database per service 落地需确保每个服务独占逻辑数据库（独立实例优先，共用实例时须严格按 schema 隔离并限制权限），go 中通过单 db 实例注入、dsn 校验、静态检查防越界，跨服务查询用 api 调用、冗余字段或读服务替代 join，迁移时清理共享表、禁用外键、双写过渡并明确数据所有权。
微服务拆分后，database per service 怎么落地
不是每个服务建个 MySQL 实例，而是每个服务独占一个逻辑数据库（schema 或独立实例），且不与其他服务共享表、视图或事务。关键在「隔离边界」——服务只能访问自己库里的表，连 JOIN 跨库都不允许。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 用独立数据库实例最稳妥（比如每个服务配一个
mysql://user:pass@host:3306/svc_order），避免 schema 级隔离带来的权限误配和备份耦合 - 若资源受限必须共用实例，至少为每个服务创建独立
schema，并通过 DB 用户权限严格限制：只授予该用户对对应schema的SELECT/INSERT/UPDATE/DELETE，禁用CREATE和跨 schema 查询 - 禁止在代码里拼接多库连接，也别用 ORM 的“多数据源自动路由”功能来模拟跨库操作——这会悄悄破坏边界
Golang 里怎么确保服务不越界访问其他库
Go 没有语言级访问控制，全靠工程约束。一旦某个 repository 包意外引入了另一个服务的 *sql.DB，运行时根本不会报错，但会埋下强耦合隐患。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 每个服务的
internal/repository目录下只初始化一个*sql.DB实例，通过依赖注入传入，绝不暴露全局变量或从配置中心动态加载其他库连接 - 在
main.go初始化 DB 时，显式校验 DSN 中的 database 名是否匹配服务名（比如svc_user服务只接受dbname=svc_user） - CI 阶段加静态检查：用
go list -f '{{.Deps}}' ./... | grep 'other-service-repo'防止误引入其他服务的数据访问层代码
跨服务查数据时，JOIN 消失了，该怎么替代
以前单体里一句 SELECT u.name, o.total FROM users u JOIN orders o ON u.id = o.user_id，现在得拆成两步：先查 users 服务接口拿 name，再查 orders 服务接口拿 total，最后在调用方合并。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 优先用最终一致性 + 缓存冗余字段：比如订单服务在创建订单时，同步写入一份
user_name到orders表里，避免每次查订单都要调用户服务 - 聚合查询场景（如管理后台）可设专用读服务（
report-service），它自己拉取多个服务的数据，写入独立报表库，不参与核心链路 - 不要用「同步 HTTP 调用 + context.WithTimeout」硬凑实时 JOIN —— 一个下游慢，整个请求就卡住；更别用分布式事务框架（如 Seata）强行保 ACID，违背了微服务解耦初衷
迁移老系统时，database per service 最容易踩的坑
不是技术实现难，是旧数据和旧逻辑甩不干净。常见错误现象：ERROR: relation "shared_config" does not exist（还在查公共配置表）、或迁移后发现账单服务更新了用户余额却没通知用户服务，导致状态不一致。
实操建议：
立即学习“go语言免费学习笔记（深入）”；
- 先识别所有跨服务共享的表（尤其是
sys_config、file_meta、tenant_info），逐个判断：能拆？能复制？还是必须转成 API？别留“暂时共用”的尾巴 - 迁移期间双写过渡：新服务写自己的库，同时发消息到 MQ 让老服务同步更新旧库（仅限过渡期），并监控双写失败率；上线后立刻下掉旧写路径
- 特别注意外键约束——原库的
FOREIGN KEY (user_id) REFERENCES users(id)在拆库后必须删掉，否则 DDL 会失败；应用层改用逻辑校验或最终一致性保障
真正难的从来不是建几个数据库，而是让团队所有人对“这个表谁负责、谁有权改、出问题找谁”达成无歧义共识。只要有一处模糊地带，半年后就会变成线上事故的温床。
