這篇文章將為大家詳細(xì)講解有關(guān)MySQL中慢查詢報(bào)警怎么處理，小編覺(jué)得挺實(shí)用的，因此分享給大家做個(gè)參考，希望大家閱讀完這篇文章后可以有所收獲。

平?jīng)鼍W(wǎng)站制作公司哪家好，找創(chuàng)新互聯(lián)！從網(wǎng)頁(yè)設(shè)計(jì)、網(wǎng)站建設(shè)、微信開(kāi)發(fā)、APP開(kāi)發(fā)、成都響應(yīng)式網(wǎng)站建設(shè)公司等網(wǎng)站項(xiàng)目制作，到程序開(kāi)發(fā)，運(yùn)營(yíng)維護(hù)。創(chuàng)新互聯(lián)自2013年起到現(xiàn)在10年的時(shí)間，我們擁有了豐富的建站經(jīng)驗(yàn)和運(yùn)維經(jīng)驗(yàn)，來(lái)保證我們的工作的順利進(jìn)行。專注于網(wǎng)站建設(shè)就選創(chuàng)新互聯(lián)。

在做節(jié)后的一個(gè)基本檢查的時(shí)候，發(fā)現(xiàn)一個(gè)不太起眼的報(bào)警，報(bào)警內(nèi)容為大體為：
MySQL 每秒慢查詢次數(shù)超過(guò) <1>個(gè)on  xxxx
查看zabbix的監(jiān)控?cái)?shù)據(jù)，發(fā)現(xiàn)每秒竟然有10個(gè)左右的慢查詢，按照這個(gè)量，這個(gè)數(shù)據(jù)庫(kù)得存在多大的問(wèn)題啊。

所以覺(jué)得可能是在做一個(gè)全表掃描導(dǎo)致的sql影響。
這個(gè)數(shù)據(jù)庫(kù)算是一個(gè)核心業(yè)務(wù)，而且負(fù)載一直不高，沒(méi)有收到任何關(guān)于IO,CPU,內(nèi)存,swap的任何報(bào)警，一直在穩(wěn)定運(yùn)行，所以這是疑點(diǎn)之一。
這個(gè)庫(kù)因?yàn)楹芊€(wěn)定，平時(shí)就是檢查基本的備份和基本的空間管理和日常的基本數(shù)據(jù)維護(hù)，而且也接手時(shí)間不長(zhǎng)，所以很少去關(guān)注更多的內(nèi)容，當(dāng)我找到對(duì)應(yīng)的數(shù)據(jù)目錄，發(fā)現(xiàn)一個(gè)問(wèn)題，那就是這個(gè)慢日志文件竟然有近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
一個(gè)慢日志如此龐大，這得暗示多大的性能問(wèn)題啊，這是疑點(diǎn)之二。
當(dāng)然如此龐大的日志文件，我看看是從什么時(shí)候積累起來(lái)的
# 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]
看來(lái)這個(gè)日志積累自2013年了，所以幾年下來(lái)一直積累到了如此龐大。
當(dāng)然我們需要馬上使用新的日志文件，這個(gè)文件就權(quán)當(dāng)備份日志吧。使用mv修改日志名，然后使用mysqladmin flush-logs 刷新日志，這樣新的日志內(nèi)容就寫(xiě)到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秒的基線。
我們來(lái)看看慢查詢?nèi)罩局械膕ql
# 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;
可以從這個(gè)日志看出，其實(shí)這個(gè)查詢的執(zhí)行時(shí)間很短，肯定沒(méi)有達(dá)到慢查詢的觸發(fā)條件，不過(guò)根據(jù)執(zhí)行計(jì)劃來(lái)看，確實(shí)沒(méi)有走索引。
而且關(guān)鍵的是相關(guān)的表只有150多條記錄，實(shí)在也沒(méi)必要添加索引了吧，所以性能問(wèn)題的可能性也不大。
這個(gè)時(shí)候有一個(gè)新的參數(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     |
如果查詢沒(méi)有做索引，也會(huì)記錄到慢查詢之中，所以需要修改為off， set global log_queries_not_using_indexes =OFF即可。
然后就再也沒(méi)有這類的報(bào)警記錄了。

對(duì)于這個(gè)參數(shù)，默認(rèn)值是off,所以一般也不會(huì)觸發(fā)這個(gè)問(wèn)題。
官方對(duì)于這個(gè)參數(shù)的解釋如下：

--log-queries-not-using-indexes

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.

關(guān)于“mysql中慢查詢報(bào)警怎么處理”這篇文章就分享到這里了，希望以上內(nèi)容可以對(duì)大家有一定的幫助，使各位可以學(xué)到更多知識(shí)，如果覺(jué)得文章不錯(cuò)，請(qǐng)把它分享出去讓更多的人看到。