要限制 MySQL 用户只能执行特定的 SQL 操作（比如只允许
SELECT，禁止
INSERT/
UPDATE/
DELETE），核心方法是通过 **精细化的权限控制**，而不是靠应用层过滤或 SQL 解析——后者不可靠且易绕过。
创建最小权限专用用户
不要复用高权限账号（如 root 或管理员账号）。应为每个应用/场景单独建用户，并只授予必要权限：
只读需求：仅授权SELECT权限到指定数据库或表 写入限制：若需写入，可只授
INSERT（不给
UPDATE/
DELETE），或进一步限定到某几张表 避免使用
GRANT ALL PRIVILEGES，哪怕在测试环境也应养成最小权限习惯
按库、按表精确授权
MySQL 支持多层级权限（全局 → 数据库 → 表 → 列），推荐按需下放：
-- 只允许 user_ro 对 db_app 的所有表执行 SELECT GRANT SELECT ON db_app.* TO 'user_ro'@'192.168.1.%'; <p>-- 只允许 user_log 对 db_app.log_table 执行 INSERT（常用于日志写入） GRANT INSERT ON db_app.log_table TO 'user_log'@'%';</p><p>-- 刷新权限使生效 FLUSH PRIVILEGES;
注意：
REVOKE可撤销已有权限，例如
REVOKE UPDATE, DELETE ON db_app.* FROM 'user_ro'@'%';
禁用高危操作（补充防护）
权限控制是主防线，但可叠加以下配置增强安全性：
在my.cnf中设置
sql_safe_updates = 1，防止没有 WHERE 的
UPDATE/
DELETE（对已授权用户生效） 禁用本地文件操作：启动时加
--secure-file-priv=NULL，阻止
LOAD DATA INFILE/
SELECT ... INTO OUTFILE避免开放
PROCESS、
SUPER、
FILE等管理类权限，除非绝对必要
验证与持续维护
授权后务必验证实际行为是否符合预期：
用新用户登录，尝试执行非授权语句（如DELETE FROM t1），确认报错
ERROR 1142 (42000): DELETE command denied定期审计用户权限：
SHOW GRANTS FOR 'username'@'host';删除不再使用的账号：
DROP USER 'old_user'@'%';
权限不是设一次就一劳永逸，需随业务变化动态调整。
