开发者社区> 问答> 正文

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的低?

展开
收起
落地花开啦 2016-02-18 13:27:11 4247 0
1 条回答
写回答
取消 提交回答
  • 喜欢技术,喜欢努力的人

    保存上级的所有id格式",0,1,2,3,5,8,9,10,999,"
    只能说, 这会让你的业务代码增加N倍, 你得考虑假如上级变更, 删除, 增加后, 你得同时修改多少家下下家? 比如省长级别增加一个副省长, 那下面的市长, 镇长, 村长都得更改.
    个人觉得还是无限分类比较好, where in之后的结果可以cache起来.

    2019-07-17 18:43:53
    赞同 展开评论 打赏
问答排行榜
最热
最新

相关电子书

更多
2022 DTCC-阿里云一站式数据库上云最佳实践 立即下载
云时代的数据库技术趋势 立即下载
超大型金融机构国产数据库全面迁移成功实践 立即下载

相关镜像