SQL注入防护：别只靠预处理，还得看连接层配置
MySQL本身不直接“拦截”SQL注入，防护核心在应用层使用参数化查询，但数据库侧配置能堵住不少旁路攻击。比如攻击者绕过应用直连数据库执行恶意语句时，
sql_mode和
secure_file_priv就是第一道防线。
sql_mode建议启用
STRICT_TRANS_TABLES和
NO_AUTO_CREATE_USER，避免隐式类型转换导致的条件绕过（如
'1' = 1被宽松解析成真）
secure_file_priv必须设为非空目录（如
/var/lib/mysql-files/），否则攻击者可能用
LOAD DATA INFILE或
SELECT ... INTO OUTFILE读写任意文件 禁用
LOCAL INFILE：启动 mysqld 时加
--local-infile=0，或运行时执行
SET GLOBAL local_infile = OFF（需 SUPER 权限）
最小权限原则：给应用账号只配 SELECT
/INSERT
等具体 DML 权限
别让 Web 应用账号拥有
GRANT OPTION、
DROP、
CREATE或对
mysql系统库的访问权——这些不是业务必需，却是提权关键。 建专用账号，按模块分库授权：
CREATE USER 'app_report'@'10.20.%' IDENTIFIED BY 'strong-pass-2024';只授必要表的权限：
GRANT SELECT, INSERT ON finance_db.invoice TO 'app_report'@'10.20.%';显式拒绝高危操作：
REVOKE FILE, PROCESS, SUPER ON *.* FROM 'app_report'@'10.20.%';（注意：REVOKE 不会报错即使权限原本未授予） 避免用
GRANT ... ON *.*—— 即使是测试环境，也容易漏掉新库的权限收敛
敏感操作审计：靠 general_log
不现实，改用 audit_log
插件
general_log会严重拖慢性能且日志无结构，生产环境必须关；真正可用的是 MySQL Enterprise Audit 插件（社区版不可用），或 Percona Server / MariaDB 的等效替代方案。 Percona Server 可启用
audit_log：安装后设置
audit_log_policy = ALL，它会记录所有语句及客户端 IP、用户、时间戳 重点过滤含
UNION SELECT、
CONCAT(、
CHAR(、
LOAD_FILE(的日志行——这些是手工注入常见特征 日志路径需独立挂载且仅 root 可读：
audit_log_file = /var/log/mysql/audit.log，配合 logrotate 限制大小
INSTALL PLUGIN audit_log SONAME 'audit_log.so'; SET GLOBAL audit_log_policy = 'LOGINS,QUERIES'; SET GLOBAL audit_log_exclude_accounts = 'monitor_user@%';
密码与连接加固：TLS 不是可选项，而是 SQL 注入后果扩大的放大器
没开 TLS 时，明文传输的账号密码 + 注入后的数据回传，等于把钥匙和保险箱一起快递给攻击者。而弱密码 + 允许远程任意 IP 登录，会让注入得手后横向移动毫无阻力。
强制 TLS：创建用户时指定REQUIRE X509或至少
REQUIRE SSL，并验证
SHOW VARIABLES LIKE 'have_ssl';返回
YES限制登录来源：
CREATE USER 'api_app'@'172.16.5.12' IDENTIFIED BY '...';，禁用
'%'通配主机（除非用跳板机代理） 密码策略：启用
validate_password插件，设
validate_password.length = 12、
validate_password.mixed_case_count = 2定期轮换凭据：用
ALTER USER 'app_rw'@'10.20.%' IDENTIFIED BY 'new-secret-2024Q3';，旧密码立即失效
实际中最容易被忽略的是：应用连接池复用账号时，权限变更不会自动生效，必须重启连接池或等待连接超时重建；而
audit_log默认不记录空密码登录或认证失败事件——这两处恰好是暴力破解+注入组合攻击的盲区。
