临时表+JOIN是解决复杂批量更新最稳的方案，需建索引、用INNER JOIN、控制数据量；否则比子查询更慢，因其将“逻辑复用”升级为“物理复用”，通过索引连接避免逐行子查询。
MySQL里用@var做中间计算，但别当真
临时变量@var在MySQL中确实能“看起来”实现链式计算，比如先算折扣率再算最终价。但它不是事务安全的，也不保证执行顺序——优化器可能重排语句、并行扫描时变量被覆盖、甚至在UPDATE中赋值和使用发生在不同阶段。实际场景中，只要并发稍高或数据量稍大，@discount_rate := ...这类写法就容易产出错值。
实操建议：
- 仅限单线程脚本或低频后台任务，且必须加
SET SESSION optimizer_switch='derived_merge=off'抑制优化器乱动 - 变量赋值必须和使用出现在同一SQL中（如
SELECT @x:=col1, @y:=@x*0.9 FROM t），拆成两条语句就失效 - 不能用于子查询内部，
WHERE条件里用@var会触发全表扫描
真正可靠的分步更新：用临时表+JOIN
把中间结果固化成物理表，才是应对强依赖字段更新的通用解法。它绕开了变量不可靠性，也让每一步可验证、可加索引、可复用。
关键操作三步不能跳：
-
建表：用
CREATE TEMPORARY TABLE tmp_calc (id BIGINT PRIMARY KEY, discount_rate DECIMAL(5,4), final_price DECIMAL(10,2))，显式声明主键，类型与目标表字段严格对齐 -
写入：用
INSERT INTO tmp_calc SELECT id, COALESCE(discount_percent, 0)/100.0, base_price * (1 - COALESCE(discount_percent, 0)/100.0) FROM products，避免SELECT INTO（MySQL不支持） -
更新：用
UPDATE products p INNER JOIN tmp_calc t ON p.id = t.id SET p.discount_rate = t.discount_rate, p.final_price = t.final_price，禁用LEFT JOIN，否则没匹配上的行会被设为NULL
PostgreSQL该用WITH而不是临时表
PostgreSQL原生支持UPDATE ... FROM配合CTE，逻辑更紧凑、事务更原子，没必要落地临时表。
示例直接套用即可：
WITH calc AS (
SELECT id,
COALESCE(discount_percent, 0) / 100.0 AS rate,
base_price
FROM products
)
UPDATE products p
SET discount_rate = c.rate,
final_price = p.base_price * (1 - c.rate)
FROM calc c
WHERE p.id = c.id;注意点：
-
WITH里的计算在UPDATE前一次性执行，不存在中间状态被其他事务篡改的风险 - 如果CTE里需要多次引用同一子集，加
MATERIALIZED关键字（PG 12+），否则优化器可能重复执行 - 别在
WITH里写INSERT/UPDATE，CTE本身只读，写操作必须放在主UPDATE里
临时表生命周期和连接池的坑
临时表是会话级的，不是事务级的——哪怕你在事务里创建，断开连接就消失；但如果你用连接池（比如Druid、Hikari），同一个物理连接可能被多个请求复用，上一个请求建的tmp_calc还在，下一个请求CREATE TEMPORARY TABLE tmp_calc就会报“table exists”。
所以必须：
- 每次使用前加
DROP TEMPORARY TABLE IF EXISTS tmp_calc - 别依赖“自动销毁”，尤其在存储过程中——异常退出时虽会清理，但人为中断或超时可能导致残留
- 临时表字段含
TEXT或BLOB时，MySQL会强制退化为磁盘表（.ibd），查SHOW STATUS LIKE 'Created_tmp_disk_tables'确认是否踩中
真正难的不是写出能跑的SQL，而是让中间结果在并发、重启、连接复用这些现实条件下依然稳定可预期。临时表提供的是可控的物理落盘，而不是飘忽的内存变量。
