MySQL 在崩溃恢复时，会遍历打开所有 ibd 文件的 header page 验证数据字典的准确性，如果 MySQL 中包含了大量表，这个校验过程就会比较耗时。 MySQL 下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘 IOPS 也会影响崩溃恢复时间，像这里开发库的 HDD IOPS 较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL 8 下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了 2 遍。不过 MySQL 8.0 里多了一个特性，即表数量超过 5W 时，会启用多线程扫描，加快表空间校验过程。
网站建设哪家好，找创新互联！专注于网页设计、网站建设、微信开发、成都小程序开发、集团企业网站建设等服务项目。为回馈新老客户创新互联还提供了东坡免费建站欢迎大家使用！
如何跳过校验MySQL 5.7 下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：
1. 配置 innodb_force_recovery可以使 srv_force_recovery != 0 ，那么 validate = false，即可以跳过表空间校验。实际测试的时候设置 innodb_force_recovery =1，也就是强制恢复跳过坏页，就可以跳过校验，然后重启就是正常启动了。通过这种临时方式可以避免崩溃恢复后非常耗时的表空间校验过程，快速启动 MySQL，个人目前暂时未发现有什么隐患。2. 使用共享表空间替代独立表空间这样就不需要打开 N 个 ibd 文件了，只需要打开一个 ibdata 文件即可，大大节省了校验时间。自从听了姜老师讲过使用共享表空间替代独立表空间解决 drop 大表时性能抖动的原理后，感觉共享表空间在很多业务环境下，反而更有优势。
临时冒出另外一种解决想法，即用 GDB 调试崩溃恢复，通过临时修改 validate 变量值让 MySQL 跳过表空间验证过程，然后让 MySQL 正常关闭，重新启动就可以正常启动了。但是实际测试发现，如果以 debug 模式运行，确实可以临时修改 validate 变量，跳过表空间验证过程，但是 debug 模式下代码运行效率大打折扣，反而耗时更长。而以非 debug 模式运行，则无法修改 validate 变量，想法破灭。
安全地关闭MySQL实例
关闭过程：
1、发起shutdown，发出 SIGTERM信号
2、有必要的话，新建一个关闭线程(shutdown
thread)
如果是客户端发起的关闭，则会新建一个专用的关闭线程
如果是直接收到 SIGTERM 信号进行关闭的话，专门负责信号处理的线程就会负责关闭工作，或者新建一个独立的线程负责这个事
当无法创建独立的关闭线程时（例如内存不足），MySQL Server会发出类似下面的告警信息：
?
1Error: Can't create thread to kill server
3、MySQL Server不再响应新的连接请求
关闭TCP/IP网络监听，关闭Unix Socket等渠道
4、逐渐关闭当前的连接、事务
空闲连接，将立刻被终止；
当前还有事务、SQL活动的连接，会将其标识为 killed，并定期检查其状态，以便下次检查时将其关闭；（参考 KILL 语法）
当前有活跃事务的，该事物会被回滚，如果该事务中还修改了非事务表，则已经修改的数据无法回滚，可能只会完成部分变更；
如果是Master/Slave复制场景里的Master，则对复制线程的处理过程和普通线程也是一样的；
如果是Master/Slave复制场景里的Slave，则会依次关闭IO、SQL线程，如果这2个线程当前是活跃的，则也会加上 killed
标识，然后再关闭；
Slave服务器上，SQL线程是允许直接停止当前的SQL操作的（为了避免复制问题），然后再关闭该线程；
在MySQl
5.0.80及以前的版本里，如果SQL线程当时正好执行一个事务到中间，该事务会回滚；从5.0.81开始，则会等待所有的操作结束，除非用户发起KILL操作。
当Slave的SQL线程对非事务表执行操作时被强制 KILL了，可能会导致Master、Slave数据不一致；
5、MySQL Server进程关闭所有线程，关闭所有存储引擎；
刷新所有表cache，关闭所有打开的表；
每个存储引擎各自负责相关的关闭操作，例如MyISAM会刷新所有等待写入的操作；InnoDB会将buffer pool刷新到磁盘中（从MySQL
5.0.5开始，如果innodb_fast_shutdown不设置为 2 的话），把当前的LSN记录到表空间中，然后关闭所有的内部线程。
6、MySQL Server进程退出
关于KILL指令
从5.0开始，KILL 支持指定 CONNECTION | QUERY两种可选项：
KILL CONNECTION和原来的一样，停止回滚事务，关闭该线程连接，释放相关资源；
KILL
QUERY则只停止线程当前提交执行的操作，其他的保持不变；
提交KILL操作后，该线程上会设置一个特殊的
kill标记位。通常需要一段时间后才能真正关闭线程，因为kill标记位只在特定的情况下才检查：
1、执行SELECT查询时，在ORDER BY或GROUP BY循环中，每次读完一些行记录块后会检查
kill标记位，如果发现存在，该语句会终止；
2、执行ALTER TABLE时，在从原始表中每读取一些行记录块后会检查 kill
标记位，如果发现存在，该语句会终止，删除临时表；
3、执行UPDATE和DELETE时，每读取一些行记录块并且更新或删除后会检查 kill
标记位，如果发现存在，该语句会终止，回滚事务，若是在非事务表上的操作，则已发生变更的数据不会回滚；
4、GET_LOCK()
函数返回NULL；
5、INSERT
DELAY线程会迅速内存中的新增记录，然后终止；
6、如果当前线程持有表级锁，则会释放，并终止；
7、如果线程的写操作调用在等待释放磁盘空间，则会直接抛出逗磁盘空间满地错误，然后终止；
8、当MyISAM表在执行REPAIR
TABLE 或 OPTIMIZE TABLE 时被 KILL的话，会导致该表损坏不可用，指导再次修复完成。
安全关闭MySQL几点建议
想要安全关闭 mysqld 服务进程，建议按照下面的步骤来进行：
0、用具有SUPER、ALL等最高权限的账号连接MySQL，最好是用 unix socket
方式连接；
1、在5.0及以上版本，设置innodb_fast_shutdown = 1，允许快速关闭InnoDB（不进行full
purge、insert buffer
merge），如果是为了升级或者降级MySQL版本，则不要设置；
2、设置innodb_max_dirty_pages_pct =
0，让InnoDB把所有脏页都刷新到磁盘中去；
3、设置max_connections和max_user_connections为1，也就最后除了自己当前的连接外，不允许再有新的连接创建；
4、关闭所有不活跃的线程，也就是状态为Sleep
且 Time 大于 1 的线程ID；
5、执行 SHOW PROCESSLIST
确认是否还有活跃的线程，尤其是会产生表锁的线程，例如有大数据集的SELECT，或者大范围的UPDATE，或者执行DDL，都是要特别谨慎的；
6、执行
SHOW ENGINE INNODB STATUS 确认History list
length的值较低（一般要低于500），也就是未PURGE的事务很少，并且确认Log sequence number、Log flushed up
to、Last checkpoint at三个状态的值一样，也就是所有的LSN都已经做过检查点了；
7、然后执行FLUSH LOCKAL TABLES
操作，刷新所有 table cache，关闭已打开的表（LOCAL的作用是该操作不记录BINLOG）；
8、如果是SLAVE服务器，最好是先关闭
IO_THREAD，等待所有RELAY LOG都应用完后，再关闭 SQL_THREAD，避免 SQL_THREAD
在执行大事务被终止，耐心待其全部应用完毕，如果非要强制关闭的话，最好也等待大事务结束后再关闭SQL_THREAD；
9、最后再执行 mysqladmin
shutdown。
10、紧急情况下，可以设置innodb_fast_shutdown = 1，然后直接执行 mysqladmin shutdown
即可，甚至直接在操作系统层调用 kill 或者 kill -9 杀掉 mysqld 进程（在innodb_flush_log_at_trx_commit = 0
的时候可能会丢失部分事务），不过mysqld进程再次启动时，会进行CRASH RECOVERY工作，需要有所权衡。
auto_increment设置这个会自动增加了，这个增加时在现有的ID基础上的，如果 你数据库还是空记录的话，最好添加一条完整记录，然后在插入数据的时候，就可以不用设置ID
