讨论一：性能优化-（执行计划，statistics,cost模型,参数嗅探，plan compile&recompile等）

2013-12-02 09:18:08 5k 阅读 AI 写同款 · GEO 优化AI 选题数据监测一键分发 ›

理解关系型数据库：从关系模型到SQL Server工程实践关系型数据库的核心不是SQL语法或图形化工具，而是建立在集合论与逻辑学之上的关系模型——它定义了数据如何组织、关联与约束。该模型通过原子性、无序性、唯一性和无名性四大原则确保数据结构严谨；借助主键、外键等键机制实现引用完整性；并依托选择、投影、连接等关系运算支撑SQL语义。其技术价值在于提供强一致性、事务保障（ACID）与可验证的数据逻辑，广泛应用于金融交易、电商订单、医疗系统等对数据可靠性要求极高的场景。本文以SQL Server为载体，深入解析关系模型如何在存储引擎、查询优化器与事务管理中落地为可工程化阅读详情

经过一周时间的收集，今天开始针对这次活动中大家感兴趣的问题进行讨论：

讨论一：

性能优化-（执行计划，statistics,cost模型,参数嗅探，plan compile&recompile等）

...全文

SQL为何成为AI时代的底层操作系统语言 SQL 是一种声明式数据操作语言，其核心原理在于通过约束、聚合与连接精确表达业务逻辑，而非执行过程。在 AI 时代，它不再仅是取数工具，而是承担数据认知接口、特征定义 DSL 和向量检索协同层等关键角色，提供确定性、可验证性与强治理能力。相比 Python 或 Spark 的过程式表达，SQL 天然适配 LLM 的自然语言理解边界，成为人机语义共识层；同时支撑实时特征计算、混合检索、图关系建模与半结构化解析等典型 AI 工程场景。本文聚焦 PostgreSQL 与现代数仓中的 CTEs、窗口函数、递归查询及阅读详情

开着拖拉机泡妞

MS-SQL Server 34,876 成员 254,635 内容

+ 关注 + 加入社区

切换为时间正序

最爱午夜 2014-08-22

打赏
举报

引用 37 楼 SQL_Beginner 的回复:

经常在论坛看到问高CPU的问题，简单的总结一下。 1，首先你要确认，高CPU是不是是SQL SERVER进程引起的还是别的进程引起的，这个很容易，直接看任务管理器。 2，如果从任务管理器看出高CPU确实是用SQL SERVER引起的。 3，如果是SQL SERVER引起的。 3.1SQL SERVER的一个比较BAD的执行计划引起的，比如说缺少必要的INDEX，引起了hash join什么的。这个也分成2种： 1，造成高CPU的语句已经执行结束，这个时候可以用下面的语句来检查。 select highest_cpu_queries.plan_handle, highest_cpu_queries.total_worker_time, q.dbid, q.objectid, q.number, q.encrypted, q.[text] from (select top 50 qs.plan_handle, qs.total_worker_time from sys.dm_exec_query_stats qs order by qs.total_worker_time desc) as highest_cpu_queries cross apply sys.dm_exec_sql_text(plan_handle) as q order by highest_cpu_queries.total_worker_time desc 3.1.2，造成高CPU的语句正在运行，这个时候可以用下面的语句来检查。 SELECT st.text, qp.query_plan, rq.* FROM sys.dm_exec_requests RQ CROSS APPLY sys.dm_exec_sql_text(rq.sql_handle) as st CROSS APPLY sys.dm_exec_query_plan(rq.plan_handle) as qp order by RQ.CPU_time desc 3.2 开启了SQL profiler. 通过3.1.2可以看到 sp_trace_getdata这个SP在运行。 3.3 过度的编译跟重编译。可以通过下面的SQL来查 select top 25 sql_text.text, sql_handle, plan_generation_num, execution_count, dbid, objectid from sys.dm_exec_query_stats a cross apply sys.dm_exec_sql_text(sql_handle) as sql_text where plan_generation_num >1 order by plan_generation_num desc 3.4 某个系统进程造成的，比如说 Ghost cleanup， Lazy writer等。可以通过select * from sys.sysprocesses where spid<51来查。造成具体的引起高CPU到底是什么引起的，然后对症下药。

我觉得，第二步应该是这样的：查看并行度，并行阀值，然后修改并行度和并行阀值。还有就是锁定多表连接查询的SQL和存储过程，如果执行频繁，有可能是数据库设计有问题或查询逻辑需要改。

我喝多了 2014-08-20

打赏
举报

学习

xxfvba 2014-08-12

打赏
举报

菜鸟学习ing

gem227 2014-08-11

打赏
举报

学习下

wangnaisheng 2014-07-31

打赏
举报

mark一下，学习~

yoan2014 2014-05-17

打赏
举报

这贴挖的不错，各位继续

jason131203 2014-05-16

打赏
举报

好东西啊，学习很多

开着拖拉机泡妞 2013-12-25

打赏
举报

下午跟大家交流一下set statistics io on的结果如何理解以及set statistics profile on输出的结果的一些重要字段的数据是什么含义，说明什么问题。

开着拖拉机泡妞 2013-12-25

打赏
举报

引用 47 楼 mcxhh2005 的回复:

执行计划中Lookup或key Lookup是什么意思？谢谢

RID LOOKP和KEY look up吧？这个是指的"书签查找" 这个可以通过修改索引来优化掉。但不一定什么时候都需要优化掉

杉子木 2013-12-24

打赏
举报

顶一下

专注or全面 2013-12-19

打赏
举报

Optimize for Ad hoc Workloads设为1和强制化参数的区别

专注or全面 2013-12-19

打赏
举报

请教执行计划的生成过程



dbcc freeproccache

select * from table1 where id=1
select * from table1 where id=2

select cacheobjtype,objtype,usecounts,sql from sys.syscacheobjects  where dbid=DB_ID('dbtest1')


cacheobjtype      objtype              usecounts   sql
----------------- -------------------- ----------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Compiled Plan     Adhoc                1           select cacheobjtype,objtype,usecounts,sql from sys.syscacheobjects  where dbid=DB_ID('dbtest1')
Compiled Plan     Adhoc                1           select * from table1 where id=1
Compiled Plan     Adhoc                1           select * from table1 where id=2

(3 行受影响)



--直接拼sql的方式，生成的是Adhoc计划，没问题

--第二次测试，开启强制化参数
--下面三个sql分别执行一次，生成了一个Prepared类型的计划，并且重用了三次，可以理解，
--是强制化参数的结果
--但是这三句sql为什么还有三个Adhoc类型的计划生成，
--所以不太理解sql执行过程中，执行计划的产生过程


select * from table1 where id=1
select * from table1 where id=2
select * from table1 where id=3

select cacheobjtype,objtype,usecounts,sql from sys.syscacheobjects  where dbid=DB_ID('dbtest1')


cacheobjtype      objtype              usecounts   sql
----------------- -------------------- ----------- ----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------
Compiled Plan     Adhoc                4           select cacheobjtype,objtype,usecounts,sql from sys.syscacheobjects  where dbid=DB_ID('dbtest1')
Compiled Plan     Prepared             1           (@0 varchar(8000))select cacheobjtype , objtype , usecounts , sql from sys . syscacheobjects where dbid = DB_ID ( @0 )
Compiled Plan     Adhoc                1           select * from sys.syscacheobjects  where dbid=DB_ID('dbtest1')
Compiled Plan     Adhoc                1           select * from table1 where id=1
Compiled Plan     Prepared             1           (@0 varchar(8000))select * from sys . syscacheobjects where dbid = DB_ID ( @0 )
Compiled Plan     Adhoc                1           select * from table1 where id=2
Compiled Plan     Adhoc                1           select * from table1 where id=3
Compiled Plan     Prepared             3           (@0 int)select * from table1 where id = @0

(8 行受影响)

ChinaITOldMan 2013-12-19

打赏
举报

执行计划中Lookup或key Lookup是什么意思？谢谢

魔者侠心之明星级程序员 2013-12-16

打赏
举报

引用 45 楼 oreoconansisu 的回复:

1.想请教可否由浅入深的讲解如何根据执行计划做优化？ 2.有时查看执行计划时，会显示'建议添加Index...‘，是否每次都要根据提示添加Index呢? 3.怎么根据执行计划中的'嵌套，合并，哈希'连接做优化先谢谢了

都是好问题 1,这个要讲的太多了，可以用2本书来讲了，不过我简单的说一下思路，首先，就像做备份跟还原一样，你不应该考虑如何做一个备份计划，还是应该考虑如何做一个还原计划，然后根据还原计划来建备份计划一样。执行计划跟优化也是一样，你不应该首先考虑那个执行计划到底多不对，需不需要优化，还是应该考虑，你认为查询优化应该生成什么样的计划才是最好的，比如说select * from table1 where id=100, 你觉得这个语句的计划，到底是table scan好还是index seek好，其实在你的心里早有了答案，如果你认为table scan比index seek更优，但是实际生成的计划确是index seek，这个时候你就要去调查，为什么没有生成table scan，你可以强制他们用table scan或者index seek，看看到底那个计划的COST更少，如果跟你想象的不一样，你就要考虑，为什么就这样，比如说你明明认为table scan的COST更少，但是在执行的时候你发现index seek的COST更少，这个时候你就要去调查为什么会这样，是不是statistics有问题？之类的。 2，不一定，最明显的例子就是，比如说你那个查选只会运行一次，那肯定就没有必要加INDEX了，另外，建议添加Index并不是最优的，比如说，Index可以包含包含索引跟非包含索引，很多情况下包含索引的性能比非包含的要好，但是建议添加Index一般不会给你包含索引的提示。 3，这个你要非常的清楚每种的'嵌套，合并，哈希'连接它背后的算法，时间复杂度，空间复杂度，以及它们的一些限制条件。比如说合并它必须要求join的列都是排序的，如果没有排序那SQL 就会执行排序，所以这个时候的注意点就是不是有相关的INDEX建好了，这样可以避免排序带来的消耗。。。。。。