0

我们最大的表有大约 7 条 Mio 记录。当我在 int 类型的非聚集索引上查询表时：

例如：

Select * from MyTable where TypeID = 401

-- 显示少于 147000 行大约需要 7 秒。

Select * from MyTable where TypeID like '%401%'

-- 显示少于 147000 行大约需要 13 秒。

有没有办法在这里提高性能？例如。更多内存？我们目前有 16GB。

我的表脚本：

create table MyTable (ID int not null, Description nvarchar(50) not null, TypeID int not null, primary key (ID));

create index MyTable_TypeID on MyTable (TypeID);

编辑：大部分答案都围绕第二个查询，实际上可以忽略。应该重点关注第一个查询。有什么办法可以更快地检索数据？

4

3 回答 3

0 
Select * from MyTable where TypeID like '%401%'

此查询不能使用索引，因此它必须查看整个表，这就是它较慢的原因。如果可以以任何方式避免通配符，则永远不应使用通配符作为 where 条件中的第一个字符。它应该可以通过更好的设计来避免，特别是因为这是一个整数字段。

于 2013-09-12T17:01:02.143 回答
0

您可以将列包含到索引中（在叶节点上，而不是在实际索引中），这应该安全一段时间，因为在叶节点中找到正确的匹配项后，不需要指向和查找数据。

性能瓶颈是必须对每一行进行的匹配检查，无论检查结果是否为正。即使您的查询结果没有返回任何行，因为没有找到匹配项，它仍然需要相同的时间量。如果结果集很大并且必须通过网络传输大量数据，这当然也会产生负面影响。

编辑：很抱歉声称结果集大小无关紧要

对于每个匹配的 ID，必须读出所需的字段。如果它们不包含在索引中，则必须使用位于索引的叶元素中的指针（地址）从“正常”表中检索它们。包括这些字段使数据在索引中立即可用。

以下是如何创建包含列的索引

CREATE INDEX MyTable_TypeID on MyTable (TypeID)
INCLUDE (ID, Description, TypeID);

如http://technet.microsoft.com/en-us/library/ms189607%28v=sql.105%29.aspx

请注意，在插入或更新操作时，此类索引需要更多维护。这里的收获就是那里的损失。

于 2013-09-12T15:17:34.153 回答
0

在查询优化器中测试
Like 将 seek 更改为 scan
即使没有通配符
如果需要，请不要使用 like = 

Select * from MyTable where TypeID = 401
-- index seek

Select * from MyTable where TypeID like 401
-- index scan 

Select * from MyTable where TypeID like '%401%'
-- index scan

你为什么要搜索这样的整数？

如果列是 char，那么
像 'value' 仍将是索引搜索
，如 'value%' 仍将是索引搜索
，如 '%value' 仍将是索引扫描

于 2013-09-12T16:52:39.953 回答