我在不同的公司都遇到同一个问题，就是如何用统一的用户表来存储不同业务的用户

@wushigejiajia01 没错，WordPress 就是这样实现的，一张 user 表，一个 user_meta 表。理论上可以无限扩展，缺点就是经常要关联查询

建议业务不明确或变化快时，能不拆就不拆，通过附属表的一个一段区分业务类型，数据库字段名称用 string1,int1 之类的代替，再用 orm 映射成有意义的名称。这样多个附属表就合并成了一个表。
后面业务量大或者业务稳定明确，再拆分也不迟。

只有用户身份标识统一，其他的无需统一

人员，身份，等级，部门，这些可以认真模仿一下现实世界。

是这样的，如果你的业务需求是单个用户账号可能存在多个角色时，那么放在一张表是比较合适的场景，比如一个商户账号既是商户，又是运维。这种情况下就比较适合单表存储，另外开设角色表和角色对应的权限表。
而如果你的业务需求是各个角色涉及的业务操作完全不一样，那么直接开多个表即可，将不同用户账户的服务完全隔离开，比如商户方单独有商户的服务，用户单独用户的服务，运维单独运维的服务，这样既减少了鉴权的请求，同时也更容易理解数据的边界。

建立一个基础的用户表，这个表只存放所有角色都需要用到的字段，例如名字，密码，电子邮件，手机号......
其余的字段按照不同的角色划分，例如供应商表存放发货地址，收款账号，等等。
我之前也一直觉得，扩展性的意思是见了一个表用一辈子，有业务需求的时候不改最佳。
但是这个世界是变化的，扩展性最佳的例子，其实是建立起一个额外的表，然后对应的 CRUD 。

维护系统的人 和 使用系统的人，这 2 类账号最好还是分离

用 mongo， 扩展也方便。

这是到处挖坑啊

单个表大了索引会很慢的

强行统一意义何在
在你觉得都是用户（因为最终是对应具体的物理人？？？），可是换个角度看根本就不是不同 entity

NoSql 不就行了吗？想怎么来怎么来

@icerhe 老哥的回答非常好，有理有据。另外这个题主真的差，自己回贴竟然是十分钟了。

一个用户表+一个角色表，可行不

用户表的设计说简单也简单，说复杂也复杂，具体需要看业务需求：不仅要看现在的需求，还要看未来的需求。例如，如果当前的系统无论如何发展都不会和其它系统关联数据，或者用户在系统中只能有一个手机号、且历史手机号记录永远没有价值等等，这时我们就可以考虑用户用单表、且直接包含所有属性字段。但如果不是，例如系统必然会和其它产品数据连接，如 OA 系统一般都会和 HR 系统、财务系统、CRM 系统等等系统连接，或者用户可以有多个手机号记录，例如做业务回溯时必须对应办理业务时的手机号、或者是个充值系统等等，这时就必须用主表+属性表的形式。
至于到底要不要做用户表合并，也是同样的思路：看业务需求，包括当前的和未来的。

@594duck 你有问题吧 我顶个贴有什么关系 不然早沉下去了 而且虽然回复很多但是并没有我满意的答案 我的方案也是通用用户表加角色子表 只不过现在我想通过 json 类型把子表直接放在通用表里面 这样避免 crud 用户数据涉及到多个表

@LokiSharp 我巴不得用户表大到索引很慢的程度 这样我工资就起飞了

@Yuicon 用 json 存有隐患的

后期如果有需要做搜索或者筛选条件用到了 你说的“子表”信息字段，那就完蛋

不要相信产品说的“以后不会用这些信息做查询筛选的”，

我以前经历过，真的很痛苦

@wushigejiajia01 这我调查过的 本来准备用 es 或者阿里云的 opensearch 解决 后来发现 mysql 本身就支持 可以正常查询的 而且效率还可以 我创建了 10w 条 查 json 里的某个字段 也只要 100ms 左右（辣鸡测试数据库）