前端查询业务场景SQL优化

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

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

实际案例：

一个输入框支持输入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文件中标签）

前端查询业务场景SQL优化

悦读