MySQL运维实战之PHP访问MySQL，你使用对了吗(3)

strace -s200 -f php mysql1.php 跟踪

大家可以看到这个模式下，prepare的时候，是不会将query发送给服务端的，只有execute的时候才会发送。

跟业务方确认后，他们使用的是后者，也就是修改了默认值，他们原本是想提升数据库的性能，，因为预处理后只需要传参数就好了。

但是对于我们的业务场景并不适合，我们的场景是频繁打开关闭连接，也就是预处理基本就用不到。

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

调整和验证

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

dba:(none)> show global status like 'Com_stmt_prepare';  
+------------------+-----------+  
| Variable_name | Value |  
+------------------+-----------+  
| Com_stmt_prepare | 716836596 |  
+------------------+-----------+  
1 row in set (0.00 sec) 

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

总结

•  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模式，前提是要做好测试  

【编辑推荐】

1. PingCAP CTO 黄东旭：我眼中的未来数据库技术趋势
2. 3 月数据库排行：MySQL 指数持续大涨，PostgreSQL 下跌
3. 推荐 | 超实用的MySQL数据库乱码问题的对应方式
4. 数据库之分库分表-垂直？水平？
5. 什么影响了数据库查询速度、什么影响了MySQL性能？

（编辑：ASP站长网）