标签: sql-execution-plan

我知道我可以通过使用FORCE INDEX (abc)关键字来改变MySQL执行查询的方式.但有没有办法改变执行顺序？

我的查询如下所示:

SELECT c.*
FROM table1 a
INNER JOIN table2 b ON a.id = b.table1_id
INNER JOIN table3 c ON b.itemid = c.itemid
WHERE a.itemtype = 1
  AND a.busy = 1
  AND b.something = 0
  AND b.acolumn = 2
  AND c.itemid = 123456

我有一个关键用于我使用的每个关系/约束.如果我在这个语句上运行解释,我看到mysql首先开始查询c.

id    select_type    table    type
1     SIMPLE         c        ref
2     SIMPLE         b        ref
3     SIMPLE         a        eq_ref

但是,我知道在命令中查询 a -> b -> c会更快(我已经证明了)有没有办法告诉mysql使用特定的顺序？

更新:我知道这a -> b -> c更快.

上面的查询需要1.9秒才能完成并返回7行.如果我将查询更改为

SELECT …

我有一个查询无法执行"无法为数据库'TEMPDB'分配新页面,因为文件组'DEFAULT'中的磁盘空间不足".

在解决问题的方式我正在检查执行计划.有两个标记为"聚集索引扫描(聚集)"的昂贵步骤.我很难找出这意味着什么？

我将不胜感激"Clustered Index Scan(Clustered)"的任何解释或有关在何处查找相关文档的建议？

我在SQL Server中运行一个相当复杂的查询,运行视图,格式如下:

SELECT *
   FROM myview, foo, bar 
   WHERE shared=1 AND [joins and other stuff]
   ORDER BY sortcode;

如上所示的查询计划显示了Sort在决赛之前的操作SELECT,这正是我所期望的.只有35个匹配的记录,查询在2秒内完成.

但是,如果我添加TOP 30,查询需要将近3分钟!使用SET ROWCOUNT同样慢.

查看查询计划,它现在似乎在连接和过滤器myview 之前对所有200多万条记录进行排序.

这个"排序"在查询计划中显示为索引上的sortcode索引扫描,主表上的聚簇索引查找以及它们之间的嵌套循环,所有这些都在连接和过滤器之前.

如何SORT 在之前 强制SQL Server TOP,就像TOP未指定时一样？

我不认为构造myview是问题,但为了以防万一,它是这样的:

CREATE VIEW myview AS
   SELECT columns..., sortcode, 0 as shared FROM mytable
   UNION ALL
   SELECT columns..., sortcode, 1 as shared FROM [anotherdb].dbo.mytable

本地mytable有几千条记录,而mytable在同一MSSQL实例的另一个数据库中有几百条记录.两个表都在各自的sortcode列上 …

有下一个分区表:

CREATE TABLE "ERMB_LOG_TEST_BF"."OUT_SMS"(
    "TRX_ID" NUMBER(19,0) NOT NULL ENABLE,
    "CREATE_TS" TIMESTAMP (3) DEFAULT systimestamp NOT NULL ENABLE,
    /* other fields... */
) PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
  STORAGE(BUFFER_POOL DEFAULT FLASH_CACHE DEFAULT CELL_FLASH_CACHE DEFAULT)
  TABLESPACE "ERMB_LOG_TEST_BF"
  PARTITION BY RANGE ("TRX_ID") INTERVAL (281474976710656)
  (PARTITION "SYS_P1358"  VALUES LESS THAN (59109745109237760) SEGMENT CREATION IMMEDIATE
  PCTFREE 10 PCTUSED 40 INITRANS 1 MAXTRANS 255
  NOCOMPRESS LOGGING
  STORAGE(INITIAL 8388608 NEXT 1048576 MINEXTENTS 1 MAXEXTENTS 2147483645
  PCTINCREASE 0 FREELISTS 1 FREELIST GROUPS 1
  BUFFER_POOL DEFAULT …

我的一个存储过程执行时间过长.看一下查询执行计划,我能够找到操作耗时太长时间.它是一个嵌套的循环物理运算符,具有外部表(65991行)和内部表(19223行).在嵌套循环上,它显示估计行= ​​1,268,544,993(乘以65991乘19223),如下所示:

我阅读了一些关于用于连接的物理运算符的文章,并且对于这种情况是否嵌套循环或散列匹配更好一点感到困惑.从我可以收集到的:

散列匹配 - 当没有有用的索引可用时,优化器使用散列匹配,一个表明显小于另一个表,表不在连接列上排序.散列匹配也可能表示可以使用更有效的连接方法(嵌套循环或合并连接).

问题:在这种情况下,哈希匹配会比嵌套循环更好吗？

谢谢

我知道怎么回事

1. 嵌套加入
2. 合并加入
3. 哈希加入

工作及其功能.

我想知道在Postgres中使用这些连接的情况

今天我花了一个多小时在一个我无法理解的查询计划上迷惑自己.查询是一个UPDATE,它根本就不会运行.完全陷入僵局:pg_locks表明它也没有等待任何事情.现在,我不认为自己是最好或最差的查询计划读者,但我发现这个非常困难.我想知道怎么读这些？为了找出错误,是否有Pg aces遵循的方法？

我打算再问一个关于如何解决这个问题的问题,但是现在我正在具体谈到如何阅读这些类型的计划.

                                         QUERY PLAN                                         
--------------------------------------------------------------------------------------------
 Nested Loop Anti Join  (cost=47680.88..169413.12 rows=1 width=77)
   Join Filter: ((co.fkey_style = v.chrome_styleid) AND (co.name = o.name))
   ->  Nested Loop  (cost=5301.58..31738.10 rows=1 width=81)
         ->  Hash Join  (cost=5301.58..29722.32 rows=229 width=40)
               Hash Cond: ((io.lot_id = iv.lot_id) AND ((io.vin)::text = (iv.vin)::text))
               ->  Seq Scan on options io  (cost=0.00..20223.32 rows=23004 width=36)
                     Filter: (name IS NULL)
               ->  Hash  (cost=4547.33..4547.33 rows=36150 width=24)
                     ->  Seq Scan on vehicles iv  (cost=0.00..4547.33 rows=36150 width=24)
                           Filter: (date_sold …

我发现EXPLAIN SELECT查询在MySQL中非常有用,因为它提供了有关如何执行SQL的信息,并提供了分析的机会,例如,您应该添加的缺失索引,以便在执行查询本身和分析统计数据之前改进响应.

我的问题是:在像MS Sql,Firebird,Ingres这样的数据库中,是否有类似的命令？

在Firebird中我们有PLAN,但是非常弱,因为很多时候为了查看一个简单的错误,必须运行很长的查询.

最好的祝福,

Mauro H. Leggieri

我有一个包含2个计算列的表,两个都将"Is Persisted"设置为true.但是,在查询中使用它们时,执行计划会显示用于计算列的UDF作为计划的一部分.由于列数据是由UDF在添加/更新行时计算的,为什么计划会包含它？

当这些列包含在查询中时,查询速度非常慢(> 30s),当排除它们时,查询速度非常快(<1s).这使我得出结论,查询实际上是在运行时计算列值,这不应该是这种情况,因为它们被设置为持久化.

我在这里错过了什么吗？

更新:这里有关于我们使用计算列的推理的更多信息.

我们是一家体育公司,有一个客户将完整的球员名称存储在一个列中.他们要求我们允许他们分别按名字和/或姓氏搜索玩家数据.值得庆幸的是,他们使用一致的播放器名称格式 - LastName,FirstName(NickName) - 因此解析它们相对容易.我创建了一个UDF,调用CLR函数来使用正则表达式解析名称部分.因此,显然调用UDF(后者又调用CLR函数)非常昂贵.但由于它仅用于持久列,我认为它只会在我们将数据导入数据库的一天中使用几次.

有没有人知道可用于比较(相对复杂)查询计划的工具？我不是在寻找查询计划的指南,而只是一个工具,使我能够快速查看例如不同的索引使用.

编辑:只是为了说清楚,我不是在寻找有关该计划的信息,而是一个可以快速指出两个计划之间差异的工具(我知道,我可以自己做,但是计划的大小(s) )使那困难).