在MySQL台湾服务器中，慢查询日志最初只是捕获比较“慢”的查询，而性能剖析却需要针对所有的查询。而且在MySQL 5.0及之前的版本中，慢查询日志的响应时间的单位是秒，粒度太粗了。幸运的是，这些限制都已经成为历史了。在MySQL 5.1 及更新的版本中，慢日志的功能已经被加强，可以通过设置long query_ time为0来捕获所有的查询，而且查询的响应时间单位已经可以做到微秒级。如果使用的是Percona Server,那么5.0版本就具备了这些特性，而且PerconaServer提供了对日志内容和查询捕获的更多控制能力。

        在MySQL的当前版本中，慢查询日志是开销最低、精度最高的测量查询时间的工具。如果还在担心开启慢查询日志会带来额外的1/O开销，那大可以放心。我们在I/O密集型场景做过基准测试，慢查询日志带来的开销可以忽略不计(实际上在CPU密集型场景的影响还稍微大一些)。更需要担心的是日志可能消耗大量的磁盘空间。如果长期开启慢查询日志，注意要部署日志轮转(log rotation)工具。或者不要长期启用慢查询日志，只在需要收集负载样本的期间开启即可。

        MySQL还有另外种查询日志， 被称之为“通用日志”，但很少用于分析和剖析台湾服务器性能。通用日志在查询请求到台湾服务器时进行记录，所以不包含响应时间和执行计划等重要信息。MySOL 5.1之后支持将日志记录到数据库的表中，但多数情况下这样做没什么必要。这不但对性能有较大影响，而且MySQL 5.1在将慢查向记录到文件中时已经支持微秒级别的信息，然而将慢查询记录到表中会导致时间粒度退化为只能到秒级。而秒级别的慢查询目志没有太大的意义。

        Perconn Server 的慢查询日志比MySOL官方版本记录了更多细节且有价值的信息，如查询执行计划、锁、10活动等。这些特性都是随着处理各种不同的优化场最的需求而慢慢加进来的。另外在可管理性上也进行了增强。比如全局修改针对每个连接的long_query. time 的阔值，这样当应用使用连接池或者持久连接的时候，可以不用重置会话级别的变量而启动或者停止连接的查询日志。总的来说，慢查询日志是种轻量而 且功能全面的性能剖析工具，是优化台湾服务器查询的利器。

        有时因为某些原因如权限不足等，无法在台湾服务器上记录查询。这样的限制我们也常常碰到，所以我们开发了两种替代的技术，都集成到了Percona Toolkit 中的pt-query-digest中。第种是通过 -processis选项不断查看SHOW FULL PROCESSLIST 的输出，记录查询第一次出现的时间和消失的时间。某些情况下这样的精度也足够发现问题，但却无法捕获所有的查询。此执行较快的查 询可能在两次执行的间隙就执行完成了， 从而无法捕获到。

        第二种技术是通过抓取TCP网络包，然后根据MySQL的客户端/服务端通信协议进行解析。可以先通过tcpdump将网络包数据保存到磁盘，然后使用pt-query-digest的--type=tcpdump选项来解析并分析查询。此方法的精度比较高，并且可以捕获所有查询。还可以解析更高级的协议特性，比如可以解析二进制协议，从而创建并执行服务端预解析的语句(prepared statement)及压缩协议。另外还有种方法，就是通过MySQLProxy代理层的脚本来记录所有查询，但在实践中我们很少这样做。