开发账号应仅授予SELECT和INSERT权限，严格遵循最小权限原则，从零开始按需添加，禁止使用GRANT ALL、模糊匹配或对系统库授权，并在每次权限变更后执行FLUSH PRIVILEGES。
给开发账号只开 SELECT 和 INSERT，别碰 DROP 和 ALTER
生产库上一个误操作 DROP TABLE 就可能让服务直接挂掉。最小权限不是“先给全再收”，而是从零开始加——只加当前业务逻辑真正需要的权限。
常见错误是给 dev_user@% 直接授 GRANT ALL PRIVILEGES ON app_db.*，结果连 CREATE VIEW 或 INDEX 都开了，其实接口压根不用建索引。
-
SELECT、INSERT是读写类 API 最常需要的，够用就停手 - 如果某张表要更新状态，才额外加
UPDATE，且限定字段：用GRANT UPDATE(status, updated_at) ON app_db.orders - 绝对禁止对
mysql系统库授任何权限，哪怕只是SELECT - 临时导数据用的账号，权限有效期设为 24 小时：
CREATE USER 'tmp_export'@'%' IDENTIFIED BY 'xxx' PASSWORD EXPIRE INTERVAL 1 DAY
按 schema + 表名精确授权，别用 * 模糊匹配
用 app_db.* 授权看似省事，但一旦新增敏感表（比如 user_passwords），旧账号自动获得访问权，等于埋雷。
真实场景里，订单服务和用户服务往往共用一个库，但它们的数据边界必须硬隔离。
- 明确列出每张表：
GRANT SELECT, INSERT ON app_db.orders TO 'order_svc'@'10.20.%' - 敏感表单独建 schema，比如把审计日志放进
audit_log库，再单独控制访问 IP 段 - 避免跨库权限，如
GRANT SELECT ON *.config_table—— MySQL 不支持这种写法，会静默失败 - 注意反斜杠转义：表名含短横线（
user-profile）必须用反引号：GRANT SELECT ON app_db.`user-profile`
REVOKE 后记得 FLUSH PRIVILEGES，否则权限不生效
很多人改完权限发现还是能删表，查 SHOW GRANTS FOR 'user'@'host' 却显示已回收——问题就在缓存没刷。
MySQL 的权限系统靠内存缓存生效，GRANT/REVOKE 只改磁盘上的 mysql.user 表，不自动 reload。
- 每次
REVOKE或GRANT后，立刻执行：FLUSH PRIVILEGES - 如果用的是 MySQL 8.0+，且启用了角色（
CREATE ROLE），则角色赋权后也需FLUSH - 自动化脚本里容易漏这步，建议写成函数封装：
function grant_and_flush() { mysql -e "$1"; mysql -e "FLUSH PRIVILEGES"; } - 注意：
FLUSH PRIVILEGES是全局操作，高并发时段慎用，它会短暂阻塞其他权限相关查询
连接池复用账号时，权限必须覆盖所有可能的 SQL 模式
Spring Boot 默认用 HikariCP，一个连接池账号可能被多个微服务共享。表面看只跑 SELECT，但某次慢 SQL 分析开了 EXPLAIN，或监控插件偷偷执行 SHOW PROCESSLIST，就会因权限不足报错。
这不是过度授权的理由，而是要提前识别“隐性依赖”。
- 上线前抓一次完整 SQL 日志（
general_log = ON），过滤出所有实际执行的语句类型 - 监控类账号至少需要
PROCESS权限才能查SHOW PROCESSLIST，但它属于管理权限，不能和业务账号混用 - ORM 框架可能生成
SELECT ... FOR UPDATE，这就要求账号有SELECT+LOCK TABLES（注意：后者是独立权限项） - 如果用到 JSON 字段，
JSON_EXTRACT不需要额外权限，但JSON_SET在某些版本需要UPDATE权限配合
权限设计最麻烦的地方不在语法，而在于得把代码里所有 SQL 路径、框架行为、运维动作都摊开来看——漏掉任意一种，线上就可能突然报 ERROR 1142 (42000): INSERT command denied。
