UPDATE查询上的MySQL high lock_time导致服务器冻结
内容导读
互联网集市收集整理的这篇技术教程文章主要介绍了UPDATE查询上的MySQL high lock_time导致服务器冻结，小编现在分享给大家，供广大互联网技能从业者学习和参考。文章包含3735字，纯文字阅读大概需要6分钟。
内容图文
这让我很难过.请帮我.我的生产服务器每周冻结一次.有些查询锁定行,并阻止其他查询,一直消耗100％的CPU.我需要在服务器恢复工作之前手动终止那些冻结的查询.
我有一个系统,将根据任何给定的插槽在网站上显示最高的CTR横幅.这是我的表结构.
CREATE TABLE IF NOT EXISTS `banners` (
`banner_id` int(5) NOT NULL AUTO_INCREMENT,
`banner_slot` varchar(15) NOT NULL,
`banner_img_path` varchar(200) NOT NULL,
`banner_link` varchar(200) NOT NULL,
`banner_views` int(8) NOT NULL DEFAULT '1',
`banner_clicks` int(8) NOT NULL DEFAULT '0',
`banner_ctr` double(5,3) NOT NULL DEFAULT '0',
PRIMARY KEY (`banner_id`),
KEY `banner_slot` (`banner_slot`,`banner_views`,`banner_ctr`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8 AUTO_INCREMENT=4231;
这在生产服务器上运行(CentOS6.3 / MySQL 5.5.28 / Apache2 / Quad核心CPU / 8GB RAM).很老,我知道.
服务器还运行了几个wordpress站点,我已经使用了WP超级缓存插件.来自wordpress的一些查询出现在慢查询日志文件中,但它们都在5秒以内.
最近,我每天的页面浏览量大约为20K.在高峰时段有大约2-3K UIP(所有域合并).
这是我的my.cnf设置：
innodb_file_per_table=1
open_files_limit=10192
skip-external-locking
key_buffer_size=800M
max_allowed_packet=100M
table_open_cache=512
table_cache=500
sort_buffer_size=2M
read_buffer_size=4M
read_rnd_buffer_size=8M
thread_cache_size=4
query_cache_type=0
query_cache_size=4M
join_buffer_size=8M
tmp_table_size=512M
max_heap_table_size=256M
max_connections=200
这是我的慢查询日志文件.你会看到这里有一个基本查询的锁定时间很长.
# Query_time: 84.554967 Lock_time: 37.070954 Rows_sent: 0 Rows_examined: 1
use db_name;
SET timestamp=1537010708;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=6;
# Query_time: 84.614748 Lock_time: 37.130587 Rows_sent: 0 Rows_examined: 1
use db_name;
SET timestamp=1537010708;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=60;
# Query_time: 54.288041 Lock_time: 0.000018 Rows_sent: 0 Rows_examined: 1
SET timestamp=1537010708;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=884;
# Query_time: 104.154232 Lock_time: 34.661097 Rows_sent: 0 Rows_examined: 1
use db_name;
SET timestamp=1537010744;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=60;
# Query_time: 107.847145 Lock_time: 38.354068 Rows_sent: 0 Rows_examined: 1
SET timestamp=1537010744;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=6;
# Query_time: 81.974780 Lock_time: 26.446288 Rows_sent: 0 Rows_examined: 1
SET timestamp=1537010771;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=6;
# Query_time: 102.331612 Lock_time: 46.507686 Rows_sent: 0 Rows_examined: 1
use db_name;
SET timestamp=1537010772;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=60;
# Query_time: 81.808158 Lock_time: 36.196089 Rows_sent: 0 Rows_examined: 1
SET timestamp=1537010772;
UPDATE banners SET banner_views=banner_views+1 WHERE banner_id=7;
我已经浏览了mysql-tuner.pl,几乎所有设置都是基于建议的绿色.
我也解释了所有的SELECT查询,这些都是使用索引.因为我在MySQL 5.5上运行,所以我无法解析任何其他查询.
有关我的问题的任何建议？提前致谢！任何帮助表示赞赏！
解决方法:
每秒速率= RPS
建议您考虑my.cnf [mysqld]部分
# 20180916 12:30 by mysqlservertuning.com
query_cache_size=0 # from 4M conserve RAM & CPU QC type=0 = OFF to start with
read_buffer_size=128K # from 4M to reduce CPU busy & handler_read_next RPS
read_rnd_buffer_size=256K # from 8M to reduce CPU busy & handler_read_rnd_next RPS
join_buffer_size=128K # from 8M to conserve RAM
thread_cache_size=32 # from 4 to reduce threads_created & CPU overhead
max_heap_table_size=512M # from 256M should be same as tmp_table_size always
将现有的my.cnf复制到某处,(以防万一)
日期行和所有6个变量要复制到my.cnf的[mysqld]部分的END
覆盖以前请求的值.
停止/启动您的实例或重新启动您的实例.如果时间允许,请SKYPE我.
内容总结
以上是互联网集市为您收集整理的UPDATE查询上的MySQL high lock_time导致服务器冻结全部内容，希望文章能够帮你解决UPDATE查询上的MySQL high lock_time导致服务器冻结所遇到的程序开发问题。 如果觉得互联网集市技术教程内容还不错，欢迎将互联网集市网站推荐给程序员好友。
内容备注
版权声明：本文内容由互联网用户自发贡献，该文观点与技术仅代表作者本人。本站仅提供信息存储空间服务，不拥有所有权，不承担相关法律责任。如发现本站有涉嫌侵权/违法违规的内容， 请发送邮件至 gblab@vip.qq.com 举报，一经查实，本站将立刻删除。
内容手机端
扫描二维码推送至手机访问。