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

推荐订阅源

W
WeLiveSecurity
T
The Exploit Database - CXSecurity.com
C
CXSECURITY Database RSS Feed - CXSecurity.com
S
Security @ Cisco Blogs
T
Threat Research - Cisco Blogs
TaoSecurity Blog
TaoSecurity Blog
Recent Commits to openclaw:main
Recent Commits to openclaw:main
cs.AI updates on arXiv.org
cs.AI updates on arXiv.org
腾讯CDC
Exploit-DB.com RSS Feed
Exploit-DB.com RSS Feed
OSCHINA 社区最新新闻
OSCHINA 社区最新新闻
T
The Blog of Author Tim Ferriss
Microsoft Azure Blog
Microsoft Azure Blog
罗磊的独立博客
F
Full Disclosure
博客园 - 【当耐特】
C
CERT Recently Published Vulnerability Notes
Engineering at Meta
Engineering at Meta
Application and Cybersecurity Blog
Application and Cybersecurity Blog
T
Threatpost
I
Intezer
V2EX - 技术
V2EX - 技术
H
Hackread – Cybersecurity News, Data Breaches, AI and More
The Hacker News
The Hacker News
小众软件
小众软件
Google DeepMind News
Google DeepMind News
T
Tailwind CSS Blog
D
Darknet – Hacking Tools, Hacker News & Cyber Security
B
Blog RSS Feed
Microsoft Security Blog
Microsoft Security Blog
N
News | PayPal Newsroom
MyScale Blog
MyScale Blog
AI
AI
Vercel News
Vercel News
Spread Privacy
Spread Privacy
美团技术团队
CTFtime.org: upcoming CTF events
CTFtime.org: upcoming CTF events
The GitHub Blog
The GitHub Blog
V
Vulnerabilities – Threatpost
Schneier on Security
Schneier on Security
Cyberwarzone
Cyberwarzone
G
GRAHAM CLULEY
Help Net Security
Help Net Security
Hacker News: Ask HN
Hacker News: Ask HN
Google DeepMind News
Google DeepMind News
MongoDB | Blog
MongoDB | Blog
L
LINUX DO - 热门话题
U
Unit 42
L
LangChain Blog
Recent Announcements
Recent Announcements

博客园 - jadesun

【转载】Zachman框架 参加了IBM的架构师培训,总结了一些内容 数据仓库 - 事实表和维度表建立的方法论 Hadoop的学习历程 Hadoop手册_v0.3 MySQL_Cluster 的尝试及各种测试 Hadoop的学习历程 Hadoop手册_v0.2 尝试数据分片处理 和同事扯了一个理论模型出来,后面再验证是否合理。 依赖倒置原则 迪米特法则 中国航油项目的一次数据库优化,关于Audit Logout的问题。 公文流转SQL优化日志七 公文流转SQL优化日志六 和同事们终于将Entity FrameWork整合进新的框架中了,发布第一个版本。 继续上篇实现的架构,有了新的进展。介绍一下格瑞趋势的产品 公文流转SQL优化日志五 工作日志,正在实现中的架构,针对SQL SERVER。参考了DZ的设计 公文流转SQL优化日志四 公文流转SQL优化日志三
公文流转SQL优化日志二
jadesun · 2011-07-06 · via 博客园 - jadesun

测试数据库: 10.20.143.153;database=dbhnaoa3;uid=sa;pwd=tab,955@loct,目的优化 sp_CreatGetDocuToDoCount 存储过程。

拆分存储过程中的SQL语句,语句一:

DBCC FREEPROCCACHE

DBCC DROPCLEANBUFFERS

SET STATISTICS IO ON

SET STATISTICS TIME ON

SELECT cnvcLeadEname,Count(cnvcLeadEname) AS iCount FROM DBHNAOA3_2010.dbo.tbAllot tbA 

    WHERE (tbA.cndReadDate IS NULL AND tbA.cnvcAllotType='0') OR (tbA.cndReadDate is not null and tbA.cnvcAllotType='1')

       GROUP BY cnvcLeadEname

SET STATISTICS TIME OFF

SET STATISTICS IO OFF

SQL Server 执行时间:

   CPU 时间= 0 毫秒,耗费时间= 0 毫秒。

'tbAllot'。扫描计数4逻辑读77371 次,物理读0 次,预读77634

SQL Server 执行时间:

   CPU 时间= 1906 毫秒,耗费时间= 9009 毫秒。

(10611 行受影响)

查看执行计划,最终还是进行了表扫描。


从数据库中看到,cndReadDatecnvcAllotType字段没有建立索引,并且cnvcLeadEname用于了Group by。那么给cndReadDate和cnvcAllotType字段建立索引。


并且将INTO TmpCreatGetDocuToDoCount1 改为 INTO #TmpCreatGetDocuToDoCount1采用临时表的方式,不在当前库建立实体表,让Master去维护。语句改成如下的方式:

SET STATISTICS IO ON

SET STATISTICS TIME ON

SELECT cnvcLeadEname,count(cnvcLeadEname) AS iCount INTO #TmpCreatGetDocuToDoCount1 FROM (

    SELECT cnvcLeadEname FROM DBHNAOA3_2010.dbo.tbAllot tbA 

       WHERE (tbA.cndReadDate IS NULL AND tbA.cnvcAllotType='0')

    UNION ALL

    SELECT cnvcLeadEname FROM DBHNAOA3_2010.dbo.tbAllot tbA 

       WHERE (tbA.cndReadDate IS NOT NULL AND tbA.cnvcAllotType='1')

    ) tbB GROUP BY cnvcLeadEname

Drop table #TmpCreatGetDocuToDoCount1

SET STATISTICS TIME OFF

SET STATISTICS IO OFF

结果如下:

SQL Server 执行时间:

   CPU 时间= 0 毫秒,耗费时间= 0 毫秒。

'#TmpCreatGetDocuToDoCount1__________________________________________________________________________________________000000000A98'。扫描计数0,逻辑读1 次,物理读0 次,预读0 次。

'tbAllot'。扫描计数4逻辑读30308 次,物理读0 次,预读0 次。

SQL Server 执行时间:

   CPU 时间= 5162 毫秒,耗费时间= 5162 毫秒。

(10611 行受影响)

查看执行计划:


结果比较:

没有优化之前的SQL语句

'tbAllot'。扫描计数4逻辑读77371 次,物理读0 次,预读77634

SQL Server 执行时间:

   CPU 时间= 1906 毫秒,耗费时间= 9009 毫秒。

(10611 行受影响)

执行之后的SQL语句

'tbAllot'。扫描计数4逻辑读30308 次,物理读0 次,预读0 次。

SQL Server 执行时间:

   CPU 时间= 5162 毫秒,耗费时间= 5162 毫秒。

(10611 行受影响)

经过小红哥的业务指导分析,SQL语句继续改成如下的格式:

SET STATISTICS IO ON

SET STATISTICS TIME ON

SELECT cnvcLeadEname,COUNT(cnvcLeadEname) AS iCount FROM (

       SELECT cnvcLeadEname FROM DBHNAOA3_2010.dbo.tbAllot WHERE cndReadDate IS NULL

       UNION ALL

       SELECT cnvcLeadEname FROM DBHNAOA3_2010.dbo.tbAllot WHERE cnvcAllotType='1'

) tbA GROUP BY cnvcLeadEname

SET STATISTICS TIME OFF

SET STATISTICS IO OFF

SQL Server 执行时间:

   CPU 时间= 0 毫秒,耗费时间= 0 毫秒。

'tbAllot'。扫描计数2,逻辑读1514 次,物理读3 次,预读1516 次。

SQL Server 执行时间:

   CPU 时间= 312 毫秒,耗费时间= 714 毫秒。

(10611 行受影响)

查看执行计划:


三次比较如下:

第一次:

SQL Server 执行时间:

   CPU 时间= 0 毫秒,耗费时间= 0 毫秒。

'tbAllot'。扫描计数4逻辑读77371 次,物理读0 次,预读77634

SQL Server 执行时间:

   CPU 时间= 1906 毫秒,耗费时间= 9009 毫秒。

(10611 行受影响)

第二次:

'tbAllot'。扫描计数4逻辑读30308 次,物理读0 次,预读0 次。

SQL Server 执行时间:

   CPU 时间= 5162 毫秒,耗费时间= 5162 毫秒。

(10611 行受影响)

第三次:

SQL Server 执行时间:

   CPU 时间= 0 毫秒,耗费时间= 0 毫秒。

'tbAllot'。扫描计数2,逻辑读1514 次,物理读3 次,预读1516 次。

SQL Server 执行时间:

   CPU 时间= 312 毫秒,耗费时间= 714 毫秒。

(10611 行受影响)

结论:在数据一致的情况下,第三次优化的结果比第二次的结果有了更大幅度的提升。从执行计划可以看得出来,查询的环节更少了。有时候对查询的优化可以多从业务的角度考虑一下。