高效SQL查询之索引（V）
先站在应用程序的角度说说它们的不同。
1、 直接拼 SQL
就像大家了解的那样，直接拼 SQL 带来了 SQL 注入攻击，带来了拼时些许的性能损失，但是拼不用添加 SqlParameter ，会少写很多代码——很多人喜欢直接拼，也许就因为这点。这种做法会把你拼好的 SQL 原样直接发送到 DB 服务器去执行。（注意类似 ”exec yourproc ‘param1’, 12” 的语句不在此范畴，这是调用存储过程的一种方式）
2、 参数化 SQL
所谓的“参数化 SQL ”就是在应用程序侧设置 SqlCommand.CommandText 的时候使用参数（如： @param1 ），然后通过 SqlCommand.Parameters.Add 来设置这些参数的值。这种做法会把你准备好的命令通过 sp_executesql 系统存储过程来执行。通过参数化 SQL ，和直接拼 SQL 相比，最直接的好处就是没有 SQL 注入攻击了。
3、 调用存储过程
直接调用存储过程其实和参数化 SQL 非常相似。唯一的本质不同在于你发送到 DB 服务器的指令不再是 sp_executesql ，而是直接的存储过程调用而已。
很多人非常非常厌恶在应用程序中使用存储过程，而宁愿使用拼 SQL 或者参数化 SQL ，理由是它们提供了更好的灵活性——这个理由其实非常非常的发指（俺现在喜欢上这个词了）。
现在做设计，一般都是从上到下来，重心都在业务逻辑上。传说中的领域模型设计完，测试用例都通过之后，才会考虑数据持久化方式。数据持久化是系统的一部分，但绝对不是最重要的部分，设计应该围绕业务逻辑开展，持久化应该仅仅是个附件。至少，高层应用应该尽可能的不关心处于最底层的物理存储结构（如：表）和数据持久、反持久方式（是拼 SQL 还是存储过程），所以用不用存储过程根本不重要。很多人害怕存储过程，其实是害怕存储过程中包括业务逻辑——真实情况是，如果存储过程中包含了业务逻辑，那一定最初需求分析不够导致用例提取不足，导致测试用例覆盖不够，导致领域模型设计不充分，要不就是偷懒。
=====
站在 DB 角度讨论它们的不同，主要从 cpu 、内存方面来考虑，其他诸如安全性， msdn 上都有， google 也能拿到一堆资料，不再赘述。
首先是查询计划。
SQL 编译完一条 SQL 之后，会把它缓存起来（可以通过 sys.syscacheobjects 系统视图查看），以后再有相同的查询过来（注意 sys.syscacheobjects 视图中的 sql 字段，和它存储的东西完全一样才能称为&
相关文档：
查询速度慢的原因很多，常见如下几种
1、没有索引或者没有用到索引(这是查询慢最常见的问题，是程序设计的缺陷)
2、I/O吞吐量小，形成了瓶颈效应。
3、没有创 ......
varchar和nvarchar如何选择：
varchar在SQL Server中是采用单字节来存储数据的，nvarchar是使用Unico来存储数据的。中文字符存储到SQL Server中会保存为两个字节（一般采用Unico编码），英文字符保存到数据库中，如果字段的类型为varchar，则只会占用一个字节，而如果字段的类型为nvarchar，则会占用两个字节。虽然使用nva ......
删除表记录，快速删除表记录，删除表这些语句相信大家都会，下面整理一下Truncate、delete、drop用法区别：
相同点
truncate和不带where子句的delete, 以及drop都会删除表内的数据
不同点:
1. truncate和 delete只删除数据不删除表的结构(定义)
drop语句将删除表的结构被依赖的约束(constrain) ......
【IT168 技术文档】
介绍
SQL SERVER2005提供了在.NET中自定义函数、存储过程、聚合、触发器以及类型的功能。于是，我们可以在数据库的函数、存储过程或类型整合.NET对象方法等。在之前的一篇文章，我们演示了如何将正则表达式功能整合到SQL CLR中。在本文中，还是演示这种整合，但是这次是从SQL CLR� ......
我们先看 NestedLoop 和 MergeJoin 的算法（以下为引用，见 RicCC 的《 通往性能优化的天堂 - 地狱 JOIN 方法说明 》 ):
==================================
NestedLoop:
foreach rowA in tableA where tableA.col2=?
{
search rowsB from tableB where tab ......
