答案：MySQL默认不记录密码修改日志，需提前启用通用查询日志、企业审计插件或分析binlog来追踪ALTER USER、SET PASSWORD等操作，结合权限管控与外部审计工具实现可追溯性。
MySQL本身不会默认记录密码修改的操作日志，因此直接查询“密码修改记录”在常规配置下是无法实现的。但可以通过以下几种方式间接获取或审计相关操作，提升密码管理的安全性和可追溯性。
启用MySQL通用查询日志（General Query Log）
如果提前开启了通用日志，可以查看所有执行过的SQL语句，包括ALTER USER、SET PASSWORD等密码修改命令。
- 检查是否开启：在配置文件my.cnf中查看是否有
general_log = ON - 日志位置：通常为数据目录下的hostname.log，可通过
SHOW VARIABLES LIKE 'general_log_file';查看 - 查找关键词：
ALTER USER、SET PASSWORD、CREATE USER等
注意：通用日志会影响性能，不建议长期开启，仅用于临时审计。
使用MySQL企业审计插件（Enterprise Audit Plugin）
MySQL Enterprise Edition提供审计插件，能详细记录用户操作，包括密码变更。
- 确认插件是否加载：
SHOW PLUGINS;查看audit_log状态 - 审计日志默认写入文件，路径由
audit_log_file变量指定 - 搜索日志中的
set password或alter user操作记录
社区版用户无法使用该功能，需考虑替代方案。
通过binlog分析DDL/DCL操作（部分可行）
密码修改属于DCL语句，在binlog中可能以事件形式存在，尤其是使用ROW格式时会记录元数据变更。
- 确认binlog开启：
SHOW VARIABLES LIKE 'log_bin'; - 使用mysqlbinlog工具解析日志：
mysqlbinlog --base64-output=DECODE-ROWS -v binlog.000001 - 查找包含USER、PASSWORD变更的相关事件
注意：STATEMENT格式下可能看不到细节，ROW格式更易追踪元数据变化。
加强密码管理与审计建议
由于MySQL原生不记录密码修改历史，应从管理层面建立规范：
- 启用日志审计机制，如部署Percona Server + 审计插件替代社区版
- 结合操作系统日志和数据库代理（如ProxySQL）记录操作行为
- 限制管理员权限，实行最小权限原则
- 定期审查用户列表：
SELECT User, Host, password_last_changed FROM mysql.user; - 使用强密码策略并配合password validation插件
基本上就这些。想查密码修改记录，关键在于是否提前开启了相应的日志功能。没有日志支持的情况下，事后追查几乎不可能。所以重点还是在于事前部署审计机制，做好权限管控和操作留痕。安全无小事，密码管理尤其要规范。
