mysql - 使用继承会提高类似查询的速度和可维护性吗？

Question

这是我的情况:

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

我的问题是:

应用继承来优化查询是否可能/有益？我可以有一个 View ，它是对我的 4 个主要查询所依赖的 2-3 个公共(public)表的查询，然后有 4 个较小的查询，仅应用其独特的额外表和条件？

优点:

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

缺点:

1. 现在我不再运行 4 个查询，而是运行 8 个查询查询(因为每次运行调用 View /存储的查询时您也必须运行该过程)
2. 使用该 View 可能会导致我为每个数据提取大量额外数据查询

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

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';

Answer 1

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

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

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