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. 数据库常用的事务隔离级别都有哪些？都是什么原理？

（编辑：辽源站长网）

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