数据库存储过程默认禁止直接执行CREATE TABLE等DDL语句，因其会隐式提交事务、破坏事务边界；SQL Server、MySQL、PostgreSQL均报相应错误，本质是引擎对可重入性与事务一致性的强制约束。
为什么直接在存储过程中执行 CREATE TABLE 会报错
SQL Server 和 MySQL 的存储过程默认不允许在运行时动态执行 DDL（如 CREATE、ALTER），因为这些语句会隐式提交事务，破坏存储过程的事务边界。PostgreSQL 更严格——函数内执行 DDL 必须用 EXECUTE 动态拼接，且不能在事务块外调用。常见错误包括：Incorrect syntax near 'CREATE'（SQL Server）、Can't execute statement in stored function（MySQL）、ERROR: cannot execute CREATE TABLE in a function（PostgreSQL）。本质不是语法问题，而是数据库引擎对“可重入性”和“事务一致性”的强制约束。
如何用 IF NOT EXISTS + 存储过程封装实现幂等 DDL
核心思路是：把 DDL 拆成“存在性检查 + 条件执行”，不依赖外部工具，纯 SQL 实现。不同数据库写法差异大，必须按实际环境选型：
- SQL Server：用
sys.tables查表，配合IF NOT EXISTS (SELECT 1 FROM sys.tables WHERE name = 'users')，再执行CREATE TABLE users (...) - PostgreSQL：用
pg_tables或to_regclass()，推荐后者——IF NOT EXISTS (SELECT FROM pg_tables WHERE tablename = 'orders')不够健壮，应改用IF to_regclass('orders') IS NULL THEN EXECUTE 'CREATE TABLE orders (...)'; END IF; - MySQL：5.7+ 支持
CREATE TABLE IF NOT EXISTS，但注意它只判断表是否存在，不校验结构差异；若需字段级幂等，得自己查information_schema.COLUMNS
关键点：所有判断逻辑必须在存储过程内完成，避免靠应用层“先查再建”——那会引入竞态条件。
怎么让添加字段也保持幂等（避免重复 ADD COLUMN）
DDL 幂等最难的是 ALTER TABLE ... ADD COLUMN，因为多数数据库不支持 ADD COLUMN IF NOT EXISTS（MySQL 8.0.23+ 才加）。通用解法是查询元数据表，手动比对：
- SQL Server：
IF NOT EXISTS (SELECT 1 FROM sys.columns WHERE object_id = OBJECT_ID('logs') AND name = 'trace_id') - PostgreSQL：
IF NOT EXISTS (SELECT 1 FROM information_schema.columns WHERE table_name = 'events' AND column_name = 'status') - MySQL：
SELECT COUNT(*) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = 'metrics' AND COLUMN_NAME = 'unit'，结果为 0 才执行ALTER TABLE metrics ADD COLUMN unit VARCHAR(10)
注意：PostgreSQL 中 information_schema 查询可能慢，高并发场景建议用 pg_attribute 配合 pg_class，但需理解 OID 关联逻辑。
存储过程做版本迁移时，哪些地方最容易丢数据或锁表
真正上线时，最危险的不是语法错误，而是隐式行为：
-
ALTER TABLE ... ADD COLUMN在 MySQL 5.7 默认触发全表拷贝，大表执行几分钟，期间阻塞写入；PostgreSQL 11+ 对ADD COLUMN有优化，但设默认值仍可能锁表 - SQL Server 的
ALTER TABLE ... ALTER COLUMN若改类型（如VARCHAR(50) → VARCHAR(100)）不锁表，但反向收缩会失败并报错ALTER COLUMN failed because one or more objects access this column - 所有数据库中，存储过程里没显式
BEGIN TRY / BEGIN TRANSACTION，出错后不会自动回滚已执行的 DDL —— DDL 本身不可回滚，只能靠人工补救
复杂点在于：你写的存储过程能跑通，不代表它能在生产 200GB 表上安全执行。务必在同规格从库上压测锁表现和执行耗时，而不是只看语法是否通过。
