估算mysql数据增长_估算数据库的初始大小以及增长幅度

http://jinnianshilongnian.iteye.com/blog/2031823

估计表的大小(一)

估计表的大小

下列步骤可用于估计存储表中的数据所需的空间量。

指定表中的行数：

表中的行数 = Num_Rows

如果在表的定义中有固定长度和可变长度列，请计算数据行中这两组列的每一组所占用的空间。列的大小取决于数据类型和长度说明。有关更多信息，请参见数据类型。

列数 = Num_Cols

所有固定长度列中的字节总和 = Fixed_Data_Size

可变长度列数 = Num_Variable_Cols

所有可变长度列的最大值 = Max_Var_Size

如果表中有固定长度列，行的一部分(称为空位图)将保留以管理列的可为空性。计算大小：

空位图 (Null_Bitmap) = 2 + (( Num_Cols + 7) / 8 )

仅使用上述表达式中的整数部分，而去掉其余部分。

如果表中有可变长度列，请确定在行中存储这些列需使用的空间：

可变长度列的总大小 (Variable_Data_Size) = 2 + (Num_Variable_Cols x 2) + Max_Var_Size

如果没有可变长度列，请将 Variable_Data_Size 设置为 0。

此公式假设所有可变长度列均百分之百充满。如果预计可变长度列占用的存储空间比例较低，则可以按照该比例调整结果以对整个表大小得出一个更准确的估计。

计算行大小：

行总大小 (Row_Size) = Fixed_Data_Size + Variable_Data_Size + Null_Bitmap +4

最后一个值 4 表示数据行首结构。

下一步，计算每页的行数(每页有 8096 可用字节)：

每页的行数 (Rows_Per_Page) = ( 8096 ) / (Row_Size + 2)

因为行不跨页，所以每页的行数应向下舌入到最接近的整数。

如果要在表上创建聚集索引，那么要根据指定的填充因子计算每页保留的可用行数。有关更多信息，请参见填充因子。如果不创建聚集索引，请将 Fill_Factor 指定为 100。

每页的可用行数 (Free_Rows_Per_Page) = 8096 x ((100 - Fill_Factor) / 100) / (Row_Size + 2)

计算中使用的填充因子为整数值，而不是百分数。

因为行不跨页，所以每页的行数应向下舍入到最接近的整数。填充因子增大时，每页将存储更多的数据，因此页数将减少。

计算存储所有行所需的页数：

页数 (Num_Pages) = Num_Rows / (Rows_Per_Page - Free_Rows_Per_Page)

估计的页数应向上舍入到最接近的整数。

最后，计算存储表中的数据所需的空间量(每页总字节为8192)：

表大小(字节)= 8192 x Num_Pages

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zjcxc/archive/2006/06/25/833776.aspx

估计表的大小(二)--估计带有聚集索引的表的大小

估计带有聚集索引的表的大小

下列步骤可用于估计存储带有聚集索引的表上的数据和任何附加的非聚集索引所需的空间。

计算存储数据所用的空间。

计算存储聚集索引所用的空间。

计算存储每个附加非聚集索引所用的空间。

汇总计算所得的值。

对于每个计算，都要指定将在表中出现的行数。表中的行数将对表的大小有直接影响：

表中的行数 = Num_Rows

计算存储数据所用的空间

有关如何计算存储数据所用空间的更多信息，请参见估计表的大小。

记下计算所得的值：

存储数据所用的空间 = Data_Space_Used

计算存储聚集索引所用的空间

下列步骤可用于估计存储聚集索引所需的空间。

聚集索引定义可以包括固定长度和可变长度列。为了估计聚集索引的大小，需要指定索引行中这两组列的每一组所占用的空间。

索引键中的列数 = Num_CKey_Cols

所有固定长度键列中的字节总和 = Fixed_CKey_Size

索引键中的可变长度列数 = Num_Variable_CKey_Cols

所有可变长度键列的最大值 = Max_Var_CKey_Size

如果聚集索引中有固定长度列，那么索引行的一部分将为空位图保留。计算大小：

索引空位图 (CIndex_Null_Bitmap) = 2 + (( Num_CKey_Cols + 7) / 8 )

仅使用上述表达式中的整数部分，而去掉其余部分。

如果索引中有可变长度列，请确定存储索引行中的这些列需使用的空间：

可变长度列的总大小 (Variable_CKey_Size) = 2 + (Num_Variable_CKey_Cols x 2) + Max_Var_CKey_Size

如果没有可变长度列，请将 Variable_CKey_Size 设置为 0。

此公式假设所有可变长度键列均百分之百充满。如果预计可变长度键列占用的存储空间比例较低，则可以按照该比例调整结果以对整个索引大小得出一个更准确的估计。

计算索引行大小：

索引行总大小 (CIndex_Row_Size) = Fixed_CKey_Size + Variable_CKey_Size + CIndex_Null_Bitmap + 1 + 8

下一步，计算每页的索引行数(每页有 8096 个可用字节)：

每页的索引行数 (CIndex_Rows_Per_Page) = ( 8096 ) / (CIndex_Row_Size + 2)

由于索引行不能跨页，所以每页的索引行数应向下舍入到最接近的整数。

下一步，计算存储索引的每一级别的所有索引行所需的页数。

页数(第 0 级)(Num_Pages_CLevel_0) = (Data_Space_Used / 8192) / CIndex_Rows_Per_Page

页数(第 1 级)(Num_Pages_CLevel_1) = Num_Pages_CLevel_0 / CIndex_Rows_Per_Page

重复第二个计算，将从前面的第 n 级中计算的页数除以 CIndex_Rows_Per_Page，直到指定的第 n (Num_Pages_CLevel_n) 级页数等于 1(索引根页)。例如，若要计算第二个索引级别所需的页数：

页数(第 2 级) (Num_Pages_CLevel_2) = Num_Pages_CLevel_1 / CIndex_Rows_Per_Page

对于每一级别，预计的页数应向上舍入到最接近的整数。

汇总存储各索引级别所需页数：

总页数 (Num_CIndex_Pages) = Num_Pages_CLevel_0 + Num_Pages_CLevel_1 +

Num_Pages_CLevel_2 + ...+ Num_Pages_CLevel_n

计算聚集索引的大小(每页总共有 8192 字节)：

聚集索引大小(字节) = 8192 x Num_CIndex_Pages

计算存储每个附加非聚集索引所用的空间

下列步骤可用于估计存储每个附加的非聚集索引所需空间量。

非聚集索引定义可以包括固定长度和可变长度列。为了估计非聚集索引的大小，需要计算索引行中这两组列的每一组所占用的空间。

索引键中的列数 = Num_Key_Cols

所有固定长度键列中的字节总和 = Fixed_Key_Size

索引键中的可变长度列数 = Num_Variable_Key_Cols

所有可变长度键列的最大值 = Max_Var_Key_Size

如果索引中有固定长度列，那么索引行的一部分将为空位图保留。计算大小：

索引空位图 (Index_Null_Bitmap) = 2 + (( Num_Key_Cols + 7) / 8 )

仅使用上述表达式中的整数部分，而去掉其余部分。

如果索引中有可变长度列，请确定存储索引行中的这些列需使用的空间：

可变长度列的总大小 (Variable_Key_Size) = 2 + (Num_Variable_Key_Cols x 2) + Max_Var_Key_Size

如果没有可变长度列，请将 Variable_Key_Size 设置为 0。

此公式假设所有可变长度键列均百分之百充满。如果预计可变长度键列占用的存储空间比例较低，则可以按照该比例调整结果以对整个索引大小得出一个更准确的估计。

计算非叶级索引行大小：

非叶级索引行总大小 (NL_Index_Row_Size) = Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1 + 8

计算每页的非叶级索引行数：

每页的非叶级索引行数 (NL_Index_Rows_Per_Page) =

( 8096 ) / (NL_Index_Row_Size + 2)

由于索引行不能跨页，所以每页的索引行数应向下舍入到最接近的整数。

计算叶级索引行大小：

叶级索引行总大小 (Index_Row_Size) = CIndex_Row_Size + Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1

最后一个值 1 表示索引行首结构。CIndex_Row_Size 是聚集索引键的索引行总大小。

计算每页的叶级索引行数：

每页的叶级索引行数 (Index_Rows_Per_Page) = ( 8096 ) / (Index_Row_Size + 2)

由于索引行不能跨页，所以每页的索引行数应向下舍入到最接近的整数。

根据为非聚集索引指定的填充因子，计算每页保留的可用索引行数。有关更多信息，请参见填充因子。

每页的可用索引行数 (Free_Index_Rows_Per_Page) = 8096 x ((100 - Fill_Factor) / 100) / Index_Row_Size

计算中使用的填充因子为整数值，而不是百分数。

由于索引行不能跨页，所以每页的索引行数应向下舍入到最接近的整数。

计算存储索引的每一级别的所有索引行所需的页数：

页数(第 0 级) (Num_Pages_Level_0) = Num_Rows / (Index_Rows_Per_Page - Free_Index_Rows_Per_Page)

页数(第 1 级) (Num_Pages_Level_1) = Num_Pages_Level_0 / NL_Index_Rows_Per_Page

重复第二个计算，将从前面的第 n 级中计算的页数除以 NL_Index_Rows_Per_Page，直到指定的第 n (Num_Pages_Level_n) 级页数等于 1(根页)。

例如，若要计算第二个和第三个索引级别所需页数：

数据页数(第 2 级) (Num_Pages_Level_2) = Num_Pages_Level_1 / NL_Index_Rows_Per_Page

数据页数(第 3 级) (Num_Pages_Level_3) = Num_Pages_Level_2 / NL_Index_Rows_Per_Page

对于每一级别，预计的页数应向上舍入到最接近的整数。

汇总存储各索引级别所需页数：

总页数 (Num_Index_Pages) = Num_Pages_Level_0 + Num_Pages_Level_1 +Num_Pages_Level_2 + ...+ Num_Pages_Level_n

计算非聚集索引的大小：

非聚集索引大小(字节) = 8192 x Num_Index_Pages

计算表的大小

计算表的大小：

表的总大小(字节) = Data_Space_Used + Clustered index size + Nonclustered index size + ...n

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zjcxc/archive/2006/06/25/833782.aspx

估计表大小(三)--估计无聚集索引的表的大小

估计无聚集索引的表的大小

下列步骤可用于估计存储没有聚集索引的表上的数据和任何附加的非聚集索引所需的空间。

计算存储数据所用的空间。

计算存储每个附加非聚集索引所用的空间。

汇总计算所得的值。

对于每个计算，都要指定将在表中出现的行数。表中的行数将对表的大小有直接影响：

表中的行数 = Num_Rows

计算存储数据所用的空间

若要计算存储数据所用的空间，请参见估计表的大小。

记下计算所得的值：

存储数据所用的空间 = Data_Space_Used

计算存储每个附加非聚集索引所用的空间

下列步骤可用于估计没有聚集索引的表上的单个非聚集索引的大小。

如果索引定义包含固定长度和可变长度列，请计算索引行中这两组列的每一组所占用的空间。列的大小取决于数据类型和长度说明。有关更多信息，请参见数据类型。

索引键中的列数 = Num_Key_Cols

所有固定长度键列中的字节总和 = Fixed_Key_Size

索引键中的可变长度列数 = Num_Variable_Key_Cols

所有可变长度键列的最大值 = Max_Var_Key_Size

如果索引中有固定长度列，那么索引行的一部分将为空位图保留。计算大小：

索引空位图 (Index_Null_Bitmap) = 2 + (( Num_Key_Cols + 7) / 8 )

仅使用上述表达式中的整数部分，而去掉其余部分。

如果索引中有可变长度列，请确定存储索引行中的这些列需使用的空间：

可变长度列的总大小 (Variable_Key_Size) = 2 + (Num_Variable_Key_Cols x 2) + Max_Var_Key_Size

如果没有可变长度列，请将 Variable_Key_Size 设置为 0。

此公式假设所有可变长度键列均百分之百充满。如果预计可变长度键列占用的存储空间比例较低，则可以按照该比例调整结果以对整个索引大小得出一个更准确的估计。

计算索引行大小：

索引行总大小 (Index_Row_Size) = Fixed_Key_Size + Variable_Key_Size + Index_Null_Bitmap + 1 + 8

下一步，计算每页的索引行数(每页有 8096 个可用字节)：

每页的索引行数 (Index_Rows_Per_Page) = ( 8096 ) / (Index_Row_Size + 2)

由于索引行不能跨页，所以每页的索引行数应向下舍入到最接近的整数。

根据为非聚集索引指定的填充因子，计算每叶级页保留的可用索引行数。有关更多信息，请参见填充因子。

每叶级页的可用索引行数 (Free_Index_Rows_Per_Page) = 8096 x ((100 - Fill_Factor) / 100) /

Index_Row_Size

计算中使用的填充因子为整数值，而不是百分数。

由于索引行不能跨页，所以每页的索引行数应向下舍入到最接近的整数。

下一步，计算存储索引的每一级别的所有索引行所需的页数：

页数(第 0 级) (Num_Pages_Level_0) = Num_Rows / (Index_Rows_Per_Page - Free_Index_Rows_Per_Page)

页数(第 1 级) (Num_Pages_Level_1) = Num_Pages_Level_0 / Index_Rows_Per_Page

重复第二个计算，将从前面的第 n 级中计算的页数除以 Index_Rows_Per_Page，直到指定的第 n (Num_Pages_Level_n) 级页数等于 1(根页)。例如，若要计算第二个索引级别所需的页数：

页数(第 2 级) (Num_Pages_Level_2) = Num_Pages_Level_1 / Index_Rows_Per_Page

对于每一级别，预计的页数应向上舍入到最接近的整数。

汇总存储各索引级别所需页数：

总页数 (Num_Index_Pages) = Num_Pages_Level_0 + Num_Pages_Level_1 +Num_Pages_Level_2 + ...+ Num_Pages_Level_n

计算聚集索引的大小(每页总共有 8192 个字节)：

非聚集索引大小(字节) = 8192 x Num_Index_Pages

计算表的大小

计算表的大小：

表的总大小(字节)= Data_Space_Used +  Nonclustered index size + ...n

本文来自CSDN博客，转载请标明出处：http://blog.csdn.net/zjcxc/archive/2006/06/25/833796.aspx

--------------------

--单表查询表的大小。

EXEC sp_spaceused 'authors'

/*

name       rows reserved data index_size unused

---------- ---- -------- ---- ---------- -------

authors    23   40 KB    8 KB 32 KB      0 KB

*/

--查询一个库所有表占空间的大小情况

use pubs --进入相应的数据库

go

--==========================================================

declare @dbname varchar(40)

declare @dbsize int

declare @sql nvarchar(1000)

declare @tablename varchar(40)

--==========================================================

--修改这里

set @dbname='pubs' --设置想要查询的数据库名字

--==========================================================

--创建存放各数据表所占用空间的中间表

if object_id('table_info') is not null drop table table_info

create table table_info(

Name nvarchar(40),

Rows char(21),

reserved varchar(28),

Data varchar(28),

index_size varchar(28),

Unused varchar(28))

--查看每一个用户表

DECLARE cur_table CURSOR

FOR SELECT name FROM sysobjects where xtype='U'

OPEN cur_table

FETCH NEXT FROM cur_table into @tablename

SET NOCOUNT ON

WHILE @@FETCH_STATUS = 0

BEGIN

insert table_info exec sp_spaceused @tablename

FETCH NEXT FROM cur_table into @tablename

END

SET NOCOUNT OFF

CLOSE cur_table

DEALLOCATE cur_table

--求出数据库的大小

SET @sql=N'select @size=size from  '+@dbname+'..sysfiles where groupid=1'

print @sql

EXEC sp_executesql @sql, N' @size int OUTPUT', @dbsize output

--@size的单位为8KB

set @dbsize=@dbsize*8

select 数据名=@dbname,

数据库大小=convert(varchar(40), @dbsize)+' KB',

用户表的数目=convert(varchar(10), count(1))+' 个',

所有表的数据所占的空间=convert(varchar(100), sum(convert(int, replace(data, 'KB', ''))))+' KB'

from table_info

--输出表的信息

select 表名=Name,表中记录数=Rows, 为该表分配的总量=reserved,

表中数据所占的空间=data, 表中索引所占的空间=index_size

from table_info order by data desc , rows desc

--清除

drop table table_info

http://www.simple-talk.com/sql/database-administration/managing-data-growth-in-sql-server/看这段 Beware of default autogrowth and recovery测试比较了默认增长条件下和修改后的io。然后建议修改model database具体建议：Correctly size the files –if you know that the database you are managing can expect a 2 Gig growth per month, size the data file(s) at 4G initially, not the 3 MB size that will be the default from the Model database.Set correct auto grow properties – while 10% growth for data and log files may be sufficient for low utilization databases, typically I set at least 500 MB for the auto growth settings for the data and log files. Unless I expect there to be unusually high data growth, 500 MB represents a good average growth rate, and keeps space utilization at a manageable level but allows for growth over time without heavy I/O impact.Make sure only those databases that need FULL recovery are using it – you will determine this from the business and will be part of the SLA for the application and database. If point-in-time recovery is required, make sure you have regular log backups taken of the databases in Full recovery mode.Switch to bulk-logged mode for bulk insert operations – bulk loading is a common practice and, if done correctly, will incur minimal log growth, while reaping the performance benefits bulk loading brings. However, make sure you understand the consequences of changing the recovery models while bulk loading data. For instance, you will be unable to perform a point-in-time recovery for the bulk transactions.