关注
鸿蒙技术社区
，回复
【鸿蒙】
送
价值
399元
的鸿蒙
开发板套件
（数量有限，先到先得）
，还可以
免费下载
鸿蒙
入门资料
！
👇
扫码
立刻关注
👇
专注开源技术，共建鸿蒙生态
大家如果是做后端开发的，想必都实现过列表查询的接口，当然有的查询条件很简单，一条 SQL 就搞定了。
图片来自 Pexels
但有的查询条件极其复杂，再加上库表中设计的各种不合理，导致查询接口特别难写，然后加班什么的就不用说了（不知各位有没有这种感受呢~）。
下面以一个例子开始，这是某购物网站的搜索条件，如果让你实现这样的一个搜索接口，你会如何实现？
当然你说借助搜索引擎，像 Elasticsearch 之类的，你完全可以实现。但我这里想说的是，如果要你自己实现呢？
从上图中可以看出，搜索总共分为 6 大类，每大类中又分了各个子类。
这中间，各大类条件之间是取的交集，各子类中有单选、多选、以及自定义的情况，最终输出符合条件的结果集。
好了，既然需求很明确了，我们就开始来实现。
率先登场是小 A 同学，他是写 SQL 方面的“专家”。小 A 信心满满的说：“不就是一个查询接口吗？看着条件很多，但凭着我丰富的 SQL 经验，这点还是难不倒我的。”
于是乎就写出了下面这段代码（这里以 MySQL 为例）：
select ... from table_1
left join table_2
left join table_3
left join (select ... from table_x where ...) tmp_1
...
where ...
order by ...
limit m,n
代码在测试环境跑了一把，结果好像都匹配上了，于是准备上预发。这一上预发，问题就开始暴露出来。
预发为了尽可能的逼真线上环境，所以数据量自然而然要比测试大的多。所以这么一个复杂的 SQL，它的执行效率可想而知。测试同学果断把小 A 的代码给打了回来。
总结了小 A 失败的教训，小 B 开始对 SQL 进行了优化，先是通过了 explain 关键字进行 SQL 性能分析，对该加索引的地方都加上了索引。
同时将一条复杂 SQL 拆分成了多条 SQL，计算结果在程序内存中进行计算。
$result_1 = query('select ... from table_1 where ...');
$result_2 = query('select ... from
