...这篇文章太需要斟酌了- 索引不适合查询，所以慢了。
- 正在下载SQL SERVER 2008 和 SQL SERVER 2012.MSDN 有点儿不给力，速度比较慢，明天研究下...
- en..., SQL SERVER 2012 与SQL SERVER 2008 是用相同的协议吗？（客户端连接数据库引擎的时候）
- SQL SERVER 2012应该不会有这么大的差距。
CREATE Database DemoPager2012
在2012 中创建的测试数据库只是初始大小，因此插入数据时数据文件需要增长，可能占用了不少时间。
另外，如果log 文件每个VLF 太小，对性能也会产生很大影响的。
楼主可以试试在2012中创建数据库时，将DATA 文件指定为500M,log 文件也指定为500M,再试试？ - 这个SP 能支持几百万数据集的分页？
- @魔君六道
有可能。msdn的这篇文章的后面一点儿也提到了自动触发checkpoint的几种情况。其中，sql server 会根据上一次checkpoint 以来，新log如果达到一定阈值，就会触发checkpoint,而'大' 事务一定会带来log的不断增长，因此就会触发checkpoint,而一旦checkpoint被触发，又会带来部分dirty log的写入。
从另外一个角度思考，即使checkpoint线程一直不被任何事件触发，而log 缓冲区已经满了，在这种情况下，log如果不被写到磁盘，sql server又将如何处理呢？ - @魔君六道
你可以通过下面的查询查看所有分配个#table的所有数据页统计信息个第一个IAM页面的信息。
SELECT * FROM sys.sysindexes - 预读操作不考虑 “select 后所选定的列进行预读”
- 查询计划在生成，但未交给查询执行器执行之前，SQL SERVER 并不产生‘预读(但在生成执行计划时，查询处理器需要读取各个表的定义及表上各个索引的统计信息)。
当查询计划生成后，真正交给查询执行器执行时，SQL server 才会使用另外一个线程将查询“可能需要的数据”从磁盘读取的缓冲区中（前提是数据不在缓存中），这就是预读。同时这也意味着查询执行时进行逻辑运算的线程与“预读”所使用的线程并不是相同的线程。 - 大企业的顶尖职位，即讲究学历，又讲究能力。
- 5：工资需要区分基本工资 + 考核工资
这个是违法的。 - --存储过程只在创造时进行编译，以后每次执行存储过程都不需再重新编译.
存储过程在创建时并不编译，只进行语法检测与绑定。在第一次运行时编译；而以后也根据情况决定是否重编译。 - 还原数据库时，为还原后的数据库文件指定新路劲即可。
- 数据库业务逻辑与code业务逻辑的划分是一种艺术，很少有人掌握这种艺术..
- @Dreamer57
INNER JOIN 只是语法，INNER JOIN 背后对应三种逻辑运算（合并连接，嵌套循环，hash 连接），应该不会有哪本书告诉你“inner join 性能要好些”。 - 楼主，两个SELECT 返回的结果不一样吧？ 如果一样，应该也只是巧合。
- 写的不错！
INSERT操作还涉及到锁管理器，页管理器，索引管理器。楼主的INSERT 原理，至少还可以写三至五大篇文章. - 写的不错
- 触发器似鸡肋，食之无味，弃之可惜。
- 这不是表值函数的问题，本质问题是没有弄清楚UNION ALL 与 TOP 合在一起用的问题。
- 系统的整体架构有系统架构师设计，并分好1，2，3，层。但在实际开发的时候，写存储过程的DBA和前端开发人员有一个协作，而且很奇怪，当公司有专门的DBA时，很多前端开发人员喜欢为了自己工作的简化而要求将一些本该写道代码中的逻辑移到数据库（这种现象在改BUG阶段体现的尤为明显），而DBA又把关不严，因此造成了数据库承载了太多工作而响应缓慢。这样的结果就是，应用程序嗖嗖快，数据库老爷车一样。这时，前端的开发人员就产生观点了：存储过程不能用。
... - 系统的整体架构有系统架构师设计，并分好1，2，3，层。但在实际开发的时候，写存储过程的DBA和前端开发人员有一个协作，而且很奇怪，当公司有专门的DBA时，很多前端开发人员喜欢为了自己工作的简化而要求将一些本该写道代码中的逻辑移到数据库（这种现象在改BUG阶段体现的尤为明显），而DBA又把关不严，因此造成了数据库承载了太多工作而响应缓慢。这样的结果就是，应用程序嗖嗖快，数据库老爷车一样。这时，前端的开发人员就产生观点了：存储过程不能用。
... - @深蓝医生
把两种方式的执行计划打开看看，看看select top 20 究竟比select * 多做了些什么工作。 - 将成千上万的SQL命令全部重新运行一遍以缓存结果。）。
在数据库加上这样一层，我相信DB SERVER 性能的提高将会非常明显》。。... - 查询。 ...
- 等差数列，等比数列...
- 不支持，只有模...”
也就是说，即使两种数据库都支持流控制，临时表，表变量，但是在“移植”这类存储过程时，由于具体的使用方法（SQL语法等）的不同，也造成了移植困难。
唉，其实饶了一大圈，就是想让 Ivony...明白：对于这里所讨论的存储过程移植问题，将存储过程和SQL语言混为一团绝对不是扯淡。... - @Ivony...
表变量SQL SERVER 支持，其它很多种类的数据库都不支持。但是在SQL SERVER 平台下写存储过程，完全可以不用表变量。
流控制，临时表很多数据库都支持。
所以，符合你标准的存储过程是很多的，你觉得这些存储过程有没有你所主张的“可移植性”问题？
