标签: sql-server

是否可以运行 SQL 命令来确定数据库的恢复模式？我想知道它是否完全恢复。

简而言之，
哪些因素会影响查询优化器对索引视图索引的选择？

对我来说，索引视图似乎违背了我对优化器如何选择索引的理解。我之前看过这个问题，但 OP 并没有得到很好的接受。 我真的在寻找 guideposts，但我会编造一个伪示例，然后发布带有大量 DDL、输出、示例的真实示例。

假设我使用的是 Enterprise 2008+，理解 with(noexpand)

伪示例

以这个伪示例为例：我创建了一个包含 22 个连接、17 个过滤器和一个跨越 1000 万行表的马戏团小马的视图。这种观点实现起来很昂贵（是的，大写 E）。我将对视图进行 SCHEMABIND 和索引。然后一个 SELECT a,b FROM AnIndexedView WHERE theClusterKeyField < 84. 在我不知道的优化器逻辑中，执行了底层连接。

结果：

• 无提示：4825 次读取 720 行，47 个 cpu 超过 76 毫秒，估计子树成本为 0.30523。
• 使用提示：17 次读取，720 行，4 毫秒内 15 个 cpu，估计子树成本为 0.007253

那么这里发生了什么？我已经在Enterprise 2008、2008-R2 和 2012 中尝试过。根据我能想到的每个指标，使用视图索引的效率要高得多。我没有参数嗅探问题或倾斜的数据，因为这是临时的。

一个真实（长）的例子

除非你是一个受虐狂，否则你可能不需要或不想阅读这部分。

是的
，企业版。

Microsoft SQL Server 2012 - 11.0.2100.60 (X64) 2012 年 2 月 10 日 19:39:15 …

我通常通过首先构造一个使用正确计划的查询，然后将其复制到类似的查询中来创建计划指南。但是，这有时很棘手，尤其是在查询不完全相同的情况下。从头开始创建计划指南的正确方法是什么？

SQLKiwi 已经提到在 SSIS 中制定计划，有没有一种方法或有用的工具来帮助为 SQL Server 制定一个好的计划？

有问题的具体实例是这个 CTE：SQLFiddle

with cte(guid,other) as (
  select newid(),1 union all
  select newid(),2 union all
  select newid(),3)
select a.guid, a.other, b.guid guidb, b.other otherb
from cte a
cross join cte b
order by a.other, b.other;

有没有任何方法来使结果拿出正好3个不同的guidS和没有更多？我希望将来能够通过包含多次引用的 CTE 类型查询的计划指南来更好地回答问题，以克服一些 SQL Server CTE 怪癖。

为了存储 128 位 UUID，有多种存储选项：

1. 一个字节[16]列
2. 两个 bigint/long（64 位）列
3. CHAR(36) 列 - 32 个十六进制数字 + 4 个破折号。
4. 一个 UUID 数据库特定列，如果 db 支持它

从索引的角度来看，哪些是最有效的？如果数据库不支持专用的 uuid 类型，那么 1、2、3 中的哪一个是最佳选择？

在我们的应用程序中，我们有一个网格，用户可以在其中翻阅大量记录（10-2000 万）。网格支持在多列 (20+) 中按升序和降序排序。许多值也不是唯一的，因此应用程序还按 id 排序作为决胜局，以确保行始终出现在同一页面上。例如，如果用户想要按小部件大小（从最大的开始）排序，应用程序会生成一个看起来像这样的查询：

SELECT TOP 30
    * -- (Pretend that there is a list of columns here)
FROM Test
--  WHERE widgetSize > 100
ORDER BY
    widgetSize DESC,
    id ASC

此查询需要大约 15 秒才能运行（使用缓存数据），主要成本似乎是按小部件大小对大约 130 万行进行排序。在尝试调整此查询时，我发现如果我添加一个WHERE仅限于最大 widgetSizes的子句（在上面的查询中注释掉），则查询只需要约 800 毫秒（所有前 50,000 个结果的小部件大小都大于 100） .

为什么没有WHERE子句的查询速度会如此之慢？我检查了 widgetSize 列的统计数据，它们显示前 739 行的 WidgetSize > 506。由于只需要 30 行，SQL Server 可以不使用此信息来推断它只需要对具有小部件大小的行进行排序哪个大？

我知道我可以通过在和上添加索引来使这个特定查询更快地执行，但是这个索引只在这个特定场景中有用，并且如果（例如）用户反转排序方向就变得毫无价值。该表包含许多附加列，并且每个索引都很大（~200mb），因此我无法为每个可能的排序顺序添加索引。widgetSizeid

有什么方法可以让这些查询查询执行而不为每个可能的排序顺序添加索引？（用户可以按 20 多列中的任何一列进行排序）

以下脚本创建上表并用一些代表性数据填充它。该表比实际表窄得多，但仍然展示了我所看到的性能。在我的 PC 上，带有 where 子句的查询需要约 200 毫秒，而没有 where caluse 的查询需要约 800 …

我使用 Ola Hallengrens 脚本进行索引维护。在我这样做之前，我使用以下查询来查看哪些索引碎片化最多：

SELECT dbschemas.[name] as 'Schema',
dbtables.[name] as 'Table',
dbindexes.[name] as 'Index',
indexstats.avg_fragmentation_in_percent,
indexstats.page_count
FROM sys.dm_db_index_physical_stats (DB_ID(), NULL, NULL, NULL, NULL) AS indexstats
INNER JOIN sys.tables dbtables on dbtables.[object_id] = indexstats.[object_id]
INNER JOIN sys.schemas dbschemas on dbtables.[schema_id] = dbschemas.[schema_id]
INNER JOIN sys.indexes AS dbindexes ON dbindexes.[object_id] = indexstats.[object_id]
AND indexstats.index_id = dbindexes.index_id
ORDER BY indexstats.avg_fragmentation_in_percent desc

在我的情况下，avg_fragmentation超过70％的15个指数和超过30％的28个指数。

因此，我使用 Ola Hallengren 的解决方案重建每个索引。当我再次运行查询时，结果如下：

碎片超过70％为12个索引，超过30％为15个索引。 …

我正在尝试将查询从 Oracle 迁移到 SQL Server 2014。

这是我在 Oracle 中运行良好的查询：

select
count(distinct A) over (partition by B) / count(*) over() as A_B
from MyTable 

这是我尝试在 SQL Server 2014 中运行此查询后遇到的错误。

Use of DISTINCT is not allowed with the OVER clause

有谁知道是什么问题？在 SQL Server 中可以进行这种查询吗？请指教。

使用什么证书来加密实例上的每个数据库。

我可以使用以下方法获取数据，但如何编写查询

USE master
GO

-- this provides the list of certificates
SELECT * FROM sys.certificates


-- this provides the list of databases (encryption_state = 3) is encrypted
SELECT * FROM sys.dm_database_encryption_keys
 WHERE encryption_state = 3;

我注意到 sys.certifcates.thumbprint 和 sys.dm_database_encryption_keys.encryptor_thumbprint 列包含相同的数据。

我有一个观点，complicated_view-- 有一些连接和 where 子句。现在，

select * from complicated_view (9000 records)

更快，更快，比

select top 500 * from complicated_view

我们说的是 19 秒对 5+ 分钟。

第一个查询返回所有 9000 条记录。如何只获得前 500 名的时间长得可笑？

显然，我将在这里查看执行计划 ---- 但是一旦我弄清楚为什么SQL Server 以次优方式运行“前 500”，我该如何实际告诉它以快速方式运行计划，喜欢坐满桌？

当然，我可能不得不完全重写视图——但很奇怪。

基本上，我将此数据表连接到第 3 方软件，该软件使用select top 500 *无法修改的默认查询预先检查表。因此，除了将此视图转储到实际表中（非常草率）之外，我也无法绕过他们的“前 500 名”附录。

这是 SQL Server 2012。

编辑：不同意重复标志。另一个问题，顶部比所有的都快。这将是预期的行为，返回较少的行。我的情况正好相反。另外，我的理解是 Top 100 是一种与 Top 100+ 不同的算法。我什至不认为重复的问题有正确的答案。也就是说，TOP X 查询将在很早的时候对潜在的大量表进行排序，而不是在它们被聚合/过滤/等之后。为什么是一个谜，但如何显然存在。

我运行了一个 SQL Server 2016 数据库，其中有一个包含 100 多万行的下表：

StationId | ParameterId |       DateTime       | Value
    1     |      2      | 2020-02-04 15:00:000 |  5.20
    1     |      2      | 2020-02-04 14:00:000 |  5.20
    1     |      2      | 2020-02-04 13:00:000 |  5.20
    1     |      3      | 2020-02-04 15:00:000 |  2.81
    1     |      3      | 2020-02-04 14:00:000 |  2.81
    1     |      4      | 2020-02-04 15:00:000 |  5.23
    2     |      2      | 2020-02-04 15:00:000 |  3.70
    2     |      4      | 2020-02-04 15:00:000 |  12.20
    3     | …