无法测试查询，但需要针对WHERE OR..OR..OR子句的最佳索引策略

Question

应用程序每周运行一次例程。 上次运行非常慢，我们知道在下一次运行期间将处理更多数据。 到目前为止，例程中最慢的语句将临时表连接到产品表。 Profiler显示的读取次数很高，表明索引编制不正确。 在上一次运行期间，“产品”表具有200,000行，而“临时”表具有1200。

 update tmp      
 set tmp.col1 = pd.col1, 
     tmp.col2 = pd.col2, 
     tmp.col3 = pd.col3 
 from #temptable tmp
, Products pd with (nolock)      
 where tmp.col2 = pd.col2 
    or tmp.col2 = pd.col3 
    or tmp.col2 = pd.col4       
    or tmp.col2 = pd.col5 

我只有一次机会应用索引策略。 临时表是根据仅存在很短时间且没有副本的数据生成的，因此无法在下一次运行之前重新创建。 计划缓存没有执行计划。

该查询应更新为ANSI-92，但我正在处理它。

产品表在col2，col3，col4，col5的每个列上都有索引，但是没有覆盖复合值或包含更新值。

临时表没有索引。

我没有尝试任何操作，因为在下一次实时运行之前无法进行测试。

谁能建议我应该应用涵盖4个“产品”列的复合索引，还是使用四个索引-每个列对应一个索引，col1，col2和col3包含INCLUDE？

Answer 1

你的问题是有局限性，因为你不能得到showplan ，倒不如说遵循这些方法。 注意：如果自上次运行proc以来未重新启动服务器，则这将为索引和昂贵的查询提供提示。

如果使用临时表到产品表的内部联接，则将增强查询执行。

遵循这些方法

1）通过query_stats检查最昂贵的查询，使用以下脚本隔离存储的proc是否在昂贵查询的列表中

SELECT TOP 5 t.TEXT AS 'SQL Text'
    ,st.execution_count
    ,ISNULL(st.total_elapsed_time / st.execution_count, 0) AS 'AVG Excecution Time'
    ,st.total_worker_time / st.execution_count AS 'AVG Worker Time'
    ,st.total_worker_time
    ,st.max_logical_reads
    ,st.max_logical_writes
    ,st.creation_time
    ,ISNULL(st.execution_count / DATEDIFF(second, st.creation_time, getdate()), 0) AS 'Calls Per Second'
FROM sys.dm_exec_query_stats st
CROSS APPLY sys.dm_exec_sql_text(st.sql_handle) t
ORDER BY st.total_elapsed_time DESC

2）还要检查服务器中最近运行的查询的索引要求，如果您不能手动重新运行查询或没有showplan https：//blog.sqlauthority ，这是Pinal出色的脚本，可为我们提供索引需求.COM / 2011/01/03 / SQL服务器-2008-失踪指数脚本下载/

SELECT TOP 25
dm_mid.database_id AS DatabaseID,
dm_migs.avg_user_impact*(dm_migs.user_seeks+dm_migs.user_scans) Avg_Estimated_Impact,
dm_migs.last_user_seek AS Last_User_Seek,
OBJECT_NAME(dm_mid.OBJECT_ID,dm_mid.database_id) AS [TableName],
'CREATE INDEX [IX_' + OBJECT_NAME(dm_mid.OBJECT_ID,dm_mid.database_id) + '_'
+ REPLACE(REPLACE(REPLACE(ISNULL(dm_mid.equality_columns,''),', ','_'),'[',''),']','') 
+ CASE
WHEN dm_mid.equality_columns IS NOT NULL
AND dm_mid.inequality_columns IS NOT NULL THEN '_'
ELSE ''
END
+ REPLACE(REPLACE(REPLACE(ISNULL(dm_mid.inequality_columns,''),', ','_'),'[',''),']','')
+ ']'
+ ' ON ' + dm_mid.statement
+ ' (' + ISNULL (dm_mid.equality_columns,'')
+ CASE WHEN dm_mid.equality_columns IS NOT NULL AND dm_mid.inequality_columns 
IS NOT NULL THEN ',' ELSE
'' END
+ ISNULL (dm_mid.inequality_columns, '')
+ ')'
+ ISNULL (' INCLUDE (' + dm_mid.included_columns + ')', '') AS Create_Statement
FROM sys.dm_db_missing_index_groups dm_mig
INNER JOIN sys.dm_db_missing_index_group_stats dm_migs
ON dm_migs.group_handle = dm_mig.index_group_handle
INNER JOIN sys.dm_db_missing_index_details dm_mid
ON dm_mig.index_handle = dm_mid.index_handle
WHERE dm_mid.database_ID = DB_ID()
ORDER BY Avg_Estimated_Impact DESC
GO

附：此解决方案仅是必要索引的指示，主要是根据您的直觉

Answer 2

在没有关于执行时间或计划的统计信息的情况下，并且考虑到您想尽快加快速度（即使索引大小增加了），我建议创建4个覆盖索引（每列一个）

CREATE NONCLUSTERED INDEX NCI_Products_col2 ON Products (col2) INCLUDE (col1, col3)
CREATE NONCLUSTERED INDEX NCI_Products_col3 ON Products (col3) INCLUDE (col1, col2)
CREATE NONCLUSTERED INDEX NCI_Products_col4 ON Products (col4) INCLUDE (col1, col2, col3)
CREATE NONCLUSTERED INDEX NCI_Products_col5 ON Products (col5) INCLUDE (col1, col2, col3)

并将更新分为4个步骤：

-- join by col2 (skip tmp.col2 update)
update tmp set 
    tmp.col1 = pd.col1, 
    tmp.col3 = pd.col3 
from 
    #temptable tmp
    INNER JOIN Products pd with (nolock) ON tmp.col2 = pd.col2 


-- join by col3
update tmp set 
    tmp.col1 = pd.col1, 
    tmp.col2 = pd.col2, 
    tmp.col3 = pd.col3 
from 
    #temptable tmp
    INNER JOIN Products pd with (nolock) ON tmp.col2 = pd.col3

-- join by col4
update tmp set 
    tmp.col1 = pd.col1, 
    tmp.col2 = pd.col2, 
    tmp.col3 = pd.col3 
from 
    #temptable tmp
    INNER JOIN Products pd with (nolock) ON tmp.col2 = pd.col4

-- join by col5
update tmp set 
    tmp.col1 = pd.col1, 
    tmp.col2 = pd.col2, 
    tmp.col3 = pd.col3 
from 
    #temptable tmp
    INNER JOIN Products pd with (nolock) ON tmp.col2 = pd.col5

因此，通过删除OR联接，每个更新都应使用其覆盖索引。 如果需要将操作作为整体处理，则可能需要包装事务。

请验证更新顺序，根据原始查询的性质，以不同的顺序执行可能会产生不同的结果（如果可以在Product col3 和 col5为不同的记录找到tmp col2则更新的值可能不同）。