navicat 16中创建联合索引需右键表→设计表→索引页→点“新增”→手动逐列添加字段并设置asc/desc顺序，确保与where/order by最左前缀严格一致，类型选btree（mysql/postgresql默认），避免仅勾选字段而忽略顺序与排序方式。
navicat 16里怎么在设计表界面创建索引
直接右键目标表 → 选“设计表” → 切到“索引”选项卡 → 点“新增”就能开建。关键不是能不能点，而是字段顺序和索引类型得对得上查询条件。
-
WHERE a = ? AND b > ? ORDER BY c这类查询，idx_a_b_c是有效复合索引；但只建idx_b_c或idx_a_c就大概率被忽略 - MySQL 默认用
BTREE，PostgreSQL 也默认b-tree，除非你明确要做等值查且不用范围查询，否则别选HASH -
TEXT字段加索引必须指定前缀长度，比如content(255)，否则 Navicat 会报错或静默失败 - 唯一约束别全靠
UNIQUE索引顶替：主键缺失时，UNIQUE能防重，但无法替代PRIMARY KEY的聚簇特性
执行计划里 key 为空，但 possible_keys 有值，说明什么
说明优化器“看见了”索引，但没用——常见原因不是 Navicat 没建好，而是索引字段顺序不匹配 WHERE 条件的最左前缀。
- 比如建了
idx_status_created_at（status 在前），但查询是WHERE created_at > '2025-01-01'，那这个索引根本不会被选中 - 函数包裹也会让索引失效：
WHERE DATE(create_time) = '2025-04-01'不走索引，得改成create_time >= '2025-04-01' AND create_time - 类型隐式转换同样危险：
user_id是INT，但写成WHERE user_id = '123'（字符串），MySQL 可能放弃索引做全表扫描 - Navicat 的“解释”功能弹出的执行计划里，如果
type是ALL、key是空、rows接近表总行数，基本就是上述某条踩中了
Navicat 的索引分析报告到底怎么看
它不生成“该建什么索引”的结论，而是把现有索引结构+查询模式摊开给你看。重点盯三处：
- “索引字段顺序”列：对照你的高频
WHERE条件，确认最左字段是否覆盖第一个过滤条件 - “选择性”提示（如果有）：低选择性字段（如
status只有 0/1 两个值）单独建索引意义不大 - “未使用索引”统计（需开启 performance_schema 或慢日志）：Navicat 本身不自动统计，但你可以导出慢 SQL 后手动比对
SHOW INDEX FROM table_name和EXPLAIN结果 - 注意 Navicat 16 对 PostgreSQL 的索引方法支持更细，比如
gist或gin索引在“索引方法”下拉里可选，但 MySQL 就只有BTREE和HASH
建完索引查询还是慢？先检查这三件事
索引不是银弹，建了不等于生效，生效了也不等于快。
- 表数据量太小（比如几千行），全表扫描可能比走索引还快，优化器会主动放弃
-
ANALYZE TABLE没跑过：统计信息过期会导致执行计划误判，尤其在大批量 INSERT/DELETE 后 - 索引字段上有
NULL值且查询条件含IS NULL：BTree 索引对NULL的处理因引擎而异，MySQL InnoDB 会存，但某些场景下仍不走索引 - Navicat 执行
EXPLAIN时用的是当前连接的 session 设置，如果开了sql_mode=STRICT_TRANS_TABLES或字符集不一致，也可能干扰优化器决策
真正容易被忽略的，是索引维护成本本身——每多一个索引，INSERT/UPDATE/DELETE 都要同步更新它。业务写多读少的表，盲目加索引反而拖慢整体吞吐。
