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