共計 3374 個字符，預計需要花費 9 分鐘才能閱讀完成。
這篇文章將為大家詳細講解有關 mysql 中慢查詢報警怎么處理，丸趣 TV 小編覺得挺實用的，因此分享給大家做個參考，希望大家閱讀完這篇文章后可以有所收獲。
在做節(jié)后的一個基本檢查的時候，發(fā)現(xiàn)一個不太起眼的報警，報警內(nèi)容為大體為：
MySQL 每秒慢查詢次數(shù)超過 1 個 on xxxx
查看 zabbix 的監(jiān)控數(shù)據(jù)，發(fā)現(xiàn)每秒竟然有 10 個左右的慢查詢，按照這個量，這個數(shù)據(jù)庫得存在多大的問題啊。
所以覺得可能是在做一個全表掃描導致的 sql 影響。
這個數(shù)據(jù)庫算是一個核心業(yè)務，而且負載一直不高，沒有收到任何關于 IO,CPU, 內(nèi)存,swap 的任何報警，一直在穩(wěn)定運行，所以這是疑點之一。
這個庫因為很穩(wěn)定，平時就是檢查基本的備份和基本的空間管理和日常的基本數(shù)據(jù)維護，而且也接手時間不長，所以很少去關注更多的內(nèi)容，當我找到對應的數(shù)據(jù)目錄，發(fā)現(xiàn)一個問題，那就是這個慢日志文件竟然有近 60G
-rw-r–r– 1 root root 102M Feb 4 17:14 query.log
-rw-rw—- 1 mysql mysql 58G Feb 17 14:58 slow.log
一個慢日志如此龐大，這得暗示多大的性能問題啊，這是疑點之二。
當然如此龐大的日志文件，我看看是從什么時候積累起來的
# head -10 slow.log
# Time: 131114 13:41:59
# User@Host: app_new_bill[app_new_bill] @ xxxx_2.107 [xxxx]
# Thread_id: 131044 Schema: mobile_billing Last_errno: 0 Killed: 0
# Query_time: 0.000648 Lock_time: 0.000129 Rows_sent: 28 Rows_examined: 58 Rows_affected: 0 Rows_read: 28
# Bytes_sent: 4235 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# InnoDB_trx_id: 1718382
SET timestamp=1384407719;
select app0_.id as id1_, app0_.appname as appname1_, app0_.appkey as appkey1_, app0_.appsecret as appsecret1_, app0_.iplist as iplist1_, app0_.isshow as isshow1_, app0_.flag as flag1_, app0_.test_version as test8_1_, app0_.create_date as create9_1_, app0_.game_type as game10_1_, app0_.callback_url as callback11_1_, app0_.iappay_id as iappay12_1_, app0_.isactivate as isactivate1_ from test_app app0_ where app0_.isshow=1 order by app0_.create_date desc;
# Time: 131114 13:42:01
# User@Host: app_new_bill[app_new_bill] @ xxxx_2.107 [xxxx]
看來這個日志積累自 2013 年了，所以幾年下來一直積累到了如此龐大。
當然我們需要馬上使用新的日志文件，這個文件就權(quán)當備份日志吧。使用 mv 修改日志名，然后使用 mysqladmin flush-logs 刷新日志，這樣新的日志內(nèi)容就寫到 slow.log 里面了。
切換之后的情況如下：
-rw-rw—- 1 mysql mysql 16195105 Feb 17 15:54 slow.log
-rw-rw—- 1 mysql mysql 61757873052 Feb 17 15:02 slow.log.bak
目前的慢查詢的配置是 2 秒的基線。
我們來看看慢查詢?nèi)罩局械?sql
# InnoDB_trx_id: 1B5249A5
SET timestamp=1455695652;
select * from tb_version_update where appkey= 1400140930701 and media_channel_id= 2014142002 and take_effect_date 2016-02-17 15:54:12 and is_take_effect=1 and isshow=1;
# User@Host: app_sdk_hero[app_sdk_hero] @ xxxx_128.100 [xxxx]
# Thread_id: 4537955 Schema: mobile_billing Last_errno: 0 Killed: 0
# Query_time: 0.000570 Lock_time: 0.000072 Rows_sent: 0 Rows_examined: 158 Rows_affected: 0 Rows_read: 0
# Bytes_sent: 1753 Tmp_tables: 0 Tmp_disk_tables: 0 Tmp_table_sizes: 0
# InnoDB_trx_id: 1B5249A6
SET timestamp=1455695652;
select * from tb_version_update where appkey= 1400140930701 and media_channel_id= 2010321003 and take_effect_date 2016-02-17 15:54:12 and is_take_effect=1 and isshow=1;
可以從這個日志看出，其實這個查詢的執(zhí)行時間很短，肯定沒有達到慢查詢的觸發(fā)條件，不過根據(jù)執(zhí)行計劃來看，確實沒有走索引。
而且關鍵的是相關的表只有 150 多條記錄，實在也沒必要添加索引了吧，所以性能問題的可能性也不大。
這個時候有一個新的參數(shù)，也是跟同事那兒取經(jīng)所得。log_queries_not_using_indexes
# mysqladmin var|grep index
| expand_fast_index_creation | OFF |
| fast_index_creation | ON |
| innodb_adaptive_hash_index | ON |
| innodb_adaptive_hash_index_partitions | 8 |
| log_queries_not_using_indexes | ON |
如果查詢沒有做索引，也會記錄到慢查詢之中，所以需要修改為 off，set global log_queries_not_using_indexes =OFF 即可。
然后就再也沒有這類的報警記錄了。
對于這個參數(shù)，默認值是 off, 所以一般也不會觸發(fā)這個問題。
官方對于這個參數(shù)的解釋如下：
–log-queries-not-using-indexes
Command-Line Format
–log-queries-not-using-indexes System Variable
Name
log_queries_not_using_indexes Variable Scope
Global Dynamic Variable
Yes Permitted Values
Type
boolean Default
OFF
If you are using this option with the slow query log enabled, queries that are expected to retrieve all rows are logged. See Section 5.2.5,“The Slow Query Log”. This option does not necessarily mean that no index is used. For example, a query that uses a full index scan uses an index but would be logged because the index would not limit the number of rows.
關于“mysql 中慢查詢報警怎么處理”這篇文章就分享到這里了，希望以上內(nèi)容可以對大家有一定的幫助，使各位可以學到更多知識，如果覺得文章不錯，請把它分享出去讓更多的人看到。
