MySQL数据库表设计规范

数据库命名规范

1. 采用26个英文字母（区分大小写）和0-9的自然数（经常不需要）加下划线‘_’组成；
2. 命名简洁明确（长度不能超过30个字符）；例如:user,stat,log,也可以wifi_user,wifi_stat,wifi_log给数据库加个前缀；
3. 除非是备份数据库可以加0-9的自然数：user_db_20181112；

数据表命名规范

1. 采用26个英文字母（区分大小写）和0-9的自然数（经常不需要）加下划线‘_’组成；
2. 全部小写命名，禁止出现大写；
3. 禁止使用数据库关键字，如：name，time，datetime，password等；
4. 命名简洁明确,多个单词用下划线'_'分隔；例如：user_login，user_profile，user_detail，user_role，user_role_relation，user_role_right，user_role_right_relation；
5. 表前缀user_可以有效的把相同关系的表显示在一起；
6. 用单数形式表示名称，例如：使用employee而不是employees；
7. 表必须填写描述信息（使用SQL语句建表时）

数据库表字段命名规范

1. 采用26个英文字母（区分大小写）和0-9的自然数（经常不需要）加下划线‘_’组成，禁止拼音英文混用；
2. 命名简洁明确,多个单词用下划线'_'分隔；例如：user_login表字段user_id,user_name,email,status,mobile,add_time;
3. 每个表中必须有自增主键；
4. 表与表之间的相关联的字段名称要求尽可能的相同；
5. 每个字段必须加入中文注释；

数据库表字段类型规范

1. 用尽量少的存储空间来存储一个字段的数据；例如：能使用int就不要使用varchar、char，能用varchar(16)就不要使用varchar(255)；默认情况下，InnoDB引擎单一字段索引的长度最大为767字节，当使用UTF-8字符集，每一个字符使用3字节存储，在text或者varchar类型的字段上建立一个超过255字符数的索引时会遇到问题。
2. 变长字段使用varchar，不要使用char，varchar的长度只分配真正需要的空间；注意varchar（M）里的M指的是字符数不是字节数
3. IP地址最好使用int类型；
4. 固定长度的类型最好使用char，例如：邮编；
5. 能使用tinyint就不要使用smallint，int；
6. 最好给每个字段一个默认值，最好不能为空，null字段很难查询优化且占用额外索引空间null字段的复合索引无效。
7. 经常需要计算和排序等消耗CPU的字段，应该尽量选择更为迅速的字段，如用timestamp(4个字节，最小值1970-01-01 00:00:00)代替Datetime(8个字节，最小值1001-01-01 00:00：00)，通过整型代替浮点型和字符型；
8. Datatime存储范围比timestamp大很多，timestamp只能存储到2038年；
9. 对于二进制多媒体数据，流水队列数据（如日志），超大文本数据不要放在数据库字段中；
10. 并不需要一定遵守范式理论，适度的冗余，让Query尽量减少Join;
11. 必须使用varchar(20)存储手机号。涉及到区号或者国家代号，可能出现+-()，varchar可以支持模糊查询，例如：like“138%”；
12. 字段类型在满足条件下越小越好，使用UNSIGNED存储非负整数，实际使用时候存储负数场景不多；
13. 使用OECIMAL存储精确浮点数，用float有的时候会有问题；

数据库表索引规范

1. 命名简洁明确，例如：user_login表user_name字段的索引应为user_name_index唯一索引；
2. 为每个表创建一个主键索引；
3. 业务需要的相关索引是根据实际的设计所构造sql语句的where条件来确定，业务不需要的不要建索引，不允许在联合索引（或主键）中存在多余的字段。特别是该字段根本不会在条件语句中出现。
4. 单表索引建议控制在5个以内；
5. 单索引字段数不允许超过5个；字段超过5个时，实际已经起不到有效过滤数据的作用了；
6. 禁止在更新十分频繁、区分度步不高的属性上建立索引；更新会变更B+树，更新频繁的字段建立索引会大大降低数据库性能；“性别”这种区分度不大的属性，建立索引是没有什么意义的，不能有效过滤数据，性能与全表扫描类似；
7. 建立组合索引，必须把区分度高的字段放在前面，能够更加有效的过滤数据；

其他规范

1. 使用默认的InnoDB存储引擎。InnoDB存储引擎支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高；
2. 存储过程、视图、触发器、Event。高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的情况下，这些功能可能将数据拖死，业务逻辑放到服务层具备更好的扩展性，能够轻易实现“增机器就加性能”。数据库擅长存储和索引，CPU计算上移好；
3. 禁止存储大文件或者大照片。大文件和照片存储在文件系统，数据库里存URL路劲；
4. 外键会导致表与表之间耦合，update与delete操作都会涉及相关联的表，十分影响sql的性能，甚至会造成死锁。
5. 字段定义为NOT NULL并且提供默认值。Null的列使索引、索引统计、值比较都更加复杂，对MySQL来说更难优化；null 这种类型MySQL内部需要进行特殊处理，增加数据库处理记录的复杂性；同等条件下，表中有较多空字段的时候，数据库的处理性能会降低很多；null值需要更多的存储空，无论是表还是索引中每行中的null的列都需要额外的空间来标识；对null 的处理时候，只能采用is null或is not null，而不能采用=、in、<、<>、!=、not in这些操作符号。如：where name!=’shenjian’，如果存在name为null值的记录，查询结果就不会包含name为null值的记录；
6. 禁止使用小数存储货币。小数容易导致钱数对不上；

SQL使用规范

1. 禁止使用SELECT *，只获取必要的字段，需要显示说明列属性；读取不需要的列会增加CPU、IO、NET消耗；不能有效的利用覆盖索引（索引包含所有需要查询的字段的值）；使用SELECT*容易在增加或者删除字段后出现程序bug;
2. 禁止使用INSERT INTO t_xxx VALUES（xxx）,必须显示指定插入的列属性，容易在增加或者删除字段后出现程序BUG；
3. 应用程序必须捕获SQL异常，并有相应处理；
4. 负向查询条件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会导致全表扫描；%开头的模糊查询，会导致全表扫描；
5. 禁止在WHERE条件的属性上使用函数或者表达式，SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15' 会导致全表扫描，正确的写法是：SELECT uid FROM t_user WHERE day>= unix_timestamp('2017-02-15 00:00:00')；
6. SELECT uid FROM t_user WHERE phone=13812345678 会导致全表扫描，而不能命中phone索引；phone是varchar类型，SQL语句带入的是整形，故不会命中索引，加个引号就好了：SELECT uid FROM t_user WHERE phone=’13812345678’；