微服务必须配独立数据库实例或Schema，数据边界须与业务边界严格对齐。实操要求包括专属配置、带服务标识的Schema名、显式连接指定、DDL含CREATE DATABASE、按访问路径而非表名分库、禁跨库JOIN但允服务间接口调用、双写迁移+校验、清除存储过程/触发器/外键。
每个微服务必须配独立数据库实例或 Schema
不是“可以”，而是“必须”。微服务的数据边界和业务边界必须严格对齐，否则后续会陷入跨库事务、数据同步延迟、DDL 阻塞全链路等不可控问题。一个服务若共用其他服务的库（哪怕只是同一个 MySQL 实例下的不同 Schema），就等于把“解耦”写在 PPT 里，实际还在共享锁、连接池和备份窗口。
实操建议：
- 新服务上线前，DBA 或平台团队必须分配专属
my.cnf配置，单独设置max_connections、innodb_buffer_pool_size，禁止沿用旧库模板 - Schema 名必须带服务标识，如
user_service、order_service，禁用模糊命名（如db_v2、new_db） - 应用连接串中
database参数必须显式指定该 Schema，不能留空或靠USE切换 - 所有 DDL 脚本需包含
CREATE DATABASE IF NOT EXISTS `user_service` CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci;，避免依赖人工建库
垂直分库 ≠ 按表名前缀切分，要看访问路径
看到 user_profile 就扔进 user_service，看到 order_detail 就塞进 order_service，这是最典型的误操作。真正决定归属的是“谁在查它、怎么查、频率多高”。比如订单服务高频 JOIN user_profile 获取昵称和头像，硬拆到用户库，要么加冗余字段，要么每次下单都调一次用户服务接口——后者在秒杀场景下直接拖垮整个链路。
实操建议：
- 用
pt-query-digest抓取一周生产 SQL，按SELECT中的FROM和JOIN表统计访问来源服务，生成热力图 - 对存在强联合访问的表（如
user_profile和order_header），先保留在同一库，后续再通过 FEDERATED 引擎或物化视图过渡 - 检查
information_schema.TABLES，优先从DATA_LENGTH + INDEX_LENGTH > 2GB的库开始切，小库先不动
禁止跨库 JOIN，但允许跨服务查数据
MySQL 层面禁止 SELECT * FROM order_service.orders JOIN user_service.users，这不是性能问题，是架构红线。但应用层调用 UserServiceClient.getUserById(123) 是完全合规的——只要这个调用走的是 HTTP/gRPC 接口或异步事件，而不是直连对方数据库。
实操建议：
- 在 ORM 层（如 MyBatis Plus）拦截器中校验 SQL，发现跨库表名立即抛
SQLException并告警 - 所有跨服务数据获取必须封装为明确语义的方法，如
OrderService.getBuyerInfo(orderId)，而非裸 SQL 拼接 - 缓存设计要覆盖这类调用，例如用
order:123:buyer_info缓存用户基础信息，避免重复请求
迁移过程必须支持双写 + 校验，不能只靠 mysqldump
停机导出导入只适用于测试环境。线上服务要求零感知迁移，否则切流瞬间就会出现订单找不到用户、支付查不到商品详情等数据不一致问题。真正的迁移不是“搬数据”，而是“搬读写逻辑”。
实操建议：
- 应用层加路由开关：老路径写原库，同时发 MQ 消息触发新库写入；MQ 消费端做幂等写入
- 用
pt-table-checksum每小时比对主键一致性，输出差异行的PRIMARY KEY值用于快速定位 - 切流前 48 小时开启只读模式，对关键表执行
SELECT ... FOR UPDATE锁定，跑最终全量比对 - 所有迁移脚本必须带分段参数，如
--where="id BETWEEN 100000 AND 200000"，避免长事务阻塞业务
最常被忽略的其实是存储过程、触发器和外键。单体库里那堆 DELIMITER $$ CREATE PROCEDURE sync_user_to_order，拆库后直接报 ERROR 1146 (42S02): Table 'old_db.user_info' doesn't exist。这些逻辑必须提前识别、重写、下线，不能指望上线后再修。
