哈希表的插入复杂度如何为 O(1)答案

【问题标题】：How can the insertion complexity for a hashtable be O(1)哈希表的插入复杂度如何为 O(1)
【发布时间】：2016-01-25 22:46:54
【问题描述】：

我正在创建一个哈希表并从一个未排序的数组中插入n 元素。当我调用哈希函数n 时。创建/插入哈希表的时间复杂度不是O(n) 吗？

我尝试到处搜索，但他们提到了发生冲突时的复杂性，但没有说明如何在完美的情况下在 O(1) 中创建哈希表，因为我必须遍历数组才能选择第一个元素加一并放入哈希表中？

【问题讨论】：

您想让插入时间保持不变吗？是吗？
@ViniciusZaramella 不，如果我已经遍历数组中的每个元素以便将它们一一插入到哈希表中，我无法理解如何将哈希表插入为 0(1)。如果我有 10 个元素，我将运行哈希函数 10 次，以找到每个元素在哈希表中的位置。
是的，但是 (O(n)) 是用数组的内容填充哈希表的复杂性。 O(1) 是关于一次插入的复杂性。
不确定，可能是因为更重要的是要知道在哈希表中插入值的时间不会随着哈希表的大小而增加。
这有点像说“为什么我们以公里/小时而不是米/秒来衡量汽车的速度”——它更多地表示我们通常行驶的距离和时间范围。加载表时以及之后的任何时间都可能发生插入。它是更有用的单元，并且与删除或查找等其他操作相比更容易。

标签： hashtable time-complexity

【解决方案1】：

当将新记录插入哈希表时，使用完美哈希函数，将立即找到未使用的索引条目（用于指向记录），给出 O(1)。稍后搜索时会立即找到该记录。

当然，哈希函数很少是完美的。随着散列索引开始填充，该函数有时需要两次或多次尝试找到未使用的索引条目以插入新记录，并且以后每次尝试搜索该记录也需要两次或多次尝试才能找到正确的索引条目被发现。因此，哈希表的实际搜索复杂度最终可能为 O(1.5) 或更高，但该值由搜索组成，其中记录最常在第一次尝试中找到，而其他记录可能需要两次或更多。

我想诀窍是找到一个“足够好”的哈希算法，这意味着在不太大的索引、相当低的平均复杂度和可接受的最坏情况之间进行折衷。

我发布了另一个搜索问题here，并展示了如何使用散列以及如何确定一个好的散列函数。该问题需要在包含 16000 条记录的表中查找 64 位值，并将其替换为记录中的另一个值。从第一个值计算第二个值是不可能的。我的算法的平均搜索复杂度为

【讨论】：