mysql - EXPLAIN SELECT 显示 MySQL 没有使用我的索引

Question

表定义，注意UNIQUE索引:

CREATE TABLE meta
(
  id INT UNSIGNED AUTO_INCREMENT PRIMARY KEY,
  type SET('tag', 'keyword') NOT NULL,
  name VARCHAR(255) NOT NULL,
  user_id INT UNSIGNED NOT NULL,
  UNIQUE (name, type, user_id),
  FOREIGN KEY (user_id) REFERENCES user (id) ON DELETE CASCADE
);

因此 MySQL 应该在搜索中使用索引，例如 WHERE name = 'tag' and type = 'cat' 以及仅(最左边的前缀)WHERE type = 'tag'.

我做到了:

EXPLAIN SELECT * FROM meta WHERE type = 'tag'

结果是(第五列是possible_keys):

'1', 'SIMPLE', 'meta', 'ALL', NULL, NULL, NULL, NULL, '1', 'Using where'

我确定我遗漏了什么，但找不到什么。有什么线索吗？

Answer 1

这种类型的解释可能已经存在过很多次了......但是试图解释为什么数据库引擎通常不会在所描述的情况下使用索引(当 WHERE 子句在多列中只有第二个字段时索引)，一个简单的类比可能会有所帮助。

您可以将实体电话簿(一种用纸制成的老式电话簿)视为一种索引。索引键是姓名，数据是电话号码。电话簿索引的基本格式为“Lastname, Firstname”。如果您在电话簿中查找姓名(例如，Mark Wilkins)，您正在寻找键“Wilkins,Mark”。您也可以通过姓氏轻松查找姓名，并找到给定姓氏的所有条目。

但是，在电话簿“索引”中搜索Firstname 并不是那么容易。如果你想找到电话簿中带有Firstname=Mark 的所有条目，你必须扫描整个电话簿。使用标准索引(例如，类似 b 树的索引)，数据库引擎也有完全相同的问题。如果 WHERE 子句仅包含双列索引的第二列，则它必须扫描整个索引才能找到匹配项。一些数据库引擎可能仍然这样做，但简单地扫描表本身可能会更快，因为它通常必须为结果集读取表中的数据。