数据库管理-第212期 上期SQL性能优化勘误与扩展（20240624）

数据库管理-第212期 上期SQL性能优化勘误与扩展（20240624）

作者：胖头鱼的鱼缸（尹海文）
Oracle ACE Pro: Database（Oracle与MySQL）
PostgreSQL ACE Partner
10年数据库行业经验，现主要从事数据库服务工作
拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证
墨天轮MVP、认证技术专家、年度墨力之星，ITPUB认证专家、专家百人团成员，OCM讲师，PolarDB开源社区技术顾问，HaloDB外聘技术顾问，OceanBase观察团成员，青学会MOP技术社区（青年数据库学习互助会）技术顾问
圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号，非著名社恐（社交恐怖分子）
公众号：胖头鱼的鱼缸；CSDN：胖头鱼的鱼缸（尹海文）；墨天轮：胖头鱼的鱼缸；ITPUB：yhw1809。
除授权转载并标明出处外，均为“非法”抄袭

上一期写完之后，和一些朋友和前辈讨论了一下，尤其是和老虎刘（公众号《老虎刘谈SQL优化》主理人，SQL优化大佬）深入沟通了一下，发现昨天有点赶的文章还是有点问题。

1 环境

昨天写完了，和朋友讨论时就发现了一些问题：

• 表是未分区的小表（文章均已修改），如涉及分区表可能会对优化器有影响
• 数据库版本是19c（具体为19.17），不同的数据库版本优化器会有不同
• 基本硬件为3台80c768G服务器搭建的RAC集群，私网为2条万兆网做的双活，存储为16Gbps EMC VMax
• 具体执行计划如下：
  

2 方案1问题

昨天通过调整谓词顺序的方案1其实是不合理的，这里引用下刘老师的留言反馈：

where后面谓词条件的先后顺序不影响索引的选择，所以方案1的调整是没有意义的，除非使用的是rbo，而且rbo好像也是先使用后面的谓词条件

由于本次实际优化也没有采用这个方案，是基于我以前处理问题的记忆来写的，翻查了以前的优化记录综合了几次优化其实大概做了3件事情：

• 调整谓词顺序
• 收集统计信息
• 删除不合理索引

这中间生效的的应该是后两种方式，而“删除不合理索引”也要根据是否有其他语句需要用到对应索引来判断，最终的解决方案都是在可调整代码和表的时候通过复合索引解决的。
因此昨天写的方案1是不合理的，应当删除。

3 问题引申

本节还是引用下刘老师的留言反馈：

索引选择错误的原因应该是直方图，索引聚簇因子和绑定变量窥视的共同作用；
方案2使用联合索引的做法是最佳的，因为2个条件都是等值条件，所以复合索引两个字段的先后顺序也是没关系，除非sn还有独立作为谓词条件的情况

那么确实方案2是最合理的解决方法，而是否附加收集直方图统计信息，则需要根据具体情况判断了。
关于方案3：

前面说ID和sn组合是唯一，那就可以创建唯一索引，没有必要创建扩展统计信息

这一点是业务方反馈，但我认为还是慎用，如果出现特殊情况可能影响业务。
关于执行时间：

如果ID和sn的条件是唯一，那么这个update应该是一个批量update（bulk），一个批次可能执行上万次，才可能用10秒那么长时间

经过与业务方进一步沟通，该操作确实是定期的批量更新操作。

总结

昨天的文章确实有不合理、不严谨的地方，在本期进行勘误及扩展，这里也感谢刘老师的反馈，获益良多。
老规矩，知道写了些啥。