如何确定 SQL Server Express 表的最大可用大小？
How can I determine the max usable size for my SQL Server Express tables?
我运行正在解决我以前从未遇到过的 SQL Server Express 问题。
我有一个包含 3200 万行的 table，此列设置为：
[Insp_ID] [nvarchar](8) NOT NULL,
[NodeID] [int] NULL,
[NodeVisible] [bit] NULL,
[Note] [nvarchar](max) NULL,
[Points] [int] NULL,
[QST_ID] [int] NULL,
[QST_Num] [int] NOT NULL,
[Response_Num] [int] NOT NULL,
[Value] [nvarchar](max) NULL,
[ValueID] [int] NULL,
[ValueVisible] [bit] NULL,
CONSTRAINT [QST2D_PK_i83] PRIMARY KEY CLUSTERED
([Insp_ID] ASC, [QST_Num] ASC, [Response_Num] ASC)
table 大约为 1900 MB，甚至可能更大一些。很难说，因为我几乎无法在 table 上执行任何维护操作而不会出现此错误：
Msg 802 There is insufficient memory available in the buffer pool.
据我了解，SQL Server Express 为此获得 1GB。当我尝试更改主键或执行 DBCC DBREINDEX 时会发生这种情况。我可以从数据库中获取信息并返回的唯一方法是使用 BCP，这非常不方便（但是，有趣的是它可以工作）。 BCP 允许我重组 table（即 PK），然后将数据带回。
无论如何，进一步的实验：我将行数减少到 8.2M，整体 table 大小减少到大约 633MB。仍然得到相同的错误，内存不足。这令人费解，因为对我来说这似乎不是很多数据。
那时，我删除了两个 nvarchar(max) 列，这进一步将 table 大小减少到大约 540MB。到那时，我不再运行内存不足了。
我无法判断缓冲区是否在抱怨行数或 table 大小，但根据这个轶事证据，感觉像是 table 大小。
有没有人对此有解决方案或见解？我觉得我们使用 SQL Server Express 找错了树——这太糟糕了，因为到目前为止它完全符合我们的需求。
根据过去的经验，SQLServer Express 的 RAM 上限为 1GB，并且还有数据库大小限制，具体取决于您使用的版本。
SO 上有一个关于 Limitations of SQL Server Express 的帖子，这可能有助于解决一般问题。
在 MSDN 上多管闲事时，我发现了一小段不错的文字，我相信它可能会对您有所帮助：
SQL Server needs enough memory to hold the data in memory-optimized tables and indexes. To account for row versions, you should provide an amount of memory that is two times the expected size of memory-optimized tables and indexes. But the actual amount of memory needed will depend on your workload. You should monitor your memory usage and make adjustments as needed. The size of data in memory-optimized tables must not exceed the allowed percentage of the pool.
要发现内存优化 table 的大小，请参阅 here 了解如何获取它（对于 SQL 2014）。
其他可能有用的文章是 Max rows in a SQL table? or Maximum Capacity Specifications for SQL Server。
我在 Microsoft 论坛上问了一个类似的问题，并被告知 DBCC DBREINDEX 在 2014 年不受支持。我觉得这很奇怪，因为它有效...有时。但是，我不能忽视语言障碍。而且，每次我都尝试过类似的陈述：
ALTER INDEX ALL ON QST2D REBUILD;
它起作用了。即使当我 运行 这个查询时：
SELECT
CASE
WHEN database_id = 32767 THEN 'mssqlsystemresource'
ELSE DB_NAME(database_id)
END AS [Database],
CONVERT(numeric(38,2),(8.0 / 1024) * COUNT(*)) AS [MB in buffer cache]
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY 2 DESC;
它在该数据库上使用了相当多的内存：
我在重建过程中不断刷新查询，我看到它从其他数据库中窃取内存，直到它们只剩下微薄的内存。我很惊讶该语句使用那么多内存而逃脱了，但是我对 SQL 的内存管理知之甚少，无法判断这只是缓冲池还是许多其他池（可能包括缓冲池）。我很高兴它有效，到目前为止似乎是可靠的。
重点是，这适用于 2+GB table 的 31M+ 行和 3 字段复合键。这更符合我的预期。我仍然不清楚为什么 DBCC DBREINDEX 会失败但 alter index 不会失败，而我相信它们会做类似的事情。它可能是如何完成的，即一个原子操作而不是单独的删除+创建。也许联合行动一次使用了更多的资源。我可能会尝试跟踪数据库，而这只是为了我自己的启发，但由于我似乎已经解决了眼前的问题，我想我应该将其标记为已回答。
我运行正在解决我以前从未遇到过的 SQL Server Express 问题。
我有一个包含 3200 万行的 table，此列设置为：
[Insp_ID] [nvarchar](8) NOT NULL,
[NodeID] [int] NULL,
[NodeVisible] [bit] NULL,
[Note] [nvarchar](max) NULL,
[Points] [int] NULL,
[QST_ID] [int] NULL,
[QST_Num] [int] NOT NULL,
[Response_Num] [int] NOT NULL,
[Value] [nvarchar](max) NULL,
[ValueID] [int] NULL,
[ValueVisible] [bit] NULL,
CONSTRAINT [QST2D_PK_i83] PRIMARY KEY CLUSTERED
([Insp_ID] ASC, [QST_Num] ASC, [Response_Num] ASC)
table 大约为 1900 MB，甚至可能更大一些。很难说，因为我几乎无法在 table 上执行任何维护操作而不会出现此错误：
Msg 802 There is insufficient memory available in the buffer pool.
据我了解，SQL Server Express 为此获得 1GB。当我尝试更改主键或执行 DBCC DBREINDEX 时会发生这种情况。我可以从数据库中获取信息并返回的唯一方法是使用 BCP，这非常不方便（但是，有趣的是它可以工作）。 BCP 允许我重组 table（即 PK），然后将数据带回。
无论如何，进一步的实验：我将行数减少到 8.2M，整体 table 大小减少到大约 633MB。仍然得到相同的错误，内存不足。这令人费解，因为对我来说这似乎不是很多数据。
那时，我删除了两个 nvarchar(max) 列，这进一步将 table 大小减少到大约 540MB。到那时，我不再运行内存不足了。
我无法判断缓冲区是否在抱怨行数或 table 大小，但根据这个轶事证据，感觉像是 table 大小。
有没有人对此有解决方案或见解？我觉得我们使用 SQL Server Express 找错了树——这太糟糕了，因为到目前为止它完全符合我们的需求。
根据过去的经验，SQLServer Express 的 RAM 上限为 1GB，并且还有数据库大小限制，具体取决于您使用的版本。
SO 上有一个关于 Limitations of SQL Server Express 的帖子，这可能有助于解决一般问题。
在 MSDN 上多管闲事时，我发现了一小段不错的文字，我相信它可能会对您有所帮助：
SQL Server needs enough memory to hold the data in memory-optimized tables and indexes. To account for row versions, you should provide an amount of memory that is two times the expected size of memory-optimized tables and indexes. But the actual amount of memory needed will depend on your workload. You should monitor your memory usage and make adjustments as needed. The size of data in memory-optimized tables must not exceed the allowed percentage of the pool.
要发现内存优化 table 的大小，请参阅 here 了解如何获取它（对于 SQL 2014）。
其他可能有用的文章是 Max rows in a SQL table? or Maximum Capacity Specifications for SQL Server。
我在 Microsoft 论坛上问了一个类似的问题，并被告知 DBCC DBREINDEX 在 2014 年不受支持。我觉得这很奇怪，因为它有效...有时。但是，我不能忽视语言障碍。而且，每次我都尝试过类似的陈述：
ALTER INDEX ALL ON QST2D REBUILD;
它起作用了。即使当我 运行 这个查询时：
SELECT
CASE
WHEN database_id = 32767 THEN 'mssqlsystemresource'
ELSE DB_NAME(database_id)
END AS [Database],
CONVERT(numeric(38,2),(8.0 / 1024) * COUNT(*)) AS [MB in buffer cache]
FROM sys.dm_os_buffer_descriptors
GROUP BY database_id
ORDER BY 2 DESC;
它在该数据库上使用了相当多的内存：
我在重建过程中不断刷新查询，我看到它从其他数据库中窃取内存，直到它们只剩下微薄的内存。我很惊讶该语句使用那么多内存而逃脱了，但是我对 SQL 的内存管理知之甚少，无法判断这只是缓冲池还是许多其他池（可能包括缓冲池）。我很高兴它有效，到目前为止似乎是可靠的。
重点是，这适用于 2+GB table 的 31M+ 行和 3 字段复合键。这更符合我的预期。我仍然不清楚为什么 DBCC DBREINDEX 会失败但 alter index 不会失败，而我相信它们会做类似的事情。它可能是如何完成的，即一个原子操作而不是单独的删除+创建。也许联合行动一次使用了更多的资源。我可能会尝试跟踪数据库，而这只是为了我自己的启发，但由于我似乎已经解决了眼前的问题，我想我应该将其标记为已回答。