@CRVV 如果按你说的场景并且只能局限于此，的确只能 BigQuery 了。但我还是比较好奇在实际场景中，遇到这种 BigQuery 是几乎开放式的（多用户或多进程可同时进行请求），这时候还能这么搞？（我实际项目中反而遇到很多这种用户可能会频繁访问 BigQuery 的情景）
我理解中的“分步处理”不是为了“代码比较好懂”而是为了“不让 mysql 高负荷运行复杂查询“，维护简单的 sql 查询比较容易（比如简单的索引组合，分表之类），但 BigQuery 的查询维护就变得很难把控。
在结合一些实际业务情况，我或者会考虑这些：
1 、针对查询业务做一个汇总表，并动态更新，这相当于持久化的热缓存了；
2 、尽量减少搜素条件需求，或针对搜索条件对分步查询进行调整；
3 、慎重考虑分页。分析 BigQuery 过程其实很多情况下（特别是排序），sql 已经把相关数据全部扫描了，然后我们只取部分数据（估计考虑数据传输压力到中间层），我觉得这种情况不如“不分页查询”。数据库和中间层之间数据传输压力（如 in 查询的数量限制也算是），可以尝试在分步处理的各个步骤当中再进行”分步查询“，中间层和客户端层之间的传输压力，那就甩锅给带宽吧（ nginx 已经有数据压缩传输处理了，不想管了）
总结我对 BigQuery 的使用场景是：业务量不大，且让业务快速到位。
以上，个人鄙见