|
如何验证业务方是否将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)
通过观察，发现这个值没有变化，说明调整已经生效
总结
- 1. 防止SQL注入
- 2. 特定场景下提升性能
- 什么是特定场景： 就是先去服务端用占位符占位，后面可以直接发送请求来填空（参数值）
- 这样理论上来说， 你填空的次数非常多，性能才能发挥出来
- 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模式，前提是要做好测试
【编辑推荐】
- PingCAP CTO 黄东旭：我眼中的未来数据库技术趋势
- 3 月数据库排行：MySQL 指数持续大涨，PostgreSQL 下跌
- 推荐 | 超实用的MySQL数据库乱码问题的对应方式
- 数据库之分库分表-垂直？水平？
- 什么影响了数据库查询速度、什么影响了MySQL性能？
【责任编辑：庞桂玉 TEL：（010）68476606】
点赞 0 （编辑：晋中站长网）
【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!
|
