# 5、优化数据库结构

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

5.1.拆分表：冷热数据分离

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

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

（3）举例
① 会员 members 表存储会员登录认证信息，该表中有很多字段，如 id、姓名、密码、地址、电话、个人描述字段。其中地址、电话、个人描述等字段并不常用，可以将这些不常用的字段分解出另一个表。将这个表取名叫 members_detail，表中有 member_id、address、telephone、description 等字段。这样就把会员表分成了两个表，分别为 members 表和 members_detail 表。

② 创建这两个表的SQL语句如下：

CREATE TABLE members ( 
id int(11) NOT NULL AUTO_INCREMENT, 
username varchar(50) DEFAULT NULL, 
password varchar(50) DEFAULT NULL, 
last_login_time datetime DEFAULT NULL, 
last_login_ip varchar(100) DEFAULT NULL, 
PRIMARY KEY(Id) 
);

CREATE TABLE members_detail ( 
Member_id int(11) NOT NULL DEFAULT 0, 
address varchar(255) DEFAULT NULL, 
telephone varchar(255) DEFAULT NULL, 
description text 
);

③ 如果需要查询会员的基本信息或详细信息，那么可以用会员的 id 来查询。如果需要将会员的基本信息和详细信息同时显示，那么可以将members 表和 members_detail 表进行联合查询，查询语句如下：

SELECT * FROM members LEFT JOIN members_detail on members.id = members_detail.member_id;
1
④ 通过这种分解可以提高表的查询效率。对于字段很多且有些字段使用不频繁的表，可以通过这种分解的方式来优化数据库的性能。

5.2.增加中间表

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

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

（3）举例
① 学生信息表和班级表的建表 SQL 语句如下：

CREATE TABLE `class` ( 
`id` INT(11) NOT NULL AUTO_INCREMENT, 
`className` VARCHAR(30) DEFAULT NULL, 
`address` VARCHAR(40) DEFAULT NULL, 
`monitor` INT NULL , PRIMARY KEY (`id`) 
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

CREATE TABLE `student` ( 
`id` INT(11) NOT NULL AUTO_INCREMENT, 
`stuno` INT NOT NULL,
`name` VARCHAR(20) DEFAULT NULL, 
`age` INT(3) DEFAULT NULL, 
`classId` INT(11) DEFAULT NULL, 
PRIMARY KEY (`id`) 
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

② 现在有一个模块需要经常查询带有学生名称 (name)、学生所在班级名称 (className)、学生班级班长 (monitor) 的学生信息。根据这种情况可以创建一个 temp_student 表。temp_student 表中存储学生名称 (stu_name)、学生所在班级名称 (className) 和学生班级班长(monitor) 信息。创建表的语句如下：

CREATE TABLE `temp_student` ( 
`id` INT(11) NOT NULL AUTO_INCREMENT, 
`stu_name` INT NOT NULL , 
`className` VARCHAR(20) DEFAULT NULL, 
`monitor` INT(3) DEFAULT NULL, 
PRIMARY KEY (`id`) 
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8;

③ 接下来，从学生信息表和班级表中查询相关信息存储到临时表中：

insert into temp_student(stu_name,className,monitor) 
select s.name,c.className,c.monitor from student as s,class as c where s.classId = c.id

以后，可以直接从 temp_student 表中查询学生名称、班级名称和班级班长，而不用每次都进行联合查询。这样可以提高数据库的查询速度。

如果用户信息修改了，是不是会导致 temp_student 中的数据不一致的问题呢？如何同步数据呢?
方式 1：清空数据→重新添加数据；
方式 2：使用视图；

3.3.增加冗余字段

（1）设计数据库表时应尽量遵循范式理论的规约，尽可能减少冗余字段，让数据库设计看起来精致、优雅。但是，合理地加入冗余字段可以提高查询速度。表的规范化程度越高，表与表之间的关系就越多，需要连接查询的情况也就越多。尤其在数据量大，而且需要频繁进行连接的时候，为了提升效率，我们也可以考虑增加冗余字段来减少连接。

（2）这部分内容在MySQL高级篇知识点——数据库的设计规范这篇文章的第 3 节已经具体讲解过，此处就不再赘述了。

3.4.优化数据类型

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

（2）列的字段越大，建立索引时所需要的空间也就越大，这样一页中所能存储的索引节点的数量也就越少，在遍历时所需要的 I/O 次数也就越多，索引的性能也就越差。具体来说：
① 情况 1：对整数类型数据进行优化
1）遇到整数类型的字段可以用 INT 型 。这样做的理由是，INT 型数据有足够大的取值范围，不用担心数据超出取值范围的问题。刚开始做项目的时候，首先要保证系统的稳定性，这样设计字段类型是可以的。但在数据量很大的时候，数据类型的定义，在很大程度上会影响到系统整体的执行效率。
2）对于非负型的数据（如自增 ID、整型 IP）来说，要优先使用无符号整型 UNSIGNED 来存储。因为无符号相对于有符号，同样的字节数，存储的数值范围更大。如 tinyint 有符号为 -128~127，无符号为 0 ~ 255，多出一倍的存储空间。

② 情况 2：既可以使用文本类型也可以使用整数类型的字段，要选择使用整数类型
跟文本类型数据相比，大整数往往占用更少的存储空间 ，因此，在存取和比对的时候，可以占用更少的内存空间。所以，在二者皆可用的情况下，尽量使用整数类型，这样可以提高查询的效率。如：将 IP 地址转换成整型数据。

③ 情况 3：避免使用 TEXT、BLOB 数据类型
1）MySQL 内存临时表不支持 TEXT、BLOB 这样的大数据类型，如果查询中包含这样的数据，在排序等操作时，就不能使用内存临时表，必须使用磁盘临时表。并且对于这种数据，MySQL 还是要进行二次查询，会使 SQL 性能变得很差，但是不是说一定不能使用这样的数据类型。
2）如果一定要使用，建议把 BLOB 或是 TEXT 列分离到单独的扩展表中，查询时一定不要使用 select *，而只需要取出必要的列，不需要 TEXT 列的数据时不要对该列进行查询。

④ 情况 4：避免使用 ENUM 类型
修改 ENUM 值需要使用ALTER语句，并且 ENUM 类型的 ORDER BY 操作效率低，需要额外操作，可使用 TINYINT 来代替 ENUM 类型。

⑤ 情况 5：使用 TIMESTAMP 存储时间
TIMESTAMP 存储的时间范围 1970-01-0100:00:01 ~ 2038-01-19-03:14:07。TIMESTAMP 使用 4 字节，而 DATETIME使用 8 个字节，同时TIMESTAMP 具有自动赋值以及自动更新的特性。

⑥ 情况 6：用 DECIMAL 代替 FLOAT 和 DOUBLE 存储精确浮点数
1）非精准浮点：float，double
2）精准浮点：decimal
Decimal 类型为精准浮点数，在计算时不会丢失精度，尤其是财务相关的金融类数据。占用空间由定义的宽度决定，每 4 个字节可以存储 9 位数字，并且小数点要占用一个字节。可用于存储比 bigint 更大的整型数据。

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

3.5.优化插入记录的速度

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

a.MyISAM 引擎的表

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

ALTER TABLE table_name DISABLE KEYS;
1
重新开启索引的语句如下：

ALTER TABLE table_name ENABLE KEYS;
1
若对于空表批量导入数据，则不需要进行此操作，因为 MyISAM 引擎的表是在导入数据之后才建立索引的。

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

SET UNIQUE_CHECKS=0;
1
开启唯─性检查的语句如下：

SET UNIQUE_CHECKS=1;
1
（3）使用批量插入
插入多条记录时，可以使用一条 INSERT 语句插入一条记录，也可以使用一条 INSERT 语句插入多条记录。插入一条记录的INSERT语句情形如下：

insert into student values(1,‘zhangsan’,18,1);
insert into student values(2,‘lisi’,17,1);
insert into student values(3,‘wangwu’,17,1);
insert into student values(4,‘zhaoliu’,19,1);
1
2
3
4
使用一条 INSERT 语句插入多条记录的情形如下：

insert into student values (1,‘zhangsan’,18,1), (2,‘lisi’,17,1), (3,‘wangwu’,17,1), (4,‘zhaoliu’,19,1);
1
第 2 种情形的插入速度要比第 1 种情形快。

（4）使用 LOAD DATA INFILE 批量导入
当需要批量导入数据时，如果能用 LOAD DATA INFILE 语句，就尽量使用。因为 LOAD DATA INFILE 语句导入数据的速度比 INSERT 语句快。

3.5.2.InnoDB 引擎的表
（1）禁用唯一性检查
插入数据之前执行 set unique_checks=0 来禁止对唯一索引的检查，数据导入完成之后再运行 set unique_checks=1。这个和 MylSAM 引擎的使用方法一样。

（2）禁用外键检查
插入数据之前执行禁止外键的检查，数据插入完成之后再恢复对外键的检查。禁用外键检查的语句如下：

SET foreign_key_checks=0;
1
灰复对外键的检查语句如下：

SET foreign_key_checks=1;
1
（3）禁止自动提交
插入数据之前禁止事务的自动提交，数据导入完成之后，执行恢复自动提交操作。禁止自动提交的语句如下：

set autocommit=0;
1
恢复自动提交的语句如下：

set autocommit=1;
1
3.6.使用非空约束
在设计字段的时候，如果业务允许，建议尽量使用非空约束。这样做的好处是：
① 进行比较和计算时，省去要对 NULL 值的字段判断是否为空的开销，提高存储效率。
② 非空字段也容易创建索引。因为索引 NULL 列需要额外的空间来保存，所以要占用更多的空间。使用非空约束，就可以节省存储空间（每个字段 1 个 bit）。

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

3.7.1.分析表
（1）MySQL 中提供了 ANALYZE TABLE 语句分析表，ANALYZE TABLE 语句的基本语法如下：

ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name]…
1
默认的，MySQL 服务会将 ANALYZE TABLE 语句写到 binlog 中，以便在主从架构中，从服务能够同步数据。可以添加参数 LOCAL 或者 NO_WRITE_TO_BINLOG 取消将语句写到 binlog 中。

（2）使用 ANALYZE TABLE 分析表的过程中，数据库系统会自动对表加一个只读锁。在分析期间，只能读取表中的记录，不能更新和插入记录。ANALYZE TABLE 语句能够分析 InnoDB 和 MyISAM 类型的表，但是不能作用于视图。

（3）ANALYZE TABLE 分析后的统计结果会反应到 cardinality 的值，该值统计了表中某一键所在的列不重复的值的个数。该值越接近表中的总行数，则在表连接查询或者索引查询时，就越优先被优化器选择使用。也就是索引列的 cardinality 的值与表中数据的总条数差距越大，即使查询的时候使用了该索引作为查询条件，存储引擎实际查询的时候使用的概率就越小。下面通过例子来验证下。cardinality 可以通过 SHOW INDEX FROM 表名查看。

（4）下面我们举例说明。
① 使用下面的语句创建一张 user1 表，并向其中添加 1000 条数据。

USE atguigudb3;

# 创建 user1 表
CREATE TABLE `user1` (
  `id` INT NOT NULL AUTO_INCREMENT,
  `name` VARCHAR(255) DEFAULT NULL,
  `age` INT DEFAULT NULL,
  `sex` VARCHAR(255) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_name` (`name`) USING BTREE
) ENGINE=INNODB AUTO_INCREMENT=1 DEFAULT CHARSET=utf8mb3;

SET GLOBAL log_bin_trust_function_creators = 1;

DELIMITER //
CREATE FUNCTION  rand_num (from_num INT ,to_num INT) RETURNS INT(11)
BEGIN   
DECLARE i INT DEFAULT 0;  
SET i = FLOOR(from_num +RAND()*(to_num - from_num+1))   ;
RETURN i;  
END //
DELIMITER ;

DELIMITER //
CREATE PROCEDURE  insert_user( max_num INT )
BEGIN  
DECLARE i INT DEFAULT 0;   
 SET autocommit = 0;    
 REPEAT  
 SET i = i + 1;  
 INSERT INTO `user1` ( NAME,age,sex ) 
 VALUES ("atguigu",rand_num(1,20),"male");  
 UNTIL i = max_num  
 END REPEAT;  
 COMMIT; 
END //
DELIMITER;

# 调用存储过程
CALL insert_user(1000);

# 查看表中的记录(需要注意的是目前所有的 name 的值均为 "atguigu")
SELECT * FROM user1;

② 此时查看 user1 表上的索引。

SHOW INDEX FROM user1;
1

根据上图我们可以看到主键索引的 Cardinality 值为 1000，而索引 idx_name 的为 1。原因在于主键 id 是唯一的，1000 条记录就有 1000 个不同的 id，所以其区分度非常高，即 Cardinality 值为 1000；而 name 字段的值均为 “atguigu”，所以其区分度非常低，即 Cardinality 值为 1。

③ 接下来，我们进行如下操作：

# 更新一条记录的 name 字段
UPDATE user1 SET NAME = 'atguigu03' WHERE id = 3;

# 分析表
ANALYZE TABLE user1;

# 再次查看索引
SHOW INDEX FROM user1;

此时根据上图可知，索引 idx_name 的 Cardinality 值变为 2 了，其原因在于我们刚才更新了 id = 3 的记录的 name 字段，所以此时 name 字段中有 999 个 “atguigu” 和 1 个 “atguigu03”，即 Cardinality 值为 2。

3.7.2.检查表
（1）MySQL 中可以使用 CHECK TABLE 语句来检查表。CHECK TABLE 语句能够检查 InnoDB 和 MyISAM 类型的表是否存在错误。CHECK TABLE 语句在执行过程中也会给表加上只读锁。

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

CHECK TABLE tbl_name [, tbl_name] … [option] … option = {QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
1
其中，tbl_name 是表名；option 参数有5个取值，分别是 QUICK、FAST、MEDIUM、EXTENDED 和 CHANGED。各个选项的意义分别是：

QUICK 不扫描行，不检查错误的连接
FAST 只检查没有被正确关闭的表
CHANGED 只检查上次检查后被更改的表和没有被正确关闭的表
MEDIUM 扫描行，以验证被删除的连接是有效的。也可以计算各行的关键字校验和，并使用计算出的校验和验证这一点
EXTENDED 对每行的所有关键字进行一个全面的关键字查找。这可以确保表是100%一致的，但是花的时间较长
（3）option 只对 MyISAM 类型的表有效，对 InnoDB 类型的表无效。比如：

该语句对于检查的表可能会产生多行信息。最后一行有一个状态的 Msg_type 值，Msg_text 通常为 OK。如果得到的不是 OK，通常要对其进行修复；是 OK 说明表已经是最新的了。表已经是最新的，意味着存储引擎对这张表不必进行检查。

3.7.3.优化表
3.7.3.1.方式1：OPTIMIZE TABLE
（1）MySQL中使用 OPTIMIZE TABLE 语句来优化表。但是，OPTILMIZE TABLE 语句只能优化表中的 VARCHAR、BLOB 或 TEXT 类型的字段。一个表使用了这些字段的数据类型，若已经删除了表的一大部分数据，或者已经对含有可变长度行的表（含有 VARCHAR、BLOB 或TEXT 列的表）进行了很多更新 ，则应使用 OPTIMIZE TABLE 来重新利用未使用的空间，并整理数据文件的碎片。

（2）OPTIMIZE TABLE 语句对 InnoDB 和 MyISAM 类型的表都有效。该语句在执行过程中也会给表加上只读锁。 OPTILMIZE TABLE 语句的基本语法如下：

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name]…
1
LOCAL | NO_WRITE_TO_BINLOG 关键字的意义和分析表相同，都是指定不写入二进制日志。

（3）执行完毕，上图中的 Msg_text 显示：

‘Table does not support optimize, doing recreate + analyze instead’
1
原因是服务器上的 MySQL 是 InnoDB 存储引擎。到底优化了没有呢？看官网https://dev.mysql.com/doc/refman/8.0/en/optimize-table.html！

在 MyISAM 中，是先分析这张表，然后会整理相关的 MySQL datafile，之后回收未使用的空间；在 InnoDB 中，回收空间是简单通过 Alter table 进行整理空间。在优化期间，MySQL 会创建一个临时表，优化完成之后会删除原始表，然后会将临时表 rename 成为原始表。

说明： 在多数的设置中，根本不需要运行 OPTIMIZE TABLE。即使对可变长度的行进行了大量的更新，也不需要经常运行，每周一次或 每月一次即可，并且只需要对特定的表运行。

（4）举例
① 新建一张表，使用存储过程往里面放入 100W 数据，或者更多一些，争取能够以兆的单位显示；
② 查看服务器上数据文件的大小，文件目录是 /var/lib/mysql/ 所在的数据库；
③ 删除二分之一的数据，然后再查看当前数据文件的大小，会发现此时大小是不变的；
④ 使用 OPTIMIZE table 表名; 命令优化表；
⑤ 再查看当前数据文件的大小，会发现此时大小已经变化了，做了空间的回收。

优化前：

优化后：

3.7.3.2.方式2：使用 mysqlcheck 命令
（1）mysqlcheck 命令格式如下

mysqlcheck -o DatabaseName TableName -u root -p******
1
mysqlcheck 是 Linux中的 rompt，-o 是代表 Optimize。

（2）举例：优化所有的表

mysqlcheck -o DatabaseName -u root -p******
mysqlcheck -o --all-databases -u root -p******
1
2

3.8.小结
上述这些方法都是有利有弊的。比如：
（1）修改数据类型，节省存储空间的同时，要考虑到数据不能超过取值范围；
（2）增加冗余字段的时候，不要忘了确保数据一致性；
（3）把大表拆分，也意味着查询会增加新的连接，从而增加额外的开销和运维的成本。
因此，一定要结合实际的业务需求进行权衡。

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

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

4.2.读/写分离
经典的数据库拆分方案，主库负责写，从库负责读。
（1）一主一从模式：

（2）双主双从模式：

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

如果数据库中的数据表过多，可以采用垂直分库的方式将关联的数据表部署在同一个数据库上。
如果数据表中的列过多，可以采用垂直分表的方式，将一张数据表分拆成多张数据表，把经常一起使用的列放到同一张表里。

垂直拆分的优点： 可以使得列数据变小，在查询时减少读取的 Block 数，减少 I/O次 数。此外，垂直分区可以简化表的结构，易于维护。
垂直拆分的缺点： 主键会出现冗余，需要管理冗余列，并会引起 JOIN 操作。此外，垂直拆分会让事务变得更加复杂。
4.4.水平拆分
（1）尽量控制单表数据量的大小，建议控制在 1000 万以内。1000 万并不是 MySQL 数据库的限制，过大会造成修改表结构、备份、恢复都会有很大的问题。此时可以用历史数据归档（应用于日志数据），水平分表（应用于业务数据）等手段来控制数据量大小。

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

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

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

（5）下面补充一下数据库分片的两种常见方案：
① 客户端代理：分片逻辑在应用端，封装在 jar 包中，通过修改或者封装 JDBC 层来实现。 当当网的 Sharding-JDBC 、阿里的 TDDL 是两种比较常用的实现。
② 中间件代理：在应用和数据中间加了一个代理层。分片逻辑统一维护在中间件服务中。我们现在谈的 Mycat 、360 的 Atlas、网易的 DDB 等等都是这种架构的实现。

5.其它调优策略
5.1.服务器语句超时处理
（1）在 MySQL 8.0 中可以设置服务器语句超时的限制，单位可以达到毫秒级别。当中断的执行语句超过设置的毫秒数后，服务器将终止查询影响不大的事务或连接，然后将错误报给客户端。

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

SET GLOBAL MAX_EXECUTION_TIME=2000;

指定该会话中 SELECT 语句的超时时间

SET SESSION MAX_EXECUTION_TIME=2000;
1
2
3
4
5.2.创建全局通用表空间
（1）MySQL 8.0 使用 CREATE TABLESPACE 语句来创建一个全局通用表空间。全局表空间可以被所有的数据库的表共享，而且相比于独享表空间，使用手动创建共享表空间可以节约元数据方面的内存。可以在创建表的时候，指定属于哪个表空间，也可以对已有表进行表空间修改等。下面创建名为 atguigu1 的共享表空间，SQL 语句如下：

CREATE TABLESPACE atguigu1 ADD datafile ‘atguigu1.ibd’ file_block_size=16k;
1
（2）指定表空间，SQL 语句如下：

CREATE TABLE test(id int, name varcfar(10)) engine=innodb default charset utf8mb4 tablespace atguigu1;
1
（3）也可以通过 ALTER TABLE 语句指定表空间，SQL 语句如下：

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

mysql> DROP TABLESPACE atguigu1;
Tablespace ‘atguigu1’ is not empty.
1
2
所以应该首先删除依赖该表空间的数据表，SQL语句如下：

DROP TABLE test;
1
最后即可删除表空间，SQL语句如下：

DROP TABLESPACE atguigu1;
1
5.3.MySQL 8.0新特性：隐藏索引对调优的帮助
（1）不可见索引的特性对于性能调试非常有用。在 MysQL 8.0中，索引可以被“隐藏"和“显示”。当一个索引被隐藏时，它不会被查询优化器所使用。也就是说，管理员可以隐藏一个索引，然后观察对数据库的影响。如果数据库性能有所下降，就说明这个索引是有用的，于是将其"恢复显示"即可；如果数据库性能看不出变化，就说明这个索引是多余的，可以删掉了。

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

（3）此外，需要注意的是数据表中的主键不能被设置为 invisible。