©2020-2024 ioDraw All rights reserved
前言
阿里巴巴的代码规范中有一条就是不建议执行三张表以上的多表联合查询，因为对数据量不大的应用来说, 多表联合查询开发高效, 但是多表联合查询在表数据量大,
并且没有索引的时候, 如果进行笛卡儿积, 那数据量会非常大, sql 执行效率会非常低，所以我们更建议多次单表查询然后在service中进行拼接参数
多次单表查询在 service 层进行合并优点
1, 缓存效率更高, 许多应用程序可以方便地缓存单表查询对应的结果对象. 如果关联中的某个表发生了变化, 那么就无法使用查询缓存了, 而拆分后,
如果某个表很少改变, 那么基于该表的查询就可以重复利用查询缓存结果了.
2, 多表信息联合的列表页面分页显示, 只需要显示一部分的数据, 如果是多表联合查询那要把所有数据联结查出来再执行 limit, 如果是多次单表查询,
先对单表进行筛选, 先执行 limit 再与其余表去关联, 数据量会大大减小
3, 如果数据库没有进行读写分离 (主从备份), 在并发量高的时候, 由于写表会加排他锁, 把多表联合查询改成单表查询后锁的粒度变小, 减少了锁的竞争
4, 在数据量变大之后, 普遍会采用分库分表的方法来缓解数据库的压力, 采用单表查询比多表联合查询更容易进行分库, 不需要对 sql 语句进行大量的修改,
更易扩展. 分库分表的中间件一般对跨库 join 都支持不好
5, 查询本身效率也可能会有所提升. 查询 id 集的时候, 使用 IN() 代替关联查询, 可以让 MySQL 按照 ID 顺序进行查询,
这可能比随机的关联要更高效.
6, 业务高速增长时, 数据库作为最底层, 最容易遇到瓶颈, 单机数据库计算资源很贵, 数据库同时要服务写和读, 都需要消耗 CPU,
为了能让数据库的吞吐变得更高,
而业务又不在乎那几百微妙到毫秒级的延时差距, 业务会把更多计算放到 service 层做, 毕竟计算资源很好水平扩展, 数据库很难啊, 这是一种重业务, 轻
DB 的架构
7, 可以减少冗余记录的查询, 在应用层做关联查询, 意味着对于某条记录应用只需要查询一次, 而在数据库中做关联查询, 则可能需要重复地访问一部分数据.
更进一步, 这样做相当于在应用中实现了哈希关联, 而不是使用 MySQL 的嵌套循环关联. 某些场景哈希关联的效率要高很多.
多次单表查询在 service 层进行合并缺点
1, 需要进行多次的数据库连接
2, 代码更复杂
总结
个人觉得还是做多次单表查询更好, 更易扩展, 当然数据量不大时, 直接联合查询开发更方便
你还没有登录，请先使用 QQ登录 或 注册！
文章评论
发表评论