慢查询日志记录在测试期间快速的查询

Slow query log logs queries that are fast during testing

我的慢速查询日志充满了具有以下查询时间和检查行的查询:

# Query_time: 26.370100  Lock_time: 0.000213  Rows_sent: 0  Rows_examined: 30976475

如果我将日志中的确切查询复制并粘贴到 phpmyadmin 中 运行,结果会立即出现,即使对该查询尝试 EXPLAIN 也没有发现索引缺陷或结构错误。

据我所知,出于某种原因,一小部分查询无法使用索引,并且在测试期间尝试重现该事件几乎是不可能的。

我应该如何防止这些在绝大多数情况下都按预期工作的偶尔的缓慢查询?

--- 编辑 #1 ---

我创建的表是:

CREATE TABLE msgs (
  id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  sender text NOT NULL,
  receiver text NOT NULL,
  cont blob NOT NULL,
  img text NOT NULL,
  orient text NOT NULL,
  d_t datetime NOT NULL,
  convo text NOT NULL,
  u_code text NOT NULL,
  viewed datetime NOT NULL,
  stat int(11) NOT NULL,
  device text NOT NULL,
  addr text NOT NULL,
  PRIMARY KEY (id),
  KEY msg_u_code (`u_code`(24)),
  KEY receiver (`receiver`(24)),
  KEY sender (`sender`(24)),
  KEY img (`img`(28)),
  KEY convo (`convo`(49))
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

CREATE TABLE usrs (
  id bigint(20) unsigned NOT NULL AUTO_INCREMENT,
  usr_name text NOT NULL,
  img text NOT NULL,
  orient text NOT NULL,
  `password` text NOT NULL,
  u_code text NOT NULL,
  d_t datetime NOT NULL,
  stat int(11) NOT NULL,
  device text NOT NULL,
  addr text NOT NULL,
  PRIMARY KEY (id),
  KEY img (`img`(28)),
  KEY usr_code (`u_code`(24))
) ENGINE=InnoDB  DEFAULT CHARSET=utf8;

我的慢查询日志条目是:

 # Time: 171115  6:26:37
 # User@Host: xxx[xxx] @ localhost []
 # Thread_id: 25524888  Schema: xxx  QC_hit: No
 # Query_time: 32.423430  Lock_time: 0.000425  Rows_sent: 1  Rows_examined: 30998008
 # Rows_affected: 0
 use xxx;
 SET timestamp=1510723597;
 select msg_cont, msg_u_code, msg_d_t, msg_viewed, usr_u_code, usr_name from
        (select
            msgs.id as msg_id,
            msgs.cont as msg_cont,
            msgs.u_code as msg_u_code,
            msgs.d_t as msg_d_t,
            msgs.viewed as msg_viewed,
            usrs.u_code as usr_u_code,
            usrs.usr_name as usr_name
            from msgs
            left join usrs on msgs.sender = usrs.u_code
    where  msgs.convo = 'aaaaaaaaaabfbaghdgcigfid_aaaaaaaaaabeiaccjfhjfach'
      and  (msgs.sender = 'aaaaaaaaaabfbaghdgcigfid'
              or  msgs.receiver = 'aaaaaaaaaabfbaghdgcigfid'
           )
      and  msgs.stat = '1'
      and  usrs.stat = '1'
      and  usrs.u_code not in('aaaaaaaaaabfaagfbgggiejh',
                              'aaaaaaaaaabfabgbjdfjigbd',
                ...... !!!!![here go 400 more usr_u_codes]!!!!!
                          )
      and  msgs.id > 30997997
        ) a order by msg_id asc;

注意,此查询应包含平均 400 个元素 而不是 函数。

--- 编辑 #2 ---

您可能打开了 "Query cache"。它捕获查询及其结果集。当您再次 运行 完全 相同的查询时,它只是回显保存的结果集,而不是重新评估它。

可以通过在语句中添加一个 space 或说 SELECT SQL_NO_CACHE ....

来避免 QC

为了进一步讨论为什么查询需要查看 31M 行,让我们看一下查询和 SHOW CREATE TABLE

搜索查询后

我想首先关注 ON msgs.sender = usrs.u_code 和 "prefix" 索引。

根据示例值,似乎 senderu_code 和其他几个列可能总是在一些小长度下?如果这是真的,那么

  • TEXT 更改为 VARCHAR(nn),其中 nn 是一些现实的限制;
  • 去除前缀(例如:KEY sender (sender(24)) --> KEY (sender).

这些更改应该会使 JOIN 更加高效,从而提高性能。如果这还不够,请回来寻求更多建议。

虽然我无法解释为什么 MySQL 偶尔决定不在非常明显和非常常见的查询上使用索引,但解决方案是简单地强制使用索引。

在我的特殊情况下:

select msg_cont, msg_u_code, msg_d_t, msg_viewed, usr_u_code, usr_name from
        (select
            msgs.id as msg_id,
            msgs.cont as msg_cont,
            msgs.u_code as msg_u_code,
            msgs.d_t as msg_d_t,
            msgs.viewed as msg_viewed,
            usrs.u_code as usr_u_code,
            usrs.usr_name as usr_name
            from msgs FORCE INDEX (convo)
            left join usrs FORCE INDEX (u_code) on msgs.sender = usrs.u_code
    where  msgs.convo = 'aaaaaaaaaabfbaghdgcigfid_aaaaaaaaaabeiaccjfhjfach'
      and  (msgs.sender = 'aaaaaaaaaabfbaghdgcigfid'
              or  msgs.receiver = 'aaaaaaaaaabfbaghdgcigfid'
           )
      and  msgs.stat = '1'
      and  usrs.stat = '1'
      and  usrs.u_code not in('aaaaaaaaaabfaagfbgggiejh',
                              'aaaaaaaaaabfabgbjdfjigbd',
                ...... !!!!![here go 400 more usr_u_codes]!!!!!
                          )
      and  msgs.id > 30997997
        ) a order by msg_id asc;

慢速查询日志证明此解决方案是有效的,因为没有出现新的慢速条目。