延迟加载（使用FK的一对一）问题

Question

当执行session . create query(" from Author ")时。list()；即使关系被标记为optional=false，fetch type = lazy from Author-

Hibernate:选择author0_。作者ID为作者I1 0，作者0。电子邮件为email2_0_，author0_。名为name3_0_ from AUTHOR author0_

Hibernate：选择“book0_”。BOOK_ID为BOOK_ID1_1_0_，book0_。AUTHOR_ID为AUTHOR_I5_1_0_，book0_描述为descript2_1_0_，book0_。作为PUBLISHE3_1_0_出版，book0_.title作为title4_1_0_来自BOOK book0_，book0_。AUTHOR_ID=？

Hibernate：选择“book0_”。BOOK_ID为BOOK_ID1_1_0_，book0_。AUTHOR_ID为AUTHOR_I5_1_0_，book0_描述为descript2_1_0_，book0_。作为PUBLISHE3_1_0_出版，book0_.title作为title4_1_0_来自BOOK book0_，book0_。AUTHOR_ID=？

Hibernate：选择“book0_”。BOOK_ID为BOOK_ID1_1_0_，book0_。AUTHOR_ID为AUTHOR_I5_1_0_，book0_描述为descript2_1_0_，book0_。作为PUBLISHE3_1_0_出版，book0_.title作为title4_1_0_来自BOOK book0_，book0_。AUTHOR_ID=？

Hibernate：选择“book0_”。BOOK_ID为BOOK_ID1_1_0_，book0_。AUTHOR_ID为AUTHOR_I5_1_0_，book0_描述为descript2_1_0_，book0_。作为PUBLISHE3_1_0_出版，book0_.title作为title4_1_0_来自BOOK book0_，book0_。AUTHOR_ID=？

Hibernate：选择“book0_”。BOOK_ID为BOOK_ID1_1_0_，book0_。AUTHOR_ID为AUTHOR_I5_1_0_，book0_描述为descript2_1_0_，book0_。作为PUBLISHE3_1_0_出版，book0_.title作为title4_1_0_来自BOOK book0_，book0_。AUTHOR_ID=？

Hibernate：选择“book0_”。BOOK_ID为BOOK_ID1_1_0_，book0_。AUTHOR_ID为AUTHOR_I5_1_0_，book0_描述为descript2_1_0_，book0_。作为PUBLISHE3_1_0_出版，book0_.title作为title4_1_0_来自BOOK book0_，book0_。AUTHOR_ID=？

@Entity
@BatchSize(size=3)
@Table(name = "AUTHOR")
public class Author {
    private long id;
    private String name;
    private String email;
    private Book book;


    public Author() {
    }

    public Author(String name, String email) {
        this.name = name;
        this.email = email;
    }

    @Id
    @Column(name = "AUTHOR_ID")
    @GeneratedValue
    public long getId() {
        return id;
    }

    public void setId(long id) {
        this.id = id;
    }

    public String getName() {
        return name;
    }

    public void setName(String name) {
        this.name = name;
    }

    public String getEmail() {
        return email;
    }

    public void setEmail(String email) {
        this.email = email;
    }

    @OneToOne(cascade=CascadeType.ALL,fetch=FetchType.LAZY,optional=false,mappedBy="author")
    public Book getBook() {
        return book;
    }

    public void setBook(Book book) {
        this.book = book;
    }


@Entity
@BatchSize(size=3)
@Table(name = "BOOK")
public class Book {

     private long id;
        private String title;
        private String description;
        private Date publishedDate;

        private Author author;

        public Book() {
        }

        @Id
        @Column(name = "BOOK_ID")
        @GeneratedValue
        public long getId() {
            return id;
        }

        public void setId(long id) {
            this.id = id;
        }

        public String getTitle() {
            return title;
        }

        public void setTitle(String title) {
            this.title = title;
        }

        public String getDescription() {
            return description;
        }

        public void setDescription(String description) {
            this.description = description;
        }

        @Temporal(TemporalType.DATE)
        @Column(name = "PUBLISHED")
        public Date getPublishedDate() {
            return publishedDate;
        }

        public void setPublishedDate(Date publishedDate) {
            this.publishedDate = publishedDate;
        }

        @OneToOne(cascade=CascadeType.ALL,fetch=FetchType.LAZY,optional=false)
        @JoinColumn(name ="AUTHOR_ID",unique=true)
        public Author getAuthor() {
            return author;
        }

        public void setAuthor(Author author) {
            this.author = author;
        }
    }

Answer 1

您忽略了从< code>Author到< code>Book的链接不是双向关联的定义所有者，我的意思是它被定义为mappedBy，而FK驻留在< code>Book表中。因此，当检索到一个作者时，它需要查询Book表来检查FK，并找出是否有一本书以及每个作者关联了哪本书。这就是为什么您在book表上看到的select语句与您拥有的作者一样多(这就是所谓的N 1查询问题)。

避免这种情况的一种方法是切换关联的所有者侧（在Author表中定义一个FK到Book），但您将看到类似的图书查询行为。

如果您关心的是并行查询，那么一个选项是在查询中应用获取策略，强制检索与作者关联的书籍。查询将类似于，会话。createQuery（“从作者a左连接获取a.book”）.list（）

我告诉过您原因和基本解决方案/解决方法，但也有更复杂的选项，您肯定可以在stackoverflow中找到它们。