必须使用独立数据库账号——未做逻辑隔离时共用账号会导致权限越界、溯源失效和安全风险，MySQL需按服务建最小权限账号并限制连接数，PostgreSQL须通过schema隔离并回收public权限，账号生命周期须与服务发布同步管理。
微服务该不该用独立数据库账号
该。不是“建议”，是必须——只要数据库没做逻辑隔离（比如 postgresql 的 schema 级权限或 mysql 8.0+ 的 dynamic privileges 配合 roles），共用账号就等于把订单服务的 delete from users 权限，悄悄塞给了日志服务。
常见错误现象：Access denied for user 'svc_common'@'%' 看似是权限问题，实际是账号复用后被某个服务误删了权限表；更隐蔽的是，审计日志里根本分不清哪条 UPDATE order_status 来自支付服务、哪条来自风控服务。
核心原因就一条：数据库连接池、SQL 日志、慢查分析、甚至 WAF 拦截记录，全靠账号名溯源。没有独立账号，等于在生产环境蒙眼开车。
MySQL 8.0+ 怎么建最小权限账号
用 CREATE USER + GRANT 组合，但必须避开两个坑：一是别用 GRANT ALL ON <em>.</em>，二是别漏掉 USAGE 默认权限导致后续 GRANT 失效。
实操建议：
- 账号命名直接体现服务名，比如
svc_payment_v1，避免payment_rw这类模糊命名 - 只授权具体库+表，例如
GRANT SELECT, INSERT, UPDATE ON payment_db.orders TO 'svc_payment_v1'@'%' - 显式拒绝危险操作：
DENY DROP ON payment_db.* TO 'svc_payment_v1'@'%'（MySQL 8.0.16+ 支持） - 设连接限制：
ALTER USER 'svc_payment_v1'@'%' WITH MAX_CONNECTIONS_PER_HOUR 120，防连接泄漏拖垮实例
PostgreSQL 怎么限制 schema 访问范围
PostgreSQL 没有“库级”概念，靠 schema 隔离。但默认所有用户都能看到 public schema，这是最大陷阱。
关键点在于三步缺一不可：
- 为每个服务建专属 schema，比如
CREATE SCHEMA payment AUTHORIZATION svc_payment - 回收 public schema 的使用权限：
REVOKE USAGE ON SCHEMA public FROM PUBLIC - 给服务账号只授对应 schema 权限：
GRANT USAGE ON SCHEMA payment TO svc_payment，再单独授表级SELECT/INSERT
漏掉第二步，svc_inventory 就能通过 SELECT * FROM public.users 直接跨查——哪怕它根本没被显式授权。
账号生命周期怎么和微服务发布对齐
数据库账号不能手工建完就扔着。服务下线、分支合并、灰度回滚时，账号若残留，就成了永久后门。
实操要点：
- 账号创建必须走 IaC 流程，比如 Terraform 的
mysql_user资源块，和应用部署流水线绑定 - 服务停用前，先执行
DROP USER 'svc_legacy_report'@'%'，再删代码；别反过来 - 测试环境账号加后缀
_stg，且密码定期轮换（用 Vault 或 Secrets Manager 注入，不硬编码） - 监控
information_schema.PROCESSLIST，告警长期空闲账号（如 7 天无查询）
最常被忽略的是权限回收时机——上线新版本时没人记得删旧账号，结果一个服务同时挂着 svc_order_v1 和 svc_order_v2 两个账号，其中一个权限还多开了 TRUNCATE。
