数据库|特别有用的SQL优化小技巧，了解之后程序性能大为提升数据库

古人讲， “不积跬步，无以至千里” 。编程也是一样，所有的小的性能优化点都做到了最优，最终的运行效果可能比没有做优化提升数百倍。尤其是在一些你并不知道哪个地方会让程序变得缓慢的情况下。因此，掌握一些最基本的优化小技巧，并且把它们变成自己工作习惯的一部分，会减少很多不必要的潜在麻烦。
那么今天我们就来科普一些SQL优化的小技巧，熟练掌握这些技巧之后，在日常工作中，程序就会比原来跑得轻松许多哦。
1、如果你知道想要查询的数据只有一条结果的话，在SQL后面加上limit 1
如果在业务系统中，已经决定了数据只有一条，比如说，我们要查找身份证号为XXX的某个人，我们知道是只有一个人的，但是数据库并不知道，所以显式的告诉数据库，找到了，别在往下找了，让它主动停止游标的移动。
2、尽管避免使用Select * ，如果需要查询所有字段，将字段名显式的写在SQL里
很多时候，我们为了方便，喜欢写Select * ，但是在MySQL里，使用*后会不使用索引，触发全表扫描，导致效率降低。

3、在业务层进行计算，避免使用数据库层进行计算
很多时候，我们喜欢采用SQL自带的函数进行计算，比如说在SQL里用函数直接获取当前时间。这种最好在业务层计算出当前时间，然后把当前时间作为参数传入SQL 。这样可以节省数据库CPU ，而且在多次传入的SQL相同的情况下，还可以利用查询缓存。
4、能用union all的场景尽量不用union
sql语句使用union关键字后，可以获取排重后的全并数据。而如果使用union all关键字，可以获取所有数据，包含重复的数据。排重的过程需要遍历、排序和比较，它更耗时，更消耗cpu资源。所以如果能用union all的时候，例如说在业务层已经知道两个表的数据不会有重合，或者说重复的数据对业务层来说不影响，那么就尽量不用union 。
5、利用小表驱动大表，而不是反过来
业务应用中，我们经常会用到查询一个表中的数据在另一个表中出现过的情况，例如有order和user两张表，其中order表有10000条数据，而user表有100条数据。如果想查一下，所有有效的用户下过的订单列表。可以使用in关键字实现：
select * from order where user_id in (select id from user where status=1)
在这种情况下，写在子查询里的语句尽量采用小表，因为SQL会优先执行in里面的子查询，如果in里面的数据量少，作为条件查询，速度会更快。
6、使用批量插入，而不是一条条插入
在很多情况下，我们需要循环一些内容，然后将数据插入到数据库中，那么，如果我们在循环过程中一条条插入，效率会么低，这种情况下，我们需要使用批量插入，类似于：
insert into order(idcodeuser_id) values(112'001'100)(125'002'100)(425'003'101);
7、如果业务涉及的大部分是单条查询，用Hash索引，而不是B-Tree索引
因为Hash索引的查询时间复杂度是O(1) ，而B-Tree是O(log(n)) ，所以如果业务涉及的大部分是单条数据的查询的话，用哈希索引效率会更高。
8、尽量使用varchar类型而不是char类型
char表示固定字符串类型，该类型的字段存储空间的固定的，会浪费存储空间。 varchar表示变长字符串类型，该类型的字段存储空间会根据实际数据的长度调整，不会浪费存储空间。因此，在非固定长度字符串的列，尽量使用varchar 。
9、选择数据库字段类型的一些规则
【数据库|特别有用的SQL优化小技巧，了解之后程序性能大为提升】遵循一些规则，会使我们的数据库表运行更加高效，一些通用的规则包括：
u 能用数字类型，就不用字符串，因为字符的处理往往比数字要慢。
u 尽可能使用小的类型，比如：用bit存布尔值，用tinyint存枚举值等。
u 长度固定的字符串字段，用char类型。
u 长度可变的字符串字段，用varchar类型。
u 金额字段用decimal ，避免精度丢失的问题。
10、先缩小数据范围，再进行group by
很多情况下，我们的业务场景需要使用group by关键字，用于去重和分组。通常它会跟having一起配合使用，表示分组后再根据一定的条件过滤数据。但是分组是一个相对耗时的操作，因此，我们可以先缩小数据的范围，然后再分组，以优化SQL的性能。类似于