MySQL中運行速度慢的查詢

我最近遇到了一個查詢，這個查詢從過去幾天開始非常耗時。我們上個月爲MySQL數據庫進行了服務器遷移，並且在以前的服務器上從未發生過這個問題。舊版服務器上的MySQL版本是5.1.34，目前版本是5.1.58（不知道這個問題是否與這個問題有關）。MySQL中運行速度慢的查詢

查詢是如下：

SELECT table_name, 
     partition_name, 
     subpartition_name, 
     partition_method, 
     subpartition_method, 
     partition_expression, 
     subpartition_expression, 
     partition_description, 
     partition_comment, 
     nodegroup, 
     tablespace_name 
FROM information_schema.partitions 
WHERE table_schema LIKE 'wialogdb' 
     AND NOT Isnull(partition_name) 
     AND table_name LIKE 'freemail' 
ORDER BY table_name, 
      partition_name, 
      partition_ordinal_position, 
      subpartition_ordinal_position;

這是對的Navicat發射，以獲取有關表結構的細節information_schema.PARTITIONS 查詢，這是非常difucult重現。

當你編輯表的Navicat已收集abotu從信息架構表中的所有細節（如發動機，表列的lsit，請參閱分析顯示創建表等）和分區是它具有表的一個

檢查你可以看到WHERE條件不是「正確的」WHERE TABLE_SCHEMA LIKE'wialogdb'它不應該是LIKE它應該是WHERE TABLE_SCHEMA ='wialogdb'，這個查詢要快得多，但它是Navicat的內部代碼我們可以不改變它。我們以前沒有這個問題（舊的MySQL 5.1.34）

任何幫助將不勝感激。

在此先感謝。

來源

2013-05-03 dave005

我認爲這是DBA StackExchange站點的一個問題，所以我已經將其標記爲在那裏移動，但是表的索引是？我會從看這個開始。如果我記得正確的話，當你遷移MySQL數據庫時，你會失去索引，所以你可能已經從索引良好的數據庫變成沒有索引的數據庫了。 – JMK 2013-05-03 11:43:55

需要多長時間？ MySQL似乎沒有對information_schema表進行索引，因此，即使查詢日誌實際上運行速度相當快，查詢可能會停留在慢查詢日誌上 - 這取決於慢查詢日誌的設置（即，它是否僅記錄查詢超過1秒，或者還記錄未索引的查詢） – Kickstart 2013-05-03 12:39:35

也瀏覽我發現此頁 - http://www.mysqlperformanceblog.com/2011/12/23/solving-information_schema-slowness/。它提到了一個設置，可以在檢查信息模式時引起緩慢的查詢。可能的值innodb_stats_on_metadata設置已在您的2個mysql安裝之間更改。 – Kickstart 2013-05-03 12:45:56

如果不是您的軟件，請不要嘗試修復它。讓創作者知道你有性能問題，並且你找到了可以提高性能的東西。

爲什麼人們購買軟件許可證是有原因的：使用支持。

來源

2013-05-03 11:43:35 Stefan

我們無法回到軟件支持的原因是，同一個查詢在遷移之前用得很好，所以他們會說這與遷移有關，而不是軟件的內部代碼。 – dave005 2013-05-05 07:26:29

@ dave005你總是可以問你應該採取哪些步驟進行遷移，也許他們能夠幫助你。 – Stefan 2013-05-05 18:52:57

MySQL中運行速度慢的查詢

回答

相關問題