随手写的，以命名为主（原来想写的是命名规范，结果写超了纲）。

通用规则

1. 原则上只使用小写字母、数字、下划线，并且字母开头。长度尽可能短（不做强制要求）。
2. 采用简练、能够清楚描绘其意义的英语单词（避开数据库关键字、保留字）。
3. 如果使用简称，应该是常用的用法，最好在相关设计文档中说明，比如：约定用户 ID 统一使用 uid 表示，订单 ID 统一使用 oid 表示。
4. 其他没有遵守规范的地方必须在文档中标明。
5. 由于 MySQL 的数据库和表直接对应到文件，所以需要考虑到 OS 的大小写敏感性问题（Windows 的文件系统就不区分大小写），所以所有命名都统一采用小写字母 + 下划线的命名风格（允许使用的字符：a-z0-9_）。
6. 数据库文档生成工具: JSON，Markdown, HTML, DOC, PDF
7. 所有表和字段都应该有备注

数据库

1. 默认采用 utf8mb4 字符集，utf8mb4_general_ci 排序规则。
   部分地方限定 ASCII 字符，可以采用 ascii + ascii_general_ci 或者 latin1 + latin1_general_ci。
2. 读库与写库使用不同地址（IP + 端口），帐号，密码
3. 不同用途使用不同的帐号（可以加 IP 限制）。
4. 帐号名称中可以有所体现（数据库 + 用途 + _r/_w），比如：
   • crm_w 表示 CRM 项目对 CRM 仓库的读帐号，主要用途。
   • crm_stuff_r 表示 CRM 库的一个读帐号，供内部员工使用。
   • crm_backend_w 表示管理后台项目对 CRM 仓库的写帐号。
5. 管理后台上有账户权限的展示
6. 代码扫描工具，应该检查访问权限，SQL 语句
7. 环境：prod, test, dev, query
8. prod: 生产环境
9. test: 测试环境，测试人员功能测试使用
10. dev: 开发环境，开发人员自测使用
11. query: 和 prod 同步，但是不在 prod 集群中，用于内部查询
12. 管理后台上应该有非线上环境的维护工具（自动重建，快速部署）
    test 和 dev 环境可以根据要求自动生成测试数据。
13. 数据脱敏问题

数据表

1. 统一采用英语单词的单数形式
2. 同一个子模块采用相同的前缀，比如：
   auth_user, auth_role, bbs_post, bbs_comment
3. 备份表：bak_原名_日期
4. 临时表：tmp_名称_日期
5. 分表分表：ec_order_000 ~ ec_order_255

字段

xxx_id;
xxx_no;
xxx_num;
xxx_count;
is_xxx;
has_xxx;

id;
name;
content;
status;
remark;

create_time;
create_user;
update_time;
update_user;

gmt_create;
gmt_modified;

is_delete;
version;

1. MyISAM 和 InnoDB/TokuDB
2. 每张表都有一个 id 作为主键
3. id int unsigned NOT NULL AUTO_INCREMENT 四字节，32 位
4. id bigint unsigned NOT NULL AUTO_INCREMENT 八字节，64 位
5. has_xxx, is_xxx, xxx_num
6. create_time, create_user, update_time, update_user
7. 外键（不是 MySQL 的 FK 约束）尽可能采用：表名_id, 可以采用不产生歧义的缩写，比如 user_id 对应 auth_user 的 id 字段。
8. 尽最大可能 NOT NULL
9. Boolean 类型统一使用 bit 类型
10. 其他有固定选项的字段考虑使用 enum 类型
11. 时间使用 datetime 或 timestamp
12. IPv4 可以采用 varchar 或 int
13. 需要用到小数的地方，如果对精度有要求尽可能采用 decimal 类型
14. 如果项目规模达到一定程度，可以在每张表中加入乐观锁字段
15. 部分表可以采用软删除处理: is_delete
    删除时，可以对相关行中的唯一键字段进行变更，比如用户表删除之后用户名字段的处理：用户名约定只能采用字母、数字、下划线，删除时改成 DEL:日期:随机串:原用户名。

索引

1. idx_xxx_yyy, uk_xxx_yyy, pk_xxx_yyy
2. 不要滥用索引，避免太多索引拖累写操作