小编Pau*_*ite的帖子

在 SQL Server 中的表上没有聚集索引有什么好处？

将要：

SELECT * INTO TABLE_A FROM TABLE_B

如果TABLE_A是堆会更快吗？

如果表是堆，哪些操作会受益？

我很确定UPDATEs 和DELETEs 将受益于聚集索引。什么INSERTS' 我的理解是INSERT“可能”受益于表是一个堆，无论是在速度方面还是其他资源和硬件（I/O、CPU、内存和存储......）。

硬件方面最稀缺的资源是什么？在存储方面，堆会占用更少的空间吗？磁盘存储不是最便宜的资源吗？如果是这样，将表保留为堆以节省磁盘空间是否合理？堆将如何影响CPU和I / O有SELECT，INSERT，UPDATE和DELETE？什么成本上升时，表是我们一个堆和SELECT，UPDATE并DELETE从它？

如果我有这个备份策略（每周完整备份和1小时日志备份），我可以将数据库恢复到绿色突出显示的时间段吗？顺便说一句，日志备份 2 是否包括其 lsn 大于日志备份 1 的 last_lsn 的所有日志记录？

我做了更多的测试，我想我找到了答案。根据备份计划中的映像，我做了一个初始完整备份，一些日志备份，然后日志备份 1，完整备份，日志备份 2。我在两者之间进行了修改。使用RESTORE HEADERONLY检查日志备份1，完全备份和日志备份2，下面是我得到了什么。如您所见，日志备份 2 捕获了日志备份 1 中最后一条的所有日志记录。如果我想恢复到绿色突出显示期间的某个点，我需要使用日志备份 2，而不是完整备份。

简而言之，规范化作为数据库设计技术的主要优点和缺点是什么？

用一些无组织数据的快照来回答这个问题可能更容易，作为一个具体的例子：

重新启动Windows是否也会重新启动SQL Server？

长话短说，我刚刚进行了更改，以便 SQL Server 和 Windows 身份验证用户都可以登录。服务器需要重新启动才能使更改生效，我可以只重新启动计算机而不是服务器吗？

我的服务器存在配置问题，我想更改其中一项设置，以便 SQL 凭据也可以登录（而不仅仅是 Windows 身份验证）。我的管理员说您可以进行任何更改，但不要重新启动 SQL Server。我问我可以重新启动SQL Server所在的Windows服务器吗，他说可以。

重新启动计算机与重新启动 SQL Server 的作用不一样吗？

当我做这样的查询时，做笛卡尔积（交叉连接）背后的想法是什么 -

SELECT * FROM agents, orders

我认为它们会连接（如pandas）。添加表格而不是乘以表格感觉更自然。

只是好奇，并没有在互联网上找到默认笛卡尔积背后的基本原理。我假设FROM table1, table2根据 SQL 的语法对于交叉连接可能更正确，但为什么呢？

SQL Server 有一个类型标志，称为is_nullable您可以在 上看到它sys.types。目前，（SQL Server 2019）它只设置为FALSE两种类型，sys.timestamp和sys.sysname. 对sys.timestamp这种类型似乎接受null。在sys.sysname它没有。这种行为有什么解释吗？

你可以看到这些类型

SELECT * FROM sys.types WHERE is_nullable = 0;  
SELECT TYPEPROPERTY('timestamp', 'AllowsNull');  -- returns 0

你可以像这样使用它，

CREATE TABLE foo ( a sys.timestamp );
INSERT INTO foo (a) VALUES ( null );

请注意，如果您使用，这将不起作用 sys.sysname

Msg 515 Level 16 State 2 Line 1
Cannot insert the value NULL into column 'a', table 'dbo.foo'; column does not allow nulls. INSERT …

Run Code Online (Sandbox Code Playgroud)

有人可以帮我弄清楚我的理解是否正确：

在我的可读辅助副本的 AG 仪表板上，我看到：

• 预计恢复时间（秒） - 4598
• REDO 队列 - 将近 24 GB

那么，如果我的辅助 AG 需要将节点/故障转移或 SQL 重新启动作为活动的一部分，这究竟意味着什么？

这是否意味着我的二级数据库需要 4598 秒才能使用 24 GB 的重做队列启动这个数据库？

我很担心，因为我们的一个生产秒方在白天的大部分时间里重做大小为 400 GB，而从 AG 仪表板恢复时间将近 10 小时。这是否意味着所谓的 DR 受到了损害？

我刚刚做了一个测试故障转移，正如我从错误日志消息中看到的那样，数据库按预期进行了恢复，并看到它在 1235 秒内完成。只是好奇，因为估计恢复的数量还差得很远。这只是为了解释我的业务用户帮助他们我们正在谈论的中断窗口。

如果 SQL Server 聚集索引是表的物理顺序，并且包含所有列，那么它是表本身吗？聚集索引是如何物理存储的？

我看过问答什么是聚集索引？但我的问题是关于这些的物理组织，而不是它们的功能。

我想弄清楚PostgreSQL在一段时间内等待锁所花费的时间（在这段时间内，PostgreSQL服务了很多请求）。

我知道的

PostgreSQL 系统表pg_locks显示一些信息。喜欢：

SELECT * FROM 
    pg_locks         pl   LEFT JOIN 
    pg_stat_activity psa
ON pl.pid = psa.pid;

但是我仍然无法弄清楚它在锁上花费了多长时间。

为什么我问这个问题

我发现当我增加 PostgreSQL 的并发性时（例如，增加每个收集的并行工作线程数、最大并行工作线程数或其他一些配置），我的 100 秒多线程 TPC-C-like 工作负载变得更慢（即，更低的吞吐量）。所以我想弄清楚这是否是因为争用过多。

类似的答案

对于 SQL Server：如何在没有分析器的情况下查看查询花费了多长时间等待锁定？

我知道表分区主要是为了数据管理。我知道大表的表维护变得更加困难，因为例如索引重建不能适应内存或因为例如使用 O(n*log(n)) 对比例进行排序，这会导致大表出现额外问题。

有人可以举一些例子，相对于服务器上的内存量，一个表应该有多大才能成为分区的明确候选者？假设表大于 RAM 量。不分区表是不好的做法吗？

我正在寻找一些可以作为分析依据的原则。

在下面的答案中链接到的文章中，它还提到：

• 长期运行的索引维护作业（或无法在所有运行他们，因为他们会花这么长时间）的参考。

所以我想我的问题可以表述为：考虑到硬件规格，当 SQL Server 没有分区时，SQL Server 何时开始出现行存储索引重建问题？

我不相信“这与桌子的大小无关”。当索引无法重建时，我会说分区与表的大小非常相关。