不会丢索引——默认mysqldump导出含完整表结构（含主键、索引等），导入自动重建；但collation不一致、未analyze table、gui工具误选“忽略索引”、select into outfile/空表insert/物理文件复制/第三方工具漏配等会导致索引失效或丢失。
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 的索引项。
