好问题！这其实是MySQL事务特性带来的典型场景——InnoDB（默认引擎）会把整个大事务的变更缓存起来，直到事务提交才会让其他会话看到结果，甚至有时候连当前会话在事务未提交时查询也可能看不到中间状态（取决于隔离级别）。要实现你说的「每处理一批就实时写入可见」，核心思路就是拆分大事务为多个小事务，每处理一小批就提交一次，这样变更就能立刻生效并被其他会话看到。

1. 手动拆分批次执行UPDATE #

最直接的方式是按主键/唯一键分段，每次处理固定数量的行，每批处理完就提交事务（MySQL默认自动提交的话，单条语句就是一个事务）。比如你提到的CHUNK 1000的思路，我们可以手动实现：

假设你的表有自增主键id，可以这样循环执行：

-- 初始化起始ID
SET @last_id = 0;
-- 循环处理，每次1000条
REPEAT
  UPDATE your_table
  SET FieldA = FieldB
  WHERE id > @last_id
  ORDER BY id
  LIMIT 1000;
  
  -- 更新最后处理的ID，避免重复处理
  SET @last_id = (SELECT MAX(id) FROM your_table WHERE id > @last_id);
  -- 用ROW_COUNT()判断是否还有未处理的行
UNTIL ROW_COUNT() = 0 END REPEAT;

• 额外优化：加上FieldA != FieldB的条件，避免重复处理已经更新过的行，提升效率：

UPDATE your_table
SET FieldA = FieldB
WHERE id > @last_id AND FieldA != FieldB
ORDER BY id
LIMIT 1000;

如果你的表没有自增主键，也可以用其他唯一有序的字段（比如时间戳、业务唯一ID）来分段。

2. 分批执行INSERT SELECT #

对于大数量的INSERT ... SELECT，同样可以拆分批次：

SET @last_id = 0;
REPEAT
  INSERT INTO target_table (col1, col2, ...)
  SELECT col1, col2, ...
  FROM source_table
  WHERE id > @last_id
  ORDER BY id
  LIMIT 1000;
  
  SET @last_id = (SELECT MAX(id) FROM source_table WHERE id > @last_id);
UNTIL ROW_COUNT() = 0 END REPEAT;

这样每插入1000条就会提交一次，目标表会实时新增数据，其他会话可以立刻查询到。

3. 关键原理说明 #

为什么默认大查询看不到中间结果？因为：

• InnoDB是事务型引擎，大事务会将所有变更放在事务日志中，直到事务提交才会刷到磁盘并对其他会话可见。
• 即使是当前会话，在默认的REPEATABLE READ隔离级别下，也只能看到事务开始前的数据状态，看不到事务内的中间变更。
  拆分小事务后，每批提交都会让变更立刻生效，突破了这个限制。

4. 注意事项 #

• 避免锁冲突：小批次处理能减少行锁的持有时间，降低和其他业务查询的锁冲突概率。
• 幂等性：确保重复执行批次不会造成数据错误（比如用FieldA != FieldB过滤已处理行，或者用唯一键避免重复插入）。
• 性能平衡：批次大小不要太小（比如100条）会增加事务提交的开销，也不要太大（比如10万条）又回到大事务的问题，通常1000-10000条是比较合适的区间，根据你的服务器配置调整。

内容的提问来源于stack exchange，提问作者UKUser35