MySQL数据库慢的排查思路

       数据库慢，如何排查？相信这个问题是所有DBA在工作中常遇到的一个问题。以下是总结的一些思路。

数据库应用，常见两种类型：CPU密集型和I/O密集型。因此，我们在排查数据库问题时，通常是从这两方面入手的。

CPU密集型的数据库，性能问题有以下几种：
1.复杂的查询语句、存储过程、触发器、自定义函数等；

2.锁竞争问题；

3.并发量大。

解决问题的思路：

1.通过慢查询日志，找出相关语句，优化查询语句调整索引策略。还可以将复杂存储过程、触发器、自定义函数交由应用代码实现；

2.根据infomation_schema中的innodb_trx、innodb_locks、innodb_lock_watis三种表，找出锁的事务与开发协调。如果场景允许，可以考虑把事务隔离级别降到读提交。

3.做读写分离、水平拆分。或者增加缓存层，让高并发的读写压力由缓存层消化；

4.调整mysql跟cpu相关参数，这里不一一罗列。

I/O密集型的数据库，性能问题有以下几种：
1.投影了所有字段、全表扫描、表结构设计、索引设计问题等；

2.内存缓冲区设置过小，造成了过多的磁盘I/O；

3.网络带宽较小（常见于分布式系统中）。

解决问题的思路：

1.通过慢查询日志，找出执行时间久，而且结果集大的语句。减少投影的字段，只选择必要的字段做投影，优化表结构与索引设计；

2.调整内存缓冲区、日志刷新、刷新方法等等参数的设置，这里不一一罗列；

3.提升网络带宽，调整内核参数。

如果上述措施还不能解决问题或者效果不明显，可以考虑扩容。扩容分为：纵向扩展和横向扩展。
纵向扩展：一般用于解决响应时间长的问题。增加CPU计算能力可以减少响应时间，增加内存可以减少磁盘I/O，并将磁盘做raid5、10、01或者直接使用SSD提升I/O处理能力；

横向扩展：一般用于解决高并发量问题。比如做简单的读写分离、使用mycat将数据量做分片等，尽量将单机压力分担出去。

这里提到了解决高并发量的问题，其实还可以用异步的方式，将压力前移到缓存层，降低写入压力；同时，缓存一些热点数据，也能大大减轻读压力。