我想知道创建索引后 CREATE INDEX 和 CREATE INDEX CONCURRENTLY(如果有)之间有什么区别。我一直在和一位同事讨论他们的工作方式。
我的理解是,CREATE INDEX 对表进行完全锁定以快速构建索引,从而导致停机时间,但对于 CREATE INDEX CONCURRENTLY 仅对表进行部分锁定。这意味着当表有写入时,会为每个新事务/插入计算索引,并且只要没有事务/插入发生,它就会“回填”或处理已存在数据的索引。一旦这个“回填”过程完成,CREATE INDEX 和 CREATE INDEX CONCURRENTLY 之间就没有严格的区别。
我同事的理解是,CREATE INDEX CONCURRENTLY 的行为有所不同,即使在“回填过程”完成后,CREATE INDEX CONCURRENTLY 的写入负载强度仍然较低。
有人可以让我们更好地了解索引创建的工作原理吗?什么时候我们可以说索引已经创建了?每当插入数据时索引创建完成后会发生什么?使用 CONCURRENTLY 与不使用 CONCURRENTLY 时索引构建完成后的计算是否有差异?
区别仅在于索引的构建方式,但一旦完成,结果是相同的。同时创建的索引可能会有些膨胀,但这种差异在一段时间后会趋于平衡。
区别在于“它如何工作”。这是关于“多久?” 和“我们可以在索引时间内阻止索引表的更改吗?”。结果是一样的。
Any 都
CREATE INDEX
应该扫描其表,对目标字段中的值进行排序,然后存储结果。常规的会锁定表。这意味着在索引创建完成之前不能处理 INSERT、UPDATE 或 DELETE 查询。在生产中,根据数据量,可能需要很长时间。更改查询可能会超时,并且服务可能部分无法运行。SELECT 查询使用此锁可以正常工作。但从总的数据库处理时间来看,这样的请求将是最优且快速的。只需要1次全表扫描和排序。
CONCURRENT 不会产生 LOCK。因此任何更新都可以流入表中。更改查询将按预期进行。但索引将花费更多时间。这个操作至少需要2次全表扫描和排序。如果在操作期间发生更改,则 - 更新新的索引数据并再次扫描。该步骤可以重复多次。因此,它的执行并不是最优的,并且比基础执行需要更多的时间和资源。
希望这会有所帮助。