看到这个数据大家的第一个想法就是……
这特么是BUG了吧。
看到这个数字，几乎所有的程序员们，DNA都动了。
小学生们最敏感的数字可能是100，因为这是他们能够达到的上限。
而2147483647可能就是码农们最敏感的数字，至少是之一。
一般出现这个数字的时候，并不代表着就真的是这个数字，而是结果超纲了，只能显示这个数字。
当然了，更敏感的数据可能是-32768之类的，那就是溢出了，这个结果会更糟糕……
现在并不代表事情不糟糕，只是网站做了防溢出处理，看起来没那么糟糕而已。
毕竟，什么样的技术，能够直接把整个测试体系干穿？
这是不可能的。
可是，这个是平子大佬的比赛结果啊。
万一平子大佬真的把比赛干穿了呢？
等等，正因为是平子大佬，所以才更加不可能吧？
毕竟，世界上有两个真理：
一、世界上没有绝对的真理。
二、平子大佬不懂算法。
所以，到底是不是出了问题？
大家其实也不知道自己的内心到底期待着什么，但还是决定把这件事情的判定交给比赛的主办方。
于是，网站的后台，此时已经收到了雪花一般的网友提供的错误报告，告诉他们网站出错了，让他们赶快处理一下。
说实话，作为一个主打搞笑和抽象的编程大赛的主办方，这个主要由L站的高级会员组成的主席团，都是业余时间在做这件事情。
他们都是激进的技术主义者，并不怎么害怕出现什么问题，反而更注重效率。
这种思路和官方的比赛是完全相反的。
所以，这个这个天榜晋升系统其实也是自动的，只要积分够了之后，就会自动晋升，而不需要任何一个关键决策者的允许之类的。
反正，对这种搞笑和抽象的比赛来说，就算是出现问题，也只是乐子中的插曲，只要及时纠正就好了，相比之下，即时反应变化才是更重要的。
这也是这个竞赛系统被开发出来的初衷。
换句话说，在参赛者们拼尽全力迭代自己的数据库查询方案的时候，其实这个主办方的网站，也在一刻不停的迭代和维护，以应对越来越多的访问者以及越来越多的代码量，不断优化测试方式和时间，不断减少资源压力，以及不断以更快的速度反映变化，让大家能够第一时间感知到自己努力的结果。
至于结果会不会出错，只要不是大问题就无所谓，毕竟也不会有人来追责他们，对吧。
陈雁行就是主办方的主要成员之一，作为L站的联合创始人和技术顾问之一，他也是这次比赛的最大技术支持与服务器赞助商。
因为这场比赛涉及到了唐一平，而自己作为【0xT1P】大佬唐师傅的同辈人以及亲密战友，或者说作为一个“长辈”，参与进去终归是不好。
毕竟这是在代写作业——不管这事儿演变成了什么，最初也是为了代写作业。
这种动机，就是不好的，自己作为长辈，不能鼓励这种事情。
至少陈雁行是这么觉得的。
他骨子里还是一个比较传统的男人来着。
所以他只是在背后暗戳戳的推动了这场比赛的大型化和规模化，以及贡献了这个网站的大部分代码而已。
什么坏事儿也没做。
就是……看乐子。
乐子人怎么能算是坏人呢？是吧。
所以，在看到了雪花一般的报错的时候，作为可能是最强的独立网安专家之一的陈雁行，看到报错的第一个想法就是不可能。
因为网站的代码是他写的，测试程序和方案也是他出的，就连测试集都是他弄来的真实测试集——他不可能出这么大的差错。
他又不是一个初出茅庐的菜鸟，他可能会犯错误，但是绝对不会在这种简单的问题上犯错误。
但如果自己不可能出错，那他就要面对第二个不可能。
这个测试结果是对的？
这更不可能吧！
毕竟那可是平子大佬，不会算法的平子大佬！
平子大佬写出来FORK-Cane这种项目一点也不奇怪，毕竟平子大佬本身就是工程暴力美学的奇迹代言人。
但是算法？
我宁愿相信门口摆摊卖饭的大叔是秦始皇。
这么想着，陈雁行打开了网站后台的日志，调出了平子大佬的测试日志。
作为网安专家，陈雁行的“看日志”是一门绝活。
速度快到夸张。
只是扫了一眼，他就发现，没问题。
至少是日志绝对显现不出来的问题。
没办法了，他只能再自己手动跑一遍测试了。
调出唐一平提交的代码，导入了由他提供的那个数据量为50万的学生档案测试集。
这是一个巨大的csv文档，整体大小大概500M。
陈雁行自己估算过，如果把这些文本文档，转成数据库的格式，理论数据量应该是50M左右。
这是其有效熵值转换成的比特数，也就是这个测试集本身蕴含的信息的比特数。
但是这种单纯的数据是不能使用和检索的，所以才会有“数据库”这种东西，把信息编码索引，安排好位置。
换言之，单纯的信息就像是无数的人，数据库就是盖上一栋大楼，把他们放进各自的房间。
这就要在本身的数据基础上，加上B-tree或者其他tree的索引、哈希表等等，就像是楼梯楼层和门牌号。
通常来说，这些数据转换成数据库格式之后，整体数据量大概在200M-300M。
这大概就是地榜排名前几的水平，其实能做到这个数量级就已经很强了。
但但如果是天榜的话，目前已经强到离谱了。
譬如现在焦灼在天榜前列的两个ID：“递归之梦”和“等待戈多”，已经把这个数据压缩到了130M左右。
在这个数据集上，已经可以和商用数据库相媲美，甚至在某些方面犹有过之了，当然，也不同程度的呈现出了过拟合，算是针对性优化。
陈雁行把自己的数据集导入了唐一平的项目里。
导入的速度很快，而且CPU占用率很高，几乎是瞬间拉满，然后导入完成。
陈雁行再次跑了一遍测试流程。
测试结果一行行的输出，和陈雁行在日志里面看到的一模一样，片刻之后，一模一样的分数出现。
2147483647。
这不对啊，这不可能。
莫非他真的是秦始皇？
作为一个网络安全的大佬，其实陈雁行首先就是个测试方面的专家，他设计的测试用例和测试程序非常完善。
还是那句话。
可能出错，但不可能出现这种低级错误。
陈雁行拉出来了测试细分项，就看到了测试的平均响应时间。
0ms（毫秒）？
果然出错了吧。
正常来说，这种体量的数据库的简单查询应该在几十毫秒。
等等，莫非是查询速度快到了四舍五入之后都是0？
直接低了一到两个数量级。
这会儿，陈雁行其实遇到了和奎哥一样的问题。
位数不够，显示不全的问题。
可是，谁特么的数据库测试响应时间，需要用到比毫秒还小的单位啊！
陈雁行一边吐槽着，一边打开了自己的测试程序，修改了一下代码，把统计单位变成了μs（微秒）。
然后又跑了一遍测试。
这次结果终于显示正常了。
不，陈雁行觉得这次更不正常了。
因为测试最终的结果显示为23μs。
合着，不是零点几毫秒，是零点零二毫秒！
特么的，这可不是四舍五入到0了吗？
自己之前的测试集能够显示出来才怪！
再特么的，系统的测试噪声都快要10μs了好吗！
读数据的延迟都要10μs了好吗？
你咋不飞呢？
这怎么可能？
这个查询结果有问题吧。
真的有问题吧。
对不起啊，平子大佬，我不是故意要这对你，但是我得把这个问题找出来啊……