狀態為“複製到 tmp 表”中的語句會破壞性能

在一個

• MySQL 數據庫（版本 5.1.73）
• Magento 商店

執行使用 distinct 的語句 (A)，請參閱

http://pastebin.com/A2sy45nF

因此根據“解釋”是“使用臨時”。

在某些負載條件下（當涉及的表被更新並且記憶體的查詢變得無效時）語句在“複製到 tmp 表”狀態下等待，例如 24 個客戶端會發生這種情況，請參閱

http://www.directupload.net/file/d/3809/8xqjqk4p_png.htm

已檢查 MySQL 為語句 (A) 創建的內部 tmp 表確實計為 Created_tmp_tables 而不是 Created_tmp_disk_tables。這與執行緒處於“Copying to tmp table”狀態的事實是一致的。

觀察使我得出這樣的假設：

innodb 或整個數據庫的記憶體不足會阻止創建 tmp 表，這會導致系統崩潰。

問題：

• 我們如何證明或拒絕這個假設？
• 數據庫配置中有哪些有希望的變化以防止崩潰？

這個問題可能與

查詢定期陷入“複製到 tmp 表”狀態，永遠不會完成，

但有

• 不同的上下文（Magento 與 WordPress）
• 和其他方面（查詢的幾個實例）。

最誠摯的問候，

安德魯

現在應用程序再次穩定。

作為第一步，innodb_thread_concurrency 減少了 2 * 核心數。這似乎稍微減少了問題。

但最終 Magento-Shop 發布的聲明已被更簡單的聲明取代，該聲明足以滿足混凝土商店的特殊情況。商店僅使用一個屬性集，因此結果獨立於 catalog_product_entity 表。修改後的語句現在非常簡單，結果總是可以從查詢記憶體中獲取。

最誠摯的問候，

安德魯

引用自：https://dba.stackexchange.com/questions/82833