MySQL 业务数据边界

MySQL 是这套系统的业务数据后端，保存用户、商品、订单、订单明细和邮件记录。微服务拆分后，数据库仍然承担“事实来源”的角色，接口返回只是数据的某种投影。

一、数据源配置

spring:
  datasource:
    driver-class-name: com.mysql.cj.jdbc.Driver
    url: jdbc:mysql://127.0.0.1:3306/spring_cloud_alibaba?serverTimezone=Asia/Shanghai&sslMode=REQUIRED

https://github.com/springvortex/spring-cloud-alibaba/blob/release/v1.0.0/service-provider/src/main/resources/application-prod.yaml

开发环境和生产环境只有地址、端口和认证配置不同，数据库命名和表结构保持同一套约定。

二、表结构跟随业务模块

主要表包括：

• t_user
• t_goods
• t_order
• t_order_detail
• t_mail_log

订单主表和明细保存在同一事务里，邮件发送则先落库待发送状态，再更新成功或失败。这说明数据库不只是 CRUD 存储，也参与业务一致性。

三、访问原则

1. MySQL 只被 Provider 和 Mail 直接访问。
2. Gateway 和 Consumer 不直连业务库。
3. 跨服务数据通过接口契约获取，不跨库 join。
4. 内部字段不直接暴露为 API 模型。

四、避坑点

1. 连接地址、账号和密码属于环境差异，不应复制到公共配置。
2. 敏感密码使用 Jasypt 密文，密钥另从环境注入。
3. 逻辑删除会影响唯一索引和查询条件。
4. 当前仓库没有数据库初始化 SQL，换环境前要先准备表结构。

五、经验总结

MySQL 是系统事实的落点。让数据库访问收敛在具体业务服务内，服务边界才不会被一条跨模块 SQL 悄悄打穿。