SQL Server中存储过程比直接运行SQL语句慢的原因
在很多的资料中都描述说SQLSERVER的存储过程较普通的SQL语句有以下优点：
1. 存储过程只在创造时进行编译即可，以后每次执行存储过程都不需再重新编译，而我们通常使用的SQL语句每执行一次就编译一次,所以使用存储过程可提高数据库执行速度。
2. 经常会遇到复杂的业务逻辑和对数据库的操作，这个时候就会用SP来封装数据库操作。当对数据库进行复杂操作时(如对多个表进行 Update,Insert,Query,Delete时），可将此复杂操作用存储过程封装起来与数据库提供的事务处理结合一起使用。可以极大的提高数据库的使用效率，减少程序的执行时间，这一点在较大数据量的数据库的操作中是非常重要的。在代码上看，SQL语句和程序代码语句的分离，可以提高程序代码的可读性。
3. 存储过程可以设置参数，可以根据传入参数的不同重复使用同一个存储过程，从而高效的提高代码的优化率和可读性。
4. 安全性高,可设定只有某此用户才具有对指定存储过程的使用权存储过程的种类：
A. 系统存储过程：以sp_开头,用来进行系统的各项设定.取得信息.相关管理工作,如 sp_help就是取得指定对象的相关信息。
B. 扩展存储过程 以XP_开头,用来调用操作系统提供的功能
exec master..xp_cmdshell 'ping 10.8.16.1'
C. 用户自定义的存储过程,这是我们所指的存储过程常用格式
模版：Create procedure procedue_name [@parameter data_type][output]
[with]{recompile|encryption} as sql_statement
解释：output：表示此参数是可传回的
with {recompile|encryption} recompile:表示每次执行此存储过程时都重新编译一次;encryption:所创建的存储过程的内容会被加密。
但是最近我们项目组中有人写了一个存储过程,其计算时间为1个小时47分钟,而有的时候运行时间都超过了两个小时,同事描述说如果将存储过程中的语句拿出来直接运行也就10分钟左右就运行完毕，我没当回事，但是今天我自己写的存储过程也遇到了这个问题，在查找资料后原因终于找到了原因，原来是Parameter sniffing问题。
下面看我是如何将
相关文档：
SQL Server 2005 T-SQL Apply
透过执行计划可以看出，cross apply类似不带where条件的连接即cross join （交叉连接即笛卡尔积：返回行数为：前表符合条件的行乘上后表符合条件的行） 。形式上会灵活些.
使用 APPLY 运算符可以为实现查询操作的外部表表达式返回的每个行调用表值函数。表值函数作为右输入，外部表表达 ......
inner join(等值连接) 只返回两个表中联结字段相等的行
left join(左联接) 返回包括左表中的所有记录和右表中联结字段相等的记录
right join(右联接) 返回包括右表中的所有记录和左表中联结字段相等的记录
INNER JOIN 语法：
INNER JOIN 连接两个数据表的用法：
SELECT * from 表1 INNER JOIN 表2 ON 表1.字段号=表2 ......
今天接到客户电话，说操作数据无法保存。经过分析，发现他的数据库已经有5G多的大小，而最终发现有张表的索引出错了，用DBCC CHECK也无力回天。
每次用select * from ln003082 语句查询，都报如下错误：
服务器: 消息 605，级别 21，状态 1，行 1
试图从数据库 'ln_fl0125' 中提取的逻辑 ......
1. SET DEADLOCK_PRIORITY
说明：控制在发生死锁情况时会话的反应方式。如果两个进程都锁定数据，并且直到其它进程释放自己的锁时，每个进程才能释放自己的锁，即发生死锁情况。
语法：SET DEADLOCK_PRIORITY { LOW | NORMAL | @deadlock_var }
参数：LOW 指定当前会话为首选死锁牺牲品。Microsoft® S ......
.Pivot的用法体会:
语句范例:
select PN,[2006/5/30] as [20060530],[2006/6/2] as [20060602]
from consumptiondata a
Pivot (sum(a.M_qty) FOR a.M_date in ([2006/5/30],[2006/6/2])) as PVT
order by PN
Table结构 Consumptiondata (PN,M_Date,M_qty)
order by PN可要可不要,并不重 ......
