1

我正在尝试优化查询，当我“解释”它时一切看起来都很好，但它仍然出现在“log_queries_not_using_index”中。

这是查询：

SELECT t1.id_id,t1.change_id,t1.like_id,t1.dislike_id,t1.user_id,t1.from_id,t1.date_id,t1.type_id,t1.photo_id,t1.mobile_id,t1.mobiletype_id,t1.linked_id 
FROM recent AS t1 
LEFT JOIN users AS t2 ON t1.user_id = t2.id_id 
WHERE t2.active_id=1 AND t1.postedacommenton_id='0'  AND t1.type_id!='Friends' 
ORDER BY t1.id_id DESC LIMIT 35;

所以它像“wallpost”数据一样抓取，然后我加入了 USERS 表以确保用户仍然是活跃用户（数字 1）和另外两个小的“AND”。

当我在 phpmyadmin 中使用 EXPLAIN 运行它时，它显示

编号 | 选择类型 | 表| 类型 | 可能的键 | 关键 | key_len | 参考 | 行 | 额外的
1 | 简单 | t1 | 索引 | 用户 ID | 初级 | 4 | 空 | 35 | 使用哪里
1 | 简单 | t2 | eq_ref | PRIMARY,active_id | 初级 | 4 | hnet_user_info.t1.user_id | 1 | 使用哪里

它显示 t1 查询使用“WHERE”找到 35 行，t2 查询使用“WHERE”找到 1 行（用户）

所以我不知道为什么它会出现在 log_queries_not_using_index 报告中。

有小费吗？如果您需要，我可以发布更多信息。

4

1 回答 1

2

tldr; 忽略“不使用索引警告”。1.3 毫秒的查询执行时间不是问题；这里没有什么可以优化的 - 查看整个性能配置文件以找到瓶颈。

信任数据库引擎。当数据库查询计划器确定这样做是有益的时，它将使用索引。在这种情况下，由于基数估计值较低(35x1)，查询规划器认为没有理由为实际执行计划使用索引。如果在这样的微不足道的情况下使用索引，它实际上可能会增加查询执行时间。

与往常一样，使用 97/3 规则。

于 2013-01-11T05:28:07.563 回答