
掀开SQL的神秘面纱,将优化进行到底
有这样一条奇怪的SQL,返回结果不足10行,逻辑读达到1.2w,存在索引却走多次全表扫描,如何揭开它神秘的面纱拯救系统性能,答案在这里,你不可错过!
本文来自上周四大讲堂课程分享。
在某运营商的优化经历中曾经遇到了一条比较有意思的SQL。
该最开始的sql执行情况如下:
SQL语句:
执行计划如下:
统计信息如下:
针对以上信息我们分析如下:
1) 该sql每天执行上千次,平均每次执行返回不到10行数据,但是平均逻辑读达到1.2W,可能存在性能问题。
2)ID为4,5的执行计划路径中出现了两个全表扫描,看到这儿我们可以想到可能是没有合适的索引导致走了全表扫描从而执行效率低下。
3)ID为2的执行计划路径出现了FILTER,且3,和6为其子路径,如果FILTER有两个及两个以上的子路径,那么他的执行原理将类似于嵌套循环,id号最小的子路径如果返回行数较多,可能会导致多次执行id号更小的子路径,导致性能低下。一般存在“OR EXISTS”的时候会出现此情况,可以根据情况避免。
4)存在条件“rownum<500”,但是从历史的执行情况来看,返回行数都远小于500行,此处我们先予以忽略。
处理过程:
1、进过探查,发现存在两个表都有可用的索引,且两个表都只有几十M的大小。
2、去掉“OR EXISTS”子句查看执行效率。
执行计划和统计信息如下:
此处可用看到,去掉“OR EXISTS”之后两个表走了合适的索引,并且执行效率极高。
3、去掉“OR EXISTS”中的子句查看执行效率。
SQL> SELECT A.OFFER_SPEC_GRP_ID
FROM OFFER_SPEC_GRP_RELA A
WHERE A.SUB_OFFER_SPEC_ID = 109910000618;
OFFER_SPEC_GRP_ID
-----------------
100000048
109090086
Elapsed: 00:00:00.01
执行计划和统计信息如下:
此处可用看到“OR EXISTS”中的子句单独执行返回行数并不多,且效率依旧很快。
4、我们把该条sql语句分为“OR EXISTS”的子句和其他部分两块,到此我们可以看到,两块的执行效率都很高,但是合在一起就低了很多。在这种情况下,几乎可以确认,将该存在“OR EXISTS”的子句改写为union必将提升效率。
执行计划如下:
统计信息:
此处我们可以看到,改写之后逻辑读仅仅11,较优化前提升了上千倍。到了此处,我们已经将sql优化到几乎最快的效率了。
第二次分析,确实改写能够提升效率,但是如果改写sql会涉及到修改代码,当前能否在不修改代码的情况下对其进行优化。
1)我们再来回顾一下最开始的执行计划路径。
我们可以看到“OR EXISTS”中的子句是在ID为6的路径才开始执行的,这儿有一个知识点即为一个sql中的子句,一般情况下默认会将其放到最后执行。
2)ID为4,5的执行计划路径中在有高效索引的情况下却出现了两个全表扫描,可以推断CBO可能没有正常评估执行的cost。
3)“OR EXISTS”中的子句执行效率很快,返回行数并不多,我们可以考虑提升CBO将其提前执行,看能否影响CBO选择出更高效的执行计划。
执行计划如下:
统计信息如下:
来看另外一种情况:
执行计划和统计信息如下:
此处我们在子句中加了一个HINT /*+ push_subq */,该HINT的作用即使提醒CBO将子句提前执行。
我们可以看到,执行效率较之前也得到了显著提升,逻辑读降低了7倍作用,虽然相对于改写效率还是高很多,但是在急需处理的情况下该方案还是更加可取的,此时对执行计划进行绑定即可,无需修改代码。
4)最后执行计划中还是存在全表扫描,我使用hint使其强制走索引查看情况:
执行计划和统计信息如下:
此时虽然走了索引,但是却是”INDEX FULL SCAN“,逻辑读也增加了很多,所以此时可以保持之前全表扫描的执行计划。
索引虽好,但不是万能的,只有结合系统的具体 情况,才能选择性能最佳的SQL。
案例总结:
1)当我们看到总的逻辑读除以最后的返回的行数过大时可以认为sql确实是存在性能瓶颈的(有些时候rownum限制除外),但是这没有一个清晰的值来判断过大还是过小,需要凭借优化的经验去评估。但是1200左右逻辑读/条这么夸张的比值还是完全可以判断的,毕竟在某些情况下两三个逻辑读就能获取上百条结果。
2)很多设计不合理的业务,没有添加合适的索引,可能会导致全表扫描,在某些情况下走全表和走索引产生性能的消耗根本不是一个数量级的。
3)filter和嵌套循环类似,可以看做是升级版的嵌套循环。而嵌套循环,oracle从较小结果集中读取一行,然后和较大结果集中所有数据逐条进行比较,如果符合规则,就放入结果集中,然后去较小结果集的下一条数据继续进行循环,直到结束。嵌套循环只适合输出较少结果集或者用于快速输出结果集。
4)某些时候符合我们限制条件的条数过多,但是我们用rownum进行条数限制之后可能会改变其选择执行计划。假如一个sql本来能够返回10000W,但是我用rownum来限制只需要500行。那么优化器会选择能够优先返回500行的执行计划。
数据分析咨询请扫描二维码
若不方便扫码,搜微信号:CDAshujufenxi
CDA 数据分析师报考条件详解与准备指南 在数据驱动决策的时代浪潮下,CDA 数据分析师认证愈发受到瞩目,成为众多有志投身数 ...
2025-07-18刚入职场或是在职场正面临岗位替代、技能更新、人机协作等焦虑的打工人,想要找到一条破解职场焦虑和升职瓶颈的系统化学习提升 ...
2025-07-182025被称为“AI元年”,而AI,与数据密不可分。网易公司创始人丁磊在《AI思维:从数据中创造价值的炼金术 ...
2025-07-18CDA 数据分析师:数据时代的价值挖掘者 在大数据席卷全球的今天,数据已成为企业核心竞争力的重要组成部分。从海量数据中提取有 ...
2025-07-18SPSS 赋值后数据不显示?原因排查与解决指南 在 SPSS( Statistical Package for the Social Sciences)数据分析过程中,变量 ...
2025-07-18在 DBeaver 中利用 MySQL 实现表数据同步操作指南 在数据库管理工作中,将一张表的数据同步到另一张表是常见需求,这有助于 ...
2025-07-18数据分析师的技能图谱:从数据到价值的桥梁 在数据驱动决策的时代,数据分析师如同 “数据翻译官”,将冰冷的数字转化为清晰的 ...
2025-07-17Pandas 写入指定行数据:数据精细化管理的核心技能 在数据处理的日常工作中,我们常常需要面对这样的场景:在庞大的数据集里精 ...
2025-07-17解码 CDA:数据时代的通行证 在数字化浪潮席卷全球的今天,当企业决策者盯着屏幕上跳动的数据曲线寻找增长密码,当科研人员在 ...
2025-07-17CDA 精益业务数据分析:数据驱动业务增长的实战方法论 在企业数字化转型的浪潮中,“数据分析” 已从 “加分项” 成为 “必修课 ...
2025-07-16MySQL 中 ADD KEY 与 ADD INDEX 详解:用法、差异与优化实践 在 MySQL 数据库表结构设计中,索引是提升查询性能的核心手段。无论 ...
2025-07-16解析 MySQL Update 语句中 “query end” 状态:含义、成因与优化指南 在 MySQL 数据库的日常运维与开发中,开发者和 DBA 常会 ...
2025-07-16如何考取数据分析师证书:以 CDA 为例 在数字化浪潮席卷各行各业的当下,数据分析师已然成为企业挖掘数据价值、驱动决策的 ...
2025-07-15CDA 精益业务数据分析:驱动企业高效决策的核心引擎 在数字经济时代,企业面临着前所未有的数据洪流,如何从海量数据中提取有 ...
2025-07-15MySQL 无外键关联表的 JOIN 实战:数据整合的灵活之道 在 MySQL 数据库的日常操作中,我们经常会遇到需要整合多张表数据的场景 ...
2025-07-15Python Pandas:数据科学的瑞士军刀 在数据驱动的时代,面对海量、复杂的数据,如何高效地进行处理、分析和挖掘成为关键。 ...
2025-07-15用 SQL 生成逆向回滚 SQL:数据操作的 “后悔药” 指南 在数据库操作中,误删数据、错改字段或误执行批量更新等问题时有发生。 ...
2025-07-14t检验与Wilcoxon检验的选择:何时用t.test,何时用wilcox.test? t 检验与 Wilcoxon 检验的选择:何时用 t.test,何时用 wilcox. ...
2025-07-14AI 浪潮下的生存与进阶: CDA数据分析师—开启新时代职业生涯的钥匙(深度研究报告、发展指导白皮书) 发布机构:CDA数据科 ...
2025-07-13LSTM 模型输入长度选择技巧:提升序列建模效能的关键 在循环神经网络(RNN)家族中,长短期记忆网络(LSTM)凭借其解决长序列 ...
2025-07-11