用JOIN替代WHERE…IN子查询可显著提升更新性能：子查询仅执行一次并物化，匹配走索引或哈希连接，避免逐行重复执行；需确保关联字段有索引，SELECT只取必要字段，大更新须分批执行并验证执行计划。
用 JOIN 替代 WHERE … IN (子查询) 更新
直接把子查询塞进 UPDATE 语句的 WHERE ... IN 里，是很多性能问题的起点。尤其是当子查询返回成千上万行时，数据库很可能对每一条待更新的记录都去执行一遍子查询（也就是所谓的“相关子查询”），或者先把整个结果集物化出来再做嵌套循环匹配。无论哪种情况，I/O和内存开销都会直线上升。
更稳妥、更高效的做法是改用 JOIN 语法。主流数据库如MySQL、PostgreSQL、SQL Server都支持，只是具体写法上略有差异：
UPDATE users u JOIN ( SELECT DISTINCT user_id FROM orders WHERE status = 'pending' AND created_at > '2026-04-01' ) o ON u.id = o.user_id SET u.status = 'processing';
- 子查询只执行一次：结果集被物化成一个临时的中间表，后续的匹配操作会走哈希连接或索引连接，效率高得多。
- 索引是前提：务必确保关联字段，比如这里的
orders.user_id和users.id上都有索引。否则，JOIN本身也可能退化成全表扫描，那就得不偿失了。 - 避免重复键：子查询里别用
SELECT *，也记得加上DISTINCT或做好去重。冗余的行虽然不会导致语法错误，但很可能引发意料之外的多重更新。
用 EXISTS 代替 IN 处理存在性判断更新
有时候，更新逻辑仅仅依赖于“某条关联记录是否存在”，而不是“具体有哪些ID”。这种情况下，EXISTS 比 IN 更轻量。因为它采用的是“短路”逻辑，一旦找到一条匹配记录就会立刻退出，根本不需要构造完整的结果集。
先看一个容易“卡住”的写法：
UPDATE products SET is_hot = 1 WHERE id IN (SELECT product_id FROM sales WHERE sale_date >= '2026-04-01');
更推荐的写法是这样的：
UPDATE products p SET is_hot = 1 WHERE EXISTS ( SELECT 1 FROM sales s WHERE s.product_id = p.id AND s.sale_date >= '2026-04-01' );
EXISTS子句里的SELECT 1是行业惯用写法，它不实际获取数据，只做存在性判断。- 关键在于，必须让子查询中的关联字段（比如
s.product_id）和外层表的字段（p.id）构成索引的前导列。否则，EXISTS也可能导致对sales表的全表扫描。 - 如果
sales表数据量极大，即使按sale_date过滤后仍然剩下很多行，那么考虑为(product_id, sale_date)建立联合索引，效果会立竿见影。
分批执行嵌套更新避免长事务
即使你已经成功把子查询重写成了 JOIN 或 EXISTS，如果一次性需要更新几十万行，仍然会触发一系列问题：长时间锁持有、产生海量的 undo log、主从复制延迟飙升，甚至直接导致事务超时。
这时候，必须进行人工“切片”，按照主键范围分批执行。来看一个具体的例子：
UPDATE users u
JOIN (
SELECT id FROM (
SELECT id FROM orders
WHERE status = 'shipped' AND updated_at < '2026-03-01'
ORDER BY id LIMIT 5000
) t
) o ON u.id = o.id
SET u.archived = 1;
- 控制批次大小：像上面这样，每次只处理最多5000行。可以通过应用层的循环，或者存储过程来推进整个批次。
- 稳定可续的批次：使用
ORDER BY id LIMIT 5000来确保每一批的边界是稳定的，并且可以无缝衔接下一批。这比用OFFSET要可靠得多，后者在数据有变动时容易跳过或重复处理数据。 - 及时提交：每一批执行完成后，记得显式地
COMMIT。这能及时释放锁，并清空事务日志的压力。 - 注意主键空洞：如果
orders表的id不连续（比如有删除操作产生空洞），那么更稳妥的滚动方式是：WHERE id > ? ORDER BY id LIMIT 5000。
避免在嵌套更新中 SELECT *
很多人图省事，在写子查询时习惯性地用 SELECT * FROM ...，觉得“反正只是用来做JOIN关联的”。这其实是一个隐蔽的性能陷阱。
数据库的优化器可能会因为返回的字段太多，而放弃使用更高效的覆盖索引。更糟糕的是，在物化中间结果时，会白白浪费大量内存和I/O资源。在某些版本的MySQL中，UPDATE ... JOIN 语句如果遇到子查询是 SELECT *，甚至会拒绝使用索引下推（ICP）优化。
- 只取所需字段：在子查询里，只
SELECT那些真正用于关联或过滤的字段。比如，用SELECT user_id就足够了，而不是SELECT *。 - 按需添加字段：只有当子查询还需要为更新操作提供具体的值时（比如，用订单的金额来更新用户的等级），才额外选取那些必要的字段。并且，要尽量确保这些字段也包含在索引中（即利用覆盖索引）。
- 警惕宽表和长字段：对于列数很多的宽表，或者包含
TEXT、BLOB这类大字段的表，这一点尤其关键。多选一个不必要的大字段，很可能导致内存临时表放不下，被迫溢出到磁盘，性能急剧下降。
说到底，真正的难点不在于写出一条能跑通的嵌套更新语句，而在于预判它在百万级甚至千万级数据量下的行为：它会怎么加锁？会产生多少事务日志？执行路径是否会穿透预期的索引？
因此，每次上线前，务必用 EXPLAIN FORMAT=TREE（MySQL 8.0+）或者 EXPLAIN (ANALYZE, BUFFERS)（PostgreSQL）仔细查看真实的执行计划。别只相信“语法没错”，执行计划告诉你的，才是数据库真正打算怎么做。
