我想知道数据库 WAL 序列是否是无限的？我猜大多数 WAL 记录都有 WAL 编号的固定大小？这是一个非常大的数字，大到无法结束吗？这可能是相当浪费空间？还是大 DB 玩家发明了更好的方法？
或者他们是否实现了一些逻辑让 WAl 再次从 0 开始？这可能会对代码中的许多地方产生重大影响......？
编辑：
影响：例如，崩溃后的恢复依赖于沿时间线变大的序列号。如果序列可以重新开始，则恢复可能会变得混乱。
术语 WAL 序列号： WAL（预写日志，即在应用层收到事务成功之前保证在磁盘上的事务日志）。这个日志有一个不断增长的数字来保持数据库的一致性，例如在恢复的情况下，通过检查来自页面的 WAL 序列号与来自 WAL 的序列号。
I would not assume that every database implements the same strategy.
Speaking only for Oracle, the SCN (system change number) is a 48-bit number so an Oracle database can handle nearly 300 trillion transactions before hitting the limit. Realistically, that will take eons. Even if you could do 1 thousand transactions per second, the SCN wouldn't hit the limit for 300 billion seconds or roughly 9500 years. Now, there are various things that can cause the SCN to increment in addition to just doing transactions (famously the recent issue with hot backups and database links that caused a few users to exceed the database's checks for the reasonability of the SCN) so it won't really take 9500 years to hit the limit. But, realistically, it gives Oracle plenty of time to move to a 64-bit SCN some years down the line, buying everyone a few more centuries of functionality.
与 SQL Server 一样，DB2 调用对日志序列号(LSN) 进行计数。IBM 最近将其 LSN 的大小从 6 个字节扩大到 8 个字节，无符号。LSN 是一个不断增长的指针，它显示在日志文件中可以找到特定日志记录的位置。一个 8 字节的 LSN 意味着 DB2 数据库在地址空间用完之前可以写入近 16 exbibytes的日志记录，此时必须卸载数据库的内容并将其复制到一个新的数据库中。
Postgres WAL 数字在技术上可以溢出，但只有在写入 32 Eb 数据之后，因为 WAL 文件指针是 64 位的
在 PostgreSQL 中，WAL 日志存储为一组段文件。“段文件被赋予不断增加的数字作为名称，从 000000010000000000000000 开始。” 数字没有环绕。
请参阅什么是 LSN：日志序列号。本文描述了 SQL Server LSN（WAL 编号）的结构，并向您展示了如何对其进行解码。由于 LSN 的大小是固定的并且它们不会翻转，因此您可能会用完它们。不过，这将需要很长时间。