跨数据库update需适配语法：mysql用join，postgresql用from+where，sqlite用子查询；临时表须建索引防慢更新；null匹配需用coalesce或exists避免静默清空；导入数据要清洗隐藏字符并校验实际内容。
临时表更新主表时，UPDATE … FROM 语法不通用怎么办
MySQL 和 SQLite 不支持 UPDATE ... FROM 语法，直接写 UPDATE t1 SET col = t2.val FROM t1 JOIN t2 ON ... 会报错。PostgreSQL 和 SQL Server 支持，但写法细节不同——比如 PostgreSQL 要求 UPDATE t1 SET col = t2.val FROM t2 WHERE t1.id = t2.id，而 SQL Server 允许更宽松的 FROM 子句位置。
跨数据库迁移或团队混用引擎时，硬写 FROM 容易踩坑。稳妥做法是统一用子查询或 JOIN（在支持的方言中显式写出）。
- MySQL 必须用
UPDATE t1 JOIN t2 ON ... SET t1.col = t2.val - PostgreSQL 推荐用
UPDATE t1 SET col = t2.val FROM t2 WHERE t1.id = t2.id，不能省略WHERE - SQLite 只能靠相关子查询：
UPDATE t1 SET col = (SELECT val FROM t2 WHERE t2.id = t1.id)，且必须确保子查询最多返回一行，否则报错subquery returns more than one row
临时表没建主键或索引，UPDATE 变得极慢甚至卡死
批量更新本质是多次查找匹配行。如果临时表 #tmp 上没有对关联字段（如 user_id）建索引，每次更新都要全表扫描 #tmp，O(n×m) 复杂度下万级数据就明显延迟。
即使只是会话级临时表，也建议在插入后立刻加索引（SQL Server/PostgreSQL 支持；MySQL 临时表支持 INDEX，但注意 5.7+ 才稳定）：
CREATE INDEX IX_tmp_user_id ON #tmp (user_id);
- 别等 UPDATE 开始再想索引——执行前加，不是执行中加
- 如果临时表字段含 NULL，且你用
=匹配，NULL 值不会被命中，需确认业务是否允许忽略 - PostgreSQL 临时表索引默认只在当前会话有效，不用删，会话结束自动清理
UPDATE 后发现部分主表记录没更新，却没报错
这是最隐蔽的问题：关联失败时，多数数据库默认把目标字段设为 NULL（如果字段允许 NULL），而不是跳过或报错。比如用子查询更新，(SELECT val FROM #tmp WHERE id = t1.id) 查不到时返回 NULL，主表对应字段就被静默清空了。
验证方式很简单：执行前先跑一遍关联检查：
SELECT COUNT(*) FROM main_table t1 LEFT JOIN #tmp t2 ON t1.id = t2.id WHERE t2.id IS NULL;
- 如果结果非零，说明有主表记录在临时表里找不到对应项
- 想保留原值？改用
COALESCE((SELECT ...), t1.col)或CASE WHEN EXISTS (...) THEN ... ELSE t1.col END - SQL Server 的
MERGE语句能显式区分WHEN MATCHED/WHEN NOT MATCHED，但要注意权限和日志开销
临时表数据来自外部导入，字符集或大小写敏感性引发隐式失配
尤其当临时表从 CSV 导入、或由应用拼接生成时，字段可能带不可见空格、BOM、换行符，或大小写不一致（如主表存 'ABC'，临时表是 'abc'）。此时 JOIN 或子查询看似逻辑正确，实际无匹配。
快速排查方法：
SELECT TOP 5 id, LEN(id), DATALENGTH(id), ASCII(LEFT(id,1)) FROM #tmp;
- 对比主表同字段的
LEN和DATALENGTH，看是否有隐藏字符 - 用
RTRIM(LTRIM())清洗后再 JOIN，但注意这会阻止索引使用——清洗动作应放在插入临时表时做，而非 UPDATE 时实时计算 - SQL Server 默认大小写不敏感，但若主表字段是
COLLATE Latin1_General_BIN，则必须严格匹配大小写
真正麻烦的从来不是语法怎么写，而是临时表那几行数据到底长什么样——UPDATE 前花两分钟查下 SELECT * FROM #tmp 的实际内容，比翻文档快得多。
