MySQL的20条军规

最近看了比较多关于MYSQL的内容，特别是在性能优化这一块，今天总结下一些数据库中的规范，当然，不都是绝对的，只是一些规范，如果不遵守，MYSQL也是能正常执行语句，数据库也能正常运行。

数据库设计

• 数据库和表的字符集统一使用UTF-8

• 最重要的一点就是国际化，UTF-8包含了几乎所有语言需要的字符，并且Unicode是个不断更新的字符集，UTF-8编码在各个操作系统和语言环境当中的支持是非常好的，UTF-8和其他Unicode编码一样，它到Unicode字符的映射是固定的，所有Unicode进行扩充之后,UTF-8也就自动进行了扩充。
• 兼容ASCLL，UTF-16和UTF-32都有大端小端的问题，只有UTF-8没有。
• 我们最终都是将结果返回给客户端，而对于Web端来说，绝大部分都是以ASCLL字符为主，因此使用UTF-8。
• 兼容前缀码，前缀码能让程序员很方便地用遍历的方法定位一段网络传输过来的字符串中出问题的范围，保持能显示部分最大化。这对那些工作在较差网络环境下时比兼容性重要得多。
• 统一字符集可以避免由于字符集转换产生的乱码，不同的字符集进行比较前需要进行转换会造成索引失效，如果数据库中有存储 emoji 表情的需要，字符集需要采用 utf8mb4 字符集。

• 所有表最好都使用 Innodb 存储引擎

• 如果不需要使用事务，或许使用MYISAM存储引擎性能会好一点，但不推荐，不管是MYSQL5.7还是更低版本的MYSQL，只要有Innodb最好是使用innodb,除非一些特殊的要求Innodb存储引擎不能满足条件（如：列存储、存储空间数据等）的。
• 最好使用innoInnodb存储引擎支持事务、行级锁、更好的恢复性、高并发下性能更好。

• 所有的表和字段都需要添加注释

• 便于从一开始就进行数据的维护
• 如果需要对数据库和表做数据采集那么应该需要明确表和字段的描述

• 不要在表中建立预留字段

• 预留字段的命名很难做到见名识意
• 预留字段不能确认最终的存储的数据类型，所以无法选择适合的类型
• 预留字段如果设置默认值为null,那么是一个无效的字段
• 对预留字段类型的修改，会对表进行锁定

• 禁止在数据库中存储图片，文件等大的二进制数据

  具体做法：一般图片、文件等大的二进制数据应该存放在第三方专门存储大型文件的服务器，比如：阿里云，腾讯云，七牛云等第三方服务器，并且不应该是服务端去上传，应该是前端去上传避免接口的耗时，上传后把文件地址存储在服务端，服务端仅仅只是存储文件地址信息。

• 一般文件都很大，如果存储在数据库中会短时间内造成数据量快速增长，数据库进行数据读取时，会进行大量的随机的IO操作，IO操作很耗时，在这过程中很容易造成连接超时等问题。

• 尽量控制单表数据量的大小，建议控制在500万以内

• 500万并不是MYSQL数据库的限制，只是一种行业普片遵循的规范，比如阿里规定单表数据超过500万就需要分库分表，因为过大的数据会增加修改表结构、备份、恢复表数据的难度，并且存在一些问题隐患。
• 可以将历史数据归档
• 分库分表，应用于业务数据等手段来控制数据量大小

• 谨慎使用MYSQL分区表

  据我了解阿里是不建议MYSQL使用分区表

  MYSQL分区表主要有以下几个问题：

• 分区表在物理上表现为多个文件，在逻辑上表现实际还是一张表
• 分区表如果不走分区键的话，很容易出现全表锁
• 一旦并发量上来，如果在分区表实施关联，那就是一个灾难
• 分区表无论怎么分，说白了还是在同一台服务器上，性能上的瓶颈是可见的
• 谨慎选择分区键，跨分区查询效率可能会很低
• 建议采用物理分表的方式来管理大数据，也就是自己分库分表，这样方便掌控业务场景

• 尽量做到冷热数据分离，减小表的宽度

  MYSQL限制每张表做多存储4096列，并且每一行数据的大小不能超过65535字节

• 减少磁盘IO，保证热数据的内存缓存命中率
• 表越宽，把表装进内存缓冲池所占用的内存也就越大
• 有效利用缓存，避免读入无用的冷数据
• 经常一起使用的列放入到一个表中，避免更多的关联操作

• 禁止在线上做数据库压力测试

• 禁止从开发环境、测试环境直接连生产环境数据库

  上面两点在一些小公司，特别是第二个连接生产环境数据库是有可能发生的，比如调试BUG的时候，当然是在这个项目不涉及利益的条件下可能会出现，这个算是必须要遵守的规范吧。

数据库命令

• 所有数据库字段名称应该是使用小写字母并用下划线分割（这里不要问为什么，没有为什么就是个规范，因为之前有人就这么问过我，啊哈哈）
• 所有的数据库字段名称禁止使用MYSQL的关键字（如果使用到了那么需要用单引号括起来）
• 数据库字段的命名应该要做到顾名思义，并且不要过长，不要超过32个字符
• 所有存储相同数据的列名和列类型必须一致，一般作为关联列，如果查询时关联列类型不一致会自动进行数据类型隐式转换，会造成列上的索引失效，导致查询效率降低
• 临时表在前缀或者后缀上加上tmp随后加上日志,备份表在前缀或者后缀上加上bak随后加上备份日期

数据库字段的设计

• 选择符合存储需要的最小的数据类型

• 无符号相对于有符号可以多出一倍的存储空间

  SIGNED INT -2147483648~2147483647
  UNSIGNED INT 0~4294967295
  

• 列的字段越大，建立索引时所需要的空间就越大，这样一页中所能存储的索引节点数据就越来越少，在遍历时所需要的IO次数也就越多，索引性能也就越差，比如：一个age字段，设置为Int类型就不是太合适，因为age的大小可以预见，应该设置为tinyint

• 尽量将一些字段类型设置成数据类型存储，例如:IP地址

• 对于非负数型的数据（自增ID，整型），有限使用无符号整型来存储

• VARCHAR（N）中的N代表的是字符数，而不是字节数，使用UTF-8存储255个汉字VARCHAR（255）=765个字节，过大的长度会消耗更多的内存。

• 避免使用 TEXT,BLOB 数据类型,TEXT 类型可以存储64k 的数据

• 建议把 BLOB 或是 TEXT 列分离到单独的扩展表中

• MySQL 内存临时表不支持 TEXT、BLOB 这样的大数据类型，如果查询中包含这样的数据，在排序等操 作时，就不能使用内存临时表，必须使用磁盘临时表进行。而且对于这种数据，MySQL 还是要进行二 次查询，会使 sql 性能变得很差，但是不是说一定不能使用这样的数据类型。

• 如果一定要使用，建议把 BLOB 或是 TEXT 列分离到单独的扩展表中，查询时一定不要使用 select * 而 只需要取出必要的列，不需要 TEXT 列的数据时不要对该列进行查询。

• TEXT 或 BLOB 类型只能使用前缀索引,因为MySQL 对索引字段长度是有限制的，所以 TEXT 类型只能使用前缀索引，并且 TEXT 列上是不能有默认值的

• 避免使用 ENUM 类型

• ENUM 类型的 ORDER BY 操作效率低，需要额外操作
• 禁止使用数值来做ENUM的枚举值

• 尽可能把所有列定义为 NOT NULL

  曾经，我接触过很多项目的数据库的很多字段基本设置为null,就图个方便，有的是为了方便前端传参，但是我觉得这是不规范的

• 如果该字段默认值为Null并且又被设置为索引列那么这一列会需要额外的空间来保存，会占用更多的空间
• 进行比较和计算时还需要对NULL值做特殊的处理

• 使用 TIMESTAMP(4 个字节) 或 DATETIME 类型 (8 个字节) 存储时间

  这里需要注意：经常有看到人用字符串来存储日期型的数据，这是不正确的做法，首先，无法用日期函数进行计算和比较，其次用字符串存储日期会占用更多的内存空间。

• TIMESTAMP 存储的时间范围 1970-01-01 00:00:01 ~ 2038-01-19-03:14:07
• TIMESTAMP 占用 4 字节和 INT 相同，但比 INT 可读性高
• 超出 TIMESTAMP 取值范围的使用 DATETIME 类型存储

• 同财务相关的金额类数据必须使用 decimal 类型

  这里需要注意：日常开发中，如果对数据不是特别敏感的数据字段类型，可以使用float就足够了，不是非要用double

• 非精准浮点：float,double
• 精准浮点：decimal
• decimal 类型为精准浮点数，在计算时不会丢失精度
• 占用空间由定义的宽度决定，每 4 个字节可以存储 9 位数字，并且小数点要占用一个字节 可用于存储比 bigint 更大的整型数据

索引设计规范

• 限制每张表上的索引数量,建议单张表索引不超过 5 个

  索引并不是越多越好！索引可以提高效率同样可以降低效率。索引可以增加查询效率，但同样也会降低插入和更新的效率，甚至有些情况下会降低查询效率。因为 MySQL 优化器在选择如何优化查询时，会根据统一信息，对每一个可以用到的索引来进行评估，以生成出一个最好的执行计划，如果同时有很多个索引都可以用于查询，就会增加 MySQL 优化器生成执行计划的时间，同样会降低查询性能。

• 禁止给表中的每一列都建立单独的索引

  MYSQL5.6 版本之前，一个 sql 只能使用到一个表中的一个索引，5.6 以后，虽然有了合并索引的优化方式，但是还是远远没有使用一个联合索引的查询方式好。

• 每个 Innodb 表必须有个主键

  Innodb 是一种索引组织表：数据的存储的逻辑顺序和索引的顺序是相同的。每个表都可以有多个索 引，但是表的存储顺序只能有一种。

• Innodb 是按照主键索引的顺序来组织表的
• 不要使用更新频繁的列作为主键，不适用多列主键（相当于联合索引）
• 不要使用 UUID,MD5,HASH,字符串列作为主键（无法保证数据的顺序增长）
• 主键建议使用自增 ID 值

• 不要在不适合的时候创建索引

• WHERE 条件，GROUP BY，ORDER BY 里用不到的字段，索引的价值是快速定位，如果起不到定位的字段通常是不需要创建索引的
• 字段中存在大量重复数据，不需要创建索引，比如性别字段，只有男女
• 表数据太少的时候，不需要创建索引
• 经常更新的字段不用创建索引，比如电商项目的用户余额，因为索引字段频繁修改，那就意味着需要频繁的重建索引

• 适合索引场景创建索引

• 字段有唯一性限制的，比如商品编码
• 经常用于 GROUP BY 和 ORDER BY 的字段
• 出现在 SELECT、UPDATE、DELETE 语句的 WHERE 从句中的列

• 合理使用索引列，避免索引失效

• 当我们使用左或者左右模糊匹配的时候，也就是 like %xx 或者 like %xx%这两种方式都会造成索引失效
• 当我们在查询条件中对索引列做了计算、函数、类型转换操作，这些情况下索引失效是因为查询过程需要扫描整个索引并回表，代价高于直接全表扫描，所以优化最终选择走全表扫描。
• 联合索引要能正确使用需要遵循最左匹配原则，也就是按照最左优先的方式进行索引的匹配，否则就会导致索引失效
• 在 WHERE 子句中，如果在 OR 前的条件列是索引列，而在 OR 后的条件列不是索引列，那么索引会失效
• 为了更好的利用索引，索引列要设置为 NOT NULL 约束

• 选择正确的索引列的顺序

  建立索引的目的是：希望通过索引进行数据查找，减少随机 IO，增加查询性能 ，索引能过滤出越少的 数据，则从磁盘中读入的数据也就越少。

• 区分度最高的放在联合索引的最左侧（区分度=列中不同值的数量/列的总行数）
• 尽量把字段长度小的列放在联合索引的最左侧（因为字段长度越小，一页能存储的数据量越大， IO 性能也就越好）
• 使用最频繁的列放到联合索引的左侧（这样可以比较少的建立一些索引）

• 避免建立冗余索引和重复索引（增加了查询优化器生成执行计划的时间）

• 重复索引示例：primary key(id)、index(id)、unique index(id)
• 冗余索引示例：index(a,b,c)、index(a,b)、index(a)

• 对于频繁的查询优先考虑使用覆盖索引

• 避免 Innodb 表进行索引的二次查询: Innodb 是以聚集索引的顺序来存储的，对于 Innodb 来 说，二级索引在叶子节点中所保存的是行的主键信息，如果是用二级索引查询数据的话，在查找到 相应的键值后，还要通过主键进行二次查询才能获取我们真实所需要的数据。而在覆盖索引中，二 级索引的键值中可以获取所有的数据，避免了对主键的二次查询 ，减少了 IO 操作，提升了查询效 率。
• 可以把随机 IO 变成顺序 IO 加快查询效率: 由于覆盖索引是按键值的顺序存储的，对于 IO 密集型 的范围查找来说，对比随机从磁盘读取每一行的数据 IO 要少的多，因此利用覆盖索引在访问时也 可以把磁盘的随机读取的 IO 转变成索引查找的顺序 IO。

• 索引 SET 规范

  这里需要注意：一般项目中都会尽量去避免使用外键，因为MYSQL的性能会很差

• 不建议使用外键约束（foreign key），但一定要在表与表之间的关联键上建立索引
• 外键可用于保证数据的参照完整性，但建议在业务端实现
• 外键会影响父表和子表的写操作从而降低性能

数据库 SQL 开发规范

• 建议使用预编译语句进行数据库操作

• 预编译语句可以重复使用这些计划，减少 SQL 编译所需要的时间，还可以解决动态 SQL 所带来的 SQL 注入的问题
• 只传参数，比传递 SQL 语句更高效
• 相同语句可以一次解析，多次使用，提高处理效率

• 避免数据类型的隐式转换

  上面说了隐式转换会导致索引失效,例如：

  select name,phone from customer where id = '111';
  

• 数据库设计时，应该要对以后扩展进行考虑

  数据库设计时，应该要预留扩展余地，当然还是要根据表的用途来定，这里不多说。

• 充分利用表上已经存在的索引

• 避免使用双%号的查询条件。如：a like '%123%' ，（如果无前置%,只有后置%，是可以用到列上的 索引的）
• 一个 SQL 只能利用到复合索引中的一列进行范围查询。如：有 a,b,c 列的联合索引，在查询条件中有 a 列的范围查询，则在 b,c 列上的索引将不会被用到
• 在定义联合索引时，如果 a 列要用到范围查找的话，就要把 a 列放到联合索引的右侧，使用 left join 或 not exists 来优化 not in 操作，因为 not in 也通常会使用索引失效

• 程序连接不同的数据库使用不同的账号，禁止跨库查询

• 消耗更多的 CPU 和 IO 以网络带宽资源
• 无法使用覆盖索引(前面的文章：【MYSQL索引的选择】有提到覆盖索引的失效原因)
• 可减少表结构变更带来的影响

• 禁止使用不含字段列表的 INSERT 语句

  例如：

  insert into values ('a','b','c');
  

  正确使用：

  insert into t(c1,c2,c3) values ('a','b','c');
  

• 避免使用子查询，可以把子查询优化为 join 操作

  join优化这块后面我会单独写一篇文章来讲解，主要是我自己对这块包括join使用到的算法比较感兴趣

  通常子查询在 in 子句中，且子查询中为简单 SQL(不包含 union、group by、order by、limit 从句) 时, 才可以把子查询转化为关联查询进行优化。子查询性能差的原因：

• 子查询的结果集无法使用索引，
• 通常子查询的结果集会被存储到临时表中，不论是内存临时表还是磁盘 临时表都不会存在索引，所以查询性能会受到一定的影响。特别是对于返回结果集比较大的子查询，其 对查询性能的影响也就越大。

• 避免使用 JOIN 关联太多的表

• 对于 MySQL 来说，是存在关联缓存的，缓存的大小可以由 join_buffer_size 参数进行设置。在 MySQL 中，对于同一个 SQL 多关联（join）一个表，就会多分配一个关联缓存，如果在一个 SQL 中 关联的表越多，所占用的内存也就越大
• 如果程序中大量的使用了多表关联的操作，同时 join_buffer_size 设置的也不合理的情况下，就容易造 成服务器内存溢出的情况，就会影响到服务器数据库性能的稳定性。同时对于关联操作来说，会产生临时表操作，影响查询效率，MySQL 最多允许关联 61 个表，建议不超 过 5 个

• 减少同数据库的交互次数

  数据库更适合处理批量操作，合并多个相同的操作到一起，可以提高处理效率。

• 对应同一列进行 or 判断时，使用 in 代替 or

  in 的值不要超过 500 个，in 操作可以更有效的利用索引，or 大多数情况下很少能利用到索引。

• 禁止使用 order by rand() 进行随机排序

  order by rand() 会把表中所有符合条件的数据装载到内存中，然后在内存中对所有数据根据随机生成的 值进行排序，并且可能会对每一行都生成一个随机值，如果满足条件的数据集非常大，就会消耗大量的 CPU 和 IO 及内存资源。

  推荐在程序中获取一个随机值，然后从数据库中获取数据的方式

• WHERE 从句中禁止对列进行函数转换和计算

  不推荐：

  where date(create_time)='20190101'
  

  推荐：

  where create_time >= '20190101' and create_time < '20190102'
  

• 在明显不会有重复值时使用 UNION ALL 而不是 UNION

• UNION 会把两个结果集的所有数据放到临时表中后再进行去重操作
• UNION ALL 不会再对结果集进行去重操作

• 拆分复杂的大 SQL 为多个小 SQL

• 大 SQL 逻辑上比较复杂，需要占用大量 CPU 进行计算的 SQL
• MySQL 中，一个 SQL 只能使用一个 CPU 进行计算
• SQL 拆分后可以通过并行执行来提高处理效率

数据库操作行为规范

• 超 100 万行的批量写 (UPDATE,DELETE,INSERT) 操作,要分批多次进行操作

• 大批量操作可能会造成严重的主从延迟 主从环境中,大批量操作可能会造成严重的主从延迟，大批量的写操作一般都需要执行一定长的时间， 而只有当主库上执行完成后，才会在其他从库上执行，所以会造成主库与从库长时间的延迟情况 binlog 日志为 row 格式时会产生大量的日志
• 大批量写操作会产生大量日志，特别是对于 row 格式二进制数据而言，由于在 row 格式中会记录每一 行数据的修改，我们一次修改的数据越多，产生的日志量也就会越多，日志的传输和恢复所需要的时间 也就越长，这也是造成主从延迟的一个原因 避免产生大事务操作
• 大批量修改数据，一定是在一个事务中进行的，这就会造成表中大批量数据进行锁定，从而导致大量的 阻塞，阻塞会对 MySQL 的性能产生非常大的影响。特别是长时间的阻塞会占满所有数据库的可用连接，这会使生产环境中的其他应用无法连接到数据库， 因此一定要注意大批量写操作要进行分批

• 对于大表使用 pt-online-schema-change 修改表结构

  对大表数据结构的修改一定要谨慎，会造成严重的锁表操作，尤其是生产环境，是不能容忍的。

  pt-online-schema-change 它会首先建立一个与原表结构相同的新表，并且在新表上进行表结构的修 改，然后再把原表中的数据复制到新表中，并在原表中增加一些触发器。把原表中新增的数据也复制到 新表中，在行所有数据复制完成之后，把新表命名成原表，并把原来的表删除掉。把原来一个 DDL 操 作，分解成多个小的批次进行。

• 避免大表修改产生的主从延迟

• 避免在对表字段进行修改时进行锁表

• 禁止为程序使用的账号赋予 super 权限

• 当达到最大连接数限制时，还运行 1 个有 super 权限的用户连接
• super 权限只能留给 DBA 处理问题的账号使用

• 对于程序连接数据库账号,遵循权限最小原则

• 程序使用数据库账号只能在一个 DB 下使用，不准跨库
• 程序使用的账号原则上不准有 drop 权限

目前，我理解的规范大概就这些，当然不同的公司可能会有一些遵循自己本身特别点的规范，但是在日常开发中，数据库的使用，包括接口设计等等都应该遵循一定的规范去做，这样能保证后期的健壮性。