MySQL - 计算关系的最有效方法

Question

我在 MySQL 中有两个表。一个带有accounts（4000 万条记录），一个带有transactions（3 亿条记录）。每天增加大约 20 万笔交易。它们具有 1:n 的关系：

+-----------------+
| Accounts        |
+----+------------+
| ID | account_no |
+----+------------+

和

+--------------------------------+
| Transactions                   |
+----+------------+--------+-...-+
| ID | account_no | amount | ... |
+----+------------+--------+-...-+

我需要编写一个 SQL 查询来创建accounts 按交易量排序的列表。于是想到了这样的事情：

SELECT a.account_no , COUNT(a.account_no) tx_count FROM accounts a
INNER JOIN transactions tx ON a.account_no = tx.account_no
GROUP BY tx.account_no ORDER BY tx_count DESC LIMIT 1000;

(Link to SQLfiddle)

我的问题：鉴于我必须处理数以千万计的记录，实现这一目标的最有效的方法是什么？

[注意：字段account_no当然是有索引的]

Answer 1

要获得性能，您必须尽可能减少工作量。

执行COUNT(*) 不符合这个口头禅。

因此，如果您正在寻找有效的方法来获取您想要的号码 - 根本不要使用COUNT(*)。只需在Account 中创建一个包含特定记录计数的整数字段，并使用触发器来处理递增/递减。听起来触发器会导致性能损失 - 它们不会，并且在尝试获取每个帐户的交易计数时整个过程变得微不足道。

您可以索引trx_count 字段，您的查询变为：

SELECT * FROM Accounts ORDER BY trx_count DESC;

表格改动：

ALTER TABLE Accounts add trx_count int unsigned  not null default '0';

在Transactions 上插入触发器后

DELIMITER $$
CREATE

    TRIGGER `Transactions_after_insert` AFTER INSERT ON `Transactions` 
    FOR EACH ROW BEGIN
        UPDATE Accounts SET trx_count = trx_count + 1 WHERE id = new.account_no;
    END;
$$

DELIMITER ;

在Transactions 上删除触发器后

DELIMITER $$
CREATE

    TRIGGER `Transactions_after_delete` AFTER DELETE ON `Transactions` 
    FOR EACH ROW BEGIN
             UPDATE Accounts SET trx_count = trx_count - 1 WHERE id = old.account_no;
    END;
$$

DELIMITER ;

Answer 2

您正在寻求效率。所以坚持一张桌子，跳过JOIN。并且，使用COUNT(*)。它计算原始行数。 COUNT(something_else) 需要在计算 something_else 值之前检查它们是否为 null。 (http://sqlfiddle.com/#!9/cd6bb2/12/0)

 SELECT account_no, 
        COUNT(*) transaction_count
   FROM transactions
  GROUP BY account_no
  ORDER BY COUNT(*) DESC
  LIMIT 1000

恰好MyISAM访问方法可以直接从索引中满足这个查询。 InnoDB 将不得不扫描索引。

如果您的生产报告需要汇总所有帐户而不仅仅是前 1000 个帐户，那么您可以考虑省略 ORDER BY COUNT(*)。这将在 dbms 上节省一些时间。

Percona 的人对查询如何利用索引有很多过人的解释。例如：https://www.percona.com/blog/2012/11/23/full-table-scan-vs-full-index-scan-performance/