第48问（为什么 MySQL 运行时, 不鼓励调整系统时间） mysqltime

文章图片

问在 MySQL 运行时，我们调整系统时间，会造成什么影响么？
实验按惯例，我们造个数据库：

文章图片

在一个会话里，进行vsleep：

文章图片

在 sleep 的同时，我们将服务器的时间向未来调整 10 秒：

文章图片

我们会发现，sleep 立刻退出，只执行了0.82 秒：

文章图片

我们在业务中很少会用到 sleep，那么调整系统时间会有更大的影响么？我们再来看看：
我们在一个会话中，锁住一张表：

文章图片

在另一个会话中, 我们做如下几件事:

先打印一个时间戳
调整 lock_wait_timeout
访问 test.a 表

文章图片

此时, 我们调整系统时间, 向过去调整 10 秒：

文章图片

过一会，等访问 test.a 的请求超时了，我们来查看输出：

文章图片

我们将两个时间戳相减，算出这个锁持续了多久：
5375908 - 5375891 = 17 秒
由此我们知道：调整系统时间，会影响 MDL 的等待时间的计算

小贴士
此处我们获取系统时间的方法有点奇怪,是从 /proc/timer_list 中获取, 而并非使用date之类的函数
主要原因是: 当系统时间被调整, date等命令的输出也会受到影响.
我们想客观的评估 MySQL实际等待了多久, 除了手动掐秒表, 还可以利用单调时钟 (monotonic clock) 来进行计算.
单调时钟不会受到系统时间变化的影响, /proc/timer_list中的输出就是单调时钟的一种

除了以上的实验, 调整系统时间, 对正在运行的MySQL还会有其他影响, 比如说半同步的等待时间计算、延时复制的延时时间计算等等
我们不建议在 MySQL 运行时调整系统时间, 如需调整, 应及时重启 MySQL
思考题本文中我们测试了 MDL 的等待时间, 大家可以设计一个实验, 测试一下 InnoDB lock 的等待时间, 会发现很大的不同.
大家可以查阅资料, 来解释其中的不同.

文章图片

关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
【第48问（为什么 MySQL 运行时, 不鼓励调整系统时间）】