【问题标题】:Would using inheritance improve speed and maintainability of similar queries?使用继承会提高类似查询的速度和可维护性吗?
【发布时间】:2015-07-19 17:49:53
【问题描述】:

这是我的情况:

  1. 我在显示异步数据的 php 仪表板上运行了 4 个查询。
  2. 所有 4 个查询同时触发,并在整个过程中按需触发 天。
  3. 每个查询连接大约 3-5 个表(应用唯一的 where 条件取决于查询)。
  4. 所有 4 个查询共享 2 或 3 个相同的表...因此有很多 4 个查询之间的重复代码。
  5. 每个表最多可以有6列,数亿行, 以及多达 5gig 的数据总量
  6. 如果不依赖缓存,查询应在 30 秒内返回, 以及几秒钟或更短的时间,他们可以使用缓存

我的问题是:

应用继承来优化查询是否可能/有益?我可以有一个视图,它是对所有 4 个主要查询所依赖的 2-3 个公用表的查询,然后有 4 个较小的查询,它们只应用它们独特的额外表和条件?

优点:

  1. 以后维护查询会更容易,因为我 可以只更新一个视图而不是重复进行更改 在所有 4 个查询中
  2. 它可能会更快,因为一个存储过程/视图最终会被 大部分时间缓存

缺点:

  1. 现在我将运行 8 个查询,而不是运行 4 个查询 查询(因为每次运行调用视图/存储的查询时 程序,您也必须运行该程序)
  2. 使用视图可能会导致我为每个 查询

以下是两个类似查询的示例:

SELECT
    SUM(visitor_cart_items.quantity * (TRIM(REPLACE(visitor_cart_items.price, '$', '')) + 0.0)) 
FROM
    (SELECT DISTINCT
           visitor_cart_items.id,
           visitor_cart_items.price,
           visitor_cart_items.quantity
    FROM
        messages_sent
        JOIN session_guid ON session_guid.visitor_forms_id = messages_sent.visitor_forms_id
        JOIN session_guid sessions ON sessions.session_guid = session_guid.session_guid
        JOIN visitor_cart_items ON visitor_cart_items.cart_id = sessions.visitor_forms_id

    WHERE
        sessions.status_type_id = 1
        AND sessions.website_id = 7
        AND messages_sent.status_id = 1
        AND sessions.updated_timestamp BETWEEN '2015-05-01' AND '2015-05-08') visitor_cart_items;

SELECT 
    COUNT(DISTINCT sessions.visitor_forms_id) all_saves
FROM
    messages_sent
    JOIN session_guid ON session_guid.visitor_forms_id = messages_sent.visitor_forms_id
    JOIN session_guid sessions ON sessions.session_guid = session_guid.session_guid
    JOIN visitor_forms ON visitor_forms.id = sessions.visitor_forms_id
WHERE
    sessions.status_type_id = 1
    AND sessions.website_id = 7
    AND visitor_forms.form_type_id = 1 #1 for forms, 2 for carts
    AND sessions.updated_timestamp BETWEEN '2015-05-01' AND '2015-05-08';

【问题讨论】:

  • 我想我记得读过 MySQL 在查询中使用 VIEW 时可能有点聪明,所以它不一定会执行 8 个查询(也不会总是缓存 VIEW 数据,特别是如果它很大)。但是,视图确实使事情复杂化,并且它们在这种情况下的用处和/或缺点可能会因使用的上下文而有很大差异。
  • 另外,我认为这不会让事情变得更容易,因为每当您想更改 VIEW 时都需要考虑这种交互。

标签: mysql sql inheritance mysql-workbench dashboard


【解决方案1】:

我的经验是,尝试在数据库级别应用继承/OO 风格思维是一件非常糟糕的事情。

一般来说,更简单的视图往往没问题...不同 DBMS 上的查询优化器擅长“精简”视图并为您提供良好的性能。

但是,当您变得更加复杂并开始使用具有聚合函数、用户定义函数和其他勘误表的视图来实现代码重用时,通常会付出巨大的 I/O 和查询计划费用。我们沿着那条路走下去,不得不撕掉那些东西并撤退。在我看来,这不值得。与可怕的查询计划相比,代码重复是一个更好的问题。

【讨论】:

    猜你喜欢
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 2020-02-07
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    • 1970-01-01
    相关资源
    最近更新 更多