Mysql 避免按顺序“使用临时”和“使用文件排序”

很抱歉，在浏览了几乎所有关于它的帖子和问题之后，我仍然无法摆脱在一个简单的查询中使用临时和文件排序。我知道这是钥匙的问题，但我找不到正确的组合

我也不知道优化器定义的连接顺序是否正确，我使用STRAIGHT_join测试了其他顺序，但没有更好的。。。使用ORDERBY查询速度非常慢，但是如果没有它，查询速度非常快，当然也没有使用临时和filesort！点表中大约有100.000行

查询：

SELECT points.id,
points.id_owner,
points.point_title,
points.point_desc,
users.user_id,
users.username
FROM points,
JOIN users ON points.id_owner = users.user_id
JOIN follows ON follows.id_followed = points.id_owner
WHERE points.deleted = 0
AND follows.id_follower = 22
ORDER BY points.id DESC
LIMIT 10

委员会解释说：

+----+-------------+---------+--------+---------------+------------+---------+---------------------+------+----------------------------------------------+
| id | select_type | table   | type   | possible_keys | key        | key_len | ref                 | rows | Extra                                        |
+----+-------------+---------+--------+---------------+------------+---------+---------------------+------+----------------------------------------------+
|  1 | SIMPLE      | follows | ref    | FOLLOW_DUO    | FOLLOW_DUO | 4       | const               |    2 | Using index; Using temporary; Using filesort |
|  1 | SIMPLE      | users   | eq_ref | PRIMARY       | PRIMARY    | 4       | follows.id_followed |    1 |                                              |
|  1 | SIMPLE      | points  | ref    | GETPOINT1     | GETPOINT1  | 5       | users.user_id,const |  460 | Using where                                  |
+----+-------------+---------+--------+---------------+------------+---------+---------------------+------+----------------------------------------------+

以下是三个表中的显示索引：

SHOW INDEX FROM points
+--------+------------+--------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+
| Table  | Non_unique | Key_name     | Seq_in_index | Column_name     | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+--------+------------+--------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+
| points |          0 | PRIMARY      |            1 | id              | A         |       91987 |     NULL | NULL   |      | BTREE      |         |
| points |          0 | GETPOINT1    |            1 | id_owner        | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
| points |          0 | GETPOINT1    |            2 | deleted         | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
| points |          0 | GETPOINT1    |            3 | id              | A         |       91987 |     NULL | NULL   |      | BTREE      |         |
+--------+------------+--------------+--------------+-----------------+-----------+-------------+----------+--------+------+------------+---------+

SHOW INDEX FROM users
+-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table | Non_unique | Key_name   | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| users |          0 | PRIMARY    |            1 | user_id     | A         |           4 |     NULL | NULL   |      | BTREE      |         |
+-------+------------+------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

SHOW INDEX FROM follows
+---------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| Table   | Non_unique | Key_name    | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment |
+---------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+
| follows |          0 | PRIMARY     |            1 | id          | A         |           5 |     NULL | NULL   |      | BTREE      |         |
| follows |          0 | FOLLOW_DUO  |            1 | id_follower | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
| follows |          0 | FOLLOW_DUO  |            2 | id_followed | A         |           5 |     NULL | NULL   |      | BTREE      |         |
| follows |          1 | id_follower |            1 | id_follower | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
| follows |          1 | id_followed |            1 | id_followed | A         |        NULL |     NULL | NULL   |      | BTREE      |         |
+---------+------------+-------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+

---

从现在起，我不知道应该测试什么来避免使用临时文件和使用文件排序。。。所以如果你对我有什么想法。。。提前感谢您的帮助

看起来要从points表中检查的行太多了。为了避免在项目中临时使用表，我尝试了以下技巧。请按照以下步骤进行操作，并对其进行解释，以查看是否有任何改进：

删除名为“GETPOINT1”的所有索引，主键索引表单点表除外。 在已删除的列上添加覆盖索引，id\u所有者。请保持上述列的顺序。 如果仍然看不到任何改进，请删除上面的索引，然后在顺序id、deleted、id\u owner和deleted、id\u owner、id列中再次添加索引，然后重试 此外，您可以从where子句中删除follows.id\u follower=22，并将其置于连接条件中，如join follows ON follows.id\u followerd=points.id\u owner和follows.id\u follower=22 请在下表中按id\u follower、id\u owner的顺序添加索引。

---

我不保证，但上面的内容应该能给您带来改进。

您阅读了和上的MySQL文档吗？@Catcall是的，我读过，但如果我理解这个问题，我想不出在这种情况下如何避免它…：你是怎么避免的？