Lar*_*sen 28 sql-server-2008 database-design datatypes
在我们当前的项目中，它经常发生，我们需要将列扩展几个字符。从varchar(20)到varchar(30)等等。
在现实中，真正重要的有多少？这优化有多好？只允许 100 或 200 甚至 500 个字符用于正常的“输入”字段有什么影响？一封电子邮件只能有 320 个字符，所以可以 - 有一个很好的限制。但是如果我将它设置为 200，我会得到什么，因为我不希望电子邮件地址比这更长。
通常我们的表不会超过 100.000 行，最多 20 或 30 个这样的列。
我们现在使用 SQL Server 2008，但了解不同的数据库如何处理这个问题会很有趣。
如果影响非常低 - 正如我所期望的那样，这将有助于获得一些好的论据（有链接支持？）来说服我的 DBA，这种长期的偏执并不是真正必要的。
如果是的话，我是来学习的:-)
Lei*_*fel 12
您的问题的具体答案（至少对于 Oracle和可能的其他数据库）是字段的长度无关紧要，只有数据的长度。但是，这不应用作决定是否将字段设置为其最大允许长度的决定因素。在最大化字段大小之前，您应该考虑以下一些其他问题。
格式化 任何根据字段大小格式化数据的客户端工具都需要特殊的格式化注意事项。例如，即使数据只有一个字符长，Oracle 的 SQL*Plus 也会默认显示 Varchar2 列的最大大小。相比…
create table f1 (a varchar2(4000), b varchar2(4000));
create table f2 (a varchar2(5), b varchar2(5));
insert into f1 values ('a','b');
insert into f2 values ('a','b');
select * from f1;
select * from f2;
坏数据 字段长度提供了一种额外的机制来捕获/防止坏数据。接口不应尝试在 100 个字符的字段中插入 3000 个字符，但如果该字段定义为 4000 个字符，则可能会这样做。该错误不会在数据输入阶段被捕获，但是当另一个应用程序尝试处理数据并阻塞时，系统可能会进一步出现问题。例如，如果您稍后决定在 Oracle 中索引该字段，您将超过最大键长度（取决于块大小和串联）。看…
create index i1 on f1(a);
内存 如果客户端应用程序使用最大大小分配内存，则该应用程序将分配比所需内存多得多的内存。为了避免这种情况，必须进行特殊考虑。
文档 字段的大小提供了关于数据的另一个文档数据点。我们可以调用所有表 t1、t2、t3 等以及所有字段 f1、f2、f3 等，但是通过指定有意义的名称我们可以更好地理解数据。例如，如果一家在美国有客户的公司的地址表有一个名为 State 的字段，它是两个字符，我们希望其中包含两个字符的州缩写。另一方面，如果该字段是一百个字符，我们可能希望在该字段中包含完整的州名。
综上所述，为变革做好准备似乎是明智之举。仅仅因为您今天的所有产品名称都适合 20 个字符，并不意味着它们总是可以。不要过分地将其设置为 1000，但要为合理的扩展留出空间。
这是一个很好的起点。
http://www.sqlskills.com/BLOGS/KIMBERLY/post/Disk-space-is-cheap.aspx
我可能误解了你原来的问题。让我看看我是否可以为您找到一些其他链接以供参考。
这里是关于数据类型选择的很好的参考：http : //sqlfool.com/2009/05/performance-thinkations-of-data-types/
从 varchar(20) 更改为 varchar(30) 似乎很小，但您需要更多地了解数据库结构的工作方式，以便了解潜在问题。例如，转到 varchar(30) 可能会使您超过列的临界点（如果所有 30 个字节都被使用）能够存储在一页上（少于 8060 个字节）。这将导致使用的磁盘空间增加，性能下降，甚至事务日志的一些额外开销。
这是数据库结构的链接：http : //technet.microsoft.com/en-us/sqlserver/gg313756.aspx
这是页面拆分和 trx 日志记录之一：http : //sqlskills.com/BLOGS/PAUL/post/How-expensive-are-page-splits-in-terms-of-transaction-log.aspx
HTH
我想我会分享另一个有趣的观点，这是我在Stack Overflow 问题中发现的。
原始答案：尼克卡瓦迪亚斯
不使用 max 或 text 字段的一个原因是您无法执行联机索引重建，即 REBUILD WITH ONLINE= ON 即使使用 SQL Server Enterprise Edition。
在任意添加 n/varchar(max) 列时，我认为这是一个很大的缺点，并且根据 MS 站点，这种对进行在线索引重建的限制仍然存在于 SQL Server 2008、2008 R2 和 Denali 中；所以它不是特定于 SQL Server 2005。
在某些情况下，为 varchar 字段分配的空间量会影响为内存中排序分配的内存量。
我发现 SQLWorkshops.com 上的演示很发人深省，这个演示讨论了一种情况，即 order by 的排序溢出到 tempdb 中，因为没有为 char/varchar 字段分配足够的内存。
http://webcasts2.sqlworkshops.com/webcasts.asp
此网络广播还作为文章在以下网站上提供：
http://www.mssqltips.com/tip.asp?tip=1955
请注意，在本演示文稿中，被排序的列不是 char/varchar 列，但内存中为 varchar 列分配的空间量在某些情况下会影响查询性能。