Navicat不支持在线修改索引字段顺序，必须删除错误索引后重建；字段顺序须严格遵循最左前缀原则：等值字段（如user_id、status）置前，范围或排序字段（如created_at）置后，PostgreSQL中DESC需显式声明，TEXT字段加索引须指定前缀长度（如content(255)）。
Navicat 不支持在线修改索引字段顺序
建好的索引，字段顺序填错了，不能“编辑”或“调整”——Navicat 的索引设计器里没有“修改已有索引字段顺序”的功能。你看到的“双击索引→弹出字段列表→拖拽重排”，只是 UI 交互假象；点确定后，它不会生成 ALTER INDEX ... ALTER COLUMN 这类语句（MySQL 本身也不支持该语法），而是静默忽略顺序变更，或直接报错退出。
根本原因在于：MySQL 不提供原生的「重排索引字段」DDL 命令；PostgreSQL 虽支持 ALTER INDEX ... RENAME TO 或重建，但也不允许跳过重建直接调序。所以所有客户端（包括 Navicat）都只能走“删旧建新”路径。
正确做法：删除再重建，且必须按最左前缀原则排字段
别试图保存、刷新、重同步——唯一可靠操作是手动删掉错误索引，再新建一个字段顺序正确的。
- 右键索引 →「删除」→ 确认
- 右键表 →「设计表」→ 切到「索引」页 →「新增索引」
- 勾选字段后，**必须手动拖拽排序**（
Navicat允许在字段列表中拖拽，这步有效） - 等值条件字段（如
user_id、status）放最左；范围/排序字段（如created_at）放右侧；中间不能跳过 - PostgreSQL 用户注意：
ORDER BY created_at DESC查询，索引中必须显式写created_at DESC，否则会触发Using filesort
TEXT/VARCHAR 长字段加索引时容易失败
如果索引含 content 这类 TEXT 或超长 VARCHAR 字段，不指定前缀长度，Navicat 会卡住、无响应，或看似创建成功但 EXPLAIN 显示未被使用。
必须在字段名后手动输入括号和数字，例如：
content(255)
不是勾选就完事。验证是否生效：
- 执行
SHOW INDEX FROM table_name，看Sub_part列是否为数字（非NULL） - 长度太短（如
content(10)）选择性差；太长（如content(1000)）可能超 MySQL 单索引键长限制（InnoDB 默认 767 字节）
为什么 EXPLAIN 里 possible_keys 有值但 key 为空
这说明优化器“看见”了索引，但拒绝使用——不是 Navicat 没建好，而是索引和查询之间存在隐性断层。常见原因：
- WHERE 条件没覆盖索引最左字段（比如索引是
(a,b,c)，但查询只用了b = ?） - 对索引字段用了函数或表达式（如
WHERE YEAR(created_at) = 2024） - 字符集或排序规则不一致（如列是
utf8mb4_bin，但查询参数是utf8mb4_general_ci） - 统计信息过期，执行
ANALYZE TABLE table_name再试
字段顺序错是最隐蔽也最常见的原因——它不报错，但让整个索引失效，且很难一眼发现。
