对于慢查询我们一般通过如下思路解决：
1. explain sql 分析慢SQL
2. 利用缓存
3. 读写分离和分库分表
4. 评论区补充，待续...

本篇是系列文章（以 MySQL 为例），从多个角度分析、解决慢查询，如意犹未尽：微信搜【JavaPub】

为了提高查询效率，当数据库表加完索引后还不不能满足性能需求，第二步，SQL 语句优化。

系统前期开发阶段，为了快速开发，SQL 语句都是以实现功能为主，性能上可能没怎么在意。本篇主要讲述几个在实战中注意优化的性能点供大家参考。

文章结构由简到难，以目录为结论，下文做详细讲解。

文章目录

• • • 1. 应尽量避免在 where 子句中对字段进行 null 值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：
    • 2. 应尽量避免在 where 子句中使用!=或<>操作符，否则将引擎放弃使用索引而进行全表扫描。
    • 3. 应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：
    • 4. in 和 not in 也要慎用，否则会导致全表扫描，如：
    • 5. 下面的查询也将导致全表扫描：
    • 6. 应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：
    • 7. 应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。如：
    • 8. 不要在 where 子句中的“=”左边进行函数、算术运算或其他表达式运算，否则系统将可能无法正确使用索引。
    • 9. 在使用索引字段作为条件时，如果该索引是复合索引，那么必须使用到该索引中的第一个字段作为条件时才能保证系统使用该索引，否则该索引将不会被使用，并且应尽可能的让字段顺序与索引顺序相一致。
    • 10. 很多时候用 exists 代替 in 是一个好的选择：
    • 11. 并不是所有索引对查询都有效，SQL 是根据表中数据来进行查询优化的，当索引列有大量数据重复时，SQL 查询可能不会去利用索引。
    • 12. 索引并不是越多越好，索引固然可以提高相应的 select 的效率，但同时也降低了 insert 及 update 的效率，
    • 13. 尽量使用数字型字段，若只含数值信息的字段尽量不要设计为字符型，这会降低查询和连接的性能，并会增加存储开销。
    • 14. 尽可能的使用 varchar 代替 char ，因为首先变长字段存储空间小，可以节省存储空间，其次对于查询来说，在一个相对较小的字段内搜索效率显然要高些。
    • 15. 任何地方都不要使用 select * from t ，用具体的字段列表代替 “*”，不要返回用不到的任何字段。
    • 16. 避免频繁创建和删除临时表，以减少系统表资源的消耗。
    • 17. 在新建临时表时，如果一次性插入数据量很大，那么可以使用 select into 代替 create table，避免造成大量 log ，以提高速度；如果数据量不大，为了缓和系统表的资源，应先create table，然后insert。
    • 18. 如果使用到了临时表，在存储过程的最后务必将所有的临时表显式删除，先 truncate table ，然后 drop table ，这样可以避免系统表的较长时间锁定。
    • 19. 尽量避免使用游标，因为游标的效率较差，如果游标操作的数据超过1万行，那么就应该考虑改写。
    • 20. 使用基于游标的方法或临时表方法之前，应先寻找基于集的解决方案来解决问题，基于集的方法通常更有效。
    • 21. 与临时表一样，游标并不是不可使用。对小型数据集使用 FAST_FORWARD 游标通常要优于其他逐行处理方法，尤其是在必须引用几个表才能获得所需的数据时。
    • 22. 尽量避免大事务操作，提高系统并发能力。
    • 23. 尽量避免向客户端返回大数据量，若数据量过大，应该考虑相应需求是否合理。