DISTINCT多列查询慢的根本原因是MySQL默认需排序和建临时表，而非去重逻辑复杂；必须依赖覆盖索引（列顺序严格匹配）才能跳过filesort和temporary，直接从B+树叶子节点读取唯一值。
DISTINCT 多列查询慢，根本原因不是“去重逻辑复杂”，而是 MySQL 默认要排序+建临时表
MySQL 的 DISTINCT 不是靠哈希表一次性扫一遍就完事的。它底层基本等价于 GROUP BY，会触发排序（Using filesort）和/或内存/磁盘临时表（Using temporary）。数据量一大，没索引支撑，这两步立刻变成 I/O 和 CPU 瓶颈。
为什么 DISTINCT 必须走索引才能快？
有合适索引时，MySQL 可以直接从 B+ 树叶子节点顺序读取唯一值，跳过排序和临时表——前提是索引覆盖所有 DISTINCT 列，且顺序匹配。
MySQL8 CRM Schema Design Expert
下载
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 单列
DISTINCT col1：只要col1上有普通索引或主键，EXPLAIN中通常能看到type: index+Extra: Using index - 多列
DISTINCT col1, col2, col3：必须建复合索引INDEX(col1, col2, col3)，且查询列顺序与索引定义完全一致；否则优化器大概率放弃使用索引 - 如果只查
DISTINCT col1, col2却建了INDEX(col2, col1)，MySQL 通常不会用——B+ 树按左前缀有序，col1不在最左，无法保证顺序遍历去重
DISTINCT 查询不走索引的典型现象
执行 EXPLAIN SELECT DISTINCT col1, col2 FROM t 后，看到这些信号基本可以确认没走索引：
-
type: ALL：全表扫描，毫无悬念 -
Extra: Using temporary; Using filesort：说明正在内存或磁盘建临时表并排序，性能已亮红灯 -
key: NULL：明确告诉你没用任何索引 - 即使
col1有索引，但查询是DISTINCT col1, col2且col2没被包含在索引里，InnoDB 仍可能放弃该索引（尤其当选择性低、重复值多时）
覆盖索引对 DISTINCT 的实际价值
覆盖索引不是“锦上添花”，而是让 DISTINCT 能绕过聚簇索引回表的关键。只要索引里包含了所有 DISTINCT 的列，MySQL 就能纯靠索引树完成去重，不用碰一行真实数据。
- 建
INDEX idx_dept_salary ON employees(department, salary)后，SELECT DISTINCT department, salary FROM employees就能全程走索引 - 但如果加了
ORDER BY或LIMIT，情况会变复杂：比如SELECT DISTINCT department FROM employees ORDER BY department，有索引可加速；但换成ORDER BY name，索引就失效了 - 注意：
MEMORY引擎的 HASH 索引对DISTINCT几乎无用，因为它不支持范围扫描和排序——而DISTINCT依赖有序遍历
真正容易被忽略的是：索引列顺序必须严格匹配查询字段顺序，且不能有“中间断层”。比如想优化 DISTINCT a, b, c，建 (a, c) 是无效的，哪怕 b 是主键也不行——因为缺失 b，索引无法保证 (a,b,c) 组合的全局唯一顺序。
