mysql数据库有关上下级的设计方案问题

现在有个应用商家可以添加下级，下级又可以添加下级相当于无限级.
商家下面有后台的操作员,有面向市场的用户，设备等
需求是当前操作的商家能够看到他下级、下下级、下下下级....的数据
现在的处理方式是：先查出当前操作商家的所有下级 id （递归出来的）
然后根据id 用where in取数据，现在发现性能很低,后来查看sql发现in后面有上千个 id 而且建立的索引页失效了
现在又想了种方法就是：商家在添加下级的时候 把他上级 上上级...的id组成字符串存储在下级的某个字段里如:当前商家的id为1000，它的上级的所有id格式",0,1,2,3,5,8,9,10,999,"那么他的下级就是",0,1,2,3,5,8,9,10,999,1000" 假如现在有个商家3要查看他所有下级的数据 就用 like '%,3,%' 取数据后来想到like的这种方法索引不能生效，可能效率低，就用全文索引。当时，我现在做了测试数据，用全文索引 match against的效率还不如like 的效率。
现在的疑问是为什么全文索引的效率会比like的低？