数据库UUID适用场景咨询：应对主键变更的稳定标识方案

是否适合使用UUID？ #

先简单说明UUID：它是一种通用唯一识别码，生成后全局唯一且不会重复。但在你当前的场景里，UUID并不是最优选择——你已经拥有唯一且稳定的name列，UUID本质是字符串类型，搜索效率远低于整数或短哈希值，额外引入UUID属于冗余字段，完全没必要，除非未来name存在修改的可能性。如果name确定永远不变，UUID对你来说没有额外价值。

如何创建导入时不变、搜索高效的唯一标识键 #

由于你无法控制原表的id变更，核心是打造一个和业务实体（这里是用户）绑定、永久不变的标识，以下是几个可行方案：

1. 基于name生成固定哈希值（首推） #

利用name的唯一性，通过数据库自带的哈希函数生成固定长度的字符串作为标识键，比如MD5（32位字符），这种方式既稳定又高效。以MySQL为例：

-- 新增稳定标识列
ALTER TABLE test ADD COLUMN stable_id CHAR(32) UNIQUE NOT NULL;
-- 基于name生成哈希值填充
UPDATE test SET stable_id = MD5(name);

只要name不变，stable_id就永远固定，而且CHAR类型的哈希值搜索速度接近整数，比UUID高效得多。

2. 手动分配自增整数标识（效率最高） #

如果允许新增列，你可以给每个name分配唯一的整数标识（比如John=1、Jay=2、Maria=3），第一次导入时就完成分配，后续无论原表id怎么变，这个整数标识都绝不修改。整数类型的搜索效率是所有方案里最高的，但需要你维护好name和整数的映射关系，确保后续新增数据时不会重复分配。

3. 若必须使用UUID的实现方式 #

如果因为跨系统等特殊需求一定要用UUID，那在第一次导入数据时生成并存储UUID，之后永远不修改。以MySQL为例：

ALTER TABLE test ADD COLUMN uuid_id CHAR(36) UNIQUE NOT NULL;
UPDATE test SET uuid_id = UUID();

但要明确：UUID是字符串类型，搜索效率不如整数和哈希值，且在当前场景下属于冗余字段，非必要不推荐。

补充提示 #

你的核心需求是“稳定+高效搜索”，所以优先选择和现有唯一字段name绑定的方案，既不用额外维护映射，又能保证标识的稳定性。只有当name未来可能发生修改时，才需要考虑提前新增UUID或独立整数标识列。

内容的提问来源于stack exchange，提问作者moth