错误日志本身不记录SQL或用户数据，所谓“脱敏”是伪命题；需通过撤销FILE/PROCESS/EXECUTE权限、禁用super_priv、设log_error_verbosity≤1、确保log_error权限为600及隔离路径来防控敏感信息绕道泄露。
error_log 本身不记录 SQL 语句或用户参数，所谓“错误日志脱敏”是个伪命题——你无法靠改 MySQL 配置让错误日志自动过滤 'password=123456' 这类内容。真正要防的，是敏感信息绕道进入错误日志的路径。
为什么 error_log 里会出现敏感参数？
MySQL 错误日志默认只记启动、崩溃、连接拒绝等系统事件。但以下情况会让敏感参数“意外落盘”：
- 应用层把
mysqli_error()或conn.error()的完整字符串（含原始 SQL）直接写入error_log文件（说明应用日志配置错误） - 自定义存储函数用
SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = CONCAT('failed for user:', @uid)，部分 MySQL 版本会把该消息写进错误日志 -
LOAD DATA INFILE '/tmp/user_789.csv'失败时，路径中的用户名或临时 ID 被记录 - 误将
general_log或slow_query_log文件当成error_log查看，而这两者确实会记明文 SQL
必须撤销的权限：堵住敏感数据入口
MySQL 没有“禁止写敏感内容到 error_log”的权限，但能限制触发敏感输出的操作：
- 执行
REVOKE FILE ON *.* FROM 'app_user'@'%';—— 防止LOAD DATA路径暴露、SELECT ... INTO OUTFILE构造恶意报错 - 执行
REVOKE PROCESS ON *.* FROM 'app_user'@'%';—— 避免应用把SHOW PROCESSLIST结果当错误上下文打印，带出正在执行的 SQL - 确保普通用户无
SUPER权限 —— 否则可动态修改log_error_verbosity或把general_log输出重定向到error_log文件 - 对非 DBA 用户，回收
EXECUTE权限 —— 阻止调用含CONCAT('token=', @token)的自定义函数
关键配置项：收紧日志行为边界
权限只是基础，必须配合配置才能切断泄露链路：
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 设
log_error_verbosity = 1（MySQL 8.0.14+）—— 只记录 ERROR 级别事件，跳过 WARNING/INFO 中可能夹带的上下文 - 确认
log_error文件权限为600，且属主为mysql用户：chown mysql:mysql /var/log/mysqld.log && chmod 600 /var/log/mysqld.log - 检查
secure_file_priv是否设为非空目录（如/var/lib/mysql-files/），避免用户随意指定LOAD DATA路径 - 绝对不要在生产环境开启
general_log或slow_query_log并设log_output = 'TABLE'——mysql.general_log表若被低权限账号读取，等于直接送源码
应用层才是真正的防线
所有服务端配置都挡不住应用自己把 SELECT * FROM users WHERE password = 'abc' 打进日志。必须同步做：
- PHP 中禁用
mysqli_report(MYSQLI_REPORT_STRICT)，改用MYSQI_REPORT_OFF或MYSQI_REPORT_ERROR - PDO 设置
$pdo->setAttribute(PDO::ATTR_ERRMODE, PDO::ERRMODE_SILENT)，并确保display_errors = Off - Java 项目中，
SQLException.toString()绝不能直接返回给前端或写入业务日志 - Node.js 使用
mysql2时，必须监听'error'事件并统一处理，不能任由未捕获异常 crash 进程
MySQL 错误日志脱敏的复杂点在于：它根本不是日志格式问题，而是权限、配置、应用三层行为耦合的结果。最容易被忽略的是——你以为关了 general_log 就安全了，却没发现运维脚本正把 mysqld --help --verbose 的输出重定向到同一个 /var/log/mysqld.log 文件里，而那个输出里明明白白写着 default_password_lifetime = 0 和 plugin_dir = /usr/lib/mysql/plugin。
