CREATE PROCEDURE 不能实现数据库架构的自动迁移，它仅是执行单元，非调度器或版本控制器；真正实现需搭配外部调用逻辑与状态追踪表，否则易出错、漏执行或重复执行。
CREATE PROCEDURE 不能实现数据库架构的自动迁移——它只是执行单元，不是调度器或版本控制器。真要靠存储过程做架构迁移，必须搭配外部调用逻辑和状态追踪表，否则极易出错、漏执行、重复执行。
MySQL 中用存储过程封装单次 DDL 迁移逻辑
每个变更（如加字段、改类型、建索引）写成独立 migrate_v20240601_add_status_column 这样的过程，名字带版本标识，便于排序和人工核对。
- 每步开头必须加存在性检查：比如用
information_schema.COLUMNS查字段是否已存在，避免ALTER TABLE ... ADD COLUMN重复执行报错 - 不要在过程里写
COMMIT或START TRANSACTION——事务控制交给调用方（比如 Python 脚本统一 begin/commit） -
DELIMITER $$必须保留在 SQL 文件中；如果用mysql -e直接执行单行命令，会因分号提前截断而报语法错误 - 过程内避免跨库引用硬编码库名，建议用参数传入或用
SCHEMA()动态获取当前上下文
SQL Server 存储过程无法自动触发，必须配 Agent Job
写了 sp_archive_orders_by_date 没用——SQL Server 不会自己定时跑它。必须用 sp_add_job 创建作业，并绑定到 SQL Server Agent 才能按计划执行。
- Agent 服务必须启动，且作业所有者账号不能被删或密码过期，否则作业静默失败，日志里只显示“未运行”
- 归档逻辑里别用
COUNT(*)判断源表行数，大表极慢；改用sys.dm_db_partition_stats查row_count字段，快一个数量级 - INSERT + DELETE 必须包在同一个事务里，并对源表加
WITH (XLOCK)，否则并发时可能漏数据或重复迁移 - 目标归档表结构、主键、索引必须提前建好；字段顺序、NULL 属性、默认值都要一致，否则
INSERT INTO ... SELECT会失败
PostgreSQL 用 pg_cron 调用存储过程才可靠
PostgreSQL 原生不支持定时执行存储过程，pg_cron 是目前最稳的选择——它是扩展，直接嵌在数据库进程里，失败自动重试，精度到秒。
- 别用
pgAgent：它是外部服务，挂了就停，还得单独维护用户权限和服务账户 - 迁移逻辑优先用 CTE +
RETURNING，例如：WITH moved AS (DELETE FROM orders WHERE order_date - 过程里别做复杂判断（比如循环查 N 个分区），
pg_cron默认超时 60 秒，超时直接中断，不回滚也不重试 - 确保 cron job 的执行用户有
EXECUTE权限，且目标表上没触发器干扰RETURNING行为
所有方案都绕不开 schema_migrations 表
存储过程本身不记录是否执行过，也不能靠“过程是否存在”来判断——information_schema.ROUTINES 不存创建时间，也无法区分 v1 和 v2 的同名过程。
- 必须建一张
schema_migrations表，字段至少含version（如'20240601'）、applied_at、success - 每个迁移过程末尾插入一行记录，且只在成功完成所有操作后才写入；失败则 rollback，不落记录
- 调用方（Shell/Python）每次先查这张表，跳过已执行的版本，严格按
version字典序执行 - 别把版本号塞进过程名再用
SHOW PROCEDURE STATUS查——过程名可能被手动删掉，但迁移实际已生效，状态就彻底丢失
真正麻烦的从来不是写 ALTER TABLE，而是保证“只跑一次、可中断、可重试、可观测”。过程只是刀，怎么握、往哪砍、砍完留不留痕，全得靠外面那一层逻辑兜住。
