前言
这是来自一线的实战经验，每一条军规背后都是血淋淋的教训。
核心篇
-
不在数据库做运算
存储过程、函数、触发器、试图、级联删除等数据库功能严禁使用。数据库是用来存取数据的，而不是做业务处理的。数据库做集群的代价远远大于应用服务器。在当前这个互联网时代中软件所需要处理的数据越来越多，请珍惜数据库的资源。 -
控制单表数据量
一年内单表数据量不要超过500W（随着硬件性能提升而提升）；单库不超过50张表，推荐ER图不超过一屏幕，一目了然可以大大提高对数据库结构的理解。 -
控制单表字段数上限在20～50
字段少的好处多多：IO高效、全表遍历快、表修复快、alter table 快、提高开发效率 -
平衡范式与冗余
本库在没有性能瓶颈的情况下不考虑冗余。跨库关键字段必须冗余，实时类数据要保证最终一致性，（在业务判断影响不大的情况下也可以不同步）当出现频繁的同步需求时，往往是库的拆分出问题了，应该考虑调整数据库设计。历史类数据不叫冗余那是尊重历史，如订单中的客户名称、货品名称等。 -
拒绝3B
大SQL、大事务、大批量
字段篇
-
用好数值字段类型
在够用的情况下尽量选择字节数少的类型。
tinyint（1B）、smallint（2B）、mediumint（3B）、int（4B）、bigint（8B）
float（4B）、double（8）
decimal（m，d） -
能用数字不用字符串
数字更高效、查询更快（经验值是20%）、占用空间更小。 -
避免使用null值
在mysql中无法对null进行查询优化，有null值的列加索引需要额外空间，含null的复合索引无效。设计合理的默认值可以规避null的问题，例如 varchar用 emptystring ，数字用0等等。 -
禁止使用text/blob/clob等大字段
这些大字段会强制生成硬盘临时表，浪费空间。在业务需要存储较大内容时，请使用文件服务器存储，在数据库中存储其url地址。 -
不在数据库里存图片
原理同上。
索引篇
-
谨慎合理添加索引
索引可以提高查询的性能，但会减慢更新的速度。所以并不是越多越好，控制在字段数的20%以内。 -
字符字段必须建前缀索引
将整个字符串都加入到索引中，是十分浪费空间的。其实用前若干位已经可以达到很好的效果了，实际用多少位需要根据实际场景判定。这个给大家几个数字作为参考
单字母区分度：26（字母，不考虑大小写）+ 10（数字）= 36（理论值是255，这里我们只考虑常见的）
4字母区分度：36 × 36 × 36 × 36 = 1,679,616（1百多万）
5字母区分度：36 × 36 × 36 × 36 × 36 = 60,466,176（6千万）
6字母区分度：36 × 36 × 36 × 36 × 36 × 36 = 2,176,782,336（20亿） -
不在索引列做运算
索引失效。其实所有列的运算都不推荐，运算应该交给java。 -
主键使用bigint且自增
忌用字符串做主键。 -
禁止使用外键
高并发时容易死锁。使用程序保证约束。
Sql篇
-
尽可能简单
将一条大sql拆成几条小sql执行。一条大sql可能把整个数据库堵死。简单sql缓存命中率更高、减少锁表时间，用上多cpu（一条sql只能在一个cpu运算）。 -
保持事务（链接）短小
事务使用原则：即开即用，用完即关
与事务无关操作放到事务外面，减少锁资源的占用
不破坏一致性前提下，使用多个短事务代替长事务 -
禁止使用
select *
只取需要数据列，减少传输量，减少表变化带来的影响。join时同名列会自动添加后缀影响程序的取数。 -
用union all 而非 union
union 的结果是去重的，这个消耗很大。 -
改写or为in()
or的效率为 O(n)，in的效率为O(Log n)当n很大时，or会慢很多。即便如此也要控制in的个数，建议n小于200。 -
改写or为union
前面的是一个字段多个值的场景，这个是不同字段的场景。注意：这里不能使用union all。 -
避免非逻辑查询和%前缀模糊查询
非逻辑指 not、!=、<>、!<、!>、not exists、not in、not like等。%前缀模糊查询 使用不了索引，导致全表扫描。 -
同数据类型的列值比较
数字对数字，字符对字符。浮点型不推荐比较。主外键必须使用同数据类型（通常是bigint）。不同类型的字段比较时，会消耗类型转换的运算量，并且容易导致索引失效。 -
禁止单词请求中大批量更新
容易出现大事务。在设计层面规避，无法避免时请使用队列控制数据库的压力。 -
explain
使用explain优化sql语句是每个程序员都应该学会的。开发库往往比生成库少很多的数据，一条未经优化的sql上线，可能导致一场灾难。
约定篇
- 隔离线上线下
-
禁止使用子查询
大部分情况很难优化。in 通常是可以改写为join的。 -
禁止在程序端显示加锁
外部锁对数据库不可控。高并发时是灾难。极难调试和排查。 -
统一字符集为UTF-8
校对规则 utf8_general_ci -
统一命名规范
库、表、字段统一使用小写，单词之间使用下划线分隔。
主键：表名关键字id
索引：idx字段名（复合组件则用多个字段名，过长时使用缩写）
避免使用保留字：如 desc 描述的缩写 结果是 排序的关键字。 -
必备字段
每张实体表都需要记录以下字段，并置于字段最后面
create_time
create_user_id
create_user_name
modify_time
modify_user_id
modify_user_name
插入时modify的值同create
关联表不需要记录
固定数据的基础资料不需要记录 -
日期类型统一使用 timestamp
国际物流是有时区问题的。 -
字段顺序
设计表结构时需要按照重要程度自上而下排列，在添加字段时必须严格遵守，不能简单的加载最后面。相关的字段必须排在一起，例如user_id、user_name。 -
可事先约定且有限值的字段使用varchar
虽然常见的做法是int或tinyint，但是在意义表达上不如字符串来的清晰，为了更加便于维护，
