目录SQL优化本质 MYSQL培训 腾科TOGOGO.doc

目录SQL优化的本质 SQL优化Road Map 2.1 制定SQL优化目标 2.2 检查执行计划 2.3 检查统计信息 2.4 检查高效访问结构 2.5 检查影响优化器的参数 2.6 SQL语句编写问题 2.7 SQL优化器限制导致的执行计划差 SQL优化案例 SQL执行计划获取 4.1 如何获取准确的执行计划 4.2 看懂执行计划执行顺序 一SQL优化的本质 一般来说，SQL优化是让SQL运行得更快，使SQL更快的方式有很多，比如提高索引的使用效率，或者并行查询。可以看到里面的公式： 执行效率或者一般说的执行时间，是和完成一次SQL所需要访问的资源总量（S）成正比以及单位时间内能够访问的资源量（V）成反比，S越大，效率越低，V越大效率越高。 比如通过并行查询，则可以提升单位时间内访问的资源量。 当然，这仅仅是从执行时间上考虑，SQL优化肯定不仅仅是执行时间降低，应该是资源使用与执行时间降低之间寻求一种平衡，否则，盲目并行，可能提升不了效率，反而让系统资源消耗殆尽。 最终来说，SQL优化的本质就是：1、缩短响应时间；2、提升系统吞吐量；3、提升系统负载能力。要使用多种手段，在提升系统吞吐量和增加系统负载能力，提高单个SQL效率之间寻求一种平衡。就是要尽量减少一条SQL需要访问的资源总量，比如走索引更好，那么不要使用全表扫描。 二SQL优化Road Map 一条SQL的优化路线图如下所示： 具体操作步骤： 2.1 制定SQL优化目标 获取待优化SQL、制定优化目标：从AWR、ASH、ORA工具等主动发现有问题的SQL、用户报告有性能问题DBA介入等，通过对SQL的执行情况进行了解，先初步制定SQL的优化目标。 2.2 检查执行计划 explain工具、sql*plus autotrace、dbms_xplan、10046、10053、awrsqrpt.sql等。 执行计划是我们进行SQL优化的核心内容，无计划，不优化。看执行计划有一些技巧，也有很多方式，各种方式之间是有区别的。 2.3 检查统计信息 ORACLE使用DBMS_STATS包对统计信息进行管理，涉及系统统计信息、表、列、索引、分区等对象的统计信息，统计信息是SQL能够使用正确执行计划的保证。我们知道，ORACLE CBO优化器是利用统计信息来判断正确的执行路径，JOIN方式的，因此，准确的统计信息是产生正确执行计划的首要条件。 可以从这个图看出，一条SQL产生执行计划需要经过哪些步骤，在我看来：1、正确的查询转换；2、准确的统计信息，是产生正确执行计划的重要保证。当然，还有BUG，或优化器限制等也会导致SQL效率低下，无法产生正确的执行计划。 如图所示： 2.4 检查高效访问结构 重要的访问结构，诸如索引、分区等能够快速提高SQL执行效率。表存储的数据本身，如碎片过多、数据倾斜严重、数据存储离散度大，也会影响效率。 2.5 检查影响优化器的参数 optimizer_mode、optimizer_index_cost_adj、optimizer_dynamic sampling、_optimizer_mjc_enabled、_optimizer_cost_based_transformation、hash_join_enable等对SQL执行计划影响较大。比如有时候我们通过禁用_optimizer_mjc_enabled 参数，让执行计划不要使用笛卡尔积来提升效率，因为这个参数开启有很多问题，所以一般生产库都要求禁用。 还有什么能够影响执行计划呢？对，new features,每个版本的new features，引入的目的都是好的，但是实际使用中，可能触发BUG。比如11g的ACS(自适应游标共享）、automatic serial direct path（自动串行直接路径读）、extended statistics、SQL query result cache等。有的新特性会导致问题，所以需要谨慎使用。 比如11g adaptive cursor sharing,自适应游标共享，它的引入是为了解决使用绑定变量与数据倾斜值，要产生多样性执行计划。因为绑定变量是为了共享执行计划，但是数据倾斜了，有的值要求走索引，有的值要求走全表，这样与使用绑定变量就产生了矛盾。以前是通过cursor_sharing=similar这样的设置可以解决，但是有很多BUG，会产生version count过高的问题，或者我们对不同的值（如果值很少），可以写多条SQL来解决，这都不是好的方案，11g acs引入就是为了解决这些问题，让这些东西交给oracle来做。但是事与愿违，以后你们遇到执行计划一会变一下，有快有慢，首先可以检查acs有没有关闭。 alter system set “_op