[MySQL] 에러 핸들링의 숨은 조력자: SHOW ERRORS 문 완벽 가이드

728x90

에러 메시지, 그 너머를 보다

데이터베이스를 다루다 보면 에러는 피할 수 없는 일상입니다. 쿼리를 실행했을 때 붉은색 텍스트로 나타나는 "Syntax error"나 "Table doesn't exist" 같은 메시지는 개발자에게 신호를 보냅니다. 하지만 복잡한 트랜잭션이나 여러 단계의 쿼리를 수행하는 과정에서 단순히 "에러가 났다"는 사실만으로는 부족할 때가 있습니다.

MySQL의 SHOW ERRORS 문은 바로 이 지점에서 빛을 발합니다. 이 명령은 가장 최근에 실행된 문장에서 발생한 오류들에 대한 상세한 진단 정보를 제공합니다. 단순히 화면에 출력되고 사라지는 에러 메시지를 넘어, 서버가 내부적으로 기억하고 있는 에러 버퍼의 내용을 조회하여 정확한 디버깅을 돕습니다. 주니어 개발자에게는 낯설 수 있지만, 숙련된 DBA에게는 문제 해결의 속도를 높여주는 필수적인 도구입니다.

이 글에서는 SHOW ERRORS의 기본 개념부터 실무적인 활용법, 그리고 MySQL 버전에 따른 문맥까지 깊이 있게 다뤄보겠습니다.

1. SHOW ERRORS란 무엇인가?

기본적으로 MySQL 클라이언트(워크벤치나 터미널 등)는 쿼리 실패 시 첫 번째 에러 메시지를 자동으로 보여줍니다. 하지만 하나의 쿼리 실행으로 인해 여러 개의 에러가 발생했다면 어떻게 될까요? 혹은 저장 프로시저 내부에서 발생한 에러를 구체적으로 확인하고 싶다면요?

SHOW ERRORS는 현재 세션의 에러 버퍼에 저장된 오류 정보를 표 형태로 보여주는 진단 명령입니다.

기본 문법:

SHOW ERRORS [LIMIT [offset,] row_count]
SHOW COUNT(*) ERRORS

이 명령은 Code, Message, Type 등의 정보를 반환합니다.

Level: Error, Warning, Note 등의 수준을 나타냅니다 (SHOW ERRORS는 주로 Error를 다루지만 메커니즘은 SHOW WARNINGS와 공유됩니다).
Code: MySQL 에러 코드 (숫자)입니다.
Message: 사람이 읽을 수 있는 상세 에러 설명입니다.

예를 들어, 존재하지 않는 테이블을 조회하려 했을 때:

SELECT * FROM non_existent_table;
-- ERROR 1146 (42S02): Table 'test.non_existent_table' doesn't exist

SHOW ERRORS;

위와 같이 실행하면 방금 발생한 에러에 대한 구조화된 정보를 다시 확인할 수 있습니다.

2. SHOW ERRORS vs SHOW WARNINGS

MySQL을 처음 접하는 분들이 가장 헷갈려 하는 부분이 바로 SHOW ERRORS와 SHOW WARNINGS의 차이입니다.

SHOW ERRORS: 오직 **오류(Errors)**만 보여줍니다. 쿼리 실행을 중단시킨 심각한 문제들입니다.
SHOW WARNINGS: 오류뿐만 아니라 **경고(Warnings)**와 **참고(Notes)**까지 모두 포함하여 보여줍니다.

실무적으로는 SHOW WARNINGS가 상위 호환에 가깝기 때문에 더 자주 사용되곤 합니다. 하지만, 수많은 경고 메시지(예: 데이터 잘림, 비표준 문법 사용 등) 속에서 **"진짜 실행을 막은 원인"**만 빠르게 필터링하고 싶다면 SHOW ERRORS가 훨씬 명확합니다.

실무 팁: 대량의 데이터 삽입 작업(LOAD DATA INFILE 등)을 수행할 때, 수천 건의 경고 속에 치명적인 에러가 섞여 있을 수 있습니다. 이때 SHOW ERRORS를 사용하면 노이즈를 제거하고 핵심 문제에만 집중할 수 있습니다.

3. MySQL 버전 흐름과 GET DIAGNOSTICS

SHOW ERRORS는 MySQL 4.1부터 지원된 매우 오래되고 안정적인 기능입니다. 하지만 현대적인 MySQL 개발, 특히 MySQL 5.6 이상을 사용하고 있다면 중요한 변화를 인지해야 합니다.

바로 SQL 표준 방식인 GET DIAGNOSTICS의 도입입니다.

SHOW ERRORS는 MySQL만의 비표준 확장 문법입니다. 따라서 애플리케이션 코드나 저장 프로시저(Stored Procedure) 내부에서 에러를 핸들링하고 변수에 할당하여 로직을 분기처리하기에는 적합하지 않습니다. SHOW 명령의 결과는 결과셋(Result Set)으로 반환되기 때문에 프로시저 내에서 SELECT ... INTO 처럼 변수에 담기 어렵기 때문입니다.

MySQL 5.6 이후의 권장 패턴: 저장 프로시저 내부에서 에러를 정교하게 처리해야 한다면 GET DIAGNOSTICS를 사용하는 것이 좋습니다.

-- MySQL 5.6+ 저장 프로시저 내부 예시
DECLARE EXIT HANDLER FOR SQLEXCEPTION
BEGIN
  GET DIAGNOSTICS CONDITION 1
    @p1 = RETURNED_SQLSTATE, @p2 = MESSAGE_TEXT;
  SELECT @p1 as SQLState, @p2 as ErrorMessage;
END;

하지만 대화형 세션(터미널, 클라이언트 툴)에서 즉각적인 디버깅을 할 때는 여전히 SHOW ERRORS가 훨씬 간편하고 직관적입니다.

4. max_error_count 시스템 변수 활용하기

SHOW ERRORS가 보여줄 수 있는 에러의 개수는 무한하지 않습니다. 이는 시스템 변수 max_error_count에 의해 제어됩니다.

기본값은 보통 64입니다. 즉, 서버는 최근 발생한 에러, 경고, 노트 등을 최대 64개까지만 기억합니다. 만약 대량의 배치 작업 중 수백 개의 에러가 발생했다면, 앞선 에러들은 버퍼에서 밀려나 SHOW ERRORS로 확인할 수 없게 됩니다.

만약 더 많은 에러 로그를 확인해야 하는 상황이라면, 작업을 수행하기 전에 세션 레벨에서 이 값을 늘려주어야 합니다.

SET SESSION max_error_count = 1024;
-- 이후 쿼리 실행
SHOW ERRORS;

결론 및 실무 활용 팁

SHOW ERRORS는 단순해 보이지만, 복잡한 문제 상황에서 개발자에게 명확한 시야를 제공하는 중요한 도구입니다. 특히 SHOW WARNINGS와 구분하여 치명적인 오류만 빠르게 솎아내고 싶을 때 유용합니다.

마지막으로 실무에서 바로 적용할 수 있는 핵심 포인트를 정리해 드립니다.

Practical Takeaways:

즉시 확인 습관: SHOW ERRORS는 가장 최근 실행된 문장(statement)의 정보만 담고 있습니다. 다른 쿼리를 실행하면 버퍼가 초기화되므로, 에러 발생 직후에 실행해야 합니다.
프로시저 vs 터미널: 터미널에서 직접 디버깅할 때는 SHOW ERRORS가 빠르고 편하지만, 저장 프로시저를 개발할 때는 표준 문법인 GET DIAGNOSTICS를 사용하는 것이 유지보수와 호환성 측면에서 유리합니다.
버퍼 크기 조절: 대량의 데이터 마이그레이션이나 배치 작업을 디버깅할 때는 max_error_count 값을 미리 늘려두어 중요한 에러 로그가 유실되지 않도록 하십시오.

관련 공식 문서: 더 깊이 있는 정보와 최신 스펙을 확인하려면 아래 링크를 참조하세요. MySQL 8.0 Reference Manual - SHOW ERRORS Statement