是否有理由在SQL Server中使用Base2长度的列?

时间:2010-10-19 16:21:45

标签: sql-server database database-design

  

可能重复:
  varchar Fields - Is a Power of Two More Efficient?
  Nvarchar or varchar what is better use multiply of 2 or rounded full numbers??

出于纯粹的习惯,我将在SQL Server中使用的列的大小定义为Base2大小。例如,这是我正在处理的表格:

  1. ID int
  2. FirstName nvarchar(64)
  3. LastName nvarchar(64)
  4. Col4 varchar(16)
  5. Col5 nvarchar(32)
  6. Col6 nvarchar(128)
  7. 等...
  8. 我不知道这个习惯来自哪里,我不确定它是否有意义。以下表格定义是否会在某种程度上低于上述定义?

    1. ID int
    2. FirstName nvarchar(50)
    3. LastName nvarchar(50)
    4. Col4 varchar(10)
    5. Col5 nvarchar(30)
    6. Col6 nvarchar(100)
    7. 等...
    8. 我想我的主要问题是:使用Base2列长度有合理的原因吗?

5 个答案:

答案 0 :(得分:4)

没有理由这样做,特别是对于(n)varchar数据,其中存储大小是数据的实际长度+ 2个字节。

答案 1 :(得分:4)

使列大于它们所需的列可能会对数据库设计产生积极的影响。来自BOL:

  

每行最多可包含8,060个字节。在SQL Server 2008中,对包含varchar,nvarchar,varbinary,sql_variant或CLR用户定义类型列的表放宽了此限制....超过8,060字节行大小限制可能会影响性能,因为SQL Server仍然维护每页限制为8 KB。当varchar,nvarchar,varbinary,sql_variant或CLR用户定义类型列的组合超出此限制时,SQL Server数据库引擎将具有最大宽度的记录列移动到ROW_OVERFLOW_DATA分配单元中的另一个页面,同时保持24-原始页面上的字节指针。将大型记录移动到另一个页面会动态发生,因为记录会根据更新操作延长。缩短记录的更新操作可能会导致记录移回IN_ROW_DATA分配单元中的原始页面。此外,查询和执行其他选择操作(例如对包含行溢出数据的大型记录进行排序或连接)会减慢处理时间,因为这些记录是同步处理而不是异步处理。

我发现如果你迟早会给他们额外的尺寸,他们会使用它。此外,如果您将某些内容设置为varchar(64)并且您最多只需要10个字符,那么您更有可能将某个字段用于除了预期目的以外的其他字段,并且您会发现在这些字段中会收到错误的数据(就像一个电话号码字段,其中包含关于办公室秘书联系的备注以选择一个不那么随机的例子。)

然而,至少这个设计比制作nvarchar(max)。

更好

答案 2 :(得分:1)

不,这只是程序员习惯于以2的权力思考和行动 - 从SQL Server来看,绝对没有技术上的理由 - 没有提高速度或性能或类似的东西。

答案 3 :(得分:0)

疑。首先,列的确切长度主要取决于您自己的数据模式原因。其次,如果长度确实进入效率,那么所有列的总长度可能是最重要的标准,即使这样,也会有簿记开销,这意味着一个好的整数不可能是最佳答案。

因此,您可能会找到有关将行大小限制为特定数量的建议,以便整行适合页面或沿着这些行的某些内容。这是为了减少每条记录的磁盘I / O数量。但是单个列的大小并不重要,它将是总数。

答案 4 :(得分:0)

这不是一个特定的SQL SErver问题......我在Oracle和MySQL中做同样的事情。除了使用base2尺寸感觉更舒服之外,没有特别的原因。