{
  "id": "f920173d-c1f5-4213-b8e6-b758adcb82f1",
  "slug": "ref/web/blog-bizspring-co-kr/sql-최적화를-위한-쿼리-실행계획-explain-명령어에-대해-알아보자-bizspring-blog",
  "doc_type": "ref",
  "title": "SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자 - BizSpring BLOG",
  "title_en": null,
  "one_liner": "SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자 - BizSpring BLOG 콘텐츠로 건너뛰기 내비게이션 메뉴 인사이트 테크 활용 방법/사례 활용 방법/사례 성공사례 성공 사례 일반 광고/마케팅 에이전시 이커머스 미디어/콘텐츠 금융/핀테",
  "summary_bullets": [
    "데이터와 쿼리가 복잡해지면서 발생하는 응답 지연을 해결하기 위한 SQL 쿼리 최적화 방법을 다룹니다.",
    "MySQL이 제공하는 EXPLAIN 명령어를 통해 쿼리 실행 계획을 분석하는 방법을 설명합니다.",
    "실행 계획의 id, select_type, table, type, key, rows, Extra 등 각 항목의 의미를 정리합니다.",
    "쿼리 튜닝에서 가장 중요한 항목인 type과 Extra의 세부 값들과 그 의미를 상세히 소개합니다.",
    "EXPLAIN을 통해 감이 아닌 근거 기반으로 쿼리 튜닝을 수행할 것을 권장합니다."
  ],
  "body_md": "SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자 - BizSpring BLOG\n\n콘텐츠로 건너뛰기\n\n내비게이션 메뉴\n\n인사이트\n\n테크\n\n활용 방법/사례\n\n활용 방법/사례\n\n성공사례\n\n성공 사례 일반\n\n광고/마케팅 에이전시\n\n이커머스\n\n미디어/콘텐츠\n\n금융/핀테크\n\n의료/헬스케어\n\n통신/인터넷\n\n뉴스/트렌드\n\n릴리즈 노트\n\n인터넷트렌드 ↗\n\n웹사이트 ↗\n\n# SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자\n\n2025년 10월 13일 2025년 10월 13일\n테크\n\n프로그래밍 산업의 발전이 빠르게 이루어지고 프로그램의 기능이 많아지면서, 프로그램이 하나의 기능만을 하는 것이 아닌 여러 기능을 포함하고 있는 추세입니다.\n\n이러한 이유로 지속적으로 새로운 서비스가 출시되고, 사용자가 늘어나면서 데이터베이스에 쌓이는 데이터의 양도 점점 방대해지게 됩니다.\n\n데이터 양의 증가로 인하여, 데이터를 컨트롤하기 위해 사용되는 SQL(Structured Query Language) 쿼리 또한 점점 복잡해지고 개발 단계 및 서비스 초기에는 확인이 어려운 응답 속도 지연 등의 현상이 많이 발생하게 됩니다.\n\n많은 서비스 제공 업체에서는 이를 해결하기 위해, 쿼리 리팩토링을 수행하여 최적화를 이루어 결과가 빠르게 도출되도록 하는 과정을 거치게 됩니다.\n\n쿼리를 리팩토링 하기 위해서는 쿼리 분석이 필요한데, 각 데이터베이스마다 쿼리를 분석하는 프로그램을 제공하고 있습니다.\n\n이 중 MySQL에서 제공하는 EXPLAIN 에 대해 간단히 살펴보겠습니다.\n\n## EXPLAIN 이란?\n\nMySQL\n\nEXPLAIN은 MySQL에서 제공하는 명령어 입니다.\n각 쿼리에 대해 실행 계획을 분석하고 결과를 제공 합니다.\n\n해당 쿼리가 실행이 될 때 어떤 테이블에서 어떤 컬럼을 조회하는지, 얼마나 많은 데이터를 참조하는지, 어떤 테이블을 조회 시 시간을 많이 소요하는지 등 각 쿼리의 실행별 과정과 결과에 대해 상세 정보를 파악할 수 있습니다.\n\n이를 이용하여 성능 분석을 하고, 쿼리 튜닝을 통해 쿼리를 최적화할 수 있습니다.\n\n## EXPLAIN은 어떻게 사용이 가능할까 ?\n\nMySQL 쿼리 실행 단계 (출처: https://coderpad.io/blog/development/optimize-query-performance-mysql)\n\nMySQL의 경우 쿼리를 실행 시, 각 테이블의 데이터 분포를 참조하여 가장 적은 비용으로 데이터를 조회하는데, 이 과정에서 데이터를 기반으로 실행 계획을 수립하는 쿼리 옵티마이저 가 작동합니다.\nEXPLAIN은 이 옵티마이저의 실행 계획을 표 형식으로 보여주는 기능입니다.\n\n## EXPLAIN 명령어의 사용법과 확인 가능한 정보\n\n모든 테스트 쿼리는 다음 데이터를 이용하여 구현하였습니다.\n\nhttps://github.com/datacharmer/test_db\n\n&times;\n\nEXPLAIN의 사용법은 간단합니다.\n다음과 같이 실행할 쿼리 앞에 “EXPLAIN” 명령어를 붙여 사용할 수 있습니다.\n\n예시) 성 혹은 이름이 Matt인 직원을 조회하여 생년월일 내림차순으로 정렬\n\nEXPLAIN SELECT * FROM employees e1 WHERE e1.emp_no IN ( SELECT e2.emp_no FROM employees e2 WHERE e2.first_name = ‘Matt’ UNION SELECT e3.emp_no FROM employees e3 WHERE e3.last_name = ‘Matt’ ) ORDER BY birth_date DESC;\n\nid select_type table partitions type possible_keys key key_len ref rows filtered Extra\n1 PRIMARY e1   ALL         299,157 100 Using where; Using filesort\n\n2 DEPENDENT SUBQUERY e2   eq_ref PRIMARY PRIMARY 4 func 1 10 Using where\n\n3 DEPENDENT UNION e3   eq_ref PRIMARY PRIMARY 4 func 1 10 Using where\n\n4 UNION RESULT <union2,3>   ALL             Using temporary\n\nEXPLAIN 명령어를 실행하면 다음과 같이 결과가 출력됩니다.\n각 항목에 대한 설명은 다음과 같습니다.\n\n실행 계획\n설명\n\nid\n실행 계획 결과의 ID 번호\n\nselect type\nSELECT 문의 유형\n\ntable\n참조 테이블명\n\npartitions\n파티셔닝이 되어있을 경우 사용되는 필드명, 파티셔닝이 되어 있지 않을 경우 NULL\n\ntype\n해당 테이블 데이터의 접근 유형, 쿼리 튜닝에 가장 중요한 요소 중 하나\n\npossible_keys\n데이터 조회 시 사용 가능한 인덱스 필드 목록\n\nkey\n실행에 사용할 기본 키 혹은 인덱스명, 없을 경우 NULL\n\nkey_len\n실제 사용할 기본 키 혹은 인덱스의 길이\n\nref\nReference, 테이블 조인 시 어떤 조건으로 해당 테이블에 접근하는 지\n\nrows\n쿼리 실행 시 조회되는 데이터 수\n\nfiltered\n이 쿼리로 실행 결과로 전체 데이터 중 필터링된 데이터의 비율\n\nExtra\nMySQL 옵티마이저가 제공하는 힌트, 쿼리 튜닝에 가장 중요한 요소 중 하나\n\n이 중 눈여겨 봐야할 항목인 type , Extra 에 대해 살펴보겠습니다.\n\n### type\n\ntype 은 해당 테이블에 있는 데이터에 접근하는 방식을 표시하는 필드입니다. 옵티마이저가 어떤 방법으로 row를 조회하는 지 나타내기 때문에 대상 테이블로 접근이 효율적인지 아닌지 판단을 할 수 있는 아주 중요한 항목 입니다.\n특히 접근 방식 중, ALL 의 경우 쿼리에 사용되는 인덱스가 없어 모든 데이터를 탐색 한다는 의미입니다. 모든 데이터를 탐색하기 때문에 시간이 다소 소요되고 쿼리 실행이 지연되는 주된 요인이 됩니다. 그러므로 인덱스 생성, 필터링을 통한 쿼리 튜닝의 주요 대상이 됩니다.\n접근 방식은 다음과 같은 종류가 존재합니다. 상위에 위치한 항목일수록 속도가 빠릅니다.\n\nType\n설명\n\nsystem\n테이블에 데이터가 1행 밖에 없는 경우\n\nconst\n쿼리 결과가 1건을 반환, 가본 키 혹은 고유 키를 이용한 조건 필터링의 경우\n\neq_ref\n조인(Join) 시 기본 키를 사용한 경우, 조인 단계에서 인덱스 혹은 기본 키로 필터링 하여 단 1건의 데이터를 조회할 경우\n\nref\n조인 시 기본 키 혹은 고유 키가 아닌 인덱스를 사용한 경우\n\nref_or_null\nref에서 NULL 비교가 추가된 형태\n\nindex_merge\n여러 개의 인덱스가 동시에 사용되는 경우\n\nunique_subquery\n서브쿼리 접근에서 기본 키 혹은 고유 키를 사용하는 경우\n\nindex_subquery\n서브쿼리 접근에서 인덱스를 사용하는 경우\n\nrange\n인덱스를 하나의 값이 아닌 범위로 검색하는 경우, 성능 순위는 낮으나 해당 방법으로도 빠른 성능을 보장\n\nindex\n인덱스를 처음부터 끝까지 조회하는 경우, all과 비슷한 형식이나 인덱스이기 때문에 all 보다는 효율적\n\nall\n테이블의 모든 데이터를 조회하는 경우, 가장 비효율적이므로 튜닝의 대상이 됨\n\n### Extra\n\nExtra 는 옵티마이저가 해당 쿼리를 어떻게 처리할 것인지에 대한 추가 정보를 보여줍니다. 이 정보를 통해 해당 쿼리가 실행될 때의 최적화 상태를 알 수 있어 쿼리 튜닝에 중요한 요소 중 하나입니다.\nExtra 항목 중 Using temporary 와 Using filesort 의 경우 많은 비용이 필요하므로 쿼리 튜닝의 대상이 될 수 있습니다.\nExtra의 여러 항목 중 주요 값들을 정리하면 다음과 같습니다.\n\nExtra\n의미\n설명\n\nUsing where\nWHERE 조건 필터링 수행\n인덱스가 아닌 필드로 필터링\n\nUsing index\n커버링 인덱스 사용\n테이블 데이터를 읽지 않고 인덱스만으로 쿼리를 처리함\n\nUsing index condition\n인덱스 조건 푸시다운(Index Condition Pushdown) 사용\n일부 WHERE 조건이 인덱스 수준에서 처리됨\n\nUsing temporary\n임시 테이블 생성\nGROUP BY , DISTINCT , UNION , ORDER BY 등에서 중간 결과를 저장하기 위해 사용됨, 튜닝의 고려 대상이 됨\n\nUsing filesort\n파일 정렬 수행\n인덱스를 사용하지 않고 별도로 정렬 작업을 수행함, 튜닝의 고려 대상이 됨 ( ORDER BY 에서 주로 발생)\n\nRange checked for each record\n각 레코드마다 범위 스캔을 시도\n매우 비효율적이므로 튜닝의 대상\n\nUsing join buffer (Block Nested Loop)\n조인 버퍼 사용\n인덱스를 사용하지 못해 조인 시 메모리 버퍼를 사용함\n\nUsing sort_union / union / intersect\n인덱스 조합 사용\n여러 인덱스를 병합하여 결과를 도출함\n\nNo tables used\n테이블 접근 없음\n예: SELECT 1 같은 단순 계산 쿼리\n\nEXPLAIN 은 쿼리 튜닝을 시작할 때 가장 먼저 확인해야 하는 도구입니다. 실행 계획을 통해 MySQL이 데이터를 어떻게 처리하는지 파악하면, 인덱스 사용 여부나 조인 방식 등 성능 저하의 원인을 명확히 찾을 수 있습니다. 이러한 분석 과정을 거치면 감이 아닌 근거를 기반으로 쿼리 튜닝을 효율적으로 수행할 수 있습니다. 쿼리 최적화가 필요할 때는 EXPLAIN을 적극적으로 활용해 실행 계획을 검토해 보시길 권합니다.\n\n최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.\n비즈스프링 뉴스레터 구독하기 →\n\n## Related Posts via Categories\n\n구글애즈가 정확검색·구문검색 키워드까지 AI 모드에 노출하기 시작했다 — 자동화 상품 없이 AI 답변 화면에 들어가는 첫 실험\nAI가 React 앱을 직접 디버깅 – Agent 기반 디버깅\nChatGPT 광고가 픽셀·전환 API·맞춤 오디언스를 갖췄다 — 답변 화면이 측정 가능한 광고 매체가 되는 순간\nAI 시대, 데이터도 설명이 필요합니다\nMCP 클라이언트는 Authorization Server를 어떻게 찾는가: 공식 MCP TypeScript SDK와 VS Code 구현 비교\nRAG 시대의 GEO: AI가 콘텐츠를 읽는 방식과 스키마의 진짜 역할\nAI 에이전트로 웹 데이터 수집 가능 여부 자동 검증하기\nGA4 Intraday 실시간 테이블, 대시보드 원천 데이터로 바로 사용할 수 있을까?\n워크플로우 오케스트레이션 플랫폼 Temporal 알아보기\niOS 14.5부터 GA4까지, 환경 변화가 가져온 업무 폭증을 해결하는 실무 전략은…?\n\n다음에 대해 검색하기...\n\n최신 글 둘러보기\n\n기존 SEO와 무엇이 같고 무엇이 다른가\n\n콘텐츠가 답인 걸 모르는 사람은 없습니다 — 문제는 지속입니다\n\n광고비를 늘리지 않고 매출을 늘린 회사들은 무엇을 했나\n\n코호트로 비교하면 광고 예산 판단이 달라집니다\n\nGEO를 위한 글쓰기를 위한 작은 노하우\n\n(해외동향) 광고주가 광고플랫폼 리포트에서 자체 측정으로 옮겨가고 있다.\n\n구글애즈가 정확검색·구문검색 키워드까지 AI 모드에 노출하기 시작했다 — 자동화 상품 없이 AI 답변 화면에 들어가는 첫 실험\n\nAI가 React 앱을 직접 디버깅 – Agent 기반 디버깅\n\nChatGPT 광고가 픽셀·전환 API·맞춤 오디언스를 갖췄다 — 답변 화면이 측정 가능한 광고 매체가 되는 순간\n\n마케팅 자동화, 무엇부터 자동화해야 할까?\n\n출처: https://blog.bizspring.co.kr/%ed%85%8c%ed%81%ac/sql-%ec%b5%9c%ec%a0%81%ed%99%94%eb%a5%bc-%ec%9c%84%ed%95%9c-%ec%bf%bc%eb%a6%ac-%ec%8b%a4%ed%96%89%ea%b3%84%ed%9a%8d-explain-%eb%aa%85%eb%a0%b9%ec%96%b4/",
  "related_slugs": [],
  "faq": [
    {
      "a": "EXPLAIN은 MySQL에서 제공하는 명령어로, 각 쿼리의 실행 계획을 분석하고 결과를 표 형식으로 보여줍니다. 어떤 테이블과 컬럼을 조회하는지, 얼마나 많은 데이터를 참조하는지 등을 파악할 수 있어 성능 분석과 쿼리 튜닝에 활용됩니다.",
      "q": "EXPLAIN 명령어는 어떤 역할을 하나요?"
    },
    {
      "a": "실행하려는 쿼리 앞에 EXPLAIN 명령어를 붙여서 실행하면 됩니다. 그러면 쿼리 옵티마이저가 수립한 실행 계획이 표 형태로 출력됩니다.",
      "q": "EXPLAIN은 어떻게 사용하나요?"
    },
    {
      "a": "네, type이 ALL인 경우는 쿼리에 사용되는 인덱스가 없어 테이블의 모든 데이터를 탐색한다는 의미로 가장 비효율적인 접근 방식입니다. 시간이 많이 소요되어 쿼리 실행 지연의 주된 요인이 되므로 인덱스 생성 등 튜닝의 주요 대상이 됩니다.",
      "q": "type 항목에서 ALL이 나오면 안 좋은 건가요?"
    },
    {
      "a": "Using temporary와 Using filesort는 많은 비용이 필요한 항목으로 쿼리 튜닝의 대상이 될 수 있습니다. Using temporary는 GROUP BY, DISTINCT, UNION, ORDER BY 등에서 임시 테이블을 생성할 때 나타나고, Using filesort는 인덱스를 사용하지 않고 별도 정렬 작업을 수행할 때 주로 ORDER BY에서 발생합니다.",
      "q": "Extra 항목에서 특히 주의해야 할 값은 무엇인가요?"
    },
    {
      "a": "본문에서는 EXPLAIN을 쿼리 튜닝을 시작할 때 가장 먼저 확인해야 하는 도구로 소개합니다. 실행 계획을 통해 MySQL이 데이터를 어떻게 처리하는지 파악하면 인덱스 사용 여부나 조인 방식 등 성능 저하 원인을 명확히 찾을 수 있습니다.",
      "q": "쿼리 튜닝을 시작할 때 무엇을 먼저 확인해야 하나요?"
    }
  ],
  "jsonld": null,
  "keywords": [],
  "source_id": "https://blog.bizspring.co.kr/%ed%85%8c%ed%81%ac/sql-%ec%b5%9c%ec%a0%81%ed%99%94%eb%a5%bc-%ec%9c%84%ed%95%9c-%ec%bf%bc%eb%a6%ac-%ec%8b%a4%ed%96%89%ea%b3%84%ed%9a%8d-explain-%eb%aa%85%eb%a0%b9%ec%96%b4/",
  "video_url": null,
  "duration_sec": null,
  "thumbnail_url": null,
  "image_url": null,
  "caption": null,
  "solution_slug": null,
  "captured_at": null,
  "width": null,
  "height": null,
  "created_at": "2026-09-06T11:11:01.3181+00:00",
  "updated_at": "2026-09-06T11:11:01.3181+00:00",
  "visibility": "public",
  "source_stage": "1",
  "anonymized": true,
  "source_key": "web-blog",
  "origin": "ingest",
  "locked": false,
  "locked_by": null,
  "locked_at": null,
  "gate_state": {
    "g1": {
      "hits": [],
      "pass": true
    },
    "g2": {
      "pass": true,
      "total": 36,
      "issues": [
        "숫자·규격 같은 검증 가능한 구체가 부족합니다",
        "다른 문서와 겹치는 말이 대부분입니다",
        "과장·공허한 표현 1회: 효율적으로"
      ],
      "applies": true
    },
    "g3": {
      "pass": true,
      "required": false
    },
    "stage": "1",
    "decided_at": "2026-09-12T15:43:23.696Z"
  },
  "raw_id": "c6b50165-f07f-42e8-8253-7e190752ee51",
  "search_text": "SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자 - BizSpring BLOG  SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자 - BizSpring BLOG 콘텐츠로 건너뛰기 내비게이션 메뉴 인사이트 테크 활용 방법/사례 활용 방법/사례 성공사례 성공 사례 일반 광고/마케팅 에이전시 이커머스 미디어/콘텐츠 금융/핀테  SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자 - BizSpring BLOG\n\n콘텐츠로 건너뛰기\n\n내비게이션 메뉴\n\n인사이트\n\n테크\n\n활용 방법/사례\n\n활용 방법/사례\n\n성공사례\n\n성공 사례 일반\n\n광고/마케팅 에이전시\n\n이커머스\n\n미디어/콘텐츠\n\n금융/핀테크\n\n의료/헬스케어\n\n통신/인터넷\n\n뉴스/트렌드\n\n릴리즈 노트\n\n인터넷트렌드 ↗\n\n웹사이트 ↗\n\n# SQL 최적화를 위한 쿼리 실행계획, Explain 명령어에 대해 알아보자\n\n2025년 10월 13일 2025년 10월 13일\n테크\n\n프로그래밍 산업의 발전이 빠르게 이루어지고 프로그램의 기능이 많아지면서, 프로그램이 하나의 기능만을 하는 것이 아닌 여러 기능을 포함하고 있는 추세입니다.\n\n이러한 이유로 지속적으로 새로운 서비스가 출시되고, 사용자가 늘어나면서 데이터베이스에 쌓이는 데이터의 양도 점점 방대해지게 됩니다.\n\n데이터 양의 증가로 인하여, 데이터를 컨트롤하기 위해 사용되는 SQL(Structured Query Language) 쿼리 또한 점점 복잡해지고 개발 단계 및 서비스 초기에는 확인이 어려운 응답 속도 지연 등의 현상이 많이 발생하게 됩니다.\n\n많은 서비스 제공 업체에서는 이를 해결하기 위해, 쿼리 리팩토링을 수행하여 최적화를 이루어 결과가 빠르게 도출되도록 하는 과정을 거치게 됩니다.\n\n쿼리를 리팩토링 하기 위해서는 쿼리 분석이 필요한데, 각 데이터베이스마다 쿼리를 분석하는 프로그램을 제공하고 있습니다.\n\n이 중 MySQL에서 제공하는 EXPLAIN 에 대해 간단히 살펴보겠습니다.\n\n## EXPLAIN 이란?\n\nMySQL\n\nEXPLAIN은 MySQL에서 제공하는 명령어 입니다.\n각 쿼리에 대해 실행 계획을 분석하고 결과를 제공 합니다.\n\n해당 쿼리가 실행이 될 때 어떤 테이블에서 어떤 컬럼을 조회하는지, 얼마나 많은 데이터를 참조하는지, 어떤 테이블을 조회 시 시간을 많이 소요하는지 등 각 쿼리의 실행별 과정과 결과에 대해 상세 정보를 파악할 수 있습니다.\n\n이를 이용하여 성능 분석을 하고, 쿼리 튜닝을 통해 쿼리를 최적화할 수 있습니다.\n\n## EXPLAIN은 어떻게 사용이 가능할까 ?\n\nMySQL 쿼리 실행 단계 (출처: https://coderpad.io/blog/development/optimize-query-performance-mysql)\n\nMySQL의 경우 쿼리를 실행 시, 각 테이블의 데이터 분포를 참조하여 가장 적은 비용으로 데이터를 조회하는데, 이 과정에서 데이터를 기반으로 실행 계획을 수립하는 쿼리 옵티마이저 가 작동합니다.\nEXPLAIN은 이 옵티마이저의 실행 계획을 표 형식으로 보여주는 기능입니다.\n\n## EXPLAIN 명령어의 사용법과 확인 가능한 정보\n\n모든 테스트 쿼리는 다음 데이터를 이용하여 구현하였습니다.\n\nhttps://github.com/datacharmer/test_db\n\n&times;\n\nEXPLAIN의 사용법은 간단합니다.\n다음과 같이 실행할 쿼리 앞에 “EXPLAIN” 명령어를 붙여 사용할 수 있습니다.\n\n예시) 성 혹은 이름이 Matt인 직원을 조회하여 생년월일 내림차순으로 정렬\n\nEXPLAIN SELECT * FROM employees e1 WHERE e1.emp_no IN ( SELECT e2.emp_no FROM employees e2 WHERE e2.first_name = ‘Matt’ UNION SELECT e3.emp_no FROM employees e3 WHERE e3.last_name = ‘Matt’ ) ORDER BY birth_date DESC;\n\nid select_type table partitions type possible_keys key key_len ref rows filtered Extra\n1 PRIMARY e1   ALL         299,157 100 Using where; Using filesort\n\n2 DEPENDENT SUBQUERY e2   eq_ref PRIMARY PRIMARY 4 func 1 10 Using where\n\n3 DEPENDENT UNION e3   eq_ref PRIMARY PRIMARY 4 func 1 10 Using where\n\n4 UNION RESULT <union2,3>   ALL             Using temporary\n\nEXPLAIN 명령어를 실행하면 다음과 같이 결과가 출력됩니다.\n각 항목에 대한 설명은 다음과 같습니다.\n\n실행 계획\n설명\n\nid\n실행 계획 결과의 ID 번호\n\nselect type\nSELECT 문의 유형\n\ntable\n참조 테이블명\n\npartitions\n파티셔닝이 되어있을 경우 사용되는 필드명, 파티셔닝이 되어 있지 않을 경우 NULL\n\ntype\n해당 테이블 데이터의 접근 유형, 쿼리 튜닝에 가장 중요한 요소 중 하나\n\npossible_keys\n데이터 조회 시 사용 가능한 인덱스 필드 목록\n\nkey\n실행에 사용할 기본 키 혹은 인덱스명, 없을 경우 NULL\n\nkey_len\n실제 사용할 기본 키 혹은 인덱스의 길이\n\nref\nReference, 테이블 조인 시 어떤 조건으로 해당 테이블에 접근하는 지\n\nrows\n쿼리 실행 시 조회되는 데이터 수\n\nfiltered\n이 쿼리로 실행 결과로 전체 데이터 중 필터링된 데이터의 비율\n\nExtra\nMySQL 옵티마이저가 제공하는 힌트, 쿼리 튜닝에 가장 중요한 요소 중 하나\n\n이 중 눈여겨 봐야할 항목인 type , Extra 에 대해 살펴보겠습니다.\n\n### type\n\ntype 은 해당 테이블에 있는 데이터에 접근하는 방식을 표시하는 필드입니다. 옵티마이저가 어떤 방법으로 row를 조회하는 지 나타내기 때문에 대상 테이블로 접근이 효율적인지 아닌지 판단을 할 수 있는 아주 중요한 항목 입니다.\n특히 접근 방식 중, ALL 의 경우 쿼리에 사용되는 인덱스가 없어 모든 데이터를 탐색 한다는 의미입니다. 모든 데이터를 탐색하기 때문에 시간이 다소 소요되고 쿼리 실행이 지연되는 주된 요인이 됩니다. 그러므로 인덱스 생성, 필터링을 통한 쿼리 튜닝의 주요 대상이 됩니다.\n접근 방식은 다음과 같은 종류가 존재합니다. 상위에 위치한 항목일수록 속도가 빠릅니다.\n\nType\n설명\n\nsystem\n테이블에 데이터가 1행 밖에 없는 경우\n\nconst\n쿼리 결과가 1건을 반환, 가본 키 혹은 고유 키를 이용한 조건 필터링의 경우\n\neq_ref\n조인(Join) 시 기본 키를 사용한 경우, 조인 단계에서 인덱스 혹은 기본 키로 필터링 하여 단 1건의 데이터를 조회할 경우\n\nref\n조인 시 기본 키 혹은 고유 키가 아닌 인덱스를 사용한 경우\n\nref_or_null\nref에서 NULL 비교가 추가된 형태\n\nindex_merge\n여러 개의 인덱스가 동시에 사용되는 경우\n\nunique_subquery\n서브쿼리 접근에서 기본 키 혹은 고유 키를 사용하는 경우\n\nindex_subquery\n서브쿼리 접근에서 인덱스를 사용하는 경우\n\nrange\n인덱스를 하나의 값이 아닌 범위로 검색하는 경우, 성능 순위는 낮으나 해당 방법으로도 빠른 성능을 보장\n\nindex\n인덱스를 처음부터 끝까지 조회하는 경우, all과 비슷한 형식이나 인덱스이기 때문에 all 보다는 효율적\n\nall\n테이블의 모든 데이터를 조회하는 경우, 가장 비효율적이므로 튜닝의 대상이 됨\n\n### Extra\n\nExtra 는 옵티마이저가 해당 쿼리를 어떻게 처리할 것인지에 대한 추가 정보를 보여줍니다. 이 정보를 통해 해당 쿼리가 실행될 때의 최적화 상태를 알 수 있어 쿼리 튜닝에 중요한 요소 중 하나입니다.\nExtra 항목 중 Using temporary 와 Using filesort 의 경우 많은 비용이 필요하므로 쿼리 튜닝의 대상이 될 수 있습니다.\nExtra의 여러 항목 중 주요 값들을 정리하면 다음과 같습니다.\n\nExtra\n의미\n설명\n\nUsing where\nWHERE 조건 필터링 수행\n인덱스가 아닌 필드로 필터링\n\nUsing index\n커버링 인덱스 사용\n테이블 데이터를 읽지 않고 인덱스만으로 쿼리를 처리함\n\nUsing index condition\n인덱스 조건 푸시다운(Index Condition Pushdown) 사용\n일부 WHERE 조건이 인덱스 수준에서 처리됨\n\nUsing temporary\n임시 테이블 생성\nGROUP BY , DISTINCT , UNION , ORDER BY 등에서 중간 결과를 저장하기 위해 사용됨, 튜닝의 고려 대상이 됨\n\nUsing filesort\n파일 정렬 수행\n인덱스를 사용하지 않고 별도로 정렬 작업을 수행함, 튜닝의 고려 대상이 됨 ( ORDER BY 에서 주로 발생)\n\nRange checked for each record\n각 레코드마다 범위 스캔을 시도\n매우 비효율적이므로 튜닝의 대상\n\nUsing join buffer (Block Nested Loop)\n조인 버퍼 사용\n인덱스를 사용하지 못해 조인 시 메모리 버퍼를 사용함\n\nUsing sort_union / union / intersect\n인덱스 조합 사용\n여러 인덱스를 병합하여 결과를 도출함\n\nNo tables used\n테이블 접근 없음\n예: SELECT 1 같은 단순 계산 쿼리\n\nEXPLAIN 은 쿼리 튜닝을 시작할 때 가장 먼저 확인해야 하는 도구입니다. 실행 계획을 통해 MySQL이 데이터를 어떻게 처리하는지 파악하면, 인덱스 사용 여부나 조인 방식 등 성능 저하의 원인을 명확히 찾을 수 있습니다. 이러한 분석 과정을 거치면 감이 아닌 근거를 기반으로 쿼리 튜닝을 효율적으로 수행할 수 있습니다. 쿼리 최적화가 필요할 때는 EXPLAIN을 적극적으로 활용해 실행 계획을 검토해 보시길 권합니다.\n\n최신 마케팅/고객 데이터 활용 사례를 받아보실 수 있습니다.\n비즈스프링 뉴스레터 구독하기 →\n\n## Related Posts via Categories\n\n구글애즈가 정확검색·구문검색 키워드까지 AI 모드에 노출하기 시작했다 — 자동화 상품 없이 AI 답변 화면에 들어가는 첫 실험\nAI가 React 앱을 직접 디버깅 – Agent 기반 디버깅\nChatGPT 광고가 픽셀·전환 API·맞춤 오디언스를 갖췄다 — 답변 화면이 측정 가능한 광고 매체가 되는 순간\nAI 시대, 데이터도 설명이 필요합니다\nMCP 클라이언트는 Authorization Server를 어떻게 찾는가: 공식 MCP TypeScript SDK와 VS Code 구현 비교\nRAG 시대의 GEO: AI가 콘텐츠를 읽는 방식과 스키마의 진짜 역할\nAI 에이전트로 웹 데이터 수집 가능 여부 자동 검증하기\nGA4 Intraday 실시간 테이블, 대시보드 원천 데이터로 바로 사용할 수 있을까?\n워크플로우 오케스트레이션 플랫폼 Temporal 알아보기\niOS 14.5부터 GA4까지, 환경 변화가 가져온 업무 폭증을 해결하는 실무 전략은…?\n\n다음에 대해 검색하기...\n\n최신 글 둘러보기\n\n기존 SEO와 무엇이 같고 무엇이 다른가\n\n콘텐츠가 답인 걸 모르는 사람은 없습니다 — 문제는 지속입니다\n\n광고비를 늘리지 않고 매출을 늘린 회사들은 무엇을 했나\n\n코호트로 비교하면 광고 예산 판단이 달라집니다\n\nGEO를 위한 글쓰기를 위한 작은 노하우\n\n(해외동향) 광고주가 광고플랫폼 리포트에서 자체 측정으로 옮겨가고 있다.\n\n구글애즈가 정확검색·구문검색 키워드까지 AI 모드에 노출하기 시작했다 — 자동화 상품 없이 AI 답변 화면에 들어가는 첫 실험\n\nAI가 React 앱을 직접 디버깅 – Agent 기반 디버깅\n\nChatGPT 광고가 픽셀·전환 API·맞춤 오디언스를 갖췄다 — 답변 화면이 측정 가능한 광고 매체가 되는 순간\n\n마케팅 자동화, 무엇부터 자동화해야 할까?\n\n출처: https://blog.bizspring.co.kr/%ed%85%8c%ed%81%ac/sql-%ec%b5%9c%ec%a0%81%ed%99%94%eb%a5%bc-%ec%9c%84%ed%95%9c-%ec%bf%bc%eb%a6%ac-%ec%8b%a4%ed%96%89%ea%b3%84%ed%9a%8d-explain-%eb%aa%85%eb%a0%b9%ec%96%b4/",
  "embedding": null,
  "embedded_at": null,
  "embedding_hash": null,
  "map_x": null,
  "map_y": null,
  "backlinks": [],
  "html_url": "https://bizspring.ai/kb/ref/web/blog-bizspring-co-kr/sql-최적화를-위한-쿼리-실행계획-explain-명령어에-대해-알아보자-bizspring-blog",
  "markdown_url": "https://bizspring.ai/kb/ref/web/blog-bizspring-co-kr/sql-최적화를-위한-쿼리-실행계획-explain-명령어에-대해-알아보자-bizspring-blog.md"
}