小编xhr*_*489的帖子

我想共享我的屏幕并显示一个执行计划，但是当我将鼠标悬停在一个操作符上以及在工具提示中用我的鼠标指向什么时，它就会消失。当我将鼠标指向一些信息时，有没有办法保持打开状态？

谢谢

是否有可能引发在 select 语句中跳过行或多次读取行的情况？例如，我们可能导致阻塞或死锁的方式......

有谁知道像这个页面https://columnscore.com/这样的工具，可以在其中确定一个表是否适合行或页压缩。

我也试图了解压缩的好处。我一直在阅读它，但仍然有这些问题。

1. 压缩会使缓冲区缓存中容纳更多 8KB 吗？数据何时变得未压缩，即在选择中？
2. 备份会变得更快吗？
3. 压缩广告cpu开销的原因是因为例如插入需要在插入之前被压缩吗？
4. 是否有充分的理由在不调查表的使用方式（即静态与易失性）的情况下压缩表。

一个同事开始压缩很多表（页）。我不知道这个决定背后的分析。我知道我们有时会在某些高峰时段等待资源信号量。我实际上不认为他知道他在做什么。我可以看到我们的 sos 调度程序收益等待略有增加。

我认为压缩会造成更大的伤害，现在维护任务似乎更多（例如备份、checkdb ......）。

我有一个多 TB 数据库，我一直在做一些清理工作并删除了许多表。所以现在数据文件有一半是空的。如果我不关心将空间释放给操作系统，是否还有其他原因来缩小文件？我想现在至少我不需要担心自动增长设置，如果我添加一个带有 ETL 的大表，这可能会减慢速度。

在 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从它？

我正在开发 SQL Server 实例并使用 Redgate SQL Monitor。我在前 10 个列表中看到一个执行了 1 次的查询，该查询的逻辑读取量比实例的内存多出约 100 倍，而且查询的持续时间只有几分钟。这怎么可能？我的意思是8KB页面乘以逻辑读取次数怎么会比内存多呢？我不明白是什么？

谢谢

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

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

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

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

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

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

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

我在 SQL Server 2016 中运行alter index reorganize一些列存储索引并收到死锁消息。

永远是reorganize受害者吗？因为我不想导致其他工作失败，并且我正在考虑添加一个set deadlock_priority. 或者这是内置的alter index声明？

在 SQL Server 的非聚集索引中将许多列作为包含列的成本是多少？

我有一个用于许多报告查询的表。我想知道以“有序”方式读取表格的次数。在聚集索引扫描的执行计划中，可以看到读取是否“有序”。此信息是否在其他地方可用，或者是搜索计划缓存的唯一解决方案？

假设我有一个固定长度的列，我SELECT从中获取 100 行。当读取固定长度列的不同行时，SQL Server 是否检查每一行的列长度，还是检查一次并重用此信息，以便可以更快地读取后续行？

相反，对于可变长度列，SQL Server 需要使用偏移数组检查每行的每个可变长度列的长度。

所以我的问题是：SQL Server 是否检查每行的固定长度数据类型的长度（即在该行的状态位 A 和 B 部分之后）？从逻辑上讲，当它需要读取固定长度列时，只需要检查一次。

这种开销是索引最适合固定长度列的原因吗？

不试图解决任何问题，只是试图理解。

额外信息：关于索引最好在固定长度列上：当我阅读这篇文章“ SQL Server 性能的索引策略”时，整个问题就开始了。在某一时刻，它说：“聚集索引键应该很窄，但也使用固定宽度的数据类型。” 这一说法的理由是什么？我只能想到与我的问题相关的原因，即固定长度的列读取起来更便宜，因为长度只需要检查一次。

我想在不可读的辅助副本上创建一个数据库来收集一些数据以用于故障排除和监控 AG。我读过，当不查询服务器时（即，当实例不是可读的辅助实例时），没有许可证成本，但当您查询服务器时，必须获得许可。

所以我的问题是：在辅助副本上创建单独的数据库是否存在问题（显然该数据库不会包含在AG中）？