本文介绍如何通过 aspectj 精准拦截 jdbc 层所有 sql 执行（含 statement 和 preparedstatement），实现与数据库框架无关的 sql 监控，适用于 spring jdbc、hibernate、spring data jpa 等各类 orm 场景。
本文介绍如何通过 aspectj 精准拦截 jdbc 层所有 sql 执行（含 statement 和 preparedstatement），实现与数据库框架无关的 sql 监控，适用于 spring jdbc、hibernate、spring data jpa 等各类 orm 场景。
要真正实现“拦截所有 SQL 查询”，关键在于理解底层 JDBC 调用的本质：无论使用 JdbcTemplate、Hibernate 还是 Spring Data JPA，最终都会通过 java.sql.Statement 或其子接口 java.sql.PreparedStatement 执行 SQL。因此，仅切中 Statement 是不够的——Spring Data JPA 默认使用预编译语句（PreparedStatement），而原切点 @Pointcut("target(java.sql.Statement)") 不会匹配 PreparedStatement（因其为接口，且 target() 仅匹配直接目标类型，不包含子类型）。
✅ 正确做法是分别定义两个切点，并覆盖所有执行方法：
@Pointcut("target(java.sql.Statement)")
public void statement() {}
@Pointcut("target(java.sql.PreparedStatement)")
public void preparedStatement() {}
接着，需为两类对象编写独立的通知逻辑：
- 对 Statement（如 executeQuery(String sql)），SQL 通常作为参数传入，可直接通过 args(sql) 获取；
- 对 PreparedStatement，SQL 已在创建时绑定（Connection.prepareStatement(sql)），无法从 execute*() 方法参数中获取，但可通过 PreparedStatement.toString() 或更可靠的方式——反射调用 PreparedStatement#getOriginalSql()（部分驱动支持）或利用 toString() 中隐含的 SQL 信息（如 PostgreSQL 驱动返回 PreparedStatement@xxx: SELECT ...）。示例中采用 toString() 作为轻量级兼容方案：
@AfterReturning("!within(AnalyzerAspect) && preparedStatement()")
public void afterPreparedStatement(JoinPoint jp) {
// 过滤非执行方法（如 close、setXxx）
if (!jp.getSignature().getName().startsWith("execute")) {
return;
}
Object target = jp.getTarget();
if (target instanceof PreparedStatement ps) {
String sql = extractSqlFromPreparedStatement(ps);
if (sql != null && !sql.trim().isEmpty()) {
handleSql(jp, sql);
}
}
}
@AfterReturning("!within(AnalyzerAspect) && statement() && args(sql)")
public void afterStatement(JoinPoint jp, String sql) {
handleSql(jp, sql);
}
// 提取 SQL 的健壮实现（推荐替代 toString()）
private String extractSqlFromPreparedStatement(PreparedStatement ps) {
try {
// 尝试通过 JDBC 4.2+ 标准方法获取
if (ps instanceof Wrapper) {
PreparedStatement unwrapped = ((Wrapper) ps).unwrap(PreparedStatement.class);
// 某些驱动（如 HikariCP 包装器）可能支持 getOriginalSql()
Method method = ReflectionUtils.findMethod(unwrapped.getClass(), "getOriginalSql");
if (method != null) {
return (String) method.invoke(unwrapped);
}
}
} catch (Exception ignored) {}
// 回退：依赖 toString()（仅作示意，生产环境建议结合驱动特性定制）
return ps.toString().replaceAll(".*?:\s*", "").trim();
}
private void handleSql(JoinPoint jp, String sql) {
// ✅ 统一处理逻辑：日志、性能分析、敏感词检测、审计等
System.out.println("[SQL INTERCEPTED] " + sql);
// your business logic here...
}
⚠️ 重要配置注意事项：
-
Weave 目标必须精准：spring-jdbc 和 hibernate-core 属于上层抽象库，其字节码中不包含 Statement/PreparedStatement 的实际实现——真正执行 SQL 的是JDBC 驱动（如 postgresql-42.x.jar、mysql-connector-java）。因此，
必须指向你实际使用的数据库驱动，而非 Spring 或 Hibernate。 -
避免过度织入：移除对 spring-jdbc 和 hibernate-core 的 weave 配置，仅保留驱动（如
org.postgresql postgresql ），既提升编译速度，又防止无谓的字节码修改。 - Aspect 排除自身：!within(AnalyzerAspect) 确保通知不递归触发，防止死循环。
- Kotlin 用户注意：原文示例为 Kotlin，Java 版本需将 fun 改为 public void，并确保 @Aspect 类被 Spring 容器管理或通过 @EnableAspectJAutoProxy 启用。
? 进阶建议：
- 若需 100% 可靠获取原始 SQL（尤其含占位符），可考虑在 DataSource 层代理（如使用 P6Spy 或自定义 DelegatingDataSource），它比 JDBC 层切面更稳定，且天然支持所有 JDBC 操作。
- 对于云原生场景，可将拦截结果上报至 OpenTelemetry，实现分布式 SQL 追踪。
该方案真正达成「一次编写，全域生效」：只要应用通过标准 JDBC API 执行 SQL（无论是否经由 JPA/Hibernate/JdbcTemplate 封装），均能被统一捕获，彻底解耦于具体 ORM 框架。
