索引问题分三类：缺失（show index为空）、存在但不用（需analyze table更新统计信息）、静默失效（权限/引擎/字符集导致）。须人工补建、验证执行计划并检查上下文。
查索引是否存在：用 show index from table_name 看输出是否为空
还原或迁移后查询变慢，第一反应不是“索引坏了”，而是先确认它还在不在。执行 show index from users，如果结果集为空，或者只有 key_name: primary 一行，说明索引压根没建——不是失效，是缺失。常见原因包括：
• navicat 还原时勾选了「仅数据」，漏掉「索引」对象类型
• 备份文件是 .nb3 或损坏的 .psc，本身不含 create index 语句
• 导出时用了 --skip-triggers --no-create-info 类参数，跳过了 ddl
别信 Navicat 的「快速修复表」：它对缺失索引完全无效
维护 → 快速修复表 只处理物理损坏（如 MyISAM 表页断裂、InnoDB 页校验失败），对“没建索引”这种逻辑缺失毫无作用。实测中，哪怕表结构完整但所有二级索引都丢失，该功能仍显示“成功”，实际 SHOW INDEX 仍是空的。遇到这种情况，必须人工补建：
• 手写 CREATE INDEX idx_order_status ON orders(status) USING BTREE，别依赖图形界面点选——它容易漏写 USING BTREE 或把列名大小写拼错
• 联合索引注意顺序：若常查 WHERE category = ? AND created_at > ?，索引必须是 (category, created_at)，反过来就无法命中最左前缀
索引“存在但不用”？先跑 ANALYZE TABLE table_name
执行 EXPLAIN SELECT * FROM logs WHERE level = 'ERROR' 发现 key 列为空、type 是 ALL，但 SHOW INDEX 明明有 idx_level——大概率是统计信息过期。MySQL 优化器靠行数估算决定走不走索引，而大表批量导入后不会自动更新统计。直接运行：
• ANALYZE TABLE logs（MySQL）
• 或 VACUUM ANALYZE logs（PostgreSQL）
之后再 EXPLAIN，key 往往立刻亮起。这个动作耗时短、无锁，上线前顺手加一句，能避开 70% 的“假失效”误判。
从 .psc 文件抢救索引：文本编辑器比 Navicat 更可靠
同事发来一个打不开的 backup.psc，Navicat 提示“文件已损坏”，但你急需里面几个关键索引定义。这时别反复点击「提取 SQL」——它一遇到头部损坏就直接退出。改用 VS Code 或 Notepad++ 以 UTF-8 编码打开该文件，滚动到底部附近，常能搜到残留的明文片段，比如：CREATE INDEX idx_user_email ON users(email) USING BTREE;
复制出来，删掉前后乱码和截断的半句（如孤立的 VALUES (1,），保存为 recovered_indexes.sql，然后在目标库的查询窗口里手动执行。注意两点：
• 先确保当前连接已选中对应数据库，或开头加 USE myapp;
• 若语句含库名前缀（如 myapp.users），统一删掉，只留表名
索引问题最易被忽略的其实是上下文：同一个 CREATE INDEX 语句，在开发库能用，在生产库可能因权限不足（缺 INDEX 权限）、引擎不同（MyISAM vs InnoDB 锁行为差异）或字符集不匹配（utf8mb4_bin 下大小写敏感导致等值判断失败）而静默失效。验证时不能只看语法通过，得连 EXPLAIN 和真实查询响应时间一起看。
