5
我試圖發現mysqld爲什麼有時飽和CPU和攤位。診斷和避免MySQL的CPU峯值
我懷疑它的東西做更新指標或其他這樣的維護。我想證明這個假設，並考慮避免它的選擇。
這是情況。我有幾十張桌子，但基於活動，似乎至少有兩個一直遭受這種情況。我們稱它們爲Big和Small。 Big包含大約6,000行總計1Mb（所以不是全部那麼大）和Small有幾十行，每個大約50字節。 Big有一個外鍵Small（InnoDB，刪除級聯，不爲空）。
有兩種情況似乎會觸發問題：a）修改Big.small_id值，或者b）向Small添加一行。
我會直覺地想到一個）是非常該死的快，O(log(size of Big))和b）是幾乎瞬間因爲Small是如此之小，沒有Big的引用，它已經改變。在每種情況下，隨後的SELECT都需要類似於二十個gigacycles（！）;那之後的那一刻完全沒有時間。還有其他的表都有這些表的外鍵，但都是相當小的，我認爲他們不負責這個高峯。
我如何可以找出哪些索引MySQL正在更新和各需要多長時間？
或者，如果沒有更新索引，我怎麼可以找出還有什麼是要花這麼長時間？
最後，我可以設置mysqld爲這項工作賦予低線程優先級，和/或臨時禁用索引以允許非索引（非阻塞）選擇與維護任務同時發生？
SHOW PROCESSLIST顯示，查詢是在「發送數據」狀態很長時間。這並不比描述更具描述性。我懷疑這是一個公平的標籤，因爲我在本地主機上，傳輸不應該是瓶頸。我從哪裏出發？謝謝 – spraff 2012-03-23 14:05:03