SQL账号权限拆分需按需分配、最小权限、读写分离，区分应用/运维/分析角色，严格分离读写账号并按模块限定视图级权限，运维与分析账号须隔离访问路径，定期审计并动态回收过期权限。
SQL账号权限拆分的核心是“按需分配、最小权限、读写分离”，不是简单地给DBA一个root账号完事。关键在于区分角色（如应用连接用户、运维查询用户、报表分析用户），再结合数据库实例的读写流量特征，针对性授权。
读写账号严格分离：应用层必须用两个独立账号
应用代码中不能复用同一账号执行SELECT和INSERT/UPDATE/DELETE。生产环境应强制配置：
- 写账号（如app_writer）：仅授予
INSERT, UPDATE, DELETE, EXECUTE（含存储过程写逻辑），禁止SELECT（除非必要且经评审） - 读账号（如app_reader）：只授
SELECT，可限定到具体视图或只读副本库，禁用LOCK TABLES、SHOW CREATE VIEW等高危元数据操作 - 连接池需分别维护两套配置，避免因故障自动降级混用
按业务模块切分读权限：避免“全库SELECT”式授权
不直接对app_reader执行GRANT SELECT ON *.*。应逐模块收敛：
- 订单服务 → 只读
order_db.orders、order_db.order_items、关联的user_db.users（只读视图） - 商品服务 → 仅
product_db.products、product_db.categories，屏蔽product_db.price_logs等敏感历史表 - 用视图封装复杂JOIN或脱敏字段（如隐藏手机号中间4位），再对视图授权，而非基表
运维与分析账号走独立通道：禁止直连主库
DBA、BI工具、临时查询账号必须隔离路径：
- 运维账号（如dba_ops）：允许
SHOW PROCESSLIST、EXPLAIN、慢日志表查询，但限制在从库或专用只读实例上执行 - 分析账号（如bi_analyst）：只连数仓同步库或TIDB/StarRocks等OLAP集群，主库禁止
SELECT大表全量扫描 - 所有非应用类账号启用
MAX_QUERIES_PER_HOUR和MAX_CONNECTIONS_PER_HOUR防误操作拖垮实例
定期审计+动态回收：权限不是“设一次就完事”
权限会随业务迭代过期。建议：
- 每月跑脚本检查：哪些账号30天未登录、哪些账号有
SELECT但近90天无查询记录 - 用
mysql.proxies_priv和information_schema.role_table_grants跟踪权限继承链，避免角色嵌套失控 - 新业务上线时，由DBA+研发双签《权限申请单》，明确表级范围、有效期、紧急回收联系人
