2.2 KiB
2.2 KiB
历史 UUID 迁移指引(已归档)
说明:项目已经统一改为直接使用
schema.sql初始化数据库,不再提供单独的 UUID 迁移脚本。本指南仅保留作为旧环境排查的参考,若你是全新部署,可直接执行schema.sql并忽略本文件。
-
确认扩展
登录 PostgreSQL,执行\dx检查是否已经启用了uuid-ossp或pgcrypto。若没有,可执行:CREATE EXTENSION IF NOT EXISTS "uuid-ossp"; CREATE EXTENSION IF NOT EXISTS "pgcrypto";推荐使用
pgcrypto的gen_random_uuid();若历史库已启用uuid-ossp,脚本中的uuid_generate_v4()亦可直接使用。 -
备份数据库
任何迁移前都应留存快照:pg_dump -U <user> -d <dbname> > backup_before_uuid.sql -
执行迁移脚本(仅旧项目)
旧版项目曾通过migrate_to_uuid.sql完成以下步骤:- 新增
uuid主键列并填充现有数据; - 添加
user_uuid外键字段,与旧的自增id并行; - 删除旧的
id、user_id列并将uuid设为主键。
如仍需在遗留环境执行,可根据上述逻辑自行编写脚本,或从历史提交中找回旧版 SQL。
- 新增
-
验证结果
迁移完成后进入数据库(psql -U <user> -d <dbname>)并检查:\d users \d identities \d sessions预期结构示例:
users(uuid PRIMARY KEY, username, password, email, created_at …)identities(uuid PRIMARY KEY, user_uuid REFERENCES users(uuid), provider, external_id …)sessions(uuid PRIMARY KEY, user_uuid REFERENCES users(uuid), token, expires_at …)
亦可通过信息架构核对外键:
SELECT constraint_name, table_name, column_name, foreign_table_name FROM information_schema.key_column_usage WHERE table_schema = 'public'; -
回滚策略
若迁移出现问题,可使用备份恢复:psql -U <user> -d <dbname> < backup_before_uuid.sql
小结:新部署只需运行
schema.sql。旧环境若要沿用 UUID 主键改造,可参考上述思路自行调整脚本,并务必在操作前备份。