gw

강의명만으로는 검색 결과가 불충분하여강의 목차 기반 검색까지 지원하기로 함ex) 강의 검색 : 객체지향@Query(""" SELECT a FROM 강의 a JOIN FETCH 강의.강의목차 b WHERE a.name LIKE %:keyword% OR b.name LIKE %:keyword% ORDER BY a.id DESC""")Page search(@Param("keyword") String keyword, Pageable pageable);검색 결과● 자바 ORM 표준 JPA 프로그래밍 - 기본편● 자바 ORM 표준 JPA 프로그래밍 - 기본편ㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡㅡ직접 결과 테스트를 해본건 아니라 문제 이상하면 얘기 좀요

게시판 board 칼럼에칼럼 status varchar(10) 존재함 데이터 분포상 DONE이 99.99999%일수도 있고DONE이 0.000000000001%일 수도 있다고 가정함 select * from board where status != 'DONE' order by id desc limit 10;가 17~18초 걸림=> 여기서 PRIMARY KEY(id)로 역순으로 읽는데 최신글이 전부 DONE이면 DONE이 아닌 것을 찾으려고 LIMIT 10 채울 때까지 수십만 건을 읽어야함 샘플링 튜닝 기법select status from board order by id desc limit 100; 100건을 가져와서 DONE 분포를 파악 IF) status 100건이 모두 DONE이면select * fro..

CREATE TABLE `product` ( `id` int NOT NULL AUTO_INCREMENT, `name` varchar(100) DEFAULT NULL, `created_at` datetime DEFAULT NULL, `display` varchar(3) DEFAULT 'N', PRIMARY KEY (`id`), KEY `display` (`display`)) ENGINE=InnoDB AUTO_INCREMENT=10001 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ciCREATE TABLE `review` ( `id` int NOT NULL AUTO_INCREMENT, `product_id` int DEFAULT NULL, `scor..

방법1select *from order // 2020~2026년 주문where주문 날짜 between '2026-02-10' and '2026-03-10'and status = ?order by 배송 일자 limit 10;방법2select *from order // 2020~2026년 주문where주문 날짜 between '2026-02-10' and '2026-03-10'and status = ?어플리케이션 단에서 정렬 후 slice로 페이징 뽑기방법1의 장점 단점방법2의 장점 단점을 설명해주세요.

mysqlselect *from order // 2020~2026년 주문where주문 날짜 between '2026-02-10' and '2026-03-10'and status = ?order by 배송 일자 limit 10;인덱스는 (status) (주문날짜) (배송일자) 세개 있음status는 비율이 매우 적은 것도 있고비율이 많은 것도 있음날짜범위도 유동적으로 변경 가능현재 실행계획은 아래와 같음딱 쿼리만 고칠 수 있음위와 같은 실행계획에서 쿼리가 오래 걸리는데 속도 개선하기

order 테이블에 최근 5년 치 주문이 저장됨상황상 취소건 비율이 많다고 가정취소가 20%로 가정order_date 주문 날짜cancel_at 취소 날짜인덱스는 (order_date), (cancel_at) 두개만 존재함select *from orderwhereorder_date between '2025-03-08' and '2026-03-08'cancel_at is not nullorder by cancel_at limit 10;1. 이 쿼리가 느린 이유를 논리적으로 설명2. 해결방안

대용량 트래픽/데이터에 대한 사고 과정 정리어디까지나 내가 회사에서 경험한 것 바탕임왠만한 기업이 아닌 이상평상시 트래픽은 굉장히 낮을 것임가장 중요한 것은지금 이 순간에 얼만큼 굵게 들어오지는가 중요함그 지표는 주로 TPS / QPS로 측정됨이렇게 선착순이나 알림톡 / 마케팅으로특정 이벤트 발생 시 유입이 몰려오고그때 서버가 터지는 경우가 대부분임1. 기본적으로 대기열로 막는다.예를 들어, 정보처리기사 접수할 때@@명이 대기 중입니다.잠시만 기다려주세요.현재 페이지를 벗어나면 대기순번이 초기화됩니다.이부분은 DevOps팀 담당이라 자세하게 말은 못하겠음2. 웹서버 단에서 스케일 아웃로드밸런서 뒤로 어플리케이션 서버를 여러개 둬서 적절히 부하를 분산함3. 무거운 작업을 하는 배치 작업/어드민 서버는 별도..

CREATE TABLE `user_points` ( `id` bigint NOT NULL, `user_id` bigint DEFAULT NULL, `amount` int DEFAULT NULL, `used_amount` int DEFAULT '0', `expired` char(1) DEFAULT 'N', `expire_at` datetime DEFAULT NULL, PRIMARY KEY (`id`), KEY `idx_expire_at` (`expire_at`), KEY `idx_expired` (`expired`)) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ciUPDATE user_pointsSET expired = '..

설마 DB가 다운되겠어? 싶은 경우가 자주 나옴MySQL innoDB는 보통 버퍼풀 사이즈를메모리의 80% 정도까지 잡는 경우가 많은데대부분의 경우엔 문제가 없지만데이터베이스 서버에서 DB외 다른 작업을 같이 수행하거나대량 Bulk Insert를 실행하면남은 20% 메모리에서 쓰게 되고 그 한계를 초과시Out Of Memory가 발생하여 DB가 kill 당해 강제로 재시작이 될 수 있다.(재기동 시간동안 장애 발생)DB서버에서 다른 무언가를 실행할때는 메모리 여유가 있는지 신중하여야 한다.

MySQL innoDB는 보통 버퍼풀 사이즈를메모리의 80% 정도까지 잡는 경우가 많은데대부분의 경우엔 문제가 없지만데이터베이스 서버에서 DB외 다른 작업을 같이 수행하거나대량 Bulk Insert를 실행하면남은 20% 메모리에서 쓰게 되고Out Of Memory가 발생하여 DB가 강제로 재시작이 될 수 있다.DB서버에서 다른 무언가를 실행할때는 메모리 여유가 있는지 신중하여야 한다.