最近都没什么时间来写比克，工做太忙......
不过这也不是什么借口。
最近在学习相关知识，写下来记录一下吧。
注意：
这里的规范并不是绝对的，如果你的团队已经制定了规范。
请按照团队规范来实行。
如果没有，请尽量遵循基本规范。并推动制定规范。
数据库设计规范:
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：尽量少使用外键
不建议使用外键约束,在使用外键约束时，会影响 父/子 的写性能。
推荐使用索引
字段设计规范
选择合适的字段类型会很大程度上提高整体性能
-- 优先选择符合存储需要的最小数据类型
-- 字符转化为数字类型存储
-- 对无符号数据采用无符号存储【省一倍空间】
-- 避免 TEXT 这种数据类型
-- 建议分离到单独的表中
-- 建议把所有列定义为 NOT NULL
-- 运算时会进行特别处理
-- 不建议储存时间类型为字符串，浪费
-- 建议使用 DATAETIME/TIMESTAMP 储存
-- 财务相关的，必须使用decial精确浮点类型
-- 计算不丢失精度
-- 可以保存比bigint更大的整数数据
-- sql 规范
-- 预编译优点
只传参数，跟高效
防范注入，一次解析，多次使用
-- 避免隐式转换
-- 可能导致索引失效
-- select * from user where id = ‘1‘;
-- 避免使用 %%/%*使用查询条件
-- 禁止跨库查询，连接不同数据库，使用不同账号
-- 为数据库迁移和分库分表留出余地
-- 避免权限过大导风险
-- 禁止 select *
-- 无用数据
-- 无法使用覆盖索引
-- 禁止使用不含字段列表的insert
-- ? inster into t values(‘a‘bc)
-- 避免表结构影响
-- 禁止使用子查询
-- 修改为 join
-- 子查询结果集不能使用索引
-- 临时表消耗IO/CPU
-- 避免 join 关联过多表
-- 多关联一个表，多耗一份内存
-- 最多61 建议不超过5个
原文地址：https://www.cnblogs.com/25-lH/p/9153958.html