标签: size

希望这有一个简单的答案，我错过了一些明显的东西。我有一个表，其中行数 * 行大小比表使用的实际数据空间小得多。

如果我运行标准报告“Top Tables 的磁盘使用情况”，我得到的数字是：

# Records   Reserved (KB)      Data (KB)      Indexes (KB)      Unused (KB) 
33,245        32,962,192       31,070,264       144               1,891,784

这（除非我遗漏了一些东西）意味着每一行占用的空间不到 1MB！

表模式（我没有设计）是：

CREATE TABLE [MySchema].[MyTable]
(
    [Code]     [varchar](4) NOT NULL,
    [SomeID]   [smallint] NOT NULL,
    [SomeID1]  [smallint] NOT NULL,
    [Updated]  [datetime] NOT NULL,
    [SomeId2]  [int] NULL,
    [SomeId3]  [int] NULL,
    [Somekey]  [real] NULL,
    [desc1]    [char](12) NULL,
    [colA]     [real] NULL,
    [someid4]  [char](20) NULL,
    [starttime] [real] NULL,
    [endtime]  [real] NULL,
    [duration] [real] NULL,
    [reason]   [real] NULL,
    [status]   [real] NULL,
    [category] [real] NULL, …

有很多关于 sql server 应该使用多大的存储块大小的文章，例如SQL Server 的磁盘分区对齐最佳实践。正确的块大小应该可以提高 sql server 数据库的性能。我正在寻找建议和方法来确定适合数据库的存储块大小。是否有关于如何确定合适的块大小的指南？

我有一个非常大的表，带有 blob 字段，称为data. 我试图弄清楚为什么它没有被很好地缓存并且重复的SELECTs 很慢：

=> SELECT pg_size_pretty(pg_total_relation_size('data'));
157 GB

这看起来有点大，所以我试着总结一下数据：

=> SELECT pg_size_pretty(pg_relation_size('data'));
19 GB

随着指数：

SELECT pg_size_pretty(pg_relation_size('data_pkey'));
757 MB   
SELECT pg_size_pretty(pg_relation_size('data_file_end_date_idx'));
766 MB   
SELECT pg_size_pretty(pg_relation_size('data_file_end_date_idx'));
766 MB
SELECT pg_size_pretty(pg_relation_size('data_merged_idx'));
854 MB
SELECT pg_size_pretty(pg_relation_size('data_owner_idx'));
794 MB
SELECT pg_size_pretty(pg_relation_size('data_session_format_idx'));
779 MB

数据和索引大小的总和约为 26 GB，但总关系大小接近 160 GB。该表刚刚从转储中恢复，此后没有进行任何写入。

• 这种差异的解释是什么？
• 有什么办法可以减少浪费的磁盘空间？聚类会有帮助吗？

我在数据库管理方面很新。我现在公司的数据库架构是主从复制。我们使用的是 MySQL 5.0.86 版。

几周前，我们升级了公司的主应用程序。此升级为其数据库的所有表添加了一列。升级前，我们的 ibdata 大小约为 3.1GiB。升级后是~5.2GiB。

今天，我已经用 mysqldump 完成了一个完整的备份恢复测试。恢复后，ibdata 大小约为 3.6 GiB。标准选择在恢复中显示与原始数据库中相同的数据。

我已经通过 select to information_schema 检查了数据大小（CUSTODIA 是我们主应用程序的名称）：

select SUM(DATA_LENGTH+INDEX_LENGTH) from TABLES where TABLE_SCHEMA='CUSTODIA';

这是主数据库中的结果：

+-------------------------------+
| SUM(DATA_LENGTH+INDEX_LENGTH) |
+-------------------------------+
|                    5683345068 |
+-------------------------------+

这是恢复数据库的结果：

+-------------------------------+
| SUM(DATA_LENGTH+INDEX_LENGTH) |
+-------------------------------+
|                    3735748608 |
+-------------------------------+

我的问题：

1. 为什么原始和恢复的数据库大小之间存在这种差异？
2. 尽管大小不同，但假设恢复的数据库没问题是否安全？
3. MySQL如何计算data_length？是估价吗？
4. 我可以在不停机的情况下安全地将生产的 ibdata 文件大小减少到 3.6GiB 吗？

对此的任何想法将不胜感激。谢谢你。

可以在 SQL Server 2008 中重新计算行大小吗？拿这个例子：

declare @counter int
declare @statement nvarchar(max)
set @counter=0
drop table kua2
create table kua2(id int)
while @counter<307
begin
    set @statement = N'alter table kua2 add id'+CAST(@counter as nvarchar(max))+N' nvarchar(max)'
    exec (@statement)
    set @statement = N'alter table kua2 drop column id'+CAST(@counter as nvarchar(max))
    exec (@statement)
    set @counter=@counter+1
end

alter index all on kua2 rebuild

dbcc cleantable (0,'kua2',0)

alter table kua2 add id0 int
alter table kua2 add id1 int
alter table kua2 add id2 int
alter …

我创建一个表并用数据填充它：

create table tab
as
select 'value' || level val
from dual
connect by level <= 10000;

如果我然后删除所有行并插入相同的数据：

delete from tab;

insert into tab
select 'value' || level val
from dual
connect by level <= 10000;

commit;

每次执行删除然后插入时表大小都会增加。多次执行这些操作会导致表增长到原始大小的许多倍。

我希望大小保持（大约）相同。为什么会这样？

删除将空间标记为空闲，它实际上并没有缩小段。后续插入应首先使用 HWM 以下的可用空块。

我可以使用alter table tab shrink space.

我在 Oracle 12 和 Oracle 18c 中进行了测试。

我尝试使用查询重建数据库的所有索引，

USE [DB_Name];
GO
DECLARE @TableName VARCHAR(255)
DECLARE @sql NVARCHAR(500)
DECLARE TableCursor CURSOR FOR
SELECT '['+OBJECT_SCHEMA_NAME([object_id])+']'+'.'+name AS TableName
FROM sys.tables
OPEN TableCursor
FETCH NEXT FROM TableCursor INTO @TableName
WHILE @@FETCH_STATUS = 0
BEGIN
SET @sql = 'ALTER INDEX ALL ON ' + @TableName + ' REBUILD'
PRINT @sql
EXEC (@sql)
FETCH NEXT FROM TableCursor INTO @TableName
END
CLOSE TableCursor
DEALLOCATE TableCursor
GO

该查询执行了大约 3.5 小时，然后抛出错误消息，指出磁盘空间不足，这不是真的，但可能是数据库达到了其大小限制。

但唯一的问题是数据库的大小实际上增长了几乎 100%，而没有重建任何索引。我选择重建的主要原因是大多数索引碎片超过75%。

现在，不幸的是，从备份恢复不是一个选择，因为我们已经写入了新数据，而且已经过去了几个小时。

再次使用足够的磁盘空间进行重建可以解决问题吗？如果是这样，我是否仍然遵循当前数据库空间 1.5 倍的经验法则？

是否可以找到特定查询将返回的数据大小？

例如，我可以使用以下内容来查找每个日期的行数：

select mydatecolumn, count(*) 
from MyTable
where mydatecolumn < '01-JAN-2014'
group by mydatecolumn

但是有没有办法找出这些行中包含的数据的大小？

例如

select mydatecolumn, "sizeofactualdata",
from mytable
where mydatecolumn < '01-JAN-2014'
group by mydatecolumn

即使每个日期只有一个查询，这也不是问题。

我在 Ubuntu 14.04 上使用 Postgres 9.5。我想在日志达到特定大小时旋转它们。所以我编辑了 /etc/postgresql/9.5/main/postgresql.conf 并设置了这个

log_rotation_size = 50MB                # Automatic rotation of logfiles will
                                        # happen after that much log output.
                                        # 0 disables.

然后我重新启动了我的服务器

sudo /etc/init.d/postgresql restart

但是在运行了一些操作之后，我的磁盘空间用完了，并且发现我的日志根本没有轮换……

myuser@mymachine:~$ ls -al /var/log/postgresql/postgresql-9.5-main.log
-rw-r----- 1 postgres postgres 3165773943 Dec 29 18:34 /var/log/postgresql/postgresql-9.5-main.log

我还需要做什么才能开始日志轮换？

使用以下查询我可以获得表索引的大小：

SELECT
    i.name              AS IndexName,
    SUM(page_count * 8) AS IndexSizeKB
FROM sys.dm_db_index_physical_stats(db_id(), object_id('schema.table'), NULL, NULL, 'DETAILED') AS s
JOIN sys.indexes AS i
ON s.[object_id] = i.[object_id] AND s.index_id = i.index_id
GROUP BY i.name
ORDER BY i.name

如果我执行sp_spaceused 'schema.table'没有索引的大小是否对应于data列？

有什么方法可以获取sql server中没有索引的表的大小吗？（SELECT声明会很好，因为我想将此查询插入到更大的查询中）。

如果我执行获取数据库中所有表的大小，表的大小几乎与索引的大小相同（表明有问题）。