字段顺序填反需删除重建，因Navicat不支持在线调整；必须按最左前缀匹配原则排序：等值字段（如user_id、status）置前，范围或排序字段（如created_at）置后，且PostgreSQL中DESC需显式声明，TEXT字段加索引须指定前缀长度（如content(255)）。
Navicat索引设计器里字段顺序填反了怎么办
建完索引查询没变快，甚至执行计划里 key 为空、type 是 all，大概率是字段顺序错了。比如高频查询是 where user_id = ? and status = 'paid' order by created_at desc，但你在索引设计器里把 status 放在最前面——这个索引对这个查询完全无效。
必须严格按“最左前缀匹配”来排：user_id（等值）→ status（等值）→ created_at（范围或排序）。中间不能跳过，也不能颠倒。
- Navicat 的“索引”页里新增索引时，字段列表是可拖拽排序的，别只管勾选，要手动调序
- 如果已建错，直接删掉重来，不要试图“修改”字段顺序——Navicat 不支持在线调整索引字段顺序
- PostgreSQL 用户注意：
DESC在索引定义中需显式写明，MySQL 则默认 ASC，ORDER BY created_at DESC要对应建created_at DESC才能避免Using filesort
TEXT 字段加索引总报错或静默失败
在 Navicat 索引设计器里给 content 这类 TEXT 或 VARCHAR(2000) 字段加索引，不指定长度就会失败。MySQL 要求前缀索引，PostgreSQL 对长字段也有限制。
错误现象包括：点“确定”没反应、弹窗提示“Invalid index length”、或者看似成功但后续 EXPLAIN 显示该索引完全不被使用。
- 必须在字段名后手动输入括号和长度，例如
content(255)，不是选中字段就完事 - 长度不是随便估的：太短（如
content(10)）选择性差，几乎没用；太长（如content(1000)）可能超 MySQL 单索引键长度限制（767 字节 InnoDB 默认） - 验证是否生效：执行
SHOW INDEX FROM table_name，看Sub_part列是否为实际数字，不是NULL
Navicat “解释”功能里 possible_keys 有值但 key 为空
这说明优化器“看到”了索引，但拒绝使用——不是 Navicat 没建好，而是索引和查询之间存在隐性断层。
常见断层点：
-
WHERE DATE(create_time) = '2026-07-27'：函数包裹直接让索引失效，得改成create_time >= '2026-07-27' AND create_time -
WHERE user_id = '123'：字段是INT，传字符串会触发隐式转换，MySQL 可能放弃索引 - 索引字段类型和查询条件类型不一致，比如
CHAR字段建了索引，但查询用LIKE '%abc'，最左前缀失效 - 统计信息过期：大表数据批量更新后没运行
ANALYZE TABLE table_name，优化器误判索引效率
联合索引建多了反而拖慢写入
索引不是越多越好。每多一个索引，INSERT/UPDATE/DELETE 就得多维护一份 B+ 树结构，尤其对日均百万级写入的大表，这点开销很真实。
Navicat 的“索引”页能一眼看清当前所有索引，但容易忽略它们的实际负载。
- 先查
information_schema.STATISTICS或用 Navicat 导出慢日志，确认哪些索引真被SELECT用到（key列非空）、哪些长期possible_keys从不变成key - 删除无用索引用
DROP INDEX idx_name ON table_name，Navicat 里右键索引 → “删除” 也可，但建议先在测试库验证 - 对写多读少的表（如用户行为日志），优先考虑分区（Navicat 支持按日期自动分区），而不是堆索引
EXPLAIN 和慢日志交叉验证——尤其当表超过百万行，微小的顺序偏差或类型不匹配，就会让索引彻底失效。
