昨天和朋友交流，联想起Oracle的两个特性，approx_count_distinct 和 SQL in Silicon，从软件到硬件，从典型SQL入手的优化，Oracle一步一步走向细节和性能的极致。 在Oracle 12c中，有一个新的函数被引入进来 - approx_count_distinct 。这个函数的作用是，当我们进行Count Distinct计算时，给出一个近似值。 TOM说，这个函数会带来5x ~ 50x的性能提升，精度可以达到97%以上。在不需要绝对精确的返回值时，这个函数可以发挥其
原则一：注意WHERE子句中的连接顺序： ORACLE采用自下而上的顺序解析WHERE子句,根据这个原理,表之间的连接必须写在其他WHERE条件之前, 那些可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾. 尤其是“主键ID=？”这样的条件。
select distinct owner from tbig where owner is not null;
优化器是 Oracle 数据库最引人入胜的部件之一，因为它对每一个 SQL 语句的处理都必不可少。优化器为每个 SQL 语句确定最有效的执行计划，这是基于给定的查询的结构，可用的关于底层对象的统计信息，以及所有与优化器和执行相关的特性。因此 Oracle 在每一个版本中，优化器都引入了新特性，本文将详细讲解 12C 中标量子查询自动转换的新特性的原理，优势，适用场景和案例分享。 1 12C 标量子查询自动转换说明 首先我们来看官方文档的说明： 标量子查询是出现在 SQL 语句的 SELECT 子句的子查询。
杨廷琨，网名 yangtingkun 云和恩墨技术总监，Oracle ACE Director，ACOUG 核心专家 只要增加了DISTINCT关键字，Oracle就会对随后跟着的所有字段进行排序去重。以前也经常发现由于开发人员对SQL不是很理解，在SELECT列表的20多个字段前面添加了DISTINCT，造成查询的执行异常缓慢，基本上很难在ORA-1555错误出现之前得到查询的结果，甚至有些SQL会产生ORA-7445错误。所以在给开发人员培训的时候还着重介绍了一下DISTINCT的功能以及不正确地使
优化器是 Oracle 数据库最引人入胜的部件之一，因为它对每一个 SQL 语句的处理都必不可少。优化器为每个 SQL 语句确定最有效的执行计划，这是基于给定的查询的结构，可用的关于底层对象的统计信息，以及所有与优化器和执行相关的特性。因此 Oracle 在每一个版本中，优化器都引入了新特性，本文将详细讲解 12C 中标量子查询自动转换的新特性的原理，优势，适用场景和案例分享。
Oracle Database 12c中加入了Data Redaction作为一个新的安全特性。（实际在11g的官方Database Advanced Security Administrator's
作者简介 苏星开 云和恩墨南区交付技术顾问，曾服务过通信、能源生产、金融等行业客户，擅长 SQL 审核和优化，DataGuard 容灾等。 1 概述 在 Oracle 12.2 版本和新发布的18.0
之前我们了解了索引的属性，以及一些对于是否能用索引似是而非的场景，相应的说明和结论可以参考，
随着2月的春风吹拂，Oracle 19c 的第一个 Exadata 版本发布将马上发布出来，等待可测试版本的朋友们马上即可如愿了。
MySQL 8.0 实现了Index skip scan，翻译过来就是索引跳跃扫描。熟悉ORACLE的朋友是不是发现越来越像ORACLE了？再者，熟悉MySQL 5.7 的朋友是不是觉得这个很类似当时优化器的选项MRR？好了，先具体说下什么 ISS，我后面全部用 ISS 简称。
用于决定在Oracle中解析目标SQL时所用优化器的类型，以及决定当使用CBO时计算成本值的侧重点。这里的“侧重点”是指当使用CBO来计算目标SQL各条执行路径的成本值时，计算成本值的方法会随着优化器模式的不同而不同。
在 ACOUG 年会的活动上，分享了一些从前未曾分享过的内容，想起，今年还欠下一篇文章，就整理和回顾一下，分享我所见到的Oracle 19c的一些重要改变（本文内容来自OOW大会演讲，关注“数据和云”公众号回复：2018OOW 获取大会PPT）。
获取准确的段对象（表、表分区、索引等）的分析数据，是CBO存在的基石。所以数据段的分析对于CBO来讲非常的重要。
为什么SQL存在性能问题？我们通过10053，可以看到经过Oracle转换的SQL如下所示，
当在SQL语句中连接多个表时, 尽量使用表的别名并把别名前缀于每个列上。这样一来,
SQL语句的逻辑处理顺序，指的是SQL语句按照一定的规则，一整条语句应该如何执行，每一个关键字、子句部分在什么时刻执行。
SQL优化技巧 1.选择最有效率的表名顺序(只在基于规则的优化器中有效): oracle的解析器按照从右到左的顺序处理 from 子句中的表名，from子句中写在最后的表(基础表 driving table)将被最先处理，在 from 子句中包含多个表的情况下, 你必须选择记录条数最少的表作为基础表。如果有 3 个以上的表连接查询, 那就需 要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. 2.where子句中的连接顺序:
ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的 情况下,你必须选择记录条数最少的表作为基础表。如果有 3 个以上的表连接查询, 那就需要选择交叉表 (intersection table)作为基础表,交叉表是指那个被其他表所引用的表。
（1） 选择最有效率的表名顺序(只在基于规则的优化器中有效)： ORACLE的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. （2） WHERE子句中的连接顺序．： ORACLE采用自下而上
. （1） 选择最有效率的表名顺序(只在基于规则的seo/' target='_blank'>优化器中有效)： ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那个被其他表所引用的表. （2） WHERE子句中的连接顺序．：
* GreatSQL社区原创内容未经授权不得随意使用，转载请联系小编并注明来源。 写在前面(By老叶)从GreatSQL 8.0.32-25版本开始支持Rapid引擎，该引擎使得GreatSQL能满足联机分析（OLAP）查询请求。老叶尝试利用Rapid引擎优化本案例，结果是相当可喜的，对比如下： -SQL执行耗时(秒)Rows_examinedRead_keyRead_nextRead_rnd_nextTmp_tablesTmp_disk_tablesTmp_table_sizesInnoDB_pages_distinct原始SQL9.943230200036368909070210877403112372448181标量子查询改写优化后2.294906728836617308100036382011284368182走Rapid引擎0.11763300001090000 上述测试结果表明：
最近做查询时，写的一条查询语句用了两个IN，导致tuexdo服务积压了不少，用户没骂就不错了。最后经过技术经理的点拨，sql语句性能提升了大约10倍，主要用了表连接、建索引、exists。这才感叹SQL性能优化的重要性啊，网上搜了半天，找到一篇令我非常满意的日志，忍不住分享之：
我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习、摘录、并汇总部分资料与大家分享！
关于对Oracle数据库查询性能优化的一个简要的总结。 从来数据库优化都是一项艰巨的任务。对于大数据量，访问频繁的系统，优化工作显得尤为重要。由于Oracle系统的灵活性、复杂性、性能问题的原因多样性以及Oralce数据库的动态特性，优化成为Oracle数据库管理中最困难的领域。作为一个对数据库了解不多的程序猿，我也只能从最基本的开始着手，慢慢来学习掌握Oracle的基础吧。
我们要做到不但会写SQL,还要做到写出性能优良的SQL,以下为笔者学习、摘录、并汇总部分资料与大家分享！ （1）选择最有效率的表名顺序(只在基于规则的优化器中有效) ORACLE 的解析器按照从右到左的顺序处理FROM子句中的表名，FROM子句中写在最后的表(基础表 driving table)将被最先处理，在FROM子句中包含多个表的情况下,你必须选择记录条数最少的表作为基础表。如果有3个以上的表连接查询, 那就需要选择交叉表(intersection table)作为基础表, 交叉表是指那
ClickHouse 是近年来分析型数据库的热点，一向以快著称，很多其它以性能为卖点的分析型数据库也常常会用它作为一个对比标杆。很多用户碰到数据库运算性能问题时，也会考虑转向求助于 ClickHouse 解决 ClickHouse 确实是有过人之处，它的列式宽表速度很快，估计是压缩做得非常好。然而，除此之外，再无长处。希望用 ClickHouse 解决数据库计算性能问题的用户，大概率会失望的。
ClickHouse 是近年来分析型数据库的热点，一向以快著称，很多其它以性能为卖点的分析型数据库也常常会用它作为一个对比标杆。很多用户碰到数据库运算性能问题时，也会考虑转向求助于 ClickHouse 解决。
语法分析> 语义分析> 视图转换 >表达式转换> 选择优化器 >选择连接方式 >选择连接顺序 >选择数据的搜索路径 >运行“执行计划”
Hive作为大数据平台举足轻重的框架，以其稳定性和简单易用性也成为当前构建企业级数据仓库时使用最多的框架之一。
数据的世界无奇不有，常常会遇到一些超出常识之外的故障的发生。这就要求广大的DBA要深入了解数据库的内部机制，面对一些奇葩的故障或者问题能够拨开迷雾找到真相。今天我们一起来盘点一下Oracle数据库中，
话团圆，画团圆，元宵佳节倍思亲，可是大家知道吗，万能的SQL可以帮助大家绘制团圆。 在ITPUB论坛里，一群SQL爱好者们会用SQL来描摹一切可能。请看如下这段SQL，为大家绘制了团团圆圆的五连环： with a as (select distinct round(a.x + b.x) x,round(a.y + b.y) y from (select (sum(x) over(order by n)) x, round(sum(y) over(ord
编辑手记：前面我们介绍常用的子查询优化方法，但总有一些情况时在规律之外。谨慎处理方能不掉坑。 前文回顾： 性能优化之查询转换 - 子查询类 将SQL优化做到极致 - 子查询优化 作者简介： 韩锋
Oracle数据库里的统计信息是一组存储在数据字典里，且从多个维度描述了数据库里对象的详细信息的一组数据。当Oracle数据库工作在CBO（Cost Based Optimization，基于代价的优化器）模式下时，优化器会根据数据字典中记录的对象的统计信息来评估SQL语句的不同执行计划的成本，从而找到最优或者是相对最优的执行计划。所以，可以说，SQL语句的执行计划由统计信息来决定，若没有统计信息则会采取动态采样的方式来生成执行计划。统计信息决定着SQL的执行计划的正确性，属于SQL执行的指导思想。若统计信息不准确，则会导致表的访问方式（例如应该使用索引，但是选择了全表扫描）、表与表的连接方式出现问题（例如应该使用HJ，但是使用了NL连接），从而导致CBO选择错误的执行计划。
小鱼（邓秋爽） 云和恩墨专家，有超过5年超大型数据库专业服务经验，擅长oracle 数据库优化、SQL优化和troubleshooting 编辑手记：如何提高数据的查询效率是每个人都关注的问题，今天让我们来学习如何合理使用标量子查询和表连接方式来提高查询速度吧~ 之前小鱼就听过了标量子查询，不过对于其中的细节理解还是远远不够，借助一部分资料和自己测试对标量子查询做一点简单的分析和介绍。 Oracle允许在select子句中包含单行子查询，这个也就是oracle的标量子查询，标量子查询有点类似于外连接，当使
最近遇到一个专门进行SQL技术优化的项目，对很多既有的老存储过程进行调优（现在已经不再新增任何存储过程），因此系统的对SQL语句编写进行一次科学的学习变得很有必要。这儿将基于黄德承大神的Oracle
在Oracle数据库中，用户发给Oracle让其执行的目标SQL和Oracle实际执行的SQL有可能是不同的，这是因为Oracle可能会对执行的目标SQL做等价改写，即查询转换。查询转换（Query Transformation），也叫逻辑优化（Logical Optimization），又称为查询改写（Query Rewrite）或软优化，即查询转换器在逻辑上对语句做一些语义等价转换，它是Oracle在解析目标SQL的过程中的非常重要的一步。查询转换能使优化器将目标SQL改写成语义上完全等价的SQL语句但生成的执行计划效率更高。
在应用系统开发初期，由于开发数据库数据比较少，对于查询SQL语句，复杂视图的的编写等体会不出SQL语句各种写法的性能优劣，但是如果将应用系统提交实际应用后，随着数据库中数据的增加，系统的响应速度就成为目前系统需要解决的最主要的问题之一。系统优化中一个很重要的方面就是SQL语句的优化。对于海量数据，劣质SQL语句和优质SQL语句之间的速度差别可以达到上百倍，可见对于一个系统不是简单地能实现其功能就可，而是要写出高质量的SQL语句，提高系统的可用性。
确定成功收集统计信息后，发现还是没有效果，在当时操作过程中认为收集统计信息后，oracle没有走上正确的索引就是成本优化器判断错误，于是决定手工绑定走错索引的sql，这也是一般的处理思路，如下示：
关于周一 Eygle 在文章《千头万绪：从一道面试题看数据库性能和安全的方方面面》讲到的 SELECT* FROM girls WHERE age BETWEEN 18 and 24 and boyfriend='no' 这个 SQL，他 从数据库 SQL优化、数据安全、SQL审核、开发规范、IN-Memory 特性方面做了深入的分析。
Oracle Database 12.2 已经让广大粉丝望眼欲穿，虽然文档已然发布，但是实验无从做起。 现在，可以通过 Oracle Live SQL 站点（文末原文链接指向该站点），在线体验Orac
题记：在多年以前，论坛活跃的时代，在ITPUB上你能看到各种新奇有趣的知识，及时新鲜的信息，出类拔萃的技巧，有很多让人多年以后还记忆犹新。 这个帖子让我忍不住在这个日子，再次发送出来，让大家一起再次体会SQL的强大和神奇能力。而写好SQL，仍然是我们持续不断的追求。 话团圆，画团圆，元宵佳节倍思亲，可是大家知道吗，万能的SQL可以帮助大家绘制团圆。 在ITPUB论坛里，一群SQL爱好者们会用SQL来描摹一切可能。请看如下这段SQL，为大家绘制了团团圆圆的五连环： with a as (select di
有朋友问了我如下这样一个问题，最后的解决过程挺有意思的，让我发现了直方图统计信息里我之前没有注意到的两个知识点，这里跟大家分享一下。 问题 数据库的版本是11.2.0.3： 创建一个测试表T1： SQ
Oracle数据库里的直方图使用了一种称为Bucket（桶）的方式来描述目标列的数据分布。Bucket（桶）是一个逻辑上的概念，相当于分组，每个Bucket就是一组，每个Bucket里会存储一个或多个目标列中的数据。Oracle会用两个维度来描述一个Bucket，这两个维度分别是ENDPOINT_NUMBER和ENDPOINT_VALUE，Oracle会将每个Bucket的这两个维度记录在数据字典基表SYS.HISTGRM$中。列的直方图的类型可以通过查询视图DBA_TAB_COL_STATISTICS的HISTOGRAM列来获取，一般情况下包含3类，NONE（没有直方图）、FREQUENCY（频率直方图，也叫等频直方图）、HEIGHT BALANCED（高度平衡直方图，也叫等高直方图）。在Oracle 12c中，又新增了两种类型的直方图，分别是顶级频率直方图（Top Frequency Histogram）和混合直方图（Hybrid Histogram），本书只讨论频率和高度平衡直方图。
我们讨论过代码编写的难和繁的原理问题，现在关注性能问题，运行速度当然是非常重要的事情。 我们知道，软件不能改变硬件的性能，CPU 和硬盘该多快就多快。不过，我们可以设计出低复杂度的算法，也就是计算量更小的算法，计算机执行的动作变少，自然也就会快了。本来要做 1 亿次运算，如果有个好算法能把计算量降低到 100 万次，那快出 100 倍就不奇怪了。但是，光想出算法还不够，还要把这个算法实实在在地用某种程序语言写出来，否则计算机不会执行。 然而，如果采用的程序语言不给力，就有可能真地写不出来，这时候就干瞪眼忍受低速度。
今天单位值班，有一些时间可以继续完成这篇连载文章。首先祝所有朋友新年快乐！感谢你们在这一年当中对我文章的关注和指点，来年我们共同继续努力！
No matter who or what, you will not destroy me. If you knock me down, I'll get back up. If you beat me, I will rise and try again.
虽说近些年来，从国内数据库市场来看，Oracle是有些势衰；但从全球角度来说，其霸主地位依然不可撼动。其技术的演讲变化，仍然对行业数据库发展有着颇大的指导引领意义。下面是我对其近三年来发布的新特性加以盘点，进而洞察行业变化，挖掘技术趋势。材料部分内容引用自盖总的《Oracle新特性》系列文章，感谢！
Oracle里的查询转换，有称为查询改写，指oracle在执行目标sql时可能会做等价改写，目的是为了更高效的执行目标sql在10g及其以后的版本中，oracle会对某些类型的查询转换（比如子查询展开、复杂视图合并等）计算成本，oracle会分别计算查询转换后的等价改写的sql的成本和原始sql的成本，如果改写后的sql的成本低于原始sql的成本，oracle才会对目标sql执行查询转换。
领取专属 10元无门槛券
手把手带您无忧上云
云服务器
ICP备案
对象存储
实时音视频
即时通信 IM
