轉載至：https://www.yuque.com/yinjianwei/vyrvkf/yh2y71

通過下面這條 SQL 語句來檢視建立的索引，大部分情況下可以定位出 90% 的索引建立不合理情況：

SELECT 
  t.TABLE_SCHEMA,
  t.TABLE_NAME,
  INDEX_NAME,
  CARDINALITY,
  TABLE_ROWS,
  CARDINALITY / TABLE_ROWS AS SELECTIVITY 
FROM
  information_schema.TABLES t,
  (SELECT 
    table_schema,
    table_name,
    index_name,
    cardinality 
  FROM
    information_schema.STATISTICS 
  WHERE (
      table_schema,
      table_name,
      index_name,
      seq_in_index
    ) IN 
    (SELECT 
      table_schema,
      table_name,
      index_name,
      MAX(seq_in_index) 
    FROM
      information_schema.STATISTICS 
    GROUP BY table_schema,
      table_name,
      index_name)) s 
WHERE t.table_schema = s.table_schema 
  AND t.table_name = s.table_name 
  AND t.table_rows != 0 
  AND t.table_schema NOT IN (
    'mysql',
    'performance_schema',
    'information_schema'
  ) 
ORDER BY SELECTIVITY ;

上述的 SQL 語句利用了 information_schema 資料庫下的元資料表 TABLES、STATISTICS。

• 表 TABLES 記錄了表的基本資訊，例如庫名，表名，行數等。
• 表 STATISTICS 記錄了各個索引的 CARDINALITY 值。

• 那麼 CARDINALITY / TABLE_ROWS 表示的就是索引的選擇性。

在 Inside 君的《MySQL技術內幕：InnoDB儲存引擎》一書中明確指出的是，在 OLTP 的應用場景下，建立的索引是要求高選擇性的。

若 CARDINALITY / TABLE_ROWS 小於10%（經驗值），那麼表示資料重複率較高，通常需要考慮是否有必要建立該索引。該語句執行的結果如下所示，列 SELECTIVITY 表示的就是選擇性：

上述 SQL 語句並不能工作在 MySQL 5.6 版本下（即使最新的 MySQL 5.6.28 版本），因為目前 5.6 的 STATISTICS 表中關於 Cardinality 的統計是錯誤的。具體可見 MySQL bugs #78066。但是，表 innodb_index_stats 中關於 Cardinality 值得統計依然是正確的。