🚀 [feature] 브리핑 목록 조회 V2 쿼리 튜닝

[swa07016]

🤖 기능 개요

브리핑 목록 조회 V2 쿼리를 튜닝합니다.

• 현재 실행 계획 결과

{
    "id": 1,
    "select_type": "SIMPLE",
    "table": "b",
    "partitions": null,
    "type": "ALL",
    "possible_keys": "idx_briefing_id",
    "key": null,
    "key_len": null,
    "ref": null,
    "rows": 1966,
    "filtered": 10,
    "Extra": "Using where; Using temporary; Using filesort"
  }

- 테이블 Full Scan을 하고 있습니다.
- 옵티마이저가 1966건 (거의 모든 행)을 검사하고 있습니다.
- 검사한 행들중 10%정도만 유효합니다.

• 쿼리 실행 속도

-> Limit: 20 row(s)  (actual time=7.34..7.35 rows=20 loops=1)
    -> Sort: date_format(b.created_at,'%Y-%m-%d %H') DESC, b.ranks, limit input to 20 row(s) per chunk  (actual time=7.34..7.35 rows=20 loops=1)
        -> Table scan on <temporary>  (actual time=7.05..7.15 rows=388 loops=1)
            -> Aggregate using temporary table  (actual time=7.05..7.05 rows=388 loops=1)
                -> Nested loop left join  (cost=319 rows=230) (actual time=0.767..3.28 rows=397 loops=1)
                    -> Filter: (b.`type` = 'SOCIAL')  (cost=246 rows=197) (actual time=0.752..2.7 rows=388 loops=1)
                        -> Table scan on b  (cost=246 rows=1966) (actual time=0.0257..2.42 rows=2163 loops=1)
                    -> Covering index lookup on s using FK48tasjrnowinupvg2usjq2y9u (briefing_id=b.id)  (cost=0.251 rows=1.17) (actual time=0.00116..0.00127 rows=0.0902 loops=388)

지금은 데이터가 적으니, 속도가 괜찮지만 매일 80건씩 테이블에 쌓이는 상황에서 미리 튜닝해 둘 필요가 있어보입니다.

📚 Remarks

적절히 인덱스를 두어서 해결할 생각입니다.