SQL优化工作记录

关键词：SQL优化

 

---

激动呀，没想到自己会在工作中遇到SQL调优的工作。由于我所在的项目组是开发一个管理人员发系统，该系统是以公司为单位设计数据库的，即不同公司的数据放到不同的库中，自然也就不会放到同一张表中。这样做的话会让单张表的数据量不会太大。所以在大大大大大部分情况下，是不会出现这种从肉眼能明显感觉到接口返回结果很慢的情况。

但是，也存在一个极小部分的数据，一个公司的账号管理着二百多个公司的数据，员工总人数将近3000，这个时候这些数据就会出现在同一张表中了。于是，在生产环境，该公司的一个查看人员请假记录的页面就出现了响应很慢的情况。该页面已经分页查询了，每页只查询10条结果，接口的响应时间却足足要50多秒。这.....也.....太.....慢.....了！

于是乎，经过一个星期的调优，无论是代码层面，还是SQL层面，将该公司的好多加载慢的页面提高了明显的性能，比如上述的50多秒响应的接口提高到了2秒内返回结果。当数据量越来越大的时候，数据库查询真的是影响性能的一个关键因素，尤其是一个很烂的SQL。

其实关于SQL调优，一般开发的时候很少会考虑性能和优化这些方面，项目前期数据量都很少，开发和测试环境一般也不会提供大数据量来使用。只有当数据量大出现问题了才会去做调优。可以说是有针对性的调优吧。

在调优之前，还需要了解下SQL执行的顺序，即一条SQL，先执行哪部分，再执行哪部分。具体请戳《Select语句执行顺序》

---

 █ 总结

（1）不要在代码中循环查询数据库

正所谓，"前人埋坑，后人凉凉"。在这个项目中，以前别人写的代码很多会在循环中去查询数据库，比如对于请假列表，申请表中存储的是员工ID，但是返回给前端需要员工的姓名，这个时候需要关联申请表和员工表了。以前的程序是这样写的，先查10条申请表记录，然后再循环10条记录，再根据记录中的申请者ID去员工表中查询姓名。这样查询10条记录，与数据库就交互了11次。其实对于这样的需求，完全可以一次性的查询出需要的数据的。上面的例子比较简单，一般人也不会这么干。对于有些复杂的需求，尽量能够减少与数据库交互的次数，可以将数据都拿到内存中，接着再进行处理。以空间换时间，可以大大提高效率。

（2）多表连接查询时，查询条件请使用索引

当初第一批开发人员为了让功能能够实现用户定制化，将一块功能的数据存放在了多个表中，所以在SQL语句中会用到大量的连接查询。在进行多表连接查询的时候，ON后面的条件包含了索引列的话，查询速度也是非常快的。比如 tableA LEFT JOIN tableB on tableA.columnA = tableB.columnB，如果columnA是tableA的索引列的话，查询会非常快。

（3）SELECT字段能少则少

在本次调优中，也发现，当SELECT 的字段很多时，也会严重影响查询的性能，尤其是在多张表连接查询中。但其实有些字段根本就用不上，所以不需要查询返回结果。所以，尽量SELECT只返回需要的字段，能少则少。

（4）对于带有分页的连接查询，若能够先从主表中筛选出分页数据，再连接其他表查询的话，请这么做

项目上的申请相关的表有四五个，主表是APPLY表，用于存放主要信息，还有一些人员表，配置表等等。其实APPLY表有四万多条数据吧。所以，对于分页查询的功能，如果能够先从APPLY表分页，比如先找出10条数据，再和其他表做连接查询。

（5）当查询条件需要用到一个重复值很多的列时，可以将其与一个唯一列做一个组合索引

当根据部门编号去员工表查询员工的时候，部门编号的重复值一定是非常多的。当查询条件写成where deptId = '' 时，及时单独设置部门列为索引列，但MySQL优化器有可能也不会使用，因为该列的重复值太多了。此时可以将该列与一个唯一列做组合索引，比如(deptId, id)。这样在根据部门编号查询的时候，也会使用到索引。

（6）学会使用EXPLAIN查询查询SQL的执行计划

根据EXPLAIN的执行计划，建立合适的索引以及调整SQL。关于EXPLAIN的详细介绍，请戳《MySQL之EXPLAIN》