共计 1761 个字符，预计需要花费 5 分钟才能阅读完成。
| 导读 | 每个 binlog 文件都有编号，从最早的 3 位数（没错，很老的版本只有 3 位数~），到现在扩展到 6 位数，从 000001 开始计数。但我打赌，你一定不知道这个序号最大可以跑到多少。 |
在我们知数堂的 MySQL DBA 课上讲到 binlog 序号是从 000001 开始，这时有细心的同学问到，是不是这个序号达到 999999 后，binlog 就要重新开始了？
讲真，当时我也是一下子被问住了，只是隐约记得这个值是可以大于 999999 的。于是，课后我自己细致地探究了一番，遂有本文。
MySQL 在启动时会扫一下 binlog 文件，找到最大的序号，然后产生下个序号文件。根据这个规则，我们可以自行测试一下，若当前最大的 binlog 序号是 999999 时，下一个文件序号是重新从 000001 开始，抑或是 1000000 呢？
把 mysqld 关掉，人为造出序号为 999999 的 binlog，并直接启动 mysqld，看看会怎样呢？
执行 show master status 进行确认
可以看到，mysqld 并没有挂掉，也没重新从 mysql-bin.000001 开始，这个序号会继续增加。
现在，我们再深挖下这个问题，最大的序号到底是多少呢？
我们课上教学使用的版本是 mysql 5.7.18，下载相应版本的源码直接看好了，在 sql/binlog.cc 文件中我们找到下面这段代码：
在上面这段代码中，我们看到如下判断：
if (max_found == MAX_LOG_UNIQUE_FN_EXT)也就是当找到 binlog 文件最大序号，达到起定义的最大值时，mysqld 就会退出。我们再看下 MAX_LOG_UNIQUE_FN_EXT 宏定义：
#define MAX_LOG_UNIQUE_FN_EXT 0x7FFFFFFF把它转成十进制看下：
这个值等于：pow(2,31) – 1
手动创建一个序号较大的 binlog，比如 mysql-bin.2147483640。把所有日志文名都写入到 mysql-bin.index 中，并确认 mysql-bin.000001 文件存在（看会不会被覆盖或者其他的）。
然后启动 mysqld，再执行 FLUSH LOGS，看看会怎样。
这时，我们能看到 mysqld 启动，日志里记录的告警信息：
我们多执行几次 FLUSH LOGS，切换日志，直到序号达到最大值，看看会发生什么：
第一次切换会发出一个 ERROR 级别错误日志，第二次再切换，直接导致 mysqld 进程退出了。看看错误日志：
看这架势，是想生成 mysql-bin.(1-999) 这样的文件而未果。于是我们再进行下面的测试。
还是 touch 一个较大序号的 binlog，比如 mysql-bin.2147483646。把所有日志文名都写入到 mysql-bin.index 中，并确认 mysql-bin.000001 文件到 mysql-bin.000999 这些文件都不存在（和测试二不同，这次是要确保这些文件不存在，看能不能重复利用）。
然后启动 mysqld，再执行 FLUSH LOGS，看看会怎样。
可以看到，还是会退出，并没有进行日志的轮转再次重复利用。
1.binlog 的最大序号是 pow(2,31)-1=2147483647。
2. 当序号接近这个值，且差距小于 1000 时（也就是序号大于 2147482647 时），就开始向 errorlog 中写入警告。
3. 当序号达到最大值时，mysqld 进程直接退出。
4. 生成新的 binlog 时，会扫描当前已存在的 binlog 文件，最终取得最大序号值。因此，如果 binlog 文件数目特别多的话，是会影响 MySQL 的启动及日志切换效率的。
5. 由此可见有两个隐患，当 binlog 文件数目过大，会导致 binlog 切换效率较低。当 binlog 文件最大序号快达到最大值时，离 mysqld 进程挂掉就不远了，需要加急处理。
6. 因此，除了要监控 binlog 文件数目、最大序号外，还应该再 errorlog 的内容，都予以足够重视。
