升級後出現在慢查詢日誌中的mysqldump選擇查詢
我們最近從 MariaDB 5.5 升級到 MariaDB 10.5
select由於這樣做，當我們使用 mysqldump 備份數據庫時，我們在慢查詢日誌中出現了幾個查詢。其中一張表是具有 125,000 條記錄的 InnoDB 表。另一個是包含 220,000 條記錄的 MyISAM 表。
我想這似乎不是什麼大問題，但是多年來我們在慢查詢日誌中從未有任何與 mysqldump 相關的內容。所以我想知道我們是否應該擔心？mysqldump 的行為是否在 5.5 和 10.5 版本之間發生了變化，或者是否存在我們之前可能已經優化的其他本地設置，但現在不是？
我們的慢查詢時間設置為 5 秒，這是之前的設置。有問題的查詢只需要不到 6 秒的時間。
謝謝
編輯
經過進一步調查，事實證明我們正在通過 gzip 管道 mysqldump，以壓縮生成的轉儲文件。從等式中刪除 gzip 會導致每個轉儲在 3 秒或更短的時間內完成。
事實上，除了從 MariaDB 5 升級到 10 之外，我們的設置保持不變，這在以前似乎不是問題。
在任何情況下，雖然管道到 gzip 會產生一個很好的“一個襯裡”，但我已將其更改為將文件轉儲為純文字，然後再將它們 gzip。知道轉儲查詢完成得更快，並且不受 gzip 阻礙，我感覺更好。
預設情況下，MariaDB 的 mysqldump 將在執行轉儲重新載入時將查詢（預設啟用–log-queries）記錄到慢日誌。MariaDB 文件說：
恢復轉儲時，如果打開了日誌記錄，伺服器會將查詢記錄到一般查詢日誌和慢查詢日誌中。預設為開；使用 –skip-log-queries 禁用。在 MariaDB 10.1.1 中添加。
這是在 MariaDB 10.1.1 中引入的。您可以嘗試
skip-log-queries作為 mysqldump 的一個選項。這可能會或可能不會影響轉儲過程本身。
如果您在慢速日誌中看到來自 mysqldump 的 SELECT，則被轉儲的表可能正在等待釋放鎖（在 MyISAM 表的情況下）或具有大量事務活動的表（在 InnoDB 的情況下）生成
INSERT INTO數千行時。建議
您可以通過增加本地會話的 long_query_time 來初始化重新載入會話以忽略慢查詢日誌：
mysql --init-command="SET long_query_time = 10000000;" < dump-file.sql