数据的可用性、可访问性和性能对于业务成功至关重要。 性能调优和SQL查询优化是困难的，但是必要的。
本文将讨论SQL查询时应用的一些SQL查询优化建议。
SELECT * vs SELECT column list
通常，开发人员使用SELECT *语句从表中读取数据。 它读取表中所有列的可用数据。 假设一个表[DBO].[POS].[APPUSER]存储 90882名员工的数据，并且您需要检索以下信息：
UserName
Password
查询效率低：如果使用SELECT * 语句，它将返回所有 90882名员工的所有列数据。
以下是select column的例子
下面两个执行计划的比较，请注意相同行数的估计行大小的差异以及CPU和IO差异。
Count(*) VS if exists
假设需要检查SQL表中是否存在特定记录。 通常，我们使用COUNT (*)来检查记录，它返回输出中的记录数。
但是，我们可以为此目的使用IF EXISTS()函数。 为了进行比较，我在执行查询之前启用了统计信息。
例如要检验在表ItemInfo对于category 73088是否有数据
SET STATISTICS IO ON
-- count查询
SELECT count(*) FROM [POS].[dbo].[ItemInfo]
where MainCategoryKey =73088
--IF EXISTS()
IF EXISTS(Select mainitemid from [POS].[dbo].[ItemInfo]
whereMainCategoryKey = 73088)
PRINT 'YES'
ELSE
PRINT 'NO'
SET STATISTICS IO OFF
我们开启了统计信息，下面是他们的比较,我们可以清晰地看出if exists效率快的多。
避免滥用SQL DISTINCT
每当我们想要查询中的唯一记录时，我们习惯性地使用SQL DISTINCT子句。
让我们看一下简单的SELECT语句并比较执行计划。 两个查询之间的唯一区别是DISTINCT运算符
select MainCategoryKey from ItemInfo
select DISTINCT MainCategoryKey from ItemInfo
可以使用 GROUP BY、CTE(common table expresssion) 或子查询来编写高效的 SQL 代码，而不是使用DISTINCT 从结果集中获取不同的值。
SQL 查询中的通配符用法
假设要搜索包含以指定字符串开头的名称的特定记录。 开发人员使用通配符来搜索匹配的记录。但是要避免滥用头通配符%。
因为在开头使用通配符时，查询优化器可能无法使用合适的索引。 所以需要评估您的应用程序要求。 应该尽量避免在搜索字符串中使用通配符，因为它可能会强制查询优化器使用表扫描。 如果表很大，则需要更高的系统资源用于 IO、CPU 和内存，并可能导致 SQL 查询出现性能问题。
使用 WHERE 和 HAVING 子句
WHERE 和 HAVING 子句用作数据行过滤器。WHERE 子句在应用分组逻辑之前过滤数据，而HAVING 子句在聚合计算之后过滤行。
例如，在下面的查询中，我们在没有WHERE 子句的 HAVING 子句中使用数据过滤器。
Select SalesOrderID,
SUM(UnitPrice* OrderQty) asOrderTotal
From Sales.salesOrderDetail
GROUP BYSalesOrderID
HAVING SalesOrderID>30000 and SalesOrderID<55555 and SUM(UnitPrice* OrderQty)>1
Go
以下查询首先在 WHERE 子句中过滤数据，然后将HAVING 子句用于聚合数据过滤器。
Select SalesOrderID,
SUM(UnitPrice* OrderQty) asOrderTotal
From Sales.salesOrderDetail
where SalesOrderID>30000 and SalesOrderID<55555
GROUP BYSalesOrderID
HAVING SUM(UnitPrice* OrderQty)>1000
Go
IN 和 EXISTS 子句的使用
应该避免在 SQL 查询中使用 IN子句，而是用exists来代替。 例如，在下面的查询中，我们首先从ItemInfo表中找到产品 ItemInternalKey，然后在 itemcode表中查找相应的记录。
select top 1000 * from ItemCode where ItemInternalKey in (select top 100 ItemInternalKey from ItemInfo)
下面是用Exists来实现的相同功能
select top 1000 * from ItemCode where exists (select top 100 ItemInternalKey from ItemInfo)
对比执行计划后，可以明确看出用exists的效率高效的多。
缺少索引
有时，当执行 SQL 查询并在 SSMS 中查看执行计划时，会得到一个可能会改进您的 SQL 查询的索引的建议。
通常，DBA 遵循 SSMS 的建议并创建索引，可能会提高查询性能。 但是，您不应直接根据这些建议盲目创建索引。 它可能会影响其他查询性能并减慢您的INSERT 和 UPDATE 语句。
或者，使用动态管理视图来检查环境中缺失索引的详细信息。
sys.dm_db_missing_index_details
sys.dm_db_missing_index_group_stats
sys.dm_db_missing_index_groups
sys.dm_db_missing_index_columns
所以首先要查看 SQL 表的现有索引。
注意，过度索引和索引不足都对查询性能不利。
在查看现有索引后应用影响最大的缺失索引建议并在测试环境中实施。 如果工作负载在实施新的缺失索引后运行良好，则值得添加该索引。
查询提示
开发人员在 t-SQL 语句中明确指定查询提示。 这些查询提示会覆盖查询优化器的行为，并强制它根据您的查询提示准备执行计划。 经常使用的查询提示是 NOLOCK、Optimize For 和 Recompile Merge/Hash/Loop。
