SQL 서버 면접 질문: 데이터베이스 추론을 크게 설명하는 방법

SQL 서버 면접 질문은 구문 회상에서 멈추는 경우가 거의 없습니다. 패널은 이미 올바른 JOIN 절이나 윈도우 함수를 찾을 수 있음을 알고 있습니다. 그들이 테스트하는 것은 데이터베이스 문제를 실시간으로 추론할 수 있는지 그리고 그 추론을 다른 사람(DBA, 애플리케이션 개발자 또는 비기술 이해관계자 등)에게 설명할 수 있는지 여부입니다.

DBA 트랙 역할의 경우 백업, 복구 모델, 인덱스 유지 관리 및 서버 구성에 더 많은 가중치가 있을 것으로 예상됩니다. 개발자 트랙 역할의 경우 T-SQL 패턴, 쿼리 설계 및 코드가 쿼리 최적화 프로그램과 상호 작용하는 방법에 더 많은 가중치가 있을 것으로 예상됩니다. 대부분의 회사는 둘 다 혼합합니다. 인덱싱을 이해하는 개발자는 더 빠른 쿼리를 작성하고, 애플리케이션 논리를 이해하는 DBA는 더 나은 튜닝 조언을 제공하기 때문입니다.

일반적인 오프닝 질문은 "새로운 보고 테이블의 인덱싱 전략을 어떻게 설계할 것인지 설명하세요"와 같은 것입니다. 단 하나의 올바른 답은 없으므로 면접관은 실제로 프로세스를 평가하고 있습니다. 쿼리 패턴을 먼저 명확히 하는 방법, 읽기 성능과 쓰기 비용을 어떻게 비교하는지, 추측이 아닌 실제 데이터로 선택을 검증하는 방법입니다.

모든 좋은 답변의 공통 스레드는 내레이션입니다. 먼저 확인할 항목, 확인하는 이유, 결과가 무엇을 말해주는지 말씀하십시오. 면접관은 암기된 정의가 아닌 의사 결정 프로세스를 듣고 있으며, 그 큰소리로 생각하는 습관은 패널 앞에 앉기 전에 연습할 가치가 있습니다.

인덱싱 질문은 SQL 서버 면접에서 가장 일반적인 기술 검사점입니다. 클러스터형 인덱스와 비클러스터형 인덱스의 차이, 커버링 인덱스가 도움이 되는 경우, 느리게 실행되는 쿼리의 속도를 높이는 방법에 대해 설명해야 할 것으로 예상됩니다.

교과서 정의 대신 실제 진단 경로 주위에 답변을 구성하세요. 실제 실행 계획으로 시작하세요. "실제 실행 계획을 가져와서 내가 원하는 위치를 검색하고, 조건 열이 인덱싱되었는지 확인합니다." 키 조회 비용과 포함된 열 추가가 언제 제거되는지 설명하세요. 통계에 대해 언급하세요. 오래된 통계로 인해 옳은 인덱스가 있어도 최적화 프로그램이 나쁜 계획을 선택할 수 있으며, 오래된 통계 업데이트는 경험 많은 후보자가 먼저 확인하는 것입니다.

면접관은 필터링된 인덱스, 채우기 계수 및 인덱스 조각화에 대한 심층적인 후속 질문을 하는 것을 좋아합니다. 필터링된 인덱스는 행의 하위 집합만 포함하고 대부분 null이거나 거의 비활성 열의 인덱스를 극적으로 축소할 수 있다는 것을 설명할 준비를 하세요. 채우기 계수는 오늘날의 낭비된 공간과 교환하여 많은 삽입이 있는 테이블의 나중에 페이지 분할을 줄입니다.

예제 답변: "보고 쿼리가 인덱스가 없는 열을 필터링하고 3개의 큰 테이블을 조인하여 시간 초과되었습니다. 계획을 가져왔고, 클러스터형 인덱스 스캔과 비용이 많이 드는 정렬을 봤고, 필터 열에 비클러스터형 인덱스를 추가하여 SELECT 목록의 열을 포함하고 통계를 업데이트했으며, 스캔이 검색으로 바뀌었습니다. 기간이 12초에서 1초 이하로 떨어졌습니다." 그러한 구체적인 인과 관계의 이야기는 일반적인 답변에서 강한 답변을 구분하는 것입니다.

기본 SELECT 명령문을 넘어 면접관은 일반적으로 몇 가지 T-SQL 영역을 조사합니다. ROW_NUMBER, RANK 및 DENSE_RANK와 같은 창 함수, 공통 테이블 식 대 임시 테이블, 집합 기반 논리 대 커서, NULL이 비교 및 집계에서 어떻게 작동하는지입니다.

커서를 피해야 하는 이유를 물었을 때 "커서는 느립니다"라고 말하지 마세요. 메커니즘을 설명하세요. 커서는 한 번에 한 행을 처리하는 반면, 집합 기반 쿼리는 최적화 프로그램이 전체 결과 집합에서 작동하도록 하므로 규모가 커지면 거의 항상 더 빠릅니다. 커서가 진정한 올바른 도구인 경우, 예를 들어 엄격한 순서로 실행해야 하는 관리 스크립트에서는 그렇다고 말하고 이유를 설명하세요.

임시 테이블과 테이블 변수를 비교하도록 요청받을 수도 있습니다. 좋은 답변은 범위, 트랜잭션 로깅 동작 및 최적화 프로그램이 임시 테이블에 대한 통계를 생성하지만 테이블 변수에 대해서는 생성하지 않는다는 사실을 다루며, 이는 더 많은 행 수가 있는 쿼리 계획에 중요합니다. 설명을 실용적으로 유지하세요. 실제로 하나를 선택한 경우와 그 결과 무엇이 변경되었는지 설명하세요.

JOIN 유형 및 쿼리 구성에 대해 최소한 하나의 질문을 받을 것으로 예상됩니다. INNER JOIN과 LEFT JOIN의 차이, CROSS APPLY가 일반 JOIN이 표현할 수 없는 행별 논리에 유용한 경우, MERGE 문이 삽입, 업데이트 및 삭제를 하나의 작업으로 결합하는 방법입니다. TRY/CATCH를 사용한 오류 처리 및 XACT_ABORT가 트랜잭션 내에서 롤백 동작을 어떻게 변경하는지에 대한 짧은 질문도 나올 수 있습니다. 구문이 아니라 실제로 사용한 상황으로 각각을 이름 지으세요.

디자인 질문은 쿼리에 대해 생각하기 전에 스키마에 대해 생각하는지를 테스트합니다. 정규화에 대한 질문을 받을 것으로 예상됩니다. 데이터를 관련 테이블로 분할하여 업데이트 이상을 줄이는 방법과 읽기 성능을 위해 테이블을 의도적으로 비정규화하는 것이 실수가 아니라 합리적인 절충안인 경우입니다.

기본 키와 고유 제약 조건의 차이, 애플리케이션이 코드에서 관계를 강제하는 경우에도 외래 키가 중요한 이유, 새 테이블의 자연 키와 서로게이트 키를 선택하는 방법을 설명할 준비를 하세요. ID 열과 기본 키로 GUID에 대해 묻는 경우 실제 영향을 언급하세요. 순차 ID는 클러스터형 인덱스 삽입을 효율적으로 유지하는 반면 임의 GUID는 순차 변수를 사용하지 않는 한 인덱스를 빠르게 단편화할 수 있습니다.

디자인 지향 후속 조치로 고객, 제품 및 라인 항목을 포함하는 주문 시스템과 같은 특정 시나리오에 대한 스키마를 스케치하도록 요청할 수 있습니다. 당신의 생각을 설명하세요. 어떤 엔터티가 자신의 테이블이 필요한지, 예상되는 쿼리 패턴을 위해 어떤 열을 인덱싱해야 하는지, 제약 조건이 다운스트림 데이터 품질 문제가 되기 전에 잘못된 삽입을 어떻게 포착할 것입니다.

백업 및 복구 질문은 단순한 명령이 아닌 복구 전략 뒤의 절충안을 이해하는지 확인합니다. 세 가지 복구 모델(단순, 전체 및 대량 로그인)과 각 모델이 특정 시점 복구가 가능한지 여부에 어떻게 영향을 미치는지 설명할 준비를 하세요.

전체 백업, 차등 백업 및 트랜잭션 로그 백업의 차이와 복구 중에 이들이 어떻게 결합되는지를 살펴보세요. 면접관은 종종 시나리오로 따라갑니다. 데이터베이스가 오후 2시에 실패했고, 마지막 전체 백업은 어제 밤이었으며, 15분마다 로그 백업이 있습니다. 복구 순서와 결과 복구 지점의 이름을 지은 다음 평문 형식의 RPO 및 RTO에 연결하세요. 허용 가능한 데이터 손실의 양, 시스템이 다시 올 필요가 있는 속도입니다.

더 높은 수준의 면접에서는 고가용성 옵션을 개념 수준에서 비교하도록 요청받을 수도 있습니다. AlwaysOn 가용성 그룹이 로그 배송과 어떻게 다른지, 그리고 회사가 더 느리게 복구함에도 불구하고 더 간단한 옵션을 선택할 수 있는 이유입니다. 모든 옵션을 구성할 필요는 없지만 각 옵션이 어떤 문제를 해결하는지 설명할 수 있어야 합니다.

실제 복원 또는 장애 조치를 처리한 경우 간단히 설명하세요. 무엇이 깨졌는지, 사용한 백업 체인, 복구에 걸린 시간, 다음에 복구 창을 줄이기 위해 변경한 사항입니다. 백업이 좋다고 가정하는 것이 아니라 일정에 따라 복원을 실제로 테스트한다고 언급하는 것은 실제 운영 경험을 나타내는 종류의 세부 정보입니다.

트랜잭션 질문은 여러 사용자가 동일한 데이터에 동시에 접촉할 때 발생하는 상황을 이해하는지를 테스트합니다. ACID에서 시작하세요. 원자성, 일관성, 격리 및 내구성, 그 후 두문자어보다 더 구체적인 것으로 빠르게 이동하세요.

격리 수준을 비교할 준비를 하세요. SQL 서버 기본값인 읽기 커밋, 읽기 커밋 전, 반복 가능 읽기, 직렬화 가능 및 스냅샷 격리입니다. 더티 읽기 또는 팬텀 읽기와 같은 각 수준이 해결하는 문제와 동시성이 무엇을 비용으로 하는지 설명하세요. 강한 후보자는 스냅샷 격리가 tempdb에서 행 버전 관리를 사용하여 독자를 작성자에 대해 차단하지 않는 방법과 이것이 애플리케이션 팀의 차단 불만을 줄이기 위해 메모리와 tempdb 로드를 어떻게 거래할 수 있는지 설명할 수도 있습니다.

Deadlock 질문은 자주 나옵니다. Extended Events에서 deadlock 그래프를 사용하여 식별하는 방법을 설명하고, deadlock이 실제로 무엇인지 설명하세요. 서로 필요한 잠금을 보유하는 두 세션이 있으며, 테이블 액세스를 일관되게 다시 정렬하거나 트랜잭션을 단축하는 등의 수정 사항을 설명하세요. 면접관이 NOLOCK이나 ROWLOCK과 같은 잠금 힌트에 대해 물으면 절충안을 평문으로 설명하세요. NOLOCK은 차단을 방지하지만 커밋되지 않은 행 또는 중복 행을 반환할 수 있으므로 근사 결과가 허용되는 보고 쿼리에 속하며 재무 계산에는 속하지 않습니다.

후보자는 타임아웃 알림에서 그래프를 가져오는 것부터 다시 쓸 쿼리를 식별하는 것까지 deadlock 조사를 단계별로 설명할 수 있습니다. 일반적으로 용어를 정의하기만 하는 후보자보다 눈에 띕니다.

빈번한 SQL 서버 면접 질문은 갑자기 느려지는 서버를 진단하는 방법을 설명하도록 요청합니다. 도구 목록이 아닌 라이브 문제 해결 설명으로 취급하세요. 먼저 확인할 항목부터 시작하세요. 현재 대기 통계, 활성 요청 및 차단 세션입니다. sys.dm_exec_requests, sys.dm_exec_sessions 및 sys.dm_os_wait_stats와 같은 보기를 사용하세요.

CPU 바운드 문제, I/O 바운드 문제 및 차단 체인의 차이를 구분하는 방법을 설명하세요. PAGEIOLATCH 대기가 디스크 압력을 나타내는지, LCK_M_X 대기가 차단을 나타내는지와 같은 대기 유형을 찾으세요. Tempdb 경합을 특히 많은 임시 테이블 또는 정렬 활동이 있는 서버에서 예기치 않은 속도 저하의 일반적이지만 간과하기 쉬운 원인으로 언급하고, 매개 변수 스니핑을 한 입력에 대해 빠르게 실행되고 같은 캐시된 계획을 사용하여 다른 입력에 대해 느리게 실행되는 쿼리의 원인으로 언급하세요.

면접관이 더 밀어붙이면 특정 쿼리를 격리하는 방법을 설명하세요. 추적 또는 Extended Events 세션을 캡처한 다음 문제가 있는 문의의 실행 계획을 검토하고 예상 행 수와 실제 행 수를 비교하여 잘못된 예상이 속도 저하를 주도하는지 확인하세요.

면접관이 이러한 시나리오 기반 질문을 하는 이유는 슬라이드에서 정의를 읽는 것은 쉽지만 시간 제한하에서 라이브 조사를 설명하는 것은 아니기 때문입니다. 실제로 실행할 순서대로 순서대로 설명을 크게 연습하면 누구든지 듣고 있는 차이를 만듭니다.

자신의 업무에서 실제 시나리오의 짧은 목록을 작성하세요. 하나의 인덱싱 수정, 하나의 deadlock 또는 차단 조사, 하나의 백업 또는 복원 상황, 성능을 개선한 쿼리 다시 작성입니다. 각각에 대해 증상, 진단 단계, 수정 및 측정 가능한 결과를 기록하세요.

그러면 각 이야기를 크게 연습하세요. 조용히 읽는 것이 아니라. 기술 면접은 시간 제한하에서 결정을 명확하게 설명할 수 있는 후보자에게 보상합니다. 그리고 그 기술은 처음으로 조용한 검토에서 나오지 않습니다. SayNow는 현실적인 후속 조치 프롬프트로 SQL 서버 면접 질문을 리허설할 수 있으므로 실제 면접 중에 처음으로 실행 계획이나 격리 수준 선택을 설명하는 것이 아니라 대화에서 설명하는 데 익숙해질 수 있습니다.

크게 리허설하면 조용한 검토가 숨기는 격차도 노출됩니다. 격리 수준을 명확하게 이해한다고 생각할 때까지 다른 사람에게 스냅샷 격리를 설명하고 설명이 반쯤 끝나간다는 것을 깨닫는 것은 드문 일이 아닙니다. 연습에서 그것을 포착하는 것이 채용 패널 앞에서 그것을 포착하는 것보다 훨씬 낫습니다.

마지막으로 자신의 질문 몇 가지를 준비하세요. 팀이 쿼리 성능을 모니터링하는 방법, 백업 및 복구 테스트 프로세스의 모양, 스키마 변경을 검토하는 방법입니다. 사려 깊은 질문은 면접이 처음 테스트하던 것과 동일한 운영 판단을 신호합니다.