一使用者rds每天隔一段時間就會出現iops 100%的問題，求助到阿里雲，這類問題的出現有以下一些排查思路：
排查思路：
(1).慢sql問題：通過優化索引，子查詢，隱士轉換，分頁改寫等優化；
(2).ddl：create index，optimze table，alter table add column，create as select ；
根據以上的排查思路我們首先去定位在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 ;
idselect_type
table
type
possible_keys
keykey_len
refrows
extra
1******
wn_user
range
primary
primary
4null
34234220
using where
可以看到上面搗蛋sql的執行計畫與審計日誌中的check_rows相同，所以通知使用者將該sql下線掉。
最後還有乙個疑問，為什麼慢日誌裡面沒有記錄著三條搗蛋sql，還是通過審計日誌發現，這三條sql都沒有執行成功，所以它是不會記錄到慢日誌中的。
阿里雲原廠專家服務為您的資料庫保駕護航：
SQL導致的索引失效
我們在開發中會發現,明明我這條sql語句應該是用到了索引才對,但是為何速度仍然那麼慢,其實是你的sql寫的有問題導致了索引失效,我們來看下什麼情況下mysql的索引會失效 對查詢進行優化,盡量避免全表掃瞄,避免導致索引失效 避免在where子句中 的左邊使用表示式操作或者函式操作select id ...
sql 注入例項
用於登入的表 users name,pwd 建立乙個窗體frmlogin，其上有兩個文字框text1，text2和兩個命令按鈕cmdok，cmdexit。兩個文字框分別用於讓使用者輸入使用者名稱和密碼，兩個命令按鈕用於 登入 和 退出 1 定義ado connection物件和ado records...
排名 SQL 例項
create table qspm bmh int identity 1,1 zf int insert into qspm zf select 70 union all select 80 union all select 90 union all select 88 union all sele...