应为用户分配最小必要权限：按库授予SELECT/INSERT/UPDATE/DELETE，限定具体IP段而非'%'，禁用CREATE/DROP等高危权限，分离主从与应用账号，结合网络层控制。
如何用
为用户分配最小必要读写权限
直接给
、
、
、
四个权限，比给
安全得多，也更符合实际业务需求。
常见错误是把权限赋给
却忘了只允许从特定网段连入，结果暴露在公网；或者用
给了跨库权限，而应用其实只操作一个库。
按库授权：用
避免通配符主机：不用
，改用具体 IP 段或内网 DNS 名（如
）
执行后必须跟
（仅在直接修改
表时才需要；用
通常自动生效）
为什么不能跳过
和
权限就认为“只读”安全
表面看只给了
就是只读，但若用户还能创建临时表、视图或函数，就可能绕过限制——比如用
包装敏感字段，再通过
间接读取；或用
缓存并重写数据逻辑。
真正只读场景下，应显式拒绝高危操作：
不授予
、
、
、
、
、
检查是否残留旧权限：
若用 MySQL 8.0+，可考虑角色（
）统一管理只读策略，避免逐个用户重复配置
权限不是给应用用户的，而是给从库同步用的
很多团队误把主从同步账号当成普通应用账号复用，导致应用意外具备读取 binlog 的能力，存在数据泄露和被注入风险。
正确做法是严格分离账号用途：
MySQL（Linux）
MySQL 9.6.0是面向Linux平台的2026年创新版本，核心架构迎来重大革新。其将外键约束与级联操作从InnoDB引擎层上移至SQL层，确保所有数据变更均被完整记录至Binlog，彻底解决了CDC（变更数据捕获）与主从复制中的数据不一致难题。此外，该版本引入container_aware启动选项以原生适配容器环境，并对审计日志进行了组件化重构，为追求极致数据一致性与云原生体验的开发者提供了全新选择。
下载
主从复制专用账号：只赋予
+
，主机限定为从库 IP
应用读写账号：仅限业务库的 DML 权限，禁止任何 replication 相关权限
监控账号（如 Prometheus）：只需
、
、
on
，不碰业务表
MySQL 8.0 的
和
对权限管控的实际影响
权限本身不控制密码策略，但弱密码会让已有权限的账号更容易被爆破或冒用。MySQL 8.0 内置的密码历史机制能降低凭证复用风险，属于权限体系的必要补足。
配置示例（在
表或
时设置）：
注意：
只对后续改密生效，不会追溯已存在的旧密码；且只有使用
或
插件才支持该策略。
权限设计最易忽略的点，是没把网络层访问控制（如防火墙、VPC 安全组）和数据库层权限做联动——哪怕 SQL 权限收得再严，如果端口对全网开放，一切都没意义。
GRANTSELECTINSERTUPDATEDELETEALL PRIVILEGES'user'@'%'GRANT ... ON *.*GRANT SELECT, INSERT, UPDATE, DELETE ON `app_db`.* TO 'app_user'@'192.168.10.%''app_user'@'%''app_user'@'web-server-01'FLUSH PRIVILEGESmysql.userGRANTCREATEDROPSELECTCREATE VIEWSELECTCREATE TEMPORARY TABLECREATEDROPALTERINDEXCREATE VIEWSHOW VIEWSHOW GRANTS FOR 'report_user'@'localhost'CREATE ROLEREPLICATION SLAVEREPLICATION SLAVEREPLICATION CLIENTPROCESSREPLICATION CLIENTSELECTperformance_schemapassword_historypassword_reuse_intervalmysql.userCREATE USERCREATE USER 'app_user'@'192.168.10.%'
IDENTIFIED WITH 'caching_sha2_password'
BY 'StrongPass!2024'
PASSWORD HISTORY 5
PASSWORD REUSE INTERVAL 365 DAY;PASSWORD HISTORYcaching_sha2_passwordsha256_password