• 前言

  • 最近压测完毕以后, MySQL 报 Can't create more than max_prepared_stmt_count statements. 正常情况下是程序没有关闭 stmt 导致. 也不排除并发量很大, MySQL 没机会去关闭. 这种情况我们系统来说出现概率较少, 并发量还没有那么大. 以下为定位问题的过程.

• 操作

  • 1、出现此类问题, 如果是线上应立即执行 set global max_prepared_stmt_count = 1048576，先控制住错误。然后进行定位代码。它的取值范围为“0 - 1048576”，默认为16382。show variables like '%prepared%' 查看当前max_prepared_stmt_count的最大值。

  • 2、以下为在测试环境的操作，首先开启mysql日志，容易定位错误。  set global general_log = on;

  • 3、查看mysql日志存放路径，show variables where Variable_name like "general_log%" 结果中会显示。

  • 4、set global max_prepared_stmt_count = 1000 设置小点, 容易复现错误. 静待错误发生.（也可以直接看日志, 但是日志太多, 不是很方便）

  • 5、错误爆发后，SHOW GLOBAL STATUS LIKE 'com_stmt%'。查看数据库 prepare 的情况。如果Com_stmt_close与Com_stmt_prepare之间的差过大就会报错。

    

  • 6、查看日志。正常情况日志由prepare、execute、close stmt组成，如果发现有很多prepare与execute组成，而没有close stmt则基本定位到这条sql没有close stmt。查看sql，定位源码。