SQL Server 每行最大 8KB？
我刚刚读了 SQL Server 2008 的最大容量规范并看到每行最多 8060 字节？什么...每行只允许 8KB？ （是的，我看到“行溢出存储”特殊处理，我说的是标准行为）
我在这里误解了什么吗？我确信我已经看到了，因为我确信我看到了存储在 SQL Server 数据库中的具有几个 MB 大小的二进制对象。这个不祥的每行真的意味着表格行是一行多列吗？
因此，当我有三个 nvarchar 列，每列 4000 个字符时（假设在文本框中写入三个法律文档...） - 服务器会发出警告？
I just happened to read the Maximum Capacity Specification for SQL Server 2008 and saw a maximum of 8060bytes per row? What the... Only 8KB per row allowed? (Yes, I saw "row-overflow storage" special handling, I'm talking about standard behavior)
Did I misunderstand something here? I'm sure I have, because I'm sure I saw binary objects with several MB sizes stored inside SQL Server databases. Does this ominous per row really mean a table row as in one row, multiple columns?
So when I have three nvarchar columns with each 4000 characters in there (suppose three legal documents written in textboxes...) - the server spits out a warning?
如果你对这篇内容有疑问，欢迎到本站社区发帖提问 参与讨论，获取更多帮助，或者扫码二维码加入 Web 技术交流群。
绑定邮箱获取回复消息
由于您还没有绑定你的真实邮箱，如果其他用户或者作者回复了您的评论，将不能在第一时间通知您！
发布评论
评论（2）
是的，您会在 CREATE TABLE 上收到警告，在 INSERT 或 UPDATE LOB 类型上收到错误
（nvarchar(max)、varchar(max) 和 varbinary(max) 允许 2Gb-1 字节，这就是您存储大块数据的方式） 会使用 nvarchar(max) 。
对于单个字段 > 4000 个字符/8000 字节，我会使用 nvarchar(max)
对于一行中的 3 x nvarchar(4000)，我会考虑以下之一：
Yes, you'll get a warning on CREATE TABLE, an error on INSERT or UPDATE
LOB types (nvarchar(max), varchar(max) and varbinary(max) allow 2Gb-1 bytes which is how you'd store large chunks of data and is what you'd have seen before.
For a single field > 4000 characters/8000 bytes I'd use nvarchar(max)
For 3 x nvarchar(4000) in one row I'd consider one of:
2008 年将处理溢出，而在 2000 年，它只会拒绝插入溢出的记录。但是，最好在设计时考虑到这一点，因为大量记录溢出可能会导致查询中出现一些性能问题。在您描述的情况下，我可能会考虑一个相关表，其中包含文档类型列、文档的大字段以及初始表的外键。然而，如果所有三列不太可能填充在同一记录中或填充最大值，那么设计可能没问题。您必须了解您的数据才能确定哪个是最好的。另一个考虑因素是继续像现在一样，直到出现问题，然后用单独的文档表替换。您甚至可以通过重命名现有表并创建一个新表来进行重构，然后使用现有表名创建一个视图，从新结构中提取数据。尽管您仍然需要调整任何插入或更新语句，但这可以防止您的许多代码被破坏。
2008 will handle the overflow while in 2000, it would simply refuse to insert a record that overflowed. However, it is still best to design with this in mind because a significant number of records overflowed might cause some performance issues in querying. In the case you described, I might consider a related table with a column for document type, a large field for document and and a foreign key to the intial table. If however it is unlikey that all three columns would be filled in the same record or at the max values, then the design might be fine. You have to know your data to determine which is best. Another consideration is to continue as you have now until you have problems and then replace with a separate document table. You could even refactor by renaming the existing table and creating a new one and then creating a view with the existing tablename that pulls the data from the new structure. This could keep alot of your code from breaking although you would still have to adjust any insert or update statements.