UPDATE 한 방이 커밋되기까지 InnoDB 안에서 무슨 일이 생기나요?

버퍼 풀 선반영 → 리두 로그 기록·플러 → 데이터 파일 쓰기는 체크포인트로 분리 → 언두 로그의 이전 버전 보관 역할

리두 로그와 언두 로그의 역할을 대비해 설명해 주세요.

리두 로그=재실행(앞으로), 언두 로그= → 각각의 사용처(리두 로그는 복구, 언두 → 바이너리 로그와 섞지 않음

쿼리 하나가 MySQL 서버에 들어와서 결과가 나가기까지, 어떤 컴포넌트를 거치고 InnoDB 안에서는 무슨 일이 일어나는지 설명해 주세요.

MySQL 엔진(커넥션 핸들러·파서·전처 → InnoDB는 버퍼 풀에 페이지를 캐시해 → 변경은 리두 로그로 내구성을, 언두 로그

AHI(적응형 해시 인덱스)가 뭔지 설명해 주세요.

자주 타는 B-Tree 경로의 자동 해시 → DBA가 만들지 않는 자동 기능 → 동등 조회용, 경합 시 병목과 대응

InnoDB와 MyISAM을 비교하고, 엔진을 섞어 쓰면 안 되는 이유를 말해 주세요.

트랜잭션·잠금·외래 키 세 축 비교 → MyISAM의 무시되는 외래 키 함정 → 혼용 시 원자성 붕괴

느린 쿼리를 찾고 고치는 흐름을 설명해 주세요.

슬로우 쿼리 로그 발굴 → 집계 → EX → `long_query_time`과 인덱스 → 수정 후 재측정까지 말하면 만점

에러 로그·제너럴 로그·슬로우 쿼리 로그의 용도를 구분해 주세요.

에러 로그=장애·복구, 제너럴 로그=전체 → 제너럴 로그 상시 ON의 위험 → 막히면 에러 로그부터라는 우선순위

MVCC(다중 버전 동시성 제어)가 뭔지, 읽기와 쓰기가 서로 안 막히는 원리로 설명해 주세요.

행 버전 체인(언두 로그)과 스냅샷 가시 → 일반 SELECT는 잠금 없이 자기 버전 → REPEATABLE READ와 READ

서버가 죽었다 떴을 때 InnoDB가 스스로 하는 일을 설명해 주세요.

리두 로그 재생(roll-forward) → 자동 내장 과정이라는 점 → 크래시 복구와 시점 복구(백업+바이너리

MyISAM 구조를 세 줄로 요약하고, 언제 쓰는지 말해 주세요.

트랜잭션 없음·테이블 락·힙 저장 → 키 캐시(인덱스만)와 OS 캐시 분담 → `COUNT(*)` 특성과 레거시 호환이

MyISAM 테이블에 쓰기가 몰리면 무슨 일이 생기나요?

테이블 쓰기 락의 전체 차단 → 읽기 대기 줄섬과 쓰기 기아(starva → InnoDB로 이전하는 것이 정석 대응

쿼리 한 방이 MySQL 안에서 어떻게 실행되는지 설명해 주세요.

커넥션·스레드 → 파서 → 옵티마이저 → → 서버 층과 엔진 분리(플러그인) 이해 → 각 단계의 역할 한 줄씩

동시 접속자가 폭증하면 MySQL에서 무슨 일이 생기나요?

커넥션당 스레드 → 컨텍스트 스위칭·메모 → `max_connections`와 세션 → 커넥션 풀·스레드 풀 등 대응 방향

InnoDB 테이블 압축을 언제 쓰고 언제 피해야 하나요?

ROW_FORMAT=COMPRESSED와 → 디스크·I/O(입출력)는 줄지만 CPU와 → 읽기 위주·큰 텍스트·아카이브 성격 데이

페이지 압축과 테이블 압축을 구분해 설명해 주세요.

투명 페이지 압축과 KEY_BLOCK_S → 버퍼 풀 이중 적재 유무 → 파일 시스템 요구사항 차이

압축을 쓸지 말지 어떻게 판단하나요?

읽기 위주인지 쓰기 위주인지 워크로드 판 → 방식별 측정 지표 구분 → 효과가 안 나오면 끈다는 결론

새 서비스의 회원·주문 테이블을 만든다면 칼럼 타입을 어떤 기준으로 고르겠습니까? 문자열·숫자·날짜 칼럼을 예로 설명해 주세요.

문자열은 길이가 고정인 코드는 CHAR, → VARCHAR 길이는 바이트로 255 경 → 커지는 PK는 BIGINT, 금액은 DE

TEXT나 BLOB 칼럼을 쓸 때 주의할 점은 무엇인가요?

기본 행 포맷 DYNAMIC은 행에 안 → 그래서 큰 값을 읽으면 페이지를 더 읽으 → 인덱스는 앞부분 길이를 정한 접두어 인덱

생성 칼럼(generated column)이 무엇이고, 어떤 문제를 풀 때 쓰나요?

같은 행의 다른 칼럼으로 계산한 값을 담 → InnoDB는 가상 칼럼에도 세컨더리 인 → 식에는 결정적인 내장 함수·연산자와 같은

MySQL에서 JSON 칼럼은 언제 쓰고, 언제 일반 칼럼으로 나눠야 하나요?

JSON 타입은 유효성 검사, 바이너리 → 종류마다 속성이 달라 칼럼으로 만들기 어 → WHERE·조인·정렬에 자주 쓰거나 NO

AUTO_INCREMENT 번호에 빈틈이 생기는 이유와, InnoDB가 동시 INSERT에 번호를 나눠 주는 방식을 설명해 주세요.

innodb_autoinc_lock_mo → 8 → 발급한 번호는 롤백해도 반납하지 않고,

DATETIME과 TIMESTAMP의 차이를 설명하고, 각각 어떤 칼럼에 쓰겠는지 말해 주세요.

TIMESTAMP는 저장할 때 세션 시간 → TIMESTAMP는 UTC 2038-01 → 여러 시간대에서 같은 순간을 봐야 하는

금액 칼럼에 FLOAT이나 DOUBLE을 쓰면 안 되는 이유는 무엇인가요?

FLOAT·DOUBLE은 2진 소수로 근 → 그래서 합계가 조금씩 틀어지고 같음 비교 → 금액은 10진 자릿수를 그대로 저장하는

CHAR와 VARCHAR는 어떻게 다르고, 각각 언제 쓰나요?

CHAR는 선언 길이만큼 공백을 채워 자 → 괄호 안 숫자는 글자 수이고 실제 바이트 → 길이가 늘 같은 코드값은 CHAR, 길이

utf8mb4와 콜레이션(문자열 비교·정렬 규칙)이 무엇이고, 콜레이션을 잘못 고르면 어떤 문제가 생기나요?

문자 집합은 글자를 바이트로 바꾸는 규칙 → 콜레이션은 비교·정렬 규칙이며 이름 조각 → 0900 콜레이션은 NO PAD라 뒤쪽

새 서비스의 데이터베이스를 설계한다면 어떤 순서와 기준으로 하겠습니까? 정규화, 반정규화, NoSQL 선택까지 묶어서 설명해 주세요.

업무 규칙에서 함수 종속과 후보 키를 찾 → 1NF 원자값, 2NF 부분 함수 종속 → 느린 쿼리를 측정해 인덱스·쿼리·캐시를

제1정규형부터 제3정규형까지 각각 무엇을 제거하는지 예를 들어 설명해 주세요.

제1정규형은 모든 칸이 원자값이어야 하며 → 제2정규형은 비주 속성이 후보 키 전체에 → 제3정규형은 비주 속성이 키가 아닌 다른

BCNF(보이스-코드 정규형)는 제3정규형과 무엇이 다른가요?

BCNF는 모든 결정자가 슈퍼 키여야 하 → (학생, 과목, 교수)에서 교수 → 과목 → BCNF 분해는 무손실이지만 종속 보존이

반정규화는 언제 하고, 하면 무엇을 대가로 치르나요?

반정규화는 정규화한 설계에서 조회 성능을 → 대가는 쓰기·공간 증가와 복사본을 놓쳤을 → 먼저 3NF까지 정규화하고, 느린 쿼리를

정규화는 왜 하나요? 정규화하지 않은 테이블에서 생기는 문제를 예로 들어 설명해 주세요.

정규화는 테이블 하나에 한 주제의 사실만 → 중복 때문에 갱신 이상(일부만 고쳐 어긋 → 구체 예(수강 테이블의 학과 전화 변경,

슈퍼 키, 후보 키, 기본 키, 대체 키의 차이를 설명해 주세요.

슈퍼 키는 행을 유일하게 구분하는 칼럼 → 후보 키는 슈퍼 키 중 칼럼을 하나라도 → 기본 키는 후보 키 중 대표로 고른 하나

CAP 정리를 설명하고, 흔한 오해가 무엇인지 말해 주세요.

일관성(모든 읽기가 최신 쓰기 또는 오류 → 네트워크 분할은 피할 수 없어 분할 내성 → CAP의 일관성은 최신 값 가시성이며 A

NoSQL의 종류를 설명하고, 각각 어떤 데이터에 맞는지 말해 주세요.

키-값 저장소는 키로만 넣고 꺼내며 캐시 → 문서 DB는 JSON 같은 문서를 저장하 → 와이드 칼럼 저장소는 행 키로 나눠 쓰기

MySQL에서 저장 데이터 암호화(TDE, 투명한 데이터 암호화)는 어떻게 동작하고, 운영할 때 무엇을 챙겨야 하나요?

테이블스페이스 단위로 ENCRYPTION → 2단계 키 구조 → 데이터 파일 유출은 막지만 접속한 사용자

MySQL TDE(투명한 데이터 암호화) 구조를 설명해 주세요.

2단계 키(마스터 키와 테이블스페이스 키 → 키링 보관과 테이블 지정 → 로그(언두·리두·바이너리) 범위

DB 암호화와 애플리케이션 암호화 중 뭘 쓰나요?

TDE는 디스크 탈취 방어 → 애플리케이션 암호화는 관리자·덤프 유출까 → 민감도에 따라 둘을 겹칠지 판단

EXPLAIN(실행 계획 조회) 결과를 어떻게 읽는지, 보는 순서대로 설명해 주세요.

type·key·rows·Extra 중심 → ALL이면 원인 찾기, key는 의도한 → id 순서로 보는 조인 흐름

type ALL(풀 테이블 스캔)이 나왔습니다. 원인과 처방을 말해 주세요.

읽기 비율에 따라 정당할 수 있다는 전제 → 통계·함수 가공·타입 불일치·선택도·인덱 → ANALYZE로 통계 갱신, 쿼리·인덱스

EXPLAIN과 EXPLAIN ANALYZE의 차이를 설명하고, 언제 뭘 쓰는지 말해 주세요.

예상과 실측의 구분 → 둘이 어긋나면 통계를 의심한다는 진단 연 → 지원 범위와 변경 문장 실측 시 주의

쿼리 튜닝 요청이 왔습니다. 처음부터 끝까지 흐름을 말해 주세요.

재현·측정, EXPLAIN, 원인 파악, → 슬로우 쿼리 로그로 발굴하고 EXPLAI → 캐시 조건 통제의 언급

느린 쿼리를 받았을 때 EXPLAIN으로 어떻게 진단하고 무엇을 고치는지, 과정을 설명해 주세요.

EXPLAIN은 예상 계획, EXPLAI → type 칼럼으로 접근 방식(const· → key·key_len으로 어떤 인덱스를

통계 정보가 실행 계획에 어떤 영향을 주는지 설명해 주세요.

행 수·카디널리티·페이지 수가 비용 계산 → 통계가 틀리면 계획이 틀어진다는 인과 → ANALYZE TABLE이 첫 단추라는

히스토그램이 뭔지, 언제 필요한지 말해 주세요.

값 분포 기록이라는 정의 → 치우친 분포에서 범위 조건 비용을 정확하 → 카디널리티만으로 부족한 경우

MySQL 서비스의 고가용성을 어떻게 설계하겠습니까? 장애 조치와 데이터 유실, 스플릿 브레인까지 포함해 설명해 주세요.

RTO(복구 시간)와 RPO(잃어도 되는 → 비동기 복제 기반 장애 조치는 유실과 스 → 그룹 복제는 과반수 합의와 충돌 검사로

고가용성 구성에서 스플릿 브레인이란 무엇이고, 그룹 복제는 장애를 어떻게 감지하고 견디나요?

스플릿 브레인은 네트워크만 끊긴 옛 소스 → 멤버 메시지가 5초 끊기면 UNREACH → 결정에는 과반수(정족수)가 필요하고 f대

InnoDB 클러스터는 어떻게 구성되고, 도입하려면 테이블과 서버 설정에 어떤 조건이 필요한가요?

그룹 복제(합의·자동 프라이머리 선출) → 애플리케이션은 Router에 접속하고, → InnoDB만, 모든 테이블에 PK(또는

그룹 복제에서 세컨더리를 읽을 때 최신 데이터를 보장하려면 어떻게 하나요? 그리고 정족수를 잃으면 어떻게 복구하나요?

커밋 응답은 합의·충돌 검사 통과 뒤라 → group_replication_cons → 과반수를 잃은 쪽은 멈추며, 끊긴 멤버가

MySQL 그룹 복제는 트랜잭션 커밋을 어떻게 결정하고, 일반 비동기·반동기 복제와 무엇이 다른가요?

쓰기 트랜잭션은 커밋 때 바뀐 행과 쓰기 → 각 멤버가 같은 순서로 충돌 검사(cer → 커밋 응답은 합의·충돌 검사 통과 뒤이며

B-Tree 인덱스 구조를 그림 그리듯 설명해 주세요.

루트·브랜치·리프 3단과 각 역할(루트· → 리프의 양방향 링크와 범위 스캔의 연결 → 균형 유지로 탐색 비용이 일정하고, 팬아

UUID(범용 고유 식별자)를 PK(기본 키)로 쓰면 안 된다고 하던데, B-Tree 관점에서 왜 그런가요?

랜덤 키라서 리프 중간에 삽입되고, 그래 → 그 결과로 단편화·캐시 미스·쓰기 증폭이 → 순차 키(AUTO_INCREMENT)와의

(a, b) 인덱스가 있는데 b로만 조회하면 어떻게 되나요?

좌측 접두어 규칙: 왼쪽 칼럼부터 연속으 → 전화번호부 비유 등 직관적 설명 → 범위 조건 뒤 칼럼은 필터로만 쓰인다는

커버링 인덱스가 뭔지, 언제 효과가 큰지 설명해 주세요.

SELECT 목록이 인덱스 칼럼 안에 모 → EXPLAIN의 Using index로 → SELECT * 와의 대비, 랜덤 I/O

클러스터링 인덱스가 뭔지, 세컨더리 인덱스와 조회 경로가 어떻게 다른지 설명해 주세요.

PK 순서로 저장하고 리프에 행 전체를 → 세컨더리 리프에는 PK 값이 있어 조회가 → 커버링이면 한 단계로 끝난다는 예외

PK(기본 키) 설계 원칙(짧고·불변이고·순차적)의 근거를 설명해 주세요.

짧게: 세컨더리 인덱스마다 PK를 품음 → 불변: 변경 시 세컨더리 인덱스 연쇄 갱 → 순차적: 끝에 삽입돼 페이지 분할 회피

인덱스가 왜 빠른지, 디스크 I/O(입출력) 관점에서 설명해 주세요.

랜덤 I/O와 순차 I/O의 차이를 안다 → 인덱스는 읽는 페이지 수를 줄이는 장치라 → SSD 시대에도 작업량 절감·캐시 효율로

인덱스를 많이 만들면 안 되는 이유를 설명해 주세요.

쓰기 비용: INSERT·UPDATE·D → 공간 비용과 버퍼 풀 점유 → 읽기·쓰기 트레이드오프라는 결론

외래 키가 잠금 대기를 일으키는 두 장면을 설명해 주세요.

자식 변경 때 부모 행의 공유 락에서 대 → 부모 변경 때 자식을 검사하며, 자식 인 → FK 자식 칼럼 인덱스의 필수성

외래 키를 걸어야 할까요, 말아야 할까요?

찬반 근거를 트레이드오프로 제시 → 안 걸 때의 대안(애플리케이션 검증·배치 → 팀 규칙·규모에 따라 다르다는 결론

인덱스가 왜 빠른지부터 시작해서, MySQL InnoDB 인덱스를 설계할 때 무엇을 고려하는지 전체적으로 설명해 주세요.

인덱스의 목적은 랜덤 디스크 I/O(입출 → InnoDB는 PK(기본 키) 기준 클러 → 다중 칼럼 인덱스는 좌측 접두어 규칙을

B-Tree로 안 되는 검색 세 가지와 각각의 대안을 말해 주세요.

앞 와일드카드 LIKE에는 FULLTEX → 공간 조건에는 R-Tree → 함수로 가공한 조건에는 가상 칼럼·함수

JSON 칼럼에 인덱스를 걸 수 있나요?

가상 생성 칼럼으로 값을 추출하고 B-T → 배열 원소는 멀티 밸류 인덱스 → 스키마 유연성과 검색 사이의 절충이라는

유니크 인덱스와 PK(기본 키)의 차이를 설명하고, 각각 언제 쓰는지 말해 주세요.

NULL 허용 여부, 개수 제한, 클러스 → 대리 키(PK)와 업무 키(유니크) 분리 → NULL 여러 개 허용 함정

쿠폰 발급처럼 경합이 심한 유니크 키 처리에서 주의할 점을 말해 주세요.

유니크 동등 조건의 잠금 축소(레코드 락 → SELECT와 INSERT를 나누기보다 → 데드락·대기 가능성과 재시도

MySQL 성능 문제를 진단할 때 Performance 스키마와 sys 스키마를 어떻게 활용하나요?

Performance 스키마는 인스트루먼 → sys 스키마는 그 테이블을 목적별 뷰로 → sys

Performance 스키마에서 느린 쿼리를 찾을 때 어떤 테이블을 보나요? 이벤트 테이블과 요약 테이블은 어떻게 다른가요?

이벤트는 트랜잭션 안에 문장, 문장 안에 → 이벤트 테이블은 current(스레드마다 → events_statements_summ

운영 중인 MySQL에서 갑자기 쿼리들이 멈췄다는 신고가 오면 어떻게 원인을 찾겠어요?

먼저 잠금 대기인지 구분하고, 메타데이터 → DDL이 끼어 있으면 sys → 행 잠금이면 sys

Performance 스키마(서버 내부 성능 측정 기능)가 무엇이고, 슬로우 쿼리 로그와 무엇이 다른가요?

서버 코드 안의 측정 지점에서 문장·단계 → 인스트루먼트(측정 지점)와 컨슈머(저장할 → 다이제스트별 요약 테이블로 모든 문장을

USE·FORCE·IGNORE INDEX의 차이를 설명해 주세요.

USE는 제안, FORCE는 테이블 스캔 → 강도 순서와 각각의 용도 → 진단 후 사용이라는 전제

힌트를 넣어야 할 때의 원칙을 말해 주세요.

진단 후 확신, 범위 최소화, 이유 기록 → SET_VAR의 쿼리 한정 안전성 → 통계·인덱스가 근본이라는 인식

MySQL 옵티마이저가 실행 계획을 어떻게 고르는지, 그리고 정렬·조인 같은 비용이 큰 작업을 어떻게 처리하는지 설명해 주세요.

비용 기반 옵티마이저가 테이블·인덱스 통 → 접근 방식은 인덱스 레인지 스캔·풀 인덱 → 정렬은 인덱스 순서를 그대로 쓰는 것이

MySQL 8.4의 NL(Nested Loop)·BKA(Batched Key Access)·해시 조인을 구분해 설명해 주세요.

NL은 바깥 행마다 안쪽 입력을 탐색하며 → BKA는 바깥 키를 모아 MRR(다중 범 → 해시 조인은 한 입력으로 해시를 구축한

조인이 느립니다. 진단 순서를 말해 주세요.

드라이빙 순서, 매칭 방식, 조인 키 인 → EXPLAIN으로 순서·방식 확인 → 힌트·STRAIGHT_JOIN은 확신 있

옵티마이저가 실행 계획을 어떻게 고르는지 설명해 주세요.

파서, 전처리, 옵티마이저, 실행 순서로 → 비용 기반 옵티마이저(CBO)이며 통계에 → 통계가 틀리면 계획이 틀어진다는 결론

인덱스가 있는데 풀 스캔을 탑니다. 어떻게 진단하나요?

풀 스캔 자체는 정당할 수 있다는 전제 → 통계·함수 가공·타입 불일치·선택도 의심 → EXPLAIN의 type·key·rows

EXPLAIN의 Using filesort와 Using temporary가 뭔지, 나오면 어떻게 하는지 말해 주세요.

파일소트는 인덱스 순서를 활용하지 못할 → Using temporary는 모아서 처 → 인덱스 활용, SELECT 축소, 메모리

GROUP BY가 느립니다. 어디를 보나요?

인덱스 순서 집계 가능 여부 → 임시 테이블 디스크 유출 여부 → MySQL 8

MySQL을 서비스 DB로 선택할 때 장점과 한계를 어떻게 설명하시겠어요?

오픈소스·넓은 생태계·클라우드 관리형 지 → 8 → 복잡한 분석 쿼리·고급 SQL 기능은 P

왜 MySQL을 쓰나요?

생태계·운영·용도 적합의 근거 → InnoDB 기본과 현대 SQL 기능 언 → LTS(장기 지원)·Innovation

MySQL과 MariaDB의 관계를 설명해 주세요.

포크(소스를 복사해 따로 개발) 형제라는 → 8 → 에디션(커뮤니티·엔터프라이즈) 구분

파티션 테이블에서 유니크 키에 제약이 있다고 하는데, 무엇이고 왜 생기나요?

파티션 식에 쓰인 칼럼은 기본 키를 포함 → 인덱스가 파티션마다 따로 있어서, 파티션 → 그래서 날짜 파티션 테이블은 기본 키를

테이블 파티셔닝(partitioning)은 언제 쓰고, 오래된 데이터를 지울 때 왜 유리한가요?

파티셔닝은 한 테이블을 칼럼 값 기준으로 → 오래된 구간을 DROP PARTITION → 파티션 키 조건이 있으면 파티션 프루닝으

대용량 이력 테이블에 파티셔닝을 적용한다면 어떻게 설계하고, 무엇을 조심하겠어요?

날짜 칼럼으로 RANGE(또는 RANGE → 파티션 키를 기본 키를 포함한 모든 유니 → 자주 쓰는 쿼리에 파티션 키 조건이 있어

GTID(전역 트랜잭션 식별자) 기반 복제는 바이너리 로그 위치 기반 복제와 무엇이 다르고, 장애 조치 때 왜 유리한가요?

GTID는 source_id(서버 UUI → 위치 기반은 파일명·위치 좌표로 진행을 → GTID는 자동 위치 지정으로 레플리카가

MySQL 복제가 어떤 구조로 동작하는지, 변경이 소스에서 레플리카까지 가는 과정을 설명해 주세요.

소스는 커밋된 변경을 바이너리 로그에 기 → 레플리카의 리시버(I/O) 스레드가 이벤 → 받기와 적용을 릴레이 로그로 분리해 적용

비동기 복제와 반동기 복제의 차이를 설명하고, 반동기 복제에서 데이터 유실이 정말 없는지 말해 주세요.

비동기는 소스가 레플리카를 기다리지 않고 → 반동기는 최소 한 대 레플리카가 이벤트를 → AFTER_SYNC(기본)는 확인 후 엔

바이너리 로그 포맷 STATEMENT와 ROW의 차이, 그리고 MySQL 8.4에서 무엇을 쓰는 게 맞는지 설명해 주세요.

STATEMENT는 SQL 문장을, RO → STATEMENT는 UUID()·RAND → ROW는 결과가 항상 같지만 대량 변경

MySQL 복제를 설계한다면 구조·포맷·동기화 방식·장애 조치를 어떻게 잡겠습니까? 전체 그림으로 설명해 주세요.

소스 바이너리 로그를 레플리카 리시버 스 → GTID 기반으로 구성해 자동 위치 지정 → 바이너리 로그는 ROW 포맷(8

레플리카 복제 지연이 계속 늘어납니다. 원인을 어떻게 찾고 어떻게 줄이겠습니까?

Seconds_Behind_Source는 → 대량 변경 트랜잭션, PK 없는 테이블, → 멀티 스레드 복제(8

쓰기는 소스로, 읽기는 레플리카로 보내는 구조에서 '방금 쓴 데이터가 안 보이는' 문제를 어떻게 해결하나요?

비동기 복제라 레플리카가 아직 그 변경을 → 쓴 직후 그 사용자나 요청의 읽기는 소스 → session_track_gtids로 받

MySQL 복제 토폴로지에는 어떤 모양이 있고, 각각 언제 쓰며 무엇을 조심해야 하나요?

멀티 레플리카는 읽기 분산용이고, 쓰기는 → 체인은 중간 레플리카가 log_repli → 듀얼 소스에 양쪽으로 쓰면 비동기 복제가

운영자가 실수로 중요한 테이블을 지웠습니다. 복제 구성으로 이를 복구할 방법이 있나요?

일반 레플리카는 삭제도 곧바로 따라 적용 → SOURCE_DELAY로 일부러 늦게 적 → 적용을 멈추고 START REPLICA

MySQL 서버 설정을 바꿀 때 어디에 어떻게 반영하고, 재시작 없이 적용되는 것과 아닌 것을 어떻게 구분하나요?

시스템 변수는 GLOBAL과 SESSIO → 동적 변수는 SET으로 즉시 바뀌고, 정 → SET PERSIST는 mysqld-au

글로벌·세션·정적·동적을 구분해 설명해 주세요.

글로벌=서버 전체·새 접속, 세션=내 커 → 정적=재시작 필요, 동적=SET 즉시 → SHOW VARIABLES는 기본으로 세

바꾼 설정이 재시작 후에도 남게 하려면 어떻게 하나요?

SET GLOBAL은 메모리 한정 → my → PERSIST 저장 위치(mysqld-a

운영 중인 큰 테이블에서 오래된 행 수천만 건을 지워야 합니다. 어떻게 하시겠어요?

한 문장으로 지우지 않고 DELETE → 한 번에 지우면 잠금 행이 많아지고 언두 → 지울 행이 남길 행보다 훨씬 많으면 남길

INSERT IGNORE, INSERT ... ON DUPLICATE KEY UPDATE, REPLACE의 차이를 설명하고, 업서트에는 무엇을 쓰시겠어요?

IGNORE는 중복 행을 버리고, ON → REPLACE는 삭제 후 삽입이라 적지 → INSERT IGNORE는 데이터 변환

SQL을 작성할 때 결과가 조용히 틀어지거나 운영에 문제를 일으키는 대표적인 함정을 조회·변경·구조 변경으로 나눠 설명해 주세요.

조회는 논리적 처리 순서(WHERE가 S → 외부 조인에서 오른쪽 테이블 조건을 WH → REPLACE는 삭제 후 삽입, INSE

LEFT JOIN에서 조건을 ON에 쓸 때와 WHERE에 쓸 때 결과가 어떻게 달라지나요?

ON은 짝짓는 조건이고 WHERE는 짝지 → 오른쪽 테이블 조건을 WHERE에 두면 → 왼쪽 테이블 조건을 ON에 두면 왼쪽 행

'주문을 한 번도 하지 않은 회원'을 구하는 쿼리를 어떻게 작성하시겠어요? 방법별 주의점도 말해 주세요.

NOT EXISTS로 짝이 있는지만 확인 → LEFT JOIN 뒤 오른쪽의 NULL이 → NOT IN은 서브쿼리 결과에 NULL이

INNER JOIN, LEFT JOIN, CROSS JOIN은 각각 어떤 행을 돌려주나요? MySQL에서 FULL OUTER JOIN이 필요하면 어떻게 하시겠어요?

INNER JOIN은 양쪽 모두 짝이 있 → CROSS JOIN은 조건 없이 모든 조 → MySQL에는 FULL OUTER JOI

운영 중인 큰 테이블에 칼럼과 인덱스를 추가해야 합니다. 어떻게 준비하고 실행하시겠어요?

작업별로 INSTANT·INPLACE·C → 8 → INSTANT 변경은 따로 실행하고, 재

ALTER TABLE을 실행한 뒤 그 테이블의 쿼리가 전부 멈췄습니다. 원인을 어떻게 찾고 어떻게 해소하시겠어요?

SHOW PROCESSLIST에서 ALT → 막는 쪽은 Sleep 상태의 열린 트랜잭 → 막는 접속은 KILL QUERY가 아니라

잠금 대기로 쿼리가 멈춰 있습니다. 막는 접속을 어떻게 찾고, 끊기 전에 무엇을 확인한 뒤 어떻게 끊으시겠어요?

행 잠금은 sys → 뷰가 만들어 준 KILL 문을 그대로 돌 → Sleep 상태로 트랜잭션만 열어 둔 접

ALTER TABLE의 ALGORITHM(INSTANT·INPLACE·COPY)과 LOCK 옵션은 무엇이고, 운영 테이블에서는 왜 명시하나요?

INSTANT는 테이블 정의만 고치고, → ALGORITHM을 생략하면 INSTAN → LOCK은 도중에 허용할 범위(NONE은

SQL 모드의 ONLY_FULL_GROUP_BY와 STRICT_TRANS_TABLES는 각각 무엇을 막고, 끄면 어떤 일이 생기나요?

ONLY_FULL_GROUP_BY는 GR → 모드를 끄지 않고 칼럼을 GROUP BY → STRICT_TRANS_TABLES는 칼

SELECT 문의 절들이 처리되는 논리적 순서를 설명하고, 그 순서 때문에 생기는 작성 규칙을 말해 주세요.

FROM·JOIN → WHERE → GR → WHERE는 SELECT보다 먼저라 별칭 → 집계 결과 조건은 HAVING에, 묶기

인덱스가 있는 칼럼인데 조회가 풀 테이블 스캔으로 돌고 있습니다. SQL 문장 쪽에서 먼저 의심할 것은 무엇인가요?

칼럼에 함수·연산을 씌우면 인덱스에 저장 → 문자열 칼럼을 숫자와 비교하면 타입 변환 → 앞이 %로 시작하는 LIKE는 범위 탐색

재귀 CTE(자기 자신을 참조하는 공통 테이블 식)가 어떻게 동작하는지, 쓸 때 조심할 점과 함께 설명해 주세요.

비재귀 부분이 시작 행을 만들고, 재귀 → 조직도·카테고리 트리처럼 깊이가 정해지지 → 데이터 순환이 있으면 끝나지 않으며 ct

부서별로 급여가 가장 높은 직원 3명씩 뽑는 쿼리를 어떻게 작성하시겠어요?

ROW_NUMBER() OVER (PAR → 윈도우 함수는 WHERE 뒤에 계산되므로 → 동점 처리에 따라 ROW_NUMBER·R

IN과 EXISTS의 차이, 그리고 NOT IN과 NOT EXISTS를 쓸 때 주의할 점을 설명해 주세요.

IN은 값이 서브쿼리 결과 목록에 있는지 → MySQL 8 → NOT IN은 서브쿼리 결과에 NULL이

스토어드 함수의 DETERMINISTIC(같은 입력이면 늘 같은 결과) 선언은 왜 중요한가요?

DETERMINISTIC은 같은 입력에 → NOT DETERMINISTIC 함수를 → 바이너리 로그가 켜져 있으면 DETERM

스토어드 프로시저의 장단점과, 실무에서 잘 쓰지 않는 이유를 말해 주세요.

여러 SQL을 서버 안에서 실행해 네트워 → 쓰기를 받는 DB 서버는 늘리기 어려워, → 디버깅·테스트 도구가 빈약하고, DB 안

MySQL의 스토어드 프로그램 종류를 설명하고, 쓴다면 무엇을 조심해야 하는지 말해 주세요.

스토어드 프로시저(CALL로 호출), 스 → 네트워크 왕복은 줄지만, 늘리기 어려운 → 기본은 DEFINER 권한으로 실행되므로

ACID(원자성·일관성·격리성·지속성)를 설명하고, 각 속성이 깨지면 어떤 일이 생기는지 말해 주세요.

원자성(전부/전무)·일관성(규칙 유지)· → 송금 예시처럼 "중간에 실패했을 때" 장 → InnoDB 구현(언두 로그로 롤백, M

트랜잭션 안에서 DDL(테이블 구조를 바꾸는 SQL)을 실행하면 어떻게 되나요?

DDL(ALTER·CREATE·DROP· → 따라서 DDL 이후 ROLLBACK해도 → 스키마 변경과 데이터 변경 트랜잭션은 분

메타데이터 락이 뭔지, 장애로 이어지는 장면을 설명해 주세요.

스키마 객체(테이블 등) 보호용 서버 층 → 긴 읽기 트랜잭션이 DDL을 대기시키고, → `Waiting for table met

글로벌 락과 테이블 락, 네임드 락의 용도 차이를 설명해 주세요.

글로벌 락은 백업용 일관 시점, 테이블 → 네임드 락은 한 서버 인스턴스 안의 애플 → InnoDB 환경에서 글로벌 락·테이블

MySQL에서 트랜잭션이 어떻게 동작하는지, 잠금과 격리 수준까지 묶어서 전체 그림을 설명해 주세요.

트랜잭션은 ACID(원자성·일관성·격리성 → InnoDB 잠금은 레코드 락·갭 락·넥 → 격리 수준은 다른 트랜잭션의 변경 가시성

갭 락이 왜 필요한지, 어떤 문제를 막는지 설명해 주세요.

갭 락은 인덱스 레코드 사이 간격을 잠가 → 목적은 팬텀 리드 방지이며 REPEATA → 조건에 맞는 행이 없어도 갭은 잠긴다는

인덱스 없는 UPDATE 한 방이 서비스를 멈춘 적 있나요? 왜 그런 일이 생기죠?

InnoDB는 스캔한 인덱스 레코드에 잠 → READ COMMITTED는 조건에 맞지 → 잠금 경합 튜닝의 1순위는 인덱스(실행

트랜잭션 격리 수준을 설명해 주세요.

동시 트랜잭션 간 변경 가시성을 정하는 → 4단계(READ UNCOMMITTED / → MySQL InnoDB 기본값은 REPE

READ COMMITTED와 REPEATABLE READ의 차이를 실제 동작으로 설명해 주세요.

READ COMMITTED는 문장마다 새 → 같은 트랜잭션에서 같은 행을 두 번 읽을 → 잠금 읽기(FOR UPDATE, UPDA

MySQL에서 애플리케이션 계정을 만들고 권한을 관리하는 원칙을 설명해 주세요.

계정은 '사용자'@'호스트' 쌍으로 식별 → 최소 권한 원칙으로 필요한 DB·테이블에 → 8

MySQL 계정과 권한 부여 원칙을 설명해 주세요.

이름+호스트 짝 식별 → 층위별 최소 권한 → 확인(SHOW GRANTS) 습관

비밀번호를 무중단으로 교체하려면 어떻게 하나요?

이중 비밀번호 패턴 → 신·구 병행 → 앱 반영 → 구 파기 순 → 정책(만료·복잡도) 언급