Question

我的mysql slow.log输出有问题。查询mysql slow显示了这一点，我用mysql explain检查了同样的内容，它说只检查了5行但是mysql慢了，表示检查了大约7万行。

此外，在我的查询中，无处写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

Answer 1

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

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

更新（进一步解释）：

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

想象一下，你有300万行，其中100万行在专栏应用中有“pic”，100万有“nic”，100万有“asdf”。这意味着，查看索引实际上是额外的工作，然后查找表中的实际记录。因此，扫描整个表格有时会更便宜。但就像我说的那样，这只是猜测。我们没有足够的有关您的数据库的信息。

拥有索引并不能保证将使用索引。

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

了解slow.log mysql

1 个答案: