目录
基础规范
命名规范
表设计规范
基础规范
- 使用InnoDB存储引擎
解读：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高
- 使用UTF8字符集
解读：字符集踩过的坑很多，为了通用性统一utf8。（如果有eimjo表情使用utf8mb4)
- 数据表、数据字段加入中文注释
解读：便于后序维护，数据分析
命名规范
- 库名、表名、字段名：小写，下划线风格
解读：
MySQL有配置参数lower_case_table_names=1，即库表名以小写存储，大小写不敏感。如果是0，则库表名以实际情况存储，大小写敏感；如果是2，以实际情况存储，但以小写比较。
如果大小写混合使用，可能存在abc，Abc，ABC等多个表共存，容易导致混乱。
字段名显示区分大小写，但实际使⽤时不区分，即不可以建立两个名字一样但大小写不一样的字段。
- 库名、表名、字段名不超过32个字符，需见名知意
解读：库名、表名、字段名支持最多64个字符，但为了统一规范、易于辨识以及减少传输量，禁止超过32个字符
普通索引以idx_col1_col2命名，唯一索引以uniq_ col1_col2命名
视图以view_开头，事件以event_开头，触发器以trig_开头，存储过程以proc_开头，函数以func_开头
临时库、表名须以tmp加日期为后缀 如xx_bak20160425
按日期时间分表须符合_YYYY[MM][DD]格式
表设计规范
- 表必须定义主键，默认为ID，整型自增
解读：
a）主键递增，数据行写入可以提高插入性能，可以避免page分裂，减少表碎片提升空间和内存的使用
b）主键要选择较短的数据类型， Innodb引擎普通索引都会保存主键的值，较短的数据类型可以有效的减少索引的磁盘空间，提高索引的缓存效率
c） 无主键的表删除，在row模式的主从架构，会导致备库夯住
- 不使用外键，如果有外键完整性约束，需要应用程序控制,关联别的表的“外键”均使用xxx_id的方式来表明
解读：外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql 的性能，甚至会造成死锁。高并发情况下容易造成数据库性能，大数据高并发业务场景数据库使用以性能优先
- 表必须包含以下字段：
1
2
3
4
5字段:类型:说明
create_date:datetime:创建时间
create_user:创建人:
update_date:datetime:修改时间
update_user:修改人:
解读：一般通用性字段
参考：