MySQL简单的确定瓶颈
如果接到报警可能需要ssh看看瓶颈是什么,怎么下手
确定os层
确定磁盘是否够用的；df –h
再看看系统整体状态： top
哪些进程占用资源比较多，能杀就杀
系统的负载
vmstat看看wa值，r列的值或者iostat –dx查看是否是IO的问题
进程IO占用情况，iotop
CPU，sar，vmstat的us%和id%的值高否
MySQL层面
哪些进程或者查询：mysqladmin pr; show processlist
一般慢查询太多IO就会很高，比如在大表中使用max聚合函数，实际上基本可以通过优化来减少检索的数据量，比如，max可以先倒排再区第一条记录即可
CPU很高的话，select可能存在大量的计算
看看慢查询是什么情况
总结
常见导致负载较高情况：
- 一次请求读写的数据量太大，导致磁盘I/O读写值较大，例如一个SQL里要读取或更新几万行数据甚至更多，这种最好是想办法减少一次读写的数据量；
- SQL查询中没有适当的索引可以用来完成条件过滤、排序（ORDER BY）、分组（GROUP BY）、数据聚合（MIN/MAX/COUNT/AVG等），添加索引或者进行SQL改写吧；
- 瞬间突发有大量请求，这种一般只要能扛过峰值就好，保险起见还是要适当提高服务器的配置，万一峰值抗不过去就可能发生雪崩效应；
- 因为某些定时任务引起的负载升高，比如做数据统计分析和备份，这种对CPU、内存、磁盘I/O消耗都很大，最好放在独立的slave服务器上执行；
- 服务器自身的节能策略发现负载较低时会让CPU降频，当发现负载升高时再自动升频，但通常不是那么及时，结果导致CPU性能不足，抗不过突发的请求；
- 使用raid卡的时候，通常配备BBU（cache模块的备用电池），早期一般采用锂电池技术，需要定期充放电（DELL服务器90天一次，IBM是30天），我们可以通过监控在下一次充放电的时间前在业务低谷时提前对其进行放电，不过新一代服务器大多采用电容式电池，也就不存在这个问题了。
- 文件系统采用ext4甚至ext3，而不是xfs，在高I/O压力时，很可能导致%util已经跑到100%了，但iops却无法再提升，换成xfs一般可获得大幅提升；
- 内核的io scheduler策略采用cfq而非deadline或noop，可以在线直接调整，也可获得大幅提升。
