大SQL执行时间较长怎么办？

Question

问题描述

MySQL数据库
已建索引了 SQL语句不复杂 就二，三个条件
单纯就是某个条件的in参数太多 查出来的结果集数据量太大导致的
SQL执行就是这么慢 业务上是这么个需求

但是上面指标要求太变态 要求所有SQL控制在200ms以内
现在很难解决 有什么办法吗？

换TiDB之类的方案就算了 上面不可能同意

相关代码

in 查询参数太多 一般超过5000个

select * from table t where t.id in (...)

已通过执行计划确认命中索引

无连表查询 需多表数据时都是单标查询后内存里拼接的

你期待的结果是什么？实际看到的错误信息又是什么？

希望能控制在200ms以内 现在经常有超过200ms
老实说几个开发都觉得查数据1s内都没啥 但是上面就是这么个要求

Answer 1

根据你评论和修改后的问题更新的内容：

1. 可以确认一下，你的传递给查询的参数和 MySQL 具体字段的类型是否匹配（MySQL 的隐式类型转换在面对较大数据量时也会消耗不少时间）
2. 尝试一下建立一个临时表，把你需要 IN 的内容全部放进去，然后用你的查询的表和这个临时表连表进行查询，这应该可以比直接的 SELECT IN 要快
3. 不得不说索引命中了也不见得是最优的，这个确实只能有看到表和查询的实际情况再讨论了，如果公司有 DBA，不妨让 DBA 来 review 你的实际情况

---

没有实际 SQL 和表的情况，所以只能泛泛而谈

explain 看过执行计划了吗？确定真的命中了索引吗？（包括所有的子查询？）

如果有连表跨表，把连表拆出来，在你的代码层面进行数据的重新组装

如果有非常大的 limit ，review 一下是不是产品层面真的有这么大的数据量要展现，查询语句是否真的设计合理

一些你要现查的数据有存在写入时冗余存储的可行性吗？（例如某个关联表的关联数量类的数据）

PS: 200ms 并不是什么变态的要求，其实还是很正常的

Answer 2

根据其他大佬的回答，我的理解是，没有子查询，没有联表，也没有回表。如果返回的字段在5个以内的话，可以考虑建一个只包含返回字段的组合索引，以减少读硬盘的IO次数，同时也减少网络IO的数据量。

Answer 3

试试用不用select 改成select from table inner join (
select id from table t where t.id in (...)) d on id=id