商丘网站公司,设计公司简介范文,软件设计说明书模板,网站制作公司 信科网络数据库管理211期 2024-06-23 数据库管理-第211期 记一次简单的SQL性能优化#xff08;20240623#xff09;1 起因2 变化3 排查问题4 优化方案1方案2方案3 5 效果总结 数据库管理-第211期 记一次简单的SQL性能优化#xff08;20240623#xff09; 作者#xff1a;胖头鱼的鱼… 数据库管理211期 2024-06-23 数据库管理-第211期 记一次简单的SQL性能优化202406231 起因2 变化3 排查问题4 优化方案1方案2方案3 5 效果总结 数据库管理-第211期 记一次简单的SQL性能优化20240623 作者胖头鱼的鱼缸尹海文 Oracle ACE Pro: DatabaseOracle与MySQL PostgreSQL ACE Partner 10年数据库行业经验现主要从事数据库服务工作 拥有OCM 11g/12c/19c、MySQL 8.0 OCP、Exadata、CDP等认证 墨天轮MVP、认证技术专家、年度墨力之星ITPUB认证专家、专家百人团成员OCM讲师PolarDB开源社区技术顾问HaloDB外聘技术顾问OceanBase观察团成员青学会MOP技术社区青年数据库学习互助会技术顾问 圈内拥有“总监”、“保安”、“国产数据库最大敌人”等称号非著名社恐社交恐怖分子 公众号胖头鱼的鱼缸CSDN胖头鱼的鱼缸尹海文墨天轮胖头鱼的鱼缸ITPUByhw1809。 除授权转载并标明出处外均为“非法”抄袭 这是发生在本周五的一个很简单的SQL性能优化案例。而且这次没有发生在一体机上而是自建的3节点X86集群上。因为本案例均涉及生产环境内容所有内容均脱敏且无截图。 1 起因 业务方反馈说在调整数据内容过后一张表上的update语句执行会超过2分钟而该语句在之前运行不会这么久。这个语句的大概内容是 update xxx set a:1,b:2,c:3 where id:4 and sn:5;2 变化 首先既然业务方说数据调整过后出现的问题那么看看调整了哪些内容其实很简单就是增加了id列的类型sn也扩展了因此数据量从原来的60W扩展到了120W。但就查询你语句来说没有任何变化。 3 排查问题 首先从执行计划来看索引是走的id对应的列上的索引再检查表的索引是id列和sn列上都建了单独的索引。 执行计划一开始显示索引仅扫描了1700行就被程序结束了怀疑统计信息有问题收集统计信息后预估行变成了60W行。因此向业务方确认id和sn列中数据的唯一性情况反馈为id为分类唯一性较少sn唯一性较多但是二者必须联查才能获取对应的唯一行。 4 优化 方案1 直接调整语句将唯一性较高的列放在where语句的第一位作为引导列使用sn列上的单独索引 update xxx set a:1,b:2,c:3 where sn:5 and id:4;这样可以通过sn列上的索引筛选出更少的行再与id列进行匹配好处是无需调整索引但性能不一定是最好的。 方案2 在方案1的基础上删除sn和id列上的索引并重新创建包含sn、id列且sn为引导列的复合索引 create index idx_xxx on xxx(sn,id);这样可以更好的利用sn和id列的关系充分利用索引问题就是重建索引过程中可能影响语句运行。 方案3 基于方案2其实还可以锦上添花因为sn和id列其实是存在一定关联关系的那么在Oracle中可以再增加收集一个多列统计信息 var v1 varchar2(1000); exec :v1:dbms_stats.create_extended_stats(USERNAME,XXX,(SN,ID)); exec dbms_stats.gather_table_stats(USERNAME,XXX,method_opt for columns (SN,ID));5 效果 最后完成方案2的优化操作后该语句执行时间降低至10s内完成。 总结 本期内容是一次简单的通过调整引导列和使用复合索引的SQL性能优化。 老规矩知道写了些啥。