客户问我的第一个问题，不是功能

西安，一家养发馆的老板，坐下聊了不到五分钟，问了我第一个问题：你们这个系统，我这几家店的数据会不会混在一起？

我说不会。

他追了一句：怎么保证？

那一刻我才反应过来，多租户根本不是个技术题。它是销售题。客户不关心你用什么架构，他关心的是隔壁那家店的会员手机号，会不会出现在他店长的手机里。

我是一个人做这套门店 SaaS 的，SpringBoot4 加 Vue3，在开源项目上二次开发，从养发起步，后面要扩到理发、美容、西服定制。

所以我要选的不是"最安全"的方案。是我一个人扛得住的方案。

先说结果：三种方案，我全推演过

行业里主流的就三种。AWS 的 SaaS 存储白皮书把它们叫 silo、bridge、pool，翻译过来就是独立库、共享库独立 Schema、共享表加租户字段。

我选了第三行。也就是最土的那一个。

方案一：独立库——隔离最强，也是我最先否掉的

一个客户一个数据库。这个方案的好处是实打实的：数据物理分开，备份按客户走，某个客户要导出全部数据带走，一条命令的事。金融、医疗这类场景，它几乎是唯一选项。

问题也在明面上。

我按 20 个客户推演了一遍。改一次表结构，我得在 20 个库上各跑一次迁移脚本。备份是 20 份。监控是 20 套。连接池里躺着 20 条空闲连接。

AWS 生态的咨询方给过一个量级估算：独立库模式下，一个租户的最低可用栈（小型 RDS 实例 + 两个容器任务 + 负载均衡 + NAT 网关）大概 250 到 400 美元一个月。20 个客户就是 5000 到 8000 美元，还没算应用本身的成本。共享池模式下，同样规模的总成本大概 800 到 1200 美元，摊到每个客户是 8 到 12 美元。

（这是第三方估算，不是 AWS 官方报价，你按自己的云厂商重算一遍。）

数字是一回事，更要命的是人。我一个人，没有 7×24 值班。凌晨两点一个客户的库挂了，我得先搞清楚是哪个库。

方案二：Schema 隔离——看着折中，坑最隐蔽

共享一个数据库实例，每个客户一个 Schema。听起来是完美折中：隔离比共享表强，成本比独立库低。

我先说 MySQL。在 MySQL 里，Schema 就是 database 的同义词。所以所谓"共享库独立 Schema"，在 MySQL 上基本等于方案一，只是少了几块钱的实例费。

再说真问题：漂移。

我这个项目的表结构全靠 Flyway 脚本管，现在是 11 个版本、1605 行。共享表模式下，这套脚本跑一遍就完事。Schema 隔离模式下，它得在 N 个 Schema 上各跑一遍，而且必须全部成功。

只要有一次，某个客户的 Schema 因为磁盘满、连接断、或者我手滑漏了一个，它就跟其他客户再也对不齐了。这个偏差不会立刻报错，它会在三个月后某次查询里冒出来，而我早忘了当初漏过一次。

这事我踩过类似的。所以我直接否掉了。

方案三：共享表 + tenant_id——最土，也最适合一个人

所有业务表带一个 tenant_id 字段，所有查询带上它。就这一招。

风险只有一个，但很致命：漏写一次，就穿了。一条统计 SQL 忘了加 WHERE tenant_id = ?，A 店的营业额里就混进了 B 店的数字。

所以我不靠自觉。自觉是最靠不住的东西，尤其是凌晨一点改 bug 的时候。

我上了三道防线：

第一道是主力。MyBatis-Plus 有现成的多租户拦截器，配一次，全项目生效。PostgreSQL 那边还有更硬的做法：开行级安全策略，并且加 FORCE ROW LEVEL SECURITY——连表 owner 都会被拦，代码写错也拿不到别家的数据。

第三道最容易被省掉。但它是唯一能在"我改了三个月代码"之后还替我把关的东西。

权限我不建 RBAC 表，五档写死

另一个不那么主流的选择：我没有做角色权限配置表，五种角色直接写死在代码里。

理由是门店这个场景，角色就那么几个：老板、店长、收银、技师、还有我这个运维账号。做成可配置的，收益是"理论上更灵活"，代价是我要再维护一张表的增删改查、一套前端配置界面、以及客户打电话问我"这个权限为什么勾不上"。

写死的代价是加一档要改代码。我算过，这事一年未必发生一次。

一人公司做架构，最不缺的是"看起来更专业"的选项，最缺的是有人替你接工单。

逃生通道：大客户要独立，我怎么接

我选共享表，还有一个理由，比省钱更重要——它最好退。

tenant_id 从第一天就在每一张表上。哪天真来一个大客户，合同里写着"数据必须独立存储"，我要做的不是重构，是给它单独起一个实例，把这个租户的数据迁过去，数据源路由改一行。

反过来的路走不通。从独立库退回共享库，那是重写。

这就是我判断方案的第二个标准：不是看它现在最合适，是看它将来最好改。

大部分人认为隔离越干净越好，我判断是反过来的

行业里的默认叙事是：隔离级别越高，架构越先进，越能卖进大客户。

我这半年推下来，判断刚好反过来——在你没有运维团队的时候，隔离级别越高，你死得越快。

依据不是理论，是我自己的排期。我一个人每周能分给这套 SaaS 的时间大概 20 小时，其中至少三分之一要花在部署、备份、答疑上。独立库会把这三分之一抬到一半以上，而多出来的这部分，不会变成任何客户愿意付钱的功能。

客户问的从来是"会不会混"，不是"是不是独立库"。前者靠三道防线能答，后者靠烧钱才能答。

如果你和我一样，一个人做 To B

别急着定架构。先做一件事：把你下一个最可能签的客户拉出来，问一句"数据能不能放一起"。

他如果说行，你就用共享表加 tenant_id，今天就能开工。他如果说不行，你也别急着上独立库——先问清楚是合同要求，还是他自己也不太确定。

我的客户当时说的是"我不想让别人看到"，不是"我要独立数据库"。这两个要求，成本差着两个数量级。

你现在手里这套系统，租户是怎么隔的？有没有哪次漏带 tenant_id 被线上抓到过？评论区说说，我挺想知道是不是只有我这么紧张。

阅读原文：原文链接