问题标签 [vacuum]

我对命令 VACUUM 从删除的 SQL 语句中释放内存有一个大问题。

我正在制作一个 Cordova Android 应用程序，我知道当我使用 DELETE SQL 语句时，应用程序的空间不会关闭，......空间像碎片硬盘一样持续存在。

然后，我看到 VACUUM 可以压缩我的数据库，但我有一个问题！

我使用 SQLite3，所有站点中的 VACUUM 都说不能在事务中执行，如下所示：

好的，那么，如果我不能在事务中做，你能告诉我如何在不写行命令的情况下执行真空或自动真空或类似压缩 BD 的东西吗？（记住它是一个移动应用程序）

我已经对一个有 900 万行的 Postgres 表运行了一个完整的 VACUUM 并且我得到了这个：

详细信息：尚无法删除 0 个死行版本。CPU 8.98s/13.06u 秒经过 549.77 秒。查询成功返回，991788 毫秒无结果。

“329992可移动”是什么意思？为什么我会得到：

我的表已编入索引并具有主键，但在其上执行查询非常慢。

我的应用程序的数据库不断增长，我想执行 VACUUM 来检索一些丢失的空间。从我读过的内容来看，如果有其他事务，VACUUM 就不会运行。

我的问题是：如何从我的 SQLiteOpenHelper 运行命令？像db.execSQL("VACUUM")工作吗？但是如何在执行此操作时获得某种进展，以便可以使用加载对话框阻止 UI？

我将数据导入 PostgreSQL 数据库中的 30 个表（每个表也有索引和约束）。经过一番检查，我截断了所有表格并vacuum full analyze在所有表格上执行。确实释放了一些空间，但我确信需要释放更多数据。在导入之前，我的 PostgreSQL 目录大约是 20G。导入后增加到270G。目前数据目录大小为215G。

我运行这个选择：

结果是最大的表是 660M（现在只有 4 个表的大小大于 100M）。

数据/基础目录大小为 213G。

我也运行这个选择：

输出 ：

选择的输出不相同。

临时文件大小：

我还尝试重新启动 PostgreSQL 实例和 Linux 服务器。接下来我可以尝试什么？

我在 Geoserver 中显示图层时遇到了速度问题。该层是通过 postgres 存储检索的。我已经在表（1600 万行）上运行了 auto-vacuum，然后事情变得更快了。问题是我不知道为什么它们更快。根据真空查询的结果：

有 0 个死行。因此，如果没有应用任何更改，为什么在我执行查询后一切都开始快速运行？

我的表有 17500000 行，

我删除了 50 万行。删除后，我运行了 Vacuum 命令。

根据SVV_VACUUM_SUMMARY， row_delta 是真空前后表行总数的差异。

但是当我看到SVV_VACUUM_SUMMARY表时，row_delta是0，不应该是500K吗？

这里也是STL_VACUUM表的输出：

状态行 sortedrows

开始 17500000 813055

完成 17500000 17500000

这是否意味着真空不成功，因为完成的行与开始时相同？

SVV_VACUUM_PROGRESS的状态也为表的完成。所以想确认它是否成功。

并检查了我的表的SVV_TABLE_INFO和 tbl_rows 有 17500000。我不知道应该做什么，因为我认为 tbl_rows 应该是 17000000，因为真空操作成功。

任何帮助，将不胜感激。

我想利用 Postgres 中仅索引扫描的强大功能并尝试使用一个表：

该索引涵盖了我想在下一个查询中使用的所有列：

我在创建后立即检查计划：

这很奇怪，但好吧......

在几秒钟内它变成另一个（自动真空？）

我尝试强制它使用仅索引扫描：

但这并没有改变任何东西。然后我做

在这里，我终于得到了我想要的：

所以这里有问题：

1. 为什么不analyze教它使用大的“全覆盖”索引？
2. 为什么这样vacuum analyze做？
3. 我的桌子从头开始装满了一个大的插入物。为什么vacuum什么都做？在我看来，那里没有什么可以吸尘的。

具有 READ COMMITTED 隔离级别，已执行写操作的空闲事务将防止清理事务写入的表的死行。

对于由仍在进行中的事务写入的表来说，这一点很清楚。在这里你可以找到一个很好的解释。

但我不清楚为什么这个限制也会影响任何其他表。

例如：事务 T 启动并更新表 B，当 T 处于“事务中的空闲”状态时，对表 A 执行真空。在这种情况下，为什么无法删除 A 中的死行？

这是我所做的：

此时我进行更新以生成新的 1000 死行

吸尘将按预期删除它们：

我现在开始在表 b 中写入事务 T：

我在 T 之后开始的不同事务 T1 中再次生成更多死行：

在不同的交易中：

这是相关部分：细节：1000 个死行版本还不能被删除。

如果我提交事务 T 并再次执行真空，我会按预期删除死行：

当 Redshift 使用索引来运行查询（比如计数）时，它是否排除了对未排序区域中的行进行计数？

我使用 COPY 命令复制了很多数据，但没有VACUUM表后记。在运行我的查询（涉及与多个表的联接）时，查询的结果是错误的 - 未计算未排序区域中新复制的行。

然后，在清理表之后，查询开始返回正确的结果。这是预期的行为，还是亚马逊引入的错误？

每天我从一张大表中删除数十万条记录，然后我进行一些计算（使用新数据）并替换我之前删除的每条记录。我认为经常做vacuum tbl就可以了。我知道它不会将磁盘空间返回给服务器，但是（由于 pg 文档）我认为因为我插入的记录与删除的记录一样多，所以我不会丢失任何/太多的磁盘空间。但是，在将表移动到不同的命名空间后（出于不相关的原因），表从 117GB 变为 44GB！所以...

有没有比这更好的策略，所以我的桌子确实膨胀：

https://www.postgresql.org/docs/9.6/static/sql-vacuum.html

PostgreSQL 9.6

我实际上为减小表大小所做的事情在我的回答中： 整数超出范围和剩余磁盘空间太小，无法将 id 转换为 bigint 和其他解决方案

编辑1：缺点vacuum full对我来说太局限了。我正在 24/7 处理东西，所以我不能有这样的锁，而且我的可用磁盘空间在任何时候都非常有限。试图以更好的方式解决这个问题。