数据库迁移提示词：让ChatGPT远离套话空话

数据库迁移文档最怕什么？怕写了一大堆正确的废话。你打开一份《迁移方案》，满眼都是“确保数据一致性”“注意备份”“建议平滑切换”——读完之后，你依然不知道第一行命令该敲什么，哪个用户去执行，回滚怎么走。这不是文档，这是免责声明。

真正能用的迁移说明，必须能直接贴进项目文档，让DBA和后端工程师一眼看懂操作路径。每一个步骤都要精确到命令、表结构、目标版本号、执行角色权限、校验SQL，以及不可逆操作的醒目标记。抽象表述和模糊建议，一个都不要留。

先砍掉所有无效修饰词

“建议”“可以”“应尽量”“务必确保”——这些词不指向具体动作，只制造责任模糊。把“建议在迁移前备份”改成“执行 mysqldump -h prod-db -u root -p --single-transaction myapp > backup_20240520.sql”，这才叫指令。

遇到“平滑过渡”“无缝切换”“高可用保障”这类抽象表述，立刻问自己：这一步要敲哪条命令？哪个服务要重启？超时时间设多少？答不上来就删。文档不是写给别人看的，是写给别人照着做的。

用真实字段名和表结构替代占位符

方法一：从当前生产库导出实际DDL片段，粘贴进提示词里。比如写明 ALTER TABLE user_profile ADD COLUMN last_login_at DATETIME NULL DEFAULT NULL AFTER updated_at;，而不是写“添加时间字段”——后者没人知道具体加在哪里、用什么类型。

方法二：在提示词中强制要求输出带环境标识的SQL。比如指定“所有表名前缀为 staging_，且仅生成PostgreSQL 14兼容语法”，它就不会输出 SHOW CREATE TABLE 这种MySQL专属语句。关键点：必须提供目标数据库版本号。不同版本对JSONB字段索引、分区表语法支持差异极大，没版本号的迁移说明等于废纸。

绑定具体执行角色和权限范围

第一步：明确写清“该脚本由运维人员在跳板机上以 deploy 用户身份执行，deploy 用户仅有 myapp_staging 库的 SELECT、INSERT、UPDATE 权限，无 DROP 权限”。权限写清楚，出了事才知道责任边界在哪。

第二步：列出每条SQL执行后的校验动作。例如“执行完 UPDATE order SET status = 'shipped' WHERE id IN (1001,1002); 后，立即运行 SELECT COUNT(*) FROM order WHERE id IN (1001,1002) AND status = 'shipped'; 验证结果为 2”。校验SQL不是可选项，是必选项。

第三步：标注不可逆操作。比如“TRUNCATE TABLE temp_migration_log; 将永久删除日志，执行前需确认已归档至 S3://myapp-logs/migration/20240520/”。不可逆的地方加粗加红，让执行者不敢跳过确认环节。