yyblog2.0 数据库开发规范 mysql中不等于过滤null的问题

1、基础规范

（1）必须使用InnoDB存储引擎

解读：支持事务、行级锁、并发性能更好、CPU及内存缓存页优化使得资源利用率更高

（2）表字符集默认使用utf8，必要时候使用utf8mb4

解读：一、通用，无乱码风险，汉字3字节，英文1字节。二、utf8mb4是utf8的超集，有存储4字节例如表情符号时，使用它

（3）数据表、数据字段必须加入中文注释

解读：N年后谁tm知道这个r1,r2,r3字段是干吗的

（4）禁止使用存储过程、视图、触发器、Event

解读：一、对数据库性能影响较大，互联网业务，能让站点层和服务层干的事情，不要交到数据库层。二、调试，排错，迁移都比较困难，扩展性较差。

再划个重点，高并发大数据的互联网业务，架构设计思路是“解放数据库CPU，将计算转移到服务层”，并发量大的状况下，这些功能极可能将数据库拖死，业务逻辑放到服务层具有更好的扩展性，可以轻易实现“增机器就加性能”。数据库擅长存储与索引，CPU计算仍是上移吧。

（5）禁止存储大文件或者大照片

解读：为什么要让数据库作它不擅长的事情？大文件和照片存储在文件系统，数据库里存URI多好

2、命名规范

（1）库名，表名，列名必须用小写，采用下划线分隔

解读：abc，Abc，ABC都是给本身埋坑

 （2）库名，表名，列名必须见名知义，长度不要超过32字符，禁止拼音英文混用

解读：tmp，wushan谁TM知道这些库是干吗的

（3）表名t_xxx，非惟一索引名idx_xxx，惟一索引名uniq_xxx

（4）SQL语句中关键字大写，并放在单独的行开始

3、表设计规范

（1）单实例表数目必须小于2000个

（2）单表列数目必须小于80个

（3）表必须有主键，推荐使用UNSIGNED整数，禁止使用字符串做为主键

解读：一、主键要选择较短的数据类型， Innodb引擎普通索引都会保存主键的值，较短的数据类型能够有效的减小索引的磁盘空间，提升索引的缓存效率。二、 无主键的表删除，在row模式的主从架构，会致使备库夯住

（4）禁止使用外键，若是有外键完整性约束，须要应用程序控制

解读：外键会致使表与表之间耦合，update与delete操做都会涉及相关联的表，十分影响sql 的性能，甚至会形成死锁。高并发状况下容易形成数据库性能，互联网业务场景数据库使用以性能优先

（5）建议将大字段，访问频度低的字段拆分到单独的表中存储，分离冷热数据

4、字段设计规范

（1）根据业务区分使用tinyint/int/bigint，分别会占用1/4/8字节

（2）根据业务区分使用char/varchar

解读：一、字段长度固定，或者长度近似的业务场景，适合使用char，可以减小碎片，查询性能高。二、字段长度相差较大，或者更新较少的业务场景，适合使用varchar，可以减小空间

（3）必须把字段定义为NOT NULL并设默认值

解读：一、NULL的列使用索引，索引统计，值都更加复杂，MySQL更难优化 二、NULL须要更多的存储空间 三、NULL只能采用IS NULL或者IS NOT NULL，而在=/!=/in/not in时有大坑，参见我以前写的：mysql中不等于过滤null的问题

（4）禁止使用double存储货币,推荐decimal

解读：你就不担忧钱对不上吗

（5）使用varchar(20)存储手机号，不要使用整数

解读：一、牵扯到国家代号，可能出现+/-/()等字符，例如+86。  二、手机号不会用来作数学运算。三、varchar能够模糊查询，例如like ‘138%’

5、索引设计规范

（1）单表索引建议控制在5个之内

（2）禁止在更新十分频繁、区分度不高的属性上创建索引

解读：一、更新会变动B+树，更新频繁的字段创建索引会大大下降数据库性能。二、“性别”这种区分度不大的属性，创建索引是没有什么意义的，不能有效过滤数据，性能与全表扫描相似。通常来讲，同值的数据超过表的百分之十五，那就不必建索引了

（3）创建组合索引，必须把区分度高的字段放在前面

解读：理解组合索引最左前缀原则，避免重复建设索引，若是创建了(a,b,c)，至关于创建了(a), (a,b), (a,b,c)

6、SQL使用规范

（1）禁止使用SELECT *，只获取必要的字段

解读：一、读取不须要的列会增长cpu/io/内存/带宽的消耗。二、指定字段能有效利用索引覆盖。三、指定字段查询，在表结构变动时，能保证对应用程序无影响

（2）禁止使用INSERT INTO t_xxx VALUES(xxx)，必须显示指定插入的列属性

解读：容易在增长或者删除字段后出现程序BUG

（3）禁止使用属性隐式转换

解读：SELECT uid FROM t_user WHERE phone=13812345678 会致使全表扫描，而不能命中phone索引。这里应当对13812345678 加上单引号'13812345678 '。实际工做中类型字段的隐式转换是最多的，须要特别注意。

（4）禁止在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')

（5）禁止负向查询，以及%开头的模糊查询

解读：一、负向查询条件：NOT、!=、<>、!<、!>、NOT IN、NOT LIKE等，会致使全表扫描。二、%开头的模糊查询，会致使全表扫描，注意像'138%'也是会使用索引的。

（6）禁止大表使用JOIN查询，禁止大表使用子查询

解读：会产生临时表，消耗较多内存与CPU，极大影响数据库性能

（7）禁止使用OR条件，必须改成IN查询，IN的值必须少于50个

解读：旧版本Mysql的OR查询是不能命中索引的，即便能命中索引，为什么要让数据库耗费更多的CPU帮助实施查询优化呢？

（8）多表链接必须使用JOIN，LEFT JOIN，禁止使用FROM tab1,tab2

解读：都能实现关联查询，可是使用join更加灵活，效率更高。同时使用join会突出主表的存在，方便在mybaits等框架中快速定位sql位置。sql必须放在主表的xml中，便于重用。

结语：本规范将做为yyblog2.0数据库的开发要求，后续会不断更新。

yyblog1.0项目地址：https://github.com/allanzhuo/yyblog 欢迎star关注yyblog项目。

参考：架构师之路