应使用 if exists drop + create 替代裸 create procedure，配合序号命名（如001_create_users_table.sql）和目录结构确保执行顺序，避免 alter procedure，统一环境基线并分离权限脚本。
SQL存储过程怎么放进Git，又不被数据库拒绝？
直接把 .sql 文件丢进 Git 没问题，但真正卡住的是：每次改完 CREATE PROCEDURE，再执行时数据库报错 There is already an object named 'xxx' in the database。这不是 Git 的问题，是 SQL 脚本写法没适配版本控制逻辑。
核心做法是统一用 IF EXISTS ... DROP + CREATE 组合，而不是裸写 CREATE PROCEDURE。这样脚本可重复执行，CI/CD 或本地重装库时才不会中断。
- 别写
CREATE PROCEDURE usp_get_user—— 第二次跑就炸 - 改写成：
IF OBJECT_ID('usp_get_user', 'P') IS NOT NULL<br> DROP PROCEDURE usp_get_user;<br>GO<br>CREATE PROCEDURE usp_get_user ... -
GO是关键分隔符，不能省；否则DROP和CREATE会被当同一批语句，SQL Server 报语法错 - PostgreSQL 用户注意：
DROP FUNCTION IF EXISTS原生支持，不用手写判断，但函数名+参数类型必须写全，比如my_func(integer)
Git 提交时该提交哪些文件？只放 .sql 行不行？
只放 .sql 文件够用，但必须配套两个约束：文件命名规则 + 目录结构反映依赖顺序。
否则团队里有人先跑了新脚本、后跑旧依赖，存储过程编译失败，还查不出谁动了上游逻辑。
- 文件名必须带序号和描述，例如：
001_create_users_table.sql、002_add_usp_get_user.sql - 按字母序执行（不是时间序），所以
002必须真能跑在001之后——建表没完成，就别定义引用它的存储过程 - 不要把不同环境的修改混在一个文件里，比如
ALTER PROCEDURE ... SET ANSI_NULLS ON这种开关变更，应单独拆出003_fix_ansi_nulls.sql，方便回滚 - 如果用 Flyway/Liquibase，它们会自动记录已执行脚本，但纯 Git 管理时，靠人维护顺序，这点最容易出错
ALTER PROCEDURE 能不能直接提交到 Git？
能，但不推荐作为主流程。因为 ALTER PROCEDURE 是“就地更新”，Git 里看不出行为变化本质：是修复 bug？加字段？还是改权限？历史追溯成本高。
更稳妥的做法是把每次变更，都转成「重建」脚本（DROP + CREATE），并用注释标明变更点。
- 错误示范：
ALTER PROCEDURE usp_get_user AS SELECT * FROM users WHERE id = @id—— Git diff 只显示一行，看不出之前是不是连@id参数都没有 - 正确做法：新脚本命名为
004_update_usp_get_user_v2.sql，开头加注释-- [v2] add @include_deleted flag，然后完整写出新逻辑 - SQL Server 中，
ALTER不改变创建时间（create_date字段不变），而DROP+CREATE会刷新时间戳，这对某些依赖元数据的运维脚本有影响，得提前对齐
开发机和测试库结构不一致，脚本一跑就挂怎么办？
不是脚本问题，是环境基线失控。Git 管的是“意图”，不是“结果”；同一份 .sql 在缺表、缺用户、缺架构的库里必然失败。
必须让每个环境都有明确的初始化快照，且该快照本身也是 Git 可追踪的。
- 根目录下放一个
baseline/文件夹，里面存create_database.sql和create_schema.sql，所有分支变更都基于它演进 - 避免在脚本里写
USE mydb—— 它会让脚本强绑定库名，CI 测试时换库名就失效；改用连接字符串指定目标库 - 权限相关语句（如
GRANT EXECUTE ON usp_get_user TO app_user）单独抽成permissions/目录，不同环境可选择性执行 - 最常被忽略的一点：SQL Server 的
QUOTED_IDENTIFIER或 PostgreSQL 的search_path设置，不显式声明的话，同一脚本在 SSMS 和 sqlcmd 下行为可能不一致
事情说清了就结束
