Question

我正在尝试查询一些趋势统计信息，但基准测试确实很慢。查询执行时间约为 134秒。

我有一个名为table_1的MySQL表。

在create语句下方

CREATE TABLE `table_1` (
  `id` bigint(11) NOT NULL AUTO_INCREMENT,
  `original_id` bigint(11) DEFAULT NULL,
  `invoice_num` bigint(11) DEFAULT NULL,
  `registration` timestamp NULL DEFAULT NULL,
  `paid_amount` decimal(10,6) DEFAULT NULL,
  `cost_amount` decimal(10,6) DEFAULT NULL,
  `profit_amount` decimal(10,6) DEFAULT NULL,
  `net_amount` decimal(10,6) DEFAULT NULL,
  `customer_id` bigint(11) DEFAULT NULL,
  `recipient_id` text,
  `cashier_name` text,
  `sales_type` text,
  `sales_status` text,
  `sales_location` text,
  `invoice_duration` text,
  `store_id` double DEFAULT NULL,
  `is_cash` int(11) DEFAULT NULL,
  `is_card` int(11) DEFAULT NULL,
  `brandid` int(11) DEFAULT NULL,
  PRIMARY KEY (`id`),
  KEY `idx_registration_compound` (`id`,`registration`)
) ENGINE=InnoDB AUTO_INCREMENT=47420958 DEFAULT CHARSET=latin1;

我已经设置了由id + registration组成的化合物索引。

在查询下方

SELECT 

store_id,
            CONCAT('[',GROUP_CONCAT(tot SEPARATOR ','),']') timeline_transactions,
            SUM(tot) AS total_transactions,
            CONCAT('[',GROUP_CONCAT(totalRevenues SEPARATOR ','),']') timeline_revenues,
            SUM(totalRevenues) AS revenues,
            CONCAT('[',GROUP_CONCAT(totalProfit SEPARATOR ','),']') timeline_profit,
            SUM(totalProfit) AS profit,
            CONCAT('[',GROUP_CONCAT(totalCost SEPARATOR ','),']') timeline_costs,
            SUM(totalCost) AS costs



 FROM (select t1.md,
COALESCE(SUM(t1.amount+t2.revenues), 0) AS totalRevenues,
COALESCE(SUM(t1.amount+t2.profit), 0) AS totalProfit,
COALESCE(SUM(t1.amount+t2.costs), 0) AS totalCost,
COALESCE(SUM(t1.amount+t2.tot), 0) AS tot,
t1.store_id

from
(
 SELECT a.store_id,b.md,b.amount from ( SELECT DISTINCT store_id FROM  table_1) AS a
  CROSS JOIN 
 (
 SELECT
  DATE_FORMAT(a.DATE, "%m") as md,
  '0' as  amount
  from (
    select curdate() - INTERVAL (a.a + (10 * b.a) + (100 * c.a)) month as Date
    from (select 0 as a union all select 1 union all select 2 union all select 3 union all select 4 union all select 5 union all select 6 union all select 7 union all select 8 union all select 9) as a
    cross join (select 0 as a union all select 1 union all select 2 union all select 3 union all select 4 union all select 5 union all select 6 union all select 7 union all select 8 union all select 9) as b
    cross join (select 0 as a union all select 1 union all select 2 union all select 3 union all select 4 union all select 5 union all select 6 union all select 7 union all select 8 union all select 9) as c
  ) a
  where a.Date >='2019-01-01' and a.Date <= '2019-01-14'
  group by md) AS b 
)t1
left join
(
  SELECT
                COUNT(epl.invoice_num) AS tot,
                SUM(paid_amount) AS revenues,
                SUM(profit_amount) AS profit,
                SUM(cost_amount) AS costs,
                store_id,
                date_format(epl.registration, '%m') md
                FROM table_1 epl
                GROUP BY store_id, date_format(epl.registration, '%m')
)t2
ON   t2.md=t1.md AND t2.store_id=t1.store_id
group BY t1.md, t1.store_id) AS t3 GROUP BY store_id  ORDER BY total_transactions desc

说明以下

也许我应该将registration列中的时间戳更改为日期时间？

Answer 1

大约90％的执行时间将用于执行GROUP BY store_id, date_format(epl.registration, '%m')。

不幸的是，您不能使用索引来group by的派生值，并且由于这对于您的报告至关重要，因此您需要预先计算。您可以通过将该值添加到表中来实现此目的，例如使用生成的列：

alter table table_1 add md varchar(2) as (date_format(registration, '%m')) stored

我在这里保留了您在该月份使用的varchar格式，也可以在该月份中使用数字（例如tinyint）。

这需要MySQL 5.7，否则您可以使用触发器来实现同一目的：

alter table table_1 add md varchar(2) null;
create trigger tri_table_1 before insert on table_1
for each row set new.md = date_format(new.registration,'%m');
create trigger tru_table_1 before update on table_1
for each row set new.md = date_format(new.registration,'%m');

然后添加一个索引，最好是覆盖索引，以store_id和md开头，例如

create index idx_table_1_storeid_md on table_1 
   (store_id, md, invoice_num, paid_amount, profit_amount, cost_amount)

如果您还有其他类似的报告，则可能要检查它们是否使用其他列，并可以从覆盖更多列中受益。该索引将需要约1.5GB的存储空间（而驱动器读取1.5GB所需的时间基本上将由一手来定义您的执行时间，而无需缓存）。

然后将您的查询更改为按此新的索引列分组，例如

      ...
            SUM(cost_amount) AS costs,
            store_id,
            md -- instead of date_format(epl.registration, '%m') md
            FROM table_1 epl
            GROUP BY store_id, md -- instead of date_format(epl.registration, '%m')
)t2   ...

此索引还将处理您执行时间的另外9％SELECT DISTINCT store_id FROM table_1，这将从store_id开始的索引中受益。

现在，您的查询中的99％已得到处理，进一步说明：

子查询b和日期范围where a.Date >='2019-01-01' and a.Date <= '2019-01-14'可能无法达到您的预期。您应该run the part SELECT DATE_FORMAT(a.DATE, "%m") as md, ... group by md单独查看它的作用。在当前状态下，它将为您提供与元组'01', 0对应的一行，表示“一月”，因此从根本上讲，这是一种复杂的select '01', 0处理方式。除非今天是15日或之后，否则它将不返回任何内容（这可能是意外的）。
特别是，它不会不将发票日期限制在该特定范围内，但仅限于任何年份（整个）一月的所有发票。如果您打算这样做，则应该（另外）直接添加该过滤器，例如通过使用FROM table_1 epl where epl.md = '01' GROUP BY ...，将执行时间减少大约12倍。因此（除了第15个问题和上升问题），如果使用当前范围，则应该获得相同的结果
```
  ...
        SUM(cost_amount) AS costs,
        store_id,
        md 
        FROM table_1 epl
        WHERE md = '01'
        GROUP BY store_id, md 
)t2   ...
```
对于不同的日期范围，您必须调整该字词。为了强调我的观点，这与按日期过滤发票（例如，按日期
```
  ...
        SUM(cost_amount) AS costs,
        store_id,
        md 
        FROM table_1 epl
        WHERE epl.registration >='2019-01-01' 
           and epl.registration <= '2019-01-14'
        GROUP BY store_id, md 
)t2   ...
```
您可能（或可能没有）尝试做的。在这种情况下，您将需要一个不同的索引（这将是一个稍微不同的问题）。
在其余的查询中可能还有一些其他的优化，简化或美化的功能，例如group BY t1.md, t1.store_id看起来多余和/或错误（表明您实际上不在MySQL 5.7上），而{{ 1}}-subquery只能为您提供1到12的值，因此可以简化生成1000个日期并再次减少它们的日期。但是，由于它们在100多个行上进行操作，因此它们不会显着影响执行时间，我也没有详细检查它们。其中一些可能是由于获得了正确的输出格式或归纳（尽管，如果按月以外的其他格式动态分组，则需要其他索引/列，但这将是另一个问题）。

另一种预先计算值的方法是汇总表，例如每天运行一次内部查询（昂贵的b），然后将结果存储在表中，然后再使用（通过从该表中选择而不是分组依据）。这对于永不更改的数据（如发票）特别可行（尽管否则，您可以使用触发器使汇总表保持最新状态）。如果您有多种情况（例如，如果您的用户可以决定按工作日，年，月或生肖分组，否则您将需要为每个索引添加索引。如果您需要动态限制发票范围（例如2019-01-01 ... 2019-01-14），它将变得不太可行。如果您需要在报表中包括当前日期，您仍然可以预先计算，然后从表中添加当前日期的值（该表只包含非常有限的行数，如果索引开头为您的日期列），或使用触发器即时更新汇总表。

Answer 2

使用PRIMARY KEY(id)，拥有INDEX(id, anything)实际上是没有用的。
查看是否可以避免嵌套子查询。
请考虑永久建立该“日期”表并在其上放置PRIMARY KEY(md)。当前，两个子查询的联接列（md）上都没有索引。
您可能患有“爆炸内爆”综合症。这是JOINs扩展行数的地方，只是使GROUP BY折叠行。
不要使用COUNT(xx)，除非您需要检查xx是否为NULL。只需执行COUNT(*)。
store_id double-真的吗？
TIMESTAMP与DATETIME –它们的表现大致相同；不用麻烦更改它。
由于您仅查看2019-01，因此摆脱
```
date_format(epl.registration, '%m')
```
仅此一项，可能会加快很多速度。（但是，您失去了普遍性。）

MySQL查询太慢

在create语句下方

在查询下方

说明以下

2 个答案: