数据库命名与变更流程需遵循可读性强、可追溯性高原则：库名用“业务域_环境_功能”，表名体现业务实体与状态，字段名语义清晰，索引/约束名统一前缀；所有SQL变更须经提单、审核、执行、验证闭环管控，并配套工具与巡检机制保障落地。
数据库命名和变更流程是SQL运维规范中最基础也最关键的两环。命名不统一，后续排查、协作、自动化都难推进；变更无流程，轻则数据出错，重则服务中断。核心原则就两条：可读性强、可追溯性高。
数据库与对象命名规范
命名不是随便起个名字，而是要让任何人看到名字就能大致判断用途、归属和生命周期。
-
库名：用小写字母+下划线，格式为业务域_环境_功能，例如
finance_prod_core（财务域生产核心库）、user_test_analytics（用户域测试分析库）；禁止使用拼音缩写或模糊词如db1、new_table -
表名：小写+下划线，体现业务实体+状态/类型，如
order_main、order_refund_log、user_profile_snapshot；避免t_user、tb_order这类带前缀的冗余写法 -
字段名：语义清晰优先，用名词短语，如
created_at、is_deleted、total_amount_cny；禁用flag1、data、info等泛化字段名 -
索引/约束名：统一前缀+表名+字段+类型，例如
idx_order_main_user_id（普通索引）、uk_order_main_order_no（唯一键）、fk_order_refund_log_order_id（外键）
SQL变更全流程管控
所有DDL/DML（含建表、改结构、删数据）必须走审批+执行+验证闭环，不能直连生产库敲命令。
-
提单阶段：在内部平台填写变更单，明确说明变更目的、影响范围（涉及库表、应用、下游任务）、回滚方案、预计执行窗口；附上完整SQL脚本及执行前/后校验语句（如
SELECT COUNT(*)） - 审核阶段：由DBA或资深开发双人核验——语法是否合规、是否加了必要索引、是否存在锁表风险（如ALTER TABLE无ALGORITHM=INPLACE）、是否符合命名规范；高危操作（TRUNCATE、DROP、大表UPDATE）需额外升级审批
- 执行阶段：仅允许通过自动化平台或指定跳板机执行；所有操作自动记录操作人、时间、SQL原文、影响行数；禁止在非维护窗口执行；超5分钟未响应自动中止
- 验证阶段：执行后10分钟内完成结果校验——表结构比对、关键数据抽样、应用日志检查、监控指标（QPS、慢查、连接数）有无异常波动；任一异常立即触发回滚
配套支撑机制
光有流程不够，得有工具和习惯兜底。
- 所有数据库客户端默认开启
sql_safe_updates=1，防止无WHERE的UPDATE/DELETE - 建立
schema_history表，每次变更成功后自动写入版本号、SQL哈希值、执行人、时间戳，支持快速溯源 -
开发环境强制使用
_dev后缀库，测试SQL必须先在dev库验证通过，才允许提测到预发 - 每月导出全量表结构+注释生成数据字典HTML页，同步至Wiki，注释字段必须填写，空注释视为不合规
违规处理与持续改进
规范落地靠约束，也靠反馈。把常见问题变成检查项，嵌入日常。
- 巡检脚本每日扫描：是否存在未登记的库/表、字段无注释、索引命名不规范、存在
SELECT *的定时任务SQL - 每次故障复盘必须检查是否违反命名或变更流程，对应责任人需在团队内做简要分享
- 每季度收集一线反馈，优化审批字段（比如增加“是否影响实时报表”选项）、缩短低风险变更路径（如只增列且非空的ALTER，可设白名单自动过审）
