我正在研究一个表设计，它可能涉及大约10个字段中的许多NULL值，可能有75％的时间不使用字段。
我刚刚生成了一些假数据（一百万条记录），并且无法感知到对SQL Server 2005的任何影响。大小差异在KB中。性能 - 在向3个不可为空的列添加索引后没有可测量的差异。
我知道SQL Server 2008具有稀疏列功能（我假设它将用于下一个SharePoint的UserData表）。我希望我的代码可以在2005上运行。 但是当前SharePoint UserData表的设计中存在大量NULL值。 所以，如果它对微软来说足够好......
关于SQL Server表中许多NULL值的缺点或难点的任何好文章，链接，白皮书？当你扩展到10 mil或100 mil记录时，任何人都有经验吗？
答案 0 :(得分：8)
我从来没有遇到多个空列上的性能问题，即使是在演出规模为100的数据库中也是如此。我想如果你在这些字段上运行索引然后在查询中使用null，你最终会遇到问题，但我个人并没有将此视为问题。然后，我还没有创建数据库表，除了3之外的每个字段都可以为空。
另一方面，当大多数数据为空时，我看到了一个架构问题。一般原因是：a）数据库规范化程度不正确或b）尝试允许用户在结束表中分段数据，而不是在提交数据库之前创建单独的表来“构建”数据。
由您决定数据库的最佳架构。
答案 1 :(得分：7)
在这种情况下我做的很常见，就是将数据分成两个表：
例如，我目前正在编写一个社区网站，其中一个表显然是一个用户表。我正在记录大量有关用户的信息，因此我将收集的数据拆分为两个表：
Users 表包含我将一直需要的基本信息，例如用户名，姓名和会话信息。
UserDetails 表包含我不需要的额外信息，例如个人资料页面，电子邮件地址，密码，网站地址，出生日期等。
答案 2 :(得分：2)
我过去遇到的问题涉及具有NULL值的编程含义。例如客户端的问题，或者在不期望的情况下返回数据的查询中没有问题，因为存在空值。
答案 3 :(得分：2)
嗯，NULL在数据库中总是有点奇怪。我不认为它对您的情况有太大的性能影响 - 当然，您必须分别处理所有NULL值。
只要有可能，我会努力使用默认值，所以如果你有某些类型为INT的ID值，您可以使用0或-1作为“无值存在”指示符。这样，您可以避免必须检查值（字段＆lt; 0）并单独检查NULL（字段IS NULL或IS NOT NULL）。
马克
答案 4 :(得分：1)
列中NULL的概率越高，列应该在表中的记录结尾越近（到表中的lat列）。
行末尾的NULLS没有分配任何空间，它们由链接到每个记录的NULL BITMAP确定（它是2个字节，每个位告诉记录中一个列值的（非）NULL-ness） ）。
现在，不从列读取NULL值，从NULL位图读取它们。当检测到NULL时，跳过实际值读数
稀疏功能应谨慎使用，因为它会调用非空值的时间和空间开销 为了提高效果，您可以参与filtered indexing on non-null part of a column
答案 5 :(得分：0)
只有一种方法可以肯定。继续插入1亿条记录，然后测量端到端的性能。
答案 6 :(得分：-1)
不要使用75％未使用的列创建表。使用您将要使用的列进行使用，并考虑使用EAV之类的其他列，或将它们放在不同的表中。