原生SQL是解决JPA多表关联、聚合统计与性能瓶颈最有效方式，关键在于结构可控、参数安全、映射清晰、分页可复用；方法命名查询无法表达括号分组逻辑，JPQL不支持数据库特有函数，@Query(nativeQuery=true)需用命名参数、显式字段、别名统一，并推荐接口投影与手动分页保障健壮性。
直接写原生SQL是解决JPA多表关联、聚合统计、性能瓶颈最有效的方式，但“优雅”不等于随便拼字符串——关键在结构可控、参数安全、映射清晰、分页可复用。
为什么不能只靠方法命名查询做复杂条件
方法命名（如 findByAppnameOrAppnameAndStatus）无法表达括号分组逻辑，AND 总是比 OR 优先级高。你想要的 (appname = 'gmail' OR appname = 'facebook') AND status = 'Pending'，实际会被解析成 appname = 'gmail' OR (appname = 'facebook' AND status = 'Pending')，结果错得离谱。
- 一旦出现嵌套 OR/AND、IN + LIKE 混合、字段函数（
DATE(created_at)）、或跨三张以上表 JOIN，就必须切到@Query - JPQL 不支持某些 MySQL 特有语法（如
GROUP_CONCAT、JSON_EXTRACT），这时nativeQuery = true是唯一选择 - 别指望 Hibernate 自动优化大表 JOIN —— 原生 SQL 才能精准控制驱动表、强制索引、避免隐式类型转换
@Query(nativeQuery = true) 的正确写法与避坑点
核心原则：SQL 可读、参数隔离、字段显式、别名统一。
- 用 Java 15+ 三重引号（
"""）换行写 SQL，别用字符串拼接；每行缩进对齐，WHERE 条件每行一个，方便 diff 和 review - 所有参数必须用命名参数（
:status），绝不用位置参数（?）—— 否则改顺序就崩，且无法复用 - SELECT 字段必须显式写出，禁止
SELECT *；涉及多表时，每个字段加表别名前缀（如o.id, c.name），避免列名冲突 - 返回 DTO 推荐用接口投影（
interface OrderSummary），而不是Object[]或Map—— 类型安全，IDE 可跳转，序列化不丢字段
示例：
@Query(value = """
SELECT
o.id AS order_id,
c.name AS customer_name,
COUNT(i.id) AS item_count,
SUM(i.quantity * i.price) AS total_amount
FROM orders o
JOIN customers c ON o.customer_id = c.id
LEFT JOIN order_items i ON o.id = i.order_id
WHERE o.created_at >= :fromDate
AND c.status = :customerStatus
GROUP BY o.id, c.name
ORDER BY total_amount DESC
""", nativeQuery = true)
List<ordersummary> findHighValueOrders(
@Param("fromDate") LocalDateTime fromDate,
@Param("customerStatus") String customerStatus);
</ordersummary>
如何让原生 SQL 支持分页且不写两遍 COUNT
Spring Data JPA 的 Pageable 对原生 SQL 分页支持有限：它默认对整个 @Query 加 LIMIT/OFFSET，但不会自动帮你生成 COUNT 查询。手动写两个 SQL 容易不一致（比如 JOIN 条件漏了、WHERE 不同步）。
win可用的mysql指令skill
下载
安装、修复、更新或打包一个基于 Python 和 PyMySQL 实现的 Windows `mysql` 命令。适用于用户希望在 PowerShell/CMD 中输入 `mysql` 时重定向到 Python 实现、需要交互式输入 MySQL 连接信息、需要同步到当前用户本地 bin 目录，或需要将该能力封装成可公开复用的 Codex skill。
- 不要自己拼
"SELECT COUNT(*) FROM (" + querySql + ")"—— MySQL 8.0+ 会报错，因为子查询带 LIMIT 不被允许 - 推荐做法：用
EntityManager手动执行 COUNT，但 SQL 要提取共用部分（比如把 WHERE 条件抽象为独立方法），或借助工具类做正则替换（如把SELECT ... FROM替换为SELECT COUNT(*) FROM） - 更稳的选择：用
PageImpl手动构造分页结果——先查总数（精简版 COUNT SQL），再查数据列表（带 LIMIT/OFFSET），最后封装成Page - 注意：MySQL 的
COUNT(*)在 InnoDB 下仍是全表扫描，如果总数查询慢，考虑加覆盖索引，或用近似值（SHOW TABLE STATUS）代替精确计数
DTO 映射最容易忽略的三个细节
你以为写了 AS xxx 就能自动映射？错。JPA 对原生 SQL 的字段映射非常脆弱。
- 字段别名必须和 DTO 接口方法名**完全一致**（大小写敏感），且不能含下划线以外的符号；
order_id→ 接口里必须是OrderId()或getOrderId()，不能是getOrder_id() - 如果用了 MySQL 函数（如
DATE_FORMAT(o.created_at, '%Y-%m')），别名要避开关键字，且确保返回类型和 DTO 字段类型匹配（StringvsLocalDate） - LEFT JOIN 后某字段可能为 NULL，DTO 中对应字段类型必须是包装类（
Integer而非int），否则反序列化时报NullPointerException
接口投影示例：
interface OrderSummary {
Long getOrderId();
String getCustomerName();
Integer getItemCount();
BigDecimal getTotalAmount();
}
别小看这几个字母大小写和 null 安全——线上查不到数据却没报错，90% 是栽在这儿。
