mysql数据库突然变慢 数据库变慢是什么原因

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 变量，想法破灭。

打开数据库管理器，选择驱动器MBE，保存退出重启ifix。

ifix自定义报表没有按预想的将历史数据呈现出来，

这里仅针对如下场景：确定你的报表程序无错。

检查电脑时间格式设置，是否与你程序中时间格式相同。

检查ifix历史库，看你需要保存历史数据的点位有没有添加进去并激活。

检查SCU配置任务看HTCEXE有没有添加进去。

组态软件是在自动控制系统监控层一级的平台和开发环境下，用户无需编写计算机程序，使用灵活的组态方式，通过简单的类似“搭积木”的方式快速构建工业自动控制系统监控功能的、通用层次的软件工具。用户构建过程包括：选择控制系统的结构、选择数据采集模块的种类、选择信号的量程和转换、选择和配置各种控制策略、绘制 *** 作员界面等。

因此，使用组态软件开发监控系统具有时间短、效率高、可靠性好、不需要购买专用的工控系统、能适应不同的控制系统和不同控制场合的应用要求等优点。可以连接不同的控制系统，实现与控制系统之间的通信和数据交换，以图形、表格或实时曲线的方式直观地显示控制系统中的数据，并可以方便地对数据设置报警、保存等管理功能。

---