MySQL 5.7引入了组提交功能，组提交的两个参数binlog_group_commit_sync_delay和binlog_group_commit_sync_no_delay_count，如果设置不当，可能导致事务提交hung住。这个问题持续了多个版本，修改了两次源码，才最终完全修复。

第一次Bug：

见地址：https://bugs.mysql.com/bug.php?id=80652
根据Bug描述，当如下参数设置时，会触发事务提交hung住。

• binlog_group_commit_sync_delay设置为1~9
• binlog_group_commit_sync_no_delay_count设置为大于1

从官方提供的Release Note来看，这个Bug在5.7.17版本被修复。

对比一下 5.7.16 和 5.7.17 关于这个Bug的修改内容，源码文件位于 sql/binlog.cc 。

首先看5.7.16的这段代码，如下：

time_t Stage_manager::wait_count_or_timeout(ulong count, time_t usec, StageID stage)
{
  time_t to_wait=
    DBUG_EVALUATE_IF("bgc_set_infinite_delay", LONG_MAX, usec);
  /*
    For testing purposes while waiting for inifinity
    to arrive, we keep checking the queue size at regular,
    small intervals. Otherwise, waiting 0.1 * infinite
    is too long.
   */
  time_t delta=
    DBUG_EVALUATE_IF("bgc_set_infinite_delay", 100000,
                     static_cast<time_t>(to_wait * 0.1));

  while (to_wait > 0 && (count == 0 || static_cast<ulong>(m_queue[stage].get_size()) < count))
  {
#ifndef DBUG_OFF
    if (current_thd)
      DEBUG_SYNC(current_thd, "bgc_wait_count_or_timeout");
#endif
    my_sleep(delta);
    to_wait -= delta;
  }
  return to_wait;
}

函数中的参数count就是binlog_group_commit_sync_no_delay_count，参数usec就是binlog_group_commit_sync_delay，当usec为1~9时，delta 为0，to_wait一直大于0，同时count 大于0，所以在循环中长时间出不来，表现为事务提交一直hung住。

下面来看看5.7.17版本如何修复的，看如下代码：

void Stage_manager::wait_count_or_timeout(ulong count, ulong usec, StageID stage)
{
  ulong to_wait=
    DBUG_EVALUATE_IF("bgc_set_infinite_delay", LONG_MAX, usec);
  /*
    For testing purposes while waiting for inifinity
    to arrive, we keep checking the queue size at regular,
    small intervals. Otherwise, waiting 0.1 * infinite
    is too long.
   */
  ulong delta=
    DBUG_EVALUATE_IF("bgc_set_infinite_delay", 100000,
                     max<ulong>(1, (to_wait * 0.1)));

  while (to_wait > 0 && (count == 0 || static_cast<ulong>(m_queue[stage].get_size()) < count))
  {
#ifndef DBUG_OFF
    if (current_thd)
      DEBUG_SYNC(current_thd, "bgc_wait_count_or_timeout");
#endif
    my_sleep(delta);
    to_wait -= delta;
  }
}

从代码对比来看，把数据类型 time_t 换成了 ulong，且delta取值必须大于等于1。貌似结解了问题，但是没有彻底解决。

第二次Bug：

分析上述代码的逻辑，如果usec>20，且不是10的整数倍，比如21，那么delta为2，多次循环后，to_wait会变成-1，是负数，我们看to_wait是ulong类型，无符号长整形，越界变成一个很大很大的无符号整数，while循环无法退出。

这个新的Bug见链接：
https://bugs.mysql.com/bug.php?id=91055

根据官方文档，新的Bug在 5.7.24 和 8.0.13版本彻底解决。

我们来看下5.7.24版本是如何彻底解决的，如下：

void Stage_manager::wait_count_or_timeout(ulong count, long usec, StageID stage)
{
 long to_wait=
   DBUG_EVALUATE_IF("bgc_set_infinite_delay", LONG_MAX, usec);
 /*
   For testing purposes while waiting for inifinity
   to arrive, we keep checking the queue size at regular,
   small intervals. Otherwise, waiting 0.1 * infinite
   is too long.
  */
 long delta=
   DBUG_EVALUATE_IF("bgc_set_infinite_delay", 100000,
                    max<long>(1, (to_wait * 0.1)));

 while (to_wait > 0 && (count == 0 || static_cast<ulong>(m_queue[stage].get_size()) < count))
 {
#ifndef DBUG_OFF
   if (current_thd)
     DEBUG_SYNC(current_thd, "bgc_wait_count_or_timeout");
#endif
   my_sleep(delta);
   to_wait -= delta;
 }
}

仅仅修改了数据类型，将ulong改成了long，也就不存在to_wait 负数越界的问题了。

参考资料：
https://bugs.mysql.com/bug.php?id=80652
https://bugs.mysql.com/bug.php?id=91055
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-17.html
https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-24.html