2

我们有一个庞大的、多表的 Sybase 查询，我们称之为get_safari_exploration_data查询，它获取与探险者进行 safari 以及他们遇到的所有动物相关的各种信息。

这个查询很慢，我被要求加快速度。让我大吃一惊的第一件事是，似乎并不迫切需要SELECT外部FROM子句中的嵌套语句。在那个嵌套SELECT的 中，似乎也有几个不需要的字段（vegetable、broomhilda、devoured等）。我也对连接的使用（“ *=”而不是“INNER JOIN...ON”）持怀疑态度。

SELECT
    dog_id,
    cat_metadata,
    rhino_id,
    buffalo_id,
    animal_metadata,
    has_4_Legs,
    is_mammal,
    is_carnivore,
    num_teeth,
    does_hibernate,
    last_spotted_by,
    last_spotted_date,
    purchased_by,
    purchased_date,
    allegator_id,
    cow_id,
    cow_name,
    cow_alias,
    can_be_ridden
FROM
(
    SELECT
        mp.dog_id as dog_id,
        ts.cat_metadata + '-yoyo' as cat_metadata,
        mp.rhino_id as rhino_id,
        mp.buffalo_id as buffalo_id,
        mp.animal_metadata as animal_metadata,
        isnull(mp.has_4_Legs, 0) as has_4_Legs,
        isnull(mp.is_mammal, 0) as is_mammal,
        isnull(mp.is_carnivore, 0) as is_carnivore,
        isnull(mp.num_teeth, 0) as num_teeth,
        isnull(mp.does_hibernate, 0) as does_hibernate,
        jungle_info.explorer as last_spotted_by,
        exploring_journal.spotted_datetime as last_spotted_date,
        jungle_info.explorer as purchased_by,
        early_exploreration_journal.spotted_datetime as purchased_date,
        alleg_id as allegator_id,
        ho.cow_id,
        ho.cow_name,
        ho.cow_alias,
        isnull(mp.is_ridable,0) as can_be_ridden,
        ts.cat_metadata as broomhilda,
        ts.squirrel as vegetable,
        convert (varchar(15), mp.rhino_id) as tms_id,
        0 as devoured
    FROM
        mammal_pickles mp,
        very_tricky_animals vt,
        possibly_venomous pv,
        possibly_carniv_and_tall pct,
        tall_and_skinny ts,
        tall_and_skinny_type ptt,
        exploration_history last_exploration_history,
        master_exploration_journal exploring_journal,
        adventurer jungle_info,
        exploration_history first_exploration_history,
        master_exploration_journal early_exploreration_journal,
        adventurer jungle_info,
        hunting_orders ho
    WHERE
        mp.exploring_strategy_id = 47
        and mp.cow_id = ho.cow_id
        and ho.cow_id IN (20, 30, 50)
        and mp.rhino_id = vt.rhino_id
        and vt.version_id = pv.version_id
        and pv.possibly_carniv_and_tall_id = pct.possibly_carniv_and_tall_id
        and vt.tall_and_skinny_id = ts.tall_and_skinny_id
        and ts.tall_and_skinny_type_id = ptt.tall_and_skinny_type_id
        and mp.alleg_id *= last_exploration_history.exploration_history_id
        and last_exploration_history.master_exploration_journal_id *= exploring_journal.master_exploration_journal_id
        and exploring_journal.person_id *= jungle_info.person_id
        and mp.first_exploration_history_id *= first_exploration_history.exploration_history_id
        and first_exploration_history.master_exploration_journal_id *= early_exploreration_journal.master_exploration_journal_id
        and early_exploreration_journal.person_id *= jungle_info.person_id
) TEMP_TBL

所以我问：

  • 我对嵌套正确SELECT吗？
  • 我对嵌套中不必要的字段是否正确SELECT？
  • 我对连接的结构/语法/用法是否正确？
  • 关于这个查询的结构/性质，还有什么其他让您觉得效率低下/速度慢的地方吗？

不幸的是，除非有无可辩驳的事实证明将这个大查询分解为更小的查询从长远来看是有益的，否则管理层根本不会批准将其重构为多个更小的查询，因为这将花费大量时间来重构和测试。在此先感谢您的任何帮助/见解！

4

3 回答 3

0

我建议采用以下方法。

on首先，使用带有子句的 ANSI 标准连接重写查询。这将使条件和过滤更容易理解。此外，这是“安全的”——您应该得到与当前版本完全相同的结果。小心，因为*=是外连接，所以不是所有东西都是内连接。

我怀疑这一步会提高性能。

然后，检查每个引用表，并确保连接键在引用表中具有索引。如果缺少密钥，请添加它们。

然后，检查是否需要左外连接。左外部联接的表上有过滤器。. . 这些过滤器将外连接转换为内连接。可能不会影响性能，但你永远不知道。

然后，考虑索引用于过滤的字段（在where子句中）。

并且，学习如何使用解释功能。任何嵌套循环连接（没有索引）都可能是性能问题的罪魁祸首。

至于嵌套选择，我认为 Sybase 足够聪明，可以“做正确的事”。即使它写出并重新读取结果集，与正确连接相比，这可能会对查询产生边际影响。

如果这是你真正的数据结构，顺便说一句，这听起来像是一个非常有趣的领域。我很少看到allegator_id表中调用了一个字段。

于 2013-04-25T18:33:47.310 回答
0
  • 我对嵌套 SELECT 是否正确？

在某些情况下，您可能会这样做，但一个称职的计划者会在这里折叠它并忽略它。

  • 我对嵌套 SELECT 中不必要的字段是否正确？

是的，特别是考虑到其中一些根本没有出现在最终的字段列表中。

  • 我对连接的结构/语法/用法是否正确？

据我所知，*=并且=*只是左右连接的语法糖，但我说的可能是错误的。如果不是，那么它们只是强制连接发生的方式，但它们可能是您的查询工作所必需的。

  • 关于这个查询的结构/性质，还有什么其他让您觉得效率低下/速度慢的地方吗？

是的。

首先，您有一些不需要的计算，例如convert (varchar(15), mp.rhino_id) as tms_id. 也许还有一两个连接，但我承认我没有看过查询的血腥细节。

接下来，您可能会遇到数据库设计本身的问题，例如cow_id 字段。（严重地？ ：-） ）

最后，为了避免进行大量的连接，有时会提到执行多个查询而不是单个查询。

例如，在博客中，获取前 10 个帖子通常是个好主意，然后使用单独的查询来获取它们的标签（其中 id 在（id1、id2 等）中）。在您的情况下，选择性部分似乎就在这里：

    mp.exploring_strategy_id = 47
    and mp.cow_id = ho.cow_id
    and ho.cow_id IN (20, 30, 50)

因此，也许可以在一个查询中隔离该部分，然后in ()使用生成的 ID 构建一个子句，并在一个或多个单独的查询中获取装饰性的点点滴滴。

哦，正如 Gordon 所指出的，还要检查你的索引。但是，请注意，如果不将查询拆分为更易于管理的部分，索引可能最终没有什么用处。

于 2013-04-25T18:48:51.090 回答
0

我会回答你的一些问题。

您认为嵌套 SELECT 中的字段（蔬菜、broomhilda、吞噬）可能会导致性能问题。不必要。嵌套 SELECT 中两个未使用的字段（vegetable、broomhilda）来自 ts 表，但正在使用的 cat_metadata 字段也来自 ts 表。因此，除非 cat_metadata 被 ts 表上使用的索引覆盖，否则不会对性能产生任何影响。因为，要提取 cat_metadata 字段，无论如何都需要从表中获取数据页。其他两个字段的提取将占用很少的 CPU，仅此而已。所以不用担心。“吞噬”场也是一个常数。这也不会影响性能。

Dennis 指出了转换函数 convert(varchar(15), mp.rhino_id) 的用法。我不同意这会影响性能，因为它只会消耗 CPU。

最后我想说，尝试使用设置表数为 13，因为那里有 13 个表。Sybase 一次使用四个表进行优化。

于 2013-06-20T08:06:36.107 回答