标签: query-performance

问题：

我们有一个社交网站，会员可以在其中相互评价兼容性或匹配度。该user_match_ratings表包含超过 2.2 亿行（9 演出数据或近 20 演出索引）。针对此表的查询通常显示在 slow.log（阈值 > 2 秒）中，并且是系统中记录最频繁的慢查询：

Query_time: 3  Lock_time: 0  Rows_sent: 3  Rows_examined: 1051
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 395357 group by rating;"

Query_time: 4  Lock_time: 0  Rows_sent: 3  Rows_examined: 1294
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 4182969 group by rating;"

Query_time: 3  Lock_time: 0  Rows_sent: 3  Rows_examined: 446
"select rating, count(*) as tally from user_match_ratings where rated_user_id = 630148 group by rating;"

Query_time: …

我正在使用 PostgreSQL (9.4) 数据库在 Ruby on Rails 中开发应用程序。对于我的用例，表中的列将被非常频繁地查找，因为应用程序的重点是在模型上搜索非常具体的属性。

我目前正在决定是对列使用integer类型还是简单地使用典型的字符串类型（例如character varying(255)，这是 Rails 中的默认值），因为我不确定索引上的性能差异是什么。

这些列是 enums。对于它们可以拥有的可能值的数量，它们具有固定的大小。大多数枚举长度不超过 5，这意味着索引在应用程序的整个生命周期中或多或少是固定的；因此，整数和字符串索引在节点数上是相同的。

但是，将被索引的字符串可能有大约 20 个字符长，在内存中大约是整数的 5 倍（如果一个整数是 4 个字节，并且字符串是纯 ASCII 每个字符 1 个字节，那么这成立）。我不知道数据库引擎如何进行索引查找，但是如果它需要“扫描”字符串直到它完全匹配，那么本质上这意味着字符串查找将比整数查找慢 5 倍；整数查找匹配之前的“扫描”将是 4 个字节而不是 20 个。这就是我的想象：

查找值为（整数）4：

扫描………………………………………………………………………………………………………………………………………… 正在获取记录... |BYTE_1|BYTE_2|BYTE_3|BYTE_4|BYTE_5|BYTE_6|BYTE_7|BYTE_8|...|

查找值是（字符串）“some_val”（8 个字节）：

扫描................................................. …………………………………………………………………………………………………………………………………………………………………… 正在获取记录... |BYTE_1|BYTE_2|BYTE_3|BYTE_4|BYTE_5|BYTE_6|BYTE_7|BYTE_8|...|

我希望这是有道理的。基本上，因为整数占用更少的空间，它可以比它的字符串对应物更快地“匹配”。也许这是一个完全错误的猜测，但我不是专家，所以这就是我问你们的原因！我想我刚刚找到的这个答案似乎支持我的假设，但我想确定一下。

列中可能值的数量在使用任何一个时都不会改变，因此索引本身不会改变（除非我向枚举添加了一个新值）。在这种情况下，使用integeror会有性能差异varchar(255)，还是使用整数类型更有意义？

我问的原因是 Rails 的enum类型将整数映射到字符串键，但它们并不是面向用户的列。本质上，您无法验证枚举值是否有效，因为无效值会ArgumentError在运行任何验证之前导致。使用string类型将允许验证，但如果存在性能成本，我宁愿绕过验证问题。

对于我尝试优化的中等复杂查询，我注意到删除TOP n子句会更改执行计划。我猜想，当查询包含TOP n数据库引擎时，会运行查询而忽略该TOP子句，然后最后将结果集缩小到请求的n行数。图形执行计划似乎表明情况确实如此——TOP是“最后”一步。但似乎还有更多事情发生。

我的问题是，TOP n 子句如何（以及为什么）影响查询的执行计划？

这是我的情况的简化版本：

查询匹配来自两个表 A 和 B 的行。

如果没有该TOP子句，优化器估计将有来自表 A 的 19k 行和来自表 B 的 46k 行。返回的实际行数是 A 的 16k 和 B 的 13k。哈希匹配用于连接这两个结果集总共 69 行（然后应用排序）。此查询发生得非常快。

当我添加TOP 1001优化器时不使用哈希匹配；相反，它首先对表 A 的结果进行排序（与 19k/16k 相同的估计值/实际值）并对表 B 执行嵌套循环。表 B 的估计行数现在为 1，奇怪的是TOP n直接影响对 B 的估计执行次数（索引搜索） - 它似乎总是2n+1，或者在我的情况下是 2003 年。如果我改变，这个估计会相应地改变TOP n。当然，由于这是嵌套连接，因此实际执行次数为 16k（表 A 中的行数），这会减慢查询速度。

实际场景有点复杂，但这捕获了基本思想/行为。两个表都使用索引查找进行搜索。这是 SQL Server 2008 R2 企业版。

如果我有一个UPDATE实际上没有改变任何数据的语句（因为数据已经处于更新状态）。在WHERE子句中进行检查以防止更新是否有任何性能优势？

例如，以下 UPDATE 1 和 UPDATE 2 之间的执行速度是否有任何差异：

CREATE TABLE MyTable (ID int PRIMARY KEY, Value int);
INSERT INTO MyTable (ID, Value)
VALUES
    (1, 1),
    (2, 2),
    (3, 3);

-- UPDATE 1
UPDATE MyTable
SET
    Value = 2
WHERE
    ID = 2
    AND Value <> 2;
SELECT @@ROWCOUNT;

-- UPDATE 2
UPDATE MyTable
SET
    Value = 2
WHERE
    ID = 2;
SELECT @@ROWCOUNT;

DROP TABLE MyTable;

我问的原因是我需要行数来包含未更改的行，所以我知道如果 ID 不存在是否进行插入。因此，我使用了 UPDATE 2 表单。如果使用 UPDATE 1 表单有性能优势，是否有可能以某种方式获得我需要的行数？

SQL Server 如何确定查询计划的缺失索引建议中键列的顺序？

如果您在视图内部或外部过滤视图会有所不同吗？

例如，这两个查询之间有什么区别吗？

SELECT Id
FROM MyTable
WHERE SomeColumn = 1

或者

SELECT Id
FROM MyView
WHERE SomeColumn = 1

并且MyView定义为

SELECT Id, SomeColumn
FROM MyTable

如果源表位于链接服务器上，答案有什么不同吗？

我问是因为我必须从链接服务器两次查询一个大表（4400 万行），并获得结果的汇总。我想知道是否应该创建两个视图来访问数据，每个查询一个视图，或者我是否可以使用单个视图和一个WHERE子句。

查询中未使用的 CTE 是否会影响性能和/或更改生成的查询计划？

我能够重现一个我认为出乎意料的查询性能问题。我正在寻找一个专注于内部的答案。

在我的机器上，以下查询执行聚集索引扫描并花费大约 6.8 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test WITH (FORCESCAN)
WHERE ID1 NOT IN
(
N'1', N'2',N'3', N'4', N'5',
N'6', N'7', N'8', N'9', N'10',
N'11', N'12',N'13', N'14', N'15',
N'16', N'17', N'18', N'19', N'20'
)
AND (ID1 = N'FILLER TEXT' AND ID2 >= N'' OR (ID1 > N'FILLER TEXT'))
ORDER BY ID1, ID2 OFFSET 12000000 ROWS FETCH FIRST 1 ROW ONLY
OPTION (MAXDOP 1);

以下查询执行聚集索引查找（唯一的区别是删除FORCESCAN提示），但需要大约 18.2 秒的 CPU 时间：

SELECT ID1, ID2
FROM two_col_key_test
WHERE ID1 …

我知道存储过程通过执行路径更有效（比应用程序中的内联 sql）。然而，当被按下时，我对原因不是很了解。

我想知道对此的技术推理（以稍后我可以向某人解释的方式）。

谁能帮我制定一个好的答案？

我有一个数据库，我将文件加载到临时表中，从这个临时表我有 1-2 个连接来解析一些外键，然后将这些行插入到最终表中（每个月有一个分区）。我有大约 34 亿行数据，用于三个月的数据。

将这些行暂存到最终表中的最快方法是什么？SSIS 数据流任务（使用视图作为源并具有快速加载活动）或插入 INTO SELECT .... 命令？我尝试了数据流任务，可以在大约 5 小时内获得大约 10 亿行（服务器上有 8 个内核/192 GB RAM），这对我来说感觉很慢。