假设一个表只包含整数并且具有聚集列存储索引。
CREATE TABLE cci_account
(
AccountKey int NOT NULL,
UnitSold int,
INDEX ColStore CLUSTERED COLUMNSTORE
);
那么看起来，在这样的表中，对一个列按另一个列分组求和总是很快，例如
SELECT
AccountKey,
SUM(UnitSold)
FROM
cci_account
GROUP BY
AccountKey;
为什么这么快？我对列存储架构的理解是，包含的段AccountKey不知道UnitSold其行上的值是什么。那么，SQL Server 如何能够如此快速地分组AccountKey？我无法想象任何算法可以实现这一点。
我一直在尝试表分区，发现了很多惊喜。我目前正在尽可能多地阅读文档，但文档数量多得令人震惊。我想我已经读完了六份白皮书中的第二份。我还没有在任何文档中看到过这个问题。
使用DROP_EXISTING = ON，似乎某些表可以就地分区。例如，我可以让它与唯一聚集索引一起工作。但是，我无法对主键执行相同的操作。本指南同意我的结论，并表示对具有主键的表进行分区需要先删除主键。这就像存在语法限制而不是功能限制。
我的问题是：什么时候可以对表进行分区而不在分区之前删除任何内容？换句话说，什么时候可以就地进行分区？
我并不是特意询问具体可以用什么方法做DROP_EXISTING。那只是我偶然发现的一种方法。
假设 SQL Server 2022。我不在乎操作是否在线。对于类似的事情，我有一个不同的问题。
CREATE PARTITION FUNCTION PF (integer)
AS RANGE RIGHT
FOR VALUES
(
10000, 20000, 30000, 40000, 50000
);
GO
CREATE PARTITION SCHEME PS
AS PARTITION PF
ALL TO ([PRIMARY]);
GO
CREATE TABLE dbo.T1
(
c1 integer NOT NULL,
c2 integer NOT NULL,
c3 integer NOT NULL,
CONSTRAINT PK_T1
PRIMARY KEY CLUSTERED (c1, c2, c3)
);
CREATE TABLE dbo.T2
(
c1 integer NOT NULL,
c2 integer NOT NULL,
c3 integer NOT NULL,
INDEX UIX_T2 UNIQUE CLUSTERED (c1, c2, c3)
);
GO
CREATE TABLE dbo.T3
(
c1 integer NOT NULL,
c2 integer NOT NULL,
c3 integer NOT NULL,
INDEX UIX_T3 UNIQUE NONCLUSTERED (c1, c2, c3)
);
GO
/* These work */
CREATE CLUSTERED INDEX UIX_T2 ON dbo.T2 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1)
GO
CREATE NONCLUSTERED INDEX UIX_T3 ON dbo.T3 (c1, c2, c3)
WITH (DROP_EXISTING = ON) ON PS(C1)
GO
/* But I could never get the primary key to! */
在上面，您可以就地对唯一索引进行分区。但是，我还没有想到可以尝试对主键起作用的方法。我非常确定也REBUILD可以。
用简单的英语来说，“分区表和索引上的并行查询处理”和“分区表并行性”听起来是同一件事。然而，在 SQL Server 2022 中，标准版具有“分区表并行性”，但没有分区表和索引上的并行查询处理。这两个功能有何不同？
我已尽力查阅了相关文档，但尚未阅读全部白皮书。我尚未了解这两个功能的具体内容。
这个问题是本网站关于堆的评分最高的问题。它询问了堆的使用情况。但是，我认为非常大的堆（例如数千 GB）是一种特殊情况，值得单独提出一个问题。
随着聚集索引的大小增加，聚集索引惩罚也会增加，即从非聚集索引中获取剩余键所需的逻辑读取次数。堆的情况并非如此。我认为堆被不公平地忽略了，因为太多人要么从数据仓库中学习了所有的数据库设计（主键扫描，因此聚集索引，通常是一个好主意），要么从未在足够大的数据库上工作过，无法感受到拥有真正大表的代价。
这就产生了一个问题：索引良好的非常大的堆是否具有在索引良好的非常大的聚类表中找不到的实际用例？
为避免这个问题太过宽泛，我们采用以下约束。假设：
总的来说，这意味着您的缓冲池 RAM 限制为 128 GB，并且不会定期对主键进行大规模扫描。从磁盘读取整个堆会很麻烦，因此有关将表用作暂存表或仅备份表的任何答案都不适用。
CREATE TABLE persons
(
person_id int not null,
name TEXT
);
INSERT INTO persons VALUES
(1, 'Adam'),
(2, 'Paul'),
(3, 'Tye'),
(4, 'Sarah');
CREATE TABLE json_to_parse
(
person_id int not null,
block json
);
INSERT INTO json_to_parse VALUES
(1, '{"size": "small", "love": "x"}'),
(2, '{"size": "medium", "love": "xx"}'),
(3, '{"size": "big", "love": "xxx"}');
运行没有问题
SELECT
*
FROM
json_to_parse
CROSS JOIN LATERAL
json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
persons
ON
persons.person_id = json_to_parse.person_id;
但这并不
SELECT
*
FROM
json_to_parse,
json_to_record(json_to_parse.block) AS my_json(size TEXT, love TEXT)
INNER JOIN
persons
ON
persons.person_id = json_to_parse.person_id;
我收到错误“对表“json_to_parse”的 FROM 子句条目的引用无效”
为什么第二个查询会出错？文档说得很清楚，LATERAL对于表值函数来说，这是可选的
中出现的表函数
FROM前面也可以加上关键字LATERAL，但对于函数来说，关键字是可选的；函数的参数FROM在任何情况下都可以包含对前面项提供的列的引用。
我最近一直在研究 Microsoft SQL Server 的列存储索引，我开始担心我的经验与行业经验不符。列存储索引旨在使聚合变得容易。人们经常说，出于这个原因，它们非常适合事实表。
这让我感到不安。根据我的经验，事实表不是聚合的。我制作的每个事实表的列表都是“主键后跟几个维度列，后跟我们存储的有关主键的每一点信息”的形式。然后它们被转储到 PowerBI 或 ThoughtSpot 等 BI 工具中，因此非技术人员可以根据维度进行筛选并找到他们想知道的任何信息。它们可能会不时聚合，但这肯定不是表格的主要用途。我预计这样的表格会有超过 100 列。
我所描述的表设计和访问模式是否符合事实表的预期？或者我所描述的是一种完全不同类型的表，而我不知道它的名称？
我所在的服务器存在严重的阻塞问题。不是死锁，只是普通的阻塞。我们知道这是服务器的主要瓶颈。但是，他们不知道块领导者是什么，所以我不知道要调整哪些查询。我可以安装更多监控，但我注意到他们启用了查询存储。查询存储中是否有任何信息可用于查找块领导者？
据我了解，动态 SQL 是批处理的一部分。然而，当我列出sqlserver.sql_batch_completed如下内容时，
CREATE EVENT SESSION [CaptureBatch] ON SERVER
ADD EVENT sqlserver.sql_batch_completed(
ACTION(sqlserver.client_app_name,sqlserver.client_hostname,sqlserver.database_id,sqlserver.database_name,sqlserver.query_hash,sqlserver.query_plan_hash,sqlserver.sql_text)
WHERE ([sqlserver].[database_id]>(4)))
ADD TARGET package0.event_file(SET filename=N'CaptureBatch',max_rollover_files=(0))
WITH (STARTUP_STATE=ON);
GO
ALTER EVENT SESSION [CaptureBatch] ON SERVER
STATE = START;
我看不到任何EXEC对该调用的调用EXEC。例如，此处的最后一行未显示在我的扩展事件日志中。
CREATE PROCEDURE [TestThis]
AS
BEGIN
SELECT 'Test';
END
GO
EXEC (N'EXEC TestThis');
这是为什么？这些是不是EXEC不算是一批，还是我漏掉了什么？
我似乎找不到有关此事件的任何详尽文献资料，所以如果我遗漏了一些，请原谅我。
假设您有一张表：
将这样的表移至内存 OLTP 有什么缺点吗？我的想法是，如果它始终在内存中，那么您应该考虑使用专为驻留在内存中而设计的架构。
读取已提交快照隔离 (RCSI) 已广为人知。它可能导致性能瓶颈的主要原因是版本链太长。是否有任何等待类型表明此特定问题？或者它仅由其他等待类型显示（如果是，是什么？）。
我经常发现 的输出具有sp_spaceused误导性。数据库中所有数据的大小实际上是数据文件和日志文件的总大小。我最近发现，它在各方面都更胜一筹。它比我计划喝酒直到忘记该过程sys.database_files要好得多。sp_spacedused
这给了我一个问题：检查数据库大小时，是否有任何 提供的功能或返回值sp_spacedused无法从 获得sys.database_files？我已检查过文档，我很确定没有。
今天，我正在检查一个庞大数据库中的每个表，并编写每个表的摘要。这意味着我要多次单击鼠标右键并按“选择前 1000 行”。有没有更快的方法？我更喜欢每个表一个选项卡，因此 SQL 技巧可能行不通。我想要做的是提高我浏览 SSMS 的速度。
Pro SQL Server 关系数据库设计和实施：可扩展性和性能的最佳实践是优秀数据库设计理念的可靠来源。作为实体-属性-值的替代方案，它建议使用动态 SQL 来允许用户向表中添加新的稀疏列。
对我来说，这个想法很糟糕。添加新列需要架构修改锁。这是一个非常严重的锁，我宁愿我的用户无法获得它。
稀疏列是否有任何属性使得允许用户采取如此严重的锁定并不像其他类型的列那样可怕？
READ COMMITTED在（悲观类型，不是 RCSI）下运行时，我刚刚看到UPDATE的 IX 锁死锁，其中SELECT的共享锁位于PAGE-level。SELECT使用并行执行计划运行。两者都没有明确使用事务。我理解UPDATEs 隐式创建事务。这是否表明并行SELECTs 也会创建隐式事务？对于非并行SELECTs 来说，情况不是这样吗？
我发现这相当令人困惑，因为教科书中的死锁例子都没有显示两个无事务查询死锁。
我到处都使用备份压缩。最近，我发现我的备份有点太大了。我决定通过压缩数据库中的索引（通常是PAGE压缩）来解决这个问题。数据库变小了很多。但令我惊讶的是，完整备份并没有变小！
这是预期的行为吗？
我显然有一个误解，但无论多少咨询文档都无法解决这个问题。考虑以下论点：
大众对堆的鄙视表明上述说法是错误的，但错在哪里呢？
假设我的服务器有一项任务，有时会根据我无法控制的因素（例如碎片）重建索引。还假设我确信它有一天会重建我想要更改的索引。有没有办法指示 SQL Server 我想WITH在下次重建时更改索引，而不是现在重建它？
例如，假设PK_HugeTable设置为填充因子 25。下次重建时，我想将其设置为 100。如果我不想现在重建索引，我该怎么办？
ALTER INDEX [...] SET适用于某些选项，但不适用于填充因子。
我有一个未压缩的聚集主键。它在聚集索引的主要部分中消耗了 63.6 GB，其中 LOB 为 17.9 GB。该表的唯一非聚集索引为 57.3 GB，其中 LOB 也为 17.9 GB。我希望在数据库不增长的情况下离线重建聚集索引。sp_spaceused不带参数运行会在其“未分配空间”列中报告 66 GB。
我想要做的事情可以实现吗？或者重建压缩索引是否会强制重建非聚集索引，从而占用至少 100 GB？
尽管我尽了最大努力，但我在文档或 Stack Overflow 中都没有找到答案。我对手边的一个小型数据库进行的实验表明，重建聚集索引不会强制重建非聚集索引。
微软的一篇旧论文ROW说，如果您有足够的 CPU 空间，请考虑默认使用压缩（重点是我的）。
如果行压缩可以节省空间，并且系统可以承受 10% 的 CPU 使用率增长，则所有数据都应进行行压缩
如今，我们的 CPU 空间比撰写本文时还要多。智者曾说过，PAGE除非有令人信服的理由不这样做，否则我们应该考虑在任何地方使用压缩。
这些都是很好的建议，我经常看到sp_estimate_data_compression_savings有人同意。但是，对于经常访问的微型表，应该怎么做呢？例如，我有一些非常小的维度表。最多 100 行，列很少。因为它们太小了，所以任何压缩带来的空间节省效益都很小。在有大量可用 CPU 空间的盒子上应用ROW或压缩这些微型表的最佳实践是什么？PAGE
就这个问题而言，请忽略列存储。我们只讨论基于磁盘的表上的老式行存储索引。
假设我有一张表，其中有许多我不关心的列，但有两列我很关心：Primary和Secondary。 上有一个聚集主键Primary。
CREATE TABLE [dbo].[OnlyTwoGoodColumnsButManyBad]
(
[Primary] INT PRIMARY KEY CLUSTERED,
[Secondary] NVARCHAR(500) NOT NULL,
[Evil1] NVARCHAR(MAX),
[Evil2] NVARCHAR(MAX),
[Evil3] NVARCHAR(MAX),
[Evil4] NVARCHAR(MAX),
[Evil5] NVARCHAR(MAX)
);
因为我不关心任何其他列，所以我决定我想要这个索引：
CREATE NONCLUSTERED INDEX [IX_Primary_Secondary]
ON [dbo].[OnlyTwoGoodColumnsButManyBad]
(
[Primary],
[Secondary]
);
鉴于此索引的键列表包含主键，因此毫无疑问该键列表是唯一的。因此，我很想这样做UNIQUE。
CREATE UNIQUE NONCLUSTERED INDEX [UIX_Primary_Secondary]
ON [dbo].[OnlyTwoGoodColumnsButManyBad]
(
[Primary],
[Secondary]
);
但这有什么好处吗？如果情况完全相同，但以 作为Secondary前导索引键，后面跟着 ，情况又如何呢Primary？