常见的操作符：Sort、Hash Match(聚合)、Filter、Compute Scalar等
一：Sort
select Shelf from Production.ProductInventory order by Shelf
在进行聚集索引扫描操作后，数据集进行了Sort操作。当优化器认为在执行过程中需要对数据尽心排序时，就会产生这个操作。
整个查询对1069行数据进行了排序操作。排序操作本身不是问题，问题是他的开销已经达到了76%。因为没有索引存在。只能执行Sort操作，这个列子是缺少了where条件，返回了非预期的数据；也可能因为缺少具有排序功能的索引，使用聚集索引可以实现预排序功能，从而减少了排序开销。
可以Order By一个聚集索引来消除Sort操作。
select * from Production.ProductInventory order by ProductID
加入了Order By子句，但是执行计划并没有出现Sort操作符，因为这个聚集索引以及你按顺序存储了数据，优化器会认为没有必要再次排序。如果必须排序，Sql Server会优先选择在内存中进行，如果排序的数据集实在太大，SQL Server就只能把数据放在TempDB中并在磁盘中排序。这时候会触发Sort Warning事件。
2.Hash Match（聚合）
在查询中需要进行聚合操作（COUNT/SUM/AVG/MAX/MIN）有时就可能出现这种操作符
select City,COUNT(City) as CityCount from Person.Address group by City
该语句没有 Where 条件，所以使用Index Scan来返回全部的数据，然后优化器使用聚集索引来实现COUNT的逻辑。由于数据量比较大，所以优化器会选择Hash Match聚合操作符。首先在内存中创建临时哈希表，然后计算满足GROUP BY条件的数据，最终汇总数据并返回
聚合操作是昂贵的操作，可能只有通过添加有效的WHERE条件或者通过使用索引视图预先聚合的方式来提高性能。
3.Filter
select City,COUNT(City) as CityCount from Person.Address group by city having COUNT(City)>1
当引入HAVING子句后，就出现了Filter操作符，这个操作符会对输出再次进行限制，可以对比Filter前后的数据量
如图：
要注意：看上去HAVING子句减少了数据量，但是实际并没有，因为HAVING子句只会在聚合操作完成后才进行，而常见的性能问题都在聚合操作之前，所以除了添加WHERE条件控制聚合的数据量之外，这种可操作符没有什么可提升空间
4.Compute Scalar --计算标量
这个操作符主要用于标量操作，通常出现在SELECT过程中，需要重新组合数据列
select e.JobTitle, a.City, p.LastName+‘, ‘+p.FirstName as EmployeeName from HumanResources.Employee as e join Person.BusinessEntityAddress as bea on e.BusinessEntityID=bea.BusinessEntityID join Person.Address a on bea.AddressID=a.AddressID join Person.Person as p on e.BusinessEntityID=p.BusinessEntityID
在这个查询中LastName和FirstName合并成了一个新列EmployeeName，这种操作符没有什么问题，但是如果在WHERE、JOIN的ON条件中出现，那可能表示存在问题，需要考虑使用计算列等方式来改进
原文地址：https://www.cnblogs.com/sunliyuan/p/9784248.html