max_prepared_stmt_count

SqlServer迁移数据到MySQL报错

链接服务器"192.168.66.53(ewallet_lxl)"的 OLE DB 访问接口 "MSDASQL" 返回了消息 "[MySQL][ODBC 5.2(w) Driver][mysqld-5.5.17-log]Can‘t create more than max_prepared_stmt_count statements (current value: 16382)"。

消息 7343,级别 16,状态 4,第 1 行

链接服务器 "192.168.66.53(ewallet_lxl)" 的 OLE DB 访问接口 "MSDASQL" 无法 UPDATE 表 "[MSDASQL]"。

解决方案:

max_prepared_stmt_count 参数限制了同一时间在mysqld上所有session中prepared 语句的上限。

它的取值范围为“0 - 1048576”,默认为16382。

mysql对于超出max_prepared_stmt_count的prepare语句就会报Can‘t create more than max_prepared_stmt_count statements (current value: 16382)"错误。

对于现场而言,可以先将这个值调大。

一般而言,默认值应该是足够用的,因为现场的并发其实没有那么的大。一个可能的原因是应用端那边没有关闭prepared的语句。

直连后端MySQLDB执行如下命令

mysql> SHOW GLOBAL STATUS LIKE ‘com_stmt%‘;

查看如下3个参数值:

Com_stmt_close               prepare语句关闭的次数

Com_stmt_execute           prepare语句执行的次数

Com_stmt_prepare           prepare语句创建的次数

通过以下命令修改max_prepared_stmt_count的值(该值可动态修改,也可在配置文件中指定后重启服务生效)

mysql> set global max_prepared_stmt_count=100000;

Query OK, 0 rows affected (0.00 sec)

再次执行迁移脚本,成功。。。问题解决!

时间: 2024-08-09 02:21:10

max_prepared_stmt_count的相关文章

NodeJs Mysql Cant't create more than max_prepared_stmt_count statements

这阵子碰到一个数据库上的问题,一个刚上线不到一周的 NodeJs 接口服务里所有的查询全部都挂掉了,接口一直处于 pending 状态,看了下 pm2 的日志发现了报错:Cant't create more than max_prepared_stmt_count statements,重启 Node 服务后接口查询恢复正常. 网上查了查资料基本上都是让修改 max_prepared_stmt_count 的,当时觉得这个方案治标不治本就没有采纳,后来优化了一下MySQL的部分代码就让服务继续跑

MySQL 报 Can't create more than max_prepared_stmt_count statements

前言 最近压测完毕以后, MySQL 报 Can't create more than max_prepared_stmt_count statements. 正常情况下是程序没有关闭 stmt 导致. 也不排除并发量很大, MySQL 没机会去关闭. 这种情况我们系统来说出现概率较少, 并发量还没有那么大. 以下为定位问题的过程. 操作 1.出现此类问题, 如果是线上应立即执行 set global max_prepared_stmt_count = 1048576,先控制住错误.然后进行定位

Can't create more than max_prepared_stmt_count statements

使用mysql connector的时候,如果报这个错误 Can't create more than max_prepared_stmt_count statements (current value: 16382) 是因为下面的写法有一定问题,如果catch了错误,那么stmt就不会释放,最好是把stmt放到外面,在最后的时候delete,但是一般不会出问题,关键是如果写了bug,导致不断运行catch错误,就会导致preparedstatement大量不会释放,超出默认的16382的个数

阿里云RDS-MYSQL数据库参数设置,K哥

2016.9.2 最近被阿里云的数据库要搞疯掉了 自打阿里云抽风,非要取消myisam引擎,都换成innodb 没事总是主备切换,也没有错误日志 一问客服就是物理机波动,擦,波动是什么???????? 服务器自己跳舞了吗 看了看参数设置,很多都不知道 这两天有时间自己搜索整理了下 发给大家,有需要的看看 我的服务器应用主要是WEB网站服务 有一些不懂的地方或者不对的地方,还请大牛不吝赐教! 回复在评论中就可以了,thank you 我是K哥 auto_increment_offset表示自增长字

Chapter 5 MySQL Server Administration_1

Chapter 5 MySQL Server Administration Table of Contents 5.1 The MySQL Server 5.1.1 Configuring the Server 5.1.2 Server Configuration Defaults 5.1.3 Server Option and Variable Reference 5.1.4 Server Command Options 5.1.5 Server System Variables 5.1.6

MySql中的变量定义

MySql中的变量定义 根据mysql手册,mysql的变量分为两种:系统变量和用户变量.但是在实际使用中,还会遇到诸如局部变量.会话变量等概念.根据个人感觉,mysql变量大体可以分为四种类型: 一.局部变量. 局部变量一般用在sql语句块中,比如存储过程的begin/end.其作用域仅限于该语句块,在该语句块执行完毕后,局部变量就消失了. 局部变量一般用declare来声明,可以使用default来说明默认值. 例如在存储过程中定义局部变量: drop procedure if exists

记一次mysql的preparedStatement使用超限问题

[现象&背景] 本服务是个为数据库的分库分表提供路由规则计算,sql过滤执行的中间服务.即上游将请求发给本服务,本服务根据分库分表规则将相应的sql执行发送给对应的分库.分表去执行,并整理结果返回给上游. 2016-07-14下午,上游流量切换后,mysql大量报出" Can't create more than max_prepared_stmt_count statements (current value: 16382)",mysql不能工作导致本层数据库路由服务不能工作

show status中文详解

状态名 作用域 详细解释 Aborted_clients Global 由于客户端没有正确关闭连接导致客户端终止而中断的连接数 Aborted_connects Global 试图连接到MySQL服务器而失败的连接数 Binlog_cache_disk_use Global 使用临时二进制日志缓存但超过binlog_cache_size值并使用临时文件来保存事务中的语句的事务数量 Binlog_cache_use Global 使用临时二进制日志缓存的事务数量 Binlog_stmt_cache

(DBA之路【八】)关于show variables那些参数的故事

基于我自己的版本:5.5.35-1ubuntu对http://blog.csdn.net/beiigang/article/details/39030695进行了修改. 1)low_priority_updates 在myisam表中此参数用于调整读锁和写锁的优先级.默认为0. 注:(以***释来自网上) 通过指定启动参数low-priority-updates,使MyISAM引擎默认给予读请求以优先的权利.在 my.cnf 的配置方法[mysqld]low-priority-updates 通