작성
·
394
0
상속 전략을 join 방식으로 해서 다른 엔티티와 @OneToMany 연관관계를 지닌 자식 테이블이 N개 있습니다. Join type으로 상속된 엔티티를 제거하고자 했을 때 entitymanager.remove 를 사용하면 엔티티가 가진 연관관계의 엔티티를 select 쿼리로 조회 후 Delete 쿼리를 수행하게 되는데 Delete 쿼리들이 In 쿼리로 발생하지 않아 삭제 쿼리마다 하나씩 발생합니다.
(batch size로 모든 쿼리가 적용되는 줄 알았는데 select의 경우만 적용 되는 줄 몰랐습니다 ㅠㅠ)
delete 쿼리를 In 쿼리로 최적화하고 싶어서 JPQL(Querydsl)을 작성했는데 where id in 방식으로 제거하는 쿼리를 작성해서 실행해보니 HT_TABLE이라는 임시 테이블이 생기면서 삭제 쿼리에 서브쿼리가 추가되는식으로 제거가 되었습니다.
이 경우 네이티브 쿼리를 사용하지 않고 삭제 쿼리를 최적화 할 수 있는 방법이 궁금합니다... HT_TABLE 임시 테이블은 왜 생기는지 원인을 모르겠습니다.
그리고 join type의 경우 자식 엔티티가 N개 생길 수록 조회시 조인 테이블이 N개 증가하는(?) 어마어마한 성능 저하가 있을 것 같은데 실무에서도 사용하는 방법인지 궁금합니다.
답변 1
2
안녕하세요. 신영진님
다음 글을 읽어보시면 원하는 답을 찾을 수 있을꺼에요.
https://in.relation.to/2017/02/01/non-temporary-table-bulk-id-strategies/
그리고 추가로 질문주신 join type의 경우 자식 엔티티가 N개 생길 수록 조회시 조인 테이블이 증가하는 단점이 있습니다. 그런 단점을 피하고 싶으면 single_table 전략을 선택해야 합니다.
그런데 정말 join type에서 성능이 어마어마하게 저하되는가? 라고 하면, 사람마다. 그리고 시스템 상황마다 다르지만, 생각보다는 저하가 크지 않습니다. 왜냐하면, JOIN 전략을 선택하면, JOIN을 PK 기준으로 하게 되는데, 이미 PK 키가 정해져 있기 때문에, INDEX 최적화가 매우 잘 된 상태로 JOIN이 발생하기 때문입니다^^
실제 적용시에 트래픽에 민감하게 반응해야 하는 시스템이라면 데이터를 미리 넣어보고 성능테스트를 하는 것을 권장드립니다.
감사합니다^^