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

数据库|特别有用的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优化小技巧,了解之后程序性能大为提升】在这种情况下 , 写在子查询里的语句尽量采用小表 , 因为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 。