高性能MySQL（三）

服务器性能剖析

性能优化概述

性能优化是降低CPU使用率？错误，资源就是用来消耗的，新版本MySQL的InnoDB引擎对资源的利用率还增高了，所以这不是一个好的衡量标准。

提升每秒查询量？其实就是吞吐量，但吞吐量也只是性能优化的副产品，恰好是性能的倒数。

降低响应时间，这才是优化的重点，但容易误解的是影响响应时间的因素有很多，我们应该关注于最耗时的几个操作。

性能分析有几点比较重要，值得优化的查询、异常、未知错误、隐藏的细节，好的工具可以获取足够的信息。

对应用进行性能剖析

数据库有时并不是主要的瓶颈，因此最好从整个应用的角度进行测量。

性能剖析本身会导致应用变慢，但相对之后的优化，这是值得的。

有很多SaaS工具软件支持应用剖析。

剖析MySQL查询

慢查询日志是官方提供的性能分析工具，配置long_query_time=0来开启捕获所有查询，响应时间单位可达微秒级。

慢查询日志几乎没什么性能影响，但注意对磁盘消耗较大，通常只在需要剖析时开启一段时间慢查询。

剖析单条查询

设置SET PROFILING = 1;然后通过SHOW PROFILES;获得ID，通过SHOW PROFILE FOR QUERY [ID]查看详细信息。

// 无法直接排序结果，但可通过INFOMATION_SCHEMA中对应的表来排序结果
SELECT STATE, SUM(DURATION) AS Total_R
FROM INFORMATION_SCHEMA.PROFILING
WHERE QUERY_ID = 7
GROUP BY STATE
ORDER BY Total_R DESC;

SHOW STATUS是一个计数器，并不能反映时间消耗，但可以用作参考。

SHOW STATUS
WHERE Variable_name LIKE 'Handler%'
OR Variable_name LIKE 'Created%';

总结

1. 定义性能最有效的方法就是响应时间；
2. 无法测量就无法有效优化；
3. 测量最好从应用开始而不是数据库，即使问题出现在数据库；
4. 完整的测量需要分析大量数据，找些工具最好；
5. 剖析报告丢弃了很多细节，不要完全依赖；
6. 消耗时间的操作有两种：工作和等待；
7. 优化和提升是两回事，若提升的成本超过收益就应该停止；
8. 决策应该基于数据而不是直觉。