为什么我们只关注最坏情况时间复杂度（Big O），给定一个数据集和2个代码片段/算法，我们能否始终确保算法将采用最坏的情况复杂度？
简短的回答：你不应该只关心最坏情况的复杂性。
如果你有一个实际有界的情况，那么常数因子可能比渐近复杂性更重要。示例：假设您有10个项目的集合。您可以在字典/映射/散列表中进行O（1）查找，或者在排序列表中进行O（log N）查找，或者在未排序列表中进行O（N）查找。
对于10个项目，渐近复杂性很少。实际上，由于更大的常数因子，O（1）字典查找可能比O（log N）排序列表查找慢。
所以你应该只关注渐近的复杂性，当你有“很多”的东西时。
我们不仅关注最坏情况的时间复杂性（或者如果你是，你不应该） - 另见Meaning of average complexity when using Big-O notation。平均时间可能同样有效，但在许多情况下，您希望确保算法不会花费很长时间。作为一个例子，为什么你会更关心'最坏情况'：假设你可能不介意算法需要1或2秒*，但你想确保至少它不需要一个小时一些案例。
*是的，显然这在很多情况下非常重要，但假设它是一个需要运行一次的脚本。
问题的第二部分：不，我们不能总是确定“更复杂”的算法花费的时间最长（我假设通过'采取复杂性'，正如你所说，你的意思是'它有多长实际上是在特定情况下进行的。一个微不足道的反例是某种低效的“查找（第一次......）”算法恰好可以非常快速地获得指定项目，而另一种好的算法只需要更长时间，因为它会迭代文件/数组不同的顺序或方向。这显然将取决于很多数据，例如假设你感兴趣的值更有可能发生在文件/数组的末尾。
我认为所有三种类型的复杂性都很重要。这取决于你，你想要什么。
例如，有一个x尺寸的管子，你开始用水填充它。要知道水何时开始溢出，你会发现上限（尺寸或容量），即最坏情况下该管可容纳多少升水。
如果你想知道你的算法在最坏的情况下会如何表现，即在最坏的情况下我的算法需要多少时间和空间，那么你需要去BIG（o），即上边界。
同样，你也可以追求最佳和平均水平。