必须拦截statementhandler，因其在sql最终定型前（prepare()调用前）可安全解析ast并注入租户条件；executor拦截太晚，boundsql已固化，硬改将引发语法错误或漏过滤。

直接在 Executor 层拦截 query/update 方法，是最稳妥、语义清晰且能拿到完整上下文的方式。它不改 SQL，只做观测和判断，天然适配审计与慢 SQL 场景。

为什么选 Executor 而不是 StatementHandler？

StatementHandler 虽然能最早拿到原始 SQL，但此时参数尚未绑定，BoundSql 中的 SQL 还带占位符（?），无法还原真实执行语句；而 Executor 的 query 和 update 方法调用时，MappedStatement 已准备好，BoundSql 可直接获取已解析的 SQL 字符串，且参数对象完整可用——这对脱敏、拼接、耗时统计都至关重要。

另外，Executor 拦截覆盖所有执行路径（含缓存命中、批量操作等），避免 StatementHandler 因代理链跳过导致漏监控。

如何获取带参数的真实 SQL（非占位符）？

核心是用 DefaultParameterHandler 渲染参数值，再替换 SQL 中的 #{} 或 ${} 占位符。关键步骤如下：

Alibabacloud Sdk Client Initialization For Java

在 Java 中初始化和管理阿里云 SDK客户端。包括单例模式、线程安全、endpoint 与 region 配置、VPC 终端节点、同步与异步等。

下载

• 从 MappedStatement 获取 BoundSql boundSql = ms.getBoundSql(parameter)
• 提取原始 SQL：String sql = boundSql.getSql()
• 获取参数映射列表：List<parametermapping> parameterMappings = boundSql.getParameterMappings()</parametermapping>
• 借助 Configuration 创建 DefaultParameterHandler，调用 setParameters(PreparedStatement) 并捕获实际设参过程（或用反射读取 boundSql.getAdditionalParameter()）
• 对每个 #{prop}，用 MetaObject 从 parameter 中取值，按类型格式化（字符串加引号、数字不加、null 写为 NULL），再正则替换 SQL 中对应位置
• 敏感字段（如 id_card、phone）需提前识别并脱敏，例如替换成 '138****1234'

怎么判断慢 SQL 并记录告警？

在 intercept() 中用纳秒级计时包裹 invocation.proceed()，阈值建议设为 500ms（可配置）。示例逻辑：

• 开始前记下 long start = System.nanoTime()
• 执行原逻辑：Object result = invocation.proceed()
• 结束后计算耗时：long costMs = (System.nanoTime() - start) / 1_000_000
• 若 costMs > threshold，则打印 WARN 日志，内容包括：
    • 执行时间（毫秒）
    • 渲染后的完整 SQL（已脱敏）
    • 对应的 Mapper 方法全名（ms.getId()）
    • 当前线程与用户标识（如有上下文）

审计日志该包含哪些关键字段？

一份合规、可追溯的 SQL 审计日志至少应记录：

• 时间戳：精确到毫秒，使用 Instant.now()
• 执行人/租户 ID：从 ThreadLocal 或 Spring Security Context 提取，多租户系统必须带上 tenant_id
• Mapper 方法 ID：MappedStatement.getId()，例如 com.example.mapper.UserMapper.selectById
• 完整 SQL（已渲染+脱敏）：避免日志泄露敏感数据
• 影响行数：query 返回 List.size()，update 直接取返回值
• 执行耗时（ms）：用于性能分析
• 数据库连接信息（可选）：如数据源名称、JDBC URL 片段，便于定位库实例

建议将审计日志单独输出到文件或发往 ELK/Splunk，不要混入业务日志流。

Java免费学习笔记：立即使用
解锁 Java 大师之旅：从入门到精通的终极指南