Hibernate先执行抓取连接后再普通连接时未生成JOIN的问题

First, let's recap your entity mappings for clarity:

@Entity
public class User {
    @Id
    private Long id;
    private String name;
    @OneToMany(mappedBy = "user", fetch = LAZY)
    private Set<UserRole> userRoles = new HashSet<>();
}

@Entity
public class UserRole {
    @Id
    private Long id;
    private String name;
    @ManyToOne(fetch = LAZY)
    private User user;
    @ManyToMany(fetch = LAZY)
    private Set<Article> articles = new HashSet<>();
}

@Entity
public class Article {
    @Id
    private Long id;
    private String name;
    @ManyToMany(mappedBy = "articles") // Assuming inverse side mapping
    private Set<UserRole> userRoles = new HashSet<>();
}

Why the JOIN Statement Isn't Generated #

This behavior comes down to how Hibernate optimizes query execution and handles fetch strategies:

1. Fetch Join Initializes Associations Early
   When you use JOIN FETCH (e.g., JOIN FETCH u.userRoles), Hibernate loads the associated UserRole entities into memory during the initial SQL query. Any subsequent "simple join" targeting the same association (like another JOIN u.userRoles) will be processed in-memory instead of generating a new SQL JOIN. Hibernate skips the redundant database call because it already has all the required data loaded.

2. Bidirectional Association Optimization
   Since User.userRoles is the inverse side of UserRole.user (via mappedBy), Hibernate tracks relationships between loaded entities. If you fetch-join user roles first, Hibernate knows it can resolve further joins on that association using already loaded objects, so it doesn't hit the database again.

3. Misaligned Query Structure
   If you split the fetch join and filter join (e.g., fetch all user roles first, then join to filter by role name), Hibernate will optimize out the second join—it filters the already loaded UserRole instances in memory instead of generating SQL.

Fixes to Force SQL-Generated JOINs #

1. Combine Fetch Join and Filtering in a Single Join #

Instead of splitting fetching and filtering into separate steps, merge them into one JOIN FETCH with your filter condition. This ensures filtering happens at the SQL level, and Hibernate won't skip the join:

SELECT u FROM User u 
JOIN FETCH u.userRoles ur 
WHERE ur.name = 'ADMIN'

2. Join a Nested Unloaded Association #

If you need to join beyond the initially fetched association (e.g., joining UserRole.articles after fetching User.userRoles), target the nested lazy association directly. Hibernate will generate the necessary SQL join because this association isn't loaded yet:

SELECT u FROM User u 
JOIN FETCH u.userRoles ur 
JOIN ur.articles a 
WHERE a.name = 'Spring Guide'

3. Avoid Redundant Association Joins #

Don't join the same association multiple times. If you need to apply different filters to the same association, structure the query to handle all logic in a single join (using aliases to reference the association) instead of adding redundant joins.

4. Native SQL (Last Resort) #

If you need full control over the JOIN logic and Hibernate's optimizations are getting in the way, use a native SQL query. This lets you define exactly which tables to join, bypassing Hibernate's query optimization layer.

Key Takeaway #

Hibernate's optimization is designed to reduce unnecessary database calls, but it can cause unexpected behavior when you expect explicit SQL joins. The cleanest fix is to align your query structure: combine fetching and filtering in one join, or target unloaded nested associations to trigger SQL-level joins.

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