MySql 查询超慢

Posted 2023-03-24

【中文标题】MySql 查询超慢

【英文标题】：MySql Query Super Slow

【发布时间】：2012-11-19 17:05:02

【问题描述】：

我有以下查询非常慢（仅需要 4-5 秒才能得到结果。我想知道是否有人可以看到我可以用这个查询做不同的事情来加快它的速度？

谢谢！

SELECT
accounts.id AS account_id,
accounts. NAME AS account_name,
accounts.assigned_user_id account_id_owner,
users.user_name AS assigned_user_name,
opportunities_cstm.firstname_c, opportunities_cstm.lastname_c,
opportunities.`name`, TRIM(
    Concat(
        Ifnull(
            opportunities_cstm.firstname_c,
            ''
        ),
        ' ',
        Ifnull(
            opportunities_cstm.lastname_c,
            ''
        )
    )
) AS 'cfull' FROM
opportunities 
LEFT JOIN users ON opportunities.assigned_user_id = users.id 
LEFT JOIN accounts_opportunities ON opportunities.id = accounts_opportunities.opportunity_id 
LEFT JOIN accounts ON accounts_opportunities.account_id = accounts.id
LEFT JOIN opportunities_cstm ON opportunities.id = opportunities_cstm.id_c
WHERE
(
    (
        opportunities.sales_stage IN (
            'Prospecting',
            'Appointment Set',
            'MeetAndGreet',
            'Qualification',
            'Needs Analysis',
            'Locating Vehicle',
            'Demo',
            'Trade Evaluation',
            'Negotiation',
            'Manager T/O',
            'Write Up',
            'Credit App Submitted',
            'Pending Finance',
            'Loan Approval',
            'Deposit',
            'Delayed Decision',
            'Sold-Vehicle Ordered',
            'Sold-Pending Finance',
            'Sold/Pending Delivery',
            'Price Quoted',
            'Service Pending'
        )
    )
)
AND (
accounts_opportunities.deleted IS NULL
OR accounts_opportunities.deleted = 0
)
AND (
accounts.deleted IS NULL
OR accounts.deleted = 0
)
AND opportunities.deleted = 0
ORDER BY
opportunities.date_entered DESC,
opportunities.id DESC
LIMIT 0,21

这是来自同一查询的解释：

╔═════════════╦════════════════════════╦════════╦═ ═════════════════════════╦═════════════════════╦══ ═══════╦══════════════════════════════════════════ ══╦═══════╦═════════════════════════════╗ ║ select_type ║ table ║ type ║ possible_keys ║ key ║ key_len ║ ref ║ rows ║ extra ║ ╠═════════════╬════════════════════════╬════════╬═ ═════════════════════════╬═════════════════════╬══ ═══════╬══════════════════════════════════════════ ══╬═══════╬══════════════════════════════ ║简单║机会║范围║sales_stage，idx_deleted║sales_stage║78║null║25161║使用where；使用文件排序║ ║ 简单 ║ 用户 ║ eq_ref ║ PRIMARY, idx_id_deleted ║ PRIMARY ║ 108 ║ version4.opportunities.assigned_user_id ║ 1 ║ ║ ║ simple ║ accounts_opportunities ║ ref ║ idx_oppid_del_accid ║ idx_oppid_del_accid ║ 111 ║ version4.opportunities.id ║ 1 ║ 使用 where；使用索引║ ║ 简单 ║ 账户 ║ eq_ref ║ PRIMARY,idx_accnt_id_del ║ PRIMARY ║ 108 ║ version4.accounts_opportunities.account_id ║ 1 ║ 使用where ║ ║ 简单 ║ 机会_cstm ║ eq_ref ║ PRIMARY ║ PRIMARY ║ 108 ║ version4.opportunities.id ║ 1 ║ ║ ╚═════════════╩════════════════════════╩════════╩═ ═════════════════════════╩═════════════════════╩══ ═══════╩══════════════════════════════════════════ ══╩═══════╩═════════════════════════════╝

【问题讨论】：

Using filesort 是最糟糕的。

是的，如果你看到Using filesort，你基本上就死定了，尤其是有大量受影响的行。您将不得不考虑在 ORDER 列上合并索引的方法。

你已经设置了哪些索引？

这是我在机会表上的索引。为了避免使用文件排序，可以做些什么不同的事情？我们有大量内存并且它没有被最大化，所以我知道它没有诉诸基于文件的表格等。这是我拍摄的索引屏幕截图的链接：d.pr/i/7oEz

Using filesort 并不意味着它会进入磁盘；这意味着有必要对派生的结果集进行排序。当您像您一样在大胖连接上使用ORDER BY ... LIMIT 时，通常会出现这种情况。

【参考方案1】：

我看到了两个问题。

首先，您使用了两个不同的WHERE (... IS NULL OR ... = 0) 标准。那些慢得无法形容。这是因为索引对于查找 NULL 值没有用。如果您可以摆脱那些deleted 列中的NULL 可能性，也许通过声明它们NOT NULL DEFAULT 0 您可以将这些标准更改为WHERE ... = 0。这应该加快很多事情。这是因为索引对于查找 NULL 值没有用处。

其次，您正在创建一个很棒的大型联合结果集，然后对其进行排序以查找最新的项目。

您可以尝试在加入之前从“机会”表中预先选择项目。做这样的事情：

SELECT   whatever....
FROM (
         SELECT * 
           FROM opportunities
          WHERE opportunities.deleted = 0
            AND opportunities.sales_stage IN (
            'Prospecting',
            'Appointment Set',  etc etc  ...
            'Service Pending' )
       ORDER BY opportunities.date_entered DESC,
                opportunities.id DESC
          LIMIT 0,21
      ) opportunities 
LEFT JOIN users ON opportunities.assigned_user_id = users.id
...
ORDER BY
opportunities.date_entered DESC,
opportunities.id DESC
LIMIT 0,21

这很可能可以通过从联接的右侧删除一堆记录来减少 LEFT JOIN 操作的基数来加快速度。

【讨论】：

我还要补充一点，date_entered、deleted 和 sales_stage 上的多列索引（按此顺序）可能也会有所帮助。我真的希望 mysql 能够实现降序排序的索引。

奥利 - 感谢您的反馈。我刚刚尝试了您在上面提供的查询。但是，我收到一条错误消息。这是我收到的错误：

我没有机会调试我的查询，很抱歉。 （我没有你的数据。）

【参考方案2】：

我不确定它是否会有所改进，但我会尝试这样做：

SELECT your_fields
FROM
  (SELECT * --or just the fields you need
   FROM
     opportunities
   WHERE
     opportunities.deleted = 0 AND
     opportunities.sales_stage IN (stage1, stage2, ...)
  ) opportunities1
  LEFT JOIN users ON opportunities1.assigned_user_id = users.id 
  LEFT JOIN accounts_opportunities ON opportunities1.id = ...etc...
WHERE
  (accounts_opportunities.deleted IS NULL
   OR accounts_opportunities.deleted = 0)
  AND (accounts.deleted IS NULL OR accounts.deleted = 0)
ORDER BY ...etc...

如果它有任何改进，请告诉我（但也可能会更慢）。另一个想法是使用包含您需要过滤的所有阶段的表格：

CREATE TABLE filter_stage (
  stage varchar(255));

（255或尽量匹配sales_stage的实际长度，最好也索引此列）在此处输入所有要过滤的字符串：

INSERT INTO filter_stage VALUES ('Prospecting'), ('Appointment Set'), ('...'), ...

然后你从你的第一个查询中删除你的 IN 子句，然后你的 FROM 变成：

FROM
  opportunities INNER JOIN filter_stage
  ON opportunities.sales_stage = filter_stage.stage
  LEFT JOIN ...

让我知道它是否有效！

【讨论】：

fthiella - 我试过你的例子，但它让它变长了。这次大约 6-7 秒。

@swhitlow 有时它可以工作，但它可能会使其变慢......您是否也尝试使用 filter_stage 表？但如果没有实际数据，我无法向您提供其他建议...我建议您尝试使用不同的子查询组合，或尝试使用括号对连接表进行分组...

【参考方案3】：

不要使用 IN。 IN 在 mysql 中运行缓慢，使用 Exists

DROP TABLE IF EXISTS tempTable;
CREATE TEMPORARY TABLE tempTable ( sales_stage VARCHAR(50) NOT NULL );
insert into tempTable () values ('Prospecting'),('Appointment Set'),('MeetAndGreet'),...,('Service Pending');

SELECT
...
WHERE EXISTS(select sales_stage from tempTable where opportunities.sales_stage = sales_stage);

【讨论】：

Boris - 我不确定我将如何使用存在于字段中。你能解释一下吗？

您能解释一下“IN 在 mysql 中运行缓慢”吗？如果 IN 是子查询，我会同意...但在这种情况下我必须不同意，因为他使用的是文字值列表。

请看这里jortk.nl/2008/07/exists-much-faster-then-in-in-mysql和这里dev.mysql.com/doc/refman/5.0/en/…