第37问：自旋锁 旋着旋着人就糊涂了

问题

追求 MySQL 的性能时，总据说要调整自旋锁的参数: innodb_spin_wait_delay 和 innodb_sync_spin_loops，是真的么？

实验

首先咱们要知道自旋锁的优势：自旋锁要上锁时，若是须要等待其余线程释放锁，那么：

• 在等待锁的过程当中会先线程会先自旋一段时间

  • 自旋阶段，线程不会放弃 CPU

• 自旋事后：

  • 若是能够获取锁了，那么响应会比较快（自旋没发生上下文切换）
  • 若是还须要等待锁，再用更高成本的方式进行锁等待

innodb_spin_wait_delay 参数决定了自旋阶段的长度。如今咱们试着调整 innodb_spin_wait_delay 参数，来测试一下：

先宽油起一个数据库，此处忽略步骤

建个表，放点数据：

配置好 performance_schema：

检查一下相关参数：

清理 performance_schema 的统计值：

来点压力：

查询一下锁等待成本最高的锁：

能够看到锁等待成本最高的是 lock_mutex，是保护 MySQL 锁系统的锁

下面咱们来调整一下 innodb_spin_wait_delay，让自旋的时间变长：

重作一次压力（记得先清理统计数据），查看统计数据：

能够看到 lock_mutex 的平均等待时间从 751267 增长到了 1399041。咱们让自旋阶段增长了 10 倍，锁等待的时间也会随之增大。

目前的实验看上去自旋阶段越短越好，那么自旋阶段是否是就没有意义了？固然不会。

你们能够将 innodb_spin_wait_delay 设置为 1，再进行测试，随着自旋阶段的减小，锁等待的时间也会随之增大（大部分锁都使用了高成本的方式来进行等待）。

那么如何选择自旋的参数呢？咱们建议“不出问题不瞎调”。

在以前的统计数据中，时间的单位是：cycle，根据如下换算表，锁的平均时间是 1399041 cycle，大概也就 0.5ms（1399041 / 2385353233 = 0.00058 s），占 SQL 的总体时间很低，能够不用瞎调。

一个著名的 CPU 问题

自旋阶段，MySQL 会调用 CPU 的 PAUSE 指令，既能占用了 CPU，同时 PAUSE 指令（比起其余占用 CPU 的指令）也比较节能。

不过既然占用了 CPU，那么就会体如今 CPU 的使用率上。

如今咱们将 innodb_spin_wait_delay 再放大一点比较一下：

能够看到 CPU 使用率会随着自旋阶段变长而升高

Intel 的 Skylake 系列 CPU，调大了 PAUSE 指令的周期时长。从 10 cycles 调大到 140 cycles（也许是由于让 PAUSE 周期变长更有利于节能）

相似于今天的实验，这个指令的调整至关于拉长了自旋阶段。

这就致使了在 Skylake 系列 CPU 下，MySQL 的锁表现和 CPU 占用率表现都有可能更糟糕。

（推荐文章：https://tech.meituan.com/2020...

小贴士

看到这里你们是否是开始焦虑了，要准备换 CPU 了？

其实没必要焦虑，绝大部分状况下，你们不用追求极致的性能。比起榨取服务器的一点点极限性能，业务稍微调整一下 SQL 取得的收益会 大几个数量级。

俗话说：业务写得好，运维回家早。

---

关于 MySQL 的技术内容，大家还有什么想知道的吗？赶忙留言告诉小编吧！