标签: disk-space

我有一个 PostgreSQL 表。select *很慢，但又select id好又快。我认为可能是行的大小非常大并且需要一段时间来运输，或者可能是其他一些因素。

我需要所有字段（或几乎所有字段），因此仅选择一个子集不是一个快速解决方案。选择我想要的字段仍然很慢。

这是我的表架构减去名称：

integer                  | not null default nextval('core_page_id_seq'::regclass)
character varying(255)   | not null
character varying(64)    | not null
text                     | default '{}'::text
character varying(255)   | 
integer                  | not null default 0
text                     | default '{}'::text
text                     | 
timestamp with time zone | 
integer                  | 
timestamp with time zone | 
integer                  | 

文本字段的大小可以是任意大小。但是，在最坏的情况下，不会超过几千字节。

问题

1. 有什么关于这叫“疯狂低效”的吗？
2. 有没有办法在 Postgres 命令行中测量页面大小来帮助我调试？

我知道收缩是魔鬼：它会颠倒页面顺序并导致皮肤癌、数据碎片化和全球变暖。名单还在继续……话虽如此，假设我有一个 100 GB 的数据库，我删除了 50 GB 的数据——不是在一个表上，而是在数据库范围内对旧数据进行一般修剪，覆盖 90% 的数据表——这是否构成缩小数据库的适当用例？

如果没有，从数据库中删除如此高比例的数据后，应采取哪些适当的步骤来清理房屋？我可以想到两个：重建索引和更新统计。还有什么？

我们为一个应用程序总共使用了 6 个数据库，并且我们只能在所有 6 个自动增长数据库之间共享 4TB 的空间（通过 SAN 存储）。

我想为单个数据库编写一个查询（报告），指示 SQL Server Management Studio 中的任务 > 收缩 > 数据库选项下的“当前分配的空间”和“可用的可用空间”属性。

然后我想将这些数字转换为 TB 并对每个数据库进行总计，以粗略估计我们还剩下多少空间。可以通过 T-SQL 查询访问这些字段吗？如果是这样，查询会是什么样子？

VACUUM通常不会将磁盘空间返回给操作系统，除非在某些特殊情况下。
从文档：

VACUUM删除表和索引中的死行版本并标记可用空间以供将来重用的标准形式。但是，它不会将空间返回给操作系统，除非在表末尾的一个或多个页面完全空闲并且可以轻松获得排他表锁的特殊情况下。相比之下，VACUUM FULL通过编写一个没有死空间的完整新版本的表文件来主动压缩表。这最大限度地减少了表的大小，但可能需要很长时间。它还需要额外的磁盘空间用于表的新副本，直到操作完成。

问题是：如何实现这个数据库状态one or more pages at the end of a table become entirely free？这可以通过 完成VACUUM FULL，但我没有足够的空间来实现它。那么还有没有其他可能呢？

我在本地安装了 9.1 数据库，其中有几个表有 cca​​。300 条 mio 记录，数据库增长到大约 20 GB。之后我发出delete from命令从中删除所有记录（我应该使用truncate，但我不知道）。所以我对我的数据库进行了完全真空以回收磁盘空间，但这无济于事。我的问题看起来与这个相同，但没有提供解决方案。我已经检查了这个线程和关于“恢复磁盘空间”的文档，但仍然找不到解决方案。我使用此代码获取所有表的大小

 SELECT nspname || '.' || relname AS "relation",
 pg_size_pretty(pg_total_relation_size(C.oid)) AS "total_size"
 FROM pg_class C
 LEFT JOIN pg_namespace N ON (N.oid = C.relnamespace)
 WHERE nspname NOT IN ('pg_catalog', 'information_schema')
 AND C.relkind <> 'i'
 AND nspname !~ '^pg_toast'
 ORDER BY pg_total_relation_size(C.oid) DESC
 LIMIT 15;

但是总共不到 1GB

SELECT pg_database.datname, pg_size_pretty(pg_database_size(pg_database.datname)) AS size FROM pg_database 

仍然显示大约 20 GB。任何建议非常感谢。

InnoDB 将所有表存储在一个大文件中ibdata1。

删除大表后，无论表有多大，文件都会保持其大小。如何缩小该文件而不必转储并重新导入整个数据库（总共有数百 GB）？

我认为原因是因为您仍然可以回滚下降。就我而言，我不需要。

我有一个包含 490 M 行和 55 GB 表空间的表，所以每行大约 167 个字节。该表包含三列： a VARCHAR(100)、 aDATETIME2(0)和 a SMALLINT。VARCHAR字段中文本的平均长度约为 21.5，因此原始数据每行应约为 32 个字节： 22+2 表示VARCHAR， 6 表示DATETIME2，2 表示 16 位整数。

请注意，上面的空间仅是数据，而不是索引。我正在使用属性下报告的值 | 存储 | 一般 | 数据空间。

当然肯定会有一些开销，但是每行 135 个字节似乎很多，尤其是对于大表。为什么会这样？有没有其他人见过类似的乘数？哪些因素会影响所需的额外空间量？

为了进行比较，我尝试创建一个包含两个INT字段和 1 M 行的表。所需的数据空间为 16.4 MB：每行 17 个字节，而原始数据为 8 个字节。另一个测试表中的 anINT和 aVARCHAR(100)填充了与真实表相同的文本，每行使用 39 个字节（44 K 行），我预计 28 加上一点。

所以生产表有更多的开销。这是因为它更大吗？我希望索引大小大约为 N * log(N)，但我不明白为什么实际数据所需的空间是非线性的。

在此先感谢您的指点！

编辑：

列出的所有字段都是NOT NULL. …

我们的空间快用完了。清除错误日志的安全方法是什么？

我知道如何检查 Postgres 中索引和表的大小（我使用的是 9.4 版）：

SELECT
   relname AS objectname,
   relkind AS objecttype,
   reltuples AS "#entries", pg_size_pretty(relpages::bigint*8*1024) AS size
   FROM pg_class
   WHERE relpages >= 8
   ORDER BY relpages DESC;

但这并没有显示物化视图。如何查看它们占用了多少磁盘空间？

这是针对系统操作员（或之前经历过这种经历的人）的一个问题。

我的公司希望在生产中的现有 SQL Server 机器上分配额外的磁盘空间。我们想知道扩展卷（磁盘管理中的“扩展卷...”）是否可以在线完成，或者是否需要关闭 SQL Server 服务。

有什么理由应该停止 SQL Server 服务来执行此操作，还是可以在白天执行此操作？

以防万一系统规格相关。这是一个运行 Windows 2012 R2 和 SQL Server 2008 R2 的真实机器（无虚拟化）。

谢谢！