update大字段会反复触发溢出页随机读，因innodb需读取旧溢出内容生成undo log以构造mvcc版本，即使只更新非大字段；dynamic格式可减少页分裂但不减少溢出页读取；拆表或冷热分离是根本解决方式。
为什么UPDATE大字段会反复触发溢出页随机读
InnoDB 在执行 UPDATE 时，只要目标行包含已溢出的 TEXT/BLOB 字段，就会强制加载对应溢出页——不是为了写，而是为了构造 MVCC 版本：必须先读出旧值（含溢出内容）生成 undo log，再写入新值。即使你只改一个 status 字段，只要该行 content 已溢出，UPDATE t SET status = 1 WHERE id = 123 就会触发一次或多次 os_aio 随机读。
更糟的是：如果更新前后 content 长度变化较大（比如从 5KB 变成 50KB），InnoDB 不仅要读旧溢出页，还要分配新溢出页、写入新内容、标记旧页为可 purge——整个过程放大 I/O 和内存压力。
- 常见错误现象：
Handler_read_rnd_next持续飙升，SHOW ENGINE INNODB STATUS\G中出现大量off-page关键字 - 即使
WHERE条件命中索引，EXPLAIN 也完全不体现溢出页读取开销 -
innodb_buffer_pool_size调再大也没用：溢出页默认不参与常规 buffer pool 缓存（除非ROW_FORMAT=DYNAMIC+innodb_large_prefix=ON）
如何避免UPDATE时反复读写溢出页
核心思路是让大字段“不参与事务快照构造”——即物理上与主记录解耦。不能靠 SQL 写法绕过，必须改存储结构：
- 拆表：把
content单独建表（如t_article_content），主表只留id和外键；UPDATE主表时不再触碰溢出页 - 冷热分离：对历史数据，将
content导出到对象存储，主表只存content_url和content_hash；更新 URL 或哈希不触发溢出页 I/O - 禁止在联合索引中包含大字段：比如
INDEX idx_bad (status, content)会让索引页本身也受溢出影响，且 UPDATE 时二级索引维护代价翻倍
注意：SUBSTRING(content, 1, 200) 在 UPDATE 中无效——它仍需先加载完整溢出页才能截取，开销没省。
ROW_FORMAT=DYNAMIC 真的能缓解UPDATE压力吗
能，但有严格前提：必须同时满足 innodb_file_per_table=ON、innodb_file_format=Barracuda（MySQL 5.7+ 默认），且建表/修改时显式指定 ROW_FORMAT=DYNAMIC。
DYNAMIC 的作用不是“避免溢出”，而是改变溢出策略：它把整段大字段移出主页，主页只留 20 字节指针；而 COMPACT 会硬塞前 768 字节进主页，导致页填充率虚高、分裂更频繁。
- 对 UPDATE 的实际收益：减少主数据页分裂（因主页更紧凑）、加快溢出页空间回收（purge 线程处理更及时）
- 但不会减少溢出页随机读次数——只要字段已溢出，每次 UPDATE 仍需加载
- 验证是否生效：
SHOW CREATE TABLE t\G必须看到ROW_FORMAT=DYNAMIC；SELECT ROW_FORMAT FROM information_schema.TABLES WHERE TABLE_NAME='t'返回DYNAMIC
分块UPDATE大字段时最容易踩的坑
很多人想用分块 UPDATE 缓解压力，但若不控制粒度和方式，反而加剧溢出页争抢：
- 别用
LIMIT分页：UPDATE t SET content = ? WHERE id > 1000 LIMIT 500会全表扫描偏移，每批都读大量溢出页 - 必须用主键范围：
UPDATE t SET content = ? WHERE id BETWEEN 1000 AND 1499，确保走聚簇索引，最小化回表 - 每批后
COMMIT：否则事务内所有溢出页读取、undo log、内存分配全部累积，OOM 风险极高 - 监控
Innodb_buffer_pool_wait_free：>0 表示缓冲池已吃紧，需立刻暂停；同时观察ps aux --sort=-%mem中 mysqld RSS 是否持续不回落——若每批涨 300MB 且不释放，说明触发器或performance_schema配置在偷偷吃内存
真正关键的不是“怎么分”，而是“分完要不要动大字段”：如果只是更新状态，就别把 content 放进 SET 子句；如果真要重写内容，优先走拆表或外部存储路径。
