我读过一些关于Server查询优化的文章。我要指出的一点是,Server在第一次执行时为每个存储过程生成一个查询执行计划。这些执行计划存储在数据库中,并将用于将来执行相同的SPs。
我不明白的部分是: SQL Server如何使用这个“查询执行计划”来优化查询执行?我们能做些什么来优化它生成的查询执行计划吗?
发布于 2016-03-23 17:43:18
如果您是一个程序员,您会注意到SQL看起来不太像普通代码。
普通代码是以一种称为命令式的方式编写的:它告诉计算机该做什么。另一方面,SQL并没有告诉数据库该做什么,而是告诉数据库您想要什么,并由DBMS引擎来决定如何检索它。这就是所谓的声明式代码,它使您的数据库查询更加简单。但实际上它并没有告诉数据库该做什么。
当数据库获得一个SQL查询时,它必须做的第一件事就是弄清楚如何接受一个请求,上面写着“我想要这个数据”,并将它转化为一种以合理有效的方式检索数据的方法。因此,它查看查询和受影响的表,并自行构建一组命令执行命令。这是查询计划。因为构建查询计划需要时间,所以大多数DBMS会在某些情况下缓存它们,当引擎有理由期望您重用相同的查询时。
有一些方法可以检查查询计划,甚至强制它在查询的某些点使用某些命令,但确切的机制在DBMS和另一个DBMS之间往往有很大的不同。有关详细信息,请使用Googling搜索“查询计划调优”,加上数据库引擎的名称;您可能会发现很多信息。
发布于 2016-03-23 19:17:29
梅森·惠勒的回答很好。还有几点要补充:
当数据库引擎第一次执行查询时,它不只是提出一个执行计划。它产生了很多这样的东西。除bug外,所有这些执行计划在逻辑上都是等价的:也就是说,它们都将为查询生成正确的结果。
然而,让他们与众不同的是执行计划所需的时间。简化一下,我要说的是“多少磁盘访问”而不是“有多少时间”。这不是严格意义上说的,但已经很接近了。与每个执行计划相关联的是估计成本。估计成本最低的是被使用的。
现在,您的原始问题可以重新表述,因为dba或程序员可以做什么来使查询优化器找到更好的计划,并选择它吗?答案是yes...but。
首先,索引设计对于执行计划至关重要。通常,正确索引的存在可能会导致查询优化器找到并选择一种速度高达100倍的策略。但你得小心点。添加索引会减缓其他数据库操作的速度,您必须小心不要做更多的坏事。
可以做的第二件事是频繁地分析表。对于不同的DBMS产品,这是不同的,但是分析表通常会存储有关表的数据,从而帮助优化器做出更好的成本估算。
可以做的第三件事是重写查询,使其更符合逻辑和更直观。有时,熟练的程序员会学习如何编写读起来像一种糟糕的命令式语言而不是一种好的声明性语言的SQL。这通常是不信任优化器完成其工作的情况。有时候,人比优化器聪明。更常见的情况是,只需让优化器进行优化就可以获得更好的结果。
可以做的第四件事是在查询中提供Oracle中过去称为“提示”的内容。我不知道其他产品的同义词。我已经有15年没见过这样的事情了,但我想还是有可能的。大约20年前,这几乎是完成任务所必需的。从那以后,世界发生了很大的变化。
它的长短在于,优化器是您的朋友,尽管它并不完美。让优化器帮助您。
发布于 2016-03-23 17:54:07
最简单的方法/一个很好的起点是数据库引擎调优顾问。通常,您将得到适用于特定表的索引建议。
您仍然需要评估和测试这些索引,并权衡可能遇到的一些缺点(例如,插入、更新和删除由于索引重建开销而减慢)。
正确地构造数据也可以大大提高性能。我建议在您的查询中处理更高级的设置之前先这样做。新手可能无法注意到意外的后果,直到为时已晚。
https://softwareengineering.stackexchange.com/questions/313626
复制相似问题