前言

大家都知道，slow query系统做的好不好，直接决定了解决slow query问题的效率。 一个数据库管理平台，拥有一个好的slow query系统，基本上就拥有了解锁性能问题的钥匙。但是今天主要分享的并不是平台，而是在平台中看到的奇葩指数五颗星的slow issue。

好了，关子卖完，直接进入正题。

症状

数据库的慢SQL日志中发现了一堆如下慢查询：

从我们的监控图上可以看到，每天不定时间段的slow query 总数在攀升，但是却看不到任何query 语句，这是我接触到的slow query优化案例中从来没有过的情况，比较好奇，也比较兴奋，至此决心要好好看看这个问题。

排查

要解决这个问题，首先想到的是，如何复现这个问题，如何模拟复现这个症状。

MySQL客户端模拟prepare

perl 模拟prepare

结论：跟MySQL客户端一样，同样是看不到administrator command: Prepare

PHP 模拟 prepare

PHP 模拟得到的slow结果

结论： 通过php代码，我们成功模拟出了想要的结果

那顺藤摸瓜，抓取下这段时间有相同session id的整个sql执行过程。

MySQL开启slow=0的抓包模式

结论：我们发现，prepare时间的确很长，但是sql语句却执行的很快，这就很尴尬了

本来是想通过抓包，看看是否能够验证我们的猜想： prepare的语句非常大，或者条件非常复杂，从而导致prepare在服务器端很慢，结果发现query语句也都非常简单。那么既然如此，我们就找了业务方，将对应业务的prepare方法一起看看，结果发现，业务使用的是php-pdo的方式，所以我们就又有了如下发现：

php-pdo 两种prepare模式

1.本地prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,true)； 不会发送给MySQL Server

2.服务器端prepare $dbh->setAttribute(PDO::ATTR_EMULATE_PREPARES,false； 发送给MySQL Server

官网说明：

验证两种prepare模式

服务端prepare模式( ATTR_EMULATE_PREPARES = false)

strace -s200 -f php mysql1.php 跟踪如下图

这个模式下，prepare的时候是将query+占位符发送给服务端的。

本地prepare模式 (ATTR_EMULATE_PREPARES=true )

strace -s200 -f php mysql1.php 跟踪如下图

这个模式下，prepare的时候是不会将query发送给服务端的，只有execute的时候才会发送。跟业务方确认后，他们使用的是后者，也就是修改了默认值，他们原本是想提升数据库的性能，因为预处理后只需要传参数就好了，但是对于我们的业务场景并不适合，我们的场景是频繁打开关闭连接，也就是预处理基本就用不到。

另外文档上面也明确指出prepared statements 性能会不好。

调整和验证

如何验证业务方是否将prepare修改为local了呢？

通过观察，发现这个值没有变化，说明调整已经生效。

总结prepare的优点

1. 防止SQL注入

2. 特定场景下提升性能

什么是特定场景： 就是先去服务端用占位符占位，后面可以直接发送请求来填空（参数值）。这样理论上来说， 你填空的次数非常多，性能才能发挥出来。

prepare的缺点

1. 在服务器端的prepare毕竟有消耗，当并发量大，频繁prepare的时候，就会有性能问题。

2. 服务端的prepare模式还会带来的另外一个问题就是，排错和slow 优化有困难，因为大部分情况下是看不到真实query的。

3. 尽量设置php-pdo为 $pdo->setAttribute(PDO::ATTR_EMULATE_PREPARES,true) ，在本地prepare，不要给服务器造成额外压力。

最后的建议

1. 默认情况下，应该使用php-pdo的默认配置，采用本地prepare的方式，这样可以做到防SQL注入的效果，性能差不到哪里去。

2. 除非真的是有上述说的特定场景，可以考虑配置成服务器prepare模式，前提是要做好测试。

欢迎大家关注“58架构师”微信公众号，定期分享云计算、AI、区块链、大数据、搜索、推荐、存储、中间件、移动、前端、运维等方面的前沿技术和实践经验。