MySQL数据库优化方法

数据库

发布日期: 2021-02-03

作者: 锦泉

文章字数: 4.5k

阅读时长: 16 分

阅读次数:

选取最适用的字段属性

MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。

例如，在定义邮政编码这个字段时，如果将其设置为CHAR（255）,显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR（6）就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。

另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。

对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

使用连接（JOIN）来代替子查询（Sub-Queries）

MySQL从4.1开始支持SQL的子查询。

例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：

DELETE FROM customerinfo
WHERE CustomerID NOT IN (SELECT CustomerID FROM salesinfo)

使用子查询可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询可以被更有效率的连接（JOIN）替代。

如果使用连接（JOIN）来完成这个查询工作，速度将会快很多。尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：

SELECT * FROM customerinfo
LEFT JOIN salesinfo ON customerinfo.CustomerID=salesinfo.CustomerID
WHERE salesinfo.CustomerID IS NULL

连接（JOIN）之所以更有效率一些，是因为MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

使用联合（UNION）来代替手动创建的临时表

MySQL从4.0的版本开始支持union查询，它可以把需要使用临时表的两条或更多的select查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。

使用union来创建查询的时候，我们只需要用UNION作为关键字把多个select语句连接起来就可以了，要注意的是所有select语句中的字段数目要相同。下面的例子就演示了一个使用UNION的查询。

SELECT Name,Phone FROM client UNION
SELECT Name,BirthDate FROM author UNION
SELECT Name,Supplier FROM product

事务

尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库操作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的操作就会变得不确定起来。

换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN关键字开始，COMMIT关键字结束。在这之间的一条SQL操作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。

BEGIN; 
INSERT INTO salesinfo SET CustomerID=14; 
UPDATE inventory SET Quantity=11 WHERE item='book'; 
COMMIT;

事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的操作不被其它的用户所干扰。

锁定表

尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。

其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE inventory WRITE SELECT Quantity FROM inventory WHERE Item='book';
...
UPDATE inventory SET Quantity=11 WHERE Item='book'; UNLOCKTABLES

这里，我们用一个select语句取出初始数据，通过一些计算，用update语句将新值更新到表中。包含有WRITE关键字的LOCK TABLE语句可以保证在UNLOCK TABLES命令被执行之前，不会有其它的访问来对inventory进行插入、更新或者删除的操作。

使用外键

锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。

例如，外键可以保证每一条销售记录都指向某一个存在的客户。在这里，外键可以把customerinfo表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。

CREATE TABLE customerinfo( CustomerID INT NOT NULL, PRIMARYKEY(CustomerID) )TYPE=INNODB;

CREATE TABLE salesinfo( SalesID INT NOT NULL, CustomerIDINT NOT NULL,PRIMARYKEY(CustomerID,SalesID),
FOREIGNKEY(CustomerID) REFERENCES customerinfo(CustomerID) ON DELETE CASCADE)TYPE=INNODB;

注意例子中的参数“ON DELETE CASCADE”。该参数保证当customerinfo表中的一条客户记录被删除的时候，salesinfo表中所有与该客户相关的记录也会被自动删除。

如果要在MySQL中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表InnoDB类型。该类型不是MySQL表的默认类型。定义的方法是在CREATETABLE语句中加上TYPE=INNODB。如例中所示。

使用索引

索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX（）,MIN（）和ORDER BY这些命令的时候，性能提高更为明显。

加索引的注意事项：

一般说来，索引应建立在那些将用于JOIN,WHERE判断和ORDER BY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。如ENUM类型的字段会出现大量重复值
索引需要逐步优化
索引一旦进行升级优化，需要将之前废弃的索引删掉，防止干扰。
根据SQL实际解析的顺序，调整索引的顺序（最左前缀，保持索引的定义和使用的顺序一致性）

sql解析顺序：from … on… join …where …group by …having …select dinstinct …order by … limit …
范围查询 in 有时不会实现，所以将含In的范围查询放到where条件的最后，防止失效。
对于多表查询，小表驱动大表
对于复合索引，where 和 order by 拼起来，不要跨列使用
此外，MySQL从版本3.23.23开始支持全文索引和搜索。全文索引在MySQL中是一个FULLTEXT类型索引，但仅能用于MyISAM类型的表。如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。

优化的查询语句

绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。

下面是应该注意的几个方面。

首先，最好是在相同类型的字段间进行比较的操作。
其次，在建有索引的字段上尽量不要计算、使用函数和类型转换进行操作。

例如，在一个DATE类型的字段上使用YEAE（）函数时，将会使索引不能发挥应有的作用。

第三，在搜索字符型字段时，我们有时会使用LIKE关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。

例如下面的查询将会比较表中的每一条记录。

SELECT  *  FROM  books  WHERE  name  like  "MySQL%"

但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：

SELECT   *  FROM  books
WHERE  name＞="MySQL"  and  name  ＜"MySQM"

SQL优化，是一种概率层面的优化，这是因为sql语句在执行前要经过服务层的sql优化器（MySQL Query Optimizer）进行优化。至于是否实际使用了我们的优化，需要通过explain进行推测。

索引失效的十大情况：http://arthurjq.com/2020/12/26/index-missing/

读写分离

就是将数据库分为主从库，一个主库（Master）用于写数据，多个从库（Slaver）进行轮询读取数据的过程，主从库之间通过某种通讯机制进行数据的同步，是一种常见的数据库架构。下面这张图就展示了 “一主二从” 的结构：

为什么要读写分离

大多数互联网数据操作往往都是读多写少，随着数据的增长，数据库的“读”会首先成为瓶颈。如果我们希望能线性地提升数据库的读性能和写性能，就需要让读写尽可能的不相互影响，各自为政。在使用读写分离之前我们应该考虑使用缓存能不能解决问题。然后再考虑对数据库按照 “读” 和 “写” 进行分组。读写分离意味着将一体的结构的进行分散，在数据量大、高并发的情景中要考虑以下这些问题：

如何保证 Master 的高可用，故障转移，熔断限流等。
读写操作的区分规则，代码层面如何处理好读命令和写命令，尽量无感知无业务入侵。
数据一致性的容忍度。虽然是数据同步，但是由于网络的不确定性这仍然是一个不可忽视的问题。

分库

数据库垂直拆分、数据库水平拆分 统称分库。是指按照特定的条条件和维度，将同一个数据库中的数据拆分到多个数据库（主机）上面以达到分散单库（主机）负载的效果。这样我们变相地降低了数据集的大小，以空间换时间来提升性能。

数据库垂直拆分

数据库垂直拆分 指的是按照业务对数据库中的表进行分组，同组的放到一个新的数据库（逻辑上，并非实例）中。需要从实际业务出发将大业务分割成小业务。

比如商城的整个业务中的 用户相关表，订单相关表，物流相关表 各自独立分类形成 用户系统数据库，订单系统数据库，物流系统数据库 如下图：

垂直分库是指按照业务将表进行分类，分布到不同的数据库上面，每个库可以放在不同的服务器上，它的核心理念是专库专用。

这样带来了一些好处：（a）业务清晰，职责单一（b）易维护，易扩展（c）数据服务化

同时也有一些负面的作用：

（a）提高了整个应用的复杂度，而且会形成跨库事务

（b）引发 “木桶效应”，任何一个短板有可能影响整个系统

（c）部分表关系不能 join 只能通过服务相互调用来维系。甚至由于网络问题引发数据不一致。

在需要进行分库的情况下，通常可优先考虑垂直拆分。

数据库水平拆分

在数据库垂直拆分后遇到单机数据库性能瓶颈之后，就可以考虑数据库水平拆分了。

之所以先垂直拆分才水平拆分，是因为垂直拆分后数据业务清晰而且单一，更加方便指定水平的标准。比如我们对商城业务垂直拆分后的用户系统进行水平拆分就比对整个商城业务进行水平拆分好找维度，我们可以根据用户注册时间的区间、用户的区域或者用户 ID 的范围、 hash 等条件，然后关联相关表的记录将数据进行拆分，如果放在整个商城业务上你是以用户为准还是以订单为准都不太好考虑。

我们按照每100万为区间对用户系统水平拆分如下（按照 id % 2 分也可以）：

水平分库是把同一个表的数据按一定规则拆到不同的数据库中，每个库可以放在不同的服务器上。

这种拆分的好处在于：（a）单个库的容量可控（b）单条记录保证了数据完整性（c）数据关系可以通过 join 维持（d）避免了跨库事务（e）稳定性体现在IO冲突减少，锁定减少，可用性指某个库出问题，部分可用；

缺点同样存在：（a）拆分规则对编码有一定的影响（b）不同业务的分区交互需要统筹设计

分表

分表也分为 数据表垂直拆分 和 数据表水平拆分 。

数据表垂直拆分

数据表垂直拆分就是纵向地把表中的列分成多个表，把表从“ 宽 ”变“ 窄 ”。一般遵循以下几个点进行拆分：

冷热分离，把常用的列放在一个表，不常用的放在一个表
大字段列独立存放
关联关系的列紧密的放在一起

我们把用户表中常用的和不常用的而且大字段分离成两张表：

垂直分表定义：将一个表按照字段分成多表，每个表存储其中一部分字段。

它带来的提升是：

为了避免IO争抢并减少锁表的几率，查看详情的用户与商品信息浏览互不影响
充分发挥热门数据的操作效率，商品信息的操作的高效率不会被商品描述的低效率所拖累。

为什么大字段IO效率低：第一是由于数据量本身大，需要更长的读取时间；第二是跨页，页是数据库存储单位，很多查找及定位操作都是以页为单位，单页内的数据行越多数据库整体性能越好，而大字段占用空间大，单页内存储行数少，因此IO效率较低。第三，数据库以行为单位将数据加载到内存中，这样表中字段长度较短且访问频率较高，内存能加载更多的数据，命中率更高，减少了磁盘IO，从而提升了数据库性能。

数据表的水平拆分

表的水平拆分感觉跟库的水平拆分思想上都是一样的，只不过粒度不同。表结构维持不变。也就是说拆分后数据集的并集等于拆分前的数据集。理解了数据库水平拆分之后这个就没有什么可说的了。

水平分表是在同一个数据库内，把同一个表的数据按一定规则拆到多个表中。

这里简单阐述了几个数据库优化概念，在实际操作中往往会组合使用。我们在实际操作之前要做好数据量的预估，这样能够根据预测未来数据的增量来进行选型。业务数据增长较小，常用于表的拆分。增长特别大达到上万级别则可以选择分库，比如一些资金积分流水，历史记录之类的。有些时候并不是拆分完就万事大吉了，比如我们按照地区拆分后，A地区业务增长很快业绩很好，而B地区推广不力竞争激烈业绩萧条，造成了数据倾斜。也会影响分库分表的期望效果。这需要建立长效的监控预测机制来应对，甚至根据实际情况及时调整策略。数据拆分还面临分布式的很多问题，分布式事务，高可用，数据一致性，全局唯一性都是应该考虑的问题。