重启时的 Mysql 内部

Question

我们有一个庞大的数据库，并加载了许多程序来处理报告，其中一些程序全天每 5 分钟调用一次。

数据库在其他方面表现良好，但如果我不每天重新启动 mysql 一次，过去需要几毫秒才能执行的查询需要几分钟甚至几小时才能完成。如果 mysql 不是每天重启，即使 mysqldump（基于时间戳列的数据选择性转储）通常在 15 分钟内完成，也需要 3-4 小时才能完成。

任何人都可以帮助我了解 mysql 在重新启动时在内部做什么。我们在我们的过程中使用了很多临时表。这些会引起争用吗？

Answer 1

我在回答中引用了官方 MySQL 5.7 文档。这个问题有一个不断发展的状态，（希望）将包含尽可能多的信息。

mysqld，也称为 MySQL 服务器，是在 MySQL 安装中完成大部分工作的主程序。MySQL Server 管理对包含数据库和表的 MySQL 数据目录的访问。数据目录也是其他信息（如日志文件和状态文件）的默认位置。

当 MySQL 服务器启动时，它会侦听来自客户端程序的网络连接并代表这些客户端管理对数据库的访问。

mysqld 程序有很多可以在启动时指定的选项。运行此命令时，可以检索完整的选项列表：

shell> mysqld --verbose --help

在MySQL文档建议：

故障排除时，通常最好从命令提示符运行 MySQL 服务器，而不是通过 mysqld_safe 或作为 Windows 服务

如果你想在启动过程中查看 mysqld 服务启动或接触的内容，你可以直接在命令提示符下启动 mysqld：

shell> mysqld 

您可能会在启动过程中找到导致性能问题的信息。

如果您使用默认的 innoDB 配置，您将使用InnoDB 临时表撤消日志，它是在启动过程中初始化的临时表空间的一部分：

临时表空间在每次服务器启动时重新创建，并接收动态生成的空间 ID，这有助于避免与现有空间 ID 发生冲突。

临时表undo日志有限制：

MySQL 5.7.2 中引入的临时表撤消日志用于临时表和相关对象。这种类型的撤消日志不是重做日志，因为在崩溃恢复期间不会恢复临时表，并且不需要重做日志。但是，临时表撤消日志用于在服务器运行时进行回滚。这种特殊类型的非重做撤消日志通过避免临时表和相关对象的重做日志记录 I/O 来提高性能。临时表撤消日志驻留在临时表空间中。默认的临时表空间文件 ibtmp1 默认位于数据目录中，并且始终在服务器启动时重新创建。可以通过设置 innodb_temp_data_file_path 来指定临时表空间文件的用户定义位置。

32个回滚段保留给临时表undo日志，用于修改临时表和相关对象的事务，这意味着生成undo记录的数据修改事务可用的最大回滚段数为96个。在96个可用回滚段的情况下，限制在并发数据修改事务上是 96K。有关更多信息，请参阅第 15.3 节“InnoDB 多版本控制”和第 15.8.8 节“InnoDB 表的限制”。

您可能会遇到创建临时对象的事务数高于此 96K 连接级别的问题。或者您可能只是生成了太多临时对象。

重新启动您的 MySQL 实例将（根据临时表空间文档）清理您的临时表空间和位于其中的所有临时表：

在正常关闭或中止初始化时删除临时表空间

鉴于提供的信息，我建议您检查临时对象，因为您的临时表空间可能有问题。