2月4日DOTA2协调服务器维护 已开21亿战局，2月4日早上8点DOTA2将会维护，维护时间大学在1小时。

翻译：NGA

Dota2游戏协调服务器将会在太平洋时间下午4点进行停机维护，届时无法进行新的游戏，但正在进行的游戏则不受影响———当然游戏结果和任务完成情况会推迟结算。如果一切顺利的话，Dota2游戏协调服务器大约会停机一个小时左右，我们将会在推特上报告最新的情况。

在很久以前我们认为32位整型可以编号约43亿场比赛，用作场次ID编号应该是足够了，然而事实证明我们想的太简单了。

我们的数据库并不支持unsigned的整型，于是总的数据量变成了2^31≈21亿4千万左右，并且我们还搞了好多东西让编号池用的更快了：

比如说游戏刚匹配到就立即分配一个场次ID，哪怕这局游戏并没有成功开始，甚至所有的离线人机游戏我们都给分配了场次ID……

于是乎，这个32位的编号池远比我们想象中用的快的多……

总之，现在就快用完了，不知道有没有人注意到，当前最大的游戏场次ID已经超过了21亿了?

为此我们一直在进行数据架构的更新，使用64位场次ID来进行编号。 (以下涉及数据库知识，看不懂可以跳过)

SQL语言在更改列大小的时候一般都很好使，分分钟就搞定;原有的存储着数据的行在写入新数据时自动就扩展了大小

然而当某列是一个表的主键，或者该表的索引包括了该列时，你就没法轻松搞定了，只能重建这个表。

而我们的一大堆表里都是这样，用了场次ID当做主键或索引………还好这些表还不算容量特别大，我们还重建的起。

不过，所有场次ID的数据加起来还是很大的，大约有170亿行，6TB大小，全部迁移到新表里的话可能需要一个星期时间。如果进行迁移我们也可以顺便优化一下这些数据

在服务器停机维护的期间我们将把过去几个小时的场次ID从旧表迁移到新的64位表内，以后都用新表了，然后协调服务器就重新上线，如果一切正常那就妥了!

下次我们2038年再见了!

(译注1：卧槽你什么意思，几个小时之前的都不管了是吗?)

(译注2：2038年很多计算机将会遇到“新千年虫”问题，有兴趣可以自己搜索“2038年问题”

同志们，我们已经玩了快21亿局DOTA2了。

通过水友的解释，2038年原来是32位计算时间库可以达到的最高年份(最高数值 从1970年开始 到2038年)，V社这个梗玩的好。