互联网产品后台开发能不能使用关联查询

Question

O2O App 后台, 开发过程中经常有这么一个疑问 到底能不能使用关联查询?

比如将某一个用户临时性的禁用一段时间, 等到期后再自动恢复, 只有在禁用表中且仍为禁用状态的用户才能恢复成正常状态, 因为禁用状态中的用户也可能被注销.

是一条关联查询呢?如

select ud.user_id from user_disabled ud, user u where ud.user_id = u.id and u.status = 'disabled'

还是两次单表查询
先查询出那些被禁用的用户

select user_id from user_disabled;

再根据上述的用户ID列表查询用户表

select * from user where id in (...);

结束禁用恢复正常状态前 需要判断用户状态 是否仍为禁用状态

同事的意见是

长期看，有跨表查询不利于分库分表，弊端很多
数据库压力很大，往往会成为性能瓶颈，尤其是跨表查询，一个数据量很大的表跨表查询或者join是很耗时的
不要用跨表查询，凡是跨表查询，都可以分成两个查询语句或者多个查询语句搞定，让业务代码来处理逻辑。

但有时候关联查询的结果集很少(如分页), 如果分成多次单表查询的话, 中间可能会返回很大的临时对象 如先查询出所有用户再将用户ID列表作为查询条件查询另一张表 这时可能只返回很少的数据 如一页10条 那么这之前的临时用户对象对内存也是很大的压力 另外用户ID列表如果有上千个的话 估计对数据库压力也不小

我现在的疑问是 互联网产品的日常开发中 到底该怎么抉择, 是毋庸置疑的一股脑的使用单表查询呢? 还是酌情处理? 假如酌情处理的话 标准是什么呢? 表数据量吗?

Answer 1

我觉得一条sql查询总比多条sql查询快

性能遇到瓶颈可以读写分离 不一定要分库分表