行迁移是数据更新导致行变长、原数据块空间不足时，数据库将整行移至新块并保留迁移指针的现象，引发二次 I /O、降低查询性能。常见诱因包括 NULL 转长值、变长字段追加、未设 PCTFREE/innodb_fill_factor、大字段高频更新；可通过 v$segment_statistics、Innodb_metrics 或 EXPLAIN 检测；预防需预留空间、分离大字段、避免追加更新及定期整理。
行迁移（Row Migration）是 SQL 数据库中一个隐蔽但影响显著的性能问题，尤其在频繁更新、行长度变化较大的场景下容易触发。它本身不是错误，却会直接拖慢查询响应、增加 I / O 开销，甚至让执行计划失真。
什么是行迁移？
当一行数据因 UPDATE 变长（比如 TEXT 字段被填充、VARCHAR 扩大），而原数据块（data block）剩余空间不足以容纳新长度时，Oracle 或 MySQL（InnoDB）等数据库会将整行“搬走”：把数据移到另一个有足够空闲空间的数据块中，原位置只保留一个指向新地址的指针（称为迁移指针或 rowid 转发）。后续对这行的访问必须先读原块、再跳转到新块——一次逻辑读变成两次，且无法利用缓存局部性。
哪些更新操作容易引发行迁移？
以下情况需特别警惕：
- 从 NULL 更新为长值 ：例如UPDATE users SET bio = ‘…’ WHERE id = 123，bio 原为 NULL（几乎不占空间），更新后存入 500 字节 文本；
- 变长字段持续追加：如日志字段log_text = CONCAT(log_text, ‘[new event]’)，反复执行导致行不断膨胀；
- 未预留 PCTFREE 或填充因子：建表时PCTFREE 0（Oracle）或innodb_fill_factor=100（MySQL），块被填满后无余量应对更新；
- 大字段与高频更新共存：含 BLOB/TEXT 列的表，同时承担订单状态、审核备注等高频 UPDATE 业务。
如何发现已发生的行迁移？
不能仅靠慢查询猜——要主动检测：
- Oracle：查 v$segment_statistics 中table fetch continued row计数突增；或用 ANALYZE TABLE … LIST CHAINED ROWS 定位具体行；
- MySQL InnoDB：监控 Innodb_row_lock_waits 和Innodb_buffer_pool_read_requests比率异常升高；结合 information_schema.INNODB_METRICS 查buffer_pool_reads是否陡增；
- 通用方法 ：对疑似表执行EXPLAIN FORMAT=JSON 看执行计划中是否出现 “using rowid filter” 或额外回表动作；对比更新前后相同主键查询的逻辑读次数。
怎样预防和缓解？
核心思路是“留空 + 拆分 + 控制”：
- 建表时预留空间 ：Oracle 设PCTFREE 10~20；MySQL 调低innodb_fill_factor 至 80~90（需重建表生效）；
- 分离大字段：把 BLOB/TEXT/CLOB 挪到独立扩展表（如orders + orders_ext），主表保持窄而稳定；
- 避免“追加式”更新：改用应用层拼接后一次性写入，或用专用日志表替代字段内累积；
- 定期整理 ：对高迁移率表安排维护窗口，Oracle 用ALTER TABLE … SHRINK SPACE，MySQL 通过OPTIMIZE TABLE 或ALTER TABLE … FORCE重建。
行迁移不报错、不阻断业务，却像慢性病一样侵蚀性能。关键在设计阶段预判更新模式，上线后结合监控指标主动识别，而不是等慢查询告警才介入。
