方案一：

如你所说，用父子关系去定义，再用whereIn查询。树关系可以缓存

方案二：

人和公司关系可以往上级公司做同步就可以了。

如果不想使用 whereIn ，可以保存下二级代理和其三级分公司下用户之间的关系，冗余字段或是新增一个表

新建个关系表比较好，更灵活，扩展性更好。

表：relation

{
user_id,//当前用户id
user_level,//当前用户等级
ancestor_id,//祖先id
ancestor_level,//祖先等级
deep,//第几代，上级是1，上上级是2，以此类推。
}

从关系表筛选出符合条件的人的id，然后拿去用户表in查询。
$uid = 1000;

select user_id from relation  where ancestor_id = {$uid} and user_level = 3 and deep < 3;

如果后续方便查询，可以在用户表上面新增两个字段 一个父级id，一个顶级id，然后你只需要保证父级id是自己上级就行，刚做了一套三级代理的系统，这样确实查询很方便
比如要顶级要查看二级三级代理的订单等,当然用的 whereIn

这个地方属于树桩结构的话题，正好我最近有在研究，直接分享出来（更深度的了解参考：《SQL 反模式》 第三节 简单的树）：

一般比较普遍的就是四种方法：（具体见 SQL Anti-patterns这本书）

Adjacency List：每一条记录存parent_id

Path Enumerations：每一条记录存整个tree path经过的node枚举

Nested Sets：每一条记录存 nleft 和 nright

Closure Table：维护一个表，所有的tree path作为记录进行保存。

邻接表

邻接表是存储树形结构最普通的一种方案了，通过添加 parent_id 字段来确定树的父子关系。

递归查询

SQL Server 2005、Oracle 11、IBM DB2 和 PostgreSQL 8.4 这些数据库都支持递归查询，而 MySQL、SQLite 和 Infomix 是少数不支持的数据库。

如果递归查询语法被所有主流数据库所支持，那么使用邻接表的设计不会再有这么多限制了。

路径枚举

接表的问题之一是从树中获取一个给定节点的所有祖先开销很大。路径枚举的设计通过将所有的祖先信息联合成一个字符串，并保存为每个节点的一个属性，很巧妙的解决了这个问题。

在 path_comment 表中，我们使用 path 字段来代替原来的 parent_id 字段，将从这个结点开始到最顶级节点的所有 id 存储起来，就像文件目录一样。

根据你自己的业务选择合适的模式。你这里将来可能是无限递归（目前是三级，可能未来有多级？），可以优先考虑路径枚举；如果固定层级就是三级，衔邻表还是不错的选择。