MySQL - CONVERT_TZ 제거 후 별도 처리 개념

✅ CONVERT_TZ(UTC_TIMESTAMP(), 'UTC','+9:00') 제거 후 별도 처리 개념

👉 1. 문제: SELECT 절에서 함수 사용 시 비효율 발생

SELECT id,
       CONVERT_TZ(UTC_TIMESTAMP(), 'UTC','+9:00') AS my_time
FROM my_table;

이렇게 하면,
✅ UTC_TIMESTAMP()는 한 번만 실행되지만,
❌ CONVERT_TZ()는 모든 행(row)마다 실행됨 (비효율적!)
👉  즉, UTC_TIMESTAMP()는 MySQL 내부에서 바로 처리하지만,
CONVERT_TZ()는 타임존 테이블을 조회하고 연산을 수행해서 상대적으로 느림
🔹 예시) 10만 건 조회 시

• CONVERT_TZ(UTC_TIMESTAMP(), 'UTC','+9:00') 10만 번 실행됨
• CPU 사용량 증가 → 쿼리 느려짐

---

👉 2. 해결책: 서브쿼리 또는 변수 활용하여 연산 최소화

✅ 방법 1: 서브쿼리 활용 (SELECT (서브쿼리))

SELECT id,
       (SELECT CONVERT_TZ(UTC_TIMESTAMP(), 'UTC','+9:00')) AS my_time
FROM my_table;

• UTC_TIMESTAMP() 변환이 한 번만 실행됨
• 모든 행이 같은 값을 사용 → 불필요한 반복 연산 제거

✅ 방법 2: 애플리케이션에서 처리 (변수 활용)

SET @my_time = CONVERT_TZ(UTC_TIMESTAMP(), 'UTC','+9:00');

SELECT id, @my_time AS my_time
FROM my_table;

• 쿼리 실행 전에 변수(@my_time)에 값 저장
• @my_time 값을 모든 행에서 재사용 → 1회 연산으로 최적화

✅ Q: 모든 함수가 SELECT 절에서 비효율적인가?

❌ NO!
일부 함수는 SELECT 절에서 사용해도 문제없지만,
반복 실행되는 연산(비싼 함수)은 미리 처리하는 것이 성능상 유리!
함수 유형 SELECT에서 직접 사용 가능? 최적화 필요 여부

함수 유형	SELECT에서 직접 사용 가능?	최적화 필요 여부(대용량 데이터인 경우)
NOW()	✅ (한 번만 실행됨)	불필요
CURRENT_TIMESTAMP()	✅ (한 번만 실행됨)	불필요
SUBSTRING(), UPPER(), LOWER()	🔶 (행수가 적으면 더 빠름)	✅ 애플리케이션에서 처리 or 그냥 사용
CONVERT_TZ()	❌ (모든 행마다 실행됨)	✅ 서브쿼리/변수 사용
RAND()	❌ (행마다 실행, 랜덤 값 생성)	✅ LIMIT + ORDER BY RAND() 대체
ST_DISTANCE() (GIS 연산)	❌ (비싼 연산)	✅ 사전 계산하여 저장 추천

💡 결론:

• 대용량 데이터인 경우 최적화가 필요하며, 아닌 경우는 그냥 써도 무방하다고 생각한다.
• 단순한 함수 (NOW(), CURRENT_TIMESTAMP()) → SELECT에서 직접 사용 가능
• 비싼 함수 (CONVERT_TZ(), RAND(), ST_DISTANCE()) → 서브쿼리/변수 활용하여 최소 실행

---

🚀 실무에서 적용 예시

✅ SELECT 절에서 반복 실행되는 함수 최적화

SET @current_kst = CONVERT_TZ(UTC_TIMESTAMP(), 'UTC','+9:00');

SELECT id, @current_kst AS my_time
FROM my_table;

✅ 함수 실행 횟수: 1회 → 성능 최적화 🚀

✅ 애플리케이션 레벨에서 처리 (권장)

python
my_time = get_current_time_kst()  # Python에서 UTC → KST 변환

query = f"""
    SELECT id, '{my_time}' AS my_time
    FROM my_table;
"""

✅ DB 부하를 줄이고, 애플리케이션에서 처리

---

✅ 결론: SELECT 절에서 함수는 언제 서브쿼리로 빼야 할까?

1. 모든 행마다 반복 실행되는 함수(CONVERT_TZ, RAND() 등...)
   → 서브쿼리 or 변수 활용하여 한 번만 실행되도록 변경
2. 비싼 연산 (GIS 연산, 텍스트 변환 등)→ 사전 계산 후 별도 컬럼 저장 또는 애플리케이션에서 처리
3. 고정된 값(NOW(), CURRENT_TIMESTAMP())→ 직접 사용 가능 (MySQL이 한 번만 실행함)

---

🔥 최적화 원칙 정리

✅ 비싼 연산은 최소한으로 실행!
✅ 고정된 값은 변수나 서브쿼리로 빼서 실행 횟수를 줄이자!
✅ 애플리케이션에서 처리할 수 있는 건 DB에서 하지 말자!
이렇게 하면 MySQL 성능이 훨씬 개선될 수 있음! 🚀