行迁移是数据更新导致行变长、原数据块空间不足时，数据库将整行移至新块并保留迁移指针的现象，引发二次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重建。
行迁移不报错、不阻断业务，却像慢性病一样侵蚀性能。关键在设计阶段预判更新模式，上线后结合监控指标主动识别，而不是等慢查询告警才介入。
