在阿里云开发者社区看到了一篇关于mysql标准规范的文章，觉得对于后续做业务时数据库的使用有一定的指导作用，于是转载一下，以下是正文。
基础规范
-
1 表存储引擎必须使用InnoDB,表字符集默认使用utf8，必要时候使用utf8mb4
解读：
（1）通用，无乱码风险，汉字3字节，英文1字节
（2）utf8mb4是utf8的超集，有存储4字节例如表情符号时，使用它 -
2 禁止使用存储过程，视图，触发器，Event
解读：
（1）对数据库性能影响较大，互联网业务，能让站点层和服务层干的事情，不要交到数据库层
（2）调试，排错，迁移都比较困难，扩展性较差，禁止在数据库中存储大文件，例如照片，可以将大文件存储在对象存储系统，数据库中存储路径 -
3 禁止在线上环境做数据库压力测试
-
4 测试，开发，线上数据库环境必须隔离
命名规范
-
1 库名，表名，列名必须用小写，采用下划线分隔
解读：abc，Abc，ABC都是给自己埋坑 -
2 库名，表名，列名必须见名知义，长度不要超过32字符
解读：tmp，wushan谁TM知道这些库是干嘛的 -
3 库备份必须以bak为前缀，以日期为后缀，从库必须以-s为后缀，备库必须以-ss为后缀
说明：MySQL 在 Windows 下不区分大小写，但在 Linux 下默认是区分大小写。因此，数据库名、表名、字段名，都不允许出现任何大写字母，避免节外生枝
三、表设计规范
-
1 单实例表个数必须控制在2000个以内，单表分表个数必须控制在1024个以内
表必须有主键，推荐使用UNSIGNED整数为主键潜在坑：删除无主键的表，如果是row模式的主从架构，从库会挂住 -
2 禁止使用外键，如果要保证完整性，应由应用程式实现
解读：外键使得表之间相互耦合，影响update/delete等SQL性能，有可能造成死锁，高并发情况下容易成为数据库瓶颈 -
3 建议将大字段，访问频度低的字段拆分到单独的表中存储，分离冷热数据
四、列设计规范
-
1 根据业务区分使用tinyint/int/bigint，分别会占用1/4/8字节，根据业务区分使用char/varchar
解读：
（1）字段长度固定，或者长度近似的业务场景，适合使用char，能够减少碎片，查询性能高
（2）字段长度相差较大，或者更新较少的业务场景，适合使用varchar，能够减少空间 -
2 根据业务区分使用datetime/timestamp
解读：前者占用5个字节，后者占用4个字节，存储年使用YEAR，存储日期使用DATE，存储时间使用datetime -
3 必须把字段定义为NOT NULL并设默认值
解读：
（1）NULL的列使用索引，索引统计，值都更加复杂，MySQL更难优化
（2）NULL需要更多的存储空间
（3）NULL只能采用IS NULL或者IS NOT NULL，而在=/!=/in/not in时有大坑 -
4 使用INT UNSIGNED存储IPv4，不要用char(15),使用varchar(20)存储手机号，不要使用整数
解读：
（1）牵扯到国家代号，可能出现+/-/()等字符，例如+86
（2）手机号不会用来做数学运算
（3）varchar可以模糊查询，例如like ‘138%’ -
5 使用TINYINT来代替ENUM
解读：ENUM增加新值要进行DDL操作
五、索引规范
唯一索引使用uniq_[字段名]来命名，非唯一索引使用idx_[字段名]来命名,单张表索引数量建议控制在5个以内
解读：
（1）互联网高并发业务，太多索引会影响写性能
（2）生成执行计划时，如果索引太多，会降低性能，并可能导致MySQL选择不到最优索引
（3）异常复杂的查询需求，可以选择ES等更为适合的方式存储组合索引字段数不建议超过5个
解读：如果5个字段还不能极大缩小row范围，八成是设计有问题,不建议在频繁更新的字段上建立索引非必要不要进行JOIN查询，如果要进行JOIN查询，被JOIN的字段必须类型相同，并建立索引
解读：踩过因为JOIN字段类型不一致，而导致全表扫描的坑么？
理解组合索引最左前缀原则，避免重复建设索引，如果建立了(a,b,c)，相当于建立了(a), (a,b), (a,b,c)
SQL规范
禁止使用select *，只获取必要字段
解读：
（1）select *会增加cpu/io/内存/带宽的消耗
（2）指定字段能有效利用索引覆盖
（3）指定字段查询，在表结构变更时，能保证对应用程序无影响
insert必须指定字段，禁止使用insert into T values()
解读：指定字段插入，在表结构变更时，能保证对应用程序无影响
隐式类型转换会使索引失效，导致全表扫描
-
禁止在where条件列使用函数或者表达式
解读：导致不能命中索引，全表扫描 -
禁止负向查询以及%开头的模糊查询
解读：导致不能命中索引，全表扫描
-
禁止大表JOIN和子查询，同一个字段上的OR必须改写问IN，IN的值必须少于50个
-
应用程序必须捕获SQL异常
解读：方便定位线上问题
MySQL主要的数据类型和用途
数据类型是定义列中可以存储什么数据以及该数据实际怎样存储的基本规则
🔥在设计表时，应该特别重视所用的数据类型。使用错误的数据类型可能会严重地影响应用程序的功能和性能。🔥更改包含数据的列不是一件小事（而且这样做可能会导致数据丢失）
串数据类型
| 数据类型 | 说明 |
|---|---|
| CHAR | 1～255个字符的定长串。它的长度必须在创建时指定，否则MySQL假定为CHAR(1) |
参照mysql必知必会书籍
扩展
使用EXPLAIN语句让MySQL解释它将如何执行一条SELECT语句
实用EXPLAIN模拟优化器执行，是执行计划的一个可视化体现
虽然 explain返回的结果项很多，这里我们只关注三种，分别是type，key，rows。其中key表明的是这次查找中所用到的索引，rows是指这次查找数据所扫描的行数（这里可以先这样理解，但实际上是内循环的次数）。而type则是本文要详细记录的连接类型
type=all 这便是所谓的"全表扫描"
📣mysql5.7中type的类型达到了14种之多，这里只记录和理解最重要且经常遇见的六种类型，它们分别是all(全表扫描),index(按索引次序全表扫描),range(范围扫描),ref(索引访问),eq_ref(索引查找)，const📣
这种是const的情况
高性能mysql第三版中有明确对explain的说明
📖🚩范式和反范式🚩
-
第一范式
第一范式的目标是确保每列的原子性:如果每列都是不可再分的最小数据单元（也称为最小的原子单元），则满足第一范式（1NF） -
第二范式((确保表中的每列都和主键相关))
首先满足第一范式，第二范式需要确保数据库表中的每一列都和主键相关，而不能只与主键的某一部分相关，第二范式要求每个表只描述一件事情 -
第三范式(确保每列都和主键列直接相关,而不是间接相关)
第三范式需要确保数据表中的每一列数据都和主键直接相关，而不能间接相关
评论区