业务场景SQL优化

发布时间:2023年12月30日

理解业务场景,否定不合理的需求,正确使用数据库

满足使用方需要的功能,而不是满足使用方想要的功能


实际案例:

????????一个输入框支持输入N个条件查询

这样的输入框在APP/小程序比较常见,一个输入框支持输入多种条件进行查询,上面给出一个案例框,实际可能条件更多维度。

这种查询对应的SQL大概长这样

SELECT
    t1.*,
    t2.* 
FROM
    table_a t1
    LEFT JOIN table_b t2 ON t1.id = t2.id
    LEFT JOIN table_c t3 ON t1.id = t3.id 
WHERE
    t1.field LIKE '%赵%' 
    OR t2.field LIKE '%赵%' 
    OR t3.field LIKE '%赵%'

问题很明显,因为无法分辨输入的值到底属于什么,所以只能多张表去关联模糊查询,条件还是 或,这就造成性能低下且结果集不精准的问题


初步优化:

在界面中提供多维护输入框 且 再提供多维度类型,类似这样

先选择自己要查询的维度,再输入要查询的关键字,这样对于SQL就可以简化很多,且结果很精准

例如输入和选择的是 table_a 表中 field则SQL如下
SELECT
    t1.*,
    t2.* 
FROM
    table_a t1
    LEFT JOIN table_b t2 ON t1.id = t2.id
    LEFT JOIN table_c t3 ON t1.id = t3.id 
WHERE
    t1.field LIKE '%赵%' 

虽然结果精准了不少,查询性能也好了不少(就事论事这里不考虑like问题先),但是问题还是存在,多关联了一些表


进一步优化:

????????在不需要关联表的时候不去做关联,提升SQL性能

????????对于后台管理系统的页面主要分为三块:搜索条件、table列表、操作按钮集(删除、修改、详情等)

????????详情:table列表一般都会展示一些“相对”重要字段,详情则展示此条数据需要展示的详细字段

????????这些字段有的在 业务主表中,有的则分布在其他表中,甚至需要关联其他表做复杂的计算才能得出

思路:这里分为两种

????????1、这个字段不必要:没啥好说的,不查询不展示此字段就行

????????2、这个字段必要:在搜索条件集 和 table列表、详情都存在,但是查询这个字段非常的费事(关联表且需做计算)

????????????????a:和产品沟通将这个字段从 table列表中移除,放入详情页中---可以避免一打开此页面就需要复杂的连表计算,而打开详情页也变成了精准搜索,性能相对也就没那么差了

????????????????b:SQL层面的调整,当用户不输入此条件的查询 或 非详情查询 则不连表计算此值(xml文件中标签)

文章来源:https://blog.csdn.net/weixin_44700876/article/details/135226157
本文来自互联网用户投稿,该文观点仅代表作者本人,不代表本站立场。本站仅提供信息存储空间服务,不拥有所有权,不承担相关法律责任。