第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 占用率表现都有可能更糟糕。小贴士
　　看到这里大家是不是开始焦虑了，要准备换 CPU 了？
　　其实不必焦虑，绝大部分情况下，大家不用追求极致的性能。比起榨取服务器的一点点极限性能，业务稍微调整一下 SQL 取得的收益会 大几个数量级。
　　俗话说：业务写得好，运维回家早。
　　相关推荐
　　关于 MySQL 的技术内容，你们还有什么想知道的吗？赶紧留言告诉小编吧！
　　本文关键字：#spin lock# #performance#