小编Eri*_* J.的帖子

在网上搜索，我发现在指定过宽的 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 …

我们有一个应用程序，它全天定期查询 SQL 数据库。有零活动或仅有轻微活动的时期，散布着对相对大量数据的个人请求。当这些请求出现时，主要目标是快速交付数据，次要目标是经济高效地完成这项工作。由于应用程序的性质，数据/索引不太可能从先前的查询（不同的用户，处理数据的不同部分）缓存在 RAM 中。

对于使用相对稳定的系统，我听说过观察磁盘队列长度并将该数字保持相对较小的经验法则。这将专门在 AWS 中运行，在那里我看到了一个经验法则，即每 100 IOPS 1 的磁盘队列长度是合理的。

如何估计此类系统的 IO 要求？在处理单个突发查询时，磁盘队列长度是否是一个可靠的指标？我还应该考虑其他指标吗？