如何确定服务器是否已经达到了性能最佳的状态？
找出某条语句为什么执行不够快？
诊断被用户描述成停顿，卡死的间歇性疑难故障
性能优化
数据库服务器的性能用查询的响应时间来度量，单位是每个查询花费的时间。
CPU利用率只是一种现象，而不能很好地度量目标。
如果把性能优化仅看成是提升每秒查询量，这其实只是吞吐量优化，即单位时间内的查询数。
如果目标要降低响应时间，需要理解为什么服务器执行查询需要这么多时间，应先测量时间花在什么地方。
完成一项任务所需时间分为两部分：执行时间和等待时间。
优化任务的执行时间，最好通过测量定位不同的子任务花费的时间，去掉一些子任务，降低子任务执行频率或提升子任务的效率。
优化等待时间要复杂，等待可能是由其他系统间接影响。
一些只占总响应时间比重很小的查询是不值得优化的。
某些任务即使没有出现在性能剖析输出的前面也要优化。比如某些任务执行次数很少，但每次执行都非常慢，严重影响用户体验。
剖析查询
慢查询日志，剖析找出代价高的查询，开启后保存在磁盘上，记录包含查询响应时间和执行计划。
通用日志在查询请求到服务器时进行记录。
将慢查询日志作为参数传递给pt-query-digest，可将查询的剖析报告打印出来。
查询时间分布直方图有明显尖峰，可能是查询条件传递了不同值，值的分布不均衡，导致服务器选择不同索引，或是查询缓存命中，实际很少见。
show profile。给出查询执行每个步骤及花费时间，但是没有按花费时间排序。可直接查询informaton_schema对应的表。
show status。大部分结果是一个计数器，显示某些活动如读索引的频繁程度。有服务器级别的全局计数器，也有基于某个连接的会话级别计数器。
对于偶尔记录到的几次查询异常慢的问题，很难知道原因，因信息有限。可能是系统中其他东西消耗了资源，如正在备份，也可能是某种类型的锁或争用阻塞了查询进度。
诊断间歇性问题
可能是缓存中的一些重要条目过期，大量请求落到MySQL以重新生成缓存条目。
当并发度超过某个阈值，InnoDB的扩展性导致查询计划的优化需要很长时间。
首先要确认这是单条查询的问题，还是服务器的问题。如果服务器上所有程序都突然变得特别慢，慢查询不一定是原因。如果服务器整体运行没有问题，只有某条查询偶尔变慢，就需要把注意力放到这条特定的查询上。
show global status。通过计数器的尖峰分析问题，服务器内部可能遇到瓶颈，导致新查询在开始执行前因需要获取老查询正在等待的锁而造成堆积。
show processlist。观察是否有大量线程处于不正常状态。
总结
MySQL执行速度慢，是一条执行慢，还是全部执行慢。慢在哪，是查询执行慢，还是等待响应慢。
一条SQL语句执行得很慢的原因有哪些