Sql server 使用字符串搜索和表定义函数提高SP的性能。

以下查询片段的估计成本分别为62%和31%

insert into #Matches (LegalPartyId)
        select top (@MaxRows) LegalPartyId
        from (select LegalPartyId, DisplayName from GRM_Records_LegalPartySearchable(@EffDate) where (DisplayName LIKE '4450700010%')
union select LegalPartyId, DisplayName from GRM_Records_LegalPartySearchable(@EffDate) where (LastName LIKE '4450700010%')
union select LegalPartyId, DisplayName from GRM_Records_LegalPartySearchable(@EffDate) where (PIN LIKE '4450700010%')
union select LegalPartyId, DisplayName from GRM_Records_LegalPartySearchable(@EffDate) where (AIN LIKE '4450700010%')
union select LegalPartyId, DisplayName from GRM_Records_LegalPartySearchable(@EffDate) where (CommStreetName LIKE '4450700010%')) lp
        group by LegalPartyId, DisplayName
        order by DisplayName

insert into #OwnedPINs (LegalPartyId, PIN)
        select distinct lpr.LegalPartyId, rtrim(ro.PIN) PIN
        from
          grm_records_AllLegalPartyRoleByEffDate(@EffDate, 'A') lpr
          join grm_records_RevObjByEffDate(@EffDate, null) ro
            on ro.Id = lpr.ObjectId
        where
          lpr.LegalPartyId in (select LegalPartyId from #Matches)
          and lpr.ObjectType = 100002 -- ObjectType.RevObj
          and lpr.LPRoleType = 100701

SQL server tuning adviser建议我们需要添加以下索引

但是，索引的所有列都已经是非聚集索引的一部分

CREATE NONCLUSTERED INDEX [LegalPartyRole1] ON [dbo].[LegalPartyRole]
    (
    [ObjectId] ASC, [ObjectType] ASC,  [BegEffDate] ASC,  [LPRoleType] ASC, 
    [EffStatus] ASC, [PrimeLegalParty] ASC, [LegalPartyId] ASC, [Id] ASC
    );

SQL server是否要求我对非聚集索引的列重新排序

另外，SQLSentry向我展示了执行计划的几个“节点”的以下消息。这是因为大量使用表定义的函数

---

如何提高此存储过程的性能？请告知

只需选择所需的数据，我们就可以将执行时间从150秒缩短到3秒。在下面的查询中，我们删除了DisplayName，因为它不是必需的。DisplayName导致了完整表扫描。但是，如果我们只选择LegalPartyId，系统将使用索引扫描

insert into #Matches (LegalPartyId)
        select top (@MaxRows) LegalPartyId
        from (select LegalPartyId from GRM_Records_LegalPartySearchable(@EffDate) where (DisplayName LIKE '4450700010%')
union select LegalPartyId from GRM_Records_LegalPartySearchable(@EffDate) where (LastName LIKE '4450700010%')
union select LegalPartyId from GRM_Records_LegalPartySearchable(@EffDate) where (PIN LIKE '4450700010%')
union select LegalPartyId from GRM_Records_LegalPartySearchable(@EffDate) where (AIN LIKE '4450700010%')
union select LegalPartyId from GRM_Records_LegalPartySearchable(@EffDate) where (CommStreetName LIKE '4450700010%')) lp
        group by LegalPartyId
        order by LegalPartyId

---

你的索引有一个很长的键。。。以及关键问题中的列顺序。谢谢@pmbAustin。还有其他建议吗？没有更多的信息真的很难说。您可以尝试将建议的索引与现有索引进行比较（尝试使用一个索引，然后使用另一个索引，然后使用两个索引）。在运行查询之前使用SET STATISTICS TIME ON，然后使用SET STATISTICS TIME OFF。这有助于进行比较。设置统计IO开/关还可以帮助您查看有多少I/O。除此之外，您还必须发布索引和计划。我不明白为什么SQL建议使用包含EffStatus的索引，而您似乎根本不在查询中使用EffStatus。除非您使用的实际查询不同。编辑：没关系，我想你的一个函数一定在大量使用它。@ZLK：是的，我的一个函数在大量使用它。更改非聚集索引中列的顺序（如@pmbAustin所建议的）将SP的性能提高了10%，但没有我们预期的那么多。