為什麼 SQL Server 內部版本號序列與發布日期序列不相關？
我正在查看Microsoft SQL Server 2016 Builds（請參閱該部分標題）。建構列表按建構編號順序給出。也就是說，列表頂部是“最高”的內部版本號，隨後的每一行的內部版本號都比前一行低。
但是，發布日期與此無關。所以這裡有 5 行，例如：
- 內部版本 13.0.5081.1 - 2018 年 8 月 14 日發布
- 內部版本 13.0.5101.9 - 2019 年 9 月 7 日發布
- 內部版本 13.0.5102.14 - 2020 年 11 月 2 日發布
- 內部版本 13.0.5149.0 - 2018 年 5 月 30 日發布
- 內部版本 13.0.5153.0 - 2018 年 7 月 17 日發布
大約在這個時候建構的一般順序來自 2018 年 - 然後我們有這 2 行奇數行，從 2019 年和 2020 年開始，然後又回到 2018 年的一般順序。
如果累積更新應該包含所有先前的累積更新，那麼最後一個版本（在上面的 5 個版本中）怎麼可能包含 2019 年和 2020 年兩個版本的更新？（糟糕——只注意到第一行是從八月開始的，也是在第四行和第五行之後！）
如果我在發佈時（分別在 2018 年 5 月和 2018 年 7 月）安裝了第 4 和第 5 版本，然後在 2018 年 8 月發布了第 1 版本 - 我會自動將這些更改合併嗎？如果是這樣，發布舊版本號的意義何在？
另一個例子
這是另一個對我來說毫無意義的例子。
首先，RTM 的日期為 2016 年 6 月。然後第一個累積更新 - CU1 - 的日期為 2017 年 7 月，即 CU2 於 2016 年 9 月發布後的 10 個月。嗯？
並閱讀底部的文字 - “在某些累積更新之後，Microsoft 發布了 SQL Server 服務包，其中包含以前的所有修復、累積更新和修補程序”。再說一遍？Note SP1 於 2016 年 11 月發布，9 個累積更新中的完整 7 個 - 更正，“以前的……累積更新”，根據標題 - 在Service Pack之後於 2017 年發布。
表來自MSSQLTips。
內部版本 13.0.5101.9 - 2019 年 9 月 7 日發布是 https://support.microsoft.com/en-us/help/4505220/kb4505220-security-update-for-sql-server-2016-sp2-gdr-july- 9-2019
內部版本 13.0.5102.14 - 2020 年 11 月 2 日發布是 https://support.microsoft.com/en-us/help/4532097/kb4532097-description-of-the-security-update-for-sql-server-2016- sp2-g
這些是通用分發版本 (GDR) 版本，旨在由執行受影響的 Service Pack 級別的所有客戶安裝。
基本上，這些是 SQL 2016 SP2 的關鍵更新檔，不需要安裝任何累積更新。
相關修復也將包含在下一個 CU 中，並且可能作為目前 CU 的修補程序提供。
至於內部版本號，GDR 是 CU 的一個獨立分支。將單個內部版本號系統應用於分支程式碼庫是很棘手的，但該策略似乎是將 GDR 內部版本號放置在公共根內部版本號 (SP2) 和第一個 CU (SP2 CU1) 之間。
如果我將系統升級到 13.0.5149.0，
那是 CU1，一旦你在“CU Train”上，你必須應用後續的 CU 來獲得修復。這就是為什麼 KB 說
若要應用此更新，您必須通過此 SQL Server 2016 SP2 GDR 安裝 SQL Server 2016 SP2 或任何 SQL Server 2016 SP2 GDR 版本。
在 SQL Server 2017 版本之前，存在 Service Pack (SP)。微軟為每個 SP 和 RTM 發布了安全更新。
例如，在這種特殊情況下，編號為 13.0.5081.1、13.0.5101.9 和 13.0.5102.14 的建構是 SQL Server 2016 SP2 GDR的安全更新。
如果我們在更新檔列表上查找，我們還會看到相同的安全更新，累積更新的發布日期也相同：
關於你的第二個問題，你名單上的日期不正確。您可以在以下 URL 上自行查看更新檔列表：
