mysqldump 导出导入会不会丢索引
不会丢——前提是不加
--no-create-info或
--skip-extended-insert类破坏性参数，且目标 MySQL 版本兼容源库的 DDL 语法。默认情况下，
mysqldump会完整导出表结构（含
CREATE TABLE、
PRIMARY KEY、
INDEX、
UNIQUE KEY等），导入时自动重建。
但真实场景中「看似没丢，实则失效」的情况更常见，比如：
源库用的是utf8mb4_0900_as_cs排序规则，目标库是
utf8mb4_general_ci，部分联合索引因 collation 不一致被静默降级或失效 迁移后未执行
ANALYZE TABLE，优化器统计信息陈旧，导致执行计划跳过本该命中的索引 Navicat 等 GUI 工具导出时默认勾选「忽略索引」或「仅数据」，用户没注意就点了确定
哪些操作真正会导致索引丢失
不是所有迁移方式都等价。以下行为会直接导致索引消失：
用SELECT INTO OUTFILE+
LOAD DATA INFILE只导数据不导结构 手动建空表再
INSERT ... SELECT，忘了
CREATE INDEX使用物理文件复制（如直接拷贝
.ibd）但没同步
.frm或没执行
ALTER TABLE ... IMPORT TABLESPACE第三方工具（如早期版 DTS 或某些定制脚本）配置漏掉「迁移索引」开关
特别注意：MySQL 8.0+ 的隐藏主键（如 JSON 列上的函数索引）、表达式索引，在低版本目标库导入时会报错跳过，而非静默忽略——错误日志里会出现类似
Unknown character set: 'utf8mb4_0900_as_cs'或
This version of MySQL doesn't support expression indexes。
迁移后必须验证索引是否生效
别只查
SHOW CREATE TABLE看语句在不在，得验证运行时是否真用得上： 用
EXPLAIN FORMAT=TREE查关键查询是否走了预期索引（尤其注意
using_index_condition和
rows_examined_per_scan） 对比迁移前后
information_schema.STATISTICS中的
CARDINALITY值，突变为 0 或极低说明统计信息没更新 检查
performance_schema.table_io_waits_summary_by_table，确认高频表的
fetch操作是否从全表扫描转为索引扫描
一个典型坑：有些 DBA 迁移后只跑
mysql -u root -p db ，却忘了在导入后补一句 <code>mysql -e "ANALYZE TABLE t1, t2;" -u root -p db，结果上线后慢查询暴增。
跨版本/跨引擎迁移时的索引兼容性
MySQL 5.7 → 8.0 或迁到 OceanBase 时，索引行为变化比你想象中多：
MySQL 8.0 默认排序规则变成utf8mb4_0900_as_cs，老索引若建在
utf8mb4_bin上，可能因 collation 冲突无法复用 InnoDB 表迁到 MyISAM（不推荐），全文索引语法不兼容，
MATCH ... AGAINST会直接报错 迁到 OceanBase 时，前缀索引长度限制更严（OB 最大 1000 字节，MySQL 是 3072），超长前缀会被截断且无提示 函数索引（如
CREATE INDEX idx ON t1 ((UPPER(name)))）在 MySQL 5.7 不支持，若 dump 文件里有，导入 5.7 会失败
最稳妥的做法：迁移前先在目标环境建测试库，用
mysqldump --no-data导出结构，人工扫一遍 DDL，重点标出带函数、JSON、隐藏列、前缀长度 > 768 的索引项。
