当sql语句中的where条件太大，比如说 select * from tname where id in(1,2,3,4,8,11,23,56,89,110,112,113,114,115,116...)，

即当in的数量相当大时，这种sql语句是很劣质的，那么用什么其它更好的方法解决这样的问题呢？

1、加索引

对要查询的字段加索引，但是要注意存在联合查询的情况；因此要考虑是加单列索引还是多列的复合索引。

如果索引情况复杂无法使用索引，并可以force index强制指定索引。

2、join

使用关联查询，并对关联字段加索引。避免出现wherein。

3、使用 between

分块，利用 between 提高效率。前提是要查询的数组内的值具有连续性。

4、利用union

select * from x where id=1 union all select * from x where id=2 union all ...

这个就不错了。

5、传入的 id 组先存入表，然后再关联查询

6、历传入的 id 组，循环里逐一查询

除了where in对于sql查询的优化还有很多，在应用开发的早期，数据量少，开发人员开发功能时更重视功能上的实现，随着生产数据的增长，很多SQL语句开始暴露出性能问题，对生产的影响也越来越大，有时可能这些有问题的SQL就是整个系统性能的瓶颈。

1、通过慢查日志等定位那些执行效率较低的SQL语句

2、explain 分析SQL的执行计划

需要重点关注type、rows、filtered、extra。

type由上至下，效率越来越高

范围查询还有“IN、between”

案例6、不等于、不包含不能用到索引的快速搜索。（可以用到ICP）

在索引上，避免使用NOT、!=、、!、NOT EXISTS、NOT IN、NOT LIKE等

案例7、优化器选择不使用索引的情况

如果要求访问的数据量很小，则优化器还是会选择辅助索引，但是当访问的数据占整个表中数据的蛮大一部分时（一般是20%左右），优化器会选择通过聚集索引来查找数据。

查询出所有未支付的订单，一般这种订单是很少的，即使建了索引，也没法使用索引。

案例8、复杂查询

如果是统计某些数据，可能改用数仓进行解决；如果是业务上就有那么复杂的查询，可能就不建议继续走SQL了，而是采用其他的方式进行解决，比如使用ES等进行解决。

案例9、asc和desc混用

desc 和asc混用时会导致索引失效

案例10、大数据

对于推送业务的数据存储，可能数据量会很大，如果在方案的选择上，最终选择存储在MySQL上，并且做7天等有效期的保存。那么需要注意，频繁的清理数据，会照成数据碎片，需要联系DBA进行数据碎片处理。

来源:https://www.cnblogs.com/powercto/p/14410128.html

补充：Mysql如何调优，实战，可以参考下这篇文章：

我是架构师小于哥

@终端研发部

关注我每天学习职场经验和技术开发小技巧哦