|
古人讲，“不积跬步，无以致千里”。编程也是一样，所有的小的性能优化点都做到了最优，最终的运行效果可能比没有做优化提升数百倍。尤其是在一些你并不知道哪个地方会让程序变得缓慢的情况下。因此，掌握一些最基本的优化小技巧，并且把它们变成自己工作习惯的一部分，会减少很多不必要的潜在麻烦。 那么今天我们就来科普一些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(id,code,user_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、选择数据库字段类型的一些规则 遵循一些规则，会使我们的数据库表运行更加高效，一些通用的规则包括： u 能用数字类型，就不用字符串，因为字符的处理往往比数字要慢。 u 尽可能使用小的类型，比如：用bit存布尔值，用tinyint存枚举值等。 u 长度固定的字符串字段，用char类型。 u 长度可变的字符串字段，用varchar类型。 u 金额字段用decimal，避免精度丢失问题。 10、先缩小数据范围，再进行group by 很多情况下，我们的业务场景需要使用group by关键字，用于去重和分组。通常它会跟having一起配合使用，表示分组后再根据一定的条件过滤数据。但是分组是一个相对耗时的操作，因此，我们可以先缩小数据的范围，然后再分组，以优化SQL的性能。类似于 select productid, orderamount from order where orderamount <= 200 group by productid 这就是一些做数据库开发时常用的小技巧，朋友们，你们还有什么优化技巧呢？欢迎在评论区写出来哦。 |
|
|
