在Hibernate中已有HQL的情况下为什么还需要使用原生SQL

HQL 作为 Hibernate 主推的面向对象查询语言，能满足大部分常规 CRUD 场景的需求，还能做到跨数据库兼容，但原生 SQL 的不可替代性主要体现在以下几个场景：

• 利用数据库专属的高级特性
  HQL 为了适配不同数据库的通用能力，无法支持单个数据库独有的方言功能，比如 MySQL 的 JSON 字段操作、窗口函数，PostgreSQL 的数组查询、全文检索，Oracle 的递归查询等，这类场景只能用原生 SQL 实现。
  举个实际例子：你需要在 MySQL 中统计每个商品分类下销售额Top3的商品，需要用到 MySQL 特有的ROW_NUMBER()窗口函数，HQL 完全不支持该语法，只能通过原生 SQL 实现：

SELECT goods_id, category_id, sales_amount
FROM (
  SELECT 
    goods_id, category_id, sales_amount,
    ROW_NUMBER() OVER (PARTITION BY category_id ORDER BY sales_amount DESC) AS rank_num
  FROM t_goods_sales
) temp WHERE rank_num <= 3

在 Hibernate 中直接通过session.createNativeQuery(sql, GoodsSales.class)就能执行上述语句，还能直接将结果映射为实体对象，开发和执行效率都远高于用 HQL 先查全量数据再在代码里排序筛选。

• 复杂查询的性能优化
  涉及多表关联、大数据量聚合统计的报表类场景，HQL 自动生成的 SQL 往往会产生多余的关联查询、冗余字段查询，很难命中最优索引，性能远不如 DBA 专门优化过的原生 SQL。手写原生 SQL 可以精准控制关联逻辑、查询范围、索引选择，性能可以比 HQL 生成的语句高几倍甚至几十倍。
• 复用存量 SQL 资产
  很多老项目重构时才引入 Hibernate 框架，之前已经有大量经过线上验证的复杂业务 SQL（比如财务对账、数据统计类的长SQL），全部转写为 HQL 不仅成本极高，还容易引入逻辑错误，直接调用原生 SQL 可以做到无缝迁移，节省大量开发和测试成本。
• 执行特殊的 DDL/批量操作
  HQL 仅面向实体相关的增删改查操作，不支持 DDL 语句（建表、修改表结构等），也不适合执行无实体关联的批量更新/删除操作，这类场景只能依赖原生 SQL 实现。
  比如需要给用户表新增一个字段，直接执行原生SQL即可：

ALTER TABLE t_user ADD COLUMN login_times INT DEFAULT 0 NOT NULL

HQL 本身不支持任何 DDL 语法，完全无法实现上述需求。

总体来说 HQL 和原生 SQL 是互补的关系，HQL 适合常规业务场景，开发效率高、跨数据库适配能力强；原生 SQL 适合特殊、高性能、数据库专属的场景，二者配合才能覆盖所有业务需求。

内容的提问来源于stack exchange，提问作者Shivansh Bajpai