背景：由于项目人数众多，同一个界面可能有几个人进行编码。不同的人在SQL语句性能上有所不同。有些页面存在短暂的卡屏，为了快速找出问题所在。
由于涉及的项目使用的SQL SERVER数据库，这里使用SQL Server Profiler工具：
1、打开SQL Server Profiler 工具：
2、可以使用WIndows认证，也可以使用sa认证
3、
1)、General:大部分可以默认
Save to file：将这次跟踪的记录写入到文件可以为以后的DataBase Engine Tuning Advisor提供输入
Save to Table:将这次跟踪的记录存入到表中。
2)、Events Selection
4、开始点击网站，执行的SQL语句会被监听到：
重点是Duration的时间进行分析找出时间最大的。这里Duration 的单位是毫秒。
Reads 和 Writes 也是重点研究的对象，当读写非常大的时候可以考虑复制TextData里面的指令进行真实的执行计划分析。
5、SQL语句的磁盘IO和CPU消耗时间分析
1）、直接在窗口中输入命令：SET STATISTICS IO ON、SET STATISTICS TIME ON
2）、通过工具栏打开
2-1、
2-2、选中 SET STATISTICS TIME 和 SET STATISTICS IO
能够快速查看某句SQL语句磁盘IO的读写，某句SQL语句CPU执行时间
Scan count ： Number of seeks/scans started after reaching the leaf level in any direction to retrieve all the values to construct the final dataset for the output.
意思就是为了构建最终输出从到达叶子节点后向任意方向检索所有的值进行扫描的次数，我的理解就是全表扫描的次数。
logical reads:在缓存中读取的页数。
physical reads 硬盘中读取的页数。
read-ahead reads 为查询提前放入到缓存的页数。
lob logical reads lob physical reads,lob read-ahead reads:文本、图片、或者大数据类型从数据缓存、硬盘读取的页数、为查询提前放入到缓存页数。
6、SQL真实的执行计划分析
1）、打开真实执行计划分析
2、执行SQL语句
1、SELECT * FROM YFOutstock YO INNER JOIN YFOutstockDetail YOD ON YO.ID = YOD.Parent
2、SELECT * FROM YFOutstock YO INNER JOIN YFOutstockDetail YOD ON YO.ID = YOD.Parent WHERE YO.ID = '1D39C77A-AD61-4D43-98A6-9F86905B6DB1'
从真实执行计划可以分析：
语句1查询的成本 91%，语句2查询的成本 9%。很明显性能语句1 可能需要进行优化
解决办法：
1）可以将 * 替换成我们需要的字段，不需要的字段，就不需要筛选，可以避免书签查找。
2）当发现对某个表进行全表扫描（Table Scan）的时候需要，尽量避免全表扫描（可能是我们没有建立恰当的索引：聚索引和非聚集索引）。
3）使用谓词筛选出符合条件。
4）尽量避免两张大表进行连接查询（可以适当建立违反第3范式的表，减少表与表之间的关联）。
