JSON字段更新本身不直接导致严重延迟，真正引发延迟的是高频、非幂等、大体积修改操作，叠加JSON函数全字段重写、WHERE中JSON_EXTRACT无法下推索引、ROW格式写放大及未配虚拟列+索引导致全表扫描等多重瓶颈。
MySQL主从复制中，JSON字段更新本身不会直接导致严重延迟；真正引发延迟的，是**对JSON字段的高频、非幂等、大体积修改操作**，叠加了MySQL在处理JSON类型时的底层机制和复制链路瓶颈。
JSON_UPDATE/JSON_SET 触发全字段重写
MySQL 5.7+ 的 JSON_SET、JSON_REPLACE 等函数在执行时，并非“原地修改”JSON文档中的某个路径，而是：
- 读取整条记录的 JSON 字段值（可能达数MB）
- 在内存中解析为内部结构，执行路径更新
- 序列化回完整 JSON 字符串，再写入磁盘
- 该过程产生完整的
UPDATE行事件，Binlog 中记录的是整个新 JSON 值（不是 diff）
这意味着：哪怕只改 $.user.profile.avatar 一个字段，Binlog 也会传输整个 JSON 字符串。网络带宽、从库 I/O 和 SQL 线程解析开销都会显著上升，尤其当单条 JSON 超过 100KB 且每秒更新上百次时，Seconds_Behind_Master 很快飙升到几十秒甚至分钟级。
JSON 字段无法使用常规索引加速 WHERE 条件
如果业务逻辑依赖 JSON 字段做条件更新（例如：UPDATE t SET data = JSON_SET(data, '$.status', 'done') WHERE JSON_EXTRACT(data, '$.task_id') = '123'），会触发严重性能问题：
-
JSON_EXTRACT在 WHERE 中属于**不可下推的函数计算**，无法利用索引 - 主库执行时可能走全表扫描，生成大量 Binlog 事件
- 从库 SQL 线程逐条重放时，同样要对每行执行 JSON 解析 + 提取 + 比较，CPU 持续满载
- 这种语句在高并发下极易让从库 SQL 线程成为瓶颈，
Slave_SQL_Running可能卡住或持续落后
Binlog 格式与 JSON 写放大效应
使用 ROW 格式（推荐）时，JSON 字段变更仍会写入完整值；但若误配为 MIXED 或 STATEMENT，问题更隐蔽：
-
STATEMENT模式下，JSON_SET等函数可能被记录为原始 SQL，从库重放时需再次解析 JSON —— 两次解析，开销翻倍 -
MIXED模式下，MySQL 可能因判定“不安全”而自动切到STATEMENT，行为不可控 - 无论哪种格式，只要 JSON 值体积大、更新频次高，就会加剧 relay log 写入、SQL 线程反解、InnoDB redo log 刷盘三重压力
虚拟列 + 索引没配，等于白用 JSON 类型
很多人以为加了 JSON 类型就“现代化”了，却忽略关键配套：
- 没为常用查询路径建虚拟列（如
ALTER TABLE t ADD COLUMN task_id VARCHAR(32) AS (JSON_UNQUOTE(JSON_EXTRACT(data, '$.task_id'))) STORED） - 没在虚拟列上建索引（
CREATE INDEX idx_task_id ON t(task_id)） - 结果所有基于 JSON 的 WHERE / JOIN 都退化为全表扫描 + JSON 解析，主库慢、从库更慢
- 这类设计缺陷在主从架构下会被指数级放大：主库压力是 1x，从库压力是 1x（SQL 线程单线程重放）+ 额外解析开销
真正卡住复制的，往往不是 JSON 本身，而是把它当黑盒用、绕过关系型数据库最擅长的索引和谓词下推能力。一旦开始在 JSON 上做高频条件更新，又没补虚拟列，延迟就不再是“可能”，而是“必然”。
