（2.15）Mysql之SQL基础——开发设计最佳规范

关键字：mysql三大范式，mysql sql开发规范

分析：

　　show profile、mysqllsla、mysqldrmpslow、explain

　　show slow log;　　show processlist;　　show query_response_time(percona);

1、数据库三大范式

（https://baijiahao.baidu.com/s?id=1591955163343123446&wfr=spider&for=pc）

设计良好结构的数据库，可以有效减小数据冗余，减少增删改中出现的问题。深入理解数据库设计的三范式，对于设计“健壮的数据库“十分有必要。数据库三范式是设计数据库 时参考的准则，接下来我们一一进行介绍：
 
一、数据库第一范式：
 
数据库表的每一列都是不可分割的基本数据项，同一列中不能有多个值，即实体中的某个属性不能有多个值或者不能有重复的属性。（保持数据的原子性）
 
数据原子性很好理解，就是表中的字段不可再分。符合数据库第一范式的表，每个字段表意明确，看个例子：
 
这是一张简单的员工信息表，其中有工号、姓名、电话三个字段。通过电话这个字段获得的信息有可能是家庭电话，或是工作地点的电话，或是手机，因此表达的信息并不明确，我们可以改成这样：
 
那这样改完以后，表中所表达的信息就非常明确了。
 
二、数据库第二范式：
 
在满足第一范式的基础上，实体的每个非主键属性完全函数依赖于主键属性（消除部分依赖）
 
主键：凡是接触过数据库的人，肯定都会知道主键，主键明确标识了每条记录，一般是一个字段，也可以由两个或两个字段组成。
 
依赖：对于X的每个值，Y都有一个值与之对应，反过来则不一定不成立，这叫做X函数决定Y，Y函数依赖X（X往往是主键）。
 
还拿上面的那张表举来说，对于每个工号，都有一个姓名与之对应，即工号决定姓名，姓名依赖工号；但由于员工之间可能有重名，一个姓名可能对应多个工号，所以姓名不能决定工号。
 
部分依赖：当主键由两个或两个以上字段构成，而表中的某些信息通过主键的一个字段就能唯一确定，我们称这样的依赖关系为部分依赖，比如这个例子：
 
学生选课（学号，姓名，专业，课程号，课程名，成绩），该表中一个学生可以选多门课，一门课有多个学生。学号和课程号可以唯一确定一条记录，因此用学号和课程号做主键。
 
表中的姓名、专业通过主键中的学号就能唯一确定，而课程名通过课程号唯一确定，这就是部分依赖，这样的设计不符合第二范式。
 
不符合第二范式会带来哪些问题呢？
 
1、数据信息冗余，可见上表
 
2、增删改会出现问题，比如有一门《微机原理》没有人选，那么由于缺少学号（主键之一）那么这门课就不能出现在表里。
 
如何解决呢，我们可以用关系分解的方法消除部分依赖，将上表改成如下三张表：
 
三、数据库第三范式：
 
在满足第二范式的基础上，在实体中不存在非主键属性传递函数依赖于主键属性。（表中字段[非主键]不存在对主键的传递依赖）
 
传递依赖：A依赖于B，B依赖于C，就可以说A依赖C。看这样一张表：
 
这张表中有如下决定关系： 学号-->姓名，性别，系号-->决定系名，宿舍号-->决定宿舍电话，也有 学号-->系名，学号-->宿舍电话。
 
在这样一张表中则存在着传递依赖。也就是系名依赖系号，系号依赖学号，那么间接的系名依赖学号，宿舍号、宿舍电话和学号之间也有同样的关系。这样设计表的同样会带来数据冗余，操作异常等问题。那么我们同样可以用关系分解的分解的方法来消除传递依赖，将这张表分成三张表：
 
这就是数据可设计的三范式了，在设计数据表的过程中注意三范式的应用，多多实践，有助于对三范式有更深入的理解。

数据库三大范式

2、生产环境的基础规范

（2.1）、必须使用innodb存储引擎

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

（2.2）、必须使用UTF8字符集，新建库建议默认使用UTF8mb4字符。

　　UTF8mb4是UTF8的超集，emoji表情及部分不常见汉字在utf8下会表现为乱码；使用UFT8mb4是标准的万国码，无需转码，无乱码风险，但不节省空间。

　　gbk ：1个字符占用2个字节　　UTF8：一个字符占3个字节　　UTF8mb4：一个字符占用4个字节

（2.3）、数据表、数据字段尽量写入中文注释

（2.4）、高并发架构下，尽量不使用存储过程、视图、触发器、event：因为并发量大的情况下，可能会严重影响DB服务器的性能。

（2.5）、尽量不要存储大文件或者大照片：让数据库里村URL和索引即可。

3、命名规范

（3.1）尽量使用内网域名，而不是IP连接数据库

　　针对互联网行业数据库，包括缓存（memcache、redis）的链接，服务（service）的链接都必须使用内网域名，机器迁移/平滑升级/运维管理，非常方便；

（3.2）见名知意库名表名字段名，库名、表名、字段名最好使用小写，下划线风格，不超过32个字符，不要中英混拼；

4、表设计规范

（4.1）单实例表数目必须小于500

（4.2）单表列数目必须小于30

（4.3）表最好有主键，例如自增主键

　　【1】主键递增可以提高插入性能，避免页分裂

　　【2】主键尽可能选择较短的数据类型，节约空间，提高索引缓存效率

　　【3】无主件的表删除，在row模式的主从架构，会导致备库挂掉。

（4.4）尽量不要使用外键，如果非要使用外键完整性约束，需要应用程序来控制

　　因为外键会导致表与表之间耦合，删除和更新表数据比较麻烦，高并发下会影响性能甚至死锁。

1  表不能有commnet,字段可以有comment
2  表必须有主键，不能修改已添加表的主键，不能使用auto_increment
3  表除了主键外不能有唯一索引
4  字段不能为空，且必须有默认值    not null + deafult值
5  索引只能使用btree类型
6  数据类型适当（特别是varchar型的，不要太长了）

5、字段设计规范

（5.1）字段尽量不设置为Null

　　【1】Null不走索引　　【2】占更多的存储空间　　【3】三值逻辑问题

（5.2）尽量不使用text/blob类型：占用太多查询热数据，导致缓存命中下降

（5.3）不用要小数存储货币

　　100/3得到3个3.33，然后始终有几分钱不对。最后发现是除法惹的祸。【尽量少的使用除法】

　　解决方案，使用分作为单位存储，这样在数据库里就是整数了。

（5.4）使用varchar(20)存储收集好

（5.5）尽量不用enum，可以使用tinyint代替

6、索引设计规范

（6.1）、单表索引建议控制在5个以内

（6.2）、但索引字段不允许超过5个，超过5个时实际上已经起不到有效过滤数据的效果了

（6.3）、禁止在更新十分频繁，重复度高的字段上建立索引

（6.4）、建立组合索引，把重复度低的字段放在前面

7、SQL使用规范

（7.1）、不建议使用select *

（7.2）、insert into test(column) values(value) ；尽量在insert into values 语句中写好表列名；

（7.3）、不要在字段列上使用隐式转换、函数、表达式等操作

（7.4）、不要用负向查询条件：not　　!=　　<>　!>　　!<　　not in　　not like，不要使用like '%str'　；

8、其他常用规范

【1】禁止大表join查询，禁止大表使用子查询

【2】禁止使用or，可以改为in

【3】应用程序必须捕获SQL异常，并有处理

【4】不要用权限很大的账户连接生成

【5】禁止非DBA人员对数据库进行非读操作

【6】给非DBA人员权限为只读

【7】开发、测试、线上环境隔离

【8】数据计算尽量放在程序

【9】单表记录控制在千万级

【10】三大范式并非绝对，需求》性能》规范

【11】拒绝大SQL，大事务，大批量一次性操作（如一次性修改1亿数据）

9、表结构变更规范

1  表不能有commnet,字段可以有comment
2  表必须有主键，不能修改已添加表的主键，不能使用auto_increment
3  表除了主键外不能有唯一索引
4  字段不能为空，且必须有默认值    not null + deafult值
5  索引只能使用btree类型
6  数据类型适当（特别是varchar型的，不要太长了）
7  不能删除字段，只能添加
   只能在表最后添加字段，不允许在中间部分添加
8  不能 CHANGE 字段
9  不能用 AFTER 加字段