数据库管理212期 2024-06-24
- [数据库管理-第212期 上期SQL性能优化勘误与扩展（20240624）](#数据库管理-第212期 上期SQL性能优化勘误与扩展（20240624）)
-
- [1 环境](#1 环境)
- [2 方案1问题](#2 方案1问题)
- [3 问题引申](#3 问题引申)
- 总结
数据库管理-第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秒那么长时间
经过与业务方进一步沟通，该操作确实是定期的批量更新操作。
总结
昨天的文章确实有不合理、不严谨的地方，在本期进行勘误及扩展，这里也感谢刘老师的反馈，获益良多。
老规矩，知道写了些啥。