数据库其它调优策略

1.数据调优的措施

1.1 调优的目标

~ 尽可能的节约系统资源，一遍系统可以提供更负荷的服务。（吞吐量更大）

~ 合理的结构设计和参数调整，以提高用户操作 响应的速度。（响应速度更快）

~ 减少系统的瓶颈，提高mysql数据库整体的性能。

1.2 如何定位调优问题

        不过随着用户量的不断增加，以及应用程序复杂度的提升，我们很难用“更快”取定义数据库调优的目标，因为用户在不同时间段访问服务器遇到的瓶颈不同，比如双十一促销的死后会带来大规模的并发访问；还有用户在进行不同业务操作的时候，数据库的 事务处理 和 sql查询都会有所不同。因此我们还需要更加精细定位，去确定调优的目标。

如何确定呢？一般情况下，有如下几种方式：

~ 用户的反馈（主要）

用户是我们的服务对象，因此他们的反馈是最直接的。虽然它们不会直接提出技术建议，但是有些问题往往是用户第一时间发现的。我们要重视用户的反馈，找到和数据相关的问题。

~ 日志分析（主要）

我们可以通过查看数据库日志和操作系统日志等方式找出异常情况，通过它们来定位遇到的问题。

~ 服务器资源使用监控

通过监控服务器的cpu，内存，io等使用情况，可以实时了解服务器的性能使用，与历史情况对比。

~ 数据库内内部状况监控

在数据的监控中，活动会话监控 是要给重要的指标。通过它，你可以清楚的了解数据库当前是否处于非常繁忙的状态，是否存在sql堆积等。

~其他

出了活动会话监控以外，我们也可以对 事务，锁等待 等进行监控，这些都可以帮助我们对数据库的运行状态有更全面的认识。
 

1.4 调优的维度和步骤

我们需要调优的对象是整个数据库管理系统，它不仅包括sql查询，还包括数据库的部署配置，架构等。从这个角度来说，我们思考的维度就不仅仅局限在sql优化上了。通过如下的步骤我们进行梳理：

1. 选择合适的DBMS

如果对 事务性处理 以及 安全性要求高 的化，可以选择商业数据库产品。这些数据库在事务处理和查询性能上都比较强，比如采用sql server， oracle，那么 单表存储上亿条数据是没有问题的。如果数据表设计得好，即使不采用分库分表得方式，查询效率也不差。

初次以外你也可以采用开源的mysql进行存储，他又很多存储引擎可以选择，如果进行事务处理得化可以选择InnoDB，非实物处理可以选择 MyISAM。

NoSQL阵营包括 键值性数据库，文档行数据库，搜索引擎，列式存储和图形数据库。这些数据库科的优缺点和使用场景各有不同，比如列式存储数据库可以大幅降低系统得io，适合于分布式文件系统，但如果数据需要平凡的增删改，那么列式存储就不太适用了。

DBMS得选择关系到了后面的整个设计过程，所以第一步就是要选择合适的DBMS。如果已经确定好了DBMS，那么这部可以跳过。

2. 优化表设计

选择了DBMS之后，我们就需要进行表设计了。而数据表的设计方式也直接影响了后续得sql查询语句。RDBMS中，每个对象都可以定义为一张表，表与表之间得关系代表了对象之间的关系。如果用的是mysql，我们还可以根据不同的表使用需求，选择不同的存储引擎。除此以外，还有一些优化的原则可以参考：

1. 表结构要尽量 遵循三范式原则。这样可以让数据结构更加清晰规范，减少冗余字段，同时也减少了在更新，插入和删除数据时等异常情况发生。

2. 如果 查询 应用比较多，尤其是需要进行 多表查询 得时候，可以采用反范式进行优化。反范式采用空间换时间得方式，通过增加冗余字段提高查询得效率。

3. 表字段的数据类型 选择，关系到了查询效率得高低以及存储空间的大小。一般来说，如果字段可以采用数值类型就不要采用字符类型；字符长度要尽可能设计得短一些。针对字符类型来说，当确定字符长度固定时，就可以采用char类型；当长度不固定时，通常采用varchar类型。

数据表得结构设计很基础，也很关键。好的表结构可以在业务发展和用户增加得情况下依然发挥作用，不好的表结构设计会让数据表变得非常臃肿，查询效率也会降低。

3. 优化逻辑查询

当我们建立好数据表之后，就可以对数据表进行增删改查的操作了。这时我们首先需要考虑得时逻辑查询优化。

sql查询优化，可以分为 逻辑查询优化 和 物理查询优化。逻辑查询优化就是通过改变sql语句得内容让sql执行效率更高，采用的方式是对sql语句进行等价交换，对查询进行重写。

sql得查询重写包括了子查询优化，等价谓词重写，视图重写，条件简化，连接消除和嵌套连接消除等。

比如我们再讲解exists子查询和in子查询得时候，会根据 小表驱动大表 得原则选择适合得子查询。在where子句中会尽量避免对字段进行函数运算，它们会让字段的索引失效。

4. 优化物理查询

物理查询优化是在确定了逻辑查询优化之后，采用物理优化技术，通过计算代价模型对各种可能得访问路径进行估算，从而找到执行方式中代价最小得作为执行计划。在这个部分中，我们需要掌握的中带你是对索引得创建和使用。

但索引不是万能得，我们需要根据实际情况来建立索引。那么都有哪些情况需要考虑呢？

sql查询时需要对不同得数据表进行查询，因此在物理查询优化阶段也需要确定这些查询所采用的路径，具体情况包括：

1. 单表扫描：对于单表扫描来说，我们可以全表扫描所有的数据，也可以局部扫描

2. 两张表的连接：常用的连接方式包括了嵌套循环连接，HASH连接合并连接。

3. 多张表的连接：多张数据表进行连接的时候，顺序很重要，因为不同的连接路径查询的效率不同，搜索空间也会不同。我们在进行多表连接的时候，搜索空间可能会达到 很高的数据量级，巨大的搜索空间显然会占用更多的资源，因此我们需要通过调整连接顺序，将搜索空间调整在一个可接受的范围内。

5. 使用redis或memcached作为缓存

除了可以对sql本身进行优化以外，我们还可以请外援提升查询效率。

因为数据都是存放到数据库中，我们需要从数据库层中取除数据放到内存中进行业务逻辑的操作，当用户量增大的时候，如果频繁的进行数据查询，会消耗数据库的很多资源。如果我们将常用的数据直接放到内存中，就会大幅提升查询的效率。

键值存储数据库可以帮我们解决这个问题。

常用的键值存储数据库有redis和memcached，它们都可以将数据存放到内存中。

从可靠性来说，reids支持持久化，可以让我们的数据保存在硬盘上，不过这样一来性能消耗也会比较大。而memcached仅仅是内存存储，不支持持久化。

从支持的数据类型来说，redis比memcached要多，它不仅支持key-value类型的数据，还支持list，set，hash等数据结构。当我们有持久化需求或者是更高级的数据处理需求的时候，就可以使用reids。如果是简单的key-value存储，则可以使用memcached。

通常我们对于查询响应要求高的场景，可以考虑内存数据库，毕竟术业有专攻。传统的RDBMS都是讲数据库存储在硬盘上，而内存数据库则存放在内存中，查询起来要快得多。不过使用不同的工具，也增加了开发人员的使用成本。

6. 库级优化

库级优化是站在数据库的维度上进行的优化策略，比如控制一个库中的数据表数量。另外，单一的数据库中会遇到各种限制，不如取长补短，利用“外援”的方式。通过主从架构优化我们的读写策略，通过对数据库进行垂直或者水平切分，突破单一数据库或数据表的访问限制，提升查询的性能。

1. 读写分离

如果读和写的业务量都很大，并且他们都在同一个数据库服务器中进行操作，那么数据库的性能就会出现瓶颈，这时候为了提升系统的性能，优化用户体验，我们可以采用读写分离的方式降低主数据库的负载，比如用主数据库完成写操作，用从数据库完成读的操作。

 

 
2. 数据分片

对 数据库分库分表。当数据量达到千万级别以上时，有时候我们需要把一个数据库切分成多份，放到不同的数据库服务器上，减少对单一数据库服务器的访问压力。如果你使用的是mysql，就可以使用mysql自带的分区表功能，当然你也可以考虑自己做垂直拆分，水平拆分，垂直+水平拆分。

 

 但需要注意的时，分拆在提升数据库性能的同时，也会增加维护和使用的成本。

2.优化mysql服务器

---

优化mysql服务器主要从两个方面来优化，一方面是对硬件进行优化；另一方面是对mysql服务的参数进行优化。这部分的内容需要叫全面的只是，一般只有专业的数据库管理员才能进行这一类的优化，对于可以定制参数的惭怍系统，也可以针对mysql进行操作系统优化。

2.1 优化服务器硬件

服务器的硬件性能直接决定着mysql数据库的性能。硬件的性能瓶颈直接决定mysql数据库的运行速度和效率。针对性能瓶颈提高硬件配置，可以提高mysql数据库查询，更新的速度。

1. 配置较大的内存。足够大的容量是提高mysql性能的方法之一。内存的速度比磁盘io快得多，可以通过增配系统 缓冲区容量 使数据在内存中更多，以减少 磁盘 io。

2. 配置高速磁盘系统，以减少读盘的等待时间，提高响应速度。磁盘的io能力，也就是它的寻道能力，目前的scsi高速旋转的使7200转/分钟，这样的速度，一旦访问的用户量上去了，磁盘的压力就过大，如果是每天的网站pv在150W，这样的一般的配置就无法满足这样的需求了。现在SSD盛行，在SSD上随机访问和顺序访问性能几乎差不多，使用SSD可以减少随机io带来的性能损耗。

3. 合理分布磁盘io，把磁盘io分散在多个设备上，以减少资源竞争，提高并行操作能力。

4. 配置多处理器，mysql是多线程的数据库，多处理器可以同时执行多个线程。

2.2 优化mysql的参数

通过优化mysql的参数可以提高资源利用率，从而达到提高mysql服务器性能的目的。

mysql服务的配置参数都在my.cnf或者my.ini文件的【mysqld】中。配置完参数以后，需要重启mysql服务才会生效。

下面对几个对性能影响比较大的参数进行详细介绍。

~ innodb_buffer_pool_size: 这个参数使mysql数据库最重要的参数之一，表示InnoDB类型的表和索引的最大缓存。它不仅仅缓存 索引数据，还会缓存 表的数据。这个值越大，查询速度就越快。但是这个值太大会影响系统的性能。

~ key_buffer_size：表示 索引缓冲区的大小。索引缓冲区是所有的 线程共享。增加索引缓冲区可以得到更好处理的索引。当然，这个之不是越大越好，它的大小取决于内存的大小。如果这个值太大，就会导致操作兄台那个频繁换页，也会降低内存在 4GB 左右的服务器该参数可设置为256M或384M。

~ table_cache：表示同时打开的表的个数。这个值越大，能供同时打开表的个数越多。物理内存越大，设置的就越大。默认为2402，调整到512-1024最佳。这个值不是越大越好，因为同时打开的表太多会影响操作系统的性能。

~ query_cache_size: 表示 查询缓冲区的大小。可以通过在mysql控制台观察，如果qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不够的情况，就要增加Query_cache_size的值；如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果改制较小反而会影响效率，那么可以考虑不用查询缓存；

~ queyr_cache_type：的值使0时，所有的查询都不使用查询缓存区。但是query_cache_type=0并不糊掉之mysql释放query_cache_size所配置的缓存区内存。

~ sort_buffer_size：表示每个需要进行排序的线程分配的缓冲区的大小。增加这个参数的值可以提高ORDER BY 或 GROYP BY操作速度。默认数值是2097144字节（约2MB）.对于内存4GB左右的服务器推荐设置为6-8MB，如果有100个连接，那么实际分配的总共排序缓冲区大小为100*6=600MB.

~ read_buffer_size：表示 每个线程连续扫描时为扫描的每个表分配的缓冲区的大小。当线程从表中连续读取记录时需要用到这个缓冲区。set session read_buffer_size=n 可以临时设置该参数的值。默认为64K，可以是遏制为4M。

~ innodb_flush_log_at_trx_commit：表示何时讲缓冲区的数据写入日志文件，并且将日志文件写入磁盘中。

~ innodb_log_buffer_size: 这是InnoDB存储引擎的 事务日志所使用的缓冲区。为了提高性能，也是先将信息写入innodb log buffer 中，当满足innodb_flush_log_trx_commit参数所设置的相应条件之后，才会将日志写道文件中。

~ back_log： 用户 控制mysql监听tcp端口时设置的挤压请求栈大小。如果mysql的连接数达到了max_connections时，新来的请求将会被存在堆栈中，以等待某已连接释放资源，该堆栈的数量集back_log，如果等待连接的数量超过back_log，将不会授予连接资源,将会报错。5.6.6版本之前默认值为50，之后版本默认为50+（max_connections/5），对于linux系统推荐设置为小于512的证书，但最大不超过900.

~ thread_cache_size：线程池缓存线程数量的大小，当客户断开连接后将当前线程缓存起来，当在接到新的连接请求时快速响应无需创建新的线程。这尤其对那些使用短连接的应用程序来说可以极大的提高创建连接效率。那么为了提高性能可以增大该参数的值。默认为60，可以设置为120。

3. 优化数据库结构

---

一个好的数据库设计方案对于数据库的性能常常会起到事半功倍的效果。合理的数据库接不仅可以是数据库占用更小的空间，而且能够使查询速度更快。数据库结构的设计需要考虑数据冗余，查询和更新的速度，字段的数据类型是否合理等多方面的内容。

3.1 拆分表：冷热数据分离

拆分表的思路是，把1个包含很多字段的表拆分成2个或者多个相对较小的表。这样做的原因是，这些表中某些字段的操作频率很高，经常要进行查询或更新操作，而另外一些字段的使用频率却很低（冷数据），冷热数据分离，可以减少表的宽度。如果放在一个表里面，每次查询都要读取大记录，会消耗较多的资源。

mysql限制每个表最多存储4096列，并且每一行数据的大小不能超过65535字节。表越宽，把表装载进内存缓冲池时所占用的内存也就越大，也会消耗更多的io。冷热数据分离的目的是：1.减少磁盘io，保证热数据的内存缓存命中率。 2. 更有效的利用缓存，避免读入无用的冷数据。

举例1：会员members表存储会员登陆认证信息，该表中有很多字段，如id，姓名，密码，地址，电话，个人描述字段。其中地址，电话，个人描述等字段并不常用，可以将这些不常用的字段分解出另外一个表。将这个表取名叫做members_detail，表中有member_idi,address,telephone,description等字段。这样就把会员表拆分成了两个表分别是members 和 members_detail 。 

3.2 增加中间表

对于需要经常联合查询的表，可以建立中间表以提高查询效率。通过建立中间表，把需要经常联合查询的数据插入中间表，然后将原来的联合查询改为对中间表的查询，以此来提高查询效率。

首先，分析经常联合查询表中的字段；然后，使用这些字段建立一个中间表，并将原来联合查询的表的数据插入中间表中；最后，使用中间表来进行查询。

3.3 增加冗余字段

设计数据库表时应尽量遵循范式理论的规约，尽可能减少冗余字段，让数据库设计看起来精致，优雅。但是，合理的加入冗余字段可以提高查询速度。

表的规范化程度越高，表与表之间的关系就越多，需要连接查询的情况也就越多。尤其在数据量大 ，而且需要频繁进行连接的时候，为了提高效率，我们也可以考虑增加冗余字段来减少连接。

3.4 优化数据类型

改进表的设计时，可以考虑优化字段的数据类型。这个问题在大家刚从是开发的时候基本不算时问题。但是随着你的经验越来越丰富，参与的项目越来越大，数据量也越来越多的时候，你就不能只从系统稳定的角度来思考问题了，还要考虑到系统整体的稳定性和效率。此时，优先选择符合存储需要的最小的数据类型。

列的字段越大，建立索引时所需要的空间也就越大，这样一页中锁能存储的索引节点的数量也就越少，在遍历时所需要的io次数也就越多，索引的性能也就越差。

总之，遇到数据量大的项目时，一定要在充分了解业务需求的前提下，合理优化数据类型，这样才能充分发挥资源的效率，使系统达到最优。

3.5 优化插入记录的速度

插入记录时，影响插入速度的主要是索引，唯一性校验，一次插入记录条数等。根据这些可以分别进行优化。这里我们分为myisam引擎和innodb存储引擎来讲。

1. myisam引擎表：

~ 禁用索引

对于非空表，插入记录时，mysql会根据表的索引对插入的记录建立索引。如果插入大量数据，建立索引就会降低插入记录的速度。为了解决这种情况，可以再插入记录之前禁用索引，数据插入完毕后在开启索引。

~ 禁用唯一性检查

插入数据时，mysql会对插入的记录进行唯一性校验。这种唯一性校验会降低插入速度。为了降低这种情况对查询速度的影响，可以再插入记录之前禁用唯一性检查，等到记录插入完毕后在开启。

2. Inoodb引擎检查的表

~ 禁用唯一性检查

插入数据之前执行 set unique_checks=0 来禁止对唯一索引的检查，数据导入完成之后在运行set unique_checks=1。这个和myisam引擎的使用方法一样。

~ 禁用外键检查

插入数据之前执行禁止对外的检查，数据插入完成之后在恢复对外键的检查。

~ 禁止自动提交

插入数据之前禁止事务的自动提交，数据导入完成之后，执行恢复自动提交操作。

3.6 使用非空约束

在设计字段的时候，如果业务允许，建议尽量使用非空约束。这样的好处是：

1. 进行比较和计算时，省去要对null值的字段判断是否为空的开销，提高存储效率。

2. 非空字段也容易创建索引。因为索引nunll列需要额外的空间来保存，所以要占用更多的空间。使用非空约束，就可以节省存储空间

3.7 分析表，检查表与优化表

mysql提供了分析表，检查表和优化表的语句。分析表 主要是分析关键字的分布，检查表 主要是检查表是否存在错误，优化表 主要是消除删除或者更新造成的空间浪费。

1. 分析表

mysql提供了analyze table 语句分析表，analyze table 语句的基本语法如下：

analyze [local | no_write_to_binlog] table tbl_name....

默认的，mysql服务会将analyze table 语句写到binlog中，以便在主从架构中，从服务能够同步数据。可以添加参数local或者no_write_binlog 取消将语句写道binlog中。

2. 检查表

mysql 中可以使用 check table 语句来检查表。check table 语句能够检查innodb和myisam类型的表是否存在错误。check table 语句在执行过程中也会给表加上 只读锁。

对于myisam类型的表，check table 语句还会更新关键字统计数据。而且，check table 也可以检查视图是否有错误，比如在试图定义中被引用的表已不存在。该语句的基本语法如下：

check table tbl_name [, tbl_name] ... [option] ...
option = { QUICK | FAST | MEDIUM | EXTENDED | CHANGED}

其中，tbl_name是表名；option参数有5个值，分别是 quick，fast, medium, extended 和 changed.各个选项的意义分别是：

~ quick: 不扫描行，不检查错误的连接。

~ fast：只检查没有被正确关闭的表。

~ changen：只检查上次检查后被更改的表和没有被正确关闭的表。

~ medium：扫描行，已验证被删除的连接是有效的。也可以计算各行的关键字校验和，并使用计算出的检验和验证这一点。

3. 优化表

方式1：optimize table

mysql中使用optimize table 语句来优化表。但是，optimize table 语句只能优化表中的varchar，blob或text字段。一个表使用了这些字段的数据类型，若已经删除了表的一大部分数据，或者已经对含有可变长度行的表进行了很多更新，使用的空间，并整理数据文件的碎片。

3.8 小结

上述这些方法都是有利有弊的。比如：

~ 修改数据类型，节省空间的同时，你要考虑到数据不能超过取值范围；

~ 增加冗余字段的时候，不要忘了确保数据一致性；

~ 把大表拆分，也意味着你的查询会增加新的连接，从而增加额外的开销和运维成本。

因此，你一定要结合实际的业务需求进行权衡。

4. 大表优化

---

当mysql单表记录数过大时，数据库的curd性能会明显下降，一些常见的优化措施如下：

4.1 限定查询的范围

禁止不带任何限制数据范围条件的查询语句。比如：我们当用户在查询订单历史的时候，我们可以控制在一个月的范围内。

4.2 读写分离

进店的数据库拆分方案，主负责写，从负责读。

~ 一主一从模式：

~ 双主双从模式：

4.3 垂直拆分

当数据量集达到千万级以上时，有时候我们需要把一个数据库切分成多分，放到不同的数据库服务器上，减少对单一数据库服务器的访问压力。

~ 如果数据库中的数据表过多，可以采用垂直分库的方式，将关联的数据表部署在同一个数据库上。

~ 如果数据表中的列过多，可以采用垂直分表的方式。将一张数据表拆分成多张数据表，把经常一起使用的列放到同一张表里。

垂直拆分的优点：可以使的列数据变小，在查询时减少读取的 block数，减少io次数。此外，垂直分区可以简化表的结构，易于维护。

垂直拆分的缺点：主键会出现冗余，需要管理冗余列，并会引起join操作。此外，垂直拆分会让事务变得更加复杂。 

4.4 水平拆分

~ 尽量控制单表数据量的大小，建立控制在1000万以内。1000万并不是mysql的限制，过大会造成修改表结构，备份，恢复都会有很大的问题。此时可以用 历史数据归档，水平分表等手段来控制数据量大小。

~ 这里我们住哟啊考虑业务数据的水平分表策略。将大的数据表按照某个属性维度分拆成不同的小表，每张小标保持相同的表结构。比如你可以按照年份来划分，把不同年份的数据放到不同的数据表中。2017年，2018年和2019年的数据就可以分别放到三张数据表中。

~ 水平分表是解决了单一表数据过大的问题。但由于表的数据还是在同一台机器上，其实对于提升mysql并发能力并没有什么意义，所以水平拆分最好分库，从而达到分布式的目的。

 水平拆分能够支持非常大的数据量存储，应用端改造也少，但 分片事务难以解决，跨界点join性能较差，逻辑复杂。《java工程师修炼之道》的作者推荐 尽量不要对数据进行分片，因为拆分会带来逻辑，部署，运维的各种复杂度，一般的数据表在优化的党的情况下支撑千万以下的数据量是没有太大问题的。如果实在要分片，尽量选择客户端分片架构，这样可以减少一次和中间件的网络io。

下面补充一下数据库分片的两种常见方案：

~ 客户端代理：分片逻辑在应用端，封装在jar包中，通过修改或者封装jdbc层来实现。当当网的Sharding-JDBC， 阿里的TDDL是两种比较常用的实现。

~ 中间件代理：在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。我们现在谈的mycat，360的atlas，网易的DDB等等都是这种架构的实现。

5.其他调优策略

---

5.1 服务器语句超时处理

在mysql8.0中可以设置 服务器语句超时的限制，单位可以达到毫秒级别。当中断的执行语句超过设置的毫秒数后，服务器将终止查询影响武大的事务或链接，然后将错误报给客户端。

设置服务器的语句超时的限制，可以通过设置系统变量 max_ececution_time 来实现。默认情况下，max_execution_time的值为0，代表没有时间限制。

5.2 创建全局通用空间

mysql 8.0 使用 create tablespace 语句来创建一个全局通用表空间。全局表空间可以被所有的数据库的表共享，而且相比于独享表空间，使用手动创建共享表空间可以节约元数据方面的内存。可以在创建表的时候，指定属于哪个表空间，也可以对已有表进行表空间修改等。

如何删除创建的共享表空间？因为时共享表空间，所以不能直接通过drop table tbname 删除，这样操作并不能回收空间。当确定共享表空间的数据都没用，并且依赖该表空间的表均已经删除时，可以通过drop tablespace 删除共享表空间来释放空间，如果该依赖共享表空间存在，就会删除失败。

5.3 mysql 8.0 新特性：隐藏索引对调优的帮助

不可见索引的特性对于性能调试非常有用。在mysql8.0中，索引可以被隐藏和显示。当一个索引被隐藏时，他不会被查询优化器所使用。也就是说，管理员可以隐藏一个索引，然后观察对数据库的影响。如果数据库性能有所下降，证明这个索引是有用的，于是将其恢复显示即可；如果数据库性能看不出变化，就说明这个索引是多余的，可以删掉了。

需要注意的时当索引被隐藏时，它的内容仍然是和正常索引一样 实时更新 的。如果一个索引需要被长期隐藏，那么可以将其删除，因为索引的存在会影响插入，更新，删除的性能。