UPDATE中函数导致慢的主因是WHERE条件对字段用函数（如UPPER()）使索引失效，引发全表扫描；应改写为字段=值、建计算列索引或预计算到临时表再JOIN更新。
UPDATE 里用函数导致慢，先看执行计划有没有全表扫描
在 UPDATE 语句的 WHERE 条件里，一旦对字段使用了 UPPER()、CONCAT() 或 DATE_FORMAT() 这类函数，无论是 MySQL 还是 PostgreSQL，数据库引擎都很可能放弃使用索引，转而进行全表扫描。原因很简单：索引是基于字段的原始值构建的，而函数计算后的值，索引“不认识”。典型的例子就是 WHERE UPPER(name) = 'JOHN'，即使 name 字段上建有索引，此时也形同虚设。
- 诊断第一步：查看执行计划。 在 MySQL 8.0.19 及以上版本，可以直接使用
EXPLAIN UPDATE ...。对于更早的版本，可以先将UPDATE改写为等价的SELECT语句，然后执行EXPLAIN。关键要看执行结果的type列是否为ALL，这通常意味着全表扫描。 - 优化首选：把函数挪到等号右边。 这是最直接的优化思路。例如，将
UPPER(name) = 'JOHN'改写为name = 'john'。当然，这需要确保数据库的校对集（Collation）是大小写不敏感的，或者应用层能保证传入值的大小写格式统一。 - 备选方案：使用持久化计算列并建立索引。 如果业务逻辑必须使用函数过滤，可以考虑创建计算列。在 PostgreSQL 中，可以使用
GENERATED ALWAYS AS (UPPER(name)) STORED语法；在 MySQL 5.7+ 中，语法类似。创建这个存储列后，再为其建立索引，查询时直接使用该列即可利用索引。
批量更新前先预计算，别在 SQL 里反复调函数
批量更新的性能瓶颈，常常隐藏在那些被反复调用的函数里。举个例子：需要根据 created_at 和 region 字段，为十万条订单记录计算并更新 status_code。如果写成 UPDATE orders SET status_code = (SELECT code FROM rules WHERE ...)，那么对于 orders 表中的每一行，那个子查询都会被执行一次，总计十万次，效率可想而知。
- 核心策略：预计算到临时表。 先把需要更新的所有ID和计算好的新值，一次性算出来，存放到临时表里。例如：
CREATE TEMPORARY TABLE tmp_update AS SELECT id, calc_status_code(created_at, region) AS new_code FROM orders WHERE ...。 - 高效更新：使用 JOIN。 然后，通过
JOIN临时表的方式执行更新：UPDATE orders o JOIN tmp_update t ON o.id = t.id SET o.status_code = t.new_code。这样，复杂的计算逻辑只执行了一次，更新操作本身也变得非常高效。 - 通用原则：避免在 SET 或 WHERE 中调用标量函数。 尤其是自定义函数，它们通常无法被数据库优化器向量化处理，而且像 MySQL 这样的数据库，默认不会缓存函数的返回值，导致每次调用都是全新的计算。
临时列不是万能解法，注意存储开销和事务一致性
有些开发者喜欢采用“临时列”策略：先给表加一个 tmp_calc_value 列，用 UPDATE 填充计算结果，再用这个列去驱动后续的 JOIN 或更新逻辑。这个方法看似一步到位，实则暗藏风险。
- 索引是前提。 如果后续操作需要基于这个临时列进行关联或筛选，那么必须为它创建索引，否则依然会引发全表扫描，优化目的就落空了。
- 注意数据清理与事务一致性。 如果更新过程意外中断，临时列里可能会残留部分更新的“脏数据”。一个更干净的做法是使用真正的临时表（
DROP TEMPORARY TABLE），或者在事务结束后显式执行ALTER TABLE ... DROP COLUMN来清理。 - 注意数据库特性限制。 在 PostgreSQL 中，标记为
GENERATED的计算列是不能直接 UPDATE 的。而在 MySQL 中，STORED类型的生成列也不允许在 UPDATE 的 SET 子句中被赋值。此外，对大表执行加列操作（即使是临时列）可能会引发锁表，虽然 MySQL 5.6+ 的ALGORITHM=INPLACE可以缓解，但元数据锁依然存在。
用 WITH 语句替代嵌套子查询（PostgreSQL / MySQL 8.0+）
过去，我们可能习惯写这样的嵌套子查询：UPDATE t1 SET x = (SELECT y FROM t2 WHERE t2.id = t1.ref_id AND t2.flag = 'A')。这种写法不仅性能不佳（可能对 t1 的每一行都执行一次子查询），可读性也差。
- 现代写法：使用 CTE (Common Table Expressions)。 通过 WITH 语句预先将需要关联的数据计算并聚合好，代码逻辑瞬间清晰：
WITH calc AS ( SELECT ref_id, MAX(y) AS new_y FROM t2 WHERE flag = 'A' GROUP BY ref_id ) UPDATE t1 SET x = calc.new_y FROM calc WHERE t1.ref_id = calc.ref_id;
- MySQL 的变通方案。 MySQL 8.0+ 虽然支持 CTE，但不支持在 UPDATE 中直接与 CTE 进行 JOIN。这时需要将 CTE 包裹在子查询中：
UPDATE t1 JOIN (SELECT ...) calc ON ... SET ...。 - 理解物化行为。 在 PostgreSQL 中，CTE 是否被物化（即结果集是否被临时存储）取决于优化器设置。而在 MySQL 中，CTE 默认不被物化，如果在一个查询中多次引用同一个 CTE，它可能会被重复计算，这点需要留意。
说到底，性能问题的关键往往不在于语法本身，而在于对函数调用位置的敏感度——它决定了计算是一次完成，还是重复 N 次。使用临时列看似省事，但背后是额外的磁盘写入、潜在的锁开销以及数据清理的责任。预计算这一步，本质上无法跳过，我们只是选择在应用层、在临时表里，还是在数据库的 CTE 中完成它而已。
