MySQL Processlist中的statistics状态
作者：互联网
我有一个繁忙的MySQL服务器有查询
SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592885621) FOR UPDATE
其中pqr_sess_id是表中的主键.
当我独立执行查询时,它在0.00秒内完成,但我已经多次观察到查询挂起的是具有状态统计信息的进程列表.
可能是什么问题,我在慢速日志中发现这个查询的计数超过10K次.
mysql> show full processlist;
+------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Id | User | Host | db | Command | Time | State | Info |
+------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| 2899 | root | 192.168.9.217:49340 | abdulrony | Query | 58 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592885621) FOR UPDATE |
| 2977 | root | 192.168.9.217:35082 | abdulrony | Query | 30 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=593059341) FOR UPDATE |
| 3010 | root | 192.168.9.217:44607 | abdulrony | Query | 3 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595647701) FOR UPDATE |
| 3011 | root | 192.168.9.217:44287 | abdulrony | Query | 33 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=593503321) FOR UPDATE |
| 3014 | root | 192.168.9.217:49280 | abdulrony | Query | 3 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595641601) FOR UPDATE |
| 3016 | root | 192.168.9.217:60243 | abdulrony | Query | 51 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=592248641) FOR UPDATE |
| 3033 | root | 192.168.9.217:49695 | abdulrony | Query | 22 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=594780861) FOR UPDATE |
| 3034 | root | 192.168.9.217:44473 | abdulrony | Query | 27 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=594503601) FOR UPDATE |
| 3038 | root | 192.168.9.217:55093 | abdulrony | Query | 1 | statistics | SELECT sys_sess_state, index_state, timeout_lvl, last_queued_dt, last_polled_wait_dt, create_id, create_dt, modify_id, modify_dt FROM PQR_AM_SYSTEM_SESSION WHERE (pqr_sess_id=595625241) FOR UPDATE |
+------+-----------------+---------------------+-----------+---------+------+-----------------------------+--------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
22 rows in set (0.00 sec)
我知道我可以通过将optimizer_search_depth设置为某个低值来调整它.默认值如下所示,但我有一个表参与查询,所以我认为不会有所帮助.
SHOW variables like 'optimizer_search_depth';
+------------------------+-------+
| Variable_name | Value |
+------------------------+-------+
| optimizer_search_depth | 62 |
+------------------------+-------+
1 row in set (0.00 sec)
解决方法:
如果查询thead保持更长时间的统计信息表明服务器可能是磁盘绑定执行其他工作.
如何减少磁盘绑定：
1)增加innodb_buffer_pool_size的大小
如果您正在使用Innodb表,那么当表数据缓存在InnoDB缓冲池中时,它可以被查询一遍又一遍地处理,而不需要任何磁盘I / O.使用innodb_buffer_pool_size选项指定缓冲池的大小.此内存区域非常重要,繁忙的数据库通常指定大小约为物理内存量的80％.
2)在某些版本的GNU / Linux和Unix中,使用Unix fsync()调用(默认情况下InnoDB使用)和类似方法将文件刷新到磁盘的速度非常慢.如果数据库写入性能存在问题,请将innodb_flush_method参数设置为O_DSYNC进行基准测试.
3)增加innodb_log_buffer_size的大小 – 设置分配给存储InnoDB预写日志条目的缓冲区的内存量.对于大型事务,可以将日志加载到日志缓冲区中,而不是将日志写入磁盘上的日志文件,直到每次事务提交都刷新日志缓冲区.如果在运行时显示show innodb状态输出中的大型日志I / O,则可能需要为innodb_log_buffer_size参数设置较大的值以节省磁盘I / O.
4)增加用于缓存表和查询的内存 – 检查它们的缓存命中率
检查并增加这些MySQL变量：
query_cache_size,query_cache_limit,query_cache_min_res_unit,tmp_table_size,join_buffer_size,sort_buffer_size等.
5)确保将正确的索引应用于服务器上的所有表并使用正确的数据类型.
您可以参考这些链接来解决磁盘限制问题：
http://dev.mysql.com/doc/refman/5.5/en/disk-issues.html
https://blogs.oracle.com/luojiach/entry/mysql_innodb_performance_tuning_for
标签：query-performance,mysql,mysql-5-1,transaction 来源： https://codeday.me/bug/20190806/1597446.html