Question

我有一个简单的问题，或者至少问题的症状很简单。以下查询在没有GROUP BY（0.15秒）的情况下闪电般快速，但在GROUP BY（超过100秒）时速度超慢。有没有办法改善这种情况？

  SELECT a.id, SUM(t.amount)
    FROM account_transaction t
    JOIN transaction_code tc ON t.transaction_code_id = tc.id
    JOIN account a ON t.account_number = a.account_number
    JOIN account_northway_product anp ON anp.account_id = a.id
    JOIN northway_product np ON np.id = anp.northway_product_id
   WHERE 1
     AND np.code != 'O1'
     AND tc.code IN (0, 20, 40)
GROUP BY a.id

修改：当我在查询的EXPLAIN版本上执行GROUP BY时，除了一行外，一切看起来都不错：

select_type: simple
table: tc
type: index
possible_keys: PRIMARY,code,code_2
key: code
key_len: 257
ref: NULL
rows: 30
Extra: Using where; Using index; Using temporary; Using filesort

从我对EXPLAIN的了解很少，key_len很糟糕，因为它很长。 “使用临时;使用filesort;”也不好。我想，我能做的一件事是缩短transaction_code.code的长度，因为我可能不需要超过3个字符。我不知道如何处理“使用临时;使用文件”;虽然。

Answer 1

可能（？）查询计划程序可能会将其取出，但看起来您的查询中不需要表。还重新安排了连接，因此首先列出了帐户。

SELECT a.id,
       SUM(t.amount)
  FROM 
    account a
        INNER JOIN account_northway_product anp ON anp.account_id = a.id 
            INNER JOIN northway_product np ON np.id = anp.northway_product_id
        INNER JOIN account_transaction t ON t.account_number = a.account_number         
            INNER JOIN transaction_code tc ON t.transaction_code_id = tc.id
 WHERE 
   np.code != 'O1'
   AND tc.code IN (0, 20, 40)
 GROUP BY a.id

Answer 2

在很大程度上取决于您的数据库设置

我建议对该查询进行EXPLAIN并分析输出

你可以一步一步地删除所有表现得足够快的联接，并集中精力处理那些不那样的东西 - 更容易看出必须以哪种方式编入索引

目标是在每次连接时扫描的行数少于10000行

编辑：关于你的解释结果 - 什么是tc.code列的类型？你在条件中使用了整数：

AND tc.code IN (0, 20, 40)

如果tc.code是varchar，那么索引用法就搞乱了

有没有办法改善GROUP BY的性能呢？

2 个答案: