数据库规范 - 技术栈

数据库规范（也叫数据库设计规范/开发规范）是一套行业通用的最佳实践，覆盖从库表设计 到SQL编写 再到运维管理的全流程，核心目标是：可读性强、扩展性好、性能稳定、安全可控。以下是分模块的核心规范，适配MySQL等主流关系型数据库。

一、基础命名规范（核心：统一、语义化、无歧义）

命名是规范的基础，混乱的命名会直接增加维护成本，核心原则：小写+下划线分隔、语义化、不缩写（必要缩写需统一）、避免关键字。

对象	规范示例	禁止示例	说明
数据库名	`user_center`、`order_system`	`UserCenter`、`db1`	小写+下划线，体现业务域
表名	`t_user`、`t_order_detail`	`user`、`OrderDetail`	前缀`t_`（表）+业务语义
字段名	`user_id`、`order_create_time`	`uid`、`createTime`	小写+下划线，不缩写
主键	`id`（单表）/`user_id`（关联）	`ID`、`userid`	单表用`id`，关联字段带业务名
索引名	`idx_order_user_id`、`uk_user_mobile`	`index1`、`idx_1`	前缀：`idx_`（普通索引）、`uk_`（唯一索引）、`pk_`（主键）+字段名
外键名	`fk_order_user_id`	`fk1`、`fk_order_1`	前缀`fk_`+表名+关联字段
视图名	`v_user_order`	`view1`、`V_UserOrder`	前缀`v_`（视图）+语义
存储过程	`proc_sync_user_data`	`sp1`、`SyncUserData`	前缀`proc_`+操作+业务

关键禁忌：

禁止使用数据库关键字（如order、user、select），若必须用需加反引号（`）；
禁止用数字开头（如1_user）、禁止用特殊字符（如user-123）；
禁止中英文混用（如user_姓名）、禁止拼音+英文混用（如user_xingming）。

二、库表结构设计规范（核心：合理、易扩展、符合范式）

1. 库表基础规范

字符集与排序规则 ：统一用utf8mb4（兼容emoji）+utf8mb4_general_ci，避免乱码和排序异常；
存储引擎 ：MySQL优先用InnoDB（支持事务、行锁、外键），禁用MyISAM（无事务、表锁）；

表注释 ：所有库、表、字段必须加注释（COMMENT），示例：

sql 复制代码

CREATE TABLE t_user (
    id BIGINT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '用户主键ID',
    mobile VARCHAR(11) NOT NULL COMMENT '手机号',
    create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
    PRIMARY KEY (id) COMMENT '主键索引'
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COMMENT='用户基础信息表';

2. 字段设计规范

字段类型	规范要求
主键	优先用`BIGINT UNSIGNED`（无符号长整型），禁用`INT`（易溢出），自增用`AUTO_INCREMENT`
字符串	固定长度用`CHAR`（如手机号`CHAR(11)`），可变长度用`VARCHAR`，禁用`TEXT`（查询慢）除非内容超长
数值	金额用`DECIMAL(10,2)`（精准），禁用`FLOAT/DOUBLE`（浮点精度丢失）
时间	统一用`DATETIME`（可读性强）或`TIMESTAMP`（需时区同步），禁用`VARCHAR`存时间（无法排序/计算）
状态字段	用`TINYINT`（如`status TINYINT COMMENT '1-正常 2-禁用'`），禁用`VARCHAR`（如`status '正常'`）

3. 范式与反范式（平衡设计）

必须遵循三大范式 （核心：减少冗余）：
1. 第一范式：字段原子性（如禁用address存"省市区"，拆分为province、city、district）；
2. 第二范式：主键依赖（非主键字段必须完全依赖主键，而非部分依赖）；
3. 第三范式：消除传递依赖（如订单表不存用户名，通过user_id关联用户表查询）。
适度反范式 （性能优先）：高频查询的关联字段可冗余（如订单表冗余user_name，避免每次关联查询）。

4. 通用字段（所有表必加）

为了便于审计和排查问题，所有业务表建议添加4个通用字段：

sql 复制代码

create_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP COMMENT '创建时间',
update_time DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP COMMENT '更新时间',
creator VARCHAR(32) COMMENT '创建人',
updater VARCHAR(32) COMMENT '更新人';

三、索引设计规范（核心：按需创建、避免冗余）

索引是性能优化的核心，但过多/不合理的索引会导致插入/更新变慢，核心原则：宁少勿多、精准高效。

1. 必加索引

所有表必须有主键（主键索引）；
外键字段（如order表的user_id）必须加普通索引；
高频查询条件字段（如mobile、order_status）加索引；
排序/分组字段（如order_create_time）加索引。

2. 索引禁忌

禁止给TEXT/BLOB字段加索引（如需加用前缀索引：idx_content (content(20))）；
禁止给低基数字段加索引（如gender（男/女），区分度太低，索引失效）；
禁止创建冗余索引（如已有idx_user_id，再创建idx_user_id_mobile就是冗余）；
单索引字段数不超过5个（复合索引），避免索引过大。

3. 复合索引设计（最左匹配原则）

复合索引需按"查询频率从高到低"排序字段，示例：

高频查询：WHERE user_id = 1 AND order_status = 2
正确索引：idx_user_id_status (user_id, order_status)（先高频字段）
错误索引：idx_status_user_id (order_status, user_id)（违反最左匹配，索引失效）

四、SQL编写规范（核心：高效、安全、可维护）

1. 性能相关规范

禁止SELECT *，只查需要的字段（减少IO、避免字段变更影响）；
禁止大表全表扫描（如WHERE create_time > '2024-01-01'需加索引）；
禁止LIMIT无排序（如SELECT * FROM t_order LIMIT 10，结果无序）；
批量操作：批量插入用INSERT INTO t_user (mobile) VALUES ('13800138000'), ('13800138001')，禁用循环单条插入；
避免JOIN过多表（建议不超过5张），避免子查询嵌套过深（用CTE替代）。

2. 安全相关规范

禁止直接拼接SQL（如SELECT * FROM t_user WHERE mobile = '${mobile}'），必须用预编译（PreparedStatement）防止SQL注入；
禁止超权限查询/修改数据（如普通业务账号禁止DROP TABLE、TRUNCATE）；
禁止在生产环境执行DELETE/UPDATE不加WHERE（必加条件，且先查后删/改）。

3. 可读性规范

SQL关键字大写（如SELECT、WHERE），字段/表名小写，增强区分度；

复杂SQL拆分行，示例：

sql 复制代码

-- 规范写法
SELECT 
    u.user_id,
    u.mobile,
    COUNT(o.order_id) AS order_count
FROM t_user u
LEFT JOIN t_order o ON u.user_id = o.user_id
WHERE u.create_time > '2024-01-01'
GROUP BY u.user_id, u.mobile
HAVING order_count > 0;

五、运维与安全规范

1. 备份规范

核心业务库：每日全量备份 + 实时binlog备份，备份文件保留至少7天；
备份后必须验证（恢复到测试库，确认数据完整）。

2. 权限规范

遵循"最小权限原则"：业务账号仅授予SELECT/INSERT/UPDATE/DELETE，禁止DROP/ALTER；
不同环境（开发/测试/生产）用不同账号，禁止生产账号在开发环境使用。

3. 性能监控

监控慢查询（MySQL开启慢查询日志，阈值设为1秒），定期优化慢SQL；
监控表碎片、索引使用率，定期优化（OPTIMIZE TABLE）。

总结

数据库规范的核心目标是降低维护成本、提升性能、规避风险，关键要点：

命名与注释：统一小写下划线、语义化、全量注释，是可读性的基础；
结构设计：遵循三大范式、字段类型精准、加通用审计字段；
索引与SQL：索引按需创建（遵循最左匹配），SQL避免全表扫描、防止注入；
运维安全：最小权限、定期备份、监控慢查询。

遵循这些规范，能让数据库从"能用"变成"好用、稳定、易扩展"，尤其在团队协作场景中，统一的规范能大幅减少沟通和排障成本。