Question

我正在尝试解释困扰我的性能问题......

我有2张桌子，A和B.

表A定义了对象：

{% for x in xxx %} \n
<li>{{x.something|e}}</li> \n
{% endfor %}

此表格中有575行。

表B定义了所述对象的一些属性。

+----+--------------+
+ ID + other_things +
+----+--------------+
+ 1  + ~~~~~~~~~~~~ +
+ 2  + ~~~~~~~~~~~~ +
+ 3  + ~~~~~~~~~~~~ +
+----+--------------+

此表格中有20254行。

目的是获得表A中项目的所有'prop2'值。

这里的一些用户已经非常友好地帮助我建立了“好”的解决方案（参见q.41331902）：

+----+-------------+-------------+
+ ID + prop_type   +  prop_value +
+----+-------------+-------------+
+ 1  +    prop1    +   foo       +
+----+-------------+-------------+
+ 1  +    prop2    +   toto      +
+----+-------------+-------------+
+ 3  +    prop2    +  lorem      +
+----+-------------+-------------+

此查询在大约20秒内执行。

然而，目前使用的是其他版本，我在开始时试图改进：

SELECT A.ID, B.prop_value
FROM A LEFT JOIN
     B
     ON A.ID = B.ID AND B.prop_type = 'prop2';

这给出了相同的结果，但查询在1.5秒内完成......

根据我在网上看到的内容，我的理解是JOIN应该比循环更好，但实际结果却不然......

我试图改变表的顺序（即大连接小），但这只会让事情变得更糟（最多1分钟）。

你能帮我理解这里发生的事吗？

旁注：我无法获得执行计划，因为数据库引擎不允许它（AspenTech的SQLPlus）

非常感谢你的帮助

Answer 1

如果您有此查询：

SELECT A.ID, B.prop_value
FROM A LEFT JOIN
     B
     ON A.ID = B.ID AND B.prop_type = 'prop2';

您希望加快速度，在B上创建索引：

CREATE INDEX idx_b_id_type_value ON B(id, prop_type, prop_value);

这应该会大大提高性能。

如果B的索引prop_type是索引中的第一个键，那么您的双查询版本会更快。我应该补充一点：我没有使用Aspen SQL的经验。另一种可能性是，它只是一个糟糕的优化器。

在循环中加入性能与选择

1 个答案: