SQL优化

原创已于 2023-09-19 14:35:20 修改 · 906 阅读

2 ·

CC 4.0 BY-SA版权

文章标签：

#sql #数据库 #mysql

于 2022-08-31 17:20:54 首次发布

JAVA技术栈专栏收录该内容

30 篇文章

订阅专栏

1、性能分析工具的使用

1.1数据库服务器的优化步骤

①观察服务器状态，观察是否存在周期性波动，如果是加缓存或者更改缓存失效策略

②如果仍有不规则延迟或卡顿，则开启慢查询，使用EXPLAIN、SHOW、PROFILING工具进行分析，如果是SQL等待时间长，则调优服务器参数，如果是SQL执行时间长，则进行索引设计优化（物理优化），JOIN表过多，需要优化（查询逻辑优化），数据表设计优化（数据类型优化）.

③如果SQL查询到达瓶颈，则从架构上优化，读写分离(主从架构)、分库分表(垂直分库、垂直分表、水平分表)

1.2查看系统性能参数

SHOW [GLOBAL|SESSION] STATUS LIKE '参数'；

• Connections：连接MySQL服务器的次数。

• Uptime：MySQL服务器的上线时间。

• Slow_queries：慢查询的次数。

• Innodb_rows_read：Select查询返回的行数

• Innodb_rows_inserted：执行INSERT操作插入的行数

• Innodb_rows_updated：执行UPDATE操作更新的行数

• Innodb_rows_deleted：执行DELETE操作删除的行数

• Com_select：查询操作的次数。

• Com_insert：插入操作的次数。对于批量插入的 INSERT 操作，只累加一次。

• Com_update：更新操作的次数。

• Com_delete：删除操作的次数。

1.3统计SQL的查询成本：last_query_cost

使用场景：它对于比较开销是非常有用的，特别是我们有好几种查询方式可选的时候。

SHOW STATUS LIKE 'last_query_cost';

1.4定位执行慢的 SQL：慢查询日志

（1） 开启慢查询日志（开启slow_query_log）

set global slow_query_log='ON';

（2）修改long_query_time阈值（慢查询的时间阈值设置）

show variables like '%long_query_time%';
set global long_query_time = 1;
#或者
set long_query_time = 1;

（3）查看慢查询数目

SHOW GLOBAL STATUS LIKE '%Slow_queries%'；

（4）慢查询日志分析工具：mysqldumpslow

在生产环境中，如果要手工分析日志，查找、分析SQL，显然是个体力活，MySQL提供了日志分析工具 mysqldumpslow 。

mysqldumpslow --help #查看mysqldumpslow的帮助信息
#常用参考：
#得到返回记录集最多的10个SQL
mysqldumpslow -s r -t 10 /var/lib/mysql/slow.log 
#得到访问次数最多的10个SQL
mysqldumpslow -s c -t 10 /var/lib/mysql/slow.lo 
#得到按照时间排序的前10条里面含有左连接的查询语句
mysqldumpslow -s t -t 10 -g "left join" /var/lib/mysql/slow.log
#另外建议在使用这些命令时结合 | 和more 使用 ，否则有可能出现爆屏情况
mysqldumpslow -s r -t 10 /var/lib/mysql/atguigu-slow.log | more

（5）关闭慢查询日志

方式1：永久性方式

[mysqld]
slow_query_log=OFF #或者，把slow_query_log一项注释掉 或 删除

方式2：临时性方式

SET GLOBAL slow_query_log=off;

（6）删除慢查询日志

1.5 查看 SQL 执行成本：SHOW PROFILE

mysql > show variables like 'profiling';
mysql > set profiling = 'ON';
mysql > show profiles;
mysql> show profile cpu,block io for query 2;

① ALL：显示所有的开销信息。

② BLOCK IO：显示块IO开销。

③ CONTEXT SWITCHES：上下文切换开销。

④ CPU：显示CPU开销信息。

⑤ IPC：显示发送和接收开销信息。

⑥ MEMORY：显示内存开销信息。

⑦ PAGE FAULTS：显示页面错误开销信息。

⑧ SOURCE：显示和Source_function，Source_file， Source_line相关的开销信息。

⑨ SWAPS：显示交换次数开销信息。

1.6分析查询语句：EXPLAIN

EXPLAIN 或 DESCRIBE语句的语法形式如下：

EXPLAIN SELECT select_options
或者
DESCRIBE SELECT select_options

EXPLAIN 语句输出的各个列的作用如下：

①id ：在一个大的查询语句中每个SELECT关键字都对应一个唯一的id

②select_type SELECT关键字对应的那个查询的类型

③table 表名

④partitions 匹配的分区信息

⑤type 针对单表的访问方法

⑥possible_keys 可能用到的索引

⑦key 实际上使用的索引

⑧key_len 实际使用到的索引长度

⑨ref 当使用索引列等值查询时，与索引列进行等值匹配的对象信息

⑩rows 预估的需要读取的记录条数

filtered 某个表经过搜索条件过滤后剩余记录条数的百分比

Extra 一些额外的信息

小结： 结果值从最好到最坏依次是： system > const > eq_ref > ref > fulltext > ref_or_null > index_merge > unique_subquery > index_subquery > range > index > ALL 其中比较重要的几个提取出来（加粗）。SQL 性能优化的目标：至少要达到 range 级别，要求是 ref 级别，最好是 consts级别。（阿里巴巴开发手册要求）

EXPLAIN四种输出格式

这里谈谈EXPLAIN的输出格式。EXPLAIN可以输出四种格式：传统格式， JSON格式， TREE格式以及可视化输出。用户可以根据需要选择适用于自己的格式。

EXPLAIN FORMAT=JSON SELECT ....
EXPLAIN FORMAT=tree SELECT ....
可视化输出，可以通过MySQL Workbench可视化查看MySQL的执行计划。通过点击Workbench的放大镜图
标，即可生成可视化的查询计划。

1.7 分析优化器执行计划：trace

SET optimizer_trace="enabled=on",end_markers_in_json=on;
set optimizer_trace_max_mem_size=1000000;
select * from student where id < 10;
select * from information_schema.optimizer_trace\G

1.8MySQL监控分析视图-sys schema

索引情况

#1. 查询冗余索引
select * from sys.schema_redundant_indexes;
#2. 查询未使用过的索引
select * from sys.schema_unused_indexes;
#3. 查询索引的使用情况
select index_name,rows_selected,rows_inserted,rows_updated,rows_deleted
from sys.schema_index_statistics where table_schema='dbname' ;

表相关

# 1. 查询表的访问量
select table_schema,table_name,sum(io_read_requests+io_write_requests) as io from
sys.schema_table_statistics group by table_schema,table_name order by io desc;
# 2. 查询占用bufferpool较多的表
select object_schema,object_name,allocated,data
from sys.innodb_buffer_stats_by_table order by allocated limit 10;
# 3. 查看表的全表扫描情况
select * from sys.statements_with_full_table_scans where db='dbname';

语句相关

#1. 监控SQL执行的频率
select db,exec_count,query from sys.statement_analysis
order by exec_count desc;
#2. 监控使用了排序的SQL
select db,exec_count,first_seen,last_seen,query
from sys.statements_with_sorting limit 1;
#3. 监控使用了临时表或者磁盘临时表的SQL
select db,exec_count,tmp_tables,tmp_disk_tables,query
from sys.statement_analysis where tmp_tables>0 or tmp_disk_tables >0
order by (tmp_tables+tmp_disk_tables) desc;

IO相关

#1. 查看消耗磁盘IO的文件
select file,avg_read,avg_write,avg_read+avg_write as avg_io
from sys.io_global_by_file_by_bytes order by avg_read limit 10;

Innodb 相关

#1. 行锁阻塞情况
select * from sys.innodb_lock_waits;

2、索引优化（物理）与查询优化（逻辑）

2.1索引失效案例

全值匹配
最佳左前缀法则：索引文件具有 B-Tree 的最左前缀匹配特性，如果左边的值未确定，那么无法使用此索引。
主键插入顺序非依次递增（导致性能损耗）
计算、函数、类型转换(自动或手动)导致索引失效
范围条件右边的列（加粗）索引失效：WHERE student.classId>20 AND student.name = ‘abc’ ；
不等于(!= 或者<>)索引失效
is null可以使用索引，is not null无法使用索引
like以通配符%开头索引失效
OR 前后存在非索引的列，索引失效
不同的字符集进行比较前需要进行转换会造成索引失效。

2.2关联查询优化

保证被驱动表的JOIN字段已经创建了索引
需要JOIN 的字段，数据类型保持绝对一致。
LEFT JOIN 时，选择小表作为驱动表，大表作为被驱动表。减少外层循环的次数。
INNER JOIN 时，MySQL会自动将小结果集的表选为驱动表。选择相信MySQL优化策略。
能够直接多表关联的尽量直接关联，不用子查询。(减少查询的趟数)
不建议使用子查询，建议将子查询SQL拆开结合程序多次查询，或使用 JOIN 来代替子查询。
衍生表建不了索引

2.3子查询优化

子查询是 MySQL 的一项重要的功能，可以帮助我们通过一个 SQL 语句实现比较复杂的查询。但是，子查询的执行效率不高。原因：

① 执行子查询时，MySQL需要为内层查询语句的查询结果建立一个临时表，然后外层查询语句从临时表中查询记录。查询完毕后，再撤销这些临时表。这样会消耗过多的CPU和IO资源，产生大量的慢查询。

② 子查询的结果集存储的临时表，不论是内存临时表还是磁盘临时表都不会存在索引，所以查询性能会受到一定的影响。

③ 对于返回结果集比较大的子查询，其对查询性能的影响也就越大。在MySQL中，可以使用连接（JOIN）查询来替代子查询。连接查询不需要建立临时表，其速度比子查询要快，如果查询中使用索引的话，性能就会更好。

结论：尽量不要使用NOT IN 或者 NOT EXISTS，用LEFT JOIN xxx ON xx WHERE xx IS NULL替代

2.4排序优化

**问题：**在 WHERE 条件字段上加索引，但是为什么在 ORDER BY 字段上还要加索引呢？

优化建议：

SQL 中，可以在 WHERE 子句和 ORDER BY 子句中使用索引，目的是在 WHERE 子句中避免全表扫描，在 ORDER BY 子句避免使用 FileSort 排序。当然，某些情况下全表扫描，或者 FileSort 排序不一定比索引慢。但总的来说，我们还是要避免，以提高查询效率。
尽量使用 Index 完成 ORDER BY 排序。如果 WHERE 和 ORDER BY 后面是相同的列就使用单索引列；如果不同就使用联合索引。
无法使用 Index 时，需要对 FileSort 方式进行调优：使用单路排序尝试提高 sort_buffer_size、max_length_for_sort_data 。

2.5GROUP BY优化

优化思路一 ：在索引上完成排序分页操作，最后根据主键关联回原表查询所需要的其他列内容。

优化思路二 ：该方案适用于主键自增的表，可以把Limit 查询转换成某个位置的查询。

2.6优先考虑覆盖索引

索引列+主键包含 SELECT 到 FROM之间查询的列。

好处：

避免Innodb表进行索引的二次查询（回表）
可以把随机IO变成顺序IO加快查询效率

弊端：

索引字段的维护 总是有代价的。这是业务 DBA，或者称为业务数据架构师的工作。

2.7给字符串添加前缀索引

mysql> alter table teacher add index index1(email);
#或
mysql> alter table teacher add index index2(email(6));

2.8索引下推

索引下推：使用完索引之后并不是立马回表，而是使用索引得到的结果，在此基础上进一步使用下一个限定条件进行过滤。

2.9普通索引与唯一索引优化

普通索引和唯一索引应该怎么选择？其实，这两类索引在查询能力上是没差别的，主要考虑的是对更新性能的影响。所以，建议你尽量选择普通索引。

在实际使用中会发现，普通索引和 change buffer 的配合使用，对于数据量大的表的更新优化还是很明显的。
如果所有的更新后面，都马上伴随着对这个记录的查询，那么你应该关闭change buffer 。而在其他情况下，change buffer都能提升更新性能。
由于唯一索引用不上change buffer的优化机制，因此如果业务可以接受，从性能角度出发建议优先考虑非唯一索引。但是如果"业务可能无法确保"的情况下，怎么处理呢？
- 首先，业务正确性优先。我们的前提是“业务代码已经保证不会写入重复数据”的情况下，讨论性能问题。如果业务不能保证，或者业务就是要求数据库来做约束，那么没得选，必须创建唯一索引。这种情况下，本节的意义在于，如果碰上了大量插入数据慢、内存命中率低的时候，给你多提供一个排查思路。
- 然后，在一些“ 归档库 ”的场景，你是可以考虑使用唯一索引的。比如，线上数据只需要保留半年，然后历史数据保存在归档库。这时候，归档数据已经是确保没有唯一键冲突了。要提高归档效率，可以考虑把表里面的唯一索引改成普通索引。

2.10关于SELECT(*)

在表查询中，建议明确字段，不要使用 * 作为查询的字段列表，推荐使用SELECT <字段列表> 查询。原因：

① MySQL 在解析的过程中，会通过查询数据字典将"*"按序转换成所有列名，这会大大的耗费资源和时间。

② 无法使用覆盖索引

2.11关于LIMIT 1

针对的是会扫描全表的 SQL 语句，如果你可以确定结果集只有一条，那么加上 LIMIT 1 的时候，当找到一条结果的时候就不会继续扫描了，这样会加快查询速度。
如果数据表已经对字段建立了唯一索引，那么可以通过索引进行查询，不会全表扫描的话，就不需要加上 LIMIT 1 了。

2.12关于COMMIT

只要有可能，在程序中尽量多使用 COMMIT，这样程序的性能得到提高，需求也会因为 COMMIT 所释放的资源而减少。 COMMIT 所释放的资源：

回滚段上用于恢复数据的信息
被程序语句获得的锁
redo / undo log buffer 中的空间
管理上述 3 种资源中的内部花费

2.13主键设计

自增ID的问题自增ID做主键，简单易懂，几乎所有数据库都支持自增类型，只是实现上各自有所不同而已。自增ID除了简单，其他都是缺点，总体来看存在以下几方面的问题：
- 1. 可靠性不高存在自增ID回溯的问题，这个问题直到最新版本的MySQL 8.0才修复。
  2. 安全性不高对外暴露的接口可以非常容易猜测对应的信息。比如：/User/1/这样的接口，可以非常容易猜测用户ID的值为多少，总用户数量有多少，也可以非常容易地通过接口进行数据的爬取。
  3. 性能差自增ID的性能较差，需要在数据库服务器端生成。
  4. 交互多业务还需要额外执行一次类似 last_insert_id() 的函数才能知道刚才插入的自增值，这需要多一次的网络交互。在海量并发的系统中，多1条SQL，就多一次性能上的开销。
  5. 局部唯一性最重要的一点，自增ID是局部唯一，只在当前数据库实例中唯一，而不是全局唯一，在任意服务器间都是唯一的。对于目前分布式系统来说，这简直就是噩梦。
非核心业务：对应表的主键自增ID，如告警、日志、监控等信息。
核心业务：主键设计至少应该是全局唯一且是单调递增。全局唯一保证在各系统之间都是唯一的，单调递增是希望插入时不影响数据库性能。这里推荐最简单的一种主键设计：UUID。 UUID的特点：全局唯一，占用36字节，数据无序，插入性能差。MySQL数据库的UUID组成以及淘宝订单如下所示：

UUID = 时间+UUID版本（16字节）- 时钟序列（4字节） - MAC地址（12字节）
订单ID = 时间 + 去重字段 + 用户ID后6位尾号

2.14关于EXISTS 和 IN

IN 是把外表和内表作hash连接，而EXISTS是对外表作loop循环，每次loop循环再对内表进行查询，一直以来认为EXISTS比 IN 效率高的说法是不准确的。

如果查询的两个表大小相当，那么用 IN 和EXISTS差别不大；
如果两个表中一个较小一个较大，则子查询表大的用EXISTS，子查询表小的用IN ；

3、数据库的设计规范（表优化）

在关系型数据库中，关于数据表设计的基本原则、规则就称为范式。可以理解为，一张数据表的设计结构需要满足的某种设计标准的级别。要想设计一个结构合理的关系型数据库，必须满足一定的范式。目前关系型数据库有六种常见范式，按照范式级别，从低到高分别是：第一范式（1NF）、第二范式（2NF）、第三范式（3NF）、巴斯-科德范式（BCNF）、第四范式(4NF）和第五范式（5NF，又称完美范式）。一般是使用到第三范式，遵循思想：高内聚，低耦合。

3.1第一范式：

原子性，表中的一个单元格不可在分割。（基本数据类型）

3.2第二范式：

一张表就是一个独立的对象，一张表只表达一个意思。（一个类）

3.3第三范式：

首先满足第一，第二范式，紧接着将数据关系转化为脑图，第三范式要求不存在两套关系融合在一起。

3.4巴斯范式

巴斯范式对第三范式进行扩充，对满足第三范式的关系进一步分类，进一步精细。

[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-HCzA7Nki-1661937273596)(C:\Users\hp-pc\AppData\Local\Temp\1659947240762.png)]
上图可进一步将关系分成，管理层面，和货物层面两张表。（仓库名，管理员）（仓库名，物品名，数量）。

3.5ER模型

实体，可以看做是数据对象，往往对应于现实生活中的真实存在的个体。在 ER 模型中，用矩形来表示。实体分为两类，分别是强实体和弱实体。强实体是指不依赖于其他实体的实体；弱实体是指对另一个实体有很强的依赖关系的实体。

属性，则是指实体的特性。比如超市的地址、联系电话、员工数等。在 ER 模型中用椭圆形来表示。

关系，则是指实体之间的联系。比如超市把商品卖给顾客，就是一种超市与顾客之间的联系。在 ER 模型中用菱形来表示。

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-Yh74oCCW-1661937273596)(C:\Users\hp-pc\AppData\Local\Temp\1659948090671.png)]$

PowerDesigner的使用制作ER模型。

4、数据库其他优化

4.1如何定位调优问题

用户的反馈（主要）
日志分析（主要）
服务器资源使用监控
数据库内部状况监控
其它

4.2调优的维度和步骤

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

第1步：选择适合的 DBMS

第2步：优化表设计

第3步：优化逻辑查询

第4步：优化物理查询

第5步：使用 Redis 或 Memcached 作为缓存

第6步：库级优化 （大表优化）

读写分离

$[外链图片转存失败,源站可能有防盗链机制,建议将图片保存下来直接上传(img-BGaJjtIf-1661937273597)(C:\Users\hp-pc\AppData\Local\Temp\1660036728940.png)]$
在这里插入图片描述

数据分片

在这里插入图片描述

4.3MySQL服务器硬件优化

（1）配置较大的内存

（2）配置高速磁盘系统

（3）合理分布磁盘I/O

（4）配置多处理器

4.4MySQL的参数优化

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的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓存；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。MySQL8.0之后失效。该参数需要和query_cache_type配合使用。
query_cache_type 的值是0时，所有的查询都不使用查询缓存区。但是query_cache_type=0并不会导致MySQL释放query_cache_size所配置的缓存区内存。
- 当query_cache_type=1时，所有的查询都将使用查询缓存区，除非在查询语句中指定 SQL_NO_CACHE ，如SELECT SQL_NO_CACHE * FROM tbl_name。
- 当query_cache_type=2时，只有在查询语句中使用 SQL_CACHE 关键字，查询才会使用查询缓存区。使用查询缓存区可以提高查询的速度，这种方式只适用于修改操作少且经常执行相同的查询操作的情况。
sort_buffer_size ：表示每个需要进行排序的线程分配的缓冲区的大小。增加这个参数的值可以提高 ORDER BY 或 GROUP BY 操作的速度。默认数值是2 097 144字节（约2MB）。对于内存在4GB 左右的服务器推荐设置为6-8M，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。
join_buffer_size = 8M ：表示联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每个连接独享。
read_buffer_size ：表示每个线程连续扫描时为扫描的每个表分配的缓冲区的大小（字节）。当线程从表中连续读取记录时需要用到这个缓冲区。SET SESSION read_buffer_size=n可以临时设置该参数的值。默认为64K，可以设置为4M。
innodb_flush_log_at_trx_commit ：表示何时将缓冲区的数据写入日志文件，并且将日志文件写入磁盘中。该参数对于innoDB引擎非常重要。该参数有3个值，分别为0、1和2。该参数的默认值为1。
- 值为 0 时，表示每秒1次的频率将数据写入日志文件并将日志文件写入磁盘。每个事务的 commit并不会触发前面的任何操作。该模式速度最快，但不太安全，mysqld进程的崩溃会导致上一秒钟所有事务数据的丢失。
- 值为 1 时，表示每次提交事务时将数据写入日志文件并将日志文件写入磁盘进行同步。该模式是最安全的，但也是最慢的一种方式。因为每次事务提交或事务外的指令都需要把日志写入（flush）硬盘。
- 值为 2 时，表示每次提交事务时将数据写入日志文件，每隔1秒将日志文件写入磁盘。该模式速度较快，也比0安全，只有在操作系统崩溃或者系统断电的情况下，上一秒钟所有事务数据才可能丢失。
innodb_log_buffer_size ：这是 InnoDB 存储引擎的事务日志所使用的缓冲区。为了提高性能，也是先将信息写入 Innodb Log Buffer 中，当满足 innodb_flush_log_trx_commit 参数所设置的相应条件（或者日志缓冲区写满）之后，才会将日志写到文件（或者同步到磁盘）中。
max_connections ：表示允许连接到MySQL数据库的最大数量，默认值是 151 。如果状态变量 connection_errors_max_connections 不为零，并且一直增长，则说明不断有连接请求因数据库连接数已达到允许最大值而失败，这是可以考虑增大max_connections 的值。在Linux 平台下，性能好的服务器，支持 500-1000 个连接不是难事，需要根据服务器性能进行评估设定。这个连接数不是越大越好，因为这些连接会浪费内存的资源。过多的连接可能会导致MySQL服务器僵死。
back_log ：用于控制MySQL监听TCP端口时设置的积压请求栈大小。如果MySql的连接数达到 max_connections时，新来的请求将会被存在堆栈中，以等待某一连接释放资源，该堆栈的数量即 back_log，如果等待连接的数量超过back_log，将不被授予连接资源，将会报错。5.6.6 版本之前默认值为 50 ，之后的版本默认为 50 + （max_connections / 5），对于Linux系统推荐设置为小于512 的整数，但最大不超过900。如果需要数据库在较短的时间内处理大量连接请求，可以考虑适当增大back_log 的值。
thread_cache_size ：线程池缓存线程数量的大小，当客户端断开连接后将当前线程缓存起来，当在接到新的连接请求时快速响应无需创建新的线程。这尤其对那些使用短连接的应用程序来说可以极大的提高创建连接的效率。那么为了提高性能可以增大该参数的值。默认为60，可以设置为 120。
wait_timeout ：指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
interactive_timeout ：表示服务器在关闭连接前等待行动的秒数。

4.5数据库结构优化

拆分表：冷热数据分离
增加中间表
增加冗余字段

在数据量大，而且需要频繁进行连接的时候，为了提升效率，我们也可以考虑增加冗余字段来减少连接。
会报错。5.6.6 版本之前默认值为 50 ，之后的版本默认为 50 + （max_connections / 5），对于Linux系统推荐设置为小于512 的整数，但最大不超过900。如果需要数据库在较短的时间内处理大量连接请求，可以考虑适当增大back_log 的值。
thread_cache_size ：线程池缓存线程数量的大小，当客户端断开连接后将当前线程缓存起来，当在接到新的连接请求时快速响应无需创建新的线程。这尤其对那些使用短连接的应用程序来说可以极大的提高创建连接的效率。那么为了提高性能可以增大该参数的值。默认为60，可以设置为 120。
wait_timeout ：指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
interactive_timeout ：表示服务器在关闭连接前等待行动的秒数。