根本原因是单个事务处理行数过多，导致innodb频繁锁管理、redo刷盘和mvcc维护，引发内核线程反复调度；应按500–2000行分批并显式commit，确保每批真实提交，且分片字段需有有效索引。
MySQL事务太大导致上下文切换飙升
根本原因是单个事务内处理的行数过多，InnoDB在执行过程中频繁申请/释放锁、刷redo log、维护MVCC版本链，让内核线程反复调度。尤其在高并发写入时，show processlist里常看到大量update或insert卡在updating或Writing to net状态，但CPU不高、IO也不满——其实是线程被调度器反复切出切进。
怎么拆分INSERT/UPDATE语句才有效
不能只看SQL写法是否“看起来分批”，关键得让每批真实提交。常见误区是用循环拼接SQL但共用一个START TRANSACTION，这毫无意义。
- 每批操作后必须显式调用
COMMIT（或自动提交开启下确保没被包在大事务里） - 单批记录数建议控制在 500–2000 行之间：太小（如50行）会放大网络往返和事务开销；太大（如10000+）仍可能触发长锁等待和undo膨胀
- 使用
INSERT INTO ... VALUES (...), (...), (...)批量插入，避免逐条INSERT——哪怕分批，也要用多值语法 - 如果用
LOAD DATA INFILE，它默认按文件块提交，但需确认innodb_log_file_size足够，否则可能因redo log写满被迫刷盘阻塞
示例（Python + PyMySQL）：
for i in range(0, len(records), 1000):<br> batch = records[i:i+1000]<br> cursor.executemany("INSERT INTO t (a,b) VALUES (%s,%s)", batch)<br> conn.commit() # 这句不能少
UPDATE按条件分片时容易漏掉WHERE或索引失效
想用WHERE id BETWEEN ? AND ?分片更新，结果全表扫了，锁住整张表，上下文切换反而更猛。
- 务必确认分片字段（如
id）上有有效索引，EXPLAIN输出中type至少是range，不能是ALL - 避免在
WHERE里对索引字段做函数操作，比如WHERE DATE(create_time) = '2024-01-01'会让索引失效 - 分片边界要严格递增且无重叠，否则同一条记录被多次更新，或漏更新；可用
SELECT MIN(id), MAX(id) FROM t先探范围，再按固定步长切 - 如果更新涉及JOIN或子查询，优先改写成临时表+主键关联，避免每次分片都重算关联逻辑
autocommit=0 + 手动COMMIT不是万能解药
有些场景下关掉自动提交、自己控制事务粒度，反而更糟——比如在连接池里复用连接，上一个请求没COMMIT或ROLLBACK，下一个请求进来就直接卡在Waiting for table metadata lock。
- Web应用中，除非明确需要跨多个DML的原子性，否则应保持
autocommit=1，靠分批SQL自然形成小事务 - 若必须用大事务（如数据迁移），记得设置
innodb_lock_wait_timeout合理值（比如30），避免死等；同时监控Innodb_row_lock_waits指标突增 - 注意
max_allowed_packet限制：分批太大可能触发Packets larger than max_allowed_packet are not allowed错误，导致批量失败回退到单行处理
真正卡点往往不在SQL怎么写，而在事务边界是否和业务语义对齐——比如“导入10万用户”本就不该是一个事务，但“给某用户升VIP并扣余额”就必须是单事务。分批只是技术手段，前提得先厘清哪部分逻辑真需要原子性。
