MySQL权限配置是SQL注入的最后一道闸门，即使代码层失守，严格权限也能限制攻击者查、删、导能力；业务账号仅授CRUD权限，禁用DROP/ALTER/CREATE/FILE/EXECUTE，限制登录IP，定期审计账号，并配合strict模式、secure_file_priv等服务端配置及错误信息管控。
MySQL权限配置是SQL注入的最后一道闸门
即使代码层完全失守（比如误用了字符串拼接），严格的权限配置也能让攻击者“查不到、删不了、导不出”。它不防注入发生，但能大幅压缩注入成功后的危害范围。
- 业务账号只授予
SELECT、INSERT、UPDATE、DELETE，禁用DROP、ALTER、CREATE、FILE、EXECUTE—— 这些权限一旦开放，报错注入或UNION SELECT LOAD_FILE()就可能直接读取服务器文件 - 限制登录主机，例如创建账号时用
'app_user'@'192.168.10.%'而非'app_user'@'%'，防止攻击者从任意IP连入尝试提权 - 定期运行
SELECT user, host, account_locked FROM mysql.user;检查是否存在长期未用或权限过宽的账号
为什么预处理语句不能替代权限控制？
因为预处理语句只解决“参数被当代码执行”的问题，但对“动态表名”“动态列名”“ORDER BY 字段”等场景完全无效 —— 这些地方必须靠白名单校验+权限兜底。
- 比如分表查询：
"SELECT * FROM log_202512 WHERE uid = ?"中的log_202512是用户传入的月份，无法用?占位，只能靠正则匹配^log_\d{6}$+ 数据库账号无权访问其他表 - 再如排序字段：
ORDER BY ?在绝大多数驱动中不被支持（会报错），必须用白名单限定为['created_at', 'score', 'name']，否则攻击者可填入id; DROP TABLE users; - 如果账号还拥有
FILE权限，即便用了PreparedStatement，攻击者仍可通过报错注入触发SELECT ... INTO OUTFILE写入 Webshell
my.cnf 里这几个配置项直接影响注入后果
服务端配置不是“锦上添花”，而是决定攻击者能否拿到错误信息、读写文件、甚至绕过路径限制的关键开关。
