MySQL的瓶頸，一般分爲IO密集型和CPU密集型
CPU出問題的情況比較少，最近就遇到過一次比較大的故障，這個話題後面會有一篇專題介紹
今天主要聊聊IO密集型的應用中，我們應該如何快速定位到是誰佔用了IO資源比較多
背景
- 環境
1. MySQL 5.7 +
低版本MySQL這邊不再考慮，就像還有使用SAS盤的公司一樣，費時費力，MySQL5.7+ 標配
2. InnoDB 存儲引擎
3. Centos 6
實戰
關於IO的問題，大家能想到的監控工具有哪些
- iostat
- dstat
- iotop
沒錯，以上都是神器，可以直接用iotop找到佔用資源最多的進程
先上一張圖
是的，根據這張圖，你能發現的就是MySQL的某個io線程佔用了比較多的disk資源，然後呢？
然後，就是去MySQL裏面去找，有經驗的DBA會去看slow log，或者processlist中去查找相關的sql語句
通常情況下，DBA只會一臉茫然的看到一堆MySQL的query語句，一堆slow log裏面去分析，有如大海撈針，定位問題繁瑣而低效
如果，你使用的是MySQL5.7+ 版本，那麼你就會擁有一件神器（說了好多遍了），可以快速而精準的定位問題
- 如何快速定位到IO瓶頸消耗在哪裏
iotop + threads
dba:lc> select * from performance_schema.threads where thread_os_id=37012\G
*************************** 1. row ***************************
THREAD_ID: 96
NAME: thread/sql/one_connection
TYPE: FOREGROUND
PROCESSLIST_ID: 15
PROCESSLIST_USER: dba
PROCESSLIST_HOST: NULL
PROCESSLIST_DB: sbtest
PROCESSLIST_COMMAND: Query
PROCESSLIST_TIME: 0
PROCESSLIST_STATE: query end
PROCESSLIST_INFO: INSERT INTO sbtest1(k, c, pad) VALUES(25079106, '33858784348-81663287461-16031064329-06006952037-79426243027-69964324491-90950423034-40185804987-62166137368-06259615216', '47186118229-42754
696460-81034599900-41836403072-66805611739'),(24907169, '77074724245-16833049423-38868029911-54850236074-63700733526-39699866447-52646750572-85552352492-59476301007-32196580154', '79013412600-99031855741-696987
96712-65630963686-19653514942'),(24896311, '28403978193-66350947863-03931166713-97714847962-65299790981-39948912629-14070597101-63277652140-34421148430-61801121402', '05239379274-22840441238-37771744512-9234774
1972-52847679847'),(18489383, '89292717216-01584483614-67433536730-45584233994-29817613740-77179131661-10692787267-83942773303-14971155500-36206705010', '55201342831-85536327239-84383935287-06948377235-96437333
726'),(24790463, '99362943588-41160434740-62783664419-16002619743-04761662097-94273988379-52564232648-19738707042-79143532768-89687113917', '09717575620-89781830996-88443720661-19001024583-14971953687'),(2
PARENT_THREAD_ID: NULL
ROLE: NULL
INSTRUMENTED: YES
HISTORY: YES
CONNECTION_TYPE: Socket
THREAD_OS_ID: 37012
1 row in set (0.00 sec)
你看，消耗資源的SQL語句立刻就呈現在你眼前，就是如此高效
好了，以上列出的，還只是全部功能的冰山一角，更多的玩法等待你去解鎖。
以上定位的問題也比較的簡單，還有一些複雜的IO問題，比如：binlog寫入過大、binlog掃描過多、同步線程阻塞、臨時表造成的IO過大，等等問題，都可以用此神器一窺究竟