主页 / dba / 问题 / 140790
Accepted
Phrancis
Asked: 2016-06-09 16:32:31 +0800 CST

使用 MAX 文本或更具体、更小的字体

  • 772

有人正在审查我用于创建表的 DDL 代码并建议，当他们看到我看到使用VARCHAR(256)文本字段时我希望它非常小，比如名字或其他任何东西，我应该始终只使用VARCHAR(MAX)和链接为什么不使用 varchar(max )。我读过它，但它似乎过时了，因为它专注于 2005 年，而且似乎没有提供任何真正的理由在所有文本字段上每行分配最多 2 GB 的空间。

从性能、存储等角度来看，应该如何决定是否VARCHAR(MAX)为现代版本的 SQL Server 使用或更小的更具体的类型？（例如，2008 年、2012 年、2014 年）

sql-server database-design

2 个回答

  1. Best Answer

    我应该始终使用(n)varchar(max)文本列吗？

    不。

    对于 SQL Server，max只有在别无选择时才应指定数据类型。相反，应该选择正确的基本类型（varchar或nvarchar）并指定适合要存储的数据的显式最大长度。

    无论列的类型是varchar(n)还是，物理存储都是相同的varchar(max)，所以这不是问题。

    不(n)varchar(max)随处选择的原因与功能、计划质量和性能有关。

    详尽的列表可能不切实际，但除其他外，max专栏：

    特征

    • 需要一个单独的约束来强制执行最大长度
    • 不能是索引中的键（因此也没有唯一约束）
    • 可能会阻止在线 DDL（包括索引重建和添加新的非空列）
    • 通常不支持“较新”的功能，例如列存储
    • 有关更具体的功能和限制，请参阅产品文档。max一般模式是围绕数据类型存在尴尬的限制和约束。并未记录所有限制和副作用。

    表现

    • 需要在执行引擎中进行特殊处理，以解决可能非常大的尺寸。通常，这涉及使用效率较低的代码路径和流接口
    • 可能会对外部代码（以及其他 SQL Server 组件，如 SSIS）产生类似的意外后果，这些代码也必须准备好处理最大 2GB 的数据
    • 在内存授予计算中假定为 4000 字节宽。这很可能会导致过多的内存预留，从而限制并发性，并将有价值的索引和数据页推出缓存内存
    • 禁用几个重要的性能优化
    • 可能会延长锁定时间
    • 可能会阻止优化器选择（非动态）搜索计划
    • 防止过滤器被推入扫描并作为残差寻找
    • 可能会增加 tempdb 压力和争用（取决于版本），因为变量和参数也可能被键入max以匹配列定义

    总而言之，不必要地使用说明符会产生许多微妙的（和不需要的）副作用max，因此这样做毫无意义。使用单一声明的次要“便利”并不是一种补偿。

    在上下文中评估每种类型，使用正确的基本类型（varchar或nvarchar）和合理的显式长度。

    延伸阅读：

    • 32

  2. 这读起来像是一个偏执狂的答案，但不仅要考虑存储和性能。

    数据库本身不控制其客户端，并且不能假定客户端始终安全地插入用户输入 - 即使数据库设计为仅与使用 Entity Framework 封装事务并确保参数化查询的 .net 应用程序一起使用被系统地使用，你无法知道情况总是如此。

    我不知道该怎么做，但是通过创建所有文本字段varchar(max)，如果客户端有Bobby 表问题和/或您的存储过程的参数也有问题varchar(max)，那么您就可以让攻击者更容易想出一个有效但巧妙邪恶的参数值，它可以做客户不应该做的事情——不管是什么。

    通过将长度限制为您实际需要的长度，您并没有保护自己免受这些巧妙的攻击（我什至不确定它实际上叫什么，我只记得前一段时间读过它），但你不是说“继续，尝试给我一个 2GB 的脚本来运行”。

    • 8

相关问题