Mysql 尽管有索引，但查询速度非常慢

我正在使用下面的查询，尽管有索引，但速度非常慢，有人能帮忙吗

表a有近5万个条目，表b约有200万个条目 我尝试在表2中的batchid上创建索引，但没有帮助

select distinct x, y 
from t1 a,t2 b  
where b.batch_id = a.batch_id and b.sm_id = a.smid and b.status = 'new' and target_userid = *some value*
limit 10

这是解释输出

+----+-------------+-------+------+-----------------------------------+---------------+---------+------------------------------+---------+------------------------------+
| id | select_type | table | type | possible_keys                     | key           | key_len | ref                          | rows    | Extra                        |
+----+-------------+-------+------+-----------------------------------+---------------+---------+------------------------------+---------+------------------------------+
|  1 | SIMPLE      | b     | ALL  | smreconhistory_sm_id_status_index | NULL          | NULL    | NULL                         | 2033644 | Using where; Using temporary |
|  1 | SIMPLE      | a     | ref  | smid_batch_id,idx_batch_id        | smid_batch_id | 16      | sync.b.sm_id,sync.b.batch_id |       1 | Using where; Distinct        |
+----+-------------+-------+------+-----------------------------------+---------------+---------+------------------------------+---------+--------------------

表1的索引

+-----------------+------------+----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table           | Non_unique | Key_name                   | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+-----------------+------------+----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| SMReconJobEntry |          0 | PRIMARY                    |            1 | id          | A         |       49323 |     NULL | NULL   |      | BTREE      |         |               |
| SMReconJobEntry |          1 | smreconjobentry_ugid_index |            1 | ugid        | A         |       49323 |     NULL | NULL   |      | BTREE      |         |               |
| SMReconJobEntry |          1 | smid_batch_id              |            1 | smid        | A         |       49323 |     NULL | NULL   |      | BTREE      |         |               |
| SMReconJobEntry |          1 | smid_batch_id              |            2 | batch_id    | A         |       49323 |     NULL | NULL   |      | BTREE      |         |               |
| SMReconJobEntry |          1 | idx_batch_id               |            1 | batch_id    | A         |       49323 |     NULL | NULL   |      | BTREE      |         |               |
+-----------------+------------+----------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+--

表2

+----------------+------------+-----------------------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table          | Non_unique | Key_name                          | Seq_in_index | Column_name  | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+----------------+------------+-----------------------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| SMReconHistory |          0 | PRIMARY                           |            1 | id           | A         |     2033644 |     NULL | NULL   |      | BTREE      |         |               |
| SMReconHistory |          1 | smreconhistory_sm_id_status_index |            1 | sm_id        | A         |          18 |     NULL | NULL   | YES  | BTREE      |         |               |
| SMReconHistory |          1 | smreconhistory_sm_id_status_index |            2 | status       | A         |          18 |     NULL | NULL   |      | BTREE      |         |               |
| SMReconHistory |          1 | gmailunit_id_foreign              |            1 | gmailunit_id | A         |     2033644 |     NULL | NULL   | YES  | BTREE      |         |               |
+----------------+------------+-----------------------------------+--------------+--------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

---

不要使用find_in_set，replace函数，它每次都会计算，我建议使用in与静态值

x IN ('a', 'b', 'c')

---

在_集中查找_与性能无关，因为即使这个查询速度很慢，也要从t1 a，t2 b中选择不同的x，y，其中b.batch_id=a.batch_id和b.sm_id=a.smid和b.status='new'和target_userid=***limit 10ok，那么我怀疑distinct可能会导致性能问题，请尝试删除它以检查差异。已经尝试过了，这不是罪魁祸首检查解释输出，第二行的行值为1，可能您的索引不起作用，您是否可以像表1一样为表2创建多列索引？您省略了一些关键信息，例如表定义。另外，什么是

*值*

和

目标用户ID

？另外，我还没有看到mysql中没有引号的

*value*

是有效的字符串文字（尽管我使用mysql已经有一段时间了）。请发布并显示导致问题的实际sql语句。@JimGarrison编辑，target_userid是另一列，value是任何值，我的意思是，您的低基数索引

smreconhistory\u sm_id_status_index

没有任何贡献，优化器选择了完整表扫描而不是索引，正如@JimGarrison所解释的，是的，我已经看到了，那么我应该在批处理id上创建索引吗？