8.1、哪怕是基于索引的條件過濾，如果優化器意識到總共需要掃描的數據量超過30%時（ORACLE里貌似是20%，MySQL目前是30%，沒準以后會調整），就會直接改變執行計劃為全表掃描，不再使用索引。 8.2、多表JOIN時，要把過濾性最大（不一定是數據量最小哦，而是只加了WHERE條件后過濾性最大的那個）的表選為驅動表。此外，如果JOIN之后有排序，排序字段一定要屬于驅動表，才能利用驅動表上的索引完成排序。 8.3、絕大多數情況下，排序的代價通常要來的更高，因此如果看到執行計劃中有 Using filesort，優先創建排序索引吧。 8.4、利用?[pt-query-digest](https://www.percona.com/doc/percona-toolkit/2.2/pt-query-digest.html)?定期分析slow query log，并結合?[Box Anemometer](https://github.com/box/Anemometer)?構建slow query log分析及優化系統。 【參考】：[[MySQL FAQ]系列 — EXPLAIN結果中哪些信息要引起關注](http://imysql.com/2015/06/14/mysql-faq-what-important-information-in-explain.shtml)。 備注：若無特別說明，以上規范建議適用于MySQL 5.6及之前的版本（并且主要是5.6版本，尤其是ICP特性、DATETIME變化這兩個地方）。5.7及之后的版本可能會有些變化，個別規范建議需要相應調整。