如何优化此查询？

查询：如何优化此查询？

select id, 
     title 
    from posts 
where id in (23,24,60,19,21,32,43,49,9,11,17,34,37,39,46,5 
2,55)

解释计划：

mysql> explain select id,title from posts where id in (23,24,60,19,21,32,43,49,9,11,17,34,37,39,46,5 
2,55); 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra  | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
| 1 | SIMPLE  | posts | ALL | PRIMARY  | NULL | NULL | NULL | 30 | Using where | 
+----+-------------+-------+------+---------------+------+---------+------+------+-------------+ 
1 row in set (0.05 sec)

ID是职位表的主键。

来源

2009-10-22 Mask

我不认为你可以：你正在选择主键的显式值，而且你的EXPLAIN预期会有不同的结果（即30行而不是18），这可能是由于optimizer交互的方式与统计。或者我误解了你的问题？ – davek 2009-10-22 14:37:05

@Dave K 30这里是MySQL为了处理查询而希望读取的行数，它不是它在结果列表中所期望的行数。由于它只需要很少的行（可能全部包含在单个节点中，或几个任意速率），因此“扫描”比“查找”更有效。 – mjv 2009-10-22 14:51:50

如果你正在寻找一个单一的ID，这个计划是什么样子？ – Thorsten 2009-10-22 19:55:31

除了添加其他索引，例如

聚簇索引ID
覆盖索引，其中包括ID [第一]并从SELECT子句

似乎有其它列要做的事情很少......

事实上，即使有这样的索引可用，MySQL可能会决定做一个表扫描，这里就是这种情况（“ALL”类型）。原因可能是该表可能只有相对较少的行（与查询将返回的估计行数相比），因此“读取”表顺序更有效，顺序丢弃不匹配的行，而不是“希望到处都有”，而且索引是间接的。

来源

2009-10-22 14:36:16 mjv

我没有看到任何问题。如果您需要根据列表进行选择，那么“IN”是正确的做法。你没有选择不必要的信息，你选择的东西是一个关键，这可能是索引。

来源

如何优化此查询？

回答

相关问题