索引明明存在，查询却慢如蜗牛？SHOW INDEX FROM 输出显示索引“空缺”，别急着怀疑是导入时的错觉——大概率是索引根本没建上去。归根结底，问题集中在三个环节：导出时结构丢失、用户权限不足、导入过程跳过维护。逐一排查，往往比反复重导更高效。
导出时跳过了表结构，导致索引语句丢失
不少开发者用 mysqldump 时习惯加 --no-create-info，或者只导数据（比如用 --no-create-db --skip-triggers 刻意精简），结果生成的 SQL 文件里只有 INSERT 语句，CREATE TABLE 和索引定义完全缺席。导入自然只剩数据，索引无从谈起。
- 用
SHOW CREATE TABLE table_name看一眼输出里有没有KEY、UNIQUE KEY、PRIMARY KEY这些行——没有就是导出时漏了。 - 正确的导出命令很简单：
mysqldump -u user -p db_name table_name > backup.sql，默认就带结构和索引。 - 已经导入但缺索引？别重导，直接补充：
CREATE INDEX idx_col ON table_name(col);
用户没被授予 ALTER 权限，CREATE INDEX 被静默跳过
phpMyAdmin 图形界面里点“创建索引”，或者执行 CREATE INDEX 语句，如果当前 MySQL 用户缺少 ALTER 权限（MySQL 5.7+ 下 ALTER 隐含 INDEX 权限），MySQL 会直接拒绝，抛出 ERROR 1142: INDEX command denied。但 phpMyAdmin 有时只显示空白或超时，不弹具体错误信息——这个坑踩过的人不少。
- 先查权限：
SHOW GRANTS FOR 'user'@'host';，看输出里有没有GRANT ALTER ON `db`.*。 - 授予权限必须用高权限账号（如 root）：
GRANT ALTER ON `db_name`.`table_name` TO 'user'@'host'; FLUSH PRIVILEGES;。 - 特别注意 host 必须完全匹配：
'user'@'localhost'和'user'@'%'是两个不同的账号，写错等于没授权。
导入过程绕过了索引维护，物理结构已损坏
大批量 INSERT 时——尤其是 phpMyAdmin 默认的导入模式——会跳过索引页合并与 B+ 树重组。结果索引虽然在元数据里存在，但严重碎片化。EXPLAIN 显示 key 非空，rows 却极大，查询依旧走全表扫描。这时候别急着删表重建，先试试轻量维护。
- 直接执行：
OPTIMIZE TABLE table_name;——对于 InnoDB，这等价于重建所有索引并更新统计信息。 - 立刻再跟一句：
ANALYZE TABLE table_name;，否则优化器可能继续沿用旧的错误统计。 - 大表操作前记得检查磁盘空间：
OPTIMIZE临时需要约 2 倍表大小的空间。
视图或 DEFINER 干扰了索引创建流程
SQL 文件里混着 CREATE VIEW 且含 DEFINER 子句，而目标库没有这个用户。MySQL 在解析视图阶段就卡住，后续的 CREATE INDEX 根本没机会执行。错误日志里常出现 ERROR 1449，但 phpMyAdmin 可能只报“脚本中断”——这种隐形问题最容易让人绕圈子。
- 导入前用 sed 清理：
sed -E "s/DEFINER=[^ ]+//g" dump.sql > clean.sql。 - 或者手动打开 SQL 文件，删掉所有
DEFINER=\`xxx\`@\`yyy\`子句（保留SQL SECURITY部分）。 - 确保文件开头有
SET sql_mode = '';，避免严格模式下字段类型不匹配导致中途退出。
说到底，真正卡住的往往不是语法，而是权限作用域、导出范围、或者视图依赖链这些看不见的环节。多跑一遍 SHOW INDEX 和 SHOW GRANTS，比反复重试快得多。
