1100万大表11秒SQL优化
【摘要】 时间:上周六刚刚从外面回来，报出生产数据慢SQL开始优化```javascriptselect t.x te.xfrom o_detail tleft join p_detail teon t.A = te.A and t.B = te.Band t.C = te.C and t.D = te.Dwhere t.A = '' and t.B = ''and te.C = '' and t.D...
时间:上周六刚刚从外面回来，报出生产数据慢SQL开始优化
```javascript
select
t.x te.xfrom o_detail t
left join p_detail te
on t.A = te.A and t.B = te.Band t.C = te.C and t.D = te.D
where t.A = '' and t.B = ''and te.C = '' and t.D = 0group by t.B,t.C,te.X,te.id,te.Y
```
分析执行计划
因为te表未用到索引造成全表扫描
大表总数据条数
那就看看为什么没走索引 怎么才能走索引 业务能不能优化 影不影响主数据？
分析各表在ABC字段均建立了索引或者覆合索引，唯独D字段未建立索引，那么是否D字段应该建索引呢？先强制走te表索引或者覆合索引
效果显著
但是现在在模拟生产数据后te表仍然无法走任何索引
思路一：
查询t表，te表，全部索引
show index from t
show index from te
字段索引都有为什么不走？索引顺序正确啊，唯独没有D索引
强制走索引是否能提高效率？
是否覆盖索引优于普通索引？
优化计划1
将关联条件去掉，改为group by分组条件 走索引
but 结果集不符合场景数量
提出想法：能不能为了索引 再用程序把商品去重呢，被否定
优化计划二
将重复的结果集去重，结果集正确，且走索引时间优化效果显著
在兴奋中带着成果验证后上线了
周一暴雷，商品结果正确，数量正确，但是在某一字段未进行筛选导致结果明细错误
最终还是采用去掉D字段，程序汇总过滤
【版权声明】本文为华为云社区用户原创内容，转载时必须标注文章的来源（华为云社区）、文章链接、文章作者等基本信息， 否则作者和本社区有权追究责任。如果您发现本社区中有涉嫌抄袭的内容，欢迎发送邮件进行举报，并提供相关证据，一经查实，本社区将立刻删除涉嫌侵权内容，举报邮箱：
cloudbbs@huaweicloud.com
- 点赞
- 收藏
- 关注作者
评论（0）