Dol*_*hin 4 postgresql locking vacuum
由于aVACUUM FULL锁表，这对于我们的生产环境来说是不可接受的。
是否可以只在生产系统上运行VACUUM而不运行？VACUUM FULL
是否可以VACUUM让空间重新用于新的INSERT用途？
Vér*_*ace 10
为了了解之间的差异
\nVACUUMVACUUM ANALYZEVACUUM FULL,需要对 PostgreSQL 的架构有基本的了解。
\n来自几个9s 1我们得知：
\n\n\n\n
\n- \n
PostgreSQL不使用IN-PLACE更新机制，因此根据DELETE和UPDATE命令的设计方式，
\n\n
\n- 每当执行 DELETE 操作时，它都会将现有元组标记为 DEAD，而不是物理删除这些元组。
\n- 类似地，每当执行 UPDATE 操作时，它都会将相应的现有元组标记为 DEAD 并插入一个新元组（即\nUPDATE 操作 = DELETE + INSERT）。
\n
这会导致所谓的“膨胀”——即表会变得更大，即使记录数量由于这些死元组而保持不变，表也会变得更大。
\n来自EnterpriseDB 2中，我们有：
\n\n\n\n
\n- 当真空进程运行时，这些死元组占用的空间被标记为可被其他元组重用。
\n
这类似于删除文件系统中的文件 - 该空间仅被标记为可重用，并且实际上没有删除任何内容。这并不重要 - 需要注意的重要一点是，该行占用的空间再次可供PostgreSQL 服务器用于该表！
\n和之间的主要区别在于，使用 时，释放的空间也可供操作系统使用！如果您希望执行备份并且磁盘空间不足，这可能会很有用。从这里：VACUUMVACUUM FULLVACUUM FULL
\n\n\n
\n- Vacuum full 取出独占锁并重建表，以便它没有空块（我们现在假设填充因子为 100%）。
\n
因此，VACUUM FULL类似于对磁盘文件进行碎片整理（考虑磁盘文件 \xe2\x89\xa1 PostgreSQL 表），从Percona 3我们有：
\n\nVACUUM FULL 是 PostgreSQL 安装中可用的默认选项，它允许我们重建表。[强调我的]
\n
但是，此重建确实需要Access Exclusive Lock，正如手册指出的那样：
\n\n\n\n
\n- \n
独家访问
\n与所有模式（ACCESS SHARE、ROW SHARE、ROW EXCLUSIVE、SHARE UPDATE EXCLUSIVE、SHARE、SHARE ROW EXCLUSIVE、\nEXCLUSIVE 和 ACCESS EXCLUSIVE）的锁冲突。此模式保证持有者是唯一以任何方式访问该表的事务。[强调我的]
\n
显然，正如您所指出的，完全重写该表对于生产来说并不好。手册甚至说
\n\n\n\n
\n- 通常，仅当需要从表内回收大量空间时才应使用此方法。
\n
所以，回答你的两个问题：
\n\n\n真空使空间可重复用于新插入件吗？
\n
是的，确实如此，但更重要的是，它不需要访问独占锁。从文档中中我们发现：
\n\n\nAutovacuum 工作人员通常不会阻止其他进程。
\n
Autovacuum是一个VACUUM不带FULL并且通常配置在postgresql.conf。
VACUUM获取 SHARE UPDATE EXCLUSIVE 锁。
再次，从手册：
\n\n\n此模式可保护表免受并发架构更改和 VACUUM 运行的影响。
\n
或者正如一位知识渊博的 PostgreSQL 贡献者所解释的那样：
\n\n\nAutovacuum 确实对表进行了锁定，但它是一个弱锁，不会干扰正常操作（SELECT、UPDATE、\nDELETE），但会干扰添加索引或\n截断表等操作。
\n
上面引用的 EnterpriseDB 博客提供了“VACUUM 和 ANALYZE 最佳实践技巧” - 就我个人而言，我通常会建议ANALYZE更新VACUUM优化器的表统计信息！本文还可以帮助您决定何时需要运行VACUUM。
主题中提出的问题。
\n\n\nPostgreSQL 中是否有可能永远不运行 Vacuum Full？
\n
是的，有可能永远不会运行它，特别是在不担心磁盘空间的情况下。然而，这可能是值得的，因为完整的表重写（连同索引）可以对查询性能产生有益的影响 - 按物理顺序的记录可以导致需要扫描的页面更少！
\n这是一个复杂的问题，完整的答案将是不可能长的，但我强烈建议您阅读这篇文章- 有点过时，但概述很好 - （还有这里的页面，这里，这里（填充因子）和这里）。
\n当然，您不希望VACUUM在繁忙时中断您的生产系统。决定最佳策略与 IT 领域的其他几乎所有事情都是一样的 -"It depends!"。
需要考虑磁盘空间和 I/O 负载参数，您必须达成最适合所有利益相关者的折衷方案。
\n1) multiple9s 是一个关于 PostgreSQL 所有内容的优秀网站。
\n 2）EnterpriseDB也是一个优秀的网站，也是最大的PostgreSQL公司，拥有大量的核心团队成员和贡献者。
\n 3) Percona 虽然以前是一家 MySQL 公司，但现在也有 PostgreSQL 发行版，并且他们赞助了有前途的pg_stat_monitor扩展（另请参阅此处）。他们受到高度重视。
| 归档时间： |
|
| 查看次数： |
3946 次 |
| 最近记录： |