SHOW PROCESSLIST顯示哪些線程正在運行。您也可以使用mysqladmin processlist語句得到此信息。如果您有SUPER權限，您可以看到所有線程。否則，您只能看到您自己的線程（也就是，與您正在使用的MySQL賬戶相關的線程）。請參見13.5.5.3節，“KILL語法”。如果您不使用FULL關鍵詞，則只顯示每個查詢的前100個字符。
本語句報告TCP/IP連接的主機名稱（采用host_name:client_port格式），以方便地判定哪個客戶端正在做什么。
如果您得到“too many connections”錯誤信息，並且想要了解正在發生的情況，本語句是非常有用的。MySQL保留一個額外的連接，讓擁有SUPER權限的 賬戶使用，以確保管理員能夠隨時連接和檢查系統（假設您沒有把此權限給予所有的用戶）。
- mysql> show full processlist;
- +---------+-------------+--------------------+----------------+-------------+-------+-----------------------------------------------------------------------+-----------------------+
- | Id | User | Host | db | Command | Time | State | Info |
- +---------+-------------+--------------------+----------------+-------------+-------+-----------------------------------------------------------------------+-----------------------+
- | 1056536 | replication | 192.168.6.91:38417 | NULL | Binlog Dump | 33759 | Master has sent all binlog to slave; waiting for binlog to be updated | NULL |
- | 1107067 | miaohr | 192.168.6.81:32024 | NULL | Query | 0 | NULL | show full processlist |
- | 1107182 | miaohr | 192.168.6.91:44217 | hr_db_business | Sleep | 1 | | NULL |
- +---------+-------------+--------------------+----------------+-------------+-------+-----------------------------------------------------------------------+-----------------------+
這個命令中最關鍵的就是state列，mysql列出的狀態主要有以下幾種：
Checking table
正在檢查數據表（這是自動的）。
Closing tables
正在將表中修改的數據刷新到磁盤中，同時正在關閉已經用完的表。這是一個很快的操作，如果不是這樣的話，就應該確認磁盤空間是否已經滿了或者磁盤是否正處於重負中。
Connect Out
復制從服務器正在連接主服務器。
Copying to tmp table on disk
由於臨時結果集大於tmp_table_size，正在將臨時表從內存存儲轉為磁盤存儲以此節省內存。
Creating tmp table
正在創建臨時表以存放部分查詢結果。
deleting from main table
服務器正在執行多表刪除中的第一部分，剛刪除第一個表。
deleting from reference tables
服務器正在執行多表刪除中的第二部分，正在刪除其他表的記錄。
Flushing tables
正在執行FLUSH TABLES，等待其他線程關閉數據表。
Killed
發送了一個kill請求給某線程，那么這個線程將會檢查kill標志位，同時會放棄下一個kill請求。MySQL會在每次的主循環中檢查kill標志位，不過有些情況下該線程可能會過一小段才能死掉。如果該線程程被其他線程鎖住了，那么kill請求會在鎖釋放時馬上生效。
Locked
被其他查詢鎖住了。
Sending data
正在處理SELECT查詢的記錄，同時正在把結果發送給客戶端。
Sorting for group
正在為GROUP BY做排序。
Sorting for order
正在為ORDER BY做排序。
Opening tables
這個過程應該會很快，除非受到其他因素的干擾。例如，在執ALTER TABLE或LOCK TABLE語句行完以前，數據表無法被其他線程打開。正嘗試打開一個表。
Removing duplicates
正在執行一個SELECT DISTINCT方式的查詢，但是MySQL無法在前一個階段優化掉那些重復的記錄。因此，MySQL需要再次去掉重復的記錄，然后再把結果發送給客戶端。
Reopen table
獲得了對一個表的鎖，但是必須在表結構修改之后才能獲得這個鎖。已經釋放鎖，關閉數據表，正嘗試重新打開數據表。
Repair by sorting
修復指令正在排序以創建索引。
Repair with keycache
修復指令正在利用索引緩存一個一個地創建新索引。它會比Repair by sorting慢些。
Searching rows for update
正在講符合條件的記錄找出來以備更新。它必須在UPDATE要修改相關的記錄之前就完成了。
Sleeping
正在等待客戶端發送新請求.
System lock
正在等待取得一個外部的系統鎖。如果當前沒有運行多個mysqld服務器同時請求同一個表，那么可以通過增加--skip-external-locking參數來禁止外部系統鎖。
Upgrading lock
INSERT DELAYED正在嘗試取得一個鎖表以插入新記錄。
Updating
正在搜索匹配的記錄，並且修改它們。
User Lock
正在等待GET_LOCK()。
Waiting for tables
該線程得到通知，數據表結構已經被修改了，需要重新打開數據表以取得新的結構。然后，為了能的重新打開數據表，必須等到所有其他線程關閉這個表。以下幾種情況下會產生這個通知：FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE,或OPTIMIZE TABLE。
waiting for handler insert
INSERT DELAYED已經處理完了所有待處理的插入操作，正在等待新的請求。
大部分狀態對應很快的操作，只要有一個線程保持同一個狀態好幾秒鍾，那么可能是有問題發生了，需要檢查一下。
還有其他的狀態沒在上面中列出來，不過它們大部分只是在查看服務器是否有存在錯誤是才用得着。
mysql 查看當前連接數
命令： show processlist;
如果是root帳號，你能看到所有用戶的當前連接。如果是其它普通帳號，只能看到自己占用的連接。
show processlist;只列出前100條，如果想全列出請使用show full processlist;
mysql> show processlist;
命令： show status;
執行狀態分析
Sleep狀態
通常代表資源未釋放，如果是通過連接池，sleep狀態應該恆定在一定數量范圍內
實戰范例：因前端數據輸出時（特別是輸出到用戶終端）未及時關閉數據庫連接，導致因網絡連接速度產生大量sleep連接，在網速出現異常時，數據庫too many connections掛死。
簡單解讀，數據查詢和執行通常只需要不到0.01秒，而網絡輸出通常需要1秒左右甚至更長，原本數據連接在0.01秒即可釋放，但是因為前端程序未執行close操作，直接輸出結果，那么在結果未展現在用戶桌面前，該數據庫連接一直維持在sleep狀態！
Waiting for net, reading from net, writing to net
偶爾出現無妨
如大量出現，迅速檢查數據庫到前端的網絡連接狀態和流量
案例:因外掛程序，內網數據庫大量讀取，內網使用的百兆交換迅速爆滿，導致大量連接阻塞在waiting for net，數據庫連接過多崩潰
Locked狀態
有更新操作鎖定
通常使用innodb可以很好的減少locked狀態的產生，但是切記，更新操作要正確使用索引，即便是低頻次更新操作也不能疏忽。如上影響結果集范例所示。
在myisam的時代，locked是很多高並發應用的噩夢。所以mysql官方也開始傾向於推薦innodb。
Copy to tmp table
索引及現有結構無法涵蓋查詢條件，才會建立一個臨時表來滿足查詢要求，產生巨大的恐怖的i/o壓力。
很可怕的搜索語句會導致這樣的情況，如果是數據分析，或者半夜的周期數據清理任務，偶爾出現，可以允許。頻繁出現務必優化之。
Copy to tmp table通常與連表查詢有關，建議逐漸習慣不使用連表查詢。
實戰范例：
u 某社區數據庫阻塞，求救，經查，其服務器存在多個數據庫應用和網站，其中一個不常用的小網站數據庫產生了一個恐怖的copy to tmp table操作，導致整個硬盤i/o和cpu壓力超載。Kill掉該操作一切恢復。
Sending data
Sending data並不是發送數據，別被這個名字所欺騙，這是從物理磁盤獲取數據的進程，如果你的影響結果集較多，那么就需要從不同的磁盤碎片去抽取數據，
偶爾出現該狀態連接無礙。
回到上面影響結果集的問題，一般而言，如果sending data連接過多，通常是某查詢的影響結果集過大，也就是查詢的索引項不夠優化。
如果出現大量相似的SQL語句出現在show proesslist列表中，並且都處於sending data狀態，優化查詢索引，記住用影響結果集的思路去思考。
Storing result to query cache
出現這種狀態，如果頻繁出現，使用set profiling分析，如果存在資源開銷在SQL整體開銷的比例過大（即便是非常小的開銷，看比例），則說明query cache碎片較多
使用flush query cache可即時清理，也可以做成定時任務
Query cache參數可適當酌情設置。
Freeing items
理論上這玩意不會出現很多。偶爾出現無礙
如果大量出現，內存，硬盤可能已經出現問題。比如硬盤滿或損壞。
i/o壓力過大時，也可能出現Free items執行時間較長的情況。
Sorting for …
和Sending data類似，結果集過大，排序條件沒有索引化，需要在內存里排序，甚至需要創建臨時結構排序。
其他
還有很多狀態，遇到了，去查查資料。基本上我們遇到其他狀態的阻塞較少，所以不關心.