最近都没什么时间来写博客，工做太忙......
不过这也不是什么借口。
最近在学习相关知识，写下来记录一下吧。
注意：
这里的规范并不是绝对的，如果你的团队已经制定了规范。
请按照团队规范来实行。
如果没有，请尽量遵循基本规范。并推动制定规范。
数据库设计规范:
1：数据库名/表名 小写
数据库等于是在 Liunx 上的一个个文件，Linux 是区分大小写的，所以表/库也是如此，为了避免在大小写上引起的错误，尽量使用小写来作为统一规定。
2：不使用mysql关键字
关于这个问题，老生常谈了吧，不使用 mysql 的关键字，也是为了避免错误。
3: 临时表命名规范
在实际工作，不免要创建一些临时表进行工作，而且会有时忘记清理(很大可能).
最后也忘记了那个是临时表，所以需要对临时表的命名做出规范，以便于我们知道那个是临时表。
命名规范为：以tmp为前缀-日期为后缀
例如：tmp_temporary_20180611
3: 备份表命名规范
同上
命名规范为：bak为前缀_日期为后缀
例如：例如：bak_temporary_20180611
4：储存相同数据的列名和类类型必须一致
这里有两张表，一个用户ID，一个文章，文章一个外键是user_id
他们储存的是同种数据，所以在构建时，他们的数据类型等等必须都一致。
如果不一致，Mysql 其实是会在内部进行一个隐式的字符转换，会耗费性能。
5：统一使用innodb
在 mysql5.6 之后，默认引擎已经变为了 Innodb 。
和 innodb 相比，Myisam 的优势已经很小了，而且在混用的时候，Myisam 的工作并不是那么理想。
所以我们在没有特殊场景时候，应该默认使用 Innodb。
它的优势在很多地方都有 支持行锁/实务/高并发下效果更好
6：统一使用uft8
字符集一直是一个比较容易被忽视的地方，实际在任何时候，字符集都是一个比较重要的地方。
混乱的字符集会导致数据的丢失和无法恢复。
于是需要统一字符集，统一使用uft8。
7：表和字符添加注释
注释的意义，不用多言，同时数据表也是需要注释的。
从最开始 对于数据字典的维护 是非常有必要的，可以使后面的同学快速明白字段的意义。
也不会出现公司运转几年之后，拿出一张表，没有一个人能完整说出字段的意义这种窘境。
8： 尽量控制单表数据量大小
之前有人说，mysql的单表最大数是 500万。
关于这个并不是一个准确数字，他和操作系统，位数，等等都有关系。
不过太大，并不是个好事情，对于太大的表
-- 进行历史数据归档
-- 分库分表
9：尽量冷热分离，减少列数
尽量把冷热的数据区分开来,便于使用查询，提高读入效率。
减少表的列数，并不是越多越好， 表列多，在读入时就会消耗更多的内存。
建议经常使用的列放入一个列。
10: 禁止在表中预留字段
在开发中，经常会有预留字段的事情发生，因为可能知道之后需要补充一些字段。
这样感觉也没什么错，但是却造成了极大浪费。
一是由于预留字段无法见名知意，也会使用大字段VARCHAR()来进行存储。
在之后修改字段的话也会进行数据库的锁表，导致一段时间的服务异常。
怎么想都是不合算的，于是在开发时一定要避免这种事情的产生。
11：禁止存文件/图片 等二进制数据
太大，太长，你懂得
12：禁止在线上做压力测试/禁止从开发环境_测试 直接连接数据库
避免脏数据的产生，建议使用专门搭建的测试环境。
索引规范
索引并不是越多越好。
大量的索引会使Mysql优化器在选择时耗费大量的时间。
1: 限制每张表的索引数量
最好不要超过五个,索引不是越多越好，会提高/也会降低索引
禁止给每一列建立索引，并不會獲得很好的效果
2：在哪些列上建立索引？
在 select/update/delete SQL中的 where 条件中建立索引
在 order by / group by 字段上建立索引
3：如何选择索引列顺序（待研究）
区分度最高的列放在联合索引的最左侧
字段长度小的放在联合索引的最左侧
最频繁查询的字段放在联合索引的最左侧
4：尽量少使用外键
不建议使用外键约束,在使用外键约束时，会影响 父/子 的写性能。
推荐使用索引
5：对于频繁查找的字段优先使用覆盖索引
避免 Innodb 二次查找
可以把随机IO 变为顺序 IO 加快效率
字段设计规范
选择合适的字段类型会很大程度上提高整体性能
1：优先选择符合存储需要的最小数据类型
对无符号数据采用无符号存储，比如 INT 类型，储存为无符号数据的话会节省这个字段一半的存储空间。
VARCHAR(N) 中 N 代表的是字符数，而不是字节数。
使用 UTF-8 储存汉字 VARCHAR(255) = 755字节。
过大的长度会消耗更多的内存。
2：避免 TEXT 这种数据类型
text 这种字段的话, 建议分离到单独的表中，和主表在一起的话会极大的耗费性能
3：建议把所有列定义为 NOT NULL
字段为 NULL 时，运算时会进行特别处理。
设置为 NOT NULL 也是对程序的一种保护，防止错误数据的产生。
4：不建议储存时间类型为字符串
mysql 有专门为时间类型使用的字段，使用它们可以更高效。
不建议使用 VARCHAR()/INT() 等存储。
浪费。
建议使用 DATAETIME/TIMESTAMP 储存
TIMESTAMP 占用 4 字节，与 INT 相同，但是比 INT 可读性更高
超出 TIMESTAMP(1970-2038) 范围的，使用 DATAETIME
5：财务相关的，必须使用decial精确浮点类型
-- 计算 不丢失精度
-- 可以保存比bigint更大的整数数据
SQL 规范
1: 避免隐式转换
比如这里有一个字段，`table_id` 是一个 INT 类型的字段，但是我在查询时候使用这样的语句
select * from `table` where id = '1';
在where 子句中，1 变为了字符串成为了查询条件。
这时 MYSQL 等于是在内部又进行了一次隐式的转换，在开发时，我们应该避免这种情况的发生。
它可能会 导致索引失效
2：禁止 select *
搜索到大量无用数据
无法使用覆盖索引
3：禁止使用不含字段列表的insert
比如像这种 INSERT INTO `table_name` values ('a','b','c');
虽然在当时是可以使用的，可是如果之后添加了新字段等等，会导致数据的混乱，所以我们应该禁止这种行为。
4：禁止使用子查询
在子查询时，子查询获得的结果集并不能使用索引。
子查询也是等于会在 mysql 中建立一个临时表来存储这个数据，大量的使用子查询，会导致临时表消耗大量的消耗IO/CPU
建议使用 Join 。
5：避免 join 关联过多表
mysql join 最多可以关联 61 个，但是最好不要超过 5 个。
每次多关联一个表，就会多消耗一份内存。