不能直接UPDATE主键后指望外键自动同步，因SQL标准不支持隐式级联更新；必须建表时明确定义ON UPDATE CASCADE（MySQL支持，PostgreSQL需触发器，SQL Server默认不支持），否则需手动同步子表或禁用约束分步更新。
为什么不能直接 UPDATE 主键后还指望外键自动同步？
SQL 标准里，UPDATE 主键值本身是允许的，但所有指向它的外键不会自动跟着改——数据库不会“猜”你是否想级联更新。哪怕你用的是 PostgreSQL 的 ON UPDATE CASCADE，也得在建表时就明确定义，事后加不了；SQL Server 默认连这个选项都不支持，必须手动处理。
常见错误现象：UPDATE 主键成功了，但关联表查不到数据、报 Foreign key constraint failed 或返回空结果，其实是因为外键字段还存着旧的 GUID 值。
- 别幻想 ORM（比如 EF Core）会自动帮你同步关联字段——它只管自己映射的那张表
- 别用字符串替换式批量
UPDATE（比如把'A1B2...' → 'C3D4...'），GUID 是二进制语义，十六进制字符串大小写、带不带短横线（{...}格式）都影响匹配 - MySQL 8.0+ 的
BINARY(16)存储 GUID 更紧凑，但UPDATE时仍需用UNHEX(REPLACE(...))转换，不能直接塞字符串
怎么安全批量更新主键 + 所有外键引用？
核心思路：先建一张映射表，记录旧 GUID → 新 GUID 的一对一关系，再用这张表驱动所有 UPDATE。这样可回溯、可验证、可分批执行。
以 PostgreSQL 为例（其他数据库仅语法微调）：
CREATE TEMP TABLE guid_mapping AS
SELECT old_id, gen_random_uuid() AS new_id
FROM (VALUES ('a1b2c3d4-e5f6-7890-g1h2-i3j4k5l6m7n8'::uuid)) AS t(old_id);
然后逐表更新：
- 主表：
UPDATE users SET id = m.new_id FROM guid_mapping m WHERE users.id = m.old_id - 外键表（如
orders）：UPDATE orders SET user_id = m.new_id FROM guid_mapping m WHERE orders.user_id = m.old_id - 若外键字段类型是
TEXT（不推荐），UPDATE 前先用TRIM和LOWER统一格式，避免因大小写或花括号导致漏更新
SQL Server 中处理 UNIQUEIDENTIFIER 类型要特别注意什么？
UNIQUEIDENTIFIER 看似和 UUID 一样，但 SQL Server 对字面量解析更严格：直接写 'A1B2C3D4-E5F6-7890-G1H2-I3J4K5L6M7N8' 会报错，必须确保是合法的 32 位十六进制+4 短横线格式，且字母全小写（内部存储不区分，但字面量解析会卡）。
- 生成新值别用
NEWID()在UPDATE里反复调用——每行都会得到不同值；改用NEWSEQUENTIALID()或提前生成好再 JOIN - 如果原主键是
CHAR(36)（非UNIQUEIDENTIFIER类型），UPDATE 外键时必须显式CAST(... AS UNIQUEIDENTIFIER)，否则可能隐式转换失败 - 禁用外键检查（
ALTER TABLE ... NOCHECK CONSTRAINT）只是绕过校验，不是解决方案——校验关了，数据不一致风险反而更高
性能和事务边界怎么控？
批量改 GUID 主键本质是重写整条数据链，I/O 和锁开销大。单次更新超过 1 万行就容易锁表或超时。
- 务必在事务里操作：
BEGIN TRANSACTION→ 所有UPDATE→COMMIT，失败则ROLLBACK - 分批次更新：按主键范围（如
WHERE id BETWEEN ... AND ...）或用OFFSET/FETCH分页，每次 500–2000 行 - 更新前对所有涉及字段建索引（特别是外键列），否则
UPDATE ... FROM mapping会变全表扫描 - 别忽略日志空间——尤其 SQL Server 的完整恢复模式下，大事务可能撑爆
tempdb或事务日志
最麻烦的其实是业务层缓存：即使数据库改完了，应用可能还拿着旧 GUID 查缓存或发消息，这类外部一致性得靠应用配合清理，数据库管不了。
