572
搗蛋SQL導致實例iops 100%
一用戶RDS每天隔一段時間就會出現IOPS 100%的問題，求助到阿裏雲，這類問題的出現有以下一些排查思路：
排查思路：
(1).慢SQL問題：通過優化索引，子查詢，隱士轉換，分頁改寫等優化；
(2).DDL：create index，optimze table，alter table add column，create as select ；
一.慢SQL
根據以上的排查思路我們首先去定位在IOPS高的時間段慢SQL，通過排查發現慢日誌中根本就沒有明顯的慢日誌出現，數據庫慢日誌設置的時間閥值是1秒，難道是我們的閥值太大了嗎？不對，IOPS張高期間數據庫的QPS並沒有明顯增加，所以看來並不是慢日誌的問題。
二.DDL
慢日誌中沒有發現線索，那麼是不是DDL導致的，用戶有定時的DDL任務或者create as select的操作，這個可以通過審計日誌進行排查跟蹤，結果還沒有發現問題所在，高峰期間並沒有DDL操作。
三.審計日誌
經過上麵兩步驟的排查並沒有結果，所以這個時候隻能排查一些IOPS高峰期間的所有SQL了，這是沒有的辦法的辦法。把出問題時間段的SQL審計日誌拉出來進行分析，結果讓人很驚喜：
我們發現有三條SQL執行時間超過了900秒，同時掃描的行數也超過了3kw，很明顯iops高的原因就是這三條SQL在搗蛋：
mysql> explain SELECT * FROM user WHERE id != 6088883 AND name like '34218864' OR id =34218864 LIMIT 0, 1 ;
+----+-------------+---------+-------+-------------------------------+---------+---------+------+----------+-------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+---------+-------+-------------------------------+---------+---------+------+----------+-------------+
| 1 | SIMPLE | wn_user | range | PRIMARY | PRIMARY | 4 | NULL | 34234220 | Using where |
+----+-------------+---------+-------+-------------------------------+---------+---------+------+----------+-------------
可以看到上麵搗蛋SQL的執行計劃與審計日誌中的check_rows相同，所以通知用戶將該SQL下線掉。
最後還有一個疑問，為什麼慢日誌裏麵沒有記錄著三條搗蛋sql，還是通過審計日誌發現，這三條sql都沒有執行成功，所以它是不會記錄到慢日誌中的。
最後更新：2017-06-05 11:33:56