Question

我正在尝试优化查询，当我得到“解析”时它们看起来都很好，但它仍然出现在“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运行它时显示

id | select_type | table | type   | possible_keys     | key     | key_len | ref                       | rows | Extra
1  | SIMPLE      | t1    | index  | user_id           | PRIMARY | 4       | NULL                      | 35   | Using where
1  | SIMPLE      | t2    | eq_ref | PRIMARY,active_id | PRIMARY | 4       | hnet_user_info.t1.user_id | 1    | Using where

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

所以我无法弄清楚为什么它会出现在log_queries_not_using_index报告中。

任何提示？如果需要，我可以发布更多信息。

Answer 1

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

信任数据库引擎。数据库查询计划程序将使用索引时确定这样做是有益的。在这种情况下，由于低cardinality estimates（35x1），查询计划程序决定没有理由使用索引来实际执行计划。如果在像这样的普通情况下使用索引，它实际上可能会增加查询执行时间。

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

MySQL有索引表，EXPLAIN看起来很好，但仍然没有使用索引

1 个答案: