mysql错误日志本身不记录sql或用户数据，但敏感信息可能通过应用堆栈、signal消息、load data失败路径等间接泄露；需从权限（revoke file/process/execute）、配置（log_error_verbosity=1、关general_log/slow_query_log并清理历史文件）、应用层（禁用错误透出、统一异常响应）三方面协同防控。
MySQL 错误日志（error_log）本身不记录 SQL 语句或用户数据，但敏感信息仍可能通过间接方式泄露——比如应用层错误堆栈、自定义函数抛出的含身份证号的 SIGNAL 消息、LOAD DATA INFILE 失败暴露的临时路径，或误将 general_log 当作错误日志查看。单纯“关日志”没用，得从权限 + 配置 + 应用三层堵住入口。
撤销 FILE、PROCESS、EXECUTE 权限防源头泄露
这些权限不是用来“写日志”的，而是让普通用户能触发带敏感上下文的错误场景：
-
REVOKE FILE ON *.* FROM 'app_user'@'%'：防止LOAD DATA INFILE或SELECT ... INTO OUTFILE报错时暴露路径（如/tmp/user_12345.csv） -
REVOKE PROCESS ON *.* FROM 'app_user'@'%'：避免用户执行SHOW PROCESSLIST后，应用把结果当调试上下文打印到日志 -
REVOKE EXECUTE ON *.* FROM 'app_user'@'%'：禁用调用自定义函数，尤其那些内部用CONCAT('id:', @user_id)拼接提示消息再SIGNAL SQLSTATE '45000' SET MESSAGE_TEXT = ...的函数
设 log_error_verbosity = 1 并收紧日志文件权限
这是 MySQL 8.0.14+ 最关键的服务端控制项，旧版本无法等效替代：
- 在
my.cnf的[mysqld]段添加log_error_verbosity = 1，重启生效；它只记录 ERROR 级别事件，跳过 WARNING 和 SQL 上下文 -
log_warnings = 0在 8.0 中已废弃，加了会导致 mysqld 启动失败 - 确认
log_error文件属主为mysql:mysql，权限为600（chmod 600 /var/log/mysql/error.log），避免运维误同步或下载后泄露 - 不要把
log_error路径设在 Web 可读目录（如/var/www/html/），否则 HTTP 服务配置出错时可能被直接下载
关 general_log / slow_query_log 并清理历史日志
这两类日志才是真正的“敏感信息高危区”，它们会完整记录明文密码、token、身份证字段值：
- 执行
SHOW VARIABLES LIKE 'general_log'确认状态，若为ON，立即SET GLOBAL general_log = OFF - 编辑
my.cnf，注释掉general-log=1和general-log-file=...行，重启 mysqld - 同样处理
slow_query_log：检查slow_query_log_file路径，确保不落在共享目录，且权限为640 - 已有日志文件必须手动清理：
rm -f $(mysql -Nse "SELECT @@general_log_file")（先验证路径是否正确）
应用层必须禁用错误透出，否则所有服务端配置都白搭
MySQL 服务端从不主动把 Unknown column 'password' 这种提示发给浏览器——是 PHP/Python/Java 应用把 mysqli_error() 或 conn.error() 直接 echo 或写进响应体才导致泄露：
- PHP MySQLi：运行时执行
mysqli_report(MYSQLI_REPORT_OFF)，或至少用MYSQLI_REPORT_ERROR（报错但不带 SQL） - PHP PDO：构造时设
PDO::ATTR_ERRMODE => PDO::ERRMODE_SILENT，并确认display_errors = Off在 php.ini 中生效 - Flask/Django 上线前必须设
debug=False，否则 500 错误会渲染完整 traceback 和原始 SQL - Node.js mysql2：监听
'error'事件并捕获，绝不让异常未处理就 crash 输出堆栈
最容易被忽略的是：即使关了 general_log，如果运维把慢查询日志误发到协作群、或备份脚本把 error.log 打包上传到对象存储，照样构成泄露。日志文件本身不是问题，问题是它的生命周期管理——谁可读、谁可传、谁可删，比配置项更关键。
