慢日誌的效能問題
造成 i/o 和 cpu 資源消耗：慢日誌通常會掃瞄大量非目的的資料，自然就會造成 i/o 和 cpu 的資源消耗，影響到其他業務的正常使用，有可能因為單個慢 sql 就能拖慢整個資料庫的效能，而且這種慢 sql，在實際業務場景下，通常都是程式發起數個 sql 請求，通過 show processlist 命令可以捕捉到同時有 n 個類似的 sql 請求在執行。
鎖等待消耗：由於慢 sql(select 查詢)會阻塞 mdl 鎖的獲取，所以針對 xtrabackup 全量備份和針對表的 ddl 操作都有可能被阻塞，一旦 ddl 被阻塞，針對表的請求就會變成序列阻塞，後續業務也就無法執行。
鎖申請消耗：對於非 select 查詢的慢事務， sql 還會把持鎖不釋放，讓後續事務無法申請到鎖，造成等待失敗，對業務本身來講是不可以接受的。
怎麼收集慢日誌？
elk 體系分析慢日誌
percona 分析慢日誌
percona 的 pt-query-digest 是一款可以針對 mysql 慢日誌進行定製化分析的工具
你需要了解的優化基礎
優化慢日誌的思路是「收集——分析——優化——預防」
優化 sql 的基礎手段是 explain，我們要在此基礎上，針對 sql 語句定點優化消除。
explain 基本語法是 explain + sql，我們需要針對 explain 進行解讀：
新增索引優化慢日誌
在索引新增時，你需要注意以下幾點情況：
除此之外，針對多表聯查的 sql 我也提供給你幾點建議：
要知道優化的目標是盡可能減少 join 中 nested loop 的迴圈次數，從而保證「永遠用小結果集驅動大結果集（這一點很重要）」。a join b，其中，a為驅動，a 中每一行和 b 進行迴圈join，看是否滿足條件，所以當 a 為小結果集時，越快，那麼：
最後，索引新增你也需要注意這樣兩點：
通過拆分冷熱資料優化慢日誌
你可能對「通過拆分冷熱資料優化慢日誌的方案」感到陌生，但實際來說，這個方案非常實用，尤其適合「超大表暫時無法新增有效索引的情況」，超大表是因為歷史資料不斷插入形成的，後面業務需要查詢某些特定條件，而這些特定條件區分度又比較低，即便新增索引效率也不會提公升太大。
比如 a 系統只需要近一年的資料，但是這個掃瞄條件沒辦法新增合適的索引，所以將之前的資料進行歸檔，在某些特定的條件下，能有效地減少掃瞄行數，大大加快 sql 語句的執行時間。
通過讀寫分離進行優化
當主庫的負載增多，我們有必要做讀寫分離：將定時的慢日誌剝離出主庫，轉而查詢沒有提供服務的從庫，從另乙個角度降低了慢日誌對於主資料庫的影響，現階段比較成熟的資料庫讀寫分離方案大概有 3 種。
提公升硬體水平
提公升伺服器配置能有效減少慢日誌的生成量，尤其是針對 pcie-ssd 的磁碟裝置使用，非常優秀，但是使用成本也會隨之增加。
這點非常重要，是一切的基礎。簡單來說，就是針對每個庫都要有乙個相應的負責人，如果乙個庫存在多個人呼叫的情況下(核心庫)就需要包含多個負責人。
通過第一步建立的負責人對應機制，然後通過程式/指令碼過濾指定的庫的 top n 慢 sql，按照一定時期傳送給相應的研發負責人，讓他們進行跟蹤優化（定時期可以是一天、一周或者半個月，按照機制進行即可）。
dba 根據慢日誌建立追蹤機制表，比如，記錄每個慢 sql 的優化進度、是否可以優化、最終期限……
優化 sql 本身就是事後救火，那麼只有建立長期有效的機制才是王道
MySQL優化 慢查詢日誌
mysql的慢查詢日誌是mysql提供的一種日誌記錄，它用來記錄在mysql中響應時間超過閥值的語句，具體指執行時間超過long query time值的sql，則會被記錄到慢查詢日誌中。當然，如果不是調優需要的話，一般不建議啟動該引數，因為開啟慢查詢日誌會或多或少帶來一定的效能影響。開啟了慢查詢日...
MySQL優化篇 慢查詢日誌
mysql的慢查詢日誌是mysql提供的一種日誌記錄，他用來記錄在mysql中響應時間超過閾值的語句，具體指執行時間超過long query time值的sql，則會被記錄到慢查詢日誌中。具體指執行時間超過long query time值的sql，則會被記錄到慢查詢日誌中。long query ti...
mysql開啟慢查詢日誌 MySQL慢日誌體系建設
慢查詢日誌是mysql提供的一種日誌記錄，用來記錄在mysql中響應時間超過閾值的sql語句，在很大程度上會影響資料庫整體的效能，是mysql優化的乙個重要方向。在58的雲db平台建設中，慢sql系統作為乙個非常重要功能模組，不僅是dba日常運維使用，我們也希望通過該功能可以協助開發人員更快速定位業...