T-SQL 的编码习惯以及规范，影响的是查询优化器对执行计划的选择
健壮的SQL语句，更稳定、更高效
SELECT 几个部分：
- 查询的数据来自什么表
- 需要查询表中哪些字段 (尽量不使用类似于 **SELECT *** )
- 查询出符合哪些特定条件的数据
- 对数据进行排序、分组、汇总等操作 (限定结果集 => SELECT TOP 防止大量IO)
ORDER BY 子句性能取决于参与排序操作的数据量大小，避免大数据量的排序操作（考虑添加非聚集索引）
GROUP BY (DISTINCT 相当于全字段的GROUP BY)
冲突 => 所有的分组和排序需要用到索引，索引不能建立太多
DELETE 检索数据的性能
? 排他锁，影响到索引；如果频繁删除数据的表，建立索引时，谨慎查询和更新的频率；
WHERE 子句优化
? 针对筛选条件的语句进行的，其实就是一个合理索引的选择及高效应用
where条件是否合理的判断因素：
- 是否有合适的索引可供使用
-
字段是否有函数计算
- 返回结果集是否过大
- 是否仅查询出需要的字段
关联查询
=> 嵌套循环 (Inner Join) => 适用于小数据量和大数据量之间的连接操作，是性能最好的连接方式
? 内部表（数据量多的表）存在索引时，嵌套循环发挥最佳性能，执行计划进行索引查找 Index Seek
? 外部表存 （数据量小的表）在索引，执行计划进行 索引扫描 Index Scan
=> 合并连接 (Merge Join)
? 关联表数据相当且存在唯一索引，如果都不存在索引则会进行哈希连接
=> 哈希连接 (Hash Match)
? 关联表不存在索引，也未进行排序 (考虑在表中的字段增加索引进行 Inner Join 或者 Merge Join)
子查询
-
子查询尽量集中在where子句中，方便阅读
-
在一个语句中，子查询的数量不超过3个，整个查询语句涉及的表不超过5个
子查询中的语句会被执行计划分解、简化、特殊的转换，转化成常用的连接操作
-
避免在子查询中对大量的数据进行汇总或者排序操作
-
尽量缩小子查询中可能返回的结果集，设计的数据量尽可能小
-
尽量使用确定的判断符（=/IN/EXISTS）避免使用any、all