【分页】用不用存储过程的区别

Question

【分页】方案网上有很多，对于好多项目来说都有它存在的意义。
网上流行很多分页存储过程，可以说都是前人研究的成果，值得学习和借鉴。以前做的项目也是用的分页存储过程，当时从网上找来，觉得好高深的SQL啊，那么长看不懂，觉得大家都这么用肯定没错。
后来看到了分页存储过程也可以SQL注入，所以细心的看了下分页存储过程中的代码，发现这不就是在存储过程里面拼接sql，然后EXEC！！
那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？
在程序里再复杂我都可以简单看懂，为什么要到存储过程里面拼接sql？？在本机分别测试了一下用/不用存储过程对千万级别的表的分页速度，差不多啊！！
难道还有客户端与服务器端的差别？我现在没法在服务器上测试，所以只有在这求解答了。
真的不明了，高手给点提示吧！！

Answer 1

你看的是哪里找来的存储过程。拼凑SQL和注入没有必然的联系。如果拼凑的内容并非来自用户输入，是不会有问题的。

Answer 2

现在所有的分页存储过程模式都是一样的，在存储过程中拼SQL，然后EXEC，这个不可否认吧？
如果不对查询条件做特殊字符过滤，就有可能SQL注入。
参见原文：http://www.cnblogs.com/yukaizhao/archive/2007/03/09/pagination_proc_problem.html

Answer 3

分页存储过程和普通存储过程不一样的，因为他里面是用EXEC(拼接的SQL)形式。
那我在程序里拼SQL，
  SqlCommand cmd = new SqlCommand(拼的SQ);
和
  SqlCommand cmd = new SqlCommand("ExecSql");
   cmd.Parameters.Add(拼的SQ);
有什么不同？到底谁更高效？Create proc ExecSql
( @sql varchar(4000))
as
BEGIN
 Exec @sql
END

Answer 4

差距不大，而且，如果这个使用存储过程，因为过于频繁，还有其他风险。
毕竟sql可以想断就断，存储过程执行到一半，你不用了，它就不是想断就断的了
事务无法关闭之类的错误，还会危害数据库

Answer 5

"
这不就是在存储过程里面拼接sql，然后EXEC！！
那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？
在程序里再复杂我都可以简单看懂，为什么要到存储过程里面拼接sql？？
""那我就不明白了，这和在程序里面拼接sql不是一样的吗？？？"
功能上是一样的,没有任何差别.
性能上也差别不大,如果是exec不是sp_execsql的话,也不存在预编译,每次都是重新编译的.
但是从隔离,封装的角度看,意义就大一些了,至少把做同一件事情的TSQL封装在一起了,更直观,更易于维护"在程序里再复杂我都可以简单看懂，为什么要到存储过程里面拼接sql？？"
在.NET程式里面,在存储过程里面,都是一样的T-SQL,为何看得懂一边,看不懂另外一边?另外分页不一定要直接用T-SQL/SP来实现,也可以用Linq(当然实质上其也是把Linq转换为T-SQL语句提交给数据库服务器的,只是我们不再关注这种转换)

Answer 6

"
  SqlCommand cmd = new SqlCommand(拼的SQ);
和
  SqlCommand cmd = new SqlCommand("ExecSql");
  cmd.Parameters.Add(拼的SQ);
有什么不同？到底谁更高效？
"这里考量的不是高效不高效,从执行效率来说,如果参数不是频繁变化 SqlCommand cmd = new SqlCommand("ExecSql"); 要高些,但是如果Exec @sql中@sql是随时变化的,那么效率没啥差别.这里考量的是封装,安全性,可读性
用cmd.Parameters.Add的方式可以防止注入
而且调用与输入是分离的,一目了然.

Answer 7

如果你把程序中的sql逻辑一模一样的放到存储过程中，那肯定没差别的，可以忽略不记程序过程的优点就是可以数据操纵逻辑封装在一起