更新：
谢谢你的帮助 . 我将总结答案 .
来自@Jaydee，他的答案成功地将结果减少到0.09秒，并且它与LIMIT中的数字成线性关系 .
select * from（select table1.id as table1_id from table1 where table1.id <100000 order by table1.id desc limit 1000）t1 inner join table2 on t1.table2_id = table2.id left join table3 on t1.table3_id = table3 . id由t1.id命令;
来自@Rick James，他提到它可能是表2的问题 . 因为我的表2只有几列，我可以把它留下来，自己做连接，即使在客户端也是如此！
所以我删除了表2，它只有0.02秒！
select table1.id as table1_id from table1 left join table3 on table1.table3_id = table3.id where table1.id <100000 order by table1.id desc limit 1000;
最后，我发现，如果我将table2从内连接更改为左连接，那么所有的痛苦都消失了，它是0.03秒！
select table1.id as table1_id from table1 left join table2 on table1.table2_id = table2.id left join table3 on table1.table3_id = table3.id where table1.id <100000 order by table1.id desc limit 1000;
再次感谢您的帮助！
==============================
注意：我在嵌入式服务器上运行，RAM有限（大约1G，足以输入所有数据，200,000个数据）并使用SD卡作为存储 .
从table1中选择table1.id，其中id <100000 order by id desc limit 1000;
（0.01S）
select table1.id as table1_id from table1 inner join table2 on table1.table2_id = table2.id where table1.id <100000 order by table1.id desc limit 1000;
（0.40s）
select table1.id as table1_id from table1 inner join table2 on table1.table2_id = table2.id where table1.id <1000 order by table1.id desc limit 1000;
（0.01S）
select table1.id as table1_id from table1 inner join table2 on table1.table2_id = table2.id left join table3 on table1.table3_id = table3.id where table1.id <100000 order by table1.id desc limit 1000;
（2.31s）
select table1.id as table1_id from table1 inner join table2 on table1.table2_id = table2.id left join table3 on table1.table3_id = table3.id where table1.id <1000 order by table1.id desc limit 1000;
（0.03S）
正如评论建议的那样，我使用了解释，但我真的不明白解释说的是什么 . 请帮我查一下 . 以下是最长的2.31s .
+----+-------------+----------------------+--------+-------------------------------------------------------------------+---------------------------------------+---------+---------------------------------------------+-------+----------------------------------------------+
| id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra |
+----+-------------+----------------------+--------+-------------------------------------------------------------------+---------------------------------------+---------+---------------------------------------------+-------+----------------------------------------------+
| 1 | SIMPLE | table2 | index | PRIMARY,table2_id_index | table1_id_index | 4 | NULL | 1 | Using index; Using temporary; Using filesort |
| 1 | SIMPLE | table1 | ref | PRIMARY,table1_table2_id_foreign,table1_id_index | table1_table2_id_foreign | 4 | videocap.table2.id | 27222 | Using where |
| 1 | SIMPLE | table3 | eq_ref | PRIMARY | PRIMARY | 4 | videocap.table1.table3_id | 1 | Using index |
+----+-------------+----------------------+--------+-------------------------------------------------------------------+---------------------------------------+---------+---------------------------------------------+-------+----------------------------------------------+
来自desc表的结果
表格1：
+-------------------------+------------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-------------------------+------------------+------+-----+---------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| table2_id | int(10) unsigned | NO | MUL | NULL | |
| table3_id | int(10) unsigned | NO | MUL | 0 | |
| created_at | timestamp | NO | | 0000-00-00 00:00:00 | |
| updated_at | timestamp | NO | | 0000-00-00 00:00:00 | |
+-------------------------+------------------+------+-----+---------------------+----------------+
表2：
+-----------------+------------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+-----------------+------------------+------+-----+---------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| created_at | timestamp | NO | | 0000-00-00 00:00:00 | |
| updated_at | timestamp | NO | | 0000-00-00 00:00:00 | |
+-----------------+------------------+------+-----+---------------------+----------------+
表3：
+---------------------------+------------------+------+-----+---------------------+----------------+
| Field | Type | Null | Key | Default | Extra |
+---------------------------+------------------+------+-----+---------------------+----------------+
| id | int(10) unsigned | NO | PRI | NULL | auto_increment |
| created_at | timestamp | NO | | 0000-00-00 00:00:00 | |
| updated_at | timestamp | NO | | 0000-00-00 00:00:00 | |
+---------------------------+------------------+------+-----+---------------------+----------------+
2 回答
看起来table2有1行 . 那是对的吗？每张表中有多少行？
在table2中只有1行，优化器似乎决定让它开始 .
在所有情况下，
PRIMARY KEY(id)，特别是如果您使用InnoDB，最适合但是，如果表的大部分id <100000，那么优化器可能（错误地）决定进行表扫描（因为它没有考虑
LIMIT） . 你用的是什么版本？ 5.6在这方面有一些改进 .请记住，查询有数百万种变体 . 虽然我感谢您尝试隔离查询的重要部分;您可能会发现将任何答案应用回“真实”查询可能会遇到其他一些打嗝 .
这是如何表现的？ （哎呀 . 更正）