怎样在MyEclipse中调试Hibernate的HQL查询【进阶】

必须在QueryImpl.executeQuery()第一行设断点，而非list()方法，以捕获HQL到SQL转换；参数绑定需步入setParameter→TypedValue.resolve()；HQL语法错误定位应从HqlLexer.nextToken()入手，结合tokenStream.index与tokens列表精确到字符偏移。

想在MyEclipse里把HQL的执行过程看得透透彻彻——比如SQL到底怎么生成的、参数是怎么绑到占位符上的、结果映射又是在哪一步出了岔子，光靠日志那点粗略输出根本不够。必须直接切入Hibernate底层的执行链路，在关键节点上设断点，一步步跟进去。下面这几条调试路径，是多年实战里摸出来的，省时省力又精准。

启用Hibernate SQL与参数日志（前置验证）

先确保代码环境能跟源码对上号。打开MyEclipse，右键项目进Properties → Ja va Build Path → Libraries → 展开hibernate-core JAR → Source attachment，确认已经关联了源码（不然后面断点白打）。 然后要在hibernate.cfg.xml或Spring配置文件里把这几行加进去：

true
true
true

三个属性缺一不可：只开show_sql，参数占位符还是问号，看不到真实值；format_sql不打开，SQL全挤成一行，眼睛都要看花；use_sql_comments一丢，MyBatis式的注释就没了，查具体哪个HQL引发的也费劲。

在QueryImpl类中设置断点拦截HQL解析

用Ctrl+Shift+T快速打开类，输入QueryImpl，选org.hibernate.impl.QueryImpl（注意别选错成其他同名类），然后打开。 找到executeQuery()方法，在第一行代码——通常是调用this.getQueryString()之前——打上断点。 启动调试模式（Debug As → MyEclipse Server Application），调一个包含HQL的DAO方法，程序就会稳稳停在这个断点上。

追踪参数绑定与类型转换过程

断点命中后，可以走三条路看清楚参数是怎么绑定上去的。 **方法一：跟踪setParameter流程** 按F5步入，进入QueryImpl.setParameter(String, Object)，继续F5，直到进入TypedValue类构造器。这个时候就能看到type.resolve()是如何把Ja va类型映射成SQL类型的。 **方法二：观察PreparedStatement绑定的瞬间** 在org.hibernate.jdbc.AbstractBatcher类里搜prepareStatement，在return stmt那句前面打上断点。执行时，原始SQL字符串和JDBC Connection对象尽收眼底。 **方法三：拦截SQL实际执行的那一步** 找到org.hibernate.jdbc.JDBCContext类，在afterTransactionCompletion()上方的doWorkInSession()调用附近设断点。这里能抓到Statement.execute()执行前最后一刻的完整SQL和参数数组——比任何日志都可靠。

定位HQL语法错误的具体位置

Hibernate抛出的“unexpected token”错误提示有时候挺坑的，回溯失败时指向的偏移位置根本不对。不如直接从词法分析器下手。 第一步：在org.hibernate.hql.ast.HqlLexer.nextToken()方法入口打上断点。 第二步：触发出错的HQL查询，断点命中后，观察tokenStream对象的index字段。 第三步：切到Variables视图，展开tokenStream，看tokens列表，根据index找到当前解析到的Token文本。 第四步：对照原始HQL字符串，用token.getStartColumn()加上token.getStartLine()换行符的累计数，算出确切的字符偏移量——问题出在第几行第几个字符，一清二楚。 这个偏移量比Hibernate自带的提示靠谱得多，尤其当错误发生在嵌套子查询或复杂表达式里时，能省去大量盲目排查的时间。