MySQL之SQL优化拭魅战记录

被核准多久. # InnoDB在其拥有的锁表中自动检测事宜死锁而且回滚事宜. # 假如你行使 LOCK TABLES 指令, 可能在同样事宜中行使除了InnoDB以外的其他事宜安详的存储引擎 # 那么一个死锁也许产生而InnoDB无法留意到. # 这种环境下这个timeout值对付办理这种题目就很是有辅佐. innodb_lock_wait_timeout=30# 开启按时event_scheduler=ON

按照营业，再加上筛选前提

快4-5s

将where前提中除时刻前提外的字段成立连系索引

结果没那么明明

将where前提中索引前提行使inner join的方法去关联

针对这条，我自身认为很惊讶。原sql,b为索引

select aa from bb_2018_10_02 left join ... on .. left join .. on .. where b = 'xxx' 

应该之前有union all，union all是一个一个的执行，最后汇总的功效。修改为

select aa from bb_2018_10_02 left join ... on .. left join .. on .. inner join 
( 
    select 'xxx1' as b2 
    union all 
    select 'xxx2' as b2 
    union all 
    select 'xxx3' as b2 
    union all 
    select 'xxx3' as b2 
) t on b = t.b2 

功效快了3-4s

机能瓶颈

按照以上操纵，3天查询服从已经到达了8s阁下，再也快不了了。查察mysql的cpu行使率和内存行使率都不高，到底为什么查这么慢了，3天最多才60w数据，关联的也都是一些字典表，不至于云云。继承按照网上提供的资料，一系列骚操纵，根基没用，没辙。

情形比拟

因说明过sql优化已经ok了，试想是不是磁盘读写题目。将优化过的措施，别离陈设于差异的现场情形。一个有ssd，一个没有ssd。发明查询服从悬殊。用软件检测过发明ssd读写速率在700-800M/s,平凡机器硬盘读写在70-80M/s。

优化功效及结论

• 优化功效：到达预期。
• 优化结论：sql优化不只仅是对sql自己的优化，还取决于自己硬件前提，其他应用的影响，外加自身代码的优化。

小结

优化的进程是自身的一个历练和检验，珍惜这种机遇，不做只写营业代码的措施员。但愿以上可以有助于你的思索，不敷之处望指正。

【编辑保举】

1. 漫衍式数据库TiDB在贸易银行的计划与实践
2. 数据库两大必备神器：索引和锁底层道理是什么！
3. 继承深入数据库 相识一下数据库的锁机制
4. 想用数据库“读写疏散” 请先大白“读写疏散”办理什么题目
5. 数据库常用的事宜断绝级别都有哪些？都是什么道理？

（编辑：湖南网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!