一文讲解如何写出高效精致SQL-Toy模板网

这篇具有很好参考价值的文章主要介绍了一文讲解如何写出高效精致SQL。希望对大家有所帮助。如果存在错误或未考虑完全的地方，请大家不吝赐教，您也可以点击"举报违法"按钮提交疑问。

尽量避免select * from，仅返回所需字段

在日常查询表数据时，经常不自觉的写select * from，查询全部字段信息；虽然记录少的单表没啥感觉，但当关联多个表且表体量大时，select * from将返回所有表的字段，会影响查询效率。较好的方式，就是需要什么查什么，仅返回所需字段信息；这也符合开发中的最少知道原则，尽量不去暴露不需要的信息。

避免全量查询，尽量小的控制查询粒度

日常开发环境查询中，可能随手就写了select * from tableA，这样的查询将返回全部记录和全部字段，这样的查询如果误升级到生产环境，查询太慢可能会带来灾难性的后果。全表扫描是一种低效的查询方式，应尽量避免。通过使用索引、合适的过滤条件和JOIN优化，减少全表扫描的情况。所以，在查询时时，习惯性的增加where条件过滤（比如分页、字段过滤、日期区间等），返回尽量小的数据，这将大大提升查询效率。

查询时尽量走索引，最好提前设计好索引

当单表记录数太多时，而且通过非索引字段进行表关联查询时，查询效率很低；此时对关联字段建立索引，将大大提升查询效率。所以，在设计表时，最好就考虑业务场景，对常用来过滤查询或者表关联的字段，建立索引，将对后续查询大有裨益。同时，在查询过程中，也尽量走索引查询，比非索引查询效率高太多了。

尽量避开索引失效的场景

索引虽好，但使用不当，可能起不到想要的效果，这其中就需要重点关注索引失效的情况，并尽量避免之。

索引失效的场景主要有：

联合索引不满足最左匹配原则
使用select * 查询
使用索引列进行表达式运算
索引列使用了内置函数
错误的使用like模糊查询
索引列进行类型隐式转换
使用or操作
使用>,<,!=等进行索引列比较
使用is not null
使用not in和not exixts
错误的order by 排序

Update时避免全量修改，只修改需要的字段

在修改表记录时，一些随手操作就是updateById(Entity entity)，虽然也能更新成功，但注意sql会发现，他把Entity 的全部字段都更新了一遍，而我们可能仅仅只想修改个状态字段。而后者的只用修改少量字段的效率显然比全量修改要高，更重要的是，能避免其他字段被误修改，导致一些其他问题。