MySQL 5.5 Community Server MySQL 5.6 Community Server Percona Configuration Wizard XtraBackup 搭建主从复制 Great Sites on MySQL Percona MySQL Performance Blog Severalnines 推荐管理工具 Sequel Pro phpMyAdmin 推荐书目 MySQL Cookbook
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html
MySQL 相关项目 MariaDB Drizzle 参考文档 http://mysql-python.sourceforge.net/MySQLdb.html 
这是一个创建于 3953 天前的主题，其中的信息可能已经有所发展或是发生改变。
大概环境是多台机器并发写一个集中式的mysql，做了分区、索引等必要的操作
现在发现每天每台机器大约有几十次 Lock wait timeout 情况出现
出现的时候，并非mysql性能不佳，而是有的进程sleep时可能没有释放资源导致其他进程 insert/update被迫等待并超时
程序代码里应该是哪里有问题，但一时难以排查的情况下，有什么系统级解决办法？
即通过对mysql进行配置操作后缓解这种状况？ 谢谢！
现在发现每天每台机器大约有几十次 Lock wait timeout 情况出现
出现的时候，并非mysql性能不佳，而是有的进程sleep时可能没有释放资源导致其他进程 insert/update被迫等待并超时
程序代码里应该是哪里有问题，但一时难以排查的情况下，有什么系统级解决办法？
即通过对mysql进行配置操作后缓解这种状况？ 谢谢！
 | 1 SoloCompany 2015-02-27 12:28:37 +08:00 via Android Show processlist |
 | 2 2dog OP @SoloCompany 看过了，包括 innodb_locks_wait表，的确是在waiting某个thread id，该thread sleep了半天，kill掉就好。 |
| 3 SoloCompany 2015-02-27 14:19:13 +08:00 你说的 thread wait 应该是 mysql 进程的 thread 吧，如果是这样的话，那应该是 innodb 的 bug 啊，怎么会需要排查程序代码呢，总不成是 trigger 或者 store procedure 能导致这样级别的问题存在吧 |
| 4 2dog OP @SoloCompany 是的，就是mysql内的thread id。应该不是innodb的bug，本质上应该是程序写的逻辑有问题，导致插入数据后没有 commit ，转而干别的事情去了，从而影响了其他进程提交。 没用复杂的数据库功能，trigger、存储过程都没用 |
Select Language