저장된 전체 링크 개수 조회 API 구현

[ckdals4600]

관련 이슈

• close 전체 링크 개수 조회 API 개발 #202

PR 설명

• Endpoint: GET /v1/links/count
• Response

     {
       "totalCount": 42
     }
  

비즈니스 로직 및 Repository

• LinkFacade -> LinkService -> LinkQueryService로 이어지는 읽기 전용 서비스 계층 파이프라인을 구축함.
• LinkRepository: 메모리 낭비와 쿼리 부하를 방지하기 위해 엔티티를 직접 조회하지 않고, 데이터베이스 레벨에서 카운트를 수행하는 countByMemberAndIsDeleteFalse 쿼리 메서드를 선언 및 적용함.

[github-actions]

📊 코드 커버리지 리포트

Overall Project	93.24%	🍏
Files changed	100%	🍏

File	Coverage
LinkController.java	100%	🍏
LinkFacade.java	100%	🍏
LinkService.java	100%	🍏
LinkQueryService.java	99.23%	🍏

[Goder-0]

해당 방향성으로 구현시, (member_id, is_delete) 복합 인덱스가 필요할 것 같습니다. 해당 인덱스 적용 제안드립니다.

[Goder-0]

PR 본문에 이슈번호 연결 부탁드립니다.

[ckdals4600]

해당 방향성으로 구현시, (member_id, is_delete) 복합 인덱스가 필요할 것 같습니다. 해당 인덱스 적용 제안드립니다.

엔드포인트에 해당 인덱스가 필요하다는 의견이실까요 ?

[Goder-0]

엔드포인트 자체 기준이라기보다, 실제 DB 조회 패턴 기준으로 드린 제안입니다.

예를 들어 이번 count 쿼리는 아래 형태로 실행됩니다.
SELECT COUNT(*) FROM link WHERE member_id = ? AND is_delete = false;

그리고 기존 조회도 유사하게 member_id + is_delete 조건을 함께 사용합니다.
SELECT ... FROM link WHERE member_id = ? AND is_delete = false ORDER BY id DESC LIMIT ?;
SELECT id FROM link WHERE member_id = ? AND url = ? AND is_delete = false;

이 패턴을 보면 (member_id, is_delete) 복합 인덱스가 공통 필터링 범위를 줄이는 데 유리해 보여 제안드렸습니다.

[ckdals4600]

엔드포인트 자체 기준이라기보다, 실제 DB 조회 패턴 기준으로 드린 제안입니다.

예를 들어 이번 count 쿼리는 아래 형태로 실행됩니다. SELECT COUNT(*) FROM link WHERE member_id = ? AND is_delete = false;

그리고 기존 조회도 유사하게 member_id + is_delete 조건을 함께 사용합니다. SELECT ... FROM link WHERE member_id = ? AND is_delete = false ORDER BY id DESC LIMIT ?; SELECT id FROM link WHERE member_id = ? AND url = ? AND is_delete = false;

이 패턴을 보면 (member_id, is_delete) 복합 인덱스가 공통 필터링 범위를 줄이는 데 유리해 보여 제안드렸습니다.

DB 인덱스까지는 미처 생각하지 못하고 있었는데, 설명해 주셔서 감사합니다.
말씀해주신 대로 대부분의 주요 조회 쿼리에서 member_id와 is_delete 조건이 공통으로 강하게 결합되어 사용되고 있어,
제안해주신 (member_id, is_delete) 복합 인덱스를 걸어두면 필터링 성능이 확실히 개선될 것 같습니다.
제안해주신 내용대로 복합 인덱스 추가 반영 완료했습니다!