惯性聚合 高效追踪和阅读你感兴趣的博客、新闻、科技资讯
阅读原文 在惯性聚合中打开

推荐订阅源

V
Visual Studio Blog
博客园 - 司徒正美
Hugging Face - Blog
Hugging Face - Blog
博客园 - 叶小钗
The Cloudflare Blog
D
DataBreaches.Net
J
Java Code Geeks
G
Google Developers Blog
L
LangChain Blog
N
Netflix TechBlog - Medium
Stack Overflow Blog
Stack Overflow Blog
月光博客
月光博客
酷 壳 – CoolShell
酷 壳 – CoolShell
WordPress大学
WordPress大学
小众软件
小众软件
量子位
Apple Machine Learning Research
Apple Machine Learning Research
P
Proofpoint News Feed
博客园_首页
罗磊的独立博客
钛媒体:引领未来商业与生活新知
钛媒体:引领未来商业与生活新知
奇客Solidot–传递最新科技情报
奇客Solidot–传递最新科技情报
B
Blog
腾讯CDC

博客园 - ideas

从 datetime2 数据类型到 datetime 数据类型的转换产生一个超出范围的值。 移除google搜索结果中烦人的URL跟踪跳转 DiscuzNT首页版块提取优化 中国娱乐网招聘asp.net软件工程师 几个有用的DMV查询 【转】Iframe高度自适应(兼容IE/Firefox、同域/跨域) 【转】MAQETTA: 基于HTML5的开源可视化界面设计工具 高效能人士的七个习惯 有《基于行块分布函数的通用网页正文抽取》想到的 MongoDB 学习笔记—MapReduce MongoDB系列文章推荐 【转】linux screen 命令详解 - [linux] 关于添加索引视图后的数据存储区别 索引视图 添加计算列,并创建索引 浏览器的加载与页面性能优化【转】 IO瓶颈 内存瓶颈 Windows Live Writer 插件 Source Code Plug-in
关于分页存储过程的优化【让数据库按我们的意思执行查询计划】
ideas · 2011-08-25 · via 博客园 - ideas

先来对比两段分页SQL,假设条件:news表有15万记录,NewsTypeId=10有9万记录,当前查询NewsTypeID=10。那么,你会认为哪个SQL效率会高呢?

--代码一
DECLARE @cc INT
SELECT NewsId,ROW_NUMBER() OVER(ORDER BY SortNum DESC) AS RowIndex INTO #tb FROM news WITH(NOLOCK) WHERE NewsTypeId=@NewsTypeId AND IsShow=1
SET @cc = @@ROWCOUNT
SELECT n.* FROM news AS n WITH(NOLOCK), #tb As t WHERE t.RowIndex>@PageIndex*@PageSize AND t.RowIndex<=(@PageIndex+1)*@PageSize AND t.newsid=n.newsid
SELECT @cc
DROP TABLE #tb
--代码二
DECLARE @cc INT
SELECT NewsId,ROW_NUMBER() OVER(ORDER BY SortNum DESC) AS RowIndex INTO #tb FROM news WITH(NOLOCK) WHERE NewsTypeId=@NewsTypeId AND IsShow=1
SET @cc = @@ROWCOUNT
SELECT NewsId INTO #tb2 FROM #tb As t WHERE t.RowIndex>@PageIndex*@PageSize AND t.RowIndex<=(@PageIndex+1)*@PageSize
SELECT * FROM news WITH(NOLOCK) WHERE NewsId IN (SELECT * FROM #tb2)

SELECT @cc
DROP TABLE #tb
DROP TABLE #tb2

答案是代码二远远高于代码一。在代码一中加粗代码的操作会引起整表扫描,因为数据库引擎在认为WHERE表达式中满足条件记录大于一定阀值的时候,就不再去进行查询优化,而直接使用表扫描。看执行信息,:

表 'news'。扫描计数 1,逻辑读取 342 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

(98361 行受影响)

(1 行受影响)

(40 行受影响)

表 '#tb________________________________________00000004C024'。扫描计数 1,逻辑读取 257 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

表 'news'。扫描计数 1,逻辑读取 2805 次,物理读取 0 次,预读 235 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

(1 行受影响)

(1 行受影响)

原本,我想的执行计划,加粗部分的代码应该是聚焦索引查找,这样性能就提高很多。看代码二:

表 'news'。扫描计数 1,逻辑读取 342 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

(98361 行受影响)

(1 行受影响)

表 '#tb____________________________________00000004BEEF'。扫描计数 1,逻辑读取 257 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

(40 行受影响)

(1 行受影响)

(40 行受影响)

表 'news'。扫描计数 0,逻辑读取 131 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

表 '#tb2___________________________________00000004BEF0'。扫描计数 1,逻辑读取 2 次,物理读取 0 次,预读 0 次,lob 逻辑读取 0 次,lob 物理读取 0 次,lob 预读 0 次。

(1 行受影响)

(1 行受影响)

很明显,代码二与代码一中的IO操作数大大降低。且代码一随着@PageIndex越来越大,效率会越来越低;但代码二的效率不会随@PageIndex变化而改变。