緩慢的查詢日志記錄了在測試期間快速的查詢

Question

我的慢速查詢日志中充滿了以下查詢時間和已檢查行的查詢：

# 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;

注意，該查詢平均應在not in函數中包含400個元素。

-編輯2-

Answer 1

您可能已打開“查詢緩存”。 它捕獲查詢及其結果集。 當您再次運行完全相同的查詢時，它只回顯已保存的結果集，而不是重新評估它。

可以通過在語句中只添加一個空格或說SELECT SQL_NO_CACHE ...來避免QC。

為了進一步討論為什么查詢需要查看3100萬行，讓我們看一下查詢和SHOW CREATE TABLE 。

后查詢

我想首先關注ON msgs.sender = usrs.u_code和“ prefix”索引。

根據樣本值，似乎sender ， u_code和其他幾個列的長度可能總是很短？ 如果這是真的，那么

• 從TEXT更改為VARCHAR(nn) ，其中nn是一些實際限制；
• 擺脫前綴（例如： KEY sender (sender(24)) -> KEY (sender) 。

這些更改將使JOIN更加有效，從而提高性能。 如果這還不夠，請返回以獲取更多建議。

Answer 2

雖然我無法解釋為什么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;

慢查詢日志證明此解決方案是有效的，因為沒有新的慢條目出現。