相关疑难解决方法(0)

在网上搜索，我发现在指定过宽的 VARCHAR 列时是否会影响性能的建议相互矛盾，例如 VARCHAR(255) 时 VARCHAR(30) 可能会这样做。

我一致认为，如果整行超过 8060 字节，性能会受到影响。除此之外，我看到了分歧。

索赔是真的The default is SET ANSI PADDING ON = potential for lots of trailing spaces吗？只要总行宽小于 8060，过大的 VARCHAR 列是否有任何真正的性能问题？

列宽很重要的证据

The same goes for CHAR and VARCHAR data types. Don’t specify more characters in character columns that you need.

http://www.sql-server-performance.com/2007/datatypes/

• Length is a constraint on the data (like CHECK, FK, NULL etc)
• Performance when the row exceeds 8060 bytes
• Can not have unique constraint or index (key column width must …

我们的数据库中有一些表的数据类型为 varchar(8000)，其中该列中最长的实际值为 75。当我们在该列上放置索引时，我们会收到预期的警告，即最大允许的索引长度为 900 字节.

实际数据类型是否会影响该索引的有效性？也就是说，既然实际数据远低于900字节，那么索引还能用吗？

就其价值而言，我正在尝试修改数据类型，因为这对于列的目的来说是一个荒谬的限制，但我不确定争论的激烈程度。

看这个问题，似乎其他网站也有随着时间的推移增加列大小的问题。

仅增加表中列的大小是一项相当简单的任务。

但是，当您的商店遵守存储过程参数的长度必须与相应表列的长度相匹配的规则时，通过您的存储过程进行的大量更改就会下降。

锁定在 Oracle 显示，该过程不需要知道 varchar2 参数的长度。

当您将每个 varchar 参数声明为 varchar(max) 或 nvarchar(max) 时，其优缺点是什么？

显然，您可以忘记每次增加色谱柱尺寸时都必须调整程序的维护噩梦。

对 SQLRockStar 的回答： 我想保留一个相当保守的表设计，其中已知长度有限的字段根据当前限制建模，而不为将来可能的扩展保留。

我的许多表都包含一个 id int、一个代码 varchar(30) 和一个描述列 varchar(255)。

代码字段必须反映不同客户的本地命名约定。

一些客户需要将此字段增加到 50。

当我不将长度编码到程序参数中时，我只需要调整这个单一客户的表列。

当我坚持将长度编码到参数中时，那么我要么支持不同客户的不同版本的程序，要么我不得不更改并将更改推出给所有客户。

例子

-- SQL Server
Create Table dbo.SQLServerTable (
    id int identity(1,1) primary key not null,
    code varchar(30) not null,
    description varchar(255) not null
);
go
Create Procedure WrapInsertSQLServer1 (
    @code varchar(30),
    @description varchar(255)
) as
INSERT INTO SQLServerTable values (@code, @description);
go      

Create Procedure WrapInsertSQLServer2 (
    @code …