1

我对 mysql slow.log 输出有疑问。查询 mysql slow 显示了这一点，我用 mysql 检查了相同的explain内容，它说只检查了 5 行，但 mysql slow 说检查了大约 7 lkh 行。

另外在我的查询中没有写set timestamp

   # User@Host: dba[dba] @ localhost []
   # Query_time: 7.282718  Lock_time: 1.291532 Rows_sent: 0  Rows_examined: 651223
   SET timestamp=1361437845;
   SELECT *
   FROM tableA
   WHERE app='pic' and sub
   LIKE '%katrina%'
   order by id desc limit 5

这是解释输出

    1 SIMPLE tableA index NULL  PRIMARY 4 NULL  5 Using where
4

1 回答 1

4

您只有 5 行，因为您将结果集限制为 5 行。查看查询的最后一行。MySQL 仍然必须检查这 651223 行以找到它只显示 5 行的结果集。这是因为不能在列上使用索引，sub因为您的 LIKE 子句以%. 如果您在 column 上有索引app，则可能由于多种原因不使用它。与您的表所​​包含的行数相比，您的不同值可能太少了。因此 MySQL 决定使用主键索引进行排序（您的 order by 子句）。至少我是这么认为的，因为我无法explain在您的评论中真正阅读您的结果。请在下一次将此类信息编辑到问题中。

这SET timestamp=1361437845是查询作为 unix_timestamp 执行的时间。

更新（进一步解释）：

您的 LIKE 子句是LIKE '%katrina%'. 这意味着“字符串中的某处是卡特里娜飓风，它之前和之后可能有字符”。现在想象一下，您想根据这些标准在电话簿中查找某人。电话簿按字母顺序排列的事实是没有用的，因为这些人的名字可能是 Ankatrina 或 Zekatrina。与您在 column 上的索引相同sub。

假设您有 300 万行，其中 100 万行在列应用程序中有“pic”，100 万行有“nic”，100 万行有“asdf”。这意味着，查看索引实际上是额外的工作，然后在表中查找实际记录。所以有时只扫描整个表会更便宜。但就像我说的，这只是一个猜测。我们没有关于您的数据库的足够信息。

拥有索引并不能保证一定会使用该索引。

之所以EXPLAIN说 5 rows 而不是 slow-query-log 的原因是，这EXPLAIN实际上只是一个猜测，优化器可能如何处理您的查询。当您想知道如何处理它时，请使用EXPLAIN EXTENDED. 这里还有一点棘手的是，如果您不需要，查询就不必检查这么多行ORDER BY id DESC。然后 MySQL 真的会扫描 5 行并吐出结果，因为你的LIMIT 5. 由于您的订购，它可能必须首先创建一个临时表，对事物进行排序，然后从该表中吐出 5 行。可能是在 中没有考虑到这EXPLAIN一点slow-query-log。

于 2013-02-21T17:44:25.363 回答