distinct慢的根本原因是未走索引导致全表扫描，需用explain查看type（all即全表扫描）和rows（接近总行数则未优化），且必须为distinct列创建最左前缀覆盖的复合索引。
为什么distinct慢得离谱？先看执行计划
绝大多数 distinct 性能问题，根本不是语法写错了，而是数据库没走索引、被迫全表扫描。navicat 本身不执行优化，它只是把你的 sql 交给 mysql/postgresql 执行——所以瓶颈一定在服务端。直接在 navicat 查询窗口里运行 explain select distinct column from table，重点看 type 和 rows 字段：type 是 all 就说明在扫全表；rows 数值接近表总行数，基本等于没优化。
哪些列加索引才真正生效？
DISTINCT 能用上索引，有严格前提：索引必须「最左前缀覆盖」SELECT 列。比如你写 SELECT DISTINCT city, country FROM customers，那只有 (city, country) 的联合索引才有效；单列 city 索引或 country 索引都无效。Navicat 的「表结构设计页」里可以右键「索引」→「新建索引」，但注意：KEY 名字不重要，字段顺序和是否包含所有 DISTINCT 列才关键。
- 如果只查单列（如
SELECT DISTINCT user_id），给该列建普通索引即可 - 如果查多列（如
SELECT DISTINCT province, city），必须建(province, city)联合索引，反过来不行 - 含
WHERE条件时，要把过滤列放在联合索引最前面，比如WHERE status = 'active' AND SELECT DISTINCT name，索引应为(status, name)
ORDER BY + DISTINCT 组合最容易翻车
很多人加了 ORDER BY 想让去重结果有序，但 MySQL 在 8.0 之前会强制使用临时表 + 文件排序，哪怕你加了索引也没用。现象是 EXPLAIN 中出现 Using temporary; Using filesort。解决办法只有两个：
一是改用子查询先去重再排序：SELECT * FROM (SELECT DISTINCT city FROM customers) t ORDER BY city；
二是确保排序字段也在 DISTINCT 列中且索引覆盖完整——比如 SELECT DISTINCT city FROM customers ORDER BY city，只要 city 有索引，就能避免临时表。
别信 Navicat 的「执行时间」面板
Navicat 底部状态栏显示的「Query took X.XXX sec」只包含网络传输和客户端解析耗时，不反映真实服务端执行压力。真正要判断性能，必须结合：
• SET STATISTICS IO ON（SQL Server）或 EXPLAIN ANALYZE（PostgreSQL）看物理读取次数
• MySQL 下用 SHOW PROFILE 查 CPU 和 Block IO 分布
• Navicat「工具」→「服务器监控」里看实时连接数、慢查询日志开关是否打开
尤其注意：如果 DISTINCT 结果集很大（比如百万级唯一值），即使索引有效，内存排序和网络传输也会拖慢整体响应——这时要考虑分页或前端缓存，而不是硬扛。
