mysqldump 备份数据库发现备份的.sql文件比原文件小 为什么

这种情况可能就是数据库没有完全备份下来，数据不完整；如果小一点，差别不大也是正常范围；最好是在本地恢复下看看数据完整度；另外数据库在备份过程中有压缩的话，也会小很多，像国内的多备份工具，也是利用mysqldump，同时有加密压缩功能，还节省存储空间

MySQL在崩溃恢复时，会遍历打开所有ibd文件的headerpage验证数据字典的准确性，如果MySQL中包含了大量表，这个校验过程就会比较耗时。MySQL下崩溃恢复确实和表数量有关，表总数越大，崩溃恢复时间越长。另外磁盘IOPS也会影响崩溃恢复时间，像这里开发库的HDDIOPS较低，因此面对大量的表空间，校验速度就非常缓慢。另外一个发现，MySQL8下正常启用时居然也会进行表空间校验，而故障恢复时则会额外再进行一次表空间校验，等于校验了2遍。不过MySQL80里多了一个特性，即表数量超过5W时，会启用多线程扫描，加快表空间校验过程。

如何跳过校验MySQL57下有方法可以跳过崩溃恢复时的表空间校验过程嘛？查阅了资料，方法主要有两种：

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 connectors

与其他编程语言中的sql 语句进行交互，如php、java等。

2 Management Serveices & Utilities

系统管理和控制工具

3 Connection Pool (连接池)

管理缓冲用户连接，线程处理等需要缓存的需求

4 SQL Interface (SQL接口)

接受用户的SQL命令，并且返回用户需要查询的结果。比如select from就是调用SQL Interface

5 Parser （解析器）

SQL命令传递到解析器的时候会被解析器验证和解析。

主要功能：

a 将SQL语句分解成数据结构，并将这个结构传递到后续步骤，后面SQL语句的传递和处理就是基于这个结构的

b 如果在分解构成中遇到错误，那么就说明这个sql语句是不合理的，语句将不会继续执行下去

6 Optimizer (查询优化器)

SQL语句在查询之前会使用查询优化器对查询进行优化(产生多种执行计划,最终数据库会选择最优化的方案去执行,尽快返会结果) 他使用的是“选取-投影-联接”策略进行查询。

用一个例子就可以理解：select uid,name from user where gender = 1;

这个select 查询先根据where 语句进行选取，而不是先将表全部查询出来以后再进行gender过滤

这个select查询先根据uid和name进行属性投影，而不是将属性全部取出以后再进行过滤

将这两个查询条件联接起来生成最终查询结果

以上就是关于mysqldump 备份数据库发现备份的.sql文件比原文件小 为什么全部的内容，包括:mysqldump 备份数据库发现备份的.sql文件比原文件小 为什么、mysql数据库崩溃的原因(mysql崩溃恢复)、IBDII的工作原理等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！