必须用EXCHANGE PARTITION而非INSERT...SELECT的情况是：将已构建好索引和约束的完整数据集（如日订单快照）快速接入分区表，以实现毫秒级元数据切换、避免锁表、重建索引及触发触发器。
什么情况下必须用 EXCHANGE PARTITION 而不是 INSERT ... SELECT
当你要把一个已构建好的、带索引和约束的完整数据集（比如一天的订单快照）快速接入分区表时，EXCHANGE PARTITION 是唯一能避免锁表、避免重建索引、避免触发触发器的方案。它本质是元数据切换，不移动数据文件，毫秒级完成。
常见误用是拿它替代日常 DML —— 它不是增删改查工具，而是“冷数据批量上架”或“热数据归档下线”的原子操作。
- 源表必须与目标分区有完全一致的列定义（顺序、类型、是否允许 NULL）、相同存储引擎（通常是
InnoDB）、且不能有外键引用 - 源表不能是临时表，也不能是分区表本身
- 执行前需确保源表已建好对应索引（否则交换后查询会变慢，且无法在交换过程中自动创建）
- 如果目标分区非空，交换会失败；想覆盖就得先
TRUNCATE PARTITION或DROP PARTITION
EXCHANGE PARTITION 和 ALTER TABLE ... REORGANIZE PARTITION 的分工区别
前者是“换皮”：把一个独立表的数据逻辑挂到某个分区名下；后者是“拆分/合并”：在同一个表内部重划数据边界，会实际拷贝数据并重建索引。
典型场景对比：
- 每天凌晨把
staging_orders_20240520表快速变成orders表的p20240520分区 → 用EXCHANGE - 发现按天分区太细，要把 30 个日分区合并成 1 个月分区 → 用
REORGANIZE - 想把旧分区里的部分数据挪到新分区（比如按用户 ID 重分布）→ 不能用
EXCHANGE，得走INSERT ... SELECT+DELETE
混淆这两者会导致计划外的 I/O 爆发或锁表时间远超预期。
为什么交换后查询变慢？常见索引陷阱
交换本身不校验索引匹配度。如果源表缺失某索引，交换后该分区就真的没这个索引——而优化器仍可能按“全表有索引”来生成执行计划，结果走全表扫描。
- 务必在交换前用
SHOW CREATE TABLE对比源表和原表的索引定义 -
PRIMARY KEY和UNIQUE KEY必须严格一致；普通INDEX缺失不会报错，但会静默丢失 - 若源表用了
AUTO_INCREMENT，交换后该列在分区上下文中不再自增（因为分区属于主表），后续插入需显式指定值或依赖主表的自增逻辑 - 交换后首次查询该分区时，InnoDB 可能触发隐式
ANALYZE TABLE，造成短暂延迟，可通过提前执行ANALYZE TABLE orders PARTITION(p20240520)规避
MySQL 8.0+ 下跨表空间（file-per-table）交换的注意事项
启用 innodb_file_per_table=ON 时，每个表/分区有独立 .ibd 文件。EXCHANGE PARTITION 本质是原子性地交换 .ibd 文件路径指针，所以要求源表和目标分区位于同一文件系统、且 MySQL 进程有读写权限。
- 如果源表建在
general tablespace或system tablespace中，无法与file-per-table分区交换 - 使用
DATA DIRECTORY指定路径的分区，交换时源表也必须建在相同路径下（否则报错ER_TABLESPACE_MISSING） - 备份恢复后，若只还原了主表结构没还原分区文件，交换会失败并提示
Tablespace is missing for table
这些限制不是 bug，而是 InnoDB 存储层强一致性的体现——文件归属关系一旦错位，就拒绝交换，避免元数据和物理文件脱节。
