不会丢索引——默认mysqldump导出含完整表结构(含主键、索引等),导入自动重建;但collation不一致、未ANALYZE TABLE、GUI工具误选“忽略索引”、SELECT INTO OUTFILE/空表INSERT/物理文件复制/第三方工具漏配等会导致索引失效或丢失。
mysql
dump 导出导入会不会丢索引
不会丢——前提是不加
或
类破坏性参数,且目标 MySQL 版本兼容源库的 DDL 语法。默认情况下,
会完整导出表结构(含
、
、
、
等),导入时自动重建。
但真实场景中「看似没丢,实则失效」的情况更常见,比如:
源库用的是
排序规则,目标库是
,部分联合索引因 collation 不一致被静默降级或失效
迁移后未执行
,优化器统计信息陈旧,导致执行计划跳过本该命中的索引
Navicat 等 GUI 工具导出时默认勾选「忽略索引」或「仅数据」,用户没注意就点了确定
哪些操作真正会导致索引丢失
不是所有迁移方式都等价。以下行为会直接导致索引消失:
用
+
只导数据不导结构
手动建空表再
,忘了
使用物理文件复制(如直接拷贝
)但没同步
或没执行
第三方工具(如早期版 DTS 或某些定制脚本)配置漏掉「迁移索引」开关
特别注意:MySQL 8.0+ 的隐藏主键(如 JSON 列上的函数索引)、表达式索引,在低版本目标库导入时会报错跳过,而非静默忽略——错误日志里会出现类似
或
。
迁移后必须验证索引是否生效
别只查
看语句在不在,得验证运行时是否真用得上:
MySQL(Linux)
MySQL 9.6.0是面向Linux平台的2026年创新版本,核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层,确保所有数据变更均被完整记录至Binlog,彻底解决了CDC(变更数据捕获)与主从复制中的数据不一致难题。此外,该版本引入container_aware启动选项以原生适配容器环境,并对审计日志进行了组件化重构,为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
用
查关键查询是否走了预期索引(尤其注意
和
)
对比迁移前后
中的
值,突变为 0 或极低说明统计信息没更新
检查
,确认高频表的
操作是否从全表扫描转为索引扫描
一个典型坑:有些 DBA 迁移后只跑
,结果上线后慢查询暴增。
跨版本/跨引擎迁移时的索引兼容性
MySQL 5.7 → 8.0 或迁到 OceanBase 时,索引行为变化比你想象中多:
MySQL 8.0 默认排序规则变成
,老索引若建在
上,可能因 collation 冲突无法复用
InnoDB 表迁到 MyISAM(不推荐),全文索引语法不兼容,
会直接报错
迁到 OceanBase 时,前缀索引长度限制更严(OB 最大 1000 字节,MySQL 是 3072),超长前缀会被截断且无提示
函数索引(如
)在 MySQL 5.7 不支持,若 dump 文件里有,导入 5.7 会失败
最稳妥的做法:迁移前先在目标环境建测试库,用
导出结构,人工扫一遍 DDL,重点标出带函数、JSON、隐藏列、前缀长度 > 768 的索引项。
--no-create-info--skip-extended-insertmysqldumpCREATE TABLEPRIMARY KEYINDEXUNIQUE KEYutf8mb4_0900_as_csutf8mb4_general_ciANALYZE TABLESELECT INTO OUTFILELOAD DATA INFILEINSERT ... SELECTCREATE INDEX.ibd.frmALTER TABLE ... IMPORT TABLESPACEUnknown character set: 'utf8mb4_0900_as_cs'This version of MySQL doesn't support expression indexesSHOW CREATE TABLEEXPLAIN FORMAT=TREEusing_index_conditionrows_examined_per_scaninformation_schema.STATISTICSCARDINALITYperformance_schema.table_io_waits_summary_by_tablefetchmysql -u root -p db ,却忘了在导入后补一句 mysql -e "ANALYZE TABLE t1, t2;" -u root -p dbutf8mb4_0900_as_csutf8mb4_binMATCH ... AGAINSTCREATE INDEX idx ON t1 ((UPPER(name)))mysqldump --no-data