唯一真正隔离的方案是为每个业务模块建独立数据库、独立账号并仅授本库必要权限；共用一个库时information_schema.tables会暴露全部表名，且跨表授权无法阻止越权查询，应用出错或注入即可猜到其他模块表结构。
唯一真正隔离的方案是为每个业务模块建独立数据库、独立账号并仅授本库必要权限；用前缀表+全库授权，等于没隔离。
为什么不能共用一个数据库配多个账号
共用一个库时，哪怕给不同账号授不同表权限，information_schema.tables仍会暴露全部表名，应用一旦出错或被注入，就可能猜到其他模块的表结构；更关键的是，GRANT SELECT ON db1.orders, db1.users这种跨表授权无法阻止账号执行SELECT * FROM users——只要它有db1.users的SELECT权限，就能查。
-
SHOW DATABASES会列出所有库名（这是MySQL默认行为），但不代表能访问；真正的隔离靠GRANT语句限定作用域 - 共用库加
module_id字段做逻辑过滤，依赖应用层100%正确拼WHERE条件，漏一次就全盘失效 - 视图带变量（如
@current_module）在连接池复用场景下极易残留值，生产环境几乎不可靠
必须成对执行CREATE DATABASE与CREATE USER
模块库和账号必须一一绑定，不能先建库再“统一授权”。常见错误是建完db_order、db_user后，给一个账号授ON *.*或ON `db_%`.*——这会让权限跨域失效。
- 建库时指定字符集：
CREATE DATABASE db_order CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci; - 建账号必须带具体
host，禁用'%'（除非走跳板机）：CREATE USER 'app_order'@'10.20.30.%' IDENTIFIED BY 'strong-pass-2026'; - 授权只写明库名，不加通配符：
GRANT SELECT, INSERT, UPDATE ON db_order.* TO 'app_order'@'10.20.30.%'; -
FLUSH PRIVILEGES在正常GRANT后非必需，但显式执行更稳妥（尤其MySQL 5.7+部分操作自动刷新）
跨模块读取数据必须绕过GRANT
订单服务要查用户昵称，不代表它该有db_user的任何权限。一旦授了，就等于把整个用户库暴露给订单模块。
- 优先走API：
GET /api/v1/users/{id}/basic，由用户服务提供，订单服务调用HTTP - 次选只读视图（仅限低延迟强耦合场景）：
CREATE VIEW order_user_info AS SELECT id, nickname FROM db_user.users; - 视图必须在本库（
db_order）中建，并显式授权：GRANT SELECT ON db_order.order_user_info TO 'app_order'@'10.20.30.%'; - 严禁
DEFINER = 'root'@'%'：否则低权限账号可借root身份执行任意逻辑
权限验证不能只看GRANT语句
很多人执行完GRANT就以为完事了，结果应用连不上或报错Access denied for user，往往卡在细节上。
- 用对应账号登录：
mysql -u app_order -p -h 10.20.30.5，确认能连 - 执行
SHOW DATABASES;：应只看到db_order（其他库名会显示但无法访问，这是正常行为） - 切换库：
USE db_order;成功，USE db_user;应报错Access denied - 查表：
SELECT * FROM users LIMIT 1;成功；DROP TABLE users;应报错ERROR 1142 (42000): DROP command denied
生产环境必须禁用WITH GRANT OPTION和全局权限——哪怕只是临时加一个，都可能被误用来创建子账号、越权建库。
