笑东风

摘要： 使用FOR XML 来解决PRINT 字符串被截断的问题 阅读全文

摘要： --如果在存储过程中定义变量，并为变量SET赋值，该变量的值无法为执行计划提供参考（即执行计划不考虑该变量）,将会出现预估行数和实际行数相差过大导致执行计划不优的情况--如果在存储过程中使用SET为存储过程参数重新赋值，执行计划仍采用执行时传入的值来生成执行计划。--=======================================--准备测试数据DROP TABLE TB1GOSELECT IDENTITY(INT,1,1) AS RID,*INTO TB1FROM sys.all_columnsGOINSERT INTO TB1SELECT *FROM sys.all_colu 阅读全文

摘要： --===========================--查询语句EXEC [sys].[sp_executesql] N'SELECT COUNT(1)FROM dbo.TB1WHERE RID>@RID',N'@RID INT',@RID=10 --===========================--为该语句创建执行计划EXEC [sys].[sp_create_plan_guide]@name=N'Guide3',@type=N'SQL',@stmt=N'SELECT COUNT(1)FROM dbo 阅读全文

摘要： --==========================================--在生产环境中，会遇到表中某列数据分布不均匀，导致在生成执行计划--不能适应参数的变化--==========================================--解决方式：强制存储过程重编译CREATE PROCEDURE dbo.USP_GetData( @PID INT)WITH RECOMPILEASBEGINSELECT *FROM TB1WHERE PID=@PIDENDGO--==========================================--解决方式:.. 阅读全文

摘要： 1>虽然可以使用“简单参数化”或“强制参数化”来优化 adhoc 查询，重用执行计划，但是仍会造成一定的性能损耗，对于重复执行的语句，还是应该将之参数化。 2>当大量只执行一次的adhoc 查询语句出现时，可以使用 optimize for ad hoc workloads 来减少计划缓存使用的内存。 阅读全文

摘要： 虽然在很多情况下SQL Sever引擎能帮助我们判定 WHERE 条件后的执行顺序,但我们仍应该将选择性高(过滤数据多)的条件放置在 WHERE 语句中的前面，尤其对于复杂的SQL 语句，应仔细分析测试。 阅读全文

摘要： 绝对值得收藏的DMV 此经典SQL囊括以下信息 1. Causes of the server waits 2. Databases using the most IO 3. Count of missing indexes, by database 4. Most important missing indexes 5. Unused Indexes 6. Most costly indexes (high maintenance) 7. Most used indexes 8. Most fragmented indexes 9. Most costly queries, by average IO 10. Most costly queries, by average CPU 11. Most costly CLR queries, by average CLR time 12. Most executed queries 13. Queries suffering most from blocking 14. Queries with the lo 阅读全文