一文讲解如何写出高效精致SQL

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

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

避免不加条件的全量查询，尽量小的控制查询粒度

        日常开发环境查询中，可能随手就写了select * from tableA，这样的查询将返回全部记录和全部字段，这样的查询如果误升级到生产环境，查询太慢可能会带来灾难性的后果。所以，在查询时时，习惯性的增加where条件过滤（比如分页、字段过滤、日期区间等），返回尽量小的数据，这将大大提升查询效率。

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

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

尽量避开索引失效的场景

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

        索引失效的场景主要有：

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

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

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

慎重选择“硬删除”重要数据

        删除数据很爽，但也很有风险，尤其是误删除了重要数据。删除数据，通常有物理删除（硬删除）、逻辑删除。但无论是哪种删除，都要注意限定条件，不要把数据全删了，不要都得跑路了。

        物理删除，可以节省内存空间，同时保证表里只有有效的数据，可读性好。但是物理删除话，数据大概率不会恢复。而逻辑删除的话，虽说更安全一点，但是一定程度污染的表数据，后续每次关联查询，都得记得过滤有效数据。

        对于一些有价值的历史数据，是否可以考虑设计历史表，用来转存被删除的历史数据，一方面，可保证的可追溯，同时也保证了原表数据的简洁和有效性。