You map a bidirectional one-to-one between two entities and set fetch = FetchType.LAZY on both sides, but Hibernate still issues an extra SELECT for the side declared with mappedBy. Why does that side ignore the lazy setting, and what can you do about it?

## The asymmetry at the root of it In a one-to-one, only one table carries the foreign key. Call the table that has it the **owning** side; the other side is mapped with `mappedBy` and is called the **inverse** side. When Hibernate loads the owning row, the FK column comes back with the row itself. Two facts are therefore free: - whether the association is set (the column is null or not), and - the identifier of the target (the column's value). That is exactly what a lazy proxy needs: a type and an id. So `fetch = LAZY` on the owning side works. When Hibernate loads the **inverse** row, it has nothing. There is no column on this table pointing anywhere. The only way to answer "does a matching row exist, and what is its id?" is `select ... from other_table where fk = ?`. And Hibernate cannot avoid the question, because the Java field must be assigned *something* right now: either a proxy or `null`. A proxy that initialises to nothing is not representable — the field type is the entity, not `Optional`. Hibernate therefore issues the select immediately, and the `LAZY` hint has no effect. This is the same reason a lazy to-one that is `optional = true` cannot be deferred without enhancement even on the owning side in some mappings: nullability, not distance, is the blocker. ## Why the symptom is easy to miss Loading one parent shows one extra select — invisible in a unit test. Loading a page of parents shows one extra select *per row*, which is where it becomes a production problem. The mapping looks correct in code review because both sides say `LAZY`, so the usual reaction is disbelief; verifying with SQL logging is the fastest way to settle it. ## The fixes ### 1. Drop the inverse side The cheapest fix is usually to not map the reverse direction at all. Keep the association unidirectional from the FK holder, and when you need to go the other way, run a query: `select c from Child c where c.parent = :parent`. You lose `parent.getChild()` sugar and gain complete control over when the query runs. For read-mostly domains this is very often the right answer. ### 2. Share the primary key If the child's primary key *is* the parent's primary key — a genuine one-to-one extension table — map it with a derived identifier: ```java @Entity class ProfileDetails { @Id Long id; @MapsId @OneToOne(fetch = LAZY) @JoinColumn(name = "id") User user; } ``` Now the parent's inverse side knows the child's identifier a priori: it equals its own. Hibernate can create a reference without a lookup. The remaining catch is existence — if the child row may be missing, Hibernate still has to check unless you declare it non-optional. Shared-key one-to-ones are also better modelling: they make the 1:1 cardinality enforceable by the database via a primary-key/unique constraint rather than by convention. ### 3. `optional = false` + bytecode enhancement Declare `@OneToOne(mappedBy = "...", fetch = LAZY, optional = false)` and turn on build-time bytecode enhancement with lazy initialisation enabled (Gradle/Maven Hibernate enhance plugin). `optional = false` is a promise that the row always exists, which removes the null-or-proxy dilemma; enhancement gives Hibernate interception inside the entity itself rather than relying on a subclass proxy, so it can defer the load until the field is read. If you break the promise — the row is sometimes missing — you get an exception at access time instead of a silent null, so only use it when a constraint actually enforces presence. ### 4. Historical option Hibernate 5 offered `@LazyToOne(LazyToOneOption.NO_PROXY)`, which combined with enhancement achieved the same effect. It was deprecated and removed in Hibernate 6; do not cite it as a current answer, but recognising it in legacy code is useful. ## How to talk about it The strong answer names the cause in one line — *no FK column on the inverse side, so existence is unknown, so no proxy* — then ranks the fixes by how much of the model they change. Reaching straight for enhancement without mentioning the option of dropping the inverse side reads as tool-first thinking.