Closed. This question needs details or clarity. It is not currently accepting answers. Learn more。
想改进这个问题吗？添加细节并通过editing this post澄清问题。
好吧，书名很能说明问题。
（Q1）堆栈溢出的问题是10000000吗？
但是，因为它可能不是（尽管我做了一个“尝试”）：
（q2）哪个问题是堆栈溢出的10000000？
我意识到这还不完全是一个编程问题，所以我将尝试把它变成一个：
（Q3）在没有管理员访问堆栈溢出数据库的情况下，如何确定哪个是堆栈溢出问题N？
几小时前我在参观Stack Overflow时想到了这些。那个问讯台引起了我的注意，因为它像个标价牌（都是9英镑）。我承认我没有考虑太多所以也许有一个明显的答案，但我现在看不到。
我“试过”的东西
显然，发布的问题总数T是要考虑的一个参数（即questions page右上角的计数器）。然而，它与任何具体问题都没有直接关系。我也怀疑这只是一个近似的实际价值，因为我刚才看到它上下几次。所以它可能每几分钟就被精确评估一次导致这种行为的另一个原因可能是问题也可以被删除。我可能在清理的时候发现了这个系统因此，可能有不止一个“问题编号N”但一定有第一个以及“最后一个”，待问题在发布前停止删除或“不太可能”在发布后被删除时确定。
我能想到的第二个“线索”是问题url。格式如下：
https://stackoverflow.com/questions/<id>/<title>
id部分和
T似乎是相关的。这两个值之间的差异并不是一个常数，尽管今天早些时候它大约为22107000，并且以相对“缓慢”的速度增加。这可能是因为
id是一个聚合计数器（我怀疑它同时计算问题和答案，可能更多）因此，除非你对问题的数量和/或答案的数量是如何随着时间的推移而演变有一个整体的看法，否则这不是一条路要走。
由于整个系统的分布式设置以及上述参数难以准确跟踪（至少是普通用户），似乎很难对上述任何一个问题给出答案（如果它们首先定义得很好的话）。所有这些都表明，可能没有确切的答案，而是应该进行概率讨论。因此，试图把这个问题定为10000000，首先是没有希望的。
尽管我看不出所有这些都有什么实际的用处（至少从普通用户的角度来看是这样），但我并不是唯一一个对此感到疑惑的人还有其他想法吗？
对于一些用户来说，我的问题似乎有点不清楚（尽管我确实收到了一个适当的答案，在被搁置之前解决了我心中的问题）所以我会尝试重新措辞。
在下图中，您可以看到问题计数器（标记为（1），上面称为
T）。这个计数器的值是由某种逻辑改变的。理想情况下，每当一个新问题满足所有要求时，这样的计数器都会增加1，而且永远不会减少。然而，这一次却时不时地下降。所以，第一个问题是：改变计数器值的逻辑是什么？
另外，我想知道是哪个问题把这个计数器的值从9999999变成了10000000。由于修改
T值的逻辑性质，此更改可能会多次发生。为了简化问题，我很好奇是哪一个问题先做的。这个问题是标记为（2）的横幅消息合法化所需的最后一步，这就是我上面所说的“问题编号10000000”。
如果有办法确定这个问题，一个可以接受的答案将以指向它的url的形式出现，并证明这确实是我正在寻找的问题。任何可能相关的想法都是受欢迎的（因为修改
T值的逻辑毕竟可能不是确定性的）。
http://stackoverflow.com/questions/4
给我看问题4。
ID 1-ID 3已删除。如果你检查这个id
http://stackoverflow.com/questions/1/where-oh-where-did-the-joel-data-go/的自动生成的URL，你会发现它是来自“joel”的问题在页面上，它说：“这个问题是出于适度的原因从堆栈溢出中删除的。”-->这是很自我解释的（我想可能是一些开发人员测试，或者无用的混乱）。
我也认识到，如果我使用一个不存在的ID，它会将我重定向到“最近”ID。表示与给定URL参数的最小差值的ID。例如，id 341888将重定向到id 341743:
http://stackoverflow.com/questions/341743/c-string-that-can-be-null/关于上述事实，我认为不可能确定
问题是（甚至曾经是）10000000，因为其中很多被删除了
出于适度的原因等。
我希望这能有帮助。