基础规范
- 使用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 的性能,甚至会造成死锁。高并发情况下容易造成数据库性能,大数据高并发业务场景数据库使用以性能优先
- 表必须包含以下字段:
字段:类型:说明
create_date:datetime:创建时间
create_user:创建人:
update_date:datetime:修改时间
update_user:修改人:
解读:一般通用性字段
参考: