MySQL 慢查詢優化提示詞：慢查詢日誌分析 + 聯合索引設計（最左前綴、覆蓋索引、索引失效排查）
數據庫 CPU 高、接口變慢，手裏有慢查詢日誌或 pt-query-digest 的彙總時用：讓 AI 從一批慢查詢裏找出最值得優化的幾條，逐條看執行計劃，設計能覆蓋多條查詢的聯合索引，同時檢查索引失效的寫法和多餘的索引。
通用大模型 對話模型通用
你是一名 MySQL 性能優化專家。請幫我分析慢查詢並設計索引。 - MySQL 版本與存儲引擎：[如 MySQL 8.0 InnoDB] - 慢查詢日誌或彙總報告（可以是 pt-query-digest 的輸出，或若干條慢 SQL 及執行次數、平均耗時）： [粘貼慢查詢] - 相關表的建表語句（含現有索引）和大致行數： [粘貼建表語句] - 相關 SQL 的 EXPLAIN 結果（如果有）： [粘貼執行計劃] - 寫入頻率：[如訂單表每秒寫入 200 條] 分析步驟： 1. 排序：按「總耗時 = 平均耗時 × 執行次數」排出最值得優化的前 5 條，說明為什麼先優化它們（一條執行一萬次的 200 毫秒查詢，往往比一條每天執行一次的 10 秒查詢更值得優化）。 2. 逐條分析： - 讀執行計劃：訪問類型、使用的索引、掃描行數、是否出現文件排序或臨時表； - 指出慢的原因：沒有可用索引、索引選擇性差、索引失效、回表太多、深分頁、查詢了不需要的列。 3. 索引失效檢查：對索引列使用函數或運算、隱式類型轉換（如字符串字段和數字比較）、前導通配符的 LIKE、OR 連接了無索引的列、聯合索引不滿足最左前綴、範圍條件之後的列無法繼續使用索引。 4. 聯合索引設計： - 字段順序的依據：等值條件在前、範圍條件在後、兼顧排序和分組； - 能否做成覆蓋索引避免回表； - 盡量用一個索引覆蓋多條查詢，避免一條查詢建一個索引； - 檢查現有索引中被新索引覆蓋的冗餘索引，建議刪除。 5. 寫法優化：不改索引也能提升的地方，例如改寫深分頁、拆分 OR、避免查詢全部列。 6. 上線方案：給出建索引語句；說明大表加索引對線上的影響，在線變更的方式和執行時間段建議；上線後如何對比效果。 所有結論基於我提供的資訊，缺少執行計劃時說明「需要 EXPLAIN 結果確認」，不要編造掃描行數。
高亮處換成你自己的內容：[如 MySQL 8.0 InnoDB]、[粘貼慢查詢]、[粘貼建表語句]、[粘貼執行計劃]、[如訂單表每秒寫入 200 條]
ChatGPT Plus 充值
已被複製 0 次
使用說明
怎麼填變量：[相關表的建表語句] 必須包含現有索引，否則 AI 無法判斷冗餘索引，也可能建議一個已經存在的索引。[寫入頻率] 用來權衡索引數量：寫入很頻繁的表，每多一個索引都會拖慢寫入。
常見坑：
- 一條慢查詢建一個索引，幾個月後表上有十幾個索引，寫入越來越慢，優化器還經常選錯。設計索引要把同一張表上的多條查詢放在一起考慮。
WHERE DATE(create_time) = '2026-10-01'這類寫法會讓索引失效，要改成create_time >= '2026-10-01' AND create_time < '2026-10-02'。- 手機號字段是字符串類型，查詢時卻傳數字，會發生隱式轉換導致索引失效，這個問題在日誌裏很難看出來。
追問技巧：建完索引後，把新的 EXPLAIN 結果貼回去，問「這個執行計劃是否已經是最優，還有沒有回表或排序」。
示例輸出
示例，僅供參考（節選）
| 排名 | SQL 摘要 | 執行次數 / 天 | 平均耗時 | 主要原因 |
|---|---|---|---|---|
| 1 | 按用戶查最近訂單 | 120 萬 | 180 ms | 只有 user_id 單列索引，排序產生文件排序 |
| 2 | 按日期統計訂單 | 2 萬 | 1.2 s | 對 create_time 使用了 DATE() 函數，索引失效 |
sql
-- 覆蓋排名 1 的查詢：等值條件 user_id 在前，排序字段 create_time 在後
ALTER TABLE orders ADD INDEX idx_user_ctime (user_id, create_time);
-- 原有的 idx_user_id (user_id) 被新索引的最左前綴覆蓋，確認無其他依賴後可刪除改寫排名 2：
sql
SELECT COUNT(*) FROM orders
WHERE create_time >= '2026-10-01' AND create_time < '2026-10-02';同款作品
用這條提示詞做出來的作品；原作者會因此獲得積分
還沒有同款，來做第一個。
0 條評論
還沒有評論，來搶沙發～