关于mysql:第48问为什么-MySQL-运行时-不鼓励调整系统时间

0次阅读

共计 746 个字符,预计需要花费 2 分钟才能阅读完成。

在 MySQL 运行时,咱们调整零碎工夫,会造成什么影响么?

试验

按常规,咱们造个数据库:

在一个会话里,进行 vsleep:

在 sleep 的同时,咱们将服务器的工夫向将来调整 10 秒:

咱们会发现,sleep 立即退出,只执行了 0.82 秒:

咱们在业务中很少会用到 sleep,那么调整零碎工夫会有更大的影响么?咱们再来看看:

咱们在一个会话中,锁住一张表:

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

  1. 先打印一个工夫戳
  2. 调整 lock_wait_timeout
  3. 拜访 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 的技术内容,你们还有什么想晓得的吗?连忙留言通知小编吧!

正文完
 0