58届小数据库30漫漫军规解读

军规适用场景:并发量大、数据量大之互联网业务

军规:介绍内容

解读:讲解原因,解读比军规更要

同样、基础专业

(1)必须动InnoDB存储引擎

       
解读:支持工作、行级锁、并作性更好、CPU及内存缓存页优化使得资源利用率还强

(2)必须运用UTF8字符集

        解读:万国码,无需转码,无乱码风险,节省空间

(3)数据表、数据字段必须进入中文注释

        解读:N年晚谁tm知道者r1,r2,r3许段是干嘛的

(4)禁止利用存储过程、视图、触发器、Event

       
解读:高并发大数据的互联网业务,架构设计思路是“解放数据库CPU,将计转移到服务层”,并发量大之情状下,这些作用非常可能拿数据库拖死,业务逻辑放到服务层具备更好的扩展性,能够随意实现“增机器便加性能”。数据库擅长存储和索引,CPU计算还是提高吧

(5)禁止存储大文件或者深照片

       
解读:为何要受数据库做她不擅长的事务?大文件和像存储于文件系统,数据库里存URI多好

其次、命名规范

(6)只同意采取外网域名,而休是ip连接数据库

(7)线及环境、开发环境、测试环境数据库内网域名以命名规范

         业务名称:xxx

         线上环境:dj.xxx.db

         开发条件:dj.xxx.rdb

         测试环境:dj.xxx.tdb

         从仓库在称呼后加-s标识,备库在名称后加-ss标识

         线上从库:dj.xxx-s.db

         线上备库:dj.xxx-sss.db

(8)库名、表名、字段名:小写,下划线风格,不跳32个字符,必须见称知意,禁止拼音英文混用

(9)表名t_xxx,非唯一索引名idx_xxx,唯一索引名uniq_xxx

其三、表设计规范

(10)单实例表数目必须低于500

(11)单表列数目必须低于30

(12)表要有主键,例如自增主键

  解读:

         
 a)主键递增,数据实施写副好增长插入性能,可以免page分裂,减少表碎片提升空间以及内存的采取

           b)主键要挑选比较短的数据类型,
Innodb引擎普通索引都见面保留主键的价,较短的数据类型可以中的减索引的磁盘空间,提高索引的休养存效率

           c)无主键的表删除,在row模式的中心架构,会招致备库夯住

(13)禁止行使外键,如果生外键完整性约束,需要应用程序控制

 
 解读:外键会导致表与发明中耦合,update与delete操作都见面干彼此关联的发明,十分震慑sql
的性能,甚至会见导致死锁。高并发情况下爱导致数据库性能,大数量高并发业务场景数据库使用以性优先

季、字段设计规范

(14)必须把字段定义也NOT NULL并且提供默认值

   解读:

         
a)null的列使索引/索引统计/值比较还愈复杂,对MySQL来说还难以优化

          b)null
这种类型MySQL内部用开展非常规处理,增加数据库处理记录之复杂;同等条件下,表中有比多空字段的时光,数据库的拍卖性能会降很多

         
c)null值需要重多之仓储空,无论是表要索引中每行中的null的列都需要格外的空间来标识

          d)对null 的拍卖上,只能采用is null或is not
null,而不可知使用=、in、<、<>、!=、not in这些操作符号。如:where
name!=’shenjian’,如果是name为null值的笔录,查询结果就不见面含有name为null值的笔录

(15)禁止使用TEXT、BLOB类型

 
解读:会浪费更多之磁盘和内存空间,非必不可少之恢宏之充分字段查询会淘汰掉热数据,导致内存命中率急剧下挫,影响数据库性能

(16)禁止使用小数存储货币

  解读:使用整数吧,小数容易造成钱对无达

(17)必须采用varchar(20)存储手机号

  解读:

        a)涉及到区号或者国家代号,可能出现+-()

        b)手机号会失掉举行数学运算么?

        c)varchar可以支持模糊查询,例如:like“138%”

(18)禁止使用ENUM,可运TINYINT代替

  解读:

        a)增加新的ENUM值要开DDL操作

        b)ENUM的里边实际存储就是整数,你当自己定义的凡字符串?

五、索引设计规范

(19)单表索引建议控制在5单里面

(20)单索引字段往往不允超过5个

  解读:字段超过5只时,实际已起无交中过滤数据的企图了

(21)禁止在更新非常勤、区分度不强之性质上起目录

  解读:

        a)更新会变更B+树,更新往往的字段建立索引会大大降低数据库性能

       
b)“性别”这种分度无特别之性质,建立目录是不曾什么意思之,不克管用过滤数据,性能及全表扫描类似

(22)建立整合索引,必须将区分度高之字段放在面前

  解读:能够更加管用的过滤数据

六、SQL使用正式

(23)禁止行使SELECT *,只获必要之字段,需要展示说明列属性

  解读:

        a)读博不需要的列会增加CPU、IO、NET消耗

        b)不可知行的用覆盖索引

        c)使用SELECT *好当大增或者去除字段后出现程序BUG

(24)禁止采取INSERT INTO t_xxx
VALUES(xxx),必须出示指定插入的列属性

  解读:容易当多还是去除字段后出现程序BUG

(25)禁止用性能隐式转换

  解读:SELECT uid FROM t_user WHERE phone=13812345678
会招全表扫描,而未能够命中phone索引,猜猜为什么?(这个线上问题频频出现过一样糟)

(26)禁止以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’)

(27)禁止负向查询,以及%开头的混淆查询

  解读:

        a)负向查询条件:NOT、!=、<>、!<、!>、NOT IN、NOT
LIKE等,会导致全表扫描

        b)%起来的歪曲查询,会招全表扫描

(28)禁止大表使用JOIN查询,禁止大表使用子查询

  解读:会生临时表,消耗比较多内存和CPU,极大影响数据库性能

(29)禁止用OR条件,必须转也IN查询

 
解读:旧本子Mysql的OR查询是无可知命中索引的,即使能命中索引,为何要受数据库耗费更多之CPU帮助实施查询优化呢?

(30)应用程序必须捕获SQL异常,并出相应处理

 
总结:大数据量高并发的互联网业务,极大震慑数据库性能的还非受用,不受用什么。

网站地图xml地图