MySQL Korean Manual

:::MySQL Korea:::
제목검색
MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select
MySQL 한글 매뉴얼에 대하여..

상위메뉴리스트 ◆
1 MySQL 한글 매뉴얼에 대하여.. 본 매뉴얼은 오픈 소스 데이터 베이스의 대명사인 MySQL 데이터 베이스에 대한 사용 설명서로서, MySQL AB가 발행한
2 MySQL 설치 및 업그레이드 하기 “MySQL 5.0 Reference Manual”을 한국어로 번역한 것입니다.
3 사용 설명서
4 MySQL 프로그램 사용하기 MySQL DB는 속도, 안정성, 대중성에 있어서 이미 확고한 자리를 잡은 데이터 베이스 시스템입니다. MySQL AB의 한국내 공식
5 데이터 베이스 관리 골드 파트너사인 ㈜아이티 브릿지는 한국내 MySQL DB 사용자께서 MySQL DB가 가지고 있는 특징과 장단점을 보다 효과적으
6 리플리케이션 로 파악할 수 있도록 본 한글 매뉴얼을 만들었으며, 따라서 현업에 MySQL을 적용하시고자 하시는 분에게 좋은 참고가 되길 바랍
7 최적화(Optimization) 니다.
8 클라이언트 및 유틸리티 프로그램

본 매뉴얼은 “MySQL 5.0 Reference Manual”의 내용을 1:1로 번역을 한 것이며, 따라서 모든 목차는 원본과 일치합니다. 영
9 언어 구조 (Language Structure)
문 원본을 참조하시고자 하는 분들을 위해서, 본 사이트에서는 영문 원본 매뉴얼도 함께 제공을 하고 있습니다.
10 문자 셋 지원
(참고하시는 중에 잘못된 부분을 발견하실 경우에는, 우리 회사에 연락을 주시기 바랍니다.)
11 데이터 타입
12 함수와 연산자
- 저작권 공지-
13 SQL 문법(SQL Statement Syntax)
본 한글 매뉴얼의 소유권은 ㈜아이티 브릿지에 있으며, 우리 회사의 사전 허가 없이 무단 복제를 하거나, 다른 웹사이트에 게재하는 것을 금지하오
17 스토어드 프로시저와 함수
니 많은 협조를 부탁 드립니다.
18 트리거
19 뷰(Views)
20 INFORMATION_SCHEMA 데이터 베이스
http://www.mysqlkorea.com/develop/sub_07.html2006-08-03 오후 3:14:03
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 2. MySQL 설치 및 업그레이드 하기
2. MySQL 설치 및 업그레이드 하기 2.1. 일반 설치 사항
2 MySQL 설치 및 업그레이드 하기 2.1.1. MySQL이 지원하는 OS
2.1 일반 설치 사항 2.1.2. 설치할 MySQL 배포판 선택하기
2.1.1 MySQL이 지원하는 OS 2.1.3. MySQL 다운 로드 하기

2.1.4. MD5 체크섬(Checksums) 또는 GnuPG 를 사용해서 패키지 집적도 검사하기
2.1.2 MYSQL 설치 배포판 선택하기
2.1.5. 설치 레이 아웃(Layouts)
2.1.2.1 설치할 MySQL 버전 선택하기
2.2. 바이너리 매포판을 사용해서 표준 MySQL 설치하기
2.1.2.2 배포판 포맷 선택하기
2.3. 윈도우에 MySQL 설치 하기
2.1.2.3 릴리즈는 언제 어떻게 발표 되는가
2.3.1. 설치 패키지 선택하기
2.1.2.4 릴리즈 철학—릴리즈판에는 알려진 오류가 없다
2.3.2. 자동 설치기를 사용한 MySQL 설치하기
2.1.2.5 MySQL AB사가 컴파일한 MySQL 바이너리
2.3.3. MySQL 설치 마법사 사용하기
2.1.3 MySQL 가져오기
2.3.4. 구성 마법사 사용하기
2.1.4 MD5 체크썸(Checksums) 또는 GnuPG를 사용해서 패키지 검사 2.3.5. 노인스톨 집 아카이브(Noinstall Zip Archive )로부터 MySQL 설치하기
하기
2.3.6. 설치 아카이브 추출하기
2.1.4.1 MD5 체크썸 검증
2.3.7. 옵션 파일 생성하기
2.1.4.2 GnuPG를 사용한 서명 검사 2.3.8. 서버 타입 선택하기
2.1.4.3 RPM을 사용한 서명 체크 2.3.9. 처음으로 서버 시작하기
2.1.5 설치 레이 아웃 2.3.10. 윈도우 명령어에서 MySQL 시작하기
2.2 바이너리 배포판을 사용해서 표준 MySQL 설치하기 2.3.11. 윈도우 서비스 형태로 MySQL 시작하기
2.3 윈도우에 MySQL설치 하기 2.3.12. MySQL 설치 테스트
2.3.1 설치 패키지 선택 하기 2.3.13. 윈도우에서 MySQL 설치 문제 해결(Troubleshooting)
2.3.2 자동 설치기를 사용한 MySQL 설치 2.3.14. 윈도우에서MySQL 업그레이드 하기
2.3.3 MySQL 설치 마법사 사용 하기 2.3.15. 유닉스상의 MySQL과 윈도우상의 MySQL 비교

2.4. 리눅스에 MySQL 설치하기
http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=0&scate=0&idx=55 (1 / 4)2006-08-03 오후 3:15:15

:::MySQL Korea:::
2.3.3.1 설치 마법사 소개 2.5. Mac OS X에 MySQL 설치하기
2.3.3.2 MySQL설치 마법사 다운 로드 및 시작 하기 2.6. NetWare에 MySQL 설치하기
2.3.3.3 설치 타입 선택 하기 2.7. 다른 유사 유닉스에 MySQL 설치하기

2.8. 소스 배포판을 사용해서 MySQL 설치하기
2.3.3.4 커스텀 설치 다이어로그
2.8.1. 소스 배포판 소개
2.3.3.5 확인(Confirmation) 다이어로그(Dialog)
2.8.2. 전형적인 configure 옵션들
2.3.3.6 MySQL 설치 마법사에 의한 변경 사항
2.8.3. 개발 단계 트리로부터 설치하기
2.3.3.7 설치 마법사를 사용한 MySQL 업그레이드
2.8.4. MySQL컴파일 문제 다루기
2.3.4 구성(Cinfiguration) 마법사 사용 하기
2.8.5. MIT-pthreads 노트
2.3.4.1 구성 마법사 소개
2.8.6. 윈도우에 소스로부터 MySQL 설치하기
2.3.4.2 MySQL 구성 마법사 시작 하기
2.8.7. 윈도우에 MySQL 클라이언트 컴파일하기
2.3.4.3 관리 옵션 선택하기 2.9. 설치후 설정 및 테스트
2.3.4.4 구성 타입 선택 하기 2.9.1. 윈도우에 설치후 과정
2.3.4.5 서버 타입 다이어로그 2.9.2. 유닉스에 설치후 과정
2.3.4.6 데이터 베이스 사용량 다이어로그 2.9.3. 초기 MySQL 계정 보안 작업하기
2.3.4.7 InnoDB 테이블 스페이스 다이어로그 2.10. MySQL 업그레이드 하기
2.3.4.8 동시 접속 다이어로그 2.10.1. MySQL 5.0에서 업그레이드 하기
2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그 2.10.2. MySQL 4.1에서 5.0으로 업그레이드 하기
2.3.4.10 문자 셋 다이어로그 2.10.3. MySQL 데이터 베이스를 다른 머신으로 복사하기

2.11. MySQL 다운 그레이드 하기
2.3.4.11 서비스 옵션 다이어로그
2.11.1. 4.1로 다운 그레이드 하기
2.3.4.12 보안 옵션 다이어로그
2.12. OS-특성 노트
2.3.4.13 확인 다이어로그
2.12.1. 리눅스 노트
2.3.4.14 my.ini 파일의 위치
2.12.2. Mac OS X 노트
2.3.4.15 my.ini 파일 편집 하기
2.12.3. Solaris 노트
2.3.5 노인스톨(Noinstall) 집(Zip) 아카이브로 부터 MySQL 설치 하기
2.12.4. BSD 노트
2.3.6 설치 아카이브 풀기
2.12.5. 다른 유닉스 노트
2.3.7 옵션 파일 생성하기 2.12.6. OS/2 노트
2.3.8 MySQL 서버 타입 선택하기 2.13. Perl 설치 노트
2.3.9 처음으로 서버를 시작 하기 2.13.1. 유닉스에 Perl 설치하기
2.13.2. 윈도우에 ActiveState Perl 설치하기

:::MySQL Korea:::
2.3.10 윈도우 명령어 라인으로 MySQL 시작하기 2.13.3. Perl DBI/DBD 인터페이스 사용상의 문제점
2.3.11 윈도우 서비스의 형태로 MySQL 시작 하기
2.3.12 설치된 MySQL 테스트 하기 이 장에서는 MySQL을 다운 로드하고 설치하는 방법에 대해 설명을 한다. 아래에서는 이러한 과정을 개략적
2.3.13 윈도우에서 MySQL 설치 문제 해결 으로 설명을 한 다음에 나중에 보다 자세한 설명을 하기로 하겠다. 여러분이 이미 설치되어 있는 버전을 새로
2.3.14 윈도우에서 MySQL 업그레이드 하기 운 버전으로 업그레이드를 할 생각이라면, Section 2.10, “MySQL 업그레이드 하기”를 참조하기 바란다.
2.3.15 윈도우에서의 MySQL과 유닉스에서의 MySQL 비교 1. 여러분이 사용하는 플랫폼을 지원하는지 검사. 모든 시스템이 MySQL을 구동 시키는데 적합
한 것은 아니라는 사실을 알아두기 바란다. Section 2.1.1, “MySQL이 지원하는 OS”을 참조할
2.4 리눅스에 MySQL 설치 하기
것.
2.5 Mac OS X에 MySQL 설치 하기
2. 설치할 배포판 선택. 대부분의 MySQL 버전은 몇가지의 배포판 포맷으로 제공된다. 여러분은
2.6 Installing MySQL on NetWare
바이너리(컴파일 이전) 프로그램 또는 소스 코드를 가지고 있는 패키지 않된(pre-packaged) 배포
2.7 유닉스와 유사한 다른 시스템에 MySQL 설치 하기
판을 선택할 수 있다. 우리는 또한 최근의 개발 단계에 있는 제품을 보고 우리가 새로운 코드에 대해
2.8 소스 배포판을 사용해서 MySQL 설치하기
테스트를 하는데에 도움을 주고자 하는 사람들을 위해 현재의 소스 트리에 접속할 수 있는 방법도 함
2.8.1 소스 배포판 설치 소개
께 제공을 한다. 어떤 버전 및 타입의 배포판을 사용할 지 결정하기 위해서는, Section 2.1.2, “설치
2.8.2 전형적인 configure 옵션들
할 MySQL 배포판 선택하기”를 참조할 것.
2.8.3 개발 단계 소스 트리를 가지고 MySQL 설치하기 3. 설치할 배포판 다운 로드하기. 다운 로드 방법에 대해서는, Section 2.1.3, “MySQL 다운 로
2.8.4 MySQL 컴파일 문제 다루기 드하기”를 참조할 것. 배포판의 집적도를 검사하기 위해서는, Section 2.1.4, “MD5 체크섬
2.8.5 MIT-pthreads 노트 (Checksums) 또는 GnuPG 를 사용해서 패키지 집적도 검사하기”의 지침을 따를 것.
2.8.6 소스 배포판을 사용해서 윈도우에 MySQL 설치하기 4. 배포판 설치하기. 바이너리 배포판으로부터 MySQL을 설치하기 위해서는, Section 2.2, “바
2.8.7 윈도우에서 MySQL 클라이언트 컴파일 하기 이너리 매포판을 사용해서 표준 MySQL 설치하기”의 지침을 따를 것. 현재의 개발 단계 소스 트리
2.9 MySQL설치 후 설정 및 테스트 에서 또는 소스 배포판을 사용해서 MySQL을 설치하기 위해서는 Section 2.8, “소스 배포판을 사
2.9.1 윈도우에서 MySQL설치후 해야 할 과정 용해서 MySQL 설치하기”의 지침을 따를 것.
2.9.2 유닉스에서 MySQL설치후 해야 할 과정 여러분이 설치하는 과정에서 어려움을 느끼게 된다면, Section 2.12, “OS-특성 노트”를 참조하
여 특정 플랫폼에 대한 문제를 해결하기 바란다.
2.9.2.1 mysql_install_db 구동상의 문제점들
5. 설치후 필요한 설정 작업 하기. MySQL을 설치한 후에는, Section 2.9, “설치후 설정 및 테스
2.9.2.2 자동으로 MySQL 을 시작하기 및 종료하기
트”의 과정을 읽어 보기 바란다. 이 섹션에는 MySQL 서버가 올바르게 동작할 수 있게끔 만드는 방
2.9.2.3 MySQL 서버 시작하기와 문제점 해결 하기
법에 대한 중요한 정보를 포함하고 있다. 또한, 초기 MySQL 계정에 대한 보안 작업을 하는 방법도
2.9.3 초기 MySQL 계정에 보안 작업하기
설명을 하는데, 이 초기 계정들은 여러분이 패스워드를 설정하기 전까지는 패스워드를 갖고 있지 않
2.10 MySQL 업그레이드 하기
게 된다. 이 섹션은 여러분이 MySQL을 바이너리 또는 소스 배포판을 사용해서 설치했는지에 따라
2.10.1 MySQL 5.0에서 업그레이드 하기
적용이 된다.
2.10.2 MySQL 4.1에서 5.0으로 업그레이드 하기
6. 여러분이MySQL 벤치마크 스크립트를 구동 시키고자 한다면, MySQL용 Perl을 반드시 설치해

:::MySQL Korea:::
야 한다.Section 2.13, “Perl 설치 노트”를 참조할 것.

2.10.3 MySQL 데이터 베이스를 다른 머신으로 복사하기
2.11 MySQL 다운 그레이드 하기
2.11.1 4.1로 다운 그레이드 하기
2.12 OS 관련 노트
2.12.1 리눅스 노트
2.12.1.1 리눅스 OS 노트
2.12.1.2 리눅스 바이너리 배포판 노트
2.12.1.3 리눅스 소스 배포판 노트
2.12.1.4 리눅스 설치후 과정 노트
2.12.1.5 리눅스 x86 노트
2.12.1.6 리눅스 SPARC 노트
2.12.1.7 리눅스 Alpha 노트
2.12.1.8 리눅스 PowerPC 노트
2.12.1.9 리눅스 MIPS 노트
2.12.1.10 리눅스 IA-64 노트
2.13 Perl 설치 노트
2.13.1 유닉스에 Perl 설치하기
2.13.2 윈도우에 ActiveState Perl 설치하기
2.13.3 Perl DBI/DBD 인터페이스를 사용하는데 있어서의 문제점

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.1. 일반 설치 사항
2. MySQL 설치 및 업그레이드 하기 2.1.1. MySQL이 지원하는 OS(Operating Systems)

2.1. 일반 설치 사항 2.1.2. MySQL 설치 배포판 선택하기
2.1 일반 설치 사항 2.1.3. MySQL 가져 오기
2.1.1 MySQL이 지원하는 OS 2.1.4. MD5 체크섬(Checksums) 또는 GnuPG 를 사용해서 패키지 검사하기
2.1.5. 설치 레이 아웃(Layouts)
MySQL을 설치하기 전에, 여러분은 아래의 사항을 고려해야 한다:
1. MySQL을 여러분의 머신에서 구동 시킬것인지 결정.
2. 설치할 배포판을 선택.
3. 배포판을 다운 로드하고 내용물을 검증.
이 섹션은 위의 단계를 실행하는데 필요한 정보를 제공한다. 위의 단계를 수행하고 나면, 여러분은 다음 장에서
2.1.3 MySQL 가져오기
설명하는 방식을 사용해서 각자가 선택한 배포판을 설치할 수 있게 될 것이다.
2.1.4 MD5 체크썸(Checksums) 또는 GnuPG를 사용해서 패키지
검사 하기
2.1.4.1 MD5 체크썸 검증

2.1.4.2 GnuPG를 사용한 서명 검사
2.1.4.3 RPM을 사용한 서명 체크
2.1.5 설치 레이 아웃
http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=0&idx=562006-08-03 오후 3:16:54
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.1.1. MySQL이 지원하는 OS
2. MySQL 설치 및 업그레이드 하기 이 섹션에서는 MySQL을 구동시키는데 사용할 수 있는 OS 리스트를 설명한다.

2.1. 일반 설치 사항
2.1.1 MySQL이 지원하는 OS 우리는GNU Autoconf를 사용하며, 따라서 MySQL은 C++컴파일러가 있고 POSIX쓰레드(thread)를 실행하는 모든 현대의 시스
템에 포팅될 수 있다.(쓰레드 지원은 서버를 위해 필요하다. 클라이언트 코드만 컴파일 한다면, C++컴퍼일러만 필요하다.) 우리
는 소프트웨어를 주로 리눅스(수세 및 레드헷), FreeBSD, 및 썬 솔라리스에서 개발하고 있다(버전 8 및 9).
MySQL은 아래와 같은 OS및 쓰레드 패키지 조합에서 성공적인 컴파일이 이루어졌다는 보고를 받고 있다. 많은 OS의 경우, 네이
티브 쓰레드(native thread)는 최신의 버전에서만 지원된다는 점을 유의하자.
● 네이티브 쓰레드와 AIX 4.x, 5.x. Section 2.12.5.3, “IBM-AIX 노트” 참조.
● 아미가(Amiga).
● MIT-pthreads 패키지와 BSDI 2.x. Section 2.12.4.4, “BSD/OS Version 2.x 노트” 참조.
● 네이티브 쓰레드와 BSDI 3.0, 3.1 및 4.x . Section 2.12.4.4, “BSD/OS Version 2.x 노트” 참조.
● 네이티브 쓰레드와 Digital Unix 4.x. Section 2.12.5.5, “Alpha-DEC-UNIX 노트(Tru64)” 참조.
● MIT-pthreads 패키지와 FreeBSD 2.x. Section 2.12.4.1, “FreeBSD 노트” 참조.
● 네이티브 쓰레드와 FreeBSD 3.x 및 4.x. Section 2.12.4.1, “FreeBSD 노트” 참조.
● 리눅스쓰레드(LinuxThread)와FreeBSD 4.x. Section 2.12.4.1, “FreeBSD 노트” 참조.
● DCE 쓰레드 또는 MIT-pthreads 패키지와 HP-UX 10.20. Section 2.12.5.1, “HP-UX Version 10.20 노트” 참조.
● 네이티브 쓰레드와 HP-UX 11.x. Section 2.12.5.2, “HP-UX Version 11.x 노트” 참조.
● Linux 2.0+ with 리눅스쓰레드(LinuxThreads) 0.7.1+와 리눅스 2.0+ 또는 다양한 CPU 아키텍처에 대한 glibc 2.0.7
+. Section 2.12.1, “Linux 노트” 참조.
● Mac OS X. Section 2.12.2, “Mac OS X 노트” 참조.
● NetBSD 1.3/1.4 Intel 및 NetBSD 1.3 Alpha (GNU판이 요구됨). Section 2.12.4.2, “NetBSD 노트” 참조.
● Novell NetWare 6.0 및 6.5. Section 2.6, “NetWare 에 MySQL설치하기” 참조.

:::MySQL Korea:::
● 네이티브 쓰레드와 OpenBSD 2.5. MIT-pthreads 패키지와 OpenBSD 2.5 이전 버전. Section 2.12.4.3, “OpenBSD
2.5 노트” 참조.
● OS/2 Warp 3, FixPack 29 및 OS/2 Warp 4, FixPack 4. Section 2.12.6, “OS/2 노트” 참조.
● FSU pthreads 패키지 최신 포트와 SCO OpenServer 5.0.X . Section 2.12.5.8, “SCO UNIX 및OpenServer 5.0.x 노
트” 참조.
● SCO Openserver 6.0.x. Section 2.12.5.9, “SCO OpenServer 6.0.x 노트”.
● SCO UnixWare 7.1.x. Section 2.12.5.10, “SCO UnixWare 7.1.x 및 OpenUNIX 8.0.0 노트” 참조.
● 네이티브 쓰레드와 SGI Irix 6.x . Section 2.12.5.7, “SGI Irix 노트” 참조.
● SPARC 및 x86상의 네이티브 쓰레드와 Solaris 2.5 및 이상 버전. Section 2.12.3, “Solaris 노트” 참조.
● MIT-pthreads 패키지와 SunOS 4.x. Section 2.12.3, “Solaris 노트” 참조.
● Tru64 Unix. Section 2.12.5.5, “Alpha-DEC-UNIX 노트(Tru64)” 참조.
● Windows 9x, Me, NT, 2000, XP, 및 Windows Server 2003. Section 2.3, “윈도우에 MySQL 설치하기” 참조.
모든 플랫폼이 MySQL을 잘 구동시키는 것은 아니다. 어떤 플랫폼이 미션 크리티컬(mission-critical)한 고부하(high-load)의

MySQL서버에 가장 적합한지는 아래의 요소에 의해 결정된다:
● 쓰레드 라이브러리에 대한 일반적인 안정성. 플랫폼이 뛰어난 명성을 갖고 있지 않는다고 하면, MySQL은 다른 모든 것이
완벽하다 하더라도, 그 자체가 호출하는 쓰레드 라이브러리만큼만 안정성이 보장된다.
● 대칭 다중 프로세서(symmetric multi-processor(SMP))시스템의 장점을 살리는 커널 및 쓰레드 라이브러리의 능력. 다
른 말로 표현하면, 프로세스가 쓰레드를 생성할 때, 프로세스는 원래의 프로세스가 아닌 다른 CPU상에서 쓰레드를 구동 시
키는 것이 가능하여야 한다.
● 지나친 문맥의 없이, 자주 짧은 크리티컬한 범위에서 뮤텍스(mutex)를 얻고 공개하기 위한 커널 및 쓰레드 라이브러리의
능력. 만약 pthread_mutex_lock() 의 실행이 너무 불안해서 CPU에 여분의 시간이 없게 된다면, 이것은 MySQL에 심각
한 문제를 야기한다. 만일 이 문제를 제대로 다루지 않으면, 추가로 CPU를 장착한다 하더라도 MySQL은 느려지게 된다.
● 일반적인 파일 시스템(filesystem)의 안정성 및 성능.
● 만일 여러분의 테이블이 크다면, 성능은 파일 시스템이 큰 파일을 어떻게 효과적을 처리하는지에 따라 전적으로 의존하게
된다.
● MySQL AB사에는 플랫폼에 대한 전문적인 견해가 있음. 만약 여러분이 자신의 플랫폼을 잘 알고 있다면, 우리는 그 플랫
폼에 대해 최적화를 할 수 있고 컴파일 시간을 확정해 줄 수 있다. 우리는 또한 MySQL에 여러분의 시스템을 최적화 시키
는 것에 대한 조언도 제공하여 준다.
● 우리는 내부적으로 유사한 구성 환경에 대해 대단히 많은 테스트를 진행하였다.

:::MySQL Korea:::
● 수많은 사용자가 유사한 구성 환경의 플랫폼에서 성공적으로 MySQL을 구동하였다.
이전의 표준에 근거하여, 이 시점에서 MySQL을 구동하기에 가장 적합한 플랫폼은 수세 리눅스 2.4 또는 2.6커널을 사용하는
x86, ReiserFS (또는 유사한 리눅스 배포판) 및 솔라리스(2.7-9)와 스팍(SPARC)이다. FreeBSD 는 세번째로 잘 동작하는 것
이지만, 우리는 진정으로 쓰레드 라이브러리가 개선된 후에는 제일 잘 돌아가는 플랫폼의 범주에 속하기를 원한다. 우리는 또한, 아
직은 동일한 안정성과 성능을 제공하지는 않지만, 현재 MySQL이 컴파일되고 구동되는 모든 다른 플랫폼이 이러한 최상위 범주에
속하기를 희망한다. 이것은 우리의 입장에서는 MySQL이 의존하는OS 및 라이브러리 컴퍼넌트 개발자와의 부단한 협력이 필요한
것이다. 만일 여러분이 이러한 컴퍼넌트 중 하나를 개선하는데 관심이 있고, 이러한 요소를 개발하는데 영향력을 미칠 수 있는 입장
에 있다면, 그리고 MySQL을 보다 효과적으로 구동시키는데 있어서 보다 많은 정보를 필요로 한다면, MySQL internals 메일링 리
스트에 이메일을 보내주길 바란다. Section 1.7.1, “MySQL 메일링 리스트” 참조.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.1.2. MySQL 설치 배포판 선택하기

2.1.2.1. MySQL 설치 버전 선택하기
2. MySQL 설치 및 업그레이드 하기 2.1.2.2. 배포판 포맷 선택하기
2.1. 일반 설치 사항 2.1.2.3. 언제 어떻게 발표되는가
2.1.2 MYSQL 설치 배포판 선택하기 2.1.2.4. 릴리즈 철학—릴리즈판에는 알려진 오류(bug)가 없다
2.1.2.1 설치할 MySQL 버전 선택하기 2.1.2.5. MySQL AB사가 컴파일한 바이너리들

MySQL 설치를 준비할 때, 여러분은 어떤 버전을 사용할 지를 결정해야 한다. MySQL 개발은 몇몇 릴리즈 시리즈로 이루어
지며, 여러분의 필요에 가장 적합한 제품을 골라야 한다. 어떤 버전을 설치할 지를 결정한 후에는, 배포판 포멧을 결정해야 한
다. 릴리즈된 제품들은 바이너리 또는 소스 포맷으로 되어 있다.
:::MySQL Korea:::
제목검색
2.1.2.1. 설치할 MySQL 버전 선택하기

2. MySQL 설치 및 업그레이드 하기 여러분이 가장 처음으로 결정해야 할 것은 제품(가장 안정적임)을 사용할 것인지 또는 개발 릴리즈판을 사용할 것인지를 결
2.1. 일반 설치 사항 정하는 것이다. MySQL의 개발 과정에는, 여러 개의 릴리즈 시리즈가 공존하는데, 각각의 시리즈는 완성도가 서로 다른 단계
2.1.2 MYSQL 설치 배포판 선택하기 를 갖게 된다:

● MySQL 5.1 는 다음 단계의 릴리즈 시리즈이며, 여기에는 새로운 기능들이 구현될 예정이다. 알파(Alpha)릴리즈는
현재 관심 있는 사용자들이 광범위하게 사용하도록 되어 있다.
● MySQL 5.0는 현재 안정화(제품화 됨)된 릴리즈 시리즈이다. 새로운 버전을 오류 해결(bug fix)문제에 관련해서만
출시되고 있다; 새로운 기능이 추가되고 안정화 되지는 않는다.
● MySQL 4.1는 이전에 발표된 안정화(제품화 됨)된 릴리즈 시리즈이다. 새로운 릴리즈는 치명적인 오류 해결 및 보
안 문제 해결의 경우에만 출시된다. 새로운 기능이 이 시리즈에 추가되지는 않는다.
● MySQL 4.0 및 3.23은 이전에 안정화(제품화 됨)를 이룬 릴리즈 시리즈이다. 이 버전들은 현재는 활동을 하고 있지
않으며, 따라서 새로운 버전은 정말로 심각한 버그가 발생할 경우에만 발표된다(주로 보안 문제).
우리는 계속 오류를 해결해야 하고 여러가지 다른 해결도 진행해야 하기 때문에 완벽한 코드의 동결에 대해서는 믿지 않고 있
다. “다소 확정된”이라는 표현을 사용해서, 우리는 현재의 안정화된 제품내에 어떤것도 영향을 받지 않는 미미한 것들은 추
가할 수도 있다. 물론, 이전 시리즈에 관련된 오류 해결(bugfixes)은 이후 버전에서 계속 진행된다.
일반적으로, 여러분이 처음으로 MySQL을 시작하거나 또는 아직 바이너리 배포판이 깔려 있지 않은 시스템에 이것을 설치하
고자 할 경우에는, 우리는 안정적인 제품을 먼저 사용하기를 권장한다. 현재, 제품으로는 MySQL 5.0이 있다. 모든 MySQL
릴리즈는, 비록 개발 단계 시리즈라 하더라도, MySQL벤치 마크와 함께 검사 되며, 출시되기 전에 광범위한 테스트를 거치게
된다.
만일 이전의 오래된 시스템을 구동하고 있으며 시스템의 중단 없이(non-seamless) 새로이 업그레이드를 하고자 한다면, 여
러분은 현재 사용하고 있는 동일 릴리즈 시리즈의 최신 버전을 업그레이드 해야 한다(버전 숫자의 맨 마지막 숫자가 최신 버

:::MySQL Korea:::
전을 말함). 우리는 해당 버전의 “안정적인” 변경에 관련된 부분만 관련하여 치명적인 오류만을 수정한다.
만일 현재 제품화된 릴리즈에는 포함되지 않은 기능들을 사용하고자 한다면, 개발 단계에 있는 시리즈를 사용하면 된다. 개발
단계의 시리즈는 제품화된 시리즈보다는 안정적이지 못하다는 점을 유의한다.
만일 모든 패치(patches)와 오류 해결이 포함된 가장 최신의 소스를 사용하고자 한다면, 여러분은 우리의 비트키퍼
(BitKeeper) 저장소에 있는 것 중의 하나를 사용하면 된다. 여기에 있는 것은 아직 발표(release)된 것은 아니지만, 향후에
발표될 릴리즈 시리즈의 코드를 미리 검토할 수는 있을 것이다.
MySQL의 명명 계획(naming scheme)은 세 개의 숫자와 하나의 접미사로 이루어 진다; 예를 들면, mysql-5.0.12-beta.
릴리즈 내부에 포함된 숫자들은 다음과 같이 해석된다:
● 처음 숫자(5)는 주요 버전을 의미하며 파일의 포멧을 나타낸다. 모든 MySQL 5 릴리즈는 동일한 파일 포맷을 갖는
다.
● 두 번째 숫자(0)는 릴리즈 레벨이다. 주요 버전 번호와 함께 사용되면 릴리즈 시리즈 번호가 된다.
● 세 번째 숫자(12)는 릴리즈 시리즈에 있는 버전 번호이다. 이것은 새로운 버전이 출시될 때마다 더해진다. 일반적으
로 여러분은 최신의 릴리즈 버전을 사용하고자 할 것이다.
각각의 미약한 업데이트의 경우, 버전 문자열의 마지막 숫자가 증가한다. 중요한 새로운 기능이 추가되거나 또는 이전 버전과
다소 호환성이 떨어지게 되면, 두 번째 번호가 증가한다. 파일 포맷이 변경될 경우에는, 첫 번째 번호가 증가한다.
릴리즈 이름은 또한 발표되는 버전의 안정성을 나타내는 접미사를 포함한다. 하나의 시리즈안에 있는 릴리즈는 접미사의 셋
을 통해 얼마나 안정화를 이루고 있는지 나타낸다. 사용 가능한 접미사로는:
● 알파(alpha) 는 아직 전체적으로 테스트를 진행하지 않은 새로운 기능이 포함되었음을 나타낸다. 알려진 오류는 뉴
스 섹션에 서류로 정리 된다. Appendix D, MySQL Change History 를 참조할 것. 대부분의 알파 릴리즈는 새로운
명령어와 확장 기능을 구현한다. 주요 코드 변경이 포함될 수 있는 실제 개발 과정은 알파 릴리즈에서 이루어 진다. 하
지만, 우리는 이 릴리즈를 발표하기 전에 테스트를 진행한다.
● 베타(beta) 는 기능- 완성(feature-complete)이 이루어진 릴리즈를 의미하며 모든 새로운 코드는 테스트를 마쳤음
을 의미한다. 주요 기능들은 새롭게 추가되지는 않는다. 여기에는 알려진 치명적인 오류는 없다. 적어도 한달 동안에
는 치명적인 오류가 보고되지 않고 이전에 구현시킨 기능들을 신뢰하지 못하게 할 정도의 새로운 기능을 추가할 계획

:::MySQL Korea:::
이 없는 경우에 알파에서 베타로 버전을 변경시킨다..
모든 API, 외부적으로 보여지는 구조, 그리고 SQL명령문에 대한 컬럼들은 향후의 베타 버전, 릴리즈 예정, 또는 제
품화 릴리즈에서는 변경되지 않는다.
● 알씨(rc) 는 릴리즈 후보를 나타낸다; 즉, 일정 기간 동안 아무런 문제없이 잘 구동되는 베타 버전을 의미한다. 단지

작은 부분의 해결만 추가된다. (릴리즈 후보는 이전에는 감마(gamma)릴리즈로 알려졌다.)
● 접미사가 없다면, 그 버전은 일정 기간 동안, 다양한 사이트에서 플랫폼 관련 오류가 아닌 다른 치명적인 반복 오류가
보고되지 않은 버전을 가리킨다. 단지 치명적 오류 해결(bugfixes)만 적용된다. 이것은 우리가 제품(안정함)이라고
부르는 것이며 또는 “General Availability” (GA)릴리즈판이라고 부르는 것이다.
MySQL 은 대부분의 다른 제품과는 다소 차이가 있는 명명 계획(naming scheme)을 사용한다. 일반적으로는, 어떠한 버전

도 여러 주간 이상 동일 릴리즈의 새로운 버전으로 변경되지(replace) 않으면 사용하기에 안정적이라고 여겨진다.
MySQL의 모든 릴리즈는 우리의 표준 테스트와 벤치마크를 거침으로서 사용하기에 상대적으로 안정적이라는 것을 검증하게
된다. 표준 테스트는 이전에 발견된 모든 오류를 검사하도록 계속 확장 되어지기 때문에, 테스트 슈트(suite)는 보다 효과적
인 상태를 유지하게 된다.
모든 릴리즈는 적어도 아래의 툴을 사용해서 테스트 된다:
● 내부 테스트 슈트
mysql-test 디렉토리는 광범위한 테스트 케이스를 갖고 있다. 우리는 가상으로 모든 서버 바이너리에 대해 이 테스

트를 진행한다. 이 테스트 슈트에 대한 보다 많은 정보는 Section 24.1.2, “MySQL 테스트 슈트”를 참조할 것.
● MySQL 벤치마크 슈트
이 슈트는 컬럼 쿼리의 범위를 테스트한다. 이것은 또한 최신의 최적화 배치(batch)가 실제로 코드를 보다 빠르게 진
행시키는지에 대해서도 검사를 한다. Section 7.1.4, “MySQL 벤치마크 슈트”를 참조할 것.
● crash-me 테스트

:::MySQL Korea:::
이 테스트는 데이터 베이스가 지원하는 기능이 무엇이며 그 기능의 능력 제약 사항은 무엇인지를 판단한다.
Section 7.1.4, “MySQL 벤치마크 슈트”를 참조할 것.

:::MySQL Korea:::
제목검색
2.1.2.2. 배포판 포맷 선택하기

2. MySQL 설치 및 업그레이드 하기 설치할 MySQL의 버전을 선택한 후에는, 여러분은 바이너리 배포판을 사용할 지 아니면 소스 배포판을 사용할 지를 결정해
2.1. 일반 설치 사항 야 한다. 대부분의 경우, 여러분의 플랫폼에 해당하는 것이 있다면, 여러분은 주로 바이너리 배포판을 사용할 것이다. 바이너
2.1.2 MYSQL 설치 배포판 선택하기 리 배포판은, 리눅스에 대한 RPM 파일 또는 Mac OS X를 위한 DMG 패키지와 같이, 많은 플랫폼에 대해 네이티브(native)
2.1.2.1 설치할 MySQL 버전 선택하기 포맷으로 사용할 수 있다. 배포판은 또한 집 아카이브(Zip archive) 또는 압축된 tar 파일의 형태로 사용 가능하다.

바이너리 배포판을 선택하는 이유에는 아래의 것들이 포함한다:
● 바이너리 배포판은 일반적으로 소스 배포판보다 설치하기가 쉽다.
● 다양한 사용자의 요구 사항을 충족시키기 위해, 우리는 두 가지 다른 바이너리 버전을 제공한다. 하나는 코어 기능
(core feature)셋을 가지고 컴파일한 것이고, 다른 하나(MySQL-Max)는 확장된 기능셋을 가지고 컴파일한 것이
다. 두 버전 모두 동일한 소스 배포판을 가지고 컴파일한 것이다. 모든 네이티브 MySQL 클라이언트는 두 가지 중 하
나를 가지고 서버에 연결할 수 있다.
확장된 MySQL 바이너리 배포판은 -max 접미사로 구분되며 mysqld-max 와 같은 옵션으로 구성된다.
Section 5.3, “mysqld-max 확장된 MySQL 서버”를 참조할 것.
RPM 배포판의 경우, 만일 MySQL-Max RPM을 사용하고자 한다면, 여러분은 우선 표준 MySQL-server RPM
을 설치하여야 한다.
어떤 환경하에서는, 여러분은 소스 배포판으로 설치하는 것이 더 유익할 수 도 있을 것이다:
● 여러분은 MySQL을 특정 위치에 설치하길 원할 수도 있다. 표준 바이너리 배포판은 어떤 위치에도 설치를 할 수 있지

만, MySQL컴퍼넌트를 여러분이 원하는 장소에 설치하고자 할 때에는 보다 많은 유연성을 요구할 수도 있다.
● 여러분은 mysqld 을 구성해서 표준 바이너리 배포판에는 포함되어 있지 않은 기능들을 사용할 수 있게끔 하고 싶을
수도 있다. 여기에 이러한 이러한 기능들을 사용 가능하게 하는 가장 일반적인 옵션 리스트가 있다:
❍ --with-innodb

:::MySQL Korea:::
❍ --with-berkeley-db (모든 플랫폼에는 사용 가능하지 않음)

❍ --with-libwrap
❍ --with-named-z-libs (이것은 바이너리에 대해서만 적용됨)
❍ --with-debug[=full]
● 여러분은 표준 바이너리에 있는 기능들은 없게끔 mysqld 을 구성하고자 원할 수 있다. 예를 들면, 배포판은 모든 문
자열 셋을 지원하면서 컴파일 된다. 만일 보다 작은 MySQL서버를 원할 경우, 여러분이 필요로 하는 문자열 셋만 지
원하도록 MySQL을 재 컴파일 할 수 있다.
● 여러분은 특별한 컴파일러(pgcc와 같은)를 가질 수 있으며 또는 자신의 프로세서에 보다 최적화된 컴파일러 옵션을
사용하길 원할 수도 있다. 바이너리 배포판은 동일한 프로세서 패밀리에서부터 다양한 종류의 프로세서에서 실행하
는 옵션을 가지고 컴파일 되어진다.
● 여러분은 현재까지의 모든 오류가 해결된 소스를 얻기 위해 비트키퍼의 저장소에서 최신의 버전을 사용하고자 원할
수 있다. 예를 들면, 만일 여러분이 오류를 발견하고 이것을 개발팀에 보고를 한다면, 오류 해결은 소스 저장 공간에
서 이루어지고 여기에서 해결된 것을 얻을 수 있다. 오류 해결은 릴리즈가 실제로 해결되기 전에는 릴리즈 판에는 포
함되지 않는다.
● 여러분은 MySQL을 구성하는 C 및 C++코드를 읽고(또는 수정)하고 싶을 것이다. 이를 위해서는, 여러분은 소스 배
포판을 가져야 하는데, 왜냐하면 소스 코드는 항상 근본적으로 매뉴얼로 되어 있기 때문이다.
● 소스 배포판은 바이너리 배포판보다 더 많은 테스트와 예제를 가지고 있다.

:::MySQL Korea:::
제목검색
2.1.2.3. 릴리즈는 언제 어떻게 발표되는가

2. MySQL 설치 및 업그레이드 하기 MySQL 은 매우 빠르게 릴리즈를 진행하며 우리는 새로운 개발자들이 다른 MySQL개발자들과 정보를 공유하기를 원한다.
2.1. 일반 설치 사항 우리는 우리가 다른 사람들이 필요로 할 수도 있는 새롭고 유용한 기능들을 가질 때마다 새로운 릴리즈를 생산하고자 노력한
2.1.2 MYSQL 설치 배포판 선택하기 다.

우리는 또한 사용자가 쉽게 구현하고자 원하는 기능들을 지원하고자 노력한다. 우리는 우리의 유료 사용자가 원하는 것에 유
의하며, 그리고 특히 우리가 지원하는 고객들이 원하는 것에 대해 유의하며 지원을 하고자 노력한다.
새로운 버전을 다운 로드하고 하고 싶지 않는 사람은 없다. 여러분은 뉴스 섹션에서 여러분이 실제로 원하는 것들을 찾을 수
있을 것이다. Appendix D, MySQL Change History.를 참조할 것
우리는 MySQL을 업데이트할 때 아래의 정책을 사용한다:
● 릴리즈는 각 시리즈안에서 이루어 진다. 각 릴리즈의 경우, 버전의 최종 번호는 같은 시리즈안에 있는 이전 버전보다
하나가 많게 된다.
● 제품(안정화)릴리즈는 일년에 1-2번 출시한다. 하지만, 작은 오류가 발견되면, 오류를 해결한 릴리즈만 출시한다.
● 이전 버전에 대한 릴리즈/오류 해결은 매 4-8주 간격으로 발표한다.
● 플랫폼에 대한 바이너리 배포판의 주요 릴리즈는 우리가 진행한다. 다른 사람들이 시스템에 대한 바이너리 배포판을
만들 수는 있지만, 그리 흔한 일은 아니다.
● 우리는 작은 또는 그리 치명적이지는 않은 오류를 우리가 발견할 때마다 가능하면 빨리 수정한다. 이러한 해결은 비트
키퍼 저장소에서 찾을 수 있으며, 다음 릴리즈에 추가 되어진다.
● 릴리즈판에서 치명적인 오류가 발견될 경우에는, 우리는 가능한 한 빠른 시간에 새로운 버전에서 이를 수정하는 것이
원칙이다.(우리도 다른 업체가 하는 방식을 따르는 것이다!)
:::MySQL Korea:::
제목검색
2.1.2.4. 릴리즈 철학—릴리즈판에는 알려진 오류가 없다

2. MySQL 설치 및 업그레이드 하기 우리는 많은 시간과 노력을 들여 우리의 릴리즈판이 오류가 없도록 하고 있다. 우리는 지금까지 한번도 이미 알려져 있는 치명
2.1. 일반 설치 사항 적인 반복 오류가 있는 상태로 MySQL 버전을 발표한 적이 없다.(“치명적” 오류는 일반적인 사용 상황에서 MySQL이 깨
2.1.2 MYSQL 설치 배포판 선택하기 지거나, 정상적인 쿼리에 대해 부정확한 답을 만들어 내거나, 또는 보안상의 문제가 있다는 것을 의미한다.)

우리는 모든 공개된 문제, 오류 및 데이터 베이스 디자인 정책에 대한 이슈 사항에 대한 것들을 서류로 정리를 하였다.
Section A.8, “Known Issues in MySQL”.
우리는 안정적인 MySQL버전이 덜 안정적이 되지 않도록 하는 범위에서 모든 가능한 문제를 수정하는 것을 목표로 하고 있
다. 경우에 따라서는, 이것은 우리가 안정화(제품) 버전에서 수정하는 것이 아니라, 개발 단계에서 이를 진행한다는 것을 의미
하기도 한다. 근본적으로는, 이러한 이슈를 서류화 함으로서 사용자가 이를 인지할 수 있도록 하고 있다.
여기에 우리가 만들어 놓은 프로세스를 설명하기로 한다:
● 우리는 우리의 고객 지원 리스트에서 오류를 모니터링 하며, 오류 데이터 베이스는 http://bugs.mysql.com/과

MySQL 외부 메일링 리스트에 있다.
● 현재 사용되는 버전에 대한 모든 보고된 오류는 오류 데이터 베이스에 포함된다.
● 하나의 오류를 해결하면, 우리는 항상 이에 대한 테스트 케이스를 만들기 위해 노력하며 이것을 우리의 테스트 시스템
에 포함시켜서 오류가 검색되지 않는 상황에서는 결코 다시 발생하지 않도록 한다. (해결된 오류의 거의 90% 가 테스
트 케이스를 가지고 있다.)
● 우리는 MySQL에 새롭게 추가한 각각의 새로운 기능들에 대해 테스크 케이스를 생성한다.
● 새로운 MySQL 릴리즈를 만들기 전에, 해당 MySQL 버전(3.23.x, 4.0.x, 4.1.x, 5.0.x, 5.1.x, 등등)에 대해 보고된
모든 반복 오류가 해결되었는지 확인한다. 만일 내부의 MySQL의 디자인 정책상 어떤 것을 해결할 수가 없다면, 우리
는 이것을 매뉴얼에 서류로 정리한다. Section A.8, “Known Issues in MySQL”를 참조.
● 우리는 바이너리를 지원하고 테스트 슈트 및 벤치마크 슈트를 돌릴 수 있는 모든 플랫폼을 구축한다..

:::MySQL Korea:::
● 우리는 테스트 또는 벤치마크 슈트가 실패한 바이너리에 대해서는 발표하지 않는다. 만일 문제가 소스에 있는 일반적
인 에러로 인한 것이라면, 우리는 그것을 해결하고 모든 시스템에서 다시 한번 테스트를 진행한다.
● 프로세스 정립 및 테스트는 일주일간 진행한다. 만일 우리가 이 과정 중에 치명적인 오류를 보고 받으면(예를 들면,
코어 덤프에서 발생), 우리는 이 문제를 해결하고 프로세스를 재 정립한다.
● http://dev.mysql.com/에 바이너리를 발표한 후에는, 우리는 mysql 및 announce 메일링 리스트를 통해 이 메시지
를 발표한다. Section 1.7.1, “MySQL 메일링 리스트”를 참조할 것. 이 발표 메시지는 릴리즈에서 일어난 모든 변
경 사항과 알게 된 모든 문제를 포함한다. 릴리즈 노트에 있는 알려진 문제들 섹션은 릴리즈를 사용할 때에만 필요한
것이다.
● 우리의 사용자에게 빠른 시간에 MySQL의 새로운 기능들을 알려 주기 위해, 우리는 새로운 버전을 매 4-8주 동안 만
들기 위해 노력한다. 소스 코드 스냅 샷은 매일 생성되며 이것은 http://downloads.mysql.com/snapshots.php 에
서 볼 수 있다.
● 만일, 우리의 노력에도 불구하고, 릴리즈판이 발표된 후에 특정 플랫폼에서 치명적인 문제를 발생시키는 어떠한 오류
가 보고 되면, 우리는 이것을 해결한 후 그 플랫폼에 해당하는 새로운 릴리즈를 만든다.
● 안정화된 릴리즈를 만들기 위한 우리의 트랙 레코드는 매우 좋다. 최근의 150개의 릴리즈의 경우, 우리는 이중에서
10개 미만의 오류를 새롭게 만들었다. 이 중에 세가지는, 우리가 오랜 시간 동안 트랙 다운했던 구축 시스템중에 하나
에서 오류 glibc 라이브러리를 만든 오류였다.

:::MySQL Korea:::
제목검색
2.1.2.5. MySQL AB사가 컴파일한 MySQL 바이너리

2. MySQL 설치 및 업그레이드 하기 MySQL AB사의 서비스 차원에서, 우리는 우리가 보유하고 있는 시스템 또는 MySQL AB사를 지원하는 사용자가 보유한 시스템
2.1. 일반 설치 사항 에서 컴파일한 바이너리 배포판을 제공하고 있다.

플랫폼 관련 패키지 포맷에서 제공하는 바이너리에 추가하여, 우리는 압축한 tar파일의 형태로 여러 가지 플랫폼에 맞는 바이너리
배포판을 제공하고 있다(.tar.gz files). Section 2.2, “바이너리 배포판을 사용해서 표준 MySQL 설치 하기”를 참조할 것.
우리 웹 사이트를 통해 제공하고 있는 MySQL 5.0릴리즈에 대한 RPM 배포판 MySQL AB사가 작성한 것이다.
2.1.2.4 릴리즈 철학—릴리즈판에는 알려진 오류
가 없다
윈도우 배포판에 대해서는, Section 2.3, “윈도우에서 MySQL설치하기”를 참조할 것.
2.1.2.5 MySQL AB사가 컴파일한 MySQL 바이너
리
이러한 배포판들은 Build-tools/Do-compile를 사용해서 만들었으며, 이것은 소스 코드를 컴파일하고 scripts/
make_binary_distribution 을 사용해서 바이너리 tar.gz 아키이브를 만들어 낸다.
이러한 바이너리들은 다음의 컴파일러와 옵션들과 함께 구성되어진다. 이 정보는 모든 바이너리 tar파일 배포판의 스크립트 bin/
mysqlbug 내부에 있는 변수 COMP_ENV_INFO 및 CONFIGURE_LINE 에서 얻을 수도 있다.
아래의 configure 명령어 중에 어떤 것에 대해서 보다 많은 옵티말(optimal) 옵션를 원하는 사람이라면 원하는 것을 MySQL
internals 메일링 리스트에 이메일을 보내시면 얻을 수 있다. Section 1.7.1, “MySQL 메일링 리스트”를 참조 할 것.
만약에 MySQL의 디버그 버전을 컴파일 하고자 한다면, 여러분은 다음의 configure 명령어에 --with-debug 또는 --with-
debug=full 를 추가해야 하고 -fomit-frame-pointer 옵션은 모두 삭제해야 한다.
다음의 바이너리들은 MySQL AB사의 개발 시스템에 구축되어 있는 것이다:
● Linux 2.4.xx x86 with gcc 2.95.3:

:::MySQL Korea:::
• CFLAGS="-O2 -mcpu=pentiumpro" CXX=gcc CXXFLAGS="-O2 -mcpu=pentiumpro
• -felide-constructors" ./configure --prefix=/usr/local/mysql
• --with-extra-charsets=complex --enable-thread-safe-client
• --enable-local-infile --enable-assembler --disable-shared
• --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static
● Linux 2.4.x x86 with icc (Intel C++ Compiler 8.1 or later releases):
• CC=icc CXX=icpc CFLAGS="-O3 -unroll2 -ip -mp -no-gcc -restrict"
• CXXFLAGS="-O3 -unroll2 -ip -mp -no-gcc -restrict" ./configure
• --prefix=/usr/local/mysql --localstatedir=/usr/local/mysql/data
• --libexecdir=/usr/local/mysql/bin --with-extra-charsets=complex
• --enable-thread-safe-client --enable-local-infile --enable-assembler
• --disable-shared --with-client-ldflags=-all-static
• --with-mysqld-ldflags=-all-static --with-embedded-server --with-innodb
인텔 컴파일러 버전 8.1 및 최신 버전은 ‘순수(pure)’ C 및 C++에 대해서로 별개의 드라이버들을 갖고 있다; 만일

icc 버전 8.0 또는 그 이전 버전을 사용하고자 한다면, 여러분은 CXX=icc로 설정할 필요가 있다.
● Linux 2.4.xx Intel Itanium 2 with ecc (Intel C++ Itanium Compiler 7.0):
• CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline" CXX=ecc CXXFLAGS="-O2

:::MySQL Korea:::
• -tpp2 -ip -nolib_inline" ./configure --prefix=/usr/local/mysql
• --enable-local-infile
● Linux 2.4.xx Intel Itanium with ecc (Intel C++ Itanium Compiler 7.0):
• CC=ecc CFLAGS=-tpp1 CXX=ecc CXXFLAGS=-tpp1 ./configure
• --prefix=/usr/local/mysql --with-extra-charsets=complex
• --enable-thread-safe-client --enable-local-infile
● Linux 2.4.xx alpha with ccc (Compaq C V6.2-505 / Compaq C++ V6.3-006):
• CC=ccc CFLAGS="-fast -arch generic" CXX=cxx CXXFLAGS="-fast -arch
• generic -noexceptions -nortti" ./configure --prefix=/usr/local/mysql
• --enable-local-infile --with-mysqld-ldflags=-non_shared
• --with-client-ldflags=-non_shared --disable-shared
● Linux 2.x.xx ppc with gcc 2.95.4:
• CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
• -fno-omit-frame-pointer -felide-constructors -fno-exceptions

:::MySQL Korea:::
• -fno-rtti" ./configure --prefix=/usr/local/mysql
• --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin
• --enable-local-infile --disable-shared --with-embedded-server
• --with-innodb
● Linux 2.4.xx s390 with gcc 2.95.3:
• CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors" ./configure
• --prefix=/usr/local/mysql --with-extra-charsets=complex
• --enable-thread-safe-client --enable-local-infile --disable-shared
• --with-client-ldflags=-all-static --with-mysqld-ldflags=-all-static
● Linux 2.4.xx x86_64 (AMD64) with gcc 3.2.1:
• CXX=gcc ./configure --prefix=/usr/local/mysql
• --enable-local-infile --disable-shared
● Sun Solaris 8 x86 with gcc 3.2.3:

:::MySQL Korea:::
• --localstatedir=/usr/local/mysql/data --libexecdir=/usr/local/mysql/bin
• --enable-local-infile --disable-shared --with-innodb
● Sun Solaris 8 SPARC with gcc 3.2:
• --enable-local-infile --enable-assembler --with-named-z-libs=no
• --with-named-curses-libs=-lcurses --disable-shared
● Sun Solaris 8 SPARC 64-bit with gcc 3.2:
• CC=gcc CFLAGS="-O3 -m64 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3
• -m64 -fno-omit-frame-pointer -felide-constructors -fno-exceptions

:::MySQL Korea:::
• --enable-local-infile --with-named-z-libs=no
• --with-named-curses-libs=-lcurses --disable-shared
● Sun Solaris 9 SPARC with gcc 2.95.3:
• --enable-local-infile --enable-assembler --with-named-curses-libs=-lcurses
• --disable-shared
● Sun Solaris 9 SPARC with cc-5.0 (Sun Forte 5.0):
• CC=cc-5.0 CXX=CC ASFLAGS="-xarch=v9" CFLAGS="-Xa -xstrconst -mt
• -D_FORTEC_ -xarch=v9" CXXFLAGS="-noex -mt -D_FORTEC_ -xarch=v9"
• ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex
• --enable-thread-safe-client --enable-local-infile --enable-assembler
• --with-named-z-libs=no --enable-thread-safe-client --disable-shared
● IBM AIX 4.3.2 ppc with gcc 3.2.3:
• CFLAGS="-O2 -mcpu=powerpc -Wa,-many " CXX=gcc CXXFLAGS="-O2

:::MySQL Korea:::
• -mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions
• --enable-local-infile --with-named-z-libs=no --disable-shared
● IBM AIX 4.3.3 ppc with xlC_r (IBM Visual Age C/C++ 6.0):
• CC=xlc_r CFLAGS="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192"
• CXX=xlC_r CXXFLAGS ="-ma -O2 -qstrict -qoptimize=2 -qmaxmem=8192"
• ./configure --prefix=/usr/local/mysql --localstatedi

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.1.3. MySQL 가져오기
2. MySQL 설치 및 업그레이드 하기 MySQL의 현재 버전 및 다운 로드 설명서를 알아보기 위해서는 http://dev.mysql.com/downloads/ 에 있는 다운 로드 페이지를

2.1. 일반 설치 사항 찾아보기 바란다. 완벽하게 업데이트되는 MySQL 다운 로드 미러(mirror) 사이트에 대한 정보는 http://dev.mysql.com/
2.1.3 MySQL 가져오기 downloads/mirrors.html를 보면 알 수 있다. 여러분은 또한 미러 사이트 예정인 것에 대한 정보 및 정보가 제대로 업데이트 되지
않고 있는 미러 사이트에 대해서 어떻게 보고를 해야 하는지에 대한 정보도 알아볼 수 있다.
우리의 메인(main) 미러 사이트는 http://mirrors.sunsite.dk/mysql/에 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.1.4. MD5 체크썸(Checksums) 또는 GnuPG를 사용해서 패키지 검사 하기
2. MySQL 설치 및 업그레이드 하기 2.1.4.1. Verifying the MD5 Checksum

2.1. 일반 설치 사항 2.1.4.2. Signature Checking Using GnuPG
2.1.4 MD5 체크썸(Checksums) 또는 GnuPG를 사용해서 패키지 검 2.1.4.3. Signature Checking Using RPM
사 하기
2.1.4.1 MD5 체크썸 검증

2.1.4.2 GnuPG를 사용한 서명 검사 여러분의 의도와 일치하는 MySQL 패키지를 다운 로드를 한 다음 설치를 하기 전에, 여러분은 반드시 이 패키
2.1.4.3 RPM을 사용한 서명 체크 지가 손상되지 않았는지를 검사해야 한다. MySQL AB사는 세가지 검사 방법을 제공한다:
● MD5 체크썸(checksums)
● GNU 프라이버시 지침서인 GnuPG 를 사용한 암호화 서명
● RPM 패키지에 대해서는, 내장되어 있는RPM 집적도 검증 메커니즘
아래에서는 이러한 방식을 사용하는 방법에 대해 설명하고 있다.
만일 MD5 체크썸 또는GPG 서명이 일치하지 않으며, 우선 다른 미러 사이트에서 패키지를 다시 한번 다운 로

드해 본다. 만약 계속해서 검증이 실패할 경우, 우리에게 발생된 문제 및 여러분이 다운 로드한 미러 사이트와
전체 패키지 이름을 <webmaster@mysql.com> 또는 <build@mysql.com>로 알려 주기 바란다. 버그 레포
트 시스템을 사용해서 레포트를 보내주시기는 말기 바란다.
:::MySQL Korea:::
제목검색
2.1.4.1. MD5 체크썸 검증

2. MySQL 설치 및 업그레이드 하기
2.1. 일반 설치 사항 MySQL을 다운 로드한 후, 여러분은 MySQL다운 로드 페이지에서 제공하는 것 MD5체크썸 중에 하나를 가지고 검증을 해야 한
2.1.4 MD5 체크썸(Checksums) 또는 GnuPG를 다. 각 패키지는 개별 체크썸을 가지고 있으며 여러분은 아래의 명령어로 이것을 검증할 수 있으며, package_name 은 여러분이 다
사용해서 패키지 검사 하기 운 로드한 패키지의 이름이 된다:
2.1.4.1 MD5 체크썸 검증

2.1.4.2 GnuPG를 사용한 서명 검사 shell> md5sum package_name

예제:
shell> md5sum mysql-standard-5.0.19-linux-i686.tar.gz
aaab65abbec64d5e907dcd41b8699945 mysql-standard-5.0.19-linux-i686.tar.gz
여러분은 결과 체크썸(16진법 숫자열)이 다운 로드한 패키지의 하단에 표시되어 있는 것과 일치 하는지 확인해야 한다.
Note: 아카이브 내부에 있는 파일들을 검사하는 것이 아니라 아카이브 파일 (예를 들면, .zip 또는 .tar.gz 파일)의 체크 썸을 검사
하는 것이다.
모든 OS가 md5sum 명령어를 지원하는 것은 아니라는 것을 유의 한다. 어떤 OS는 단순히md5만을 호출하지만, 다른 것은 아무것
도 지원하지 않는 것도 있다. 리눅스의 경우, 이것은 GNU Text Utilities 패키지의 일 부분에 있으며, 이것은 다양한 플랫폼에서 사
용 가능 하다. 여러분은 소스 코드를 http://www.gnu.org/software/textutils/ 에서도 다운 로드할 수 있다. 만일 OpenSSL 이 설
치 되어 있다면, 여러분은 openssl md5 package_name 명령어를 대신 사용할 수 있다. md5 명령어 라인 유틸리티의 윈도우 실행
은 http://www.fourmilab.ch/md5/에서 얻을 수 있다. winMd5Sum 는 그래픽 기반의 MD5 검사 툴로서, http://www.nullriver.
com/index/products/winmd5sum에서 얻을 수 있다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
2.1.4.2. GnuPG를 사용한 서명 검사

2. MySQL 설치 및 업그레이드 하기 패키지의 인증 및 집적도를 검사하는 다른 방법능 암호 서명을 사용하는 것이다. 이 방법은 MD5 체크썸 검사보다는 신뢰도가 높으
2.1. 일반 설치 사항 나, 보다 많은 작업을 해야 한다.
2.1.4 MD5 체크썸(Checksums) 또는 GnuPG를

사용해서 패키지 검사 하기 MySQL AB사는, MySQL 다운로드 가능 패키지에 GnuPG (GNU Privacy Guard)를 사용한 서명을 해 놓았다. GnuPG은 필 짐머
2.1.4.1 MD5 체크썸 검증 맨(Phil Zimmermann )이 사용한 유명한 Pretty Good Privacy (PGP)에 대한 오픈 소스 진영의 대안 방법이다. GnuPG 에 대한
2.1.4.2 GnuPG를 사용한 서명 검사 보다 자세한 정보는 http://www.gnupg.org/을 참조하면 된다. 여기에는 다운 로드 방법 및 설치 방법에 대해서도 설명을 하고 있
다. 대부분의 리눅스 배포판은 이 패키지를 디폴트로 해서 배포되고 있다. http://www.openpgp.org/ 도 함께 참조 바람.
특정 패키지에 대한 서명 검증을 하기 위해서는, 우선 MySQL AB사의 공중(public) GPG 구축 키가 필요하게 되는데, 이것은
http://www.keyserver.net/에서 다운로드할 수 있다. 여러분이 다운 로드해야 할 키는 build@mysql.com 라는 이름의 것이다.
다른 방법으로는, 여러분은 아래의 문장에서 직접 키를 복사해서 사용할 수가 있을 것이다:
Key ID:
pub 1024D/5072E1F5 2003-02-03
MySQL Package signing key (www.mysql.com) <build@mysql.com>
Fingerprint: A4A9 4068 76FC BD3C 4567 70C8 8C71 8D3B 5072 E1F5
Public Key (ASCII-armored):

:::MySQL Korea:::
-----BEGIN PGP PUBLIC KEY BLOCK-----
Version: GnuPG v1.0.6 (GNU/Linux)
Comment: For info see http://www.gnupg.org
mQGiBD4+owwRBAC14GIfUfCyEDSIePvEW3SAFUdJBtoQHH/nJKZyQT7h9bPlUWC3
RODjQReyCITRrdwyrKUGku2FmeVGwn2u2WmDMNABLnpprWPkBdCk96+OmSLN9brZ
fw2vOUgCmYv2hW0hyDHuvYlQA/BThQoADgj8AW6/0Lo7V1W9/8VuHP0gQwCgvzV3
BqOxRznNCRCRxAuAuVztHRcEAJooQK1+iSiunZMYD1WufeXfshc57S/+yeJkegNW
hxwR9pRWVArNYJdDRT+rf2RUe3vpquKNQU/hnEIUHJRQqYHo8gTxvxXNQc7fJYLV
K2HtkrPbP72vwsEKMYhhr0eKCbtLGfls9krjJ6sBgACyP/Vb7hiPwxh6rDZ7ITnE
kYpXBACmWpP8NJTkamEnPCia2ZoOHODANwpUkP43I7jsDmgtobZX9qnrAXw+uNDI
QJEXM6FSbi0LLtZciNlYsafwAPEOMDKpMqAK6IyisNtPvaLd8lH0bPAnWqcyefep
rv0sxxqUEMcM3o7wwgfN83POkDasDbs3pjwPhxvhz6//62zQJ7Q7TXlTUUwgUGFj
a2FnZSBzaWduaW5nIGtleSAod3d3Lm15c3FsLmNvbSkgPGJ1aWxkQG15c3FsLmNv
bT6IXQQTEQIAHQUCPj6jDAUJCWYBgAULBwoDBAMVAwIDFgIBAheAAAoJEIxxjTtQ
cuH1cY4AnilUwTXn8MatQOiG0a/bPxrvK/gCAJ4oinSNZRYTnblChwFaazt7PF3q

:::MySQL Korea:::
zIhMBBMRAgAMBQI+PqPRBYMJZgC7AAoJEElQ4SqycpHyJOEAn1mxHijft00bKXvu
cSo/pECUmppiAJ41M9MRVj5VcdH/KN/KjRtW6tHFPYhMBBMRAgAMBQI+QoIDBYMJ
YiKJAAoJELb1zU3GuiQ/lpEAoIhpp6BozKI8p6eaabzF5MlJH58pAKCu/ROofK8J
Eg2aLos+5zEYrB/LsrkCDQQ+PqMdEAgA7+GJfxbMdY4wslPnjH9rF4N2qfWsEN/l
xaZoJYc3a6M02WCnHl6ahT2/tBK2w1QI4YFteR47gCvtgb6O1JHffOo2HfLmRDRi
Rjd1DTCHqeyX7CHhcghj/dNRlW2Z0l5QFEcmV9U0Vhp3aFfWC4Ujfs3LU+hkAWzE
7zaD5cH9J7yv/6xuZVw411x0h4UqsTcWMu0iM1BzELqX1DY7LwoPEb/O9Rkbf4fm
Le11EzIaCa4PqARXQZc4dhSinMt6K3X4BrRsKTfozBu74F47D8Ilbf5vSYHbuE5p
/1oIDznkg/p8kW+3FxuWrycciqFTcNz215yyX39LXFnlLzKUb/F5GwADBQf+Lwqq
a8CGrRfsOAJxim63CHfty5mUc5rUSnTslGYEIOCR1BeQauyPZbPDsDD9MZ1ZaSaf
anFvwFG6Llx9xkU7tzq+vKLoWkm4u5xf3vn55VjnSd1aQ9eQnUcXiL4cnBGoTbOW
I39EcyzgslzBdC++MPjcQTcA7p6JUVsP6oAB3FQWg54tuUo0Ec8bsM8b3Ev42Lmu
QT5NdKHGwHsXTPtl0klk4bQk4OajHsiy1BMahpT27jWjJlMiJc+IWJ0mghkKHt92
6s/ymfdf5HkdQ1cyvsz5tryVI3Fx78XeSYfQvuuwqp2H139pXGEkg0n6KdUOetdZ
Whe70YGNPw1yjWJT1IhMBBgRAgAMBQI+PqMdBQkJZgGAAAoJEIxxjTtQcuH17p4A
n3r1QpVC9yhnW2cSAjq+kr72GX0eAJ4295kl6NxYEuFApmr1+0uUq/SlsQ==

:::MySQL Korea:::
=YJkx
-----END PGP PUBLIC KEY BLOCK-----
이 구축 키를 여러분 개인의 공중 GPG 키링에(keyring) 넣기 위해서는, gpg –import를 사용한다. 예를 들면, 여러분이 키를
mysql_pubkey.asc라는 파일에 저장을 하였다면, 입력 명령어는 다음과 같이 보일 것이다:
shell> gpg --import mysql_pubkey.asc
공중 구축 키를 다운로드 하고 입력을 한후에, 여러분이 원하는 배포판 패키지와 그에 상응하는 서명을 다운로드 한다. 서명 파일
은 배포판의 이름과 동일한 이름을 가지고 확장자는.asc 가 된다. 예를 들면:
Distribution file mysql-standard-5.0.19-linux-i686.tar.gz
Signature file mysql-standard-5.0.19-linux-i686.tar.gz.asc
두개의 파일이 동일한 디렉토리에 저장되어야 한다는 것을 명심하여야 하며, 그 다음에는 아래의 명령어를 사용해서 배포판 파일
의 서명을 검사하도록 한다:
shell> gpg --verify package_name.asc
예제:
shell> gpg --verify mysql-standard-5.0.19-linux-i686.tar.gz.asc
gpg: Signature made Tue 12 Jul 2005 23:35:41 EST using DSA key ID 5072E1F5
gpg: Good signature from "MySQL Package signing key (www.mysql.com) <build@mysql.com>"
Good signature 메시지는 모든 것이 제대로 되어 있다는 것을 의미한다. 여러분은 insecure memory 경고문에 대해서는 전혀 신
경을 쓰지 않아도 된다.

:::MySQL Korea:::
GPG 문서를 통해서 공중 키의 활용법에 대해 보다 자세한 정보를 얻기 바란다.

:::MySQL Korea:::
제목검색
2.1.4.3. RPM을 사용한 서명 체크

2.1. 일반 설치 사항 RPM 패키지의 경우, 개별 서명이 존재하지 않는다. RPM 패키지는 내부에 GPG 서명과 MD5 체크썸을 갖고 있다. 여러분은 아래
2.1.4 MD5 체크썸(Checksums) 또는 GnuPG를 의 명령어를 사용해서 이 패키지를 검사할 수 있다:

사용해서 패키지 검사 하기
2.1.4.1 MD5 체크썸 검증 shell> rpm --checksig package_name.rpm
2.1.4.2 GnuPG를 사용한 서명 검사

Example:
shell> rpm --checksig MySQL-server-5.0.19-0.i386.rpm
MySQL-server-5.0.19-0.i386.rpm: md5 gpg OK
Note: 여러분이 RPM 4.1를 사용하고 이것이 (GPG) NOT OK (MISSING KEYS: GPG#5072e1f5)의 결과를 내보내면, 설사 여
러분이 MySQL 공중 구축 키(public build key)를 여러분 개인의GPG 키링(keyring)에 넣어 놓았다 하더라도, 여러분은 그 키를
RPM 키링(keyring)에 먼저 가져올 필요가 있다. RPM 4.1은 더 이상 여러분 개인의GPG 키링(또는 GPG 자체)를 사용하지 않는
다. 반대로, 그것은 시스템 확장 어플리케이션이고 사용자의 GPG공중 키링은 사용자 관련 파일이기 때문에 자신의 키링 자체를 유
지한다. MySQL 공중 키를 RPM 키링에 가져오기 위해서는, 우선 Section 2.1.4.2, “Signature Checking Using GnuPG”에서
키를 얻어야 한다. 그 다음에rpm --import 를 사용해서 키를 가져온다. 예를 들면, 만일 mysql_pubkey.asc 라는 이름의 파일에
공중 키를 저장하고 있다면, 이것을 다음의 명령어를 사용해서 가져온다:
shell> rpm --import mysql_pubkey.asc
MySQL 공중 키를 얻기 위해서는, Section 2.1.4.2, “GnuPG를 사용해서 서명 검사”.를 참조할 것.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.1.5. 설치 레이 아웃
2.1. 일반 설치 사항 이 섹션에서는 MySQL AB사가 제공하는 바이너리 또는 소스 배포판을 설치할 때 생성되는 디렉토리의 디폴트 레이 아웃에 대해
2.1.5 설치 레이 아웃 설명하기로 한다. 다른 벤더가 제공하는 배포판에 대해서는 우리가 여기에서 제공하는 레이 아웃과 다소 차이가 있을 것이다.
윈도우상의 MySQL 5.0의 경우, 디폴트 설치 디렉토리는 C:￦Program Files￦MySQL￦MySQL Server 5.0이 된다. (어떤 윈도
우 사용자는 MySQL이 이전에 사용했던 디폴트 디렉토리인 C:￦mysql에 설치하는 것을 선호할 수도 있는데, 여기에 설치하여도
서브 디렉토리의 레이 아웃은 동일한 형태를 갖게 된다.) 설치 디렉토리는 아래와 같은 서브 디렉토리를 갖는다:
Directory Contents of Directory
bin Client programs and the mysqld server
data Log files, databases
Docs Documentation
examples Example programs and scripts
include Include (header) files
lib Libraries
scripts Utility scripts
share Error message files
MySQL AB'의 리눅스 RPM 배포판의 설치는 다음과 같은 서브 디렉토리를 갖는다:

:::MySQL Korea:::
/usr/bin Client programs and scripts
/usr/sbin The mysqld server
/var/lib/mysql Log files, databases
/usr/share/doc/packages Documentation
/usr/include/mysql Include (header) files
/usr/lib/mysql Libraries
/usr/share/mysql Error message and character set files
/usr/share/sql-bench Benchmarks
유닉스의 경우, tar 파일 바이너리 배포판은 여러분이 선택한 곳(일반적으로는 /usr/local/mysql)에 패키지를 풀면서 설치되고 그
위치에 다음의 디렉토리를 생성한다:
bin Client programs and the mysqld server
data Log files, databases
docs Documentation, ChangeLog
include Include (header) files
lib Libraries
scripts mysql_install_db
share/mysql Error message files
sql-bench Benchmarks
소스 배포판은 여러분이 설정을 구성하고 컴파일을 한 후에 설치가 된다. 디폴트로는, 설치 단계는 파일을 /usr/local에 설치하며,
서브 디렉토리는 다음과 같다:

:::MySQL Korea:::
Bin Client programs and scripts
include/mysql Include (header) files
Info Documentation in Info format
lib/mysql Libraries
Libexec The mysqld server
share/mysql Error message files
sql-bench Benchmarks and crash-me test
Var Databases and log files
설치 디렉토리 안에서, 소스 설치의 레이 아웃은 아래의 방법에서 바이너리 설치와는 다르게 나타난다:
● mysqld 서버는 bin디렉토리가 아닌 libexec디렉토리에 설치된다.

● 데이터 디렉토리는 data가 아닌 var이다.
● mysql_install_db 은 scripts디렉토리가 아닌 bin 디렉토리에 설치된다.
● 헤더 파일과 라이브러리 디렉토리는 include 및 lib가 아닌 include/mysql 및 lib/mysql 가 된다.
여러분은 소스 배포판 디렉토리의 최상위에 있는 scripts/make_binary_distribution 스크립트를 실행함으로써 컴파일된 소스 배

포판으로부터 여러분 자신의 바이너리 설치를 생성할 수 있다.

:::MySQL Korea:::
제목검색
2.2. 바이너리 배포판을 사용해서 표준 MySQL 설치하기
2.2. 바이너리 배포판을 사용해서 표준 MySQL 설치하기

이 다음의 여러 섹션에서는 각각의 플랫폼에 맞는 네이티브 패키징 포멧을 사용한 패키지를 해당 플랫폼에 설치하는 방
2.2 바이너리 배포판을 사용해서 표준 MySQL 설치하기
법에 대해 설명 하기로 한다. (이것은 “바이너리 설치”라고도 부르고 있다.) 하지만, MySQL의 바이너리 배포판은 다
른 많은 플랫폼에서도 물론 사용 가능하다. 모든 플랫폼에 적용되는 일반적인 설치 설명서는 Section 2.7, “다른 유사
유닉스 시스템에 MySQL 설치하기”를 참조 하면 된다.
Section 2.1, “일반 설치 사항”를 참조 하면, 어떤 바이너리 배포판이 사용 가능하며 그것을 어떻게 다운 로드할 수 있
는지에 대한 보다 많은 정보를 찾을 수 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3. 윈도우에 MySQL설치 하기
2. MySQL 설치 및 업그레이드 하기 2.3.1. 설치 패키지 선택

2.3. 윈도우에 MySQL설치 하기 2.3.2. 자동 설치기를 이용한 MySQL 설치
2.3 윈도우에 MySQL설치 하기 2.3.3. MySQL 설치 마법사 사용하기
2.3.1 설치 패키지 선택 하기 2.3.4. 구성 마법사 사용하기
2.3.2 자동 설치기를 사용한 MySQL 설치 2.3.5. 노인스톨 집 아카이브(Noinstall Zip Archive)로부터 MySQL 설치 하기
2.3.6. 설치 아카이브 추출
2.3.3 MySQL 설치 마법사 사용 하기
2.3.7. 옵션 파일 생성
2.3.3.1 설치 마법사 소개
2.3.8. MySQL 서버 타입 선택하기
2.3.3.2 MySQL설치 마법사 다운 로드 및 시작 하기
2.3.9. 처음으로 서버 시작하기
2.3.3.3 설치 타입 선택 하기
2.3.10. 윈도우 명령어 라인에서 MySQL 시작하기
2.3.11. 윈도우 서비스 형태로 MySQL 시작하기
2.3.12. MySQL 설치 검사 하기
2.3.13. 윈도우에서 MySQL 설치 트러블 슈팅(Troubleshooting)
2.3.3.7 설치 마법사를 사용한 MySQL 업그레이드 2.3.14. 윈도우에서 MySQL 업그레이드 하기
2.3.4 구성(Cinfiguration) 마법사 사용 하기 2.3.15. 유닉스상의 MySQL과 윈도우상의 MySQL 비교하기
2.3.4.2 MySQL 구성 마법사 시작 하기 MySQL의 네이티브 윈도우 배포판은 버전3.21에서부터 MySQL AB사가 제공하고 있으며 매일 매일 다운 로드
2.3.4.3 관리 옵션 선택하기 횟수가 늘어나고 있다. 이 섹션은 윈도우에서 MySQL을 설치하는 과정을 설명하기로 한다.
2.3.4.4 구성 타입 선택 하기 Note: 이미 MySQL4.1.5 이전 버전이 설치된 시스템을 업그레이드 하고자 한다면, 여러분은 Section 2.3.14,
2.3.4.5 서버 타입 다이어로그 “윈도우에서 MySQL업그레이드 하기”에서 설명하고 있는 과정을 먼저 실행하야 한다.
2.3.4.6 데이터 베이스 사용량 다이어로그 윈도우에서 MySQL 을 구동하기 위해서는, 아래의 사항이 필요하게 된다:
2.3.4.7 InnoDB 테이블 스페이스 다이어로그

● 32-비트(bit) 윈도우 OS가 필요함. 9x, Me, NT, 2000, XP, 또는 윈도우 서버 2003등.
2.3.4.8 동시 접속 다이어로그

:::MySQL Korea:::
2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그 윈도우 NT-기반 OS(NT, 2000, XP, 2003)는 MySQL을 서버로 동작하게끔 한다. 윈도우 NT-기반
2.3.4.10 문자 셋 다이어로그 OS의 사용을 적극 권장한다. Section 2.3.11, “윈도우 서비스 형태로 MySQL 시작하기”를 참조할
2.3.4.11 서비스 옵션 다이어로그 것.

일반적으로, 여러분은 관리자 권한이 있는 계정을 사용해서 윈도우에 MySQL 을 설치해야 한다. 그렇지
않으면, 여러분은 PATH 환경 변수 또는 Service Control Manager 접근과 같은 특정 동작에서 문제를
직면할 수 있다.
● TCP/IP 프로토콜의 지원.
2.3.5 노인스톨(Noinstall) 집(Zip) 아카이브로 부터 MySQL 설치
● 패키지를 풀고, 설치하고, 그리고 여러분의 의도를 충족시킬 만큼 충분한 디스크 공간(일반적으로
하기
200MB 이상을 권장함).
2.3.7 옵션 파일 생성하기 여러분이 MySQL을 어떻게 사용것인지에 따라 기타의 요구 사항이 필요로 하게 된다:
2.3.8 MySQL 서버 타입 선택하기
2.3.9 처음으로 서버를 시작 하기 ● ODBC를 통해서 MySQL서버에 접속할 생각이라면, Connector/ODBC 드라이버가 필요하게 됨.
2.3.10 윈도우 명령어 라인으로 MySQL 시작하기 Section 23.1, “MySQL Connector/ODBC”를 참조할 것.
2.3.11 윈도우 서비스의 형태로 MySQL 시작 하기 ● 4GB보다 큰 테이블 크기를 필요로 한다면, NTFS또는 새로운 파일 시스템에 MySQL을 설치해야 한다.
2.3.12 설치된 MySQL 테스트 하기 테이블 생성시 MAX_ROWS AVG_ROW_LENGTH 를 사용하는 것을 잊지 말기 바란다.
Section 13.1.5, “CREATE TABLE 신텍스”를 참조할 것.
2.3.13 윈도우에서 MySQL 설치 문제 해결
2.3.14 윈도우에서 MySQL 업그레이드 하기
윈도우용 MySQL은 여러가지 배포판 형식으로 사용 가능하다:
2.3.15 윈도우에서의 MySQL과 유닉스에서의 MySQL 비교
● 셋업 프로그램이 있는 바이너리 배포판은 서버를 즉시 구동시키는데 필요한 모든 것을 갖고 있다. 다른 배

포판 포맷은 설치 위치에 단순히 패키지를 풀어 놓고 구성은 여러분 스스로 해야 하는 아카이브를 갖고 있
다. 자세한 사항은, Section 2.3.1, “Choosing An Installation Package”를 참조할 것.
● 소스 배포판은 모든 소스를 갖고 있으며 비주얼 스튜디오2003 컴파일러 시스템을 사용 가능하게 구축하
는 파일들을 지원한다.
일반적으로, 여러분은 설치기(installer)가 있는 바이너리 배포판을 사용할 것이다. 이것은 다른 것을 사용하는 것

보다 간단하며, MySQL을 다운 로드하여 설치하는데 있어서 별도의 것들이 필요하지 않게 된다. MySQL을 위한
윈도우 설치기는 GUI구성 마법사와 연결되어 있고, 자동으로 MySQL을 설치하며, 옵션 파일을 생성하고, 서버
를 구동 시키며, 그리고 디폴트 사용자 계정을 보안화 한다.

:::MySQL Korea:::
아래의 섹션에서는 바이너리 배포판을 사용한 MySQL 설치 방법을 설명한다. 설치기가 없는 설치 패키지의 사용
은, Section 2.3.5, “노인스톨(Noinstall) 집 아카이브로부터 MySQL설치 하기”에서 설명하는 과정을 따라 진
행하면 된다. 소스 배포판을 사용한 설치는, Section 2.8.6, “소스 배포판으로 윈도우에 MySQL 설치 하기”를
참조하기 바란다.
윈도우용 MySQL배포판은 http://dev.mysql.com/downloads/에서 다운로드 받을 수 있다. Section 2.1.3,
“MySQL 가져 오기”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.1. 설치 패키지 선택 하기
2.3. 윈도우에 MySQL설치 하기 MySQL 5.0의 경우, 윈도우에 MySQL을 설치할 때 세 가지의 설치 패키지를 선택할 수 있다:
2.3.1 설치 패키지 선택 하기
● The Essentials Package: 이 패키지는mysql-essential-5.0.19-win32.msi 와 비슷한 파일 이름을 갖고 있으며 윈도우
에 MySQL을 설치하는데 필요한 최소의 파일들을 갖고 있고, 구성 마법사를 갖고 있다. 이 패키지에는 임베디드 서버 또
는 벤치마크 슈트와 같은 선택적인 요소들은 없다.
● The Complete Package: 이 패키지는 mysql-5.0.19-win32.zip 와 비슷한 파일 이름을 갖고 있으며, 구성 마법사를 포
함해서 윈도우에 MySQL을 설치하는데 필요한 모든 파일들을 갖고 있다. 이 패키지에는 임베디드 서버 및 벤치마크 슈트
등이 포함되어 있다.
● The Noinstall Archive: 이 패키지는 mysql-noinstall-5.0.19-win32.zip 과 유사한 파일 이름을 가지며 구성 마법사
를 제외한 모든 설치 파일들이 포함된다. 이 패키지는 자동 설치기가 포함되지 않으며, 따라서 설치 및 시스템 구성을 수동
으로 해야 한다.
대부분의 사용자에게는 Essentials package를 권장한다. 여기에는 윈도우 설치기와 함께 사용할 수 있는 .msi 파일이 제공된다.
Complete 및 Noinstall 배포판은 집(Zip)아카이브 형태로 패키지되어 있다. 이것들을 사용하기 위해서는, .zip 파일을 해제할 수
있는 툴이 있어야 한다.
어떤 설치 패키지를 선택하는지에 따라 여러분은 서로 다른 설치 과정을 따라야 한다. Essentials 또는 Complete 패키지를 선택하
였다면, Section 2.3.2, “자동 설치기를 사용한 MySQL설치”를 참조 하기 바라며, Noinstall아카이브의 경우에는,
Section 2.3.5, “노인스톨 집 아카이브(Noinstall Zip Archive)를 사용한 MySQL 설치”를 참조하기 바란다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.2. 자동 설치기를 사용한 MySQL 설치
2.3. 윈도우에 MySQL설치 하기 새로운 MySQL 사용자는 윈도우상에서 MySQL 설치 마법사와 구성 마법사를 사용해서 MySQL을 설치 할 수 있다. 이러한 것들
2.3.2 자동 설치기를 사용한 MySQL 설치 은 처음 MySQL을 설치하는 사용자가 손쉽게 설치를 진행할 수 있도록 디자인되어 있다.
MySQL 설치 마법사 및 구성 마법사는 Essentials 및 Complete 설치 패키지에 들어 있다. 이것들은 대부분의 표준 MySQL설치
시 권장되는 것들이다. 싱글 서버 호스트에 MySQL의 다중 인스턴스(instances)를 설치하고자 하는 사용자 및 서버의 설정을 전
체적으로 제어하고자 하는 고급 사용자의 경우는 예외로 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.3. MySQL 설치 마법사 사용 하기
2. MySQL 설치 및 업그레이드 하기 2.3.3.1. 설치 마법사 소개

2.3. 윈도우에 MySQL설치 하기 2.3.3.2. MySQL설치 마법사 다운 로드 및 시작 하기
2.3.3 MySQL 설치 마법사 사용 하기 2.3.3.3. 설치 타입 선택
2.3.3.1 설치 마법사 소개 2.3.3.4. 커스텀(Custom) 설치 다이어로그(Dialog)
2.3.3.2 MySQL설치 마법사 다운 로드 및 시작 하기 2.3.3.5. 확인(Confirmation) 다이어로그(Dialog)

2.3.3.6. MySQL 마법사에 의한 변경 사항
2.3.3.7. 설치 마법사를 사용하여 MySQL업그레이드 하기
:::MySQL Korea:::
제목검색
2.3.3.1. 설치 마법사 소개
2.3. 윈도우에 MySQL설치 하기 MySQL 설치 마법사는 마이크로 소프트를 위한 최신의 설치기 기법을 사용하는 MySQL서버를 위한 설치기이다. MySQL 설치
2.3.3 MySQL 설치 마법사 사용 하기 마법사는, 구성 마법사와 조합을 이루어서, 사용자가 설치후 즉시 사용을 할 준비가 되어 있는 MySQL 서버를 설치하고 구성을
2.3.3.1 설치 마법사 소개 할 수 있게끔 한다.

MySQL 설치 마법사는 버전 4.1.5 및 그 이후 버전의 모든 MySQL서버를 위한 표준 설치기이다. 이전 버전의 사용자는 기존에
설치되어 있는 MySQL을 수동으로 정지 시킨 후 삭제한 다음에 MySQL 설치 마법사를 사용해서 MySQL을 설치하여야 한다. 보
다 자세한 사항은 Section 2.3.3.7, “설치 마법사를 사용해서 MySQL 업그레이드 하기”를 참조 하기 바란다.
마이크로 소프트사는 최신 윈도우 버전에 보다 개선된 윈도우 설치기(MSI)를 포함 시켜 놓았다. MSI는 윈도우2000, XP, 및 윈
2.3.3.7 설치 마법사를 사용한 MySQL 업그레이드 도우서버2003용 어플리케이션에 대한 표준(de-facto)이 되고 있다. MySQL 설치 마법사는 이 기법을 사용해서 보다 부드럽고
유연한 설치 과정을 진행하도록 하고 있다.
마이크로소프트 윈도우 설치 엔진은 윈도우 XP 버전의 릴리즈와 함께 개선되었다; 이전 버전의 윈도우를 사용하는 설치기에서
최신 버전의 윈도우 설치기 엔진으로 업그레이드하기 위한 보다 많은 정보는 this Microsoft Knowledge Base article 를 참조하
기 바란다.
부가적으로, 마이크로소프트는 최근에 WiX (Windows Installer XML) 툴킷을 출시하였다. 이것은 마이크로소프트가 최초로 진
행하는 최초의 오픈 소스 프로젝트이다. 이것은 오픈 소스 프로젝트이기 때문에, 그리고 이를 통해서 스크립트를 사용하는 기법
에 보다 유연성을 확보할 수 있기 때문에, 우리는 WiX로 전환을 하고 있다.
MySQL 설치 마법사를 개선하는 것은 여러분과 같은 사용자의 지원과 피드백에 의존한다. 만일 여러분에게는 중요한 기능들 중
일부가 MySQL 설치 마법사에 빠져 있는 것을 발견하면, 또는 버그를 발견할 경우에는, Section 1.8, “오류 또는 문제점 보고 하
기”에서 주어지는 방법을 통해 우리에게 내용을 보내주기 바란다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
2.3.3.2. MySQL설치 마법사 다운 로드 및 시작 하기

2.3. 윈도우에 MySQL설치 하기 MySQL 설치 패키지는 http://dev.mysql.com/downloads/에서 다운 로드할 수 있다. 다운 로드하는 패키지가 집(Zip)아카이브
2.3.3 MySQL 설치 마법사 사용 하기 안에 있다면, 아카이브를 먼저 추출(extract)하는 것이 필요하다.
마법사를 사작하는 과정은 여러분이 다운 로드한 설치 패키지의 컨텐츠에 달려 있다. 만일 다운 로드한 것에 setup.exe 파일이
있다면, 이것을 더블 클릭해서 설치를 시작하면 된다. 만일 .msi 파일이 있으면, 이것을 더블 클릭하면 된다.
:::MySQL Korea:::
제목검색
2.3.3.3. 설치 타입 선택 하기
2.3. 윈도우에 MySQL설치 하기 사용할 수 있는 설치 타입은 세 가지가 있다: Typical, Complete, 및 Custom.

Typical 설치 타입은 MySQL 서버, mysql 명령어-라인 클라이언트, 그리고 명령어-라인 유틸리티를 설치한다. 명령어-라인
클라이언트 및 유틸리티는 mysqldump, myisamchk, 및 기타 다른 툴을 가지고 있으며 여러분이 MySQL서버를 관리하는데 도
움을 준다.
Complete 설치 타입은 설치 패키지에 포함되어 있는 모든 요소들을 설치한다. 전체 설치 패키지는 임베디드 서버 라이브러리, 벤
치마크 슈트, 지원 스크립트, 및 서류와 같은 것들은 모두 갖고 있다.
2.3.3.7 설치 마법사를 사용한 MySQL 업그레이드 Custom 설치 타입은 여러분이 설치하고자 하는 패키지와 사용하고자 하는 설치 경로에 대해 전적으로 제어를 할 수 있게 한다.
보다 자세한 내용은 Section 2.3.3.4, “커스텀(Custom) 설치 다이어로그”를 참조 하기 바란다.
만일Typical 또는Complete 설치 타입을 선택하고 다음 버튼을 누르게 되면, 확인 화면으로 이동이 되고 지금 선택한 것이 확실
한지 다시 한번 확인을 한 후 설치가 진행된다. Custom 타입을 선택하고 다음 버튼을 누르면, 커스텀 설치 다이어로그 화면으로
이동한다. 이 과정은 Section 2.3.3.4, “커스텀 설치 다이어로그”에서 설명한다.
:::MySQL Korea:::
제목검색
2.3.3.4. 커스텀 설치 다이어로그

2.3. 윈도우에 MySQL설치 하기 만약에 MySQL설치 마법사가 설치하는 경로나 특정 요소를 변경하고자 한다면, Custom 설치 타입을 선택한다.

커스텀 설치 다이어로그 좌측에 있는 트리는 모든 설치 가능한 요소들을 나타낸다. 설치되지 않은 요소들은 빨간 색으로 X 아이콘
을 갖는다; 설치 되어진 요소들은 회색의 아이콘을 갖는다. 설치된 아이콘을 변경하기 위해서는, 해당 요소의 아이콘을 클릭한 후
나타나는 드롭 다운(drop-down)에서 새로운 옵션을 선택한다.
여러분은 디폴트 설치 경로를 변경하고자 할 때에는 화면에 표시된 설치 경로의 오른쪽에 있는 Change... 버튼을 눌러서 변경할
수 있다.
2.3.3.7 설치 마법사를 사용한 MySQL 업그레이드 설치 요소 및 설치 경로를 선택한 후에는, 다음 버튼을 누른후 확인(Confirmation) 다이어로그 화면으로 진행하면 된다.
:::MySQL Korea:::
제목검색
2.3.3.5. 확인(Confirmation) 다이어로그(Dialog)

2.3. 윈도우에 MySQL설치 하기 일단 설치 타입과 설치 요소를 선택적으로 선택을 하고 나면, 확인 다이어로그 창으로 이동을 한다. 여기에서 여러분이 선택한 설
2.3.3 MySQL 설치 마법사 사용 하기 치 타입 및 설치 경로를 다시 한번 확인할 수 있다.
여러분이 구성한 내용에 대해 확인을 마치고 나면, 설치 버튼을 누른다. MySQL을 설치하지 않은 상태에서 설치 마법사를 끝내려
면, 취소(Cancel)버튼을 누르면 된다.
설치가 완료된 후, 여러분은 MySQL웹 사이트에 등록을 할 수 있는 옵션을 볼 수 있다. 여기에 등록을 하면 여러분은 forums.
mysql.com에 있는 MySQL포럼에 등록 되어지며, 아울러 bugs.mysql.com 에 오류 레포트를 보고할 수 있고 또한 우리의 뉴스
2.3.3.6 MySQL 설치 마법사에 의한 변경 사항 레터를 정기적으로 구독할 수 있게 된다. 설치기에서 볼 수 있는 마지막 화면에서 여러분은 설치 정보를 요약해서 볼 수 있으며 구
2.3.3.7 설치 마법사를 사용한 MySQL 업그레이드 성 마법사를 시작할 수 있는 옵션을 볼 수 있는데, 이것을 가지고 여러분은 설정 파일을 생성하고, MySQL서비스를 설치하고, 그
리고 보안 설정을 할 수 있게 된다.
:::MySQL Korea:::
제목검색
2.3.3.6. MySQL 설치 마법사에 의한 변경 사항

2.3. 윈도우에 MySQL설치 하기 일단 설치 버튼을 누르면, MySQL 설치 마법사는 설치 과정을 시작하고 여러분 시스템을 아래에서 설명하는 것처럼 변경을 하게
2.3.3 MySQL 설치 마법사 사용 하기 만든다.
등록에 대한 변경 사항
MySQL 설치 마법사는 전형적인 설치 상황에서 하나의 윈도우 등록 키를 생성하는데, 이 키는 HKEY_LOCAL_MACHINE
￦SOFTWARE￦MySQL AB에 존재한다.
2.3.3.6 MySQL 설치 마법사에 의한 변경 사항 MySQL 설치 마법사는 설치되는 서버의 메인 버전 뒤에, 예를 들면 MySQL Server 5.0과 같은, 이름이 붙는 키를 하나 생성한
2.3.3.7 설치 마법사를 사용한 MySQL 업그레이드 다. 이것은 두개의 문자열 값을 갖는데, Location 및 Version이 된다. Location 문자열은 설치 디렉토리에 대한 경로를 갖는다.
디폴트 설치에서는 이것은 C:￦Program Files￦MySQL￦MySQL Server 5.0￦값을 갖는다. Version 문자열은 릴리즈 숫자
를 갖는다. 예를 들면, MySQL Server 5.0.19의 설치에서는, 키는 5.0.19의 값을 갖는다.
이러한 등록 키들은 MySQL서버의 설치 위치를 알려주는 외부 툴을 지원하는데 사용되며, 이것을 사용하면 MySQL서버의 경로
를 찾기 위해 하드디스크를 모두 검색할 필요가 없어지게 된다. 그리고 만약에 여러분이 MySQL 을 noinstall 집(Zip)아카이브
를 사용해서 설치하면, 등록 키는 생성되지 않는다.
시작 메뉴에 대한 변경 사항
MySQL 설치 마법사는 메이저 MySQL버전 다음에 이름을 붙인 공통 MySQL 메뉴 아래에 윈도우 시작 메뉴의 새로운 목록을 생
성한다. 예를 들면, 여러분이 MySQL 5.0을 설치 한다면, MySQL 설치 마법사는 시작 메뉴안에 MySQL 서버 5.0섹션을 만들게
된다.
아래의 목록들은 새로운 시작 메뉴 섹션에 생성되는 것들이다:

:::MySQL Korea:::
● MySQL 명령어 라인 클라이언트: 이것은 mysql 명령어 라인에 대한 단축 키(shortcut)이며 root 사용자로서 접속하도
록 구성된다. 여러분이 접속될 때 root 사용자 패스워드를 묻는 프롬프트가 나타난다.
● MySQL 서버 인스턴스 구성 마법사: 이것은 MySQL설정을 위한 단축키이다. 이 키를 사용해서 새롭게 설치된 서버를 설
정할 수 있으며, 또는 존재하는 서버를 재구성할 수 있다.
● MySQL 문서: 이것은 MySQL서버 설치 디렉토리에 로컬로 저장되어 있는 MySQL서버 문서와 연결하는 링크이다. 이
옵션은 MySQL을 Essential 설치 패키지를 사용하는 MySQL 설치의 경우에는 사용할 수 없다.
파일 시스템에 대한 변경 사항
디폴트 MySQL 설치 마법사를 사용하면 MySQL5.0서버는 C:￦Program Files￦MySQL￦MySQL Server 5.0에 설치되고
Program Files 은 어플리케이션이 디폴트로 설치되는 위치이며, MySQL서버의 메이저 버전은 5.0 이 된다. 이곳은 MySQL서버
를 설치하는 권장 위치이며, 이전 버전의 위치인 C:￦mysql에서 변경된 곳이다.
디폴트로는, 모든 MySQL 어플리케이션은 C:￦Program Files￦MySQL 에 있는 공통 디렉토리에 저장되는데, Program Files

은 윈도우 설치에서 어플리케이션이 디폴트로 저장되는 곳이다. 개발 장비에 전형적으로 설치되는 형태는 다음과 같을 것이다:
C:￦Program Files￦MySQL￦MySQL Server 5.0
C:￦Program Files￦MySQL￦MySQL Administrator 1.0
C:￦Program Files￦MySQL￦MySQL Query Browser 1.0
이렇게 함으로서 특정 시스템상에서 모든 MySQL어플리케이션을 보다 쉽게 관리할 수 있게 된다.

:::MySQL Korea:::
제목검색
2.3.3.7. 설치 마법사를 사용한 MySQL 업그레이드

2.3. 윈도우에 MySQL설치 하기 MySQL 설치 마법사는 MSI의 업그레이드 기능을 사용해서 서버를 자동으로 업그레이드할 수 있게 한다. 이 기능을 통해 여러분
2.3.3 MySQL 설치 마법사 사용 하기 은 이전에 설치해 놓은 버전을 수동으로 삭제하지 않고 새로운 버전으로 업그레이드 할 수 있게 된다. 설치기는 자동으로 중단
2.3.3.1 설치 마법사 소개 (shut down)되며 이전 MySQL의 서비스는 새 버전이 설치되기 전에 삭제된다.

자동 업그레이드는 설치가 동일 서버에서 이루어 지고 마이너 버전 번호가 동일할 경우에만 가능하다. 예를 들면, 여러분은
MySQL 4.1.5 에서 MySQL 4.1.6으로 자동 업그레이드는 진행할 수 있으나, MySQL 4.1 에서 MySQL 5.0으로는 진행할 수 없
다.
2.3.3.6 MySQL 설치 마법사에 의한 변경 사항 Section 2.3.14, “윈도우에서 MySQL 업그레이드 하기”를 참조 할 것.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.4. 구성(Cinfiguration) 마법사 사용 하기
2. MySQL 설치 및 업그레이드 하기 2.3.4.1. 구성 마법사 소개

2.3. 윈도우에 MySQL설치 하기 2.3.4.2. MySQL 구성 마법사 시작 하기
2.3.4 구성(Cinfiguration) 마법사 사용 하기 2.3.4.3. 관리 옵션(Maintenance Option)선택하기
2.3.4.1 구성 마법사 소개 2.3.4.4. 구성 타입 선택하기
2.3.4.2 MySQL 구성 마법사 시작 하기 2.3.4.5. 서버 터입 다이어로그

2.3.4.6. 데이터베이스 사용량 다이어 로그
2.3.4.3 관리 옵션 선택하기
2.3.4.7. InnoDB 테이블 스페이스(Tablespace) 다이어로
2.3.4.4 구성 타입 선택 하기
그
2.3.4.5 서버 타입 다이어로그
2.3.4.8. 동시 접속 다이어로그
2.3.4.6 데이터 베이스 사용량 다이어로그
2.3.4.9. 네트워킹 및 스트릭트(strict)모드 옵션 다이어로
그
2.3.4.10. 문자셋 다이어로그
2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그
2.3.4.11. 서비스 옵션 다이어로그
2.3.4.10 문자 셋 다이어로그 2.3.4.12. 보안 옵션 다이어로그
2.3.4.11 서비스 옵션 다이어로그 2.3.4.13. 확정(Confirmation) 다이어로그
2.3.4.12 보안 옵션 다이어로그 2.3.4.14. my.ini 파일의 위치
2.3.4.13 확인 다이어로그 2.3.4.15. my.ini 파일 편집하기
:::MySQL Korea:::
제목검색
2.3.4.1. 구성 마법사 소개
2.3. 윈도우에 MySQL설치 하기 MySQL구성 마법사는 윈도우에서 여러분의 서버를 자동으로 구성하는데 도움을 준다. MySQL구성 마법사는 여러분에
2.3.4 구성(Cinfiguration) 마법사 사용 하기 게 여러 가지 질문을 한 후 여러분의 대답을 my.ini 파일을 만들어 내는 템플릿에 적용함으로서 커스템(custom) my.ini
2.3.4.1 구성 마법사 소개 파일을 생성한다.

MySQL 구성 마법사는 MySQL 5.0 서버에 포함되어 있으며, 이것은 현재 윈도우 사용자만이 사용할 수 있다.
MySQL 구성 마법사는 여러 해 동안 수많은 사용자가 보내준 피드백을 통해 계속 기능을 확장해 나가고 있다. 하지만, 만
약에 어떤 기능이 부족하거나 꼭 필요한 기능을 원하는 경우에는, 언제든지 오류 데이터 베이스 레포트 지침을 따라서 보
2.3.4.6 데이터 베이스 사용량 다이어로그 고하여 주기 바란다. Section 1.8, “오류 또는 문제점 보고하기”를 참조할 것.
2.3.4.10 문자 셋 다이어로그
:::MySQL Korea:::
제목검색
2.3.4.2. MySQL 구성 마법사 시작 하기

2.3. 윈도우에 MySQL설치 하기 MySQL 구성 마법사는 전형적으로 MySQL설치 마법사를 종료한 후에 시작할 수 있다. 또한, 여러분은 윈도우 시작 매뉴
2.3.4 구성(Cinfiguration) 마법사 사용 하기 의 MySQL섹션에 있는 MySQL서버 인스턴스 마법사를 클릭해서 구동시킬 수도 있다.
다른 방법으로는, MySQL설치 패키지에서 bin 디렉토리를 찾은 다음 MySQLInstanceConfig.exe 파일을 직접 실행할
수도 있다.
:::MySQL Korea:::
제목검색
2.3.4.3. 관리 옵션 선택하기
2.3. 윈도우에 MySQL설치 하기 만약에 MySQL 구성 마법사가 현재 있는 my.ini 를 검색하면, 여러분은 자신의 현재 서버를 재구성하거나, 또는 my.ini
2.3.4 구성(Cinfiguration) 마법사 사용 하기 파일을 제거하고 MySQL서비스를 정지 및 삭제함으로써 서버 인스턴스를 삭제하는 옵션을 갖게 된다.
현재의 서버를 재 구성하기 위해서는, 재 구성 인스턴스(Re-configure Instance)옵션을 선택한 후 다음(Next)버튼을
누른다. 현재 있는 my.ini 파일은 mytimestamp.ini.bak로 재 명명되며, timestamp 은 현재 있었던 my.ini 파일이 생성
된 날짜와 시간이 된다. 현재의 서버 인스턴스를 제거하기 위해서는, 인스턴스 옵션 제거 버튼을 선택하고 다음 버튼을 누
르면 된다.
2.3.4.6 데이터 베이스 사용량 다이어로그 인스턴스 제거 옵션을 선택하게 되면, 확인 윈도우로 이동한다. 실행 버튼을 누른다. MySQL 구성 마법사는 MySQL 서
2.3.4.7 InnoDB 테이블 스페이스 다이어로그 비스를 종료하고 이릉 제거한 다음, my.ini 파일을 삭제한다. 서버 설치와 서버의data 폴더는 삭제되지 않는다.
2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그 재 구성 인스턴스 옵션을 선택하면, 여러분이 구성하고자 원하는 설정 타입을 선택할 수 있는 구성 타입 다이어로그 화면
2.3.4.10 문자 셋 다이어로그 으로 이동하게 된다.

:::MySQL Korea:::
제목검색
2.3.4.4. 구성 타입 선택 하기
2.3. 윈도우에 MySQL설치 하기 새로운 MySQL설치를 위해 MySQL구성 마법사를 시작할 때, 또는 기존의 설치에 대해 재구성 인스턴스 옵션을 선택할
2.3.4 구성(Cinfiguration) 마법사 사용 하기 경우, 구성 타입 다이어로그 화면으로 이동하게 된다.
사용 가능한 구성 타입은 두 가지가 있다: 상세 구성 및 표준 구성. 표준 구성 옵션은 서버 구성에 대해 많은 선택을 하지
않고 빠른 시간에 MySQL을 설치하고자 하는 새로운 사용자를 위한 것이다. 상세 구성 옵션은 서버 구성에 대해 보다 많
은 제어를 하고자 하는 고급 사용자를 위한 것이다.
만약에 여러분이 새롭게 MySQL을 사용하고 단일-사용자 개발 장비에 설치를 하고자 한다면, 표준 구성이 적합할 것이
2.3.4.6 데이터 베이스 사용량 다이어로그 다. 표준 구성 옵션은 MySQL 마법사가 서비스 옵션 및 보안 옵션을 제외한 모든 구성을 자동으로 설정하게끔 한다.
2.3.4.8 동시 접속 다이어로그 표준 구성은 현재 MySQL이 설치되어 있는 시스템과는 일치하지 않는 옵션을 설정할 수도 있다. 만약에 이미 존재하는
2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그 MySQL설치 시스템에 대해 설치를 다시 하고자 한다면, 상세 구성을 권장한다.
표준 구성을 완료하기 위해서는, Section 2.3.4.11, “서비스 옵션 다이어로그”, 및 Section 2.3.4.12, “보안 옵션 다
이어로그”에서 서비스 옵션과 보안 옵션을 각각 참조하기 바란다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.4.5. 서버 타입 다이어로그
2. MySQL 설치 및 업그레이드 하기 선택할 수 있는 서버 타입은 세 가지가 있다. 여러분이 선택하는 서버 타입은 MySQL구성 마법사가 메모리,
2.3. 윈도우에 MySQL설치 하기 디스크, 및 프로세서 사용량을 구성할 때 영향을 미친다.
● Developer Machine: 개인적으로만 사용 하고자 하는 전형적인 데스크 탑 웍크스테이션에
MySQL을 설치할 때 이 옵션을 선택한다. 다른 많은 데스크 탑 어플리케이션이 운영된다는 점을
가정한다. MySQL서버는 최소 시스템 자원을 사용하도록 구성된다.
● Server Machine: MySQL이 FTP, email, 그리고 웹 서버와 같은 다른 서버 어플리케이션과 함께
운영되는 서버를 위한 선택 옵션이다. MySQL서버는 적정한 시스템 자원을 사용하도록 구성된다.
2.3.4.5 서버 타입 다이어로그 ● Dedicated MySQL Server Machine: 이 옵션은 서버 장비가 MySQL만 전용으로 실행하는 용도
2.3.4.6 데이터 베이스 사용량 다이어로그 의 옵션이다. 다른 어떠한 어플리케이션도 같이 운영되지 않는다는 가정을 한다. MySQL서버는 모
2.3.4.7 InnoDB 테이블 스페이스 다이어로그 든 가능한 서버 자원을 사용하도록 구성된다.
:::MySQL Korea:::
제목검색
2.3.4.6. 데이터 베이스 사용량 다이어로그

2.3. 윈도우에 MySQL설치 하기 데이터 베이스 사용량 다이어로그는 MySQL테이블을 생성할 때 사용을 예상할 수 있는 스토리지 엔진을 표시한다. 여러
2.3.4 구성(Cinfiguration) 마법사 사용 하기 분이 선택한 옵션은 InnoDB스토리지 엔진을 사용할 수 있는지 그리고 서버 자원의 몇 퍼센트를 InnoDB에서 사용할 수
2.3.4.1 구성 마법사 소개 있는지를 결정한다.

● Multifunctional Database: 이 옵션은 InnoDB 및 MyISAM 스토리지 엔진 모두를 활성화 시키며 두 엔진에 서
버 자원을 동등하게 분할한다. 이 옵션은 두 엔진 모두를 규칙적으로 사용하는 사용자에게 권장되는 사항이다.
● Transactional Database Only: 이 옵션은 InnoDB 및 MyISAM 스토리지 엔진을 모두 활성화 시키지만, 대부
분이 서버 자원을InnoDB 스토리지 엔진에 할당한다. 이 옵션은 InnoDB엔진을 대부분 사용하고 MyISAM엔진
은 최소한 사용하는 사용자에게 권장된다.
● Non-Transactional Database Only: 이 옵션은 InnoDB 스토리지 엔진을 완벽하게 비 활성화 시키고 모든 서버
2.3.4.8 동시 접속 다이어로그 의 자원을 MyISAM 스토리지 엔진에 할당한다. 이 옵션은 InnoDB엔진을 사용하지 않는 사용자에게 권장할 수
2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그 있다.
:::MySQL Korea:::
제목검색
2.3.4.7. InnoDB 테이블 스페이스 다이어로그

2.3. 윈도우에 MySQL설치 하기 어떤 사용자는 InnoDB 테이블 스페이스 파일을 MySQL서버 디렉토리가 아닌 다른 곳에 놓고 싶어할 수도 있다. 테이블
2.3.4 구성(Cinfiguration) 마법사 사용 하기 스페이스 파일을 별도의 위치에 놓는 것은, 시스템이 고부하 이거나 또는 고성능 스토리지 장치, 예를 들면 RAID스토리
2.3.4.1 구성 마법사 소개 지 시스템일 경우에 바람직하다.

InnoDB 테이블 스페이스 파일의 디폴트 위치를 변경하기 위해서는, 드라이브를 표시하는 문자에서 새로운 드라이브를
선택하고 경로 리스트에서 새로운 경로를 선택하면 된다. 커스텀 경로를 선택하기 위해서는, ... 버튼을 누른다.
현재의 서버 구성을 수정하고자 한다면, 경로를 변경하기 전에 수정(Modify)버튼을 먼저 누른다. 이 경우, 여러분은 서버
2.3.4.6 데이터 베이스 사용량 다이어로그 를 구동하기 전에 반드시 먼저 현재의 테이블 스페이스 파일을 새로운 위치로 수동으로 옮겨 놓아야 한다.
:::MySQL Korea:::
제목검색
2.3.4.8. 동시 접속 다이어로그
2.3. 윈도우에 MySQL설치 하기 서버 자원이 고갈되는 상황을 피하기 위해서는, MySQL에 동시에 접속하는 숫자를 제한하는 것이 중요하다. 동시 접속
2.3.4 구성(Cinfiguration) 마법사 사용 하기 다이어로그는 여러분이 서버의 예상 사용량을 선택할 수 있게 하며, 이에 따른 동시 접속의 한계를 설정할 수 있게 한다.
2.3.4.1 구성 마법사 소개 또한, 동시 접속 한계는 수동으로도 설정할 수 있다.

● Decision Support (DSS)/OLAP: 서버에 많은 수의 동시 접속이 요구되지 않는 경우에 이 옵션을 선택한다. 최
대 접속 수는 100을 설정하고, 평균 동시 접속은 20으로 가정한다.
● Online Transaction Processing (OLTP): 서버가 많은 수의 동시 접속을 필요로 하는 경우에 선택한다. 최대 접
속 수는 500으로 설정한다.
● Manual Setting: 서버에 최대 동시 접속 수를 수동으로 설정할 때 선택한다. 제공되는 드롭 다운 박스에서 동시
접속 숫자를 선택하거나, 또는 원하는 숫자가 박스에 없으면 최대 접속 숫자를 그 안에 입력하면 된다.
:::MySQL Korea:::
제목검색
2.3.4.9. 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그

2.3. 윈도우에 MySQL설치 하기 네트워킹 옵션 다이어로그는 TCP/IP네트워킹을 활성화 또는 비활성화 시킬 수 있으며 MySQL서버에 접속하는데 사용
2.3.4 구성(Cinfiguration) 마법사 사용 하기 하는 포트의 숫자를 구성하는데 사용할 수 있다.
TCP/IP 네트워킹은 디폴트로 활성화된다. TCP/IP 네트워킹은 비활성화 시키기 위해서는, uncheck the box next to
the Enable TCP/IP 네트워킹 옵션 활성화 박스를 해제시키면 된다.
Port 3306은 디폴트로 사용된다. MySQL을 접속하는데 사용되는 포트를 변경하기 위해서는, 드롭 다운 박스에서 새 포
트 번호를 선택하거나 또는 드롭 박스에 직접 새 포트 번호를 입력하면 된다. 여러분이 선택한 포트 번호가 사용 중 이라
2.3.4.6 데이터 베이스 사용량 다이어로그 면, 포트 번호를 확인하라는 프롬프트가 생긴다.
2.3.4.8 동시 접속 다이어로그 서버 SQL모드를 스트릭트(strict) 모드로 활성화 또는 비활성 시킨다. 스트릭트(strict) 모드 활성화(디폴트)는 MySQL
2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그 을 다른 데이터 베이스 관리 시스템보다 더욱 돋보이게 한다. 만약에 여러분이 어플리케이션을 MySQL의 이전 버전의
2.3.4.10 문자 셋 다이어로그 “이해할 수 있는(forgiving)” 상황에서 구동한다면, 그 어플리케이션을 수정하든지 아니면 스트릭트(strict) 모드를 비
2.3.4.11 서비스 옵션 다이어로그 활성화 시켜라. 스트릭트(strict) 모드에 대한 보다 자세한 정보는, Section 5.2.5, “서버 SQL 모드”를 참조 하기 바
2.3.4.12 보안 옵션 다이어로그 람.
:::MySQL Korea:::
제목검색
2.3.4.10. 문자 셋 다이어로그
2.3. 윈도우에 MySQL설치 하기 MySQL서버는 다중 문자 셋을 지원하며 모든 테이블, 컬럼, 및 데이터 베이스에 중복 사용 하지 않는 한 디폴트 문자 셋
2.3.4 구성(Cinfiguration) 마법사 사용 하기 이 적용 되도록 설정하는 것이 가능하다. 문자 셋 다이어로그를 사용해서 MySQL서버의 디폴트 문자 셋을 변경할 수 있
2.3.4.1 구성 마법사 소개 다.

● Standard Character Set: latin1을 서버의 디폴트 문자 셋으로 사용할 경우 선택할 수 있는 옵션이다. latin1는
영어 및 많은 서 유럽 언어에서 사용된다.
● Best Support For Multilingualism: utf8 를 디폴트 서버 문자 셋으로 선택할 때 사용되는 옵션이다. 이것은 유
니 코드 문자 셋으로 다른 많은 언어에서 저장할 수 있는 것이다.
● Manual Selected Default Character Set / Collation: 서버의 디폴트 문자 셋을 수동으로 선택할 때 사용하는
옵션이다. 제공되는 드롭 다운 리스트에서 원하는 문자를 선택한다.
:::MySQL Korea:::
제목검색
2.3.4.11. 서비스 옵션 다이어로그

2.3. 윈도우에 MySQL설치 하기 윈도우 NT기반 플랫폼에서, MySQL서버는 윈도우 서비스로서 설치될 수 있다. 이렇게 설치할 경우, MySQL서버는 시스
2.3.4 구성(Cinfiguration) 마법사 사용 하기 템이 시작(startup)되는 동안 자동으로 설치를 시작할 수 있게 되며, 윈도우의 서비스가 실패할 경우에도 자동으로 재 구
2.3.4.1 구성 마법사 소개 동 된다.

MySQL 구성 마법사는 MySQL이라는 서비스 이름을 사용해서, MySQL서버를 디폴트 서비스의 형태로 설치한다. 서비
스를 설치하고 싶지 않다면, 윈도우 서비스 옵션 설치 박스를 해제하면 된다. 여러분은 드롭 박스에서 새로운 이름을 가져
와서 서비스 이름을 변경할 수 있거나, 또는 이름을 직접 입력할 수도 있다.
2.3.4.6 데이터 베이스 사용량 다이어로그 MySQl서비스를 서비스 형태로 설치는 하지만, 윈도우 구동시 자동으로 시작지는 않도록 하기 위해서는, MySQL서버 자
2.3.4.7 InnoDB 테이블 스페이스 다이어로그 동 실행 옵션을 해제하면 된다.
:::MySQL Korea:::
제목검색
2.3.4.12. 보안 옵션 다이어로그
2.3. 윈도우에 MySQL설치 하기 MySQL서버에 대해 root 패스워드를 설정할 것을 강력하게 권장하며, 또한 MySQL구성 마법사는 이것을 디폴트로 요구
2.3.4 구성(Cinfiguration) 마법사 사용 하기 한다. 만일 루트 패스워드를 설정하고 싶지 않을 경우에는, 보안 설정 옵션 수정 박스를 해제하면 된다.
루트 패스 워드를 설정하기 위해서는, 새로운 루트 패스 워드 및 확인 박스안에 원하는 패스 워드를 입력하시면 된다. 만
일 현재의 서버를 재 구성할 경우에는, 현재의 루트 패스 워드를 패스 워드 입력 박스에 입력하면 된다.
네트워크를 통해 루트로 로그인 하는 것을 막기 위해서는, 로컬호스트 옵션를 통해서만 루트에 접속하는 박스를 설정하
면 된다. 이를 통해 여러분의 루트 계정은 보다 안전을 확보하게 된다.
2.3.4.7 InnoDB 테이블 스페이스 다이어로그 익명의 사용자 계정을 생성하기 위해서는, 익명 사용자 계정 옵션 생성 박스를 설정하면 된다. 익명 계정 생성은 서버의
2.3.4.8 동시 접속 다이어로그 보안성을 약화 시키며 로그인 및 승인상의 문제를 일으키게 된다. 이러한 이유로, 이에 대해서는 권장하지 않는다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.4.13. 확인 다이어로그
2. MySQL 설치 및 업그레이드 하기 MySQL 구성 마법사의 마지막 다이어로그는 확인 다이어로그이다. 서버 구성을 진행하기 위해서, Execute
2.3. 윈도우에 MySQL설치 하기 버튼을 누른다. 이전의 다이어로그로 복귀하기 위해서는, Back 버튼을 누른다. 서버를 구성하지 않고 구성 마
2.3.4 구성(Cinfiguration) 마법사 사용 하기 법사를 빠져 나오기 위해서는, Cancel 버튼을 누른다.
Execute 버튼을 누르면, MySQL 구성 마법사는 화면에 진행되는 프로세스의 상태를 보여주면서 서버 구성
을 진행한다.
2.3.4.4 구성 타입 선택 하기 MySQL 구성 마법사는 우선 MySQL AB사의 개발자 및 엔지니어가 제공하는 템플릿을 사용해서 여러분이
2.3.4.5 서버 타입 다이어로그 선택한 구성 파일 옵션을 검사한다. 이 템플릿은 my-template.ini 이며 서버 설치 디렉토리에 위치한다.
2.3.4.7 InnoDB 테이블 스페이스 다이어로그 그 다음에, MySQL구성 마법사는 여러분의 옵션을 my.ini 파일에 쓰기 시작한다. my.ini 파일의 최종 위치
2.3.4.8 동시 접속 다이어로그 는 구성 파일 테스크 쓰기창의 옆에 표시된다.

MySQL서버를 위한 서비스를 생성하도록 선택하면, MySQL구성 마법사는 이 서비스를 생성하고 시작을 하
게 한다. 이미 존재하는 서비스를 재 구성할 경우에는, MySQL 구성 마법사는 이 서비스를 여러분이 선택한
구성에 맞도록 재 구동시킨다.
2.3.4.13 확인 다이어로그 루트 패스워드를 설정한 경우에는, MySQL구성 마법사는 서버에 접속하고, 새로운 패스워드를 설정하고 여
2.3.4.14 my.ini 파일의 위치 러분이 선택한 기타의 보안 설정에 이를 적용시킨다..
MySQL구성 마법사가 해당 업무를 마치게 되면, 진행 내역을 요약해서 화면에 보여준다. Finish 버튼을 눌
러서 MySQL구성 마법사를 종료한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.4.14. my.ini 파일의 위치
2. MySQL 설치 및 업그레이드 하기 MySQL 구성 마법사는 MySQL서버용 설치 디렉토리에 my.ini 을 저장한다. 이것을 가지고 특정 서버 인스
2.3. 윈도우에 MySQL설치 하기 턴스에 관련된 구성 파일을 지원하다.
MySQL서버가 my.ini 파일이 있는 위치를 정확히 알고 있는지 확인하기 위해서는, 이와 비슷한 인수가 서비
스 설치의 항목으로 MySQL에 전달된다: --defaults-file="C:￦Program Files￦MySQL￦MySQL
Server 5.0￦my.ini". 여기에서, C:￦Program Files￦MySQL￦MySQL Server 5.0 은 MySQL서버에 대
한 설치 경로로 변경된다.
2.3.4.5 서버 타입 다이어로그 --defaults-file 옵션은 MySQL서버가 구동될 때 구성 옵션에 대한 지정된 파일을 읽도록 지시한다.
:::MySQL Korea:::
제목검색
2.3.4.15. my.ini 파일 편집 하기
2.3. 윈도우에 MySQL설치 하기 my.ini 파일을 수정하기 위해서는, 텍스트 편집기를 사용해서 이것을 열고 필요한 변경을 한다. 여러분은 또한 MySQL
2.3.4 구성(Cinfiguration) 마법사 사용 하기 Administrator 유틸리티를 사용해서 서버의 구성을 수정할 수도 있다.
mysql 및 mysqldump 명령어 라인 클라이언트와 같은 MySQL클라이언트 및 유틸리티는 서버 설치 디렉토리에 있는
my.ini 파일을 수정할 수 없다. 클라이언트 및 유틸리티를 구성하기 위해서는, C:￦WINDOWS or C:￦WINNT 디렉토
리(윈도우 버전에 따라 다를 수 있음)에 새로운 my.ini 파일을 생성한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.5. 노인스톨(Noinstall) 집(Zip) 아카이브로 부터 MySQL 설치 하기
2.3. 윈도우에 MySQL설치 하기 Noinstall 패키지를 가지고 설치를 하는 사용자는, 이 섹션에서 설명하는 방법을 가지고 수동으로 MySQL을
2.3.5 노인스톨(Noinstall) 집(Zip) 아카이브로 부터 MySQL 설치 하기 설치할 수 있다. 집 아카이브를 가지고 설치하는 과정은 아래와 같다:
1. 아카이브를 원하는 설치 디렉토리에 푼다.

2. 옵션 파일을 생성한다.
3. MySQL서버 타입을 선택한다.
4. MySQL서버를 구동한다.
5. 디폴트 사용자 계정을 안전하게 한다.
이 과정에 대한 설명은 이후의 섹션에서 설명하기로 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.6. 설치 아카이브 풀기
2.3. 윈도우에 MySQL설치 하기 MySQL을 수동으로 설치하기 위해서는, 아래의 순서를 따라 한다:
1. 이전 버전에서 업그레이드를 한다면, 업그레이드를 시작하기 전에 Section 2.3.14, “윈도우에서MySQL 업그레이
드 하기”를 먼저 참조하기 바란다.
2. 윈도우 NT, 2000, XP 또는 윈도우 서버2003과 같은 NT기반 OS를 사용한다면, 관리자 권한이 있는 사용자로 로그
인 하여야 한다.
3. 설치 위치를 선택한다. 전통적으로는, MySQL서버는 C:￦mysql에 설치 된다. MySQL 설치 마법사는 MySQL을 C:
￦Program Files￦MySQL에 설치한다. 만약에 여러분이C:￦mysql에 설치하지 않는다면, 구동 시점 또는 옵션 파일에
서 설치 디렉토리의 경로를 지정해야 한다. Section 2.3.7, “옵션 파일 생성하기”를 참조.
4. Zip 아카이브 툴을 사용해서 원하는 위치에 아카이브를 푼다. 어떤 툴들은 여러분이 선택한 설치 위치 안에 있는 폴
더에 아카이브를 풀기도 한다. 이렇게 풀릴 경우에는, 서브 폴더의 내용물을 여러분이 선택한 설치 위치로 이동시키면 된
다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.7. 옵션 파일 생성하기
2. MySQL 설치 및 업그레이드 하기 여러분이 서버를 구동할 때 스타트업 옵션을 지정하고자 한다면, 명령어 라인에서 옵션들을 나타내거나 또는 옵션 파
2.3. 윈도우에 MySQL설치 하기 일에 표시해 두면 된다. 서버가 실행될 때마다 옵션이 실행되도록 하기 위해서는, MySQL구성을 지정하는 옵션 파일
2.3.7 옵션 파일 생성하기 을 사용하는 것이 가장 효과적인 방법이다. 이것은 아래와 같은 환경에서 특히 효과적이다:
● 설치 및 데이터 디렉토리의 위치가 디폴트 위치와 다른 경우 (C:￦Program Files￦MySQL￦MySQL

Server 5.0 및 C:￦Program Files￦MySQL￦MySQL Server 5.0￦data).
● 서버 설정을 개선할 필요가 있는 경우.
MySQL서버는 윈도우에서 시작할 때, 두 가지 파일안에 있는 옵션들을 찾는다: 윈도우 디렉토리에 있는 my.ini 파일,
및 C:￦my.cnf 파일. 전형적으로 윈도우 디렉토리는 C:￦WINDOWS 또는 C:￦WINNT와 유사한 이름을 갖고 있다.
여러분은 아래의 명령어를 사용해서 WINDIR 환경 변수로부터 정확한 위치를 알아볼 수 있다:
C:￦> echo %WINDIR%
MySQL은 my.ini 파일에 있는 첫 번째 옵션을 찾는다. 하지만, 혼란을 피하기 위해서는, 여러분은 한가지 파일만 사용
하는 것이 최선이다. 여러분 PC가 C:의 부팅 드라이브가 아닌 부팅 로더를 사용한다면, 여러분이 선택할 옵션은 단지
my.ini 파일을 사용하는 것이다. 어떤 옵션 파일을 선택하든지, 이 파일은 텍스트 파일이어야 한다.
여러분은 또한 MySQL배포판에 포함되어 있는 예제용 옵션 파일을 사용할 수도 있다. Look in your install
directory for files such as my-small.cnf, my-medium.cnf, my-large.cnf, 및 my-huge.cnf와 같은 파일용 설
치 디렉토리를 검토해 보면, 기본 구성 파일용으로 사용할 수 있는 적당한 위치를 찾아서 재명명하거나 복사할 수 있
다.
노트 패드와 같은 어떠한 텍스트 편집기를 사용해서도 옵션 파일을 생성 및 수정할 수 있다. 예를 들면, 만약 MySQL
이 E:￦mysql 에 설치되고데이터 디렉토리가 E:￦mydata￦data에 있다면, 여러분은 basedir 및 datadir 파라미터

:::MySQL Korea:::
를 위한 값을 지정하기 위한 [mysqld] 섹션을 갖는 옵션을 생성할 수 있다:
[mysqld]
# set basedir to your installation path
basedir=E:/mysql
# set datadir to the location of your data directory
datadir=E:/mydata/data
윈도우 경로는 백슬레쉬가 아닌 슬레쉬를 사용해서 옵션 파일에서 지정된다는 점을 유의한다. 백슬레쉬를 사용할 경
우에는, 이것을 두번 반복 사용해야 한다:
[mysqld]
basedir=E:￦￦mysql
datadir=E:￦￦mydata￦￦data
윈도우에서, MySQL 설치기는 데이터 디렉토리를 여러분이 MySQL을 설치하는 디렉토리 아래에 직접 위치 시킨다.
만약에 다른 위치에 데이터 디렉토리를 위치하고자 한다면, 데이터 디렉토리에 있는 모든 내용물을 복사해서 새로운
위치로 옮겨 놓아야 한다. 예를 들면, 만약에 MySQL이 C:￦Program Files￦MySQL￦MySQL Server 5.0에 설치
되었다면, 데이터 디렉토리는 디폴트로 C:￦Program Files￦MySQL￦MySQL Server 5.0￦data에 있게 된다. 만
약에 E:￦mydata 를 대신 데이터 디렉토리로 사용하고자 한다면, 두 가지의 일을 해야 한다:
1. C:￦Program Files￦MySQL￦MySQL Server 5.0￦data 에 있는 전체 디렉토리 및 모든 내용물을 E:

￦mydata로 옮긴다.

:::MySQL Korea:::
2. 여러분이 서버를 매번 실행할 때마다 --datadir 옵션을 사용해서 새로운 디렉토리의 위치를 지정한다.

:::MySQL Korea:::
제목검색
2.3.8. MySQL 서버 타입 선택하기

2.3. 윈도우에 MySQL설치 하기 아래의 테이블은 MySQL5.0에서 윈도우가 사용할 수 있는 서버들을 보여준다:
2.3.8 MySQL 서버 타입 선택하기

바이너리 상세 설명
mysqld-debug InnoDB 및 BDB 테이블 뿐만 아니라, 자동 메모리 설정 검사 및 전체 디버깅까지 컴파일 함.
Mysqld InnoDB 지원을 갖는 최적화된 바이너리.
mysqld-nt 네임드 파이프에 대한 지원 기능이 있는 윈도우 NT, 2000, 및 XP를 위한 최적화된 바이너리.
mysqld-max InnoDB 및 BDB 테이블을 지원하는 최적화된 바이너리.
Mysqld-max-nt mysqld-max과 비슷하지만, 네임드 파이프를 지원하기 위해 컴파일 됨.
이전의 모든 바이너리는 현재의 인텔 프로세서를 위해 최적화 되어 있으나, 인텔의 i386-class 또는 보다 고성능의 프로세서에서
동작되어야 한다.
모든 윈도우MySQL 5.0 서버는 데이터 베이스 디렉토리의 심볼릭 링크를 지원하고 있다.
MySQL은 모든 윈도우 플랫폼의 TCP/IP를 지원한다. mysqld-nt 및 mysql-max-nt 서버는 윈도우 NT, 2000, XP, 및 2003상
의 네임드 파이프를 지원한다. 하지만, 디폴트는 플랫폼에는 상관 없이 TCP/IP를 사용하는 것이다. (네임드 파이프는 많은 윈도우
구성에서 TCP/IP보다 속도가 느리다.)
네임드 파이프의 사용은 아래의 조건에 달려 있다:
● 네임드 파이프는 여러분이 서버를 --enable-named-pipe 옵션과 함께 시작할 때에만 활성화 된다. 어떤 사용자들은 네
임드 파이프를 사용할 때 MySQL서버가 셧 다운되는 경험을 하였기 때문에 이 옵션을 사용하는 것은 신중하게 할 필요가

:::MySQL Korea:::
있다.
● 네임드 파이프 연결은 mysqld-nt 또는 mysqld-max-nt 서버에 의해서만 가능하며, 또한 서버가 네임드 파이프를 지원
하는 윈도우 버전(NT, 2000, XP, 2003)에서 구동될 때에만 사용 가능하다.
● 이러한 서버들은 TCP/IP가 설치된 경우에만 윈도우 98 또는 Me에서 구동 되어 진다.
● 이러한 서버들은 윈도우95에서는 구동되지 않는다.
Note: 이 매뉴얼에 있는 대부분의 예제들은 mysqld 을 서버의 이름으로 사용한다. 만약에 다른 서버를 사용하고자 한다면, 예를 들
면mysqld-nt와 같이, 예제에서 보여 주는 것 같은 명령어에서 적당히 대신할 이름을 사용한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.9. 처음으로 서버를 시작 하기
2.3. 윈도우에 MySQL설치 하기 이 섹션에서는 MySQL서버를 시작하는 것에 대해 일반적인 내용을 설명하기로 한다. 이후의 섹션에서는 명령어 라인 또는 윈도우
2.3.9 처음으로 서버를 시작 하기 서비스로서 MySQL을 시작하기 위한 방법에 대해 보다 자세한 정보를 보여 주기로 한다.
여기에서는 여러분이 노인스톨 버전을 사용해서 설치할 경우, 또는 GUI툴을 사용하지 않고 수동으로 MySQL을 구성하고 테스트
할 경우를 먼저 다루기로 한다.
이 섹션에 있는 예제들은 MySQL이 C:￦Program Files￦MySQL￦MySQL Server 5.0의 디폴트 위치에 설치되어 있다는 가정
을 한다. 여러분이 MySQL을 다른 곳에 설치 하였다면 예제에서 보여주는 경로 이름을 조정 하기 바란다.
윈도우 NT, 2000, XP, or 2003와 같은 NT기반 OS상에서는, 클라이언트는 두 가지 옵션을 갖는다. 이 OS들은 TCP/IP를 사용
하거나, 또는 서버가 네임드 파이프 연결을 지원할 경우 네임드 파이프를 사용한다. 윈도우 NT 4에서 TCP/IP를 함께 사용하게 한
다면, 여러분은 서비스 팩3(또는 이후 버전)을 설치 하여야 한다.
윈도우 95, 98, 또는Me에서는, MySQL클라이언트는 항상 TCP/IP를 사용해서 서버에 접속한다. (이것은 네트워크상에 있는 모
든 장비가 여러분의 MySQL서버에 접속이 가능하게 한다.) 이러한 이유 때문에, 여러분은 MySQL을 시작하기 전에 여러분 시스템
상에 TCP/IP가 지원되도록 해야 한다. 여러분의 윈도우 CD에서 TCP/IP를 찾을 수 있을 것이다.
여러분이 지금 구형 윈도우 95 릴리즈(예를 들면, OSR2)를 사용하고 있다면, 구형 윈속(Winsock)패키지를 가지고 있는 것과 같

다; MySQL은 윈속2를 필요로 한다. 최신의 윈속은 http://www.microsoft.com/에서 얻을 수 있다. 윈도우98은 새로운 윈속2 라
이브러리를 갖고 있기 때문에 이 라이브러리를 업데이틀 할 필요는 없다.
윈도우용 MySQL은 또한 --shared-memory 옵션으로 시작될 경우에는 공유 메모리(shared-memory)연결을 지원한다. 클라

이언트는 --protocol=memory 옵션을 사용해서 공유 메모리에 연결할 수 있다.

:::MySQL Korea:::
구동 시킬 수 있는 서버 메모리에 대해서는 Section 2.3.8, “MySQL 서버 타입 선택하기”를 참조하기 바란다.
테스트는 콘솔 윈도우(또는 “도스 윈도우’)에 있는 명령어 프롬프트로 하는 것이 제일 좋다. 이 방법으로 여러분은 윈도우에 서
버가 상태 메시지를 나타내도록 할 수 있다. 여러분의 구성에 어떤 문제가 있다면, 이 메시지를 통해 여러분은 보다 쉽게 문제를 알
수 있게 되며 문제를 수정할 수 있게 된다.
서버를 구동 시키기 위해서는, 아래의 명령어를 입력한다:
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqld" --console
InnoDB 를 지원하는 서버에 대해서는, 서버가 실행될 때 아래의 메시지를 볼 수 있을 것이다:
InnoDB: The first specified datafile c:￦ibdata￦ibdata1 did not exist:
InnoDB: a new database to be created!
InnoDB: Setting file c:￦ibdata￦ibdata1 size to 209715200
InnoDB: Database physically writes the file full: wait...
InnoDB: Log file c:￦iblogs￦ib_logfile0 did not exist: new to be created
InnoDB: Setting log file c:￦iblogs￦ib_logfile0 size to 31457280

:::MySQL Korea:::
InnoDB: Doublewrite buffer not found: creating new
InnoDB: Doublewrite buffer created
InnoDB: creating foreign key constraint system tables
InnoDB: foreign key constraint system tables created
011024 10:58:25 InnoDB: Started
서버가 시동 절차를 마치게 되면, 여러분은 이것과 비슷한 것을 보게 되는데, 이것들은 서버가 지금 클라이언트와 연결될 준비가 되
어 있음을 나타내는 것이다:
mysqld: ready for connections
Version: '5.0.19' socket: '' port: 3306
서버는 계속해서 진행되는 진단 결과를 화면에 보여 준다. 여러분은 새로운 윈도우를 열어서 클라이언트 프로그램을 구동시킬 수
있다.
만약에 여러분이 --console 옵션을 생략하면, 서버는 데이터 디렉토리에 에 있는 에러 로그에 진단 결과를 쓰게 된다(C:
￦Program Files￦MySQL￦MySQL Server 5.0￦data, 디폴트의 경우). 에러 로그는 .err 확장자가 있는 파일이다.
Note: MySQL그랜트 테이블에 있는 계정들은 초기에는 패스워드가 없다. 서버를 구동한 후에, 여러분은 이 계정들에 대한 패스워
드를 설정하야 한다. Section 2.9, “설치후 설정 및 테스트”를 참조할 것.

:::MySQL Korea:::
제목검색
2.3.10. 윈도우 명령어 라인으로 MySQL 시작하기

2.3. 윈도우에 MySQL설치 하기 MySQL서버는 명령어 라인에서 수동으로 시작할 수 있다. 이것은 모든 윈도우 버전에서 가능하다.
2.3.10 윈도우 명령어 라인으로 MySQL 시작하기

명령어 라인에서mysqld 서버를 시작하기 위해서는, 콘솔 윈도우(또는 도스 윈도우)를 시작하고 아래의 명령어를 입력한다:
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqld"
이 예제에서 사용한 경로는 여러분의 설치 위치에 따라 변할 수 있다.
NT기반 윈도우가 아닌 경우에는, OS는 백그라운드에서 mysqld 를 고동 시킨다. 즉, 서버가 구동된 후, 여러분은 또 다른 명령어
프롬프트를 보게 된다. 만약에 이러한 방식으로 윈도우 NT, 2000, XP, 또는 2003에서 서버를 시작하면, 서버는 전면
(foreground)에서 실행되고 서버를 종료하지 않으면 어떤 명령어 프롬프트로 나타나지 않는다. 이러한 이유로 인해, 여러분은 서
버가 구동되는 동안 또 다른 윈도우를 열고 여기에서 클라이언트 프로그램을 구동 시켜야 한다.
아래의 명령어로 실행중인 MySQL 서버를 종료할 수 있다:
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqladmin" -u root shutdown
Note: MySQL root 사용자 계정이 패스워드가 있다면, 여러분은 mysqladmin 을 -p 옵션과 함께 호출하고 프롬프트가 나오면 패
스워드를 입력한다.
이 명령어는 MySQL 관리자 유틸리티인 mysqladmin 를 호출해서 서버에 연결하고 셧 다운을 하게끔 한다. 이 명령은, MySQL그
랜트 테이블에 있는 디폴트 관리자 계정인, MySQL root 사용자로서 실행된다. MySQL그랜트 테이블에 있는 사용자는 전적으로
윈도우에 있는 로그인 사용자와는 독립적으로 운영된다는 것을 알아 두기 바란다.

:::MySQL Korea:::
만약에 mysqld 이 실행되지 않으면, 에러 로그를 분석해서 문제의 원인이 무엇인지를 파악한다. 에러 로그는 C:￦Program Files
￦MySQL￦MySQL Server 5.0￦data 디렉토리에 있다. 이것은 접미어 .err를 갖고 있는 파일이다. 여러분은 또한 서버를
mysqld –console로 시작할 수 있다; 이 경우, 여러분은 문제를 해결하는데 도움이 되는 여러 유용한 정보를 얻을 수 있을 것이
다.
마지막 옵션은 –standalone 및 --debug 옵션을 가지고 mysqld를 실행하는 것이다. 이 경우, mysqld은 mysqld 이 구동되지 않
으면 그 이유를 저장하는 로그 파일 C:￦mysqld.trace 을 작성한다. Section E.1.2, “Trace Files 생성”을 참조 할 것.
mysqld 에서 쓸 수 있는 모든 옵션을 보기 위해서는 mysqld --verbose –help를 사용한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.11. 윈도우 서비스의 형태로 MySQL 시작 하기
2.3. 윈도우에 MySQL설치 하기 NT 계열(Windows NT, 2000, XP, 2003)의 OS의 경우, MySQL을 실행하는 권장 방법은 MySQL을 윈도우 서비스의 형태로 설
2.3.11 윈도우 서비스의 형태로 MySQL 시작 하기 치하는 것이며, 이렇게 함으로서 윈도우가 시작되고 종료될 때 자동으로 MySQL도 구동되고 종료하게 된다. 서비스의 형태로 설치
된 MySQL서버는 NET명령어를 사용해서 명령어 라인에서 제어할 수 있으며, 또는 그래픽 서비스 유틸리티를 사용할 수도 있다.
서비스 유틸리티(윈도우 서비스 컨트롤 메니저(Service Control Manager) )는 윈도우 제어 판넬에서 찾을 수 있다(윈도우 200,
XP, 및 서버 2003에는 관리자 툴 밑에 있음). 충돌을 피하기 위해, 명령어 라인에서 서버 설치 또는 제거를 실행하는 동안에는 서
비스 유틸리티를 닫아 두기를 권장한다.
윈도우 서비스 형태로 MySQL을 설치하기 전에, 우선 만일 서버가 실행되고 있다면 아래의 명령어로 우선 현재의 서버를 중지 시
켜야 한다:
Note: 만약에 MySQL root 사용자 계정이 패스워드가 있다면, -p옵션을 가지고 mysqladmin 를 호출한 다음 패스워드를 입력하
면 된다.
이 명령어는 MySQL 관리자 유틸리티인 mysqladmin 를 호출해서 서버에 연결하고 셧 다운을 하게끔 한다. 이 명령은, MySQL그
랜트 테이블에 있는 디폴트 관리자 계정인, MySQL root 사용자로서 실행된다. MySQL그랜트 테이블에 있는 사용자는 전적으로
윈도우에 있는 로그인 사용자와는 독립적으로 운영된다는 것을 알아 두기 바란다.
다음의 명령어를 사용해서 MySQL서버를 서비스의 형태로 설치한다:
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqld" --install

:::MySQL Korea:::
서비스-설치 명령어는 서버를 구동시키지는 않는다. 이에 대한 지침서는 이 섹션 후반부에서 설명하기로 한다.
MySQL 프로그램을 보다 쉽게 호출하기 위해서, MySQL bin 디렉토리의 경로 이름을 윈도우 시스템 PATH 환경 변수에 추가할
수 있다:
● 윈도우 데스크 탑에서, 내 컴퓨터 아이콘 위에서 오른쪽 마우스를 클릭한 다음, 속성(Properties)을 선택한다.
● 다음에 시스템 속성에서 고급 탭을 선택한 후, Environment Variables 버튼을 누른다.
● 시스템 변수에서, 경로를 선택한 다음, Edit 버튼을 누른다. 시스템 변수 편집 다이어로그가 나오게 된다.
● 변수 값이 있는 텍스트 끝에 커서를 오게 한다. (End 를 사용해서 커서가 텍스트의 맨 마지막에 가게 하도록 한다.) 그 다
음, MySQL bin 디렉토리의 전체 경로 이름을 입력한다(예를 들면, C:￦Program Files￦MySQL￦MySQL Server 5.0
￦bin). 여기에는 이 필드에 있는 값들과 경로를 구분하는 세미콜론(semicolon)이 있다는 것을 유의한다. 이 다이어로그
를 닫고, 모든 열려 있는 다이어로그 창이 닫힐 때까지 OK 버튼을 누른다. 이제 여러분은 도스 프롬프트에서, 경로를 별도
로 지정하지 않고서도, 시스템에 있는 실행 가능한 모든 MySQL 프로그램을 호출할 수 있게 된다. 여기에는 서버, mysql
클라이언트, 그리고 mysqladmin 및 mysqldump과 같은 모든 MySQL명령어-라인 유틸리티도 포함된다.
여러 개의 MySQL 서버를 동일한 시스템에서 구동하고 있다면, 여러분은 MySQL bin 디렉토리를 윈도우 PATH 에 추가
할 수 없다.
Warning: 시스템 PATH를 수동으로 편집할 때에는 각별한 주의를 해야 한다; 현재의 PATH값 중에 일부분이라도 부주의로 삭제
또는 수정을 할 경우에는 전체 시스템이 오 작동을 하거나 또는 시스템을 사용할 수 없게 될 수도 있다.
MySQL 5.0을 서비스로 설치할 때 사용할 수 있는 부가적인 내용을 아래에 표시 한다:
● 여러분은 --install 옵션이 붙는 서비스 이름을 지정할 수 있다. 디폴트 서비스 이름은 MySQL이다.
● 서비스 이름이 주어지면, 단일 옵션을 붙일 수 있다. 편의를 위해, 이것은 --defaults-file=file_name 가 되고 서버가 구
동될 때 읽게 되는 옵션에서 옵션 파일의 이름을 지정하게 한다.
--defaults-file가 아닌 다른단일 옵션을 사용하는 것도 가능하지만, 이것은 추천하지 않는다. --defaults-file 이 더

욱 편리한 방법인데, 왜냐하면 이것은 옵션들을 네임드 옵션 파일에 저장함으로서 서버에 대한 다중 시작 옵션을 지정할
수 있게 해 주기 때문이다. 또한, MySQL 5.0에서는, --defaults-file 이외의 옵션은 5.0.3 이전에는 지원하지 않는다.
● MySQL 5.0.1 버전 까지는, 서비스 이름 다음에 --local-service 옵션을 지정할 수 있다. 이것은 서버가 제한적인 시스

:::MySQL Korea:::
템 권한을 갖고 있는 LocalService 윈도우 계정을 사용해서 구동되도록 한다. 이 계정은 윈도우XP 또는 그 후의 버전에서
만 사용 가능하다. --defaults-file 및 --local-service 는 모두 서비스 이름 다음에 사용되며, 어떤 순서로도 사용 가능
하다.
윈도우 서비스의 형태로 설치되는 MySQL서버의 경우, 다음의 규정이 서버가 사용하는 서비스의 이름 및 옵션 파일을 결정한다:
● 만약 서비스-설치 명령어가 --install 옵션 다음에 어떠한 서비스 이름이나 디폴트 서비스 이름(MySQL)을 지정하지 않
는다면, 서버는 MySQL 서비스 이름과 표준 옵션 파일에 있는 [mysqld] 그룹에서 읽기 옵션을 가져와서 사용하게 된다.
● 만약에 MySQL 대신에 특정 서비스 이름을 --install 과 함께 사용하면, 서버는 지정한 서비스 이름을 사용한다. 서버는
동일한 이름을 갖고 있는 그룹에서 서비스 형태로 옵션을 읽어 오고, 표준 옵션 파일에서 옵션을 읽어온다.
서버는 또한 표준 옵션 파일에서 [mysqld] 으로 부터 옵션을 읽어온다. 이것은 여러분이 모든 MySQL서비스가 사용하는

옵션에 대해 [mysqld] 그룹과, 그리고 그 서비스 이름을 갖고 설치된 서버에 의해 사용되는 서비스의 형태로 동일한 이름
을 갖는 옵션 그룹을 사용할 수 있게 해 준다.
● 만약에 서비스-설치 명령어가 서비스 이름 다음에 --defaults-file 옵션을 지정한다면, 서버는 네임드 파일의
[mysqld] 그룹에서만 옵션을 읽어오고 표준 옵션 파일을 무시한다.
보다 복잡한 예제를 본다면, 다음의 명령어를 가정하자:
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqld"
--install MySQL --defaults-file=C:￦my-opts.cnf
여기에서 보면, 디폴트 서비스 이름(MySQL)이 --install 다음에 나온다. 만약에 아무런 --defaults-file 이 주어지지 않는다
면, 이 명령어는 서버가 표준 옵션 파일에서 [mysqld] 그룹을 읽도록 한다. 하지만, --defaults-file 옵션이 존재하기 때문에, 서
버는 [mysqld] 옵션 그룹과 네임드 파일에서만 옵션을 읽어 온다.
여러분은 또한 MySQL을 구동하기 전에 윈도우 서비스 유틸리티에 시작(Start) 파라미터로 옵션을 지정할 수도 있다.
MySQL서버가 서비스 형태로 설치되면, 윈도우는 윈도우가 시작될 때마다 서비스를 자동으로 실행한다. 이 서비스는 또한 서비스

:::MySQL Korea:::
유틸리티, 또는 NET START MySQL 명령어를 가지고도 실행할 수 있다. NET 명령어는 대소 무자를 구분하지 않는다.
서비스로 구동될 때, mysqld 은 콘솔 윈도우를 접속하지 못하며, 따라서 아무런 메시지도 볼 수 없다. 만약에 mysqld 이 실행되지
않으면, 문제를 분석하기 위해서 에러 로그를 검사하도록 한다. 에러 로그는 MySQL데이터 디렉토리에 있다 (예를 들면, C:
￦Program Files￦MySQL￦MySQL Server 5.0￦data). 이 파일은 .err 접미사를 갖고 있다.
서비스 형태로 MySQL서버가 설치될 때, 그리고 이 서비스가 구동될 때, 윈도우가 셧 다운 되게 되면 자동으로 이 서비스도 종료된
다. 서버는 서비스 유틸리티, NET STOP MySQL 명령어, mysqladmin shutdown 명령어를 사용해서 수동으로도 종료시킬 수 있
다.
여러분은 시스템이 부팅될 때 자동으로 서비스가 실행되는 것을 원하지 않을 경우, 수동 서비스 형태로 서버에 설치할 수 있는 옵션
을 가질 수 있다. 이렇게 하기 위해서는, --install 옵션이 아닌 --install-manual 옵션을 사용한다:
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqld" --install-manual
서비스 형태로 설치된 서버를 제거하기 위해서는, 우선 서버가 구동된다면, NET STOP MYSQL를 사용해서 서버를 종료하게 한
다음, --remove 옵션을 사용해서 서버를 삭제 한다:
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqld" --remove
mysqld 이 서비스 형태로 구동되지 않는다면, 여러분은 명령어 라인에서 이것을 실행 시킬 수 있다. 이 방법에 대해서는,
Section 2.3.10, “윈도우 명령어 라인에서 MySQL 시작 하기”를 참조하기 바람.
만약에 설치하는데 어떤 문제가 있다면, Section 2.3.13, “윈도우에서의 MySQL 설치 문제 해결”를 참조하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.12. 설치된 MySQL 테스트 하기
2.3. 윈도우에 MySQL설치 하기 여러분은 아래의 명령어 중에 하나를 사용해서 MySQL 서버가 제대로 동작하는지를 검사할 수 있다:
2.3.12 설치된 MySQL 테스트 하기

C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqlshow"
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqlshow" -u root mysql
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysqladmin" version status proc
C:￦> "C:￦Program Files￦MySQL￦MySQL Server 5.0￦bin￦mysql" test
만약에 mysqld가 클라이언트 프로그램에서의 TCP/IP접속이 느리게 나타나면, 아마도 여러분의 DNS에 문제가 있는 것이다. 이
와 같은 경우, mysqld을 --skip-name-resolve 옵션과 함께 구동을 시키고 MySQL 그랜트 테이블의 Host 컬럼에 있는 IP 번
호와 localhost만을 사용하기 바란다.
여러분은 --pipe 또는 --protocol=PIPE 옵션을 지정 하거나 또는 호스트 이름으로 . (period)를 지정 함으로써 MySQL 클라
이언트가 TCP/IP가 아닌 네임드 파이프 접속을 사용하도록 만들 수가 있다. 디폴트 파이프 이름을 사용하고 싶지 않을 경우에는,
--socket 옵션을 사용한다.
여러분이 root 계정에 패스워드를 설정하였거나, 익명 사용자 계정을 삭제하였거나, 또는 새로운 계정을 생성하였다면, MySQL 서
버에 접속을 하기 위해서는 위에 있는 명령어와 함께 -u and -p 옵션을 같이 사용해야 한다. Section 5.8.4, “MySQL 서버에 접
속하기”를 참조할 것.
Mysqlshow에 대한 보다 자세한 정보는, Section 8.13, “mysqlshow — 데이터 베이스, 테이블, 그리고 컬럼 정보를 디스플레이
하기”를 참조할 것.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.13. 윈도우에서 MySQL 설치 문제 해결
2.3. 윈도우에 MySQL설치 하기 처음으로 MySQL을 설치하고 구동할 때, 여러분은 아마도 여러 가지 에러를 접하게 될 것이다. 이 섹션에서는 이러한 문제를 진단
2.3.13 윈도우에서 MySQL 설치 문제 해결 하고 에러를 해결하는 방법을 설명하기로 한다.
여러분이 에러를 바로 잡기 위해 사용할 수 있는 첫 자료는 에러 로그이다. MySQL 서버는 에러 로그를 사용해서 서버 구동에 문
제를 일으키는 관련 에러를 기록한다. 에러 로그는 여러분의 my.ini 에서 지정하는 데이터 디렉토리 안에 있다. 디폴트 디렉토리의
위치는 C:￦Program Files￦MySQL￦MySQL Server 5.0￦data이다. Section 5.12.1, “에러 로그”를 참조할 것.
가능한 에러에 관련된 또 다른 정보는 MySQL서비스 시작될 때 콘솔에서 보여지는 메시지이다. MySQL서버를 서비스의 형태로
시작하는 것과 관련된 에러 메시지를 보기 위해서는 mysqld 을 서비스의 형태로 설치한 후 NET START mysql 명령어를 사용한
다. Section 2.3.11, “윈도우 서비스 형태로 MySQL설치하기”를 참조할 것.
아래의 예제는 여러분이 처음으로 MySQL을 설치하고 구동 시킬 때 겪을 수 있는 일반적인 에러 메시지를 보여준다:
● 만약에 MySQL서버가 mysql 권한 데이터 베이스 또는 다른 크리티컬한 파일을 찾지 못한다면, 아래의 에러 메시지가 나타
난다:
• System error 1067 has occurred.
• Fatal error: Can't open privilege tables: Table 'mysql.host' doesn't exist
이러한 메시지는 MySQL의 기본 또는 데이터 디렉토리가 디폴트 디렉토리가 아닌 곳에 설치 되었을 경우에 종종 발생한
다 (C:￦Program Files￦MySQL￦MySQL Server 5.0 및 C:￦Program Files￦MySQL￦MySQL Server 5.0
￦data, 각각 해당).
이러한 경우는 MySQL이 새로운 위치에 업그레이드 또는 설치는 되지만, 구성 파일이 새로운 위치를 반영하지 않을 경우

:::MySQL Korea:::
에 발생할 수도 있다. 또한, 구형 구성 파일과 새로운 구성 파일이 서로 충돌을 일으킬 경우에도 발생한다. MySQL을 업그
레이들 할 때에는 반드시 구형 구성 파일을 삭제하거나 다른 이름으로 저장을 해 두어야 한다는 점을 유의한다.
만약에 MySQL을 C:￦Program Files￦MySQL￦MySQL Server 5.0가 아닌 다른 곳에 설치를 했다면, 여러분은
MySQL이 구성(my.ini)파일을 통해 이 위치를 인지하게끔 해야 한다. my.ini 파일은 여러분의 윈도우 디렉토리에 두어
야 하는데, 일반적으로는C:￦WINDOWS 또는 C:￦WINNT가 된다. 명령어 플롬프트에서 아래의 명령어를 입력해서
WINDIR 환경 변수의 값으로부터 정확한 위치를 알아낼 수 있다:
노트 패드와 같은 텍스트 편집기를 가지로 옵션 파일을 작성 및 수정할 수 있을 것이다. 예를 들면, MySQL이 E:￦mysql
에 설치되었고 데이터 디렉토리가 D:￦MySQLdata라면, 여러분은 옵션 파일을 생성하고 [mysqld] 섹션이 basedir 과
datadir 파라미터의 값을 지정하도록 설정할 수 있다:
[mysqld]
basedir=E:/mysql
datadir=D:/MySQLdata
윈도우 파라미터는 옵션 파일에서 백슬레쉬가 아닌 슬레쉬를 사용해서 경로를 지정한다는 점을 유의하자. 백슬레쉬를 사
용하고자 하면, 두번 연속 사용한다:
[mysqld]
basedir=C:￦￦Program Files￦￦MySQL￦￦MySQL Server 5.0

:::MySQL Korea:::
datadir=D:￦￦MySQLdata
MySQL구성 파일에 있는 datadir 의 값을 변경하고자 한다면, 여러분은 반드시 서버를 재 구동하기 전에 기존의 데이터
디렉토리에 있는 모든 내용물을 옮겨 놓아야 한다. Section 2.3.7, “옵션 파일 생성 하기”를 참조할 것.
● 기존의 MySQL서비스를 중단 및 제거하지 않고 MySQL을 재 설치 또는 업그레이드 하고 그 다음에 MySQL구성 마법사

를 사용해서 MySQL을 설치한다면, 다음과 같은 에러가 나올 수 있다:
• Error: Cannot create Windows service for MySql. Error: 0
이것은 구성 마법사가 서비스 설치를 시도하고 동일한 이름을 가진 기존의 서비스를 찾을 경우에 발생한다.
이 문제를 해결하는 한 가지 방법은 구성 마법사를 사용할 때 서비스 이름을 mysql이 아닌 다른 이름을 사용하는 것이다.
이것은 새로운 서비스가 정확히 설치 되도록 하게 해 주지만, 대신에 이전의 서비스를 남기게 된다. 비록 이렇게 하는 것
이 시스템에는 무해할 지라도, 더 이상 사용하지 않는 이전의 서비스는 삭제하는 것이 더욱 바람직하다.
구형 mysql 서비스를 영원히 삭제하기 위해서는, 명령어 라인에서 관리자 권한이 있는 사용자로서 아래의 명령어를 실행
한다:
C:￦> sc delete mysql
[SC] DeleteService SUCCESS
만약에 여러분이 사용하는 윈도우 버전에서 sc를 사용할 수 없다면, delsrv 유틸리티를 http://www.microsoft.com/
windows2000/techinfo/reskit/tools/existing/delsrv-o.asp 에서 다운 로드 받고 delsrv mysql 신텍스를 사용한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.14. 윈도우에서 MySQL 업그레이드 하기
2. MySQL 설치 및 업그레이드 하기 이 섹션에서는 여러분이 윈도우에서 MySQL을 업그레이드 할 때 진행해야 하는 과정들을 설명한다.
2.3. 윈도우에 MySQL설치 하기
2.3.14 윈도우에서 MySQL 업그레이드 하기 1. Section 2.10, “MySQL 업그레이드 하기”를 참고 한다.
2. 업그레이드를 수행하기 전에는 항상 현재의 MySQL을 백업 한다. Section 5.10.1, “데이터 베이스 백업하기”를
참조.
3. http://dev.mysql.com/downloads/에서 최신의 MySQL 윈도우용 배포판을 다운 로드한다.
4. 업그레이드를 하기 전에는 반드시 서버를 종료한다. 만약에 서버가 서비스 형태로 설치되어 있다면, 아래의 명령어
를 사용해서 서비스를 멈추게 한다:
5. C:￦> NET STOP MYSQL
서버가 서비스 형태가 아니라면, 아래의 명령어를 사용한다:
Note: 만약에 MySQL의 root 사용자 계정이 패스워드가 있다면, mysqladmin을 -p 옵션과 함께 구동시켜서 패스
워드를 입력한다.
6. 4.1.5. 이전 버전에서 5.0으로 업그레이드를 할 때, 또는 Zip 아카이브에서 설치한 MySQL 버전을 MySQL 설치 마
법사로 설치하는 버전으로 업그레이드를 할 경우에는, 여러분은 반드시 수동으로 이전의 설치 버전과 서비스를 제거해야
한다.
MySQL 서비스를 제거하기 위해서는, 아래의 명령어를 사용한다:
C:￦> C:￦mysql￦bin￦mysqld --remove
만약에 현재의 서비스를 제거하지 않으면, MySQL 설치 마법사는 새로운 MySQL 서비스를제대로 설치하지 못할 수도 있

:::MySQL Korea:::
다.
7. 여러분이 설치 마법사를 사용한다면, Section 2.3.3, “MySQL 설치 마법사 사용하기”에 설명되어 있는 마법사를
사용한다.
8. Zip 아카이브에서 MySQL을 설치한다면, 아카이브를 추출한다. 여러분은 현재 설치되어 있는 위치에 덮어 쓰기를
할 수도 있고(일반적으로는 C:￦mysql), 또는 다른 디렉토리에 설치할 수도 있다(예를 들면, C:￦mysql4). 현재 위치에
덮어 쓰기를 하길 권장한다.
9. MySQL 서버가 윈도우 서비스 형태로 동작되었고 이 과정 초기에 서비스를 삭제했다면, 서비스를 재 설치한다.
(Section 2.3.11, “윈도우 서비스 형태로 MySQL 시작하기”를 참조.)
10. 서버를 재 구동한다. 예를 들면, MySQL 서버가 윈도우 서비스 형태로 구동한다면 NET START MySQL를 사용하
고, 그렇지 않은 경우에는, mysqld을 직접 호출한다.
11. 에러가 발생하면, Section 2.3.13, “윈도우에서 MySQL 설치 문제 해결”을 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.3.15. 윈도우에서의 MySQL과 유닉스에서의 MySQL 비교
2. MySQL 설치 및 업그레이드 하기 윈도우용 MySQL은 매우 안정하다는 것이 검증되어 있다. MySQl의 윈도우 버전은 이에 대응하는 유닉스 버전과 동일한 기능을
2.3. 윈도우에 MySQL설치 하기 갖고 있지만, 아래의 내용은 예외이다:
2.3.15 윈도우에서의 MySQL과 유닉스에서의

MySQL 비교 ● 윈도우95와 쓰레드
Windows 95는 가가 쓰레드를 생성하는 데 있어서 메인 메모리의 200바이트 정도를 소모(leak)한다. MySQL에서 각각
의 연결은 새로운 쓰레드를 생성하고, 따라서 서버가 많은 수의 연결을 처리하는 경우에는 윈도우 95에서는 오랜 시간 동
안 mysqld 을 구동할 수 없게 된다! 새로운 윈도우 버전은 이러한 버그를 수정하였다.
● 제한된 포트 수
윈도우는 클라이언트를 위해 약 4,000개의 포트를 사용할 수 있으며, 또한 한 포트에서 연결이 종료된 후에는, 그 포트를
다시 사용할 수 있을 때까지는 2에서 4분 정도가 걸리게 된다. 이 같은 경우에, 클라이언트가 서버와 매우 빈번하게 연결
및 해제를 하게 되면, 종료된 포트를 다시 사용하기 전에 모든 포트가 사용될 가능성이 생기게 된다. 만일 이러한 일이 발
생하면, MySQL 서버는 구동을 되더라도 무응답 상태가 되게 된다. 플랫폼에 있는 다른 어플리케이션도 포트를 사용하기
때문에, 이와 같은 경우 MySQL이 사용할 수 있는 포트는 매우 적은 수가 된다는 점을 알아두기 바란다.
http://support.microsoft.com/default.aspx?scid=kb;en-us;196271를 참조하여 이 문제에 관련된 보다 많은 정보
를 얻기 바란다.
● 동시 읽기
MySQL은 INSERT 와 SELECT를 섞어 사용하기 위해서 pread() 및 pwrite() 시스템 호출을 사용한다. 현재의 버전까
지는, 우리는 mutexes를사용해서 pread() 과 pwrite()를 모방(emulate)하고 있다. 우리는 향후에 가상의 인터페이스
를 가지고 파일 레벨 인터페이스를 대신하고자 하고 있으며, 이렇게 되면 우리는 윈도우 NT, 2000, 및 XP에서 보다 빠른
속도로 readfile()/writefile()를 실행할 수 있을 것이다. 현재까지는 MySQL5.0이 사용할 수 있는 오픈 파일의 숫자를

:::MySQL Korea:::
2,048개로 제한 하는데, 이것은 유닉스에서와 같이 많은 수의 쓰레드를 윈도우 NT, 2000, XP, 및 2003에서는 구동할
수 없음을 의미한다.
● 블록킹 읽기(Blocking Read)
MySQL은 각각의 연결에서 블록킹 읽기를 사용한다. 네임드 파이프 연결이 활성화 될 경우에 다음의 동작이 실행된다:
❍ 연결은, MySQL의 유닉스 버전에서와 같이, 자동으로 8시간 동안 끊기지 않게 된다.

❍ 연결이 행(hang) 상태가 된다면, MySQl을 강제로 종료하기 전에는 끝낼 수가 없게 된다.
❍ mysqladmin kill은 슬리핑(sleeping) 연결상에서는 동작하지 않는다.
❍ mysqladmin shutdown는 슬리핑 연결이 되어 있는 한 종료할 수 없다.
이 문제에 대해서는 나중에 해결할 계획이다.
● ALTER TABLE
여러분이 ALTER TABLE 명령문을 실행 시키는 동안, 테이블은 다른 쓰레드에의해 잠기게(locked) 된다. 윈도우에서는
필연적으로 이러한 일이 발생하고, 여러분은 다른 쓰레드가 사용중에 있는 파일을 삭제할 수 없게 된다. 향후에, 이 문제
를 해결하도록 할 것이다.
● DROP TABLE
MERGE 테이블이 사용하는 테이블상에서 DROP TABLE작업은 MERGE 핸들러가 MySQL의 최상위 계층으로부터 테이
블 매핑을 숨기기 때문에 윈도우에서는 작동되지 않는다. 윈도우는 열려 있는 파일을 드롭핑하는 것을 수용하지 않기 때문
에, 여러분은 우선 모든 MERGE 테이블을 꺼내거나 또는 테이블을 드롭하기 전에 MERGE 테이블을 드롭해야만 한다.
● DATA DIRECTORY 및 INDEX DIRECTORY
CREATE TABLE 에 대한 DATA DIRECTORY 및 INDEX DIRECTORY 옵션들은 윈도우에서는 무시 되어지는데, 왜

냐하면 윈도우는 심볼릭 링크를 지원하지 않기 때문이다. 이러한 옵션들은 비 함수적인(non-functional ) realpath() 호
출을 갖는 시스템에서도 무시된다.

:::MySQL Korea:::
● DROP DATABASE
다른 쓰레드가 사용하고 있는 데이터 베이스를 드롭할 수 없다.
● 테스크 관리자(Task Manager)로부터 MySQL을 강제로 종료하기
윈도우 95에서는, 테스크 관리자 또는 셧 다운 유틸리티를 가지고 강제로 MySQL을 종료할 수 없다. mysqladmin
shutdown를 사용해야만 한다.
● Case-insensitive names
윈도우에서는 파일 이름은 대소 문자를 구분하지 않으며, 따라서 윈도우상의 MySQL데이터 베이스 및 테이블 역시 대소
문자를 구분하지 않는다. 단, 데이터 베이스와 테이블 이름은 명령문에서 지정하는 대소 문자와는 똑 같이 사용해야 한다.
Section 9.2.2, “Identifier Case Sensitivity”를 참조할 것.
● The ‘￦’ pathname separator character
윈도우에서는 경로 이름을 ‘￦’ 문자로 구분하는데, MySQL에서는 이 문자를 종료 문자로도 사용한다. 만약에 여러분
이 LOAD DATA INFILE 또는SELECT ... INTO OUTFILE를 사용한다면, ‘/’ 문자를 가진 파일 이름을 사용하기
바란다:
mysql> LOAD DATA INFILE 'C:/tmp/skr.txt' INTO TABLE skr;
mysql> SELECT * INTO OUTFILE 'C:/tmp/skr.txt' FROM skr;
아니면, ‘￦’문자를 두 번 연속 사용해야 한다:
mysql> LOAD DATA INFILE 'C:￦￦tmp￦￦skr.txt' INTO TABLE skr;
mysql> SELECT * INTO OUTFILE 'C:￦￦tmp￦￦skr.txt' FROM skr;
● Problems with pipes

:::MySQL Korea:::
파이프는 윈도우 명령어 라인에서 정확히(reliably) 동작하지 않는다. 만약에 파이프가 문자 ^Z / CHAR(24)를 포함하고
있다면, 윈도우는 이것이 파일의 끝이고 프로그램을 종료하라는 의미로 받아 들인다.
이것은 주로 여러분이 아래와 같이 바이너리를 적용하고자 할 때 문제를 일으킨다:
C:￦> mysqlbinlog binary_log_file | mysql --user=root
만약에 로그를 적용하는데 문제가 있고 이 문제가 ^Z / CHAR(24) 문자때문이라고 의심이 되면, 아래와 같이 다른 방법
을 사용하기 바란다:
C:￦> mysqlbinlog binary_log_file --result-file=/tmp/bin.sql
C:￦> mysql --user=root --execute "source /tmp/bin.sql"
두번째 명령어는 바이너리 데이터를 갖고 있는 어떤 SQL 파일에서도 안정적으로 사용할 수 있는 것이다.
● Access denied for user error
만약에 MySQL이 여러분의 호스트 이름을 정확하게 풀지 못하면, 여러분이 MySQL클라이언트 프로그램을 구동시켜서
동일 머신의 서버에 연결하고자 할 때 아래와 같은 에러를 보게 된다:
Access denied for user 'some_user'@'unknown'
to database 'mysql'
이 문제를 해결하기 위해서는, 아래의 정보를 갖는 ￦windows￦hosts라는 파일을 하나 만들어야 한다:
127.0.0.1 localhost
다음에는 윈도우에서 MySQl을 개선하는데 있어서 여러분들이 도움이 필요한 문제를 열거하겠다:
● 윈도우가 제공하는 쓰레드-안전(the faster thread-safe) 증분/감산( increment/decrement) 방법을 보다 빠르게 구동

:::MySQL Korea:::
시키기 위한 매크로.

:::MySQL Korea:::
제목검색
MySQL 한글 매뉴얼에 대하여..

1. MySQL 한글 매뉴얼에 대하여.. 본 매뉴얼은 오픈 소스 데이터 베이스의 대명사인 MySQL 데이터 베이스에 대한 사용 설명서로서, MySQL AB가 발행한
1 MySQL 한글 매뉴얼에 대하여.. “MySQL 5.0 Reference Manual”을 한국어로 번역한 것입니다.
MySQL DB는 속도, 안정성, 대중성에 있어서 이미 확고한 자리를 잡은 데이터 베이스 시스템입니다. MySQL AB의 한국내 공식
골드 파트너사인 ㈜아이티 브릿지는 한국내 MySQL DB 사용자께서 MySQL DB가 가지고 있는 특징과 장단점을 보다 효과적으
로 파악할 수 있도록 본 한글 매뉴얼을 만들었으며, 따라서 현업에 MySQL을 적용하시고자 하시는 분에게 좋은 참고가 되길 바랍
니다.
본 매뉴얼은 “MySQL 5.0 Reference Manual”의 내용을 1:1로 번역을 한 것이며, 따라서 모든 목차는 원본과 일치합니다. 영
문 원본을 참조하시고자 하는 분들을 위해서, 본 사이트에서는 영문 원본 매뉴얼도 함께 제공을 하고 있습니다.
(참고하시는 중에 잘못된 부분을 발견하실 경우에는, 우리 회사에 연락을 주시기 바랍니다.)
- 저작권 공지-
본 한글 매뉴얼의 소유권은 ㈜아이티 브릿지에 있으며, 우리 회사의 사전 허가 없이 무단 복제를 하거나, 다른 웹사이트에 게재하는 것을 금지하오
니 많은 협조를 부탁 드립니다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.4. 리눅스에 MySQL 설치 하기
2. MySQL 설치 및 업그레이드 하기 리눅스에 MySQL을 설치하는데 있어서 권장할 수 있는 방법은 RPM패키지를 사용하는 것이다. MySQL RPM들은 현재 수세 리눅
2.4. 리눅스에 MySQL 설치 하기 스7.3 시스템에서 구축되어 있느나, rpm 과 glibc 의 사용을 지원하는 대부분의 리눅스에서도 동작할 수 있다. RPM 패키지는
2.4 리눅스에 MySQL 설치 하기 Section 2.1.3, “MySQL 다운 로드 하기”에서 참조하기 바란다.
MySQL AB사는 특정 플랫폼 관련 RPM들을 제공한다; 플랫폼 관련 RPM과 일반 RPM의 차이는, 플랫폼 관련 RPM은 특정 플랫
폼에 구축이 되고 동적으로 해당 플랫폼에 연결되도록 의도된 것인 반면에 일반 RPM은 리눅스쓰레드(LinusThread)를 갖고 정적
(statically)으로 연결되는 것이다.
Note: MySQL의 RPM 배포판은 종종 다른 벤더에서도 제공하고 있다. 이러한 것들은 MySQL AB사가 제공하는 것들과 기능 및
내용물에서 다소 차이가 있을 수 있으며, 이 설명서에서 제공하는 방법으로 설치할 수 없을 수도 있다는 점을 알기 바란다. 대신에
제품을 제공하는 벤더의 설명서를 따르기 바란다.
RPM파일에 문제가 있다면(예를 들면, Sorry, the host 'xxxx' could not be looked up과 같은 에러가 있다면),
Section 2.12.1.2, “리눅스 바이너리 배포판 노트”를 참조하기 바란다.
대부분의 경우, MySQL의 표준 기능 설치는 MySQL-server 및 MySQL-client만 설치하면 된다. 다른 패키지들은 표준 설치에
서는 필요 없는 것들이다. MySQL의 다른 부가적인 기능을 갖고 있는MySQL-Max 서버를 설치하기 위해서는, MySQL-Max
RPM을 설치해야 한다. 하지만, 이것들은 반드시 MySQL-server RPM 을 설치한 다음에 진행해야 한다. Section 5.3,
“MySQL 서버의 mysqld-max 확장 버전”를 참조할 것.
MySQL패키지를 설치하고자 할 때 의존적 실패(dependency failure)가 발생하면(예를 들어, error: removing these packages
would break dependencies: libmysqlclient.so.10 is needed by ...), 여러분은 MySQL-shared-compat 패키지도 설치해야
하는데, 여기에는 이전 버전과(backward)의 호화성을 위한 공유 라이브러가 들어 있다(MysQL4.0을 위한 libmysqlclient.so.12
및 3.23을 위한 libmysqlclient.so.10).
몇몇 리눅스 배포판들은 아직까지도 MySQL 3.23과 함께 제공되며 이것들은 일반적으로 디스크 공간을 절약하기 위해 어플리케
이션들과 동적으로 연결되어 있다. 별도의 패키지에 이러한 공유 라이브러리들이 있는 경우에는 (예를 들면, MySQL-shared), 설
치된 패키지는 그대로 놓아 두고 MySQL서버와 클라이언트 패키지를 업그레이드 하는 것으로도 충분하다(이것들은 정적으로 링
크가 되어 있으며 공유 라이브러리들에는 의존하지 않는다). MySQL서버(예를 들면, 레드헷 리눅스)와 같이 동일한 패키지에 공
유 라이브러리들을 갖고 있는 배포판의 경우, 여러분은 우리가 제공하는 3.23 MySQL-shared RPM을 사용하거나, 또는

:::MySQL Korea:::
MySQL-shared-compat 를 대신 사용할 수 있을 것이다.

아래의 RPM 패키지들은 사용 가능한 것들이다:
● MySQL-server-VERSION.i386.rpm
MySQL 서버. 여러분은 다른 머신에서 동작하는 MySQL서버에만 연결되길 원하지 않는다면 이것이 필요하게 된다. 노
트: 서버 RPM 파일은 4.0.10 버전 이전에는 MySQL-VERSION.i386.rpm 이라고 불리었다. 즉, 여기에는 –server를
붙이지 않았다.
● MySQL-Max-VERSION.i386.rpm
MySQL-Max 서버. 이 서버는 MySQL-server RPM에서는 제공하지 않는 부가적인 기능들이 포함되어 있다. 우선
MySQL-server RPM 를 먼저 설치해야 하는데, MySQL-Max RPM 이 이것에 의존하기 때문이다.
● MySQL-client-VERSION.i386.rpm
표준 MySQL 클라이언트 프로그램. 아마도 항상 이 패키지를 설치하고자 할 것이다.
● MySQL-bench-VERSION.i386.rpm
테스트 및 벤치마크. Perl과 DBD::mysql 모듈이 필요함.
● MySQL-devel-VERSION.i386.rpm
Perl모듈과 같은 다른 MySQL클라이언트를 컴파일 하고자 할 경우에 필요한 라이브러리와 파일들을 포함함.
● MySQL-shared-VERSION.i386.rpm
이 패키지는 특정 언어와 어플리케이션인 MySQL을 동적으로 로드하고 사용할 때 필요한 공유 라이브러리들

(libmysqlclient.so*)을 갖고 있다.
● MySQL-shared-compat-VERSION.i386.rpm

:::MySQL Korea:::
이 패키지는 MySQL 3.23 및 MySQL 4.0에 모두 필요한 공유 라이브러리들을 갖고 있다. 만약에 여러분이 MySQL3.23
에 대비해서 동적으로 링크되어 있는 어플리케이션을 갖고 있지만, 라이브러리의 의존성의 해치지 않는 상태에서 4.0버전
으로 업그레이드를 하고자 할 경우에 MySQL-shared 대신에 이 패키지를 설치 한다. 이 패키지는 MySQL4.0.13이후 버
전에서 사용 가능하다.
● MySQL-embedded-VERSION.i386.rpm
MySQL 서버 라이브러리(MySQL 4.0에서부터 사용할 수 있음).
● MySQL-VERSION.src.rpm
여기에는 이전의 모든 패키지에 대한 소스 코드가 포함되어 있다. 다른 구조(예를 들면, Alpha 또는 SPARC)상에서 RPM
을 재 구성할 수 있게 한다.
RPM 패키지(예를 들면, MySQL-server RPM)에 들어 있는 모든 파일을 보기 위해서는, 아래와 같은 명령어를 구동시킨다:
shell> rpm -qpl MySQL-server-VERSION.i386.rpm
표준 최소 설치를 실행하기 위해서는, 서버와 클라이언트의 RPM을 설치한다:
shell> rpm -i MySQL-server-VERSION.i386.rpm
shell> rpm -i MySQL-client-VERSION.i386.rpm
클라이언트 프로그램만 설치할 경우에는, 단지 클라이언트 RPM만 설치한다:
shell> rpm -i MySQL-client-VERSION.i386.rpm
RPM은 이것을 설치하기 전에 패키지의 신뢰도와 집적도를 검증할 수 있는 기능을 제공한다. 이러한 기능에 대해 보다 자세히 알아
보고자 한다면, Section 2.1.4, “MD5 체크 썸(Checksums) 또는 GnuPG를 사용해서 패키지 집적도를 검사하기”를 참조할 것
서버 RPM은 데이터를 /var/lib/mysql 밑에 놓는다. RPM는 또한 mysql 이름의 사용자가 MySQL서버를 구동시키기 위해 사용할
수 있는 로그인 계정을 생성하며(존재하지 않는다면), 부팅시 자동으로 서버를 구동시키기 위해 /etc/init.d/ 안에 적당한 엔트리들
을 생성한다.(이것은 만약에 여러분이 이전에 설치를 했고 시작 스크립트를 변경시켰다면, 여러분은 스크립트를 복사해 두어서 새
로운 RPM을 설치할 때 잃어 버리는 것을 대비할 수 있다는 것을 의미한다.) MySQL이 시스템 구동시 자동으로 구동되게 하는 방
법에 대해 보다 많은 정보를 원한다면 Section 2.9.2.2, “Starting and Stopping MySQL Automatically”를 참조하기 바란다.
만약에 /etc/init.d (직접적으로 또는 심링크(symlink)를 통해)에 있는 초기화 스크립트를 지원하지 않는 구형 리눅스 배포판에
MySQL RPM을 설치하고자 한다면, 여러분의 초기화 스크립트가 실제로 설치되어 있는 장소를 가리키는 심볼릭 링크를 생성해야
한다. 예를 들면, 만약에 그 위치가 /etc/rc.d/init.d라면, RPM을 설치하기 전에 그 위치를 가리키는 심볼릭 링크로서 /etc/init.d 를

:::MySQL Korea:::
생성하기 위해 아래의 명령어를 사용한다:

shell> cd /etc
shell> ln -s rc.d/init.d .
하지만, 현재의 모든 주요 리눅스 배포판은 /etc/init.d를 사용하는 새로운 디렉토리를 지원하고 있는데, 왜냐하면 이것이 LSB
(Linux Standard Base) 호환을 위해 필요하기 때문이다.
여러분이 설치한 RPM파일이MySQL-server를 포함하고 있다면, 설치후에 mysqld 서버를 불러와서 구동시켜야 한다. MySQL
를 사용해서 구동 시킬 수 있어야 한다.
만약에 무언가 문제가 생긴다면, 바이너리 설치 섹션에서 보다 많은 정보를 찾을 수 있을 것이다. Section 2.7, “유닉스와 유사한
시스템에서 MySQL설치하기”를 참조할 것.
Note: 초기 MySQL그랜트 테이블에 있는 계정들은 패스워드를 갖고 있지 않다. 서버를 구동시킨 다음에는, Section 2.9, “설치
후 설정 및 테스팅”에서 제공하는 지침을 사용해서 패스워드를 설정해야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.5. Mac OS X에 MySQL 설치 하기
2. MySQL 설치 및 업그레이드 하기 여러분은 Mac OS X 10.2.x (“Jaguar”) 또는 이후 버전에 바이너리 타볼(tarball)배포판 대신에 PKG버전에 있는 Mac OS X바
2.5. Mac OS X에 MySQL 설치 하기 이너리 패키지를 사용해서 MySQL을 설치할 수 있다. 이 패키지는 Mac OS X (for example, 10.1.x) 보다 구형 버전은 지원하지
2.5 Mac OS X에 MySQL 설치 하기 않음을 알아 두기 바란다.
이 패키지는 파인더에서 여러분이 맨 처음 더블 클릭해서 마운트해야 하는 아이콘인 디스크 이미지(.dmg) 파일 안에 들어 있다.
그 다음에는 이미지를 마운트해서 내용물을 화면에 보이게 한다.
MySQL 다운 로드 하기 위해서는, Section 2.1.3, “MySQL 다운 로드 하기”를 참조할 것.
Note: 설치 작업을 진행하기 전에, 반드시 모든 MySQL서버 인스턴스를 MySQL관리자 어플리케이션(Mac OS X 서버에서) 또는
명령어 라인에서 mysqladmin shutdown를 실행시켜서 셧다운 시켜야 한다.
MySQL PKG 파일을 실제로 설치 하기 위해서는, 패키지 아이콘을 더블 클릭한다. 이것은 Mac OS X 패키지 설치기를 구동시키
게 되며, MySQ이 설치되는 동안 여러분을 도와줄 것이다.
Mac OS X 패키지 설치기에 있는 버그 때문에, 여러분은 목적(destination )디스크 선택 다이어로그에서 아래와 같은 에러 메시지
를 볼 수도 있을 것이다:
You cannot install this software on this disk. (null)
에러가 발생하게 되면, Go Back 버튼을 눌러서 이전 페이지로 복귀한다. 그 다음에 Continue 버튼을 다시 한번 눌러서 목적 디스
크 선택을 다시 한번 하게 되면 목적 디스크를 올바르게 선택할 수 있게 될 것이다. 우리는 이 버그를 애플사에 통보를 하였으며 지
금 이 문제를 애플사가 검토하고 있는 상황이다.
MySQL의 Mac OS X PKG 는 패키지 자체를 /usr/local/mysql-VERSION 에 설치하고 심볼릭 링크를 설치하는데, /usr/local/
mysql, 이것은 새로운 위치를 가리키게 된다. 만약에 /usr/local/mysql 라는 디렉토리가 존재한다면, 이것은 /usr/local/mysql.
bak 라는 이름으로 우선 변경된다. 또한, 설치기는 mysql_install_db 를 실행시켜서 mysql 데이터 베이스내에 그랜트 테이블을 생
성한다.
설치 레이 아웃은 tar 파일 배포판의 레이 아웃과 비슷한 형태가 된다; 모든 MySQL 바이너리들은 /usr/local/mysql/bin 디렉토리
에 위치하게 된다. MySQL 소켓 파일은 디폴트로 /tmp/mysql.sock의 형태로 만들어 진다. Section 2.1.5, “설치 레이 아웃”을
참조할 것.
MySQL 설치는 mysql 이라는 Mac OS X 사용자 계정을 요구한다. 이 이름을 갖는 사용자 계정은 Mac OS X 10.2이후 버전에서

:::MySQL Korea:::
는 디폴트로 존재하고 있다.

Mac OS X 서버가 구동 중이라면, MySQL버전은 이미 설치되어 있어야 한다. 아래의 테이블은 mac OS X서버 버전에 포함되어 있
는 MySQL버전을 나타내는 것이다.
Mac OS X Server Version MySQL Version
10.2-10.2.2 3.23.51
10.2.3-10.2.6 3.23.53
10.3 4.0.14
10.3.2 4.0.16
10.4.0 4.1.10a
이 매뉴얼 섹션은 공식적인 MySQL Mac OS X PKG의 설치만을 다루고 있다. MySQL설치에 관련된 애플사의 도움말을 읽기 바
란다: “Help View”어플리케이션을 구동 시킨후, “Mac OS X Server”도움말을 선택, “MySQL,”관련 부분을 찾은 다음에
“Installing MySQL.”이라는 항목을 읽기 바란다.
Mac OS X서버에 사전 설치(pre-installed)된 MySQL버전에 대해서는, 특히 MySQL의 버전이 4.0보다 이전 버전이라면,
mysqld_safe 을 구동하는 대신에 safe_mysqld 를 사용해서 mysqld 을 동작시켜야 한다는 점을 알기 바란다.
만약에 여러분이 예전에 http://www.entropy.ch 에서 얻은 Mac OS X를 위한 Marc Liyanage's MySQL 패키지를 사용하였다
면, 거기에서 설명하는 바이너리 설치 레이아웃을 사용해서 패키지를 업데이트 시킬 수 있을 것이다.
만약에 Marc's 3.23.xx 버전 또는 MySQL의 Mac OS X 서버 버전으로부터 공식 MySQL PKG로 업그레이드를 하고자 한다면,
여러분은 존재하는 MySQL권한 테이블을 현재의 포멧으로 변환할 필요가 있는데, 그 이유는 몇가지 새로운 보안 권한이 추가 되었
기 때문이다. Section 5.6, “mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드”를 참조할 것.
시스템 시작 시점에 MySQL을 자동으로 구동시키고자 한다면, 여러분은 MySQL스타트업 항목(Startup item)도 함께 설치를 해
야 한다. 이것은 별개의 패키지 형태로 Mac OS X설치 디스크 이미지에 있다. 간단히 MySQLStartupItem.pkg 아이콘을 더블 클
릭한 후에 설치 가이드를 따라서 설치를 진행하면 된다.
스타트업 아이템은 오직 한번만 설치하면 된다는 점을 알아두자! 나중에 MySQL패키지를 업그레이드할 때마다 계속 설치할 필요
가 없다.
MySQL스타트업 아이템은 /Library/StartupItems/MySQLCOM안에 설치된다.( MySQL 4.1.2 이전 버전에서는, /Library/
StartupItems/MySQL에 설치 되었으나Mac OS X가 설치하는 MySQL스타트업 아이템과 서로 충돌을 일으켰다.) 스타트업 아이
템 설치는 변수 MYSQLCOM=-YES- 를 시스템 구성 파일인 /etc/hostconfig에 추가 한다. MySQL스타트업의 자동 실행을 비

:::MySQL Korea:::
활성화 시키고자 한다면, 간단하게 이 변수를 MYSQLCOM=-NO-로 변경시키면 된다.

Mac OS X Server서버에서, 디폴트 MySQL 설치는 /etc/hostconfig 파일에 있는 변수 MYSQL 를 사용한다. MySQL AB사의 스
타트업 아이템 설치기는 MYSQL=-NO-로 이 변수를 설정하여 비활성화 시킨다. 이것은 MySQL AB사의 스타트업 아이템이 사
용하는 MYSQLCOM 변수와 부팅 시간에 서로 충돌을 일으키는 것을 피하기 위해서이다. 하지만, 이것은 동작중인 MySQL서버를
셧다운 시키지는 않는다. 여러분 스스로가 셧다운을 해야 한다.
설치 후에는, 터미널 윈도우에서 아래의 명령어를 실행시켜서 MySQL을 시작할 수 있게 된다. 이 업무를 진행하기 위해서는 관리
자(administrator) 권한이 있어야 한다.
이 명령어를 사용해서 스타트업 아이템을 설치한다면:
shell> sudo /Library/StartupItems/MySQLCOM/MySQLCOM start
(Enter your password, if necessary)
(Press Control-D or enter "exit" to exit the shell)
스타트업 아이템을 사용하지 않는다면, 아래의 명령어들을 순차적으로 입력한다:
shell> cd /usr/local/mysql
shell> sudo ./bin/mysqld_safe
(Enter your password, if necessary)
(Press Control-Z)
shell> bg
(Press Control-D or enter "exit" to exit the shell)
여러분은 예를 들면, /usr/local/mysql/bin/mysql 를 구동시켜서, MySQL서버에 접속할 수 있게 될 것이다.
Note: MySQL그랜트 테이블에 초기에 들어 있는 계정들은 패스워드가 없다. 서버를 구동 시킨 후에는, Section 2.9, “설치후 설
정 및 테스트”에서 설명하는 방식을 사용해서 계정들에 대해 패스워드를 설정해야 한다.
여러분은 쉘 리소스 파일에 별칭(aliases)을 추가 해서 명령어 라인에서 mysql 및 mysqladmin 과 같은 일상적으로 사용되는 프로
그램을 보다 쉽게 접근하고자 할 것이다. bash에 대한 신텍스는 아래와 같다:
alias mysql=/usr/local/mysql/bin/mysql
alias mysqladmin=/usr/local/mysql/bin/mysqladmin
tcsh에 대해서는, 아래를 사용한다:
alias mysql /usr/local/mysql/bin/mysql
alias mysqladmin /usr/local/mysql/bin/mysqladmin
아울러, PATH 환경 변수에 /usr/local/mysql/bin 를 추가할 수도 있다. 예를 들면, 여러분 쉘이 bash 라면 아래의 라인을 여러분
의 $HOME/.bashrc 파일에 추가해 보자:
PATH=${PATH}:/usr/local/mysql/bin

:::MySQL Korea:::
여러분 쉘이 tcsh라, 아래의 라인을 $HOME/.tcshrc 파일에 추가한다:

setenv PATH ${PATH}:/usr/local/mysql/bin
여러분 홈 디렉토리에 .bashrc 또는 .tcshrc 파일이 없다면, 텍스트 편집기를 사용해서 이것을 생성한다.
기존에 설치되어 있는 것을 업그레이드 하고자 한다면, 새로운 MySQL PKG의 설치를 통해서는 예전에 설치한 디렉토리가 제거되
지 않는다는 점을 알아두자. 애석하게도, Mac OS X 설치기는 아직까지 이전 설치 패키지를 정확히 업그레이드하는데 필요한 기능
들을 제공해 주지 못하고 있다.
기존의 데이터 베이스를 업그레이드 할 경우에는, 기존의 데이터 디렉토리의 모든 내용을 새로운 디렉토리로 복사해 둘 필요가 있
다. 복사 작업을 하는 동안에는 어떠한 서버(구형 또는 새로운 서버)도 동작하지 않도록 해야 한다. 이전에 설치한 데이터 베이스
를 복사하고 성공적으로 새로운 서버를 구동시킨 다음에는, 구형 설치 파일들을 제거함으로서 디스트의 공간을 절약하도록 한다.
아울러, /Library/Receipts/mysql-VERSION.pkg 에 있는 구형 패키지 수신(receipts)디렉토리도 삭제해야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.6. Installing MySQL on NetWare –

Skip
2.6. Installing MySQL on NetWare
2.6 Installing MySQL on NetWare
:::MySQL Korea:::
제목검색
상위메뉴 2.7. 유닉스와 유사한 다른 시스템에 MySQL 설치 하기

리스트 ◆
이 섹션에서는 압축된 tar파일(.tar.gz 확장자 형식의 파일) 형태로 제공되는 MySQL바이너리 배포판을 설치하는 방법에 대해 설명하기로 한다. 보다 자세한 사항은 Section 2.1.2.5,
2. “MySQL AB사가 컴파일한 MySQL바이너리”를 참조하기 바란다.
MySQL
MySQL을 다운 로드하는 방법은 Section 2.1.3, “MySQL 다운 로드하기”를 참조하기 바란다.
설치 및
MySQL tar 파일 바이너리 배포판은 mysql-VERSION-OS.tar.gz형태의 이름을 갖고 있으며, VERSION 은 숫자이며(예를 들면, 5.0.19), OS 는 이 배포판을 설치하고자 하는 OS타입을 의
업그레
미한다(예를 들면, pc-linux-i686).
이드 하
기 이러한 일반적인 패키지에는, 선택한 플렛폼-관련 패키지 포멧안에 바이너리를 같이 제공한다. Section 2.2, “바이너리 배포판을 사용한 표준 MySQL 설치”에서 보다 많은 정보를 찾기 바란
다.
2.7. 유
닉스와 여러분은 MySQL tar파일 바이너리 배포판을 설치하기 위해서 아래의 툴들이 필요할 것이다:
유사한
다른 시 ● 배포판의 압축을 풀기 위한 GNU gunzip.
스템에 ● 제대로 동작하는tar. GNU tar 이 많이 알려져 있음. 어떤 OS에는 문제점을 갖고 있다고 알려져 있는 tar가 포함되어 있기도 하다. 예를 들면, Mac OS X tar 및 Sun tar는긴 파일 이름
MySQL 의 처리에 문제를 갖고 있다고 알려져 있다. Mac OS X의 경우, OS안에 있는 gnutar 프로그램을 사용할 수 있을 것이다. 기능이 떨어지는tar를 갖고 있는 다른 OS의 경우, 우선 GNU
설치 하
tar를 설치하기 바란다.
기
2.7 유닉스 만약에 어떠한 문제가 있다고 생각으로 하고 버그 레포트를 제출하고자 한다면, Section 1.8, “버그 또는 문제점 레포트 하기”의 지침을 따라 하시기 바란다.
와 유사
MySQL바이너리 배포판을 설치하고 사용하기 위해 가장 먼저 실행해야 할 명령어들은 아래와 같다:
한 다른
shell> groupadd mysql
시스템
에 shell> useradd -g mysql mysql
MySQL shell> cd /usr/local

설치 하 shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
기 shell> ln -s full-path-to-mysql-VERSION-OS mysql
shell> cd mysql
shell> scripts/mysql_install_db --user=mysql
shell> chown -R root .
shell> chown -R mysql data
shell> chgrp -R mysql .
shell> bin/mysqld_safe --user=mysql &
Note: 이 과정에서는 MySQL계정을 위한 어떠한 패스워드고 설정을 하지 않는다. 이 과정을 마친후에, Section 2.9, “MySQL 설치후 설정 및 테스트”의 과정을 진행한다.

:::MySQL Korea:::
위의 설치 과정을 마친 후에는 다음의 과정을 진행한다:

1. mysqld 용 로그인 사용자와 그룹을 아래와 같이 추가한다:
2. shell> groupadd mysql
3. shell> useradd -g mysql mysql
이 명령어들은 mysql 그룹과 mysql 사용자를 추가하게 한다. useradd 및 groupadd 에 대한 신텍스는 유닉스 버전에 따라 약간의 차이가 있을 수 있거나, 또는 adduser 및 addgroup
처럼 사용하는 이름이 차이가 있을 수 있다.
여러분은 mysql 대신에 다른 이름으로 사용자와 그룹을 부르고 싶을 수도 있을 것이다. 만약 그렇게 하고자 한다면, 아래의 단계에서 적당한 다른 이름을 선택하면 된다.
4. 배포판을 풀어 넣고 싶은 디렉토리를 선택한다. 아래의 예제에서는, 배포판을 /usr/local에 풀어 놓았다. (여러분이 /usr/local에 접근하고 파일을 생성할 수 있는 권한이 있다는 가
정을 우선 한다. 만일 권한이 없다면, root의 권한으로 설치를 해야 한다.)
5. shell> cd /usr/local
6. Section 2.1.3, “MySQL 다운 로드하기”의 지침대로 MySQL배포판을 다운 로드한다.
7. 배포판을 풀기 위해, 설치 디렉토리를 생성한다. 그 다음에는 그 디렉토리를 지정하는 심볼릭 링크를 생성한다:
8. shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
9. shell> ln -s full-path-to-mysql-VERSION-OS mysql
tar 명령어는 mysql-VERSION-OS라는 이름의 디렉토리를 생성한다. ln 명령어는 이 디렉토리에 대한 심볼릭 링크를 만들어 준다. 이것을 통해 여러분은 /usr/local/mysql 와 같은
설치 디렉토리를 보다 쉽게 참조할 수 있게 된다.
GNU tar를 사용한다면, 별도의 gunzip 호출은 필요없게 된다. 여러분은 첫번째 라인을 아래의 명령어로 바꿔 사용해서 배포판의 압축을 풀고 내용물을 추출할 수 있다:
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
10. 설치 디렉토리로 위치 변경:
11. shell> cd mysql
mysql 에 있는 여러 개의 파일들과 서브 디렉토리들을 볼 수 있을 것이다. 설치용 파일들 중에서 가장 중요한 것들은 bin 과 scripts 서브 디렉토리들이다:
• bin 디렉토리는 클라이언트 프로그램과 서버를 갖고 있다. 이 디렉토리의 전체 경로 이름을 PATH 환경 변수에 추가하여 여러분의 쉘이 올바르게 MySQL프로그램을 찾
을 수 있도록 한다. Appendix F, Environment Variables를 참조할 것.
• scripts 디렉토리는 서버 접근 권한을 갖고 있는 그랜트 테이블이 있는 mysql 데이터 베이스를 초기화 하는데 사용하는 mysql_install_db 스크립트를 갖고 있다.
12. 이전에 MySQL을 설치한 적이 없다면, MySQL그랜트 테이블을 반드시 생성해야 한다:
13. shell> scripts/mysql_install_db --user=mysql
루트 권한으로 명령어를 실행한다면, 위에서 본 것처럼 --user 옵션을 사용해야 한다. 옵션의 값은 여러분이 서버를 구동시키기 위해 처음 단계에서 생성했던 로그인 계정 이름이 되
어야 한다. 그 계정을 사용해서 로그인한 상태라면, --user 옵션을 생략해도 된다.
그랜트 테이블을 생성 또는 업데이트 한 후에는, 서버를 수동으로 재구동 시킨다.
14. 프로그램 바이너리의 소유권(ownership)을 root 로 변경하고 데이터 디렉토리의 소유권을 mysqld 을 구동시키고 있는 사용자로 변경한다. 여러분이 설치 디렉토리(/usr/local/
mysql)에 있다면, 명령어는 다음과 같을 것이다:
15. shell> chown -R root .
16. shell> chown -R mysql data
17. shell> chgrp -R mysql .

:::MySQL Korea:::
처음의 명령어는 파일의 소유 속성을 root 사용자로 변경시킨다. 두번째 명령어는 데이터 디렉토리의 소유 속성를 mysql 사용자로 변경 시킨다. 세번째 명령어는 그룹의 속성을
mysql 그룹으로 변경시킨다.
18. 여러분이 시스템을 부팅할 때 자동으로 MySQL을 시작하고자 한다면, support-files/mysql.server 를 여러분의 시스템 스타트업 파일이 있는 디렉토리고 복사하면 된다. 보다
자세한 정보는 support-files/mysql.server 스크립트 자체에서 찾을 수 있으며 또한 Section 2.9.2.2, “자동으로 MySQL시작 및 종료하기”에서도 찾을 수 있다.
19. DBI 및 DBD::mysql 펄(Perl) 모듈을 설치하였다면, 여러분은 bin/mysql_setpermission 스크립트를 사용해서 새로운 계정을 설정할 수 있게 된다. 보다 자세한 정보는
Section 2.13, “Perl 설치 노트”를 참조하기 바란다.
20. 만약에 mysqlaccess 를 사용하길 원하고 MySQL배포판을 표준 위치가 아닌 곳에 설치하고자 한다면, mysqlaccess 이 mysql 클라이언트를 찾는 위치를 변경해야 한다. bin/
mysqlaccess

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.8. 소스 배포판을 사용해서 MySQL 설치하기
2. MySQL 설치 및 업그레이드 하기 2.8.1. 소스 설치 소개하기

2.8. 소스 배포판을 사용해서 MySQL 설치하기 2.8.2. 전형적인 configure 옵션들
2.8 소스 배포판을 사용해서 MySQL 설치하기 2.8.3. 개발 단계 소스 트리에서 설치하기
2.8.1 소스 배포판 설치 소개 2.8.4. MySQL 컴파일링 문제 다루기
2.8.2 전형적인 configure 옵션들 2.8.5. MIT-pthreads 노트

2.8.6. 윈도우에 소스 배포판 MySQL 설치하기
2.8.3 개발 단계 소스 트리를 가지고 MySQL 설치하기
2.8.7. 윈도우에서 MySQL 클라이언트 컴파일하기
2.8.4 MySQL 컴파일 문제 다루기
2.8.5 MIT-pthreads 노트
소스 배포판을 사용해서 설치 작업을 진행하기 전에, 우선 우리가 제공하는 바이너리가 여러분의 시스템에서 사용 가능한
2.8.6 소스 배포판을 사용해서 윈도우에 MySQL 설치하기
지 그리고 제대로 동작될 것인지에 대해 검사를 해야 한다. 우리는 우리가 제공하는 바이너리들이 가장 최선의 옵션을 가지
2.8.7 윈도우에서 MySQL 클라이언트 컴파일 하기
고 구축되었다는 것을 검증하기 위해 최대한의 노력을 기울이고 있다.
MySQL 소스 배포판은 Section 2.1.3, “MySQL 다운 로드하기”를 참조하여 얻을 수 있다.
MySQL 소스 배포판은 압축된 tar 아카이브 형태로 제공되며, mysql-VERSION.tar.gz와 같은 형태의 이름을 가지는데,
여기에서VERSION 은 5.0.19와 같은 숫자가 된다.
소스로부터 MySQL을 설치하기 위해서는 다음과 같은 툴들을 사용할 필요가 있다:
● 배포판의 압축을 풀기 위한 GNU gunzip.

● 배포판을 풀기 위한 tar. GNU tar 이 많이 알려져 있음. 어떤 OS에는 문제점을 갖고 있다고 알려져 있는 tar가 포
함되어 있기도 하다. 예를 들면, Mac OS X tar 및 Sun tar는 긴 파일 이름의 처리에 문제를 갖고 있다고 알려져 있
다. Mac OS X의 경우, OS안에 있는 gnutar 프로그램을 사용할 수 있을 것이다. 기능이 떨어지는tar를 갖고 있는
다른 OS의 경우, 우선 GNU tar를 설치하기 바란다.
● 제대로 구동되는ANSI C++ 컴파일러. gcc 2.95.2 또는 이후 버전, egcs 1.0.2 또는 이후 버전 또는 egcs
2.91.66, SGI C++, 및 SunPro C++ 등의 컴파일러들이 제대로 동작되는 컴파일러로 알려져 있다. gcc를 사용
할 때에는 libg++ 는 필요없다. gcc 2.7.x에는 sql/sql_base.cc 와 같은 공식 C++컴파일러를 사용할 수 없게 하

:::MySQL Korea:::
는 버그가 있다. 여러분이gcc 2.7.x만 갖고 있다면, gcc를 업그레이드하여 MySQL을 컴파일 할 수 있도록 해주어
야 한다. gcc 2.8.1도 역시 특정 플랫폼에서 문제가 있는 것으로 알려져 있는데, 플랫폼에 새로운 컴파일러가 있다
면 이것을 사용하는 것을 피해야 한다.
gcc 2.95.2 또는 이후 버전은 MySQL 3.23.x를 컴파일 할 때 권장할 수 있는 것이다.
● 잘 만들어진 make 프로그램. GNU make 는 항상 권장할 만한 것이며 때에 따라서는 필수적으로 필요한 프로그램
이다. 만약에 문제가 있다면, GNU make 3.75 또는 이후 버전을 권장한다.
-fno-exceptions 옵션을 구동시킬 수 있는 최신의 gcc 버전 컴파일러를 사용하고 있다면, 이 옵션을 사용하는 것이 매우
중요하다. 그렇지 않으면, 바이너리를 컴파일하면서 랜덤하게 크래쉬가 발생할 수도 있다. 우리는 또한 -felide-
constructors 과 -fno-rtti 를 -fno-exceptions와 함께 사용하기를 권장한다. 의심스러울 경우에는, 아래의 것을 실행
해 본다:
CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors ￦
-fno-exceptions -fno-rtti" ./configure ￦
--prefix=/usr/local/mysql --enable-assembler ￦
--with-mysqld-ldflags=-all-static
대부분의 시스템에서, 이것은 여러분에게 빠르고 안정적인 바이너리를 제공해 준다.
만일에 문제가 있거나 버그에 대해 레포트를 하고자 하는 경우에는, in Section 1.8, “버그 및 문제점 레포트 하기”의 지
침을 따라서 해주길 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.8.1. 소스 배포판 설치 소개
2.8. 소스 배포판을 사용해서 MySQL 설치하 소스 배포판을 설치하기 위해 기본적으로 실행한 명령어는 다음과 같다:
기
2.8.1 소스 배포판 설치 소개 shell> groupadd mysql
shell> useradd -g mysql mysql
shell> gunzip < mysql-VERSION.tar.gz | tar -xvf -
shell> cd mysql-VERSION
shell> ./configure --prefix=/usr/local/mysql
shell> make
shell> make install
shell> cp support-files/my-medium.cnf /etc/my.cnf
shell> cd /usr/local/mysql
shell> bin/mysql_install_db --user=mysql
shell> chown -R root .

:::MySQL Korea:::
shell> chown -R mysql var
shell> chgrp -R mysql .
소스 RPM으로 시작을 하였다면, 아래의 명령어를 실행한다:
shell> rpmbuild --rebuild --clean MySQL-VERSION.src.rpm
이것은 여러분이 설치할 수 있는 바이너리 RPM을 만들어 준다. 구형 RPM 버전의 경우, rpmbuild 를 rpm 대신에 사용할 수 있을
것이다.
Note: 이 과정에서는 MySQL 계정을 위한 패스워드 설정을 하지 않는다. 이 과정을 마친 후에, Section 2.9, “설치후 설정 및 테
스트”의 설명을 참고하여 MySQL설치후의 설정 및 테스트 과정을 진행한다.
소스 배포판으로 MySQL을 설치하는 있어서 보다 자세한 설명은 다음과 같다:
1. mysqld 용 로그인 사용자와 그룹을 아래와 같이 추가한다:
2. shell> groupadd mysql
3. shell> useradd -g mysql mysql
이 명령어들은 mysql 그룹과 mysql 사용자를 추가하게 한다. useradd 및 groupadd 에 대한 신택스는 유닉스 버전에 따
라 약간의 차이가 있을 수 있거나, 또는 adduser 및 addgroup 처럼 사용하는 이름이 차이가 있을 수 있다.
여러분은 mysql 대신에 다른 이름으로 사용자와 그룹을 부르고 싶을 수도 있을 것이다. 만약 그렇게 하고자 한다면, 아래
의 단계에서 적당한 다른 이름을 선택하면 된다.
4. 배포판을 풀어 넣고 싶은 디렉토리를 선택한 다음 그곳으로 이동한다.
5. Section 2.1.3, “MySQL 다운 로드하기”의 지침대로 MySQL배포판을 다운 로드한다.
6. 현재의 디렉토리에 배포판을 풀어 놓는다:

:::MySQL Korea:::
7. shell> gunzip < /path/to/mysql-VERSION.tar.gz | tar xvf -
이 명령어는 mysql-VERSION라는 이름의 디렉토리를 생성한다.

GNU tar를 사용한다면, 별도의 gunzip 호출은 필요 없게 된다. 아래의 명령어를 대신 사용해서 배포판의 압축을 풀고 내
용물을 추출할 수 있다:
shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz
8. 풀어 놓은 배포판의 최상위 디렉토리로 이동한다:
9. shell> cd mysql-VERSION
여러분은 현재 여기 최상위 디렉토리에서 MySQL을 설치하고 구성해야 한다는 것을 명심하기 바란다. 다른 디렉토리에서
는 MySQL을 설치할 수 없다.
10. 릴리즈를 구성하고 모든 것을 컴파일 한다:
11. shell> ./configure --prefix=/usr/local/mysql
12. shell> make
configure를 구동시킬 때, 여러분은 다른 옵션을 지정할 수도 있다. 사용 가능한 옵션 리스트는 ./configure --help 를
통해 볼 수 있다. Section 2.8.2, “전형적인 configure 옵션들”을 참조하면 보다 유용한 옵션들을 알 수 있게 된다.
configure 실행이 실패하고 MySQL메일링 리스트를 통해 도움을 받고자 할 경우에는, config.log 에서 여러분이 문제가
있다고 생각하는 라인을 복사해서 같이 보내주기 바란다. 또한, 이때 configure의 결과중에 맨 마지막에 있는 라인들도 함
께 보내주기 바란다. 버그 레포트를 보내기 위해서는, Section 1.8, “버그 또는 문제점 레포트 하기”에서 설명하는 방법
을 따르기 바란다.
컴파일에 실패할 경우, Section 2.8.4, “MySQL 컴파일 문제 다루기”에서 도움을 얻기 바란다.
13. 배포판 설치:
14. shell> make install
옵션 파일을 설정하고자 한다면, 템플릿의 형태로서 support-files 디렉토리에 있는 것들 중에 하나를 사용한다. 예를 들

:::MySQL Korea:::
면:
shell> cp support-files/my-medium.cnf /etc/my.cnf
여러분은 루트 사용자로서 이 명령어들을 구동시킬 수 있을 것이다.

InnoDB 테이블을 지원하도록 구성하고자 한다면, /etc/my.cnf 파일을 편집하고, innodb_...와 함께 시작하는 옵션 라인
앞에 있는 #문자를 제거하고, 여러분이 원하는 옵션 값으로 수정을 하면 된다. Section 4.3.2, “옵션 파일 사용하기”,
및 Section 14.2.3, “InnoDB 구성하기”를 참조할 것.
15. 설치 디렉토리로 위치 변경:
16. shell> cd /usr/local/mysql
17. 전에 MySQL을 설치하지 않았다면, 반드시 그랜트 테이블을 만들어야 한다:
18. shell> bin/mysql_install_db --user=mysql
루트 권한으로 명령어를 실행한다면, 위에서 본 것처럼 --user 옵션을 사용해야 한다. 옵션의 값은 여러분이 서버를 구동
시키기 위해 처음 단계에서 생성했던 로그인 계정 이름이 되어야 한다. 그 계정을 사용해서 로그인한 상태라면, --user
옵션을 생략해도 된다.
MySQL그랜트 테이블 생성을 위해 mysql_install_db 를 사용한 후에는, 수동으로 서버를 재 구동시킨다. 이것을 실행하
기 위한 mysqld_safe 명령어는 나중에 설명하기로 한다.
19. 프로그램 바이너리의 소유권(ownership)을 root 로 변경하고 데이터 디렉토리의 소유권을 mysqld 을 구동시키고
있는 사용자로 변경한다. 여러분이 설치 디렉토리(/usr/local/mysql)에 있다면, 명령어는 다음과 같을 것이다:
20. shell> chown -R root .
21. shell> chown -R mysql var
22. shell> chgrp -R mysql .
처음의 명령어는 파일의 소유 속성을 root 사용자로 변경시킨다. 두번째 명령어는 데이터 디렉토리의 소유 속성를
mysql 사용자로 변경 시킨다. 세번째 명령어는 그룹의 속성을 mysql 그룹으로 변경시킨다.

:::MySQL Korea:::
23. 여러분이 시스템을 부팅할 때 자동으로 MySQL을 시작하고자 한다면, support-files/mysql.server 를 여러분의 시
스템 스타트업 파일이 있는 디렉토리고 복사하면 된다. 보다 자세한 정보는 support-files/mysql.server 스크립트 자체
에서 찾을 수 있으며 또한 Section 2.9.2.2, “자동으로 MySQL시작 및 종료하기”에서도 찾을 수 있다.
24. DBI 및 DBD::mysql 펄(Perl) 모듈을 설치하였다면, 여러분은 bin/mysql_setpermission 스크립트를 사용해서 새
로운 계정을 설정할 수 있게 된다. 보다 자세한 정보는 Section 2.13, “Perl 설치 노트”를 참조하기 바란다.
모든 것을 풀어놓고 설치를 한후에는, 설치한 배포판을 시험해 보아야 한다. MySQL서버를 시작하기 위해, 아래의 명령어를 사용
한다:
shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &
만약에 명령어가 곧장 실패를 하고 mysqld ended가 화면에 나오게 되면, 여러분은 데이터 디렉토리에 있는 host_name.err 파일
에서 문제에 대한 정보를 얻을 수 있을 것이다.
mysqld_safe 에 대한 보다 자세한 정보는 Section 5.4.1, “mysqld_safe — MySQL 서버 스타트업 스크립트”에 있다.
Note: MySQL그랜트 테이프블에 있는 계정들은 초기에는 패스워드를 갖고 있지 않다. 서버를 구동시킨 후에는, Section 2.9,
“MySQL 설치후 설정 및 테스트”에서 설명하는 방식으로 각 계정에 대한 패스워드를 설정해야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.8.2. 전형적인 configure 옵션들
2.8. 소스 배포판을 사용해서 MySQL 설치하 configure 스크립트는 여러분이 MySQL소스 배포판을 구성하는데 있어서 매우 효과적으로 제어할 수 있는 방법들을 제공해 준
기 다. 전형적으로는, 여러분은 configure 명령어 라인에서 옵션들을 사용해서 이러한 일을 수행할 수 있게 된다. 또한 특정 환경 변수
2.8.2 전형적인 configure 옵션들 를 사용해서 configure 에 영향을 줄 수도 있다. Appendix F, Environment Variables를 참조할 것. configure 가 지원하는 옵션
리스트는, 이 명령어를 돌려서 얻을 수 있다:
shell> ./configure --help
보다 일반적으로 사용되는 configure 옵션들에 대해 여기에서 설명하기로 하겠다:
● 서버가 아닌 MySQL클라이언트 라이브러리들 및 클라이언트 프로그램들만을 컴파일 하기 위해서는, --without-

server 옵션을 사용한다:
• shell> ./configure --without-server
C++ 컴파일러가 없다면, mysql 은 컴파일 되지 않는다(C++을 필요로 하는 프로그램이 하나 있다). 이와 같은 경우에
는, C++컴파일러를 테스트 하는 configure 안에 있는 코드를 삭제하고 그 다음에 --without-server 를 가지고 ./
configure 를 구동시킨다. 컴파일 단계는 여전히 mysql을 구축하고자 시도할 것이지만, mysql.cc에 대한 에러는 무시할
수 있게 된다(make 가 멈춰지면, make -k 을 시도해서 에러가 발생하더라도 나머지 구축을 진행하도록 명령할 수 있
다.)
● 임베디드MySQL라이브러리를 구축하고자 할 경우에는(libmysqld.a), --with-embedded-server 옵션을 사용한다.

● 로그 파일 및 데이터 베이스 디렉토리가 /usr/local/var의 밑에 있게 하고 싶지 않다면, configure 명령어를 다음의 것 중에
서 하나와 사용한다:

:::MySQL Korea:::
• shell> ./configure --prefix=/usr/local/mysql
• shell> ./configure --prefix=/usr/local ￦
• --localstatedir=/usr/local/mysql/data
첫번째 명령어는 설치 프리픽스(prefix)를 변경시켜서 모든 것이 디폴트/usr/local아래에 설치되는 것이 아니라 /usr/

local/mysql밑에 설치되도록 한다. 두번째 명령어는 디폴트 설치 프리픽스를 보존하고, 그 위치를 데이터베이스 디렉토리
를 위한 것으로 중복 지정한 후(일반적으로 /usr/local/var) 이것을 /usr/local/mysql/data로 변경 시킨다.
여러분은 서버를 구동하는 시점에 MySQL 옵션을 사용해서 그 위치를 지정할 수도 있다. Section 4.3.2, “옵셤 파일 사
용하기”를 참조할 것.
● 여러분이 유닉스를 사용하고 MySQL의 소켓 파일의 위치를 디폴트 위치(일반적으로는 /tmp 또는 /var/run 디렉토리에 있
음)가 아닌 다른 위치로 지정하고자 한다면, configure 명령어를 다음과 같이 사용한다:
• shell> ./configure ￦
• --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock
소켓 파일 이름은 완벽한 경로 이름 이어야 한다. 여러분은 또한 MySQL 옵션 파일을 사용해서 서버 구동시에도 mysql.
sock의 위치를 지정할 수 있다. Section A.4.5, “How to Protect or Change the MySQL Unix Socket File”를 참조
할 것.
● 정적으로 링크된 프로그램(예를 들면, 바이너리 배포판을 만들기 위해, 보다 나은 성능을 위해, 또는 레드햇 리눅스 배포판
에 있는 몇몇 문제점들을 피하기 위해)들을 컴파일 하고자 한다면, configure 을 다음과 같이 실행한다:
• shell> ./configure --with-client-ldflags=-all-static ￦
• --with-mysqld-ldflags=-all-static
● gcc 를 사용하고 libg++ 또는 libstdc++ 가 설치되어 있지 않다면, configure 가 gcc 를 마치 C++ 컴파일러처럼 구동하
도록 할 수 있다:

:::MySQL Korea:::
• shell> CC=gcc CXX=gcc ./configure
gcc 를 C++ 컴파일러로 사용할 때, 이것은 libg++ 또는 libstdc++에 링크를 시도하지 않게 된다. 비록 여러분이 이러
한 라이브러리들을 갖고 있다고 하더라도 이렇게 동작하는 것은 매우 좋은 일이다. 이러한 라이브러리들 의 버전중에 어
떤 것들은 과거에 MySQL사용자에게 이상한 문제를 야기하곤 했었다.
아래의 리스트들은 각각 일상적으로 사용되는 컴파일러들과 환경 변수들의조합을 나타낸다.
❍ gcc 2.7.2:
o CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors"
❍ egcs 1.0.3a:
o CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors ￦
o -fno-exceptions -fno-rtti"
❍ gcc 2.95.2:
o CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro ￦
o -felide-constructors -fno-exceptions -fno-rtti"
❍ pgcc 2.90.29 또는 이후 버전:
o CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc ￦
o CXXFLAGS="-O3 -mpentiumpro -mstack-align-double ￦
o -felide-constructors -fno-exceptions -fno-rtti"
대부분의 경우, 여러분은 위에서 언급한 리스트의 옵션들을 사용하고 아래의 옵션들을 configure 라인에 추가함으로써 보

:::MySQL Korea:::
다 최적화된 MySQL 바이너리를 얻을 수 있게 된다:
전체 configure 라인은, 다른 말로 표현하면, 모든 최신의 gcc 버전에 대해 아래와 같은 형태를 갖게 될 것이다:
CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro ￦
-felide-constructors -fno-exceptions -fno-rtti" ./configure ￦
MySQL 웹사이트(http://dev.mysql.com/downloads/)에서 제공하는 바이너리들은 완벽하게 최적화된 상태에서 컴파일

된 것들이며 대부분의 사용자들에게 올바르게 적용될 수 있을 것이다. Section 2.1.2.5, “MySQL AB사가 컴파일한 바이
너리들”를 참조할 것. 여기에는 바이너리를 보다 개선시킬 수 있는 구성 설정의 여지가 있기는 하지만, 고급 사용자들만
을 위한 부분이다. Section 7.5.4, “How Compiling and Linking Affects the Speed of MySQL”를 참조할 것.
만약에 구축이 실패하고 컴파일러 또는 링커가 공유 라이브러리 libmysqlclient.so.N (N 은 버전 번호임)를 생성하지 못
한다는 에러를 만들게 되면, configure 에 --disable-shared 을 줌으로서 이 문제를 해결할 수 있을 것이다. 이와 같은
경우에, configure는 공유 라이브러리 libmysqlclient.so.N 를 만들지 않게 된다.
● 디폴트로는, MySQL은 latin1 (cp1252 West European) 문자 셋을 사용한다. 디폴트 셋을 변경하고자 하면, --with-
charset 옵션을 사용한다:
• shell> ./configure --with-charset=CHARSET
CHARSET 는 big5, cp1251, cp1257, czech, danish, dec8, dos, euc_kr, gb2312, gbk, german1, hebrew, hp8,
hungarian, koi8_ru, koi8_ukr, latin1, latin2, sjis, swe7, tis620, ujis, usa7, 또는 win1251ukr들 중의 하나가 될 것이
다. Section 5.11.1, “The Character Set Used for Data and Sorting”를 참조할 것.

:::MySQL Korea:::
디폴트 콜레션(collation)도 역시 지정할 수 있다. MySQL은 latin1_swedish_ci 을 디폴트로 사용하고 있다. 이것을 변경
하기 위해서는, --with-collation 옵션을 사용한다:
shell> ./configure --with-collation=COLLATION
문자 셋과 콜레션을 동시에 변경하기 위해서는, --with-charset 및 --with-collation을 모두 같이 사용한다. 콜레션

은 문자 셋에 대해 공식(legal) 콜레션 이어야 한다. (각 문자 셋이 사용할 수 있는 콜레션의 종류를 알아보기 위해서는
SHOW COLLATION 명령문을 사용한다.)
서버와 클라이언트간의 문자 셋을 변환하고자 한다면, SET NAMES 명령문을 배워야 한다. Section 13.5.3, “SET 신
택스”, 및 Section 10.4, “문자 셋과 콜레션(Collations)를 연결하기”를 참조할 것.
Warning: 어떤 테이블이라도 생성을 한 후에 문자 셋을 변경하고자 한다면, myisamchk -r -q --set-
collation=collation_name을 모든 테이블에서 구동시켜야 한다. 그렇지 않으면 여러분의 인덱스들이 부정확하게 정렬
(sorted)될 수가 있다. 이런 경우는, 여러분이 MySQL을 설치하고, 몇몇 테이블들을 생성하고, 그 다음에 MySQL이 다
른 문자 셋을 사용하도록 재 구성하고 재 설치하는 경우에 발생할 수 있다.
configure를 옵션 --with-extra-charsets=LIST와 함께 사용함으로서, 어떤 부가적인 문자 셋이 서버에서 컴파일 되
는지를 명기할 수 있다. LIST 는 아래의 것 중에 하나가 된다:
❍ 스페이스로 구분된 문자 셋 이름중의 하나

❍ 동적으로 로드할 수 없는 모든 문자 셋을 포함하기 위한 위한 complex
❍ 모든 문자 셋을 바이너리안으로 포함시키기 위한 all
● 디버깅 코드와 함께 MySQL을 구성하기 위해서는, --with-debug 옵션을 사용한다:
• shell> ./configure --with-debug
이것은 안전 메모리 할당자(safe memory allocator)가 예상 에러를 포함하도록 만들며 어떤 일이 발생했는지에 대해 알

려 주도록 한다. Section E.1, “Debugging a MySQL Server”를 참조할 것.
● 여러분의 클라이언트 프로그램이 쓰레드를 사용한다면, 여러분은 반드시 --enable-thread-safe-client 구성 옵션을 사

용해서 쓰레드 안전 MySQL클라이언트 버전을 컴파일 해야 한다. 이것은 여러분이 쓰레드 어플리케이션을 링크시켜야 하
는 libmysqlclient_r 라이브러리를 생성한다. Section 22.2.15, “쓰레드 클라이언트 만드는 방법”를 참조할 것.
● MySQL 5.0.4이후에는, MySQL 5.0이 대형 테이블을 지원하도록 --with-big-tables 옵션을 사용하는 것이 가능해졌

:::MySQL Korea:::
다.
이 옵션은 테이블의 줄을 세는데 사용하는 변수가 unsigned long을 사용하지 않고 unsigned long long 을 사용해서 저장
될 수 있도록 한다. 이렇게 함으로써 테이블이 232 (~4.295E+09)의 줄이 아닌 대략 1.844E+19 ((232)2) 정도의 줄을
가질 수 있는 것이 가능하게 된다. 이전에는, 이러한 기능을 할 수 있도록 하기 위해서는 -DBIG_TABLES를 수동으로 컴
파일러에 패스시켜야 했었다.
● 특정 OS에 속한 옵션들은 이 매뉴얼의 시스템-관련 섹션에서 찾을 수 있을 것이다. Section 2.12, “OS-관련 노트”를
참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.8.3. 개발 단계 소스 트리를 가지고 MySQL 설치하기 – SKIP
2.8.3 개발 단계 소스 트리를 가지고 MySQL 설치하기
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.8.4. MySQL 컴파일 문제 다루기
2. MySQL 설치 및 업그레이드 하기 우리의 경우, 솔라리스 또는 gcc 를 사용한 리눅스에서는 아무런 문제없이 모든 MySQL 프로그램을 컴파일 할 수 있었다. 다른 시
2.8. 소스 배포판을 사용해서 MySQL 설치하 스템의 경우, 시스템에 포함된 파일에 따라 서로 다른 경고 메시지를 접할 수도 있을 것이다. Section 2.8.5, “MIT-pthreads 노
기 트”를 참조하면, MIT-pthreads를 사용할 때 발생될 수 있는 경고에 대해 정보를 얻을 수 있을 것이다. 다른 문제에 대해서는, 아
2.8.4 MySQL 컴파일 문제 다루기 래의 리스트를 먼저 살펴 본다.
대부분의 문제에 대해서는 시스템을 재 구성함으로써 해결할 수 있다. 시스템을 재 구성할 필요가 있다면, 아래의 내용을 숙지하기
바란다:
● 만약에 configure이 한번 구동된 후에 다시 구동 한다면, 이전에 구동되었을 때 수집한 정보들을 사용할 것이다. 이 정보들
은 config.cache안에 저장되어 있다. configure 이 실행될 때, configure는 이 파일을 찾게 되고 존재한다면 여기에 포함
된 내용을 읽으며, 이 정보가 여전히 정확하다는 가정을 하게 된다. 이러한 가정은 여러분이 시스템을 재 구성할 경우에는
틀린 정보가 되는 것이다.
● Configure를 구동할 때마다, 여러분은 반드시 make 를 재 구동시켜서 다시 컴파일을 하도록 해야 한다. 하지만, 이전에 구
축한 파일에서 구형 오브젝트 파일들을 삭제하고 싶을 수도 있는데, 왜냐하면 이런 파일들이 다른 구성 옵션을 가지고 컴파
일 되었기 때문이다.
구형 구성 정보 또는 오브젝트 파일이 사용되는 것을 피하기 위해서는, configure 를 재 구동시키기 전에 다음과 같은 명령어를 실

행한다:
shell> rm config.cache
shell> make clean
다른 방법으로는, make distclean를 실행 시킬 수 있다.

:::MySQL Korea:::
다음의 리스트들은 MySQL을 컴파일할 때 자주 접하게 되는 문제들을 설명하는 것이다:
● sql_yacc.cc를 컴파일할 때 여기에서 보는 것과 같은 에러가 발생하면, 아마도 메모리 부족 또는 메모리 스왑 공간 부족이

원인일 것이다:
• Internal compiler error: program cc1plus got fatal signal 11
• Out of virtual memory
• Virtual memory exhausted
문제는 gcc가 인라인(inline)함수들과 함께 sql_yacc.cc를 컴파일 할 때 대용량 메모리를 요구한다는 것이다. configure
를 --with-low-memory 옵션과 함께 사용해서 실행시켜본다:
shell> ./configure --with-low-memory
이 옵션은 여러분이 gcc를 사용할 경우에, -fno-inline를 컴파일 라인에 추가되도록 하며, 다른 것을 사용할 경우에는 -
O0 가 추가되도록 만든다. 만약에 시스템을 구동시키기에 충분한 메모리와 스왑 공간이 없다고 판단 되어 지더라도 --
with-low-memory 을 사용해 보도록 한다. 이 문제는 일반적인 하드웨어 구성의 시스템에서도 발생되는 것으로 알려져
있고, --with-low-memory옵션을 사용해서 수정할 수 있다.
● 디폴트로는, configure는 c++을 컴파일러 이름처럼 인식하며 GNU c++ 은 -lg++과 함께 링크를 한다. 여러분이 gcc
를 사용한다면, 시스템 구성시 아래와 같은 문제가 생기는 원인이 된다:
• configure: error: installation or configuration problem:
• C++ compiler cannot create executables.
또한, 컴파일을 실행하는 동안에 g++, libg++, libstdc++등과 연관된 문제를 만날 수도 있다.
이러한 문제의 원인 중에 하나는 여러분이 g++을 갖고 있지 않거나 또는 g++은 있지만 libg++ 또는 libstdc++이 없
기 때문이다. config.log 파일을 검사해 보기 바란다. 이 파일에는 C++컴파일러가 동작되지 않는 정확한 이유가 있다.
이 문제를 해결하는 방법은, gcc를 C++컴파일러로 사용하는 것이다. 환경 변수 CXX를 "gcc -O3"로 설정해 보도록 하

:::MySQL Korea:::
자. 예를 들면:
shell> CXX="gcc -O3" ./configure
이렇게 하면 gcc가 g++ 뿐만 아니라 C++소스 파일도 컴파일을 하지만 libg++ 또는 libstdc++에 링크는 되지 않기 때
문에 제대로 동작을 하게 된다.
이 문제를 해결하는 또 다른 방법은 g++, libg++, 및 libstdc++를 설치하는 것이다. 하지만, 여러분이 MySQL과 함께
libg++ 또는 libstdc++를 사용하는 것을 권장 하지는 않는데, 그 이유는 어떠한 성능의 효과도 주지 않으면서 mysqld의
바이너리 사이즈만 증가시키기 때문이다.
● 아래와 같은 에러 때문에 컴파일에 실패할 경우, 여러분은 make 버전을GNU make로 업그레이드 해야 한다:
• making all in mit-pthreads
• make: Fatal error in reader: Makefile, line 18:
• Badly formed macro assignment
또는:
make: file `Makefile' line 18: Must be a separator (:
또는:
pthread.h: No such file or directory
솔라리스와 FreeBSD에서는 make 프로그램이 문제가 다소 있다고 알려져 있다.

GNU make 3.75는 문제 없이 잘 동작을 한다.
● 만약에 플래그(flags)를 C 또는 C++ 컴파일러가 사용하도록 정의를 하고자 한다면, 플래그를 CFLAGS 및 CXXFLAGS
환경 변수에 추가하면 된다. 여러분은 또한 CC 와 CXX 를 사용해서 컴파일러의 이름을 이런 방식으로 지정할 수 있다. 예
를 들면:

:::MySQL Korea:::
• shell> CC=gcc
• shell> CFLAGS=-O3
• shell> CXX=gcc
• shell> CXXFLAGS=-O3
• shell> export CC CFLAGS CXX CXXFLAGS
다양한 시스템에서 유용하게 사용 되어지는 플래그 정의 리스트에 대해 보다 많은 정보를 원한다면, Section 2.1.2.5,
“MySQL AB사가 컴파일한 바이너리들”을 참조하기 바란다.
● Mysqld을 컴파일 할 때 여기에 있는 것과 비슷한 에러들이 발생한다면, configure 마지막 인수 타입이 정확하게 accept
(), getsockname(), 또는 getpeername()를 찾지 못한 것이다:
• cxx: Error: mysqld.cc, line 645: In this statement, the referenced
• type of the pointer value ''length'' is ''unsigned long'',
• which is not compatible with ''int''.
• new_sock = accept(sock, (struct sockaddr *)&cAddr, &length);
이 에러를 해결 하기 위해서는, config.h 파일을 편집해야 한다(configure가 만든 파일). 아래의 사항을 살펴 본다:
/* Define as the base type of the last arg to accept */
#define SOCKET_SIZE_TYPE XXX
여러분의 OS에 따라 XXX를 size_t 또는 int로 변경한다.(여러분이configure를 구동 시킬 때마다 config.h가 업데이트되

기 때문에 configure를 구동할 때마다 이 작업을 반복적으로 해 주어야 한다.)

:::MySQL Korea:::
● sql_yacc.cc 파일은 sql_yacc.yy가 만들어 낸다. 일반적으로, MySQL은 초기 작성 복사본(pre-generated copy)를 가지

고 있기 때문에 설치 과정에서는 sql_yacc.cc를 만들지 않는다. 하지만, 여러분이 이것을 재 생성 하고자 한다면, 아래와 같
은 에러를 볼 수 있을 것이다:
• "sql_yacc.yy", line xxx fatal: default action causes potential...
이것은 여러분이 사용하는 yacc버전이 완벽한 버전이 아니라는 것을 의미한다. 여러분은 아마도 bison (yacc의 GNU버
전)을 설치해야 하고 이것을 대신에 사용해야 할 것이다.
● 데비안 리눅스(Debian Linux) 3.0에서, MySQL이 버클리DB를 지원하도록 컴파일하고자 할 경우에는, 디폴트 mawk를
사용하는 대신에 gawk를 설치해야 할 것이다.
● mysqld 또는 MySQL 클라이언트를 디버깅하고자 한다면, configure를 --with-debug 옵션과 함께 구동시키고, 그리고
재 컴파일 한 다음 클라이언트를 새로운 클라이언트 라이브러리와 링크 시킨다. Section E.2, “MySQL 클라이언트 디버
깅”을 참조할 것.
● 리눅스(예를 들면, 수세 리눅스 8.1 또는 레드헷 리눅스 7.3)에서 컴파일 하는 도중에 아래의 것 중에 하나와 비슷한 에러
가 발생한다면:
• libmysql.c:1329: warning: passing arg 5 of `gethostbyname_r' from
• incompatible pointer type
• libmysql.c:1329: too few arguments to function `gethostbyname_r'
• libmysql.c:1329: warning: assignment makes pointer from integer
• without a cast
• make[2]: *** [libmysql.lo] Error 1
디폴트로는, configure 스크립트는 GNU C++컴파일러인 g++를 사용해서 인수의 정확한 숫자를 계산하게 된다. 이 테
스트는 g++이 설치되어 있지 않으면 잘못된 결과를 만들게 된다. 이 문제를 해결하는 두 가지 방법이 있다:

:::MySQL Korea:::
❍ GNU C++컴파일러인 g++를 정확히 설치 한다. 어떤 리눅스 버전에서는, gpp라는 이름으로 불리고 있다;다른 버
전의 경우는, gcc-c++.
❍ CXX 환경 변수를 gcc로 설정 함으로서 gcc를 C++ 컴파일러로 사용하도록 한다.
o export CXX="gcc"
위와 같이 변경을 한 후에는 반드시 configure를 다시 구동 시켜야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.8.5. MIT-pthreads 노트
2.8. 소스 배포판을 사용해서 MySQL 설치하 이 섹션에서는 MIT-pthreads를 사용하는데 있어서의 몇 가지 항목에 대해 설명을 하기로 한다.
기
2.8.5 MIT-pthreads 노트 리눅스에서는, 여러분은 MIT-pthreads를 사용하지 못한다. 대신에 리눅스쓰레드(LinuxThreads)를 구현해서 사용한다.
Section 2.12.1, “리눅스 노트”를 참조할 것.
만약에 여러분의 시스템이 네이티브(native) 쓰레드를 지원하지 않는다면, MIT-pthreads 패키지를 사용해서 MySQL을 설치해
야 한다. 여기에는 구형 FreeBSD 시스템들, SunOS 4.x, Solaris 2.4 및 이전 버전, 그리고 다른 것들이 포함되어 있다.
Section 2.1.1, “MySQL이 지원하는 OS”를 참조할 것.
MIT-pthreads는 MySQL 5.0 소스 배포판에 포함되어 있지 않다. 이 패키지가 필요할 경우에는, 이것만 별도로http://www.
mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz에서 다운 로드 받으면 된다.
다운 로드를 받은 후에, 이 소스 아카이브를 MySQL 소스 디렉토리의 최상위 레벨에 풀어 놓는다. 이렇게 하면 새로운 이름의 서
브 디렉토리인 mit-pthreads가 생성된다.
● 대부분의 시스템의 경우, 여러분은 --with-mit-threads 옵션을 configure 과 함께 사용해서 MIT-pthreads를 사용할
수 있도록 할 수 있다:
• shell> ./configure --with-mit-threads
비-소스(non-source)디렉토리 구축은 이것을 사용할 때 지원되지 않는데, 왜냐하면 우리는 이 코드를 최소한도로 수정
하기를 원하기 때문이다.
● MIT-pthreads를 사용할지 아닐지를 결정하는 것은 서버 코드를 가지고 시스템 구성을 하는 과정에서만 일어난다. 여러분

:::MySQL Korea:::
이 --without-server 옵션을 사용해서 배포판을 클라이언트 코드로만 구축한다고 한다면, 클라이언트는 MIT-
pthreads 사용되고 있는지 아닌지에 대해 알지 못하게 되며 디폴트로 유닉스 소켓 파일 커넥션만을 사용하게 된다. 어떤
시스템에서는 유닉스 소켓 파일이 MIT-pthreads의 상황 아래에서 동작을 하지 않기 때문에, 이것은 여러분이 클라이언
트 프로그램을 구동시킬 때 localhost 의 값을 사용하는 것이 아니라 -h 또는 –host의 값을 필요로 한다는 것을 의미하게
된다.
● MySQL을 MIT-pthreads를 사용해서 컴파일 할 때, 시스템 잠금은 성능의 이유로 인해 디폴트로 비활성화 된다. 여러분
은 서버가 --external-locking 옵션을 가지고 시스템 잠금을 사용할 수 있도록 할 수 있다. 이것은 하나의 동일한 데이
터 파일에 대해 두 대의 MySQL서버를 구동시키고자 할 경우에만 필요하지만, 어쨌든, 우리로서는 권장할 사항은 아니다.
● 때때로 pthread bind() 명령어는 소켓을 어떠한 에러 메시지 없이 묶는데 실패한다 (적어도 솔라이스 상에서는). 모든 커
넥션을 서버에 연결하는 데 실패하는 결과가 생긴다. 예를 들면:
• shell> mysqladmin version
• mysqladmin: connect to server at '' failed;
• error: 'Can't connect to mysql server on localhost (146)'
이 문제를 해결하는 방법은 mysqld 서버를 강제로 종료하고 다시 구동 시키는 것이다.
● MIT-pthreads를 가지고서는, sleep() 시스템 호출은 SIGINT (break)에 인터럽트를 할 수가 없다. 이것은 여러분이
mysqladmin –sleep를 구동할 경우에는 중요한 사항이다. 여러분은 인터럽트가 발생하고 프로세스가 종료하기 전에
sleep()이 종료되기 기다려야만 한다.
● 링크가 되었을 경우, 여러분은 아래와 같은 경고 메시지를 접하게 될수도 있다(적어도 솔라리스에서는); 이런 메시지들은
무시할 수 있다:
• ld: warning: symbol `_iob' has differing sizes:
• (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
• file /usr/lib/libc.so value=0x140);
• /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken

:::MySQL Korea:::
• ld: warning: symbol `__iob' has differing sizes:
• (file /my/local/pthreads/lib/libpthread.a(findfp.o) value=0x4;
• file /usr/lib/libc.so value=0x140);
• /my/local/pthreads/lib/libpthread.a(findfp.o) definition taken
● 다른 경고 메시지도 무시할 수 있다:
• implicit declaration of function ìnt strtoll(...)'
• implicit declaration of function ìnt strtoul(...)'

:::MySQL Korea:::
제목검색
2.8.6. 소스 배포판을 사용해서 윈도우에 MySQL 설치하기
2.8. 소스 배포판을 사용해서 MySQL 설치하기 2.8.6.1. VC++를 사용해서 MySQL구축하기 - SKIP
2.8.6 소스 배포판을 사용해서 윈도우에 MySQL 설치하기 2.8.6.2. 최신 개발 단계 소스를 가지고 윈도우 소스 패키지 만들기 - SKIP
이 설명서는 윈도우에 MSQL 5.0 소스를 가지고 바이너리를 구축하는 방법 대해 설명하고 있다. 이 설명서는 표준 배포판
또는 BitKeeper트리에서 최신 개발 소스를 사용해서 바이너리를 구축하는 방법에 대해 설명하고 있다.
Note: 여기에서 설명하는 방법은 가장 최신의 소스 배포판 또는 비트키퍼 트리에서 MySQL 소스를 다운 로드해서 윈도우
에서 테스트를 하고자 하는 사용자들만을 위한 것이다. 따라서, MySQL AB사는 여러분 스스로가 MySQL을 혼자 설치하
는 것을 권장하지 않는다. 일반적으로는, MySQL AB사가 미리 컴파일하고 윈도우에 최적화를 시켜 놓은 바이너리 배포판
을 사용하는 것이 최선의 방법이다. 바이너리 배포판 설치에 관한 내용은 Section 2.3, “윈도우에 MySQL 설치하기”에
서 찾아볼 수 있다
윈도우에 MySQL을 소스를 사용해서 설치하기 위해서는, 아래의 컴파일러와 사용 가능한 시스템 자원이 필요하게 된다:
● Visual Studio 2003 컴파일러 시스템(VC++ 7.0).

● 3GB 에서 5GB 사이의 디스크 공간.
● Windows 2000 또는 이상 버전.
정확한 시스템 요구 사항은 여기에서 볼 수 있다: http://msdn.microsoft.com/vstudio/productinfo/sysreqs/default.

aspx
윈도우를 위한 MySQL 소스 배포판도 필요하다. 소스 배포판은 두 가지 방법으로 얻을 수가 있다:
1. MySQL AB사에서 소스 배포판 패키지를 다운 로드 한다. http://dev.mysql.com/downloads/.

:::MySQL Korea:::
2. 여러분 스스로 최신의 비트키퍼 개발자 트리에서 패키지를 다운로드할 수 있다. 이 방법을 사용할 경우에는,
유닉스상에서 패키지를 생성해야 하며 그 다음에 이것을 윈도우로 전송해야 한다.( 몇가지 구성 및 구축 단계에서
는 유닉스에서만 동작하는 툴을 요구하게 된다.) 따라서, 비트키퍼는 다음을 요구하게 된다:
• 유닉스 또는 리눅스와 같은 유사 유닉스가 구동되는 시스템.
• 이 시스템 설치된 비트키퍼 3.0. Section 2.8.3, “개발 단계 소스 트리로부터 설치”에서 비트키퍼
다운 로드 및 설치 방법을 참조하기 바란다.
여러분이 윈도우 소스 배포판을 사용한다면, Section 2.8.6.1, “VC++을 사용해서 MySQL 구축하기” 섹션으로 직접 이
동하기 바란다. 비트키퍼 트리에서 구축으로 하기 위해서는, Section 2.8.6.2, “최신의 개발 단계 소스에서 윈도우 소스 패
키지 생성하기”로 가기 바란다.

:::MySQL Korea:::
제목검색
2.8.7. 윈도우에서 MySQL 클라이언트 컴파일 하기
2.8.7 윈도우에서 MySQL 클라이언트 컴파일 하기 여러분의 소스 파일에서는, 반드시my_global.h를 mysql.h 전에 포함(include)시켜야 한다:
#include <my_global.h>
#include <mysql.h>
my_global.h는 여러분이 윈도우에서 프로그램을 컴파일할 때 윈도위와 호환성을 유지하기 위한 여러가지의 파일들(windows.h
와 같은 파일)이 포함되어 있다.
여러분은 또한 소스 코드를 동적으로 libmysql.lib 라이브러리와 연결할 수 있는데, 이것은 필요에 따라 libmysql.dll 에 집어 넣
을 수 있거나, 또는 정적(static) mysqlclient.lib 라이브러리와 연결 시킬 수 있는 단순한 래퍼(wrapper)이다.
MySQL 클라이언트 라이브러리들은 쓰레드된(threaded) 라이브러리처럼 컴파일 되며, 따라서 여러분의 코드도 역시 멀티 쓰레
드(multi-threaded)가 되도록 컴파일해야 한다.
:::MySQL Korea:::
제목검색
2.9. MySQL설치 후 설정 및 테스트
2.9. MySQL설치 후 설정 및 테스트 2.9.1. 윈도우에서 MySQL 설치후 해야 할 과정

2.9 MySQL설치 후 설정 및 테스트 2.9.2. 유닉스에서 MySQL설치후 해야 할 과정
2.9.1 윈도우에서 MySQL설치후 해야 할 과정 2.9.3. 초기 MySQL계정에 대한 보안 작업
2.9.2 유닉스에서 MySQL설치후 해야 할 과정

2.9.2.1 mysql_install_db 구동상의 문제점들 MySQL을 설치한 후에는, 몇 가지 사항에 대해 여러분이 처리해야 할 것들이 있다. 예를 들면, 유닉스에서는, 여러분은 데이터 디
렉토리를 초기화 해야 하고 MySQL 그랜트 테이블을 생성해야 한다. 모든 플랫폼에서, 보안 관점에서 보는 중요한 사항중의 하나
2.9.2.2 자동으로 MySQL 을 시작하기 및 종료하기
가 바로 그랜트 테이블에 있는 초기 게정들이 패스워드가 없다는 점이다. 여러분은 권한이 없는 사용자들이 MySQL서버에 접근하
2.9.2.3 MySQL 서버 시작하기와 문제점 해결 하기
는 것을 방지하기 위해 패스워드를 지정해 주어야 한다. 옵션 사항으로는, 타임존 테이블을 만들어서 명명된 타임존이 인식되도록
해줄 수도 있다.
이 다음에 나오는 섹션에서는 MySQL서버를 설치한 다음에 윈도우 시스템 및 유닉스 시스템에서 해야 할 과정들에 대해 설명을
하기로 한다. 다른 섹션인 Section 2.9.2.3, “MySQL서버 시작 및 문제점 해결”에서는 모든 플랫폼에 적용되는 사항에 대해 언
급할 것이다; 여기에서는 서버를 시작할 때 발생하는 문제를 해결하는 방법을 설명한다. Section 2.9.3, “초기 MySQL계정에 대
한 보안 작업”의 내용 역시 모든 플랫폼에 적용된다. 여러분은 여기에서 설명하는 지침을 정확히 따라 함으로서 MySQL계정에
올바르게 패스워드를 설정하도록 하여야 한다.
여러분이 추가적인 계정을 생성할 준비가 되어졌다면, 여러분은 MySQL접근 제어 시스템 및 계정 관리에 대한 정보를
Section 5.8, “MySQL 접근 권한 시스템”, 및 Section 5.9, “MySQL 사용자 계정 관리”에서 얻을 수 있게 될 것이다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.9.1. 윈도우에서 MySQL설치후 해야 할 과정
2.9. MySQL설치 후 설정 및 테스트 윈도우에서는, 데이터 디렉토리와 그랜트 테이블은 생성 되어도 상관이 없다. MySQL 윈도우 배포판에는 데이터 디렉토리 아래에
2.9.1 윈도우에서 MySQL설치후 해야 할 과정 있는 mysql 데이터 베이스에는 초기화되어 있는(preinitialized) 계정 셋이 그랜트 테이블과 함께 제공된다. 유닉스에서 사용하는
mysql_install_db 스크립트를 구동시킬 필요가 없다. 패스워드에 관련해서는, 만약에 MySQL을 윈도우 설치 마법사를 사용해서
설치한다면, 여러분은 아마도 이미 각 계정에 패스워드를 할당하였을 것이다. (Section 2.3.3, “MySQL 설치 마법사 사용하
기”를 참조할 것.) 그렇지 않다면, Section 2.9.3, “초기 MySQL계정에 대한 보안 작업”에서 제공하고 있는 패스워드-할당 과
정을 사용하기 바란다.
패스워드를 설정하기 전에, 여러분이 서버에 제대로 연결되고 있고 서버가 올바르게 동작하고 있는지 확인하기 위해 클라이언트 프
로그램을 그동시켜 보고 싶을 것이다. 서버가 제대로 구동되는지 확인을 한 다음에 ( Section 2.3.9, “서버를 처음으로 구동 시키
기”를 참조), 아래의 명령어를 입력하여 여러분이 서버에서 정보를 제대로 불러올 수 있는지 확인한다. 그 결과값은 아래에 있는
것과 비슷할 것이다:
C:￦> C:￦mysql￦bin￦mysqlshow
+-----------+
| Databases |
+-----------+
| mysql |
| test |

:::MySQL Korea:::
+-----------+
C:￦> C:￦mysql￦bin￦mysqlshow mysql
Database: mysql
+---------------------------+
| Tables |
+---------------------------+
| columns_priv |
| db |
| func |
| help_category |
| help_keyword |
| help_relation |
| help_topic |
| host |
| proc |

:::MySQL Korea:::
| procs_priv |
| tables_priv |
| time_zone |
| time_zone_leap_second |
| time_zone_name |
| time_zone_transition |
| time_zone_transition_type |
| user |
+---------------------------+
C:￦> C:￦mysql￦bin￦mysql -e "SELECT Host,Db,User FROM db" mysql
+------+-------+------+
| host | db | user |
+------+-------+------+
|% | test% | |
+------+-------+------+
서비스가 지원되는 윈도우 버전을 구동시키고 있고 윈도우가 시작될 때 자동으로 MySQL서버가 구동되도록 만들고 싶다면,

:::MySQL Korea:::
Section 2.3.11, “윈도우 서비스 형태로 MySQL 시작하기”를 참조하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.9.2. 유닉스에서 MySQL설치후 해야 할 과정
2. MySQL 설치 및 업그레이드 하기 2.9.2.1. mysql_install_db 구동상의 문제점들

2.9. MySQL설치 후 설정 및 테스트 2.9.2.2. 자동으로 MySQL 구동 시키기 및 종료시키기
2.9.2 유닉스에서 MySQL설치후 해야 할 과정 2.9.2.3. MySQL 구동하기 및 문제 해결 하기

유닉스에서 MySQL을 설치한 후에는, 여러분은 그랜트 테이블을 초기화 시키고, 서버를 구동하고, 또한 서버가 만족스럽게 동작하
2.9.2.2 자동으로 MySQL 을 시작하기 및 종료하
기 고 있는지 확인할 필요가 있다. 또한, 여러분이 시스템을 구동하고 마칠 때 MySQL서버가 자동으로 구동을 하고 종료하게끔 조정
2.9.2.3 MySQL 서버 시작하기와 문제점 해결 하 을 하고 싶을 수도 있을 것이다. 여러분은 또한 그랜트 테이블에 패스워드를 활당해 주어야 한다.
기
유닉스에서는, 그랜트 테이블은 mysql_install_db 프로그램에 의해 설정 된다. 어떤 설치 방식에서는, 이 프로그램이 자동으로 실
행되기도 한다:
● 리눅스에 RPM배포판을 가지고 MySQL을 설치할 경우, 서버 RPM은 mysql_install_db를 구동 시킨다.

● Mac OS X에 PKG 배포판을 사용해서 설치할 경우에는, 설치기가 mysql_install_db를 구동 시킨다.
그렇지 않으면, 여러분 스스로가 mysql_install_db를 구동 시켜야 한다.
아래의 과정은 그랜트 테이블(만약에 아직 초기화를 하지 않았다면)을 초기화 시키고 그 다음에 서버를 구동시키는 방법에 대해 설
명을 하고 있다. 또한, 몇 가지 명령어를 제공해 주는데, 이 명령어들을 사용해서 여러분은 서버가 접근 가능한지 그리고 제대로 작
동을 하고 있는지에 대한 테스트를 진행할 수 있게 된다. 자동으로 서버를 구동시키고 종료시키는 것에 대한 정보는
Section 2.9.2.2, “자동으로 MySQL서버를 구동 시키기 및 종료 시키기”를 참조하기 바란다.
이 과정을 모두 마치고 서버가 구동된 후에는, mysql_install_db가 생성한 계정에 대해 패스워드를 할당애 주어야 한다. 이렇게 하
는 방법에 대해서는 Section 2.9.3, “초기 MySQL 계정에 보안 설정하기”에서 설명하기로 한다.
여기에 있는 예제에서는, 서버가 mysql 로그인 계정의 사용자 ID에서 동작을 하고 있다. 이것은 그러한 계정이 있다는 가정을 하

:::MySQL Korea:::
게 된다. 만약에 없다면 계정을 생성하거나, 또는 여러분이 서버에서 사용할 예정인 다른 존재하는 계정의 이름을 대신 사용하면 된
다.
1. 여러분이 설치한 MySQL의 최상위 디렉토리로 이동한다. 여기에서는BASEDIR로 표현한다:
2. shell> cd BASEDIR
BASEDIR는 /usr/local/mysql 또는 /usr/local과 비슷한 것들이다. 이 다음 단계는 여러분이 이 디렉토리에 있다고 가정

을 한다.
3. 필요하다면, mysql_install_db 프로그램을 구동시켜서 사용자들이 서버에 연결되는 권한을 갖는 그랜트 테이블을 초
기화 시키도록 한다. 설치 과정에서 자동으로 이것을 실행시키지 않는 배포판을 사용할 경우에는 이 과정을 진행할 필요
가 있다.
전형적으로, mysql_install_db는 여러분이 처음으로 MySQL을 설치할 때에만 동작시키면 되므로, 기존의 버전을 업그레
이드할 경우에는 이 과정을 진행하지 않아도 된다. 하지만, mysql_install_db는 기존에 있는 어떠한 권한도 겹쳐 쓰지
(overwrite) 않기 때문에, 어떤 환경에서도 안전하게 다루어져야 한다.
그랜트 테이블을 초기화 하기 위해서는, mysql_install_db이 bin 또는 scripts 디렉토리에 있는지에 따라 아래의 명령어중
에 하나를 사용한다:
shell> scripts/mysql_install_db --user=mysql
mysql_install_db 스크립트는 서버의 데이터 디렉토리를 생성한다. 데이터디렉토리 안에서는, 이것은 모든 데이터 베이스
의 권한과 여러분이 MySQL을 테스트할 때 사용하는 test 데이터 베이스를 갖고 있는 mysql 데이터 베이스를 위한 디렉
토리를 만들게 된다. 이 스크립트는 또한 root 계정과 익명 사용자 계정을 위한 권한 테이블 엔트리를 생성한다. 이들에 대
한 초기 권한에 대한 상세 내용은 Section 2.9.3, “초기 MySQL 계정에 대한 보안 작업 하기”에서 제공하기로 한다. 간
략히 말해서, 이러한 권한들은 MySQL root 사용자가 어떠한 일들도 할 수 있게 해주며, 또한 누구라도 test 또는 test_
라는 이름의 데이터 베이스를 생성하거나 사용할 수 있도록 해 준다.
mysql 로그인 계정이 데이터 베이스 디렉토리 및 파일들을 소유하게 함으로써 나중에 여러분이 서버를 구동시킬 때 서버
가 이것들을 접근해서 읽고 쓸 수 있도록 해주는 것은 매우 중요한 사항이다. 이렇게 하도록 하기 위해서는, --user 옵션
은 여러분이 mysql_install_db를 구동시킬 경우에 root에서 보여준 것처럼 사용되어야 한다. 그렇지 않으면, mysql로 로

:::MySQL Korea:::
그인 하는 동안 스크립트를 실행시켜야 하는데, 이럴 경우에는 --user 옵션을 명령어에서 생략할 수 있다.

mysql_install_db는 mysql 데이터 베이스 안에 여러 개의 테이블을 생성하는데, 여기에는 user, db, host, tables_priv,
columns_priv, 및 func등이 다른 것들과 함께 포함된다. Section 5.8, “MySQL 접근 권한 시스템”에서 이러한 테이블
의 전체 리스트 및 상세 설명을 하기로 한다.
여러분이 test 데이터 베이스를 갖고 싶지 않다면, 서버를 구동 시킨 다음에 mysqladmin -u root drop test를 실행 시켜
서 이것을 삭제하면 된다.
이 시점에 mysql_install_db에서 문제가 발생된다면, Section 2.9.2.1, “mysql_install_db 구동상의 문제점들”을 참조
하기 바란다.
4. MySQL 서버를 구동 시킨다:
5. shell> bin/mysqld_safe --user=mysql &
MySQL 서버는 루트가 아닌(non-root) 로그인 계정으로 구동 되어야 한다는 점이 중요하다. 이것을 확실하게 하기 위
해, --user 옵션은 여러분이 mysql_safe 을 구동한다면 시스템 root에서 볼 수 있는 형태로 사용 되어야 한다. 그렇지
않으면, 그렇지 않으면, mysql로 로그인 하는 동안 스크립트를 실행시켜야 하는데, 이럴 경우에는 --user 옵션을 명령어
에서 생략할 수 있다.
권한이 없는 사용자로서 MySQL을 구동시키는 것에 대한 보다 자세한 정보는 Section 5.7.5, “일반 사용자로 MySQL
구동 시키기”에서 다루기로 한다.
이 과정을 진행하기 전에 그랜트 테이블을 생성하는 것을 잊었다면, 여러분이 서버를 시작할 때 에러 로그 파일에서 다음
과 같은 메시지를 볼 수 있을 것이다:
mysqld: Can't find file: 'host.frm'
서버를 구동 시키는데 또 다른 문제가 있을 경우에는, Section 2.9.2.3, “MySQL서버 구동 시키기 및 문제 해결하

기”를 참조하기 바란다.
6. mysqladmin를 사용해서 서버가 구동되는지 검사한다. 아래의 명령어들은 서버가 제대로 올라와서 연결되어 있는지
에 대해 간단하게 테스트 하는 방법을 알려주는 것이다:
7. shell> bin/mysqladmin version
8. shell> bin/mysqladmin variables

:::MySQL Korea:::
mysqladmin version을 통해서 나오는 결과는 여러분이 사용하는 플랫폼과 MySQL버전에 따라 약간의 차이가 있으나,
여기에서 보여주는 것들과 매우 흡사한 형태를 띄게 된다:
shell> bin/mysqladmin version
mysqladmin Ver 14.12 Distrib 5.0.19, for pc-linux-gnu on i686
Copyright (C) 2000 MySQL AB & MySQL Finland AB & TCX DataKonsult AB
This software comes with ABSOLUTELY NO WARRANTY. This is free software,
and you are welcome to modify and redistribute it under the GPL license
Server version 5.0.19-Max
Protocol version 10
Connection Localhost via UNIX socket
UNIX socket /var/lib/mysql/mysql.sock
Uptime: 14 days 5 hours 5 min 21 sec
Threads: 1 Questions: 366 Slow queries: 0
Opens: 0 Flush tables: 1 Open tables: 19
Queries per second avg: 0.000

:::MySQL Korea:::
mysqladmin을 가지고 여러분이 할 수 있는 일이 무엇인지를 보기 위해서는 --help을 함께 사용하면 된다.

9. 서버를 제대로 셧다운 시켰는지 검증한다:
10. shell> bin/mysqladmin -u root shutdown
11. 서버를 다시 구동 시킬 수 있는지 검증한다. mysqld_safe를 사용하거나 또는 mysqld 를 직접 호출해서 이 작업을

실행한다. 예를 들면:
12. shell> bin/mysqld_safe --user=mysql --log &
만약에 mysqld_safe이 실패하면, Section 2.9.2.3, “MySQL서버 구동 시키기 및 문제 해결하기”를 참조하기 바란다.
13. 여러분이 서버에서 정보를 불러올 수 있는지 검증하기 위해 간단한 테스트를 진행한다. 결과 값은 아래와 비슷할 것
이다:
14. shell> bin/mysqlshow
15. +-----------+
16. | Databases |
17. +-----------+
18. | mysql |
19. | test |
20. +-----------+
21.
22. shell> bin/mysqlshow mysql

:::MySQL Korea:::
23. Database: mysql
24. +---------------------------+
25. | Tables |
26. +---------------------------+
27. | columns_priv |
28. | db |
29. | func |
30. | help_category |
31. | help_keyword |
32. | help_relation |
33. | help_topic |
34. | host |
35. | proc |
36. | procs_priv |
37. | tables_priv |
38. | time_zone |

:::MySQL Korea:::
39. | time_zone_leap_second |
40. | time_zone_name |
41. | time_zone_transition |
42. | time_zone_transition_type |
43. | user |
44. +---------------------------+
45.
46. shell> bin/mysql -e "SELECT Host,Db,User FROM db" mysql
47. &nbs

:::MySQL Korea:::
제목검색
2.9.2.1. mysql_install_db 구동상의 문제점들

2.9. MySQL설치 후 설정 및 테스트 mysql_install_db 스크립트의 목적은 새로운 MySQL 권한 테이블을 만드는 것이다. 이것은 기존의 권한 테이블에 겹쳐 쓰기를 하
2.9.2 유닉스에서 MySQL설치후 해야 할 과정 지 않고, 다른 어떤 데이터에도 영향을 미치지 않는다.

여러분의 권한 테이블을 재 생성하고자 할 경우에는, 동작중인mysqld 서버가 있다면 우선 이것을 종료시켜야 한다. 그 다음에는 데
기 이터 디렉토리 밑에 있는 mysql 디렉토리의 이름을 바꿔서 저장한 다음에 mysql_install_db를 구동시킨다. 현재 여러분이 있는 디
렉토리는 MySQL 설치 디렉토리이며 mysql_install_db는 bin 디렉토리에 있고 데이터 디렉토리의 이름은data라고 가정한다.
2.9.2.3 MySQL 서버 시작하기와 문제점 해결 하
기 mysql 데이터베이스의 이름을 변경하고 mysql_install_db를 재 구동 시키기 위해서, 다음의 명령어를 사용한다:
shell> mv data/mysql data/mysql.old
mysql_install_db를 구동시킬 때, 다음과 같은 문제가 일어날 수도 있다:
● mysql_install_db fails to install the grant tables
여러분은 mysql_install_db가 그랜트 테이블을 설치하는데 실패하고 아래의 메시지가 화면에 나타난 다음에 시스템이 종
료되는 것을 볼 수 있을 것이다:
Starting mysqld daemon with databases from XXXXXX
mysqld ended
이와 같은 경우에는, 여러분은 에러 로그 파일을 매우 주의 깊게 살펴 보아야 한다. 로그는 XXXXXX라는 이름의 디렉토리

:::MySQL Korea:::
에 있게 되며 mysqld이 구동되지 못한 이유를 나열해 놓을 것이다. 무슨 이유로 구동이 되지 않았는지 이해할 수가 없다

면, 여러분이 버그를 보고할 때 함께 첨부해서 보내기 바란다.
● There is a mysqld process running
이것은 서버가 지금 구동중임을 나타내며, 이와 같은 경우에는 그랜트 테이블이 이미 생성되어 있을 것이다. 만약에 생성
이 되어 있다면, mysql_install_db을 구동 시킬 필요가 전혀 없는데, 왜냐하면 이것은 MySQL을 설치할 때 한번만 실행시
키면 되는 것이기 때문이다.
● Installing a second mysqld server does not work when one server is running
위의 메시지는 여러분이 이미 MySQL을 설치하였지만, 다른 위치에 새롭게설치를 하고자 하는 경우에 발생한다. 예를 들

면, 여러분이 MySQL제품판을 가지고 설치를 하였는데, 테스트 목적으로 두번째 설치를 하고자 하는 경우를 말한다. 일반
적으로 두번째 서버를 구동시키고자 시도할 때 발생하는 문제점은 이미 첫 번째 서버가 사용중에 있는 네트웍크 인터페이
스를 두 번째 서버가 사용하고자 시도한다는 것이다. 이와 같은 상황에서는, 아래와 같은 에러 메시지를 보게 될 것이다:
Can't start server: Bind on TCP/IP port:
Address already in use
Can't start server: Bind on unix socket...
다중 서버 설정에 대한 자세한 정보는, Section 5.13, “동일 머신에서 다중의 MySQL서버 구동 시키기”를 참조하기 바
란다.
● You do not have write access to the /tmp directory
여러분이 디폴트 위치(/tmp 디렉토리)에 임시 파일 또는 유닉스 소켓 파일을 생성하기 위한 쓰기 권한을 갖고 있지 않을

경우에는, mysql_install_db 또는 mysqld 서버를 구동 시킬 때 에러가 발생한다.
여러분은 mysql_install_db 또는 mysqld를 시작하기 전에 아래의 명령어를 실행 시켜서 임시 파일과 유닉스 소켓 파일
을 다른 디렉토리로 지정할 수 있는데, 여기에서 some_tmp_dir 는 여러분이 지정하는 곳의 전체 경로 이름이 된다:

:::MySQL Korea:::
shell> TMPDIR=/some_tmp_dir/
shell> MYSQL_UNIX_PORT=/some_tmp_dir/mysql.sock
shell> export TMPDIR MYSQL_UNIX_PORT
그 다음에는 mysql_install_db를 구동 시키고 서버를 아래의 명령어로 시작할 수 있다:
만약에 mysql_install_db이 scripts 디렉토리에 있다면, 첫 번째 명령어를 scripts/mysql_install_db로 수정한다.

Section A.4.5, “How to Protect or Change the MySQL Unix Socket File”, 및 Appendix F, Environment
Variables.를 참조할 것
MySQL배포판에는 mysql_install_db 스크립트를 구동시키는 여러가지 다른 방법들을 제공한다:
● 만약에 표준 디폴트에서 제공하는 것과 다른 초기 권한을 갖고 싶다면, mysql_install_db를 구동하기 전에 수정할 수 있

다. 하지만, 권한 변경은 그랜트 테이블을 설정한 다음에 GRANT 및 REVOKE를 사용해서 하는 것이 더 자주 사용되는 방
법이다. 다른 말로 표현 하자면, 여러분은 mysql_install_db을 구동 시키고, 그 다음에 mysql -u root mysql를 사용해서
MySQL root 사용자로서 서버에 접속함으로써 필요한 GRANT와 REVOKE 명령문을 실행한다.
여러대의 머신에 동일한 권한을 가진 MySQL를 설치하고자 한다면, GRANT 와 REVOKE 명령문을 하나의 파일에 넣고
mysql_install_db을 실행한 후에 이 파일을 mysql를 사용하는 스크립트 형태로 실행 시킨다. 예를 들면:
shell> bin/mysql -u root < your_script_file
이렇게 함으로써, 각 머신에 수동으로 명령문을 입력하는 수고를 피할 수있다.

:::MySQL Korea:::
● 그랜트 테이블이 생성된 후에 그 테이블을 다시 생성시키는 것은 언제든지 가능하다. 여러분은 GRANT와 REVOKE를 사
용하는 방법을 배운 후에는 이렇게 하길 원할 수도 있으며 mysql_install_db를 구동 시킨 다음에 테이블의 내용을 모두 없
애고 새로 시작하는 다양한 수정을 진행할 수 있을 것이다.
그랜트 테이블을 다시 생성하기 위해서는, mysql 디렉토리에 있는 모든.frm, .MYI, 및 .MYD 파일을 없애야 한다. 그런 다음
에 mysql_install_db 스크립트를 다시 구동 시킨다.
● 여러분은 --skip-grant-tables 옵션을 사용해서 수동으로 mysqld 을 구동 시킬 수 있고 mysql을 사용해서 권한에 대

한 정보를 추가할 수도 있다:
• shell> bin/mysqld_safe --user=mysql --skip-grant-tables &
• shell> bin/mysql mysql
mysql로부터, mysql_install_db안에 들어 있는 SQL 명령어를 수동으로실행한다.. 서버가 그랜트 테이블을 다시 가져온

후에 반드시 mysqladmin flush-privileges 또는 mysqladmin reload를 실행시켜야 하는 것을 알기 바란다.
mysql_install_db를 사용하지 않음으로써, 여러분은 수동으로 그랜트 테이블을 작성해야 하는 것뿐만 아니라, 맨 처음에
이것들을 생성해야 한다는 점을 주의하기 바란다.

:::MySQL Korea:::
제목검색
2.9.2.2. 자동으로 MySQL 을 시작하기 및 종료하기

2.9. MySQL설치 후 설정 및 테스트 일반적으로, 아래의 방법중에 하나를 가지고 mysqld 서버를 구동 시킬수 있다:
2.9.2 유닉스에서 MySQL설치후 해야 할 과정

● 직접 mysqld을 호출한다. 이 방법은 모든 플랫폼에서 실행된다.
● 윈도우 서비스 형태로MySQL 서버를 구동 시킨다. 이 방법은 서비스를 지원하는 윈도우 버전(NT, 2000, XP, 및 2003
기 등)에서 실행할 수 있다. 이 서비스는 윈도우가 실행될 때 자동으로 MySQL서버를 구동 시키거나, 또는 수동으로 원하는
시기에 서버를 구동할 수 있게 한다. 실행 방법에 대해서는, Section 2.3.11, “윈도우 서비스 형태로 MySQL 서버 시작
기 하기”를 참조하기 바란다.
● mysqld_safe 호출을 하면, 이것은 mysqld 을 위한 적당한 옵션을 찾게 되며 이 옵션들을 이용해서 서버를 구동 시킨다.
이 스크립트는 유닉스 및 유닉스 유사(Unix-like) 시스템에서 사용된다. Section 5.4.1, “mysqld_safe — MySQL 서버
스타트업(Startup)스크립트”.
● mysql.server를 호출한다. 이 스크립트는 시스템 V-스타일(System V-style) 구동 디렉토리를 사용하는 시스템에서 시
스템을 스타트업과 셧다운 시킬 때 주로 사용되는데, 이것은 mysql 밑에 설치되어 있다. mysql.server 스크립트는
mysqld_safe를 호출해서 서버를 구동 시킨다. Section 5.4.2, “mysql.server — MySQL 서버 스타트업 스크립트”를
참조할 것.
● Mac OS X에서는, 별도의MySQL 스타트업 아이템 패키지를 설치해서 시스템이 구동될 때 자동적으로 MySQL의 스타트
업이 진행되도록 할 수 있다. 스타트업 아이템은 mysql.server을 호출해서 서버를 구동 시킨다. Section 2.5,
“Installing MySQL on Mac OS X”에서 보다 자세한 내용을 알아보기 바란다.
mysqld_safe, mysql.server 스크립트 및 Mac OS X 스타트업 아이템은 서버를 수동으로 구동시킬 수도 있으며, 또는 시스템 스
타트업 시간에 자동으로 서버를 실행시킬 수도 있다. mysql.server 및 스타트업 아이템은 또한 서버를 종료시키는데에도 사용할
수 있다.
mysql.server 스크립트를 사용해서 서버를 수동으로 시작 및 종료하기 위해서는, start 또는 stop 인수를 함께 사용해서 호출한

:::MySQL Korea:::
다:
shell> mysql.server start
shell> mysql.server stop
mysql.server 는 서버를 구동하기 전에, 디렉토리를 MySQL 설치 디렉토리로 이동 하고 mysqld_safe를 호출하게 된다. 만약에
서버가 특정 사용자로서 구동되도록 하고자 한다면, 적당한 user 옵션을 /etc/my.cnf 옵션 파일의 [mysqld] 그룹에 추가한다(이
섹션 후반부에서 예를 보여줌). (여러분이 MySQL바이너리 배포판을 비 표준 위치에 설치하였다면, mysql.server를 편집할 필요
가 있을 것이다. 서버가 mysqld_safe를 구동 시키기 전에 cd 를 적당한 디렉토리안에 넣도록 서버를 수정한다. 이렇게 한다면, 여
러분이 수정한 mysql.server 버전은 나중에 업그레이드를 할 경우에 덮어 씌워지게 될 것이며, 따라서 나중에 이것을 가지고 재 설
치할 수 있도록 편집한 버전을 잘 복사해두어야 한다.)
mysql.server stop은 서버에 신호를 보내서 종료를 시킨다. 또한 여러분은 mysqladmin shutdown를 실행 시켜서 수동으로 서버
를 종료 시킬 수도 있다.
자동으로 MySQL서버를 시작 및 종료 시키기 위해서는, 여러분의 /etc/rc* 파일내 적당한 위치에 시작 및 종료 명령어를 추가해야
한다.
리눅스 서버 RPm패키지(MySQL-server-VERSION.rpm)를 사용한다면, mysql.server 스크립트는 /etc/init.d 디렉토리안에

mysql 이름을 가지고 저장된다. 여러분은 이것을 수동으로 설치할 필요는 없다. 보다 자세한 정보는 Section 2.4, “리눅스에
MySQL 설치하기”를 참조하기 바란다.
어떤 제조사들은 mysqld 과 같은 별도의 이름을 가진 디렉토리에 스타트업 스크립트를 설치하는 RPM 패키지를 제공하기도 한다.
mysql.server를 자동으로 설치하지 않는 소스 배포판 또는 바이너리 배포판 포맷을 사용해서 MySQL을 설치할 경우에는, 수동으
로 이것을 설치할 수 있다. 이 스크립트는 MySQL설치 디렉토리 또는 소스 트리안에 있는 support-files 디렉토리에서 찾을 수
있다.
mysql.server를 수동으로 설치하기 위해서는, 이것을 /etc/init.d 에 mysql이름을 가지고 복사를 한 다음, 이를 실행시킨다.
mysql.server 가 있는 적당한 디렉토리로 이동을 한 다음에 아래의 명령어를 실행한다:

:::MySQL Korea:::
shell> cp mysql.server /etc/init.d/mysql
shell> chmod +x /etc/init.d/mysql
구형의 레드헷 시스템들은 /etc/init.d가 아닌 /etc/rc.d/init.d 디렉토리를 사용하였다. 위의 명령어에서 이것을 수정한다. 다른 방
법으로는, 우선 /etc/init.d 를 /etc/rc.d/init.d를 가리키는 심볼릭 링크로 만드는 것이다:
shell> cd /etc
shell> ln -s rc.d/init.d .
스크립트를 설치한 후에는, 여러분이 사용하는 OS에 따라 시스템 스타트업 시점에 구동시켜야 하는 명령어들이 틀려지게 된다. 리
눅스에서는, chkconfig를 사용할 수 있을 것이다:
shell> chkconfig --add mysql
어떤 리눅스 시스템에서는, mysql 스크립트를 완벽하게 활성화 시키기 위해서 아래의 명령어가 추가로 필요할 수도 있다:
shell> chkconfig --level 345 mysql on
FreeBSD버전에서는, 스타트업 스크립트는 일반적으로 /usr/local/etc/rc.d/ 디렉토리 안으로 들어가게 된다. rc(8) 사용 설명서
에서는 이 디렉토리안에 있는 스크립트들은 베이스네임(basename)이 *.sh 쉘 파일이름 패턴과 일치할 경우에만 실행된다고 설명
하고 있다. 이 디렉토리안에 있는 다른 파일들 또는 디렉토리들은 무시해도 되는 것들이다. 다시 말해서, FreeBSD에서는, mysql.
server 스크립트를 /usr/local/etc/rc.d/mysql.server.sh 로 설치해서 자동 스타트업을 실행해야 한다.
위의 설정에 대한 다른 방법으로, 어떤 OS시스템들은 /etc/rc.local 또는 /etc/init.d/boot.local를 사용해서 스타트업시에 부가적

인 서비스를 시작하도록 하기도 한다. 이 방법으로 MySQL 를 구동시키기 위해서는, 아래와 같은 명령어를 스타트업 파일에 첨가
해야 한다:
/bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'
다른 시스템에 대해서는, OS 설명서에서 스타트업 스크립트를 설치하는 방법을 찾아보기 바란다.

:::MySQL Korea:::
mysql.server를 위한 옵션은 글로벌 /etc/my.cnf 파일에 추가할 수 있다. 전형적인 /etc/my.cnf 파일은 아래와 같이 보이게 된
다:
[mysqld]
datadir=/usr/local/mysql/var
socket=/var/tmp/mysql.sock
port=3306
user=mysql
[mysql.server]
basedir=/usr/local/mysql
mysql.server 스크립트는 다음의 옵션들을 수용한다: basedir, datadir, 및 pid-file. 만약에 이러한 옵션들이 지정이 되면, 이것들
은 반드시 옵션 파일안에 있어야 한다(명령어 라인이 아님). mysql.server가 명령어 라인에서 받아들이는 인수는 start와 stop밖
에 없다.
아래의 테이블은 서버와 스타트업 스크립트가 옵션 파일에서 읽어올 수 있는 옵션 그룹의 종류를 나타낸다:
Script Option Groups
mysqld [mysqld], [server], [mysqld-major_version]
mysqld_safe [mysqld], [server], [mysqld_safe]
mysql.server [mysqld], [mysql.server], [server]

:::MySQL Korea:::
[mysqld-major_version]는 [mysqld-4.1] 및 [mysqld-5.0]과 같은 이름의 그룹들은 버전 4.1.x, 5.0.x, 및 이후 버전의 서버

가 읽을 수 있음을 의미한다. 이 특징은 주어진 릴리즈 시리즈에 속한 서버들만 읽을 수 있도록 옵션을 지정하는데 사용된다.
이전 버전들과의 호환성을 위해서, mysql.server는 [mysql_server] 그룹도 읽을 수 있으며 mysqld_safe는 [safe_mysqld] 그룹

도 읽을 수 있다. 하지만, 5.0버전을 사용할 때 [mysql.server] 및 [mysqld_safe] 그룹을 사용하기 위해서는 여러분의 옵션 파일
을 업데이트 시켜야 한다.
Section 4.3.2, “옵션 파일 사용하기”를 참조할 것.

:::MySQL Korea:::
제목검색
2.9.2.3. MySQL 서버 시작하기와 문제점 해결 하기

2.9. MySQL설치 후 설정 및 테스트 이 섹션에서는 유닉스에서 서버를 구동 시킬 때 발생되는 문제에 대해 해결하는 방법을 제시한다. 여러분이 윈도우를 사용하고 있
2.9.2 유닉스에서 MySQL설치후 해야 할 과정 다면, Section 2.3.13, “윈도우에서 MySQL설치하는데 발생하는 문제점 해결”를 참조하기 바란다.

여러분이 서버를 구동하는데 있어서 문제가 발생한다면, 여기에 있는 것들을 시도해 보기 바란다:
기
● 에러 로그를 분석해서 서버가 구동되지 않는 이유를 알아본다.
● 여러분이 사용하고 있는 스토리지 엔진에 필요한 옵션을 지정한다.
기
● 서버가 데이터 디렉토리의 위치를 제대로 찾고 있는지 확인한다.
● 서버가 데이터 디렉토리에 접근할 수 있는지 확인한다. 데이터 디렉토리의 소유권과 사용 권한 및 컨텐츠들은 서버가 읽고
수정할 수 있도록 설정되어 있어야 한다.
● 서버가 사용하게 될 네트웍크 인터페이스가 사용 가능한 상태인지 점검한다.
어떤 스토리지 엔진들은 동작을 제어하는 옵션들을 가지고 있다. 여러분은 my.cnf 파일을 생성해서 사용하고자 하는 엔진을 위한
스타트업 옵션을 지정할 수 있다. 만약에 트랜잭션 테이블((InnoDB, BDB, NDB)을 지원하는 스토리지 엔진을 사용할 예정이라
면, 서버를 구동시키기 전에 여러분이 원하는 형태로 스토리지 엔진을 구성해 두어야 한다:
● InnoDB 테이블을 사용한다면, Section 14.2.3, “InnoDB 구성”을 참조.

● BDB (Berkeley DB) 테이블을 사용한다면, Section 14.5.3, “BDB 스타트업 옵션들”을 참조.
● MySQL 클러스터를 사용한다면, Section 15.4, “MySQL 클러스터 구성”을 참조.
스토리지 엔진은 여러분이 특별히 지정을 하지 않으면 디폴트 옵션 값을 사용하지만, 여러분이 사용 가능한 옵션의 내용을 검토하
고 디폴트 옵션이 여러분이 원하는 설치에 적합하지 않을 경우에 반드시 사용해야 할 값을 지정할 것을 권장한다.
mysqld 서버가 구동을 할 때, 이것은 위치를 데이터 디렉토리로 변경을 한다. 여기에 데이터 베이스가 있고 로그 파일을 여기에 작

:::MySQL Korea:::
성하고자 하는 것이다. 서버는 또한 이 디렉토리에 pid (process ID) 파일을 작성한다.
데이터 디렉토리의 위치는 서버가 컴파일될 때 고정 되어진다. 그 위치는 서버가 디폴트로 데이터 디렉토리를 찾게 되는 곳이다. 만
약에 데이터 디렉토리가 다른 곳이 있다고 한다면, 서버는 올바른 동작을 하지 못하게 된다. 여러분은 mysqld을 --verbose 및
--help 옵션과 함께 사용해서 호출함으로서 디폴트 경로 설정이 무엇인지를 알아볼 수 있다.
디폴트 위치가 MySQL설치 레이 아웃과 일치하지 않으면, 여러분은 명령어 라인 또는 옵션 파일에서 mysqld 또는 mysqld_safe
에 옵션을 지정해서 우선권을 설정할 수 있다.
데이터 디렉토리의 위치를 확정적으로 지정하기 위해서는, --datadir 옵션을 사용한다. 하지만, 일반적으로는 MySQL이 설치되
어 있는 디렉토리 하부에 있는 베이스 디렉토리를 mysqld에게 알려 주고 그곳에서 데이터 디렉토리를 찾도록 하면 된다. 여러분
은 이것은 --basedir 옵션을 사용해서 진행할 수 있다.
경로 옵션 지정의 효과를 체크하기 위해, mysqld를 --verbose 과 --help 옵션을 함께 호출해 본다. 예를 들면, mysqld이 설치
되어 있는 디렉토리로 위치를 변경하고 그곳에서 아래의 명령어를 실행하고자 한다면, 서버 구동의 효과는 /usr/local의 베이스 디
렉토리와 함께 보여진다.
shell> ./mysqld --basedir=/usr/local --verbose --help
여러분은 –datadir와 같은 옵션도 지정할 수 있으나, --verbose 및 --help 옵션은 맨 나중에 사용해야 한다는 점을 알아두기
바란디.
일단 여러분이 경로 설정에 대해 결정을 하였다면, --verbose 와 –help 옵션이 없는 상태로 서버를 구동시켜본다.
만약에 mysqld이 현재 동작 중이라면, 여러분은 아래의 명령어를 사용해서 지금 mysqld이 사용중에 있는 경로가 어떤 것인지 알
아낼 수 있다:
shell> mysqladmin variables
또는:
shell> mysqladmin -h host_name variables

:::MySQL Korea:::
host_name은 MySQL서버 호스트의 이름이다.
Mysqld을 시작할 때 Errcode 13 (Permission denied를 의미함)이 발생한다면, 이것은 서버가 데이터 디렉토리 또는 그 컨텐츠
에 접속할 권한이 없음을 의미하는 것이다. 이와 같은 경우에는, 데이터 디렉토리 및 그 안에 있는 파일에 대한 접근 허가
(permission)를 변경시켜서 서버가 제데로 접속할 수 있도록 해야 한다. 여러분은 root의 권한으로 서버를 구동시킬 수도 있으나,
이것은 보안 문제를 야기시키기 때문에 이 방법은 피해야 한다.
유닉스에서는, 데이터 디렉토리로 위치를 변경하고 데이터 디렉토리와 그 안에 있는 파일의 소유권을 체크해서 서버가 접근할 수
있는지를 확인해야 한다. 예를 들면, 데이터 디렉토리가 /usr/local/mysql/var라면, 아래의 명령어를 사용한다:
shell> ls -la /usr/local/mysql/var
데이터 디렉토리 또는 그 안에 있는 파일 또는 서브 디렉토리가 서버 구동시 로그인 한 계정의 것이 아니라면, 우선 그 계정의 것으

로 소유권을 변경한다. 계정의 이름이mysql이라면, 다음의 명령어를 사용한다:
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql/var
서버가 제대로 구동되지 않으면, 에러 로그를 분석한다. 로그 파일은 데이터 디렉토리 안에 있다(전형적으로, 윈도우에서는 C:
￦Program Files￦MySQL￦MySQL Server 5.0￦data에 있고, 유닉스 바이너리 배포판은 /usr/local/mysql/data에 있으며, 그
리고 유닉스 소스 배포판은 /usr/local/var에 있다). 데이터 디렉토리에서 host_name.err 및 host_name.log 형태의 이름을 가진
파일을 찾아본다. host_name 은 서버 호스트의 이름이다. 그 다음에 이 파일의 맨 마지막 몇 줄을 검사해 본다. 유닉스에서는, tail
을 사용해서 이 라인들을 볼 수 있다:
shell> tail host_name.err
shell> tail host_name.log
이 에러 로그에는 서버가 제대로 구동되지 않은 이유가 적혀 있다. 예를 들면, 로그 파일에서 아래와 비슷한 내용을 볼 수 있을 것이
다:

:::MySQL Korea:::
000729 14:50:10 bdb: Recovery function for LSN 1 27595 failed
000729 14:50:10 bdb: warning: ./test/t1.db: No such file or directory
000729 14:50:10 Can't init databases
이것은 여러분이 mysqld을 --bdb-no-recover 옵션과 함께 구동 시키지 않았다는 것을 의미하며 버클리 DB(Berkeley DB)
는 데이터 베이스를 복구하고자 시도할 때 자체의 로그 파일에 무엇인가 문제가 있다는 점을 발견했음을 알려주는 것이다. 계속 진
행을 하기 위해서는, 데이터 디렉토리에 있는 구형 버클리 DB를 다른 곳으로 이동을 시켜야 하며, 그곳에서 나중에 분석을 하면 된
다. BDB 로그 파일은 log.0000000001로 시작해서 순차적으로 명명 되어지고, 번호는 시간이 지나면서 증가하게 된다.
mysqld이BDB 테이블을 지원하면서 구동 되어지고 mysqld이 스타트업 때 코어를 덤프(dump)한다면, 이것은 BDB 복구 로그가
갖고 있는 문제점 때문이다. 이와 같은 경우에는, mysqld을 --bdb-no-recover 옵션을 가지고 시도해 본다. 이것이 도움이 된다
면, 데이터 디렉토리에서 모든 BDB 로그 파일을 삭제하고 다시 한번 mysqld을 --bdb-no-recover 옵션 없이 구동시켜 본다.
아래의 에러 로그중에 하나라도 다시 나타나면, mysqld이 사용하고자 하는 TCP/IP포트 또는 유닉스 소켓 파일을 다른 프로그램
(아마도 다른 mysqld) 이 사용하고 있음을 의미하는 것이다:
Can't start server: Bind on TCP/IP port: Address already in use
Can't start server: Bind on unix socket...
ps를 사용해서 다른 mysqld 이 현재 동작되고 있는지 확인해 본다. 만약에 있다면, mysqld 을 다시 구동 시키기 전에 서버를 셧다
운 시킨다. (만약에 다른 서버가 구동 중이라면, 그리고 다중 서버를 구동시켜야 한다면, Section 5.13, “동일 머신에서 다중
MySQL 서버를 구동 시키기”에서 그에 대한 방법을 알아보기 바란다.)
구동 중에 있는 다른 서버가 없다면, telnet your_host_name tcp_ip_port_number 명령어를 실행 시켜 본다. (디폴트 MySQL 포

트는 3306이다.) 그 다음에 엔터키를 여러 번 눌러 본다. 만약에 telnet: Unable to connect to remote host: Connection
refused과 같은 에러 메시지를 보지 못한다면, mysqld이 사용하고자 하는 TCP/IP포트를 다른 프로그램이 사용하고 있는 것이다.
이 프로그램이 무엇인지 계속 찾아본 다음에 이것을 비활성화 시키거나, 또는 mysqld 을 --port 옵션과 함께 실행해서 사용 가능
한 다른 포트가 있는지를 확인해 본다. 이와 같은 경우에는, TCP/IP를 통해 서버에 접속할 때 클라이언트용 포트도 함께 지정해 주

:::MySQL Korea:::
어야 한다.
여러분이 방화벽을 사용하고 있을 경우에도 서버가 포트에 접속을 하지 못하게 된다. 만약에 이러한 경우라면, 방화벽 설정을 변경
하여 포트에 접속할 수 있도록 한다.
서버는 구동 되지만 여기에 접속을 할 수 없을 경우에는, 여러분이 아래와 같이 보이는 /etc/hosts의 엔트리에 포함되어 있는지 다
시 한번 확인해 본다:
127.0.0.1 localhost
이 문제는 시스템이 동작중인 쓰레드 라이브러리가 없을 경우에만 발생되는데, 그 이유는 MySQL은 반드시 MIT-pthreads를 사
용해서 구성되어지기 때문이다.
여러분이 구동시킬 수 있는 mysqld을 가져 올 수 없다면, --debug 옵션을 사용해서 문제를 찾아보기 위한 추적 파일(trace file)
을 만들어 본다. Section E.1.2, “추적 파일(Trace Files) 생성하기”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.9.3. 초기 MySQL 계정에 보안 작업하기
2.9. MySQL설치 후 설정 및 테스트 MySQL 설치 과정에는 그랜트 테이블을 갖는 mysql 데이터베이스를 설정하는 부분이 있다:

● 윈도우 배포판에는 처음부터 초기화 되어 있는(preinitialized) 그랜트 테이블이 존재하며 자동으로 설치된다.
● 유닉스에서는, 그랜트 테이블은 mysql_install_db를 통해서 작성되어진다. 이것을 구동 시키는 방법은 여러 가지가 있다.
어떤 것들은 여러분이 직접 수동으로 설치해야 하는 것도 있다. 보다 자세한 사항은 Section 2.9.2, “유닉스 설치후 과
정”을 참조하기 바란다.
그랜트 테이블은 초기 MySQL 사용자 계정과 접근 권한을 정의한다. 이 계정들은 아래와 같이 설정한다:
● root 이름을 갖는 계정이 생성된다. 이것은 모든 업무를 할 수 있는 슈퍼유저(superuser) 계정이다. 초기root 계정 패스워
드는 비어 있으며, 따라서 누구라도 MySQL 서버에 root — 패스워드 없이 — 로 접속할 수 있으며 모든 권한을 갖게 된
다.
❍ 윈도우에서는, 한 개의 root 계정이 생성된다; 이 계정은 로컬 호스트에서만 접근에 허용된다. 윈도우 설치기는
MySQL을 설치할 때 옵션 사항으로 사용자가 리모트 머신에 있는 어떤 호스트로도 접속이 가능하게끔 root 계정
을 활성화 시킬 수 있다.
❍ 유닉스에서는, 로컬 호스트에서 접속하기 위해서 두 개의 root 계정이 모두 사용된다. 하나의 계정에 대해서는
localhost 의 호스트 이름을, 또는 다른 계정에 대해서는 실제 호스트 이름 또는 IP 번호를 지정함으로써 로컬 호스
트로부터 접속이 이루어져야 한다.
● 두 개의 익명 사용자 계정이 생성되고, 각자는 사용자 이름이 비어 있는 상태로 만들어 진다. 익명 사용자 계정은 패스워드
가 없으며, 따라서 누구라도 이 계정을 사용해서 MySQL서버에 접속할 수 있다.
❍ 윈도우 시스템에서는, 하나의 익명 사용자 계정이 로컬 호스트를 통해 접속이 이루어진다. 이 계정은 root 계정과
같이 모든 권한을 가지고 있다. 나머지 계정 하나는 다른 호스트로부터의 접속을 위한 것이며 test 데이터 베이스
및 test로 시작되는 다른 데이터 베이스를 위한 모든 권한을 가지고 있다.

:::MySQL Korea:::
❍ 유닉스에서는, 두 개 모두가 로컬 호스트에서 접속을 하기 위한 것으로 사용된다. 하나의 계정에 대해서는

localhost 의 호스트 이름을, 또는 다른 계정에 대해서는 실제 호스트 이름 또는 IP 번호를 지정함으로써 로컬 호스
트로부터 접속이 이루어져야 한다. 이 계정들은 test 데이터 베이스 및 test_로 시작되는 다른 데이터 베이스를 위
한 모든 권한을 가지고 있다.
위에서 보았듯이, 초기 계정 중에 어떤 것도 패스워드를 갖고 있지 않다. 이것은 여러분이 MySQL을 설치할 때 이에 대한 보안 작

업을 하기 전까지 보호를 받지 못한다는 것을 의미한다:
● 만약에 익명의 사용자가 패스워드 없이 클라이언트에 접속하는 것을 막고자 한다면, 각 익명 사용자 계정에 패스워드를 할
당하거나, 또는 익명 사용자 계정을 삭제해야 한다.
● 각 MySQL root 계정에 패스워드를 할당한다.
아래에서는 초기 MySQL계정에 패스워드를 할당하는 방법에 대해 설명을 하기로 하는데, 우선 익명 사용자 계정 설정 방법을 설명
하고 다음에 root 계정에 관한 방법을 설명하기로 한다. 아래의 예제에 있는“newpwd”를 여러분이 원하는 것으로 바꾼다. 이 설
명서는 익명 사용자 계정을 삭제하는 방법에 대해서도 설명을 하는데, 이렇게 하면 익명 사용자 계정을 가지고는 절대로 서버에 접
속을 할 수 없게 된다.
여러분은 패스워드 설정을 나중에 하고 싶을 수도 있는데, 이렇게 하면 추가적인 설정 또는 테스트를 진행하는 동안 패스워드를 지
정하지 않아도 된다. 하지만, 상용 제품을 설치하고 실제 사용하기 전에는 반드시 해야 한다.
익명 사용자 계정에 패스워드를 할당하기 위해서는, root로 서버에 접속을 한 다음에 SET PASSWORD 또는 UPDATE를 실행한
다. 어느 경우에서든지, PASSWORD() 함수를 사용해서 패스워드를 암호화 하도록 한다.
윈도우에서 SET PASSWORD를 사용하기 위해서는, 다음과 같이 실행한다:
shell> mysql -u root
mysql> SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR ''@'%' = PASSWORD('newpwd');
유닉스에서는 다음과 같이 SET PASSWORD를 사용한다:

:::MySQL Korea:::
mysql> SET PASSWORD FOR ''@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR ''@'host_name' = PASSWORD('newpwd');
두 번째 SET PASSWORD 명령문에서, host_name 을 서버 호스트 이름으로 변경한다. 이것은 user 테이블에 있는 root에 대한
non-localhost 레코드의 Host 컬럼에 지정되어 있는 이름이다. 만약에 호스트 이름이 무엇인지 모를 경우에는, SET
PASSWORD를 실행하기 전에 아래의 명령어를 입력한다:
mysql> SELECT Host, User FROM mysql.user;
Host 컬럼에 있는 localhost가 아니고 User 컬럼과 다른 것에서 root를 가지고 있는 레코드를 살펴본다. 그 다음에 두 번째 SET
PASSWORD에서 그 Host 값을 사용한다.
익명 사용자 계정에 패스워드를 할당하는 다른 방법은 UPDATE를 사용해서 user 테이블을 직접 수정하는 것이다. Root로 서버
에 접속을 한 다음에 UPDATE 명령문을 입력하여 적당한 user 테이블 레코드의 Password 컬럼에 값을 할당한다. 이 과정은 윈도
우와 유닉스에서 모두 동일하다. 아래의 UPDATE 명령문은 하나의 패스워드를 두 개의 익명 계정에 동시에 할당해 준다:
mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd')
-> WHERE User = '';
mysql> FLUSH PRIVILEGES;
UPDATE를 사용해서 user 테이블에 직접 패스워드를 갱신한 다음에는, 서버가 FLUSH PRIVILEGES를 통해 그랜트 테이블을
다시 읽어 오도록 해야 한다. 그렇게 하지 않으면, 여러분이 서버를 재 구동 시키기 전까지 서버는 갱신된 내용을 알지 못하게 된
다.

:::MySQL Korea:::
대신에 익명 사용자 계정을 삭제하고자 한다면, 아래의 명령을 실행한다:
mysql> DELETE FROM mysql.user WHERE User = '';
DELETE 명령문은 윈도우와 유닉시에 모두 적용된다. 윈도우에서, 만약에 root 권한과 똑 같은 권한을 갖고 있는 익명 계정만 삭
제하고자 한다면, 아래를 대신 실행한다:
mysql> DELETE FROM mysql.user WHERE Host='localhost' AND User='';
이 계정은 익명의 사용자가 전체 권한을 갖고 있기 때문에, 이것을 삭제하면 보안성이 개선되는 것이다..
root 계정에 패스워드를 할당하는 방법은 여러 가지가 있다. 아래에서는 세 가지 방법에 대해 보여 주기로 한다:
● SET PASSWORD 명령문을 사용한다

● mysqladmin 명령어 라인 클라이언트 프로그램을 사용한다
● UPDATE 명령문을 사용한다
SET PASSWORD를 사용해서 패스워드를 할당하기 위해서는, root로 서버에 접속을 한 다음에 두개의 SET PASSWORD 명령문
을 입력한다. PASSWORD() 함수를 사용해서 패스워드를 암호화 하도록 한다.
윈도우에서는 아래와 같이 한다:

:::MySQL Korea:::
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR 'root'@'%' = PASSWORD('newpwd');
유닉스에서는 다음과 같다:
mysql> SET PASSWORD FOR 'root'@'localhost' = PASSWORD('newpwd');
mysql> SET PASSWORD FOR 'root'@'host_name' = PASSWORD('newpwd');
두 번째 SET PASSWORD 명령문에서, host_name를 서버 호스트 이름으로 바꾼다. 이것은 익명 계정의 패스워드를 할당할 때 사
용한 이름과 똑 같은 이름이다.
mysqladmin를 사용해서 root 패스워드를 할당하기 위해서는, 다음의 명령문을 실행한다:
shell> mysqladmin -u root password "newpwd"
shell> mysqladmin -u root -h host_name password "newpwd"
이 명령문들은 윈도우와 유닉스에서 모두 적용 된다. 두 번째 명령에서, host_name를 서버 호스트 이름으로 바꾼다. 패스워드를 감
싸고 있는 이중 인용 부호는 항상 필요한 것은 아니지만, 패스워드가 스페이스를 가지고 있거나 또는 명령어 해석기가 특수 문자로
해석하는 문자를 포함하고 있을 때에는 반드시 사용해야 한다.
UPDATE를 사용해서 user 테이블을 직접 수정할 수도 있다. 아래의 UPDATE 명령문은 하나의 패스워드를 두 개의 root 계정 모
두에 동시에 할당한다:
mysql> UPDATE mysql.user SET Password = PASSWORD('newpwd')

:::MySQL Korea:::
-> WHERE User = 'root';
UPDATE 명령문은 윈도우와 유닉스에 모두 적용된다.
패스워드를 설정한 다음에는, 서버에 접속할 때마다 패스워드를 입력해야 한다. 예를 들면, 만약에 서버를 셧다운 시키기 위해
mysqladmin를 사용하고자 한다면, 아래의 명령어를 사용해서 실행할 수 있다:
shell> mysqladmin -u root -p shutdown
Enter password: (enter root password here)
Note: 패스워드 설정 후에 root 패스워드를 잊어 버렸다면, Section A.4.1, “How to Reset the Root Password”을 참조해서
root 패스워드를 재 설정하기 바란다.
다른 계정들에 대한 설정은, GRANT 명령문을 사용하면 된다. 사용 설명은 Section 5.9.2, “새로운 계정을 MySQL에 추가 하
기”을 참조하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.10. MySQL 업그레이드 하기
2. MySQL 설치 및 업그레이드 하기 2.10.1. MySQL 5.0에서 업그레이드 하기

2.10. MySQL 업그레이드 하기 2.10.2. MySQL 4.1에서 5.0으로 업그레이드 하기
2.10 MySQL 업그레이드 하기 2.10.3. MySQL 데이터베이스를 다른 머신으로 복사하기
2.10.1 MySQL 5.0에서 업그레이드 하기 일반적인 규칙에 따라서, 하나의 릴리즈 시리즈에서 다른 시리즈로 업그레이드를 할 경우에, 시리즈를 건너 띄기 보다는 바로 다
2.10.2 MySQL 4.1에서 5.0으로 업그레이드 하기 음의 시리즈로 업그레이드할 것을 권장한다. 예를 들면, 여러분이 현재 MySQL 3.23을 사용하고 있고 새로운 시리즈로 업그레
2.10.3 MySQL 데이터 베이스를 다른 머신으로 복사 이드를 하고자 한다면, u4.1 또는 5.0으로 곧장 하지 말고 4.0으로 업그레이드를 하도록 한다.
하기 아래의 사항들은 여러분이 업그레이드를 할 때마다 검사해야 하는 체크 리스트 항목들이다:
● MySQL4.1에서 5.0으로 업그레이드를 하기 전에, Section 2.10.2, “MySQL 4.1에서 5.0으로 업그레이드 하기”) 뿐
만 아니라 Appendix D, MySQL Change History도 읽기 바란다. 여기에는 MySQL5.0에 포함되어 있는 새로운 기능
들 또는 4.1과의 차이점에 대한 내용이 들어있다. 4.1 이전 버전에서 4.1 버전으로 업그레이드를 하고자 한다면, 현재
사용 버전에서부터 차례대로 업그레이들 실행해서 4.1 버전까지 진행하도록 해야 하며, 그 다음에 5.0 버전으로 업그레
이드를 실행해야 한다. 4.1 버전 또는 그 이전 버전에서 업그레이드에 대한 보다 자세한 정보는 MySQL 3.23, 4.0, 4.1
Reference Manual을 참조하기 바란다.
● 업그레이드를 하기 전에, 그랜트 테이블을 갖고 있는 mysql 데이터 베이스를 포함해서 모든 데이터 베이스를 백업 받아
두기 바란다.
● MySQL 버전중에 어떤 것은 그랜트 테이블에 새로운 권한 또는 기능들을 추가 하기 위해 그 구조를 변경시킨다. 새로
운 버전으로 업그레이드를 할 때마다, 그랜트 테이블을 갱신시켜서 해당 업그레이드 버전이 갖고 있는 새로운 기능을 항
상 그랜트 테이블이 갖고 있도록 해야 한다. Section 5.6.1, “mysql_fix_privilege_tables — 업그레이드 MySQL 시
스템 테이블”을 참조할 것.
● 윈도우에서 MySQL 서버를 구동시킨다면, Section 2.3.14, “윈도우에서 MySQL 업그레이드 하기”를 참조할 것.
● 리플리케이션을 사용하고 있다면, Section 6.6, “리플리케이션 설정 업그레이드 하기”를 참조하여 보다 자세한 정보
를 얻기 바란다.
● mysqld-max라는 이름의 서버가 포함된 MySQL-Max배포판을 전에 설치 하였고, 그리고 나중에 MySQL의 non-

:::MySQL Korea:::
Max버전으로 업그레이드를 하였다면, mysqld_safe는 여전히 예전 mysqld-max 서버를 구동시키고자 한다. 만약에
이러한 업그레이드를 한다면, 수동으로 예전 mysqld-max 서버를 삭제해서 mysqld_safe 서버가 새로운 mysqld 서버
를 실행하게끔 해주어야 한다.
동일한 MySQL릴리즈 시리즈 버전내에서 업그레이드를 한다면 MySQL포맷 파일과 데이터 파일을 서로 다른 버전간에 언제든
지 이동 시킬 수 있다. MySQL을 구동 시킬 때 문자 셋을 변경하고자 한다면, 모든 MyISAM 테이블에서 myisamchk -r -q
--set-collation=collation_name을 실행시켜야 한다. 그렇지 않으면, 인덱스를 올바르게 순서화하지 못할 수 있는데, 왜냐하
면 문자 셋 변경은 정렬 순서까지도 변경 시키기 때문이다.
여러분이 새로운 버전을 사용한 것에 대해 염려가 된다면, 새로운 버전을 설치하기 전에 예전 mysqld의 이름을 변경시켜 놓을
수 있다. 예를 들면, 여러분이 지금 MySQL 4.1.13 을 사용하고 있고 5.0.10으로 업그레이드를 하고 싶다면, 현재의 서버를
mysqld에서 mysqld-4.1.13로 변경시켜 놓는다. 그런 후에 만약에 새로운 mysqld에 예상하지 못한 문제가 생긴다면, 간단히
이것을 셧다운 시킨 다음에 예전 mysqld를 재 실행시키면 된다.
업그레이드를 한 후에, 클라이언트를 재 컴파일 하는데 있어서 문제가 발생한다면, 예를 들면 Commands out of sync 또는 예
상하지 못한 코어 덤프, 여러분이 프로그램을 컴파일할 때 아직도 예전 헤더(header) 또는 라이브러리 파일들을 사용하고 있는
것이다. 이와 같은 경우에, 우선 mysql.h 파일과 libmysqlclient.a 의 생성 날짜를 검사해서 이것들이 새로운 MySQL이 생성한
것들인지 확인을 한다. 그렇지 않다면, 프로그램을 새로운 해더와 라이브러리를 가지고 컴파일 한다..
새로운 mysqld 서버를 구동할 수 없다거나 패스워드 없이 접속하는 것이 불가능하다는 것과 같은 문제가 발생하면, 예전 설치
때 만들어진 my.cnf 파일이 있는지 확인해 본다. 이것은 --print-defaults 옵션을 사용해서 확인할 수 있다(예를 들면,
mysqld --print-defaults). 이 명령어를 실행한 후에 프로그램 이름 이외의 것이 화면에 나타난다면, 서버와 클라이언트의 실
행에 영향을 미치는 my.cnf 파일이 존재하는 것이다.
MySQL의 새로운 릴리즈를 설치할 때마다 펄(Perl) DBD::mysql 모듈을 재 설치하고 재 구축하는 것은 좋은 생각이다. PHP
mysql 확자자 및 Python MySQLdb 모듈과 같은 다른 MySQL 인터페이스에 대해서도 똑 같은 작업을 하는 것이 좋다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.10.1. MySQL 5.0에서 업그레이드 하기
2.10. MySQL 업그레이드 하기 5.0에서 5.0.10 또는 그 이상 버전으로 업그레이드를 할 때에는, 그랜트 테이블을 업그레이드 하는 것이 필요하다는 것을 알아두
2.10.1 MySQL 5.0에서 업그레이드 하기 기 바란다. 그렇지 않으면, 스토어드 프로시저 및 함수의 생성이 진행되지 않는다. Section 5.6.1, “mysql_fix_privilege_tables
— 업그레이드 MySQL 시스템 테이블”을 참조할 것.
:::MySQL Korea:::
제목검색
상위메뉴리 2.10.2. MySQL 4.1에서 5.0으로 업그레이드 하기

스트 ◆
2. MySQL Note: 새로운 소프트웨어 버전으로 업그레이드를 하기 전에 데이터를 백업 받아 두는 것은 좋은 습관이다. 비록 MySQL이 최고 수준의 성능을 보장한다고 하더라도, 여러분은 스스로 데이터를
설치 및 업 백업하여 데이터의 안전을 보장해야 한다. MySQL은 5.0 이전 버전에서 5.0으로 업그레이드 하기 위해 테이블을 덤프하여 재 로드(re-load)하는 것을 권장한다.
그레이드 하
기
일반적으로, 4.1에서 5.0으로 업그레이드를 할 때 아래의 과정을 진행해야 한다:
2.10.
MySQL 업 ● 이 섹션 후반에서 보게 되는 변경 리스트(change list)에 있는 항목(items)을 검사해서 그 중에 어떤 것이 여러분의 어플리케이션에 영향을 줄 수 있는지 확인한다. 특히Incompatible
그레이드 하
change라고 되어 있는 부분을 주목한다. 이러한 것들은 예전 MySQL 버전과의 비호환성(incompatibilities)을 야기하며, 이로 인해 여러분은 업그레이드를 하기 전에 무엇인가를 해야
기
만 하게 된다.
2.10.2 MySQL
● MySQL 5.0 변경 디렉토리를 읽음으로써5.0에서 사용할 수 있는 중요한 새로운 기능들을 알아 본다. Section D.1, “Changes in release 5.0.x (Production)”를 참조할 것.
4.1에서
● 윈도우에서 MySQL 서버를 구동시킨다면, Section 2.3.14, “윈도우에서 MySQL 업그레이드 하기”를 참조할 것. 윈도우 MySQL서버중에 두 개의 이름이 변경된다는 점도 역시 알아
5.0으로
업그레 두기 바란다. Section 2.3.8, “MySQL 서버 타입 선택하기”를 참조할 것.
이드 하 ● MySQL 5.0은 스토어드 프로시저에 대한 지원을 추가 하였다. 이러한 지원은 mysql 데이터 베이스 안에 proc 테이블을 필요로 한다.
기 ● MySQL 5.0은 뷰(view)를 지원한다. 이 지원은 mysql 데이터 베이스에서 user와 db 테이블에 추가적인 권한 컬럼들을 요구하게 된다. 이러한 컬럼들을 만들기 위해서는,
Section 5.6.1, “mysql_fix_privilege_tables — 업그레이드 MySQL 시스템 테이블”에서 설명하는 방식으로 mysql_fix_privilege_tables 스크립트를 구동 시켜야 한다.
● 리플리케이션을 사용하고 있다면, Section 6.6, “리플리케이션 설정 업그레이드 하기”를 참조하여 여러분의 리플리케이션을 업그레이드 하기 바란다.
MySQL 4.1이 5.0으로 업그레이드 되면서 표준 SQL과의 호환성을 우지하기 위한 몇 가지 변화가 있다. 이런 변경은 여러분이 사용하고 있는 어플리케이션에도 영향을 미칠 것이다.
아래에서는 어플리케이션에 영향을 줄 수 있는 것들과 5.0으로 업그레이드를 할 때 주의해야 할 사항들을 설명하기로 한다.
Server Changes:
● Incompatible change: TEXT 컬럼에 있는 InnoDB 와 MyISAM 테이블을 위한 엔드-스페이스(end-space)용 인덱싱 순서가 변경 되었다. 5.0.3버전 이후에, TEXT 인덱스는 마지막
에서 스페이스-패드(space-padded)와 비교된다(마치 MySQL이 CHAR, VARCHAR 및 TEXT 필드를 정렬시키는 것처럼). TEXT 컬럼에 인덱스가 있다면, 여기에서 CHECK
TABLE을 실행해야 한다. 실행 후에 에러가 발생하면, 인덱스를 재 구축한다: InnoDB 테이블이 있다면 테이블을 덤프하고 재 로드 하거나, 또는MyISAM 테이블이 있다면 OPTIMIZE
TABLE 또는 REPAIR TABLE를 실행한다.
● Warning: Incompatible change. BINARY 컬럼에 대해서는, 패드(pad) 값과 이것을 다루는 방법이 MySQL 5.0.15이후로 변경 되었다. 현재 삽입을 위한 패드 값은 스페이스가 아니
라 0x00 이고, 그리고 선택을 위한 패드 값 스트라이핑(stripping)은 없다. 자세한 사항은, Section 11.4.2, “BINARY 와 VARBINARY 타입”을 참조할 것.

:::MySQL Korea:::
● Incompatible change: MySQL 5.0.3에서 5.0.5까지 DECIMAL 컬럼을 가지고 생성된 MyISAM 과 InnoDB 테이블은 5.0.6으로 업그레이드를 한 후에는 깨져 버린다(corrupted). 업
그레이드를 하기 전에 이 테이블들을 덤프(Dump)해 놓은 다음에, 업그레이드를 한 후에 다시 재 로드 한다. (동일한 비호환성 문제가 5.0.6에서 생성한 테이블을 5.0.3과 5.0.5로 다운
그레이드할 때에도 발생한다.)
● Incompatible change: DECIMAL구현 방법이 MySQL 5.0.3에서 변경 되었다. 어플리케이션이 이 변경 사항을 인식하도록 해야 하는데, 자세한 내용은, Section 21.2, “DECIMAL 데
이터 타입 변경”을 참조하기 바란다.
DECIMAL 과 NUMERIC 고정-소수점 타입(fixed-point data types)의 구현 방법의 변경으로 인해 서버는 표준 SQL의 규칙을 보다 확실하게 준수하게 되었다. 예를 들면,
DECIMAL(3,1)의 데이터 타입은 99.9의 최대 값을 저장한다. MySQL 5.0.3 이전에서는, 서버는 보다 큰 숫자를 저장했어야 했다. 즉, 서버는 100.0에 대해 100.0으로 저장을 했다.
MySQL 5.0.3 이후에는, 서버는 100.0을 절사해서(clips) 최대 가능 숫자 99.9로 저장된다. 여러분이 5.0.3 이전 버전에서 생성된 테이블을 갖고 있고 이 테이블이 부동 소수점 데이
터 타입을 갖고 있다면, 이 데이터를 변경 시켜야 한다. 예를 들면:
ALTER TABLE tbl_name MODIFY col_name DECIMAL(4,1);
● Incompatible change: MySQL 5.0.3 이후부터는, 서버가 메인 함수 심볼에 추가적으로 정의된 보조 심볼(auxiliary symbol)(예를 들면 xxx_init 또는 xxx_deinit 심볼)을 적어도 하
나 이상 갖고 있지 않는다면 디폴트로 더 이상 사용자 정의 함수를 로드 하지 않는다. 이런 동작은 --allow-suspicious-udfs 옵션을 가지고 우선적으로 실행시킬 수 있다.
Section 24.2.4.6, “사용자 정의 함수 보안 사전 대책”을 참조할 것.
● Incompatible change: 업데이트 로그는 MySQL 5.0에서 삭제 되었다. 여러분이 전에 이것을 활성화 시켰다면, 이것 대신에 바이너리 로그를 활성화 시켜야 한다.
● Incompatible change: ISAM 스토리지 엔지에 대한 지원은 없어졌다. 만약에 ISAM 테이블을 갖고 있다면, 업그레이드하기 전에 그 테이블을 변환시켜야(convert) 한다. 예를 들면,
MyISAM 스토리지 엔진을 사용하도록 ISAM 테이블을 변환 시키기 위해서는, 다음의 명령문을 사용한다:
• ALTER TABLE tbl_name ENGINE = MyISAM;
데이터 베이스에 있는 각각의 ISAM 테이블에 대해 비슷한 명령문을 실행한

다.
● Incompatible change: MySQL5.0부터는 MyISAM 테이블에 있는 RAID 옵션에 대한 지원이 삭제 되었다. 이러한 옵션을 사용하는 테이블을 갖고 있다면, 업그레이드 하기 전에 변환
을 해 놓아야 한다. 한 가지 방법은 mysqldump을 가지고 덤프를 하고, 덤프 파일을 CREATE TABLE 명령문에 있는 RAID 옵션을 삭제하고 덤프 파일을 다시 로드 하는 것이다. 다른
방법으로는 CREATE TABLE new_tbl ... SELECT raid_tbl을 사용해서 RAID 테이블로부터 새로운 테이블을 생성하는 것이다. 하지만, 명령문의 CREATE TABLE 부분에는 반드
시 인덱스뿐만 아니라 컬럼 속성을 재 생성을 위한 충분한 정보가 포함되어야 하는데, 그렇지 않을 경우에는 컬럼 속성을 잃어 버리게 되고 인덱스는 새로운 테이블에서 사라지게 될 것
이다. Section 13.1.5, “CREATE TABLE 신텍스”를 참조할 것.
주어진 데이터베이스에 있는 RAID 테이블을 위한 .MYD 파일들은 00에서 ff까지의 16진수로 이름이 되어 있는 서브 디렉토리에 있는 데이터 디렉토리 아래에 저장된다. RAID 옵션
을 가지고 있는 모든 테이블을 변환시킨 다음에도, 이러한 RAID-관련 서브 디렉토리는 아직까지 존재하게 되지만 삭제가 가능하다. 이 디렉토리가 비어 있음을 확인하고, 수동으로 이
것들을 삭제한다. (디렉토리가 비어 있지 않으면, 아직까지도 변환되지 않은 RAID 테이블이 있는 것이다.)
● MySQL 5.0.6에서는, 스토어드 루틴과 트리거의 바이너리 로깅이 변경 되었다. 이 변경 사항은 Section 17.4, “스토어드 루틴과 트리거의 바이너리 로깅”에서 설명하듯이 보안, 리플

:::MySQL Korea:::
리케이션, 그리고 데이터 복구와 관련되어 있다.
SQL Changes:
● Incompatible change: 이전에는, 잠금 대기 타임 아웃(lock wait timeout)은 InnoDB가 현재의 모든 트랜젝션을 롤백(roll back)하게끔 만들었다. MySQL 5.0.13이후에는, 이것은 가
장 최신의 SQL명령문만 롤백 시킨다.
● Incompatible change: 트리거용 이름 공간(namespace)은 MySQL 5.0.10에서 변경 되었다. 이전 버전에서는, 트리거의 이름은 테이블 별로 서로 틀린 것을 사용해야 했다. 이제는 스
키마(데이터베이스)별로 서로 틀린 이름을 사용해야 한다. 이 변경은 이제는 DROP TRIGGER 신텍스가 테이블 이름 대신에 스키마 이름을 사용한다는 것을 의미하는 것이다(스키마 이
름은 옵션 사항이며, 만약에 생략 되면, 현재의 스키마가 사용 된다).
MySQL 5.0 이전 버전에서 MySQL 5.0.10 또는 그 이후 버전으로 업그레이드를 할 때, 여러분은 모든 트리거를 드롭(drop)시킨 후에 다시 생성 시켜야 하는데, 그렇지 않으면 DROP
TRIGGER가 업그레이드 후에 동작하지 않는다. 이것을 실행하기 위한 권장 과정이 여기에 있다:
1. MySQL 5.0.10 또는 그 이후 버전으로 업그레이드를 해서 INFORMATION_SCHEMA.TRIGGERS 테이블에 있는 트리거 정보를 접근할 수 있도록 한다. (이것은
5.0.10 이전 트리거에 대해서도 실행해야 한다.)
2. 다음의 SELECT 명령문을 사용해서 모든 트리거 정의문을 덤프한다Dump all trigger definitions using the following SELECT statement:
SELECT CONCAT('CREATE TRIGGER ', t.TRIGGER_SCHEMA, '.',t.TRIGGER_NAME,
' ', t.ACTION_TIMING, ' ', t.EVENT_MANIPULATION, ' ON ',
t.EVENT_OBJECT_SCHEMA, '.', t.EVENT_OBJECT_TABLE,
' FOR EACH ROW ', t.ACTION_STATEMENT, '//' )
INTO OUTFILE '/tmp/triggers.sql'
FROM INFORMATION_SCHEMA.TRIGGERS AS t;
명령문은 INTO OUTFILE을 사용하기 때문에, 여러분은 FILE 권한을 반드시 갖고 있어야 한다. 이 파일은 서버 호스트에서 생성 되어진다; 원하면 다른 이름을 사용 한다.
100% 안전을 보장하기 위해, triggers.sql 파일에 있는 트리거 정의문을 조사하고, 이 파일의 복사본을 만들어 둔다.
3. 서버를 종료하고 데이터 디렉토리에 있는 모든 .TRG 파일을 삭제해서 모든 트리거를 드롭시킨다. 데이터 디렉토리로 위치를 변경한 다음에 다음의 명령어를 입력한다:
4. shell> rm */*.TRG
5. 서버를 구동 시킨 다음에 triggers.sql 파일을 사용해서 모든 트리거를 재 작성한다: 예를 들면:
6. mysql> delimiter // ;
7. mysql> source /tmp/triggers.sql //

:::MySQL Korea:::
8. SHOW TRIGGERS 명령문을 사용해서 모든 트리거가 성공적으로 생성되었는지 확인한다.
● Incompatible change: MySQL 5.0.15 이후에는, CHAR() 함수는 연결 문자 셋에 있는 스트링이 아닌 바이너리 스트링을 리턴 한다. USING charset_name 옵션 구문은 이것 대신에
특수 문자 셋을 리턴할 때 사용할 수 있다. 또한, 256보다 큰 인수들은 다중 문자(multiple character)를 만들어 낸다. 더 이상 모듈로 256을 해석해서 단일 문자 셋을 만들지는 못한다.
이러한 변경으로 인해 몇 가지 비호화성이 발생하게 되었다:
l CHAR(ORD('A')) = 'a' 는 더 이상 허용(true)되지 않는다:
o mysql> SELECT CHAR(ORD('A')) = 'a';
o +----------------------+
o | CHAR(ORD('A')) = 'a' |
o +----------------------+
o | 0|
o +----------------------+
대소 문자를 구분하지 않는 비교문을 실행하기 위해서는, USING 구문을 추가 하거나 또는 결과를 변환 시킴으로써 비-바이너리(non-binary)문자 셋에 결과 스트링을 만들
수 있다:
mysql>

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.10.3. MySQL 데이터 베이스를 다른 머신으로 복사하기
2.10. MySQL 업그레이드 하기 여러분은 MyISAM 테이블용 .frm, .MYI, 및 .MYD 파일을 동일한 부동 소수점 포맷을 지원하는 서로 다른 머신 사이에서 이동 시
2.10.3 MySQL 데이터 베이스를 다른 머신으로 복 킬 수 있다. Section 14.1, “MyISAM 스토리지 엔진”을 참조 할 것.
사하기
서로 다른 머신간에 데이터 베이스를 전달할 필요가 있을 경우에는, mysqldump를 사용해서 SQL명령문을 갖는 파일을 만든다.
그 다음에는 다른 머신에 전달하고 mysql 클라이언트의 입력 값으로 사용한다.
mysqldump --help옵션을 사용해서 사용 가능한 옵션을 알아 본다. 데이터를 새로운 버전의 MySQL로 전달한다면,
mysqldump --opt 를 사용해서 최대한 최적화를 시켜서 덤프를 함으로서 크기를 작게 할 수 있다.
두 머신간의 데이터 이동(빠르지는 않더라도) 방법 중에 가장 간단한 것은 데이터 베이스가 있는 머신에서 아래의 명령어들을 실행
하는 것이다:
shell> mysqladmin -h 'other_hostname' create db_name
shell> mysqldump --opt db_name | mysql -h 'other_hostname' db_name
속도가 느린 네트워크상에 있는 리모트 머신에서 데이터를 복사하고자 한다면, 다음의 명령어를 사용하면 된다:
shell> mysqladmin create db_name
shell> mysqldump -h 'other_hostname' --opt --compress db_name | mysql db_name
여러분은 파일안에 덤프로 저장하고, 타겟 머신에 파일을 전송하고, 그 다음에 그곳에 있는 데이터 베이스로 파일을 로드할 수도 있
다. 예를 들면, 아래와 같이 소스 머신에서 데이터 베이스를 압축 파일로 덤프할 수 있다:

:::MySQL Korea:::
shell> mysqldump --quick db_name | gzip > db_name.gz
데이터 베이스를 갖고 있는 파일을 타겟 머신으로 전송한 다음에 아래의 명령어를 그곳에서 실행한다:
shell> mysqladmin create db_name
shell> gunzip < db_name.gz | mysql db_name
데이터 베이스를 전송하기 위해서 mysqldump 와mysqlimport 도 사용할 수 있다. 큰 테이블의 경우, 이것은 단순히 mysqldump
를 사용하는 것보다 빠르다. 아래의 명령어에서 보면, DUMPDIR 는 mysqldump 로부터 결과를 저장하기 위해 사용하는 디렉토리
의 전체 경로 이름을 표시하는 것이다.
우선, 결과 파일을 위한 디렉토리를 만들고 데이터 베이스를 덤프한다:
shell> mkdir DUMPDIR
shell> mysqldump --tab=DUMPDIR db_name
그 다음에는 DUMPDIR 디렉토리에 있는 파일을 타겟 머신의 대응되는 디렉토리에 전송하고 그 곳에 잇는 MySQL안으로 로드를
한다:
shell> mysqladmin create db_name # create database
shell> cat DUMPDIR/*.sql | mysql db_name # create tables in database
shell> mysqlimport db_name DUMPDIR/*.txt # load data into tables
mysql 데이터 베이스를 복사하는 것을 잊지 말아야 하는데, 거기에 그랜트 테이블이 저장되어 있기 때문이다. 여러분이 새로운 머
신에 mysql 데이터 베이스를 갖기 전까지는 그 곳에서 root 사용자로서 명령어를 실행해야 할 것이다.
mysql 데이터 베이스를 새로운 머신으로 전송한 다음에는, mysqladmin flush-privileges를 실행해서 서버가 그랜트 테이블 정보

:::MySQL Korea:::
를 다시 로드하도록 만든다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.11. MySQL 다운 그레이드 하기
2. MySQL 설치 및 업그레이드 하기 2.11.1. 4.1로 다운 그레이드 하기

2.11. MySQL 다운 그레이드 하기 이 섹션에서는 이전 버전이 새로운 버전 보다 더 효과적으로 동작되는 경우에 어떻게 구형 버전으로 다운 그레이드 하는지에 대해
2.11 MySQL 다운 그레이드 하기 설명하기로 한다.
2.11.1 4.1로 다운 그레이드 하기 동일한 릴리즈 시리즈내에서 다운 그레이드를 한다면(예를 들면, 4.1.13에서 4.1.12로), 일반적인 방법은 새로운 바이너리를 이전
버전의 최상위에 설치하는 것이다. 데이터 베이스에는 아무것도 할 것이 없다. 하지만, 항상 그러하듯이, 백업을 받아 두는 것이 좋
다.
아래에서는 다운 그레이드를 실행할 때 체크해야 할 항목들을 명시하고 있다.:
● 다운 그레이드 하고자 하는 버전에 있는 업그레이드 섹션을 숙지하여 필요 없는 기능은 실행하지 않도록 한다.
Section 2.10, “MySQL 업그레이드 하기”를 참조할 것.
● 그곳에 다운 그레이드에 관련된 사항이 있다면, 그 부분도 숙지하기 바란다.
대부분의 경우, 여러분은 동일한 MySQL릴리즈 시리즈 버전에서 진행하는 동안 동일 머신에 있는 서로 다른 버전간에 MySQL 포
맷 파일과 데이터 파일을 이동하는 것은 가능하다.
하나의 릴리즈 시리즈에서 다른 다운 그레이드를 할 경우에는, 테이블 스토리지 포맷에서 호환이 되지 않는 경우도 있다. 이럴 경우
에는, mysqldump를 사용해서 다운 그레이드 하기 전에 테이블을 덤프한다. 다운 그레이드한 후에, mysql을 사용해서 덤프 파일
을 재 로드하거나 또는 mysqlimport를 사용해서 테이블을 재 생성한다. 예를 들면, Section 2.10.3, “다른 머신으로 MySQL 데
이터 베이스 복사하기”를 참조할 것.
다운 그레이드할 때 하향 비화화적인 테이블 포멧(downward-incompatible table format) 변경의 일반적인 증상은 테이블을 열
지 못한다는 것이다. 이와 같은 경우, 다음의 과정을 진행한다:
1. 다운 로드 하고자 하는 예전 서버를 종료한다.
2. 다운 로드 하고자 하는 새로운 서버를 재 시작한다.
3. 예전 서버에서 사용할 수 없는 테이블들을 덤프한다. Mysqldump를 사용해서 덤프 파일을 만든다.
4. 새로운 서버를 종료하고 구형 서버를 재 시작한다.

:::MySQL Korea:::
5. 구형 서버로 덤프 파일을 재 로드한다. 이제는 사용 가능할 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.11.1. 4.1로 다운 그레이드 하기
2.11. MySQL 다운 그레이드 하기 5.0에서 다운 그레이드를 한 다음에는, mysql.err 파일에서 다음과 같은 에러를 볼 수 있을 것이다:
2.11.1 4.1로 다운 그레이드 하기

Incorrect information in file: './mysql/user.frm'
이와 같은 경우에는, 다음과 같이 실행한다:
1. MySQL 5.0.4 (또는 이후 버전)을 시작한다.

2. mysql_fix_privilege_tables를 실행 시킨다. 이것은 mysql.user을 4.1과 5.0에서 모두 사용 가능하도록 테이블 포
맷을 변경시킨다.
3. MySQL 서버를 종료한다.
4. MySQL 4.1를 시작한다.
앞의 과정이 실패하면, 대신에 아래의 과정을 실행한다:
1. MySQL 5.0.4 (또는 이후 버전)을 실행한다.

2. mysqldump --opt --add-drop-table mysql > /tmp/mysql.dump를 실행한다.
3. MySQL 서버를 종료한다.
4. MySQL 4.1을 --skip-grant 옵션과 함께 실행한다.
5. mysql mysql < /tmp/mysql.dump를 실행한다.
6. mysqladmin flush-privileges를 실행한다

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.12. OS 관련 노트
2. MySQL 설치 및 업그레이드 하기 2.12.1. Linux Notes

2.12. OS 관련 노트 2.12.2. Mac OS X Notes
2.12 OS 관련 노트 2.12.3. Solaris Notes
2.12.1 리눅스 노트 2.12.4. BSD Notes
2.12.1.1 리눅스 OS 노트 2.12.5. Other Unix
2.12.1.2 리눅스 바이너리 배포판 노트 Notes

2.12.6. OS/2 Notes
2.12.1.5 리눅스 x86 노트
2.12.1.10 리눅스 IA-64 노트
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.12.1. 리눅스 노트
2. MySQL 설치 및 업그레이드 하기 2.12.1.1. 리눅스 OS 노트

2.12. OS 관련 노트 2.12.1.2. 리눅스 바이너리 배포판 노트
2.12.1 리눅스 노트 2.12.1.3. 리눅스 소스 배포판 노트
2.12.1.1 리눅스 OS 노트 2.12.1.4. 리눅스 설치후 과정(Post-Installation) 노트
2.12.1.2 리눅스 바이너리 배포판 노트 2.12.1.5. 리눅스 x86 노트

2.12.1.6. 리눅스 SPARC 노트
2.12.1.7. 리눅스 알파(Alpha) 노트
2.12.1.8. 리눅스 PowerPC 노트
2.12.1.5 리눅스 x86 노트
2.12.1.9. 리눅스 MIPS 노트
2.12.1.10. 리눅스 IA-64 노트
이 섹션에서는 리눅스에서 발생하는 여러 문제들에 대해 설명하기로 한다. 처음 몇 장에서는 일반적인 OS관련 이슈들, 바이너리 또
는 소스 배포판을 설치할 때 발생되는 문제점들, 그리고 설치후에 해야 할 과정들에 대해 설명할 것이다. 나머지 섹션에서는 특정
2.12.1.10 리눅스 IA-64 노트
플랫폼에 리눅스를 설치하는 과정에서 발생되는 문제점들에 대해 설명하기로 한다.
여기에서 설명하는 대부분의 문제점들은 구형 리눅스 버전을 사용할 경우에 발생되는 것들로서, 만약에 최신의 리눅스 버전을 사용
할 경우에는 거의 발생하지 않게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.12.1.1. 리눅스 OS 노트
2.12. OS 관련 노트 MySQL은 리눅스 버전 2.0 이상이 요구된다.
2.12.1 리눅스 노트
Warning: 우리는 몇 가지 이상한 문제점들이 리눅스 2.2.14과 MySQL이 시스템에서 동작할 때 발생된다는 것을 발견하였다. 우리
2.12.1.1 리눅스 OS 노트
는 또한 몇몇 MySQL사용자들이 리눅스 커널 2.2.14에서 MySQL서버를 구동시킬 때 안정성에 심각한 문제가 있다는 보고를 받
은 적도 있다. 여러분이 이런 커널을 사용하고 있다면, 커널을 2.2.19(또는 그 이상)으로 업그레이드 하거나 2.4커널로 업그레이
드 해야 한다. 다중 CPU시스템을 사용중이라면, 2.4 커널을 사용하길 적극 권장하는데, 이런 시스템 환경에서는 괄목할 만한 성능
향상과 개선된 안정성을 기대할 수 있기 때문이다.
2.12.1.5 리눅스 x86 노트
2.12.1.6 리눅스 SPARC 노트 리눅스쓰레드(LinuxThreads)를 사용할 때, 여러분은 최소한 3개의 mysqld 프로세스가 구동되고 있음을 볼 것이다. 이것들이 사
2.12.1.7 리눅스 Alpha 노트 실 쓰레드이다. 하나는 리눅스쓰레드 관리자용이고, 다른 하나는 연결(connection)을 다루기 위한 쓰레드이며, 나머지 한 개는 경
2.12.1.8 리눅스 PowerPC 노트 고와 신호(alarm and signal)을 처리하기 위한 것이다.
2.12.1.10 리눅스 IA-64 노트
:::MySQL Korea:::
제목검색
2.12.1.2. 리눅스 바이너리 배포판 노트

2.12. OS 관련 노트 리눅스-인텔 바이너리 및 RPM릴리즈는 최상의 성능을 위한 조합이다.
2.12.1 리눅스 노트
바이너리 릴리즈는 -static으로 링크되어 있는데, 이것은 여러분이 지금 가지고 있는 시스템 버전이 무엇인지 걱정을 하지 않아도
2.12.1.1 리눅스 OS 노트
된다는 것을 의미한다. 리눅스 쓰레드를 설치할 필요도 없다. -static으로 링크된 프로그램은 동적으로 링크된 것보다 파일 크기가
다소 크긴 하지만, 3~5%정도 빠르게 동작한다. 하지만, 정적으로 링크된 프로그램이 갖는 한가지 문제점은 사용자 정의 함수
(UDFs)를 사용할 수 없다는 것이다. 만약에 UDF를 작성 하거나 사용하고자 할 경우라면(C 또는 C++ 프로그래머에만 해당될
수 있음), 여러분 스스로 동적 링크를 사용해서 MySQL을 컴파일 해야 한다.
2.12.1.5 리눅스 x86 노트
2.12.1.6 리눅스 SPARC 노트 libc (레드햇 4.x 또는 Slackware)를 사용하는 구형 리눅스 시스템에서 바인너리 배포판을 사용할 때에는, 호스트 이름에 관련하
2.12.1.7 리눅스 Alpha 노트 여 몇 가지 문제점들(non-fatal)이 있다고 알려져 있다. 시스템이 glibc2를 사용하지 않고 libc를 사용할 경우에는, 호스트 이름 해
2.12.1.8 리눅스 PowerPC 노트 결 및 getpwnam()에서 문제를 느낄 것이다. 이것은 glibc (불행하게도)가 –static를 가지고 컴파일 한다고 하더라도, 몇몇 외부
2.12.1.9 리눅스 MIPS 노트 라이브러리를 사용해서 호스트 이름 해결 및 getpwent()를 처리하기 때문이다. 이러한 문제들은 두 가지 방식으로 표현된다:
2.12.1.10 리눅스 IA-64 노트
● 여러분이 mysql_install_db를 구동시키면 아래와 같은 에러를 보게된다:
• Sorry, the host 'xxxx' could not be looked up
여러분은 이것을 mysql_install_db –force를 가지고 처리할 수 있는데, 이것은 mysql_install_db에서 resolveip 테스트
를 실행하지 않게 한다. 이런 하향 지원으로 인해 여러분은 그랜트 테이블에서 호스트 이름을 사용할 수 없게 된다:
localhost을 사용하지 않고, 대신에 IP 번호를 사용해야 한다. –force를 지원하지 않는 구형 MySQL버전을 사용하
고 있다면, 텍스트 편집기를 사용해서 수동으로 mysql_install 에 있는 resolveip 테스트를 삭제해야 한다.
● Mysqld를 --user 옵션과 함께 사용할 경우에는 다음과 같은 에러를 볼 수도 있다:

:::MySQL Korea:::
• getpwnam: No such file or directory
이 문제를 해결하기 위해서는, mysqld을 실행할 때 --user 옵션을 사용하지 말고 su 명령어를 사용한다. 이것은 시스템
자체가 mysqld 프로세스의 사용자 ID를 변경 시켜서 mysqld이 그 일을 할 필요가 없게 만들어 준다.
두 가지 문제를 모두 해결할 수 있는 다른 방법으로는, 바인너리 배포판을 사용하지 않는 것이다. 대신에 소스 배포판(RPM 또는

tar.gz 포맷)을 사용해서 설치 한다.
어떤 리눅스 2.2. 버전에서는, 클러이언트가 TCP/IP를 통해 mysqld 서버에 새로운 접속을 수없이 진행할 때 ‘Resource
temporarily unavailable’라는 에러가 생기기도 한다. 이 문제는 여러분이 TCP/IP소켓을 닫는 시간과 시스템이 실제로 이것을
사용 가능하게 만드는 시간 사이에 차이가 발생하기 때문이다. 예를 들면, TCP/IP를 통해 MySQL test-connect 벤치 마크를 실
행하면 에러가 발생하게 된다
우리는 여러 가지 방법을 통해 이 문제를 해결하고자 하고 있지만, 아직은 적절한 해결책을 찾지는 못하고 있는 상황이다. 유일한
해결책은 클라이언트가 계속적으로 접속을 시도하거나, 또는 데이터베이스 서버와 클라이언트를 동일 장비에서 구동 시킬 경우에
는, TCP/IP 접속을 사용하지 않고 유닉스 소켓 파일 접속을 사용하는 것이다.

:::MySQL Korea:::
제목검색
2.12.1.3. 리눅스 소스 배포판 노트

2.12. OS 관련 노트 이 장에서는 여러분이 스스로 MySQL을 설치하는 경우에만 적용되는 glibc 에 관련된 내용을 설명하기로 한다. 만약에 x86머신에
2.12.1 리눅스 노트 서 리눅스를 사용하고 있다면, 대부분의 경우에는 우리가 제공하는 바이너리를 사용하는 것이 더 좋을 것이다. 우리는 우리가 얻을
2.12.1.1 리눅스 OS 노트 수 있는 최신의 glibc 버전을 최상의 컴파일 옵션을 가지고 바이너리 배포판에 링크를 해서 고부하 서버에서 적용될 수 있도록 만들
었다. 일반적인 사용자의 경우에는, 비록 많은 수의 동시 접속의 설정하거나 최대 테이블 크기가 2GB를 초과한다고 하더라도, 대부
분의 경우에 우리가 제공하는 바이너리를 사용하는 것이 최선의 방법이다. 이 장을 모두 읽고 난 후에, 아직도 어떤 것을 사용할 지
결정하지 못한 사용자일 경우에는, 우선 우리가 배포한 바이너리를 사용해서 원하는 기능을 제공하는지 판단해 보길 권장한다. 우
리의 배포판이 만족스럽지 못할 경우에는, 스스로 구축해 보고 싶은 마음이 생길 것이다.
2.12.1.5 리눅스 x86 노트
MySQL는 리눅스에서 리눅스 쓰레드를 사용한다. 여러분이 glibc2를 갖고 있지 않는 구형 리눅스를 사용하고 있다면, MySQL을
컴파일하기 전에 우선 리눅스쓰레드를 설치해야 한다. 리눅스 쓰레드는 http://dev.mysql.com/downloads/os-linux.html에서 얻
2.12.1.8 리눅스 PowerPC 노트 을 수 있다.
2.12.1.10 리눅스 IA-64 노트 버전 2.1.1을 포함한 이전의 glibc는 pthread_mutex_timedwait()를 구현하는데 있어서 치명적이 에러를 가지고 있는데, 이것은
INSERT DELAYED 명령문이 실행될 때 나타난다. glibc를 업그레이드 하기 전에는 INSERT DELAYED를 사용하지 말 것을 권
장한다.
리눅스 커널과 리눅스쓰레드 라이브러리는 디폴트로 최대 1,024개의 쓰레드를 처리한다는 점을 알아두기 바란다. 1,000개 이상
의 동시 접속을 하고자 계획한다면, 리눅스 쓰레드에 대해서 아래와 같이 몇 가지 변경을 해두어야 한다:
● sysdeps/unix/sysv/linux/bits/local_lim.h에 있는 PTHREAD_THREADS_MAX는 4096로 증가 시키고 linuxthreads/

internals.h 에 있는 STACK_SIZE 는 256KB로 내린다. 경로는 glibc 의 루트와 연결시킨다. (MySQL은 STACK_SIZE
가 디폴트 크기인 2MB인 경우에는 600-1000개의 연결에 대해 불안정하게 된다.)
● 리눅스쓰레드를 재 컴파일해서 새로운 libpthread.a 라이브러리를 생성하게 하고, MySQL과 재 링크를 시킨다.

:::MySQL Korea:::
리눅스쓰레드에서 쓰레드 제약을 해결하는 방법에 대한 보다 많은 정보는 http://www.volano.com/linuxnotes.html에서 찾을 수

있다.
MySQL의 성능을 현저하게 저하 시키는 또 다른 문제가 있는데, 특히SMP시스템에서 이러한 것들이 발생한다. glibc 2.1에 있는
리눅스쓰레드에서의 mutex 구현은 수많은 쓰레드가 매우 짧은 시간 동안만 mutex를 실행하는 프로그램에 대해서는 매우 좋지 않
은 성능을 내게 된다. 이것은 역설적인(paradoxical) 결과를 만들어낸다: 여러분이 MySQL을 수정하지 않은 리눅스쓰레드에 링
크 한다면, SMP에서 프로세서를 삭제하는 것이 많은 경우에 실제적으로 MySQL의 성능을 향상 시킨다. 우리는 glibc 2.1.3에서
사용 가능한 패치를 만들어 놓았다 (http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch).
glibc 2.2.2에서는, MySQL은 개선된 mutex를 사용하는데, 이것은 2.1.3에 패치를 한 것 보다 더 우수한 성능을 보여준다. 하지
만, 우리가 경고를 하였듯이, 어떤 환경에서는 2.2.2에 있는 현재의 mutex코드는 오버 스핀(overspin)을 하기 때문에, MySQL의
성능을 저하시킨다. 이러한 경우는 mysqld 프로세스를 최고의 우선 순위로 변경시키면 많이 발생하지가 않는다. 우리는 또한 이러
한 오버 스핀을 해소할 수 있는 패치를 제공하고 있으며, http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch
에서 찾을 수 있다. 이 패치는 오버스핀의 해결, 쓰레드의 최대 숫자, 그리고 스택 스페이싱(stack spacing)을 하나로 묶어서 제공
한다. 이것은 linuxthreads 디렉토리에 patch -p0 </tmp/linuxthreads-2.2.2.patch로 적용한다. 우리는 이 패치가 향후에 2.2.
릴리즈에 포함되어 제공되길 기대한다. 어떤 경우이건, 여러분이 glibc 2.2.2에 링크를 한다면, 여전히 STACK_SIZE 과
PTHREAD_THREADS_MAX를 해결해야 한다. 우리는 향후에 고 부하(high-load)MySQL에 보다 잘 적용될 수 있는 디폴트 값
이 제공되길 기대하며, 이에 따라 여러분 스스로 ./configure; make; make install을 구축하려는 수고가 많이 절감되길 바란다.
우리는 여러분이 이러한 패치들을 사용해서 libpthread.a 의 특별한 정적(static) 버전을 구축하고 MySQL에 정적으로만 링크할
때 사용하길 권장한다. 우리는 이러한 패치들이 MySQL에서 안정적으로 동작되고 상당한 수준의 성능 개선을 만든다는 것을 알고
있지만, 다른 어떤 어플리케이션에 무슨 영향을 미치는지에 대해서는 정확히 말할 수 없다. 리눅스쓰레드를 요구하는 다른 어플리
케이션을 패치가 된 정적 라이브러리 버전과, 또는 패치가 된 공유 버전과 링크를 하고 이것을 시스템에 설치하고자 한다면, 이에
대한 위험은 여러분 스스로 책임져야 한다.
MySQL을 설치하는 동안, 또는 일반 유틸리티를 다루면서 어떤 이상한 문제를 발견하게 되는 경우는, 그런 문제들은 라이브러리
또는 컴파일러와 연관된 것들일 것이다. 이러한 경우가 발생하면, 우리가 제공하는 바이너리를 사용해서 문제를 해결하기 바란다.
만약에 여러분 스스로의 MySQL클라이언트 프로그램을 링크하는 경우에는, 런타임 때에 아래와 같은 에러를 볼 수도 있을 것이
다:

:::MySQL Korea:::
ld.so.1: fatal: libmysqlclient.so.#:
open failed: No such file or directory
이 문제는 아래의 방법 중에 하나를 가지고 해결할 수 있다:
● 클라이언트를 링크할 때 –Lpath)를 사용하지 말고 - Wl,r/full/path/to/libmysqlclient.so 플래그를 사용한다.

● libmysqclient.so 를 /usr/lib에 복사한다.
● 클라이언트를 구동시키기 전에 libmysqlclient.so가 있는 디렉토리의 경로를 LD_RUN_PATH 환경 변수에 추가한다.
후지쯔 컴파일러(fcc/FCC)를 사용한다면, MySQL을 컴파일 할 때 몇 가지 문제가 발생할 수 있는데, 그 이유는 리눅스 헤더 파일
이 gcc와 매우 밀접하게 관련이 있기 때문이다. 이때에는 아래의 configure 라인을 fcc/FCC과 함께 사용해야 한다:
CC=fcc CFLAGS="-O -K fast -K lib -K omitfp -Kpreex -D_GNU_SOURCE ￦
-DCONST=const -DNO_STRTOLL_PROTO" ￦
CXX=FCC CXXFLAGS="-O -K fast -K lib ￦
-K omitfp -K preex --no_exceptions --no_rtti -D_GNU_SOURCE ￦
-DCONST=const -Dalloca=__builtin_alloca -DNO_STRTOLL_PROTO ￦
'-D_EXTERN_INLINE=static __inline'" ￦
./configure ￦
--with-mysqld-ldflags=-all-static --disable-shared ￦
--with-low-memory

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
2.12.1.4. 리눅스 설치후 과정 노트

2.12. OS 관련 노트 mysql.server 는 MySQL설치 디렉토리 밑에 있는 support-files 디렉토리 또는 MySQL 소스 트리에서 찾을 수 있다. 여러분은
2.12.1 리눅스 노트 이것을 /etc/init.d/mysql 형태로 설치하여 자동으로 MySQL 스타트업 및 셧 다운을 하도록 할 수 있다. Section 2.9.2.2, “자동
2.12.1.1 리눅스 OS 노트 으로 MySQL 시작하기 및 종료하기”를 참조할 것.

만약에 MySQL이 충분한 파일을 열거나 또는 연결을 이루지 못할 경우는, 여러분이 리눅스가 충분한 파일을 다룰 수 있도록 구성
하지 못한 것이다.
2.12.1.5 리눅스 x86 노트
리눅스 2.2 및 이후 버전에서는, 아래와 같이 처리할 수 있는 할당 파일의 숫자를 검사해 본다:
2.12.1.7 리눅스 Alpha 노트 shell> cat /proc/sys/fs/file-max
2.12.1.9 리눅스 MIPS 노트 shell> cat /proc/sys/fs/dquot-max
2.12.1.10 리눅스 IA-64 노트

shell> cat /proc/sys/fs/super-max
여러분이16MB 이사의 메모리를 갖고 있다면, 여러분의 초기 스크립트에 아래와 같은 것들을 추가해야 한다(예를 들면, 수세 리눅
스에서는 /etc/init.d/boot.local):
echo 65536 > /proc/sys/fs/file-max
echo 8192 > /proc/sys/fs/dquot-max
echo 1024 > /proc/sys/fs/super-max

:::MySQL Korea:::
또한 root 사용자로서 명령어 라인에서 echo 명령어를 구동시킬 수는 있지만, 나중에 컴퓨터를 재 구동 시킬 때 시간만 허비하게
만든다.
대신에, 여러분은 sysctl 툴을 사용해서 스타트업 파일에 이러한 파라미터들을 설정할 수 있는데, 이런 방법은 많은 수의 리눅스 배
포판에서 사용하는 방법이다(수세 리눅스 8.0 및 이후 버전 포함). 아래의 값들을 /etc/sysctl.conf라는 이름의 파일에 추가한다:
# Increase some values for MySQL
fs.file-max = 65536
fs.dquot-max = 8192
fs.super-max = 1024
또한, 아래의 것들을 /etc/my.cnf에 추가한다:
[mysqld_safe]
open-files-limit=8192
이를 통해 서버는 연결 가능 숫자와 열 수 있는 파일의 숫자의 한계를 8,192가 될 수 있게 된다.
리눅스쓰레드에 있는 STACK_SIZE 상수(constant)는 주소 크기(space)에 있는 쓰레드 스택의 크기를 제어한다. 이것은 각 개

별 쓰레드 스택에 대해 충분한 공간을 제공할 만큼 커야 하지만, 쓰레드 스택이 글로벌 mysqld 데이터와 충돌하지 않을 만큼만 되
면 된다. 불행하게도, 우리가 실험적으로 발견하였듯이, 리눅스의 mmap() 구현은, 여러분이 이 함수로 하여금 현재 사용중인 주소
를 정확히 찾도록 요청할 경우, 에러를 리턴하는 대신데 전체 페이지에 있는 데이터를 삭제(zeroing out)함으로써, 매핑되어 있는
지역을 풀어 버린다. 따라서, mysqld의 안정성 또는 다른 쓰레드 어플리케이션들은 쓰레드를 생성하는 코드의 “신사적인
(gentlemanly)” 행동에 의존하게 된다. 사용자는 주어진 시간 동안 실행되는 쓰레드의 숫자가 쓰레드 스택이 글러벌 데이터와 충
돌하지 않을 만큼 충분히 작다는 것을 확인할 수 있는 측정 도구를 필요로 한다. Mysqld과 함께, 여러분은 max_connections 변수
에 적당한 값을 설정함으로써 이렇게 동작되도록 해야 한다.
여러분 스스로 MySQL을 설정 한다면, 스택을 보다 잘 활용할 수 있도록 리눅스쓰레드를 패치할 수 있다. Section 2.12.1.3, “리

:::MySQL Korea:::
눅스 소스배포판 노트”를 참조할 것. 리눅스쓰레드를 패치하고 싶지 않다면, max_connections가 500 보다 크지 않도록 설정해
야 한다. 이것은 여러분이 대용량 키 버퍼, 대용량 데이터 테이블, 또는 mysqld에 많은양의 메모리를 할당해 주는 다른 어떤 것을
갖고 있다 하더라도, 또는 여러분이 2GB의 패치와 함께 2.2.커널을 구동 시키고 있다고 하더라도 마찬가지 인다. 우리가 제공하는
바이너리 또는 RPM 버전을 사용 중이라면, 여러분은 대량의 데이터를 가진 대용량 키 버퍼 또는 테이블이 없다는 가정하에 안심하
고 max_connections 를 1500으로 설정할 수가 있다. 리눅스쓰레드에서 STACK_SIZE의 크기를 줄이면 줄일수록 여러분은 쓰레
드를 더 안정적으로 생성할 수 있게 된다. 우리는 128KB 와256KB 사이의 값을 권장한다.
여러분이 많은 수의 동시 접속을 사용한다면, 아마도 2.2. 커널이 갖고 있는 “특성”인 프로세스 포킹(forking) 또는 클론닝
(cloning)을 방해하는 기능 때문에 곤란을 겪을 것이다. 이것으로 인해 MySQL은 동시 클라이언트의 숫자를 확장할 수가 없게 된
다. 단일-CPU 시스템에서, 우리는 매우 느린 속도의 쓰레드 생성을 경험하였다; MySQL에 접속하는데에 많은 시간이 걸리게 되
며(1분 정도 소요됨), 또한 셧 다웃을 할 때에도 마찬가지로 오래 걸린다. 다중-CPU 시스템에서는, 클라이언트의 수가 늘어날수
록 쿼리의 속도가 점진적으로 느려진다는 것을 경험했다. 해결책을 찾는 과정에서, 우리는 이러한 문제를 자신의 사이트에서 해결
한 사용자로부터 패치를 받게 되었다. 이 패치는 http://www.mysql.com/Downloads/Patches/linux-fork.patch에서 얻을 수 있
다. 우리는 이 패치가 아무런 문제를 발생시키지 않고 MySQL의 성능을 향상시킨다는 것을 테스트를 통해 알게 되었기 때문에 2.2.
커널에서 고 부하 서버를 구동시키는 사용자들이 이것을 사용할 것을 권장한다.
이 문제는 2.4커널에서는 해결이 되었기 때문에, 만약에 여러분이 아직도 현재의 성능에 만족을 느끼지 못한다면, 2.2 커널을 패치
하기 보다는 2.4 커널로 업그레이드하는 것이 훨씬 쉬울 것이다. SMP시스템에서는, 업그레이드를 통해 버그 패치뿐만 아니라 보
다 나은 성능 개선을 제공 받을 것이다.
우리는 MySQL을 2.4 커널과 2 CPU 머신에서 테스트 하였으며, MySQL이 보다 개선되었음을 알게 되었다. 클라이언트 1,000개
까지는 쿼리 처리율(throughput)에서 어떠한 감소 현상도 없었으며, MySQL 성능 요소는 180%까지 증가하였다. 우리는 4-
CPU 시스템에서도 비슷한 결과를 얻었다: 클라이언트 1,000개 까지는 쿼리 처리율(throughput)에서 어떠한 감소 현상도 없었으
며, MySQL 성능 요소는 300%까지 증가 하였다. 이러 결과를 근거로, 2.2 커널을 사용하는 고 부하 SMP서버에 대해서는, 결론적
으로 2.4커너로 업그레이드를 할 것을 권장하는 것이다.
우리는 mysqld 프로세스를 2.4 커널에서 동작 시킬 때에는 가능한 한 최고의 우선 순위를 가지고 진행하는 것이 최대의 성능을 얻
는데 필수적이라는 것을 알게 되었다. 이것은 renice -20 $$ 명령어를 mysqld_safe에 추가해서 진행하면 된다. 4-CPU 시스템
에서 진행한 우리의 테스트에서, 우선 순위를 증가 시킴으로써 60%의 처리율 개선 효과를 400개 클라이언트까지 볼 수 있었다.
여러분이 ps 를 갖고 있는 비활성화된 mysqld 서버 프로세스를 보게 된다면, 이것은 일반적으로 MySQL의 버그이거나, 깨진 테이

:::MySQL Korea:::
블을 가지고 있음을 의미하는 것이다. Section A.4.2, “What to Do If MySQL Keeps Crashing”를 참조할 것.
mysqld 이 SIGSEGV 라는 시그널을 가지고 죽어 있을 경우에 리눅스에서 코어 덤프를 하기 위해서는, mysqld 을 --core-file
옵션을 가지고 시작한다. ulimit -c 1000000를 mysqld_safe에 추가해서 코어 파일의 크기를 늘려야 하거나, 또는 mysqld_safe
를 --core-file-size=1000000을 가지고 시작해야 한다는 것을 알아 두기 바란다. Section 5.4.1, “mysqld_safe — MySQL
서버 스타트업 스크립트”를 참조할 것.

:::MySQL Korea:::
제목검색
2.12.1.5. 리눅스 x86 노트

2.12. OS 관련 노트 MySQL은 libc 5.4.12 또는 그 이상의 버전을 요구한다. 현재까지는 libc 5.4.46과 구동이 잘 되는 것으로 알려져 있으며, glibc
2.12.1 리눅스 노트 2.0.6 과 이후 버전과도 잘 동작하고 있다. 하지만, 레드헷이 제공하는 glibc RPM과는 몇가지 문제가 있는데, 만약에 이럴 경우에
2.12.1.1 리눅스 OS 노트 는, 업데이트 사항을 검토하기 바란다. glibc 2.0.7-19 과2.0.7-29 RPM은 잘 구동되는 것으로 알려져 있다.

여러분이 레드헷8.0 또는 새로운 glibc 2.2.x 라이브러리를 사용하고 있다면, mysqld이 gethostbyaddr()에서 동작되지 않는다는
것을 볼 수 있을 것이다. 이것은 새로운 glibc 라이브러리가 스택 크기를 128KB 보다 크게 요청하기 때문이다. 이 문제를 해결하
기 위해서는, mysqld을 --thread-stack=192K 옵션과 함께 사용한다. (MySQL 4이전 버전일 경우에는, -O
2.12.1.5 리눅스 x86 노트
thread_stack=192K.) 이 스택 크기는 4.0.10과 이후 버전에서 디폴트로 사용하는 것이며, 더 이상 문제를 보지 않을 것이다.
2.12.1.7 리눅스 Alpha 노트 gcc 3.0 및 이후 버전을 사용해서 MySQL을 컴파일 할 경우에는, 컴파일을 하기 전에 반드시 libstdc++v3 라이브러리를 설치해
2.12.1.8 리눅스 PowerPC 노트 야 한다; 이렇게 하지 않으며, 링크를 진행하는 동안 __cxa_pure_virtual 심볼 누락 에러를 보게 된다.
2.12.1.10 리눅스 IA-64 노트 어떤 구형 리눅스 배포판에서는, configure 가 아래와 같은 에러를 만들어 낼 수도 있다:
Syntax error in sched.h. Change _P to __P in the
/usr/include/sched.h file.
See the Installation chapter in the Reference Manual.
에러 메시지가 말하는 대로 실행해 본다. _P 매크로에 밑줄(underscore)을 하나 추가한 다음에 다시 실행한다.
컴파일할 때 에러가 또 나올 수도 있는데, 아래에서 보이는 것은 무시해 버린다:

:::MySQL Korea:::
mysqld.cc -o objs-thread/mysqld.o
mysqld.cc: In function `void init_signals()':
mysqld.cc:315: warning: assignment of negative value `-1' to
`long unsigned int'
mysqld.cc: In function `void * signal_hand(void *)':
mysqld.cc:346: warning: assignment of negative value `-1' to
`long unsigned int'
Mysqld이 시작될 때마다 코어를 덤프한다면, 이것은 여러분이 구형 /lib/libc.a를 가지고 있기 때문에 발생되는 문제이다. 이것을
재 명명(rename)하고, 그 다음에 sql/mysqld를 삭제하고 새로운 make install 을 한 다음에 다시 실행한다. 이 문제는 슬랙웨어
(Slackware)를 설치할 때 발생된다고 보고되고 있다.
Mysqld을 링크할 때 아래와 같은 에러가 발생하면, 이것은 여러분이 사용하는libg++.a 가 제대로 설치되지 않았다는 것을 의미하
는 것이다:
/usr/lib/libc.a(putc.o): In function `_IO_putc':
putc.o(.text+0x0): multiple definition of `_IO_putc'
아래와 같이 configure를 구동시킴으로서 libg++.a 를 사용하는 것을 피할 수 있다:
shell> CXX=gcc ./configure

:::MySQL Korea:::
이하에 대해서는 Skip함
● 2.12.1.6 리눅스 SPARC 노트 - Skip

● 2.12.1.7 리눅스 Alpha 노트 - Skip
● 2.12.1.8 리눅스 PowerPC 노트 - Skip
● 2.12.1.9 리눅스 MIPS 노트 - Skip
● 2.12.1.10 리눅스 IA-64 노트 - Skip

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.12.1.6 리눅스 SPARC 노트 -

Skip
2.12. OS 관련 노트
2.12.1 리눅스 노트
2.12.1.1 리눅스 OS 노트
2.12.1.5 리눅스 x86 노트
2.12.1.10 리눅스 IA-64 노트
:::MySQL Korea:::
제목검색
2.13. Perl 설치 노트
2. MySQL 설치 및 업그레이드 하기 2.13.1. 유닉스에 Perl 설치하기

2.13. Perl 설치 노트 2.13.2. 윈도우에 ActiveState Perl 설치하기
2.13 Perl 설치 노트 2.13.3. Perl DBI/DBD 인터페이스 사용상의 문제점
2.13.1 유닉스에 Perl 설치하기 MySQL을 지원하는 Perl은 DBI/DBD 클라이언트 인터페이스의 형태로 제공된다. 이 인터페이스는 Perl 5.6.1 또
2.13.2 윈도우에 ActiveState Perl 설치하기 는 이후 버전을 요구한다. 여러분이 구형 Perl버전을 가지고 있다면 구동이 되지 않을 것이다.
2.13.3 Perl DBI/DBD 인터페이스를 사용하는데 있어서의 문제점 Perl DBI 트랜젝션을 사용하고자 한다면, DBD::mysql 버전 1.2216 또는 이후 버전이 필요하게 된다. DBD::
mysql 2.9003 도는 이후 버전을 권장한다.
MySQL 4.1 또는 이후 버전의 클라이언트 라이브러리를 가지고 있다면, DBD::mysql 2.9003 또는 이후 버전을 사
용해야 한다.
Perl에 대한 지원은 MySQL 배포판에는 포함되어 있지 않다. 여러분은 필요한 유닉스에 모듈은 http://search.
cpan.org 에서 얻을 수 있으며, 또는 윈도우에서 ActiveState ppm 프로그램을 사용해서 얻을 수 있다. 다음의 섹
션에서는 이것을 어떻게 사용하는지에 대해 설명하기로 한다.
Perl support for MySQL을 위한 Perl 지원은 여러분이 MySQL벤치마크 스크립트를 구동시키고자 한다면 반드
시 설치 되어 있어야 한다. Section 7.1.4, “MySQL 벤치마크 슈트”를 참조할 것.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.13.1. 유닉스에 Perl 설치하기
2.13. Perl 설치 노트 MySQL의 Perl 지원은 여러분이 MySQL클라이언트 프로그래밍 지원을 설치해 둘 것을 요구한다(라이브러리 및 헤더 파일들). 대
2.13.1 유닉스에 Perl 설치하기 부분의 설치 방법들은 필요한 파일들을 설치한다. 하지만, 리눅스에서 RPM으로 MySQL을 설치한 경우라면, 여러분이 개발자
(developer) RPM을 설치했는지 확인하기 바란다. 클라이언트 프로그램은 클라이언트 RPM에 있지만, 클라이언트 프로그래밍 지
원은 개발자 RPM에 들어 있다.
Perl 지원을 설치하고자 한다면, 여러분은 필요한 파일들을 http://search.cpan.org에 있는 CPAN (Comprehensive Perl
Archive Network)에서 찾을 수가 있다.
유닉시에 Perl 모듈을 설치하는 가장 쉬운 방법은 CPAN 모듈을 사용하는 것이다. 예를 들면:
shell> perl -MCPAN -e shell
cpan> install DBI
cpan> install DBD::mysql
DBD::mysql 설치는 많은 수의 테스트를 구동 시킨다. 이러한 테스트들은 디폴트 사용자 이름과 패스워드를 사용해서 로컬
MySQL서버에 접속을 시도한다. (디폴트 사용자 이름은 여러분이 유닉스에서 로그인한 이름이며, 윈도우에서는 ODBC이다. 디폴
트 패스워드는 “no password”이다.) 만약에 이러한 값들을 가지고 서버에 접속하는데 실패한다면(예를 들면, 계정에 패스워드
가 설정되어 있다면), 테스트는 실패하게 된다. 이때에는 force install DBD::mysql 를 사용해서 실패한 테스트를 무시하도록 한
다.
DBI는 Data::Dumper 모듈을 필요로 한다. 이 모듈은 아마도 설치되어 있을 것이다; 만약에 설치되지 않았다면, 여러분은 DBI을
설치하기 전에 이것을 설치해 두어야 한다.

:::MySQL Korea:::
압축 tar 아카이브 형태로 모듈 배포판을 다운 로드해서 수동으로 설치하는 것도 가능하다. 예를 들면, DBI 베포판을 풀어서 설치
를 한 다음에, 아래의 과정을 진행한다:
1. 배포판을 풀어서 현재 디렉토리에 저장한다:
2. shell> gunzip < DBI-VERSION.tar.gz | tar xvf -
이 명령어는 DBI-VERSION이라는 이름의 디렉토리를 생성한다.

3. 풀어 놓은 배포판의 최상위 디렉토리로 이동 한다.:
4. shell> cd DBI-VERSION
5. 배포판을 설치하고 모든 것을 컴파일 한다:
6. shell> perl Makefile.PL
7. shell> make
8. shell> make test
9. shell> make install
make test 명령어는 중요한데, 왜냐하면 이 명령어가 모듈이 제대로 동작하는지를 검증을 하기 때문이다. DBD::mysql을 설치하
는 동안 이 명령어가 인터페이스 코드를 실행하도록 구동시키면, MySQL 서버는 구동될수 도 있지만 테스트가 실패할 수도 있다
는 점을 알기 바란다.
여러분이 새로운 릴리즈의 MySQL을 설치할 때마다, 특히 여러분이 MySQL을 업그레이드한 후에 모든 DBI 스크립트가 실패하는
것을 보게 될 경우에는, DBD::mysql 배포판을 항상 재 설치하고 재 구축하는 것이 바람직한 일이다.
여러분이 시스템 디렉토리에 Perl 모듈을 올바르게 설치하기 위한 접속 권한을 갖고 있지 않거나 또는 로컬 Perl 모듈을 설치하고
싶을 경우에는, 아래의 레퍼런스가 도움이 많이 될 것이다: http://servers.digitaldaze.com/extensions/perl/modules.

:::MySQL Korea:::
html#modules
“Installing New Modules that Require Locally Installed Modules.”라는 제목의 내용을 잘 살펴보기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 2.13.2. 윈도우에 ActiveState Perl 설치하기
2.13. Perl 설치 노트 윈도우에서는, MySQL DBD 모듈을 ActiveState Perl과 함께 설치하기 위해서는 아래의 과정을 따라서 해야 한다:
2.13.2 윈도우에 ActiveState Perl 설치하기

1. ActiveState Perl 을 http://www.activestate.com/Products/ActivePerl/ 에서 다운 로드한 다음에 설치한
다.
2. 콘솔 윈도우를 연다(“DOS window”).
3. 필요하다면, HTTP_proxy 변수를 설정한다. 예를 들면, 아래와 같이 설정할 수 있을 것이다:
4. set HTTP_proxy=my.proxy.com:3128
5. PPM 프로그램을 시작한다:
6. C:￦> C:￦perl￦bin￦ppm.pl
7. 아직 설치를 하지 않았다면, DBI를 설치한다:
8. ppm> install DBI
9. 성공하였다면, 아래의 명령어를 실행한다:
10. install ￦
11. ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd
이 과정은 ActiveState Perl 5.6 또는 이후 버전에서는 올바르게 동작한다.

:::MySQL Korea:::
만약에 위의 과정이 제대로 진행되지 않으면, 대신에 MyODBC 드라이버를 설치하고 ODBC를 통해 MySQL 서버에 접속한
다:
use DBI;
$dbh= DBI->connect("DBI:ODBC:$dsn",$user,$password) ||
die "Got error $DBI::errstr when connecting to $dsn￦n";

:::MySQL Korea:::
제목검색
2.13.3. Perl DBI/DBD 인터페이스를 사용하는데 있어서의 문제점

2.13. Perl 설치 노트 만약에 Perl이 ../mysql/mysql.so 모듈을 찾을 수 없다면, 문제는 아마도 Perl이 libmysqlclient.so 공유 라이브러리를 가져오지
2.13.3 Perl DBI/DBD 인터페이스를 사용하는데 못했기 때문일 것이다. 여러분은 아래에 열거된 방법중에 하나를 가지고 이 문제를 해결해야 한다:
있어서의 문제점
● DBD::mysql 배포판을 컴파일 할 때, perl Makefile.PL 를 사용하지 말고, perl Makefile.PL -static -config 를 사용한
다.
● libmysqlclient.so 를 여러분의 다른 공유 라이브러리가 저장되어 있는 디렉토리에 복사 한다(아마도 /usr/lib 또는 /lib).
● Modify used to compile DBD::mysql을 컴파일할 때 사용하는 -L 옵션을 수정해서 libmysqlclient.so의 실제 위치를 반
영하도록 만든다.
● 리눅스에서는, libmysqlclient.so 가 저장되어 있는 디렉토리의 경로 이름을 /etc/ld.so.conf 파일에 추가 한다.
● libmysqlclient.so 가 저장되어 있는 디렉토리의 경로 이름을 LD_RUN_PATH 환경 변수에 추가 한다. 어떤 시스템에서는
이것 대신에 LD_LIBRARY_PATH 를 사용하기도 한다.
만약에 링커가 찾는데 실패하는 다른 라이브러리가 있다면 -L 옵션을 수정할 필요도 있다는 점을 알기 바란다. 예를 들면, 링커
가 /lib 에 있고 링크 명령어가 -L/usr/lib /lib를 지정하고 있기 때문에 libc 를 찾는데 실패하면, -L 옵션을 -L/lib 로 변경하거나
또는 -L/lib 를 존재하는 링크 명령어에 추가한다.
DBD::mysql에서 아래와 같은 에러를 보게 되면, 여러분은 아마도 gcc 를 사용하고 있는 것이다(또는 gcc로 컴파일된 구형 바이너
리들을 사용하는 것이다):
/usr/bin/perl: can't resolve symbol '__moddi3'
/usr/bin/perl: can't resolve symbol '__divdi3'
mysql.so 라이브러리가 구축될 때 -L/usr/lib/gcc-lib/... –lgcc를 링크 명령어에 추가한다(여러분이 Perl클라이언트를 컴파일

:::MySQL Korea:::
할 때 mysql.so 에 대해서 make가 만드는 결과를 검사한다). -L 옵션은 여러분의 시스템에 libgcc.a 이 저장되어 있는 디렉토리
의 경로 이름을 지정해 주어야 한다.
이 문제에 대한 다른 원인은 Perl과 MySQL이 모두 gcc로 컴파일 되지 않았다는 것을 의미할 수도 있다. 이와 같은 경우에는, 두
가지 모두를 gcc를 가지고 컴파일해서 불일치 되는 문제를 해결하면 된다.
테스트를 진행하는 동안에 DBD::mysql에서 아래의 에러를 볼 수도 있다:
t/00base............install_driver(mysql) failed:
Can't load '../blib/arch/auto/DBD/mysql/mysql.so' for module DBD::mysql:
../blib/arch/auto/DBD/mysql/mysql.so: undefined symbol:
uncompress at /usr/lib/perl5/5.00503/i586-linux/DynaLoader.pm line 169.
이것은 -lz 암축 라이브러리를 링크 라인에 포함시킬 필요가 있음을 의미하는 것이다. 이것은 lib/DBD/mysql/Install.pm에 있는
아래의 라인을 변경해서 해결할 수 있다:
$sysliblist .= " -lm";
위의 라인을 아래와 같이 변경한다:
$sysliblist .= " -lm -lz";
이렇게 한 후에, 여러분은 반드시 make realclean 를 실행해야 하고 그 다음에는 처음부터 설치 과정을 진행한다.

:::MySQL Korea:::
제목검색
Chapter 3. 사용 설명서
3. 사용 설명서 3.1. 서버에 접속하기 및 접속 종료하기
3 사용 설명서 3.2. 쿼리 입력하기
3.1 서버에 접속 하기와 접속 종료하기 3.3. 데이터 베이스 생성 및 사용하기

3.3.1. 데이터 베이스 생성 및 선택하기
3.2 쿼리 입력 하기
3.3.2. 테이블 생성하기
3.3 데이터베이스 생성 및 사용하기
3.3.3. 테이블에 데이터 로딩하기
3.3.1 데이터 베이스 생성 및 선택하기
3.3.4. 테이블에서 정보 가져오기
3.3.2 테이블 생성하기
3.4. 데이터 베이스와 테이블에 관한 정보 얻기
3.3.3 테이블에 데이터 넣기
3.5. 배치(Batch) 모드에서 mysql 사용하기
3.3.4 테이블에서 정보를 불러오기
3.6. 일반적인 쿼리의 예
3.3.4.1 모든 데이터 선택하기
3.6.1. 컬럼의 최대 값
3.3.4.2 특정 줄 선택하기 3.6.2. 특정 컬럼의 최대 값을 가지고 있는 줄(Row)
3.3.4.3 특정 컬럼 선택하기 3.6.3. 그룹 당 컬럼의 최대 값
3.3.4.5 데이터 계산하기 3.6.4. 특정 필드의 그룹-와이즈(Group-wise) 최대 값을 가지고 있는 줄(Rows)
3.3.4.6 NULL 값을 가지고 작업하기 3.6.5. 사용자 정의 변수 사용하기
3.3.4.7 패턴 매칭 3.6.6. 외국어 키 사용하기
3.3.4.8 줄 세기 3.6.7. 두 개의 키상에서 검색하기
3.3.4.9 한 개 이상의 테이블 사용하기 3.6.8. 일별 방문자수 계산하기
3.3.4.4 줄 정렬하기 3.6.9. AUTO_INCREMENT 사용하기

3.7. 쌍둥이 프로젝트에서의 쿼리
3.4 데이터 베이스와 테이블에 대한 정보 얻기
3.7.1. 모든 논-디스트리뷰티드(Non-distributed) 쌍둥이 찾기
3.5 배치(Batch)모드에서 mysql 사용 하기
3.7.2. 쌍둥이 상태 테이블 보이기
3.6 일반적인 쿼리의 예제들(Examples)
3.8. 아파치(Apache)에서 MySQL 사용하기
3.6.1 컬럼에 대한 최대 값(Maximum Value)

:::MySQL Korea:::
3.6.2 특정 컬럼의 최대값을 갖고 있는 줄(Row) 이 장에서는 mysql 클라이언트 프로그램을 사용해서 간단한 데이터 베이스를 만들고 사용하는 방법을 보여 줌으
3.6.3 그룹별 최대 컬럼 수(Maximum of Column per Group) 로써 MySQL의 사용법을 설명하기로 한다. mysql (때에 따라서 “terminal monitor” 또는 그냥
3.6.4 특정 필드의 그룹 와이즈(Group-wise) 최대값을 갖는 줄 “monitor”로 불리기도 함)은 여러분이 MySQL서버에 연결하고, 쿼리를 구동 시키고, 결과를 볼 수 있도록 하
여 주는 쌍방향(interactive)프로그램이다. mysql은 배치(batch)모드에서도 사용할 수 있다: 여러분은 쿼리를
3.6.5 사용자 정의 변수 사용하기(Using User-Defined Variables)
파일 안에 미리 만들어 놓고, mysql이 이 파일의 내용을 실행하게끔 할 수 있다. 여기에서는 이러한 두 가지의
3.6.6 외국어 키(Foreign Keys) 사용하기
mysql 사용 방법에 대해 설명하기로 한다.
3.6.7 두 개의 키(Two Keys)상에서 검색
3.6.8 일별 방문자수 계산하기(Calculating Visits Per Day)
mysql에서 사용할 수 있는 옵션의 종류를 보기 위해서는, --help 과 함께 이것을 호출하면 된다:
3.6.9 AUTO_INCREMENT사용하기
3.7 쌍둥이 프로젝트에서의 쿼리(Queries from the Twin Project) shell> mysql --help
3.8 아파치와 함께 MySQL 사용하기
이 장에서는 mysql 이 여러분의 머신에 설치되어 있고, 여러분은 MSQL 서버에 연결할 수 있다고 가정한다. 만
약에 이러한 상황이 아니라면, MySQL관리자에게 연락을 해서 위의 가정이 이루어 지도록 해야 한다. (여러분
이 관리자의 입장이라면, 이 설명서의 관련 부분을 잘 숙지하고 있어야 한다. Chapter 5, 데이터 베이스 관리.를
참조할 것)
이 장에서는 데이터 베이스를 설정하고 사용하는 전체 과정에 대해 설명을 한다. 만약에 현재 있는 데이터 베이
스에 접속하는 부분에 대해서만 관심이 있다면, 데이터 베이스 및 테이블 생성 방법에 대한 부분은 건너 띄어도
된다.
이 장은 원론적인 사용 설명서이기 때문에, 많은 부분에서 상세한 기술은 하지 않을 것이다. 여기에서 다루는 주

제에 대해 보다 자세한 정보를 얻기 위해서는 관련된 장을 참조하기 바란다.

:::MySQL Korea:::
제목검색
3.1. 서버에 접속 하기와 접속 종료하기
3. 사용 설명서
서버에 연결하기 위해서는, mysql을 호출할 때 보통은 서버의 사용자 이름과 패스워드를 넣어주어야 한다. 만약에 여러분이 로그
3.1. 서버에 접속 하기와 접속 종료하기
인 한 서버가 아닌 머신에서 서버가 구동 된다면, 호스트 이름도 같이 지정해 주어야 한다. 어떤 파라미터를 사용해서 서버에 연결
3.1 서버에 접속 하기와 접속 종료하기
할 수 있는지는 서버 관리자에게 문의하면 된다(즉, 사용할 수 있는 호스트 이름, 사용자 이름 및 패스위드). 올바른 파라미터 값을
알고 나면, 아래와 같이 서버에 연결할 수 있게 된다:
shell> mysql -h host -u user -p
Enter password: ********
host 및 user는 여러분의 MySQL서버가 돌아가고 있는 호스트의 이름 과 MySQL 계정에 있는 사용자 이름을 나타낸다. 여러분
이 설정한 것으로 입력하면 된다. ******** 는 패스워드를 말하는 것이다; mysql 이 Enter password: 프롬프트를 나타내면 입력
을 한다.
이렇게 하고 나면, 여러분은 여러 가지의 자료를 보게 되며 mysql> prompt가 뒤따라 나오게 된다:
shell> mysql -h host -u user -p
Welcome to the MySQL monitor. Commands end with ; or ￦g.
Your MySQL connection id is 25338 to server version: 5.0.19-standard

:::MySQL Korea:::
Type 'help;' or '￦h' for help. Type '￦c' to clear the buffer.
mysql>
mysql> 프롬프트는 여러분이 이제 mysql에 명령어를 입력할 수 있게 되었음을 말하는 것이다.
여러분이 MySQL이 구동 되고 있는 머신에 로그인을 한다면, 호스트 이름을 생략하고, 간단히 아래와 같이 입력을 하면 된다:
shell< mysql -u user -p
만약에, 로그인을 시도할 때, ERROR 2002 (HY000): Can't connect to local MySQL server through socket '/tmp/mysql.
sock' (2)과 같은 에러가 나오면, 이것은 해당 MySQL서버의 데몬(유닉스) 또는 서비스(윈도우)가 동작되지 않고 있음을 의미하
는 것이다. 이럴 경우에는 서버 관리자의 도움을 받거나 Chapter 2, MySQL 설치 에서 여러분의 OS에 해당하는 부분을 참조하기
바란다.
로그인 할 때에 종종 나타나는 문제를 해결 하기 위해서는, Section A.2, “Common Errors When Using MySQL
Programs”를 참조하기 바란다.
어떤 MySQL 설치 버전에서는 사용자가 로컬 호스트에서 돌아가는 서버에 익명으로 접속할 수 있도록 하는 것들도 있다. 여러분
이 이런 경우에 해당된 다면, 다른 옵션이 없이도 서버에 연결할 수 있을 것이다:
shell> mysql
서버에 성공적으로 접속을 한 후에는, 언제든지 QUIT (또는 ￦q)을 mysql> 프롬프트에 입력해서 서버와의 연결을 끊을 수 있게
된다:
mysql> QUIT
Bye

:::MySQL Korea:::
유닉스에서는, Control-D를 사용해서 연결을 끊을 수도 있다.
이어지는 섹션에서 보여주는 대부분의 예제들은 여러분이 서버에 올바르게 연결되어 있다는 가정을 한다. 이것들은 mysql> 프롬
프트를 통해 이런 상태를 보여 줄 것이다.

:::MySQL Korea:::
제목검색
3.2. 쿼리 입력 하기
3. 사용 설명서
이전 섹션에서 설명 하였듯이 여러분은 서버에 연결 되어 있어야 한다. 이렇게 하는 것이 자체적으로는 특정 데이터 베이스를 선택
3.2. 쿼리 입력 하기
한 것은 아니지만, 이 상태로도 충분하다. 이 단계에서는, 테이블을 생성하고, 테이블 속으로 데이터를 넣고, 그리고 테이블에서 데
3.2 쿼리 입력 하기
이터를 가져오는 방법 보다는 쿼리를 만드는 방법에 대해 배우는 것이 보다 중요한 단계가 된다. 이 섹션에서는, mysql 이 어떻게
동작되는지에 대해 여러분이 정확히 알고 있는 몇몇 쿼리를 사용해서, 명령어 입력의 기본 원칙에 대해 설명하기로 한다.
여기에 있는 간단한 명령어는 서버가 현재의 날짜와 버전을 보여주도록 하는 것이다. 여기에 있는 대로 mysql> 프롬프트 다음에
입력을 한 후 엔터키(Enter)를 누른다:
mysql> SELECT VERSION(), CURRENT_DATE;
+----------------+--------------+
| VERSION() | CURRENT_DATE |
+----------------+--------------+
| 5.0.7-beta-Max | 2005-07-11 |
+----------------+--------------+
1 row in set (0.01 sec)
mysql>
이 쿼리는 mysql에 대한 몇 가지 내용을 설명하고 있다:

:::MySQL Korea:::
• 일반적으로 명령어는 세미콜론을 갖고 있는 SQL명령문으로 구성된다. (세미 콜론이 생략되는 예외적이 경우도 있
다. 앞에서 언급한 QUIT 의 경우가 이 중 하나이다. 다른 것들은 나중에 보기로 한다.)
• 명령어를 입력할 때, mysql은 이 명령어를 서버에 보내서 실행을 하도록 하며 그 결과를 화면에 보여주며, 그 다음에
는 또 다른 mysql> 프롬프트를 보여주어서 다른 명령어를 받아들일 준비가 되었음을 알려준다.
• mysql는 쿼리의 결과를 표 형식(열과 행이 있는)으로 보여 준다. 첫 번째 열은 행의 레이블을 갖고 있다. 뒤따라오

는 열은 쿼리의 결과 값이다. 일반적으로, 컬럼 레이블은 데이터 베이스에서 가져오는 컬럼의 이름이 된다. 만약에 위에서
보여준 것과 같은 테이블 컬럼이 아니라 수식 결과값을 얻으려면, mysql 레이블은 수식 자체가 된다.
• mysql 은 얼마나 많은 줄을 생성하고 쿼리를 처리하는데 얼마의 시간이 소모되었는지에 대한 정보를 보여 주는데,
이러한 것들은 서버의 성능에 대한 대략적인 정보를 제공해 준다. 이러한 값들은 정확한 값들이 아닌데, 왜냐하면 대략적
인 처리 시간(CPU, 머신 타임이 아님)만을 나타내고, 서버의 로드 및 네트워크의 성능에 영향을 받기 때문이다.(간단히
말해서, “rows in set” 라인은 종종 이 장의 나머지 예제에서는 나타나지 않는다.)
키워드들은 어떤 문자 형식(대/소 문자)로도 입력할 수 있다. 아래의 쿼리는 모두 동일하다:
mysql> SELECT VERSION(), CURRENT_DATE;
mysql> select version(), current_date;
mysql> SeLeCt vErSiOn(), current_DATE;
여기에 또 다른 쿼리가 있다. 이 쿼리는 mysql을 간단한 계산기로 사용하는 예를 나타내는 것이다:
mysql> SELECT SIN(PI()/4), (4+1)*5;
+------------------+---------+
| SIN(PI()/4) | (4+1)*5 |
+------------------+---------+

:::MySQL Korea:::
| 0.70710678118655 | 25 |
+------------------+---------+
지금까지 보여진 쿼리들은 상대적으로 간단한, 단일 라인 명령문들이었다. 하나의 라인에 여러 개의 명령문을 입력하는 것도 가능
하다. 각각의 명령문들은 세미콜론으로 구분한다:
mysql> SELECT VERSION(); SELECT NOW();
+----------------+
| VERSION() |
+----------------+
| 5.0.7-beta-Max |
+----------------+
+---------------------+
| NOW() |
+---------------------+
| 2005-07-11 17:59:36 |

:::MySQL Korea:::
+---------------------+
명령어는 하나의 라인에서만 표현될 필요는 없고, 여러 라인을 필요로 하는 기다란 명령어를 입력하는 것도 문제가 없다. mysql은
여러분이 입력하는 명령문을 입력 라인의 끝으로 구분하는 것이 아니라, 명령문의 끝을 가리키는 세미콜론을 가지고 구분하게 된
다. (다른 말로 표현하자면, mysql는 프리-포맷(free-format) 입력을 수용한다: mysql은 세미콜론이 나타나지 않으면 모든 입
력 라인을 실행하지 않는다.)
여기에 간단한 다중 라인 명령문이 있다:
mysql> SELECT
-> USER()
-> ,
-> CURRENT_DATE;
+---------------+--------------+
| USER() | CURRENT_DATE |
+---------------+--------------+
| jon@localhost | 2005-07-11 |
+---------------+--------------+
이 예문에서, 여러분이 다중 라인 쿼리의 처음 라인을 입력한 후에 프롬프트가 mysql>에서 ->로 변하는 것을 주목하자. 이것은
mysql이 아직 완전한 명령문을 가지지 않았으며 나머지 부분이 입력되기를 기다리고 있다는 것을 나타내는 것이다.

:::MySQL Korea:::
만약에 여러분이 명령어를 입력하는 도중에 입력한 명령어를 실행시키고 싶지 않을 경우, ￦c를 통해 취소 명령을 내릴 수 있다:
mysql> SELECT
-> USER()
-> ￦c
mysql>
여기에서도, 역시 프롬프트의 변화를 주목하자. 프롬프트는 ￦c 이후에 mysql>로 다시 복귀되었으며, mysql은 새로운 명령어를
실행할 준비가 되었음을 나타낸다.
아래의 테이블은 여러분이 볼 수 있는 프롬프트의 형태이며, 각 프롬프트가 의미하는 mysql의 상태를 정리한 것이다:
Prompt Meaning
mysql> 새로운 명령어를 위한 준비.
-> 다중 라인 명령어의 다음 라인 대기 상태.
'> 단일 인용 부호(‘'’)로 시작된 문장의 완결을 위한 다음 문장 대기.
"> 복수 인용 부호(‘"’)로 시작된 문장의 완결을 위한 다음 문장 대기.
`> 역 인용 부호(‘`’)로 시작된 식별자(identifier)의 완결을 위한 다음 문장 대기 .
/*> /*로 시작된 코멘트 문장(comment)의 완결을 위한 다음 문장 대기.
MySQL 5.0 시리즈에서, /*> 프롬프트는 MySQL 5.0.6에서부터 구현된다.
다중 라인 명령문들은 주로 여러분이 단일 라인 명령문을 입력한 후에 실수로 세미콜론을 입력하지 않을 경우에 일어난다. 이러한
경우에, mysql은 입력 사항이 더 있는지를 기다린다:
mysql> SELECT USER()

:::MySQL Korea:::
->
이러한 일이 일어나면(모든 명령어를 다 입력을 하였지만 -> 프롬프트가 나타나면), 대부분의 경우 mysql은 세미콜론을 기다리
고 있는 것이다. 명령문을 완료하기 위한 세미콜론을 입력하게 되면, mysql은 이를 실행한다:
mysql> SELECT USER()
-> ;
+---------------+
| USER() |
+---------------+
| jon@localhost |
+---------------+
'> 과 "> 프롬프트는 문장을 표현할 때 나타난다(다른 말로 표현하면 MySQL은 문장이 완료되길 기다린다). MySQL에서는, 여러
분은 ‘'’ 또는 ‘"’ 문자를 가지고 문장을 쓸 수 있고(예를 들면, 'hello' 또는 "goodbye"), and mysql은 문장을 여러 개의 라인
에 걸쳐 입력할 수 있게 한다. '> 또는 "> 프롬프트를 보게 되면, 이것은 여러분이 ‘'’ 또는 ‘"’로 시작되는 문장의 입력을 시작
했으나, 아직까지 이 문장을 맺기 위해 나머지 인용 부호를 입력하지 않고 있다는 것을 의미한다. 이것은 종종 실수로 인용 부호를
누락하고 있다는 것을 가리켜 주기도 한다. 예를 들면:
mysql> SELECT * FROM my_table WHERE name = 'Smith AND age < 30;
'>
위와 같은 SELECT 명령문을 입력하였다면, Enter를 누르고 결과를 기다린다고 하더라도 아무런 일이 일어나지 않는다. 이 쿼리
가 너무 오래 걸린다고 의심하지 말고, '> 프롬프트가 의미하는 것이 무엇인지를 찾아야 한다. 이 프롬프트는, mysql이 지금 문장
의 완성을 위해 무엇인가를 기다리고 있다는 것을 나타내고 있는 것이다.

:::MySQL Korea:::
이 시점에서, 여러분이 할 수 있는 일은? 가장 간단한 것은 명령을 취소하는 것이다. 하지만, 이와 같은 경우에는 ￦c 만을 입력해
서 종료할 수 없는데, 왜냐하면 mysql은 이것을 문장의 일부분으로 해석하기 때문이다. 이렇게 하는 것 대신에, 문장 종료 문자를
입력하고(mysql이 문장의 끝임을 알게끔), 그 후에 ￦c를 입력한다:
mysql> SELECT * FROM my_table WHERE name = 'Smith AND age < 30;
'> '￦c
mysql>
프롬프트는 다시 mysql>로 변하였고, mysql은 새로운 명령어를 기다리게 된다.
`> 프롬프트는 '> 과 "> 프롬프트와 유사하지만, 여러분이 역방향(backtick-quoted)인용 부호로 시작한 식별자를 완성하지 않
았음을 가리킨다.
'>, ">, 및 `> 프롬프트가 무엇을 의미하는지 알고 있는 것이 중요한데, 왜냐하면 여러분이 실수로 완료(unterminated)가 되지 않
은 문장을 입력한다면, 그 이후의 모든 라인들은- QUIT 을 갖고 있는 문장 포함-mysql에 의해 무시되기 때문이다. 만약에 여러
분이 현재의 명령어를 취소하기 전에 문장 종료용 인용 부호를 입력해야 한다는 것을 모르고 있을 경우에는 특히 혼란을 일으킬 수
있는 사항이다.

:::MySQL Korea:::
제목검색
3.3. 데이터베이스 생성 및 사용하기
3. 사용 설명서 3.3.1. 데이터 베이스 생성 및 선택하기
3.3. 데이터베이스 생성 및 사용하기 3.3.2. 테이블 생성하기
3.3.3. 테이블에 데이터 로딩하기
3.3 데이터베이스 생성 및 사용하기
3.3.4. 테이블에서 정보 추출하기
일단 명령어를 입력하는 방법을 알게 되면, 데이터 베이스에 접근할 준비가 되어진 것이다.
3.3.4 테이블에서 정보를 불러오기 여러분이 집에서 여러 가지의 애완 동물을 기르고 있고 이것들에 대해 여러 가지 정보를 유지하고 싶다고 가정하자.
3.3.4.1 모든 데이터 선택하기 여러분은 테이블을 생성하고 데이터를 넣고 필요한 정보를 읽음으로써 이것을 유지할 수 있게 된다. 이 섹션은 여러분
3.3.4.2 특정 줄 선택하기 이 이러한 것들을 어떻게 할 수 있는지 보여준다:
3.3.4.3 특정 컬럼 선택하기
• 데이터 베이스 생성
3.3.4.5 데이터 계산하기
3.3.4.6 NULL 값을 가지고 작업하기 • 테이블 생성
3.3.4.7 패턴 매칭 • 테이블로 데이터 넣기

3.3.4.8 줄 세기 • 여러 가지 방법으로 데이터를 읽어오기
3.3.4.9 한 개 이상의 테이블 사용하기
• 다중 테이블 사용하기
3.3.4.4 줄 정렬하기
애완 동물 데이터 베이스는 간단한 것이지만, 현실 세계에서 사용되어지는 비슷한 유형의 데이터 베이스를 생각하는
것은 그리 어려운 일이 아니다. 예를 들면, 이와 같은 유형의 데이터 베이스는 농부가 자신의 가축을 관리하는데 사용
할 수 있거나, 수의사가 병든 가축들의 이력을 관리하기 위해서도 사용할 수도 있다. 이 다음의 섹션에서 사용되는 쿼
리와 샘플 데이터들을 갖고 있는 동물 관리용 배포판은 MySQL 웹 사이트에서 쉽게 얻을 수 있다. 이것들은 tar 형태
(http://www.mysql.com/Downloads/Contrib/Examples/menagerie.tar.gz) 및 집(Zip) (http://www.mysql.
com/Downloads/Contrib/Examples/menagerie.zip) 형식으로 되어 있다.

:::MySQL Korea:::
현재 서버에 어떤 데이터 베이스가 있는지 알기 위해 SHOW 명령문을 사용한다:
mysql> SHOW DATABASES;
+----------+
| Database |
+----------+
| mysql |
| test |
| tmp |
+----------+
데이터 베이스 리스트는 여러분이 사용하는 머신에 따라 다르겠지만, mysql과 test 데이터 베이스는 거의 다 포함되
어 있을 것이다. mysql 데이터 베이스는 사용자 접근 권한을 나타내는 것이기 때문에 필요한 것이다. test 데이터 베
이스는 사용자가 무엇을 시험을 해 볼 수 있도록 하기 위해 종종 제공되어지는 것이다.
여러분이 SHOW DATABASES 권한이 없다면 모든 데이터 베이스를 보지는 못할 것이다. Section 13.5.1.3,
“GRANT 신텍스”를 참조할 것.
test 데이터 베이스가 있다면, 이것을 접근하도록 해보자:
mysql> USE test
Database changed
USE는, QUIT과 마찬가지로, 세미콜론을 필요하지 않는다.(이러한 명령문들을 세미콜론으로 종료하는 것도 가능하
기는 하다.) USE 명령문의 사용에는 주의 사항이 하나 있다: 이 명령문은 단일 라인에서만 사용되어야 한다.

:::MySQL Korea:::
여러분은 예제에서와 같이 test 데이터 베이스를 사용할 수 있겠지만, 여러분이 생성한 데이터들은 다른 누군가에 의
해 삭제될 수도 있다. 이러한 이유로, 여러분은 MySQL관리자에게 여러분만의 데이터 베이스를 사용할 수 있는 권한
을 요청해야 할 것이다. 여러분의 menagerie를 호출하고자 한다고 가정하자. 관리자는 다음과 같은 명령어를 실행하
야 할 것이다:
mysql> GRANT ALL ON menagerie.* TO 'your_mysql_name'@'your_client_host';
your_mysql_name 은 여러분이 등록한 사용자 이름이며 your_client_host 는 여러분이 서버에 접속하고 있는 호스

트의 이름이 된다.

:::MySQL Korea:::
제목검색
3.3.1. 데이터 베이스 생성 및 선택하기
3. 사용 설명서
만약에 관리자가 여러분을 위해 권한을 설정할 때 데이터 베이스도 함께 생성을 하였다면, 여러분은 이것을 사용할 수 있게 된 것이
다. 그렇지 않으면, 여러분 스스로 이것을 생성해야 한다:
mysql> CREATE DATABASE menagerie;
유닉스 환경에서는, 데이터 베이스의 이름은 대소 문자를 구분하기 때문에 (SQL 키워드와는 달리), 여러분은 반드시 데이터 베이
스 이름을 menagerie로 해야 한다. Menagerie, MENAGERIE, 또는 다른 변형된 형태를 사용하지 말기 바란다. 이것은 테이블 이
름에서도 동일하다. (윈도우에서는, 이러한 제약이 적용되지 않는다. 하지만, 여러 가지 이유로 인해, 데이터 베이스가 생성될 때 사
용한 문자 크기와 동일한 것을 사용할 것을 권장한다.)
Note: 만약에 데이터 베이스를 생성할 때 ERROR 1044 (42000): Access denied for user 'monty'@'localhost' to database
'menagerie'와 같은 에러가 나온다면, 이것은 여러분 계정이 데이터 베이스를 생성하는데 있어서 충분한 권한이 설정되지 않았음
을 의미하는 것이다. 이럴 경우에는 관리자와 상의를 하거나, Section 5.8, “MySQL 접근 권한 시스템”을 참조하기 바란다.
데이터 베이스 생성은 사용할 데이터 베이스를 선택하지는 않는다; 데이터 베이스를 선택하는 것은 확실하게(explicitly) 한다.
menagerie를 현재의 데이터 베이스로 만들기 위해서는, 이 명령어를 사용한다:
mysql> USE menagerie;
Database changed
여러분의 데이터 베이스가 일단 한번 생성되었다고 하더라도, 이것을 사용하기 위해서는 mysql 세션을 시작할 때마다 이것을 선택
해야 한다. 여러분은 이것을 예제에서 보았듯이 USE 명령문을 사용해서 실행할 수 있다. 다른 방법으로는, mysql 을 호출할 때 명
령어 라인에서 이 데이터 베이스를 선택할 수 있다. 여러분이 입력하고자 하는 연결 파라미터 다음에 데이터 베이스의 이름을 입력

:::MySQL Korea:::
하는 것으로 충분하다. 예를 보자면:
shell> mysql -h host -u user -p menagerie
명령어에 있는 menagerie는 여러분의 패스워드가 아니라는 점을 유의한다. 만약에 명령어의 -p 옵션 다음에 패스워드를 넣기를
원하면, 중간에 공간을 두지 말고 입력을 해야 한다(예를 들면, -pmypassword로 해야 하며, -p mypassword처럼 하면 안된
다). 하지만, 패스워드를 명령어 라인에서 입력하는 것은 권장하지 않는데, 왜냐하면 다른 사람들이 여러분의 머신에서 로그인할 경
우에 이 패스워드가 노출될 수도 있기 때문이다.

:::MySQL Korea:::
제목검색
3.3.2. 테이블 생성하기
3. 사용 설명서
데이터 베이스를 생성하는 것은 쉽지만, 현재까지는 그 안에 아무것도 없다. SHOW TABLES을 입력하면:

mysql> SHOW TABLES;
Empty set (0.00 sec)
보다 어려운 부분은 여러분이 데이터베이스의 구조를 어떻게 만들 것인지 결정해야 하는 것이다: 어떤 테이블이 필요하며 그 안에
어떤 컬럼을 넣어야 하는지에 대해 결정해야 한다.
여러분은 애완 동물 각각에 대한 기록을 갖는 테이블을 원한다. 이것을 pet 테이블이라고 부르고, 각 동물의 이름을 갖고 있다. 이
름 자체는 그다지 흥미로운 것은 아니기 때문에 테이블은 이름 이외의 정보를 가져야 한다. 예를 들면, 여러분의 가족 중에 한 명 이
상이 애완 동물을 기르고 있다면, 각 동물의 주인을 나열하고 싶을 것이다. 또한 여러분은 애완 동물의 종자 및 성별과 같은 기본적
인 내용도 기록하고 싶을 것이다.
나이는? 이것은 흥미로운 정보일지 모르겠지만, 이것을 데이터 베이스에 넣는 것은 그리 좋은 일은 아니라고 생각한다. 나이는 시간
이 지나면서 변하는데, 이것은 여러분이 자주 데이터베이스를 업데이트해야 한다는 것을 의미한다. 대신에, 생일과 같은 변하지 않
는 값을 넣는 것이 더 좋다. 그 다음에는, 나이를 기록하고 싶을 때마다, 여러분은 생일과 현재의 날짜의 차이를 계산하기만 하면 된
다. MySQL은 날짜 계산식을 제공하고 있기 때문에 이것을 계산하는 것은 어려운 작업이 아니다. 나이보다는 생일을 저장하는 것
은 여러 가지 다른 장점도 있게 된다:
• 여러분은 애완 동물의 다가오는 생일을 상기 시키는 리마인더(reminder)로 이 데이터베이스를 사용할 수 있다. (여

러분 생각이 이런 형태의 쿼리가 다소 어리석은 것이라도 여긴다면, 여러분이 이번 주 또는 다음달에 생일 선물을 보내고
자 하는 고객 명단을 데이터 베이스에서 불러와야 할 경우를 생각하자.)
• 여러분은 현재의 날짜가 아닌 일수(dates)로 나이를 계산할 수 있다. 예를 들면, 데이터베이스에 애완 동물이 죽은

:::MySQL Korea:::
날을 저장한다면, 여러분은 쉽게 죽은 동물의 나이를 계산할 수 있을 것이다.
여러분은 이 데이터베이스 테이블에 유용하게 사용될 다른 형태의 정보를 생각할 수 있겠지만, 다음과 같은 것만으로도 충분하자:
name, owner, species, sex, birth, and death.
CREATE TABLE 명령문을 사용해서 테이블의 레이아웃을 지정하도록 한다:
mysql> CREATE TABLE pet (name VARCHAR(20), owner VARCHAR(20),
-> species VARCHAR(20), sex CHAR(1), birth DATE, death DATE);
VARCHAR는 name, owner, 및 species 컬럼용으로는 잘 선택한 것인데, 왜냐하면 컬럼의 값들이 서로 길이가 다르기 때문이다.
이러한 컬럼 정의에서 길이는 모두 같을 필요가 없고, 20이 될 필요도 없다. 여러분 입장에서 가장 적당하다고 생각하는 길이를 1
에서 65535의 사이에서 선택하기만 하면 된다. (Note: MySQL 5.0.3 이전 버전에서는, 최대 한계치는 255 이었다.) 여러분이 처
음에 길이를 잘못 선택하였고 나중에 보다 긴 필드가 필요하게 될 경우에는, MySQL은 ALTER TABLE 명령문을 사용하면 된다.
다른 몇몇 값의 타입들은 애완 동물의 성별을 나타내는 것으로 선택하는데, 'm' 과 'f', 또는 'male' 과 'female'이 될 수도 있다. 단
일 문자 'm' 과 'f'를 사용하는 것이 가장 간편한 방법이다.
birth 와death를 위해 DATE 데이터 타입을 사용하는 것은 매우 잘한 선택이다.
일단 여러분이 테이블을 생성하면, SHOW TABLES 는 다음과 같은 결과를 보여준다:
mysql> SHOW TABLES;
+---------------------+
| Tables in menagerie |
+---------------------+
| pet |

:::MySQL Korea:::
+---------------------+
테이블이 여러분이 의도한 방식으로 생성되었는지 검사하기 위해, DESCRIBE 명령문을 사용해 본다:
mysql> DESCRIBE pet;
+---------+-------------+------+-----+---------+-------+
| Field | Type | Null | Key | Default | Extra |
+---------+-------------+------+-----+---------+-------+
| name | varchar(20) | YES | | NULL | |
| owner | varchar(20) | YES | | NULL | |
| species | varchar(20) | YES | | NULL | |
| sex | char(1) | YES | | NULL | |
| birth | date | YES | | NULL | |
| death | date | YES | | NULL | |
+---------+-------------+------+-----+---------+-------+
여러분은 언제든지 DESCRIBE를 사용할 수 있는데, 예를 들면, 테이블에 있는 컬럼의 이름 또는 그 안에 무엇이 있는지를 잊었을
경우에 사용할 수 있다.
MySQL 데이터 타입에 대한 보다 자세한 정보는, Chapter 11, 데이터 타입을 참조하기 바란다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
3.3.3. 테이블에 데이터 넣기
3. 사용 설명서
테이블을 생성한 다음에는, 여러분은 테이블에 데이터를 넣어야 한다. LOAD DATA 와INSERT 명령문이 이런 작업에서 매우 유
용하게 사용된다.
여러분의 애완 동물 기록이 아래와 같다고 가정하자. (MySQL은 날짜를 'YYYY-MM-DD' 포맷으로 다룬다는 것을 주의한다; 이
것은 여러분이 사용하는 방식과 다를 수도 있다.)
name owner species sex Birth death
Fluffy Harold cat f 1993-02-04
Claws Gwen cat m 1994-03-17
Buffy Harold dog f 1989-05-13
Fang Benny dog m 1990-08-27
Bowser Diane dog m 1979-08-31 1995-07-29
Chirpy Gwen bird f 1998-09-11
Whistler Gwen bird 1997-12-09
Slim Benny snake m 1996-04-29
여러분은 비어있는 테이블을 가지고 시작하고 있기 때문에, 그 안에 데이터를 넣는 쉬운 방법은 각각의 애완 동물에 대한 줄(row)
을 가지는 텍스트 파일을 만든 다음에, 간단한 명령문을 사용해서 파일의 내용물을 읽어 들여서(load) 테이블에 넣는 것이다.
여러분은 라인 당 하나의 기록을 갖고 있고, 각각의 값들은 탭으로 구분되고, CREATE TABLE 명령문에서 컬럼이 나열된 순서로
되어 있는 텍스트 파일 pet.txt을 만들 수 있다. 누락된 값들에 대해서는(성별을 모르거나 아직 살아 있는 동물에 대한 죽은 날짜

:::MySQL Korea:::
등), NULL 값을 사용하면 된다. 텍스트 파일에서 이러한 것들을 표현하기 위해서는, ￦N (backslash, capital-N)를 사용한다. 예
를 들면, Whistler라는 이름의 새에 대해서는 아래와 같이 보이게 된다:
name owner species sex birth death
Whistler Gwen bird ￦N 1997-12-09 ￦N
텍스트 파일 pet.txt를 pet 테이블로 불러 오기 위해서는, 다음의 명령어를 사용한다:
mysql> LOAD DATA LOCAL INFILE '/path/pet.txt' INTO TABLE pet;
여러분이 윈도우에서 ￦r￦n 를 라인 터미네이터로 사용하는 에디터를 가지고 파일을 작성하였다면, 아래와 같은 것을 사용해야 한
다:
mysql> LOAD DATA LOCAL INFILE '/path/pet.txt' INTO TABLE pet
-> LINES TERMINATED BY '￦r￦n';
(애플의OS X를 사용하는 머신에서는, LINES TERMINATED BY '￦r'를 사용한다.)
여러분은 원한다면 컬럼 값 구분자(separator)와 LOAD DATA 명령문에 있는 라인마커의 끝을 지정할 수 있지만, 디폴트는 탭과
라인피드(linefeed)이다. 이것들만 가지고도 파일 pet.txt를 읽기 위한 명령문에서 충분히 사용할 수 있다.
명령문이 실패한다면, 여러분이 설치한 MySQL이 디폴트로 활성화시켜 놓은 로컬 파일을 갖고 있지 않은 것이다. 이에 대한 보다

자세한 정보는 Section 5.7.4, “LOAD DATA LOCAL과의 보안 문제”를 참조하기 바란다.
여러분이 한번에 한 개씩 새로운 레코드를 추가하고자 할 때에는, INSERT 명령문이 유용하다. 이 명령문의 간단한 형식 안에,
CREATE TABLE 명령문에서 지정한 컬럼의 순서대로 각 컬럼용 값을 입력하면 된다. 다이안(Diane)이 “Puffball”이라는 이름
의 새로운 햄스터를 얻었다고 하자. 여러분은 아래와 같이INSERT 명령문을 사용해서 새로운 레코드를 추가할 수 있다:
mysql> INSERT INTO pet

:::MySQL Korea:::
-> VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL);
스트링과 날짜 값은 인용부호를 사용해서 지정하였다. 또한, INSERT를 가지고, 여러분은 누락값(missing value)를 나타내는
NULL을 직접 삽입할 수 있다. 하지만, 여러분이 LOAD DATA 에서 사용한 것과 같이 ￦N를 사용할 수는 없다.
예를 들면, 여러분은 간단한 LOAD DATA 명령문을 사용하는 대신에 여러 개의 INSERT 명령문을 사용해서 초기에 레코드를 로
드(load)하는 것을 볼 수 있을 것이다.

:::MySQL Korea:::
제목검색
3.3.4. 테이블에서 정보를 불러오기
3. 사용 설명서 3.3.4.1. 모든 데이터 선택하기
3.3. 데이터베이스 생성 및 사용하기 3.3.4.2. 특정 줄(row) 선택하기
3.3.4 테이블에서 정보를 불러오기 3.3.4.3. 특정 컬럼(Column) 선택하기
3.3.4.1 모든 데이터 선택하기 3.3.4.4. 줄 정렬하기

3.3.4.5. 데이터 계산하기
3.3.4.2 특정 줄 선택하기
3.3.4.6. NULL 값을 가지고 작업하기
3.3.4.7. 패턴 매칭(Pattern Matching)
3.3.4.8. 줄 세기(Counting Rows)
3.3.4.6 NULL 값을 가지고 작업하기
3.3.4.9. 한 개 이상의 테이블 사용하기
3.3.4.7 패턴 매칭
3.3.4.8 줄 세기 SELECT 명령문은 테이블에서 정보를 가져올 때 사용된다. 명령문의 일반적인 형식은:
3.3.4.4 줄 정렬하기 SELECT what_to_select
FROM which_table
WHERE conditions_to_satisfy;
what_to_select 은 여러분이 보고자 하는 것을 가리킨다. 이것은 컬럼의 리스트가 될 수 있고, 또는 * 를 사용하면 “모든 컬
럼”을 나타내기도 한다. which_table은 여러분이 데이터를 가져오고 싶은 테이블이 어떤 것인지를 나타낸다. WHERE 구문은 옵
션이다. 이 구문이 표시되면, conditions_to_satisfy는 한 개 또는 그 이상의 조건문이다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.1. 모든 데이터 선택하기
3. 사용 설명서
간단한 형태의 SELECT 명령문은 테이블에서 모든 것을 가져온다:

mysql> SELECT * FROM pet;
3.3.4.2 특정 줄 선택하기 +----------+--------+---------+------+------------+------------+
3.3.4.5 데이터 계산하기 | name | owner | species | sex | birth | death |

+----------+--------+---------+------+------------+------------+
3.3.4.7 패턴 매칭
3.3.4.8 줄 세기
| Fluffy | Harold | cat |f | 1993-02-04 | NULL |
3.3.4.4 줄 정렬하기 | Claws | Gwen | cat |m | 1994-03-17 | NULL |
| Buffy | Harold | dog |f | 1989-05-13 | NULL |
| Fang | Benny | dog |m | 1990-08-27 | NULL |
| Bowser | Diane | dog |m | 1979-08-31 | 1995-07-29 |
| Chirpy | Gwen | bird |f | 1998-09-11 | NULL |
| Whistler | Gwen | bird | NULL | 1997-12-09 | NULL |
| Slim | Benny | snake | m | 1996-04-29 | NULL |

:::MySQL Korea:::
| Puffball | Diane | hamster | f | 1999-03-30 | NULL |
+----------+--------+---------+------+------------+------------+
SELECT는 여러분이 전체 테이블을 검토하고자 할 때 유용하게 사용되는 명령문이다. 예를 들면, 여러분은 Bowser의 생일이 틀
리게 입력되었다고 생각할 수 있을 것이다. 수의사의 기록을 살펴보면, 정확한 생일이 1979년이 아니고, 1989이다.
이것을 해결 하는 데에는 적어도 두 가지 방법이 있다:
• pet.txt를 편집해서 에러를 수정한 다음, 테이블을 비우고 DELETE 과 LOAD DATA 를 사용해서 이것을 다시 로
드 한다:
• mysql> DELETE FROM pet;
• mysql> LOAD DATA LOCAL INFILE 'pet.txt' INTO TABLE pet;
하지만, 여러분이 이렇게 하면, Puffball용 레코드도 다시 입력을 해야 한다.
• UPDATE 명령문을 가지고 에러가 있는 레코드만 수정한다:
• mysql> UPDATE pet SET birth = '1989-08-31' WHERE name = 'Bowser';
UPDATE 명령문은 의심스러운 레코드만을 변경시키며, 여러분은 테이블을 재 로드 할 필요가 없게 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.2. 특정 줄 선택하기
3. 사용 설명서
바로 전 섹션에서 보았듯이, 전체 테이블을 읽어오는 것은 쉬운 일이다. SELECT 명령문에서 WHERE 구문을 생략한다. 하지만 테
이블이 매우 큰 것이라면 전체 테이블을 보고 싶지 않을 것이다. 대신에, 여러분은 특정 질문에 대한 대답을 얻는 것이 더욱 흥미를
가질 것인데, 이런 경우에는 여러분이 원하는 정보에 some constraints를 지정할 수 있다. 애완 동물에 관한 질문을 하는 몇 가지
선택 쿼리들을 살펴보기로 하자.
3.3.4.3 특정 컬럼 선택하기 여러분은 테이블에서 특정 줄만 선택할 수 있다. 예를 들면, Bowser의 생일을 변경한 것을 확인해 보고 싶다면, 아래와 같이
3.3.4.5 데이터 계산하기 Bowser의 레코드를 선택한다:
3.3.4.7 패턴 매칭 mysql> SELECT * FROM pet WHERE name = 'Bowser';
3.3.4.8 줄 세기
+--------+-------+---------+------+------------+------------+
3.3.4.4 줄 정렬하기
| name | owner | species | sex | birth | death |
+--------+-------+---------+------+------------+------------+
+--------+-------+---------+------+------------+------------+
그 결과값은 1979년이 아닌, 1989년으로 올바르게 기록되어 있음을 확인시켜 준다.
스트링 비교는 일반적으로 대소 문자를 구분하지 않기 때문에, 여러분은 이름을 'bowser', 'BOWSER', 및 다른 형식으로 지정할
수 있다. 쿼리의 결과는 동일하게 나온다.

:::MySQL Korea:::
여러분은 이름 컬럼을 제외하고, 다른 어떤 컬럼에 대해서도 조건문을 작성할 수 있다. 예를 들면, 어떤 동물이 1998년에 또는 그
이후에 태어 났는지 알고 싶다면, birth 컬럼을 테스트한다:
mysql> SELECT * FROM pet WHERE birth >= '1998-1-1';
+----------+-------+---------+------+------------+-------+
+----------+-------+---------+------+------------+-------+
| Puffball | Diane | hamster | f | 1999-03-30 | NULL |
+----------+-------+---------+------+------------+-------+
조건문을 여러 개 조합할 수도 있는데, 예를 들면, 암컷 개를 찾을 때 사용할 수도 있다:
mysql> SELECT * FROM pet WHERE species = 'dog' AND sex = 'f';
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
앞의 쿼리는 AND 논리 연산자를 사용하였다. OR 연산자도 역시 사용할 있다:

:::MySQL Korea:::
mysql> SELECT * FROM pet WHERE species = 'snake' OR species = 'bird';
+----------+-------+---------+------+------------+-------+
+----------+-------+---------+------+------------+-------+
| Slim | Benny | snake | m | 1996-04-29 | NULL |
+----------+-------+---------+------+------------+-------+
AND 및 OR는 서로 혼용해서 사용할 수 있는데, AND가 OR보다 우선 순위가 있다. 이 두 가지 연산자를 모두 사용할 경우, 어떤
조건문이 그룹으로 동작되어야 하는지를 지정하기 위해 괄호를 사용하는 것이 좋다:
mysql> SELECT * FROM pet WHERE (species = 'cat' AND sex = 'm')
-> OR (species = 'dog' AND sex = 'f');
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
| Claws | Gwen | cat |m | 1994-03-17 | NULL |

:::MySQL Korea:::
+-------+--------+---------+------+------------+-------+

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.3. 특정 컬럼 선택하기
3. 사용 설명서
테이블에서 전체 줄을 보고 싶지 않을 경우에는, 콤마를 사용해서 보고 싶은 컬럼의 이름만 입력하면 된다. 예를 들면, 여러분의 동
물들이 언제 태어났는지 보고 싶다, name 과 birth 컬럼을 선택한다:
3.3.4.1 모든 데이터 선택하기 mysql> SELECT name, birth FROM pet;
3.3.4.3 특정 컬럼 선택하기 +----------+------------+
3.3.4.6 NULL 값을 가지고 작업하기 | name | birth |
3.3.4.7 패턴 매칭
+----------+------------+
3.3.4.8 줄 세기
| Fluffy | 1993-02-04 |
3.3.4.4 줄 정렬하기
| Claws | 1994-03-17 |
| Buffy | 1989-05-13 |
| Fang | 1990-08-27 |
| Bowser | 1989-08-31 |
| Chirpy | 1998-09-11 |
| Whistler | 1997-12-09 |

:::MySQL Korea:::
| Slim | 1996-04-29 |
| Puffball | 1999-03-30 |
+----------+------------+
누가 주인인지를 보기 위해서는, 아래의 쿼리를 사용한다:
mysql> SELECT owner FROM pet;
+--------+
| owner |
+--------+
| Harold |
| Gwen |
| Harold |
| Benny |
| Diane |
| Gwen |
| Gwen |
| Benny |

:::MySQL Korea:::
| Diane |
+--------+
쿼리는 각 레코드에서 간단하게 owner를 불러오는데, 어떤 사람의 이름은 여러 번 나오게 된다는 것을 주목한다. 이것을 최소화하
기 위해서는 각각의 이름이 딱 한번만 나오도록 하기 위해 DISTINCT를 추가할 수도 있다:
mysql> SELECT DISTINCT owner FROM pet;
+--------+
| owner |
+--------+
| Benny |
| Diane |
| Gwen |
| Harold |
+--------+
여러분은 WHERE 구문을 사용해서 줄 선택과 컬럼 선택을 서로 묶을 수가 있다. 예를 들면, 개와 고양이들의 생일만 얻기 위해서
는, 아래의 쿼리를 사용한다:
mysql> SELECT name, species, birth FROM pet
-> WHERE species = 'dog' OR species = 'cat';

:::MySQL Korea:::
+--------+---------+------------+
| name | species | birth |
+--------+---------+------------+
| Fluffy | cat | 1993-02-04 |
| Claws | cat | 1994-03-17 |
| Buffy | dog | 1989-05-13 |
| Fang | dog | 1990-08-27 |
| Bowser | dog | 1989-08-31 |
+--------+---------+------------+

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.5. 데이터 계산하기
3. 사용 설명서
MySQL은 여러분이 날짜를 가지고 나이를 계산하거나 날짜 포맷에서 특정 부분을 추출해 낼 수 있는 여러 가지 함수를 제공해 주
고 있다.
3.3.4.1 모든 데이터 선택하기 각 동물들이 얼마나 나이를 먹었는지 계산하기 위해서는, 현재의 날짜와 태어난 날짜의 연도의 차이를 계산하고, 그 다음에 현재의
3.3.4.2 특정 줄 선택하기 날짜가 태어난 날짜보다 앞선 날짜면 1을 뺀다. 아래의 쿼리는 각 애완 동물에 대해, 생일, 현재 날짜, 그리고 나이를 보여주고 있
3.3.4.3 특정 컬럼 선택하기 다.
3.3.4.6 NULL 값을 가지고 작업하기 mysql> SELECT name, birth, CURDATE(),
3.3.4.7 패턴 매칭
-> (YEAR(CURDATE())-YEAR(birth))
3.3.4.8 줄 세기
-> - (RIGHT(CURDATE(),5)<RIGHT(birth,5))
3.3.4.4 줄 정렬하기
-> AS age
-> FROM pet;
+----------+------------+------------+------+
| name | birth | CURDATE() | age |
+----------+------------+------------+------+
| Fluffy | 1993-02-04 | 2003-08-19 | 10 |

:::MySQL Korea:::
| Claws | 1994-03-17 | 2003-08-19 | 9|
| Buffy | 1989-05-13 | 2003-08-19 | 14 |
| Fang | 1990-08-27 | 2003-08-19 | 12 |
| Bowser | 1989-08-31 | 2003-08-19 | 13 |
| Chirpy | 1998-09-11 | 2003-08-19 | 4|
| Whistler | 1997-12-09 | 2003-08-19 | 5|
| Slim | 1996-04-29 | 2003-08-19 | 7|
| Puffball | 1999-03-30 | 2003-08-19 | 4|
+----------+------------+------------+------+
여기에서, YEAR() 는 날짜에서 연도 부분을 가져오고 RIGHT()는 날짜 포맷의 MM-DD (calendar year)을 나타내는 오른 쪽
다섯 숫자를 가져 온다. The part of the expression that compares the MM-DD 값을 비교하는 수식은 1 또는0를 계산하는데,
이것은 만약에 CURDATE()가 birth보다 앞선 일자이면 연도의 차이에서 한 해를 뺀다. 전체 수식은 다소 ungainly하기 때문에,
alias (age)는 보다 의미를 잘 나타내는 결과 컬럼을 만드는데 사용한다.
이 쿼리는 제대로 동작을 하기는 하지만, 만약에 줄이 특정 순서로 표시되어 있다면 보다 쉽게 검사할 수 있을 것이다. 이것은
ORDER BY name 구문을 추가해서 결과가 나올 때 이름으로 정렬하도록 할 수 있다:
mysql> SELECT name, birth, CURDATE(),

:::MySQL Korea:::
-> AS age
-> FROM pet ORDER BY name;
+----------+------------+------------+------+
+----------+------------+------------+------+
| Bowser | 1989-08-31 | 2003-08-19 | 13 |
| Buffy | 1989-05-13 | 2003-08-19 | 14 |
| Chirpy | 1998-09-11 | 2003-08-19 | 4|
| Claws | 1994-03-17 | 2003-08-19 | 9|
| Fang | 1990-08-27 | 2003-08-19 | 12 |
| Fluffy | 1993-02-04 | 2003-08-19 | 10 |
| Puffball | 1999-03-30 | 2003-08-19 | 4|
| Slim | 1996-04-29 | 2003-08-19 | 7|
| Whistler | 1997-12-09 | 2003-08-19 | 5|
+----------+------------+------------+------+
To sort the output rather than name으로 정렬을 하지 말고 age로 결과 값을 정렬하기 위해서는, 다른 ORDER BY 구문을 사용
한다:

:::MySQL Korea:::
mysql> SELECT name, birth, CURDATE(),
-> AS age
-> FROM pet ORDER BY age;
+----------+------------+------------+------+
+----------+------------+------------+------+
| Chirpy | 1998-09-11 | 2003-08-19 | 4|
| Puffball | 1999-03-30 | 2003-08-19 | 4|
| Whistler | 1997-12-09 | 2003-08-19 | 5|
| Slim | 1996-04-29 | 2003-08-19 | 7|
| Claws | 1994-03-17 | 2003-08-19 | 9|
| Fluffy | 1993-02-04 | 2003-08-19 | 10 |
| Fang | 1990-08-27 | 2003-08-19 | 12 |
| Bowser | 1989-08-31 | 2003-08-19 | 13 |

:::MySQL Korea:::
| Buffy | 1989-05-13 | 2003-08-19 | 14 |
+----------+------------+------------+------+
비슷한 쿼리를 사용해서 이미 죽은 동물들의 죽은 나이를 검사할 수 있다. 여러분은 death값이NULL 인지 아닌지를 먼저 검사해
서 죽은 동물이 어느 것인지 검사 한다. 그 다음에 NULL 값이 아닌 동물에 대해, death 와birth 값의 차이를 계산한다:
mysql> SELECT name, birth, death,
-> (YEAR(death)-YEAR(birth)) - (RIGHT(death,5)<RIGHT(birth,5))
-> AS age
-> FROM pet WHERE death IS NOT NULL ORDER BY age;
+--------+------------+------------+------+
| name | birth | death | age |
+--------+------------+------------+------+
| Bowser | 1989-08-31 | 1995-07-29 | 5|
+--------+------------+------------+------+
쿼리는 death <> NULL를 사용하지 않고 death IS NOT NULL를 사용하고 있는데, 그 이유는 NULL이 일반적이 비교 연산자
를 가지고는 비교 연산을 할 수 없는 특별한 값을 가지기 때문이다. 이 점에 대해서는 나중에 논의하기로 한다. Section 3.3.4.6,
“NULL 값을 가지고 작업하기”를 참조할 것.
다음달에 생일이 돌아오는 동물이 어떤 것인지 알고자 할 경우에는 어떻게 야 하는가? 이것을 계산하기 위해서는, 연도와 요일은
관련이 없게 된다; 여러분은 birth 컬럼에서 월(month)부분만을 가져 오면 된다. MySQL은 YEAR(), MONTH(), 및
DAYOFMONTH()와 같이 날짜 부분에서 필요한 부분을 추출해주는 함수를 제공한다. MONTH()는 여러분이 여기에서 원하는 것

:::MySQL Korea:::
을 작업해 준다. 이것이 어떻게 동작하는지 보기 위해, birth 와 MONTH(birth)의 값을 알려주는 간단한 쿼리를 구동시킨다:
mysql> SELECT name, birth, MONTH(birth) FROM pet;
+----------+------------+--------------+
| name | birth | MONTH(birth) |
+----------+------------+--------------+
| Fluffy | 1993-02-04 | 2|
| Claws | 1994-03-17 | 3|
| Buffy | 1989-05-13 | 5|
| Fang | 1990-08-27 | 8|
| Bowser | 1989-08-31 | 8|
| Chirpy | 1998-09-11 | 9|
| Whistler | 1997-12-09 | 12 |
| Slim | 1996-04-29 | 4|
| Puffball | 1999-03-30 | 3|
+----------+------------+--------------+
앞으로 다가오는 달에 생일이 있는 동물을 찾는 것 역시 쉽다. 지금은 4월이라고 가정하자. 그러면 월(month0값은 4가 되며 여러
분은 아래와 같이 5월에 생일이 있는 동물을 찾아낼 수 있다:

:::MySQL Korea:::
mysql> SELECT name, birth FROM pet WHERE MONTH(birth) = 5;
+-------+------------+
| name | birth |
+-------+------------+
| Buffy | 1989-05-13 |
+-------+------------+
지금이 12월이라면 다소 복잡한 일이 생긴다. 여러분은 간단히 숫자 하나를 월(month)값에 더해서 13월에 태어난 동물을 찾을 수
가 없는데, 13월 이라는 달은 없기 때문이다. 대신에 여러분은 1월에 태어난 동물을 찾아야 한다.
지금이 무슨 달인지 상관없는 쿼리를 쓸 수가 있는데, 이렇게 하면 숫자를 사용해서 특정 월을 표시하지 않아도 된다. DATE_ADD
()는 여러분이 시간 간격(interval)을 주어진 날짜에 추가할 수 있도록 해 준다. 여러분이 1달을 CURDATE()의 값에 더하고, 그
다음에 MONTH()를 가지고 월 부분을 가져오고자 한다면, 결과는 생일을 월 부분에서 찾는 작업을 한다:
mysql> SELECT name, birth FROM pet
-> WHERE MONTH(birth) = MONTH(DATE_ADD(CURDATE(),INTERVAL 1 MONTH));
동일 업무를 실행하는 다른 방법은 만약에 지금이 12라면 월(month)값을 0으로 하기 위해 모듈로(modulo) 함수(MOD) 를 사용
한 후에 1을 더해서 다음달을 계산하면 된다:
mysql> SELECT name, birth FROM pet
-> WHERE MONTH(birth) = MOD(MONTH(CURDATE()), 12) + 1;
MONTH는 1에서 12의 사이 숫자를 리턴한다는 점을 알기 바란다. 그리고 MOD(something,12)는 0 과 11사이의 숫자를 리턴한
다. 따라서 첨가 작업은 MOD() 다음에 해야 하는데, 그렇지 않으면 우리는11월에서 1월로 가게 된다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.6. NULL 값을 가지고 작업하기
3. 사용 설명서
NULL값은 개념적으로 본다면, “누락된 알려지지 않은 값(missing unknown value)”을 의미하고 다른 값과는 다소 다르게 취
급된다. NULL에 대한 테스트를 할 때에는, =, <, 또는 <>과 같은 산순 비교 연산자는 사용할 수 없다. 이것을 실험해 보기 위해,
다음의 쿼리를 시도해 보자:
3.3.4.2 특정 줄 선택하기 mysql> SELECT 1 = NULL, 1 <> NULL, 1 < NULL, 1 > NULL;
3.3.4.5 데이터 계산하기 +----------+-----------+----------+----------+

| 1 = NULL | 1 <> NULL | 1 < NULL | 1 > NULL |
3.3.4.7 패턴 매칭
3.3.4.8 줄 세기
+----------+-----------+----------+----------+
3.3.4.4 줄 정렬하기
| NULL | NULL | NULL | NULL |
+----------+-----------+----------+----------+
명백히 이러한 비교문을 가지고는 의미 있는 결과를 얻어낼 수 없다. 대신에 IS NULL과 IS NOT NULL 연산자를 사용해 본다:
mysql> SELECT 1 IS NULL, 1 IS NOT NULL;
+-----------+---------------+
| 1 IS NULL | 1 IS NOT NULL |
+-----------+---------------+

:::MySQL Korea:::
| 0| 1|
+-----------+---------------+
MySQL에서는, 0 또는 NULL은 거짓(false)을 의미하며 다른 것은 진실(true)를 의미한다. 불리안(boolean) 연산에서 디폴트 진

실은 1이다.
앞의 섹션에서 보았듯이, 어떤 동물이 죽었는지를 판단하기 위한 방법을 death <> NULL가 아닌 death IS NOT NULL로 사용
한 이유가 바로 이러한 NULL의 특별한 성격 때문이다..
두 개의 NULL 값은 하나의 GROUP BY에서는 동등한 것으로 여겨진다.
ORDER BY를 실행할 때, NULL은 ORDER BY ... ASC를 하면 가장 먼저 나오고 ORDER BY ... DESC를 하면 가장 나중에 나오
는 값이 된다.
NULL을 가지고 작업을 할 때 범하는 일반적인 에러중의 하나는 NOT NULL로 정의된 컬럼에 0 또는 빈 스트링을 삽입하는 것은
불가능하게 생각하는 것이다. 하지만, 그렇지 않다. NULL이 “값을 갖고 있지 않음(not having a value)”을 의미하는 반면에, 이
러한 것들은 분명한 값으로 존재하는 것이다. 여러분은 아래와 같이IS [NOT] NULL을 사용해서 간단히 이것을 테스트 해볼 수 있
다:
mysql> SELECT 0 IS NULL, 0 IS NOT NULL, '' IS NULL, '' IS NOT NULL;
+-----------+---------------+------------+----------------+
| 0 IS NULL | 0 IS NOT NULL | '' IS NULL | '' IS NOT NULL |
+-----------+---------------+------------+----------------+
| 0| 1| 0| 1|
+-----------+---------------+------------+----------------+

:::MySQL Korea:::
따라서 0 또는 빈 스트링을 NOT NULL에 삽입하는 것은 분명히 가능한 작업이다. Section A.5.3, “Problems with NULL
Values”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.7. 패턴 매칭
3. 사용 설명서
MySQL은 유닉스 유틸리티가 사용하는 vi, grep, 및 sed등과 유사한 확장된 규칙 수식(extended regular expression)에 근거한
패턴 매칭 형식 뿐만 아니라 표준 SQL 패턴 매칭도 함께 제공한다.
3.3.4.1 모든 데이터 선택하기 SQL 패턴 매칭은 ‘_’을 사용해서 단일 문자를 매칭시킬 수 있게 하고 ‘%’ 를 사용해서는 문자(제로 문자 포함)의 arbitrary
3.3.4.2 특정 줄 선택하기 number를 매칭 시킬 수 있게 해 준다. MySQL에서는, SQL 패턴은 디폴트로 대소 문자를 구분하지 않는다. 몇 가지 예문을 보기
3.3.4.3 특정 컬럼 선택하기 로 한다. 주의할 것은 SQL패턴을 사용할 때에는 = 또는 <>는 사용할 수 없다는 것이다; LIKE 또는 NOT LIKE 를 대신 사용한
3.3.4.5 데이터 계산하기 다.
3.3.4.7 패턴 매칭 ‘b’로 시작되는 이름을 찾기 위해서는:
3.3.4.8 줄 세기
mysql> SELECT * FROM pet WHERE name LIKE 'b%';
3.3.4.4 줄 정렬하기
+--------+--------+---------+------+------------+------------+
+--------+--------+---------+------+------------+------------+
+--------+--------+---------+------+------------+------------+
‘fy’로 끝나는 이름을 찾기 위해서는:

:::MySQL Korea:::
mysql> SELECT * FROM pet WHERE name LIKE '%fy';
+--------+--------+---------+------+------------+-------+
+--------+--------+---------+------+------------+-------+
+--------+--------+---------+------+------------+-------+
이름 안에 ‘w’가 있는 것을 찾기 위해서는:
mysql> SELECT * FROM pet WHERE name LIKE '%w%';
+----------+-------+---------+------+------------+------------+
+----------+-------+---------+------+------------+------------+
+----------+-------+---------+------+------------+------------+

:::MySQL Korea:::
정확히 5개의 문자로 이름이 되어 있는 것을 찾기 위해서는, ‘_’ 패턴 문자를 5번 사용한다:
mysql> SELECT * FROM pet WHERE name LIKE '_____';
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
패턴 매칭의 다른 형태는 MySQL이 확장된 규칙 수식을 사용할 때 나타난다. 이러한 유형의 패턴 매칭을 테스트 하고자 할 때에
는, REGEXP 과 NOT REGEXP 연산자를 사용한다(또는 RLIKE 과 NOT RLIKE를 사용한다).
확장된 규칙 수식의 몇 가지 특징을 알아보면:
• ‘.’는 모든 단일 문자를 매치 시킨다.
• 문자 클래스 ‘[...]’는 대괄호 안에 있는 모든 문자를 매치 시킨다. 예를 들면, ‘[abc]’는 ‘a’, ‘b’, 또는

‘c’를 매치 시킨다. 문자 범위를 지정하기 위해서는, 대시(dash)를 사용한다. ‘[a-z]’는 모든 문자를 매치 시키며,
반면에 ‘[0-9]’는 모든 숫자를 매치 시킨다.
• ‘*’는 기호 앞에 문자의 0개 또는 그 이상의 인스턴스를 매치 시킨다. 예를 들면, ‘x*’는 ‘x’ 문자의 모든 갯수

를 매치 시키며, characters, ‘[0-9]*’는 숫자의 모든 수를 매치 시키며, 그리고 ‘.*’는 모든 것의 모든 숫자를 매치
시킨다.
• REGEXP 패턴 매치는 테스트되는 값이 있는 모든 곳에서 매칭을 하게 된다.(이것은 LIKE 패턴 매치와는 다른데,

LIKE는 전체 값에서만 패턴 매치를 진행한다.)

:::MySQL Korea:::
• 테스트 되는 값의 처음 또는 끝을 매칭 시키도록 패턴을 고정 시키기 위해서는, 패턴의 처음에 ‘^’ 또는 끝에

‘$’ 를 사용한다.
확장 규칙 수식이 어떻게 동작을 하는지 보이기 위해, 이전에 사용한 LIKE 쿼리를 REGEXP를 사용하는 수식으로 다시 작성한다.
‘b’로 시작하는 이름을 찾기 위해, ‘^’를 사용해서 패턴에 일치하는 이름을 찾는다:
mysql> SELECT * FROM pet WHERE name REGEXP '^b';
+--------+--------+---------+------+------------+------------+
+--------+--------+---------+------+------------+------------+
+--------+--------+---------+------+------------+------------+
여러분이 REGEXP 비교문이 대소 문자를 구분하도록 하고자 한다면, BINARY 키워드를 사용해서 바이너리 스트링을 만든다. 이
쿼리는 이름이 소문자 ‘b’로 시작하는 것만을 매치 시킨다:
mysql> SELECT * FROM pet WHERE name REGEXP BINARY '^b';
‘fy’로 끝나는 이름을 찾기 위해서는, ‘$’를 사용해서 이름의 끝을 매치 시킨다:
mysql> SELECT * FROM pet WHERE name REGEXP 'fy
+--------+--------+---------+------+------------+-------+

:::MySQL Korea:::
+--------+--------+---------+------+------------+-------+
+--------+--------+---------+------+------------+-------+
이름에 ‘w’문자를 갖고 있는 것을 찾으려면, 다음의 쿼리를 사용한다:
mysql> SELECT * FROM pet WHERE name REGEXP 'w';
+----------+-------+---------+------+------------+------------+
+----------+-------+---------+------+------------+------------+
+----------+-------+---------+------+------------+------------+
레귤러 수식 패턴은 테스트가 되는 값에서 매칭을 하기 때문에, 이전의 쿼리에서는 여러분이 SQL 패턴에서 사용한 것과 같이 와일
드카드를 패턴의 양 끝에 넣고 전체 값을 매칭 시키는 것이 불필요하게 된다.
정확히 5개의 문자를 가지고 있는 이름을 찾기 위해서는, ‘^’ 와 ‘$’ 를 패턴의 양쪽 끝에 놓고 중간에 다섯 개의 ‘.’ 인스턴

:::MySQL Korea:::
스를 넣어둔다:
mysql> SELECT * FROM pet WHERE name REGEXP '^.....
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
앞에 있는 쿼리를 {n} (“repeat-n-times”) 연산자를 사용해서 작성할 수도 있다:
mysql> SELECT * FROM pet WHERE name REGEXP '^.{5}
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+
+-------+--------+---------+------+------------+-------+

:::MySQL Korea:::
Appendix G, MySQL Regular Expressions에서는 레귤러 수식 신텍스에 대한 보다 자세한 정보를 볼 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.8. 줄 세기
3. 사용 설명서
데이터 베이스는 “테이블에서 얼마나 자주 특정 데이터 타입이 일어나는가?”와 같은 물음에 답하기 위해 사용된다. 예를 들면, 여
러분이 얼마나 많은 동물을 가지고 있는지 또는 각각의 주인들이 몇 마리씩을 키우고 있는지 또는 여러 가지의 다른 종류의 조사를
할 수도 있다.
3.3.4.2 특정 줄 선택하기 여러분이 기르고 있는 동물의 수를 계산하는 것은, “pet 테이블에는 몇 개의 줄이 있는가?”를 묻는 것과 같은 질문이다. 왜냐하
3.3.4.3 특정 컬럼 선택하기 면 동물당 한 개의 레코드가 있기 때문이다. COUNT(*)는 줄의 수를 계산하는데, 따라서 쿼리는 아래와 같이 동물의 수를 계산하
3.3.4.5 데이터 계산하기 게 된다:
3.3.4.7 패턴 매칭 mysql> SELECT COUNT(*) FROM pet;
3.3.4.8 줄 세기
+----------+
3.3.4.4 줄 정렬하기
| COUNT(*) |
+----------+
| 9|
+----------+
앞에서, 여러분은 동물의 주인 이름을 읽어올 수 있었다. 여기에서는 COUNT()를 사용해서 각 주인들이 얼마나 많은 수의 동물을
기르고 있는지를 계산할 수 있게 된다:
mysql> SELECT owner, COUNT(*) FROM pet GROUP BY owner;

:::MySQL Korea:::
+--------+----------+
| owner | COUNT(*) |
+--------+----------+
| Benny | 2|
| Diane | 2|
| Gwen | 3|
| Harold | 2|
+--------+----------+
GROUP BY는 각 owner의 모든 기록을 그룹화 하기 위해 사용한다는 것을 알아 두기 바란다. 이렇게 하지 않으면, 에러가 발생한
다:
mysql> SELECT owner, COUNT(*) FROM pet;
ERROR 1140 (42000): Mixing of GROUP columns (MIN(),MAX(),COUNT(),...)
with no GROUP columns is illegal if there is no GROUP BY clause
COUNT() 과 GROUP BY는 여러모로 데이터를 특성화 시키는데 유용하다. 아래의 예제들은 다양한 방법으로 동물의 특성을 알
아 보는 방법을 알려 주는 것이다.
종류별로 동물을 세어본다:
mysql> SELECT species, COUNT(*) FROM pet GROUP BY species;

:::MySQL Korea:::
+---------+----------+
| species | COUNT(*) |
+---------+----------+
| bird | 2|
| cat | 2|
| dog | 3|
| hamster | 1|
| snake | 1|
+---------+----------+
성별로 구분한다:
mysql> SELECT sex, COUNT(*) FROM pet GROUP BY sex;
+------+----------+
| sex | COUNT(*) |
+------+----------+
| NULL | 1|
|f | 4|

:::MySQL Korea:::
|m | 4|
+------+----------+
(결과 값에서, NULL은 성별을 모른다는 것을 나타낸다.)
종류와 성별의 조합으로 동물을 세어 본다:
mysql> SELECT species, sex, COUNT(*) FROM pet GROUP BY species, sex;
+---------+------+----------+
| species | sex | COUNT(*) |
+---------+------+----------+
| bird | NULL | 1|
| bird |f | 1|
| cat |f | 1|
| cat |m | 1|
| dog |f | 1|
| dog |m | 2|
| hamster | f | 1|
| snake | m | 1|
+---------+------+----------+

:::MySQL Korea:::
COUNT()을 사용할 때에는 전체 테이블을 읽어 들일(retrieve) 필요가 없다. 예를 들면, 앞의 쿼리에서, 개와 고양이에서만 실행
할 경우, 아래와 같이 보인다:
mysql> SELECT species, sex, COUNT(*) FROM pet
-> WHERE species = 'dog' OR species = 'cat'
-> GROUP BY species, sex;
+---------+------+----------+
+---------+------+----------+
| cat |f | 1|
| cat |m | 1|
| dog |f | 1|
| dog |m | 2|
+---------+------+----------+
또는, 성별이 알려진 동물에 대해서만 성별로 숫자를 세고자 한다면:
mysql> SELECT species, sex, COUNT(*) FROM pet
-> WHERE sex IS NOT NULL
-> GROUP BY species, sex;

:::MySQL Korea:::
+---------+------+----------+
+---------+------+----------+
| bird |f | 1|
| cat |f | 1|
| cat |m | 1|
| dog |f | 1|
| dog |m | 2|
| hamster | f | 1|
| snake | m | 1|
+---------+------+----------+

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.9. 한 개 이상의 테이블 사용하기
3. 사용 설명서
pet 테이블은 여러분이 기르는 동물의 기록을 유지하고 있다. 여러분이 만약에 이 동물들에 대한 다른 정보들을 기록하고 싶다면,
여러분은 다른 테이블이 필요하게 된다. 이 테이블은 어떤 모양이 되어야 하는가? 다음의 것이 필요하게 된다:
• 각각의 이벤트가 어떤 동물에게 일어났는지 알기 위해서 동물의 이름을 가지고 있을 것.
• 이벤트가 일어난 날짜를 알기 위한 날짜 기록.
• 이벤트를 기록하기 위한 필드.
3.3.4.6 NULL 값을 가지고 작업하기 • 이벤트 타입 필드. 각각의 이벤트를 목록화 하고자 할 경우에 필요함.
3.3.4.7 패턴 매칭
이러한 고려 사항을 가지고, event 테이블을 위한 CREATE TABLE 명령문은 아래와 같이 작성될 것이다:
3.3.4.8 줄 세기
mysql> CREATE TABLE event (name VARCHAR(20), date DATE,
3.3.4.4 줄 정렬하기
-> type VARCHAR(15), remark VARCHAR(255));
pet 테이블에서와 마찬가지로, 각 정보를 가지고 있는 텍스트 파일에서 초기에 데이터를 읽어 오는 것은 매우 쉬운 일이다:
name date type Remark
Fluffy 1995-05-15 litter 4 kittens, 3 female, 1 male
Buffy 1993-06-23 litter 5 puppies, 2 female, 3 male
Buffy 1994-06-19 litter 3 puppies, 3 female
Chirpy 1999-03-21 vet needed beak straightened

:::MySQL Korea:::
Slim 1997-08-03 vet broken rib
Bowser 1991-10-12 kennel
Fang 1991-10-12 kennel
Fang 1998-08-28 birthday Gave him a new chew toy
Claws 1998-03-17 birthday Gave him a new flea collar
Whistler 1998-12-09 birthday First birthday
아래와 같이 레코드를 읽어(Load)온다:
mysql> LOAD DATA LOCAL INFILE 'event.txt' INTO TABLE event;
pet 테이블에서 구동 시켜본 쿼리로부터 배운 것을 토대로 하면, 여러분은 event 테이블 안에 있는 레코드를 불러(retrieval)올 수
있을 것이다; 원리는 똑 같다. 하지만 event 테이블 자체가 여러분이 질문하는 것에 대해 불충분하게 답변을 할 경우에는 어떻게 해
야 하는가?
각 동물이 새끼를 낳았을 때의 나이를 알고 싶다고 가정하자. 앞에서 우리는 두 개의 날짜를 가지고 나이를 계산하는 방법을 본적
이 있다. 어미가 새끼를 낳은 날짜는 even 테이블에 있지만, 어미의 나이를 계산하기 위해서는 생일이 언제인지 알 필요가 있는데,
이 날짜는 pet 테이블에 기록되어 있다. 이것을 쿼리가 두 테이블을 모두 필요로 한다는 것을 의미한다:
mysql> SELECT pet.name,
-> (YEAR(date)-YEAR(birth)) - (RIGHT(date,5)<RIGHT(birth,5)) AS age,
-> remark
-> FROM pet, event
-> WHERE pet.name = event.name AND event.type = 'litter';
+--------+------+-----------------------------+

:::MySQL Korea:::
| name | age | remark |
+--------+------+-----------------------------+
| Fluffy | 2 | 4 kittens, 3 female, 1 male |
| Buffy | 4 | 5 puppies, 2 female, 3 male |
| Buffy | 5 | 3 puppies, 3 female |
+--------+------+-----------------------------+
이 쿼리에는 잘 알아두어야 할 점이 여러 가지 있다:
• 쿼리가 두 테이블 모두에서 정보를 불러와야 하기 때문에 FROM 구문은 두 테이블에서 목록에 가져온다.
• 다중의 테이블에서 정보를 조합(combining)할 때, 여러분은 하나의 테이블에 있는 레코드가 어떻게 다른 테이블에
있는 레코드에 매치되는지를 지정해 주어야 한다. 이것은 쉬운 일인데, 왜냐하면 두 테이블 모두 name 컬럼을 갖고 있기
때문이다. 쿼리는 WHERE 구문을 사용해서 두 테이블에서 name 값을 가지고 레코드들을 비교한다.
• name 컬럼이 두 테이블에 모두 있기 때문에, 참조하고자 하는 컬럼이 어떤 테이블에 있는 것인지를 분명히 지정해
주어야 한다. 이것은 컬럼 이름 앞에 테이블 이름을 적어 주는 방식으로 사용된다.
여러분은 두 개의 서로 다른 테이블을 합(join)할 필요는 없다. 때로는 테이블 자체를 합하는 것이 더 유용할 수 있는데, 만약에 동
일한 테이블에 있는 다른 레코드간에 비교를 할 경우가 이에 해당한다. 예를 들면, 암수 한 쌍의 동물을 찾기 위해서, pet 테이블 자
체를 합에서 각 동물의 암수 쌍을 만들어 낸다:
mysql> SELECT p1.name, p1.sex, p2.name, p2.sex, p1.species
-> FROM pet AS p1, pet AS p2
-> WHERE p1.species = p2.species AND p1.sex = 'f' AND p2.sex = 'm';

:::MySQL Korea:::
+--------+------+--------+------+---------+
| name | sex | name | sex | species |
+--------+------+--------+------+---------+
| Fluffy | f | Claws | m | cat |
| Buffy | f | Fang | m | dog |
| Buffy | f | Bowser | m | dog |
+--------+------+--------+------+---------+

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 3.3.4.4. 줄 정렬하기
3. 사용 설명서
여러분의 앞의 예제에서 결과로 화면에 나온 줄들이 특정 규칙이 없이 보여졌다는 점을 발견할 수 있을 것이다. 어떤 의미를 가지
고 줄이 정렬이 되어지면 쿼리의 결과를 분석하는 것이 보다 쉬울 수도 있을 것이다. 결과를 정렬하기 위해서는, ORDER BY 구문
을 사용한다.
3.3.4.2 특정 줄 선택하기 여기에서는 동물의 생일을 날짜로 정렬하고 있다:
3.3.4.5 데이터 계산하기 mysql> SELECT name, birth FROM pet ORDER BY birth;

+----------+------------+
3.3.4.7 패턴 매칭
3.3.4.8 줄 세기
| name | birth |
3.3.4.4 줄 정렬하기
+----------+------------+
| Buffy | 1989-05-13 |
| Bowser | 1989-08-31 |
| Fang | 1990-08-27 |
| Fluffy | 1993-02-04 |
| Claws | 1994-03-17 |
| Slim | 1996-04-29 |

:::MySQL Korea:::
| Whistler | 1997-12-09 |
| Chirpy | 1998-09-11 |
| Puffball | 1999-03-30 |
+----------+------------+
문자 타입의 컬럼에서, 정렬-모든 비교 연산과 마찬가지로-은 일반적으로는 대소 문자를 구분하지 않는다. 여러분은 다음과 같이
BINARY를 사용해서 컬럼에 대해 대소 문자를 구분하도록 정렬시킬 수 있다: ORDER BY BINARY col_name.
디폴트 정렬 순서는 오름 차순이고, 가장 작은 것이 먼저 나오게 된다. 내림 차순으로 정렬하기 위해서는, DESC 키워드를 정렬하고
자 하는 컬럼 이름에 추가한다:
mysql> SELECT name, birth FROM pet ORDER BY birth DESC;
+----------+------------+
| name | birth |
+----------+------------+
| Puffball | 1999-03-30 |
| Chirpy | 1998-09-11 |
| Whistler | 1997-12-09 |
| Slim | 1996-04-29 |
| Claws | 1994-03-17 |

:::MySQL Korea:::
| Fluffy | 1993-02-04 |
| Fang | 1990-08-27 |
| Bowser | 1989-08-31 |
| Buffy | 1989-05-13 |
+----------+------------+
다중 컬럼에서 정렬을 할 수 있으며, 서로 다른 순서로 컬럼을 정렬할 수도 있다. 예를 들면, 오름 차순으로 동물의 타입을 정렬하
고, 그 다음에는 동물의 타입에서 내림 차순으로 생일을 정렬하기 위해서는, 아래의 쿼리를 사용한다:
mysql> SELECT name, species, birth FROM pet
-> ORDER BY species, birth DESC;
+----------+---------+------------+
| name | species | birth |
+----------+---------+------------+
| Chirpy | bird | 1998-09-11 |
| Whistler | bird | 1997-12-09 |
| Claws | cat | 1994-03-17 |
| Fluffy | cat | 1993-02-04 |
| Fang | dog | 1990-08-27 |

:::MySQL Korea:::
| Bowser | dog | 1989-08-31 |
| Buffy | dog | 1989-05-13 |
| Puffball | hamster | 1999-03-30 |
| Slim | snake | 1996-04-29 |
+----------+---------+------------+
DESC 키워드는 바로 앞에 있는 컬럼 이름(birth)에만 적용된다는 점을 주목하기 바란다; 이것은 species 컬럼의 정렬에는 관여하
지 않는다.

:::MySQL Korea:::
제목검색
3.4. 데이터 베이스와 테이블에 대한 정보 얻기
3. 사용 설명서
만약에 데이터 베이스 또는 테이블 이름을 잊었거나, 또는 주어진 테이블의 구조(예를 들면, 컬럼의 이름이 무엇인지)를 모른다고
3.4. 데이터 베이스와 테이블에 대한 정보 얻기
할 경우에는? MySQL은 이러한 문제를 다루는 명령문을 제공해 줌으로서 데이터 베이스와 테이블에 대한 정보를 나타내도록 하
3.4 데이터 베이스와 테이블에 대한 정보 얻기
고 있다.
여러분은 앞에서 SHOW DATABASES를 보았는데, 이것은 서버가 관리하는 데이터 베이스를 목록으로 보여준다. 어떤 데이터 베
이스가 현재 사용되고 있는지 보기 위해서, DATABASE() 함수를 사용한다:
mysql> SELECT DATABASE();
+------------+
| DATABASE() |
+------------+
| menagerie |
+------------+
아직 아무런 데이터 베이스를 선택하지 않았다면, 결과는 NULL이 된다.
디폴트 데이터 베이스가 갖고 있는 테이블이 무엇인지를 보기 위해(예를 들면, 여러분이 테이블 이름에 대해 확신이 없다면), 다음
의 명령어를 사용한다:
mysql> SHOW TABLES;

:::MySQL Korea:::
+---------------------+
| Tables in menagerie |
+---------------------+
| event |
| pet |
+---------------------+
테이블의 구조를 알고 싶다면, DESCRIBE 명령어가 유용하다; 이 명령어는 각 테이블의 컬럼 정보를 표시해 준다:
mysql> DESCRIBE pet;
+---------+-------------+------+-----+---------+-------+
+---------+-------------+------+-----+---------+-------+
| name | varchar(20) | YES | | NULL | |
| owner | varchar(20) | YES | | NULL | |
| species | varchar(20) | YES | | NULL | |
| sex | char(1) | YES | | NULL | |
| birth | date | YES | | NULL | |

:::MySQL Korea:::
| death | date | YES | | NULL | |
+---------+-------------+------+-----+---------+-------+
Field는 컬럼 이름을 나타내며, Type은 컬럼에 대한 데이터 타입, NULL 은 컬럼이 NULL 값을 갖고 있는지 아닌지를 표시하며,
Key는 컬럼이 인덱싱이 되어 있는지 아닌지, 그리고 Default는 컬럼의 디폴트 값을 지정하고 있다.
테이블에 인덱스를 갖고 있다면, SHOW INDEX FROM tbl_name은 인덱스에 대한 정보를 보여 주게 된다.

:::MySQL Korea:::
제목검색
3.5. 배치(Batch)모드에서 mysql 사용 하기
3. 사용 설명서
앞의 섹션에서, 여러분은 mysql을 사용해서 쿼리를 입력하고 결과를 볼 수가 있었다. 여러분은 mysql을 배치 모드에서도 사용할
3.5. 배치(Batch)모드에서 mysql 사용 하기
수 있다. 이렇게 사용하기 위해서는, 명령어를 구동시키고 싶은 파일 안에 기록해 놓은 다음에, mysql이 이 파일에서 입력 값을 읽
3.5 배치(Batch)모드에서 mysql 사용 하기
어 오도록 명령하면 된다:
shell> mysql < batch-file
윈도우 환경에서 mysql를 구동시키고 파일 안에 문제를 일으키는 특수 문자가 있는 경우에는, 아래의 것을 실행한다:
C:￦> mysql -e "source batch-file"
명령어 라인에서 연결 파라미터를 지정하고자 할 경우에는, 명령어는 다음과 같이 된다:
shell> mysql -h host -u user -p < batch-file
이런 방식으로mysql을 사용할 때에는, 스크립트 파일을 하나 만들고, 그 다음에 스크립트를 실행시킨다.
스크립트 안에 있는 명령어 중에 하나가 에러를 발생시킨다고 하더라도 스크립트를 계속 진행 시키고자 한다면, --force 명령어
라인 옵션을 사용해야 한다.
왜 스크립트를 사용해야 하는가? 여기에 몇 가지 이유가 있다:
• 하나의 쿼리를 반복적으로 사용한다면(즉, 내일 또는 매주), 스크립트를 사용하면 매번 반복적으로 입력하는 것을 피

할 수 있다.

:::MySQL Korea:::
• 이미 있는 유사한 스크립트 파일을 복사하고 편집해서 새로운 쿼리를 만들 수 있다.
• 배치 모드는 또한 쿼리를 개발할 경우에 유용한데, 특히 다중 라인 명령어 또는 다중 명령어 시퀀스를 위한 것을 개발

할 때 유용하다. 여러분이 실수를 한다고 하더라도, 모든 것을 다시 타이핑할 필요가 없다. 간단히 스크립트를 수정해서 에
러를 바로 잡은 다음에, mysql이 이것을 다시 실행하도록 하면 된다.
• 대용량의 결과를 만들어 내는 쿼리를 가지고 있다면, 화면에 스크롤 되는 결과를 얻는 것보다는 종이에 출력을 얻는
것이 나을 것이다:
• shell> mysql < batch-file | more
• 다음의 진행을 위해 파일로 결과를 보낼 수 있다:
• shell> mysql < batch-file > mysql.out
• 여러분이 작성한 스크립트를 다른 사람에 줄 수 있으며, 그 사람들도 여러분과 동일한 명령어를 실행 시킬 수 있다.
• 어떤 상황에서는 상호 교류 동작(interactive)을 할 수 없는데, 예를 들면, 여러분이 cron 작업을 통해서 쿼리를 구

동 시킬 경우에, 여러분은 반드시 배치 모드를 사용해야 한다.
디폴트 결과 포맷은 배치 모드에서 mysql을 사용할 때와 상호 교류 동작시에 사용할 때가 다르게 나타난다. 예를 들면, SELECT
DISTINCT species FROM pet은 mysql이 상호 교류적으로 구동될 때에는 다음과 같이 나온다:
+---------+
| species |
+---------+
| bird |
| cat |
| dog |

:::MySQL Korea:::
| hamster |
| snake |
+---------+
대신에 배치 모드에서는, 결과가 다음과 같이 나온다:
species
bird
cat
dog
hamster
snake
만약에 배치 모드에서 상호 교류적인 결과값 포맷을 얻고자 한다면, mysql –t를 사용한다. 실행된 명령문에 결과 값을 다시 돌려
보내고 싶다면(to echo), mysql –vvv를 사용한다.
또한, source 또는 ￦. 명령어를 사용해서 mysql 프롬프트상에서 스크립트를 사용할 수도 있다:
mysql> source filename;
mysql> ￦. filename

:::MySQL Korea:::
제목검색
3.6. 일반적인 쿼리의 예제들(Examples)
3. 사용 설명서 3.6.1. 컬럼의 최대 값
3.6. 일반적인 쿼리의 예제들(Examples) 3.6.2. 특정 컬럼의 최대 값을 가지고 있는 줄(Row)
3.6 일반적인 쿼리의 예제들(Examples) 3.6.3. 그룹 당 컬럼의 최대 값

3.6.4. 특정 필드의 그룹 와이즈 최대 값을 가지고 있는 줄(Rows)
3.6.5. 사용자 지정 변수 사용하기
3.6.2 특정 컬럼의 최대값을 갖고 있는 줄(Row)
3.6.6. 외국어 키 사용하기
3.6.3 그룹별 최대 컬럼 수(Maximum of Column
per Group) 3.6.7. 두 개의 키상에서 검색하기
3.6.8. 일별 방문자수 계산하기
3.6.4 특정 필드의 그룹 와이즈(Group-wise) 최
대값을 갖는 줄 3.6.9. AUTO_INCREMENT 사용하기
3.6.5 사용자 정의 변수 사용하기(Using User-

Defined Variables) 여기에서는 MySQL에서 일반적으로 발생하는 문제점들을 해결할 수 있는 예제들을 보여 주기로 한다.

어떤 예제들은 테이블 shop 을 사용해서 특정 판매자(dealer)의 상품들(item number)의 값을 갖고 있도록 만든다. 각 판매자들
은 상품별로 정해진 단일 가격을 가지고 있고, 그 다음에 (article, dealer)는 레코드에 대한 프라이머리 키(primary key)라고 가
3.6.8 일별 방문자수 계산하기(Calculating Visits
정한다.
Per Day)
명령어 라인에서 mysql을 구동 시키고 데이터 베이스를 선택한다:
shell> mysql your-database-name
(대부분의MySQL 설치판에서, 여러분은 test라는 이름의 데이터 베이스를 사용할 수 있을 것이다).
아래의 명령어를 가지고 예제로 사용할 테이블을 생성하고 데이터를 그 안에 넣는다:
mysql> CREATE TABLE shop (

:::MySQL Korea:::
-> article INT(4) UNSIGNED ZEROFILL DEFAULT '0000' NOT NULL,
-> dealer CHAR(20) DEFAULT '' NOT NULL,
-> price DOUBLE(16,2) DEFAULT '0.00' NOT NULL,
-> PRIMARY KEY(article, dealer));
mysql> INSERT INTO shop VALUES
-> (1,'A',3.45),(1,'B',3.99),(2,'A',10.99),(3,'B',1.45),
-> (3,'C',1.69),(3,'D',1.25),(4,'D',19.95);
명령문을 입력한 후에는, 테이블은 아래의 내용을 갖게 될 것이다:
mysql> SELECT * FROM shop;
+---------+--------+-------+
| article | dealer | price |
+---------+--------+-------+
| 0001 | A | 3.45 |
| 0001 | B | 3.99 |
| 0002 | A | 10.99 |
| 0003 | B | 1.45 |

:::MySQL Korea:::
| 0003 | C | 1.69 |
| 0003 | D | 1.25 |
| 0004 | D | 19.95 |
+---------+--------+-------+

:::MySQL Korea:::
제목검색
3.6.1. 컬럼에 대한 최대 값(Maximum Value)
3. 사용 설명서
“최고(highest)의 아이템 숫자는 어떤 것인가?”

SELECT MAX(article) AS article FROM shop;
+---------+
| article |
+---------+
| 4|
+---------+
:::MySQL Korea:::
제목검색
3.6.2. 특정 컬럼의 최대값을 갖고 있는 줄(Row)
3. 사용 설명서
Task: 가장 비싼 상품의 숫자, 판매자, 그리고 가격을 찾는다.
3.6.2 특정 컬럼의 최대값을 갖고 있는 줄(Row)

서브 쿼리를 사용하면 간단히 처리할 수 있다:
SELECT article, dealer, price
FROM shop
WHERE price=(SELECT MAX(price) FROM shop);
다른 해결 방법은 모든 줄은 가격 내림 차순으로 정렬시킨 다음에 MySQL-특성(specific) LIMIT 구문을 사용해서 맨 윗줄만 가

져오면 된다:
FROM shop
ORDER BY price DESC
LIMIT 1;
Note: 만약에 가장 비싼 제품들이 여러 개가 있고, 가격이 19.95라면, LIMIT 솔루션은 이들 중에 한 개만 보여 주게 된다.
:::MySQL Korea:::
제목검색
3.6.3. 그룹별 최대 컬럼 수(Maximum of Column per Group)
3. 사용 설명서
Task: 상품별로 최고의 값을 찾는다.
3.6.3 그룹별 최대 컬럼 수(Maximum of Column per

SELECT article, MAX(price) AS price
Group)
FROM shop
GROUP BY article
+---------+-------+
| article | price |
+---------+-------+
| 0001 | 3.99 |
| 0002 | 10.99 |
| 0003 | 1.69 |
| 0004 | 19.95 |
+---------+-------+

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
3.6.4. 특정 필드의 그룹 와이즈(Group-wise) 최대값을 갖는 줄
3. 사용 설명서
Task: 각 상품별로, 판매자를 찾거나 또는 최고의 값을 갖고 있는 판매자를 찾는
다.
3.6.4 특정 필드의 그룹 와이즈(Group-wise) 최대값
을 갖는 줄
이 문제는 아래와 같은 서브 쿼리를 사용해서 해결할 수 있다:
FROM shop s1
WHERE price=(SELECT MAX(s2.price)
FROM shop s2
WHERE s1.article = s2.article);
:::MySQL Korea:::
제목검색
3.6.5. 사용자 정의 변수 사용하기(Using User-Defined Variables)
3. 사용 설명서
여러분은 결과값을 클라이언트에 있는 임시 변수에 저장하지 않고 MySQL사용자 변수에 기억시키도록 할 수가 있다.
( Section 9.3, “사용자 지정(User-Defined) 변수”를 참조할 것.)
3.6.5 사용자 정의 변수 사용하기(Using User-
Defined Variables)
예를 들면, 최고 가격 및 최저 가격을 갖는 상품을 찾기 위해 여러분은 아래와 같이 할 수 있다:
mysql> SELECT @min_price:=MIN(price),@max_price:=MAX(price) FROM shop;
mysql> SELECT * FROM shop WHERE price=@min_price OR price=@max_price;
+---------+--------+-------+
| article | dealer | price |
+---------+--------+-------+
| 0003 | D | 1.25 |
| 0004 | D | 19.95 |
+---------+--------+-------+
:::MySQL Korea:::
제목검색
3.6.6. 외국어 키(Foreign Keys) 사용하기
3. 사용 설명서
MySQL에서, InnoDB 테이블은 외국어 키 constraints 검사를 지원한다. Section 14.2, “InnoDB 스토리지 엔지”, 및
Section 1.9.5.5, “외국어 키(Foreign Keys)”를 참조할 것.
외국어 키 constraint는 단순히 두 테이블을 합할 때에는 필요하지 않다. InnoDB가 아닌 스토리지 엔진에 대해서는, 컬럼이
REFERENCES tbl_name(col_name) 구문을 사용하도록 정의할 때 사용 가능한데, 이것은 실제로 아무런 효과도 없으며, 또한 여
러분이 지금 정의한 컬럼은 다른 테이블에 있는 컬럼을 참조하도록 의도된 것이라는 것을 알려주는 메모 또는 코멘트 역할만 하게
된다. 아래와 같은 신텍스를 사용할 때는 매우 중요하다:
• MySQL은 col_name 이 실제로 tbl_name 에 있는지(또는 tbl_name 자체가 있는지) 확인하기 위한 어떠한 종류의
CHECK도 실행하지 않는다.
• MySQL 은 여러분이 정의한 테이블에서 줄을 가져와서 삭제하는 것과 같은 행동을 tbl_name 에서는 전혀 하지 않는

다; 다른 말로 표현하면, 이 신텍스는 ON DELETE 또는 ON UPDATE 의 구동상에 아무런 영향을 미치지 않는다. (여러
분이ON DELETE 또는 ON UPDATE 구문을 REFERENCES 구문의 일부분으로 작성한다 하더라도, 이것은 무시되어
버린다.)
• 이 신텍스는 column을 만들어 낸다; 이것은 어떤 종류의 인덱스 또는 키를 만들지는 않는다.
• 이 신텍스는 InnoDB 테이블을 정의하고자 사용될 경우에는 에러를 발생시킨다.
여러분은 여기에서 보듯이, 컬럼을 만들어서 조인(join) 컬럼으로 사용할 수 있다:
CREATE TABLE person (
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,

:::MySQL Korea:::
name CHAR(60) NOT NULL,
PRIMARY KEY (id)
);
CREATE TABLE shirt (
id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
style ENUM('t-shirt', 'polo', 'dress') NOT NULL,
color ENUM('red', 'blue', 'orange', 'white', 'black') NOT NULL,
owner SMALLINT UNSIGNED NOT NULL REFERENCES person(id),
PRIMARY KEY (id)
);
INSERT INTO person VALUES (NULL, 'Antonio Paz');
SELECT @last := LAST_INSERT_ID();

:::MySQL Korea:::
INSERT INTO shirt VALUES
(NULL, 'polo', 'blue', @last),
(NULL, 'dress', 'white', @last),
(NULL, 't-shirt', 'blue', @last);
INSERT INTO person VALUES (NULL, 'Lilliana Angelovska');
SELECT @last := LAST_INSERT_ID();
INSERT INTO shirt VALUES
(NULL, 'dress', 'orange', @last),
(NULL, 'polo', 'red', @last),
(NULL, 'dress', 'blue', @last),
(NULL, 't-shirt', 'white', @last);
SELECT * FROM person;
+----+---------------------+

:::MySQL Korea:::
| id | name |
+----+---------------------+
| 1 | Antonio Paz |
| 2 | Lilliana Angelovska |
+----+---------------------+
SELECT * FROM shirt;
+----+---------+--------+-------+
| id | style | color | owner |
+----+---------+--------+-------+
| 1 | polo | blue | 1|
| 2 | dress | white | 1|
| 3 | t-shirt | blue | 1|
| 4 | dress | orange | 2|
| 5 | polo | red | 2|
| 6 | dress | blue | 2|

:::MySQL Korea:::
| 7 | t-shirt | white | 2|
+----+---------+--------+-------+
SELECT s.* FROM person p, shirt s
WHERE p.name LIKE 'Lilliana%'
AND s.owner = p.id
AND s.color <> 'white';
+----+-------+--------+-------+
| id | style | color | owner |
+----+-------+--------+-------+
| 4 | dress | orange | 2|
| 5 | polo | red | 2|
| 6 | dress | blue | 2|
+----+-------+--------+-------+

:::MySQL Korea:::
이러한 형태로 사용될 경우에, REFERENCES 구문은 SHOW CREATE TABLE 또는 DESCRIBE 구문의 결과에는 나타나지 않
는다:
SHOW CREATE TABLE shirt￦G
*************************** 1. row ***************************
Table: shirt
Create Table: CREATE TABLE `shirt` (
ìd` smallint(5) unsigned NOT NULL auto_increment,
`style` enum('t-shirt','polo','dress') NOT NULL,
`color` enum('red','blue','orange','white','black') NOT NULL,
òwner` smallint(5) unsigned NOT NULL,
PRIMARY KEY (ìd`)
) ENGINE=MyISAM DEFAULT CHARSET=latin1
여기처럼 REFERENCES 를 컬럼 정의문에서 코멘트 형태 또는 “리마인더(reminder)”로 사용하는 것은 MyISAM 및

BerkeleyDB 테이블에서도 적용 되어진다.

:::MySQL Korea:::
제목검색
3.6.7. 두 개의 키(Two Keys)상에서 검색
3. 사용 설명서
단일 키를 사용하는 OR는 AND에서 다루어진 것처럼 매우 잘 동작을 하게 된다.

한가지 까다로운 경우는 OR로 조합되어 있는 두 개의 다른 키에서 검색을 하는 것이다:
SELECT field1_index, field2_index FROM test_table
WHERE field1_index = '1' OR field2_index = '1'
이것은MySQL 5.0.0에서부터 최적화 되었다. Section 7.2.6, “인덱스 병합 최적화(Index Merge Optimization)”를 참조할 것.
여러분은 또한 두 의 독립적인 SELECT 명령문에서 나오는 결과를 조합하는 UNION을 사용해서 문제를 효과적으로 해결할 수 있
다. Section 13.2.7.2, “UNION 신텍스”를 참조할 것.
SELECT 명령문은 오직 한 개의 키만을 검색하고 최적화 시킨다:
SELECT field1_index, field2_index
FROM test_table WHERE field1_index = '1'
UNION
SELECT field1_index, field2_index
FROM test_table WHERE field2_index = '1';

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
3.6.8. 일별 방문자수 계산하기(Calculating Visits Per Day)
3. 사용 설명서
아래의 예제는 비트 그룹 함수를 사용해서 월별 일수를 계산하고 웹 사이트에 일별로 방문한 사람의 숫자를 계산하는 방법을 알려
주는 것이다.
3.6.8 일별 방문자수 계산하기(Calculating Visits
Per Day)
CREATE TABLE t1 (year YEAR(4), month INT(2) UNSIGNED ZEROFILL,
day INT(2) UNSIGNED ZEROFILL);
INSERT INTO t1 VALUES(2000,1,1),(2000,1,20),(2000,1,30),(2000,2,2),
(2000,2,23),(2000,2,23);
이 예제 테이블에는 사용자가 페이지를 방문하는 것을 나타내는 년-월-일(year-month-day)값이 있다. 월별로 며칠 동안 방문

자가 있었는지 알아보기 위해, 다음의 쿼리를 사용한다:
SELECT year,month,BIT_COUNT(BIT_OR(1<<day)) AS days FROM t1
GROUP BY year,month;
Which returns:
+------+-------+------+
| year | month | days |
+------+-------+------+

:::MySQL Korea:::
| 2000 | 01 | 3|
| 2000 | 02 | 2|
+------+-------+------+
쿼리는 중복되는 엔트리를 자동으로 삭제 시키면서, 각 년/월 조합 테이블에서 얼마나 많은 날들이 발생했는지를 계산한다.

:::MySQL Korea:::
제목검색
3.6.9. AUTO_INCREMENT사용하기
3. 사용 설명서
AUTO_INCREMENT는 새로운 줄에 대해 유일한(unique) 값을 생성시킬 때 사용된다:
CREATE TABLE animals (
id MEDIUMINT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (id)
);
INSERT INTO animals (name) VALUES
('dog'),('cat'),('penguin'),
('lax'),('whale'),('ostrich');
SELECT * FROM animals;
Which returns:

:::MySQL Korea:::
+----+---------+
| id | name |
+----+---------+
| 1 | dog |
| 2 | cat |
| 3 | penguin |
| 4 | lax |
| 5 | whale |
| 6 | ostrich |
+----+---------+
여러분은 LAST_INSERT_ID() SQL 함수 또는 mysql_insert_id() C API 함수를 사용해서 가장 최근의 AUTO_INCREMENT

값을 불러올 수가 있다. 이 함수들은 연결 특성(connection-specific)이 있기 때문에, 이것들이 생성하는 결과 값들은 삽입을 실행
하는 다른 연결에는 영향을 미치지 않게 된다.
Note: 다중 줄 삽입에 대해서는, LAST_INSERT_ID() 와 mysql_insert_id()는 실제로 삽입된 맨 처음 줄로부터

AUTO_INCREMENT 를 돌려 준다. 이것은 리플리케이션 설정에 있는 다른 서버에서 다중 줄 삽입이 정확히 이루어 지도록 해 준
다.
MyISAM 및 BDB 테이블에서, 여러분은 다중 컬럼 인덱스에 있는 두번째(secondary)컬럼에 AUTO_INCREMENT를 지정할 수

있다. 이와 같은 경우, AUTO_INCREMENT 컬럼을 위한 생성 값은 MAX(auto_increment_column) + 1 WHERE
prefix=given-prefix와 같이 만들어진다. 이것은 여러분이 데이터를 주문 받은(ordered)그룹 안에 넣고자 할 경우에 매우 유용

:::MySQL Korea:::
하다.
CREATE TABLE animals (
grp ENUM('fish','mammal','bird') NOT NULL,
id MEDIUMINT NOT NULL AUTO_INCREMENT,
PRIMARY KEY (grp,id)
);
INSERT INTO animals (grp,name) VALUES
('mammal','dog'),('mammal','cat'),
('bird','penguin'),('fish','lax'),('mammal','whale'),
('bird','ostrich');
SELECT * FROM animals ORDER BY grp,id;
다음을 리턴 한다:
+--------+----+---------+

:::MySQL Korea:::
| grp | id | name |
+--------+----+---------+
| fish | 1 | lax |
| mammal | 1 | dog |
| mammal | 2 | cat |
| mammal | 3 | whale |
| bird | 1 | penguin |
| bird | 2 | ostrich |
+--------+----+---------+
이와 같은 경우에(AUTO_INCREMENT 컬럼이 다중 컬럼 인덱스의 일부분이 되는 경우), AUTO_INCREMENT 값은 여러분이

어떤 그룹에 있는 제일 큰 AUTO_INCREMENT 값을 가지고 줄을 삭제할 경우에 다시 사용된다는 점을 알아두기 바란다. 이것은
MyISAM 테이블에서도 동일하게 발생되는데, 일반적으로 AUTO_INCREMENT 값은 다시 사용되지는 않는다.
만약에 AUTO_INCREMENT 컬럼이 다중 인덱스의 부분이라면, MySQL은 AUTO_INCREMENT 컬럼을 가지고 시작하는 인덱
스를 사용해서 시퀀스 값을 만들어 낼 것이다. 예를 들면, 만약에 animals 테이블이 PRIMARY KEY (grp, id) 및 INDEX (id) 인
덱스를 갖고 있다면, MySQL은 시퀀스 값을 만들기 위해 PRIMARY KEY를 무시하게 될 것이다. 그 결과로, 테이블은 단일 시퀀스
를 갖게 되며, grp의 값 별로 시퀀스를 갖지는 않는다.
AUTO_INCREMENT 의 값이 1인 아닌 것으로 시작으로 하기 위해, 아래와 같이 그 값을 CREATE TABLE 또는 ALTER

TABLE을 가지고 설정한다:
mysql> ALTER TABLE tbl AUTO_INCREMENT = 100;
AUTO_INCREMENT에 대한 보다 자세한 정보는 다음과 같다:

:::MySQL Korea:::
• AUTO_INCREMENT 속성을 컬럼에 할당하는 방법: Section 13.1.5, “CREATE TABLE 신텍스”, 및
Section 13.1.2, “ALTER TABLE 신텍스”를 참조.
• SQL 모드에 따른 AUTO_INCREMENT 의 동작 원리: Section 5.2.5, “서버 SQL 모드”를 참조.
• 가장 최신의 AUTO_INCREMENT 값을 찾기: Section 12.1.3, “비교 함수와 연산자”를 참조.
• AUTO_INCREMENT 값이 사용되도록 설정하기: Section 13.5.3, “SET 신텍스”를 참조.
• AUTO_INCREMENT 및 리플리케이션: Section 6.7, “리플리케이션 의 특징과 알려진 문제점들”를 참조할 것.
• 리플리케이션용으로 사용할 수 있는 AUTO_INCREMENT (auto_increment_increment 및

auto_increment_offset) 과 관련된 서버 시스템 변수: Section 5.2.2, “서버 시스템 변수”를 참조.

:::MySQL Korea:::
제목검색
3.7. 쌍둥이 프로젝트에서의 쿼리(Queries from the Twin Project) - Skip
3. 사용 설명서 3.7.1. Find All Non-distributed Twins
3.7. 쌍둥이 프로젝트에서의 쿼리(Queries from the Twin Project) 3.7.2. Show a Table of Twin Pair Status
3.7 쌍둥이 프로젝트에서의 쿼리(Queries from the Twin Project)
:::MySQL Korea:::
제목검색
3.8. 아파치와 함께 MySQL 사용하기
3. 사용 설명서
여기에는 여러분이 MySQL데이터 베이스에 대해 확신을 가지고 MySQL테이블에 로그 파일을 기입할 수 있도록 하는 프로그램이
3.8. 아파치와 함께 MySQL 사용하기
있다.
3.8 아파치와 함께 MySQL 사용하기
여러분은 아파치 구성 파일에 아래의 내용을 넣음으로써 MySQL이 보다 쉽게 아파치 로깅 포맷을 읽을 수 있도록 할 수 있다:
LogFormat ￦
"￦"%h￦",%{%Y%m%d%H%M%S}t,%>s,￦"%b￦",￦"%{Content-Type}o￦", ￦
￦"%U￦",￦"%{Referer}i￦",￦"%{User-Agent}i￦""
이와 같은 포맷의 로그 파일을 MySQL안으로 로드하기 위해서는, 아래와 비슷한 명령문을 사용한다:
LOAD DATA INFILE '/local/access_log' INTO TABLE tbl_name
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '￦￦'
LogFormat 라인이 로그 파일에 써 넣을 수 있는 컬럼을 갖는 테이블을 만들어야 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 4. MySQL 프로그램 사용하기
4. MySQL 프로그램 사용하기 4.1. MySQL 프로그램 소개
4 MySQL 프로그램 사용하기 4.2. MySQL 프로그램 호출하기
4.1 MySQL 프로그램 소개 4.3. 프로그램 옵션 지정하기
4.2 MySQL 프로그램 호출 하기 4.3.1. 명령어 라인에서 옵션 사용하기

4.3.2. 옵션 파일 사용하기
4.3 프로그램 옵션 지정하기
4.3.3. 환경 변수를 사용하여 옵션 지정하기
4.3.1 명령어 라인에서 옵션 사용 하기
4.3.4. 옵션을 사용하여 프로그램 변수 설정하기
4.3.2 옵션 파일 사용 하기
4.3.3 환경 변수를 사용해서 옵션 지정 하기
이 장에서는 MySQL AB사가 제공하는 명령어 라인 프로그램에 대해 개략적으로 설명을 하고 여러분이 이러한 프로그램을 구동시
4.3.4 옵션을 사용해서 프로그램 변수 설정하기
킬 때 사용하는 옵션 지정용 신텍스에 대해 설명하기로 한다. 대부분의 프로그램은 자체의 기능을 특징짓는 옵션을 가지고 있으나,
옵션 신텍스는 이러한 옵션들과 매우 유사한 기능들을 제공한다. 이 다음의 장에서는 각 프로그램 별로 보다 자세한 설명을 하게
될 것이며, 프로그램들이 인식하는 옵션들에 대해서도 함께 설명을 하기로 한다.
MySQL AB사는 또한 MySQL 서버와 함께 사용할 수 있는 세 가지의 GUI클라이언트 프로그램을 같이 제공한다:
● MySQL 관리자(Administrator): 이 툴은 MySQL 서버, 데이터 베이스, 테이블, 그리고 사용자 계정을 관리하기 위한 것
이다.
● MySQL 쿼리 브라우저(Query Browser): 이 그래픽 툴은 MySQL에서 쿼리를 생성하고, 실행하고, 그리고 최적화 시키
기 위한 툴이다.
● MySQL 마이그레이션 툴 킷(Migration Toolkit): 이것은 여러분이 다른 관계 지향 데이터 베이스 관리 시스템에 있는 스
키마와 데이터를 MySQL에서 사용할 수 있도록 도와주는 프로그램이다.
이러한 GUI 프로그램은 각각 별도의 매뉴얼이 있으며 http://dev.mysql.com/doc/에서 찾을 수 있을 것이다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 4.1. MySQL 프로그램 소개
4. MySQL 프로그램 사용하기 MySQL AB사는 여러 형태의 프로그램을 제공한다:

4.1. MySQL 프로그램 소개
4.1 MySQL 프로그램 소개 ● MySQL 서버 및 서버 스타트업 스크립트:

❍ Mysqld 는 MySQL 서버이다.
❍ mysqld_safe, mysql.server, 및 mysqld_multi는 서버 스타트업 스크립트이다.
❍ mysql_install_유는 데이터 디렉토리와 초기 데이터 베이스를 초기화 시킨다.
❍ MySQL 인스턴스 관리자는 MySQL서버 인스턴스를 모니터하고 관리해 준다.
Chapter 5, 데이터 베이스 관리(Administration)에서 보다 자세히 설명하기로 한다
● 서버에 접속하는 클라이언트 프로그램:

❍ Mysql은 쌍방향 또는 배치 모드로 SQL명령문을 실행하기 위한 명령어 라인 클라이언트다.
❍ Mysqladmin은 관리 클라이언트이다.
❍ Mysqlcheck은 테이블 유지 관리 기능(table maintenance operations)을 수행한다.
❍ mysqldump 및 mysqlhotcopy은 데이터 베이스 백업을 실행한다.
❍ Mysqlimport는 데이터를 들여 온다(import).
❍ Mysqlshow는 데이터 베이스와 테이블의 정보를 화면에 보여준다.
Chapter 8, 클라이언트 및 유틸리티 프로그램에서 보다 자세히 다루기로 한다
● 서버와 별도로 동작하는 유틸리티 프로그램:

❍ Myisamchk는 테이블 유지 관리 기능(maintenance operations)을 수행한다.
❍ Myisampack는 압축된 읽기 전용 테이블을 만든다.
❍ Mysqlbinlog는 바이너리 로그 파일을 실행하는 툴이다.
❍ Perror는 에러 코드의 의미를 화면에 보여 준다.

:::MySQL Korea:::
Chapter 5, 데이터 베이스 관리(Administration)에서 myisamchk에 대해 다시 설명할 것이며, Chapter 8, 클라이언트

및 유틸리티 프로그램 에서 는 다른 프로그램에 대해서 설명하기로 한다.
대부분의 MySQL 배포판은 위의 모든 프로그램을 함께 제공하지만, 특정 플랫폼에 관련된 배포판 에서는 같이 제공을 하지 않는
다. (예를 들면, 서버 스타트업 스크립트는 윈도우에서는 사용되지 않는다.) RPM 배포판은 보다 특별하게 만들어진 것이므로 역
시 위의 프로그램들을 같이 제공하지 않는다. 서버용 RPM 이 있고, 클라이언트 프로그램용 RPM이 별도로 존재하는 것이다. 여러
분이 하나 또는 그 이상의 프로그램을 누락시켰다고 생각하면, Chapter 2, MySQL 설치 및 업그레이드를 참조하여 각 배포판이
갖고 있는 내용물과 이에 해당하는 정보를 알아보기 바란다. 여러분이 갖고 있는 배포판이 모든 프로그램을 포함하지 않은 것일 수
도 있으며 다른 무엇인가를 추가로 설치할 필요가 생길 수도 있다.

:::MySQL Korea:::
제목검색
4.2. MySQL 프로그램 호출 하기
4. MySQL 프로그램 사용하기
명령어 라인에서 MySQL 프로그램을 호출하기 위해서는(즉, 쉘 또는 명령어 프롬프트에서), 프로그램 이름과 그 프로
4.2. MySQL 프로그램 호출 하기
그램이 실행할 일을 지시하는 옵션 또는 인수를 함께 입력한다. 아래의 명령어는 프로그램 호출의 샘플을 보여주는 것
4.2 MySQL 프로그램 호출 하기 이다. “shell>”은 명령어 해석기(interpreter)를 위한 프롬프트를 나타낸다. 여러분이 사용하는 명령어 해석기에
따라 서로 다른 프롬프트가 나타날 것이다. 전형적인 프롬프트는, sh 또는 bash에서는 $, csh 또는 tcsh에서는 %, 그
리고 윈도우 command.com 또는 cmd.exe 명령어 해석기에 대해서는 C:￦> 가 된다.
shell> mysql -u root test
shell> mysqladmin extended-status variables
shell> mysqlshow --help
shell> mysqldump --user=root personnel
단일 또는 중복 대쉬(dash) (‘-’, ‘--’)로 시작하는 인수들은 옵션 사항이다. 전형적으로 옵션들은 서버에 접

속해야 하는 프로그램의 형태 또는 프로그램의 실행 모드를 지정해 준다. 옵션 신텍스에 대해서는 Section 4.3, “프
로그램 옵션 지정하기”에서 다루기로 한다.
옵션이 없는(Non-option) 인수들(앞에 대쉬가 없는 인수들)은 프로그램에 추가적인 정보를 제공해 주는 것이다. 예
를 들면, mysql 프로그램은 처음에 나오는 옵션 없는 인수를 데이터 베이스의 이름으로 해석하는데, 따라서 명령어
mysql -u root test는 여러분이test 데이터 베이스를 사용하고자 한다는 것을 나타내는 것이다.
이 다음의 섹션에서는 프로그램이 이해하는 인수에는 어떤 것들이 있으며 옵션 없이 사용하는 인수들은 무엇을 의미
하는 것인지에 대해 각 프로그램 별로 설명을 하기로 하겠다.

:::MySQL Korea:::
어떤 옵션들은 여러 프로그램에서 공통으로 사용되기도 한다. 이러한 옵션들중에 가장 대표적인 것들은 --host (또
는 -h), --user (또는 -u), 그리고 --password (또는 -p) 옵션으로서, 이것들은 접속 파라미터를 지정하는 것들
이다. 이 옵션들은 MySQL 서버가 구동되는 호스트를 지정하며, 또한 MySQL계정의 사용자 이름과 패스워드를 나타
내는 것들이다. 모든 MySQL 클라이언트 프로그램들은 이러한 옵션들을 이해한다; 이 옵션들을 사용해서 여러분은
어떤 서버에 접속을 하고 어떤 계정을 사용할 것인지를 지정할 수 있게 된다.
여러분은 MySQL 프로그램들을 호출하기 위해서는 이 프로그램들이 설치되어 있는 bin 디렉토리의 경로 이름을 사용
할 필요가 있다는 것을 알게 될 것이다. 이것은 여러분이 bin 디렉토리가 아닌 곳에서 MySQL프로그램을 구동 시키고
자 할 때마다 “program not found” 에러를 보게 된다면 느낄 수 있을 것이다. 보다 편리하게 MySQL을 사용하기
위해서는, bin 디렉토리의 경로 이름을 PATH 환경 변수 설정에 추가하면 된다. 이렇게 함으로써 전체 경로의 이름을
입력하지 않고 단순히 프로그램의 이름만을 입력해서 구동시킬 수 있게 된다. 예를 들면, 만약에 mysql이 /usr/local/
mysql/bin에 설치되어 있다면, 여러분은 이것을 단지 mysql의 호출로만으로도 실행 시킬 수 있게 된다; 이것을 호출
할 때 더 이상 /usr/local/mysql/bin/mysql 전체를 입력할 필요가 없게 된다.
PATH 변수 설정에 대한 사용 방법은 여러분이 사용하는 명령어 해석기 사용 설명서를 참조하기 바란다. 환경 변수
설정 신텍스는 각 명령어 해석기와 관련을 갖고 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 4.3. 프로그램 옵션 지정하기

4.3.1. 명령어 라인에서 옵션 사용하기
4. MySQL 프로그램 사용하기 4.3.2. 옵션 파일 사용하기
4.3. 프로그램 옵션 지정하기 4.3.3. 환경 변수를 사용해서 옵션 지정하기
4.3 프로그램 옵션 지정하기 4.3.4. 옵션을 사용해서 프로그램 변수 설정하기
4.3.1 명령어 라인에서 옵션 사용 하기 MySQL프로그램용 옵션을 지정하는 데에는 몇 가지 방법이 있다:
4.3.2 옵션 파일 사용 하기
● 명령어 라인에서 프로그램 이름 다음에 옵션을 열거한다. 이것은 프로그램을 특별하게 호출할 때 사용하는 가장 일반적인
4.3.3 환경 변수를 사용해서 옵션 지정 하기
방법이다.
4.3.4 옵션을 사용해서 프로그램 변수 설정하기
● 프로그램이 시작될 때 읽게 되는 옵션 파일에 옵션을 열거한다. 이 방법은 프로그램이 실행될 때마다 이 옵션을 사용하도
록 하게 할 경우에 쓰는 일반적인 방법이다.
● 환경 변수에 옵션을 열거한다. 이 방법은 프로그램이 실행 될 때마다 이 옵션을 적용하고자 할 경우에 유용한 방법이다. 실
제로는, 이러한 목적으로는 옵션 파일들이 주로 사용된다. 하지만, Section 5.13.2, “유닉스에서 다중 서버 구동 시키
기”에서는 환경 변수들이 보다 효과적으로 사용될 수 있다는 것을 보여 준다. 그곳에서는 이러한 변수들을 사용해서 서버
와 클라이언트 프로그램 모두를 위한 TCP/IP 포트 및 유닉스 소켓 파일을 효과적으로 지정하는 방법을 설명한다.
어떤 변수들이 지정되어졌는지 확인 하기 위해, MySQL 프로그램은 우선 환경 변수들을 검사하게 되고, 그 다음에 옵션 파일들을
읽고, 그 다음에 마지막으로 명령어 라인을 검사하게 된다. 하나의 옵션이 여러 번 지정되어 있다면, 마지막에 나오는 것이 우선권
을 갖게 된다. 이것은 환경 변수가 가장 낮은 순위를 갖고 명령어 라인이 가장 높은 우선권을 갖는다는 것을 의미하는 것이다.
여러분은 옵션 파일에 있는 프로그램 옵션에 대해 디폴트 값을 지정해서 프로그램들이 이것을 사용하도록 활용할 수도 있다. 이렇
게 하면 프로그램을 실행시킬 때마다 일일이 입력을 하는 수고를 피할 수 있을 뿐만 아니라, 필요하다면 명령어 라인에서 다른 옵션
을 지정해 줌으로서 디폴트 값을 무시하도록 만들 수도 있게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 4.3.1. 명령어 라인에서 옵션 사용 하기
4. MySQL 프로그램 사용하기 명령어 라인에서 지정되는 옵션들은 아래의 규칙을 따른다:
4.3. 프로그램 옵션 지정하기
4.3.1 명령어 라인에서 옵션 사용 하기 ● 옵션은 명령어 다음에 입력한다.

● 옵션 인수는 약식 이름(short name) 또는 전체 이름(ling name)에 따라서 단일 대쉬 또는 이중 대쉬를 사용한다. 대부분
의 옵션들은 두 가지 형태를 모두 갖고 있다. 예를 들면, -? 과 --help 는 MySQL 프로그램이 도움말을 보여주도록 지시
하는 옵션의 약식 이름과 전체 이름이 된다.
● 옵션 이름은 대소 문자를 구분한다. -v 와 -V 는 모두 사용 가능하지만 의미는 서로 다른 것이다. (각각 --verbose 과
--version 옵션의 약식 이름이 된다.)
● 어떤 옵션들은 옵션 이름 다음에 값을 가지게 된다. 예를 들면, -h localhost 또는 --host=localhost 은 클라이언트 프로
그램에 MySQL 서버 호스트를 지정해 주는 것이다. 옵션 값은 MySQL이 구동되고 있는 호스트의 이름을 프로그램에게 알
려 준다.
● 값을 가진 전체 이름의 옵션에 대해서는, 옵션 이름과 그 값을 ‘=’ 기호를 가지고 구분해 놓는다. 약식 이름 옵션의 경우
에는, 옵션 값을 옵션 바로 다음에 붙여 쓰거나, 한 칸 띄운 다음에 기입한다: -hlocalhost 과 -h localhost 는 동일한 표현
이다. 이러한 규칙에서 한 가지 예외 규정이 있는데, MySQL패스워드를 지정할 때가 해당된다. 이 옵션은 전체 이름을 사용
해서 --password=pass_val 또는 --password로 쓸 수 있다. 두 번째의 경우(패스워드 값이 없는 경우), 프로그램은 여
러분에게 패스워드를 입력할 수 있는 프롬프트를 보여준다. 패스워드 옵션은 또한 약식 이름 형태인 -ppass_val 또는 –p
로 사용될 수 있다. 하지만, 약식 이름의 경우, 패스워드 값을 주게 되면, 옵션과 그 값 사이에 빈칸(space)를 사용하지 말
아야 한다. 그 이유는 옵션 문자 다음에 스페이스를 주게 되면, 프로그램은 뒤 따라오는 인수가 패스워드 값인지 또는 어떤
다른 종류의 인수 값인지 알지 못하기 때문이다. 결론적으로, 아래의 두 명령어는 완벽하게 서로 틀린 의미를 갖게 된다:
• shell> mysql -ptest
• shell> mysql -p test

:::MySQL Korea:::
첫 번째 명령어는 mysql이 test를 패스워드 값으로 사용하도록 지시하지만, 디폴트 데이터 베이스를 지정하지는 않게 된
다. 두 번째 명령어는 mysql가 프롬프트를 패스워드로 사용하고 test를 디폴트 데이터 베이스로 사용하도록 지시하는 것
이다.
어떤 옵션들은 결과를 활성화 또는 비활성화(turn on or off)시키는 기능을 제어하기도 한다. 예를 들면, mysql 클라이언트는 --
column-names 옵션을 지원하는데, 이 옵션은 쿼리 결과를 보여줄 때 컬럼 이름 열을 화면에 보여줄 지 또는 숨길지를 결정한다.
이 옵션의 디폴트 값은 보여주는 것이다. 하지만, 여러분은 이 기능을 어떤 상황에서는 숨길 수도 있는데, 예를 들면 mysql의 결과
를 다른 프로그램에 보내서 초기 헤더 라인을 뺀 데이터 부분만을 보고자 할 경우가 여기에 해당한다.
컬럼 이름을 비활성화 시키기 위해서는, 아래의 형태중에 하나를 가지고 옵션을 지정하면 된다:
--disable-column-names
--skip-column-names
--column-names=0
--disable 과 --skip 접두사 및 =0 접미사는 모두 동일한 효과를 나타낸다: 이것들은 옵션을 비활성화 시킨다.
옵션을 “enabled” 하게 만드는 형태는 다음과 같이 지정될 수 있다:
--column-names
--enable-column-names
--column-names=1
만약에 옵션이 –loose 다음에 나온다면, 프로그램이 그 옵션을 인식하지 못할 경우에는 에러를 보이면서 종료하는 대신에, 경고
메시지만을 보여주게 된다:
shell> mysql --loose-no-such-option
mysql: WARNING: unknown option '--no-such-option'

:::MySQL Korea:::
--loose 접두사는 동일 머신에 다중의 MySQL을 설치한 장비에서 프로그램을 구동시키고 옵션 파일에 옵션을 기술해 놓을 때 유
용하게 사용할 수 있는 것이다. 한 프로그램의 모든 버전이 인식하지 못하는 옵션에 대해서는 --loose 접두사를 가지고 줄 수 있
다(또는 옵션 파일에서는 loose 를 사용한다). 이 옵션을 인식하는 프로그램 버전은 정상적으로 프로세스를 진행하고, 이것을 인식
하지 못하는 버전은 경고 메시지를 보낸 다음에 무시해 버리게 된다.
때때로 mysql과 함께 유용하게 사용할 수 있는 옵션이 --execute 또는 -e 옵션인데, 이것은 SQL명령문을 서버에 패스할 때 사
용된다. 이러한 명령문들은 단일 또는 이중 인용 부호로 묶여야 한다. 명령문안에서 인용 부호를 사용하고자 한다면, 명령문에 대해
서는 이중 인용 부호를 사용하고, 명령문 내에서는 단일 인용 부호를 사용한다. 이 옵션을 사용하면, mysql은 그 명령문을 사용한
다음에 종료를 한다.
예를 들면, 여러분은 아래의 명령어를 가지고 사용자 계정의 리스트를 얻을 수 있을 것이다:
shell> mysql -u root -p --execute="SELECT User, Host FROM user" mysql
Enter password: ******
+------+-----------+
| User | Host |
+------+-----------+
| | gigan |
| root | gigan |
| | localhost |
| jon | localhost |
| root | localhost |

:::MySQL Korea:::
+------+-----------+
shell>
전체 이름 형태(--execute)는 등호 기호(=)가 뒤 따라 와야 한다는 점을 기억하기 바란다.
앞의 예제에서 보듯이, mysql 데이터 베이스의 이름은 별도의 인수 형태로 전달 되었다. 하지만, 동일한 명령문을 아래의 명령어
로 실행시킬 수 있는데, 여기에는 디폴트 데이터 베이스를 지정하지 않았다:
mysql> mysql -u root -p --execute="SELECT User, Host FROM mysql.user"
다중 SQL 명령문은 명령어 라인에서 세미콜론으로 구분해서 전달 될 수도 있다:
shell> mysql -u root -p -e "SELECT VERSION();SELECT NOW()"
Enter password: ******
+------------+
| VERSION() |
+------------+
| 5.0.19-log |
+------------+
+---------------------+
| NOW() |

:::MySQL Korea:::
+---------------------+
| 2006-01-05 21:19:04 |
+---------------------+
--execute 또는 -e 옵션은 또한 MySQL 클러스터에 대한 ndb_mgm 관리 클라이언트에 비슷한 형식으로 명령문을 전달할 때
사용될 수도 있다. Section 15.3.6, “안전한 셧다운과 재 시작”에서 예문을 참조하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 4.3.2. 옵션 파일 사용 하기
4. MySQL 프로그램 사용하기 대부분의 MySQL 프로그램들은 옵션 파일(때로는 구성 파일로도 불리어짐)에서 스타트업 옵션을 읽을 수 있다. 옵
4.3. 프로그램 옵션 지정하기 션 파일들은 주로 사용되는 옵션들을 지정하는데 있어서 편리한 방법을 제공하여 주는데, 따라서 여러분이 명령어 라
4.3.2 옵션 파일 사용 하기 인에서 프로그램을 구동할 때마다 입력하는 수고를 없게 준다.
프로그램이 옵션 파일을 읽을 수 있는지 없는지를 확인하기 위해서는, --help 옵션(mysqld의 경우, --verbose 및
--help for mysqld)을 함께 사용해서 프로그램을 호출한다. 만약에 프로그램이 옵션 파일을 읽을 수 있다면, 도움
말 메시지는 프로그램이 찾는 파일과 인식할 수 있는 옵션 그룹을 표시하게 된다.
Note: MySQL 클러스터 프로그램과 함께 사용되는 옵션 파일들은 Section 15.4, “MySQL 클러스터 구성”에서 설
명하기로 한다.
윈도우에서는, MySQL 프로그램은 아래의 파일들에서 스타트업 옵션들을 읽게 된다:
Filename Purpose
WINDIR￦my.ini Global options
C:￦my.cnf Global options
INSTALLDIR￦my.ini Global Options

defaults-extra-file The file specified with --defaults-extra-file=path, if any
WINDIR 는 여러분의 윈도우 디렉토리의 위치를 나타낸다. 이것은 주로 C:￦WINDOWS 또는 C:￦WINNT가 된다.
여러분은 이것의 정확한 위치를 아래의 명령문을 사용해서 WINDIR 환경 변수의 값을 가지고 알아낼 수가 있다:

:::MySQL Korea:::
INSTALLDIR 는 MySQL이 설치된 디렉토리를 가리킨다. 이것은 전형적으로 C:￦PROGRAMDIR￦MySQL

￦MySQL 5.0 Server 이며, MySQL 5.0이 설치 및 구성 마법사를 사용해서 설치될 때에는, PROGRAMDIR 는 프로
그램 디렉토리를 가리키는 것이다.(일반적으로 영문 윈도우 버전의 경우에는 Program Files). Section 2.3.4.14,
“my.ini 파일의 위치”를 참조할 것.
유닉스에서는, MySQL 프로그램은 아래의 파일들에서 스타트업 옵션을 읽게 된다:
Filename Purpose
/etc/my.cnf Global options
$MYSQL_HOME/my.cnf Server-specific options
defaults-extra-file The file specified with --defaults-extra-file=path, if any
~/.my.cnf User-specific options
MYSQL_HOME은 특정 서버 my.cnf 파일이 상주하고 있는 디렉토리에 대한 경로를 갖고 있는 환경 변수이다.

(This was DATADIR prior to MySQL version 5.0.3.)
만약에 MYSQL_HOME 이 설정되지 않고 서버를 mysqld_safe 프로그램을 통해 구동시킨다면, mysqld_safe은

MYSQL_HOME을 아래와 같이 설정하고자 할 것이다:
● BASEDIR 과 DATADIR 이 각각 MySQL 베이스 디렉토리와 데이터 디렉토리의 경로 이름을 나타내도

록 만든다.
● my.cnf 파일이 BASEDIR이 아닌 DATADIR 에 있다면, mysqld_safe은 MYSQL_HOME 을 DATADIR
에 설정한다.
● 반면에, MYSQL_HOME 이 설정되지 않고 그리고 DATADIR 안에 my.cnf 파일이 없다면, mysqld_safe
은 MYSQL_HOME을 BASEDIR에 설정한다.
전형적으로, DATADIR 는 바이너리를 설치할 경우에는 /usr/local/mysql/data 가 되고 또는 소스를 설치할 경우에

는 /usr/local/var 가 된다. 이것은 MySQL을 구성할 때 지정되는 데이터 디렉토리의 위치이며, mysqld 을 구동할 때
--datadir옵션을 가지고 지정하는 위치가 아니라는 것을 알아두기 바란다. 런타임시 –datadir를 사용하는 것은 서
버가 옵션 파일을 어디에서 찾을 것인지에 대해 아무런 영향을 주지 않는데, 왜냐하면 서버는 어떠한 옵션을 실행하
기 전에 옵션 파일들을 찾기 때문이다.

:::MySQL Korea:::
MySQL은 위에서 언급한 순서대로 옵션 파일들을 찾고 읽게 된다. 여러분이 사용하고자 하는 옵션 파일이 존재하지
않는다면, 일반적인 텍스트 편집기를 사용해서 이것을 생성한다.
주어진 옵션에서 다중의 인스턴스가 발견되면, 최종 인스턴스가 우선 순위를 갖게 된다. 한 가지 예외가 있다: mysqld
에 대해서는, --user 옵션의 첫 번째 인스턴스는 보안 목적으로 사용되기 때문에, 옵션 파일에 있는 사용자 지정 옵
션을 명령어 라인에서 지정하는 것이 앞서 실행되지 않도록 하고 있다.
Note: 유닉스 플랫폼에서는, MySQL은 모든 사람이 작성할 수 있는(world-writable) 구성 파일은 무시해 버린다.
이것은 의도적인 것으로, 보안에 관련된 정책이다.
MySQL프로그램을 구동할 때 명령어 라인에서 입력할 수 있는 옵션들은 어떤 것이든지 옵션 파일에서도 사용할 수

있다. 한 프로그램에서 사용 가능한 옵션들의 목록을 보기 위해서는, 그 프로그램을 --help 옵션과 함께 구동 시킨
다.
하나의 옵션 파일에서 옵션을 지정할 때 사용하는 신텍스는 명령어 라인에서 사용하는 신텍스와 유사한데, 옵션 앞에
사용하는 두 가지의 대쉬는 생략해야 한다. 예를 들면, 명령어 라인에서 사용되는 --quick 또는 --host=localhost
은 옵션 파일에서는 quick 또는 host=localhost 과 같이 쓰여져야 한다. --loose-opt_name 를 옵션 파일에서 지정
하기 위해서는, loose-opt_name와 같이 작성되어야 한다.
옵션 파일에서 비어 있는 라인(Empty lines)은 무시된다. 라인이 비어 있지 않다면 아래의 형태 중에 하나가 될 것이

다:
● #comment, ;comment
코멘트 라인은 ‘#’ 또는 ‘;’로 시작한다. ‘#’로 시작 되는 코멘트는 라인의 중간에서도 시작할 수
있다.
● [group]
group은 여러분이 옵션을 설정하고자 하는 그룹 또는 프로그램의 이름이다. 그룹 라인 다음에, 다른 그룹

라인이 주어지거나 옵션 파일의 끝이 나오기 전까지는 어떠한 옵션 설정 라인도 주어진 그룹에 적용할 수

:::MySQL Korea:::
있다.
● opt_name
이것은 명령어 라인에서의 --opt_name 과 동일한 것이다.
● opt_name=value
이것은 명령어 라인의 --opt_name=value 과 동일한 것이다. 옵션 파일에서는, ‘=’ 기호 앞뒤에 스페

이스를 사용할 수 있는데, 명령어 라인에서는 이렇게 사용할 수 없다. 여러분은 단일 또는 이중 인용 부호
로 값을 묶을 수도 있는데, 그 값이 ‘#’ 코맨트 문자 또는 화이트 스페이스(whitespace)를 갖고 있을
경우에 유용하게 사용할 수 있다.
숫자 값을 갖는 옵션의 경우에는, 그 값에 접미사 K, M, 또는 G (대소문자 모두 사용 가능)을 사용해서 1024, 10242

또는 10243의 승수를 표시할 수 있다. 예를 들면, 아래의 명령어는 mysqladmin에게 서버를 1024 번 만큼 PING하도
록 하는데, 각 PING간에는 10초의 간격을 두라고 명령하는 것이다:
mysql> mysqladmin --count=1K --sleep=10 ping
앞뒤에 있는 공백(blank)은 옵션 이름과 값에서 자동으로 삭제된다. 여러분은 이스케이프 시퀀스(escape

sequences)를 사용할 수도 있는데, 옵션 파일에서 ‘￦b’, ‘￦t’, ‘￦n’, ‘￦r’, ‘￦￦’, 와 ‘￦s’를 사용
해서 백스페이스( backspace),탭(tab), 새 라인(newline), 캐리지 리턴(carriage return), 그리고 스페이스 문자를
의미하도록 할 수 있다.
‘￦￦’ 이스케이프 시퀀스는 단일 백슬레쉬를 의미하기 때문에, 여러분은 각각의 ‘￦’를 ‘￦￦’로 써야 한다.
다른 방법으로는, 경로 이름 구분자로서 ‘￦’를 사용하지 않고 ‘/’를 사용할 수도 있다.
옵션 그룹의 이름이 프로그램 이름과 같다면, 그룹에 있는 옵션들은 특별히 그 프로그램에 적용되게 된다. 예를 들면,
[mysqld] 과 [mysql] 그룹은 mysqld 서버와 mysql 클라이언트 프로그램에 각각 적용된다.
[client] 옵션 그룹은 모든 클라이언트 프로그램이 읽을 수 있다(mysqld은 읽을 수 없음). 이것은 여러분이 모든 클라

이언트에 적용되는 옵션을 지정할 수 있게 해 준다. 예를 들면, [client]는 여러분이 서버에 접속할 때 사용하는 패스

:::MySQL Korea:::
워드를 지정할 때 사용할 수 있는 완벽한 그룹이다. (하지만 그 옵션 파일이 여러분만 읽고 쓸 수 있도록 해야 하며, 따
라서 다른 사람들이 패스워드를 알지 못하도록 해야 한다.) 어떤 옵션 하나를 여러분이 사용하는 모든 클라이언트 프
로그램이 인식하지 못할 경우에는 [client] 그룹에 그 옵션을 넣지 않도록 한다. 여러분이 프로그램을 구동시키고자
한다면, 프로그램은 이 옵션을 인식하지 못하게 되며 에러 메시지를 보여 주면서 동작을 멈추게 된다.
여기에 전형적인 글로벌 옵션 파일이 있다:
[client]
port=3306
socket=/tmp/mysql.sock
[mysqld]
port=3306
key_buffer_size=16M
max_allowed_packet=8M
[mysqldump]
quick
앞의 옵션 파일은 key_buffer_size 과 max_allowed_packet 변수를 설정하는 라인을 위해 var_name=value 신텍스

를 사용하고 있다.

:::MySQL Korea:::
여기에 전형적인 옵션 파일이 있다:
[client]
# The following password will be sent to all standard MySQL clients
password="my_password"
[mysql]
no-auto-rehash
connect_timeout=2
[mysqlhotcopy]
interactive-timeout
특정 MySQL릴리그 시리즈에 속한 mysqld 서버만 읽을 수 있는 옵션 그룹을 생성하고자 한다면, 여러분은 이것을

[mysqld-4.1], [mysqld-5.0]와 같은 이름을 가진 그룹을 사용해서 만들 수가 있다. 아래의 그룹은 --new 옵션
이 5.0.x 버전 번호를 가진 MySQL 서버에 의해서만 사용되도록 지시한다:
[mysqld-5.0]
new
MySQL 5.0.4 이후에는, 옵션 파일에 !include 지시문(directives)을 사용해서 다른 옵션 파일을 포함하도록 지시할
수 있게 되었고 !includedir를 사용해서 옵션 파일에 대한 특정 디렉토리를 검색하도록 할 수 있다. 예를 들면, /home/

:::MySQL Korea:::
mydir/myopt.cnf 파일을 포함하기 위해서는, 여러분은 아래의 지시문을 사용할 수 있다:
!include /home/me/myopt.cnf
/home/mydir 디렉토리를 검색하고 그곳에서 찾게 되는 옵션 파일들을 읽기 위해서는, 아래의 지시문을 사용한다:
!includedir /home/mydir
Note: 현재의 버전까지는, 유닉스 시스템에서 !includedir 지시문을 사용해서 검색되고 포함 되어지는 파일들은 반드
시 파일 이름 끝에 .cnf가 있어야 한다. 윈도우에서는, 이러한 지시문은 .ini 또는 .cnf 확장자로 끝나는 파일을 검사한
다.
포함되어진 파일에서 읽혀진 옵션들은 현재(current) 옵션 그룹의 문장에서 적용된다는 점을 알아두기 바란다. 여러
분이 아래의 라인을 my.cnf 안에 써 놓았다고 가정하자:
[mysqld]
!include /home/mydir/myopt.cnf
이 경우에, myopt.cnf <span style="FONT-SIZE: 10pt

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 4.3.3. 환경 변수를 사용해서 옵션 지정 하기
4. MySQL 프로그램 사용하기 환경 변수를 사용해서 옵션을 지정하기 위해서는, 여러분이 사용하는 명령어 프로세서에 적당한 신텍스를 사용해서 변수를 설정한
4.3. 프로그램 옵션 지정하기 다. 예를 들면, 윈도우 또는 넷웨어(NetWare)에서는, USER 변수를 설정해서 MySQL 계정 이름을 지정하도록 한다. 이렇게 하기
4.3.3 환경 변수를 사용해서 옵션 지정 하기 위해서, 아래의 신텍스를 사용한다:
SET USER=your_name
유닉스에서의 신텍스는 여러분이 사용하는 쉘에 관련이 된다. 여러분이 TCP/IP 포트 번호를 MYSQL_TCP_PORT 변수를 사용해
서 지정하고자 한다고 가정한다. 전형적인 신텍스는(sh, bash, zsh의 경우) 다음과 같다:
MYSQL_TCP_PORT=3306
export MYSQL_TCP_PORT
첫 번째 명령어는 변수를 설정하고, 그리고 export 명령어는 그 변수를 쉘 환경 변수로 보내어서 이 값을 MySQL과 다른 프로세스
들이 사용할 수 있도록 만든다.
csh 와 tcsh의 경우에는, setenv를 사용해서 쉘 변수를 환경에 맞게 만들게 된다:
setenv MYSQL_TCP_PORT 3306
환경 변수를 설정하는 명령어는 명령어 라인에서 실행 시켜서 즉시 효과를 나타내도록 할 수 있으나, 하지만 설정은 여러분이 로그
아웃을 하지 않은 상태에서만 유지된다. 여러분이 로그인 할 때마다 효과를 갖기 위해서는, 적당한 명령어 또는 명령어들을 스타트
업 파일에 적어 놓아서 명령어 해석기가 매 서버 시작 때마다 읽을 수 있도록 하면 된다. 전형적인 스타트업 파일들은 윈도우에서
는 AUTOEXEC.BAT 이며, for bash에서는 .bash_profile, 또는 tcsh에 대해서는 .tcshrc 가 된다. 보다 상세한 사항은 명령어 해
석기 매뉴얼을 참조하기 바란다.

:::MySQL Korea:::
Appendix F, Environment Variables에서는 MySQL프로그램 작동에 영향을 미치는 모든 환경 변수를 열거하고 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 4.3.4. 옵션을 사용해서 프로그램 변수 설정하기
4. MySQL 프로그램 사용하기 많은 MySQL 프로그램들이 런타임 때 설정할 수 있는 내부 변수들을 가지고 있다. 프로그램 변수들은 전체 이름 옵션들에 값을 설
4.3. 프로그램 옵션 지정하기 정하는 것과 같은 방식으로 설정된다. 예를 들면, mysql은 max_allowed_packet 라는 변수를 가지고 있는데, 이 변수는 통신 버퍼
4.3.4 옵션을 사용해서 프로그램 변수 설정하기 의 최대 크기를 제어한다. max_allowed_packet 변수를 16MB로 설정하기 위해서는, 아래의 명령어 중에 하나를 사용한다:
shell> mysql --max_allowed_packet=16777216
shell> mysql --max_allowed_packet=16M
첫 번째 명령어는 그 값을 바이트로 지정했다. 두 번째 명령어는 메가 바이트로 지정을 했다. 숫자 값을 가지는 변수에 대해서는, 접
미사 K, M, 또는 G (대소 문자 상관 없음)를 사용해서 1024, 10242 or 10243의 승수를 표시할 수 있다.(예를 들면,
max_allowed_packet를 설정하기 위해 사용될 때, 접미사는 킬로 바이트, 메가 바이트, 또는 기가 바이트를 나타낸다.)
옵션 파일에서, 변수 설정은 대쉬를 앞에 두지 않는다:
[mysql]
max_allowed_packet=16777216
또는:
[mysql]
max_allowed_packet=16M
아래의 옵션 그룹들은 모두 동일한 것들이다. 양쪽 모두 서버의 키 버퍼를 512MB로 설정한다:

:::MySQL Korea:::
[mysqld]
key_buffer_size=512M
[mysqld]
key-buffer-size=512M
Note: MySQL 4.0.2 이전에는, 프로그램 변수를 설정할 수 있는 유일한 신텍스는 --set-variable=option=value (또는 옵션 파
일에서는, set-variable=option=value)밖에 없었다. 이 신텍스는 여전히 사용 가능하지만, 4.0.2 이후에는 그다지 사용되지 않는
다.
많은 서버 시스템 변수들도 역시 런타임시에 설정을 할 수가 있다. 자세한 사항은, Section 5.2.3.2, “동적 시스템 변수들”을 참
조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 5. 데이터 베이스 관리

5.1. 서버 측면의 프로그램 소개
5. 데이터 베이스 관리 5.2. mysqld — MySQL 서버
5 데이터 베이스 관리 5.2.1. mysqld 명령어 옵션
5.1 서버 측면의 프로그램들 소개 5.2.2. 서버 시스템 변수
5.2 mysqld — MySQL 서버 5.2.3. 시스템 변수 사용하기

5.2.4. 서버 상태(status) 변수
5.2.1 mysqld 명령어 옵션
5.2.5. 서버 SQL 모드
5.2.2 서버 시스템 변수
5.2.6. MySQL 서버 셧다운 프로세스
5.2.3 시스템 변수 사용하기
5.3. mysqld-max 확장 MySQL 서버
5.2.3.1 구조(structured) 시스템 변수
5.4. MySQL 서버 스타트업 프로그램
5.2.3.2 동적(dynamic) 시스템 변수
5.4.1. mysqld_safe — MySQL 서버 스타트업 스크립트
5.2.4 서버 상태 변수
5.4.2. mysql.server — MySQL 서버 스타트업 스크립트
5.2.5 서버 SQL 모드
5.4.3. mysqld_multi — 다중 MySQL 서버 관리
5.2.6 MySQL 서버 셧다운 프로세스 5.5. mysqlmanager — MySQL 인스턴스 관리자
5.3 mysqld-max 확장 MySQL 서버 5.5.1. MySQL인스턴스 관리자를 사용해서 MySQL서버 시작하기
5.4 MySQL 서버 스타트업 프로그램 5.5.3. MySQL 인스턴스 관리자 명령어 옵션
5.4.1 mysqld_safe — MySQL 서버 스타트업 스크립트 5.5.4. MySQL 인스턴스 관리자 구성 파일
5.4.2 mysql.server — MySQL 서버 스타트업 스크립트 5.5.5. MySQL 인스턴스 관리자가 인식하는 명령어
5.4.3 mysqld_multi — 다중 MySQL 서버 관리 5.6. 설치 관련 프로그램
5.5 mysqlmanager — MySQL 인스턴스 관리자 5.6.1. mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이
5.5.1 MySQL 인스턴스 관리자를 가지고 MySQL 서버 구동하기 드
5.5.2 MySQL 인스턴스 관리자에 접속하기와 사용자 계정 생성하기 5.6.2. mysql_upgrade — MySQL 업그레이드를 위한 테이블 체크
5.7. 일반적인 보안 문제
5.5.2.1 인스턴스 관리자 사용자 및 패스워드
5.7.1. 일반적인 보안 가이드 라인
5.5.2.2 상태 모니터를 위한 MySQL 서버 계정
5.7.2. 보안 공격으로부터 MySQL 보안 설정하기

:::MySQL Korea:::
5.5.3 MySQL 인스턴스 관리자 명령어 옵션 5.7.3. 보안 관련 mysqld 옵션들
5.5.4 MySQL 인스턴스 관리자 구성 파일 5.7.4. LOAD DATA LOCAL 에서의 보안 문제들
5.5.5 MySQL 인스턴스 관리자가 인식하는 명령어 5.7.5. How to Run MySQL as a Normal User
5.8. MySQL 접근 권한 시스템
5.6 설치-관련 프로그램
5.8.1. 권한 시스템이 하는 일
5.6.1 mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드
5.8.2. 권한 시스템의 동작 방식
5.6.2 mysql_upgrade — MySQL 업그레이드를 위한 테이블 검사
5.8.3. MySQL이 제공하는 권한
5.7 일반적인 보안 이슈
5.8.4. MySQL서버에 접속하기
5.7.1 일반적인 보안 가이드 라인
5.8.5. 접근 제어, Stage 1: 접속 검증
5.7.2 공격으로부터 MySQL 보안 설정하기
5.8.6. 접근 제어, Stage 2: 요청 검증
5.7.3 보안-관련 mysqld 옵션
5.8.7. 권한 변경이 효력을 나타내는 시점
5.7.4 LOAD DATA LOCAL가 가지고 있는 보안 이슈 5.8.8. Access denied 에러의 원인
5.7.5 일반 사용자 자격으로 MySQL 구동시키는 방법 5.8.9. MySQL 4.1 이후의 패스워드 해싱(Hashing)
5.8 MySQL 권한 시스템 5.9. MySQL 사용자 계정 관리
5.8.1 권한 시스템이 하는 일 5.9.1. MySQL 사용자 이름과 패스워드
5.8.2 권한 시스템은 어떻게 동작하는가 5.9.2. MySQL에 새로운 사용자 계정 추가하기
5.8.3 MySQL이 제공하는 권한 5.9.3. MySQL에서 사용자 계정 삭제하기
5.8.4 MySQL 서버에 접속하기 5.9.4. 계정 자원 제한하기

5.9.5. 계정 패스워드 할당하기
5.8.5 접근 제어, Stage 1: 접속 검증
5.9.6. 패스워드 보안 유지 하기
5.8.6 접근 제어, Stage 2: 요청 검증
5.9.7. 보안 접속 사용하기
5.8.7 권한 변경시의 효과
5.10. 백업과 복구
5.8.8 접근 거부 에러의 원인
5.10.1. 데이터 베이스 백업
5.8.9 MySQL 4.1 이후의 패스워드 해싱
5.10.2. 백업과 복구 전략 예제
5.9 MySQL 사용자 계정 관리
5.10.3. 시점(Point-in-Time) 복구
5.9.1 MySQL 사용자 이름과 패스워드
5.10.4. 테이블 관리와 크래시 복구
5.9.2 MySQL에 새로운 사용자 계정 추가하기 5.11. MySQL 지역화(Localization)와 국제적인 사용
5.9.3 MySQL에서 사용자 계정 제거하기 5.11.1. 데이터와 정렬을 위해 사용되는 문자 셋
5.9.4 계정 자원 제한하기 5.11.2. 에러 메시지 언어 설정하기
5.9.5 계정 패스워드 할당하기 5.11.3. 새로운 문자 셋 추가하기
5.11.4. 문자 정의 배열

:::MySQL Korea:::
5.9.6 패스워드 보안 유지하기 5.11.5. 스트링 콜레션(Collating) 지원

5.9.7 보안 접속 사용하기 5.11.6. 다중-바이트 문자 지원
5.9.7.1 기본적인 SSL 개념 5.11.7. 문자 셋의 문제점
5.9.7.2 OpenSSL을 사용해서 SSL 접속하기 5.11.8. MySQL 서버 타임 존 지원
5.9.7.3 yaSSL을 사용해서 SSL 접속하기 5.12. MySQL 서버 로그

5.12.1. 에러 로그
5.9.7.4 MySQL을 위한 SSL 인증 설정 하기
5.12.2. 일반적인 쿼리 로그
5.9.7.5 SSL 명령어 옵션
5.12.3. 바이너리 로그
5.9.7.6 SSH를 사용해서 윈도우에서 원경으로 MySQL 접속하기
5.12.4. 슬로우 쿼리 로그
5.10 백업 및 복구
5.12.5. 서버 로그 관리
5.10.1 데이터 베이스 백업
5.13. 동일 머신에서 다중 MySQL 서버 구동하기
5.10.2 백업 및 복구 전략 예제
5.13.1. 윈도우에서 다중 서버 구동하기
5.10.3 시점(Point-in-Time) 복구
5.13.2. 유닉스에서 다중 서버 구동하기
5.10.3.1 복구 시간 지정하기 5.13.3. 다중-서버 환경에서 클라이언트 프로그램 사용하기
5.10.3.2 복구 위치 지정하기 5.14. MySQL 쿼리 캐시
5.10.4 테이블 관리와 크래시(Crash) 복구 5.14.1. 쿼리 캐시를 동작시키는 방법
5.10.4.1 크래시 복구를 위해 myisamchk 사용하기 5.14.2. 쿼리 캐시 SELECT 옵션
5.10.4.2 에러에 대해 MyISAM 테이블을 검사하는 방법 5.14.3. 쿼리 캐시 구성
5.10.4.3 테이블 치료하는 방법 5.14.4. 쿼리 캐시 상태와 관리
5.10.4.4 테이블 최적화 이 장에서는 MySQL 설치를 관리하는 사항들에 대해 설명하기로 한다:
5.10.4.5 테이블 정보 가져오기

● 서버 구성
5.10.4.6 테이블 관리(Maintenance) 스케줄 설정
● 사용자 계정 관리
5.11 MySQL 지역화(Localization)와 국제적인 사용
● 백업 실행
5.11.1 데이터와 정렬을 위한 문자 셋
● 서버 로그 파일
5.11.2 에러 메시지 언어 설정
● 쿼리 캐시
5.11.3 새로운 문자 셋 추가
5.11.4 문자 정의 배열
5.11.5 스트링 콜레팅(collating)지원
5.11.6 다중-바이트 문자 지원

:::MySQL Korea:::
5.11.7 문자 셋 문제
5.11.8 MySQL 서버 타임존 지원
5.12 MySQL 서버 로그
5.12.1 에러 로그
5.13.1.2 서비스 형태로 여러 개의 윈도우 서버 시작하기
5.12.2 일반적인 쿼리 로그
5.12.3 바이너리 로그
5.12.4 슬로우 쿼리 로그
5.12.5 서버 로그 관리
5.13 동일 머신에서 여러 대의 MySQL 서버 구동 시키기
5.13.1.1 명령어 라인에서 여러 개의 윈도우 서버 구동하기
5.13.2 유닉스에서 여러 개의 서버 구동하기
5.13.3 다중-서버 환경에서 클라이언트 프로그램 사용하기
5.14 MySQL 쿼리 캐시
5.14.1 쿼리 캐시를 동작 시키는 방법
5.14.2 쿼리 캐시 SELECT 옵션
5.14.3 쿼리 캐시 구성
5.14.4 쿼리 캐시 상태 및 관리

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.1. 서버 측면의 프로그램들 소개

MySQL 서버, mysqld은 MySQL를 설치하는 과정에서 동작하는 메인 프로그램이다. 이 프로그램은 여러분이 MySQL을 설치할
5. 데이터 베이스 관리 때 셋업을 수행하는 여러 기능들 또는 서버를 구동하고 종료하는데 도움을 주는 여러 가지 관련 스크립트들로 구성된다. 이 섹션에
5.1. 서버 측면의 프로그램들 소개 서는 서버와 이에 관련된 프로그램들을 소개하기로 한다. 이 다음의 섹션에서는 이러한 프로그램들에 대해 개별적으로 보다 자세
5.1 서버 측면의 프로그램들 소개 한 설명을 하기로 하겠다.
각 MySQL 프로그램은 서로 다른 옵션들을 많이 가지고 있다. 대부분의 프로그램들은 --help 옵션을 제공하는데, 여러분은 이것
을 사용해서 각 프로그램의 서로 다른 옵션들에 대한 정보를 얻을 수 있게 된다. 예를 들어서, mysqld –help를 실행해 보자.
여러분은 명령어 라인 또는 옵션 파일에 옵션을 지정해 줌으로서 MySQL 프로그램에 대한 디폴트 옵션 값을 변경시킬 수가 있다.
Section 4.3, “프로그램 옵션 지정하기”를 참조할 것.
아래에서는 MySQL서버와 서버 관련 프로그램들에 대해 간략히 설명을 하고 있다:
● mysqld
SQL 데몬 (즉, MySQL 서버). 클라이언트 프로그램을 사용하기 위해서는, mysqld을 반드시 구동 시켜야 하는데, 왜냐하
면 클라이언트는 서버 접속을 통해서 데이터 베이스에 접근할 수 있기 때문이다. Section 5.2, “mysqld — MySQL 서
버”를 참조.
● mysqld-max
부가적인 기능을 포함하고 있는 서버 버전. Section 5.3, “The mysqld-max 확장된 MySQL 서버”를 참조.
● mysqld_safe
서버 스타트업 스크립트. mysqld_safe는 mysqld-max가 있다면 이것을 구동 시킨다. 그것이 없으면, mysqld를 구동시
킨다. Section 5.4.1, “mysqld_safe — MySQL 서버 스타트업 스크립트”를 참조.
● mysql.server

:::MySQL Korea:::
서버 스타트업 스크립트. 이 스크립트는 시스템 V계열 구동 디렉토리를 사용하는 시스템에서 사용되어지는데, 이 구동 디

렉토리는 특정 구동 레벨에 대한 시스템 서비스를 구동 시키는 스크립트들이 포함되어 있다. 이 스크립트는 mysqld_safe
를 호출하여 MySQL 서버를 구동 시킨다. Section 5.4.2, “mysql.server — MySQL 서버 스타트업 스크립트”를 참조
할 것.
● mysqld_multi
시스템에 설치되어 있는 다중 서버들을 구동 시키고 종료 시키는 서버 스타트업 스크립트. Section 5.4.3,

“mysqld_multi — 다중 MySQL 서법 관리”를 참조할 것. MySQL 5.0.3 (유닉스 관련 시스템) or 5.0.13 (윈도우)까
지는, mysqld_multi에 대한 다른 대안으로, MySQL 인스턴스 관리자인 mysqlmanager를 사용한다. Section 5.5,
“mysqlmanager — MySQL 인스턴스 관리자”를 참조할 것.
● mysql_install_db
이 스크립트는 MySQL 데이터베이스를 생성하고 디폴트 권한을 가진 그랜트 테이블을 초기화 시킨다. 이것은 일반적으
로 오직 한번만 실행되는데, 최초 에 시스템에 MySQL을 설치할 때 실행된다. Section 2.9.2, “유닉스 설치후 처리 과
정”을 참조할 것.
● mysql_fix_privilege_tables
이 프로그램은 MySQL을 업그레이드한 다음에 사용된다. 이것은 MySQL의 새로운 버전에서 변경된 사항들을 그랜트 테
이블에 적용시킨다. Section 5.6.1, “mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드”를 참조할
것.
Note: MySQL 5.0.19 버전 이후로는, 이 프로그램은 mysql_upgrade로 대체되었다.
● mysql_upgrade
이 프로그램은 MySQL을 업그레이드한 이후에 사용된다. 이것은 테이블의 비호환성에 대해 검사를 하고 필요하면 수정
을 하며, 새로운 MySQL버전에서 변경된 사항들을 그랜트 테이블에 적용 시킨다. Section 5.6.2, “mysql_upgrade —
MySQL 업그레이드에 대한 테이블 검사”를 참조할 것.

:::MySQL Korea:::
● mysqlmanager
MySQL서버를 모니터하고 관리하기 위한. Section 5.5, “mysqlmanager — MySQL 인스턴스 관리자”를 참조할 것.
위의 것들 이외에도 서버 호스트에서 구동되는 다른 프로그램들이 여러 개가 있다:
● make_binary_distribution
이 프로그램은 컴파일된 MySQL의 바이너리 릴리즈를 만든다. 이것은 FTP에 의해 다른 MySQL사용자의 편의를 위해
ftp.mysql.com 에 있는 /pub/mysql/upload/ 로 보내진다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.2. mysqld — MySQL 서버

5.2.1. mysqld Command Options
5. 데이터 베이스 관리 5.2.2. Server System Variables
5.2. mysqld — MySQL 서버 5.2.3. Using System Variables
5.2 mysqld — MySQL 서버 5.2.4. Server Status Variables
5.2.1 mysqld 명령어 옵션 5.2.5. The Server SQL Mode
5.2.2 서버 시스템 변수 5.2.6. The MySQL Server Shutdown Process
5.2.3 시스템 변수 사용하기 mysqld 은 MySQL 서버다. 아래의 내용은 이 MySQL서버 구성에 대한 주제를 다루는 것이
다:
● 서버가 지원하는 스타트업 옵션
● 서버 시스템 변수
● 서버 상태 변수
5.2.6 MySQL 서버 셧다운 프로세스
● 서버 SQL모드 설정 방법
● 서버 셧다운 과정
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.2.1. mysqld 명령어 옵션
5. 데이터 베이스 관리 mysqld 서버를 시작할 때, 여러분은 Section 4.3, “프로그램 옵션 지정하기”에서 설명하는 방법으로 프로그램 옵션을 지정할
5.2. mysqld — MySQL 서버 수 있다. 가장 일반적인 방법은 옵션 파일 또는 명령어 라인에서 옵션을 제공하는 것이다. 하지만, 대부분의 경우에는 서버가 매번
5.2.1 mysqld 명령어 옵션 실행할 때마다 동일한 옵션을 사용하도록 해 주는 것이 가장 바람직한 방법이다. 이렇게 동작하도록 하는 최선의 방법은 옵션 파일
에 옵션을 작성하는 것이다. Section 4.3.2, “옵션 파일 사용하기”를 참조할 것.
Mysqld은 [mysqld] 과 [server] 그룹에서 옵션을 읽는다. mysqld_safe 은 [mysqld], [server], [mysqld_safe], 및
[safe_mysqld] 그룹에서 옵션을 읽는다. mysql.server는 [mysqld] 과 [mysql.server] 그룹에서 옵션을 읽는다.
임베디드 MySQL 서버는 일반적으로 [server], [embedded], 그리고 [xxxxx_SERVER] 그룹에서 옵션을 읽는데, 여기에서
xxxxx는 서버가 임베디드되는 어플리케이션의 이름이다.
Mysqld는 많은 수의 옵션을 사용한다. 간략한 리스트를 보고자 하면, mysqld –help를 실행한다. 전체 리스트를 보고자 하면,
mysqld --verbose –help를 사용한다.
아래의 리스트는 가장 일반적인 서버 옵션을 보여주는 것이다. 추가적인 옵션들에 대해서는 나중에 설명하기로 한다:
● 보안에 영향을 주는 옵션들: Section 5.7.3, “보안 관련 mysqld 옵션”.

● SSL-관련 옵션들: Section 5.9.7.5, “SSL 명령어 옵션”.
● 바이너리 로그 제어 옵션들: Section 5.12.3, “바이너리 로그”.
● 리플리케이션 관련 옵션들: Section 6.8, “리플리케이션 스타트업 옵션”.
● 특정 스토리지 엔진에 관련되는 옵션들:Section 14.1.1, “MyISAM 스타트업 옵션”, Section 14.5.3, “BDB 스타트업
옵션”, Section 14.2.4, “InnoDB 스타트업 옵션과 시스템 변수”, 그리고 Section 15.5.5.1, “mysqld 에 대한
MySQL 클러스터 관련 옵션”.
여러분은 다음 섹션에서 설명하는 방법을 사용해서, 변수 이름을 옵션처럼 사용해서 서버 시스템 변수의 값을 설정할 수도 있다.

:::MySQL Korea:::
● --help, -?
간략한 도움말을 출력하고 종료한다. --verbose 와 --help 를 모두 사용해서 전체 도움말을 볼 수도 있다.
● --allow-suspicious-udfs
이 옵션은 메인 함수에 대해 xxx symbol만을 갖고 있는 사용자 지정 함수를 로드할 것인지를 제어한다. 디폴트로는, 이
옵션은 오프(off)이며 최소 한 개의 보조 심볼을 갖고 있는 UDF만 로드할 수 있다; 이것은 규칙에 맞게 작성된 UDF가 아
닌 다른 공유 오브젝트 파일에서 함수를 로드하려는 시도를 하지 못하도록 한다. 이 옵션은 5.0.3에서 추가되었다.
Section 24.2.4.6, “사용자 정의 함수 보안에 대한 사전 해결책”.
● --ansi
MySQL 신텍스 대신에 표준(ANSI) SQL 신텍스를 사용한다. SQL모드에 대해 보다 정확한 제어를 하기 위해서는, --
sql-mode 를 대신 사용한다. Section 1.9.3, “ANSI 모드에서 MySQL구동 시키기”, 및 Section 5.2.5, “서버
SQL 모드”를 참조할 것.
● --basedir=path, -b path
MySQL 설치 디렉토리에 대한 경로. 모든 경로는 일반적으로 이 경로에 관련되어 있다.
● --bind-address=IP
연결하고자 하는 IP 주소.
● --bootstrap
이 옵션은 전체 MySQL서버를 구동시키지 않는 MySQL 권한 테이블을 생성하기 위해 mysql_install_db 이 사용한다.
● --character-sets-dir=path

:::MySQL Korea:::
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이터와 정렬을 위해사용되는 문자 셋”.
● --character-set-client-handshake
클라이언트가 보내는 문자 셋 정보를 무시하지 말도록 함. 클라이언트의 정보를 무시하고 디폴트 서버 문자셋을 사용하기
위해서는, --skip-character-set-client-handshake를 사용한다; 이것은 MySQL이 4.0 처럼 행동하도록 만든다.
● --character-set-filesystem=charset_name
파일 시스템 문자 셋. 이 옵션은 character_set_filesystem 시스템 변수를 설정한다. MySQL 5.0.19에서 추가되었다.
● --character-set-server=charset_name, -C charset_name
charset_name을 디폴트 서버 문자 셋으로 사용한다. Section 5.11.1, “데이터와 정렬을 위해 사용되는 문자 셋”을 참
조.
● --chroot=path
Put the mysqld server in a closed environment during startup by using chroot() 시스템 호출을 사용하는 동안
mysqld 서버를 페쇄적인 상황으로만들어 둔다. 이것은 보안 문제 관점에서 추천된다. 이 옵션의 사용은 LOAD DATA
INFILE 과 SELECT ... INTO OUTFILE을 다소 제한한다는 점을 알아두기 바란다.
● --collation-server=collation_name
collation_name를 디폴트 서버 콜레션(collation)으로 사용한다. Section 5.11.1, “데이터와 정렬을 위해 사용되는 문

자셋”을 참조.
● --console
(윈도우만 해당됨.) --log-error가 지정되어 있다고 하더라도, 에러 로그 메시지를 stderr 과 stdout에 작성한다.
mysqld은 이 옵션이 사용되면 콘솔을 닫지 않는다.

:::MySQL Korea:::
● --core-file
Mysqld이 멈추면 코어 파일을 작성한다. 어떤 시스템에서는, mysqld_safe 에 대해 --core-file-size 옵션을 반드시

지정해야 한다. Section 5.4.1, “mysqld_safe — MySQL 서버 스타트업 스크립트”를 참조. 어떤 시스템에서는, 솔라이
스와 같은 시스템의 경우, 여러분이 --user 옵션을 함께 사용한다면 코어 파일을 얻을 수 없다는 점을 알아 두기 바란다.
● --datadir=path, -h path
데이터 디렉토리에 대한 경로.
● --debug[=debug_options], -# [debug_options]
MySQL이 --with-debug와 함께 구성된다면, 이 옵션을 사용해서 mysqld 이 실행하고 있는 사항에 대한 추적 파일을

작성할 수 있게 된다. debug_options 스트링 옵션은 'd:t:o,file_name'이다. 디폴트는 'd:t:i:o,mysqld.trace'이다.
Section E.1.2, “추적 파일 생성하기”를 참조.
● --default-character-set=charset_name (DEPRECATED)
charset_name 를 디폴트 문자 셋으로 사용한다. 이 옵션은 --character-set-server을 통해 무시될 수 있다.

Section 5.11.1, “데이터와 정렬을 위해 사용되는 문자셋”을 참조할 것.
● --default-collation=collation_name
collation_name 를 디폴트 콜레션(collation)으로 사용한다. 이 옵션은 --collation-server으로 무시된다.

Section 5.11.1, “데이터와 정렬을 위해 사용되는 문자셋”을 참조할 것.
● --default-storage-engine=type
테이블을 위한 디폴트 스토리지 엔진(테이블 타입)을 설정한다. Chapter 14, 스토리지 엔진과 테이블 타입 을 참조할
것.
● --default-table-type=type

:::MySQL Korea:::
이 옵션은 --default-storage-engine과 같다.
● --default-time-zone=timezone
디폴트 서버 타임존을 설정한다. 이 옵션은 글로벌 time_zone 시스템 변수를 설정한다. 이 옵션이 주어지지 않으면, 디폴
트 타임존은 시스템 타임존과 같게 된다(system_time_zone 시스템 변수가 설정된 값).
● --delay-key-write[= OFF | ON | ALL]
키 쓰기 지연(delay)을 사용하는 방법을 지정한다. 지연된 키 쓰기는 키 버퍼가 MyISAM 테이블을 작성하는 동안에 넘치
지 않게 한다. OFF는 키 쓰기 지연을 비활성화 시킨다. ON은 DELAY_KEY_WRITE 옵션을 가지고 생성되는 태이블들
에 대한 지연 키 쓰기를 활성화 시킨다. ALL은 모든 MyISAM 테이블에 대한 작성을 지연 시킨다. Section 7.5.2, “서
버 파라미터 튜닝하기”, 및Section 14.1.1, “MyISAM 스타트 업 옵션”을 참조할 것.
Note: 이 변수를 ALL로 설정하면, MyISAM 테이블이 사용될 때 다른 프로그램(다른 MySQL 서버 또는 myisamchk)안
에서는 이 테이블을 사용할 수 없게 된다.
● --des-key-file=file_name
이 파일로부터 디폴트 DES 키를 읽어 온다. 이러한 키들은 DES_ENCRYPT() 과 DES_DECRYPT() 함수가 사용한다.
● --enable-named-pipe
네임드 파이프에 대한 지원을 가능하게 한다. 이 옵션은 Windows NT, 2000, XP, and 2003 시스템에만 적용되며, 또한
네임드 파이프 접속을 지원하는 mysqld-nt 와 mysqld-max-nt 서버와 함께만 사용될 수 있다.
● --exit-info[=flags], -T [flags]
이것은 mysqld 서버를 디버깅 하기 위해 사용하는 다른 플래그의 비트마스크(bit mask) 이다. 이 옵션이 무슨 일을 하는
지 정확히 알지 못한다면 사용하지 말기 바란다!
● --external-locking

:::MySQL Korea:::
외부 잠금(시스템 잠금)을 활성화 시키는데, 이것은 4.0 이후에는 디폴트로비활성화 된다. lockd가 완전하게 동작하지 않
는 시스템(리눅스와 같은 시스템)에서 이 옵션을 사용한다면, mysqld이 데드락(deadlock) 되기 쉽다는 점을 알아두기 바
란다. 이 옵션은 이전에는 --enable-locking라고 불리었다.
Note: 많은 MySQL 처리 과정에서 MyISAM 테이블을 업데이트 할 수 있도록하기 위해 이 옵션을 사용하고자 한다면,
아래의 조건이 만족하는지 먼저 확인해야 한다:
<li class="MsoNormal"style="MARGIN: 0cm 0cm 0pt; WORD-BREAK: keep-all;

TEXT-AUTOSPACE: ideograph-numeric; TEXT-ALIGN: left; mso-pagination:
widow-orphan; mso-margin

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.2.2. 서버 시스템 변수
5. 데이터 베이스 관리 mysql 서버는 서버가 어떻게 구성되었는지를 가리키는 많은 시스템 변수들을 유지 관리 한다. 각 시스템 변수는 디폴트 값을 가지고 있다. 시스템 변수들
5.2. mysqld — 은 명령어 라인 또는 옵션 파일에서 옵션을 사용하여 서버 스타트 업때에 설정될 수 있다. 대부분의 것들은 서버가 구동되고 있는 동안에 SET 명령문을 가
MySQL 서버 지고 동적으로 변경할 수 있는데, 이 명령문은 서버를 종료하고 재 구동 시키지 않는 상태에서 서버의 동작을 수정할 수 있다. 여러분은 수식 안에 시스템 변
5.2.2 서버 시스템 변수 수를 사용할 수 있다.
시스템 변수의 이름과 값을 볼 수 있는 방법은 여러 가지가 있다:
● 서버가 읽는 디폴트 및 옵션 파일 컴파일에서 서버가 사용하게 될 변수의 값을 보기 위해서는, 아래의 명령어를 사용한다:
• mysqld --verbose --help
● 다른 옵션 파일에 있는 설정 값은 무시하고, 서버의 디폴트 컴파일에서 서버가 사용하게 될 변수의 값을 보기 위해서는, 아래의 명령어를 사용한다:
• mysqld --no-defaults --verbose --help
● 구동 중에 있는 서버가 사용하는 현재의 값을 보기 위해서는, SHOW VARIABLES 명령문을 사용한다.
이 섹션은 각 시스템 변수에 대한 상세 설명을 제공한다. 버전 번호가 없는 변수들은 모든 MySQL 5.0 릴리즈에 존재하는 것임을 의미한다. 이러한 변수들
의 구현에 관련된 이전의 정보들에 대해서는 MySQL 3.23, 4.0, 4.1 Reference Manual을 참조하기 바란다.
부가적인 시스템 변수 정보에 대해서는, 아래의 섹션을 참고하기 바란다:
● Section 5.2.3, “Using System Variables”에서는, 시스템 변수 값을 설정하고 화면에 보여주는 신텍스를 설명한다.
● Section 5.2.3.2, “Dynamic System Variables”에서는, 런타임시에 설정할 수 있는 변수들을 보여 준다.
● 시스템 변수 튜닝에 대한 정보는 Section 7.5.2, “Tuning Server Parameters”에서 찾을 수 있다.

:::MySQL Korea:::
● Section 14.2.4, “InnoDB Startup Options and System Variables”에서는, InnoDB 시스템 변수를 열거한다.
Note: 아래의 변수 설명문 중에 어떤 것들은 변수를 “enabling” 또는 “disabling” 하는 것에 대해 언급하고 있다. 이러한 변수들은 SET 명령문을 사용
해서 그 값을 ON 또는 1로 설정해서 활성화 시킬 수 있으며, 또는 OFF 또는 0으로 설정해서 비활성화 시킬 수가 있다. 하지만, 이러한 변수들을 명령어 라
인 또는 옵션 파일에서 설정하기 위해서는, 이것들은 반드시 1 또는 0으로 설정 되어야 한다; ON 또는 OFF로 설정하면 구동이 되지 않는다. 예를 들면, 명
령어 라인에서, --delay_key_write=1는 잘 구동되지만, --delay_key_write=ON 는 실행되지 않는다.
버퍼 크기, 길이, 그리고 스택의 크기에 대한 값은 별도로 지정되지 않으면 바이트 단위로 주어진다.
● auto_increment_increment
auto_increment_increment 및 auto_increment_offset는 마스터와 마스터간의 리플리케이션을 위한 용도로 사용되며, 또한

AUTO_INCREMENT 컬럼의 동작을 제어하기 위해서도 사용된다. 두 변수 모두 글로벌 또는 로컬 변수로 지정될 수 있으며, 또한 각각은 1에서
65, 535 사이의 정수 값을 가질 수 있다. 이들 변수의 값을 0으로 설정하면 그 값은 0 대신에 1로 설정된다. 이 변수들의 값을 65.535보다 큰 값
또는 0보다 작은 값으로 설정하고자 하면 그 값은 65.535가 설정되어 버린다. auto_increment_increment 또는 auto_increment_offset의 값을
정수가 아닌 값으로 설정하고자 하면 에러가 발생하고, 그리고 그 변수의 실제 값이 변경 없이 유지된다.
이 두 변수는 AUTO_INCREMENT 의 실행 결과에 아래와 같은 영향을 준다:
❍ auto_increment_increment 는 연속적인 컬럼 값 사이의 간격을 제어 한다. 예를 들면:
o mysql> SHOW VARIABLES LIKE 'auto_inc%';
o +--------------------------+-------+
o | Variable_name | Value |
o +--------------------------+-------+
o | auto_increment_increment | 1 |
o | auto_increment_offset |1 |

:::MySQL Korea:::
o +--------------------------+-------+
o 2 rows in set (0.00 sec)
o mysql> CREATE TABLE autoinc1
o -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
o Query OK, 0 rows affected (0.04 sec)
o mysql> SET @@auto_increment_increment=10;
o ㅡ
o +--------------------------+-------+
o +--------------------------+-------+
o +--------------------------+-------+

:::MySQL Korea:::
o mysql> INSERT INTO autoinc1 VALUES (NULL), (NULL), (NULL), (NULL);
o Records: 4 Duplicates: 0 Warnings: 0
o mysql> SELECT col FROM autoinc1;
o +-----+
o | col |
o +-----+
o | 1|
o | 11 |
o | 21 |
o | 31 |
o +-----+

:::MySQL Korea:::
(이러한 변수들의 현재 값을 얻기 위해 SHOW VARIABLES가 어떻게 사용되었는지 잘 알아 두기 바란다.)
❍ auto_increment_offset는 AUTO_INCREMENT 컬럼 값의 시작 포인트를 결정한다. 아래의 것을 본다면, 이 명령문들은

auto_increment_increment의 설명에서 보여준 예제와 같은 세션 동안 실행된다고 가정한다:
o mysql> SET @@auto_increment_offset=5;
o +--------------------------+-------+
o +--------------------------+-------+
o +--------------------------+-------+
o mysql> CREATE TABLE autoinc2
o -> (col INT NOT NULL AUTO_INCREMENT PRIMARY KEY);

:::MySQL Korea:::
o mysql> INSERT INTO autoinc2 VALUES (NULL), (NULL), (NULL), (NULL);
o Records: 4 Duplicates: 0 Warnings: 0
o mysql> SELECT col FROM autoinc2;
o +-----+
o | col |
o +-----+
o | 5|
o | 15 |
<span lang="EN" style="FONT-SIZE: 10pt; FONT-FAMILY: "Courier New"; mso-ansi-language:

EN; mso-bidi-font-size: 9.0pt; mso-

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.2.3. 시스템 변수 사용하기

5.2.3.1. 구조(structured) 시스템 변수
5. 데이터 베이스 관리 5.2.3.2. 동적(dynamic) 시스템 변수
5.2. mysqld — MySQL 서버
5.2.3 시스템 변수 사용하기 mysql 서버는 서버가 어떻게 구성되었는지를 알려주는 많은 시스템 변수들을 관리한다. Section 5.2.2, “서버 시스템 변수”에서는 이
5.2.3.1 구조(structured) 시스템 변수 러한 변수들의 의미를 설명한다. 각 시스템 변수는 디폴트 값을 가지고 있다. 시스템 변수는 서버 스타트업 시점에 명령어 라인 또는 옵
션 파일에서 설정될 수 있다. 대부분의 것들은 서버가 구동되는 동안에 SET 명령문을 사용해서 동적으로 그 값이 변경될 수 있는데, 이
명령문은 서버를 중단하고 다시 구동시키지 않는 상태에서 서버의 동작을 수정할 수 있게 해 준다. 여러분은 수식 안에서 시스템 변수의
값을 참조할 수 있다.
서버는 두 가지 종류의 시스템 변수를 관리한다. 글로벌 변수는 서버의 전반적인 동작에 영향을 준다. 세션 변수는 개별 클라이언트 접속
에 대한 서버 동작에 영향을 준다. 주어진 하나의 시스템 변수는 글로벌과 세션 값을 모두 가질 수가 있다. 글로벌 및 세션 시스템 변수
는 아래와 같이 관련이 있다:
● 서버가 구동될 때, 서버는 모든 글로벌 변수를 자신의 디폴트 값으로 초기화 시킨다. 이러한 디폴트 값은 명령어 라인 또는 옵션
파일에서 지정된 옵션으로 변경될 수 있다. ( Section 4.3, “프로그램 옵션 지정하기”를 참조할 것.)
● 서버는 접속되는 각각의 클라이언트에 대한 세션 변수 셋을 관리하기도 한다. 클라이언트의 세션 변수는 접속되는 시점에 대응
되는 글로벌 변수의 현재 값으로 초기화 된다. 예를 들면, 클라이언트의 SQL 모드는 세션 sql_mode 값의 제어를 받는데, 이것
은 클라이언트가 접속될 때 글로벌 sql_mode 값으로 초기화 된 것이다.
시스템 변수의 값은 서버 스타트업 시점에 명령어 라인 또는 옵션 파일에 있는 옵션을 가지고 글로벌하게 설정 될 수 있다. 여러분이 스
타트업 옵션을 사용해서 변수가 숫자 값을 가지도록 설정을 한다면, 이 값은 K, M, 또는 G (대 소문자 구분 없음)라는 접미사를 사용해
서 1024, 10242 or 10243의 승수를 표시할 수 있다;즉, 킬로 바이트, 메가 바이트,또는 기가 바이트를 의미한다. 따라서, 아래의 명령어
는 서버를 16메가 바이트의 캐시 크기와 1 기가 바이트의 최대 패킷 크기를 가지고 구동 되도록 만든다.:
mysqld --query_cache_size=16M --max_allowed_packet=1G

:::MySQL Korea:::
옵션 파일 내에서는, 이러한 변수는 다음과 같이 보인다:
[mysqld]
query_cache_size=16M
max_allowed_packet=1G
접미사의 문자 크기는 상관이 없다; 16M 와 16m 는 동일한 것이며, 1G 와 1g도 마찬가지 이다.
만약에 런타임 시에 SET 명령문을 가지고 설정할 수 있는 시스템 변수의 최대 값을 제한하고자 한다면, 서버 스타트업 시점에 --
maximum-var_name 의 형태 옵션을 사용해서 최대 값을 한정할 수가 있게 된다. 예를 들면, query_cache_size의 크기가 런타임 시
에 32MB 보다 커지기 않게 하기 위해서는, --maximum-query_cache_size=32M의 옵션을 사용한다.
많은 시스템 변수들이 동적인 변수이며 서버가 동작 중에 있을 때 SET 명령문을 사용해서 변경될 수 있다.이러한 변수의 리스트를 보고
싶다면, Section 5.2.3.2, “동적(dynamic) 시스템 변수”를 참조 한다. SET명령문을 사용해서 시스템 변수를 변경하기 위해서는,
var_name와 같은 것을 통해서 참조하기 바라며, 옵션으로는 수정자(modifier)를 앞세우기도 한다:
● 하나의 변수가 글로벌 변수임을 확실하게 지정하기 위해서는, 변수 이름 앞에 GLOBAL 또는 @@global. 를 앞세운다. 글로벌
변수 지정은 SUPER 권한이 있어야 한다.

● 하나의 변수를 세션 변수로 확실하게 지정하기 위해서는, 변수 이름 앞에 SESSION, @@session. 또는 @@.를 앞세운다. 세션
변수 설정은 특별한 권한이 필요하지 않지만, 클라이언트는 자신의 세션 변수만을 변경할 수 있으며, 다른 클라이언트의 세션 변
수에는 영향을 줄 수가 없다.
● LOCAL 과 @@local. 는 SESSION 과 @@session. 과 동일한 것이다.

● 수정자(modifier)가 있다면, SET 명령문은 세션 변수를 변경 시킨다.
SET 명령문은 다중 변수 지정문을 가질 수 있는데, 각각은 콤마(,)로 구분된다. 여러분이 여러 개의 시스템 변수를 설정한다면, 명령문
안에 있는 가장 최신의 GLOBAL 또는 SESSION 수정자가 뒤따라 오는 수정자가 지정되지 않은 변수를 위해 사용된다..
예제:

:::MySQL Korea:::
SET sort_buffer_size=10000;
SET @@local.sort_buffer_size=10000;
SET GLOBAL sort_buffer_size=1000000, SESSION sort_buffer_size=1000000;
SET @@sort_buffer_size=1000000;
SET @@global.sort_buffer_size=1000000, @@local.sort_buffer_size=1000000;
여러분이 SET를 가지고 시스템 변수의 값을 지정할 때, 변수 값의 접미사는 사용할 수가 없다 (스타트 업 옵션에서 사용한 것과 같이).
하지만, 그 값은 하나의 수식 형태로 나타낼 수는 있다:
SET sort_buffer_size = 10 * 1024 * 1024;
@@var_name 신텍스는 다른 데이터 베이스 시스템과의 호환성을 위해 지원되는 것이다.
여러분이 세션 시스템 변수를 변경한다면, 그 값은 여러분이 세션을 종료하거나 또는 그 세션 변수의 값을 다른 것을 변경하기 전까지 그
대로 유지가 된다. 변수 값의 변경은 다른 클라이언트에는 보여지지 않는다.
글로벌 변수를 변경한다면, 서버가 재 구동 되기 전까지 변경된 값이 기억되고 새로운 접속에서 사용될 것이다. (글로벌 변수를 영구적
인 값으로 만들기 위해서는, 그 값을 옵션 파일에서 설정을 해야 한다.) 이렇게 변경된 값은 글로벌 변수에 접근하는 모든 클라이언트가
볼 수 있게 된다. 하지만, 변경 사항은 글로벌 변수 변경 후에 접속을 하는 클라이언트의 세션 변수에만 영향을 주게 된다. 글로벌 변수
의 변경 내용은 이미 기존에 접속을 하고 있는 클라이언트의 세션 변수에는 어떠한 영향도 주지 못한다 (클라이언트가 SET GLOBAL
명령문을 입력한다고 하더라도 마찬가지임).
올바르지 않게 사용하는 것을 방지하기 위해서, MySQL은 SET GLOBAL이 SET SESSION 을 가지고서 만 사용되는 변수와 함께 사
용되거나 또는 글로벌 변수를 설정할 때 GLOBAL (또는 @@global.)를 사용하지 않을 경우에는 에러를 발생 시킨다.
SESSION 변수를 GLOBAL 값으로 설정하거나 또는 GLOBAL 값을 컴파일된 MySQL 디폴트 값으로 설정하기 위해서는, DEFAULT
키워드를 사용한다. 예를 들면, 아래의 두 명령문은 max_join_size의 세션 값을 글로벌 값으로 설정하는데 있어서 동일한 것들이다:
SET max_join_size=DEFAULT;

:::MySQL Korea:::
SET @@session.max_join_size=@@global.max_join_size;
모든 시스템 변수가 DEFAULT로 설정되는 것은 아니다. 어떤 경우에는, DEFAULT를 사용하는 것이 에러를 만들 수도 있다.
@@-수정자(modifiers)중의 하나를 사용해서 수식 안에 있는 글로벌 또는 세션 시스템 변수의 특정 값을 참조할 수가 있다. 예를 들

면, 아래와 같이 SELECT 에서 값을 추출할 수가 있다:
SELECT @@global.sql_mode, @@session.sql_mode, @@sql_mode;
여러분이 수식 안에 있는 시스템 변수를 @@var_name로 참조할 때(즉, @@global. 또는 @@session.를 지정하지 않을 때), MySQL
은 세션 값이 존재하면 그것을 리턴하고 아니면 글로벌 값을 리턴한다. (이것은 SET @@var_name = value와는 다른 것인데, 이것은
항상 세션 값을 참조하는 것이다.)
Note: 어떤 시스템 변수들은 ON 또는 1으로 설정을 해서 SET 명령문을 활성화 시키거나 또는 OFF 또는 0으로 설정을 해서 비활성화
시킬 수가 있다. 하지만, 이 같은 변수들을 명령어 라인 또는 옵션 파일에서 설정하기 위해서는, 반드시 1 또는 0으로 설정을 해야 한다;
ON 또는 OFF으로 설정하는 것은 동작하지 않는다. 예를 들면, 명령어 라인에서, --delay_key_write=1은 동작을 하지만 --
delay_key_write=ON는 그렇지 못하게 된다.
시스템 변수의 이름과 값을 디스플레이 하기 위해서는, SHOW VARIABLES 명령문을 사용한다.
mysql> SHOW VARIABLES;
+--------+--------------------------------------------------------------+
| Variable_name | Value |
+--------+--------------------------------------------------------------+
| auto_increment_increment |1 |
| auto_increment_offset |1 |

:::MySQL Korea:::
| automatic_sp_privileges | ON |
| back_log | 50 |
| basedir |/ |
| bdb_cache_size | 8388600 |
| bdb_home | /var/lib/mysql/ |
| bdb_log_buffer_size | 32768 |
| bdb_logdir | |
| bdb_max_lock | 10000 |
| bdb_shared_data | OFF |
| bdb_tmpdir | /tmp/ |
| binlog_cache_size | 32768 |
| bulk_insert_buffer_size | 8388608 |
| character_set_client | latin1 |
| character_set_connection | latin1 |
| character_set_database | latin1 |
| character_set_results | latin1 |

:::MySQL Korea:::
| character_set_server | latin1 |
| character_set_system | utf8 |
| character_sets_dir | /usr/share/mysql/charsets/ |
| collation_connection | latin1_swedish_ci |
| collation_database | latin1_swedish_ci |
| collation_server | latin1_swedish_ci |
...
| innodb_additional_mem_pool_size | 1048576 |
| innodb_autoextend_increment |8 |
| innodb_buffer_pool_awe_mem_mb | 0 |
| innodb_buffer_pool_size | 8388608 |
| innodb_checksums | ON |
| innodb_commit_concurrency |0 |
| innodb_concurrency_tickets | 500 |
| innodb_data_file_path | ibdata1:10M:autoextend |
| innodb_data_home_dir | |

:::MySQL Korea:::
...
| version | 5.0.19-Max |
| version_comment | MySQL Community Edition - Max (GPL) |
| version_compile_machine | i686 |
| version_compile_os | pc-linux-gnu |
| wait_timeout | 28800 |
+--------+--------------------------------------------------------------+
LIKE 구문과 함께 사용하면, 명령문은 패턴이 일치하는 변수의 값들만 출력하게 된다. 특정 변수의 이름을 얻기 위해서는, LIKE 구문
을 아래와 같이 사용한다:
SHOW VARIABLES LIKE 'max_join_size';
SHOW SESSION VARIABLES LIKE 'max_join_size';
이름이 일치하는 변수의 리스트를 얻기 위해서는, LIKE 구문 안에 ‘%’ 와일드카드 문자를 사용한다:
SHOW VARIABLES LIKE '%size%';
SHOW GLOBAL VARIABLES LIKE '%size%';
와일드카드 문자는 매치 시키고자 하는 패턴 안에 어느 위치에서도 사용할 수가 있다. 엄밀하게 말한다면, ‘_’ 는 모든 단일 문자를 매
치를 시키는 와일드카드 문자이기 때문에, 문자 그대로 이것을 매치 시키고자 한다면 ‘￦_’ 형태로 사용해야 한다. 실제로는, 거의 필
요하지가 않다.
SHOW VARIABLES에 대해서는, 여러분이 GLOBAL 또는 SESSION중에 어느 것도 지정을 하지 않으면, MySQL은 SESSION 값을

:::MySQL Korea:::
리턴 한다.
GLOBAL 변수만을 설정할 때에 GLOBAL 키워드를 요청하고 글로벌 변수에서 값을 추출할 때에는 요청하지 않는 이유는 이후 버전에
서 나올 수 있는 문제들을 피하기 위해서이다. 우리가 GLOBAL 변수와 똑 같은 이름을 사용하는 SESSION 변수를 삭제했다면,
SUPER 권한을 가지고 있는 클라이언트는 자신의 접속을 위한 SESSION 변수가 아닌 GLOBAL 변수가 우연히 변경될 수도 있었을 것
이다. 만약에 GLOBAL 변수와 똑 같은 이름을 가지고서 SESSION 변수를 추가 한다면, 자신의 변경된 SESSION 변수만을 찾고자 했
던 클라이언트는 GLOBAL 변수를 변경하려고 할 것이다.

:::MySQL Korea:::
제목검색
5.2.3.1. 구조(structured) 시스템 변수

5. 데이터 베이스 관리 구조 변수(structured variable)는 정규 시스템 변수(regular system variable)와는 두 가지 측면에서 서로 다르다:
5.2.3 시스템 변수 사용하기 ● 이 변수의 값은 밀접하게 관련되었다고 간주되는 서버 파라미터를 지정하는 요소들을 가지고 있는 구조이다.
● 구조 변수의 주어진 타입에는 여러 가지 인스턴스가 있을 수 있다. 각 인스턴스는 서로 다른 이름을 가지며 서버가 관리하
5.2.3.2 동적(dynamic) 시스템 변수 는 서로 다른 자원들을 참조한다.
MySQL 5.0은 하나의 구조 변수 타입을 지원하는데, 이것은 키 캐시의 동작을 관장하는 파라미터를 지정한다. 하나의 키 캐시 구
조 변수는 다음의 요소들을 가지고 있다:
● key_buffer_size
● key_cache_block_size
● key_cache_division_limit
● key_cache_age_threshold
이 섹션에서는 구조 변수를 참조하기 위한 신텍스를 설명한다. 키 캐시 변수들은 신텍스 예제들에서 사용되지만, 키 캐시가 어떻게
동작하는지에 대한 상세 설명은 다른 곳에서 찾아 볼 수가 있다.Section 7.4.6, “MyISAM 키 캐시”를 참조할 것.
구조 변수 인스턴스의 컴퍼넌트를 참조하기 위해서는, instance_name.component_name 포맷에 있는 컴퍼넌트의 이름을 사용한

다. 예를 들면:
hot_cache.key_buffer_size
hot_cache.key_cache_block_size
cold_cache.key_cache_block_size

:::MySQL Korea:::
각각의 구조 시스템 변수에 대해서는, default 이름을 가진 하나의 인스턴스가 먼저 정의 된다. 아무런 인스턴스의 이름을 사용하
지 않고 구조 변수의 컴퍼넌트를 참조할 경우에는, default 인스턴스가 사용되게 된다. 따라서, default.key_buffer_size 와
key_buffer_size 는 둘 다 동일한 시스템 변수를 참조하게 된다.
구조 변수 인스턴스와 컴퍼넌트는 아래의 명명 규칙을 따른다:
● 주어진 구조 변수의 타입에 대해서는, 각 인스턴스는 반드시 그 타입의 변수 안에서 고유의 이름을 가져야 한다. 하지만, 인
스턴스 이름은 구조 변수 타입 전체에서 유일한 이름을 사용할 필요는 없다. 예를 들면, 각 구조 변수는 default라는 이름
의 변수를 하나씩 갖고 있고, 따라서 default는 변수 타입 전체에서 유일하지가 않게 된다.

● 각 구조 변수 타입의 컴퍼넌트 이름은 반드시 모든 시스템 변수 이름을 통틀어서 유일해야 한다. 이렇지 않다면(즉, 두 개의
서로 다른 타입의 구조 변수들이 동일한 이름의 컴퍼넌트 멤버 이름을 공유한다면), 인스턴스 이름의 사용해서 검증하지 못
한 멤버 이름을 참조하기 위해서는 어떤 디폴트 구조 변수를 사용해야 하는지가 불분명해 진다.

● 만약에 구조 변수 인스턴스 이름이 인용 부호를 사용하지 않은 구분자(identifier)처럼 규칙에 어긋나 있다면, 백틱스
(backticks)를 사용해서 인용 부호화된 구분자로 참조를 하게 된다. 예를 들면, hot-cache 은 규칙에 위반되지만, `hot-
cache` 은 아니다.
● global, session, 그리고 local은 정확한(legal) 인스턴스 이름은 아니다. 이것은 비 구조(non-structured) 시스템 변수
를 참조하기 위한 @@global.var_name 와 같은 표기법(notation)과는 충돌을 피하게 된다.
현재까지의 버전으로는, 위의 처음 두 가지 규칙에 대해서는 혼란이 없는데, 그 이유는 구조 변수 타입만이 키 캐시를 위한 것이기
때문이다. 이러한 규칙들은 다른 구조 변수들이 향후에 생성되어 진다면 보다 중요성이 증대될 것이다.
한가지 예외적인 것은, 단순한 변수 이름이 나타나는 문장에서 컴퍼넌트 이름을 사용해서 구조 변수의 컴퍼넌트를 참조할 수가 있
다는 것이다. 예를 들면, 여러분은 명령어 라인 옵션을 사용해서 구조 변수의 값을 지정할 수가 있게 된다:
shell> mysqld --hot_cache.key_buffer_size=64K
옵션 파일에서는, 아래의 신텍스를 사용한다:
[mysqld]
hot_cache.key_buffer_size=64K

:::MySQL Korea:::
서버가 이 옵션을 가지고 구동된다면, 서버는 8MB의 디폴트 크기를 가지고 있는 디폴트 키 캐시와 더불어서 64KB 크기의
hot_cache라는 이름의 키 캐시를 생성하게 된다.
여러분이 서버를 다음과 같이 구동 시켰다고 가정하자:
shell> mysqld --key_buffer_size=256K ￦
--extra_cache.key_buffer_size=128K ￦
--extra_cache.key_cache_block_size=2048
이와 같은 경우에는, 서버는 디폴트 키 캐시의 트기를 256KB로 설정하게 된다. (--default.key_buffer_size=256K처럼 작성할
수도 있다) 부가적으로, 서버는 the server creates a second key cache named extra_cache 라는 이름의 두 번째 키 캐시를
128KB의 크기로 생성을 하는데, 이 크기는2048 바이트로 설정되는 테이블 인덱스 블록을 캐싱 하기 위한 블록 버퍼의 크기이다.
아래의 예제는 서버를 크기가 3:1:1의 비율로 되어 있는 세 개의 서로 다른 키 캐시를 가지고 시작되도록 하는 것이다:
shell> mysqld --key_buffer_size=6M ￦
--hot_cache.key_buffer_size=2M ￦
--cold_cache.key_buffer_size=2M
구조 변수 값은 런타임 시에도 설정 및 추출을 할 수가 있다. 예를 들면, hot_cache 라는 이름의 키 캐시를 10MB 크기로 설정하기
위해서는, 아래의 명령문 중에 하나를 사용한다:
mysql> SET GLOBAL hot_cache.key_buffer_size = 10*1024*1024;
mysql> SET @@global.hot_cache.key_buffer_size = 10*1024*1024;
캐시 크기를 추출하기 위해서는, 이것을 사용한다:

:::MySQL Korea:::
mysql> SELECT @@global.hot_cache.key_buffer_size;
하지만, 아래의 명령문은 실행되지 않는다. 여기에서 사용된 변수는 컴퍼넌트의 이름으로 해석되는 것이 아니고, LIKE 패턴-매칭
동작을 위한 단순한 스트링으로 해석이 되어 버린다:
mysql> SHOW GLOBAL VARIABLES LIKE 'hot_cache.key_buffer_size';
이것은 단순 변수 이름이 나타날 수 있는 곳에서 구조 변수 이름을 사용할 수 있도록 하는 예외적인 경우이다.

:::MySQL Korea:::
제목검색
5.2.3.2. 동적(dynamic) 시스템 변수

5. 데이터 베이스 관리 많은 서버 시스템 변수들이 동적 변수이며 런타임 시에 SET GLOBAL 또는 SET SESSION를 사용해서 설정
5.2. mysqld — MySQL 서버 될 수 있다. 여러분은 SELECT를 사용해서 그 값을 얻을 수도 있다. Section 5.2.3, “시스템 변수 사용하
5.2.3 시스템 변수 사용하기 기”를 참조.

아래의 테이블은 모든 동적 시스템 변수를 보여 준다. 마지막 컬럼은 각 변수가 GLOBAL 또는 SESSION 중
에 어느 것에(또는 모두에) 적용되는지를 나타낸다. 이 테이블은 또한 SET 명령문을 가지고 설정할 수 있는
세션 옵션의 리스트를 보여준다. Section 13.5.3, “SET 신텍스”에서 이러한 옵션들을 설명하기로 한다.
“스트링(string)” 타입을 가지고 있는 변수들은 스트링 값을 가지게 된다. “숫자(numeric)” 타입의 변수

들은 숫자를 값으로 가진다. “불리안(boolean)” 타입의 변수들은 0, 1, ON 또는 OFF로 설정된다. (이 변수
들을 명령어 라인 또는 옵션 파일에서 설정할 경우에는, 숫자 값으로 설정을 해야 한다.) “목록
(enumeration)”으로 표시된 변수들은 일반적으로 변수에 지정될 수 있는 가능한 값들 주에 한가지로 설정되
어야 하지만, 원하는 목록과 대응되는 숫자로도 설정할 수 있다. 목록 시스템 변수에 대해서는, 첫 번째 목록 값
이 0이 된다. 이것은 ENUM 컬럼과는 다른 것인데, 이 컬럼에서는 첫 번째 목록 값이 1이 된다.
Variable Name Value Type Type
Autocommit boolean SESSION
big_tables boolean SESSION
binlog_cache_size numeric GLOBAL
bulk_insert_buffer_size numeric GLOBAL | SESSION
character_set_client string GLOBAL | SESSION
character_set_connection string GLOBAL | SESSION

:::MySQL Korea:::
character_set_filesystem string GLOBAL | SESSION
character_set_results string GLOBAL | SESSION
character_set_server string GLOBAL | SESSION
collation_connection string GLOBAL | SESSION
collation_server string GLOBAL | SESSION
completion_type numeric GLOBAL | SESSION
concurrent_insert boolean GLOBAL
connect_timeout numeric GLOBAL
convert_character_set string GLOBAL | SESSION
default_week_format numeric GLOBAL | SESSION
delay_key_write OFF | ON | ALL GLOBAL
delayed_insert_limit numeric GLOBAL
delayed_insert_timeout numeric GLOBAL
delayed_queue_size numeric GLOBAL
div_precision_increment numeric GLOBAL | SESSION
engine_condition_pushdown boolean GLOBAL | SESSION
error_count numeric SESSION
expire_logs_days numeric GLOBAL
flush boolean GLOBAL
flush_time numeric GLOBAL
foreign_key_checks boolean SESSION
ft_boolean_syntax numeric GLOBAL
group_concat_max_len numeric GLOBAL | SESSION
identity numeric SESSION

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.2.4. 서버 상태 변수
5. 데이터 베이스 관리 서버는 자신의 동작에 대한 정보를 제공하는 많은 상태 변수를 관리한다. 여러분은 이러한 변수와 값들을 SHOW STATUS 명령문
5.2. mysqld — MySQL 서버 을 사용해서 볼 수가 있다:
mysql> SHOW STATUS;
+-----------------------------------+------------+
+-----------------------------------+------------+
| Aborted_clients |0 |
| Aborted_connects |0 |
| Bytes_received | 155372598 |
| Bytes_sent | 1176560426 |
...
| Connections | 30023 |
| Created_tmp_disk_tables |0 |

:::MySQL Korea:::
| Created_tmp_files |3 |
| Created_tmp_tables |2 |
...
| Threads_created | 217 |
| Threads_running | 88 |
| Uptime | 1389872 |
+-----------------------------------+------------+
많은 상태 변수들은 FLUSH STATUS 명령문에 의해 0으로 리셋 되어진다.
상태 변수는 아래와 같은 의미를 가지고 있다. 아무런 버전 정보가 없는 변수들은 5.0 이전 버전에서부터 있었던 것들이다
● Aborted_clients
클라이언트가 올바르게 닫히지 않고 멈추었기 때문에 중단된 접속의 숫자. Section A.2.10, “Communication Errors
and Aborted Connections”를 참조.
● Aborted_connects
MySQL 서버에 접속을 시도했으나 실패한 횟수. Section A.2.10, “Communication Errors and Aborted
Connections”를 참조.
● Binlog_cache_disk_use

:::MySQL Korea:::
임시 바이너리 로그 캐시를 사용했지만 binlog_cache_size 의 값을 초과했고 그리고 트랜젝션에서 오는 명령문을 저장하

기 위해 임시 파일을 사용한 트랜젝션의 숫자.
● Binlog_cache_use
임시 바이너리 로그 캐시를 사용한 트랜젝션의 숫자.
● Bytes_received
모든 클라이언트로부터 받게 되는 바이트의 숫자.
● Bytes_sent
모든 클라이언트에 전달되는 바이트의 수.
● Com_xxx
Com_xxx 명령문 카운터 변수는 각 xxx 명령문이 실행된 횟수를 가리킨다. 각 명령문 타입에 대해서는 하나의 상태 변수
가 존재한다. 예를 들면, Com_delete과 Com_insert는 DELETE과 INSERT 명령문을 각각 카운트 한다.
Com_stmt_xxx 상태 변수는 5.0.8에 추가 되었다:
❍ Com_stmt_prepare
❍ Com_stmt_execute
❍ Com_stmt_fetch
❍ Com_stmt_send_long_data
❍ Com_stmt_reset
❍ Com_stmt_close
이 변수들은 프리페어드(prepared) 명령문의 명령어를 표현한다. 이들 변수의 이름들은 네트워크 레이어(layer)에서 사

용되는 COM_xxx 명령어를 참조한다. 다른 말로 표현하면, 이들 변수의 값들은 mysql_stmt_prepare(),
mysql_stmt_execute()와 같은 프리페어드 명령문 API 호출이 실행될 때마다 증가하게 된다. 하지만,
Com_stmt_prepare, Com_stmt_execute 그리고 Com_stmt_close등도 PREPARE, EXECUTE, 또는 DEALLOCATE

:::MySQL Korea:::
PREPARE에 대해서 각각 증가를 하게 된다. 부가적으로, 이전 버전의 명령문 카운터 변수(4.1.3 이후에 사용된 것들)인
Com_prepare_sql, Com_execute_sql, 그리고 Com_dealloc_sql의 값들도 PREPARE, EXECUTE, 및 DEALLOCATE
PREPARE 명령문에 대해서 증가를 하게 된다. Com_stmt_fetch은 커서로부터 가져(fetching)될 때 생기는 네트워크 라
운드-트립(round-trip)의 전체 숫자를 표현하게 된다.
Com_stmt_xxx 변수의 모든 것들은 프리페어드 명령문 이슈가 알려져 있지 않거나 또는 실행하는 동안 에러가 발생되더
라도 증가를 한다. 다른 말로 표현하면, 이들 변수의 값들은 발생된 요청의 숫자에 대응하는 것이지, 성공적으로 완료가
된 요청의 숫자에 대응되는 것이 아니다.
● Compression
클라이언트 접속이 클라이언트/서버 프로토콜에 있는 압축을 사용하는지 판단함. MySQL 5.0.16에 추가 됨.
● Connections
MySQL 서버에 시도된 접속 횟수(성공 또는 실패 모두 포함).
● Created_tmp_disk_tables
서버가 명령문을 실행할 때 자동으로 생성되는 디스크에 있는 임시 테이블의 숫자.
● Created_tmp_files
Mysqld이 생성한 임시 파일의 숫자.
● Created_tmp_tables
서버가 명령문을 실행할 때 자동으로 생성되는 메모리에 있는 임시 테이블의 숫자. Created_tmp_disk_tables이 크다면,
tmp_table_size 변수의 값을 늘려서 임시 테이블이 디스크가 아닌 메모리에 들어 가도록 하길 원할 수도 있다.
● Delayed_errors
에러를 발생 시키는 것에 대해(아마도 duplicate key) INSERT DELAYED를 사용해서 쓰여진 줄의 숫자.

:::MySQL Korea:::
● Delayed_insert_threads
사용 중에 있는 INSERT DELAYED 핸들러 쓰레드 숫자.
● Delayed_writes
쓰여진 INSERT DELAYED 줄의 숫자.
● Flush_commands
실행된 FLUSH 명령문의 숫자.
● Handler_commit
내부 COMMIT 명령문의 숫자.
● Handler_discover
MySQL 서버는 주어진 이름을 가진 테이블에 대한 정보를 NDB Cluster 스토리지 엔진에 요청할 수 있다. 이것을 디스커
버리(discovery)라고 부른다. Handler_discover는 테이블들이 이 메커니즘을 통해서 몇 번이나 발견되었는지를 나타낸
다.
● Handler_delete
줄이 테이블에서 삭제된 횟수.
● Handler_read_first
첫 번째 엔트리가 인덱스에서 읽혀진 횟수. 이 값이 크다면, 서버는 많은 수의 전체 인덱스 스캔을 실행하고 있음을 의미하
는 것이다; 예를 들면, SELECT col1 FROM foo에서, col1은 인덱스 된 것으로 간주된다.

:::MySQL Korea:::
● Handler_read_key
키에 근거를 한 줄을 읽기 위한 요청 횟수. 이 값이 크다면, 여러분이 사용하는 테이블이 쿼리에 올바르게 인덱스 되어 있

다는 좋은 의미이다.
● Handler_read_next
키 순서에서 다음 줄을 읽기 위한 요청 횟수. 이 값은 인덱스 컬럼을 범위 제한 값을 가지고 쿼리 하거나 또는 인덱스 스캔

을 한다면, 증가하게 된다..
● Handler_read_prev
키 순서에서 이전 줄을 읽기 위한 요청의 숫자. 이러한 읽기 방식은 주로ORDER BY ... DESC를 최적화 시키기 위해 사용
된다.
● Handler_read_rnd
고정된 위치를 근거로 줄을 읽기 위한 요청 횟수. 결과 값을 정렬하도록 요청하는 많은 수의 쿼리를 실행할 것이라면 이 값

은 높게 된다. 여러분은 아마도 MySQL이 전체 테이블을 스캔할 것을 요구하는 쿼리를 많이 가지고 있거나 또는 키를 정
확히 사용하지 않는 조인(join)을 가지고 있는 것이다.
● Handler_read_rnd_next
데이터 파일에 있는 다음 줄을 읽기 위한 요청 횟수. 이 값은 여러분이 많은 수의 테이블 스캔을 할 경우에 높게 된다. 일반

적으로는 테이블이 올바르게 인덱스 되지 않았거나 또는 여러분의 쿼리가 여러분이 가지고 있는 인덱스를 활용하기 위해
쓰여지지 않았음을 의미한다.
● Handler_rollback
내부 ROLLBACK 명령문의 숫자.
● Handler_update

:::MySQL Korea:::
테이블에 있는 줄을 업데이트 하기 위해 요청하는 횟수.
● Handler_write
테이블에 줄을 하나 삽입하기 위한 요청 횟수.
● Innodb_buffer_pool_pages_data
데이터를 가지고 있는 페이지 숫자(dirty or clean). MySQL 5.0.2에서 추가됨.
● Innodb_buffer_pool_pages_dirty
현재 더티(dirty)한 페이지의 숫자. MySQL 5.0.2에서 추가됨.
● Innodb_buffer_pool_pages_flushed
버퍼 풀 페이지-플러시(buffer pool page-flush) 요청 숫자. MySQL 5.0.2에 추가 됨.
● Innodb_buffer_pool_pages_free
프리(free) 페이지 숫자. MySQL 5.0.2에 추가 됨.
● Innodb_buffer_pool_pages_latched
InnoDB 버퍼 풀에 있는 latched 페이지의 숫자. 이것은 현재 읽히고 있거나 또는 쓰여지고 있거나 또는 여러 가지 이유로
인해 플러시 될 수 없거나 또는 삭제할 수 없는 페이지들을 가리킨다. MySQL 5.0.2에 추가 됨.
● Innodb_buffer_pool_pages_misc
줄 잠금 또는 적응적 해시 인덱스(adaptive hash index)와 같은 관리적인 오버 헤드를 위해 할당되었기 때문에 바쁜

(busy) 상태인 페이지의 숫자. 이 값은 Innodb_buffer_pool_pages_total – Innodb_buffer_pool_pages_free –

:::MySQL Korea:::
Innodb_buffer_pool_pages_data를 통해서도 계산될 수 있다. MySQL 5.0.2에 추가 됨.
● Innodb_buffer_pool_pages_total
페이지에 있는 버퍼 풀의 전체 크기. MySQL 5.0.2에 추가 됨.
● Innodb_buffer_pool_read_ahead_rnd
InnoDB에 의해 초기화 되는 “무작위(random)” read-aheads의 숫자. 이것은 쿼리가 테이블의 많은 부분을 무작위 순
서로 스캔 할 때 발생된다. MySQL 5.0.2에서 추가 됨.
● Innodb_buffer_pool_read_ahead_seq
InnoDB에 의해 초기화 되는 시퀀셜 read-aheads의 숫자. 이것은 InnoDB가 시퀀셜로 전체 테이블을 스캔할 때 발생한
다. MySQL 5.0.2에서 추가 됨.
● Innodb_buffer_pool_read_requests
InnoDB가 실행한 논리적인 읽기 요청의 숫자. MySQL 5.0.2에서 추가 됨.
● Innodb_buffer_pool_reads
InnoDB가 버퍼 풀에서 찾지를 못하고 단일 페이지 읽기를 해야만 하는 논리적 읽기 횟수. MySQL 5.0.2에 추가 됨.
● Innodb_buffer_pool_wait_free
일반적으로는, 백그라운드에서 발생된 InnoDB 버퍼 풀에 쓰기를 한다. 하지만, 페이지를 읽거나 또는 생성하는 것이 필요
하고 어떠한 페이지도 깨끗이 만드는 것이 불가능 하다면, 페이지가 처음으로 플러시 되는 것도 역시 기다려야 한다. 이 카
운터는 이러한 대기 인스턴스를 카운트 한다. 버퍼 풀의 크기가 올바르게 설정 되었다면, 이 값은 작을 것이다. MySQL
5.0.2에서 추가 됨.
● Innodb_buffer_pool_write_requests

:::MySQL Korea:::
쓰기 횟수는 InnoDB 버퍼 풀에 기록된다. MySQL 5.0.2에 추가 됨.
● Innodb_data_fsyncs
지금 까지의 fsync() 동작 횟수. MySQL 5.0.2에 추가 됨.
● Innodb_data_pending_fsyncs
현재 지연되고 있

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.2.5. 서버 SQL 모드
5. 데이터 베이스 관리 MySQL 서버는 서로 다른 SQL 모드 상태에서 동작할 수가 있고, 그리고 서로 다른 클라이언트에 대해 이러한 모드들을 다르게 적
5.2. mysqld — MySQL 서버 용할 수가 있다. 이러한 능력은 각 어플리케이션들이 서버의 동작 모드를 따라서 자신의 요구 사항을 처리할 수 있게 해 준다.
모드는 어떤 SQL 신텍스를 MySQL이 지원하고 있는지 그리고 데이터의 유효성(Validation)을 검사하는 방법은 무엇이 있는지를
가리킨다. 이것은 MySQL을 서로 다른 환경에서 사용하는 것을 손쉽게 만들어 주며 그리고 다른 데이터 베이스 서버와 함께
MySQL을 사용하는 것이 가능하도록 만들어 준다.
디폴트 SQL 모드 설정은 mysqld을 --sql-mode="modes" 옵션과 함께 구동 시켜서 할 수가 있다. modes 는 콤마(,)로 구분되
는 서로 다른 모드의 리스트이다. 디폴트 값은 비어 있다(empty) (아무런 모드고 설정되어 있지 않다). 만약에 확실하게 비어둘 생
각이라면, modes 값도 역시 비어 둘 수 있다 (--sql-mode="").
여러분은 서버의 런 타임 시에 sql_mode 시스템 값을 설정을 하기 위한 SET [GLOBAL|SESSION] sql_mode='modes' 명령문

을 사용해서 SQL 모드의 값을 변경 시킬 수가 있다. GLOBAL 변수 설정은 SUPER 권한이 필요하며 그 시간 이후에 연결되는 모
든 클라이언트의 동작에 영향을 주게 된다. 모든 클라이언트는 자신의 세션 sql_mode 값을 언제든지 변경할 수가 있다.
여러분은 현재의 글로벌 또는 세션 sql_mode 값을 아래의 명령문을 가지고 설정할 수가 있다:
SELECT @@global.sql_mode;
SELECT @@session.sql_mode;
가장 중요한 sql_mode 값들은 아마도 아래의 것들일 것이다:
● ANSI

:::MySQL Korea:::
표준 SQL에 보다 근접하도록 신텍스와 실행 동작을 변경 시킴.
● STRICT_TRANS_TABLES
만약에 트랜젝션 테이블 속으로 값을 주어진 형태로 삽입할 수가 없다면, 명령문을 중단한다. 논-트랜젝션(non-
transactional) 테이블에 대해서는, 그 값이 단일-줄 명령문 또는 다중-줄 명령문의 맨 처음 줄에 나오게 되면 명령문을
중단한다. 보다 자세한 설명은 이 섹션 후반부에 하기로 한다. (MySQL 5.0.2에서 구현됨.)
● TRADITIONAL
MySQL의 동작을 마치 “전통적인(traditional)” SQL 데이터 베이스 시스템처럼 구동되도록 만든다. 올바르지 않은 값
을 컬럼에 삽입할 때 이 모드에 대한 간단한 설명이 “경고문 대신에 에러로 나온다(give an error instead of a
warning)”. Note: INSERT/UPDATE 는 에러가 발생되는 즉시 중단된다. 이것은 여러분이 논-트랜젝션(non-
transaction) 스토리지 엔진을 사용한다면 원하는 결과가 아닐 것인데, 왜냐하면 에러 이전에 수행된 데이터 변경은 롤백
(rolled-back)되지 않고, 그 결과 ‘부분적으로 수행된(partially done)”업데이트가 되기 때문이다. (MySQL 5.0.2에
추가 됨)
이 매뉴얼이 “스트릭트 모드(strict mode)”를 참조할 때에는, 적어도 STRICT_TRANS_TABLES 또는

STRICT_ALL_TABLES중의 하나가 활성화 되어 있는 곳의 모드를 의미하는 것이다.
아래의 리스트는 모든 지원 모드에 대한 설명이다:
● ALLOW_INVALID_DATES
전체 날짜를 검사하지 않는다. 월(month)이 1에서 12 사이와 일자가 1에서31일 사이인 것들만 검사한다. 이것은 여러분
이 년, 월, 그리고 날짜(day)를 세 개의 필드에서 얻고 사용자가 삽입하는(날짜 유효 없이) 것을 정확하게 저장하고자 하
는 웹 어플리케이션에서 유용하게 사용할 수 있다. 이 모드는 DATE 와 DATETIME 컬럼에 적용된다. 이것은
TIMESTAMP 컬럼에는 적용되지 않는데, 이 컬럼은 유효한 날짜를 필요로 한다
이 모드는 MySQL 5.0.2에서 추가 되었다. 5.0.2 이전에는, 이것이 디폴트 MySQL 날짜-핸들링 모드였다. 5.0.2 이후에
는, 서버는 월(month)와 날짜(day) 값이, 단순히 1에서 12 사이와 1에서 31 사이의 값이 아닌, 규칙에 맞아야 하는 것을
요구한다. 스트릭트 모드를 비활성화 시키면, '2004-04-31' 과 같은 유효하지 않은 값은 '0000-00-00'로 변환 되고
경고문을 내보내게 된다. 스트릭트 모드를 활성화 시키면, 유효하지 않은 날짜 값은 에러를 발생 시킨다. 이러한 날짜 값

:::MySQL Korea:::
을 허용하기 위해서는, ALLOW_INVALID_DATES를 활성화 시킨다.
● ANSI_QUOTES
‘"’를 구분자 인용 부호 문자로 다루고 (‘`’ 인용 부호 문자 처럼) 스트링 인용 문자로 다루지 않는다. 여러분은 이 모
드에서도 여전히 ‘`’를 인용 구분자로 사용할 수가 있다. ANSI_QUOTES을 활성화 시키면, 이중 인용 부호를 사용해
서 문자 스트링을 인용할 수는 없게 되는데, 그 이유는 그것이 구분자로 해석되기 때문이다.
● ERROR_FOR_DIVISION_BY_ZERO
INSERT 또는 UPDATE를 실행하는 동안 0 (또는 MOD(X,0))으로 나눗셈을 하는 것을 만나게 되면 스트릭트 모드에서

는 에러가 나오게 된다(다른 모드에서는 경고가 나옴). 만약에 이 모드가 활성화 되지 않았다면, MySQL은 0으로 나누는
것에 대해 NULL값을 대신 리턴 하게 된다. INSERT IGNORE 또는 UPDATE IGNORE에서 사용되면, MySQL은 0으
로 나누는 것에 대해 경고문을 만들어 내지만, 동작의 결과는 NULL이 된다. (MySQL 5.0.2에서 구현됨)
● HIGH_NOT_PRECEDENCE
MySQL 5.0.2 이후에, NOT 연산자의 우선권은 NOT a BETWEEN b AND c 와 같은 수식에서는 NOT (a BETWEEN
b AND c)와 같이 분석(parse)된다. MySQL 5.0.2 이전에는, 수식은 (NOT a) BETWEEN b AND c 과 같이 분석되었
다. 이전버전과 같은 우선권 동작은 HIGH_NOT_PRECEDENCE SQL 모드를 활성화 시키면 된다. (MySQL 5.0.2에서
추가됨)
mysql> SET sql_mode = '';
mysql> SELECT NOT 1 BETWEEN -5 AND 5;
-> 0
mysql> SET sql_mode = 'broken_not';
mysql> SELECT NOT 1 BETWEEN -5 AND 5;

:::MySQL Korea:::
-> 1
● IGNORE_SPACE
함수 이름과 ‘(’ 문자 사이에 스페이스를 허용한다. 이것은 모든 함수 이름이사용 지정된(reserved) 단어로 취급되도
록 한다. 그 결과, 만약에 어떤 데이터 베이스, 테이블, 또는 사용 지정된 컬럼 이름에 여러분이 엑세스 하고자 한다면, 반
드시 그것을 인용 부호화 해야 한다. 예를 들면, USER() 라는 함수가 존재하기 때문에, mysql 데이터 베이스에 있는
user 테이블과 그 테이블 안에 있는 User 컬럼은 사용 지정 되는데, 따라서 그것들은 인용 부호로 둘러 쌓여야 한다:
SELECT "User" FROM mysql."user";
IGNORE_SPACE SQL 모드는 빌트인(built-in) 함수에 적용 되며, 스토어드 루틴에는 적용되지 않는다. 루틴 이름 다음
에 스페이스를 가지는 것은 항상 가능한데, IGNORE_SPACE가 활성화 되어 있는지 와는 상관이 없게 된다.
● NO_AUTO_CREATE_USER
비어 있지 않는(non-empty) 패스워드가 함께 지정되어 있지 않는다면, GRANT가 자동으로 새로운 사용자를 생성하지

못하도록 만든다. (MySQL 5.0.2에 추가 됨)
● NO_AUTO_VALUE_ON_ZERO
NO_AUTO_VALUE_ON_ZERO는 AUTO_INCREMENT 컬럼을 처리 하는데 영향을 준다. 일반적으로, NULL 또는 0

중에 하나를 컬럼에 삽입함으로써 컬럼에 대한 다음 시퀀스의 숫자를 만들어낼 수 있다. NO_AUTO_VALUE_ON_ZERO
는 0 에 대한 이러한 행동을 종식 시켜서 NULL 만이 다음 시퀀스 숫자를 만들어 내도록 한다.
이 모드는 0 이 테이블의 AUTO_INCREMENT 컬럼에 있을 경우에 유용하게 사용될 수 있다. (0을 저장하는 것은 실제
로는 권장할 사항이 아니다.) 예를 들면, 만약에 여러분이 mysqldump를 가지고 테이블을 덤프하고 그 다음에 그것을 다
시 로드 한다면, MySQL은 일반적으로 0 값을 만날 때 새로운 시퀀스 번호를 만들어 내고, 그 결과로 덤프된 내용과는 다
른 내용물을 가진 테이블이 생성되게 된다. 덤프 파일을 다시 로드 하기 전에 NO_AUTO_VALUE_ON_ZERO를 활성화
시키는 것이 이 문제를 해결하는 방법이다. mysqldump 은 현재, 이 문제를 해결하기 위해서, 자신의 결과에 자동으로

:::MySQL Korea:::
NO_AUTO_VALUE_ON_ZERO를 활성화 시키는 명령문을 포함 시키고 있다. NO_BACKSLASH_ESCAPES

스트링 안에 있는 종료(escape) 문자로서 백슬레시 문자(‘￦’) 사용을 비활성화 시킨다. 이 모드가 활성화가 되면, 백
슬레시는 다른 문자와 같이 일상적인 문자로 인식된다. (MySQL 5.0.1에서 구현됨)
● NO_DIR_IN_CREATE
테이블을 생성할 때, 모든 INDEX DIRECTORY 와 DATA DIRECTORY 디렉토리를 무시한다. 이 옵션은 슬레이브 리플
리케이션 서버에서 유용하다.
● NO_ENGINE_SUBSTITUTION
CREATE TABLE와 같은 명령문이 비활성화 되었거나 또는 컴파일 되지 않은 스토리지 엔진을 지정할 때, 디폴트 스토리
지 엔진으로 자동 대체 되는 것을 막는다. (MySQL 5.0.8에서 구현됨)
● NO_FIELD_OPTIONS
SHOW CREATE TABLE의 결과에 MySQL-특성 컬럼 옵션을 프린트 하지 않는다. 이 모드는 포터빌러티(portability)
모드에서 mysqldump에 의해 사용된다.
● NO_KEY_OPTIONS
SHOW CREATE TABLE의 결과에 MySQL-특성 인덱스 옵션을 프린트 하지 않는다. 이 모드는 포터빌러티
(portability) 모드에서 mysqldump에 의해 사용된다.
● NO_TABLE_OPTIONS
SHOW CREATE TABLE의 결과에 MySQL-특성 테이블 옵션(ENGINE와 같은)을 프린트 하지 않는다. 이 모드는 포
터빌러티(portability) 모드에서 mysqldump에 의해 사용된다.
● NO_UNSIGNED_SUBTRACTION
뺄셈 동작에서, 오퍼랜드(operand)중의 하나가 부호화 되지 않으면(unsigned) 그 결과를 UNSIGNED로 표시하지 않는

:::MySQL Korea:::
다. 이것은 BIGINT UNSIGNED 을 모든 문장에서 100% 사용 가능하도록 만들지 않는다는 것을 알아두기 바란다.
Section 12.8, “Cast Functions and Operators”를 참조할 것
● NO_ZERO_DATE
스트릭트 모드에서, '0000-00-00' 를 유효한 날짜 표시 방법으로 만들지 않는다. 여러분은 여전히 IGNORE 옵션을 사
용해서 제로 날짜를 입력할 수 있게 된다. 스트릭트 모드가 아닐 때에는, 이러한 날짜는 경고는 발생되기는 하지만 수용된
다. (MySQL 5.0.2에서 추가됨)
● NO_ZERO_IN_DATE
스트릭트 모드에서, 월 또는 날짜 부분이 0 인 날짜는 받아들이지 않는다. 만약에 IGNORE 옵션이 사용된다면, MySQL
은 '0000-00-00' 날짜를 이러한 날짜에 삽입한다. 스트릭트 모드가 아닌 경우에는, 이러한 날짜는 경로를 만들기는 하지
만 사용 가능하다. (MySQL 5.0.2에 추가됨)
● ONLY_FULL_GROUP_BY
GROUP BY 구문이 결과 컬럼 리스트에 존재 하지 않는 컬럼을 참조하기 위한 쿼리를 허용하지 않는다.
● PIPES_AS_CONCAT
Treat || 를 OR 에 대한 동의어가 아닌 스트링 연쇄(concatenation) 연산자로 다룬다.
● REAL_AS_FLOAT
REAL를 FLOAT에 대한 동의어로 다룬다. 디폴트로는, MySQL은 REAL을 DOUBLE의 동의어로 처리한다.
● STRICT_ALL_TABLES
모든 스토리지 엔진에 대해 스트릭트 모드를 활성화 시킨다. 유효하지 않은 데이터는 거절 된다. 추가적인 설명은 나중에
한다(MySQL 5.0.2에 추가됨)

:::MySQL Korea:::
● STRICT_TRANS_TABLES
논-트랜젝션 스토리지 엔진이 사용 가능할 때, 트랜젝션 스토리지 엔진에 대한 스트릭트 모드를 활성화 시킨다. 부가적인
설명은 나중에 한다. (MySQL 5.0.2에서 구현됨)
스트릭트 모드는 MySQL가 유효하지 않거나 누락된(missing) 데이터를 처리하는 방법을 제어한다. 하나의 값은 여러 가지 이유
로 유효하지 않게 된다. 예를 들면, 컬럼에 대해 틀린 데이터 타입을 가질 수가 있거나, 또는 범위를 벗어날 수도 있다. 삽입될 새로
운 줄이 확실한 DEFAULT 구문을 자신의 정의문안에 가지고 있지 않는 컬럼에 대한 값을 가지고 있지 않을 때 데이터는 누락되
게 된다.
트랜젝션 테이블에 대해서는, STRICT_ALL_TABLES 또는 STRICT_TRANS_TABLES 중의 하나의 모드가 활성화 될 때 명령

문안에 데이터가 유효하지 않거나 누락이 되면 에러가 발생하게 된다. 명령문은 중단되고 롤백(roll-back) 된다.
논-트랜젝션(non-transactional) 테이블에 대해서는, 만약에 삽입되어야 하거나 업데이트 되어야 하는 처음 줄에 유효하지 않은

값이 나오게 되면, 양쪽 모드에 대해서 동일한 결과를 만들게 된다. 명령문은 중단되고 테이블은 변경되지 않는 상태를 유지한다.
명령문이 여러 개의 줄을 삽입 또는 수정하고 유효하지 않은 값이 두 번째 또는 그 이후의 줄에 나타나게 되면, 그 결과는 어떤 스트
릭트 옵션이 활성화 되어 있는지에 따라 다르게 나온다:
● STRICT_ALL_TABLES에 대해서는, MySQL은 에러를 리턴 하고 나머지 줄들을 무시한다. 하지만, 이와 같은 경우에, 가

장 앞서 있는 줄들은 여전히 삽입 또는 업데이트가 되어져 있게 된다. 이것은 여러분이 부분적인 업데이트를 하게 된다는
것을 의미하며, 이런 상태를 원하지는 않았을 것이다. 이런 상황을 피하기 위해서는, 단일 줄 명령문을 사용하는 것이 최선
인데, 그 이유는 이러한 명령문은 테이블 변경 없이 중단될 수 있기 때문이다.
● STRICT_TRANS_TABLES에 대해서는, MySQL은 유효하지 않은 값 컬럼에 대해 가장 근접한 유효 값으로 변환 시킨 다
음에 이 값을 삽입한다. 데이터 값이 누락될 경우에는, MySQL은 컬럼 데이터 타입에 대한 암시적인(implicit) 디폴트 값
을 삽입하게 된다. 둘 중의 어느 경우에도, MySQL은 에러 메시지가 아닌 경고 메시지를 만들게 되며 명령문을 계속 처리
하게 된다. 암시적인(Implicit) 디폴트 값에 대해서는 Section 11.1.4, “Data Type Default Values”<

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.2.6. MySQL 서버 셧다운 프로세스
5. 데이터 베이스 관리 서버의 셧다운(shutdown) 프로세스는 다음과 같이 이루어 진다:

5.2.6 MySQL 서버 셧다운 프로세스 1. 셧다운 프로세스가 초기화 된다.

서버 셧다운은 여러 가지 방법으로 초기화 될 수 있다. 예를 들면, SHUTDOWN 권한을 가지고 있는 사용자는
mysqladmin shutdown 명령어를 실행 시킬 수가 있다. Mysqladmin은 MySQL이 지원하는 모든 플랫폼에서 사용할 수
있다. 다른 OS-특성 셧다운 초기화 방법도 역시 가능하다: 유닉스에서는 서버가 SIGTERM 신호를 받을 때 셧 다운된다.
윈도우에서 서비스 형태로 구동중인 서버는 서비스 관리자가 셧다운 하도록 요청할 때 셧다운 된다.
2. 서버는 필요할 경우에는 셧다운 쓰레드를 생성한다.
어떤 방식으로 셧다운이 초기화 되었는지에 따라, 서버는 셧다운 프로세스를 처리하기 위한 쓰레드를 생성할 수도 있다.
만약에 셧다운이 클라이언트의 요청으로 이루어 졌다면, 셧다운 쓰레드가 생성이 된다. 셧다운이 SIGTERM 신호를 받음
으로서 이루어 진 것이라면, 신호 쓰레드가 셧다운 자체를 처리하거나, 또는 이러한 일을 하기 위한 별도의 새로운 쓰레드
를 생성하게 된다. 만약에 서버가 셧다운 쓰레드를 생성하려고 시도는 하지만 생성할 수 없게 되면(예를 들면, 메모리 부족
으로 인해), 에러 로그에서 볼 수 있는 진단 메시지를 발생시키게 된다:
Error: Can't create thread to kill server
3. 서버는 새로운 접속 수용을 중단한다.

셧다운이 진행되는 동안 새로운 실행 동작이 이루어 지지 않게 하기 위해, 서버는 새로운 클라이언트 접속 수용을 중단하
게 된다. 서버는 네트워크의 접속을 차단함으로써 이러한 일을 처리한다: 유닉스에서는 TCP/IP 포트, 윈도우에서는 윈도
우 네임드 파이프와 공유 메모리.
4. 서버는 현재의 동작을 종료한다.
클라이언트 접속과 관련이 있는 각각의 쓰레드에 대해서는, 클라이언트에 대한 접속은 깨지게 되고 쓰레드는 킬드(killed)
로 표시가 된다. 쓰레드는 자신들이 이렇게 표시되는 것을 인지하게 되면 종료를 하게 된다. 아이들(idle)접속에 대한 쓰레

:::MySQL Korea:::
드는 재빠르게 종료된다. 명령문을 처리 중에 있는 쓰레드는 자신의 상태를 주기적으로 검사하고 종료를 하기 위해 시간

을 끌게 된다. 쓰레드 종료에 대한 보다 자세한 내용은 Section 13.5.5.3, “KILL 신텍스”에서 참고하기 바라며, 특히
MyISAM 테이블에서의 킬드(killed) REPAIR TABLE 또는 OPTIMIZE TABLE 동작에 대해서 참고를 하기 바란다.
열려 있는 트랜젝션을 가지고 있는 쓰레드에 대해서는, 쓰레드를 롤백 시켜버린다. 하나의 쓰레드가 논-트랜젝션 테이블
을 업데이트 한다면, 다중-줄 UPDATE 또는 INSERT와 같은 동작은 테이블이 부분적으로 업데이트 된 상태로 놔 두게
되는데, 그 이유는 동작을 완료하기 전에 중단이 되기 때문이다.
만약에 서버가 마스터 리플리케이션 서버일 경우에는, 현재 접속되어 있는 슬레이브와 관련된 쓰레드들은 다른 클라이언
트의 쓰레드처럼 취급된다. 즉, 각각의 쓰레드는 킬드(killed)로 표시 되고 각 쓰레드가 자신의 상태를 다음에 검사할 때
종료를 하게 된다.
서버가 슬레이브 리플리케이션 서버일 경우에는, I/O 와 SQL 쓰레드는, 만약에 활동 중이라면, 클라이언트 쓰레드가 킬드
로 표시되기 전에 마치게 된다. SQL 쓰레드는 자신의 현재 명령문을 끝까지 실행한 후에(리플리케이션 문제가 발생되는
것을 피하기 위해), 그 다음에 종료를 하게 된다. SQL 쓰레드가 이 시점에 트랜젝션의 중간에 있게 되면, 트랜젝션은 롤
백 된다.
5. 스토리지 엔진은 셧다운 되거나 닫히게 된다.
이 과정에서는, 테이블 캐시는 플러시 되고 모든 열려 있는 테이블은 닫히게 된다.
각 스토리지 엔진은 자신들이 관리하는 테이블에 대해 필요한 조치를 하게 된다. 예를 들면, MyISAM 은 테이블에 대한
모든 지연된 인덱스 쓰기를 프러시한다. InnoDB는 자신의 버퍼 풀의 내용을 디스크에 플러시하고 (5.0.5에서부터 구현
됨: innodb_fast_shutdown 이 2가 아닐 경우), 현재의 LSN 을 테이블스페이스에 쓰게 되고, 그리고 난 후에 자신의 내
부 쓰레드를 종료하게 된다.
6. 서버가 종료 된다.

:::MySQL Korea:::
제목검색
상위메뉴 5.3. mysqld-max 확장 MySQL 서버

MySQL-Max 서버는 여러 가지 다른 기능을 포함하고 있는 mysqld MySQL 서버의 버전이다. MySQL-Max 배포판을 사용할 수 있는 것은 여러분이 어떤 플랫폼을 사용하는지에 달려 있다:
리스트 ◆
5. 데이터 ● 윈도우의 경우, MySQL 바이너리 배포판은 표준 서버(mysqld.exe)와 MySQL-Max 서버(mysqld-max.exe)를 동시에 포함하고 있다. Section 2.3, “윈도우에 MySQL 설치하
베이스 관 기”를 참조.
리
● 리눅스의 경우, 만약에 MySQL을 RPM 배포판으로 설치한다면, MySQL-Max RPM 은 여러분이 이미 레귤러 서버 RPM을 설치해 놓았다고 추정을 한다. 우선, 레귤러 MySQL-
5.3. server RPM을 사용해서 mysqld를 설치한 다음에, MySQL-Max RPM을 사용해서 mysqld-max를 설치한다. Section 2.4, “리눅스에 MySQL 설치하기”를 참조.
mysqld-
● 다른 모든 MySQL-Max 배포판은 mysqld라는 이름의 단일 서버를 가지고 있지만 부가적인 기능들도 함께 포함되어 있다.
max 확
장
여러분은 MySQL-Max 바이너리 배포판을 http://dev.mysql.com/downloads/에서 얻을 수 있다.
MySQL
MySQL AB사는 MySQL-Max 서버를 아래와 같은 configure 옵션을 사용해서 구축하였다:
서버
5.3 mysqld-
● --with-server-suffix=-max
max 확장
MySQL
서버 이 옵션은 -max 접미사를 mysqld 버전 스트링에 추가한다.
● --with-innodb
이 옵션은 InnoDB 스토리지 엔진 지원을 활성화 시킨다. MySQL-Max 서버는 항상 InnoDB 지원을 포함하고 있다. MySQL 4.0 이후로 지금까지, InnoDB는 모든 바이너리 배포판에
디폴트로 포함되어 있기 때문에, 모든 MySQL-Max 서버는 별도의 InnoDB 지원을 가질 필요가 없게 된다.
● --with-bdb
이 옵션은 BDB를 사용하고 있는 플랫폼상의 버클리DB (BDB) 스토리지 엔진을 지원하도록 만든다.
● --with-blackhole-storage-engine
이 옵션은 BLACKHOLE 스토리지 엔진을 지원하도록 만든다.
● --with-csv-storage-engine

:::MySQL Korea:::
이 옵션은 CSV 스토리지 엔진을 지원하도록 만든다.
● --with-example-storage-engine
이 옵션은 EXAMPLE 스토리지 엔진을 지원하도록 만든다.
● --with-federated-storage-engine
이 옵션은 FEDERATED 스토리지 엔진을 지원하도록 만든다.
● --with-ndbcluster
이 옵션은 클러스터가 사용중에 있는 플랫폼상의 NDB Cluster 스토리지 엔진을 지원하도록 만든다.
● USE_SYMDIR
이것은 윈도우를 지원하기 위한 데이터 베이스 심볼릭 링크를 구동시킨다. 4.0 이후로는, 심볼릭 링크 지원은 모든 윈도우 서버를 지원하고 있기 때문에, MySQL-Max 서버는 이것을
사용할 필요가 없다.
MySQL-Max 바이너리 배포판은 미리 컴파일된 프로그램을 사용하고자 하는 사용자들에게는 매우 편리한 제품이다. 만약에 여러분이 소스 배포판을 사용해서 MySQL을 구축하고자 한다면,
서버 구성시에 MySQL-Max 바이너리 배포판이 가지고 있는 특징과 동일한 것들을 활성화 시킴으로서 MySQL-Max 서버와 비슷하게 MySQL 서버를 스스로 구축할 수도 있다
MySQL-Max 서버에는 BerkeleyDB (BDB) 스토리지 엔진이 포함되어 있으나, 모든 플랫폼이 BDB를 지원하는 것은 아니다.
현재, MySQL 클러스터는 리눅스(대부분의 플랫폼), Solaris, Mac OS X, 그리고 HP-UX만 지원하고 있다. 몇몇 사용자들이 소스 코드를 사용해서 BSD OS에 MySQL 클러스터를 성공적으
로 설치하였다고 보고하였으나, 아직까지는 공식적으로는 지원을 하지 않고 있다. 서버가 클러스터를 지원하게끔 컴파일 되었다고 하더라도, NDB Cluster 스토리지 엔진은 디폴트로는 활성화
되지 않는다는 점을 알아두기 바란다. 여러분은 서버를 --ndbcluster 옵션을 사용해서 구동 시켜서 이것이 MySQL 클러스터의 일부분으로 사용하도록 만들어 주어야 한다. (자세한 내용은,
Section 15.4, “MySQL 클러스터 구성”을 참조할 것.)
아래의 테이블은 BDB 와 NDB Cluster를 지원하는 MySQL-Max 바이너리 배포판에 대한 플랫폼을 보여주고 있다.
System BDB Support NDB Support
AIX 5.2 N N
HP-UX Y Y
Linux-IA-64 N Y
Linux-Intel Y Y
Mac OS X N Y
NetWare N N

:::MySQL Korea:::
SCO 6 N N
Solaris-SPARC Y Y
Solaris-Intel N Y
Solaris-AMD 64 Y Y
Windows NT/2000/XP Y N
여러분의 서버가 지원하는 스토리지 엔진이 어떤 것인지 확인하기 위해서는, SHOW ENGINES 명령문을 사용한다. (Section 13.5.4.10, “SHOW ENGINES 신텍스”를 참조.) 예를 들면:
mysql> SHOW ENGINES￦G
*************************** 1. row ***************************
Engine: MyISAM
Support: DEFAULT
Comment: Default engine as of MySQL 3.23 with great performance
*************************** 2. row ***************************
Engine: MEMORY
Support: YES
Comment: Hash based, stored in memory, useful for temporary tables
*************************** 3. row ***************************
Engine: InnoDB
Support: YES
Comment: Supports transactions, row-level locking, and foreign keys
*************************** 4. row ***************************
Engine: BerkeleyDB
Support: NO
Comment: Supports transactions and page-level locking
*************************** 5. row ***************************
Engine: BLACKHOLE
Support: YES

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.4. MySQL 서버 스타트업 프로그램

5.4.1. mysqld_safe — MySQL 서버 스타트업 스크립트
5. 데이터 베이스 관리 5.4.2. mysql.server — MySQL 서버 스타트업 스크립트
5.4. MySQL 서버 스타트업 프로그램 5.4.3. mysqld_multi — 다중 MySQL 서버 관리
5.4 MySQL 서버 스타트업 프로그램 이 섹션에서는 MySQL 서버인 mysqld을 구동 시키는데 사용되는 몇 가지 프로그램에 대해 설명을 하기로 한
5.4.1 mysqld_safe — MySQL 서버 스타트업 스크립트 다.
5.4.2 mysql.server — MySQL 서버 스타트업 스크립트

5.4.3 mysqld_multi — 다중 MySQL 서버 관리
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.4.1. mysqld_safe — MySQL 서버 스타트업 스크립트
5. 데이터 베이스 관리 mysqld_safe는 유닉스와 넷웨어에서 mysqld 서버를 구동 시키는 권장 방법이다. mysqld_safe는 에러가 발생했을 때 서버를 재
5.4. MySQL 서버 스타트업 프로그램 구동 시키고 런타임 정보를 에러 로그에 기록하는 것과 같은 안전 기능을 추가로 가지고 있다. NetWare-특성 동작은 이 섹션 후
5.4.1 mysqld_safe — MySQL 서버 스타트업 스 반부에서 다시 하기로 한다.

크립트
Note: MySQL의 이전 구형 버전들과의 호환성을 유지하기 위해서, MySQL 바이너리 배포판은 여전히 mysqld_safe에 대한 심볼
릭 링크로서 safe_mysqld를 포함하고 있다. 하지만, 이 기능은 향후에 완전히 삭제될 예정이므로 이것에 의존하지 말길 바란다.
디폴트로, mysqld_safe는 mysqld-max가 존재하면 이것을 시작할려고 시도하며, 존재하지 않으면 mysqld를 시도한다. 이러한
동작 구현에 대해서는 잘 숙지해야 한다:
● 리눅스에서는, MySQL-Max RPM은 이 mysqld_safe의 동작에 의존한다. RPM 은 mysqld-max를 설치하는데, 이것은
mysqld가 아닌 mysqld_safe를 자동으로 실행 가능하도록 사용한다.
● 여러분이 mysqld-max 라는 이름의 서버를 포함하고 있는 MySQL-Max 배포판을 설치했고, 그 다음에 MySQL의 non-
Max으로 업그레이드를 했다면, mysqld_safe 는 여전히 mysqld-max 서버를 구동 시키려는 시도를 할 것이다. 만약에 여
러분이 이러한 업그레이드를 했다면, 수동으로 구형 mysqld-max를 삭제해서 mysqld_safe 가 새로운 mysqld 서버를 구
동 시키게끔 해야 한다.
디폴트 동작을 없애고 여러분이 원하는 서버의 이름을 명확하게 지정하기 위해서는, --mysqld 또는 --mysqld-version 옵션
을 mysqld_safe에 지정한다. 또한 –ledir를 사용해서 mysqld_safe가 서버를 찾는 디렉토리를 지정하도록 할 수도 있다.
mysqld_safe에 대한 많은 옵션들은 mysqld에 대한 옵션들과 모두 동일하다. Section 5.2.1, “mysqld 명령어 옵션”을 참조할
것.
명령어 라인에서 mysqld_safe에 지정되는 모든 옵션들은 mysqld에 패스 된다. 만약에 mysqld_safe에만 해당되고 mysqld은 지
원하지 않는 옵션을 사용하고자 한다면, 명령어 라인에서 그것들을 지정하지 않으면 된다. 대신에, 옵션 파일 그룹의

:::MySQL Korea:::
[mysqld_safe] 안에 그 옵션들을 올려 놓는다. Section 4.3.2, “옵션 파일 사용하기”를 참조할 것.
mysqld_safe는 옵션 파일의 [mysqld], [server], 그리고 [mysqld_safe] 섹션에서 모든 것을 읽는다. 이전 버전과의 호환성을 위
해서, 여러분이 5.0 설치시에 [safe_mysqld] 섹션을 [mysqld_safe] 로 재 명영했다고 하더라도 이 섹션도 함께 읽게 된다.
mysqld_safe는 아래의 옵션들을 지원한다:
● --help
도움말 메시지를 디스플레이한 다음에 빠져 나온다.( MySQL 5.0.3에 추가 됨)
● --autoclose
(NetWare에만 해당됨) NetWare상에서는, mysqld_safe은 스크린 존재(presence)를 제공한다. 여러분이

mysqld_safe NLM를 셧다운 하면, 스크린은 디폴트로 사라지지 않는다. 대신에 사용자 입력용 프롬프트를 보여준다:
*<NLM has terminated; Press any key to close the screen>*
만약에 NetWare가 자동으로 스크린을 닫게 할려면, --autoclose옵션을 mysqld_safe에 사용한다.
● --basedir=path
MySQL 설치 디렉토리 경로.
● --core-file-size=size
mysqld가 생성하는 코어(core) 파일의 크기. 옵션값은 ulimit –c에 전달 된다.
● --datadir=path
데이터 디렉토리의 경로.

:::MySQL Korea:::
● --defaults-extra-file=path
일반적인 옵션 파일에 추가하여 읽혀 지는 옵션 파일의 이름. 이것이 사용될 경우에는 반드시 명령어 라인 처음에 나와야
한다.
● --defaults-file=file_name
일반적인 옵션 파일 대신에 읽혀 지는 옵션 파일의 이름. 만약에 사용될 경우에는명령어 라인의 첫 번째 옵션이 되어야 한
다.
● --ledir=path
mysqld_safe가 서버를 찾지 못할 경우, 이 옵션을 사용하여 서버가 저장되어 있는디렉토리의 경로 이름을 표시한다.
● --log-error=file_name
에러 로그를 주어진 파일에 기록한다. Section 5.12.1, “에러 로그”를 참조.
● --mysqld=prog_name
여러분이 시작하고자 하는 서버 프로그램의 이름(ledir 디렉토리에 있음. 이 옵션은여러분이 바이너리 배포판을 사용하고
있지만 데이터 디렉토리가 바이너리 배포판이 아닌 곳에 있는 경우에 필요하게 된다. 만약에 mysqld_safe가 서버를 찾지
못할 경우, --ledir 옵션을 사용해서 서버가 저장되어 있는 디렉토리의 경로 이름을 표시하도록 한다.
● --mysqld-version=suffix
이 옵션은 --mysqld 옵션과 비슷하지만, 여러분은 서버 프로그램 이름에 대한접미사만 지정하면 된다. 베이스 이름은
mysqld라고 여겨진다. 예를 들면, --mysqld-version=max를 사용한다면, mysqld_safe는 ledir 디렉토리에 있는
mysqld-max 프로그램을 구동 하기 시작한다. --mysqld-version에 대한 인수가 비어 있다면, mysqld_safe는 ledir
디렉토리에 있는 mysqld를 사용한다.
● --nice=priority

:::MySQL Korea:::
주어진 값에 대한 서버의 스케쥴링 우선 순위를 설정하기 위해 nice 프로그램을사용한다.
● --no-defaults
어떠한 옵션 파일도 읽지 않는다. 만약에 이것이 사용될 경우에는 명령어 라인에서첫 번째 옵션이 되어야 한다.
● --open-files-limit=count
mysqld가 열 수 있는 파일의 숫자. 옵션 값은 ulimit –n에 전달 된다. 이것이 올바르게 동작을 하기 위해서는 root로
mysqld_safe를 구동 시켜야 한다!
● --pid-file=file_name
프로세스 ID 파일의 경로 이름.
● --port=port_num
서버가 TCP/IP 접속을 기다릴 때 사용하는 포트 번호. 포트 번호는 서버가 root 시스템 사용자로 구동되지 않는 한 반드
시 1024 또는 그 이상 이어야 한다.
● --socket=path
서버가 로컬 접속을 기다릴 때 사용하는 유닉스 소켓 파일.
● --timezone=timezone
주어진 옵션 값에 TZ 타임 존 환경 변수를 설정한다. 올바른 타임 존 지정 포맷에대해서는 OS 문서를 참고한다.
● --user={user_name | user_id}
user_name 이름 또는 숫자로 된 사용자 ID user_id를 갖고 있는 사용자로서 mysqld 서버를 구동 시킨다. (여기에서

:::MySQL Korea:::
“사용자(User)”는 시스템 계정을 참조한 것을 의미하며, 그랜트 테이블안에 있는 MySQL 사용자를 가리키는 것은 아
니다.)
옵션 파일에 이름을 주기 위해 --defaults-file 또는 --defaults-extra-option 옵션을 가지고 mysqld_safe 를 실행한다면, 옵

션은 반드시 명령어 라인에서 첫번째로 주어져야 한다. 그렇지 않으면 옵션은 사용되지 않는다. 예를 들면, 이 명령어는 네임드 옵
션 파일을 사용하지 않게 된다:
mysql> mysqld_safe --port=port_num --defaults-file=file_name
대신에, 아래의 명령어를 사용한다:
mysql> mysqld_safe --defaults-file=file_name --port=port_num
mysqld_safe 스크립트는 보통은 소스 또는 바이너리 배포판을 설치한 서버를 구동 시킬 수 있도록 작성된다. (Section 2.1.5,
“설치 레이 아웃”을 참조할 것.) mysqld_safe는 아래의 조건들 중에 하나가 트루(true)일 것으로 기대한다:
● 서버와 데이터 베이스는 동작하고 있는 디렉토리에 관련되어 찾게 된다 ( mysqld_safe를 호출한 디렉토리에서). 바이너
리 배포판의 경우, mysqld_safe는 자신의 동작 디렉토리 밑에서 bin 과 data 디렉토리를 찾는다. 소스 배포판의 경우,
libexec 와 var 디렉토리를 찾게 된다. 이 조건은 만약에 여러분이 MySQL설치 디렉토리에서 mysqld_safe를 실행 시킨다
면 일치하게 된다 (예를 들면, 바이너리 배포판의 경우 /usr/local/mysql).
● 만약에 서버와 데이터 베이스가 동작중에 있는 디렉토리와 관련되어 찾지 못하게 되면, mysqld_safe는 이것들을 절대 경
로 이름(absolute pathname)을 가지고 저장 시키려고 한다. 전형적인 위치는 /usr/local/libexec 과 /usr/local/var가 된
다. 실제 위치는 배포판이 설치되는 시점에 구성된 값을 가지고 결정된다. 이것들은 만약에 MySQL이 서버 구성시에 지정
된 위치에 설치되어져 있다면 트루(true)가 된다.
Because mysqld_safe는 자신의 동작 디렉토리에 관련하여 서버와 데이터 베이스를 찾으려고 시도하기 때문에, 여러분은
MySQL 설치 디렉토리에서 mysqld_safe를 구동 시키는 한 바이너리 배포판을 어디에도 설치할 수가 있게 된다:
shell> cd mysql_installation_directory
shell> bin/mysqld_safe &

:::MySQL Korea:::
만약에 mysqld_safe가 실패하면, 비록 MySQL 설치 디렉토리에서 호출을 한 경우에라도, 여러분은 --ledir 와 --datadir 옵션
을 지정해서 서버와 데이터 베이스가 저장되어 있는 디렉토리를 가리키도록 할 수 있다.
보통의 경우에는, 여러분은 mysqld_safe 스크립트는 수정하지 말아야 한다. 대신에, my.cnf 옵션 파일의 [mysqld_safe]섹션에
있는 옵션 또는 명령어 라인의 옵션을 사용해서 mysqld_safe를 구성한다. 드문 경우이긴 하지만, mysqld_safe를 직접 편집을 해
서 서버가 올바르게 구동되도록 해야할 경우도 있긴 하다. 하지만, 이렇게 하게 되면, 여러분이 수정한 mysqld_safe이 나중에
MySQL을 업그레이드 할 때 없어지기 때문에, 복사본을 마리 만들어 두어야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.4.2. mysql.server — MySQL 서버 스타트업 스크립트
5. 데이터 베이스 관리
5.4. MySQL 서버 스타트업 프로그램 유닉스상의 MySQL 배포판은 mysql.server라는 이름의 스크립트를 가지고 있다. 이것은 시스템 서비스를 시작/종료 하는
5.4.2 mysql.server — MySQL 서버 스타트업 스크립트 시스템-V 형태의 구동 디렉토리(System V-style run directory)를 사용하는 리눅스와 솔라리스와 같은 시스템에서 사용
된다. 이것은 또한 MySQL을 위한 Mac OS X 스타트업 아이템에 의해서도 사용된다.
mysql.server는 여러분의 MySQL 설치 디렉토리 아래에 있는 support-files 디렉토리 또는 MySQL 소스 배포판에서도

찾을 수 있다.
여러분이 리눅스 서버 RPM 패키지 (MySQL-server-VERSION.rpm)를 사용한다면, mysql.server 스크립트는 mysql라

는 이름을 가지고 /etc/init.d 디렉토리에 설치될 것이다. 여러분은 이것을 수동으로 설치할 필요는 없다. Section 2.4, “리
눅스에 MySQL 설치하기”를 참조할 것.
몇몇 벤더들은 mysqld와 같은 다른 이름 아래에 스타트업 스크립트를 설치하는 RPM 패키지를 제공한다
여러분이 소스 배포판을 사용하거나 또는 자동으로 mysql.server를 설치하지 않는 바이너리 배포판을 사용해서 MySQL을
설치한다면, 여러분은 이것을 수동으로 설치해야 한다. 설치 설명서는 Section 2.9.2.2, “자동으로 MySQL 시작하기 및 종
료하기”를 참조할 것.
mysql.server는 옵션 파일의 [mysql.server] 와 [mysqld] 섹션에서 옵션을 읽는다. 이전 버전과의 호환성을 위해서,
[mysql_server] 섹션도 함께 읽게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.4.3. mysqld_multi — 다중 MySQL 서버 관리
5. 데이터 베이스 관리 mysqld_multi는 다른 유닉스 소켓 파일과 TCP/IP 포트상에서 접속을 기다리는 mysqld 프로세스를 관리하기 위해 디자인 된 것
5.4. MySQL 서버 스타트업 프로그램 이다. 이것은 서버를 시작 또는 종료할 수 있으며, 또는 서버의 현재 상태를 보고할 수도 있다. MySQL 인스턴스 매니저는 다중 서
5.4.3 mysqld_multi — 다중 MySQL 서버 관리 버를 관리하는 것을 달리 의미하는 용어다. (Section 5.5, “mysqlmanager — MySQL 인스턴스 매니저”를 참조할 것).
mysqld_multi 는 my.cnf (또는 --config-file 옵션으로 이름 붙여진 파일)에서 [mysqldN]라는 이름의 그룹을 검색한다. N 는
모든 양수 정수가 될 수 있다. 이 번호는 다음의 섹션에서 옵션 그룹 번호 또는 GNR로 참조될 것이다. 그룹 번호는 각 그룹을 구분
하며 여러분이 시작, 종료, 또는 상태 레포트를 받고자 원하는 서버가 어떤 것인지를 지정하기 위한 mysqld_multi의 인수로서 사용
된다. 이러한 그룹내에 열거되어 있는 옵션들은 mysqld를 구동시키기 위해 사용하는 [mysqld] 그룹내에서 사용하는 것과 동일
한 것들이다. (Section 2.9.2.2, “자동으로 MySQL 시작하기 및 종료하기”를 참조할 것.) 하지만, 다중 서버를 사용할 때에는, 각
자의 서버는 유닉스 소켓 파일 및 TCP/IP 포트 번호와 같은 것에 대해 자신만의 옵션 값을 가지는 것이 필요하다. 다중 서버 환경
에서 서버별로 고유의 값을 가져야만 하는 옵션이 어떤 것이 있는지에 대한 보다 자세한 정보는 Section 5.13, “동일 서버에서 다
중의 MySQL서버 구동 시키기”를 참조할 것.
mysqld_multi를 호출하기 위해서는, 아래의 신텍스를 사용한다:
shell> mysqld_multi [options] {start|stop|report} [GNR[,GNR] ...]
start, stop, 그리고 report는 수행되야할 동작을 가리키는 것이다. 여러분은 옵션 이름 다음에 나오는 GNR 리스트에 따라서, 단
일 서버 또는 다중 서버에 대한 지정 동작을 실행을 할 수가 있게 된다. 만약에 리스트가 없는 경우에는, mysqld_multi는 옵션 파일
에 있는 모든 서버에 대한 동작을 실행하게 된다.
각각의 GNR 값은 옵션 그룹 번호 또는 그룹 번호의 범위를 나타낸다. 그 값은 옵션 파일에 있는 그룹 이름의 맨 끝에 있는 번호이

어야 한다. 예를 들면, [mysqld17]의 GNR 는 17이 된다. 번호의 범위를 지정하기 위해서는, 처음 번호와 마지막 번호 사이에 대시
를 넣어서 구분한다. GNR 값 10-13은 그룹 [mysqld10]에서 [mysqld13]를 표시한다. 다중 그불 또는 그룹 범위는 명령어 라인
에서 지정할 수 있는데, 콤마로 구분을 한다. GNR 리스트에는 화이트스페이스 문자(스테이스또는 탭)이 있으면 안된다; 화이트 스

:::MySQL Korea:::
페이스 다음에 오는 모든 문자는 무시된다.
아래의 명령어는 옵션 그룹 [mysqld17]를 사용햇 단일 서버를 시작하게 한다:
shell> mysqld_multi start 17
아래의 명령어는 옵션 그룹 [mysqld8]와 [mysqld10]에서 [mysqld13]까지를 사용해서 여러대의 서버를 종료한다:
shell> mysqld_multi stop 8,10-13
여러분이 옵션 파일을 설정하는 방법에 대한 예를 보자면, 아래의 명령어를 사용한다:
shell> mysqld_multi --example
mysqld_multi는 아래의 옵션을 지원한다:
● --help
도움말 메시지를 디스플레이한 후에 빠져 나온다.
● --config-file=name
대신 사용할 옵션 파일의 이름을 지정한다. 이것은 mysqld_multi이 [mysqldN] 옵션 그룹을 어디에서 찾을지를 알려준
다. 이 옵션 파일이 없으면, 모든 옵션은 일반적인 my.cnf 파일에서 읽혀 진다. 이 옵션은The option does not affect
where mysqld_multi가 자신의 옵션을 어디에서 읽을 지에 대해서는 알려주지 않는데, 이것은 항상 일반적인 my.cnf 파
일 안에 있는 [mysqld_multi] 그룹에서 얻어진다.
● --example
샘플 옵션 파일을 디스플레이 한다.
● --log=file_name

:::MySQL Korea:::
로그 파일의 이름을 지정한다. 파일이 존재한다면, 로그 결과(log output)가 뒤에 붙게 된다.
● --mysqladmin=prog_name
서버를 종료하기 위해 사용되는 mysqladmin 바이너리.
● --mysqld=prog_name
사용되는 mysqld 바이너리. 이 옵션을 위한 값으로서 mysqld_safe도 함께 지정할수 있다는 것을 알아두기 바란다. 만약
에 mysqld_safe를 사용햇 서버를 구동 시켰다면, 여러분은 [mysqldN] 옵션 그룹에 상응하여 mysqld 또는 ledir 옵션들
을 포함 시킬 수가 있게 된다. 이러한 옵션들은 mysqld_safe이 구동 시켜야 하는 서버의 이름과 서버가 저장되어 있는 디
렉토리의 경로 이름을 가리킨다. (Section 5.4.1, “mysqld_safe — MySQL 서버 스타트업 스크립트”를 참조.)
예제:
[mysqld38]
mysqld = mysqld-max
ledir = /opt/local/mysql/libexec
● --no-log
로그 파일이 아닌 stdout에 로그 정보를 프린트 한다. 디폴트로, 결과치(output)가 로그 파일로 가게 된다.
● --password=password
mysqladmin을 호출할 때 사용되는 MySQL 계정의 패스워드. 다른 MySQL 프로그램과는 달리, 이 옵션에 대한 패스워
드 값은 필수 사항이 된다.
● --silent

:::MySQL Korea:::
사일런트(Silent) 모드; 경고문을 비활성화 시킴.
● --tcp-ip
각각의 MySQL 서버를 유닉스 소켓 파일 대신에 TCP/IP 포트를 통해 접속 시킴. (만약에 소켓 파일이 누락되어 있으면,
서버는 여전히 동작은 하겠지만, TCP/IP 포트만을 통해서만 접근할 수 있게 된다.) 디폴트로는, 유닉스 소켓 파일을 통해
서 접속이 이루어 진다. 이 옵션은 stop 과 report 동작에 영향을 준다.
● --user=user_name
mysqladmin을 호출할 때 사용하는 MySQL 계정의 사용자 이름
● --verbose
좀더 장황하게 표현하도록 한다.
● --version
버전 번호를 보여주고 빠져 나온다.
mysqld_multi에 대해서 몇가지 노트가 있다:
● Most important: mysqld_multi를 사용하기 전에, 여러분은 mysqld 서버에 패스되는 옵션의 의미와 개별적인 mysqld 프
로세스를 가져야 하는 이유가 무엇인지를 정확히 알아야 한다. 동일한 데이터 디렉토리를 갖는 다중 mysqld 서버의 사용
은 위험하다는 것을 알기 바란다. 여러분이 무엇을 하고 있는지 정확히 알지 못할 경우에는. 데이터 디렉토리를 구분해서
사용하기 바란다. 동일한 데잍 디렉토리를 가지고 여러대의 서버를 구동 시키는 것은 쓰레드 시스템에서는 아무런 성능의
효과를 얻을 수가 없다. Section 5.13, “동일 머신에서 다중 MySQL 서버 구동하기”를 참조.
● Important: 각 서버에 대한 데이터 디렉토리는 특정 mysqld 프로세스가 구동되는 시스템의 전체 유닉스 계정이 접근 가능
하다는 것을 알아두기 바란다. 여러분이 무엇을 하고 있는지 정확히 알지 못할 경우에는, 이렇게 동작 시키기 위해서 유닉
스 root 계정을 사용하지 말기 바란다. Section 5.7.5, “일반 사용자로서 MySQL 구동 시키기”를 참조.
● mysqld 서버를 종료 시키기(mysqladmin 프로그램을 사용해서) 위해 사용하는 MySQL 계정은, 각 서버에 대해 동일한
사용자 이름과 패스워드를 가지고 있다는 점을 알아 두기 바란다. 또한, 그 계정은 SHUTDOWN 권한을 가지고 있어야 한

:::MySQL Korea:::
다. 만약에 여러분이 관리하고자 하는 서버가 관리 계정에 대해 서로 다른 사용자 이름 또는 패스워드를 가지고 있다면, 여

러분은 각 서버상에 동일한 사용자 이름과 패스워드를 가지고 있는 계정을 만들 필요가 있다. 예를 들면, 각 서버에 대해 아
래의 명령어를 실행해서 공통의 multi_admin 계정을 설정할 수가 있다:
• shell> mysql -u root -S /tmp/mysql.sock -p
• Enter password:
• mysql> GRANT SHUTDOWN ON *.*
• -> TO 'multi_admin'@'localhost' IDENTIFIED BY 'multipass';
Section 5.8.2, “권한 시스템이 어떻게 동작을 하는가”를 참조. 여러분은 각각의 mysqld에 대해 이러한 조치를 해야 한
다. 각각을 연결할 때에 접속 파라미터의 값을 적당히 변경한다. 계정 이름의 호스트 이름 부분은 반드시 여러분이 구동 시
키고자 하는 mysqld_multi가 있는 호스트에서 multi_admin를 접속할 수 있게 해 주어야 한다.
● 유닉스 소켓 파일과 TCP/IP 포트 번호는 모든 mysqld에 대해 반드시 달라야 한다.

● --pid-file 옵션은, 만약에 여러분이 mysqld_safe를 사용(예를 들면, --mysqld=mysqld_safe)해서 mysqld를 구동
시킨다면, 매우 중요한 것이 된다. 모든 mysqld은 자신의 고유 프로세스 ID 파일을 가지고 있어야 한다. The advantage
of using instead of mysqld 대신에 mysqld_safe를 쓰는 장점은, mysqld_safe 은 자신의 mysqld 프로세스를 모니터 하
면서 만약에 프로세스가 kill -9을 사용하는 신호 또는 세그먼트 폴트(fault)와 같은 다른 이유로 종료될 경우에, 재 구동
을 시킨다는 것이다. mysqld_safe 스크립트는 여러분이 특정 위치에서 서버를 시작하도록 요구한다는 것을 주의하기 바란
다. 이것은 여러분이 mysqld_multi를 구동 시키기 전에 특정 디렉토리로 위치를 변경해야 한다는 것을 의미한다. 만약에
서버 구동에 문제가 있을 경우에는, mysqld_safe 스크립트를 살펴 보기 바란다. 특히 아래의 라인을 주의 깊게 검사한다:
• ------------------------------------------------------------
• MY_PWD=`pwd`
• # Check if we are starting this relative (for the binary release)
• if test -d $MY_PWD/data/mysql -a -f ./share/mysql/english/errmsg.sys -a ￦

:::MySQL Korea:::
• -x ./bin/mysqld
• ------------------------------------------------------------
이 라인이 수행하는 테스트는 성공을 해야 하는데, 그렇지 않을 경우에는 문제가 생기게 된다. See Section 5.4.1,
“mysqld_safe — MySQL 서버 스타트업 스크립트”을 참조.
● 여러분은 mysqld을 위해 --user 옵션을 사용하고자 하겠지만, 이렇게 하기 위해서는 유닉스 root 사용자로서
mysqld_multi 스크립트를 구동 시킬 필요가 있다. 옵션 파일에 옵션을 가지고 있는 것은 아무 문제가 없다; 여러분이 슈퍼
유저가 아니고 mysqld 프로세스가 여러분 자신의 유닉스 계정 아래에서 시작될 경우에는 단지 경고만 받게 된다.
아래의 예제에서는 여러분이 mysqld_multi를 가지고 옵션 파일을 어떻게 설정을 하는지를 보여 주고 있다. mysqld 프로그램이 시
작되거나 또는 종료하는 순서는 옵션 파일에 어떤 순서로 되어 있는지에 달려 있다. 그룹 번호는 깨지지 않는 시퀀스(unbroken
sequence)를 구성하는데 필요 없다. 첫 번째와 다섯 번째의 [mysqldN] 그룹은 이 예제에서는 의도적으로 생략 되었는데, 이것은
여러분이 옵션 파일에서 “갭(gap)”을 가질 수 있음을 알려 주기 위해서이다. 이것은 여러분에게 보다 많은 유연성을 제공한다.
# This file should probably be in your home dir (~/.my.cnf)
# or /etc/my.cnf
# Version 2.1 by Jani Tolonen
[mysqld_multi]
mysqld = /usr/local/bin/mysqld_safe
mysqladmin = /usr/local/bin/mysqladmin
user = multi_admin

:::MySQL Korea:::
password = multipass
[mysqld2]
socket = /tmp/mysql.sock2
port = 3307
pid-file = /usr/local/mysql/var2/hostname.pid2
datadir = /usr/local/mysql/var2
language = /usr/local/share/mysql/english
user = john
[mysqld3]
port = 3308
language = /usr/local/share/mysql/swedish

:::MySQL Korea:::
user = monty
[mysqld4]
port = 3309
language = /usr/local/share/mysql/estonia

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.5. mysqlmanager — MySQL 인스턴스 관리자
5. 데이터 베이스 관리 5.5.1. MySQL 인스턴스 관리자를 가지고 MySQL 서버 구동하기

5.5. mysqlmanager — MySQL 인스턴스 관리자 5.5.2. MySQL 인스턴스 관리자에 접속하기와 사용자 계정 생성하기
5.5 mysqlmanager — MySQL 인스턴스 관리자 5.5.3. MySQL 인스턴스 관리자 명령어 옵션
5.5.1 MySQL 인스턴스 관리자를 가지고 MySQL 서버 구동하기 5.5.4. MySQL 인스턴스 관리자 구성 파일
5.5.2 MySQL 인스턴스 관리자에 접속하기와 사용자 계정 생성하기 5.5.5. MySQL 인스턴스 관리자가 인식하는 명령어

mysqlmanager 는 MySQL 인스턴스 관리자 (IM)이다. 이 프로그램은 TCP/IP 포트에서 구동하면서 MySQL 데
이터 베이스 서버 인스턴스를 모니터 하고 관리하는 데몬(deamon)이다. MySQL 인스턴스 관리자는 유닉스와
5.5.3 MySQL 인스턴스 관리자 명령어 옵션
유사한 OS에서는 사용 가능하며, MySQL 5.0.13 이후에는 윈도우에서도 역시 사용 가능해 졌다.
5.5.4 MySQL 인스턴스 관리자 구성 파일
MySQL 인스턴스 관리자는 5.0.3 이후에 MySQL 배포판에 포함되었으며, 리모트 서버일 경우라도 MySQL 서버
5.5.5 MySQL 인스턴스 관리자가 인식하는 명령어
를 시작하고 종료하기 위해 mysqld_safe 스크립트를 대신해서 사용할 수가 있다. MySQL 인스턴스 관리자는 또
한 mysqld_multi 스크립트의 기능(그리고 대부분의 신텍스)을 구현한다. MySQL 인스턴스 관리자에 대한 보다
자세한 설명은 아래와 같다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.5.1. MySQL 인스턴스 관리자를 가지고 MySQL 서버 구동하기

일반적으로, mysqld MySQL 데이터 베이스 서버는 mysql.server 스크립트와 함께 시작되는데, 이것은 일반적으
5. 데이터 베이스 관리 로 /etc/init.d/ 폴더 안에 상주한다. MySQL 5.0.3에서는, 이 스크립트는mysqlmanager (MySQL 인스턴스 관리자
5.5. mysqlmanager — MySQL 인스턴스 관리자 바이너리)를 호출하여 MySQL을 구동 시킨다. (MySQL의 이전 버전에서는, mysqld_safe 스크립트가 이 역할을 했
5.5.1 MySQL 인스턴스 관리자를 가지고 MySQL 서버 구동하기 다.) MySQL 5.0.4 이후에는, init 스크립트의 역할이 양쪽 설정 스키마를 통합하게끔 다시 변경 되었다. 5.0.4에서
는, init 스타트업 스크립트는 디폴트로 구형 스키마(mysqld_safe를 호출하는 스키마)를 사용하지만, 스크립트에 있
는 use_mysqld_safe 변수를 0(zero)로 설정해서 MySQL 인스턴스 관리자를 사용해서 서버를 구동하게끔 할 수가
있다.
이와 같은 경우에 있는 인스턴스 관리자는 MySQL 구성 파일에 주어진 옵션에 따라 동작을 한다. 만약에 구성 파일
이 존재하지 않으면, MySQL 인스턴스 관리자는 creates a server instance named mysqld이라는 이름의 서버 인
스턴스를 생성하게 되며, 디폴트 구성 값을 가지고 서버를 시작하려고 시도한다. 이것은 만약에 mysqld이 디폴트 위
치에 저장되어 있지 않다면, IM은 mysqld 의 저장 위치를 추정하지 못한다는 것을 의미한다. 만약에 여러분이
MySQL 서버를 표준 위치가 아닌 곳에 설치를 하였다면, 여러분은 구성 파일을 사용해야만 한다. Section 2.1.5,
“설치 레이 아웃”을 참조.
구성 파일이 존재한다면, IM은 [mysqld] 섹션(예를 들면, [mysqld], [mysqld1], [mysqld2], 등등)을 찾기 위해
이것을 읽게 된다. 이러한 섹션들 각각은 인스턴스를 지정한다. 인스턴스 관리자가 시작될 때, IM은 자신이 발견하
는 모든 서버 인스턴스를 시작하려고 시도한다. 디폴트로, IM은 자신이 셧다운될 때 모든 서버 인스턴스를 종료한
다.
IM에 의해서만 인식되는 특별한 --mysqld-path=path-to-mysqld-binary 옵션이 있다는 것을 알아두기 바란

다. 이 변수를 사용해서 IM으로 하여금 mysqld 바이너리가 상주해 있는 곳을 알도록 할 수 있다. 여러분은 서버를
위해 basedir과 datadir 옵션을 설정할 수도 있다.
활성화 된 MySQL 인스턴스 관리자를 가진 MySQL 서버를 위한 전형적인 스타트업/셧다운 사이클은 다음과 같다:

:::MySQL Korea:::
1. MySQL 인스턴스 관리자는 /etc/init.d/mysql 스크립트와 함께 구동된다.

2. MySQL 인스턴스 관리자는 모든 인스턴스를 시작하고 그것들을 모니터 한다.
3. 만약에 서버 인스턴스가 실패하면, MySQL 인스턴스 관리자는 그것을 재 구동 시킨다.
4. 만약에MySQL 인스턴스 관리자가 셧다운 되면 ( /etc/init.d/mysql stop 명령어를 가진 인스턴스에
대해), 모든 인스턴스는 MySQL 인스턴스 관리자에 의해 셧다운 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.5.2. MySQL 인스턴스 관리자에 접속하기와 사용자 계정 생성하기
5. 데이터 베이스 관리 5.5.2.1. 인스턴스 관리자 사용자 및 패스워드

5.5. mysqlmanager — MySQL 인스턴스 관리자 5.5.2.2. 상태 모니터를 위한 MySQL 서버 계정
5.5.2 MySQL 인스턴스 관리자에 접속하기와 사용자 계정 생성하기
5.5.2.1 인스턴스 관리자 사용자 및 패스워드 MySQL 인스턴스 관리자와의 커뮤니케이션은 MySQL 클라이언트-서버 프로토콜을 사용해서 처리된다. 그렇
게 함으로서, 여러분은 MySQL C API뿐만 아니라, 표준 mysql 클라이언트 프로그램을 사용해서 IM에 접속을
할 수 있게 된다. IM은 MySQL 4.1 또는 그 이후 버전과 함께 제공되는 클라이언트 및 라이브러리가 사용하는
MySQL 클라이언트-서버 프로토콜 버전을 지원한다.
:::MySQL Korea:::
제목검색
5.5.2.1. 인스턴스 관리자 사용자 및 패스워드

5. 데이터 베이스 관리 IM은 자신의 사용자 정보를 패스워드 파일에 저장한다. 패스워드의 디폴트 이름은 /etc/mysqlmanager.passwd이다.
5.5. mysqlmanager — MySQL 인스턴스 관
리자 패스워드 엔트리는 아래의 포맷을 가지고 있다:
5.5.2 MySQL 인스턴스 관리자에 접속하기와 사용

자 계정 생성하기 petr:*35110DC9B4D8140F5DE667E28C72DD2597B5C848

만약에 /etc/mysqlmanager.passwd 파일에 엔트리가 없다면, 여러분은 IM에 접속을 하지 못하게 된다.
새로운 엔트리를 생성하기 위해서는, IM을 --passwd 옵션과 함께 호출한다. 그렇게 하면, 새로운 사용자를 추가 하기 위해 그 결
과 값이 /etc/mysqlmanager.passwd 파일에 덧 붙여지게 된다. 아래에 예제가 있다:
shell> mysqlmanager --passwd >> /etc/mysqlmanager.passwd
Creating record for new user.
Enter user name: mike
Enter password: password
Re-type password: password
앞의 audfudd는 아래의 라인이 /etc/mysqlmanager.passwd에 붙여지게 한다:
mike:*00A51F3F48415C7D4E8908980D443C29C69B60C9

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
5.5.2.2. 상태 모니터를 위한 MySQL 서버 계정

5. 데이터 베이스 관리 서버의 상태를 모니터 하기 위해서, MySQL 인스턴스 check_connection의 패스워드를 가지고 있는
5.5. mysqlmanager — MySQL 인스턴스 관리자 MySQL_Instance_Manager@localhost 사용자 계정을 사용해서 레귤러 인터벌(regular interval) 동안 MySQL 서버
5.5.2 MySQL 인스턴스 관리자에 접속하기와 사용자 계정 인스턴스에 접속을 시도할 것이다.
생성하기
5.5.2.1 인스턴스 관리자 사용자 및 패스워드 여러분은 MySQL 인스턴스 관리자가 서버의 상태를 모니터 하도록 하기 위해 MySQL_Instance_M@localhost user 계
5.5.2.2 상태 모니터를 위한 MySQL 서버 계정 정을 만들 필요가 없는데, 그 이유는 동작 중인 서버를 구분하는데에는 로그인 실패(failure)만으로도 충분하기 때문이
다. 하지만, 만약에 계정이 존재하지 않으면, 실패한 접속 시도는 서버에 의해 자신의 일반 쿼리 로그에 등록 되어진다.
(Section 5.12.2, “일반 쿼리 로그”).
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.5.3. MySQL 인스턴스 관리자 명령어 옵션
5. 데이터 베이스 관리 MySQL 인스턴스 관리자는 여러 가지의 명령어 라인 옵션을 지원한다. 간단하게 리스트를 하자면, mysqlmanager를 --help
5.5. mysqlmanager — MySQL 인스턴스 관리자 옵션을 가지고 호출한다.
5.5.3 MySQL 인스턴스 관리자 명령어 옵션

Mysqlmanager는 아래의 옵션을 지원한다:
● --help, -?
도움말 메시지를 디스플레이 한후에 빠져 나온다.
● --bind-address=IP
연결할 IP 주소.
● --default-mysqld-path=path
유닉스상에서, 인스턴스 섹션에 아무런 경로도 주지 않을 경우의 MySQL 서버 바이너리의 경로 이름. 예: --

default-mysqld-path=/usr/sbin/mysqld
● --defaults-file=file_name
주어진 파일에서 인스턴스 관리자와 MySQL 서버의 설정 값을 읽음. 인스턴스 관리자가 변경하는 모든 구성 내용이
이 파일에 기록됨. 이 파일을 사용할 경우에는 반드시 명령어 라인의 맨 처음에 나와야 함.
● --install

:::MySQL Korea:::
윈도우에서, 윈도우 서비스 형태로 인스턴스 관리자를 설치함. 이 옵션은 MySQL 5.0.11에 추가 됨.
● --log=file_name
IM 로그 파일의 경로. 이것은 --run-as-service 옵션과 함께 사용됨.
● --monitoring-interval=seconds
모니터링 인스턴스의 초 단위 인터벌(interval). 디폴트는 20초다. 인스턴스 관리자는 모니터링된 각 인스턴스에 접속

하여 그 인스턴스가 살아 있는지(alive) 또는 행(hang)이 되었는지를 검사하고자 한다. 실패가 되는 경우에는, IM은
인스턴스를 여러 번 다시 재 구동한다. 인스턴스 섹션에서 nonguarded 옵션을 사용하면 특정 인스턴스에 대한 이런
동작을 비활성화 시킨다.
● --passwd, -P
패스워드 파일에 대한 엔트리를 준비한 다음에 마침.
● --password-file=file_name
이 파일에 있는 인스턴스 관리자 사용자 및 패스워드를 검사. 디폴트 파일은 /etc/mysqlmanager.passwd.
사용할 프로세스 ID 파일. 디폴트는, mysqlmanager.pid라는 이름의 파일이 된다.
● --port=port_num
들어오는(incoming) 접속을 위해 사용할 TCP/IP 포트 번호. (IANA가 할당하는 디폴트 번호는 2273).
● --print-defaults
현재의 디폴트 값을 출력하고 마침. 이 옵션을 사용할 경우에는, 반드시 명령어 라인 매 처음에 나와야 함.

:::MySQL Korea:::
● --remove
윈도우에서, 윈도우 서비스 형태의 인스턴스 관리자를 제거. 이것은 인스턴스 관리자가 이전에 –install와 함께 구동
되었다고 가정한다. 이 옵션은 MySQL 5.0.11에 추가 됨.
● --run-as-service
엔젤(angel)프로세스를 시작하고 데몬화(Daemonize) 시킴. 실패할 경우, 이것은 인스턴스 관리자를 재 구동 시킴.
● --socket=path
유닉스에서, 들어오는(incoming) 접속을 위해 사용될 유닉스 소켓. 디폴트는, /tmp/mysqlmanager.sock라는 파일이

다.
● --standalone
윈도우에서, 단독(standalone) 모드에서 인스턴스 관리자를 구동한다. 이 옵션은 5.0.13에서 추가됨.
● --user=user_name
mysqlmanager를 시작하고 구동 시킬 사용자 이름. mysqld 를 구동시키는데 사용한 사용자 계정 아래에서

mysqlmanager를 구동 시킬 것을 권장한다. (이 문장에서 쓰인 “사용자(User)”는 시스템 로그인 계정을 참조하고,
그랜트 테이블에 있는 MySQL 사용자를 참조하지는 않는다.)
● --version, -V
버전 정보를 보여 주고 마침.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.5.4. MySQL 인스턴스 관리자 구성 파일
5. 데이터 베이스 관리 인스턴스 관리자는 표준 my.cnf 파일을 사용한다. 이것은 자신을 위한 옵션을 읽기 위해 [manager] 섹션을 사용하고 인스턴스를
5.5. mysqlmanager — MySQL 인스턴스 관 생성하기 위해서는 [mysqld] 섹션을 사용한다. [manager] 섹션은 Section 5.5.3, “MySQL 인스턴스 관리자 명령어 옵션”에
리자 있는 모든 옵션을 가지고 있다. 아래에 [manager] 섹션의 예가 있다:
5.5.4 MySQL 인스턴스 관리자 구성 파일
# MySQL Instance Manager options section
[manager]
default-mysqld-path = /usr/local/mysql/libexec/mysqld
socket=/tmp/manager.sock
pid-file=/tmp/manager.pid
password-file = /home/cps/.mysqlmanager.passwd
monitoring-interval = 2
port = 1999
bind-address = 192.168.1.5
MySQL 5.0.10 이전에는, MySQL 인스턴스 관리자는 /etc/my.cnf, ~/.my.cnf등을 포함해서 MySQL 서버와 동일한 구성 파일
을 읽었다. MySQL 5.0.10 이후에는, MySQL 인스턴스 관리자는 유닉스에서만 /etc/my.cnf 파일을 읽고 관리한다, 윈도우에서
는, MySQL 인스턴스 관리자가 설치되어 있는 디렉토리내의 my.ini 파일만 읽는다. 디폴트 옵션 파일은 --defaults-

:::MySQL Korea:::
file=file_name 옵션으로 변경할 수가 있다.
인스턴스 섹션은 스타트업 시점에 각 인스턴스에 대한 옵션을 지정한다. 이러한 옵션들은 주로 일반적인 MySQL 서버 옵션이지
만, 몇가지는 IM에만 관련된 옵션들이 있다:
● mysqld-path = path
mysqld 서버 바이너리에 대한 경로 이름.
● shutdown-delay = seconds
인스턴스가 셧다운되기 위해 IM이 대기해야 하는 시간(초). 디폴트는 35초다. 이 대기시간이 끝나게 되면, IM은 인스턴스
가 행(hang) 상태가 된것으로 간주하고 재차 종료를 시도한다. 큰 테이블에서 InnoDB를 사용한다면, 이 값을 늘리도록
한다.
● nonguarded
여러분이 특정 인스턴스에 대해 IM 모니터링 기능을 비활성화 시키고자 한다면 이 옵션을지정해야 한다.
아래에 샘플 인스턴스 섹션이 있다:
[mysqld]
mysqld-path=/usr/local/mysql/libexec/mysqld
port=3307
server_id=1
skip-stack-trace

:::MySQL Korea:::
core-file
skip-bdb
log-bin
log-error
log=mylog
log-slow-queries
[mysqld2]
nonguarded
port=3308
server_id=2
mysqld-path= /home/cps/mysql/trees/mysql-5.0/sql/mysqld
pid-file = /tmp/hostname.pid5
datadir= /home/cps/mysql_data/data_dir1
language=/home/cps/mysql/trees/mysql-5.0/sql/share/english

:::MySQL Korea:::
log-bin
log=/tmp/fordel.log

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.5.5. MySQL 인스턴스 관리자가 인식하는 명령어
5. 데이터 베이스 관리 일단 여러분이MySQL 인스턴스 관리자에 대한 패스워드를 설정하였고 IM이 구동 중이면, 여러분은 IM에 접속할 수가 있다. 여러분은
5.5. mysqlmanager — MySQL 인스턴 mysql 클라이언트 툴을 사용해서 표준 MySQL API를 통해 접속을 할 수가 있다. 아래의 명령어 리스트는 현재 MySQL 인스턴스 관리자
스 관리자 가 수용하는 것들이며, 예문을 함께 보여준다.
5.5.5 MySQL 인스턴스 관리자가 인식하는
명령어 ● START INSTANCE instance_name
이 명령어는 인스턴스를 시작하는 시도를 한다.
mysql> START INSTANCE mysqld4;
Query OK, 0 rows affected (0,00 sec)
● STOP INSTANCE instance_name
이 명령어는 인스턴스를 종료하는 시도를 한다.
mysql> STOP INSTANCE mysqld4;
Query OK, 0 rows affected (0,00 sec)
● SHOW INSTANCES
로드된 인스턴스 모두를 보여준다.
mysql> SHOW INSTANCES;

:::MySQL Korea:::
+---------------+---------+
| instance_name | status |
+---------------+---------+
| mysqld3 | offline |
| mysqld4 | online |
| mysqld2 | offline |
+---------------+---------+
3 rows in set (0,04 sec)
● SHOW INSTANCE STATUS instance_name
인스턴스에 대한 상태와 버전 정보를 보여준다.
mysql> SHOW INSTANCE STATUS mysqld3;
+---------------+--------+---------+
| instance_name | status | version |
+---------------+--------+---------+
| mysqld3 | online | unknown |
+---------------+--------+---------+

:::MySQL Korea:::
● SHOW INSTANCE OPTIONS instance_name
인스턴스가 사용한 옵션을 보여준다.
mysql> SHOW INSTANCE OPTIONS mysqld3;
+---------------+---------------------------------------------------+
| option_name | value |
+---------------+---------------------------------------------------+
| instance_name | mysqld3 |
| mysqld-path | /home/cps/mysql/trees/mysql-4.1/sql/mysqld |
| port | 3309 |
| socket | /tmp/mysql.sock3 |
| pid-file | hostname.pid3 |
| datadir | /home/cps/mysql_data/data_dir1/ |
| language | /home/cps/mysql/trees/mysql-4.1/sql/share/english |
+---------------+---------------------------------------------------+
7 rows in set (0.01 sec)

:::MySQL Korea:::
● SHOW instance_name LOG FILES
인스턴스가 사용한 모든 로그 파일을 보여준다. 결과 셋은 로그 파일의 경로와 크기를 가지고 있다. 만약에 구성 파일에 아무런
로그 파일 경로도 지정되지 않았다면 (예를 들어, log=/var/mysql.log), IM은 그 로그 파일의 위치를 추정하게 된다. 만일 IM이
로그 파일의 위치를 추정할 수 없다면, 여러분은 구성 파일의 인스턴스 섹션에 적절한 로그 옵션을 사용해서 로그 파일의 위치를
지정해야 한다.
mysql> SHOW mysqld LOG FILES;
+-------------+------------------------------------+----------+
| Logfile | Path | Filesize |
+-------------+------------------------------------+----------+
| ERROR LOG | /home/cps/var/mysql/owlet.err | 9186 |
| GENERAL LOG | /home/cps/var/mysql/owlet.log | 471503 |
| SLOW LOG | /home/cps/var/mysql/owlet-slow.log | 4463 |
+-------------+------------------------------------+----------+
● SHOW instance_name LOG {ERROR | SLOW | GENERAL} size[,offset_from_end]
이 명령어는 지정된 로그 파일의 부분(portion)을 추출(retrieve)한다. 대부분의 사용자는 마지막 로그 메시지에 관심을 가지기
때문에, size 파라미터는 여러분이 로그 끝에서 시작해서 추출하고자 원하는 바이트의 크기를 정의한다. 여러분은
offset_from_end 파라미터를 사용해서 로그 파일의 중간에서 데이터를 읽어올 수도 있다. 아래의 예제에서는, 로그 파일의 끝으
로부터 23 바이트에서 시작해서 끝의 2바이트까지의 21바이트를 추출하는 것을 보여 준다:

:::MySQL Korea:::
mysql> SHOW mysqld LOG GENERAL 21, 2;
+---------------------+
| Log |
+---------------------+
| using password: YES |
+---------------------+
● SET instance_name.option_name=option_value
이 명령어는 지정된 인스턴스 구성 파일을 편집해서 인스턴스 옵션을 변경하거나 또는 추가하게끔 한다. IM은 구성 파일이 /etc/
my.cnf에 저장되어 있다고 가정한다. 여러분은 이 파일이 실제로 있는지와 적당한 권한이 허용되었는지를 검사해야 한다.
mysql> SET mysqld2.port=3322;
Query OK, 0 rows affected (0.00 sec)
구성 파일의 변경은 MySQL 서버가 재 구동되기 까지는 영향을 주지 않는다. 또한, 이러한 변경은 FLUSH INSTANCES 명령어
가 실행되기 까지는 인스턴스 관리자의 로컬 캐시에 저장되지 않는다.
● UNSET instance_name.option_name
이 명령어는 인스턴스 구성 파일에서 옵션을 제거한다.
mysql> UNSET mysqld2.port;

:::MySQL Korea:::
구성 파일의 변경은 MySQL 서버가 재 구동되기 까지는 영향을 주지 않는다. 또한, 이러한 변경은 FLUSH INSTANCES 명령어
가 실행되기 까지는 인스턴스 관리자의 로컬 캐시에 저장되지 않는다.
● FLUSH INSTANCES
이 명령어는 IM이 구성 파일을 다시 읽도록 만들고 내부 구조를 다시 만들도록 한다. 이 명령어는 구성 파일을 편집한 후에 수행
해야 한다. 이 명령어는 인스턴스 재 구동 시키지 않는다.
mysql> FLUSH INSTANCES;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.6. 설치-관련 프로그램
5. 데이터 베이스 관리 5.6.1. mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이

5.6. 설치-관련 프로그램 드
5.6 설치-관련 프로그램 5.6.2. mysql_upgrade — MySQL 업그레이드를 위한 테이블 검사
5.6.1 mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드

5.6.2 mysql_upgrade — MySQL 업그레이드를 위한 테이블 검사
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.6.1. mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드
5. 데이터 베이스 관리 MySQL의 몇몇 버전들은 새로운 권한을 추가하거나 또는 새로운 기능을 지원하기 위해 mysql 데이터 베이스에 있는 시스
5.6. 설치-관련 프로그램 템 테이블의 구조를 변경한다. 여러분이 새로운 버전으로 업데이트를 할 경우, 시스템 테이블을 업데이트하는 것은 물론이
5.6.1 mysql_fix_privilege_tables — MySQL 시스템 테 고, 여러분은 그 테이블의 구조가 업그레이드 되었는지를 살펴 보아야 한다. 우선, 여러분의 mysql 데이터 베이스를 백업
이블 업그레이드 한 다음에, 아래와 과정을 진행한다.
Note: A MySQL 5.0.19 이후에는, mysql_fix_privilege_tables은 mysql_upgrade가 지원을 하는데, 이것을 대신 사용해
야 한다. Section 5.6.2, “mysql_upgrade — MySQL 업그레이드를 위한 테이블 검사”를 참조.
유닉스 또는 이와 비슷한 시스템에서는, 시스템 테이블 업데이트는 mysql_fix_privilege_tables 스크립트 구동을 통해서
한다:
shell> mysql_fix_privilege_tables
이 스크립트는 서버가 구동 중에 있을 때 해야 한다. 이것은 로컬 호스트 상에서 구동하고 있는 서버에 root로 접속을 시도
한다. 만일 root 계정에 패스워드가 필요하면, 명령어 라인에서 아래와 같이 패스워드를 지정한다:
shell> mysql_fix_privilege_tables --password=root_password
mysql_fix_privilege_tables 스크립트는 여러분의 시스템 테이블을 현재의 포맷으로 변환하기 위한 모든 필요한 조치를 수
행한다. 여러분은 이것을 실행할 때 Duplicate column name 경고와 같은 것을 보게 되는데, 이것들은 무시해도 된다.
스크립트를 구동시킨 다음에는, 서버를 종료시키고 다시 재 구동 시킨다.
윈도우 시스템에서는, MySQL 배포판은 mysql_fix_privilege_tables.sql SQL 스크립트를 포함하는데, 여러분은 mysql
클라이언트를 사용해서 이것을 구동할 수가 있다. 예를 들면, 만약에 여러분이 MySQL을 C:￦Program Files￦MySQL

:::MySQL Korea:::
￦MySQL Server 5.0에 설치 하였다면, 명령어는 다음과 같을 것이다:
C:￦> cd "C:￦Program Files￦MySQL￦MySQL Server 5.0"
C:￦> bin￦mysql -u root -p mysql
mysql> SOURCE scripts/mysql_fix_privilege_tables.sql
mysql 명령어는 패스워드 프롬프트를 보이게 되며, 이때 패스워드를 입력한다.
만일 다른 위치에 설치를 하였다면, 경로 이름을 적절하게 수정한다.
유닉스 프로시저가 진행되면서, Duplicate column name 경고문과 같은 것을 볼 수 있을 것이데, 무시해도 된다.
스크립트를 구동 시킨 다음에는, 서버를 종료하고 다시 구동시킨다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.6.2. mysql_upgrade — MySQL 업그레이드를 위한 테이블 검사
5. 데이터 베이스 관리 mysql_upgrade은 여러분이 MySQL을 업그레이드할 때마다 실행해야 한다. 이것은 모든 데이터 베이스의 테이블과 업그레이드하
5.6. 설치-관련 프로그램 는 MySQL 버전과의 비 호환성을 검사한다. 만약에 하나의 테이블이 호환되지 않을 가능성이 있다면, 체크를 하게 되며, 어떤 문제
5.6.2 mysql_upgrade — MySQL 업그레이드를 가 발견될 경우에는 그 테이블을 치료한다. mysql_upgrade은 또한 시스템 테이블을 업그레이드 해서 여러분이 새로운 권한 또는
위한 테이블 검사 기능들을 사용할 수 있게끔 해 준다.
검사와 치료를 받은 모든 테이블은 현재의 MySQL 버전 번호로 표시가 된다. 이것을 통해 여러분이 다음에 서버의 동일한 버전을
가지고 mysql_upgrade를 구동을 시킬 때, 더 이상 검사 또는 치료를 해야할 테이블이 있는지를 알게 된다.
mysql_upgrade는 또한 데이터 디렉토리에 있는 mysql_upgrade.info라는 이름의 파일에 MySQL버전 번호를 저장한다. 이 파일

을 무시하고자 하면, --force 옵션을 사용한다.
시스템 테이블을 검사, 치료, 그리고 업그레이드를 하기 위해서는, mysql_upgrade를 아래와 같이 실행한다:
mysqlcheck --check-upgrade --all-databases --auto-repair
mysql_fix_privilege_tables
mysql_upgrade는 현재 유닉스에서만 지원한다. 윈도우에서는, mysqlcheck 명령어를 수동으로 실행하며, 그 다음에

Section 5.6.1, “mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드”에서 설명하는 방법으로 시스템 테이블을
업그레이드 한다.
어떤 것이 검사 되었는지 보다 자세히 보기 위해서는, CHECK TABLE 명령문의 FOR UPGRADE 옵션에 있는 내용을 보기 바란
다. (Section 13.5.2.3, “CHECK TABLE 신텍스”를 참조).
mysql_upgrade를 사용하기 위해서는, 서버가 구동 되고 있는지를 확인한 다음에, 아래와 같이 호출을 한다:

:::MySQL Korea:::
shell> mysql_upgrade [options]
mysql_upgrade은 명령어 라인과 옵션 파일의 [mysqld] 및 [mysql_upgrade] 그룹에서 옵션을 읽는다. 이것이 지원하는 옵션
은 다음과 같다:
● --basedir=path
MySQL 설치 디렉토리의 경로.
● --datadir=path
데이터 디렉토리 경로.
● --force
mysql_upgrade이 이미 현재 버전에 대해 실행이 되었다고 하더라도 강제로 mysqlcheck를 실행 시킴. (달리 표현 하면,
이 옵션은 mysql_upgrade.info 파일을 무시하게끔 만든다.)
● --user=user_name, -u user_name
서버에 접속을 할 때 사용되는 MySQL 사용자 이름. 디폴트는 root.
● --verbose
상세(Verbose) 모드. 프로그램이 실행하는 것에 대한 정보를 자세히 보여줌.
다른 옵션들도 mysqlcheck 과 mysql_fix_privilege_tables에 전달 된다. 예를 들면, --password[=password] 옵션을 지정할

필요가 있을 것이다.
mysql_upgrade은 MySQL 5.0.19에서 추가 되었다. 이것은 이전의 mysql_fix_privilege_tables 스크립트를 대체한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.7. 일반적인 보안 이슈
5. 데이터 베이스 관리 5.7.1. 일반적인 보안 가이드라인

5.7. 일반적인 보안 이슈 5.7.2.공격으로부터 MySQL 보안 설정하기
5.7 일반적인 보안 이슈 5.7.3. 보안-관련 mysqld 옵션
5.7.1 일반적인 보안 가이드 라인 5.7.4. LOAD DATA LOCAL 이 가지는 보안 이슈
5.7.2 공격으로부터 MySQL 보안 설정하기 5.7.5. 일반 사용자 자격으로 MySQL 구동시키는 방법
5.7.3 보안-관련 mysqld 옵션

이 섹션에서는 여러분이 MySQL을 보다 안정적으로 설치하여 다른 사람으로부터의 공격이 잘못 사용하는 것을 피할 수 있도
5.7.4 LOAD DATA LOCAL가 가지고 있는 보안 이슈
록 해 주는 일반적인 보안 이슈에 대해 설명을 하도록 한다. MySQL이 사용자 계정을 설정하고 데이터 베이스 접근을 제어하는
5.7.5 일반 사용자 자격으로 MySQL 구동시키는 방법
데 사용하는 접근 제어 시스템에 관련된 사항은 Section 5.8, “MySQL 접근 권한 시스템”에서 다루기로 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.7.1. 일반적인 보안 가이드 라인
5. 데이터 베이스 관리 인터넷에 연결되어 있는 컴퓨터에서 MySQL을 사용하고 있는 사용자들은 모두 대부분의 공통적인 보안 실수를 피하기 위해서는
5.7. 일반적인 보안 이슈 이 섹션을 읽기 바란다.
5.7.1 일반적인 보안 가이드 라인

MySQL은 사용자가 수행하고자 시도하는 모든 접속, 쿼리, 그리고 다른 실행 동작에 대해 접근 제어 리스트(ACL)에 근거를 한 보
안 정책을 사용하고 있다. 또한 MySQL 클라이언트와 서버 사이의 SSl-암호화 접속도 지원을 한다. 여기에서 설명하는 많은 개념
들은 MySQL에만 국한되지 않는다; 동일한 개념들이 거의 모든 어플리케이션에도 적용된다.
MySQL을 구동할 때에는 가능하면 항상 아래의 가이드 라인을 준수하기 바란다:
● user 테이블에 대해서는 누구도 접근을 허용하지 말 것(MySQL root 계정은 제외)! 이 테이블은 매우 중요한 것이다.
MySQL에서는 패스워드가 암호화 된다. 테이블에 있는 패스워드를 알게 되면, 누구라도 쉽게 다른 사용자 계정에 접근할
수가 있다.
● MySQL 접근 권한 시스템에 대해 공부한다. GRANT 및 REVOKE 명령문은 MySQL에 대한 접근을 제어하는데 사용된
다. 필요 이상의 권한을 부여하지 말도록 한다.
체크 리스트:
❍ mysql -u root을 시도한다. 만약에 패스워드를 넣지 않고도 서버에 쉽게 접속이 된다면, 모든 사람들이 전체 권한
을 가지고 root 사용자로서 여러분의 MySQL 서버에 접속할 수가 있다는 것을 의미한다! MySQL 설치 설명을 다
시 한번 보고 root 패스워드 설정에 대한 사항을 숙지하기 바란다. Section 2.9.3, “초기 MySQL 계정 보안 작업
하기”를 참조.
❍ 어떤 계정이 접속을 하고 있는지 보기 위해서는 SHOW GRANTS 명령문을 사용해서 검사한다. 그 다음에는 필요
없는 권한을 삭제하기 위해 REVOKE 명령문을 사용한다.
● 여러분의 데이터 베이스에서 평범한 패스워드는 저장하지 말 것. 대신에, MD5(), SHA1(), 또는 다른 한 방향(one-
way) 해싱(hashing) 함수를 사용해서 해시(hash) 값을 저장하도록 한다.

:::MySQL Korea:::
● 방화벽을 설치한다. MySQL을 방화벽 뒤 또는 DMZ(demilitarized zone)에 놓는다.
체크 리스트:
❍ nmap과 같은 툴을 사용해서 인터넷에서 여러분의 포트를 스캔하여 본다. MySQL 은 디폴트로 3306 포트를 사용
한다. 이 포트는 인가 받지 못한 호스트는 접근하지 못하게 한다. 여러분의 포트가 열리는지 아닌지를 검사 하는 다
른 간단한 방법은 리모트 머신에서 아래의 명령어를 시도해 보는 것이다. 여기에서 server_host는 여러분의
MySQL 서버가 구동되고 있는 호스트의 이름 또는 IP 번호가 된다:
o shell> telnet server_host 3306
이것을 사용해서 접속이 되고 이상한 문자가 나오게 되면, 여러분의 포트는 열려 있는 것이며, 방화벽 또는 라우
터를 사용해서 닫아야 한다. 만일 telnet이 행(hang) 상태가 되거나 또는 접속이 거절되면, 포트는 블로킹 된 것
이다.
● 많은 어플리케이션 프로그래밍 인터페이스는 데이터 값에서 탈출(escaping) 특수 문자의 수단을 제공한다. 제대로만 사용
한다면, 이것은 어플리케이션 사용자가 여러분이 의도하는 것과는 다른 효과를 발생시키는 명령문을 어플리케이션이 만들
지 못하도록 할 수 있다:
❍ MySQL C API: mysql_real_escape_string() API 호출을 사용한다.
❍ MySQL++: 쿼리 스트림을 위해 escape 와 quote 수정자(modifier)를 사용한다.
❍ PHP: mysql_escape_string() 함수를 사용하는데, 이것은 MySQL C API에 있는 동일한 이름의 함수를 기초로
한다. (PHP 4.0.3 이전에는, addslashes()를 대신 사용함.) PHP 5에서는, mysqli 확장자를 사용할 수가 있는데,
이것은 MySQL 승인 프로토콜과 패스워드, 그리고 플레이스홀더(placeholder)가 있는 프리페어드 명령문을 지원
한다.
❍ Perl DBI: quote() 방식을 사용하거나 또는 플레이스홀더를 사용한다.
❍ Ruby DBI: 플레이스홀더를 사용한다.
❍ Java JDBC: PreparedStatement 오브젝트와 플레이스홀더를 사용한다.
다른 프로그래밍 인터페이스는 비슷한 기능을 가지고 있다.

인터넷으로 평이한(암호화 하지 않은) 데이터를 전송하지 말 것. 대신에, SSL 또는 SSH와 같은 암호화 프로토콜을 사용
한다. MySQL은 4.0 이후에 내부 SSL을 지원하고 있다. 다른 방법으로는 SSH 포트- 전달 방식을 사용해서 암호화(압

:::MySQL Korea:::
축) 터널을 생성해서 통신을 하는 것이다.
● tcpdump 과 strings 유틸리티 사용법을 배운다. 대부분의 경우, 아래와 같은 명령어를 입력해서 MySQL 데이터 스트림이
암호화가 되어 있지 않은지를 검사할 수가 있다:
• shell> tcpdump -l -i eth0 -w - src or dst port 3306 | strings
(위의 것은 리눅스 환경에서만 동작을 하는 명령문이며 다른 시스템에서는 약간 수정을 해야 한다.) 경고: 만약에 여러분
이 일반 텍스트 데이터를 보지 못한다고 하더라도, 이것이 데이터가 실제로 암호화 되었다는 것을 항상 의미하는 것은 아
니다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.7.2. 공격으로부터 MySQL 보안 설정하기
5. 데이터 베이스 관리 여러분이 MySQL 서버에 접속을 할 때에는, 패스워드를 사용하도록 한다. 클라이언트 접속 시퀀스 동안 패스워드 다루기는
5.7. 일반적인 보안 이슈 MySQL 4.1.1에서 많은 업그레이드가 되었다. 만약에 여러분이 아직도 4.1.1 이전 버전 형태의 패스워드를 사용한다면, 암호화 알
5.7.2 공격으로부터 MySQL 보안 설정하기 고리즘이 새 버전의 알고리즘 만큼 튼튼하지 못한 것이다. 명석한 공격자는, 약간의 노력만 가지고도 클라이언트와 서버간의 통신
을 가로채서 패스워드를 해석할 수가 있다. (Section 5.8.9, “MySQL 4.1 이후의 패스워드 해싱(Hashing)”,을 참조할 것.)
다른 모든 정보는 텍스트 형태로 전송되는데, 이것은 접속을 지켜보는 사용자라면 누구라도 읽을 수가 있는 것이다. 만약에 클라이
언트와 서버간의 접속이 신뢰도가 떨어지는 네트워크를 통해 이루어 진다면, 그리고 여러분이 이에 대해 걱정을 한다면, 압축 프로
토콜을 사용해서 통신을 해석하는 것을 더욱 어렵게 만들 수도 있다. 또한 MySQL의 내부 SSL을 사용해서 보안성을 보다 좋게 만
들 수도 있다. Section 5.9.7, “보안 접속 사용하기”를 참조할 것.
MySQL 시스템의 보안성을 좋게 하기 위해서는, 여러분은 아래의 내용을 정확하게 숙지해야 한다:
● 모든 MySQL 계정이 패스워드를 가지도록 한다.
패스워드 설정 방법은 Section 5.9.5, “계정 패스워드 설정하기”를 참조한다.
● 유닉스 root 사용자로는 절대로 MySQL 서버를 구동하지 말 것. 이것은 매우 위험한 일인데, 그 이유는 FILE 권한을 가진
사용자라면 누구라도 서버가 root로 파일을 생성할 수 있게끔 할 수가 있다(예를 들면, ~root/.bashrc). 이것을 방지하기
위해서, mysqld은 --user=root 옵션을 사용해서 명확하게 지정을 하지 않는 root로 구동되는 것을 거부한다.
mysqld은 대신에 권한이 없는 일반 사용자로서 구동 시킬 수가 있다. 여러분은 별도의 유닉스 계정 mysql을 생성해서 일
을 처리하는 것이 보다 안전하다. 이 계정은 MySQL을 관리하는 용도로만 사용한다. 다른 유닉스 사용자로서 mysqld을
구동 시킬 때에는, 여러분이 서버 옵션을 지정하는 my.cnf 옵션 파일에 있는 [mysqld] 그룹에 사용자 이름을 지정하는
user 옵션을 추가한다. 예를 들면:

:::MySQL Korea:::
[mysqld]
user=mysql
보다 자세한 사항은 Section 5.7.5, “일반 사용자 자격으로 MySQL 구동시키는 방법”을 참조할 것.
Mysqld을 root가 아닌 다른 유닉스 사용자로서 구동시킨다는 것은 여러분이 user 테이블에 있는 root 사용자 이름을
the 변경해야 한다는 것을 의미하는 것이 아니다. MySQL 계정에 대한 사용자 이름은 유닉스 계정에 대한 사용자 이름과
는 아무 상관이 없다.
● 테이블에 대한 심볼릭 링크를 허용하지 말 것.(이 기능은 --skip-symbolic-links 옵션을 사용해서 비활성화 시킬 수가
있다.) 만약에 여러분이 mysqld을 root 자격으로 구동 시킬 때 특히 중요한 사항인데, 그 이유는 서버의 데이터 디렉토리
에 쓰기 접근 권한을 가지는 사용자는 시스템의 모든 파일을 삭제할 수 있기 때문이다! Section 7.6.1.2, “유닉스에서 심
볼릭 링크 사용하기”를 참조.
● 데이터 디렉토리에서 읽기 또는 쓰기 권한을 가지고 있는 유닉스 사용자만이 mysqld을 구동 시킬 수 있는 사용자가 되도
록 한다.
● 비-관리 사용자에게 PROCESS 또는 SUPER 권한을 주지 말 것. mysqladmin processlist 과 SHOW PROCESSLIST
의 결과는 현재 실행되고 있는 모든 명령문의 텍스트를 보여준다. 따라서 서버 프로세스 리스트를 볼 수 있는 사용자는
UPDATE user SET password=PASSWORD('not_secure')와 같은 사용자가 입력하는 명령문도 볼 수가 있게 된다.
Mysqld은 SUPER 권한을 가지고 있는 사용자를 위해 여분의 접속을 유지하는데, 그 이유는 일반 접속이 모두 사용되는
중일 지라도 MySQL root 사용자가 로그인하여 서버의 동작을 검사할 수 있도록 하기 위해서다.
SUPER 권한은 클라이언트 접속을 종료시키고, 시스템 변수 값을 변경해서 서버 동작을 변경시키고, 리플리케이션 서버
를 제어하기 위해 사용할 수가 있다.
● 비-관리 사용자에게 FILE 권한을 주지 말 것. 이 권한을 가지고 있는 사용자는 mysqld 데몬에 대한 권한을 가지고서 파
일 시스템에 있는 어떤 파일에도 쓰기를 할 수가 있다.
● 만약에 여러분의 DNS를 신뢰하지 못한다면, 그랜트 테이블에서 호스트 이름을 사용하지 말고 IP 번호를 사용하도록 한다.
또한, 와일드 카드를 가지는 호스트 이름을 사용해서 그랜트 테이블 엔트리를 생성할 경우에는 세심한 주의를 한다.
● 하나의 계정이 접속할 수 있는 숫자를 제한하고자 한다면, mysqld에 있는 max_user_connections 변수를 설정하면 된다.
GRANT 명령문을 사용해서도 하나의 계정에게 허용된 서버 사용 확장에 대한 자원 제어 옵션을 지정할 수가 있다.
Section 13.5.1.3, “GRANT 신텍스”를 참조.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.7.3. 보안-관련 mysqld 옵션
5. 데이터 베이스 관리 아래의 mysqld 옵션은 보안성에 영향을 준다:

5.7. 일반적인 보안 이슈
5.7.3 보안-관련 mysqld 옵션 ● --allow-suspicious-udfs
이 옵션은 주 함수에 대해 xxx 심볼만 가지고 있는 사용자 정의 함수를 로드할 수 있는지 없는지를 제어한다. 디폴트로는
오프(off)이며, 최소 한 개의 보조 심볼을 가지고 있는 UDF만을 로드할 수가 있다; 이것은 규칙에 맞는 UDF를 가지고 있
는 파일에서가 아니고 공유 오브젝트 파일에서 함수를 로드하려는 시도를 못하게 한다. 이 옵션은 5.0.3에 추가 되었다.
See Section 24.2.4.6, “사용자 정의 함수 보안 유의 사항”을 참고할 것.
● --local-infile[={0|1}]
만일 여러분이 서버를 --local-infile=0와 함께 구동 시킨다면, 클라이언트는 LOAD DATA 에서 LOCAL을 사용할 수

가 없다. Section 5.7.4, “LOAD DATA LOCAL가 가지고 있는 보안 이슈”를 참조.
● --old-passwords
새로운 패스워드에 대해 서버가 짧은(pre-4.1) 패스워드 해시를 만들도록 한다. 이것은 서버가 이전 버전의 클라이언트
프로그램을 지원해야 하는 경우에 유용하다. Section 5.8.9, “MySQL 4.1이후의 패스워드 해싱(Hashing)”을 참조할
것.
● --safe-show-database (없어짐)
이전 버전의 MySQL에서, 이 옵션은 SHOW DATABASES 명령문이 사용자가 권한을 가지고 있는 데이터 베이스의 이
름을 출력하게끔 한다. 5.0 이후에는 이 옵션은 더 이상 사용되지 않는다. Section 13.5.1.3, “GRANT 신텍스”를 참조
할 것.

:::MySQL Korea:::
● --safe-user-create
만약에 이 옵션이 활성화되면, 사용자는 mysql.user 테이블에 대한 INSERT 권한을 가지고 있지 않는 GRANT 명령문
을 사용해서 새로운 MySQL 사용자를 만들 수가 없다. 만약에 사용자에게 이러한 권한을 가지는 새로운 사용자를 생성할
수 있도록 하고자 한다면, 여러분은 그 사용자에게 아래의 권한을 승인해야 한다:
GRANT INSERT(user) ON mysql.user TO 'user_name'@'host_name';
이것은 사용자가 권한이 있는 컬럼을 직접은 변경하지 못하도록 만들며, 대신에 GRANT 명령문을 사용해서 다른 사용자
에게 권한을 주도록 만든다.
● --secure-auth
구형(pre-4.1)패스워드를 가지고 있는 계정에 대해서는 사용을 허가하지 않음.

mysql 클라이언트도 --secure-auth 옵션을 가지는데, 이것은 만약에 서버가 클라이언트 계정에 대해 구형 포맷의 패스
워드를 요구할 경우에는 접속을 하지 못하도록 만든다.
● --skip-grant-tables
이 옵션은 서버가 권한 테이블을 전혀 사용할 수 없도록 만든다. 이것은 누구라도 제한 없이 서버와 모든 데이터 베이스에
접근할 수 있도록 만든다. 여러분은 mysqladmin flush-privileges을 실행 시키거나 또는 시스템 쉘에서 mysqladmin
reload 명령어를 실행하거나, 또는 MySQL FLUSH PRIVILEGES 명령문을 입력해서 구동 중인 서버가 그랜트 테이블
을 사용해서 재 구동 되도록 할 수가 있다. 이 옵션은 또한 사용자 정의 함수를 로딩하지 못하도록 한다.
● --skip-name-resolve
호스트 이름을 해석하지 않는다. 그랜트 테이블에 있는 모든 Host 컬럼값은 반드시 IP 번호 또는 localhost 이어야 한다.
● --skip-networking
네트워크를 통한 TCP/IP 접속을 허용하지 않음. 모든 접속은 유닉스 소켓 파일을 통해서 이루어져야 한다.

:::MySQL Korea:::
● --skip-show-database
이 옵션을 사용하면, SHOW DATABASES 명령문은 SHOW DATABASES 권한을 가지고 있는 사용자에게만 허용되
며, 그리고 명령문은 모든 데이터 베이스 이름을 출력한다. 이 옵션이 없으면, SHOW DATABASES은 모든 사용자가 사
용할 수 있으나, 사용자가 SHOW DATABASES 권한을 가지고 있는 데이터 베이스 이름만 디스플레이 한다. 모든 글로
벌 권한은 데이터 베이스에 대한 권한임을 알기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.7.4. LOAD DATA LOCAL가 가지고 있는 보안 이슈
5. 데이터 베이스 관리 LOAD DATA 명령문은 서버 호스트에 있는 파일을 로드할 수 있으며, 또는 LOCAL 키워드가 지정이 되면 클라이언트에 있는 파
5.7. 일반적인 보안 이슈 일을 로드할 수가 있다.
5.7.4 LOAD DATA LOCAL가 가지고 있는 보안

이슈 LOAD DATA 명령문의LOCAL 버전 지원에는 잠재적인 보안 이슈가 존재 한다:
● 클라이언트 호스트에서 서버 호스트로 파일을 전송하는 것은 MySQL 서버가 초기화 한다. 이론적으로는, 클라이언트가
LOAD DATA 명령문에서 지정하는 파일이 아닌 서버가 선택한 파일을 클라이언트 프로그램이 전송하도록 서버를 구축할
수가 있다. 그러한 서버는 클라이언트 사용자가 읽기 접근을 가지는 클라이언트 호스트에 있는 모든 파일을 접근할 수가 있
다.
● 클라이언트가 웹 서버를 통해 접속하는 웹 환경에서는, 웹 서버 프로세스가 일기 접근을 가지고 있는 모든 파일을 사용자
는 LOAD DATA LOCAL를 사용해서 읽을 수가 있게 된다 (사용자가 SQL 서버에 대응하는 명령문을 구동 시킨다고 가정
한다). 이러한 환경에서, MySQL 서버와 관련된 클라이언트는 실제로는 웹 서버가 되며, 웹 서버에 접속을 한 사용자가 구
동하는 리모트 프로그램은 아니다.
이러한 문제를 다루기 위해서, 우리는 LOAD DATA LOCAL를 처리하는 방법을 변경하였다:
● 디폴트로, 바이너리 배포판에 있는 모든 MySQL 클라이언트와 라이브러리는 --enable-local-infile 옵션을 가지고 컴파

일 되며, MySQL 3.23.48 및 이전 버전과 호환이 된다.
● 여러분이 MySQL을 소스를 가지고 구축하였으나 --enable-local-infile 옵션을 가지고 configure을 호출하지는 않았다
면, LOAD DATA LOCAL는 mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0)를 호출할 수 있도록 명확하게 쓰여
지지 않는 한 어떤 클라이언트도 사용할 수가 없게 된다. Section 22.2.3.48, “mysql_options()”을 참조.
● 여러분은 mysqld 을 --local-infile=0 옵션으로 시작 함으로서 서버 측면에서 모든 LOAD DATA LOCAL 명령어를 비
활성화 시킬 수가 있다.
● mysql 명령어-라인 클라이언트의 경우, LOAD DATA LOCAL는 --local-infile[=1] 옵션 지정을 통해 활성화 시킬
수 있거나, 또는, --local-infile=0 옵션을 가지고 비활성화 시킬 수가 있다. 비슷하게, mysqlimport의 경우, --local 또

:::MySQL Korea:::
는 -L 옵션은 로컬 데이터 파일 로딩을 활성화 시킬 수가 있다. 어떤 경우에서건, 성공적인 로컬 로딩 동작은 서버가 이를

허용하도록 활성화 되어 있어야 한다.
● 만약에 여러분이 Perl 스크립트 또는 옵션 파일에서 [client] 그룹을 읽는 다른 프로그램에서 LOAD DATA LOCAL를 사
용한다면, local-infile=1 옵션을 그 그룹에 추가할 수가 있다. 하지만, local-infile를 이해하지 못하는 프로그램에 대해
문제가 발생하지 못하도록 하기 위해서는, loose- 접두사를 사용해서 이것을 지정한다:
• [client]
• loose-local-infile=1
● 만약에 LOAD DATA LOCAL INFILE이 비활성화 되었다면, 서버 또는 클라이언트에서, 이러한 명령문을 입력하고자 하
는 클라이언트는 아래의 에러 메시지를 받게 된다:
• ERROR 1148: The used command is not allowed with this MySQL version

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.7.5. 일반 사용자 자격으로 MySQL 구동시키는 방법
5. 데이터 베이스 관리 윈도우에서는, 여러분은 일반 사용자 계정을 사용해서 MySQL 서버를 윈도우 서비스 형태로 구동 시킬 수가 있다.
5.7. 일반적인 보안 이슈
5.7.5 일반 사용자 자격으로 MySQL 구동시키는 유닉스에서는, MySQL 서버 mysqld는 모든 사용자가 시작 및 구동을 할 수가 있다. 하지만, 보안상의 이유로, 여러분은 서버를 유
방법 닉스 root 사용자로는 구동 시키지 말아야 한다. Mysqld를 권한이 없는 일반 유닉스 사용자 user_name가 구동할 수 있도록 변경
하기 위해서는, 아래의 사항을 따르기 바란다:
1. 서버가 구동 중이라면, 종료를 시킨다 (mysqladmin shutdown를 사용).

2. 데이터 베이스 디렉토리 및 파일을 변경해서 user_name가 읽기 및 쓰기 권한을 가지도록 변경한다 (이러한 일은 유
닉스 root 사용자의 자격으로 해야 함):
3. shell> chown -R user_name /path/to/mysql/datadir
만약에 여러분이 이렇게 하지 않으면, user_name로 서버를 구동 시킬 때 서버는 데이터 베이스 또는 테이블에 접근을 하
지 못하게 된다.
만약에 MySQL 데이터 디렉토리 안에 있는 디렉토리 또는 파일이 심볼릭 링크라면, 여러분은 또한 그 링크를 따라야 하
고 링크가 가리키는 디렉토리와 파일도 변경을 해야 한다. chown –R은 여러분을 위한 심볼릭 링크를 따르지 않을 것이
다.
4. 사용자user_name로 서버를 시작한다. 만약에 여러분이 MySQL 3.22 또는 그 이후 버전을 사용한다면, 사용할 수
있는 다른 방법은 mysqld를 유닉스 root 사용자로 시작하고 --user=user_name 옵션을 사용하는 것이다. mysqld 은
시작이 된 후에, 다른 접속을 받아들이기 전에 유닉스 사용자 user_name로 구동을 변경한다.
5. 시스템 스타트업 시점에, 지정한 사용자로서 서버를 자동으로 시작하기 위해서는, user 옵션을 추가해서 사용자의 이
름을 /etc/my.cnf 옵션 파일의 [mysqld] 그룹 또는 서버의 데이터 디렉토리에 있는 my.cnf 옵션 파일에 지정한다. 예를
들면:
6. [mysqld]

:::MySQL Korea:::
7. user=user_name

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8. MySQL 접근 권한 시스템
5. 데이터 베이스 관리 5.8.1. 권한 시스템이 하는 일

5.8. MySQL 권한 시스템 5.8.2. 권한 시스템은 어떻게 동작하는가
5.8 MySQL 권한 시스템 5.8.3. MySQL이 제공하는 권한
5.8.1 권한 시스템이 하는 일 5.8.4. MySQL 서버에 접속하기
5.8.2 권한 시스템은 어떻게 동작하는가 5.8.5. 접근 제어, Stage 1: 접속 검증

5.8.6. 접근 제어, Stage 2: 요청 검증
5.8.3 MySQL이 제공하는 권한
5.8.7. 권한 변경시의 효과
5.8.4 MySQL 서버에 접속하기
5.8.8. Access denied 에러의 원인
5.8.9. MySQL 4.1 이후의 패스워드 해싱
5.8.6 접근 제어, Stage 2: 요청 검증
MySQL 은 진보된 보안 및 권한 시스템을 가지고 있다. 이 섹션에서는 이 권한 시스템이 어떻게 동작되는지를 설명하겠다.
5.8.8 접근 거부 에러의 원인
5.8.9 MySQL 4.1 이후의 패스워드 해싱
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.1. 권한 시스템이 하는 일
5. 데이터 베이스 관리 MySQL 권한 시스템의 주된 기능은 주어진 호스트에서 접속을 하는 사용자를 승인하고 그 사용자를 SELECT, INSERT,
5.8. MySQL 권한 시스템 UPDATE, and DELETE와 같은 데이터 베이스에 있는 권한에 연결을 시키는 것이다.
5.8.1 권한 시스템이 하는 일
또 다른 기능으로는 익명의 사용자를 가질 수 있으며 LOAD DATA INFILE과 같은 MySQL-특성 함수와 관리 동작에 대한 권한
을 허용하는 것이다.
:::MySQL Korea:::
제목검색
상위메뉴 5.8.2. 권한 시스템은 어떻게 동작하는가

리스트 ◆
MySQL 권한 시스템은 모든 사용자가 허용된 동작만을 하도록 해 준다. 하나의 사용자로서, 여러분이 MySQL 서버에 접속을 하게 되면, 여러분의 ID는 여러분이 접속을 하고 사용자 이름을 지정
5. 데이 한 서버에 의해 판단된다. 접속을 한 후에 어떤 요청을 할 경우에는, 시스템은 여러분의 ID와 여러분이 원하는 것에 따라서 권한을 승인하게 된다.
터 베이
스 관리 MySQL은 여러분을 구분하기 위해 여러분의 호스트 이름과 사용자 이름을 모두 고려한다. 예를 들면, office.example.com에서 접속한 사용자 joe는 home.example.com에서 접속한 사용자 joe
5.8. 와 동일한 사람일 필요는 없다. MySQL은 우연히 동일한 이름을 가지고 있는 서로 다른 머신상의 사용자로 여러분을 인식해서 이것을 처리한다: 여러분은 office.example.com에서 접속한 joe
MySQL 를 위해 하나의 권한 셋을 승인하고, 그리고 home.example.com에서 오는 joe의 접속을 위한 권한 셋을 다르게 승인할 수가 있다.
권한 시
스템
MySQL 접근 제어는 서버에 접속을 하는 클라이언트 프로그램을 구동 시킬 때 두 단계를 갖게 된다:
5.8.2 권한
시스템
● Stage 1: 서버는 여러분에게 접속을 허용할지를 검사.
은어
● Stage 2: 여러분이 접속을 하였다고 가정을 한 후, 서버는 여러분이 입력하는 각 명령문에 대해 충분한 권한을 가지고 있는지를 검사. 예를 들면, 만일 여러분이 데이터 베이스에 있는 테
떻게
이블에서 열을 선택하거나 또는 데이터 베이스에서 테이블을 삭제하고자 시도할 경우, 서버는 여러분이 선택한 테이블에 대해 SELECT 권한을 가지고 있는지 또는 삭제하고자 하는 데이
동작하
는가 터 베이스에 대해 DROP 권한을 가지고 있는지를 검사한다.
만약에 접속을 하고 있는 동안에 여러분의 권한이 변경된다면, 여러분이 입력하는 그 다음 명령문에 대해서는 변경된 내용이 즉시 효과를 나타내지 못한다. Section 5.8.7, “권한 변경시의 효
과”를 참조할 것.
서버는 mysql 데이터 베이스의 그랜트 테이블에 권한 정보를 저장한다. MySQL 서버는 시작을 할 때 이 테이블에 있는 컨텐츠를 메모리로 읽어 들이고 또한 Section 5.8.7, “권한 변경시의 효
과”에서 지정하는 환경 아래일 경우에도 다시 한번 그것들을 읽어 들인다. 접근-제어 결정은 그랜트 테이블의 메모리 복사본을 근거로 이루어 진다.
일반적으로, 여러분은 GRANT 와 REVOKE와 같은 명령문을 사용해서 계정을 설정하고 각 사용자가 그 권한을 사용할 수 있도록 그랜트 테이블의 컨텐츠를 사용할 수 있다. Section 13.5.1,
“계정 관리 명령문”을 참조할 것. 여기에서는 그랜트 테이블의 하부 구조와 서버가 클라이언트와 상호 통신을 할 때 그 컨텐츠를 어떻게 사용하는지에 대해 설명을 하도록 한다.
서버는 접근 제어의 두 단계 모두에서 mysql 데이터 베이스에 있는 user, db, 그리고 host 테이블을 사용한다. 아래에 user 와 db 테이블에 있는 컬럼들이 있다. host 테이블은 db 테이블과 유사
하지만, Section 5.8.6, “접근 제어, Stage 2: 요청 검증”에서 설명한 것과 같은 특별한 쓰임새를 가지고 있다.
Table Name user db
Scope columns Host Host

:::MySQL Korea:::
User Db
Password User
Privilege columns Select_priv Select_priv
Insert_priv Insert_priv
Update_priv Update_priv
Delete_priv Delete_priv
Index_priv Index_priv
Alter_priv Alter_priv
Create_priv Create_priv
Drop_priv Drop_priv
Grant_priv Grant_priv
Create_view_priv Create_view_priv
Show_view_priv Show_view_priv
Create_routine_priv Create_routine_priv
Alter_routine_priv Alter_routine_priv
Execute_priv Execute_priv
Create_tmp_table_priv Create_tmp_table_priv
Lock_tables_priv Lock_tables_priv
References_priv References_priv
Reload_priv
Shutdown_priv
Process_priv
File_priv
Show_db_priv
Super_priv
Repl_slave_priv
Repl_client_priv

:::MySQL Korea:::
Security columns ssl_type

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.3. MySQL이 제공하는 권한
5. 데이터 베이스 관리 계정 권한에 대한 정보는 mysql데이터 베이스에 있는 the user, db, host, tables_priv, columns_priv, 그리고 procs_priv테이블
5.8. MySQL 권한 시스템 에 저장된다. MySQL 서버는 시작될 때 이러한 테이블의 내용을 메모리로 읽어 들이고 Section 5.8.7, “권한변경시의효과”에서
5.8.3 MySQL이 제공하는 권한 기술한 환경이 되면 그것들을 다시 읽어 들인다. 접근-제어 결정은 그랜트 테이블의 메모리 복사본을 근거로 이루어진다.
권한을 참조하기 위한The names used in the GRANT와 REVOKE명령문에서 사용된 이름이 아래의 테이블에 있는데, 이것은 그
랜트 테이블에 있는 각각의 권한과 관련된 컬럼 이름과 그 권한이 적용되는 문장(context)와 함께 나타난다. 각 권한이 의미하는
정보에 대해서는 Section 13.5.1.3, “GRANT를 참고하기 바란다. 신텍스”
Privilege Column Context
CREATE Create_priv databases, tables, or indexes
DROP Drop_priv databases or tables
GRANT OPTION Grant_priv databases, tables, or stored routines
REFERENCES References_priv databases or tables
ALTER Alter_priv tables
DELETE Delete_priv tables
INDEX Index_priv tables
INSERT Insert_priv tables
SELECT Select_priv tables
UPDATE Update_priv tables
CREATE VIEW Create_view_priv views
SHOW VIEW Show_view_priv views

:::MySQL Korea:::
ALTER ROUTINE Alter_routine_priv stored routines
CREATE ROUTINE Create_routine_priv stored routines
EXECUTE Execute_priv stored routines
FILE File_priv file access on server host
CREATE TEMPORARY TABLES Create_tmp_table_priv server administration
LOCK TABLES Lock_tables_priv server administration
CREATE USER Create_user_priv server administration
PROCESS Process_priv server administration
RELOAD Reload_priv server administration
REPLICATION CLIENT Repl_client_priv server administration
REPLICATION SLAVE Repl_slave_priv server administration
SHOW DATABASES Show_db_priv server administration
SHUTDOWN Shutdown_priv server administration
SUPER Super_priv server administration
MySQL의 몇몇 릴리즈판에는 그랜트 테이블의 구조를 변경해서 새로운 권한 또는 기능을 추가할 수 있도록 하고 있다. 여러분이
새로운 버전의 MySQL로 업데이트를 하는 경우에는, 항상 그랜트 테이블이 새로운 버전의 기능을 포함할 수 있도록 그랜트 테이블
에 대한 갱신도 함께 해야 한다. Section 5.6.2, “mysql_upgrade를 참조할 것. —MySQL 업그레이드에대한테이블검사”
CREATE VIEW와 SHOW VIEW는 MySQL 5.0.1에서 추가 되었다. CREATE USER, CREATE ROUTINE, 그리고 ALTER
ROUTINE은 MySQL 5.0.3에 추가 되었다. 비록 5.0에 EXECUTE가 존재하기는 하지만, MySQL 5.0.3 이후부터 그 기능을 발휘
한다.
바이너리 로그가 활성화 되어 있을 때 스토어드 루틴을 생성 또는 변경하기 위해서는, 여러분은 Section 17.4, “스토어드루틴과트
리거에대한바이너리로깅”에서 언급하듯이, SUPER권한도 역시 필요할 수도 있다.
CREATE와 DROP권한은 여러분이 새로운 데이터 베이스와 테이블을 생성할 수 있게 하거나, 또는 존재하는 데이터 베이스와 테
이블을 제거할 수 있게 한다. 만약에 여러분이 사용자가 mysql데이터 베이스에 대한 DROP권한을 가지도록 승인한다면, 그 사용자
는 MySQL 접근 권한이 저장되어 있는 데이터 베이스를 제거할 수가 있다.
SELECT, INSERT, UPDATE, 그리고 DELETE권한은 여러분이 데이터 베이스에 존재하는 테이블에 있는 열에서 동작을 수행

:::MySQL Korea:::
할 수 있도록 한다.
SELECT명령문은 테이블에서 열을 실제로 추출하는 경우에만 SELECT권한을 필요로 한다. 어떤 SELECT명령문은 테이블에 접
근할 수는 없으나 데이터 베이스에 대한 권한이 없이도 실행될 수도 있는 것이 있다. 예를 들면, 여러분은 테이블을 참조하지 않는
수식을 계산하기 위해 mysql 클라이언트를 단순한 계산기로 사용할 수가 있다:
SELECT 1+1;
SELECT PI()*2;
INDEX권한은 여러분이 인덱스를 생성 또는 제거할 수 있도록 한다. INDEX는 존재하고 있는 테이블에 적용된다. 만약에 여러분
이 테이블에 대해 CREATE권한을 가지고 있다면, 여러분은 CREATE TABLE명령문안에 인덱스 정의문을 포함 시킬 수가 있다.
ALTER권한은 여러분이 테이블의 구조를 변경하거나 또는 이름을 바꿀 수 있는 ALTER TABLE을 사용할 수 있도록 한다.
CREATE ROUTINE권한은 스토어드 루틴(함수 및 프로시저)를 생성하기 위해 필요한 것이다. ALTER ROUTINE권한은 스토어
드 루틴을 변경 또는 제거하기 위해 필요하며, 또한 EXECUTE는 스토어드 루틴 실행을 위해 필요하다.
GRANT권한은 여러분 자신이 가지고 있는 권한을 다른 사용자에게 줄 수 있게끔 한다. 이것은 데이터베이스, 테이블, 그리고 스토
어드 루틴을 위해 사용될 수 있다.
FILE권한은 여러분이 서버 호스트에서 LOAD DATA INFILE and SELECT ... INTO OUTFILE명령문을 사용해서 파일을 읽고
쓸 수 있도록 해 준다. FILE권한을 가지고 있는 사용자는 서버 호스트에 있는 모든 파일을 읽을 수 있다. (이것은 그 사용자가 모
든 데이터베이스 디렉토리에 있는 모든 파일을 읽을 수가 있다는 것을 의미하는데, 그 이유는 서버가 이러한 파일들에 접근할 수 있
기 때문이다.) FILE권한은 또한 사용자가 MySQL 서버가 쓰기 권한을 가지고 있는 모든 디렉토리에 새로운 파일을 생성할 수 있
도록 해 준다. 보안상의 이유로, 서버는 현재 존재하는 파일에 덮어 쓰기를 하지는 않는다.
이제 남은 권한은 관리 동작을 위한 것이다. 대부분의 이 권한들은 mysqladmin 프로그램의 사용 또는 SQL 명령문 입력을 통해서
수행될 수 있다. 아래의 테이블은 mysqladmin 명령어를 사용해서 여러분이 실행할 수 있는 각 관리 권한을 보여 준다.:
Privilege Commands Permitted to Privilege Holders
RELOAD flush-hosts, flush-logs, flush-privileges, flush-status, flush-tables, flush-threads, refresh, reload
SHUTDOWN Shutdown
PROCESS Processlist
SUPER Kill

:::MySQL Korea:::
reload명령어는 서버가 그랜트 테이블의 내용을 메모리로 다시 읽어 들이도록 만든다. flush-privileges는 reload과 동일한 기능
을 한다. Refresh명령어는 로그 파일을 닫은 다음에 다시 열고 모든 테이블을 플러시한다. 또 다른 flush-xxx명령어는 refresh와
유사한 기능을 수행하지만, 좀더 구체적이며 어떤 인스턴스에서는 보다 많이 사용되기도 한다. 예를 들면, 만일 여러분이 로그 파일
만을 플러시 하고자 한다면, flush-logs를 사용하는 것이 refresh보다 나은 선택이 된다.
shutdown audfudd는 서버를 셧다운 시킨다. 이것과 대응되는 SQL 명령문은 없다.
processlist명령어는 서버 안에서 실행되는 쓰레드에 대한 정보를 디스플레이 한다 (즉, 클라이언트가 실행하는 명령문에 대한 정
보). kill명령어는 서버 쓰레드를 종료 시킨다. 여러분은 항상 여러분 소유의 쓰레드를 디스플레이 또는 종료 시킬 수가 있으나, 하
지만 여러분은 다른 사용자가 초기화 시킨 쓰레드를 디스 플레이 하기 위해서는 PROCESS권한이 필요하며, 그러한 쓰레드를 종
료 시키기 위해서는 SUPER권한이 있어야 한다. Section 13.5.5.3, “KILL를 참조할 것. 신텍스”
CREATE TEMPORARY TABLES권한은 CREATE TABLE명령문에 있는 키워드 TEMPORARY를 사용할 수 있도록 해 준다.
LOCK TABLES권한은 여러분이 SELECT권한을 가지고 있는 테이블을 잠그기 위해LOCK TABLES명령문을 사용할 수 있도록
한다. 이것은 쓰기 잠금을 포함하고 있는데, 이것은 누구라도 잠겨 있는 테이블을 읽지 못하도록 해준다.
REPLICATION CLIENT권한은 SHOW MASTER STATUS와 SHOW SLAVE STATUS를 사용할 수 있도록 해 준다.
REPLICATION SLAVE권한은 슬레이브 서버가 현재의 서버를 자신의 마스터로 접속하기 위해 사용하는 계정을 승인한다.. 이 권
한이 없다면, 슬레이브는 마스터 서버에 있는 데이터 베이스에서 이루어지는 업데이트를 요청할 수가 없게 된다.
SHOW DATABASES권한은 사용하는 계정이 SHOW DATABASE명령문을 이용해서 데이터 베이스의 이름을 볼 수 있도록 해
준다. 이 권한을 가지고 있지 않는 계정은 자신이 소유한 권한내의 데이터 베이스만을 볼 수 있고, 만약에 서버가 --skip-show-
database옵션을 가지고 시작되었다면, 명령문을 전혀 사용할 수가 없게 된다. 모든 글로벌 권한은 데이터 베이스에 대한 권한을 가
지고 있음을 알아두기 바란다.
계정에게는 꼭 필요한 권한만을 부여하는 것이 좋다. 여러분은 FILE과 관리 권한을 승인할 경우에는 매우 주의를 기울여야 한다:
● FILE권한은 MySQL 서버가 서버 호스트에 있는 파일을 데이터 베이스 테이블 속으로 읽어 들이기 위해 자칫 남용될 수가
있다. 이것은 서버의 데이터 디렉토리에 있는 모든 파일에 해당된다. 그런 다음에는 SELECT를 사용해서 테이블에 접근을
해서 테이블의 내용을 클라이언트 호스트에 전달할 수가 있다.
● GRANT권한은 사용자가 자신의 권한을 다른 사용자에게 줄 수 있도록 한다. 서로 다른 권한을 가지고 있는 두 명의 사용자
는 GRANT권한을 가지고 권한을 조합할 수가 있다.
● ALTER권한은 테이블의 이름을 바꾸어 줌으로서 권한 시스템을 없애 버리는데 사용할 수가 있다.
● SHUTDOWN권한은 서버를 종료 시킴으로서 다른 사용자에 대한 모든 서비스를 거부하도록 만들 수가 있다.
● PROCESS권한은 패스워드 설정 또는 변경을 진행하는 명령문을 포함해서, 현재 실행 중에 있는 명령문의 텍스트를 보기
위해 사용될 수 있다.
● SUPER권한은 다른 클라이언트를 종료시키거나 또는 서버의 동작을 변경시키는데 사용할 수 있다.

:::MySQL Korea:::
● Privileges granted for the mysql데이터 베이스 자체에 대해 승인된 권한은 패스워드와 다른 접근 권한 정보를 변경시키
는데 사용될 수 있다. 패스워드는 암호로 저장된다. 하지만, However, a user with write access to the user테이블의
Password컬럼에 쓰기 접근을 할 수 있는 사용자는 계정의 패스워드를 변경할 수 있으며, 그리고 그 계정을 사용해서
MySQL 서버에 접속을 할 수가 있게 된다.
MySQL 권한 시스템을 가지고 할 수 없는 일이 몇 가지가 있다:
● 여러분은 특정 사용자의 접근을 거부하도록 확정적으로 지정할 수가 없다. 즉, 여러분은 어떤 사용자와 접속 거부를 명백하
게 매치(match)시킬 수가 없다.
● 여러분은 어떤 사용자가 데이터 베이스 자체를 생성 또는 삭제하지 않고, 데이터 베이스에 들어 있는 테이블을 생성 또는
삭제할 수 있는 권한을 가지도록 지정할 수는 없다.
● 패스워드는 글로벌하게 하나의 계정에 적용된다. 여러분은 패스워드를 데이터 베이스, 테이블, 또는 루틴과 같은 특정 오브
젝트에 연관 시킬 수가 없다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.4. MySQL 서버에 접속하기

MySQL 클라이언트 프로그램은 일반적으로 여러분이 MySQL 서버에 접근을 할 때 특정 접속 파라미터를 지정하기를 기대한다:
5.8. MySQL 권한 시스템 ● MySQL 서버가 구동되고 있는 호스트의 이름 is running
5.8.4 MySQL 서버에 접속하기 ● 여러분의 사용자 이름

● 여러분의 패스워드
예를 들면, mysql클라이언트는 명령어 라인 프롬프트에서 아래와 같이 시작될 수 있다:
shell> mysql -h host_name -u user_name -pyour_pass
-h, -u, 그리고 -p옵션의 다른 방식은 --host=host_name, --user=user_name, 그리고 --password=your_pass이다. -p

또는 --password=과 뒤따라오는 패스워드간에는 스페이스가 없어야 한다.
만약에 여러분이 -p또는 --password옵션을 사용하면서 패스워드 값을 지정하지 않으면, 클라이언트 프로그램은 패스워드를 입
력하도록 프롬프트를 내 보내게 된다. 이 방법이 명령어 라인에 패스워드를 표시하는 것보다 더 안전한 방법이다. 어떤 사용자라도
명령어 라인에서 ps auxww와 같은 명령어를 실행하면 여러분이 명령어 라인에 지정했던 패스워드를 볼 수가 있다.
Section 5.9.6, “패스워드보안유지하기”를 참조.
MySQL 클라이언트 프로그램은 여러분이 지정하지 않는 접속 파라미터 옵션에 대해서는 디폴트 값을 사용한다:
● 디폴트 호스트 이름은 localhost.

● 디폴트 사용자 이름은 윈도우에서는 ODBC이고 유닉스에서는 여러분의 유닉스 로그인 이름이 된다.
● -p또는 –password중에 아무것도 주어지지 않으면, 패스워드는 지정되지 않는다.
따라서, joe라는 로그인 이름을 가지고 있는 유닉스 사용자에 대해서는, 아래의 모든 명령어가 동일한 것이 된다:
shell> mysql -h localhost -u joe

:::MySQL Korea:::
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql
다른 MySQL 클라이언트도 비슷하게 동작을 한다.

여러분은 클라이언트 프로그램을 호출할 때마다 명령어 라인에 매번 입력하는 수고를 피하기 위해 서버에 접속할 때 사용되는 디폴
트 값을 달리 지정할 수가 있다. 이것은 여러 가지 방법으로 실행할 수가 있다:
● 여러분은 옵션 파일의 [client]섹션에 접속 파라미터를 지정할 수가 있다. 이 파일에 관련된 섹션은 아래와 같다:
• [client]
• host=host_name
• user=user_name
• password=your_pass
Section 4.3.2, “옵션파일사용하기”를 참조 할 것.
● 여러분은 환경 변수를 사용해서 몇몇 접속 파라미터를 지정할 수가 있다. Mysql에 대한 호스트는 MYSQL_HOST를 사용

해서 지정할 수가 있다. MySQL 사용자 이름은 USER를 사용해서 지정할 수가 있다(이것은 윈도우와 NetWare에만 해당
함). 비록 보안에 문제가 있기는 하지만, 패스워드는 MYSQL_PWD를 사용할 수가 있다; Section 5.9.6, “패스워드보안유
지하기”를 참조. 변수의 리스트에 대해서는, Appendix F, Environment Variables를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.5. 접근 제어, Stage 1: 접속 검증

여러분이 MySQL 서버에 접속을 시도할 때, 서버는 여러분의 ID와 패스워드를 근거로 접속을 허용하거나 거부를 하게 된다. 여러
5. 데이터 베이스 관리 분의 ID와 패스워드가 올바른 것으로 판명되면, 서버는 Stage 2 로 들어가고 여러분의 요청 사항을 기다리게 된다.
5.8. MySQL 권한 시스템 여러분의 ID는 다음의 두 가지 정보를 기초로 한다:
● 여러분이 접속하는 클라이언트 호스트
● 여러분의 MySQL 사용자 이름
ID 검사는 세 가지의 user테이블 범위 컬럼을 사용해서 수행된다 (Host, User, 그리고 Password). 서버는 user테이블에 있는
Host와 User컬럼의 열이 클라이언트의 호스트 이름 및 사용자 이름과 일치할 경우에만 접속을 허용하고, 클라이언트는 그 열에서
지정되어 있는 패스워드를 주게 된다.
user테이블에 있는 Host값은 아래와 같이 지정될 수 있다:
● Host값은 호스트 이름 또는 IP 번호가 될 수 있거나, 또는 'localhost'는 로컬 호스트를 가리킨다.

● 여러분은 Host컬럼 값에 와일드카드 문자 ‘%’ 및 ‘_’를 사용할 수 있다. 이 문자들은 LIKE연산자와 함께 실행되는
패턴-매칭(pattern-matching) 동작과 동일하게 사용된다. 예를 들면, '%'의 Host값은 모든 호스트 이름과 매치가 되는
데 비해서, '%.mysql.com'값은 mysql.com도메인에 있는 모든 호스트와 매치가 된다.
● IP 번호로 지정된 Host값에 대해서는, 네트워크 번호를 위해서 얼마나 많은 주소 비트(bit)를 사용하고 있는지를 가리키
는 넷마스크(netmask)를 지정할 수가 있다. 예를 들면:
· GRANT ALL PRIVILEGES ON db.* TO david@'192.58.197.0/255.255.255.0';
위의 예에서 보면, david는 아래의 조건이 일치하는 경우에는 IP 번호 client_ip를 가지고 있는 어떤 호스트에서도 접속을
할 수가 있게 된다:
client_ip & netmask = host_ip

:::MySQL Korea:::
즉, GRANT명령문은 아래와 같이 보인다:
client_ip & 255.255.255.0 = 192.58.197.0
이 조건을 만족하고 MySQL 서버에 접속을 할 수 있는 IP 번호는 192.58.197.0 에서 192.58.197.255사이의 범위 내에

있는 것들이 된다.
Note: 넷마스크(netmask)는 서버가 8, 16, 24, or 32 비트의 주소를 사용하도록 할 때에만 사용될 수 있다. 예를 들면:
❍ 192.0.0.0/255.0.0.0: 192 클래스 A 네트워크에 있는 호스트

❍ 192.168.0.0/255.255.0.0: 192.168 클래스 B 네트워크에 있는 호스트
❍ 192.168.1.0/255.255.255.0: 192.168.1 클래스 C 네트워크에 있는 호스트
❍ 192.168.1.1: 이 IP에만 한정
아래의 넷마스크는 (28 비트) 동작하지 않는다:
192.168.0.1/255.255.255.240
● db테이블 열의 빈 Host값은 그 값의 권한이 host테이블에 있는 열 중에서 클라이언트의 호스트 이름과 일치는 열의 권한

과 조합을 해야 한다는 것을 의미한다. 권한은 AND (intersection) 연산을 사용해서 조합 되며, OR (union)를 통해서 만
들어지지는 않는다. Section 5.8.6, “접근 제어, Stage 2: 요청 검증”를 참조할 것.
다른 그랜트 테이블에 있는 빈 Host값은 '%'과 동일하다.

여러분이 Host컬럼에 IP 와일드카드 값을 사용할 수 있기 때문에 (예를 들면, 서브넷 상에 있는 모든 호스트를 매치하기 위한
'144.155.166.%'), 어떤 사람들은 호스트의 이름을 144.155.166.somewhere.com로 해서 이러한 기능을 활용하고자 할 것이다.
이러한 시도를 하지 못하게 하기 위해서, MySQL은 숫자 및 점(dot)으로 시작하는 호스트 이름에서는 매칭을 허용하지 않는다. 따
라서, 만약에 여러분이 1.2.foo.com과 같은 이름의 호스트를 가지고 있다면, 이 이름은 그랜트 테이블의 Host컬럼과는 결코 매칭
이 되지 않게 된다. IP 와일드카드 값은 IP 번호에만 매치되며, 호스트 이름에는 매치되지 않는다.
User컬럼에서, 와일드카드 문자는 허용되지 않지만, 여러분은 비어있는 값(blank value)를 지정해서 모든 이름을 매칭시킬 수가
있다. 만약에 들어오는 접속과 매치되는 user테이블의 열이 빈(blank) 사용자 이름이라면, 사용자는 이름이 없는 익명의 사용자로
간주되며, 클라이언트가 실제로 지정한 이름을 갖는 사용자로 간주되지 않는다. 이것은 빈 사용자 이름을 접속이 되어 있는 동안
(즉, Stage 2 동안)에 모든 다른 접근을 검사할 목적으로 사용한다는 의미이다

:::MySQL Korea:::
Password컬럼은 비워둘 수가 있다. 이것은 와일드카드 문자가 아니며 모든 패스워드와 매칭을 한다는 것을 의미하는 것은 아니
다. 이것은 사용자가 반드시 패스워드를 지정하지 않고 접속을 해야 한다는 것을 의미한다.
user테이블에 비어 있지 않는(Non-Blank) Password값은 암호화 되어 있게 된다. MySQL은 무든 사람이 볼 수 있는 평범한 문
장으로 패스워드를 저장하지는 않는다. 반면에, 접속을 시도하는 사용자가 입력한 패스워드는 암호화가 된다 (PASSWORD()함수
를 사용한다). 암호화된 패스워드는 접속이 이루어지는 동안 계속 사용된다. 암호화된 패스워드는 관리자 이외에는 절대로 알려 주
지 말아야 한다.
MySQL 5.0은 접속 프로세스가 진행되는 동안 패스워드를 보호하기 위해 이전 버전에 비해 보다 강력한 인증 방식을 구현하였다.
이 방식은 TCP/IP 패킷 또는 mysql데이터 베이스가 해킹을 당하더라도 안전을 보장한다. Section 5.8.9, “MySQL 4.1 이후의패
스워드해싱”을 참조할 것.
아래의 테이블은 user테이블에 있는 Host와 User값의 조합이 들어오는 접속에 대해 얼마나 다양하게 적용될 수 있는지를 보여준
다.
Host Value User Value Allowable Connections
'thomas.loc.gov' 'fred' fred, connecting from thomas.loc.gov
'thomas.loc.gov' '' Any user, connecting from thomas.loc.gov
'%' 'fred' fred, connecting from any host
'%' '' Any user, connecting from any host
'%.loc.gov' 'fred' fred, connecting from any host in the loc.gov domain
fred, connecting from x.y.net, x.y.com, x.y.edu, and so on (this is

'x.y.%' 'fred'
probably not useful)
'144.155.166.177' 'fred' fred, connecting from the host with IP address 144.155.166.177
'144.155.166.%' 'fred' fred, connecting from any host in the 144.155.166 class C subnet
'144.155.166.0/255.255.255.0' 'fred' Same as previous example
다중 매치가 가능할 경우, 서버는 반드시 어떤 것을 사용할지를 결정해야 한다. 서버는 이 문제를 다음과 같이 해결한다:
● 서버가 user테이블을 메모리로 읽어 올 때마다, 서버는 열을 정렬한다.

● 클라이언트가 접속을 시도할 때, 서버는 정렬된 순서로 열을 검사한다.
● 서버는 클라이언트의 호스트 이름과 사용자 이름이 일치하는 맨 처음의 열을 사용한다.

:::MySQL Korea:::
위의 동작이 진행되는 것을 보기 위해서, user테이블이 아래와 같이 되어 있다고 가정하자:
+-----------+----------+-
| Host | User | ...
+-----------+----------+-
|% | root | ...
|% | jeffrey | ...
| localhost | root | ...
| localhost | | ...
+-----------+----------+-
서버가 테이블의 내용을 메모리로 읽어 올 때, 서버는 Host값 중에서 가장 명확하게 사용되고 있는 것을 가지고 열을 정렬한다. 문
자로 된 호스트 이름과 IP 번호가 가장 명확한 것이다. 패턴 '%'는 “모든 호스트(any host)”를 의미하며 가장 일반적인 것이 된
다. 동일한 Host값을 가지는 열은 가장 명확한 User값을 가지고 우선 정렬이 된다 (빈 User값은 “모든 사용자(any user)”를 의
미하며 가장 일반적인 것이 된다). user테이블에서 보듯이, 정렬의 결과는 다음과 같이 보이게 된다:
+-----------+----------+-
| Host | User | ...
+-----------+----------+-
| localhost | root | ...
| localhost | | ...

:::MySQL Korea:::
|% | jeffrey | ...
|% | root | ...
+-----------+----------+-
클라이언트가 접속을 시도할 때, 서버는 정렬된 열을 검사하고 처음으로 매치되는 값을 사용한다. For a connection from by
jeffrey가 localhost에서 한 접속의 경우, 테이블의 열 중에 두 개가 일치를 한다: 하나는 'localhost'와 ''의 Host와 User열이고, 다
른 하나는 '%'와 'jeffrey'의 열이다. 'localhost'열이 정렬된 순서에서 처음으로 나타나며, 따라서 서버는 이것을 사용한다.
여기에 다른 예가 있다. user테이블이 아래와 같다고 가정하자:
+----------------+----------+-
| Host | User | ...
+----------------+----------+-
|% | jeffrey | ...
| thomas.loc.gov | | ...
+----------------+----------+-
정렬된 테이블은 다음과 같다:
+----------------+----------+-
| Host | User | ...
+----------------+----------+-
| thomas.loc.gov | | ...

:::MySQL Korea:::
|% | jeffrey | ...
+----------------+----------+-
jeffrey가 thomas.loc.gov에서 한 접속에서는 처음의 열이 일치를 하고, 반면에 jeffrey가whitehouse.gov에서 한 접속에서는 두

번째가 일치를 하게 된다.
만약에 여러분이 서버에 접속은 할 수가 있지만, 여러분이 하고자 하는 일에 대해서는 권한을 가지고 있지 않다면, 여러분은 다른
계정의 형태로 인증을 받아야 한다. 서버가 여러분을 인증하는데 사용하는 계정이 어떤 것인지를 알기 위해서는,
CURRENT_USER()함수를 사용한다. (Section 12.9.3, “정보함수”를 참조.) 이 함수는 일치하는 user테이블 열에서 User와
Host값을 가리키는 user_name@host_name형태의 값을 리턴한다. Jeffrey가 접속을 해서 아래의 쿼리를 입력한다고 가정하자:
mysql> SELECT CURRENT_USER();
+----------------+
| CURRENT_USER() |
+----------------+
| @localhost |
+----------------+
여기에 나타나 있는 결과는 매칭된 user테이블의 열이 빈 User컬럼 값을 가지고 있다는 것을 가리킨다. 달리 표현하면, 서버는
jeffrey를 익명의 사용자로 취급하고 있다는 것이다.
여러분이 인증 문제를 진단하기 위해 할 수 있는 방법 중의 하나는 user테이블을 출력해서 일일이 손으로 첫 번째 매칭되는 것을
찾는 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.6. 접근 제어, Stage 2: 요청 검증

여러분이 접속을 한 다음에는, 서버는 접근 제어의 Stage 2로 들어 간다. 여러분이 접속 상태에서 입력하는 각각의 요청에 대해, 여
5. 데이터 베이스 관리 러분이 원하는 서버의 동작이 무엇인지를 판단하고, 그런 다음에 여러분이 그러한 요청을 할 만한 충분한 권한을 가지고 있는지를
5.8. MySQL 권한 시스템 검사한다. 이것은 그랜트 테이블의 권한 컬럼이 진행을 한다. 이러한 권한은 user, db, host, tables_priv, columns_priv, 또는
5.8.6 접근 제어, Stage 2: 요청 검증 procs_priv테이블로부터 올 수 있다. (Section 5.8.2, “권한시스템이어떻게동작하는가”를 참조 할 것.)
user테이블은 글로벌 기반으로 여러분에게 할당이 되고 디폴트 데이터 베이스에는 상관 없이 적용되는 권한을 승인한다. 예를 들
면, 만약에 user테이블이 여러분의 DELETE권한을 승인한다면, 여러분은 서버 호스트에 있는 데이터 베이스의 어떤 데이터 베이
스에서든지 열을 삭제할 수가 있게 된다! 달리 말하면, user테이블 권한은 superuser 권한인 것이다. It is wise to grant
privileges in the user테이블에 대한 권한은 데이터 베이스 관리자와 같은 사람에게만 부여하는 것이 현명하다.
db와 host테이블은 데이터 베이스-관련 권한을 승인한다. 이러한 테이블에 있는 범위 컬럼내의 값은 아래의 형태를 가지게 된다:
● 와일드카드 문자 ‘%’ 와 ‘_’ 는 각 테이블의 Host와 Db컬럼에서 사용할 수 있다. 이 문자들은 LIKE연산자와 함께 실
행되는 패턴-매칭 동작과 동일한 의미를 가진다. 만약에 여러분이 권한을 승인할 때 이들 문자를 사용하고자 한다면, 백슬
레시를 가지고 문자를 종료 시켜야 한다. 예를 들면, 데이터 베이스 이름에 (‘_’)문자를 포함 시키고자 한다면, GRANT
명령문에서 이름을 ‘￦_’형태로 지정한다.
● db테이블에 있는 '%'Host값은 “모든 호스트( any host)”를 의미한다. Host값을 비어 두면 “host테이블을 나중에 참
조”한다는 의미가 된다.
● host테이블의 '%'또는 비어 있는 Host값은 “모든 호스트(any host)”를 의미한다.
● db 또는 host테이블의 값이 '%'또는 비어 있는 Db값이 되면 “모든 데이터 베이스(any database)”를 의미하게 된다.
● 두 테이블에서 User값이 비게 되면 익명의 사용자를 매치하게 된다.
서버는 db와 host테이블을 메모리로 읽어 오며 서버가 user테이블을 읽을 때 동시에 메모리로 읽어온 내용을 정렬한다. 서버는 db
테이블을 Host, Db, 그리고 User범위 컬럼을 근거로 정렬하며, host테이블은 Host및 Db범위 컬럼을 근거로 정렬한다. user테이
블을 사용하기 때문에, 정렬은 가장 특징적인 값을 우선 사용하고 가장 일반적인 값을 맨 나중에 사용하며, 그리고 서버가 매칭된
엔트리를 검사할 때, 처음으로 매칭된 것을 사용하게 된다.
tables_privcolumns_priv, 그리고 proc_priv테이블은 테이블-특성(table-specific), 컬럼-특성(column-specific), 그리고 루

:::MySQL Korea:::
틴-특성(routine-specific) 권한을 승인한다. 이러한 테이블내의 범위 컬럼에 있는 값은 아래의 형태를 따르게 된다:
● 와일드카드 문자 ‘%’ 와 ‘_’ 는 Host컬럼에서 사용할 수 있다. 이 문자들은 LIKE연산자와 함께 실행되는 패턴-매칭
동작과 동일한 의미를 가진다
● '%'또는 비어 있는Host값은 “모든 호스트(any host)”를 의미한다.
● Db, Table_name, 그리고 Column_name컬럼은 와일드카드 또는 비어있는 값을 가질 수가 없다.
서버는 Host, Db, 그리고 User컬럼을 근거로 tables_priv, columns_priv, 그리고 procs_priv테이블을 정렬한다. 이것은 db테이
블을 정렬하는 것과 비슷하지만, Host컬럼만이 와일드 카드 문자를 가질 수 있기 때문에 보다 단순하게 진행된다.
서버는 들어오는 각각의 요청을 검증하기 위해 정렬된 테이블을 사용한다. SHUTDOWN또는 RELOAD와 같은 관리적인 권한을
요구하는 요청에 대해서, 서버는 user테이블의 열만을 검사하는데, 그 이유는 이 테이블만이 관리적인 권한을 지정하기 때문이다.
서버는 그 열이 요청된 동작을 허용할 경우에 접근을 승인하며, 그 반대일 경우에는 거절을 한다. 예를 들면, 만일 여러분이
mysqladmin shutdown를 실행하고자 원하지만 여러분의 user테이블 열이 여러분의 SHUTDOWN권한을 승인하지 않을 경우, 서
버는 db또는 host테이블에 대한 검사를 하지도 않고 거절을 하게 된다. (이 테이블들에는 Shutdown_priv컬럼이 없으므로, 이것들
을 검사할 필요가 없게 된다.)
데이터 베이스에 관련된 요청 (INSERT, UPDATE, 등등)에 대해서는, 서버는 우선 사용자의 글로벌 (superuser) 권한을 user테
이블 열을 가지고 검사를 한다. 만일 그 열이 요청된 동작을 허용할 경우, 접근이 승인된다. 만약에 이 테이블에 있는 글로벌 권한
이 충분하지 않다면, 서버는 db와 host테이블을 검사해서 사용자의 데이터 베이스 관련 권한을 판단한다:
1. 서버는 Host, Db, 그리고 User컬럼의 매치를 위해 db테이블을 검사한다. Host와 User컬럼은 사용자의 호스트 이름
과 MySQL 사용자 이름간의 연결에 매치된다. Db컬럼은 사용자가 접근하고자 하는 데이터 베이스와 매치가 된다. 만약
에 Host와 User를 위한 열이 없다면, 접근은 거부된다.
2. 만약에 매칭되는 db테이블 열이 있고 그 열의 Host컬럼이 비어 있지 않다면, 그 열은 사용자의 데이터 베이스-특성
권한을 정의하는 것이다.
3. 만약에 매칭되는 db테이블 열의 Host컬럼이 비어 있다면, 이것은 host테이블이 데이터 베이스에 접근이 허용된 호
스트를 모두 열거한다는 것을 의미한다. 이와 같은 경우, Host와 Db컬럼에 매치되는 것을 host테이블에서 찾는 동작이 진
행된다. 아무런 host테이블 열도 매치가 되지 않으면, 접근은 거부된다. 만약에 매치되는 것이 있으면, 사용자의 데이터 베
이스-특성 권한은 db와 host테이블 엔트리에 있는 권한의 교집합(intersection)의 형태로 계산된다 (합집합(union)이
아님); 즉, 양쪽 엔트리엣 'Y'인 권한.
db와 host테이블 엔트리가 승인한 데이터베이스-특성 권한을 결정한 후에, 서버는 이 권한들을 user테이블이 승인하는 글로벌 권
한에 추가한다. 만일 그 결과가 요청 받은 동작을 허용하면, 접근이 승인된다. 그렇지 않으면, 서버는 tables_priv와 columns_priv
테이블에 있는 사용자 테이블과 컬럼 권한을 계속해서 검사를 하며, 그것들을 사용자의 권한에 추가하고, 그리고 그 결과를 가지고

:::MySQL Korea:::
승인 또는 거절을 한다. 스토어드 루틴 동작의 경우, 서버는 tables_priv와 columns_priv가 아닌 procs_priv테이블을 사용한다.
불리안 형식의 수식을 사용하면, 위에서 설명한 사용자 권한을 계산하는 동작 방식은 아래와 같이 정리할 수가 있다:
global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges
OR routine privileges
글로벌 user열 권한이 요청 받은 동작에 대해 초기에 만족스럽지 못한 경우, 서버가 그러한 권한을 데이터 베이스, 테이블, 그리고
컬럼 권한에 나중에 추가하는 이유에 대해서는 분명하지 않을 수도 있다. 그 이유는 요청 동작이 하나 이상의 권한 형태를 요구하
기 때문이다. 예를 들면, 만약에 여러분이 INSERT INTO ... SELECT명령문을 실행한다면, 여러분은 INSERTSELECT에 대한
권한이 필요하게 된다. 여러분의 권한은 user테이블의 열이 하나의 권한을 승인하고 db테이블의 열이 다른 권한을 승인하는 형태
가 될 것이다. 이와 같은 경우, 여러분은 요청 받은 동작을 수행할 수 있는 충분한 권한을 가지게 되지만, 서버는 양 쪽 테이블에 이
러한 것을 알려줄 수가 없게 된다; 양쪽 테이블의 엔트리가 승인한 권한들은 반드시 연결이 되어야 한다.
host테이블은 GRANT또는 REVOKE명령문이 영향을 주지 않는데, 따라서 대부분의 MySQL 설치에서는 사용되지 않는다. 만약
에 여러분이 이것을 직접 수정한다면, 여러분은 이것을 보안 서버 리스트 관리와 같은 몇몇 특별한 목적으로 사용할 수가 있다. 예
를 들면, TcX에서, host테이블은 로컬 네트워크에 있는 모든 머신의 리스트를 가지고 있다. 이것들은 모든 권한을 승인한다.
여러분은 또한 host테이블을 사용해서 안전하지 못한 호스트를 가리킬 수도 있다. 여러분이 안전하지 못하다고 생각하는 공중망에
존재하는 public.your.domain라는 머신을 가지고 있다고 가정하자. 여러분은 아래와 같은 host테이블을 사용하여 그 머신을 제외
한 모든 호스트가 접근을 할 수 있도록 만들 수가 있다:
+--------------------+----+-
| Host | Db | ...
+--------------------+----+-

:::MySQL Korea:::
| public.your.domain | % | ... (all privileges set to 'N')
| %.your.domain | % | ... (all privileges set to 'Y')
+--------------------+----+-

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.7. 권한 변경시의 효과
5. 데이터 베이스 관리 Mysqld이 시작이 될 때, 서버는 모든 그랜트 테이블의 내용을 메모리로 읽어 온다. 메모리에 있는 테이블은 그 시점부터 접근 제어
5.8. MySQL 권한 시스템 에 효력을 나타낸다.
서버가 그랜트 테이블을 다시 읽어 올 때, 현재 존재하는 클라이언트 접속에 대한 권한은 아래와 같이 영향을 받는다:
● 테이블과 컬럼의 권한 변경은 클라이언트의 다음 요청에 영향을 준다.

● 데이터 베이스 권한 변경은 다음 번의 USE db_name 명령문에 영향을 준다.
● 글로벌 권한 및 패스워드의 변경은 클라이언트가 다음에 접속을 할 때 영향을 준다.
만약에 여러분이 GRANT, REVOKE, 또는 SET PASSWORD와 같은 명령문을 사용해서 간접적으로 그랜트 테이블을 수정한다
면, 서버는 이러한 변경 사항을 인지하게 되고 그랜트 테이블을 메모리고 즉시 다시 읽어 온다.
만약에 INSERT, UPDATE, 또는 DELETE와 같은 명령문을 사용해서 그랜트 테이블을 직접 수정한다면, 여러분이 서버를 다시
시작하거나 또는 서버가 그랜트 테이블을 다시 읽어 오도록 만들 때까지 변경 사항이 적용되지 않는다. 그랜트 테이블을 수동으로
읽어 오기 위해서는 FLUSH PRIVILEGES 명령문을 입력하거나 또는 mysqladmin flush-privileges 또는 mysqladmin reload
명령어를 실행한다.
만약에 그랜트 테이블을 직접 수정하였지만 다시 읽어 오는 것을 잊었을 경우에는, 서버가 재 구동 되기 전까지는 변경 사항이 적용

되지 않는다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.8. 접근 거부 에러의 원인

만약에 여러분이 MySQL 서버에 접속을 시도할 때 문제가 발생한다면, 아래의 과정 중에 하나를 가지고 문제를 해결하기 바라다.
5.8. MySQL 권한 시스템 ● 서버가 구동되고 있는지를 확인한다. 만약에 아래와 같은 에러가 나오는 원인 중의 하나는, 서버가 구동을 하고 있지 않는
5.8.8 접근 거부 에러의 원인 것이다:
· shell> mysql
· ERROR 2003: Can't connect to MySQL server on 'host_name' (111)
· shell> mysql
· ERROR 2002: Can't connect to local MySQL server through socket
· '/tmp/mysql.sock' (111)
서버는 구동을 하고 있다고 한다면, TCP/IP 포트, 네임드 파이프, 또는 유닉스 소켓 파일등을사용해서 서버에 접속을 다
시 시도해 본다. 클라이언트 프로그램을 호출할 때 이 문제를 해결하기 위해서는, --port옵션을 사용해서 포트 번호를 지
정하고, 또는 --socket옵션을 사용해서 네임드 파이프 또는 유닉스 소켓 파일의 이름을 지정한다. 소켓 파일이 있는 곳
을 알아내기 위해서는, 아래의 명령어를 사용한다:
shell> netstat -ln | grep mysql
● 서버가 접근 제어를 하는데 올바르게 사용할 수 있도록 그랜트 테이블이 정확히 설정되어야 한다. 몇몇 배포판의 경우 (윈
도우상의 바이너리 배포판, 또는 리눅스의 RPM 등), 설치 과정에서 그랜트 테이블을 가지고 있는 mysql데이터 베이스를
초기화 시킨다. 이러한 일을 하지 못하는 배포판의 경우, 여러분은 mysql_install_db 스크립트를 사용해서 수동으로 그랜
트 테이블에 대한 초기화를 해 주어야 한다 Section 2.9.2, “유닉스설치후처리프로세스”를 참조.

:::MySQL Korea:::
여러분이 그랜트 테이블을 초기화 시켜야 하는지를 판단할 수 있는 한 가지 방법은 데이터 디렉토리 밑에 있는 mysql디렉
토리를 검사하는 것이다. (데이터 디렉토리는 보통 data또는var라는 이름으로 되어 있고 MySQL 설치 디렉토리 아래에
있다.) mysql데이터 디렉토리에 user.MYD라는 이름의 파일을 가지고 있는지 확인한다. 만약에 없다면,
mysql_install_db스크립트를 실행한다. 이 스크립트를 실행하고 서버를 재 시작한 다음에, 아래의 명령어를 실행해서 초
기 권한을 테스트한다:
shell> mysql -u root test
이렇게 하면, 여러분은 에러없이 서버에 접속할 수 있게 된다.
● MySQL 설치를 갱신한 후에는, 여러분은 서버에 접속을 해서 여러분의 사용자와 사용자들의 접근 허용을 설정해야 한다:
· shell> mysql -u root mysql
● 만약에 이미 설치되어 있는 MySQL을 새로운 버전으로 업그레이드를 하였다면, 여러분은 mysql_upgrade 스크립트를 다
시 실행하였는가? 만약에 하지 않았다면, 이것을 실행한다. 그랜트 테이블의 구조는 새로운 기능이 추가되면 변경이 되며,
따라서 버전 업그레이드를 한 후에는, 여러분은 항상 테이블이 새로운 버전의 구조를 가지고 있도록 만들어야 한다. 이렇
게 하는 방법은 Section 5.6.2, “mysql_upgrade를 참조하기 바란다. —MySQL 업그레이드를위한테이블검사하기”
● 만약에 클라이언트 프로그램이 서버에 접속을 할 때 아래와 같은 에러 메시지를 받게 된다면, 이것은 클라이언트가 만들어
내는 포맷이 아닌 새로운 포맷의 패스워드를 서버가 요청한다는 것을 의미한다:
· shell> mysql
· Client does not support authentication protocol requested
· by server; consider upgrading MySQL client
이것을 다루는 방법에 대해서는 Section 5.8.9, “MySQL 4.1 이후의패스워드해싱”, 및Section A.2.3, “Client does
not support authentication protocol”를 참조하기 바란다.
● 만약에 여러분이 root사용자로 접속을 시도할 때 아래와 같은 에러를 받게 되면, 이것은 user테이블에서 'root'값의 User

:::MySQL Korea:::
컬럼을 가지고 있는 열을 여러분이 가지고 있지 않다는 것과 mysqld이 여러분의 클라이언트를 위한 호스트 이름을 해석하
지 못하고 있다는 것을 의미한다:
· Access denied for user ''@'unknown' to database mysql
이와 같은 경우, 여러분은 --skip-grant-tables옵션을 가지고 서버를 재 시작해야 하고 여러분이 사용하는 호스트를 위

한 엔트리를 추가하기 위해 /etc/hosts파일 또는 ￦windows￦hosts파일을 편집해야 한다.
● 클라이언트 프로그램은 옵션 파일 또는 환경 변수에서 지정하는 접속 파라미터를 사용한다는 것을 기억하기 바란다. 만약

에 클라이언트 프로그램이 여러분이 명령어 라인에서 접속 파라미터를 지정하지 않을 때 틀린 디폴트 접속 파라미터를 보
낸다고 생각되면, 여러분이 지정한 환경 변수와 적용 되는 옵션 파일을 검사하기 바란다. 예를 들면, 만일 여러분이 아무런
옵션 없이 클라이언트를 구동할 때 Access denied라는 에러를 받게 된다면, 여러분의 옵션 파일들 안에 이전의 패스워드
타입을 지정하지 않았는지를 확인한다!
여러분은 클라이언트 프로그램을 호출할 때 --no-defaults옵션을 사용함으로써 옵션 파일을 사용하지 못하도록 할 수

가 있다. 예를 들면:
shell> mysqladmin --no-defaults -u root version
● 만일 아래와 같은 에러가 나온다면, 이것 root패스워드를 잘 못 사용했다는 것을 의미한다:
· shell> mysqladmin -u root -pxxxx ver
· Access denied for user 'root'@'localhost' (using password: YES)
만약에 여러분이 아무런 패스워드도 지정하지 않았는데도 위와 같은 에러가 나온다면, 이것은 여러분이 옵션 파일들 중에
한곳에 잘못된 패스워드를 넣어 두었다는 것을 의미한다. 위에 나온 것을 가지고 --no-defaults옵션을 사용해서 다시
한번 시도한다.
만약에 root패스워드를 잊었다면, 패스 워드 변경을 위해 mysqld를 --skip-grant-tables옵션을 사용해서 재 시작한
다. Section A.4.1, “How to Reset the Root Password”를 참조.
● 만약에 SET PASSWORD, INSERT, 또는 UPDATE를 사용해서 패스워드를 변경한다면, 여러분은 반드시 PASSWORD

:::MySQL Korea:::
()함수를 사용해서 패스워드를 암호화 해야 한다. 만약에 PASSWORD()를 사용하지 않는다면, 패스워드는 동작을 하지
않게 된다. 예를 들면, 아래의 명령문은 패스워드를 설정하기는 하지만, 암호화를 하지 못하며, 따라서 사용자는 접속을 할
수가 없게 된다:
· SET PASSWORD FOR 'abe'@'host_name' = 'eagle';
대신에, 아래와 같이 패스워드를 설정한다:
SET PASSWORD FOR 'abe'@'host_name' = PASSWORD('eagle');
PASSWORD()함수는 여러분이 GRANT또는CREATE USER명령문, 또는 mysqladmin password 명령어를 사용해서

패스워드를 지정할 때에는 필요가 없게 된다. 이것들은 자동으로 PASSWORD()를 사용해서 패스워드를 암호화 시킨다.
Section 5.9.5, “계정패스워드할당하기”, 그리고 Section 13.5.1.1, “CREATE USER 신텍스”를 참조할 것.
● localhost는 여러분의 로컬 호스트 이름과 동의어이며, 이것은 또한 여러분이 호스트를 명확하게 지정하지 않을 경우에 클
라이언트가 접속을 시도하는 디폴트 호스트가 된다.
● 만약에 여러분이 mysql -u user_name를 사용해서 데이터 베이스에 접속을 시도할 때 Access denied라는 에러가 생긴
다면, 여러분은 user테이블에 문제를 가지고 있는 것이다. mysql -u root mysql를 실행하고 아래의 SQL 명령문을 입력
해서 이 이 테이블을 검사한다:
· SELECT * FROM user;
결과 값에는 여러분의 시스템 호스트 이름과 MySQL 사용자 이름에 매치되는 Host와 User컬럼을 가지는 열이 있을 것이
다.
● Access denied에러는 여러분이 어떤 사용자 이름으로 로그인을 시도하고 있는지, 어떤 클라이언트 호스트에서 접속을 하
고자 하는지, 그리고 패스워드를 사용하고 있는지를 알려준다. 일반적으로, 여러분은 에러 메시지에 나와 있는 호스트 이름
과 사용자 이름에 정확히 매치되는 열을 user테이블에 가지고 있어야 한다. 예를 들면, 만약에 여러분이 using password:
NO가 포함된 에러 메시지를 받게 된다면, 이것은 여러분이 패스워드 없이 로그인을 시도하였다는 것을 의미한다.
● 만약에 MySQL 서버가 구동되고 있는 서버가 아닌 다른 호스트에서 접속을 시도할 때 아래와 같은 에러가 발생한다면, 이
것은 클라이언트 호스트와 매치되 Host값을 가진 user테이블 열이 존재하지 않는다는 것을 의미한다:

:::MySQL Korea:::
· Host ... is not allowed to connect to this MySQL server
여러분은 접속을 시도할 때 클라이언트의 호스트 이름과 사용자 이름에 대한 계정을 설정해서 이 문제를 해결할 수가 있
다.
만약에 접속을 시도하는 시스템의 IP 번호 또는 호스트 이름을 모른다면, user 테이블에 있는 Host컬럼 값에 '%'를 넣는
다. 클라이언트 머신에서 접속을 시도한 후에는, SELECT USER()쿼리를 사용해서 여러분이 실제로 접속을 했는지 확인
한다. (그런 다음에 user테이블 열의 '%'값을 로그에서 찾은 실제 호스트 이름으로 바꾼다. 그렇지 않으면, 서버는 모든 호
스트가 접속을 할 수 있도록 허용을 하기 때문에 시스템의 보안에 문제가 생기게 된다.)
리눅스에서는, 이러한 에러가 생기는 또 다른 이유는 여러분이 사용하는 버전과 다른 glibc라이브러리 버전을 사용해서 컴
파일된 MySQL 바이너리 버전을 여러분이 사용할 경우에 발생하기도 한다. 이와 같은 경우, 여러분은 OS 또는 glibc를 업
그레이드 해야 하거나, 또는 MySQL 소스 버전을 다운로드 해서 여러분 스스로 컴파일 해서 사용해야 한다.
● 만약에 접속을 시도할 때 호스트 이름을 지정하였으나, 호스트 이름이 보이지 않고 IP 번호만 나오는 에러를 가지게 되면,
이것은 MySQL 서버가 IP 번호를 호스트 이름으로 해석하는데 있어서 에러가 발생했다는 것을 의미하는 것이다:
· shell> mysqladmin -u root -pxxxx -h some_hostname ver
· Access denied for user 'root'@'' (using password: YES)
이것은 DNS 문제를 가리키는 것이다. 이것을 해결하기 위해서는, mysqladmin flush-hosts를 실행해서 내부 DNS 호스
트 이름 캐시를 리셋 시킨다. Section 7.5.6, “MySQL DNS 사용방법”을 참조.
영구적인 해결 방법은:
❍ DNS 서버의 문제를 알아내서 고친다.

❍ MySQL 그랜트 테이블에 호스트 이름이 아닌 IP 번호를 지정한다.
❍ 클라이언트 머신 이름에 대한 엔트리를 /etc/hosts또는 ￦windows￦hosts에 넣어 둔다.
❍ Mysqld를 --skip-name-resolve옵션으로 구동시킨다.
❍ Mysqld를 --skip-host-cache옵션과 함께 구동 시킨다.
❍ 유닉스에서, 만약에 서버와 클라이언트를 하나의 머신에서 구동시킨다면, localhost에 접속을 한다. Localhost에
대한 유닉스 접속은 TCP/IP가 아닌 유닉스 소켓 파일을 사용한다.
❍ 윈도우에서, 만약에 서버와 클라이언트가 동일한 머신에서 구동이 되고, 서버가 네임드 파이프 접속을 지원한다면,

:::MySQL Korea:::
호스트 이름 . (period)에 접속을 한다. 호스트 .에 대한 접속은 TCP/IP가 아닌 네임드 파이프를 사용한다.
● 만약에 mysql -u root test가 동작은 하지만 mysql -h your_hostname -u root test의 결과로 Access denied
(your_hostname은 로컬 호스트의 실제 호스트 이름)가 발생한다면, 여러분은 아마도 user테이블에 있는 호스트에 대해
정확한 이름을 가지고 있지 않는 것이다. 여기에서의 일반적인 문제는 in the user테이블 열에 있는 Host값이 검증되지 않
은 호스트 이름을 지정하고 있으나, 시스템의 이름 해석 루틴은 완전히 검증된 도메인 이름을 돌려준다는 것이다(혹은 그
반대). 예를 들면, 만약에 user테이블에 호스트'tcx'를 가지는 엔트리가 있으나, DNS가 MySQL에게 호스트 이름은 'tcx.
subnet.se'라고 알려줄 경우, 그 엔트리는 동작을 하지 않게 된다. 엔트리를 Host컬럼 값을 호스트의 IP 번호로 가지고 있
는 user테이블에 추가하도록 해본다. (다른 방법으로는, 와일드 카드를 가지고 있는 Host값이 있는 user테이블에 엔트리
를 추가해 본다; 예를 들면, 'tcx.%'. 하지만, ‘%’로 끝나는 이름을 가진 것을 사용하는 것은 보안에 문제가 생기기 때문
에 권장하지는 않는다!)
● 만약에 mysql -u user_name test는 동작은 하지만 mysql -u user_name other_db_name이 동작을 하지 않는다면, 여
러분은 주어진 사용자의 other_db_name에 대한 데이터 베이스 접근 권한을 승인하지 않은 것이다.
● 만약에 mysql -u user_name가 서버 호스트에서 실행될 때 제대로 동작은 하지만, 리모트 클라이언트 호스트에서 실행
할 때에는 mysql -h host_name -u user_name가 동작하지 않는다면, 리모트 호스트에서 주어진 사용자 이름에 대한 서
버 접근을 활성화 시키지 않은 것이다.
● 만약에 여러분이 Access denied에러가 발생한 이유를 모른다면, 와일드 카드를 가지고 있는 Host값이 있는 모든 엔트리
( ‘%’ 또는 ‘_’를 가지고 있는 엔트리)를 the user테이블에서 삭제를 한다. 가장 일반적인 에러는 Host='%'와
User='some_user’를 가지고 새로운 엔트리를 삽입하는 것이다. 이것이 동작을 하지 않는 이유는 디폴트 권한이
Host='localhost'와 User=''를 가지고 있는 엔트리를 포함하고 있기 때문이다. 엔트리가 '%'보다 구체적인 Host값인
'localhost'를 가지고 있기 때문에, localhost에서 접속을 할 때 새로운 엔트리를 위해 이것이 우선적으로 사용된다. 올바른
진행 과정은 Host='localhost'와 User='some_user'를 가지고 두번째 엔트리를 삽입하거나, 또는 Host='localhost'와
User=''를 가지고 있는 엔트리를 삭제하는 것이다. 엔트리를 삭제한 후에는, 그랜트 테이블을 다시 읽어 오기 위해
FLUSH PRIVILEGES명령문을 입력하는 것을 잊지 말기 바란다.
● 만약에 여러분이 아래의 에러를 가지게 된다면, 아마도 db또는 host테이블에 문제가 있는 것이다:
· Access to database denied
만약에 db테이블에서 선택된 엔트리가 Host컬럼에 빈 값을 가지고 있다면, db테이블이 적용되는 호스트를 지정하는 host
테이블에 있는 엔트리가 하나 또는 그 이상이 있는지를 확인한다.
● 만일 여러분이 MySQL 서버에 접속을 할 수는 있지만, SELECT ... INTO OUTFILE또는 LOAD DATA INFILE명령문

:::MySQL Korea:::
을 입력할 때마다 Access denied에러 메시지를 가지게 되면, user테이블에 있는 여러분의 엔트리가 활성화된 FILE권한
을 가지고 있지 않다는 것이다.
● 만일 여러분이 직접 그랜트 테이블을 변경하였지만 변경된 내용이 무시되고 있다고 판단되면 execute a FLUSH
PRIVILEGES명령문 또는 mysqladmin flush-privileges 명령어를 실행 시켜서 서버로 하여금 권한 테이블을 다시 읽어
오도록 만들어야 한다. 그렇지 않으면, 서버가 재 구동되기까지 변경한 내용이 적용되지 않는다. UPDATE명령어를 가지
고 root패스워드를 변경한 후에는, 여러분이 권한을 플러시하기 전까지는 새로운 패스워드를 지정할 필요가 없는데, 그 이
유는 서버가 변경된 패스워드를 아직 모르고 있기 때문이다
● 만약에 여러분의 권한이 세션 도중에 변경되었다고 판단되면, 이것은 관리자가 변경을 한 것으로 생각할 수가 있다. 그랜
트 테이블을 다시 읽어 오는 것은 새로운 접속에 영향을 미치지만, 이것은 또한 Section 5.8.7, “권한변경시의효과”에서
설명하고 있는 것처럼 현재 존재하고 있는 접속에도 영향을 미치게 된다.
● 만약에 Perl, PHP, Python, 또는 ODBC 프로그램 접속에 문제가 있다면, mysql -u user_name db_name또는 mysql -
u user_name -pyour_pass db_name를 사용해서 서버에 접속해 본다. 만약에 mysql 클라이언트를 사용해서 접속할 수
가 있다면, 문제는 접근 권한에 있는 것이 아니라 프로그램에 있는 것이다.
● 테스트를 위해, mysqld서버를 --skip-grant-tables옵션과 함께 시작한다. 그런 다음에 MySQL의 그랜트 테이블을 변
경하고 mysqlaccess 스크립트를 사용해서 여러분이 변경시킨 내용이 원하는 형태로 진행되는지를 검사한다. 변경 내용이
제대로 동작되면, mysqladmin flush-privileges를 실행해서 mysqld 서버가 새로운 그랜트 테이블을 사용해서 시작되도
록 만든다.
만약에 모든 것이 실패를 할 경우에는, mysqld서버를 디버깅 옵션을 사용해서 구동 시킨다 (예를 들면, --debug=d,general,
query). 이것은 접속을 시도한 호스트와 사용자에 대한 정보를 출력해 주고, 또한 입력된 각 명령어에 대한 정보도 보여 준다.
Section E.1.2, “Creating Trace Files”를 참조.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.8.9. MySQL 4.1 이후의 패스워드 해싱
5. 데이터 베이스 관리 MySQL 사용자 계정은 mysql 데이터 베이스의 user 테이블에 리스트 되어 있다. 각 MySQL 계정에는 패스워드가 할당되는데,
5.8. MySQL 권한 시스템 user 테이블의 Password 컬럼에 저장되는 패스워드는 일반적인 문장이 아닌 해시 값으로 저장된다. 패스워드 해시 값은
5.8.9 MySQL 4.1 이후의 패스워드 해싱 PASSWORD() 함수로 계산된다.
MySQL은 클라이언트/서버 통신의 두 과정에서 패스워드를 사용한다:
● 클라이언트가 서버에 접속을 시도할 때, 클라이언트가 사용하고자 하는 계정을 위한 user 테이블에 저장된 해시 값과 매칭
되는 해싱 값을 갖고 있는 패스워드를 클라이언트가 표현해야 하는 초기 인증 절차가 있다.
● 클라이언트는 접속을 한 후에는, 클라이언트는 user 테이블에 있는 계정에 대한 패스워드 해시를 설정 또는 변경할 수가 있
게 된다. 클라이언트는 패스워드 해시를 만들기 위한 PASSWORD() 함수를 사용하거나, 또는 GRANT 또는 SET
PASSWORD 명령문을 사용해서 이 일을 수행한다.
달리 표현하면, 서버는 클라이언트가 처음으로 접속을 시도할 때 인증을 하는 동안에 이 해시 값을 사용한다. 서버는 접속된 클라이
언트가 PASSWORD() 함수를 호출하거나 또는 GRANT 또는 SET PASSWORD 명령문을 사용해서 명령문을 설정 또는 변경하
는 경우에 해시 값을 생성한다.
패스워드 해싱 매커니즘은 MySQL 4.1에서 개선되어 보다 우수한 보안성을 제공해 주었다. 하지만, 이 새로운 매커니즘은 4.1(그
리고 그 이후 버전)의 서버와 클라이언트에서만 사용이 가능하며, 그 결과 이전 버전과의 호환성에 문제가 생기게 되었다. 4.1 또
는 그 이후 버전의 클라이언트는 이전 버전의 서버에 접속을 할 수는 있으나, 4.1 이전 버전의 클라이언트가 4.1 이후의 서버에 접
속하는 것은 문제를 가지게 된다. 예를 들면, 5.0 서버에 접속을 시도하는 3.23 mysql 클라이언트는 아래와 같은 에러를 가질 수
가 있다:
shell> mysql -h localhost -u root
Client does not support authentication protocol requested

:::MySQL Korea:::
by server; consider upgrading MySQL client
아래의 내용은 구형과 새로운 패스워드 매커니즘간의 차이점에 대한 설명이며, 여러분이 서버를 업그레이드하는 경우에 4.1 이전
버전과의 호환성을 유지하기 위해서 취해야 할 일들에 대해 알려주고 있다. 부가적인 정보는 Section A.2.3, “Client does not
support authentication protocol”을 참고하기 바란다. 이 정보는 4.0 또는 이전 버전을 4.1 또는 그 이후 버전으로 업그레이드
를 하고자 하는 PHP 프로그래머에게 특히 중요한 사항이다.
Note: 여기에서는 4.1 이전 버전과 4.1 버전과의 차이점에 대해 주로 설명을 하는데, 4.1의 특성은 실제로는 4.1.1 이후 버전에 관
한 것이다. MySQL 4.1.0은 4.1.1 이후 버전과는 다소 차이가 있는 매커니즘을 사용하고 있기 때문에 “odd” 릴리즈라고 간주된
다.
MySQL 4.1 이전 버전에서는, PASSWORD() 함수가 계산하는 패스워드 해시는 16 바이트이다. 그러한 해시는 다음과 같이 보인
다:
mysql> SELECT PASSWORD('mypass');
+--------------------+
| PASSWORD('mypass') |
+--------------------+
| 6f8c114b58f2ce9e |
+--------------------+
user 테이블의 Password 컬럼 여기 4.1 이전에는 16 바이트다.
MySQL 4.1 이후에는, PASSWORD() 함수는 41 바이트의 해시 값을 생성하도록 수정되었다:
mysql> SELECT PASSWORD('mypass');

:::MySQL Korea:::
+-------------------------------------------+
| PASSWORD('mypass') |
+-------------------------------------------+
| *6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4 |
+-------------------------------------------+
따라서, user 테이블에 있는 Password 컬럼 역시 41바이트의 값을 저장하도록 수정되었다:
● 만약에 여러분이 5.0을 새롭게 설치한다면, Password 컬럼은 자동적으로 41 바이트 길이로 만들어 진다.
● MySQL 4.1 (4.1.1 또는 4.1 시리즈의 나중 버전)에서 MySQL 5.0로 업그레이드할 때에는, 두 버전이 모두 동일한 매커
니즘을 사용하고 있기 때문에 별도로 해야 할 일이 없다. 하지만, 4.1 이전 버전에서 5.0으로 업그레이드를 하고자 한다면,
우선 4.1로 업그레이드를 한 후에 5.0으로 업그레이드를 해야 한다.
확장된 Password 컬럼은 구형 및 신형의 패스워드 해시 포맷 값을 저장할 수가 있다. 주어진 패스워드 해시 값의 구분은 두 가지
방법으로 판단된다:
● 명백한 길이의 차이 (16 바이트 대 41 바이트).

● 두 번째 차이는 새로운 패스워드 해시는 항상 ‘*’ 문자로 시작되는 반면에, 구형 해시는 그렇지 않다는 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9. MySQL 사용자 계정 관리
5. 데이터 베이스 관리 5.9.1. MySQL 사용자 이름과 패스워드

5.9. MySQL 사용자 계정 관리 5.9.2. MySQL에 새로운 사용자 계정 추가하기
5.9 MySQL 사용자 계정 관리 5.9.3.MySQL에서 사용자 계정 제거하기
5.9.1 MySQL 사용자 이름과 패스워드 5.9.4. 계정 자원 제한하기
5.9.2 MySQL에 새로운 사용자 계정 추가하기 5.9.5. 계정 패스워드 할당하기

5.9.6. 패스워드 보안 유지하기
5.9.3 MySQL에서 사용자 계정 제거하기
5.9.7. 보안 접속 사용하기
5.9.4 계정 자원 제한하기
5.9.5 계정 패스워드 할당하기
이 섹션에서는 여러분의 MySQL 서버의 클라이언트를 위한 계정을 어떻게 설정하는지 설명을 한다. 다음의 주제를
5.9.6 패스워드 보안 유지하기
다루기로 한다:
5.9.7 보안 접속 사용하기
5.9.7.1 기본적인 SSL 개념 ● MySQL에서 사용되는 계정 이름과 패스워드의 의미와 OS가 사용하는 이름과 패스워드의 의미를 비교한다
5.9.7.2 OpenSSL을 사용해서 SSL 접속하기 ● 새로운 계정 설정 방법과 존재하는 계정 제거 하는 방법
5.9.7.3 yaSSL을 사용해서 SSL 접속하기 ● 패스워드 변경 방법
5.9.7.4 MySQL을 위한 SSL 인증 설정 하기 ● 패스워드를 안전하게 사용하는 가이드 라인
5.9.7.5 SSL 명령어 옵션 ● SSL을 사용한 보안 접속 사용법
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9.1. MySQL 사용자 이름과 패스워드
5. 데이터 베이스 관리 MySQL 계정은 사용자 이름(username) 과 사용자가 서버에 접속을 할 수 있는 클라이언트 호스트 또는 호스트라는 용어로 정의
5.9. MySQL 사용자 계정 관리 된다. 계정에는 패스워드도 있다. MySQL이 사용하는 사용자 이름 및 패스워드와 OS가 이것들을 다루는 방식에는 뚜렷한 차이점
5.9.1 MySQL 사용자 이름과 패스워드 이 몇 가지 있다:
● MySQL이 인증의 목적으로 사용하는 사용자 이름은 윈도우 또는 유닉스가 사용하는 사용자 이름(로그인 이름)과는 아무
런 상관이 없다. 유닉스에서는, 대부분의 MySQL 클라이언트는 디폴트로 MySQL이 사용하는 사용자 이름을 현재의 유닉
스 사용자 이름으로 사용해서 로그인을 시도하지만, 이것은 단지 편의상의 이유 때문이다. 디폴트는 쉽게 변경 시킬 수가
있는데, 그 이유는 클라이언트 프로그램은 사용자 이름을 -u 또는 --user 옵션을 사용해서 지정할 수 있도록 하기 때문
이다. 이것은 누구라도 어떤 사용자 이름을 가지고도 서버에 접속을 할 수 있다는 것을 의미하는 것이기 때문에, 모든
MySQL 계정이 패스워드를 가지지 않는 한 여러분은 데이터 베이스를 안전하게 만들지 못하게 된다.
● MySQL 사용자 이름은 최대 16 문자 길이로 만들 수가 있다. 이 제한은 MySQL 서버와 클라이언트에는 엄격하게 적용되
며, mysql 데이터 베이스에 있는 테이블의 정의를 수정해서 이 제한을 없앨 수는 없다.
OS가 사용하는 사용자 이름은 MySQL의 사용자 이름과는 전혀 관련이 없으며 최대 가능길이도 서로 틀리다. 예를 들면,
유닉스에서는 전형적으로 문자 길이가 8로 제한된다.
● MySQL 패스워드는 여러분이 OS에 로그인할 때 사용하는 패스워드와는 아무런 상관이 없는 것이다.
● MySQL는 자신의 고유 알고리즘을 사용해서 패스워드를 암호화 한다. MySQL이 사요하는 암호화 기법은 PASSWORD
() SQL 함수이며, 유닉스에서는 ENCRYPT() SQL 함수를 사용해서 암호화를 한다.
여러분이 MySQL을 설치할 때, 그랜트 테이블은 초기 계정 셋을 가지게 된다. 이러한 계정들은 초기 Section 2.9.3, “초기
MySQL 계정 보안 설정하기”에서 설명하는 이름과 접근 권한을 가지게 된다. 그 후에, 여러분은 GRANT 와 REVOKE와 같은 명
령문을 사용해서 MySQL 계정을 설정, 수정, 그리고 제거할 수가 있게 된다. Section 13.5.1, “계정 관리 명령문”을 참조.
명령어 라인의 클라이언트를 가지고 서버에 접속을 할 때에는, 여러분은 사용하고자 하는 사용자 계정을 위한 사용자 이름과 패스

:::MySQL Korea:::
워드를 지정해야 한다:
shell> mysql --user=monty --password=guess db_name
짧은 옵션을 선호할 경우에는, 아래와 같다:
shell> mysql -u monty -pguess db_name
-p 옵션과 패스워드 값 사이에는 스페이스가 없다. Section 5.8.4, “MySQL 서버에 접속하기”를 참조.
위의 명령어에는 패스워드 값이 명령어 라인에 보이게 되기 때문에 보안의 문제가 생긴다. See Section 5.9.6, “패스워드 보안 유
지하기”를 참조. 이것을 피하기 위해서는, --password 또는 -p 옵션을 아래와 같이 사용한다:
shell> mysql --user=monty --password db_name
shell> mysql -u monty -p db_name
패스워드 옵션이 패스워드 값을 가지지 않으면, 클라이언트 프로그램은 프롬프트를 발생시켜서 여러분이 패스워드를 입력하기를
기다리게 된다. (이 경우에, db_name는 패스워드 값으로 인식되지 않는데, 그 이유는 패스워드 옵션과 뒤의 값 사이에 스페이스가
있기 때문이다.)
어떤 시스템에서는, MySQL이 패스워드를 위한 프롬프트로 사용하는 라이브러리 루틴이 자동적으로 패스워드의 길이를 8 문자로
한정한다. 이것은 시스템 라이브러리에 관련된 문제이며, MySQL과는 관련이 없다. 내부적으로는, MySQL은 패스워드의 길이를
제한하지 않는다. 이 문제를 피하기 위해서는, 여러분의 MySQL 패스워드를 8 또는 그보다 작은 값으로 변경을 하거나, 또는 옵션
파일에 패스워드를 넣어두면 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9.2. MySQL에 새로운 사용자 계정 추가하기
5. 데이터 베이스 관리 여러분은 두 가지 방법으로 MySQL 계정을 생성할 수가 있다:

5.9. MySQL 사용자 계정 관리
5.9.2 MySQL에 새로운 사용자 계정 추가하기 ● CREATE USER or GRANT와 같이 계정 생성을 진행하는 명령문을 사용한다
● INSERT, UPDATE, 또는 DELETE와 같은 명령문을 사용해서 MySQL 그랜트 테이블을 직접 편집한다
첫 번째 방법이 보다 간편하고 에러가 나올 확률이 적다. CREATE USER 와 GRANT는 Section 13.5.1.1, “CREATE USER 신
텍스”, 및 Section 13.5.1.3, “GRANT 신텍스”에서 설명을 하고 있다.
계정 생성을 위한 또 하나의 옵션은 MySQL 계정 관리 기능을 제공하는 타 회사의 제품을 사용하는 것이다. phpMyAdmin이 이런
제품 중에 하나이다.
아래의 예제는 mysql 클라이언트 프로그램을 사용해서 새로운 사용자를 설정하는 방법을 보여준다. 이 예제에서는 권한이
Section 2.9.3, “초기 MySQL 계정에 보안 작업하기”에서 설명하는 디폴트에 따라서 설정되어 있다는 가정을 한다. 이것은 변
경 작업을 하기 위해서는, 여러분이 반드시 MySQL 서버에 MySQL root 사용자로 접속을 해야 하고, 그리고 root 계정은 반드시
mysql 데이터 베이스에 대해서는 INSERT 권한을 가지고 RELOAD 관리 권한을 가지고 있어야 한다는 것을 의미한다.
우선, mysql 프로그램을 사용해서 MySQL root 사용자로 서버에 접속을 한다:
shell> mysql --user=root mysql
만약에 루트 계정에 패스워드를 할당하였다면, --password 또는 -p 옵션을 사용해서 mysql 명령어를 입력한다.
서버에 접속을 한 후에는, 여러분은 새로운 계정을 추가할 수가 있게 된다. 아래의 명령문은 GRANT 를 사용해서 새로운 계정을 설
정한다:

:::MySQL Korea:::
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'localhost'
-> IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT ALL PRIVILEGES ON *.* TO 'monty'@'%'
-> IDENTIFIED BY 'some_pass' WITH GRANT OPTION;
mysql> GRANT RELOAD,PROCESS ON *.* TO 'admin'@'localhost';
mysql> GRANT USAGE ON *.* TO 'dummy'@'localhost';
GRANT 명령문을 사용해서 생성된 계정은 아래와 같은 특성을 가지게 된다:
● 생성된 계정 중에 두 개는 사용자 이름 monty와 패스워드 some_pass를 가진다. 두 계정 모두 전체 권한을 가지고 있는 슈

퍼유저(superuser) 계정이다. 하나의 계정('monty'@'localhost')은 로컬 호스트에서 접속을 할 경우에만 사용된다. 또 다
른 계정 ('monty'@'%')는 다른 호스트에서 접속을 하기 위해 사용된다. monty라는 이름으로 어디에서든지 접속을 할 수
있기 위해서는 monty에 대해 두 개의 계정을 모두 가지고 있는 것이 필요하다는 것을 알아 두기 바란다. localhost 계정이
없다면, monty가 로컬 호스트에서 접속을 할 때 mysql_install_db가 생성한 localhost에 대한 익명의 사용자 계정이 우선
적으로 사용된다. 그 결과로, monty는 하나의 익명의 사용자처럼 취급을 받게 된다. 이렇게 되는 이유는 익명의 사용자 계
정이 'monty'@'%' 계정보다 더 구체적인(more-specific) Host 컬럼 값을 가지기 때문이며 따라서 user 테이블 정렬 순
서에서 보다 앞서서 나오기 때문이다. (user 테이블 정렬은 Section 5.8.5, “접근 제어, Stage 1: 접속 검증”를 참조할
것.)
● 한 개의 계정이 admin이라는 이름을 가지고 있고 패스워드는 없다. 이 계정은 로컬 호스트에서 접속하기 위해서만 사용된
다. 이 계정은 RELOAD 와 PROCESS 관리 권한이 승인되어 있다. 이러한 권한은 admin 사용자가 mysqladmin reload,
mysqladmin refresh, 그리고 mysqladmin flush-xxx 명령문 뿐만 아니라, mysqladmin processlist도 실행할 수 있도
록 해 준다. 어떤 데이터 베이스에 대해서도 접근할 수 있는 권한은 승인되지 않았다. 여러분은 나중에 GRANT 명령문을
입력해서 이러한 권한을 추가할 수가 있다.
● 하나의 계정은 dummy라는 이름을 가지고 있고 패스워드가 할당되지 않았다. 이 계정은 로컬 호스트에서 접속을 할 때에
만 사용된다. 아무런 권한도 승인되지 않았다. GRANT 명령문에 있는 USAGE 권한은 여러분이 아무런 권한이 없는 계정
을 만들 수 있게 해 준다. 이것은 모든 글로벌 권한을 'N'으로 설정하면 된다. 이 계정에 여러분이 특정 권한을 나중에 승인

:::MySQL Korea:::
할 것이라는 가정을 한다.
GRANT명령문에 대한 대안으로, 여러분은 동일한 계정을 INSERT 명령문을 입력해서 직접 생성할 수 있고 그런 다음에 FLUSH
PRIVILEGES를 사용해서 서버가 그랜트 테이블을 다시 읽어 오도록 만들 수가 있다.
mysql> INSERT INTO user
-> VALUES('localhost','monty',PASSWORD('some_pass'),
-> 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user
-> VALUES('%','monty',PASSWORD('some_pass'),
-> 'Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO user SET Host='localhost',User='admin',
-> Reload_priv='Y', Process_priv='Y';
mysql> INSERT INTO user (Host,User,Password)
-> VALUES('localhost','dummy','');
여러분이 INSERT를 사용해서 계정을 생성할 때 FLUSH PRIVILEGES를 사용하는 이유는 서버가 그랜트 테이블을 다시 읽어 오
도록 만들기 위해서이다. 그렇지 않으면, 여러분이 서버를 재 구동 시키기 전에는 변경 사항이 적용되지 않느다. GRANT를 사용하
는 경우는, FLUSH PRIVILEGES가 필요 없다.

:::MySQL Korea:::
PASSWORD() 함수를 INSERT와 함께 사용하는 이유는 패스워드를 암호화 하기 위해서다. GRANT 명령문은 패스워드를 암호
화 하며, 따라서 PASSWORD()가 필요 없게 된다.
'Y' 값은 계정의 권한을 활성화 시킨다. 여러분이 사용하는 MySQL 버전에 따라, 맨 처음 두 개의 INSERT 명령문에서 서로 다른
수의 'Y' 값을 사용할 것이다. admin 계정의 경우, 여러분은 SET을 사용하는 확장된 INSERT 신텍스를 추가할 수가 있을 것이다.
dummy 계정에 대한 INSERT 명령문의 경우, user 테이블 열의 Host, User, 및 Password 컬럼에만 값이 할당된다. 아무런 권
한 컬럼도 명확하게 설정이 되지 않았기 때문에, MySQL은 디폴트 값인 'N'을 모두 할당한다. 이것은 GRANT USAGE가 실행하
는 것과 같은 결과 값이다.
슈퍼유저 계정을 설정하기 위해서는, 권한 컬럼을 'Y'로 설정한 user 테이블 엔트리를 생성하기만 하면 된다는 점을 알아두자.
user 테이블 권한은 글로벌이며, 따라서 다른 그랜트 테이블의 어떤 엔트리도 필요가 없게 된다.
다음의 예제에서는 세 개의 계정을 생성하며 각 계정들이 특정 데이터 베이스에 접근할 수 있도록 하고 있다. 각각의 계정은 이름
이 custom이며 패스워드는 obscure가 된다.
GRANT를 가지고 계정을 생성하기 위해서는, 아래의 명령문을 사용한다:
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
-> ON bankaccount.*
-> TO 'custom'@'localhost'
-> IDENTIFIED BY 'obscure';
-> ON expenses.*

:::MySQL Korea:::
-> TO 'custom'@'whitehouse.gov'
-> ON customer.*
-> TO 'custom'@'server.domain'
세 개의 계정은 아래와 같이 사용될 수 있다:
● 처음의 계정은 bankaccount 데이터 베이스에 접근할 수는 있으나, 로컬 호스트에서만 가능하다.

● 두 번째 계정은 expenses 데이터 베이스에 접근할 수 있으나, 호스트 whitehouse.gov에서만 가능하다.
● 세 번째 계정은 customer 데이터 베이스에 접근할 수 있으나, server.domain에서만 가능하다.
custom 계정을 GRANT 없이 설정하기 위해서는, 그랜트 테이블을 직접 수정하기 위해 아래와 같이 INSERT 명령문을 사용한다:
-> VALUES('localhost','custom',PASSWORD('obscure'));
-> VALUES('whitehouse.gov','custom',PASSWORD('obscure'));

:::MySQL Korea:::
-> VALUES('server.domain','custom',PASSWORD('obscure'));
mysql> INSERT INTO db
-> (Host,Db,User,Select_priv,Insert_priv,
-> Update_priv,Delete_priv,Create_priv,Drop_priv)
-> VALUES('localhost','bankaccount','custom',
-> 'Y','Y','Y','Y','Y','Y');
-> VALUES('whitehouse.gov','expenses','custom',
-> 'Y','Y','Y','Y','Y','Y');
-> VALUES('server.domain','customer','custom',
-> 'Y','Y','Y','Y','Y','Y');

:::MySQL Korea:::
처음 세 개의 INSERT 명령문은 사용자 custom이 주어진 패스워드를 가지고 다양한 호스트에서 접속을 할 수는 있지만, 글로벌
권한을 승인하지 않는 user테이블 엔트리를 추가하고 있다 (모든 권한은 디폴트 값이

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9.3. MySQL에서 사용자 계정 제거하기
5. 데이터 베이스 관리 계정을 제거하기 위해서는, DROP USER 명령문을 사용한다. Section 13.5.1.2, “DROP USER 신텍스”를 참조할
5.9. MySQL 사용자 계정 관리 것.
5.9.3 MySQL에서 사용자 계정 제거하기
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9.4. 계정 자원 제한하기
5. 데이터 베이스 관리 MySQL 서버의 자원 사용을 제한하는데 사용하는 방법 중의 하나는 max_user_connections 시스템 변수의 값을 0이 아니 값으
5.9. MySQL 사용자 계정 관리 로 설정하는 것이다. 하지만, 이 방법은 글로벌하게 적용되게 되며, 개별 사용자 계정을 관리하지는 못한다. 또한, 단일 계정을 사용
5.9.4 계정 자원 제한하기 해서 이루어지는 동시 접속의 숫자만을 제한하며, 접속을 한 클라이언트의 동작을 제한 하지는 못한다.
MySQL 5.0에서는, 여러분은 각 개별 계정에 대해 아래의 서버 자원을 한정할 수가 있다:
● 한 계정이 시간 당 입력할 수 있는 쿼리의 숫자

● 한 계정이 시간 당 입력할 수 있는 업데이트의 숫자
● 한 계정이 시간 당 접속할 수 있는 숫자
클라이언트가 입력하는 모든 명령문이 쿼리 제한치에 대해서 계산된다. 데이터 베이스 또는 테이블을 수정하는 명령문만이 업데이
트 제한치에 대해 계산된다.
MySQL 5.0.3 이후에는, 하나의 계정 당 서버에 동시에 접속할 수 있는 숫자를 제한할 수도 있게 되었다.
이 문장에서 표현되는 계정은 user 테이블에 있는 단일 열이다. 각 계정은 자신의 User 와 Host 컬럼 값을 가지고 서로 구분 된다.
이러한 기능을 사용하기 위한 필요 요건으로는, mysql 데이터 베이스에 있는 user 테이블은 반드시 자원-권련 컬럼을 가지고 있
어야 한다. 자원 제한은 max_questions, max_updates, max_connections, 그리고 max_user_connections 컬럼에 저장된다. 만
일 여러분의 user 테이블에 이러한 컬럼이 없다면, 이 테이블을 업그레이드 해야 한다; Section 5.6.2, “mysql_upgrade —
MySQL 업그레이드를 위한 테이블 검사”를 참조할 것.
GRANT 명령문을 사용해서 자원의 한계를 설정하기 위해서는, 제한되는 자원의 이름을 지정하고 재한 값을 가리키는 시간당 카운
트를 하는 WITH 구문을 사용한다. 예를 들면, customer 데이터 베이스에는 접근할 수는 있으나, 제한적인 범위에서만 가능한 계
정을 새로 만들기 위해서는, 아래와 같이 명령문을 입력한다:

:::MySQL Korea:::
mysql> GRANT ALL ON customer.* TO 'francis'@'localhost'
-> IDENTIFIED BY 'frank'
-> WITH MAX_QUERIES_PER_HOUR 20
-> MAX_UPDATES_PER_HOUR 10
-> MAX_CONNECTIONS_PER_HOUR 5
-> MAX_USER_CONNECTIONS 2;
제한 타입을 WITH 구문에 모두 거론할 필요는 없으나, 제한 타입의 이름들은 일정 순서로 표시될 수는 있다. 각각의 시간당 제한
치 값은 시간당 카운트 되는 정수 값이 되어야 한다. 만약에 GRANT 명령문이 WITH 구문을 가지고 있지 않다면, 제한치는 각각
디폴트 0으로 설정된다 (즉, 제한 없음). MAX_USER_CONNECTIONS의 경우, 제한치는 그 계정이 어느 한 시점에 동시에 접속
을 할 수 있는 최대 값을 나타내는 정수 값이 된다. 만일 이 값이 디폴트 0으로 설정되면, max_user_connections 시스템 변수 값
이 그 계정의 동시 접속 숫자가 된다.
현재 존재하는 계정의 제한치를 설정 또는 변경하기 위해서는, 글로벌 레벨 (ON *.*)에서 GRANT USAGE 명령문을 사용한다. 아
래의 명령문은 francis의 쿼리 한계를 100으로 변경한다:
mysql> GRANT USAGE ON *.* TO 'francis'@'localhost'
-> WITH MAX_QUERIES_PER_HOUR 100;
이 명령문은 계정의 현재 권한을 변경하지 않는 상태에서 지정된 한계 값만을 수정한다.
현재의 제한 값을 제거하기 위해서는, 그 값을 0으로 설정한다. 예를 들면, francis가 한 시간에 접속할 수 있는 한계 값을 제거하
기 위해서는, 아래의 명령문을 사용한다:
mysql> GRANT USAGE ON *.* TO 'francis'@'localhost'

:::MySQL Korea:::
-> WITH MAX_CONNECTIONS_PER_HOUR 0;
서버는 구동을 하면서, 각 계정이 자원을 사용하는 횟수를 계산한다. 만일 한 계정이 시간당 접속 한계치에 도달하게 되면, 서버는
새로운 시간 단위가 발생하기 전까지 그 계정에 대한 접속을 거부한다. 그 계정이 쿼리나 업데이트 한계치에 도달할 경에도 마찬가
지로 동작을 한다. 이러한 모든 경우에는 에러 메시지가 나오게 된다.
자원 계산은 클라이언트 단위가 아닌 계정 단위로 이루어진다. 예를 들면, 만약에 여러분의 계정이 쿼리 한계를 50으로 하고 있다
면, 여러분은 서버에 두 개의 클라이언트를 동시에 접속을 시키는 방법으로 이 한계를 100으로 늘릴 수는 없다. 양쪽에서 일어나
는 쿼리는 같이 계산이 된다.
현재의 시간당 자원 사용 카운트는 모든 계정에 대해 전체적으로, 또는 주어진 계정에 대해서만 개별적으로 리셋 시킬 수가 있다:
● 모든 계정에 대해 현재의 카운트 값을 0으로 리셋 시키기 위해서는, FLUSH USER_RESOURCES 명령문을 사용한다. 이
카운트 값은 그랜트 테이블을 다시 읽어 와서 리셋 시킬 수도 있다 (예를 들면, FLUSH PRIVILEGES 명령문 또는
mysqladmin reload 명령어를 사용해서).
● 개별 계정에 대한 카운트 값은 그 제한 값 중의 하나를 재 승인함으로써 0으로 설정할 수가 있다. 이렇게 하기 위해서는, 앞
에서 설명한 방식으로 GRANT USAGE를 사용하고 제한 값을 그 계정이 현재 가지고 있는 값과 같이 지정을 한다.
카운터 리셋은 MAX_USER_CONNECTIONS 제한 값에는 영향을 주지 않는다.
서버가 시작될 때 모든 카운트는 0으로 리셋 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9.5. 계정 패스워드 할당하기
5. 데이터 베이스 관리 페스워드는 mysqladmin 명령어를 사용해서 명령어 라인에서 할당해 줄 수가 있다:
5.9.5 계정 패스워드 할당하기 shell> mysqladmin -u user_name -h host_name password "newpwd"
이 명령어가 패스워드를 리셋 시키는 계정은 User 컬럼에 있는 user_name 과 매치되는 user 테이블 열과 Host 컬럼에 있는 클라
이언트 호스트를 가지고 있는 계정이 된다.
한 계정에 패스워드를 할당하는 또 다른 방법은 SET PASSWORD 명령문을 실행하는 것이다:
mysql> SET PASSWORD FOR 'jeffrey'@'%' = PASSWORD('biscuit');
mysql 데이터 베이스에 업데이트 접근을 할 수 있는 root 사용자만이 다른 사용자의 패스워드를 변경 시킬 수가 있다. 만일 여러분
이 익명의 사용자로 접속을 할 수 없다면, FOR 구문을 생략해서 여러분 자신의 패스워드를 변경 시킬 수가 있게 된다:
mysql> SET PASSWORD = PASSWORD('biscuit');
여러분은 또한 글로벌 레벨(ON *.*)에서 GRANT USAGE 명령문을 사용해서 한 계정의 현재 권한에 영향을 미치지 않고 패스워
드를 할당할 수가 있다:
mysql> GRANT USAGE ON *.* TO 'jeffrey'@'%' IDENTIFIED BY 'biscuit';
비록 위의 방법들을 사용해서 패스워드를 할당하는 것이 일반적인 방법이기는 하지만, 여러분은 user 테이블을 직접 수정을 해서
동일한 일을 처리할 수도 있다:
● 새로운 계정을 생성할 때 패스워드를 지정하기 위해서는, Password 컬럼에 값을 부여한다:

:::MySQL Korea:::
• shell> mysql -u root mysql
• mysql> INSERT INTO user (Host,User,Password)
• -> VALUES('%','jeffrey',PASSWORD('biscuit'));
• mysql> FLUSH PRIVILEGES;
● 이미 존재하는 계정의 패스워드를 변경하고자 한다면, UPDATE를 사용해서 Password 컬럼의 값을 설정한다:
• shell> mysql -u root mysql
• mysql> UPDATE user SET Password = PASSWORD('bagel')
• -> WHERE Host = '%' AND User = 'francis';
• mysql> FLUSH PRIVILEGES;
여러분이 SET PASSWORD, INSERT, 또는 UPDATE를 사용해서 한 계정에 비어 있지 않는 패스워드(non-empty password)

를 할당할 때에는, 반드시 PASSWORD() 함수를 사용해서 암호화를 해야 한다. 이 함수는 패스워드를 일반 문장이 아닌 암호화를
해서 저장을 하게 된다. 만약에 여러분이 이 사실을 잊게 되면, 아마도 아래와 같이 할 것이다:
shell> mysql -u root mysql
-> VALUES('%','jeffrey','biscuit');
위의 결과는 암호화된 값이 아닌 'biscuit'이 user 테이블에 패스워드로 저장이 된다. Jeffrey가 이 패스워드를 사용해서 서버에 접
속을 시도할 때, 입력하는 패스워드는 암호화가 되고 user 테이블에 저장되어 있는 패스워드 값과 비교를 하게 된다. 하지만, 저장

:::MySQL Korea:::
되어 있는 값은 일반 문장인 'biscuit'이며, 따라서 비교는 실패하게 되고 서버는 접속을 거절하게 된다:
shell> mysql -u jeffrey -pbiscuit test
Access denied
만약에 여러분이 GRANT ... IDENTIFIED BY 명령문 또는 mysqladmin password 명령어를 사용해서 패스워드를 할당했다면,
이것들은 모두 패스워드를 암호화 한다. 이와 같은 경우, PASSWORD() 함수 사용은 불필요하게 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9.6. 패스워드 보안 유지하기
5. 데이터 베이스 관리 관리적인 차원에서, 관리자 계정이 아닌 사용자에게는 절대로 user 테이블에 대한 접근 권한을 승인하지 말아야 한다.
5.9.6 패스워드 보안 유지하기 여러분이 클라이언트 프로그램을 구동해서 서버에 접속을 할 경우에는, 다른 사람이 볼 수 있도록 패스워드를 입력하는 방법은 그
리 좋은 것이 아니다. 여러분이 클라이언트 프로그램을 구동 시킬 때 패스워드를 지정할 수 있는 방법이 여기에 있는데, 각각의 방
법마다 위험 요소가 있게 된다:
● -pyour_pass 또는 --password=your_pass 옵션을 명령어 라인에서 사용한다. 예를 들면:
• shell> mysql -u francis -pfrank db_name
이것은 편리하기는 하지만, 안전하지가 못하다. 왜냐하면, 다른 사용자가 명령어 라인에서 ps와 같은 시스템 상태 프로그
램을 사용하면 여러분의 패스워드를 볼 수가 있기 때문이다.
● -p 또는 --password 옵션을 패스워드 값을 사용하지 않고 입력한다. 이와 같은 경우, 클라이언트 프로그램은 패스워드

를 입력하라는 프롬프트를 보내게 된다:
• shell> mysql -u francis -p db_name
• Enter password: ********
‘*’ 문자는 여러분이 입력하는 패스워드를 가리킨다. 이 패스워드는 여러분이 입력하는 문자로는 나타나지 않는다.
이 방법은 패스워드를 명령어 라인에 직접 입력하는 방법보다는 안전하다. 하지만, 이 방법은 여러분이 쌍방향
(interactive) 통신을 하는 프로그램을 사용할 경우에만 사용할 수 있다. 만약에 스크립트를 통해 클라이언트를 호출하는
경우에는, 터미널에서 패스워드를 입력할 수가 없게 된다.

:::MySQL Korea:::
● 패스워드를 옵션 파일에 저장한다. 예를 들면, 유닉스에서 여러분은 여러분의 홈 디렉토리에 있는.my.cnf 파일의[client]
섹션에 패스워드를 저장할 수가 있다:
• [client]
• password=your_pass
만약에 패스워드를 .my.cnf에 저장한다면, 그 파일은 여러분 이외의 사람이 접근할 수가 없게 된다. 이것을 확실하게 하
기 위해서, 파일 접근 모드를 400 또는 600으로 설정한다. 예를 들면:
shell> chmod 600 .my.cnf
Section 4.3.2, “옵션 파일 사용하기”를 참조할 것.
● 패스워드를 환경 변수 MYSQL_PWD에 저장한다. 이 방법은 가장 보안에 취약하기 때문에 절대로 사용하지 말기 바란다.
Appendix F, Environment Variables를 참조할 것.
위의 방법 중에, 가장 안전한 방법은 프롬프트에서 패스워드를 입력하거나, 옵션 파일에 패스워드를 저장해서 사용하는 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.9.7. 보안 접속 사용하기
5. 데이터 베이스 관리 5.9.7.1. 기본적인 SSL 개념

5.9. MySQL 사용자 계정 관리 5.9.7.2. OpenSSL을 사용해서 SSL 접속하기
5.9.7 보안 접속 사용하기 5.9.7.3. yaSSL을 사용해서 SSL 접속하기
5.9.7.1 기본적인 SSL 개념 5.9.7.4. MySQL을 위한 SSL 인증 설정 하기
5.9.7.2 OpenSSL을 사용해서 SSL 접속하기 5.9.7.5. SSL 명령어 옵션

5.9.7.6. SSH를 사용해서 윈도우에서 원경으로 MySQL 접속하기
5.9.7.3 yaSSL을 사용해서 SSL 접속하기
MySQL은 보안 소켓 레이어(Secure Sockets Layer) (SSL) 프로토콜을 사용해서 MySQL클라이언트와 서버간
의 보안(암호화) 접속을 지원한다. 이 섹션에서는 SSL 접속을 사용하는 방법을 설명하기로 한다. 또한, 윈도우에서
SSH를 설정하는 방법도 설명하기로 한다. Section 13.5.1.3, “GRANT 신텍스”를 참조할 것.
MySQL의 표준 구성은 가능하면 빠른 성능을 내도록 의도하고 있는데, 따라서 암호화 접속은 디폴트로 사용되지 않
는다. 이렇게 구성을 하면 클라이언트/서버 프로토콜이 더욱 느려지게 된다..
MySQL은 접속 당 암호화를 활성화 시킨다. 여러분은 각각의 어플리케이션에 따라서 암호화를 하거나 비 암호화 상
태의 접속을 선택할 수가 있다.
:::MySQL Korea:::
제목검색
5.9.7.1. 기본적인 SSL 개념

5. 데이터 베이스 관리 MySQL이 SSL을 사용하는 방법을 이해하기 위해서는, SSL과 X509의 기본적인 개념을 알고 있어야 한다.
5.9.7 보안 접속 사용하기 디폴트로, MySQL은 클라이언트와 서버간에는 암호화되지 않은 접속을 사용한다. 이것은 누군가 네트워크를 접근
할 수 있는 사람이라면 서로 통신을 하고 있는 데이터를 지켜 볼 수 있다는 것을 의미한다. 보안성을 좀더 개선하기
5.9.7.1 기본적인 SSL 개념
위해서, 여러분은 클라이언트/서버의 트래픽을 --compress 옵션을 사용해서 압축할 수가 있는데, 이 방법으로 모
5.9.7.2 OpenSSL을 사용해서 SSL 접속하기
든 공격자를 방어할 수는 없다.
임호화는 모든 종류의 데이터를 읽을 수 없는 형태로 만드는 것이다. SSL은 공중망을 통해 받은 데이터가 신뢰할
수 있는 것이라는 확신을 주기 위해 서로 다른 암호화 알고리즘을 사용하는 프로토콜이다. 여기에는 데이터의 변경,
손실, 또는 재생성을 추적할 수 있는 매커니즘을 포함한다. SSL은 또한 X509 표준을 사용하는 ID 검증 알고리즘과
함께 동작을 한다.
X509는 인터넷상에서 누군가를 구분하는 것이 가능하게 만들어 준다. 이것은 전자 상거래에서 광범위하게 사용되
고 있다. 기본적인 용어로는, “인증 기관(Certificate Authority)” (또는 CA)라는 회사가 있게 되며 필요한 사람
들에게 전자 인증을 부여한다. 인증은 비대칭 암호화 알고리즘을 기반으로 하고 있으며 두 개의 암호화 키를 가지고
있다 (공중 키와 보안 키). 인증 소유자는 자신임을 증명하기 위해 다른 기관에게 인증서를 제출할 수 있다. 인증서
는 소유자의 공중 키로 구성이 된다. 이 공중 키를 가지고 암호화된 데이터는 대응하는 보안 키를 사용해야만 암호
가 풀리게 된다.
보다 자세한 정보에 대해서는 인터넷을 통해 알아보기 바란다.
:::MySQL Korea:::
제목검색
5.9.7.2. OpenSSL을 사용해서 SSL 접속하기

5. 데이터 베이스 관리 MySQL 서버와 클라이언트 프로그램간의 SSL 접속을 사용하기 위해서는, 여러분의 시스템이 OpenSSL 또는 (MySQL 5.0.10 이
5.9. MySQL 사용자 계정 관리 후에는) yaSSL를 지원해야 한다. 이 섹션에서는 OpenSSL을 다루기로 한다. yaSSL의 사용에 대해서는, Section 5.9.7.3,
5.9.7 보안 접속 사용하기 “YaSSL을 사용해서 SSL 접속하기”, 를 참조하기 바란다.

MySQL과 OpenSSL간의 보안 접속을 하기 위해서는, 아래의 사항을 따라야 한다:
1. OpenSSL 라이브러리를 설치한다. 우리는 OpenSSL 0.9.6을 가지고 테스트를 하였다. OpenSSL은 http://www.
openssl.org에서 얻는다.
2. MySQL을 구성할 때, configure 스크립트를 --with-vio 그리고 --with-openssl 옵션과 함께 호출한다:
5.9.7.6 SSH를 사용해서 윈도우에서 원경으로
MySQL 접속하기
3. shell> ./configure --with-vio --with-openssl
4. mysql.user 테이블에 SSL-관련 컬럼이 포함되도록 그랜트 테이블을 업그레이드 해 두어야 한다. 그랜트 테이블이
4.0.0 이전 버전일 경우에는 업그레이드가 필요하다. 업그레이드 과정은 Section 5.6.2, “mysql_upgrade —MySQL 업
그레이드를 위해 테이블 검사하기”를 참조할 것.
5. 구동되는 mysqld 서버가 OpenSSL을 지원하는지를 검사하기 위해서는, have_openssl 시스템 변수의 값을 조사한
다:
6. mysql> SHOW VARIABLES LIKE 'have_openssl';
7. +---------------+-------+
8. | Variable_name | Value |
9. +---------------+-------+

:::MySQL Korea:::
10. | have_openssl | YES |
11. +---------------+-------+
만약에 그 값이 YES이면, 서버는 OpenSSL 접속을 지원하는 것이다

:::MySQL Korea:::
제목검색
5.9.7.3. yaSSL을 사용해서 SSL 접속하기

5. 데이터 베이스 관리 MySQL이 내부적으로 가지고 있는 yaSSL 를 사용하면 보다 간단하게 보안 접속을 할 수가 있다. 여러분은
5.9. MySQL 사용자 계정 관리 Section 5.9.7.2, “OpenSSL을 사용해서 SSL 접속하기”에서 설명한 OpenSSL 설치를 위한 과정을 진행하지 않아도 된
5.9.7 보안 접속 사용하기 다. 또한, MySQL와 yaSSL는 동일한 라이센스 모델을 사용하고 있다.

현재, yaSSL은 아래의 플랫폼에 대해서만 지원이 되고 있다:
● Linux/x86-64 Red Hat Enterprise 3.0
● Linux RHAS21 Itanium-2 with gcc, statically linked
● Linux Itanium-2 with gcc
5.9.7.6 SSH를 사용해서 윈도우에서 원경으로 MySQL
● Windows (all builds)
접속하기
MySQL을 소스를 가지고 설치를 할 때 yaSSL를 활성화 시키기 위해서는, 아래와 같이 MySQL를 구성한다:
shell> ./configure --with-yassl
유닉스 플랫폼에서의 yaSSL 지원은 트루 랜덤(true random) 번호를 추출하기 위해 /dev/urandom 또는 /dev/random가 설
치되어야 한다는 것을 알아두자. 보다 자세한 정보(특히 솔라리스 2.8 이전 버전 또는 HP-UX에서의 yaSSL에 관한 것)는,
Bug #13164를 참조하기 바란다.
MySQL 서버가 yaSSL 지원하도록 시작하기 위해서는, OpenSSL를 지원하기 위한 옵션과 동일한 것을 사용하고 보안 접속
을 만들기 위해 필요한 인증서를 식별한다:
shell> mysqld --ssl-ca=cacert.pem ￦
--ssl-cert=server-cert.pem ￦

:::MySQL Korea:::
--ssl-key=server-key.pem
● --ssl-ca CA(Certificate Authority) 인증서를 식별한다.

● --ssl-cert 서버 인증서를 식별한다.
● --ssl-key 클라이언트 인증서를 식별한다.
MySQL 서버가 yaSSL를 지원하는 보안 접속을 형성하기 위해서는, 클라이언트를 아래와 같이 시작한다:
shell> mysql --ssl-ca=cacert.pem ￦
--ssl-cert=server-cert.pem ￦
--ssl-key=server-key.pem
달리 표현하면, 옵션들은 서버를 위한 것과 똑 같은 것이며, 그리고 CA 인증서도 동일해야 한다.
어플리케이션 프로그램에서 보안 접속을 형성하기 위해서는, mysql_real_connect()를 호출하기 전에 mysql_ssl_set()

API 함수를 사용해서 적당한 인증 옵션을 설정한다. Section 22.2.3.64, “mysql_ssl_set()”를 참조할 것.

:::MySQL Korea:::
제목검색
5.9.7.4. MySQL을 위한 SSL 인증 설정 하기

5. 데이터 베이스 관리 여기에는 OpenSSL을 사용하는 MySQL을 위한 SSL 인증 설정 방법의 예가 있다:

5.9.7 보안 접속 사용하기 DIR=`pwd`/openssl

PRIV=$DIR/private
5.9.7.5 SSL 명령어 옵션 mkdir $DIR $PRIV $DIR/newcerts
5.9.7.6 SSH를 사용해서 윈도우에서 원경으로
MySQL 접속하기 cp /usr/share/ssl/openssl.cnf $DIR
replace ./demoCA $DIR -- $DIR/openssl.cnf
# Create necessary files: $database, $serial and $new_certs_dir
# directory (optional)
touch $DIR/index.txt
echo "01" > $DIR/serial

:::MySQL Korea:::
# Generation of Certificate Authority(CA)
openssl req -new -x509 -keyout $PRIV/cakey.pem -out $DIR/cacert.pem ￦
-config $DIR/openssl.cnf
# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ................++++++
# .........++++++
# writing new private key to '/home/monty/openssl/private/cakey.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:

:::MySQL Korea:::
# -----
# You are about to be asked to enter information that will be
# incorporated into your certificate request.
# What you are about to enter is what is called a Distinguished Name
# or a DN.
# There are quite a few fields but you can leave some blank
# For some fields there will be a default value,
# If you enter '.', the field will be left blank.
# -----
# Country Name (2 letter code) [AU]:FI
# State or Province Name (full name) [Some-State]:.
# Locality Name (eg, city) []:
# Organization Name (eg, company) [Internet Widgits Pty Ltd]:MySQL AB
# Organizational Unit Name (eg, section) []:
# Common Name (eg, YOUR name) []:MySQL admin
# Email Address []:

:::MySQL Korea:::
# Create server request and key
openssl req -new -keyout $DIR/server-key.pem -out ￦
$DIR/server-req.pem -days 3600 -config $DIR/openssl.cnf
# Sample output:
# ..++++++
# ..........++++++
# writing new private key to '/home/monty/openssl/server-key.pem'
# -----

:::MySQL Korea:::
# or a DN.
# -----
# Common Name (eg, YOUR name) []:MySQL server
# Email Address []:
# Please enter the following 'extra' attributes

:::MySQL Korea:::
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:
# Remove the passphrase from the key (optional)
openssl rsa -in $DIR/server-key.pem -out $DIR/server-key.pem
# Sign server cert
openssl ca -policy policy_anything -out $DIR/server-cert.pem ￦
-config $DIR/openssl.cnf -infiles $DIR/server-req.pem

:::MySQL Korea:::
# Sample output:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName :PRINTABLE:'FI'
# organizationName :PRINTABLE:'MySQL AB'
# commonName :PRINTABLE:'MySQL admin'
# Certificate is to be certified until Sep 13 14:22:46 2003 GMT
# (365 days)
# Sign the certificate? [y/n]:y
# 1 out of 1 certificate requests certified, commit? [y/n]y
# Write out database with 1 new entries

:::MySQL Korea:::
# Data Base Updated
# Create client request and key
openssl req -new -keyout $DIR/client-key.pem -out ￦
$DIR/client-req.pem -days 3600 -config $DIR/openssl.cnf
# Sample output:
# .....................................++++++
# .............................................++++++
# writing new private key to '/home/monty/openssl/client-key.pem'
# -----

:::MySQL Korea:::
# or a DN.
# -----
# Common Name (eg, YOUR name) []:MySQL user
# Email Address []:

:::MySQL Korea:::
# Please enter the following 'extra' attributes
# to be sent with your certificate request
# A challenge password []:
# An optional company name []:
# Remove a passphrase from the key (optional)
openssl rsa -in $DIR/client-key.pem -out $DIR/client-key.pem
# Sign client cert
openssl ca -policy policy_anything -out $DIR/client-cert.pem ￦
-config $DIR/openssl.cnf -infiles $DIR/client-req.pem

:::MySQL Korea:::
# Sample output:
# Check that the request matches the signature
# Signature ok
# The Subjects Distinguished Name is as follows
# countryName :PRINTABLE:'FI'
# organizationName :PRINTABLE:'MySQL AB'
# commonName :PRINTABLE:'MySQL user'
# Certificate is to be certified until Sep 13 16:45:17 2003 GMT
# (365 days)
# Sign the certificate? [y/n]:y
# 1 out of 1 certificate requests certified, commit? [y/n]y

:::MySQL Korea:::
# Write out database with 1 new entries
# Data Base Updated
# Create a my.cnf file that you can use to test the certificates
cnf=""
cnf="$cnf [client]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/client-cert.pem"
cnf="$cnf ssl-key=$DIR/client-key.pem"
cnf="$cnf [mysqld]"
cnf="$cnf ssl-ca=$DIR/cacert.pem"
cnf="$cnf ssl-cert=$DIR/server-cert.pem"
cnf="$cnf ssl-key=$DIR/server-key.pem"
echo $cnf | replace " " '

:::MySQL Korea:::
' > $DIR/my.cnf
SSL 접속을 테스트 하기 위해서는, 서버를 아래와 같이 시작하는데, 여기에서 $DIR은 샘플 my.cnf 옵션 파일이 저장되어 있는 디
렉토리의 경로 이름이다:
shell> mysqld --defaults-file=$DIR/my.cnf &
그 다음에 동일한 옵션 파일을 사용해서 클라이언트 프로그램을 호출한다:
shell> mysql --defaults-file=$DIR/my.cnf
여러분이 MySQL 소스 배포판을 가지고 있다면, 위에 있는 my.cnf 파일이 배포판의 SSL 디렉토리에 있는 데모 인증서와 키 파일
을 참조하도록 설정을 변경해서 테스트 할 수도 있다.

:::MySQL Korea:::
제목검색
5.9.7.5. SSL 명령어 옵션

5. 데이터 베이스 관리 아래에 있는 리스트는 SSL, 인증서 파일, 그리고 키 파일의 사용을 지정하기 위해 사용되는 옵션을 설명하는 것이다. 이
5.9. MySQL 사용자 계정 관리 옵션들은 명령어 라인 또는 옵션 파일에서 지정될 수 있다.
● --ssl
서버의 경우, 이 옵션은 서버가 SSL 접속을 허용한다는 것을 가리킨다. 클라이언트 프로그램에 대해서는, 이 옵
션은 클라이언트가 SSL을 사용해서 서버에 접속할 수 있다는 것을 나타낸다. 이 옵션 자체만을 가지고는 SSL
접속을 만들 수가 없다. 여러분은 반드시 --ssl-ca, --ssl-cert, 그리고 --ssl-key 옵션을 함께 지정해야
한다.
5.9.7.6 SSH를 사용해서 윈도우에서 원경으로 MySQL 접속
이 옵션은 SSL을 사용하지 말도록 가리키기 위한 형태로 보다 많이 사용된다. 이렇게 지정하기 위해서는, 옵션
하기
을 --skip-ssl 또는 --ssl=0와 같이 지정한다.
--ssl 의 사용은 SSL 접속을 요구하지 않는다는 것을 알아두자. 예를 들면, 만일 서버 또는 클라이언트가 SSL
을 지원하지 않고 컴파일 되었다면, 일반적인 암호화 되지 않은 접속이 사용된다.
SSL 접속이 사용되고 있다는 것을 확인하는 방법은 GRANT 명령문 안에 REQUIRE SSL 구문을 포함하고 있
는 계정을 서버에서 생성하는 것이다. 그런 다음에 이 계정을 사용해서 서버에 접속을 하는데, 이때 서버와 클라
이언트가 모두 SSL 지원을 활성화 되어 있어야 한다.
● --ssl-ca=file_name
신뢰성이 있는 SSL CA 리스트를 가지고 있는 파일에 대한 경로
● --ssl-capath=directory_name
신뢰성이 있는 SSL CA 인증서를 PEM 포맷 형태로 가지고 있는 디렉토리의 경로.

:::MySQL Korea:::
● --ssl-cert=file_name
보안 접속 구축을 위해 사용되는 SSL 인증 파일의 이름.
● --ssl-cipher=cipher_list
SSL 암호화를 위해 사용되는 암호 리스트. cipher_list는 openssl ciphers 명령어와 동일한 포맷이다.
예: --ssl-cipher=ALL:-AES:-EXP
● --ssl-key=file_name
보안 접속 구축을 위해 사용되는 SSL 키 파일의 이름.

:::MySQL Korea:::
제목검색
5.9.7.6. SSH를 사용해서 윈도우에서 원경으로 MySQL 접속하기

5. 데이터 베이스 관리 여기에서는 원격 MySQL 서버를 SSH를 사용해서 보안 접속을 하는 방법을 설명한다 (by David Carlson
5.9. MySQL 사용자 계정 관리 <dcarlson@mplcomm.com>):
1. SSH 클라이언트를 여러분의 윈도우 머신에 설치한다. 무료 버전이 아닌 것 중에 가장 좋은 것은 http://
www.vandyke.com/에 있는 SecureCRT이다. 또 다른 옵션은 http://www.f-secure.com/에 있는 f-secure이
다. 무료 버전의 경우, http://directory.google.com/Top/Computers/Security/Products_and_Tools/
Cryptography/SSH/Clients/Windows/에서 찾을 수가 있다.
2. 윈도우를 SSH 클라이언트와 함께 시작한다. Host_Name = yourmysqlserver_URL_or_IP를 설정한다. 서
버에 로그인 하기 위해 userid=your_userid를 설정한다. userid 값은 MySQL 계정의 사용자 이름과 동일하지 않
5.9.7.6 SSH를 사용해서 윈도우에서 원경으로 MySQL 접
을 수도 있다.
속하기
3. 포트를 전방향(forwarding)으로 설정한다. 원격 전방향(remote forward) (local_port: 3306,
remote_host: yourmysqlservername_or_ip, remote_port: 3306 ) 또는 로컬 전방향(local forward) (port:
3306, host: localhost, remote port: 3306)으로 설정한다.
4. 모든 것을 저장한다, 그렇지 않으면, 다음에 위의 모든 것을 다시 실행해야 한다.
5. 지금 막 생성한 SSH 세션을 가지고 서버에 로그인 한다.
6. 윈도우 머신에서, ODBC 어플리케이션을 시작한다 (Access와 같은 것).
7. 윈도우에서 새로운 파일을 생성하고 여러분이 일반적으로 하는 방식대로 ODBC 드라이버를 사용해서
MySQL에 링크를 하되, MySQL 호스트 서버에 대한 localhost 에는 yourmysqlservername를 타이핑하지 않는
다.
이때, 여러분은 SSH를 사용한 암호화를 통해 MySQL에 ODBC 접속을 가지게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.10. 백업 및 복구
5.10.1. 데이터 베이스 백업
5. 데이터 베이스 관리 5.10.2. 백업 및 복구 전략 예제
5.10. 백업 및 복구 5.10.3. 시점(Point-in-Time) 복구
5.10 백업 및 복구 5.10.4. 테이블 관리와 크래시(Crash) 복구
5.10.1 데이터 베이스 백업

5.10.2 백업 및 복구 전략 예제 이 섹션에서는 데이터 베이스 백업 (전체 그리고 증분(incremental))을 만드는 방법과 테이블 관리를 하는 방법에 대해 설
5.10.3 시점(Point-in-Time) 복구 명을 하기로 한다. 여기에서 설명하는 SQL 명령문의 신텍스는 Chapter 13, SQL 명령문 신텍스 에서 설명을 한다. 여기에
서 설명하는 것들은 주로 MyISAM에 관련되어 있다. InnoDB 백업 과정에 대한 설명은 Section 14.2.8, “InnoDB 데이터
5.10.3.1 복구 시간 지정하기
베이스 백업 및 복구”에서 하기로 한다.
5.10.3.2 복구 위치 지정하기
5.10.4 테이블 관리와 크래시(Crash) 복구
5.10.4.1 크래시 복구를 위해 myisamchk 사용하기
5.10.4.2 에러에 대해 MyISAM 테이블을 검사하는 방법
5.10.4.3 테이블 치료하는 방법
5.10.4.4 테이블 최적화
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.10.1. 데이터 베이스 백업
5. 데이터 베이스 관리 MySQL 테이블은 파일 형태로 저장되기 때문에, 백업을 하기가 쉽다. 일관된 백업을 하기 위해서는, 연관된 테이블에 FLUSH
5.10. 백업 및 복구 TABLES 다음에 LOCK TABLES을 한다. Section 13.4.5, “LOCK TABLES 및 UNLOCK TABLES 신텍스”, 그리고
5.10.1 데이터 베이스 백업 Section 13.5.5.2, “FLUSH 신텍스”를 참조할 것. 여러분은 읽기 잠금만 하면 된다; 이렇게 하면 여러분이 데이터 베이스 디렉
토리에 파일 복사를 하는 동안에도 다른 클라이언트가 테이블에 쿼리를 계속 할 수 있도록 해 준다. 여러분이 백업을 시작하기 전
에 모든 액티브 인덱스 페이지를 디스크에 쓰기 위해서는 FLUSH TABLES 명령문이 필요하다.
테이블의 SQL-레벨 백업을 만들기 위해서는, SELECT INTO ... OUTFILE를 사용한다
데이터 베이스 백업에 대한 또 다른 방법은 mysqldump 프로그램 또는 mysqlhotcopy script 스크립트를 사용하는 것이다.
Section 8.10, “mysqldump — 데이터 베이스 백업 프로그램”, 및 Section 8.11, “mysqlhotcopy — 데이터 베이스 백업 프로
그램”을 참조할 것.
1. 데이터 베이스 전체 백업을 만든다.
2. shell> mysqldump --tab=/path/to/some/dir --opt db_name
또는:
shell> mysqlhotcopy db_name /path/to/some/dir
여러분은 서버가 아무것도 업데이트를 하지 않는 다면, 간단하게 전체 테이블 파일(*.frm, *.MYD, 및 *.MYI 파일)을 복사
해서 바이너리 백업을 만들 수도 있다. mysqlhotcopy 스크립트는 이 방법을 사용한다. (하지만, 데이터 베이스가
InnoDB 테이블을 가지고 있다면, 이 방법을 사용할 수가 없다. InnoDB는 데이터 디렉토리에 테이블 컨텐츠를 저장하지
않으며, 또한 mysqlhotcopy은 MyISAM 테이블에 대해서만 동작을 한다.)
3. mysqld이 구동 중이라면 종료를 시키고, 그런 다음에 그것을 --log-bin[=file_name] 옵션을 사용해서 다시 구동

:::MySQL Korea:::
시킨다. Section 5.12.3, “바인리 로그” 참조. 바이너리 로그 파일은 여러분이 mysqldump를 실행 시킨 시점에 만들어
진 변경 사항을 데이터 베이스에 리플리케이트 시키는데 필요한 정보를 제공해 준다.
InnoDB 테이블의 경우, 테이블에 잠금을 하지 않고 온라인 백업을 실행할 수가 있다; Section 8.10, “mysqldump — 데이터 베
이스 백업 프로그램”을 참조할 것.
MySQL은 증분(incremental) 백업을 지원한다: 여러분은 --log-bin 옵션을 사용해서 서버를 구동 시켜서 바이너리 로깅을 활성
화 시킬 필요가 있다; Section 5.12.3, “바이너리 로그”를 참조. 여러분이 증분 백업을 하고자 원할 경우에는 (마지막 전체 또는
증분 백업을 한 이후에 변경된 모든 것을 포함), FLUSH LOGS를 사용해서 바이너리 로그를 바꿔야(rotate) 한다. 이것을 실행하
고 나면, 모든 바이너리 로그를 백업 위치에 복사할 필요가 있게 된다. 이러한 바이너리 로그들은 증분 백업본이다; 복원(restore)
시점이 되면, 여러분은 이후의 섹션에서 설명하는 방법으로 이것들을 사용한다. 그 다음으로 전체 백업을 하고자 한다면, 여러분은
역시 FLUSH LOGS, mysqldump --flush-logs, 또는 mysqlhotcopy --flushlog를 사용해서 바이너리 로그를 바꿔야 한다.
Section 8.10, “mysqldump — 데이터 베이스 백업 프로그램”, and Section 8.11, “mysqlhotcopy — 데이터 베이스 백업 프
로그램”을 참조.
여러분의 서버가 슬레이브 리플리케이션 서버라면, 여러분이 선택한 백업 방법에 관계없이, 슬레이브의 데이터를 백업할 때에는,
master.info 와 relay-log.info 파일도 함께 백업해야 한다. 이 파일들은 여러분이 슬레이브의 데이터를 복원한 후에 리플리케이션
을 다시 시작하기 위해 항상 필요한 것들이다. 만약에 슬레이브가 LOAD DATA INFILE 명령어를 리플리케이트 해야 한다면, 여
러분은 --slave-load-tmpdir 옵션이 지정하는 디렉토리에 있는 모든 SQL_LOAD-* 파일들도 함께 백업해야 한다. (이 위치가
지정이 되지 않으면, tmpdir 변수 값이 디폴트로 사용된다.) 슬레이브는 인터럽트된 LOAD DATA INFILE 동작의 리플리케이션
재 구동을 위해 이 파일들이 필요하게 된다.
만약에 MyISAM 테이블을 복원 해야 한다면, 우선 REPAIR TABLE 또는 myisamchk –r를 사용해서 테이블을 복구하도록 해본
다. 이렇게 하면 99.9%가 복구 된다. 만약에 myisamchk가 실패한다면, 아래의 프로시저를 시도해 본다. 여러분이 --log-bin 옵
션을 사용해서 MySQL을 구동 시켜서 바이너리 로깅을 활성화 시켰을 경우에만 이것이 동작한다는 것을 명심하기 바란다.
1. 원본 mysqldump 백업 또는 바이너리 백업을 복원한다.

2. 바이너리 로그에 있는 업데이트를 재 구동 시키기 위해 아래의 명령어를 실행 시킨다:
3. shell> mysqlbinlog binlog.[0-9]* | mysql

:::MySQL Korea:::
어떤 경우에는, 특정 위치에 있는 특정 바이너리 로그만을 재구동 시키고자 할 것이다. Section 8.8, “mysqlbinlog — 바
이너리 로그 파일을 처리하기 위한 유틸리티”에서, mysqlbinlog 유틸리티와 활용법에 대해 보다 자세히 알아보기 바란
다.
여러분은 개별 파일들에 대한 선택적인 백업도 할 수가 있다:
● 테이블을 덤프하기 위해서는, SELECT * INTO OUTFILE 'file_name' FROM tbl_name를 사용한다.
● 테이블을 재 로드하기 위해서는, LOAD DATA INFILE 'file_name' REPLACE .... 를 사용한다. 열 중복을 피하기 위해서
는, 테이블은 반드시 PRIMARY KEY 또는 UNIQUE 인덱스를 가지고 있어야 한다. REPLACE 키워드는 고유의 키 값에
이전 열을 새로운 열로 중복시킬 때 이전 열이 새로운 열로 대체되도록 만든다.
백업을 진행하는 중에 시스템의 성능에 문제가 발생한다면, 한가지 전략은 리플리케이션을 설정을 한 다음에 서버가 아닌 슬레이브
에서 백업을 실행 시키는 것이다. Section 6.1, “리플리케이션 소개”를 참조.
여러분이 Veritas 파일 시스템을 사용한다면, 아래와 같이 백업을 만들 수가 있다:
1. 클라이언트 프로그램에서, FLUSH TABLES WITH READ LOCK를 실행한다.

2. 다른 쉘에서, mount vxfs snapshot를 실행한다.
3. 첫 번째 클라이언트에서, UNLOCK TABLES를 실행한다.
4. 스냅샷에서 파일을 복사한다.
5. 스냅샷 마운트를 해제한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.10.2. 백업 및 복구 전략 예제
5. 데이터 베이스 관리 5.10.2.1. 백업 정책

5.10. 백업 및 복구 5.10.2.2. 복구를 위한 백업 사용
5.10.2 백업 및 복구 전략 예제 5.10.2.3. 백업 전략 정리
이 섹션은 여러 가지의 데이터 크래시가 발생한 후에 데이터를 복구할 수 있는 백업을 실행하는 과정을 설명한다:
● OS 크래시
● 파워(Power) 문제
● 파일 시스템 크래시
● 하드웨어 문제 (하드 드라이브, 마더 보드, 및 기타 등등)
예제의 명령어들은 mysqldump 와 mysql 프로그램에 대해 --user 와 --password 와 같은 옵션을 포함하고 있지 않다. 여러분
이 MySQL 서버에 접속을 하기 위해서는 필요한 옵션들을 함께 넣어야 한다.
우리는 데이터가 InnoDB 스토리지 엔진에 저장되어 있다고 가정하는데, 이 엔진은 트랜젝션과 자동 크래시 복구를 지원한다. 우리
는 또한 크래시가 되는 시점에 MySQL 서버가 로드중에 있다는 가정을 한다. 그런 상황이 아니라면, 아무런 복구도 필요 없게 된
다.
OS 크래시 또는 시스템 파워 문제의 경우, MySQL의 디스크 데이터는 서버를 재 구동 시키면 사용 가능하다고 가정할 수 있다.
InnoDB 데이터 파일은 크래시로 인해 일관된 데이터를 가지고 있지 않을 수도 있으나, InnoDB는 자신의 로그를 읽고, 그 로그에
서 데이터 파일에 플러시 되지 않은 실행된(committed) 트랜젝션과 실행되지 않고(non-committed) 지연 된 트랜젝션의 리스트
를 찾게 된다. InnoDB 는 자동으로 실행되지 않은 트랜젝션으로 롤백 되고, 이미 실행된 트랜젝션을 자신의 데이터 파일에 플러시
한다. 이러한 복구 과정에 대한 정보는 MySQL 에러 로그를 통해 사용자에게 전달 된다. 아래의 것은 예제 로그에서 발췌한 것이
다:

:::MySQL Korea:::
InnoDB: Database was not shut down normally.
InnoDB: Starting recovery from log files...
InnoDB: Starting log scan based on checkpoint at
InnoDB: log sequence number 0 13674004
InnoDB: Doing recovery: scanned up to log sequence number 0 13739520
...
InnoDB: 1 uncommitted transaction(s) which must be rolled back
InnoDB: Starting rollback of uncommitted transactions
InnoDB: Rolling back trx no 16745
InnoDB: Rolling back of trx no 16745 completed
InnoDB: Rollback of uncommitted transactions completed

:::MySQL Korea:::
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections
파일 시스템 크래시 또는 하드웨어 문제의 경우, 우리는 MySQL의 디스크 데이터는 서버를 재 구동 시켜도 사용할 수 없을 것이라
고 생각한다. 이와 같은 경우에는, 디스크를 재 포맷시키거나, 다른 디스크를 설치하거나, 또는 다른 조치를 취할 필요가 있게 된
다. 그런 다음에 백업 파일에서 복구를 해야 한다. 이러한 경우를 대비하기 위해, 우리는 백업 정책을 만들어 두어야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.10.3. 시점(Point-in-Time) 복구
5. 데이터 베이스 관리 5.10.3.1. 복구 시간 지정하기

5.10. 백업 및 복구 5.10.3.2. 복구 위치 지정하기
5.10.3 시점(Point-in-Time) 복구
5.10.3.1 복구 시간 지정하기 MySQL 서버가 바이너리 로그를 활성화 시키기 위해 --log-bin 옵션을 가지고 시작되었다면, 여러분은 mysqlbinlog 유틸리티
를 사용하여 지정된 시점에서부터 바이너리 로그 파일에서 데이터를 복구할 수가 있다. 바이너리 로그 활성화와 mysqlbinlog의 사
용에 대한 정보는 Section 5.12.3, “바이너리 로그” 와 Section 8.8, “mysqlbinlog — 바이너리 로그 파일 처리를 위한 유틸리
티”를 참조할 것.
바이너리 로그에서 데이터를 복구하기 위해서는, 현재의 바이너리 로그의 정확한 이름과 저장 위치를 알고 있어야 한다. 디폴트로,
서버는 바이너리 로그를 데이터 디렉토리에 생성하지만, 다른 위치에 파일을 저장하기 위해서는 --log-bin 옵션을 사용해서 경
로 이름을 지정해야 한다. 전형적으로 옵션은 옵션 파일에서 주게 된다 (즉, my.cnf 또는 my.ini). 옵션은 서버가 시작될 때 명령
어 라인에서도 줄 수가 있다. 현재의 디렉토리 이름을 알아 보기 위해서는, 아래의 명령어를 사용한다:
mysql> SHOW BINLOG EVENTS￦G
여러분이 원할 경우에는, 아래의 명령어를 명령어 라인에 대신 입력한다:
shell> mysql -u root -p -E -e "SHOW BINLOG EVENTS"
mysql 프롬프트가 나오면 root 패스워드를 입력한다.
:::MySQL Korea:::
제목검색
5.10.3.1. 복구 시간 지정하기
5. 데이터 베이스 관리 복구 시작 시점과 종료 시점을 지정하기 위해서는, DATETIME 포맷에서 mysqlbinlog에 대한--start-date 와 --stop-date
5.10. 백업 및 복구 옵션을 지정한다. 예를 들면, 정확히 2005년 4월 20일 오전 10시 정각에 테이블을 삭제하는 SQL 명령문을 실행했다고 가정하자.
5.10.3 시점(Point-in-Time) 복구 이 테이블과 데이터를 복구하기 위해서는, 여러분은 전날 밤에 백업해 놓은 파일을 복원한 다음에, 아래의 명령어를 실행한다:
5.10.3.1 복구 시간 지정하기
shell> mysqlbinlog --stop-date="2005-04-20 9:59:59" ￦
/var/log/mysql/bin.123456 | mysql -u root -p
이 명령어는 --stop-date 옵션이 지정하는 날짜와 시간 이전의 모든 데이터를 복구한다. 만약에 여러분이 10시 이후에 잘못 입
력한 SQL 명령문을 검사하지 않았다면, 여러분은 아마도 그 후에 발생한 서버의 동작도 함께 복구하고 싶을 것이다. 이러한 가정하
에, 여러분은 아래와 같이 시작 날짜와 시간을 다시 입력하여 mysqlbinlog을 재 구동 시킬 수가 있다.
shell> mysqlbinlog --start-date="2005-04-20 10:01:00" ￦
/var/log/mysql/bin.123456 | mysql -u root -p
이 명령어에서 보면, 10시 1초에 로그된 SQL 명령문이 재 동작할 것이다. 전날 밤에 덤프한 파일과 두 개의 mysqlbinlog 명령어
를 조합하면 10시 1초 전까지의 모든 것과 10시 1초 후의 모든 것을 복구하게 된다. 명령어에 지정할 시간을 정확히 하기 위해서
는 로그를 조사해야 한다. 로그 파일을 실행하지 않고 내용물을 보기 위해서는, 아래의 명령어를 실행한다:
shell> mysqlbinlog /var/log/mysql/bin.123456 > /tmp/mysql_restore.sql
그런 다음에 텍스트 편집기를 사용해서 파일을 검사한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
5.10.3.2. 복구 위치 지정하기
5. 데이터 베이스 관리 날짜와 시간을 지정하는 대신에, mysqlbinlog에 대한 --start-position 과 --stop-position 옵션을 사용하여 로그 위치를 지
5.10. 백업 및 복구 정할 수가 있다. 이것들은 시작 일자와 종료 일자 지정 옵션과 동일한 동작을 하는데, 이때 여러분은 일자 대신에 로그의 위치 번호
5.10.3 시점(Point-in-Time) 복구 를 지정 해주어야 한다. 로그의 위치를 사용하는 것은 복구할 로그의 부분을 보다 정확하게 지정할 수 있게끔 해 주는 것인데, 특히
5.10.3.1 복구 시간 지정하기 옳지 못한 SQL 명령문으로 인해 동시에 많은 트랜젝션이 발생하는 경우에 유용하게 사용된다. 로그의 위치 번호를 알아내기 위해
5.10.3.2 복구 위치 지정하기 서는, 원하지 않은 트랜젝션이 발생했던 시간 전후에 대해 mysqlbinlog을 구동 시킨다. 결과는 텍스트 파일 형태로 나온다. 아래와
같이 실행할 수가 있다:
shell> mysqlbinlog --start-date="2005-04-20 9:55:00" ￦
--stop-date="2005-04-20 10:05:00" ￦
/var/log/mysql/bin.123456 > /tmp/mysql_restore.sql
이 명령어는 /tmp 디렉토리 안에 작은 텍스트 파일을 하나 생성하는데, 이 파일은 옳지 않은 SQL 명령문이 실행 되었던 시점 주변
의 SQL 명령문을 가지게 된다. 텍스트 편집기를 사용해서 이 파일을 연 다음에 반복되지 말아야 할 명령문을 찾아낸다. 바이너리
로그에서 종료를 하고 다시 구동 시킬 위치를 찾아 낸다. 로그의 위치는 log_pos 다음에 숫자를 사용해서 레이블 되어 있다. 이전
백업 파일을 복원한 다음에, 이 위치 번호를 사용해서 바이너리 로그 파일을 처리한다. 예를 들면, 여러분은 아래와 비슷한 명령어
를 사용할 것이다:
shell> mysqlbinlog --stop-position="368312" /var/log/mysql/bin.123456 ￦
| mysql -u root -p

:::MySQL Korea:::
shell> mysqlbinlog --start-position="368315" /var/log/mysql/bin.123456 ￦
| mysql -u root -p
첫 번째 명령어는 지정된 종료 위치 전까지 나타난 모든 트랜젝션을 복구한다. 두 번째 명령어는 지정된 시작 시점에서부터 바이너
리 로그의 끝까지의 모든 트랜젝션을 복구한다. mysqlbinlog의 결과 값에는 SQL 명령문이 기록되기 전의 SET TIMESTAMP 명
령문을 포함하고 있기 때문에, 복구된 데이터와 이에 관련된 MySQL로그는 트랜젝션이 실행된 원래의 시점에 반영이 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.10.4. 테이블 관리와 크래시(Crash) 복구
5. 데이터 베이스 관리 5.10.4.1. 크래시 복구를 위해 myisamchk 사용하기

5.10. 백업 및 복구 5.10.4.2. 에러에 대해 MyISAM 테이블 검사하는 방법
5.10.4 테이블 관리와 크래시(Crash) 복구 5.10.4.3. 테이블 치료하는 방법
5.10.4.1 크래시 복구를 위해 myisamchk 사용하기 5.10.4.4. 테이블 최적화
5.10.4.2 에러에 대해 MyISAM 테이블을 검사하는 방법 5.10.4.5. 테이블 정보 가져오기

5.10.4.6. 테이블 관리(Maintenance) 스케쥴 설정
5.10.4.4 테이블 최적화
이 섹션에서는 MyISAM 테이블(이 테이블은 데이터와 인덱스를 저장하기 위한 .MYD 와 .MYI 파일을 가지고 있음)을 검사
하거나 또는 치료하기 위해 myisamchk를 사용하는 방법에 대해 설명을 한다. 일반적인 myisamchk에 대해서는
Section 8.2, “myisamchk — MyISAM 테이블-관리 유틸리티”를 참조할 것.
여러분은 myisamchk를 사용해서 데이터 베이스 테이블에 대한 정보를 얻거나, 이 테이블을 검사, 치료, 또는 최적화를 할 수
가 있다. 다음에 나오는 섹션에서는 이러한 동작을 어떻게 실행 시키는지 그리고 테이블 관리 스케쥴을 어떻게 설정하는지에
대해 설명하기로 한다.
myisamchk를 사용하는 테이블 치료가 안전하기는 하지만, 테이블을 치료하거나 또는 테이블의 내용을 많이 변경시키는 관
리 동작 이전에 백업을 받아 두는 것이 현명하다.
인덱스에 영향을 주는 Myisamchk FULLTEXT 인덱스가 MySQL 서버가 사용하는 값들과 호환성을 갖지 못하는 전체-텍
스트 파라미터를 재 구축하게끔 한다. 이러한 문제를 피하기 위해서는, Section 8.2.1, “myisamchk 일반 옵션”에 나와 있
는 가이드 라인을 따르기 바란다..
많은 경우에, 여러분은 myisamchk 동작을 하는 SQL 명령문을 사용해서 MyISAM 테이블을 관리하는 것이 보다 손 쉽다는
것을 알게 될 것이다:

:::MySQL Korea:::
● MyISAM 테이블을 검사 또는 치료하기 위해서는, CHECK TABLE 또는 REPAIR TABLE를 사용한다.

● MyISAM 테이블을 최적화 하기 위해서는, OPTIMIZE TABLE을 사용한다.
● MyISAM 테이블을 분석하기 위해서는, ANALYZE TABLE을 사용한다.
이러한 명령문들은 직접 또는 mysqlcheck 클라이언트 프로그램을 통해서 사용할 수가 있다. 이러한 명령문들이
myisamchk에 비해 가지고 있는 하나의 장점은 서버가 모두 실행할 수 있다는 것이다. Myisamchk를 사용한다면,
myisamchk과 서버 사이에 원하지 않는 상호 작용이 발생하지 않도록 하기 위해서 서버는 동시에 테이블을 사용할 수 없다
는 것을 알고 있어야 한다. Section 13.5.2.1, “ANALYZE TABLE 신텍스”, Section 13.5.2.3, “CHECK TABLE 신텍
스”, Section 13.5.2.5, “OPTIMIZE TABLE 신텍스”, 그리고 Section 13.5.2.6, “REPAIR TABLE 신텍스”를 참조
할 것.

:::MySQL Korea:::
제목검색
5.10.4.1. 크래시 복구를 위해 myisamchk 사용하기

5.10. 백업 및 복구 이 섹션은 MySQL 데이터 베이스의 데이터 깨짐을 검사하고 처리하는 방법에 대해 설명을 한다. 여러분의 테이블이 자주 깨
5.10.4 테이블 관리와 크래시(Crash) 복구 진다면, 그 이유를 분명히 알아 두어야 한다. Section A.4.2, “What to Do If MySQL Keeps Crashing”를 참조할 것.

MyISAM 테이블이 어떻게 깨지는지를 설명하기 위해서는 Section 14.1.4, “MyISAM 테이블 문제”를 참조하기 바란다.
여러분이 mysqld을 외부 잠금이 비활성화 된 상태로 구동 시킨다면 (4.0 이후에는 디폴트임), myisamchk를 사용해서
5.10.4.4 테이블 최적화
mysqld이 사용하고 있는 테이블을 안정적으로 검사할 수는 없게 된다. 만약에 여러분이 myisamchk을 사용하는 중에는 아
무도 mysqld 를 통해서 테이블에 접근하지 않는 다고 확신을 한다면, 테이블 검사를 하기 전에 mysqladmin flush-tables
5.10.4.6 테이블 관리(Maintenance) 스케줄 설정 를 실행 시키기만 하면 된다. 이것을 확신하지 못하는 경우에는, 여러분이 테이블을 검사하는 도중에는 반드시 mysqld를 종
료시켜야 한다. 만약에 myisamchk를 구동 시켜서 mysqld이 똑 같은 시간에 업데이트를 하고 있는 테이블을 검사한다면, 테
이블이 깨진다는 경고문을 받게 될 것이다.
만약에 서버를 외부 잠금 활성화 상태로 구동 시킨다면, 어느 때라도 myisamchk를 사용해서 테이블을 검사할 수가 있다. 이
와 같은 경우, 만약에 서버가 myisamchk가 사용하고 있는 테이블을 업데이트 하고자 시도하면, 서버는 myisamchk가 마치
기를 기다리게 된다.
만약에 myisamchk를 사용해서 테이블을 치료 또는 최적화 시킨다면, 여러분은 반드시 mysqld 서버는 그 테이블을 사용하
고 있지 않음을 항상 확인해야 한다 (이것은 외부 잠금이 비활성화된 상태에도 동일하게 적용된다). 만약에 Mysqld을 종료
하지 않는다면, 여러분은 최소한 myisamchk를 구동하기 전에는 a mysqladmin flush-tables를 실행해야 한다. 만약에 서
버와 myisamchk가 동시에 테이블에 접근을 한다면, 테이블은 깨지게 될 것이다.
크래시 복구를 할 때에는, 데이터 베이스에 있는 각 MyISAM 테이블 tbl_name 은 데이터 베이스 디렉토리에 있는 세 개의
파일에 대응한다는 것을 이해하는 것이 중요하다:

:::MySQL Korea:::
File Purpose
tbl_name.frm 정의문(포맷) 파일
tbl_name.MYD 데이터 파일
tbl_name.MYI 인덱스 파일
이 세 개의 파일 타입은 각각 다양한 방식의 데이터 깨짐과 관련을 가지고 있으나, 대부분의 깨짐은 데이터 파일과 인덱스 파
일에서 발생하게 된다.
Myisamchk은 .MYD 데이터 파일을 줄 별로 복사를 하면서 동작을 한다. 이것은 구형 .MYD파일을 제거 하고 새로운 파일
을 원래의 파일 이름으로 변경을 한 다음에 치료 과정을 종료한다. 만약에 여러분이 –quick 옵션을 사용한다면, myisamchk
은 임시 .MYD파일을 생성하지 않으며, 대신에 .MYD 파일이 정확하다고 가정으로 하고 .MYD 파일을 손 대지 않고 새로운
인덱스 파일을 만들게 된다. 이런 동작은 안전한데, 그 이유는 myisamchk은 자동적으로 .MYD파일이 깨졌는지 그리고 치료
를 해야 하는지를 검사하기 때문이다. 여러분은 --quick 옵션을 myisamchk에 두 번 사용할 수도 있다. 이 경우에,
myisamchk는 어떤 에러(중복-키 에러 와 같은)에서는 종료를 하지 않는 대신에 .MYD 파일을 수정해서 문제를 해결하려
는 시도를 하게 된다. 일반적으로 --quick 옵션을 두 번 사용하는 것은, 만약에 일반적인 치료를 진행하기에는 여유 공간이
너무 부족한 경우에, 매우 유용하게 된다. 이와 같은 경우, 여러분은 myisamchk를 구동하기 전에 최소한 한번은 백업을 해
두는 것이 좋다.

:::MySQL Korea:::
제목검색
5.10.4.2. 에러에 대해 MyISAM 테이블을 검사하는 방법

5. 데이터 베이스 관리 MyISAM 테이블을 검사하기 위해서는, 아래의 명령어를 사용한다:

5.10. 백업 및 복구
5.10.4 테이블 관리와 크래시(Crash) 복구 ● myisamchk tbl_name

이것은 모든 에러의 99.99%를 찾아 낸다. 하지만 데이터 파일에만 포함되어 있는 데이터 깨짐은 발견하지 못한다
(매우 드문 경우임). 테이블을 검사하고자 한다면, 옵션 없이 myisamchk를 구동 시키거나 또는 -s (silent) 옵션
을 사용해서 구동 시키는 것이 일반적이다.
5.10.4.4 테이블 최적화
5.10.4.5 테이블 정보 가져오기 ● myisamchk -m tbl_name
이것은 모든 에러의 99.999%를 찾아낸다. 이것은 우선 에러에 대한 모든 인덱스 엔트리를 검사하고, 그 다음에 모
든 열을 읽는다. 이것은 열에 있는 모든 키 값의 체크 섬을 계산하고 인덱스 트리에 있는 키 값의 체크 섬과 서로 비
교를 한다.
● myisamchk -e tbl_name
이것은 모든 데이터를 완벽하고 철저하게 검사한다 (-e는 “확대 검사(extended check)”를 의미함). 이것은 모
든 키가 올바른 열을 가리키고 있는지를 검증하기 위해 각 열에 대한 모든 키 값을 검사-읽기(check-read) 한다.
이것은 많은 인덱스를 가지고 있는 대형 테이블의 경우에는 많은 시간이 걸리게 된다. 일반적으로, myisamchk는
첫 번째 에러가 발견되면 즉시 종료를 한다. 만약에 보다 많은 정보를 얻고자 한다면, -v (verbose) 옵션을 추가한
다. 이것은 myisamchk이 20개의 에러를 발견할 때 까지 계속 진행을 하도록 만든다.
● myisamchk -e -i tbl_name
이것은 앞의 명령어와 비슷한 것이지만, -i 옵션은 myisamchk이 추가적인 통계 정보를 프린트 하도록 만든다.

:::MySQL Korea:::
대부분의 경우, 테이블 이름을 사용하지 않고 단순히 myisamchk 명령어를 사용해서도 충분히 테이블을 검사할 수 있다.

:::MySQL Korea:::
제목검색
5.10.4.3. 테이블 치료하는 방법

5.10. 백업 및 복구 이 섹션에서는 MyISAM 테이블(확장자 .MYI 와 .MYD)에서 myisamchk를 사용하는 방법을 설명하기로 한다.

여러분은 있다 MyISAM 테이블을 검사하고 치료하기 위해 CHECK TABLE 와 REPAIR TABLE 명령문을 사용할 수도.
5.10.4.1 크래시 복구를 위해 myisamchk 사용하
기 Section 13.5.2.3, “CHECK TABLE 신텍스”, 그리고 Section 13.5.2.6, “REPAIR TABLE 신텍스”를 참조할 것.
5.10.4.2 에러에 대해 MyISAM 테이블을 검사하

는 방법 테이블이 깨지게 되면 쿼리가 예상과 다르게 종료를 하게 되며 아래와 같은 에러가 발생하기도 한다:

● tbl_name.frm이 데이터 변경에 대해 잠기게 된다
5.10.4.4 테이블 최적화
● tbl_name.MYI (Errcode: nnn)를 찾을 수 없다
● 기대하지 않은 파일의 마지막 부분으로 이동
● 레코드 파일이 크래시됨
● 테이블 핸들러에서 nnn 번호의 에러를 갖게 됨
에러에 대해 보다 많은 정보를 얻기 위해서는, perror nnn를 구동 시키는데, nnn 는 에러 번호가 된다. 아래의 예제는 테이블 문제
를 가리키는 가장 일반적인 에러 번호의 의미를 알아 내기 위해 perror를 어떻게 사용하는지를 보여 준다:
shell> perror 126 127 132 134 135 136 141 144 145
126 = Index file is crashed / Wrong file format
127 = Record-file is crashed

:::MySQL Korea:::
132 = Old database file
134 = Record was already deleted (or record file crashed)
135 = No more room in record file
136 = No more room in index file
141 = Duplicate unique key or constraint on write or update
144 = Table is crashed and last repair failed
145 = Table was marked as crashed and should be repaired
에러 135 (no more room in record file)과 에러 136 (no more room in index file)는 간단한 수정으로 처리될 수 있는 것임을
알기 바란다. 이와 같은 경우에는, ALTER TABLE을 사용해서 MAX_ROWS 와 AVG_ROW_LENGTH 테이블 옵션 값을 늘려주
어야 한다:
ALTER TABLE tbl_name MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;
만약에 현재의 테이블 옵션 값을 모른다면, SHOW CREATE TABLE를 사용한다.
다른 에러에 대해서는, 여러분은 테이블을 치료해야 한다. Myisamchk는 테이블에서 발생된 에러들을 검사하고 치료하는데 일반적
으로 사용할 수 있는 것이다.
치료 과정에는 네 단계가 있다. 시작을 하기 전에, 데이터 디렉토리로 이동을 해서 테이블 파일을 검사할 수 있는 권한을 검사하기
로 한다.
만약에 명령어 라인에서 테이블을 치료하고자 한다면, 우선 mysqld 서버를 종료 시켜야 한다. 리모트 서버에서 mysqladmin
shutdown을 실행하면, mysqld 서버는 모든 명령문 프로세스가 종료를 하고 모든 인덱스 변경이 디스크에 플러시 될 때까지,
mysqladmin가 리턴 된 후에도 당분간 살아 있게 된다는 점을 알기 바란다.

:::MySQL Korea:::
Stage 1: Check your tables
myisamchk *.MYI 또는 myisamchk -e *.MYI를 구동 시킨다. -s (silent) 옵션을 사용해서 불필요한 정보를 없애도록 한다.
만약에 mysqld 서버가 종료 되면, --update-state 옵션을 사용해서 myisamchk가 테이블을 “checked”로 표시하도록 만든
다.
여러분은 myisamchk에 의해 에러가 있다고 표시된 테이블만 치료해야 한다. 그런 테이블에 대해서만 Stage 2를 진행한다.
만약에 검사를 하는 도중에 예상하지 못한 에러가 나오게 되거나(out of memory 에러와 같은), 또는 myisamchk가 크래시가 되
면, Stage 3를 실행한다.
Stage 2: Easy safe repair
우선, myisamchk -r -q tbl_name (-r –q은 “quick recovery mode”를 의미함)를 시도해 본다. 이것은 데이터 파일을 손대
지 않고 인덱스 파일을 치료하고자 한다. 만약에 데이터 파일이 모든 것을 가지고 있고 삭제 링크가 데이터 파일 안에 있는 올바른
위치를 가리키고 있다면, 이것은 제대로 동작을 하 것이고, 테이블은 수정이 된다. 다음 테이블을 치료하도록 한다. 그렇지 않은 경
우에는, 아래의 과정을 진행한다:
1. 계속 진행을 하기 전에 데이터 파일의 백업을 한다.

2. myisamchk -r tbl_name (-r 은 “recovery mode”를 의미함)을 사용한다. 이것은 올바르지 못한 열을 제거하
고 데이터 파일에서 열을 삭제하고 인덱스 파일을 재 구성한다.
3. 만약에 앞의 과정이 실패를 한다면, myisamchk --safe-recover tbl_name를 사용한다. 안전 복구 모드(Safe
recovery mode)는 레귤러 복구 모드가 지원하지 않는 경우를 구형 모드를 사용해서 처리한다.
Note: 만약에 치료 동작을 보다 빠르게 하고자 한다면, myisamchk을 구동 시킬 때 여러분이 사용 가능한 메모리의 약 25% 정도
를 sort_buffer_size 와 key_buffer_size 변수에 각각 할당하면 된다
치료를 하는 도중에 예상하지 못한 에러를 만나게 되거나 (out of memory 에러와 같은), 또는 myisamchk가 크래시 되면, Stage
3으로 간다.
Stage 3: Difficult repair

:::MySQL Korea:::
만약에 인덱스 파일의 처음 16KB블록이 깨졌거나 또는 잘못된 정보를 가지고 있거나, 또는 인덱스 파일이 빠져 있는 경우에만 이
단계의 과정을 진행한다. 아래와 같이 진행을 한다:
1. 데이터 파일을 안전한 곳으로 이동 시킨다.

2. 테이블 설명 파일을 사용해서 새로운(빈)데이터 파일과 인덱스 파일을 만든다:
3. shell> mysql db_name
4. mysql> SET AUTOCOMMIT=1;
5. mysql> TRUNCATE TABLE tbl_name;
6. mysql> quit
7. 이전 데이터 파일을 새로운 데이터 파일로 복사한다. (단순히 이동을 하지 말고, 복사를 하기 바란다. 다른 에러에 대
비해서 복사본은 계속 보관을 해야 한다.)
Stage 2로 돌아 간다. myisamchk -r –q이 제대로 동작을 할 것이다.
여러분은 REPAIR TABLE tbl_name USE_FRM SQL 명령문을 사용할 수도 있는데, 이것은 자동으로 전체 과정을 수행한다.
Section 13.5.2.6, “REPAIR TABLE 신텍스”를 참조.
Stage 4: Very difficult repair
이 단계는 .frm 설명 파일이 크래시 되었을 경우에만 해당한다. 그런 일은 결코 일어 나지 않는데, 왜냐하면 설명 파일은 테이블이
생성된 후에는 변경되지 않기 때문이다:
1. 백업에서 설명 파일을 복원한 다음에 Stage 3로 돌아 간다. 인덱스 파일을 복원한 다음에 Stage 2으로 갈 수도 있
다. 두 번째 경우, 여러분은 myisamchk –r을 가지고 시작해야 한다.
2. 만약에 여러분이 백업을 가지고 있지는 않지만, 테이블을 어떻게 생성했는지 정확히 알고 있다면, 다른 데이터 베이
스에 있는 테이블을 복사한다. 새로운 데이터 파일을 삭제하고, 다른 데이터 베이스에 있는 .frm 설명 파일과 .MYI 인덱

:::MySQL Korea:::
스 파일을 깨진 데이터 베이스로 복사한다. 이렇게 하면 새로운 설명 파일과 인덱스 파일은 만들어 지지만, .MYD 데이터
파일은 남게 된다. Stage 2로 갓 인덱스 파일을 재 구축하도록 한다.

:::MySQL Korea:::
제목검색
5.10.4.4. 테이블 최적화

5. 데이터 베이스 관리 To 열을 삭제하거나 업데이트를 하면서 생기는 소비 공간을 없애고 조각나 있는 열을 합치기 위해서는, myisamchk를 복구
5.10. 백업 및 복구 모드로 실행한다:

shell> myisamchk -r tbl_name
여러분은 OPTIMIZE TABLE SQL 명령문을 사용해서 동일한 방식으로 테이블을 최적화 시킬 수가 있다. OPTIMIZE
TABLE은 테이블을 치료하고 키 분석을 하며, 또한 키의 빠른 검색을 위해 인덱스 트리를 정렬해 준다. Section 13.5.2.5,
5.10.4.4 테이블 최적화
“OPTIMIZE TABLE 신텍스”를 참조.
5.10.4.6 테이블 관리(Maintenance) 스케줄 설정 Myisamchk에는 테이블의 성능을 개선하는데 사용할 수 있는 여러 가지의 옵션이 있다:
● --analyze, -a
● --sort-index, -S
● --sort-records=index_num, -R index_num
모든 사용 가능한 옵션을 보기 위해서는 Section 8.2, “myisamchk — MyISAM 테이블-관리 유틸리티”를 참조할 것.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.10.4.5. 테이블 정보 가져오기

테이블에 대한 설명이나 통계 자료를 얻기 위해서는, 여기에 있는 명령어들을 사용한다. 나중에 보다 상세
5. 데이터 베이스 관리 한 설명을 하기로 한다.
5.10. 백업 및 복구
5.10.4 테이블 관리와 크래시(Crash) 복구 ● myisamchk -d tbl_name

myisamchk를 “describe mode”상태로 구동 시켜서 테이블에 대한 설명을 표시하도록 한다. 만약에
기
MySQL 서버가 외부 잠금이 비활성화된 상태로 시작되었다면, myisamchk이 실행되는 동안 업데이트
5.10.4.2 에러에 대해 MyISAM 테이블을 검사하
가 된 테이블에 대해서는 에러를 보고한다. 하지만, myisamchk은 설명 모드(describe mode)에 있는 테
는 방법
이블을 변경 시키지 않기 때문에, 데이터가 손상될 염려는 없다.
5.10.4.4 테이블 최적화 ● myisamchk -d -v tbl_name
5.10.4.6 테이블 관리(Maintenance) 스케줄 설정 myisamchk에 –v를 추가 해서 “verbose mode”로 구동 시켜서 보다 많은 정보를 보이게 끔 만든다.
● myisamchk -eis tbl_name
테이블에서 가장 중요한 정보만을 보이도록 한다. 이것은 테이블 전체를 읽어야만 하기 때문에 속도가 느
리게 된다.
● myisamchk -eiv tbl_name
이것은 –eis와 비슷하지만, 이제 막 마친 동작을 보이게 된다.

위에 있는 명령어들의 샘플 결과가 아래에 있다. 이 명령어들은 아래와 같은 데이터와 인덱스 파일 크기
를 가지고 있다고 가정을 한다:
-rw-rw-r-- 1 monty tcx 317235748 Jan 12 17:30 company.MYD

:::MySQL Korea:::
-rw-rw-r-- 1 davida tcx 96482304 Jan 12 18:35 company.MYI
myisamchk -d 결과 샘플:
MyISAM file: company.MYI
Record format: Fixed length
Data records: 1403698 Deleted blocks: 0
Recordlength: 226
table description:
Key Start Len Index Type
1 2 8 unique double
2 15 10 multip. text packed stripped
3 219 8 multip. double
4 63 10 multip. text packed stripped
5 167 2 multip. unsigned short
6 177 4 multip. unsigned long
7 155 4 multip. text

:::MySQL Korea:::
193 1 text
myisamchk -d -v 결과 샘플:
MyISAM file: company
File-version: 1
Creation time: 1999-10-30 12:12:51
Recover time: 1999-10-31 19:13:01
Status: checked
Datafile parts: 1403698 Deleted data: 0
Datafile pointer (bytes): 3 Keyfile pointer (bytes): 3
Max datafile length: 3791650815 Max keyfile length: 4294967294
Recordlength: 226
table description:
Key Start Len Index Type Rec/key Root Blocksize

:::MySQL Korea:::
1 2 8 unique double 1 15845376 1024
2 15 10 multip. text packed stripped 2 25062400 1024
3 219 8 multip. double 73 40907776 1024
4 63 10 multip. text packed stripped 5 48097280 1024
5 167 2 multip. unsigned short 4840 55200768 1024
6 177 4 multip. unsigned long 1346 65145856 1024
7 155 4 multip. text 4995 75090944 1024
193 1 text
myisamchk -eis 결과 샘플:
Checking MyISAM file: company
Key: 1: Keyblocks used: 97% Packed: 0% Max levels: 4

:::MySQL Korea:::
Total: Keyblocks used: 98% Packed: 17%
Records: 1403698 M.recordlength: 226
Packed: 0%
Recordspace used: 100% Empty space: 0%
Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1626.51, System time 232.36
Maximum resident set size 0, Integral resident set size 0
Non physical pagefaults 0, Physical pagefaults 627, Swaps 0

:::MySQL Korea:::
Blocks in 0 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 639, Involuntary context switches 28966
myisamchk -eiv 결과 샘플:
Checking MyISAM file: company
- check file-size
- check delete-chain
block_size 1024:
index 1:
index 2:
index 3:
index 4:
index 5:
index 6:
index 7:
index 8:

:::MySQL Korea:::
index 9:
No recordlinks
- check index reference
- check data record references index: 1

:::MySQL Korea:::
Total: Keyblocks used: 9% Packed: 17%
- check records and index references
*** LOTS OF ROW NUMBERS DELETED ***
Records: 1403698 M.recordlength: 226 Packed: 0%
Recordspace used: 100% Empty space: 0% Blocks/Record: 1.00
Record blocks: 1403698 Delete blocks: 0
Recorddata: 317235748 Deleted data: 0
Lost space: 0 Linkdata: 0
User time 1639.63, System time 251.61
Maximum resident set size 0, Integral resident set size 0

:::MySQL Korea:::
Non physical pagefaults 0, Physical pagefaults 10580, Swaps 0
Blocks in 4 out 0, Messages in 0 out 0, Signals 0
Voluntary context switches 10604, Involuntary context switches 122798
myisamchk가 만들어 내는 정보 타입에 대한 설명이 아래에 있다. “Keyfile”은 인덱스 파일을 참조한
다. “Record” 와 “row”는 동의어다.
● MyISAM file
MyISAM (index) 파일의 이름.
● File-version
MyISAM 포맷의 버전. 현재는 항상 2.
● Creation time
데이터 파일이 생성된 시점.
● Recover time
인덱스/데이터 파일이 마지막으로 재 구성된 시점.
● Data records
테이블에 있는 열의 수.
● Deleted blocks
삭제된 블록이 여전히 점유하고 있는 공간의 크기. 이 공간을 최소로 만들어서 테이블을 최적화 시킨다.
Section 5.10.4.4, “테이블 최적화”참조.

:::MySQL Korea:::
● Datafile parts
동적-열 포맷의 경우, 이것은 데이터 블록이 얼마나 있는지를 가리킨다. 조각나 있는 열이 없는 최적화
된 테이블의 경우, 이것은 Data records과 같게 된다.
● Deleted data
삭제된 후에 다시 복구되지 않은 데이터의 크기(바이트). 이 공간을 최소로 해서 테이블을 최적화 시켜

야 한다. Section 5.10.4.4, “테이블 최적화”를 참조.
● Datafile pointer
데이터 파일 포인터의 크기(바이트). 보통은 2, 3, 4, 또는 5 바이트가 된다. 대부분의 테이블은 2 바이트

를 가지고 관리 하지만, 아직은 MySQL에 의해 제어되지는 않는다. 고정 테이블의 경우, 이것은 열의 주
소가 된다. 동적 테이블의 경우, 이것은 바이트 주소가 된다.
● Keyfile pointer
인덱스 파일 포인터의 크기(바이트). 보통은 1, 2, 또는 3 바이트가 된다. 대부분의 테이블은2바이트를

가지고 관리 하지만, 이것은 MySQL이 자동으로 계산을 한다. 이것은 항상 블록 주소가 된다.
● Max datafile length
테이블 데이터 파일의 최대 길이(바이트).
● Max keyfile length
테이블 인덱스 파일의 최대 길이(바이트).
● Recordlength
각 열이 차지하고 있는 공간의 길이(바이트).

:::MySQL Korea:::
● Record format
테이블 열을 저장하는데 사용되는 포맷. 앞의 예제에서는 Fixed length를 사용했다. 다른 사용 가능한 값

으로는 Compressed 와 Packed이 있다.
● table description
테이블에 있는 모든 키의 리스트. 각 키에 대해서, myisamchk는 다소 하위-레벨의 정보를 보여준다:
❍ Key
이 키의 번호.
❍ Start
열에서 인덱스의 이 부분이 시작하는 곳.
❍ Len
인덱스의 이 부분의 길이. 팩(packed) 숫자일 경우, 이것은 항상 컬럼의 전체 길이가 된다. 스트링의 경
우, 이것은 인덱스된 컬럼의 전체 길이보다는 작게 된다. 그 이유는 스트링 컬럼의 접두사를 인덱스 하기
때문이다.
❍ Index
키 값이 인덱스에 여러 번 존재할 수 있는지를 검사. 사용 가능한 값은 unique 또는 multip이다.
❍ Type
인덱스의 이 부분이 가지는 데이터 타입. 이것은 가능한 값으로 packed, stripped, 또는 empty를 가지
고 있는 MyISAM 데이터 타입이 된다.
❍ Root

:::MySQL Korea:::
루트 인덱스 블록의 주소.
❍ Blocksize
각 인덱스 블록의 크기. 디폴트로는 1024이지만, 소스를 가지고 MySQL을 구성할 때에는 컴파일시에
그 값이 변할 수도 있다.
❍ Rec/key
이것은 옵티마이저가 사용하는 통계 값이다. 이것은 이 인덱스에 대한 값 별로 얼마나 많은 열이 있는지

를 알려준다. 고유의 인덱스는 항상 그 값이 1이다. 테이블이 myisamchk –a를 가지고 로드된 후에는 변
경될 수 있다. 이것이 전혀 업데이트가 되지 않았다면, 디폴트 값은 30으로 주어진다.
이 예제에서 보여진 테이블의 경우, 9번째 인덱스에 대해 두 개의 table description 라인이 있다. 이것
은 두 개의 부분을 가지고 있는 다중-파트 인덱스라는 것을 알려 주는 것이다.
● Keyblocks used
keyblocks의 몇 퍼센트가 사용되었는지 나타낸다. 테이블이 myisamchk를 사용해서 이제 막 재 구성되

었을 경우, 그 값은 매우 높게 된다(이론적인 최대 값에 거의 근접).
● Packed
MySQL이 공통의 접미사를 가지고 있는 키 값들을 팩(pack)하려고 한다. 이것은 CHAR 와 VARCHAR
컬럼에 있는 인덱스에 대해서만 사용된다. 가장 왼쪽으로 치우쳐 있는 스트링을 인덱스 한 경우, 이것은
사용 공간을 현격하게 줄여 준다. 앞의 예제 중에 세 번째의 경우, 네 번째 키는 10개 문자 길이로 되어 있
고 사용 공간의 60%를 줄여 주고 있다.
● Max levels
이 키에 대한 B-트리의 깊이. 기다란 키 값을 가지고 있는 대형 테이블은 높은 값을 가진다.
● Records

:::MySQL Korea:::
테이블에 있는 열의 수.
● M.recordlength
평균 열 길이. 이것은 고정-길이 열을 가지고 있는 테이블에 대해서는 정확한 열 길이가 되는데, 그 이유

는 모든 열이 동일한 길이를 가지고 있기 때문이다.
● Packed
MySQL이 스트링의 끝에서 공간을 삭제한다. 팩이 된 값은 이것의 실행에 의해 얻게 된 절약공간의 퍼센

트를 가리킨다.
● Recordspace used
사용된 데이터 파일의 퍼센트.
● Empty space
사용되지 않은 데이터 파일의 퍼센트.
● Blocks/Record
열 당 블록의 평균 숫자 (즉, 조각난 열을 구성하고 있는 링크의 숫자). 이것은 고정-포맷 테이블에 대해

서는 항상 1.0이 된다. 이 값은 가능한 한 1.0에 가깝게 되어 있어야 한다. 만약에 이 값이 너무 크게 되
면, 여러분은 테이블을 재 구성해야 한다. Section 5.10.4.4, “테이블 최적화”를 참조할 것.
● Recordblocks
사용된 블럭(링크)의 숫자. 고정-포맷 테이블의 경우, 열의 숫자와 동일하게 된다.
● Deleteblocks
삭제된 블록(링크)의 숫자.

:::MySQL Korea:::
● Recorddata
데이터 파일에서 사용된 바이트.
● Deleted data
데이터 파일에서 삭제된(사용하지 않은) 바이트.
● Lost space
만약에 열이 보다 짧게 업데이트가 되었다면, 공간의 일부가 손실한 것이다. 이것은 모든 손실 공간의 합

이며, 바이트로 표시된다.
● Linkdata
동적 테이블 포맷이 사용될 때, 열 조각들은 포인터를 가지고 링크된다(4에서 7 바이트). Linkdata는 이

러한 모든 포인터가 사용하는 스토리지의 총 합이 된다.
테이블이 myisampack–d, myisamchk 로 압축 되어졌다면, 각 테이블 컬럼에 대한 추가 정보를 알려주
게 된다. Section 8.4, “myisampack— 압축된, 읽기 전용 MyISAM 테이블 만들기”를 참조.

:::MySQL Korea:::
제목검색
5.10.4.6. 테이블 관리(Maintenance) 스케줄 설정

5. 데이터 베이스 관리 테이블 검사는 문제가 발생한 다음에 하는 것 보다 정상적인 상태에서 실행하는 것이 바람직하다. MyISAM 테이블을 검사하고 치
5.10. 백업 및 복구 료하는 한 가지 방법은 CHECK TABLE 과 REPAIR TABLE 명령문을 사용하는 것이다. Section 13.5.2.3, “CHECK TABLE
5.10.4 테이블 관리와 크래시(Crash) 복구 신텍스”, 그리고 Section 13.5.2.6, “REPAIR TABLE 신텍스”를 참조.

기 테이블 검사의 또 다른 방법으로는 myisamchk를 사용하는 것이다. 관리 목적인 경우, myisamchk –s를 사용한다. -s 옵션은
5.10.4.2 에러에 대해 MyISAM 테이블을 검사하 (--silent) myisamchk을 침묵 모드(silent mode)로 동작 시키며, 에러가 발생했을 때에만 메시지를 출력한다.
는 방법
자동으로 MyISAM 테이블 검사를 실행하도록 하는 것도 좋은 생각이다. 예를 들면, 시스템이 업데이트 도중에 재 시작을 할 때마
다, 일반적으로는 각 테이블을 검사해야 한다. MyISAM 테이블을 자동으로 검사하도록 하기 위해서는, --myisam-recover 옵
5.10.4.4 테이블 최적화
션을 가지고 서버를 구동한다. Section 5.2.1, “mysqld 명령어 옵션”을 참조할 것.
여러분은 서버의 정상적인 동작 중에도 주기적으로 테이블을 검사 해야 한다. MySQL AB의 경우, 우리는 cron 잡(job)을 돌려서
우리의 모든 중요 테이블을 일주일에 한번씩 검사하도록 하고 있다. crontab 파일에 아래와 같은 링크를 사용한다:
35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI
이것은 크래시된 테이블에 대한 정보를 출력하며, 필요할 경우 우리는 그러한 테이블을 검사하고 치료할 수가 있다.
우리는 여러분이 지난 24시간 동안 업데이트가 된 모든 파일에 대해서, 매일 밤마다 myisamchk -s 를 사용해서 검사하기를 권장
한다.
일반적으로는, MySQL 테이블은 거의 유지 관리가 필요 없다. 만약에 여러분이 동적 크기의 열을 가지고 있는 MyISAM 테이블에
많은 업데이트를 하거나 (VARCHAR, BLOB, 또는TEXT 컬럼을 가지고 있는 테이블) 또는 많은 열을 삭제한 테이블을 가지고 있
다면, 테이블의 공간을 계속해서 최적화 시킬 필요가 있다. 여러분은 의심이 가는 테이블에 OPTIMIZE TABLE을 가지고 최적화
를 할 수가 있다. 다른 방법으로는, mysqld 서버를 당분간 종료해 놓을 수 있다면, 데이터 디렉토리로 이동을 해서 서버가 멈추어

:::MySQL Korea:::
있는 동안 아래의 명령어를 실행하도록 한다:
shell> myisamchk -r -s --sort-index --sort_buffer_size=16M */*.MYI

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11. MySQL 지역화(Localization)와 국제적인 사용

5.11.1. 데이터와 정렬을 위한 문자 셋
5. 데이터 베이스 관리 5.11.2. 에러 메시지 언어 설정
5.11. MySQL 지역화(Localization)와 국제적인 사용 5.11.3. 새로운 문자 셋 추가
5.11 MySQL 지역화(Localization)와 국제적인 사용 5.11.4. 문자 정의 배열
5.11.1 데이터와 정렬을 위한 문자 셋 5.11.5. 스트링 콜레팅(collating)지원
5.11.2 에러 메시지 언어 설정 5.11.6. 다중-바이트 문자 지원
5.11.3 새로운 문자 셋 추가 5.11.7. 문자 셋 문제

5.11.8. MySQL 서버 타임존 지원
이 섹션은 다른 문자 셋을 서버가 사용할 수 있도록 구성하는 방법을 설명한다. 또한, 서버의 타임 존 설정 방법과 접속 별
타임 존 지원 활성화 방법에 대해서도 함께 설명을 한다.
5.11.7 문자 셋 문제
5.11.8 MySQL 서버 타임존 지원
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.1. 데이터와 정렬을 위한 문자 셋
5. 데이터 베이스 관리 디폴트로는, MySQL 은 latin1 (cp1252 서유럽) 문자 셋과 latin1_swedish_ci 콜레션(collation)을 사용하고 있다. 이 디폴트 값
5.11. MySQL 지역화(Localization)와 국제적 은 대부분의 서유럽과 미국 사용자들이 사용할 수 있는 문자 셋이다.
인 사용
5.11.1 데이터와 정렬을 위한 문자 셋 모든 MySQL 바이너리 배포판은 --with-extra-charsets=complex를 사용해서 컴파일 되어 있다. 이것은 모든 표준 배포판에
코드를 추가해서 배포판이 latin1과 바이너리에 포함되어 있는 모든 다중-바이트 문자 셋을 처리할 수 있도록 해준다. 다른 문자
셋은 필요할 경우에 문자-셋 정의문에서 로드할 수가 있다.
문자 셋은 구분자(identifier)에서 사용할 수 있는 문자가 어떤 것인지를 판단한다. 콜레션(collation)은 SELECT 명령문의

ORDER BY 와 GROUP BY 구문이 스트링을 어떻게 정렬하는지를 결정한다.
여러분은 서버가 시작될 때 서버의 디폴트 문자 셋과 콜레션을 --character-set-server 와 --collation-server 옵션을 사용

해서 변경 시킬 수가 있다. 콜레션은 반드시 디폴트 문자 셋에 대해 리걸 콜레션이 되어야 한다. (SHOW COLLATION 명령문을
사용해서 각 문자 셋에서 사용할 수 있는 콜레션이 무엇인지를 알아본다.) Section 5.2.1, “mysqld 명령어 옵션”을 참조할 것.
사용 가능한 문자 셋은 configure에 대한 --with-charset=charset_name 과 --with-extra-charsets=list-of-charsets

| complex | all | none 옵션과 SHAREDIR/charsets/Index에 있는 문자 셋 구성 파일에 달려 있다. Section 2.8.2, “전형적인
configure 옵션”을 참조.
MySQL이 동작하고 있는 도중에 문자 셋을 변경 하고자 한다면, 정렬 순서도 함께 바꾸어야 한다. 결론적으로, 여러분은 반드시 모
든 테이블에 있는 myisamchk -r -q --set-collation=collation_name 를 구동 시켜야 하는데, 그렇지 않으면 올바르게 순서
가 지켜지지 않을 수도 있다.
클라이언트가 MySQL 서버에 접속을 할 때, 서버는 클라이언트에게 자신의 디폴트 문자 셋이 어떤 것인지를 알려 준다. 클라이언
트는 이 접속에 대해 서버가 알려주는 문자 셋으로 변환을 한다.

:::MySQL Korea:::
SQL 쿼리에 대한 스트링을 빠져 나올 때에는 mysql_real_escape_string()를 사용해야 한다. mysql_real_escape_string()는 이

전의 mysql_escape_string() 함수와 동일한 것이지만, 이것은 처음의 MYSQL 접속 핸들을 처음의 파라미터로 가져와서 문자에
서 빠져 나올 때 적절한 문자 셋이 계정 안으로 들어갈 수 있도록 해주는 차이가 있다..
만약에 클라이언트가 서버가 설치된 것과는 다른 경로를 가지고 컴파일 되었고 MySQL 서버를 구성한 사용자가 MySQL 바이너리
에 있는 모든 문자 셋을 포함 시키지 않았다면, 여러분은 서버가 클라이언트와 다른 문자 셋을 사용할 경우에 클라이언트가 찾아야
하는 추가 문자 셋이 어디에 있는지를 반드시 클라이언트에게 알려 주어야 한다.
여러분은 이것을 동적 MySQL 문자 셋이 저장되어 있는 디렉토리 경로를 가리켜 주는 --character-sets-dir 옵션 지정을 통해

구현 할 수가 있다. 예를 들면, 아래의 내용을 옵션 파일에 넣을 수가 있다:
[client]
character-sets-dir=/usr/local/mysql/share/mysql/charsets
여러분은 클라이언트가 아래와 같은 문자 셋을 사용하도록 만들 수가 있다:
[client]
default-character-set=charset_name
하지만, 이것은 일반적으로는 불필요한 행동이 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.2. 에러 메시지 언어 설정
5. 데이터 베이스 관리 디폴트로, mysqld는 에러 메시지를 영어로 보여 주지만, 여러분은 이 메시지를 다른 언어로 나타나도록 할 수가 있다: Czech,
5.11. MySQL 지역화(Localization)와 국제적 Danish, Dutch, Estonian, French, German, Greek, Hungarian, Italian, Japanese, Korean, Norwegian, Norwegian-ny,
인 사용 Polish, Portuguese, Romanian, Russian, Slovak, Spanish, 또는 Swedish.
5.11.2 에러 메시지 언어 설정
특정 언어를 사용해서 에러 메시지를 보여 주도록 mysqld을 시작하기 위해서는, --language 또는 -L 옵션을 사용한다. 이 옵션
값은 언어 이름 또는 에러 메시지 파일의 경로가 될 수 있다. 예를 들면:
shell> mysqld --language=swedish
또는:
shell> mysqld --language=/usr/local/share/swedish
언어 이름은 소문자로 지정되어야 한다.
디폴트로는, 언어 파일은 MySQL의 베이스 디렉토리 밑에 있는 share/LANGUAGE 디렉토리에 있다.
여러분은 서버가 만들어 내는 에러 메시지의 내용도 변경할 수가 있다. http://dev.mysql.com/doc/를 참조할 것. 만약에 에러 메시
지를 변경한 후에 MySQL을 새로운 버전으로 업그레이드 한다면, 에러 메시지 변경 작업을 다시 하도록 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.3. 새로운 문자 셋 추가
5. 데이터 베이스 관리 이 섹션은 MySQL에 새로운 문자 셋을 추가하는 과정에 대해 설명은 하고 있다. 이 과정을 진행하기 위해서는 반드시 MySQL 소
5.11. MySQL 지역화(Localization)와 국제적 스 배포판을 사용해야 한다. 올바른 과정을 선택하기 위해서는, 문자 셋이 단순한 것인지 아니면 복잡한 것인지를 알아야 한다:
인 사용
5.11.3 새로운 문자 셋 추가 ● 만약에 문자 셋이 특수 스트링 콜레션 루틴을 사용해서 정렬을 하지 않고 다중-바이트 문자 지원이 필요 없는 것이라면,
이 문자 셋은 단순한 것이다.
● 만약에 위의 특성 중에 하나라도 필요하게 되면, 복잡한 문자 셋이다.
예를 들면, latin1 과 danish는 단순 문자 셋이며, 반면에 big5 와 czech는 복잡한 문자 셋이다.
아래의 지침에서 보면, 문자 셋의 이름은 MYSET로 표현 되어 있다.
단순 문자 셋의 경우, 아래의 과정을 진행한다:
1. MYSET 을 sql/share/charsets/Index 파일의 끝에 추가한다. 이 파일에 고유의 번호를 부여한다.

2. sql/share/charsets/MYSET.conf를 생성한다. (이 파일은 sql/share/charsets/latin1.conf의 복사본을 사용해서
만들 수 있다.)
파일에 대한 신텍스는 매우 간단하다:
• ‘#’ 문자를 사용해서 코멘트를 입력한다.
• 단어는 화이트 스페이스를 사용해서 구분한다.
• 문자 셋을 정의할 때, 모든 단어는 반드시 16진수 포맷의 숫자로 되어야 한다.
• ctype 배열은 처음의 257 단어를 가져온다. to_lower[], to_upper[] 그리고 sort_order[] 배열은 그 다음
의 256 단어를 각각 취한다.
Section 5.11.4, “문자 정의 배열”을 참조.
3. 문자 셋 이름을 configure.in에 있는 CHARSETS_AVAILABLE 과 COMPILED_CHARSETS 리스트에 추가한다.
4. 재 구성하고, 재 컴파일 하고, 테스트를 한다.

:::MySQL Korea:::
복잡 문자 셋의 경우, 아래의 과정을 진행한다:
1. MySQL 배포판에 있는 strings/ctype-MYSET.c 파일을 생성한다.

2. MYSET 을 sql/share/charsets/Index 파일 끝에 추가한다. 여기에 고유 번호를 부여한다.
3. 무엇을 정의해야 하는지 알기 위해 ctype-*.c 파일을 살펴 본다 (strings/ctype-big5.c와 같은 파일). 여러분의 파
일에 있는 배열은 ctype_MYSET, to_lower_MYSET와 같은 이름을 가져야 한다는 것을 명심한다. Section 5.11.4, “문
자 정의 배열”를 참조.
4. 파일의 맨 위 근처에, 아래와 같은 코멘트를 집어 넣는다:
5. /*
6. * This comment is parsed by configure to create ctype.c,
7. * so don't change it unless you know what you are doing.
8. *
9. * .configure. number_MYSET=MYNUMBER
10. * .configure. strxfrm_multiply_MYSET=N
11. * .configure. mbmaxlen_MYSET=N
12. */
configure 프로그램은 이 코멘트를 사용해서 문자 셋을 MySQL 라이브러리에 자동으로 집어 넣는다.

strxfrm_multiply 와 mbmaxlen 라인은 다음 섹션에서 설명하기로 한다. 이것들은 여러분이콜레션 함수가 필요하거나 또
는 다중-바이트 문자 셋 함수가 필요할 경우에만 개별적으로 포함 시킬 필요가 있다.
13. 그런 다음에는, 아래의 함수들을 생성한다:
• my_strncoll_MYSET()
• my_strcoll_MYSET()

:::MySQL Korea:::
• my_strxfrm_MYSET()
• my_like_range_MYSET()
Section 5.11.5, “스트링 콜레팅(collating)지원”을 참조.
14. 문자 셋 이름을 configure.in에 있는CHARSETS_AVAILABLE 과 COMPILED_CHARSETS 리스트에 추가한다.
15. 재 구성하고, 재 컴파일하고, 테스트를 한다.
sql/share/charsets/README 파일은 추가적인 과정을 포함하고 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.4. 문자 정의 배열
5. 데이터 베이스 관리 to_lower[] 와 to_upper[]은 각 문자 셋의 각 멤버에 대응하는 소문자와 대문자를 가지고 있는 단순 배열이다. 예를 들면:
5.11. MySQL 지역화(Localization)와 국제적인
사용 to_lower['A'] should contain 'a'
to_upper['a'] should contain 'A'
sort_order[]은 문자가 비교와 정렬을 위해 어떤 순서로 되어 있는지를 가리키는 맵(map)이다. 매우 흔히 (하지만 모든 문자

에 해당하지는 않음) 이것은 to_upper[]과 동일하게 취급 되는데, to_upper[] 는 대소 문자 구분 없는 정렬을 의미한다.
MySQL은 sort_order[] 요소 값을 근거로 문자를 정렬한다. 좀더 복잡한 정렬 규칙에 대해서는, Section 5.11.5, “스트링 콜
레팅(collating)지원”를 참조할 것.
ctype[]는 비트 값 배열로서, 하나의 문자에 하나의 요소를 가지고 있다. ( to_lower[], to_upper[], 그리고 sort_order[]는
문자 값으로 인덱스 되어 있으나, ctype[]는 문자 값 + 1로 인덱스 되어 있다. 이것은 EOF를 다루기 위한 구형 레가시 방식이
다)
여러분은 m_ctype.h에서 아래와 같은 비트마스크(bitmask)를 볼 수가 있다:
#define _U 01 /* Uppercase */
#define _L 02 /* Lowercase */
#define _N 04 /* Numeral (digit) */
#define _S 010 /* Spacing character */

:::MySQL Korea:::
#define _P 020 /* Punctuation */
#define _C 040 /* Control character */
#define _B 0100 /* Blank */
#define _X 0200 /* heXadecimal digit */
각 문자에 대한 ctype[] 엔트리는 문자를 설명하는 적용 가능한 비트 마스크 값의 합집합(union)이 되어야 한다. 예를 들면,
'A'는 대문자일 뿐만 아니라(_U) 16진수 숫자이기도 한데(_X), 따라서 ctype['A'+1]는 다음의 값을 가지게 된다:
_U + _X = 01 + 0200 = 0201

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.5. 스트링 콜레팅(collating)지원
5. 데이터 베이스 관리 만약에 여러분이 사용하는 언어에 대한 정렬 규칙이 너무 복잡해서 단순 sort_order[] 테이블을 가지고서는 처리할 수가
5.11. MySQL 지역화(Localization)와 국제적인 사용 없다면, 스트링 콜레션 함수를 사용할 필요가 있다.

이에 대한 가장 좋은 설명서는 현존하는 문자 셋이 된다. big5, czech, gbk, sjis, 그리고 tis160 문자 셋을 참고 삼아 살펴
본다.
여러분은 파일의 맨 위의 특별 코멘트에 있는 strxfrm_multiply_MYSET=N 값을 지정해야 한다. N 은

my_strxfrm_MYSET 을 실행하는 동안 스트링이 커질 수 있는 최대 비율로 설정한다(이것은 양수이어야 한다).
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.6. 다중-바이트 문자 지원
5. 데이터 베이스 관리 만약에 다중-바이트 문자를 포함하는 새로운 문자 셋 지원을 추가 하고자 한다면, 다중-바이트 문자 함수를 사용할 필요
5.11. MySQL 지역화(Localization)와 국제적인 사용 가 있다.
이에 대한 가장 좋은 설명서는 현존하는 문자 셋이 된다. euc_kr, gb2312, gbk, sjis, 그리고 ujis 문자 셋을 살펴 본다. 이
것들은 strings 디렉토리에 있는 ctype-charset_name.c 파일에서 구현되었다.
여러분은 파일의 맨 위의 특별 코멘트에 있는 mbmaxlen_MYSET=N 값을 지정해야 한다.
N 은 문자 셋에 있는 것 중에 가장 큰 문자의 크기를 바이트 단위로 설정해야 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.7. 문자 셋 문제
5. 데이터 베이스 관리 여러분이 사용하는 바이너리 배포판에 컴파일 되어 있지 않은 문자 셋을 사용하고자 한다면, 아래의 문제를 만날 수도 있다:
5.11. MySQL 지역화(Localization)와 국제적
인 사용 ● 여러분이 사용하는 프로그램은 문자 셋이 저장되어 있는 곳을 알아 내기 위한 경로를 잘못 사용하게 된다. (디폴트는 /usr/
5.11.7 문자 셋 문제 local/mysql/share/mysql/charsets). 이 문제는 의심스러운 프로그램을 구동 시킬 때 --character-sets-dir 옵션을

사용해서 수정할 수가 있다.
● 문자 셋은 동적으로 로딩할 수 없는 다중-바이트 문자 셋이다. 이와 같은 경우, 여러분은 반드시 문자 셋을 지원하도록 프
로그램을 재 컴파일 해야 한다.
● 문자 셋은 동적 문자 셋이지만, 이에 대한 구성 파일을 가지고 있지 않게 된다. 이와 같은 경우, 새로운 MySQL 배포판을 가
지고 그 문자 셋에 대한 구성 파일을 설치해야 한다.
● 만약에 Index 파일이 문자 셋에 대한 이름을 가지고 있지 않다면, 여러분의 프로그램은 아래와 같은 에러를 디스플레이 한
다:
• ERROR 1105: File '/usr/local/share/mysql/charsets/?.conf'
• not found (Errcode: 2)
이와 같은 경우, 여러분은 새로운 Index 파일을 가져오거나 또는 수동으로 누락된 문자 셋 이름을 현재 파일에 추가해야
한다.
MyISAM 테이블의 경우, myisamchk -dvv tbl_name을 사용해서 테이블 번호와 문자 셋을 검사할 수가 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.11.8. MySQL 서버 타임존 지원
5. 데이터 베이스 관리 MySQL 서버는 여러 가지 타임 존에 대한 설정 방법을 가지고 있다:

5.11. MySQL 지역화(Localization)와 국제적
인 사용 ● 시스템 타임 존. 서버가 시작될 때에, 서버는 호스트 머신의 타임 존을 알아 내려고 시도하며 그것을 사용해서
5.11.8 MySQL 서버 타임존 지원 system_time_zone 시스템 변수를 설정한다. 이 값은 설정 후에는 변경되지 않게 된다.
● 서버의 현재 타임 존. 글로벌 time_zone 시스템 변수는 서버가 현재 동작하면서 사용하고 있는 타임 존을 나타낸다.
time_zone의 초기 값은 'SYSTEM'이며, 이것은 서버의 타임 존이 시스템 타임 존과 동일하다는 것을 나타낸다. 초기 값은
--default-time-zone=timezone 옵션을 사용해서 확정적으로 지정할 수가 있다. 여러분이 SUPER 권한을 가지고 있다
면, 아래의 명령문을 사용해서 런타임 시에 글로벌 값을 설정할 수가 있다:
• mysql> SET GLOBAL time_zone = timezone;
● 접속 별 타임 존. 접속하는 각 클라이언트는 자신만의 타임 존 설정을 가지고 있는데, 이것은 세션 time_zone 변수에 의해

주어진다. 초기에는, 세션 변수는 그 값을 글로벌 time_zone 변수에서 가져 오지만, 클라이언트는 아래의 명령문을 사용해
서 자신만의 고유 타임 존으로 변경할 수가 있다:
• mysql> SET time_zone = timezone;
글로벌 및 클라이언트-특성 타임 존의 현재 값은 아래와 같이 얻을 수가 있다:
mysql> SELECT @@global.time_zone, @@session.time_zone;
timezone 값은 스트링으로 주어지며 '+10:00' 또는 '-6:00'와 같이 UTC에서 오프셋을 가리키게 된다. 만약에 mysql 데이터 베
이스에 타임 존 정보 테이블을 이미 가지고 있다면, 여러분은 'Europe/Helsinki', 'US/Eastern', 또는 'MET'와 같은 네임드 타임
존도 역시 사용할 수가 있다. 'SYSTEM'은 사용하는 타임 존이 시스템 타임 존과 동일한 것임을 가리킬 때 사용한다. 타임 존 이름
은 대소 문자를 구분하지 않는다.

:::MySQL Korea:::
MySQL 설치 과정은 mysql 데이터 베이스에 타임 존 테이블을 생성하지만, 그것을 로드 하지는 않는다. 여러분은 수동으로 그것
을 로드해야 한다. (만약에 여러분이 이전 버전을 4.1.3 또는 그 이후 버전으로 업그레이드 한다면, 여러분의 mysql 데이터 베이스
를 업그레이드 해서 테이블이 생성되도록 해야 한다. Section 5.6.2, “mysql_upgrade —MySQL 업그레이드에 대한 테이블 검
사”에 있는 방법을 따라 한다.)
만약에 여러분의 시스템이 자체 zoneinfo 데이터 베이스를 가지고 있다면 (타임 존을 설명하는 파일 셋), 타임 존 테이블을 채우기
위해 mysql_tzinfo_to_sql 프로그램을 사용해야 한다. 만약에 여러분의 시스템이 zoneinfo 데이터 베이스를 가지고 있지 않다면,
이 섹션 후반에서 설명하는 다운 로드 패키지를 사용한다.
mysql_tzinfo_to_sql 프로그램은 타임 존 테이블을 로드하기 위해 사용한다. 명령어 라인상에서, zoneinfo 디렉토리의 경로 이름

을 mysql_tzinfo_to_sql에 보내고 그 결과를 mysql 프로그램으로 보낸다. 예를 들면:
shell> mysql_tzinfo_to_sql /usr/share/zoneinfo | mysql -u root mysql
mysql_tzinfo_to_sql은 여러분의 시스템 타임 존을 읽고 거기에서 SQL명령문을 만든다. mysql 은 그 명령문이 타임 존 테이블을

로드 하도록 한다.
mysql_tzinfo_to_sql를 사용해서 단일 타임 존 파일을 로드할 수도 있고, 또한 립 세컨드(leap second) 정보를 만들어 낼 수도 있

다:
● 타임 존 이름 tz_name에 상응하는 단일 타임 존 파일 tz_file를 로드하기 위해서는, mysql_tzinfo_to_sql 을 아래와 같이

호출한다:
• shell> mysql_tzinfo_to_sql tz_file tz_name | mysql -u root mysql
● 만약에 여러분의 타임 존이 립 세컨드를 위한 계정을 필요하게 되면, 립 세컨드 정보를 아래와 같이 초기화 시킨다. 여기에
서 tz_file는 여러분이 사용하는 타임 존 파일의 이름이 된다:
• shell> mysql_tzinfo_to_sql --leap tz_file | mysql -u root mysql
만약에 여러분의 시스템이 zoneinfo 데이터 베이스를 가지고 있지 않다면 (예를 들어, 윈도우 또는 HP-UX), http://dev.mysql.

:::MySQL Korea:::
com/downloads/timezones.html에서 존 테이블을 다운 로드하여 사용한다. 이 패키지는 MyISAM 타임 존 테이블을 위한 .frm, .

MYD, 및 .MYI 파일을 가지고 있다. 이러한 테이블들은 mysql 데이터 베이스의 일 부분이며, 따라서 파일들을 MySQL 서버의 데
이터 디렉토리의 mysql 서브디렉토리에 저장해야 한다. 이것을 수행하는 동안에는 서버를 종료해 두어야 한다.
Warning: 여러분의 시스템이 zoneinfo 데이터 베이스를 가지고 있다면 다운 로드 패키지를 사용하지 말길 바란다. 대신에
mysql_tzinfo_to_sql 유틸리티를 사용한다. 그렇지 않으면, 시스템에서 다른 어플리케이션과 MySQL을 처리할 때 datetime의 차
이가 발생하게 된다.
리플리케이션 설정에서의 타임 존 설정에 관한 정보는 Section 6.7, “리프리케이션 특징과 알려져 있는 문제점들”을 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.12. MySQL 서버 로그

5.12.1. 에러 로그
5. 데이터 베이스 관리 5.12.2. 일반적인 쿼리 로그
5.12. MySQL 서버 로그 5.12.3. 바이너리 로그
5.12 MySQL 서버 로그 5.12.4. 슬로우 쿼리 로그
5.12.1 에러 로그 5.12.5. 서버 로그 관리
5.13.1.2 서비스 형태로 여러 개의 윈도우 서버 시작하기 MySQL은 여러 개의 각기 다른 로그 파일을 가지고 있는데, 이것들은 사용하면 mysqld 내부에서 진행되고 있는 것을 알 수
5.12.2 일반적인 쿼리 로그 있게 된다:
5.12.3 바이너리 로그 로그 타입 로그에 기록하는 정보
5.12.4 슬로우 쿼리 로그 에러 로그 mysqld를 시작, 구동, 또는 종료할 때 나오는 문제점들

5.12.5 서버 로그 관리 일반적인 쿼리 로그 수립된 클라이언트 접속 및 클라이언트에서 받는 명령문
바이너리 로그 데이터를 변경 시키는 모든 명령문 (리플리케이션용으로 사용되는 것 포함)
슬로우 로그 long_query_time 시간보다 오래 실행되는 모든 쿼리 또는 인덱스를 사용하지 않은 쿼리
디폴트로, 모든 로그 파일은 mysqld 데이터 디렉토리에 생성된다. 여러분은 로그를 플러시해서 강제로 mysqld을 닫고 로그
파일을 다시 열 수 있다. 로그 플러싱은 여러분이 FLUSH LOGS 명령문을 입력하거나, 또는 mysqladmin flush-logs 또는
mysqladmin refresh를 실행할 때 발생한다. Section 13.5.5.2, “FLUSH 신텍스”를 참조할 것.
만약에 여러분이 MySQL 리플리케이션을 사용한다면, 슬레이브 리플리케이션 서버는 릴레이 로그 라는 로그 파일을 관리하
게 된다. 이것에 대해서는 Chapter 6, “리플리케이션” 에서 다루기로 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.12.1. 에러 로그
5. 데이터 베이스 관리 에러 로그 파일은 mysqld의 시작 및 종료 시점을 가리키는 정보와 서버의 동작 중에 발생한 치명적인 에러에 대한 정보를 가
5.12. MySQL 서버 로그 지고 있다. 만약에 mysqld가 자동으로 검사 또는 치료해야 할 필요가 있는 테이블을 발견하게 되면, 메시지를 에러 로그에
5.12.1 에러 로그 기록하게 된다.
5.13.1.2 서비스 형태로 여러 개의 윈도우 서버 시작하기

어떤 OS 시스템에서는, 에러 로그는 mysqld가 동작을 멈출 경우에 스택 트레이스(stack trace)를 갖게 된다. 트레이스는
mysqld이 멈춘 곳이 어디인지를 판단하는데 사용된다. Section E.1.4, “Using a Stack Trace”를 참조.
만약에 mysqld가 예상하지 못하게 멈추고 mysqld_safe을 통해 이것을 재 구동해야만 할 경우, mysqld_safe는 restarted
mysqld 메시지를 에러 로그에 기록한다.
여러분은 mysqld이 에러 로그를 저장하는 곳을 --log-error[=file_name] 옵션을 사용해서 지정할 수가 있다. 만약에 아
무런 file_name 값도 주어지지 않는다면, mysqld은 host_name.err라는 이름을 사용해서 데이터 디렉토리에 파일을 기록한
다. 만약에 여러분이 FLUSH LOGS를 실행한다면, 에러 로그는 -old라는 접미사가 붙은 이름으로 바뀌게 되고 mysqld은
새로운 빈 로그 파일을 만든다. (--log-error 옵션이 주어지지 않는다면, 파일 이름 변경은 생기지 않게 된다.)
만약에 여러분이 --log-error를 지정하지 않거나, 또는(윈도우에서) --console 옵션을 사용한다면, 에러는 표준 에러 결
과(output)인 stderr에 기록된다. 일반적으로, 이것은 여러분의 터미널이 된다.
윈도우에서는, 만일 –console이 주어지지 않는다면, 에러 결과가 항상 .err 파일에 기록된다.
:::MySQL Korea:::
제목검색
5.13.1.2. 서비스 형태로 여러 개의 윈도우 서버 시작하기

5. 데이터 베이스 관리 NT-기반 시스템에서, MySQL 서버는 윈도우 서비스 형태로 구동될 수 있다. 단일 MySQL 서비스를 설치, 제어, 그리고 제거하
5.12. MySQL 서버 로그 는 과정은 Section 2.3.11, “윈도우 서비스 형태로 MySQL 시작하기”에서 설명하고 있다.
5.12.1 에러 로그
5.13.1.2 서비스 형태로 여러 개의 윈도우 서버 시
작하기
여러분은 여러 개의 MySQL 서버를 서비스 형태로 설치할 수도 있다. 이와 같은 경우, 여러분은 반드시 각 서버가 별도의 서비스
이름을 사용하도록 해야 하며, 아울러 모든 다른 파라미터도 각 서버에 대해 고유의 값을 가지고 있어야 한다.
아래의 설명에서는, 여러분이 C:￦mysql-4.1.8 과 C:￦mysql-5.0.19에 설치된 서로 다른 버전의 MySQL에서 mysqld-nt 서버

를 구동 시킨다는 가정을 하고 있다.
아래의 원칙은 MySQL 서비스를 --install or --install-manual 옵션을 가지고 설치할 때 적용된다:
● 여러분이 서비스 이름을 지정하지 않으면, 서버는 MySQL의 디폴트 서비스 이름을 사용하며, 표준 옵션 파일에 있는
[mysqld] 그룹에서 옵션을 읽게 된다.
● 만약에 --install 옵션 다음에 서비스 이름을 지정한다면, 서버는 [mysqld] 옵션 그룹을 무시하게 되며, 서비스와 동일한
이름을 가지고 있는 그룹에서 옵션을 대신 읽는다. 서버는 표준 옵션 파일에서 옵션을 읽는다.
● 만약에 서비스 이름 다음에 --defaults-file 옵션을 지정한다면, 서버는 표준 옵션 파일을 무시하게 되며 네임드 파일의
[mysqld] 그룹에서만 옵션을 읽게 된다.
위의 설명을 토대로, 여러분은 다중 서비스를 설정할 수 있는 여러 가지의 방법을 알게 될 것이다. 아래에서는 몇 가지 예를 설명하
고 있다. 이것들을 시도하기 전에, 우선 여러분은 MySQL 서버를 종료하고 이미 존재하는 서비스를 제거하도록 해야 한다.
● Approach 1: 하나의 표준 옵션 파일에 모든 서비스에 대한 옵션들을 지정한다. 이렇게 하기 위해서는, 각 서버 별로 별도

의 서비스 이름을 사용한다 mysqld1이라는 서비스 이름을 사용해서4.1.8 mysqld-nt을 구동 시키고 mysqld2 서비스 이

:::MySQL Korea:::
름을 사용해서는 5.0.19 mysqld-nt를 구동시킨다고 가정을 하자. 이와 같은 경우, 4.1.8을 위해서는 [mysqld1] 그룹을
사용하고, 5.0.19를 위해서는 [mysqld2] 그룹을 사용할 수 있다. 예를 들면, 아래와 같이 C:￦my.cnf를 설정할 수가 있
다:
• # 옵션 for mysqld1 service
• [mysqld1]
• basedir = C:/mysql-4.1.8
• port = 3307
• enable-named-pipe
• socket = mypipe1
• # 옵션 for mysqld2 service
• [mysqld2]
• basedir = C:/mysql-5.0.19
• port = 3308
• enable-named-pipe
• socket = mypipe2
전체 서버경로 이름을 사용해서 윈도우가 각 서비스를 위한 정확한 실행 프로그램을 등록할 수 있도록 하기 위해, 아래와
같이 서비스를 설치한다:

:::MySQL Korea:::
C:￦> C:￦mysql-4.1.8￦bin￦mysqld-nt --install mysqld1
서비스를 시작하기 위해, 서비스 관리자를 사용하거나, 또는 적당한 서비스 이름을 가지고 NET START를 사용한다:
C:￦> NET START mysqld1
C:￦> NET START mysqld2
서비스를 멈추기 위해서는, 서비스 관리자 또는 적당한 이름을 가진 NET STOP을 사용한다:
C:￦> NET STOP mysqld1
C:￦> NET STOP mysqld2
● Approach 2: 개별 파일에 있는 각 서버용 옵션을 지정하고 각 서버가 사용할 파일을 알려 주기 위해 서비스를 설치할 때
에 --defaults-file를 사용한다. 이와 같은 경우, 각 파일은 [mysqld] 그룹을 사용해서 옵션을 리스트 해야 한다.
이 단계에서, 4.1.8 mysqld-nt에 대한 옵션을 지정하기 위해서는, 아래와 같은 모습의 C:￦my-opts1.cnf를 생성한다:
[mysqld]
basedir = C:/mysql-4.1.8
port = 3307
enable-named-pipe
socket = mypipe1
5.0.19 mysqld-nt에 대해서는, C:￦my-opts2.cnf를 아래와 같이 생성한다:

:::MySQL Korea:::
[mysqld]
basedir = C:/mysql-5.0.19
port = 3308
enable-named-pipe
socket = mypipe2
아래와 같이 서비스를 설치한다 (각 명령어를 한 줄에 입력한다):
--defaults-file=C:￦my-opts1.cnf
--defaults-file=C:￦my-opts2.cnf
MySQL 서버를 서비스로 설치할 때 --defaults-file 옵션을 사용하기 위해서는, 반드시 서비스 이름 앞에 옵션을 지정
해야 한다.
서비스를 설치한 다음에는, 위에서 설명한 방식으로 서비스를 시작하고 종료한다.
여러 개의 서비스를 제거하기 위해서는, 각 서버별로 mysqld –remove를 사용하고, 서비스 이름을 지정하고 뒤에 --remove 옵
션을 넣는다. 서비스 이름이 디폴트 (MySQL)라면, 이를 생략할 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.12.2. 일반적인 쿼리 로그
5. 데이터 베이스 관리 일반적인 쿼리 로그는 mysqld이 실행한 것에 대한 일반 기록이다. 서버는 클라이언트가 접속을 하거나 또는 접속을 끊을 때 정보
5.12. MySQL 서버 로그 를 이 로그에 기록하며, 그리고 클라이언트에서 받는 각 SQL 명령문을 로그 한다. 일반적인 쿼리 로그는 클라이언트에서 에러를 의
5.12.2 일반적인 쿼리 로그 심할 경우와 클라이언트가 mysqld에 보내는 것이 무엇인지를 정확히 알고 싶을 때 매우 유용하게 사용된다.
Mysqld는 명령문을 받는 순서대로 쿼리 로그에 기록한다.
일반적인 쿼리 로그를 활성화 시키기 위해서는, mysqld을 --log[=file_name] 또는 -l [file_name] 옵션과 함께 구동 시킨다. 만
약에 아무런 file_name 값도 주어지지 않는다면, 디폴트 이름은 데이터 디렉토리에 있는 host_name.log가 된다.
서버 재 시작과 로그 플러싱은 새로운 일반 쿼리 로그 파일을 만들지는 않는다.(비록 플러싱이 이 로그 파일을 닫고 다시 열기는 하

지만). 유닉스에서는, 아래의 명령어를 사용해서 이 파일을 재 명명하고 새로운 로그 파일을 만들 수 있다.:
shell> mv host_name.log host_name-old.log
shell> mysqladmin flush-logs
shell> cp host_name-old.log backup-directory
shell> rm host_name-old.log
윈도우에서는, 서버가 이 로그 파일을 열어 놓은 상태에서는 이름을 바꿀 수가 없다. 여러분은 서버를 종료 시킨 다음에 이름을 바
꾸어야 하고, 그런 다음에 서버를 재 시작하여 새로운 로그 파일을 만들도록 해야 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.12.3. 바이너리 로그
5. 데이터 베이스 관리 바이너리 로그는 데이터를 업데이트 하거나 또는 나중에 업데이트를 진행하는 모든 명령문을 가지고 있다. 명령문은 데이터 수정
5.12. MySQL 서버 로그 을 나타내는 “이벤트(event)” 형태로 저장된다. 바이너리 로그는 또한 각 명령문이 데이터를 업데이트하는데 얼마의 시간을 소
5.12.3 바이너리 로그 비했는지에 대한 정보도 가지고 있다.
Note: 바이너리 로그는 이전(old)의 업데이트 로그를 대체하는데, 이 로그는 5.0 이후에는 더 이상 사용하지 않는다. 바이너리 로
그는 이전의 업데이트 로그에서 사용했던 모든 정보를 보다 편리한 형태와 트랜젝션에 보다 안정적인 형태로 가지고 있다. 만약에
여러분이 트랜젝션을 사용한다면, 반드시 이전 업데이트 로그가 아닌 바이너리 로그를 사용해서 백업을 진행해야 한다.
바이너리 로그는 데이터를 수정하지 않는 명령문은 가지지 않는다. 만약에 여러분이 모든 명령문을 로그하고 싶다면 (예를 들면, 문
제 쿼리를 구분하기 위해), 일반 쿼리 로그를 사용하기 바란다. Section 5.12.2, “일반 쿼리 로그”를 참조.
바이너리 로그의 주요 목적은 서버가 복원 작업을 하는 동안 가능한 한 전체적으로 데이터 베이스를 업데이트할 수 있도록 하는 것
인데, 왜냐하면 바이너리 로그는 백업이 만들어진 후에 발생한 모든 업데이트를 가지고 있기 때문이다. 바이너리 로그는 또한 마스
터 리플리케이션 서버에서는 슬레이브 서버에 보내져야 하는 명령문의 기록으로 사용되기도 한다. Chapter 6, 리플리케이션 를 참
조할 것.
Running the server with 바이너리 로그가 활성화된 상태로 서버를 구동하면 약 1%정도의 성능 저하가 발생한다. 하지만, 복원
작업과 리플리케이션을 설정할 수 있도록 해주는 바이너리 로그의 장점은 약간의 성능 저하 보다는 더 큰 이익을 준다.
서버가 --log-bin[=base_name] 옵션으로 시작되었을 때, mysqld는 데이터를 업데이트하는 모든 SQL 명령어를 가지고 있는
로그 파일을 작성한다. 만약에 아무런 base_name 값도 주어지지 않는다면, 디폴트 이름은 –bin이 붙어 있는 호스트 머신의 이름
을 사용하게 된다. 만일 베이스 이름을 주어지기는 하지만 절대 경로 이름(absolute pathname) 형태가 아닌 경우에는, 서버는 파
일을 데이터 디렉토리에 작성한다. 여러분이 베이스 이름을 지정할 것을 권장한다; Section A.8.1, “Open Issues in MySQL”에
서 그 이유를 참조하기 바란다.

:::MySQL Korea:::
만약에 로그 이름에 확장자를 주게 되면(예를 들면, --log-bin=base_name.extension), 그 확장자는 무시되고 제거 된다.
Mysqld은 바이너리 로그 베이스 이름에 숫자로 된 확장자를 부여한다. 그 숫자는 서버가 새로운 로그 파일을 생성할 때 마다 증가
를 하게 되는데, 따라서 파일의 생성 순서가 만들어 진다. 서버가 시작되거나 또는 로그를 플러시할 때 마다 서버는 새로운 바이너
리 로그 파일을 생성한다. 서버는 또한 현재의 로그 크기가 max_binlog_size에 근접할 때에도 새로운 바이너리 로그 파일을 만들
기도 한다. 만약에 트랜젝션이 여러 개의 파일로 분리되지 않고 하나로 형성이 되기 때문에 어쩔 수 없이 큰 트랜젝션을 사용해야
할 경우에는 바이너리 로그의 크기가 max_binlog_size 보다 커질 수는 있다.
사용된 바이너리 로그 파일들을 관리하기 위해서, mysqld는 사용된 모든 바이너리 로그 파일의 이름을 가지고 있는 바이너리 로
그 인덱스 파일도 생성을 한다. 이 인덱스 파일은 바이너리 로그 파일과 동일한 베이스 이름을 디폴트로 가지게 되며, 확장자는 '.
index'가 된다. 여러분은 --log-bin-index[=file_name] 옵션을 사용해서 이 인덱스 파일의 이름을 변경할 수가 있다. mysqld
의 동작 중에는 수동으로 이 파일을 수정할 수가 없다; 이렇게 하면 mysqld이 혼동을 하게 된다.
Writes to 바이너리 로그 파일과 바이너리 로그 인덱스 파일에 기록을 하는 것은 MyISAM 테이블에 기록하는 방식과 동일하게 처
리가 된다. Section A.4.3, “How MySQL Handles a Full Disk”를 참조.
여러분은 RESET MASTER 명령문을 사용해서 모든 바이너리 로그 파일을 삭제할 수 있고, 또는 PURGE MASTER LOGS를 사
용해서 이 로그 파일의 일부분만을 삭제할 수도 있다. Section 13.5.5.5, “RESET 신텍스”, 및 Section 13.6.1, “마스터 서버
를 제어하기 위한 SQL 명령문”을 참조할 것.
바이너리 로그 포맷에는 백업에서 복원하는데 영향을 줄 수 있는 몇 가지 제약이 있다. Section 6.7, “리플리케이션 기능과 알려
진 문제점들”을 참조할 것.
스토어드 루틴과 트리거에 대한 바이너리 로깅은 Section 17.4, “스토어드 루틴과 트리거에 대한 바이너리 로깅”을 참조할 것.
여러분은 아래의 옵션을 사용해서 mysqld이 바이너리 로그에 로그 되는 것에 영향을 주도록 만들 수 있다.
만약에 여러분이 리플리케이션을 사용한다면, 여기에서 설명하는 옵션들은 마스터 서버가 자신의 슬레이브에 전달하는 명령문에
영향을 주게 된다. 마스터 서버가 보내주는 명령문을 실행 또는 무시할지를 제어하는 슬레이브 서버를 위한 옵션도 존재한다. 자세
한 사항은 Section 6.8, “리플리케이션 스타트업 옵션”을 참조할 것.

:::MySQL Korea:::
● --binlog-do-db=db_name
디폴트 데이터베이스 db_name (즉, USE가 선택한 데이터 베이스)에 대해 업데이트에 대한 바이너리 로깅을 제한하도록
서버에게 명령. 이름이 정확히 지정되지 않은 모든 다른 데이터 베이스는 무시된다. 이 옵션을 사용할 경우에는, 여러분이
디폴트 데이터 베이스에만 업데이트를 한다는 것을 확인해야 한다.
CREATE DATABASE, ALTER DATABASE, 및 DROP DATABASE 명령문에 대해서는 예외적이다. 서버는 명령문
을 로그 할지 말지를 결정하기 위해 명령문(디폴트 데이터 베이스가 아님)안에 적혀 있는 데이터 베이스를 사용한다.
여러분이 기대한 것과는 다르게 동작하는 예를 보자: 만약에 서버가 binlog-do-db=sales와 함께 구동되고, 여러분이
USE prices; UPDATE sales.january SET amount=amount+1000; 을 실행한다면, 이 명령문은 바이너리 로그에 기
록되지 않는다.
여러 개의 데이터 베이스에 로그 하기 위해서는, 각 데이터 베이스 별로 옵션을 지정하는, 다중옵션을 사용한다.
● --binlog-ignore-db=db_name
디폴트 데이터베이스 db_name (즉, USE가 선택한 데이터 베이스)에 대해 업데이트에 대한 바이너리 로깅을 하지 말도
록 서버에게 명령. 이 옵션을 사용할 경우에는, 여러분이 디폴트 데이터 베이스에만 업데이트를 한다는 것을 확인해야 한
다.
CREATE DATABASE, ALTER DATABASE, 및 DROP DATABASE 명령문에 대해서는 예외적이다. 서버는 명령문
을 로그 할지 말지를 결정하기 위해 명령문(디폴트 데이터 베이스가 아님)안에 적혀 있는 데이터 베이스를 사용한다.
여러분이 기대한 것과는 다르게 동작하는 예를 보자: 만약에 서버가 binlog-do-db=sales와 함께 구동되고, 여러분이
USE prices; UPDATE sales.january SET amount=amount+1000; 을 실행한다면, 이 명령문은 바이너리 로그에 기
록된다.
.
여러 개의 데이터 베이스를 무시하기 위해서는, 각 데이터 베이스 별로 옵션을 지정하는, 다중옵션을 사용한다.
서버는 아래의 규칙에 따라 바이너리 로그에 업데이트를 로그 또는 무시하기 위한 옵션을 평가한다. 앞에서 설명을 하였듯이,
CREATE DATABASE, ALTER DATABASE, 그리고 DROP DATABASE 명령문에 대해서는 예외적이다. 이 명령문들의 경
우, 아래의 규칙에 따라 created, altered, 또는 dropped 동작을 하는 데이터 베이스가 디폴트 데이터 베이스를 대신하게 된다.
1. --binlog-do-db 또는 --binlog-ignore-db 규칙이 있는가?

• No: 바이너리 로그에 명령문을 기록한 후에 마침.
• Yes: 다음 단계로 이동.

:::MySQL Korea:::
2. 몇 가지 규칙이 있다 (--binlog-do-db, --binlog-ignore-db, 또는 양쪽에 대해). 디폴트 데이터 베이스가 있는

가 (USE에 의해 선택된 것이 있는가?)?
• No: 명령문을 기록하지 않고 마침.
• Yes: 다음 단계로 이동.
3. 디폴트 데이터 베이스가 있다. --binlog-do-db 규칙이 있는가?
• Yes: 디폴트 데이터 베이스가 --binlog-do-db 규칙 중에 하나라도 일치(match)가 되는가?
o Yes: 명령문을 기록한 다음에 마침.
o No: 명령문을 기록하지 않고 마침.
• No: 다음 단계로 이동.
4. --binlog-ignore-db 규칙이 있다. 디폴트 데이터 베이스가 --binlog-ignore-db 규칙 중에 일치하는 것이 있는
가?
• Yes: 명령문을 기록하지 말고 마침.
• No: 쿼리를 기록한 다음에 마침.
예를 들면, --binlog-do-db=sales를 가지고만 구동되는 슬레이브는 바이너리 로그 디폴트 데이터 베이스가 sales와 다른 것에
대해서는 어떠한 명령문도 바이너리 로그에 기록을 하지 않는다(달리 말하면, --binlog-do-db 는 때때로 “다른 데이터 베이스
는 무시”의 의미를 가지기도 한다).
리플리케이션을 사용 중에 있다면, 어떠한 슬레이브도 구형(old) 바이너리 로그 파일을 사용하지 않는다고 확신하지 않는 한 그 바
이너리 파일들을 삭제할 수 없다. 예를 들면, 만약에 슬레이브가 3일 이상 동작하지 않았다면, 마스터에서 mysqladmin flush-
logs를 실행하고 3일 이상이 된 모든 로그를 제거한다. 여러분은 수동으로 이 파일들을 삭제할 수 있겠지만, PURGE MASTER
LOGS를 사용하는 것이 더욱 효과적이며, 바이너리 로그 인덱스 파일을 안전하게 업데이트 하는 방법이다. Section 13.6.1, “마스
터 서버 제어를 위한 SQL 명령문”을 참조할 것.
SUPER 권한을 가지고 있는 클라이언트는 SET SQL_LOG_BIN=0 명령문을 사용해서 자신의 명령문에 대한 바이너리 로깅을 비
활성화 시킬 수가 있다. Section 13.5.3, “SET 신텍스”를 참조.
여러분은 mysqlbinlog 유틸리티를 사용해서 바이너리 로그 파일의 내용물을 디스플레이 할 수 있다. 이것은 여러분이 로그에 있
는 명령문을 다시 실행하고자 할 때 유용하게 쓸 수 있다. 예를 들면, 아래와 같이 바이너리 로그에서 MySQL 서버를 업데이트 할
수가 있다:

:::MySQL Korea:::
shell> mysqlbinlog log_file | mysql -h server_name
Section 8.8, “mysqlbinlog — 바이너리 로그 파일 처리를 위한 유틸리티”를 참조하여 mysqlbinlog 유틸리티에 대한 정보와 사
용 방법을 알아두기 바란다. Mysqlbinlog은 또한 릴레이 로그 파일과 함께 사용될 수도 있는데, 왜냐하면 릴레이 로그 파일이 바이
너리 로그 파일과 동일한 포맷으로 작성되어 있기 때문이다.
바이너리 로깅은 명령문이 완료된 후에 하지만 모든 잠금이 풀리거나 모든 동작이 마치기 전에 즉시 종료가 된다. 이것은 로그가 실
행 순서에 따라 로그 되도록 하기 위해서이다.
논-트랜젝션(non-transactional) 테이블에 대한 업데이트는 명령문 실행 후에 즉시 바이너리 로그에 저장된다. 실행되지 않은 트

랜젝션 안에서는, BDB 또는 InnoDB 테이블과 같은 트랜젝션 테이블을 변경하는 모든 업데이트(UPDATE, DELETE, 또는
INSERT)는 COMMIT 명령문을 서버가 받을 때까지 캐시된다. 그 시점에서, mysqld은 COMMIT가 실행되기 전에 전체 트랜젝션
을 바이너리 로그에 기록한다. 트랜젝션을 처리하는 쓰레드가 시작이 될 때, 쓰레드는 binlog_cache_size의 버퍼를 버퍼 명령문에
할당한다. 만약에 명령문이 이것보다 크다면, 쓰레드는 트랜젝션을 저장하기 위해 임시 파일을 연다. 임시 파일은 쓰레드가 종료하
면 삭제된다.
논-트랜젝션 테이블에 대한 수정은 롤백 되지 않는다. 만약에 롤백된 트랜젝션이 논-트랜젝션 테이블에 대한 수정을 포함하고 있
다면, 전체 트렌젝션은 이러한 테이블에 대한 수정이 리플리케이트 되었음을 확신하기 위해 마지막에 ROLLBACK 명령문을 가지
고 로그된다.
Binlog_cache_use 상태 변수는 명령문을 저장하기 위해 이 버퍼(또는 임시 파일)를 사용한 트랜젝션의 숫자를 표시한다.
Binlog_cache_disk_use 상태 변수는 이 임시 파일을 실제로 사용한 트랜젝션의 숫자를 표시한다. 이 두 가지의 변수는 임시 파일
사용을 피하기 위해 binlog_cache_size의 크기를 튜닝하는데 사용된다.
max_binlog_cache_size 시스템 변수(디폴트 4GB)는 다중-명령문 트랜젝션을 캐시 하는데 사용되는 전체 크기를 제한하는데 사
용된다. 만약에 한 트랜젝션이 이것보다 크게 되면, 그 트랜젝션을 실패하게 되고 롤백된다,
만약에 여러분이 바이너리 로그를 사용하고 있다면, 동시 삽입은 CREATE ... SELECT 또는 INSERT ... SELECT 명령문에 대
한 정상 삽입으로 변환된다. 이것은 여러분이 백업 동작을 하는 도중에 로그를 적용해서 여러분의 테이블에 대한 정확한 복사본을
다시 생성할 수 있도록 하기 위해 실행되는 것이다.
5.0의 바이너리 로그 포맷은 리플리케이션의 속도를 개선하기 위해 이전의 MySQL 버전과는 달라졌다는 것을 알기 바란다.

:::MySQL Korea:::
Section 6.5, “MySQL 버전간의 리플리케이션 호환성”을 참조.
디폴트로는, 바이너리 로그는 각각의 기록 시점에 디스크와 동기화가 되지는 않는다. 따라서, 만약에 OS 또는 머신(MySQL 서버
뿐만 아니라)이 크래시 된다면, 바이너리 로그의 마지막 명령문을 잃을 가능성이 생긴다. 이것을 방지하기 위해서는, sync_binlog
시스템 변수를 사용해서, 모든 N 이 바이너리 로그에 기록될 때마다 디스크와 동기화를 하도록 해야 한다. Section 5.2.2, “서버
시스템 변수”를 참조할 것. 1 은 sync_binlog에 대해서는 가장 안전한 값이기는 하지만 또한 가장 느린 값이기도 하다.
sync_binlog를 1로 설정하였다고 하더라도, 크래시가 발생할 경우에는 테이블 컨텐츠와 바이너리 로그 컨텐츠 간에는 여전히 불일
치가 나올 가능성이 있다. 예를 들면, 여러분이 InnoDB 테이블을 사용하고 MySQL 서버가 COMMIT 명령문을 처리 한다면, 모든
트랜젝션이 바이너리 로그에 기록되고 난 후에 이 트랜젝션을 InnoDB 안으로 넣게 된다. 만약에 서버가 이 두 개의 동작 사이에 크
래시 되면, 트랜젝션은 InnoDB에 의해 롤백 되지만 여전히 바이너리 로그에 남아 있게 된다. 이 문제는 --innodb-safe-binlog
옵션으로 해결할 수 있는데, 이 옵션은 InnoDB 테이블의 컨텐츠와 바이너리 로그의 컨텐츠간에 일관성을 추가한다 (Note: --
innodb-safe-binlog는 MySQL 5.0 이후에는 필요 없게 되었다; 이 옵션은 XA 트랜젝션 지원으로 인해 쓰지 않아도 되게 됨.)
이 옵션이 보다 완벽한 안전성을 제공하기 위해서는, MySQL 서버는 모든 트랜젝션 시점에도 바이너리 로그와 InnoDB 로그를 디
스크에 동기화 시키도록 구성되어야 한다. InnoDB 로그는 디폴트로 동기화 되며, sync_binlog=1는 바이너리 로그를 동기화 하기
위해 사용된다. 이 옵션의 효과는 크래시 후에 재 구동하는 시점에, 트랜젝션 롤백을 한 후에, MySQL 서버가 롤백된 InnoDB 트랜
젝션을 바이너리 로그에서 잘라 낸다는 것이다. 이것은 바이너리 로그가 InnoDB 테이블의 정확한 데이터를 반영하도록 해 주며,
따라서 슬레이브는 마스터와 일관성을 유지하게 된다tables, and so, that the slave remains in synchrony with the master (롤
백된 명령문을 받지 않음).
MySQL 서버가 InnoDB가 아닌 다른 스토리지 엔진을 업데이트 할 경우에도 --innodb-safe-binlog를 사용할 수 있다는 점을
알기 바란다. InnoDB에 영향을 미치는 명령문과 트랜젝션만이 InnoDB의 크래시를 복구하는 시점에 바이너리 로그에서 제거된다.
이 복구 시점에, MySQL 서버가 가지고 있어야 하는 바이너리 로그보다 짧은 것을 발견하게 되면, 성공적으로 수행된 InnoDB 트
랜젝션 중에 최소한 한 개를 잃어 버린 것이다. 이것은 sync_binlog=1 이고 디스크/파일시스템이 실제로 동기화를 실행한다면 발
생하지 않는데, 따라서 서버는 binary log <name> is shorter than its expected size. 라는 에러 메시지를 출력한다. 이와 같은
경우, 바이너리 로그는 올바른 것이 아니며 마스터 서버의 데이터 스냅 샷에서 리플리케이션을 다시 실행해야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.12.4. 슬로우 쿼리 로그
5. 데이터 베이스 관리 슬로우 쿼리 로그는 실행 시간이 long_query_time 보다 길게 걸리는 모든 SQL 명령문으로 구성된다. 초기 테이블 잠금을 얻기 위
5.12. MySQL 서버 로그 한 시간은 실행 시간으로 계산되지 않는다. The minimum and default values of long_query_time의 최소값 및 디폴트 값은 각
5.12.4 슬로우 쿼리 로그 각 1 과 10이다.
Mysqld은 명령문을 실행한 후에 그리고 모든 잠금이 풀린 후에 그 명령문을 슬로우 쿼리 로그에 기록한다. 로그 순서는 실행 순서
와는 다르다.
슬로우 쿼리 로그를 활성화 시키기 위해서는, mysqld을 --log-slow-queries[=file_name] 옵션과 함께 시작한다.
아무런 file_name 값도 주어지지 않는다면, 디폴트는 -slow.log의 접미사를 가지고 있는 호스트 머신의 이름을 사용한다. 만약에
파일 이름은 주어 지지만, 절대 경로 이름이 아니라면, 서버는 파일을 데이터 디렉토리에 기록한다.
슬로우 쿼리 로그는 실행 시간이 오래 걸리기 때문에 최적화를 해야 할 쿼리를 찾는데 사용할 수 있다. 하지만, 긴 슬로우 쿼리 로그
를 검사 하는 것은 어려운 작업이다. 이 작업을 보다 쉽게 하기 위해서는, 로그안에 있는 쿼리를 요약하기 위한 mysqldumpslow 명
령어를 사용해서 슬로우 쿼리를 처리 한다. mysqldumpslow –help를 사용해서 이 명령어에 사용할 수 있는 옵션들을 보도록 한
다.
MySQL 5.0에서, 인덱스를 사용하지 않는 슬로우 쿼리는 인덱스를 사용하는 쿼리와 함께 로그 된다. 슬로우 쿼리 로그에 인덱스를
사용하지 않는 쿼리가 로그되는 것을 방지하기 위해서는, --log-queries-not-using-indexes 옵션을 사용한다.
Section 5.2.1, “mysqld 명령어 옵션”을 참조.
MySQL 5.0에서, --log-slow-admin-statements 서버 옵션은 OPTIMIZE TABLE, ANALYZE TABLE, and ALTER
TABLE 와 같은 관리 명령문이 슬로우 쿼리 로그에 로깅 되는 것을 활성화 시킨다.
쿼리 캐시가 처리하는 쿼리들은 슬로우 쿼리 로그에 추가되지 않으며, 테이블에 열이 없거나 하나의 열만 가지고 있기 때문에 인덱

:::MySQL Korea:::
스를 사용할 필요가 없는 쿼리들도 슬로우 쿼리 로그에 추가되지 않는다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.12.5. 서버 로그 관리
5. 데이터 베이스 관리 MySQL 서버는 서로 다른 여러 개의 로그 파일을 생성해서 지금 진행되고 있는 일을 보다 쉽게 볼 수 있도록 할 수 있다.

5.12. MySQL 서버 로그 Section 5.12, “MySQL 서버 로그”를 참조. 하지만, 이러한 로그들이 너무 많은 디스크 공간을 차지하지 못하도록 정기적으로
5.12.5 서버 로그 관리 없애 주어야 한다.
MySQL 을 로깅 활성화 상태로 사용할 때에는, 백업을 받고 가끔씩 오래된 로그 파일을 삭제할 필요가 있으며 MySQL이 새로운
파일에 로깅 하도록 만들고 싶을 것이다. Section 5.10.1, “데이터 베이스 백업”을 참조.
리눅스(레드 헷) 설치에서는, 이것을 위해 mysql-log-rotate 스크립트를 사용할 수가 있다. 만약에 RPM 버전을 가지고 MySQL
을 설치 한다면, 이 스크립트는 자동으로 설치가 된다. 만약에 리플리케이션을 위해 바이너리 로그를 사용하는 중이라면, 이 스크립
트를 사용하는 것에 주의를 해야 한다. 여러분은 바이너리 로그에 있는 컨텐츠를 모든 슬레이브가 처리했다고 확신할 때까지는 바
이너리 로그를 삭제할 수가 없다.
다른 시스템의 경우, 로그 파일을 처리하기 위해 스스로 간단한 스크립트를 설치해서 서버를 cron (또는 동일한 것들)에서 시작을
할 수 있도록 해야 한다.
여러분은 mysqladmin flush-logs을 사용하거나 또는 SQL 명령문인 FLUSH LOGS를 사용해서 MySQL 서버가 새로운 로그 파
일을 사용해서 구동되도록 만들 수가 있다.
로그 플러싱 동작은 다음과 같이 진행된다:
● 만약에 일반 쿼리 로깅 (--log) 또는 슬로우 쿼리 로깅 (--log-slow-queries)을 사용 한다면, 서버는 일반 쿼리 로그

파일과 슬로우 쿼리 로그 파일을 닫은 다음에 다시 연다.
● 만약에 바이너리 로깅 (--log-bin)을 사용하면, 서버는 현재의 로그 파일을 닫고 그 다음 순서의 번호를 사용해서 새로
운 로그 파일을 열게 된다.

:::MySQL Korea:::
서버는 로그를 플러시할 때 새로운 바이너리 로그 파일을 생성한다. 하지만, 서버는 일반 쿼리 로그 파일과 슬로우 쿼리 로그 파일
은 단순히 닫은 다음에 다시 열기만 한다. 유닉스에서 새로운 파일이 생성되도록 하기 위해서는, 현재의 로그를 플러시 하기 전에
이름을 바꿔 준다. 플러시 할 때에는, 서버는 원래의 이름을 가진 새로운 로그를 열게 된다. 예를 들면, 만약에 일반 쿼리 로그와 슬
로우 쿼리 로그가 mysql.log 와 mysql-slow.log라고 되어 있다면, 아래와 같은 일련의 명령어를 사용할 수가 있다:
shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mv mysql-slow.log mysql-slow.old
shell> mysqladmin flush-logs
이 시점에, mysql.old 와 mysql-slow.log의 백업을 만들고 난 다음에 디스크에서 그것들을 삭제한다.
윈도우에서는, 서버가 로그 파일을 열어 놓을 동안에는 이름을 바꾸지 못한다. 여러분은 반드시 서버를 종료 시킨 후에 이름을 바꾸
어야 하고, 새로운 로그를 생성하기 위해서는 서버를 재 구동 시켜야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.13. 동일 머신에서 여러 대의 MySQL 서버 구동 시키기

5.13.1. 윈도우에서 여러대의 서버 구동 시키기
5. 데이터 베이스 관리 5.13.2. 유닉스엣 여러대의 서버 구동 시키기
5.13. 동일 머신에서 여러 대의 MySQL 서버 구동 시 5.13.3. 다중-서버 환경에서 클라이언트 프로그램 사용하기
키기 어떤 경우에는, 동일 머신에서 여러대의 mysqld 서버를 구동하고자 할 수도 있다. 하나의 머신에서 여러 개의 서버를 구동
5.13 동일 머신에서 여러 대의 MySQL 서버 구동 시키기 시키기 위해서는, 각 서버는 여러 가지의 동작 파라미터에 대해 고유의 값을 가지고 있어야 한다. 이 값들은 명령어 라인 또
5.13.1.1 명령어 라인에서 여러 개의 윈도우 서버 구동하기 는 옵션 파일에 지정할 수가 있다. Section 4.3, “프로그램 옵션 지정하기”를 참조.
5.13.2 유닉스에서 여러 개의 서버 구동하기 각각의 서버에 대해서는 아래의 옵션들이 최소한 서로 달라야 한다:
5.13.3 다중-서버 환경에서 클라이언트 프로그램 사용하기

● --port=port_num
--port는 TCP/IP 접속을 위한 포트 번호를 제어한다.
● --socket=path
--socket은 유닉스에서는 유닉스 소켓 파일 경로를 제어하며, 윈도우에서는 네임드 파이프의 이름을 제어한다.
윈도우에서는, 네임드 파이트 접속을 지원하는 서버에 대해서만 정확한 파이프 이름을 지정할 필요가 있다.
● --shared-memory-base-name=name
이 옵션은 아직까지는 윈도우에서만 사용된다. 이것은 윈도우 서버가 사용하는 공유 메모리 이름을 가지고 클라이
언트가 공유 메모리를 통해 접속할 수 있도록 하기 위한 것이다. 공유 메모리 접속을 지원하는 서버에 대해서만 정
확히 지정하면 된다.
이 옵션은 유닉스에서만 사용된다. 이것은 서버가 자신의 프로세스 ID를 기록하는 파일의 경로 이름을 가리킨다.

:::MySQL Korea:::
만약에 아래의 로그 파일 옵션을 사용한다면, 이 옵션들은 각각의 서버에 대해 서로 틀리게 지정되어야 한다:
● --log=file_name
● --log-bin=file_name
● --log-update=file_name
● --log-error=file_name
● --bdb-logdir=file_name
Section 5.12.5, “서버 로그 관리”에서 보다 많은 옵션을 다루고 있다.

보다 좋은 성능을 위해서, 각각의 서버에 아래의 옵션을 달리 지정할 수가 있는데, 이것들은 여러 개의 물리적으로 분리된
디스크간에 로드를 분산해 준다:
● --tmpdir=path
● --bdb-tmpdir=path
서로 다른 임시 디렉토리를 가지는 것도 어떤 MySQL 서버가 주어진 임시 파일을 생성했는지를 보다 쉽게 판단할 수 있도

록 해 주기 때문에 권장할 만 사항이다.
매우 제한적인 예외 사항을 가지고, 각 서버는 서로 다른 데이터 디렉토리를 사용해야 하는데, 이것은 --datadir=path 옵
션을 사용해서 지정된다.
Warning: 정상적으로는, 동일한 데이터 베이스에 두 대의 서버가 동시에 데이터를 업데이트할 수는 없다. 만약에(이 경고
에도 불구하고), 동일한 데이터 디렉토리를 사용해서 여러 개의 서버를 구동 키시고 이 서버들의 로깅이 활성화 되어 있다
면, 여러분은 반드시 각 서버 별로 고유의 로그 파일 이름을 지정하기 위한 옵션을 사용해야 한다. 그렇지 않으면, 서버는
동일한 파일에 로그를 시도할 것이다. Please note that this kind of setup only works with MyISAM 과 MERGE 테이
블에만 동작하는 것을 설정하도록 하며, 다른 스토리지 엔진에 대해서는 적용하지 않도록 한다.
서버간에 공유하는 데이터 디렉토리에 대한 경고는 NFS 환경에서도 적용된다. 여러 개의 MySQL 서버가 NFS를 통해 공
통의 데이터 디렉토리에 접근하도록 허용하는 것은 결코 좋은 생각이 아니다.
● 가장 치명적인 문제는 바로 NFS의 버틀넥(bottleneck) 발생이다.

● 또 다른 문제는 두 개 또는 그 이상의 서버가 다른 서버들과 인터페이스를 하지 못하도록 수정을 해야 한다는 것이
다. 일반적으로 NFS 파일 잠금은 lockd 데몬이 처리하지만, 모든 상황에서 100% 신뢰성을 제공해 주는 플랫폼은
존재하지 않는다.

:::MySQL Korea:::
보다 쉽게 생각을 하자: NFS를 통해서 서버들이 데이터 디렉토리를 공유하는 것을 잊어 버리자. 보다 좋은 솔루션은 쓰레
드를 보다 효과적으로 처리하는 OS를 탑재한 다중 CPU 시스템을 하나 운영하는 것이다.
서로 다른 위치에 여러 개의 MySQL을 설치했다면, 각 서버별 베이스 설치 디렉토리를 --basedir=path 옵션으로 지정
을 해서 각각의 서버가 서로 다른 데이터 디렉토리, 로그 파일, 그리고 PID 파일을 사용하도록 만든다. (이러한 모든 것들
의 디폴트 값은 베이스 디렉토리와 관련이 있다). 이와 같은 경우, 여러분이 지정을 할 필요가 있는 한가지 다른 옵션은
--socket 과 --port 옵션이다. 예를 들면, tar 파일 바이너리 배포판을 사용해서 서로 다른 MySQL 버전들을 설치했다
고 가정하자. 서로 다른 위치에 설치를 하였기 때문에, 여러분은 각각의 베이스 디렉토리 아래에서 명령어bin/
mysqld_safe 를 사용해서 각각의 설치 서버를 시작할 수가 있다. mysqld_safe는 --basedir 옵션이 정확한지를 판단해
서 mysqld에 전달을 하며, 여러분은 mysqld_safe에 대한 --socket 과 --port 옵션만 지정하면 된다.

:::MySQL Korea:::
제목검색
5.13.1.1. 명령어 라인에서 여러 개의 윈도우 서버 구동하기

5. 데이터 베이스 관리 명령어 라인에서 수동으로 여러 개의 서버를 구동하기 위해서는, 명령어 라인 또는 옵션 파일에 적절한 옵션을 지정해야 한다. 옵
5.13. 동일 머신에서 여러 대의 MySQL 서버 션 파일에 옵션을 주는 것이 더 편리한 방법이지만, 각각의 서버가 자신들의 옵션만을 가져가도록 해야 한다. 이렇게 하기 위해서
구동 시키기 는, 각 서버 별로 옵션 파일을 생성하고 서버를 구동할 때 서버에 --defaults-file 옵션이 붙은 파일 이름을 알려 준다.
5.13.1.1 명령어 라인에서 여러 개의 윈도우 서버
구동하기 여러분이 포트 3307에서 mysqld을 데이터 디렉토리 C:￦mydata1를 가지고 구동시키며, 포트 3308에서는 mysqld-max를 C:
￦mydata2와 함께 구동 시킨다고 가정하자 (이렇게 하기 위해서는, 서버를 구동 하기 전에, 각 데이터 디렉토리는 이미 존재하고
그랜트 테이블을 가지고 있는 mysql 데이터 베이스의 복사본을 가지고 있어야 한다.) 그런 다음에 두 개의 옵션 파일을 생성한다.
예를 들면, 아래와 같은 형식의 파일 C:￦my-opts1.cnf를 생성한다:
[mysqld]
datadir = C:/mydata1
port = 3307
두 번째 파일 C:￦my-opts2.cnf을 생성한다:
[mysqld]
port = 3308
그런 다음에 각 서버를 자신들의 옵션 파일과 함께 구동 시킨다:

:::MySQL Korea:::
C:￦> C:￦mysql￦bin￦mysqld --defaults-file=C:￦my-opts1.cnf
C:￦> C:￦mysql￦bin￦mysqld-max --defaults-file=C:￦my-opts2.cnf
NT에서는, 각 서버는 전면(foreground)에서 구동 되며 (서버가 동작을 마칠 때까지 프롬프트는 나타나지 않음), 따라서 위의 두
개의 명령어를 서로 별도의 콘솔 윈도우에서 구동 시킨다.
서버를 셧다운 시키기 위해서는, 각 서버의 포트 번호를 사용해서 서버에 접근해야 한다:
C:￦> C:￦mysql￦bin￦mysqladmin --port=3307 shutdown
C:￦> C:￦mysql￦bin￦mysqladmin --port=3308 shutdown
위와 같이 구성된 서버는 클라이언트가 TCP/IP를 통해 접속할 수 있도록 해 준다. 여러분이 사용하는 윈도우 버전이 네임드 파이
프를 지원하고 그리고 네임드 파이프 접속을 허용하고자 한다면, mysqld-nt 또는 mysqld-max-nt 서버를 사용하여 네임드 파이
프를 활성화 시키는 옵션과 네임드 파이프의 이름을 지정해 준다. 네임드 파이프 접속을 지원하는 각 서버는 고유의 파이프 이름을
사용해야 한다. 예를 들면, C:￦my-opts1.cnf 파일을 아래와 같이 작성해 보자:
[mysqld]
port = 3307
enable-named-pipe
socket = mypipe1
그런 다음에 아래와 같이 서버를 시작한다:
C:￦> C:￦mysql￦bin￦mysqld-nt --defaults-file=C:￦my-opts1.cnf

:::MySQL Korea:::
두 번째 서버의 C:￦my-opts2.cnf도 비슷하게 수정을 한다.
공유-메모리 접속을 지원하는 서버에 대해서도 비슷한 과정을 수행할 수가 있다. --shared-memory 옵션을 가지고 접속을 활
성화 시키고 --shared-memory-base-name 옵션을 사용해서 서버 별 고유의 공유-메모리 이름을 지정한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.13.2. 유닉스에서 여러 개의 서버 구동하기
5. 데이터 베이스 관리 유닉스에서 여러 개의 서버를 구동 시키는 가장 쉬운 방법은 각각의 서버를 서로 다른 TCP/IP 포트와 유닉스 소켓 파일을 사용해
5.13. 동일 머신에서 여러 대의 MySQL 서버 서 컴파일 해서 각 서버가 별도의 네트워크 인터페이스를 통하도록 하는 것이다. 각각의 설치 서버별로 서로 다른 베이스 디렉토리
구동 시키기 를 가지고 컴파일을 하게 되면 자동으로 서버별 데이터 디렉토리, 로그 파일, 그리고 PID 파일 위치가 구분된다.
5.13.2 유닉스에서 여러 개의 서버 구동하기
현재 설치되어 있는 4.1.8 서버가 디폴트 TCP/IP 포트 번호(3306)과 유닉스 소켓 파일 (/tmp/mysql.sock)로 구성 되었다고 가
정하자. 새로운 5.0.19 서버가 별도의 동작 파라미터를 가지게 하기 위해서는, 아래와 같이 configure 명령어를 사용한다:
shell> ./configure --with-tcp-port=port_number ￦
--with-unix-socket-path=file_name ￦
--prefix=/usr/local/mysql-5.0.19
여기에서, port_number 와 file_name은 디폴트 TCP/IP 포트 번호와 유닉스 소켓 파일과 달라야 하고, 또한 --prefix 값은 현재
의 MySQL 서버가 설치되어 있는 디렉토리와는 다른 곳을 지정해야 한다.
만약에 주어진 포트 번호를 참조는 MySQL 서버가 이미 있다면, 여러분은 아래의 명령어를 사용해서 베이스 디렉토리와 유닉스 소
켓 파일 이름을 포함해서 몇몇 중요한 구성 변수가 사용하고 있는 동작 파라미터의 값을 알아 볼 수가 있다:
shell> mysqladmin --host=host_name --port=port_number variables
이 명령어를 통해 얻어진 정보를 가지고, 여러분은 다른 서버가 추가될 때 사용할 수 없는 옵션 값이 무엇인지를 알 수가 있다.
만약에 호스트 이름으로 localhost를 지정한다면, mysqladmin은 TCP/IP가 아닌 유닉스 소켓 파일 접속을 디폴트로 사용한다.
MySQL 4.1 이후에는, --protocol={TCP|SOCKET|PIPE|MEMORY} 옵션을 사용해서 여러분이 사용하고자 하는 접속 프로

:::MySQL Korea:::
토콜을 명확하게 지정할 수가 있다.
여러분은 서로 다른 유닉스 소켓 파일과 TCP/IP를 가지고 시작하기 위해 새로운 서버를 컴파일할 필요는 없다. 동일한 서버 바이
너리를 사용하고 런타임 시에 별도의 파라미터 값을 가지고 각각을 호출하는 것도 가능하다. 이렇게 하는 방법 중의 하나는 명령어
라인에서 옵션을 사용하는 것이다:
shell> mysqld_safe --socket=file_name --port=port_number
두 번째 서버를 구동하기 위해서는, –socket과 –port의 옵션 값을 다른 값으로 주고, 그리고 --datadir=path 옵션을
mysqld_safe에 전달해서 서버가 다른 데이터 디렉토리를 사용하도록 한다.
비슷한 효과를 얻기 위한 다른 방법은 유닉스 소켓 파일 이름과 TCP/IP 포트 번호를 설정하는 환경 변수를 사용하는 것이다:
shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> mysql_install_db --user=mysql
shell> mysqld_safe --datadir=/path/to/datadir &
이 방법은 두 번째 서버를 빠르게 시작할 수 있도록 한다. 이 방법의 장점은 환경 변수 설정이 여러분이 동일한 쉘에서 호출하는 모
든 클라이언트 프로그램에 적용된다는 것이다. 따라서, 이러한 클라이언트에 대한 접속이 자동으로 두 번째 서버를 가리키게 된다.
Appendix F, Environment Variables에는 여러분이 mysqld에 영향을 주도록 사용할 수 있는 여러 가지의 다른 환경 변수가 설명
되어 있다.
서버의 자동 실행을 위해서는, 서버 부팅 시점에 실행되는 스타트업 스크립트가 아래의 명령어 별로 적당한 옵션 파일 경로를 가지
고 각 서버 별로 한번씩은 실행되어야 한다:

:::MySQL Korea:::
shell> mysqld_safe --defaults-file=file_name
각 옵션 파일은 주어진 서버를 지칭하는 옵션 값을 가지고 있어야 한다.
유닉스에서는, mysqld_multi 스크립트를 사용해서 여러 개의 서버를 구동할 수가 있다. Section 5.4.3, “mysqld_multi — 다중
MySQL 서버 관리”를 참조.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.13.3. 다중-서버 환경에서 클라이언트 프로그램 사용하기
5. 데이터 베이스 관리 클라이언트에 컴파일된 것과는 다른 네트워크 인터페이스를 참조하고 있는 서버에 클라이언트 프로그램을 가지고 접속하기 위해서
5.13. 동일 머신에서 여러 대의 MySQL 서버 는, 아래의 방법 중에 하나를 사용한다:
구동 시키기
5.13.3 다중-서버 환경에서 클라이언트 프로그램 ● 리모트 서버에 TCP/IP를 경유해서 접속하기 위해서는 클라이언트를 --host=host_name --port=port_number와 함
사용하기 께 시작하고, 로컬 서버에 접속하기 위해서는 --host=127.0.0.1 --port=port_number를 가지고 시작하고, 또는 유닉
스 소켓 파일 또는 윈도우 네임드 파이프를 사용해서 로컬 서버에 접속을 할 경우에는 --host=localhost --
socket=file_name을 사용해서 클라이언트를 시작한다.
● MySQL 4.1 이후에는, TCP/IP를 경유한 클라이언트 접속은 --protocol=tcp를 사용하고, 유닉스 소켓 파일을 경유하는
접속은 --protocol=socket, --protocol=pipe는 네임드 파이프를 위한 것이며, --protocol=memory는 공유 메모리
를 통한 접속을 위해 사용하는 것이다. TCP/IP 접속의 경우, 여러분은 --host 와 --port 옵션도 지정할 필요가 있다. 다
른 형태의 접속에 대해서는, 유닉스 소켓 파일 또는 윈도우 네임드 파이프 이름을 위해서는 --socket 옵션을, 공유 메모
리 이름을 위해서는 --shared-memory-base-name 옵션을 지정할 필요가 있다. 공유 메모리 접속은 윈도우에서만 지
원된다.
● 유닉스에서는, 클라이언트를 시작하기 전에 MYSQL_UNIX_PORT 와 MYSQL_TCP_PORT 환경 변수를 설정해서 유닉
스 소켓 파일과 TCP/IP포트 번호를 가리키도록 한다. 만약에 여러분이 특정 유닉스 소켓 파일 또는 포트 번호를 일반적으
로 사용한다면, .login 파일에 이러한 환경 변수를 설정하는 명령어를 입력해서 여러분이 로그인 할 때마다 적용되도록 한
다. Appendix F, 환경 변수를 참조할 것.
● 옵션 파일의 [client] 그룹 안에 디폴트 유닉스 소켓 파일과 TCP/IP포트 번호를 지정한다. 예를 들면, 윈도우에서는 C:
￦my.cnf, 또는 유닉스에서는 여러분의 홈 디렉토리에 있는 .my.cnf 파일을 사용할 수 있다. Section 4.3.2, “옵션 파일
사용하기”를 참조.
● C 프로그램에서는, mysql_real_connect() 호출에 유닉스 소켓 파일과 포트 번호 인수를 지정할 수가 있다. 또한, mysql_
옵션()을 호출해서 프로그램 읽기 옵션 파일을 가질 수도 있다. Section 22.2.3, “C API 함수 상세 설명”을 참조.
● 만약에 Perl DBD::mysql 모듈을 사용한다면, 여러분은 MySQL 옵션 파일에서 옵션을 읽을 수가 있다. 예를 들면:

:::MySQL Korea:::
• $dsn = "DBI:mysql:test;mysql_read_default_group=client;"
• . "mysql_read_default_file=/usr/local/mysql/data/my.cnf";
• $dbh = DBI->connect($dsn, $user, $password);
Section 22.4, “MySQL Perl API”를 참조.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.14. MySQL 쿼리 캐시

5.14.1. 쿼리 캐시를 동작 시키는 방법
5. 데이터 베이스 관리 5.14.2. 쿼리 캐시SELECT 옵션
5.14. MySQL 쿼리 캐시 5.14.3. 쿼리 캐시구성
5.14 MySQL 쿼리 캐시 5.14.4. 쿼리 캐시상태 및 관리
5.14.1 쿼리 캐시를 동작 시키는 방법 쿼리 캐시는 SELECT 명령문이 클라이언트에 보내는 결과와 함께 명령문을 저장한다. 만약에 동일한 명령문이 나중에 전달되면,
5.14.2 쿼리 캐시 SELECT 옵션 서버는 그 명령문을 다시 분석(parsing)하고 실행하는 대신에 쿼리 캐시에서 그 결과 값을 추출한다.
5.14.3 쿼리 캐시 구성 쿼리 캐시는 여러분이 자주 변경되지 않는 테이블을 가지고 있고 서버가 동일한 쿼리를 많이 받는 환경에서는 매우 유용하게 사용
된다. 이것은 데이터 베이스 컨텐츠를 기반으로 많은 수의 동적 페이지를 만들어 내는 대부분의 웹 서버에서 활용할 수가 있다.
5.14.4 쿼리 캐시 상태 및 관리
Note: 쿼리 캐시는 오래된 데이터(stale)를 리턴 하지는 않는다. 테이블이 수정되면, 쿼리 캐시에 있는 모든 연관 엔트리는 플러시
된다.
Note: 쿼리 캐시는 동일한 MyISAM 테이블을 업데이트하는 여러 개의 mysqld 서버를 가지고 있는 환경에서는 동작하지 않는다.
Note: 쿼리 캐시는 서버-측면의 프리페어드(prepared)명령문에서는 사용되지 않는다. Section 22.2.4, “C API 프리페어드
(Prepared) 명령문”을 참조.
서버 스타트업 시점에 쿼리 캐시를 비활성화 시키기 위해서는, query_cache_size 시스템 변수를 0으로 설정한다. 만약에 MySQL
을 소스를 가지고 설치한다면, 쿼리 캐시 기능은 --without-query-cache 옵션을 가지고 configure를 호출해서 전부 제외 시
킬 수가 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.14.1. 쿼리 캐시를 동작 시키는 방법
5. 데이터 베이스 관리 이 섹션에서는 쿼리 캐시를 구동 시키는 방법을 설명하기로 한다. Section 5.14.3, “쿼리 캐시 구성”에서는 쿼리 캐시가 동작 가
5.14. MySQL 쿼리 캐시 능한 것인지를 제어하는 방법을 설명한다.
5.14.1 쿼리 캐시를 동작 시키는 방법

입력되는 쿼리는 분석을 하기 전에 쿼리 캐시에 있는 것과 비교를 하며, 따라서 아래의 두 쿼리는 쿼리 캐시에 의해 서로 다른 것으
로 간주된다:
SELECT * FROM tbl_name
Select * from tbl_name
쿼리가 서로 동일한 것으로 보이기 위해서는 반드시 정확히 똑 같아야 한다(바이트 비교). 또한, 동일한 쿼리 스트링은 다른 이유
로 인해 서로 다른 것으로 취급되기도 한다. 서로 다른 데이터 베이스, 프로토콜 버전, 또는 디폴트 문자 셋을 사용하는 쿼리들은 서
로 다른 것으로 간주되고 별도로 캐시된다.
쿼리의 결과를 쿼리 캐시에서 가져오기 전에, MySQL은 사용자가 모든 데이터 베이스와 호출된 테이블에 대해 SELECT 권한을
가지고 있는지를 검사한다, 만약에 권한이 없다면, 캐시 결과는 사용되지 않는다.
만약에 쿼리 결과가 쿼리 캐시에서 리턴되면, 서버는 Qcache_hits 상태 변수를 증가 시킨다(Com_select를 증가 시키지 않음).
Section 5.14.4, “쿼리 캐시상태 및 관리”를 참조.
테이블이 변경된다면, 그 테이블을 사용하는 모든 캐시된 쿼리들은 사용할 수 없게 되며(invalid) 캐시에서 제거된다. 여기에는 변
경된 테이블을 매핑하는 MERGE 테이블도 포함된다. INSERT, UPDATE, DELETE, TRUNCATE, ALTER TABLE, DROP
TABLE, 또는 DROP DATABASE와 같은 여러 가지의 명령문으로 인해 테이블은 변경될 수 있다.
변경된 트랜젝션 InnoDB 테이블은 COMMIT 이 실행될 때에는 사용되지 못한다.

:::MySQL Korea:::
쿼리 캐시는 InnoDB 테이블을 사용할 때 트랜젝션 내에서 동작될 수도 있는데, 테이블 버전 번호를 사용해서 테이블 컨텐츠가 여
전히 존재하는지를 검사하도록 한다.
MySQL 5.0에서는, 캐시되는 뷰에 의해서 쿼리가 만들어 진다.
MySQL 5.0 이전에는, 코멘트로 시작되는 쿼리는 캐시 되었으나, 캐시에서 가져올 수는 없었다. 이 문제는 MySQL 5.0에서 해결
을 했다.
쿼리 캐시는 SELECT SQL_CALC_FOUND_ROWS ... 그리고 SELECT FOUND_ROWS() 타입의 쿼리와 동작을 한다.
FOUND_ROWS()는 비록 발견된 열의 숫자도 함께 캐시에 저장되기 때문에 앞에 있는 쿼리를 캐시로부터 가져올 수 있었다고 하
더라도 올바른 값을 리턴해 준다.
만약에 아래의 테이블에 있는 함수 중에 하나라도 쿼리가 가지고 있게 되면 캐시를 할 수가 없다.
BENCHMARK() CONNECTION_ID() CURDATE()
CURRENT_DATE() CURRENT_TIME() CURRENT_TIMESTAMP()
CURTIME() DATABASE() ENCRYPT() with one parameter
FOUND_ROWS() GET_LOCK() LAST_INSERT_ID()
LOAD_FILE() MASTER_POS_WAIT() NOW()
RAND() RELEASE_LOCK() SYSDATE()
UNIX_TIMESTAMP()(파라미터 없이 사용되는 경우) USER()
또한, 아래의 조건에서는 쿼리가 캐시 되지 않는다:
● 쿼리가 사용자 정의 함수 (UDFs)를 참조함.

● 쿼리가 사용자 변수를 참조함.
● 쿼리가 mysql 시스템 데이터 베이스에 있는 테이블을 참조함.
● 쿼리가 아래의 형태 중에 하나일 경우:

:::MySQL Korea:::
• SELECT ... IN SHARE MODE
• SELECT ... FOR UPDATE
• SELECT ... INTO OUTFILE ...
• SELECT ... INTO DUMPFILE ...
• SELECT * FROM ... WHERE autoincrement_col IS NULL
마지막 형태는 쿼리가 마지막 ID 값을 얻기 위해 ODBC를 사용하고 있기 때문에 캐시 되지 못한다. Section 23.1.14.1,
“ODBC에서 AUTO_INCREMENT 컬럼 값을 가져 오기”를 참조할 것.
● 플레이스 홀더(placeholder)가 사용되었다고 하더라도, 쿼리가 프리페어드 명령문 형태로 입력되었다. 예를 들면, 여기에
서 사용되는 쿼리는 캐시되지 않는다:
• char *my_sql_stmt = "SELECT a, b FROM table_c";
• /* ... */
• mysql_stmt_prepare(stmt, my_sql_stmt, strlen(my_sql_stmt));
Section 22.2.4, “C API 프리페어드(Prepared) 명령문”을 참조.
● 쿼리가 TEMPORARY 테이블을 사용한다.

● 어떠한 테이블도 쿼리가 사용하지 않는다.
● 사용자가 포함되어 있는 모든 테이블에 대한 컬럼-레벨 권한을 가지고 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.14.2. 쿼리 캐시 SELECT 옵션
5. 데이터 베이스 관리 SELECT 명령문 안에서 두 개의 쿼리 캐시-관련 옵션을 지정할 수도 있다:
5.14. MySQL 쿼리 캐시
● SQL_CACHE
5.14.2 쿼리 캐시 SELECT 옵션
쿼리 결과 값은 query_cache_type 시스템변수의 값이 ON 또는 DEMAND라면 캐시 된다.
● SQL_NO_CACHE
쿼리 결과는 캐시 되지 않는다.
예제:
SELECT SQL_CACHE id, name FROM customer;
SELECT SQL_NO_CACHE id, name FROM customer;
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.14.3. 쿼리 캐시 구성
5. 데이터 베이스 관리 have_query_cache 서버 시스템 변수는 쿼리 캐시가 사용 가능한지를 나타낸다:

5.14.3 쿼리 캐시 구성 mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
+------------------+-------+
| have_query_cache | YES |
+------------------+-------+
표준 MySQL 바이너리를 사용하면, 이 값은 항상 YES인데, 쿼리 캐시가 비활성화 되었을 경우에도 해당한다.
다른 여러 가지의 시스템 변수가 쿼리 캐시의 동작을 제어 한다. 이 변수들은 옵션 파일 또는 명령어 라인에서 설정될 수 있다.
mysqld이 시작될 때 이 변수들은 옵션 파일 또는 명령어 라인에서 설정될 수 있다. 쿼리 캐시 시스템 변수 모두는 query_cache_
를 가지고 시작된다.
쿼리 캐시의 크기를 설정하기 위해서는, query_cache_size 시스템 변수를 설정하면 된다. 이것을 0으로 설정하게 되면 쿼리 캐시
는 비활성화가 된다. 디폴트는 0 이다.
여러분이 query_cache_size를 0이 아니 값으로 설정할 때에는, 쿼리 캐시는 최소한 40KB의 크기를 가져야 한다는 것을 알기 바
란다. (정확한 크기는 시스템 구조에 달려 있다.) 만약에 이 값을 너무 작게 설정한다면, 아래와 같은 경고문이 나오게 된다:

:::MySQL Korea:::
mysql> SET GLOBAL query_cache_size = 40000;
Query OK, 0 rows affected, 1 warning (0.00 sec)
mysql> SHOW WARNINGS￦G
*************************** 1. row ***************************
Level: Warning
Code: 1282
Message: query cache failed to set size 39936; new query cache size is 0
mysql> SET GLOBAL query_cache_size = 41984;
mysql> SHOW VARIABLES LIKE 'query_cache_size';
+------------------+-------+
+------------------+-------+

:::MySQL Korea:::
| query_cache_size | 41984 |
+------------------+-------+
만약에 쿼리 캐시의 크기가 0 보다 크면, query_cache_type 변수가 동작에 영향을 주게 된다. 이 변수는 아래의 값을 가지고 설정
할 수 있다:
● 0 또는OFF는 캐싱 또는 캐시 결과를 추출하지 못하게 한다.

● 1 또는 ON는 SELECT SQL_NO_CACHE로 시작되는 명령문을 제외하고는 캐싱을 허용한다.
● 2 또는 DEMAND는 SELECT SQL_CACHE로 시작되는 명령문만을 캐싱 하도록 만든다.
GLOBAL query_cache_type 값을 설정하면 데이터가 변경된 후에 접속이 되는 모든 클라이언트에 대한 쿼리 캐시 동작을 결정하

게 된다. 개별적인 클라이언트는 SESSION query_cache_type 값을 사용해서 자신의 접속에 대한 캐시 동작을 제어할 수가 있다.
예를 들면, 클라이언트는 아래와 같이 자신의 쿼리를 위한 쿼리 캐시 사용을 비활성화 시킬 수가 있다:
mysql> SET SESSION query_cache_type = OFF;
캐시될 수 있는 개별 쿼리 캐시의 최대 크기를 제어하기 위해서는, query_cache_limit 시스템 변수를 설정한다. 디폴트는 1MB이
다.
쿼리가 캐시 되어질 경우, 그 결과 값(클라이언트에 전달되는 데이터)은 결과를 추출하는 동안 쿼리 캐시에 저장된다. 따라서 일반
적으로 데이터는 하나의 큰 단위로 취급되지 않는다. 쿼리 캐시는 필요에 따라 이 데이터를 저장하기 위한 블록을 할당하는데, 따라
서 하나의 블록이 가득 차게 되면, 다른 새로운 블록이 할당된다. 메모리 할당 동작은 비용이 비싸기 때문에, 쿼리 캐시는
query_cache_min_res_unit 시스템 변수가 주는 최소의 크기를 가지고 블록을 할당한다. 쿼리가 실행될 때, 최종의 결과 블록은 실
제의 데이터 크기로 조정되고 사용하지 않는 나머지 메모리를 돌려 준다. 여러분의 서버가 실행하는 쿼리의 형태에 따라,
query_cache_min_res_unit의 값을 튜닝하는 것이 도움이 될 것이다:
● query_cache_min_res_unit의 디폴트는 4KB이다. 이 크기는 대부분의 경우에 적당하다.

● 작은 결과 값을 가지는 쿼리를 많이 가지고 있다면, 디폴트 블록 크기로 인해 많은 메모리 단편화(fragmentation)이 발생
할 수도 있다. 메모리 조각은 메모리 부족을 일으켜서 쿼리 캐시가 캐시에서 쿼리를 삭제하게끔 만든다. 이와 같은 경우에
는, query_cache_min_res_unit의 값을 하향 조정한다. 프리 블록(free block)의 숫자와 삭제된 쿼리의 숫자는

:::MySQL Korea:::
Qcache_free_blocks과 Qcache_lowmem_prunes 상태 변수를 가지고 얻을 수 있다.

● 만약에 여러분의 쿼리 대부분이 큰 결과 값(Qcache_total_blocks와 Qcache_queries_in_cache 상태 변수를 검사)을 가지
고 있다면, query_cache_min_res_unit의 값을 증가 시켜서 성능을 개선한다. 하지만, 너무 크게 하지는 않도록 주의 한
다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 5.14.4. 쿼리 캐시 상태 및 관리
5. 데이터 베이스 관리 여러분은 아래의 명령문을 사용해서 여러분의 MySQL 서버에 쿼리 캐시가 존재하는지를 알아볼 수 있다:
5.14.4 쿼리 캐시 상태 및 관리 mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
+------------------+-------+
| have_query_cache | YES |
+------------------+-------+
여러분은 FLUSH QUERY CACHE 명령문을 사용해서 보다 효율적으로 메모리를 관리하도록 쿼리 캐시의 단편화(defragment)
를 해소할 수가 있다. 이 명령문은 캐시에서 어떠한 쿼리도 제거하지 않는다.
RESET QUERY CACHE 명령문은 쿼리 캐시엣 모든 쿼리 결과를 제거한다. FLUSH TABLES 명령문도 이와 같은 일을 한다.
쿼리 캐시의 성능을 모니터 하기 위해서는, SHOW STATUS를 사용해서 캐시 상태 변수를 본다:
mysql> SHOW STATUS LIKE 'Qcache%';
+-------------------------+--------+

:::MySQL Korea:::
+-------------------------+--------+
| Qcache_free_blocks | 36 |
| Qcache_free_memory | 138488 |
| Qcache_hits | 79570 |
| Qcache_inserts | 27087 |
| Qcache_lowmem_prunes | 3114 |
| Qcache_not_cached | 22989 |
| Qcache_queries_in_cache | 415 |
| Qcache_total_blocks | 912 |
+-------------------------+--------+
각각의 변수에 대한 설명은 Section 5.2.4, “서버 상태 변수”에서 하고 있다.
SELECT 쿼리의 전체 숫자는 아래의 공식으로 얻을 수 있다:
Com_select
+ Qcache_hits
+ queries with errors found by parser

:::MySQL Korea:::
Com_select 값은 아래의 공식으로 얻어진다:
Qcache_inserts
+ Qcache_not_cached
+ queries with errors found during the column-privileges check
쿼리 캐시는 변수-길이 블록을 사용하는데, 따라서 Qcache_total_blocks 와 Qcache_free_blocks 는 쿼리 캐시 조각을 가리킬

수 있다. FLUSH QUERY CACHE를 실행한 후에는, 하나의 프리 블록만 남게 된다.
캐시된 모든 쿼리는 최소한 두 개의 블록을 요구한다.(쿼리 텍스트를 위해서 하나가 필요하고, 쿼리 결과 값을 위해서는 한 개 이상
이 필요함). 또한, 쿼리가 사용하는 모든 테이블은 하나의 블록을 요구한다. 하지만, 만약에 두 개 이상의 쿼리가 동일한 테이블을
사용한다면, 하나의 테이블 블록만 할당할 필요가 있다.
Qcache_lowmem_prunes 상태 변수가 제공하는 정보를 가지고 여러분은 쿼리 캐시의 크기를 튜닝할 수가 있다. 이것은 캐시에서
삭제가 되는 쿼리의 숫자를 계산한다. 튜닝 정보는 Section 5.14.3, “쿼리 캐시구성”를 참조할 것.

:::MySQL Korea:::
제목검색
Chapter 6. 리플리케이션
6. 리플리케이션
6 리플리케이션 6.1. 리플리케이션 소개
6.1 리플리케이션 소개 6.2. 리플리케이션 구현 개론

6.3. 리플리케이션 구현 상세 설명
6.2 리플리케이션 구현 개론
6.3.1. 리플리케이션 마스터 쓰레드 상태
6.3 리플리케이션 구현 상세 설명
6.3.2. ‘리플리케이션 슬레이브 I/O 쓰레드 상태
6.3.1 리플리케이션 마스터 쓰레드 상태
6.3.3. 리플리케이션 슬레이브 SQL 쓰레드 상태
6.3.2 리플리케이션 슬레이브 I/O 쓰레드 상태
6.3.4. 리플리케이션 릴레이 및 상태 파일
6.3.3 리플리케이션 슬레이브 SQL 쓰레드 상태
6.4. 리플리케이션 설정 방법
6.3.4 리플리케이션 릴레이 및 상태 파일
6.5. MySQL 버전간의 리플리케이션 호환성
6.4 리플리케이션 설정 방법
6.6. 리플리케이션 설정 업그레이드 하기
6.5 MySQL 버전간의 리플리케이션 호환성 6.6.1. 5.0으로 리플리케이션 업그레이드 하기
6.6 리플리케이션 설정 업그레이드 하기 6.7. 리플리케이션 기능들과 알려져 있는 문제점들
6.6.1 5.0으로 리플리케이션 업그레이드 하기 6.8. 리플리케이션 스타트업 옵션들
6.7 리플리케이션 기능들과 알려져 있는 문제점들 6.9. 서버가 리플리케이션 규칙을 얻는 방법
6.8 리플리케이션 스타트업 옵션들 6.10. 리플리케이션 FAQ
6.9 서버가 리플리케이션 규칙을 얻는 방법 6.11. 리플리케이션 문제 해결
6.10 리플리케이션 FAQ 6.12. 리플리케이션 버그와 문제점 보고하기
6.11 리플리케이션 문제 해결 6.13. 다중 마스터 리플리케이션에서 자동 인크리먼트
6.12 리플리케이션 버그와 문제점 보고하기

6.13 다중 마스터 리플리케이션에서 자동 인크리먼트
이 장에서는 MySQL이 제공하는 다양한 리플리케이션 기능들에 대해 설명하기로 한다. 리플리케이션의 개념을 소개하고, 리플
리케이션 서버를 설정하는 방법, 그리고 참고 자료로서 사용할 수 있는 옵션들에 대해 설명을 할 것이다. 또한 FAQ를 답과 함께
보여주고, 리플리케이션 문제를 해결할 수 있는 방안등에 대해서도 제공을 하기로 하겠다.

:::MySQL Korea:::
리플리케이션 관련 SQL명령문 신텍스에 대한 보다 자세한 사항은, Section 13.6, “리플리케이션 명령문”을 참조하기 바란다.

:::MySQL Korea:::
제목검색
6.1. 리플리케이션 소개
MySQL의 기능들은 한 방향, 즉 비동기 리플리케이션(asynchronous replication)을 지원하는데, 하나의 서버는 마스터로 동작하
6.1. 리플리케이션 소개
고, 나머지 한 개 이상의 다른 서버들은 슬레이브로 동작한다. 이것은 MySQL클러스터의 특징인 동기화된(synchronous) 리플리
6.1 리플리케이션 소개
케이션과는 반대되는 개념이다.( Chapter 15, MySQL 클러스터)를 참조할 것.
싱글-마스터 리플리케이션에서, 마스터 서버는 업데이트를 자신의 바이너리 로그 파일들에 작성을 하고 로그 로테이션의 트레이
스(trace)를 유지하기 위해 이 파일들의 인덱스를 유지 관리 한다. 바이너리 로그 파일들은 다른 슬레이브 서버에 보내어지는 업데
이트 레코드 역할을 한다. 슬레이브가 자신의 마스터에 연결이 될 때, 슬레이브는 마스터의 정보를 자신이 마지막으로 업데이트가
성공했을 때 읽었던 로그에 전달한다. 슬레이브는 그 시간 이후에 발생한 모든 사항에 대한 업데이트를 전달 받고, 그 다음에는 블
록(block)을 한 후에 마스터가 새로운 업데이트를 알려 주기를 기다리게 된다.
슬레이브 서버는, 여러분이 체인드 리플리케이션 서버(chained replication server)로 설정을 하게 되면, 자신이 마스터의 역할을
하게 된다.
다중-마스터(Multiple-master) 리플리케이션은 가능 하기는 하지만, 싱글-마스터 리플리케이션에서는 발생하지 않는 문제들이

나타나게 된다. Section 6.13, “다중 마스터 리플리케이션에서 자동 인크리먼트”를 참조.
리플리케이션을 사용할 때에는, 리플리케이트된 테이블에 대한 모든 업데이트는 마스터 서버에서 실행 되어야 한다. 그렇지 않으
면, 여러분은 사용자가 마스터에 있는 테이블에서 행하는 업데이트와 슬레이브에서 행하는 업데이트간의 충돌을 피하도록 항상 주
의해야만 한다.
리플리케이션은 견고성, 속도, 그리고 시스템 관리에 많은 혜택을 제공한다:
• 견고성(Robustness)은 마스터/슬레이브 설정을 가지고 증가된다. 마스터에서 문제가 발생하면, 여러분은 백업의 형
태로 슬레이브로 전환할 수 있다.

:::MySQL Korea:::
• 마스터와 슬레이브 서버간에 클라이언트 쿼리 처리를 분산함으로써 클라이언트에 대해 보다 개선된 응답 시간을 제

공해 줄 수 있다. 슬레이브에 SELECT 쿼리들을 전달해서 마스터의 쿼리 처리 업무를 줄여 줄 수 있다. 마스터와 슬레이
브의 동기화가 끊어지지 않도록 하기 위해 데이터를 수정하는 명령문들은 여전히 마스터에 전달 된다. 이러한 로드 밸런
싱 전략은 업데이트 하지 않는(non-updating)쿼리가 압도적으로 많은 경우에는 효과적이지만, 그것은 일반적인 경우이
다.
• 리플리케이션 사용의 다른 이점은 여러분이 마스터의 방해 없이 슬레이브 서버를 사용해서 데이터베이스 백업을 실
행할 수 있다는 것이다. 마스터는 백업이 진행되는 동안에도 업데이트 프로세스를 계속 한다.Section 5.10.1, “데이터 베
이스 백업”을 참조할 것.

:::MySQL Korea:::
제목검색
6.2. 리플리케이션 구현 개론
MySQL 리플리케이션은 마스터 서버의 바이너리 로그에 있는 여러분의 데이터 베이스에 대한 모든 변경(업데이트, 삭제, 등등) 사
6.2. 리플리케이션 구현 개론
항에 대한 마스터 서버 유지 트랙(master server keeing track)에 기초를 하고 있다. 따라서, 리플리케이션을 사용하기 위해서
6.2 리플리케이션 구현 개론
는, 마스터 서버에 있는 바이너리 로깅을 활성화 시켜야 한다. Section 5.12.3, “바이너리 로그”를 참고할 것.
각 슬레이브 서버는 마스터 서버가 자신의 바이너리 로그에 기록해둔 업데이트 사항을 전달 받게 되는데, 따라서 슬레이브는 데이
터 복사본에서 동일한 업데이트를 실행할 수 있게 된다.
바이너리 로그는 단순히 여러분이 바이너리 로깅을 활성화 시킨 시점부터 시작된 기록에 불과하다는 것을 이해하는 것이 절대적으
로 중요하다. 여러분이 설정한 모든 슬레이브는 여러분이 마스터 서버에서 바이너리 로깅을 활성화 시켰던 시점에 존재 했던 것처
럼 마스터 서버에 데이터 베이스의 복사본을 필요로 한다. 만약에 바이너리 로그가 시작될 때 마스터에 있었던 것과 같은 상태의 데
이터 베이스가 아닌 다른 것을 가지고 슬레이브를 시작한다면, 여러분은 슬레이브 구동에 실패를 할 것이다.
마스터의 데이터를 슬레이브로 복사하는 한 가지 방법은 LOAD DATA FROM MASTER 명령문을 사용하는 것이다. 하지만,
LOAD DATA FROM MASTER는 마스터에 있는 모든 테이블이 MyISAM 스토리지 엔진을 사용할 때에만 제대로 동작한다. 부가
적으로, 이 명령문은 글로벌 읽기 잠금(read lock)을 갖게 되는데, 따라서 테이블이 슬레이브로 전달되는 동안에는 마스터에서는
어떠한 업데이트도 할 수 없게 된다. 우리가 잠금 –면제 핫 테이블(lock-free hot table) 백업을 실행할 때에는, 이 글로벌 읽기
잠금 기능은 더 이상 필요 없게 된다.
이러한 제약으로 인해, 우리는 여러분이 마스터에 있는 데이터 셋이 상대적으로 작거나, 또는 마스터에서 연기된 읽기 잠금이 수용
될 때에만 LOAD DATA FROM MASTER를 사용하기를 권장한다. 비록 LOAD DATA FROM MASTER의 실제 속도가 시스템
에 따라 다양하다고 하더라도, 경험적으로는 1MB의 데이터 당 1초가 걸린다. 이것은 대략적인 측정값이지만, 마스터와 슬레이브
가 둘 다 동일하게700MHz 팬티엄 CPU를 가지고 있고 100Mbps 네트워크에 연결되어 있는 경우에 거의 정확하다는 것을 알게
될 것이다.

:::MySQL Korea:::
슬에이브가 마스터의 데이터 복사본을 가지고 설정이 된 후에는, 슬레이브는 마스터에 접속을 하고 업데이트가 진행되기를 기다리
게 된다. 만약에 마스터가 실패(fail)를 하면, 또는 슬레이브가 마스터와 접속이 끊어지게 되면, 슬레이브는 업데이트에 대한 정보
를 다시 들을 수 있을 때까지 주기적으로 접속을 시도하게 된다. --master-connect-retry 옵션은 재시도 간격을 제어한다. 디
폴트 값은 60초이다.
각 슬레이브는 자신의 마스터로부터 마지막으로 업데이트를 읽었을 때 어디에서 중단 되었는지에 대한 트랙을 유지한다. 마스터는
자신이 얼마나 많은 슬레이브를 가지고 있는지 또는 어느 것이 주어진 시간에서 갱신 되었는지 알지 못한다.

:::MySQL Korea:::
제목검색
6. 리플리케이션 6.3.1. 리플리케이션 마스터 쓰레드 상태
6.3. 리플리케이션 구현 상세 설명 6.3.2. 리플리케이션 슬레이브 I/O 쓰레드 상태
6.3 리플리케이션 구현 상세 설명 6.3.3. 리플리케이션 슬레이브 SQL 쓰레드 상태

MySQL 리플리케이션은 세개의 쓰레드를 사용해서 구현된다 (하나는 마스터에서 구현되며 나머지 두개는 슬레이브에서 구현된
다). START SLAVE 명령문이 슬레이브 서버에 입력되면, 슬레이브 서버는 하나의 I/O 쓰레드를 생성하는데, 이 쓰레드는 마스터
에 접속하여 마스터 바이너리 로그에 기록되어 있는 업데이트 사항을 요청한다. 마스터는 쓰레드를 하나 생성해서 바이너리 로그
의 내용을 슬레이브에 보낸다. 이 쓰레드는 마스터 서버에서 실행되는 SHOW PROCESSLIST의 결과에 있게 되는 Binlog Dump
쓰레드 형태로 알아볼 수 있다. 슬레이브 I/O 쓰레드는 마스터 Binlog Dump 쓰레드가, 릴레이 로그 라고 알려져 있고 슬레이브의
데이터 디렉토리에 저장 되어 있는, 로컬 파일로 보내서 복사본을 만드는 업데이트 내용을 읽는다. 세 번째 쓰레드는 SQL 쓰레드이
며, 이것은 슬레이브가 릴레이 로그를 읽고 그 안에 있는 것들을 실행하기 위해 생성하는 쓰레드이다.
앞에서 설명을 하였듯이, 마스터/슬레이브 연결마다 세 개의 쓰레드가 있게 된다. 여러 개의 슬레이브를 가지고 있는 하나의 마스터
는 현재 접속되어 있는 각각의 슬레이브별로 하나의 쓰레드를 생성하고, 그리고 가가 슬레이브는 자신들만의 I/O 와 SQL 쓰레드들
을 가지게 된다.
슬레이브는 마스터에서 업데이트된 것을 읽고 이것들을 실행시키기 위해 서로 별도의 일을 처리하는 두 개의 쓰레드를 사용한다.

따라서, 명령문을 읽는 업무는, 설사 명령문을 실행하는 속도가 느리다고 하더라도, 느려 지지 않는다. 예를 들면, 슬레이브 서버가
한동안 구동 되지 않았다면, 이 슬레이브의 I/O쓰레드는, 비록 SQL쓰레드의 속도가 꽤 느리다고 하더라도, 슬레이브가 구동될 때
마스터로부터 재빠르게 모든 바이너리 로그의 내용물을 읽게 된다. 만약에 SQL쓰레드가 읽어온 모든 명령문을 실행하기 전에 슬레
이브 서버가 멈추게 된다면, I/O 쓰레드는 명령문의 안전한 복사본이 슬레이브의 릴레이 로그에 로컬로 저장이 되고, 슬레이브가 다
시 구동될 때 실행을 계속할 수 있도록 하기 위한 최소한의 것들을 갖게 된다. 이것은 마스터 서버가 자신의 바이너리 로그를 잠시
후에 깨끗이 지울 수 있게 만드는데, 왜냐하면 마스터는 더 이상 슬레이브가 자신의 업데이트를 읽도록 기다릴 필요가 없기 때문이

:::MySQL Korea:::
다.
SHOW PROCESSLIST 명령문은 리플리케이션에 관련하여 마스터와 슬레이브 서버에서 어떤 일이 있었는지를 보여 준다. 아래
의 SHOW PROCESSLIST 명령문의 결과에서 세 개의 쓰레드가 어떻게 보여지는지를 나타내고 있다.
마스터 서버에서는, SHOW PROCESSLIST의 결과는 아래처럼 보인다:
mysql> SHOW PROCESSLIST￦G
*************************** 1. row ***************************
Id: 2
User: root
Host: localhost:32931
db: NULL
Command: Binlog Dump
Time: 94
State: Has sent all binlog to slave; waiting for binlog to
be updated
Info: NULL
여기에서, 쓰레드 2는 연결된 슬레이브에 대한 Binlog Dump 리플리케이션 쓰레드이다. State 정보는 모든 업데이트 사항이 슬레
이브에 전달 되었으며 마스터는 다른 업데이트가 발생하는 것을 대기하고 있다는 점을 설명하는 것이다. 여러분이 마스터 서버에
서 아무런 Binlog Dump 쓰레드도 보지 못한다면, 이것은 리플리케이션이 구동 되지 않고 있음을 의미하는 것이다 — 즉, 현재 어떠

:::MySQL Korea:::
한 슬레이브로 연결되어 있지 않다.
슬레이브 서버에서는, SHOW PROCESSLIST의 실행 결과는 다음과 같다:
mysql> SHOW PROCESSLIST￦G
*************************** 1. row ***************************
Id: 10
User: system user
Host:
db: NULL
Command: Connect
Time: 11
State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 11
User: system user
Host:

:::MySQL Korea:::
db: NULL
Command: Connect
Time: 11
State: Has read all relay log; waiting for the slave I/O
thread to update it
Info: NULL
이 정보는 쓰레드 10이 마스터 서버와 통신을 하는 I/O 쓰레드이고, 그리고 쓰레드 11은 릴레이 로그에 저장되어 있는 업데이트 사
항을 실행하는 SQL 쓰레드라는 것을 알려 준다. SHOW PROCESSLIST 이 실행 되었을 때에는, 양쪽 쓰레드 모두 아이들(idle)
상태였으며, 또 다른 업데이트를 기다리고 있는 중이었다.
Time 컬럼에 있는 값은 슬레이브가 마스터에 비교해서 얼마나 늦는지를 알려주는 것이다. Section 6.10, “리플리케이션
FAQ”를 참조할 것.

:::MySQL Korea:::
제목검색
6.3.1. 리플리케이션 마스터 쓰레드 상태
아래의 리스트는 마스터 서버의 Binlog Dump 쓰레드에 대해 State 컬럼에서 여러분이 볼 수 있는 가장 일반적인 상태를 보여준
다. 마스터 서버에서 아무런 Binlog Dump 쓰레드를 보지 못한다면, 리플리케이션은 구동 되지 않는 것이다- 즉, 어떠한 슬레이브
서버도 연결이 되어 있지 않다는 것이다.
• Sending binlog event to slave
바이너리 로그는 이벤트(events)들로 구성되는데, 하나의 이벤트는 일반적으로 여러 개의 정보를 가지고 있는 하나의 업
데이트 항목이 된다. 쓰레드는 바이너리 로그에서 이벤트를 읽었으며 이제 이것을 슬레이브에 전달한다.
• Finished reading one binlog; switching to next binlog
쓰레드는 바이너리 로그를 읽는 것을 마쳤고 이제는 슬레이브에 보낼 바로 다음 이벤트를 열고 있다.
• Has sent all binlog to slave; waiting for binlog to be updated
쓰레드는 모든 업데이트 항목을 바이너리 로그에서 읽었으며 그것들을 슬레이브에 전달했다. 쓰레드는 현재 아이들(idle)
상태이며, 마스터에서 새로운 업데이트가 발생해서 바이너리 로그에 새로운 이벤트가 나타나기를 기다리고 있는 상태이
다.
• Waiting to finalize termination
쓰레드가 종료했을 때 매우 짧게 나타나는 상태
:::MySQL Korea:::
제목검색
6.3.2. 리플리케이션 슬레이브 I/O 쓰레드 상태
아래의 리스트는 슬레이브 서버의 I/O 쓰레드에 대해 State 컬럼에서 여러분이 볼 수 있는 가장 일반적인 상태를 설명하는 것이다.
이 상태는 SHOW SLAVE STATUS를 통해서 볼 수 있는 Slave_IO_State 컬럼에서도 나타날 수도 있다. 따라서 이 명령문을 사
용하면, 여러분은 어떤 일이 일어났는지에 대해서 유익한 정보를 얻을 수 있게 된다.
• Connecting to master
쓰레드는 마스터에 접속을 시도하고 있다.
• Checking master version
마스터에 접속이 된 후에 매우 짧게 나타나는 상태.
• Registering slave on master
마스터에 접속이 된 후에 매우 짧게 나타나는 상태.
• Requesting binlog dump
마스터에 접속이 된 후에 매우 짧게 나타나는 상태. 쓰레드는 바이너리 로그의 파일 이름과 위치를 가지고, 바이너리 로그
의 내용물에 대한 요청을 마스터에 보낸다.
• Waiting to reconnect after a failed binlog dump request
바이너리 로그 덤프가 실패할 경우(접속 불가로 인해), 쓰레드는 곧장 이 상태가 되며, 그 다음에는 주기적으로 재 접속을
시도하게 된다. 재시도 간격은 --master-connect-retry 옵션을 가지고 지정할 수가 있다.
• Reconnecting after a failed binlog dump request
쓰레드는 마스터에 재 접속을 시도한다.
• Waiting for master to send event
쓰레드는 마스터에 접속이 되었고 바이너리 로그 이벤트가 도착 하기를 기다린다. 이것은 마스터가 아이들 상태일 경우에

:::MySQL Korea:::
는 시간이 오래 걸린다. 만약에 대기 시간이 slave_read_timeout 시간이 된다면, 시간 초과(timeout)이 발생한다. 그런

경우가 된다면, 쓰레드는 마스터와의 연결이 단절되었다고 생각을 하며 재 접속을 시도한다.
• Queueing master event to the relay log
쓰레드는 이벤트를 읽었고 이것을 릴레이 로그에 복사를 해서 SQL 쓰레드가 이 이벤트를 처리하게끔 한다.
• Waiting to reconnect after a failed master event read
이벤트를 읽는 도중에 발생된 에러(접속 단절로 인해). 쓰레드는 재접속을 시도하기 전에 master-connect-retry 시간
동안 대기(sleeping)를 한다.
• Reconnecting after a failed master event read
쓰레드는 마스터에 재 접속을 시도한다. 접속이 다시 이루어지게 되면, 상태는 Waiting for master to send event 가 된
다.
• Waiting for the slave SQL thread to free enough relay log space
여러분은 0(zero)가 아닌 relay_log_space_limit 값을 사용하는 중이며, 그리고 릴레이 로그의 크기는 이 값을 초과할 만
큼 충분이 커져 있다. I/O 쓰레드는 SQL 쓰레드가 릴레이 로그 파일 중에 일부를 삭제해서 충분한 공간을 확보하지 않으
면 계속 대기를 한다.
• Waiting for slave mutex on exit
쓰레드가 멈추었을 때 매우 짧게 발생하는 상태.

:::MySQL Korea:::
제목검색
6.3.3. 리플리케이션 슬레이브 SQL 쓰레드 상태
아래의 리스트는 슬레이브 서버의 SQL 쓰레드에 대해 State 컬럼에서 가장 일반적으로 볼 수 있는 상태를 설명한다:

• Reading event from the relay log
쓰레드는 릴레이 로그에서 이벤트를 하나 읽었으며 이것을 처리할 수가 있다.
• Has read all relay log; waiting for the slave I/O thread to update it
쓰레드는 릴레이 로그 파일에 있는 모든 이벤트를 처리하였고, 이제는 I/O쓰레드가 새로운 이벤트들을 릴레이 로그에 작
성하기를 기다리고 있다.
• Waiting for slave mutex on exit
쓰레드가 멈추었을 때 매우 짧게 나타나는 상태.
I/O 쓰레드에 대한 State 컬럼은 명령문 문장도 함께 보여 준다. 이것은 쓰레드가 릴레이 로그로부터 하나의 이벤트를 읽었으며, 거
기에서 명령문을 추출했고, 그리고 그 명령문을 실행했다는 것을 가리킨다.
:::MySQL Korea:::
제목검색
디폴트로는, 릴레이 로그 파일 이름은 host_name-relay-bin.nnnnnn 형식을 가지며, 여기에서 host_name 는 슬레이브 서버의
이름이 되고 nnnnnn 은 시퀀스 번호가 된다. 000001으로 시작해서, 연속적인 시퀀스 번호를 사용해서 연속적인 릴레이 로그 파일
들이 생성된다. 슬레이브는 현재 사용중에 있는 릴레이 로그 파일들을 추적하기 위해 하나의 인덱스를 사용한다. 디폴트 릴레이 로
그 인덱스 파일 이름은 host_name-relay-bin.index이다. 디폴트로는, 슬레이브 서버는 자신의 데이터 디렉토리에 릴레이 파일
을 생성한다. 디폴트 파일 이름은 --relay-log 와 --relay-log-index 서버 옵션을 가지고 덮어 쓸 수가 있다. Section 6.8,
“리플리케이션 스타트업 옵션들”을 참조할 것.
릴레이 로그는 바이너리 로그와 동일한 포맷을 갖고 mysqlbinlog를 사용해서 읽을 수가 있다. SQL 쓰레드는 릴레이 로그 파일 안
에 있는 모든 이벤트들이 처리가 되고 더 이상 그 파일이 필요가 없게 되면 즉시 자동으로 각 릴레이 로그 파일을 삭제한다. SQL 쓰
레드는 이러한 삭제 동작을 매우 조심스럽게 진행하기 때문에 릴레이 로그 파일을 삭제하는 데에는 명백한 메커니즘이 존재하지 않
는다. 하지만, FLUSH LOGS 는 릴레이 로그를 로테이트(rotate) 시키는데, 이것은 SQL 쓰레드가 이 파일들을 삭제하는 시기에
영향을 미친다.
슬레이브 서버는 아래의 조건 아래에서 새로운 릴레이 로그 파일을 생성한다:
• /O 쓰레드가 시작될 때마다.
• 로그가 플러시 될 때; 예를 들면, FLUSH LOGS 또는 mysqladmin flush-logs가 실행될 때.
• 현재 로그 파일의 크기가 너무 커질 때. “너무 크다(too large)” 의 의미는 아래와 같이 판단된다:
o 만일 max_relay_log_size의 값이 0보다 크면, 그 값이 릴레이 로그 파일의 최대 크기가 된다.
o 만일 max_relay_log_size의 값이 0이면, max_binlog_size가 릴레이 로그 파일의 최대 크기가 된다.
슬레이브 리플리케이션 서버는 데이터 디렉토리에 두 개의 작은 파일을 추가로 생성을 한다. 이 상태 파일들은 디폴트로 master.
info 와 relay-log.info라고 이름되어 있다. 이것들의 이름은 --master-info-file 와 --relay-log-info-file 옵션으로 바꿀

:::MySQL Korea:::
수가 있다. Section 6.8, “리플리케이션 스타트업 옵션들”을 참조할 것.
이러한 두 상태 파일들은 Section 13.6.2, “슬레이브 서버를 제어하기 위한 SQL 명령문”에서 설명을 하는 SHOW SLAVE
STATUS 명령문의 결과에서 볼 수 있는 정보를 가지고 있다. 상태 파일들은 디스크에 저장이 되기 때문에, 슬레이브 서버가 셧 다
운 되더라도 계속 존재를 하게 된다. 슬레이브가 시작되는 다음 시점에, 슬레이브 서버는 마스터에서 바이너리 로그를 어디까지 읽
었는지 그리고 자신의 릴레이 로그가 어디까지 진행이 되었는지를 알아보기 위해 이 파일들을 읽게 된다.
I/O 쓰레드는 master.info 파일을 갱신한다. 아래의 테이블에서는 그 파일에 있는 라인에 대응하여 SHOW SLAVE STATUS가
출력하는 컬럼의 상관 관계를 나타내고 있다.
Line Description
1 Number of lines in the file
2 Master_Log_File
3 Read_Master_Log_Pos
4 Master_Host
5 Master_User
6 Password (not shown by SHOW SLAVE STATUS)
7 Master_Port
8 Connect_Retry
9 Master_SSL_Allowed
10 Master_SSL_CA_File
11 Master_SSL_CA_Path
12 Master_SSL_Cert
13 Master_SSL_Cipher
14 Master_SSL_Key
SQL 쓰레드는 relay-log.info 파일을 갱신한다. 아래의 테이블에서는 그 파일에 있는 라인에 대응하여 SHOW SLAVE STATUS

:::MySQL Korea:::
가 출력하는 컬럼의 상관 관계를 나타내고 있다.
Line Description
1 Relay_Log_File
2 Relay_Log_Pos
3 Relay_Master_Log_File
4 Exec_Master_Log_Pos
여러분이 슬레이브의 데이터를 백업할 때에는, 릴레이 로그 파일과 더불어 이 두 파일들도 함께 백업을 받도록 해야 한다. 이 파일
들은 여러분이 슬레이브의 데이터를 다시 읽어 온후에 리플리케이션을 재 구동 시키기 위해 필요한 것 들이다. 만일 여러분이 릴레
이 로그는 잃어버렸지만 relay-log.info 파일은 여전히 가지고 있다면, 이것을 가지고 SQL 쓰레드가 마스터 바이너리 로그에서 얼
마나 진행이 되었는지를 알아볼 수가 있게 된다. 그런 다음에 여러분은 Then you can use with the MASTER_LOG_FILE 과
MASTER_LOG_POS 옵션과 함께 CHANGE MASTER TO를 사용해서 슬레이브로 하여금 그 시점에서 바이너리 로그를 다시 읽
어 오도록 할 수가 있다. 물론, 이것은 바이너리 로그가 여전히 마스터 서버에 있어야 한다는 것을 전제로 한다.
만일 슬레이브가 LOAD DATA INFILE 명령문을 리플리케이션 하는 것과 관련이 있다면, 슬레이브가 이러한 목적으로 사용하는
디렉토리에 있는 모든 SQL_LOAD-* 파일들도 함께 백업을 해 두어야 한다. 슬레이브는 이 파일들을 가지고 인터럽트를 당한
LOAD DATA INFILE의 리플리케이션을 다시 진행한다. 디렉토리의 위치는 --slave-load-tmpdir 옵션을 사용해서 지정할 수
가 있다. 만일 이 옵션을 지정하지 않으면, 디렉토리의 위치는 tmpdir 시스템 변수의 값이 된다.

:::MySQL Korea:::
제목검색
상위
6.4. 리플리케이션 설정 방법
메뉴리스
트◆ 이 섹션에서는 MySQL 서버의 전체 리플리케이션을 설정하는 방법에 대해 간략히 설명을 하기로 한다. 여러분은 마스터 서버에 있는 모든 데이터 베이스를 복제 하고자 한다는 가정을 한다. 여기
에서 설명하고 있는 단계를 완료하기 위해서는 서버를 셧 다운 시켜야 한다.
6.
리플
리케 여기의 과정은 단일 슬레이브를 설정하는 것에 대한 것이지만, 여러분은 이 과정을 반복 사용하면 여러 대의 슬레이브로 설정을 할 수가 있게 된다.
이션
비록 이 방법이 가장 간단한 방법이기는 하지만, 유일한 방법을 아니다. 예를 들면, 만일 여러분이 마스터 서버의 데이터에 대한 스냅샷(snapshot)을 가지고 있고, 마스터가 이미 자신의 ID 셋을
6.4.
리플 가지고 있으며 바이너리 로깅을 활성화 시켰다면, 여러분은 마스터 서버를 셧 다운 시키거나 또는 업데이트에 대한 블로킹을 하지 않은 상태로도 슬레이브를 설정할 수가 있다. 보다 자세한 사항
리케 은 Section 6.10, “리플리케이션 FAQ”을 참조할 것.

이
션 만약에 여러분이 MySQL 리플리케이션 설정을 관리하고자 한다면, 이 장에 있는 모든 내용을 잘 숙지할 것과 Section 13.6.1, “마스터 서버를 제어하기 위한 SQL 명령문”, 및
설 Section 13.6.2, “슬레이브 서버를 제어하기 위한 SQL 명령문”에서 언급하고 있는 모든 명령문을 모두 실행해 보기를 권장한다. 또한, 여러분은 Section 6.8, “리플리케이션 스타트업 옵션
정
들”에서 설명하고 있는 리플리케이션 스타트업 옵션들에 대해서도 잘 다룰 수가 있어야 한다.
방법
6.4 리플 Note: 여기에서 설명하고 있는 과정 및 다음의 섹션에 나오는 여러 가지의 리플리케이션 SQL 명령문들은 SUPER 권한이 있어야 한다.
리케
이
1. 마스터와 슬레이브에 설치되어 있는 MySQL 버전이 Section 6.5, “MySQL 버전간의 리플리케이션 호환성”에 나와 있는 테이블과 서로 호환성을 가지고 있는지 확인한다. 가장
션
이상적인 것은, 마스터와 슬레이브가 가장 최신의 버전을 사용하는 것이다.
설
정 2. 슬레이브 서버가 접속을 해서 사용할 수 있는 계정을 마스터에 하나 생성한다. 이 계정은 반드시 REPLICATION SLAVE 권한을 가지고 있어야 한다. 만일 그 계정이 리플리케이션
방법 만을 위해 사용된다면(권장 사항임), 다른 권한들은 그 계정에 줄 필요가 없다.
여러분이 사용하는 도메인은 mydomain.com이며 이 도메인에 있는 어떠한 호스트에서도 접속할 수 있는 계정을 repl라는 이름과 slavepass라는 패스워드를 갖도록 생성한다고 가정하
자. 이 계정을 생성하기 위해서는, 아래의 GRANT 명령문을 사용한다:
mysql> GRANT REPLICATION SLAVE ON *.*
-> TO 'repl'@'%.mydomain.com' IDENTIFIED BY 'slavepass';
만일 여러분이 슬레이브 호스트에서 LOAD TABLE FROM MASTER 또는 LOAD DATA FROM MASTER 명령문을 사용할 계획이라면, 이 계정에 추가적인 권한을 승인해야 한다:

:::MySQL Korea:::
• 계정이 SUPER 와 RELOAD 글로벌 권한을 승인한다.
• 여러분이 읽어 오길 원하는 모든 테이블에 대해 SELECT 권한을 승인한다. 이 계정이 SELECT할 수 없는 모든 마스터 테이블은 LOAD DATA FROM MASTER에 의해
무시될 것이다.
사용자 계정 및 권한 설정에 대한 추가적인 내용은 Section 5.9, “MySQL 사용자 계정 관리”를 참조한다.
3. 모든 테이블을 플러시하고 FLUSH TABLES WITH READ LOCK 명령문을 실행해서 쓰기 명령문을 막도록(block) 한다:
4. mysql> FLUSH TABLES WITH READ LOCK;
InnoDB 테이블의 경우, FLUSH TABLES WITH READ LOCK 명령문은 COMMIT 동작도 막는다는 것을 알아두자. 여러분이 글로벌 읽기 잠금(lock)을 가지게 될 때, 여러분 자신의
InnoDB 테이블에 대한 파일 시스템 스냅샷을 시작할 수가 있게 된다. 내부적으로는 (InnoDB 스토리지 엔지 내부에서는) 스냅샷은 일관되게 유지가 되지 않지만 (InnoDB 캐시는 플러
시되지 않기 때문에), 이것은 염려할 사항이 되지 않는데, 왜냐하면 InnoDB는 이것을 스타트업 시점에 해석을 하고 일관된 값을 전달하기 때문이다. 이것은 InnoDB가 이 스냅샷에서 시
작될 때 아무런 충돌 없이 크래시 복구(crash recovery)를 수행할 수 있다는 것을 의미한다. 하지만, InnoDB 테이블의 스냅샷을 일관성 있게 유지하는 동안 MySQL 서버를 종료할 수
는 없다.
여러분이 FLUSH TABLES 명령문을 입력하는 클라이언트를 구동 상태로 두어서 읽기 잠금이 계속 유지되도록 한다. (만일 클라이언트를 종료하면, 읽기 잠금은 해제되어 버린다.) 그
런 다음에 마스터 서버에 있는 데이터의 스냅샷을 한다.
스냅샷을 생성하는 가장 쉬운 방법은 마스터 데이터 디렉토리에 있는 데이터 베이스의 바이너리 백업을 만드는 아카이빙(archiving) 프로그램을 사용하는 것이다. 예를 들면, 유닉스에
서는 tar, 또는 윈도우에서는 PowerArchiver, WinRAR, WinZip등과 유사한 소프트웨어를 사용하는 것이다. 모든 데이터 베이스를 포함하고 있는 아카이브를 만들기 위한 tar를 사용하
기 위해서는, 마스터 서버의 데이터 디렉토리로 이동을 한 다음에, 아래의 명령어를 실행한다:
shell> tar -cvf /tmp/mysql-snapshot.tar .
만일If you want the archive to include only a database called this_db라는 이름의 데이터 베이스만 아카이브에 포함시키고자 한다면, 아래의 명령어를 사용한다:
shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db
그런 다음에 슬레이브 서버 호스트에 있는 /tmp 디렉토리로 아카이브 파일을 복사한다. 슬레이브 호스트에서, 데이터 디렉토리로 위치를 변경한 다음에, 아래의 명령어를 사용해서 아카
이브 파일을 푼다:
shell> tar -xvf /tmp/mysql-snapshot.tar
만약에 슬레이브 서버가 마스터에 있는 사용자 계정 셋과 다른 것을 가지고 있다면, 여러분은 mysql 데이터 베이스를 복제하고 싶지 않을 수도 있을 것이다. 이와 같은 경우, 여러분은 아
카이브에서 이것을 제외 시킨다. 또한 아카이브에 로그 파일, master.info 또는 relay-log.info 파일을 포함시키고 싶지 않을 수도 있을 것이다.
FLUSH TABLES WITH READ LOCK에 의한 읽기 잠금이 효력을 가지고 있는 동안에는, 마스터 서버에 있는 오프셋과 현 바이너리 로그 이름 값을 읽는다:

:::MySQL Korea:::
mysql > SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| mysql-bin.003 | 73 | test | manual,mysql |
+---------------+----------+--------------+------------------+
File 컬럼은 로그의 이름을 보여주며 Position은 파일 안에 있는 오프셋(offset)을 보여준다. 이 예제에서 보면, 바이너리 로그 파일은 mysql-bin.003이며 오프셋은 73이 된다. 이 값들
을 기록해 둔다. 여러분이 슬레이브를 설정할 때 이 값들이 필요하게 된다. 이 값들은 슬레이브가 마스터에서 새로운 업데이트를 진행할 때의 리플리케이션의 위치를 표시한다.
만일 바이너리 로깅이 활성화 되기 전에 마스터가 구동이 되었다면, SHOW MASTER STATUS 또는 mysqldump --master-data가 출력하는 로그 이름과 위치 값은 비어 있게 된
다. 그와 같은 경우, 여러분이 나중에 슬레이브의 로그 파일과 위치를 지정할 때 사용하는 값들은 빈 스트링 ('') 및 4가 된다.
여러분이 스냅샷을 만들고 로그 이름과 오프셋을 가진 후에는, 마스터 서버상에서 쓰기를 다시 활성화 시킬 수가 있게 된다:
mysql> UNLOCK TABLES;
여러분이 InnoDB 테이블을 사용할 경우, 가장 좋은 방법은 InnoDB Hot Backup 툴을 사용하는 것인데, 이것은 마스터 서버상에서 어떠한 잠금도 하지 않은 채 일관된 스냅샷을 만들 수
가 있으며, 나중에 슬레이브에서 사용될 스냅샷에 대응하는 로그 이름과 오프셋을 기록할 수가 있게 된다. Hot Backup은 유료(non-free) 툴이며 표준 MySQL 배포판에는 포함되어 있
지 않다. InnoDB Hot Backup의 홈페이지에서 보다 자세한 내용을 참조하기 바란다. http://www.innodb.com/manual.php
Hot Backup 툴을 사용하지 않는 상태에서, InnoDB 테이블의 바이너리 스냅샷을 만드는 가장 빠른 방법은 마스터 서버를 셧 다운 한 다음에 InnoDB 데이터 파일, 로그 파일, 그리고 테
이블 포맷 파일 (.frm 파일)을 복사하는 것이다. 현 로그 파일과 오프셋을 기록하기 위해서는, 서버를 셧 다운하기 전에 아래의 명령문을 실행한다:
mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;
이렇게 하면 SHOW MASTER STATUS의 결과로 위에서 본 것과 같은 로그 이름과 오프셋을 얻을 수가 있게 된다. 로그 이름과 오프셋을 기록한 다음에, 서버가 현 로그 파일과 오프셋
에 대응하는 스냅샷을 가지고 종료하도록 하기 위해 테이블을 잠그지 않는 상태로 서버 셧 다운을 한다:
shell> mysqladmin -u root shutdown

:::MySQL Korea:::
An alternative that works for both MyISAM 과 InnoDB 테이블 양쪽 모두에서 실행시킬 수 있는 다른 방법으로는 위에서 설명한 대로 바이너리를 복사하는 것 대신에 마스터 서버의
SQL 덤프를 하는 것이다. 이렇게 하기 위해서는, 마스터 상에서 mysqldump --master-data 를 사용하고 나중에 슬레이브로 SQL 덤프를 로드한다. 하지만, 이것은 바이너리 복사보
다는 실행 속도가 느리다.
5. 마스터 호스트에 있는 my.cnf 파일의 [mysqld] 섹션이 log-bin 옵션을 가지도록 한다. 이 섹션은 또한 server-id=master_id 옵션도 가지고 있어야 하며, master_id는 1 에서
232 – 1 사이의 양수 정수 값을 가져야 한다. 예를 들면 :
6. [mysqld]
7. log-bin=mysql-bin
8. server-id=1
만약에 이러한 옵션들이 존재하지 않으면, 이것들을 추가하고 서버를 다시 구동 시킨다. 서버는 바이너리 로깅이 활성화 되기 전 까지는 리플리케이션 서버 역할을 하지 못한다.
Note: 트랜젝션과 함께 For the greatest possible durability and consistency in a replication setup using InnoDB를 사용하는 리플리케이션 설정에서 일관성을 가장 확실하게 유
지하기 위해서는, 마스터 서버의 my.cnf 파일에 innodb_flush_log_at_trx_commit=1, sync_binlog=1, 그리고, MySQL 5.0.3 이전 버전의 경우에는, innodb_safe_binlog를 설정한
다.. (5.0.3 이후 버전에서는 innodb_safe_binlog가 필요 없게 된다.)
9. 슬레이브로 사용될 서버를 종료하고 아래의 라인을 my.cnf 파일에 추가한다:
10. [mysqld]
11. server-id=slave_id
slave_id 값은, master_id 값과 비슷하게, 1 에서 232 – 1 사이의 양수 정수 값을 가져야 한다. 또한, 슬레이브의 ID는 마스터의 ID와 서로 달라야 한다. 예를 들면:
[mysqld]
server-id=2
만일 여러분이 여러 대의 슬레이브를 설정한다면, 각각의 슬레이브는 반드시 마스터 서버 및 다른 슬레이브와는 틀린 고유의 server-id 값을 가져야 한다. server-id 값을 IP 주소 값
과 유사하게 생각하면 된다: 이러한 ID는 리플리케이션 파트너 집단에서 각 서버의 인스턴스를 개별적으로 구분해 준다.
만일 여러분이 server-id 값을 지정하지 않으면, 정의된 master-host가 있으면 2로 설정되고, 없으면 1로 설정된다. server-id를 생략하게 되면, 마스터는 모든 슬레이브에서 오는 접
속을 거절하게 된다는 점을 알아두자. 따라서, server-id는 바이너리 로그를 사용하는 백업일 경우에만 생략하는 것이 좋다.
12. 만약에 마스터 서버의 데이터에 대해 바이너리 백업을 만들었다면, 슬레이브를 시작하기 전에 그것을 슬레이브 서버의 데이터 디렉토리에 복사를 해 둔다. 그 파일과 디렉토리에 대

:::MySQL Korea:::
한 권한이 올바르게 되어 있는지를 확인한다. 여러분이 슬레이브 서버를 구동 시키기 위해 사용하는 시스템 계정은 마스터에서와 마찬가지로 그 파일에 대해 읽기와 쓰기가 가능하도록
해 두어야 한다.
만약에 여러분이 mysqldump를 사용해서 백업을 만들었다면, 슬레이브를 먼저 시작한다. 그런 다음에 나중에 덤프 파일을 로드한다.
13. 슬레이브 서버를 시작한다. 만일 이 서버가 이전에 복제(replicating)을 했었다면, 이 서버가 마스터 서버에 곧장 접속을 시도하지 못하도록 --skip-slave-start 옵션을 사용해
서 시작을 한다. 여러분은 또한 문제(예를 들면, 네트워크 또는 접속 문제)에 대한 정보를 에러 로그에서 더 많이 얻기 위해서 --log-warnings 옵션을 사용해서 슬레이브를 시작할 수
도 있다. 이 옵션은 디폴트로 활성화 되어 있으나, 그 값이 1보다 크지 않으면 이미 종료된 접속은 에러 로그에 로그할 수가 없게 된다.
14. 만일 mysqldump를 사용해서 마스터 서버의 데이터를 백업했다면, 이 덤프 파일을 슬레이브 서버로 로드한다:
15. shell> mysql -u root -p < dump_file.sql
16. 아래의 명령문을 슬레이브 서버에서 실행하되, 옵션 값은 여러분의 시스템과 관련된 실제 값을 넣는다:
17. mysql> CHANGE MASTER TO
18. -> MASTER_HOST='master_host_name',
19. -> MASTER_USER='replication_user_name',
20. -> MASTER_PASSWORD='replication_password',
21. -> MASTER_LOG_FILE='recorded_log_file_name',
22. -> MASTER_LOG_POS=recorded_log_position;
아래의 테이블은 스트링-값 옵션에 대한 사용 가능 최대 길이를 보여 준다:
MASTER_HOST 60

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
MySQL 5.0에서 구현된 바이너리 로그 포맷은 이전 버전에서 구현된 포맷과는 매우 큰 차이가 있다. 주된 변화는 MySQL 5.0.3
(문자 셋과 LOAD DATA INFILE 처리에 대한 개선)과 5.0.4 (타임존 처리에 대한 개선)에서 구현 되었다.
6.5 MySQL 버전간의 리플리케이션 호환성
리플리케이션의 기능들은 계속 진보를 하고 있기 때문에, 가능하면 가장 최신의 MySQL 버전을 사용할 것을 권장한다. 또한, 마스
터와 슬레이브는 동일한 버전을 사용하도록 한다. 알파 또는 베타 버전을 구동하고 있는 마스터 및 슬레이브는 새로운 제품 버전을
사용하도록 권장한다. 5.0.3 마스터에서 5.0.2 슬레이브로의 리플리케이션은 실패하게 된다; 5.0.4 마스터에서 5.0.3 슬레이브로
의 리플리케이션도 역시 실패를 하게 된다. 일반적으로, MySQL 5.0.x를 구동하고 있는 슬레이브는 이것보다 이전의 버전을 사용
하고 있는 마스터와는 리플리케이션을 할 수가 있지만 (MySQL 3.23, 4.0, 또는 4.1을 구동한다고 하더라도), 그 반대의 경우는 동
작이 되지 않는다.
Note: 슬레이브 보다 신형 버전의 바이너리 로그를 사용하는 마스터에서 슬레이브로 복제를 할 수는 없다 (예를 들면, MySQL
5.0 에서MySQL 4.1로). 이것은 Section 6.6, “리플리케이션 설정 업그레이드 하기”에서 설명을 하는 것처럼, 리플리케이션 서
버에 대해 중요한 의미를 가지게 된다.
위에서 나온 정보는 프로토콜 레벨에서의 리플리케이션 호환성과 관련이 있다. 하지만, SQL-레벨 호환성 이슈와 같은 다른 제한
사항도 존재할 수 있다. 예를 들면, 복제된 명령문(replicated statements)이 4.1에서는 사용할 수 없고 5.0에서만 사용 가능한
SQL 특성을 사용한다면, 5.0 마스터는 4.1 슬레이브에 복제를 할 수 없게 된다. Section 6.7, “리플리케이션 기능들과 알려져 있
는 문제점들”에서 다른 이슈 사항들을 참조한다.
:::MySQL Korea:::
제목검색
6. 리플리케이션 6.6.1. 5.0으로 리플리케이션 업그레이드 하기

리플리케이션 설정에 관여하는 서버를 업그레이드 할 때, 업그레이드 과정은 현 서버의 버전과 업그레이드를 하고자 하는 버전에
6.6 리플리케이션 설정 업그레이드 하기
따라 달리 진행이 된다.
6.6.1 5.0으로 리플리케이션 업그레이드 하기
:::MySQL Korea:::
제목검색
6.6.1. 5.0으로 리플리케이션 업그레이드 하기
이 섹션은 MySQL 3.23, 4.0, 또는 4.1을 MySQL 5.0으로 리플리케이션 업그레이드 하는 것에 대해 설명을 한다. 이때 4.0는
4.0.3 또는 그 이후 버전이어야 한다.
6.6.1 5.0으로 리플리케이션 업그레이드 하기
여러분이 마스터를 5.0 보다 이전 버전에서 5.0으로 업그레이드를 할 때에는, 우선 이 마스터의 모든 슬레이브가 동일한 5.x 시리
즈를 사용하고 있는지를 확인해야 한다. 만일 그렇지 않은 경우에는, 우선 슬레이브를 업그레이드 한다. 각 슬레이브를 업그레이드
하기 위해서는, 슬레이브를 셧 다운 시키고, 5.0.x 버전으로 업그레이드를 하고, 재 시작하고, 리플리케이션을 재 시작한다. 5.0 슬
레이브는 업그레이드를 하기 위해 이전에 작성된 릴레이 로그를 읽고 그 안에 있는 명령문을 실행한다. 업그레이드를 한 후에 슬레
이브가 실행하는 릴레이 로그는 5.0 포맷을 가지게 된다.
슬레이브를 업그레이드 한 후에, 마스터를 셧 다운 시키고, 슬레이브와 동일한 5.0.x버전으로 업그레이드를 하고, 재 시작을 한다.
5.0 마스터는 이전에 작성된 바이너리 로그를 읽을 수 있게 되고 이것들을 5.0 슬레이브에 보낼 수 있게 된다. 슬레이브는 구형 포
맷을 인식하고 올바르게 처리를 한다. 업그레이드 후에 마스터가 생성한 바이너리 로그는 5.0 포맷으로 된다. 이것 역시 5.0 슬레이
브가 인식을 한다.
다른 말로 표현하면, 여러분이 마스터를 5.0으로 업그레이드 하기 전에 슬레이브가 먼저 5.0으로 업그레이드 되어야 한다는 점을
제외하고는, 5.0으로 업그레이드를 하는 데 있어서 주의할 사항은 없다. 5.0에서 이전 버전으로 다운 그레이드하는 것은 간단하지
가 않다는 점을 알아두자: 여러분이 다운그레이드를 진행하기 전에 삭제를 할 수 있도록 하기 위해, 모든 5.0 바이너리 로그 또는
릴레이 로그가 완벽하게 실행 되었음을 확인해야 한다.
:::MySQL Korea:::
제목검색
6.7. 리플리케이션 기능들과 알려져 있는 문제점들
일반적으로, SQL 레벨에서의 리플리케이션 호환성은 마스터 서버와 슬레이브 서버 모두가 지원하는 기능을 모두 사용할 수 있어
6.7. 리플리케이션 기능들과 알려져 있는 문제
야 한다. 만일 주어진 버전 이후에만 사용 가능한 기능만을 서버에서 사용한다면, 여러분은 그 버전 이전의 슬레이브에는 리플리케
점들
이션을 진행할 수가 없게 된다. 이러한 비호환성은 시리즈와 시리즈 사이에서도 일어날 수 있는데, 예를 들면, MySQL 5.0에서 4.1
6.7 리플리케이션 기능들과 알려져 있는 문제점들
로의 복제는 실행할 수가 없다. 하지만, 이러한 비 호환성은 한 시리즈 내부의 버전 사이에서도 일어날 수가 있다. 예를 들면,
SLEEP() 함수는 MySQL 5.0.12 및 그 이후 버전에서 구현된다. 만약에 여러분이 마스터 서버에서 이 함수를 사용한다면,
5.0.12 보다 이전 버전을 사용하고 있는 슬레이브 서버에는 복제(replicate)를 할 수가 없게 된다.
만약에 5.0과 이전 버전 사이에 리플리케이션을 할 계획이라면, 그 버전의 리플리케이션 특성에 대한 정보를 제공하는 MySQL 레
퍼런스 매뉴얼을 참고해야 한다.
아래의 리스트는 지원되는 것과 지원되지 않는 것에 대해 자세히 설명을 하고 있다. 리플리케이션에 대한 추가적인 InnoDB-관련
정보는 Section 14.2.6.5, “InnoDB 와 MySQL 리플리케이션”에 나와 있다.
스토어드 루틴과 트리거에 대한 리플리케이션 이슈는 Section 17.4, “스토어드 루틴과 트리거에 대한 바이너리 로깅”에서 설명
하고 있다.
• 알려진 이슈: MySQL 5.0.17에서, CREATE TRIGGER에 대한 신텍스는 트리거 호출 시점에 검사해야 할 접근 권
한을 지정하기 위한 DEFINER 구문을 포함하기 위해 변경 되었다. (Section 18.1, “CREATE TRIGGER 신텍스”를
참고할 것.) 하지만, 만일 여러분이 MySQL 5.0.17 보다 이전 버전의 마스터 서버에서 MySQL 5.0.17 또는 그 이상의 슬
레이브로 복제(replicate)를 시도한다면, CREATE TRIGGER 명령문에 대한 리플리케이션은 Definer not fully
qualified 에러와 함께 실패를 하게 된다. 하나의 해결책은 각 CREATE TRIGGER 명령문에 포함되어 있는(embedded)
버전-관련 명령어를 사용해서 마스터에서 트리거를 생성하는 것이다:
• CREATE /*!50017 DEFINER = 'root'@'localhost' */ TRIGGER ... ;

:::MySQL Korea:::
이런 방식으로 작성된 CREATE TRIGGER 명령문은 새로운 버전의 슬레이브로 복제가 되는데, 이 슬레이브는 코멘트에
서 DEFINER 구문을 가져와서 성공적으로 실행을 한다.
• AUTO_INCREMENT, LAST_INSERT_ID(), 그리고 TIMESTAMP 값에 대한 리플리케이션은 올바르게 실행된

다.
• USER(), UUID(), 그리고 LOAD_FILE() 함수는 변경 없이 복제가 되기 때문에 슬레이브에서는 정확히 실행되지
않는다.
• mysql 데이터 베이스가 복제되는 경우에만 사용자 권한은 복제된다. 즉, GRANT, REVOKE, SET PASSWORD,
CREATE USER, 그리고 DROP USER 명령문은 리플리케이션 설정이 mysql 데이터 베이스를 포함하고 있을 경우에만
슬레이브에서 효력을 나타낸다.
만일 여러분이 모든 데이터 베이스를 복제 하지만, 복제될 사용자 권한에 영향을 주는 명령문은 제외 시키고 싶다면, --
replicate-wild-ignore-table=mysql.% 옵션을 사용해서 mysql 데이터 베이스를 복제하지 못하도록 슬레이브를 설정
한다. 슬레이브는 입력한 권한-관련 SQL 명령문이 효력이 없다는 것을 인식할 것이며, 따라서 그러한 명령문을 실행하
지 않게 된다.
• 사용자-레벨 잠금을 다루는GET_LOCK(), RELEASE_LOCK(), IS_FREE_LOCK(), 그리고 IS_USED_LOCK()

함수는 마스터에서 문장이 동시에 실행되는 것을 슬레이브가 인식하지 않는 상태에서도 복제가 된다. 따라서, 슬레이브에
있는 컨텐츠가 다르기 때문에 마스터 서버의 테이블에 삽입을 할 목적으로 이러한 함수들을 사용할 수가 없다. (예를 들
면, INSERT INTO mytable VALUES(GET_LOCK(...))와 같은 명령문을 입력할 수가 없다.)
• FOREIGN_KEY_CHECKS, SQL_MODE, UNIQUE_CHECKS, 그리고 SQL_AUTO_IS_NULL 변수들은 모두

MySQL 5.0에 복제된다. storage_engine 시스템 변수 (table_type라는 이름으로도 알려짐)는 아직까지는 복제되지 않
는데, 이것은 서로 다른 스토리지 엔진간의 리플리케이션을 위해서는 좋은 것이다.
• MySQL 5.0.3 (마스터와 슬레이브) 이후로는, 마스터와 슬레이브가 서로 다른 글로벌 문자 셋 변수를 가지고 있다
고 하더라도 리플리케이션은 잘 실행된다. MySQL 5.0.4 (마스터 및 슬레이브) 이후로는, 마스터와 슬레이브가 서로 다
른 글로벌 타임존 변수를 가지고 있다고 하더라도, 리플리케이션은 잘 실행된다.
• 아래의 사항들은 서로 다른 문자 셋을 사용하는 MySQL 서버간의 리플리케이션에 적용된다:
1. 만일 마스터가 MySQL 4.1를 사용한다면, 슬레이브에서 구동되는 MySQL 버전과는 상관 없이, 마스터와
슬레이브에서 항상 동일한 글로벌 문자 셋과 콜레션(collation)을 사용해야만 한다. (이것들은 --character-
set-server 와 --collation-server 옵션이 제어를 한다.) 그렇지 않으면, 여러분은 슬레이브에서 복제 키 에러
(duplicate-key error)를 가지게 되는데, 그 이유는 마스터 문자 셋에서 고유의 값을 가지는 키가 슬레이브 문

:::MySQL Korea:::
자 셋에서는 유일한(unique) 값을 가지지 않을 수도 있기 때문이다. 마스터와 슬레이브가 모두 5.0 또는 그 이상

의 버전일 경우에는 발생하지 않는다는 것을 알아두자.
2. 만일 마스터가 4.1.3 보다 이전 버전을 사용하고 있다면, 클라이언트의 문자 셋은 자신의 글로벌 값과는 절

대로 다르게 만들어 지면 안 되는데, 그 이유는 이 문자 셋 변경을 슬레이브가 알지 못하기 때문이다. 달리 표현하
면, 클라이언트는 SET NAMES, SET CHARACTER SET등과 같은 명령문을 사용할 수가 없다. 만일 마스터
및 슬레이브 모두가 4.1.3 또는 그 이후 버전일 경우, 클라이언트는 문자 셋 변수에 대한 값을 자유롭게 설정할 수
가 있는데, 그 이유는 바이너리 로그에 이러한 설정이 작성되고 슬레이브에 통보가 되기 때문이다. 즉, 클라이언
트는 SET NAMES 또는 SET CHARACTER SET를 사용할 수 있거나 또는 COLLATION_CLIENT 또는
COLLATION_SERVER와 같은 변수를 설정할 수 있게 된다. 하지만, 클라이언트는 이 변수들의 글로벌 변수 값
을 변경 시키지는 못한다; 앞에서도 언급을 하였듯이, 마스터와 슬레이브는 항상 동일한 문자 셋 값을 가지고 있
어야만 한다.
3. 만일 여러분이 글로벌 character_set_server 값과는 다른 문자 셋을 마스터 서버에 있는 데이터 베이스에

가지고 있다면, 여러분 자신의 CREATE TABLE 명령문을 설계해서 이 데이터 베이스에 있는 테이블들이 그 데
이터 베이스에 있는 디폴트 문자 셋과 관련이 되지 않도록 해야 한다 (Bug #2326를 참조). 한가지 좋은 방법은
CREATE TABLE에서 명확하게 문자 셋과 콜레션(collation)을 언급하는 것이다
• 만일 마스터가 MySQL 4.1를 사용한다면, 동일한 타임 존이 마스터와 슬레이브 모두에 설정되어야 한다. 그렇지 않
으면, NOW() 또는 FROM_UNIXTIME() 함수 등을 사용하는 명령문 같은 것들이 올바르게 복제되지 않게 된다. 여러분
은 mysqld_safe 스크립트의 --timezone=timezone_name 옵션을 사용하거나 또는 TZ 환경 변수를 설정함으로써
MySQL 서버가 구동하는 타임 존을 설정할 수가 있다. 마스터 및 슬레이브 모두는 또한 동일한 디폴트 접속 타임 존 설정
을 가지고 있어야 한다; 즉, --default-time-zone 파라미터는 마스터와 슬레이브에 모두에 대해 동일한 값을 가지고 있
어야 한다. 마스터가 5.0 이상의 버전을 사용한다면, 이러한 사항들은 필요가 없게 된다.
• CONVERT_TZ(...,...,@@global.time_zone)은 올바르게 복제되지 않는다. CONVERT_TZ(...,...,@@session.

time_zone)은 마스터와 슬레이브가 5.0.4 이상의 버전일 경우에만 올바르게 복제된다.
• 세션 변수들이 테이블을 업데이트하는 명령문에서 사용될 경우에는 올바르게 복제되지 않는다. 예를 들면, INSERT
INTO mytable VALUES(@@MAX_JOIN_SIZE)가 뒤에 따르는 SET MAX_JOIN_SIZE=1000는 마스터와 슬레이브
에 동일한 데이터를 삽입할 수가 없게 된다. 이것은 INSERT INTO mytable VALUES(CONVERT_TZ(...,...,
@@time_zone))가 뒤 따라 나오는 일반적인 SET TIME_ZONE=... 시퀀스에는 적용이 되지 않는데, 이것은 5.0.4 이후
에는 올바르게 복제가 된다.
• 슬레이브에 있는 논-트랜젝션(non-transactional) 테이블을 사용해서 마스터에 있는 트랜젝션 테이블을 복제하는

:::MySQL Korea:::
것은 가능하다. 예를 들면, 여러분은 InnoDB 마스터 테이블을 MyISAM 슬레이브 테이블처럼 복제할 수가 있다. 하지만,
여러분이 이런 일을 실행한다면, 슬레이브가 BEGIN 블록을 실행하면서 슬레이브가 재 시작하기 때문에 BEGIN/
COMMIT 블록 실행 중간에 슬레이브가 멈추게 되는 경우에는 문제가 발생하게 된다.
• 사용자 정의 변수(즉 @var_name 형태의 변수)를 참조하는 명령문의 업데이트는 MySQL 5.0에서는 올바르게 복제
된다. 하지만, 4.1 이전 버전에서는 그렇지가 않다. 사용자 변수의 이름은 5.0에서부터는 대소 문자를 구분하지 않는다는
점을 알아두자. 여러분은 MySQL 5.0과 이전 버전간의 리플리케이션을 설정할 때에는 이점을 고려해야 한다.
• 슬레이브는 SSL을 사용해서 마스터에 접속할 수가 있다.
• MySQL 5.0 (5.0.3 이후)에서는, 글로벌 시스템 변수 slave_transaction_retries가 존재한다: 만일 리플리케이션 슬

레이브 SQL 쓰레드가 InnoDB 데드락(deadlock)으로 인해 또는 InnoDB innodb_lock_wait_timeout, NDB클러스터
TransactionDeadlockDetectionTimeout, 또는 TransactionInactiveTimeout 값을 초과하기 때문에 트랜젝션 실행에
실패를 하는 경우에는, 에러를 가지고 종료를 하기 전에 트랜젝션은 slave_transaction_retries에서 지정하는 횟수만큼
자동으로 재 시도를 하게 된다. 디폴트 값은 10이다. MySQL 5.0.4 이후에는, 전체 자동 재시도 횟수는 SHOW STATUS
의 실행 결과로 확인할 수가 있다; Section 5.2.4, “서버 상태 변수”를 참조.
• 만일 DATA DIRECTORY 또는 INDEX DIRECTORY 테이블 옵션이 마스터 서버의 CREATE TABLE 명령문에
서 사용된다면, 그 테이블 옵션은 슬레이브에서도 사용되게 된다. 이것은 슬레이브 호스트 파일 시스템에 대응하는 디렉토
리가 없거나 또는 존재는 하지만 슬레이브 서버가 접근을 할 수 없는 경우에는 문제의 원인이 된다. MySQL은
NO_DIR_IN_CREATE라고 불리는 sql_mode 옵션을 지원한다. 만일 슬레이브 서버가 SQL 모드가 활성화 된 상태로 구
동을 한다면, 슬레이브는 CREATE TABLE 명령문을 복제할 때 DATA DIRECTORY 와 INDEX DIRECTORY 테이블
옵션을 무시해 버린다. 그 결과로 MyISAM 데이터와 인덱스 파일이 테이블의 데이터 베이스 디렉토리에 생성된다.
• 하나의 명령문이 데이터 수정(data modification)을 비 결정적(non-deterministic) 방식으로 실행하도록 고안되

는 경우에는, 마스터와 슬레이브에 있는 데이터가 서로 달라질 가능성이 있다; 즉, 쿼리 옵티마이저의 의도에 반함(left to
the will). (이것은 리플리케이션 이외의 상황에서도 그리 좋은 경우가 아니다.) 이 이슈에 대한 보다 자세한 내용은
Section A.8.1, “Open Issues in MySQL”을 참조할 것.
• 아래의 사항은 마스터 또는 슬레이브 중의 하나라도 MySQL 5.0.3 또는 그 이전 버전을 사용하는 경우에만 적용된
다: 만일 마스터에서 LOAD DATA INFILE이 인터럽트가 된다면 (integrity constraint violation, killed connection,
등등), 슬레이브는 LOAD DATA INFILE 전체를 건너 띈다(skip). 이것은 만일 이 명령어가 인터럽트를 당하기 전에 테
이블 레코드를 영구적으로 삽입하거나 또는 업데이트 했다면, 이러한 수정 사항은 슬레이브에 복제되지 않는다.
• 몇몇 FLUSH 명령문들은 슬레이브에 복제되면 문제를 일으키기 때문에 로그되지 않는다: FLUSH LOGS, FLUSH
MASTER, FLUSH SLAVE, 그리고 FLUSH TABLES WITH READ LOCK. 신텍스 예제에 관련되어서는

:::MySQL Korea:::
Section 13.5.5.2, “FLUSH 신텍스”를 참조할 것. FLUSH TABLES, ANALYZE TABLE, OPTIMIZE TABLE, 그리
고 REPAIR TABLE 명령문은 바이너리 로그에 쓰여지며 따라서 슬레이브에 복제가 된다. 이것은 일반적인 경우에 문제
를 발생시키지 않는데, 그 이유는 이 명령문들은 테이블 데이터를 수정하지 않기 때문이다. 하지만, 특정 환경 아래에서는
심각한 문제를 야기할 수 있다. 만일 여러분이 mysql 데이터 베이스에 있는 권한 테이블을 복제하고 GRANT를 사용하지
않고 직접 그 테이블들을 업데이트 한다면, 슬레이스에서 FLUSH PRIVILEGES를 입력하여 새로운 권한이 효과를 나타
내도록 해야 한다. 또한, 만일 여러분이 MERGE 테이블의 일부분인 MyISAM 테이블의 이름을 변경할 때 FLUSH
TABLES를 사용한다면, 반드시 슬레이브에서 FLUSH TABLES을 수동으로 입력해야 한다. 이러한 명령문들은 여러분
이 NO_WRITE_TO_BINLOG 또는 이것의 별칭인 LOCAL을 지정하지 않는 한 바이너리 로그에 쓰여지게 된다.
• MySQL은 하나의 마스터와 여러 개의 슬레이브만을 지원한다. 향후에는, 현 마스터에 문제가 생길 경우에 마스터를
자동으로 변경하는 투표 알고리즘(voting algorithm)을 추가할 계획이다. 또한, SELECT 쿼리를 서로 다른 슬레이브에
보내줌으로써 로드 밸런싱(load balancing)을 도와주는 에이전트 프로세스를 추가할 계획도 있다.
• 서버를 셧 다운하고 다시 시작을 할 때에는, 서버의 MEMORY (HEAP) 테이블은 비어 진다. 마스터는 이러한 결과
를 아래와 같이 슬레이브에 복제한다: 스타트업 후에 마스터 서버가 각 MEMORY 테이블을 처음으로 사용할 때, 서버는
DELETE 명령문을 사용해서 비워져야 할 필요가 있는 테이블을 슬레이브에게 통보하는 이벤트를 기록한다. 보다 자세한
정보는 Section 14.4, “MEMORY (HEAP) 스토리지 엔진”을 참조할 것.
• 여러분이 슬레이브 서버를 셧 다운(슬레이브 쓰레드가 아님)하는 경우와 슬레이브에서 아직 실행이 되지 않은 업데

이트에서 사용된 복제된 임시 테이블을 가지고 있는 경우를 제외하면, 임시 테이블은 복제가 된다. 만일 여러분이 슬레이
브 서버를 셧 다운 시켰다면, 이러한 업데이트에 필요한 임시 테이블들은 슬레이브가 재 시작될 때에는 더 이상 사용할 수
가 없게 된다. 이러한 문제를 피하기 위해서는, 슬레이브 서버가 임시 테이블을 열어 두고 있는 동안에는 셧 다운 시키지
않는다. 대신에, 아래의 과정을 따라 한다:
1. STOP SLAVE 명령문 입력.
2. Slave_open_temp_tables 변수의 값을 검사하기 위해 SHOW STATUS를 사용.
3. 그 값이 0 이면, 슬레이브를 종료 시키기 위해 mysqladmin shutdown 명령어를 사용한다.
4. 만일 그 값이 0 이 아니면, 슬레이브 쓰레드를 START SLAVE와 함께 재 시작한다.
5. Slave_open_temp_tables 변수가 0 이 될 때까지 과정을 반복하고, 그 후에 슬레이브를 종료 시킨다.
• 별칭(alias)을 사용하는 다중-테이블 DELETE 명령문의 신텍스는 MySQL 4.0 과 4.1 사이에 변경 되었다.
MySQL 4.0에서는, 삭제되어야 할 열을 가지고 있는 모든 테이블을 참조하기 위해서는 실제 테이블 이름(true table
name)을 사용해야 한다:

:::MySQL Korea:::
• DELETE test FROM test AS t1, test2 WHERE ...
MySQL 4.1에서는, 아래와 같은 별칭을 사용해야 한다:
DELETE t1 FROM test AS t1, test2 WHERE ...
만일 여러분이 위와 같은 DELETE 명령문을 사용한다면, 신텍스 안에서의 변경은 4.0 마스터는 4.1 (또는 그 이상 버전)
슬레이브에 복제할 수 없다는 의미를 가진다.
• 만일 여러분이 --log-slave-updates 옵션을 사용한다면, 순환 마스터/슬레이브 관계(circular master/slave

relationship)에서 서버에 접속을 하는 것이 안전하다. 이것은 여러분이 아래와 같은 설정을 생성할 수 있다는 것을 의미
한다:
• A -> B -> C -> A
하지만, 여러분의 클라이언트 코드가 서로 다른 서버상에서 서로 다른 시퀀스 안에서 발생되는 업데이트 중에 일어날 수
있는 잠재적인 문제에 대해 주의 깊게 작성되지 않았다면, 대부분의 명령문은 올바르게 동작을 하지 않게 된다.
서버 ID는 바이너리 로그 이벤트에 기록(encoded)되며, 따라서 서버 A는 자신이 만든 이벤트를 읽기는 하지만 실행을 하
지 않은 시점을 알게 된다 (서버 A 가 --replicate-same-server-id 옵션을 가지고 실행되지 않은 한, 하지만 대부분
의 경우에는 의미가 없다). 따라서, 무한 루프(infinite loop)는 존재하지 않는다. 이러한 순환 설정(circular setup) 형태
는 여러분이 테이블간의 충돌이 없이 업데이트를 수행하는 경우에만 동작을 하게 된다. 다른 말로 표현하면, 만일 A와 C
에 모두 데이터를 삽입할 경우, 여러분은 C에 삽입되는 열과 충돌을 하는 키를 가지고 있는 A의 열에는 데이터를 절대로
삽입할 수가 없게 된다. 또한 적용되는 업데이트가 순서가 중요한 사항일 경우 두 개의 서버에 동일한 데이터를 업데이트
할 수가 없게 된다.
• 슬레이브에 있는 명령문이 에러를 발생시킨다면, 슬레이브의 SQL 쓰레드는 종료를 하게 되며, 슬레이브는 자신의 에
러 로그에 메시지를 작성한다. 그렇게 되면, 여러분은 슬레이브에 수동으로 접속을 해서 문제의 원인이 무엇인지를 파악해
야 한다. (SHOW SLAVE STATUS는 이런 상황에서 유용하게 사용할 수 있다.) 그런 다음에 문제를 수정하고 (예를 들
면, 여러분들은 실제 존재하지 않는(non-existent)테이블을 만들 필요가 있을 것이다) START SLAVE를 구동시킨다.
• 마스터 서버를 셧 다운 시킨 다음에 나중에 다시 시작하는 것이 안전하다. 슬레이브가 서버와의 접속을 잃게 될 때,

슬레이브는 즉시 재 접속을 시도하고 실패를 하게 되면 주기적으로 재 접속을 시도한다. 디폴트는 매 60초마다 재 시도를
하는 것이다. 이 값은 --master-connect-retry 옵션으로 변경시킬 수 있다. 슬레이브는 또한 네트워크 접속 불능

:::MySQL Korea:::
(network connectivity outage)을 처리할 수 있다. 하지만, 슬레이브는 slave_net_timeout 시간 동안 마스터에서 데이

터를 받지 못할 경우에만 네트워크 불능을 통보한다. 만일 여러분에게 할당된 사용 불능(outage)이 너무 짧다면,
slave_net_timeout값을 줄이고 싶을 것이다. Section 5.2.2, “서버 시스템 변수”를 참조.
• 슬레이브를 완벽하게(cleanly) 셧 다운 시키는 것이 안전한데, 그 이유는 슬레이브가 어디에서 중단을 했는지에 대

한 정보를 유지하고 있기 때문이다. 애매하게 셧 다운을 시키게 되면 문제가 발생할 수 있는데, 특히 디스크 캐시가 시스템
이 종료되기 전에 디스크에 플러시 되지 않았을 경우가 그러하다. 여러분의 시스템 장애 무 정지(fault tolerance)는 언인
터럽터블(uninterruptible) 전원 공급 장치를 가지고 있는 경우에는 획기적으로 향상된다. 마스터의 애매한 셧 다운은 마
스터 서버의 테이블 컨텐츠와 바이너리간의 일관성을 해칠 우려가 있다; 이 문제는 마스터상에서 InnoDB 테이블과 --
innodb-safe-binlog 옵션을 사용해서 해결할 수가 있다. Section 5.12.3, “바이너리 로그”를 참조할 것.
Note: --innodb-safe-binlog는 XA 트랜젝션 지원이 MySQL 5.0.3에 포함되었기 때문에 불필요하게 되었다.
• MyISAM 테이블의 논-트랜젝션 특성으로 인해, 테이블을 부분적으로 업데이트하면 에러 코드를 발생시키는 명령문
을 가지는 것이 가능하다. 예를 들면, 다중-열 삽입에서 키 제약을 위반하는 열을 가지거나, 또는 열 중에 몇 개를 업데이
트 한 후에 기다란 업데이트 명령문을 죽이게 될 경우에 이런 일이 생길 수 있다. 만일 마스터에서 이런 일이 발생한다면,
에러 코드가 유효하고 그리고 명령문 실행으로 인해 동일한 에러 코드가 슬레이브에도 기록이 되지 않는 한 슬레이브 쓰레
드는 종료를 하게 되고 데이터 베이스 관리자의 조정을 기다리게 된다. 만일 에러 코드 검증 행위를 원하지 않을 경우에
는, 몇몇 또는 모든 에러를 무시하도록 --slave-skip-errors 옵션을 사용할 수가 있다.
• 만일 BEGIN/COMMIT 시퀀스 내부에 있는 논-트랜젝션 테이블에서 트랜젝션 가능(transactional)테이블을 업데

이트 한다면, 트랜젝션을 실행하기 전에 논-트랜젝션 테이블을 업데이트 한다면, 바이너리에 대한 업데이트는 동기화
(synchrony)되지 않을 수도 있다. 이것은 트랜젝션이 실행될 때에만 바이너리에 기록되기 때문에 일어나는 것이다.
• 트랜젝션이 트랜젝션 가능(transactional) 및 논-트랜젝션(non-transactional) 테이블에 대한 업데이트를 혼용하

는 경우에, 바이너리 로그에 있는 명령문의 순서는 올바르게 진행되고, 그리고 모든 필요한 명령문이 ROLLBACK일 경우
에도 바이너리 로그에 기록된다. 하지만, 첫 번째 접속의 트랜젝션이 완료되기 전에 두 번째 접속의 논-트랜젝션 업데이트
가 진행될 때, 명령문은 순서가 틀리게 로그 아웃 될 수 있는데, 그 이유는 첫 번째 접속이 수행한 트랜젝션의 상태와는 상
관 없이 두 번째 접속의 업데이트가 실행된 후에 즉시 기록되기 때문이다.

:::MySQL Korea:::
제목검색
6.8. 리플리케이션 스타트업 옵션들
이 섹션에서는 여러분이 슬레이브 리플리케이션 서버에서 사용할 수 있는 옵션들에 대해 설명하기로 한다. 이 옵션들은 명령어 라
6.8. 리플리케이션 스타트업 옵션들
인 또는 옵션 파일에서 지정할 수 있다.
6.8 리플리케이션 스타트업 옵션들
마스터와 각 슬레이브에서, 여러분은 고유의 리플리케이션 ID를 설정하기 위해서 반드시 server-id 옵션을 사용해야 한다. 각 서
버의 경우, 여러분은 1 에서 232 – 1 사이의 양수 정수 중의 고유 값을 사용해야 하고 각 ID는 반드시 다른 ID와 구분이 되어야 한
다. 예: server-id=3
바이너리 로깅을 제어하기 위해 마스터에서 사용할 수 있는 옵션들은 Section 5.12.3, “바이너리 로그”에서 설명을 한다.
어떤 슬레이브 리플리케이션 옵션들은 슬레이브가 그 옵션 값을 가지고 시작될 때 master.info 파일이 존재한다면 무시가 되는 것
과 같은 형태로 특별히 취급되는 것들이 있다. 아래의 옵션들이 이런 방식으로 처리된다:
• --master-host
• --master-user
• --master-password
• --master-port
• --master-connect-retry
• --master-ssl
• --master-ssl-ca
• --master-ssl-capath
• --master-ssl-cert
• --master-ssl-cipher

:::MySQL Korea:::
• --master-ssl-key
MySQL 5.0의 master.info 파일 포맷은 SSL 옵션과 상응되는 값을 가진다. 또한, 이 파일 포맷은 자신의 첫 라인에 파일의 전체
라인 수를 가진다. 만일 구형의 서버(4.1.1 이전 버전)를 새로운 버전으로 업그레이드 한다면, 새로운 서버는 시작이 될 때 자동으
로 master.info 파일을 새로운 포맷으로 업그레이드 시킨다. 하지만, 만일 여러분이 새 버전에서 구형 버전으로 다운그레이드를 할
경우에는, 구형 버전의 서버를 맨 처음 시작하기 전에 수동으로 처음 라인을 제거해야 한다.
슬레이브 서버가 시작될 때 master.info 파일이 존재하지 않는다면, 슬레이브는 옵션 파일 또는 명령어 라인에서 지정한 옵션에 대
한 값을 사용한다. 여러분이 서버를 맨 처음 리플리케이션 서버로 구동 시킬 때, 또는 RESET SLAVE를 구동 시킨 후에 슬레이브
를 셧 다운하고 다시 시작할 때 이런 일이 일어나게 된다.
만일 master.info 파일이 슬레이브 서버를 시작할 때 존재한다면, 서버는 이 파일의 내용을 사용하게 되며 파일에 올라와 있는 값
에 대응되는 어떤 옵션들도 무시를 하게 된다. 따라서, 만일 여러분이 master.info 파일에 있는 값에 대응되는 스타트업 옵션의 값
과는 다른 것을 사용해서 슬레이브 서버를 시작한다면, 다르게 적용된 값은 무시가 되는데, 그 이유는 서버는 계속해서 master.
info 파일의 값을 사용하기 때문이다. 다른 값을 사용하기 위해서는, 반드시 master.info 파일을 제거한 다음에 재 시작을 하거나
또는 슬레이브가 구동하고 있는 동안에 그 값을 리셋하기 위한 CHANGE MASTER TO 명령문을 사용해서 재 시작을 하도록 한
다 (흔히 사용됨).
여러분이 이 옵션을 my.cnf 파일에 지정했다고 가정하자:
[mysqld]
master-host=some_host
서버를 리플리케이션 슬레이브로 처음 구동을 할 때, 서버는 my.cnf 파일에서 그 옵션을 읽어서 사용한다. 그런 후에, 서버는 그 값
을 master.info 파일에 기록한다. 다음 번에 서버를 구동할 때에는, 서버는 master.info 파일에서만 마스터 호스트 값을 읽게 되고
옵션 파일에 있는 값을 무시를 한다. 만일 여러분이 some_other_host의 마스터 호스트를 달리 지정하기 위해my.cnf 파일을 수정
한다고 하더라도, 변경 내용은 효과를 나타내지 못한다. 대신에 여러분은 CHANGE MASTER TO를 사용해야 한다.
위에서 설명하였듯이, 서버는 스타트업 옵션이 아닌 존재하고 있는 master.info 파일에 우선권을 주기 때문에, 이 값들에 대해 스타
트업 옵션을 전혀 먼저 사용할 수 없게 되므로, CHANGE MASTER TO 명령문을 사용해서 이 값들을 대신 지정하도록 한다.

:::MySQL Korea:::
Section 13.6.2.1, “CHANGE MASTER TO 신텍스”를 참조.
아래의 예문은 슬레이브 서버를 구성하기 위해 스타트업 옵션을 보다 광범위하게 사용하는 방법을 보여주는 것이다:
[mysqld]
server-id=2
master-host=db-master.mycompany.com
master-port=3306
master-user=pertinax
master-password=freitag
master-connect-retry=60
report-host=db-slave.mycompany.com
아래의 리스트는 리플리케이션을 제어하기 위한 스타트업 옵션을 설명하는 것이다. 이 옵션들 중의 많은 것들은 서버가 구동되고
있는 동안 CHANGE MASTER TO 명령문을 사용해서 리셋 시킬 수가 있다. --replicate-* 옵션과 같은 것들은 슬레이브 서버
가 시작될 때에만 설정될 수 있다.
• --log-slave-updates
일반적으로, 슬레이브는 마스터 서버에서 전달 받은 업데이트에 대해서는 자신의 바이너리 로그에 전혀 로그를 하지 못한
다. 이 옵션은 SQL 쓰레드가 실행한 업데이트를 자신의 바이너리 로그에 로그 하도록 만든다. 이 옵션이 효력을 갖기 위해
서는, 슬레이브는 바이너리 로깅을 활성화 시키기 위한 --log-bin 옵션과 함께 시작되어야 한다. --log-slave-
updates 는 여러분이 리플리케이션 서버를 서로 연결(chain)하고자 할 때 사용된다. 예를 들면, 아래와 같은 배열을 사용
해서 리플리케이션 서버를 설정하고자 할 것이다:
A -> B -> C

:::MySQL Korea:::
여기에서, A는 슬레이브B에 대한 마스터의 역할을 하며, B는 슬레이브 C에 대해 마스터 역할을 한다. 이렇게 동작하기 위
해서는, B는 반드시 마스터인 동시에 슬레이브가 되어야 한다. 여러분은 바이너리 로깅을 활성화 시키기 위해 A와 B 모두
에서 --log-bin옵션을 실행해야 하고, A에서 받은 업데이트를 B가 자신의 바이너리 로그에 로그할 수 있도록 B는 --
log-slave-updates 옵션을 실행해야 한다.
• --log-warnings
이 옵션은 에러 로그에 보다 자세한 메시지를 기록하게끔 만든다. 리플리케이션 관점에서 보면, 서버는 네트워크/접속 실
패 후에 지속적으로 접속을 다시 시도하는 경고문을 만들게 되며, 각각의 슬레이브가 어떻게 시작되는지에 대한 정보를 여
러분에게 알려 준다. 이 옵션은 디폴트로 활성화 된다; 이것을 비활성화 시키기 위해서는, --skip-log-warnings를 사
용한다. 단절된 접속은 이 값이 1보다 크지 않는 한 에러 로그에 로그 되지 않는다.
• --master-connect-retry=seconds
마스터가 다운(down)되거나 또는 접속이 끊어지는 경우에, 마스터에 재 접속을 시도하기 전에 슬레이브 쓰레드가 슬립
(sleep)되는 시간. master.info 파일에 있는 값이 우선권을 가진다. 설정되지 않으면, 디폴트는 60이 된다.
• --master-host=host_name
마스터 리플리케이션 서버의 호스트 이름 또는 IP 번호. master.info에 있는 값이 우선권을 갖는다. 마스터 호스트가 지정
되지 않으면, 슬레이브 쓰레드는 시작되지 않는다.
• --master-info-file=file_name
슬레이브가 마스터에 대한 정보를 기록하기 위해 사용하는 파일의 이름. 디폴트는 데이터 디렉토리에 있는 mysql.info이
된다.
• --master-password=password
슬레이브가 마스터에 접속을 할 때 슬레이브 쓰레드가 인증용으로 사용하는 계정의 패스워드. master.info 파일에 있는
값이 우선권을 가지게 된다. 설정이 되어 있지 않으면, 패스워드가 비어 있다고 간주된다.
• --master-port=port_number
마스터가 기다리는(listening) TCP/IP 포트 번호. master.info 파일에 있는 값이 우선권을 가진다. 설정이 되어 있지 않

으면, 설정이 컴파일 되어 있다고 가정을 한다 (일반적인 경우 3306).
• --master-retry-count=count
슬레이브가 마스터에 접속을 시도하는 횟수(접속 포기 전까지).

:::MySQL Korea:::
• --master-ssl, --master-ssl-ca=file_name, --master-ssl-capath=directory_name, --master-ssl-

cert=file_name, --master-ssl-cipher=cipher_list, --master-ssl-key=file_name
이 옵션은 SSL을 사용하여 마스터 서버에 보안 리플리케이션 접속을 설정하기 위해 사용된다. 각각의 의미는
Section 5.9.7.5, “SSL 명령어 옵션”에서 설명하고 있는 --ssl, --ssl-ca, --ssl-capath, --ssl-cert, --ssl-
cipher, --ssl-key 옵션들과 같다. master.info 파일에 있는 값들이 우선권이 있다.
• --master-user=user_name
슬레이브가 서버에 접속을 할 때 슬레이브 쓰레드가 인증을 위해 사용하는 계정의 사용자 이름. 이 계정은 반드시
REPLICATION SLAVE 권한을 가지고 있어야 한다. master.info 파일 값이 우선권이 있다. 만일 마스터 사용자 이름이
설정되지 않았다면, test라는 이름일 것이라고 추정한다.
• --max-relay-log-size=size
서버가 자동으로 릴레이 로그 파일을 순환(rotate)시키는 크기. 자세한 정보는 Section 6.3.4, “리플리케이션 릴레이 및
상태 파일”를 참조할 것.
• --read-only
슬레이브는 자신의 쓰레드가 보내거나 SUPER 권한의 사용자가 보내는 업데이트 이외에는 어떠한 업데이트도 하지 못하
도록 한다. 이것은 슬레이브 서버가 클라이언트에서 오는 업데이트를 받아들이지 못하도록 한다. MySQL 5.0.16 이후에
는, 이 옵션은 TEMPORARY 테이블에 적용되지 않는다.
• --relay-log=file_name
릴레이 로그에 대한 이름. 디폴트 이름은 host_name-relay-bin.nnnnnn이며, 여기에서 host_name는 슬레이브 서버 호

스트의 이름이며, nnnnnn는 릴레이 로그가 이만큼의 시퀀스 동안 생성되었음을 가리키는 것이다. 여러분은 호스트 이름과
는 무관한 릴레이 로그 이름을 생성하기 위해서 또는 여러분의 릴레이 로그가 점점 커지고(그리고 여러분이
max_relay_log_size의 크기를 줄이고 싶지 않으며) 그리고 이 릴레이 로그들을 데이터 디렉토리가 아닌 다른 곳에 저장
하고 싶거나, 또는 디스크간의 로드 밸런싱을 통해 속도를 증가 시키고자 할 경우에 이 옵션을 지정할 수가 있다.
• --relay-log-index=file_name
릴레이 로그 인덱스 파일의 이름. 디폴트 이름은 데이터 디렉토리내에 있는 host_name-relay-bin.index이며, 여기에서
host_name은 슬레이브 서버의 이름이 된다.
• --relay-log-info-file=file_name
릴레이 로그에 대한 정보를 기록하는데 사용되는 파일의 이름. 디폴트 이름은 데이터 디렉토리내에 있는 relay-log.info

:::MySQL Korea:::
가 된다.
• --relay-log-purge={0|1}
릴레이 로그가 더 이상 필요 없게 되는 순간에 자동으로 이 로그를 비워 버리는(purging)것을 활성화 또는 비 활성화 시

킴. 디폴트는 1(활성화)임. 이것은 SET GLOBAL relay_log_purge = N를 사용해서 동적으로 변경 시킬 수 있는 글로벌
변수이다.
• --relay-log-space-limit=size
이 옵션은 슬레이브에 있는 모든 릴레이 로그의 전체 크기의 최대 크기(바이트 단위)를 지정한다. 이 값이 0 이면 “제한

없음(no limit)”을 의미한다. 제한된 디스크 공간을 가지고 있는 슬레이브 서버 호스트에 유용한 옵션이다. 제한치에 접
근을 하게 되면, I/O 쓰레드는 SQL 쓰레드가 사용되지 않고 있는 릴레이 로그를 가져와서 제거하기 전까지 쓰레드는 마스
터 서버에서 오는 바이너리 로그 이벤트에 대해 읽기를 중단한다. 이 제한 값은 절대적인 것이 아니라는 것을 알아두자:
SQL쓰레드는 릴레이 로그를 삭제하기 전에 보다 많은 이벤트를 필요로 하는 경우가 있다. 그럴 경우, I/O 쓰레드는 SQL
쓰레드가 몇몇 릴레이 로그를 삭제할 수 있을 때까지 제한치를 초과하게 되는데, 그 이유는 그렇게 하지 않으면 데드락
(deadlock)이 생길 수 있기 때문이다. 여러분은 --max-relay-log-size (또는 --max-relay-log-size가 0 일 경
우에는, --max-binlog-size) 값의 두 배 보다 작게 --relay-log-space-limit의 값을 설정하지 말아야 한다. 그렇
지 않으면, --relay-log-space-limit가 초과되기 때문에 I/O 쓰레드는 사용 가능 공간을 기다리게 되지만, SQL 쓰레
드는 깨끗이 비워야 할(purge) 릴레이 로그를 가지지 않게 되고, 따라서 I/O 쓰레드를 만족시키지 못하게 된다. 이것은 I/
O 쓰레드가 임시적으로 --relay-log-space-limit를 무시하게끔 만들어 버린다.
• --replicate-do-db=db_name
디폴트 데이터 베이스(즉, USE가 선택하는 것)가 db_name인 곳에서는 명령문을 리플리케이션 하는 것을 제한하도록 서
버에게 지시한다. 한 개 이상의 데이터 베이스를 지정하기 위해서는, 각각의 데이터 베이스 별로 한 번씩 이 옵션을 사용한
다. 이 옵션은 서로 다른 데이터 베이스를 선택했거나 또는 아무런 데이터 베이스도 선택하지 않은 동안에는, UPDATE
some_db.some_table SET foo='bar' 와 같이 크로스-데이터 베이스(cross-database) 명령문은 복제하지 않는다는
점을 알아두자.
여러분이 예상하는 것과는 달리, 동작을 하지 않는 예를 보자: 만일 슬레이브가 --replicate-do-db=sales와 함께 시작

이 되고 그리고 여러분이 마스터에서 아래와 같은 명령문을 입력했다면, UPDATE 명령문은 복제되지 않는다:
USE prices;
UPDATE sales.january SET amount=amount+1000;

:::MySQL Korea:::
이렇게 “디폴트 데이터 베이스를 단지 검사만 하는” 동작이 일어나는 주된 이유는, 명령문을 복제할지 말지에 대해서는
명령문 하나만 가지고서는 알기가 어렵기 때문이다 (예를 들면, 만약에 여러분이 다중-테이블 DELETE 명령문 또는 여
러 개의 데이터 베이스를 넘나드는 다중-테이블 UPDATE 명령문을 사용 중일 경우). 전체 데이터 베이스를 검색할 필요
가 없는 경우에는, 당연히 디폴트 데이터 베이스만 검사하는 것이 빠를 것이다.
만일 여러분이 크로스-데이터 베이스 업데이트를 수행할 필요가 없다면, --replicate-wild-do-table=db_name.%

를 대신 사용한다. Section 6.9, “서버가 리플리케이션 규칙을 얻는 방법”를 참조.
• --replicate-do-table=db_name.tbl_name
지정된 테이블로의 리플리케이션을 제한하도록 슬레이브 쓰레드에게 지시한다. 한 개 이상의 테이블을 지정하기 위해서
는, 각각의 테이블 별로 한 번씩 이 옵션을 사용한다. 이 옵션은--replicate-do-db와는 반대로, 크로스-데이터 베이스
에 대해서도 동작을 한다. Section 6.9, “서버가 리플리케이션 규칙을 얻는 방법”를 참조.
• --replicate-ignore-db=db_name
디폴트 데이터 베이스가 (즉, USE가 선택하는 것) db_name인 곳에서는 모든 명령문을 복제하지 않도록 서버에게 지시한
다. 한 개 이상의 데이터 베이스를 무시하도록 하기 위해서는, 각각의 데이터 베이스 별로 한번씩 이 옵션을 사용한다. 만
일 여러분이 크로스-데이터 베이스 업데이트를 사용하고 있고 이러한 데이터 베이스들이 업데이트 되는 것을 원하지 않
을 경우에는, 이 옵션을 사용하지 말아야 한다. Section 6.9, “서버가 리플리케이션 규칙을 얻는 방법”를 참조.
여러분이 기대하는 것처럼 동작하지 않는 예를 보자: 만일 슬레이브가 --replicate-ignore-db=sales와 함께 시작되

고 여러분이 아래와 같은 명령문을 마스터에서 입력하였다면, UPDATE 명령문은 복제되지 않는다:
USE prices;
UPDATE sales.january SET amount=amount+1000;
만일 크로스-데이터 베이스의 업데이트를 실행하고자 한다면, --replicate-wild-ignore-table=db_name.%를 대신

사용한다. Section 6.9, “서버가 리플리케이션 규칙을 얻는 방법”를 참조.
• --replicate-ignore-table=db_name.tbl_name
동일한 명령문이 다른 모든 테이블을 업데이트 한다고 하더라도, 지정된 테이블을 업데이트 하는 모든 명령문은 복제하지
말도록 슬레이브에게 지시한다. 한 개 이상의 테이블을 무시하도록 지정하기 위해서는, 각각의 테이블 별로 한번씩 이 옵
션을 사용한다. 이것은 --replicate-ignore-db와는 반대로, 크로스-데이터 베이스 업데이트를 실행한다.

:::MySQL Korea:::
Section 6.9, “서버가 리플리케이션 규칙을 얻는 방법”를 참조.
• --replicate-rewrite-db=from_name->to_name
마스터 상에서 디폴트 데이터 베이스(즉, USE가 선택하는 것)가 from_name였다면, 그것을 to_name로 해석하도록 슬레
이브에게 지시한다. 테이블을 포함하는 명령문에만 영향을 주며 (CREATE DATABASE, DROP DATABASE, 그리고
ALTER DATABASE와 같은 명령문은 제외), 그리고 마스터 상에서 디폴트 데이터 베이스가 from_name일 경우에만 영
향을 준다. 이것은 크로스-데이터 베이스를 업데이트 하지는 않는다. 데이터 베이스의 이름을 해석하는 것은 --
replicate-* 규칙을 테스트 하기 전에 이루어 진다.
만일 여러분이 이 옵션을 명령어 라인에서 사용하고 ‘>’ 문자가 여러분이 사용하는 명령어 해석기에서 특수 문자로
받아 들여진다면, 인용 부호를 사용해서 이 옵션 값을 지정한다. 예를 들면:
shell> mysqld --replicate-rewrite-db="olddb->newdb"
• --replicate-same-server-id
슬레이브 서버에서 사용됨. 일반적으로 여러분은 디폴트 설정 값인 0을 사용하는데, 이것은 순환 리플리케이션(circular

replication)에 의한 무한 루프를 방지한다. 만일 1로 설정한다면, 슬레이브는 자신의 서버 ID를 가지고 있는 이벤트를 건
너 띄지 않게 된다. 일반적으로, 1로 설정하는 경우는 거의(rare) 없다. 만약에 --log-slave-updates가 사용된다면, 1
로 설정할 수가 없게 된다. 디폴트로, 슬레이브 I/O 쓰레드는 바이너리 로그 이벤트가 슬레이브의 서버 ID를 가지고 있는
경우에는 그것을 릴레이 로그이 기록조차 하지 않는다는 것을 알아두자 (이것은 디스크 사용량을 절감시키는데 도움이 된
다). 따라서, 만일 여러분이 --replicate-same-server-id를 사용하고자 한다면, 슬레이브 SQL 쓰레드가 실행하길 원
하는 이벤트를 읽게끔 만들기 전에 이 옵션과 함께 슬레이브가 실행되도록 해야 한다.
• --replicate-wild-do-table=db_name.tbl_name
업데이트된 모든 테이블이 지정된 데이터 베이스와 테이블 이름 패턴을 매치(match)하는 곳에서는 명령문을 리플리케이
션하는 것을 제한하도록 슬레이브 쓰레드에게 지시한다. 패턴에는 ‘%’ 및 ‘_’ 와일드 카드 문자가 포함될 수 있는데,
이것들은 LIKE 패턴-매칭 연산자에 대한 것과 동일한 의미를 가진다. 한 개 이상의 테이블을 지정하기 위해서는, 각각의
테이블 별로 한번씩 이 옵션을 사용한다. 이것은 크로스-데이터 베이스 업데이트를 실행한다. Section 6.9, “서버가 리
플리케이션 규칙을 얻는 방법”를 참조.
예제: --replicate-wild-do-table=foo%.bar%는 데이터 베이스 이름이 foo로 시작되고 테이블 이름이 bar로 시작되
는 곳에서 테이블을 사용하는 업데이트만을 복제한다
만일 테이블 이름의 패턴이 %이라면, 모든 테이블 이름 및 데이터베이스-레벨 명령문에도 적용되는 옵션들을 매치

:::MySQL Korea:::
(match)한다 (CREATE DATABASE, DROP DATABASE, 그리고 ALTER DATABASE). 예를 들면, 만일 여러분이
--replicate-wild-do-table=foo%.%를 사용한다면, 데이터 베이스 이름이 패턴 foo%와 매치가 되는 경우에 데이터
베이스-레벨 명령문을 복제한다.
데이터 베이스 또는 테이블 이름 패턴에 와일드 카드 문자를 포함 시키기 위해서는, 그 문자들은 백슬레시(backslash)를
사용해서 제외(escape) 시킨다. 예를 들면, my_own%db라는 이름의 데이터 베이스에 있는 모든 테이블은 복제하지만,
my1ownAABCdb 데이터 베이스로부터는 테이블을 복제하고 싶지 않다면, 여러분은 ‘_’ 와 ‘%’ 문자를 아래와 같
이 제외(escape) 시켜야 한다: --replicate-wild-do-table=my￦_own￦%db. 만일 여러분이 명령어 라인에서 이 옵
션을 사용한다면, 여러분이 사용하는 명령어 해석기에 따라서 옵션 값을 인용 부호나 이중(double) 백슬래시를 사용해서
지정해야 한다. 예를 들면, bash 쉘을 사용할 경우에는, --replicate-wild-do-table=my￦￦_own￦￦%db라고 입력
해야 한다.
• --replicate-wild-ignore-table=db_name.tbl_name
주어진 와일드카드 패턴과 테이블이 하나라도 매치가 되는 곳에서는 명령문 복제를 하지 못하도록 슬레이브 쓰레드에게
지시한다. 한 개 이상의 테이블을 무시하도록 지정하기 위해서는, 각각의 테이블 별로 한번씩 이 옵션을 사용한다. 이것은
크로스-데이터 베이스 업데이트를 실행한다. Section 6.9, “서버가 리플리케이션 규칙을 얻는 방법”를 참조할 것.
예제: --replicate-wild-ignore-table=foo%.bar%는 데이터 베이스 이름이 foo로 시작되고 테이블 이름이 bar로 시
작되는 곳에서 테이블을 사용하는 업데이트를 복제하지 않는다.
매칭 작업이 어떻게 이루어지는지에 대해서는, --replicate-wild-do-table 옵션을 설명하는 부분을 참고한다. 옵션 값

에 와일드카드 문자를 포함하기 위한 규칙은 --replicate-wild-ignore-table에 적용되는 것과 동일하다.
• --report-host=slave_name
슬레이브 등록(registration)을 하는 동안에 마스터에 보고되는 슬레이브의 호스트 이름 또는 IP 번호. 이것은 마스터 서
버에서의 SHOW SLAVE HOSTS 실행 결과 값에서 얻을 수가 있다. 슬레이브를 마스터에 등록하고 싶지 않을 경우에는
이 값을 설정하는 않는다. 슬레이브의 접속 후에 TCP/IP 소켓에서 슬레이브의 IP 번호를 마스터가 단순히 읽는다는 것은
충분치가 못하다는 점을 알아두자. NAT와 다른 라우팅(routing) 이슈 때문에, 그 IP는 마스터 또는 다른 호스트에서 슬
레이브로 접속을 하기 위한 유효한 값이 안될 수도 있다.
• --report-port=slave_port_num
이것은 슬레이브가 등록되는 동안, 마스터에 보고가 되는 슬레이브 접속을 위한 TCP/IP 포트 번호다. 슬레이브가 디폴트
포트가 아닌 것을 주목(listen)하거나 또는 여러분이 마스터 서버 또는 다른 클라이언트에서 슬레이브로 접속을 하기 위
해 특별한 터널(tunnel)을 가지고 있는 경우에만 이 값을 설정한다. 확신이 없다면, 이 값을 설정하지 않는다.

:::MySQL Korea:::
• --skip-slave-start
서버가 시작될 때, 슬레이브 쓰레드는 시작하지 말도록 서버에게 지시한다. 나중에 슬레이브 쓰레드를 시작하기 위해서
는, START SLAVE 명령어를 사용한다.
• --slave_compressed_protocol={0|1}
이 옵션이 1로 설정되면, 슬레이브/마스터 프로토콜에 대해 압축을 사용한다 (양쪽 서버가 모두 지원을 할 경우).
• --slave-load-tmpdir=file_name
슬레이브가 임시 파일을 만드는 디렉토리의 이름. 이 옵션은 tmpdir 시스템 변수 값과 동일한 것을 디폴트로 사용한다. 슬
레이브 SQL 쓰레드가 LOAD DATA INFILE 명령문을 복제할 때, 이 쓰레드는 릴레이 로그에서 읽어와서 임시 파일에 저
장할 파일을 추출하고, 그 파일을 테이블에 전달한다. 만일 마스터에 있는 그 파일이 매우 큰 것이라면, 슬레이브에 있는
임시 파일도 역시 큰 것이 된다. 따라서, 이 옵션은 충분한 사용 가능 공간을 가지고 있는 파일 시스템내의 디렉토리에 임
시 파일을 저장하도록 슬레이브에 지시할 때 권장할 만한 것이 된다. 그와 같은 경우, 릴레이 로그 역시 크게 되며, 따라서
그 파일 시스템에 릴레이 로그를 놓아두기 위해서는 --relay-log 옵션을 또한 사용할 필요가 있다.
이 옵션으로 지정된 디렉토리는 디스크 기반의 파일 시스템(메모리 기반이 아님)에 위치해야 하는데, 그 이유는 LOAD
DATA INFILE를 복제하기 위한 임시 파일은 머신이 재 시작될 때에도 존재하고 있어야 하기 때문이다. 또한, 그 디렉토
리는 시스템 스타트업 과정 중에 OS가 제거할 수 없는 것이 되어야 한다.
• --slave-net-timeout=seconds
접속이 끊어졌고, 읽기가 중단되었으며, 따라서 재 접속을 시도해야 한다고 슬레이브가 판단을 하기 전에, 마스터에서 오
는 데이터를 기다리는 대기 시간. 첫 번째 재 접속은 이 타임 아웃이 끝나면 즉시 시도된다. 재 시도 간격(interval)은 --
master-connect-retry 옵션으로 제어할 수 있다.
• --slave-skip-errors=[err_code1,err_code2,...|all]
일반적으로, 슬레이브에서 에러가 발생되면 리플리케이션은 중단이 된다. 이를 통해 여러분은 데이터의 일관성을 수동으
로 해결할 수 있게 된다. 이 옵션은 옵션 값에 열거되어 있는 에러 중의 하나를 명령문이 리턴 하더라도 리플리케이션을 계
속 진행하도록 슬레이브 SQL 쓰레드에게 지시한다..
여러분이 에러 발생 원인에 대해 충분히 이해하고 있지 않으면 이 옵션을 사용하지 말도록 한다.만일 여러분의 리플리케이
션 설정과 클라이언트 프로그램에 오류가 없고(no bug), MySQL 자체에도 오류가 없다면, 리플리케이션을 중단 시키는
에러는 결코 발생하지 않는다.
에러 코드에 대해서는, 슬레이브 에러 로그와 SHOW SLAVE STATUS의 결과에 나와 있는 에러 메시지가 제공하는 번

:::MySQL Korea:::
호를 사용한다. Appendix B, Error Codes and Messages를 참조할 것.

:::MySQL Korea:::
제목검색
6.9. 서버가 리플리케이션 규칙을 얻는 방법
만일 마스터 서버가 명령문을 자신의 바이너리 로그에 기록하지 못한다면, 그 명령문은 복제가 되지 않는다. 만일 서버가 명령문을
6.9. 서버가 리플리케이션 규칙을 얻는 방법
로그 한다면, 그 명령문은 모든 슬레이브에 전달되고, 각 슬레이브는 전달 받은 명령문을 실행할지 말지를 결정한다.
6.9 서버가 리플리케이션 규칙을 얻는 방법
마스터 측면에서는, 로그 할 명령문은 바이너리 로깅을 제어하는 --binlog-do-db 와 --binlog-ignore-db 옵션에 따라서 결
정된다. 이 옵션을 평가하는데 사용하는 규칙에 대해서는 Section 5.12.3, “바이너리 로그”를 참조하기 바란다.
슬레이브 측면에서는, 마스터에서 전달된 명령문의 실행 여부는 슬레이브가 함께 실행한 --replicate-* 옵션에 따라 결정된다.
(Section 6.8, “리플리케이션 스타트업 옵션들”을 참조.) 슬레이브는 아래의 과정을 통해서 이 옵션을 평가하는데, 가장 먼저 검
사하는 것은 데이터베이스-레벨 옵션이며 그 다음에 테이블-레벨 옵션을 진행한다.
가장 단순한 경우, 아무런 --replicate-* 옵션이 없을 때에는, 마스터에서 전달 받은 모든 명령문을 슬레이브가 실행하도록 한
다. 그렇지 않은 경우에는, 주어진 옵션에 의존해서 이 평가 과정의 결과가 나온다. 일반적으로, 하나의 옵션 셋이 가질 영향에 대
해 보다 쉽게 평가하기 위해서는, “do” 와 “ignore” 옵션을 혼용하거나, 또는 와일드 카드와 일반 문자(non-wildcard) 옵션
을 혼용해서 사용하지 말 것을 권장한다.
Stage 1. 데이터 베이스 옵션 검사
이 단계에서는, 슬레이브는 데이터 베이스-관련 조건문을 지정하는 --replicate-do-db 또는 --replicate-ignore-db 옵션

이 존재하는지를 검사한다:
• No: 명령문을 허용하고 테이블-검사 단계로 이동.
• Yes: 명령문을 허용할지 무시할 지를 결정하기 위해 --binlog-do-db 와 --binlog-ignore-db 옵션에 적용한

것과 동일한 규칙을 사용해서 옵션을 테스트한다. 테스트의 결과는?
o Permit: 그 명령문을 곧장 실행하지 않음. 결정을 유보하고 테이블-감사 단계로 이동.

:::MySQL Korea:::
o Ignore: 그 명령문을 무시한 후에 빠져 나옴.
이 단계는 옵션-검사를 위해 명령문을 허용하거나, 또는 무시하게 만든다. 하지만, 이 단계에서 허용된 명령문은 실제로 아직 실행
되지는 않는다. 대신에, 그 명령문은 테이블 옵션을 검사하는 다음 단계로 전달된다.
Stage 2. 테이블 옵션 검사.
우선, 사전 조건으로서, 슬레이브는 그 명령문이 스토어드 함수 또는(5.0.12 이전에서는) 스토어드 프로시저 내에서 만들어 진 것
인지를 검사한다. 만일 그러하다면, 명령문을 실행하고 빠져 나온다. (MySQL 5.0.12 이후에는, 스토어드 프로시저가 이 테스트에
서 제외가 되었는데, 그 이유는 프로시저 로깅이 CALL 레벨이 아닌 루틴 내에서 실행되는 명령문 레벨에서 발생하기 때문이다.)
그 다음에는, 슬레이브는 테이블 옵션을 검사 및 평가 한다. 만일 서버가 이 시점에 도달하면, 테이블 옵션이 없는 모든 명령문은 실
행을 한다. 만일 “do” 테이블 옵션이 있다면, 명령문은 이 옵션들 중의 하나와 반드시 매치가 되어야 실행이 되게 된다; 그렇지 않
은 경우, 그 명령문은 무시 된다. 만일 “ignore” 옵션이 있다면, ignore 옵션과 매치가 되는 것을 제외한 모든 명령문은 실행된
다. 아래의 단계는 이 평가 과정을 보다 자세히 설명한다.
1. --replicate-*-table 옵션들이 있는가?
• No: 아무런 테이블 제약이 없고, 따라서 모든 명령문이 매치(match)가 된다. 그 명령문을 실행한 후에 빠
져 나온다.
• Yes: 테이블 제약 사항이 있다. 업데이트 해야 할 테이블을 평가한다. 업데이트 해야 할 테이블이 여러 개 있

을 수 있고, 따라서 매치 되는 옵션을 찾기 위해서 각 테이블에 대해 아래의 과정을 반복(loop) 실행한다 (우선
와일드카드 문자가 없는 옵션을 하고, 나중에 일반 문자 옵션을 한다). 업데이트 해야 할 테이블에 대해서만 옵션
을 비교한다. 예를 들면, 만일 명령문이 INSERT INTO sales SELECT * FROM prices라면, sales만 옵션 비교
를 한다. 몇몇 테이블을 업데이트 해야 한다면 (다중-테이블 명령문), “do” 또는 “ignore” 과 매치되는 테이
블이 가장 먼저 실행된다. 즉, 서버는 이 옵션에 대해 첫 번째 테이블을 검사한다. 아무런 결정을 하지 못했다면,
두 번째 테이블, 세 번째 테이블로 검사를 진행한다.
2. --replicate-do-table 옵션들이 있는가?
• Yes: 테이블이 이 옵션들 중의 하나와 매치가 되는가?

:::MySQL Korea:::
o No: 다음 단계로 이동.
o Yes: 명령문을 실행하고 빠져 나옴.
3. --replicate-ignore-table 옵션들이 있는가?
o Yes: 명령문을 무시하고 빠져 나옴.
4. --replicate-wild-do-table 옵션들이 있는가?
o Yes: 명령문을 실행하고 빠져 나옴.
5. --replicate-wild-ignore-table 옵션들이 있는가?
o Yes: 명령문을 무시하고 빠져 나옴.
6. 아무런 --replicate-*-table 옵션도 매치되지 않았음. 이러한 옵션들에 대해 테스트를 진행할 다른 테이블이 있는
가?
• No: 업데이트할 모든 테이블을 테스트 했으며 어떠한 옵션도 매치되지 않았음. --replicate-do-table 또
는 --replicate-wild-do-table 옵션이 있는가?
o No: 아무런 “do” 테이블 옵션이 존재하지 않았으며, 따라서 어떠한 “do” 매치도 필요하지 않
음. 명령문을 실행하고 빠져 나옴.
o Yes: “do” 테이블 옵션이 있었으며, 따라서 이 옵션과 확실히 매치되는 것만을 가지고 명령문을
실행된다. 다른 명령문은 무시되고 빠져 나옴.

:::MySQL Korea:::
• Yes: 루프 실행.
예제:
• --replicate-* 옵션이 전혀 없음
슬레이브는 마스터에서 받는 모든 명령문을 실행한다.
• --replicate-*-db 옵션, 그러나 테이블 옵션은 없음
슬레이브는 데이터 베이스 옵션을 사용해서 명령문을 허용 또는 무시한다. 그런 다음에, 테이블에 대한 아무런 제약도 없
기 때문에 이 옵션이 허용하는 모든 명령문을 실행한다.
• --replicate-*-table 옵션, 하지만 데이터 베이스 옵션은 없음
데이터 베이스 조건이 없기 때문에 모든 명령문은 데이터 베이스-검사 단계에서 허용 되어 진다. 슬레이브는 테이블 옵션
에 따라 명령문을 실행 또는 무시한다.
• 데이터 베이스 및 테이블 옵션을 함께 사용
슬레이브는 데이터 베이스 옵션을 사용해서 명령문을 허용 또는 무시한다. 그런 다음에 테이블 옵션에 따라서 이 옵션이
허용한 모든 명령문을 평가한다. 몇몇 경우에, 이 과정은 다소 반직관적인(counterintuitive) 결과를 만들기도 한다. 아래
와 같은 옵션 셋을 고려해 보자:
[mysqld]
replicate-do-db = db1
replicate-do-table = db2.mytbl2
db1은 디폴트 데이터 베이스이며 슬레이브는 다음의 명령문을 받는다고 가정한다:
INSERT INTO mytbl1 VALUES(1,2,3);
데이터 베이스는 db1이며, 이것은 데이터 베이스-검사 단계에서 --replicate-do-db 옵션과 매치가 된다. 그런 후에,
테이블-검사 단계로 이동한다. 만일 테이블 옵션이 없다면, 명령문은 실행된다. 하지만, 옵션에 “do” 테이블 옵션이 포
함되어 있기 때문에, 명령문이 실행되기 위해서는 반드시 매치가 되어야 한다. 명령문은 매치가 되지 않았고, 따라서 그 명

:::MySQL Korea:::
령문은 무시가 된다. (db1에 있는 모든 테이블에서도 동일한 일이 발생한다)

:::MySQL Korea:::
제목검색
6.10. 리플리케이션 FAQ
Q: 마스터가 구동 중에 있고 이 서버를 멈추지 않고 슬레이브를 구성할 수 있는가?
6.10. 리플리케이션 FAQ
6.10 리플리케이션 FAQ A: 여러 가지 방법이 있다. 만일 여러분이 어느 시점의 마스터 스냅샷 백업을 만들어 두었고 그 스냅샷에 대응하는 바이너리 로그
파일 이름과 오프셋(SHOW MASTER STATUS의 결과로부터)을 기록해 두었다면, 아래의 과정을 사용한다:
1. 슬레이브에 고유의 서버 ID가 할당되었는지 확인한다.
2. 슬레이브에서 아래의 명령문을 실행한다.(각 옵션에 적당한 값을 채움):
3. mysql> CHANGE MASTER TO
4. -> MASTER_HOST='master_host_name',
5. -> MASTER_USER='master_user_name',
6. -> MASTER_PASSWORD='master_pass',

:::MySQL Korea:::
7. -> MASTER_LOG_FILE='recorded_log_file_name',
8. -> MASTER_LOG_POS=recorded_log_position;
9. 슬레이브에서 START SLAVE를 실행한다.
만일 여러분이 마스터 서버의 백업을 가지고 있지 않다면, 아래의 방법으로 백업을 생성한다. 모든 과정은 마스터 호스트에서 실행
되어야 한다.
1. 글로벌 읽기 잠금을 얻기 위해 아래의 명령문을 입력:
3. 잠금 상태에서, 아래의 명령어(또는 유사한 형태)를 실행:
4. shell> tar zcf /tmp/backup.tar.gz /var/lib/mysql
5. 아래의 명령문을 입력하고 그 결과를 기록한다(나중에 필요함):
6. mysql> SHOW MASTER STATUS;
7. 잠금을 해제:
8. mysql> UNLOCK TABLES;
바이너리 복사를 하기 위한 다른 방법은 마스터의 SQL 덤프(dump)를 만드는 것이다. 이렇게 하기 위해서는, 마스터에서
mysqldump --master-data를 사용하고 그런 다음에 슬레이브로 덤프를 한 것을 로드한다. 하지만, 이 방법은 바이너리 복사보
다 속도가 느리다.
여러분이 어떤 방법을 사용하든지 상관 없이, 여러분이 스냅샷과 로그 파일 이름 및 오프셋에 대한 기록을 가지게 되면 위의 지침

을 따라 다음 과정을 진행한다. 여러분은 동일한 스냅샷을 사용해서 여러 대의 슬레이브를 설정할 수가 있다. 일단 마스터의 스냅샷

:::MySQL Korea:::
을 가지게 되면, 마스터의 바이너리 로그가 변경되지 않은 한 이것을 가지고 슬레이브를 설정할 수가 있게 된다.
여러분은 LOAD DATA FROM MASTER 명령문도 사용할 수가 있다. 이 명령문은 슬레이브에 스냅샷을 손쉽게 전달해 주며 로
그 파일 이름과 오프셋을 동시에 정렬을 한다. 하지만, 이 명령문은 MyISAM 테이블에 대해서만 동작을 하고 읽기 잠금을 오랫동
안 한다는 점을 주의하기 바란다. 아직까지는 우리가 원하는 만큼 효과적으로 구현되지는 않고 있다. 만일 여러분이 큰 테이블을 가
지고 있다면, 아직까지는 FLUSH TABLES WITH READ LOCK를 실행한 후에 마스터 서버에서 바이너리 스냅샷을 만드는 방법
이 더 많이 쓰이고 있다.
Q: 슬레이브는 항상 마스터에 접속을 하고 있어야 하는가?
A: 아니오, 그렇지 않다. 슬레이브를 여러 시간 또는 여러 날 동안 다운 시키거나 접속을 끊은 다음에, 나중에 다시 접속을 할 때 업

데이트 사항을 가져올 수 있다.
Q: 슬레이브가 얼마나 늦게 마스터와 비교가 되는지를 어떻게 알 수 있는가? 달리 말하면, 슬레이브가 마지막으로 명령문 복제를
한 날짜를 어떻게 알 수 있는가?
A: 여러분은 SHOW SLAVE STATUS에 있는 Seconds_Behind_Master를 보면 된다. Section 6.3, “리플리케이션 구현 상세

설명”를 참조할 것.
슬레이브 SQL이 마스터에서 읽어온 이벤트를 실행할 때, 자신의 시간을 이벤트 타임 스템프로 수정을 한다. (이것이
TIMESTAMP가 잘 복제되는 이유다.) in the output of SHOW PROCESSLIST의 결과 값에 있는 Time 컬럼에서, 슬레이브
SQL 쓰레드를 디스플레이 하기 위한 시간은 마지막으로 복제된 타임 스탬프와 슬레이브 머신의 실제 시간 사이의 시간이 된다. 여
러분은 이것을 사용햇 마지막으로 이벤트를 복제한 날짜를 알아낼 수가 있게 된다. 만일 여러분의 슬레이브가 마스터와 1 시간 동
안 접속을 하지 않았고, 그 다음에 다시 접속을 하였다면, 여러분은 SHOW PROCESSLIST에서 슬레이브 SQL 쓰레드에 대한
3600의 Time 값을 볼 수가 있을 것이다. 이것은 슬레이브가 한 시간 전의 명령문을 실행하기 때문이다.
Q: 슬레이브가 가져 갈 때까지 업데이트를 강제로 막도록 서버를 제어하는 방법은 무엇인가?
A: 아래의 과정을 사용한다:
1. 마스터에서, 아래의 명령문을 실행한다:

:::MySQL Korea:::
3. mysql> SHOW MASTER STATUS;
SHOW 명령문의 결과를 가지고 리플리케이션 좌표(coordinate)(로그 파일 이름과 오프셋)를 기록한다.
4. 슬레이브에서, 아래의 명령문을 입력하는데, MASTER_POS_WAIT() 함수에 대한 인수는 바로 전 단계에서 얻어

진 리플리케이션 좌표를 사용한다:
5. mysql> SELECT MASTER_POS_WAIT('log_name', log_offset);
SELECT 명령문은 슬레이브가 지정한 로그 파일과 오프 셋에 도달할 때까지 막는다. 그 시점이 되면, 슬레이브는 마스터
와 동기화(synchrony)되고 명령문은 리턴된다.
6. 마스터에서는, 업데이트 과정을 다시 시작하도록 아래의 명령문을 입력한다:
7. mysql> UNLOCK TABLES;
Q: 양방향(two-way) 리플리케이션을 설정할 때 고려해야 하는 사항은 무엇이 있는가?
A: MySQL 리플리케이션은 분산(cross-server) 업데이트 원소(atomicity)를 보장하기 위해서 마스터와 슬레이브간의 어떠한
잠금 프로토콜도 현재까지는 지원하지 않는다. 달리 표현하면, 클라이언트 A가 co-master 1에 업데이트를 만드는 것은 가능하
고, 일정 시간 동안, 그것이 co-master 2로 전달 되기 전에, 클라이언트 B는 co-master 1에서 했던 것과는 다르게 클라이언트 A
의 업데이트를 만드는 co-master 2에 업데이트를 만들 수가 있게 된다. 따라서, 클라이언트 A의 업데이트가 when the update
of client A makes it to co-master 2에 만들어 질 때, 비록 co-master 2에서 일어나는 모든 업데이트가 전달이 된다고 하더라
도, 그 업데이트는 여러분이 co-master 1에서 가지고 있는 것과는 다른 테이블을 만들게 된다. 이것은 업데이트가 어떤 순서로 진
행되든지 간에 안전하게 일어난다고 확신하거나, 또는 클라이언트 코드에서 잘못된 순서의 업데이트를 주의하지 않는 이상 양방향
(two-way) 리플리케이션 관계에 있어서 두 대의 서버를 연결할 수 없다는 것을 의미한다..
여러분은 또한 양방향 리플리케이션이 실제로는 업데이트에 있어서는 성능 향상에 많은 도움이 되지 않는다는 점을 알고 있어야 한
다. 각 서버는, 하나의 서버가 실행하는 것과 같이, 반드시 동일한 숫자의 업데이트를 가지고 있어야 한다. 한가지 차이점은, 여기에
는 잠금 경쟁이 덜 존재한다는 것인데, 그 이유는 다른 서버에서 생기는 업데이트는 하나의 슬레이브 쓰레드에서 순차적으로
(serialize) 나열되기 때문이다. 이러한 장점 조차도 네트워크 지연(delay)으로 인해 반감(offset)되어질 수 있다.

:::MySQL Korea:::
Q: 리플리케이션을 어떻게 사용해야만 시스템 성능을 향상 시킬 수가 있는가?
A: 하나의 서버를 마스터로 설정하고 모든 것이 직접 그 서버에 작성 한다. 그런 다음에는 슬레이브를 구성하고, 마스터와 슬레이브
간의 읽기를 분산 시킨다. 또한, 슬레이브를 --skip-innodb, --skip-bdb, --low-priority-updates, 그리고 --delay-
key-write=ALL 옵션과 함께 시작을 해서 슬레이브 단의 속도를 향상시킬 수가 있다. 이와 같은 경우, 슬레이브는 InnoDB 와
BDB 테이블 대신에 논-트랜젝션(non-transactional) MyISAM 테이블을 사용해서 트랜젝션 총 비용(overhead)를 절약함으로
써 보다 개선된 속도를 얻을 수 있게 된다.
Q: 리플리케이션의 성능을 향상 시키기 위해서는 위해서는 어플리케이션의 클라이언트 코드를 어떻게 해 두어야 하는가?
A: 만약에 데이터 베이스 접근을 담당하는 클라이언트 코드 부분이 올바르게 요약/모듈화(abstracted/modularized) 되어 있다

면, 이것을 복제된 설정과 함께 구동되도록 변환 시키는 작업은 매우 손쉽고 간단하다. 작성되는 모든 것은 마스터에 전달되고, 읽
는 것은 마스터 또는 슬레이브에 전달하도록 데이터 베이스 접근 구현 방식을 수정한다. 만일 여러분의 코드가 이러한 레벨로 되어
있지 않다면, 복제 시스템을 여러분이 설정해야 한다. 아래의 함수를 구현하는 레퍼 라이브러리(wrapper library) 또는 모듈 생성
을 먼저 시작한다:
• safe_writer_connect()
• safe_reader_connect()
• safe_reader_statement()
• safe_writer_statement()
각 함수 이름의 safe_ 는 함수가 모든 에러 조건을 주의 깊게 다룬다는 것을 의미한다. 여러분은 다른 이름을 사용할 수 있다. 중요
한 것은 읽기와 쓰기를 하기 위한 접속을 위해서는 통일된 인터페이스(unified interface)를 가져야 한다는 것이다.
그런 다음에, 클라이언트 코드가 레퍼 라이브러리(wrapper library)를 사용할 수 있도록 변환 시킨다. 이 작업은 처음에는 매우 어
려운 것일 수 있지만, 결국은 보상을 받게 된다. 위에서 설명한 접근 방식을 사용하는 모든 어플리케이션은, 여러 대의 슬레이브를
포함한다고 하더라도, 마스터/슬레이브 구성에 있어서 장점을 가질 수 있게 된다. 코드는 관리하기가 수월하며, 문제 해결(trouble
shooting) 옵션을 추가하기가 쉬워진다.
Q: When and how much can MySQL 리플리케이션은 시스템 성능을 언제 그리고 얼마나 향상 시키는가?

:::MySQL Korea:::
A: MySQL 리플리케이션은 읽기는 자주 실행하되 쓰기는 덜 자주 실행하는 시스템에 유익하게 동작을 한다. 이론적으로는, 단일-
마스터/다중-슬레이브 설정을 사용해서, 네트워크의 대역폭(band-width)가 허락하는 한, 또는 마스터가 처리하지 못할 정도의
업데이트를 사용할 때까지 슬레이브를 추가해서 시스템을 확장할 수가 있다.
사용할 수 있는 슬레이브의 숫자를 계산하기 위해, 그리고 여러분의 사이트 성능을 얼마나 향상 시킬 수 있는지를 알아내기 위해서
는, 여러분의 쿼리 패턴을 알 필요가 있으며, 또한 전형적인 마스터와 슬레이브 상의 읽기(초당 읽기, 또는 reads)와 쓰기(writes)
에 대한 처리량(throughput) 사이의 관계를 밴치마킹 함으로써 경험적으로 알 필요가 있다. 여기의 예제는 가상의 시스템에 대한
리플리케이션을 가지고 여러분이 얻을 수 있는 다소 단순한 계산법을 보여 주는 것이다.
시스템 로드(load)가 10%의 쓰기와 90%의 읽기로 구성되고, 우리는 벤치마킹을 통해서 reads가 1200 – 2 × writes라는 사실
을 알아냈다고 하자. 다른 말로 표현하면, 시스템은 쓰기 없이 초당 1,200의 읽기를 실행할 수가 있고, 평균 쓰기는 평균 읽기 속도
의 2배 느리며, 선형 관계(linear relationship)이다. 마스터와 각 슬레이브는 동일한 시스템 용량을 가지고 있고, 그리고 우리는 하
나의 마스터와 N 개의 슬레이브를 가지고 있다고 가정한다:
reads = 1200 – 2 × writes
reads = 9 × writes / (N + 1) (읽기는 분산되지만, 쓰기는 모든 서버에서 이루어진다)
9 × writes / (N + 1) + 2 × writes = 1200
writes = 1200 / (2 + 9/(N+1))
마지막 등식은 N 개의 슬레이브에 대한 최대 쓰기 숫자를 나타내는 것이며, 분당 1,200회의 최대 가능 읽기 비율과 쓰기 당 9번의

읽기가 주어진다는 것을 나타낸다..
이러한 분석은 다음과 같은 결론을 만들어 낸다:
• 만일 N = 0 (리플리케이션이 없다는 의미임)이면, 우리의 시스템은 대략 초당 1200/11 = 109 의 쓰기를 다룰 수

있다.
• 만일 N = 1이면, 우리는 초당 184번까지의 쓰기를 갖는다.

:::MySQL Korea:::
• 결국, N은 무한대로 증가하기 때문에 (그리고 우리의 예산은 유한하므로), 우리는 초당 거의 600번의 쓰기를 가질
수 있으며, 시스템의 처리량은 대략 5.5배 증가하게 된다. 하지만, 8대의 서버만을 가지고서는, 우리는 4배의 성능을 향상
시킬 수가 있다.
이러한 계산법은 네트워크의 대역폭과 서버의 다른 조건들을 무시한 것이라는 것을 알아두자. 대부분의 경우, 여러분은 N개의 리플
리케이션 슬레이브를 추가할 경우에 예상할 수 있는 결과를 정확히 예측할 수 없을 것이다. 하지만, 아래의 질문에 대답을 함으로
써, 여러분은 리플리케이션이 여러분의 시스템 성능을 얼마나 많이 향상 시킬 수 있는지를 판단하는데 도움을 얻을 수가 있을 것이
다:
• 여러분 시스템에서 읽기/쓰기의 비율은?
• 여러분이 읽기 로드를 줄인다면, 얼마나 많은 쓰기 로드를 서버가 처리할 수 있는가?
• 여러분이 사용하는 네트워크 대역폭에서 처리할 수 있는 슬레이브의 숫자는?
Q: 리던던시(redundancy) 또는 고 가용성(high-availability)을 제공하기 위해서는 리플리케이션을 어떻게 사용할 수 있는가?
A: 현재까지 사용할 수 있는 기능을 가지고서, 여러분은 하나의 마스터와 하나의 슬레이브(또는 여러 대의 슬레이브)를 구성해야
하고, 마스터가 동작 중인지를 검사하기 위해 마스터를 모니터링하는 스크립트를 작성해야 한다. 그런 다음에, 마스터가 동작을 하
지 않을 경우에는, 어플리케이션과 슬레이브에게 마스터를 바꾸도록 지시를 한다. 몇 가지 제안 사항:
• 슬레이브에게 자신의 마스터를 바꾸도록 지시하기 위해서는, CHANGE MASTER TO 명령문을 사용한다.
• 마스터의 위치에 대한 정보를 어플리케이션이 유지하기 위한 좋은 방법은 마스터에 대한 동적 DNS 엔트리를 가지

고 있는 것이다. bind와 함께nsupdate를 사용해서, 여러분은 DNS를 동적으로 업데이트할 수가 있다.
• 여러분의 슬레이브를 --log-bin 옵션은 사용하지만 --log-slave-updates를 없는 상태로 시작한다. 이 방법을

통해, 슬레이브는 여러분이 다른 슬레이브에서 STOP SLAVE; RESET MASTER, 그리고 CHANGE MASTER TO 명
령문을 입력하는 동시에 마스터로 동작할 준비를 하게 된다:
• WC

:::MySQL Korea:::
• ￦
• v
• WC----> M
• /|￦
• / | ￦
• v v v
• S1 S2 S3
이 다이어그램에서 보면, M은 마스터를, S는 슬레이브를, WC는 데이터 베이스 쓰기와 읽기를 입력하는 클라이언트를 가
리킨다; 데이터 베이스 읽기만을 입력하는 클라이언트는 표시되지 않았는데, 그 이유는 그런 클라이언트는 변환될
(switch) 필요가 없기 때문이다. S1, S2, 그리고 S3는 --log-bin는 사용하지만 --log-slave-updates는 사용하지
않고 구동되는 슬레이브다. 마스터로부터 슬레이브가 받는 업데이트는 --log-slave-updates가 지정되지 않는 한 바이
너리 로그에 로그 되지 않기 때문에, 각 슬레이브에 있는 바이너리는 초기에는 비어 있다. 만일 어떤 이유로 M을 사용할
수 없게 되면, 여러분은 슬레이브 중의 하나를 새로운 마스터로 만들 수가 있게 된다. 예를 들면, 만일 여러분이 S1를 가
져 온다면, 모든 WC는 S1를 향하게 되는데, 이것은 업데이트를 자신의 바이너리 로그에 로그하게 된다. S2 와 S3는 이
제 S1에서 복제를 하게 된다.
슬레이브를 --log-slave-updates 없이 구동 시켜야 하는 이유는, 여러분이 슬레이브 중의 하나를 새로운 마스터로 지

정할 경우에 슬레이브가 업데이트를 두 번 받는 것을 방지하기 위해서다. S1이 --log-slave-updates 활성화가 되어 있
다고 가정하자. 그렇게 되면, 이 서버는 M에서 자신의 바이너리 로그로 전달되는 업데이트를 쓰게 된다. S2가 자신의 서버
를 M에서 S1로 변경할 때, 이 서버는 이미 M에서 전달 받았던 업데이트를 S1에서도 받을 수도 있다.
모든 슬레이브는 자신의 릴레이 로그에 있는 모든 명령문을 실행했다는 것을 확인 하자. 각각의 슬레이브에서, STOP
SLAVE IO_THREAD를 입력하고, 그런 다음에 여러분이 Has read all relay log를 볼 수 있을 때까지 SHOW
PROCESSLIST의 결과를 검사한다. 모든 슬레이브에 대해 이것이 확인(true)되면, 모든 슬레이브를 새로운 설정으로 재
구성할 수 있게 된다. 새로운 마스터가 된 슬레이브 S1에서, STOP SLAVE 와 RESET MASTER를 입력한다.
다른 슬레이브 S2 와 S3에서는, STOP SLAVE 와 CHANGE MASTER TO MASTER_HOST='S1' ('S1'은 S1의 실제

:::MySQL Korea:::
호스트 이름임)를 사용한다. CHANGE MASTER를 실행하기 위해서는, S2 또는 S3에서 S1 로 어떻게 접속이 이루어 지
는지에 대한 모든 정보를 추가한다(user, password, port). CHANGE MASTER에서는, S1'의 바이너리 로그 이름 또는
읽어올 바이너리 로그의 위치를 지정할 필요가 없다: 우리는 그것이 첫 번째 바이너리 로그이며 포지션 4에 있다는 것을
알고 있으며, CHANGE MASTER에 대한 디폴트라는 것을 알고 있다. 마지막으로 S2 와 S3에서, START SLAVE를 입
력한다.
그 다음에는 모든 WC에게 자신의 명령문을 S1에 전달하도록 지시한다. 그 시점 이후에, WC가 S1에게 보내는 모든 업데
이트 명령문은 S1의 바이너리 로그에 쓰여지게 되는데, 이 바이너리 로그는 since M가 다운된 이후에 S1에게 전달된 모
든 업데이트 명령문을 가지고 있다. .
결과는 다음과 같이 구성된다:
WC
WC | M(unavailable)
￦ |
￦ |
vv
S1<--S2 S3
^ |
+-------+
M이 다시 올라오게 되면(up again), 여러분은 S2 와 S3에서 입력했던 것과 동일한 CHANGE MASTER 를 M에서 입력

:::MySQL Korea:::
해야 하는데, 이렇게 되면 M은 S1의 슬레이브가 되고, M이 다운되어 있는 동안 놓쳤던 모든 WC의 쓰기를 가져오게 된
다. M을 마스터로 다시 만들기 위해서는 (예를 들면, M이 가장 성능이 좋은 머신이기 때문에), S1이 사용할 수 없게 되었
고 그리고 M이 새로운 마스터가 되는 것처럼 해서 위의 과정을 진행하면 된다. 이 과정 동안에는, S1, S2, 그리고S3를 M
의 슬레이브로 만들기 전에 M에서 미리 RESET MASTER를 구동 시켜야 한다는 것은 잊지 말기 바란다. 그렇지 않으면,
S1, S2, 그리고S3는 M을 사용할 수 없는 시점이 되기 전에 구형의 WC 쓰기를 가져올 수도 있게 된다.
Q: 여러 개의 OS 시스템상에서도 리플리케이션이 동작을 하는가(예를 들면, 마스터에서는 리눅스가 돌고, 슬레이브는 Mac OS와
윈도우가 구동됨)?
A: 예.
Q: 여러 개의 하드웨어 아키텍처상에서도 리플리케이션이 동작되는가 (예를 들면, 마스터는 64-비트 머신이며, 슬레이브는 32-
비트 머신임)?
A: 예.

:::MySQL Korea:::
제목검색
6.11. 리플리케이션 문제 해결
만일 여러분이 지침을 그대로 따라서 실행을 하였지만 리플리케이션 설정이 동작을 하지 않는다면, 처음으로 해야 할 일은 에러 로
6.11. 리플리케이션 문제 해결
그 메시지를 검사하는 것이다. 많은 사용자들이 이 작업을 수행하지 않고 시간만 허비하고 있다.
6.11 리플리케이션 문제 해결
만일 여러분이 에러 로그를 통해서도 문제의 원인을 발견할 수가 없다면, 아래의 방법을 시도해 본다:
• SHOW MASTER STATUS 명령문을 입력해서 마스터 서버가 바이너리 로깅이 활성화 되었는지를 검증한다. 만일
활성화 되어 있다면, Position은 0이 아닌 값이 된다. 만일 활성화가 되어 있지 않다면, 여러분이 마스터를 --log-bin
과 --server-id 옵션을 가지고 구동 시켰는지 검증한다.
• 슬레이브가 구동 중인지를 검증한다. SHOW SLAVE STATUS를 사용해서 Slave_IO_Running 과

Slave_SQL_Running 값이 모두 Yes인지를 검사한다. 만일 아니라면, 슬레이브 서버를 시작할 때 사용한 옵션을 검사한
다. 예를 들면, --skip-slave-start는 여러분이 START SLAVE 명령문을 입력할 때까지는 슬레이브 쓰레드가 시작되
지 못하도록 한다.
• 만일 슬레이브가 구동 중이라면, 마스터와 접속이 이루어져 있는지를 검사한다. SHOW PROCESSLIST를 사용해
서, I/O 와 SQL 쓰레드를 찾고 State 컬럼을 검사한다. Section 6.3, “리플리케이션 구현 상세 설명”을 참조. 만일 I/O
쓰레드 상태가 Connecting to master라고 한다면, 마스터에 있는 리플리케이션 사용자에 대한 권한, 마스터 호스트 이
름, 그리고 DSN 설정을 검사해서, 슬레이브가 접근할 수 있도록 되어 있는지를 알아본다.
• 만일 슬레이브가 동작은 했었지만 멈춰버렸다면, 일반적으로는 마스터에서 진행되었던 명령문들이 슬레이브에서는

실패를 했기 때문이다. 만일 여러분이 마스터의 스냅샷을 올바르게 가지고 있고, 그리고 슬레이브 쓰레드 밖에 있는 슬레
이브 상에서 데이터를 결코 수정하지 않았다면, 이러한 일은 결코 발생하지 않는다. 만일 슬레이브가 예상과 달리 멈춰 버
렸다면, 그것은 버그 또는 Section 6.7, “리플리케이션 기능들과 알려져 있는 문제점들”에서 설명한 리플리케이션 제약
사항으로 인한 것일 것이다. 만일 버그로 인한 것이라면, Section 6.12, “리플리케이션 버그와 문제점 보고하기”를 참조
해서 레포트를 하기 바란다.
• 만일 마스터에서 진행되었던 명령문들이 슬레이브에서는 거부가 되었다면, 슬레이브의 데이터 베이스를 삭제하고 마

:::MySQL Korea:::
스터에서 새로운 스냅샷을 복사함으로써 전체 데이터 베이스를 재 동기화(resynchronization)할 수 없다면, 아래의 과정

을 시도해 본다:
1. 슬레이브 상에 있는 영향을 받는 테이블이 마스터 테이블과 다른지를 검사한다. 이런 일이 발생한 원인을 알

아보도록 한다. 그런 다음에 슬레이브의 테이블을 마스터의 테이블과 같게 만들고 START SLAVE를 실행한다.
2. 앞의 과정이 동작을 하지 않거나 또는 적용이 되지 않을 경우에는, 수동으로 업데이트를 하는 것이 안전한지

를 판단하고 마스터에서 오는 그 다음 명령문을 무시한다.
3. 만일 마스터에서 오는 그 다음 명령문을 무시하기로 결정했다면, 아래의 명령문을 입력한다:
4. mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N;
5. mysql> START SLAVE;
N의 값은, 마스터에서 오는 그 다음 명령문이 AUTO_INCREMENT 또는 LAST_INSERT_ID()를 사용하지 않

는다면, 1이 된다. 그렇지 않으면, 그 값은 2가 된다. The reason for using a value of 2 for statements that
use AUTO_INCREMENT 또는 LAST_INSERT_ID()를 사용하는 명령문에 대해 2의 값을 사용하는 이유는,
이것들이 마스터의 바이너리 로그에서 두 개의 이벤트를 가져가지 때문이다.
6. 만일 슬레이브가 마스터와 완벽하게 동기화 된 상태로 시작되었고, 그리고 슬레이브 쓰레드 외부에 업데이
트된 테이블이 없다고 확신을 한다면, 이것은 버그로 인한 불일치라고 생각할 수가 있다. 만일 여러분이 가장 최
신의 MySQL 버전을 사용하고 있다면, 발생된 문제점을 레포트해 주길 바란다. 만일 여러분이 예전 버전을 사용
하고 있다면, 해당 문제점이 계속 발생되는지 알아보기 위해 최신 버전의 제품으로 업그레이드를 하도록 한다.

:::MySQL Korea:::
제목검색
6.12. 리플리케이션 버그와 문제점 보고하기
여러분이 생각하기에 사용자 에러가 없다고 판단을 하고, 리플리케이션이 전혀 동작을 하지 않거나 또는 여전히 불안정하다면, 버
6.12. 리플리케이션 버그와 문제점 보고하기
그 레포트를 보내 주길 바란다. 우리가 버그를 추적하기 위해서는, 가능하면 많은 정보를 여러분께서 보내 주길 바란다.
6.12 리플리케이션 버그와 문제점 보고하기
만일 여러분이 버그를 보여 줄 수 있는 테스트 케이스를 가지고 있다면, Section 1.8, “버그 및 문제점 보고 방법”에서 설명하는
방법을 사용해서 우리의 버그 데이터 베이스에 넣어 주길 바란다. 만일 여러분이 “phantom” 문제를 가지고 있다면 (여러분이 전
혀 복제할 수 없는 것), 아래의 과정을 사용하기 바란다:
1. 사용자 에러가 없다는 것을 검증한다. 예를 들면, 만일 여러분이 슬레이브 쓰레드 외부에서 슬레이브를 업데이트 한
다면, 데이터는 동기화가 되지 않으며, 그리고 여러분은 업데이트에 대한 고유의 키 위반을 가지게 된다. 이와 같은 경우,
슬레이브 쓰레드는 멈추게 되고 테이블간의 동기화를 만들기 위해 여러분이 수동으로 테이블을 정리하도록 대기한다. 이
것은 리플리케이션 문제가 아니다.
2. 슬레이브를 --log-slave-updates 및 --log-bin 옵션과 함께 구동한다. 이 옵션들은 마스터에서 자신의 바이너

리 로그로 전달 받은 업데이트를 슬레이브가 로그 하도록 만든다.
3. 리플리케이션 상태를 리셋 하기 전에 모든 증거를 저장한다. 여러분이 저장해야 할 정보는:
• 마스터의 모든 바이너리 로그
• 슬레이브의 모든 바이너리 로그
• 여러분이 문제를 발견한 시점의 마스터에서의 SHOW MASTER STATUS 결과
• 여러분이 문제를 발견한 시점의 슬레이브에서의 SHOW SLAVE STATUS 결과
• 마스터와 슬레이브에서의 에러 로그
4. 바이너리 로그를 검사하기 위해서 mysqlbinlog를 사용한다. 아래의 사항은 문제가 있는 명령문을 찾는데 도움이 될
것이다. log_pos 및 log_file은 SHOW SLAVE STATUS의 결과에 있는 Master_Log_File 및 Read_Master_Log_Pos
값이다.

:::MySQL Korea:::
5. shell> mysqlbinlog -j log_pos log_file | head
문제에 대한 증거를 수집한 후에, 우선 이것들을 별개의 테스트 테이스로 구분하도록 한다. 그런 다음에, Section 1.8, “버그와 문
제점 보고 방법”에서 설명하는 방법을 사용해서 가능한 한 많은 정보를 우리의 버그 데이터 베이스에 전달하기 바란다.

:::MySQL Korea:::
제목검색
6.13. 다중 마스터 리플리케이션에서 자동 인크리먼트
여러 대의 서버를 리플리케이션 마스터로 구성을 할 때에는, When multiple servers are configured as replication masters,
6.13. 다중 마스터 리플리케이션에서 자동 인
special steps must be taken to prevent key collisions when using AUTO_INCREMENT 컬럼을 사용할 때 키 콜레션
크리먼트
(collision)을 피하기 위해는 특별한 단계를 거쳐야 하는데, 그렇지 않으면 다중 서버는 열을 삽입할 때 동일한
6.13 다중 마스터 리플리케이션에서 자동 인크리먼
AUTO_INCREMENT 값을 사용하고자 할 것이다.
트
auto_increment_increment 및 auto_increment_offset 시스템 변수는 다중-마스터 리플리케이션이 AUTO_INCREMENT 컬럼

을 가질 수 있도록 도와 준다. 각각의 이러한 변수들은 디폴트 값을 가지고 있으며 최소 1에서 최대 65,535의 값을 가진다. 이것들
은 MySQL 5.0.2에서 추가되었다.
이 두 개의 변수들은 AUTO_INCREMENT 컬럼 동작에 아래와 같이 영향을 준다:
• auto_increment_increment는 연속해서 나오는 AUTO_INCREMENT 값들 사이의 인크리먼트(increment)를 제

어 한다.
• auto_increment_offset는 AUTO_INCREMENT 컬럼 값의 시작점을 결정한다.
서로 다른 마스터 상에서 충돌이 되지 않는 값을 선택함으로써, 다중-마스터 구성상의 서버들은 새로운 열을 동일 테이블에 삽입

할 때 AUTO_INCREMENT 값이 충돌 되지 않도록 사용하게 된다. N 개의 마스터 서버를 설정하기 위해서는, 아래와 같이 변수
를 설정한다:
• 각각의 마스터에서 auto_increment_increment 를 N 으로 설정한다.
• 1, 2, …, N를 사용해서, 각각의 N 마스터가 서로 다른 auto_increment_offset를 가지도록 설정한다. 1, 2, …, N를

사용해서, 각각의
auto_increment_increment 및 auto_increment_offset에 대한 보다 자세한 정보는 Section 5.2.2, “서버 시스템 변수”를 참조

:::MySQL Korea:::
할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 7. 최적화(Optimization)
7. 최적화(Optimization) 7.1. 최적화 소개

7 최적화(Optimization) 7.1.1. MySQL 디자인상의 제약 사항 및 트레이드오프(Tradeoff)
7.1 최적화 소개 7.1.2. 이식성(Portability)을 갖도록 어플리케이션 디자인하기
7.1.1 MySQL 디자인상의 제약 사항 및 트레이드오프(Tradeoff) 7.1.3. MySQL에 사용된 것들
7.1.2 이식성(Portability)을 갖도록 어플리케이션 디자인하기 7.1.4. MySQL 벤치 마크 슈트

7.1.5. 여러분 자신의 벤치 마크 사용하기
7.1.3 MySQL에 사용된 것들
7.1.4 MySQL 벤치 마크 슈트
7.2. SELECT 및 다른 명령문 최적화 하기
7.2.1. EXPLAIN 을 가지고 쿼리 최적화 하기
7.1.5 여러분 자신의 벤치 마크 사용하기
7.2.2. 쿼리 성능 추정하기
7.2 SELECT 및 다른 명령문 최적화 하기
7.2.3. SELECT 쿼리의 속도
7.2.1 EXPLAIN을 사용해서 쿼리 최적화 하기
7.2.4. WHERE 구문 최적화
7.2.2 쿼리 성능 추정하기
7.2.5. 범위 최적화
7.2.3 SELECT 쿼리의 속도
7.2.6. 인덱스 병합 최적화
7.2.4 WHERE 구문 최적화
7.2.7. IS NULL 최적화
7.2.5 범위 최적화 7.2.8. DISTINCT 최적화
7.2.5.1 단일 부분 인덱스에 대한 범위 접근 방식 7.2.9. LEFT JOIN 및 RIGHT JOIN 최적화
7.2.5.2 다중 부분 인덱스에 대한 범위 접근 방식 7.2.10. 네스티드 조인(Nested Join) 최적화
7.2.6 인덱스 병합 최적화 7.2.11. 외부 조인(Outer Join) 딘순화
7.2.6.1 인덱스 병합 교차 접근 알고리즘 7.2.12. ORDER BY 최적화
7.2.6.2 인덱스 병합 결합 접근 알고리즘 7.2.13. GROUP BY 최적화
7.2.6.3 인덱스 병합 정렬-결합 접근 알고리즘 7.2.14. LIMIT 최적화
7.2.7 IS NULL 최적화 7.2.15. 테이블 스캔을 피하는 방법

7.2.16. INSERT 명령문 속도
7.2.8 DISTINCT 최적화
7.2.17. UPDATE 명령문 속도

:::MySQL Korea:::
7.2.9 LEFT JOIN 및 RIGHT JOIN 최적화 7.2.18. DELETE 명령문 속도
7.2.10 네스티드 조인(Nested Join) 최적화 7.2.19. 다른 여러 가지의 최적화 팁(Tips)
7.2.11 외부 조인(Outer Join) 단순화 7.3. 잠금 이슈

7.3.1. 잠금 방법
7.2.12 ORDER BY 최적화
7.3.2. Table 잠금 이슈
7.2.13 GROUP BY 최적화
7.3.3. 동시 삽입
7.2.13.1 느슨한 인덱스 스캔(Loose index scan)
7.4. 데이터 베이스 구조 최적화
7.2.13.2 타이트한 인덱스 스캔(Tight index scan)
7.4.1. 디자인 선택
7.2.14 LIMIT 최적화
7.4.2. 데이터를 가능한 한 작게 만들기
7.2.15 테이블 스캔을 피하는 방법
7.4.3. 컬럼 인덱스
7.2.16 INSERT 명령문의 속도
7.4.4. 다중-컬럼 인덱스
7.2.17 UPDATE 명령문의 속도 7.4.5. MySQL은 인덱스를 어떻게 사용하는가
7.2.18 DELETE 명령문의 속도 7.4.6. MyISAM 키 캐시
7.2.19 다른 여러 가지의 최적화 팁(Tips) 7.4.7. MyISAM 인덱스 통계 수집
7.3 잠금 이슈 7.4.8. MySQL은 테이블을 어떻게 열고 닫는가
7.3.1 잠금 방법 7.4.9. 동일 데이터 베이스에서 많은 테이블을 생성하기 위한 드로우백(Drawback)
7.3.2 테이블 잠금 이슈 7.5. MySQL 최적화 하기
7.3.3 동시 삽입 7.5.1. 시스템 요소(Factor) 및 스타트업 파라미터 튜닝(Tuning)
7.4 데이터 베이스 구조 최적화 하기 7.5.2. 서버 파라미터 튜닝하기

7.5.3. 쿼리 옵티마이저(Optimizer) 성능 제어하기
7.4.1 디자인 선택
7.5.4. MySQL 속도에 영향을 주는 컴파일 및 링크
7.4.2 데이터를 가능한 한 작게 만들기
7.5.5. MySQL이 메모리를 사용하는 방법
7.4.3 컬럼 인덱스
7.5.6. MySQL이 DNS를 사용하는 방법
7.4.4 다중-컬럼 인덱스
7.6. 디스크 이슈
7.4.5 MySQL의 인덱스 사용 방법
7.6.1. 심볼릭 링크 사용하기
7.4.6 MyISAM 키 캐시
7.4.6.1 공유 키 캐시 접속
최적화는 이를 실행하고자 하는 시스템 전체에 대해 이해를 확실히 해야 하기 때문에 매우 복잡한 작업이
7.4.6.2 다중 키 캐시 된다. 비록 여러분이 어플리케이션 또는 시스템에 대해 약간의 지식을 가지고서 부분적인 로컬 최적화를
7.4.6.3 중간 삽입(Midpoint Insertion) 전략 할 수는 있더라도, 시스템을 보다 최적화를 시키고자 하면 할수록, 여러분이 알아야 할 부분이 더 많아지게
7.4.6.4 인덱스 프리 로딩(Preloading) 된다.

:::MySQL Korea:::
7.4.6.5 키 캐시 블럭 크기 이 장에서는 MySQL을 최적화 시키기 위한 여러 가지의 방법을 예제를 통해서 설명하도록 한다.
7.4.6.6 키 캐시 재 구축하기
7.4.7 MyISAM 인덱스 통계 수집
7.4.8 MySQL의 테이블 열기 및 닫기 방법
7.4.9 동일 데이터 베이스에 많은 테이블을 생성하기 위해 드로우 백
(drawback) 하기
7.5 MySQL 서버 최적화 하기

7.5.1 시스템 요소 및 스타트 업 파라미터 튜닝
7.5.2 서버 파라미터 튜닝
7.5.3 쿼리 옵티마이저 성능 제어하기
7.5.4 컴파일 및 링크 작업이 어떻게 MySQL 속도에 영향을 주는가
7.5.5 MySQL의 메모리 사용 방법
7.5.6 MySQL의 DNS사용 방법
7.6 디스크 이슈
7.6.1 심볼릭 링크 사용하기
7.6.1.1 유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기
7.6.1.2 유닉스에 있는 테이블에 대한 심볼릭 링크 사용하기
7.6.1.3 윈도우에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.1. 최적화 소개
7. 최적화(Optimization) 7.1.1. MySQL 디자인상의 제약 사항 및 트레이드오프(Tradeoff)

7.1. 최적화 소개 7.1.2. 이식성(Portability)을 갖도록 어플리케이션 디자인하기
7.1 최적화 소개 7.1.3. MySQL에 사용된 것들
7.1.1 MySQL 디자인상의 제약 사항 및 트레이드오프(Tradeoff) 7.1.4. MySQL 벤치 마크 슈트
7.1.2 이식성(Portability)을 갖도록 어플리케이션 디자인하기 7.1.5. 여러분 자신의 벤치 마크 사용하기

시스템을 빠르게 만들기 위해서 가장 중요한 것은 바로 시스템의 기본 디자인에 달려 있다. 여러분은 사용 중에 있
7.1.4 MySQL 벤치 마크 슈트
는 시스템이 어떤 종류의 프로세싱을 하고 있는지, 그리고 어떤 병목 현상(bottleneck)이 생기는지에 대해서도 알
7.1.5 여러분 자신의 벤치 마크 사용하기
고 있어야 한다. 대부분의 경우, 시스템 병목 현상은 아래와 같은 곳에서 발생하게 된다:
● 디스크 검색(Disk seeks). 디스크는 데이터 조각을 찾는데 시간을 소비한다. 최신의 디스크들은, 평균 검
색 시간이 보통10ms 이하이며, 따라서 우리는 이론적으로 초당 약 100 검색(seek)을 수행할 수 있게 된
다. 이 시간은 점진적으로 개선되고 있으며 단일 테이블에 대해 이것을 최적화 시키기는 매우 어렵다. 검색
시간을 최적화 할 수 있는 방법은 데이터를 한 개 이상의 디스크에 분산하는 것이다.
● 디스크 읽기 및 쓰기. 디스크가 올바른 위치에 있을 때, 우리는 데이터를 읽게 된다. 최신의 디스크들은, 하
나의 디스크가 최소 10–20MB/s의 처리량(throughput)을 나타낸다. 이것은 검색 보다 쉽게 최적화를 시
킬 수가 있는데, 그 이유는 여러분이 여러 개의 디스크에서 병렬로 데이터를 읽을 수 있기 때문이다.
● CPU 싸이클(cycle). 데이터가 메인 메모리에 있을 때, 우리는 이것을 처리해서 결과를 얻고자 한다. 메모리
에 비해 작은 양의 테이블을 가지는 것이 가장 일반적인 제약 요소이다. 하지만 작은 테이블을 가지고 있다
면, 속도는 문제가 되지 않는다.
● 메모리 대역폭(Memory bandwidth). When the CPU가 자신의 캐시가 보유할 수 있는 양보다 많은 데이터
를 필요로 하게 되면, 메인 메모리 대역폭에서 병목 현상이 발생한다. 이것은 대부분의 시스템에서는 일반적
으로 발생되지는 않는데, 하지만 이 점에 대하여는 인지를 하고 있어야 한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.1.1. MySQL 디자인상의 제약 사항 및 트레이드오프(Tradeoff)
7. 최적화(Optimization)
7.1. 최적화 소개 MyISAM 스토리지 엔진을 사용할 경우, MySQL은 다중 리더(reader) 또는 하나의 라이터(writer)를 허용하는 최
7.1.1 MySQL 디자인상의 제약 사항 및 트레이드오프(Tradeoff) 고 속도의 빠른 테이블 잠금을 사용한다. 이 스토리지 엔진이 가지고 있는 가장 큰 문제점은 여러분이 꾸준한 혼용
업데이트 스트림(stream)과 단일 테이블에서의 느린 선택을 가지고 있는 경우에 발생한다. 만일 특정 테이블에 대
해 이 문제가 발생을 한다면, 여러분은 그러한 테이블에 대해서는 다른 스토리지 엔진을 사용하도록 한다.
Chapter 14, 스토리지 엔진과 테이블 타입을 참조할 것.
MySQL은 트랜젝셔널(transactional) 및 논-트랜젝셔널(non-transactional) 테이블 모두와 함께 동작할 수가 있

다. 논-트랜젝셔널 테이블과 보다 부드럽게 동작을 하도록 만들기 위해서 (이 테이블은 무언가 잘못 되는 경우에는
롤백 할 수가 없다), MySQL은 아래의 규칙을 따르고 있다. 이러한 규칙은 스트릭트(strict) SQL 모드에서 동작을
하지 않을 경우, 또는 여러분이 INSERT 또는 UPDATE에 대해서 IGNORE를 사용할 경우에만 적용된다는 점을 알
아두기 바란다.
● 모든 컬럼은 디폴트 값을 가지고 있다.

● 만일 여러분이 적절하지 못하거나 또는 범위를 벗어난 값을 컬럼에 삽입할 경우, MySQL 은 에러를 보고하
는 대신에 “가장 가능성이 높은 값(best possible value)”을 컬럼에 설정한다. 숫자 값에 대해서는, 이것
은 0이 되며, 가장 가능성이 낮은 값 또는 가장 가능성이 높은 값으로 적용된다. 스트링 값에 대해서는, 이것
은 빈 스트링(empty string) 또는 컬럼에 저장할 수 있는 최대 크기의 스트링 중의 하나가 된다.
● 계산된 모든 수식은 에러 상태를 알려주는 대신에 사용할 수 있는 값을 리턴 한다. 예를 들면, 1/0은 NULL
을 리턴 한다.
위의 동작을 변경하기 위해서는, 여러분은 서버SQL 모드를 적당히 설정함으로써 스트릭터(stricter) 데이터 처리
를 활성화 시킬 수가 있다. 데이터 처리에 대한 보다 많은 정보는 Section 5.2.5, “서버 SQL모드”, 및
Section 13.2.4, “INSERT 신텍스”를 참조할 것

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.1.2. 이식성(Portability)을 갖도록 어플리케이션 디자인하기
7.1. 최적화 소개 모든 SQL 서버는 표준 SQL을 서로 다르게 구현하기 때문에, 이식 가능한 데이터 베이스로 작성을 해야 한다. 가장 단
7.1.2 이식성(Portability)을 갖도록 어플리케이션 디자인하기 순한 선택 및 삽입에 대해서 이식성을 갖도록 하는 것은 쉬운 일이지만, 점점 어려운 일을 처리할수록 여러분 더욱 더
많은 것을 알고 있어야 한다. 만일 여러분이 다양한 데이터 베이스 시스템에서 빠르게 동작되는 어플리케이션을 원할
경우, 일은 점점 어려워진다.
모든 데이터 베이스 시스템은 각기 서로 다른 장점 및 단점들을 가지고 있다.
복잡한 어플리케이션이 이식성을 갖도록 하기 위해서는, 이 어플리케이션을 어떤 SQL 서버와 구동을 시켜야 하는지를
결정해야 하고, 그 서버가 지원하는 기능에는 어떤 것들이 있는지를 파악해야 한다. 여러분은 데이터 베이스 서버를 선
택하는데 있어서, MySQL crash-me 프로그램을 사용해서 그 서버의 함수, 타입, 그리고 한계점을 파악할 수가 있을
것이다. crash-me이 모든 가능 기능들을 검사하지는 못하지만, 약 450번의 테스트를 거쳤기 때문에 믿고 사용할 수
는 있다. crash-me가 제공하는 정보의 예를 본다면, 만일 여러분이 Informix 또는 DB2를 사용하고자 한다면, 18개
문자 이상의 길이로 컬럼 이름을 사용할 수 없다는 것이다.
crash-me 프로그램과 MySQL 벤치마크는 모두 데이터 베이스와는 무관하게 동작한다. 이것들이 어떻게 작성되어 있
는지 잠시 살펴본다면, 여러분이 어플리케이션을 데이터베이스와 무관하게 만들기 위해서 해야 할 일이 어떤 것인지를
알 수 있게 될 것이다. 이 프로그램들은 MySQL 소스 배포판의 sql-bench 디렉토리에서 찾을 수가 있다. 이것들은
Perl로 쓰여졌고 DBI 데이터 베이스 인터페이스를 사용한다. 자체적으로 DBI를 사용함으로써 이식성에 관련된 문제
를 해결하고 있는데, 그 이유는 이 인터페이스가 데이터베이스-무관 접근 방식을 제공하기 때문이다. Section 7.1.4,
“MySQL 벤치 마크 슈트”를 참조할 것.
만일 여러분이 데이터베이스 무관성에 대해 노력을 하고 있다면, 각 SQL 서버의 병목 현상 문제에 대해서 잘 알고 있어

야 한다. 예를 들면, MySQL은 MyISAM 테이블에 대한 열 추출(retrieving) 및 업데이트는 매우 빠르게 처리하지만,

:::MySQL Korea:::
동일 테이블상에서 슬로우 리더(slow reader) 및 슬로우 라이터(slow writer)를 혼용해서 사용하면 문제가 생기게 된
다. 반면에, Oracle의 경우, 여러분이 최근에 업데이트를 한 열을 접근하고자 할 때에는 커다란 문제가 생기게 된다 (업
데이트한 것들이 디스크에 플러시 될 때까지는). 트랜젝셔널 데이터베이스 시스템은 일반적으로 로그 테이블에서 요약
테이블(summary table)을 만드는데 있어서는 그다지 좋게 동작으로 하지 않는데, 그 이유는 이와 같은 경우에는 열 잠
금(row locking)이 거의 쓸모가 없게 되기 때문이다.
여러분의 어플리케이션이 진정으로 데이터 베이스와 무관한 것이 되기 위해서는, 여러분이 처리하는 데이터가 사용하
는 인터페이스가 손쉽게 확장 가능한 것이 되도록 정의해야 한다. 예를 들면, C++은 거의 모든 시스템에서 사용 가능
한데, 따라서 여러분의 데이터 베이스에 대해서 C++ 클래스-기반의 인터페이스를 사용하는 것은 좋은 생각이 되는 것
이다.
만일 여러분이 주어진 데이터 베이스 시스템에 관련된 기능들을 사용하고 있다면 (예를 들면, MySQL에만 관련되어 있
는 REPLACE 명령문), 다른 SQL 서버에 대해서는 동일한 기능을 수행하도록 별도의 방식으로 코딩을 해야 한다. 비
록 이렇게 작성된 것들이 속도는 느릴지라도, 다른 SQL 서버가 동일한 업무를 처리할 수는 있게 된다.
MySQL을 사용한다면, 여러분은 /*! */ 신텍스를 사용해서 명령문에 MySQL-관련 키워드를 추가할 수가 있다. /* */
의 내부에 있는 코드는 대부분의 다른 SQL 서버에 의해 코멘트로 인식된다 (무시됨). 코멘트 작성에 대한 정보는,
Section 9.4, “코멘트 신텍스(Comment Syntax)”를 참조할 것.
만일 정확성 보다는 성능이 보다 중요한 요소일 경우, 여러분이 얻게 되는 모든 정보를 캐시하는 어플리케이션 레이어
(application layer)를 생성할 수도 있을 것이다. 일정 시간이 지난 후에는 이전의 결과를 없애 버림으로써, 여러분은
캐시를 참신한 상태로 유지 시킬 수 있게 된다. 이것은 고 부하 시스템을 처리하는 방법으로서, 이와 같은 경우, 여러분
은 캐시의 크기를 동적으로 증가 시킬 수가 있고 모든 것들이 정상적으로 될 때까지는 폐기 타임 아웃(expiration
timeout)을 높게 설정할 수가 있게 된다.
이와 같은 경우, 테이블 생성 정보는 초기 캐시의 크기와 테이블이 얼마나 자주 정상적으로 개선(refresh)되는지에 대

한 정보를 가지게 된다.
어플리케이션 캐시를 처리하는 또 하나의 매력적인 방법으로는 MySQL 쿼리 캐시를 사용하는 것이다. 쿼리 캐시를 활
성화 시킴으로써, 서버는 쿼리의 결과를 다시 사용할 수 있는지에 대한 여부를 상세하게 처리한다. 이를 통해 여러분의
어플리케이션은 단순화 된다. Section 5.14, “MySQL 쿼리 캐시”를 참조.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.1.3. MySQL에 사용된 것들
7.1. 최적화 소개 이 섹션에서는 예전에 MySQL에 포함되어 있었던 어플리케이션들에 대해 설명을 하기로 한다.

MySQL의 초기 개발 과정 동안에, MySQL의 기능들은 주로 우리의 대형 고객들의 요구에 맞도록 만들어졌는데, 이 기능들은 스웨
덴의 가장 큰 소매 업체들의 데이터를 처리하도록 설계되었다.
--- 이하의 내용은 기술적인 내용이 아닌 MySQL 개발 초기의 경험을 기술하고 있기 때문에
생략하기로 함 ---
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.1.4. MySQL 벤치 마크 슈트
7.1. 최적화 소개 벤치 마크 슈트는 주어진 SQL 동작이 제대로 구현되는지 여부를 사용자에게 알려준다. 여러분은 벤치 마크의 코드와 MySQL 소
7.1.4 MySQL 벤치 마크 슈트 스 배포판의 sql-bench 디렉토리에 있는 결과를 검토함으로써 벤치 마크가 어떻게 동작을 하는지를 알아볼 수가 있다.
이 벤치 마크는 아직은 단일 쓰레드로만 동작을 하며, 따라서 수행된 동작에 대해서는 최소의 시간을 계산한다는 점을 알아두자. 우
리는 향후에 다중 쓰레드 테스트를 추가할 예정이다.
벤치 마크 슈트를 사용하기 위해서는, 아래의 조건이 충족되어야 한다:
● 벤치 마크 슈트는 MySQL 소스 배포판에서 제공한다. 여러분은 http://dev.mysql.com/downloads/에서 다운로드를 하거

나, 또는 개발 소스 트리를 사용하도록 한다. (Section 2.8.3, “개발 소스 트리에서 설치하기”를 참조할 것.)
● 벤치 마크 스크립트는 Perl로 작성이 되었으며 데이터 베이스 서버에 대한 접근은 Perl DBI 모듈을 사용하고 있고, 따라서
DBI가 설치되어 있어야 한다. 또한, 여러분은 테스트 하고자 하는 각각의 서버에 대해 서버-관련 DBD 드라이버도 가지고
있어야 한다. 예를 들면, MySQL, PostgreSQL, 그리고 DB2를 테스트 하기 위해서는, 여러분은 DBD::mysql, DBD::Pg,
그리고 DBD::DB2 모듈을 설치해야 한다. Section 2.13, “Perl 설치 노트”를 참조할 것.
MySQL 소스 배포판을 다운 로드한 다음에는, 여러분은 sql-bench 디렉토리에서 벤치 마크 슈트를 볼 수가 있다. 벤치 마크 테스

트를 구동 시키기 위해서는, MySQL를 구축하고, 그 다음에 sql-bench 디렉토리로 이동한 다음에 run-all-tests 스크립트를 실
행한다:
shell> cd sql-bench
shell> perl run-all-tests --server=server_name
server_name은 지원되는 서버 중의 하나의 이름이다. 모든 옵션 및 지원 서버의 리스트를 얻기 위해서는, 아래의 명령어를 호출한

:::MySQL Korea:::
다:
shell> perl run-all-tests --help
crash-me 스크립트도 sql-bench 디렉토리에 있다. crash-me는 데이터 베이스 시스템이 지원하는 기능이 무엇이며 실제로 구
동 중인 쿼리의 능력 및 제약 사항이 어떤 것인지를 알아 보기 위해 사용된다. 예를 들면, 이것을 아래의 것들을 알아낸다:
● 지원되는 데이터의 타입
● 지원되는 인덱스의 숫자
● 지원되는 함수
● 얼마나 큰 쿼리를 실행할 수 있는지
● 얼마나 큰 VARCHAR 컬럼을 실행할 수 있는지
여러분은 많은 종류의 데이터 베이스 서버에 대한 crash-me의 결과를 http://dev.mysql.com/tech-resources/crash-me.php

에서 볼 수 있을 것이다. 벤치 마크 결과에 대한 정보는, http://dev.mysql.com/tech-resources/benchmarks/에서 찾아 보기 바
란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.1.5. 여러분 자신의 벤치 마크 사용하기
7.1. 최적화 소개 결론적으로는, 여러분은 자신의 어플리케이션 및 데이터 베이스를 벤치 마크 함으로써 병목 현상이 어디에서 발생하는지를 알아 보
7.1.5 여러분 자신의 벤치 마크 사용하기 아야 할 것이다. 하나의 병목 현상을 우선 처리한 후에야(또는 “dummy” 모듈로 바꿈으로써), 여러분은 그 다음의 병목 현상을
처리할 수가 있을 것이다. 비록 여러분의 어플리케이션이 전반적으로 아직은 성능이 괜찮을 지라도, 여러분은 최소한 각 병목 현상
이 어디에서 발생하며 어떻게 이것을 처리할 지에 대한 계획은 가지고 있어야 하다.
이식성이 있는 벤치 마트 프로그램의 예는 MySQL 벤치 마크 슈트에 있다. Section 7.1.4, “MySQL 벤치 마크 슈트”를 참조할
것. 여러분은 이 슈트에서 프로그램을 하나 가져와서 여러분의 필요에 따라 수정해서 사용할 수가 있다. 이렇게 함으로써, 여러분
은 자신의 문제에 대해 다른 방식의 해결책을 만들 수가 있고 보다 빠른 성능을 내도록 테스트를 할 수가 있게 된다.
또 다른 벤치 마크 슈트로는 오픈 소스 데이터 베이스 벤치 마크가 있으며, http://osdb.sourceforge.net/에서 찾을 수가 있다.
일상적으로 보면, 시스템에 부하를 매우 크게 걸 때 문제들이 많이 발생을 한다. 우리의 고객들은 시스템을 생산 단계에서 테스트
를 할 때 부하 문제를 겪곤 한다. 대부분의 경우, 성능 문제는 근본적인 데이터 베이스 디자인 이슈(예를 들면, 고 부하 상황하에서
는 테이블 스캔은 좋지 않음) 또는 OS 또는 라이브러리의 문제에서 기인한다고 알려져 있다. 이러한 문제를 해결하는 것은 그리 어
려운 문제가 아니다.
이와 같은 문제를 해결하기 위해서는, 가능한 최악의 상황 아래에서 여러분의 어플리케이션 전체를 벤치 마킹 해야만 한다. 여러분
은 슈퍼 스맥(Super Smack)을 사용할 수 있는데, http://jeremy.zawodny.com/mysql/super-smack/에서 이것을 찾아 볼 수 있
다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2. SELECT 및 다른 명령문 최적화 하기
7. 최적화(Optimization) 7.2.1. EXPLAIN을 사용해서 쿼리 최적화 하기

7.2. SELECT 및 다른 명령문 최적화 하기 7.2.2. 쿼리 성능 추정하기
7.2 SELECT 및 다른 명령문 최적화 하기 7.2.3. SELECT 쿼리의 속도
7.2.1 EXPLAIN을 사용해서 쿼리 최적화 하기 7.2.4. WHERE 구문 최적화
7.2.2 쿼리 성능 추정하기 7.2.5. 범위 최적화

7.2.6. 인덱스 병합 최적화
7.2.7. IS NULL 최적화
7.2.8. DISTINCT 최적화
7.2.5 범위 최적화
7.2.9. LEFT JOIN 및 RIGHT JOIN 최적화
7.2.5.1 단일 부분 인덱스에 대한 범위 접근 방식
7.2.10. 네스티드 조인(Nested Join) 최적화
7.2.5.2 다중 부분 인덱스에 대한 범위 접근 방식
7.2.11. 외부 조인(Outer Join) 딘순화
7.2.6 인덱스 병합 최적화
7.2.12. ORDER BY 최적화
7.2.6.1 인덱스 병합 교차 접근 알고리즘 7.2.13. GROUP BY 최적화
7.2.6.2 인덱스 병합 결합 접근 알고리즘 7.2.14. LIMIT 최적화
7.2.6.3 인덱스 병합 정렬-결합 접근 알고리즘 7.2.15. 테이블 스캔을 피하는 방법
7.2.7 IS NULL 최적화 7.2.16. INSERT 명령문의 속도
7.2.8 DISTINCT 최적화 7.2.17. UPDATE 명령문의 속도
7.2.9 LEFT JOIN 및 RIGHT JOIN 최적화 7.2.18. DELETE 명령문의 속도
7.2.10 네스티드 조인(Nested Join) 최적화 7.2.19. 다른 여러 가지의 최적화 팁(Tips)
7.2.11 외부 조인(Outer Join) 단순화

우선, 하나의 요소(factor)가 모든 명령문에 영향을 준다: 여러분이 퍼미션(permission) 설정을 복잡하게 하면 할수록, 여러분은
더 큰 오버헤드(overhead)를 가지게 된다. GRANT 명령문을 사용할 때 보다 단순한 퍼미션을 사용하는 것이 클라이언트가 명령
문을 실행할 때 퍼미션-검사의 오버헤드를 낮추는 것이다. 예를 들면, 만일 테이블 레벨 또는 컬럼 레벨의 권한에 대해서는 전혀
승인을 하지 않을 경우, 서버는 tables_priv 및 columns_priv 테이블의 내용물에 대해서는 전혀 검사를 하지 않게 된다. 비슷하

:::MySQL Korea:::
7.2.13.2 타이트한 인덱스 스캔(Tight index scan) 게, 여러분이 어느 계정에 대해서는 자원의 제한을 하지 않게 되면, 서버는 자원 카운팅을 실행하지 않는다. 만일 여러분이 매우
7.2.14 LIMIT 최적화 큰 명령문-처리 업무를 해야 한다면, 퍼미션-검사 오버헤드를 줄일 수 있도록 단순화된 승인 구조를 사용하는 것이 효율적인 것
7.2.15 테이블 스캔을 피하는 방법 이다.

만일 여러분이 특정 MySQL 수식 또는 함수에 문제를 가지고 있다면, 여러분은 mysql 클라이언트 프로그램을 사용해서
BENCHMARK() 함수를 호출하여 테스트를 할 수 있다. 이것의 신텍스는 BENCHMARK(loop_count,expression)이다. 리턴
7.2.17 UPDATE 명령문의 속도
값은 항상 0 인데, 하지만 mysql은 명령문이 실행하는데 걸리는 시간의 대략적으로 한 줄씩 프린트를 해 준다. 예를 들면:
7.2.18 DELETE 명령문의 속도
mysql> SELECT BENCHMARK(1000000,1+1);
7.2.19 다른 여러 가지의 최적화 팁(Tips)
+------------------------+
| BENCHMARK(1000000,1+1) |
+------------------------+
| 0|
+------------------------+
이 결과 값은 펜티엄(Pentium) II 400MHz 시스템을 가지고 얻은 것이다. 이것은 MySQL이 이 시스템에서 1,000,000개의 단
순 추가 수식(simple addition expression)을 처리하는데 0.32초가 소요된다는 것을 나타낸다.
모든 MySQL 함수는 고도로 최적화가 되어 있으나, 몇가지 예외는 있다. BENCHMARK()는 여러분의 쿼리에 무슨 문제가 있을
경우에 이를 찾아내는 훌륭한 툴이 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.1. EXPLAIN을 사용해서 쿼리 최적화 하기
7.2. SELECT 및 다른 명령문 최적화 하기 EXPLAIN tbl_name
7.2.1 EXPLAIN을 사용해서 쿼리 최적화 하기

또는:
EXPLAIN [EXTENDED] SELECT select_options
EXPLAIN 명령문은 DESCRIBE에 대한 동의어로 사용할 수 있거나 또는 MySQL이 SELECT 명령문을 실행하는 방법에 대한 정
보를 얻기 위한 수단으로 사용할 수가 있다:
● EXPLAIN tbl_name은 DESCRIBE tbl_name 또는 SHOW COLUMNS FROM tbl_name과 동일한 의미이다.
● 여러분이 SELECT 명령문을 EXPLAIN 앞에 두면, MySQL은 쿼리 실행 플랜(query execution plan)에 대한 정보를 옵
티마이저(optimizer)에서 가져 와서 출력을 한다. 즉, MySQL은 테이블들이 어떤 순서로 조인(join)을 하는지에 대한 정
보를 포함해서, SELECT를 처리하는 방법에 대해서 알려 주게 된다.
이 섹션에서는 쿼리 실행 플랜 정보를 얻기 위한 EXPLAIN의 사용법을 설명한다. DESCRIBE 및 SHOW COLUMNS 명령문에 대

한 설명은 Section 13.3.1, “DESCRIBE 신텍스”, 및 Section 13.5.4.3, “SHOW COLUMNS 신텍스”를 참조하기 바란다.
EXPLAIN를 사용함으로써, 여러분은 테이블의 어느 곳에 인덱스를 추가해야만 열을 찾기 위한 SELECT가 보다 빠르게 되는지를

알 수 있게 된다. 또한, EXPLAIN를 사용하면 옵티마이저가 최적의(optimal) 순서로 테이블을 조인(join)할 수 있는지 여부도 검
사할 수 있다. SELECT 명령문에 명명되어 있는 테이블의 순서와 상응하게 조인(join)순서를 사용하도록 옵티마이저를 만들기 위
해서는, 명령문에 SELECT만을 사용하는 대신에 SELECT STRAIGHT_JOIN를 사용해서 시작을 하도록 한다.
만일 여러분 생각에는 사용 되어야만 했을 인덱스가 사용되지 않은 상태로 문제를 일으키게 되면, 키의 기수(cardinality)와 같은
테이블 상태를 업데이트 하기 위한 ANALYZE TABLE를 구동 시켜야 하는데, 이것은 옵티마이저의 선택에 영향을 미치게 된다.

:::MySQL Korea:::
Section 13.5.2.1, “ANALYZE TABLE 신텍스”를 참조할 것.
EXPLAIN은 SELECT 명령문에서 사용된 각 테이블에 대한 정보 열을 리턴한다. MySQL이 쿼리를 처리하는 동안 읽을 수 있도

록 하기 위해, 테이블들은 결과물 안에 목록으로 정리가 된다. MySQL 은 single-sweep multi-join 방법을 사용해서 모든 조인
(join)을 풀어 버린다(reslove). 이것은 This means that MySQL은 첫 번째 테이블에서 열을 읽고, 그 다음에 두 번째 테이블에
서 매치(match)가 되는 것을 찾으며, 세 번째, 네 번째 등으로 이동을 한다는 것을 의미하는 것이다. 모든 테이블을 처리한 후에는,
MySQL은 선택된 컬럼을 내 보내고 테이블에 매치되는 다른 열이 있을 때까지 테이블을 역으로 검사를 한다. 이 테이블에서 그 다
음 열을 읽고 다음 테이블로 이동을 해서 동일한 과정을 진행한다.
EXTENDED 키워드가 사용되면, EXPLAIN은 EXPLAIN 명령문 다음에 SHOW WARNINGS 명령문을 입력해서 볼 수 있는 여분
의 정보를 보여 준다. 이 정보는 옵티마이저가 SELECT 명령문에 있는 컬럼 이름과 테이블을 얼마나 많이 검증을 하였는지를 보여
주며, SELECT는 최적화 과정에 관한 어플리케이션 재 작성과 최적화 규칙, 그리고 다른 가능한 노트(notes)를 보여준다.
Each output row from EXPLAIN를 통해서 나오는 각각의 결과 열은 하나의 테이블에 대한 정보이며, 각 열은 아래의 컬럼을 가
지고 있다:
● id
SELECT 구분자(identifier). 이것은 쿼리 안에 있는 SELECT의 순차적인 번호(sequential number)이다.
● select_type
SELECT의 타입으로서, 아래의 테이블에 있는 것 중에 하나가 된다:
SIMPLE Simple SELECT (not using UNION or subqueries)
PRIMARY Outermost SELECT
UNION Second or later SELECT statement in a UNION
DEPENDENT UNION Second or later SELECT statement in a UNION, dependent on outer query
UNION RESULT Result of a UNION.

:::MySQL Korea:::
SUBQUERY First SELECT in subquery
DEPENDENT SUBQUERY First SELECT in subquery, dependent on outer query
DERIVED Derived table SELECT (subquery in FROM clause)
DEPENDENT은 전형적으로는 상호 연관된(correlated) 서브 쿼리(subquery)의 사용을 의미한다. Section 13.2.8.7,

“상호 연관된 서브 쿼리(Correlated Subqueries)”를 참조할 것.
● table
결과 열이 참조하는 테이블.
● type
조인(join) 타입. 서로 다른 타입의 조인(join)이 아래에 있는데, 가장 좋은 것부터 가장 나쁜 것의 순서로 되어 있다:
❍ system
테이블은 하나의 열만을 가지고 있다 (= 시스템 테이블). 이것은 const 조인(join) 타입의 특별한 경우이다.
❍ const
테이블은 적어도 하나의 매칭(matching) 테이블을 가지고 있는데, 쿼리가 시작되는 시점에 이 테이블을 읽게 된
다. 여기에는 하나의 열만이 존재하기 때문에, 이 열에 있는 컬럼에서 얻는 값은 나머지 옵티마이저에 의해 항수
(constant)로 인식될 수 있다. const 테이블은 한번 밖에 읽혀지지 않기 때문에 매우 빠르다.
const는 여러분이 PRIMARY KEY 또는 UNIQUE 인덱스의 모든 부분을 항수 값(constant value)와 비교를 할
때 사용된다. 아래의 쿼리에서 보면, tbl_name는 const 테이블 형태로 사용되고 있다:
SELECT * FROM tbl_name WHERE primary_key=1;

:::MySQL Korea:::
WHERE primary_key_part1=1 AND primary_key_part2=2;
❍ eq_ref
이전 테이블로부터 각 열을 조합(combination)하기 위해서 이 테이블에서 하나의 열을 읽는다. system 및

const 타입과는 달리, 이것이 가장 최선의 가능 조인(join) 타입이다. 이것은 조인(join)에 의해 인덱스의 모든
부분이 사용될 때 쓰이게 되고, 이때 인덱스는 PRIMARY KEY 또는 UNIQUE 인덱스가 된다.
eq_ref는 = 연산자를 사용해서 비교되는 인덱스된 컬럼을 위해 사용될 수 있다. 비교 값은 이 테이블 전에 읽었
던 테이블에서 컬럼을 사용한 수식 또는 항수(constant)가 될 수 있다. 아래의 예제에서 보면, MySQL은
ref_table를 처리하기 위해서 eq_ref 조인(join)을 사용한다.
SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;
WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;
❍ ref
매칭(matching) 인덱스 값을 가진 모든 열이 이전 테이블로부터의 각 열의 조합을 위해 이 테이블에서 읽혀진

다. 만일 조인(join)이 키의 좌측 끝(leftmost)의 접두사 만을 사용하거나 또는 키가 PRIMARY KEY 또는
UNIQUE 인덱스가 아니라면 (달리 말하면, 만일 조인(join)이 키 값을 기반으로 한 단일(single) 열을 선택하지
않는다면), ref가 사용된다. 적은 수의 열에 대해서만 매치(match)를 하는데 키를 사용한다면, 좋은 조인(join)
타입이다.

:::MySQL Korea:::
ref는 = 또는 <=> 연산자를 사용해서 비교되는 인덱스된 컬럼에 대해 사용될 수 있다. 아래의 예제에서 본
다면, MySQL은 ref_table의 처리 과정에서 ref 조인(join)을 사용한다.
SELECT * FROM ref_table WHERE key_column=expr;
WHERE ref_table.key_column=other_table.column;
WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;
❍ ref_or_null
이 조인(join) 타입은 ref과 유사하지만, MySQL이 NULL 값을 가지고 있는 열에 대해서도 검색을 한다는 점이
차이가 있다. 이 조인(join) 타입 최적화는 서브 쿼리(subqueries)를 해석하는데 자주 사용된다. 아래의 예제에
서 보면, MySQL은 ref_table의 처리 과정에서 ref_or_null 조인(join)을 사용하고 있다.
SELECT * FROM ref_table
WHERE key_column=expr OR key_column IS NULL;
Section 7.2.7, “IS NULL 최적화”를 참조할 것.
❍ index_merge

:::MySQL Korea:::
이 조인(join) 타입은 인덱스 병합 최적화가 사용되었음을 나타낸다. 이 경우에, 결과 열에 있는 key 컬럼은 사용

된 인덱스 리스트를 가지고 있고, key_len는 사용된 인덱스에 대해서 가장 긴 키 부분의 리스트를 가지고 있다.
보다 자세한 정보는, Section 7.2.6, “인덱스 병합 최적화”를 참조할 것.
❍ unique_subquery
이 타입은 아래 형태의 IN 서브 쿼리(subqueries)에 대한 ref를 대체한다:
value IN (SELECT primary_key FROM single_table WHERE some_expr)
unique_subquery는 효율성을 위해서 서브 쿼리(subquery)를 대체하는 인덱스 룩업(lookup)함수이다.
❍ index_subquery
이 조인(join)타입은 unique_subquery와 유사하다. 이것은 IN 서브 쿼리(subqueries)를 대체하지만, 아래 형

태의 서브 쿼리(subquery)에 있는 논-유니크(non-unique)인덱스에 대해서도 동작을 한다:
value IN (SELECT key_column FROM single_table WHERE some_expr)
❍ range
주어진 범위에 들어 있는 열만을 추출하는데, 열을 선택 하기 위해서는 인덱스를 사용한다. 결과 열에 있는 key

컬럼은 어떤 인덱스가 사용되었는지를 가리킨다. key_len은 사용된 키에서 가장 긴 부분을 가진다. ref 컬럼은
이 타입에 대해서는 NULL 값이 된다.
range는 키 컬럼이 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, 또는 IN 연산자
를 사용하는 항수(constant)와 비교가 될 때 사용될 수 있다:
WHERE key_column = 10;

:::MySQL Korea:::
WHERE key_column BETWEEN 10 and 20;
WHERE key_column IN (10,20,30);
WHERE key_part1= 10 AND key_part2 IN (10,20,30);
❍ index
이 조인(join) 타입은 ALL과 동일하지만, 인덱스 트리(index tree)만을 스캔한다는 점은 다르다. 일반적으로 이
것이 ALL 보다는 빠르게 동작하는데, 왜냐하면 보통 인덱스 파일이 데이터 파일보다 작기 때문이다.
MySQL은 쿼리가 단일 인덱스의 일부분인 컬럼만을 사용할 때 이 조인(join)을 사용한다.
❍ ALL
전체 테이블 스캔은 이전 테이블로부터의 각 열의 조합에 대해서 실행된다. 일반적으로, 만일 그 테이블이 표시

가 된 const의 첫 번째 테이블이 아니고, 다른 모든 경우에 있어서 매우 좋지 않은 경우라면, 이것은 그리 좋은 경
우가 아니다. 보통은, 이전의 테이블로부터 항수(constant) 값 또는 컬럼 값을 가지고 있는 테이블에서 열 추출
(retrieval)을 허용하는 인덱스를 추가 함으로써 ALL을 피할 수가 있다.
● possible_keys

:::MySQL Korea:::
possible_keys 컬럼은 MySQL이 이 테이블에서 열을 찾기 위해 선택한 인덱스가 어떤 것인지를 가리킨다. 이 컬럼은

EXPLAIN의 결과에서 나타나는 것과 같은 테이블 순서와는 전적으로 별개의 순서가 된다. 이것은 possible_keys에 있
는 키들 중에 어떤 것들이 테이블 순서를 만드는 과정에서는 사용이 되지 않을 수도 있음을 의미하는 것이다.
만일 이 컬럼 값이 NULL이라면, 연관된 인덱스가 존재하지 않게 된다. 이와 같은 경우, 여러분은 WHERE 구문을 검사해
서 인덱스 하기에 적당한 컬럼을 이 구문이 참조하고 있는지 여부를 검사함으로써 여러분의 쿼리 속도를 개선 시킬 수가
있게 된다. 만일 그렇다면, 적절한 인덱스를 하나 생성하고 EXPLAIN을 다시 사용해서 쿼리를 검사한다.
Section 13.1.2, “ALTER TABLE 신텍스”를 참조할 것.
테이블이 어떤 인덱스를 가지고 있는지를 보기 위해서는, SHOW INDEX FROM tbl_name를 사용한다.
● key
key 컬럼은 MySQL이 실제로 사용할 예정인 키(인덱스)를 가리킨다. 만일 아무런 인덱스도 선택되지 않았다면, 그 키
는 NULL이 된다. To force MySQL로 하여금 possible_keys 컬럼에 있는 인덱스를 사용 또는 무시하도록 만들기 위
해서는, 쿼리에서 FORCE INDEX, USE INDEX, 또는 IGNORE INDEX를 사용하도록 한다. Section 13.2.7,
“SELECT 신텍스”를 참조할 것.
MyISAM 및 BDB 테이블의 경우, ANALYZE TABLE를 구동시킴으로써 옵티마이저가 보다 좋은 인덱스를 선택하도록
도움을 줄 수가 있다. MyISAM 테이블의 경우에는, myisamchk --analyze 가 동일한 역할을 한다. Section 13.5.2.1,
“ANALYZE TABLE 신텍스”, 및 Section 5.10.4, “테이블 유지 관리 및 크래시(Crash) 복구”를 참조할 것.
● key_len
key_len 컬럼은 MySQL이 사용하기로 결정한 키의 길이를 나타낸다. 만일 key 컬럼이 NULL이라면, 이 길이도 NULL
이 된다. Note that key_len의 값은 다중-부분(multiple-part)키 부분 중에 얼마나 많은 부분을 MySQL이 실제로 사용
하는지를 여러분이 알 수 있도록 해 준다.
● ref
ref 컬럼은 테이블에서 열을 선택하기 위해 key 컬럼 안에 명명되어 있는 인덱스를 어떤 컬럼 또는 항수(constant)와 비

교하는지를 보여준다.
● rows

:::MySQL Korea:::
rows 컬럼은 MySQL이 쿼리를 실행하기 위해 조사해야 하는 열의 숫자를 가리킨다.
● Extra
이 컬럼은 MySQL이 쿼리를 어떻게 해석하는지에 대해 추가적인 정보를 제공한다. 이 컬럼이 가질 수 있는 값에 대한 설

명을 아래에서 한다:
❍ Distinct
MySQL은 명확한 값(distinct value)를 찾게 되며, 따라서 MySQL이 매칭되는 열을 찾게 되면 더 이상의 열에

대해서는 검색을 중단한다.
❍ Not exists
MySQL은 쿼리상에서 LEFT JOIN 최적화를 실행 했으며, 이 최적화와 매치가 되는 열을 찾은 후에는 이전 열

조합에 대해서 더 이상 이 테이블에서는 검색을 하지 않게 된다. 이러한 방식으로 최적화가 되는 쿼리 타입의 예
를 아래에 보여 준다:
SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;
t2.id를 NOT NULL으로 정의했다고 가정하자. 이와 같은 경우, MySQL은 t1을 스캔하고 and looks up the
rows in using the values of t1.id의 값을 사용해서 t2에 있는 열을 검색한다. 만일 MySQL이 t2에서 매칭되는
열을 발견하면, MySQL은 t2.id 가 결코 NULL이 아님을 알게 되며, 따라서 동일한 id 값을 가지고 있는 t2에서
는 더 이상 열을 스캔하지 않게 된다. 달리 표현하면, t1에 있는 각 열에 대해, MySQL은 t2에서는 단일 검색
(lookup)만을 하게 되며, t2에서 실제로 얼마나 많은 열이 매치가 되는지는 상관이 없게 된다.
❍ range checked for each record (index map: N)
MySQL은 사용하기에 좋은 인덱스를 찾지 못했으나, 이전 테이블에서 컬럼 값을 찾고 난 후에는 사용할 수도 있

:::MySQL Korea:::
을 법한 인덱스는 알아냈다. 이전 테이블에 있는 각 열 조합에 대해서는, MySQL은 그 조합이 열을 추출하기 위

해서 range 또는 index_merge 접근 방식을 사용할 수 있는지를 검사한다. 이 방법은 그리 빠른 방법은 아니지
만, 인덱스를 전혀 사용하지 않는 것 보다는 빠르게 진행한다.
❍ Using filesort
MySQL은 저장된 순서에 따라서 열을 추출하기 위한 방법을 찾기 위한 여분의 과정을 진행한다. 정렬(sort)은
조인(join) 타입과 정렬 키 및 WHERE 구문과 매치가 되는 모든 열에 대한 열 포인터(pointer)를 가지고 모든
열에 걸쳐 진행 된다. 그런 다음에 그 키는 저장이 되며 열은 저장 순서에 따라서 추출된다. Section 7.2.12,
“ORDER BY 최적화”를 참조할 것.
❍ Using index
부가적인 실제 열 검색을 하지 않는 상태로 인덱스 트리에 있는 정보만을 가지고 테이블에서 컬럼 정보를 추출한
다. 쿼리가 단일 인덱스의 일부분인 컬럼만을 사용할 때 이러한 전략을 사용할 수가 있다.
❍ Using temporary
쿼리를 해석하기 위해서는, MySQL은 결과를 집어 넣을 임시 테이블을 하나 생성할 필요가 있다. 전형적으로는,
만일 쿼리가 컬럼을 서로 다르게 목록화 한 GROUP BY 및 ORDER BY 구문을 가지고 있는 경우에 이런 것이 일
어나게 된다.
❍ Using where
WHERE 구문은 다음 테이블에 대한 열 매치(match) 클라이언트에 보내지는 열을 제한하기 위해 사용된다. 여

러분이 테이블에서 모든 열을 조사하거나 불러올 의도가 특별히 없다면, Extra 값이 Using where 가 아니고 테
이블 조인(join) 타입이 ALL 또는 index일 경우에는, 여러분의 쿼리에 문제가 생길 수도 있다.
만일 여러분이 가능한 한 빠른 쿼리를 만들고 싶다면, Extra Using filesort 및 Using temporary의 값을 조사해
야 한다.
❍ Using sort_union(...), Using union(...), Using intersect(...)

:::MySQL Korea:::
이것들은 인덱스 스캔이 어떻게 index_merge 조인(join) 타입과 병합(merge)가 되는지를 나타낸다.
Section 7.2.6, “인덱스 병합 최적화”를 참조할 것.
❍ Using index for group-by
테이블 접근에 대한 Using index 방식과 유사한 Using index for group-by 방식은MySQL이 실제 테이블을
추가적으로 검색을 하지 않고서도 GROUP BY 또는 DISTINCT 쿼리의 모든 컬럼을 추출(retrieve)하기 위해
사용될 수 있는 인덱스를 찾았음을 가리킨다. 또한, 그 인덱스는 각 그룹에 대해 가장 효과적인 방식으로 사용되
기 때문에, 적은 수의 인덱스 엔트리만이 읽혀지게 된다. 자세한 사항은 Section 7.2.13, “GROUP BY 최적
화”를 참조할 것.
❍ Using where with pushed condition
이 아이템은 NDB Cluster 테이블에만 적용된다. 이것은 MySQL 클러스터가 인덱스가 되지 않은 컬럼(non-
indexed column)과 항수(constant)간의 직접 비교(direct comparision (=))의 효율성을 개선하기 위해서 조
건문을 푸시 다운(condition pushdown)하는 중이라는 의미를 갖는다. 이와 같은 경우, 조건문은 동시에 값이 검
사되는 클러스터의 모든 데이터 노드로 “푸시 다운(pushed down)”가 된다. 이것은 매치되지 않는 열(non-
matching row)를 네트워크 전체에 보낼 필요성을 없애 주며, 조건문 푸시 다운을 하지 않는 경우에 비해서 5에
10배의 속도 향상을 얻을 수가 있다.
여러분이 아래와 같은 클러스터 테이블을 가지고 있다고 가정하자:
CREATE TABLE t1 (
a INT,
b INT,
KEY(a)
) ENGINE=NDBCLUSTER;
이와 같은 경우, 조건문 푸시 다운은 아래와 같은 쿼리와 함께 사용될 수 있다:

:::MySQL Korea:::
SELECT a,b FROM t1 WHERE b = 10;
이것은 EXPLAIN SELECT의 결과를 통해서 볼 수가 있는데, 아래와 같다:
mysql> EXPLAIN SELECT a,b FROM t1 WHERE b = 10￦G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 10
Extra: Using where with pushed condition
조건문 푸시 다운(Condition pushdown)는 아래와 같은 쿼리 중의 하나와는 함께 사용될 수 없다:
SELECT a,b FROM t1 WHERE a = 10;

:::MySQL Korea:::
SELECT a,b FROM t1 WHERE b + 1 = 10;
위의 첫 번째 쿼리의 경우, 조건문 푸시 다운을 적용할 수가 없는데, 그 이유는 인덱스가 컬럼 a에 존재하기 때문

이다. 두 번째 경우에 대해서 조건문 푸시 다운을 사용할 수 없는 까닭은, 인덱스가 되지 않은 컬럼 b를 포함하는
비교문이 간접적이기 때문이다. (하지만, 여러분이 WHERE 구문에서 b + 1 = 10 를 b = 9 로 줄여서 비교를
한다면 사용 가능하다.)
하지만, 조건문 푸시 다운은 a > 또는 < 연산자를 사용해서 인덱스된 컬럼을 항수(constant)와 비교를 하
는 경우에는 사용할 수가 있다:
mysql> EXPLAIN SELECT a,b FROM t1 WHERE a<2￦G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t1
type: range
possible_keys: a
key: a
key_len: 5
ref: NULL
rows: 2

:::MySQL Korea:::
Extra: Using where with pushed condition
조건문 푸시 다운에 관련해서는 아래의 사항을 기억하기 바란다:
■ 조건문 푸시 다운은 MySQL 클러스터에만 관련이 있으며, 다른 스토리지 엔진을 사용하고 있는 테이블에
대해서 쿼리를 실행할 경우에는 발생하지 않는다.
■ 조건문 푸시 다운 기능은 디폴트로 사용되지 않는다. 이 기능을 활성화 시키기 위해서는, mysqld을 --
engine-condition-pushdown 옵션과 함께 시작하거나, 또는 아래의 명령문을 실행한다:
§ SET engine_condition_pushdown=On;
조건문 푸시 다운, Using where with pushed condition, 그리고 engine_condition_pushdown 등은 모두 5.0
클러스터에서 추가가 되었다.
여러분은 EXPLAIN의 결과에 있는 rows 컬럼 값을 가지고 좋은 조인(join)을 얻는 방법을 알아 낼 수가 있다. 이것은 MySQL이
쿼리를 실행하기 위해서 조사해야 하는 열의 수가 얼마나 되는지 대략적으로 알려 주게 된다. 만일 여러분이 max_join_size 시스
템 변수를 가지고 쿼리를 제한하면, 이러한 열은 다중-테이블 SELECT 명령문을 실행해야 하는지 또는 무시를 해야 하는지를 결
정하는 데 이러한 열 값을 사용할 수도 있게 된다. Section 7.5.2, “서버 파라미터 튜닝하기”를 참조할 것.
아래의 예제는 EXPLAIN에 의해 얻어진 정보를 가지고서 다중-테이블 조인을 어떻게 최적화 시키는 지를 설명한다.
여러분은 아래와 같은 SELECT 명령문을 가지고 있으며 EXPLAIN를 사용해서 이것을 조사하고자 한다고 가정하자:
EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,
tt.ProjectReference, tt.EstimatedShipDate,
tt.ActualShipDate, tt.ClientID,
tt.ServiceCodes, tt.RepetitiveID,
tt.CurrentProcess, tt.CurrentDPPerson,

:::MySQL Korea:::
tt.RecordVolume, tt.DPPrinted, et.COUNTRY,
et_1.COUNTRY, do.CUSTNAME
FROM tt, et, et AS et_1, do
WHERE tt.SubmitTime IS NULL
AND tt.ActualPC = et.EMPLOYID
AND tt.AssignedPC = et_1.EMPLOYID
AND tt.ClientID = do.CUSTNMBR;
이 예제의 경우, 아래와 같은 가정을 한다:
● 비교가 되는 컬럼은 아래와 같이 선언 되었다:
Table Column Data Type
Tt ActualPC CHAR(10)
Tt AssignedPC CHAR(10)
Tt ClientID CHAR(10)
Et EMPLOYID CHAR(15)
Do CUSTNMBR CHAR(15)
● 테이블은 아래와 같은 인덱스를 갖는다:
Table Index
Tt ActualPC

:::MySQL Korea:::
Tt AssignedPC
Tt ClientID
Et EMPLOYID (primary key)
Do CUSTNMBR (primary key)
● tt.ActualPC 값은 골고루 나누어 지지 않는다 (are not evenly distributed).
우선, 최적화를 하기 전에, EXPLAIN 명령문은 다음과 같은 정보를 생성한다:
table type possible_keys key key_len ref rows Extra
et ALL PRIMARY NULL NULL NULL 74
do ALL PRIMARY NULL NULL NULL 2135
et_1 ALL PRIMARY NULL NULL NULL 74
tt ALL AssignedPC, NULL NULL NULL 3872
ClientID,
ActualPC
range checked for each record (key map: 35)
type 은 모든 테이블에 대해 ALL이기 때문에, 이 결과 값은 MySQL이 모든 테이블에 대해 하나의 Cartesian 값을 생성하는 중이

라는 것을 가리킨다; 즉, 열에 대한 모든 조합(every combination of rows). 이 과정은 시간이 오래 걸리는데, 왜냐하면 각각의 테
이블에 있는 열의 숫자를 조사해야 하기 때문이다. 위의 경우에는, 74 × 2135 × 74 × 3872 = 45,268,558,720 열이 된다.
만일 컬럼 상의 인덱스들을 동일한 타입과 크기로 선언할 경우에는 MySQL이 이를 효과적으로 처리하는데 한가지 문제가 생긴다.
위의 문장에서 보면, VARCHAR 및 CHAR는 크기가 동일하게 선언된다면, 동일한 것으로 간주가 된다. tt.ActualPC는 CHAR

:::MySQL Korea:::
(10)로 선언 되었고 et.EMPLOYID는 CHAR(15)로 선언 되었기 때문에, 길이가 맞지 않게 된다.
컬럼 길이간의 이러한 문제를 해결 하기 위해서는, ALTER TABLE를 사용해서 ActualPC의 길이를 10 개의 문자에서 15 문자로
늘린다:
mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15);
이제 tt.ActualPC 및 et.EMPLOYID는 모두 VARCHAR(15)가 된다. EXPLAIN 명령문을 다시 실행하면 아래와 같은 결과를 얻

게 된다:
tt ALL AssignedPC, NULL NULL NULL 3872 Using
ClientID, where
ActualPC
do ALL PRIMARY NULL NULL NULL 2135
et_1 ALL PRIMARY NULL NULL NULL 74
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
이것은 완벽한 것은 아니지만, 많이 개선이 된 것이다: rows 값은 74 보다 작다. 이와 같은 실행은 수초 정도 걸린다.
두 번째 대안으로는 tt.AssignedPC = et_1.EMPLOYID 와 tt.ClientID = do.CUSTNMBR 비교에서 컬럼 길이가 일치하지 않는

것을 제거하는 방법이 있다:

:::MySQL Korea:::
mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),
-> MODIFY ClientID VARCHAR(15);
이와 같이 수정을 하면, EXPLAIN은 아래와 같은 결과를 만들게 된다:
et ALL PRIMARY NULL NULL NULL 74
tt ref AssignedPC, ActualPC 15 et.EMPLOYID 52 Using
ClientID, where
ActualPC
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
이렇게 되면, 쿼리는 거의 최적화가 이루어진다. 남아 있는 문제는, MySQL은 tt.ActualPC 컬럼에 있는 값들은 골고루 분포가 되
어 있으나, tt 테이블에 대해서는 그렇지 않다고 가정하고 있다는 점이다. 다행스러운 것은, MySQL로 하여금 키의 분포도를 분석
하도록 만드는 것이 쉽다는 점이다:
mysql> ANALYZE TABLE tt;
추가적인 인덱스 정보를 사용하면, 조인(join)은 완벽해 지고 EXPLAIN은 아래와 같은 결과를 만들게 된다:
tt ALL AssignedPC NULL NULL NULL 3872 Using

:::MySQL Korea:::
ClientID, where
ActualPC
et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1
et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1
do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1
EXPLAIN의 결과에 있는 rows 컬럼은 MySQL 조인(join) 최적화를 통해서 개선된다는 점을 알아두자. 여러분은 rows 가 만들
어 내는 값과 쿼리가 리턴하는 열의 실제 숫자를 비교함으로써 그 숫자가 거의 일치하는지를 검사해야 한다. 만일 그 숫자가 많이
차이가 난다면, SELECT 명령문에서 STRAIGHT_JOIN을 사용하고 FROM 구문에서 테이블의 순서를 다르게 해 줌으로서 보다
나은 성능을 얻을 수가 있을 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.2. 쿼리 성능 추정하기
7.2. SELECT 및 다른 명령문 최적화 하기 대부분의 경우, 여러분은 디스크 검색(disk seek) 시간을 계산해서 쿼리의 성능을 추정할 수 있다. 작은 테이블의 경우에는 한번
7.2.2 쿼리 성능 추정하기 의 디스크 검색으로 열을 찾을 수가 있다(왜냐하면 인덱스가 거의 캐시되어 있기 때문에). 보다 큰 테이블일 경우에는, 여러분은
B-트리 인덱스를 사용해서 이를 추정할 수가 있는데, 하나의 열을 찾기 위해서는 많은 검색을 하여야 한다: log(row_count) / log
(index_block_length / 3 × 2 / (index_length + data_pointer_length)) + 1.
MySQL에서는, 하나의 인덱스 블록은 통상 1,024 바이트가 되며 데이터 포인터(data pointer)는 보통 4 바이트가 된다. 인덱스
의 길이가 3 바이트인 500,000개의 열이 있는 테이블의 경우 (MEDIUMINT의 크기), 공식은 log(500,000)/log(1024/3×2/(3
+4)) + 1 = 4 검색(seek)이 된다.
이 인덱스는 대략 500,000 × 7 × 3/2 = 5.2MB (전형적인 인덱스 버퍼 공간 비율을 2/3로 가정함)의 스토리지 공간을 필요로
하게 되며, 따라서 여러분은 메모리에 충분한 인덱스를 가지고 있으며 열을 찾기 위해서는 한 두 번의 데이터 읽기를 실행하기만 하
면 된다.
하지만, 쓰기의 경우에는, 새로운 인덱스 값을 저장할 위치를 찾는데 4번의 검색을 하여야 하고 인덱스를 업데이트 하고 열을 쓰기
위해서는 2번의 검색을 해야 한다.
위에서 설명하는 것은, 여러분의 어플리케이션이 로그 N에 의해서 성능이 저하된다는 것을 의미하는 것은 아니다. 모든 것이 OS
또는 MySQL에 의해 캐시가 되는 한, 테이블이 점점 커지는 만큼만 느려지게 된다. 데이터가 캐시 되지 못할 정도로 커지게 된 후
에는, 디스크 검색 (로그 N에 의해 늘어난)이 어플리케이션을 한정하기 전까지 점점 속도가 저하되기 시작한다. 이러한 현상을 없
애기 위해서는, 키 캐시의 크기를 데이터가 늘어나는 만큼 늘려 주면 된다. MyISAM 테이블의 경우, 키 캐시의 크기는
key_buffer_size 시스템 변수가 제어한다. Section 7.5.2, “서버 파라미터 튜닝하기”를 참조할 것.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.3. SELECT 쿼리의 속도
7.2. SELECT 및 다른 명령문 최적화 하기 일반적으로, 속도가 느린 SELECT ... WHERE 쿼리를 보다 빠르게 만들기 위해서는, 우선 여러분이 인덱스를 하나 추가 할 수 있
는지를 검사해 본다. 서로 다른 테이블간의 모든 참조 사항들은 보통 인덱스를 가지고서 이루어 진다. 여러분은 EXPLAIN 명령문
을 사용해서 SELECT에 사용할 수 있는 인덱스에는 어떤 것들이 있는지를 알아볼 수가 있다. Section 7.2.1, “EXPLAIN를 사용
해서 쿼리 최적화 하기”, 및 Section 7.4.5, “MySQL은 인덱스를 어떻게 사용하는가”를 참조할 것.
MyISAM 테이블에 있는 쿼리의 속도를 향상 시키기 위한 몇 가지 일반적인 사항이 다음과 같이 있다:
● MySQL이 쿼리를 보다 잘 최적화 하도록 하기 위해서는, 데이터를 읽어온 다음에 ANALYZE TABLE를 사용하거나 또는
myisamchk –analyze를 테이블에서 구동 시킨다. 이를 통해서 동일한 값을 가지고 있는 열의 평균 수를 가리키는 각 인덱
스 부분을 업데이트 한다. (고유의 인덱스의 경우, 이 값은 항상 1이다.) MySQL은 이것을 사용해서 항수가 아닌(non-
constant) 수식 형태의 두 개의 테이블을 조인(join)할 때 어떤 인덱스를 선택해야 하는지를 결정한다. 여러분은You can
check the result from the table analysis by using SHOW INDEX FROM tbl_name를 사용한 테이블 분석과
Cardinality 값의 조사를 통해서 그 결과를 검사할 수가 있다. myisamchk --description –verbose는 인덱스 분포에 대
한 정보를 보여 준다.
● 하나의 인덱스에 따라서 인덱스 및 데이터의 정렬을 위해서는, myisamchk --sort-index --sort-records=1 (여러분
이 인덱스 1에 대한 정렬을 하고자 한다고 가정한다)를 사용한다. 만일 여러분이 인덱스의 순서에 따라서 모든 열을 읽고
자 하는 고유의 인덱스를 가지고 있는 경우에는, 이것은 매우 좋은 방법이 된다. 이러한 방식으로 커다란 테이블을 처음으
로 정렬하는 경우에는, 시간이 매우 오래 걸리게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.4. WHERE 구문 최적화
7.2. SELECT 및 다른 명령문 최적화 하기 이 섹션에서는 WHERE 구문을 처리하기 위해 만들 수 있는 최적화 방법에 대해서 설명하기로 한다. 이 섹션에서 사용되는 예문들
은 SELECT 명령문을 사용하지만, DELETE 와 UPDATE 명령문에 있는 WHERE 구문에 대한 최적화에도 동일한 최적화 방식
을 적용할 수가 있다.
MySQL 옵티마이저는 현재에도 계속 개발을 진행하고 있기 때문에, 이 섹션에서 설명하는 것들은 아직 완전하지가 않다. 하지만
MySQL은 이 문서에서 설명하는 것 이외의 많은 부분에서 최적화를 실행하고 있는 중이다.
MySQL이 실행한 최적화의 종류에는 아래와 같은 것들이 있다:
● 필요 없는 괄호를 없앰:
• ((a AND b) AND c OR (((a AND b) AND (c AND d))))
• -> (a AND b AND c) OR (a AND b AND c AND d)
● 항수 홀딩(Constant folding):
• (a<b AND b=c) AND a=5
• -> b>5 AND b=c AND a=5
● 항수 조건문 제거 (항수 홀딩으로 인해 필요함):
• (B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)

:::MySQL Korea:::
• -> B=5 OR B=6
● 인덱스에 의해 사용되는 항수 수식은 한 번만 평가된다.

● WHERE가 없는 단일 테이블 상의 COUNT(*)는 MyISAM 및 MEMORY 테이블에 대한 정보에서 직접 가져올 수가 있
다. 이것은 또한 오직 하나의 테이블만을 사용하는 모든 NOT NULL 수식용으로도 사용 된다.
● 옳지 않은 항수 수식에 대한 초기 검사. MySQL은 사용할 수 없고 아무런 열도 리턴하지 않는 SELECT 명령문을 빨리 찾
아낸다.
● 만일 여러분이 GROUP BY 또는 집합 함수(aggregate functions) (COUNT(), MIN(), 등등)를 사용하지 않으면,
HAVING 은 WHERE과 병합된다.
● 하나의 조인(join)에 있는 각 테이블에 대해서는, WHERE를 단순하게 할수록 각 테이블에 대한 WHERE 평가를 빠르게
할 수가 있고 가능한 한 빨리 열을 건너 띄게 할 수가 있다.
● 쿼리내에 있는 다른 테이블보다 모든 항수 테이블을 먼저 읽는다. 항수 테이블은 아래의 것 중의 하나가 된다:
❍ 빈 테이블 또는 열이 하나밖에 없는 테이블.
❍ PRIMARY KEY 또는 UNIQUE 인덱스상에서 WHERE 구문을 가지고 사용되는 테이블이며, 여기에서 모든 인덱
스 부분은 항수 수식과 비교가 되고 NOT NULL로 정의 된다.
아래의 테이블들은 항수 테이블로 사용된다:
SELECT * FROM t WHERE primary_key=1;
SELECT * FROM t1,t2
WHERE t1.primary_key=1 AND t2.primary_key=t1.id;
● 모든 가능성을 시도해서 테이블 조인(join)에 대한 가장 좋은 조인(join) 조합을 찾는다. 만일 If all columns in ORDER
BY 와 GROUP BY 구문에 있는 모든 컬럼이 동일한 테이블에서 나온다면, 조인을 진행할 때 그 테이블을 우선 사용한다.
● 만일 ORDER BY 구문이 있고 이와는 틀린 GROUP BY 구문이 존재하거나, 또는 만일 ORDER BY 또는 GROUP BY 구문
이 조인 큐(join queue)에 있는 첫 번째 테이블이 아닌 다른 테이블로부터 컬럼을 가져 온다면, 임시 테이블이 생성된다.
● 만일 여러분이 SQL_SMALL_RESULT 옵션을 사용한다면, MySQL은 메모리에 있는 임시 테이블을 사용한다.
● 각 테이블 인덱스는 쿼리화가 되며, 그리고 테이블 스캔을 사용하는 것이 보다 효과적이라고 옵티마이저가 판단하지 않는
한 가장 좋은 인덱스를 사용하게 된다. 처음에는, 가장 좋은 인덱스가 테이블의 30% 이상을 처리하는지에 따라서 테이블

:::MySQL Korea:::
스캔을 사용하지만, 인덱스 또는 테이블 스캔 사용간의 선택에 대한 정확한 비율은 정해지지 않았다. 옵티마이저는 보다 복
잡해졌고, 또한 테이블 크기, 열의 수, I/O 블록 크기 등의 추가적인 요소로 인해 추정치가 변하였다.
● 어떤 상황에서는, MySQL은 데이터 파일을 참조하지 않은 채로 테이블에서 열을 읽기도 한다. 만일 인덱스에서 사용된 모
든 컬럼이 숫자(numeric)일 경우에는, 인덱스 트리만을 가지고 쿼리를 해석하게 된다.
● 각각의 열을 내보내기 전에는, HAVING 구문과 일치하지 않는 것들은 건너 띄게 된다.
매우 빠른 쿼리의 예를 아래에서 보여 준다:
SELECT COUNT(*) FROM tbl_name;
SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;
SELECT MAX(key_part2) FROM tbl_name
WHERE key_part1=constant;
SELECT ... FROM tbl_name
ORDER BY key_part1,key_part2,... LIMIT 10;
ORDER BY key_part1 DESC, key_part2 DESC, ... LIMIT 10;

:::MySQL Korea:::
MySQL은 인덱스 트리만을 가지고 아래의 쿼리를 해석하는데, 인덱스된 컬럼이 숫자(numeric)이라는 가정을 한다:
SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;
SELECT COUNT(*) FROM tbl_name
WHERE key_part1=val1 AND key_part2=val2;
SELECT key_part2 FROM tbl_name GROUP BY key_part1;
아래의 쿼리는 별개의 정렬 경로를 사용하지 않는 상태로 정렬된 순서에 있는 열을 추출하기 위해 인덱싱을 사용한다:
ORDER BY key_part1,key_part2,... ;
ORDER BY key_part1 DESC, key_part2 DESC, ... ;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.5. 범위 최적화
7. 최적화(Optimization) 7.2.5.1. 단일 부분 인덱스에 대한 범위 접근 방식

7.2. SELECT 및 다른 명령문 최적화 하기 7.2.5.2. 다중 부분 인덱스에 대한 범위 접근 방식
7.2.5 범위 최적화
range 접근 방식은 하나 또는 여러 개의 인덱스 값 인터벌(interval)내에 포함되어 있는 테이블 열의 서브 셋(subset)을 추출하기
위해서 단일 인덱스를 사용한다. 이것은 단일 부분 또는 다중 부분 인덱스를 위해 사용될 수 있다. 다음에 나오는 섹션에서는
WHERE 구문에서 인터벌(interval)을 어떻게 얻을 수 있는지에 대해 자세히 설명을 하기로 한다.
:::MySQL Korea:::
제목검색
7.2.5.1. 단일 부분 인덱스에 대한 범위 접근 방식
7.2. SELECT 및 다른 명령문 최적화 하기 단일 부분 인덱스의 경우, 인덱스 값 인터벌(index value intervals)은 WHERE 구문에 있는 조건문에 상응해서 쉽게 표현될 수가
7.2.5 범위 최적화 있으며, 따라서 우리는 “인터벌(interval)”이라는 표현 보다는 범위 조건(range conditions)이라고 표현을 하겠다.
단일 부분 인덱스에 대한 범위 조건의 정의는 다음과 같다:
● BTREE 와 HASH 인덱스 모두에 대해서는, 항수 값을 가지고 있는 키 부분의 비교는 =, <=>, IN, IS NULL, 또는
IS NOT NULL 연산자를 사용할 경우에 범위 조건이 된다.
● BTREE 인덱스의 경우, 항수 값을 가지는 키 부분의 비교는 >, <, >=, <=, BETWEEN, !=, 또는 <> 연
산자, 또는 LIKE 'pattern' (이때의 'pattern'는 와일드카드로 시작되지 않음)을 사용할 때 범위 조건이 된다.
● 모든 타입의 인덱스의 경우, 다중 범위 조건은 OR 또는 AND 형태의 범위 조건과 연결된다.
위의 설명에서 나오는 “항수 값(Constant value)”이란 아래의 것 중에 하나를 의미한다:
● 쿼리 스트링에서 나오는 항수
● 동일한 조인(join)에서 나오는 const 또는 system 테이블의 컬럼
● 서로 연결되어 있지 않는 서브 쿼리의 결과
● 위의 타입에 대한 서브 수식(subexpression)으로만 구성되어 있는 모든 수식
WHERE 구문에서 범위 조건을 가지고 있는 쿼리의 예가 아래에 있다:
SELECT * FROM t1
WHERE key_col > 1

:::MySQL Korea:::
AND key_col < 10;
SELECT * FROM t1
WHERE key_col = 1
OR key_col IN (15,18,20);
SELECT * FROM t1
WHERE key_col LIKE 'ab%'
OR key_col BETWEEN 'bar' AND 'foo';
항수 전파 단계(propagation phase) 동안에 어떤 비 항수 값(non-constant value)들은 항수로 변환 된다는 것을 주의하자.
MySQL은 각각의 모든 가능한 인덱스에 대해 WHERE 구문으로부터 범위 조건을 추출하고자 시도한다. 추출 과정 동안, 범위 조
건을 구축하는데 사용되지 않는 조건들은 제거(dropped)되고, 범위 중첩(overlapping range)을 만드는 조건들은 서로 연결이 되
며, 비어 있는 범위를 만드는 조건들은 제거된다.
아래의 명령문을 검토해 보면, key1은 인덱스된 컬럼이며, nonkey은 인덱스가 되지 않았다:
SELECT * FROM t1 WHERE
(key1 < 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
(key1 < 'bar' AND nonkey = 4) OR

:::MySQL Korea:::
(key1 < 'uux' AND key1 > 'z');
키 key1에 대한 추출 과정은 다음과 같다:
1. 원래의 WHERE 구문을 가지고 시작한다:
2. (key1 < 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR
3. (key1 < 'bar' AND nonkey = 4) OR
4. (key1 < 'uux' AND key1 > 'z')
5. nonkey = 4 와 key1 LIKE '%b'를 제거하는데, 그 이유는 이것들은 범위 조건을 위해 사용되지 않기 때문이다.
TRUE를 가지고 이것들을 대체하면 되며, 이렇게 하면 매치가 되는 모든 열은 범위를 스캔 할 때 누락이 생기지 않게 된
다. TRUE를 가지고 대체를 하면, 다음의 것을 얻게 된다:
6. (key1 < 'abc' AND (key1 LIKE 'abcde%' OR TRUE)) OR
7. (key1 < 'bar' AND TRUE) OR
8. (key1 < 'uux' AND key1 > 'z')
9. 항상 트루(true) 또는 거짓(false)인 조건문을 정리한다(Collapse).:

• (key1 LIKE 'abcde%' OR TRUE)은 항상 트루(true)
• (key1 < 'uux' AND key1 > 'z')은 항상 거짓(false)
이와 같은 조건문을 항수로 대체하면, 다음을 얻게 된다:
(key1 < 'abc' AND TRUE) OR (key1 < 'bar' AND TRUE) OR (FALSE)
필요 없는 TRUE 와 FALSE 항수를 제거하면, 다음을 얻게 된다:
(key1 < 'abc') OR (key1 < 'bar')

:::MySQL Korea:::
10. 중첩되는 인터벌들을 하나로 연결해서 범위 스캔용으로 사용할 최종 조건을 만든다:
11. (key1 < 'bar')
일반적인 경우(위의 설명에서 예시한 대로), 범위 스캔용으로 사용된 조건은 WHERE 구문보다는 덜 제한적이다. MySQL은
WHERE 구문이 아닌 범위 조건을 충족하는 열을 걸러내기 위한 추가적인 검사를 진행한다.
범위 조건 추출 알고리즘은 임의적인 깊이(arbitrary depth)의 네스티드(nested) AND/OR 구조를 처리하며, 그 결과는 WHERE
구문에서 나오는 조건에 있는 순서와는 관련을 갖지 않는다.

:::MySQL Korea:::
제목검색
7.2.5.2. 다중 부분 인덱스에 대한 범위 접근 방식
7.2. SELECT 및 다른 명령문 최적화 하기 다중 부분 인덱스상의 범위 조건은 단일 부분 인덱스에 대한 범위 조건의 확장이다. 다중 범위 인덱스상의 범위 조건은 한 개 또는
7.2.5 범위 최적화 여러 개의 키 튜플(key tuple) 인터벌 내에 인덱스 열을 놓는 것을 제한한다. 키 튜플(Key tuple) 인터벌은 인덱스로부터 순서를
7.2.5.1 단일 부분 인덱스에 대한 범위 접근 방식 사용해서 키 튜플 셋에 걸쳐서 정의 된다.
예를 들면, 다중 부분 인덱스가 key1(key_part1, key_part2, key_part3)로 정의가 되고, 키 순서에서 나열된 키 튜플 셋이 다음
과 같다고 가정하자:
key_part1 key_part2 key_part3
NULL 1 'abc'
NULL 1 'xyz'
NULL 2 'foo'
1 1 'abc'
1 1 'xyz'
1 2 'abc'
2 1 'aaa'
조건 key_part1 = 1은 다음의 인터벌을 정의 한다:

:::MySQL Korea:::
(1,-inf,-inf) <= (key_part1,key_part2,key_part3) < (1,+inf,+inf)
인터벌은 위의 데이터 셋의 4번째, 5번째, 그리고 6번째 튜플을 커버(cover)하며 범위 접근 방식에 의해 사용될 수 있다.
반대로, 조건 key_part3 = 'abc'은 단일 인터벌을 정의하지 않으며 범위 접근 방식에 의해 사용될 수가 없다.
아래의 설명은 범위 조건이 어떻게 다중 부분 인덱스와 동작을 하는지를 보여 준다.
● HASH 인덱스의 경우에는, 독립적인 값을 가지고 있는 각각의 인터벌들이 사용된다. 이것은 아래의 형태에 있는 조건에 대
해서만 인터벌이 만들어진다는 것을 의미한다:
• key_part1 cmp const1
• AND key_part2 cmp const2
• AND ...
• AND key_partN cmp constN;
여기에서, const1, const2, … 는 항수(constants)이며, cmp는 =, <=>, 또는 IS NULL 비교연산자 중의 하나이

며, 그리고 조건은 모든 인덱스 부분을 커버(cover)한다. (즉, N 개의 조건이 존재하고, N-부분 인덱스의 각 부분에 대
해 하나씩 존재한다.) 예를 들면, 아래의 것은 세 부분의 HASH 인덱스에 대한 범위 조건이 된다:
key_part1 = 1 AND key_part2 IS NULL AND key_part3 = 'foo'
항수 정의에 대한 부분에 대해서는, Section 7.2.5.1, “단일 부분 인덱스에 대한 범위 접근 방식”을 참조할 것.
● BTREE 인덱스의 경우, 하나의 인터벌을 AND와 결합된 조건에 대해서 사용할 수가 있는데, 여기에서 각각의 조건은 키
부분을 =, <=>, IS NULL, >, <, >=, <=, !=, <>, BETWEEN를 사용하는 항수 값, 또는 LIKE
'pattern' (이때의 'pattern'은 와일드카드로 시작되지 않음)과 비교를 한다. 조건과 매치되는 모든 열을 가지고 있는 단일
키 튜플(key tuple)을 판단할 수 있는 한 하나의 인터벌을 사용할 수가 있게 된다 (또는 만일 <> 또는 != 가 사용되

:::MySQL Korea:::
었다면, 두개의 인터벌). 예를 들면, 아래의 조건에 대해서는:
• key_part1 = 'foo' AND key_part2 >= 10 AND key_part3 > 10
단일 인터벌은:
('foo',10,10) < (key_part1,key_part2,key_part3) < ('foo',+inf,+inf)
생성된 인터벌이 초기 조건 보다 많은 열을 가지는 것은 가능하다. 예를 들면, 위의 인터벌은 ('foo', 11, 0) 값을 가지고 있

으며, 이것은 원래의 조건을 만족시키지는 못한다.
만일 인터벌 안에 가지고 있는 열 셋( set of rows)를 충족하는 조건이 OR와 결합을 한다면, 그 조건은 자신의 인터벌 조
합 내에 포함되어 있는 열 셋(set of row)를 충족하는 조건을 만든다. 만일 그 조건이 AND와 결합이 된다면, 그 조건은
자신의 인터벌에 대한 교차(intersection) 부분 안에 있는 열 셋을 충족하는 조건을 형성한다. 예를 들면, 두 개 부분
(two-part)의 인덱스에서의 조건에 대해서는:
• (key_part1 = 1 AND key_part2 < 2) OR (key_part1 > 5)
인터벌은:
(1,-inf) < (key_part1,key_part2) < (1,2)
(5,-inf) < (key_part1,key_part2)
이 예제에서 보면, 첫 번째 줄의 인터벌은 왼쪽 경계에 대해서는 하나의 키 부분을 사용하고 오른쪽 경계에 대해서는 두 개
의 키 부분을 사용하고 있다. 두 번째 줄의 인터벌은 하나의 키 부분만을 사용하고 있다. EXPLAIN의 결과에 있는
key_len 컬럼은 사용된 키 접두사(prefix)의 최대 길이를 나타낸다.
어떤 경우에는, key_len가 사용된 키 부분을 가리키기도 하지만, 여러분이 기대하였던 것이 아닌 경우도 있다.
key_part1 및 key_part2 이 NULL 이라고 가정하자. 그렇게 되면 key_len 컬럼은 아래의 조건에 대해서 두 개의 키 부
분 길이를 표시한다:
key_part1 >= 1 AND key_part2 < 2

:::MySQL Korea:::
하지만, 사실은, 조건은 아래와 같이 변환된다:
key_part1 >= 1 AND key_part2 IS NOT NULL

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.6. 인덱스 병합 최적화
7. 최적화(Optimization) 7.2.6.1. 인덱스 병합 교차 접근 알고리즘

7.2. SELECT 및 다른 명령문 최적화 하기 7.2.6.2. 인덱스 병합 결합 접근 알고리즘
7.2.6 인덱스 병합 최적화 7.2.6.3. 인덱스 병합 정렬-결합 접근 알고리즘
7.2.6.1 인덱스 병합 교차 접근 알고리즘

7.2.6.2 인덱스 병합 결합 접근 알고리즘
인덱스 병합 방식은 여러 개의 range 스캔을 가지고서 열을 추출(retrieve)하고 이 결과를 하나로 병합하기 위해 사용된다. 병합
7.2.6.3 인덱스 병합 정렬-결합 접근 알고리즘
은 결합(union), 교차(intersection), 또는 시스템 내부에서 진행되는 스캔(underlying scan)의 교차 결합(union-of-
intersection)을 만들어 낼 수 있다.
Note: 만일 여러분이 MySQL의 예전 버전에서 업그레이드를 했다면, 조인(join)최적화에 대한 이러한 형태는 5.0에서부터 소개되
었고, 또한 인덱스에 관련해서 상당한 변화가 있다는 점을 유의해야 한다. (이전 버전에서는, MySQL은 각각의 참조 테이블에 대해
서는 하나의 인덱스만을 사용할 수 있었다.)
EXPLAIN의 결과에서 보면, 인덱스 병합 방식은 type 컬럼 안에 있는 index_merge 형태로 나타난다. 이와 같은 경우, 키 컬럼은
사용된 인덱스 리스트를 가지며, 그리고 key_len는 이러한 인덱스에 대한 가장 긴 키 부분 리스트를 가진다.
예제:
SELECT * FROM tbl_name WHERE key_part1 = 10 OR key_part2 = 20;
WHERE (key_part1 = 10 OR key_part2 = 20) AND non_key_part=30;

:::MySQL Korea:::
SELECT * FROM t1, t2
WHERE (t1.key1 IN (1,2) OR t1.key2 LIKE 'value%')
AND t2.key1=t1.some_col;
WHERE t1.key1=1
AND (t2.key1=t1.some_col OR t2.key2=t1.some_col2);
인덱스 병합 방식은 여러 개의 접근 알고리즘을 가진다 (EXPLAIN 결과의 Extra 필드에서 보여짐):
● Using intersect(...)
● Using union(...)
● Using sort_union(...)
아래의 섹션에서는 이러한 방식에 대해 보다 자세한 설명을 한다.
Note: 인덱스 병합 최적화 알고리즘은 아래와 같이 이미 알려져 있는 결함을 가지고 있다:
● 만일 범위 스캔이 어떤 키에서 가능하다면, 인덱스 병합은 고려되지 않는다. 예를 들면, 아래의 쿼리를 고려해 보자:
• SELECT * FROM t1 WHERE (goodkey1 < 10 OR goodkey2 < 20) AND badkey < 30;
이 쿼리에 대해서는, 두 가지의 가능성이 생긴다:

:::MySQL Korea:::
❍ (goodkey1 < 10 OR goodkey2 < 20) 조건을 사용하는 인덱스 병합 스캔.

❍ badkey < 30 조건을 사용하는 범위 스캔.
하지만, 옵티마이저는 두 번째 스캔만을 고려한다. 만일 여러분이 원하는 것이 이것이 아니라면, If that is not what you
want, you can make the optimizer consider Index Merge by using IGNORE INDEX 또는 FORCE INDEX을 사용함
으로써 옵티마이저가 인덱스 병합을 고려하도록 만들 수가 있다. 아래의 쿼리는 인덱스 병합을 사용해서 실행된다:
SELECT * FROM t1 FORCE INDEX(goodkey1,goodkey2)
WHERE (goodkey1 < 10 OR goodkey2 < 20) AND badkey < 30;
SELECT * FROM t1 IGNORE INDEX(badkey)
WHERE (goodkey1 < 10 OR goodkey2 < 20) AND badkey < 30;
● 만일 여러분의 쿼리가If your query has a AND/OR 네스팅(nesting)을 사용하는 복잡한 WHERE 구문을 가지고 있고
MySQL이 옵티말 플랜(optimal plan)을 선택하지 않는다면, 아래의 아이덴티티(identity) 규칙을 사용해서 단어(term)
를 분산해 본다:
• (x AND y) OR z = (x OR z) AND (y OR z)
• (x OR y) AND z = (x AND z) OR (y AND z)
● 인덱스 병합은 전체 문장(fulltext) 인덱스에는 적용되지 않는다. 이 부분에 대해서는 향후 MySQL 버전에서 다루기로 한
다.
인덱스 병합 접근 방식의 여러 가지 형태 중에 어떤 것을 선택할지는 다양한 사용 가능한 옵션의 추정 값에 따라서 진행된다.

:::MySQL Korea:::
제목검색
7.2.6.1. 인덱스 병합 교차 접근 알고리즘

7.2. SELECT 및 다른 명령문 최적화 하기 이 접근 알고리즘은 WHERE 구문이 AND와 결합된 서로 다른 키 상에 있는 여러 개의 범위 조건으로 변환될 때 사용될 수 있으
7.2.6 인덱스 병합 최적화 며, 각각의 조건은 아래의 것 중에 하나가 된다:

● 아래의 형태에서는, 인덱스는 정확히 N 개의 부분을 가진다 (즉, 모든 인덱스 부분이 커버(cover)된다):
• key_part1=const1 AND key_part2=const2 ... AND key_partN=constN
● InnoDB 또는 BDB 테이블의 주요 키(primary key)에 걸친 모든 범위 조건.
예제:
SELECT * FROM innodb_table WHERE primary_key < 10 AND key_col1=20;
WHERE (key1_part1=1 AND key1_part2=2) AND key2=2;
인덱스 병합 교차 알고리즘은 모든 사용된 인덱스상에서 동시에 스캔을 실행하고 병합된 인덱스 스캔으로부터 전달 받는 열 시퀀스
(row sequence)에 대한 교차를 만들어 낸다.
만일 사용된 인덱스가 쿼리에서 사용된 모든 컬럼을 커버(cover)한다면, 전체 테이블 열은 추출되지 않는다 (이 경우 EXPLAIN
결과는 Extra 필드(field)에 있는 Using index를 가진다). 아래에는 이러한 쿼리의 예가 있다:

:::MySQL Korea:::
SELECT COUNT(*) FROM t1 WHERE key1=1 AND key2=1;
만일 사용된 인덱스가 쿼리에서 사용된 모든 컬럼을 커버하지 못한다면, 사용된 모든 키에 대한 범위 조건이 만족스러울 때에만 전
체 열이 추출된다.
만일 병합된 조건 중의 하나가 InnoDB 또는 BDB 테이블의 주요 키(primary key)에 걸쳐지는 조건이라면, 이 조건은 열 추출용으
로 사용되지는 않지만, 다른 조건을 사용해서 추출된 열을 걸러 낼 때(filter out) 사용된다.

:::MySQL Korea:::
제목검색
7.2.6.2. 인덱스 병합 결합 접근 알고리즘

7.2. SELECT 및 다른 명령문 최적화 하기 이 알고리즘에 대한 표준은 인덱스 병합 방식 교차 알고리즘과 유사하다. 이 알고리즘은 OR와 결합된 서로 다른 키 상에서 테이블
7.2.6 인덱스 병합 최적화 의 WHERE 구문이 여러 개의 범위 조건으로 변환될 때 적용될 수 있으며, 각 조건은 아래의 것 중에 하나가 된다:

● 아래의 형태에서는, 인덱스는 정확히 N 개의 부분을 가진다 (즉, 모든 인덱스 부분이 커버된다):
• key_part1=const1 AND key_part2=const2 ... AND key_partN=constN
● InnoDB 또는 BDB 테이블의 주요 키(primary key)에 걸친 모든 범위 조건.

● 인덱스 병합 방식 교차 알고리즘을 적용할 수 있는 조건.
예제:
SELECT * FROM t1 WHERE key1=1 OR key2=2 OR key3=3;
SELECT * FROM innodb_table WHERE (key1=1 AND key2=2) OR
(key3='foo' AND key4='bar') AND key5=5;
:::MySQL Korea:::
제목검색
7.2.6.3. 인덱스 병합 정렬-결합 접근 알고리즘

7.2. SELECT 및 다른 명령문 최적화 하기 이 접근 알고리즘은 WHERE 구문이 OR에 의해 결합된 여러 개의 범위 조건으로 변환될 때 적용되지만, 인덱스 병합 방식 결합
7.2.6 인덱스 병합 최적화 (union) 알고리즘에는 적용되지 않는다.

예제:
SELECT * FROM tbl_name WHERE key_col1 < 10 OR key_col2 < 20;
WHERE (key_col1 > 10 OR key_col2 = 20) AND nonkey_col=30;
정렬-결합 알고리즘(sort-union algorithm)과 결합 알고리즘간의 차이점은 정렬 결합 알고리즘의 경우 모든 열의 ID를 우선 가

져온 다음에 열을 돌려 주기 전에 정렬을 한다는 것이다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.7. IS NULL 최적화
7.2. SELECT 및 다른 명령문 최적화 하기 MySQL은 col_name = constant_value용으로 사용할 수 있는 col_name IS NULL상의 최적화를 동일하게 수행한다. 예를 들면,
MySQL은 IS NULL를 사용해서 NULL에 대한 검색을 위해 인덱스와 범위를 사용한다.
7.2.7 IS NULL 최적화
예제:
SELECT * FROM tbl_name WHERE key_col IS NULL;
SELECT * FROM tbl_name WHERE key_col <=> NULL;
WHERE key_col=const1 OR key_col=const2 OR key_col IS NULL;
만일 WHERE 구문이 NOT NULL로 선언된 컬럼에 대한 col_name IS NULL 조건을 포함하고 있다면, 그 수식은 최적화와는 거
리가 멀게 된다. 최적화는 컬럼이 NULL을 만들어 내는 경우에는 일어나지 않는다
MySQL은 또한 col_name = expr AND col_name IS NULL와 같은 조합에 대해서도 최적화를 할 수가 있는데, 이러한 형태는 서
브 쿼리 해석에서는 일반적인 것이다. EXPLAIN은 이러한 최적화가 사용되는 경우에 ref_or_null를 표시한다.
이러한 최적화는 모든 키 부분에 대해서 하나의 IS NULL을 처리한다.

:::MySQL Korea:::
최적화된 쿼리의 예문 중에서, 테이블 t2의 a 와 b 컬럼상에 하나의 인덱스가 존재한다고 가정하자:
SELECT * FROM t1 WHERE t1.a=expr OR t1.a IS NULL;
SELECT * FROM t1, t2 WHERE t1.a=t2.a OR t2.a IS NULL;
WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;
WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);
WHERE (t1.a=t2.a AND t2.a IS NULL AND ...)
OR (t1.a=t2.a AND t2.a IS NULL AND ...);
ref_or_null은 참조 키에서 한번의 읽기를 실행하고, 그 다음에 NULL 키 값을 가지고 열에 대한 별개의 검색을 실행한다.
최적화는 오직 한번의 IS NULL 레벨을 처리한다는 점을 기억하자. 아래의 쿼리에서 보면, MySQL 은 수식 (t1.a=t2.a AND t2.a
IS NULL)에서만 키 룩업(lookup)을 사용하며 b에 있는 키 부분은 사용할 수가 없다:

:::MySQL Korea:::
WHERE (t1.a=t2.a AND t2.a IS NULL)
OR (t1.b=t2.b AND t2.b IS NULL);

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.8. DISTINCT 최적화
7.2. SELECT 및 다른 명령문 최적화 하기 ORDER BY와 연결되어 있는 DISTINCT 는 많은 경우에 임시 테이블을 필요로 한다.
7.2.8 DISTINCT 최적화

DISTINCT는 GROUP BY를 사용할 수도 있기 때문에, 여러분은 선택된 컬럼 부분이 아닌 ORDER BY 또는 HAVING 구문에 있
는 컬럼과 함께 MySQL이 어떻게 동작을 하는지를 반드시 알아 두어야 한다. Section 12.10.3, “숨겨진 필드가 있는 GROUP
BY”를 참조.
대부분의 경우, DISTINCT 구문은 GROUP BY의 특별한 경우(case)로 간주된다. 예를 들면, 아래의 두 쿼리는 동일한 것이다:
SELECT DISTINCT c1, c2, c3 FROM t1 WHERE c1 > const;
SELECT c1, c2, c3 FROM t1 WHERE c1 > const GROUP BY c1, c2, c3;
위의 것이 동일한 것이기 때문에, GROUP BY 쿼리에 적용되는 최적화는 DISTINCT 구문을 가지고 있는 쿼리에도 또한 적용이
될 수 있다. 따라서, DISTINCT 쿼리에 대한 최적화 가능성에 대한 보다 자세한 설명은, Section 7.2.13, “GROUP BY 최적
화”를 참조하기 바란다.
LIMIT row_count 를 DISTINCT에 연결을 할 때에는, MySQL은 row_count 고유(unique) 열을 찾는 즉시 멈추게 된다.
만일 여러분이 쿼리에 명명되어 있는 테이블에 있는 컬럼을 사용하지 않는다면, MySQL은 매치되는 것을 처음으로 찾는 즉시 아
직 사용되지 않은 테이블에 대해서는 스캐닝을 멈추게 된다. 아래의 경우, t1이 t2 보다 먼저 사용된다고 가정하면 (여러분은
EXPLAIN로 검사할 수 있음), MySQL은 t2에서 맨 처음 열을 찾게 되면 t2에서의 읽기를 멈추게 된다 (t1에 있는 특정 열에 대
해).

:::MySQL Korea:::
SELECT DISTINCT t1.a FROM t1, t2 where t1.a=t2.a;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.9. LEFT JOIN 및 RIGHT JOIN 최적화
7.2. SELECT 및 다른 명령문 최적화 하기 MySQL은 아래와 같이 A LEFT JOIN B join_condition을 실행한다:
7.2.9 LEFT JOIN 및 RIGHT JOIN 최적화

● 테이블 B 는 테이블 A 및 A 가 의존하는 모든 테이블에 의존하여 설정된다.
● 테이블 A 는 LEFT JOIN 조건에서 사용되는 모든 테이블(B는 제외)에 의존하여 설정된다.
● LEFT JOIN 조건은 테이블 B에서 열을 추출하는 방법을 결정하기 위해서 사용된다 (달리 표현하면, WHERE 구문에 있
는 조건은 사용되지 않음.)
● 모든 표준 조인(oin)최적화는 실행되지만, 하나의 테이블은 자신이 의존하는 모든 테이블이 읽힌 후에 읽혀진다는 점은 예
외다. 만일 순환 의존성(circular dependence)이 존재한다면, MySQL은 에러가 발생한다.
● 모든 표준 WHERE 최적화는 실행된다.
● 만일 A에 있는 열 중에서 WHERE 구문과 매치되는 것이 있기는 하지만, B에 있는 것 중에는 ON 조건과 맞는 열이 없다
면, 모든 컬럼이 NULL로 설정되는 여분의 B 열이 생성된다.
● 만일 여러분이 어떤 테이블에는 존재하지 않는 열을 찾기 위해 LEFT JOIN을 사용하고 WHERE 부분에서 col_name IS
NULL이라는 테스트를 하고, 이때 col_name이 NOT NULL로 선언된 컬럼 이라면, MySQL은 LEFT JOIN 조건과 맞는
열을 찾은 후에는 더 이상의 열(특정 키 조합에 대해서)에 대한 검색을 멈추게 된다.
RIGHT JOIN의 실행은 테이블 규칙을 반대로 하는 LEFT JOIN의 실행과 유사하다.
조인(join) 옵티마이저는 조인되는 테이블의 순서를 계산한다. LEFT JOIN 또는 STRAIGHT_JOIN이 만들어 내는 테이블 읽기
순서는 조인(oin) 옵티마이저가 자신의 업무를 보다 빠르게 진행할 수 있도록 지원하는데, 그 이유는 검사를 해야 할 테이블 순열
(permutation)이 거의 없기 때문이다. 이것은 만일 여러분이 아래와 같은 타입의 쿼리를 실행한다면, MySQL LEFT JOIN이
MySQL로 하여금 d를 읽기 전에 b를 읽도록 하기 때문에 여기에서 전체 스캔을 진행한다는 점을 알아 두자.
SELECT *

:::MySQL Korea:::
FROM a JOIN b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
WHERE b.key=d.key;
이와 같은 경우에는 FROM 구문에 있는 a 와 b 의 순서를 바꾸어 준다 :
SELECT *
FROM b JOIN a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d ON (d.key=a.key)
WHERE b.key=d.key;
LEFT JOIN의 경우, 만일 WHERE 조건이 생성된 NULL 열에 대해 항상 거짓(false)가 된다면, LEFT JOIN은 보통의 조인(join)
으로 변경된다. 예를 들면, t2.column1이 NULL이었다면, 아래의 쿼리에서는 WHERE 구문이 거짓이 될 것이다.
SELECT * FROM t1 LEFT JOIN t2 ON (column1) WHERE t2.column2=5;
따라서, 쿼리를 일반적인 조인(join)으로 변환하는 것이 안전하다:
SELECT * FROM t1, t2 WHERE t2.column2=5 AND t1.column1=t2.column1;
이렇게 하는 것이 보다 빠르게 수행되게 만드는 것인데, 그 이유는 MySQL이 t2를 t1 이전에 읽기 때문이다. 특정 테이블 순서를
실행하도록 하기 위해서는, STRAIGHT_JOIN를 사용한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.10. 네스티드 조인(Nested Join) 최적화
7.2. SELECT 및 다른 명령문 최적화 하기 MySQL 5.0.1 이후에는, 조인(join)을 표현하는 신텍스에서 네스티드 조인(nested join)을 사용할 수 있게 되었다. 아래에서 설명
7.2.10 네스티드 조인(Nested Join) 최적화 하는 내용은 Section 13.2.7.1, “JOIN 신텍스”에서 설명하고 있는 조인 신텍스를 참조한다.
table_factor 신텍스는 SQL 표준의 확장 형태이다. 표준 SQL의 경우에는 table_reference만을 허용하며, 괄호 안에 이것을 넣을
수는 없다. 만일 내부 조인(inner join)과 동일한 형태로서 table_reference 아이템 리스트에 있는 각각의 콤마를 고려한다면, 이
것은 보수적인 확장(conservative extension)이 된다. 예를 들면:
SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
ON (t2.a=t1.a AND t3.b=t1.b AND t4.c=t1.c)
은 아래와 동일하다:
SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)
MySQL에서는, CROSS JOIN은 INNER JOIN과 언어적으로 동일한 의미를 표현한다(이 둘은 서로 대체해서 사용할 수가 있다).
표준SQL의 경우, 이 둘은 동일한 것이 아니다. INNER JOIN은 ON 구문과 함께 사용된다; 그렇지 않은 경우에는 CROSS JOIN이
사용된다.
MySQL 5.0.1 이전 버전에서는, table_references에 있는 괄호는 생략 되었고 모든 조인(join) 연산은 왼쪽으로 그룹화가 되었
다. 일반적으로, 괄호는 내부 조인 연산(inner join operation)만을 가지고 있는 조인 수식(join expression)에서만 생략될 수가
있다.

:::MySQL Korea:::
괄호를 생략하고 연산 동작을 왼쪽으로 그룹화 하고 나면, 조인 수식은 다음과 같이 된다:
t1 LEFT JOIN (t2 LEFT JOIN t3 ON t2.b=t3.b OR t2.b IS NULL)
ON t1.a=t2.a
수식을 다음과 같이 변환한다:
(t1 LEFT JOIN t2 ON t1.a=t2.a) LEFT JOIN t3
ON t2.b=t3.b OR t2.b IS NULL
하지만, 두 개의 수식은 동일한 것이 아니다. 이것을 알아 보기 위해, 테이블 t1, t2, 그리고 t3가 다음의 상태를 가지고 있다고 가정
하자:
● 테이블 t1 은 (1), (2) 열을 가지고 있다

● 테이블 t2 는 (1,101) 열을 가지고 있다
● 테이블 t3 는 (101) 열을 가지고 있다
이와 같은 경우, 첫 번째 수식은 (1,1,101,101), (2,NULL,NULL,NULL)가 포함된 결과 셋을 만들어 내는데 비해서, 두 번째 수식

은 (1,1,101,101), (2,NULL,NULL,101) 열을 만들게 된다:
mysql> SELECT *
-> FROM t1
-> LEFT JOIN
-> (t2 LEFT JOIN t3 ON t2.b=t3.b OR t2.b IS NULL)
-> ON t1.a=t2.a;

:::MySQL Korea:::
+------+------+------+------+
|a |a |b |b |
+------+------+------+------+
| 1| 1 | 101 | 101 |
| 2 | NULL | NULL | NULL |
+------+------+------+------+
mysql> SELECT *
-> FROM (t1 LEFT JOIN t2 ON t1.a=t2.a)
-> LEFT JOIN t3
-> ON t2.b=t3.b OR t2.b IS NULL;
+------+------+------+------+
|a |a |b |b |
+------+------+------+------+
| 1| 1 | 101 | 101 |
| 2 | NULL | NULL | 101 |

:::MySQL Korea:::
+------+------+------+------+
아래의 예문에서 보면, 외부 조인 연산(outer join operation)은 내부 조인 연산과 함께 사용된다:
t1 LEFT JOIN (t2, t3) ON t1.a=t2.a
이 수식은 아래와 같은 수식으로 변환될 수 없다:
t1 LEFT JOIN t2 ON t1.a=t2.a, t3.
주어진 테이블 상태로 보면, 두 개의 수식은 서로 다른 열 셋을 만들게 된다:
mysql> SELECT *
-> FROM t1 LEFT JOIN (t2, t3) ON t1.a=t2.a;
+------+------+------+------+
|a |a |b |b |
+------+------+------+------+
| 1| 1 | 101 | 101 |
| 2 | NULL | NULL | NULL |
+------+------+------+------+
mysql> SELECT *

:::MySQL Korea:::
-> FROM t1 LEFT JOIN t2 ON t1.a=t2.a, t3;
+------+------+------+------+
|a |a |b |b |
+------+------+------+------+
| 1| 1 | 101 | 101 |
| 2 | NULL | NULL | 101 |
+------+------+------+------+
따라서, 만일 여러분이 외부 조인 연산자(outer join operator)를 사용하는 조인 수식에서 괄호를 생략한다면, 우리는 원래의 수식
에 대한 결과 셋을 변경해야 할지도 모른다.
보다 정확히 말하자면, 우리는 왼쪽 외부 조인 연산의 오른쪽 피 연산자(operand)에 있는 괄호와 오른쪽 조인 연산의 왼쪽 피 연산

자에 있는 괄호를 무시할 수가 없다. 달리 표현하면, 우리는 외부 조인 연산의 내부 테이블 수식에 대한 괄호를 무시할 수 없다는 것
이다. 다른 피 연산자(외부 테이블에 대한 피 연산자)에 대한 괄호는 무시할 수가 있다.
다음의 수식은:
(t1,t2) LEFT JOIN t3 ON P(t2.b,t3.b)
아래의 수식과 동일한 것이다:
t1, t2 LEFT JOIN t3 ON P(t2.b,t3.b)
조인 수식(join expression) (join_table)에 있는 조인 연산의 실행 순서가 왼쪽에서 오른쪽으로 되어 있지 않을 때마다, 우리는

네스티드 조인(nested join)을 거론한다. 아래의 쿼리를 고려해 보자:
SELECT * FROM t1 LEFT JOIN (t2 LEFT JOIN t3 ON t2.b=t3.b) ON t1.a=t2.a

:::MySQL Korea:::
WHERE t1.a > 1
SELECT * FROM t1 LEFT JOIN (t2, t3) ON t1.a=t2.a
WHERE (t2.b=t3.b OR t2.b IS NULL) AND t1.a > 1
위의 쿼리는 아래의 네스티드 조인을 가지고 있다고 간주된다:
t2 LEFT JOIN t3 ON t2.b=t3.b
t2, t3
네스티드 조인은 왼쪽 조인 연산과 함께 처음 쿼리에서 형성되어 있는데 비해서, 두 번째 쿼리에서는 네스티드 조인은 내부 조인 연
산과 함께 구성되어 있다.
처음 쿼리의 경우, 괄호는 생략될 수 있다: 조인 수식의 문법적인 구조는 조인 연산에 대한 실행 순서와 동일하다. 두 번째 쿼리의
경우, 비록 여기에서의 조인 수식은 명백하게 해석될 수 있다고 하더라도 괄호는 생략할 수 없다. (우리의 확장 신텍스의 경우, 비
록 이론적으로는 두 번째 쿼리를 괄호 없이 파싱(parsing)을 시킬 수는 있다고 하더라도, 이 쿼리의 (t2, t3)에서는 괄호가 필요하
게 된다: 우리는 여전히 쿼리에 대해 명확한 이론적 구조를 가지고 있는데, 왜냐하면 LEFT JOIN 및ON 은 수식 (t2,t3)에 대한 왼
쪽과 오른쪽의 구획 문자(delimiter) 역할을 하기 때문이다.)
위에서 보여준 예제는 아래의 사항을 설명하는 것이다:
● 내부 조인(외부 조인이 아님)만을 포함하고 있는 조인 수식의 경우는, 괄호를 생략할 수가 있다. 여러분은 괄호를 제거하
고 왼쪽에서 오른쪽으로 진행 시킬 수가 있다 (또는, 사실은, 테이블을 어떤 순서로도 진행 시킬 수가 있다).
● 일반적인 경우, 내부 조인과 함께 혼합되어 있는 외부 조인에 대해서는 일치하지가 않는다(not true). 괄호를 제거하면 결
과가 변경될 수 있다.
네스티드 외부 조인을 가지고 있는 쿼리는 내부 조인을 가지고 있는 쿼리와 동일한 파이프 라인 방식으로 실행이 된다. 보다 정확

:::MySQL Korea:::
히 표현하면, 네스티드 루프 조인 알고리즘(nested-loop join algorithm)의 변형된 형태가 많이 사용된다. 우리는 3 개의 테이블
T1,T2,T3 에 걸친 조인 쿼리를 가지고 있다고 가정하자:
SELECT * FROM T1 INNER JOIN T2 ON P1(T1,T2)
INNER JOIN T3 ON P2(T2,T3)
WHERE P(T1,T2,T3).
여기에서, P1(T1,T2) 및 P2(T3,T3)은 일종의 조인(join) 조건(수식상에서)인데 비해서, P(t1,t2,t3)는 테이블 T1,T2,T3 컬럼
의 조건이 된다
네스티드 루프 조인 알고리즘은 아래와 같이 이 쿼리를 실행한다:
FOR each row t1 in T1 {
FOR each row t2 in T2 such that P1(t1,t2) {
IF P(t1,t2,t3) {
t:=t1||t2||t3; OUTPUT t;

:::MySQL Korea:::
t1||t2||t3는 “열 t1, t2, 및 t3의 컬럼을 연쇄적으로 연결해서 만든 열”을 의미한다. 아래에 있는 예제 중에서, 열의 이름이 나
타나는 NULL은 이것을 해당 열의 각 컬럼에서 사용한다는 것을 의미한다. 예를 들면, t1||t2||NULL은 “열 t1 과 t2의 컬럼을
연쇄적으로 연결해서 만든 열, 그리고 t3의 각 컬럼에 대해서는 NULL”을 의미한다.
이제, 네스티드 외부 조인을 가지고 있는 쿼리를 고려해 보자:
SELECT * FROM T1 LEFT JOIN
(T2 LEFT JOIN T3 ON P2(T2,T3))
ON P1(T1,T2)
WHERE P(T1,T2,T3).
이 쿼리의 경우, 우리는 네스티드 루프 패턴을 수정하였다:
BOOL f1:=FALSE;
BOOL f2:=FALSE;
IF P(t1,t2,t3) {

:::MySQL Korea:::
f2=TRUE;
f1=TRUE;
IF (!f2) {
IF P(t1,t2,NULL) {
t:=t1||t2||NULL; OUTPUT t;
f1=TRUE;
IF (!f1) {
IF P(t1,NULL,NULL) {
t:=t1||NULL||NULL; OUTPUT t;

:::MySQL Korea:::
일반적인 경우, 외부 조인 연산에서 첫 번째의 내부 테이블에 대한 네스티드 루프에 대해서는, 루프가 시작되기 전에 꺼지고
(turned off) 루프를 수행한 후에 검사를 받는 플래그(flag)가 추가된다. 플래그는 외부 테이블의 현재 열에 대해 내부 연산자를 표
시하는 테이블에서 매치되는 것이 발견되면 켜지게 된다(turn on). 만일 루프 사이클 마지막까지 플래그가 여전히 꺼져 있다면, 외
부 테이블의 현재 열에 대해 아무런 매치도 발견되지 않았다는 것이다. 이와 같은 경우, 열은 내부 테이블 컬럼에 대해서 NULL 값
으로 보완 된다. 결과 열은 결과에 대한 마지막 검사를 진행하거나 또는 다음 네스티드 루프로 들어가게 되지만, 그 열이 모든 임베
디드 외부 조인(embedded outer join)의 조인 조건을 만족할 경우에만 해당된다.
우리의 예제에서 보면, 아래의 수식으로 표현된 외부 조인 테이블(outer join table)은 임베디드된다:
(T2 LEFT JOIN T3 ON P2(T2,T3))
내부 조인을 가지고 있는 쿼리에 대해서는, 옵티마이저가 아래의 것과 같은 별도의 네스티드 루프 순서를 선택한다:
IF P(t1,t2,t3) {
외부 조인을 가지고 있는 쿼리의 경우, 옵티마이저는 외부 테이블에 대한 루프가 내부 테이블을 위한 루프보다 앞서는 경우의 순서
만을 선택한다. 따라서, 외부 조인을 가지고 있는 우리의 쿼리에 대해서는, 단지 하나의 네스팅 순서(nesting order)만이 가능하

:::MySQL Korea:::
다. 아래의 쿼리에 대해서는, 옵티마이저는 두 가지의 서로 다른 네스팅을 구하게 된다:
SELECT * T1 LEFT JOIN (T2,T3) ON P1(T1,T2) AND P2(T1,T3)
WHERE P(T1,T2,T3)
네스팅은 다음과 같다:
BOOL f1:=FALSE;
IF P(t1,t2,t3) {
f1:=TRUE
IF (!f1) {

:::MySQL Korea:::
그리고:
BOOL f1:=FALSE;
IF P(t1,t2,t3) {
f1:=TRUE
IF (!f1) {

:::MySQL Korea:::
두 가지의 네스팅에서 보면, T1은 외부 루프에서 처리되어야 하는데, 그 이유는 이것이 외부 조인에서 사용되기 때문이다. T2 및
T3는 내부 조인에서 사용되며, 따라서 이것들은 내부 루프에서 처리되어야 한다. 하지만, 조인이 내부 조인이기 때문에, T2 및 T3
는 둘 중의 하나의 순서로 처리될 수가 있다.
내부 조인에 대한 네스티드 루프 알고리즘을 설명할 때, 우리는 쿼리 실행 성능에 막대한 영향을 줄 수도 있는 것을 생략했다. 우리

는 소위 “푸시 다운(pushed-down)” 조건을 언급하지 않았다. 우리의 WHERE 조건 P(T1,T2,T3)이 결합 공식(conjunctive
formula)으로 표현될 수 있다고 가정을 한다:
P(T1,T2,T2) = C1(T1) AND C2(T2) AND C3(T3).
이와 같은 경우, MySQL은 실제로 내부 조인을 가지고 있는 쿼리를 실행하기 위해 아래의 네스티드 루프 스키마를 사용하게 된다:
FOR each row t1 in T1 such that C1(t1) {
FOR each row t2 in T2 such that P1(t1,t2) AND C2(t2) {
FOR each row t3 in T3 such that P2(t2,t3) AND C3(t3) {
IF P(t1,t2,t3) {

:::MySQL Korea:::
여러분은 각각의 결합(conjunct) C1(T1), C2(T2), C3(T3)들이 실행될 때 가장 내부에 있는 루프를 가장 외부 루프로 밀어 내
는 것을 볼 수 있을 것이다. 만일 C1(T1)이 매우 제한적인 조건이라면, 이 조건 푸시 다운은 내부 루프에 전달된 테이블 T1에서 열
의 숫자를 현격하게 줄일 수 있게 된다. 결과적으로, 쿼리의 실행 시간이 매우 많이 개선이 되는 것이다.
외부 조인을 가지고 있는 쿼리의 경우, WHERE 조건은 외부 테이블의 현재 열이 내부 테이블에서 매치가 되는 것을 발견한 후에
만 검사된다. 따라서, 조건을 내부 네스티드 루프 밖으로 밀어 내는 최적화는 외부 조인을 가지고 있는 쿼리에는 직접적으로 적용
할 수가 없다. 여기에서 우리는 하나의 매치를 발견할 때 켜지는 플래그가 보호하는 조건 푸시 다운(conditional push-down) 술
어(predicate) 개념을 추가해야 했다.
외부 조인을 가지고 있는 예문에 대해서는:
P(T1,T2,T3)=C1(T1) AND C(T2) AND C3(T3)
보호가 된 푸시 다운 조건(guarded pushed-down condition)은 다음과 같이 된다:
FOR each row t1 in T1 such that C1(t1) {
BOOL f1:=FALSE;
FOR each row t2 in T2
such that P1(t1,t2) AND (f1?C2(t2):TRUE) {
BOOL f2:=FALSE;

:::MySQL Korea:::
FOR each row t3 in T3
such that P2(t2,t3) AND (f1&&f2?C3(t3):TRUE) {
IF (f1&&f2?TRUE:(C2(t2) AND C3(t3))) {
f2=TRUE;
f1=TRUE;
IF (!f2) {
IF (f1?TRUE:C2(t2) && P(t1,t2,NULL)) {
t:=t1||t2||NULL; OUTPUT t;
f1=TRUE;
IF (!f1 && P(t1,NULL,NULL)) {

:::MySQL Korea:::
일반적으로, 푸시 다운 술어(pushed-down predicates)는 P1(T1,T2) 및 P(T2,T3)와 같은 조인 조건(join condition)에서 가

져올 수 있다. 이와 같은 경우, 푸시 다운 술어(pushed-down predicate)는 대응되는 외부 조인 연산에 의해 만들어지는 NULL-
보완(complemented) 열에 대한 술어(predicate) 검사를 막는 플래그에 의해 보호가 된다.
하나의 내부 테이블에서 동일하게 네스티드 조인이 되어 있는 다른 테이블로의 접근은 만일 이 접근이 WHERE 조건에서의 술어
에 의해 발생될 경우에는 금지가 된다. (이와 같은 경우, 우리는 조건 키 접근을 사용하였지만, 이 기법은 아직까지 5.0에는 추가되
지 않았다.)

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.11. 외부 조인(Outer Join) 단순화
7.2. SELECT 및 다른 명령문 최적화 하기 많은 경우에 있어서 쿼리의 FROM 구문에 있는 테이블 수식은 단순화 시킬 수가 있다.
7.2.11 외부 조인(Outer Join) 단순화

파서(parser) 단계에서, 오른쪽 외부 조인 연산(right outer joins operation)이 있는 쿼리는 왼쪽 조인 연산만을 가지고 있는 동
일한 쿼리로 변환시킬 수가 있다. 일반적인 경우, 이러한 변환은 아래의 규칙에 따라서 진행된다:
(T1, ...) RIGHT JOIN (T2,...) ON P(T1,...,T2,...) =
(T2, ...) LEFT JOIN (T1,...) ON P(T1,...,T2,...)
T1 INNER JOIN T2 ON P(T1,T2) 형태의 모든 내부 조인 수식은 WHERE 조건과의 결합 형태로서 조인이 된( 또는 만일 존재

한다면, 임베디드 조인의 조인 조건으로) 리스트 T1,T2, P(T1,T2)에 의해 대체가 된다.
옵티마이저가 외부 조인 연산을 가지고 있는 조인 쿼리에 대한 플랜을 계산할 때, 이것은 각각의 연산에 대해서는, 외부 테이블을
내부 테이블보다 먼저 접근하는 플랜에 대해서만 고려를 하게 된다. 옵티마이저의 옵션들은 제한적이 되는데, 그 이유는 이러한 플
랜들만이 네스티드 루프 스키마에 의한 외부 조인 연산을 가진 쿼리를 실행할 수 있도록 하기 때문이다.
아래와 같은 쿼리를 가지고 있다고 가정하자:
SELECT * T1 LEFT JOIN T2 ON P1(T1,T2)
WHERE P(T1,T2) AND R(T2)
이 쿼리의 R(T2)는 T2로부터 많은 수의 매칭 열을 가지고 있다고 가정한다. 만일 우리가 쿼리를 위와 같이 실행 시킨다면, 옵티마
이저는 매우 비 효율적인 실행 플랜을 가지고 테이블 T1을 테이블 T2 전에 접속하는 것 이외에는 선택을 하지 못하게 된다.

:::MySQL Korea:::
다행스럽게도, MySQL은 WHERE 조건이 널 값 거부(null-rejected)가 되는 경우에는, 이러한 쿼리를 외부 조인 연산이 없는 쿼

리로 변화시켜 버린다. 만일 그러한 연산을 위해 구성된 NULL-보완 열에 대해서 어떤 조건이 FALSE 또는 UNKNOWN로 계산
된다면, 이러한 조건을 외부 조인 연산에 대한 널 값 거부(null-rejected)라고 부르게 된다.
따라서, 아래와 같은 외부 조인에 대해서는:
T1 LEFT JOIN T2 ON T1.A=T2.A
아래와 같은 조건들은 널 값 거부(null-rejected)라고 불리게 된다:
T2.B IS NOT NULL,
T2.B > 3,
T2.C <= T1.C,
T2.B < 2 OR T2.C > 1
하지만, 아래와 같은 조건들은 여기에 해당하지 않는다:
T2.B IS NULL,
T1.B < 3 OR T2.B IS NOT NULL,
T1.B < 3 OR T2.B > 3
어떤 조건이 외부 조인 연산에 대해서 널 값 거부인지 아닌지를 검사하는 일반적인 규칙은 간단하다. 아래의 경우에 해당되면 널
값 거부(null-rejected) 조건이 된다:
● 조건이 A IS NOT NULL 형태이고, 이때 A는 내부 테이블의 속성을 가지고 있는 경우

● 조건 인수 중의 하나가 NULL일 때 UNKNOWN을 만들어 내는 내부 테이블을 참조하는 술어일 경우

:::MySQL Korea:::
● 조건이 하나의 접속사 형태로 널 값 거부 조건을 가지고 있는 결합(conjunction)일 경우

● 조건이 널 값 거부 조건의 분리된 형태일 경우
하나의 조건이 어떤 쿼리에서는 외부 조인 연산에 대해서 널 값 거부가 되고 다른 쿼리에 대해서는 그렇지 않게 될 수도 있다. 아래
의 쿼리에서 보면:
SELECT * FROM T1 LEFT JOIN T2 ON T2.A=T1.A
LEFT JOIN T3 ON T3.B=T1.B
WHERE T3.C > 0
WHERE 조건은 두 번째 외부 조인 연산에 대해서는 널 값 조건이 되지만, 첫 번째 것에 대해서는 그렇지 않게 된다.
만일 WHERE 조건이 하나의 쿼리에서 외부 조인 연산에 대한 널 값 거부가 되면, 그 외부 조인 연산은 내부 조인 연산으로 대체가
된다.
예를 들면, 앞에서 보여준 쿼리는 아래의 쿼리로 대체가 된다:
INNER JOIN T3 ON T3.B=T1.B
WHERE T3.C > 0
원래의 쿼리에 대해서는, 옵티마이저는 오직 하나의 접속 순서인T1,T2,T3 와 호환되는 플랜만을 계산한다. 대체되는 쿼리에 대해
서는, 옵티마이저는 접속 시퀀스 T3,T1,T2에 대해서도 추가적으로 고려를 하게 된다.
하나의 외부 조인 연산에 대한 변환은 다른 변환을 트리거 할 수도 있다. 따라서 아래의 쿼리는:
LEFT JOIN T3 ON T3.B=T2.B

:::MySQL Korea:::
WHERE T3.C > 0
다음과 같이 우선 변환 된다:
INNER JOIN T3 ON T3.B=T2.B
WHERE T3.C > 0
이것은 다음의 쿼리와 동일하게 된다:
SELECT * FROM (T1 LEFT JOIN T2 ON T2.A=T1.A), T3
WHERE T3.C > 0 AND T3.B=T2.B
이제 남아 있는 외부 조인 연산은 내부 조인으로 역시 대체가 되는데, 그 이유는 T3.B=T2.B이 널 값 거부 조건이고 외부 조인이

전혀 없이 쿼리를 가져오기 때문이다:
SELECT * FROM (T1 INNER JOIN T2 ON T2.A=T1.A), T3
WHERE T3.C > 0 AND T3.B=T2.B
때로는 하나의 임베디드 외부 조인 연산을 대체할 수도 있으나, 임베디드 외부 조인을 변환시킬 수는 없다. 다음의 쿼리는:
(T2 LEFT JOIN T3 ON T3.B=T2.B)
ON T2.A=T1.A

:::MySQL Korea:::
WHERE T3.C > 0
아래의 형태로 변환된다:
(T2 INNER JOIN T3 ON T3.B=T2.B)
ON T2.A=T1.A
WHERE T3.C > 0,
이것은 임베디드 외부 조인 연산을 여전히 가지고 있는 형태만으로 다시 쓰여질 수가 있다:
(T2,T3)
ON (T2.A=T1.A AND T3.B=T2.B)
WHERE T3.C > 0.
쿼리 안에 있는 임베디드 외부 조인 연산을 변환 시키고자 할 때에는, WHERE 조건과 함께 임베디드 외부 조인에 대한 조인 조건

을 반드시 고려해야 한다. 아래의 쿼리에서 보면:
(T2 LEFT JOIN T3 ON T3.B=T2.B)
ON T2.A=T1.A AND T3.C=T1.C
WHERE T3.D > 0 OR T1.D > 0

:::MySQL Korea:::
WHERE 조건은 임베디드 외부 조인에 대해서는 널 값 거부 조건이 아니지만, 임베딩 외부 조인(embedding outer join) T2.
A=T1.A AND T3.C=T1.C의 조인에 대해서는 널 값 거부 조건이 된다. 따라서 위의 쿼리는 아래와 같이 변환 될 수 있다:
(T2, T3)
ON T2.A=T1.A AND T3.C=T1.C AND T3.B=T2.B
WHERE T3.D > 0 OR T1.D > 0
외부 조인 연산을 내부 조인으로 변환 시키는 알고리즘은 MySQL 5.0.1에서 전체적으로 구현되었다. MySQL 4.1 버전에서는 일
부 기능만이 실행되었다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.12. ORDER BY 최적화
7.2. SELECT 및 다른 명령문 최적화 하기 어떤 경우에는, MySQL은 어떠한 추가 정렬 행위를 하지 않고서도 하나의 인덱스만을 사용해서 ORDER BY 구문을 만족 시킬 수
있게 된다.
인덱스의 사용하지 않는 모든 부분과 모든 여분의 ORDER BY 컬럼이 WHERE 구문에서 항수로 되어 있는 한, ORDER BY가 인덱
스와 정확히 매치가 되지 않는다고 하더라도 위의 형태로 사용할 수가 있게 된다. 아래의 쿼리들은 인덱스를 사용해서 ORDER BY
부분을 해석하고 있다:
SELECT * FROM t1
ORDER BY key_part1,key_part2,... ;
SELECT * FROM t1
WHERE key_part1=constant
ORDER BY key_part2;
SELECT * FROM t1
ORDER BY key_part1 DESC, key_part2 DESC;

:::MySQL Korea:::
SELECT * FROM t1
WHERE key_part1=1
ORDER BY key_part1 DESC, key_part2 DESC;
어떤 경우에는, MySQL이 WHERE 구문과 매치되는 열을 찾기 위해 인덱스를 여전히 사용하고 있다고 하더라도, 그 인덱스를 사
용해서 ORDER BY를 해석하지 못하는 경우가 있다. 아래의 경우가 이에 해당한다:
● 서로 다른 키에서 ORDER BY를 사용한다:
• SELECT * FROM t1 ORDER BY key1, key2;
● 키의 비 연속 부분(non-consecutive part)에서 ORDER BY를 사용한다:
• SELECT * FROM t1 WHERE key2=constant ORDER BY key_part2;
● ASC 와 DESC를 혼용한다:
• SELECT * FROM t1 ORDER BY key_part1 DESC, key_part2 ASC;
● 열을 가져오기 위해 사용한 키가 ORDER BY에서 사용한 것과 동일한 것이 아니다:
• SELECT * FROM t1 WHERE key2=constant ORDER BY key1;
● 여러분이 많은 테이블을 조인(joining)하는 중이고, ORDER BY에 있는 컬럼들이 열을 복원하는데 사용된 맨 처음의 비 항
수 테이블에서 나온 것들이 아니다. (이것은 EXPLAIN 결과에 있는 const 조인 타입을 가지고 있지 않는 첫 번째 테이블이
다.)
● 여러분은 서로 다른 ORDER BY 와 GROUP BY 수식을 가지고 있다.
● 사용된 테이블 인덱스 타입이 순서에 맞게 열을 저장하지 않는다. 예를 들면, 이것은 MEMORY 테이블에 있는 HASH 인덱

:::MySQL Korea:::
스에 대해서는 트루(true)가 된다.
EXPLAIN SELECT ... ORDER BY를 사용하면, 여러분은 MySQL이 인덱스를 가지고 쿼리를 해석할 수 있는지를 알아볼 수가 있
게 된다. 만일 여러분이 Extra 컬럼에 있는 Using filesort를 사용한다면, MySQL은 인덱스를 사용해서 쿼리를 해석할 수 없게 된
다. Section 7.2.1, “EXPLAIN을 사용해서 쿼리 최적화 하기”를 참조.
filesort 최적화는 정렬 키 값과 열 위치 및 쿼리용으로 요구되는 컬럼 기록을 사용한다. filesort 알고리즘은 아래와 같이 동작을 한
다:
1. WHERE 구문과 매치되는 열을 읽는다.

2. 각각의 열에 대해서는, 정렬 키 값과 열 위치를 구성하는 값 튜플(tuple of value)과 쿼리용으로 요구되는 컬럼을 기
록한다.
3. 정렬 키 값을 가지고서 튜플을 정렬한다
4. 정렬된 순서로 열을 추출하지만, 테이블에 다시 접속을 하는 대신에 정렬된 튜플에서 직접 필요한 컬럼을 읽는다.
속도가 느려지는 것을 막기 위해서, 이 알고리즘은 정렬 튜플에 있는 여분의 컬럼의 전체 크기가 max_length_for_sort_data 시스

템 변수의 값을 초과하지 않는 경우에만 이러한 최적화를 사용한다.
만일 ORDER BY의 속도를 증가시키고 싶다면, 여러분이 추가적인 정렬을 실행하지 않고 인덱스를 사용하도록 MySQL을 만들 수
있는지를 검사하면 된다. 만일 이렇게 하는 것이 불가능하다면, 아래의 전략을 사용하도록 한다:
● sort_buffer_size 변수의 크기를 증가 시킨다.

● read_rnd_buffer_size 변수의 크기를 증가 시킨다.
● 빈 공간이 많은 지정 파일 시스템(dedicated filesystem)을 가리키도록 tmpdir를 변경 시킨다. 이 옵션은 라운드 로빈
(round-robin) 형태에서 사용되는 여러 가지의 경로를 수용한다. 경로는 유닉스에서는 콜론 문자(‘:’)로, 윈도우 및
NetWare와 OS/2에서는 (‘;’)로 구분한다. 여러분은 이 기능을 사용해서 여러 디렉토리에 로드를 분산할 수가 있다.
Note: 이러한 경로는 서로 물리적으로 다른 디스크상에 존재하는 파일 시스템에 있는 디렉토리의 경로가 되어야 하며, 동
일 디스크에 있는 별도의 파티션상에 존재하는 디렉토리에 해당하는 것이 아님을 주의한다.
디폴트로, MySQL은 마치 여러분이 쿼리 안에 ORDER BY col1, col2, ... 를 지정한 것처럼 모든 GROUP BY col1, col2, ... 쿼리
를 정렬한다. 만일 여러분이 동일한 컬럼 리스트를 가지고 있는 ORDER BY 구문을 명확하게 포함시킨다면, MySQL은 비록 정렬

:::MySQL Korea:::
이 여전히 일어날 지라도, 어떠한 속도의 저하 없이 이것을 최적화 시키게 된다. 만일 쿼리가 GROUP BY를 포함하고는 있으나 여
러분은 그 결과를 정렬하는 오버헤드를 피하고자 한다면, ORDER BY NULL을 지정해 줌으로서 정렬 동작을 억제 시킬 수가 있
다. 예를 들면:
INSERT INTO foo
SELECT a, COUNT(*) FROM bar GROUP BY a ORDER BY NULL;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.13. GROUP BY 최적화
7. 최적화(Optimization) 7.2.13.1. 느슨한 인덱스 스캔(Loose index scan)

7.2. SELECT 및 다른 명령문 최적화 하기 7.2.13.2. 타이트한 인덱스 스캔(Tight index scan)

The most general way to satisfy a GROUP BY 구문을 만족 시키는 가장 일반적인 방법은 테이블 전체를 스캔하고 각 그룹에
서 나오는 모든 열들이 연속적으로 구성이 되는 임시 테이블을 생성을 한 후에, 이 테이블을 사용해서 그룹을 찾고 집합 함수
7.2.13.2 타이트한 인덱스 스캔(Tight index scan)
(aggregate function)(존재 한다면)을 적용한다.
GROUP BY를 위한 인덱스 사용에 있어서 가장 중요한 선결 조건은 모든 GROUP BY 컬럼 참조가 동일한 인덱스에서 속성을 가
져오고, 인덱스는 자신의 키를 순서대로 저장한다는 것이다 (예를 들면, 이것은 BTREE 인덱스이며 HASH 인덱스가 아님). 임
시 테이블 사용을 인덱스 접속으로 대체할 수 있는지는 쿼리에서 사용된 인덱스 부분과, 이 부분을 지정하는 조건, 그리고 선택된
집합 함수에 따라 정해진다.
인덱스 접속을 통한 GROUP BY 쿼리 실행에는 두 가지 방법이 있다. 첫 번째 방법은, 그룹 연산을 모든 범위 술어(존재할 경우)
와 함께 적용시키는 것이며, 두 번째로는 범위 스캔을 우선 실행하고, 그 다음에 결과 튜플 그룹에 대해 스캔을 하는 방법이 있다.
:::MySQL Korea:::
제목검색
7.2.13.1. 느슨한 인덱스 스캔(Loose index scan)

7.2. SELECT 및 다른 명령문 최적화 하기 가장 효과적으로 GROUP BY를 처리하는 방법은 인덱스를 사용해서 그룹 필드에서 직접 데이터를 추출할 때이다. 이러한 접속 방
7.2.13 GROUP BY 최적화 식을 통해서, MySQL은 키를 정렬시키는 인덱스 타입의 특성을 사용하게 된다 (예를 들면, BTREE). 이러한 특성은 모든
7.2.13.1 느슨한 인덱스 스캔(Loose index scan) WHERE 조건을 만족시키는 인덱스내의 모든 키를 고려하지 않는 상태로 인덱스에 있는 룩업 그룹(lookup group)을 사용할 수 있
도록 해 준다. 이러한 접속 방식은 인덱스 안에 있는 키 조각(fraction)만을 고려하며, 따라서 이것을 느슨한 인덱스 스캔(loose
7.2.13.2 타이트한 인덱스 스캔(Tight index
scan) index scan)이라고 부른다. 아무런 WHERE 구문이 존재하지 않을 경우, 느슨한 인덱스 스캔은 그룹의 수 만큼의 키를 읽어 오며,
이것은 모든 키 숫자보다는 훨씬 작은 숫자가 된다. 만일 WHERE 구문이 범위 술어를 가지고 있다면 (range 조인 타입에 대한
Section 7.2.1, “Optimizing Queries with EXPLAIN”를 참조할 것), 느슨한 인덱스 스캔은 범위 조건을 만족시키는 각 그룹의
첫 번째 키를 조사하고, 최소 가능 키 숫자를 다시 읽게 된다. 이것은 아래의 조건하에서 가능해 진다:
● 쿼리가 한 테이블을 넘어 선다.

● GROUP BY가 인덱스의 첫 번째 연속 부분을 포함하고 있다. (만일 쿼리가 GROUP BY대신에 DISTINCT 구문을 가지고
있다면, 모든 속성들은 인덱스의 처음 시작 부분을 참조하게 된다.)
● (존재할 경우) 사용되는 집합 함수는 MIN() 와 MAX()만이며, 이것들은 모두 동일 컬럼을 참조한다.
● 쿼리에서 참조되는 GROUP BY에서 나오는 것이 아닌 인덱스의 다른 모든 부분은 반드시 항수 이어야 하지만 (즉, 이것들
은 항수와 동일하게 참조되어야 한다), MIN() 또는 MAX() 함수의 인수에 대해서는 예외적이다.
이러한 쿼리에 대한 EXPLAIN의 결과는 Extra 컬럼에 Using index for group-by를 보여준다.
아래의 쿼리들은 이러한 범주에 속하는 것이며, 여기에는assuming that there is an index 테이블 t1(c1,c2,c3,c4)상에 idx(c1,
c2,c3) 인덱스가 있다고 가정한다:
SELECT c1, c2 FROM t1 GROUP BY c1, c2;
SELECT DISTINCT c1, c2 FROM t1;

:::MySQL Korea:::
SELECT c1, MIN(c2) FROM t1 GROUP BY c1;
SELECT c1, c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;
SELECT MAX(c3), MIN(c3), c1, c2 FROM t1 WHERE c2 > const GROUP BY c1, c2;
SELECT c2 FROM t1 WHERE c1 < const GROUP BY c1, c2;
SELECT c1, c2 FROM t1 WHERE c3 = const GROUP BY c1, c2;
다음의 쿼리들은 이러한 선택 방식을 가지고서는 실행될 수 없는데, 그 이유는 다음과 같다:
● MIN() 또는 MAX()가 아닌 다른 집합 함수가 있다. 예를 들면:
• SELECT c1, SUM(c2) FROM t1 GROUP BY c1;
● The fields in the GROUP BY 구문에 있는 필드는 인덱스 시작 부분을 참조하지 못한다:
• SELECT c1,c2 FROM t1 GROUP BY c2, c3;
● 쿼리는 GROUP BY 부분 다음에 나오는 키 부분을 참고하며, 항수와 일치 되지 않는다:
• SELECT c1,c3 FROM t1 GROUP BY c1, c2;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.13.2. 타이트한 인덱스 스캔(Tight index scan)
7.2. SELECT 및 다른 명령문 최적화 하기 타이트 인덱스 스캔은 쿼리 조건에 따라서 전체 인덱스 스캔 또는 범위 인덱스 스캔이 될 수 있다.

느슨한 인덱스 스캔에 대한 조건이 맞지 않을 때에는, GROUP BY 쿼리를 위한 임시 테이블 생성을 하지 않을 수도 있다. 만일
WHERE 구문에 범위 조건이 존재한다면, 이 방식은 이 조건을 만족하는 키에 대해서만 읽기를 실행한다.
7.2.13.2 타이트한 인덱스 스캔(Tight index
scan)
그렇지 않으면, 이 방식은 인덱스 스캔을 실행한다. 이 방식은 WHERE 구문이 정의한 각 범위 안에 있는 모든 키를 읽거나, 또는
만일 아무런 범위 조건이 없다면 전체 인덱스를 스캔하기 때문에, 우리는 이것을 타이트한 인덱스 스캔이라고 부른다. 타이트한 인
덱스 스캔을 사용한다면, 그룹 연산(grouping operation)은 범위 조건을 만족 시키는 모든 키를 찾고 난 후에만 실행된다는 점을
알아 두기 바란다.
이 방식이 동작되도록 하기 위해서는, GROUP BY 키의 부분간에 나오거나 또는 이 키가 나오기 전에 나오는 키를 참조하는 쿼리

의 모든 컬럼에 대해 항수 등식 조건(constant equality condition)이 존재하기만 하면 된다. 등식 조건에서 나오는 항수는 인덱스
의 접두사(prefix)가 완벽한 형태를 갖추도록 하기 위해서 검색 키에 집어 넣어진다. 그렇게 되면 이 인덱스 접두사는 인덱스 루프
를 실행하는데 사용될 수가 있다. 만일 우리가 GROUP BY의 결과에 대해 정렬을 하도록 요구한다면, 인덱스의 접두사인 검색 키
를 만드는 것이 가능하며, MySQL은 순서화된 인덱스에 있는 접두사를 사용한 검색이 이미 순서별로 모든 키를 추출하였기 때문
에 추가적인 정렬을 하지 않게 된다.
아래의 쿼리는 위에서 설명한 느슨한 인덱스 스캔 접속 방식과는 동작을 하지는 않지만, 타이트한 인덱스 스캔 접속 방식과는 동작
을 한다 (인덱스 idx(c1,c2,c3) t1(c1,c2,c3,c4)에 인덱스 idx(c1,c2,c3)가 존재한다고 가정하자).
● GROUP BY에는 갭(gap)이 존재하지만, 조건 c2 = 'a'에 의해 커버(cover)된다:
• SELECT c1, c2, c3 FROM t1 WHERE c2 = 'a' GROUP BY c1, c3;

:::MySQL Korea:::
● GROUP BY는 키의 처음 부분을 가지고서는 시작하지 않지만, 그 부분에 대한 항수를 제공하는 조건이 존재한다:
• SELECT c1, c2, c3 FROM t1 WHERE c1 = 'a' GROUP BY c2, c3;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.14. LIMIT 최적화
7.2. SELECT 및 다른 명령문 최적화 하기 어떤 경우에는, MySQL은 여러분이 LIMIT row_count은 사용하면서 HAVING은 사용하지 않으면 쿼리를 다른 방식으로 다루게
7.2.14 LIMIT 최적화 된다.
● 만일 여러분이 LIMIT를 사용해서 적은 수의 열만을 선택한다면, MySQL은 전체 테이블 스캔을 행하는 인덱스를 사용한
다.
● 만일 여러분이 LIMIT row_count를 ORDER BY와 함께 사용한다면, MySQL은 정렬된 결과의 첫 번째 row_count 열을
찾은 즉시 정렬 동작을 마친다. 만일 인덱스를 사용해서 순서를 매기게 된다면, 이것은 속도가 매우 빠르게 된다. 만일 파
일 정렬이 마쳐졌다면, LIMIT 구문이 없이 쿼리와 매치가 된 모든 열은 선택되어야 하고, 이러한 것들은 거의 모두 저장이
되어야 하며, 이런 동작들은 첫 번째 row_count 열이 발견되기 전에 이루어져야 한다. 둘 중의 하나의 경우에라도, 처음의
열이 발견된 후에는, 결과 셋의 나머지 부분에 대한 추가적인 정렬은 필요없게 되며, MySQL은 이를 실행하지 않는다.
● LIMIT row_count를 DISTINCT와 연결을 할 때, MySQL은 고유의 row_count 열(unique rows)을 찾는 즉시 멈추게 된
다.
● 어떤 경우에는, 순서대로(또는 키를 정렬함으로서) 키를 읽고 키 값이 변경될 때까지 요약 계산을 실행함으로써 GROUP
BY를 해석할 수가 있다. 이와 같은 경우, LIMIT row_count 는 필요하지 않은 모든 GROUP BY 값은 계산하지 않는다.
● MySQL이 필요한 열의 수를 클라이언트로 보내고 난 후에, 여러분이 SQL_CALC_FOUND_ROWS를 사용하지 않는 한 쿼
리를 즉시 끝내 버린다.
● LIMIT 0은 재빨리 비어 있는 셋(empty set)을 하나 돌려준다. 이것은 쿼리의 유효성을 검사하는데 유용하게 사용할 수
가 있다. MySQL API 중의 하나를 사용할 경우에, 결과 컬럼 타입을 얻기 위해서도 이것을 사용할 수가 있다. (이것은
MySQL 모니터 (mysql 프로그램)에서는 동작을 하지 않는데, 이것은 단지 이와 같은 경우의 Empty set을 보여주기만 한
다; 대신에 여러분은 이러한 목적으로는 SHOW COLUMNS 또는 DESCRIBE 를 사용하면 된다.)
● 서버가 쿼리를 해석하기 위해서 임시 테이블을 사용한다면, 서버는 얼마의 공간이 필요한지를 계산하기 위해서 LIMIT
row_count 구문을 사용한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.15. 테이블 스캔을 피하는 방법
7.2. SELECT 및 다른 명령문 최적화 하기 EXPLAIN의 결과는 MySQL이 쿼리를 해석하기 위해 테이블 스캔을 사용할 때 type 컬럼에 있는 ALL을 보여준다. 이것은 일반적
7.2.15 테이블 스캔을 피하는 방법 으로 아래와 같은 조건 아래에서 나타난다:
● 테이블이 너무 작아서 키 룩업(lookup)을 실행하는 것보다 테이블 스캔을 하는 것이 더 빠르다. 일반적으로10개 미만의 짧
은 길이의 열을 가진 테이블이 여기에 해당한다.
● 인덱스가 된 컬럼에 대한 ON 또는 WHERE 구문에서는 유용하게 사용할 수 있는 제약이 존재하지 않는다.
● 여러분은 인덱스된 컬럼을 항수 값과 비교할 수 있고 MySQL은 테이블의 대부분을 커버하고 있는 항수를 계산하고 테이
블 스캔이 빠르게 진행되도록 만든다. Section 7.2.4, “WHERE 구문 최적화”를 참조할 것.
● 여러분은 다른 컬럼을 통해서 낮은 기수(cardinality)를 가지고 있는(많은 열이 키 값과 매치가 됨) 열을 사용할 수 있다.
이와 같은 경우, MySQL은 키 값을 사용함으로써 많은 키 룩업(lookup)이 진행이 되며 이에 따라서 테이블 스캔이 보다 빠
를 것이라고 가정을 한다.
작은 테이블의 경우, 테이블 스캔은 종종 a table scan often is appropriate and the performance impact is negligible. 대형 테
이블의 경우, 옵티마이저가 올바르지 않은 테이블 스캔을 선택하지 못하도록 하기 위해서는 아래의 기법을 따라서 시도해 본다:
● 스캔이 된 테이블에 대해서 키 배포를 업데이트 하기 위해서 ANALYZE TABLE tbl_name를 사용한다.
Section 13.5.2.1, “ANALYZE TABLE 신텍스”를 참조할 것.
● 주어진 인덱스를 사용하는 것 보다 테이블 스캔을 하는 것이 보다 비효율적이라고 MySQL에게 말하도록 하기 위해서, 스
캔이 된 테이블에 대해서 FORCE INDEX를 사용한다:
• SELECT * FROM t1, t2 FORCE INDEX (index_for_column)
• WHERE t1.col_name=t2.col_name;

:::MySQL Korea:::
Section 13.2.7, “SELECT 신텍스”를 참조할 것.
● 옵티마이저에게 어떠한 키 스캔도 1,000 개의 키 검색(key seek) 이상을 발생시키지 않는다고 가정하도록 만들기 위해서
는, mysqld을 --max-seeks-for-key=1000 옵션과 함께 시작하거나 또는 SET max_seeks_for_key=1000를 사용
한다. Section 5.2.2, “서버 시스템 변수”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.16. INSERT 명령문의 속도
7.2. SELECT 및 다른 명령문 최적화 하기 열을 삽입하는데 필요한 시간은 아래의 요소들을 가지고 판단할 수가 있는데, 여기에서 보여주는 숫자는 대략적인 수치이다:

● 연결: (3)
● 서버에 쿼리를 보내기: (2)
● 쿼리 파싱: (2)
● 열 삽입: (1 × size of row)
● 인덱스 삽입: (1 × number of indexes)
● 마침: (1)
여기에는 테이블을 처음에 열 때 발생하는 오버헤드는 고려하지 않았는데, 이것은 동시에 구동하는 각 쿼리에 대해서 한번씩 발생
을 한다.
여러분은 아래의 방법을 통해서 삽입 속도를 개선 시킬 수가 있다:
● 만일 여러분이 같은 클라이언트로부터 동시에 많은 수의 열을 가져와서 삽입하고자 한다면, INSERT 명령문을 다중

VALUES 리스트와 함께 사용한다. 이것을 사용하면 개별적인 단일-열 INSERT 명령문을 사용하는 것 보다 훨씬 속도의
개선을 가져올 수가 있다. 만일 비어 있지 않는 테이블에 데이터를 추가한다면, bulk_insert_buffer_size 변수를 튜닝해서
데이터 삽입의 속도를 개선시킬 수가 있다. Section 5.2.2, “서버 시스템 변수”를 참조할 것.
● 만일 여러분이 다른 클라이언트로부터 많은 열을 가져와서 삽입을 한다면, INSERT DELAYED 명령문을 사용함으로써 속
도의 개선을 얻을 수가 있을 것이다. Section 13.2.4.2, “INSERT DELAYED 신텍스”를 참조할 것.
● MyISAM 테이블의 경우, 테이블 중간에 삭제된 열이 없다면, SELECT 명령문이 구동되고 있을 때에 열을 추가할 수 있는
동시 삽입을 사용할 수 있게 된다. Section 7.3.3, “동시 삽입”을 참조.
● 텍스트 파일에서 테이블을 읽어 올 때(loading)에는, LOAD DATA INFILE을 사용한다. 이것은 INSERT 명령문을 사용
하는 것보다 20배 정도 속도가 빠르다. Section 13.2.5, “LOAD DATA INFILE 신텍스”를 참조할 것.

:::MySQL Korea:::
● 추가적인 작업으로는, 많은 수의 인덱스를 가지고 있는 MyISAM 테이블에 대해서 보다 빠른 LOAD DATA INFILE을 만
들 수가 있는데, 이렇게 하기 위해서는 아래의 과정을 따라 진행한다:
1. CREATE TABLE을 사용해서 선택적으로 테이블을 만든다.

2. FLUSH TABLES 명령문 또는 mysqladmin flush-tables 명령어를 실행한다.
3. myisamchk --keys-used=0 -rq /path/to/db/tbl_name를 사용한다. 이것은 테이블에 대한 모든 인덱
스 사용을 제거한다.
4. LOAD DATA INFILE을 사용해서 데이터를 테이블에 삽입시킨다. 이것은 어떠한 인덱스도 업데이트를 시
키지 않기 때문에 속도가 매우 빠르게 된다.
5. 만일 여러분이 나중에 테이블에서 데이터를 읽기만 할 생각이라면, 이것을 압축하기 위해서는 myisampack
를 사용한다. Section 14.1.3.3, “압축된 테이블의 특성”을 참조할 것.
6. myisamchk -rq /path/to/db/tbl_name를 사용해서 인덱스를 다시 생성 시킨다. 이것은 디스크에 기록을
하기 저에 메모리에 인덱스 트리를 먼저 생성을 하는데, 이렇게 하는 것이 LOAD DATA INFILE를 실행하는 동
안 인덱스를 업데이트하는 것을 보다 빠르게 만들게 되는데, 그 이유는 이것이 디스크 검색을 피하기 때문이다.
그 결과 인덱스 트리 또한 완벽하게 균형이 잡히게 된다.
7. FLUSH TABLES 명령문 또는 mysqladmin flush-tables 명령어를 실행한다.
여러분이 데이터를 삽입 시키는 MyISAM 테이블이 비어 있을 경우에는, LOAD DATA INFILE은 앞에서 설명하는 최적
화 동작을 자동으로 실행한다는 점을 알아두자.
여러분은 myisamchk을 사용하는 대신에 아래의 명령문을 사용해서 MyISAM 테이블에 대한 인덱스를 비활성화 또는 활
성화 시킬 수도 있다. 만일 이 명령문을 사용한다면, 여러분은 FLUSH TABLE 동작을 하지 않아도 된다:
ALTER TABLE tbl_name DISABLE KEYS;
ALTER TABLE tbl_name ENABLE KEYS;
● 비 트랜젝셔널 테이블에 대해서 다중 명령문과 함께 실행되는 INSERT 연산의 속도를 향상 시키기 위해서는, 여러분의 테
이블에 대해 잠금을 실행한다:
• LOCK TABLES a WRITE;
• INSERT INTO a VALUES (1,23),(2,34),(4,33);

:::MySQL Korea:::
• INSERT INTO a VALUES (8,26),(6,29);
• ...
• UNLOCK TABLES;
이렇게 함으로써 속도를 개선 시킬 수가 있는데, 그 이유는 인덱스 버퍼는 모든 INSERT 명령문이 실행이 완료된 후에 디
스크에 오직 한번만 플러시 되기 때문이다. 보통의 경우, INSERT 명령문의 개수만큼의 인덱스 버퍼 플러시가 생기게 된
다. 만일 여러분이 단일 INSERT 명령문만을 가지고 모든 열을 삽입할 수가 있다면, 명확한 잠금 명령문은 필요하지 않게
된다.
트랜젝셔널 테이블에 대해서, 보다 빠른 삽입 성능을 얻기 위해서는, LOCK TABLES를 사용하는 대신에, 여러분은
START TRANSACTION 와 COMMIT를 사용해야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.17. UPDATE 명령문의 속도
7.2. SELECT 및 다른 명령문 최적화 하기 업데이트 명령문은 추가적인 쓰기 동작의 오버 헤드를 가지고 있는 SELECT 쿼리와 유사하게 최적화가 이루어진다. 쓰기의 속도
는 업데이트가 되는 데이터의 양과 인덱스의 숫자에 따라 다르게 나타난다. 변경이 되지 않는 인덱스는 업데이트가 되지 않는다.
7.2.17 UPDATE 명령문의 속도
업데이트의 속도를 빠르게 만들 수 있는 다른 방법은 개별적인 업데이트는 지연을 시킨 후에 나중에 하나의 열에 대해서 업데이트
를 한꺼번에 실행하는 것이다. 여러분이 테이블을 잠가 놓았을 경우에는, 여러 개의 업데이트를 한꺼번에 실행하는 것이 한번에 하
나의 업데이트를 실행하는 것 보다 훨씬 빠른 속도를 나타낸다.
동적 열 포멧을 사용하고 있는 MyISAM 테이블의 경우, 열 전체에 대해서 업데이트를 실행할 경우에는 열이 나누어질 수도(split)
있다. 만일 이것을 자주 실행한다면, OPTIMIZE TABLE을 많이 사용하는 것이 중요하다. Section 13.5.2.5, “OPTIMIZE
TABLE 신텍스”를 참조할 것.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.18. DELETE 명령문의 속도
7.2. SELECT 및 다른 명령문 최적화 하기 개개의 열을 삭제하는데 필요한 시간은 인덱스의 숫자 비율과 정확히 일치한다. 열을 보다 빠르게 삭제를 하기 위해서는,
7.2.18 DELETE 명령문의 속도 key_buffer_size 시스템 변수를 증가 시켜서 키 캐시의 크기를 높이면 된다. Section 7.5.2, “서버 파라미터 튜닝하기”를 참조
할 것.
하나의 테이블에 있는 모든 열을 삭제하기 위해서는, TRUNCATE TABLE tbl_name를 사용하는 것이 DELETE FROM
tbl_name보다 빠를 것이다. Section 13.2.9, “TRUNCATE 신텍스”를 참조할 것.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.2.19. 다른 여러 가지의 최적화 팁(Tips)
7.2. SELECT 및 다른 명령문 최적화 하기 이 섹션에서는 쿼리의 처리 속도를 개선 시키기 위한 여러 가지의 최적화 팁에 대해서 설명을 하기로 한다:
7.2.19 다른 여러 가지의 최적화 팁(Tips)

● 접속에 따른 오버 헤드를 피하기 위해서는 영구적인 접속(persistent connection)을 하도록 한다. 만일 여러분이 영구 접
속을 할 수가 없고 데이터 베이스에 대한 새로운 많은 접속을 초기화 시키게 된다면, 아마도 여러분은 thread_cache_size
변수의 값을 변경하고자 할 것이다. Section 7.5.2, “서버 파라미터 튜닝하기”를 참조할 것.
● 여러분이 테이블에 생성해 둔 인덱스를 모든 쿼리가 실제로 사용하고 있는지 항상 검사를 한다. MySQL에서는,
EXPLAIN 명령문을 사용해서 이것을 검사할 수가 있게 된다. Section 7.2.1, “EXPLAIN를 사용해서 쿼리 최적화 시키
기”를 참조할 것.
● 데이터 리더(reader)와 라이터(writer)간의 테이블 잠금 문제를 피하기 위해서는, 업데이트가 자주 되는 MyISAM 테이블
에서는 복잡한 SELECT 쿼리 사용을 피하도록 한다.
● 테이블 중간에 삭제된 열이 없는 MyISAM 테이블을 사용한다면, 여러분은 다른 쿼리가 테이블에서 열을 읽을 때 동시에
테이블 끝에 열을 삽입할 수가 있다. 여러분이 테이블에서 많은 수의 열을 삭제한 후에는 테이블의 조각을 모으기 위해서
(defragment) OPTIMIZE TABLE를 구동 시킨다. Section 14.1, “MyISAM 스토리지 엔진”을 참조할 것.
● ARCHIVE 테이블과 함께 발생될 수 있는 압축 문제를 해결하기 위해서는, OPTIMIZE TABLE을 사용할 수가 있다.
Section 14.8, “ARCHIVE 스토리지 엔진”을 참조할 것.
● 여러분이 expr1, expr2, ... 순서로 열을 추출한다면, ALTER TABLE ... ORDER BY expr1, expr2, ...를 사용한다. 테이
블에 많은 변경을 실행한 후에 이 옵션을 사용한다면, 여러분은 매우 좋은 성능 향상을 얻을 수가 있을 것이다.
● 어떤 경우에는, 다른 컬럼 으로부터 얻은 정보를 기반으로 하는 “ 해쉬(hashed)” 컬럼을 사용하는 것이 좋을 때도 있다.
만일 이 컬럼이 매우 짧고 고유의 값을 가지고 있다면, 다른 많은 컬럼에 있는 “와이드(wide)” 컬럼보다 매우 빠르게 처
리가 된다. MySQL의 경우, 이러한 컬럼을 사용하는 것은 매우 쉽다:
• SELECT * FROM tbl_name

:::MySQL Korea:::
• WHERE hash_col=MD5(CONCAT(col1,col2))
• AND col1='constant' AND col2='constant';
● 자주 변경되는 MyISAM 테이블의 경우, 여러분은 모든 변수 길이 컬럼(variable-length column) (VARCHAR, BLOB,

및 TEXT)는 사용을 피하도록 해야 한다. 테이블은 변수 길이 컬럼을 하나만 가지고 있다고 하더라도 동적 열 포맷을 사용
하게 된다. Chapter 14, 스토리지 엔진과 테이블 타입을 참조할 것.
● 열이 매우 커진다는 이유만을 가지고 하나의 테이블을 여러 개의 다른 테이블로 분산(split)키시는 것은 보통의 경우에는
그리 좋은 방법이 아니다. 열에 접속을 하는데 있어서, 가장 최고의 성능 히트는(performance hit) 열의 처음 바이트를 찾
는데 필요한 디스크 검색이 된다. 데이터를 찾은 다음에는, 대부분의 현대의 디스크는 전체 열을 매우 빠르게 읽어 온다. 하
나의 테이블을 분산 시키는 것이 보다 유리한 경우는, 그 테이블이 고정 열 길이로 여러분이 변경 시킬 수가 있는 동적 열
포맷을 사용하는 MyISAM 테이블이거나, 또는 여러분이 대부분의 컬럼을 사용하지 않은 채로 테이블을 자주 스캔할 경우
뿐이다. Chapter 14, 스토리지 엔진과 테이블 타입.을 참조할 것
● 만일 여러분이 많은 수의 열에서 나오는 정보를 가지고서 행하는 카운트와 같이 자주 결과를 계산하고자 한다면, 새로운 테
이블을 생성하고 실제 시간으로 카운터를 업데이트 하는 것이 더 좋을 것이다. 아래의 폼과 같은 업데이트는 매우 빠르다:
• UPDATE tbl_name SET count_col=count_col+1 WHERE key_col=constant;
이것은 테이블-레벨 잠금(단일 라이터(writer)를 가지고 있는 다중의 리더(reader))만을 가지고 있는 MyISAM 테이블
과 같은 스토리지 엔진을 사용할 경우에는 매우 중요하다.
● 만일 여러분이 대형 로그 테이블에서 통계 값을 수집하고자 한다면, 전체 로그 테이블을 스캐닝 하지 말고 대신에 요약 테

이블을 사용한다
● 컬럼은 디폴트 값을 가지고 있다는 점을 잘 활용한다. 삽입되는 값이 디폴트와 다를 경우에만 명확하게 값을 삽입한다. 이
렇게 하면 MySQL이 반드시 해야 하는 파싱(parsing)을 줄일 수 있으며 삽입의 속도를 개선 시킬 수가 있다.
● 어떤 경우에는, BLOB 컬럼에 데이터를 패킹(pack) 및 저장하는 것이 보다 효과적일 때가 있다. 이럴 경우에는, 여러분은
패킹 및 언 패킹 정보를 어플리케이션에 제공해 주어야 하지만, 이렇게 해 줌으로써 몇몇 단계에서의 접근 시간을 매우 효
율적으로 절감 시킬 수가 있게 된다.
● 수토어드 루틴 또는 UDFs (user-defined functions)는 보다 우수한 성능을 얻는데 좋은 방법이 된다. Chapter 17, 스토
어드 프로시저와 함수, 및 Section 24.2, “MySQL에 새로운 함수 추가 하기”를 참조할 것.
● 데이터가 언제 쓰여질지에 대해 알고 싶지 않을 경우에는 INSERT DELAYED를 사용한다. 이렇게 하면 전반적인 삽입 시

:::MySQL Korea:::
간을 줄일 수가 있는데, 그 이유는 한번의 디스크 쓰기를 사용해서 많은 수의 열을 쓸 수 있기 때문이다.

● 삽입 동작보다 SELECT 명령문에 앞선 우선 순위를 주고자 한다면, INSERT LOW_PRIORITY를 사용한다.
● 큐에 직접 들어가는 복원을 하고자 한다면 SELECT HIGH_PRIORITY를 사용한다. 즉, 쓰기를 대기하고 있는 다른 클라이
언트가 있다고 하더라도 SELECT가 실행이 된다.
● 하나의 SQL 명령문을 사용해서 많은 수의 열을 저장하기 위해서는 다중-열 INSERT 명령문을 사용하도록 한다. MySQL
을 포함해서 대부분의 SQL 서버가 이것을 지원한다.
● 대량의 데이터를 읽어 오기 위해서는 LOAD DATA INFILE를 사용한다. 이것은 INSERT 명령문을 사용하는 것 보다 훨
씬 빠르다.
● 고유의 값을 얻기 위해서는 AUTO_INCREMENT 컬럼을 사용한다.
● 동적-포맷MyISAM 테이블을 사용해서 테이블의 조각(fragmentation)을 피하기 위해서는 OPTIMIZE TABLE를 한번
사용한다. Section 14.1.3, “MyISAM 테이블 스토리지 포맷”을 참조할 것.
● MEMORY (HEAP) 테이블을 사용해서 보다 빠른 속도를 얻고자 시도한다. Section 14.4, “MEMORY (HEAP) 스토리
지 엔진”을 참조할 것. MEMORY 테이블은 중요하지 않은 데이터 이면서 자주 엑세스가 되는 것에 대해서 매우 유용한 형
태인데, 예를 들면 가장 최근에 표시된 배너 광고와 같은 정보를 가질 수가 있다.
● 웹 서버와 함께 사용된다면, 이미지 및 다른 바이너리 자산은 보통 파일 형태로 저장되어야 한다. 즉, 데이터 베이스에 파
일 자체를 저장하는 대신에 파일에 대한 참조만을 저장하도록 한다. 대부분의 웹 서버는 데이터 베이스 컨텐츠가 아닌 파
일 캐싱을 선호하며, 따라서 파일을 사용하는 것이 보다 빠르다.
● 서로 다른 테이블에서 독립적인 정보를(identical information)을 가지고 있는 컬럼은 서로 별개의 데이터 타입으로 선언
되어야 한다.
● 컬럼의 이름은 단순하게 만들도록 한다. 예를 들면, customer라는 이름의 테이블에서는, customer_name라는 이름 보다
는 name를 사용한다. 여러분이 사용하는 이름이 다른 SQL 서버에서도 사용될 수 있도록 하기 위해서는, 18 문자 길이 이
내로 이름을 지어야 한다.
● 만일 여러분이 정말로 고 성능을 원할 경우에는, 서로 다른 SQL 서버가 지원하는 낮은 수준의 인터 페이스(low-level
interface)를 사용해야 한다. 예를 들면, MySQL MyISAM 스토리지 엔진을 직접 접속하면, 여러분은 SQL 인터 페이스를
사용하는 것에 비해서 2에서 5배의 성능 개선을 얻을 수가 있게 된다. 이렇게 하기 위해서는, 데이터는 반드시 동일한 어플
리케이션 서버에 존재해야 하며, 보통의 경우 한번의 프로세스를 통해서 접속 가능해야 한다.
● 만일 여러분이 숫자 데이터를 사용한다면, 대부분의 경우에는 텍스트 파일 데이터를 접속하는 것 보다 빠르게 된다.
● 리플리케이션을 사용해서 성능 개선을 가지는 경우도 있다. 여러분은 업무(load)를 분산시키기 위해서 리플리케이션 서버
간에 클라이언트 복원을 분산 시킬 수가 있다. 마스터가 백업을 진행하는 동안 느려지는 것을 막기 위해서는, 백업을 슬레
이브 서버에서 진행할 수도 있다. Chapter 6, 리플리케이션을 참조할 것.
● MyISAM 테이블을 DELAY_KEY_WRITE=1 테이블 옵션과 함께 선언하면 인덱스 업데이트의 속도를 향상 시킬 수가 있

:::MySQL Korea:::
는데, 그 이유는 테이블이 닫힐 때까지 인덱스들은 디스크에 플러시 되지 않기 때문이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.3. 잠금 이슈
7. 최적화(Optimization) 7.3.1. 잠금 방법
7.3. 잠금 이슈 7.3.2. Table 잠금 이
7.3 잠금 이슈 슈
7.3.1 잠금 방법 7.3.3. 동시 삽입
7.3.2 테이블 잠금 이슈
7.3.3 동시 삽입
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.3.1. 잠금 방법
7.3. 잠금 이슈 MySQL은 MyISAM 및 MEMORY 테이블에 대해서는 테이블 레벨 잠금을 사용하며 BDB 테이블에 대해서는 페이지 레벨의 잠금
7.3.1 잠금 방법 을, 그리고 InnoDB 테이블에 대해서는 열 레벨의 잠금을 사용한다.
많은 경우에, 여러분은 어떤 어플리케이션에 대해 가장 최선의 잠금 방식을 경험적으로 선택할 수 있으나, 주어진 잠금 방식이 다
른 타입에 비해 우수하다고 단정짓는 것은 매우 어렵다. 사용하는 어플리케이션에 따라서 서로 다른 잠금 방식을 사용할 수 있다.
스토리지 엔진을 열 레벨 잠금과 함께 사용하기 위해서는, 여러분이 사용하는 어플리케이션 및 이것이 사용하는 선택 및 업데이트
가 어떤 것들이 있는지를 잘 살펴 보아야 한다. 예를 들면, 대부분의 웹 어플리케이션들은 많은 선택은 하지만, 상대적으로 적은 삭
제를 하며, 업데이트는 주로 키 값을 기반으로 실행하고, 열 삽입은 몇몇 특정 테이블에 대해서만 실행을 한다. MySQL MyISAM
설정은 이런 용도에 잘 들어 맞게 튜닝된 것이다.
MySQL에서의 테이블 잠금은 테이블 레벨 잠금을 사용하는 스토리지 엔진에 대해서는 데드락-프리(deadlock-free)가 된다. 쿼
리를 시작할 때 항상 모든 필요한 잠금을 한번에 요청하고 항상 동일한 순서로 테이블을 잠금으로써 데드락 없앰(Deadlock
avoidance)을 제어할 수가 있게 된다.
WRITE 잠금을 위해 MySQL이 사용하는 테이블 잠금 방식은 아래와 같다:
● 테이블에 아무런 잠금도 존재하지 않으면, 테이블에 쓰기 잠금을 추가한다.

● 그렇지 않으면, 쓰기 자금 큐에 잠금 요청을 넣어 둔다.
READ 잠금 동작을 위한 테이블 잠금 방식은 다음과 같다:
● 테이블에 쓰기 잠금이 존재하지 않으면, 읽기 잠금을 테이블에 추가한다.

● 그렇지 않으면, 일기 잠금 큐에 잠금 요청을 넣어 둔다.

:::MySQL Korea:::
잠금이 해제가 되면, 그 잠금은 쓰기 잠금 큐에 있는 쓰레드가 사용할 수 있도록 되며 그 다음에는 읽기 잠금 큐에 있는 쓰레드가 사

용할 수 있도록 되어 진다. 이것은 만일 여러분이 테이블에 대해서 많은 업데이트를 했다면, SELECT 명령문은 더 이상의 업데이
트가 생기기 않을 때까지 기다리게 된다는 것을 의미하는 것이다.
여러분은 Table_locks_waited 및 Table_locks_immediate 상태 변수를 검사함으로써 시스템 상의 테이블 잠금 경쟁을 분석할 수

가 있다:
mysql> SHOW STATUS LIKE 'Table%';
+-----------------------+---------+
+-----------------------+---------+
| Table_locks_immediate | 1151552 |
| Table_locks_waited | 15324 |
+-----------------------+---------+
만일 MyISAM 테이블이 중간에 어떠한 자유 블록(free block)도 가지고 있지 않다면, 열 삽입은 항상 데이터 파일의 맨 마지막에
이루어진다. 이와 같은 경우, 여러분은 자유롭게 INSERT 및 SELECT 명령문을 동시에 잠금 없이 MyISAM 테이블 용으로 사용
할 수 있다. 즉, 여러분은 다른 클라이언트가 MyISAM 테이블을 읽는 동안에도 이 테이블 안에 열을 삽입할 수가 있다는 것이다.
만일 여러분이 동시 삽입이 불 가능한 경우에도 많은 수의 INSERT 및 SELECT 동작을 한 테이블에서 실행하고자 한다면, 여러분
은 임시 테이블에 열을 삽입하고 나중에 이 임시 파일에 있는 열을 가지고 실제 테이블을 업데이트 하면 된다. 이것은 아래의 코드
를 가지고 실행하면 된다:
mysql> LOCK TABLES real_table WRITE, insert_table WRITE;

:::MySQL Korea:::
mysql> INSERT INTO real_table SELECT * FROM insert_table;
mysql> TRUNCATE TABLE insert_table;
mysql> UNLOCK TABLES;
InnoDB는 열 레벨의 잠금을 사용하고 BDB는 페이지 레벨의 잠금을 사용한다. 이 두 가지 스토리지 엔진의 경우, 데드락이 발생할
가능성이 있는데, 그 이유는 이 엔진들은 트랜젝션이 시작되는 시점이 아닌SQL 명령문을 실행하는 동안 자동으로 잠금을 얻어내
기 때문이다.
열 레벨 잠금의 장점으로는 다음과 같은 것이 있다:
● 많은 쓰레드에 있는 서로 다른 열을 가져올 때 충돌이 거의 일어나지 않음.

● 롤백(rollback)에 대한 변경이 거의 없음.
● 오랜 시간 동안 하나의 열에 대한 잠금이 가능함.
열 잠금의 단점은 다음과 같다:
● 페이지 레벨 또는 테이블 레벨의 잠금 보다 더 많은 메모리가 필요함.

● 테이블 대부분에서 이 잠금을 사용하게 되면 보다 많은 수의 잠금이 이루어지기 때문에, 페이지 레벨 또는 테이블 레벨의
잠금에 비해 속도가 느려지게 된다.
● 데이터의 대부분에 대해서 GROUP BY 동작을 자주 사용하거나 또는 테이블 전체에 대한 스캔을 자주 실행해야 하는 경우
에는 다른 두 가지의 잠금보다 현격한 성능 저하가 생긴다.
아래의 경우에는, 테이블 잠금이 나머지 두 개의 잠금 방식보다 훨씬 성능이 좋게 된다:
● 테이블에 대한 대부분의 명령문이 읽기 이다.

● 일기 및 쓰기가 혼재되어 있으며, 이때 쓰기는 업데이트 또는 하나의 키 읽기와 함께 패치(fetch)될 수 있는 단일 열에 대
한 삭제이다:
• UPDATE tbl_name SET column=value WHERE unique_key_col=key_value;

:::MySQL Korea:::
• DELETE FROM tbl_name WHERE unique_key_col=key_value;
● SELECT은 INSERT 명령문과 동시에 연결이 되어 있고, UPDATE 또는 DELETE 명령문과는 거의 연결이 되어 있지 않
다.
● 어떠한 라이터(writer)도 없이 많은 수의 스캔 또는 GROUP BY 동작이 전체 테이블에서 이루어진다.
보다 고-레벨(higher-level)의 잠금을 사용하면, 여러분은 서로 다른 형태의 잠금을 지원함으로써 어플리케이션을 보다 쉽게 튜

닝할 수 있게 되는데, 그 이유는 잠금 오버 헤드가 낮은 레벨(lower-level) 잠금보다 덜 생기기 때문이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.3.2. 테이블 잠금 이슈
7.3. 잠금 이슈 매우 빠른 잠금 속도를 얻기 위해서, MySQL은 InnoDB 및 BDB를 제외한 모든 스토리지 엔진에 대해서는 테이블 잠금을 사용한
7.3.2 테이블 잠금 이슈 다.
InnoDB 및 BDB 테이블에 대해서는, MySQL은 여러분이 LOCK TABLES를 가지고 명확하게 테이블을 잠그는 경우에만 테이블
잠금을 사용한다. 이러한 스토리지 엔진에 대해서는, 우리는 여러분이 LOCK TABLES를 사용하지 말 것을 권장하는데, 그 이유
는 페이지 트랜젝션 분리(isolation)를 위해서 InnoDB은 자동 열 레벨 잠금을 그리고 BDB 는 자동 레벨 잠금을 사용하기 때문이
다.
대형 테이블의 경우, 대부분의 어플리케이션에 대해서는 열 잠금 보다는 테이블 잠금이 보다 좋기는 하지만, 아래와 같이 몇 가지
의 예외적인 경우가 존재한다:
● 테이블 잠금은 많은 수의 쓰레드가 하나의 테이블에서 동시에 읽기를 실행할 수 있도록 해 주지만, 만일 하나의 쓰레드가
테이블에 쓰기를 하고자 한다면, 그 쓰레드는 테이블에 대해서 완벽한 접속(exclusive access)를 우선 가져야만 한다. 업
데이트를 하는 동안에는, 모든 다른 쓰레드는 업데이트가 끝날 때까지 대기를 해야만 한다.
● 일반적인 경우, 테이블 업데이트는 테이블 복원 보다 더 중요하게 고려되는데, 따라서 이것이 우선 순위가 높게 매겨진다.
이것은 테이블에 대해서 많은 양의(heavy) SELECT 실행이 있다고 하더라도 테이블에 대한 업데이트는 “굶음
(starved)”이 되지 말아야 한다는 것을 의미한다.
● 테이블 잠금은 디스크가 꽉 차서 쓰레드를 진행 시키기 전에 여유 공간이 필요하기 때문에 쓰레드가 대기를 해야 하는 경우
에는 문제의 원인이 되기도 한다. 이와 같은 경우, 문제 테이블에 접속을 하고자 하는 모든 쓰레드는 사용 가능한 디스크 공
간이 생길 때 까지 대기 상태가 되어 버린다.
테이블 잠금은 아래와 같은 시나리오 아래에서도 단점을 가지게 된다:
● SELECT명령문을 어떤 클라이언트가 요청 한다.

:::MySQL Korea:::
● 그런 후에 다른 클라이언트 하나가 동일한 테이블에서 UPDATE를 실행한다. 이 클라이언트는 SELECT가 끝날 때까지 대

기를 한다.
● 또 다른 클라이언트 하나가 동일한 테이블에서 별도의 SELECT 명령문을 입력한다. UPDATE 는 SELECT 보다 우선 순
위가 높기 때문에, 이 SELECT 명령문은 UPDATE가 마칠 때까지, 그리고 처음의 SELECT가 끝날 때까지 대기를 한다.
아래의 사항들은 테이블 잠금에 의해 야기되는 경쟁 상황을 피하거나 또는 절감 시킬 수 있는 여러 가지 방법을 설명해 주는 것들이
다:
● 짧은 시간 동안만 테이블을 잠그도록 하기 위해 SELECT 명령문이 빠르게 구동되도록 만든다. 이렇게 하기 위해서는 요
약 테이블을 생성해야 할 것이다.
● Mysqld을 --low-priority-updates와 함께 시작한다. 이것은 테이블을 업데이트(수정)하는 모든 명령문에 대해서
SELECT 명령문 보다 낮은 우선 순위를 할당해 준다. 이렇게 하면, 앞의 시나리오에서 나오는 두 번째 SELECT 명령문은
UPDATE 명령문 보다 먼저 실행이 되며, 처음의 SELECT가 끝날 때까지 대기를 할 필요가 없게 된다.
● SET LOW_PRIORITY_UPDATES=1 명령문을 사용하면, 특정 접속에서 입력된 모든 업데이트에 대해서는 낮은 우선 순
위를 가지도록 지정할 수 있게 된다. Section 13.5.3, “SET 신텍스”를 참조.
● LOW_PRIORITY 속성을 사용해서 특정 INSERT, UPDATE, 또는 DELETE 명령문이 낮은 우선 순위를 가지도록 할 수
있다.
● HIGH_PRIORITY 속성을 사용하면 특정 SELECT 명령문이 높은 우선 순위를 가지도록 만들 수가 있다. Section 13.2.7,
“SELECT 신텍스”를 참조.
● mysqld이 max_write_lock_count 시스템 변수에 대해서 낮은 우선 순위를 가지고 시작을 하도록 해서 MySQL로 하여금
특정 수의 열 삽입이 이루어진 테이블을 기다리는 모든 SELECT 명령문의 우선 순위를 임시적으로 높일 수 있도록 만들
수가 있다. 특정 수의 WRITE 잠금을 실행한 후에 READ 잠금을 허용한다..
● 만일 여러분이 SELECT와 연결되어 있는 INSERT에 문제를 가지고 있다면, MyISAM 테이블 변환(switching)을 고려해
볼만 한데, 이것은 동시 SELECT 및 INSERT 명령문을 지원한다. (Section 7.3.3, “동시 삽입”을 참조.)
● 만일 여러분이 동일한 테이블에서 삽입과 삭제를 혼용해서 사용한다면, INSERT DELAYED 가 매우 큰 도움을 줄 것이
다. Section 13.2.4.2, “INSERT DELAYED 신텍스”를 참조.
● 만일 SELECT 및 DELETE 명령문 혼용에 있어서 어떠한 문제가 발생한다면, DELETE에 대한 LIMIT 옵션이 도움이 될
것이다. Section 13.2.1, “DELETE 신텍스”를 참조할 것.
● SQL_BUFFER_RESULT를 SELECT 명령문과 함께 사용하는 것이 테이블 잠금 기간을 줄이는데 도움이 될 것이다.
Section 13.2.7, “SELECT 신텍스”를 참조할 것.
● 여러분은 mysys/thr_lock.c에 있는 잠금 코드를 변경 시키면 단일 큐를 사용할 수 있게 된다. 이렇게 하면, 쓰기 잠금 및

:::MySQL Korea:::
읽기 잠금은 동일한 우선 순위를 가지게 되며, 몇몇 어플리케이션 실행에 도움이 되기도 한다.
아래의 내용은 MySQL에서 테이블 잠금에 대해 고려해야 할 몇 가지 팁 들을 나열한 것이다:
● 동시 사용자의 수는 여러분이 동일한 테이블에서 많은 수의 열을 조사할 필요가 있는 선택을 업데이트와 함께 사용하지 않

으면 아무런 문제가 되지 않는다.
● 여러분은 LOCK TABLES를 사용해서 속도를 개선 시킬 수가 있는데, 그 이유는 단일 잠금 내에 있는 많은 업데이트는 잠
금이 없는 업데이트 보다 속도가 빠르기 때문이다. 한 테이블의 내용을 여러 개의 테이블에 분산 시키는 것도 도움이 된다.
● 만일 여러분이 MySQL의 테이블 잠금과 함께 성능상의 문제를 만나게 되면, 여러분이 사용하고 있는 테이블을 InnoDB 또
는 BDB 테이블로 전환해서 성능을 개선하도록 시도해 본다. Section 14.2, “InnoDB 스토리지 엔진”, 그리고
Section 14.5, “BDB (BerkeleyDB) 스토리지 엔진”을 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.3.3. 동시 삽입
7.3. 잠금 이슈 MyISAM 테이블의 경우, 테이블 중간에 삭제된 열이 없다면, 여러분은 SELECT 명령문이 구동 중에 있는 동안에도 열을 추가하
7.3.3 동시 삽입 기 위한 동시 삽입을 사용할 수가 있게 된다.
동시 삽입이 사용될 수 있는 환경 아래에서는, INSERT 명령문에 대해서는 DELAYED 수정자(modifier)를 사용할 필요가 거의
없게 된다. Section 13.2.4.2, “INSERT DELAYED 신텍스”를 참조할 것.
만일 여러분이 바이너리로그를 사용하고 있다면, 동시 삽입은 CREATE ... SELECT 또는 INSERT ... SELECT 명령문에 대해서
는 정상 삽입(normal insert)로 변환 된다. 이것은 백업 동작이 진행되는 동안 로그를 적용 시킴으로써 여러분이 테이블의 정확한
복사본을 재 생성할 수 있게 끔 해 준다.
만일 여러분이 동시 삽입 조건을 만족 시키는MyISAM 테이블과 함께CONCURRENT를 지정한다면(즉, 테이블 중간에 아무런 프

리 블록(free block)도 없는 경우), LOAD DATA INFILE를 사용함으로써, LOAD DATA가 실행되는 동안에 다른 쓰레드가 테이
블에서 데이터를 추출할 수 있도록 해 준다. 이 옵션을 사용하면 LOAD DATA의 성능에 다소 영향을 줄 수가 있는데, 비록 다른 쓰
레드가 동시에 테이블을 사용하는 경우에도 가능하게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4. 데이터 베이스 구조 최적화 하기
7. 최적화(Optimization) 7.4.1. 디자인 선택

7.4. 데이터 베이스 구조 최적화 하기 7.4.2. 데이터를 가능한 한 작게 만들기
7.4 데이터 베이스 구조 최적화 하기 7.4.3. 컬럼 인덱스
7.4.1 디자인 선택 7.4.4. 다중-컬럼 인덱스
7.4.2 데이터를 가능한 한 작게 만들기 7.4.5. MySQL의 인덱스 사용 방법

7.4.6. MyISAM 키 캐시
7.4.3 컬럼 인덱스
7.4.7. MyISAM 인덱스 통계 수집
7.4.4 다중-컬럼 인덱스
7.4.8. MySQL의 테이블 열기 및 닫기 방법
7.4.5 MySQL의 인덱스 사용 방법
7.4.9. 동일 데이터 베이스에 많은 테이블을 생성하기 위해 드로우 백(drawback) 하기
7.4.6.1 공유 키 캐시 접속
7.4.6.2 다중 키 캐시
7.4.6.3 중간 삽입(Midpoint Insertion) 전략
7.4.6.4 인덱스 프리 로딩(Preloading)
7.4.6.5 키 캐시 블럭 크기
7.4.9 동일 데이터 베이스에 많은 테이블을 생성하기 위해 드로우 백(drawback) 하
기
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.1. 디자인 선택
7.4. 데이터 베이스 구조 최적화 하기 MySQL은 열 데이터와 인덱스 데이터를 서로 별도의 파일에서 관리한다. 거의 대부분의 다른 데이터 베이스 시스템은 열 데이터
7.4.1 디자인 선택 와 인덱스 데이터를 동일 파일에서 같이 관리를 하고 있다. 우리는 MySQL이 선택한 방식에 현대적인 시스템에 보다 잘 맞는 것이
라고 생각을 하고 있다.
열 데이터를 저장하는 다른 방법은 각 컬럼의 정보를 별도의 구역(area)에 두는 것이다(예를 들면 SDBM 및 Focus). 이렇게 하면
모든 쿼리가 한번 이상 컬럼을 접속해야 하기 때문에 성능의 이슈가 발생한다. 이런 방식은 범용 데이터 베이스에는 그다지 좋은 방
식이 아니라고 생각을 한다.
보다 일반적인 방식은 인덱스와 데이터를 같이 저장하는 것이다. (오라클/ 사이베이스 등등이 이 방식을 사용한다). 이럴 경우, 여
러분은 열에 대한 정보를 인덱스의 리프 페이지(leaf page)에서 찾아 볼 수가 있게 된다. 이런 레이 아웃의 장점으로는, 인덱스가
얼마나 잘 캐시되어 있는지에 따라서, 디스크의 공간을 절약 시켜 준다는 것이다. 이 레이 아웃이 갖는 단점은 다음과 같다:
● 데이터를 가져 오기 위해서는 인덱스 전체를 읽어야 하기 때문에 테이블 스캔의 속도가 느려지게 된다.
● 인덱스 테이블만을 사용해서는 쿼리용 데이터를 추출할 수가 없게 된다.
● 노드에 인덱스를 중복 저장(duplicate)해야 하기 때문에 보다 많은 디스크 공간이 필요하게 된다 (열을 노드에 저장할 수
가 없다).
● 삭제 동작으로 인한 테이블 오버 타임(over time)이 발생한다 (노드에 있는 인덱스는 보통의 경우 삭제 중에는 업데이트
가 되지 않기 때문임).
● 인덱스 데이터만을 캐시하는 것이 보다 어렵다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.2. 데이터를 가능한 한 작게 만들기
7.4. 데이터 베이스 구조 최적화 하기 가장 기본적인 최적화 컴퍼넌트 중의 하나는 가능한 한 디스크의 공간을 작게 가지도록 테이블을 디자인 하는 것이다. 이렇게 함으
7.4.2 데이터를 가능한 한 작게 만들기 로써 디스크 읽기의 속도를 개선 시킬 수 있으며, 따라서 테이블이 작을수록 쿼리를 실행하는 동안 실제로 처리되는 컨텐츠가 메인
메모리를 적게 차지하게 된다. 인덱싱 또한 보다 작은 컬럼상에서 이루어 진다면 자원을 덜 차지하게 된다.
MySQL은 여러 가지의 스토리지 엔진(테이블 타입)과 열 포맷을 지원한다. 각각의 테이블에 대해서는, 어떤 스토리지 엔진과 인덱
싱 방식을 사용할 지를 여러분이 결정할 수가 있다. 여러분의 어플리케이션에 맞는 테이블 포맷을 잘 선택하는 것이 성능 향상에 커
다란 도움을 줄 것이다. Chapter 14, 스토리지 엔진과 테이블 타입 을 참조할 것.
여러분은 아래에 열거된 기법을 활용해서 최적의 테이블 타입 및 최소한의 스토리지 공간을 만들어 낼 수 있을 것이다:
● 가능한 한 최적의(가장 작은) 데이터 타입을 사용한다. MySQL에는 디스크 공간 민 메모리를 절약 시켜 주는 다양한 타입
들이 존재 한다. 예를 들면, 보다 작은 테이블을 가지기 위해서는 가능하면 정수 타입을 사용한다. MEDIUMINT이 INT 보
다는 종종 좀더 좋은 선택이 될 수 있는데, 그 이유는 MEDIUMINT 컬럼이 25% 정도 덜 공간을 차지하기 때문이다.
● 가능하다면 컬럼을 NOT NULL로 선언한다. 이렇게 하면 모든 것들이 빨라지고 컬럼 당 1 바이트의 공간을 절약 시킬 수
가 있다. 만일 어플리케이션에서 반드시 NULL을 사용해야 하는 경우라면, 그렇게 하도록 해야 하지만, 단지 모든 컬럼의
디폴트로는 사용하지 말기 바란다.
● MyISAM 테이블의 경우, 여러분이 변수 길이 컬럼(variable-length column) (VARCHAR, TEXT, 또는 BLOB 컬럼)을
가지고 있지 않다면, 고정 크기 열 포맷이 사용된다. 이런 형태는 속도는 빠르겠지만 불행하게도 공간은 더 차지하게 된다.
Section 14.1.3, “MyISAM 테이블 스토리지 엔진 포맷”을 참조할 것. 이런 사항으로 인해, 여러분은 VARCHAR 컬럼
을 CREATE TABLE 옵션 ROW_FORMAT=FIXED와 함께 가지고 있다고 하더라도 고정 길이 열을 가지는 것이 나을 것

:::MySQL Korea:::
이라는 생각을 가질 것이다.

● MySQL 5.0.3 이후에는, InnoDB 테이블은 보다 간단한(compact) 스토리지 엔진 포맷을 사용하고 있다. MySQL의 초기
버전에서는, InnoDB의 열은 여분의 정보(redundant information)를 가지고 있었는데, 컬럼의 숫자와 각 컬럼의 길이뿐
만 아니라 고정 길이 컬럼에 대한 정보 까지고 가지고 있었다. 디폴트로는, 테이블은 콤팩트 포맷인
(ROW_FORMAT=COMPACT)로 생성이 된다. 만약에 여러분이 이전 버전의 MySQL로 다운 그레이드 하고자 한다면,
이 포맷을 이전의 구형 포맷인 ROW_FORMAT=REDUNDANT로 요청해야 한다.
콤팩트(compact) InnoDB 포맷은 UTF-8 데이터를 가지고 있는 CHAR 컬럼의 저장 방법도 변경 시켰다.
ROW_FORMAT=REDUNDANT 포맷의 경우, UTF-8 CHAR(N)는 3 × N 바이트로 구성 되었는데, UTF-8 의 엔코
딩된 문자의 최대 길이는 3 바이트로 주어졌다. 대부분의 언어는 주로 단일 바이트 UTF-8 문자로 쓰여질 수 있기 때문
에, 고정 스토리지 길이는 종종 공간을 허비 했다. ROW_FORMAT=COMPACT 포맷을 사용하는 경우에는, InnoDB는
변수를 N 에서 3 × N 바이트의 범위 내에서 할당을 해 준다.
● 테이블의 주 인덱스(primary index)는 가능한 한 작게 만든다. 이렇게 하면 각각의 열의 특성(identification)을 쉽고 효율

적으로 만들 수가 있게 된다.
● 실제로 필요한 경우에만 인덱스를 만든다. 인덱스는 데이터를 추출할 때에는 좋지만 데이터를 빠르게 저장할 때에는 좋지
가 않게 된다. 만일 주로 컬럼 조합의 검색을 가지고 테이블을 접속한다면, 이러한 조합의 인덱스를 별도로 만든다. 이러한
인덱스의 첫 부분은 가장 자주 사용되는 컬럼이 되어야 한다. 만일 여러분이 테이블에서 선택(select)를 할 때 항상 많은
수의 컬럼을 사용한다면, 인덱스를 보다 효과적으로 압축한 컬럼 복사본을 사용하도록 한다.
● 만일 스트링 컬럼이 문자의 첫 번째 숫자에 고유의 접두사(unique prefix)를 가지고 있는 경우라면, 이 접두사만을 인덱스
하는 것이 바람직하다 (Section 13.1.4, “CREATE INDEX 신텍스”를 참조). 보다 작은 인덱스가 보다 빠른 동작을 구
현하는데, 그 이유는 디스크 공간을 덜 필요로 하기 때문일 뿐만 아니라, 인덱스 캐시의 일치(hit) 비율이 더 높기 때문에 디
스크 검색을 덜 하기 때문이다. Section 7.5.2, “서버 파라미터 튜닝하기”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.3. 컬럼 인덱스
7.4. 데이터 베이스 구조 최적화 하기 모든 MySQL 데이터 타입은 인덱스화 될 수 있다. 상호 연관된 컬럼상에서 인덱스 사용은 SELECT 연산의 성능을 향상시키기 위
7.4.3 컬럼 인덱스 한 최선의 방법이다.
테이블 당 최대 인덱스 숫자 및 최대 인덱스 길이는 스토리지 엔진별로 정의 된다. Chapter 14, 스토리지 엔진과 테이블 타입을 참
조할 것. 모든 스토리지 엔진은 테이블 당 최소 16개의 인덱스와 최소 256 바이트의 인덱스 길이를 지원한다.
인덱스 정의문에서 col_name(N)를 사용하면, 여러분은 스트링 컬럼에서 첫 번째 문자가 N인 것만을 인덱스할 수가 있다. 이러한
방식으로 컬럼 값의 접두사만을 인덱싱하면 인덱스 파일을 보다 작게 만들 수가 있다. 여러분이 BLOB 또는 TEXT 컬럼을 인덱스
할 때에는, 반드시 인덱스의 접두사(prefix) 길이를 지정해 주어야 한다. 예를 들면:
CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));
접두사(Prefixes)는 1000 바이트 길이까지 사용할 수가 있다 (InnoDB 테이블에 대해서는 767 바이트까지). 접두사의 길이 제한
은 바이트 단위이며, 반면에 CREATE TABLE 명령문에 있는 접두사의 길이는 문자의 숫자로 변환된다는 점을 알아 두자. 다중 바
이트 문자 셋을 사용하는 컬럼에 대한 접두사 길이를 지정할 때에는 이점을 명심한다.
여러분은 FULLTEXT 인덱스도 생성할 수가 있다. 이것은 전체 문장(full-text) 검색을 위해 사용된다. MyISAM 스토리지 엔진
만이 FULLTEXT 인덱스를 지원하며 CHAR, VARCHAR, 그리고 TEXT 컬럼에 대해서만 지원을 한다. 인덱싱은 항상 전체 컬럼

:::MySQL Korea:::
에서 이루어지며 부분적인 인덱싱은 지원되지 않는다. 자세한 사항은 Section 12.7, “전체-문장 검색(Full-Text Search) 함
수”를 참조할 것.
여러분은 또한 공간(spatial)데이터 타입에서도 인덱스를 만들 수가 있다. 현재까지는, MyISAM만이 공간 타입에서의 R-트리

(tree) 인덱스를 지원하고 있다. MySQL 5.0.16 까지는, 다른 스토리지 엔진은 공간 타입의 인덱싱을 위해서는 B-트리(tree)를
사용하고 있다 (ARCHIVE 및 NDBCLUSTER는 예외인데, 이것들은 공간 타입 인덱싱을 지원하지 않는다).
MEMORY 스토리지 엔진은 디폴트로 HASH 인덱스를 사용하지만, BTREE 인덱스도 지원을 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.4. 다중-컬럼 인덱스
7.4. 데이터 베이스 구조 최적화 하기 MySQL은 복합(composite) 인덱스를 만들 수가 있다 (즉, 다중 컬럼상의 인덱스). 하나의 인덱스는 최대 15개의 컬럼으로 구성
7.4.4 다중-컬럼 인덱스 될 수 있다. 특정 데이터 타입의 경우,여러분은 컬럼의 접두사를 인덱스할 수 있다 (see Section 7.4.3, “컬럼 인덱스”를 참조).
다중-컬럼 인덱스는 인덱스가 된 컬럼 값의 연쇄 연결로 만들어진 값을 가지고 있는 정렬된 어레이(sorted array)로 간주된다.
MySQL은 WHERE 구문에 있는 인덱스의 첫 번째 컬럼에 대해 비록 여러분이 다른 컬럼의 값은 지정하지 않았다고 하더라도, 여
러분이 알려진 양을 지정할 때 쿼리가 빨리 처리할 수 있도록 다중-컬럼 인덱스를 사용한다.
테이블이 아래와 같은 형태로 되어 있다고 가정하자:
CREATE TABLE test (
id INT NOT NULL,
last_name CHAR(30) NOT NULL,
first_name CHAR(30) NOT NULL,
PRIMARY KEY (id),

:::MySQL Korea:::
INDEX name (last_name,first_name)
);
name 인덱스는 last_name 과 first_name 컬럼 전반에 대한 인덱스이다. 이 인덱스는 last_name, 또는 last_name 과 first_name
모두의 알려진 범위에 있는 값을 지정하는 쿼리를 위해 사용된다. 따라서 name 인덱스는 아래의 쿼리에서 사용된다:
SELECT * FROM test WHERE last_name='Widenius';
SELECT * FROM test
WHERE last_name='Widenius' AND first_name='Michael';
SELECT * FROM test
WHERE last_name='Widenius'
AND (first_name='Michael' OR first_name='Monty');
SELECT * FROM test
WHERE last_name='Widenius'
AND first_name >='M' AND first_name < 'N';
하지만, name 인덱스는 아래의 쿼리에서는 사용되지 않는다:
SELECT * FROM test WHERE first_name='Michael';
SELECT * FROM test

:::MySQL Korea:::
WHERE last_name='Widenius' OR first_name='Michael';
쿼리의 속도를 향상 시키기 위해 MySQL이 인덱스를 사용하는 방법에 대해서는 Section 7.4.5, “MySQL의 인덱스 사용 방
법”에서 보다 자세히 다루기로 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.5. MySQL의 인덱스 사용 방법
7.4. 데이터 베이스 구조 최적화 하기 인덱스는 특정 컬럼 값을 가지고 있는 열을 빨리 찾기 위해서 사용된다. 인덱스를 사용하지 않는다면, MySQL은 첫 번째의 열로부
7.4.5 MySQL의 인덱스 사용 방법 터 전체 테이블에 걸쳐서 연관된 열을 찾아야만 한다. 테이블이 크면 클수록 비용도 늘어나게 되는 것이다. 만일 테이블이 쿼리에
있는 질문 컬럼에 대한 인덱스를 가지고 있다면, MySQL은 모든 데이터를 조사하지 않고 데이터 파일의 중간에서 검색 위치를 재
빨리 알아낼 수가 있다. 만일 테이블이 1,000개의 열을 가지고 있다면, 이것은 최소 100배의 속도 향상을 가질 수가 있다. 만일 여
러분이 대부분의 열을 접속할 필요가 있는 경우라면, 순차적인 읽기(sequential read)가 더 빠르게 되는데, 그 이유는 이 방법이 디
스크 검색을 최소화 하기 때문이다.
대부분의 MySQL 인덱스 (PRIMARY KEY, UNIQUE, INDEX, 그리고 FULLTEXT)는 B-트리에 저장된다. 공간 테이터
(spatial data)의 경우는 R-트리를 사용한다는 것은 예외이며, 또한 MEMORY 테이블도 해시 인덱스(hash indexes)를 지원한다
는 점도 알아 두기 바란다.
스트링은 자동적으로 접두사-(prefix-)와 끝-공간(end-space) 압축이 된다. Section 13.1.4, “CREATE INDEX 신텍
스”를 참조할 것.
MySQL은 아래의 연산에서 인덱스를 사용한다:
● WHERE 구문과 일치하는 열을 빨리 찾기.

● 열을 고려 대상에서 빨리 없애 버리기. 만일 여러 개의 인덱스간에 선택을 해야 한다면, MySQL은 보통 최소의 열을 찾는

:::MySQL Korea:::
인덱스를 사용한다.
● 조인(join)을 실행할 때 다른 테이블에서 열을 추출하기.
● 특정하게 인덱스된 컬럼 key_col을 위한 MIN() 또는 MAX() 값 찾기. 이것은 인덱스에서 key_col 전에 발생하는 모든
키 부분의 WHERE key_part_N = constant를 여러분이 사용할 수 있는지를 검사하는 프리 프로세서(pre-processor)
에 의해 최적화 된다. 이와 같은 경우에는, MySQL은 각각의 MIN() 또는 MAX() 수식에 대해서 단일 키 룩업(lookup)을
하게 되며 이것을 항수로 대체한다. 만일 모든 수식이 항수로 대체가 되면, 쿼리는 즉시 리턴된다. 예를 들면:
• SELECT MIN(key_part2),MAX(key_part2)
• FROM tbl_name WHERE key_part1=10;
● 정렬(sorting)및 그룹화(grouping)가 사용할 수 있는 키의 최 좌측 접두사(leftmost prefix)를 가지고 이루어지는 경우

의 정렬(sort) 및 그룹화(group)하기 (예를 들면, ORDER BY key_part1, key_part2). 만일 모든 키 부분이 DESC 다음
에 나온다면, 그 키는 역순으로 읽혀지게 된다. Section 7.2.12, “ORDER BY 최적화”를 참조할 것.
● 어떤 경우에는, 데이터의 열을 참조하지 않는 상태로 값을 추출하기 위해서 쿼리를 최적화 할 수도 있다. 만일 쿼리가 숫자
만으로 이루어진 테이블에 있는 컬럼만을 사용하고 몇몇 키에 대해서는 최 좌측 접두사를 가지고 있다면, 선택된 값은 인덱
스 트리로부터 매우 빠른 속도로 추출이 될 것이다:
• SELECT key_part3 FROM tbl_name
• WHERE key_part1=1
여러분이 아래와 같은 SELECT 명령문을 입력했다고 가정하자:
mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
만일 다중-컬럼 인덱스가 col1 과 col2에 존재한다면, 적당한 열을 직접 가져올 수 있게 된다. 만일 별개의 단일-컬럼 인덱스가
col1 과 col2에 존재한다면, 옵티마이저는 어떤 인덱스가 가장 적은 열을 찾아내는 가장 제한적인 인덱스를 찾으려고 시도를 한다.
만일 테이블이 다중-컬럼 인덱스를 가지고 있다면, 옵티마이저는 인덱스의 최 좌측 접두사를 사용해서 열을 찾게 된다. 예를 들면,

:::MySQL Korea:::
만일 여러분이 세개의 컬럼 인덱스를 (col1, col2, col3)에서 가지고 있다면, 여러분은 (col1), (col1, col2), 그리고 (col1, col2,
col3)상에서 검색 기능이 있는 인덱스를 가지게 되는 것이다.
MySQL은 컬럼이 인덱스의 최 좌측 접두사를 가지고 있지 않다면, 부분 인덱스를 사용할 수가 없게 된다. 여러분이 아래와 같은
SELECT 명령문을 가지고 있다고 가정하자:
SELECT * FROM tbl_name WHERE col1=val1;
SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;
SELECT * FROM tbl_name WHERE col2=val2;
SELECT * FROM tbl_name WHERE col2=val2 AND col3=val3;
만일 (col1, col2, col3)상에 인덱스가 하나 존재한다면, 처음 두 개의 쿼리만이 인덱스를 사용하게 된다. 세 번째와 네 번째도 인덱
스된 컬럼을 가지고 있기는 하지만, (col2) 와 (col2, col3) 는 (col1, col2, col3)의 최 좌측 접두사가 아니다.
B-트리 인덱스는 =, >, >=, <, <=, 또는 BETWEEN 연산자를 사용하는 수식에서 컬럼 비교를 위해 사용될 수 있다.
또한, LIKE에 대한 인수가 와일드 카드 문자로 시작되지 않는 항수 스크링일 경우에는, LIKE 비교를 위해서도 이 인덱스를 사용
할 수 있다. 예를 들면, SELECT 명령문은 인덱스를 사용한다:
SELECT * FROM tbl_name WHERE key_col LIKE 'Patrick%';
SELECT * FROM tbl_name WHERE key_col LIKE 'Pat%_ck%';
첫 번째 명령문에서 보면, 'Patrick' <= key_col < 'Patricl'를 가지고 있는 열만이 고려되었다. 두 번째 명령문에서는, 'Pat'

:::MySQL Korea:::
<= key_col < 'Pau'를 가지고 있는 열만이 고려된다.
아래의 SELECT 명령문은 인덱스를 사용하지 않는다:
SELECT * FROM tbl_name WHERE key_col LIKE '%Patrick%';
SELECT * FROM tbl_name WHERE key_col LIKE other_col;
첫 번째 명령문의 경우, LIKE 값은 와일드 카드 문자로 시작이 된다. 두 번째 명령문에서는, LIKE 값이 항수가 아니다.
만일 여러분이 ... LIKE '%string%'을 사용하고, string이 3개의 문자 보다 길다면, MySQL 은 스트링용 패턴을 초기화 시키기 위
해Turbo Boyer-Moore algorithm 을 사용하게 되며, 이 패턴을 사용해서 검색을 보다 빠르게 실행한다.
col_name IS NULL을 사용하는 검색은 col_name 이 인덱스 되어진 경우에는 적용할 수가 있다.
WHERE 구문에 있는 모든AND 레벨에 해당하지 않는 모든 인덱스는 쿼리를 최적화하는데 사용되지 않는다. 달리 표현하면, 인덱
스를 사용하기 위해서는, 인덱스의 접두사가 반드시 모든 AND 그룹에서 사용되어야 한다는 것이다.
아래의 WHERE 구문은 인덱스를 사용한다:
... WHERE index_part1=1 AND index_part2=2 AND other_column=3
/* index = 1 OR index = 2 */
... WHERE index=1 OR A=10 AND index=2
/* optimized like "index_part1='hello'" */

:::MySQL Korea:::
... WHERE index_part1='hello' AND index_part3=5
/* Can use index on index1 but not on index2 or index3 */
... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;
아래의 WHERE 구문은 인덱스를 사용하지 않는다:
/* index_part1 is not used */
... WHERE index_part2=1 AND index_part3=2
/* Index is not used in both parts of the WHERE clause */
... WHERE index=1 OR A=10
/* No index spans all rows */
... WHERE index_part1=1 OR index_part2=10
때때로, MySQL은 인덱스를 사용할 수 있을 지라도 이것을 사용하지 않는 경우도 있다. MySQL이 인덱스를 사용하기 위해서는 테
이블의 거의 모든 열을 접속할 필요가 있다고 옵티마이저가 판단할 경우가 이에 해당한다. (이와 같은 경우에는, 테이블 스캔이 속
도가 더 빠르다.) 하지만, 만일 이러한 쿼리가 LIMIT를 사용해서 열의 일부분만 추출하는 경우에는, MySQL은 인덱스를 사용하
게 되는데, 그 이유는 결과를 리턴하기 위해서 찾아야 하는 열의 숫자가 작기 때문에 그 만큼 속도가 빠르기 때문이다.
해시 인덱스(Hash indexes)는 위에서 설명한 것과는 다소 다른 특징을 가지고 있다:
● 이것은 = 또는 <=> 연산자를 사용하는 등식 비교에 대해서만 사용된다 (하지만 매우 빠름). 이것은 값의 범위를 찾
기 위한 < 와 같은 비교 연산자와는 사용되지 않는다.
● 옵티마이저는 ORDER BY 연산의 속도를 증가 시키기 위해 이것을 사용할 수가 없다. (이런 타입의 인덱스는 다음 순서의
엔트리를 위한 검색용으로 사용될 수 없다.)

:::MySQL Korea:::
● MySQL은 두 개의 값 사이에 얼마나 많은 열이 있는지를 추정할 수 없다 (이것은 사용한 인덱스가 어떤 것인지를 결정하
기 위한 범위 옵티마이저가 사용하는 것이다).
단지 전체 키만을 가지고 열에 대한 검색을 할 수가 있다. (B-트리 인덱스를 사용한다면, 키의 최 좌측 접두사가 열 검색에 사용될
수가 있다.)

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.6. MyISAM 키 캐시
7. 최적화(Optimization) 7.4.6.1. 공유 키 캐시 접속
7.4. 데이터 베이스 구조 최적화 하기 7.4.6.2. 다중 키 캐시
7.4.6 MyISAM 키 캐시 7.4.6.3. 중간 삽입(Midpoint Insertion) 전략
7.4.6.1 공유 키 캐시 접속 7.4.6.4. 인덱스 프리 로딩(Preloading)
7.4.6.2 다중 키 캐시 7.4.6.5. 키 캐시 블럭 크기
7.4.6.6. 키 캐시 재 구축하기
7.4.6.5 키 캐시 블럭 크기
디스크의 I/O를 최소화 하기 위해서, MyISAM 스토리지 엔진은 대부분의 데이터 베이스 시스템이 사용하고 있는 전략을 사용하고
있다. 이 엔진은 메모리에 있는 테이블 블록 중에서 가장 자주 사용이 되는 것의 정보를 보관하기 위한 캐시 매커니즘을 사용한다:
● 인덱스 블록의 경우, key cache (또는 key buffer)라고 불리는 특정 구조를 관리한다. 이 구조는 가장 많이 사용된 인덱
스 블록이 있는 블록 버퍼의 숫자를 가진다.
● 데이터 블록의 경우, MySQL는 특별한 캐시를 사용하지 않는다. 대신에 이 시스템은 원(native) OS의 파일 시스템 캐시
에 의존을 한다.
이 섹션에서는 우선 MyISAM 키 캐시의 기본 동작 원리에 대해 설명을 하며, 그런 다음에 키 캐시 성능을 개선시킬 수 있는 기능들
과 여러분이 캐시 동작을 보다 효과적으로 제어할 수 있는 방법에 대해 설명을 하기로 한다:
● 키 캐시에 대한 접속은 더 이상 쓰레드간에 순차적으로 이루어 지는 것이 아니다. 여러 개의 쓰레드들이 하나의 캐시에 동

시에 접속을 할 수 있게 되었다.
● 여러분은 다중 키 캐시를 설정할 수 있게 되었으며 특정 캐시에 테이블 인덱스를 할당할 수도 있다.
키 캐시의 크기를 제어하기 위해서는, key_buffer_size 시스템 변수를 사용한다. 만일 이 변수가 0(zero)으로 설정이 된다면, 아무

:::MySQL Korea:::
런 키 캐시도 사용되지 않는다. 키 캐시는 key_buffer_size 값이 너무 작아서 블록 버퍼(8)의 최소 숫자를 할당할 수 없는 경우에
도 키 캐시는 사용되지 않는다.
키 캐시가 동작을 하지 않게 되면, 인덱스 파일은 OS가 제공하는 원(native) 파일 시스템의 버퍼만을 사용해서 접속할 수 있다.
(달리 표현하면, 테이블 인덱스 블록은 테이블 데이터 블록에 적용된 동일한 전략을 사용해서 접속할 수가 있게 된다.)
인덱스 블록은 MyISAM 인덱스 파일에 대한 연속적인 접속 단위(contiguous unit of access)이다. 보통의 경우, 인덱스 블록의
크기는 인덱스 B-트리의 노드 크기와 일치하게 된다. (인덱스는 B-트리 데이터 구조를 사용해서 디스크에 나타낸다. 트리의 맨
밑에 있는 노드는 잎사귀(leaf)노드이다. 잎사귀 노드 위의 것들은 잎사귀 노드가 아니다.)
키 캐시 구조내에 있는 모든 블록 버퍼는 동일한 크기가 된다. 이 크기는 케이블 인덱스 블록의 크기와 같거나, 크거나, 또는 작을
수가 있다. 보통의 경우, 이 두 값들 중의 하나는 다른 하나의 볓 배수가 된다.
테이블 인덱스 블록으로부터 데이터를 접속할 때, 서버는 우선 이것이 키 캐시의 다른 블록 버퍼에서 사용 가능한 것인지를 검사한
다. 만일 가능 하다면, 서버는 디스크가 아닌 키 캐시에 있는 데이터를 접속한다. 즉, 서버는 캐시에서 읽어 오거나 캐시에 쓰게 된
다. 그렇지 않을 경우에는, 서버는 서로 다른 테이블 인덱스 블록(또는 블록)을 가지고 있는 캐시 블록 버퍼를 하나 선택하고 요청
을 받은 테이블 인덱스 블록의 복사본을 가지고 그것을 대체한다. 새로운 인덱스 블록이 캐시에 생기게 되면, 인덱스 데이터는 즉
시 접속될 수가 있게 된다.
만일 대체용으로 선택된 블록이 수정되어지면, 그 블록은 “오염(dirty)”된 것으로 간주된다. 이와 같은 경우가 발생하면, 대체를
하기 전에, 그 내용물을 테이블 인덱스로 플러시 해 버린다.

:::MySQL Korea:::
일반적으로 서버는 LRU (Least Recently Used) 전략을 따르게 된다: 대체용으로 블록을 선택할 때, 서버는 인덱스 블록 중에 최
근에 가장 덜 사용된 것을 고른다. 이러한 선택을 보다 쉽게 하기 위해서, 키 캐시 모듈은 사용
되는 모든 블록에 대해 특별한 큐(LRU chain)를 관리한다. 하나의 블록을 접속하면, 이것은 큐의 맨 마지막으로 들어가게 된다. 블
록을 대체할 필요가 생기면, 큐의 맨 처음에 있는 블록이 최근에 가장 덜 사용된 것이 되며 이 목적에 대한 첫 번째 후보가 되는 것
이다.

:::MySQL Korea:::
제목검색
7.4.6.1. 공유 키 캐시 접속
7.4. 데이터 베이스 구조 최적화 하기 쓰레드는 아래의 조건에 관련하여 키 캐시 버퍼를 동시에 접속할 수가 있다:
● 업데이트 되지 않는 버퍼는 여러 개의 쓰레드에 의해 접속될 수 있다.
7.4.6.1 공유 키 캐시 접속
● 업데이트가 되는 버퍼는 업데이트가 완료될 때까지 이 버퍼를 사용하고자 하는 쓰레드를 대기 상태로 만든다.
7.4.6.2 다중 키 캐시
● 다중의 쓰레드는 서로간에 간섭을 하지 않는 한 캐시 블록을 대체하게끔 초기에 요청할 수가 있다 (즉, 쓰레드들이 서로 다
른 인덱스 블록을 필요로 하는 한, 이것은 서로 다른 캐시 블록이 대체되게끔 한다).
7.4.6.5 키 캐시 블럭 크기
키 캐시에 대한 공유 접속은 서버의 성능을 획기적으로 개선 시켜 준다.
:::MySQL Korea:::
제목검색
7.4.6.2. 다중 키 캐시
7.4. 데이터 베이스 구조 최적화 하기 키 캐시에 대한 공유 접속이 서버의 성능을 개선 시켜 주기는 하지만 쓰레드간의 전반적인 경쟁을 해소해 주지는 않는다. 쓰레드들
7.4.6 MyISAM 키 캐시 은 키 캐시 버퍼의 접속을 관리하기 위한 관리 구조에 대해서 서로 경쟁을 한다. 캐 캐시 접속 경쟁을 해소하기 위해서, MySQL는
7.4.6.1 공유 키 캐시 접속 다중 키 캐시도 함께 제공을 한다. 이 기능을 통해 여러분은 서로 다른 캐
7.4.6.2 다중 키 캐시
캐시에 서로 별도의 테이블 인덱스를 할당할 수가 있게 된다.
7.4.6.5 키 캐시 블럭 크기
7.4.6.6 키 캐시 재 구축하기 다중 키 캐시가 존재하는 경우에는, 서버는 주어진 MyISAM 테이블에 대한 쿼리를 실행할 때 어떤 캐시를 사용해야 하는지를 알
고 있어야 한다. 디폴트로는, 모든 MyISAM 테이블 인덱스가 디폴트 키 캐시에 저장된다(cached). 테이블 인덱스를 특정 키 캐시
에 할당하기 위해서는, CACHE INDEX 명령문을 사용한다 (Section 13.5.5.1, “CACHE INDEX 신텍스”를 참조). 예를 들면,
아래의 명령문은 테이블 t1, t2, 및 t3 로 부터 hot_cache라는 이름의 키 캐시를 할당한다.
mysql> CACHE INDEX t1, t2, t3 IN hot_cache;
+---------+--------------------+----------+----------+
| Table | Op | Msg_type | Msg_text |
+---------+--------------------+----------+----------+
| test.t1 | assign_to_keycache | status | OK |

:::MySQL Korea:::
+---------+--------------------+----------+----------+
CACHE INDEX 명령문에서 참조되는 키 캐시는 statement can be created by setting its size with a SET GLOBAL 파라미
터 설정 명령문을 가지고 그 크기를 설정하거나 또는 서버 스타트업 옵션을 사용해서 생성을 할 수가 있다. 예를 들면:
mysql> SET GLOBAL keycache1.key_buffer_size=128*1024;
키 캐시를 없애기 위해서는, 그 크기를 0으로 설정한다:
mysql> SET GLOBAL keycache1.key_buffer_size=0;
여러분은 디폴트 키 캐시를 없애지는 못한다는 것을 알아두기 바란다.:
mysql> SET GLOBAL key_buffer_size = 0;
mysql> SHOW VARIABLES LIKE 'key_buffer_size';
+-----------------+---------+
+-----------------+---------+
| key_buffer_size | 8384512 |
+-----------------+---------+
키 캐시 변수는 이름과 컴퍼넌트(component)를 가지고 있는 구조 시스템 변수(structured system variable)이다. keycache1.

key_buffer_size의 경우, keycache1는 캐시 변수의 이름이며 key_buffer_size는 컴퍼넌트가 된다. Section 5.2.3.1, “구조 시스
템 변수”를 참조할 것.

:::MySQL Korea:::
디폴트로는 테이블 인덱스는 서버가 스타트업 될 때 메인(디폴트) 키 캐시에 할당된다. 키 캐시를 없애 버리게 되면, 여기에 할당
된 모든 인덱스는 디폴트 키 캐시에 재 할당이 된다.
업무를 바쁘게 처리하는 서버의 경우, 우리는 세 가지 키 캐시를 사용하는 전략을 권장한다:
● “핫(hot)” 키 캐시: 모든 키 캐시에 할당된 공간(space)의 20% 이상을 차지하는 키 캐시. 업데이트는 없이 주로 검색용
으로 사용하는 테이블을 위해서는 이 키 캐시를 사용한다.
● “콜드(cold)” 키 캐시: 모든 키 캐시에 할당된 공간(space)의 20% 정도를 차지하는 키 캐시. 임시 테이블과 같이 중간
크기의 수정용으로 사용되는 테이블용으로는 이 키 캐시를 사용한다.
● “웜(warm)” 키 캐시: 모든 키 캐시에 할당된 공간(space)의 60% 이상을 차지하는 키 캐시. 다른 모든 테이블이 디폴트
로 사용하도록 이 캐시를 디폴트 키 캐시로 적용한다.
세 가지 키 캐시를 사용하는 것이 유익한 이유 중의 하나는 하나의 키 캐시 구조에 대한 접속이 다른 키 캐시에 대한 접속을 막지 않

는다는 것이다. 하나의 캐시에 할당된 테이블에 접속을 하는 명령문은 다른 캐시에 할당된 테이블에 접속을 하는 명령문과 경쟁을
하지 않게 된다. 아래와 같은 여러 가지 이유로 인해 성능은 많이 개선이 된다:
● 핫 캐시는 데이터 추출용 쿼리를 위해서만 사용되기 때문에, 이것이 가지고 있는 데이터는 결코 수정이 되지 않는다. 결과
적으로, 하나의 인덱스 블록을 디스크에서 가져올 필요가 있을 때마다, 대체용으로 선택된 캐시 블록의 내용물을 우선 플러
시 할 필요가 없어지게 된다.
● 핫 캐시에 할당된 인덱스의 경우, 만일 인덱스 스캔을 요구하는 쿼리가 존재하지 않는다면, 인덱스 B-트리의 잎사귀 노드
가 아닌 것에 대응하는 인덱스 블록이 캐시 안에 있을 가능성이 매우 높게 된다.
● 임시 테이블에 대해서 매우 자주 실행된 업데이트 동작은 업데이트가 된 노드가 캐시에 있을 경우에는 매우 빠르게 실행이
되며 디스크에서 먼저 읽어올 필요가 없어지게 된다. 만일 임시 테이블의 인덱스 크기가 콜드 키 캐시의 크기와 비슷하다
면, 업데이트 노드가 캐시 안에 있을 가능성이 매우 높게 된다.
CACHE INDEX은 테이블과 키 캐시간의 결합(association)을 설정하지만, 이 결합은 서버가 재 시작을 하면 잃어 버리게 된다. 만
일 여러분이 서버가 시작할 때 마다 이 결합이 이루어 지도록 만들고자 한다면, 옵션 파일을 사용하는 것이 하나의 방법이다: 캐 캐
시를 구성하는 변수 설정을 옵션 파일에 포함시키고, 실행될 CACHE INDEX 명령문을 가지고 있는 파일 이름을 init-file 옵션에

:::MySQL Korea:::
지정해 준다. 예를 들면:
key_buffer_size = 4G
hot_cache.key_buffer_size = 2G
cold_cache.key_buffer_size = 2G
init_file=/path/to/data-directory/mysqld_init.sql
mysqld_init.sql 안에 있는 명령문은 서버가 시작될 때마다 실행된다. 파일 안에는 라인 당 하나의 SQL 명령문을 사용해야 한다.
다음의 예제는 몇몇 테이블을 hot_cache 와 cold_cache에 할당을 해 준다:
CACHE INDEX db1.t1, db1.t2, db2.t3 IN hot_cache
CACHE INDEX db1.t4, db2.t5, db2.t6 IN cold_cache

:::MySQL Korea:::
제목검색
7.4.6.3. 중간 삽입(Midpoint Insertion) 전략

7.4. 데이터 베이스 구조 최적화 하기 디폴트로, 키 캐시 관리 시스템은 복원(evict)해야 할 키 캐시 블록을 선택하기 위해서 LRU 전략을 사용하지만, 소위 중간 삽입
7.4.6 MyISAM 키 캐시 (Midpoint Insertion) 전략이라고 불리는 보다 복잡한 방식도 지원을 한다
7.4.6.1 공유 키 캐시 접속
7.4.6.2 다중 키 캐시
중간 삽입(Midpoint Insertion) 전략을 사용할 경우, LRU 체인(chain)은 두 부분으로 나뉘어 진다: 핫 서브 체인(hot sub-
chain) 및 웜 서브 체인(warm sub-chain). 두 부분이 나눠지는 경계(point)는 정해지지는 않지만, 키 캐시 관리 시스템은 웜 부
7.4.6.5 키 캐시 블럭 크기 분(warm part)가 항상 키 캐시 블록의 최소 key_cache_division_limit 를 가질 수 있도록 “너무 작게(too short)”되지 않도록
7.4.6.6 키 캐시 재 구축하기 만들게 된다. key_cache_division_limit는 구조 키 캐시 변수의 컴퍼넌트(component)이기 때문에, 이것의 값은 캐시 당 설정되어
야 하는 파라미터가 된다.
인덱스 블록을 테이블에서 키 캐시로 읽어 들일 때, 이것은 웜 서브 체인(warm sub-chain)의 맨 마지막에 들어가게 된다. 특정 숫
자만큼의 히트(블록에 대한 접속)가 되고 나면, 이것은 핫 서브 체인(hot sub-chain)으로 개선(promote) 된다. 현재의 버전으로
보면, 블록(3)로 개선(promote)되는데 필요한 히트 수는 모든 인덱스 블록에 대해서 동일하게 적용된다.
핫 서브 체인으로 개선된 블록은 체인의 맨 마지막에 위치하게 된다. 그런 후에, 그 블록은 이 서브 체인 안에서 순환된다
(circulate). 만일 이 블록이 서브 체인의 처음 부분에 오랫동안 있게 된다면, 이것은 다시 웜 체인으로 내려지게 된다. 이렇게 되는
시간은 키 캐시의 key_cache_age_threshold 컴퍼넌트 값을 가지고 판단된다.

:::MySQL Korea:::
N 개의 블록을 가지고 있는 키 캐시에 대해서, 쓰레드홀드(threshold)는 마지막 N × key_cache_age_threshold / 100개의 히트

내에서는 접속하지 않은 핫 서브 체인의 시작 시점의 블록은 웜 서브 체인의 시작 점으로 이동되어야 한다고 규정 한다. 그렇게 되
면, 이것이 복원(eviction)을 위한 첫 번째 후보가 되는데, 그 이유는 대체를 위한 블록은 항상 웜 서브 체인의 처음에서 가져오기
때문이다.
중간 삽입(Midpoint Insertion) 전략을 통해 여러분은 캐시 안에 보다 가치를 가지는 블록을 유지할 수 있게 된다. 만일 여러분이
일반적인(plain) LRU 전략을 선호한다면, key_cache_division_limit의 값을 디폴트 100으로 놔 두면 된다.

:::MySQL Korea:::
제목검색
7.4.6.4. 인덱스 프리 로딩(Preloading)

7.4. 데이터 베이스 구조 최적화 하기 만약에 캐시 내에 전체 인덱스 블록을 가질 수 있을 만큼의 충분한 블록이 존재하거나, 또는 인덱스의 잎사귀 노드가 아닌 것과 상
7.4.6 MyISAM 키 캐시 응할 만큼의 최소 블록을 가지고 있다면, 키 캐시를 사용해서 시작을 하기 전에 인덱스 블록과 함께 키 캐시를 읽어 오는 것이 좋을
7.4.6.1 공유 키 캐시 접속 것이다. 이렇게 미리 읽어 오게 되면 여러분은 테이블 인덱스 블록을 가장 효과적인 방법으로 키 캐시 버퍼안에 넣을 수가 있게 된
다: 디스크에서 순차적으로 인덱스 블록을 읽어 옴으로써.
7.4.6.2 다중 키 캐시
7.4.6.5 키 캐시 블럭 크기 미리 읽어 오지 않게 되면, 블록은 여전히 쿼리가 필요로 하는 형태로 키 캐시 안에 머물러 있게 된다. 비록 블록이 캐시 안에 있게
7.4.6.6 키 캐시 재 구축하기 되더라도, 이것들을 보관할 만큼 충분한 공간이 있기 때문에, 순차적인 순서가 아닌 랜덤(random)한 순서로 디스크에서 블록을 가
져올 수 있게 된다.
'인덱스를 캐시 안으로 미리 읽어 오기 위해서는, LOAD INDEX INTO CACHE 명령문을 사용한다. 예를 들면, 아래의 명령문은
테이블 t1 과 t2의 인덱스 노드(인덱스 블록)을 미리 읽어 온다:
mysql> LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;
+---------+--------------+----------+----------+
+---------+--------------+----------+----------+

:::MySQL Korea:::
| test.t1 | preload_keys | status | OK |
+---------+--------------+----------+----------+
IGNORE LEAVES 수정자(modifier)는 인덱스의 잎사귀 노드가 아닌 블록만을 미리 읽어 오도록 한다. 따라서, 위의 명령문은 t1
로부터 모든 인덱스 블록을 미리 읽어 오지만, t2로부터는 잎사귀 노드가 아닌 블록만을 읽어 오게 된다.
만일 인덱스가 CACHE INDEX 명령어를 사용해서 키 캐시에 할당되었다면, 미리 읽기(preloading)는 인덱스 블록을 그 캐시 안으
로 집어 넣게 된다. 그렇지 않은 경우에는, 인덱스는 디폴트 키 캐시 안으로 들어가게 된다.

:::MySQL Korea:::
제목검색
7.4.6.5. 키 캐시 블럭 크기
7.4. 데이터 베이스 구조 최적화 하기 key_cache_block_size 변수를 사용하면 개별적인 키 캐시의 블록 버퍼 크기를 지정할 수가 있게 된다. 이를 통해서 인덱스 파일
7.4.6 MyISAM 키 캐시 에 대한 I/O 연산의 성능을 튜닝할 수 있게 된다.
7.4.6.1 공유 키 캐시 접속
7.4.6.2 다중 키 캐시
I/O 연산은 읽기용 버퍼의 크기가 OS의 원(native) I/O 버퍼와 크기가 동일할 때 가장 좋은 성능을 나타낸다. 하지만 키 노드의 크
기를 I/O버퍼의 크기와 똑 같게 만드는 것이 전반적으로 가장 좋은 성능을 보장해 주는 것은 아니다.
7.4.6.5 키 캐시 블럭 크기
현재까지는, 여러분은 테이블에 있는 인덱스 블록의 크기를 제어할 수가 없다. 이 크기는 .MYI 인덱스 파일이 생성될 때 서버에 의
해 설정되며, 테이블 정의문에 존재하는 인덱스의 키 크기에 따라서 정해 진다. 대부분의 경우, 이것은 I/O 버퍼 크기와 동일하게 설
정된다.
:::MySQL Korea:::
제목검색
7.4.6.6. 키 캐시 재 구축하기
7.4. 데이터 베이스 구조 최적화 하기 키 캐시는 파라미터 값을 업데이트하면 언제든지 재 구성될 수가 있다. 예를 들면:
mysql> SET GLOBAL cold_cache.key_buffer_size=4*1024*1024;
7.4.6.1 공유 키 캐시 접속
7.4.6.2 다중 키 캐시
만일 여러분이 key_buffer_size 또는 key_cache_block_size 키 캐시의 컴퍼넌트에 현재의 값과는 다른 값을 할당한다면, 서버는
캐시의 이전 구조를 없애버리며 새로운 값을 기반으로 하는 새로운 구조를 생성하게 된다. 만일 그 캐시가 더티(dirty) 블록을 가지
고 있다면, 서버는 이것을 없애기 전에 디스크에 보관을 하고 난 후에 캐시를 재 생성한다. 만일 여러분이 다른 키 캐시 파라미터를
7.4.6.5 키 캐시 블럭 크기
수정할 경우에는 이러한 재 구성은 일어나지 않는다.
키 캐시를 재 구축할 때, 서버는 우선 더티 버퍼에 있는 데이터를 디스크에 플러시를 한다. 이 과정을 마치고 나면, 캐시에 있는 컨
텐츠는 더 이상 사용을 할 수 없게 된다. 하지만, 캐시 재 구축은 캐시에 할당된 인덱스를 사용하고자 하는 쿼리를 막지는 않는다.
대신에, 서버는 원(native) 파일 시스템 캐싱을 사용해서 테이블 인덱스를 직접 접속한다. 파일 시스템 캐싱은 키 캐시를 사용하는
것만큼 효율적이지 못하기 때문에, 쿼리가 실행되기는 하지만, 속도가 느려지게 된다. 캐시가 재 구축된 후에는, 여기에 할당된 인
덱스를 캐싱하기 위해 다시 사용 가능한 상태가 되고, 인덱스에 대한 파일 시스템 캐싱 사용은 중단된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.7. MyISAM 인덱스 통계 수집
7.4. 데이터 베이스 구조 최적화 하기 스토리지 엔진은 옵티마이저가 사용한 테이블에 대한 통계 정보를 수집한다. 테이블 통계치는 값 그룹 (value group)을 기반으로
하며, 여기에서 값 그룹은 동일한 키 접두사 값을 가지고 있는 열 셋이다. 옵티마이저의 경우, 중요한 통계 값은 평균 값 그룹 크기
가 된다.
MySQL은 아래의 방식에서 평균 값 그룹 크기를 사용한다:
● 얼마나 많은 열이 각 ref 접속을 위해 읽혀져야 하는지를 추정하기 위해

● 부분적인 조인(partial join)이 만들어 내는 열의 숫자를 추정하기 위해: 즉, 이러한 형태의 연산이 만들어낼 수 있는 열의
숫자:
• (...) JOIN tbl_name ON tbl_name.key = expr
인덱스에 대한 평균 값 그룹의 크기는 계속 증가를 함에 따라서, 룩업(lookup)당 열의 평균 숫자는 증가를 하기 때문에, 인덱스는
이러한 두 가지 목적에서는 그리 유용한 것이 되지 못한다: 최적화 목적으로 인덱스를 사용하는 것이 좋을 경우에는, 각각의 인덱
스 값이 테이블에 있는 열의 숫자 보다 작게 되는 것이 바람직하다. 주어진 인덱스 값이 많은 수의 열을 만들어 낸다면, 인덱스는
덜 유용하게 되며 MySQL은 이것을 덜 사용하게 된다.
평균 값 그룹 크기는 테이블 기수(cardinality)와 관련이 되는데, 이것은 값 그룹의 숫자가 된다. SHOW INDEX 명령문은 N/S에
기반한 기수 값을 표시하는데, 여기서 N은 테이블에 있는 열의 숫자이며 S는 평균 값 그룹 크기가 된다. 이 비율은 테이블에 있는
값 그룹의 추정적인 숫자를 만들게 된다.

:::MySQL Korea:::
<=> 비교 연산자를 기반으로 하는 조인(join)의 경우, NULL은 다른 값들과 틀리게 취급되지 않는다: just as for 모든 다
른 N에 대해서 N <=> N 인 것 같이, NULL <=> NULL이 된다.
하지만, = 연산자에 기초한 조인(join)의 경우, NULL은 NULL 값이 아닌 것과 틀리게 취급된다: expr1 또는 expr2 (또는 둘 모
두)이 NULL이 되면, expr1 = expr2 는 트루(true)가 아니다. 이것은 tbl_name.key = expr 형태의 비교에 대한 ref 접속에 영
향을 준다: MySQL은 expr 의 현재 값이 NULL일 경우에는 테이블을 접속할 수가 없게 되는데, 그 이유는 비교 연산이 트루(true)
가 아니기 때문이다.
= 비교에 대해서는, 테이블 안에 얼마나 많은 NULL 값이 존재하느냐는 문제가 되지 않는다. 최적화 목적의 경우, 이에 관련된 값
은NULL이 아닌 값 그룹의 평균 크기가 된다. 하지만, MySQL은 아직까지는 그러한 평균 크기를 수집하거나 사용하는 것을 허용
하지 않고 있다.
MyISAM 테이블의 경우, myisam_stats_method 시스템 변수를 사용해서 테이블 통계 수집 전반에 대한 제어를 할 수가 있다. 이
변수는 두 가지의 가능 값을 가지는데, 그 차이는 아래와 같다:
● myisam_stats_method이 nulls_equal이 될 때, 모든 NULL 값은 서로 별개로(identical) 취급된다. (즉, 모두가 하나의 단

일 값 그룹 형태를 갖는다).
만일 NULL 값 그룹 크기가 평균 비- NULL 값 그룹 크기보다 크다면, 이 방식은 평균 값 그룹 크기를 보다 크게 만든다.

이것은 비-NULL 값을 조사하는 조인(join)용에 비해 덜 유익한 것으로 옵티마이저에 보여지게 된다. 결론적으로는,
nulls_equal 방식은 옵티마이저가 ref 접속을 위해서는 인덱스를 사용하지 못하도록 만들어 버린다.
● myisam_stats_method가 nulls_unequal이 되면, NULL 값은 동일하게 간주되지 않는다. 대신에, 각 NULL 값은 별도의

:::MySQL Korea:::
크기 1인 값 그룹을 형성한다.
만일 여러분이 많은 NULL 값을 가지고 있다면, 이 방식은 평균 값 그룹의 크기를 작게 만든다. 만일 평균 비-NULL 값

그룹의 크기가 크다면, NULL 값을 크기 1의 그룹처럼 계산하는 것은 옵티마이저로 하여금 비-NULL 값을 찾는 조인에
대한 인덱스 값을 과대 해석하게끔 만든다. 결과적으로, nulls_unequal 방식은 다른 방식이 더 효과적일 경우에도 옵티마
이저로 하여금 ref 룩업(lookup)에 대해서는 이 방식을 사용하도록 만들게 된다.
만일 여러분이 =가 아니라 <=>를 사용하는 많은 조인을 사용할 생각이라면, NULL 값은 비교문에서 더 이상 특별한 것이
되지 않으며 하나의 NULL은 다른 것과 동일하게 된다. 이와 같은 경우에는, nulls_equal이 적절한 통계 방법이 된다.
myisam_stats_method 시스템 변수는 글로벌 및 세션 값을 가진다. 글로벌 값을 설정하는 것은 모든 MyISAM 테이블에 대한

MyISAM 통계치 수집에 영향을 미치게 된다. 세션 값을 설정하는 것은 현재의 클라이언트 접속에 대한 통계 수집에만 영향을 준
다. 이것은 myisam_stats_method의 세션 값을 설정함으로써 다른 클라이언트에 영향을 주지 않고 주어진 방식을 사용해서 테이
블 통계치를 재 생성하도록 만든다는 것을 의미한다.
테이블 통계치를 재 생성하기 위해서는, 여러분은 아래의 방식 중에 하나를 사용할 수가 있다:
● myisam_stats_method를 설정하고, 그 다음에 CHECK TABLE 명령문을 입력한다

● myisamchk --stats_method=method_name –analyze를 실행한다
● 테이블을 변경해서 그 통계치가 이전 것이 되도록 하고 (예를 들면, 열을 삽입한 후에 그것을 삭제), 그 다음에
myisam_stats_method를 설정하고 ANALYZE TABLE 명령문을 입력한다
myisam_stats_method를 사용하는 데에는 몇 가지 주의 사항이 있다:
● 여러분은, 위에서 설명한 바와 같이, 테이블 통계치가 명확하게 수집되도록 만들 수가 있다. 하지만, MySQL은 통계치를 자
동으로도 수집을 한다. 예를 들면, 테이블에 대한 명령문을 실행하는 도중에, 만일 이 명령문 중에 하나가 테이블을 수정한

:::MySQL Korea:::
다면, MySQL은 통계치를 수집할 수도 있다. (이것은 대량의 삽입 또는 삭제, 또는 몇몇ALTER TABLE 명령문에서 발생
할 수 있다.) 만일 이런 경우가 발생한다면, 그 통계치는 그 시점의 myisam_stats_method 값을 사용해서 수집된다. 따라
서, 만일 여러분이 하나의 방법을 사용해서 통계치를 수집하지만, if you collect statistics using one method, but 테이
블 통계치를 나중에 자동으로 수집을 할 때에는 myisam_stats_method가 다른 방법을 사용하도록 설정한다면, 다른 방법
이 사용될 것이다.
● 주어진 MyISAM 테이블을 위한 통계치를 만들기 위해 사용된 방식이 어떤 것인지를 알려줄 수 있는 방법은 없다.
myisam_stats_method는 MyISAM 테이블에만 적용된다. 다른 스토리지 엔진은 한 가지 방법만을 가지고 테이블 통계치를 수집
한다. 일반적으로 이것은 nulls_equal 방식과 유사하다

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.8. MySQL의 테이블 열기 및 닫기 방법
7.4. 데이터 베이스 구조 최적화 하기 여러분이 mysqladmin status 명령문을 실행할 때, 여러분은 아래와 비슷한 것을 보게 될 것이다:

Uptime: 426 Running threads: 1 Questions: 11082
Reloads: 1 Open tables: 12
여러분이 오직 6개의 테이블만을 가지고 있다면12의 Open tables 값은 다소 수수께끼와 같은 의미를 가질 것이다.
MySQL은 다중-쓰레드 방식이며, 따라서 주어진 테이블에 대해서 동시에 쿼리를 입력하는 클라이언트가 많이 존재하게 된다. 동
일한 테이블에 있는 서로 다른 상태의 클라이언트 쓰레드로 인한 문제를 최소화 하기 위해서는, 테이블을 각각의 동시 쓰레드에 대
해서 독립적으로 열어야 한다. 이것은 메모리를 추가적으로 사용하기는 하지만 일반적으로는 성능을 향상 시켜준다. MyISAM 테
이블을 사용한다면, 테이블을 열게 하는 각각의 클라이언트에 대한 데이터 파일을 위해서는 여분의 파일 디스크립터(descriptor)
가 필요하게 된다. (반대의 경우, 인덱스 파일 디스크립터는 모든 쓰레드간에 공유가 된다.)
table_cache, max_connections, 그리고 max_tmp_tables 시스템 변수는 서버가 열어 놓는 파일의 최대 숫자에 영향을 준다. 만
일 여러분이 이 값들 중의 하나 또는 여러 개를 증가 시킨다면, 여러분은 프로세스 당 오픈 파일 디스크립터(open file descriptor)
의 숫자 한계를 늘릴 수가 있을 것이다. 많은 OS가 여러 가지 방법을 통해 오픈 파일의 한계를 늘릴 수 있도록 허용을 한다.

:::MySQL Korea:::
table_cache는 max_connections과 관련이 있다. 예를 들면, 200개의 동시 구동 접속의 경우, 여러분은 테이블 캐시의 크기를 최
소 200 × N로 만들 수가 있는데, 여기에서N 은 여러분이 실행하는 쿼리 안에 있는 조인(join) 당 테이블의 최대 숫자가 된다. 여
러분은 또한 반드시 임시 테이블 및 임시 파일에 대한 여분의 파일 디스크립터를 보관하고 있어야 한다.
여러분은 지금 사용하고 있는 OS가 table_cache 설정에 포함되어 있는 오픈 파일 디스크립터의 숫자를 다룰 수 있는지를 확인해
야 한다. 만일 table_cache가 너무 크다면, MySQL은 파일 디스크립터 오류를 만들게 되며 접속을 거부하고, 쿼리 실행을 하지 못
하며, 또한 매우 불안정하게 된다. 여러분은 또한 MyISAM 스토리지 엔진은 각각의 고유한 오픈 테이블에 대해서 두 개의 파일 디
스크립터를 필요로 한다는 점을 알고 있어야 한다. 여러분은 mysqld의 스타트 업 옵션인 --open-files-limit를 사용해서
MySQL에서 사용 가능한 파일 디스크립터의 숫자를 늘릴 수가 있다. Section A.2.17, “File Not Found”를 참조할 것.
오픈 파일의 캐시는 table_cache 엔트리 레벨에서 관리된다. 디폴트 값은 64이다; 이것은 --table_cache 옵션을 가지고 변경 시
킬 수가 있다. MySQL은 쿼리를 실행하기 위한 것 보다 많은 수의 테이블을 임시로 오픈 한다는 점을 알아두자.
아래의 환경 아래에서는, MySQL은 사용되지 않은 테이블은 닫고 이것을 캐시에서 삭제해 버린다:
● 캐시가 가득 찼고 쓰레드가 캐시 안에 없는 테이블을 열고자 시도할 경우.

● 캐시가 table_cache 엔트리에 있는 것 보다 많은 것을 가지고 있고 캐시 안에 있는 테이블이 더 이상 어떠한 쓰레드에 의해
서도 사용되지 않을 경우.
● 테이블 플러싱 연산이 발생될 경우. 이것은 누군가가 FLUSH TABLES 명령문을 입력하거나 또는 mysqladmin flush-
tables 또는 mysqladmin refresh 명령어를 실행할 때 발생한다.
테이블 캐시가 가득 차게 되면, 서버는 사용할 캐시 엔트리를 저장하기 위해서 아래의 과정을 진행한다:
● 사용 중에 있지 않는 테이블은 풀어 놓는다(release).
● 만일 오픈해야 할 테이블이 필요하기는 하지만 캐시가 가득 찾기 때문에 풀어 놓을 테이블이 없게 된다면, 캐시는 필요한
만큼 임시로 확장이 된다.

:::MySQL Korea:::
캐시가 임시로 확장된 상태이고 테이블이 사용되지 않는 상태가 되면, 테이블은 닫히게 되고 캐시에서 풀어져 나오게 된다.
테이블은 각각의 동시 접속에 대해서 열리게 된다. 이것은 만일 두 개의 쓰레드가 동일한 테이블에 접속으로 하거나 하나의 쓰레드
가 동일한 쿼리에서 한 테이블을 두 번 접속을 할 경우에는 테이블이 두 번 열려야 한다는 것을 의미한다. 각각의 동시 오픈은 테이
블 캐시에 있는 하나의 엔트리를 필요로 한다. MyISAM 테이블의 첫 번째 오픈은 두 개의 파일 디스크립터를 가져 온다: 하나는 테
이더 파일용이고 다른 하나는 인덱스 파일용 임. 테이블에 대한 각각의 여분의 사용은 데이터 파일에 대해서 오직 하나의 파일 디스
크립터만을 가져온다. 인덱스 파일 디스트립터는 모든 쓰레드간에 공유가 된다.
만일 여러분이 HANDLER tbl_name OPEN 명령문을 가지고 테이블을 오픈한다면, 지정 테이블 오브젝트(dedicated table
object)는 그 쓰레드에 할당이 된다. 이 테이블 오브젝트는 다른 쓰레드에 의해서는 공유가 되지 않으며 그 쓰레드가 HANDLER
tbl_name CLOSE를 호출하거나 쓰레드를 종료하기 전까지는 닫히지가 않게 된다. 이런 일이 발생을 하면, 테이블은 테이블 캐시
안으로 다시 들어가게 된다 (캐시가 가득 차지 않았을 경우). Section 13.2.3, “HANDLER 신텍스”를 참조.
여러분은 mysqld의 상태 변수인 Opened_tables을 검사함으로써 여러분이 사용하는 테이블 캐시가 너무 작은지를 알아볼 수가 있
다:
mysql> SHOW STATUS LIKE 'Opened_tables';
+---------------+-------+
+---------------+-------+
| Opened_tables | 2741 |

:::MySQL Korea:::
+---------------+-------+
만일 이 값이 너무 크다면, 여러분은 테이블 캐시의 크기를 늘려주어야 한다. Section 5.2.2, “서버 시스템 변수”, 그리고
Section 5.2.4, “서버 상태 변수”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.4.9. 동일 데이터 베이스에 많은 테이블을 생성하기 위해 드로우 백(drawback) 하기
7. 최적화(Optimization) 만일 여러분이 동일한 데이터 디렉토리 안에 많은 수의 MyISAM 테이블을 가지고 있다면, 테이블을 영
7.4. 데이터 베이스 구조 최적화 하기 고, 닫고, 그리고 생성하는 동작이 느려지게 된다. 만일 여러분이 많은 수의 테이블에서 SELECT 명령문
7.4.9 동일 데이터 베이스에 많은 테이블을 생성하기 위해 드로우 백 을 실행한다면, 테이블 캐시가 가득 차게 될 경우에는 다소 오버 헤드가 발생하게 된다. 여러분이 테이블
(drawback) 하기 캐시의 크기를 증가 시킴으로써 이 오버 헤드를 줄일 수가 있게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.5. MySQL 서버 최적화 하기
7. 최적화(Optimization) 7.5.1. 시스템 요소 및 스타트 업 파라미터 튜닝

7.5. MySQL 서버 최적화 하기 7.5.2. 서버 파라미터 튜닝
7.5 MySQL 서버 최적화 하기 7.5.3. 쿼리 옵티마이저 성능 제어하기
7.5.1 시스템 요소 및 스타트 업 파라미터 튜닝 7.5.4. 컴파일 및 링크 작업이 어떻게 MySQL 속도에 영향을 주는
7.5.2 서버 파라미터 튜닝 가
7.5.5. MySQL의 메모리 사용 방법
7.5.3 쿼리 옵티마이저 성능 제어하기
7.5.6. MySQL의 DNS사용 방법
7.5.4 컴파일 및 링크 작업이 어떻게 MySQL 속도에 영향을 주는가
7.5.6 MySQL의 DNS사용 방법
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.5.1. 시스템 요소 및 스타트 업 파라미터 튜닝
7.5. MySQL 서버 최적화 하기 우리는 시스템-레벨의 요소를 가지고 시작을 할 것인데, 그 이유는 이런 요소들이 초창기부터 시스템의 성능을 개선 시키기 위해
7.5.1 시스템 요소 및 스타트 업 파라미터 튜닝 서 사용되었기 때문이다.
OS를 잘 다루는 것이 매우 중요하다. 다중 CPU 시스템을 잘 다루기 위해서는, 솔라리스(왜냐하면 이 OS는 쓰레드를 잘 처리한
다) 또는 리눅스(그 이유는 2.4 및 이후 버전의 커널은 SMP를 잘 지원한다)를 다루는 것이 좋다. 구형 커널 버전의 리눅스는 파일
크기가 2GB만큼 디폴트로 사용한다는 점을 알아두자. 만일 여러분이 이러한 커널을 가지고 있고 2GB 보다 큰 파일을 필요로 한다
면, ext2 파일 시스템에 대한 LFS(Large File System)을 가지고 있어야 한다.
상용 MySQL을 사용하기 전에, 우리는 여러분이 이것을 먼저 테스트 해 보기를 권장한다.
다른 팁:
● 만일 여러분이 충분한 RAM을 가지고 있다면, 모든 스왑(swap) 디바이스(device)를 삭제할 수가 있다. 어떤 OS은 여러분
이 사용 가능한 메모리를 가지고 있다고 하더라도 어떤 문장 안에 스왑 디바이스를 사용하기도 한다.
● 외부 잠금을 사용하지 말 것. MySQL 4.0 이후에는, 모든 시스템에서 외부 잠금을 비활성화 하도록 디폴트로 만들어졌다.
--external-locking 및 --skip-external-locking 옵션은 외부 잠금을 명확하게 활성화 및 비 활성화 시킨다.
외부 잠금을 비 활성화 시키는 것은 여러분이 MySQL을 하나의 서버에서만 구동 시키는 한MySQL의 기능성에는 아무런
영향을 주지 않는다는 점을 알아두자. 여러분이 myisamchk를 구동 시키기 전에는 서버를 다운(down)시켜야 한다는 점
(또는 관련된 테이블을 잠그거나 플러시)만을 기억하기 바란다.
여러분이 외부 잠금을 비 활성화 시킬 수 없는 유일한 경우는, 여러분이 여러 개의 하나의 데이터를 사용해서 여러 대의
MySQL 서버(클라이언트가 아님)를 구동시킬 때이거나, 또는 서버로 하여금 우선 테이블을 플러시한 다음에 잠그도록 명
령하지 않은 채로 테이블을 검사하기 위한 myisamchk를 구동 시킬 경우에만 해당된다. 하나의 데이터에 동시에 여러 대
의 MySQL 서버가 접속을 하도록 하는 것은 일반적으로 권장하지 않는 사항임을 알아두기 바란다. (MySQL클러스터는

:::MySQL Korea:::
예외임)
LOCK TABLES 및 UNLOCK TABLES 명령문은 내부 잠금을 사용하는데, 따라서 여러분은 외부 잠금이 비 활성화 되
어 있는 경우에는 이것을 사용할 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.5.2. 서버 파라미터 튜닝
7.5. MySQL 서버 최적화 하기 여러분은 아래의 명령어를 사용해서 mysqld 서버가 디폴트로 사용하는 디폴트 버퍼의 크기를 알아볼 수가 있다:
7.5.2 서버 파라미터 튜닝
shell> mysqld --verbose --help
이 명령어는 모든 mysqld 옵션 리스트와 구성 가능한 시스템 변수 리스트를 보여 준다. 이 결과에는 디폴트 변수 값이 포함되어 있
고 아래와 같이 보이게 된다:
back_log 50
binlog_cache_size 32768
bulk_insert_buffer_size 8388608
connect_timeout 5
date_format (No default value)
datetime_format (No default value)
default_week_format 0
delayed_insert_limit 100
delayed_insert_timeout 300

:::MySQL Korea:::
delayed_queue_size 1000
expire_logs_days 0
flush_time 1800
ft_max_word_len 84
ft_min_word_len 4
ft_query_expansion_limit 20
ft_stopword_file (No default value)
group_concat_max_len 1024
innodb_additional_mem_pool_size 1048576
innodb_autoextend_increment 8
innodb_buffer_pool_awe_mem_mb 0
innodb_buffer_pool_size 8388608
innodb_concurrency_tickets 500
innodb_file_io_threads 4
innodb_force_recovery 0
innodb_lock_wait_timeout 50

:::MySQL Korea:::
innodb_log_buffer_size 1048576
innodb_log_file_size 5242880
innodb_log_files_in_group 2
innodb_mirrored_log_groups 1
innodb_open_files 300
innodb_sync_spin_loops 20
innodb_thread_concurrency 8
innodb_thread_sleep_delay 10000
interactive_timeout 28800
join_buffer_size 131072
key_buffer_size 8388600
key_cache_age_threshold 300
key_cache_block_size 1024
key_cache_division_limit 100
long_query_time 10
lower_case_table_names 1

:::MySQL Korea:::
max_allowed_packet 1048576
max_binlog_cache_size 4294967295
max_binlog_size 1073741824
max_connect_errors 10
max_connections 100
max_delayed_threads 20
max_error_count 64
max_heap_table_size 16777216
max_join_size 4294967295
max_length_for_sort_data 1024
max_relay_log_size 0
max_seeks_for_key 4294967295
max_sort_length 1024
max_tmp_tables 32
max_user_connections 0
max_write_lock_count 4294967295
multi_range_count 256

:::MySQL Korea:::
myisam_block_size 1024
myisam_data_pointer_size 6
myisam_max_extra_sort_file_size 2147483648
myisam_max_sort_file_size 2147483647
myisam_repair_threads 1
myisam_sort_buffer_size 8388608
net_buffer_length 16384
net_read_timeout 30
net_retry_count 10
net_write_timeout 60
open_files_limit 0
optimizer_prune_level 1
optimizer_search_depth 62
preload_buffer_size 32768
query_alloc_block_size 8192
query_cache_limit 1048576

:::MySQL Korea:::
query_cache_min_res_unit 4096
query_cache_size 0
query_cache_type 1
query_cache_wlock_invalidate FALSE
query_prealloc_size 8192
range_alloc_block_size 2048
read_buffer_size 131072
read_only FALSE
read_rnd_buffer_size 262144
div_precision_increment 4
record_buffer 131072
relay_log_purge TRUE
relay_log_space_limit 0
slave_compressed_protocol FALSE
slave_net_timeout 3600
slave_transaction_retries 10

:::MySQL Korea:::
slow_launch_time 2
sort_buffer_size 2097144
sync-binlog 0
sync-frm TRUE
sync-replication 0
sync-replication-slave-id 0
sync-replication-timeout 10
table_cache 64
thread_cache_size 0
thread_concurrency 10
thread_stack 196608
time_format (No default value)
tmp_table_size 33554432
transaction_alloc_block_size 8192
transaction_prealloc_size 4096
updatable_views_with_limit 1

:::MySQL Korea:::
wait_timeout 28800
현재 구동 중에 있는 mysqld 서버의 경우, 여기에 접속을 해서 아래의 명령문을 입력하면 이 서버의 시스템 변수의 현재 값을 알
아 볼 수가 있다:
mysql> SHOW VARIABLES;
또한 아래의 명령어를 사용하면 구동 중에 있는 서버의 몇몇 통계치와 상태 인디케이터(indicator)를 확인할 수가 있다:
mysql> SHOW STATUS;
시스템 변수 및 상태 정보는 mysqladmin를 사용해서도 얻을 수가 있다:
shell> mysqladmin variables
shell> mysqladmin extended-status
모든 시스템 변수 및 상태 변수에 대한 전체 설명은, Section 5.2.2, “서버 시스템 변수”, 및 Section 5.2.4, “서버 상태 변
수”를 참조할 것.
MySQL은 매우 확장 가능한 알고리즘을 사용하며, 따라서 여러분은 소량의 메모리만을 사용해서도 이것을 구동 시킬 수가 있다.
하지만, 일반적으로 여러분은 보다 많은 메모리를 사용하면 보다 좋은 성능을 얻어낼 수가 있다.
MySQL 서버를 튜닝할 때에는, key_buffer_size 와 table_cache의 값을 정확히 구성하는 것이 매우 중요하다. 여러분은 다른 변
수를 변경하기 전에 이 변수들을 올바르게 설정했는지에 대해 확인을 해야 한다.
이래의 예제는 서로 다른 런 타임 구성을 위한 전형적인 변수 값을 나타내 준다.
● 만일 여러분이 최소 256MB의 메모리와 많은 테이블을 가지고 있고 중간 정도의 클라이언트와 함께 최고의 성능이 나오도
록 하고 싶다면, 아래와 같은 것을 사용해야 한다:
• shell> mysqld_safe --key_buffer_size=64M --table_cache=256 ￦

:::MySQL Korea:::
• --sort_buffer_size=4M --read_buffer_size=1M &
● 만일 여러분이 128MB의 메모리와 적은 수의 테이블만을 가지고 있지만, 정렬할 것이 많이 있다면, 아래와 같이 사용한다:
• shell> mysqld_safe --key_buffer_size=16M --sort_buffer_size=1M
만일 동시 접속 수가 많이 존재한다면, 각각의 접속에 대해서 mysqld 이 적은 량의 메모리만을 사용하도록 구성되지 않

는 한 스왑핑(swapping) 문제가 발생될 수도 있다. Mysqld은 모든 접속에 대해서 충분한 메모리가 있는 경우에 성능이
좋게 된다.
● 메모리는 작고 접속은 많은 경우에는, 아래와 같은 것을 사용한다:
• shell> mysqld_safe --key_buffer_size=512K --sort_buffer_size=100K ￦
• --read_buffer_size=100K &
또는:
shell> mysqld_safe --key_buffer_size=512K --sort_buffer_size=16K ￦
--table_cache=32 --read_buffer_size=8K ￦
--net_buffer_length=1K &
만일 여러분이 사용할 수 있는 메모리보다 큰 테이블에서 GROUP BY 또는 ORDER BY 연산을 실행한다면, 열을 읽은 후에 정렬

연산의 속도를 증가 시키기 위해서는 read_rnd_buffer_size의 값을 늘려 주어야 한다.
여러분이 MySQL을 설치하면, support-files 디렉토리는 my.cnf 샘플 파일을 가지게 된다: my-huge.cnf, my-large.cnf, my-
medium.cnf, 및 my-small.cnf. 여러분은 이것을 시스템 최적화용으로 사용할 수 있을 것이다. (윈도우의 경우, MySQL 설치 디
렉토리를 찾아 보기 바라다.)
만일 여러분이 mysqld 또는 mysqld_safe용의 옵션을 명령어 라인에서 지정하였다면, 이것은 서버의 호출에 대해서만 효력을 나

:::MySQL Korea:::
타낸다. 서버가 구동될 때마다 사용될 수 있도록 하기 위해서는, 이것을 옵션 파일에서 지정해야 한다.
파라미터 변경의 효과를 보기 위해서는, 아래와 같이 입력한다:
shell> mysqld --key_buffer_size=32M --verbose --help
변수 값은 결과의 끝 부분에 나타난다. --verbose 및 --help 옵션이 마지막에 오도록 한다. 그렇지 않으면, 명령어 라인 상에서
이것 뒤에 나오는 옵션들은 결과에 영향을 주지 못하게 된다.
InnoDB 스토리지 엔진 튜닝에 대한 정보는, Section 14.2.11, “InnoDB 성능 튜닝 팁”을 참조하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.5.3. 쿼리 옵티마이저 성능 제어하기
7.5. MySQL 서버 최적화 하기 쿼리 옵티마이저의 업무는 SQL쿼리를 실행하기 위한 옵티말 플랜(optimal plan)을 찾는 것이다. MySQL 5.0.1에서는 보다 유연
7.5.3 쿼리 옵티마이저 성능 제어하기 한 쿼리 최적화 방식을 제공하고 있다.
여러 가지의 플랜에 관련해서 옵티마이저가 실행하는 방식은 두 가지의 시스템 변수를 통해서 제어된다:
● optimizer_prune_level 변수는 각 테이블에 접속을 한 열의 숫자를 추정해서 옵티마이저로 하여금 몇몇 플랜들은 건너 띄

도록 만든다. 우리의 경험상 이러한 종류의 “경험적 추정(educated guess)”은 옵티말 플랜을 거의 빠트리지 않으며, 놀
라울 정도로 쿼리 컴파일 시간을 절약 시켜 준다. 이런 까닭으로 이 옵션이 디폴트로 (optimizer_prune_level=1)가 되는
것이다. 하지만, 만일 옵티마이저가 보다 우수한 쿼리 플랜을 빠트렸다고 생각을 한다면, 이 옵션을
(optimizer_prune_level=0)으로 설정해 놓을 수도 있지만 이렇게 하면 보다 오랜 쿼리 처리 시간이 소요된다.
● optimizer_search_depth 변수는 옵티마이저가 각각의 불완전한 플랜이 나중에 확장될 수 있는지를 조사하도록 만든다.
optimizer_search_depth의 값이 작을수록 쿼리 컴파일 시간이 작게 된다. 예를 들면, 12,13, 또는 그 이상의 테이블을 가
지고 있는 쿼리는, 만일 optimizer_search_depth가 쿼리 안에 있는 테이블 숫자와 비슷해지는 경우에는 몇 시간 또는 하
루 정도가 걸리게 된다. 동시에, 만일 optimizer_search_depth와 함께 컴파일 되는 테이블이 3개 또는 4개 정도라면, 옵티
마이저는 동일 쿼리에 대해서는 몇 분 밖에 걸리지 않을 것이다. 만일 여러분이If you are unsure of what a reasonable
value is for optimizer_search_depth에 가장 적당한 값이 어떤 것인지를 확신하지 않는다면, 이 값을 0으로 설정해서 옵
티마이저로 하여금 이 값을 자동으로 판단하도록 만들면 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.5.4. 컴파일 및 링크 작업이 어떻게 MySQL 속도에 영향을 주는가
7.5. MySQL 서버 최적화 하기 아래에 있는 대부분의 테스트들은 리눅스에서 MySQL 벤치 마크를 사용해서 실행한 것들이긴 하지만, 여러분은
7.5.4 컴파일 및 링크 작업이 어떻게 MySQL 속도에 영향을 주는가 이를 통해서 다른 OS에 대한 지침을 얻을 수가 있을 것이다.
여러분이–static에 링크를 하면 가장 빠른 실행 속도를 얻을 수가 있을 것이다.
리눅스에서는, 서버를 pgcc 및 -O3와 함께 컴파일 하는 것이 가장 좋은 방법이다. 이러한 옵션을 가지고

sql_yacc.cc를 컴파일 하기 위해서는 약 200MB의 메모리가 필요하게 되는데, 그 이유는 gcc 또는 pgcc가 모든
함수를 처리하기 위해서 많은 메모리를 필요로 하기 때문이다. libstdc++ 라이브러리를 포함하지 않도록 MySQL
을 구성할 경우에는 CXX=gcc 설정을 해야만 한다.
보다 좋은 컴파일러와 컴파일 옵션을 사용함으로써, 여러분은 어플리케이션 처리에서 10~30%의 속도 증가를 얻

어낼 수가 있다. 이것은 특히 여러분이 스스로 MySQL을 컴파일할 때에는 특히 중요하다.
표준 MySQL 바이너리 배포판은 모든 문자 셋을 지원하도록 컴파일 되어 있다. 여러분이 스스로 MySQL을 설치

할 때에는, 여러분이 사용하고자 하는 문자 셋만을 지원하도록 해주어야 한다. 이것은 --with-charset 옵션을
configure에 지정해 줌으로서 가능하다.
아래의 리스트는 우리가 이미 만들어 놓은 몇 가지 측정 값들이다:
● 만일 여러분이 pgcc를 사용하고 모든 것을 -O6로 컴파일 한다면, mysqld 서버는 1% gcc 2.95.2 보다
1% 정도 속도가 개선된다.
● 만일 여러분이 동적으로 (-static 없이) 링크를 한다면, 리눅스에서는 13% 정도 속도가 느려지게 된다.
여러분은 여전히 클라이언트 어플리케이션에 대해서는 MySQL 라이브러리르 동적으로 링크 시킬 수가 있
다는 점을 알아 두기 바란다. 성능에 대해서는 서버 쪽이 보다 심각해지는 것이다.

:::MySQL Korea:::
● 동일한 호스트에 있는 서버로 접속을 하는 클라이언트의 경우, 만일 여러분이 유닉스 소켓 파일을 사용하
지 않고 TCP/IP를 사용하는 경우라면, 7.5% 정도의 속도 저하가 생기게 된다. (유닉스의 경우, 만일 여러
분이 호스트 이름 localhost에 접속을 한다면, MySQL은 디폴트로 소켓 파일을 사용한다.)
● 클라이언트에서 서버로의 접속을 TCP/IP로 하는 경우에는, 다른 호스트에 있는 원격 서버로의 접속이 동
일 호스트에 있는 서버로의 접속보다 약 8–11% 정도 느려지게 된다.
● 보안 접속을 사용해서 벤치마크 테스트를 구동 시키면(모든 데이터를 내부 SSL을 가지고 암호화 함) 성능
은 암호화를 하지 않은 접속에 비해 55% 정도 느려지게 된다.
● 만일 여러분이 --with-debug=full를 사용해서 컴파일을 하는 경우에는, 대부분의 쿼리가 20% 정도 느
려지게 된다. 어떤 쿼리들은 심각할 정도로 오래 걸리기도 한다; 예를 들면, MySQL 벤치 마크는 35% 정
도 느려지게 된다. 만일 여러분이 --with-debug (=full 없이)를 사용한다면, 속도는 15% 정도 느려진
다. --with-debug=full을 사용해서 컴파일 된 mysqld의 경우, 여러분은 서버가 시작될 때 --skip-
safemalloc 옵션을 사용해서 런 타임시의 메모리 검사를 비 활성화 시킬 수가 있다. 이렇게 하면 --
with-debug를 사용해서 구성했을 때 얻어지는 수준만큼의 실행 속도를 얻을 수가 있게 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.5.5. MySQL의 메모리 사용 방법
7.5. MySQL 서버 최적화 하기 아래의 리스트는 mysqld 서버가 메모리를 사용하는 방법들을 설명하는 것이다:

● 키 버퍼 (변수 key_buffer_size)는 모든 쓰레드에 의해 공유된다; 서버가 사용하는 다른 버퍼들은 필요할 경우에 할당된
다. Section 7.5.2, “서버 파라미터 튜닝”을 참조할 것.
● 각각의 접속은 쓰레드-관련 공간을 사용한다:
❍ 스택 (디폴트 192KB, 변수 thread_stack)
❍ 접속 버퍼 (변수 net_buffer_length)
❍ 결과 버퍼 (변수 net_buffer_length)
접속 버퍼와 결과 버퍼는 필요할 경우 max_allowed_packet까지 동적으로 커지게 된다. 쿼리가 동작을 하는 동안에는, 현
재 쿼리 스트링의 복사본도 역시 할당된다.
● 모든 쓰레드는 동일 베이스 메모리를 공유한다.

● 한 쓰레드가 더 이상 사용되지 않으면, 그 쓰레드가 다시 쓰레드 캐시로 들어 가지 않는 한 여기에 할당된 메모리는 풀려지
게 되고(release) 시스템에 돌려지게 된다.
● 압축된 MyISAM 테이블만이 메모리에 매핑이 된다. 그 이유는 4GB의 32-비트 메모리 공간은 대부분의 커다란 테이블용
으로는 부족하기 때문이다. 64-비트 주소 공간을 가지는 시스템이 보다 보편화 되면, 우리는 이 점을 보완할 예정이다.
● 테이블에 대한 순차적인 스캔을 실행하는 각각의 요청은 읽기 버퍼(read buffer) (변수 read_buffer_size)를 할당한다.
● 임의적인 순서로 열을 읽을 때(예를 들면, 정렬 순으로), 랜덤 읽기 버퍼(random-read buffer )(변수
read_rnd_buffer_size)를 디스크 검색을 피하기 위해서 할당할 수도 있다.
● 모든 조인(join)은 단일 패스내에서 실행되며, 대부분의 조인(join)은 임시 테이블을 사용하지 않고서도 실행될 수 있다. 대
부분의 입시 테이블은 메모리-기반의 해시(hash) 테이블이다. 긴 열 길이를 가지고 있는 임시 테이블(모든 컬럼 길이의
합으로 계산된) 또는 BLOB 컬럼을 가지고 있는 테이블은 디스크에 저장된다.

:::MySQL Korea:::
만일 내부 힙(heap) 테이블의 크기가 tmp_table_size를 초과한다면, MySQL은 필요하다면 메모리 내에 있는 힙 테이블

을 디스크 기반의 MyISAM 테이블로 변경시켜서 자동으로 이것을 처리한다. 여러분은 tmp_table_size 옵션을 mysqld
에 설정하거나 또는 클라이언트 프로그램에 있는 SQL 옵션 SQL_BIG_TABLES를 설정함으로써 임시 테이블의 크기를
증가 시킬 수가 있다. Section 13.5.3, “SET 신텍스”를 참조할 것.
● 정렬을 실행하는 대부분의 요청은 정렬 버퍼를 할당하며 결과 셋 크기에 따라서 두 개의 임시 파일을 0으로 만든다.
Section A.4.4, “Where MySQL Stores Temporary Files”를 참조할 것.
● 거의 모든 파싱(parsing)과 계산(calculating)은 로컬 메모리에 저장된다. 작은 아이템의 경우에는 메모리 오버 헤드가 거
의 발생하지 않으며, 따라서 일반적인 슬로우 메모리 할당 및 해제(freeing)은 피해진다. 메모리는 예상치 못한 대형 스트
링에 대해서만 할당된다. 이것은 malloc() 과 free()를 가지고 실행된다.
● 열려 있는 각각의 MyISAM 테이블에 대해서는, 인덱스 파일이 일단 열리게 된다; 데이터 파일은 현재 구동 중에 있는 각각
의 쓰레드게 대해서 한번 열리게 된다. 각각의 현재 쓰레드에 대해서는, 테이블 구조, 각 컬럼에 대한 컬럼 구조, 그리고 3
× N 크기의 버퍼가 할당된다 (여기에서 N 은 최대 열 길이이며, BLOB 컬럼을 계산하지는 않는다). BLOB 컬럼은
BLOB 데이터 길이보다 5에서8 바이트를 더 필요로 한다. MyISAM 스토리지 엔진은 내부 용도로 하나의 열 버퍼를 추가
로 관리한다.
● For each table having BLOB 컬럼을 가지고 있는 각 테이블에 대해서는, 버퍼가 BLOB에 들어 있는 큰 값을 읽을 수 있도
록 동적으로 커진다. 만일 여러분이 테이블을 스캔한다면, BLOB 값 만킄 커다란 버퍼가 할당된다.
● 사용 중에 있는 테이블에 대한 핸들러 구조(Handler structure)는 캐시 안에 저장되며 FIFO 방식으로 다루어진다. 디폴트
로는, 캐시는 64개의 엔트리를 가진다. 만일 테이블이 동시에 구동되는 두 개의 쓰레드에 의해 사용된다면, 캐시는 그 테이
블용으로 두 개의 엔트리를 가지게 된다. Section 7.4.8, “MySQL이 테이블을 열고 닫는 방법”을 참조할 것.
● FLUSH TABLES 명령문 또는 mysqladmin flush-tables 명령어는 한번도 사용되지 않은 테이블은 닫아 버리며 사용 중
에 있는 모든 테이블은 현재 실행 중에 있는 쓰레드가 종료가 되면 닫히게 끔 표시를 해 둔다. 이것은 사용 중에 있는 대부
분의 메모리를 효과적으로 해제 시키는 방법이다. FLUSH TABLES은 모든 테이블이 닫히기 전까지는 리턴되지 않는다.
ps 및 다른 시스템 상태 프로그램은 mysqld이 많은 메모리를 사용한다고 보고할 수도 있다. 이것은 서로 다른 메모리 주소 상에 있

는 쓰레드 스택에 의해 발생될 수도 있다. 예를 들면, Solaris 버전의 ps는 메모리를 사용하고 있는 스택 사이에서 사용되지 않는 메
모리를 계산한다. 여러분은 사용 가능한 스왑을 swap –s를 사용해서 검사 해보면 이것을 알아볼 수가 있게 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.5.6. MySQL의 DNS사용 방법
7.5. MySQL 서버 최적화 하기 새로운 클라이언트가 mysqld에 접속을 하게 되면, mysqld은 그 요청을 처리하기 위해 새로운 쓰레드를 만든다. 이 쓰레드는 우선
7.5.6 MySQL의 DNS사용 방법 호스트 이름 캐시에 있는 호스트 이름을 검사한다. 만약에 여기에 없다면, 쓰레드는 호스트 이름을 알아내기 위한 시도를 한다:
● 만일 OS가 gethostbyaddr_r() 와 gethostbyname_r() 호출을 지원한다면, 쓰레드는 이것들을 사용해서 호스트 이름을
알아내도록 한다.
● 만일 OS가 위와 같은 호출(thread-safe)을 지원하지 않는다면, 쓰레드는 mutex를 잠그고 대신에 gethostbyaddr() 및
gethostbyname()를 호출하게 된다. 이와 같은 경우가 되면, 다른 첫 번째 쓰레드가 mutex의 잠금을 해제하기 전까지는
어떠한 쓰레드도 호스트 이름 캐시에 들어 있지 않는 호스트 이름을 알아낼 수가 없게 된다.
여러분은 --skip-name-resolve 옵션을 사용해서 mysqld를 시작함으로써 DNS 호스트 이름 룩업(lookup)을 비 활성화 시킬
수가 있다. 하지만, 이럴 경우에는, 여러분은 MySQL 그랜트 테이블에 있는 IP번호만을 사용할 수가 있게 된다.
만일 여러분이 매우 느린 DNS와 많은 수의 호스트를 가지고 있다면, --skip-name-resolve를 사용해서 DNS를 비 활성화 시키

거나 또는 HOST_CACHE_SIZE의 값(디폴트 값: 128)을 늘린 다음에 mysqld를 재 컴파일 해주면 보다 좋은 성능을 얻을 수가
있게 된다.
--skip-host-cache 옵션을 사용해서 서버를 시작하면 호스트 이름 캐시를 비 활성화 시킬 수가 있다. 호스트 이름 캐시를 초기
화(clean) 시키기 위해서는, FLUSH HOSTS 명령문 또는 mysqladmin flush-hosts 명령어를 실행하면 된다.
TCP/IP 접속을 전체적으로 허용하지 않기 위해서는, mysqld을 --skip-networking 옵션을 사용해서 시작한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.6. 디스크 이슈
7. 최적화(Optimization) 7.6.1. 심볼릭 링크 사용하기

7.6. 디스크 이슈
7.6 디스크 이슈 ● 디스크 검색(Disk seek)은 성능 저하의 중요 원인을 제공한다. 이런 문제는 효과적인 캐싱 처리가 불가능할
정도로 데이터의 양이 많아지는 경우에 뚜렷하게 나타난다. 여러분이 다소 랜덤하게 대형 데이터 베이스를
7.6.1 심볼릭 링크 사용하기
접속하는 경우에는, 데이터를 읽기 위해서는 최소 1번의 디스크 검색과 데이터를 쓰기 위해서는 두 번의 디
7.6.1.1 유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하
기 스크 검색이 필요하다는 점을 확실히 알고 있어야 한다. 이런 문제를 최소화 하기 위해서는, 가능한 한 최소
의 디스크 검색이 이루어 지도록 해야 한다.
● 서로 별개의 디스크에 대한 파일 심볼릭 링크(symbolic link) 또는 디스크 스트라이핑(striping)을 사용해
7.6.1.3 윈도우에 있는 데이터 베이스에 대한 심볼릭 링크 사용하
기 서 사용 가능한 디스크 스핀들(spindle)의 숫자를 늘린다:
❍ 심볼릭 링크 사용하기
MyISAM 테이블의 경우, 인덱스 파일과 데이터 파일이 일반적으로 저장되어 있는 데이터 디렉토
리를 다른 디스크로 심볼릭 링크 시킨다. 이렇게 하면 디스크 검색 및 데이터 읽기 시간을 보다 개
선 시킬 수 있다. Section 7.6.1, “심볼릭 링크 사용하기”를 참조할 것.
❍ 스트라이핑
스트라이핑이란, 여러분이 디스크를 많이 가지고 있으며 첫 번째 블록은 첫 번째 디스크에 올려 놓

고, 두 번째 블록을 두 번째 디스크에, 세 번째는 세 번째 디스크에, 그리고 N 번째 블록은 (N
MOD 디스크 번호) 디스크에 놓는 것을 의미한다. 만일 일반적인 데이터의 크기가 스트라이프 크
기보다 작다면(또는 정확히 같다면), 보다 좋은 성능을 얻을 수가 있다. 스트라이핑은 OS 및 스트
라이프 크기에 매우 밀접하기 때문에, 여러분이 사용하는 어플리케이션을 서로 다른 스트라이프 크
기를 가지고 벤치 마크를 해보기 바란다. Section 7.1.5, “여러분 자신의 벤치 마크 사용하

:::MySQL Korea:::
스트라이핑의 속도 차이는 파라미터와 매우 밀접한 관련이 있다. 스트라이핑 파라미터와 디스크의

숫자를 어떻게 설정하느냐에 따라서, 여러분은 전체적인 차이를 가지게 된다.
● 안전성을 위해서는, 여러분은 RAID 0+1 (스트라이핑 및 미러링(striping plus mirroring))을 사용하고자
할 수도 있는데, 하지만 이와 같은 경우에는, 2 × N 개의 디스크 드라이브가 필요하게 된다.
● 리눅스의 경우, 여러분은 hdparm를 사용해서 디스크 인터페이스를 구성 한다면 보다 우수한 성능을 얻어낼
수가 있을 것이다. MySQL의 경우, 아래의 옵션을 사용하면 된다:
• hdparm -m 16 -d 1
이때 성능 향상과 안정성은 여러분이 사용하는 시스템의 하드웨어와 매우 밀접하게 된다 .
● 여러분은 또한 데이터 베이스가 사용하는 파일 시스템용 파라미터를 설정할 수도 있다:
만일 파일이 언제 최종적으로 접속이 되었는지 알 필요가 없다면 ( 이것은 실제로 데이터 베이스 서버에서
는 필요 없는 사항임), 여러분이 사용하는 파일 시스템을 -o noatime 옵션을 사용해서 마운트 한다. 이렇
게 하면 파일 시스템에 있는 inode에 최종 접속 시간을 업데이트 하지 않게 되며, 이에 따라서 디스크 검색
시간을 절약 시킬 수가 있게 된다.
대부분의 OS에서, 여러분은 파일 시스템을 -o async 옵션과 함께 마운트 시킴으로써 비 동기적인 업데이
트가 되도록 만들 수가 있다. 이렇게 하면, 보다 개선된 성능을 얻어낼 수가 있다. (리눅스에서는 이 플래그
가 디폴트임)

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 7.6.1. 심볼릭 링크 사용하기
7. 최적화(Optimization) 7.6.1.1. 유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

7.6. 디스크 이슈 7.6.1.2. 유닉스에 있는 테이블에 대한 심볼릭 링크 사용하기
7.6.1 심볼릭 링크 사용하기 7.6.1.3. 윈도우에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기
7.6.1.1 유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

여러분은 데이터 베이스 디렉토리에 있는 테이블과 데이터 베이스를 다른 위치로 이동 시킬 수가 있으며 이것들
은 새로운 위치를 가리키는 심볼릭 링크로 대체 시킬 수가 있다.
이렇게 하기 위한 권장 방법은 데이터 베이스를 다른 디스크로 간단히 심링크(symlink)시키는 것이다.
:::MySQL Korea:::
제목검색
7.6.1.1. 유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

7.6. 디스크 이슈 유닉스에서, 데이터 베이스를 심링크 시키는 방법은 우선 여유 공간이 있는 디스크에 디렉토리를 하나 만들고 MySQL 데이터 디렉
7.6.1 심볼릭 링크 사용하기 토리에서 이곳으로 심링크를 생성하면 된다.
7.6.1.1 유닉스에 있는 데이터 베이스에 대한 심볼

릭 링크 사용하기 shell> mkdir /dr1/databases/test
7.6.1.2 유닉스에 있는 테이블에 대한 심볼릭 링크

사용하기 shell> ln -s /dr1/databases/test /path/to/datadir
7.6.1.3 윈도우에 있는 데이터 베이스에 대한 심볼

MySQL은 하나의 디렉토리에서 여러 개의 데이터 베이스로 링크 시키는 것을 지원하지 않는다. 데이터 디렉토리를 하나의 심볼릭
릭 링크 사용하기
링크로 대체 시키는 것은 여러분이 데이터 베이스간에 심볼릭 링크를 만들지 않는 한 올바로 동작을 한다. MySQL의 데이터 디렉
토리 밑에 데이터 베이스 db1 를 가지고 있다고 가정하고, 그 다음에 심링크 db2를 만들어서 db1를 가리키도록 만들어 본다:
shell> cd /path/to/datadir
shell> ln -s db1 db2
그 결과, db1 안에 뿐만 아니라, db2에도 테이블 tbl_a가 나타난다. 만일 한 클라이언트가 db1.tbl_a 를 업데이트하고 다른 클라이
언트가 db2.tbl_a를 업데이트 한다면, 문제가 발생될 수 있다.
하지만, 만일 여러분이 정말로 이렇게 실행하고자 하다면, mysys/my_symlink.c의 소스 파일을 수정하면 되는데, 아래의 명령문
을 잘 살펴 보기 바란다:
if (!(MyFlags & MY_RESOLVE_LINK) ||
(!lstat(filename,&stat_buff) && S_ISLNK(stat_buff.st_mode)))

:::MySQL Korea:::
위의 것을 아래와 같이 수정한다:
if (1)

:::MySQL Korea:::
제목검색
7.6.1.2. 유닉스에 있는 테이블에 대한 심볼릭 링크 사용하기

7.6. 디스크 이슈 여러분은 realpath() 호출을 완벽하게 실행하지 못하는 시스템에서는 테이블을 심링크 시킬 수가 없다. (리눅스 및 솔라리스는
7.6.1 심볼릭 링크 사용하기 realpath()를 지원함). 여러분은 SHOW VARIABLES LIKE 'have_symlink' 명령문을 사용해서 지금 사용하고 있는 시스템이
7.6.1.1 유닉스에 있는 데이터 베이스에 대한 심볼 심볼릭 링크를 지원하는지를 검사해 볼 수가 있다.
릭 링크 사용하기
심링크는 MyISAM 테이블에 대해서만 전적으로 지원된다. 다른 스토리지 엔진을 위한 테이블이 사용하는 파일의 경우에는, 심볼
7.6.1.2 유닉스에 있는 테이블에 대한 심볼릭 링크
사용하기 릭 링크를 사용하고자 한다면 예상하지 못한 문제가 나올 수도 있다.
7.6.1.3 윈도우에 있는 데이터 베이스에 대한 심볼

릭 링크 사용하기 MyISAM 테이블을 위한 심볼릭 링크는 다음과 같이 처리가 된다:
● 데이터 디렉토리에서, 여러분은 항상 (.frm)포맷 파일, (.MYD)데이터 파일, 그리고 (.MYI)인덱스 파일을 가지고 있다.
데이터 파일과 인덱스 파일은 다른 어떤 곳으로도 이동 시킬 수가 있고 데이터 디렉토리에서 심링크로 대체 시킬 수가 있
다. 포맷 파일은 그렇게 할 수가 없다.
● 데이터 파일과 인덱스 파일은 서로 별개의 디렉토리에 독립적으로 심링크 시킬 수가 있다.
● 여러분은 CREATE TABLE에 DATA DIRECTORY 및 INDEX DIRECTORY 옵션을 사용하면 구동 중인 MySQL 서버
가 심링크를 실행하도록 지시할 수가 있다. Section 13.1.5, “CREATE TABLE 신텍스”를 참조. 다른 방법으로는,
mysqld이 구동 중이 아니라면, 명령어 라인에서 ln –s를 실행 시켜서 수동으로 심링크를 만들어 낼 수도 있다.
● Myisamchk는 심링크를 데이터 파일 또는 인덱스 파일로 대체 시킬 수가 없다. 이것은 심링크가 가리키고 있는 파일에서
직접 동작을 한다. 임시 파일은 데이터 파일 또는 인덱스 파일이 저장되어 있는 디렉토리 안에서 만들어진다.
● Note: 심링크를 사용하고 있는 테이블을 종료 시키게 되면, 심링크가 가리키고 있는 심링크 및 파일이 모두 종료된다.
● 만일 여러분이 ALTER TABLE ... RENAME를 사용해서 테이블 이름을 변경 시키고 이것을 다른 데이터 베이스로 이동
시키지 않으면, 데이터 베이스 디렉토리에 있는 심링크는 새로운 이름으로 바뀌게 되고 데이터 파일과 인덱스 파일은 이
에 따라서 이름이 바뀌게 된다.
● 만일 여러분이 ALTER TABLE ... RENAME를 사용해서 테이블을 다른 데이터 베이스로 이동 시킨다면, 테이블은 다른

:::MySQL Korea:::
데이터 베이스 디렉토리로 옮겨지게 된다. 구형의 심링크와 이것이 가리키고 있는 파일들은 삭제가 된다. 달리 말하면, 새
로운 테이블은 심링크가 되지 않는다.
● 만일 여러분이 심링크를 사용하지 않는다면, --skip-symbolic-links 옵션을 mysqld에 사용해서 아무도 mysqld를 사
용해서 데이터 디렉토리 밖에 있는 파일의 이름을 바꾸거나 종료 시킬 수 없도록 해야 한다.
테이블 심링크 연산은 아직까지은 지원하지 않는다:
● ALTER TABLE는 DATA DIRECTORY 및 INDEX DIRECTORY 테이블 옵션을 무시한다.

● BACKUP TABLE 및 RESTORE TABLE는 심볼릭 링크를 기대하지 않는다.
● .frm 파일은 절대로 심볼릭 링크가 될 수 없다 (앞에서 설명하였듯이, 데이터 파일과 인덱스 파일만이 심볼릭 링크가 가능
하다). 이를 시도하게 되면, 올바르지 못한 결과가 나온다. MySQL 데이터 베이스 밑에 데이터 베이스b1를 가지고 있으
며, 이 데이터 베이스 안에 테이블 tbl1를 가지고 있고, db1 디렉토리에서 tbl1를 가리키는 심링크 tbl2를 만들고자 한다
고 가정하자:
• shell> cd /path/to/datadir/db1
• shell> ln -s tbl1.frm tbl2.frm
• shell> ln -s tbl1.MYD tbl2.MYD
• shell> ln -s tbl1.MYI tbl2.MYI
하나의 쓰레드가 db1.tbl1를 읽고 다른 쓰레드가 db1.tbl2를 업데이트 한다면 문제가 발생한다:
❍ 쿼리 캐시는 “fooled”가 된다 (쿼리 캐시는 tbl1가 업데이트 되지 않았음을 알 수 없고, 따라서 이전 내용만을
리턴한다).
❍ tbl2 에 있는ALTER 명령문은 실패한다.

:::MySQL Korea:::
제목검색
7.6.1.3. 윈도우에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기

7.6. 디스크 이슈 심볼릭 링크는 모든 윈도우 서버에 대해서 디폴트로 활성화 되어 있다. 이것은 여러분이 서로 다른 디스크에 있는
7.6.1 심볼릭 링크 사용하기 데이터 베이스 디렉토리를 가져 올 수 있도록 해 준다. 이것은 유닉스에서의 데이터 베이스 심볼릭 링크가 동작하
7.6.1.1 유닉스에 있는 데이터 베이스에 대한 심볼릭 링크 사용하기 는 방식과 유사하지만, 링크 설정 과정은 다르게 된다. 만일 심볼릭 링크가 필요 없다면, --skip-symbolic-
links 옵션을 사용해서 이것을 비 활성화 시키면 된다.
윈도우에서는, 목적 디렉토리 경로를 가지고 있는 데이터 디렉토리에 파일을 하나 생성함으로써 MySQL에 대한
심볼릭 링크를 만든다. 이 파일은 db_name.sym이라는 이름이 되어야 하고, 여기에서 db_name는 데이터 베이스
의 이름이 된다.
MySQL 데이터 디렉토리가 C:￦mysql￦data이고 D:￦data￦foo에 데이터 베이스 foo가 있도록 한다고 가정하
자. 이에 대한 심볼릭 링크는 다음과 같이 만들어 진다:
1. D:￦data￦foo 디렉토리가 확실히 존재하는지 다시 한번 확인하고, 없다면 생성을 한다. 만일 이 디

렉토리에 이미 foo라는 이름의 데이터 베이스가 존재 한다면, 이것을 D:￦data로 이동 시킨다. 그렇지 않
으면, 심볼릭 링크가 효력을 갖지 못하게 된다. 데이터 베이스 디렉토리를 이동 시킬 때에는 서버가 구동
되지 않도록 해야만 문제가 발생되지 않는다.
2. 경로 이름 D:￦data￦foo￦를 가지는 텍스트 파일 C:￦mysql￦data￦foo.sym를 생성한다.
이렇게 하고 나면, 데이터 베이스 foo에서 생성된 모든 테이블은 D:￦data￦foo안에서 생성된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 8. 클라이언트 및 유틸리티 프로그램
8. 클라이언트 및 유틸리티 프로그램 8.1. 클라이언트 및 유틸리티 프로그램 개요
8 클라이언트 및 유틸리티 프로그램 8.2. myisamchk — MyISAM 테이블-관리 유틸리티
8.1 클라이언트 및 유틸리티 프로그램 개요 8.2.1. myisamchk 일반적인 옵션
8.2 myisamchk — MyISAM 테이블 관리 유틸리티 8.2.2. myisamchk 검사 옵션

8.2.3. myisamchk 복구 옵션
8.2.1 myisamchk 일반적인 옵션
8.2.4. 다른 myisamchk 옵션
8.2.2 myisamchk 검사 옵션
8.2.5. myisamchk 메모리 사용
8.2.3 myisamchk 복구(repair) 옵션
8.3. myisamlog — MyISAM 로그 파일 컨텐츠 표시하기
8.2.4 다른 myisamchk 옵션
8.4. myisampack — 압축된, 읽기 전용 MyISAM 테이블 만들기
8.2.5 myisamchk 메모리 사용
8.5. mysql — MySQL 명령어 라인 툴
8.3 myisamlog — MyISAM 로그 파일 컨텐츠 표시하기
8.5.1. mysql 옵션
8.4 myisampack — 압축된, 읽기 전용 MyISAM 테이블 만들기
8.5.2. mysql 명령어
8.5 mysql — MySQL 명령어 라인 툴 8.5.3. 텍스트 파일로부터 SQL 명령문 실행하기
8.5.1 mysql 옵션 8.5.4. mysql 팁
8.5.2 mysql 명령어 8.6. mysqlaccess — 접속 권한 검사를 위한 클라이언트
8.5.3 텍스트 파일로부터 SQL 명령문 실행하기 8.7. mysqladmin — MySQL 서버 관리를 위한 클라이언트
8.5.4 mysql 팁 8.8. mysqlbinlog — 바이너리 로그 파일 처리를 위한 유틸리티
8.5.4.1 쿼리 결과를 횡으로(Vertically) 출력하기 8.9. mysqlcheck — 테이블 관리 및 복구 프로그램
8.5.4.2 --safe-updates 옵션 사용하기 8.10. mysqldump — 데이터 베이스 백업 프로그램
8.5.4.3 mysql 자동-재 접속 비활성화 시키기 8.11. mysqlhotcopy — 데이터 베이스 백업 프로그램
8.6 mysqlaccess - 접속 권한을 검사하기 위한 클라이언트 8.12. mysqlimport — 데이터 임포트(Import)프로그램

8.13. mysqlshow — 데이터 베이스, 테이블, 그리고 컬럼 정보 표시하기
8.7 mysqladmin - MySQL 서버를 관리하기 위한 클라이언트
8.14. mysql_zap — 패턴과 일치하는 프로세스 죽이기(Kill)
8.8 mysqlbinlog - 바이너리 로그 파일을 처리하기 위한 유틸리티
8.15. perror — 에러 코드 설명

:::MySQL Korea:::
8.9 mysqlcheck - 테이블 관리(Maintenance) 및 복구 프로그램 8.16. replace — 스트링-대체 유틸리티
8.10 mysqldump - 데이터 베이스 백업 프로그램

데이터 베이스에 접속하거나 또는 관리 업무를 실행하기 위해 서버에 접속을 하는 클라이언트 프로그램은
8.11 mysqlhotcopy — 데이터 베이스 백업 프로그램
매우 많다. 다른 유틸리티들도 이러한 기능을 역시 할 수 있다. 하지만 이런 유틸리티들은 서버와 클라이언
8.12 mysqlimport — 데이터 임포트(Import) 프로그램
트로 접속을 하지 않은 채로 MySQL과 연관된 연산을 수행한다.
8.13 mysqlshow — 데이터 베이스, 테이블, 그리고 컬럼 정보를 보여 준다
이 장에서는 이러한 프로그램에 대해서 개괄적으로 설명을 하며 각각에 대해서는 별도의 장에서 자세히 설
8.14 mysql_zap — 패턴과 일치하는 프로세스 죽이기(Kill)
명하기로 한다. 각각의 프로그램에 대한 설명에는 호출 신텍스와 옵션들에 대한 설명이 포함된다.
8.15 perror — 에러 코드 설명
Chapter 4, MySQL 프로그램 사용하기 를 참조하면, 프로그램 호출 및 프로그램 옵션 지정에 대한 설명
8.16 replace — 스트링 대체 유틸리티
을 찾을 수 있을 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.1. 클라이언트 및 유틸리티 프로그램 개요
8. 클라이언트 및 유틸리티 프로그램 아래의 리스트는 MySQL 클라이언트 프로그램과 유틸리티에 대한 개략적인 설명이다:
8.1. 클라이언트 및 유틸리티 프로그램 개요
8.1 클라이언트 및 유틸리티 프로그램 개요 ● myisamchk
MyISAM 테이블을 설명, 검사, 최적화, 그리고 복구를 하는 유틸리티. Section 8.2, “myisamchk — MyISAM 테이블
관리 유틸리티”를 참조.
● myisamlog
MyISAM 로그 파일의 컨텐츠를 처리하는 유틸리티. Section 8.3, “myisamlog — MyISAM 로그 파일 컨텐츠 표시하
● myisampack
보다 작은 읽기 전용 테이블을 만들기 위해 MyISAM 테이블을 압축하는 유틸리티. Section 8.4, “myisampack — 압축

된, 읽기 전용 MyISAM 테이블 만들기”를 참조할 것.
● mysql
상호 교류적으로(interactively) SQL명령문을 입력하거나 또는 배치 모드(batch mode)의 파일에서 이 명령문들을 실행

시키기 위한 명령어 라인 툴. Section 8.5, “mysql — MySQL 명령어 라인 툴”을 참조.
● mysqlaccess
호스트 이름, 사용자 이름, 그리고 데이터 베이스 조합(combination)을 위한 접속 권한을 검사하는 스크립트.

:::MySQL Korea:::
Section 8.6, “mysqlaccess — 접속 권한 검사를 위한 클라이언트”를 참조할 것.
● mysqladmin
데이터 베이스 생성 또는 제거, 그랜트 테이블 다시 읽기, 테이블을 디스크로 플러시하기, 그리고 로그 파일 다시 열기 등
과 같은 관리 연산을 수행하는 클라이언트. Mysqladmin은 서버로부터 버전, 프로세스, 그리고 상태 정보를 추출할 때에
도 사용될 수 있다. Section 8.7, “mysqladmin — MySQL 서버 관리를 위한 클라이언트”를 참조할 것.
● mysqlbinlog
바이너리 로그에서 명령문을 읽어 오기 위한 유틸리티. 바이너리 로그 파일에 저장되어 있는 실행된 명령문의 로그는 크래
시 복구를 위해서도 사용될 수 있다. Section 8.8, “mysqlbinlog — 바이너리 로그 파일 처리를 위한 유틸리티”를 참조
할 것.
● mysqlcheck
테이블 검사, 복구, 분석, 그리고 최적화를 수행하는 테이블 관리 클라이언트. Section 8.9, “mysqlcheck — 테이블 관
리 및 복구 프로그램”을 참조할 것.
● mysqldump
MySQL 데이터 베이스를 SQL 명령문 또는 탭으로 분리된 텍스트 파일 형태로 파일안으로 덤프하는 클라이언트.
Section 8.10, “mysqldump — 데이터 베이스 백업 프로그램”을 참조할 것.
● mysqlhotcopy
서버가 구동되는 동안 MyISAM 테이블의 백업을 만드는 유틸리티. Section 8.11, “mysqlhotcopy — 데이터 베이스 백
업 프로그램”을 참조할 것.
● mysqlimport
LOAD DATA INFILE을 사용해서 텍스트 파일을 연관된 테이블로 임포트(import)하는 클라이언트. Section 8.12,

:::MySQL Korea:::
“mysqlimport — 데이터 임포트(Import) 프로그램”을 참조.
● mysqlshow
데이터 베이스, 테이블, 컬럼, 그리고 인덱스 정보를 표시하는 클라이언트. Section 8.13, “mysqlshow — 데이터 베이
스, 테이블, 그리고 컬럼 정보 표시하기”를 참조할 것.
● mysql_zap
패턴과 일치하는 프로세스를 죽이는(kill) 유틸리티. Section 8.14, “mysql_zap — 패턴과 일치하는 프로세스 죽이기
(Kill)”를 참조할 것.
● perror
시스템 또는 MySQL에러 코드의 의미를 표시하는 유틸리티. Section 8.15, “perror — 에러 코그 설명”을 참조할 것.
● replace
입력 텍스트에서 스트링 대체를 수행하는 유틸리티. Section 8.16, “replace — 스트링 대체 유틸리티”를 참조할 것.
MySQL AB는 관리를 위한 GUI 툴도 여러 가지를 제공하고 있다. 이러한 툴에 대해서는 Chapter 4, MySQL 프로그램 을 참조하
기 바란다.
각각의 MySQL 프로그램은 서로 다른 옵션들을 가지고 있다. 대부분의 프로그램은 --help 옵션을 가지고 있으며, 여러분은 이것
을 사용해서 각 프로그램이 사용할 수 있는 옵션들을 살펴볼 수가 있다. 예를 들면, mysql –help를 시도해 본다.
MySQL 클라이언트/서버 라이브러리를 사용해서 서버와 통신을 하는 클라이언트 프로그램은 아래와 같은 환경 변수를 사용한다:
MYSQL_UNIX_PORT The default Unix socket file; used for connections to localhost
MYSQL_TCP_PORT The default port number; used for TCP/IP connections
MYSQL_PWD The default password
MYSQL_DEBUG Debug trace options when debugging
TMPDIR The directory where temporary tables and files are created
MYSQL_PWD의 사용은 안전하지 못하다. Section 5.9.6, “패스워드 안전 유지하기”를 참조할 것.

:::MySQL Korea:::
여러분은 옵션 파일에서 또는 명령어 라인에서 옵션을 지정함으로써 모든 표준 프로그램에 대해서 환경 변수에 지정되어 있는 값
또는 디폴트 옵션 값을 덮어 씌울 수가(override) 있다. Section 4.3, “프로그램 옵션 지정하기”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.2. myisamchk — MyISAM 테이블 관리 유틸리티
8. 클라이언트 및 유틸리티 프로그램 8.2.1. myisamchk 일반적인 옵션

8.2. myisamchk — MyISAM 테이블 관리 유틸리티 8.2.2. myisamchk 검사 옵션
8.2 myisamchk — MyISAM 테이블 관리 유틸리티 8.2.3. myisamchk 복구 옵션
8.2.1 myisamchk 일반적인 옵션 8.2.4. 다른 myisamchk 옵션
8.2.2 myisamchk 검사 옵션 8.2.5. myisamchk 메모리 사용

myisamchk 유틸리티는 데이터 베이스 테이블 검사, 복구, 또는 최적화를 위한 정보를 가져온다. Myisamchk는 MyISAM
테이블과 함께 동작한다 (데이터 및 인덱스를 저장하기 위해 .MYD 및 .MYI 파일을 가지고 있는 테이블).
8.2.5 myisamchk 메모리 사용
myisamchk는 아래와 같이 호출한다:
shell> myisamchk [options] tbl_name ...
options은 myisamchk을 구동 시키고자 하는 사항을 나타낸다. 이 옵션들에 대해서는 다음 섹션에서 설명하기로 한다. 여러
분은 myisamchk --help을 호출해서 사용 가능한 옵션을 볼 수가 있다.
아무런 옵션을 사용하지 않으면, myisamchk은 디폴트 연산 형태로 테이블 검사만을 실행한다. 보다 많은 정보를 얻기 위해
서 또는 myisamchk로 하여금 정확한 연산을 하도록 만들기 위해서는, 다음 섹션에서 설명하는 방식으로 옵션을 지정하면
된다.
tbl_name은 여러분이 검사 또는 복구하고자 원하는 데이터 베이스 테이블이 된다. 만일 여러분이 데이터 베이스 디렉토리
가 아닌 다른 곳에서 myisamchk를 구동 시킨다면, 여러분은 반드시 데이터 베이스 디렉토리 경로를 지정해 주어야 하는데,
왜냐하면 myisamchk는 데이터 베이스가 어디에 있는지를 알지 못하기 때문이다. 사실, myisamchk는 여러분이 작업을 하
고 있는 파일이 데이터 베이스 디렉토리에 있는지에 대해서는 관여를 하지 않는다. 여러분은 데이터 베이스 테이블과 상응하
는 파일을 복사해서 다른 위치에 저장할 수 있으며 그곳에서 복구 연산을 실행할 수 있다.
여러분이 원하기만 한다면 myisamchk 명령어 라인에서 테이블 이름을 지정할 수가 있다. 또한 테이블의 인덱스 파일(.MYI
접미사를 갖고 있는 파일)을 명명함으로써 하나의 테이블을 지정할 수가 있다. 이를 통해서 여러분은 *.MYI를 사용해서 디
렉토리에 있는 모든 파일을 지정할 수 있게 된다. 예를 들면, 만일 여러분이 데이터 베이스 디렉토리에 있다면, 여러분은 아래
와 같이 그 디렉토리에 있는 모든 MyISAM 테이블을 검사할 수 있게 된다:

:::MySQL Korea:::
shell> myisamchk *.MYI

만일 여러분이 데이터 베이스 디렉토리에 없다면, 그 디렉토리의 경로를 지정해 줌으로써 거기에 있는 모든 테이블을 검사
할 수가 있게 된다:
shell> myisamchk /path/to/database_dir/*.MYI
또한, 여러분은 MySQL 데이터 디렉토리의 경로를 와일드 카드를 사용해서 지정해 주면 모든 데이터 베이스에 있는 모든 테
이블까지도 검사를 할 수 있게 된다:
shell> myisamchk /path/to/datadir/*/*.MYI
모든 MyISAM 테이블을 쉽고 빠르게 검사할 수 있는 권장 방법은 아래와 같다:
shell> myisamchk --silent --fast /path/to/datadir/*/*.MYI
만일 여러분이 모든 MyISAM 테이블을 검사하고 깨져 있는(corrupted) 테이블을 복구하고자 한다면, 아래의 명령어를 사
용하면 된다:
shell> myisamchk --silent --force --fast --update-state ￦
--key_buffer_size=64M --sort_buffer_size=64M ￦
--read_buffer_size=1M --write_buffer_size=1M ￦
/path/to/datadir/*/*.MYI
이 명령어는 여러분이 64MB 이상의 메모리 여유가 있다는 가정하에 실행된 것이다. myisamchk를 사용하는 메모리 할당
에 대해서는, Section 8.2.5, “myisamchk 메모리 사용”을 참조할 것.
여러분이 myisamchk를 구동시키는 동안에는 다른 어떤 프로그램도 동일 테이블을 사용하지 않도록 해야 한다. 그렇지 않으
면, 여러분이myisamchk를 구동 시킬 때, 아래와 같은 에러 메시지가 나오게 된다:
warning: clients are using or haven't closed the table properly
이것은 여러분이 다른 프로그램(mysqld 서버와 같은)이 업데이트를 아직 끝마치지 않았거나 또는 올바르게 닫히지가 않은
테이블을 검사하고자 시도한다는 것을 의미하는 것이다.
만일 mysqld이 구동 중이라면, 여러분은 FLUSH TABLES를 사용해서 메모리에 아직 남아 있는 테이블 수정 내용을 우선
플러시 하도록 만들어야 한다. 그런 후에, 여러분이 myisamchk를 사용하는 동안에는 다른 어떤 프로그램도 그 테이블을 사
용하지 못하도록 해야 한다. 이런 문제를 해소하기 위한 가장 쉬운 방법은 myisamchk를 사용해서 테이블을 검사하는 대신
에 CHECK TABLE를 사용하는 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.2.1. myisamchk 일반적인 옵션
8. 클라이언트 및 유틸리티 프로그램
8.2. myisamchk — MyISAM 테이블 관리 유 이 섹션에서는 myisamchk가 수행하는 모든 타입의 테이블 관리 연산을 위해서 사용될 수 있는 옵션들에 대해서 설명하기로 한
틸리티 다..
8.2.1 myisamchk 일반적인 옵션

● --help, -?
도움말을 표시하고 빠져 나옴.
● --debug=debug_options, -# debug_options
디버깅 로그를 작성한다. debug_options 스트링은 종종 'd:t:o,file_name'가 된다.
● --silent, -s
침묵 모드(Silent mode). 에러가 발생될 때에만 결과를 작성한다. 여러분은 –s를 두 번 사용해서 (-ss) myisamchk
로 하여금 아주 침묵하도록 만들 수가 있다.
● --verbose, -v
버보스(Verbose) 모드. 프로그램이 실행하고 있는 사항에 대해 자세한 정보를 표시한다. 이것은 -d 와 –e를 사용해서
실행시킬 수가 있다. –v를 여러 번 사용할 수도 있다 (-vv, -vvv).
● --version, -V
버전 정보를 표시한 후에 빠져 나온다.

:::MySQL Korea:::
● --wait, -w
테이블이 잠겨 있는 경우에 에러를 가지고 종료하는 대신에, 테이블이 풀릴 때까지 대기를 한다. 만일 여러분이 외부 잠금
을 비 활성화 한 상태로 mysqld를 구동 시킨다면, 테이블은 또 다른 myisamchk 명령어에 의해서만 잠겨질 수 있다는 점
을 알아두자.
여러분은 --var_name=value 신텍스를 사용해서 아래의 변수들을 설정할 수도 있다:
Variable Default Value
decode_bits 9
ft_max_word_len version-dependent
ft_min_word_len 4
ft_stopword_file built-in list
key_buffer_size 523264
myisam_block_size 1024
read_buffer_size 262136
sort_buffer_size 2097144
sort_key_blocks 16
stats_method nulls_unequal
write_buffer_size 262136
가능한 myisamchk 변수 및 이들 변수의 디폴트 값은 myisamchk --help를 사용해서 알아볼 수가 있다:
sort_buffer_size는 정렬 키에 의해 키가 복구될 때 사용되며, 여러분이 –recover를 사용하는 경우는 일반적인 경우가 된다.
key_buffer_size는 여러분이 --extend-check를 가지고 테이블을 검사하거나 또는 삽입 키 열에 의해서 키가 복구될(일반 삽입

의 경우) 때 사용된다. 키 버퍼를 통한 복구는 아래의 경우에 사용된다:

:::MySQL Korea:::
● 여러분이 --safe-recover를 사용한다.

● 키 정렬을 위해 필요로 한 임시 파일이 키 파일을 직접 생성할 때 보다 두 배 이상 크다. 이러한 경우는 여러분이 This is
often the case when you have large key values for CHAR, VARCHAR, 또는 TEXT 컬럼에 대한 키 값을 크게 가지
고 있을 때 종종 나타나는데, 그 이유는 정렬 연산이 완벽한 키 값을 저장할 필요가 있기 때문이다. 만일 여러분이 임시 공
간을 많이 가지고 있고 myisamchk로 하여금 정렬을 복구하도록 한다면, 여러분은 --sort-recover 옵션을 사용할 수가
있다.
키 버퍼를 통한 복구는 정렬을 사용하는 것 보다 디스크 공간을 덜 사용하지만, 속도는 더 느려지게 된다.
만일 여러분이 모다 빠른 복구를 하고자 한다면, key_buffer_size 와 sort_buffer_size 변수를 여러분이 사용 가능한 메모리의
25% 정도로 늘려 준다. 여러분은 이 두 변수를 모두 크게 만들 수가 있는데, 그 이유는 한번에 하나만 사용되기 때문이다.
myisam_block_size는 인덱스 블록용으로 사용되는 크기이다.
stats_method는--analyze 옵션이 주어졌을 때 인덱스 통계 수집을 위해서는 NULL 값을 어떻게 다루어야 하는지를 나타낸다.
이것은 myisam_stats_method 시스템 변수와 비슷하게 동작을 한다. 보다 자세한 정보는 Section 5.2.2, “Server System
Variables”, 그리고 Section 7.4.7, “MyISAM Index Statistics Collection”에 있는 myisam_stats_method에 대한 설명을 참
조하기 바란다. MySQL 5.0의 경우, stats_method는 MySQL 5.0.14에서 추가 되었다. 이 보다 오래된 버전의 경우, 통계 수집 방
식은 nulls_equal과 같다.
ft_min_word_len 및 ft_max_word_len은 FULLTEXT 인덱스에 대한 최소와 최대 문자 길이(word length)를 나타낸다.

ft_stopword_file은 스톱워드(stopword) 파일의 이름이 된다. 이것은 아래의 환경 아래에서 설정될 필요가 있다.
만일 여러분이 myisamchk를 사용해서 테이블 인덱스를 수정하는(예를 들면 복구 또는 분석) 연산을 실행하고자 한다면, 여러분
이 다른 것들을 지정하지 않는 한 최소 최대 문자 길이에 대한 디폴트 전체 텍스트 파라미터 및 스톱워드 파일을 사용해서
FULLTEXT 인덱스를 재 구축한다. 이것은 쿼리에서 문제가 발생한다.
이러한 파라미터들은 서버에만 알려져 있기 때문에 문제가 발생하는 것이다. 이것들은 MyISAM 인덱스 파일에는 저장되지 않는
다. 여러분이 서버에서 최소 최대 문자 길이 또는 스톱워드를 수정할 경우에 이러한 문제를 피하기 위해서는, 여러분이 mysqld용으
로 사용한 것과 같은 ft_min_word_len, ft_max_word_len, 그리고 ft_stopword_file값을 myisamchk에 지정해 주면 된다. 예를
들면, 만일 여러분이 최소 문자 길이를 3으로 설정을 했다면, myisamchk를 사용해서 아래와 같이 테이블을 복구할 수가 있다:

:::MySQL Korea:::
shell> myisamchk --recover --ft_min_word_len=3 tbl_name.MYI
myisamchk 및 서버가 전체 텍스트 파라미터에 대해서 동일한 값을 확실하게 사용하도록 하기 위해서는, 옵션 파일의 [mysqld]
및 [myisamchk] 섹션 모두에 이것을 지정해 준다:
[mysqld]
ft_min_word_len=3
[myisamchk]
ft_min_word_len=3
myisamchk를 사용할 수 있는 다른 방법으로는 REPAIR TABLE, ANALYZE TABLE, OPTIMIZE TABLE, 또는 ALTER
TABLE를 사용하는 것이다. 이러한 명령문들은 서버가 실행하는 것이며, 서버는 올바른 전체 텍스트 파라미터 값을 알게 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.2.2. myisamchk 검사 옵션
8.2. myisamchk — MyISAM 테이블 관리 유틸리티 Myisamchk은 테이블 검사 연산에 대해서 아래의 옵션들을 지원한다:
8.2.2 myisamchk 검사 옵션
● --check, -c
에러에 대해서 테이블을 검사한다. 여러분이 명확하게 다른 연산 타입을 지정하지 않을 경우에는 디폴트로 이것을
실행한다.
● --check-only-changed, -C
마지막 검사를 한 이후에 변경된 테이블만 검사한다.
● --extend-check, -e
테이블을 매우 철저하게 검사한다. 테이블이 많은 인덱스를 가지고 있는 경우에는 속도가 매우 느리게 된다. 이 옵
션은 아주 특별한 경우에만 사용해야 한다. 일반적으로는, myisamchk 또는 myisamchk --medium-check이 테
이블에 에러가 있는지를 검사할 때 사용된다.
만일 여러분이 --extend-check를 사용하고 메모리가 많이 있다면, key_buffer_size 변수의 값을 크게 해 줌으
로써 복구 연산을 보다 빠르게 진행 시킬 수가 있다.
● --fast, -F
올바르게 닫히지 않은 테이블만 검사한다.
● --force, -f

:::MySQL Korea:::
myisamchk가 테이블에서 에러를 발견하게 되면, 자동으로 복구 연산을 실시한다. 복구 타입은 --recover 또는
-r 옵션을 가지고 지정한 것과 같게 된다.
● --information, -i
검사를 받은 테이블의 정보를 표시해 준다.
● --medium-check, -m
--extend-check 연산 보다는 빠르게 검사를 진행한다. 이것은 모든 에러의 99.99%를 찾아주며, 대부분의 경
우 매우 좋은 방법이 된다.
● --read-only, -T
검사된 것으로 테이블을 표시하지 않는다. 이 옵션은 잠금을 사용하지 않는 다른 어플리케이션이 사용하고 있는 테
이블을 검사하기 위해 myisamchk를 사용하는 경우에 유용하다.
● --update-state, -U
테이블을 검사해서 그 테이블이 깨졌는지를 알려주기 위해 정보를 .MYI 파일에 저장한다. 이 옵션은 --check-
only-changed 옵션의 효과를 전체적으로 얻기 위해서는 사용할 수 있지만, 만일을 전체적 mysqld 서버가 그 테이
블을 사용하고 있고 여러분이 외부 잠금을 비 활성화 시킨 채로 구동 시키는 경우에는 이 옵션을 사용할 수 없다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.2.3. myisamchk 복구(repair) 옵션
8.2. myisamchk — MyISAM 테이블 관리 유틸리티 myisamchk은 테이블 복구 연산을 위해서 아래의 옵션들을 지원한다:

● --backup, -B
.MYD 파일의 백업을 file_name-time.BAK 형태로 만든다.
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이터 및 정렬을 위해 사용된 문자 셋”을 참조할 것.
● --correct-checksum
테이블에 대한 체크섬(checksum)을 교정한다(correct).
● --data-file-length=len, -D len
데이터 파일의 최대 길이 (데이터 파일이 “가득 찰(full)” 경우 이것을 재 생성할 때).
● --extend-check, -e
데이터 파일로부터 가능한 모든 열을 복구하기 위한 시도를 한다. 일반적인 경우, 이것은 많은 수의 가비지
(garbage) 열도 같이 찾게 된다. 꼭 필요한 경우가 아니면 이 옵션을 사용하지 않도록 한다.
● --force, -f

:::MySQL Korea:::
종료(aborting)하는 대신에 구형 인터미디어트(old intermediate) 파일(tbl_name.TMD과 같은 이름을 가지고 있

는 파일)을 겹쳐 쓴다 (files with names like).
● --keys-used=val, -k val
Myisamchk의 경우, 이 옵션 값은 업데이트가 되는 인덱스를 가리키는 비트-값(bit-value)가 된다. 옵션의 각 바

이너리 비트 값은 테이블 인덱스에 대응이 되고, 이 때 첫 번째 인덱스는 비트 0이 된다. 0의 옵션 값은 모든 인덱스
의 업데이트를 비 활성화 시키는데, 이것은 보다 빠른 삽입을 실행하기 위해서 사용할 수가 있다. 비 활성화된 인덱
스는 myisamchk –r를 사용해서 다시 활성화 시킬 수가 있다.
● --max-record-length=len
myisamchk이 열을 가지게 위해 메모리를 할당하지 못하는 경우에는, 주어진 길이보다 긴 열은 건너 띄도록 한다.
● --parallel-recover, -p
Uses the same technique as -r 및 –n과 같은 형태의 기법을 사용하지만, 다른 쓰레드를 사요해서 모든 키를 병
렬로 생성한다. 아직은 베타 테스트 중인 코드이다.
● --quick, -q
데이터 파일을 수정하지 않음으로써 보다 빠른 복구를 실행한다. 이 옵션을 두 번 지정해 주면 myisamchk로 하여

금 키가 중복되는 경우에는 원래의 데이터 파일을 수정하도록 만든다.
● --recover, -r
유니크(unique)하지 않은 유니크 키를 제외하고는 거의 모든 문제를 해결할 수 있는 복구를 실행한다. 만일 여러분

이 테이블 하나를 복구하고자 한다면, 이 옵션을 먼저 시도해 보도록 한다. –recover를 사용해서는 테이블이 복구
될 수 없다고 myisamchk가 보고를 하는 경우에만 --safe-recover를 시도한다. (--recover가 실패하는 경우
에도, 데이터 파일은 피해를 입지 않은 채로 남아 있게 된다.)
만일 여러분이 메모리를 많이 가지고 있다면, sort_buffer_size의 크기를 늘리도록 한다.

:::MySQL Korea:::
● --safe-recover, -o
모든 열을 순서대로 읽고 찾은 열을 기반으로 모든 인덱스 트리를 업데이트하는 구형 방식을사용해서 복구를 진행

한다. 이 방식은 –recover 방식 보다는 매우 느리게 실행되지만, –recover이 처리하지 못하는 특이한 경우에 대
해서도 복구를 처리할 수가 있다. 이 복구 방식은 –recover 보다는 디스크 공간을 덜 사용하기도 한다. 일반적으
로, 여러분은 –recover를 사용해서 우선 복구를 실행하고, 그 다음에 –recover가 실패하는 경우에만 --safe-
recover를 실행한다.
만일 여러분이 메모리를 많이 가지고 있다면, key_buffer_size의 값을 늘리도록 한다.
● --set-character-set=name
테이블 인덱스가 사용한 문자 셋을 변경 시킨다. 이 옵션은 5.0.3 이후에는 --set-collation 로 대체 되었다.
● --set-collation=name
정렬 테이블 인덱스를 위해 사용할 콜레션(collation)을 지정한다. 문자 셋 이름은 콜레션 이름의 처음 부분의 의미

를 가진다. 이 옵션은 MySQL 5.0.3에서 추가 되었다.
● --sort-recover, -n
Myisamchk로 하여금 임시 파일이 비록 클 경우에라도 키를 해석하기 위해서는 정렬을 사용하게끔 만든다.
● --tmpdir=path, -t path
정렬용 임시 파일을 위해서 사용되는 디렉토리의 경로. 만일 이것이 설정되지 않으면, myisamchk은 TMPDIR 환
경 변수의 값을 사용하게 된다. tmpdir은 임시 파일을 생성하기 위한 라운드-로빈 방식으로 연속적으로 사용된 디
렉토리의 경로 리스트로 설정될 수 있다. 디렉토리 이름간의 구분 문자는 유닉스에서는 콜론 (‘:’)이고 윈도우,
넷웨어, 그리고 OS/2에서는 세미 콜론 (‘;’)이 된다.
● --unpack, -u

:::MySQL Korea:::
myisampack를 사용해서 패킹이 된 테이블을 푼다(unpack).

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.2.4. 다른 myisamchk 옵션
8.2. myisamchk — MyISAM 테이블 관리 유틸리티 Myisamchk은 테이블 검사 및 복구 이외의 동작에 대해서는 아래의 옵션을 지원한다:
● --analyze, -a
키 값의 분포도(distribution)를 분석한다. 이것은 테이블 및 여기에 사용되는 인덱스를 보다 잘 선택하기 위해서 조

인 옵티마이저(join optimizer)를 활성화 시킴으로써 조인의 성능을 개선시켜 준다. 키 분포도에 대한 정보를 얻기
위해서는, myisamchk --description --verbose tbl_name 명령어 또는 SHOW INDEX FROM tbl_name 명령
문을 사용한다.
● --block-search=offset, -b offset
주어진 오프셋에 속해 있는 레코드를 찾는다.
● --description, -d
테이블에 대한 상세정보를 알려 준다.
● --set-auto-increment[=value], -A[value]
새로운 레코드에 대한 AUTO_INCREMENT 번호 매기기(numbering)가 주어진 값에서부터 시작되도록 만든다

(만일 AUTO_INCREMENT 값이 주어진 값보다 큰 값을 가지고 이미 존재한다면, 이것보다 보다 앞선 값을 가지
도록 한다). 만일 value가 지정되지 않으면, 새로운 레코드에 대한 AUTO_INCREMENT 번호는 테이블에서 현재
가장 큰 값보다 하나가 더 많은 값으로 시작을 한다.

:::MySQL Korea:::
● --sort-index, -S
내림 차순(high-low order)으로 트리 블록을 정렬한다. 이것은 검색을 최적화 시키고 인덱스를 사용하는 테이블
스캔을 보다 빠르게 실행한다.
● --sort-records=N, -R N
특정 인덱스에 따라서 레코드를 정렬시킨다. 이것은 데이터를 보다 지역적으로(localized) 만들고 이 인덱스를 사용

하는 범위-기반 SELECT 및 ORDER BY 연산을 빠르게 만들어 주기도 한다. (여러분이 이 옵션을 처음으로 사용
해서 테이블을 정렬한다면, 아마도 속도가 느리게 될 것이다.) 테이블의 인덱스 번호를 알아보기 위해서는, SHOW
INDEX를 사용하며, 이것은 myisamchk가 바라보는 것과 같은 순서로 테이블 인덱스를 표시한다. 인덱스는 1로부
터 시작되어서 번호가 매겨진다.
만일 키가 패킹되지 않으면 (PACK_KEYS=0)), 키는 똑 같은 길이를 가지면, 따라서 myisamchk가 정렬을 하고
레코드를 이동시킬 때에는, 인덱스에 있는 레코드 오프셋을 덮어 쓰게 된다. 만일 키가 패킹이 되면
(PACK_KEYS=1), myisamchk은 키 블록을 우선 풀어야 하면, 그 다음에 인덱스를 재 생성하고 키 블록을 다시
패킹한다. (이와 같은 경우, 인덱스 재 생성은 각 인덱스에 대한 오프셋 업데이트 보다 빠르게 된다.)

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.2.5. myisamchk 메모리 사용
8.2. myisamchk — MyISAM 테이블 관리 유 여러분이 myisamchk 구동 시킬 때에는 메모리 할당이 매우 중요하다. Myisamchk은 메모리 관련 변수가 설정되면 더 이상 메모
틸리티 리를 사용하지 않게 된다. 만일 여러분이 매우 큰 테이블에서 myisamchk를 사용하고자 한다면, 우선 얼마나 많은 메모리를 사용
8.2.5 myisamchk 메모리 사용 할 지를 결정해야 한다. 디폴트는 복구를 실행하기 위해서 약 3MB를 사용하는 것이다. 이 보다 큰 값을 사용한다면, 여러분은
myisamchk 실행 속도를 보다 빠르게 만들 수가 있게 된다. 예를 들면, 만일 여러분이 32MB이상의 메모리를 가지고 있다면, 여러
분은 아래와 같이 옵션을 사용할 수 있을 것이다:
shell> myisamchk --sort_buffer_size=16M --key_buffer_size=16M ￦
--read_buffer_size=1M --write_buffer_size=1M ...
--sort_buffer_size=16M를 사용하는 것이 대부분의 경우에 충분할 것이다.
myisamchk은 TMPDIR에 있는 임시 파일을 사용한다는 점을 알아 둔다. 만일 TMPDIR가 메모리 파일 시스템을 가리킨다면, 아

마도 메모리 에러가 발생할 것이다. 이런 일이 발생한다면, 좀더 많은 공간을 가지고 있는 파일 시스템에 있는 디렉토리를 지정하
기 위해서 myisamchk를 --tmpdir=path 옵션과 함께 구동 시킨다.
복구를 할 경우, myisamchk는 디스크 공간을 많이 필요로 한다:
● 데이터 파일의 두 배 크기가 필요하다 (원본 파일과 복사본). 만일 여러분이 --quick를 사용해서 복구를 한다면, 이 공간
은 필요 없게 된다; 이와 같은 경우에는, 인덱스 파일만이 재 생성된다. 이 공간은 원본 데이터 파일과 동일한 파일 시스템
에서 필요하게 된다! (복사본은 원본 파일의 디렉토리와 동일한 곳에 생성된다.)
● 이전 인덱스 파일을 대체하는 새로운 인덱스 파일을 위한 공간. 이전(구형) 인덱스 파일은 복구 동작이 시작될 때 잘려 나
간다 (truncated). 이 공간은 원본 인덱스 파일과 동일한 파일 시스템에서 필요하게 된다!
● --recover 또는 --sort-recover (--safe-recover를 사용할 때가 아님)를 사용할 때에는, 정렬 버퍼용 공간이 필요

:::MySQL Korea:::
하게 된다. 아래의 공식을 사용해서 필요한 공간을 계산하면 된다:
• (largest_key + row_pointer_length) × number_of_rows × 2
여러분은 키 길이와 row_pointer_length의 길이를 myisamchk -dv tbl_name를 사용해서 검사할 수가 있다. 이 공간은
임시 디렉토리에 할당된다 (TMPDIR 또는 --tmpdir=path에 의해 지정됨).
만일 여러분이 복구를 하는 과정 중에 디스크 공간에 관련된 문제를 가지게 되면, --recover를 사용하지 말고 --safe-recover
를 시도해 보기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.3. myisamlog — MyISAM 로그 파일 컨텐츠 표시하기
8. 클라이언트 및 유틸리티 프로그램 myisamlog는 MyISAM의 로그 파일 컨텐츠를 처리한다.

8.3. myisamlog — MyISAM 로그 파일 컨텐츠 표시하기 아래와 같이 myisamlog를 호출한다:
8.3 myisamlog — MyISAM 로그 파일 컨텐츠 표시하기 shell> myisamlog [options] [log_file [tbl_name] ...]
디폴트 연산은 업데이트다 (-u). 만일 복구(recovery)를 실행하면 (-r), 모든 쓰기(all write)와 가능한 업데이트
(possibly update) 그리고 삭제가 실행되고 에러는 카운트만 된다. 디폴트 로그 파일 이름은, 아무런 log_file 인수도 주
어지지 않을 경우라면, myisam.log이 된다. 만일 테이블 이름을 명령어 라인에서 주게 되면, 그 테이블만이 업데이트가
된다.
myisamlog는 아래의 옵션들을 지원한다:
● -?, -I
도움말 메시지를 출력하고 빠져 나온다.
● -c N
N 명령어만을 실행한다.
● -f N
오픈 파일의 최대 숫자를 지정한다.
● -i
빠져 나오기 전에 추가적인 정보를 출력한다.

:::MySQL Korea:::
● -o offset
시작 오프셋을 지정한다.
● -p N
경로에서 N 요소(components)를 제거한다.
● -r
복구 동작을 실행한다.
● -R record_pos_file record_pos
레코드 위치 파일 및 레코드 위치를 지정한다.
● -u
업데이트 연산을 실행한다.
● -v
버보스 모드(Verbose mode). 프로그램이 진행한 내용을 자세히 보여준다. 보다 많은 정보를 얻고자 한다면
이 옵션을 여러 번 사용할 수 있다.
● -w write_file
쓰기 파일을 지정한다.
● -V
버전 정보를 보여준다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.4. myisampack — 압축된, 읽기 전용 MyISAM 테이블 만들기
8. 클라이언트 및 유틸리티 프로그램 myisampack 유틸리티는 MyISAM 테이블을 압축한다. Myisampack은 테이블에 있는 컬럼을 개별적으로 압축한다.
8.4. myisampack — 압축된, 읽기 전용 MyISAM 테이블 일반적으로, myisampack는 데이터 파일을 40%-70% 정도 압축을 한다.
만들기 테이블이 나중에 사용될 때에는, 서버는 압축을 해제하고자 하는 컬럼의 정보를 메모리로 읽어 온다. 이렇게 하면 각
8.4 myisampack — 압축된, 읽기 전용 MyISAM 테이블 만들 각의 열에 접속을 할 때 보다 성능이 좋아 지는데, 그 이유는 여러분은 정확히 하나의 열만을 압축 해제할 수 있기 때문
기 이다.
MySQL은 압축된 테이블에 메모리 매핑을 실행할 때 mmap()를 사용한다. 만일 mmap()이 동작을 하지 않는다면,
MySQL은 일반적인 읽기/쓰기 동작을 실행한다.
아래의 사항에 대해서는 주의를 하기 바란다:
● 만일 mysqld 서버가 외부 잠금이 비활성화 된 상태로 호출되었다면, 패킹 프로세스가 진행되는 동안 서버가

그 테이블을 업데이트 한다면 myisampack를 호출하는 것은 좋은 방법이 아니다. 서버를 종료 시킨 후에 테이
블을 압축하는 것이 가장 안전하다.
● 테이블은 압축이 된 후에는, 읽기 전용이 된다.
● Myisampack은 BLOB 또는 TEXT 컬럼을 압축할 수 있다. (ISAM 테이블에 대한 이전의 pack_isam 프로그
램은 이러한 기능이 없었다.)
Myisampack를 아래와 같이 호출한다:

shell> myisampack [options] file_name ...
각각의 파일 이름 인수는 인덱스 (.MYI) 파일 이름 형태이어야 한다. 만일 여러분이 데이터 베이스 디렉토리에 있지 않
으면, 그 파일에 대한 경로 이름을 지정해 주어야 한다. .MYI 확장자는 생략 가능하다.
여러분이 myisampack를 사용해서 테이블을 압축한 후에는, 이 테이블의 인덱스를 재 구축하기 위해서 myisamchk
–rq를 사용해야 한다. Section 8.2, “myisamchk — MyISAM 테이블-관리 유틸리티”를 참조할 것.
Myisampack는 아래의 옵션을 지원한다:

:::MySQL Korea:::
● --help, -?
도움말 메시지를 표시하고 빠져 나옴.
● --backup, -b
tbl_name.OLD를 사용해서 각 케이블의 데이터 파일 백업을 만든다.
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”을 참조할

것.
디버깅 로그를 작성한다. debug_options 스트링은 종종 'd:t:o,file_name'가 된다.
● --force, -f
압축된 테이블이 원본 보다 크게 되거나 또는 myisampack 의 초기 호출로부터 생긴 중간 파일

(intermediate file)이 존재하더라도 압축을 실행한다. (myisampack는 테이블을 압축하는 동안에 데이터 베
이스 디렉토리에 tbl_name.TMD라는 이름의 중간 파일을 생성한다. 만일 여러분이 myisampack를 죽이더라
도, .TMD 파일은 제거되지 않는다.) 일반적인 경우, myisampack는 tbl_name.TMD 파일이 존재하는 것을
알게 되면 에러를 발생시키면서 연산을 종료하게 된다. --force를 사용하면, myisampack는 테이블을 계속
압축한다.
● --join=big_tbl_name, -j big_tbl_name
명령어 라인에서 이름을 지정한 모든 테이블을 하나의 테이블 big_tbl_name로 조인(join)시킨다. 결합이 되
어야 할 모든 테이블은 반드시 동일한(identical) 구조를 가지고 있어야 한다 (같은 컬럼 이름과 타입,같은 인
덱스, 등등).

:::MySQL Korea:::
● --packlength=len, -p len
열 길이 스토리지 엔진을 바이트 단위로 지정한다. 그 값은 1, 2, 또는 3이 되어야 한다. myisampack는 1, 2,

또는 3 바이트 길이의 포인터를 가지고서 모든 열을 저장한다. 대부분의 정상적인 경우에, myisampack는 파
일을 압축하기 전에 올바른 길이 값을 알아낼 수가 있지만, 압축이 진행되는 동안에는 보다 짧은 길이를 사용
한다는 점을 알아두자. 이와 같은 경우, myisampack는 여러분이 같은 파일을 다음에 압축할 때에는 보다 짧
은 길이 열을 사용할 수 있다는 점을 알려 준다.
● --silent, -s
침묵 모드(Silent mode). 에러가 발생될 경우에만 결과를 보여준다.
● --test, -t
실제로 압축을 하는 것이 아니라, 테스트로만 실행한다.
● --tmpdir=path, -T path
myisamchk가 임시 파일을 생성하는 위치의 디렉토리를 사용한다.
● --verbose, -v
버보스 모드(Verbose mode). 압축 연산과 그 결과에 대한 진행 과정 정보를 작성한다.
● --version, -V
버전 정보를 출력하고 빠져 나온다.
● --wait, -w
테이블이 사용 중에 있다면 대기를 하고 재 시도를 한다. 만일 mysqld 서버가 외부 잠금이 비 활성화된 채로

호출이 된다면, 압축이 진행되는 동안 서버가 그 테이블을 업데이트 하는 경우에는 myisampack를 호출하는

:::MySQL Korea:::
것은 좋은 방법이 아니다.
아래의 명령어들은 전형적인 테이블 압축 세션을 보여 주는 것들이다:
shell> ls -l station.*
-rw-rw-r-- 1 monty my 994128 Apr 17 19:00 station.MYD
-rw-rw-r-- 1 monty my 53248 Apr 17 19:00 station.MYI
-rw-rw-r-- 1 monty my 5767 Apr 17 19:00 station.frm
shell> myisamchk -dvv station
MyISAM file: station

Isam-version: 2
Creation time: 1996-03-13 10:08:58
Recover time: 1997-02-02 3:06:43
Recordlength: 834
table description:
Key Start Len Index Type Root Blocksize Rec/key
1 2 4 unique unsigned long 1024 1024 1
2 32 30 multip. text 10240 1024 1
Field Start Length Type

1 1 1
2 2 4
3 6 4
4 10 1
5 11 20

:::MySQL Korea:::
6 31 1
7 32 30
8 62 35
9 97 35
10 132 35
11 167 4
12 171 16
13 187 35
14 222 4
15 226 16
16 242 20
17 262 20
18 282 20
19 302 30
20 332 4
21 336 4
22 340 1
23 341 8
24 349 8
25 357 8
26 365 2
27 367 2
28 369 4
29 373 4
30 377 1
31 378 2
32 380 8
33 388 4
34 392 4
35 396 4

:::MySQL Korea:::
36 400 4
37 404 1
38 405 4
39 409 4
40 413 4
41 417 4
42 421 4
43 425 4
44 429 20
45 449 30
46 479 1
47 480 1
48 481 79
49 560 79
50 639 79
51 718 79
52 797 8
53 805 1
54 806 1
55 807 20
56 827 4
57 831 4
shell> myisampack station.MYI

Compressing station.MYI: (1192 records)
- Calculating statistics
normal: 20 empty-space: 16 empty-zero: 12 empty-fill: 11

pre-space: 0 end-space: 12 table-lookups: 5 zero: 7
Original trees: 57 After join: 17
- Compressing file

:::MySQL Korea:::
87.14%
Remember to run myisamchk -rq on compressed tables
shell> ls -l station.*
-rw-rw-r-- 1 monty my 127874 Apr 17 19:00 station.MYD
-rw-rw-r-- 1 monty my 55296 Apr 17 19:04 station.MYI
-rw-rw-r-- 1 monty my 5767 Apr 17 19:00 station.frm
shell> myisamchk -dvv station
MyISAM file: station

Isam-version: 2
Creation time: 1996-03-13 10:08:58
Recover time: 1997-04-17 19:04:26
Recordlength: 834
Record format: Compressed
table description:
Key Start Len Index Type Root Blocksize Rec/key
1 2 4 unique unsigned long 10240 1024 1
2 32 30 multip. text 54272 1024 1
Field Start Length Type Huff tree Bits

1 1 1 constant 1 0
2 2 4 zerofill(1) 2 9
3 6 4 no zeros, zerofill(1) 2 9
4 10 1 3 9

:::MySQL Korea:::
5 11 20 table-lookup 4 0
6 31 1 3 9
7 32 30 no endspace, not_always 5 9
8 62 35 no endspace, not_always, no empty 6 9
9 97 35 no empty 7 9
11 167 4 zerofill(1) 2 9
14 222 4 zerofill(1) 2 9
16 242 20 no endspace, not_always 8 9
17 262 20 no endspace, no empty 8 9
20 332 4 always zero 2 9
22 340 1 3 9
26 365 2 2 9
30 377 1 3 9
32 380 8 no zeros 2 9

:::MySQL Korea:::

37 404 1 2 9
38 405 4 no zeros 2 9
40 413 4 no zeros 2 9
42 421 4 no zeros 2 9
44 429 20 no empty 3 9
45 449 30 no empty 3 9
46 479 1 14 4
47 480 1 14 4
49 560 79 no empty 2 9
50 639 79 no empty 2 9
51 718 79 no endspace 16 9
52 797 8 no empty 2 9
53 805 1 17 1
54 806 1 3 9
55 807 20 no empty 3 9
myisampack는 아래와 같은 정보를 보여준다:
● normal
추가적인 압축이 사용되지 않은 컬럼 숫자.
● empty-space
빈 공간만을 가지고 있는 컬럼의 숫자. 이것은 1 비트가 된다.

:::MySQL Korea:::
● empty-zero
바이너리 0 값만을 가지고 있는 컬럼의 숫자. 이것은 1 비트가 된다.
● empty-fill
자신의 타입의 전체 바이트 범위를 갖추지 못하는 정수 컬럼의 숫자. 이것은 보다 작은 타입으로 변경된다. 예
를 들면, BIGINT 컬럼(8 바이트)은 자신의 모든 값이 -128 에서 127 사이의 범위에 있다면 TINYINT 컬럼
(1 바이트) 형태로 저장된다.
● pre-space
스페이스가 앞에 두고(leading space) 저장된 10진 컬럼의 숫자. 이와 같은 경우, 각각의 값은 앞에 나오는
스페이스의 숫자를 카운트 한다.
● end-space
맨 뒤에 스페이스가 있는 컬럼의 숫자. 이와 같은 경우, 각각의 값은 맨 뒤에 나오는 스페이스의 숫자를 카운

트 한 값이 된다.
● table-lookup
서로 다른 값이 작은 것만을 가지고 있는 컬럼이며, 호프만(Huffman)식 압축을 하기 전에 ENUM으로 변환된

다.
● zero
모든 값이 0인 컬럼의 숫자.
● Original trees

:::MySQL Korea:::
호프만 트리(Huffman tree)의 초기 숫자.
● After join
헤더 스페이스(header space)를 저장하기 위해 트리를 조인(joining)한 후에 남게 되는 정확한 호프만 트리

의 숫자.
테이블이 압축이 된 후에는, myisamchk –dvv는 각 컬럼에 대해서 부가적인 내용을 출력한다:
● Type
데이터 타입. 그 값으로는 아래의 디스크립터(descriptor)중의 하나를 갖게 된다:
❍ constant
동일한 값을 가지는 모든 열.
❍ no endspace
엔드스페이스(endspace)는 저장하지 않는다.
❍ no endspace, not_always
엔드스페이스를 저장하지 않고 모든 값에 대해서 엔드스페이스를 압축하지 않는다.
❍ no endspace, no empty
엔드스페이스를 저장하지 않는다. 엠프티(empty) 값은 저장하지 않는다.
❍ table-lookup
컬럼이 ENUM로 변환된다.

:::MySQL Korea:::
❍ zerofill(N)
값 안에서 가장 중요한 N 바이트는 항상 0 이며 저장되지 않는다.
❍ no zeros
0을 저장하지 않는다.
❍ always zero
0 값은 1 비트를 사용해서 저장한다.
● Huff tree
컬럼과 관련이 있는 호프만 트리의 숫자.
● Bits
호프만 트리에서 사용된 비트 수.

여러분이 myisampack을 구동시킨 후에는, 반드시 myisamchk를 구동 시켜서 모든 인덱스를 재 구축해야 한다. 이 시
점이 되면, 여러분은 인덱스 블록을 정렬할 수 있게 되고 보다 효과적으로 MySQL 옵티마이저가 동작하는 데 필요한
통계치를 생성할 수도 있게 된다:
shell> myisamchk -rq --sort-index --analyze tbl_name.MYI
압축된 테이블을 MySQL데이터 베이스 디렉토리에 설치를 한 후에는, mysqld로 하여금 새로운 테이블을 시작하도록
만들기 위해서 mysqladmin flush-tables를 실행해야 한다.
압축된 테이블을 해제하기 위해서는, --unpack 옵션을 사용해서 myisamchk를 실행한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.5. mysql — MySQL 명령어 라인 툴
8. 클라이언트 및 유틸리티 프로그램 8.5.1. mysql 옵션

8.5. mysql — MySQL 명령어 라인 툴 8.5.2. mysql 명려어
8.5 mysql — MySQL 명령어 라인 툴 8.5.3. 텍스트 파일로부터 SQL 명령문 실행하기
8.5.1 mysql 옵션 8.5.4. mysql 팁
8.5.2 mysql 명령어

mysql은 간단한 SQL 쉘이다 (GNU readline 기능을 가지고 있음). 이것은 인터액티브(interactive) 및 일 방향적인(non-
8.5.3 텍스트 파일로부터 SQL 명령문 실행하기
interactive)한 사용을 지원해 준다. 인터액티브적으로 사용을 할 경우에는, 쿼리의 결과 값은 ASCII-테이블 포맷 형태로 표현된
8.5.4 mysql 팁
다. 일 방향적으로 사용되는 경우 (예를 들면, 필터로서 사용되는 경우), 그 결과는 탭으로 구분되는 포맷을 갖게 된다. 결과 포맷
8.5.4.1 쿼리 결과를 횡으로(Vertically) 출력하기
은 명령어 옵션을 사용해서 변경 시킬 수가 있다.
8.5.4.2 --safe-updates 옵션 사용하기
만일 여러분이 메모리가 부족해서 대형 결과 셋을 처리하는데 문제를 가지게 된다면, --quick 옵션을 사용하도록 한다. 이것은
8.5.4.3 mysql 자동-재 접속 비활성화 시키기
mysql로 하여금 서버에서 결과를 한번에 하나씩 추출하도록 만든다. 이것은 mysql_store_result()에 있는 것이 아닌 클라이언트/
서버 라이브러리 안에 있는 mysql_use_result() C API 함수를 사용해서 결과 셋을 리턴해 준다.
mysql를 사용하는 것은 매우 쉽다. 명령어 프롬프트에서 이것을 아래와 같이 호출한다:
shell> mysql db_name
또는:
shell> mysql --user=user_name --password=your_password db_name
그 다음에 SQL 명령문을 입력하고, 끝에 ‘;’, ￦g, 또는 ￦G를 입력한 후에 엔터키(Enter Key)를 누른다.
여러분은 아래와 같이 스크립트 파일(배치 파일) 안에서 SQL명령문을 실행할 수도 있다:
shell> mysql db_name < script.sql > output.tab
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.5.1. mysql 옵션
8.5. mysql — MySQL 명령어 라인 툴 mysql 은 아래의 옵션을 지원한다:
8.5.1 mysql 옵션
● --help, -?
도움말을 출력하고 빠져 나온다.
● --auto-rehash
자동 재해싱(rehashing)을 활성화 시킨다. 이 옵션은 디폴트로 동작하며, 테이블 및 컬럼 이름 완료(completion)을 활성

화 시킨다. --skip-auto-rehash를 사용하면 재해싱(rehashing)을 비 활성화 시킬 수 있다. 이렇게 하면 mysql을 보
다 빠르게 시작할 수는 있지만, 테이블 및 컬럼 이름 완료(completion)을 사용하고자 할 경우에는 반드시 rehash 명령어
를 입력해야 한다.
● --batch, -B
컬럼 구분자(separator)로서 탭을 사용해서 각 열을 새로운 라인에 결과를 출력한다. 이 옵션을 사용하면, mysql은 히스

토리 파일(history file)을 사용하지 않게 된다.
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”을 참조할 것.
● --column-names

:::MySQL Korea:::
결과에 컬럼 이름을 작성한다.
● --compress, -C
클라이언트와 서버가 압축을 지원하면, 두 서버간에 전달되는 모든 정보를 압축한다.
● --database=db_name, -D db_name
사용할 데이터 베이스. 옵션 파일에서 유용하게 쓰인다.
디버깅 로그를 작성한다. debug_options 스트링은 종종 'd:t:o,file_name'가 된다. 디폴트는 'd:t:o,/tmp/mysql.trace'이

다.
● --debug-info, -T
프로그램이 종료될 때 디버깅 정보를 출력한다.
● --default-character-set=charset_name
charset_name를 디폴트 문자 셋으로 사용한다. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”를 참조할
것.
● --delimiter=str
명령문 구획 문자(delimiter)를 설정한다. 디폴트는 세미 콜론 (‘;’)이다.
● --execute=statement, -e statement
명령문을 실행하고 종료한다. 디폴트 결과 포맷은 --batch이 만든 것과 비슷하다. Section 4.3.1, “명령어 라인에서 옵
션 사용하기”을 참조할 것.

:::MySQL Korea:::
● --force, -f
SQL 에러가 발생하더라도 계속 진행 시킨다.
● --host=host_name, -h host_name
주어진 호스트에서 MySQL 서버에 접속을 한다.
● --html, -H
HTML 결과를 만든다.
● --ignore-spaces, -i
함수 이름 다음에 나오는 스페이스를 무시한다. 이 옵션의 효과는 IGNORE_SPACE SQL 모드에 대한 설명에서 다루어
져 있다 (Section 5.2.5, “서버 SQL 모드”를 참조할 것).
● --line-numbers
에러 라인 숫자를 작성한다. --skip-line-numbers를 사용하면 이 옵션을 비활성화 시키게 된다.
● --local-infile[={0|1}]
LOAD DATA INFILE에 대한 LOCAL 기능을 활성화 또는 비활성화 시킨다. 아무런 값이 없다면, 이 옵션은 LOCAL을
활성화 시킨다. 이 옵션은 LOCAL을 명확하게 비활성화 또는 활성화 시키기 위해 --local-infile=0 또는 --local-
infile=1 형태로 표현된다. 만일 서버가 이 옵션을 지원하지 않으면, LOCAL를 활성화 시키는 의미가 없게 된다.
● --named-commands, -G
네임드(named) mysql 명령어를 활성화 시킨다. 긴-포맷(Long-format) 명령어뿐만 아니라 짧은-포맷(short-

format) 명령어도 사용할 수 있다. 예를 들면, quit 과 ￦q 은 둘 다 인식된다. --skip-named-commands를 사용하면
네임드 명령어를 비 활성화 시킬 수가 있다. Section 8.5.2, “mysql 명령어”를 참조할 것.

:::MySQL Korea:::
● --no-auto-rehash, -A
--skip-auto-rehash의 반대 옵션. --auto-rehash에 대한 설명을 참조할 것.
● --no-beep, -b
에러가 발생할 때 경고음을 내지 말도록 한다.
● --no-named-commands, -g
네임드 명령어를 비 활성화 시킨다. 세미 콜론 (‘;’)을 가지고 끝나는 라인의 처음 부분에서는 ￦* 형태만을 사용하거
나, 또는 네임드 명령어만을 사용한다. mysql은 디폴트로 이 옵션이 활성화 된 상태로 시작을 한다. 하지만, 이 옵션을 사
용한다고 하더라도, 긴-포맷 명령어는 맨 처음 라인에서부터 시작을 한다. Section 8.5.2, “mysql 명령어”를 참조할
것.
● --no-pager
--skip-pager의 반대 옵션. --pager 옵션을 참조할 것.
● --no-tee
결과를 파일로 복사하지 말도록 한다. Section 8.5.2, “mysql 명령어”를 참조하여 티 파일(tee file)에 대해서 알아 본
다.
● --one-database, -o
명령어 라인에서 지명된 디폴트 데이터 베이스에 대한 것을 제외하고 다른 명령문은 무시를 한다. 이 옵션은 바이너리 로
그에서 다른 데이터 베이스를 업데이트하지 못하도록 하는 경우에 유용하다.
● --pager[=command]

:::MySQL Korea:::
쿼리 결과를 페이징(paging)하기 위해 주어진 명령어를 사용한다. 만일 명령어가 생략되면, 디폴트 페이저(pager)는 여

러분이 사용하는 PAGER 환경 변수 값이 된다. 올바른 페이저는 less, more, cat [> filename], 등등이 된다. 이 옵션
은 유닉스에서만 구동된다. 배피 모드에서는 구동되지 않는다. 페이징(paging)을 비활성화 시키기 위해서는, --skip-
pager를 사용한다. Section 8.5.2, “mysql 명령어”에서 보다 자세한 정보를 참조한다.
● --password[=password], -p[password]
서버에 접속을 할 때 사용하는 패스워드. 만일 여러분이 짧은 옵션 형태 (-p)를 사용한다면, 옵션과 패스워드 중간에 스페
이스를 가질 수 없다. 만일 여러분이 명령어 라인에서 --password 또는 -p 옵션 다음에 password 값을 생략한다면, 프
롬프트가 나오게 된다.
명령어 라인에서 패스워드를 지정하는 것은 안전한 방법이 아니다. Section 5.9.6, “패스워드보안 유지하기”를 참조할
것.
● --port=port_num, -P port_num
접속을 위해 사용할 TCP/IP 포트 번호.
● --prompt=format_str
지정된 포맷을 위한 프롬프트를 설정한다. 디폴트는 mysql>가 된다. 프롬프트가 가질 수 있는 특별 시퀀스는

Section 8.5.2, “mysql 명령어”에서 설명한다.
● --protocol={TCP|SOCKET|PIPE|MEMORY}
사용할 접속 프로토콜.
● --quick, -q
각각의 쿼리 결과를 캐시에 넣지 않고, 결과가 나올 때 마다 한 줄씩 출력한다. 결과가 느리게 나오는 경우에는 서버의 속
도를 느리게 만든다. 이 옵션을 사용하면, mysql은 히스토리 파일(history file)을 사용하지 않게 된다.
● --raw, -r

:::MySQL Korea:::
이스케이프 변환(escape convertion)을 사용하지 않고 컬럼 값을 작성한다. 이 옵션은 종종 --batch 옵션과 함께 사용

된다.
● --reconnect
서버에 대한 접속을 잃게 되면, 자동으로 재 접속을 시도하게 된다. 접속을 잃게 될 때 마다 한번씩 재 접속을 시도하게 된
다. 재 접속 동작을 없애기 위해서는, --skip-reconnect를 사용한다.
● --safe-updates, --i-am-a-dummy, -U
키 값을 사용해서 수정할 열을 지정하는 UPDATE 와 DELETE 명령문만을 허용한다. 만일 여러분이 옵션 파일에서 이

옵션을 설정했다면, 명령어 라인에서 --safe-updates를 입력함으로써 옵션 파일의 것을 덮어 씌울 수가 있다.
Section 8.5.4, “mysql 팁”을 참조할 것.
● --secure-auth
4.11. 이전 버전 포맷의 패스워드는 서버에 보내지 못하도록 한다. 새로운 패스워드 포맷을 사용하지 않는 접속을 막을 때
사용할 수 있다.
● --show-warnings
각 명령문을 실행 후에 경고가 발생한다면 이 경고문을 출력하도록 한다. 이 옵션은 인터액티브(interactive) 모드 및 배

치 모드에서 모두 사용할 수 있다. 이 옵션은 5.0.6에서 추가 되었다.
● --sigint-ignore
SIGINT 신호를 무시한다.
● --silent, -s
침묵 모드 (Silent mode). 결과물의 만들어 내지 않는다. 이 옵션은 여러 번 반복 사용할 수있다.

:::MySQL Korea:::
● --skip-column-names, -N
결과에 컬럼 이름을 쓰지 않도록 한다.
● --skip-line-numbers, -L
에러가 발생한 라인 번호를 쓰지 않도록 한다. 에러 메시지를 포함하는 결과 파일을 비교하고자 할 경우에 유용한 옵션이
다.
● --socket=path, -S path
localhost에 접속을 하는 경우, 사용할 유닉스 소켓 파일, 또는 윈도우에서 사용할 네임드 파이프의 이름.
● --table, -t
테이블 포맷으로 결과를 출력한다. 이것은 인터액티브 모드에서는 디폴트이지만, 배치 모드에서도 결과를 테이블 모드를
만들기 위해 사용될 수 있다.
● --tee=file_name
결과물에 대한 복사본은 주어진 파일에 첨부한다. 이 옵션은 배치 모드에서는 동작하지 않는다. Section 8.5.2, “mysql
명령어”를 참조할 것.
● --unbuffered, -n
각 쿼리를 실행한 후에 버퍼를 플러시한다.
서버에 접속을 할 때 사용할 MySQL 사용자 이름.

:::MySQL Korea:::
● --verbose, -v
버보스 모드(Verbose mode). 프로그램이 실행한 사항에 대해 자세한 정보를 출력한다. 이 옵션은 여러 번 반복 사용을
할 수가 있다. (예를 들면, -v -v –v는 배치 모드에서도 테이블 결과 포맷을 만들어 낸다.)
● --version, -V
버전 번호를 출력한 후에 빠져 나온다.
● --vertical, -E
쿼리의 과 열을 횡(vertically)으로 출력한다 (컬럼 값 당 하나의 라인). 이 옵션을 사용하지 않으면, 각각의 명령문을 ￦G
를 사용해서 종료 시킴으로써 횡으로 결과를 표시하도록 만들 수가 있다.
● --wait, -w
만일 접속을 만들 수가 없다면, 그대로 끝내지 말고 대기를 한 다음에 다시 접속을 시도하도록 만든다.
● --xml, -X
결과를 XML 형태로 만들도록 한다.
또한, 여러분은 --var_name=value 신텍스를 사용해서 아래의 변수를 설정할 수도 있다:
● connect_timeout
접속 타임 아웃이 되기 전까지의 시간(초 단위) (디폴트는 0임).
● max_allowed_packet
서버에 전달 또는 서버로부터 받게 되는 패킷의 최대 길이. (디폴트는 16MB임.)
● max_join_size

:::MySQL Korea:::
--safe-updates를 사용할 때 하나의 조인에 있게 되는 열의 자동 한계 값 (디폴트 값은 1,000,000.)
● net_buffer_length
TCP/IP 및 소켓 통신을 위한 버퍼의 크기. (디폴트 값은 16KB.)
● select_limit
--safe-updates을 사용할 때 SELECT 명령문에 대한 자동 한계 값. (디폴트 값은 1,000.)
유닉스에서는, mysql 클라이언트는 실행된 명령문의 레코드를 히스토리 파일에 작성한다. 디폴트로는, 히스토리 파일의 이름이 .
mysql_history 이며 홈 디렉토리 안에서 생성된다. 다른 이름을 지정하기 위해서는, MYSQL_HISTFILE 환경 변수의 값을 설정한
다.
만일 여러분이 히스토리 파일을 관리하고 싶지 않다면, 우선 .mysql_history 를 제거하고, 그 다음에 아래의 기법 중에 하나를 사용
한다:
● MYSQL_HISTFILE 변수를 /dev/null에 설정한다. 이 설정 내용이 로그인 할 때 마다 효력을 내도록 하기 위해서는, 쉘의

스타트업 파일 중의 하나에 이 설정 값을 넣어 둔다.
● /dev/null에 대한 심볼릭 링크 형태로 .mysql_history를 생성한다.
• shell> ln -s /dev/null $HOME/.mysql_history
위의 사항에 대해서는 한번만 실행하면 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.5.2. mysql 명령어
8.5. mysql — MySQL 명령어 라인 툴 mysql 은 여러분이 입력하는 각각의 SQL 명령문을 서버에 전달해서 실행이 되도록 한다. 여기에는 mysql은 또한 자체가 해석할
8.5.2 mysql 명령어 수 있는 명령어 셋이 있다. 이러한 명령어 리스트는, help 또는 ￦h를 mysql> 프롬프트에서 입력하면 볼 수가 있다:
mysql> help
List of all MySQL commands:
Note that all text commands must be first on line and end with ';'
? (￦?) Synonym for `help'.
clear (￦c) Clear command.
connect (￦r) Reconnect to the server. Optional arguments are db and host.
delimiter (￦d) Set statement delimiter. NOTE: Takes the rest of the line as
new delimiter.
edit (￦e) Edit command with $EDITOR.
ego (￦G) Send command to mysql server, display result vertically.

:::MySQL Korea:::
exit (￦q) Exit mysql. Same as quit.
go (￦g) Send command to mysql server.
help (￦h) Display this help.
nopager (￦n) Disable pager, print to stdout.
notee (￦t) Don't write into outfile.
pager (￦P) Set PAGER [to_pager]. Print the query results via PAGER.
print (￦p) Print current command.
prompt (￦R) Change your mysql prompt.
quit (￦q) Quit mysql.
rehash (￦#) Rebuild completion hash.
source (￦.) Execute an SQL script file. Takes a file name as an argument.
status (￦s) Get status information from the server.
system (￦!) Execute a system shell command.
tee (￦T) Set outfile [to_outfile]. Append everything into given
outfile.
use (￦u) Use another database. Takes database name as argument.

:::MySQL Korea:::
charset (￦C) Switch to another charset. Might be needed for processing binlog with multi-byte charsets.
warnings (￦W) Show warnings after every statement.
nowarning (￦w) Don't show warnings after every statement.
각각의 명령어는 긴 폼과 짧은 폼을 모두 가지고 있다. 긴 폼은 대소 문자를 구분하지 않지만 짧은 포맷은 구분을 한다. 긴 폼은 뒤
에 세미 콜론 터미네이터를 선택적으로 가질 수 있지만, 짧은 폼은 가질 수가 없다.
delimiter 명령어에서는, 백 슬레쉬 (‘￦’) 문자를 사용하지 말아야 하는데, 그 이유는 이 문자가 MySQL에서는 이스케이프
(escape)문자이기 때문이다.
edit, nopager, pager, 그리고 system 명령어는 유닉스에서만 동작을 한다.
status 명령어는 여러분이 사용하고 있는 서버 및 접속 정보를 제공한다. 만일 여러분이 --safe-updates 모드에서 서버를 구동
중이라면, status는 여러분이 사용하는 쿼리에 영향을 주는 mysql 변수 값도 출력을 하게 된다.
쿼리와 그 결과에 로그를 하기 위해서는, tee 명령어를 사용한다. 스크린에 표시되는 모든 데이터는 주어진 파일에 첨부가 된다. 이
것은 디버깅 목적으로도 유용하게 사용할 수가 있다. 여러분은 이 기능을 명령어 라인에서 --tee 옵션을 사용해서 활성화 시킬
수 있거나, 또는 tee 명령어를 사용해서 인터액티브(interactive)하게 활성화 시킬 수가 있다. tee 파일은 notee 명령어를 사용해
서 비 활성화 시킬 수 있다. Tee를 다시 실행 시키면 재 활성화 시킬 수가 있게 된다. 파라미터를 사용하지 않으면, 이전
(previous) 파일이 사용된다. tee 명령어는 각 명령문이 실행된 후에, 그리고 mysql이 다음 프롬프트를 출력하기 전에 쿼리 결과
를 파일에 플러시한다는 점을 알아두자.
--pager 옵션을 사용하면, less, more와 같은 유닉스 프로그램, 또는 다른 비슷한 프로그램을 사용해서 인터액티브 모드에서 쿼
리 결과를 검색 또는 브라우즈(browse)할 수 있게 된다. 만일 여러분이 이 옵션에 아무런 값을 지정하지 않으면, mysql은
PAGER 환경 변수의 값을 검사하고 이것을 페이저에 설정한다. 결과 페이징은 pager 명령어를 가지고 활성화 시킬 수 있으며
nopager를 가지고 비활성화 시킬 수 있다. 명령어는 옵션 인수를 가진다; 만일 옵션 인수가 주어진다면, 페이징 프로그램은 그것
을 설정한다. 인수가 없다면, 페이저는 명령어 라인에서 설정된 페이저로 설정되거나, 또는 아무런 페이저가 없는 경우에는 stdout
가 된다.
결과 페이징은 popen() 함수를 사용하기 때문에 유닉스에서만 동작을 하는데, 윈도우에서는 이 함수를 지원하지 않는다. 윈도우

:::MySQL Korea:::
의 경우, tee 옵션은 비록 어떤 환경에서는 편리한 방식은 아닐 지라도 쿼리 결과를 저장하는데 대신 사용될 수도 있다.
pager 명령어에 대한 몇 가지 팁이 아래에 있다:
● 이것을 사용해서 파일에 쓰기를 할 수 있고 그 결과는 파일에만 기록된다:
• mysql> pager cat > /tmp/log.txt
또한 페이저로 사용하고자 하는 프로그램에 대한 옵션을 지정할 수도 있다:
mysql> pager less -n -i -S
● 위의 예에서 -S 옵션을 주목하도록 한다. 여러분은 이것이 수평으로 넓은(wide) 쿼리 결과를 브라우징(browsing)하는
데 매우 유용하다는 점을 알 수 있을 것이다. 때때로 매우 넓은 결과를 스크린에서 읽기가 어려울 때가 있다. less에 대한 -
S 옵션은 여러분이 왼쪽과 오른 쪽 화살표 키를 사용해서 결과를 수평(horizontally)으로 스크롤(scroll)할 수 있게끔 해
준다. 또한 이 옵션을 less과 함께 사용하면 수평-브라우즈(horizontal-browse) 모드를 온(on)/오프(off)시킬 수도 있
게 된다. 보다 자세한 정보는, less 매뉴얼 페이지를 읽도록 한다:
• shell> man less
● 여러분은 쿼리 결과를 다루기 위해서 매우 복잡한 페이저 명령어를 지정할 수 있다:
• mysql> pager cat | tee /dr1/tmp/res.txt ￦
• | tee /dr2/tmp/res2.txt | less -n -i -S
이 예문에서 보면, 명령어는 /dr1 과 /dr2에 마운트 되어 있는 서로 다른 두 개의 파일 시스템상의 두 디렉토리에 있는 두

개의 파일에 쿼리 결과를 보내고 있지만, 여전히 less를 통해서 결과를 스크린에 출력시킨다.
또한, 여러분은 tee 와 pager 함수를 서로 연결시킬 수도 있다. tee 파일을 활성화 시키고 pager를 less에 설정하면, 여러분은
and you are able to browse the results using the less 프로그램을 사용해서 그 결과를 브라우즈할 수 있고 동시에 모든 것을
파일에 첨부 시킬 수 있게 된다. pager 명령어와 함께 사용된 유닉스 tee와 tee 명령어에 빌트-인(built-in)된 mysql간의 차이점

:::MySQL Korea:::
은, 여러분이 유닉스 tee를 사용하지 못하는 경우가 되더라도 빌트-인 tee는 동작을 한다는 점이다. 빌트-인 tee 는 또한 스크린
에 표시되는 모든 것을 로그 하지만, pager와 함께 사용된 유닉스 tee는 그렇게 되지 않는다. 부가적으로, tee 파일 로깅은 mysql
내부에서 인터 액티브하게 온(On)/오프(Off)될 수 있다 이 기능은 여러분이 어떤 쿼리만을 파일에 로그하고자 할 때 유용하게 사
용할 수 있다.
디폴트 mysql> 프롬프트는 재 구성될 수 있다. 프롬프트를 정의하기 위한 스트링은 아래의 특수 시퀀스를 갖는다:
Option Description
￦v The server version
￦d The default database
￦h The server host
￦p The current TCP/IP port or socket file
￦u Your username
￦U Your full user_name@host_name account name
￦￦ A literal ‘￦’ backslash character
￦n A newline character
￦t A tab character
￦ A space (a space follows the backslash)
￦_ A space
￦R The current time, in 24-hour military time (0-23)
￦r The current time, standard 12-hour time (1-12)
￦m Minutes of the current time
￦y The current year, two digits
￦Y The current year, four digits
￦D The full current date

:::MySQL Korea:::
￦s Seconds of the current time
￦w The current day of the week in three-letter format (Mon, Tue, …)
￦P am/pm
￦o The current month in numeric format
￦O The current month in three-letter format (Jan, Feb, …)
￦c A counter that increments for each statement you issue
￦S Semicolon
￦' Single quote
￦" Double quote
‘￦’ 앞에 문자가 있게 되면 그것은 그 문자가 된다.
만일 아무런 인수 없이 prompt 명령어를 지정하면, mysql은 디폴트 프롬프트로 리셋된다: mysql>.
여러분은 여러 가지 방법을 사용해서 프롬프트를 설정할 수 있다:
● 환경 변수 사용. 프롬프트 스트링을 위해서는 MYSQL_PS1 환경 변수를 사용한다. 예를 들면:
• shell> export MYSQL_PS1="(￦u@￦h) [￦d]> "
● 명령어 라인 옵션 사용. 명령어 라인에서 --prompt 옵션을 mysql에 지정한다. 예를 들면:
• shell> mysql --prompt="(￦u@￦h) [￦d]> "
• (user@host) [database]>
● 옵션 파일 사용. MySQL 옵션 파일의 [mysql] 그룹에 있는 prompt 옵션을 설정한다. 홈 디렉토리에 있는 /etc/my.cnf 또
는 .my.cnf 파일을 사용한다. 예를 들면:

:::MySQL Korea:::
• [mysql]
• prompt=(￦￦u@￦￦h) [￦￦d]>￦￦_
이 예문에서 보면, 백 슬레시가 두 번 반복 사용된 점을 유의한다. 만일 옵션 파일에 있는prompt 옵션을 사용해서 프롬프
트를 설정한다면, 특별 프롬프트 옵션을 사용할 때 백 슬레시를 두 번 사용하는 것이 좋다. 사용이 허용된 프롬프트 옵션
셋 및 옵션 파일에서 인식되는 특수 이스케이프(escape) 시퀀스 셋에는 오버랩(oberlap)되는 것들이 몇 가지 존재한다.
(이러한 시퀀스들은 Section 4.3.2, “옵션 파일 사용하기”에 나와 있다.) 따라서, 백 슬레시를 중복해서 사용하지 않게
되면 이러한 오버랩으로 인해 문제가 생길 수도 있게 된다. 예를 들면, ￦s는 현재 초(second) 값으로 해석되는 대신에 스
페이스로 해석이 된다. 아래의 예문에서는 현재의 시간을 HH:MM:SS> 포맷으로 옵션 파일 안에 포함 시키기 위한 프
롬프트 정의 방법을 보여준다:
[mysql]
prompt="￦￦r:￦￦m:￦￦s> "
● 인터 액티브하게 프롬프트를 설정한다. prompt (또는 ￦R) 명령어를 사용해서 인터 액티브하게 프롬프트를 변경 시킬 수
가 있다. 예를 들면:
• mysql> prompt (￦u@￦h) [￦d]>￦_
• PROMPT set to '(￦u@￦h) [￦d]>￦_'
• (user@host) [database]>
• (user@host) [database]> prompt
• Returning to default PROMPT of mysql>
• mysql>

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.5.3. 텍스트 파일로부터 SQL 명령문 실행하기
8.5. mysql — MySQL 명령어 라인 툴 mysql 클라이언트는 전형적으로 인터 액티브하게 사용된다:
8.5.3 텍스트 파일로부터 SQL 명령문 실행하기

shell> mysql db_name
하지만, SQL 명령문을 파일 안에 넣은 다음에 mysql로 하여금 그 파일을 읽어 오도록 만들 수도 있다. 이렇게 하기 위해서는, 실행
하고자 하는 명령문을 가지고 있는 텍스트 파일 text_file that 을 생성해야 한다. 그 다음에 아래와 같이 mysql를 호출한다:
shell> mysql db_name < text_file
만일 그 파일의 첫 줄에 USE db_name 명령문을 놓는다면, 명령어 라인에서 데이터 베이스 이름을 지정할 필요가 없어진다:
shell> mysql < text_file
만일 여러분이 이미 mysql을 구동 시켰다면, source 또는 ￦. 명령어를 사용해서 SQL스크립트 파일을 실행 시킨다:
mysql> source file_name
mysql> ￦. file_name
때로는 여러분이 사용한 스크립트의 진행 과정을 출력하도록 만들고 싶을 경우가 있다. 이렇게 하기 위해서는 아래와 같이 명령문
을 파일에 삽입하면 된다:
SELECT '<info_to_display>' AS ' ';

:::MySQL Korea:::
이 명령문은 <info_to_display>를 출력한다.
배치 모드에 대한 보다 자세한 정보는 Section 3.5, “배치 모드에서 mysql 사용하기”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.5.4. mysql 팁
8. 클라이언트 및 유틸리티 프로그램 8.5.4.1. 쿼리 결과를 횡으로(Vertically) 출력하기

8.5. mysql — MySQL 명령어 라인 툴 8.5.4.2. --safe-updates 옵션 사용하기
8.5.4 mysql 팁 8.5.4.3. mysql 자동-재 접속 비활성화 하기
8.5.4.1 쿼리 결과를 횡으로(Vertically) 출력하기

이 섹션에서는 여러분이 mysql을 보다 효과적으로 사용할 수 있도록 도움을 주는 몇 가지 팁에 대해서 설명을 하기로 한
다.
:::MySQL Korea:::
제목검색
8.5.4.1. 쿼리 결과를 횡으로(Vertically) 출력하기

8.5. mysql — MySQL 명령어 라인 툴 어떤 쿼리 결과들은 화면에 수평이 아닌 횡으로 출력을 하는 것이 보다 읽기 편할 경우가 있다. 쿼리를 세미 콜론이 아닌 ￦G로 끝
8.5.4 mysql 팁 맺게 되면 그 결과가 화면에 횡으로 표시가 된다. 예를 들면, newlines 을 포함하는 긴 텍스트 값들은 횡으로 표시하는 것이 보다
8.5.4.1 쿼리 결과를 횡으로(Vertically) 출력하기 읽기가 편하다:

mysql> SELECT * FROM mails WHERE LENGTH(txt) < 300 LIMIT 300,1￦G
*************************** 1. row ***************************
msg_nro: 3068
date: 2000-03-01 23:29:50
time_zone: +0200
mail_from: Monty
reply: monty@no.spam.com
mail_to: "Thimble Smith" <tim@no.spam.com>
sbj: UTF-8
txt: >>>>> "Thimble" == Thimble Smith writes:

:::MySQL Korea:::
Thimble> Hi. I think this is a good idea. Is anyone familiar
Thimble> with UTF-8 or Unicode? Otherwise, I'll put this on my
Thimble> TODO list and see what happens.
Yes, please do that.
Regards,
Monty
file: inbox-jani-1
hash: 190402944

:::MySQL Korea:::
제목검색
8.5.4.2. --safe-updates 옵션 사용하기

8.5. mysql — MySQL 명령어 라인 툴 초보 사용자의 경우, 유용하게 사용할 수 있는 스타트업 옵션이 --safe-updates (또는 --i-am-a-dummy)일 것이다. 이것
8.5.4 mysql 팁 은 여러분이 DELETE FROM tbl_name 명령어를 입력하면서 WHERE 구문을 잊고 사용하지 않을 경우에 도움이 될 것이다. 보통
8.5.4.1 쿼리 결과를 횡으로(Vertically) 출력하기 의 경우, 이 같은 명령문은 테이블에서 모든 열을 삭제한다. --safe-updates를 사용하면, 여러분은 키 값을 지정한 열만 삭제할
수가 있다. 이렇게 하면 실수를 막을 수가 있다.
--safe-updates 옵션을 사용하면, mysql은 MySQL 서버에 접속을 할 때 아래의 명령문을 입력한다:
SET SQL_SAFE_UPDATES=1,SQL_SELECT_LIMIT=1000, SQL_MAX_JOIN_SIZE=1000000;
Section 13.5.3, “SET 신텍스”를 참조할 것.
SET 명령문은 다음과 같은 효과를 갖는다:
● 여러분이 WHERE 구문에 키 항수 값을 지정하지 않거나 또는 LIMIT 구문을 제공하지 않으면(또는 둘 다) UPDATE 또
는 DELETE 명령문을 실행할 수가 없다. 예를 들면:
• UPDATE tbl_name SET not_key_column=val WHERE key_column=val;
• UPDATE tbl_name SET not_key_column=val LIMIT 1;
● 명령문이 LIMIT 구문을 가지고 있지 않는 한 서버는 모든 SELECT 결과를 최대 1,000 열로 한정한다.

● 서버는 1,000,000 열 조합 이상을 조사하는데 필요한 다중-테이블 SELECT 명령문은 종료 시킨다.
1,000 에서 1,000,000 사이의 한계를 지정하기 위해서는, --select_limit 및 --max_join_size 옵션을 사용해서 디폴트를 무시

:::MySQL Korea:::
하도록 만들어야 한다:
shell> mysql --safe-updates --select_limit=500 --max_join_size=10000

:::MySQL Korea:::
제목검색
8.5.4.3. mysql 자동-재 접속 비활성화 시키기

8.5. mysql — MySQL 명령어 라인 툴 만일 mysql 클라이언트가 쿼리를 보내는 도중에 서버와 접속이 끊어지게 되면, 클라이언트는 즉시 자동으로 서버와 재 접속을 시
8.5.4 mysql 팁 도하고 쿼리를 다시 전송한다.하지만, mysql이 재 접속에 성공한다고 하더라도, 처음에 했던 접속은 종료가 되었기 때문에 이전에
8.5.4.1 쿼리 결과를 횡으로(Vertically) 출력하기 설정된 모든 세션 오브젝트와 설정 값들은 잃어 버리게 된다: 임시 테이블, 오토 커밋(autocommit) 모드, 그리고 사용자 정의 및
세션 변수 등. 또한, 현재의 모든 트랜젝션도 롤백된다. 이러한 동작은 매우 위험할 수도 있는데, 왜냐하면 아래의 예에서 보면, 서
버가 여러분이 알지 못하는 상태에서 셧 다운 되고 재 시작이 되기 때문이다.:
mysql> SET @a=1;
mysql> INSERT INTO t VALUES(@a);
ERROR 2006: MySQL server has gone away
No connection. Trying to reconnect...
Connection id: 1
Current database: test

:::MySQL Korea:::
Query OK, 1 row affected (1.30 sec)
mysql> SELECT * FROM t;
+------+
|a |
+------+
| NULL |
+------+
사용자 변수 @a는 접속과 함께 잃게 되고, 재 접속이 된 후에는 재 정의가 되지 않는다. 만일 접속이 끊어지면 에러를 발생 시키고
mysql을 종료하도록 하고자 한다면, mysql 클라이언트를 --skip-reconnect 옵션과 함께 시작하면 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.6. mysqlaccess - 접속 권한을 검사하기 위한 클라이언트
8.6. mysqlaccess - 접속 권한을 검사하기 위 Mysqlaccess는 Yves Carlier가 제공해 준 진단 프로그램이다. 이것은 호스트 이름, 사용자 이름, 그리고 데이터 베이스 컴비네이
한 클라이언트 션(combination)에 대한 접속 권한을 검사한다. Mysqlaccess은 user, db, 그리고 host 테이블만을 사용해서 접속을 검사한다는
8.6 mysqlaccess - 접속 권한을 검사하기 위한 클 점을 알아두자. 이것은 tables_priv, columns_priv, 또는 procs_priv 테이블에서 지정이 된 테이블, 컬럼, 또는 루틴 권한 등은 검
라이언트 사를 하지 않는다.
Mysqlaccess을 아래와 같이 호출한다:
shell> mysqlaccess [host_name [user_name [db_name]]] [options]
mysqlaccess은 아래의 옵션을 지원한다:
● --help, -?
● --brief, -b
싱글-라인 표 형식으로 레포트를 작성한다.
● --commit
임시 테이블에서 원본 그랜트 테이블로 새로운 접속 권한을 복사한다. 새로운 권한이 효력을 갖도록 하기 위해서는 그랜
트 테이블을 플러시 해야 한다. (예를 들면, mysqladmin reload 명령어를 실행한다.)

:::MySQL Korea:::
● --copy
원본 그랜트 테이블에서 임시 테이블로 다시 읽어 온다.
● --db=db_name, -d db_name
데이터 베이스 이름을 지정한다.
● --debug=N
디버그 레벨을 지정한다. N 은 0에서 3 사이의 정수가 된다.
접속 권한에서 사용되는 호스트 이름.
● --howto
mysqlaccess를 사용하는 방법에 대한 예문을 보여준다
● --old_server
서버가 마치 전체적으로 WHERE 구문을 처리하는 방법을 모르는 구형 MySQL 서버(3.21 이전 버전)인 것처럼 만든다.
서버에 접속을 할 때 사용할 패스워드. 만일 명령문에서 --password 또는 -p 옵션 다음에 password를 생략하면, 프롬

프트가 나오게 된다.
● --plan
향후에 발표될 버전에 대한 아이디어를 보여 준다.

:::MySQL Korea:::
● --preview
임시 그랜트 테이블을 변경 시킬 경우의 권한 변경 내역을 미리 보여준다.
● --relnotes
릴리즈 노트를 보여준다.
● --rhost=host_name, -H host_name
주어진 호스트 상의 MySQL 서버와 접속을 한다.
● --rollback
임시 그랜트 테이블에서 일어난 가장 최근의 변경을 복원(Undo) 시킨다.
● --spassword[=password], -P[password]
Superuser로 서버에 접속을 할 때 사용하는 패스워드. 만일 명령문에서 --password 또는 -p 옵션 다음에 password

를 생략하면, 프롬프트가 나오게 된다.
● --superuser=user_name, -U user_name
Superuser로 접속을 하기 위한 사용자 이름을 지정한다.
● --table, -t
테이블 포맷으로 레포트를 작성한다.
접속 권한에서 사용할 사용자 이름.

:::MySQL Korea:::
● --version, -v
만일 여러분이 사용하고 있는 MySQL 배포판이 표준 설치 위치가 아닌 곳에 설치되어 있다면, 여러분은 반드시 mysqlaccess이
mysql 클라이언트를 찾고자 하는 위치를 변경 시켜야 한다. 라인 18에 있는 mysqlaccess 스크립트를 적당히 편집한다:
$MYSQL = '/usr/local/bin/mysql'; # path to mysql executable
mysql이 실제로 저장되어 있는 위치를 가리키도록 경로를 변경한다. 만일 여러분이 이렇게 변경하지 않고 mysqlaccess을 구동시
키게 되면, Broken pipe 에러가 발생한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.7. mysqladmin - MySQL 서버를 관리하기 위한 클라이언트
8.7. mysqladmin - MySQL 서버를 mysqladmin은 관리 연산을 수행하는 클라이언트이다. 여러분은 이것을 사용해서 서버의 구성 및 현재의 상태를 검사할 수 있고, 데이터 베
관리하기 위한 클라이언트 이스를 생성 및 제거할 수 있다.
8.7 mysqladmin - MySQL 서버를 관리

하기 위한 클라이언트 mysqladmin은 아래와 같이 호출한다:
shell> mysqladmin [options] command [command-arg] [command [command-arg]] ...
mysqladmin은 아래의 명령어들을 지원한다. 아래의 명령어 중에는 명령어 뒤에 인수를 가지는 것들도 있다.
● create db_name
db_name라는 이름의 새로운 데이터 베이스를 생성한다.
● debug
서버로 하여금 디버그 정보를 에러 로그에 기록하도록 한다.
● drop db_name
db_name 라는 이름의 데이터 베이스와 여기에 있는 모든 테이블을 제거한다.
● extended-status
서버 상태 변수 및 그 값을 보여준다.

:::MySQL Korea:::
● flush-hosts
호스트 캐시에 있는 모든 정보를 플러시한다.
● flush-logs
모든 로그를 플러시한다.
● flush-privileges
그랜트 테이블을 다시 읽어 온다 (reload와 동일함).
● flush-status
상태 변수를 비운다 (Clear).
● flush-tables
모든 테이블을 플러시한다.
● flush-threads
쓰레드 캐시를 플러시한다.
● kill id,id,...
서버 쓰레드를 죽인다 (Kill). 만일 여러 개의 쓰레드 ID 값을 줄 경우에는, 중간에 스페이스가 없어야 한다.
● old-password new-password
이것은 password 명령어와 유사하지만, 패스워드를 구형 (4.1 이전 버전) 패스워드 해싱 포맷을 사용해서 저장한다.
(Section 5.8.9, “Password Hashing as of MySQL 4.1”을 참조.)

:::MySQL Korea:::
● password new-password
새로운 패스워드를 설정한다. 이것은 여러분이 서버에 접속하기 위해 mysqladmin와 함께 사용하는 계정용 패스워드를 new-
password 로 변경 시킨다. 따라서, 여러분이 동일한 계정을 사용해서 mysqladmin (또는 다른 클라이언트 프로그램)을 호출하는
다음 시점부터는 이 새로운 패스워드를 사용해야 한다.
만일 new-password 값이 스페이스 또는 여러분이 사용하는 명령어 해석기에서 특별하게 취급되는 다른 문자를 가지고 있는 경
우에는, 인용 부호를 사용해서 이것들을 지정해 주어야 한다. 윈도우에서는, 이중 인용 부호를 사용해야 한다; 단일 인용 부호는 패
스워드의 일부분으로 간주된다. 예를 들면:
shell> mysqladmin password "my new password"
● ping
서버가 제대로 동작 중인지를 검사한다. 서버가 구동 중에 있다면, mysqladmin 는 0을 리턴하고, 그렇지 않다면 1을 리턴한다.
mysqladmin 은 Access denied일 경우에도 0을 리턴하는데, 그 이유는 서버가 접속을 거부하기는 했지만 구동 중이기 때문이며,
이것은 서버가 구동을 하지 않는 상황과는 다른 것이다.
● processlist
액티브 서버 쓰레드의 리스트를 보여준다. 이것은 SHOW PROCESSLIST 명령문의 결과와 유사한 내용을 출력한다. 만일 --
verbose 옵션을 주게 되면, 그 결과는 SHOW FULL PROCESSLIST와 비슷하게 나온다. (Section 13.5.4.19, “SHOW
PROCESSLIST 신텍스”를 참조.)
● reload
그랜트 테이블을 다시 읽어 온다.
● refresh
모든 테이블을 플러시한 다음에 닫고 로그 파일을 연다.

:::MySQL Korea:::
● shutdown
서버를 종료 시킨다.
● start-slave
슬레이브 서버 상에서 리플리케이션을 시작한다.
● status
서버 상태 메시지를 짧게 보여준다.
● stop-slave
슬레이브 서버에서 리플리케이션을 종료 한다.
● variables
서버 시스템 변수 및 그 값을 보여 준다.
● version
서버의 버전 정보를 보여준다.
모든 명령어는 각각의 고유 접두사를 사용해서 축약할 수가 있다. 예를 들면:
shell> mysqladmin proc stat
+----+-------+-----------+----+---------+------+-------+------------------+
| Id | User | Host | db | Command | Time | State | Info |

:::MySQL Korea:::
+----+-------+-----------+----+---------+------+-------+------------------+
| 51 | monty | localhost | | Query | 0 | | show processlist |
+----+-------+-----------+----+---------+------+-------+------------------+
Uptime: 1473624 Threads: 1 Questions: 39487
Slow queries: 0 Opens: 541 Flush tables: 1
Open tables: 19 Queries per second avg: 0.0268
mysqladmin status 명령어 결과는 아래의 값을 표시한다:
● Uptime
MySQL 서버가 구동을 한 시간(초 단위).
● Threads
액티브 쓰레드의 숫자(클라이언트).
● Questions
서버가 시작된 이후 클라이언트에서 보내진 문의 (쿼리) 숫자.
● Slow queries
The number of queries that have taken more than long_query_time 시간 보다 길게 걸린 쿼리의 숫자. Section 5.12.4, “슬
로우 쿼리 로그”를 참조.
● Opens

:::MySQL Korea:::
서버가 연 테이블의 숫자.
● Flush tables
서버가 실행한 flush-*, refresh, 그리고 reload 명령어의 숫자.
● Open tables
현재 열려 있는 테이블의 숫자.
● Memory in use
mysqld가 직접 할당한 메모리 크기. 이 값은 MySQL이 --with-debug=full와 함께 컴파일 된 경우에만 볼 수가 있다.
● Maximum memory used
mysqld가 직접 할당한 전체 메모리 크기. 이 값은 MySQL이 --with-debug=full와 함께 컴파일 된 경우에만 볼 수가 있다.
만일 여러분이 유닉스 소켓 파일을 사용해서 로컬 서버에 접속을 할 때 mysqladmin shutdown을 실행하게 되면, mysqladmin은 서버가 올
바르게 종료 되었다는 것을 확인하기 위해 서버의 프로세스 ID 파일이 제거될 때까지 대기를 하게 된다.
Mysqladmin는 아래의 옵션을 지원한다:
● --help, -?
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”를 참조.
● --compress, -C

:::MySQL Korea:::
서버 및 클라이언트가 압축을 지원할 경우, 두 서버간에 전달된 모든 정보를 압축한다.
● --count=N, -c N
명령어 반복 실행을 위한 반복 횟수. 이것은 --sleep 옵션과 함께만 동작을 한다.
디버깅 로그를 작성한다. debug_options 스트링은 종종 'd:t:o,file_name'이 되기도 한다. 디폴트는 'd:t:o,/tmp/mysqladmin.
trace'.
디폴트 문자 셋으로 charset_name 를 사용한다. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”을 참조.
● --force, -f
drop db_name 명령어에 대해 확인을 문의하지 않게 한다. 여러 개의 명령어를 사용하면, 에러가 발생하더라도 계속 진행을 한다.
주어진 호스트에서 MySQL 서버에 접속을 한다.
서버에 접속을 할 때 사용하는 패스워드. 만일 여러분이 축약 폼 (-p)을 사용한다면, 이 옵션과 패스워드 사이에는 스페이스를 두
면 안 된다. 만일 --password 또는 -p 옵션 뒤에 패스워드를 지정하지 않으면, 프롬프트가 나오게 된다.
접속할 때 사용하는 TCP/IP 포트 번호.

:::MySQL Korea:::
● --relative, -r
--sleep 옵션을 함께 사용했을 때의 값과 현재의 값을 비교해 준다. 현재의 버전까지는, 이 옵션은 extended-status 명령어에서
만 동작을 한다.
● --silent, -s
서버와의 접속이 이루어지지 않을 경우에 조용히 (에러 없이) 종료 한다.
● --sleep=delay, -i delay
delay 시간 동안 슬리핑(sleeping)한 후에 명령어를 반복 실행한다. --count 옵션은 반복 횟수를 결정한다.
localhost에 접속을 할 경우, 사용할 유닉스 소켓 파일, 또는 윈도우에서의 네임드 파이프 이름.
서버에 접속을 할 때 사용하는 MySQL 사용자 이름.
● --verbose, -v
버보스 모드(Verbose mode). 프로그램이 실행한 사항에 대해 보다 자세한 정보를 출력한다.
● --version, -V
버전 정보를 보여 주고 종료한다.

:::MySQL Korea:::
● --vertical, -E
결과를 횡으로 출력한다. 이것은 –relative와 유사하지만, 이 옵션은 결과를 횡으로 출력한다.
● --wait[=count], -w[count]
접속을 하지 못하는 경우, 종료를 하는 대신에 대기를 하고 다시 접속을 시도한다. 만일count 값을 주게 되면, 이 값은 재 시도 횟수
를 나타내는 것이다. 디폴트는 한 번이다.
또한, 여러분은 --var_name=value 신텍스를 사용해서 아래의 변수를 설정할 수가 있다:
● connect_timeout
접속 타임 아웃 이전의 최대 시간. 디폴트 값은 43200 (12 시간)이다.
● shutdown_timeout
서버 셧 다운용 최대 대기 시간. 디폴트는 3600 (1 시간)이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.8. mysqlbinlog - 바이너리 로그 파일을 처리하기 위한 유틸리티
8.8. mysqlbinlog - 바이너리 로그 파일을 처 서버가 만드는 바이너리 로그 파일은 바이너리 포맷으로 작성된다. 이 파일을 텍스트 포맷으로 검사를 하기 위해서는,
리하기 위한 유틸리티 mysqlbinlog 유틸리티를 사용하면 된다. 리플리케이션 셋업에서 슬레이브가 작성한 릴레이 로그 파일을 읽기 위해서도
8.8 mysqlbinlog - 바이너리 로그 파일을 처리하 mysqlbinlog를 사용할 수가 있다. 릴레이 로그는 바이너리 로그 파일과 같은 포맷을 가지고 있다.
기 위한 유틸리티
Mysqlbinlog은 아래와 같이 호출한다:
shell> mysqlbinlog [options] log_file ...
예를 들면, binlog.000003라는 이름의 바이너리 로그 파일의 내용물을 보여 주기 위해서는, 아래의 명령어를 사용한다:
shell> mysqlbinlog binlog.0000003
이 명령어를 실행하면 binlog.000003에 포함되어 있는 모든 이벤트가 나오게 된다. 이벤트 정보는 실행된 명령문, 명령문 실행 시
간, 명령문을 입력한 클라이언트의 쓰레드 ID, 실행된 타임 스탬프 등등의 정보가 포함되어 있다.
Mysqlbinlog를 통해 얻게 되는 결과는 로그에 있는 명령문을 재 적용하기 위해 다시 실행 시킬 수가 있다 (예를 들면, 이것을

mysql의 입력 값으로 사용할 수 있다). 이 값은 서버가 크래시(crash)가 난 후에 복구를 할 때 유용하게 사용할 수가 있다.
보통의 경우, 여러분은 바이너리 로그 파일을 직접 읽고 이것을 로컬 MySQL 서버에 적용하기 위해 mysqlbinlog를 사용하게 된
다. 또한, 이것을 --read-from-remote-server 옵션과 함께 사용해서 원격 서버로부터 바이어리 로그를 읽는 것도 가능하다.
여러분이 원격 바이너리 로그를 읽을 경우, 접속 파라미터 옵션을 지정해서 서버와의 접속 방법을 지시할 수도 있다. 이렇게 할 수
있는 옵션으로는 --host, --password, --port, --protocol, --socket, 그리고 –user가 있다; 이 옵션들은 여러분이 --
read-from-remote-server 옵션을 함께 지정해야만 기능을 발휘한다.

:::MySQL Korea:::
바이너리 로그 및 릴레이 로그는 Section 5.12.3, “바이너리 로그”, 그리고and Section 6.3.4, “리플리케이션 릴레이 및 상태
파일”을 참조할 것.
mysqlbinlog는 아래의 옵션을 지원한다:
● --help, -?
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”를 참조할 것.
● --database=db_name, -d db_name
지정된 데이터 베이스용 엔트리만을 보여준다 (로컬 로그만 해당).
디버깅 로그를 작성한다. 전형적인 debug_options 스트링은 'd:t:o,file_name'.
● --disable-log-bin, -D
바이너리 로깅을 비 활성화 시킨다. 이것은 여러분이 --to-last-log 옵션을 사용하고 그 결과를 동일한 MySQL 서버에
보내는 경우에 무한 루프를 피하기 위해서 유용하게 사용할 수 있다. 또한, 이 옵션은 서버 크래시 이후에 여러분이 로그
한 명령문이 중복되는 것을 피하기 위해서도 유용하게 사용된다.
이 옵션은 여러분이 SUPER 권한을 가지고 있어야 한다. 이것은 mysqlbinlog로 하여금 남아있는 결과의 바이너리 로깅
을 비 활성화 시키기 위해 자신의 결과에 있는 SET SQL_LOG_BIN=0 명령문을 비 활성화 시키도록 만든다. SET 명령
문은 여러분이 SUPER 권한을 가지고 있지 않는 한 효력을 갖지 못한다.
● --force-read, -f

:::MySQL Korea:::
이 옵션을 사용하면, 만일 mysqlbinlog가 인식하지 못하는 바이너리 로그 이벤트를 읽는 경우에, 서버는 경고를 출력하
고, 이벤트를 무시하고 계속 진행을 한다.이 옵션을 사용하지 않으면, mysqlbinlog이 이와 같은 이벤트를 읽는 경우 멈추
게 된다.
● --hexdump, -H
코멘트에 있는 로그의 헥스(hex)덤프를 출력한다. 이로 인한 결과는 리플리케이션 디버깅에 유용하게 사용될 수 있다. 헥
스 덤프는 나중에 설명하기로 한다. 이 옵션은 5.0.16에서 추가 되었다.
주어진 호스트 상에 있는 MySQL 서버로부터 바이너리 로그를 가져온다.
● --local-load=path, -l path
지정된 디렉토리에 있는 LOAD DATA INFILE을 위한 로컬 임시 파일을 준비 시킨다.
● --offset=N, -o N
로그에 있는 첫 번째 N 엔트리를 무시 한다(skip).
서버에 접속을 할 때 사용하는 패스워드. 축약형 옵션 (-p)을 사용할 경우에는, 이 옵션과 패스워드 사이에는 스페이스를
사용하지 않는다. 만일 --password 또는 -p 옵션 다음에 패스워드를 지정하지 않으면, 프롬프트가 나오게 된다.
원격 서버에 접속을 하기 위해 사용되는 TCP/IP 포트 번호.
● --position=N, -j N

:::MySQL Korea:::
사용 중지됨. 대신에 --start-position을 사용한다.
● --read-from-remote-server, -R
로컬 로그 파일을 읽는 대신에 MySQL 서버에서 바이너리 로그를 읽는다. 모든 접속 파라미터 옵션은 이 옵션을 같이 지
정하지 않는 한 무시된다. 이러한 파라미터 옵션에는 --host, --password, --port, --protocol, --socket, 그리고
–user가 있다.
● --result-file=name, -r name
실행 결과를 주어진 파일에 직접 넣는다.
● --short-form, -s
로그에 포함되어 있는 명령문만을 다른 정보 없이 표시한다.
Localhost에 접속을 하는 경우, 사용하게 될 유닉스 소켓 파일, 또는 윈도우에서의 네임드 파이프 이름.
● --start-datetime=datetime
datetime 인수와 동일하거나 느린 타임 스탬프를 가지고 있는 이벤트가 처음으로 발생할 때 바이너리 로그를 읽기 시작한
다. datetime 값는 여러분이 mysqlbinlog를 구동 시키는 시스템의 로컬 타임 존과 연관된다. 이 값은 DATETIME 또는
TIMESTAMP 데이터 타입에 적합한 포맷 형태를 가져야 한다. 예를 들면:
shell> mysqlbinlog --start-datetime="2005-12-25 11:25:56" binlog.000003

:::MySQL Korea:::
이 옵션은 포인트-인-타입(point-in-time) 복구시에 유용하다. Section 5.10.2, “백업 및복구전략의 예”를 참조할
것.
● --stop-datetime=datetime
datetime 인수와 동일하거나 빠른 타임 스탬프를 가지고 있는 이벤트가 처음으로 발생할 때 바이너리 로그를 읽기를 종료
한다. 이 옵션은 포인트-인-타입(point-in-time) 복구시에 유용하다. datetime 값에 대한 정보는 --start-datetime
옵션에 대한 설명을 참조하기 바란다.
● --start-position=N
N 인수와 동일한 위치를 가지고 있는 이벤트가 처음 발생할 때 바이너리 로그를 읽기 시작한다.
● --stop-position=N
N 인수와 동일하거나 보다 큰 위치를 가지고 있는 이벤트가 처음 발생할 때 바이너리 로그를 읽기를 멈춘다
● --to-last-log, -t
MySQL 서버로부터 요청 받은 바이너리 로그의 끝에서 멈추는 대신에, 마지막 바이너리 로그의 끝이 될 때까지 프린트를
계속한다. 만일 여러분이 이 결과를 동일한 MySQL 서버에 보낸다면, 무한 루프가 발생할 수도 있다. 이 옵션은 --
read-from-remote-server를 필요로 한다.
원격 서버에 접속을 할 때 사용하는 MySQL 사용자 이름.
● --version, -V
또한, --var_name=value 신텍스를 사용해서도 아래의 변수를 지정할 수가 있다:

:::MySQL Korea:::
● open_files_limit
보관해야 할 오픈 파일 디스크립터의 숫자를 지정한다.
바이너리 로그에 포함되어 있는 명령문을 실행하기 위해서, mysqlbinlog의 결과를 mysql 클라이언트에 전달할 수 있다. 이것은 여
러분이 오래된 백업을 가지고 있을 때 크래시를 복구하기 위해서 사용할 수가 있다 (Section 5.10.1, “데이터 베이스 백업”을 참
조). 예를 들면:
shell> mysqlbinlog binlog.000001 | mysql
또는:
shell> mysqlbinlog binlog.[0-9]* | mysql
만일 여러분이 명령문의 로그를 우선 수정할 필요가 있다면, mysqlbinlog의 결과를 텍스트 파일로 보낼 수가 있다 (예를 들면, 실
행되지 않기를 원하는 명령문을 제거하기 위해). 이 파일을 수정한 다음에, 이것을 mysql 프로그램의 입력 값으로 사용해서 그 명
령문을 실행 시킨다.
mysqlbinlog은 --start-position 옵션을 가지고 있는데, 이것은 바이너리 로그 안에서 주어진 위치와 동일하거나 보다 큰 오프셋
을 가지고 있는 명령문만을 출력한다 (주어진 위치는 반드시 하나의 이벤트 시점과 매치가 되어야 한다). 또한, 이것은 주어진 날
짜 및 시간을 가지고 있는 이벤트를 발견할 때 종료하고 시작하는 옵션을 가지기도 한다. 이것을 사용하면 여러분은 --stop-
datetime 옵션을 사용해서 포인트-인-타입 복구를 실행할 수가 있다.
만약에 MySQL 서버에서 하나 이상의 바이너리 로그를 가지고 있다면, 이 모든 것을 한번에 서버에 연결해서 처리하는 것이 안전
한 방법이다. 아래에서 보여주는 것은 안전하지 못한 예이다:
shell> mysqlbinlog binlog.000001 | mysql # DANGER!!
shell> mysqlbinlog binlog.000002 | mysql # DANGER!!
서버에 서로 다르게 접속을 해서 바이너리 로그를 처리하게 되면, 맨 처음의 로그 파일이 CREATE TEMPORARY TABLE 명령

:::MySQL Korea:::
문을 가지고 있고 두 번째 로그가 임시 테이블을 사용하는 명령문을 가지고 있는 경우에는 문제가 발생하게 된다. 맨 처음의
mysql 프로세스가 종료될 때, 서버는 임시 테이블을 제거한다. 두 번째 mysql 프로세스가 이 테이블을 사용하고자 시도하면, 서버
는 “unknown table.”이라고 알려주게 된다.
이와 같은 문제를 없애기 위해서는, 여러분이 처리하고자 하는 모든 바이너리 로그 컨텐츠에 대해서 한번의 접속을 사용하도록 한
다. 아래에 이렇게 하는 방법을 보여준다:
shell> mysqlbinlog binlog.000001 binlog.000002 | mysql
또 다른 방식은 모든 로그를 하나의 파일에 작성을 하고 이 파일을 처리하는 것이다:
shell> mysqlbinlog binlog.000001 > /tmp/statements.sql
shell> mysqlbinlog binlog.000002 >> /tmp/statements.sql
shell> mysql -e "source /tmp/statements.sql"
mysqlbinlog는 원본 데이터 파일을 사용하지 않고 LOAD DATA INFILE 연산을 재 실행하는 결과를 만들어 낸다. mysqlbinlog
은 그 데이터를 임시 파일에 복사를 하고 이 파일을 참조하는 LOAD DATA LOCAL INFILE 명령문을 작성한다. 이 파일이 작성
되는 디폴트 디렉토리의 위치는 시스템에 따라 달라진다. 이 디렉토리를 명확히 지정하기 위해서는 --local-load 옵션을 사용한
다.
mysqlbinlog이 LOAD DATA INFILE 명령문을 LOAD DATA LOCAL INFILE 명령문으로 변환 시키기 때문에 (즉, LOCAL를
추가 함), 이 명령문을 처리하는 클라이언트 및 서버 모두는 반드시 LOCAL 기능을 처리할 수 있도록 구성되어야 한다.
Section 5.7.4, “LOAD DATA LOCAL를 사용한 보안 이슈”를 참조.
Warning: LOAD DATA LOCAL 명령문용으로 생성된 임시 파일은 여러분이 실제로 이 명령문을 실행할 때까지 필요한 것이기 때
문에 자동으로 삭제가 되지 않는다. 더 이상 이 명령문의 로그가 필요하지 않게 되면 그 때에 임시 파일을 삭제 하도록 한다. 이 파
일은 임시 파일 디렉토리에서 찾을 수 있으며 original_file_name-#-#와 같은 이름을 가지고 있다.
--hexdump 옵션은 코멘트에서 로그 컨텐츠에 대한 헥스(hex) 덤프를 만든다:

:::MySQL Korea:::
shell> mysqlbinlog --hexdump master-bin.000001
위의 명령어를 사용하면, 아래와 같은 결과가 만들어진다:
/*!40019 SET @@session.max_insert_delayed_threads=0*/;
/*!50003 SET @OLD_COMPLETION_TYPE=@@COMPLETION_TYPE,COMPLETION_TYPE=0*/;
# at 4
#051024 17:24:13 server id 1 end_log_pos 98
# Position Timestamp Type Master ID Size Master Pos Flags
# 00000004 9d fc 5c 43 0f 01 00 00 00 5e 00 00 00 62 00 00 00 00 00
# 00000017 04 00 35 2e 30 2e 31 35 2d 64 65 62 75 67 2d 6c |..5.0.15.debug.l|
# 00000027 6f 67 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |og..............|
# 00000037 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 |................|
# 00000047 00 00 00 00 9d fc 5c 43 13 38 0d 00 08 00 12 00 |.......C.8......|
# 00000057 04 04 04 04 12 00 00 4b 00 04 1a |.......K...|
# Start: binlog v 4, server v 5.0.15-debug-log created 051024 17:24:13
# at startup
ROLLBACK;

:::MySQL Korea:::
헥스 덤프로 만들어지는 결과에는 아래와 같은 것들이 포함된다. 이 포맷은 나중에 변경될 예정이다.
● Position: 로그 파일 안에 있는 바이트 위치.

● Timestamp: 이벤트 타임 스탬프. 위의 예문에서 보면, '9d fc 5c 43'은 헥사데시멀(hexadecimal) '051024 17:24:13'의
다른 표현식이다.
● Type: 로그 이벤트의 타입. 위의 예문에서 보면, '0f'는 예문의 이벤트가 FORMAT_DESCRIPTION_EVENT라는 것을 의
미한다. 아래에서는 가능한 타입을 열거하고 있다.
Type Name Meaning
00 UNKNOWN_EVENT This event should never be present in the log.
01 START_EVENT_V3 This indicates the start of a log file written by MySQL 4 or earlier.
The most common type of events. These contain statements executed

02 QUERY_EVENT
on the master.
03 STOP_EVENT Indicates that master has stopped.
04 ROTATE_EVENT Written when the master switches to a new log file.
Used mainly for AUTO_INCREMENT values and when the

05 INTVAR_EVENT
LAST_INSERT_ID() function is used in the statement.
06 LOAD_EVENT Used for LOAD DATA INFILE in MySQL 3.23.
07 SLAVE_EVENT Reserved for future use.
Used for LOAD DATA INFILE statements. This indicates the start of
08 CREATE_FILE_EVENT execution of such a statement. A temporary file is created on the slave.
Used in MySQL 4 only.
Contains data for use in a LOAD DATA INFILE statement. The data is
09 APPEND_BLOCK_EVENT
stored in the temporary file on the slave.
Used for LOAD DATA INFILE statements. The contents of the

0a EXEC_LOAD_EVENT
temporary file is stored in the table on the slave. Used in MySQL 4 only.
Rollback of a LOAD DATA INFILE statement. The temporary file should

0b DELETE_FILE_EVENT
be deleted on slave.

:::MySQL Korea:::
0c NEW_LOAD_EVENT Used for LOAD DATA INFILE in MySQL 4 and earlier.
Used to send information about random values if the RAND() function is

0d RAND_EVENT
used in the statement.
0e USER_VAR_EVENT Used to replicate user variables.
0f FORMAT_DESCRIPTION_EVENT This indicates the start of a log file written by MySQL 5 or later.
10 XID_EVENT Event indicating commit of an XA transaction.
11 BEGIN_LOAD_QUERY_EVENT Used for LOAD DATA INFILE statements in MySQL 5 and later.
12 EXECUTE_LOAD_QUERY_EVENT Used for LOAD DATA INFILE statements in MySQL 5 and later.
13 TABLE_MAP_EVENT Reserved for future use.
14 WRITE_ROWS_EVENT Reserved for future use.
15 UPDATE_ROWS_EVENT Reserved for future use.
16 DELETE_ROWS_EVENT Reserved for future use.
● Master ID: 이벤트를 생성한 마스터의 서버 ID.

● Size: 이벤트의 바이트 단위 크기.
● Master Pos: 원본 마스터 로그 파일에 있는 이벤트의 위치.
● Flags: 16 플래그. 현재까지는, 아래의 플래그들이 사용된다. 나머지들은 향후에 사용될 예정이다.
Flag Name Meaning
Log file correctly closed. (Used only in

FORMAT_DESCRIPTION_EVENT.) If this flag is set (if the flags are,
01 LOG_EVENT_BINLOG_IN_USE_F for example, '01 00') in a FORMAT_DESCRIPTION_EVENT, the log file
has not been properly closed. Most probably this is because of a master
crash (for example, due to power failure).
02 Reserved for future use.

:::MySQL Korea:::
Set if the event is dependent on the connection it was executed in (for

04 LOG_EVENT_THREAD_SPECIFIC_F
example, '04 00'), for example, if the event uses temporary tables.
Set in some circumstances when the event is not dependent on the

08 LOG_EVENT_SUPPRESS_USE_F
default database.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.9. mysqlcheck - 테이블 관리(Maintenance) 및 복구 프로그램
8.9. mysqlcheck - 테이블 관리 mysqlcheck 클라이언트는 테이블을 검사, 복구, 최적화, 그리고 분석을 한다.
(Maintenance) 및 복구 프로그램
8.9 mysqlcheck - 테이블 관리(Maintenance) mysqlcheck는 myisamchk과 유사한 기능을 구현하지만, 전혀 다른 방식으로 동작을 한다. 가장 주된 차이점은, mysqlcheck는
및 복구 프로그램 mysqld 서버가 구동될 때만 사용될 수 있는데 비해서, myisamchk는 이 서버가 없는 경우에도 사용될 수 있다는 점이다.
mysqlcheck를 사용할 때 얻을 수 있는 장점으로는 여러분이 테이블을 검사하기 위해서 서버를 종료할 필요가 없다는 것이다.
mysqlcheck은 SQL 명령문인 CHECK TABLE, REPAIR TABLE, ANALYZE TABLE, 그리고 OPTIMIZE TABLE를 사용자
입장에서 편리하게 사용한다. 이것은 여러분이 원하는 연산을 위해서 어떤 명령문을 사용할 것인지를 판단하고, 서버에게 이 명령
문을 전달해서 실행을 하도록 만든다. 각각의 명령문이 함께 실행하는 스토리지 엔진에 대해서는 Chapter 13, SQL 명령문 신텍스
를 참조하면 된다.
MyISAM 스토리지 엔진은 위의 4 가지 명령문을 모두 지원하며, 따라서 mysqlcheck는 MyISAM 테이블에서 위의 4 가지 연산

을 모두 실행할 수가 있다. 다른 스토리지 엔진은 이것들을 모두 지원하지는 않는다. 이와 같은 명령문 처리를 위해 다른 엔진을 사
용하는 경우에는, 에러 메시지가 나타나게 된다. 예를 들면, 만일 test.t이 하나의 MEMORY 테이블이라면, 이것을 검사하고자 하
는 시도는 아래와 같은 결과를 만들게 된다:
shell> mysqlcheck test t
test.t
note : The storage engine for the table doesn't support check
mysqlcheck를 호출하는 방법에는 일반적으로 3 가지가 있다:

:::MySQL Korea:::
shell> mysqlcheck [options] db_name [tables]
shell> mysqlcheck [options] --databases db_name1 [db_name2 db_name3...]
shell> mysqlcheck [options] --all-databases
만일 여러분이 db_name 다음에 어떠한 테이블 이름도 지정하지 않거나 또는 여러분이 --databases 또는 --all-databases 옵
션을 사용하는 경우에는, 전체 데이터 베이스가 검사된다.
mysqlcheck는 다른 클라이언트 프로그램과 비교해서 특별한 특성이 하나 있다. 테이블 검사에 대한 디폴트 동작 (--check)은
바이너리의 이름을 재 지정함으로써 변경 시킬 수가 있다. 만일 여러분이 디폴트로 테이블을 복구하는 툴을 가지고가 한다면, 간단
히 mysqlcheck를 mysqlrepair이름으로 복사를 하거나, 또는 mysqlcheck를 mysqlrepair라는 이름으로 심볼릭 링크를 만들기
만 하면 된다. 만일 여러분이 mysqlrepair를 호출한다면, 이것은 테이블을 복구하게 된다.
아래의 이름들은 mysqlcheck의 디폴트 동작을 변경 시킬 때 사용할 수 있는 것들이다:
mysqlrepair The default option is --repair
mysqlanalyze The default option is --analyze
mysqloptimize The default option is --optimize
mysqlcheck는 아래의 옵션을 지원한다:
● --help, -?
● --all-databases, -A
모든 데이터 베이스에 있는 모든 테이블을 검사한다. 이것은 --databases 옵션을 사용하고 명령어 라인에서 모든 데이
터 베이스 이름을 지정하는 것과 동일한 기능을 한다.

:::MySQL Korea:::
● --all-in-1, -1
각 테이블에 대해서 명령문을 하나씩 입력하는 대신에, 실행 시키고자 하는 데이터 베이스에 있는 모든 테이블 이름을 가
지고 있는 각 데이터 베이스에 대해서 하나의 명령문을 실행 시킨다.
● --analyze, -a
테이블을 분석한다.
● --auto-repair
만일 검사를 한 테이블이 깨졌다면, 자동으로 이것을 복구 시킨다. 모든 테이블을 검사한 후에 필요한 모든 복구를 실행한
다.
● --check, -c
테이블 에러를 검사한다. 이것은 디폴트 연산이다.
● --check-only-changed, -C
마지막 검사를 한 후에 변경된 테이블 또는 올바르게 닫히지 않은 테이블만 검사한다.
● --check-upgrade, -g
서버의 현재 버전과 호환성이 없는 테이블을 검사하기 위해서 CHECK TABLE를 FOR UPGRADE 옵션과 함께 호출한
다. 이 옵션은 MySQL 5.0.19 에서 추가 되었다.
● --compress

:::MySQL Korea:::
클라이언트 및 서버가 모두 압축을 지원한다면, 이 두 서버간의 전달되는 모든 정보를 압축시킨다.
● --databases, -B
네임드 데이터 베이스에 있는 모든 테이블을 처리한다. 일반적인 경우, mysqlcheck는 명령어라인에 있는 첫 번째 이름을
데이터 베이스 이름을 간주하고 그 다음의 이름을 테이블 이름으로 간주한다. 이 옵션을 사용하면, 모든 이름 인수를 데이
터 베이스 이름으로 간주하게 된다.
디버깅 로그를 작성한다. 전형적인 debug_options 스트링은 'd:t:o,file_name'.
charset_name를 디폴트 문자 셋으로 사용한다. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”를 참조할
것.
● --extended, -e
만일 여러분이 이 옵션을 사용해서 테이블을 검사한다면, 시간은 오래 걸리지만 100%의 일관성을 보장받을 수가 있다.
만일 이 옵션을 테이블 복구용으로 사용한다면, 복구하는데 시간이 오래 걸릴 뿐만 아니라 필요 없는 열도 많이 생성되게
된다!
● --fast, -F
올바르게 닫히지 않은 테이블만 검사한다.
● --force, -f
SQL 에러가 발생하더라도 계속 진행한다.

:::MySQL Korea:::
주어진 호스트에 있는 MySQL 서버에 접속을 한다.
● --medium-check, -m
--extended 연산 보다는 빠른 검사를 실행한다. 이것은 모든 에러에 대해서 99.99%의 신뢰도를 보장하는데, 대부분의
경우 이 정도면 충분하다.
● --optimize, -o
테이블을 최적화 시킨다.
서버에 접속을 할 때 사용할 패스워드. 만일 축약형 옵션(-p)을 사용할 경우에는, 이 옵션과 패스워드 사이에는 스페이스
를 두지 말도록 한다. 만일 --password 또는 -p 옵션 다음에 패스워드를 지정하지 않으면, 프롬프트가 나오게 된다.
접속용으로 사용하는 TCP/IP 포트 번호.
● --quick, -q
이 옵션을 사용해서 테이블을 검사한다면, 잘못된 링크를 검사하기 위한 열 스캐닝을 검사하지 못하도록 한다. 이 방법이
가장 빠른 검사 방법이다.
이 옵션을 사용해서 테이블을 복구한다면, 이것은 인덱스 트리만을 복구하려고 할 것이다. 가장 빠른 복구 방법이다.
● --repair, -r

:::MySQL Korea:::
유니크(unique)하지 않은 유니크 키를 제외하고 거의 모든 것을 복구시킨다.
● --silent, -s
침묵 모드(Silent mode). 에러 메시지만을 출력한다.
localhost에 접속하는 경우, 사용할 유닉스 소켓 파일, 또는 윈도우 네임드 파이프 이름.
● --tables
--databases 또는 -B 옵션을 무력화 시킨다(override). 이 옵션 다음에 나오는 모든 이름 인수는 테이블 이름으로 간

주된다.
● --use-frm
MyISAM 테이블에서의 복구 연산의 경우, 테이블의 .MYI 헤더가 깨졌다고 하더라도 테이블 복구를 실행하기 위해서 .
frm 파일로부터 테이블 구조를 가져온다.
서버에 접속을 할 때 사용하는 MySQL 사용자 이름.
● --verbose, -v
버보스 모드(Verbose mode). 프로그램 연산의 다양한 단계 정보를 출력한다.
● --version, -V
버전 정보를 출력하고 빠져 나옴.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.10. mysqldump - 데이터 베이스 백업 프로그램
8.10. mysqldump - 데이터 베이스 백업 프로 mysqldump 클라이언트는 Igor Romanenko가 작성한 백업 프로그램이다. 이것은 데이터베이스를 덤프하거나 또는 백업 또는 데
그램 이터를 다른 SQL 서버(MySQL서버가 아닌)에 전달하기 위해서 데이터 베이스를 모을 때 사용하는 프로그램이다. 덤프에는 테이
8.10 mysqldump - 데이터 베이스 백업 프로그램 블을 생성하거나 또는 안주(populate)시키기 위한 SQL명령문이 포함되어 있다.
만일 여러분이 서버에서 백업을 진행하고 있고, 또한 여러분이 사용하는 테이블이 MyISAM 테이블이라면, mysqlhotcopy를 대신
사용하는 것이 좋은데, 그 이유는 이것이 보다 빠른 백업과 복원을 실행하기 때문이다. Section 8.11, “mysqlhotcopy — 데이터
베이스 백업 프로그램”을 참조할 것.
mysqldump를 호출하는 데에는 일반적으로 세 가지 방법이 있다:
shell> mysqldump [options] db_name [tables]
shell> mysqldump [options] --databases db_name1 [db_name2 db_name3...]
shell> mysqldump [options] --all-databases
If you do not name any tables following db_name or if you use the --databases or --all-databases option, entire
databases are dumped.
To get a list of the options your version of mysqldump supports, execute mysqldump --help.
만일 mysqldump를 --quick 또는 --opt 옵션이 없이 사용한다면, mysqldum는 결과를 덤프하기 전에 전체 결과 셋을 메모리

로 읽어오게 된다. 만일 대형 데이터 베이스를 덤프할 경우에는 이것은 문제가 된다. --opt 옵션은 디폴트로 활성화 되어 있으나,
--skip-opt로 비활성화 시킬 수가 있다.

:::MySQL Korea:::
만일 여러분이 최근의 mysqldump 프로그램을 사용해서 구형 MySQL 서버로 덤프를 실행하고자 한다면, --opt 또는 --
extended-insert 옵션을 사용하지 말도록 한다. 대신에 --skip-opt 옵션을 사용한다.
mysqldump는 아래의 옵션을 지원한다:
● --help, -?
● --add-drop-database
DROP DATABASE 명령문은 각각의 CREATE DATABASE 명령문 전에 추가 한다.
● --add-drop-table
DROP TABLE 명령문을 각각의 CREATE TABLE 명령문 전에 추가한다.
● --add-locks
Surround each table dump with LOCK TABLES 과 UNLOCK TABLES 명령문을 사용해서 각각의 테이블 덤프를 둘
러 싼다(surround). 이렇게 하면 덤프 파일을 다시 읽어올 때 보다 빠른 삽입을 실행할 수가 있다. Section 7.2.16,
“INSERT 명령문의 속도”를 참조.
● --all-databases, -A
모든 데이터 베이스에 있는 모든 테이블을 덤프한다. 이것은 --databases 옵션을 사용해서 명령어 라인에서 모든 데이
터 베이스 이름을 입력하는 것과 동일한 기능을 실행한다.
● --allow-keywords
키 워드 이름을 사용해서 컬럼을 생성하는 것을 허용한다.

:::MySQL Korea:::
● --comments, -i
프로그램 버전, 서버 버전, 그리고 호스트와 같은 추가적인 정보를 덤프 파일에 기록한다. 이 옵션은 디폴트로 활성화 된
다. --skip-comments를 사용하면, 디폴트 활성화를 없앨 수 있다.
● --compact
간략한 결과를 만들게 한다. 이 옵션은 코맨트를 없애주며 --skip-add-drop-table, --no-set-names, --skip-
disable-keys, 그리고 --skip-add-locks 옵션을 활성화 시킨다.
● --compatible=name
다른 데이터 시스템 또는 구형 MySQL 서버와의 호환성을 보다 많이 갖도록 결과를 만든다. name의 값은 ansi,
mysql323, mysql40, postgresql, oracle, mssql, db2, maxdb, no_key_options, no_table_options, 또는
no_field_options가 될 수 있다. 여러 개의 값을 사용하기 위해서는, 각각을 콤마로 구분시킨다. 이러한 값들은 서버 SQL
모드를 설정하기 위한 대응 값들과 동일한 의미를 갖게 된다. Section 5.2.5, “서버 SQL 모드”를 참조할 것.
이 옵션은 다른 서버와의 호환성을 보장하지는 않는다. 단지 덤프를 한 결과가 다른 SQL 서버와 호환성을 보다 많이 가지
도록 만들어줄 뿐이다. 예를 들면, --compatible=oracle는 오라클 타입의 데이터 또는 코멘트 신텍스와 매핑되는 것은
아니다.
● --complete-insert, -c
컬럼 이름을 가지고 있는 완벽한 INSERT 명령문을 사용한다.
● --compress, -C
클라이언트 및 서버가 압축을 지원할 경우, 두 서버간에 전달되는 정보를 압축한다.

:::MySQL Korea:::
● --create-options
CREATE TABLE 명령문에 모든 MySQL 관련 테이블 옵션을 포함시킨다.
● --databases, -B
여러 개의 데이터 베이스를 덤프한다. 일반적으로, mysqldump는 명령어라인에 있는 첫 번째 이름을 데이터 베이스 이름

을 간주하고 그 다음의 이름을 테이블 이름으로 간주한다. 이 옵션을 사용하면, 모든 이름 인수를 데이터 베이스 이름으로
간주하게 된다. CREATE DATABASE 및 USE 명령문은 각각의 새로운 데이터 베이스 전에 결과에 포함된다.
디버깅 로그를 작성한다. debug_options 스트링은 종종 'd:t:o,file_name'가 된다. 디폴트는 'd:t:o,/tmp/mysqldump.

trace'.
charset_name를 디폴트 문자 셋으로 사용한다. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”을 참조. 만
일 지정하지 않으면, mysqldump은 utf8를 사용한다.
● --delayed-insert
INSERT DELAYED 명령문을 INSERT 명령문 대신에 작성한다.
● --delete-master-logs
마스터 리플리케이션 서버에서, 덤프 연산을 실행한 후에 바이너리 로그를 삭제한다. 이 옵션은 자동으로 --master-
data를 활성화 시킨다.
● --disable-keys, -K
각각의 테이블에 대해서, INSERT 명령문을 /*!40000 ALTER TABLE tbl_name DISABLE KEYS */; 그리고 /*!

:::MySQL Korea:::
40000 ALTER TABLE tbl_name ENABLE KEYS */; 명령문을 사용해서 둘러싼다(surround). 이것은 모든 열이 삽입
된 후에 인덱스가 생성되기 때문에 덤프 파일을 읽어 오는데 보다 빠른 속도가 나오게 된다. 이 옵션은 MyISAM 테이블
에 대해서만 효과가 있다.
● --extended-insert, -e
여러 개의 VALUES 리스트를 가지고 있는 다중-열 INSERT 신텍스를 사용한다.이렇게 하면 덤프 파일이 작아지고 파일

을 다시 읽어 올 때 삽입 속도를 빠르게 할 수가 있다.
● --fields-terminated-by=..., --fields-enclosed-by=..., --fields-optionally-enclosed-by=..., --fields-

escaped-by=..., --lines-terminated-by=...
이들 옵션은 -T 옵션과 함께 사용되며 LOAD DATA INFILE에 대한 대응 구문과 같은 의미를 가진다. Section 13.2.5,
“LOAD DATA INFILE 신텍스”를 참조.
● --first-slave, -x
기능 삭제됨. 현재는 --lock-all-tables로 바뀌었음.
● --flush-logs, -F
덤프를 시작하기 전에 MySQL 서버 로그 파일을 플러시한다. 이 옵션은 RELOAD 권한을 필요로 한다. 만일 여러분이 이
옵션을 --all-databases (또는 -A) 옵션과 함께 결합해서 사용한다면, 로그는 각각의 덤프된 데이터 베이스에 대해서
플러시 된다는 점을 알아야 한다. 한가지 예외는 --lock-all-tables 또는 --master-data를 사용하는 경우이다: 이와
같은 경우, 로그는 모든 테이블이 잠기는 시점에 오직 한번만 플러시된다. 만일 동일한 시점에 덤프 및 로그 플러시가 일어
나도록 하기 위해서는, --flush-logs를 --lock-all-tables 또는 --master-data와 함께 사용하도록 한다.
● --force, -f
테이블 덤프를 하는 동안 SQL 에러가 발생하더라도 계속 진행 시킨다.

:::MySQL Korea:::
주어진 호스트에 있는 MySQL 서버에서 데이터를 덤프한다. 디폴트 호스트는 localhost.
● --hex-blob
16진법(hexadecimal)을 사용해서 바이너리 컬럼을 덤프한다 (예를 들면, 'abc'는 0x616263가 된다). 이렇게 할 수 있
는 데이터 타입은 BINARY, VARBINARY, 그리고 BLOB가 된다. MySQL 5.0.13까지는, BIT 컬럼도 해당된다.
● --ignore-table=db_name.tbl_name
주어진 테이블을 덤프하지 않는데, 이것은 데이터 베이스 및 테이블 이름을 사용해서 지정해야 한다. 여러 개의 테이블을
무시하기 위해서는, 이 옵션을 여러 번 사용한다.
● --insert-ignore
INSERT 명령문을 IGNORE 옵션과 함께 작성한다.
● --lock-all-tables, -x
모든 데이터 베이스에 걸쳐서 모든 테이블을 잠근다. 이것은 전체 덤프 주기에 대한 글로벌읽기 잠금을 통해 얻을 수 있

다. 이 옵션은 자동으로 --single-transaction --lock-tables를 오프(Off)시킨다.
● --lock-tables, -l
덤프를 하기 전에 모든 테이블을 잠근다. MyISAM 테이블의 경우에는 동시 삽입을 허용하기 위해서 테이블을 READ
LOCAL로 잠근다. InnoDB 및 BDB와 같은 트랜젝션이 되는 테이블의 경우, --single-transaction이 보다 좋은 옵션이
되는데, 그 이유는 이것은 테이블을 전혀 잠글 필요가 없기 때문이다.
여러 개의 데이터 베이스를 덤프할 때에는, --lock-tables은 각각의 데이터 베이스에 대해서 테이블을 개별적으로 잠근
다는 점을 알아두기 바란다. 따라서, 이 옵션은 덤프 파일에 있는 테이블이 데이터 베이스간에 논리적으로 일관성을 가지
는 것에 대해서는 보장을 하지 않는다. 서로 다른 데이터 베이스에 있는 테이블들은 완벽하게 틀린 상태에서 덤프가 된다.
● --master-data[=value]

:::MySQL Korea:::
바이너리 로그 파일 이름과 위치(position)을 결과에 작성한다. 이 옵션은 RELOAD 권한이 필요하고 바이너리 로그는 반
드시 활성화 되어야 한다. 만일 이 옵션 값이 1 이면, 그 위치 및 파일 이름은 CHANGE MASTER 명령문 형태로 덤프 결
과에 작성되는데, 이것은 여러분이 슬레이브를 설정하기 위해 이 SQL 덤프를 사용하는 경우에 슬레이브 서버로 하여금 마
스터의 바이너리 로그에 있는 올바른 위치에서 시작을 하도록 만든다. 만일 이 옵션 값이 2와 같다면, CHANGE
MASTER 명령문은 SQL 코멘트처럼 작성된다. 만일 값이 생략되면, 이것이 디폴트 동작이 된다.
--master-data 옵션은 --single-transaction을 함께 지정하지 않는 한, --lock-all-tables를 온(ON) 시킨다 (이
와 같은 경우, 글로벌 읽기 잠금은 덤프가 시작되는 짧은 시점에만 얻을 수 있다). --single-transaction에 대한 설명을
함께 참조한다. 모든 경우에, 로그 상의 모든 동작은 정확히 덤프가 일어나는 시점에 발생을 한다. 이 옵션은 자동으로 --
lock-tables를 오프(Off) 시킨다.
● --no-autocommit
각각의 덤프된 테이블에 대한 INSERT 명령문을 SET AUTOCOMMIT=0 과COMMIT 명령문안에 넣는다.
● --no-create-db, -n
이 옵션은 --databases 또는 --all-databases 옵션이 주어질 경우에 결과에 포함되는 CREATE DATABASE 명령문
을 무력화 시킨다.
● --no-create-info, -t
각각의 덤프된 테이블을 다시 생성하는 CREATE TABLE 명령문을 작성하지 않는다.
● --no-data, -d
테이블에 대한 어떠한 열 정보도 작성하지 않는다. 이것은 테이블에 대해서 CREATE TABLE 명령문만을 덤프하고자 할
경우에 매우 유용하다.
● --opt
이 옵션은 축약형이다; 이것은 --add-drop-table --add-locks --create-options --disable-keys --

:::MySQL Korea:::
extended-insert --lock-tables --quick --set-charset를 지정하는 것과 같다. 이 옵션은 빠른 덤프 연산을 실행

하며 MySQL 서버로 빠르게 다시 읽혀지는 덤프 파일을 만들어 낸다.
이 옵션은 디폴트로 활성화 되어 있지만, --skip-opt를 사용해서 비 활성화 시킬 수가 있다. –opt에 의해서 활성화된
특정 옵션만을 비활성화 시키기 위해서는, 해당 옵션의 --skip 형태를 사용한다; 예를 들면, --skip-add-drop-table
또는 --skip-quick.
● --order-by-primary
주요(primary) 키 또는 맨 처음의 유니크 인덱스(만일 인덱스가 존재한다면)를 사용해서 각각의 테이블 열을 정렬한다.
이것은 InnoDB 테이블 안으로 집어넣을 MyISAM 테이블을 덤프할 때 유용하게 사용되지만, 덤프 자체를 매우 오래 걸리
게 한다.
서버에 접속을 할 때 사용하는 패스워드.
접속용으로 사용할 TCP/IP 포트 번호.
접속용 프로토콜.
● --quick, -q
이 옵션은 대형 테이블을 덤프할 때 유용하다. 이것은 mysqldump로 하여금 테이블에 대한 열을 서버에서 한번에 한 열
씩 추축하도록 만들고 추출한 열을 쓰기 전에 메모리에 버퍼링 하도록 만든다.
● --quote-names, -Q
인용 부호를 사용해서 데이터 베이스, 테이블, 그리고 컬럼 이름을 둘러 쌓도록 한다. 만일 ANSI_QUOTES SQL 모드가

:::MySQL Korea:::
활성화 되어 있다면, 그 이름도 인용 부호화 시킨다. 이 옵션은 디폴트로 활성화 되어 있다. 이것은 --skip-quote-
names으로 비 활성화 시킬 수 있으나, 이 옵션은 --quote-names을 활성화 시킬 수 있는 –-compatible과 같은 옵션
다음에 주어져야 한다.
● --result-file=file, -r file
주어진 파일로 결과를 직접 넣는다. 이 옵션은 윈도우에서 새 라인 문자 ‘￦n’가 ‘￦r￦n’ 캐리지 리턴/새 라인 시퀀
스로 변환되지 못하도록 하기 위해서 사용된다.
● --routines, -R
덤프된 데이터 베이스에서 스토어드 루틴(함수 및 프로시저)를 덤프한다. --routines을 사용해서 만들어지는 결과는
CREATE PROCEDURE 루틴을 재 생성하기 위한 CREATE FUNCTION 명령문을 갖게 된다. 하지만, 이러한 명령문들
은 루틴 생성 및 수정 타임 스탬프와 같은 속성을 가지지 않는다. 이것은 루틴이 리로드(reload)될 때, 리로드 시간과 동일
한 타임 스탬프를 가지고서 생성된다는 것을 의미한다.
만일 여러분이 재 생성될 루틴이 원래의 타임 스탬프 속성을 가지도록 하기 위해서는, --routines를 사용하지 말도록 한
다. 대신에, mysql 데이터 베이스에 대해 적절한 권한을 가지고 있는 MySQL 계정을 사용해서 mysql.proc 테이블의 내
용물을 직접 덤프 및 리로드 하도록 한다.
이 옵션은 MySQL 5.0.13 에 추가되었다. 이 버전 이전에는 스토어드 루틴을 덤프할 수가 없었다. 루틴 DEFINER 값은
5.0.20 이후에 덤프가 되었다. 이것은 5.0.20 이전에는, 루틴이 리로드될 때, 리로딩 사용자에 대해서 디파이너(definer)
셋을 가지고 생성된다는 것을 의미하는 것이다. 만일 루틴이 원래의 디파이너를 가지고 재 생성되도록 하고자 한다면, 앞
에서 설명한 방식으로 mysql.proc 테이블의 내용물을 직접 덤프 및 로드한다.
● --set-charset
SET NAMES default_character_set를 결과에 추가한다. 이 옵션은 디폴트로 활성화 된다. SET NAMES 명령문을 무
시하기 위해서는, --skip-set-charset를 사용한다.
● --single-transaction
이 옵션은 서버에서 데이터를 덤프하기 전에 BEGIN SQL 명령문을 실행한다. 이것은 InnoDB 및 BDB와 같은 트랜젝션
이 되는 테이블에서만 유용한데, 그 이유는 이것이 BEGIN이 다른 어플리케이션을 블러킹하지 않은 채로 입력될 때 데이

:::MySQL Korea:::
터 베이스를 일관성 있게 담프하기 때문이다.

이 옵션을 사용할 때, 여러분은 InnoDB 테이블만이 일관성 있게 덤프된다는 점을 알고 있어야 한다. 예를 들면, 이 옵션
을 사용할 때 덤프되는 MyISAM 또는 MEMORY 테이블은 상태가 변경될 수도 있다.
--single-transaction 옵션과 --lock-tables 옵션은 상호 배타적인데(mutually exclusive), 그 이유는 LOCK
TABLES이 암묵적으로 실행되는 트랜젝션을 연기 시키기 때문이다.
대형 테이블을 덤프하기 위해서는, 이 옵션을 –quick과 결합해서 사용한다.
localhost에 접속하는 경우, 유닉스 소켓 파일 또는, 윈도우의 네임드 파이프 이름.
● --skip-comments
--comments 옵션에 대한 설명을 참조한다.
● --tab=path, -T path
탭으로 구분된 데이터 파일을 만든다. 각가의 덤프 테이블의 경우, mysqldump은 테이블을 생성하는 CREATE TABLE
명령문을 갖는 tbl_name.sql 파일과, 그것의 데이터를 가지고 있는 tbl_name.txt 파일을 생성한다. 이 옵션 값은 파일을
작성하는 디렉토리가 된다.
디폴트로는t, .txt 데이터 파일이 컬럼 값과 각 라인의 끝에 있는 새 라인(newline) 값 사이에 탭 문자를 사용해서 포맷된
다. 이 포맷은 --fields-xxx 및 --lines--xxx 옵션을 사용해서 명확하게 지정될 수 있다.
Note: 이 옵션은 mysqldump가 mysqld 서버가 구동되는 서버에서 실행될 때에만 사용될 수 있다. 여러분은 반드시
FILE 권한이 있어야 하고, 또한 서버는 반드시 여러분이 지정하는 디렉토리에 파일을 작성할 수 있어야 한다.
● --tables
--databases 또는 -B 옵션을 무력화 시킨다. 이 옵션 다음에 나오는 모든 이름 인수는 테이블 이름으로 간주된다.
● --triggers

:::MySQL Korea:::
각각의 덤프 테이블에 대한 트리거를 덤프한다. 이 옵션은 디폴트로 활성화 되어 있다; --skip-triggers로 비 활성화 시
킬 수 있다.이 옵션은 MySQL 5.0.11 에 추가 되었다. 이전에는, 트리거를 덤프할 수 없었다.
● --tz-utc
SET TIME_ZONE='+00:00'를 덤프 파일에 추가해서 TIMESTAMP 컬럼이 서로 다른 타임 존에 있는 서버간에 덤프되

고 리로드될 수 있도록 한다. 이 옵션을 사용하지 않으면, TIMESTAMP 컬럼은 로컬 및 목적 서버의 타임 존에 덤프 및
리로드 되고, 이 결과로 인해 값이 변하게 된다. --tz-utc는 디폴트로 활성화 되어 있고, --skip-tz-utc를 사용해서
비활성화 시킬 수가 있다. 이 옵션은 MySQL 5.0.15 에서 추가 되었다.
서버에 접속할 때 사용되는 MySQL 사용자 이름.
● --verbose, -v
버보스 모드 (Verbose mode). 프로그램이 실행하는 정보를 보다 자세히 출력한다.
● --version, -V
● --where='where_condition', -w 'where_condition'
주어진 WHERE 조건문에 의해 선택된 열만을 덤프한다. 만일 스페이스 또는 다른 문자가 여러분이 사용하는 명령어 해석
기에서 특별하게 인식되는 경우에는 인용부호를 사용해야 한다.
Examples:
--where="user='jimf'"
-w"userid>1"
-w"userid<1"

:::MySQL Korea:::
● --xml, -X
덤프 결과를 XML 형태로 출력한다.
또한, --var_name=value 신텍스를 사용해서 아래의 변수를 지정할 수도 있다:
● max_allowed_packet
클라이언트/서버 통신용 버퍼의 최대 크기. 최대 크기는 1GB.
● net_buffer_length
클라이언트/서버 통신용 버퍼의 초기 크기. 다중-열-삽입 명령문을 생성할 때 (--extended-insert or –opt 옵션을
사용하는 것과 같이), mysqldump는 열을 최대 net_buffer_length 길이 만큼 만든다. 만일 여러분이 이 변수의 값을 늘린
다면, MySQL 서버에 있는 net_buffer_length 변수가 최소한 이 만큼의 크기가 되는지를 확인해야 한다.
mysqldump의 가장 일반적인 사용은 아마도 전체 데이터 베이스에 대한 백업용일 것이다:
shell> mysqldump --opt db_name > backup-file.sql
또한 덤프 받은 파일을 아래와 같이 서버로 다시 읽어 올 수도 있다:
shell> mysql db_name < backup-file.sql
또는 아래와 같이 한다:
shell> mysql -e "source /path-to-backup/backup-file.sql" db_name
mysqldump는 또한 하나의 MySQL 서버에서 다른 MySQL 서버로 데이터를 복사해서 데이터 베이스를 안주 시키기 위한 용도로
매우 유용하게 사용할 수가 있다:

:::MySQL Korea:::
shell> mysqldump --opt db_name | mysql --host=remote_host -C db_name
하나의 명령어를 사용해서 여러 개의 데이터 베이스를 덤프하는 것도 가능하다:
shell> mysqldump --databases db_name1 [db_name2 ...] > my_databases.sql
모드 데이터 베이스를 덤프하기 위해서는, --all-databases 옵션을 사용하면 된다:
shell> mysqldump --all-databases > all_databases.sql
InnoDB 테이블의 경우, mysqldump는 온라인 백업이 가능하도록 한다:
shell> mysqldump --all-databases --single-transaction > all_databases.sql
이 백업은 덤프가 시작되는 시점에 모든 테이블에서 글로벌 읽기 잠금만 있으면 된다 (FLUSH TABLES WITH READ LOCK).
이 잠금이 이루어지면 즉시, 바이너리 로그는 읽혀지고 잠금이 릴리즈 된다. 만일 FLUSH 명령문이 실행될 때 하나의 기다란 업데
이트 명령문이 구동된다면, MySQL 서버는 이 명령문이 종료할 때까지 기다리게 되고, 덤프 연산은 잠금을 풀어 버린다. 만일
MySQL 서버가 받은 업데이트 명령문이 짧은 실행을 하는 것이라면, 초기의 잠금 기간(period)은 크게 중요하지 않게 된다.
포인트-인-타임 복구(point-in-time recovery) ( “롤-포워드(roll-forward)”라고도 알려짐)에 대해서는, 바이너리 로그

를 순환(rotate)시키거나, 또는 최소한 덤프가 대응하는 바이너리 로그 코디네이트(coordinate)를 아는 것이 유용하다:
shell> mysqldump --all-databases --master-data=2 > all_databases.sql
또는:
shell> mysqldump --all-databases --flush-logs --master-data=2
> all_databases.sql
--master-data 와 --single-transaction를 동시에 사용하면 테이블이 InnoDB 스토리지 엔진에 저장되어 있는 경우에 포인
트-인-타임 복구에 대해서 적절한 온라인 백업을 만들 수가 있게 된다.

:::MySQL Korea:::
백업 만들기에 대한 보다 자세한 정보는 Section 5.10.1, “데이터 베이스 백업”, 그리고 Section 5.10.2, “백업과 복구 전략에
대한 예제”를 참조하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.11. mysqlhotcopy — 데이터 베이스 백업 프로그램
8. 클라이언트 및 유틸리티 프로그램 Mysqlhotcopy는 Perl 스크립트로서 Tim Bunce이 작성한 프로그램이다. 이것은 데이터 베이스 백업을 빠르게 실행하기
8.11. mysqlhotcopy — 데이터 베이스 백업 프로그램 위해 LOCK TABLES, FLUSH TABLES, 그리고 cp 또는 scp를 사용한다. 이것은 데이터 베이스 또는 단일 테이블을 백
8.11 mysqlhotcopy — 데이터 베이스 백업 프로그램 업하는데 가장 빠른 방법이기는 하지만, 데이터 베이스 디렉토리가 설치되어 있는 동일 머신에서만 구동을 한다.
Mysqlhotcopy는 MyISAM 및 ARCHIVE 테이블 백업만을 할 수 있다. 이것은 유닉스와 NetWare에서 구동이 된다.
shell> mysqlhotcopy db_name [/path/to/new_directory]
shell> mysqlhotcopy db_name_1 ... db_name_n /path/to/new_directory
레귤러 수식과 매치가 되는 주어진 데이터 베이스에 있는 테이블을 백업한다:
shell> mysqlhotcopy db_name./regex/
테이블 이름에 대한 레귤러 수식은 (‘~’)를 앞에 사용해서 이름을 무시하도록 할 수 있다:
shell> mysqlhotcopy db_name./~regex/
mysqlhotcopy는 아래의 옵션을 지원한다:
● --help, -?
● --addtodest
목적 디렉토리(존재 한다면)의 이름을 변경하지 않는다; 단순히 파일을 여기에 추가만 한다.
● --allowold
목적 디렉토리가 있으면 종료를 하지 않는다; _old 접미사를 추가해서 이것의 이름을 변경 시킨다.
● --checkpoint=db_name.tbl_name

:::MySQL Korea:::
체크 포인트 엔트리를 지정 데이터 베이스 db_name 와 테이블 tbl_name에 삽입한다.
● --chroot=path
mysqld이 연산을 하는 chroot 자일(jail)의 베이스 디렉토리. path 값은 mysqld에 주어지는 --chroot 옵션과
매치가 되어야 한다.
● --debug
디버그 결과 값을 활성화 시킨다.
● --dryrun, -n
액션(action)을 실행하지 않고 레포트만 한다.
● --flushlog
모든 테이블이 잠긴 후에 로그를 플러시한다.
로컬 서버에 TCP/IP접속을 만들기 위해 사용할 로컬 호스트의 호스트 이름. 디폴트로는, 유닉스 소켓 파일을 사용
해서 localhost에 접속을 하게 된다.
● --keepold
실행을 마친 후에 이전(변경된) 목적 디렉토리를 삭제하지 않는다.
● --method=command
파일 복사를 위한 방법 (cp 또는 scp).

:::MySQL Korea:::
● --noindices
백업에 전체 인덱스 파일을 포함 시키지 않는다. 이렇게 하면 백업 파일이 작아지고 속도가 빨라진다. 다시 읽혀지
는 테이블에 대한 인덱스는 나중에 myisamchk –rq를 사용해서 구조를 변경 시킬 수가 있다.
● --password=password, -ppassword
서버에 접속을 할 때 사용할 패스워드. 이 옵션의 경우에는 다른 MySQL 프로그램과는 달리 패스워드를 반드시
지정해야 한다는 점을 알아두기 바란다. 여러분은 옵션 파일을 사용해서 패스워드를 지정할 수 있다.
로컬 서버에 접속을 할 때 사용할 TCP/IP 포트 번호.
● --quiet, -q
에러가 아니면 침묵 모드를 유지한다.
● --record_log_pos=db_name.tbl_name
마스터 및 슬레이브의 상태를 지정 데이터 베이스 db_name 과 테이블 tbl_name에 기록한다.
● --regexp=expr
주어진 레귤러 수식과 매치가 되는 이름을 사용해서 모든 데이터 베이스를 복사한다.
● --resetmaster
모든 테이블을 잠근 다음에 바이너리 로그를 리셋 시킨다.
● --resetslave

:::MySQL Korea:::
모든 테이블을 잠근 다음에 master.info 파일을 리셋 시킨다.
접속에 사용할 유닉스 소켓 파일.
● --suffix=str
복사된 데이터 베이스의 이름에 사용할 접미사.
● --tmpdir=path
임시 디렉토리. 디폴트는 /tmp.
서버에 접속을 할 때 사용할 MySQL 사용자 이름.

mysqlhotcopy는 옵션 파일에서 [client] 와 [mysqlhotcopy] 옵션 그룹을 읽는다.
mysqlhotcopy를 실행하기 위해서는, 여러분이 백업을 하는 테이블에 대한 파일에 접속을 해야 하고, 그러한 테이블에 대
한 SELECT 권한, RELOAD 권한 (FLUSH TABLES를 실행하기 위해서), 그리고 LOCK TABLES 권한 (테이블을 잠그
기 위해서)을 가지고 있어야 한다.
--checkpoint 와 --record_log_pos 옵션에 필요한 테이블의 구조에 관한 정보를 포함해서 mysqlhotcopy에 대한 추가
적인 정보를 얻고자 한다면, perldoc를 사용하도록 한다:
shell> perldoc mysqlhotcopy

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.12. mysqlimport — 데이터 임포트(Import) 프로그램
8. 클라이언트 및 유틸리티 프로그램 mysqlimport 클라이언트 프로그램은 LOAD DATA INFILE SQL 명령문에 대해서 명령어 라인 인터 페이스를 제공한
8.12. mysqlimport — 데이터 임포트(Import) 프로그램 다. mysqlimport에 대한 대부분의 옵션은 LOAD DATA INFILE 신텍스 구문과 직접적으로 상관이 된다.
8.12 mysqlimport — 데이터 임포트(Import) 프로그램 Section 13.2.5, “LOAD DATA INFILE 신텍스”를 참조할 것.
mysqlimport는 다음과 같이 호출한다:
shell> mysqlimport [options] db_name textfile1 [textfile2 ...]
명령어 라인에서 지정을 한 각각의 텍스트 파일의 경우, mysqlimport는 파일 이름에서 확장자를 떼어 낸 다음에 그 값
을 파일의 내용물을 임포트 할 테이블 이름으로 판단한다. 예를 들면, patient.txt, patient.text, 그리고 patient는 모두
patient 라는 이름의 테이블에 임포트가 된다.
mysqlimport는 아래의 옵션을 지원한다:
● --help, -?
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자 셋”을 참조할

것.
● --columns=column_list, -c column_list
이 옵션은 콤마로 구분된 컬럼 이름 리스트를 자신의 값으로 가져간다. 컬럼 이름의 순서는 데이터 파일 컬럼을
테이블 컬럼과 어떻게 매치를 시켜야 하는지를 나타낸다.
● --compress, -C

:::MySQL Korea:::
클라이언트와 서버가 압축을 지원한다면 두 서버간에 전달되는 정보를 압축한다.
디버깅 로그를 작성한다. debug_options 스트링은 'd:t:o,file_name'.
디폴트 문자 셋으로 charset_name를 사용한다. Section 5.11.1, “데이터 및 정렬을 위해 사용되는 문자

셋”을 참조할 것.
● --delete, -D
텍스트 파일을 임포팅 하기 전에 테이블을 비운다.
● --fields-terminated-by=..., --fields-enclosed-by=..., --fields-optionally-enclosed-by=..., --

fields-escaped-by=..., --lines-terminated-by=...
이 옵션들은 LOAD DATA INFILE에 대해서 상응되는 구문들과 같은 의미를 가지고 있다. Section 13.2.5,
“LOAD DATA INFILE 신텍스”를 참조할 것.
● --force, -f
에러를 무시한다. 예를 들면, 만일 텍스트 파일에 대한 테이블이 존재하지 않는다면, 남아 있는 파일들에 대한

처리를 계속 진행한다. --force를 사용하지 않으면, 테이블이 존재하지 않을 경우에는 mysqlimport가 종료된
다.
주어진 호스트 상에 있는 MySQL 서버에 데이터를 임포트 한다. 디폴트 호스트는 localhost.

:::MySQL Korea:::
● --ignore, -i
--replace 옵션에 대한 설명을 보여 준다.
● --ignore-lines=N
데이터 파일의 첫 번째 N 라인을 무시한다.
● --local, -L
클라이언트 호스트로부터 로컬에서 입력 파일을 읽는다.
● --lock-tables, -l
텍스트 파일을 처리하기 전에 쓰기를 위해 모든 테이블을 잠근다. 이것은 모든 테이블이 서버에서 동기화 되도
록 해 준다.
● --low-priority
테이블을 읽을 때 LOW_PRIORITY 를 사용한다.
서버에 접속을 할 때 사용할 패스워드. 만일 여러분이 축약형 옵션 폼 (-p)을 사용한다면, 패스워드와 옵션 사

이에는 스페이스를 두지 말아야 한다. 명령어 라인에서 --password 또는 -p 옵션 다음에 패스워드를 지정하
지 않으면, 프롬프트가 나오게 된다.
접속에 사용할 TCP/IP 포트 번호.

:::MySQL Korea:::
● --replace, -r
--replace 와 --ignore 옵션은 유니크 키 값에 존재하는 열을 복제(duplicate)하는 입력 열 처리를 제어한

다. 만일 여러분이 --replace를 지정하면, 새로운 열이 동일한 유니크 키 값을 가지고 있는 현재의 열을 대체
한다. 만일 --ignore를 지정하면, 유니크 키 값에 존재하는 열을 복제하는 입력 열은 무시가 된다. 만일 두 가
지 중에 어느 것도 지정을 하지 않으면, 복제 키 값이 발견될 때 에러가 발생하고, 텍스트 파일의 나머지는 무시
가 된다.
● --silent, -s
침묵 모드. 에러가 발생할 때에만 결과 값을 만든다.
localhost에 접속을 하는 경우에 사용되는, 유닉스 소켓 파일, 또는 윈도우 네임드 파이프의 이름.
서버에 접속할 때 사용되는 MySQL 사용자 이름.
● --verbose, -v
버보스 모드. 프로그램이 실행하는 것에 대한 정보를 자세히 출력한다.
● --version, -V

아래에서는 mysqlimport의 사용 사례를 보여 준다
shell> mysql -e 'CREATE TABLE imptest(id INT, n VARCHAR(30))' test

:::MySQL Korea:::
shell> ed
a
100 Max Sydow
101 Count Dracula
.
w imptest.txt
32
q
shell> od -c imptest.txt
0000000 1 0 0 ￦t M a x S y d o w ￦n 1 0
0000020 1 ￦t C o u n t D r a c u l a ￦n
0000040
shell> mysqlimport --local test imptest.txt
test.imptest: Records: 2 Deleted: 0 Skipped: 0 Warnings: 0
shell> mysql -e 'SELECT * FROM imptest' test
+------+---------------+
| id | n |
+------+---------------+
| 100 | Max Sydow |
| 101 | Count Dracula |
+------+---------------+

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.13. mysqlshow — 데이터 베이스, 테이블, 그리고 컬럼 정보를 보여 준다
8. 클라이언트 및 유틸리티 프로그램 mysqlshow 클라이언트는 어떤 데이터 베이스가 있고, 어떤 테이블, 어떤 테이블 컬럼 또는 인덱스가 있는지를 쉽게
8.13. mysqlshow — 데이터 베이스, 테이블, 그리고 컬럼 보여주는 프로그램이다.
정보를 보여 준다 mysqlshow는 몇몇 SQL SHOW 명령문에 대해서 명령어 라인 인터 페이스를 제공한다. Section 13.5.4, “SHOW
8.13 mysqlshow — 데이터 베이스, 테이블, 그리고 컬럼 정보 신텍스”를 참조할 것. 이와 같은 명령어를 직접 사용해서도 동일한 정보를 얻을 수가 있다. 예를 들면, 여러분은you
를 보여 준다 can issue them from the mysql 클라이언트 프로그램에서 이것들을 입력할 수가 있다.
mysqlshow는 아래와 같이 호출한다:
shell> mysqlshow [options] [db_name [tbl_name [col_name]]]
● 만일 아무런 데이터 베이스도 주어지지 않으면, 데이터 베이스 이름 리스트가 나오게 된다.
● 만일 아무런 테이블도 주어지지 않으면, 데이터 베이스 있는 모든 매칭 테이블이 나오게 된다.
● 만일 아무런 컬럼도 주어지지 않으면, 매칭되는 모든 컬럼과 컬럼 타입이 나오게 된다.
결과 값으로는 여러분이 권한을 가지고 있는 데이터 베이스, 테이블, 또는 컬럼만을 출력한다.

만일 마직막 인수가 쉘 또는 SQL 와일드 카드 문자 (‘*’, ‘?’, ‘%’, or ‘_’)를 가지고 있다면, 와일드 카드와
매치가 되는 이름만이 나오게 된다. 만일 데이터 베이스의 이름에 밑줄(underscore)이 들어가 있으면, 이러한 이름들
은 올바른 테이블 또는 컬럼 리스트를 얻기 위해서 백 슬레시(어떤 유닉스 쉘에서는 이줄 백슬레시가 필요함)를 사용
해서 이스케이스 되어야 한다. ‘*’ 및 ‘?’ 문자는 SQL에서 ‘%’ 과 ‘_’ 와일드 카드 문자로 변환된다. 이것은
여러분이 테이블 이름에 ‘_’ 가 있는 테이블을 위해서 컬럼을 출력하고자 할 때 혼란스러움을 야기 시킬 수도 있는
데, 그 이유는 이와 같은 경우, mysqlshow는 이 패턴과 매치되는 테이블 이름만을 출력하기 때문이다. 이 문제는 명령
어 라인에서 여분의 ‘%’를 추가해서 이것을 구분 인수로 사용하면 간단하게 해결할 수가 있다.
mysqlshow은 아래의 옵션을 지원한다:
● --help, -?

:::MySQL Korea:::
문자 셋이 설치되어 있는 디렉토리. Section 5.11.1, “데이타 및 정렬을 위해 사용되는 문자 셋”을 참조할

것.
● --compress, -C
클라이언트 및 서버가 압축을 지원하면 둘 사이에 전달되는 정보를 압축한다.
● --count
테이블 당 열 수를 보여준다. 이것은 non-MyISAM 테이블에 대해서는 속도가 느리다. 이 옵션은 MySQL
5.0.6에서 추가되었다.
charset_name 를 디폴트 문자 셋으로 사용한다. Section 5.11.1, “데이타 및 정렬을 위해 사용되는 문자

셋”를 참조할 것.
주어진 호스트에 있는 MySQL 서버에 접속을 한다.
● --keys, -k
테이블 인덱스를 보여준다.

:::MySQL Korea:::
서버에 접속을 할 때 사용하는 패스워드.
접속을 위해서 사용할 TCP/IP 포트 번호.
접속 프로토콜.
● --show-table-type, -t
테이블 타입을 가리키는 컬럼을 보여준다. SHOW FULL TABLES과 동일하다. 이 타입은 BASE TABLE 또
는 VIEW가 된다. 이 옵션은 MySQL 5.0.4에서 추가되었다.
localhost에 접속할 때 사용하는 유닉스 소켓 파일 또는 윈도우의 네임드 파이프 이름.
● --status, -i
각 테이블의 추가적인 정보를 출력한다.
서버에 접속할 때 사용하는MySQL 사용자 이름.
● --verbose, -v
버보스 모드(Verbose mode). 프로그램이 실행하는 정보를 자세히 보여준다. 이 옵션을 여러 번 사용하면 보

:::MySQL Korea:::
다 많은 정보를 얻을 수가 있다.
● --version, -V

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.14. mysql_zap — 패턴과 일치하는 프로세스 죽이기(Kill)
8. 클라이언트 및 유틸리티 프로그램 mysql_zap은 패턴과 일치하는 프로세스를 죽이는 프로그램이다. 이것은 ps 명령어 및 유닉스 신호를 사용하기 때문
8.14. mysql_zap — 패턴과 일치하는 프로세스 죽이기(Kill) 에, 유닉스와 유닉스와 유사한 시스템에서 구동이 된다.
8.14 mysql_zap — 패턴과 일치하는 프로세스 죽이기(Kill) mysql_zap은 아래와 같이 호출한다:

shell> mysql_zap [-signal] [-?Ift] pattern
ps 명령어로부터 나오는 결과 값이 패턴을 가지고 있다면 프로세스는 매치가 된다. 디폴트로는, mysql_zap은 각 프
로세스에 대해서 확답을 묻는다. y로 답을 하면 그 프로세스를 죽이라는 것이며, 또는 q 는 mysql_zap를 종료하라
는 것이다. 이외의 다른 응답에 대해서는, mysql_zap는 프로세스를 죽이지 않는다.
만일 -signal 옵션을 주게 되면, 이것은 각 프로세스에 전달하기 위한 신호의 이름 또는 번호를 지정하는 것이다. 이
옵션을 주지 않게 되면, mysql_zap는 우선 TERM (signal 15)를 시도하고 그 다음에 KILL (signal 9)를 시도한
다.
mysql_zap는 아래의 옵션을 지원한다:
● --help, -?, -I
● -f
강제 모드(Force mode). mysql_zap은 아무런 확답 없이 각 프로세스를 죽이고자 시도한다.
● -t
테스트 모드. 각 프로세스를 죽이는 대신에 각각에 대한 정보를 출력한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.15. perror — 에러 코드 설명
8. 클라이언트 및 유틸리티 프로그램 대부분의 시스템 에러의 경우, MySQL은 내부 텍스트 메시지와 더불어, 아래의 스타일 중의 한 형태로 시스템 에러 코드를 출력하
8.15. perror — 에러 코드 설명 다:
8.15 perror — 에러 코드 설명 message ... (errno: #)

message ... (Errcode: #)
여러분은 시스템 설명서 또는 perror 유틸리티를 사용해서 각 에러 코드가 의미하는 내용을 알아 볼 수가 있다.
perror는 시스템 에러 코드 또는 스토리지 엔지(테이블 핸들러) 에러 코드에 대한 설명을 출력한다.
perror는 아래와 같이 호출한다:
shell> perror [options] errorcode ...
예제:
shell> perror 13 64
Error code 13: Permission denied
Error code 64: Machine is not on the network
MySQL 클러스터 에러 코드에 대한 에러 메시지를 얻기 위해서는, perror를 --ndb 옵션과 함께 사용한다:
shell> perror --ndb errorcode
시스템 에러 메시지의 의미는 여러분이 사용하는 OS에 관련이 되어 있다는 점을 알기 바란다. 주어진 에러 코드는 OS별로 틀리게
나올 수도 있다.
perror는 아래의 옵션을 지원한다:
● --help, --info, -I, -?
● --ndb

:::MySQL Korea:::
MySQL 클러스터 에러 코드에 대한 에러 메시지를 출력한다.
● --silent, -s
침묵 모드(Silent mode). 에러 메시지만을 출력한다.
● --verbose, -v
버보스 모드 (Verbose mode). 에러 코드와 메시지를 출력한다. 이것이 디폴트 임.
● --version, -V

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 8.16. replace — 스트링 대체 유틸리티
8. 클라이언트 및 유틸리티 프로그램 replace 유틸리티 프로그램은 파일 또는 표준 입력 값에서 스트링을 변경 시킨다.

8.16. replace — 스트링 대체 유틸리티
8.16 replace — 스트링 대체 유틸리티 아래의 방법 중에 하나를 사용해서 replace를 호출한다:

shell> replace from to [from to] ... -- file [file] ...
shell> replace from to [from to] ... < file
from 은 변경을 고려하는 스트링을 의미하며 to 는 대체할 스트링을 의미한다. 하나 또는 여러 쌍의 스트링이 존재할 수 있다.
-- 옵션을 사용해서 스트링 대체가 어디에서 끝이 나고 파일 이름이 어디에서 시작이 되는지를 가리킬 수가 있다. 이와 같은 경
우, 명령어 라인에서 지정된 파일은 그 자리에서 수정이 되며, 따라서 여러분은 변환을 하기 전에 원본을 복사하는 것이 좋다.
replace는 실제로 수정이 되는 입력 파일에 대한 내용을 출력한다.
만일 – 옵션이 주어지지 않으면, replace는 표준 입력 값을 읽게 되고 표준 결과 값을 작성하게 된다.
replace는 유한 상태 머신(finite state machine)을 사용해서 보다 긴 스트링을 우선 매치한다. 이것은 스트링을 스왑(swap)하기
위해서도 사용될 수 있다. 예를 들면, 아래의 명령어는 주어진 파일 file1 과 file2에 있는 a 와 b를 스왑한다.
shell> replace a b b a -- file1 file2 ...
replace 프로그램은 msql2mysql에 의해서 사용될 수 있다. Section 22.9.1, “msql2mysql — Convert mSQL Programs for
Use with MySQL”를 참조할 것.
replace는 아래의 옵션을 지원한다:
● -?, -I

:::MySQL Korea:::
● -# debug_options
● -s
침묵 모드(Silent mode).
● -v
버보스 모드(Verbose mode).
● -V

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 9. 언어 구조 (Language Structure)
9. 언어 구조 (Language Structure) 9.1. 리터럴 값(Literal Values)
9 언어 구조 (Language Structure) 9.1.1. 스트링(Strings)
9.1 리터럴 값(Literal Values) 9.1.2. 숫자(Numbers)
9.1.1 스트링(Strings) 9.1.3. 16진수 값(Hexadecimal Values)

9.1.4. 불리안 값(Boolean Values)
9.1.2 숫자
9.1.5. 비트-필드 값(Bit-Field Values)
9.1.3 16진수 값
9.1.6. NULL 값
9.1.4 불리안 값 (Boolean Values)
9.2. 데이터 베이스, 테이블, 인덱스, 컬럼, 그리고 별칭(Alias Names)
9.1.5 비트-필드 값 (Bit-Field Values)
9.2.1. 식별자 수식어(Identifier Qualifiers)
9.1.6 NULL 값
9.2.2. 식별자 문자 크기 구분(Identifier Case Sensitivity)
9.2 데이터 베이스, 테이블, 인덱스, 컬럼 그리고 별칭 이름(Alias
9.3. 사용자 지정 변수
Names)
9.4. 코멘트 신텍스
9.2.1 식별자 수식어 (Identifier Qualifiers)
9.5. MySQL에서 사용 지정된 단어 다루기
9.2.2 식별자 대소 문자 구분
9.3 사용자 정의 변수들
9.3 사용자 정의 변수 이 장에서는 아래의 SQL 명령문을 MySQL에서 작성할 때 사용되는 규칙에 대해서 설명을 하기로 한
9.4 코멘트 신텍스 다:
9.5 MySQL 에서 사용 지정된 단어 다루기
● 스트링 및 숫자와 같은 리터럴 값(Literal value)
● 데이터 베이스, 테이블, 그리고 컬럼 이름과 같은 식별자(Identifiers)
● 사용자 지정 시스템 변수
● 코멘트
● 사용 지정 단어

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.1. 리터럴 값(Literal Values)
9. 언어 구조 (Language Structure) 9.1.1. 스트링

9.1. 리터럴 값(Literal Values) 9.1.2. 숫자
9.1 리터럴 값(Literal Values) 9.1.3. 16진수 값
9.1.1 스트링(Strings) 9.1.4. 불리안 값
9.1.2 숫자 9.1.5. 비트-필드 값

9.1.6. NULL 값
9.1.3 16진수 값
9.1.4 불리안 값 (Boolean Values)
이 섹션에서는 MySQL에서 리터럴 값을 작성하는 방법을 설명하기로 한다. 여기에는 스트링, 숫자, 16진수 값, 불리안 값, 그리고
9.1.5 비트-필드 값 (Bit-Field Values)
NULL이 포함된다. 이 섹션은 또한 여러분이 이러한 기본적인 타입을 MySQL에서 다룰 때 구동할 수 있는 다양한 의미등에 대해
9.1.6 NULL 값
서도 다룰 것이다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.1.1. 스트링(Strings)
9. 언어 구조 (Language Structure)
9.1. 리터럴 값(Literal Values) 스트링은 단일 인용 부호 또는 이중 인용 부호로 둘러 쌓인 문자 또는 바이트의 시퀀스이다. 예를 들면:
9.1.1 스트링(Strings)
'a string'
"another string"
만일 ANSI_QUOTES SQL 모드가 활성화 되어 있다면, 스트링 리터럴은 단일 인용 부호만을 사용할 수 있는데, 그 이유는 이중 부
호를 사용하게 되면 이것을 식별자(identifier)로 해석하기 때문이다.
바이너리 스트링은 어떠한 문자 셋 또는 콜레션(collation)도 가지고 있지 않는 바이트 스트링이다. 비-바이너리 스트링(non-

binary string)은 문자 셋과 콜레션을 가지고 있는 문자 스트링이다. 두 가지 형태의 스트링 모두에 대해서는, 스트링 유닛(unit)
의 숫자 값을 기반으로 비교를 한다. 바이너리 스트링의 경우, 이 유닛은 바이트가 된다. 비-바이너리 스트링의 경우에는, 이 유닛
은 문자가 되고 어떤 문자 셋은 다중-바이트 문자를 허용하기도 한다. 문자 값 순서는 스트링 콜레션의 함수가 된다.
스트링 리터럴은 옵션으로 문자 셋 인트로듀서(introducer) 및 COLLATE 구문을 가질 수도 있다:
[_charset_name]'string' [COLLATE collation_name]
예제:
SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci;

:::MySQL Korea:::
이러한 형태의 스트링 신텍스에 관한 보다 자세한 정보는 Section 10.3.5, “문자 스트링 리터럴 문자 셋 및 콜레션”을 참조 할
것.
스트링 안에서는, 어떤 시퀀스는 특별한 의미를 갖게 된다. 이러한 시퀀스들은 각각 이스케이프 문자로 알려져 있는 백 슬레시로 시
작이 된다. MySQL은 아래의 이스케이프 시퀀스를 인식한다:
￦0 An ASCII 0 (NUL) character.
￦' A single quote (‘'’) character.
￦" A double quote (‘"’) character.
￦b A backspace character.
￦n A newline (linefeed) character.
￦r A carriage return character.
￦t A tab character.
￦Z ASCII 26 (Control-Z). See note following the table.
￦￦ A backslash (‘￦’) character.
￦% A ‘%’ character. See note following the table.
￦_ A ‘_’ character. See note following the table.
다른 모든 이스케이프 시퀀스의 경우, 백 슬레시는 무시가 된다. 즉, 이스케이프 문자는 이스케이프가 아닌 것처럼 해석이 된다. 예
를 들면, ‘￦x’ 는 단지 ‘x’로 해석된다.
이러한 시퀀스들은 대소 문자를 구분한다. 예를 들면, ‘￦b’는 백 스페이스로 해석되지만, ‘￦B’는 ‘B’로 해석된다.
ASCII 26 문자는 ‘￦Z’로 해석되며 윈도우에서 END-OF-FILE을 나타내는 ASCII 26 문제를 해결하도록 한다. 파일 안에 있
는 ASCII 26는 여러분이 mysql db_name < file_name를 시도할 경우에 문제를 발생 시킨다.
‘￦%’ 와 ‘￦_’ 시퀀스는 이것들이 와일드 카드 문자로 해석되어야 하는 곳의 패턴-매칭 문장에서 ‘%’ 와 ‘_’의 리터럴
인스턴스를 검색하기 위해 사용된다. Section 12.3.1, “스트링 비교 함수”에 있는 LIKE 연산자에 대한 설명을 살펴 보기 바란

:::MySQL Korea:::
다. 만일 여러분이 비-패턴-매칭 문장에서 ‘￦%’ 또는 ‘￦_’를 사용할 경우, 이것들은 스트링 ‘￦%’ 와 ‘￦_’로 해석되
고, ‘%’ 와 ‘_’로는 해석되지 않게 된다.
스트링 안에 인용 부호를 포함 시키는 방법은 여러 가지가 있다:
● 단일 인용 부호 안에 있는 스트링 내부의 ‘'’는 ‘''’ 형태로 작성될 수도 있다.

● 이중 인용 부호 안에 있는 스트링 내부의 ‘"’는 ‘""’ 형태로 작성될 수도 있다.
● 이스케이프 문자 앞에는 인용 부호를 앞세운다 (‘￦’).
● 이중 인용 부호 안에 있는 스트링 내부의 ‘'’는 특별히 다룰 필요가 없으며 이중 처리 또는 이스케이프를 할 필요가 없
다. 같은 방식으로, 단일 인용 부호 안에 있는 스트링 내부의 ‘"’ 도 특별히 다룰 필요가 없다.
아래의 SELECT 명령문은 인용 부호 및 이스케이핑을 어떻게 처리하는 지를 보여 준다:
mysql> SELECT 'hello', '"hello"', '""hello""', 'hel''lo', '￦'hello';
+-------+---------+-----------+--------+--------+
| hello | "hello" | ""hello"" | hel'lo | 'hello |
+-------+---------+-----------+--------+--------+
mysql> SELECT "hello", "'hello'", "''hello''", "hel""lo", "￦"hello";
+-------+---------+-----------+--------+--------+
| hello | 'hello' | ''hello'' | hel"lo | "hello |
+-------+---------+-----------+--------+--------+

:::MySQL Korea:::
mysql> SELECT 'This￦nIs￦nFour￦nLines';
+--------------------+
| This
Is
Four
Lines |
+--------------------+
mysql> SELECT 'disappearing￦ backslash';
+------------------------+
| disappearing backslash |
+------------------------+
만일 여러분이 스트링 컬럼 속에 (예를 들면 BLOB 컬럼) 바이너리 데이터를 삽입하고자 한다면, 아래의 문자는 반드시 이스케이
프 시퀀스를 사용해서 표시되어야 한다:
NUL NUL byte (ASCII 0). Represent this character by ‘￦0’ (a backslash followed by an ASCII ‘0’ character).
￦ Backslash (ASCII 92). Represent this character by ‘￦￦’.
' Single quote (ASCII 39). Represent this character by ‘￦'’.

:::MySQL Korea:::
" Double quote (ASCII 34). Represent this character by ‘￦"’.
어플리케이션 프로그램을 작성할 때, 이러한 특수 문자를 가지고 있는 스트링은 반드시 MySQL 서버에 보내지는 SQL 명령문에서
이 스트링을 사용하기 전에 올바르게 이스케이프가 되어야 한다. 여러분이 이것을 두 가지 방식으로 처리할 수가 있다:
● 특수 문자를 이스케이프하는 함수를 사용해서 스트링을 처리한다. C 프로그램에서는, 문자를 이스케이프 시키기 위해서
mysql_real_escape_string() C API 함수를 사용할 수 있다. Section 22.2.3.52, “mysql_real_escape_string()”을 참
조. Perl DBI 인터페이스는 특수 문자를 적당한 이스케이프 문자로 변환시키는 방법으로 quote 방식을 제공해 준다.
Section 22.4, “MySQL Perl API”를 참조. 다른 언어 인터 페이스에서도 이와 유사한 방식을 제공해 준다.
● 특수 문자를 확실하게 이스케이프 시키기 위한 다른 방안으로는, 많은 수의 MySQL API가 특수 마커(marker)를 명령문
스트링에 삽입할 수 있도록 해 주는 플레이스홀더(placeholder)를 제공하고 있으며, 여러분이 명령문을 입력하게 되면 데
이터 값을 이것들과 묶어 버린다. 이와 같은 경우, API는 이 값에서 이스케이프 특수 문자를 조심스럽게 처리한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.1.2. 숫자
9.1. 리터럴 값(Literal Values) 정수는 숫자(digit)의 시퀀스 형태로 표현된다. 소수점은 10진법의 구분자(separater)로서 ‘.’을 사용한다. 두 가지 형태의 숫자
9.1.2 숫자 들은 음수 또는 양수를 표시하기 위해서 ‘-’ 또는 ‘+’를 각각 앞에 사용할 수도 있다.
유효한 정수 값의 예를 보면:
1221
-32
유효한 소수점 숫자의 예를 보면:
294.42
-32032.6809e+10
148.00
정수를 소수점 문장 안에서 사용할 수도 있다; 이것은 소수점 숫자와 동일하게 취급된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.1.3. 16진수 값
9.1. 리터럴 값(Literal Values) MySQL은 16 진수 값을 지원한다. 숫자 문장에서는, 이 값은 마치 정수처럼 동작을 한다 (64-비트 표현식). 스트링 문자에서는,
9.1.3 16진수 값 이 값은 바이너리 스트링처럼 동작을 하며, 각각의 16진수 쌍은 하나의 문자로 변환이 된다:
mysql> SELECT x'4D7953514C';
-> 'MySQL'
mysql> SELECT 0xa+0;
-> 10
mysql> SELECT 0x5061756c;
-> 'Paul'
16진수 값의 디폴트 타입은 스트링이다. 만일 이 값을 확실하게 숫자로 처리하고 싶다면, CAST(... AS UNSIGNED)를 사용하면
된다:
mysql> SELECT 0x41, CAST(0x41 AS UNSIGNED);
-> 'A', 65
x'hexstring' 신텍스는 표준 SQL를 기반으로 한다. 0x 신텍스는 ODBC에 기반을 둔다. BLOB 컬럼에 대한 값을 지원하기 위해서
ODBC가 16진수 스트링을 사용하는 경우도 종종 있다.

:::MySQL Korea:::
여러분은 HEX() 함수를 사용해서 스트링 또는 숫자를 16진수 포맷의 스트링으로 변환 시킬 수가 있다:
mysql> SELECT HEX('cat');
-> '636174'
mysql> SELECT 0x636174;
-> 'cat'

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.1.4. 불리안 값 (Boolean Values)
9.1. 리터럴 값(Literal Values) 항수(constants) TRUE 와 FALSE는 각각 1 과 0로 해석된다. 항수 이름은 대소 문자 구분을 하지 않는
9.1.4 불리안 값 (Boolean Values) 다.
mysql> SELECT TRUE, true, FALSE, false;
-> 1, 1, 0, 0
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.1.5. 비트-필드 값 (Bit-Field Values)
9.1. 리터럴 값(Literal Values) MySQL 5.0.3 이후, 비트-필드(bit-field) 값을 b'value' 표기법을 사용해서 작성할 수 있게 되었다. value 는 여러 개의 0 과 1
9.1.5 비트-필드 값 (Bit-Field Values) 을 사용해서 작성된 바이너리 값이다.
비트-필드 표기법(Bit-field notation)을 사용하면 BIT 컬럼에 값을 지정할 때 편리하다:
mysql> CREATE TABLE t (b BIT(8));
mysql> INSERT INTO t SET b = b'11111111';
mysql> INSERT INTO t SET b = b'1010';
+------+----------+----------+----------+
| b+0 | BIN(b+0) | OCT(b+0) | HEX(b+0) |
+------+----------+----------+----------+
| 255 | 11111111 | 377 | FF |
| 10 | 1010 | 12 |A |
+------+----------+----------+----------+
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.1.6. NULL 값
9.1. 리터럴 값(Literal Values) NULL 값은 “데이터가 없음(no data)”을 의미한다. NULL은 대소 문자 구분을 하지 않는다.
9.1.6 NULL 값
NULL 값은 숫자 타입의 0 또는 스트링 타입의 빈 스트링(empty string)과는 다른 것임을 알아야 한다. Section A.5.3, “NULL
값 사용의 문제점”을 참조할 것.
LOAD DATA INFILE 또는 SELECT ... INTO OUTFILE를 사용해서 실행되는 텍스트 파일 임포트 또는 익스포트의 경우,
NULL은 ￦N 시퀀스를 가지고 표시가 된다. Section 13.2.5, “LOAD DATA INFILE 신텍스”를 참조할 것.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.2. 데이터 베이스, 테이블, 인덱스, 컬럼 그리고 별칭 이름(Alias Names)
9. 언어 구조 (Language Structure) 9.2.1. 식별자 수식어 (Identifier Qualifiers)

9.2. 데이터 베이스, 테이블, 인덱스, 컬럼 그리고 별칭 이름 9.2.2. 식별자 대소 문자 구분 (Identifier Case Sensitivity)
(Alias Names)
9.2 데이터 베이스, 테이블, 인덱스, 컬럼 그리고 별칭 이름 데이터 베이스, 테이블, 인덱스, 컬럼 그리고 별칭은 식별자이다. 이 섹션에서는 MySQL에서 사용할 수 있는 식별자
(Alias Names) 에 대해서 설명하기로 한다.
9.2.1 식별자 수식어 (Identifier Qualifiers) 아래의 테이블에서는 각각의 식별자 타입의 최대 크기를 보여 준다.
9.2.2 식별자 대소 문자 구분 Identifier Maximum Length
Database 64
Table 64
Column 64
Index 64
Alias 255
식별자에 나타날 수 있는 문자에는 몇 가지 제약이 존재한다:
● 어떠한 식별자도 ASCII 0 (0x00) 또는 255의 값을 가지는 바이트를 가질 수 없다.

● 식별자 안에서 식별자 인용 부호 문자를 사용하는 것은 가능하지만, 가능하면 이 방법을 사용하지 않는 것이
좋다.
● 데이터 베이스, 테이블, 그리고 컬럼 이름은 스페이스 문자로 끝나지 말아야 한다.
● 데이터 베이스 이름에는 ‘/’, ‘￦’, ‘.’, 또는 디렉토리 이름으로 사용할 수 없는 문자를 사용할 수 없
다.
● 테이블 이름은 ‘/’, ‘￦’, ‘.’, 또는 파일 이름으로 허용되지 않은 문자를 사용할 수 없다.
식별자는 유니 코드(UTF-8)을 사용해서 저장된다. 이것은 .frm 파일에 저장되는 테이블 정의문에 있는 식별자 및

:::MySQL Korea:::
mysql 데이터 베이스에 있는 그랜트 테이블에 저장되는 식별자에 적용이 된다. MySQL 5.0의 그랜트 테이블(그리
고 다른 테이블)에 있는 스트링 컬럼의 크기는 문자의 수로 주어진다. 이것은 (MySQL의 이전 버전과는 달리) 여러
분이 이러한 컬럼에 저장되는 값에 대해서 다중-바이트 문자를 사용할 수 있다는 것을 의미하는 것이다.
식별자는 인용 부호를 사용할 수도 있고 사용하지 않을 수도 있다. 만일 식별자가 사용 지정된 단어이거나 또는 특수
문자를 가지고 있다면, 여러분은 반드시 이것을 참조할 때마다 인용 부호를 사용해야 한다. (예외 사항: 사용이 검증
된 이름 안에서 점(period)이 붙어 있는 단어는 반드시 식별자 이어야 하고, 따라서 이것이 사용 지정 단어라고 하더
라고 인용 부호를 사용할 필요는 없게 된다.) 사용 지정 단어 리스트에 대해서는 Section 9.5, “MySQL에서 사용이
지정된 단어 다루기”를 참조할 것. 특수 문자는 알파뉴메릭(alphanumeric) 문자 셋 이외의 문자들을 의미한다.
식별자 인용 부호 문자는 백틱(backtick) (‘`’)이다:
mysql> SELECT * FROM `select` WHERE `select`.id > 100;
만일 ANSI_QUOTES SQL 모든가 활성화 되어 있다면, 이중 인용 부호를 사용해서 식별자를 처리하는 것이 가능하
다:
mysql> CREATE TABLE "test" (col INT);
ERROR 1064: You have an error in your SQL syntax. (...)
mysql> SET sql_mode='ANSI_QUOTES';
mysql> CREATE TABLE "test" (col INT);
Note: ANSI_QUOTES 모드는 서버로 하여금 이중 인용 부호를 사용한 스트링을 식별자로 해석하게끔 하기 때문에,
이 모드가 활성화 되어 있는 경우에는 반드시 스트링 리터럴을 단일 인용 부호를 사용해서 처리해야만 한다. 이중 인
용 부호를 사용해서는 처리가 않된다.
서버 SQL 모드는 Section 5.2.5, “서버 SQL 모드”에서 설명한 방식으로 제어가 된다.
식별자 인용 문자는 여러분이 식별자를 인용 부호화할 경우에 식별자 안에 포함 시킬 수가 있다. 만일 식별자 안에 포
함 시켜야 할 문자가 식별자 자체를 인용 부호화 하는데 사용한 것과 같을 경우에는, 이중 인용 부호를 사용하면 된
다. 아래의 명령문은 c"d라는 이름의 컬럼을 가지고 있는 a`b 라는 이름의 테이블을 생성한다.
mysql> CREATE TABLE à``b` (`c"d` INT);
M 과 N 이 정수인 경우에 Me 또는 MeN 형태의 이름을 사용하지 말 것을 권고한다. 예를 들면, 식별자로서 1e 또는
2e2 와 같은 형태는 피해야 하는데, 그 이유는 1e+3 와 같은 수식이 애매 모호해지기 때문이다. 문장에 관련해서는,
이러한 이름은 수식 1e + 3 또는 숫자 1e+3로 해석될 수도 있다.
MD5()을 사용해서 테이블 이름을 생성할 때에는 주의를 해야 하는데, 그 이유는 이것이 위에서 설명한 것과 유사한
애매 모호한 포맷 또는 올바르지 못한 이름을 만들기 때문이다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.2.1. 식별자 수식어 (Identifier Qualifiers)
9.2. 데이터 베이스, 테이블, 인덱스, 컬럼 그리고 별칭 이름 MySQL 은 단일 식별자 또는 여러 개의 식별자로 구성된 이름을 허용한다. 여러 부분으로 이름을 만들 경우에는
(Alias Names) 점 (‘.’) 으로 구분을 해야 한다. 여러 부분으로 되어 있는 이름의 첫 부분은 최종 식별자가 해석되는 곳에 있는
9.2.1 식별자 수식어 (Identifier Qualifiers) 문장에 영향을 주는 수식어 형태로 동작을 한다.
MySQL에서는, 여러분은 아래의 형태 중의 하나를 사용해서 컬럼을 참조할 수 있다:
Column Reference Meaning
The column col_name from whichever table used in the statement

col_name
contains a column of that name.
tbl_name.col_name The column col_name from table tbl_name of the default database.
db_name.tbl_name.col_name The column col_name from table tbl_name of the database db_name.
만일 여러 부분으로 구성된 이름중의 일부가 인용 부호를 필요로 할 경우에는, 이름 전체 보다는 개별적으로 인용

부호화 한다. 예를 들면, `my-table`.`my-column`형태로 하면 되며, `my-table.my-column` 형태로는 하지 않
도록 한다.
명령문 안에 있는 컬럼 참조를 위해서는 참조를 애매 모호하게 하지 않는 한 tbl_name 또는 db_name.tbl_name

의 접두사를 지정할 필요는 없다. 테이블 t1 과 t2이 각각 컬럼 c를 가지고 있고, 테이블 t1 과 t2 모두를 사용하는
SELECT 명령문에서 c를 추출한다고 가정하자. 이러한 경우, c는 이 명령문 안에서 사용되는 테이블 사이에서 유
니크(unique)하지 않기 때문에 애매 모호한 상태가 된다. 이럴 때에는 여러분이 의미하는 테이블이 어떤 것인지
를 분명히 하기 위해서 t1.c 또는 t2.c 형태로 표현을 해주어야 한다. 비슷하게, db1에서 t 를 추출하고 동일한 명령
문에서 db2에 있는 t 를 추출하기 위해서는, db1.t.col_name 와 db2.t.col_name와 같은 형태로 테이블에서 컬럼

:::MySQL Korea:::
을 참조해야 한다.
수식이 된 이름에서 점(period) 다음에 나오는 단어는 반드시 식별자이어야 하며, 따라서 이것이 사용 지정된 단어
일 지라도 인용 부호화 할 필요는 없다.
신텍스 .tbl_name는 디폴트 데이터 베이스에 있는 테이블 tbl_name을 의미한다. 이 신텍스는 몇몇 ODBC 프로그
램이 테이블 이름을 ‘.’ 문자를 사용해서 앞세우기 때문에 ODBC와는 호환성을 가지게 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.2.2. 식별자 대소 문자 구분
9.2. 데이터 베이스, 테이블, 인덱스, 컬럼 그리 MySQL에서는, 데이터 베이스는 데이터 디렉토리에 있는 디렉토리와 연결이 된다(correspond). 하나의 데이터 베이스에 들어 있
고 별칭 이름(Alias Names) 는 각각의 테이블은 데이터 베이스 디렉토리에 들어 있는 파일과 최소한 한 개가 연결이 된다 (또한, 스토리지 엔진에 따라서 여러
9.2.2 식별자 대소 문자 구분 개와 연결될 수도 있음). 결론적으로, 사용하는OS 환경이 대소 문자를 구분하는지에 따라서 데이터 베이스와 테이블 이름에 대한
대소 문자 구분이 이루어지게 된다. 이것이 의미하는 것은 데이터 베이스와 테이블 이름이 대부분의 유닉스에서는 대소 문자를 구
분하며, 윈도우에서는 그렇지 않다는 것을 가리킨다. 하지만 Mac OS X의 경우는 예외인데, 이 OS는 유닉스 기반이기는 하지만 이
것이 사용하는 디폴트 파일 시스템 (HFS+)은 대소 문자를 구분하지 않는다. 하지만, Mac OS X 역시 UFS를 지원하며, 이것은 대
소 문자를 구분한다. Section 1.9.4, “표준 SQL에 대한 MySQL의 확장”을 참조할 것. lower_case_table_names 시스템 변수
또한 이 섹션 후반부에서 설명하는 식별자 대소 문자 구분을 서버가 처리하는 동작에 영향을 준다.
Note: 비록 데이터 베이스 및 테이블 이름이 어떤 플랫폼에서는 대소 문자를 구분하지 않는다 하더라도, 여러분은 동일한 명령문
내에서는 대소 문자를 혼용해서 데이터 베이스 및 테이블 이름을 지정하지 않도록 한다. 아래의 명령문은 하나의 동일 테이블을
my_table 및 MY_TABLE로 참조를 하기 때문에 동작을 하지 않게 된다:
mysql> SELECT * FROM my_table WHERE MY_TABLE.col=1;
컬럼, 인덱스, 스토어드 루틴, 그리고 트리거의 이름은 모든 플랫폼에서 대소 문자를 구분하지 않으며, 컬럼 별칭도 마찬가지이다.
디폴트로는, 테이블 별칭은 유닉스에서는 대소 문자를 구분하지만, 윈도우 또는 Mac OS X에서는 그렇지 않게 된다. 아래의 명령문
은 유닉스에서는 동작을 하지 않게 되는데, 그 이유는 이것이 a 및 A 형태로 별칭을 참조하기 때문이다
mysql> SELECT col_name FROM tbl_name AS a
-> WHERE a.col_name = 1 OR A.col_name = 2;

:::MySQL Korea:::
하지만, 위의 명령문은 윈도우에서는 동작을 한다. 이와 같은 차이점으로 인한 문제를 해결하기 위해서는, 항수 변환을 적용하는 것
이 최선의 방법인데, 데이터 베이스와 테이블을 생성하고 참조할 경우에는 항상 소문자 이름을 사용하도록 하는 것이다. 이러한 변
환은 이식성을 최대한 보장해 주고 사용을 용이하게 해 주기 때문에 권장하고 있다.
MySQL에서 테이블 맟 데이터 베이스가 디스크에 저장되고 사용되는 방법은 lower_case_table_names 시스템 변수를 가지고 제
어할 수 있는데, 여러분은 이것을 mysqld을 시작하는 시점에 설정할 수 있다. lower_case_table_names은 아래의 테이블에 있는
값을 가져온다. 유닉스의 경우, lower_case_table_names의 디폴트 값은0 이다. 윈도우의 경우에는 1 이 되며, Mac OS X는 디폴
트가 2가 된다.
Value Meaning
Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or
CREATE DATABASE statement. Name comparisons are case sensitive. Note that if you force this variable
0
to 0 with --lower-case-table-names=0 on a case-insensitive filesystem and access MyISAM tablenames
using different lettercases, index corruption may result.
Table names are stored in lowercase on disk and name comparisons are not case sensitive. MySQL converts
1 all table names to lowercase on storage and lookup. This behavior also applies to database names and table
aliases.
Table and database names are stored on disk using the lettercase specified in the CREATE TABLE or
CREATE DATABASE statement, but MySQL converts them to lowercase on lookup. Name comparisons are
2
not case sensitive. Note: This works only on filesystems that are not case sensitive! InnoDB table names are
stored in lowercase, as for lower_case_table_names=1.
만일 여러분이 오직 하나의 플랫폼 상에서만 MySQL을 사용한다면, 보통의 경우에는 lower_case_table_names 변수를 변경 시
킬 필요는 없다. 하지만, 파일 시스템이 대소 문자를 구분하는 플랫폼 간에 테이블을 전달하고자 하는 경우에는 어려움을 직면할 수
도 있게 된다. 예를 들면, 유닉스 상에서는 이름이 my_table 과 MY_TABLE인 두 개의 테이블을 가질 수는 있으나, 윈도우에서는
이 두 개의 테이블이 동일한 것으로 간주된다. 문자 크기에 민감한 테이블과 데이터 베이스 이름 전송의 문제를 해결하기 위해서
는, 아래의 두 가지 옵션을 사용해야 한다:
● 모든 시스템에서 lower_case_table_names=1 로 설정을 한다. 이렇게 할 경우의 가장 큰 단점은, 여러분이 SHOW

TABLES 또는 SHOW DATABASES를 사용할 경우, 여러분은 이것들의 원래의 문자 크기로 된 이름을 볼 수 없다는 점이

:::MySQL Korea:::
다.
● 유닉스에서는 lower_case_table_names=0로 설정하고, 윈도우에서는 lower_case_table_names=2로 설정한다. 이렇게
하면 데이터 베이스 및 테이블 이름의 원래 문자 크기가 보존된다. 이렇게 할 경우의 단점으로는, 여러분이 사용하는 명령
문이 항상 윈도우에서 정확한 문자 크기를 사용해서 데이터 베이스 및 테이블 이름을 참조한다고 확인을 해야 한다는 것이
다. 만일 명령문을 문자 크기에 민감한 유닉스로 전송할 경우에는, 문자 크기가 정확하기 않는 명령문은 동작을 하지 않게
된다.
Exception: 만일 여러분이 InnoDB 테이블을 사용한다면, 모든 플랫폼 상에서 lower_case_table_names를 1로 설정해

서 이름이 강제로 소문자로 변환되도록 해야 한다.
만일 여러분이 유닉스에서 lower_case_table_names 시스템 변수를 1로 설정하고자 한다면, 우선 구형 데이터 베이스 및 테이블
의 이름 mysqld을 새로운 설정으로 재 시작하기 전에 우선 데이터 베이스 및 테이블 이름을 소문자로 변환 시켜야 한다는 점을 알
아두기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.3. 사용자 정의 변수들
9.3. 사용자 정의 변수들

여러분은 사용자 정의 변수를 지정하고 나중에 참조할 수 있다. 이것은 한 구문으로부터 다른 구문으로 값을 넘길 수 있도록 한다.
9.3 사용자 정의 변수들
사용자 정의 변수는 커넥션에 국한되어 있다. 다시 말해, 한 클라이언트에서 정의된 사용자 변수는 다른 클라이언트에서는 보이지
9.3 사용자 정의 변수
않고 사용되지 못한다. 주어진 커넥션에서 정의된 모든 변수는 클라이언트가 종료되면 자동으로 해제된다.
변수명은 var_name 이라고 쓰는 반면, 사용자 변수는 @var_name 이라고 쓴다. 사용자 변수의 이름으로 현재의 문자 집합에서 알
파벳이나 숫자, ‘.’, ‘_’, 그리고 ‘$’을 사용할 수 있다. 기본 문자 집합은 latin1이다 (cp 1252 서유럽어). 이것은 mysqld
에 --default-character-set옵션을 주어 바꿀 수 있다. 5.11.1절 “자료와 저장에 사용되는 문자 집합” 절을 참고. 문자열이
나 이름identifier을 따옴표로 둘러 싸면 사용자 변수명에 다른 문자도 넣을 수 있다 (예를 들어, @'my-var', @"my-var", or
@`my-var`).
Note: MySQL 5.0이전에는 사용자 변수명에 대소문자를 가렸지만, MySQL 5.0과 그 이후부터는 대소문자를 가리지 않는다.
사용자 정의 변수는 SET문을 이용해서 정의할 수 있다
SET @var_name = expr [, @var_name = expr] ...
SET문에서는 할당 연산자로 = 나 := 모두 사용될 수 있다. 각 변수에 할당되는 expr은 정수, 실수, 문자열이나 NULL값으로 평가
될 수 있다.
SET 문이 아닌 다른 구문으로 값을 변수에 할당할 수 있다. 이 경우에 할당 연산자는 = 가 아니라 := 여야만 한다. =는 SET 이 아
닌 구문에서는 비교 연산자로 쓰이기 때문이다.
mysql> SET @t1=0, @t2=0, @t3=0;

:::MySQL Korea:::
mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
+----------------------+------+------+------+
| @t1:=(@t2:=1)+@t3:=4 | @t1 | @t2 | @t3 |
+----------------------+------+------+------+
| 5| 5| 1| 4|
+----------------------+------+------+------+
사용자 변수는 식을 사용할 수 있는 곳에 쓸 수 있다. 하지만 SELECT 문의 LIMIT 절이나, LOAD DATA문의 IGNORE N
LINES 절과 같이 숫자만 들어갈 수 있는 곳에도 사용할 수 있는 것은 아니다.
문자열을 사용자 변수에 할당하면, 변수는 문자열과 같은 문자열 집합과 콜레이션을 갖는다. 사용자 변수의 coercibility는
MySQL 5.0.3에서는 암시적이다(implicit). (테이블 컬럼 값들의 coercibility와 같다.)
Note: SELECT 구문에서는, 각 식이 클라이언트에 보내졌을 때에만 평가된다. 이 말은 HAVING, GROUP BY, 나 ORDER BY 절
에서, SELECT 목록에 있는 변수가 사용된 식을 참조할 수 없다는 뜻이다. 예를 들어, 다음 구문은 의도된 대로 동작하지 않는다.
mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM tbl_name HAVING b=5;
HAVING 절에 쓰인 b는 SELECT 목록에 있는, @aa 가 사용된 식의 별명이다. 이것은 의도된 대로 동작하지 않는다: @aa 가 현
재 줄이 아니라, 이전에 선택된 줄에서의 id 값을 갖고 있기 때문이다.
일반적인 규칙은 사용자 변수를 한 구문 안에서 정의하면 같은 구문의 다른 부분에서 절대 사용하지 않는 것이다. 여러분은 예상한
결과를 얻을 수도 있겠지만, 반드시 보장되지는 않는다.
한 구문 안에서 변수를 정의하고 사용하는 데에 따른 또다른 사항은, 변수의 기본 결과 타입이 구문의 시작 부분에서의 변수 타입
에 기반한다는 것이다. 다음 예제가 이것을 설명한다:
mysql> SET @a='test';

:::MySQL Korea:::
mysql> SELECT @a,(@a:=20) FROM tbl_name;
SELECT 구문에서, MySQL은 두 번째 열에서 @a가 수로 설정되었더라도, 첫째 열이 문자열이고 @a에 관한 모든 접근을 문자열
로 한다고 알린다. 우리가 SELECT 문을 실행하고 나면, 다음 구문에서 @a는 수로 여겨진다.
이런 행동에서 나오는 문제를 피하기 위해, 한 구문 안에 같은 변수를 동시에 설정하고 사용하지 않거나, 변수를 사용하기 전에 0,
0.0, 혹은 ‘’로 정의해야 한다.
초기화되지 않은 변수를 참조하는 경우, 그 변수는 NULL값을 갖는 문자열 형이다

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.3. 사용자 정의 변수
9. 언어 구조 (Language Structure) 여러분은 사용자 정의 변수를 지정하고 나중에 참조할 수 있다. 이것은 한 구문으로부터 다른 구문으로 값을 넘길 수 있도록 한다.
9.3. 사용자 정의 변수들 사용자 정의 변수는 커넥션에 국한되어 있다. 다시 말해, 한 클라이언트에서 정의된 사용자 변수는 다른 클라이언트에서는 보이지
9.3 사용자 정의 변수들 않고 사용되지 못한다. 주어진 커넥션에서 정의된 모든 변수는 클라이언트가 종료되면 자동으로 해제된다.
9.3 사용자 정의 변수 변수명은 var_name 이라고 쓰는 반면, 사용자 변수는 @var_name 이라고 쓴다. 사용자 변수의 이름으로 현재의 문자 집합에서 알
파벳이나 숫자, ‘.’, ‘_’, 그리고 ‘$’을 사용할 수 있다. 기본 문자 집합은 latin1이다 (cp 1252 서유럽어). 이것은 mysqld
에 --default-character-set옵션을 주어 바꿀 수 있다. 5.11.1절 “자료와 저장에 사용되는 문자 집합” 절을 참고. 문자열이
나 이름identifier을 따옴표로 둘러 싸면 사용자 변수명에 다른 문자도 넣을 수 있다 (예를 들어, @'my-var', @"my-var", or
@`my-var`).
Note: MySQL 5.0이전에는 사용자 변수명에 대소문자를 가렸지만, MySQL 5.0과 그 이후부터는 대소문자를 가리지 않는다.
사용자 정의 변수는 SET문을 이용해서 정의할 수 있다
SET @var_name = expr [, @var_name = expr] ...
SET문에서는 할당 연산자로 = 나 := 모두 사용될 수 있다. 각 변수에 할당되는 expr은 정수, 실수, 문자열이나 NULL값으로 평가
될 수 있다.
SET 문이 아닌 다른 구문으로 값을 변수에 할당할 수 있다. 이 경우에 할당 연산자는 = 가 아니라 := 여야만 한다. =는 SET 이 아
닌 구문에서는 비교 연산자로 쓰이기 때문이다.
mysql> SET @t1=0, @t2=0, @t3=0;
mysql> SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;
+----------------------+------+------+------+
| @t1:=(@t2:=1)+@t3:=4 | @t1 | @t2 | @t3 |
+----------------------+------+------+------+
| 5| 5| 1| 4|
+----------------------+------+------+------+
사용자 변수는 식을 사용할 수 있는 곳에 쓸 수 있다. 하지만 SELECT 문의 LIMIT 절이나, LOAD DATA문의 IGNORE N
LINES 절과 같이 숫자만 들어갈 수 있는 곳에도 사용할 수 있는 것은 아니다.
문자열을 사용자 변수에 할당하면, 변수는 문자열과 같은 문자열 집합과 콜레이션을 갖는다. 사용자 변수의 coercibility는

:::MySQL Korea:::
MySQL 5.0.3에서는 암시적이다(implicit). (테이블 컬럼 값들의 coercibility와 같다.)

Note: SELECT 구문에서는, 각 식이 클라이언트에 보내졌을 때에만 평가된다. 이 말은 HAVING, GROUP BY, 나 ORDER BY 절
에서, SELECT 목록에 있는 변수가 사용된 식을 참조할 수 없다는 뜻이다. 예를 들어, 다음 구문은 의도된 대로 동작하지 않는다.
mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM tbl_name HAVING b=5;
HAVING 절에 쓰인 b는 SELECT 목록에 있는, @aa 가 사용된 식의 별명이다. 이것은 의도된 대로 동작하지 않는다: @aa 가 현
재 줄이 아니라, 이전에 선택된 줄에서의 id 값을 갖고 있기 때문이다.
일반적인 규칙은 사용자 변수를 한 구문 안에서 정의하면 같은 구문의 다른 부분에서 절대 사용하지 않는 것이다. 여러분은 예상한
결과를 얻을 수도 있겠지만, 반드시 보장되지는 않는다.
한 구문 안에서 변수를 정의하고 사용하는 데에 따른 또다른 사항은, 변수의 기본 결과 타입이 구문의 시작 부분에서의 변수 타입
에 기반한다는 것이다. 다음 예제가 이것을 설명한다:
mysql> SET @a='test';
mysql> SELECT @a,(@a:=20) FROM tbl_name;
SELECT 구문에서, MySQL은 두 번째 열에서 @a가 수로 설정되었더라도, 첫째 열이 문자열이고 @a에 관한 모든 접근을 문자열
로 한다고 알린다. 우리가 SELECT 문을 실행하고 나면, 다음 구문에서 @a는 수로 여겨진다.
이런 행동에서 나오는 문제를 피하기 위해, 한 구문 안에 같은 변수를 동시에 설정하고 사용하지 않거나, 변수를 사용하기 전에 0,
0.0, 혹은 ‘’로 정의해야 한다.
초기화되지 않은 변수를 참조하는 경우, 그 변수는 NULL값을 갖는 문자열 형이다

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.4. 코멘트 신텍스
9. 언어 구조 (Language Structure) MySQL 서버는 세 가지 형태의 코멘트 스타일을 지원한다:

9.4. 코멘트 신텍스
9.4 코멘트 신텍스 ● ‘#’문자를 사용한 라인.

● ‘-- ’ 시퀀스를 사용한 라인. MySQL에서는, ‘-- ’ (double-dash) 코멘트 스타일은 최소한 한 개의 화이트스페이
스(whitespace)또는 제어 문자(control character) (스페이스, 탭, 뉴라인(newline) 등등)가 두 번째 대쉬(the second
dash) 다음에 오도록 하고 있다. 이것은 표준 SQL 코멘트 신텍스와는 다소 차이가 있으며, Section 1.9.5.7, “'--' 코멘
트 시작 형태”를 참조하기 바란다.
● C 프로그래밍에서와 같이 /* 시퀀스로 시작하고 */ 시퀀스로 끝나는 라인. 이 신텍스는 코멘트가 시작되는 라인이 끝나는
라인과 같을 필요가 없기 때문에 여러 줄의 코멘트를 작성할 수 있도록 해 준다.
아래의 예문은 위의 세 가지 형태의 코멘트를 보여 주고 있다:

mysql> SELECT 1+1; # This comment continues to the end of line
mysql> SELECT 1+1; -- This comment continues to the end of line
mysql> SELECT 1 /* this is an in-line comment */ + 1;
mysql> SELECT 1+
/*
this is a
multiple-line comment
*/
1;
MySQL 서버는 C-스타일의 코멘트 중의 몇몇 변형 스타일을 지원한다. 이러한 것들은 아래의 형태를 사용해서 MySQL 확장 형태
에 포함되는 코드를 작성할 수가 있다:
/*! MySQL-specific code */
이와 같은 경우, MySQL 서버는 코멘트에 포함되어 있는 코드를 다른 SQL 명령문 형태로 파스(parse)하고 실행을 하지만, 다른

:::MySQL Korea:::
SQL 서버는 이것을 무시한다. 예를 들면, MySQL 서버는 아래의 명령문에 있는 STRAIGHT_JOIN 키워드를 인식할 수 있지만,
다른 SQL 서버는 인식하지 못한다:
SELECT /*! STRAIGHT_JOIN */ col1 FROM table1,table2 WHERE ...
만일 여러분이 If you add a version number after the ‘!’ 문자 다음에 버전 정보를 추가한다면, 이 신텍스는 이렇게 지정된
MySQL 버전과 같거나 보다 늦게 출시된 서버에서만 실행이 된다. 아래의 코멘트에 있는 TEMPORARY 키워드는 MySQL
3.23.02 또는 그 이상 버전의 서버에서만 구동을 한다:
CREATE /*!32302 TEMPORARY */ TABLE t (a INT);
위에서 설명한 코멘트는 mysqld 서버가 SQL명령문을 파스(parse)하는 방식에 영향을 준다. mysql 클라이언트 프로그램은 또한
서버에 명령문을 보내기 전에 몇몇 파싱 동작을 하기도 한다. (이러한 동작은 다중 명령문 입력 라인 안에 있는 명령문의 범위를 판
단하기 위해 실행된다.)

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 9.5. MySQL 에서 사용 지정된 단어 다루기
9. 언어 구조 (Language Structure) SELECT와 같이 사용이 지정된 단어, TIMESTAMP 또는 GROUP와 같은 빌트-인(built-in) MySQL 데이터 타입 또는 함수의
9.5. MySQL 에서 사용 지정된 단어 다루기 이름을 테이블 또는 컬럼 이름과 같은 식별자로 사용하고자 시도를 할 때 문제가 일반적으로 발생한다.
9.5 MySQL 에서 사용 지정된 단어 다루기 만일 식별자가 사용 지정 단어라면, 여러분은 반드시 이것을 인용 부호화 해야 한다. Section 9.2, “데이터 베이스, 테이블, 인덱
스, 컬럼, 그리고 별칭 이름”을 참조할 것. 예외 사항: 수식 이름에서 점을 가지고 있는 단어는 반드시 식별자이기 때문에, 이 단어
가 사용 지정 단어일 지라도, 인용 부호를 사용할 필요는 없다.
함수의 이름을 식별자로 사용하는 것은 가능하다. 예를 들면, ABS를 컬럼 이름으로 사용하는 것은 가능하다. 하지만, 디폴트로는,
함수를 호출 할 때에는 함수 이름과 ‘(’ 문자 사이에 어떠한 화이트스페이스(whitespace)도 사용할 수가 없다. 이러한 요구 사
항은 컬럼 이름에 대한 참조화 함수 호출을 구분하기 위해 필요한 것이다.
이러한 특성으로 인해 몇몇 문장 안에서 스페이스를 생략하면 이것을 함수 이름으로 해석하는 경우가 발생한다. 예를 들면, 아래의
명령문은 허용이 된다:
mysql> CREATE TABLE abs (val INT);
하지만 abs 다음에 스페이스를 생략하게 되면, 이 신텍스는 에러를 발생시키는데, 그 이유는 이 명령문이 ABS() 함수를 호출하는
것으로 생각되기 때문이다:
mysql> CREATE TABLE abs(val INT);

ERROR 1064 (42000) at line 2: You have an error in your SQL
syntax ... near 'abs(val INT)'
만일 IGNORE_SPACE SQL 모드가 활성화 되어 있다면, 서버는 함수 호출에서 함수 이름과 ‘(’ 문자 사이에 화이트스페이스를
가지는 것을 허용한다. 이렇게 하면 함수 이름은 사용 지정 단어처럼 취급된다. 결론적으로, 함수 이름과 같은 식별자는 반드시
Section 9.2, “데이터 베이스, 테이블, 인덱스, 컬럼, 그리고 별칭 이름”에서 설명한 방식으로 인용 부호화 되어야 한다. 서버
SQL 모드는 Section 5.2.5, “서버 SQL 모드”에서 설명한 방식으로 제어가 된다.

:::MySQL Korea:::
아래의 테이블에 있는 단어들은 MySQL 5.0에서 명확하게 사용이 지정된 단어들이다. 여러분이 보다 상위의 버전으로 업데이트
를 하고자 할 때에는 향후에 사용이 지정될 단어를 미리 알아보는 것은 좋은 생각이다. 아래의 테이블에 있는 대부분의 단어들은 표
준 SQL에서 컬럼 또는 테이블 이름으로 사용할 수 없는 것들이다 (GROUP와 같이).
ADD ALL ALTER
ANALYZE AND AS
ASC ASENSITIVE BEFORE
BETWEEN BIGINT BINARY
BLOB BOTH BY
CALL CASCADE CASE
CHANGE CHAR CHARACTER
CHECK COLLATE COLUMN
CONDITION CONNECTION CONSTRAINT
CONTINUE CONVERT CREATE
CROSS CURRENT_DATE CURRENT_TIME
CURRENT_TIMESTAMP CURRENT_USER CURSOR
DATABASE DATABASES DAY_HOUR
DAY_MICROSECOND DAY_MINUTE DAY_SECOND
DEC DECIMAL DECLARE
DEFAULT DELAYED DELETE
DESC DESCRIBE DETERMINISTIC
DISTINCT DISTINCTROW DIV
DOUBLE DROP DUAL
EACH ELSE ELSEIF
ENCLOSED ESCAPED EXISTS

:::MySQL Korea:::
EXIT EXPLAIN FALSE
FETCH FLOAT FLOAT4
FLOAT8 FOR FORCE
FOREIGN FROM FULLTEXT
GRANT GROUP HAVING
HIGH_PRIORITY HOUR_MICROSECOND HOUR_MINUTE
HOUR_SECOND IF IGNORE
IN INDEX INFILE
INNER INOUT INSENSITIVE
INSERT INT INT1
INT2 INT3 INT4
INT8 INTEGER INTERVAL
INTO IS ITERATE
JOIN KEY KEYS
KILL LEADING LEAVE
LEFT LIKE LIMIT
LINES LOAD LOCALTIME
LOCALTIMESTAMP LOCK LONG
LONGBLOB LONGTEXT LOOP
LOW_PRIORITY MATCH MEDIUMBLOB
MEDIUMINT MEDIUMTEXT MIDDLEINT
MINUTE_MICROSECOND MINUTE_SECOND MOD
MODIFIES NATURAL NOT
NO_WRITE_TO_BINLOG NULL NUMERIC

:::MySQL Korea:::
ON OPTIMIZE OPTION
OPTIONALLY OR ORDER
OUT OUTER OUTFILE
PRECISION PRIMARY PROCEDURE
PURGE RAID0 READ
READS REAL REFERENCES
REGEXP RELEASE RENAME
REPEAT REPLACE REQUIRE
RESTRICT RETURN REVOKE
RIGHT RLIKE SCHEMA
SCHEMAS SECOND_MICROSECOND SELECT
SENSITIVE SEPARATOR SET
SHOW SMALLINT SONAME
SPATIAL SPECIFIC SQL
SQLEXCEPTION SQLSTATE SQLWARNING
SQL_BIG_RESULT SQL_CALC_FOUND_ROWS SQL_SMALL_RESULT
SSL STARTING STRAIGHT_JOIN
TABLE TERMINATED THEN
TINYBLOB TINYINT TINYTEXT
TO TRAILING TRIGGER
TRUE UNDO UNION
UNIQUE UNLOCK UNSIGNED
UPDATE UPGRADE USAGE
USE USING UTC_DATE

:::MySQL Korea:::
UTC_TIME UTC_TIMESTAMP VALUES
VARBINARY VARCHAR VARCHARACTER
VARYING WHEN WHERE
WHILE WITH WRITE
X509 XOR YEAR_MONTH
ZEROFILL
아래의 단어들은 MySQL 5.0에서 새롭게 사용이 지정된 단어들이다: ASENSITIVE, CALL, CONDITION, CONNECTION,
CONTINUE, CURSOR, DECLARE, DETERMINISTIC, EACH, ELSEIF, EXIT, FETCH, GOTO, INOUT, INSENSITIVE,
ITERATE, LABEL, LEAVE, LOOP, MODIFIES, OUT, READS, RELEASE, REPEAT, RETURN, SCHEMA, SCHEMAS,
SENSITIVE, SPECIFIC, SQL, SQLEXCEPTION, SQLSTATE, SQLWARNING, TRIGGER, UNDO, UPGRADE, WHILE.
MySQL은 이전에 많은 사람들이 이미 사용을 해 오고 있는 키워드들에 대해서는 인용 부호를 사용하지 않아도 되게끔 하고 있다.
아래의 리스트는 이러한 단어들에 대한 예이다:
● ACTION
● BIT
● DATE
● ENUM
● NO
● TEXT
● TIME
● TIMESTAMP

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 10. 문자 셋 지원
10. 문자 셋 지원 10.1. 일반적인 용도의 문자 셋과 콜레션
10 문자 셋 지원 10.2. MySQL에서의 문자 셋과 콜레션
10.1 일반적인 용도의 문자 셋과 콜레션 10.3. 문자 셋과 콜레션 지정하기
10.2 MySQL에서의 문자 셋과 콜레션 10.3.1. 서버 문자 셋과 콜레션

10.3.2. 데이터 베이스 문자 셋과 콜레션
10.3 문자 셋과 콜레션 지정하기
10.3.3. 테이블 문자 셋과 콜레션
10.3.1 서버 문자 셋과 콜레션
10.3.4. 컬럼 문자 셋과 콜레션
10.3.2 데이터 베이스 문자 셋과 콜레션
10.3.5. 문자 스트링 리터럴 문자 셋과 콜레션
10.3.3 테이블 문자 셋과 콜레션
10.3.6. 국가 문자 셋
10.3.4 컬럼 문자 셋과 콜레션
10.3.7. 문자 셋과 콜레션 할당의 예
10.3.5 문자 스트링 리터럴 문자 셋과 콜레션
10.3.8. 다른 DBMS와의 호환성
10.3.6 국가 문자 셋
10.4. 문자 셋과 콜레션 접속
10.3.7 문자 셋과 콜레션 할당의 예 10.5. 콜레션 이슈
10.3.8 다른 DBMS와의 호환성 10.5.1. SQL명령문에서 COLLATE 사용하기
10.4 문자 셋과 콜레션 접속 10.5.2. COLLATE 구문 우선 순위
10.5 콜레션 이슈 10.5.3. BINARY 연산자
10.5.1 SQL명령문에서 COLLATE 사용하기 10.5.4. 콜레션 결정이 애매 모호한 특별 사례들
10.5.2 COLLATE 구문 우선 순위 10.5.5. 콜레션은 반드시 올바른 문자 셋용 이어야 한다
10.5.3 BINARY 연산자 10.5.6. 콜레션 효과의 사례
10.5.4 콜레션 결정이 애매 모호한 특별 사례들 10.6. 문자 셋 지원에 의해 영향을 받는 연산들
10.5.5 콜레션은 반드시 올바른 문자 셋용 이어야 한다 10.6.1. 결과 스트링

10.6.2. CONVERT() 및 CAST()
10.5.6 콜레션 효과의 사례
10.6.3. SHOW 명령문과 INFORMATION_SCHEMA
10.6 문자 셋 지원으로 영향을 받는 연산
10.7. 유니코드 지원

:::MySQL Korea:::
10.6.1 결과 스트링 10.8. 메타 데이터를 위한 UTF-8
10.6.2 CONVERT() 및 CAST() 10.9. MySQL이 지원하는 문자 셋과 콜레션
10.6.3 SHOW 명령문 및 INFORMATION_SCHEMA 10.9.1. 유니코드 문자 셋

10.9.2. West European Character Sets
10.7 유니 코드 지원
10.9.3. Central European Character Sets
10.8 메타 데이터를 위한 UTF-8
10.9.4. South European and Middle East Character Sets
10.9 MySQL이 지원하는 문자 셋과 콜레션
10.9.5. Baltic Character Sets
10.9.1 유니 코드 문자 셋
10.9.6. Cyrillic Character Sets
10.9.7 아시아 문자 셋
10.9.7. 아시아 문자 셋
MySQL은 다양한 문자 셋을 사용해서 데이터를 저장하고 여러 가지 콜레션에 따라서 비교 연산을 할 수 있도록 지원하는 문
자 셋을 가지고 있다. 여러분은 서버, 데이터 베이스, 테이블, 그리고 컬럼 레벨에서 문자 셋을 지정할 수가 있다. MySQL은
MyISAM, MEMORY, NDBCluster, 그리고 InnoDB 스토리지 엔진을 위한 문자 셋 사용을 지원한다.
이 장에서는 아래의 주제를 다루고 있다:
● 문자 셋과 콜레션이 무엇인가?
● 문자 셋 할당을 위한 다중-레벨 디폴트 시스템
● 문자 셋과 콜레션을 지정하기 위한 신텍스
● 이것들로 인해 영향을 받는 함수와 연산
● 유니코드 지원
● 사용 가능한 문자 셋과 콜레션
문자 셋 이슈는 데이터 스토리지 뿐만 아니라 클라이언트 프로그램과 MySQL 서버간의 통신에도 영향을 주게 된다. 만일 여러
분이 디폴트와는 다른 문자 셋을 사용해서 서버와 클라이언트 프로그램이 통신하도록 하고자 한다면, 적용하고자 하는 문자 셋
을 지정해야 한다. 예를 들면, utf8 유니 코드 문자 셋을 사용하고자 한다면, 서버에 접속을 한 다음에 아래의 명령문을 입력한
다:
SET NAMES 'utf8';
보다 자세한 정보는 Section 10.4, “문자 셋과 콜레션 접속”를 참조하기 바란다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.1. 일반적인 용도의 문자 셋과 콜레션
10. 문자 셋 지원 문자 셋이란 심볼과 엔코딩(encoding) 셋을 의미한다. 콜레션은 하나의 문자 셋에 있는 문자들을 비교하기 위한 규칙 셋을 의미한
10.1. 일반적인 용도의 문자 셋과 콜레션 다. 가상의 문자 셋을 사용해서 설명을 보다 명확히 하도록 하자.
10.1 일반적인 용도의 문자 셋과 콜레션

4개의 문자를 가지는 알파벳이 있다고 가정하자: ‘A’, ‘B’, ‘a’, ‘b’. 각각의 문자에 숫자를 하나씩 부여한다: ‘A’ =
0, ‘B’ = 1, ‘a’ = 2, ‘b’ = 3. 문자 ‘A’는 심볼이고, 숫자 0 은 ‘A’에 대한 엔코딩이며, 네 개의 문자를 각각의 엔코
딩과 결합한 것이 문자 셋이 되는 것이다.
두 개의 스트링 값을 비교하는 경우를 가정하자: ‘A’ 와 ‘B’. 가장 간단하게 비교하는 방법은 각 문자의 엔코딩을 살펴 보는
것이다: ‘A’의 0 과 ‘B’의 1. 0 이 1보다 작기 때문에, 우리는 ‘A’가 ‘B’보다 작다고 말할 수 있다. 방금 행한 방법이 우
리가 사용한 문자 셋에 대해서 콜레션을 적용한 것이다. 콜레션은 규칙 셋이다 (이와 같은 경우에는 한 가지 규칙만 있음): “엔코
딩을 비교한다.” 위와 같이 콜레션 방법 중에 가장 간단한 방법을 우리는 바이너리 콜레션이라고 부른다.
하지만 만일 우리가 소문자와 대문자를 동일하게 하고자 한다면? 이럴 경우에는 최소한 두 개의 규칙을 가져야 한다: (1) 소문자
‘a’ 와 ‘b’를 대문자 ‘A’ 및 ‘B’와 동일하게 취급한다; (2) 그 다음에 엔코딩을 비교한다. 이러한 방식을 대소 문자 구분
이 없는 콜레션(case-insensitive collation)이라고 부른다. 이 방식은 바이너리 콜레션보다는 다소 복잡하다.
실 생활에서는, 대부분의 문자 셋이 많은 문자를 가지고 있다: ‘A’ 와 ‘B’ 뿐만 아니라 전체 알파벳, 때로는 다양한 형태의 알
파벳 또는 수 천개의 문자를 사용하는 동양의 필기 시스템. 또한 실제의 생활에서는, 대부분의 콜레션은 소문자를 구분하는 것 뿐
만 아니라 액센트를 구분하는 규칙까지도 가지고 있다.
MySQL은 이와 같은 문제를 아래와 같이 처리한다:
● 다양한 문자 셋을 사용해서 스트링을 저장한다

● 다양한 콜레션 규칙을 사용해서 스트링을 비교한다
● 동일한 서버, 동일 데이터 베이스, 또는 심지어 동일 테이블에서 서로 다른 문자 셋 또는 콜레션을 사용해서 스트링을 조합

:::MySQL Korea:::
한다
● 어떤 레벨에서건 문자 셋과 콜레션을 지정할 수 있도록 허용한다
MySQL은 다른 데이터 베이스 시스템보다도 우수하게 문자 셋 및 콜레션을 처리하고 있지만, 이러한 특성을 효과적으로 사용하기
위해서는, 여러분은 사용 가능한 문자 셋과 콜레션이 어떤 것이 있으며, 디폴트 값을 어떻게 변경 시킬 수 있는지, 그리고 이것들이
스트링 연산자와 함수에 어떻게 영향을 주는지를 잘 알고 있어야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.2. MySQL에서의 문자 셋과 콜레션
10. 문자 셋 지원 MySQL 서버는 다양한 문자 셋을 지원한다. 사용 가능한 문자 셋을 보기 위해서는, SHOW CHARACTER SET 명령문을 입력한
10.2. MySQL에서의 문자 셋과 콜레션 다. 아래에 있는 리스트는 사용 가능한 문자 셋의 일부분이며, 보다 자세한 정보는 Section 10.9, “MySQL이 지원하는 문자 셋과
10.2 MySQL에서의 문자 셋과 콜레션 콜레션”을 참조하기 바란다.
mysql> SHOW CHARACTER SET;

+----------+-----------------------------+---------------------
+--------+
| Charset | Description | Default collation | Maxlen |
+----------+-----------------------------+---------------------
+--------+
| big5 | Big5 Traditional Chinese | big5_chinese_ci | 2|
| dec8 | DEC West European | dec8_swedish_ci | 1|
| cp850 | DOS West European | cp850_general_ci | 1|
| hp8 | HP West European | hp8_english_ci | 1|
| koi8r | KOI8-R Relcom Russian | koi8r_general_ci | 1|
| latin1 | cp1252 West European | latin1_swedish_ci | 1|
| latin2 | ISO 8859-2 Central European | latin2_general_ci | 1|
| swe7 | 7bit Swedish | swe7_swedish_ci | 1|
| ascii | US ASCII | ascii_general_ci | 1|
| ujis | EUC-JP Japanese | ujis_japanese_ci | 3|
| sjis | Shift-JIS Japanese | sjis_japanese_ci | 2|
| hebrew | ISO 8859-8 Hebrew | hebrew_general_ci | 1|
| tis620 | TIS620 Thai | tis620_thai_ci | 1|
| euckr | EUC-KR Korean | euckr_korean_ci | 2|

:::MySQL Korea:::
| koi8u | KOI8-U Ukrainian | koi8u_general_ci | 1|

| gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2|
| greek | ISO 8859-7 Greek | greek_general_ci | 1|
| cp1250 | Windows Central European | cp1250_general_ci | 1|
| gbk | GBK Simplified Chinese | gbk_chinese_ci | 2|
| latin5 | ISO 8859-9 Turkish | latin5_turkish_ci | 1|
...
주어진 모든 문자 셋은 적어도 하나의 콜레션을 가지고 있다. 어떤 것들은 여러 개의 콜레션을 가지고 있기도 한다. 한 문자 셋에 대
한 콜레션을 보기 위해서는, SHOW COLLATION 명령문을 사용한다. 예를 들면, latin1 (cp1252 West European) 문자 셋의 콜
레션을 보고자 한다면, 아래와 같이 입력을 한다:
mysql> SHOW COLLATION LIKE 'latin1%';

+---------------------+---------+----+---------+----------+---------+
| Collation | Charset | Id | Default | Compiled | Sortlen |
+---------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1 | 5 | | | 0|
| latin1_swedish_ci | latin1 | 8 | Yes | Yes | 1|
| latin1_danish_ci | latin1 | 15 | | | 0|
| latin1_german2_ci | latin1 | 31 | | Yes | 2|
| latin1_bin | latin1 | 47 | | Yes | 1|
| latin1_general_ci | latin1 | 48 | | | 0|
| latin1_general_cs | latin1 | 49 | | | 0|
| latin1_spanish_ci | latin1 | 94 | | | 0|
+---------------------+---------+----+---------+----------+---------+
latin1 콜레션은 아래와 같은 의미를 가지고 있다:
Collation Meaning
latin1_german1_ci German DIN-1
latin1_swedish_ci Swedish/Finnish

:::MySQL Korea:::
latin1_danish_ci Danish/Norwegian
latin1_german2_ci German DIN-2
latin1_bin Binary according to latin1 encoding
latin1_general_ci Multilingual (Western European)
latin1_general_cs Multilingual (ISO Western European), case sensitive
latin1_spanish_ci Modern Spanish
콜레션은 아래와 같은 일반적인 특성을 가지고 있다:
● 두 개의 서로 다른 문자 셋은 동일한 콜레션을 가질 수 없다.

● 각각의 문자 셋은 디폴트 콜레션을 하나씩 가지고 있다. 예를 들면, latin1에 대한 디폴트 콜레션은 latin1_swedish_ci이
다. SHOW CHARACTER SET의 결과 값은 출력되는 각각의 문자 셋에 대한 디폴트 콜레션이 어떤 것인지를 가리킨다.
● 콜레션 이름의 변환이 존재한다: 콜레션 이름은 서로 연관된 문자 셋의 이름을 가지고 시작되고, 이것들은 일반적으로 언
어 이름을 포함하며, _ci (case insensitive), _cs (case sensitive), 또는 _bin (binary)로 끝을 맺는다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3. 문자 셋과 콜레션 지정하기
10. 문자 셋 지원 10.3.1. 서버 문자 셋과 콜레션

10.3. 문자 셋과 콜레션 지정하기 10.3.2. 데이터 베이스 문자 셋과 콜레션
10.3 문자 셋과 콜레션 지정하기 10.3.3. 테이블 문자 셋과 콜레션
10.3.1 서버 문자 셋과 콜레션 10.3.4. 컬럼 문자 셋과 콜레션
10.3.2 데이터 베이스 문자 셋과 콜레션 10.3.5. 문자 스트링 리터럴 문자 셋과 콜레션

10.3.6. 국가 문자 셋
10.3.3 테이블 문자 셋과 콜레션
10.3.7. 문자 셋과 콜레션 할당의 예
10.3.4 컬럼 문자 셋과 콜레션
10.3.8. 다른 DBMS와의 호환성
10.3.6 국가 문자 셋
문자 셋과 콜레션에 대해서는 4 개의 레벨에서 디폴트 설정이 존재한다: 서버, 데이터 베이스, 테이블, 그리고 컬럼. 다음에 설명하
10.3.7 문자 셋과 콜레션 할당의 예
는 내용은 다소 복잡하게 보이겠지만, 여러 레벨의 디폴트 설정을 통해 보다 자연스럽고 명확한 결과를 얻을 수 있다는 것을 알게
10.3.8 다른 DBMS와의 호환성
될 것이다.
CHARACTER SET은 문자 셋을 지정하는 구문에서 사용된다. CHARSET은 CHARACTER SET의 동의어 형태로 사용되기도
한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.1. 서버 문자 셋과 콜레션
10. 문자 셋 지원
10.3. 문자 셋과 콜레션 지정하기 MySQL 서버는 서버 문자 셋과 서버 콜레션을 가지고 있다. 이러한 것들은 서버 스타트 업 시점에 설정할 수 있으며 런 타임시에
10.3.1 서버 문자 셋과 콜레션 변경을 할 수 있다.
기본적으로는, 서버 문자 셋과 콜레션은 여러분이 mysqld을 시작할 때 사용하는 옵션에 의존을 한다. 여러분은 문자 셋에 대해서
--character-set-server를 사용할 수 있다. 이것과 함께, 콜레션에 대해서는 --collation-server를 사용할 수가 있다. 만일
문자 셋을 지정하지 않는다면, --character-set-server=latin1라고 말하는 것과 같아진다. 만일 여러분이 콜레션은 지정하지
않고 문자 셋만을 지정한다면 (예를 들면, latin1), 이것은 --character-set-server=latin1 --collation-
server=latin1_swedish_ci를 지정하는 것과 같게 되는데, 그 이유는 latin1_swedish_ci가 latin1의 디폴트 콜레션이기 때문이다.
따라서, 아래의 세 가지 명령어는 모두 동일한 효과를 나타낸다:
shell> mysqld
shell> mysqld --character-set-server=latin1
shell> mysqld --character-set-server=latin1 ￦
--collation-server=latin1_swedish_ci
이 설정을 변경하는 방법 중에 한 가지는 재 컴파일을 하는 것이다. 만일 소스를 사용해서 MySQL을 설치할 때 디폴트 서버 문자
셋과 콜레션을 변경하고자 한다면, 다음과 같이 한다: configure에 대한 인수로 --with-charset 과 --with-collation을 사용한
다. 예를 들면:

:::MySQL Korea:::
shell> ./configure --with-charset=latin1
또는:
shell> ./configure --with-charset=latin1 ￦
--with-collation=latin1_german1_ci
mysqld 와 configure는 모두 문자 셋/콜레션 결합이 유효한지를 검증한다. 만일 유효하지 않다면, 각 프로그램은 에러 메시지를 출
력하고 종료를 한다.
현재의 서버 문자 셋과 콜레션은 character_set_server 와 collation_server 시스템 변수 값을 가지고 알아볼 수가 있다. 이 변수

들의 값은 런 타임시에 변경할 수가 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.2. 데이터 베이스 문자 셋과 콜레션
10.3. 문자 셋과 콜레션 지정하기 모든 데이터 베이스는 데이터 베이스 문자 셋과 데이터 베이스 콜레션을 가지고 있다. CREATE DATABASE 와 ALTER
10.3.2 데이터 베이스 문자 셋과 콜레션 DATABASE 명령문은 데이터 베이스 문자 셋과 콜레션을 지정하기 위한 옵션 구문을 가지고 있다:
CREATE DATABASE db_name
[[DEFAULT] CHARACTER SET charset_name]
[[DEFAULT] COLLATE collation_name]
ALTER DATABASE db_name
[[DEFAULT] CHARACTER SET charset_name]
[[DEFAULT] COLLATE collation_name]
키워드 SCHEMA를 DATABASE 대신에 사용할 수 있다.
모든 데이터 베이스 옵션은 데이터 베이스 디렉토리에 있는 db.opt라는 이름의 텍스트 파일에 저장된다.
CHARACTER SET 과 COLLATE 구문은 동일 MySQL 서버에서 서로 다른 문자 셋과 콜레션을 가지는 데이터 베이스를 생성할
수 있게 한다.

:::MySQL Korea:::
예문:
CREATE DATABASE db_name CHARACTER SET latin1 COLLATE latin1_swedish_ci;
MySQL은 아래의 방식을 사용해서 데이터 베이스 문자 셋과 데이터 베이스 콜레션을 선택한다:
● 만일 CHARACTER SET X 와 COLLATE Y 를 모두 지정한다면, 문자 셋은 X 가 되고 콜레션은 Y가 된다.

● 만일 CHARACTER SET X는 지정하였지만 COLLATE를 지정하지 않았다면, 문자 셋은 X 가 되고 콜레션은 디폴트를
사용한다.
● 만일 COLLATE Y 는 지정하였지만 CHARACTER SET을 지정하지 않았다면, 문자 셋은 Y 와 관련된 것이 되고 콜레션
은 Y가 된다.
● 아무것도 지정을 하지 않으면, 서버의 문자 셋과 콜레션을 사용하게 된다.
만일 테이블 문자 셋과 콜레션을 CREATE TABLE 명령문에서 지정하지 않았다면, 데이터 베이스 문자 셋과 콜레션을 디폴트로
사용하게 된다.
디폴트 데이터 베이스에 대한 문자 셋과 콜레션은 character_set_database 와 collation_database 시스템 변수의 값을 통해서 알

수가 있다. 서버는 디폴트 데이터 베이스가 변경될 때마다 이 변수 값을 설정한다. 만일 디폴트 데이터 베이스가 존재하지 않는다
면, 이에 대응하는 서버-레벨 시스템 변수 character_set_server 와 collation_server의 값이 이들 변수의 값으로 사용된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.3. 테이블 문자 셋과 콜레션
10.3. 문자 셋과 콜레션 지정하기 모든 테이블은 테이블 문자 셋과 테이블 콜레션을 가지고 있다. CREATE TABLE 과 ALTER TABLE 명령문에는 테이블 문자 셋
10.3.3 테이블 문자 셋과 콜레션 과 콜레션을 지정하기 위한 옵션 구문이 있다:
CREATE TABLE tbl_name (column_list)
[[DEFAULT] CHARACTER SET charset_name] [COLLATE collation_name]]
ALTER TABLE tbl_name
[[DEFAULT] CHARACTER SET charset_name] [COLLATE collation_name]
예문:
CREATE TABLE t1 ( ... ) CHARACTER SET latin1 COLLATE latin1_danish_ci;
MySQL은 아래의 방법으로 테이블 문자 셋과 콜레션을 선택한다:
● 만일 CHARACTER SET X 와 COLLATE Y 를 모두 지정한다면, 문자 셋은 X 가 되고 콜레션은 Y가 된다.

● 만일 CHARACTER SET X 는 지정하지만 COLLATE는 지정하지 않으면, 문자 셋은 X 가 되고 콜레션은 디폴트를 사용
하게 된다.
● 만일 COLLATE Y 는 지정하고 CHARACTER SET는 지정하지 않으면, 문자 셋은 Y 와 관련된 것이 되고 콜레션은 Y가
된다.

:::MySQL Korea:::
● 모두 지정하지 않으면, 데이터 베이스 문자 셋과 콜레션을 사용하게 된다.
만일 개별적인 컬럼 정의에서 컬럼 문자 셋과 콜레션을 지정하지 않으면, 테이블 문자 셋과 콜레션을 디폴트 값으로 사용하게 된
다. 테이블 문자 셋과 콜레션은 MySQL에만 있는 것이다; 표준 SQL 서버에는 이러한 것이 없다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.4. 컬럼 문자 셋과 콜레션
10.3. 문자 셋과 콜레션 지정하기 모든 “문자” 컬럼 (즉, CHAR, VARCHAR, 또는 TEXT 타입의 컬럼)은 컬럼 문자 셋과 컬럼 콜레션을 가지고 있다. 컬럼 정의
10.3.4 컬럼 문자 셋과 콜레션 신텍스는 컬럼 문자 셋과 콜레션을 지정하기 위한 옵션 구문을 가지고 있다:
col_name {CHAR | VARCHAR | TEXT} (col_length)
[CHARACTER SET charset_name] [COLLATE collation_name]
예문:
CREATE TABLE Table1
column1 VARCHAR(5) CHARACTER SET latin1 COLLATE latin1_german1_ci
);
MySQL은 아래와 같은 방식으로 컬럼 문자 셋과 콜레션을 선택한다:
● 만일 CHARACTER SET X 와 COLLATE Y 를 모두 지정하면, 문자 셋은 X 가 되고 콜레션은 Y 가 된다.

● 만일 CHARACTER SET X 는 지정을 하고 COLLATE는 지정하지 않으면, 문자 셋은 X 가 되고 콜레션은 디폴트를 사용
하게 된다.
● 만일 COLLATE Y 는 지정을 하되 CHARACTER SET는 지정하지 않으면, 문자 셋은 Y 와 관련된 것을 사용하고 콜레션
은 Y를 사용하게 된다.

:::MySQL Korea:::
● 아무것도 지정하지 않는 경우에는, 테이블 문자 셋과 콜레션을 사용하게 된다.
CHARACTER SET 과 COLLATE 구문은 표준 SQL이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.5. 문자 스트링 리터럴 문자 셋과 콜레션
10.3. 문자 셋과 콜레션 지정하기 모든 문자 스트링 리터럴은 문자 셋과 콜레션을 가지고 있다.

문자 스트링 리터럴은 하나의 문자 셋 인트로듀서(introducer)와 COLLATE 구문을 옵션으로 가질 수가 있다:
[_charset_name]'string' [COLLATE collation_name]
예문:
SELECT 'string';
SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci;
간단한 명령문 SELECT 'string'의 경우, 스트링은 character_set_connection 과 collation_connection 시스템 변수가 정의하는
문자 셋과 콜레션을 갖는다.
_charset_name 수식은 정식으로는 인트로듀서(introducer)라고 불린다. 이것은 파서(parser)에게, “뒤에 따라오는 스트링은 문
자 셋 X를 사용한다”라고 말을 한다. 과거에는 이로 인해 사용자들이 혼란이 있었기 때문에, 우리는 인트로듀서는 어떠한 변환
(conversion)도 일으키지 않는다는 점을 강조한다; 엄밀히 말한다면, 이것은 스트링 값을 변경하지 않는 신호(signal)이다. 또한,
인트로듀서는 표준 헥스 리터럴(hex literal)과 헥스 리터럴 표기법 (x'literal' 및 0xnnnn), 그리고 ? 보다 앞선 규칙이다.
예문:

:::MySQL Korea:::
SELECT _latin1 x'AABBCC';
SELECT _latin1 0xAABBCC;
SELECT _latin1 ?;
MySQL은 리터럴의 문자 셋과 콜레션을 아래와 같은 방식을 선택한다:
● 만일 _X 와 COLLATE Y 를 모두 지정하면, 문자 셋은 X 가 되고 콜레션은 Y 를 사용하게 된다.

● 만일 _X 는 지정하지만 COLLATE를 지정하지 않는다면, 문자 셋은 X 가 되고 콜레션은 디폴트 값을 사용하게 된다.
● 아무것도 지정하지 않는다면, 문자 셋과 콜레션은 character_set_connection 과 collation_connection 시스템 변수의 값
을 사용하게 된다.
예문:
● latin1 문자 셋과 latin1_german1_ci 콜레션을 사용하는 스트링:
• SELECT _latin1'Müller' COLLATE latin1_german1_ci;
● latin1 문자 셋과 디폴트 콜레션 (즉, latin1_swedish_ci)을 사용하는 스트링:
• SELECT _latin1'Müller';
● 접속 디폴트 문자 셋과 콜레션을 사용하는 스트링:
• SELECT 'Müller';
문자 셋 인트로듀서와 COLLATE 구문은 표준 SQL 사양(specification)에 따라서 실행된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.6. 국가 문자 셋
10.3. 문자 셋과 콜레션 지정하기 표준 SQL은 몇몇 미리 지정된 문자 셋을 CHAR이 사용하도록 지정하기 위한 방법으로 NCHAR 또는 NATIONAL CHAR를 정의
10.3.6 국가 문자 셋 한다. MySQL 5.0은 미리 지정된 문자 셋으로 utf8을 사용하고 있다. 예를 들면, 아래의 데이터 타입 선언은 모두 동일한 것이다:
CHAR(10) CHARACTER SET utf8
NATIONAL CHARACTER(10)
NCHAR(10)
따라서:
VARCHAR(10) CHARACTER SET utf8
NATIONAL VARCHAR(10)
NCHAR VARCHAR(10)
NATIONAL CHARACTER VARYING(10)
NATIONAL CHAR VARYING(10)
여러분은 국가 문자 셋에 스트링을 생성하기 위해서 N'literal'을 사용할 수 있다. 아래의 두 명령문은 동일한 것들이다:
SELECT N'some text';

:::MySQL Korea:::
SELECT _utf8'some text';
MySQL 4.1 이전 버전에서 5.0으로 문자 셋 업그레이드에 대한 보다 자세한 정보는 MySQL 3.23, 4.0, 4.1사용자 매뉴얼을 참조
하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.7. 문자 셋과 콜레션 할당의 예
10.3. 문자 셋과 콜레션 지정하기 아래의 예문에서는 MySQL이 디폴트 문자 셋과 콜레션 값을 어떻게 결정하는지에 대한 사항을 보여 준다.
10.3.7 문자 셋과 콜레션 할당의 예

예문 1: 테이블과 컬럼 정의
CREATE TABLE t1
c1 CHAR(10) CHARACTER SET latin1 COLLATE latin1_german1_ci
) DEFAULT CHARACTER SET latin2 COLLATE latin2_bin;
여기에서 latin1 문자 셋과 latin1_german1_ci 콜레션을 사용하는 컬럼이 하나 있다. 정의가 명확하기 때문에, 이것은 그대로 실행
이 된다. latin2 테이블에 latin1 컬럼을 저장하는 것은 아무런 문제가 없다는 점을 잘 알아두자.
예문 2: 테이블과 컬럼 정의
CREATE TABLE t1
c1 CHAR(10) CHARACTER SET latin1
) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

:::MySQL Korea:::
이번에는 latin1 문자 셋과 디폴트 콜레션을 사용하는 컬럼이 있다. 이 형태가 비록 자연스럽게 보인다고 하더라도, 디폴트 콜레션
을 테이블 레벨에서 가져오지는 못한다. 대신에, latin1에 대한 디폴트 콜레션이 항상 latin1_swedish_ci이기 때문에, 컬럼 c1 은
latin1_swedish_ci (latin1_danish_ci이 아님)의 콜레션을 갖게 된다.
Example 3: 테이블과 컬럼 정의
CREATE TABLE t1
c1 CHAR(10)
) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;
이번에는 디폴트 문자 셋과 디폴트 콜레션을 갖는 컬럼이 있다. 이런 환경에서는, MySQL은 컬럼 문자 셋과 콜레션을 결정하기 위
해서 테이블 레벨을 검사한다. 결과적으로, 컬럼 c1에 대한 문자 셋은 latin1이 되고 이것의 콜레션은 latin1_danish_ci가 된다.
예문 4: 데이터 베이스, 테이블, 그리고 컬럼 정의
CREATE DATABASE d1
DEFAULT CHARACTER SET latin2 COLLATE latin2_czech_ci;
USE d1;
CREATE TABLE t1
c1 CHAR(10)
);

:::MySQL Korea:::
이번에는 문자 셋과 콜레션을 지정하지 않고 컬럼을 생성했다. 또한 테이블 레벨에서 문자 셋과 콜레션도 지정하지 않았다. 이런 환
경에서는, MySQL은 테이블 설정(setting)을 결정하기 위해서 데이터 베이스 레벨의 검사를 하게 되는데, 이렇게 한 다음에 컬럼
설정을 하게 된다. 결론적으로, 컬럼c1에 대한 문제 셋은 latin2이 되고 이것의 콜레션은 latin2_czech_ci가 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.3.8. 다른 DBMS와의 호환성
10.3. 문자 셋과 콜레션 지정하기 MaxDb와의 호환성을 위해서는 아래의 명령문을 사용한다. 두 명령문은 동일한 것이
10.3.8 다른 DBMS와의 호환성 다:
CREATE TABLE t1 (f1 CHAR(N) UNICODE);
CREATE TABLE t1 (f1 CHAR(N) CHARACTER SET ucs2);
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.4. 문자 셋과 콜레션 접속
10. 문자 셋 지원 몇몇 문자 셋과 콜레션 시스템 변수는 서버와 클라이언트의 상호 작용과 관련을 갖는다. 이러한 것들 중의 몇 가지는 이전 세션에
10.4. 문자 셋과 콜레션 접속 서 언급하였다:
10.4 문자 셋과 콜레션 접속
● 서버 문자 셋과 콜레션은 character_set_server 와 collation_server 시스템 변수의 값을 가지고 결정할 수 있다.
● 디폴트 데이터 베이스의 문자 셋과 콜레션은 character_set_database 와 collation_database 시스템 변수의 값을 가지고
결정할 수 있다.
추가적인 문자 셋 및 콜레션 시스템 변수는 클라이언트와 서버간의 통신을 처리할 때 포함된다. 모든 클라이언트는 접속과 관련한
문자 셋과 콜레션 시스템 변수를 가지고 있다.
“접속”이란 무엇인지를 생각해 보자: 접속이란 여러분이 서버에 접속을 할 때 만드는 무엇이다. 클라이언트는 쿼리와 같은 SQL
명령문을 서버와의 연결 통로를 통해 전달한다. 서버는 결과 셋과 같은 것을 동일한 연결 통로를 통해 클라이언트에 전달한다. 이것
은 클라이언트 연결을 처리하는 문자 셋과 콜레션에 대해서 몇 가지 궁금한 사항을 일으키게 되는데, 각각의 것들은 시스템 변수에
의해 답을 할 수가 있게 된다.:
● 명령문이 클라이언트에서 보내질 때 포함되는 문자 셋은 어떤 것인가?
서버는 클라이언트가 보낸 명령문에 있는 문자 셋을 사용하기 위해 character_set_client 시스템 변수를 가져 온다.
● 서버가 명령문을 받은 후에 이것을 해석하기 위해서 사용하는 문자 셋은 어떤 것인가?
이에 대해서는, 서버는 character_set_connection 과 collation_connection 시스템 변수를 사용하게 된다. 서버는 클라

이언트 전달한 명령문을 character_set_client에서 character_set_connection (_latin1 또는 _utf8과 같이 인트로듀서
를 가지고 있는 스트링 리터럴은 예외)로 변환 시킨다. collation_connection은 리터럴 스트링에 대한 비교를 위해 매우
중요한 것이다. 컬럼 값을 사용해서 스트링을 비교하는 경우에는 collation_connection가 그리 중요하지가 않게 되는데,

:::MySQL Korea:::
그 이유는 컬럼이 자체 콜레션을 가지고 있기 때문이며, 이것이 보다 우선적인 순위를 갖는 콜레션이 된다.
● 결과 셋 또는 에러 메시지를 클라이언트에 돌려 보내기 전에 서버가 해석해야 하는 문자 셋은 어떤 것이 있는가?
character_set_results 시스템 변수는 서버가 쿼리 결과를 클라이언트에 돌려 보낼 때 포함 되어 있는 문자 셋을 가리킨

다. 이것에는 컬럼 값, 그리고 컬럼 이름과 같은 결과 메타 데이터등이 포함된다.
여러분은 이러한 변수들을 튜닝 설정할 수 있으며, 또는 디폴트 값을 사용할 수도 있다.

접속 문자 셋에 영향을 주는 명령문이 두 개 있다:
SET NAMES 'charset_name'

SET CHARACTER SET charset_name
SET NAMES는 클라이언트가 서버에 SQL명령문을 보낼 때 사용하는 문자 셋을 가리킨다. 따라서, SET NAMES 'cp1251'은 서
버에게 “이 클라이언트로부터 오게 될 메시지는 cp1251 문자 셋을 사용한다”라는 의미를 전달 한다. 또한, 이것은 서버가 클라
이언트에 결과를 돌려 줄 때 사용하는 문자 셋을 나타내기도 한다. (예를 들면, 이것은 여러분이 SELECT 명령문을 사용할 경우 컬
럼 값을 위해 사용할 문자 셋을 가리키는 것이다.)
SET NAMES 'x' 명령문은 아래의 세 명령문과 동일한 것이다:
SET character_set_client = x;
SET character_set_results = x;
SET character_set_connection = x;
character_set_connection을 x로 설정하면 동시에 x에 대한 디폴트 콜레션이 collation_connection으로 설정된다.

SET CHARACTER SET은 SET NAMES과 유사하지만, 이것은 접속 문자 셋과 콜레션을 디폴트 데이터 베이스의 것으로 설정한
다. SET CHARACTER SET x 명령문은 아래의 세 명령문과 동일한 것이다:
SET character_set_client = x;
SET character_set_results = x;
SET collation_connection = @@collation_database;

:::MySQL Korea:::
collation_connection에 대한 설정은 동시에 character_set_connection을 콜레션과 관련된 문자 셋으로 설정해 준다.

클라이언트가 연결이 되면, 클라이언트는 자신이 사용할 문자 셋의 이름을 서버에 전달한다. 서버는 이 이름을 사용해서
character_set_client, character_set_results, character_set_connection 시스템 변수를 설정한다. 이를 통해, 서버는 문자 셋
이름을 사용해서 SET NAMES 연산을 실행하게 된다.
mysql 클라이언트를 사용하면, 여러분이 디폴트 문자 셋과는 다른 것을 사용하고자 할 경우에 서버를 구동 시킬 때 마다 매번
SET NAMES을 실행할 필요가 없어진다. mysql 명령문 라인, 또는 옵션 파일에--default-character-set 옵션을 설정을 추가
할 수도 있다. 예를 들면, 아래의 옵션 파일 설정은 여러분이 mysql를 호출할 때 마다 세 가지의 문자 셋 설정 변수를 koi8r로 변경
시킨다.
[mysql]
default-character-set=koi8r
예문: column1이 CHAR(5) CHARACTER SET latin2 형태로 정의 되었다고 가정하자. 만일 여러분이 SET NAMES 또는
SET CHARACTER SET에 대해 지정을 하지 않는다면, SELECT column1 FROM t에 대해서는, 서버는 클라이언트가 서버에 연
결할 때 지정한 문자 셋을 사용해서 column1에 대한 모든 값을 돌려 준다. 이에 반해서, 만일 여러분이 SELECT 명령문을 입력하
기 전에 SET NAMES 'latin1' 또는 SET CHARACTER SET latin1을 입력하면, 서버는 결과를 돌려 보내기 바로 전에 latin2 값
을 latin1로 변환 시킨다. 만약에 양쪽의 문자 셋에 있지 않는 문자를 변환할 경우에는 다소 시간이 길게 걸리기도 한다.
만일 서버가 결과 셋을 변환 시키지 못하도록 하고자 한다면, character_set_results을 NULL로 설정한다:
SET character_set_results = NULL;
Note: 현재까지는, UCS-2를 클라이언트의 문자 셋으로 사용할 수는 없는데, 이것은 SET NAMES 'ucs2'는 동작을 하지 않는다
는 것을 의미한다.
여러분이 접속을 할 때 사용한 문자 셋과 콜레션 시스템 변수의 값을 보고자 한다면, 아래의 명령문을 입력하면 된다:
SHOW VARIABLES LIKE 'character_set%';

SHOW VARIABLES LIKE 'collation%';

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.5. 콜레션 이슈
10. 문자 셋 지원 10.5.1. SQL 명령문에서 COLLATE 사용하기

10.5. 콜레션 이슈 10.5.2. COLLATE 구문 우선 순위
10.5 콜레션 이슈 10.5.3. BINARY 연산자
10.5.1 SQL명령문에서 COLLATE 사용하기 10.5.4. 콜레션 결정이 애매 모호한 특별 사례들
10.5.2 COLLATE 구문 우선 순위 10.5.5. 콜레션은 반드시 올바른 문자 셋용 이어야 한다

10.5.6. 콜레션 효과의 사례
10.5.3 BINARY 연산자
10.5.4 콜레션 결정이 애매 모호한 특별 사례들
다음에 나오는 섹션들은 문자 셋 콜레션의 다양한 특징을 보여 줄 것이
10.5.5 콜레션은 반드시 올바른 문자 셋용 이어야 한다
다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.5.1. SQL명령문에서 COLLATE 사용하기
10.5. 콜레션 이슈 COLLATE 구문을 사용하면, 여러분은 비교를 위한 디폴트 콜레션을 무시할 수 있게 된다. COLLATE 는 SQL 명령문의 다양한
10.5.1 SQL명령문에서 COLLATE 사용하기 부분에서 사용되는데, 몇 가지 예문이 아래에 있다:
● ORDER BY를 사용한 것:
• SELECT k
• FROM t1
• ORDER BY k COLLATE latin1_german2_ci;
● AS를 사용한 것:
• SELECT k COLLATE latin1_german2_ci AS k1
• FROM t1
• ORDER BY k1;
● GROUP BY를 사용한 것:
• SELECT k
• FROM t1

:::MySQL Korea:::
• GROUP BY k COLLATE latin1_german2_ci;
● 집합 함수를 사용한 것:
• SELECT MAX(k COLLATE latin1_german2_ci)
• FROM t1;
● DISTINCT를 사용한 것:
• SELECT DISTINCT k COLLATE latin1_german2_ci
• FROM t1;
● WHERE를 사용한 것:
• SELECT *
• FROM t1
• WHERE _latin1 'Müller' COLLATE latin1_german2_ci = k;
• SELECT *
• FROM t1
• WHERE k LIKE _latin1 'Müller' COLLATE latin1_german2_ci;
● HAVING을 사용한 것:
• SELECT k
• FROM t1

:::MySQL Korea:::
• GROUP BY k
• HAVING k = _latin1 'Müller' COLLATE latin1_german2_ci;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.5.2. COLLATE 구문 우선 순위
10.5. 콜레션 이슈 COLLATE 구문은 높은 우선 순위를 가지며 (||보다 높음), 따라서 아래의 두 수식은 동일한 것이
10.5.2 COLLATE 구문 우선 순위 다:
x || y COLLATE z
x || (y COLLATE z)
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.5.3. BINARY 연산자
10.5. 콜레션 이슈 BINARY 연산자는 뒤에 따라오는 스트링을 바이너리 스트링으로 캐스트(cast)한다. 이것은 문자를 비교할 때 문자 대 문자로 하
10.5.3 BINARY 연산자 지 않고 바이트 대 바이트로 비교 연산을 하게끔 하기 위한 것이다. BINARY는 또한 뒤따라 오는 스페이스가 의미를 가지도록 만든
다.
mysql> SELECT 'a' = 'A';
-> 1
mysql> SELECT BINARY 'a' = 'A';
-> 0
mysql> SELECT 'a' = 'a ';
-> 1
mysql> SELECT BINARY 'a' = 'a ';
-> 0
BINARY str 는 CAST(str AS BINARY)의 축약형이다.

:::MySQL Korea:::
문자 컬럼 정의에 있는 BINARY 속성은 다른 효과를 갖는다. BINARY 속성을 사용해서 정의된 문자 컬럼은 컬럼의 문자 셋에 대
한 바이너리 콜레션에 할당된다. 모든 문자 셋은 바이너리 콜레션을 갖는다. 예를 들면, latin1 문자 셋에 대한 바이너리 콜레션은
latin1_bin이기 때문에, 만일 테이블의 디폴트 문자 셋이 latin1이라면, 아래의 두 컬럼 정의는 동일한 것이 된다:
CHAR(10) BINARY
CHAR(10) CHARACTER SET latin1 COLLATE latin1_bin
컬럼 속성 형태로의 BINARY의 효과는 MySQL 4.1 이전 버전과는 서로 달라졌다. 예전에는, BINARY 의 결과로 컬럼은 바이너
리 스트링으로 취급이 되었다. 바이너리 스트링은 문자 셋 또는 콜레션이 아닌 바이트 스트링이며, 이것은 바이너리 콜레션을 갖고
있는 비-바이너리(non-binary)문자 셋과는 다른 것이다. 두 가지 타입의 스트링 모두에 대해서는, 스트링 유닛의 숫자 값 기반으
로 비교가 이루어 지지만, 비-바이너리 스트링의 경우에는 유닛이 문자이며 어떤 문자 셋은 다중 바이트 문자를 허용하기도 한다.
Section 11.4.2, “BINARY 와 VARBINARY 타입”을 참조할 것.
CHAR, VARCHAR, 또는 TEXT 컬럼 정의에서 CHARACTER SET binary를 사용하면 컬럼이 바이너리 데이터 타입으로 취급
된다. 예를 들면, 아래의 정의문은 두 개가 동일한 것이다:
CHAR(10) CHARACTER SET binary
BINARY(10)
VARCHAR(10) CHARACTER SET binary
VARBINARY(10)
TEXT CHARACTER SET binary
BLOB

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.5.4. 콜레션 결정이 애매 모호한 특별 사례들
10.5. 콜레션 이슈 대부분의 명령문에서는, MySQL이 비교 연산을 하기 위해서 어떤 콜레션을 사용하는지는 명확하게 나타난다. 예를 들면, 아래와
10.5.4 콜레션 결정이 애매 모호한 특별 사례들 같은 경우, 사용되는 콜레션이 컬럼x에 대한 콜레션이라는 것이 분명히 나타난다:
SELECT x FROM T ORDER BY x;
SELECT x FROM T WHERE x = x;
SELECT DISTINCT x FROM T;
하지만, 여러 개의 피 연산자가 포함되어 있는 경우에는 다소 애매 모호해지는 경우도 있다. 예를 들면:
SELECT x FROM T WHERE x = 'Y';
이 쿼리는 컬럼x의 콜레션을 사용해야 하는가? 아니면, 스트링 리터럴 'Y'의 것을 사용해야 하는가?
표준 SQL은 이와 같은 질문을 소위 “강제성(coercibility)” 규칙이라고 불리는 방법을 사용해서 해결한다. 기본적으로는 다음

과 같은 의미를 갖는다: x 와 'Y'는 둘 다 콜레션을 가지고 있고, 따라서 어떤 콜레션이 우선 순위가 높은가? 이 문제는 해결하기가
어렵지만, 아래의 규칙은 대부분의 경우에 이 문제를 해결해 준다:
● 명확한 COLLATE 구문은 0의 강제성을 갖는다. (전혀 강제적이지 않음.)

● 서로 다른 콜레션을 사용해서 두 개의 스트링을 연결(concatenation)하면 1의 강제성을 갖는다.
● 컬럼의 콜레션 또는 스토어드 루틴 파라미터 또는 로컬 변수는 2의 강제성을 갖는다.
● “시스템 상수(system constant)” (USER() 또는 VERSION()와 같은 함수가 리턴하는 스트링) 는 3의 강제성을 갖는
다.

:::MySQL Korea:::
● 리터럴의 콜레션은 4의 강제성을 갖는다.

● NULL 또는 NULL에서 나오는 수식은 강제성 5를 갖는다.
강제성 값에 우선 순위를 매기는 것은 MySQL 5.0.3에 추가 되었다. 5.0.3이전 버전에서는, 시스템 상수 또는 무시할 만한 강제성
이 존재하지 않는다. Functions such as USER()와 같은 함수는 3이 아닌 2의 강제성을 가지며, 리터럴은 4가 아닌 3의 강제성을
갖는다.
이러한 규칙은 아래와 같은 형태의 모호함을 해결한다:
● 가장 낮은 강제성 값과 함께 콜레션 사용하기.

● 만일 양쪽이 동일한 강제성을 갖고 있다면, 콜레션이 동일하지 않는 경우에는 에러가 발생한다.
예문:
column1 = 'A' Use collation of column1
column1 = 'A' COLLATE x Use collation of 'A'
column1 COLLATE x = 'A' COLLATE y Error
COERCIBILITY() 함수는 스트링 수식의 강제성을 결정하기 위해서 사용될 수 있다:
mysql> SELECT COERCIBILITY('A' COLLATE latin1_swedish_ci);
-> 0
mysql> SELECT COERCIBILITY(VERSION());
-> 3
mysql> SELECT COERCIBILITY('A');

:::MySQL Korea:::
-> 4
Section 12.9.3, “정보 함수”를 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.5.5. 콜레션은 반드시 올바른 문자 셋용 이어야 한다
10.5. 콜레션 이슈 각각의 문자 셋은 하나 또는 그 이상의 콜레션을 가지고 있지만, 각각의 콜레션은 오직 하나의 문자 셋에만 연관이 된다. 따라서, 아
10.5.5 콜레션은 반드시 올바른 문자 셋용 이어야 래의 명령문은 에러를 발생 시키는데, 그 이유는 latin2_bin 콜레션이 latin1 문자 셋과는 유효하지 않기 때문이다:
한다
mysql> SELECT _latin1 'x' COLLATE latin2_bin;
ERROR 1253 (42000): COLLATION 'latin2_bin' is not valid
for CHARACTER SET 'latin1'
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.5.6. 콜레션 효과의 사례
10.5. 콜레션 이슈 테이블 T에 있는 컬럼 X 가 아래와 같은 latin1 컬럼 값을 가지고 있다고 가정하자:

Muffler
Müller
MX Systems
MySQL
또한, 아래의 명령문을 사용해서 이 컬럼 값을 추출한다고 가정한다:
SELECT X FROM T ORDER BY X COLLATE collation_name;
아래의 테이블은 우리가 서로 다른 콜레션을 사용해서 ORDER BY를 실행할 경우에 얻을 수 있는 결과 값의 순서를 나타내는 것이
다:
latin1_swedish_ci latin1_german1_ci latin1_german2_ci
Muffler Muffler Müller
MX Systems Müller Muffler
Müller MX Systems MX Systems
MySQL MySQL MySQL

:::MySQL Korea:::
이 예문에서 서로 다른 정렬 순서를 야기 시키는 특성은 점이 두 개 찍힌 문자 U 인데, 이것은 독일어로 “U-umlaut”라고 불린

다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.6. 문자 셋 지원으로 영향을 받는 연산
10. 문자 셋 지원 10.6.1. 결과 스트링

10.6. 문자 셋 지원으로 영향을 받는 연산 10.6.2. CONVERT() 와 CAST()
10.6 문자 셋 지원으로 영향을 받는 연산 10.6.3. SHOW 명령문과 INFORMATION_SCHEMA
10.6.1 결과 스트링
이번 섹션에서는 문자 셋 정보를 사용자 계정으로 가져가는 연산에 대해서 설명을 하기로 하겠
10.6.2 CONVERT() 및 CAST()
다.
10.6.3 SHOW 명령문 및 INFORMATION_SCHEMA
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.6.1. 결과 스트링
10.6. 문자 셋 지원으로 영향을 받는 연산 MySQL에는 스트링을 리턴하는 연산자와 함수가 많이 있다. 이번 섹션에서는 다음과 같은 질문에 대해서 설명을 하기로 한다: 그
10.6.1 결과 스트링 와 같은 스트링에 대한 문자 셋과 콜레션은 어떤 것이 있는가?
스트링을 입력 받아서 스트링을 결과로 리턴하는 단순 함수의 경우, 결과의 문자 셋과 콜레션은 원래의 입력 값의 문자 셋과 콜레션
을 갖게 된다. 예를 들면, UPPER(X)는 X의 문자 스트링 및 콜레션과 동일한 형태의 스트링을 리턴한다. INSTR(), LCASE(),
LOWER(), LTRIM(), MID(), REPEAT(), REPLACE(), REVERSE(), RIGHT(), RPAD(), RTRIM(), SOUNDEX(),
SUBSTRING(), TRIM(), UCASE(), UPPER()에 대해서도 동일하다.
Note: REPLACE() 함수는, 다른 모든 함수와는 달리, 항상 스트링 입력 값의 콜레션을 무시하고 대소 문자를 구분하는 비교 연산
을 실행한다.
만일 스트링 입력 값 또는 함수 결과가 바이너리 스트링일 경우, 이 스트링은 아무런 문자 셋 또는 콜레션을 가지지 않는다. 이것은
CHARSET() 와 COLLATION() 함수로 검사할 수 있는데, 두 함수 모두 자신들의 인수가 바이너리 스트링임을 가리키기 위해
binary를 리턴한다:
mysql> SELECT CHARSET(BINARY 'a'), COLLATION(BINARY 'a');
+---------------------+-----------------------+
| CHARSET(BINARY 'a') | COLLATION(BINARY 'a') |
+---------------------+-----------------------+
| binary | binary |

:::MySQL Korea:::
+---------------------+-----------------------+
여러 개의 스트링 입력 값을 결합해서 하나의 스트링 결과를 리턴하는 연산의 경우에는, 표준 SQL의 “집합 규칙(aggregation
rules)”이 결과 값의 콜레션을 결정하기 위해서 적용된다:
● 만일 명확하게 COLLATE X 가 나타나면, X를 사용한다.

● 만일 명확하게 COLLATE X 와 COLLATE Y 가 나타나면, 에러가 발생된다.
● 이와는 달리, 모든 콜레션이 X라면, X를 사용한다.
● 위의 사항에 아무것도 해당하지 않으면, 결과 값은 콜레션을 가지지 않는다.
예를 들면, CASE ... WHEN a THEN b WHEN b THEN c COLLATE X END를 사용하면, 결과 콜레션은 X가 된다. 이것은
UNION, ||, CONCAT(), ELT(), GREATEST(), IF(), 그리고 LEAST()에도 적용이 된다.
문자 데이터를 변환하는 연산의 경우, 이 연산의 결과로 나오는 스트링의 문자 셋 및 콜레션은 character_set_connection 과
collation_connection 시스템 변수에 의해 정의가 된다. 이것은 CAST(), CHAR(), CONV(), FORMAT(), HEX(), 그리고
SPACE()에도 적용된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.6.2. CONVERT() 및 CAST()
10.6. 문자 셋 지원으로 영향을 받는 연산 CONVERT()는 서로 다른 문자 셋간의 데이터 변환을 한다. 신텍스는 다음과 같다:
10.6.2 CONVERT() 및 CAST()

CONVERT(expr USING transcoding_name)
MySQL에서는, 트랜스코딩(transcoding) 이름은 대응하는 문자 셋의 이름과 같게 된다.
예문:
SELECT CONVERT(_latin1'Müller' USING utf8);
INSERT INTO utf8table (utf8column)
SELECT CONVERT(latin1field USING utf8) FROM latin1table;
CONVERT(... USING ...)은 표준 SQL 사양에 따라서 구현된다.
스트링을 다른 문자 셋으로 변환하기 위한 방법으로 CAST()를 사용할 수도 있는데, 신텍스는 다음과 같다:
CAST(character_string AS character_data_type CHARACTER SET charset_name)
예문:
SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8);
만일 여러분이 CHARACTER SET을 지정하지 않은 채로 CAST()를 사용한다면, 결과로 나오는 문자 셋과 콜레션은

:::MySQL Korea:::
character_set_connection 및 collation_connection 시스템 변수에 의해 정의 된다. 만일 CAST()를 CHARACTER SET X와 함

께 사용한다면, 결과 문자 셋과 콜레션은 각각 X 와 X 의 디폴트 콜레션이 된다.
CAST() 내부에서는 COLLATE 구문을 사용하지 못 하겠지만, 외부에서는 사용이 가능하다. 즉, CAST(... COLLATE ...)는 유효
하지 않지만, CAST(...) COLLATE ... 는 사용 가능하다.
예문:
SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8) COLLATE utf8_bin;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.6.3. SHOW 명령문 및 INFORMATION_SCHEMA
10.6. 문자 셋 지원으로 영향을 받는 연산 몇몇 SHOW 명령문들은 추가적인 문자 셋 정보를 제공하기도 한다.이러한 명령문에는 SHOW CHARACTER SET, SHOW
COLLATION, SHOW CREATE DATABASE, SHOW CREATE TABLE 그리고 SHOW COLUMNS등이 있다. 이 섹션에서는
10.6.3 SHOW 명령문 및
INFORMATION_SCHEMA 이러한 명령문들에 대해서 간략히 설명을 할 것이며, 보다 자세한 정보를 원할 경우에는 Section 13.5.4, “SHOW 신텍스”를 참
조하기 바란다.
INFORMATION_SCHEMA에는 몇 가지 테이블이 있는데, 이것들은 SHOW 명령문이 보여주는 정보와 비슷한 것들을 가지고 있
다. 예를 들면, CHARACTER_SETS 및 COLLATIONS 테이블은 SHOW CHARACTER SET 및 SHOW COLLATION이 보여
주는 정보를 가진다. Chapter 20, “INFORMATION_SCHEMA 데이터 베이스”를 참조할 것.
SHOW CHARACTER SET 명령어는 모든 사용한 문자 셋을 보여준다. 이 명령어는 옵션으로 LIKE 구문을 가져오며, 이 구문은
매치하기 위한 문자 셋의 이름을 가리킨다. 예를 들면:
mysql> SHOW CHARACTER SET LIKE 'latin%';
+---------+-----------------------------+-------------------+--------+
+---------+-----------------------------+-------------------+--------+

:::MySQL Korea:::
| latin7 | ISO 8859-13 Baltic | latin7_general_ci | 1|
+---------+-----------------------------+-------------------+--------+
SHOW COLLATION는 사용 가능한 모든 콜레션을 리턴한다. 이 명령어는 옵션으로 LIKE 구문을 가져오며, 이 구문은 매치하기
위한 콜레션 이름을 가리킨다. 예를 들면:
+-------------------+---------+----+---------+----------+---------+
| Collation | Charset | Id | Default | Compiled | Sortlen |
+-------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1 | 5 | | | 0|
| latin1_swedish_ci | latin1 | 8 | Yes | Yes | 0|
| latin1_bin | latin1 | 47 | | Yes | 0|
| latin1_general_ci | latin1 | 48 | | | 0|

:::MySQL Korea:::
| latin1_spanish_ci | latin1 | 94 | | | 0|
+-------------------+---------+----+---------+----------+---------+
SHOW CREATE DATABASE는 주어진 데이터 베이스를 생성하는 CREATE DATABASE 명령문을 출력한다:
mysql> SHOW CREATE DATABASE test;
+----------
+-----------------------------------------------------------------+
| Database | Create Database |
+----------
+-----------------------------------------------------------------+
| test | CREATE DATABASE `test` /*!40100 DEFAULT CHARACTER SET latin1 */ |
+----------
+-----------------------------------------------------------------+
만일 아무런 COLLATE 구문도 주어지지 않는다면, 그 문자 셋에 대한 디폴트 콜레션이 사용된다.
SHOW CREATE TABLE도 유사한 결과를 보여 주지만, 주어진 테이블을 생성하기 위한 CREATE TABLE 명령문을 출력한다.
컬럼 정의문은 모든 문자 셋 상세 사양을 가리키며, 테이블 옵션은 문자 셋의 정보를 가지게 된다.
SHOW COLUMNS 명령문은 SHOW FULL COLUMNS형태로 호출을 했을 때 테이블 컬럼의 콜레션을 출력한다. CHAR,
VARCHAR, 또는 TEXT 데이터 타입을 가진 컬럼은 콜레션을 가진다. 숫자(Numeric) 및 다른 비-문자(non-character)타입은
콜레션을 갖지 않는다. 예를 들면:

:::MySQL Korea:::
mysql> SHOW FULL COLUMNS FROM person￦G
*************************** 1. row ***************************
Field: id
Type: smallint(5) unsigned
Collation: NULL
Null: NO
Key: PRI
Default: NULL
Extra: auto_increment
Privileges: select,insert,update,references
Comment:
*************************** 2. row ***************************
Field: name
Type: char(60)
Collation: latin1_swedish_ci
Null: NO

:::MySQL Korea:::
Key:
Default:
Extra:
Privileges: select,insert,update,references
Comment:
문자 셋은 출력되지 않지만 콜레션 이름을 가지고 유추할 수가 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.7. 유니 코드 지원
10. 문자 셋 지원 MySQL 5.0은 유니 코드 데이터를 저장하기 위해서 두 가지의 문자 셋을 지원하고 있다:

10.7. 유니 코드 지원
10.7 유니 코드 지원 ● ucs2, UCS-2 유니 코드 문자 셋.

● utf8, 유니 코드 문자 셋에 대한 UTF-8 엔코딩(encoding).
UCS-2 (binary Unicode representation)의 경우, 모든 문자는 가장 의미가 있는 바이트를 앞에 사용하여 2-바이트 유니 코드
로 표현된다. 예를 들면: LATIN CAPITAL LETTER A는 코드 0x0041를 가지며, 이것은 2-바이트 시퀀스 형태로 저장된다:
0x00 0x41. CYRILLIC SMALL LETTER YERU (유니 코드 0x044B)는 2-바이트 시퀀스 형태로 저장된다: 0x04 0x4B. 유
니 코드 문자 및 이것의 코드에 대해서는 Unicode Home Page를 참조하기 바란다.
현재까지는, UCS-2를 클라이언트 문자 셋 형태로 사용할 수 없으며, 따라서 SET NAMES 'ucs2' 는 구동을 하지 않는다.
UTF-8 문자 셋은 유니 코드 데이터를 저장하기 위한 또 다른 방식이다. 이것은 RFC 3629에 따라서 구현이 된다. The idea of
the UTF-8 문자 셋에 대한 아이디어는 바로 다양한 유니 코드 문자들은 서로 다른 길이의 바이트 시퀀스를 사용해서 엔코딩 된다
는 것이다:
● 기본적인 라틴 문자, 숫자, 그리고 구두점(punctuation) 기호는 1 바이트를 사용한다.

● 대부분의 유럽 및 중동 스크립트 문자는 2-바이트 시퀀스를 사용한다: 라틴 문자의 확장형 (틸드(tilde), 마크론
(macron), 어큐트(acute), 그레이브(grave) 그리고 기타 액센트를 사용하는 문자), Cyrillic, Greek, Armenian,
Hebrew, Arabic, Syriac, 등등.
● 한국어, 중국어, 그리고 일본어 표의 문자는 3-바이트 시퀀스를 사용한다.
RFC 3629는 1~4바이트를 갖는 엔코딩 시퀀스를 설명한다. 현재까지는, UTF-8을 지원하는 MySQL에는 4바이트 시퀀스가 포
함되지 않고 있다.
Tip: UTF-8를 사용하는 스페이스를 저장하기 위해서는, VARCHAR를 CHAR 대신에 사용한다. 그렇지 않으면, MySQL CHAR

:::MySQL Korea:::
CHARACTER SET utf8 컬럼 안에 있는 각각의 문자에 대해서 MySQL은 3 바이트를 지정(reserve)하는데, 그 이유는 이것이
최대 가능 길이 이기 때문이다. 예를 들면, MySQL 은 CHAR(10) CHARACTER SET utf8 컬럼에 대해서는 30 바이트를 반드
시 지정(reserve)해야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.8. 메타 데이터를 위한 UTF-8
10. 문자 셋 지원 메타 데이터란 “데이터에 대한 데이터”를 의미한다. 데이터 베이스를 설명하는 모든 것-데이터 베이스의 컨텐츠에 해당하는 것
10.8. 메타 데이터를 위한 UTF-8 과는 반대로-이 메타 데이터이다. 따라서 컬럼 이름, 데이터 베이스 이름, 사용자 이름, 그리고 SHOW의 결과로 나오는 대부분의
10.8 메타 데이터를 위한 UTF-8 스트링은 메타 데이터이다. INFORMATION_SCHEMA의 테이블 컨텐츠에 대해서도 적용이 되는데, 그 이유는 이렇게 정의된 테
이블은 데이터 베이스 오브젝트에 대한 정보를 가지기 때문이다.
메타 데이터에 대한 표현은 반드시 아래의 요구 사항을 충족해야 한다:
● 모든 메타 데이터는 동일한 문자 셋을 가져야 한다. 그렇지 않을 경우, INFORMATION_SCHEMA 안에 있는 테이블에 대

한 SHOW 명령어 또는 SELECT 명령문은 둘 다 올바르게 동작을 하지 않는데, 그 이유는 이러한 명령문을 처리하면 한 컬
럼에 있는 열들이 서로 다른 문자 셋을 가지기 때문이다.
● 메타 데이터는 반드시 모든 언어에 있는 모든 단어를 포함해야 한다. 그렇지 않으면, 사용자는 자신의 언어를 사용해서 컬
럼 및 테이블의 이름을 지정할 수 없게 된다.
위의 두 가지 요구 사항을 만족시키기 위해서, MySQL은 메타 데이터를 UTF-8이라는 이름의 유니 코드 문자 셋에 저장한다. 여

러분이 액센트 또는 라틴 문자가 아닌 문자를 결코 사용하지 않는다면 아무런 문제를 일으키지 않는다.
메타 데이터 요구 사항이 의미하는 것은 USER(), CURRENT_USER(), SESSION_USER(), SYSTEM_USER(), DATABASE

(), 그리고 VERSION() 함수의 리턴 값이 디폴트로 UTF-8 문자를 갖는다는 것을 나타내는 것이다.
서버는 character_set_system 시스템 변수를 메타 데이터 문자 셋의 이름으로 설정한다:
mysql> SHOW VARIABLES LIKE 'character_set_system';

+----------------------+-------+
+----------------------+-------+

:::MySQL Korea:::
| character_set_system | utf8 |
+----------------------+-------+
유니 코드를 사용하는 메타 데이터의 스토리지는 서버가 디폴트로 character_set_system 문자 셋에 있는 DESCRIBE 함수의 결

과 값과 컬럼의 헤더를 리턴한다는 것을 의미하는 것은 아니다. 여러분이 SELECT column1 FROM t를 사용하게 되면, column1
의 이름 자체는 character_set_results 시스템 변수의 값에 의해 결정되는 문자 셋에 있는 클라이언트에 리턴되는데, 이것은 디폴
트로 latin1를 갖고 있다. 만일 서버로 하여금 메타 데이터 결과를 다른 문자 셋으로 다시 돌려 주도록 하고자 한다면 , SET
NAMES 명령문을 사용해서 서버가 문자 셋 변환을 강제로 진행하도록 만들어 준다. SET NAMES 은 character_set_results 및
기타 연관된 시스템 변수를 설정한다. (Section 10.4, “문자 셋과 콜레션 연결”.) 다른 방법으로는, 서버에서 결과를 받은 후에
변환 작업을 하는 클라이언트 프로그램도 있다. 클라이언트가 변환 작업을 하는 것이 보다 효과적이기는 하지만, 이 옵션은 모든 클
라이언트에 적용되는 것은 항상 아니다.
만일 character_set_results가 NULL로 설정되어 있다면, 아무런 변환도 실행되지 않으며 서버는 자신의 원래의 문자 셋을 사용해
서 메타 데이터를 리턴한다 (character_set_system가 지정하는 문자 셋).
서버에서 클라이언트로 전달되는 에러 메시지는 메타 데이터와 함께 자동으로 클라이언트의 문자 셋으로 변환된다.
만일 여러분이 비교 연산 또는 단일 명령문 안에 있는 할당을 위해서 USER() 함수를 사용한다면, 걱정을 하지 않아도 된다.
MySQL은 이러한 것들을 자동으로 진행한다.
SELECT * FROM Table1 WHERE USER() = latin1_column;
이것은 제대로 동작을 하는데, 그 이유는 latin1_column의 컨텐츠가 비교 연산이 실행되기 전에 자동으로 UTF-8로 변환되기 때
문이다.
INSERT INTO Table1 (latin1_column) SELECT USER();
이것은 제대로 동작을 하는데, 그 이유는 USER()의 컨텐츠가 할당이 이루어지지 전에 자동으로 latin1 로 변환되기 때문이다. 자
동 변환은 아직까지는 완벽하게 구현되지는 않았지만, 다음 버전에서는 정확히 구현될 예정이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.9. MySQL이 지원하는 문자 셋과 콜레션
10. 문자 셋 지원 10.9.1. 유니 코드 문자 셋
10.9. MySQL이 지원하는 문자 셋과 콜레션 10.9.2. West European Character Sets - Skip
10.9 MySQL이 지원하는 문자 셋과 콜레션 10.9.3. Central European Character Sets - Skip
10.9.1 유니 코드 문자 셋 10.9.4. South European and Middle East Character Sets - Skip
10.9.7 아시아 문자 셋 10.9.5. Baltic Character Sets -Skip

10.9.6. Cyrillic Character Sets – Skip
10.9.7. 아시아 문제 셋
MySQL은 30+ 문자 셋에 대해서 70+ 콜레션을 지원한다. 이번 섹션에서는 MySQL이 지원하는 문자 셋에 대해서 설명을 하기로
한다. 관련된 문자 셋의 각 그룹에는 하나씩 서브 섹션이 존재 한다. 각 문자 셋의 경우, 사용 가능한 콜레션이 리스트로 제공된다.
SHOW CHARACTER SET 명령문을 사용하면 사용 가능한 문자 셋과 이에 대한 콜레션을 볼 수가 있다:

+----------+-----------------------------+---------------------+
| Charset | Description | Default collation |
+----------+-----------------------------+---------------------+
| big5 | Big5 Traditional Chinese | big5_chinese_ci |
| dec8 | DEC West European | dec8_swedish_ci |
| cp850 | DOS West European | cp850_general_ci |
| hp8 | HP West European | hp8_english_ci |
| koi8r | KOI8-R Relcom Russian | koi8r_general_ci |
| latin1 | cp1252 West European | latin1_swedish_ci |
| latin2 | ISO 8859-2 Central European | latin2_general_ci |

:::MySQL Korea:::
| swe7 | 7bit Swedish | swe7_swedish_ci |

| ascii | US ASCII | ascii_general_ci |
| ujis | EUC-JP Japanese | ujis_japanese_ci |
| sjis | Shift-JIS Japanese | sjis_japanese_ci |
| hebrew | ISO 8859-8 Hebrew | hebrew_general_ci |
| tis620 | TIS620 Thai | tis620_thai_ci |
| euckr | EUC-KR Korean | euckr_korean_ci |
| koi8u | KOI8-U Ukrainian | koi8u_general_ci |
| gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci |
| greek | ISO 8859-7 Greek | greek_general_ci |
| cp1250 | Windows Central European | cp1250_general_ci |
| gbk | GBK Simplified Chinese | gbk_chinese_ci |
| latin5 | ISO 8859-9 Turkish | latin5_turkish_ci |
| armscii8 | ARMSCII-8 Armenian | armscii8_general_ci |
| utf8 | UTF-8 Unicode | utf8_general_ci |
| ucs2 | UCS-2 Unicode | ucs2_general_ci |
| cp866 | DOS Russian | cp866_general_ci |
| keybcs2 | DOS Kamenicky Czech-Slovak | keybcs2_general_ci |
| macce | Mac Central European | macce_general_ci |
| macroman | Mac West European | macroman_general_ci |
| cp852 | DOS Central European | cp852_general_ci |
| latin7 | ISO 8859-13 Baltic | latin7_general_ci |
| cp1251 | Windows Cyrillic | cp1251_general_ci |
| cp1256 | Windows Arabic | cp1256_general_ci |
| cp1257 | Windows Baltic | cp1257_general_ci |
| binary | Binary pseudo charset | binary |
| geostd8 | GEOSTD8 Georgian | geostd8_general_ci |
| cp932 | SJIS for Windows Japanese | cp932_japanese_ci |
| eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci |
+----------+-----------------------------+---------------------+

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.9.1. 유니 코드 문자 셋
10.9. MySQL이 지원하는 문자 셋과 콜레션 MySQL은 두 개의 유니 코드 문자 셋을 가지고 있다. 여러분은 이 문자 셋을 사용해서 약 650개의 언어로 된 텍스트를 저장할 수
10.9.1 유니 코드 문자 셋 가 있다.
● ucs2 (UCS-2 유니 코드) 콜레션:

❍ ucs2_bin
❍ ucs2_czech_ci
❍ ucs2_danish_ci
❍ ucs2_esperanto_ci
❍ ucs2_estonian_ci
❍ ucs2_general_ci (디폴트)
❍ ucs2_hungarian_ci
❍ ucs2_icelandic_ci
❍ ucs2_latvian_ci
❍ ucs2_lithuanian_ci
❍ ucs2_persian_ci
❍ ucs2_polish_ci
❍ ucs2_roman_ci
❍ ucs2_romanian_ci
❍ ucs2_slovak_ci
❍ ucs2_slovenian_ci
❍ ucs2_spanish2_ci
❍ ucs2_spanish_ci
❍ ucs2_swedish_ci

:::MySQL Korea:::
❍ ucs2_turkish_ci
❍ ucs2_unicode_ci
● utf8 (UTF-8 유니코드) 콜레션:
❍ utf8_bin
❍ utf8_czech_ci
❍ utf8_danish_ci
❍ utf8_esperanto_ci
❍ utf8_estonian_ci
❍ utf8_general_ci (디폴트)
❍ utf8_hungarian_ci
❍ utf8_icelandic_ci
❍ utf8_latvian_ci
❍ utf8_lithuanian_ci
❍ utf8_persian_ci
❍ utf8_polish_ci
❍ utf8_roman_ci
❍ utf8_romanian_ci
❍ utf8_slovak_ci
❍ utf8_slovenian_ci
❍ utf8_spanish2_ci
❍ utf8_spanish_ci
❍ utf8_swedish_ci
❍ utf8_turkish_ci
❍ utf8_unicode_ci
ucs2_esperanto_ci 및utf8_esperanto_ci 콜레션은 MySQL 5.0.13에서 추가 되었고, ucs2_hungarian_ci 및 utf8_hungarian_ci

콜레션은 MySQL 5.0.19에서 추가 되었다.
MySQL은 http://www.unicode.org/reports/tr10/에서 설명되어 있는 유니코드 콜레션 알고리즘(UCA)에 의해서

:::MySQL Korea:::
utf8_unicode_ci 콜레션을 구현한다. 이 콜레션은 버전-4.0.0 UCA 웨이트 키(weight keys)를 사용하고 있다: http://www.
unicode.org/Public/UCA/4.0.0/allkeys-4.0.0.txt. 아래의 섹션은 utf8_unicode_ci의 사용에 대해서 설명을 하고 있지만,
ucs2_unicode_ci에 대해서도 적용이 된다.
현재의 버전까지는, utf8_unicode_ci 콜레션은 아직까지는 UCA를 부분적으로만 지원하며, 몇몇 문자들은 아직까지 지원되지 않
고 있다. 또한, 결합 마크(combining marks)는 전체적으로 지원되지 않는다.
utf8_unicode_ci의 가장 중요한 특징은 이것이 확장자(expantion)을 지원한다는 것이다; 즉, 하나의 문자가 여러 문자의 조합과
동일하게 비교가 될 때. 예를 들면, 독일어와 몇몇 다른 언어에서는 ‘ß’는 ‘ss’과 동일한 것이다.
utf8_general_ci는 확장자를 지원하지 않는 레가시 콜레션(legacy collation)이다. 이것은 문자간에 일대일 비교만을 실행한다. 이
것이 It can make only one-to-one comparisons between characters. This means that comparisons for the
utf8_general_ci 콜레션에 대한 비교가 보다 빠르다는 것을 의미하지만, 정확도는 utf8_unicode_ci 보다 다소 떨어진다.
예를 들면, 아래의 등식은 utf8_general_ci 및 utf8_unicode_ci에서 모두 적용된다.
Ä=A
Ö=O
Ü=U
위의 콜레션간의 차이점은 아래의 것은 utf8_general_ci에 대해서도 적용된다는 것이다:
ß=s

:::MySQL Korea:::
반면에 아래의 것은 utf8_unicode_ci에 적용된다:
ß = ss
MySQL은 utf8_unicode_ci를 사용하는 순서화(ordering)이 어떤 언어에 대해서 올바르게 동작하지 않는 경우에만 utf8 문자 셋
에 대한 언어-관련 콜레션을 구현한다. 예를 들면, utf8_unicode_ci는 독일어 및 프랑스어에 대해서는 잘 동작을 하기 때문에, 이
두 언어에 대해서는 특별한 utf8 콜레션을 생성할 필요가 없게 된다.
-- 이하는 독일어, 프랑스어, 스웨덴어, 스페인어에 해당하는 내용이므로 생략 함

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 10.9.7. 아시아 문자 셋
10. 문자 셋 지원 10.9.7.1. cp932 문자 셋 - Skip

10.9. MySQL이 지원하는 문자 셋과 콜레션
10.9.7 아시아 문자 셋
아시아 문자 셋에는 중국어, 일본어, 한국어, 그리고 태국어 지원이 포함되어 있
다.
● big5 (Big5 전통적인 중국어) 콜레션:

❍ big5_bin
❍ big5_chinese_ci (디폴트)
● cp932 (SJIS 윈도우용 일본어) 콜레션:
❍ cp932_bin
❍ cp932_japanese_ci (디폴트)
● eucjpms (UJIS 윈도우용 일본어) 콜레션:
❍ eucjpms_bin
❍ eucjpms_japanese_ci (디폴트)
● euckr (EUC-KR 한국어) 콜레션:
❍ euckr_bin
❍ euckr_korean_ci (디폴트)
● gb2312 (GB2312 간자 중국어) 콜레션:
❍ gb2312_bin
❍ gb2312_chinese_ci (디폴트)
● gbk (GBK 간자 중국어) 콜레션:
❍ gbk_bin
❍ gbk_chinese_ci (디폴트)

:::MySQL Korea:::
● sjis (Shift-JIS Japanese) 콜레션:

❍ sjis_bin
❍ sjis_japanese_ci (디폴트)
● tis620 (TIS620 Thai) 콜레션:
❍ tis620_bin
❍ tis620_thai_ci (디폴트)
● ujis (EUC-JP Japanese) 콜레션:
❍ ujis_bin
❍ ujis_japanese_ci (디폴트)

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 11. 데이터 타입
11. 데이터 타입 11.1. 데이터 타입 개요
11 데이터 타입 11.1.1. 숫자 타입 개요
11.1 데이터 타입 개요 11.1.2. 날짜 및 시간 타입 개요
11.1.1 숫자 타입 개요 11.1.3. 스트링 타입 개요

11.1.4. 데이터 타입 디폴트 값
11.1.2 날짜 및 시간 타입 개요
11.2. 숫자 타입
11.1.3 스트링 타입 개요
11.3. 날짜 및 시간 타입
11.1.4 데이터 타입 디폴트 값
11.3.1. DATETIME, DATE, 그리고 TIMESTAMP 타입
11.2 숫자 타입
11.3.2. TIME 타입
11.3 날짜 및 시간 타입
11.3.3. YEAR 타입
11.3.1 DATETIME, DATE, 그리고 TIMESTAMP 타입
11.3.4. Y2K 이슈 및 날짜 타입
11.3.1.1 MySQL 4.1 버전까지의 TIMESTAMP 특성
11.4. 스트링 타입
11.3.2 TIME 타입 11.4.1. CHAR 및 VARCHAR 타입
11.3.3 YEAR 타입 11.4.2. BINARY 및 VARBINARY 타입
11.4 스트링 타입 11.4.3. BLOB 및 TEXT 타입
11.4.1 CHAR 및 VARCHAR 타입 11.4.4. ENUM 타입
11.4.2 BINARY 및 VARBINARY 타입 11.4.5. SET 타입
11.4.3 BLOB 및 TEXT 타입 11.5. 데이터 타입 스토리지 요구 사항
11.4.4 ENUM 타입 11.6. 컬럼용으로 올바른 타입 선택하기
11.4.5 SET 타입 11.7. 다른 데이터 베이스 엔진의 데이터 타입 사용하기
11.5 데이터 타입 스토리지 요구 사항

MySQL는 여러 가지의 카타고리로 데이터 타입을 지원한다: 숫자 타입, 날짜 및 시간 타입, 그리고 스트링 (문자) 타입. 이
11.6 컬럼에 대한 올바른 타입 선택하기
장에서는 우선 이러한 데이터 타입의 개요를 설명한 다음에 각각의 카타고리에 속한 타입들의 속성에 대한 보다 자세한 설
11.7 다른 데이터 베이스 엔진의 데이터 타입 사용하기
명을 한 다음에 데이터 타입 스토리지 요구 사항에 대해서 설명을 하기로 하겠다.

:::MySQL Korea:::
MySQL은 스파샬(spatial) 데이터를 처리하기 위한 확장도 지원을 한다. Chapter 16, Spatial Extensions을 참조하여 스
파샬 데이터에 대해서 보다 자세한 정보를 얻기 바란다.
몇몇 데이터 타입에 대한 설명에서는 아래와 같은 변환을 사용할 것이다:
● M은 정수 타입의 최대 출력(display) 폭을 나타낸다. 부동 소수점 및 고정 소수점 타입의 경우, M은 전체 자리 수

를 가리킨다. 스트링 타입의 경우, M은 최대 길이를 나타낸다. M의 최대 사용 가능 값은 데이터 타입에 따라 다르
다.
● D는 부동 소수점과 고정 소수점 타입에 적용되며, 소수점 뒷자리의 수를 나타낸다. 최대 가능 값은 30이지만, M–
2 이상 될 수는 없다.
● 스퀘어 괄호(Square brackets) (‘[’ and ‘]’)은 타입 정의의 옵션 파트를 나타낸다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.1. 데이터 타입 개요
11. 데이터 타입 11.1.1. 숫자 타입 개요

11.1. 데이터 타입 개요 11.1.2. 날짜 및 시간 타입 개
11.1 데이터 타입 개요 요
11.1.1 숫자 타입 개요 11.1.3. 스트링 타입 개요
11.1.2 날짜 및 시간 타입 개요 11.1.4. 데이터 타입 디폴트
11.1.3 스트링 타입 개요 값
11.1.4 데이터 타입 디폴트 값
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.1.1. 숫자 타입 개요
11. 데이터 타입
11.1. 데이터 타입 개요 이 섹션에서는 숫자 데이터 타입에 대해서 간략히 설명을 할 예정이며, 보다 자세한 정보를 얻고자 한다면 Section 11.2, “숫자 타
11.1.1 숫자 타입 개요 입”을 참조하기 바란다. 스토리지 요구 사항에 대해서는 Section 11.5, “데이터 타입 스토리지 요구 사항”을 참조하기 바란다.
M은 출력할 수 있는 최대 폭을 나타낸다. 최대 유효 출력 폭은 255이다. 출력 폭은 스토리지의 크기 또는 하나의 타입이 가질 수 있

는 값의 범위와는 관련이 없다.
만일 여러분이 숫자 컬럼에 대해서 ZEROFILL을 지정하면, MySQL은 자동으로 UNSIGNED 속성을 컬럼에 추가한다.
SERIAL은 BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE의 별칭이다.
정수 컬럼의 정의에서의 SERIAL DEFAULT VALU는 NOT NULL AUTO_INCREMENT UNIQUE의 별칭이다.
Warning: 정수간의 뺄샘을 할 때 이들 정수 중의 하나가 UNSIGNED으로 되어 있는 경우에는, 결과 값은

NO_UNSIGNED_SUBTRACTION SQL 모드가 활성화 되어 있지 않는 한 부호가 표시되지 않게 된다. Section 12.8, “Cast
Functions and Operators”을 참조.
● BIT[(M)]
비트-필드 타입. M은 값 당 비트 수를 나타내며, 1에서 64 사이의 값을 갖는다. M이 생략되면 디폴트는 1이 된다.

이 데이터 타입은 MyISAM에 대해서는 5.0.3에서 추가 되었고, MEMORY, InnoDB, 그리고 BDB에 대한 확장으로 5.0.5

:::MySQL Korea:::
에서 추가 되었다. 5.0.3 이전에는, BIT는 TINYINT(1)와 동의어 이다.
● TINYINT[(M)] [UNSIGNED] [ZEROFILL]
매우 작은 정수. 부호 범위는 -128에서 127까지 이다. 부호가 없다면 범위는 0에서 255까지 이다.
● BOOL, BOOLEAN
이 타입들은 TINYINT(1)과 동의어 이다. 0의 값은 거짓(false)로 간주 된다. 0이 아닌 값은 진실(true)로 처리된다.

나중에 출시될 버전에서는, 전체 불리안 타입에 대해서는 표준 SQL을 준수해서 처리되도록 할 예정이다.
● SMALLINT[(M)] [UNSIGNED] [ZEROFILL]
작은 정수. 부호가 있는 범위는 -32768에서 32767까지 이다. 부호가 없다면 0 에서 65535까지 임.
● MEDIUMINT[(M)] [UNSIGNED] [ZEROFILL]
중간 크기의 정수. 부호가 있으면 -8388608 에서 8388607까지 이고, 부호가 없다면 0 에서 16777215까지 임.
● INT[(M)] [UNSIGNED] [ZEROFILL]
일반적인 크기의 정수. 부호 범위는 -2147483648 에서 2147483647까지 이고, 없으면 0 에서 4294967295까지 임.
● INTEGER[(M)] [UNSIGNED] [ZEROFILL]
이 타입은 INT과 동의어 임.
● BIGINT[(M)] [UNSIGNED] [ZEROFILL]
큰 크기의 정수. 부호 범위는 -9223372036854775808에서 9223372036854775807까지 이고, 없으면 0 에서

18446744073709551615까지 임.
BIGINT 컬럼에 관련해서는 몇 가지를 유의해야 한다:

:::MySQL Korea:::
❍ 모든 계산(arithmetic)은 부호화 된 BIGINT 또는 DOUBLE 값을 사용해서 해야 하며, 따라서 비트 함수를 사용

할 때를 제외하고는 9223372036854775807 (63 bits) 보다 큰 부호가 없는 정수를 사용할 수는 없다! 만일 이
렇게 하지 않으면, BIGINT 값을 DOUBLE로 변환할 때 절사(rounding) 에러가 나오기 때문에 결과가 틀려질 수
도 있게 된다.
MySQL에서는 아래와 같은 경우에 BIGINT를 사용할 수 있다:
■ 정수를 사용해서 부호가 없는 큰 정수를 BIGINT 컬럼 안에 저장할 때.

■ MIN(col_name) 또는 MAX(col_name)에서, col_name이 BIGINT 컬럼을 참조할 때.
■ 양 쪽의 피 연산자가 모두 정수인 경우에 연산자를 사용할 때(+, -, *, 등등).
❍ 스트링을 사용해서 BIGINT 컬럼 안에 정확한 정수 값을 저장할 수 있다. 이럴 경우, MySQL은 스트링-숫자 변환
을 실행한다.
❍ -, +, 그리고 * 연산자는 양 쪽의 피 연산자가 모두 정수 값일 경우에 BIGINT 연산을 사용한다. 이것은, 만일 여러
분이 두 개의 큰 정수 값을 곱할 경우 (또는 정수를 리턴하는 함수의 결과), 9223372036854775807 보다 큰 결
과가 나올 때 예상치 못한 결과를 가질 수도 있음을 의미한
● FLOAT[(M,D)] [UNSIGNED] [ZEROFILL]
작은(단일 정밀도 - single-precision) 부동 소수점 수. 사용 가능한 값은 -3.402823466E+38 에서 -

1.175494351E-38, 0 이고, 그리고 1.175494351E-38 에서3.402823466E+38 까지다. 이 범위는 이론적인 한계이
고, IEEE 표준에 근거를 하고 있다. 실제로는 여러분이 사용하는 H/W 또는 OS에 근거하여 약간 작게 된다.
M은 전체 자릿 수이고 D는 소수점 뒷자리를 가리킨다. 만일 M 과 D가 생략되면, H/W가 허용하는 범위로 값을 저장한다.
단일 정밀도 부동 소수점 숫자는 대략 7개의 십진 자리수를 갖는다.
UNSIGNED를 지정 하면, 음수 값을 허용하지 않는다.
FLOAT를 사용하면 예상하지 못한 결과가 나올 수도 있는데, 그 이유는 MySQL에서의 모든 계산은 이중 정밀도
(double-precision)로 실행되기 때문이다. Section A.5.7, “Solving Problems with No Matching Rows”를 참조.
● DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL]
일반 크기 (이중 정밀도)의 부동 소수점 숫자. 사용 가능 값은 -1.7976931348623157E+308 에서 -

2.2250738585072014E-308, 0, 그리고 2.2250738585072014E-308 에서 1.7976931348623157E+308 까지
다. 이 범위는 이론적인 한계이고, IEEE 표준에 근거를 하고 있다. 실제로는 여러분이 사용하는 H/W 또는 OS에 근거하

:::MySQL Korea:::
여 약간 작게 된다.
M은 전체 자릿 수이고 D는 소수점 뒷자리를 가리킨다. 만일 M 과 D가 생략되면, H/W가 허용하는 범위로 값을 저장한다.
이중 정밀도 부동 소수점 숫자는 대략 15개의 십진 자리수를 갖는다.
UNSIGNED를 지정 하면, 음수 값을 허용하지 않는다.
● DOUBLE PRECISION[(M,D)] [UNSIGNED] [ZEROFILL], REAL[(M,D)] [UNSIGNED] [ZEROFILL]
이 타입은 DOUBLE과 동의어다. 예외 사항: 만일 REAL_AS_FLOAT SQL 모드를 활성화 하면, REAL은 DOUBLE이 아
니라, FLOAT에 대한 동의어가 된다.
● FLOAT(p) [UNSIGNED] [ZEROFILL]
부동 소수점 숫자. p 는 비트 정밀도를 가리키지만, MySQL은 결과 데이터 타입으로 FLOAT 또는 DOUBLE을 사용할 지
를 결정할 때에만 이 값을 사용한다. 만일 p 가 0 에서 24 사이라면, 데이터 타입은 아무런 M 또는 D 값을 사용하지 않는
FLOAT가 된다. 만일 p 가 25 에서 53 사이의 값이라면, 데이터 타입은 아무런 M 또는 D 값을 사용하지 않는 DOUBLE
이 된다. 결과 컬럼의 범위는 단일 정밀도 FLOAT 또는 이중 정밀도 DOUBLE 데이터 타입에 대한 것과 동일하다.
FLOAT(p) 신텍스는 ODBC와의 호환성을 위해 제공된 것이다.
● DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL]
MySQL 5.0.3 및 이후 버전에만 해당:

묶음(packed) 고정 소수점 숫자. M 은 전체 자릿수를 가리키고 (정밀도) D 는 소수점 뒷자리수를 나타낸다 (Scale). 소
수점 및 음수 부호 ‘-’는 M 에 포함되지 않는다. 만일 D 가 0 이라면, 값은 소수점 또는 분수를 가지지 않는다. The
maximum number of for DECIMAL 에 대한 최대 (M) 자리수는 65 (5.0.3 에서 5.0.5 까지는 64)다. (D)의 최대 지원
숫자는 30 이다. 만일 D 가 생략되면, 디폴트는 0 이다. 만일 M 가 생략되면, 디폴트는 10 이다.
UNSIGNED를 지정하면, 음수 값을 사용할 수 없다.
DECIMAL 컬럼을 사용하는 모든 기본 계산(+, -, *, /)는 65 자리수를 가지고 계산된다.
MySQL 5.0.3 이전:

묶이지 않은(unpacked) 고정 소수점 숫자. CHAR 컬럼처럼 동작 함; “묶이지 않은(unpacked)”의 의미는, 숫자가 각각

:::MySQL Korea:::
의 자리값 별로 하나의 문자를 사용해서 스트링으로 저장되는 것을 의미한다. M 은 전체 자릿수이며 D 는 소수점 이하 자

릿수를 나타낸다. 소수점 및 음수 부호 ‘-’는 M 에 포함되지 않는다. 만일 D 가 0 이면, 소수점을 없는 것이다.
DECIMAL 값의 최대 범위는 DOUBLE과 동일하지만, 주어진 DECIMAL 컬럼의 실제 범위는 M 과 D 에 의해 제한된다.
만일 D 가 생략되면, 디폴트는 0 이 된다. 만일 M 이 생략되면, 디폴트는 10이 된다.
UNSIGNED가 지정되면, 음수 값을 사용할 수 없다.
테이블에 있는 DECIMAL 컬럼에 대한 서버의 동작은 테이블을 생성한 MySQL 버전에 의존한다. 만일 서버가 MySQL
5.0.3 또는 그 이상 버전이기는 하지만, 테이블에 있는 DECIMAL 컬럼이 5.0.3 이전에 생성된 것이라면, 이전 버전의 특
징이 이 컬럼에 적용된다. 테이블을 새로운 버전의 DECIMAL 포멧으로 변환 시키고자 한다면, mysqldump을 사용해서
덤프를 하고 이것을 다시 읽어 온다.
● DEC[(M[,D])] [UNSIGNED] [ZEROFILL], NUMERIC[(M[,D])] [UNSIGNED] [ZEROFILL], FIXED[(M[,D])]

[UNSIGNED] [ZEROFILL]
위의 타입들은 DECIMAL과 동의어다. FIXED 동의어는 다른 데이터 베이스 시스템과의 호환을 위해서 사용하는 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.1.2. 날짜 및 시간 타입 개요
11.1. 데이터 타입 개요 임시 데이터 타입에 대한 개요는 아래와 같다. 보다 자세한 정보는, Section 11.3, “날짜 및 시간 타입”을 참조하기 바란다. 스토
11.1.2 날짜 및 시간 타입 개요 리지에 대한 요구 사항은 Section 11.5, “데이터 타입 스토리지 요구 사항”를 참조하기 바란다.
DATETIME 및 DATE 범위 설명에 있어서, “지원됨(supported)”은 비록 이전의 값들이 제대로 동작을 할 지라도, 현재로는 아
무런 보증도 하지 않음을 의미한다.
SUM() 및 AVG() 집합 함수는 임시 값들과는 동작을 하지 않는다. (이 함수들은 값을 숫자로 변환시키는데, 첫 번째로 나오는 숫
자가 아닌 문자 다음의 부분을 잃게 된다.) 이러한 문제를 해결하기 위해서는,숫자 유닛을 변환 시킨 다음, 집합 연산을 실행하고,
이것을 다시 임시 값으로 변환 시키면 된다. 예를 들면:
SELECT SEC_TO_TIME(SUM(TIME_TO_SEC(time_col))) FROM tbl_name;
SELECT FROM_DAYS(SUM(TO_DAYS(date_col))) FROM tbl_name;
● DATE
날짜. 지원 범위는 '1000-01-01'에서 '9999-12-31'까지 임. MySQL은 DATE 값을 'YYYY-MM-DD' 포맷으로 출

력하지만, 스트링 또는 숫자를 사용해서 DATE 컬럼에 값을 할당할 수 있게 한다.
● DATETIME

:::MySQL Korea:::
날짜와 시간 결합(combination). 지원 범위는 '1000-01-01 00:00:00'에서 '9999-12-31 23:59:59'까지 임.

MySQL은 DATETIME 값을 'YYYY-MM-DD HH:MM:SS' 포맷으로 출력하지만, 스트링 또는 숫자를 사용해서
DATE 컬럼에 값을 할당할 수 있게 한다.
● TIMESTAMP[(M)]
타임 스탬프. 범위는 '1970-01-01 00:00:00' 에서 2037까지 임.

TIMESTAMP 컬럼은 INSERT 또는 UPDATE 연산의 날짜와 시간을 기록하는데 유용하다. 디폴트로는, 별도로 지정하
지 않는 경우에는, 테이블의 처음 TIMESTAMP 컬럼이 자동으로 가장 최근의 연산 날짜와 시간으로 설정된다. 또한, 여
기에 NULL 값을 지정하면 현재의 날짜와 시간을 TIMESTAMP 컬럼에 설정할 수도 있다. 자동 초기화 및 업데이트 특성
에 대한 다양한 변형에 대해서는 Section 11.3.1.1, “TIMESTAMP Properties as of MySQL 4.1”을 참조할 것.
TIMESTAMP 값은 'YYYY-MM-DD HH:MM:SS' 포맷의 스트링 형태로 19 문자 폭의 고정 크기로 출력된다. 숫자 형

태로 값을 얻기 위해서는, 타임 스탬프 컬럼에 +0 을 추가해야 한다.
Note: 4.1 버전 이전에 사용된 TIMESTAMP 포맷은 MySQL 5.0 에서는 지원되지 않는다; 구형 버저에 관한 정보는
MySQL 3.23, 4.0, 4.1 Reference Manual 을 참조하기 바람.
● TIME
시간. 범위는 '-838:59:59' 에서 '838:59:59'까지 임. MySQL은 TIME 값을 'HH:MM:SS' 포맷으로 출력하지만, 스트

링 또는 숫자를 사용해서 TIME 컬럼에 값을 할당할 수도 있다.
● YEAR[(2|4)]
두 자리 또는 네 자리 포맷의 연도. 디폴트는 네 자리 포맷이다. 네 자리 포맷의 경우, 사용가능한 값은

1901 에서 2155까지 이며, 그리고 0000 이 있다. 두 자리 포맷의 경우에는, 사용 가능한 값의 범위가 70
에서 69 까지 이며, 1970 에서 2069 까지를 의미하는 것이다. MySQL은 YEAR 값을 YYYY 포맷으로 표
현하지만, 스트링 또는 숫자를 사용해서 YEAR 컬럼에 값을 할당할 수가 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.1.3. 스트링 타입 개요
11.1. 데이터 타입 개요 스트링 데이터 타입에 대한 개요는 아래와 같다. 보다 자세한 정보는 Section 11.4, “스트링 타입”을 참조하기 바란다. 스토리지
11.1.3 스트링 타입 개요 에 대한 요구 사항은 Section 11.5, “데이터 타입 스토리지 요구 사항”를 참조하기 바란다.
몇몇 경우에는, MySQL은 스트링을 CREATE TABLE 또는 ALTER TABLE 명령문에서 주어지는 타입과 다른 형태로 스트링 컬
럼을 변경 시키기도 한다. Section 13.1.5.1, “Silent Column Specification Changes”을 참조 바람.
MySQL 4.1 및 이후 버전의 경우, 스트링 데이터 타입은 아래와 같이 이전 버전에서는 접해보지 못한 특성을 가지고 있다.:
● 많은 수의 스트링 데이터 타입에 대한 컬럼 정의가 문자 셋을 지정하기 위한 CHARACTER SET 속성을 가지고 있다.
(CHARSET 는 CHARACTER SET과 동의어 임.) COLLATE 속성은 문자 셋에 대한 콜레션을 지정한다. 이러한 속성들
은 CHAR, VARCHAR, TEXT, ENUM, 그리고 SET에 적용된다. 예를 들면:
• CREATE TABLE t
• (
• c1 VARCHAR(20) CHARACTER SET utf8,
• c2 TEXT CHARACTER SET latin1 COLLATE latin1_general_cs

:::MySQL Korea:::
• );
위의 테이블 정의는 utf8 의 문자 셋과 이에 대해 디폴트 콜레션을 갖는 c1 이라는 컬럼과, latin1의 문자 셋과 대소 문자

를 구분하는 콜레션을 갖는 c2 이라는 컬럼을 생성한다.
● MySQL 5.0 은 문자 유닛의 문자 컬럼 정의문에 있는 길이 지정문을 해석한다. (이전 버전은, MySQL 길이를 바이트 단위
로 해석한다.)
● CHAR, VARCHAR, 그리고 TEXT 타입의 경우, BINARY 속성은 컬럼이 컬럼 문자 셋의 바이너리 콜레션에 할당되도록
한다. (이전 버전의 경우, BINARY는 컬럼이 바이너리 스트링을 저장하도록 한다.)
● 문자 컬럼에 대한 정렬 및 비교는 컬럼에 할당된 문자 셋을 기반으로 한다. (이전 버전의 경우, 정렬 및 비교는 서버의 문자
셋 콜레션을 기반으로 하였다.) CHAR 및 VARCHAR 컬럼의 경우, 여러분은 컬럼을 바이너리 콜레션 또는 BINARY 속성
으로 선언해서 정렬 및 비교가 어휘 순서가 아닌 문자 코드 값으로 실행되도록 만들 수가 있다.
● [NATIONAL] CHAR(M) [BINARY | ASCII | UNICODE]
고정-길이 스트링이며, 저장될 때 지정된 길이를 맞추기 위해 오른 쪽에 스페이스를 항상 집어 넣는다. M 은 컬럼 길이를

나타내며, M 의 범위는 0 에서 255 문자 이다.
Note: CHAR 값이 추출될 때에는 뒤에 붙어 있는 스페이스는 제거된다.
MySQL 5.0.3 이전에는, 255 보다 길게 길이가 지정된 CHAR 컬럼은 주어진 길이의 값을 가질 수 있는 가장 작은
TEXT 타입으로 변환되었다. 예를 들면, CHAR(500)은 TEXT로 변환 되고, CHAR(200000)는 MEDIUMTEXT로 변
환된다. 이것은 호환성을 위한 특성이다. 하지만 이러한 변환은 컬럼이 변수 길이 컬럼이 되게끔 만들며, 또한 뒤에 있는
스페이스를 제거하는데 영향을 미치게 한다.
MySQL 5.0.3 및 그 이후 버전의 경우, 만일 CHAR 의 길이를 255 보다 길게 설정하고자 하면, 이렇게 되어 있는
CREATE TABLE 또는 ALTER TABLE 명령문은 동작을 하지 않고 에러를 발생시킨다:
mysql> CREATE TABLE c1 (col1 INT, col2 CHAR(500));
ERROR 1074 (42000): Column length too big for column 'col' (max = 255);
use BLOB or TEXT instead
mysql> SHOW CREATE TABLE c1;

:::MySQL Korea:::
ERROR 1146 (42S02): Table 'test.c1' doesn't exist
CHAR는 CHARACTER의 축약 형이다. NATIONAL CHAR (또는 축약 형, NCHAR)는 CHAR 컬럼이 미리 정의된 문
자 셋을 사용하도록 정의하기 위해 사용하는 표준 SQL 방식이다.
BINARY 속성은 컬럼 문자 셋에 대한 바이너리 콜레션을 지정하기 위한 축약 형이다. 이와 같은 경우, 정렬 및 비교는 숫
자 문자 값(numeric character value)에 기반을 한다.
ASCII 속성은 CHARACTER SET latin1에 대한 축약 형이다.
UNICODE 속성은 CHARACTER SET ucs2에 대한 축약 형이다.
CHAR BYTE 데이터 타입은 BINARY 타입에 대한 축약 형이다. 이것은 향후의 호환성을 위한것이다.
MySQL은 여러분이 CHAR(0) 타입의 컬럼을 생성하는 것을 허용한다. 이것은 실제로는 존재하기는 하지만 그 값을 실제
로 사용하지 않는 컬럼을 근간으로 하는 이전(old) 어플리케이션과 호환성을 유지해야 하는 경우에 특히 유용하다. CHAR
(0)는 두 가지의 값만을 가지는 컬럼이 필요할 경우에도 유용하다: NOT NULL 형태로 정의되지 않은 하나의 컬럼
CHAR(0) 컬럼은 오직 1 비트만을 NULL 및 '' (the empty string)만을 가질 수 있다.
● CHAR
CHAR(1)과 동의어 임.
● [NATIONAL] VARCHAR(M) [BINARY]
변수-길이 스트링. M 은 최대 컬럼 길이를 나타낸다. MySQL 5.0에서는, M 의 범위가 5.0.3 버전 까지는 0 에서 255까
지 이고, 5.0.3 및 그 이후 버전에서는 0 에서 65,535 까지다. (MySQL 5.0의 실제 VARCHAR 최대 길이는 여러분이 사
용하는 최대 열 길이 및 문자 셋을 사용해서 알아볼 수가 있다. MySQL 5.0.3에서의 최대 유효 길이는 65,532 바이트이
다.)
Note: 5.0.3 이전에는, VARCHAR 값이 저장될 때 뒤에따라오는 스페이스는 제거되었는데, 이것은 표

준 SQL 지정문과는 다른 방식이다.

:::MySQL Korea:::
MySQL 5.0.3 이전 버전의 경우, 255 보다 길게 정의된 VARCHAR 컬럼은 주어진 길이를 가질 수 있는 가장 작은
TEXT 타입으로 변환 되었다. 예를 들면, VARCHAR(500)은 TEXT으로 변환 되었고, 그리고 VARCHAR(200000)는
MEDIUMTEXT로 변환 되었다. 이것은 향후의 호환성을 위한 것이지만, 이러한 변환으로 인해 뒤에 따라오는 스페이스
가 제거되었다.
VARCHAR는 CHARACTER VARYING에 대한 축약 형이다.
BINARY 속성은 컬럼 문자 셋에 대한 바이너리 콜레션을 지정하기 위한 축약 형이다. 이와 같은 경우, 정렬 및 비교는 숫

자 문자 값에 기반을 한다.
VARCHAR 값은 필요한 만큼 많은 문자를 사용해서 저장되며, 길이를 기록하기 위해 1 바이트가 추가된다 (255보다 길
게 선언된 컬럼의 경우에는 1 바이트가 추가 됨).
● BINARY(M)
BINARY 타입은 CHAR 타입과 유사하지만, 비-바이너리 문자 스트링이 아닌 바이너리 바이트 스트링으로 저장을 한다.
● VARBINARY(M)
VARBINARY 타입은 VARCHAR 타입과 유사하지만, 비-바이너리 문자 스트링이 아닌 바이너리 바이트 스트링으로 저
장된다.
● TINYBLOB
255 (28 – 1) 바이트의 최대 길이를 사용하는 BLOB 컬럼.
● TINYTEXT
255 (28 – 1) 문자 최대 길이를 사용하는 TEXT 컬럼.
● BLOB[(M)]

:::MySQL Korea:::
65,535 (216 – 1) 바이트의 최대 길이를 사용하는 BLOB 컬럼.

옵션 길이 M 을 줄 수도 있다. 이것을 지정하면, MySQL은 M 바이트 길이의 값을 가지기 위한 가장 작은 BLOB 타입 형
태로 컬럼을 생성한다.
● TEXT[(M)]
65,535 (216 – 1) 문자 최대 길이를 사용하는 TEXT 컬럼.

옵션 길이 M 을 줄 수도 있다. 이것을 지정하면, MySQL은 M 바이트 길이의 값을 가지기 위한 가장 작은 TEXT 타입 형
태로 컬럼을 생성한다.
● MEDIUMBLOB
16,777,215 (224 – 1) 바이트 최대 길이를 사용하는 BLOB 컬럼.
● MEDIUMTEXT
16,777,215 (224 – 1) 문자 최대 길이를 사용하는 TEXT 컬럼.
● LONGBLOB
4,294,967,295 또는 4GB (232 – 1) 바이트의 최대 길이를 사용하는 BLOB 컬럼. LONGBLOB 컬럼의 최대 유효 길이
는 클라이언트/서버 프로토콜에서 구성되어 있는 최대 패킷 크기와 사용 가능한 메모리의 크기에 달려 있다.
● LONGTEXT
4,294,967,295 또는 4GB (232 – 1) 문자 최대 길이를 사용하는 TEXT 컬럼. column with a maximum length of.
The maximum effective (permitted) length of LONGTEXT 컬럼의 최대 유효 길이는 클라이언트/서버 프로토콜에서
구성되어 있는 최대 패킷 크기와 사용 가능한 메모리의 크기에 달려 있다.
● ENUM('value1','value2',...)

:::MySQL Korea:::
계산식enumeration). 오직 하나의 값만을 가질 수 있는 스트링 오브젝트로써, 그 값을 'value1', 'value2', ..., NULL 또

는 특수 '' 에러 값에서 선택한다. ENUM 컬럼은 최대 65,535 개의 개별(distinct) 값을 가질 수 있다. ENUM 값은 내부
적으로는 정수 값으로 표현된다.
● SET('value1','value2',...)
셋(set). 0(zero) 또는 그 이상의 값을 가질 수 있는 스트링 오브젝트로써, 각각의 값은 'value1', 'value2', ... 리스트에서
선택되어야 한다. SET 컬럼은 최대 64개의 요소(members)로 구성될 수 있다. SET 값은 내부적으로는 정수 값이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.1.4. 데이터 타입 디폴트 값
11.1. 데이터 타입 개요 데이터 타입 지정문에 있는 DEFAULT value 구문은 컬럼의 디폴트 값을 나타낸다. 한 가지 예외적인 것은, 디폴트 값이 반드시 상
11.1.4 데이터 타입 디폴트 값 수이어야 한다는 점이다; 함수 또는 수식이 되지는 못한다. 이것은, 데이터 컬럼에 대한 디폴트로 NOW() 또는 CURRENT_DATE
와 같은 함수를 설정할 수 없다는 것을 의미한다. 예외적으로는,
TIMESTAMP 컬럼에 대한 디폴트로는 CURRENT_TIMESTAMP를 지정할 수는 있다. Section 11.3.1.1, “TIMESTAMP

Properties as of MySQL 4.1”를 참조.
MySQL 5.0.2 이전에서는, 만일 컬럼 정의문에 아무런 DEFAULT 값도 명확하게 포함되지 않았다면, MySQL은 아래과 같이 디
폴트 값을 결정한다:
만일 컬럼이 그 값으로 NULL을 가진다면, 그 컬럼은 명확한 DEFAULT NULL 구문을 가지고서 정의 된다.
만일 컬럼이 그 값으로 NULL 을 가질 수 없다면, MySQL은 defines the column with an explicit DEFAULT 구문을 사용해서
그 컬럼을 정의하는데, 이때에는 해당 컬럼의 데이터 타입에 대한 디폴트 값을 암묵적으로 사용하게 된다. 암묵적인 디폴트
(Implicit defaults)는 아래와 같이 정의된다:
● AUTO_INCREMENT 속성을 가지고 선언된 정수 타입이 아닌 숫자 타입의 경우, 디폴트는 0 이다.

AUTO_INCREMENT 컬럼의 경우, 디폴트 값은 시퀀스의 바로 다음 값이 된다.

:::MySQL Korea:::
● 날짜 및 시간 타입 TIMESTAMP가 아닌 날짜 및 시간 타입의 경우, 디폴트는 그 타입에 대한 적정 “zero” 값이 된다. 테

이블에서 맨 처음 나오는 TIMESTAMP 컬럼의 경우는, 디폴트 값이 현재(current) 날짜와 시간이 된다. Section 11.3,
“날짜 및 시간 타입”을 참조.
● 스트링 타입 ENUM이 아닌 스트링 타입의 경우, 디폴트 값은 빈 스트링(empty string)이 된다. ENUM의 경우는, 가장 처
음의 계산(enumeration) 값이 디폴트가 된다.
BLOB 와 TEXT 컬럼에는 디폴트 값이 할당될 수 없다.
MySQL 5.0.2까지는, 만일 컬럼 정의문이 아무런 DEFAULT 값도 가지고 있지 않으면, MySQL 은 아래와 같은 방식으로 디폴트
값을 결정한다:
만일 컬럼이 그 값으로 NULL을 가질 수 있다면, 컬럼은 명확한 DEFAULT NULL 구문을 사용해서 정의된다. 이것은 5.0.2 이전
버전과 동일하다.
만일 컬럼이 그 값으로 NULL을 가질 수 없다면, MySQL은 어떠한 DEFAULT 구문도 사용하지 않고 컬럼을 정의한다. 데이터 엔
트리의 경우, 만일 INSERT 또는 REPLACE 명령문이 컬럼에 대해서 어떠한 값도 가지지 않는다면, MySQL은 그 시점에서 효과
를 미치는 SQL 모드에 따라서 그 컬럼을 처리한다:
● 만일 스트릭트(strict) SQL 모드가 활성화 되지 않았다면, MySQL은 컬럼 데이터 타입에 대해서는 암묵적인 디폴트 값을
설정한다.
● 만일 이 모드가 활성화 되었다면, 트랙젝셔널 테이블에 대해서는 에러가 발생하고 명령문은 롤백(roll backed) 된다. 비 트
랙젝셔널 테이블의 경우는, 에러가 발생하기는 하지만, 만일 다중-열 명령문의 서브 시퀀트에 대해서 또는 두 번째에 에러
가 발생하는 경우에는, 앞에 있는 열이 삽입된다.
테이블 t 가 아래와 같이 정의 되었다고 가정하자:

:::MySQL Korea:::
CREATE TABLE t (i INT NOT NULL);
이와 같은 경우, i 는 어떠한 디폴트도 가지지 않으며, 따라서 스트릭트 모드에서는 아래의 명령문들은 각각 에러가 발생하고 어떠
한 열도 삽입이 되지 않는다. 스트릭트 모드를 사용하지 않을 경우에는, 세 번째 명령문만이 에러를 발생한다; 암묵적인 디폴트는
처음 두 개의 명령문에서만 삽입되지만, 세 번째 명령문에서는 실패하게 되는데, 그 이유는 DEFAULT(i) 가 값을 만들지 못하기
때문이다:
INSERT INTO t VALUES();
INSERT INTO t VALUES(DEFAULT);
INSERT INTO t VALUES(DEFAULT(i));
Section 5.2.5, “서버 SQL 모드” 를 참조할 것.
주어진 테이블의 경우, 어떤 컬럼이 SHOW CREATE TABLE 명령문을 사용하면, 어떤 컬럼이 명확한 DEFAULT 구문을 가지고
있는지를 볼 수가 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.2. 숫자 타입
11. 데이터 타입 MySQL은 표준 SQL의 모든 숫자 데이터 타입을 지원한다. 이러한 타입에는 정확한 숫자 데이터 타입 (INTEGER, SMALLINT,
11.2. 숫자 타입 DECIMAL, 그리고 NUMERIC) 뿐만 아니라, 대략적인 숫자 데이터 타입 (FLOAT, REAL, 그리고 DOUBLE PRECISION)도 포
11.2 숫자 타입 함된다. 키워드 INT는 INTEGER의 동의어 이며, 키워드 DEC는 DECIMAL과 동의어 이다. 숫자 타입 스토리지 요구 사항에 대해
서는, Section 11.5, “데이터 타입 스토리지 요구 사항”를 참조할 것.
MySQL 5.0.3 이후에는, BIT 데이터 타입을 사용해서 비트-필드 값을 저장할 수가 있게 되었다. (5.0.3 이전에서는, MySQL은
BIT을 TINYINT(1) 형태로 해석했다.) MySQL 5.0.3의 경우, BIT는 MyISAM에 대해서만 지원을 한다. MySQL 5.0.5에서는
BIT가 MEMORY, InnoDB, 그리고 BDB를 지원하도록 확장되었다.
표준 SQL 의 확장 형태로서, MySQL 은 정수 타입도 함께 지원을 한다: TINYINT, MEDIUMINT, 그리고 BIGINT. 아래의 테이
블은 각각의 정수 타입을 위한 요구 사항 및 범위를 나타내고 있다.
Type Bytes Minimum Value Maximum Value
(Signed/Unsigned) (Signed/Unsigned)
TINYINT 1 -128 127
0 255
SMALLINT 2 -32768 32767
0 65535
MEDIUMINT 3 -8388608 8388607
0 16777215
INT 4 -2147483648 2147483647

:::MySQL Korea:::
0 4294967295
BIGINT 8 -9223372036854775808 9223372036854775807
0 18446744073709551615
타입에 대한 베이스 키워드에 따라 나오는 괄호에 있는 정수의 출력 폭을 지정하기 위한 옵션을 MySQL은 추가로 지원한다 (예를
들면, INT(4)).
출력 폭은 컬럼에 저장될 수 있는 값의 범위를 한정하거나, 컬럼에 지정된 폭을 초과하는 값을 한정하지는 않는다.
옵션 확장 속성인 ZEROFILL을 사용해서 결합(conjunction)을 하게 되면, 스페이스에 대한 디폴트 패딩(padding)은 0으로 대체

된다. 예를 들면, INT(5) ZEROFILL으로 선언된 컬럼의 경우, 4 는 00004 형태로 나오게 된다. 만일 여러분이 정수 컬럼에 있는
출력 폭 보다 큰 값을 저장한다면, MySQL이 복잡한 조인(join)을 위해 임시 테이블을 생성할 때 문제가 발생할 수도 있는데, 그 이
유는 이와 같은 상황에서는 MySQL은 데이터가 원래의 컬럼 폭에 적합할 것이라고 간주하기 때문이다.
모든 정수 타입은 옵션(비 표준) 속성인 UNSIGNED을 가진다. 여러분이 컬럼 안에는 음수가 아닌 값만을 허용하고자 하고 그러
한 컬럼에 대해서는 보다 큰 상위 숫자 범위를 사용하고자 할 경우에 부호화 되지 않은 값(unsigned value)를 사용할 수 있다. 예
를 들면, 만일 INT 컬럼이 UNSIGNED라면, 이 컬럼의 범위는 동일한 크기를 갖지만 -2147483648 과 2147483647 에서 0 과
4294967295로 변경된다.
부동 소수점 및 고정 소수점 타입 역시 UNSIGNED가 될 수 있다. 정수 타입과 함께 사용되기 때문에, 이 속성은 음수 값을 컬럼에
저장할 수 없도록 한다. 하지만, 정수 타입과는 달리, 컬럼의 상위 범위(upper range)는 동일한 범위를 갖는다.
만일 여러분이 숫자 컬럼에 대해서 ZEROFILL을 지정하면, MySQL은 자동으로 UNSIGNED 속성을 컬럼에 추가한다.
부동 소수점 데이터 타입의 경우, MySQL은 단일-정밀도(single-precision) 값에 대해서는 4 바이트를 사용하고 이중-정밀도
(double-precision) 값에 대해서는 8 바이트를 사용하게 된다.
FLOAT 및 DOUBLE 데이터 타입은 대략의 숫자 데이터 값을 표시하기 위해 사용된다. FLOAT 의 경우, 표준 SQL은 괄호 안에
있는 키워드 FLOAT 다음에 비트 단위로 정밀도를 표시할 수 있는 옵션을 허용한다. MySQL 역시 이러한 옵션 정밀도 표현을 허

:::MySQL Korea:::
용하지만, 정밀도 값은 스토리지의 크기를 알아보기 위해서만 사용된다. 0 에서 23까지의 정밀도는 4 바이트 단일 정밀도 FLOAT
컬럼을 나타내며, 24에서 53까지는 8 바이트 이중 정밀도 DOUBLE 컬럼을 나타낸다.
MySQL은 비 표준적인 신텍스를 허용한다: FLOAT(M,D) 또는 REAL(M,D) 또는 DOUBLE PRECISION(M,D). 여기에서,

“(M,D)”이 의미하는 것은 전체적으로 최대 M 의 숫자 크기와 소수점 다음의 D 자릿수를 갖는 값이다. 예를 들면, FLOAT(7,4)
로 정의된 컬럼은 -999.9999 으로 출력된다. MySQL은 값을 저장할 때 절사(rounding)을 실행하며, 따라서 만일 여러분이
999.00009 를 FLOAT(7,4) 컬럼에 삽입하는 경우에는, 그 결과는 대략 999.0001이 된다.
MySQL은 DOUBLE을 DOUBLE PRECISION (비 표준적인 확장임)의 동의어로 취급한다. MySQL은 REAL_AS_FLOAT SQL
모드가 활성화 되어 있지 않는 한, REAL도 DOUBLE PRECISION (비 표준적인 확장임)의 동의어로 함께 취급한다.
이식성을 최대로 하기 위해서, 대략의 숫자 데이터 값에 대한 스토리지를 요구하는 코드는 어떠한 정밀도 또는 자릿수를 사용하지
않고 FLOAT 또는 DOUBLE PRECISION을 사용해야 한다.
DECIMAL 및 NUMERIC 데이터 타입은 정확한 숫자 값을 저장하기 위해 사용된다. MySQL의 경우, NUMERIC은 DECIMAL 형
태로 구현된다. 이러한 타입들은 정확한 정밀도를 유지해야 하는 경우, 예를 들면 통화 데이터와 같은 것을 저장하는데 사용된다.
MySQL 5.0.3 이후에는, DECIMAL 과 NUMERIC 값은 바이너리 포맷으로 저장된다. 이전 버전에서는, 이러한 값들은 스트링으
로 저장되었으며, 각각의 자리 값은 하나의 단어, 소수점(크기가 0 보다 큰 경우), 그리고 ‘-’ 부호를 사용하였다 (음수인 경
우). Chapter 21, Precision Math를 참조.
DECIMAL 또는 NUMERIC 컬럼을 선언할 때에는, 정밀도 및 스케일 (scale)를 지정할 수 있다; 예를 들면:
salary DECIMAL(5,2)
위의 예문의 경우, 5 는 정밀도이며 2 는 스케일을 나타낸다. 정밀도(precision)는 의미를 갖는 자릿수를 나타내며, 스케일(scale)
은 소수점 다음에 나오는 자릿수를 나타낸다. 만일 스케일이 0 이면, DECIMAL 과 NUMERIC 값은 소수점 또는 분수 부분을 갖
지 않는다.
표준 SQL은 salary 컬럼이 모든 값을 저장할 때 5 자리와 소수 자리를 2개 사용하도록 한다. 따라서, 이와 같은 경우, 값의 범위는
salary 컬럼에 저장되는 값의 범위는 -999.99 에서 999.99까지가 된다. MySQL은 MySQL 5.0.3 에서 이 형태를 구현했다.
5.0.3 이전에는, 양수 범위의 끝에서, 컬럼은 실제로 9999.99까지의 숫자를 저장하였다.

:::MySQL Korea:::
표준 SQL의 경우, 신텍스 DECIMAL(M)은 DECIMAL(M,0)과 동일하다. 비슷하게, 신텍스 DECIMAL은 DECIMAL(M,0)과 동
일하다. MySQL은 DECIMAL 과 NUMERIC 신텍스에 대한 위의 두 가지 형태 모두를 지원한다. M 의 디폴트는 10이다.
DECIMAL 또는 NUMERIC의 최대 가능 자릿수는 65 (MySQL 5.0.3 에서 5.0.5까지는 64). MySQL 5.0.3 이전의 경우,
DECIMAL 및 NUMERIC 값의 최대 범위는 DOUBLE과 동일하지만, 주어진 DECIMAL 또는 NUMERIC 컬럼에 대한 실제 범위
는 주어진 컬럼의 정밀도 또는 스케일에 의해 제한을 받는다. 이러한 컬럼이 소수점 다음에 지정된 스케일 보다 큰 값을 할당 받는
경우에는, 그 값은 해당 스케일로 변환된다.
MySQL 5.0.3 이후에는, BIT 데이터 타입은 비트-필드(bit-field) 값을 저장하는데 사용된다. BIT(M) 타입은 allows for
storage of M-비트 값에 대한 스토리지를 허용한다. M 은 1 에서 64까지 범위를 가질 수 있다.
비트 값을 지정하기 위해서는, b'value' 수식을 사용할 수 있다. value 는 0과 1을 사용해서 작성된 바이너리 값이다. 예를 들면,
b'111' 과 b'100000000'은 7 과 128을 각각 나타낸다. Section 9.1.5, “Bit-Field Values”를 참조할 것.
만일 여러분이 M 비트 크기보다 작은 값을 BIT(M) 컬럼에 할당 한다면, 그 값의 왼쪽에는 0이 채워진다. 예를 들면, b'101'을 BIT
(6) 컬럼에 할당하는 것은, b'000101'과 동일한 효과를 나타낸다.
데이터 타입의 허용 범위를 벗어나는 숫자 컬럼에 값을 저장하도록 할 경우에는, MySQL은 그 시점에 효력을 발생하는 SQL 모드
에 따라서 행동을 한다. 예를 들면, 만일 어떠한 SQL 모드도 활성화 되지 않았다면,
MySQL은 그 값을 범위내의 적당한 끝자리에 갖다 놓는다. 하지만, 만일 모드가 TRADITIONAL로 설정되어 있다면, MySQL은
범위 밖의 값은 거부하고 에러를 발생시키며, SQL 표준에 따라서 실패를 삽입한다.
논-스트릭트 모드(non-strict mode)의 경우, 범위 밖의 값이 정수 컬럼에 할당되면, MySQL은 컬럼 데이터 타입 범위의 끝 지점

(end point) 값을 저장한다. 만일 여러분이 256을 TINYINT 또는 TINYINT UNSIGNED 컬럼에 저장한다면, MySQL은 127 또
는 255를 각각 저장한다. 부동 소수점 또는 고정 소수점 컬럼이 지정된(또는 디폴트) 정밀도와 스케일의 범위를 초과하는 값을 할
당 받는다면, MySQL은 범위의 끝 부분 지점 값을 저장한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.3. 날짜 및 시간 타입
11. 데이터 타입 11.3.1. DATETIME, DATE, 그리고 TIMESTAMP 타입

11.3. 날짜 및 시간 타입 11.3.2. TIME 타입
11.3 날짜 및 시간 타입 11.3.3. YEAR 타입
11.3.1 DATETIME, DATE, 그리고 TIMESTAMP 타입 11.3.4. Y2K 이슈 및 날짜 타입 - 생략

임시 값을 표시하기 위한 날짜 및 시간 타입은 DATETIME, DATE, TIMESTAMP, TIME, 그리고 YEAR가 있다. 각각의
11.3.2 TIME 타입
임시 타입은 유효 값에 대한 범위를 가지는데, MySQL은 표현할 수 없는 값을 지정할 때 사용하는 0 도 포함을 한다.
11.3.3 YEAR 타입
TIMESTAMP 타입은 특수 자동 업데이트 동작을 하는데, 이것에 대해서는 나중에 설명하기로 하겠다. 임시 타입 스토리지
요구 사항에 대해서는, Section 11.5, “데이터 타입 스토리지 요구 사항”를 참조하기 바란다.
MySQL 5.0.2부터는, MySQL은 유효하지 않은 날짜를 입력할 경우에 경고 또는 에러가 발생한다. SQL 모드에 적당한 값
을 설정하면, 여러분은 MySQL이 지원하도록 하고자 하는 날짜 타입을 정확히 지정할 수 있다. (Section 5.2.5, “서버
SQL 모드”를 참조.) ALLOW_INVALID_DATES SQL 모드를 사용하면, MySQL이 특정 날짜, 예를 들면 '1999-11-
31'와 같은 날짜를 수용할 수 있도록 할 수가 있다. (5.0.2 이전 버전의 경우, 이러한 모드는 MySQL의 디폴트였음.) 이것
은 사용자가 향후에 있을 프로세싱에 대해서 데이터 베이스 내에 지정한 (예를 들면, 웹 형태에서) “틀릴 가능성이 있는”
값으 저장하고자 할 때 유용하다. 이러한 모드 아래에서는, MySQL은 달(month)이 0에서 12 사이의 범위에 있는지 그리
고 날짜가 0에서 31 사이에 존재하는지 만을 검증한다. 이러한 범위에는 0이 포함 되어 있는데, 그 이유는 MySQL은
DATE 또는 DATETIME 컬럼에 일자 또는 달에 해당하는 값으로 0을 저장할 수 있도록 하기 때문이다. 이것은 여러분이
정확한 날짜를 모르는 날짜를 저장할 필요가 있는 어플리케이션에 대해서 매우 유용하다. 이와 같은 경우, 여러분은 날짜를
'1999-00-00' 또는 '1999-01-00' 형태로 저장하기만 하면 된다. 만일 여러분이 이와 같은 값을 저장한다면, 완벽한 날
짜를 요구하는 DATE_SUB() 또는 DATE_ADD 와 같은 함수에 대해서는 정확한 값을 얻어낼 수가 없을 것이다. (만일 날
짜 값으로 0 을 허용하고 싶지 않을 경우에는, NO_ZERO_IN_DATE SQL 모드를 사용하면 된다).
MySQL은 또한 “더미 날짜(dummy date)로써 '0000-00-00' 을 저장할 수 있게도 한다 (만일 NO_ZERO_DATE SQL

:::MySQL Korea:::
모드를 사용하지 않는 다면). 이것은 어떤 경우에는 (날짜와 인덱스에서 스페이스를 덜 사용한다) NULL 값을 사용하는 것
보다 더욱 편리할 때도 있다.
아래의 내용은 날짜 및 시간 타입을 가지고 일을 처리할 때 고려해야 할 일반적인 사항들이다:
● MySQL은 주어진 날짜 또는 시간 타입에 대해서 표준 결과 포맷으로 값을 추출하지만, 여러분이 제공하는 (예를 들

면, 날짜또는 시간 타입을 비교하거나 또는 이것들에 할당하고자 하는 값을 지정할 때) 입력 값에 대해서는 다양한
형태의 포맷을 해석하고자 시도한다. 지원되는 포맷은 다음 섹션에서 설명될 것이다. MySQL은 유효한 값이 주어진
다고 가정한다. 만일 여러분이 다른 포맷의 값을 사용한다면, 예상하지 못한 결과가 나올 수도 있다.
● 두 자리 년도 값을 가지고 있는 날짜는 모호한 형태가 되는데, 그 이유는 세기(century)가 표시되지 않기 때문이
다. MySQL은 두 자리 년도 값을 해석할 때 아래의 규칙을 사용한다:
❍ 70-99 범위 내의 년도 값은 1970-1999로 변환된다.
❍ 00-69 범위 내의 년도 값은 2000-2069로 변환 된다.
● 비록 MySQL이 여러 가지의 포맷 형태로 값을 해석하고자 하더라도, 날짜는 항상 년-월-일 순서로 주어져야 하고
(예, '98-09-04'), 다른 지역에서 흔히 사용되는 월-일-년 또는 일-월-년 순서로 주어지면 안 된다 (예, '09-
04-98', '04-09-98').
● MySQL은 그 값이 숫자 문장(numeric context) 또는 그 반대 형태로 사용될 경우 자동으로 날짜 또는 시간 타입
을 숫자로 변환 시킨다.
● 디폴트로는, MySQL이 범위를 벗어나거나 또는 유효하지 않은 타입이 날짜 또는 시간 타입을 만나게 되면, 그 값을
0으로 변경 시킨다. 하지만, 범위를 벗어난 TIME 값이 TIME 범위의 적당한 끝 지점에 클립(clip)될 경우에는 예외
적이다.
아래에 있는 테이블은 각각의 타입에 대한 “0(zero)” 값 포맷을 보여 주는 것이다. 이러한 값을 사용하면

NO_ZERO_DATE SQL 모드가 활성화 되어 있는 경우에 이러한 값을 사용하면 에러가 발생한다는 것은 알아두기
바란다.
Data Type “Zero” Value
DATETIME '0000-00-00 00:00:00'
DATE '0000-00-00'

:::MySQL Korea:::
TIMESTAMP '0000-00-00 00:00:00'
TIME '00:00:00'
YEAR 0000
● “0 (zero)” 값이 특별한 것이기는 하지만, 테이블에 나타나 있는 값을 사용해서 명확하게 이것을 참조 또는 저장

할 수가 있다. 또한, '0' 또는 0을 사용해서 이렇게 할 수도 있는데, 이것이 쓰기에 보다 편리하다.
● MyODBC를 통해서 사용되는 “0 (Zero)” 날짜 또는 시간 값은 MyODBC 2.50.12 및 이후 버전에서는 자동으로
NULL 로 변환 되는데, 그 이유는 ODBC가 그러한 값을 처리할 수 없기 때문이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.3.1. DATETIME, DATE, 그리고 TIMESTAMP 타입

11.3.1.1. MySQL 4.1 버전까지의 TIMESTAMP 특성
11.3. 날짜 및 시간 타입
11.3.1 DATETIME, DATE, 그리고 TIMESTAMP 타입 DATETIME, DATE, 그리고 TIMESTAMP 타입들은 서로 관련이 있다. 이 섹션에서는 이러한 타입들의 특성과, 서로가
얼마나 유사한지, 그리고 다른 점은 어떤 것이 있는지에 대해서 설명하기로 한다.
DATETIME 타입은 날짜와 시간 정보를 모두 가지고 있는 값을 필요로 할 때 사용된다. MySQL 은 DATETIME 값을

'YYYY-MM-DD HH:MM:SS' 포맷 형태로 추출해서 출력한다. 지원되는 범위는 '1000-01-01 00:00:00' 에서 '9999-
12-31 23:59:59'까지 이다.
DATE 타입은 날짜 값만을 필요로 할 때 사용되는데, 여기에는 시간 부분이 없다. MySQL은 DATE 값을 'YYYY-MM-
DD' 포맷으로 추출해서 출력한다. 지원되는 범위는 '1000-01-01' 에서 '9999-12-31'까지 이다.
DATETIME 및 DATE 의 범위 설명에서, “지원되는(supported)”의 의미는 이것 보다 이전 값을 사용할 수는 있더라도

책임지지는 않는다는 것을 나타낸다.
TIMESTAMP 데이터 타입은 다양한 특성을 가지고 있는데, MySQL 버전과 서버가 구동 중에 있는 SQL 모드에 따라 다르
다. 이러한 특성들은 이 섹션 후반부에 설명하기로 한다.

:::MySQL Korea:::
여러분은 포맷의 공통 셋(common set)을 사용해서 DATETIME, DATE, 그리고 TIMESTAMP 값을 지정할 수가 있다:
● 'YYYY-MM-DD HH:MM:SS' 또는 'YY-MM-DD HH:MM:SS' 포맷 중의 하나를 사용하는 스트링 형태. “릴렉

스드(relaxed)” 신텍스는 허용된다: 어떠한 구두(punctuation) 문자도 날짜 부분 또는 시간 부분 사이의 구분 문
자(delimiter)로 사용할 수가 있다. 예를 들면, '98-12-31 11:30:45', '98.12.31 11+30+45', '98/12/31
11*30*45', 그리고 '98@12@31 11^30^45' 는 모두 동일한 것이다.
● 'YYYY-MM-DD' 또는 'YY-MM-DD' 포맷 중의 하나를 사용하는 스트링 형태. 여기에서도 “릴렉스드
(relaxed)” 신텍스는 허용된다. 예를 들면, '98-12-31', '98.12.31', '98/12/31', 그리고 '98@12@31'는 모두
동일하다.
● 'YYYYMMDDHHMMSS' 또는 'YYMMDDHHMMSS' 포맷 중의 하나를 사용하는 구분 문자가 없는 스트링 형태로
시간 부분이 의미를 가지고 있다. 예를 들면, '19970523091528' 그리고 '970523091528'는 '1997-05-23
09:15:28'로 해석되지만, '971122129015'는 유효한 형태가 아니며 '0000-00-00 00:00:00'로 해석된다.
● As a string with no delimiters in either 'YYYYMMDD' or 'YYMMDD' 포맷 중의 하나를 사용하는 구분 문자가
없는 스트링 형태로, 날짜 부분이 의미가 있다. 예를 들면, '19970523' 및 '970523'은 '1997-05-23' 형태로 해석
되지만, '971332'은 유효하지 않기 때문에 '0000-00-00'으로 변환된다.
● YYYYMMDDHHMMSS 또는 YYMMDDHHMMSS 포맷 중의 하나를 사용하는 숫자로써, 숫자는 날짜의 의미를 갖
는다. 예를 들면, 19830905132800 및 830905132800는 '1983-09-05 13:28:00'로 해석된다.
● YYYYMMDD 또는 YYMMDD 포맷 중의 하나를 사용하는 숫자로서, 숫자는 날짜의 의미를 갖는다. 예를 들면,
19830905 및 830905 은 '1983-09-05'으로 해석된다.
● DATETIME, DATE, 또는 TIMESTAMP 문맥에 적합한 값을 리턴하는 함수의 결과 형태로, NOW() 또는
CURRENT_DATE가 있다.
유효하지 않은 DATETIME, DATE, 또는 TIMESTAMP 값들은 “0 (zero)” 값으로 변환된다 ('0000-00-00

00:00:00' 또는 '0000-00-00').
날짜 부분 구분 문자를 포함하는 스트링 형태로 지정된 값에 대해서는, 10 보다 작은 월 (month) 또는 날짜 값에 대해서

두 자리를 지정할 필요는 없다. '1979-6-9'은 '1979-06-09'과 동일하다. 비슷하게, 시간 부분 구분 문자를 포함하는 스

:::MySQL Korea:::
트링 형태로 지정된 값에 대해서는, 10 보다 작은 시(hour), 분(minute), 또는 초(second)에 대해서 두 자리를 지정할 필

요가 없다. '1979-10-30 1:2:3' 은 '1979-10-30 01:02:03'과 동일하다.
숫자 형태로 지정된 값은 6, 8, 12, 또는 14 자리 길이가 되어야 한다. 만일 어떤 숫자가 8 또는 14 자리 길이라고 한다면,

그 숫자는 YYYYMMDD 또는 YYYYMMDDHHMMSS 포맷이며 연도는 처음 4 자리로 표시된다고 간주된다. 만일 숫자가
6 또는 12 자리 길이라면, 그 숫자는 YYMMDD 또는 YYMMDDHHMMSS 포맷이며 연도는 처음 두 자리라고 간주된다. 위
의 두 가지 경우에 해당하지 않는 숫자는 0 을 앞에 넣어서 자릿수가 가장 근접한 길이로 변환된다.
구분 문자가 없는 스트링 형태로 지정된 값은 주어진 길이를 사용해서 해석된다. 만일 그 스트링이 8 또는 14 문자 길이를
갖는다면, 연도는 처음의 4 자리 문자라고 가정을 한다. 그렇지 않을 경우, 연도는 처음 두 자리의 문자로 주어졌다고 간주된
다. 스트링은 왼쪽에서 오른쪽으로 연도, 월, 일, 시간, 분, 초 값으로 해석을 한다. 이것이 의미하는 것은 여러분이 6 보다 작
은 문자 길이의 스트링을 사용할 수 없다는 것이다. 예를 들면, 만일 여러분이 '9903'을 지정해서 March, 1999을 나타낸다
고 한다면, MySQL은 “0 (zero)”의 날짜 값을 테이블에 삽입한다. 이것은 연도와 월 값이 각각 99와 03이기는 하지만,
날짜 부분이 완벽하게 빠져 있기 때문에, 날짜에 해당하는 값은 유효하지가 않게 된다. 하지만, 여러분은 월 또는 날짜 부분
을 생략하기 위해서 0 값을 명확하게 지정할 수가 있다. 예를 들면, '990300'을 사용해서 0 값을 '1999-03-00'에 삽입 시
킬 수가 있다.

:::MySQL Korea:::
제목검색
11.3.1.1. MySQL 4.1 버전까지의 TIMESTAMP 특성

11.3. 날짜 및 시간 타입 Note: 이전 버전의 MySQL (4.1 이전 버전)의 경우, TIMESTAMP 데이터 타입의 특성들은 이 섹션에서 설명한 것들과 여러 가
11.3.1 DATETIME, DATE, 그리고 지 부분에서 많은 차이점을 가지고 있다. 따라서, 만일 이전 버전의 TIMESTAMP 데이터를 MySQL 5.0에서 동작되도록 변환 시
TIMESTAMP 타입 키고자 한다면, MySQL 3.23, 4.0, 4.1 Reference Manual 을 참조하기 바란다.
11.3.1.1 MySQL 4.1 버전까지의 TIMESTAMP

특성
TIMESTAMP 컬럼은 DATETIME 컬럼과 동일한 포맷으로 출력된다. 다른 말로 표현하면, 출력 폭은 19 문자 길이로 고정되며,
그리고 포맷은 YYYY-MM-DD HH:MM:SS와 같다.
MySQL서버는 또한 MAXDB SQL 모드를 활성화 시킨 상태에서도 동작을 한다. 이 모드가 활성화 된 채로 서버를 구동하게 되면,
TIMESTAMP는 DATETIME과 동일하게 된다. 즉, 만일 어떤 테이블을 생성하는 시점에 이 모드가 활성화 되어 있다면,
TIMESTAMP 컬럼은 DATETIME 컬럼 형태로 생성이 된다. 그 결과, 그러한 컬럼은 DATETIME 출력 포맷을 사용하며, 동일
한 범위를 가지고, 그리고 현재(current) 날짜 및 시간을 자동으로 초기화 또는 업데이트하지 않게 된다.
MAXDB 모드를 활성화 시키기 위해서는, 서버 스타트 업 시점에 --sql-mode=MAXDB 서버 옵션을 사용해서 서버 SQL 모드
모드를 MAXDB로 설정하거나 또는 서버가 구동 중에 있을 때에 글로벌 sql_mode 변수를 아래와 같이 설정해 주면 된다:
mysql> SET GLOBAL sql_mode=MAXDB;
클라이언트는 자신의 연결을 위해서 아래와 같이 서버가 MAXDB 모드로 동작을 하게끔 만들 수가 있다:

:::MySQL Korea:::
mysql> SET SESSION sql_mode=MAXDB;
아래에서 설명하는 내용은 MAXDB 모드가 활성화된 상태로 생성되지 않은 테이블의 TIMESTAMP 컬럼에만 해당하는 것임을 알
아야 하는데, 그 이유는 그러한 컬럼들은 DATETIME 컬럼 형태로 생성되기 때문이다.
MySQL 5.0.2 버전 현재, MySQL은 날짜 또는 월 컬럼에 0을 가지고 있는 타임 스탬프 값 또는 유효한 날짜를 가지고 있지 않는
값을 허용하지 않는다. 이 규칙에서 유일한 예외 사항은 특별 값 '0000-00-00 00:00:00' 뿐이다.
여러분은 자동 TIMESTAMP 초기화 (initialization)와 갱신이 발생할 때 그리고 아래와 같은 동작을 하는 컬럼에 대해서는 신중
하게 처리해야 한다:
● 테이블에 있는 하나의 TIMESTAMP 컬럼에 대해서는, 디폴트 값으로 현재(current) 타임 스탬프를 할당할 수 있고 자
동-업데이트 값을 할당할 수가 있다. 현재의 타입 스탬프를 컬럼 초기화를 위한, 자동-업데이트를 값을 위한, 그리고 양
쪽 모두를 위한 디폴트 값으로 만들 수가 있다. 현재의 타입 스템프를 하나의 컬럼에 대해서는 디폴트 값으로 하고 다른 컬
럼에 대해서는 자동-업데이트 값으로 만들 수는 없다.
● 현재의 날짜 및 시간에 대해서 자동으로 초기화를 하거나 업데이트를 하기 위해 특정 TIMESTAMP 컬럼을 지정하는 것
은 가능하다. 이것은 맨 처음의 TIMESTAMP 컬럼을 사용할 필요는 없다.
아래의 규칙은 TIMESTAMP 컬럼에 대한 초기화 및 업데이트를 관장하는 것이다:
● 만일 DEFAULT 값이 테이블에 있는 맨 처음의 TIMESTAMP 컬럼에 대해서 지정이 되었다면, 이것은 무시할 수가 없다.
디폴트는 CURRENT_TIMESTAMP 또는 상수 날짜 및 시간 값이 될 수 있다.
● DEFAULT NULL은 맨 처음의 TIMESTAMP 컬럼에 대해서는 DEFAULT CURRENT_TIMESTAMP과 동일하다. 다
른 모든 TIMESTAMP 컬럼에 대해서는, DEFAULT NULL은 DEFAULT 0 형태로 취급된다.
● 테이블 내의 모든 단일 TIMESTAMP 컬럼은 현재의 타입 스탬프를 초기화 하거나 또는 업데이트를 자동으로 하기 위한
것으로 사용될 수 있다.
● CREATE TABLE 명령문에서는, 맨 처음의 TIMESTAMP 컬럼은 아래의 방식 중의 하나의 형태로 선언될 수 있다:
❍ DEFAULT CURRENT_TIMESTAMP 및 ON UPDATE CURRENT_TIMESTAMP 구문 모두를 사용할 경우,
그 컬럼은 현재의 타입 스탬프를 디폴트 값으로 가질 수 있고, 업데이트가 자동으로 이루어 진다.

:::MySQL Korea:::
❍ DEFAULT 또는 ON UPDATE 구문 모두를 사용하지 않을 경우, 이것은 DEFAULT CURRENT_TIMESTAMP

ON UPDATE CURRENT_TIMESTAMP과 같다.
❍ DEFAULT CURRENT_TIMESTAMP 구문을 사용하면서 어떠한 ON UPDATE 구문도 사용하지 않는 경우, 그
컬럼은 현재의 타입 스탬프를 디폴트로 사용할 수는 있지만 자동 업데이트를 하지는 못한다.
❍ 아무런 DEFAULT 구문도 사용하지 않으면서 ON UPDATE CURRENT_TIMESTAMP 구문을 사용하는 경우에
는, 그 컬럼은 디폴트로 0 을 가지며 자동 업데이트를 실행한다.
❍ 상수 DEFAULT 값을 사용하면, 그 컬럼은 주어진 디폴트 값을 갖게 된다. 만일 그 컬럼이 ON UPDATE
CURRENT_TIMESTAMP 구문을 갖고 있다면, 자동으로 업데이트를 실행하며, 그렇지 않을 경우에는 자동 업데
이트를 실행하지 못한다.
달리 표현하면, 여러분은 현재의 타임 스탬프를 초기 값과 자동-업데이트 값으로, 또는 이들 중의 하나로 사용하거나 양

쪽 모두에 사용하지 않을 수도 있다.
● CURRENT_TIMESTAMP 또는 이것과 동일한 것들을 (CURRENT_TIMESTAMP(), NOW(), LOCALTIME,

LOCALTIME(), LOCALTIMESTAMP, 또는 LOCALTIMESTAMP()) DEFAULT 및 ON UPDATE 구문 안에서 사용
할 수가 있다. 이것들은 모두 “현재의 타임 스탬프 (the current timestamp)”를 의미한다. (UTC_TIMESTAMP는 사
용할 수가 없다.)
● DEFAULT 와 ON UPDATE 속성의 순서는 중요하지가 않다. 만일 DEFAULT 와 ON UPDATE 모두 TIMESTAMP 컬
럼에 대해서 지정이 된다면, 둘 중의 하나가 우선 순위를 갖는다. 예를 들면, 아래의 명령문은 모두 동일한 것이다:
• CREATE TABLE t (ts TIMESTAMP);
• CREATE TABLE t (ts TIMESTAMP DEFAULT CURRENT_TIMESTAMP
• ON UPDATE CURRENT_TIMESTAMP);
• CREATE TABLE t (ts TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
• DEFAULT CURRENT_TIMESTAMP);
● 맨 처음 것이 아닌 다른 TIMESTAMP 컬럼에 대해서 자동 디폴트 또는 업데이트를 지정하기 위해서는, 맨 처음의

TIMESTAMP 컬럼에 대한 자동 초기화 및 업데이트 동작을 억제 시켜야 하는데, 이렇게 하기 위해서는 상수 DEFAULT

:::MySQL Korea:::
값을 명확하게 할당해 주어야 한다 (예를 들면, DEFAULT 0 또는 DEFAULT '2003-01-01 00:00:00'). 다른

TIMESTAMP 컬럼의 경우에는, 맨 처음 TIMESTAMP 컬럼에 해당하는 것과 같은 규칙이 적용되는데, 만일 여러분이
DEFAULT 및 ON UPDATE 구문 모두를 생략할 경우에는, 자동 초기화 또는 업데이트가 발생하지 않는다는 점은 예외적
이다.
예문. 아래의 명령문들은 모두 동일한 것들이다:
CREATE TABLE t (
ts1 TIMESTAMP DEFAULT 0,
ts2 TIMESTAMP DEFAULT CURRENT_TIMESTAMP
ON UPDATE CURRENT_TIMESTAMP);
CREATE TABLE t (
ts1 TIMESTAMP DEFAULT 0,
ts2 TIMESTAMP ON UPDATE CURRENT_TIMESTAMP
DEFAULT CURRENT_TIMESTAMP);
여러분은 접속 별로 현재의 타임 존을 설정할 수가 있는데, Section 5.11.8, “MySQL 서버 타임 존 지원”을 참조하기 바란다.
여러분은 컬럼에 NULL 값을 넣을 수 있게 하기 위해서 TIMESTAMP 컬럼의 정의문에 NULL 속성을 포함 시킬 수가 있다. 예를
들면:
CREATE TABLE t

:::MySQL Korea:::
ts1 TIMESTAMP NULL DEFAULT NULL,
ts2 TIMESTAMP NULL DEFAULT 0,
ts3 TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP
);
만일 NULL 속성을 지정하지 않으면, 컬럼을 NULL로 설정하는 것이 현재(current) 타임 스탬프로 설정하는 것이 된다. NULL 값
을 허용하는 TIMESTAMP 컬럼이 아래의 조건 중의 하나에 해당하지 않으면 현재의 타임 스탬프를 가져오지 않음을 알기 바란
다.:
● 그 컬럼의 디폴트 값이 CURRENT_TIMESTAMP 형태로 정의 됨

● NOW() 또는 CURRENT_TIMESTAMP가 그 컬럼에 삽입 됨
달리 설명하면, NULL로 정의된 TIMESTAMP 컬럼은 아래와 같은 정의문을 사용해서 생성되어질 경우에만 자동-초기화가 된다
는 것이다:
CREATE TABLE t (ts TIMESTAMP NULL DEFAULT CURRENT_TIMESTAMP);
그렇지 않을 경우 — 즉, 아래와 같이 TIMESTAMP 컬럼이 NULL 값을 허용하기는 하지만 DEFAULT TIMESTAMP를 사용하
지 않을 경우에는 …,
CREATE TABLE t1 (ts TIMESTAMP NULL DEFAULT NULL);
CREATE TABLE t2 (ts TIMESTAMP NULL DEFAULT '0000-00-00 00:00:00');
… 여러분은 현재에 해당하는 날짜와 시간을 명확하게 삽입해야 한다. 예를 들면:
INSERT INTO t1 VALUES (NOW());

:::MySQL Korea:::
INSERT INTO t2 VALUES (CURRENT_TIMESTAMP);

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.3.2. TIME 타입
11.3. 날짜 및 시간 타입 MySQL은 TIME 값을 'HH:MM:SS' 포맷 형태로 추출해서 출력한다 (또는 큰 시간 값의 경우에는 'HHH:MM:SS' 포맷). TIME
11.3.2 TIME 타입 값은 '-838:59:59'에서 '838:59:59' 까지의 범위를 가질 수 있다. 시간(hours) 부분은 때로는 매우 클 수가 있는데, 그 이유는
TIME 타입을 일별 시간을 표현하는데 뿐만 아니라(보통 24 시간 이내), 두 가지의 사건 사이의 시간 간격을 표시하기 위해 사용되
기도 하기 때문이다 (이와 같은 경우에는 보통 24 시간 보다 큰 값이 나오거나, 음수 값이 나오기도 한다).
여러분은 다양한 형태로 TIME 값을 지정할 수가 있다:
● 'D HH:MM:SS.fraction' 포맷. 또한 아래와 같은 “릴렉스드(relaxed)” 신텍스를 사용할 수도 있다: 'HH:MM:SS.

fraction', 'HH:MM:SS', 'HH:MM', 'D HH:MM:SS', 'D HH:MM', 'D HH', 또는 'SS'. 여기에서 D는 날짜를 나타내며 0에
서 34까지의 범위를 갖는다. MySQL은 프랙션(fraction) 부분을 저장하지 않는다는 점을 기억하자.
● 'HHMMSS' 포맷 형태의 구분 문자가 없는 스트링 타입으로, 이 스트링은 시간의 의미를 갖는다. 예를 들면, '101112'은
'10:11:12'라고 해석되지만, '109712'는 유효한 형태가 아니기 때문에 (분에 해당하는 부분이 잘못 되어 있음)
'00:00:00'이 된다.
● HHMMSS 포맷 형태의 숫자 타입으로, 이 숫자들은 시간의 의미를 갖는다. 예를 들면, 101112은 '10:11:12'로 해석된다.
아래와 같은 다른 방식의 포맷들도 사용할 수가 있다: SS, MMSS, HHMMSS, HHMMSS.fraction.
● TIME 문맥에서 사용 가능한 값을 리턴하는 함수의 결과 형태로서, CURRENT_TIME가 있다.
시간 부분 구분 문자를 포함하는 스트링 형태로 지정된 TIME 값의 경우, 10 보다 작은 시간, 분, 또는 초를 나타내는 값에 대해서
는 두 자리를 지정할 필요가 없다. '8:3:2'은 '08:03:02'과 동일하다.

:::MySQL Korea:::
축약된 값을 TIME 컬럼에 할당할 때에는 세심한 주의를 하기 바란다. 콜론을 사용하지 않는다면, MySQL은 맨 오른쪽의 두 자리
값이 초를 나타내는 것으로 생각을 하면서 값을 해석하게 된다. (MySQL 은 TIME 값을 일별 시간이 아닌 경과 시간으로 해석한
다.) 예를 들면, 여러분은 '1112' 및 1112을 '11:12:00'로 해석할지는 몰라도(11 시 12분), MySQL은 이것을 '00:11:12' (11
분, 12 초)로 해석한다. 비슷하게, '12' 및 12 는 '00:00:12'로 해석된다. 콜론을 사용하는 TIME 값은, 그 반대로, 항상 일별 시간
으로 해석된다. 즉, '11:12' 은 '11:12:00'을 의미하며, '00:11:12'을 의미하지는 않는다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.3.3. YEAR 타입
11.3. 날짜 및 시간 타입 YEAR 타입은 연도를 나타내기 위해서 사용되는 한 바이트 타입이다.
11.3.3 YEAR 타입
MySQL은 YEAR 값을YYYY 포맷으로 추출해서 표시한다. 범위는 1901 에서 2155까지 이다.
여러분은 다양한 형태로 YEAR 값을 표시할 수가 있다:
● '1901' 에서 '2155'의 범위를 갖는 4 자리수의 스트링

● '00' 에서 '99'의 범위내의 두 자리수의 스트링. '00' 에서 '69' 까지 그리고 '70' 에서 '99' 까지의 숫자는 2000 에서 2069
까지 그리고1970 에서 1999까지로 변환된다.
● 1 에서 99의 범위내의 두 자리수의 스트링. 1 에서 69 및 70 에서 99 까지의 값은 2001 에서 2069 그리고1970 에서
1999로 변환된다. 두 자리 숫자에 대한 범위는 두 자리 스트링에 대한 범위와 다소 차이가 있는데, 그 이유는 2000(Y2K)
때문이다.
● YEAR 문맥에서 사용 가능한 값을 리턴하는 함수의 결과 값 형태로, NOW()가 있다.
유효하지 않은 YEAR 값은 0000으로 변환 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.4. 스트링 타입
11. 데이터 타입 11.4.1. CHAR 및 VARCHAR 타입

11.4. 스트링 타입 11.4.2. BINARY 및 VARBINARY 타입
11.4 스트링 타입 11.4.3. BLOB 및 TEXT 타입
11.4.1 CHAR 및 VARCHAR 타입 11.4.4. ENUM 타입
11.4.2 BINARY 및 VARBINARY 타입 11.4.5. SET 타입
11.4.3 BLOB 및 TEXT 타입

스트링 타입에는 CHAR, VARCHAR, BINARY, VARBINARY, BLOB, TEXT, ENUM, 그리고 SET가 있다. 이 섹션에서는 이러
11.4.4 ENUM 타입
한 타입의 동작 형태 및 쿼리에서 어떻게 사용할 수 있는지를 설명하기로 하겠다. 스토리지 요구 사항에 대한 스트링 타입에 대해서
11.4.5 SET 타입
는, Section 11.5, “데이터 타입 스토리지 요구 사항”을 참조하기 바란다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.4.1. CHAR 및 VARCHAR 타입
11.4. 스트링 타입 CHAR 및 VARCHAR 타입은 서로 비슷하지만, 저장 및 추출하는 방식에서 서로 차이가 있다. MySQL 5.0.3 버전까지는, 두 타입
11.4.1 CHAR 및 VARCHAR 타입 간에는 최대 길이 및 트레일링 스페이스(trailing space)가 유지 되는지에 관해서도 차이점을 가진다.
CHAR 및 VARCHAR 타입은 여러분이 저장하고자 하는 문자의 최대 숫자를 지정하는 길이와 함께 선언된다. 예를 들면, CHAR
(30)은 30개의 문자를 저장할 수가 있다.
CHAR 컬럼의 길이는 여러분이 테이블을 생성할 때 선언한 길이에 고정이 된다. 그 길이는 0 에서 255 사이의 값을 가진다.
CHAR 값을 저장할 때에는, 지정된 길이를 맞추기 위해서 오른쪽에 스페이스를 집어 넣게 된다. CHAR 값을 추출할 때에는, 이렇
게 추가된 스페이스가 제거된다.
VARCHAR 컬럼에 저장되어 있는 값들은 변수-길이 스트링이다. 그 길이는 MySQL 5.0.3 이전에는 0에서 255 사이의 값을 가
질 수 있었으며, 5.0.3 이후의 버전에서는 0에서 65,535 사이의 값을 가지게 된다.
CHAR와는 반대로, VARCHAR 값은 필요한 문자 수 만큼만을 사용해서 저장되며, 여기에 길이를 기록하는 1 바이트가 추가 된다
(255 보다 긴 길이로 선언된 컬럼에 대해서는 2 바이트가 추가 됨).

:::MySQL Korea:::
VARCHAR 값을 저장할 때에는 스페이스가 따라 붙지 않는다. 트레일링 스페이스를 처리하는 것은 버전에 따라 다르게 된다.
MySQL 5.0.3 버전 이후에는, 표준 SQL 에서 처럼, 값을 저장 및 추출할 때 트레일링 스페이스를 유지한다. MySQL 5.0.3 버전
이전에는, VARCHAR 컬럼에 값을 저장할 때 트레일링 스페이스가 값에서 제거가 된다; 이것은 값을 추출할 때에도 스페이스가 없
게 된다는 것을 의미한다.
만일 여러분이 컬럼의 최대 길이를 초과하는 CHAR 또는 VARCHAR 컬럼에 값을 할당한다면, 그 값은 허용된 길이에 맞도록 잘리
게 된다 (truncated). 만일 이렇게 잘린 문자가 스페이스가 아니라면, 경고문이 발생한다. 스페이스가 아닌 문자를 제거
(truncation)할 경우에 경고가 아닌 에러를 발생시키도록 할 수가 있고 스트릭트 SQL모드를 사용해서 값을 삽입하는 것을 막을 수
도 있다. Section 5.2.5, “서버 SQL 모드”를 참조.
MySQL 5.0.3 이전에서는, 만일 트레일링 스페이스가 제거되지 않는 데이터 타입을 필요로 할 경우에는, BLOB 또는 TEXT 타입
을 사용하면 된다. 또한, 만일 임의의 바이트 값을 가지고 있는 암호 또는 압축 함수에서 얻는 결과와 같은 바이너리 값을 저장하고
자 한다면, CHAR 또는 VARCHAR 컬럼 보다는 BLOB 컬럼을 사용한다 이렇게 하면 트레일링 스페이스를 삭제함으로서 발생될
수 있는 데이터 값의 변화를 피할 수가 있게 된다.
아래의 테이블은 CHAR 및 VARCHAR 간의 차이점에 대해서 예시를 하고 있다:
Value CHAR(4) Storage Required VARCHAR(4) Storage Required
'' ' ' 4 bytes '' 1 byte
'ab' 'ab ' 4 bytes 'ab' 3 bytes
'abcd' 'abcd' 4 bytes 'abcd' 5 bytes

:::MySQL Korea:::
'abcdefgh' 'abcd' 4 bytes 'abcd' 5 bytes
테이블의 마지막 줄에서 보이는 값들은 스트릭트 모드를 사용하지 않았을 경우에만 적용되는 것임을 알아두자; 만일 MySQL이 스
트릭트 모드를 구동하고 있다면, 컬럼 길이를 초과하는 값은 저장되지 않으며, 에러가 발생하게 된다.
만일 주어진 값이 CHAR(4) 및 VARCHAR(4) 컬럼에 저장된다고 하더라도, 그 컬럼에서 추출되는 값들이 항상 동일한 것은 아닌
데, 그 이유는 데이터를 추출하기 전에 CHAR 컬럼에서 트레일링 스페이스를 삭제하기 때문이다. 아래의 예문은 이러한 차이점을
보여 주는 것이다:
mysql> CREATE TABLE vc (v VARCHAR(4), c CHAR(4));
mysql> INSERT INTO vc VALUES ('ab ', 'ab ');
mysql> SELECT CONCAT('(', v, ')'), CONCAT('(', c, ')') FROM vc;
+---------------------+---------------------+
| CONCAT('(', v, ')') | CONCAT('(', c, ')') |
+---------------------+---------------------+

:::MySQL Korea:::
| (ab ) | (ab) |
+---------------------+---------------------+
CHAR 및 VARCHAR 컬럼에 있는 값들은 컬럼에 할당된 문자 셋과 콜레션에 따라서 저장 및 비교가 된다.
모든 MySQL 콜레션은 PADSPACE 타입이라는 점을 알아두자. 이것은 MySQL의 모든 CHAR 및 VARCHAR 값들은 어떠한 트
레일링 스페이스와는 상관 없이 비교된다는 것을 의미하는 것이다. 예를 들면:
mysql> CREATE TABLE names (myname CHAR(10), yourname VARCHAR(10));
mysql> INSERT INTO names VALUES ('Monty ', 'Monty ');
mysql> SELECT myname = 'Monty ', yourname = 'Monty ' FROM names;
+--------------------+----------------------+
| myname = 'Monty ' | yourname = 'Monty ' |
+--------------------+----------------------+
| 1| 1|

:::MySQL Korea:::
+--------------------+----------------------+
이것은 모든 MySQL 버전에 공통으로 적용되는 사항임을 알아 두자.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.4.2. BINARY 및 VARBINARY 타입
11.4. 스트링 타입 BINARY 및 VARBINARY 타입은 CHAR 및 VARCHAR과 유사하지만, 비-바이너리 스트링이 아닌 바이너리 스트링을 가진다
11.4.2 BINARY 및 VARBINARY 타입 는 점은 차이가 있다. 즉, 이것들은 문자 스트링이 아닌 바이트 스트링을 가진다. 이것은 이것들이 문자 셋을 가지지 않으며, 정렬
및 비교를 숫자 값을 기반을 실행한다는 것을 의미한다.
최대 허용 길이는 CHAR 및 VARCHAR의 것과 동일하지만, BINARY 및 VARBINARY에 대한 길이는 문자가 아닌 바이트로 지정

된다는 점이 다르다.
BINARY 및 VARBINARY 데이터 타입은 CHAR BINARY 및 VARCHAR BINARY 데이터 타입과는 확실히 구분이 된다. 후자
의 경우, BINARY의 속성은 컬럼을 바이너리 스트링 컬럼으로 취급되도록 하지는 않는다. 대신에, 이 속성은 컬럼의 문자 셋에 대
한 콜레션을 사용하도록 만들며, 컬럼 자체는 바이너리 바이트 스트링이 아닌 비 바이너리 문자 스트링을 가지게 된다. 예를 들면,
CHAR(5) BINARY는 CHAR(5) CHARACTER SET latin1 COLLATE latin1_bin 형태로 취급되며, 디폴트 문자 셋은 latin1라
는 가정을 하게 된다. 이것은 BINARY(5)과는 다른 것인데, 후자의 경우는 어떠한 문자 셋 또는 콜레션을 가지지 않는 5-바이트
바이너리 스트링을 저장한다.
BINARY 값이 저장될 때에는, 지정된 길이를 맞추기 위해 오른쪽에 스페이스를 집어 넣게 된다. 패드(pad) 값과 처리되는 방식은
버전에 따라 다르다:
● MySQL 5.0.15 이후에는, 패드 값은 0x00 (zero byte)가 된다. 삽입 동작에서는 오른쪽에 0x00을 가지고 값이 추가되

:::MySQL Korea:::
며, 선택을 할 때에는 어떠한 트레일링 바이트도 제거가 되지 않는다. 모든 바이트는 비교 연산에서 의미를 가지며,
ORDER BY 및 DISTINCT 동작에서도 의미를 갖는다. 0x00 바이트 및 스페이스는 비교 연산에서 서로 다르게 취급되며,
0x00 < 스페이스의 형태를 갖는다.
Example: BINARY(3) 컬럼의 경우, 'a '는 삽입이 될 때 'a ￦0'가 된다. 'a￦0'를 삽입하면 'a￦0￦0'가 된다. 이렇게 삽
입된 값들은 선택이 될 때 변경되지 않은 값을 그대로 가지게 된다.
● MySQL 5.0.15 이전에는 , 패드 값은 스페이스가 된다. 값을 삽입을 할 때에는 오른쪽에 스페이스를 넣게 되고, 그 값을 선
택할 경우에는 트레일링 스페이스가 제거가 된다. 트레일링 스페이스는 비교 연산에서 무시가 되는데, ORDER BY 및
DISTINCT 연산에서도 마찬가지가 된다. 0x00 바이트 및 스페이스는 비교 연산에서 서로 다르게 취급되며, 0x00 < 스
페이스의 형태를 갖는다.
Example: BINARY(3) 컬럼의 경우, 'a '은 삽입이 되면 'a '가 되고, 선택이 이루어 지면 'a' 가 된다. 'a￦0'을 삽입하면 'a
￦0 '가 되고, 선택을 하게 되면 'a￦0'가 된다.
VARBINARY의 경우, 삽입 동작에서 패딩(padding)은 일어나지 않으며 선택을 하는 경우에도 어떠한 바이트도 제거되지
(stripped) 않는다. 모든 바이트는 비교 연산에서 의미를 가지며, ORDER BY 및 DISTINCT 연산에서도 마찬가지가 된다. 0x00
바이트 및 스페이스는 비교 연산에서 서로 다르며, 0x00 < 스페이스 형태가 된다. (예외 사항: MySQL 5.0.3 이전 버전의 경
우, 값을 저장을 할 때 트레일링 스페이스가 제거가 된다. MySQL 5.0.15 이전 버전의 경우, 트레일링되는 0x00 바이트는
ORDER BY 연산에 대해서는 제거가 된다.)
Note: InnoDB 스토리지 엔진은 MySQL 5.0.18 버전까지 계속해서 BINARY 및 VARBINARY 컬럼 값에 트레일링 스페이스를 계
속 보관을 한다. MySQL 5.0.19 버전 이후에는, InnoDB는 다른 스토리지 엔진과 마찬가지로 트레일링 스페이스 문자를 비교 연산
을 하는데 사용한다.
트레일링 패드 바이트가 제거되거나 비교 연산에서 그것들을 무시하는 경우에 대해서는, 만일 하나의 컬럼이 유니크 값을 요구하

:::MySQL Korea:::
는 인덱스를 가지고 있다면, 트레일링 패드 바이트의 숫자와 다른 것만을 컬럼 값 안으로 삽입하는 동작을 하면 중복-키
(duplicate-key) 에러가 발생하게 된다. 예를 들면, 만일 테이블이 'a'를 가지고 있다면, 'a￦0'를 저장하고자 하는 시도는 중복-
키 에러를 야기하게 된다.
만약에 여러분이 바이너리 데이터를 저장하기 위해 BINARY 데이터 타입을 사용하고자 하고 저장된 값과 정확히 같은 값을 추출해
야 하는 경우라면, 위의 패딩 및 스트라이핑(stripping) 특성을 주의 깊게 고려해야 한다. 아래의 예문은 BINARY 값에 대한
0x00-패딩이 컬럼 값 비교 연산에 어떻게 영향을 주는지를 보여 주는 것이다:
mysql> CREATE TABLE t (c BINARY(3));
mysql> INSERT INTO t SET c = 'a';
mysql> SELECT HEX(c), c = 'a', c = 'a￦0￦0' from t;
+--------+---------+-------------+
| HEX(c) | c = 'a' | c = 'a￦0￦0' |
+--------+---------+-------------+
| 610000 | 0| 1|

:::MySQL Korea:::
+--------+---------+-------------+
만일 추출된 값이 패딩이 되지 않은 지정된 값과 정확히 같아야 한다면, VARBINARY 또는 BLOB 데이터 타입 중의 하나를 대신
사용하는 것이 더 좋을 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.4.3. BLOB 및 TEXT 타입
11.4. 스트링 타입 BLOB는 다양한 데이터 크기를 가질 수 있는 대형 바이너리 오브젝트이다. BLOB 타입으로는 TINYBLOB, BLOB,
11.4.3 BLOB 및 TEXT 타입 MEDIUMBLOB, 그리고 LONGBLOB가 있다. 각각의 타입들은 저장할 수 있는 최대 크기에서만 차이점을 가진다. TEXT 타입에
는 TINYTEXT, TEXT, MEDIUMTEXT, 그리고 LONGTEXT가 있다. 이것들은 BLOB 타입들과 대응되며 동일한 최대 길이 및
스토리지 요구 사항을 갖는다. Section 11.5, “데이터 타입 스토리지 요구 사항”을 참조할 것. 데이터가 저장되거나 추출되는 도
중에는 TEXT 또는 BLOB 컬럼에 대해서 어떠한 문자 크기 변환도 일어나지 않는다.
BLOB 컬럼은 바이너리 스트링(바이트 스트링) 형태로 취급된다. TEXT 컬럼은 비-바이너리 스트링(문자 스트링) 형태로 취급된
다. BLOB 컬럼은 문자 셋을 가지고 있지 않으며, 정렬 및 비교 연산은 컬럼 값에 있는 바이트의 숫자 값을 근거로 처리한다.
TEXT 컬럼은 문자 셋을 가지며, 문자 셋의 콜레션을 기반으로 값을 저장 및 비교하게 된다.
만일 TEXT 컬럼에 인덱스가 되어 있다면, 인덱스 엔트리 비교 연산은 마지막 부분에 스페이스가 패드 된다. 이것이 의미하는 것
은, 만일 인덱스가 유니크 값을 요구한다면, 트레일링 스페이스의 숫자와 다른 값에 대해서는 중복-키 에러가 발생한다는 것을 말
하는 것이다. 예를 들면, 만일 테이블이 'a'를 가지고 있다면, 'a '를 저장하고자 하는 시도는 중복-키 에러를 발생시키게 된다. 이것
은 BLOB 컬럼에 대해서는 적용되지 않는다.
서버가 스트릭트 모드를 구동하고 있지 않을 때, 만일 여러분이 데이터 타입의 최대 길이를 초과하는 BLOB 또는 TEXT 컬럼에 어
떤 값을 할당하고자 한다면, 그 값은 지정된 길이에 맞게 잘려 진다(truncated). 만일 잘리게 되는 문자가 스페이스가 아니라면, 경
고문이 나오게 된다. 여러분은 경고가 아닌 에러가 발생하게끔 해서 그 값을 거부하도록 만들 수가 있다. Section 5.2.5, “서버

:::MySQL Korea:::
SQL 모드”를 참조할 것.
대부분의 경우, 여러분은 BLOB 컬럼을 원하는 크기 만큼을 처리할 수 있는 VARBINARY 컬럼으로 생각을 할 수가 있다. 비슷하
게, TEXT 컬럼에 대해서도 VARCHAR 컬럼 형태로 생각할 수가 있다. BLOB 및 TEXT는 아래와 같은 방식에서는
VARBINARY 및 VARCHAR과 차이가 나타난다:
● 데이터를 저장 또는 추출할 때에는 BLOB 및 TEXT 컬럼에 대해서는 트레일링-스페이스 삭제를 할 수가 없다. MySQL
5.0.3 이전 버전의 경우, 이것은 VARBINARY 및 VARCHAR과 차이가 있는데, 그 이유는 트레일링 스페이스가 데이터를
저장할 때 삭제되기 때문이다.
TEXT는 비교 연산을 할 때 비교되는 오브젝트에 맞도록 스페이스가 확장되는데, 이것은 CHAR 및 VARCHAR과 동일하
다는 것을 주의한다.
● BLOB 및 TEXT 컬럼에 있는 인덱스의 경우, 반드시 인덱스 프리픽스(prefix) 길이를 지정해 주어야 한다. CHAR 및
VARCHAR의 경우, 프리픽스 길이는 옵션 사항이다. Section 7.4.3, “컬럼 인덱스”를 참조할 것.
● BLOB 및 TEXT 컬럼은 DEFAULT 값을 가질 수가 없다.
LONG 및 LONG VARCHAR은 MEDIUMTEXT 데이터 타입에 매핑된다. 이것은 호환성을 위한 기능이다. 만일 여러분이
BINARY 속성을 TEXT 데이터 타입과 함께 사용한다면, 그 컬럼은 컬럼 문자 셋에 대한 바이너리 콜레션을 할당 받게 된다.
MySQL Connector/ODBC은 BLOB 값을 LONGVARBINARY 형태로 정의하고 그리고 TEXT 값에 대해서는LONGVARCHAR

형태로 정의한다.
BLOB 및 TEXT 값을 매우 크게 할 수가 있기 때문에, 이것을 사용하는 데에는 몇 가지 제약 사항이 있게 된다:
● 컬럼의 맨 처음 max_sort_length 바이트만이 정렬 될 때 사용된다. max_sort_length의 디폴트 값은 1024 이다. 이 값은

:::MySQL Korea:::
mysqld 서버를 시작할 때 --max_sort_length=N 옵션을 사용해서 변경 시킬 수가 있다. Section 5.2.2, “서버 시스템
변수”를 참조할 것.
서버의 런 타임시에 max_sort_length의 값을 증가 시킴으로써 정렬 또는 그룹 연산 중에 보다 많은 바이트가 의미를 가

질 수 있도록 만들 수가 있다. 모든 클라이언트는 자신의 세션 max_sort_length 변수의 값을 변경 시킬 수가 있다:
mysql> SET max_sort_length = 2000;
mysql> SELECT id, comment FROM t
-> ORDER BY comment;
max_sort_length 바이트 보다 큰 바이트를 의미 있게 하고자 할 때 큰(long) 값을 가지고 있는 BLOB 또는 TEXT 컬럼

상에서 GROUP BY 또는 ORDER BY를 사용할 수 있는 또 다른 방법은 컬럼의 값을 고정-길이 오브젝트로 변환하는 것
이다. 이렇게 하는 표준 방식은 SUBSTRING() 함수를 사용하는 것이다. 예를 들면, 아래의 명령문은 정렬을 하기 위해
서 comment 컬럼에서 2000 바이트를 가져 오도록 만든다:
mysql> SELECT id, SUBSTRING(comment,1,2000) FROM t
-> ORDER BY SUBSTRING(comment,1,2000);
● BLOB 또는 TEXT 오브젝트의 최대 크기는 자신들의 타입에 의해 결정되지만, 클라이언트와 서버간에 전달할 수 있는 실
제 최대 크기는 사용 가능한 메모리의 크기와 통신 버퍼의 크기에 달려 있다. max_allowed_packet 변수의 값을 변경해서
메시지 버퍼의 크기를 변경 시킬 수는 있으나, 이러한 변수 값 조정은 클라이언트 및 서버 양쪽 모두에서 해야 한다. 예를
들면, mysql 및 mysqldump는 모두 클라이언트 쪽의 max_allowed_packet 값을 변경 시킨다. Section 7.5.2, “서버 파
라미터 튜닝”, Section 8.6, “mysql — MySQL 명령어-라인 툴”, 그리고 Section 8.11, “mysqldump — 데이터 베
이스 백업 프로그램”을 참조할 것.
각각의 BLOB 또는 TEXT 값은 별도로 할당된 오브젝트에 의해 표현 된다. 이것은 다른 모든 데이터 타입과는 반대인데, 그 이유
는 테이블이 오픈될 때 스토리지가 컬럼 별로 한번씩 할당되기 때문이다.

:::MySQL Korea:::
어떤 경우에는, 미디어 파일과 같은 바이너리 데이터를 BLOB 또는 TEXT 컬럼에 저장하는 것이 바람직할 때가 있다. 여러분은 이
러한 데이터를 처리하는데 있어서 MySQL의 스트링 처리 함수를 사용하는 것이 유용하다는 점을 알게 될 것이다. Section 12.3,
“스트링 함수”를 참조.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.4.4. ENUM 타입
11.4. 스트링 타입 ENUM은 테이블 생성 시점에 컬럼 지정문에서 명확하게 계산된 허용 값 리스트에서 선택이 된 값을 사용하는 스트링 오브젝트이
11.4.4 ENUM 타입 다.
그 값은 어떤 환경에서는 빈 스트링 (empty string) ('') 또는 NULL 값이 될 수도 있다:
● 만일 여러분이 유효하지 않은 값을 ENUM에 삽입한다면 (즉, 허용된 값 리스트에 없는 스트링), 빈 스트링이 특별 에러 값

형태로 대신 삽입된다. 이 스트링은 숫자 값으로 0 을 가진다는 사실로 인해 “일반적인(normal)” 빈 스트링과 구분이 된
다. 나중에 보다 자세히 다루기로 한다.
만일 스트릭트 SQL 모드가 활성화 되어 있다면, 유효하지 않은 ENUM 값을 삽입하고자 하는 시도는 에러를 발생 시킨
다.
● 만일ENUM 컬럼이 NULL을 허용하도록 선언되었다면, NULL 값은 그 컬럼에 대해서 유효한 값이 되며, 그리고 디폴트 값
은 NULL이 된다. 만일 ENUM 컬럼이 NOT NULL로 선언되었다면, 이것의 디폴트 값은 허용된 값 리스트의 첫 번째 요소
(element)가 된다.
각각의 계산(enumeration) 값들은 인덱스를 가지고 있다:
● 컬럼 지정문에 있는 사용 가능 요소 리스트에서 가져오는 값은 1 부터 시작을 해서 번호를 매기게 된다.

● 빈 스트링 에러 값의 인덱스 값은 0 이다. 이것은 아래의 SELECT 명령문을 사용해서 유효하지 않은 ENUM 값이 어디에
할당되었는지를 찾을 수 있다는 것을 의미한다:

:::MySQL Korea:::
• mysql> SELECT * FROM tbl_name WHERE enum_col=0;
● NULL 값의 인덱스는 NULL이다.

● 여기에서 말하는 “인덱스(index)”는 계산 값(enumeration value) 리스트 내에 있는 위치만을 참조한다. 이것은 테이
블 인덱스와는 상관이 없다.
예를 들면, ENUM('one', 'two', 'three') 형태로 지정된 컬럼은 아래에 있는 값들 중에 어떠한 것들도 가질 수가 있다. 각각의 값에
대한 인덱스 역시 아래에 있다:
Value Index
NULL NULL
'' 0
'one' 1
'two' 2
'three' 3
계산(enumeration)은 최대 65,535 요소(elements)를 가질 수 있다.
트레일링 스페이스는 테이블이 생성될 때 테이블 정의문에 있는 ENUM 맴버 값에서 자동으로 삭제된다.
데이터를 추출할 때에는, ENUM 컬럼에 저장된 값은 컬럼 정의문에서 사용된 문자 크기를 사용해서 출력이 된다. ENUM 컬럼에
는 문자 셋과 콜레션이 할당될 수 있다는 점을 알아두자. 바이너리 또는 문자 크기를 구분하는 콜레션의 경우, 문자의 크기는 컬럼

:::MySQL Korea:::
에 값을 할당할 때 그 고려가 된다.
만일 숫자 문맥에 있는 ENUM 값을 추출하는 경우에는, 그 컬럼 값의 인덱스가 리턴된다. 예를 들면, 여러분은 아래와 같이

ENUM 컬럼에서 숫자 값을 추출할 수가 있다:
mysql> SELECT enum_col+0 FROM tbl_name;
만일 어떤 숫자를 ENUM 컬럼에 저장한다면, 그 숫자는 인덱스 형태로 취급되며, 저장된 값은 그 인덱스를 가지고서 계산
(enumeration) 맴버가 된다. (하지만, 이것은 LOAD DATA과는 동작을 하지 않는데, 이것은 모든 입력 값을 스트링 형태로 취급
하기 때문이다.) 숫자와 같은 계산 값을 가지고 ENUM 컬럼을 정의하는 것은 권고할 만한 것이 아니다. 예를 들면, 아래에 있는 컬
럼은 스트링 값 '0', '1', 그리고 '2'를 가지는 계산 멤버를 가지고 있지만, 숫자 인덱스 값이 1, 2, 그리고 3이 된다:
numbers ENUM('0','1','2')
ENUM 값은 컬럼 지정문에서 계산 멤버가 리스트 되어 있는 순서대로 저장된다. (달리 말하면, ENUM 값은 자신의 인덱스 번호
에 따라서 저장된다.) 예를 들면, ENUM('a', 'b')에 대해서는 'a' 가 'b' 보다 전에 정렬이 되지만, ENUM('b', 'a')의 경우에는 'b'가
'a' 보다 전에 정렬이 된다. 빈 스트링은 비어 있지 않은 스트링 보다 앞서서 정렬이 되고, NULL 값은 다른 모든 계산 값 보다 먼저
정렬이 된다. 예상하지 못한 결과를 피하기 위해서는, ENUM 리스트를 알파벳 순서로 지정을 한다. 또한, 컬럼이 인덱스 번호가 아
닌 사전적 순서로 정렬되도록 하기 위해서는 GROUP BY CAST(col AS CHAR) 또는 GROUP BY CONCAT(col)를 사용할 수
도 있다.
만일 ENUM 컬럼에 대해서 모든 가능한 값이 어떤 것이 있는지를 알아보고자 한다면, SHOW COLUMNS FROM tbl_name
LIKE enum_col 를 사용하고 그 결과로 나오는 Type 컬럼의 ENUM 정의문을 파스(parse) 하면 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.4.5. SET 타입
11.4. 스트링 타입 SET은 0 또는 그 이상의 값을 가질 수 있는 스트링 오브젝트로서, 각각의 값들은 테이블이 생성될 때 지정된 허용 값 리스트에서
11.4.5 SET 타입 선택 되어야 한다. 여러 개의 셋 멤버로 구성된 SET 컬럼은 콤마 (‘,’)로 각 맴버를 구분한다. 따라서, SET 맴버는 자체적으로
콤마를 가질 수가 없다.
예를 들면, SET('one', 'two') NOT NULL로 지정된 컬럼은 아래의 값 중에 어떤 것도 가질 수가 있다:
''
'one'
'two'
'one,two'
SET은 최대 64개의 서로 다른 맴버를 가질 수가 있다.
트레일링 스페이스는 테이블이 생성될 때 테이블 정의문에 있는 SET 맴버에서 자동으로 삭제가 된다.
추출이 될 때에는, SET 컬럼에 저장되어 있는 값은 컬럼 정의문에서 사용된 문자 크기를 사용해서 출력이 된다. SET 컬럼에는 문
자 셋과 콜레션이 할당될 수 있다는 점을 알아두자. 바이너리 또는 문자 크기를 구분하는 콜레션의 경우, 문자 크기는 컬럼에 값이

:::MySQL Korea:::
할당될 때 고려가 된다.
MySQL은 SET 값을 번호 순서대로(numerically) 저장을 하는데, 첫 번째 셋 맴버에 해당하는 것이 가장 낮은 순서 비트를 갖는

다. 만일 숫자 문맥에 있는 SET 값을 추출한다면, 추출된 값은 컬럼 값을 구성하는 셋 멤버와 대응하는 비트 셋을 가지게 된다. 예
를 들면, 아래와 같이 SET 컬럼에서 숫자 값을 추출할 수가 있다:
mysql> SELECT set_col+0 FROM tbl_name;
만일 어떤 숫자가 SET 컬럼에 저장이 된다면, 해당 숫자의 바이너리 표현식에 있는 셋은 컬럼 값에 있는 셋 멤버를 결정하게 된다.
SET('a','b','c','d') 형태로 지정된 컬럼의 경우, 해당 멤버는 아래의 10진수와 바이너리 값을 가지게 된다:
SET Member Decimal Value Binary Value
'a' 1 0001
'b' 2 0010
'c' 4 0100
'd' 8 1000
만일 여러분이 이 컬럼에 9에 해당하는 값을 할당한다면, 그것은 바이너리로 1001이 되며, 따라서 첫 번째와 네 번째의 SET 값 멤
버 'a' 및 'd'가 선택이 되고 그 결과 값은 'a,d'가 된다.
하나 이상의 SET 요소(element)를 가지는 값에 대해서는, 그 값에 요소를 삽입할 때 순서는 중요하지가 않게 된다. 또한, 그 값 안
에 주어진 요소가 몇 번이나 반복되는지도 중요하지가 않게 된다. 나중에 그 값을 추출할 때, 그 값에 있는 각각의 요소들은 한번
씩 나타나며, 이때 각 요소들은 테이블이 생성되는 시점에 지정된 순서에 따라서 나타나게 된다. 예를 들면, 어떤 컬럼이 SET

:::MySQL Korea:::
('a','b','c','d')과 같이 지정되었다고 가정하자:
mysql> CREATE TABLE myset (col SET('a', 'b', 'c', 'd'));
만일 'a,d', 'd,a', 'a,d,d', 'a,d,a', 그리고 'd,a,d'를 삽입한다면:
mysql> INSERT INTO myset (col) VALUES
-> ('a,d'), ('d,a'), ('a,d,a'), ('a,d,d'), ('d,a,d');
Records: 5 Duplicates: 0 Warnings: 0
이렇게 하면, 값을 추출할 때 모든 값들은 'a,d' 형태로 나오게 된다:
mysql> SELECT col FROM myset;
+------+
| col |
+------+
| a,d |
| a,d |
| a,d |
| a,d |

:::MySQL Korea:::
| a,d |
+------+
만일 SET 컬럼에 지원되지 않는 값을 설정한다면, 그 값은 무시가 되고 경고문이 나오게 된다:
mysql> INSERT INTO myset (col) VALUES ('a,d,d,s');
Query OK, 1 row affected, 1 warning (0.03 sec)
mysql> SHOW WARNINGS;
+---------+------+------------------------------------------+
| Level | Code | Message |
+---------+------+------------------------------------------+
| Warning | 1265 | Data truncated for column 'col' at row 1 |
+---------+------+------------------------------------------+
mysql> SELECT col FROM myset;

:::MySQL Korea:::
+------+
| col |
+------+
| a,d |
| a,d |
| a,d |
| a,d |
| a,d |
| a,d |
+------+
만일 스트릭트 SQL 모드가 활성화 되어 있다면, 유효하지 못한 값을 SET 값에 삽입하고자 하는 시도는 에러를 발생 시키게 된다.
SET 값은 순서적으로 저장이 된다. NULL 값은 비(non)-NULL SET 값 보다 먼저 정렬이 된다.
일반적으로, 여러분은 SET 값을 검색하기 위해서 FIND_IN_SET() 함수 또는 LIKE 연산자를 사용할 수가 있다:
mysql> SELECT * FROM tbl_name WHERE FIND_IN_SET('value',set_col)>0;
mysql> SELECT * FROM tbl_name WHERE set_col LIKE '%value%';

:::MySQL Korea:::
첫 번째 명령문은 set_col 이 value 셋 멤버를 가지고 있는 열을 찾는다. 두 번째 명령문도 비슷하지만, 정확히 같지는 않다: 두 번
째 명령문은 set_col 이 value 가 다른 셋 멤버의 서브 스트링이라 하더라도 이 값이 있는 열을 모두 찾는다.
아래의 명령문 역시 유효한 것들이다:
mysql> SELECT * FROM tbl_name WHERE set_col & 1;
mysql> SELECT * FROM tbl_name WHERE set_col = 'val1,val2';
위의 명령문 중에 첫 번째 것은 첫 번째 셋 멤버를 가지고 있는 값을 찾는다. 두 번째 명령문은 정확히 일치가 되는 값을 검색한다.

두 번째 타입의 비교 연산을 주의를 하기 바란다. 셋 값 'val1,val2'를 비교하면 'val2,val1'를 비교할 때와는 다른 값이 나오게 된
다. 컬럼 정의문에 리스트 되어 있는 동일 순서대로 값을 지정해 주어야 한다.
만일 SET 컬럼에 대해서 가능한 모든 값을 알아 보고자 한다면, SHOW COLUMNS FROM tbl_name LIKE set_col 을 사용하고
그 결과로 나오는 Type 컬럼에서 SET 정의문을 파스(parse)한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.5. 데이터 타입 스토리지 요구 사항
11. 데이터 타입 MySQL이 지원하는 각각의 데이터 타입에 대한 스토리지 요구 사항은 아래와 같다.
11.5. 데이터 타입 스토리지 요구 사항 MyISAM 테이블에 있는 열의 최대 크기는 65,534 바이트이다. 각 BLOB 및 TEXT 컬럼은 단지 5에서 9 바이트만을 차지한다.
11.5 데이터 타입 스토리지 요구 사항

Important: NDBCluster 스토리지 엔진을 사용하는 테이블의 경우, 스토리지 요구 사항을 계산할 때 고려해야 하는 요소로서 4-
바이트 얼라인먼트(4-byte alignment)가 존재 한다. 이것은 모든 NDB 데이터 스토리지 엔진이 여러 개의 4 바이트 안에서 실행
된다는 것을 의미한다. 따라서, 스토리지에 대해서 15 바이트를 갖는 컬럼 값 —NDB가 아닌 다른 스토리지 엔진을 사용하는 테이
블에서— 의 은, NDB 테이블에서는 16 바이트가 필요하게 된다. 이러한 요구 사항은 이 섹션에서 설명되는 다른 모든 고려 사항과
더불어 적용이 된다. 예를 들면, NDBCluster 테이블에서는, TINYINT, SMALLINT, MEDIUMINT, 그리고 INTEGER (INT) 컬
럼 타입 각각은 레코드 당 4 바이트를 요구한다.
숫자 타입에 대한 스토리지 요구 사항
Data Type Storage Required
TINYINT 1 byte
SMALLINT 2 bytes
MEDIUMINT 3 bytes
INT, INTEGER 4 bytes
BIGINT 8 bytes
FLOAT(p) 4 bytes if 0 <= p <= 24, 8 bytes if 25 <= p <= 53
FLOAT 4 bytes
DOUBLE [PRECISION], REAL 8 bytes
DECIMAL(M,D), NUMERIC(M,D) Varies; see following discussion

:::MySQL Korea:::
BIT(M) approximately (M+7)/8 bytes
DECIMAL (그리고 NUMERIC)에 대한 스토리지 요구 사항은 버전에 따라 다르다:

MySQL 5.0.3 버전 이후에는, DECIMAL 컬럼에 대한 값은 9개의 10진 자리수를 4 바이트로 묶는 바이너리 포맷을 사용해서 표
현된다. 각 값에 대한 정수 및 분수 부분에 대한 스토리지는 개별적으로 결정된다. 여러 개의 9 자릿수는 4 바이트를 요구하며, 그
리고 “레프트오버(leftover)” 자릿수는 4 바이트의 분수를 요구한다. 초과 자릿수에 대한 스토리지는 아래의 테이블에서 나타나
있다:
Leftover Digits Number of Bytes
0 0
1 1
2 1
3 2
4 2
5 3
6 3
7 4
8 4
9 4
MySQL 5.0.3 버전 이전에는, DECIMAL 컬럼은 스트링 형태로 표현되며 스토리지 요구 사항은: D > 0일 경우에는,M+2 바이
트이고, D = 0일 경우에는, (D+2, if M < D) M+1 바이트가 된다.
날짜 및 시간 타입에 대한 스토리지 요구 사항
DATE 3 bytes

:::MySQL Korea:::
DATETIME 8 bytes
TIMESTAMP 4 bytes
TIME 3 bytes
YEAR 1 byte
스트링 타입에 대한 스토리지 요구 사항
CHAR(M) M bytes, 0 <= M <= 255
Prior to MySQL 5.0.3: L + 1 bytes, where L <= M and 0 <= M <= 255.
VARCHAR(M) MySQL 5.0.3 and later: L + 1 bytes, where L <= M and 0 <= M <= 255 or
L + 2 bytes, where L <= M and 256 <= M <= 65535 (see note below).
BINARY(M) M bytes, 0 <= M <= 255
Prior to MySQL 5.0.3: L + 1 bytes, where L <= M and 0 <= M <= 255.
VARBINARY(M) MySQL 5.0.3 and later: L + 1 bytes, where L <= M and 0 <= M <= 255 or
L + 2 bytes, where L <= M and 256 <= M <= 65535 (see note below).
TINYBLOB, TINYTEXT L+1 byte, where L < 28
BLOB, TEXT L+2 bytes, where L < 216
MEDIUMBLOB, MEDIUMTEXT L+3 bytes, where L < 224
LONGBLOB, LONGTEXT L+4 bytes, where L < 232
1 or 2 bytes, depending on the number of enumeration values (65,535 values

ENUM('value1','value2',...)
maximum)
1, 2, 3, 4, or 8 bytes, depending on the number of set members (64 members

SET('value1','value2',...)
maximum)
CHAR, VARCHAR, 그리고 TEXT 타입의 경우, 앞의 테이블에 있는 값 L 및 M 은 문자의 수로 해석이 되고, 그리고 컬럼 지정문
에 있는 이러한 타입의 길이는 문자의 숫자를 가리키게 된다. 예를 들면, TINYTEXT 값을 저장하기 위해서는 L 문자와 더불어 1
바이트가 더 필요하게 된다.

:::MySQL Korea:::
VARCHAR, VARBINARY, 그리고 BLOB 및 TEXT 타입은 변수-길이 타입이다. 각각의 경우, 스토리지 요구 사항은 아래의 요소
들에 관련을 갖는다:
● 컬럼 값의 실제 길이
● 컬럼의 최대 가능 길이
● 컬럼용으로 사용된 문자 셋
예를 들면, VARCHAR(10) 컬럼은 최대 길이 10의 스트링을 갖는다. 이 컬럼이 latin1 문자 셋 (문자 당 1 바이트)을 사용한다고
가정하면, 필요한 실제 스토리지는 스트링 (L)의 길이에, 스트링의 길이를 기록하기 위한 1 바이트가 추가 된다. 'abcd의 경우, , L
은 4 이고 스토리지 요구 사항은 5 바이트가 된다. 만일 동일한 컬럼이 VARCHAR(500)로 선언되었다면, 스트링 'abcd'는 4 + 2
= 6 바이트를 필요로 한다. 프리픽스에 대해서는 1 바이트가 아닌 2 바이트가 요구되는데, 그 이유는 컬럼의 길이가 255 문자 보
다 크기 때문이다.
특정 CHAR, VARCHAR, 또는 TEXT 컬럼 값을 저장하기 위해 사용되는 바이트의 숫자를 계산하기 위해서는, 반드시 그 컬럼을
위해 사용된 문자 셋을 고려해야 한다. 특히, utf8 Unicode 문자 셋을 사용할 경우에는, 반드시 모든 utf8 문자 셋이 동일한 바이트
숫자를 가지는 것이 아니라는 점을 기억해야 한다. Section 10.7, “Unicode Support”를 참조.
Note: MySQL 5.0.3 및 이후 버전에서는, VARCHAR 또는 VARBINARY 컬럼에 대한 유효한 최대 길이는 65,532가 된다.
MySQL 5.0.3 이후에는, NDBCLUSTER 엔진은 고정-길이 컬럼만을 지원한다. 이것은 MySQL Cluster에 있는 테이블에서 나오
는 VARCHAR 컬럼은 아래와 같이 동작을 한다는 것을 의미한다:
● 만일 컬럼의 크기가 256 문자 보다 작다면, 컬럼은 열 별로 추가적인 1 바이트의 스토리지가 필요하게 된다.
● 만일 컬럼의 크기가 256 문자 이상일 경우, 컬럼은 추가적으로 열 당 2 바이트를 필요하게 된다.
문자 별로 요구되는 바이트의 숫자는 사용되는 문자 셋에 따라서 달라진다는 점을 알아 두자. 예를 들면, 만일 클러스터 테이블에
있는 VARCHAR(100) 컬럼이 utf8 문자 셋을 사용한다면, 각각의 문자는 3 바이트 스토리지를 필요로 한다. 이것은 그러한 컬럼
에 있는 각각의 레코드가 주어진 레코드에 실제로 저장되는 스트링의 길이에는 상관 없이 스토리지용으로 100 × 3 + 1 = 301 바
이트를 가진다는 것을 의미한다. utf8 문자 셋과 함께 NDBCLUSTER 스토리지 엔진을 사용하는 테이블의 VARCHAR(1000) 컬
럼의 경우에는, 각각의 레코드가 1000 × 3 + 2 = 3002 바이트의 스토리지를 사용하게 된다; 즉, 컬럼은 1,000 문자 크기가 되

:::MySQL Korea:::
며, 각각의 문자는 3 바이트 스토리지를 필요로 하고, 그리고 각각의 레코드는 2-바이트 만큼의 오버 헤드를 가지는데, 그 이유는
1,000 > 256 이기 때문이다.
BLOB 및 TEXT 타입은, 타입의 최대 가능 길이에 따라서, 컬럼 값의 길이를 저장하기 위해서 1, 2, 3, 또는 4 바이트를 사용하게
된다. Section 11.4.3, “BLOB 및 TEXT 타입”을 참조할 것.
TEXT 및 BLOB 컬럼은 NDB Cluster 스토리지 엔진에서는 다르게 구현이 되는데, 이 클러스터 엔진에서는 TEXT 컬럼에 있는
각각의 열은 두 개의 서로 다른 부분으로 구성이 된다. 이 부분 중의 하나는 길이가 고정 (256 bytes)되며, 실제로 원본 테이블에
저장이 된다. 다른 부분은 256 바이트가 초과되는 데이터로 구성이 되며, 이것은 숨겨진 테이블에 저장이 된다. 이 두 번째 테이블
에 있는 열은 크기가 항상 2,000 바이트가 된다. 이것은 만일 size <= 256 (size 는 열의 크기를 나타냄)일 경우에는 TEXT 컬
럼의 크기가 256이 된다는 것을 의미한다; 그렇지 않을 경우에는, 그 크기가 256 + size + (2000 – (size – 256) % 2000)가
된다.
ENUM 오브젝트의 크기는 서로 다른 계산(enumeration) 값의 숫자에 의해 측정된다. 1 바이트는 255개의 가능 값까지를 계산하
는데 사용된다 2 바이트는 256에서 65,535 사이의 가능 값을 계산하는데 사용된다. Section 11.4.4, “ENUM 타입”을 참조할
것.
SET 오브젝트의 크기는 서로 다른 셋 멤버의 숫자를 가지고 계산할 수가 있다. 만일 셋의 크기가 N이라면, 그 오브젝트는 (N
+7)/8 바이트를 저장할 수가 있고, 1, 2, 3, 4, 또는 8 바이트가 될 수가 있다. SET은 최대 64개의 멤버를 가질 수 있다.
Section 11.4.5, “SET 타입”을 참조할 것.

:::MySQL Korea:::
제목검색
11.6. 컬럼에 대한 올바른 타입 선택하기
최적의 스토리지에 대해서는, 모든 경우에 대해서 가장 정밀한 타입을 사용하도록 시도해야 한다. 예를 들면, 만일 어떤 정수 컬럼
11.6. 컬럼에 대한 올바른 타입 선택하기
이 1 에서 99999 사이의 값을 사용하고 있다면, MEDIUMINT UNSIGNED가 최적의 타입일 것이다. 필요로 하는 모든 값을 표시
11.6 컬럼에 대한 올바른 타입 선택하기
하기 위한 타입에 대해서, 이 타입이 최소의 스토리지를 사용한다.
MySQL 5.0.3 및 이후 버전에서 생성된 테이블은 DECIMAL 컬럼에 대해서는 새로운 스토리지 포맷을 사용한다. DECIMAL 컬럼
을 사용하는 모든 기본 연산 (+,-,*,/)은 65자리의 십진 자릿수 만큼의 정밀도를 가지고 실행된다. Section 11.1.1, “Overview
of Numeric Types”를 참조할 것.
MySQL 5.0.3 이전 버전의 경우, DECIMAL 값에서의 계산은 이중-정밀도 연산을 사용해서 실행된다. 만일 정밀도 보다는 실행
속도가 중요한 경우라면, DOUBLE 타입 정도면 충분할 것이다. 높은 정밀도에 대해서는, 항상 고정-소수점 타입을 변환 시켜서
BIGINT에 저장되도록 할 수가 있다. 이렇게 하면 모든 계산이 64 비트 정수를 사용할 수 있게끔 하며 그리고 필요할 경우에는 그
결과 값을 부동 소수점 값으로 환원 시킬 수도 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 11.7. 다른 데이터 베이스 엔진의 데이터 타입 사용하기
11. 데이터 타입 다른 벤더가 만든 SQL용으로 작성된 코드를 잘 활용하기 위해서, MySQL은 아래의 테이블에 나타난 것과 같이 데이터 타입을 서
11.7. 다른 데이터 베이스 엔진의 데이터 타입 로 매핑 시킨다. 이러한 매핑을 통해 다른 데이터 베이스 시스템에서 정의된 테이블을 쉽게 MySQL로 가져올 수가 있게 된다:
사용하기
11.7 다른 데이터 베이스 엔진의 데이터 타입 사용 Other Vendor Type MySQL Type
하기
BOOL, TINYINT
BOOLEAN TINYINT
CHAR VARYING(M) VARCHAR(M)
DEC DECIMAL
FIXED DECIMAL
FLOAT4 FLOAT
FLOAT8 DOUBLE
INT1 TINYINT
INT2 SMALLINT
INT3 MEDIUMINT
INT4 INT
INT8 BIGINT
LONG VARBINARY MEDIUMBLOB
LONG VARCHAR MEDIUMTEXT
LONG MEDIUMTEXT

:::MySQL Korea:::
MIDDLEINT MEDIUMINT
NUMERIC DECIMAL
데이터 타입 매핑은 테이블 생성 시점에 일어나며, 원래의 타입 지정문이 폐기된 후에 일어난다. 만일 다른 벤더가 사용하는 타입
을 가지고 테이블을 생성한 다음에 DESCRIBE tbl_name 명령문을 입력하게 된다면, MySQL은 이에 해당하는 동등한
(equivalent) MySQL 타입을 사용해서 테이블 구조를 출력한다. 예를 들면:
mysql> CREATE TABLE t (a BOOL, b FLOAT8, c LONG VARCHAR, d NUMERIC);

mysql> DESCRIBE t;
+-------+---------------+------+-----+---------+-------+
+-------+---------------+------+-----+---------+-------+
|a | tinyint(1) | YES | | NULL | |
|b | double | YES | | NULL | |
|c | mediumtext | YES | | NULL | |
|d | decimal(10,0) | YES | | NULL | |
+-------+---------------+------+-----+---------+-------+

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 12. 함수와 연산자
12. 함수와 연산자 12.1. 연산자
12 함수와 연산자 12.1.1. 연산자 우선 순위
12.1 연산자 12.1.2. 수식 평가에서 타입 변환
12.1.1 연산자 우선 순위 12.1.3. 비교 함수와 연산자

12.1.4. 논리 연산자
12.1.2 수식 계산에서의 타입 변환
12.2. 제어 플로우 함수
12.1.3 비교 함수와 연산자
12.3. 스트링 함수
12.1.4 논리 연산자
12.3.1. 스트링 비교 함수
12.2 제어 플로우 함수
12.4. 수치 함수
12.3 스트링 함수
12.4.1. 산술 연산자
12.4 숫자 함수
12.4.2. 수학 함수
12.4.1 산술 연산자
12.5. 날짜 및 시간 함수
12.4.2 수학 함수
12.6. MySQL이 사용하는 달력
12.5 날짜 및 시간 함수(1) 12.7. 전체 문장 검색 함수
12.5 날짜 및 시간 함수(2) 12.7.1. 불리안 전체 문장 검색
12.6 MySQL이 사용하는 달력 12.7.2. 쿼리 수식을 사용한 전체 문장 검색
12.7 전문 (Full-Text) 검색 함수 12.7.3. 전체 문장 스톱워드(Stopword)

12.7.4. 전체 문장 제약
12.7.5. 전체 문장 검색 튜닝
12.8. 캐스트(Cast) 함수 및 연산자
12.9. 기타 함수들
12.9.1. 비트 함수
12.9.2. 암호화 및 압축 함수
12.9.3. 정보 함수

:::MySQL Korea:::
12.9.4. 기타 함수들
12.10. GROUP BY 구문과 함께 사용하기 위한 함수 및 수정자(Modifier)
12.10.1. GROUP BY (집합) 함수
12.10.2. GROUP BY 수정자(Modifiers)
12.10.3. 숨겨진 필드를 갖는 GROUP BY 및 HAVING
수식은 SQL 명령문의 여러 곳에서 사용되는데, 예를 들면 SELECT 명령문의 ORDER BY 또는 HAVING 구문에서, SELECT,
DELETE, 또는 UPDATE 명령문의 WHERE 구문에서, 또는 SET 명령문에서 사용된다. 수식은 리터럴(literal) 값, 컬럼 값,
NULL, 빌트-인(built-in) 함수, 스토어드 함수, 사용자 정의 함수, 그리고 연산자를 사용해서 작성된다. 이 장에서는 MySQL에
서 수식을 작성하는데 사용할 수 있는 함수 및 연산자에 대해서 설명을 하겠다. 스토어드 함수 및 사용자 정의 함수에 대해서는
Chapter 17, 스토어드 프로시저 및 함수, 그리고 Section 24.2, “MySQL에 새로운 함수 추가하기” 부분에서 설명하기로 하겠
다.
NULL을 가지는 함수는 특정 함수 또는 연산자를 지정하지 않는 한 항상 NULL 값을 만들어 낸다.
Note: 디폴트로는, 함수 이름과 뒤에 따라 나오는 괄호 사이에는 화이트 스페이스를 두지 말아야 한다. 이것은 This helps the
MySQL 파서(parser)가 함수 호출과 함수의 이름과 동일한 이름을 사용하는 테이블 또는 컬럼 참조를 구분하는데 도움을 준다. 하
지만, 함수 인수 주변에 있는 스페이스는 허용된다.
서버를 구동 시킬 때 --sql-mode=IGNORE_SPACE 옵션을 사용하면 MySQL 서버로 하여금 함수 이름 다음에 스페이스를 사

용할 수 있도록 만들 수가 있다. (Section 5.2.5, “서버 SQL 모드”를 참조할 것.) 각각의 클라이언트 프로그램은
mysql_real_connect()에 대해서 CLIENT_IGNORE_SPACE 옵션을 사용함으로써 이러한 동작을 요구할 수가 있다. 어느 경우이
건 간에, 모든 함수 이름은 사용이 지정된 단어(reserved word)가 된다.
설명을 간단하게 하기 위해서, 이 장에서 보여주는 대부분의 예문들은 mysql 프로그램에서 나오는 결과를 간략한 형태로 보여 줄
것이다. 즉, 아래와 같은 형태가 아닌:
mysql> SELECT MOD(29,9);

+-----------+
| mod(29,9) |
+-----------+

:::MySQL Korea:::
| 2|
+-----------+
다음과 같은 형태를 대신 사용할 것이다:

-> 2

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.1. 연산자
12. 함수와 연산자 12.1.1. 연산자 우선 순위

12.1. 연산자 12.1.2. 수식 평가에서 타입 변
12.1 연산자 환
12.1.1 연산자 우선 순위 12.1.3. 비교 함수와 연산자
12.1.2 수식 계산에서의 타입 변환 12.1.4. 논리 연산자
12.1.3 비교 함수와 연산자

12.1.4 논리 연산자
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.1.1. 연산자 우선 순위
12. 함수와 연산자
12.1. 연산자 연산자 우선 순위는 아래와 같으며, 가장 낮은 것에서부터 가장 높은 것 순서로 되어 있다. 동일한 라인에 나와 있는 연사자들은 같
12.1.1 연산자 우선 순위 은 우선 순위를 갖는 것들이다.
:=
||, OR, XOR
&&, AND
NOT
BETWEEN, CASE, WHEN, THEN, ELSE
=, <=>, >=, >, <=, <, <>, !=, IS, LIKE, REGEXP, IN
&
<<, >>
-, +
*, /, DIV, %, MOD

:::MySQL Korea:::
- (unary minus), ~ (unary bit inversion)
BINARY, COLLATE
NOT에 대한 우선 순위는 MySQL 5.0.2 이후에 존재한다. 이전 버전, 또는 HIGH_NOT_PRECEDENCE SQL 모드가 활성화 되
어 있는 경우의 5.0.2 까지는, NOT의 우선 순위는 ! 연산자의 우선 순위와 같다. Section 5.2.5, “서버 SQL 모드” 를 참조.
연산자의 우선 순위는 수식에 있는 항(term)의 계산 순서를 결정한다. 위의 순서를 무시하고 그룹 항을 명확하게 지정하고자 한다
면, 괄호를 사용하면 된다. 예를 들면:
mysql> SELECT 1+2*3;
-> 7
mysql> SELECT (1+2)*3;
-> 9

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.1.2. 수식 계산에서의 타입 변환
12.1. 연산자 하나의 연산자가 서로 다른 타입의 피 연산자와 함께 사용된다면, 피 연산자의 호환성을 위해 타입 변환(conversion)이 발생한다.
12.1.2 수식 계산에서의 타입 변환 어떤 경우에는 변환이 암묵적(implicitly)으로 발생한다. 예를 들면, MySQL은 필요할 경우에는 숫자를 문자로 또는 문자를 숫자
로 자동 변환 시킨다.
mysql> SELECT 1+'1';
-> 2
mysql> SELECT CONCAT(2,' test');
-> '2 test'
또한, 명확하게 변환을 실행 시킬 수도 있다. 만일 여러분이 숫자를 문자로 명확하게 변환 시키고자 한다면, CAST() 또는
CONCAT() 함수를 사용하면 된다 (CAST()이 더 많이 사용됨):
mysql> SELECT 38.8, CAST(38.8 AS CHAR);
-> 38.8, '38.8'
mysql> SELECT 38.8, CONCAT(38.8);
-> 38.8, '38.8'
아래의 규칙은 비교 연산에 대한 변환이 어떻게 발생하는지를 설명하는 것이다:

:::MySQL Korea:::
● 만일 하나 또는 양쪽의 인수(argument)가 NULL이면, 비교 연산의 결과는 NULL이 되는데, NULL-safe <=> 등

식 비교 연산은 예외이다. NULL <=> NULL의 경우는, 그 결과가 트루(true)가 된다.
● 만일 비교 연산의 양쪽 인수가 모두 스트링이라면, 스트링 형태로 비교가 된다.
● 만일 양쪽 인수가 모두 정수라면, 정수로서 비교가 된다.
● 16진수 값은 숫자와 비교가 되지 않는다면 바이너리 스트링으로 취급이 된다.
● 만일 두 인수중의 하나가 TIMESTAMP 또는 DATETIME 컬럼이고 다른 인수는 상수라면, 그 상수는 비교 연산이 되기
전에 타임 스탬프로 변환이 된다. 이것은 보다 ODBC에 가깝게 만들기 위한 것이다. IN()에 대한 인수에 대해서는 실행되
지 않는다는 점을 알아두자! 보단 안전한 연산을 위해서는, 항상 완벽한 날짜시간(datetime), 날짜, 또는 시간 스트링을 비
교 연산에 사용하도록 한다.
● 다른 모든 경우에서는, 인수들은 부동 소수점 숫자로 비교가 된다.
아래의 예문은 비교 연산을 위해서 스트링을 숫자로 변환하는 것을 보여 주고 있다:
mysql> SELECT 1 > '6x';
-> 0
mysql> SELECT 7 > '6x';
-> 1
mysql> SELECT 0 > 'x6';
-> 0
mysql> SELECT 0 = 'x6';
-> 1
스트링 컬럼을 숫자와 비교를 할 경우에는, MySQL은 값을 빨리 찾기 위해서 컬럼의 인덱스를 사용하지는 않는다는 점을 알아두
기 바란다. 만일 str_col 이 인덱스가 된 스트링 컬럼이라면, 그 인덱스는 아래의 명령문에서 룩업(lookup)을 실행할 때 사용될 수

:::MySQL Korea:::
가 없다:
SELECT * FROM tbl_name WHERE str_col=1;
그 이유는 바로, '1', ' 1', 또는 '1a'처럼, 그 컬럼에는 1로 변환 시켜야 하는 스트링이 너무 많이 존재하기 때문이다.
부동 소수점 숫자 (또는 부동 소수점 숫자로 변환되는 값)를 사용하는 비교 연산은 대략적으로 실행되는데, 그 이유는 그런 숫자는
부정확하기 때문이다:
mysql> SELECT '18015376320243458' = 18015376320243458;
-> 1
mysql> SELECT '18015376320243459' = 18015376320243459;
-> 0
이러한 결과가 발생하는 이유는 해당 값이 부동 소수점으로 변환 되기 때문이며, 이렇게 변환이 되는 숫자는 단지 53 비트의 정밀
도만을 가지며 나머지는 절사(rounding) 처리 된다:
mysql> SELECT '18015376320243459'+0.0;
-> 1.8015376320243e+16
더욱이, 스트링에서 부동 소수점 그리고 정수에서 부동 소수점으로의 변환은 동일한 방식으로 처리되지는 않는다. 정수는 CPU에
의해 부동 소수점 숫자로 변환되는 반면에, 스트링은 부동 소수점 곱셈이 포함된 연산에서 자릿수 별로 변환이 된다.
위의 결과 값은 시스템 별로 다르게 나올 것이며, 또한 컴퓨터의 구조 또는 컴파일러 버전 또는 최적화 레벨에 따라서도 그 값이 달

라질 수 있다. 이러한 문제를 해결하는 한가지 방법은 CAST()를 사용해서 값을 암묵적으로 부동 소수점 숫자로 바뀌지 못하도록
하는 것이다:

:::MySQL Korea:::
mysql> SELECT CAST('18015376320243459' AS UNSIGNED) = 18015376320243459;
-> 1
부동 소수점 비교 연산에 대해서는 Section A.5.8, “Problems with Floating-Point Comparisons”를 참조하기 바란다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.1.3. 비교 함수와 연산자
12.1. 연산자 비교 연산의 결과는 1 (TRUE), 0 (FALSE), 또는 NULL가 된다. 이러한 연산은 숫자 및 스트링에서 실행된다. 스트링은 자동으
12.1.3 비교 함수와 연산자 로 숫자로 변환되며 필요할 경우에는 숫자를 스트링으로 변환 시킬 수도 있다.
이 섹션에 있는 몇몇 함수들 (LEAST() 및 GREATEST()와 같은 함수들)은 1 (TRUE), 0 (FALSE), 또는 NULL이 아닌 값 자

체를 리턴 한다. 하지만, 이러한 함수들은 Section 12.1.2, “수식 계산에서의 타입 변환”에서 설명한 규칙에 따라서 실행된 비교
연산에 근거하여 값을 리턴한다.
비교 연산의 목적에 맞게 어떤 값을 특정 타입으로 변환하기 위해서는, CAST() 함수를 사용하면 된다. 스트링 값은 CONVERT()
을 사용하면 서로 다른 문자 셋으로 변환 시킬 수가 있다. Section 12.8, “캐스트(Cast) 함수 및 연산자”를 참조.
디폴트로는, 스트링 비교 연산은 문자 크기를 구분하지 않으며 현재(current)의 문자 셋을 사용한다. 디폴트는 latin1 (cp1252
West European)이며, 이것은 영어에서도 잘 동작을 한다.
● =
같음(equal):
mysql> SELECT 1 = 0;

:::MySQL Korea:::
-> 0
mysql> SELECT '0' = 0;
-> 1
mysql> SELECT '0.0' = 0;
-> 1
mysql> SELECT '0.01' = 0;
-> 0
mysql> SELECT '.01' = 0.01;
-> 1
● <=>
NULL-세이프(safe) 등호. 이 연산자는 = 연산자와 같은 등식 비교 연산을 실행하지만, 양쪽의 연산자가 모두 NULL이

면, NULL 대신에 1을, 그리고 하나의 연산자만 NULL이면, NULL 대신에 0 을 리턴한다.
mysql> SELECT 1 <=> 1, NULL <=> NULL, 1 <=> NULL;
-> 1, 1, 0
mysql> SELECT 1 = 1, NULL = NULL, 1 = NULL;
-> 1, NULL, NULL
● <>, !=

:::MySQL Korea:::
같지 않음(Not equal):
mysql> SELECT '.01' <> '0.01';
-> 1
mysql> SELECT .01 <> '0.01';
-> 0
mysql> SELECT 'zapp' <> 'zappp';
-> 1
● <=
작거나 같음:
mysql> SELECT 0.1 <= 2;
-> 1
● <
보다 작음:
mysql> SELECT 2 < 2;
-> 0
● >=

:::MySQL Korea:::
크거나 같음:
mysql> SELECT 2 >= 2;
-> 1
● >
보다 큼:
mysql> SELECT 2 > 2;
-> 0
● IS boolean_value, IS NOT boolean_value
불리안 값에 대응해서 값을 테스트 하는데, 여기에서 boolean_value 은 TRUE, FALSE, or UNKNOWN이 될 수 있다.
mysql> SELECT 1 IS TRUE, 0 IS FALSE, NULL IS UNKNOWN;
-> 1, 1, 1
mysql> SELECT 1 IS NOT UNKNOWN, 0 IS NOT UNKNOWN, NULL IS NOT UNKNOWN;
-> 1, 1, 0
IS [NOT] boolean_value 신텍스는 MySQL 5.0.2에서 추가 되었다.
● IS NULL, IS NOT NULL
값이 NULL인지 아닌지를 테스트

:::MySQL Korea:::
mysql> SELECT 1 IS NULL, 0 IS NULL, NULL IS NULL;
-> 0, 0, 1
mysql> SELECT 1 IS NOT NULL, 0 IS NOT NULL, NULL IS NOT NULL;
-> 1, 1, 0
ODBC 프로그램과 잘 동작을 하도록 하기 위해서, MySQL은 IS NULL을 사용할 때 아래와 같은 추가적인 기능들을 지원
한다:
❍ 값을 생성한 다음에 곧바로 아래와 같은 명령문을 입력하면 가장 최근의 AUTO_INCREMENT 값을 가지고 있는

열을 찾을 수가 있다:
o SELECT * FROM tbl_name WHERE auto_col IS NULL
이러한 동작은 SQL_AUTO_IS_NULL=0로 설정을 하면 비 활성화 시킬 수가 있다. Section 13.5.3, “SET 신

텍스”를 참조.
❍ NOT NULL로 선언된 DATE 및 DATETIME 컬럼에 대해서는, 아래와 같은 명령문을 사용하면 특수 날짜인
'0000-00-00'을 찾을 수가 있다:
o SELECT * FROM tbl_name WHERE date_column IS NULL
이것은 ODBC가 '0000-00-00' 와 같은 날짜 값을 지원하지 않기 때문에 어떤 경우의 어플리케이션을 실행하

기 위해서 필요할 때가 있다.
● expr BETWEEN min AND max
만일 expr 가 min 보다 크거나 같고 expr 가 max 보다 작거나 같으면, BETWEEN은 1을 리턴하고, 그렇지 않으면 0 을
리턴 한다. 이것은 모든 인수가 동일한 타입일 경우의 수식 (min <= expr AND expr <= max)과 같다. 그렇지 않
을 경우, 타입 변환이 Section 12.1.2, “수식 계산에서의 타입 변환”에서 설명한 방식에 따라서 실행되지만, 세 가지 인

:::MySQL Korea:::
수 모두에 적용된다.
mysql> SELECT 1 BETWEEN 2 AND 3;
-> 0
mysql> SELECT 'b' BETWEEN 'a' AND 'c';
-> 1
mysql> SELECT 2 BETWEEN 2 AND '3';
-> 1
mysql> SELECT 2 BETWEEN 2 AND 'x-3';
-> 0
● expr NOT BETWEEN min AND max
이것은 NOT (expr BETWEEN min AND max)과 동일하다.
● COALESCE(value,...)
리스트에 있는 첫 번째 논(non)-NULL 값을 리턴하거나, 또는 논(non)-NULL 값이 없을 경우에는 NULL을 리턴한다.
mysql> SELECT COALESCE(NULL,1);
-> 1
mysql> SELECT COALESCE(NULL,NULL,NULL);

:::MySQL Korea:::
-> NULL
● GREATEST(value1,value2,...)
두 개 이상의 인수를 사용하면, 그 중에 가장 큰 인수 값을 리턴 한다. 인수들은 LEAST()에서 적용하는 규칙과 같은 것

을 사용해서 비교가 된다.
mysql> SELECT GREATEST(2,0);
-> 2
mysql> SELECT GREATEST(34.0,3.0,5.0,767.0);
-> 767.0
mysql> SELECT GREATEST('B','A','C');
-> 'C'
MySQL 5.0.13 이전 버전에서는, GREATEST()은 모든 인수가 NULL 일 경우에만 NULL을 리턴한다. 5.0.13 이후에
는, 인수 중의 하나가 NULL 이면 NULL을 리턴한다.
● expr IN (value,...)
만일 expr 이 IN 리스트에 있는 값들 중의 하나와 같게 되면 1을, 그렇지 않으면 0 을 리턴한다. 만일 모든 값이 상수라

면, 그 값들은 expr 의 타입에 따라서 값이 계산된 후에 정렬이 된다. 그런 다음에, 아이템에 대한 검색은 바이너리 검색
을 통해서 실행된다. 이것은, 만일 This means IN 의 값 리스트가 전체적으로 상수로 구성되어 있다면 IN이 매우 빠르다
는 것을 의미하는 것이다. 그렇지 않을 경우에는, Section 12.1.2, “수식 계산에서의 타입 변환”에서 설명한 규칙에 따
라서 타입 변환이 일어나지만, 모든 인수에 적용이 된다.
mysql> SELECT 2 IN (0,3,5,'wefwf');
-> 0

:::MySQL Korea:::
mysql> SELECT 'wefwf' IN (0,3,5,'wefwf');
-> 1
IN 리스트에 있는 값의 번호는 max_allowed_packet 값에 의해서만 한정이 된다.

표준 SQL을 따르기 위해서, IN 은 왼쪽 부분의 수식이 NULL 일 경우 뿐만 아니라, 리스트에서 매치되는 것을 발견하지
못하고 리스트에 있는 수식 중의 하나가 NULL일 경우에도 NULL을 리턴한다.
IN() 신텍스는 특정 타입의 서브 쿼리를 작성할 때에도 사용할 수가 있다. Section 13.2.8.3, “ANY, IN, 그리고 SOME
을 사용하는 서브 쿼리”를 참조.
● expr NOT IN (value,...)
NOT (expr IN (value,...))과 동일한 것임.
● ISNULL(expr)
만일 expr 이 NULL 이라면, ISNULL() 은 1 을, 그렇지 않을 경우라면 0 을 리턴한다.
mysql> SELECT ISNULL(1+1);
-> 0
mysql> SELECT ISNULL(1/0);
-> 1
can be used instead of = to test whether 어떤 값이 NULL인지 아닌지를 테스트 하기 위해서 = 대신에 ISNULL()
을 사용할 수도 있다. (= 를 사용해서 어떤 값을 NULL 과 비교하면 항상 거짓(false)이 나온다.)
ISNULL() 함수는 IS NULL 비교 연산자와 함께 특정 동작을 공유한다. IS NULL에 대한 설명을 참조할 것.
● INTERVAL(N,N1,N2,N3,...)

:::MySQL Korea:::
N < N1 일 경우에는 0 을, N < N2 과 같은 순서일 경우에는 1 을, 또는 N 이 NULL이면 -1을 리턴한다. 모든 인수

는 정수로 다루어진다. 이 함수에 대해서는 N1 < N2 < N3 < ... < Nn 이 제대로 동작 되어야 한다. 그 이유는
여기에서는 바이너리 검색이 사용되기 때문이다.
mysql> SELECT INTERVAL(23, 1, 15, 17, 30, 44, 200);
-> 3
mysql> SELECT INTERVAL(10, 1, 10, 100, 1000);
-> 2
mysql> SELECT INTERVAL(22, 23, 30, 44, 200);
-> 0
● LEAST(value1,value2,...)
두 개 이상의 인수를 사용하면, 가장 작은 인수 값을 리턴한다. 인수들은 아래의 규칙에 따라서 비교가 된다:
❍ 만일 리턴 값이 INTEGER 문맥에서 사용되거나 또는 모든 인수가 정수 값이라면, 그 인수들은 정수로 비교가 된

다.
❍ 만일 리턴 값이 REAL 문맥에서 사용되거나 또는 모든 인수가 실수 값(real value)이라면, 인수들은 실수(real)로
비교된다.
❍ 만일 어떤 인수가 문자 크기에 민감한 스트링이라면, 그 인수는 문자 크기를 구분하는 스트링으로 비교가 된다.
❍ 이외의 모든 경우에는, 인수들은 문자 크기와는 상관없는 스트링으로 비교가 된다.
MySQL 5.0.13 이전의 경우, LEAST() 은 모든 인수가 NULL 일 경우에만 NULL을 리턴한다. 5.0.13 이후에는, 어떤
인수가 NULL 이면 NULL을 리턴한다.
mysql> SELECT LEAST(2,0);

:::MySQL Korea:::
-> 0
mysql> SELECT LEAST(34.0,3.0,5.0,767.0);
-> 3.0
mysql> SELECT LEAST('B','A','C');
-> 'A'
위의 변환 규칙은 어떤 경계 라인(borderline)의 경우에는 예상하지 못한 결과를 만들 수도 있다는 점을 알아 두기 바란

다:
mysql> SELECT CAST(LEAST(3600, 9223372036854775808.0) as SIGNED);
-> -9223372036854775808
위의 결과가 나오는 이유는, MySQL이 9223372036854775808.0을 정수 문맥에서 읽기 때문이다. 위의 값을 가지기 위

해서는 정수 표현식이 좋지 않기 때문에, 이것을 부호화된 정수 타입으로 만들었다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.1.4. 논리 연산자
12.1. 연산자 SQL에서는, 모든 논리 연산자는 TRUE, FALSE, 또는 NULL (UNKNOWN)으로 계산된다. MySQL의 경우에는, 이러한 것들이
12.1.4 논리 연산자 1 (TRUE), 0 (FALSE), 그리고 NULL로 계산된다. 이들 대부분은 다른 SQL 데이터 베이스 서버에서도 공통적인 것으로, 비록
어떤 서버가 TRUE에 대한 값으로 0 이 아닌 값을 리턴하는 경우에도 해당이 된다.
● NOT, !
논리 NOT. 피 연산자가 0 이면 1 을, 피 연산자가 0 이 아니면 0 을 계산하고, NOT NULL 일 경우에는 NULL을 리턴

한다.
mysql> SELECT NOT 10;
-> 0
mysql> SELECT NOT 0;
-> 1
mysql> SELECT NOT NULL;
-> NULL
mysql> SELECT ! (1+1);
-> 0

:::MySQL Korea:::
mysql> SELECT ! 1+1;
-> 1
마지막 예문은 1 을 리턴하는데, 그 이유는 이 수식이 (!1)+1과 같은 방식으로 처리되기 때문이다.

NOT 연산자에 대한 우선 순위가 MySQL 5.0.2에서 변경이 되었다는 점을 알아두기 바란다. Section 12.1.1, “연산자
우선 순위”를 참조.
● AND, &&
논리 AND. 모든 피 연산자가 0 이 아니고 NULL도 아니라면 1을, 한 개 또는 그 이상의 피 연산자가 0 이라면 0 을, 그렇

지 않을 경우에는 NULL 을 리턴한다.
mysql> SELECT 1 && 1;
-> 1
mysql> SELECT 1 && 0;
-> 0
mysql> SELECT 1 && NULL;
-> NULL
mysql> SELECT 0 && NULL;
-> 0
mysql> SELECT NULL && 0;
-> 0

:::MySQL Korea:::
● OR, ||
논리 OR. 양쪽의 피 연산자가 NULL이 아니라면, 그 결과는, 양쪽의 피 연산자가 0 이 아니면 1 을, 그렇지 않으면 0 을 리
턴한다. NULL 피 연산자를 사용하면, 다른 피 연산자가 0 이 아니면 1 을, 그렇지 않으면 NULL 을 리턴한다. 만일 양쪽
의 피 연산자가 모두 NULL 이라면, 그 결과는 NULL 이 된다.
mysql> SELECT 1 || 1;
-> 1
-> 1
-> 0
mysql> SELECT 0 || NULL;
-> NULL
mysql> SELECT 1 || NULL;
-> 1
● XOR
논리 XOR. 피 연산자 중의 하나가 NULL 이면 NULL을 리턴한다. NULL이 아닌 피 연산자의경우, 피 연산자의 홀수 개

수가 0 이 아니면 1 을, 그렇지 않으면 0 을 리턴한다.

:::MySQL Korea:::
mysql> SELECT 1 XOR 1;
-> 0
mysql> SELECT 1 XOR 0;
-> 1
mysql> SELECT 1 XOR NULL;
-> NULL
mysql> SELECT 1 XOR 1 XOR 1;
-> 1
XOR b 는 수학적으로 (a AND (NOT b)) OR ((NOT a) and b)과 동일하다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.2. 제어 플로우 함수
12. 함수와 연산자 ● CASE value WHEN [compare_value] THEN result [WHEN [compare_value] THEN result ...] [ELSE result]
12.2. 제어 플로우 함수 END
12.2 제어 플로우 함수
CASE WHEN [condition] THEN result [WHEN [condition] THEN result ...] [ELSE result] END
첫 번째 수식은 value=compare_value 인 경우에 result 을 리턴한다. 두 번째 수식은 처음의 조건이 트루(true)일 경우
에 값을 리턴한다. 만일 매칭되는 결과 값이 없는 경우에는, ELSE 다음의 값이 리턴이 되거나, 또는 ELSE 부분이 없는 경
우에는 NULL 을 리턴한다.
mysql> SELECT CASE 1 WHEN 1 THEN 'one'

-> WHEN 2 THEN 'two' ELSE 'more' END;
-> 'one'
mysql> SELECT CASE WHEN 1>0 THEN 'true' ELSE 'false' END;
-> 'true'
mysql> SELECT CASE BINARY 'B'
-> WHEN 'a' THEN 1 WHEN 'b' THEN 2 END;
-> NULL
CASE 수식의 디폴트 리턴 타입은 모든 리턴 값에 대해서 호환성이 있는 집합 타입(aggregated type)이지만, 그 수식이

사용된 문맥에도 또한 의존을 한다. 만일 스트링 문맥에서 이 수식이 사용되었다면, 그 결과는 스트링으로 리턴된다. 만일
숫자 문맥에서 사용되었다면, 그 결과는 10진수, 실수, 또는 정수 값으로 리턴된다.
Note: 위에서 보여진 CASE 수식의 신텍스는, 내부 스토어드 루틴의 사용에 있어서, Section 17.2.10.2, “CASE 명령
문”에서 설명한 SQL CASE 명령문과는 다소 차이가 있다. CASE 명령문은 ELSE NULL 구문을 가질 수가 없으며, 또
한 END 대신에 END CASE를 사용해서 종료가 된다.

:::MySQL Korea:::
● IF(expr1,expr2,expr3)
만일 expr1 이 TRUE (expr1 <> 0 and expr1 <> NULL)라면, IF() 는 expr2 를 리턴한다; 그렇지 않을 경
우에는 expr3를 리턴한다. IF()는 자체가 어떤 문맥에서 사용되는지에 따라서, 숫자 또는 스트링 값을 리턴한다.
mysql> SELECT IF(1>2,2,3);

-> 3
mysql> SELECT IF(1<2,'yes','no');
-> 'yes'
mysql> SELECT IF(STRCMP('test','test1'),'no','yes');
-> 'no'
만일 expr2 또는 expr3 중의 하나가 명확하게 NULL 이라면, IF() 함수의 결과 타입은 NULL 이 아닌 수식 값을 갖는
다.
expr1 은 정수 값 형태로 계산되는데, 이것은, 만일 부동 소수점 또는 스트링 값을 테스트 할 경우라면, 비교 연산식을 사

용해서 테스트를 해야 한다는 것을 의미하는 것이다.
mysql> SELECT IF(0.1,1,0);

-> 0
mysql> SELECT IF(0.1<>0,1,0);
-> 1
첫 번째 예에서 보면, IF(0.1) 은 0 을 리턴하는데, 그 이유는 0.1 이 정수 값으로 변환되기 때문이며, 따라서 그 결과는 IF
(0)과 같다. 이 결과 값은 어쩌면 여러분이 예상한 값과는 다를 것이다. 두 번째 경우를 보면, 원래의 부동 소수점 값이 0
인지 아닌지를 보기 위해서 비교 연산을 테스트 하고 있다. 비교 결과는 정수 형태로 사용된다.
IF() 의 디폴트 리턴 타입 (임시 테이블에 저장될 때에만 고려 대상임)은 아래와 같이 계산된다:
Expression Return Value

:::MySQL Korea:::
expr2 or expr3 returns a string string
expr2 or expr3 returns a floating-point value floating-point
expr2 or expr3 returns an integer integer
만일 expr2 및 expr3 이 둘 다 스트링 이라면, 두 인수중의 하나가 문자 크기를 구분한다면 그 결과는 문자 크기를 구분하
게 된다.
Note: IF 명령문도 또한 존재 하는데, 이 명령문은 위에서 설명한 IF() 함수와는 다소 다른 것이다. Section 17.2.10.1,
“IF 명령문”을 참조할 것.
● IFNULL(expr1,expr2)
만일 expr1 이 NULL이 아니라면, IFNULL() 은 expr1을 리턴한다; 그렇지 않을 경우에는 expr2를 리턴한다. IFNULL
() 은 사용된 문맥에 따라서 숫자 또는 스트링 값을 리턴한다.
mysql> SELECT IFNULL(1,0);

-> 1
mysql> SELECT IFNULL(NULL,10);
-> 10
mysql> SELECT IFNULL(1/0,10);
-> 10
mysql> SELECT IFNULL(1/0,'yes');
-> 'yes'
IFNULL(expr1,expr2)의 디폴트 리턴 타입은 STRING, REAL, 또는 INTEGER 순서에 있어서, 위의 두 수식보다는 보

다 “일반적(general)”인 형태를 갖는다. 수식에 기반을 둔 테이블 또는 MySQL이 IFNULL()에 의해 리턴되는 값을 임
시 테이블에 저장해야만 하는 경우를 가정해 보자:
mysql> CREATE TABLE tmp SELECT IFNULL(1,'test') AS test;

mysql> DESCRIBE tmp;

:::MySQL Korea:::
+-------+---------+------+-----+---------+-------+
+-------+---------+------+-----+---------+-------+
| test | char(4) | | | | |
+-------+---------+------+-----+---------+-------+
이 예문에서 보면, test 컬럼의 타입은 CHAR(4)가 된다.
● NULLIF(expr1,expr2)
만일 expr1 = expr2 가 트루(true)라면 NULL을, 그렇지 않을 경우는 expr1을 리턴한다. 이것은 CASE WHEN expr1
= expr2 THEN NULL ELSE expr1 END과 동일하다.
mysql> SELECT NULLIF(1,1);

-> NULL
mysql> SELECT NULLIF(1,2);
-> 1
만일 인수들이 동일하지 않을 경우에는, MySQL은 expr1 를 두번 계산한다는 점을 알아두자.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.3. 스트링 함수
12. 함수와 연산자 12.3.1. 스트링 비교 함수

12.3. 스트링 함수
12.3 스트링 함수 스트링-값 함수는 그 결과 값의 길이가 max_allowed_packet 시스템 변수의 값 보다 클 경우에는, NULL을 리턴한다.
Section 7.5.2, “서버 파라미터 튜닝하기”를 참조할 것.
스트링 포지션(position)에서 연산을 하는 함수의 경우, 첫 번째 포지션은 숫자 1이 된다.
● ASCII(str)
스트링 str 의 맨 왼쪽 문자의 숫자 값을 리턴한다. str 이 빈 스트링(empty string)일 경우에는 0 을 리턴한다. NULL if
str 이 NULL일 경우에는 NULL 을 리턴한다. ASCII()는 0 에서 255 사이의 숫자 값을 갖는 문자에 대해서 연산을 한
다.
mysql> SELECT ASCII('2');
-> 50
mysql> SELECT ASCII(2);
-> 50
mysql> SELECT ASCII('dx');
-> 100
ORD() 함수를 함께 참조할 것.
● BIN(N)
N의 바이너리 값에 대한 스트링 표현식을 리턴하는데, 여기에서N 은 (BIGINT) 숫자이다. 이것은 CONV(N,10,2)과 동

일하다. N 이 NULL일 경우에는 NULL을 리턴한다.
mysql> SELECT BIN(12);

:::MySQL Korea:::
-> '1100'
● BIT_LENGTH(str)
스트링 str 의 길이를 비트 단위로 리턴한다.

mysql> SELECT BIT_LENGTH('text');
-> 32
● CHAR(N,... [USING charset_name])
CHAR()은 각각의 인수 N 을 정수 형태로 해석을 하고 이러한 정수의 코드 값에 의해 주어지는 문자로 구성된 스트링을
리턴한다. NULL 값은 무시(skipped)된다.
mysql> SELECT CHAR(77,121,83,81,'76');
-> 'MySQL'
mysql> SELECT CHAR(77,77.3,'77.3');
-> 'MMM'
MySQL 5.0.15 이후 버전에서는, 255 보다 큰 CHAR() 인수는 여러 개의 결과 바이트로 변환된다. 예를 들면, CHAR
(256)는 CHAR(1,0)와 같고, 그리고 CHAR(256*256) 는 CHAR(1,0,0)과 같다:
mysql> SELECT HEX(CHAR(1,0)), HEX(CHAR(256));
+----------------+----------------+
| HEX(CHAR(1,0)) | HEX(CHAR(256)) |
+----------------+----------------+
| 0100 | 0100 |
+----------------+----------------+
mysql> SELECT HEX(CHAR(1,0,0)), HEX(CHAR(256*256));
+------------------+--------------------+
| HEX(CHAR(1,0,0)) | HEX(CHAR(256*256)) |
+------------------+--------------------+
| 010000 | 010000 |
+------------------+--------------------+
디폴트로는, CHAR()는 바이너리 스트링을 리턴한다. 주어진 문자 셋에 있는 스트링을 만들기 위해서는, USING 구문을

:::MySQL Korea:::
옵션으로 사용한다:
mysql> SELECT CHARSET(CHAR(0x65)), CHARSET(CHAR(0x65 USING utf8));
+---------------------+--------------------------------+
| CHARSET(CHAR(0x65)) | CHARSET(CHAR(0x65 USING utf8)) |
+---------------------+--------------------------------+
| binary | utf8 |
+---------------------+--------------------------------+
만일 USING을 사용하였는데도 그 결과 스트링이 주어진 문자 셋에 대해서 유효하지 않게 되면, 경고문이 나오게 된다. 또
한, 만일 스트릭트(strict) SQL 모드를 활성화 한다면, CHAR() 의 결과 값은 NULL이 된다.
MySQL 5.0.15 이전 버전에서는, CHAR()는 연결 문자 셋에 있는 스트링을 리턴하며 USING 구문은 사용할 수 없게 된
다. 또한, 각각의 인수는 모듈로(modulo) 256으로 해석이 되기 때문에, CHAR(256) 및 CHAR(256*256)는 둘 다
CHAR(0)과 동일한 것이 된다.
● CHAR_LENGTH(str)
스트링 str의 길이를 리턴한다. 다중 바이트 문자는 단일 문자로 계산(count) 된다. 즉, 5개의 2 바이트 문자를 갖는 스트
링에 대해서, LENGTH() 는 10을 리턴 하지만, CHAR_LENGTH()는 5를 리턴 한다.
● CHARACTER_LENGTH(str)
CHARACTER_LENGTH()는 CHAR_LENGTH()과 동일하다.
● CONCAT(str1,str2,...)
인수를 연결한 결과로 나오는 스트링을 리턴한다. 한 개 또는 그 이상의 인수를 가질 수 있다. 만일 모든 인수가 바이너리
스트링이 아니라면, 그 결과는 바이너리가 아닌 스트링이 된다. 만일 인수에 바이너리 스트링이 포함되어 있다면, 그 결과
는 바이너리 스트링이 된다. 숫자 인수는 동일한 바이너리 스트링 형태로 변환된다; 만일 이렇게 변환되는 것을 원하지 않
을 경우에는, 아래의 예문과 같이 명확하게 타입 캐스트(type cast)를 사용하면 된다:
SELECT CONCAT(CAST(int_col AS CHAR), char_col);
CONCAT()는 모든 인수가 NULL이 아니면 NULL을 리턴한다.
mysql> SELECT CONCAT('My', 'S', 'QL');

:::MySQL Korea:::
-> 'MySQL'
mysql> SELECT CONCAT('My', NULL, 'QL');
-> NULL
mysql> SELECT CONCAT(14.3);
-> '14.3'
● CONCAT_WS(separator,str1,str2,...)
CONCAT_WS()는 구분자를 사용하는 연결(Concatenate With Separator)을 나타내는 것이며 CONCAT()의 특수 형

태이다. 첫 번째 인수는 나머지 인수들에 대한 구분자(separator)가 된다. 구분자는 연결되는 스트링 사이에 추가된다. 구
분자는 스트링이 될 수 있다. 만일 구분자가 NULL 이면, 그 결과는 NULL이다.
mysql> SELECT CONCAT_WS(',','First name','Second name','Last Name');
-> 'First name,Second name,Last Name'
mysql> SELECT CONCAT_WS(',','First name',NULL,'Last Name');
-> 'First name,Last Name'
CONCAT_WS()는 빈 스트링(empty string)을 무시(skip)하지 않는다. 하지만, 구분자 인수 다음에 나오는 모든 NULL
값은 무시를 한다.
● CONV(N,from_base,to_base)
서로 다른 문자 베이스(base)간의 숫자를 변환한다. from_base 에서 베이스 to_base로 변환된 숫자 N의 스트링 표현식

을 리턴한다. 인수 중의 하나가 NULL이면 NULL을 리턴한다.인수 N 은 정수로 해석되지만, 정수 또는 스트링으로 지정
될 수도 있다. 최소 베이스는 2 이고 최대 베이스는 36이다. 만일 to_base 가 음수라면, N 은 부호화된 숫자로 간주된다.
그렇지 않을 경우에는, N 은 부호 없는 숫자로 취급된다. CONV()는 64-비트 정밀도를 갖는다.
mysql> SELECT CONV('a',16,2);
-> '1010'
mysql> SELECT CONV('6E',18,8);
-> '172'
mysql> SELECT CONV(-17,10,-18);
-> '-H'
mysql> SELECT CONV(10+'10'+'10'+0xa,10,10);

:::MySQL Korea:::
-> '40'
● ELT(N,str1,str2,str3,...)
만일N = 1이면, str1을, N = 2이면, str2 을 리턴하는 방식. N 이 1 보다 작거나 또는인수의 숫자보다 많을 경우에는
NULL을 리턴한다. ELT()는 FIELD()의 보수(complement)이다.
mysql> SELECT ELT(1, 'ej', 'Heja', 'hej', 'foo');
-> 'ej'
mysql> SELECT ELT(4, 'ej', 'Heja', 'hej', 'foo');
-> 'foo'
● EXPORT_SET(bits,on,off[,separator[,number_of_bits]])
bits에 있는 모든 비트 셋(bit set)에 대해서는, on 스트링을, 그리고 모든 리셋 비트에 대해서는, off 스트링을 리턴한다.
bits 에 있는 비트는 오른쪽에서 왼쪽으로 검사된다 (낮은 순서에서 높은 순서 비트로). 스트링은 왼쪽에서 오른쪽으로 결
과에 추가되는데, separator 스트링으로 구분이 된다 (디폴트 스트링은 콤마 문자 ‘,’). 검사가 되는 비트의 숫자는
number_of_bits로 주어진다 (디폴트는 64).
mysql> SELECT EXPORT_SET(5,'Y','N',',',4);
-> 'Y,N,Y,N'
mysql> SELECT EXPORT_SET(6,'1','0',',',10);
-> '0,1,1,0,0,0,0,0,0,0'
● FIELD(str,str1,str2,str3,...)
str1, str2, str3, ... 리스트에 있는 str 의 인덱스(포지션)를 리턴한다. str을 찾을 수 없는 경우에는 0 을 리턴 한다.
만일 FIELD()에 대한 모든 인수가 스트링이라면, 모든 인수는 스트링으로 비교된다. 만일 모든 인수가 숫자일 경우에는
숫자로 비교가 된다. 그렇지 않은 경우라면, 인수들은 두 번 (double) 비교가 된다.
만일 str 이 NULL이라면, 리턴 값은 0 이 되는데, 그 이유는 NULL 은 어떤 값과도 등식 비교가 되지 않기 때문이다.
FIELD()는 ELT()의 보수(complement)이다.
mysql> SELECT FIELD('ej', 'Hej', 'ej', 'Heja', 'hej', 'foo');
-> 2

:::MySQL Korea:::
mysql> SELECT FIELD('fo', 'Hej', 'ej', 'Heja', 'hej', 'foo');

-> 0
● FIND_IN_SET(str,strlist)
만일 스트링 str 이 N 의 서브 스트링으로 구성된 스트링 리스트 strlist 에 있는 것이라면, 1의 범위에 있는 값을 N 에 리

턴한다. 하나의 스트링 리스트는 콤마 문자로 구분된 서브 스트링들로 구성된 스트링이다. 만일 첫 번째 인수가 상수 스트
링이고 두 번째 인수가 타입 SET의 컬럼이라면, FIND_IN_SET() 함수는 비트 산술식을 사용하기 위해서 최적화가 된
다. 만일 str 이 strlist에 없거나 또는 strlist가 빈 스트링이라면, 0을 리턴한다. NULL if만일 인수 중의 하나가 NULL이
라면, NULL을 리턴한다. 만일 첫 번째 인수가 콤마 문자를 가지고 있다면, 이 함수는 제대로 동작을 하지 않는다.
mysql> SELECT FIND_IN_SET('b','a,b,c,d');
-> 2
● FORMAT(X,D)
숫자 X 의 포맷을 '#,###,###.##' 형태로 만들고, D의 소수점 뒷자리에서 절사(round)를 하고, 그 결과를 스트링으
로 리턴한다. 만일 D 가 0 이면, 그 결과는 소수점 또는 분수 부분을 갖지 않는다.
mysql> SELECT FORMAT(12332.123456, 4);
-> '12,332.1235'
mysql> SELECT FORMAT(12332.1,4);
-> '12,332.1000'
mysql> SELECT FORMAT(12332.2,0);
-> '12,332'
● HEX(N_or_S)
만일N_or_S 이 숫자라면, N에 대한 16진수 값에 해당하는 스트링 표현을 리턴하는데, 여기에서 N 은 (BIGINT) 숫자가
된다. 이것은 CONV(N,10,16)과 동일하다.
만일 N_or_S 이 스트링 이라면, N_or_S 에 대한 16진수 스트링 표현식을 리턴하는데, N_or_S 에 있는 각각의 문자는 2
개의 16진수 숫자로 변환된다.
mysql> SELECT HEX(255);

:::MySQL Korea:::
-> 'FF'
mysql> SELECT 0x616263;
-> 'abc'
mysql> SELECT HEX('abc');
-> 616263
● INSERT(str,pos,len,newstr)
str 의 포지션 pos 에서 시작하는 서브 스트링을 len 문자 길이만큼 스트링 newstr로 변경시켜서 str 을 리턴한다. 만일
pos 가 스트링의 길이 안에 있지 않다면, 원래의 스트링을 리턴한다. 만일 len 의 범위가 스트링의 나머지 길이 범위 내에
있지 않다면, 포지션 pos 이후의 나머지 스트링을 대체 시킨다. 만일 어떤 인수가 NULL 이면, NULL을 리턴한다.
mysql> SELECT INSERT('Quadratic', 3, 4, 'What');
-> 'QuWhattic'
mysql> SELECT INSERT('Quadratic', -1, 4, 'What');
-> 'Quadratic'
mysql> SELECT INSERT('Quadratic', 3, 100, 'What');
-> 'QuWhat'
이 함수는 다중 바이트에서도 동작을 한다.
● INSTR(str,substr)
str 에서 서브 스트링 substr 가 처음으로 나오는 포지션을 리턴한다. 이것은 LOCATE()에서 두 개의 인수를 사용하는
것과 동일한 결과를 리턴 하지만, 인수들의 순서는 반대가 된다.
mysql> SELECT INSTR('foobarbar', 'bar');
-> 4
mysql> SELECT INSTR('xbar', 'foobar');
-> 0
이 함수는 다중 바이트에서도 동작을 하며, 최소 하나의 인수가 바이너리 스트링일 경우에만 문자 크기를 구분한다.
● LCASE(str)

:::MySQL Korea:::
LCASE()는 LOWER()와 동의어 이다.
● LEFT(str,len)
스트링 str에서 가장 왼쪽으로부터 len 개의 문자를 리턴한다.

mysql> SELECT LEFT('foobarbar', 5);
-> 'fooba'
● LENGTH(str)
str의 길이를 바이트 단위로 리턴한다. 다중 바이트 문자는 다중 바이트로 계산 (count)된다. 이것은 2 바이트 문자가 5
개 있는 스트링의 경우, LENGTH() 은 10을 리턴하는 반면에, CHAR_LENGTH()는 5를 리턴한다는 것을 의미한다.
mysql> SELECT LENGTH('text');
-> 4
● LOAD_FILE(file_name)
파일을 읽은 다음에 파일의 내용물을 스트링으로 리턴한다. 이 함수를 사용하기 위해서는, 파일은 반드시 서버 호스트에
있어야 하며, 그 파일에 대한 경로 이름을 전체적으로 지정해야 하며, 그리고 FILE 권한을 가져야 한다. 그 파일은 모든 사
용자에게 읽힐 수 있어야 하며 파일의 크기는 max_allowed_packet 바이트 보다는 작아야 한다.
만일 파일이 존재하지 않거나 또는 위의 조건 중에 하나로 인해 파일을 읽을 수가 없게 된다면, 이 함수는 NULL을 리턴한
다.
MySQL 5.0.19 이후 버전에서는, character_set_filesystem 시스템 변수가 리터럴 스트링으로 주어진 파일 이름에 대
한 해석을 제어한다.
mysql> UPDATE t
SET blob_col=LOAD_FILE('/tmp/picture')
WHERE id=1;
● LOCATE(substr,str), LOCATE(substr,str,pos)
첫 번째 신텍스는 str 에서 서브 스트링 substr 가 처음으로 나오는 포지션을 리턴한다. 두 번째 신텍스는, 포지션 pos에
서 시작을 해서, str 에서 서브 스트링 substr 가 처음으로 나오는 포지션을 리턴한다. substr 이 str에 존재하지 않을 경

:::MySQL Korea:::
우에는, 0을 리턴한다.
mysql> SELECT LOCATE('bar', 'foobarbar');
-> 4
mysql> SELECT LOCATE('xbar', 'foobar');
-> 0
mysql> SELECT LOCATE('bar', 'foobarbar', 5);
-> 7
이 함수는 다중 바이트에서도 동작을 하며, 인수 중에서 최소 하나라도 바이너리 스트링일 경우에만 문자 크기를 구분한
다.
● LOWER(str)
현재 (current) 문자 셋 매핑에 따라서 스트링 str 의 모든 문자를 소문자로 변경 시켜서 리턴한다. 디폴트는 latin1
(cp1252 West European).
mysql> SELECT LOWER('QUADRATICALLY');
-> 'quadratically'
● LPAD(str,len,padstr)
왼쪽에 스트링 padstr 를 집어 넣어서 문자의 길이를 len 만큼 되도록 한 스트링 str 을 리턴한다. 만일 str 이 len 보다 길
다면, 리턴 값은 len 길이 만큼 줄어 든다.
mysql> SELECT LPAD('hi',4,'??');
-> '??hi'
mysql> SELECT LPAD('hi',1,'??');
-> 'h'
● LTRIM(str)
스트링 앞에 있는 스페이스를 없앤 스트링 str 를 리턴한다.

mysql> SELECT LTRIM(' barbar');

:::MySQL Korea:::
-> 'barbar'
● MAKE_SET(bits,str1,str2,...)
bits 셋에 대응되는 비트를 가지고 있는 스트링으로 구성된 셋 값 (콤마 문자로 구분된 서브 스트링을 가지고 있는 스트
링)을 리턴한다. str1은 비트 0에 대응되고, str2 은 1에 대응되며, 계속 이런 식으로 대응이 된다. str1, str2, ... 에 있는
NULL 값은 결과에 따라 나오지 않는다.
mysql> SELECT MAKE_SET(1,'a','b','c');
-> 'a'
mysql> SELECT MAKE_SET(1 | 4,'hello','nice','world');
-> 'hello,world'
mysql> SELECT MAKE_SET(1 | 4,'hello','nice',NULL,'world');
-> 'hello'
mysql> SELECT MAKE_SET(0,'a','b','c');
-> ''
● MID(str,pos,len)
MID(str,pos,len)은 SUBSTRING(str,pos,len)과 동의어 이다.
● OCT(N)
N의 8진 값에 해당하는 스트링 표현식을 리턴하는데, 여기에서 N 은 (BIGINT) 번호가 된다. 이것은 CONV(N,10,8)과
같다. 만일 N 이 NULL이면, NULL을 리턴한다.
mysql> SELECT OCT(12);
-> '14'
● OCTET_LENGTH(str)
OCTET_LENGTH()는 LENGTH()과 동의어 이다.

:::MySQL Korea:::
● ORD(str)
만일 If the leftmost character of the string스트링 str 의 가장 왼쪽의 문자가 다중 바이트 문자라면, 그 문자에 대한 코
드를 리턴하는데, 그 값은 아래의 공식을 사용해서 얻어낸다:
(1st byte code)
+ (2nd byte code × 256)
+ (3rd byte code × 2562) ...
만일 가장 왼쪽의 문자가 다중 바이트 문자가 아니라면, ORD()는 ASCII() 함수와 같은 값을 리턴한다.
mysql> SELECT ORD('2');
-> 50
● POSITION(substr IN str)
POSITION(substr IN str)는 LOCATE(substr,str)과 동의어 이다.
● QUOTE(str)
SQL 명령문에서 이스케이프된 데이터 값으로 사용할 수 있는 결과를 만들기 위해 스트링에 인용 부호를 준다. 만일 인수
가 NULL이면, 리턴 값은 인용 부호가 없는 단어 “NULL” 이 나오게 된다.
mysql> SELECT QUOTE('Don￦'t!');
-> 'Don￦'t!'
mysql> SELECT QUOTE(NULL);
-> NULL
● REPEAT(str,count)
count 횟수 만큼 반복된 스트링 str 으로 구성된 스트링을 리턴한다. 만일 count 가 1 보다 작을 경우에는, 빈 스트링을 리
턴한다. str 또는 count 가 NULL이라면, NULL을 리턴한다
mysql> SELECT REPEAT('MySQL', 3);
-> 'MySQLMySQLMySQL'

:::MySQL Korea:::
● REPLACE(str,from_str,to_str)
스트링 from_str 가 나온 부분을 모두 스트링 to_str로 대체해서 스트링 str 을 리턴한다. REPLACE()은
from_str에 대한 검색을 할 때 문자 크기를 구분해서 매칭을 실행한다.
mysql> SELECT REPLACE('www.mysql.com', 'w', 'Ww');
-> 'WwWwWw.mysql.com'
● REVERSE(str)
문자의 순서를 역순으로 헤서 스트링 str 을 리턴한다.

mysql> SELECT REVERSE('abc');
-> 'cba'
● RIGHT(str,len)
str에서 오른쪽으로부터 len 문자 만큼을 리턴한다.

mysql> SELECT RIGHT('foobarbar', 4);
-> 'rbar'
● RPAD(str,len,padstr)
스트링 padstr 를 오른쪽에 집어 넣어서 len 문자 길이 만큼 str을 만들어서 리턴한다. 만일 str 가 len 보다 길다면, 리턴
값은 len 문자 만큼 짧아진다.
mysql> SELECT RPAD('hi',5,'?');
-> 'hi???'
mysql> SELECT RPAD('hi',1,'?');
-> 'h'

:::MySQL Korea:::
● RTRIM(str)
스트링 str에서 뒤에 붙어 있는 스페이스 문자를 없앤 스트링을 리턴한다.

mysql> SELECT RTRIM('barbar ');
-> 'barbar'
● SOUNDEX(str)
Str의 사운덱스(soundex) 스트링을 리턴한다. 거의 같은 소리가 나는 두 개의 스트링은 고유의 사운덱스 스트링을 가져

야 한다. 표준 사운덱스 스트링은 4 문자 길이가 되지만, SOUNDEX() 함수는 임의의 길이 스트링을 리턴한다. 여러분은
표준 사운덱스 스트링을 얻기 위해서 결과 값에 SUBSTRING()을 사용할 수가 있다. str에 있는 문자 중에 알파벳이 아
닌 것들은 모두 무시가 된다. A-Z 범위를 벗어나는 모든 국제 문자들은 모두 모음으로 취급된다.
mysql> SELECT SOUNDEX('Hello');
-> 'H400'
mysql> SELECT SOUNDEX('Quadratically');
-> 'Q36324'
● expr1 SOUNDS LIKE expr2
이것은 SOUNDEX(expr1) = SOUNDEX(expr2)과 같다.
● SPACE(N)
N 개의 스페이스 문자로 구성된 스트링을 리턴한다.

mysql> SELECT SPACE(6);
-> ' '
● SUBSTRING(str,pos), SUBSTRING(str FROM pos), SUBSTRING(str,pos,len), SUBSTRING(str FROM pos

FOR len)

:::MySQL Korea:::
len 인수가 없는 형태는 포지션 pos에서 시작을 하는 서브 스트링을 스트링 str 에서 리턴 한다. len 인수를 가지고 있는
형태는 포지션 pos에서 시작을 해서 서브 스트링 len 문자를 리턴한다. FROM을 사용하는 형태는 표준 SQL 신텍스이다.
pos의 값으로 음수를 사용하는 것도 가능하다. 음수를 사용할 경우에는, 서브 스트링의 시작점이 스트링의 처음이 아닌 끝
에서부터 pos 문자 위치가 된다. 음수 값은 이 함수의 어떤 형태에서도 사용이 가능하다.
mysql> SELECT SUBSTRING('Quadratically',5);
-> 'ratically'
mysql> SELECT SUBSTRING('foobarbar' FROM 4);
-> 'barbar'
mysql> SELECT SUBSTRING('Quadratically',5,6);
-> 'ratica'
mysql> SELECT SUBSTRING('Sakila', -3);
-> 'ila'
mysql> SELECT SUBSTRING('Sakila', -5, 3);
-> 'aki'
mysql> SELECT SUBSTRING('Sakila' FROM -4 FOR 2);
-> 'ki'
만일 len 이 1 보다 작으면, 그 결과는 빈 스트링이 된다.
SUBSTR()은 SUBSTRING()과 동일하다.
● SUBSTRING_INDEX(str,delim,count)
구분자 (delimiter) delim가 count 만큼 나오기 전에 스트링 str 에서 서브 스트링을 리턴한다. 만일 count 가 양수
(positive)라면, 마지막 구분자의 왼쪽에 있는 모든 것들이 리턴된다 (왼쪽부터 계산이 됨). 만일 count 가 음수일 경우에
는, 마지막 구분자의 오른쪽에 있는 모든 것들이 리턴된다 (오른쪽부터 계산됨). SUBSTRING_INDEX()는 delim에 대
한 검색을 할 때 문자의 크기를 구분한다.
mysql> SELECT SUBSTRING_INDEX('www.mysql.com', '.', 2);
-> 'www.mysql'
mysql> SELECT SUBSTRING_INDEX('www.mysql.com', '.', -2);
-> 'mysql.com'
이 함수는 다중 바이트를 지원한다.

:::MySQL Korea:::
● TRIM([{BOTH | LEADING | TRAILING} [remstr] FROM] str), TRIM([remstr FROM] str)
스트링 str 를 모든 remstr 접두사 (prefixes) 또는 접미사를 제거한 상태로 리턴한다. 만일 BOTH, LEADING, 또는
TRAILING 중의 어느 것도 주어지지 않는다면, BOTH가 주어진 것으로 간주된다. remstr 는 선택 사항이며, 만일 지정
되지 않을 경우에는, 스페이스가 제거된다.
mysql> SELECT TRIM(' bar ');
-> 'bar'
mysql> SELECT TRIM(LEADING 'x' FROM 'xxxbarxxx');
-> 'barxxx'
mysql> SELECT TRIM(BOTH 'x' FROM 'xxxbarxxx');
-> 'bar'
mysql> SELECT TRIM(TRAILING 'xyz' FROM 'barxxyz');
-> 'barx'
● UCASE(str)
UCASE()는 UPPER()와 동의어이다.
● UNHEX(str)
HEX(str)와는 반대 연산을 실행한다. 즉, 이 함수는 인수에 있는 각각의 16진수를 숫자로 해석을 하고 그 숫자에 대응하
는 문자로 변환을 시킨다. 그 결과로 나오는 문자들은 바이너리 스트링으로 리턴된다.
mysql> SELECT UNHEX('4D7953514C');
-> 'MySQL'
mysql> SELECT 0x4D7953514C;
-> 'MySQL'
mysql> SELECT UNHEX(HEX('string'));
-> 'string'
mysql> SELECT HEX(UNHEX('1267'));

:::MySQL Korea:::
-> '1267'
● UPPER(str)
Returns 스트링 str 를 현재의 (current) 문자 셋 매핑에 따라서 대문자로 변환이 된 모든 문자와 함께 리턴한다. 디폴트
는 latin1 (cp1252 West European).
mysql> SELECT UPPER('Hej');
-> 'HEJ'

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.4. 숫자 함수
12. 함수와 연산자 12.4.1. 산술 연산

12.4. 숫자 함수 자
12.4 숫자 함수 12.4.2. 수학 함수
12.4.1 산술 연산자
12.4.2 수학 함수
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.4.1. 산술 연산자
12.4. 숫자 함수 일반적인 산술 연산자를 사용할 수가 있다. -, +, 그리고 * 의 경우, 양쪽의 인수가 모두 정수일 경우에는 BIGINT (64-bit) 정밀
12.4.1 산술 연산자 도로 계산된다는 점을 알아두자. 만일 인수 중의 하나가 부호화되지 않은 정수라면, 그리고 다른 인수 또한 정수일 경우에는, 그 결
과는 부화화 되지 않은 정수가 된다. Section 12.8, “캐스트 함수 (Cast Functions)와 연산자”.
● +
덧셈:
mysql> SELECT 3+5;
-> 8
● -
뺄셈:
mysql> SELECT 3-5;
-> -2
● -
음수 부호. 이 연산자는 인수의 부호를 변경 시킨다.

:::MySQL Korea:::
mysql> SELECT - 2;
-> -2
Note: 만일 이 연산자가 BIGINT과 함께 사용된다면, 리턴 값 역시 BIGINT가 된다.
● *
곱셈:
mysql> SELECT 3*5;
-> 15
mysql> SELECT 18014398509481984*18014398509481984.0;
-> 324518553658426726783156020576256.0
mysql> SELECT 18014398509481984*18014398509481984;
-> 0
마지막 수식의 결과는 옳게 나온 것이 아닌데, 그 이유는 정수 곱셈의 결과 값이 BIGINT 계산의 64 비트 범위를 벗어 났

기 때문이다. (Section 11.2, “숫자 타입”을 참조.)
● /
나눗셈:
mysql> SELECT 3/5;
-> 0.60

:::MySQL Korea:::
0으로 나눗셈을 하면 NULL 이 나온다:
mysql> SELECT 102/(1-1);
-> NULL
처리되는 문맥의 결과가 정수로 변환되는 경우에만 나눗셈을 BIGINT과 함께 사용할 수가 있다.
● DIV
정수 나눗셈. FLOOR()과 비슷하지만, BIGINT 값과 함께 사용하는 것이 안전하다.
mysql> SELECT 5 DIV 2;
-> 2

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.4.2. 수학 함수
12.4. 숫자 함수 에러가 발생하는 경우에, 모든 수학 함수는 NULL을 리턴한다.
12.4.2 수학 함수
● ABS(X)
X의 절대 값을 리턴한다.
mysql> SELECT ABS(2);
-> 2
mysql> SELECT ABS(-32);
-> 32
이 함수는 BIGINT 값과 함께 사용하는 것이 안전하다.
● ACOS(X)
X의 아크 코사인(arc cosine) 값을 리턴한다. 즉, 코사인이 X인 값을 리턴한다. 만일 X 가 -1 에서 1 사이의 범위에 있지

않으면, NULL을 리턴한다.
mysql> SELECT ACOS(1);
-> 0

:::MySQL Korea:::
mysql> SELECT ACOS(1.0001);
-> NULL
mysql> SELECT ACOS(0);
-> 1.5707963267949
● ASIN(X)
X 의 아크 사인 값(arc sine)을 리턴 한다. 즉 사인 값이 X인 값. 만일 X 가 -1 에서 1 사이의 범위에 있지 않으면, NULL

을 리턴 한다.
mysql> SELECT ASIN(0.2);
-> 0.20135792079033
mysql> SELECT ASIN('foo');
+-------------+
| ASIN('foo') |
+-------------+
| 0|
+-------------+
1 row in set, 1 warning (0.00 sec)

:::MySQL Korea:::
+---------+------+-----------------------------------------+
+---------+------+-----------------------------------------+
| Warning | 1292 | Truncated incorrect DOUBLE value: 'foo' |
+---------+------+-----------------------------------------+
● ATAN(X)
Returns the arc tangent of X의 아크 탄젠트(arc tangent) 값을 리턴한다. 즉, 탄젠트가 X인 값.
mysql> SELECT ATAN(2);
-> 1.1071487177941
mysql> SELECT ATAN(-2);
-> -1.1071487177941
● ATAN(Y,X), ATAN2(Y,X)
두 변수 X 와 Y의 아크 탄젠트 값을 리턴한다. 이것은 Y / X의 아크 탄젠트 값을 계산하는 방식과 유사하지만, 두 인수의

부호는 결과에 대한 쿼드런트 (quadrant)를 알아내기 위해 사용된다는 점은 틀리다.

:::MySQL Korea:::
mysql> SELECT ATAN(-2,2);
-> -0.78539816339745
mysql> SELECT ATAN2(PI(),0);
-> 1.5707963267949
● CEILING(X), CEIL(X)
X 보다는 작지 않은 가장 작은 정수 값을 리턴한다.
mysql> SELECT CEILING(1.23);
-> 2
mysql> SELECT CEIL(-1.23);
-> -1
위의 두 함수는 동일한 것이다. 리턴 값은 BIGINT으로 변환된다는 점은 알아 두자.
● COS(X)
X 의 코사인 값을 리턴 하는데, 여기에서 X 는 레디안(radian)으로 주어진다.
mysql> SELECT COS(PI());
-> -1
● COT(X)

:::MySQL Korea:::
X 의 코 탄젠트 값을 리턴한다.
mysql> SELECT COT(12);
-> -1.5726734063977
mysql> SELECT COT(0);
-> NULL
● CRC32(expr)
싸이클릭 리던던시 체크 값 (cyclic redundancy check value)을 계산한 다음에 32-비트 부호화되지 않은 값을 리턴한
다. 인수가 NULL이면 NULL을 리턴한다. 인수는 스트링 값이 되어야 한다.
mysql> SELECT CRC32('MySQL');
-> 3259397556
mysql> SELECT CRC32('mysql');
-> 2501908538
● DEGREES(X)
인수 X를 리턴하는데, 레디안에서 차수 (degree)로 변경된 값이 나온다.
mysql> SELECT DEGREES(PI());
-> 180
mysql> SELECT DEGREES(PI() / 2);

:::MySQL Korea:::
-> 90
● EXP(X)
X 의 제곱에 대한 e (자연 로그 근) 값을 리턴한다.
mysql> SELECT EXP(2);
-> 7.3890560989307
mysql> SELECT EXP(-2);
-> 0.13533528323661
mysql> SELECT EXP(0);
-> 1
● FLOOR(X)
X 보다 크지 않은 정수 중에 가장 큰 값을 리턴 한다.
mysql> SELECT FLOOR(1.23);
-> 1
mysql> SELECT FLOOR(-1.23);
-> -2
리턴 값이 BIGINT로 변환 된다는 점을 알아 두자.

:::MySQL Korea:::
● FORMAT(X,D)
숫자 X 의 형태를 '#,###,###.##'로 변경 시키고, D 자릿수 위치에서 절사를 한 다음에, 그 결과를 스트링으로 리턴한
다. 보다 자세한 사항은, Section 12.3, “스트링 함수”를 참조할 것.
● LN(X)
X의 자연 로그를 리턴한다; 즉, X의 베이스-e 로그.
mysql> SELECT LN(2);
-> 0.69314718055995
mysql> SELECT LN(-2);
-> NULL
이 함수는 LOG(X)과 동의어 이다.
● LOG(X), LOG(B,X)
만일 하나의 파라미터를 사용해서 호출이 되면, 이 함수는 X의 자연 로그를 리턴한다.
mysql> SELECT LOG(2);
-> 0.69314718055995
mysql> SELECT LOG(-2);
-> NULL
만일 두 개의 파라미터를 사용해서 호출을 하면, 이 함수는 부정 베이스 (arbitrary base) B 에 대한 X의 자연 로그를 리

턴 한다.

:::MySQL Korea:::
mysql> SELECT LOG(2,65536);
-> 16
mysql> SELECT LOG(10,100);
-> 2
LOG(B,X)는 LOG(X) / LOG(B)과 동의어 이다.
● LOG2(X)
X의 베이스-e 로그를 리턴한다.
mysql> SELECT LOG2(65536);
-> 16
mysql> SELECT LOG2(-100);
-> NULL
LOG2()는 스토리지용으로 필요한 비트의 수가 얼마나 되는지를 알아 보는데 유용하다. 이 함수는 LOG(X) / LOG(2)과
동일하다.
● LOG10(X)
X의 베이스-10 로그를 리턴한다.

:::MySQL Korea:::
-> 0.30102999566398
-> 2
mysql> SELECT LOG10(-100);
-> NULL
LOG10(X)는 LOG(10,X)과 동일하다.
● MOD(N,M), N % M, N MOD M
모듈러 연산. M으로 나누어진 N의 나머지를 리턴한다.
mysql> SELECT MOD(234, 10);
-> 4
mysql> SELECT 253 % 7;
-> 1
-> 2
mysql> SELECT 29 MOD 9;
-> 2

:::MySQL Korea:::
이 함수는 BIGINT 값과 함께 사용할 수가 있다.

MOD()는 분수를 가지고 있는 값에서도 동작을 하며 나눗셈을 한 다음에 정확히 나머지 값을리턴한다:
mysql> SELECT MOD(34.5,3);
-> 1.5
● PI()
π (pi) 값을 리턴 한다. 출력되는 기본 자릿수는 7 자리이지만, MySQL은 내부적으로는 전 이중 정밀도(full double-

precision) 값을 사용한다.
mysql> SELECT PI();
-> 3.141593
mysql> SELECT PI()+0.000000000000000000;
-> 3.141592653589793116
● POW(X,Y), POWER(X,Y)
Y 제곱이 된 X 값을 리턴한다.
mysql> SELECT POW(2,2);
-> 4
mysql> SELECT POW(2,-2);
-> 0.25
● RADIANS(X)

:::MySQL Korea:::
각도를 레디안으로 변경한 인수 X를 리턴한다. (π 레디안은 180 도와 동일하다.)
mysql> SELECT RADIANS(90);
-> 1.5707963267949
● RAND(), RAND(N)
0 과 1 사이의 무작위 부정 소수점 값 v 를 리턴한다 (즉, 0 <= v <= 1.0 사이의 범위). 만일 정수 인수 N이 지정 되
었다면, 이것은 시드 값(seed value)로 사용되며, 반복 시퀀스를 만들어 낸다.
mysql> SELECT RAND();
-> 0.9233482386203
mysql> SELECT RAND(20);
-> 0.15888261251047
-> 0.15888261251047
-> 0.63553050033332
-> 0.70100469486881

:::MySQL Korea:::
-> 0.15888261251047
i <= R <= j 범위에서 임의적으로 정수 R 을 얻기 위해서는, 수식 FLOOR(i + RAND() * (j – i)을 사용한다. 예

를 들면, 1에서 12 사이의 범위에서 임의의 정수를 얻고자 한다면, 아래의 명령문을 사용하면 된다:
SELECT FLOOR(7 + (RAND() * 5));
ORDER BY 구문에서는 RAND() 값을 사용하는 컬럼을 사용할 수가 없는데, 그 이유는 ORDER BY가 그 컬럼을 여러 번
계산하기 때문이다. 하지만, 아래와 같이 무작위로 열을 추출할 수는 있다:
mysql> SELECT * FROM tbl_name ORDER BY RAND();
LIMIT과 결합이 된 ORDER BY RAND()는 열로 이루어진 셋에서 무작위 샘플을 선택하는 경우에 유용하게 사용할 수
가 있다:
mysql> SELECT * FROM table1, table2 WHERE a=b AND c<d -> ORDER BY RAND() LIMIT 1000;
WHERE 구문에 있는 RAND()는 WHERE 구문이 실행될 때마다 반복적으로 계산된다는 점을 알아 두기 바란다.
RAND()는 완벽한 무작위 제너레이터는 아니지만, 동일 MySQL 버전을 사용하고 있는 플랫폼간에 이식성이 있는 ad
hoc 랜덤 숫자를 만들기에는 속도가 빠른 방식이다.
● ROUND(X), ROUND(X,D)
인수 X를 리턴 하는데, 이때에는 이와 가장 가까운 정수로 절사가 된다. 두 개의 인수를 사용하면, D 자릿수에서 절사가
된 X 가 리턴 된다. D 는 음수로 표시될 수도 있는데, 이렇게 하면 소수점에서 왼쪽으로 D 자리에 있는 X 의 값이 0 이 된
다.
mysql> SELECT ROUND(-1.23);
-> -1

:::MySQL Korea:::
mysql> SELECT ROUND(-1.58);
-> -2
mysql> SELECT ROUND(1.58);
-> 2
mysql> SELECT ROUND(1.298, 1);
-> 1.3
mysql> SELECT ROUND(1.298, 0);
-> 1
mysql> SELECT ROUND(23.298, -1);
-> 20
리턴 타입은 첫 번째 인수와 같은 타입이 된다. 이것은 정수 인수의 경우에는, 그 결과가 정수 (소수점이 없는)가 된다는
것을 의미하는 것이다.
MySQL 5.0.3 이전에는, 인수가 두 개의 정수 사이의 절반에 해당될 때 ROUND()는 C 라이브러리의 실행에 따라서 값
을 리턴 했다. 이 방식은 항상 반올림, 잘라냄, 0으로 만들기와 같은 방식을 취했다. 만일 한 가지 방식의 절사 (rounding)
방식만을 사용하고자 할 경우에는 TRUNCATE() 또는 FLOOR()와 같은 함수를 대신 사용하는 것이 좋다.
MySQL 5.0.3 이후에는, ROUND()는 첫 번째 인수가 10진수 값일 경우에는 정확한 인수 값을 얻기 위해서 정밀도 수학
라이브러리(precision math library)를 사용한다:
❍ 정확한 숫자를 얻기 위해서, ROUND()는 “반올림 (round half up)” 또는 “가장 가까운 값으로 절사 (round
toward nearest)” 규칙을 사용한다: 어떤 수의 소수점 이하 부분이 .5 보다 크거나 같을 경우에는, 그 수가 양수
라면 바로 다음의 정수로, 그 수가 음수일 경우에는, 바로 이전 정수로 절사 (round)를 한다 (즉, 소수 부분을 0 으

:::MySQL Korea:::
로 만든다). 소수점 이하의 숫자가 .5보다 작을 경우에는, 그 수가 양수라면 바로 이전 정수로, 음수일 경우에는 바
로 다음 정수로 된다.
❍ 추정 값 숫자에 대해서는, C 라이브러리에 따라서 그 결과가 나온다. 대부분의 시스템에서는, ROUND()가 "가장
근접한 짝수로 절사 (round to nearest even)" 규칙을 사용한다: 소수점 이하 부분이 있는 값은 가장 근접한 정수
로 된다.
아래의 예문은 정확한 값과 추정 값을 어떻게 서로 다르게 라운딩 (rounding)하는지를 보여준다:
mysql> SELECT ROUND(2.5), ROUND(25E-1);
+------------+--------------+
| ROUND(2.5) | ROUND(25E-1) |
+------------+--------------+
|3 | 2|
+------------+--------------+
보다 자세한 정보는, Chapter 21, Precision Math를 참고한다.
● SIGN(X)
인수의 부호를 -1, 0, 또는 1로 리턴 하는데, 여기에서 리턴 되는 숫자는 각각 음수, 0, 양수를 나타내는 것이다.
mysql> SELECT SIGN(-32);
-> -1
mysql> SELECT SIGN(0);

:::MySQL Korea:::
-> 0
mysql> SELECT SIGN(234);
-> 1
● SIN(X)
래디안으로 주어진 X의 싸인(sin) 값을 리턴 한다.
mysql> SELECT SIN(PI());
-> 1.2246063538224e-16
mysql> SELECT ROUND(SIN(PI()));
-> 0
● SQRT(X)
음수가 아닌 X의 제곱 루트(square root) 값을 리턴한다.
mysql> SELECT SQRT(4);
-> 2
mysql> SELECT SQRT(20);
-> 4.4721359549996
mysql> SELECT SQRT(-16);

:::MySQL Korea:::
-> NULL
● TAN(X)
래디안으로 주어진 X의 탄젠트 값을 리턴한다.
mysql> SELECT TAN(PI());
-> -1.2246063538224e-16
mysql> SELECT TAN(PI()+1);
-> 1.5574077246549
● TRUNCATE(X,D)
숫자 X를 D 자릿수 뒤의 숫자를 없앤 후 리턴한다. 만일 D가 0 이면, 리턴되는 숫자는 소수점 또는 소수 부분이 없게 된

다. D는 음수로 표시할 수도 있는데, 이렇게 표시하면 숫자 X의 D 자리로부터 왼쪽 부분이 0으로 표시가 된다.
mysql> SELECT TRUNCATE(1.223,1);
-> 1.2
-> 1.9
-> 1
mysql> SELECT TRUNCATE(-1.999,1);

:::MySQL Korea:::
-> -1.9
mysql> SELECT TRUNCATE(122,-2);
-> 100
mysql> SELECT TRUNCATE(10.28*100,0);
-> 1028

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.5. 날짜 및 시간 함수(1)
12. 함수와 연산자 이 섹션에서는 임시 값 (temporal value)을 처리하는 함수에 대해서 설명을 하기로 하겠다.
12.5. 날짜 및 시간 함수(1) 아래의 명령문은 날짜 함수 사용에 대한 예문이다. 예문에 나와 있는 쿼리는 최근 30일 동안에 date_col 값을 가지고 있는 모든 열
12.5 날짜 및 시간 함수(1) 을 선택하는 것이다:
12.5 날짜 및 시간 함수(2) mysql> SELECT something FROM tbl_name

-> WHERE DATE_SUB(CURDATE(),INTERVAL 30 DAY) <= date_col;
날짜 값을 기대하는 함수는 일반적으로 데이트타임(datetime)을 수용하지만 시간 부분은 무시 한다. 반면에, 타임 값을 기대하는
함수는 일반적으로 데이트 타임 값을 수용하지만 날짜 부분은 무시를 한다.
현재 날짜 또는 시간을 각각 리턴하는 함수는 쿼리가 실행되는 시작 시점에서 쿼리 당 한번씩만 계산을 한다. 이것은, 하나의 쿼리
안에 있는 NOW()와 같은 함수를 여러 번 참조하더라도 항상 같은 값이 나온다는 것을 의미하는 것이다. 이러한 방식은
CURDATE(), CURTIME(), UTC_DATE(), UTC_TIME(), UTC_TIMESTAMP(), 그리고 이 함수들과 동일한 기능을 하는 함
수들에도 적용이 된다.
CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE(), 그리고 FROM_UNIXTIME() 함수는 연결이 된 현
재 (current)의 타임 존에 있는 값을 리턴하는데, 이것은 time_zone 시스템 변수의 값으로 사용 가능하다. 또한,
UNIX_TIMESTAMP()는 자신의 인수가 현재의 타임 존에 있는 데이트타임 값이라고 가정을 한다. Section 5.11.8, “MySQL 서
버 타임 존 지원”을 참조할 것.
몇몇 날짜 함수는 “제로 (zero)” 날짜 또는 '2001-11-00'와 같이 완전하지 않은 형태의 날짜를 수용한다. 날짜 부분을 추출하
는 함수는 전형적으로 이러한 값들을 수용한다. 예를 들면:
mysql> SELECT DAYOFMONTH('2001-11-00'), MONTH('2005-00-00');
-> 0, 0
이외의 함수들은 완전한 형태의 날짜를 사용하며, 완전하지 않은 형태에 대해서는 NULL을 리턴한다. 날짜를 수학적으로 계산하거
나 또는 날짜 부분을 이름과 매핑시키는 함수들이 여기에 해당한다. 예를 들면:
mysql> SELECT DATE_ADD('2006-05-00',INTERVAL 1 DAY);
-> NULL
mysql> SELECT DAYNAME('2006-05-00');

:::MySQL Korea:::
-> NULL
● ADDDATE(date,INTERVAL expr unit), ADDDATE(expr,days)
두 번째 인수에 INTERVAL 폼을 사용해서 호출을 하게 되면, ADDDATE()는 DATE_ADD()과 동일한 값을 리턴한다.

이 함수와 관련을 갖는 SUBDATE() 함수는 DATE_SUB()과 동일한 것이다. INTERVAL unit 인수에 대한 정보는
DATE_ADD() 함수 설명을 참조하기 바란다.
mysql> SELECT DATE_ADD('1998-01-02', INTERVAL 31 DAY);
-> '1998-02-02'
mysql> SELECT ADDDATE('1998-01-02', INTERVAL 31 DAY);
-> '1998-02-02'
두 번째 인수를 days 폼으로 호출하면, MySQL은 이것을 expr에 추가되어야 하는 날짜 일수로 처리를 한다.
mysql> SELECT ADDDATE('1998-01-02', 31);
-> '1998-02-02'
● ADDTIME(expr1,expr2)
ADDTIME()는 expr2 를 expr1 에 추가한 다음에 그 결과를 리턴 한다. expr1 는 타임 또는 데이트 타임 수식이며,
expr2 는 타임 수식이다.
mysql> SELECT ADDTIME('1997-12-31 23:59:59.999999',
-> '1 1:1:1.000002');
-> '1998-01-02 01:01:01.000001'
mysql> SELECT ADDTIME('01:00:00.999999', '02:00:00.999998');
-> '03:00:01.999997'
● CONVERT_TZ(dt,from_tz,to_tz)
CONVERT_TZ()는 from_tz에 의해 주어진 타임 존의 데이트 타임 값 dt를 to_tz에 의해 주어지는 타임 존으로 변환을

시키고 그 결과 스트링을 리턴한다. 타임 존에 대해서는 Section 5.11.8, “MySQL 서버 타임 존 지원”을 참조하기 바란
다. 이 함수는 인수가 올바르지 않을 경우에는 NULL을 리턴한다.
만일 그 값이 from_tz에서 UTC로 변환이 될 때 TIMESTAMP 타임의 지원 범위를 벗어 나게 되는 경우에는, 아무런 변

:::MySQL Korea:::
환도 일어나지 않는다. TIMESTAMP 범위는 Section 11.1.2, “날짜 및 시간 타입 개요”를 참조하기 바란다.
mysql> SELECT CONVERT_TZ('2004-01-01 12:00:00','GMT','MET');
-> '2004-01-01 13:00:00'
mysql> SELECT CONVERT_TZ('2004-01-01 12:00:00','+00:00','+10:00');
-> '2004-01-01 22:00:00'
Note: 'MET' 또는 'Europe/Moscow'와 같은 네임드 타임 존을 사용하기 위해서는, 그 타임 존 테이블은 반드시 올바르
게 설정이 되어 있어야 한다. Section 5.11.8, “MySQL 서버 타임 존 지원”을 참조할 것.
만일 다른 테이블들이 LOCK TABLES과 함께 잠겨 있는 동안에 CONVERT_TZ() 함수를 사용하고자 한다면, 여러분은
반드시 mysql.time_zone_name 테이블도 잠가 두어야 한다.
● CURDATE()
이 함수가 스트링 또는 숫자 문장 안에서 사용되는 것에 따라서, 현재의 날짜를 'YYYY-MM-DD' 또는 YYYYMMDD 포

맷 형태의 값으로 리턴한다.
mysql> SELECT CURDATE();
-> '1997-12-15'
mysql> SELECT CURDATE() + 0;
-> 19971215
● CURRENT_DATE, CURRENT_DATE()
CURRENT_DATE 및 CURRENT_DATE()는 CURDATE()과 동일한 함수이다.
● CURTIME()
이 함수가 스트링 또는 숫자 문장 안에서 사용되는 것에 따라서, 현재 시간을 'HH:MM:SS' 또는 HHMMSS 포맷 형태로

리턴한다.
mysql> SELECT CURTIME();
-> '23:50:26'
mysql> SELECT CURTIME() + 0;
-> 235026

:::MySQL Korea:::
● CURRENT_TIME, CURRENT_TIME()
CURRENT_TIME 및 CURRENT_TIME()는 CURTIME()와 동일한 함수이다.
● CURRENT_TIMESTAMP, CURRENT_TIMESTAMP()
CURRENT_TIMESTAMP 및 CURRENT_TIMESTAMP()는 NOW()과 동일한 함수이다.
● DATE(expr)
날짜 또는 데이트 타임 수식 expr에서 날짜 부분을 추출한다.

mysql> SELECT DATE('2003-12-31 01:02:03');
-> '2003-12-31'
● DATEDIFF(expr1,expr2)
DATEDIFF()는 두 날짜 간의 차이를 expr1 – expr2 수식의 결과 값으로 리턴한다. expr1 및 expr2는 날짜 또는 날

짜-및-시간 수식이 될 수 있다. 이 함수에서는 오직 날짜 값만이 계산에서 사용된다.
mysql> SELECT DATEDIFF('1997-12-31 23:59:59','1997-12-30');
-> 1
mysql> SELECT DATEDIFF('1997-11-30 23:59:59','1997-12-31');
-> -31
● DATE_ADD(date,INTERVAL expr unit), DATE_SUB(date,INTERVAL expr unit)
이 함수들은 날짜 산술식 (date arithmetic)을 실행한다. date는 시작 날짜를 지정하는 DATETIME 또는 DATE 값이
다. expr는 시작 날짜에서 더해지거나 빼지는 간격 값 (interval value)를 나타내는 수식이다. expr 는 스트링이다; 이것
은 음수 기호 ‘-’를 사용할 수도 있다. unit 는 수식이 해석되어야 하는 유닛을 가리키는 키워드이다.
INTERVAL 키워드 및 unit 는 문자 크기를 구분하지 않는다.
아래의 테이블은 각각의 unit 값에 대한 expr 인수의 예상 형태를 보여주는 것이다.

:::MySQL Korea:::
unit Value Expected expr Format
MICROSECOND MICROSECONDS
SECOND SECONDS
MINUTE MINUTES
HOUR HOURS
DAY DAYS
WEEK WEEKS
MONTH MONTHS
QUARTER QUARTERS
YEAR YEARS
SECOND_MICROSECOND 'SECONDS.MICROSECONDS'
MINUTE_MICROSECOND 'MINUTES.MICROSECONDS'
MINUTE_SECOND 'MINUTES:SECONDS'
HOUR_MICROSECOND 'HOURS.MICROSECONDS'
HOUR_SECOND 'HOURS:MINUTES:SECONDS'
HOUR_MINUTE 'HOURS:MINUTES'
DAY_MICROSECOND 'DAYS.MICROSECONDS'
DAY_SECOND 'DAYS HOURS:MINUTES:SECONDS'
DAY_MINUTE 'DAYS HOURS:MINUTES'
DAY_HOUR 'DAYS HOURS'
YEAR_MONTH 'YEARS-MONTHS'
QUARTER 및 WEEK는 MySQL 5.0.0에서부터 사용 가능해 졌다.

MySQL은 expr 포맷 안에서 모든 구두점 구분자를 사용하는 것을 허용한다. 위의 테이블에 나와 있는 것들은 제안 형식
이다. 만일 date 인수가 DATE 값이고 여러분이 사용하는 계산식이 YEAR, MONTH만을 포함하고 있으며, 그리고 DAY
부분 (즉, 타임 부분이 없음)만을 사용한다면, 그 결과는 DATE 값이 된다. 그렇지 않을 경우에는, 그 결과는

:::MySQL Korea:::
DATETIME 값이 된다.
날짜 계산식은 또한 INTERVAL을 + 또는 – 연산자와 함께 사용할 수도 있다:
date + INTERVAL expr unit
date - INTERVAL expr unit
INTERVAL expr unit 는, 다른 쪽에 있는 수식이 날짜 또는 데이트 타임 값일 경우에는 + 연산자를 중심으로 어느쪽에
도 올 수가 있다. – 연산자의 경우, INTERVAL expr unit는 오른쪽 부분에만 나올 수가 있는데, 그 이유는 인터벌에서
데이트 타임 또는 날짜를 뺀다는 것이 의미가 없기 때문이다.
mysql> SELECT '1997-12-31 23:59:59' + INTERVAL 1 SECOND;
-> '1998-01-01 00:00:00'
mysql> SELECT INTERVAL 1 DAY + '1997-12-31';
-> '1998-01-01'
mysql> SELECT '1998-01-01' - INTERVAL 1 SECOND;
-> '1997-12-31 23:59:59'
mysql> SELECT DATE_ADD('1997-12-31 23:59:59',
-> INTERVAL 1 SECOND);
-> '1998-01-01 00:00:00'
-> INTERVAL 1 DAY);
-> '1998-01-01 23:59:59'
-> INTERVAL '1:1' MINUTE_SECOND);
-> '1998-01-01 00:01:00'
mysql> SELECT DATE_SUB('1998-01-01 00:00:00',
-> INTERVAL '1 1:1:1' DAY_SECOND);
-> '1997-12-30 22:58:59'
-> INTERVAL '-1 10' DAY_HOUR);
-> '1997-12-30 14:00:00'
mysql> SELECT DATE_SUB('1998-01-02', INTERVAL 31 DAY);
-> '1997-12-02'

:::MySQL Korea:::
mysql> SELECT DATE_ADD('1992-12-31 23:59:59.000002',

-> INTERVAL '1.999999' SECOND_MICROSECOND);
-> '1993-01-01 00:00:01.000001'
만일 너무 짧은 인터벌 값을 지정한다면, MySQL은 여러분이 인터벌 값의 맨 왼쪽 부분을 생략했다고 가정을 한다. 예를
들면, 만일 여러분이 DAY_SECOND의 unit 부분을 지정한다면, expr 의 값은 날짜, 시간, 분, 그리고 초 부분을 가져야 한
다고 가정을 한다. 만일 어떤 값을 '1:10'처럼 지정할 경우에는, MySQL은 날짜 및 시간 (hour) 부분이 누락이 되고 분과
초만 표시되었다고 가정을 한다. 달리 표현하면, '1:10' DAY_SECOND는 '1:10' MINUTE_SECOND로 해석이 된다. 이
것은 MySQL 이 TIME 값을 일별 시간이 아닌 경과 시간으로 표현한 것으로 해석하는 것과 같은 방식이다.
만일 시간 부분이 있는 특정 날짜 값에서 날짜를 더하거나 빼게 되는 경우, 그 결과는 자동적으로 데이트타임 값으로 변환
된다:
-> '1999-01-02'
mysql> SELECT DATE_ADD('1999-01-01', INTERVAL 1 HOUR);
-> '1999-01-01 01:00:00'
만일 여러분이 MONTH, YEAR_MONTH를 더하거나, 또는 YEAR 및 결과 날짜가 새로운 달의 최대 일수보다 크게 된다
면, 그 결과 날짜는 새로운 달의 최대 날짜로 정렬이 된다:
mysql> SELECT DATE_ADD('1998-01-30', INTERVAL 1 MONTH);
-> '1998-02-28'
날짜 산술식 연산은 완벽한 날짜 형태를 요구하며 '2006-07-00'와 같은 완전하지 못한 형태를 가지고는 동작을 하지 않
는다:
-> NULL
mysql> SELECT '2005-03-32' + INTERVAL 1 MONTH;
-> NULL

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.5. 날짜 및 시간 함수(2)
12. 함수와 연산자 ● DATE_FORMAT(date,format)
12.5. 날짜 및 시간 함수(1)
format 스트링에 따라서date 값을 포맷한다.
12.5 날짜 및 시간 함수(1)
아래에 나와 있는 지정자 (specifier)들은 format 스트링안에서 사용할 수 있다. ‘%’ 문자는 지정자 문자를 포맷하기
12.5 날짜 및 시간 함수(2)
전에 필요한 것이다.
Specifier Description
%a Abbreviated weekday name (Sun..Sat)
%b Abbreviated month name (Jan..Dec)
%c Month, numeric (0..12)
%D Day of the month with English suffix (0th, 1st, 2nd, 3rd, …)
%d Day of the month, numeric (00..31)
%e Day of the month, numeric (0..31)
%f Microseconds (000000..999999)
%H Hour (00..23)
%h Hour (01..12)
%I Hour (01..12)
%i Minutes, numeric (00..59)
%j Day of year (001..366)
%k Hour (0..23)

:::MySQL Korea:::
%l Hour (1..12)
%M Month name (January..December)
%m Month, numeric (00..12)
%p AM or PM
%r Time, 12-hour (hh:mm:ss followed by AM or PM)
%S Seconds (00..59)
%s Seconds (00..59)
%T Time, 24-hour (hh:mm:ss)
%U Week (00..53), where Sunday is the first day of the week
%u Week (00..53), where Monday is the first day of the week
%V Week (01..53), where Sunday is the first day of the week; used with %X
%v Week (01..53), where Monday is the first day of the week; used with %x
%W Weekday name (Sunday..Saturday)
%w Day of the week (0=Sunday..6=Saturday)
%X Year for the week where Sunday is the first day of the week, numeric, four digits; used with %V
%x Year for the week, where Monday is the first day of the week, numeric, four digits; used with %v
%Y Year, numeric, four digits
%y Year, numeric (two digits)
%% A literal ‘%’ character
%x x, for any ‘x’ not listed above
달 및 날짜 지정자를 위한 범위는 0에서부터 시작을 한다..

mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00', '%W %M %Y');
-> 'Saturday October 1997'
mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00', '%H:%i:%s');
-> '22:23:00'

:::MySQL Korea:::
mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00',

'%D %y %a %d %m %b %j');
-> '4th 97 Sat 04 10 Oct 277'
mysql> SELECT DATE_FORMAT('1997-10-04 22:23:00',
'%H %k %I %r %T %S %w');
-> '22 22 10 10:23:00 PM 22:23:00 00 6'
mysql> SELECT DATE_FORMAT('1999-01-01', '%X %V');
-> '1998 52'
mysql> SELECT DATE_FORMAT('2006-06-00', '%d');
-> '00'
● DAY(date)
DAY() is a synonym for DAYOFMONTH().
● DAYNAME(date)
date에 대한 주간 요일 이름을 리턴한다.

mysql> SELECT DAYNAME('1998-02-05');
-> 'Thursday'
● DAYOFMONTH(date)
0에서 31 사이의 달별 날짜를 리턴한다.

mysql> SELECT DAYOFMONTH('1998-02-03');
-> 3
● DAYOFWEEK(date)
date에 대한 주간 요일 인덱스를 리턴한다 (1 = Sunday, 2 = Monday, …, 7 = Saturday). 이러한 인덱스들은 ODBC

표준을 따른다.
mysql> SELECT DAYOFWEEK('1998-02-03');

:::MySQL Korea:::
-> 3
● DAYOFYEAR(date)
1에서 366 사이의 date에 해당하는 일수를 리턴한다.

mysql> SELECT DAYOFYEAR('1998-02-03');
-> 34
● EXTRACT(unit FROM date)
EXTRACT() 함수는 DATE_ADD() 또는 DATE_SUB()과 같은 종류의 유닛 지정자를 사용하지만, 날짜 산술식을 실행

하는 것이 아닌 날짜에서 부분을 추출하는 기능을 수행한다..
mysql> SELECT EXTRACT(YEAR FROM '1999-07-02');
-> 1999
mysql> SELECT EXTRACT(YEAR_MONTH FROM '1999-07-02 01:02:03');
-> 199907
mysql> SELECT EXTRACT(DAY_MINUTE FROM '1999-07-02 01:02:03');
-> 20102
mysql> SELECT EXTRACT(MICROSECOND
-> FROM '2003-01-02 10:30:00.00123');
-> 123
● FROM_DAYS(N)
주어진 날짜 숫자 N에 대해서 DATE 값을 리턴한다.

mysql> SELECT FROM_DAYS(729669);
-> '1997-10-07'
● FROM_UNIXTIME(unix_timestamp), FROM_UNIXTIME(unix_timestamp,format)
unix_timestamp 인수에 대한 표현식을 이 함수가 사용된 문장에 따라서 'YYYY-MM-DD HH:MM:SS' 또는

:::MySQL Korea:::
YYYYMMDDHHMMSS 포맷으로 리턴한다. unix_timestamp는 UNIX_TIMESTAMP() 함수가 만들어 내는 것과 같은

내부 타임 스탬프 값이다.
만일 format 을 주게 되면, 그 결과는 format 스트링에 따라서 포맷이 되는데, 이것은 DATE_FORMAT() 함수에 대한
엔트리에 목록화 되는 방식과 같은 방식을 사용한다.
mysql> SELECT FROM_UNIXTIME(875996580);
-> '1997-10-04 22:23:00'
mysql> SELECT FROM_UNIXTIME(875996580) + 0;
-> 19971004222300
mysql> SELECT FROM_UNIXTIME(UNIX_TIMESTAMP(),
-> '%Y %D %M %h:%i:%s %x');
-> '2003 6th August 06:22:58 2003'
● GET_FORMAT(DATE|TIME|DATETIME, 'EUR'|'USA'|'JIS'|'ISO'|'INTERNAL')
포맷 스트링을 리턴한다. 이 함수는 DATE_FORMAT() 및 STR_TO_DATE() 함수를 결합하는데 있어서 매우 유용한

것이다.
첫 번째 인수와 두 번째 인수에 대해서 몇 가지 포맷 스트링 값이 사용 가능하다. 이 값들은 ISO 9075를 참조한다.
Function Call Result
GET_FORMAT(DATE,'USA') '%m.%d.%Y'
GET_FORMAT(DATE,'JIS') '%Y-%m-%d'
GET_FORMAT(DATE,'ISO') '%Y-%m-%d'
GET_FORMAT(DATE,'EUR') '%d.%m.%Y'
GET_FORMAT(DATE,'INTERNAL') '%Y%m%d'
GET_FORMAT(DATETIME,'USA') '%Y-%m-%d-%H.%i.%s'
GET_FORMAT(DATETIME,'JIS') '%Y-%m-%d %H:%i:%s'
GET_FORMAT(DATETIME,'ISO') '%Y-%m-%d %H:%i:%s'
GET_FORMAT(DATETIME,'EUR') '%Y-%m-%d-%H.%i.%s'

:::MySQL Korea:::
GET_FORMAT(DATETIME,'INTERNAL') '%Y%m%d%H%i%s'
GET_FORMAT(TIME,'USA') '%h:%i:%s %p'
GET_FORMAT(TIME,'JIS') '%H:%i:%s'
GET_FORMAT(TIME,'ISO') '%H:%i:%s'
GET_FORMAT(TIME,'EUR') '%H.%i.%S'
GET_FORMAT(TIME,'INTERNAL') '%H%i%s'
TIMESTAMP는 또한 GET_FORMAT() 함수의 첫 번째 인수로 사용이 가능한데, 이와 같은 경우, 함수는 DATETIME

함수와 같은 값을 리턴한다.
mysql> SELECT DATE_FORMAT('2003-10-03',GET_FORMAT(DATE,'EUR'));
-> '03.10.2003'
mysql> SELECT STR_TO_DATE('10.31.2003',GET_FORMAT(DATE,'USA'));
-> '2003-10-31'
● HOUR(time)
time에 대해서 시간 (hour)를 리턴한다. 일별 시간에 대해서는 0에서 23 사이의 값을 가진다. 하지만, TIME 값의 실제
범위는 이것보다 훨씬 크기 때문에, HOUR는 23 보다 큰 값을 리턴할 수 있다.
mysql> SELECT HOUR('10:05:03');
-> 10
mysql> SELECT HOUR('272:59:59');
-> 272
● LAST_DAY(date)
날짜 또는 데이트타임 값을 가져와서 그 달의 가장 마지막 날짜에 해당하는 값을 리턴한다. 만일 인수가 올바르지 않으면

NULL을 리턴한다.
mysql> SELECT LAST_DAY('2003-02-05');
-> '2003-02-28'

:::MySQL Korea:::
-> '2004-02-29'
mysql> SELECT LAST_DAY('2004-01-01 01:01:01');
-> '2004-01-31'
-> NULL
● LOCALTIME, LOCALTIME()
LOCALTIME 및 LOCALTIME()는 NOW()과 동일한 것이다.
● LOCALTIMESTAMP, LOCALTIMESTAMP()
LOCALTIMESTAMP 및 LOCALTIMESTAMP()는 NOW()과 동일하다.
● MAKEDATE(year,dayofyear)
주어진 연도 및 연도별 날짜 값을 가지고서, 해당하는 날짜를 리턴한다. dayofyear 인수는 0 보다 커야 하며, 그렇지 않을
경우에는 NULL을 리턴한다.
mysql> SELECT MAKEDATE(2001,31), MAKEDATE(2001,32);
-> '2001-01-31', '2001-02-01'
mysql> SELECT MAKEDATE(2001,365), MAKEDATE(2004,365);
-> '2001-12-31', '2004-12-30'
mysql> SELECT MAKEDATE(2001,0);
-> NULL
● MAKETIME(hour,minute,second)
hour, minute, 그리고 second 인수를 가지고 계산된 시간 값을 리턴한다.

mysql> SELECT MAKETIME(12,15,30);
-> '12:15:30'
● MICROSECOND(expr)

:::MySQL Korea:::
시간 또는 데이트타임 수식 expr 에서 마이크로 세컨드(microsecond) 값을 리턴하는데, 그 범위는0에서 999999 사이

가 된다.
mysql> SELECT MICROSECOND('12:00:00.123456');
-> 123456
mysql> SELECT MICROSECOND('1997-12-31 23:59:59.000010');
-> 10
● MINUTE(time)
time에서 분 (minute)에 해당하는 값을 리턴하는데, 그 범위는 0에서 59 사이가 된다.

mysql> SELECT MINUTE('98-02-03 10:05:03');
-> 5
● MONTH(date)
date에서 월에 해당하는 값을 리턴하는데, 그 범위는 0에서 12 사이가 된다.

mysql> SELECT MONTH('1998-02-03');
-> 2
● MONTHNAME(date)
date에 해당하는 월을 전체 이름으로 표시한다.

mysql> SELECT MONTHNAME('1998-02-05');
-> 'February'
● NOW()
이 함수가 사용되는 문장에 따라서 그 형태를 'YYYY-MM-DD HH:MM:SS' 또는 YYYYMMDDHHMMSS로 해서 현재

의 날짜 및 시간을 리턴한다.
mysql> SELECT NOW();

:::MySQL Korea:::
-> '1997-12-15 23:50:26'

mysql> SELECT NOW() + 0;
-> 19971215235026
NOW()는 이 명령문이 실행을 시작하는 시점을 나타내는 시간을 상수 값으로 리턴한다. (스토어드 루틴 또는 트리거 안에
서는, NOW()는 루틴 또는 트리거링 명령문이 실행되는 시점 값을 리턴한다.) 이 함수는 SYSDATE()와는 차이점을 가지
는데, 후자의 경우는 5.0.13 이후에는 함수가 실행된 정확한 시간을 리턴한다.
mysql> SELECT NOW(), SLEEP(2), NOW();
+---------------------+----------+---------------------+
| NOW() | SLEEP(2) | NOW() |
+---------------------+----------+---------------------+
| 2006-04-12 13:47:36 | 0 | 2006-04-12 13:47:36 |
+---------------------+----------+---------------------+
mysql> SELECT SYSDATE(), SLEEP(2), SYSDATE();

+---------------------+----------+---------------------+
| SYSDATE() | SLEEP(2) | SYSDATE() |
+---------------------+----------+---------------------+
| 2006-04-12 13:47:44 | 0 | 2006-04-12 13:47:46 |
+---------------------+----------+---------------------+
이 두 함수간의 차이점에 대해서는 SYSDATE() 함수 설명을 참고로 하기 바란다.
● PERIOD_ADD(P,N)
N 월 (month)을 기간 P 에 추가한다 (YYMM 또는 YYYYMM 포맷). 리턴되는 값은 YYYYMM 포맷을 가진다. 기간 인

수 P 는 날짜 값이 아니라는 점을 유의한다.
mysql> SELECT PERIOD_ADD(9801,2);
-> 199803
● PERIOD_DIFF(P1,P2)
P1 와P2 사이의 월별 간격을 리턴하는데, 여기에서 P1 과 P2 는 YYMM 또는 YYYYMM 형태가 되어야 한다. 인수 P1
과 P2 는 날짜 값이 아니라는 점을 유의한다.

:::MySQL Korea:::
mysql> SELECT PERIOD_DIFF(9802,199703);

-> 11
● QUARTER(date)
Date에 해당하는 분기를 리턴하는데, 범위는1 에서 4 사이가 된다

mysql> SELECT QUARTER('98-04-01');
-> 2
● SECOND(time)
time에서 초 부분을 리턴하는데, 범위는 0 에서 59 사이가 된다.

mysql> SELECT SECOND('10:05:03');
-> 3
● SEC_TO_TIME(seconds)
seconds 인수를 리턴하는데, 이 함수가 사용되는 문장에 따라서 'HH:MM:SS' 또는 HHMMSS 포맷의 값으로 시간, 분,
초로 변환을 시킨다.
mysql> SELECT SEC_TO_TIME(2378);
-> '00:39:38'
mysql> SELECT SEC_TO_TIME(2378) + 0;
-> 3938
● STR_TO_DATE(str,format)
이 함수는 DATE_FORMAT() 함수와는 정 반대 값을 리턴한다. 이 함수는 스트링 str 을 가져와서 스트링 format형태로
포맷을 한다. STR_TO_DATE()는, 포맷 스트링이 날짜 및 시간 부분을 모두 가지고 있는 경우에는 DATETIME 값을,
또는 스트링이 날짜 또는 시간 부분만을 가지고 있는 경우에는 DATE 또는 TIME 값을 리턴한다.
Str에 포함되어 있는 날짜, 시간, 또는 데이트타임 값은 ormat에 의해 지정되는 포맷으로 주어져야 한다. format에서 사용
될 수 있는 지정자의 경우는 DATE_FORMAT() 함수 설명을 참조하기 바란다. 만일 str이 올바르지 않은 날짜, 시간, 또

:::MySQL Korea:::
는 데이트타임 값을 가지고 있다면, STR_TO_DATE()는 NULL을 리턴한다. MySQL 5.0.3 이후에서는 경고문도 함께
발생한다.
날짜 값의 범위 검사는 Section 11.3.1, “DATETIME, DATE, 그리고 TIMESTAMP 타입”에서 설명을 하고 있다. 예
를 들면, 이것은, “제로 (zero)” 날짜 또는 날짜 부분에 0을 가지고 있는 날짜는 SQL 모드가 이러한 값을 허용하지 않도
록 설정되지 않는 한 사용 가능하다는 것을 의미한다.
mysql> SELECT STR_TO_DATE('00/00/0000', '%m/%d/%Y');
-> '0000-00-00'
mysql> SELECT STR_TO_DATE('04/31/2004', '%m/%d/%Y');
-> '2004-04-31'
● SUBDATE(date,INTERVAL expr unit), SUBDATE(expr,days)
두 번째 인수에 대해서 INTERVAL 폼을 사용해서 호출을 한다면, SUBDATE()는 DATE_SUB()과 동일한 값을 리턴하
게 된다.
mysql> SELECT DATE_SUB('1998-01-02', INTERVAL 31 DAY);
-> '1997-12-02'
mysql> SELECT SUBDATE('1998-01-02', INTERVAL 31 DAY);
-> '1997-12-02'
두 번째 형태는 days에 대해서 정수 값을 사용할 수 있도록 하고 있다. 이와 같은 경우, 날짜 또는 데이트타입 수식 expr
에서 빼기가 되어야 하는 날짜 수로 해석이 된다.
mysql> SELECT SUBDATE('1998-01-02 12:00:00', 31);
-> '1997-12-02 12:00:00'
Note: "%X%V" 형태를 사용해서 년-주간 스트링을 날짜로 변환 시킬수는 없는데, 그 이유는 연도와 주간의 결합은 해당
주간이 두 개의 달에 걸쳐 있을 경우에는 연도 및 달을 구분할 수 없기 때문이다. 연도-주간 값을 날짜로 변환하기 위해서
는, 주간 요일 (weekday)을 함께 지정해 주어야 한다:
mysql> SELECT STR_TO_DATE('200442 Monday', '%X%V %W');
-> '2004-10-18'
● SUBTIME(expr1,expr2)
SUBTIME() 함수는 expr1 – expr2 수식의 결과 값을 리턴하느데, 그 포맷은 expr1을 따른다. expr1 은 시간 또는 데

:::MySQL Korea:::
이트 타임 수식을 사용할 수 있으며, expr2은 시간 수식이 된다.

mysql> SELECT SUBTIME('1997-12-31 23:59:59.999999','1 1:1:1.000002');
-> '1997-12-30 22:58:58.999997'
mysql> SELECT SUBTIME('01:00:00.999999', '02:00:00.999998');
-> '-00:59:59.999999'
● SYSDATE()
함수가 사용된 문장에 따라서 'YYYY-MM-DD HH:MM:SS' 또는 YYYYMMDDHHMMSS 포맷으로 현재 날짜 및 시간

을 리턴한다.
MySQL 5.0.13 이후부터는, SYSDATE()은 이것이 실행된 시간을 리턴한다. 이 함수는 NOW()과 차이를 가지는데, 후
자의 경우는 명령문이 실행을 시작한 상수 시간을 리턴한다.
mysql> SELECT NOW(), SLEEP(2), NOW();
+---------------------+----------+---------------------+
| NOW() | SLEEP(2) | NOW() |
+---------------------+----------+---------------------+
| 2006-04-12 13:47:36 | 0 | 2006-04-12 13:47:36 |
+---------------------+----------+---------------------+
mysql> SELECT SYSDATE(), SLEEP(2), SYSDATE();

+---------------------+----------+---------------------+
| SYSDATE() | SLEEP(2) | SYSDATE() |
+---------------------+----------+---------------------+
| 2006-04-12 13:47:44 | 0 | 2006-04-12 13:47:46 |
+---------------------+----------+---------------------+
또한, SET TIMESTAMP 명령문은 NOW()가 리턴하는 값에는 영향을 주지만, SYSDATE()가 리턴하는 값에는 영향을
주지 않는다. 이것이 의미하는 것은 바이너리 로그에서 설정된 타임 스탬프가 SYSDATE() 함수 호출에는 영향을 주지 않
는다는 것을 나타내는 것이다.
SYSDATE()는 동일한 명령문 안에서도 서로 다른 값을 리턴하고, SET TIMESTAMP에 의해서도 영향을 받지 않기 때
문에, 이 함수는 논-디터미니스틱 (non-deterministic)이며 따라서 리플리케이션에서는 안전하지가 못하게 된다. 만일
이것이 문제가 된다면, 서버를 --sysdate-is-now 옵션과 함께 구동 시킴으로서 SYSDATE()가 NOW()의 별칭으로

:::MySQL Korea:::
동작하도록 할 수는 있다.
● TIME(expr)
시간 또는 데이트 타임 수식 expr 에서 시간 부분을 추출하고 그 값을 스트링으로 리턴한다.

mysql> SELECT TIME('2003-12-31 01:02:03');
-> '01:02:03'
mysql> SELECT TIME('2003-12-31 01:02:03.000123');
-> '01:02:03.000123'
● TIMEDIFF(expr1,expr2)
TIMEDIFF()은 expr1 – expr2 수식의 결과를 시간 값으로 리턴한다. expr1 및 expr2 는 시간 또는 날짜-시간 수식
이 될 수 있지만, 양쪽 모두 동일한 타입이어야 한다.
mysql> SELECT TIMEDIFF('2000:01:01 00:00:00',
-> '2000:01:01 00:00:00.000001');
-> '-00:00:00.000001'
mysql> SELECT TIMEDIFF('1997-12-31 23:59:59.000001',
-> '1997-12-30 01:01:01.000002');
-> '46:58:57.999999'
● TIMESTAMP(expr), TIMESTAMP(expr1,expr2)
단일 인수를 사용하게 되면, 이 함수는 날짜 또는 데이트 타임 수식 expr 을 데이트 타임 값으로 리턴한다. 두 개의 인수

를 사용하게 되면, 이 함수는 시간 수식 expr2 를 날짜 또는 데이트 타임 수식 expr1 에 추가를 하게 되고 그 결과를 데이
트타임 값 형태로 리턴한다.
mysql> SELECT TIMESTAMP('2003-12-31');
-> '2003-12-31 00:00:00'
mysql> SELECT TIMESTAMP('2003-12-31 12:00:00','12:00:00');
-> '2004-01-01 00:00:00'

:::MySQL Korea:::
● TIMESTAMPADD(unit,interval,datetime_expr)
정수 수식 interval 를 날짜 또는 데이트타임 수식 datetime_expr에 추가를 한다. interval 에 대한 유닛은 unit 인수에 의

해 주어지는데, 이 인수는 다음의 값 중에 하나가 되어야 한다: FRAC_SECOND, SECOND, MINUTE, HOUR, DAY,
WEEK, MONTH, QUARTER, or YEAR.
unit 값은 위에 나와 있는 키워드중의 하나를 사용하거나 또는 지정될 수 있다. SQL_TSI_의 접두어를 사용해서 지정할 수
가 있다. 예를 들면, DAY 및 SQL_TSI_DAY 는 모두 유효하다.
mysql> SELECT TIMESTAMPADD(MINUTE,1,'2003-01-02');
-> '2003-01-02 00:01:00'
mysql> SELECT TIMESTAMPADD(WEEK,1,'2003-01-02');
-> '2003-01-09'
TIMESTAMPADD()는 5.0.0 이후에 사용 가능해졌다.
● TIMESTAMPDIFF(unit,datetime_expr1,datetime_expr2)
날짜 또는 데이트 타임 수식 datetime_expr1 및 datetime_expr2간의 정수 차이를 리턴한다. 그 결과에 대한 유닛은

unit 인수에 의해 주어진다. unit 에 대한 유효 값은 TIMESTAMPADD() 함수에서 설명된 리스트 값과 같다.
mysql> SELECT TIMESTAMPDIFF(MONTH,'2003-02-01','2003-05-01');
-> 3
mysql> SELECT TIMESTAMPDIFF(YEAR,'2002-05-01','2001-01-01');
-> -1
TIMESTAMPDIFF()는 5.0.0 이후에 사용 가능해졌다.
● TIME_FORMAT(time,format)
이 함수는 DATE_FORMAT() 함수와 비슷하게 사용되지만, format 스트링은 시간, 분, 그리고 초에만 해당하는 지정자
를 가질 수도 있다. 다른 지정자들을 사용하면 NULL 값 또는 0이 나오게 된다.
만일 time 값이 23 보다 큰 시간 부분을 가진다면, %H 및 %k 시간 포맷 지정자는 0에서 23 보다 큰 값을 만들게 된다. 다
른 시간 포맷 지정자는 시간 값 모듈로 12를 만든다.
mysql> SELECT TIME_FORMAT('100:00:00', '%H %k %h %I %l');
-> '100 100 04 04 4'

:::MySQL Korea:::
● TIME_TO_SEC(time)
time 인수를 초로 변환해서 리턴한다.

mysql> SELECT TIME_TO_SEC('22:23:00');
-> 80580
mysql> SELECT TIME_TO_SEC('00:39:38');
-> 2378
● TO_DAYS(date)
주어진 날짜 date에 대해서, 연도 0에서부터 계산된 날짜 숫자를 리턴한다.

mysql> SELECT TO_DAYS(950501);
-> 728779
mysql> SELECT TO_DAYS('1997-10-07');
-> 729669
● UNIX_TIMESTAMP(), UNIX_TIMESTAMP(date)
만일 아무런 인수를 지정하지 않고 호출을 한다면, 부호를 사용하지 않은 유닉스 타임 스탬프를 리턴한다 ('1970-01-
01 00:00:00' UTC 이후의 초). 만일 UNIX_TIMESTAMP()가 date 인수를 사용해서 호출되었다면, 이 함수는 '1970-
01-01 00:00:00' UTC 이후의 초 형태로 인수 값을 리턴한다. Date는 DATE 스트링, DATETIME 스트링,
TIMESTAMP, 또는 YYMMDD 또는 YYYYMMDD에 있는 숫자가 될 수도 있다. 서버는 date를 현재의 타임 존에 있는
값으로 해석을 해서 UTC의 내부 값으로 변환을 시킨다. 클라이언트는 자신의 타임 존을 Section 5.11.8, “MySQL 서
버 타임 존 지원”에서 설명한 방식으로 설정을 한다.
mysql> SELECT UNIX_TIMESTAMP();
-> 882226357
mysql> SELECT UNIX_TIMESTAMP('1997-10-04 22:23:00');
-> 875996580
UNIX_TIMESTAMP를 TIMESTAMP 컬럼에서 사용하는 경우, 이 함수는 내부 타임 스탬프 값을 직접 리턴하고, 의미적
인 (implicit) “스트링에서 유닉스 타임 스탬프로 변환”을 실행하지 않는다. 만일 날짜 범위를 벗어난 값을
UNIX_TIMESTAMP()에 주게 되면, 함수는 0을 리턴한다.

:::MySQL Korea:::
● UTC_DATE, UTC_DATE()
이 함수가 사용된 문장에 따라서, 현재의 UTC 날짜를 'YYYY-MM-DD' 또는 YYYYMMDD 포맷으로 리턴한다.
mysql> SELECT UTC_DATE(), UTC_DATE() + 0;
-> '2003-08-14', 20030814
● UTC_TIME, UTC_TIME()
이 함수가 사용된 문장에 따라서, 현재의 UTC 시간을 'HH:MM:SS' 또는 HHMMSS 포맷으로 리턴한다.
mysql> SELECT UTC_TIME(), UTC_TIME() + 0;
-> '18:07:53', 180753
● UTC_TIMESTAMP, UTC_TIMESTAMP()
이 함수가 사용된 문장에 따라서, 현재의 UTC 날짜를 'YYYY-MM-DD HH:MM:SS' 또는 YYYYMMDDHHMMSS 포맷
으로 리턴한다.
mysql> SELECT UTC_TIMESTAMP(), UTC_TIMESTAMP() + 0;
-> '2003-08-14 18:08:04', 20030814180804
● WEEK(date[,mode])
이 함수는 date에 해당하는 주간 숫자를 리턴한다. WEEK() 함수에 두 개의 인수를 사용하면 해당 주가 일요일 또는 월요
일에 시작을 하는지를 지정할 수 있으며 또한 리턴되는 값이 0에서 53 사이 또는 1에서 53 사이에 있는지를 지정할 수가
있게 된다. 만일 mode 인수를 생략한다면, default_week_format 시스템 변수가 사용된다. Section 5.2.2, “서버 시스
템 변수”를 참조할 것.
아래의 테이블은 mode 인수가 어떻게 동작을 하는지를 보여주는 것이다.
First day
Mode of week Range Week 1 is the first week …
0 Sunday 0-53 with a Sunday in this year

:::MySQL Korea:::
1 Monday 0-53 with more than 3 days this year
2 Sunday 1-53 with a Sunday in this year
3 Monday 1-53 with more than 3 days this year
4 Sunday 0-53 with more than 3 days this year
5 Monday 0-53 with a Monday in this year
6 Sunday 1-53 with more than 3 days this year
7 Monday 1-53 with a Monday in this year
mysql> SELECT WEEK('1998-02-20');

-> 7
mysql> SELECT WEEK('1998-02-20',0);
-> 7
-> 8
-> 53
만일 어떤 날짜가 바로 전년도의 마지막 주에 있다면, 여러분이 옵션 인수MySQL은 0을 리턴한다:
mysql> SELECT YEAR('2000-01-01'), WEEK('2000-01-01',0);
-> 2000, 0
● WEEKDAY(date)
Date에 해당하는 주간 요일 인덱스를 리턴한다 (0 = Monday, 1 = Tuesday, … 6 = Sunday).

mysql> SELECT WEEKDAY('1998-02-03 22:23:00');
-> 1
mysql> SELECT WEEKDAY('1997-11-05');
-> 2
● WEEKOFYEAR(date)

:::MySQL Korea:::
1에서 53 사이의 달력 주간 숫자를 리턴한다.

mysql> SELECT WEEKOFYEAR('1998-02-20');
-> 8
● YEAR(date)
1000에서 9999 사이의 date에 해당하는 연도를 리턴하거나, 또는 “제로” 날짜일 경우에는 0을 리턴한다.
mysql> SELECT YEAR('98-02-03');
-> 1998
● YEARWEEK(date), YEARWEEK(date,start)
해당되는 연도 및 주를 리턴한다. start 인수는 WEEK() 함수에서 사용되는 것과 동일하게 동작을 한다. 결과에 나오는 연
도는 날짜 인수에 표시되어 있는 연도와 다르게 나올 수도 있다.
mysql> SELECT YEARWEEK('1987-01-01');
-> 198653

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.6. MySQL이 사용하는 달력
12. 함수와 연산자 MySQL은 “proleptic Gregorian calendar”라고 알려진 그레고리력을 사용하고 있다.
12.6. MySQL이 사용하는 달력
12.6 MySQL이 사용하는 달력
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 12.7. 전문 (Full-Text) 검색 함수
12. 함수와 연산자 12.7.1. 불리안 전문 검색

12.7. 전문 (Full-Text) 검색 함수 12.7.2. 쿼리 확장을 사용한 전문 검색
12.7 전문 (Full-Text) 검색 함수 12.7.3. 전문 스톱워드 (Stopwords)

12.7.4. 전문 제약 사항
12.7.5. 올바른 MySQL 전문 검색 튜닝
MATCH (col1,col2,...) AGAINST (expr [search_modifier])
search_modifier: { IN BOOLEAN MODE | WITH QUERY EXPANSION }

MySQL은 전문 인덱싱과 검색을 지원한다:
● MySQL에서 전문 인덱스는 타입 FULLTEXT의 인덱스이다.

● 전문 인덱스는 MyISAM 테이블을 사용해서만 사용될 수 있으며, 또한 CHAR, VARCHAR, 또는 TEXT 컬럼용으로만 생
성할 수가 있다.
● FULLTEXT 인덱스 정의는 테이블을 생성할 때 CREATE TABLE 명령문에 주어질 수 있거나, 또는 ALTER TABLE 또
는 CREATE INDEX를 사용한 후에 추가될 수가 있다.
● 대형 데이터 셋의 경우에는, FULLTEXT 인덱스를 가지고 있지 않는 테이블에 데이터를 읽어 오는 것이 더 빠르다.
전문 검색은 MATCH() ... AGAINST 신텍스를 사용해서 실행된다. MATCH()은 콤마로 구분된 리스트를 가져오는데, 이 리스트
는 검색할 컬럼들의 이름이 된다. AGAINST는 검색에 사용할 스트링을 가져오며, 실행할 검색의 타입이 어떤 것인지를 가리키는
모디파이어 (modifier)를 옵션으로 가져온다. 검색 스트링은 반드시 리터럴 스트링이어야 하며, 변수 또는 컬럼 이름은 될 수 없
다. 전문 검색에는 세 가지 타입이 있다:
● 불리안 검색은 특별한 쿼리 언어 규칙을 사용해서 검색 스트링을 해석한다. 이 스트링은 검색에 사용할 단어를 가진다. 또

:::MySQL Korea:::
한, 이 스트링에는 특정 단어가 매칭 열에 반드시 있어야 하거나 없어야 하는 것, 또는 가중치를 일반적인 것 보다 더 주거

나 또는 덜 주는 것과 같은 요구 조건을 지정하는 연산자를 포함할 수 있다. “some” 또는 “then”과 같은 일반적인 단
어는 스톱워드 (stopword)이며, 이런 단어가 검색 스트링에 존재할 경우에는 매치가 되지 않는다. IN BOOLEAN MODE
모디파이어는 불리안 검색을 지정한다. 보다 자세한 정보는, Section 12.7.1, “불리안 전문 검색”을 참조할 것.
● 자연어 검색은 검색 스트링을 자연어의 구문 (자연스러운 문장의 구문)처럼 해석한다. 여기에는 특별한 연산자가 존재하
지 않는다. 스톱워드 리스트는 적용된다. 또한, 열 중에 50% 이상에서 존재하는 단어들은 일반적인 것으로 간주되어서 매
치를 하지 않게 된다. 어떠한 모디파이어도 제공되지 않을 경우의 전문 검색은 자연어 검색이다.
● 쿼리 확장 검색은 자연어 검색의 변형된 형태이다. 자연어 검색을 실행하기 위해 검색 스트링을 사용한다. 검색의 결과로
가장 연관성이 높은 열에서 나오는 단어들이 검색 스트링에 추가되며 검색이 재차 실행된다. 쿼리는 두 번째 검색에서 그
열들을 리턴한다. WITH QUERY EXPANSION 모디파이어는 쿼리 확장 검색을 지정한다. 보다 자세한 정보는,
Section 12.7.2, “쿼리 확장을 사용한 전문”을 참조하기 바란다.
전문 검색의 제약 사항에 대해서는 Section 12.7.4, “전문검색 제약 사항”을 참조하기 바란다.
mysql> CREATE TABLE articles (

-> id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
-> title VARCHAR(200),
-> body TEXT,
-> FULLTEXT (title,body)
-> );
mysql> INSERT INTO articles (title,body) VALUES

-> ('MySQL Tutorial','DBMS stands for DataBase ...'),
-> ('How To Use MySQL Well','After you went through a ...'),
-> ('Optimizing MySQL','In this tutorial we will show ...'),
-> ('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
-> ('MySQL vs. YourSQL','In the following database comparison ...'),
-> ('MySQL Security','When configured properly, MySQL ...');

:::MySQL Korea:::
mysql> SELECT * FROM articles

-> WHERE MATCH (title,body) AGAINST ('database');
+----+-------------------+------------------------------------------+
| id | title | body |
+----+-------------------+------------------------------------------+
| 5 | MySQL vs. YourSQL | In the following database comparison ... |
| 1 | MySQL Tutorial | DBMS stands for DataBase ... |
+----+-------------------+------------------------------------------+
MATCH() 함수는 텍스트 콜렉션 (text collection)에 대응해서 특정 스트링에 대한 자연어 검색을 실행한다. 콜렉션이란
FULLTEXT 인덱스에 포함되어 있는 하나 이상의 컬럼 셋이다. 검색 스트링은 AGAINST()에 대한 인수 형태로 주어진다. 테이블
에 있는 각각의 열에 대해서는, MATCH()은 연관도 (relevance value) 리턴한다; 즉, 검색 스트링과 MATCH() 리스트에 명명되
어 있는 컬럼내의 열에 있는 텍스트간의 유사성을 측정한다.
디폴트로는, 검색은 문자의 크기를 구분하지 않고 실행된다. 하지만, 인덱스된 컬럼에 대한 바이너리 콜레션을 사용하면 문자 크기
를 구분하는 전문 검색을 실행할 수가 있다. 예를 들면, latin1 문자 셋을 사용하는 컬럼은 전문 검색을 할 때 문자 크기를 구분하기
위해서 latin1_bin의 콜레션을 할당 받을 수가 있다.
위에 나와 있는 예문과 같이, MATCH() 함수가 WHERE 구문에서 사용되게 되면, 리턴되는 열은 연관도가 높은 순서대로 자동 정
렬이 되어 나오게 된다. 연관도는 음수가 아닌 부동 소수점 숫자이다. 제로 연관도는 유사성이 없다는 것을 의미한다. 연관도는 열
에 있는 단어의 수, 열에 있는 유니크한 단어의 수, 콜렉션에 있는 전체 단어의 수, 그리고 특정 단어를 가지고 있는 열의 숫자등을
기반으로 계산된다.
자연어 전문 검색의 경우, MATCH() 함수에 명명된 컬럼은 여러분이 사용하는 테이블에 있는 FULLTEXT 인덱스에 포함되어 있
는 컬럼과 같아야 하는 제약 조건이 있다. 위의 예문에 나와 있는 쿼리의 경우, MATCH() 함수에 명명된 컬럼 (title 및 body)이
article 테이블의 FULLTEXT 인덱스 정의문에서 명명된 컬럼 이름과 같다는 점을 기억하자. 만일 여러분이 title 또는 body를 개
별적으로 검색하고자 한다면, 여러분은 각각의 컬럼에 대해서 별도의 FULLTEXT 인덱스를 생성해야 할 것이다.
쿼리 확장을 사용한 검색 또는 불리안 검색을 실행하는 것 역시 가능하다. 이러한 검색 타입은 Section 12.7.1, “불리안 전문 검

:::MySQL Korea:::
색”, 그리고 Section 12.7.2, “쿼리 확장을 사용한 전문 검색”을 참고하기 바란다.
위의 예문은 연관도가 낮은 순서대로 열이 리턴되는 곳에서 MATCH() 함수를 어떻게 사용하는지를 보여주는 기본적인 것이다. 다
음에 나오는 예문은 명확하게 연관도를 추출하는 방법에 대해서 보여주고 있다. 리턴되는 열은 순서대로 정렬되지 않는데, 그 이유
는 SELECT 명령문이 WHERE 또는 ORDER BY 구문중의 어느 것도 포함하고 있지 않기 때문이다:
mysql> SELECT id, MATCH (title,body) AGAINST ('Tutorial')

-> FROM articles;
+----+-----------------------------------------+
| id | MATCH (title,body) AGAINST ('Tutorial') |
+----+-----------------------------------------+
| 1| 0.65545833110809 |
| 2| 0|
| 3| 0.66266459226608 |
| 4| 0|
| 5| 0|
| 6| 0|
+----+-----------------------------------------+
아래에 나오는 예문은 좀더 복잡한 것이다. 예문에 있는 쿼리는 연관도 값을 리턴하고 연관도가 낮은 순서대로 열을 정렬한다. 이러
한 결과를 얻기 위해서는, 여러분은 MATCH()를 두 번 지정해 주어야 한다: 한번은 SELECT 리스트에서 하고 나머지 한번은
WHERE 구문에서 한다. 이렇게 하면 추가적인 오버 헤드가 발생하지 않게 되는데, 그 이유는 MySQL 옵티마이저가 두 개의
MATCH() 호출이 각각 동일한 것이고 전문 검색 코드는 한번만 호출한다는 것을 알기 때문이다.
mysql> SELECT id, body, MATCH (title,body) AGAINST

-> ('Security implications of running MySQL as root') AS score
-> FROM articles WHERE MATCH (title,body) AGAINST
-> ('Security implications of running MySQL as root');
+----+-------------------------------------+-----------------+
| id | body | score |

:::MySQL Korea:::
+----+-------------------------------------+-----------------+
| 4 | 1. Never run mysqld as root. 2. ... | 1.5219271183014 |
| 6 | When configured properly, MySQL ... | 1.3114095926285 |
+----+-------------------------------------+-----------------+
MySQL의 FULLTEXT 실행은 모든 실제 문자 (문자, 숫자, 그리고 언더 스코어 문자) 시퀀스를 하나의 단어로 인식한다. 이러한
시퀀스에는 어퍼스크로피 (apostrophe) (‘'’)도 포함되지만, 하나의 열에 하나 이상은 포함되지 않는다. 이것은 aaa'bbb는 하나
의 단어로 인식되지만, aaa''bbb는 두 개의 단어로 인식된다는 것을 의미한다. 단어의 처음 또는 마지막에 나오는 어퍼스트로피는
FULLTEXT 파서 (parser)가 잘라낸다; 'aaa'bbb'는 aaa'bbb 형태가 된다.
FULLTEXT 파서는 특정 구분 문자 (delimiter)를 찾아서 단어가 시작되는 곳과 끝나는 곳을 결정한다; 예를 들면,

‘ ’ (space), ‘,’ (comma), and ‘.’ (period). 만일 단어들이 구분 문자에 의해 분리되어 있지 않으면, FULLTEXT 파서
는 단어의 시작과 끝을 알아낼 수가 없게 된다. 특정 언어 (예를 들면, 중국어)에 있는 단어 또는 별도의 인덱스된 용어를
FULLTEXT 인덱스에 추가하기 위해서는, ‘"’와 같은 임의의 구분 문자를 사용해서 각각의 단어를 미리 분리하는 작업을 해 두
어야 한다.
전문 검색에서는 몇 가지 단어들이 무시가 된다:
● 너무 짧은 단어는 모두 무시가 된다. 전문 검색이 될 수 있는 디폴트 최소 길이는 4개 문자이다.

● 스톱워드 리스트에 있는 단어들은 무시가 된다. 스톱워드는 A stopword is a word such as “the” 또는 “some”과 같
은 단어이며, 이러한 단어들은 너무 일반적인 것이기 때문에 의미론적으로 제로 값을 가지게 된다. 빌트-인 스톱워드 리스
트가 있기는 하지만, 사용자 지정 리스토로 대체를 할 수가 있다.
디폴트 스톱워드 리스트는 Section 12.7.3, “전문 스톱워드”에 있다. 디폴트 최소 단어 길이 및 스톱워드 리스트는
Section 12.7.5, “ 올바른 MySQL 전문 검색 튜닝”에서 설명하는 방법으로 수정할 수가 있다.
콜렉션 및 쿼리 안에 있는 모든 유효한 단어들은 콜렉션 또는 쿼리에서의 중요도에 따라서 가중치를 가지게 된다. 결론적으로, 하나
의 단어가 여러 열에 등장하게 되면 낮은 가중치를 가지게 되는데, 그 이유는 그러한 단어는 특정 콜렉션에서 낮은 의미를 가지기
때문이다. 반대로, 만일 어떤 단어가 희귀하다면, 그 단어는 높은 가중치를 가지게 된다. 어떤 단어에 대한 가중치는 열의 연관도를
계산하기 위해 결합된 것이다.

:::MySQL Korea:::
이러한 기법은 대형 콜렉션에서도 올바르게 동작을 한다 (주의 깊게 튜닝이 되어야 함). 매우 작은 테이블의 경우, 단어 분포도는
자신의 의미 값을 적절하게 반영하지 못하며, 이러한 모델은 엉뚱한 결과를 만들기도 한다. 예를 들면, 비록 “MySQL”이라는 단
어가 위에 나와 있는 articles 테이블의 모든 열에 나오기는 하지만, 이 단어에 대한 검색은 아무런 결과도 리턴하지 않게 된다:
mysql> SELECT * FROM articles

-> WHERE MATCH (title,body) AGAINST ('MySQL');
검색 결과가 위와 같이 나오는 이유는, 단어 “MySQL”이 최소 50%의 열에 나오기 때문이다. 따라서, 이와 같은 경우에는 이 단

어를 스톱워드로 다루는 것이 효과적이다. 대형 데이터 셋의 경우, 이렇게 하는 것이 가장 권장할 수 있는 방식이다.
테이블에 있는 열의 50%와 매치가 되는 단어는 관련된 서류에 위치해 있을 가능성이 덜하다. 사실, 이것들은 연관성이 없는 서류에
서 더 많이 발견이 된다. 인터넷 검색 엔진을 사용해서 인터넷에서 무언가를 찾고자 할 때 이러한 일이 너무 자주 발생한다는 것을
우리는 잘 알고 있다. 이러한 이유로 인해, 이러한 단어를 포함하고 있는 열은 그 단어가 나오는 특정 데이터 셋에 대해서 낮은 가중
치를 할당 받게 되는 것이다. 주어진 단어는 어떤 데이터 셋에서는 50% 이상 나올 수도 있지만 다른 곳에서는 그렇지 않을 수도 있
다.
여러분이 전문 검색이 어떻게 동작을 하는지 보고자 할 때 50%의 쓰레드 홀드 (threshold)는 중요한 의미를 갖는다: 만일 여러분
이 테이블을 하나 생성한 다음에 하나 또는 두개의 텍스트 열만 그 테이블에 삽입한다면, 텍스트에 나오는 모든 단어들은 최소
50% 이상의 열에 존재하게 된다. 그 결과, 어떠한 검색 결과도 얻을 수가 없게 된다. 최소 3개의 열을 삽입해야 한다는 점을 알아두
기 바라며, 가능하면 많은 열을 삽입하도록 한다. Section 12.7.1, “불리안 전문 검색”을 참조할 것.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 13. SQL 문법(SQL Statement Syntax)
13. SQL 문법(SQL Statement Syntax) 13.1. 데이터정의 문
13 SQL 문법(SQL Statement Syntax) 13.1.1. ALTER DATABASE
13.1 데이터정의 문 13.1.2. ALTER TABLE
13.1.1 ALTER DATABASE 13.1.3. CREATE DATABASE

13.1.4. CREATE INDEX
13.1.2 ALTER TABLE
13.1.5. CREATE TABLE
13.1.3 CREATE DATABASE
13.1.6. DROP DATABASE
13.1.4 CREATE INDEX
13.1.7. DROP INDEX
13.1.5 CREATE TABLE
13.1.8. DROP TABLE
13.1.5.1 Silent Column Specification Changes
13.1.9. RENAME TABLE
13.1.6 DROP DATABASE
13.2. 데이터 조작 SQL문
13.1.7 DROP INDEX
13.2.1. DELETE
13.1.8 DROP TABLE 13.2.2. DO
13.1.9 RENAME TABLE 13.2.3. HANDLER
13.2 데이터 조작 SQL문 13.2.4. INSERT
13.2.1 DELETE 문 13.2.5. LOAD DATA INFILE
13.2.2 DO 13.2.6. REPLACE
13.2.3 HANDLER 13.2.7. SELECT
13.2.4 INSERT 13.2.8. 서브 쿼리 신텍스
13.2.4.1 INSERT .. 13.2.9. TRUNCATE

13.2.10. UPDATE
13.2.4.2 INSERT DELAYED
13.3. MySQL 유틸리티 문
13.2.4.3 INSERT ..
13.3.1. DESCRIBE
13.2.5 LOAD DATA INFILE
13.3.2. USE

:::MySQL Korea:::
13.2.6 REPLACE 13.4. MySQL 트랜잭션 및 잠금 문
13.2.7 SELECT 13.4.1. START TRANSACTION, COMMIT, ROLLBACK
13.2.7.1 JOIN Syntax 13.4.2 롤백(RollBack) 될수 없는 문

13.4.3. 암시적 Commit 유발 문
13.2.7.2 UNION
13.4.4. SAVEPOINT과 ROLLBACK TO SAVEPOINT
13.2.8 서브쿼리
13.4.5. LOCK TABLES 와 UNLOCK TABLES
13.2.8.1 단계적 변수로써의 서브쿼리
13.4.6. SET TRANSACTION
13.2.8.2 서브쿼리를 이용한 비교
13.4.7. XA 트랜잭션
13.2.8.3 ANY, IN과 SOME를 가진 서브쿼리
13.5. 데이터베이스 관리 문
13.2.8.4 ALL을 가진 서브쿼리
13.5.1. 계정 관리 문
13.2.8.5 로우 서브쿼리
13.5.2. 테이블 유지보수 문
13.2.8.6 EXISTS and NOT EXISTS 13.5.3. SET
13.2.8.7 서로 관련된 서브쿼리들 13.5.4. SHOW
13.2.8.8 FROM 절 안에서의 서브쿼리들 13.5.5. 기타 관리 문
13.2.8.9 서브쿼리 에러 13.6. 리플리케이션 문
13.2.8.10 서브쿼리 최적화 13.6.1. 마스터 서버 컨트롤을 위한SQL 문
13.2.8.11 MySQL 초기버전 용 Joins로써의 리라이팅 서브쿼리들 13.6.2. 슬레이브 서버 컨트롤을 위한 SQL 문
13.2.9 TRUNCATE 13.7. Prepared 문을 위한 SQL 신텍스
13.2.10 UPDATE
이 장은 MySQL이 제공하는 모든 SQL 문의 문법에 대해 설명한다. 추가 적인 SQL문에 대한 설명
13.3 MySQL 유틸리티 명령문
은 다음 장을 참조 하라.
13.3.1 DESCRIBE Syntax
13.3.2 USE Syntax
● EXPLAIN 7장 최적화 부분을 참조하라.
13.4 MySQL 트랜잭션 과 잠금문 ● 저장루틴을 위한 SQL문은 17장 스토어드 프로시져 및 기능 부분.
13.4.1 START TRANSACTION, COMMIT, 와 ROLLBACK ● 쓰기 트리거문은 18장 트리거를 참조하라.
13.4.2 Roll back될 수 없는 SQL문 ● 뷰에 관련된 문은 19장 뷰를 참조하라.
13.4.3 암묵적 Commit을 유발하는 SQL문
13.4.4 SAVEPOINT 와 ROLLBACK TO SAVEPOINT *본 13장은 조우현 회원님께서 번역하셨습니다.
13.4.5 LOCK TABLES 와 UNLOCK TABLES
13.4.6 SET TRANSACTION

:::MySQL Korea:::
13.4.7 XA 트랜잭션
13.4.7.1 XA Transaction SQL 신텍스
13.4.7.2 XA Transaction States
13.5 데이터베이스 관리문
13.5.1 계정 관리문
13.5.1.1 CREATE USER
13.5.1.2 DROP USER Syntax
13.5.1.3 GRANT
13.5.1.4 RENAME USER
13.5.1.5 REVOKE
13.5.1.6 SET PASSWORD
13.5.2 테이블 유지보수 문
13.5.2.1 ANALYZE TABLE
13.5.2.2 BACKUP TABLE
13.5.2.3 CHECK TABLE
13.5.2.4 CHECKSUM TABLE
13.5.2.5 OPTIMIZE TABLE
13.5.2.6 REPAIR TABLE
13.5.2.7 RESTORE TABLE
13.5.3 SET
13.5.4 SHOW
13.5.4.1 SHOW CHARACTER SET
13.5.4.2 SHOW COLLATION
13.5.4.3 SHOW COLUMNS
13.5.4.4 SHOW CREATE DATABASE
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW CREATE FUNCTION
13.5.4.6 SHOW CREATE TABLE
13.5.4.7 SHOW CREATE VIEW

:::MySQL Korea:::
13.5.4.8 SHOW DATABASES

13.5.4.9 SHOW ENGINE
13.5.4.10 SHOW ENGINES
13.5.4.11 SHOW ERRORS
13.5.4.12 SHOW GRANTS
13.5.4.13 SHOW INDEX
13.5.4.14 SHOW INNODB STATUS
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES
13.5.4.17 SHOW PRIVILEGES
13.5.4.18 SHOW PROCEDURE STATUS 과 SHOW FUNCTION STATUS
13.5.4.19 SHOW PROCESSLIST
13.5.4.20 SHOW STATUS
13.5.4.21 SHOW TABLE STATUS
13.5.4.22 SHOW TABLES
13.5.4.23 SHOW TRIGGERS
13.5.4.24 SHOW VARIABLES
13.5.4.25 SHOW WARNINGS
13.5.5 기타 관리 문
13.5.5.1 CACHE INDEX
13.5.5.2 FLUSH
13.5.5.3 KILL
13.5.5.4 LOAD INDEX INTO CACHE
13.5.5.5 RESET
13.6 리플리케이션(Replication) 문
13.6.1 마스터 서버 컨트롤을 위한 SQL 문
13.6.1.1 PURGE MASTER LOGS
13.6.1.2 RESET MASTER

:::MySQL Korea:::
13.6.1.3 SET SQL_LOG_BIN

13.6.1.4 SHOW BINLOG EVENTS
13.6.1.5 SHOW MASTER LOGS
13.6.1.6 SHOW MASTER STATUS
13.6.1.7 SHOW SLAVE HOSTS
13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문
13.6.2.1 CHANGE MASTER TO
13.6.2.2 LOAD DATA FROM MASTER
13.6.2.3 LOAD TABLE tbl_name FROM MASTER
13.6.2.4 MASTER_POS_WAIT()
13.6.2.5 RESET SLAVE
13.6.2.6 SET GLOBAL SQL_SLAVE_SKIP_COUNTER
13.6.2.7 SHOW SLAVE STATUS
13.6.2.8 START SLAVE
13.6.2.9 STOP SLAVE
13.7 Prepared 문을 위한 SQL 신텍스

:::MySQL Korea:::
제목검색
13.1. 데이터정의 문
13. SQL 문법(SQL Statement Syntax)
13.1. 데이터정의 문 13.1.1. ALTER DATABASE
13.1 데이터정의 문 13.1.2. ALTER TABLE
13.1.1 ALTER DATABASE 13.1.3. CREATE DATABASE
13.1.2 ALTER TABLE 13.1.4. CREATE INDEX

13.1.5. CREATE TABLE
13.1.6. DROP DATABASE
13.1.4 CREATE INDEX
13.1.7. DROP INDEX
13.1.5 CREATE TABLE
13.1.8. DROP TABLE
13.1.5.1 Silent Column Specification Changes
13.1.9. RENAME TABLE
13.1.6 DROP DATABASE
13.1.7 DROP INDEX
............................................................................................................
13.1.8 DROP TABLE
13.1.9 RENAME TABLE
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.1 ALTER DATABASE
13. SQL 문법(SQL Statement Syntax) ALTER {DATABASE | SCHEMA} [db_name]

13.1. 데이터정의 문 alter_specification [, alter_specification] ...
13.1.1 ALTER DATABASE

alter_specification:
[DEFAULT] CHARACTER SET charset_name
| [DEFAULT] COLLATE collation_name
ALTER DATABASE는 여러분이 데이터베이스의 전체적인 특징들을 변경할 수 있도록 한다. 이들 특징들은 데이터베이스 디렉토
리의 db.opt 파일에 저장 되어 있다. ALTER DATABASE를 사용하기 위해서는 여러분이 데이터베이스 에서 ALTER 권한을 가
져야 한다. ALTER SCHEMA는 MySQL 5.0.2의 ALTER DATABASE와 같다.
CHARACTER SET 부분은 기본 데이터베이스 문자 셑을 변경한다. COLLATE부는 기본 데이터베이스의 조사을 변경한다. 문자

셑과 조사 문에 관해서는 10장에서 자세히 설명 한다.
데이터베이스 이름은 생략 될 수 있으며 이 경우 기본 데이터베이스가 적용된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.2. ALTER TABLE
13. SQL 문법(SQL Statement Syntax) ALTER [IGNORE] TABLE tbl_name

13.1. 데이터정의 문 alter_specification [, alter_specification] ...
13.1.2 ALTER TABLE
alter_specification:
ADD [COLUMN] column_definition [FIRST | AFTER col_name ]
| ADD [COLUMN] (column_definition,...)
| ADD INDEX [index_name] [index_type] (index_col_name,...)
| ADD [CONSTRAINT [symbol]]
PRIMARY KEY [index_type] (index_col_name,...)
UNIQUE [INDEX] [index_name] [index_type] (index_col_name,...)
| ADD [FULLTEXT|SPATIAL] [INDEX] [index_name] (index_col_name,...)
FOREIGN KEY [index_name] (index_col_name,...)
[reference_definition]
| ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}
| CHANGE [COLUMN] old_col_name column_definition
[FIRST|AFTER col_name]
| MODIFY [COLUMN] column_definition [FIRST | AFTER col_name]
| DROP [COLUMN] col_name
| DROP PRIMARY KEY
| DROP INDEX index_name
| DROP FOREIGN KEY fk_symbol
| DISABLE KEYS

:::MySQL Korea:::
| ENABLE KEYS
| RENAME [TO] new_tbl_name
| ORDER BY col_name
| CONVERT TO CHARACTER SET charset_name [COLLATE collation_name]
| [DEFAULT] CHARACTER SET charset_name [COLLATE collation_name]
| DISCARD TABLESPACE
| IMPORT TABLESPACE
| table_options
ALTER TABLE은 여러분이 현재 테이블의 구조를 변경할 수 있도록 한다. 한 예로, 여러분은 컬럼 추가/삭제, 인덱스 생성/삭제,
기존 컬럼의 type변경, 테이블 혹은 컬럼 자체의 이름 변경을 할 수 있다. 여러분은 또한 테이블의 type과 테이블을 위한 주석을 변
경 할 수도 있다.
많은 변경을 위한 구문은 CREATE TABLE문의 구문과 유사하다. 이는 ENGINE, AUTO_INCREMENT 그리고

AVG_ROW_LENGTH와 같은 옵션들과 같이 table_options 변경을 포함한다.(반면, ALTER TABLE문은 DATA DIRECTORY
과 INDEX DIRECTORY 테이블 옵션은 무시한다.)
13.1.5 장 “CREATE TABLE ”에서 모든 테이블 옵션에 대해 설명한다.
몇몇 기능들은 저장 엔진이 그 기능을 지원하지 않을 경우 테이블에 대해 어떤 시도를 할 경우 warning을 보낼 수 있다. 이들

warning은 SHOW WARNINGS와 함께 보여진다. 이에 대한 내용은 13.5.4.25 "SHOW WARNINGS"를 참조하라.
여러분이 하나의 컬럼 지정을 변경 하기 위해 ALTER TABLE을 사용하지만 DESCRIBE tbl_name 에는 여러분의 컬럼이 변경하
지 않은 것으로 표시된다면, 13.1.5.1” 암묵적인 컬럼 지정 변경”에서 설명하는 이유 중 하나로 인해 MySQL이 변경한 사항을
인식하지 못할 수 있다.
대부분의 경우, ALTER TABLE은 원본 테이블의 임시 복사본을 만들어서 작업을 한다. 변경 이 복사본에서 수행되고 원본 테이블
이 지워지고 새로이 이름 지워진다. ALTER TABLE이 수행되는 동안 원본 테이블은 다른 클라이언트들에 의해 읽혀질 수 있다.
테이블에 업데이트와 쓰기는 새로운 테이블이 준비될 때까지 거부되며, 자동으로 update의 실패 없이 새로운 테이블로 다시 향한
다.
여러분이 다른 옵션 없이 ALTER TABLE 테이블이름 RENAME TO 새 테이블 이름 을 사용한다면 MySQL은 단순히 테이블 이

:::MySQL Korea:::
름과 일치하는 파일들의 이름만 바꾸게 된다. 이때는 임시 테이블을 생성할 필요가 없다. (여러분은 테이블들을 재 명명 하기 위해
서 RENAME TABLE 문을 사용할 수 있다. 13.1.9 "RENAME TABLE"을 참조하라.)
여러분이 RENAME보다 ALTER TABLE에 옵션을 사용하면 MySQL은 컬럼의 이름을 변경하는 것과 같이 그 데이타가 복사될
필요가 없을 지라도, 항상 임시 테이블을 생성한다. MyISAM 테이블들에 대해, 여러분은 myisam_sort_buffer_size시스템 변수
를 높은 값으로 설정함으로써 인덱스 재 생성 작업(이것은 변경 처리 작업의 가장 느린 부분에 해당한다.)의 속도를 증가 시킬수 있
다
ALTER TABLE을 사용하기 위해 여러분은 테이블에 대한 ALTER, INSERT 그리고 CREATE 권한을 가져야 한다.
IGNORE는 표준 SQL에서 MySQL의 확장이다. 이것은 새로운 테이블에 unique key들이 중복될때 ALTER TABLE이 작동하는
방법이나 엄격 모드(strict mode)가 장동할때 warning이 났을때 등을 제어 한다. IGNORE가 명시 된 경우, 즉 첫번째 열이
unique key에서 중복 되어 존재 할 경우 , 다른 충돌되는 열들은 삭제 된다. 정확 하지 않은 값들은 가능한 수용 가능한 값으로 수
정된다.
여러분은 한 ALTER TABLE문에서 콤마로 구분하여 다수 ADD, ALTER, DROP 그리고 CHANGE문을 사용할 수 있다. 이것은
표준 SQL에 대한 MySQL의 확장인데 이것은 각 ALTER TABLE문에서 각 구문의 하나를 허락하는 것이다. 예를 들면, 하나의 문
에서 여러개의 컬럼을 drop하려 할경우 다음과 같이 하면 된다.
ALTER TABLE t2 DROP COLUMN c, DROP COLUMN d;
CHANGE col_name, DROP col_name, 그리고 DROP INDEX는 표준 SQL에대한 MySQL의 확장이다.
MODIFY는 ALTER TABLE에서 Oracle확장이다.
COLUMN은 옵션이며 생략 가능하다.
column_definition문들은 CREATE TABLE에서처럼 ADD와 CHANGE를 위해 같은 구문을 사용한다. 이 구문이 컬럼 이름을 포

함하는것에 주의 해야 한다. 이에 대한 자세한 사항은 13.1.5 "CREATE TABLE"을 참고한다.

:::MySQL Korea:::
여러문은 CHANGE 옛 컬럼 이름 새 컬럼 이름 구문을 사용하여 하나의 컬럼을 재 명명 할 수 있다. 이를 위해 기존 컬럼 과 새 컬

럼 이름들과 그 타입도 명시 하도록 한다. 예로써 INTEGER형인 컬럼 a를 b로 변경 하려 하면 다음과 같이;
ALTER TABLE t1 CHANGE a b INTEGER;
만일 여러분이 컬럼의 이름이 아닌 type을 변경하기 원한다 해도 CHANGE문은 앞의 것과 같이 사용한다. 예로서 아래와 같이 사
용 할 수 있다.
ALTER TABLE t1 CHANGE b b BIGINT NOT NULL;
여러분은 또한 컬럼의 이름을 재 명명 하지 않고 컬럼의 type만을 변경 하기 위해 아래와 같이 MODIFY를 사용할 수 있다.
ALTER TABLE t1 MODIFY b BIGINT NOT NULL;
여러분은 한 인덱스가 컬럼에 존재하도록 하기 위해 컬럼을 짧게하는 경우, 결과 적으로 컬럼 길이가 인덱스 길이보다 짧을때
MySQL은 인덱스를 자동으로 짧게 한다.
여러분이 CHANGE 나 MODIFY를 사용하여 데이터 타입을 변경 하는 경우, MySQL은 기존의 컬럼 값들을 가능한한 새로운 타입
으로 변경 하려 한다.
한 테이블 열에서 특정 위치에 컬럼을 추가 하기 위해서는 FIRST 혹은 AFTER 컬럼 이름 을 사용한다. 기본적으로는 컬럼을 가
장 마지막 부분에 추가 한다. 여러분은 또한 CHANGE나 MODIFY 기능들에서 FIRST 와 AFTER를 사용할 수 있다.
ALTER ... SET DEFAULT 혹은 ALTER ... DROP DEFAULT은 각각 한 커럼에 대한 새로운 기본 값을 명시 하거나 기존 값
을 지우도록 한다. 기존 기본값이 지워지고 그 컬럼이 NULL값이 될 수 있으면 새로운 기본 값은 NULL이 된다. 만일 그 컬럼이
NULL이 될 수 없다면, MySQL은 기본 값을 할당하는데 이에 대한 내용은 11.1.4 "데이터 타입 기본값들(Data Type Default
Values)"를 참조 하라.
DROP INDEX는 한 인덱스를 삭제 한다. 이것은 표준 SQL에 대한 MySQL의 확장이다. 13.1.7 "DROP INDEX"를 참조 하라.
컬럼들이 한 테이블로부터 삭제되면, 그 컬럼들은 또한 그들이 한 부분인 인덱스로부터 삭제 된다. 한 인덱스를 구성하는 모든 컬럼

:::MySQL Korea:::
들이 삭제 되면 그 인덱스 또한 삭제 된다.
한 테이블이 단지 하나의 컬럼을 가지고 있을 경우, 그 컬럼은 삭제 될 수 없다. 여러분이 의도하는 것이 테이블을 삭제 하는 것이라
면 DROP TABLE을 대신 사용하도록 하라.
DROP PRIMARY KEY는 primary 키를 삭제 한다. 주의 : MySQL의 이전 버전에서는 primary키가 존재 하지 않을 경우 DROP

PRIMARY KEY는 테이블에서 첫번째 UNIQUE 인덱스를 삭제 했었다. 그러나 MySQL 5.0에서는 primary 키가 없는 테이블에
서 DROP PRIMARY KEY를 사용하려 할때 에러를 일이킨다.
여러분이 테이블에 UNIQUE INDEX나 PRIMARY KEY를 추가 하면, 이것은 비 unique 인덱스 앞에 저장되어 MySQL이 가능한
한 빨리 중복 키를 찾을 수 있도록 한다.
ORDER BY는 여러분이 특정 순서대로 열을 가진 새 테이블을 생성하도록 한다. 삽입/삭제문 사용 후에는 이 순서대로 유지 되지
않음을 주의 하도록 한다. 이 옵션은 대부분 어떤 순서로 열들을 질의 하는 경우 가장 유용하다. 그 테이블에 대해 큰 변경후에 이
옵션을 사용 함으로써 여러분은 높은 처리 능력을 가지게 된다. 어떤 경우, 이것은 테이블이 여러분이 원하는 순서대로 정렬할 컬럼
의 순서대로 있다면 MySQL이 정렬을 쉽게 할 것이다.
여러분이 MyISAM 테이블에서 ALTER TABLE을 사용한다면 모든 non-unique인덱스들은 개별 배치(REPAIR TABLE에서와

같이)로 생성 된다. 이것은 여러분이 많은 인덱스를 가질때 ALTER TABLE은 훨씬 빠르게 만들것이다.
이 특징은 명백하게(explicitly) 활성화 될 수 있다. ALTER TABLE...DISABLE KEYS는 MySQL에게 MyISAM 테이블에서
non-unique 인덱스들을 업데이트 하는것을 정지 시키도록 한다. MySQL은 하나씩 key들을 삽입하는 것보다 훨씬 빠른 특별한
알고리즘으로 이것을 수행하며, 대량의 삽입 작업 들을 수행 하기 이전 키들을 금지하여 현저한 속도 향상이 이루어 진다. ALTER
TABLE....DISABLE KEYS는 이전에 언급한 권한 외에 추가적으로 INDEX 권한을 요구한다.
FOREIGN KEY 와 REFERENCES 구문은 InnoDB 저장 엔진에 의해 지원되는데, 이들은 ADD [CONSTRAINT [symbol]]
FOREIGN KEY (...) REFERENCES ... (...)을 제공한다. 14.2.6.4 “FOREIGN KEY 제약"을 참고한다. 다른 저장 엔진들에 대해
서는 이 구문이 분석은 되어지나 무시된다. CHECK 구문은 모든 저장 엔진에 의해서 무시된다. 이에 대한 내용은 13.1.5
“CREATE TABLE ”을 참조하라. 이처럼 구문을 받아들이지만 무시 하는 이유는 호환성때문인데 다른 SQL 서버로 포팅을 쉽게
한다던가 테이블을 생성하는 응용 프로그램을 실행 시키기 쉽게 하도록 하기 위해서이다. 자세한 내용은 1.9.5 "표준 SQL과

:::MySQL Korea:::
MySQL의 차이점"을 참조하도록 한다.
여러분은 하나의 ALTER TABLE문의 부분 절에서 외래키를 추가 와 삭제를 할 수 없다. 분리된 문장들에서 사용하여야 한다.
InnoDB는 외래 키들을 삭제 하기 위해 ALTER TABLE의 사용을 지원한다.
ALTER TABLE 테이블 이름 DROP FOREIGN KEY 외래키;
보다 자세한 내용은 14.2.6.4 "FORENGIN KEY 제약"을 참조하도록 하라.
여러분이 테이블 기본 character set과 모든 문자 열들(CHAR, VARCHAR,TEXT)을 새로운 character set으로 변경 하고자 한
다면 다음과 같은 구문을 사용한다.
ALTER TABLE 테이블 이름 CONVERT TO CHARACTER SET character set 이름;
주의: 앞의 연산은 컬럼 값을 변환한다. 이는 여러분이 한 character set(ex. latin1)안에 하나의 컬럼을 가지고 있고 저장된 값들
이 실제 다른 것들을 사용한다면 여러분이 원하는 바가 아니다. The preceding operation converts column values between
the character sets. This is not what you want if you have a column in one character set (like latin1) but the stored
values actually use some other, incompatible character set (like utf8). In this 이 경우 여러분은 각 컬럼에 대해 다음과 같
이 해 주어야 한다.
ALTER TABLE 테이블 CHANGE 컬럼1 컬럼1 BLOB;

ALTER TABLE 테이블 CHANGE 컬럼1 컬럼1 TEXT CHARACTER SET utf8;
위와 같이 작업 해야 하는 이유는 여러분이 BLOB 컬럼들로 부터 혹은 BLOB 컬럼들로 변환 하려 할때 변환이 이루어지지 않기 때

문이다.
여러분이 CONVERT TO CHARACTER SET binary로 명시 하면, CHAR, VARCHAR그리고 TEXT 컬럼들은 그것들과 대응되
는 바이너리 string 타입들로 변환 된다(BINARY, VARBINARY, BLOB). 이는 컬럼들이 더이상 character set을 가지지 않게 되
며 CONVERT TO연산이 적용되지 않게 됨을 의미한다.

:::MySQL Korea:::
테이블의 기본 character set을 변경 하기 위해서는 다음 문장을 사용한다.
ALTER TABLE 테이블 이름 DEFAULT CHARACTER SET character set 이름;
DEFAULT는 옵션 사항이다. 기본 character set은 여러분이 테이블에 추가 하려는 새 컬럼을 위해 character set을 명시 하지 않
으면 기본으로 설정된다. (예를 들면, ALTER TABLE... ADD 컬럼 과 같은 문장)
한 .ibd 파일안에서 테이블 공간을 가지고 생성된 InnoDB 테이블에 대해서는 그 파일은 제외 되고 반입 될 수 있다.
.idb파일을 제외 하기 위해서는 다음 문장을 사용한다.
ALTER TABLE 테이블 이름 DISCARD TABLESPACE;
이문장은 현재 .ibd파일을 삭제 하게 되므로 여러분은 백업을 가져야 한다. 테이블공간 파일이 제외되는 동안 테이블에 접근 하려
한다면 에러를 발생시킨다.
.idb파일을 다시 테이블에 포함 시키려면 데이터베이스 디렉토리에 복사를 하고 다음 문장을 사용하도록 한다.
ALTER TABLE 테이블 이름 IMPORT TABLESPACE;
14.2.3.1 "테이블당 테이블공간 사용"을 참조한다.
C API 함수인 mysql_info()를 사용하면 여러분은 얼마나 많은 레코드들이 복사 되었는지 알 수 있으며, (IGNORE를 사용할 경
우)unique 키 값의 중복으로 인해서 얼마나 많은 레코드가 지워 졌는지 알 수 있다. 이에 대한 자세한 사항은 22.2.3.34
"mysql_info()함수"를 참조하라.
아래는 ALTER TABLE의 사용을 보여주는 예들이다.
CREATE TABLE 테이블1 (a INTEGER,b CHAR(10));
테이블을 테이블1 에서 테이블 2로 이름을 변경 하려 할때

:::MySQL Korea:::
ALTER TABLE 테이블1 RENAME 테이블2;
INTEGER 형 컬럼을 TINYINT NOT NULL으로 변경 하기 위해서, b에서 c로 이름을 변경 하는 것 뿐만 아니라 CHAR(10)에서
CHAR(20)으로 변경하기 위해서는 아래 문장을 사용한다.
ALTER TABLE 테이블2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);
새로운 TIMESTAMP 컬럼인 d를 추가 하려할때는
ALTER TABLE 테이블 2 ADD d TIMESTAMP;
컬럼 d와 컬럼 a에서 인덱스를 추가 하기 위해서는
ALTER TABLE 테이블2 ADD INDEX (d), ADD INDEX (a);
컬럼 c를 삭제 하려면
ALTER TABLE 테이블2 DROP COLUMN c;
새로운 AUTO_INCREMENT속성의 정수 컬럼인 c를 추가 하려면
ALTER TABLE 테이블2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,

ADD PRIMARY KEY (c);
AUTO_INCREMENT 컬럼들은 인덱싱 되어야 하기 때문에, 컬럼 c를 PRIMARY KEY로 지정 했다. 또한 primary 키 컬럼들은
NULL이 될수 없기 때문에 c를 NOT NULL로 정의 했다.
여러분이 AUTO_INCREMENT 컬럼을 추가할때 컬럼 값들은 자동으로 순차적인 숫자로 채워 진다. MyISAM 테이블들에 대해서
여러분은 ALTER TABLE 이전에 SET INSERT_ID=값 을 실행 하거나 AUTO_INCREMENT=값 테이블 옵션을 사용하여 첫
sequence number를 설정 할 수 있다. 13.5.3 "SET" 을 참조하라.

:::MySQL Korea:::
MySQL5.0.3부터 여러분은 AUTO_INCREMENT 컬럼에있는 최대 값보다 값이 큰 경우 새로운 줄에 대해서 sequence number

를 설정하기 위해서 ALTER TABLE ... AUTO_INCREMENT=값 테이블 옵션을 사용할수 있다. 그 값이 컬럼에 있는 최대 값보
다 작다면 에러 메시지가 발생하지 않으며 현재 sequence 값은 변경 되지 않는다.
MyISAM 테이블에서는 여러분이 AUTO_INCREMENT 컬럼을 변경 하지 않으면 sequence number는 영향을 받지 않는다. 만
약 여러분이 AUTO_INCREMENT 컬럼을 제거 하면 그 숫자들은 시작 값을 1로 재 설정 된다.
A.7.1, “ALTER TABLE에서의 문제들”부분을 참조하라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.3. CREATE DATABASE
13. SQL 문법(SQL Statement Syntax) CREATE {DATABASE | SCHEMA} [IF NOT EXISTS] 데이터베이스 이름
13.1. 데이터정의 문 [생성 옵션 [, 생성 옵션] ...]

생성 옵션:
[DEFAULT] CHARACTER SET character set 이름
| [DEFAULT] COLLATE 정렬 이름
CREATE DATABASE 는 주어진 이름으로 데이터베이스를 생성한다. CREATE DATABASE를 사용하기 위해서는 데이터베이스에 대
해 생성 권한을 필요로 한다. CREATE SCHEMA 는 MySQL 5.0.2에서 CREATE DATABASE와 동일하다.
허가된 데이터베이스 이름에 대한 규칙은 9.2 "데이터베이스, 테이블 인덱스, 컬럼 그리고 Alias 이름들"을 참고 한다. 여러분이 데
이터 생성시 IF NOT EXIST를 명시 하지 않은 경우 데이터베이스가 존재하면 에러가 발생한다.
생성 옵션들은 데이터베이스이 특징을 명시한다. 데이터베이스 특징은 데이터베이스 디렉토리의 db.opt파일 안에 저장된다.
CHARACTER SET문은 기본 데이터베이스 character set을 명시 한다. COLLATE문은 기본 데이터베이스 정렬을 명시 한다.
10 장 "Character Set 지원" 은 character set 이름과 정렬 이름에 대해 설명 한다.
MySQL의 데이터베이스는 데이터베이스안의 테이블들에 해당하는 파일들을 포함하는 디렉토리들로 구현 된다. 처름 생성 될때는
데이터베이스 안에 테이블이 존재 하지 않기 때문에 CREATE DATABASE 문장은 단지 MySQL 데이터 디렉토리 아래에 하나의
디렉토리와 db.opt 파일만을 생성 한다.
여러분이 직접 데이터 디렉토리 하에 하나의 디렉토리를 생성하면(예를 들면 , mkdir등의 명령) 서버는 그것을 데이터 디렉토리로
인식하며 SHOW DATABASE명령에 대해 내용을 보여준다.

:::MySQL Korea:::
여러분은 또한 데이터베이스를 생성하기 위해 mysqladmin프로그램을 사용할 수 있다. 이에 대한 내용은 8.7 "mysqladmin -

MySQL서버 관리를 위한 클라이언트 프로그램"을 참조한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.4. CREATE INDEX
13. SQL 문법(SQL Statement Syntax) CREATE [UNIQUE|FULLTEXT|SPATIAL] INDEX 인덱스 이름

13.1. 데이터정의 문 [USING 인덱스 타입]
13.1.4 CREATE INDEX ON 테이블 이름(인덱스 컬럼 이름,...)
인덱스 컬럼 이름:
컬럼 이름 [(길이)] [ASC | DESC]
CREATE INDEX는 인덱스를 생성하기 위해 ALATER TABLE 문으로 매핑 된다. 자세한 내용은 13.1.2, "ALTER TABLE"을 참
조 하라. 어떻게 MySQL이 인덱스들을 사용하는지에 대해 좀더 자세한 정보를 원한다면 7.4.5, "MySQL의 인덱스 사용방법" 부분
을 참조하라.
일반적으로 여러분은 CREATE TABLE문으로 테이블이 생성될때 모든 인덱스를 생성 할 수 있다. 이에 대한 내용은 13.1.5
"CREATE TABLE"부분을 참조하라. CREATE INDEX 는 여러분이 기존 테이블에 인덱스를 추가할 수 있도록 한다.
(컬럼1,컬럼2,...)형태의 컬럼 리스트는 다수 컬럼 인덱스를 생성한다. 인덱스 값들은 주어진 컬럼들의 값들을 연계 하여 형성된다.
CHAR, VARCHAR, BINARY 와 VARBINARY 컬럼들에 대해 인덱스들은 인덱스의 길이를 명시하기 위해 컬럼 이름 (길이)문의 사용
과 같이 단지 한 컬럼의 부분만을 사용하여 생성 될 수 있다. 인덱스는 CHAR 와 VARCHAR 컬럼들에 대한 각 컬럼 값의 처음 길
이 문자들과, BINARY와 VARBINARY컬럼들을 위한 각 컬럼 값의 첫 길이 바이트 들로 구성된다. BLOB와 TEXT컬럼들 또한 인
덱싱 될 수 있으나 ,prefix length(전위어 길이)가 주어져야 한다.
여기 보여지는 문장은 이름 컬럼의 첫 10자리를 이용하여 인덱스를 생성한다.
CREATE INDEX 이름의부분 ON customer (이름(10));

:::MySQL Korea:::
컬럼의 이름들이 첫 10자리가 다르다면, 이 인데그는 전체 이름 컬럼으로 부터 생성된 인덱스 보다 느려져서는 안된다. 또한 인덱
스에 대한 부분 컬럼사용은 인덱스 파일을 훨씬 작게 만들수 있는데 이는 디스크 공간을 많이 절약 하게 디며 INSERT 작업을 빠르
게 처리 하게 된다.
Prefix들은 1000바이트 까지 될 수 있다( InnoDB 테이블들은 767바이트 까지). Prefix제한은 CREATE INDEX 문에서 prefix의
길이가 비 바이너리 데이터 타입(CHAR, VARCHAR, TEXT)에서 문자열의 수로 해석 되는 것과 달리, 바이트들로 측정됨을 주
시 하라. 멀티byte character set을 사용하는 컬럼의 prefix 길이를 명시 할때 이를 기억 하도록 한다.
MySQL 5.0에서
오직 MyISAM, InnoDB, BDB 혹은 MEMORY 저장 엔진을 사용할 경우에만 NULL을 가지는 컬럼에 인덱스를 추가할수 있다.
인덱스 컬럼 이름 옵션은 ASC나 DESC로 명시 된다. 이들 키워드 들은 ascending(증가) 혹은 descending(감소) 인덱스 값 저장

을 명시 하기 위해 추후 확장을 위해 호락 된다. 현재 이들은 분석이 되지만 무시되며 인덱스 값들은 항상 ascending 순서로 저장
되어 있다.
모든 저장 엔진은 여러분이 인덱스를 생성할때 이를 명시하도록 한다. 인덱스 타입을 위한 이 구문은 USING 타입 이름 을 명시 한
다. 다른 저장 엔진에 의해 지원되는 수용가능한 타입 이름 값이 다음 테이블에서 보여진다. 다수 인덱스 타입들이 나열 된 곳에서
첫번째 것은 인덱스 타입 옵션이 주어지지 않을경우 첫번째가 기본 값이 된다.
저장 엔진 가능 인덱스 타입
MyISAM BTREE
InnoDB BTREE
MEMORY/HEAP HASH, BTREE
사용 예:
CREATE TABLE lookup (id INT) ENGINE = MEMORY;

CREATE INDEX id_index USING BTREE ON lookup (id);

:::MySQL Korea:::
TYPE 의 타입 이름은 인덱스 타입을 명시 하기 위해 USING 타입 이름 와 동일하게 사용된다. 추가적으로 인덱스 명시 문에서 인덱
스 타입보다 선행 하는 인덱스 이름은 TYPE의 옵션이 아니다. 즉 USING과 달리, TYPE은 예약어가 아니며 이름이 주어지지 않을
경우 인덱스 이름으로 해석 된다.
여러분이 주어진 저장 엔진에 대해 적법하지 않은 인덱스를 명시하고 질의 결과에 영향을 주지 않게 엔진이 사용하는 인덱스 타입
이 있다면 엔진은 가능한 타입을 사용한다.
FULLTEXT 인덱스들은 오직 MyISAM 테이블들에 의해서만 지원 되며 CHAR, VARCHAR 그리고 TEXT 컬럼만을 포함한다.
12.7 "전체 텍스트 검색 함수들"을 참조한다.
SPATIAL인덱스들은 오직 MyISAM테이블들에 의해서만 지원되며 NOT NULL로 정의 된 컬럼들만을 포함 할 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.5. CREATE TABLE
13. SQL 문법(SQL Statement Syntax) 13.1.5.1. 암묵적 컬럼 지정 변경

13.1.5 CREATE TABLE

13.1.5.1 Silent Column Specification Changes CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
[(create_definition,...)]
[table_options] [select_statement]
이나
CREATE [TEMPORARY] TABLE [IF NOT EXISTS] tbl_name
[(] LIKE old_tbl_name [)];
생성 정의:
컬럼 정의
| [CONSTRAINT [symbol]] PRIMARY KEY [index_type] (index_col_name,...)
| KEY [index_name] [index_type] (index_col_name,...)

:::MySQL Korea:::
| INDEX [index_name] [index_type] (index_col_name,...)
| [CONSTRAINT [symbol]] UNIQUE [INDEX]
[index_name] [index_type] (index_col_name,...)
| [FULLTEXT|SPATIAL] [INDEX] [index_name] (index_col_name,...)
| [CONSTRAINT [symbol]] FOREIGN KEY
[index_name] (index_col_name,...) [reference_definition]
| CHECK (expr)
컬럼 정의:
col_name type [NOT NULL | NULL] [DEFAULT default_value]
[AUTO_INCREMENT] [UNIQUE [KEY] | [PRIMARY] KEY]
[COMMENT 'string'] [reference_definition]
타입:
TINYINT[(length)] [UNSIGNED] [ZEROFILL]
| SMALLINT[(length)] [UNSIGNED] [ZEROFILL]

:::MySQL Korea:::
| MEDIUMINT[(length)] [UNSIGNED] [ZEROFILL]
| INT[(length)] [UNSIGNED] [ZEROFILL]
| INTEGER[(length)] [UNSIGNED] [ZEROFILL]
| BIGINT[(length)] [UNSIGNED] [ZEROFILL]
| REAL[(length,decimals)] [UNSIGNED] [ZEROFILL]
| DOUBLE[(length,decimals)] [UNSIGNED] [ZEROFILL]
| FLOAT[(length,decimals)] [UNSIGNED] [ZEROFILL]
| DECIMAL(length,decimals) [UNSIGNED] [ZEROFILL]
| NUMERIC(length,decimals) [UNSIGNED] [ZEROFILL]
| DATE
| TIME
| TIMESTAMP
| DATETIME
| YEAR
| CHAR(length) [BINARY | ASCII | UNICODE]
| VARCHAR(length) [BINARY]

:::MySQL Korea:::
| BINARY(length)
| VARBINARY(length)
| TINYBLOB
| BLOB
| MEDIUMBLOB
| LONGBLOB
| TINYTEXT [BINARY]
| TEXT [BINARY]
| MEDIUMTEXT [BINARY]
| LONGTEXT [BINARY]
| ENUM(value1,value2,value3,...)
| SET(value1,value2,value3,...)
| spatial_type
index_col_name:
col_name [(length)] [ASC | DESC]

:::MySQL Korea:::
reference_definition:
REFERENCES tbl_name [(index_col_name,...)]
[MATCH FULL | MATCH PARTIAL | MATCH SIMPLE]
[ON DELETE reference_option]
[ON UPDATE reference_option]
reference_option:
RESTRICT | CASCADE | SET NULL | NO ACTION
table_options: table_option [table_option] ...
table_option:
{ENGINE|TYPE} [=] engine_name
| AUTO_INCREMENT [=] value
| AVG_ROW_LENGTH [=] value
| [DEFAULT] CHARACTER SET charset_name [COLLATE collation_name]

:::MySQL Korea:::
| CHECKSUM [=] {0 | 1}
| COMMENT [=] 'string'
| CONNECTION [=] 'connect_string'
| MAX_ROWS [=] value
| MIN_ROWS [=] value
| PACK_KEYS [=] {0 | 1 | DEFAULT}
| PASSWORD [=] 'string'
| DELAY_KEY_WRITE [=] {0 | 1}
| ROW_FORMAT [=] {DEFAULT|DYNAMIC|FIXED|COMPRESSED|REDUNDANT|COMPACT}
| UNION [=] (tbl_name[,tbl_name]...)
| INSERT_METHOD [=] { NO | FIRST | LAST }
| DATA DIRECTORY [=] 'absolute path to directory'
| INDEX DIRECTORY [=] 'absolute path to directory'
select_statement:
[IGNORE | REPLACE] [AS] SELECT ... (Some legal select statement)

:::MySQL Korea:::
CREATE TABLE은 주어진 이름으로 테이블을 생성한다. 여러분은 테이블에 대한 생성 권한을 가지고 있어야 한다.
테이블 이름 지정에 관한 규칙은 9.2 장 "데이타베이스, 테이블, 인덱스, 컬럼, 별칭 이름" 부분을 참조한다. 기본적으로 테이블은
기본 데이타 베이스 안에서 생성된다. 기본 데이타베이스가 없거나 테이블이 존재 하는 경우 에러를 발생 시킨다.
테이블 이름은 특정 데이터베이스안에 테이블을 생성 하기 위해서는 데이터베이스 이름.테이블 이름 으로 명시 할 수 있다. 이 작읍

은 기본 데이타베이스의 존재 와 관계없이 수행된다. 인용 식별자들을 사용할 경우에는 데이터베이스와 테이블 이름을 개별적으로
인용 문을 사용하도록 한다. 예를 들자면, 'mydb.mytbl'이 아니라 'mydb'.'mytble'로 표기 해야 한다.
테이블을 생성할 경우 TEMPORARY 키워드를 사용 할 수 있다. TEMPORARY 테이블은 현제 연결에서만 볼 수 있고 연결이 닫

힐때 자동으로 삭제 된다. 이것은 두개의 서로 다른 연결이 같은 이름의 임시 테이블 혹은 비 임시 테이블이건 간에 충돌 없이 사용
할 수 있음을 의미한다(기존 테이블은 임시 테이블이 삭제 될때까지 보여지지 않는다). 여러분이 임시 테이블을 생성 하기 위해서
는 CREATE TEMPORARY TABLES 권한을 가지고 있어야 한다.
IF NOT EXISTS 키워드는 테이블이 존재하는 경우 발생하게될 에러를 방지 해 준다. 그러나 CREATE TABLE 문에 의해 명시것
과 같이 같은 구조를 가지는 테이블이 존재하는 것에 대한 검증은 하지 않는다.
주의: CREATE TABLE... SELECT 문에서 IF NOT EXISTS 문을 사용할 경우 SELECT에 의해 선택된 레코드들은 테이블이 이
미 존재 하는 경우라도 삽입 된다.
MySQL은 데이터베이스 디렉토리 안에 하나의 .frm(정의)포맷으로 각 테이블을 표현 한다. 테이블을 위한 저장 엔진은 다른 파일

들도 생성 한다. MyISAM 테이블의 경우, 저장 엔진은 데이타와 인덱스 파일들을 생성한다. 따라서 각 MyISAM 테이블에 대해서
는 세개의 디스크 파일들이 존재 한다.
File Purpose
tbl_name.frm 테이블 포맷 (정의)파일
tbl_name.MYD 데이터 파일
tbl_name.MYI 인덱스 파일

:::MySQL Korea:::
14장 "저장 엔진과 테이블 타입"에서는 저장 엔진이 테이블을 표현 하기 위해 사용하는 각 파일들에 대해 설명한다.
타입은 데이터 타입이 컬럼 정의라는 것을 표현 한다. 공간 타입(spatial type)은 공간 데이터 타입을 표현한다. 데이터 타입들의
속성에 관한 일반적인 정보는 11장 "데이터 타입" 부분을 참조 하라. 공간 데이터 타입(spatial data type)에 관한 보다 자세한 내
용은 16장 "공간 확장(Spatial Extension)"부분을 참조 하라.
l NULL혹은 NOT NULL이 명시 되지 않았다면 컬럼은 NULL이 명시 된것으로 간주 한다.
l 하나의 정수 컬럼은 추가적으로 AUTO_INCREMENT 속성을 가질 수 있다. 여러분이 AUTO_INCREMENT 인덱스

컬럼의 값을 NULL 혹은 0으로 입력 하면 그 컬럼은 다음 일련 번호 값으로 설정된다. 일반적으로 이 것은 value + 1 로 되며 테
이블의 컬럼 값 중 가장 큰 값이 된다. AUTO_INCREMENT 일련번호는 1부터 시작한다.
하나의 레코드를 삽입 한 후에 AUTO_INCREMENT 값을 받기 위해서는 LAST_INSERT_ID() SQL 함수나 C API 함수인

mysql_insert_id() 를 사용하라. 이에 대한 내용은 12.9.3장 "정보 함수들"부분과 22.2.3.36 장 "mysql_insert_id()" 부분을 참조
하라.
NO_AUTO_VALUE_ON_ZERO SQL 모드가 동작 하면, 새로운 일련 번호를 생성하지 않은채 0으로 AUTO_INCREMENT 컬럼
들에 저장 할 수 있다. 이에 대한 내용은 5.2.5장 "서버 SQL 모드" 부분을 참조한다.
주의: 테이블당 단지 하나의 AUTO_INCREMENT 컬럼이 있을 수 있고 인덱싱 되어야 하며 DEFAULT 값을 가질 수 없다. 하나

의 AUTO_INCREMENT 컬럼은 양수를 가질 경우에만 올바르게 작동한다. 음수의 삽입은 매우 큰 양수를 입력 한 것으로 간주 된
다. 이는 숫자들이 양수가 음수로 뒤바뀔 때 정확성 문제를 피하고 여러분이 0을 포함하고 있는 AUTO_INCREMENT 컬럼을 가질
수 있는 상황을 피하기 위한 것이다.
MyISAM 와 BDB 테이블들에 대해 다수 컬럼 키안에서 AUTO_INCREMENT 2차 컬럼을 지정할 수 있다. 3.6.9장

"AUTO_INCREMENT 사용"부분을 참조하라.
MySQL을 ODBC 응용 프로그램과 호환성을 갖도록 하기 위해서는 다음 질의로 가장 마지막에 삽입된 AUTO_INCREMENT 값

:::MySQL Korea:::
을 찾을수 있다.
SELECT * FROM 테이블 이름 WHERE 자동 증가 컬럼 IS NULL
l SERIAL의 속성은 BIGINT UNSIGNED NOT NULL AUTO_INCREMENT UNIQUE 에 대한 별칭이다..
l 문자형(CHAR, VARCHAR, TEXT)은 컬럼에 대한 문자 집합과 정렬을 지정하기 위한 CHARACTER SET 과

COLLATE 속성들을 포함 할 수 있다. 자세한 사항은 10장 "문자 집합 지원"부분을 참조하라. CHARSET은 CHARACTER SET
과 동의어이다.
CREATE TABLE 테이블 (컬럼 CHAR(20) CHARACTER SET utf8 COLLATE utf8_bin);
MySQL 5.0은 문자 컬럼 정의에서 길의 명시를 문자열들로 해석한다. (MySQL 4.1 이전 버넌에서는 byte로 해석했다)
l DEFAULT 문은 컬럼에 대한 기본 값을 지정한다. 한가지 예외로 기본 값은 제약 조건이 되어야만 한다. 즉 이것은 함

수나 표현식이 될수 없다. 이것은 여러분이 NOW()나 CURRENT_DATE 와 같은 함수의 값으로 날짜 컬럼의 기본값으로 설정 할
수 없다는 의미이다. 예외적으로 TIMESTAMP컬럼에 대한 기본 값으로 CURRENT_TIMESTAMPA를 지정 할 수 있다.
11.3.1.1장 "MySQL 4.1의 TIMESTAMP 속성"부분을 참조하라.
컬럼 정의가 DEFAULT 값을 포함하지 않는다면 MySQKL은 11.1.4장 " 테이터 형과 기본 값"부분에서 기술된 기본 값으로 설정
한다.
BLOB 와 TEXT 컬럼들은 기본 값으로 할당될 수 없다.
l 컬럼에 대한 주석은 COMMENT 옵션으로 지정될 수 있다. 주석은 SHOW CREATE TABLE 과 SHOW FULL
COLUMNS 문에서 보여진다.
l KEY 는 보통 INDEX 와 같은 의미를 갖는다. PRIMARY KEY 속성은 컬럼 정의에서 KEY로서 명시 지시 될 수 있다.
이는 다른 데이터베이스 시스템들과의 호환성을 위해 구현되었다.
l UNIQUE 인덱스는 인덱스 안의 모든 값들이 유일 해야 한다는 것과 같은 제약 조건을 생성 한다. 여러분이 현재 존재

:::MySQL Korea:::
하는 레코드와 매치 되는 키로 새로운 레코드를 추가 하려하면 에러를 발생 시킨다. 이 예외는 인덱스의 컬럼이 NULL 값의 포함
이 허락 될 경우 다수 NULL 값을 포함 할 수 있다. 이 예외는 BDB 테이블 에서는 적용 되지 않는데 UNIQUE 인덱스를 가진 컬럼
이 단 하나의 NULL 값만을 허용 하기 때문이다.
l PRIMARY KEY 는 모든 키 컬럼들이 NOT NULL로 정의 되어야 할때 유일한 인덱스 이다. 이들이 NOT NULL로 명
시적으로 선언되지 않으면 MySQL은 암시적으로 선언 하게 된다. 하나의 테이블은 오직 하나의 PRIMARY KEY를 가질 수 있다.
여러분이 PRIMARY KEY 를 갖지 않은 상태에서 응용 프로그램이 그 테이블의 PRIMARY KEY에 관해 질의를 할 경우, MySQL
은 PRIMARY KEY 로서 NULL 값을 갖지 않는 컬럼을 UNIQUE 인덱스로 리턴한다.
InnoDB 테이블에서 긴 PRIMARY KEY는 공간을 낭비 하게 된다 (이에 대한 내용은 14.2.13 장 " PRIMARY KEY 테이블 과 인
덱스 구조" 부분을 참조하라).
l 생성된 테이블에서 PRIMARY KEY 가 최우선에 위치하고 그담으로 UNIQUE 인덱스들이 그다음이 non- UNIQUE
인덱스들이 위치한다. 이는 MySQL 최적기(optimizer)가 어떤 인덱스를 사용하고 중복된 UNIQUE 키들을 좀더 빨리 찾기 위해
우선 순위를 매겨놓는데 도움을 준다.
l PRIMARY KEY 는 다수 컬럼 인덱스가 될 수 있다. 그러나 여러분이 컬럼 지정에서 PRIMARY KEY 속성을 사용하여
다수 컬럼 인덱스를 생성 할 수는 없다. 단일 컬럼을 PRIMARY로 명시하는 것만 가능하다. 여러분은 개별 PRIMARY KEY (인덱
스 컬럼 이름, ...)문을 사용해야 한다.
l PRIMARY KEY 나 UNIQUE 인덱스는 정수형으로 된 하나의 컬럼 으로 이루어지며 여러분은 SELECT 문에서
_rowid로서 그 컬럼을 참조 할 수 있다.
MySQL에서 PRIMARY KEY 의 이름은 PRIMARY이다. 다른 인덱스들에 대해서는 이름을 지정하지 않으면 그 인덱스는 첫 인덱
싱된 컬럼과 같은 이름으로 지정되는데 유일하게 만들기 위해서 _2 혹은 _3 과 같이 접미어를 붙이기도 한다. 여러분은 SHOW
INDEX FROM tbl_name 을 사용하여 인덱스 이름들을 볼 수 있다. 이에 대한 내용은 13.5.4.13장 "SHOW INDEX"를 참조하라.
몇몇 저장 엔진들은 인덱스를 생성할때 인덱스 타입을 명시 하도록 하기도 한다. 인덱스 타입 지정자에 대한 문법은 USING 타입
이름 이다.

:::MySQL Korea:::
예:
CREATE TABLE lookup

(id INT, INDEX USING BTREE (id))
ENGINE = MEMORY;
USING에 대한 자세한 내용은 13.1.4 장 "CREATE INDEX" 부분을 참조하라.
MySQL이 어떻게 인덱스들을 사용하는지에 대한 보다 자세한 사항은 7.4.5장 "MySQL의 인덱스 사용법" 부분을 참조하라.
l MySQL 5.0에서는 오직 MyISAM, InnoDB, BDB, 와 MEMORY 저장 엔진들만이 NULL값을 가질 수 있는 컬럼들에

게 인덱스를 지원한다. 다른 경우에는 인덱스 컬럼들에 대해서는 NOT NULL로 선언 해야 한다. 그렇지 않을 경우 에러를 리턴한
다.
l 인덱스 지정에서 컬럼 이름(길이) 문을 사용하여 여러분은 한 컬럼의 일 부분만을 사용하는 인덱스를 생성 할 수 있다.
인덱스 엔트리는 CHAR 와 VARCHAR 형의 컬럼들에 대해 각 컬럼 값에서 길이 만큼의 문자열들이나 BINARY 나 VARBINARY
형의 컬럼들에 대해서 각 컬럼의 첫 길이만큼의 byte들로 이루어진다. 이와 같이 컬럼 값들의 접두어(prefix)의 인덱싱은 인덱스
파일을 훨씬 작게 할 수 있다. 7.4.3 장 "컬럼 인덱스" 부분을 참조하라.
MyISAM, BDB 과 InnoDB 저장 엔진은 BLOB 와 TEXT 컬럼에서 인덱싱을 지원하므로 여러분은 인덱스의 길이를 명시 해야 한
다.
예를 들면:
CREATE TABLE test (컬럼이름 BLOB, INDEX(컬럼 이름(10)));
Prefixes들은 최대 1000 바이트 길이까지 가능 하다(InnoDB 테이블인 경우 767 byte). Prefix 제한들은 byte로 측정되나
CREATE TABLE 문에서 prefix길이는 비 바이너리형(CHAR, VARCHAR, TEXT)들에 대한 문자열의 수로 해석 된다. 다수 바
이트 문자열 모음(character set)을 사용하는 컬럼에 대해서는 prefix길이을 지정할때 유의 해야 한다.
l 인덱스 컬럼 이름 지정은 ASC 나 DESC로 끝날 수 있다. 이들 키워드들은 오름순 혹은 내림순 인덱스 값 저장을 지정할때 사

:::MySQL Korea:::
용하기 위한 것들이다. 현재는 이들이 분석되지만 무시되는 상태이며 이는 곧 모든 인덱스 값들은 항상 오름순 으로 저장 됨을 의미
한다.
l 여러분이 SELECT에서 TEXT 혹은 BLOB 형 컬럼에 대해 ORDER BY나 GROUP BY를 사용할 경우, 서버는 최대 정렬 길
이 시스템 변수들에 의해 지정된 바이트들의 처음 숫자를 사용하여 값들을 정렬 한다. 이에 대한 자세한 내용은 11.4.3장 "BLOB
와 TEXT형" 부분을 참조하라.
l 사용자는 특별한 FULL TEXT 인덱스들을 생성 할수 있는데 이들은 전체 텍스트 검색에 사용된다. MyISAM저장 엔진만이
이 FULL TEXT 인덱스를 지원한다. 이 인덱스들은 CHAR, VARCHAR 과 TEXT 컬럼들로 부터 생성 될 수 있다. 인덱싱은 전체
컬럼에 대해 항상 발생 하며 부분 인덱싱은 지원 되지 않으며 prefix길이가 명시된 경우 이는 무시 된다. 이에 대한 사항은 12.7
"전체 텍스트 검색 함수" 부분을 참조 하라.
l 사용자는 공간 데이터 형으로 SPATIAL 인덱스를 생성 할 수 있다. 공간형들은 MyISAM 테이블들에서만 지원 되며 인덱스
컬럼들은 NOT NULL로 선언 되어야 한다. 이에 대한 사항은 16장 "Spatial 확장" 부분을 참조하라.
l InnoDB테이블은 외래 키 제약 조건에 대한 확인을 제공한다. 14.2장 "InnoDB 저장 엔진"부분에 이에 대한 내용이 있다.

InnoDB에서 FOREIGN KEY는 이 부분의 시작부에 CREATE TABLE문에 나타난 것보다 제한적이다. 참조 테이블의 컬럼들은
항상 명시적으로 명명 되어야 하며 InnoDB는 ON DELETE와 ON UPDATE 적용을 외래키들에 대해 제공한다. 자세한 사항은
14.2.6.4장 "FOREIGN KEY 제약 사항" 부분을 참조하라.
다른 저장 엔진들에 대해서는 MySQL서버가 CREATE TABLE 문에서 FOREIGN KEY와 REFERENCE문은 분석하나 무시 한
다. CHECK문은 모든 저장 엔진에 의해 무시 되며 1.9.5.5장 "외래키" 부분을 참조 하라.
l MyISAM 테이블의 경우, 각 NULL 컬럼은 최근접 바이트로 반올림하는 하나의 엑스트라 비트(bit)를 가진다. 최대 열
의 바이트 길이는 다음과 같이 계산할 수 있다.
레코드 길이 = 1
+ (컬럼 길이의 합)
+ (NULL 컬럼의 수 + delete_flag + 7) /8
+ (가변길이 컬럼의 수)
delete_flag 는 고정 레코드 포멧을 가진 테이블에 대해 1값을 갖는다. 고정 테이블은 레코드가 삭제 되었는지 나타내는 플래그로

:::MySQL Korea:::
레코드에서 한 bit를 사용한다. 동적 테이블에 대해서는 이 플래그가 동적 레코드 헤더에 저장 되므로 0 값을 가진다.
위의 식은 저장 크기가 NOT NULL 컬럼 보다는 NULL 컬럼들에 대해서 차이가 없으므로 InnoDB 테이블에 적용되지는 않는다.
ENGINE 테이블 옵션은 테이블을 위한 저장 엔진을 지정한다. TYPE이 동의어 이나 ENGINE 이 주로 사용되는 옵션 이름이다.
ENGINE 테이블 옵션은 다음 테이블에서 보여지는 바와 같이 저장 엔진 이름을 갖는다.
Storage Engine 설명
ARCHIVE archive 저장 엔진 14.8장 "ARCHIVE 저장 엔진"부분을 참조하라.
페이지 잠금을 통한 트랜잭션 안전 테이블. BerkeleyDB로 알려져 있음. 14.5장 "BDB(BerkelyDB)저장

BDB
엔진"부분을 참조하라.
CSV 콤마로 구분되는 값 포맷으로 레코드를 저장하는 테이블들. 14.9장 "CSV 저장 엔진"을 참조하라..
EXAMPLE 예제 엔진. 14.6장 "EXAMPLE 저장 엔진"을 참조하라..
FEDERATED 원격 테이블들에 접근하는 저장 엔진. 14.7장 "FEDERATED 저장 엔진"을 참조하라.
HEAP MEMORY와 동의어
MySQL 5.0에서는 불가능. 이전 버전에서 MySQL 5.0으로 DB를 업그레이드 할 경우 ISAM 테이블을
ISAM (OBSOLETE)
MyISAM으로 변환하여야 한다.
InnoDB 레코드 잠금과 외래키를 가진 트랜잭션 안전 테이블. 14.2장 "InnoDB 저장 엔진" 부분을 참조 하라.
MEMORY 이 저장 엔진의 데이터는 메모리에 저장 된다. 14.4 장 "MEMORY(HEAP) 저장 엔진"부분을 참조 하라..
MyISAM 테이블들이 하나의 테이블로 사용된다. MRG_MyISAM으로 알려져 있다. 14.3장 "MERGE 저
MERGE
장 엔진"부분을 참조하라.
MySQL에 의해 사용되는 기본 저장 엔진으로 binary portable 엔진임. 14.1장 "MyISAM 저장 엔진"을

MyISAM
참조하라..
NDBCLUSTER 클러스터되고 무정지의 메모리 기반 테이블들. NDB로 알려짐. 15장 "MySQL Cluster"를 참조하라.

:::MySQL Korea:::
저장 엔진이 불가능 하다고 명시 되어 있다면 MySQL은 기본 엔진을 대신 사용한다. 예로서 한 테이블 정의가 ENGINE=BDB 옵
션을 포함하고 MySQL 서버가 BDB 테이블을 지원하지 않는다면 이 테이블은 MyISAM 테이블로 생성된다. 이는 마스터에 트랜잭
션 테이블을 가지고 있지만 slave로 생성된 테이블들은 비 트랜잭션적인(속도를 높이기 위해) 곳에서 치환 설정을 가능 하게 한
다. MySQL 5.0에서는 저장 엔진 지정이 불가능 한경우 경고를 발생 시킨다.
다른 테이블 옵션들은 테이블의 행위를 최적화 하기 위해 사용된다. 대부분의 경우 여러분은 그들의 일부를 지정해야 한다. 이들 옵
션들은 모든 저장 엔진에 적용 된다.
l AUTO_INCREMENT
테이블에서 AUTO_INCREMENT 값의 이니셜이다. MySQL 5.0에서 이것은 MyISAM과 MEMORY 테이블들로 작동한다. 이것
은 또한 MySQL 5.0.3에서 처럼 InnoDB를 위해 지원된다. AUTO_INCREMENT 테이블 옵션을 지원하지 않는 엔진들에 대해 자
동 증가 값을 설정 하기 위해서는 테이블 생성후 원하는 값보다 1적은 값으로 "dummy"레코드에 삽입 한 다음 그 "dummy"레코드
를 삭제 한다.
CREATE_TABLE문에서 AUTO_INCREMENT 테이블 옵션을 제공하는 엔진들에 대해 여러분은 AUTO_INCREMENT 값을

재 설정 하기 위해서 ALTER TABLE 테이블 이름 AUTO_INCREMENT = N 으로 설정 할 수 있다.
l AVG_ROW_LENGTH
테이블의 평균 레코드 길이의 근사값이다. 여러분은 가변 크기의 레코드들을 가진 큰 테이블들에 대해서만 설정 할 필요가 있다.
MyISAM 테이블을 생성 할때 MySQL은 결과 테이블이 얼마나 큰지를 결정하기 위해서 MAX_ROWS와 AVG_ROW_LENGTH옵
션의 결과를 사용한다. 여러분이 만약 어떤 옵션도 지정하지 않으면 테이블의 최대 크기는 65,536TB 이다 (MySQL 5.0.6 이전
버전에서는 4GB였다.). (만약 여러분의 운영 체제가 이정도 크기의 파일을 지원하지 않는다면 테이블 크기는 파일 크기 제약에 의
해 제한 받는다.) 여러분이 인덱스를 작게 하거나 빠르게 하고 싶고 실제 큰 파일이 필요하지 않다면 myisam_data_pointer_size
시스템 변수를 설정하여 기본 크기를 줄일 수 있다. 이것은 MySQL 4.1.2 버전에서 추가 되었다. (5.2.2.2장 "서버 시스템 변수"부
분을 참조하라). 여러분이 모든 테이블을 기본 제한 값보다 크게 만들고 약간 느려지게 하고자 한다면 이 값의 설저을 변경 하여 증
가 시킬 수 있다.

:::MySQL Korea:::
l [DEFAULT] CHARACTER SET
테이블의 기본 문자 모음(character set)을 지정한다. CHARSET은 CHARACTER SET과 동의어이다.
l COLLATE
테이블의 기본 정렬 방법을 지정한다.
l CHECKSUM
MySQL 모든 레코드들에 대해서 checksum을 유지 하고 싶다면 이것을 1로 설정하라(MySQL이 테이블이 변경되면 자동으로 업
데이트 한다.). 이것은 테이블의 업데이트를 다소 느리게 만들지만 깨진 테이블을 쉽게 찾도록 하기도 한다. CHECKSUM
TABLE 문은 checksum을 보고 한다.(MyISAM 만 해당)
l COMMENT
테이블의 주석으로 최대 60자까지 남길 수 있다.
l CONNECTION
FEDERATED 테이블을 위한 연결 문자열이다. 이 옵션은 MySQL 5.0.13부터 가능 하다. 그전에는 COMMENT 옵션을 사용한다.
l MAX_ROWS
테이블에 저장하려는 레코드의 최대 수이다. 이것은 고정된 제한 값이 아니라 테이블이 최소 이 정도의 레코드들 저장 할 수 있어
야 한다는 것을 지정하는 것이다.
l MIN_ROWS
테이블에 저장하려는 레코드의 최소 수이다.

:::MySQL Korea:::
l PACK_KEYS
PACK_KEYS은 MyISAM 테이블에서 효과를 지닌다. 작은 인덱스들을 원한다면 이 옵션을 1로 설정 하라. 이것은 보통 업데이트
를 느리게 하고 읽기를 빠르게 만든다. 옵션을 0으로 하면 키들의 모든 패킹(packing)을 불가능 하게 한다. 이 값을 DEFAULT로
하면 저장엔진이 CHAR나 VARCHAR 컬럼들만 동반 할 수 있다.
여러분이 PACK_KEYS를 사용하지 않으면 기본적으로 숫자가 아닌 문자열을 패킹한다. PACK_KEYS=1로 하면 숫자들로 pack
될 수 있다.
바이너리 숫자 키를 pack할때 MySQL은 prefix 압축을 사용한다.
l 모든 키는 이전 키의 얼마나 많은 byte들이 다음 키와 동일 할 것인지를 가리키는 하나의 byte를 필요로 한다.
l 레코드 포인터는 압축을 향상 시키기 위해 키 다음 바로 높은 byte가 먼저 오는 방식으로 저장된다.
이것은 여러분이 두개의 연속 적인 레코드에 많은 동일한 키들을 가지 있다면 모든 다음의 "same"키들은 단지 2바이트 만을 갖는
다(레코드에 대한 포인터 포함). 일반 적인 경우 키들은 각 키의 저장 크기 + 포인터 크기(포인터 크기는 4byte 이다) 를 갖는다.
여러분은 동일 한 값을 갖는 키가 많을 경우 prefix 압축으로 부터 많은 잇접을 얻게 된다. 만약 모든 키들이 다르다고 이때 그 key
가 NULL값을 갖지 않는다면, 여러분은 각 key당 1 byte를 더 사용한다.(이 경우 pack된 key 길이는 key가 NULL이면 표기 하는
데 사용되는 같은 byte에 저장 된다.)
l PASSWORD
.frm 파일을 password로 암호화한다. 이 옵션은 표준 MySQL 버전에서 동작 하지 않는다.
l DELAY_KEY_WRITE
테이블이 닫힐 때까지 테이블의 키 업데이트를 지연 시키려 할때 이를 1로 설정한다. 5.2.2장 "서버 시스템 변수"에서 지연 키 쓰
기 시스템 변수의 설명을 참조 하라.(MyISAM만 해당)

:::MySQL Korea:::
l ROW_FORMAT
레코드들이 어떻게 저장 되어야 하는지 정의한다. MyISAM 테이블에 대해 옵션 값은 고정 혹은 가변 길이 레코드 포맷에서

FIXED혹은 DYNAMIC 으로 될 수 있으며 myisampack은 그 형을 COMPRESSED로 설정 한다. 14.1.3 "MyISAM 테이블 저장
포맷"을 참조 하라.
InnoDB 테이블에 대해 MySQL 5.0.3에서 레코드들이 기본적으로 compact 포맷으로 저장 된다(ROW_FORMAT =

COMPACT). 이전 버전의 MySQL에서 사용된 비 compact 포맷은 ROW_FORMAT=REDUNDANT 로 지정하여 요구 되어질
수 있다.
l RAID_TYPE
RAID는 MySQL 5.0에서는 삭제 되었다. 홈페이지 http://dev.mysql.com/doc/refman/4.1/en/create-table.html를 참조하라.
l UNION
UNION은 여러분이 MyISAM테이블들을 모음을 접근 하려 할 대 사용된다. 이것은 단지 MERGE 테이블들에 대해서만 작동 한

다. 14.3장 "MERGE 저장 엔진" 부분을 참조 하라.
여러분은 테이블들을 하나의 MERGE 테이블로 매핑 하려면 SELECT, UPDATE, DELETE 권한을 가져야 한다. ( 주의 : 형식적
으로 모든 테이블은 MERGE 테이블과 같은 데이터베이스 안에 있어야 한다. 이 제약은 더이상 적용 되지 않는다)
l INSERT_METHOD
MERGE 테이블에 데이타를 삽입 하려면 레코드가 삽입될 테이블에 INSERT_METHOD를 명시 해야 한다. INSERT_METHOD
는 MERGE테이블에 대해서만 유용한 옵션이다. 테이블의 처음 이나 끝부분에 삽입을 하려면 FIRST나 LAST를 사용한다 NO의
값은 삽입을 못하게 한다. 자세한 사항은 14.3장 "MERGE 저장 엔진"부분을 참조 하라.
l DATA DIRECTORY, INDEX DIRECTORY
DATA DIRECTORY='디렉토리' 나 INDEX DIRECTORY='디렉토리'는 MyISAM 저장 엔진이 테이블의 데이타 파일이나 인덱

:::MySQL Korea:::
스 파일을 어디에 저장 할지를 지정한다. 디렉토리는 상대 경로가 아닌 절대 경로이어야 한다.
이들 옵션들은 여러분이 --skip-symbolic-links 옵션을 사용하지 않는한 적용된다. 여러분의 운영 시스템이 쓰레드 안전
realpath() 호출을 해야 한다. 자세한 사항은 7.6.1.2장 "Unix에서 테이블을 위한 Symbolic Links사용" 부분을 참조 하라.
CREATE TABLE문의 끝부분에 SELECT문을 추가 하여 다른 하나의 테이블을 생성 할 수 있다.
CREATE TABLE 새 테이블 SELECT * FROM 원본 테이블;
MySQL은 SELECT에서 모든 요소들의 신규 컬럼들을 생성 한다.

예:
mysql> CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,

-> PRIMARY KEY (a), KEY(b))
-> ENGINE=MyISAM SELECT b,c FROM test2;
이것은 새개의 컬럼 a,b와 c를 가지는 MyISAM 테이블을 생성하는 명령이다. 여기서 SELECT문에 있는 컬럼들은 테이블의 오른
쪽에 추가 되며 그것에 겹쳐지지 않는다. 다음과 같은 예를 보면;
mysql> SELECT * FROM foo;

+---+
|n|
+---+
|1|
+---+
mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;


:::MySQL Korea:::
mysql> SELECT * FROM bar;

+------+---+
|m |n|
+------+---+
| NULL | 1 |
+------+---+
테이블 foo의 각 레코드에 대해, foo 테이블로 부터의 값들과 새로운 컬럼들에 대한 기본값들로 이루어지는 하나의 레코드가 bar
테이블에 삽입 된다.
CREATE TABLE ... SELECT 결과로 테이블안에는 , CREATE TABLE부분에 명명된 커럼들이 우선한다. SELECT 컬럼s 의
데이타형은 CREATE TABLE 부분에서 그 컬럼을 지정 하여 바뀌어 질 수 있다.
데이타를 테이블에 복사하는 동안 에러가 발생하면 자동으로 삭제 하고 테이블은 생성 되지 않는다.
CREATE TABLE ... SELECT 은 자동으로 어떤 인덱스도 생성 하지 않는다. 이것은 의도적으로 그 문장을 유연하게 만들기 위
해 이루어지는 것이다. 여러분이 생성된 테이블에 인덱스를 지정하길 원한다면 SELECT문 이전에 이것들을 명시 하도록 한다.
mysql> CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;
데이타형의 변환도 발생 할 수 있다. 예를 들면 AUTO_INCREMENT 속성이 보존되지 않으면 VARCHAR 컬럼은 CHAR 컬럼이
될 수 있다.
CREATE...SELECT 문으로 테이블 생성시, 질의 에서 함수 호출에 대한 별칭 지정을 확실히 하도록 하라. 그렇지 않으면
CREATE 문은 올바르지 않은 컬럼 이름에 대해서 실패 할 수도 있다.
CREATE TABLE artists_and_works

SELECT artist.name, COUNT(work.artist_id) AS number_of_works
FROM artist LEFT JOIN work ON artist.id = work.artist_id
GROUP BY artist.id;

:::MySQL Korea:::
여러분은 또한 생성된 컬럼에 대한 데이타 타입을 명시적으로 지정 할 수 있다.
CREATE TABLE foo (a TINYINT NOT NULL) SELECT b+1 AS a FROM bar;
원본 테이블에서 정의된 컬럼 속성과 인덱스들을 포함 하는 다른 테이블의 정의를 기반으로 빈 테이블을 생성 하려면 LIKE를 사용
하도록 하라.
CREATE TABLE new_tbl LIKE orig_tbl;
CREATE TABLE ... LIKE은 원본 테이블에서 지정되었던 어떤 DATA DIRECTORY 나 INDEX DIRECTORY 테이블 옵션이
나 외래키 정의들을 유지 하지 않는다.
유일키 값이 중복되는 레코드를 어떻게 처리 할지 지시 하기 위해 IGNORE 와 REPLACE를 선행 시킬수 있다. IGNORE를 사용하
면 중복된 레코드는 삭제 된다. REPLACE를 사용하는 경우 새로운 레코드들은 같은 유일 키 값을 갖는 레코드로 대채 된다.
IGNORE 와 REPACE 모두 명시 하지 않으면 중복된 유일 키에 대해서 에러를 발생 하게 된다.
바이너리 로그가 원본 테이블들을 재생성 하는데 사용되도록 하기 위해, MySQL은 CREATE TABLE...SELECT에 동시 삽입을
허용하지 않는다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.5.1. Silent Column Specification Changes
13. SQL 문법(SQL Statement Syntax) 어떤 경우는, MySQL이 CREATE TABLE이나 ALTER TABLE문에서 컬럼 지정들을 암묵적으로 변경 하기도 하는데 데이타
13.1. 데이터정의 문 형, 속성, 데이타 형과 관련된 속성 혹은 인덱스 등이다.
13.1.5 CREATE TABLE

13.1.5.1 Silent Column Specification Changes 가능한 데이타 형 변경은 다음 리스트와 같다. 이것은 MySQL 5.0.3이전에 발생 한다. 5.0.3부터는 컬럼이 지정된 데이타타입을
사용하여 생성될 수 없으면 에러가 발생한다.
l 4보다 작은 길이의 VARCHAR 컬럼들은 CHAR로 변경된다.
l 테이블에 어떤 컬럼이 가변 길이를 갖는다면 전체 레코드는 가변 길이가 된다. 따라서, 한 테이블이 가변 길이 컬럼

(VARCHAR, TEXT 혹은 BLOB)를 포함 한다면 3자리 보다 긴 모든 CHAR 컬럼들은 VARCHAR 컬럼들로 변경 된다. 이것은 여
러분이 어떤방식으로 그 컬럼을 사용하지에 대해서는 영향을 미치지 않는다. MySQL에서 VARCHAR는 문자열들을 저장하기 위
한 다른 방법일 뿐이다. MySQL은 공간을 절약하고 테이블 연산을 빠르게 하기 때문에 이 변환을 수행한다. 이에 대한 자세한 내용
은 14장 "저장 엔진과 테이블 형" 부분을 참조하라.
l MySQL 5.0.3이전에 255보다 큰 길이를 갖는 CHAR 나 VARCHAR형 컬럼은 주어진 길이의 갑들을 가지는 가장 작
은 TEXT 형으로 변환된다. 예를 들면 VARCHAR(500)은 TEXT로 변환 되며 VARCHAR(200000)은 MEDIUMTEXT로 변환
된다. 이 변환은 저장 공간 을 고려하여 이루어 진다.
BINARY 와 VARBINARY형에 대해서도 이들이 BLOB형으로 변환 되는 경우를 제외 하고, 유사한 변환이 발생한다.
MySQL 5.0.3서 부터 255길이 보다 긴 CHAR 나 BINARY형 컬럼은 암묵적으로 변환 되지 않고 에러를 발생 시킨다. MySQL
5.0.6 부터는 SQL의 엄격 모드 하에서는 65,535보다 긴 길이의 VARCHAR 과 VARBINARY 형 컬럼의 암묵적인 변환은 발생
하지 않는다. 즉 에러를 발생 시킨다.

:::MySQL Korea:::
l DECIMAL(M,D) 명시에서, M이 D보다 크지 않으면 높은 것으로 조정된다. 예를 들면 DECIMAL(10,10)의 경우 차

이 가 없으므로 M을 증가 시켜 DECIMAL(11,10)이 된다.
다른 암묵적인 컬럼 지정 변경들은 속성이나 인덱스 지정에 대한 변경을 포함한다.
l TIMESTAMP 표시 크기가 제외 된다. TIMESTAMP 컬럼들이 최근 버전의 MySQL에서 상당히 변경 되었는데 이들

변화에 대한 설명은 3.23, 4.0, 4.1장을 참조 하라.
l PRIMARY KEY의 부분인 컬럼들은 그것들이 NOT NULL 처럼 선언 되었다 해도 NOT NULL로 만들어 지지 않는다.
l 테이블이 생성 될때 ENUM 과 SET 멤버 값들로 부터 trailing space들이 자동으로 삭제 된다.
l MySQL은 다른 SQL 데이타베이스 에서 사용되는 데이타 형을 MySQL의 데이타 형으로 매핑 시키기도 한다. 이에 관
한 내용은 11.7장 "다른 데이타베이스 의 데이타형 사용"부분을 참조 하라.
여러분이 주어진 저장 공간에 대해 알맞지 않은 인덱스 형을 지정하는 USING문을 포함 할 경우, 질의 결과에 영향을 주지 않는 다
른 인덱스 형이 있다면 ,데이타베이스는 그 유효 타입을 사용한다.
MySQL이 여러분이 지정한 것과 다른 데이타 형을 사용했는지 보기 위해서는 테이블 생성이나 테이블 변경 후, DESCRIBE 나
SHOW CREATE TABLE 문을 사용하라.
여러분이 myisampack을 사용하여 테이블을 압축 하면 다른 데이터형 변환이 일어 날수 있다. 이에 관한 내용은 14.1.3.3장 "압축
테이블 특성"부분을 참고하라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.6. DROP DATABASE
13. SQL 문법(SQL Statement Syntax) DROP {DATABASE | SCHEMA} [IF EXISTS] 데이타베이스 이름
13.1.6 DROP DATABASE DROP DATABASE 은 데이타베이스 안의 모든 테이블을 지우고 데이타베이스도 삭제 한다. 따라서 이를 이용할때는 매우 주의
를 하도록 해야 한다. DROP DATABASE를 사용하기 위해서는 이에 대한 권한을 가져야 한다. DROP SCHEMA는 DROP
DATABASE와 동의어이다.
IF EXISTS는 데이타베이스가 존재 하지 않는 경우 발생 하게되는 에러를 방지 하기 위해 사용한다.
상징적으로 연관된(symbolically linked)데이타베이스 에서 DROP DATABASE을 사용하면 그 링크와 원본 데이타베이스가 모

두 삭제 된다.
DROP DATABASE는 삭제된 테이블의 수를 리턴한다. 이것은 삭제된 .frm 파일의 수와 일치 한다.
DROP DATABASE 문은 MySQL이 정상 적인 운용 기간에 생성하게 되는 디렉토리와 그 안의 파일들을 지운다.
삭제 되는 파일들의 확장자는 다음과 같다.
.BAK .DAT .HSH
.MRG .MYD .ISD
.MYI .db .frm
두개의 16진수 00-ff로 이루어진 이름을 가진 모든 서브디렉토리들. 이들은 RAID 테이블들을 위해 사용되는 하부 디렉토리들이
다.(이들 디렉토리들은 RAID 테이블에 대한 지원이 삭제될때 MySQL 5.0에서 부터는 삭제 되지 않는다. 여러분은 MySQL 5.0으

:::MySQL Korea:::
로 업그레이드 하기전에 이들 디렉토리를 삭제 하고 RAID 테이블들을 변환 해야 한다. 2.10.2장 "MySQL 4.1에서 5.0으로의 업
그레이드" 를 참조 하라)
db.opt 파일 .
MySQL이 열거된 파일들을 삭제한 후 데이타베이스 디렉토리 안에 다른 파일과 디렉토리들이 존재 한다면 데이타베이스 디렉토리
는 삭제 될 수 없다. 이경우 여러분은 직접 해당 디렉토리와 파일들을 삭제 하고 DROP DATABASE 문을 다시 사용 하도록 해야
한다.
여러분은 mysqladmin으로 데이타베이스를 삭제 할 수 있다. 이에 대한 내용은 8.7장 "mysqladmin-MySQL 서버 관리 클라이언

트"를 참고 하라.
13.1.7. DROP INDEX

DROP INDEX 인덱스 이름 ON 테이블 이름
DROP INDEX는 테이블 이름에서 인덱스 이름으로 명시된 인덱스를 삭제 한다. 이 SQL문은 인덱스를 삭
제 하기 위해서 ALTER TABLE로 매핑된다. 이에 대한 내용은 13.1.2장 "ALTER TABLE"을 참고 하
라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.7. DROP INDEX
13.1. 데이터정의 문 DROP INDEX index_name ON tbl_name
13.1.7 DROP INDEX

DROP INDEX는 테이블 이름에서 인덱스 이름으로 명시된 인덱스를 삭제 한다. 이 SQL문은 인덱스를 삭제 하기 위해서 ALTER
TABLE로 매핑된다. 이에 대한 내용은 13.1.2장 "ALTER TABLE"을 참고 하라.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.8. DROP TABLE
13. SQL 문법(SQL Statement Syntax) DROP [TEMPORARY] TABLE [IF EXISTS]
tbl_name [, tbl_name] ...
13.1.8 DROP TABLE
[RESTRICT | CASCADE]
DROP TABLE문은 하나 혹은 그 이상의 테이블을 삭제 한다. 여러분은 각 테이블에 대한 DROP 권한을 가져야 한다. 모든 테이블 데
이타와 테이블 정의가 삭제 되므로 주의 해서 사용해야 한다.
존재 하지 않는 테이블을 삭제 하려 할때 발생 하게 되는 에러를 막기 위해 IF EXISTS문을 사용하라. NOTE는 IF EXISTS문을 사

용할때 존재하지 않는 테이블을에 대해 생성된다. 보다 자세한 사항은 13.5.4.25장 "SHOW WARKINGS"를 참조 하라
RESTRICT 과 CASCADE 는 porting을 쉽게 하기 위해 허용된다.
주의: DROP TABLE은 여러분이 TEMPORARY키워드를 사용하지 않는 이상 현재 활성화된 트랜잭션을 자동으로 위임(commit)한
다.
TEMPORARY키워드는 아래와 같은 효과를 가진다.
TEMPORARY 테이블만을 삭제 한다.
실행 중인 트랜잭션을 멈추지 않는다.

:::MySQL Korea:::
접근 권한이 체크 되지 않는다. (TEMPORARY테이블은 그것을 생성한 client에만 보이며, 어떤 check 도 필요하지 않다)
TEMPORARY의 사요은 여러분이 의도 하지 않게 비 TEMPORARY 테이블을 삭제 하는 것을 막을 수 있는 좋은 방법이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.1.9. RENAME TABLE
13. SQL 문법(SQL Statement Syntax) RENAME TABLE tbl_name TO new_tbl_name

13.1.9 RENAME TABLE [, tbl_name2 TO new_tbl_name2] ...
이 SQL문은 하나 혹은 그이상의 테이블의 이름을 새 이름으로 변경한다.
재 명명 연산은 방대하게 이루어 지기때문에 이 기간 동안 테이블에 대한 어떤 접근도 할 수 없다. 예를 들면 , 원본 테이블 이 있고

같은 구조를 갖지만 비어 있는 새 테이블 을 생성 할 수 있다. 그 다음 빈 테이블과 존재 하는 테이블을 다음과 같이 교체 한다
( back up 테이블이 존재 하지 않는 다고 가정하자.)
CREATE TABLE new_table (...);
RENAME TABLE old_table TO backup_table, new_table TO old_table;
이 SQL문이 하나이상의 테이블을 재명명 하면 새이름변경 연산은 왼쪽에서 오른쪽으로 진행 된다. 여러분이 두개의 테이블을 교
환 하려면 다음과 같이 할 수 있다(임시 테이블이 존재 하지 않는다고 가정한다.).
RENAME TABLE old_table TO tmp_table,
new_table TO old_table,

:::MySQL Korea:::
tmp_table TO new_table;
두 데이타베이스가 같은 파일 시스템에 있는동안에는 여러분은 한 데이타베이스에서 다른 쪽으로 테이블을 옮기려 할때

RENAME TABLE을 사용 할 수 있다.
RENAME TABLE current_db.tbl_name TO other_db.tbl_name;
MySQL 5.0.14에서 부터는 RENAME TABLE을 다른 테이타베이스로 재명명 하려 하지 않는 이상, 뷰에 대해서도 사용 가능 하

다.
여러분이 RENAME을 실행 시키면 어떤 잠긴 테이블이나 활성화된 트랜잭션을 가질 수 없다. 새 테이블에 대한 CREATE와

INSERT 권한 과 원본 테이블에 대한 ALTER와 DROP 권한 을 가져야 한다.
MySQL 다수 테이블 재명명에서 에러를 발생 시키면 이름이 바뀐 테이블들을 다시 원래 이름의 테이블들로 바꾸어 놓는다.

:::MySQL Korea:::
제목검색
13. SQL 문법(SQL Statement Syntax) 13.2.1. DELETE
13.2. 데이터 조작 SQL문 13.2.2. DO
13.2 데이터 조작 SQL문 13.2.3. HANDLER

13.2.4. INSERT
13.2.1 DELETE 문
13.2.5. LOAD DATA INFILE
13.2.2 DO
13.2.6. REPLACE
13.2.3 HANDLER
13.2.7. SELECT
13.2.4 INSERT
13.2.8. 서브쿼리 신텍스
13.2.4.1 INSERT ..
13.2.9. TRUNCATE
13.2.10. UPDATE
13.2.4.3 INSERT ..
13.2.6 REPLACE .......................................................................................................
13.2.7 SELECT
13.2.7.1 JOIN Syntax
13.2.7.2 UNION
13.2.8 서브쿼리
13.2.8.5 로우 서브쿼리
13.2.8.6 EXISTS and NOT EXISTS

:::MySQL Korea:::
13.2.8.7 서로 관련된 서브쿼리들

13.2.8.8 FROM 절 안에서의 서브쿼리들
13.2.8.9 서브쿼리 에러
13.2.8.10 서브쿼리 최적화
13.2.8.11 MySQL 초기버전 용 Joins로써의 리라
이팅 서브쿼리들
13.2.9 TRUNCATE
13.2.10 UPDATE

:::MySQL Korea:::
제목검색
13.2.1. DELETE 문
13. SQL 문법(SQL Statement Syntax) 단일 테이블:

13.2.1 DELETE 문
DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROM tbl_name
[WHERE where_condition]
[ORDER BY ...]
[LIMIT row_count]
다수 테이블:
DELETE [LOW_PRIORITY] [QUICK] [IGNORE]
tbl_name[.*] [, tbl_name[.*]] ...
FROM table_references
또는:

:::MySQL Korea:::
DELETE [LOW_PRIORITY] [QUICK] [IGNORE]
FROM tbl_name[.*] [, tbl_name[.*]] ...
USING table_references
단일 테이블문은 DELETE문이 테이블 이름에서 레코드들을 삭제 하고 삭제된 레코드의 수를 리턴한다. WHERE절이 없는 경우

모든 레코드가 삭제 된다. ORDER BY절이 지정되면 레코드들이 지정된 순서대로 삭제 된다. LIMIT절은 삭제될수 있는 레코드의
수에 제한을 둔다.
다수 테이블문은 DELETE가 조건을 만족하는 각 테이블의 레코드들을 삭제 한다. 이경우 ORDER BY와 LIMIT는 사용할 수 없
다.
where 조건은 각각의 레코드가 삭제 되어 할 지 평가 하는 문이다. 상세한 내용은 13.2.7 장 "SELECT"부분을 참조 하라.
WHERE절이 없는 DELETE문은 모든 레코드들을 지운다. 이를 좀더 빨리 하기 위해서 삭제 되는 레코드 수를 알 필요가 없을 경

우 TUNCATE TABLE을 사용하라. 이에 대한 사항은 13.2.9장 "TRUNCATE"를 참조 하라.
AUTO_INCREMENT 컬럼에 대한 최대 값을 가진 레코드를 삭제하는 경우, 이 값은 BDB 테이블에서 재 사용되는데 MyISAM이

나 InnoDB 테이블에 대해서는 예외 이다. AUTOCOMMINT 모드에서 DELETE FROM 테이블 이름 (WHERE 절이 포함되지 않
음)문으로 테이블의 모든 레코드를 지우려 할때는 일련 번호가 InnoDB와 MyISAM을 제외한 모든 엔진에서 시작된다. InnoDB테
이블에 대해서는 몇가지 예외가 있으면 이에 대한 사항은 14.2.6.3장 "InnoDB에서 AUTO_INCREMENT 컬럼의 동작 방법" 부분
에서 다룬다.
MyISAM 과 BDB테이블에 대해서는 다수 컬럼 키안에서 AUTO_INCREMENT 속성의 두번째 컬럼을 지정 할 수 있다. 이 경우

일련번호의 맨 처음에서 삭제된 값의 재 사용이 MyISAM테이블에 대해서도 발생 한다. 3.6.9장 "AUTO_INCREMENT"부분을 참

:::MySQL Korea:::
조 하라.
DELETE문은 다음과 같은 제한자들을 지원한다.
여러분이 LOW_PRIORITY로 지정 하는경우 서버는 클라이언트가 테이블에서 더이상 읽지 않을때까지 DELET의 실행을 지연시
킨다.
MyISAM테이들의 경우 QUICK 키워드를 사용하면 저장 엔진은 삭제 기간동안 인덱스 가지들을 병합하지 않는데 이것은 몇몇 삭
제 작업시 속도를 향상 시킨다.
IGNORE키워드는 MySQL로 하여금 레코드의 삭제 기간중에 모든 에러를 무시 하도록 한다. (분석 기간중에 발생 하는 에러들은
일반 적인 방법에 따라 처리 된다) OPTION의 사용으로 인해 무시 되는 에러들은 경고로 리턴된다.
삭제 작업의 속도는 7.2.18장 "DELETE문의 속도"부분에서 설명되는 요인들에 의해 영향을 받는다.
MyISAM 테이블들에서는 삭제된 레코드들은 linked list로 유지 되며 연속적인 INSERT 연산들은 옛 레코드 위치를 재 사용한
다. 사용되지 않는 공간의 반환과 파일 크기를 줄이기 위해서는 OPTIMIZE TABLE문을 사용하거나 테이블들을 재 구성하는
myisamchk 유틸리티를 사용하라. OPTIMIZE TABLE이 쉽지만 myisamchk는 빠르다. 13.5.2.5장 "OPTIMIZE TABLE"과 8.2
장 "myisamchk-MyISAM 테이블 유지 보수 유틸리티"부분을 참조 하라.
QUICK modifier는 index leaf들이 삭제 작업을 위해 병합 되는데 영향을 미친디ㅏ. DELETE QUICK은 삭제된 레코드의 인덱스
값들이 후에 삽입되는 레코드의 유사한 인덱스 값들로 대체 되도록 하는데 가장 유요한 방법이다.
DELETE QUICK는 삭제된 값들이 새로운 삽입이 발생 할때 인덱스 값들의 범위를 조사하는 undef_filled 인덱스 블럭에 이르는
경우에는 유용하지 않다. 이 경우 QUICK의 사용은 반환되지 않고 있는 인덱스 안의 낭비되는 공간을 야기 시킬수 있다. 아래는 그
러한 시나리오의 예이다.
1. 하나의 인덱스된 AUTO_INCREMENT 컬럼을 갖는 테이블을 생성 한다.
2. 테이블에 많은 레코드를 삽입한다. 각 삽입 결과는 인덱스의 값이 증가 한다.

:::MySQL Korea:::
3. DELETE QUICK을 사용하여 컬럼 범위의 레코드 끝에 위치한 레코드 블럭을 삭제 한다.
이 시나리오에서는 삭제된 인덱스 값들과 연관된 인덱스 블럭이 undef-filled 상태가 되나 QUICK의 사용으로 다른 인덱스 블럭
과 병합 되지 않는다. 그들은 새로운 레코드는 삭제된 범위 안에 속한 인덱스 값을 가지고 있지 않으므로 새로운 삽입이 발생할때까
지 undef-filled상태를 유지한다. 더 나가 그것들은 여러분이 추후 QUICK없이 DELET를 사용할때에도 삭제된 인덱스값들중 일
부가 undef-filled 블럭과 인접한 경우가 발생하기 전에는 undef-filled 상태를 유지한다. 이러한 환경에서 사용되지 않는 인덱스
공간을 해제 하기 위해서는 OPTIMIZE TABLE을 사용하라.
여러분이 테이블에서 많은 수의 레코드를 삭제 하려 하면 OPTIMIZE TABLE뒤에 DELETE QUICK명렬을 사용하면 더 빠르다.

이것은 많은 수의 인덱스 블럭을 병합 하기 보다 새로이 만든다.
DELTE문에서 MySQL 고유 절인 LIMIT 레코드 수 는 클라이언트에게 되돌아 가기전에 삭제될 최대 레코드 수를 서버에게 말해
준다. 이것은 주어진 DELETE문이 많은 시간을 소비하지 않도록 하기 위해 사용될 수 있다. 여러분은 단지 영향을 받는 레코드의
수가 LIMINT 의 값보다 작을 때까지 DELETE문을 반복할 수 있다.
DELTE문이 ORDER BY절을 포함하면 그 절에서 지정된 순서대로 레코드가 삭제된다. LIMIT와 함께 쓰이면 유용하다. 예를 들
면, 다음 문장은 WHERE절에 의해 일치 하는 레코드를 찾고 timestamp_column의 순서대로 정렬을 하여 첫번째 레코드를 삭제
한다.
DELETE FROM somelog WHERE user = 'jcole'

ORDER BY timestamp_column LIMIT 1;
WHERE절에서 특정 조건에 따라 하나 혹은 그 이상의 테이블로부터 레코드를 삭제 하는데 DELETE문에서 여러 테이블을 지정

할 수 있다. 그러나 다수 테이블 DELETE문 내에서 ORDER BY나 LIMIT를 사용할 수 없다. 테이블 참조절은 join과 관련된 테이
블을 나열한다. 이 문법은 13.2.7.1장 "JOIN"부분을 참조 하라.
처음 다수 테이블 문에서, FROM 절 이전에 나열된 테이블들로부터 일치하는 레코드들이 삭제 된다. 두번째 다수 테이블 문에서
FROM 절 안(USING 절 이전)에 나열된 테이블들에서 일치하는 레코드를 삭제 한다. 이 효과는 여러분이 동시에 여러 테이블에서
레코드를 삭제 할수 있으며 검색을 위해서만 사용되는 추가적인 테이블을 가진다는 것이다.

:::MySQL Korea:::
DELETE t1, t2 FROM t1, t2, t3 WHERE t1.id=t2.id AND t2.id=t3.id;
또는:
DELETE FROM t1, t2 USING t1, t2, t3 WHERE t1.id=t2.id AND t2.id=t3.id;
이 SQL문들은 삭제할 레코드를 찾기 위해서 세개의 테이블을 사용하지만 테이블 1과 2에 대해서면 일치하는 레코드를 삭제 한다.
위의 예는 콤마 연산자를 사용하는 inner join을 보여준다. 그러나 다수 테이블 DELETE문은 LEFT JOIN과 같이 SELECT문에
서 허용되는 join형만 사용할 수 있다.
문법은 Access와의 호환성을 위해 테이블 이름 뒤에 .*를 허용한다.
여러분이 외래키 제약 사항에 대해 InnoDB테이블을 연관짓는 다수 테이블 DELETE문을 사용할 경우, MySQL 최적화기는 그들
간의 부모/자식관계 의 그것과는 차이가 있는 순서로 테이블을 처리 한다. 이 경우, SQL문은 실패 하고 roll back된다. 대신 다른
테이블들이 자연스럽게 변경 되도록 하려면 여러분은 하나의 테이블에서 지우고 InnoDB가 제공하는 ON DELETE문의 능력에 의
존 해야 한다.
주의 : 한 테이블에 대한 별칭을 제공하면 그 테이블을 참조 할 때 그 별명을 사용해야 한다.
DELETE t1 FROM test AS t1, test2 WHERE ...
교차 데이타베이스 삭제는 다수 테이블 삭제를 위해 제공 되며 이 경우, 여러분은 alias없이 테이블을 참조 해야 한다. 예를 들면;
DELETE test1.tmp1, test2.tmp2 FROM test1.tmp1, test2.tmp2 WHERE ...
현재는 테이블에서 삭제도 부 질의 에서 같은 테이블에서 선택도 할 수 없다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.2. DO
13.2. 데이터 조작 SQL문 DO expr [, expr] ...
13.2.2 DO
DO는 뒤의 expression을 실행 하지만 결과를 리턴하지 않는다. 모든 면에서 DO는 SELECT expr, ..., 문의 편법이지만 여러분이
결과를 신경 쓰지 않아도 된다는 점에서 다소 빠른 잇점을 지니고 있다. DO문은 어떤 에러도 보고 하지 않고 경고로써 에러를 보
고 한다.
DO는 RELEASE_LOCK()와 같이 의외 상황을 갖는 함수들에서 유용하다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.2. HANDLER
13. SQL 문법(SQL Statement Syntax) DO expr [, expr] ...

13.2.3 HANDLER
DO는 뒤의 expression을 실행 하지만 결과를 리턴하지 않는다. 모든 면에서 DO는 SELECT expr, ..., 문의 편법이지만 여러분이
결과를 신경 쓰지 않아도 된다는 점에서 다소 빠른 잇점을 지니고 있다. DO문은 어떤 에러도 보고 하지 않고 경고로써 에러를 보
고 한다.
DO는 RELEASE_LOCK()와 같이 의외 상황을 갖는 함수들에서 유용하다.
13.2.3. HANDLER
HANDLER tbl_name OPEN [ AS alias ]
HANDLER tbl_name READ index_name { = | >= | <= | < } (value1,value2,...)
[ WHERE where_condition ] [LIMIT ... ]
HANDLER tbl_name READ index_name { FIRST | NEXT | PREV | LAST }
HANDLER tbl_name READ { FIRST | NEXT }

:::MySQL Korea:::
HANDLER tbl_name CLOSE
HANDLER문은 테이블 저장 엔진 인터페이스에 대한 직접 접근을 제공한다. 이는 MyISAM과 InnoDBtable에서 가능하다.
HANDLER ... OPEN문이 테이블을 open하고 뒤의 HANDLER...READ문을 이용하여 접근 할수 있게 한다. 이 테이블 객체는 다
른 쓰레드들에 의해 공유되며 그 쓰레드가 HANDLER ... CLOSE를 호출 하거나 쓰레드가 종료되기 전에 close하지 않는다. alias
를 이용하여 테이블을 open한 경우 그 테이블에 대한 참조 하기 위해 HANDLER문을 쓰는 경우 alias를 대신 써야 한다.
첫번째 HANDLER ... READ문은 인덱스가 주어진 조건을 만족하거나 WHERE조건 과 일치 하는 경우 레코드를 가져온다. 여러분
이 다수 컬럼 인덱스를 가진 경우 콤마로 인덱스 컬럼들의 값을 명시 하도록 해야 한다. 인덱스의 모든 컬럼에 대한 값을명시 하거
나 인덱스 컬럼들의 가장 좌측의 prefix에 대한 값을 명시 하라. 예를 들면 my_idx라는 인덱스가 col_a, col_b, col_c의 컬럼 들을
포함 한 경우 HANDLER 문은 인덱스에 세개의 컬럼들의 값을 명시 하거나 가장 좌측의 prefix에 있는 컬럼 명시 할 수있다.
HANDLER ... READ my_idx = (col_a_val,col_b_val,col_c_val) ...
HANDLER ... READ my_idx = (col_a_val,col_b_val) ...
HANDLER ... READ my_idx = (col_a_val) ...
HANDLER 문에서 테이블을 PRIMARY KEY를 참조할 경우 'PRIMARY'로 명시 하라.
HANDLER tbl_name READ `PRIMARY` ...
두번째 HANDLER ... READ문은 WHERE 조건과 일치 하는 한 레코드에 대해 인덱스 순서대로 가져 온다.
세번째 HANDLER ... READ문은 WHERE조건을 만족하는 한 레코드를 원래 순서대로 가져 오게 된다. 전체 테이블 스캔을 할때

:::MySQL Korea:::
HANDLER 테이블 이름 READ 인덱스 이름 을 사용하는 것 보다 빠르다. 자연적인 레코드 순서서 레코드들이 MyISAM 테이블 데
이타 파일에 저장된 순서이다. 이 문은 InnoDB테이블에 대해서도 쓸수 있으나 분리된 데이타 바일이 없으므로 그러한 개념은 존
재 하지 않는다.
LIMIT절 없이 모든 형식의 HANDLER ... READ문은 하나의 레코드만 가져 온다. 레코드의 수를 되돌려 주기 위해서는 LIMIT절
을 포함 하라. 이것은 SELECT문과 같다. 이에 대한 사항은 13.2.7장 "SELECT"를 참조 하라.
HANDLER ... CLOSE 문은 HANDLER ... OPEN으로 열려진 테이블을 닫는다.
HANDLER는 다소 low 레벨의 문자이다. 예를 들면, 그것은 일관성을 제공하지 않는다. 즉 HANDLER ... OPEN은 테이블의 단편
을 갖거나 테이블을 자그지 않는다. 이는 HANDLER ... OPEN문후 테이블 데이타가 변경 될수 있으며 이들 변경은 HANDLER ...
NEXT 혹은 HANDLER ... PREV 스캔에서 일부 볼수 있다.
보통 SELECT문 대신 HANDLER 인터페이스를 쓰는 몇가지 이유가 있다.
l HANDLER가 SELECT보다 빠르다.
l 지정된 저장 엔진 handler 객체는 HANDLER ... OPEN을 위해 할당 된다. 이 객체는 그 테이블을 위해 다음

HANDLER 문을 위해 재 사용된다. 이것은 각각을 위해 초기화 될 필요가 없다.
l 적은 분석이 사용된다.
l 최적화기 와 질의 검사 오버 헤드가 없다.
l 테이블은 두개의 핸들러 요구사이를 잠글 필요가 없다.
l handler인터페이스는 데이타의 일관된 모양을 제공할 필요가없다. (예를 들면 dirty 읽기가 허락된다) 따라서 저
장 엔진은 SELECT가 허용하지 않는 최적화를 사용할 수 있다.
l 하위 수준의 ISAM 인터페이스를 사용하는 응용프로그램에 대해 HANDLER는 MySQL로 전환 하는데 쉽게 한다.

:::MySQL Korea:::
l HANDLER는 SELECT를 사용해서는 완수 하기 어려운 방식으로 데이타 베이스를 운용 할 수 있다. HANDLER 인터

페이스는 데이타베이스에 interactive한 사용자 인터페이스를 제공하는 응용 프로그램과 함께 작동 할때에 데이타를 보는 보다 자
연스런 방법이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.4. INSERT
13. SQL 문법(SQL Statement Syntax) 13.2.4.1. INSERT ... SELECT

13.2. 데이터 조작 SQL문 13.2.4.2. INSERT DELAYED
13.2.4 INSERT 13.2.4.3. INSERT ... ON DUPLICATE KEY UPDATE
13.2.4.1 INSERT ..
INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
13.2.4.3 INSERT ..
[INTO] tbl_name [(col_name,...)]
VALUES ({expr | DEFAULT},...),(...),...
[ ON DUPLICATE KEY UPDATE col_name=expr, ... ]
Or:
INSERT [LOW_PRIORITY | DELAYED | HIGH_PRIORITY] [IGNORE]
[INTO] tbl_name
SET col_name={expr | DEFAULT}, ...
Or:
INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]

:::MySQL Korea:::
SELECT ...
INSERT문은 존재하는 테이블에 새로운 레코드를 삽입 한다. INSERT ... VALUES 과 INSERT ... SET 문은 명시적으로 지정된
값들을 기반으로 레코드를 삽입 한다. INSERT ... SELECT문은 다릍 테이블이나 테이블들 에서 선택된 레코드를 삽입한다.
INSERT ... SELECT문은 13.2.4.1 "INSERT... SELECT"부분을 참조 하라.
기존 레코드를 덮으쓰기 위해서는 INSERT가 아닌 REPLACE문을 사용할 수 있다. REPLACE는 유일키가 같은 중복 레코드를 새
로운 레코드로 처리 하는점에서 INSERT IGNORE와 대응 된다. 새로운 레코드들은 오래된 레코드를 대체 한다.이에 대한 자세한
사항은 13.2.6 "REPLACE"부분을 참조 하라.
테이블 이름 은 레코드가 삽입될 테이블이다. 이 SQL문이 제공하는 컬럼 값들은 다음과 같다.
테이블 뒤에 콤마로 구분 되는 컬럼 이름들을 나열 한다. 이 경우 각 컬럼에 대한 값은 SELECT 혹은 VALUE 리스트에 의해 제공

되어야 한다.
INSERT ... VALUES 나 INSERT ...SELECT 문에서 컬럼 이름들을 지정하지 않으면 테이블안의 모든 컬럼 값은 VALUE 리스
트나 SELECT 문에 의 해 제공 되어야 한다. 만약 여러분이 테이블의 컬럼 순서를 모르는 경우 DESCRIBE 테이블 이름을 사용하
라.
SET절은 명시적으로 컬럼 이름을 지정한다.
컬럼 값들은 몇가지 다음 방식으로 주어 질 수 있다.
엄격한 SQL 모드 에서 실행 할 경우, 값이 주어지지 않은 컬럼은 기본 값(암시적 혹은 명시적으로)으로 설정 된다. 예를 들면, 여러

분이 테이블안의 모든 컬럼이름을 지정 하지 않았다면 이름이 없는 컬럼들은 기본 값으로 설정된다. 설정되는 기본 값은 11.1.4장

:::MySQL Korea:::
"Data 형 기본 값들" 과 1.9.6.2장 "유효 데이타의 제약 사항"부분을 참조 하라.
여러분이 기본 값을 갖지 않는 모든 컬럼들에 대해서 명시적으로 값을 지정하지 않을 경우 에러를 발생 하게 하기 위해 INSERT문

을 쓰고자 한다면, strict mode에서 사용해야 한다. 5.2.5장 "서버 SQL 모드"부분을 참조 하라.
기본 값을 명시적으로 설정하기 위해서는 DEFAULT를 사용하라. 이 키워드는 테이블 안의 각 컬럼에 대해 값을 포함 하지 않는

불완전한 VALUES 리스트 문의 사용을 피할 수 있으므로 몇개의 컬럼을 제외한 모든 컬럼에 대해 값을 할당 하는 INSERT문을 쓰
기 쉽게 해준다. 이 키워드를 사용하지 않을경우 컬럼 이름들과 그에 따르는 각 값들을 VALUES 리스트안에 명시 해야만 한다.
주어진 컬럼의 기본 값을 생성 하기 위한 좀더 일반 적인 형태로 DEFAULT (컬럼 이름) 을 사용하라.
컬럼 리스트와 VALUES 리스트가 모두 빈 경우, INSERT는 각 컬럼을 기본 값으로 설정 하여 생성 한다.
INSERT INTO tbl_name () VALUES();
엄격 모드(strict mode)에서는 컬럼이 기본 값을 가지 않을 경우 에러를 발생 시킨다. 그렇지 않으면 MySQL은 명시적으로 정의

된 기본값을 갖지 안흔 컬럼에 대해서 암시적 기본값을 사용한다.
컬럼 값을 제공하기 위해서 정규식 expr을 지정 할 수 있다. 이는 정규 식의 형이 컬럼의 형과 일치 하지 않을경우 형 변환을 포함

할 수 있고 주어진 값의 변환은 데이타 형에 따라 다른 삽입 값이 될 수도 있다. 예를 들면 문자열 '1999.0e-2'는 INT,FLOT,
DECIMAL(10,6)이나 YEAR 컬럼에 1999, 19.9921, 19.992100 그리고 1999로 각각 삽입 된다. INT와 YEAR컬럼안에 저장
된 값이 1999가 된 이유는 string-to-integer변환이 문자열의 첫 부분을 유효한 integer나 year로 판단 되기 때문이다. 유동 소
수점(floating-point) 과 부동 소수점(fixed-point) 컬럼들에 대해, string-to-floating-point 변환 전체 문자열을 유효 유동 소
숫점 값으로 인식 한다.
정규식 exprdms value 리스트에서 이미 설정된 컬럼을 참조 할 수 있다. 예를 들면 컬럼 col2가 col1을 참조 하는데 이는 그 전에
할당 된것이다.
INSERT INTO tbl_name (col1,col2) VALUES(15,col1*2);

:::MySQL Korea:::
그러나 다음 식은 col1이 col2를 참조 하여 col1이후에 할당 되었으므로 맞지 않다.
INSERT INTO tbl_name (col1,col2) VALUES(col2*2,15);
한가지 예외는 AUTO_INCREMENT 값들을 가진 컬럼을 포함 한다. AUTO_INCREMENT값은 다른 값들이 할당 된 후에 생성

되기 빼문에 AUTO_INCREMENT 컬럼에 대한 참조는 0을 리턴한다.
VALUES문을 사용하는 INSERT문은 다수 레코드를 삽입 할 수 있다. 이를 위해, 다수 컬럼 값 리스트를 포함 하고 각각은 괄호 안

에 콤마로 구분되어서 존재 한다. 예를 들면
INSERT INTO tbl_name (a,b,c) VALUES(1,2,3),(4,5,6),(7,8,9);
각 레코드에 대한 값 리스트는 괄호로 묶여야 된다. 다음 SQL문은 리스트의 값들의 수가 컬럼 이름의 수와 맞지 않으므로 올바르
지 않다.
INSERT INTO tbl_name (a,b,c) VALUES(1,2,3,4,5,6,7,8,9);
INSERT문에 의해 영향을 받은 레코드들은 C API 함수인 mysql_affedted_rows()를 사용하여 얻어 질 수 있다. 이에 대한 사항

은 22.2.3.1장 "mysql_affected_rows()"부분을 참조 하라.
여러분이 다수 값 리스트와 INSERT ... VALUES를 사용하거나 INSERT ...SELECT문을 사용하면, 이 SQL문은 아래 포맷 대로
정보 문자열을 리턴한다.

:::MySQL Korea:::
Records 는 SQL문에 의해 처리된 레코드의 수를 의미한다. (이는 Duplicates가 0이 아닐 수 있기 때문에 실제로 삽입된 레코드
수일 필요는 없다)Duplicates 는 레코드들이 다른 레코드들과 유일 키 값에 의해 중복 되므로 삽입 될수 없는 레코드의 수를 의미
한다. Warnings는 문제가 될 수 있는 식으로 컬럼 값들을 삽입 하려 한 시도 횟수를 의미한다. Warnings는 다음 아래 조건들에서
일어 날 수 있다.
NOT NULL로 선언된 컬럼에 NULL을 삽입 하는 경우. 다수 레코드 삽입 SQL문 이나 INSERT INTO ... SELECT 문에 대해, 컬
럼의 암시적인 기본 값을 설정한다. 이것은 숫자 형에는 0을, string 형에는 빈 문자열(''), 그리고 date와 time 형에는 "zero"값이
할당 된다. INSERT INTO... SELECT SQL문은 서버가 결과가 하나의 레코드만을 리턴하는지 보기 위해 SELECT에서 결과를
검사 하지 않으므로 다수 레코드 삽입에서와 같은 방식으로 처리 된다. (단일 레코드 INSERT 문에 대해, NULL이 NOT NULL 컬
럼에 삽입 되면 warning이 발생 하지 않고 에러와 함께 실패 하게 된다.)
컬럼 범위 밖에 있는 값을 숫자 컬럼으로 설정. 값이 범위의 가장 가까운 끝 부분에 고정 된다.
숫자 컬럼에 '10.34 a'과 같은 할당. 숫자가 아닌 텍스는 삭제 되고 남은 숫자 부분만 삽입된다. 문자열 값이 숫자 부분이 없을 경우
에는 0으로 설정된다.
컬럼의 최대 길이를 초과하는 문자열 컬럼(CHAR, VARCHAR, TEXT , 혹은 BLOB)에 문자열 삽입. 값은 컬럼의 최대 길이에서
잘린다.
data 형에서 올바른 date나 time 컬럼에 값 삽입인 경우. 그 컬럼은 그 형에 적당한 zero 값으로 설정된다.
C API 함수를 이용할 경우, mysql_info() 함수를 사용하여 정보 문자열을 얻을 수 잇다. 이에 대한 사항은 22.2.3.34장
"mysql_info()"부분을 참조 하라.
INSERT 문이 AUTO_INCREMENT컬럼을 가진 테이블에 한 레코드를 삽입하면 LAST_INSERT_ID() SQL 함수를 사용하여 컬

럼에 할당된 값을 찾을 수 있다. C API 함수인 mysql_insert_id()함수를 사용하라. 그러나 두개의 함수가 항상 동일하게 행동하지
않는 다는 것을 유념해야 한다. AUTO_INCREMENT 컬럼
을 포함한 INSERT 문의 동작은 12.9.3wkd "정보 함수"부분과 22.2.3.36장 "mysql_insert_id()"부분에서 상세히 설명된다.
INSERT 문은 다음과 같은 modifier를 지원한다.

:::MySQL Korea:::
DELAYED키워드를 사용하면 서버는 레코드들을 버퍼 안에 삽입되게 하고, INSERT DELAYED문을 사용한 클라이언트는 즉시
다음일을 계속 할 수 있다. 테이블이 사용중이면 서버는 레코드들을 보관 한다. 테이블이 사용상태가 아니면 서버는 삽입 작업을 시
작하는데 테이블에 대한 새로운 읽기 요청이 있는지를 정기적으로 체크한다. 만약 이럴 경우, 지연된 레코드 큐는 테이블이 다시
비 사용 상태가 될 때까지 중지 상태가 된다. 이에 대한 자세한 사항은 13.2.4.2장 "INSERT DELAYED"를 참조 하라.
DELAYED는 INSERT ... SELECT 나 INSERT ... ON DUPLICATE KEY UPDATE에서 무시 된다.
LOW_PRIORITY 키워드를 사용하면, INSERT문의 실행은 다른 클라이언트들이 테이블에서 읽지않을 때까지 지연된다. 클라이언
트들이 읽는 중간 그리고 INSERT LOW PRIORITY문이 기다리는 동안 읽기를 시작한 다른 클라이언트도 포함한다. 오랜 시간
동안 기다리기 위해 INSERT LOW_ PRIORITY문을 사용하는 것이 가능하다. (이것은 INSERT DELAYED와 대조적인데 , 이
SQL문은 클라이언트가 동시에 계속 하게 한다. LOW_PRIORITY가 MyISAM ㅌ;이블과 함께 사용될수 없다. 이는 동시적인 삽입
을 불가능 하게 하기때문이다. 이에 대한 내용은 7.3.3장 "동시적인 삽입(concurrent insert)"부분을 참조 하라.
HIGH_PRIORITY를 명시 하는 경우 서버가 이 옵션으로 시작 했다면 low-priority 업데이트의 효과를 뒤엎는다. 이것은 동시적
인 삽입이 사용되지 못하게 한다.
IGNORE 키워드 사용시 INSERT문을 처리 하는 동안 발생하는 에러들은 warning으로 처리 된다. 예를 들면, IGNORE 없이
UNIQUE 혹은 PRIMARY KEY 값으로 중복 되는 레코드는 중복 키 에러를 발생 시키고 그 문장은 취소 된다. IGNORE을 써도 그
레코드는 삽입 이 안되는데 이때 에러는 발생 되지 않는다. 에러를 유발 시키는 데이터 변환은 IGNORE가 명시 되지 않으면 취소
된다. IGNORE가 있으면 잘못된 값들은 근사 값들로 대치 되고삽입 된다. warning이 발생 하지만 그 SQL문이 취소 되지는 않는
다. 여러분은 얼마나 많은 레코드들이 테이블에 실제 삽입 되었는지 보기 위해 C API 함수인 mysql_info()함수로 결정 할 수 있다.
ON DUPLICATE KEY UPDATE를 명시 하면 UNIQUE 인덱스나 PRIMARY KEY에서 중복을 유발할 레코드가 삽입 되고 예전
레코드의 UPDATE가 수행 된다. 이에 대한 사항은 13.2.4.3장 "INSERT ... ON DUPLICATE KEY UPDATE" 부분을 참조 하
라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.4.1. INSERT ... SELECT
13.2. 데이터 조작 SQL문 INSERT [LOW_PRIORITY | HIGH_PRIORITY] [IGNORE]
13.2.4 INSERT
13.2.4.1 INSERT ..
SELECT ...
13.2.4.3 INSERT ..
INSERT ... SELECT 문에서 하나 혹은 그 이상의 테이블로 부터 많은 레코드들을 빠르게 삽입 할 수 있다.
INSERT INTO tbl_temp2 (fld_id)
SELECT tbl_temp1.fld_order_id
FROM tbl_temp1 WHERE tbl_temp1.fld_order_id > 100;
다음 조건들은 INSERT ... SELECT 문들에서 속한 것들이다.
중복 키 위반을 일으키는 레코드들을 무시 하기 위해 IGNORE를 사용한다.
DELAYED는 INSERT ... SELECT 로 무시 된다..

:::MySQL Korea:::
INSERT 문의 목표 테이블은 질의의 SELECT 문의 FROM 절에 나타날 수 있다. (예전 MySQL에서는 발생 하지 않았다)
AUTO_INCREMENT컬럼들이 변함 없이 작동한다.
바이너리 로그가 원본 테이블의 재 생성을 위해 사용되도록하려면 MySQL은 INSERT ... SELECT 문을 위한 현재 삽입들을 가
능하지 않게 한다.
현재는 , 하부 질의 에서 같은 테이블로 부터 선택이나 삽입을 할수 없다.
ON DUPLICATE KEY UPDATE의 값 부분에서 SELECT 부분에서 GROUD BY문을사용 하지 않는 이상 여러분은 다른 테이블
에서 컬럼들을 참조 할수 있다. 하나의 side effect는 여러분이 값 부분에서 유일 하지 않은 컬럼 이름들을 손질 해야 한다는 것이
다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.4.2. INSERT DELAYED
13.2.4 INSERT INSERT DELAYED ...
13.2.4.1 INSERT ..
INSERT 문에서 DELAYED옵션은 표준 SQL에 대한 MySQL의 확장 이다. 이것은 여러분이 INSERT 를 완수 하기 위해 기다려
13.2.4.3 INSERT ..
야 하는 클라이언트가 있을때 유용 하다. 이 것은 여러분이 logging을 위해 MySQL을 사용할 때와 주기적으로 오랜 시간을 필요로
하는 SELECT와 UPDATE문을 실행 시킬때 일반 적인 상황이다.
클라이언트가 INSERT DELAYED를 사용할 때 server 로부터 OK를 받고 그 레코드는 테이블이 다른 어떤 쓰레드에 의해서 사용
되지 않을때 queuing되 었다가 삽입 된다.
INSERT DELAYED문을 사용하는 또 하나의 큰 이점은 많은 클라이언트로부터의 삽입들이 한데 묶여 한 블럭으로 쓰여 진다는

것이다. 이것은 개별적으로 삽입 하는 것보다 훨씬 빠르게 수행 된다.
테이블이 반대로 사용되지 않으면 INSERT DELAYED가 일반 INSERT보다 느려짐을 유의 해야 한다. 지연된 레코드들이 있는
각 테이블에 대해 서버가 개별 쓰레드로 하여금 처리 하게 하면 추가적인 오버 헤드가 있다. 이는 정말 필요로 할 때에만 INSERT
DELAYED를 사용해 함을 의미 한다.
queuing된 레코드들은 table에 삽입 될 때까지 메모리에 존재 한다. 이는 여러분이 mysqld를 종료 하거나 mysqld가 죽을때 디스
크에 쓰여지지 않은 queuing된 레코드들은 분실 된 다는 것을 의미 한다.
DELAYED의 사용에 대한 제약 사항은 다음과 같다.

:::MySQL Korea:::
INSERT DELAYED문은 MyISAM, MEMORY 과 ARCHIVE 테이블에서 쓰인다. 이에 대한 사항은 14.1장 "MyISAM 저장 엔
진", 14.4장 "MEMORY(HEAP) 저장 엔진", 그리고 14.8장 "ARCHIVE 저장 엔진" 부분을 참조 하라.
MyISAM 테이블의 경우, 데이타 바일의 중간에 빈 블럭이 없는경우 SELECT 와 INSERT 문들이 지원된다. 이들 환경에서는
MyISAM에서 INSERT DELAYED를 쓸 필요가 거의 없다.
INSERT DELAYED는 값 리스트 들을 명시하는 INSERT 문에서만 사용되어야 한다. 서버는 INSERT ... SELECT 혹은
INSERT ... ON UPDATE KEY UPDATE 문을 위해 DELAYED를 무시 한다.
INSERT DELAYED문이 즉시 리턴 하므로, 레코드들이 삽입 되기 전에 이 SQL문이 생성하는 AUTO_INCREMENT 값을 얻기

위해 LAST_INCRE_ID()를 사용 할수 없다.
DELAYED 레코드s 는 레코드들이 실제 삽입 될때 까지 SELECT문으로 볼수 없다.
DELAYED는 종속 응답 서버(slave replication server)에서 무시 되는데 이는 slave가 master와 다른 데이타를 갖게 될 수 있

기 때문이다.
다음 설명들은 여러분이 INSERT 나 REPLACE에 대한 DELAYED 옵션을 사용할때 발생하는 사항에 대해 상세히 설명 한다. 이
설명에서 "쓰레드(thread)"는 INSERT DELAYED문을 받는 쓰레드 이고 "핸들러(handler)"는 특정 테이블에 대한 모든
INSERT DELAYED 문을 처리 하는 쓰레드 이다.
한 쓰레드가 테이블에 대해 DELAYED문을 실행 할때, 핸들러 쓰레드가 존재 하지 않는 경우, 그 테이블을 위한 모든 DELAYED문

들을 처리 하기 위해 생성된다.
쓰레드는 핸들러가 이전에 얻은 DELAYED 잠금(lock)을 가지고 있는지 검사 하고 이 잠금(lock)이 없다면 핸들러 쓰레드에게 이
를 명령한다. DELAYED 잠금은 다른 쓰레드들이 테이블에 대해 READ 혹은 WRITE잠금을 가진 경우도 얻어질 수 있다. 그러나
핸들러는 테이블 구조가 최신상 태를 유지 하도록 하기 위해 모든 ALTER TABLE 잠금 이나 FLUSH TABLES 문이 끝나길 기다
린다.
쓰레드는 INSERT 문을 실행 하지만 레코드를 테이블에 쓰는 대신 최종 레코드의 복사본을 핸들러 쓰레드가 관리하는 큐(queue)
에 넣어 둔다. 쓰레드에 의해 문법 에러가 발생 되고 이는 클라이언트 프로그램에 보고 된다.

:::MySQL Korea:::
클라이언트는 서버에서 중복된 레코드의 수나 결과 레코드를 위한 AUTO_INCREMENT값을 얻을수 없다. 삽입 연산이 끝나기 전
에 INSERT는 리턴 되기 때문이다. ( 같은 이유로 C API 함수인 mysql_info()함수를 사용하면 어떤 값도 리턴 할수 없다.)
바이너리 log는 레코드가 테이블에 삽입 될때 핸들러 쓰레드에 의해 업데이트 된다. 다수 레코드 삽입의 경우 바이너리 log는 첫번
째 레코드가 삽입 될때 업데이트 된다.
delayed_insert_limit 레코드들이 쓰여지면, 핸들러는 어떤 SELECT문이 대기 상태 인지 조사 한다. 만약 이 경우가 발생 하면 계

속 하기 전에 이들을 실행 한다.
핸들러가 큐에 더이상의 레코드를 가지고 있지 않으면 테이블의 잠금은 풀린다. 새로운 INSERT DELAYED문들이
delayed_insert_time 시간안에 있지 않으면 핸들러는 종료된다.
특정 핸들러 큐에 delayed_queue_size 레코드 보다 더 많은 수의 레코드가 대기상태로 있으면 INSERT DELAYED를 요구 하는

쓰레드는 큐에 공간이 있을때까지 기다린다. 이는 mysqld가 지연된 메모리 큐를 위해 모든 메모리를 사용하지 않도록 하기 위함이
다.
핸들러 쓰레드는 Command 컬럼 안에 delayed_insert로 MySQL 프로세스 리스트 안에 나타난다. 여러분이 FLUSH TABLES 문
을 실행 하거나 KILL 쓰레드 id 을 이용하면 그 쓰레드를 제거 할 수 있다. 그러나 그 전에 모든 큐잉 된 레코드들을 테이블에 저장
한다. 이 시간 동안은 다른 쓰레드들로 부터 어떤 새로운 INSERT 문도 받아 들이지 않는다. 이 뒤에 INSERT DELAYED를 실행
하면 새로운 핸들러 쓰레드가 생성된다.
INSERT DELAYED문이 INSERT DELAYED 핸들러가 실행 되는 동안에는 일반 INSERT문 보다 우선 순위가 높다는 것에 유

의 하라. 다른 업데이트 문은 INSERT DELAYED 큐가 빌 때까지나 쓰레드를 종료 시키거나, FLUSH TABLES를 실행 할 때까
지 기다려야 한다.
아음 상태 값은 INSERT DELAYED 문에 대한 정보를 제공한다.

:::MySQL Korea:::
Status Variable Meaning
Delayed_insert_threads 핸들러 쓰레드 수
Delayed_writes INSERT DELAYED 에서 쓰여진 레코드 수
Not_flushed_delayed_rows 쓰기 대기 상태인 레코드 수
여러분은 이들 값을 SHOW STATUS 문이나 mysql admin extened-status 명렬을 통해 확인 해 볼 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.4.3. INSERT ... ON DUPLICATE KEY UPDATE
13. SQL 문법(SQL Statement Syntax) ON DUPLICATE KEY UPDATE를 명시 할경우, UNIQUE 인덱스 혹은 PRIMATU KEY에서 중복 값을 가진 레코드가 삽입되
13.2. 데이터 조작 SQL문 면 예전 레코드의 UPDATE 가 수행된다. 예를 들면 컬럼 a가 UNIQUE 로 선언되고 값으로 1을 가진 경우 다음 두 문장은 동일
13.2.4 INSERT 한 효과를 같는다.
13.2.4.1 INSERT ..
13.2.4.2 INSERT DELAYED INSERT INTO table (a,b,c) VALUES (1,2,3)
ON DUPLICATE KEY UPDATE c=c+1;
13.2.4.3 INSERT ..
UPDATE table SET c=c+1 WHERE a=1;
레코드가 새 레코드로 삽입 되면 영향을 받는 레코드의 값은 1이고 기존 레코드가 업데이트 되면 값이 2이다.
컬럼 b가 유일 하다면, INSERT문은 UPDATE문과 동일하다.
UPDATE table SET c=c+1 WHERE a=1 OR b=2 LIMIT 1;
a=1 OR b=2 가 몇개의 레코드와 일치하면 단지 하나의 레코드만 업데이트 된다. 일반적으로 여러분을 다수 유일 인덱스를 가진
테이블에서 ON DUPLICATE KEY절을 사용하여 이를 피하여야 한다.
INSERT ... UPDATE문의 INSERT 부분에서 컬럼 값을 참조하게 되는 UPDATE절에서 VALUES(컬럼 이름)함수를 사용할 수
있다. 즉, UPDATE 절 안의VALUES(컬럼 이름)은 삽입될 컬럼 이름의 값을 참조 하여 중복 키 문제가 발생 하지 않는다. 이 함수
는 다수 레코드 삽입시 유용한다. VALUES() 함수는
INSERT ... UPDATE문에서만 유효 하며 그 외경우는 NULL을 리턴한다.
예를 들면 ;

:::MySQL Korea:::
INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6)

ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);
이 문은 다음 두개의 SQL문과 동일 하다.
INSERT INTO table (a,b,c) VALUES (1,2,3)

ON DUPLICATE KEY UPDATE c=3;
INSERT INTO table (a,b,c) VALUES (4,5,6)
ON DUPLICATE KEY UPDATE c=9;
DELAYED 옵션은 ON DUPLICATE KEY UPDATE를 사용 하는 경우 무시 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.5. LOAD DATA INFILE
13.2. 데이터 조작 SQL문 LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name'

[REPLACE | IGNORE]
INTO TABLE tbl_name
[FIELDS
[TERMINATED BY 'string']
[[OPTIONALLY] ENCLOSED BY 'char']
[ESCAPED BY 'char']
[LINES
[STARTING BY 'string']
[TERMINATED BY 'string']

:::MySQL Korea:::
[IGNORE number LINES]
[(col_name_or_user_var,...)]
[SET col_name = expr,...)]
LOAD DATA INFILE 텍스트 파일에서 테이블에 매우 빠른 속도록 레코드를 읽어 들인다. 파일 이름은 알파벳 문자열로 주어져
야 한다.
LOAD DATA INFILE 은 SELECT ... INTO OUTFILE 문의 보충이다. (13.2.7장 "SELECT"부분을 참고 하라.) 테이블에서 파
일로 데이타를 쓰기 위해서는 SELECT ... INTO OUTFILE문을 사용하라. 파일에서 테이블로 다시 읽기 위해서는 LOAD DATA
INFILE 을 사용하라. FIELDS와 LINES 절의 문법은 두 문장에서 동일하다. 두 절은 옵션이며 두개의 절이 명시된 경우 LINES 절
이 선행 한다.
LOAD DATA INFILE 의 속도 개선과 LOAD DATA INFILE 에 비해 INSERT의 효과에 대한 정보는 7.2.16장 "INSERT 문의
속도" 부분을 참조 하라.
character_set_database 시스템 변수에 의해 지정된 문자열 모음(character set)은 파일안의 정보를 해석하기 위해 사용된다.
SET NAMES와 character_set_client의 설정은 입력에 대한 해석에 영향을 주지 않는다.
ucs2 문자열 모음을 사용하는 데이타 파일들을 읽을수 없다는것을 주의 하라.
MySQL 5.0.19에서 character_set_filesystem 시스템 변수는 파일 이름의 해석을 제어 한다.
mysqlimport utility를 사용하여 데이타 파일을 읽어 들일수 있다. 이 utility는 LOAD DATA INFILE 문을 서버에 보냄으로서 작
동한다. --local 옵션은 mysqlimport가 클라이언트 호스트로부터 데이타 파일을 읽도록 한다. 여러분은 클라이언트와 서버가 압
축 프로토콜을 지원하는 경우 느린 네트웍에서 좀더 성능을 향상 시키기 위해 --compress 옵션을 사용할 수 있다. 이에대한 자세
한 내용은 8.12장 "mysqlimport - 데이타 가져오기 프로그램" 부분을 참조하라.
LOW_PRIORITY를 사용하면 LOAD DATA 문의 실행이 다른 모든 클라이언트들이 테이블에서 데이타를 읽지 않을 때까지 지연

:::MySQL Korea:::
된다.
동시 삽입(즉, 중간에 빈 블럭을 갖지 않는 경우)을 위한 조건을 만족하는 시키는 MyISAM 테이블에 대해 CONCURRENT를 명시
하면 다른 쓰레드는 LOAD DATA 가 실행 되는동안 테이블에서 데이타를 가져 올 수 있다. 이 옵션의 사용은 동시에 다른 어떤 쓰
레드들도 그 테이블을 사용하지 않아도 LOAD DATA의 성능에 약간 영향을 준다.
LOCAL 키워드는 클라이언트와의 연결 종료로 해석 된다.
LOCAL 이 명시 되면 파일은 클라이언트 호스트에서 읽혀져 서버에 보내진다. 이 파일은 정확한 위치를 명시 하기 위해 절대 경로
로 주어질수 있다. 상대 경로로 주어지는 경우 그 이름은 클라이언트 프로그램이 시작한 디렉토리와 연관되어 해석 된다.
LOCAL 이 명시 되지 않으면 파일은 서버 호스트에 존재해야하며 서버에 의해 직접 읽혀 진다. 서버는 파일의 위치를 파악 하기 위
해 다음 규칙을 사용한다.
파일 이름이 절대 경로이면 서버는 그것이 주어진 대로 사용한다.
파일 이름이 하나 혹은 그 이상의 컴포넌트를 가진 상대 경로이면 서버는 서버의 데이타 디렉토리와 관련된 파일을 찾는다.
주요 요소를 갖지 않은 파일이름이 주어진 경우 서버는 기본 데이타 베이스의 데이타베이스 디렉토리에서 파일을 검색 한다.
LOCAL 이 아닌 경우, 이들 규칙들은 ./myfile.txt로 주어진 파일은 서버의 데이타 디렉토리에서 읽혀짐을 의미한다. 파일 이름이
myfile.txt인경우에는 기본 데이타베이스의 데이타베이스 디렉토리에서 읽혀 진다. 예를 들면 db1이 기본 데이타베이스 이면 , 그
SQL문이 그 파일을 db2 데이타베이스 안의 테이블에 읽어 들인다 해도, 다음 LOAD DATA 문은 db1의 데이타베이스 디렉토리로
부터 data.txt파일을 읽는다.
LOAD DATA INFILE 'data.txt' INTO TABLE db2.my_table;
Windows 경로는 역 슬래쉬보다 슬래쉬를 사용하여 명시 된다. 여러분이 역 슬래쉬를 이용하면 두번 상요해야 한다.
안전상의 이유로 서버에 위치한 텍스트 파일들을 읽을때 파일들은 데이타베이스 디렉토리에 위치 하거나 모두에 의해 읽혀질 수 있
어야 한다. 또한 서버 파일에서 LOAD DATA INFILE 의 사용을 위해서는 FILE 권한을 가지고 있어야 한다. 이에 대한 사항은

:::MySQL Korea:::
5.8.3장 "MySQL이 제공하는 권한"부분을 참조하라.
LOCAL의 사용은 서버가 파일을 직접 접근하도록 하는 것보다 약간 느린데 그 파일의 내용이 클라이언트에서 서버로의 연결을 통
해 보내지기 때문이다. 반면 LOCAL파일을 읽어들이기 위해서 FILE권한은 필요없다.
LOCAL은 서버와 클라이언트 모두가 그것을 허락하는 경우에만 작동한다. 예를 들면 mysqld가 --local-infile=0, 으로 시작하
면 , LOCAL은 작동하지 않는다. 이에 대한 사항은 5.7.4장 " LOAD DATA LOCAL의 Security사항" 부분을 참조 하라.
Unix에서는 pipe에서 읽기 위해 LOAD DATA 를 필요로 하는 경우 여러분은 다음과 같은 기술을 사용할 수 있다.
mkfifo /mysql/db/x/x
chmod 666 /mysql/db/x/x
find / -ls > /mysql/db/x/x
mysql -e "LOAD DATA INFILE 'x' INTO TABLE x" x
REPLACE 와 IGNORE 키워드들은 유일키 값에서 중복 된 레코드가 있을때, 레코드의 입력 처리를 제어 한다.
REPLACE를 명시하면 입력 레코드는 존재하는 레코드를 바꾼다. 즉, primary key나 unique 인덱스 값이 같은 레코드가 있을 경
우이다. 이에 대한사항은 13.2.6장 "REPLACE"부분을 참조 하라
여러분이 IGNORE를 명시 하면, 유일키에서 기존 레코드와 중복된 레코드 입력은 건너뛴다. 여러분이 어떤 옵션도 명시 하지 않으
면 그 행동은 LOCAL 키워드가 명시 되어 있느냐에 따라 달라진다. LOCAL이 없는 경우, 중복된 키값이 발견되면 에러가 발생한
다. 이때 텍스트 파링릐 나머지는 무시 된다. LOCAL이 있는 경우, 기본 행동은 IGNORE가 명시 되었을때와 같다. 이는 서버가 연
산 중간에 파일의 전송을 중단 시킬 방법이 없기때문이다.
load연산 중에 외래 키 제약 사항을 무시하려면 LOAD DATA 문의 실행 전에 SE_FORIENG_KEY_CHECKS=0 문을 사용하라.
비어 있는 MyISAM 테이블에 LOAD DATA INFILE을 사용하면 모든 non-unique인덱스들이 개별 배치 안에서 생성된다

( REPAIR TABLE). 정상적으로 이것은 많은 인덱스를 가진 경우 LOAD DATA INFILE 문을 빠르게 한다. 몇가지 극단적인 경
우, 파일을 읽어 들인 다음 인덱스를 재 생성 하기 위해서 ALTER TABLE ... ENABLE KEYS를 사용하거나 파일을 테이블로 읽

:::MySQL Korea:::
기 전 ALTER TABLE ... DISABLE KEYS문으로 그것들을 제외 시키면 훨씬 빨리 인덱스를 생성 할 수 있다. 이에 대한 사항은
7.2.15장 "INSERT 문의 속도"부분을 참조 하라.
LOAD DATA INFILE과 SELECT ... INTO OUTFILE문 모두에게 , FIELDS와 LINES 절의 문법은 같다. 두 절은 옵션이지만
FIELDS가 LINES보다 선행 한다.
FIELDS절을 명시할 경우 그것의 하부 절들(TERMINATED BY , [OPTIONALLY] ENCLOSED BY 와 ESCAPED BY)의 각각

또한 옵션인데 하나만 명시할 경우는 예외가 된다.
FIELDS 절을 명시하지 않으면, 기본적으로 여러분이 다음을 쓴것과 같다.
FIELDS TERMINATED BY '￦t' ENCLOSED BY '' ESCAPED BY '￦￦'
LINES절을 쓰지 않으면, 기본적으로 아래처럼 사용한 것과 같다.
LINES TERMINATED BY '￦n' STARTING BY ''
달리 말하자면, 기본 값들은 LOAD DATA INFILE 입력을 읽을때 다음과 같이 행동하도록 한다.
새로운 줄에 있는 줄 경계들을 찾아라.
어떤 라인의 prefix도 빠트리지 말라.
tab으로 줄들을 필드들로 나눈다.
어떤 필드도 인용 문자안에 포함된다고 바라지 말라.
문자열에서 탭, 개행 문자, '￦' 들의 출현은 필드 값들의 일부로 해석하라.
반대로, 기본적으로 쓰기의 경우, SELECT ... INTO OUTFILE 문이 다음과 같이 행동하도록 한다.

:::MySQL Korea:::
필드 사이에 탭을 쓰라.
필드를 어떤 인용 문자들 안에도 넣지 마라.
필드 값들에서 나타나는 탭,개행,혹은 '￦'의 탈출 자로는 '￦'를 사용하라.
라인의 끝에는 개행문자를 쓰라.
역슬래쉬(backslash)는 문자열에서 MySQL excape 문자이다. 따라서 FIELDS ESCAPED BY '￦￦'를 쓰려면 두개의 사용하여
하나의 역슬래쉬로 해석 되도록 하라.
주의 : 윈도우 시스템에서 텍스트 파일을 생성했다면 여러분은 파일을 적절하게 읽기 위해 LINES TEMINATED BY '￦r￦n' 을
사용해야 한다. 왜냐 하면 윈도우 프로그램은 전형적으로 라인 종결자로써 두개의 문자열을 사용하기 때문이다. 워드 패드 같은 프
로그램은 파일 쓰기가 끝나면 줄 종결자로서 ￦r을 사용한다. 이런 파일을 읽기 위해서는 LINE TERMINATED BY '￦r'을 사용하
라.
여러분이 읽어들이는 모든 라인이 여러분이 무시하려는 일반 prefix를 가진 경우 그 prefix를 건너뛰기 위해 LINES STARTING
BY 'prefix_string'을 사용할 수 있다. 한 라인이 prefix를 포함 하지 않으면 전체 라인이 걸러 진다. 여러분이 다음과 같은 문장을
사용 한다고 하면
LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test

FIELDS TERMINATED BY ',' LINES STARTING BY 'xxx';
데이타 테이블은 다음과 같이 보일경우
xxx"abc",1
something xxx"def",2
"ghi",3
결과 레코드는 ("abc",1) 와 ("def",2)가 된다. 파일에서 세번째 줄은 prefix를 포함 하지 않으므로 걸러진다.
IGNORE 숫자 LINES 옵션은 파일의 시작에서 라인들을 모시 하기 위해 사용될 수 있다. 예를 들면 IGNORE 1 LINES를 쓰면 컬

:::MySQL Korea:::
럼 이름들을 포함 한 초기 header 라인을 건너뛰게 된다.
LOAD DATA INFILE '/tmp/test.txt' INTO TABLE test IGNORE 1 LINES;
데이타베이스에서 데이타를 파일에 쓰기 위해 LOAD DATA INFILE와 연결된 SELECT ... INTO OUTFILE을 사용하고 다시 파
일을 데이타베이스로 읽어 들일 경우 두 SQL문은 필드와 라인 처리 옵션이 일치 해야 한다. 그렇지 않으면 LOAD DATA INFILE
은 파일의 내용을 처리 하지 못할 것이다. 콤마로 구분된 필드들을 파일에 쓰기 위해 SELECT ... INTO OUTFILE을 사용한다고
가정하면;
SELECT * INTO OUTFILE 'data.txt'

FIELDS TERMINATED BY ','
FROM table2;
콤마로 구분된 파일을 읽어 들이기 위한 정확한 SQL문은;
LOAD DATA INFILE 'data.txt' INTO TABLE table2

FIELDS TERMINATED BY ',';
아래와 같은 SQL문을 사용하여 파일을 읽는다면, LOAD DATA INFILE이 필드들 사이에서 탭을 찾으려 하기 때문에 작동하지 않
는다.
LOAD DATA INFILE 'data.txt' INTO TABLE table2

FIELDS TERMINATED BY '￦t';
가능한 결과는 각 입력 라인이 하나의 필드로 해석될때이다.
LOAD DATA INFILE 문은 외부 출처에서 언어딘 파일을 읽기 위해 사용될때이다. 예를 들면 많은 프로그램들이 콤마 분류 값 형

식(CSV)로 데이타를 내보낼수 있는데 그 라인들은 콤마로 구분 되고 큰 따옴표에 의해 둘러싸인 필드를 가진다. 그러한 파일안의
라인들이 개행 문자로 끝나면, 그 여기 보여지는 SQL문은 여러분이 파일을 load하기 위해 사용하게될 field- ,와 line- 처리 옵션
을 설명한다.

:::MySQL Korea:::
LOAD DATA INFILE 'data.txt' INTO TABLE 테이블 이름

FIELDS TERMINATED BY ',' ENCLOSED BY '"'
LINES TERMINATED BY '￦n';
field-나 line- 옵션중 어느것이든 빈문자열('')을 명시 할 수 있다. 빈 상태가 아니면 FIELDS[OPTIONALLY]ENCLOSED BY

와 FIELDS ESCAPED BY 값들은 하나의 문자이어야 한다. FIELDS TERMINATED BY, LINES STARTING BY 그리고
LINES TERMINATED BY값들은 한문자 이상이 될 수 있다. 예를 들면 cariiage return/linefeed 쌍으로 끝나는 라인을 쓰기 위
해서, 혹은 그런 라인을 포함한 파일을 읽기 위해서는 LINES TERMINATED BY '￦r￦n' 절을 사용하라.
%%구성하는 줄들에의해 구분된 jokes를 포함한 파일을 읽기 위해서는 다음과 같이 할 수 있다.
CREATE TABLE jokes

(a INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
joke TEXT NOT NULL);
LOAD DATA INFILE '/tmp/jokes.txt' INTO TABLE jokes
FIELDS TERMINATED BY ''
LINES TERMINATED BY '￦n%%￦n' (joke);
FIELDS [OPTIONALLY] ENCLOSED BY는 필드들의 인용을 제어한다. 출력(output) (SELECT ... INTO OUTFILE)을 위
해 , OPTIONALLY를 생략 하면 모든 필드들이 ENCLOSED BY 문자에 의해 둘러싸인다. 아래 예제를 참고 하라.
"1","a string","100.20"
"2","a string containing a , comma","102.20"
"3","a string containing a ￦" quote","102.20"
"4","a string containing a ￦", quote and comma","102.20"
여러분이 OPTIONALLY를 명시하면 , ENCLOSED BY 문자는 문자 데이타 형(CHAR, BINARY, TEXT, ENUM)을 갖는 컬럼들
로 부터 값들을 포함 시키기 위해 사용된다.
1,"a string",100.20

:::MySQL Korea:::
2,"a string containing a , comma",102.20

3,"a string containing a ￦" quote",102.20
4,"a string containing a ￦", quote and comma",102.20
한 필드 값안의 ENCLOSED BY 문자의 출현은 ESCAPED BY 문자로 그것들을 prefix로 만드는 것에서 벗어난는 점에 유의 하
라. 또한 여러분이 빈 ESCAPED BY 값을 명시하면 LOAD DATA INFILE에 의해 올바르게 읽혀 질수 없는 output을 만들 가능
성이 있다는것을 주의 하라. 예를 들면 선행하는 output은 escape문자가 비어 있으면 다음과 같이 나타날 것이다. 네번째 줄의 두
번째 필드가 다음 인용 을 하는 콤마를 포함 한경우 필드를 끝내기 위해 나타난다.
1,"a string",100.20
2,"a string containing a , comma",102.20
3,"a string containing a " quote",102.20
4,"a string containing a ", quote and comma",102.20
입력을 위해 ENCLOSED BY 문자는 필드 값의 끝에서 제거 된다. (이것은 OPTIONALLY가 명시 된것과 무관하다.

OPTIONALLY는 입력 문의 해석에 어떤 영향도 끼치지 않는다.) ESCAPED BY 문자에 선행 하는 ENCLOSED BY 문자의 출현
은 현재 필드 값의 일부로 해석 된다.
필드가 ENCLOSED BY 문자 로 시작하면 그 문자의 instance는 라인 TERMINATED BY 일련 번호혹은 그 필드가 오는 경우 필

드 값을 끝내는 것으로 간주 되어 진다. 이런 모호 함을 피하기 위해서는 필드 값안에 ENCLOSED BY 문자의 출현이 중복 될수 있
고 그 문자의 한 instance로 해석 될 수 있다. 예를 들면 ENCLOSED BY '"'가 명시 된 경우 인용부호는 아래 처럼 처리 된단.
"The ""BIG"" boss" -> The "BIG" boss

The "BIG" boss -> The "BIG" boss
The ""BIG"" boss -> The ""BIG"" boss
FIELDS ESCAPED BY는 특별한 문자들을 어떻게 읽고 쓰는지 제어 한다. 만약 FIELDS ESCAPED BY 문자가 비어 있지 않으
면 output에서 다음 문자들을 prefix로 하는데 사용한다.
FIELDS ESCAPED BY character

:::MySQL Korea:::
FIELDS [OPTIONALLY] ENCLOSED BY character
FIELDS TERMINATED BY 와 LINES TERMINATED BY 값들의 첫 문자
ASCII 0 (실제 escape 문자로 ASCII '0'쓰는데 zero값의 바이트가 아니다)
FIELDS ESCAPED BYTE 문자가 빈 경우, 어떤 문자들도 이를 벗어 날 수 없으며 NULL은 ￦N 이 아닌 NULL로 출력된다. 빈
escape문자를 명시하는 것은 좋은 생각이 아니며 데이타의 필드 값들이 주어진 문자들 중 하나를 포함 한다면 더욱 좋지 않다.
입력을 위해 FIELDS ESCAPED BY 문자 가 비어 있지 않으면 문자의 표현은 제거 되고 이따르는 문자는 필드 값의 일부로 간주

된다. 이 예외들은 '0'dlsk 'N'일때이다 (예로써 ￦N 이나 ￦N 이 escape 문가가 '￦'인 경우 이에 해당한다). 이들은 ASCII NULL
(zero 값의 byte) 과 NULL로 해석 된다. NULL핸들링의 규칙들은 이 장의 뒤에서 설명된다.
'￦' escape 문법에 관한 보다 자세한 사항은 9.1장 "문자 값" 부분을 참조 하라.
어떤 경우에는 field-와 line-처리 옵션이 서로 상호 작용을 한다.
LINES TERMINATED BY가 빈 문자열이고 FIELDS TERMINATED BY가 비어있지 않을경우 라인은 FIELDS
TERMINATED BY로 끝맺는다.
FIELDS TERMINATED BY 와 FIELDS ENCLOSED BY값들은 모두 빈(empty,'')경우, fixed-row 포맷이 사용된다. fixed-
row포맷과는 어떤 경계자(delimiter)들도 필드 사이에서 사용되지 않는다. 대신 컬럼 값들은 컬럼의 display 폭을 이용하여 읽기
와 쓰기를 한다. 예를 들면 한 컬럼이 INT(7)로 선언 되면, 그 컬럼의 값들이 7자리 필드를 이용하여 쓰여진다. 입력시, 컬럼에 대
한 값들은 7자리 문자들을 읽어 얻어진다.
LINES TERMINATED BY가 각 라인들을 분리 하기 위해 사용된다. 한 라인이 모든 필드를 포함 하지 않으면 나머지 컬럼들은 기
본값으로 설정 된다. 라인 종결자를 갖지 않으면 여러분은 이를 ''로 설정 해야한다. 이경우 텍스트 파일은 각 레코드를 위해 모든 필
드를 포함한다.
Fixed-row 포맷은 나중에 설명이 되겠지만 NULL값들의 처리에 영향을 준다. 고정 크기의 포맷은 여러분이 multi-byte문자 모

:::MySQL Korea:::
음을 사용한다면 작동하지 않는다는 것을 유의 하라.
NULL 값들의 처리는 사용시 FIELDS 와 LINES옵션 에 따라 다양하다.
기본 FIELDS와 LINES 값들에 대해, NULL이 output을 위해 ￦N의 필드 값으로 쓰여지고 ￦N의 필드 값이 입력시 NULL로 읽
혀 진다. (ESCAPED BY 문자 가 '￦N'이라 가정한면)
FIELDS ENCLOSED BY가 empty가 아니면 NULL 문자를 포함한 필드는 NULL 값으로 읽혀 진다. 이것은 FIELDS
ENCLOSED BY 문자열안에 묶인 NULL과는 다른데 이것은 문자열 'NULL'로 읽혀 진다.
FIELDS ESCAPED BY 가 empty이면 , NULL 이 단어 NULL로 쓰여진다.
fixed-row포맷으로 (FIELDS TERMINATED BY와 FIELDS ENCLOSED BY 모두가 empty empty일경우 사용된다.), NULL
이 empty 문자열로 사용된다.이것은 NULL 값들과 table의 empty문자열이 파일에 쓰여질때 둘다가 empty 문자열로 쓰여지므로
구분이 불가능하다. 만양 여러분이 파일에서 읽어 들일때 서로 다르게 말해야하 할 경우가 있다면 fixed-row 포맷을 사용할수 없
다.
다음과 같은 경우는 LOAD DATA INFILE에의해 제공 되지 않는다.
고정 크기 레코드(FIELDS TERMINATED BY와 FIELDS ENCLOSED BY모두 empty)와 BLOB 혹은 TEXT 컬럼들.
다른 prefix이거나 혹은 같은 하나의 분리자를 명시 한 경우 LOAD DATA INFILE은 입력을 올바르게 해석 할 수 없다. 다음

FIELDS절이 문제를 일으킬수 있다.
FIELDS TERMINATED BY '"' ENCLOSED BY '"'
FIELDS ESCAPED BY가 empty이면 FIELDS TERMINATED BY 값에 수반된 FIELDS ENCLOSED BY혹은 LINES
TERMINATED BY를 포함하는 한 필드 값은 LOAD DATA INFILE이 되어 필드나 라인을 읽는것을 빨리 멈춘다. LOAD
DATA INFILE이 필드나 라인 값이 어디에서 끝나는지 정확히 결정 할 수 없기때문에 발생한다.
다음 예제는 persondata 테이블의 모든 컬럼을 읽어 들인다(load)

:::MySQL Korea:::
LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;
기본적으로 컬럼 리스트가 LOAD DATA INFILE 문의 끝에 제공 되지 않으면 입력 라인들은 각 테이블 컬럼에 대해 하나의 필드
를 포함하는것으로 예상된다. 만약 여러분이 테이블의 컬럼들중 일부만을 읽어들이고 싶다면 컬럼 리스트를 명시 하라.
LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata (col1,col2,...);
여러분은 입력 파일의 필드 순서가 테이블 안의 컬럼들의 순서와 다른 경우 여러분은 하나의 컬럼 리스트를 명시 해야 한다. 그렇
지 않으면 MySQL은 테이블 컬럼과 입력 필드들을 어떻게 매치 시킬지 말할 수 없다.
MySQL 5.0.3이전에는 컬럼 리스트는 읽혀진 컬럼들의 이름을 포함 해야하며 SET 절은 제공 되지 않는다. MySQL 5.0.3에서부
터는 컬럼 리스트는 컬럼 이름들이나 사용자 변수들을 포함할 수 있다. 사용자 변수들과 함께 SET절은 그 결과를 컬럼들에 할당
하기 전에 변수 값들에 변환을 수행 할수 있게 한다.
SET절의 사용자 변수들은 몇가지 방법으로 사용될 수 있다. 다름 예제는 t1.column1의 값에 직접 처음 입력 컬럼을 사용하고 두
번째 컬럼은 t1.column2의 값에 사용되기전의 분리 연산에 의해 사용자변수에 할당 된다.
LOAD DATA INFILE 'file.txt'

INTO TABLE t1
(column1, @var1)
SET column2 = @var1/100;
SET절은 입력 파일로부터 나오지 않은 값들을 제공하는데 사용될수 있다. 다음 SQL문은 column3을 현내 날짜와 시간으로 설정
한다.

INTO TABLE t1
(column1, column2)
SET column3 = CURRENT_TIMESTAMP;

:::MySQL Korea:::
입력 값을 사용자 변수에 할당하여 없애고 그 변수를 테이블 컬럼에 할당하지 않음으로서 제거 할 수 있다.

INTO TABLE t1
(column1, @dummy, column2, @dummy, column3);
컬럼/변수 리스트와 SET절의 사용은 다은 제한에 따른다.
SET절에서 할당은 할당 연산자의 왼쪽에 컬럼 이름을 가질 수 있다.
SET 할당의 오른쪽에 하부 질의를 사용할 수 있다. 한 컬럼에 할당되기 위한 값을 리턴하는 하부 질의는 스칼라(scalar) 하부 질
의 이다. 또한 여러분은 읽혀지고 있는 테이블로 부터 선택을 하기 위해 하부 질의를 사용할 수 없다.
IGNORE절에 의해 무시된 라인들은 컬럼/변수 리스트 나 SET 절을 위해 처리 되지 않는다.
fixed-row포맷으로 데이타를 로딩할때 사용자 변수들이 display폭을 갖지 않으므로 사용자 변수들은 사용될 수 없다.
입력 라인을 처리 할때 LOAD DATA는 필드들로 나누고 값들을 컬럼/변수 리스트와 SET절에 따라 나눈다. 그리고 결과 레코드
는 테이블에 삽입된다. 테이블을 위해 BEFORE INSERT 나 AFTER INSERT 트리가가 있는경우 레코드 삽입 이전 혹은 이후에
개별 적으로 활성화 된다.
한 입력 라인 이 너무 많은 필드를 가진 경우 나머지 필드들은 무시 되고 경고의 수가 증가 한다.
입력 라인이 극히 적은 필드를 가진 경우 테이블 컬럼 기본 값들로 설정한다. 기본 값의 할당에 관한 사항은 11.1.4장 "데이타 형

기본 값"부분을 참조 하라
empty필드 값이 다르게 해석 되면
문자 형에서 컬럼이 empty 문자열로 설정된다.

:::MySQL Korea:::
숫자형에서는 컬럼은 0으로 설정된다.
date와 time형인 경우 컬럼은 "zero"값으로 설정된다. 이 내용은 11.3장 "날짜와 시간 형"부분을 참고하라.
이들은 여러분이 빈 문자열을 INSERT나 UPDATE문에서 명시적으로 하나의 문자열,숫자 혹은 날짜 시간 형에 할당하려할 때 같

은 결과 값이 된다.
TIMESTAMP컬럼들은 컬럼에 NULL 값이 있다면(￦N), 혹은 TIMESTAMP컬럼의 기본 값이 현재 timestamp이고 필드 리스트

에서 빠진경우, 현재 날짜와 시간 형으로 설정 된다.
LOAD DATA INFILE 는 모든 입력을 문자열들로 인식하고 INSERT 문과 함께 ENUM이나 SET컬럼을 위한 숫자 값들을 사용
할 수 없다. 모든 ENUM과 SET값들은 문자열들로 명시 되어야 한다.
BIT값들은 이진법을 사용하여 읽혀 질수 없다.(예를 들면 b'011010'). 이를 위해서 정규 정수형으로 값들을 명시 하고 그것들을

면환 하기 위해서 SET절을 사용하나. 이것은 MySQL이 숫자 형 변환을 수행하고 그것들을 BIT 컬럼에 적당히 로드 한다.
shell> cat /tmp/bit_test.txt
127
shell> mysql test
mysql> LOAD DATA INFILE '/tmp/bit_test.txt'
-> INTO TABLE bit_test (@var1) SET b= CAST(@var1 AS SIGNED);
Records: 2 Deleted: 0 Skipped: 0 Warnings: 0

:::MySQL Korea:::
mysql> SELECT BIN(b+0) FROM bit_test;
+----------+
| bin(b+0) |
+----------+
| 10 |
| 1111111 |
+----------+
ROAD DATA INFILE문이 끝나면 다음과 같은 포맷으로 정보 문자열을 리턴한다.
Records: 1 Deleted: 0 Skipped: 0 Warnings: 0
여러분이 C API 함수를 사용한다면 mysal_info()함수를 호출하여 SQL문에관한 정보를 얻을 수 있다. 22.2.3.34장 "mysql_info
()"부분을 참조 하라.
값들이 INSERT문(13.2.4 "INSERT")을 통해 삽입 될때 같은 환경하에서 경고가 발생한다. 입력 레코드에 필드가 매우 적거나 매

우 많은 경우 경고를 발생할 수 있는경우는 예외 이다. 경고들은 어디에도 저장 되지 않으며 경고 수는 모든것이 잘되는 것을 의하
기 위해 사용 될 수 있다. 여러분은
어떤 잘못된 것이 있는지에 관한 정보로서 max error_count 경고의 리스트를 얻기 위해서 SHOW WARNINGS를 사용할 수 있

:::MySQL Korea:::
다. 이에 대한 사항은 13.5.4.25장 "SHOW WARNING"부분을 참조 하라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.6. REPLACE
13. SQL 문법(SQL Statement Syntax) REPLACE [LOW_PRIORITY | DELAYED]

13.2. 데이터 조작 SQL문 [INTO] tbl_name [(col_name,...)]
13.2.6 REPLACE VALUES ({expr | DEFAULT},...),(...),...
또는:
REPLACE [LOW_PRIORITY | DELAYED]

[INTO] tbl_name
SET col_name={expr | DEFAULT}, ...
또는:
REPLACE [LOW_PRIORITY | DELAYED]

SELECT ...
REPLACE 문은 PRIMARY KEY 와 UNIQUE 에 대해 새로운 레코드와 같은 값을 가진 테이블의 오래된 레코드가 있는 경우 기
존 레코드는 새 레코드가 삽입되기 전에 삭제 된다는 것을 제외 하고 INSERT 문과 같다. 이에 대한 사항은 13.2.4장
“INSERT”를 참조 하라.
REPLACE 는 표준 SQL에 대한 MySQL의 확장이다. 이것은 삽입, 혹은 삭제 후 삽입을 한다. 여러분이 이 SQL문 뒤에 오는 SQL
문에 대해 알고자 한다면 13.2.4.3장 “INSERT ... ON DUPLICATE KEY UPDATE”” 부분을 참조 하라.
테이블이 PRIMARY KEY 나 UNIQUE 인덱스를 갖지 않는 한, REPLACE문을 이용하는 것은 적절 하지 못하다는 것을 유의 해
야 한다. 이것은 새로운 레코드가 다른 것과 중복 될 때 결정하는데 필요한 인덱스가 없으므로 INSERT문과 같아진다.

:::MySQL Korea:::
모든 컬럼들에 대한 값은REPLACE 문에서 명시된 값들로부터 얻어진다. 빠진 누락된 컬럼들은 INSERT 문에서와 같이 기본값들
로 설정 된다. 현재 레코드에서 값을 참조 하거나 새로운 레코드에서 참조 할 수 없다. SET col_name=col_name + 1과 같은 할
당문을 사용할 경우, 오른쪽의 컬럼이름에 대한 참조는 DEFAULT(col_name)으로 할당 되고 이 할당은 SET col_name =
DEFAULT(col_name) + 1 과 같다.
REPLACE문을 사용하려면 테이블에 대한 INSERT 와 DELETE권한을 모두 가지고 있어야 한다.
REPLACE문은 영향을 받는 레코드의 수를 가리키는 값을 리턴한다. 이것은 삭제되고 삽입된 레코드의 합계이다. 그 수가 단일 레
코드 REPLACE인 경우 하나의 레코드가 삽입되고 삭제된 레코드가 없음을 의미한다. count값이 1보다 큰 경우 하나 혹은 그 이상
의 오랜 레코드들은 새로운 레코드가 삽입되기 전에 삭제 된 것이다. 테이블이 다중 유일 인덱스를 포함하고 있고 새로운 레코드가
다른 유일 인덱스 에서 오래된 레코드와 다른 중복된 값을 갖게 된다면 오래된 것과 교체될 가능성이 있다.
영향 받은 레코드 수는 REPLACE 가 단지 하나의 레코드만을 추가 한 것인지 혹은 다른 레크와 대체 되었는지를 결정하기 쉽게

해 준다. count값이 1인지 혹은 그보다 큰 지 검사 하도록 하라.
C API 를 사용한다면 영향 받은 레코드의 수는 mysql_affected_rows()함수를 이용하여 얻어질 수 있다. 현재는 테이블에서 대

치 나 하부 질의안에서 같은 테이블로부터 선택이 불가능 하다
MySQL은 REPLACE (와 LOAD DATA ... REPLACE)를 위한 다음 알고리즘을 사용한다.:
1. 테이블에 새로운 레코드를 삽입하려 한다.

2. primary key나 혹은 unique인덱스에 대해 중복 키 에러가 발생했기 때문에 삭제가 실패하면
a. 중복 키 값과 충동을 일으키는 레코드를 삭제 한다.
b. 테이블에 새로운 레코드를 삽입 하려 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.7. SELECT
13. SQL 문법(SQL Statement Syntax) 13.2.7.1. JOIN

13.2. 데이터 조작 SQL문 13.2.7.2. UNION
13.2.7 SELECT
13.2.7.1 JOIN Syntax SELECT
13.2.7.2 UNION [ALL | DISTINCT | DISTINCTROW ]

[HIGH_PRIORITY]
[STRAIGHT_JOIN]
[SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
[SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS]
select_expr, ...
[FROM table_references
[GROUP BY {col_name | expr | position}
[ASC | DESC], ... [WITH ROLLUP]]
[HAVING where_condition]
[ORDER BY {col_name | expr | position}
[ASC | DESC], ...]
[LIMIT {[offset,] row_count | row_count OFFSET offset}]
[PROCEDURE procedure_name(argument_list)]
[INTO OUTFILE 'file_name' export_options
| INTO DUMPFILE 'file_name']
[FOR UPDATE | LOCK IN SHARE MODE]]
SELECT 문은 하나 이상의 테이블에서 선택된 레코드들을 가져오기 위해 사용된다. 13.2.7.2 “UNION”과 13.2.8

:::MySQL Korea:::
“Subquery”부분을 참조 하라.
가장 빈번하게 사용되는 SELECT문의 절은 다음과 같다: The most commonly used clauses of SELECT statements are
these:
● 각 select_expr 는 가져오려는 컬럼을 가리킨다. 적어도 하나의 select_expr을 사용해야 한다.

● table_references 는 레코드를 가져오려는 하나 이상의 테이블을 가리킨다. 이 문법은 Section 13.2.7.1, “JOIN ”에서
자세히 설명된다.
● WHERE 절은 레코드가 선택 되기 위한 하나의 혹은 여러 개의 조건을 가리킨다. where_condition 는 선택될 각 레코드에
대한 참 값을 조사한다. WHERE 절이 없는 경우 모든 레코드를 가져온다..
WHERE 절에서 MySQL이 제공하는 어떤 함수나 연산자를 사용하여도 된다. 단지 예외가 되는 것은12장 “기능과 오퍼
레이터” 을 참조하라.
SELECT는 어떤 테이블에 대한 참조 없이도 레코드를 가져오는데 사용될 수 있다.
예를 들면:
mysql> SELECT 1 + 1;
-> 2
어떤 테이블도 참조 되지 않는 상황에서는 dummy 테이블을 의미하는 DUAL 을 명시할 수 있다.:
mysql> SELECT 1 + 1 FROM DUAL;
-> 2
DUAL 은 FROM 절을 필요로 하는 다른 데이터베이스 서버들과의 호환성을 한 것이다. MySQL은 어떤 테이블도 참조 되지 않으
면 그 저을 필요로 하지 않는다.
일반적으로 상용되는 절들은 문법 표현에서 보여지는 순서대로 정확하게 주어져야 한다. 예를 들면 HAVING절은 GROUP BY절
뒤에 와야 하고 ORDER BY절 앞에 위치 해야 한다. INTO 절은 문 앞에 위치 하거나 FROM절 바로 앞에 위치 할 수 있다.
● select_expr 는 AS alias_name를 사용하여 하나의 alias로 사용될 수 있다. Alias는 문장의 컬럼 이름으로서 사용되며
GROUP BY, ORDER BY 혹은 HAVING절들 안에서 사용될 수 있다. 예를 들면
SELECT CONCAT(last_name,', ',first_name) AS full_name

FROM mytable ORDER BY full_name;
AS 키워드는 select_expr를 alias로 할 때 선택적이다. 앞의 예제는 다음과 같이 사용될 수 있다.:

:::MySQL Korea:::
SELECT CONCAT(last_name,', ',first_name) full_name

FROM mytable ORDER BY full_name;
그러나 AS가 선택적이기 때문에 select_expr 사용시 콤마를 잊는다면 사소한 문제가 발생 할 수 있다. 즉 MySQL은 두
번째 것을 alias 이름으로 해석한다. 다음 예제는columnb 이 alias이름으로 해석되는 것이다.:
SELECT columna columnb FROM mytable;
이러한 이유로 컬럼 alias를 명시 할 때는 AS를 쓰는 습관을 갖도록 하는 것이 좋다.
● WHERE 절에서 컬럼 alias를 사용하는 것은 허용되지 않는데 이는 WHERE절이 수행될 때 컬럼 값이 아직 결정 되지 않았

을 수도 있기 때문이다. 이에 대한 사항은 A.5.4, “컬럼 알리아스의 문제점”을 참조하라.
● FROM table_references 절은 레코드를 가져올 하나 혹은 그 이상의 테이블을 지정한다. 만약 하나 이상의 테이블을 지정
려면 JOIN 을 해야 한다. JOIN 문에 관한 정보는 13.2.7.1장 “JOIN ”을 참조 하라. 지정된 각 테이블을 위해서는 선택적
으로 하나의 alias를 명시 할 수 있다.
tbl_name [[AS] alias]

[{USE|IGNORE|FORCE} INDEX (key_list)]
어떻게 인덱스 들을 선택하는지에 관한 최적화기 힌트를 주기 위한 USE INDEX, IGNORE INDEX, FORCE INDEX 의
사용은 13.2.7.1장 “JOIN ”을 참조하라.
MySQL로 하여금 테이블 스캔보다 key 스캔을 하도록 하는 대안적인 방법으로 SET max_seeks_for_key=value 를 사
용할 수 있다. 이에 대한 사항은 5.2.2장 “서버 시스템 변수”를 참조 하라.
● 여러분은 기본 데이터베이스안에서 tbl_name 이나 테이블을 명시하는db_name.tbl_name 을 이용 하여 하나의 테이블을

참조할 수 있다. 여러분은 컬럼 참조를 위해 col_name, tbl_name.col_name, 혹은 db_name.tbl_name.col_name를 사용
할 수 있다. 여러분은 참조가 모호 하지 않는 한 컬럼 참조에 대한 tbl_name 이나 db_name.tbl_name prefix를 지정할 필
요가 없다. 이에 대한 내용은 9.2.1장 “Identifier Qualifiers”를 참조하라. 하나의 테이블 참조는 tbl_name AS
alias_name 이나 tbl_name alias_name를 사용하여 alias로 사용될 수 있다.
SELECT t1.name, t2.salary FROM employee AS t1, info AS t2

WHERE t1.name = t2.name;
SELECT t1.name, t2.salary FROM employee t1, info t2

WHERE t1.name = t2.name;

:::MySQL Korea:::
● 출력을 위해 선택된 컬럼 들은 컬럼 이름들과 alias혹은 컬럼의 위치 등을 사용하는ORDER BY 와 GROUP BY절 안에서

참조 될 수 있다. 컬럼의 위치는 정수 값으로 1부터 시작한다.
SELECT college, region, seed FROM tournament

ORDER BY region, seed;
SELECT college, region AS r, seed AS s FROM tournament

ORDER BY r, s;
SELECT college, region, seed FROM tournament

ORDER BY 2, 3;
역 방향으로 정렬하기 위해서 여러분이 정열하려는 ORDER BY 절 안에 컬럼의 이름을 위한 DESC 키워드를 추가하라.
기본 값은 ascending 순서이며 이것은 ASC 키워드를 사용하여 명시적으로 지정될 수 있다.
컬럼 위치의 사용은 그 문법이 SQL 표준에서 없어졌으므로 사용하지 말아야 한다.
● GROUP BY을 사용하면 결과 레코드들은 같은 컬럼들에 대해 ORDER BY 를 가진 것처럼 GROUP BY 컬럼들에 따라 저

열 된다. GROUP BY 가 유발하는 정렬시 overhead를 피하기 위해서는 ORDER BY NULL 을 추가하라.
SELECT a, COUNT(b) FROM test_table GROUP BY a ORDER BY NULL;
● MySQL는 GROUP BY 절을 확장하여 절안에서 명명된 컬럼들 뒤에 ASC 와 DESC 를 지정할 수 있다. extends the
GROUP BY clause so that you can also specify ASC and DESC after columns named in the clause:
SELECT a, COUNT(b) FROM test_table GROUP BY a DESC;
● MySQL은 GROUP BY절에서 언급되지 않은 필드의 선택을 허용하기 위해 GROU BY의 사용을 확장한다. 여러분이 질의
로부터 바라는 결과를 얻지 못한다면 12.10장 “GROUP 절과 함께 사용하는 함수들과 modifier들”.
● GROUP BY 는 WITH ROLLUP modifier를 허용한다. 12.10.2장 “GROUP BY Modifiers”부분을 참조하라.
● 최적화 없이 아이템들이 클라이언트로 보내지기 전데 HAVING 절이 가장 마지막에 적용 된다
● MySQL 5.0.2이전에는 HAVING 절은 SELECT 리스트 안의 select_expr안에서 명명된 alias나 어떤 컬럼도 참조 할 수

:::MySQL Korea:::
있다. SQL 표준은 HAVING은 GROUP BY절 안의 컬럼들혹은 aggregate 함수에서 사용되는 컬럼 들에 대해서만 참조해
야 한다는 것을 요구한다. 표준과 MySQL 모두를 수용하기 위해서-SELECT리스트에서 컬럼들을 참조할수 있는 특별 행
동자,MySQL 5.0.2과 그 이상의 버전은 SELECT list에서 컬럼들이나 GROUP BY절안의 컬럼들, 외부 sub질의안에서의
컬럼, aggregate 함수들을 참조 하는 것을 허용한다
● 예를 들면 다음 예문은 MySQL5.0.2에서 동작하지만 이전 버전에서는 에러가 발생한다:
mysql> SELECT COUNT(*) FROM t GROUP BY col1 HAVING col1 = 2;
HAVING절이 모호한 컬럼을 참조할 경우 경고가 발생한다. 다음 문장 에서col2가 컬럼 이름과 alias모두로 사용되고
있기 때문에 모호해 진다.
SELECT COUNT(col1) AS col2 FROM t GROUP BY col2 HAVING col2 = 2;

우선권이 표준 SQL에 주어지므로 HAVING 컬럼 이름이 GROUP BY와 출력 컬럼 리스트 안에서 alias된 컬럼으로 사용
될 경우, 우선권은 GROUP BY 컬럼 안에서 그 컬럼에게 주어진다.
● WERE절안에서 사용되어야 하는 아이템들을 위해 HAVING을 사용하지 말라. 예를 들면 다음과 같이 사용하지 말라:
SELECT col_name FROM tbl_name HAVING col_name > 0;

대시 다음과 같이 사용하라:
SELECT col_name FROM tbl_name WHERE col_name > 0;
● HAVING 절은 집합 함수들을 참조 할수 있으나 WHERE절을 할 수 없다.:
SELECT user, MAX(salary) FROM users

GROUP BY user HAVING MAX(salary) > 10;
(이것은 몇몇 구 MySQL에서는 동작 하지 않았다.)
● LIMIT 절은 SELECT문에 의해 리턴된 레코드의 수를 제한 하기 위해 사용될 수 있다. LIMIT는 하나 혹은 두개의 숫자 변

수를 가지는데 이때 모두 양의 정수 제한을 가져야 한다. (prepared 문 사용시는 제외 된다.).
두 개의 argument중 첫 번째는 리턴될 첫 레코드의 offset이고 두번째는 리턴될 최대 레코드 수를 지정한다. 초기 레코드
의 offset은 0이다
SELECT * FROM tbl LIMIT 5,10; # Retrieve rows 6-15

:::MySQL Korea:::
어떤 offset에서 결과 집합의 끝에 이르기까지 모든 레코드를 가져오기 위해서는 두 번째 파라미터에 큰 수를 쓸 수 있다.

아래 문장은 96번째에서 마지막까지 모든 레코드를 가져 온다.:
SELECT * FROM tbl LIMIT 95,18446744073709551615;
한 변수만 있는 경우 그 값은 결과 집합의 시작에서부터 리턴될 레코드의 수를 지정한다.
SELECT * FROM tbl LIMIT 5; # Retrieve first 5 rows
즉, LIMIT row_count 는 LIMIT 0, row_count과 동일하다.
prepared 문을 위해 placeholder를 사용 할 수 있다. (MySQL 5.0.7 부터 제공된다.)다음 SQL문은 tbl테이블로부터 하
나의 레코드를 리턴 하게 된다.
SET @a=1;
PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?';
EXECUTE STMT USING @a;
다음 문장은 tbl테이블의 두번째에서 6번째에 이르는 레코드를 리턴한다.
SET @skip=1; SET @numrows=5;
PREPARE STMT FROM 'SELECT * FROM tbl LIMIT ?, ?';
EXECUTE STMT USING @skip, @numrows;
PostgreSQL과의 호환성을 위해 MySQL 은LIMIT row_count OFFSET offset 을 지원한다.
● SELECT의SELECT ... INTO OUTFILE 'file_name' 폼은 선택된 레코드들을 한 파일에 기록한다. 이 파일은 서버 호스
트에서 생성되므로 이 문을 사용하기 위해서는 FILE 권한을 가지고 있어야 한다. file_name 은 존재하지 않는 파일 일 수
도 있다. 이는 /etc/passwd 나 데이터베이스 테이블과 같은 파일들을 삭제 하지 못하게 한다. MySQL 5.0.19부터는
character_set_filesystem 시스템 변수가 파일 이름의 해석을 조절 한다.
SELECT ... INTO OUTFILE 문은 테이블을 서버에 있는 한 텍스트 파일에 빠르게 쎃넣게 하기 위해 주로 사용된다. 여
러분이 서버가 아닌 클라이언트 호스트에 결과 파일을 생성 하고자 한다면 SELECT … INTO OUTFILE을 사용 할 수 없
다. 이 경우, mysql –e “SELECT … “ > file_name문을 파일을 클라이언트에 생성하기 위해 사용해야 한다.
SELECT ... INTO OUTFILE는 LOAD DATA INFILE의 보완이다. 즉, SQL문의 export_options 부분의 문법은
LOAD DATA INFILE과 함께 사용되는 같은 FIELDS와 LINES절로 구성된다. 이에 대한 내용은 13.2.5장 “LOAD
DATA INFILE”을 참조하라.
FIELDS ESCAPED BY 은 특수 문자들의 사용 방법을 제어한다. 만일 FIELDS ESCAPED BY 문자가 비어 있지 않으
면 output에서 다음 문자들에 선행되는 하나의 prefix로 사용된다.

:::MySQL Korea:::
❍ FIELDS ESCAPED BY 문자
❍ FIELDS [OPTIONALLY] ENCLOSED BY 문자
❍ FIELDS TERMINATED BY 의 첫 문자와 LINES TERMINATED BY 값
❍ ASCII NUL (제로값의 바이트; 실제로 이스케이프 문자 다음에 따라오는 것은 ASCII ‘0’이며, 제로값의 바이
트는 아니다)
FIELDS TERMINATED BY, ENCLOSED BY, ESCAPED BY, 혹은 LINES TERMINATED BY 문자들 은 escaped되
어 여러분은 그 파일을 신뢰성 있게 다시 읽을 수 있다. ASCII NUL pager들로 보기 쉽게 escaped된다.
결과 파일은 SQL문법을 따를 필요가 없으며 어느 것도 escape될 필요가 없다.
FIELDS ESCAPED BY 문자가 empty이면 어떤 문자도 escape될 수 없으며 NULL은 ￦N이 아닌 NULL로 출력된다.
Empty escape문자를 명시하는 것은 좋은 생각이 아니며, 특히 데이터 안의 필드 값이 방금 나열된 문자들 중 하나를 포
함하고 있을 때에는 더욱 좋지 않다.
다음은 많은 프로그램에서 사용되는 콤마로 구별되는 값을 가진 파일을 생성하는 예문이다:
SELECT a,b,a+b INTO OUTFILE '/tmp/result.txt'
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY '￦n'
FROM test_table;
● INTO OUTFILE대신 INTO DUMPFILE을 사용하면 MySQL은 어떤 컬럼 이나 레코드의 종료와 escape처리 없이, 파일
에 오직 하나의 레코드를 기록 한다. 이것은 여러분이 파일에 BLOB값을 저장 할 때 유용하다.If you use INTO
DUMPFILE instead of INTO OUTFILE, MySQL writes only one row into the file, without any column or line
termination and without performing any escape processing. This is useful if you want to store a BLOB value in
a file.
● 주의:INTO OUTFILE이나 INTO DUMPFILE에 의해서 생성된 파일은 서버 호스트상의 모든 사용자에 의해 쓰여 질 수
있다. 이 이유는 MySQL 서버가 계정을 가진 사용자 외에 다른 어떤 사용자에 의해 소유된 파일을 생성 할 수 없기 때문이
다. (어떤 이유에서건 mysqld를 root로 실행 하지 말라) 그 그 파일은 모두에게 쓰기 가능해야 하며 따라서 여러분은 그 내
용을 변경 할 수 있다.
● 이 장 도입부에 있는 SELECT문은 그 문장의 끝부분에서 INTO 절이 존재 한다. FROM 절에 선행하여 INTO OUTFILE
이나 INTO DUMPFILE을 직시 사용하는 것도 가능하다.
● PROCEDURE 절은 결과 집합에서 처리 해야 할 프로시져를 명명한다. 이에 대한 예는 24.3.1장 “프로시저 분석”부분
을 참조 하라.

:::MySQL Korea:::
● 페이지 혹은 레코드 잠금을 사용하는 저장엔진과 함께 FOR UPDATE를 사용한다면 질의에 의해 조사되는 레코드들은 현
재 트랜잭션이 끝날때까지 쓰기 잠금 상태가 된다. ROCK IN SHARE MODE의 사용은 검사된 레코드들을 읽도록 다른 트
랜잭션에 허용하나 업데이트와 삭제는 할 수 없는 공유 잠금을 설정한다. 이에 대한 내용은 14.2.10.5장 “SELECT …
FOR UPDATE 와 SELECT … LOCK IN SHARE MODE 잠금 읽기”부분을 참조 하라.
SELECT키워드와 더불어 그 SQL문의 수행에 영향을 주는 많은 옵션들을 사용할 수 있다.

ALL, DISTINCT, 그리고 DISTINCTROW 옵션은 레코드가 중복되면 리턴되어야 하는지를 명시하는 옵션이다. 이들 옵션들중 어
느 것도 사용되지 않으면 기본값으로 ALL이 사용된다. DISTINCT 와 DISTINCTROW 는 동의 어이며 결과 집합으로부터 중복
된 레코드를 삭제 하도록 한다.
HIGH_PRIORITY, STRAIGHT_JOIN, 와 SQL_과 함께 시작하는 옵션들은 MySQL 의 확장이다.
● HIGH_PRIORITY 는 테이블을 업데이트 하는 문장보다 SELECT에 높은 priority를 준다. 여러분은 한번에 그리고 매우
빨리 처리 해야 할 질의에 이것을 사용해야 한다. 읽기를 위해 테이블이 잠긴 동안 수행된 SELECT HIGH_PRIORITY 질
의는 테이블이 free상태가 되길 기다리는 업데이트 문이 있을 지라도 수행 된다.
HIGH_PRIORITY 는 UNION의 일부분인 SELECT문과 같이 사용될 수 없다.
● STRAIGHT_JOIN 는 최적화기로 하여금 FROM절에 열거된 순서대로 테이블들을 join하도록 한다. Optimizer가 바람직
하지 않은 순서로 테이블을 joint할 경우 이 질의 속도를 높이기 위해 사용할 수 있다. 7.2.1장 “EXPLAIN 과 최적화 질
의” 부분을 참조 하라. STRAIGHT_JOIN은 table_references 리스트에서 사용될 수 있다. 13.2.7.1장 “JOIN”부분을
참조 하라..
● SQL_BIG_RESULT 는 결과 집합이 많은 레코드를 갖는 다는 것을 optimizer에게 말하기 위해 GROUP BY나 DISTINCT
와 함께 사용될 수 있다. 이 경우, MySQL은 필요할 경우 직접 디스크 기반 임시 테이블을 사용하고 GROUP BY 상의 키
로 임시 테이블을 정렬한다.
● SQL_BUFFER_RESULT 는 결과가 임시 테이블에 저장되도록 한다. 이것은 MySQL이 테이블의 잠금을 빨리 해지 하하
는 것을 도우며 클라이언트에게 결과를 보내는데 오랜 시간이 걸리는 경우에도 도움을 준다.
● SQL_SMALL_RESULT 는 결과 집합이 작다는 것을 optimizer에게 말해주기 위해 GROUP BY나 DISTINCT와 함께 사
용될 수 있다. 이 경우 MySQL은 정렬을 사용하는 대신 결과 테이블을 저장하기 위해 빠른 임시 테이블을 사용한다. 이것
은 보통 는 필요하지 않다.
● SQL_CALC_FOUND_ROWS 은 MySQL이 LIMIT절과 상관 없이, 얼마나 많은 레코드가 결과 집합에 있어야 하는지 계
산 하도록 한다. 레코드의 수는 SELECT FOUND_ROWS()로 얻어질수 있다. 12.9.3장 “정보 함수”부분을 참조 하라.

:::MySQL Korea:::
● SQL_CACHE 는 MySQL으로 하여금 여러분이 query_cach_type 값으로 2 혹은 DEMAND를 사용하는 경우 질의 cache

안에 질의 결과를 저장 하도록 한다. UNION이나 sub-질의를 사용하는 질의에 대해서는 이 옵션은 SELECT에 영향을 준
다. 5.14장 “MySQL 질의 cache”부분을 참조 하라.
SQL_NO_CACHE 는 MySQL이 질의 결과를 질의 cache에 저장하지 못하게 한다. 5.14장 “MySQL Query Cache”부분을 참
조 하라. UNION이나 sub 질의를 사용하는 질의에 대해선, 이 옵션이 질의의 SELECT에 영향을 준다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.7.1. JOIN Syntax
13.2. 데이터 조작 SQL문 MySQL 은 SELECT문 과 다중 테이블 DELETE 그리고 UPDATE문의 table_reference 부분을 위해 다음과 같이 JOINT을 지
13.2.7 SELECT 원한다:

table_references:
13.2.7.2 UNION
table_reference [, table_reference] ...
table_reference:
table_factor
| join_table
table_factor:
tbl_name [[AS] alias]
[{USE|IGNORE|FORCE} INDEX (key_list)]
| ( table_references )

:::MySQL Korea:::
| { OJ table_reference LEFT OUTER JOIN table_reference
ON conditional_expr }
join_table:
table_reference [INNER | CROSS] JOIN table_factor [join_condition]
| table_reference STRAIGHT_JOIN table_factor
| table_reference STRAIGHT_JOIN table_factor ON condition
| table_reference LEFT [OUTER] JOIN table_reference join_condition
| table_reference NATURAL [LEFT [OUTER]] JOIN table_factor
| table_reference RIGHT [OUTER] JOIN table_reference join_condition
| table_reference NATURAL [RIGHT [OUTER]] JOIN table_factor
join_condition:
ON conditional_expr
| USING (column_list)
하나의 테이블 참조는 하나의 JOIN 표현으로 알려져 있다.

:::MySQL Korea:::
table_factor 구문은 SQL 표준에 비해 확장 되었다. 후자는 한 쌍의 괄호 안의 리스트가 아닌 단지 table_reference를 받아들인

다.
우리가 table_reference 아이템의 한 리스트 안의 각 콤마를 inner join과 동등하게 여긴다면 이것은 convervative extension이
다. 예를 들면:
SELECT * FROM t1 LEFT JOIN (t2, t3, t4)
는 아래 문장과 동등하다:
SELECT * FROM t1 LEFT JOIN (t2 CROSS JOIN t3 CROSS JOIN t4)
MySQL에서, CROSS JOIN 은 INNER JOIN과 동등하다. 표준 SQL에서는 그렇지 않다. INNER JOIN은 ON 절과 함께 쓰이며
CROSS JOIN은 그렇지 않다.
5.0.1이전의 MySQL에서는 table_references안의 괄호들이 생략되고 모든 join 연산들은 왼쪽으로 그룹지어진다. 일반적으로 괄
호들은 단지 inner join연산을 포함하는 join 표현 안에서 무시 될 수 있다. 5.0.1부터는 nested join이 허락된다 (7.2.10장
“nested join optimization”부분을 참조하라.
join연산 에서 좀더 많은 변경들이 5.0.12에서 이루어 졌으며 MySQL을 표준 SQL을 따르도록 했다. 이들 변경들은 이 장의 후반
부에서 설명된다.
다음 리스트는 join을 쓸 때 유념 해야 할 일반적인 사실들을 설명한다.
● 테이블 참조는 tbl_name as alias_name 이나 tbl_name alias name을 사용하여 alias될 수 있다.
SELECT t1.name, t2.salary

:::MySQL Korea:::
FROM employee AS t1 INNER JOIN info AS t2 ON t1.name = t2.name;
SELECT t1.name, t2.salary
FROM employee t1 INNER JOIN info t2 ON t1.name = t2.name;
● INNER JOIN 과 콤마(,)는 join 조건의 결여로 의미론적으로 동등하다. 양자는 명시된 테이블 사이에서 데카르트 곱을 만
들어 낸다. (즉, 첫 번째 테이블의 각각 모든 레코드는 두 번째 테이블의 각각 모든 레코드와 join된다.)
그러나 콤마 연산자의 서열은 INNSER JOIN, CROSS JOIN, LEFT JOIN등 보다 낮다. Join 조건이 있는 경우 다른
join 형들과 콤마를 혼합하면 Unknown column ‘col_name’ in ‘on clause”의 형태의 에러가 발생한다. 이 문제
처리에 관한 정보는 이 장의 후반부에 다루어진다.
● ON 조건은 WHER 절에서 사용될 수 있는 형태의 조건 표현이다. 일반적으로 테비블들을 어떻게 join하는 지를 명시하는
조건을 위해선 ON조건을 결과 집합에서 어떤 레코드를 원하는 가에 대한 제한을 위해서는 WHERE절을 사용해야 한다.
● LEFT JOIN에서 ON이나 USING부분에서 오른쪽 테이블과 매칭 되는 레코드가 없는 경우 모든 컬럼들이 NULL로 설정
된 레코드가 오른쪽 테이블을 위해 사용된다. 다른 테이블과 대응을 갖지 못하는 테이블에서 레코드를 찾기 위해 이 사실
을 사용할 수 있다.
SELECT table1.* FROM table1
LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;
이 예제는 table2에 나타나지 않은 id 값을 가지고 table1에서 모든 레코드를 찾는다.( 이것은 table1에 있는 모든 레코

드가 table2에 있는 어떤 것과도 일치 하지 않는다.) 이것은 table2.id가 NOT NULL로 선언 되었음을 의미한다. 7.2.9
장 “LEFT JOIN과 RIGHT JOIN 최적화” 부분을 참조 하라.
● USING(column_list) 절은 양 테이블들에 존재해야 하는 컬럼들을 지정한다. 테이블 a와 b가 컬럼 c1, c2 그리고 c3를 포

:::MySQL Korea:::
함하고 있다면 이어지는 join은 두 테이블의 컬럼들을 비교한다.
a LEFT JOIN b USING (c1,c2,c3)
● 두 테이블의 NATURAL [LEFT] JOIN 은 두 테이블에 존재하는 모든 컬럼을 지정하는 USING절의 INNSER JOIN 이나
LEFT JOIN과 의미적으로 동일하도록 정의 된다.
● RIGHT JOIN 는 LEFT JOIN과 유사하게 작용한다. LEFT JOIN. 데이터베이스 들 간에 이식 가능한 코드를 유지 하기 위
해서는 RIGHT JOIN보다 LEFT JOIN을 사용하는 것이 좋다.
● JOIN문 설명에서 보여지는 { OJ ... LEFT OUTER JOIN ...} 문은 ODBC와의 호환성을 위해 존재 한다. 이 문장에서 중괄
호는 정확히 쓰여져야 하는데 다른 구문 표현들에서 보여지는 포괄적 의미로 사용되는 것과는 다르다.
● STRAIGHT_JOIN 은 왼쪽 테이블이 오른쪽 테이블보다 항상 먼저 읽힌 다는 점을 제외하면 JOIN과 동일하다. JOIN
optimizer가 테이블을 잘못된 순서로 놓을 경우에 사용될 수 있다.
다음은 JOIN연산을 사용하는 예문들이다:
SELECT * FROM table1, table2;
SELECT * FROM table1 INNER JOIN table2 ON table1.id=table2.id;
SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id;
SELECT * FROM table1 LEFT JOIN table2 USING (id);
SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id

:::MySQL Korea:::
LEFT JOIN table3 ON table2.id=table3.id;
테이블로부터 정보를 가져올 때 MySQL이 사용할 인덱스에 대한 힌트를 제공 할 수 있다. USE INDEX (key_list)를 사용하여
MySQL이 테이블의 레코드들을 찾기 위해 가능한 인덱스들중 단지 하나만 사용하도록 할 수 있다. 선택적 구문인 IGNORE
INDEX(key_list)문은 MySQL이 특정 인덱스를 사용하지 못하도록 할 수 있다. 이러한 힌트들은 EXPLAIN문이 MySQL이 인덱
스들 중 잘못된 인덱스를 사용하고 있다는 것을 보여준다면 유용하다.
여러분은 FORCE INDEX 문을 사용 할 수 있는데 이것은 USE INDEX(key_list)와 같이 작용하며 테이블 스캔이 추가적이다. 즉,
테이블에서 레코드를 찾기 위해 주어진 인덱스들을 사용할 수 없는 경우에만 테이블 스캔이 사용될 수 있다.
USE INDEX, IGNORE INDEX와FORCE INDEX 문은 테이블에서 레코드를 어떻게 찾고 JOIN을 하기 위해 어떻게 해야 하는지
MySQL이 결정 할 때에 어떤 인덱스들이 사용될 것인지에 영향을 미친다. 이들은 ORDER BY 나 GROUP BY를 결정할 때 사용할
인덱스에는 영향을 주지 않는다.
USE KEY, IGNORE KEY 와 FORCE KEY 는 USE INDEX, IGNORE INDEX, FORCE INDEX 와 동일하다.
예:
SELECT * FROM table1 USE INDEX (key1,key2)
WHERE key1=1 AND key2=2 AND key3=3;
SELECT * FROM table1 IGNORE INDEX (key3)
WHERE key1=1 AND key2=2 AND key3=3;
MySQL 5.0.12에서 변경된 JOIN연산
MySQL 5.0.12에서 natural joins 과 외부 join 변수들을 포함한 USING을 사용한 join은 SQL:2003 표준에 따라 처리 된다. 그

:::MySQL Korea:::
목적은 MySQL의 구문들과 의미들을 SQL:2003에 따라 NATURAL JOIN과 JOIN… USING 을 조절하는 것이다. 그러나 이들
join연산에서의 변화들은 어떤 join들에 대해서는 다른 출력물을 결과로 내놓을 수 있다. 또한 이전 버전들에서 정확히 동작하는 것
처럼 보여진 몇몇 질의들이 표준에 맞게 새롭게 씌여 져야만 한다.
이들 변화들은 다섯 가지 주요 측면을 가지고 있다:
● MySQL이 NATURAL 혹은 USING Join 연산에서 결과 컬럼을 결정하는 방법(이는 전체 FROM절의 결과이다.)
● SELECT * 과 SELECT tbl_name.* 의 선택된 컬럼 들의 리스트로의 확장.
● NATURAL과 USING join에서 컬럼 이름들의 결정.
● NATURAL 이나 USING 에서 JOIN ... ON. 으로의 전이
● JOIN…ON에서 ON조건에 있는 컬럼 이름의 결정.
다음의 리스트는 join 연산에 관한 5.0.12에서의 변화의 몇 가지 효과에 관한 상세한 정보를 제공한다. “previously”의 의미는
“MySQL 5.0.12 이전 “ 을 의미한다.
● NATURAL 이나 USING join의 컬럼들은 이전 버전과 다를 수 있다. Redundant한 결과들은 더 이상 나타나지 않으며
SELECT *확장에서의 컬럼 순서는 전과 다를 수 있다.
다음 문장들을 고려해 보자:
CREATE TABLE t1 (i INT, j INT);
CREATE TABLE t2 (k INT, j INT);
INSERT INTO t1 VALUES(1,1);
SELECT * FROM t1 NATURAL JOIN t2;
SELECT * FROM t1 JOIN t2 USING (j);

:::MySQL Korea:::
이전 버전에서 문장들은 다음 결과를 만들어 낸다.
+------+------+------+------+
|i |j |k |j |
+------+------+------+------+
| 1| 1| 1| 1|
+------+------+------+------+
+------+------+------+------+
|i |j |k |j |
+------+------+------+------+
| 1| 1| 1| 1|
+------+------+------+------+
처음 SELECT문에서는 컬럼 i가 양쪽 테이블들에 나타나며 표준 SQL에 따라 join 컬럼이 되는데 output에서 단지 한번

만 나타 나야 한다. 두번째 SELECT문 역시 유사하게 컬럼 j가 USING절 안에서 몇 명되고 output으로 한번만 나와야 한
다. 그러나 두가지 경우 모두 redundant 컬럼이 제거 되지 않는다. 또한 컬럼들의 순서도 표준 SQL과 정확히 일치 하지
않는다.
이제 결과물들은 아래와 같은 결과를 생산 한다.:
+------+------+------+
|j |i |k |

:::MySQL Korea:::
+------+------+------+
| 1| 1| 1|
+------+------+------+
+------+------+------+
|j |i |k |
+------+------+------+
| 1| 1| 1|
+------+------+------+
Redundant 컬럼이 제거 되고 컬럼 순서가 정확하게 표준 SQL을 따른다.:
❍ 첫번째로, 두개의 join된 테이블들의 일반 컬럼들을 첫번째 테이블의 컬럼 들 순서에 따라 합체 시킨다.

❍ 두번째로, 컬럼들은 첫 번째 테이블에서의 순서대로 유일하게 되어야 한다.
❍ 세번째로, 컬럼들은 두 번째 테이블에서의 순서대로 유일하게 되어야 한다.
두개 일반 컬럼들을 대체하는 하나의 결과 컬럼은 COALESCE연산을 통해정의 된다. 즉 t1.a와 t2.a의 단일 join 컬럼
은 a로 정의 되는데 구문은
a = COALESCE(t1.a, t2.a)과 같다. where:
COALESCE(x, y) = (CASE WHEN V1 IS NOT NULL THEN V1 ELSE V2 END)
만일 join연산이 다른 join연산이라면 그 join의 결과 컬럼들은 join된 테이블들의 모든 컬럼의 연결로 이루어 진다. 이것
은 이전 버전의 MySQL와 동일하다.
coalesced컬럼의 정의에 대한 결과는 그 컬럼이 두개의 컬럼중 하나가 항상NULL이라면 coalesced컬럼은 NULL이
아닌 컬럼의 값을 포함한다. 두 컬럼이 NULL이거나 NULL이 아닌경우, 양쪽 일반 컬럼들은 같은 값을 갖게 되고

:::MySQL Korea:::
coalesced 컬럼의 값으로 어떤 것이 선택 되었는지는 문제가 되지 않는다. 이것을 해석하는 가장 간단한 방법은 outer
join의 coalesced컬럼이 JOIN의 JOIN의 inner테이블의 일반 컬럼에 의해 재 표현 된다. 다음 두개의 테이블 t1(a,b)
와 t2(a,c)이 다음과 같은 값을 가지고 있다면::
t1 t2
---- ----
1x 2z
2y 3w
그러면:
mysql> SELECT * FROM t1 NATURAL LEFT JOIN t2;
+------+------+------+
|a |b |c |
+------+------+------+
| 1|x | NULL |
| 2|y |y |
+------+------+------+
a컬럼의 값은 t1.a를 포함하고 있다.
mysql> SELECT * FROM t1 NATURAL RIGHT JOIN t2;

:::MySQL Korea:::
+------+------+------+
|a |c |b |
+------+------+------+
| 2|y |y |
| 3|z | NULL |
+------+------+------+
여기에서 컬럼 a는 t2.a의 값을 포함 하고 있다.

이들 결과들을 다른 JOIN…ON을 가진 동등한 질의들과 비교하면
mysql> SELECT * FROM t1 LEFT JOIN t2 ON (t1.a = t2.a);
+------+------+------+------+
|a |b |a |c |
+------+------+------+------+
| 1|x | NULL | NULL |
| 2|y | 2|y |
+------+------+------+------+
mysql> SELECT * FROM t1 RIGHT JOIN t2 ON (t1.a = t2.a);
+------+------+------+------+

:::MySQL Korea:::
|a |b |a |c |
+------+------+------+------+
| 2|y | 2|y |
| NULL | NULL | 3|z |
+------+------+------+------+
● 이전 버전에서, USING절은 다음 컬럼들을 비교 하기 위해 ON절로 다시 쓰여 질 수 있다. 예를 들면, 다음 두 절들은 의미

적으로 동일하다.:
a LEFT JOIN b USING (c1,c2,c3)
a LEFT JOIN b ON a.c1=b.c1 AND a.c2=b.c2 AND a.c3=b.c3
이제 두 절들은 더 이상 같지 않다:
❍ join조건을 어떤 레코드가 만족 시키는지를 결정하는 것과 관련하여 두가지 모두의 join은 의미적으로 동일하다.
❍ SELECT * 확장을 위해 어떤 컬럼을 display할지 결정하는 것과 관련하여 두개의 join은 의미적으로 동일 하지 않
다. USING join은 ON join이 모든 테이블로부터 모든 컬럼을 선택하는데 반해, 컬럼들 중 coalesced 값을 선택한
다. USING join에 선행자로 SELECT* 는 이들 값들을 선택한다:
COALESCE(a.c1,b.c1), COALESCE(a.c2,b.c2), COALESCE(a.c3,b.c3)
ON join을 위해 SELET * 문이 이들 값들을 선택한다.

:::MySQL Korea:::
a.c1, a.c2, a.c3, b.c1, b.c2, b.c3
inner join과 함께 COALESCE(a.c1,b.c1) 는 두 컬럼 모두가 같은 값을 갖게 되므로 a.c1과 b.c1은 같게 된다.

Out join 에서 두 컬럼들중 하나가 NULL이 될 수 있다. 그 컬럼은 결과에서 삭제 될 것이다.
● 다중 natural join에 대한 평가는 질의를 다시 쓰도록 요구하는 NATURAL이나 USING join의 결과에 영향을 미치는 매
우 중요한 방법 에서 다르다. 예를 들어 세개의 테이블 t1(a,b), t2(c,b) 그리고 t3(a,c)가 있고 각각의 테이블은 t1(1,2),
t2(10,2) 그리고 t3(7,10)으로 하나의 레코드를 갖는다고 가정하자. 또한 세개의 테이블들에서 다음과 같이 NATURAL
JOIN을 갖는다고 가정해보자:
SELECT ... FROM t1 NATURAL JOIN t2 NATURAL JOIN t3;
이전 버전의 MySQL에서는 그 문장이 nested join 인 (t1 NATURAL JOIN t2)이므로 두번째 JOIN의 연산 대상자는 t2
로 인식되었다. 결과적으로 t3의 컬럼들은 t2에서 일반 컬럼들로 체크되고 t3가 t1과 함께 일반 컬럼들을 갖는다면 이들
컬럼들은 equi-join컬럼 들로 사용되지 않는다. 따라서 이전버전의 MySQL에서는 선행적인 질의가 다음 equi-join으로
변환 된다.:
SELECT ... FROM t1, t2, t3
WHERE t1.b = t2.b AND t2.c = t3.c;
그 JOIN은 (t1.a = t3.a) 동등 질의 속성을 빠뜨리고 있다. 결과적으로 그것이 가져야 할 empty 결과를 갖지 못하고 하나
의 레코드를 생산한다. 정확한 동등 질의는 다음과 같다:
SELECT ... FROM t1, t2, t3
WHERE t1.b = t2.b AND t2.c = t3.c AND t1.a = t3.a;
여러분이 이전 버전과 현재 버전에서 같은 결과를 갖는 질의를 요구한다면 첫번째 동등 join으로 natural join을 다시 쓰도
록 하라.

:::MySQL Korea:::
● 이전 버전에서, 컴마 연산자(,)와 JOIN 연산자 모두는 같은 우선 순위를 가졌다. 따라서 join 연산 t1,t2 JOIN t3는 ((t1,
t2) JOIN t3)로 해석 되었다. 현재 버전은 JOIN이 좀더 높으며 따라서 그 SQL문은 (t1, (t2 JOIN t3))로 해석 된다. 이
변경은 ON절을 사용하는SQL문들에 영향을 주는데 그 절이 JOIN의 피 연산자 안에 있는 컬럼 들만을 참조 할 수 있고 우
선순위의 변화는 그들 피 연산자의 해석에 변화를 주기 때문이다.
예:
CREATE TABLE t1 (i1 INT, j1 INT);
SELECT * FROM t1, t2 JOIN t3 ON (t1.i1 = t3.i3);
이전 버전에서 SELECT는 t1,t2를 (t1,t2)와 같이 암시적 그룹으로 인식 하므로 문법적으로 맞다. 현재 버전에서는 JOIN
이 우선순위를 가지며 ON 절에 있는 피 연산자로 t2와 t3가 된다. t1.i1이 t2와 t3에 속한 컬럼 조건에 해당 하지 않으며
이는 Unknown column ‘t1.i1’ in ‘on clause’ 에러를 만들게 된다. 그 JOIN이 처리 되도록 하기 위해서는 처음 두
테이블을 괄호로 그룹을 만들어 주어야 하며 이렇게 되면 ON절의 피 연산자는 (t1,t2)와 t3가 된다:
SELECT * FROM (t1, t2) JOIN t3 ON (t1.i1 = t3.i3);
콤마 연산자의 사용을 피하고 JOIN연산을 대신 쓸 수 이다.
SELECT * FROM t1 JOIN t2 JOIN t3 ON (t1.i1 = t3.i3);

:::MySQL Korea:::
이 변경은 INNER JOIN, CROSS JOIN, LEFT JOIN, 그리고 RIGHT JOIN 와 콤마 연산자가 혼합된 SQL문에 적용 되
며 이들 모두는 콤마 연산자보다 높은 우선순위를 갖는다.
● 이전 버전에서 ON 절은 오른쪽에 있는 테이블 안에 있는 컬럼 들을 참조 할 수 있었으나 현재 버전에서는 오직 피 연산자

들만 참조 할 수 있다.
예:
CREATE TABLE t1 (i1 INT);
SELECT * FROM t1 JOIN t2 ON (i1 = i3) JOIN t3;
이전 버전에서 SELECT문은 맞는 표현이었으나 현재 버전에서는 Unknown column 'i3' in 'on clause' 에러와 함께 실패
한다. i3 컬럼이 t3 안에 없기 때문인데 이는 ON절의 피 연산자가 아니다. 이 문장은 다음과 같이 다시 쓰여져야 한다.
SELECT * FROM t1 JOIN t2 JOIN t3 ON (i1 = i3);
● NATURAL이나 USING join들 안에서 컬럼 이름 들의 결과는 이전 버전과 다르다. FROM절의 외부에 있는 컬럼 이름들
에 대해, MySQL은 이전 버전과 대비 되는 질의들의 집합을 다룬다. 즉, MySQL이 어떤 컬럼이 모호 하다는 에러를 공식적
으로 발생 시킬 경우, 그 질의는 정확히 다루어 진다. 이것은 MySQL이 이제 NATURAL 이나 USING join의 일반 컬럼 들
을 하나의 컬럼으로 다루기 때문이며 따라서 한 질의가 그런 컬럼 들을 참조할 경우 질의 compiler는 그것들을 모호하게
여기지 않는다.
예:
SELECT * FROM t1 NATURAL JOIN t2 WHERE b > 1;
이전 버전에서 이 질의는 ERROR 1052 (23000): Column 'b' in where clause is ambiguous 에러를 출력한다. 현재 버

:::MySQL Korea:::
전에서 질의는 다음과 같이 정확한 결과를 출력한다:
+------+------+------+
|b |c |y |
+------+------+------+
| 4| 2| 3|
+------+------+------+
SQL:2003표준과 비교하여 MySQL에서의 확장은 MySQL이 NATURAL이나USING join의 common 컬럼 들을 조절 할

수 있게 하였는데 이는 표준 SQL문에서는 허용되지 않는다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.7.2. UNION
13. SQL 문법(SQL Statement Syntax) SELECT ...

13.2.7 SELECT UNION [ALL | DISTINCT] SELECT ...

[UNION [ALL | DISTINCT] SELECT ...]
13.2.7.2 UNION
UNION 은 여러 개의 SELECT문을 하나의 결과 집합으로 결합 하기 위해 사용된다.
SELECT문에서 컬럼 이름들은 리턴될 결과에 대한 컬럼 이름으로써 사용된다. 각 SELECT문에서 선택된 컬럼 들은 같은 데이터

형을 가져야 한다. (예를 들면, 첫 번째 문장에서 선택된 첫 번째 컬럼은 다른 문들에서 선택된 첫 컬럼과 같은 데이터 형을 가져야
한다.)
만일 SELECT 컬럼 들의 데이터 형이 일치 하지 않으면, UNION에서 컬럼들의 길이화 형들이 모든 SELECT문들에서 가져온 값

들로 인식 된다. 예를 들면 다음과 같은 SQL문은:
mysql> SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);
+---------------+
| REPEAT('a',1) |
+---------------+
|a |

:::MySQL Korea:::
| bbbbbbbbbb |
+---------------+
(이전 버전의 MySQL에서 첫번째 SELECT로부터 그 형과 길이가 사용되고 두번째 레코드는 길이가 1로 변경될 것이다.)
SELECT 문은 일반적인 선택 문들이나 다음 과 같은 제한을 갖는다:
● 오직 마지막 SELECT문만이 INTO OUTFILE을 사용할 수 있다.

● HIGH_PRIORITY 는 UNION의 부분들은 SELECT 문과 사용될 수 없다. 첫번째 SELECT에서 명시하면 어떤 영향도 있
지 않게 된다. 뒤의 SELECT문들에 사용할 경우 문법 에러가 발생한다.
UNION의 기본 행동은 중복 레코드들이 그 결과에서 제거되는 것이다. DISTINCT 옵션 keyword역시 중복 레코드를 삭제 하도

록 명시 하는 것이기 때문에 아무런 영향도 갖지 않는다. ALL 옵션 keyword를 사용하면 중복 레코드 제거는 발생하지 않으며 결
과는 SELECT문에서 모든 매칭되는 레코드를 포함한다.
같은 질의 안에서 UNION ALL 와 UNION DISTINCT를 사용할 수 있다. 혼합된 UNION 타입들은 DISTINCT UNION이 ALL
UNION을 그것의 왼쪽으로 덮어 쓰도록 취급된다. DISTINCT UNION은 UNION DISTINCT을 사용하여 명시적으로 만들어지거
나 DISTINCT나 ALL keyword없이 UNION을 사용하여 암시적으로 만들어 질 수 있다.
정렬을 위해 ORDER BY나 LIMIT절을 사용하기 위해서, 혹은 전체 UNION 결과를 제한 하기 위해 각 SELECT문을 괄호로 묶고
마지막에 ORDER BY나 LIMIT을 위치 시킨다. 다음 예제는 두 가지 절 모두를 사용한다.:
(SELECT a FROM t1 WHERE a=10 AND B=1)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2)
ORDER BY a LIMIT 10;
이런 종류의 ORDER BY는 테이블 이름을 포함하는 컬럼 참조들을 사용하지 않는다. (즉, tbl_name.col_name 포맷으로 명명한

:::MySQL Korea:::
다) 대신, 첫 SELECT 문에서 컬럼 alias를 제공하고 ORDER BY에서 그 alias를 참조 한다. (대안적으로 그 컬럼 위치를 이용하
는 ORDER BY안에서 컬럼을 참조 한다. 그러나 컬럼 위치의 사용은 반대 된다.)
또한 저장 되는 컬럼이 alias라면, ORDER BY 절은 컬럼 이름이 아닌 그 alias를 참조 해야 한다. 다음 문장들 중 처음 문장은 잘 수

행되지만 두번째 문장은 Unknown column 'a' in 'order clause' 에러와 함께 실패 한다:
(SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY b;
(SELECT a AS b FROM t) UNION (SELECT ...) ORDER BY a;
개별 SELECT에 ORDER BY나 LIMIT를 적용하기 위해서는 SELECT를 괄호로 묶어 그 안에 절을 위치 시키도록 하라:
(SELECT a FROM t1 WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2 ORDER BY a LIMIT 10);
개별 SELECT문을 위한 ORDER BY의 사용은 기본적으로 UNION은 레코드 집합을 순서 없이 만들게 되기 때문에 최종 결과에
서 레코드들이 어떻게 나타나야 하는지 순서에 관해 아무것도 암시 하지 않는다. ORDER BY가 LIMIT과 함께 쓰일 경우, 그것은
SELECT를 위해 가져온 선택된 레코드의 부분 집합을 결정하기 위해 사용된다. 그러나 그것은 최종 UION 결과에서 레코드들의
순서에 영향을 주지 않는다. ORDER BY가 한 SELECT문에서 LIMIT없이 나타나는 경우 아무런 영향을 갖지 않으므로 최적화는
되지 않는다..
UNION결과에 있는 레코드들을 순서대로 각 SELECT 에 의해 취해진 레코드들의 집합으로 구성되도록 하려면, 정렬 컬럼으로 사
용하기 위해 각 SELECT문에서 추가적인 컬럼을 선택하고 마지막 SELECT뒤에 ORDER BY를 추가 하도록 하라:
(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1)
UNION
(SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col;

:::MySQL Korea:::
또한 개별 SELECT 결과들 안에서 정렬 순서를 유지 하기 위해 ORDER by 절에 두 번째 컬럼을 추가 하도록 하라:
(SELECT 1 AS sort_col, col1a, col1b, ... FROM t1)
UNION
(SELECT 2, col2a, col2b, ... FROM t2) ORDER BY sort_col, col1a;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8. 서브쿼리
13. SQL 문법(SQL Statement Syntax) 13.2.8.1. 단계적 변수로써의 서브쿼리

13.2. 데이터 조작 SQL문 13.2.8.2. 서브쿼리를 이용한 비교
13.2.8 서브쿼리 13.2.8.3. ANY, IN와 SOME 서브쿼리
13.2.8.1 단계적 변수로써의 서브쿼리 13.2.8.4. ALL 과 서브쿼리
13.2.8.2 서브쿼리를 이용한 비교 13.2.8.5. 로우 서브쿼리
13.2.8.3 ANY, IN과 SOME를 가진 서브쿼리 13.2.8.6. EXISTS 와 NOT EXISTS

13.2.8.7. 서로 관련된 서브쿼리들
13.2.8.8. FROM 절에서의 서브쿼리
13.2.8.5 로우 서브쿼리
13.2.8.9. 서브쿼리 에러들
13.2.8.10. 서브쿼리 최적화
13.2.8.11. MySQL 초기버전용 Joins로써의 리라이팅 서브쿼리들
13.2.8.9 서브쿼리 에러
서브쿼리 다른 SQL문 안에 있는 하나의 SELECT문이다.
13.2.8.10 서브쿼리 최적화 MySQL 4.1부터 MySQL 고유의 몇몇 특성 들뿐만 아니라 SQL 표준이 요구하는 모든 서브쿼리 형태와 연산들이
13.2.8.11 MySQL 초기버전 용 Joins로써의 리라이팅 서브쿼리들 제공된다
서브쿼리의 한 예는 다음과 같다:
SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
이 예제에서 SELECT * FROM t1 ... 은 outer 질의(outer 문)이고 (SELECT column1 FROM t2)는 서브쿼리
이다. 우리는 outer 쿼리 안에 서브쿼리가 내포 되었다고 말한다. 또한 다른 서브 쿼리 안에 서브 쿼리를 내포 하는
것도 가능하다. 서브쿼리는 항상 괄호로 묶여 있어야 한다.
서브쿼리의 주요 이점들은 다음과 같다:
● 서브쿼리는 구조화되어 다른 문장의 부분과 분리하는 것을 가능하게 한다.

● 서브쿼리는 복잡한 JOIN과 UNION을 필요로 하는 연산을 수행하는 다른 대안을 제공한다.

:::MySQL Korea:::
● 서브쿼리는 많은 사람들들의 의견대로 읽혀질수 있다. 실제로 “구조화된 질의 언어”인 SQL로 부른 원

래 생각을 주게 된 것은 이 서브쿼리의 등장에 의해서 이다.
다음은 SQL 표준과 MySQL에 의해 지원되는 서브쿼리에 관한 주요 사항을 보여주는 예문이다.

DELETE FROM t1
WHERE s11 > ANY
(SELECT COUNT(*) /* no hint */ FROM t2
WHERE NOT EXISTS
(SELECT * FROM t3
WHERE ROW(5*t2.s1,77)=
(SELECT 50,11*s1 FROM t4 UNION SELECT 50,77 FROM
(SELECT * FROM t5) AS t5)));
한 서브쿼리는 하나의 scalar(하나의 값), 하나의 레코드, 하나의 컬럼 혹은 하나의 테이블(하나이상의 컬럼을 갖
는 하나이상의 레코드)을 리턴할 수 있다. 이것들은 scalar, column, row 그리고 테이블 서브쿼리라 불린다. 특정
종류의 결과를 리턴하는 서브쿼리는 특정 context에서 사용될 수 있으며 이에 대한 것은 다음 장들에서 설명된다.
서브쿼리가 사용될 수 있는 문장 형에는 제약 사항들이 있다. 서브쿼리는 일반적인 SELECT 가 포함하는 어떤 키

워드나 절들도 포함 할 수 있다: DISTINCT, GROUP BY, ORDER BY, LIMIT, joins, index hints, UNION
constructs, comments, functions, 등등.
하나의 제약은 서브쿼리의 outer 문은 SELECT, INSERT, UPDATE,DELETE, SET 이나 DO중 하나이어야 한
다. 또다른 제약은 하나의 서브쿼리 안에서 여러분이 동시에 테이블의 수정이나 같은 테이블로부터 선택을 할 수
없다는 것이다. 이것은 as DELETE, INSERT, REPLACE, UPDATE, 그리고 (서브쿼리들이 SET절 안에서 사용
될 수 있기 때문이다.) LOAD DATA INFILE과 같은SQL문에 적용된다.
서브 쿼리의 형태에 관한 성능 관련 사항을 포함하여 서브쿼리 사용 제약에 관한 포괄적은 논의는 1.3장 “서브쿼
리의 제약들” 부분에서 다루어진다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.1. 단계적 변수로써의 서브쿼리
13.2. 데이터 조작 SQL문 가장 단순한 형으로 하나의 값을 리턴하는 scalar 서브쿼리가 있다. Scalar 서브쿼리는 하나의 단순한 연산 함수이고 여러분은 하
13.2.8 서브쿼리 나의 단순 컬럼 값이나 literal이 규칙에 맞는 어느 곳에서나 사용할 수 있다. 모든 피연산자 들이 갖는 데이터 형, 길이, NULL이 될
수 있는지 없는지에 대한 지정 등의 특징을 얘기 할 수 있다. 예를 들어:
CREATE TABLE t1 (s1 INT, s2 CHAR(5) NOT NULL);
INSERT INTO t1 VALUES(100, 'abcde');
13.2.8.5 로우 서브쿼리
13.2.8.6 EXISTS and NOT EXISTS SELECT (SELECT s2 FROM t1);
13.2.8.8 FROM 절 안에서의 서브쿼리들 SELECT문에서 서브쿼리는 CHAR 형이고 길이가 5이며 문자열 모음과 대조가 CREATE TABLE시에 기본값과 동일하며 컬럼안
13.2.8.9 서브쿼리 에러 의 값이 NULL이 될 수 있는지에 대한 지정 등을 갖는 하나의 단순 값(‘abcde’)를 리턴한다. 사실 모든 서브쿼리는 NULL이 될

수 있다. 이 예에서 사용된 테이블이 empty라면 서브쿼리의 값은 NULL이 될 것이다.
13.2.8.10 서브쿼리 최적화
Scalar 서브쿼리가 사용될 수 없는 몇가지 문장이 있다. 만약 SQL문이 하나의 문자열 값을 허용한다면 여러분은 서브 쿼리를 사용
할 수 없다. 예를 들면 LIMIT은 정수 인자를 요구하고 LOAD DATA INFILE은 문자열 파일 이름을 요구한다. 이때 이들 값들을
제공하기 위해 서브쿼리를 사용할 수 없다.
다소 간소한 구조를 포함하고 있는 다음 섹션에서 예를 보면서(SELECT column1 FROM t1), 더욱 다양하고 복잡한 구조를 가진
코드를 생각해 보자
두 개의 테이블을 만들었다고 가정하자:
CREATE TABLE t1 (s1 INT);

:::MySQL Korea:::
INSERT INTO t1 VALUES (1);
CREATE TABLE t2 (s1 INT);
INSERT INTO t2 VALUES (2);
SELECT를 수행하면:
SELECT (SELECT s1 FROM t2) FROM t1;
그 결과는 2가 되는데 값이 2인 컬럼 s1을 포함하고 있는 t2안에 레코드가 존재 하기 때문이다.
Scalar 서브쿼리는 표현의 부분이 될 수 있으나 괄호를 사용해야 하며 서브 쿼리가 함수에 대해 하나의 인자를 제공하는 연산자 함
수일 때도 마찬가지 이다. 예를 들면 다음과 같다:
SELECT UPPER((SELECT s1 FROM t1)) FROM t2;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.2. 서브쿼리를 이용한 비교
13.2.8 서브쿼리
가장 일반적인 서브쿼리는 다음과 같은 형태이다.:
13.2.8.3 ANY, IN과 SOME를 가진 서브쿼리 non_subquery_operand comparison_operator (subquery)
13.2.8.5 로우 서브쿼리 comparison_operator 는 다음 연산자들 중 하나이다:

= > < >= <= <>
예로:
13.2.8.9 서브쿼리 에러
13.2.8.10 서브쿼리 최적화
... 'a' = (SELECT column1 FROM t1)
서브쿼리의 적정 위치는 비교의 오른쪽에 위치하며 이것은 오래된 DBMS에서도 동일하다.
일반 형태의 서브쿼리 비교의 예는 다음과 같으며 이는 JOIN과 함께 사용될 수 없다. 이SQL문은 t2의 최대값과 같은 값을 갖는 레
코드를 t1테이블에서 찾는다:
SELECT column1 FROM t1
WHERE column1 = (SELECT MAX(column2) FROM t2);

:::MySQL Korea:::
또 다른 예로, 테이블들의 하나에 대해 aggregating을 포함하기 때문에 JOIN이 불가능하다. 주어진 컬럼에서 두번 나타나는 값을
포함하고 있는t1 테이블에서 모든 레코들 찾는다.:
SELECT * FROM t1 AS t
WHERE 2 = (SELECT COUNT(*) FROM t1 WHERE t1.id = t.id);
이들 연산자들중 하나와 함께 수행되는 비교를 위해 서브쿼리는 scalar를 리턴 해야 한다. 이때 예외적으로 =는 레코드 서브쿼리
와 함께 사용될 수도 있다. 13.2.8.5장 “레코드 서브쿼리” 부분을 참조 하라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.3. ANY, IN과 SOME를 가진 서브쿼리

구문:
13.2.8 서브쿼리
operand comparison_operator ANY (subquery)
13.2.8.3 ANY, IN과 SOME를 가진 서브쿼리 operand IN (subquery)
13.2.8.5 로우 서브쿼리 operand comparison_operator SOME (subquery)
13.2.8.7 서로 관련된 서브쿼리들 비교 연산자 뒤에 위치한 ANY keyword은 “서브쿼리가 리턴 하는 컬럼 안의 값들 중 ANY에 대해서 비교 값이 TRUE이면
TRUE를 리턴 한다”의 의미이다. 예를 들면:
13.2.8.9 서브쿼리 에러
SELECT s1 FROM t1 WHERE s1 > ANY (SELECT s1 FROM t2);
13.2.8.10 서브쿼리 최적화
(10)을 포함하는 t1테이블안에 하나의 값이 있다고 가정하자. 그 SQL문은 10보다 작은 7이 t2 테이블에 있기 때문에 t2테이블이
(21,14,7)을 포함하면 TRUE가 된다. t2테이블이 (20,10)을 포함하면 FALSE 이다. T2테이블이 (NULL,NULL,NULL)을 포함
하면 그 표현은 UNKNOWN이 된다.
IN은 = ANY 에 대한 alias이다. 따라서 이들 두 문장은 같다:
SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 IN (SELECT s1 FROM t2);

:::MySQL Korea:::
그러나 NOT IN은 <> ANY에 대한 alias가 아니다. 13.2.8.4장 “ALL문장과 서브쿼리” 부분을 참조 하라.
SOME은 ANY에 대한 alias이다. 따라서 이들 두 문장은 동일하다:
SELECT s1 FROM t1 WHERE s1 <> ANY (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 <> SOME (SELECT s1 FROM t2);
SOME 의 사용은 드물지만 이 예제는 그것을 사용했을 때의 유용함을 보여준다. 모든 사람들의 귀에는 영어 문장 “a is not
equal to any b”가 “there is no b which is equal to a”로 해석된다. 그러나 SQL문에서는 다르다. 그 의미는 “there is
some b to which a is not equal”을 의미한다. <> SOME의 사용은 모두가 그 질의의 진짜 의미를 이해 하는데 도움을 준
다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.4. ALL을 가진 서브쿼리
13.2. 데이터 조작 SQL문 구문:
13.2.8 서브쿼리
operand comparison_operator ALL (subquery)
비교 연산자 뒤에 있는 모든 ALL 은 서브 쿼리가 리턴 하는 컬럼안의 값들 모두에 대해 비교가 TRUE이면 TRUE를 리턴 하
라”의 의미이다. 예를 들면:
13.2.8.5 로우 서브쿼리 SELECT s1 FROM t1 WHERE s1 > ALL (SELECT s1 FROM t2);
13.2.8.7 서로 관련된 서브쿼리들 t1테이블 안에 (10)을 포함하는 레코드가 있다고 가정하자. 이 표현은 t2테이블이 (-5,0,+5)를 가지면 true가 되는데 10이 t2의
13.2.8.8 FROM 절 안에서의 서브쿼리들 세 값 모두보다 크기 때문이다. T2테이블이 (0,NULL,1)을 포함하면 그 표현은 unknown이 된다(즉, NULL).
13.2.8.9 서브쿼리 에러
마지막으로 t2테이블이 empty이면 결과는 TRUE가 된다. 따라서 다음 문장은 t2가 empty일 때 TRUE가 된다.
13.2.8.10 서브쿼리 최적화
SELECT * FROM t1 WHERE 1 > ALL (SELECT s1 FROM t2);
그러나 이 문장은 t2가 empty일 때 NULL이 된다:
SELECT * FROM t1 WHERE 1 > (SELECT s1 FROM t2);
추가적으로 다음 문장은 t2가 empty일 때 NULL이 된다:
SELECT * FROM t1 WHERE 1 > ALL (SELECT MAX(s1) FROM t2);

:::MySQL Korea:::
일반적으로 tables containing NULL values 와 empty tables 은 “edge cases.”이다. 서브쿼리를 사용할 때 항상 여러분은 이
런 두가지 가능성을 염두 해 두어야 한다.
NOT IN 은 <> ALL에 대한 alias이다. 따라서 이들 두 문장은 같다:
SELECT s1 FROM t1 WHERE s1 <> ALL (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 NOT IN (SELECT s1 FROM t2);

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.5. 로우 서브쿼리
13.2. 데이터 조작 SQL문 이부분에 대한 논의는 scalar 혹은 컬럼 서브쿼리 였다: 즉, 컬럼 값들 혹은 하나의 값을 리턴하는 서브 쿼리들을 의미한다. row
13.2.8 서브쿼리 subquery 는 하나의 레코드를 리턴하는 서브쿼리 이고 하나 이상의 컬럼 값을 리턴한다. 아래 예제를 참조 하라:

SELECT * FROM t1 WHERE (1,2) = (SELECT column1, column2 FROM t2);
SELECT * FROM t1 WHERE ROW(1,2) = (SELECT column1, column2 FROM t2);
13.2.8.5 로우 서브쿼리 여기의 쿼리들은 caolumn1=1고 column2 = 2인 레코드를 갖는 t 2 테이블에 대해서 모두 참이다.
13.2.8.7 서로 관련된 서브쿼리들 표현 (1,2) 과 레코드 (1,2)들은 가끔 레코드 생성자로 불리운다. 둘은 동등하고 다른 문에서도 적절하다. 예를 들면 다음 두개의
13.2.8.8 FROM 절 안에서의 서브쿼리들 문장은 의미적으로 동일하다(두번째 문장만 최적화 될 수 있음에도 불구하고):
13.2.8.9 서브쿼리 에러
SELECT * FROM t1 WHERE (column1,column2) = (1,1);
13.2.8.10 서브쿼리 최적화
SELECT * FROM t1 WHERE column1 = 1 AND column2 = 1;
레코드 생성자의 일반적인 사용은 두개 이상의 컬럼을 리턴하는 서브쿼리와 비교를 위한 것이다. 예를 들면 다음 쿼리는 요구 “t2
테이블에도 존재하고 t2테이블에도 존재하는 모든 레코드를 찾아라”한다:
SELECT column1,column2,column3
FROM t1
WHERE (column1,column2,column3) IN

:::MySQL Korea:::
(SELECT column1,column2,column3 FROM t2);

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.6. EXISTS 와 NOT EXISTS
13.2. 데이터 조작 SQL문 서브쿼리가 어떤 레코드 던지 리턴하면 EXIST subquery는 TRUE이며 NOT EXIST suquery는 FALSE가 된다. 예를 들면:
13.2.8 서브쿼리
SELECT column1 FROM t1 WHERE EXISTS (SELECT * FROM t2);
전통적으로 EXISTS서브쿼리는 SELECT *와 함께 시작하나, SELECT 5 혹은 SELeCT column1과 함께 시작할 수도 있다.
MySQL은 그런 서브쿼리에서 SELECT를 무시하여 차이를 만들지 않는다.
13.2.8.5 로우 서브쿼리 처음 예문에서 NULL 값들만 가진 레코드라도 t2가 레코드를 포함하면 EXISTS조건은 TRUE를 갖는다. 실제로 [NOT] EXISTS
13.2.8.6 EXISTS and NOT EXISTS 서브 쿼리는 항상 상호 관계를 갖기 때문에 드문 예제 이다. 여기 실질적인 예제가 있다.:
13.2.8.8 FROM 절 안에서의 서브쿼리들 ● 어떤 종류의 가계가 하나 이상의 도시에 있는가?
13.2.8.9 서브쿼리 에러
SELECT DISTINCT store_type FROM stores
13.2.8.10 서브쿼리 최적화
WHERE EXISTS (SELECT * FROM cities_stores
WHERE cities_stores.store_type = stores.store_type);
● 어떤 종류의 가계가 어떤 도시에도 나타나지 않는가
SELECT DISTINCT store_type FROM stores
WHERE NOT EXISTS (SELECT * FROM cities_stores

:::MySQL Korea:::
WHERE cities_stores.store_type = stores.store_type);
● 어떤 종류의 가계가 모든 도시에서 보여지는가?
SELECT DISTINCT store_type FROM stores s1
WHERE NOT EXISTS (
SELECT * FROM cities WHERE NOT EXISTS (
SELECT * FROM cities_stores
WHERE cities_stores.city = cities.city
AND cities_stores.store_type = stores.store_type));
마지막 예문은 이중 중첩 NOT EXISTS 쿼리이다. 즉, NOT EXISTS질의이다. 즉 NOT EXISTS절 안에 NOT EXISTS절을 갖는
다. 공식적으로 그것은 “가계들 안에서 있는 않은 한 가계를 가진 도시가 있는가?”의 질문에 응답한다. 그러나 중첩 NOT
EXISTS가 “x가 모든 y에 대해 TRUE”인가 라는 질문에 답하기를 쉽도록 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.7. 서로 관련된 서브쿼리들
13.2. 데이터 조작 SQL문 서로 관련된 서브쿼리 는 outer query에 나타난 테이블에 대한 참조를 포함한 서브쿼리이다. 예를 들면:
13.2.8 서브쿼리
SELECT * FROM t1 WHERE column1 = ANY
(SELECT column1 FROM t2 WHERE t2.column2 = t1.column2);
13.2.8.4 ALL을 가진 서브쿼리 서브쿼리가 그것의 FROM절이 t1테이블을 언급하지 않았으면서도 t1의 한 컬럼에 대한 참조를 포함하고 있다. 따라서 MySQL은
13.2.8.5 로우 서브쿼리 서브쿼리의 외부를 살피고 outer query에서 t1을 찾는다.
13.2.8.7 서로 관련된 서브쿼리들 T1테이블이 column1=5이고 column2=6인 레코드를 포함한다고 가정하자. T2테이블은 column1=5이고 column2 =7인 레코
13.2.8.8 FROM 절 안에서의 서브쿼리들 드를 포함한다. 이 단순한 표현 ... WHERE column1 = ANY (SELECT column1 FROM t2) 는 TRUE가 될것이다 그러나 이 예
13.2.8.9 서브쿼리 에러 제에서 서브쿼리안의 WHERE 절은 FALSE가 된다( 왜냐 하면 (5,6)이 (5,7)과 갖지 않기 때문이다). 따라서 전체로서 서브쿼리
는 FALSE가 된다.
13.2.8.10 서브쿼리 최적화
Scoping rule: MySQL 내부에서 외부로 판단해 간다. 예를 들면:
SELECT column1 FROM t1 AS x
WHERE x.column1 = (SELECT column1 FROM t2 AS x
WHERE x.column1 = (SELECT column1 FROM t3
WHERE x.column2 = t3.column1));

:::MySQL Korea:::
이 문장에서 x.column2 은 SELECT column1 FROM t2 AS x ... 이 t2을 재 명명하기 때문에 t2테이블 안의 컬럼 이어야 한다.
이것은 SELECT column1 FROM t1 ... 가 farter out인 outer 쿼리이기 때문에 t1테이블 안의 컬럼 이 아니다.
HAVING 혹은 ORDER BY 절을 갖는 서브쿼리에 대해, MySQL은 outer 선택 리스트에서 컬럼 이름들을 찾는다.
어떤 경우에는 correlated subquery는 최적화 된다. 예를 들면:
val IN (SELECT key_val FROM tbl_name WHERE correlated_condition)
그렇지 않으면 그것들은 비효율적이고 느려진다. JOIN으로서 쿼리의 재 작성은 성능을 향상 시킬것이다.
Correlated subqueries는 outer 질의로부터 집합 함수의 결과를 참조 할 수가 없다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.8. From 절 안에서의 서브쿼리들
13.2. 데이터 조작 SQL문 서브쿼리는 SELECT문의 FROM절에서 유효 하다. 실제 구문은 다음과 같다:
13.2.8 서브쿼리
SELECT ... FROM (subquery) [AS] name ...
[AS] name 절은 필수인데 FROM절의 모든 테이블이 하나의 이름을 가져야 하기 때문이다. subquery 선택 리스트안의 어떤 컬
럼도 유일한 이름을 가져야 한다. 이 매뉴얼의 다른 곳에서 “derived tables.”으로 사용되는 설명되는 이 구문을 찾을 수 있다.
13.2.8.5 로우 서브쿼리 실례를 위해 다음 테이블이 있다고 가정하자:
13.2.8.7 서로 관련된 서브쿼리들 CREATE TABLE t1 (s1 INT, s2 CHAR(5), s3 FLOAT);

예문 테이블을 이용하여 FROM 절 안에 서브쿼리를 어떻게 이용하는지 보여준다:
13.2.8.9 서브쿼리 에러
13.2.8.10 서브쿼리 최적화
INSERT INTO t1 VALUES (1,'1',1.0);
INSERT INTO t1 VALUES (2,'2',2.0);
SELECT sb1,sb2,sb3
FROM (SELECT s1 AS sb1, s2 AS sb2, s3*2 AS sb3 FROM t1) AS sb
WHERE sb1 > 1;
결과: 2, '2', 4.0.

:::MySQL Korea:::
또 다른 하나의 예가 있는데, group화 된 테이블에 대한 합계의 평균을 알고 있다고 가정 하자. 이 문장은 수행 되지 않는다.
SELECT AVG(SUM(column1)) FROM t1 GROUP BY column1;
However, this query provides the desired information:
SELECT AVG(sum_column1)
FROM (SELECT SUM(column1) AS sum_column1
FROM t1 GROUP BY column1) AS t1;
서브쿼리에서 사용되는 컬럼 이름은 outer 쿼리에서 인식된다는 것을 유의 하라.
FROM절에서 서브쿼리들은 scalar, 컬럼, 레코드 혹은 테이블을 리턴할 수 있다. FROM절의 서브쿼리들은 서브 쿼리들과
correlate될 수 없다.
FROM절 안의 서브 쿼리들은EXPLAIN문을위해 수행된다. 이것은 상위 레벨의 쿼리들이 최적화를 하는동안 모든 테이블에 관한
정보를 필요로 하기 때문이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.9. 서브쿼리 에러
13.2. 데이터 조작 SQL문 서브쿼리에만 적용되는 몇몇 에러들이 있으며 이 장에서는 그들에 대해 설명한다.
13.2.8 서브쿼리
● 서브 쿼리에서 부정확한 수의 컬럼:
ERROR 1241 (ER_OPERAND_COL)
13.2.8.4 ALL을 가진 서브쿼리 SQLSTATE = 21000
13.2.8.5 로우 서브쿼리
13.2.8.6 EXISTS and NOT EXISTS Message = "Operand should contain 1 column(s)"

이 에러는 다음과 같은 경우에 발생 한다.:
13.2.8.9 서브쿼리 에러
SELECT (SELECT column1, column2 FROM t2) FROM t1;
13.2.8.10 서브쿼리 최적화
사용 목적이 비교인 경우, 여러분은 여러 개의 컬럼을 리턴 하는 서브쿼리를사용 할 수 있다. 13.2.8.5장 “레코드 서브쿼
리” 부분을 참조 하라. 그러나 다른 SQL문들에서 서브쿼리는 scalar 연산 함수이어야 한다.
● 서브쿼리에서 부정확한 수의 레코드:
ERROR 1242 (ER_SUBSELECT_NO_1_ROW)
SQLSTATE = 21000
Message = "Subquery returns more than 1 row"

:::MySQL Korea:::
이 에러는 서브쿼리가 하나 이상의 레코드를 리턴하는 문장들에 대해 발생한다. 다음 예문을 생각 해 보면:
SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);
SELECT column1 FROM t2 는 단지 하나의 레코드를 리턴한다. 이전 쿼리는동작한다. 만일 서브쿼리가 하나 이상의 레

코드를 리턴하면 error 1242가 발생 한다. 이 경우 그 쿼리는 다음과 같이 갱신 되어야 한다.
SELECT * FROM t1 WHERE column1 = ANY (SELECT column1 FROM t2);
● 서브쿼리에서 부정확한 테이블의 사용:
Error 1093 (ER_UPDATE_TABLE_USED)
SQLSTATE = HY000
Message = "You can't specify target table 'x'
for update in FROM clause"
이 에러는 다음과 같은 경우에 발생 한다:
UPDATE t1 SET column2 = (SELECT MAX(column1) FROM t1);
여러분은 UPDATE문 내에서 할당을 위한 서브쿼리를 사용할 수 있는데 그서브쿼리들은 SELECT문 뿐만 아니라
UPDATE와 DELETE문들 내에서 적합하기 때문이다. 그러나 서브쿼리의 FROM절과 업데이트 target모두를 위해 같은
테이블을 사용할 수 없다.
트랜잭션 저장 엔진을 위해 서브쿼리절의 실패는 전체 문장을 실패로 만들게 된다. 비 트랜잭션 저장 엔진의 경우 그 에러가 발생하
기 전에 만들어진 데이터 수정은 보존된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.10. 서브쿼리 최적화
13.2. 데이터 조작 SQL문 개발은 계속되고 있으며 최적화 팁이 장 시간 동안에는 신뢰성이 없다. 다음 리스트는 여러분이 다루길 원하는 몇 가지 흥미로운 트
13.2.8 서브쿼리 릭을 제공한다.:

● 서브 쿼리안의 레코드의 순서나 수에 영향을 주는 서브쿼리 절을 사용하라 예를 들면 :
SELECT * FROM t1 WHERE t1.column1 IN
13.2.8.5 로우 서브쿼리 (SELECT column1 FROM t2 ORDER BY column1);
13.2.8.7 서로 관련된 서브쿼리들 SELECT * FROM t1 WHERE t1.column1 IN

(SELECT DISTINCT column1 FROM t2);
13.2.8.9 서브쿼리 에러
13.2.8.10 서브쿼리 최적화
SELECT * FROM t1 WHERE EXISTS
(SELECT * FROM t2 LIMIT 1);
● JOIN을 서브쿼리와 바꾸라. 예를 들면:
SELECT DISTINCT column1 FROM t1 WHERE t1.column1 IN (
SELECT column1 FROM t2);
이것 대신:

:::MySQL Korea:::
SELECT DISTINCT t1.column1 FROM t1, t2
WHERE t1.column1 = t2.column1;
● 일부 서브쿼리는 서브쿼리를 지원하지 않은 MySQL의 예전 버전과의 호환석을 위해 JOIN으로 변환 될 수 있다. 그러나 일

부 경우 서브쿼리를 JOIN으로 변환 하는 것은 성능을 향상 시킬 수도 있다. 13.2.8.11 장 “이전 MySQL 버전을 위한
JOIN으로서 서브쿼리의 재 작성”부분을 참조하라.
● 서브쿼리의 바깥에서 안쪽으로 절들을 옮기도록 하라 예를 들면 이런 쿼리를 사용하라:
SELECT * FROM t1
WHERE s1 IN (SELECT s1 FROM t1 UNION ALL SELECT s1 FROM t2);
이런 쿼리 대신 :
SELECT * FROM t1
WHERE s1 IN (SELECT s1 FROM t1) OR s1 IN (SELECT s1 FROM t2);
또다른 예로서 이 쿼리를 사용하라:
SELECT (SELECT column1 + 5 FROM t1) FROM t2;
이 쿼리 대신
SELECT (SELECT column1 FROM t1) + 5 FROM t2;
● 상호 연관된 서브쿼리대신에 하나의 레코드 서브쿼리를 사용하도록 하라. 예를 들면 다음 쿼리문을 사용하라:
SELECT * FROM t1
WHERE (column1,column2) IN (SELECT column1,column2 FROM t2);

:::MySQL Korea:::
이 쿼리 대신:
SELECT * FROM t1
WHERE EXISTS (SELECT * FROM t2 WHERE t2.column1=t1.column1
AND t2.column2=t1.column2);
a <> ALL (...).대신 NOT (a = ANY (...))를 사용하라
● x=1 OR x=2보다 x = ANY (table containing (1,2)) 를 사용하라.

● EXISTS 대신 Use = ANY.
● 항상 하나의 레코드를 리턴하는 uncorrelated 서브쿼리에 대해 IN은 =.보다 느리다. 예를 들면 다음 예문을 사용하라.
SELECT * FROM t1 WHERE t1.col_name
= (SELECT a FROM t2 WHERE b = some_const);
Instead of this query:
SELECT * FROM t1 WHERE t1.col_name
IN (SELECT a FROM t2 WHERE b = some_const);
이들 트릭은 프로그램을 빠르게 혹은 느리게 할 수 있다. BENCHMARK() 함수와 같이 MySQL의 제공하는 서비스를 이용하면 여
러분의 상황에서 무엇이 도움이 될지에 관해 아이디어를 얻을 수 있다. 12.9.3장 “정보 함수”를 참조 라.
MySQL 스스로 만드는 최적화는 다음과 같다:
● MySQL은 non-correlate서브쿼리를 단 한번만 수행한다. 주어진 서브쿼리가 non-correlate라는 것을 확실하게 하기 위

해 EXPLAIN을 사용하라.

:::MySQL Korea:::
● MySQL은 서브쿼리 안의 선택 리스트 컬럼들이 인덱스될 가능성에 대한 이점을 갖도록 하기 위해 IN, ALL, ANY, 그리고
SOME 서브 쿼리를 사용한다.
● MySQL는 다음 형태의 서브쿼리들을 인덱스 조사 함수로 대치 하는데 이런 EXPLAIN은 특별한 JOIN형으로 표현한다.
(unique_subquery 나 index_subquery):
• ... IN (SELECT indexed_column FROM single_table ...)
● MySQL은 NULL 값들나 empty 집합이 포함되지 않는한 MIN()이나 MAX()를 포함하는 표현과 함께 다음 form의 표현
을 강화 한다.
value {ALL|ANY|SOME} {> | < | >= | <=} (non-correlated subquery)
예를 들어 이 WHER절은:
WHERE 5 > ALL (SELECT x FROM t)
이와 같은 초적화에 의해 처리 될 수 있다.
WHERE 5 > (SELECT MAX(x) FROM t)
MySQL 내부 매뉴얼에 “MySQL의 서브쿼리 변환 방법” 장이 있으며 http://dev.mysql.com/doc/에서 볼 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.8.11. MySQL 초기버전 용 Joins로써의 리라이팅 서브쿼리들
13.2. 데이터 조작 SQL문 MySQL의 이전 버전에서는 INSERT … SELECT ..와 REPLACE … SELECT …형의 쿼리들만 지원 되었다. 이것은 MySQL
13.2.8 서브쿼리 5.0에서의 경우가 아닐 지라도 값들 안에 있는 멤버쉽을 테스트 하기 위한 다른 방법들이 있다는 점은 사실이다. 그것은 또한 몇 가
지 경우에도 사실이며, 서브 쿼리를 갖지 않은채 쿼리를 다시 쓰기는 불가능 하며 서브쿼리를 사용하는 것보다 이러한 기술들을 사
용하는 것이 좀더 효과적이다. 이러한것들 중 하나는 IN()이다:
예를 들면 이 쿼리는
13.2.8.5 로우 서브쿼리 SELECT * FROM t1 WHERE id IN (SELECT id FROM t2);
13.2.8.7 서로 관련된 서브쿼리들 다음 처럼 다시 쓰여 질 수 있다:

13.2.8.9 서브쿼리 에러 SELECT DISTINCT t1.* FROM t1, t2 WHERE t1.id=t2.id;
13.2.8.10 서브쿼리 최적화

아래 쿼리들은:
SELECT * FROM t1 WHERE id NOT IN (SELECT id FROM t2);
SELECT * FROM t1 WHERE NOT EXISTS (SELECT id FROM t2 WHERE t1.id=t2.id);
IN()을 사용하여 아래와 같이 쓰여질 수 있다.
SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
WHERE table2.id IS NULL;

:::MySQL Korea:::
LEFT [OUTER] JOIN 은 동등한 서브쿼리 보다 빠를 수 있는데 서버가 그것을 좀더 최적화 할 수 있기 때문이다. 이 것은
MySQL 서버 에게만 해당되는 사항이 아니다. SQL-92 이전에는 outer join은 존재 하지 않았고 따라서 서브쿼리 들이 그러한
일들을 하기 위한 유일한 방법이었다. 오늘날 MySQL서버와 다른 많은 데이터베이스 시스템은 outer join 형을 제공한다.
MySQL 서버는 하나 혹은 여러 개의 테이블에서 얻은 정보를 바탕으로 레코드들을 효과적으로 지우는데 사용될 수 있는 다중 테이

블 DELETE문을 제공한다. 또한 다중 테이블 UPDATE문들도 지원된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.9. TRUNCATE
13. SQL 문법(SQL Statement Syntax) TRUNCATE [TABLE] tbl_name

13.2.9 TRUNCATE TRUNCATE TABLE 은 테이블을 완전히 비운다. 논리적으로 이것은 모든 열을 삭제하는 DELETE 문에 해당되지만, 실제로는
몇몇 상황에 있어 차이가 있다.
5.0.3 버전 이전의 InnoDB 의 경우, TRUNCATE TABLE 은 DELETE와 같아서 차이가 없다. MySQL 5.0.3 버전부터,
TRUNCATE TABLE 이 사용되고 있다. 그러나 테이블에 인용한 외부 키 제약이 있다면, 오퍼레이션은 여전히 DELETE 로 된
다. (빠른 종료를 사용하면 AUTO_INCREMENT 카운터를 리셋한다. MySQL5.0.13버전부터, AUTO_INCREMENT 카운터는
외부 키 제약과 관계없이 TRUNCATE TABLE에 의해 리셋된다.)
다른 스토리지 엔진의 경우, MySQL 5.0에서 다음과 같이 TRUNCATE TABLE 는 DELETE 와 다르다:
● Truncate 오퍼레이션은 테이블을 중단시키고 재생성하므로, 한 줄씩 삭제하는 것보다 훨씬 빠르다.

● Truncate 오퍼레이션은 안전한 트랜잭션처리가 되지 않는다(한번 실행된 Truncate 작업은 복구가 불가능하다); 액티브
트랜잭션이나 액티브 테이블 락을 실행하면 에러가 발생한다.
● 삭제된 열의 수는 리턴되지 않는다.
● tbl_name.frm 테이블 포맷 파일이 유효하면, 데이터나 인덱스 파일이 손상되었다하더라도 TRUNCATE TABLE 를 가진
빈 테이블로 재생성될 수 있다
● 테이블 핸들러는 마지막 사용된 AUTO_INCREMENT 값을 기억할 수 없다. 그러나 처음부터 카운팅이 시작된다. 이것은
MyISAM 과 InnoDB에서도 마찬가지로, 일반적으로 시퀀스 값은 다시 사용되지 않는다.
테이블 트렁케이션(중단/끊기)은 DELETE 를 사용할 수 없지만, TRUNCATE 문은 ON DELETE 트리거를 불러올 수 없다.
TRUNCATE TABLE 은 MySQL에서 채택된 오라클 SQL 확장이다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.2.10. UPDATE
13. SQL 문법(SQL Statement Syntax) 단일 테이블 신텍스:

13.2. 데이터 조작 SQL문 UPDATE [LOW_PRIORITY] [IGNORE] tbl_name
13.2.10 UPDATE SET col_name1=expr1 [, col_name2=expr2 ...]

[ORDER BY ...]
[LIMIT row_count]
멀티 테이블 신텍스:
UPDATE [LOW_PRIORITY] [IGNORE] table_references
SET col_name1=expr1 [, col_name2=expr2 ...]
단일 테이블 신텍스의 경우, UPDATE 문은 tbl_name 로우에 있는 컬럼을 새로운 값으로 업데이트 한다. SET 절은 수정된 컬럼
과 주어진 값을 보여준다. WHERE 절은 업데이트할 로우를 확인하는 조건을 지정한다. WHERE 절이 없다면, 모든 로우는 업데이
트 된 것이다. ORDER BY 절이 지정되어 있다면, 로우는 지정된 순서대로 업데이트 된다. LIMIT 절은 업데이트될 수 있는 로우의
수에 제한을 둔다.
멀티 테이블 신텍스의 경우, UPDATE 문은 조건을 만족하는 table_references 에 명명된 각각의 테이블의 로우을 업데이트한다.
이런 경우, ORDER BY 와 LIMIT 는 사용될 수 없다.
where_condition 은 업데이트된 각각의 로우를 평가하는 표식이다. 이것은 13.2.7 “SELECT 신텍스” 장에 기술되어 있는대로
지정된다.
UPDATE 문은 다음의 변경자를 지원한다:

:::MySQL Korea:::
● LOW_PRIORITY 키워드를 사용한다면, UPDATE 문 실행은 다른 어떤 클라이언트도 테이블에서 읽히지 않을 때까지 지

연된다.
● IGNORE 키워드를 사용한다면, 업데이트 도중에 에러가 발생하더라도 업데이트 문은 중단되지 않는다. 중복키 충돌이 발
생한 로우만 업데이트 되지 않는다. 또한 업데이트 되는 컬럼에 데이터 변환 에러를 유발시키는 로우들은 가장 가까운 유효
한 값으로 대체된다.
위의 표현에 있는 tbl_name 의 컬럼을 엑세스 하게 되면, UPDATE 는 컬럼의 현재 값을 사용한다. 예를 들어, 다음 문은 현재

값보다 큰 값으로 age 컬럼을 셋팅한다.:
UPDATE persondata SET age=age+1;
UPDATE 작업은 왼쪽에서 오른쪽으로 진행된다. 예를들어, 다음의 문은 age 칼럼을 이중으로하며, 그것을 인크리먼트 한다.:
UPDATE persondata SET age=age*2, age=age+1;
만약 컬럼을 현재 값에 셋팅하면, MySQL은 이것을 인지하고 업데이트하지 않는다.

NOT NULL 로 표시된 컬럼을 NULL 로 셋팅하여 업데이트한다면, 컬럼은 데이터 타입에 어울리는 디폴트값으로 셋팅되고 경고
횟수가 증가한다. 숫자형 데이터 타입의 경우, 디폴트 값이 0이고, 문자형의 경우, 빈 문자(''), 데이터와 시간 타입의 경우에는 “제
로zero”가 디폴트 값이 된다.
UPDATE 는 실제로 변경된 로우들을 반환한다. mysql_info() C API 함수는 조건에 상응하는 로우들과, 업데이트 된 로우들, 그
리고UPDATE 도중에 발생하는 경고들을 반환한다.
UPDATE 유효범위를 한정하기 위해서 LIMIT row_count 를 사용할 수 있다. LIMIT 절은 로우에 부합하는 제한이다. 실제로 변
경되었던 안되었던지 WHERE 절을 만족시키는 row_count 로우를 찾자마자 명령문은 중단된다.
UPDATE 문은 ORDER BY 절을 포함한다. 로우들은 절에서 명기한 순서에 따라 업데이트된다.

멀티 테이블을 커버하는 UPDATE 오퍼레이션을 실행할 수 있습니다. 그러나 멀티 테이블 UPDATE 에서 ORDER BY 또는
LIMIT 는 사용할 수 없다. table_references 절은 집합에 관련된 테이블을 기록한다. 그 신텍스는 13.2.7.1 “JOIN 신텍스”장
에 기술되어 있다. 다음이 그 예이다:

:::MySQL Korea:::
UPDATE items,month SET items.price=month.price

WHERE items.id=month.id;
앞의 예는 콤마 오퍼레이터를 사용하는 내적인 집합을 보여준다. 그러나 멀티 테이블 UPDATE 문은 LEFT JOIN 에서와 마찬가지
로, SELECT 문에서 허용된 집합 타입을 사용할 수 있다.
실제로 업데이트 된 멀티 테이블 UPDATE 에서 언급된 컬럼의 경우 UPDATE 권한이 필요하다. 읽혀지지만 수정되지 않은 컬럼
에만 SELECT 권한을 사용하면 된다
만약 외부키 제한이 있는 InnoDB 테이블에 포함된 멀티 테이블 UPDATE 문을 사용한다면, MySQL 옵티마이저는 테이블들의
parent/child relationship (부자관계)과는 별도로 처리하게 된다. 이런 경우, 명령문은 실패하고 롤백된다. 대신에, 싱글 테이블을
업데이트되고, InnoDB 가 제공하는 ON UPDATE 기능에 따라 적절하게 다른 테이블을 수정하게 된다. 14.2.6.4. “외부키 제
한” 장을 참조하라.
현재는 테이블을 업데이트할 수 없고, 서브쿼리에 있는 같은 테이블로부터 선택해야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.3. MySQL 유틸리티 명령문
13. SQL 문법(SQL Statement Syntax) 13.3.1. DESCRIBE

13.3. MySQL 유틸리티 명령문 13.3.2. USE
13.3 MySQL 유틸리티 명령문

13.3.2 USE Syntax
:::MySQL Korea:::
제목검색
13.3.1. DESCRIBE Syntax

{DESCRIBE | DESC} tbl_name [col_name | wild]
13.3. MySQL 유틸리티 명령문

DESCRIBE 는 하나의 테이블에 있는 컬럼에 대한 정보를 제공한다.이것은 SHOW COLUMNS FROM을 위한 간단한 방법이다.
MySQL 5.0.1에서, 이 명령문은 뷰어를 위한 정보를 보여준다. (13.5.4.3, “SHOW COLUMNS 신텍스” 장을 참조하라)
col_name 는 하나의 컬럼 이름이 되거나, 문자열에 맞는 컬럼일 때에만 출력되는 와일드카드 문자인 SQL ‘%’ 와 ‘_’ 를 포함
하는 문자열일 수도 있다. 만약 문자열에 스페이스나 다른 특별한 문자가 포함되어 있지 않다면 인용문 안에 문자열을 넣을 필요가
없다.
mysql> DESCRIBE city;
+------------+----------+------+-----+---------+----------------+
+------------+----------+------+-----+---------+----------------+
| Id | int(11) | NO | PRI | NULL | auto_increment |
| Name | char(35) | NO | | | |
| Country | char(3) | NO | UNI | | |

:::MySQL Korea:::
| District | char(20) | YES | MUL | | |
| Population | int(11) | NO | |0 | |
+------------+----------+------+-----+---------+----------------+
Field 는 컬럼의 이름을 표시한다.
Null 필드는 NULL 값이 컬럼에 저장되어 있는지 여부를 보여준다.
Key 필드는 컬럼이 인덱싱되어 있는지를 보여준다. PRI 의 값은 컬럼이 테이블의 주요 키의 일부분이라는 것을 보여준다. UNI 는
컬럼이 UNIQUE 인덱스의 부분이라는 것을 보여준다. MUL 값은 해당 컬럼 안에 주어진 값이 여러 번 나올 수 있다는 것을 보여준
다.
UNIQUE 인덱스에 디스플레이 되는 MUL 에 있어 하나의 이유는 몇몇 컬럼들이 합성 UNIQUE 인덱스를 만든다는 것이다; 물론
컬럼의 조합이 유일무이하고, 각각의 컬럼에서 주어진 값이 여러 번 나올 수 있다. 하나의 합성 인덱스에서 가장 왼쪽에 있는 컬럼
만 Key 필드에 입력할 수 있다는 것을 주의하라.
MySQL 5.0.11 버전 이전에는, 만약 컬럼이 NULL 값을 고려한다면, Key 값은 UNIQUE 인덱스를 사용할 때 조차 MUL이 될 수
있다. UNIQUE에 있는 복합적인 로우는 컬럼이 NOT NULL 이라고 밝히지 않는다면, NULL 값을 가질 수 있다. MySQL 5.0.11
에서, 디스플레이는 컬럼이 NULL을 허락하는지에 관계없이MUL보다는 UNI이다; 컬럼이 NULL을 포함하고 있는지 여부는
NULL 필드에서 볼 수 있다.

:::MySQL Korea:::
Default 필드는 컬럼에 할당된 디폴드 값을 보여준다.
Extra 필드는 주어진 컬럼에 유효한 추가적 정보를 포함하고 있다. 예시에서 보여주듯이, Extra 필드는 Id 컬럼이
AUTO_INCREMENT 키워드로 생성된다는 것을 보여준다.
만약 데이터 타입이 예상밖으로 CREATE TABLE 문에 바탕을 둔 것과 다르다면, 가끔 MySQL이 데이터 타입을 변경시킨다는 것
을 주의하라. 13.1.5.1.”암묵적인 컬럼 지정 변경” 장을 참조하라.
DESCRIBE 문은 오라클과 호환성을 제공한다.
SHOW CREATE TABLE 과 SHOW TABLE STATUS 문은 테이블에 관한 정보를 제공한다. 13.5.4”SHOW 신텍스”장을 참
조하라.

:::MySQL Korea:::
제목검색
13.3.2. USE Syntax

USE db_name
13.3. MySQL 유틸리티 명령문
13.3.2 USE Syntax

USE db_name 문은 MySQL에 그 다음 문에서 디폴트(현재) 데이터베이스로 db_name 데이터베이스를 사용하라고 한다. 데이터
베이스는 세션 끝까지 또는 다른 USE 문이 나올 때까지 디폴트로 남아 있는다:
USE db1;
SELECT COUNT(*) FROM mytable; # selects from db1.mytable
USE db2;
SELECT COUNT(*) FROM mytable; # selects from db2.mytable
USE 문에 의해서 특별한 데이터베이스를 디폴트로 하는 것이 다른 데이터베이스로 엑세스 하는 것을 방해하는 것은 아니다. 다음

예시는 db1데이터베이스로부터 author 테이블에 그리고 bd2 데이터베이스로부터 editor 테이블에 입력하는 것이다:
USE db1;
SELECT author_name,editor_name FROM author,db2.editor
WHERE author.editor_id = db2.editor.editor_id;
USE 문은 사이베이스와 호환성을 제공한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.4. MySQL 트랜잭션 과 잠금문
13. SQL 문법(SQL Statement Syntax) 13.4.1. START TRANSACTION, COMMIT, ROLLBACK
13.4. MySQL 트랜잭션 과 잠금문 13.4.2. 록백(ROLLBACK)될 수 없는 문
13.4 MySQL 트랜잭션 과 잠금문 13.4.3. 암시적 Commit 유발문
13.4.1 START TRANSACTION, COMMIT, 와 ROLLBACK 13.4.4. SAVEPOINT 와 ROLLBACK TO SAVEPOINT
13.4.2 Roll back될 수 없는 SQL문 13.4.5. LOCK TABLES 와 UNLOCK TABLES

13.4.3 암묵적 Commit을 유발하는 SQL문
13.4.7. XA 트랜잭션
13.4.4 SAVEPOINT 와 ROLLBACK TO SAVEPOINT
13.4.5 LOCK TABLES 와 UNLOCK TABLES
13.4.7 XA 트랜잭션 MySQL 은 SET AUTOCOMMIT, START TRANSACTION, COMMIT, ROLLBACK 과 같은 로컬 트랜잭션 문을
13.4.7.1 XA Transaction SQL 신텍스 제공한다. 13.4.1장 “START TRANSACTION, COMMIT, and ROLLBACK”부분을 참고하라. MySQL 5.0 부터
13.4.7.2 XA Transaction States XA 트랜잭션 제공이 가능해졌는데 이는 MySQL이 분산 트랜잭션을 할 수 있도록 해주었다. 13.4.7장 “XA 트랜잭
션”부분을 참고하라.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.4.1. START TRANSACTION, COMMIT, 와 ROLLBACK
13. SQL 문법(SQL Statement Syntax) START TRANSACTION | BEGIN [WORK]

13.4. MySQL 트랜잭션 과 잠금문 COMMIT [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
13.4.1 START TRANSACTION, COMMIT, 와 ROLLBACK [WORK] [AND [NO] CHAIN] [[NO] RELEASE]
ROLLBACK SET AUTOCOMMIT = {0 | 1}
START TRANSACTION 과 BEGIN 문은 새로운 트랜잭션을 시작한다. COMMIT는 현재 트랜잭션을 수행하여 그 변경 사

항들을 영구적으로 만든다. ROLLBACK은 현재 트랜잭션을 끝내고 그 현재까지의 작업을 취소한다. SET AUTOCOMMIT
문은 현재 연결에 대해서 기본 자동 커밋을 활성화 혹은 비활성화 할 수 있다.
MySQL 5.0부터 WORK 옵션 키워드가 CHAINT과 RELASE절 처럼 COMMIT과 RELEASE에 제공된다. CHAIN과
RELEASE는 트랜잭션의 완수를 위한 추가적인 제어를 위해 사용될 수 있다. Completion_type 시스템 변수의 값은 기본 완
료 동작을 결정한다. 5.2.2장 “서버 시스템 변수”부분을 참고하라.
AND CHAIN 절은 현재 트랜잭션이 끝나자마자 새로운 트랜잭션을 시작하도록 하고 새로운 트랜잭션은 이전 트랜잭션과 같
은 격리(isolation) 레벨을 갖는다. RELEASE절은 서버가 현재 트랜잭션을 끝낸 후 서버와의 연결을 끊도록 한다. NO 키워
드의 포함은 CHAIN이나 RELEASE완료를 억제 하도록 하는데 이는 compoletion_type 시스템 변수가 기본적으로 chain과
release완료를 하도록 설정하는데 유용하다.
기본적으로 MySQL은 자동 커밋(autocommit) 모드 상태로 운영된다. 이는 여러분이 테이블을 업데이트 하는 문장을 수행하
자마자MySQL은 디스크에 저장한다.
트랜잭션 안전 저장 엔진(예를 들면, InnoDB, BDB 혹은 NDB Cluster )을 사용하면 아래와 같은 문장으로 자동 커밋을 비
활성화 할 수 있다.:

:::MySQL Korea:::
SET AUTOCOMMIT=0;
AUTOCOMIT변수를 0으로 설정하여 자동 커밋 모드를 비 활성화 시킨 후, 변경 사항을 저장하기 위해 COMMIT을 사용하거

나 트랜잭션 시작 이후 만들어진 변경을 무시하기 위해서는 ROLLBACK을 사용해야 한다.
일련의 문장들에 대해 자동 커밋을 비활성화 하기 위해서는 TRANSACTION 문을 다음과 같이 사용하라.
START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summary=@A WHERE type=1;
COMMIT;
START TRANSACTION은 여러분이 COMMIT이나 ROLLBACK으로 트랜잭션을 끝낼 때까지 자동 커밋이 비활성화 상태

에 있게 된다. 자동 커밋은 이전 상태로 되돌아 간다.
BEGIN 과 BEGIN WORK 트랜잭션을 시작하기 위한 START TRANSACTION의 alias로 제공된다. START
TRANSACTION은 표준 SQL구문이고 ad-hoc 트랜잭션을 시작하기 위해 권장되는 방법이다.
BEGIN 문은 BEGIN … END 복합 문을 시작하는 BEGIN 키워드의 사용과는 다르다. 후자는 트랜잭션을 시작하지 않는다.
17.2.5장 “BEGIN…END 복합문”부분을 참고하라.
다음과 같이 트랜잭션을 시작 할 수 이다.:
START TRANSACTION WITH CONSISTENT SNAPSHOT;
WITH CONSISTENT SNAPSHOT 절은 가능한 저장 엔진에 대해 일관된 읽기를 시작하도록 한다. 현재, 이것은 InnoDB에
만 적용된다. 이는 어떤 InnoDB테이블로부터 SELECT에 의한 START TRANSACTION을 사용하는 것과 같은 효과를 갖
는다.14.2.10.4장 “일관된 비잠금 읽기(consistent non-blocking read)”부분을 참조하라.
WITH CONSISTENT SNAPSHOT 은 현재 트랜잭션의 격리 수준(isolation level)을 변경 하지 않도록 함으로써

consistent read(REPEATABLE READ 혹은 SERIALIZABLE)만 가능하게 하는 격리 수준에 대해서만 고정된 스냅샷을

:::MySQL Korea:::
제공한다.
트랜잭션 시작은 암시적인 UNLOCK TABLES가 수행되도록 한다.

최상의 결과를 위해, 트랜잭션들은 하나의 트랜잭션 저장 엔진에 의해 운영되는 테이블들을 사용하여 수행 되어야 한다. 그렇
지 않으면 다음 과 같은 문제들이 발생 할 수 있다.
● InnoDB와 BDB같은 하나 이상의 트랜잭션 지원 스토리지 엔진의 테이블을 사용할 경우, 트랜잭션 격리 수준은
SERIALIZABLE이 아니면 한 트랜잭션이 커밋 할 때 같은 테이블을 사용 하고 있는 다른 트랜잭션은 첫번째 트랜잭
션에 의해 만들어진 변경 사항들을 보게 된다. 이것은 트랜잭션의 원자성(atomicity)이 혼합된 엔진들과는 보증되지
않으며 비 일관성의 결과가 될 수 있다. (혼합 엔진 트랜잭션들이 드문 경우가 아니면 필요할 때 트랜잭션 단위로
SERIALIZABLE에 대한 격리 수준을 설정하기 위해 SET TRANSACTION ISOLATION LEVEL을 사용할 수 있
다.)
● 한 트랜잭션 안에서 비 트랜잭션 안전 테이블을 사용하면 자동 커밋 모드 상태에 관계없이 그 테이블들에 대한 변경
사항들이 동시에 저장된다.
한 트랜잭션 안에서 비 트랜잭션 테이블을 업데이트 한 후 ROLLBACK문을 사용하면

ER_WARNING_NOT_COMPLETE_ROLLBACK경고가 발생한다. 트랜잭션 안전 테이블 들에 대한 변경 사항은 취
소되지만 비 트랜잭션 안전 테이블들에 대한 변경 사항은 취소 되지 않는다.
각 트랜잭션은 COMMIT문에 의해 하나의 단위(one chunk)로 바이너리 로그에 저장된다. 롤백(roll back)되는 트랜잭션은
저장되지 않는다. (예외: 비 트랜잭션 테이블들에 대한 변경은 롤백 될 수 없다. 롤백된 트랜잭션이 비 트랜잭션 테이블들을
포함한다면 전체 트랜잭션은 그 테이블들에 대한 변경이 복제되었음을 확실히 하기 위해 롤백 문을 사용한다.) 5.12.3장 “바
이너리 로그” 부분을 참조하라.
SET TRANSACTION ISONLATION LEVEL문과 함께 트랜잭션을 위한 격리 수준(isolation level)을 변경할 수 있다.

13.4.5장 “SET TRANSACTION”부분을 참조 하라.
롤백(roll back)은 사용자에게 명시적인 알림 없이 일어날 수 있는 느린 수행이 될 수 있다(예를 들면, error가 발생하는 경
우) 이 때문에 SHOW PROCESSLIST는 암시적/명시적 rollback동안 연결을 위한 State컬럼에서 Rolling back을 보여준
다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
13.4.2. Roll back될 수 없는 SQL문

몇몇 SQL문은 rollback 될 수 없다. 일반적으로, database의 생과 삭제, 테이블의 변경, 혹은 저장 루틴 등과 같이 DDL(data
13.4. MySQL 트랜잭션 과 잠금문
defininition language)문을 포함 한다.
13.4.2 Roll back될 수 없는 SQL문
여러분은 이러한 SQL문을 포함하지 않도록 트랜잭션을 디자인 해야 한다. 만일 rollback될 수 없는 트랜잭션 에서 앞의 한 SQL문
을 사용한 후 뒤의 다른 SQL문이 실패하면 그 트랜잭션의 전체 영향은 ROLLBACK문을 사용하는 경우처럼 rollback될 수 없다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.4.3. 암묵적 Commit을 유발하는 SQL문
13. SQL 문법(SQL Statement Syntax) 다음과 같은 SQL 문 각각은 여러분이 그 문장을 수행하기 전에 COMMIT을 한 것처럼, 암묵적으로 트랜잭션을 끝낸다:
13.4.3 암묵적 Commit을 유발하는 SQL문 ● ALTER FUNCTION, ALTER PROCEDURE, ALTER TABLE, BEGIN, CREATE DATABASE, CREATE
FUNCTION, CREATE INDEX, CREATE PROCEDURE, CREATE TABLE, DROP DATABASE, DROP
FUNCTION, DROP INDEX, DROP PROCEDURE, DROP TABLE, LOAD MASTER DATA, LOCK TABLES, LOAD
DATA INFILE, RENAME TABLE, SET AUTOCOMMIT=1, START TRANSACTION, TRUNCATE TABLE,
UNLOCK TABLES.
● UNLOCK TABLES 은 테이블들이 잠겨있는 경우에만 트랜잭션을 커밋 한다.
● CREATE TABLE, CREATE DATABASE DROP DATABASE과TRUNCATE TABLE 문은 MySQL 5.0.6서부터 암묵
적 commit을 유발한다. ALTER FUNCTION, ALTER PROCEDURE, CREATE FUNCTION, CREATE
PROCEDURE, DROP FUNCTION 와 DROP PROCEDURE 문들은 MySQL 5.0.13 서부터 암묵적 commit을 유발한다.
● InnoDB 에서 CREATE TABLE 문은 단일 트랜잭션으로 처리 된다. 이는 사용자가 실행한 ROLLBACK이 트랜잭션 동안
사용자가 만든 CREATE TABLE문을 수행 하지 않음을 의미한다.
트랜잭션은 내포될 수 없다. 이는 여러분이 START TRANSACTION문이나 그와 같은 동의어를 가진 문장을 사용할 때 현재 트랜

잭션을 위해 수행 되는 암묵적 COMMIT의 결과이다.
:::MySQL Korea:::
제목검색
13.4.4. SAVEPOINT 와 ROLLBACK TO SAVEPOINT

SAVEPOINT identifier
13.4.4 SAVEPOINT 와 ROLLBACK TO

ROLLBACK [WORK] TO SAVEPOINT identifier
SAVEPOINT
RELEASE SAVEPOINT identifier
InnoDB 은 SAVEPOINT 와 ROLLBACK TO SAVEPOINT 문을 지원한다. MySQL 5.0.3서부터 RELEASE SAVEPOINT

와 ROLLBACK을 위한 옵션인 WORK 키워드가 지원된다.
SAVEPOINT 문은 identifier의 이름으로 명명된 트랜잭션 savepoint를 설정한다. 만일 현재 트랜잭션이 같은 이름으로

savepoint를 가지고 있다면 예전 savepoint는 삭제되고 새로운 것으로 대체 된다.
ROLLBACK TO SAVEPOINT 문은 명명된 savepoint로 롤백(roll back) 한다. 현재 트랜잭션이 savepoint후에 레코드들에
대한 변경은 롤백에서 수행되지 않지만, InnoDB는 savepoint뒤에 메모리에 저장된 열 잠금을 풀지 않는다. (새로이 삽입된 레
코드에 대해, 잠금 정보는 레코드에 저장된 트랜잭션 ID에 따라 전달 된다. 이 경우, 열 잠금은 실행 취소시 풀린다.) 명명된
savepoint보다 뒤에 설정된 Savepoints는 삭제된다.
만일 ROLLBACK TO SAVEPOINT 문이 다음 에러를 리턴 하면, 지정된 이름을 가진 savepoint가 존재 하지 않음을 의미한

다.

:::MySQL Korea:::
ERROR 1181: Got error 153 during ROLLBACK
RELEASE SAVEPOINT 문은 현재 트랜잭션의 savepoint의 집합으로부터 명명된 savepoint를 삭제 한다. commit이나

rollback이 발생하지 않는다. Savepoint가 존재 하지 않으면 에러이다.
savepoint를 지정하지 않는 COMMIT이나 ROLLBACK을 실행하면 현재 트랜잭션의 모든 savepoint는 삭제 된다.
MySQL 5.0.17서부터는 저장된 함수가 불리거나 트리거가 활성화 될 때 새로운 savepoint 레벨이 생성된다. 이전 레벨에서
savepoint들은 사용불가능하게 되고 새로운 레벨의 savepoint되 충돌을 피하게 된다. 함수나 트리거가 종료되면 생성된
savepoint 들은 삭제되고 이전 savepoint 레벨은 복귀된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.4.5. LOCK TABLES 와 UNLOCK TABLES
13. SQL 문법(SQL Statement Syntax) LOCK TABLES

13.4. MySQL 트랜잭션 과 잠금문 tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}
13.4.5 LOCK TABLES 와 UNLOCK TABLES [, tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}] ...
UNLOCK TABLES
LOCK TABLES 은 현재 쓰레드를 위해 테이블들을 잠근다. 테이블들이 현재 쓰레드에 의해 잠겨 있으면 모든 잠금들이 획득

(acquired)될 때까지 block된다. UNLOCK TABLES는 현재 쓰레드에 의해 설정되 모든 잠금을 해제 한다. 현재 쓰레드에 의해
잠긴 모든 테이블들은 쓰레드가 또 다른 LOCK TABLES을 실행 시키거나 서버와의 연결이 닫힐 때 암묵적으로 잠금을 해제 한
다.
테이블 잠금은 다른 클라이언트들에 의한 부적절한 읽기나 쓰기를 제한 한다. 잠금을 소유한 클라이언트는 그것이 읽기 잠금일지라
도 DROP TABLE과 같은 테이블 수준의 연산들도 수행 할 수 있다.
다은 트랜잭션 가능한 테이블들에 대한 LOCK TABLES의 사용에 유념 하라:
● LOCK TABLES 은 안전한 트랜잭션이 아니고 테이블을 잠그려는 시도 이전에 수행 중인 모든 트랜잭션을 암묵적으로
commit한다. 또한 트랜잭션의 시작(예를 들면, START TRANSACTION)은 UNLOCK TABLES을 암묵적으로 수행한
다.(13.4.3장 “암묵적 commit을 유발하는 SQL문”을 참조하라.)
● InnoDB테이블과 같은 트랜잭션 테이블들과 함께 LOCK TABLES를 사용하는 정확한 방법은 AUTOCOMMIT=0 으로
설정 하고 트랜잭션을 명시적으로 commit할 때까지 UNLOCK TABLES를 호출 하지 않는 것이다. 여러분인 LOCK
TABLES를 호출할 때 InnoDB는 그자신의 table잠금을 가지게 되고 MySQL은 그 자신의 테이블 잠금을 가진다. InnoDB
는 다음 commint에서 테이블 잠금을 해제 하지만, MySQL이 그 테이블 잠금을 해제 하기 위해서는 여러분이 UNLOCK
TABLES를 호출 해야 한다. InnoDB가 LOCK TABLES의 호출 후에 테이블 잠금을 즉시 해제 하고 데드락(deadlock)이
매우 쉽게 발생 할 수 있기 때문에 AUTOCOMMIT=1을 가질 필요는 없다. 오래된 application들이 불필요한 deadlock을
피하는 것을 돕기 위해 AUTOCOMMIT=1일지라고 InnoDB 테이블 잠금을 얻지 않는 것에 유의하라.

:::MySQL Korea:::
● ROLLBACK 은 MySQL의 비 트랜잭션 테이블 잠금 들을 해제 하지 않는다.
LOCK TABLES을 사용하기 위해, 여러분은 포함된 테이블들에 대한 SELECT권한 및 LOCK TABLES권한을 가지고 있어야 한
다.
LOCK TABLES를 사용하는 주된 이유는 트랜잭션들을 에뮬레이트(emulate)하기 위해서 혹은 테이블을 업데이트 할 때 좀더 속

도를 올리기 위해서이다. 이는 뒤에서 좀더 상세히 설명된다.
한 쓰레드가 한 테이블에서 READ 잠금을 가지면, 쓰레드는 그 테이블에서 오직 읽기만 가능하다. 테이블에 대해 WRITE잠금만
가진 경우, 잠금을 소유한 쓰레드만 그 테이블에 쓸 수 있다. 다른 쓰레드들은 그 잠금이 해제 될 때까지 block된다.
READ LOCAL 과 READ 의 차이는 READ LOCAL이 잠금을 소유한 동안 실행될 충돌 없는(non-conflicting) INSERT 문들을
허용한다. 그러나, 이것은 여러분이 잠금을 소요하는 동안 MySQL외부에서 데이터베이스 파일을 조작 하려 할 때는 사용될 수 없
다. InnoDB테이블들에 대해 READ LOCAL은 MySQL 5.0.13에서의 READ과 같다.( 그 이전에는, READ LOCAL은 아무 것도
하지 않았다. 즉 테이블에 대해 전혀 잠금을 하지 않으며 InnoDB 테이블들에 대해 READ LOCAL의 사용은 일관된 읽기 SELECT
가 같은 읽을 하고 잠금이 필요하지 않기 때문에 반대(deprecated) 된다.)
LOCK TABLES을 사용할 때, 여러분의 질의에서 사용하려는 모든 테이블들에 대해 잠금을 설정해야 한다.
LOCK TABLES문으로 획득된 잠금들이 발휘되는 동안 여러분은 그 SQL문에 의해 lock되지 않은 어떤 테이블들도 접근 할 수 없

다. 또한 여러분은 하나의 질의에서 여러 차레 잠금 테이블을 사용할 수 없다.
각 alias에 대한 잠금을 가져야 하는 경우에는 대신 alias를 사용하라
mysql> LOCK TABLE t WRITE, t AS t1 WRITE;

mysql> INSERT INTO t SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> INSERT INTO t SELECT * FROM t AS t1;
질의가 alias를 이용하여 테이블을 참조한다면 여러분은 같은alias를 사용하여 그 테이블을 잠금(lock)설정을 해야 한다. Alias를
명시 하지 않고 테이블에 대한 잠금은 수행되지 않는다:

:::MySQL Korea:::
mysql> LOCK TABLE t READ;

mysql> SELECT * FROM t AS myalias;
ERROR 1100: Table 'myalias' was not locked with LOCK TABLES
반대로, 여러분이 alias를 사용하여 테이블을 잠그면, 질의 내에서는 그 alias를 사용해서만 참조해야 한다.:
mysql> LOCK TABLE t AS myalias READ;

mysql> SELECT * FROM t;
ERROR 1100: Table 't' was not locked with LOCK TABLES
mysql> SELECT * FROM t AS myalias;
WRITE 잠금은 업데이트가 가능한 빨리 처리되도록 하기 위해 READ 잠금들 보다 높은 우선순위를 가진다. 이는 만약 한 쓰레드
가 READ 잠금을 가지고 다른 쓰레드가 WRITE 잠금을 요청 한 경우 READ 잠금 요청은 WRITE 쓰레드가 잠금을 가지고 그것을
해제할 때까지 대기 해야 함을 의미한다. 여러분은 그 쓰레드가 WRITE lock을 기다리는 동안 READ lock들을 갖도록 허용하기
위해 LOW_PRIORITY WRITE lock을 사용할 수 있다. 어떤 쓰레드도 READ lock을 가지지 않는 때가 있는 것이 확실 한 경우에
만 LOW_PRIORITY WRITE lock을 사용해야 한다.
LOCK TABLES 는 다음과 같이 작용한다.:

1. 내부적으로 정의된 순서에 따라 모든 테이블들이 lock되도록 정렬한다. 사용자 관점에서 이 순서는 정의 되지 않는
다.
2. 한 테이블이 read/write lock으로 잠긴 경우 read 보다 write lock을 앞에 놓는다.
3. 쓰레드가 모든 lock을 가질 때까지 한번에 한 테이블만 잠근다.
이 정책은 테이블 잠금이 deadlock일으키지 못하도록 한다. 그러나 여러분이 이 정책에 대해 알아야 할 다른 사항들이 있다: 한 테
이블에 대해 LOW_PRIORITY WRITE를 사용하는 경우 MySQL은 READ lock을 원하는 쓰레드가 없을 때까지 이런 잠금 동안
대기 함을 의미한다. 그 쓰레드가 WRITE lock을 가지고 잠금 테이블 리스트에서 다음 테이블에 대한 lock을 얻기 위해 기다리면,
다른 모든 쓰레드들은 WRITE lock이 해제 되길 기다린다. 만약 이것이 여러분의 응용프로그램에 심각한 문제가 된다면 여러분의
테이블들 중 일부를 안전한 트랜잭션 테이블로의 변환을 고려해야 한다.
여러분은 테이블 lock을 기다리고 있는 쓰레드를 안전하게 종료 시키기 위해 KILL을 사용할 수 있다. 13.5.5.3장 “KILL”부분

:::MySQL Korea:::
을 참조 하라.
INSERT가 분리된 쓰레드에 의해 수행되는 경우 때문에 INSERT DELAYED를 사용하는 어떤 테이블에 대해서도 lock을 설정
할 수 없음을 유의하라
모든 단일 UPDATE 문들은 하나의 작은 단위이므로 테이블들에 잠금을 설정할 필요는 없다. 이는 어떤 쓰레드도 현재 수행 중인
SQL문을 방해 할 수 없음을 의미한다. 그러나 테이블 잠금이 이점을 제공하는 몇 가지 경우가 있다.:
● MyISAM 테이블들에서 많은 연산을 수행하려면, 사용하려는 테이블을 잠그는 것이 빠르다. MyISAM 테이블들에 대한 잠
금은 삽입,업데이트나 삭제시 속도를 높여준다. If you are going to run many operations on a set of MyISAM tables,
it is much faster to lock the tables you are going to use. Locking MyISAM tables speeds up inserting, updating,
or deleting on them. 어떤 쓰레드도 READ잠금이 된 테이블을 업데이트 할 수 없으며 어떤 쓰레드도 WRITE잠금이 된
테이블을 접근할 수 없다.
MyISAM연산이 LOCK TABles에서 빠른 이유는 MySQL이 UNLOCK TABLE이 호출 되기 전까지 잠금 설정된 테이블
들에 대해 키 캐쉬(cache)를 삭제 하지 않기 때문이다. 일반적으로 key cache는 각 SQL문 이후에 비워진다.
● MySQL에서 트랜잭션을 지원하지 않는 저장 엔진을 사용하면, 여러분은 어떠한 쓰레드도 SELECT 와 UPDATE사이에
올 수 없도록 하기 위해 LOCK TABLES를 사용해야 한다. 여기 보여지는 예제는 안전하게 수행하기 위해 LOCK
TABLES를 요구 한다:
LOCK TABLES trans READ, customer WRITE;

SELECT SUM(value) FROM trans WHERE customer_id=some_id;
UPDATE customer
SET total_value=sum_from_previous_statement
WHERE customer_id=some_id;
UNLOCK TABLES;
LOCK TABLES이 없으면 다른 쓰레드가 SELECT와 UPDATE문이 수행 중인 가운데 trans 테이블에 새로운 레코드를
삽입할 가능성이 있다.
여러분은 많은 경우 관련된 업데이트들(UPDATE customer SET value=value+new_value)의 사용이나 LAST_INSERT_ID()

:::MySQL Korea:::
함수를 사용함으로써 LOCK TABLES의 사용을 피할 수 있다. 1.9.5.3장 “트랜잭션과 atomic 연산”부분을 참조하라.
또한 GET_LOCK()과 RELEASE_LOCK()과 같은 추가적은 잠금 함수들을 사용하여 테이블 잠금을 피할 수 있다. 이들 잠금들은

서버의 hash테이블에 저장되고 높은 속도를 올리기 위해 pthread_mutes_lock()과 pthread_mutex_unlock()으로 구현된다.
12.9.4장 “Miscellaneous 함수”부분을 참조 하라.
잠금 정책에 관한 좀더 상세한 사항을 원한다면 7.3.1장 “잠금 방법”부분을 참조하라.
FLUSH TABLES WITH READ LOCK문을 사용하여 일기 잠금으로 모든 데이터베이스의 모든 테이블들에 대해 잠금 설정을 할
수 있다. 13.5.5.2장 “FLUSH”부분을 참조 하라. 이것은 여러분이 시간에 snapshot을 가질 수 있는 Veritas와 같은 파일 시스템
을 가진 경우 backup하기 위한 매우 편리한 방법이다.
Note: 잠금된 테이블에 ALTER TABLE을 사용할 경우 unlock이 될수 있다. 이에 대한 사항은 A.7.1장 “ALTER TABLE의 문
제점”부분을 참조하라.

:::MySQL Korea:::
제목검색

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL

{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }
이 SQL문은 현재 세션을 위해 전역적으로 다음 트랜잭션을 위한 트랜잭션 격리 레벨(isolation level)을 설정한다.
SET TRANSACTION의 기본 행동은 다음 트랜잭션을 위한 격리 레벨을 설정하는 것이다. GLOBAL키워드를 사용하는 경우 그

SQL문은 그 시점에 생성된 모든 새 연결들에 대해 전역적으로 기본 트랜잭션 레벨을 설정한다. 이미 존재하는 연결들은 영향 받지
않는다. 여러분은 이것을 위해 SUPER권한을 가져야 한다. SESSION 키워드의 사용은 현재 연결에서 수행될 모든 미래의 트랜잭
션에 대한 기본 트랜잭션 레벨을 설정한다.
각 InnoDB트랜잭션 격리레벨을 위한 설명은 14.2.10.3장 “InnoDB와 TRANSACTION ISONLATION LEVEL”부분을 참조

하라. InnoDB는 MySQL 5.0에서 이들 각 레벨을 지원한다. 기본 레벨은 RPEATABLE READ이다.
Mysqlid를 초기 기본 전역 격리 레벨을 설정하기 위해서는 trasaciton-isolation 옵션을 사용하라. 5.2.1장 “mysql command
option”을 참조하라.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.4.7. XA 트랜잭션
13. SQL 문법(SQL Statement Syntax) 13.4.7.1. XA Transaction SQL Syntax

13.4. MySQL 트랜잭션 과 잠금문 13.4.7.2. XA Transaction States
13.4.7.1 XA Transaction SQL 신텍스 MySQL 5.0.3 과 그 상위 버전은 XA 트랜잭션을 위한 서버측 지원을 제공한다. 현재 이 지원은 InnoDB저장 엔진에 대해 가능하
다. MySQL XA 구현은 X/Open CAE 문서 인 Distributed transaction processing: XA Specification을 기반으로 구현되었다.
이 문서는 Open Group에 의해 작성되었고 http://www.opengroup.org/public/pubs/catalog/c193.htm에서 얻을 수 있다. 현재
XA 구현의 제한은 1.5장 “XA 트랜잭션에서의 제약 사항” 부분을 참조하라.
client측에서는 특별한 요구 사항이 없다. MySQL 서버에 대한 XA 인터페이스는 XA 키워드로 시작하는 SQL문으로 이루어져 있
다. MySQL client프로그램은 SQL문을 보내고 XA문 인터페이스에 대한 의미를 이해할 수 있어야 한다. 최근 클라이언트 library
에 링크되지 않아도 된다. 기존 client library들이 또한 작업할 것이다.
MySQL 컨넥터(connectors)들 중, MySQL Connector/J 5.0.0은 XA 디렉토리를 지원한다(여러분을 위한 XA SQL문 인터페이
스를 다루는 클래스 인터페이스를 의미한다).
XA는 분산 트랜잭션을 지원한다. 즉, 여러 개의 분리된 트랜잭션 리소스들로 하여금 하나의 글로벌(global) 트랜잭션에 참여 하도
록 하는 것을 의미한다. 트랜잭션 리소스들은 대부분 RDBMS들이지만 다른 리소스들이 될 수도 있다.
하나의 global 트랜잭션은 그 들 안에서 트랜잭션 되는 몇 가지 action들을 포함한다. 그러나 그 모두는 하나의 그룹으로서 성공적
으로 완료되거나 하나의 그룹으로서 롤백(rollback)된다. 본질적으로, 이것은 ACID 속성을 “up a level”로 하여 여러 개의
ACID트랜잭션들이 하나의 global 연산의 구성원들로서 조화를 이루어 수행될 수 있게 된다. (그러나, 분산 트랜잭션에 경우
ACID 속성을 위해서는 SERIALIZABLE 격리 레벨을 사용해야 한다. 비-분산 트랜잭션을 위해 REPEATABLE READ를 사용해
도 되지만 분산 트랜잭션의 경우에는 그럴 수 없다).
몇 가지 분산 트랜잭션의 예를 들면:

:::MySQL Korea:::
● 하나의 응용 프로그램이 하나의 RDBMS와 함께 메시징 서비스를 결합하여 하나의 통합 툴로서 작동할 수 있다. 이
application은 메시지 전송, 검색(retrieval), 그리고 하나의 트랜잭션 database를 포함하는 처리(processing)가 하나의
global 트랜잭션 안에서 일어나도록 한다. 여러분은 이것을 “transaction email”로 생각할 수도 있다.
● 한 응용 프로그램은 MySQL서버와 Oracle 서버와 같이 이기종의 데이터베이스 서버들을 포함하는 action들을 수행하는
데, 이때 여러 서버들을 포함하는 action들은 각 서버들에게 분리된 트랜잭션이 아닌 하나의 global 트랜잭션의 부분으로
발생 해야 한다.
● 한 은행이 RDBMS에 계좌 정보를 가지고있고 ATM기를 통해서 돈을 받는다. 이때 ATM의 action들은 그 계좌에게 정확
하게 반영되어야 한다. 그러나 이 작업은 RDBMS 혼자서 이루어질 수 없다. 하나의 global트랜잭션 매니저(manager)가
ATM과 데이터베이스 리소스들을 통합하여 전반적인 트랜잭션들의 일관성을 유지 시켜주어야 한다.
global트랜잭션을 사용하는 응용 프로그램들은 하나 혹은 그 이상의 리소스 매니저와 트랜잭션 매니저를 포함한다:
● 리소스 매니저(Resource Manager)는 트랜잭션 리소스들에 대한 접근을 제공한다. 데이터베이스 서버는 하나의 리소스
매니저이다. 이것은 리소스 매니저에 의해 관리 되는 트랜잭션을 commit하거나 rollback할 수 있어야 한다.
● 트랜잭션 매니저(Transaction Manager)는 하나의 global트랜잭션의 부분인 트랜잭션들을 통합(coordination)한다. 이것
은 이들 트랜잭션 각각을 다루는 리소스 매니저들과 함께 정보를 주고받는다. 하나의 global 트랜잭션에서 개별적인 트랜잭
션은 global 트랜잭션의 “branches”이다. Global트랜잭션과 그 branch들은 나중에 설명되는 naming scheme에 의해
구별된다.
XA MySQL의 MySQL구현은 MySQL서버로 하여금 한 global 트랜잭션 안에서 XA트랜잭션들을 다루는 하나의 리소스 매니저
(RM)으로 행동하도록 한다. MySQL서버에 연결하는 클라이언트 프로그램은 트랜잭션 매니저로서 행동한다.
한 global 트랜잭션을 완료 하기 위해서는 어떤 구성원이 포함되어 있고, 각 구성원이 commint되거나 rollback되는 시점을 언제
가져 올지에 대해 알고 있어야 한다. 각 구성원이 성공 하기 위한 능력을 어떻게 보고 하느냐에 따라서 그것들 모두가 commit 되거
나 rollback되어야 한다. 즉, 모든 구성원들이 commit되거나, 모든 구성원들이 roll back되어야 한다. 하나의 global트랜잭션을 다
루기 위해서는 어떤 구성원이나 연결 네트웍도 실패할 수 있다는 것을 유념할 필요가 있다.
하나의 global트랜잭션을 실행하기 위한 process는 2단계 commit(2PC)를 사용한다. 이것은 global 트랜잭션의 branch들에 의
해 수행되는 action들 뒤에 일어난다.
1. 첫번째 단계에서는 모든 브랜치(branch/분기)들이 준비된다. 즉, 트랜잭션 매니저™에 의해 알려진 모든 것들이

:::MySQL Korea:::
commit할 준비 상태가 된다. 일반적으로 이것이 의미하는 것은 브랜치(branch)를 관리하는 각각의RM(리소스 매니저)
는 안정된 스토리지에서 브랜치의 액션들을 기록한다는 것이다. 이 브랜치들은 이것을 할 수 있는지, 그리고 결과가 두번
째 단계에서 사용되는지를 표시한다.
2. 두번째 단계에서는 TM(트랜잭션 매니저)가 RM(리소스 매니저)에게 커미트할 것이지 또는 롤백할 것인지 명령한
다. 만약 모든 브랜치들이 준비되어 있을 때 커미트가 불가능하다고 표시한다면, 모든 브랜치들은 롤백하라고 명령한다.
몇 가지 경우global 트랜잭션은 한 단계 commit을 사용한다. 예를 들면, 트랜잭션 매니저가 global 트랜잭션이 단지 하나의 트랜잭
션 자원으로 성 되었다는 것을 알았을 때 그 자원은 동시에 준비되고 commit되도록 이야기 될수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.4.7.1. XA Transaction SQL 신텍스
13.4. MySQL 트랜잭션 과 잠금문 MySQL에서 XA 트랜잭션을 수행 하기 위해서는 다음 문장들을 사용하라:
XA {START|BEGIN} xid [JOIN|RESUME]
XA END xid [SUSPEND [FOR MIGRATE]]
XA PREPARE xid
XA COMMIT xid [ONE PHASE]
XA ROLLBACK xid
XA RECOVER

:::MySQL Korea:::
XA START에서 JOIN 과RESUME 절은 지원되지 않는다.
XA END 에 대해 SUSPEND [FOR MIGRATE] 절은 지원되지 않는다.
각 XA 문은 XA키워드로 시작하고, 그들 대부분은 xid 값을 필요로 한다. 하나의 xid는 XA 트랜잭션의 구별자 이다. 이것은 그 문
장이 적용되는 트랜잭션을 가리킨다. xid값들은 클라이언트에 의해 제공되거나 MySQL 서버에의해 생성된다. xid값은 하나에서
세개 부분으로 나뉘어진다.
xid: gtrid [, bqual [, formatID ]]
gtrid 는 global 트랜잭션 구별자이고, bqual은 가지 한정자(branch qualifier) 이다. formatID는 gtrid와 bqual 값들에 의해 사용
되는 포맷을 지정하는 숫자이다. Bqual과 formatID는 옵션 사항이다. 기본 bqual값은 ‘ ‘이다. 기본 formatID값은 1이다.
gtrid 와 bqual 는 최대 64자리 길이의 문자열이다. Gtrid와 bqual은 여러 차례 명시 될 수 있다. 인용 문구인 ‘ab’로 사용하거
나 16진수 문자열인 (0x6162,X’ab) 혹은 비트 값은 (b’nnn’)으로 사용할 수 있다.
formatID 는 unsigned integer이다.
gtrid 와 bqual 값들은 MySQL 서버의 XA 지원 루틴에 의해 byte들로 해석된다. 그러나, XA문을 포함한 한 SQL문이 해석되는 동
안에는 서버는 특별한 문자열 집합을 사용하여 작업한다. 안전을 위해 gtrid와 bqual을 16진수 문자열로 사용하라.
xid 값들은 전형적으로 트랜잭션 매니저에 의해 생성된다. 하나의 트랜잭션 매니저에 의해 생성된 값들은 다른 트랜잭션 매니저에
의해 생성된 값들과 달라야 한다. 하나의 트랜잭션 매니저는 XA RECORVER문에서 리턴 된 값들 중에서 자신의 값을 인지할 수
있어야 한다.

:::MySQL Korea:::
XA START xid 는 주어진 xid값을 이용하여 하나의 XA 트랜잭션을 시작한다. 각 XA 트랜잭션은 유일한 xid값을 가져야 하며
그 값은 다른 XA 트랜잭션에 의해 사용될 수 없어야 한다. 유일성은 gtrid와 bqual 값들을 이용하여 획득된다. XA 트랜잭션을 위
한 모든 다음 XA트랜잭션 문은 XA START 문에서 주어진 값을 xid값을 이용하여 명시 되어야 한다. 여러분이 이들 문장들 중 하
나를 사용하지만 몇몇 기존의 XA트랜잭션에 부합하지 않는 xid값을 명시 한다면, 에러가 발생한다.
하나 혹은 그 이상의 XA트랜잭션은 같은 global 트랜잭션의 부분일 수 있다. 하나의 주어진 global트랜잭션 안에서 모든 XA 트랜
잭션은 같은 xid 값에서 같은 gtrid값을 사용해야 한다. 이러한 이유로, gtrid값은 전역적으로(globally)유일해야 하며 이로써 XA
트랜잭션이 어떤 global 트랜잭션의 부분인지에 관한 모호성이 사라진다. xid값의 bqual 부분은 하나의 global 트랜잭션 안에서
각 XA트랜잭션과 달라야 한다. (bqual 값들이 달라야 하는 요구 사항은 현재 MySQL XA 구현의 한계이다. 이것은 XA 명시의 부
분이 아니다)
XA RECOVER 문은 PREPARED 상태에 있는 MySQL 서버에서 XA트랜잭션 들을 위한 정보를 리턴한다. (13.4.7.2 장 “XA 트
랜잭션 상태”등을 참조 하라) 결과는 서버상에서 XA 트랜잭션을 위한 하나의 레코드들 포함한다.
XA RECOVER 결과 열은 다음처럼 보인다. (예를 들면 xid값은 ‘abc’, ‘def’ 와 7로 구성된다):
mysql> XA RECOVER;
+----------+--------------+--------------+--------+
| formatID | gtrid_length | bqual_length | data |
+----------+--------------+--------------+--------+
| 7| 3| 3 | abcdef |
+----------+--------------+--------------+--------+

:::MySQL Korea:::
결과 컬럼들은 다음과 같은 의미들을 갖는다:
● formatID 은 트랜잭션 xid의 formatID 부분이다.

● gtrid_length 는 xid의 gtrid부분에 대한 바이트 길이이다.
● bqual_length 는 xid의 bqual 부분에 대한 바이트 길이이다.
● data 는 xid의 gtrid와 bqual부분에 대한 연결이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.4.7.2. XA Transaction States
13.4. MySQL 트랜잭션 과 잠금문 하나의 XA트랜잭션은 다음 상태들을 통해 진행 된다:
1. 하나의 XA 트랜잭션을 시작하기 위해서는 XA START를 사용하고 ACTIVE 상태로 둔다.
2. 하나의 ACTIVE XA 트랜잭션에 대해 트랜잭션을 구성하는 SQL문들을 호출한다. 그 다음 XA END문을 사용한다.
XA END는 트랜잭션을 IDLE상태로 변경 한다.
3. 하나의 IDLE XA트랜잭션에 대해, XA PREPARE 문이나 XA COMMIT … ONE PHASE 문을 사용할 수 있다:
• XA PREPARE 은 트랜잭션을 PREPARE상태로 한다. 이때 XA RECOVER문은 XA RECOVER가
PREPARED상태에 있는 모든 XA 트랜잭션을 나열하기 때문에 출력 값으로 트랜잭션의 xid 값을 포함할 것이
다.
• XA COMMIT ... ONE PHASE 는 트랜잭션을 준비하고 commit한다. xid값은 트랜잭션이 끝나기 때문에
XA RECOVER에 의해 나열되지 않을 것이다.
4. PREPARED XA 트랜잭션에 대해 그 트랜잭션을 commit하고 종료 하기 위해 XA COMMIT문을 사용 할 수 있다.
혹은 트랜잭션을 롤백하고 종료하기 위해 XA ROLLBACK 을 사용할 수 있다.
아래는 global트랜잭션의 일 부분으로서 하나의 테이블에 하나의 레코드를 삽입하는 간단한 트랜잭션을 예로 든다.
mysql> XA START 'xatest';

:::MySQL Korea:::
mysql> INSERT INTO mytable (i) VALUES(10);
mysql> XA END 'xatest';
mysql> XA PREPARE 'xatest';
mysql> XA COMMIT 'xatest';
주어진 클라이언트 연결에서 XA 트랜잭션과 local(non-XA)트랜잭션들은 상호 배타적이다. 예를 들면 XA START가 XA 트랜잭

션을 시작하기 위해 사용된 경우 local 트랜잭션은 XA 트랜잭션이 commit되고 롤백 될 때 까지 시작될 수 없다. 반대로 하나의
local 트랜잭션이 START TRANSACTION으로 시작 된다면, XA 문들은 그 트랜잭션이 commit되고 롤백 될 때까지 사용될 수
없다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5. 데이터베이스 관리문
13. SQL 문법(SQL Statement Syntax) 13.5.1. 계정관리문

13.5. 데이터베이스 관리문 13.5.2. 테이블 유지보수문
13.5 데이터베이스 관리문 13.5.3. SET
13.5.1 계정 관리문 13.5.4. SHOW
13.5.1.1 CREATE USER 13.5.5. 기타 관리문

13.5.1.3 GRANT
13.5.1.5 REVOKE
13.5.3 SET
13.5.4 SHOW

:::MySQL Korea:::

13.5.4.15 SHOW LOGS
13.5.5 기타 관리 문
13.5.5.2 FLUSH
13.5.5.3 KILL

:::MySQL Korea:::
13.5.5.5 RESET

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.1. 계정 관리문
13. SQL 문법(SQL Statement Syntax) 13.5.1.1. CREATE USER

13.5. 데이터베이스 관리문 13.5.1.2. DROP USER
13.5.1 계정 관리문 13.5.1.3. GRANT
13.5.1.1 CREATE USER 13.5.1.4. RENAME USER
13.5.1.2 DROP USER Syntax 13.5.1.5. REVOKE

13.5.1.6. SET PASSWORD
13.5.1.3 GRANT
MySQL 계정 정보는 mysql 데이터베이스의 테이블에 저장된다. 이 데이터베이스와 액세스 컨트롤 시스템은 5장 데이터베이스 관
13.5.1.5 REVOKE
리 부분에서 광범위하게 다루고 있으며, 추가적인 세부사항은 컨설팅이 필요하다.
중요: MySQL의 몇몇 릴리즈들은 새로운 권한과 기능이 추가된 grant 테이블 구조의 변화를 소개하고 있다.MySQL을 새버전으로
업데이트할 때면 언제나 테이블들이 현재의 구조로 구성되어 있어 새로운 권한을 가질 수 있는지 확인하기 위해서 grant 테이블을
업데이트 해야 한다. 5.6.2, “mysql_upgrade — MySQL 업그레이드를 위한 테이블 체크”장을 참조하라.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.1.1. CREATE USER
13.5. 데이터베이스 관리문 CREATE USER user [IDENTIFIED BY [PASSWORD] 'password']
13.5.1 계정 관리문
[, user [IDENTIFIED BY [PASSWORD] 'password']] ...
CREATE USER 문은 MySQL 5.0.2 버전에서 새롭게 추가되었다. 이 문은 새로운 MySQL 계정을 생성한다. 이것을 사용하기 위
13.5.1.3 GRANT
해서 MySQL 용 글로벌 CREATE USER 권한이나NSERT 권한을 갖고 있어야 한다. 각각의 계정에 CREATE USER 는 권한이
없는 mysql.user 테이블에 새로운 레코드를 생성한다. 계정이 이미 존재한다면 에러가 발생한다. 각각의 계정은 GRANT 문에 관
13.5.1.5 REVOKE 하여 같은 포맷으로 명명된다; 예를들면, jeffrey'@'localhost'.
계정 이름의 사용자와 호스트(Host) 부분은 그 계정에 대한 User 테이블의 레코드상의 User 와 Host 컬럼 값과 일치한다.
계정은 임의의 IDENTIFIED BY 절을 가진 패스워드가 주어질 수 있다. user 값과 패스워드는 GRANT 문에 대하여 같은 방법으
로 주어진다. 특히 단조로운 텍스트에서 패스워드를 지정하기 위해서, PASSWORD 키워드는 생략하라. PASSWORD() 기능에 의
해 리턴된 해쉬값으로 패스워드를 지정하기 위해서 PASSWORD 키워드를 포함하라.13.5.1.3 “GRANT 신텍스” 장을 참조하라
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.1.2. DROP USER Syntax
13.5. 데이터베이스 관리문 DROP USER user [, user] ...
13.5.1 계정 관리문
DROP USER 문은 하나 또는 그 이상의 MySQL 계정을 제거한다. 이것을 사용하기 위해서, mysql용으로 글로벌 CREATE
USER 권한 또는 DELETE 권한을 가지고 있어야 한다. 각 계정은 GRANT 문에 대하여 같은 포맷을 사용하여 명명된다. 예를들
어, 'jeffrey'@'localhost'. 계정 이름의 사용자와 호스트(Host) 부분은 그 계정에 대한 User 테이블의 레코드상의 User 와 Host
13.5.1.3 GRANT
컬럼 값과 일치한다.
13.5.1.5 REVOKE
MySQL 5.0.0에서 DROP USE는 오직 권한이 없는 계정만을 제거한다. MySQL 5.0.2에서는 계정 권한까지 제거하도록 수정되었
다. 이것은 한 계정을 제거하는 처리절차가 MySQL버전에 따라 다르다는 것을 의미한다.
MySQL 5.0.2에서, 계정을 제거할 수 있으며, 그 권한은 다음과 같다:
DROP USER user;
문은 모든 grant테이블로부터 계정에 대해 권한 로우를 제거한다.
MySQL 5.0.0 와 5.0.1에서, DROP USER 는 오직 권한이 없는 MySQL 계정만을 삭제한다. 이 MySQL 버전에서 user 테이블로
부터 각각의 계정 레코드를 삭제하는 데에만 작용한다. 한 MySQL 계정을 완전히 삭제하려면(그것의 모든 권한을 포함해), 다음
의 프로시져를 차례로 사용해야 한다:
1. 계정이 가지고 있는 권한을 결정하기 위해서SHOW GRANTS를 사용한다. 13.5.4.12, “SHOW GRANTS”장을

:::MySQL Korea:::
참조하라.
2. SHOW GRANTS 를 통해 보여주는 권한을 취소하기 위해서 REVOKE를 사용한다. 이것은 user테이블을 제외한 모
든 grant로부터 계정에 대한 로우를 삭제하고 user테이블에 있는 글로벌 권한을 취소한다. 13.5.1.3, “GRANT 신텍
스”. 장을 참조하라
3. user 테이블 레코드를 제거하기 위해 DROP USER 를 사용하여 계정을 삭제한다.
중요: DROP USER 는 어떤 오픈 유저 세선을 자동적으로 종료하지 않는다. 오히려 하나의 오픈 세션을 가진 유저가 드롭되는 경우
에, 명령문은 그 사용자의 세션이 드롭될 때까지 효력을 발생하지 않는다. 세션이 종료되기 이전에, 사용자가 드롭되고, 사용자가
로그인을 시도하면 실패할 것이다. This is by design.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.1.3. GRANT
13. SQL 문법(SQL Statement Syntax) GRANT priv_type [(column_list)] [, priv_type [(column_list)]] ...
13.5. 데이터베이스 관리문 ON [object_type] {tbl_name | * | *.* | db_name.*}
13.5.1 계정 관리문 TO user [IDENTIFIED BY [PASSWORD] 'password']
13.5.1.1 CREATE USER [, user [IDENTIFIED BY [PASSWORD] 'password']] ...
13.5.1.2 DROP USER Syntax [REQUIRE

NONE |
13.5.1.3 GRANT
[{SSL| X509}]
[CIPHER 'cipher' [AND]]
13.5.1.5 REVOKE
[ISSUER 'issuer' [AND]]
[SUBJECT 'subject']]
[WITH with_option [with_option] ...]
object_type =
TABLE
| FUNCTION
| PROCEDURE
with_option =
GRANT OPTION
| MAX_QUERIES_PER_HOUR count
| MAX_UPDATES_PER_HOUR count
| MAX_CONNECTIONS_PER_HOUR count
| MAX_USER_CONNECTIONS count

:::MySQL Korea:::
GRANT 문은 시스템 관리자가 MySQL 사용자 계정을 생성하고 계정으로부터 권한을 부여할 수 있도록 한다. GRANT를 사용하
려면, 반드시GRANT OPTION 권한을 가지고 있어야 하며, 또한 스스로 권한을 부여할 수 있어야 한다. REVOKE 문과 관련이 있
으며, 관리자가 계정권한을 삭제할 수 있도록 한다. 13.5.1.5, “REVOKE ”장을 참조하라.
MySQL 계정 정보는 mysql 데이터베이스 테이블에 저장되어 있다. 이 데이터베이스와 엑세스 컨트롤 시스템은 “5. 데이터베이
스 관리” 장에 자세히 언급되어 있다
중요: MySQL의 몇몇 릴리즈에는 새로운 권한과 기능을 추가한 grant 테이블의 구성에 변경이 있다고 소개한다. MySQL 새로운
버전으로 업데이트할 때면 언제나grant 테이블도 업데이트해야 한다. 그럼으로써 새로운 기능을 이용할 수 있는지 현재 구성을 확
인할 수 있다. 5.6.2, “mysql_upgrade — Check Tables for MySQL Upgrade”장을 참조하라.
Grant 테이블이 mixed-case 데이터베이스 또는 테이블 이름들을 포함하고 있는 권한 로우를 가지고 있거나,
lower_case_table_names 시스템 변수를 non-zero 값으로 셋팅한다면, REVOKE 는 이 권한들을 취소할 수 없다. grant 테이블
을 직접 조정할 필요가 있다. (GRANT는 lower_case_table_names 가 셋팅되었을 때, 그런 로우를 생성하지 않는다.그러나 그런
로우는 변수를 셋팅하기에 앞서 생성되기도 한다
권한들은 다음과 같이 레벨로 나누어져 있다.:
● Global level
Global 권한은 주어진 하나의 서버에 모든 데이터베이스를 적용한다. 이 권한은 mysql.user 테이블에 저장되어 있다.
GRANT ALL ON *.* 과 REVOKE ALL ON *.* 은 오직 글로벌 권한들만을 부여하고 취소한다.
● Database level
데이터베이스 권한은 주어진 하나의 데이터베이스에서 모든 오브젝트에 적용한다. 이 권한은 mysql.db 와 mysql.host 테
이블에 저장되어 있다. GRANT ALL ON db_name.* 와REVOKE ALL ON db_name.* 은 오직 데이터베이스 권한들만
부여하고 취소한다.
● Table level
테이블 권한은 주어진 하나의 테이블에서 모든 컬럼에 적용한다. 이 권한은 mysql.tables_priv 테이블에 저장되어 있다.

:::MySQL Korea:::
GRANT ALL ON db_name.tbl_name 과 REVOKE ALL ON db_name.tbl_name 은 오직 테이블 권한들만 부여하고 취

소한다.
● Column level
컬럼 권한은 주어진 하나의 테이블에서 싱글 컬럼에 적용한다. 이 권한은 mysql.columns_priv 테이블에 저장되어 있다.
REVOKE를 사용할 때, 부여받은 것과 같은 컬럼을 지정해야만 한다.
● Routine level
CREATE ROUTINE, ALTER ROUTINE, EXECUTE, GRANT 권한은 스토어드 루틴에 적용한다. (기능과 프로시져).
이 권한들은 글로벌과 데이터베이스 레벨에서 부여된다. 물론 CREATE ROUTINE 을 제외하고, 이 권한들은 각가의 루
틴을 위한 루틴 레벨에서 부여될 수 있으며, mysql.procs_priv 테이블에 저장되어 있다.
object_type 절은 MySQL 5.0.6에서 추가되었다. 다음 오브젝트가 하나의 테이블, 하나의 저장된 기능, 또는 하나의 스토어드 프
로시져라면, TABLE, FUNCTION, 또는 PROCEDURE 로 지정되어야 한다.
GRANT 와 REVOKE 문의 경우, priv_type 다음과 같이 지정될 수 있다:
권한 의미
ALL [PRIVILEGES] GRANT OPTION 을 제외하고 모든 간단한 권한을 셋팅
ALTER ALTER TABLE 사용을 허용
ALTER ROUTINE 변경되거나 드롭된 스토어드 루틴들을 허용
CREATE CREATE TABLE 사용을 허용
CREATE ROUTINE 스토어드 루틴 생성 허용
CREATE
TEMPORARY CREATE TEMPORARY TABLE 사용 허용
TABLES

:::MySQL Korea:::
CREATE USER, DROP USER, RENAME USER, REVOKE ALL PRIVILEGES 사

CREATE USER
용을 허용
CREATE VIEW CREATE VIEW 사용 허용
DELETE DELETE 사용 허용
DROP DROP TABLE 사용 허용
EXECUTE 사용자의 스토어드 루틴 실행 허용
FILE SELECT ... INTO OUTFILE and LOAD DATA INFILE 사용 허용
INDEX CREATE INDEX 와 DROP INDEX 사용 허용
INSERT INSERT 사용 허용
LOCK TABLES SELECT 권한을 가진 테이블에서 LOCK TABLES 사용 허용
PROCESS SHOW FULL PROCESSLIST 사용 허용
REFERENCES 제공되지 않음.
RELOAD FLUSH 사용 허용
REPLICATION
사용자가 슬레이브 또는 마스터 서버가 있는 곳을 질문할 수 있음
CLIENT
REPLICATION SLAVE 리플리케이션 슬레이브에 필요한(마스터로부터 바이너라 로그 이벤트를 읽기 위해)
SELECT SELECT 사용 허용
SHOW DATABASES SHOW DATABASES 는 모든 데이트베이스를 보여줌
SHOW VIEW SHOW CREATE VIEW 사용 허용
SHUTDOWN mysqladmin shutdown 사용 허용
CHANGE MASTER, KILL, PURGE MASTER LOGS, 그리고 SET GLOBAL 문,

SUPER mysqladmin debug 명령 사용 허용; max_connections 가 이루어지더라도, (한번만)
접속할 수 있다.
UPDATE UPDATE 사용 허용
USAGE “권한 없음”과 동의어

:::MySQL Korea:::
GRANT OPTION 권한을 부여할 수 있음
EXECUTE 권한은 MySQ5.0.3까지 실행할 수 없었다. CREATE VIEW 와 SHOW VIEW 는 MySQL 5.0.1에 추가되었다.
CREATE USER, CREATE ROUTINE, 와 ALTER ROUTINE MySQL 5.0.3에 추가되었다.
REFERENCES 권한은 현재 사용하지 않는다.
USAGE 는 권한이 없는 사용자를 생성하고자 할 때 지정될 수 있다.
어떤 권한을 계정에 부여할지 결정할 때 SHOW GRANTS 를 사용하라 13.5.4.12, “SHOW GRANTS Syntax”장을 참조하라.
ON *.* 신텍스를 이용해 글로벌 권한을 또는 ON db_name.* 신텍스를 이용해 데이터베이스-레벨 권한을 지정할 수 있다. 만약
ON *지정하고, 디폴트 데이터베이스를 선택한다면, 권한은 데이터베이스-레벨이 부여된다.
(주의: 만약 ON *을 지정하고 디폴트 데이터베이스를 선택하지 않았다면, 지정된 권한은 글로벌이다)

FILE, PROCESS, RELOAD, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES, SHUTDOWN, 그리
고 SUPER 권한은 전체적으로 부여되는 관리권한이다. (ON *.* 신텍스를 사용하는).
다른 권한들은 전체적으로 또는 더 분명한 레벨에서 부여될 수 있다.
테이블에 지정할 수 있는 priv_type 값은 SELECT, INSERT, UPDATE, DELETE, CREATE, DROP, GRANT OPTION,
INDEX, ALTER, CREATE VIEW 그리고 SHOW VIEW이다.
컬럼에 지정할 수 있는 priv_type 값은(즉, column_list 절을 사용할 때) SELECT, INSERT, 그리고 UPDATE이다.
루틴 레벨에 지정할 수 있는 priv_type 값은 ALTER ROUTINE, EXECUTE, 그리고 GRANT OPTION이다. CREATE
ROUTINE 은 루틴을 생성하기 위해서는 우선 이 권한을 가지고 있어야 하기 때문에 루틴-레벨 권한이 아니다.
글로벌, 데이터베이스, 테이블, 루틴 레벨에 있어, GRANT ALL 은 사용자가 지정하는 레벨에 존재하는 권한만을 지정한다. 예를
들어, GRANT ALL ON db_name.* 은 데이터베이스-레벨 문이다. 그러므로 그것은 FILE 과 같이 글로벌-권한은 부여되지 않는
다.

:::MySQL Korea:::
MySQL에서 사용자는 존재하지 않는 데이터베이스 오브젝트에 까지도 권한을 부여할 수 있다. 이런 경우, 주어진 권한들은
CREATE 권한을 포함하고 있어야 한다. 이런 것은 계획적이며, 데이터베이스 관리자가 나중에 생성될 데이터베이스 오브젝트를
위한 사용자 계정과 권한을 준비할 수 있도록 한다.
중요: MySQL 은 테이블이나 데이터베이스가 드롭된다고, 권한이 자동적으로 취소되지 않는다. 그러나, 루틴이 드롭되면, 루틴-레
벨에 주어진 권한은 취소된다.
주의: ‘_’ 과 ‘%’ 와일드카드는 글로벌 또는 데이터베이스 레벨에 권한을 부여한 GRANT문에서 데이터베이스 이름을 지정
할 때, 허용된다. 즉, 예를 들어, ‘_’ 문자를 데이터베이스 이름의 부분으로 사용하고자 한다면, 예를 들어 GRANT ... ON `foo
￦_bar`.* TO ... 와 같이 와일드카드 패턴으로 매칭되는 추가적인 데이터베이스에 사용자가 접근하는 것을 막기 위해서 GRANT
문에서 ‘￦_’로 지정해야 한다.
임의의 호스트들로부터 사용자들에게 granting권한을 부여하기 위해서, MySQL은 user_name@host_name으로부터 user값에

대한 명시를 지원한다. 만약 user_name 혹은 host_name값이 인용 부호로서 적합하다면 여러분은 인용할 필요가 없다. 그러나 인
용 부호는 특정 문자들(예를 들면 ‘_’)을 포함하고 있는 user_name 문자열 혹은 특별한 문자열을 포함하고 있는 host_name 혹
은 wildcard문자열(예를 들면’%’)을 명시하기 위해 필요하다: 예를 들면 ‘test-user’@’test-hostname’. 사용자이름과
호스트이름은 각각 따로 인용 부호를 사용하라.
호스트이름에서 wildcard를 명시 할 수 있다. 예를 들면, user_name@'%.loc.gov' 도메인에 한 호스트에 대한 user_name으로 적

용되며, user_name@'144.155.166.%' 은 144.155.166 클래스의 C 서브넷안의 임의의 호스트에 대한 user_name으로 적용된
다.
User_name의 단순한 형태는 user_name@’%’와 동의어 이다.
MySQL은 사용자 이름들에서 wildcard를 지원하지 않는다. Anonymous사용자들은 mysql.user테이블 안에 User=’’로 입력

하거나 GRANT 문장과 함께 빈 이름으로 사용자를 생성함으로써 정의 될 수 있다:
GRANT ALL ON test.* TO ''@'localhost' ...
인용된 값을 명시할 경우 backtick(‘`’)을 사용하여 지시어로서 데이터베이스,테이블,컬럼 그리고 루틴 이름을 인용하라. 단일

인용 부호(‘’’)를 사용하려 문자열로서 호스트 이름, 사용자 이름 그리고 비밀 번호를 인용 한다.

:::MySQL Korea:::
경고: 여러분이 익명의 사용자들이 MySQL서버로의 연결을 허가 한다면, 여러분은 user_name@localhost로서 모든 local 사용자
들에게 권한을 부여해야 한다. 그렇지 않으면 명명된 사용자들이 local 시스템으로부터 MySQL서버에 로그인 하려 할 때에 mysql.
user테이블(MySQL 설치 시 생성된)내의 localhost에 대한 익명의 사용자 계정이 사용된다. 보다 상세한 사항은 5.8.5장
“Access Control, Stage 1 : Connection Verification”부분을 참조 하라.
다음과 같은 쿼리를 실행함으로써 이것을 적용할 것인지를 결정할 수 있으며, 이는 익명의 사용자들을 기재한다:
SELECT Host, User FROM mysql.user WHERE User='';
만일 여러분이 방금 설명된 문제를 피하기 위해 local 익명 사용자 계정을 삭제 하길 원한다면 다음과 같은 문장을 사용하라:
DELETE FROM mysql.user WHERE Host='localhost' AND User='';

FLUSH PRIVILEGES;
GRANT 는 최대 60자의 호스트 이름을 지원한다. 데이터베이스,테이블,컬럼 그리고 루틴 이름들은 64자 문자열까지 가능하다. 사
용자 이름들은 16자까지 가능하다.
주의: 사용자이름에 대한 허용가능한 길이는 mysql.user 테이블의 내용을 조절하여 변경될 수 없으며 이러한 시도는 그 사용자들
이 해당 MySQL서버에 로그인 하지 못하는 예상치 못한 결과를 초래 할 수 있다. 여러분은 5.6.2장 “mysql_upgrade – Check
Tables for MySQL Upgrade”에서 설명된 MySQL AB에 의해 규정된 procedure의 방법을 제외하고 어떤 방법으로든 mysql
데이터베이스 내의 테이블의 내용을 변경 할 수 없다.
테이블, 컬럼, 혹은 루틴에 대한 권한들은 권한 레벨들의 각 권한의 논리 OR로서 만들어진다. 예를 들면 mysql.user테이블이 한사

용자가 global SELECT권한을 가졌다면 그 권한은 데이터베이스, 테이블, 혹은 컬럼 레벨의 한 엔트리(entry)에 의해 거부 될 수
없다.
한 컬럼에 대한 권한들은 다음과 같이 계산 될 수 있다:
global privileges
OR (database privileges AND host privileges)

:::MySQL Korea:::
OR table privileges
OR column privileges
OR routine privileges
대부분의 경우, 여러분은 권한 레벨의 하나에서만 사용자에게 권한을 부여 한다. 권한 check 프로시져에 대한 자세한 사항은 5.8
장 “MySQL Access Privilege System’부분을 참조하라.
mysql.user 테이블에 존재하지 않는 username/hostname 조합에 대해 권한을 부여하면, 한 entry가 추가 되며 DELETE 문에 의

해 삭제 될때까지 남아 있다. 즉, GRANT는 user 테이블 엔트리를 생성하나, REVOKE는 그것들을 삭제 하지 않는다; 여러분은
DROP USER 나 DELETE를 통해서 명시적으로 이를 할수 있다.
경고: 여러분이 새로운 사용자를 생성하고 IDENTIFIED BY 절을 명시 하지 않으면, 그 사용자는 패스워드를 갖지 않는다. 이것은
매우 위험하다. MySQL 5.0.2에서부터는, 여러분은 IDENTIFIED BY가 새로운 사용자에게 패스워드를 제공하기 위해 주어지지
않는한, 새로운 사용자를 생성할 때 GRANT를 방지 하기 위해 NO_AUTO_CREATE_USER SQL 모드를 활성화 할 수 있다.
새로운 사용자가 생성되거나 여러분이 global grant 권한을 가진 경우, 사용자의 패스워드는 IDENTIFIED BY절에 의해 명시 된
패스워드가 된다. 사용자가 이미 패스워드를 가진 경우 이것은 새로운 것으로 교체된다.
패스워드들은 SET PASSWORD 문에 의해 설정될 수 있다. 13.5.1.6장 “SET PASSWORD”를 참조하라.

IDENTIFIED BY 절에서, 패스워드는 문자 패스워드 값으로 주어져야 한다. SET PASSWORD문을 위해서 PASSWORD() 함수
를 사용할 필요는 없다.
예를 들면:
GRANT ... IDENTIFIED BY 'mypass';
여러분이 순수 text로 패스워드를 보내고 싶지 않고 PASSWORD()함수가 그 패스워드에 대해 리턴하는 해쉬 값을 알고있는 경
우, 여러분은 키워드 PASSWORD와 해쉬 값을 명시 할 수 있다:
GRANT ...
IDENTIFIED BY PASSWORD '*6C8989366EAF75BB670AD8EA7A7FC1176A95CEF4';

:::MySQL Korea:::
C프로그램에서 여러분은 make_scrambled_password() C API함수를 사용하여 해쉬 값을 얻을 수 있다.
여러분이 데이터베이스에 대한 권한을 부여할 때, mysql.db테이블안의 엔트리가 필요에 따라 생성된다.
데이터베이스에 대한 모든 권한은 REVOKE로 제거 되고 이 entry는 삭제 된다.
SHOW DATABASES 권한은 사용자 계정이 SHOW DATABASE문을 실행하여 데이터베이스 이름을 볼 수 있도록 한다. 이 권한
을 갖지 않는 계정들은 그들이 권한을 가진 몇몇 데이터베이스만을 볼 수 있고 서버가 –skip_show-database옵션으로 시작 했다
면 그 문장을 사용할 수 없다.
한 사용자가 한 테이블에 대해 권한을 갖지 않는 경우 이 테이블 이름은 사용자가 테이블 리스트를 요구할 경우에 display되지 않
는다(예를 들면, SHOW TABLES 문).
WITH GRANT OPTION절은 사용자에게 명시된 권한 레벨에 따라 그가 가진 권한들 중 어느 것이든 줄 수 있는 권한을 준다. 여
러분은 다른 권한을 가진 두 사용자가 join 권한을 활성화 할 수 있기 때문에, GRANT OPTION권한을 줄 대상에 대해 주의 해야
한다.
여러분은 여러분이 갖지 않은 권한을 다른 사용자에게 부여 할 수 없다. GRANT OPTION권한은 자신이 소유한 권한들만을 할당
할 수 있게 한다.
여러분이 틀별한 권한 레벨로 GRANT OPTION권한을 한 사용자에게 부여할 때, 그 레벨에서 사용자가 소유(혺은 미래에 제공될)
한 어떤 권한들도 다른 사용자에게 부여 될 수 있다. 여러분이 한 데이터베이스에 INSERT권한을 부여할 경우를 가정해 보라. 여러
분이 데이터베이스에서 SELECT 권한을 부여하고 WITH GRANT OPION을 명시 하면, 그 사용자는 SELECT 권한을 부여할 뿐
만 아니라 INSERT권한도 부여할 수 있다.
여러분이 그 데이터베이스에 대해 UPDATE 권한을 부여하면 그 사용자는 INSERT, SELECt, 그리고 UPDATE에 대한 권한도
부여할 수 있다.
관리자가 아닌 사용자에 대해, 여러분은 global혹은 mysql 데이터베이스에 대해 ALTER권한을 부여할 수 없다. 만약 이것을 할 경
우, 그 사용자는 테이블들을 재 명명하여 권한 시스템을 파괴 하려 할 수 있다.

:::MySQL Korea:::
MAX_QUERIES_PER_HOUR count, MAX_UPDATES_PER_HOUR count, 그리고 MAX_CONNECTIONS_PER_HOUR

count 옵션들은 한 사용자가 주어진 한 시간 동안 수행할 수 있는 쿼리, update, 그리고 로그인의 수를 제한 한다. Count가 0(기본
값)이면 이것은 사용자에게 제한이 없는 것을 의미한다.
MySQL 5.0.3에서 구현된, MAX_USER_CONNECTIONS count옵션은 그 계정이 만들수 있는 동시 연결의 최대 수를 제한한

다. Count가 0(기 값)이면, max_user_connections 시스템 변수가 그 계정에 대한 동시 접속의 수를 결정한다.
주의: 존재하는 권한들을 영항을 미치지 않고 기존 사용자에게 자원 제한 옵션을 명시하기 위해서는 GRANT USAGE ON *.* …
WITH MAX_...를 사용하라.
5.9.4장 “Limiting Account Resource”를 참조 하라.
MySQL은 username과 password에 기반한 일반적인 인증에 더해서 X509 자격 속성을 체크 할수 있다.
MySQL 계정을 위해 SSL관련 옵션들을 명시하기 위해서는 GRANT문의 REQUIRE절을 사용하라(MySQL과 SSL의 사용에 관
한 배경 정보는 5.9.7장 “Using Secure Connections”을 참조하라.)
주어진 계정에 대해 연결 타입을 제한하기 위한 많은 다른 가능성들이 존재 한다:
● 계정이 SSL 이나 X509 자격을 갖지 않으면 username과 password가 유효 할 경우 비암호화된 연결이 허락된다. 그러나
client의 옵션에서, 클라이언트가 적절한 인증과 키파일을 갖는 경우, 암호화된 연결들이 사용될 수 있다.
● REQUIRE SSL 옵션은 그 계정에 대해서 오직 SSL-암호화 연결만을 허용하도록 말한다. 이 옵션은 비-SSL 연결들을 허
용하는 접근 제어 레코드들이 존재하면 생략될 수 있다.
GRANT ALL PRIVILEGES ON test.* TO 'root'@'localhost'

IDENTIFIED BY 'goodsecret' REQUIRE SSL;
● REQUIRE X509 는 client는 유효한 인증을 가져야 하여 정확한 인증, isuser, 그리고 subject는 문제가 되지 않음을 의미
한다. 단지 필요한 요건은 CA 인증 중 하나로 그 서명(signature)를 확인할 수 있어야 한다.

:::MySQL Korea:::
IDENTIFIED BY 'goodsecret' REQUIRE X509;
● REQUIRE ISSUER 'issuer' 클라이언트가 CA 'issuer'로 발생한 유효한 X509 인증을 제출 해야하는 연결 시도에 대해 제
한을 가한다. 만약 그 사용자가 유효하지만 다른 issuer를 가진 인증을 제시 할경우 서버는 이 연결을 거부한다. X509 인증
의 사용은 항상 암호화를 내포하며 SSL 옵션은 이 경우 불 필요하다.

IDENTIFIED BY 'goodsecret'
REQUIRE ISSUER '/C=FI/ST=Some-State/L=Helsinki/
O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com';
'issuer' 값은 단일 문자열로 입력되어야 한다.
● REQUIRE SUBJECT 'subject' 는 subject 를 포함하는 유효한 X509 인증을 제시해야 하는 연결 시도에대해 제약을 가한
다. 클라이언트가 유효하지만 다른 subject를 가진 인증을 제시하면 서버는 그 연결을 거부 한다.

REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/
O=MySQL demo client certificate/
CN=Tonu Samuel/Email=tonu@example.com';
'subject' 값은 단일 문자열로 입력되어야 한다.
● REQUIRE CIPHER 'cipher' 는 충분한 강도의 암호문들과 키가 사용되도록 할 필요가 있다. SSL은 짧은 암호화 키들을
이용하는 오래된 알고리즘이 사용될 경우 약해질 수 있다. 이 옵션을 사용하면 여러분은 특정 암호화 방법이 연결을 허락하
기 위해 사용될 수 있는지 물어봐야 한다.

REQUIRE CIPHER 'EDH-RSA-DES-CBC3-SHA';
SUBJECT, ISSUER, 그리고CIPHER 옵션은 다음과 같이 REQUIRE 절 안에서 혼합될 수 있다.:

:::MySQL Korea:::

REQUIRE SUBJECT '/C=EE/ST=Some-State/L=Tallinn/
O=MySQL demo client certificate/
CN=Tonu Samuel/Email=tonu@example.com'
AND ISSUER '/C=FI/ST=Some-State/L=Helsinki/
O=MySQL Finland AB/CN=Tonu Samuel/Email=tonu@example.com'
AND CIPHER 'EDH-RSA-DES-CBC3-SHA';
AND 키워드는 REQUIRE 옵션들 사이에 선택적이다.
옵션들의 순서는 문제가 되지 않으나 옵션은 두번 명시될 수 없다.
mysqld 이 시작할 때, 모든 권한들은 메모리로 읽어 온다. 이에 대한 자세한 사항은 5.8.7장 “Wen Privilege Changes Take
Effect”를 참조하라.
여러분이 심지어 한 사용자에 대해서 table, column 혹은 routine 권한을 사용할 경우, 서버는 모든 사용자에 대한 table, column
그리고 routine 권한을 검사하며 이는 MySQL을 다소 느리게 한다. 유사하게, 임의의 사용자들에 대해 query, update, 혹은 연결
의 수를 제한한다면 그 서버는 이들 값들을 모니터 해야 한다.
GRANT에 대한 표준 SQL과 MySQL간의 가장 큰 차이들은 다음과 같다:
● MySQL에서 권한들은 hostname과 username과 관련이 있고 단지 username과만 관련 있지는 않다.

● 표준 SQL은 global혹은 데이터베이스 레벨의 권한들이 없으며 MySQL이 제공하는 모든 권한 타입들도 제공하지 않는다.
● MySQL 은 표준 SQL TRIGGER 혹은 UNDER 권한들을 제공하지 않는다.
● 표준 SQL 권한들은 계층적인 방법으로 구조화 되어 있다. 여러분이 한 사용자를 삭제하면 사용자에게 부여된 모든 권한들
이 철회 된다. 이것은 MySQL 5.0.2에서도 적용 되며 여러분이 DROP USER 를 사용 할 경우에도 해당된다. 5.0.2이전에
는 부여된 권한들이 자동으로 철회 되지 않았다; 여러분이 직접 철회 해야 한다. 이에 대한 내용은 13.5.1.2장 “DROP
USER”를 참조하라.
● 표준 SQL에서 여러분이 한 테이블을 drop하는 경우, 그 테이블에 대한 모든 권한들이 철회 된다. 표준 SQL에서는 여러분

:::MySQL Korea:::
이 한 권한을 삭제 할 때 그 권한에 기반하여 부여되었던 모든 권한들이 철회 된다. MySQL에서는 명시적인 REVOKE 문

장들이나 MySQL grant 테이블들에 저장된 관리 값들을 이용하여 삭제 될 수 있다.
● MySQL에서 한 테이블의 몇 개의 컬럼에 대해서만 INSERT 권한을 가질 수 있다. 이 경우, 여러분은 INSERT권한을 갖
지 않은 컬럼들을 생략한다는 전제 하에, 그 테이블에 ISNERT 문들을 실행 할 수 있다. 생략된 컬럼들은 엄격한 SQL모드
가 활성화 되지 않으면 암시적인 기본 값들로 설정된다. strict mode에서는 생략된 컬럼들중 기본값을 갖지 않는 컬럼이 있
다면, 그 SQL 문은 거부 된다. (표준 SQL은 모든 컬럼에 대해 INSERT 권한을 갖도록 요구한다.) 5.2.5장 “The Server
SQL Mode”은 strict mode에 대해 설명한다. 11.1.4 장 “Data Type Default Values” 는 암시적인 기본값들에 대해
논의 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.1.4. RENAME USER
13.5. 데이터베이스 관리문 RENAME USER old_user TO new_user
13.5.1 계정 관리문
[, old_user TO new_user] ...
RENAME USER 문은 MySQL 5.0.2 버전에서 추가되었다. 이것을 사용하려면, 글로벌 CREATE USER 권한 또는 mysql 데이터
13.5.1.3 GRANT
베이스용 UPDATE 권한이 있어야 한다. 임의의 오래된 계정이 존재하지 않거나 임의의 새로운 계정이 존재하면 에러가 발생한다.
각각의 계정은 GRANT 문과 같은 포맷을 사용하여 명명된다. 예를들어 'jeffrey'@'localhost'. 사용자나 계정이름의 호스트 부분
13.5.1.5 REVOKE 은 계정에 있어 user 로우의 User 와 Host 컬럼 값에 따라 결정된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.1.5. REVOKE
13.5. 데이터베이스 관리문 REVOKE priv_type [(column_list)] [, priv_type [(column_list)]] ...
13.5.1 계정 관리문
ON [object_type] {tbl_name | * | *.* | db_name.*}
FROM user [, user] ...
13.5.1.3 GRANT
13.5.1.5 REVOKE
13.5.1.6 SET PASSWORD REVOKE ALL PRIVILEGES, GRANT OPTION FROM user [, user] ...
REVOKE 문은 시스템 관리자가 MySQL 계정으로부터 권한을 취소할 수 있게 해준다. REVOKE 문을 사용하려면, GRANT
OPTION 권한을 가지고 있어야 하며, 취소권한이 있어야 한다.
권한을 가진 레벨, 허용된 priv_type 값, 지정한 사용자와 비밀번호에 관한 신텍스에 관한 자세한 사항은 13.5.1.3, “GRANT
Syntax” 장을 참조하라
grant 테이블이 mixed-case 데이터베이스 또는 테이블 이름이 포함된 권한 로우에 있고, lower_case_table_names 시스템 변수
가 제로(zero)가 아닌 값으로 셋팅되어 있다면, REVOKE는 이 권한들을 취소할 수 없다. 그것은 grant 테이블을 직접 조작하는데
필요하게 될 것이다. (GRANT 는 lower_case_table_names 이 셋팅되었을 때, 그런 로우를 생성하지 못한다. 그러나 그런 로우
는 변수 셋팅에 앞서 생성될 수 있다.

:::MySQL Korea:::
모든 권한을 취소하려면, 다음의 신텍스를 사용하라. 이 신텍스는 명명된 사용자 또는 사용자들의 모든 글로벌, 데이터베이스-, 테
이블-, 컬럼-레벨 권한을 드롭시킨다:
REVOKE ALL PRIVILEGES, GRANT OPTION FROM user [, user] ...
이 REVOKE 신텍스를 사용하려면, 글로벌 CREATE USER 권한 또는 mysql 데이터베이스 용 UPDATE 권한이 있어야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.1.6. SET PASSWORD
13.5. 데이터베이스 관리문 SET PASSWORD [FOR user] = PASSWORD('some password')
13.5.1 계정 관리문
SET PASSWORD 문은 현재 MySQL에 있는 사용자 계정에 비밀번호를 지정한다.
FOR 가 없는 절에서, 이 문은 현재 사용자의 비밀번호를 셋팅한다 익명이 아닌 계정을 사용하는 서버에 접속된 클라이언트는 그 계
13.5.1.3 GRANT
정의 비밀번호를 변경할 수 있다.
13.5.1.5 REVOKE FOR 절에서, 이 문은 현재 서버 호스트에서 특정한 계정의 비밀번호를 셋팅한다. mysql 데이터베이스용UPDATE 권한을 가진 클
13.5.1.6 SET PASSWORD 라이언트만 이것을 할 수 있다. user 값은 user_name@host_name 포맷에 주어진다. 이 포맷은 user_name 과 host_name 이
mysql.user 테이블 입력의 User와 Host 컬럼에 기록된 것과 똑같다. 예를 들어, 'bob' 와 '%.loc.gov' 의 User와 Host 컬럼 값을
입력했다면, 다음과 같이 명령문을 쓴다:
SET PASSWORD FOR 'bob'@'%.loc.gov' = PASSWORD('newpass');
이것은 다음 명령문에 상응한다:
UPDATE mysql.user SET Password=PASSWORD('newpass')
WHERE User='bob' AND Host='%.loc.gov';
FLUSH PRIVILEGES;
주의: MySQL 4.1 또는 4.1 클라이언트 프로그램을 사용하는 서버에 연결되어 있다면, 먼저 5.8.9, “MySQL 4.1에서의 비밀번
호 해쉬(hash)” 장을 읽어보고 SET PASSWORD 또는 UPDATE 문을 사용하라. 비밀번호 포맷이 MySQL 4.1 버전에서 변경되

:::MySQL Korea:::
었다. 그리고 비밀번호를 변경한다면, 그 이후로 서버에 접속이 불가능할지 지도 모른다.
SELECT CURRENT_USER() 를 실행하여 어떤 계정이 서버에서 인증되는지 볼 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.2. 테이블 유지보수 문
13. SQL 문법(SQL Statement Syntax) 13.5.2.1. ANALYZE TABLE

13.5. 데이터베이스 관리문 13.5.2.2. BACKUP TABLE
13.5.2 테이블 유지보수 문 13.5.2.3. CHECK TABLE
13.5.2.1 ANALYZE TABLE 13.5.2.4. CHECKSUM

TABLE
13.5.2.5. OPTIMIZE TABLE
13.5.2.6. REPAIR TABLE
13.5.2.7. RESTORE TABLE
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.2.1. ANALYZE TABLE
13.5. 데이터베이스 관리문 ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

ANALYZE TABLE은 테이블의 중요 분포(Key distribution)를 분석하고 저장한다. 분석하는 동안, 테이블은 리드록(read rock)
으로 잠긴다. 이 문은 MyISAM, BDB, InnoDB 테이블에서 쓰인다. MyISAM 테이블에서 이 문은 myisamchk --analyze 에 상
응한다.
MySQL 은 상수(불변수)보다 다른 어떤 것에 조인(join)을 실행할 때, 어떤 테이블에서 조인해야 할지 순서를 결정하기 위해서 스
13.5.2.5 OPTIMIZE TABLE 토어드 키 디스트리뷰션을 사용한다.
13.5.2.7 RESTORE TABLE 이 문은 테이블에서 SELECT와 INSERT 권한을 요구한다.
ANALYZE TABLE 은 다음 컬럼과 같은 결과 셋트로 리턴한다:
Column Value
Table 테이블 이름
Op 항상 analyze
Msg_type status, error, info, 또는 warning 중 하나
Msg_text 메시지

:::MySQL Korea:::
SHOW INDEX 문으로 스토어드 키 디스트리뷰션을 체크할 수 있다. 13.5.4.13, “SHOW INDEX” 장을 참조하라
마지막 ANAYZE TABLE 문 이래로 테이블이 변경되지 않는다면, 테이블은 다시 분석되지 않는다.
임의의 NO_WRITE_TO_BINLOG 키워드(또는 그것의 알리아스 LOCAL)를 사용하지 않는다면, ANALYZE TABLE 문은 바이
너리 로그로 쓰여진다. 리플리케이션 마스터로 작용하는 MySQL 서버에서 사용중인 ANALYZE TABLE 문은 리플리케이션 슬레
이브로 디폴트로 리플리케이션 될 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.2.2. BACKUP TABLE
13.5. 데이터베이스 관리문 BACKUP TABLE tbl_name [, tbl_name] ... TO '/path/to/backup/directory'

주의: 이 문은 반대된다. 우리는 더 나은 리플레이스먼트에서 작업 중이라 온라인 백업 기능을 제공할 것이다. 그러는 동안에
mysqlhotcopy 스크립트가 대신 사용될 수 있다.
13.5.2.5 OPTIMIZE TABLE BACKUP TABLE 은 버퍼된 변경을 디스크에 기록한 후에, 테이블을 복구하는데 필요한 최소의 테이블 파일을 백업 디렉토리에
13.5.2.6 REPAIR TABLE 복사한다. 문은 오로지 MyISAM 테이블에만 해당된다. 이것은 .frm 정의와 .MYD 데이터파일을 복사한다. .MYI 인덱스 파일은
13.5.2.7 RESTORE TABLE 그 두 파일로부터 개조될 수 있다. 디렉토리는 완전한 경로이름으로 열거된다. 테이블을 복구하기 위해서, RESTORE TABLE 을
사용한다.
백업하는 동안, 리드록(read rock)은 백업될 순서대로 각각의 테이블에 보관된다. 만약 몇몇 테이블을 스냅샷으로 백업하고 싶다
면(백업을 실행하는 동안 변경되는 것으로부터 이것을 보호하기 위해), 그룹 내 모든 테이블에 리드록(read lock)을 포함시키기
위해 LOCK TABLES 문을 먼저 실행한다.
BACKUP TABLE 은 다음 컬럼과 같은 결과 셋트로 리턴한다:

:::MySQL Korea:::
Column Value
Op 항상 backup
Msg_text 메시지

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.2.3. CHECK TABLE
13. SQL 문법(SQL Statement Syntax) CHECK TABLE tbl_name [, tbl_name] ... [option] ...
13.5. 데이터베이스 관리문

option = {FOR UPGRADE | QUICK | FAST | MEDIUM | EXTENDED | CHANGED}
CHECK TABLE 은 테이블이나 테이블 에러를 체크한다. CHECK TABLE 은MyISAM, InnoDB, 그리고(MySQL 5.0.16 버전부
13.5.2.4 CHECKSUM TABLE 터) ARCHIVE 테이블들에 해당된다. MyISAM 테이블에서, 키 통계치까지 업데이트된다.
13.5.2.6 REPAIR TABLE MySQL 5.0.2에서, CHECK TABLE은 더 이상 존재하지 않는 뷰 정의에 언급된 테이블과 같은 문제의 뷰를 체크할 수 있다.
CHECK TABLE 은 다음 컬럼과 같은 결과 셋트로 리턴한다:
Column Value
Op 항상 backup
Msg_text 메시지

:::MySQL Korea:::
문은 각각 체크된 테이블에 관한 정보가 있는 많은 로우를 생성할 수 있다는 것을 유념하라. 마지막 로우는 staus의 Msg_type 값
을 가지고 있고, Msg_text 은 일반적으로 OK이다. 만약 OK또는 Table is already up to date 가 나오지 않는다면, 일반적으로 테
이블 복구를 실행해야한다. 5.10.4, “테이블 관리와 크래쉬복구”장을 참조하라. Table is already up to date 는 테이블의 스토
리지 엔진이 테이블을 체크할 필요가 없다고 표시한다는 것을 의미한다.
FOR UPGRADE 옵션은 명명된 테이블이 현재 MySQL 버전과 호환성이 있는지 체크한다. 이 옵션은 MySQL 5.0.19버전에 추가
되었다. 테이블이 생성된 이래로 테이블의 데이터 타입이나 인덱스에 있어 어떤 호환성없는 변경이 있는지 측정하기 위해서, 서버
는 FOR UPGRADE로 각 테이블을 체크한다. 변경이 없다면 체크는 성공이다. 그렇지 않고 호환성이 없다면, 서버는 테이블을 모
두 체크한다(시간이 좀 걸린다). 풀 체크가 성공하면, 서버는 테이블의 .frm 파일을 현재 MySQL 버전 숫자로 표시한다. .frm 파일
로 표시함으로써, 서버와 같은 버전으로 테이블을 체크하는 것이 더 빨라질 것이다.
데이터타입에 따라 스토리지 포맷이 변경되거나, 정렬순서가 변경되기 때문에 호환되지 않는 경우가 발생한다. 우리의 의도는 이
런 변경을 예방하는 것이다. 그러나 때때로 릴리즈된 버전 간에 호환이 안되는 문제를 교정하는 것이 필요하다.
일반적으로, FOR UPGRADE 는 다음과 같이 호환이 안되는 경우를 나타낸다:
● InnoDB와 MyISAM테이블의 TEXT 컬럼에 있어 end-space 인덱싱 순서는 MySQL 4.1과 5.0 사이에서 변경되었다.
● 새로운 DECIMAL 데이터 타입의 저장방법은 MySQL 5.0.3과 5.0.5 사이에 변경되었다.
다른 체크 옵션은 다음 표에서 보여준다. 이 옵션들은 오직 MyISAM 테이블을 체크하는 데에만 적용되며, InnoDB 테이블과 뷰에
서는 무시된다.

:::MySQL Korea:::
Type Meaning
QUICK 잘못된 링크를 체크하기 위해 로우를 스캔하지 말라.
FAST 올바르게 닫혀있지 않은 테이블만 체크하라.
CHANGED 마지막 체크한 이후 변경되거나 올바르게 닫혀있지 않은 테이블만 체크한다.
삭제된 링크가 유효한지 검증하기 위해 로우를 스캔한다. 이것은 로우의 키 검사합계를 계산하고, 키들의 계산된
MEDIUM
검사합계를 가지고 이것을 검증한다.
EXTENDED 각 로우의 모든 키들을 검색한다. 이것은 테이블이 100% 일치한다는 것을 보여주지만 시간이 오래 걸린다.
QUICK, MEDIUM, 또는 EXTENDED 옵션이 열거되어 있지 않다면, 동적인 포맷 MyISAM 테이블에 디폴트 체크 타입은
MEDIUM이다. 이것은 테이블에 있어 myisamchk --medium-check tbl_name 실행과 같은 결과이다. CHANGED 또는 FAST
가 열거되어 있지 않다면, 정적인 포맷 MyISAM 테이블에 디폴트 체크 타입 또한 MEDIUM이다. 그런 경우, 디폴트가 QUICK 이
다. 로우가 오류를 일으키는 경우가 매우 드물기 때문에, 로우 스캔은 CHANGED와 FAST의 경우 생략한다.
완전히 종료되었는지 결정하기 위해 테이블에서 빠른 체크를 실행하는 다음의 예와 같이 체크옵션을 결합할 수도 있다:
CHECK TABLE test_table FAST QUICK;
주의: 몇 명의 경우에서 CHECK TABLE은 테이블을 변경시킨다. 만약 테이블에 “오류발생” 또는 “완전히 종료되지 않음”이
라는 표시가 나타나면 이런 변경이 발생한다. 그러나 CHECK TABLE은 이 테이블에서 문제점을 찾지 못한다. 이런 경우 CHECK
TABLE은 OK로 표시된다.
테이블에 오류가 발생한다면, 문제가 데이터 파트가 아니라 인덱스에 있다는 것과 같다. 전술한 체크 타입 모두 인덱스를 완전히 체
크하며, 모든 에러를 찾아낸다.

:::MySQL Korea:::
OK라고 생각되는 테이블을 체크하고자 한다면, 체크옵션이나 QUICK옵션을 사용할 필요가 없다. 후자(QUICK 옵션)는 급할 때
사용되며, 데이터파일에서 QUICK이 에러를 찾아내지 못하는 정도의 매우 작은 리스크를 감당할 수 있다. (대부분의 경우, 일반적
인 사용에는 MySQL이 데이터파일에 있는 모든 에러를 찾아낸다. 이런 경우가 발생하면, 테이블에 “corrupted”라고 표시되며
정정될 때까지 사용이 중단된다.)
만약 때때로 테이블을 체크하고자 한다면, FAST 와 CHANGED 는 대체로 한 스크립트로부터 사용된다(예를 들어 cron 으로부
터 실행됨) 대부분의 경에, FAST 가 CHANGED보다 선호된다. (그것이 선호되지 않는 경우는 오로지 MyISAM코드에서 버그가
발견되었다고 생각될 때 뿐이다.)
EXTENDED 는 일반적으로 체크하고도 MySQL이 로우를 업데이트하거나, 키로 로우를 찾을 때, 테이블에서 이상한 에러가 생기
는 경우에만 사용된다. 일반적인 체크가 성공한다면, 이런 경우는 아주 드물다.
CHECK TABLE로 리포트되는 몇 가지 문제는 자동적으로 정정되지 않는다:
● Auto_increment 컬럼이 0 값인 로우를 찾아라.
이것은 테이블에 AUTO_INCREMENT 인덱스 컬럼이 0 값을 포함한 로우가 있음을 의미한다. (UPDATE 문으로 컬럼
을 명확하게 0으로 셋팅함으로써 AUTO_INCREMENT 컬럼이 0인 로우를 생성할 수 있다. )
이것은 그 자체로써 에러가 아니다. 그러나 테이블을 덤프하고 그것을 복구하거나 또는 테이블에서 ALTER TABLE을 하
기로 결정한다면, 트러블을 일으킬 수 있다. 이런 경우, AUTO_INCREMENT 컬럼은 중복-키 에러와 같은 문제를 야기
하는 AUTO_INCREMENT 컬럼 규칙에 따라 값을 변경한다.
이런 경고를 제거하기 위해서, 0과는 다른 값으로 컬럼을 셋팅하려면 UPDATE문을 실행한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 113.5.2.4. CHECKSUM TABLE
13.5. 데이터베이스 관리문 CHECKSUM TABLE tbl_name [, tbl_name] ... [ QUICK | EXTENDED ]

CHECKSUM TABLE 은 테이블의 검사합계를 리포트한다.
13.5.2.4 CHECKSUM TABLE 유효한 테이블 검사합계는 그것이 유효하거나 NULL이면 QUICK으로 리포트된다. 이것은 매우 빠르다. 유효한 검사합계는 테이
13.5.2.5 OPTIMIZE TABLE 블을 생성할 때, CHECKSUM=1 테이블 옵션을 지정함으로써 가능해진다; 현재, 이것은 MyISAM 테이블에서만 지원된다.
13.5.2.6 REPAIR TABLE 13.1.5, “CREATE TABLE ”장을 참조하라.
EXTENDED로, 전체 테이블은 로우별로 읽혀진다. 이것은 테이블이 크면 매우 천천히 실행된다.
QUICK 이나 EXTENDED 모두 지정되지 않아 테이블 스토리지 엔진이 지원되지 않고 다른 방법으로 테이블이 스캔되면, MySQL
은 유효한 검사합계를 리턴한다.
존재하지 않는 테이블의 경우, CHECKSUM TABLE 은 NULL 을 리턴한다. 이것은 MySQL 5.0.3 부터 경고하고 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.2.5. OPTIMIZE TABLE
13.5. 데이터베이스 관리문 OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name [, tbl_name] ...

OPTIMIZE TABLE 은 테이블의 많은 부분을 삭제하거나 테이블에 변경사항이 많아 테이블에 가변길이 로우를 적용할 때 사용된
다(VARCHAR, VARBINARY, BLOB, 또는 TEXT 컬럼을 가진 테이블). 삭제된 로우는 연계된 리스트에 계속 남아있고 그 다음
INSERT 실행은 이전 로우 포지션을 재사용한다. OPTIMIZE TABLE 은 사용한 적이 없는 스페이스를 교정하고, 데이터파일을
조각처리하기 위해서 사용할 수 있다.
13.5.2.7 RESTORE TABLE 이 문은 테이블에서 SELECT와 INSERT 권한을 요구한다.
대체로 셋업에는, OPTIMIZE TABLE이 전혀 필요하지 않다. 비록 가변길이 로우로 업데이트를 많이 한다고 하더라도, 일주일이
나 한 달에 한 번 이상이 일정한 테이블에서만 할 필요는 없다.
OPTIMIZE TABLE MyISAM, BDB, InnoDB 테이블에서만 적용된다.
MyISAM 테이블의 경우, OPTIMIZE TABLE 은 다음과 같이 실행된다:

:::MySQL Korea:::
1. 테이블이 삭제되거나 로우를 분리한다면, 테이블을 복구한다.

2. 인덱스 페이지가 정렬되어 있지 않다면, 그것을 정렬한다.
3. 테이블의 통계가 데이터에 반영되지 않았다면(그리고 인덱스 정렬로 복구가 완료되지 않았다면), 그것을 업데이트한
다.
BDB 테이블의 경우, OPTIMIZE TABLE 는 ANALYZE TABLE로 표시된다. 13.5.2.1, “ANALYZE TABLE Syntax”장을
참조하라.
InnoDB 테이블의 경우, OPTIMIZE TABLE 은 ALTER TABLE로 표시된다. 이것은 인덱스 통계와 연결된 인덱스에서 사용되
지 않는 공간을 업데이트하여, 테이블을 개조한다.
--skip-new 또는 --safe-mode 옵션으로 mysqld를 시작함으로써 OPTIMIZE TABLE 을 다른 스토리지 엔진에서 작용하게
만들 수 있다. 이런 경우, OPTIMIZE TABLE 은 ALTER TABLE로 표시된다.
OPTIMIZE TABLE 은 다음 컬럼과 같이 결과 셋으로 리턴한다:
Column Value
Op 항상 optimize

:::MySQL Korea:::
Msg_text 메시지
OPTIMIZE TABLE을 실행하는 동안 MySQL은 테이블을 고정시킨다는 것을 주의하라.
임의의 NO_WRITE_TO_BINLOG 키워드(또는 그것의 알리아스 LOCAL) 를 사용하지 않는다면, OPTIMIZE TABLE 문은 바이
너리 로그로 씌여 있다. 그래서 MySQL 서버에서 리플리케이션 마스터로 사용하는 OPTIMIZE TABLE 문은 리플리케이션 슬레
이브에서 디폴트로 복제될 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.2.6. REPAIR TABLE
13.5. 데이터베이스 관리문 REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE

tbl_name [, tbl_name] ... [QUICK] [EXTENDED] [USE_FRM]
REPAIR TABLE 은 아마도 손상된 테이블을 복구할 것이다. 디폴트로 그것은 myisamchk --recover tbl_name 과 같은 결과
를 갖는다. REPAIR TABLE 은 MyISAM과 ARCHIVE 테이블에서 동작한다. 14.1, “MyISAM 스토리지 엔진”장과 14.8,
“ARCHIVE 스토리지 엔진”장을 참조하라.
이 문은 테이블에서 SELECT와 INSERT 권한을 요구한다.
일반적으로, 이 문을 실행할 필요가 없다 그러나, 장애가 발생하면, REPAIR TABLE이 MyISAM테이블로부터 모든 데이터를 되
돌린다. 만약 테이블이 자주 오류를 일으킨다면, 그것의 원인을 찾아 REPAIR TABLE을 이용할 필요가 없도록 해야 한다. A.4.2,
“MySQL 시스템 고장시 대처법”, 장과 14.1.4, “MyISAM 테이블 문제들”장을 참조하라.
주의: REPAIR TABLE 실행 중 서버가 멈춘다면, 우선 서버를 재시작한 후, 어떤 작동을 하기 전에 즉시 다른 REPAIR TABLE문
을 실행한다. (백업하고 새로 시작하는 것이 언제나 가장 좋다.) 최악의 경우, 데이터파일에 관한 정보없이 새로운 인덱스 파일을
만들어야 한다. 그리고 나서 해야 할 일은 데이터파일을 중복해서 쓰는 것이다. 그러나 이런 일은 거의 일어나지 않는다.

:::MySQL Korea:::
REPAIR TABLE 은 다음 컬럼과 같이 결과 셋으로 리턴한다:
Column Value
Op 항상 repair
Msg_text 메시지
REPAIR TABLE 문은 각 복구된 테이블에 관한 정보의 로우가 많이 생성된다. 마지막 로우는 status의 Msg_type 값을 갖으며,
Msg_test는 일반적으로 OK이다. OK되지 않은 경우, myisamchk --safe-recover 로 테이블을 복구해 본다. (REPAIR
TABLE 은 아직 myisamchk 의 모든 옵션에서 실행되지 않는다.) myisamchk --safe-recover로, --max-record-length
와 같이, REPAIR TABLE이 지원하는 옵션을 사용할 수 있다.
QUICK 이 주어지면, REPAIR TABLE 인덱스 트리만 복구하려고 시도한다. 이런 복구 타입은 myisamchk --recover --
quick 로 하던 것과 같다.
EXTENDED를 사용한다면, MysQL은 인덱스를 한번에 하나씩 생성하지 않고 로우별로 차례로 생성한다. 이런 복구 타입은
myisamchk --safe-recover 로 하던 것과 같다.

:::MySQL Korea:::
REPAIR TABLE 의 경우 USE_FRM 모드를 사용할 수 있다. .MYI 인덱스 파일이 빠지거나 또는 그것의 헤더가 손상되었다면, 이
것을 이용하라. 이런 모드에서, MySQL은 .frm 파일로부터 정보를 사용하는 .MYI 파일을 재 생성한다. 이런 종류의 복구는
myisamchk 로 할 수 없다. 주의: 이 모드는 보통의 REPAIR 모드가 사용되지 못할 경우에만 사용하라. .MYI 헤더는 REPAIR ...
USE_FRM 에 묻혀있는 중요한 테이블 메타데이터를 포함하고 있다. (특히, 현재 AUTO_INCREMENT 값과 Delete link) 이런
정보가 .MYI 파일에 저장되어 있기 때문에, 테이블이 압축되었다면, USE_FRM을 사용하지 말라.
임의의 NO_WRITE_TO_BINLOG 키워드(또는 그것의 알리아스 LOCAL)를 사용하지 않는다면, REPAIR TABLE 문은 바이너
리 로그로 쓰여진다. 그래서 MySQL 서버에서 리플리케이션 마스터로 사용하는 REPAIR TABLE 문은 리플리케이션 슬레이브에
서 디폴트로 복제될 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.2.7. RESTORE TABLE
13.5. 데이터베이스 관리문 RESTORE TABLE tbl_name [, tbl_name] ... FROM '/path/to/backup/directory'

RESTORE TABLE 은 테이블 또는 BACKUP TABLE로 된 백업 테이블을 복구한다. 현재 테이블은 중복되지 않는다: 현재 테이
블을 복구하고자 한다면, 에러가 발생한다. BACKUP TABLE, RESTORE TABLE 은 현재 MyISAM 테이블에서만 작동한다. 디
렉토리는 풀 경로이름으로 지정해야한다.
13.5.2.6 REPAIR TABLE 각 테이블의 백업은 그것의 .frm 포맷 파일과 .MYD 데이터 파일로 구성된다. 복구실행은 그런 파일을 복구하고 나서 .MYI 인덱스
13.5.2.7 RESTORE TABLE 파일을 개조하기 위해 그것을 사용한다. 인덱스 개조가 필요하기 때문에 복구하는 것이 백업하는 것보다 오래 걸린다. 테이블에 인
덱스가 많을수록 시간은 더 길어진다.
RESTORE TABLE 은 다음 컬럼과 같이 결과 셋으로 리턴한다:
Column Value
Op 항상 restore

:::MySQL Korea:::
Msg_text 메시지

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.3. SET
13. SQL 문법(SQL Statement Syntax) SET variable_assignment [, variable_assignment] ...

13.5.3 SET variable_assignment:

user_var_name = expr
| [GLOBAL | SESSION] system_var_name = expr
| [@@global. | @@session. | @@]system_var_name = expr
SET 문은 서버혹은 여러분의 client의 동작에 영향을 주는 다른 종류의 변수들에 값들을 할당하는 문장이다. MySQL의 이전 버전
에서는 SET OPTION을 사용했으나 이 문은 OPTION없이 SET만을 사용하도록 변경되었다.
이 장에서는 시스템 변수 혹은 사용자 변수에 값 할당을 위한 SET의 사용에 대해 설명한다. 이들 변수들에 대한 좀더 일반 적인 정

보는 5.2.2 장 “Server System Variables”와 9.3장 “User-defined variables”을 참조하라.
시스템 변수들은 5.2.3장 “Using System Variables”에서 설명 되는 바와 같이 서버의 시작 시점에 설정될 수 있다.
몇몇 SET문의 변형이 다음과 같은 문에서 사용될 수 있다:
● SET PASSWORD 는 사용자 계정에 대한 비밀 번호를 할당한다. 13.5.1.6장 “SET PASSWORD”를 참조하라
● SET TRANSACTION ISOLATION LEVEL 은 트랜잭션 처리에 대한 격리 레벨을 설정한다. 13.4.6장 “SET
TRANSACATION”을 참조하라.
● SET은 로컬 루틴 변수들에 값을 할당하기 위해 저장 루틴 안에서 사용된다. 17.2.7.2장 “Variables SET 문”을 참조하
라.
다음 논의는 여러분이 변수들에 갑을 할당하기 위해 사용할수 있는 다른 SET구문들을 보여준다. 예제들은 할당 연산자로 = 를 사

:::MySQL Korea:::
용 하지만 := 연산자도 사용가능하다.

하나의 사용자 변수는 @var_name 로 씌여지며 다음과 같이 할당 될수 있다.
SET @var_name = expr;
많은 시스템 변수들은 동적이고 서버가 SET문을 사용하여 실행 하는 동안 변경 될수 있다. 이에 대한 사항은 5.2.3.2장

“Dynamic System Variables”을 참조하라. 시스템 변수를 SET을 사용하려 변경 하기 위해서는 var_name 으로 참조하고 선택
적으로 수식어 앞에 놓인다:
● 변수가 global변수임을 명시적으로 지정하기 위해서는 변수 이름 앞에 GLOBAL 이나 @@global을 쓴다. global변수 설정

을 위해서는 SUPER권한이 필요하다.
● 변수가 세션 변수임을 명시적으로 지정하기 위해서는 변수 이름 앞에 SESSION, @@session 혹은@@를 사용한다. 세션
변수 설정에는 특별한 권한이 요구 되지는 않는다. 그러나 client는 자신의 세션 변수만을 변경할수 있다.
● LOCAL 과 @@local. 는 SESSION 과 @@session..의 동의어이다.
● 수식어(modifier)가 없는 경우 SET은 세션 변수를 변경한다.
한 SET 문은 콤마로 분리되는 다중 변수 할당을 포함할 수 있다. 여러분이 몇가지의 시스템 변수를 할당하면 그 문안의 가장 빈번
한GLOBAL혹은 SESSION 수식어들이 수식어가 명시되지 않은 다음 변수들에 사용될 수 있다.
예:
SET sort_buffer_size=10000;
SET @@local.sort_buffer_size=10000;
SET GLOBAL sort_buffer_size=1000000, SESSION sort_buffer_size=1000000;
SET @@sort_buffer_size=1000000;
SET @@global.sort_buffer_size=1000000, @@local.sort_buffer_size=1000000;
여러분이 SET으로 하나의 시스템 변수에 값을 할당할 때, 그 값에 접미어(suffix)를 쓸 수 없다.(이것은 시작 옵션에서 가능한 기
능이다). 그러나 그 값은 다음과 같은 형태의 표현을 가질 수 있다:
SET sort_buffer_size = 10 * 1024 * 1024;

:::MySQL Korea:::
시스템 변수를 위한 @@var_name 구문은 다른 데이터베이스 시스템과 호환성을 위해 제공된다.
세션 시스템 변수를 변경하면, 그 값은 여러분의 세션이 끝나거나 여러분이 그 값을 다른 값으로 변경 할때까지 유지된다. 그 변경
은 다른 client들에게는 보여지지 않는다.
global 시스템 변수를 변경하면, 그 값은 서버가 재 시작 될 때까지 기억되어 새로운 연결에 대해서 사용된다. (global 시스템 변
수의 설정을 영구적으로 만들기 위해서는 옵션 파일 안에 설정해 놓아야 한다.) 그 변경은 global변수에 접근하는 어느 client에게
도 보여진다. 그러나, 그 변경은 이후에 연결하는 클라이언트들에 대해서만 영향을 미친다. global변수 변경은 현재 연경되어 있는
client들을 위한 세션 변수에는 영향을 미치지 않는다. (SET GLOBAL 문을 사용하는 clicent 변수라 할지라도)
잘못된 사용을 방지하기 위해 MySQL은 여러분이 SET SESSION과 사용될수 있는 변수에 SET GLOBAL을 사용하거나 global
변수를 설정할 때 GLOBAL(혹은 @@global)을 명시하지 않으면 에러를 발생한다.
컴파일된 MySQL 기본 값에 GLOBAL 값이나 SESSION 변수에 GLOBAL변수를 설정하기 위해서는 DEFAULT 키워드를 사용하
라. 예를 들면 다음 두 문장은 max_join_siz의 세션 값을 global 변수로 설정한다.
SET max_join_size=DEFAULT;
SET @@session.max_join_size=@@global.max_join_size;
모든 시스템 변수가 DEFAULT가 될수는 없다. 이런 경우, DEFAULT 의 사용은 에러를 발생 시킨다.
여러분은 @@-수식어들중 하나를 사용하여 표현들에서 특정global혹은 session 시스템 변수들의 값을 참조 할 수 있다. 예를 들
면 여러분은 아래와같이 SELECT문에서 값들을 가져올 수 있다:
SELECT @@global.sql_mode, @@session.sql_mode, @@sql_mode;
한 표현(expression)에서 @@var_name(@@global 혹은 @@session을 명시하지 않은 경우)으로 시스템 변수를 참조할 때,

MySQL은 그 값이 존재 하나 global 변수인 경우 그 세션 값을 리턴한다. (이는 항상 세션 값을 참조하는 SET @@var_name =
value과는 다르다.)
시스템 변수이름과 값들을 display하기 위해서 SHOW VARIABLES문을 사용하라. ( 13.5.4.24, 장“SHOW VARIABLES ”을

:::MySQL Korea:::
참조하라.)
다음 리스트는 5.2.2장 “Server System Variables”에서 보여지는 시스템 변수들을 리스트에서 설명되지 않거나 비 표준 구문
을 가진 옵션들을 설명한다. 여기에서 설명되는 옵션들이 SHOW VARIABLES에 의해 display되지는 않지만 여러분은 SELECT
를 사용하여 그 값들을 얻을수 있다.(CHARACTER SET 과 SET NAMES는 제외)
예를 들면:
mysql> SELECT @@AUTOCOMMIT;

+--------------+
| @@AUTOCOMMIT |
+--------------+
| 1|
+--------------+
이들 옵션에 대한 대소분자 구분은 문제 되지 않는다.
● AUTOCOMMIT = {0 | 1}
Autocomint 모드로 설정한다. 1로 설정하면 한 테이블에 대한 모든 변경들이 즉시 영향을 미친다. 0으로 설정하면 한 트
랜잭션을 받아들이기 위해 COMMIT을 사용하거나 그것을 취소하기 위해서 ROLLBACK을 사용해야 한다. 기본적으로
client 연결은 AUTOCOMMIT을 1로 하여 시작한다. 여러분이 AUTOCOMMIT을 0에서 1로 변경하면, MySQL은 트랜
잭션에 대한 자동 COMMIT을 수행한다. 트랜잭션을 시작하기 위한 다른 방법은 START TRANSACTION이나 BEGIN
문을 사용하는 것이다. 13.4.1 장 “START TRANSACTION, COMMIT그리고 ROLLBACK문”을 참조하라.
● BIG_TABLES = {0 | 1}
1로 설정하면 모든 임시 테이블들은 메모리가 아닌 디스크에 저장된다. 그러나 에러문인 The table tbl_name is full은
큰 임시 테이블을 필요로하는 SELECT 연산에 대해서는 일어나지 않는다. 새로운 연결에 대한 기본값은 0(메모리 임시
테이블)이다. 보통, In-메모리 테이블들은 필요할 경우 disk 기반 테이블들로 자동으로 변환되기 때문에, 여러분은 이 값
을 설정할 필요가 없다. (Note: 이 변수는 SQL_BIG_TABLES로 명명되었다.)

:::MySQL Korea:::
● CHARACTER SET {charset_name | DEFAULT}
이것은 주어진 매핑으로 클라이언트와 주고 받는 모든 문자열들을 매핑한다. MySQL 소스 배포에서 sql/convert.cc를

편집하여 새로운 매핑을 추가할 수 있다. SET CHARACTER SET 세개의 세션 시스템 변수들을 설정한다:
character_set_client와 character_set_results는 주어진 문자 셋에 설정되고 character_set_database의 값을
character_set_connection으로 설정된다. 10.4, 장“Connection Character Sets and Collations”을 참조하라.
기본 매핑은 DEFAUT를 사용함으로써 복귀 시킬수 있다. 기본값은 서버 구성에 따라 좌우 된다.

SET CHARACTER SET에 대한 구문이 대부분의 다른 옵션 설정과는 다르다는 점을 주의 하라.
● FOREIGN_KEY_CHECKS = {0 | 1}
기본 값으로 1을 설정하면, InnoDB테이블에 대한 외래 키 제한이 체크 된다. 0으로 설정하는 경우 그것들은 무시 된다. 외

부키 체크를 Disable로 하면 테이블들의 parent/child 관계에 의해 요구 되어지는 것과 다른 순서로 InnoDB테이블들을
재 로드 하는 데에 유용하다. 14.2.6.4장 “FOREIGN KEY 제한”을 참조하라.
● IDENTITY = value
이 변수는 LAST_INSERT_ID 변수와 동의어 이다. 이것은 다른 데이터베이스 시스템과의 호환성을 위해 존재 한다. 여러
분은 SELECT @@IDENTITY를 사용하여 이 값을 읽고 SET IDENTITY를 이용하여 값을 설정 할 수 있다.
● INSERT_ID = value
AUTO_INCREMENT 값을 삽입하는 경우 다음 INSERT 혹은 ALTER TABLE문에서 사용 되는 값을 설정한다. 이는

바이너리 로그와 함께 주로 사용된다.
● LAST_INSERT_ID = value
LAST_INSERT_ID()로부터 리턴된 값을 설정한다. 이것은 여러분이 테이블을 update하는 SQL문에서

LAST_INSERT_ID()를 사용할 때 바이너리 로그에 저장될 수 있다. 이 변수를 설정하면 mysql_insert_id() C API함수
에 의해 리턴된 값을 갱신하지 않는다.

:::MySQL Korea:::
● NAMES {'charset_name' | DEFAULT}
SET NAMES 는 세개의 세션 시스템 변수인 character_set_client, character_set_connection, 그리고

character_set_results 을 주어진 문자 셋으로 설정한다. character_set_connection 을 charset_name 으로 설정하면
collation_connection 을 기본 charset_name을 위한 기본 대조를 설정한다. 10.4장 “Connection Character Sets and
Collations”을 참조하라.
기본 매핑은 DEFAULT를 사용하여 복귀 될수 있다. 기본 값들은 서버의 구성에 따라 좌우 된다.
SET NAMES에 대한 문법은 대부분의 다른 옵션에 대한 설정과 다르다는 것에 주의 하라.
● ONE_SHOT
이 옵션은 하나의 변수가 아닌 수식어(modifier)이다. 이것은 문자셋, 대조(collation) 그리고 타임존(time zone)을 설정
하는 변수들의 효과에 영향을 주는 데 사용될 수 있다. ONE_SHOT은 주로 복제 목적으로 사용된다: mysqlbinlog는
rollforward시에 반영하기 위해 문자셋(character set), 대조(collation) 그리고 타임존(time zone)의 값들을 일시적으
로 변경하기 위해SET ONE_SHOT을 사용한다. ONE_SHOT은 MySQL 5.0에서부터 가능하다.
여러분은 허락된 변수들 외에 다른데서 ONE_SHOT을 사용할 수 없다. 만약 이를 시도할 경우 아래와 같은 에러를 얻게
된다:
mysql> SET ONE_SHOT max_allowed_packet = 1;

ERROR 1382 (HY000): The 'SET ONE_SHOT' syntax is reserved for purposes
internal to the MySQL server
ONE_SHOT이 허락된 번수들과 함께 사용될 경우 그 변수들을 요구 되는(requested)상태로 변경하지만 다음 비 SET

문에대해서만 해당 된다. 이후, 서버가 모든 문자 셋, 대조(collation)과 타임존(time zone)관련 시스템 변수들을 이전 값
들로 리셋한다.
예:
mysql> SET ONE_SHOT character_set_connection = latin5;

:::MySQL Korea:::
mysql> SET ONE_SHOT collation_connection = latin5_turkish_ci;
mysql> SHOW VARIABLES LIKE '%_connection';

+--------------------------+-------------------+
+--------------------------+-------------------+
| collation_connection | latin5_turkish_ci |
+--------------------------+-------------------+
mysql> SHOW VARIABLES LIKE '%_connection';

+--------------------------+-------------------+
+--------------------------+-------------------+
| collation_connection | latin1_swedish_ci |
+--------------------------+-------------------+
● SQL_AUTO_IS_NULL = {0 | 1}
1(기본 값)로 설정하면 여러분은 다음 문을 사용하여 AUTO_INCREMENT 컬럼을 포함하고 있는 테이블의 최근 삽입된
레코드를 찾을 수 있다:
WHERE auto_increment_column IS NULL
이것은 Access와 같은 몇몇 ODBC프로그램들에 의해 사용된다.
● SQL_BIG_SELECTS = {0 | 1}
0으로 설정하면 MySQL은 수행하는데 오랜 시간이 걸릴 것 같은 SELECT문을 중지한다. (검사 되는 레코드 수가

max_join_size의 값을 초과하는지 검사하는 최적화기(optimizer)를 위한 문들이다.) 이것은 부적당한 WHERE문이 실
행 될 때 유용하다. 새 연결에 대한 기본 값은 1이고 이것은 모든 SELECT문을 허락한다.
여러분이 max_join_size 시스템 변수를 DEFAULT가 아닌 값으로 설정하면 SQL_BIG_SELECTS는 0으로 설정된다.

:::MySQL Korea:::
● SQL_BUFFER_RESULT = {0 | 1}
1로 설정하면 SQL_BUFFER_RESULT 은 SELECT문의 결과를 임시 테이블에 넣도록 한다. 이것은 MySQL이 그 테이

블을 빨리 lock을 풀수 있게 하며 결과를 client에 보내는데 오래 걸리는 경우에 유용하다. 기본 값은 0이다.
● SQL_LOG_BIN = {0 | 1}
0으로 설정되면 client를 위한 바이너리 로그에 로그 정보가 남지 않느다. 클라이언트는 이 옵션을 설정하기 위해서
SUPER 권한을 가져야 한다. 기본 값은 0이다.
● SQL_LOG_OFF = {0 | 1}
1로 설정하면 이 클라이언트에 대해 일반적인 쿼리에 대한 로그가 남지 않는다. 이 옵션을 설정하기 위해서는 client가
SUPER권한을 가져야 한다. 기본 값은 0이다.
● SQL_LOG_UPDATE = {0 | 1}
이 변수는 무시되고 SQL_LOG_BIN으로 매핑된다.
● SQL_NOTES = {0 | 1}
1(기본값)으로 설정하면, Note레벨의 경고가 기록된다. 0으로 설정하면 Note 경고들은 은폐(suppressed)된다.
Mysqldump는 이 값을 0으로 하여 dump 파일의 재로드가 재로드 연산의 무결성에 영향을 주지 않는 이벤트들에 대한 경
고를 생성하지 않도록 하기 위해 output을 포함한다. SQL_NOTES 는 MySQL 5.0.3에서 추가 되었다.
● SQL_QUOTE_SHOW_CREATE = {0 | 1}
1(기본 값)으로 설정하면 서버는 SHOW CREATE TABLE 와SHOW CREATE DATABASE 문들에 대한 지시자들을
인용한다. 0으로 설정하면 인용은 disable상태가 된다. 이 옵션은 기본적으로 enable되어 인용이 필요한 지시자들을 위
해 복제를 한다. 13.5.4.6, 장“SHOW CREATE TABLE ”과 13.5.4.4장 “SHOW CREATE DATABASE ”을 참조
하라.

:::MySQL Korea:::
● SQL_SAFE_UPDATES = {0 | 1}
1로 설정하면 MySQL은 WHER절이나 LIMIT절에서 key를 사용하지 않는 UPDATE 혹은 DELETE문의 실행을 중지한
다. 이것은 많은 수의 레코드를 변경하거나 삭제 할 경우 키들이 사용되지 않는 UPDATE 혹은 DELETE문을 catch하도
록 한다. 기본값은 0이다.
● SQL_SELECT_LIMIT = {value | DEFAULT}
SELECT문에서 리턴되는 최대 레코드 수를 지정한다. 새로운 연결에 대해서 기본 값이 “unlimited”이다. 여러분이 그

limit을 변경하면 기본값은 DEFAULT의 값으로 SQL_SELECT_LIMIT을 사용하여 복귀 시킬 수 있다.
SELECT 가 LIMIT절을 가진 경우 그 LIMIT은 SQL_SELECT_LIMIT의 값에 대해 우선권을 갖는다.
SQL_SELECT_LIMIT 는 저장 루틴안에서 실행되는SELECT문에는 적용되지 않는다. 이것은 client에 리턴될 결과 집합
을 생성하지 않는 SELECT문에서 도 적용되지 않는다. 이들은 CREATE TABLE … SELECT 와 InSERT INTO …
SELECT의 하부 쿼리로 SELECT문을 포함한다.
● SQL_WARNINGS = {0 | 1}
이 변수는 단일 레코드 INSERT문이 경고가 발생할 경우 정보 문자열을 생성할 것인지를 조절한다. 기본 값은 0이다. 정
보 문자열을 생성하기 위해서는 값을 1로 설정한다.
● TIMESTAMP = {timestamp_value | DEFAULT}
이 클라이언트에 대한 시간을 설정한다. 이것은 여러분이 레코드들을 복원하기 위해 바이너리 로그를 사용하는 경우 원래
timestamp를 얻는데 사용된다. Timestamp_value는 MySQL의 timestamp가 아닌Unix 에서의 timestamp이어야 한
다.
SET TIMESTAMP 은 SYSDATE()가 아닌 NOW()에 의해 리턴되는 값에 영향을 준다. 이는 바이너리 로그에서
timestamp 설정들이 SYSDATE()호출에서 영향을 미치지 않는 것을 의미한다. 서버가SYSDATE()가 NOW()에 대한
별칭이 되도록 하는 –sysdate-is-now 옵션과 함께 시작될 수 있다. 이 경우 SET TIMESTAMP는 두 함수에 영향을
준다.
● UNIQUE_CHECKS = {0 | 1}

:::MySQL Korea:::
1(기본값)으로 설정하면 InnoDB테이블들에서 두 번째 인덱스들에 대한 유일성 체크가 수행된다. 0으로 설정하면 저장

엔진은 중복 키들이 입력 데이터에서 나타나지 않도록 추측하도록 하락된다. 여러분이 여러분의 데이터가 유일성의 위배
를 포함하는지를 확실하게 안다면 이 값을 0으로 설정하여 InnoDB로의 큰 테이블을 import하는데 속도를 높일 수 있다.
이 값을 0으로 설정하면 저장엔진이 중복 키들을 무시하도록 요구하지 않는다. 엔진은 이것들을 체크하도록 허락되고 이
를 감지할 경우 중복 키 에러를 발생한다.

:::MySQL Korea:::
제목검색
13.5.4. SHOW
13. SQL 문법(SQL Statement Syntax) 13.5.4.1. SHOW CHARACTER SET

13.5. 데이터베이스 관리문 13.5.4.2. SHOW COLLATION
13.5.4 SHOW 13.5.4.3. SHOW COLUMNS
13.5.4.1 SHOW CHARACTER SET 13.5.4.4. SHOW CREATE DATABASE
13.5.4.2 SHOW COLLATION 13.5.4.5. SHOW CREATE PROCEDURE 와 SHOW CREATE FUNCTION
13.5.4.3 SHOW COLUMNS 13.5.4.6. SHOW CREATE TABLE

13.5.4.7. SHOW CREATE VIEW
13.5.4.8. SHOW DATABASES
13.5.4.9. SHOW ENGINE
13.5.4.10. SHOW ENGINES
13.5.4.11. SHOW ERRORS
13.5.4.12. SHOW GRANTS
13.5.4.13. SHOW INDEX
13.5.4.14. SHOW INNODB STATUS
13.5.4.11 SHOW ERRORS 13.5.4.15. SHOW LOGS
13.5.4.12 SHOW GRANTS 13.5.4.16. SHOW OPEN TABLES
13.5.4.13 SHOW INDEX 13.5.4.17. SHOW PRIVILEGES
13.5.4.14 SHOW INNODB STATUS 13.5.4.18. SHOW PROCEDURE STATUS 와 SHOW FUNCTION
13.5.4.15 SHOW LOGS STATUS
13.5.4.16 SHOW OPEN TABLES 13.5.4.19. SHOW PROCESSLIST
13.5.4.17 SHOW PRIVILEGES 13.5.4.20. SHOW STATUS

13.5.4.21. SHOW TABLE STATUS
13.5.4.22. SHOW TABLES
13.5.4.23. SHOW TRIGGERS

:::MySQL Korea:::
13.5.4.20 SHOW STATUS 13.5.4.24. SHOW VARIABLES
13.5.4.21 SHOW TABLE STATUS 13.5.4.25. SHOW WARNINGS


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.1. SHOW CHARACTER SET
13. SQL 문법(SQL Statement Syntax) SHOW CHARACTER SET [LIKE 'pattern']
13.5.4 SHOW SHOW CHARACTER SET 문은 모든 사용할 수 있는 캐틱터 셋을 보여준다. 그것은 어떤 캐릭터 셋이 이름과 매치되는지 보여주
는 임의의 LIKE 절을 취한다. 예를 들어:
mysql> SHOW CHARACTER SET LIKE 'latin%';
13.5.4.4 SHOW CREATE DATABASE +---------+-----------------------------+-------------------+--------+
13.5.4.5 SHOW CREATE PROCEDURE 와
SHOW CREATE FUNCTION | Charset | Description | Default collation | Maxlen |
13.5.4.7 SHOW CREATE VIEW +---------+-----------------------------+-------------------+--------+

13.5.4.14 SHOW INNODB STATUS | latin7 | ISO 8859-13 Baltic | latin7_general_ci | 1|
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES +---------+-----------------------------+-------------------+--------+

13.5.4.18 SHOW PROCEDURE STATUS 과
SHOW FUNCTION STATUS

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST Maxlen 컬럼은 하나의 캐릭터를 저장하기 위해 요구되는 최대 바이트 수를 보여준다.


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.2. SHOW COLLATION
13. SQL 문법(SQL Statement SHOW COLLATION [LIKE 'pattern']

Syntax)
13.5. 데이터베이스 관리문 SHOW COLLATION의 출력은 모든 사용가능한 캐릭터셋을 포함한다. 이것은 대조 이름이 일치하도록 하는 pattern 을 보여주는 임의의
13.5.4 SHOW LIKE절을 갖는다. 예를 들면:

+-------------------+---------+----+---------+----------+---------+
13.5.4.5 SHOW CREATE | Collation | Charset | Id | Default | Compiled | Sortlen |
PROCEDURE 와 SHOW
CREATE FUNCTION
+-------------------+---------+----+---------+----------+---------+
13.5.4.7 SHOW CREATE VIEW | latin1_german1_ci | latin1 | 5 | | | 0|
13.5.4.9 SHOW ENGINE | latin1_swedish_ci | latin1 | 8 | Yes | Yes | 0|

13.5.4.14 SHOW INNODB STATUS | latin1_bin | latin1 | 47 | | Yes | 0|
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES | latin1_general_ci | latin1 | 48 | | | 0|


:::MySQL Korea:::
13.5.4.18 SHOW PROCEDURE

STATUS 과 SHOW | latin1_spanish_ci | latin1 | 94 | | | 0|
FUNCTION STATUS
13.5.4.19 SHOW PROCESSLIST +-------------------+---------+----+---------+----------+---------+

13.5.4.21 SHOW TABLE STATUS Default 컬럼은 그 캐릭터 셋에서 조합(collation)이 디폴트인지 보여준다. Compiled 는 캐릭터 셋이 서버로 컴파일되는지 보여준다.
13.5.4.22 SHOW TABLES Sortlen 은 캐릭터 셋에서 나타내는 일련의 스트링에 요구되는 메모리 양과 관계가 있다.


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.3. SHOW COLUMNS
13. SQL 문법(SQL Statement Syntax) SHOW [FULL] COLUMNS FROM tbl_name [FROM db_name] [LIKE 'pattern']
13.5.4 SHOW SHOW COLUMNS 주어진 테이블에 있는 컬럼에 대한 정보를 보여준다. 이것은 MySQL5.0.1버전의 뷰에서 작동한다

만약 데이터 타입이 CREAT TABLE문에 근거를 두고 예상한 것과 다르다면, MySQL이 테이블을 생성하거나 변경할 때 간혹 데
이터 타입이 변경된다는 것을 명심하라. 이런 상황이 발생하는 조건은 13.1.5.1, “암묵적 컬럼 지정 변경”.장에 서술되어 있다.
SHOW CREATE FUNCTION FULL 키워드는 각 컬럼에 대한 컬럼당 주석과 권한을 포함한 출력을 야기한다.
db_name.tbl_name 와tbl_name FROM db_name 둘 중에 선택적으로 사용할 수 있다. 다시 말해서, 이 두 문은 같다:
mysql> SHOW COLUMNS FROM mytable FROM mydb;
13.5.4.12 SHOW GRANTS mysql> SHOW COLUMNS FROM mydb.mytable;
13.5.4.14 SHOW INNODB STATUS SHOW FIELDS 와SHOW COLUMNS는 동의어이다. mysqlshow db_name tbl_name 명령으로 테이블의 컬럼을 기록할 수 있
13.5.4.15 SHOW LOGS 다.

DESCRIBE 문은 SHOW COLUMNS와 같은 정보를 제공한다. 13.3.1, “DESCRIBE Syntax”장을 참조하라.

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.4. SHOW CREATE DATABASE
13. SQL 문법(SQL Statement Syntax) SHOW CREATE {DATABASE | SCHEMA} db_name
13.5.4 SHOW 주어진 데이터베이스를 생성하는 CREATE DATABASE 문을 보라. SHOW CREATE SCHEMA 는 MySQL 5.0.2에서
SHOW CREATE DATABASE 와 동일하다.
mysql> SHOW CREATE DATABASE test￦G
13.5.4.4 SHOW CREATE DATABASE *************************** 1. row ***************************
SHOW CREATE FUNCTION Database: test
13.5.4.7 SHOW CREATE VIEW Create Database: CREATE DATABASE `test`

/*!40100 DEFAULT CHARACTER SET latin1 */
mysql> SHOW CREATE SCHEMA test￦G
13.5.4.14 SHOW INNODB STATUS *************************** 1. row ***************************
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES Database: test

Create Database: CREATE DATABASE `test`

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST /*!40100 DEFAULT CHARACTER SET latin1 */

SHOW CREATE DATABASE 는 SQL_QUOTE_SHOW_CREATE 옵션 값에 따라 테이블과 컬럼 이름들을 인용한다.
13.5.3, “SET Syntax”장을 참조하라

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.5. SHOW CREATE PROCEDURE 와 SHOW CREATE FUNCTION
13. SQL 문법(SQL Statement Syntax) SHOW CREATE {PROCEDURE | FUNCTION} sp_name
13.5.4 SHOW 이 문은 MySQL 확장기능이다. SHOW CREATE TABLE과 비슷하다면, 그것은 명명된 루틴을 재 생성하기 위해 사용될 수 있는
정확한 스트링으로 리턴한다
mysql> SHOW CREATE FUNCTION test.hello￦G
SHOW CREATE FUNCTION Function: hello
13.5.4.7 SHOW CREATE VIEW sql_mode:

Create Function: CREATE FUNCTION `test`.`hello`(s CHAR(20)) RETURNS CHAR(50)
RETURN CONCAT('Hello, ',s,'!')
13.5.4.15 SHOW LOGS

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.6. SHOW CREATE TABLE
13. SQL 문법(SQL Statement Syntax) SHOW CREATE TABLE tbl_name

13.5.4 SHOW 주어진 테이블을 생성하는 CREATE TABLE 문을 보라. MySQL 5.0.1에서, 이 문은 뷰와 함께 작동한다.

mysql> SHOW CREATE TABLE t￦G
*************************** 1. row ***************************
13.5.4.5 SHOW CREATE PROCEDURE 와 Table: t
SHOW CREATE FUNCTION
13.5.4.6 SHOW CREATE TABLE Create Table: CREATE TABLE t (

13.5.4.8 SHOW DATABASES id INT(11) default NULL auto_increment,

s char(60) default NULL,
PRIMARY KEY (id)
13.5.4.13 SHOW INDEX ) ENGINE=MyISAM
13.5.4.15 SHOW LOGS
SHOW CREATE TABLE 는 SQL_QUOTE_SHOW_CREATE 옵션 값에 따라 테이블과 컬럼 이름들을 인용한다. 13.5.3,
“SET Syntax”장을 참조하라

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.7. SHOW CREATE VIEW
13. SQL 문법(SQL Statement Syntax) SHOW CREATE VIEW view_name

13.5.4 SHOW 이 문은 주어진 뷰를 생성하는 CREATE VIEW 문을 보여준다.

mysql> SHOW CREATE VIEW v;
+------+----------------------------------------------------+
13.5.4.5 SHOW CREATE PROCEDURE 와 | View | Create View |
13.5.4.6 SHOW CREATE TABLE +------+----------------------------------------------------+

13.5.4.8 SHOW DATABASES |v | CREATE VIEW `test`.`v` AS select 1 AS à`,2 AS `b` |

+------+----------------------------------------------------+
이 문은 MySQL 5.0.1에서 추가되었다.
13.5.4.15 SHOW LOGS MySQL 5.0.11이전에, 이 문의 출력 컬럼은 Table 과 Create Table로 나타났다.

VIEWS 테이블을 포함하고 있는INFORMATION_SCHEMA 로부터 뷰 오브젝트에 관한 정보를 얻을 수 있다. 20.15,

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST “INFORMATION_SCHEMA VIEWS 테이블”장을 참조하라.


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.8. SHOW DATABASES
13. SQL 문법(SQL Statement Syntax) SHOW {DATABASES | SCHEMAS} [LIKE 'pattern']
13.5.4 SHOW SHOW DATABASES 는 MySQL 서버 호스트에서 데이터베이스를 열거한다. SHOW SCHEMAS 는 MySQL 5.0.2에서
SHOW DATABASES 와 동일하다.
글로벌SHOW DATABASES 권한을 가지고 있지 않다면, 몇몇 권한을 가지고 있는 저런 데이터베이스만 볼 수 있다.
mysqlshow 명령을 사용하여 이 목록을 얻을 수 있다.
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW 서버가 --skip-show-database 옵션으로 시작되었다면, SHOW DATABASES권한을 가지지 않고서는 절대로 이 문을
CREATE FUNCTION
사용할 수 없다.
13.5.4.15 SHOW LOGS
13.5.4.18 SHOW PROCEDURE STATUS 과 SHOW
FUNCTION STATUS

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.9. SHOW ENGINE
13. SQL 문법(SQL Statement Syntax) SHOW ENGINE engine_name {LOGS | STATUS }
13.5.4 SHOW SHOW ENGINE은 로그와 스토리지 엔진에 관한 상태 정보를 보여준다. 다음 문이 현재 지원되고 있다.:

SHOW ENGINE BDB LOGS
SHOW ENGINE INNODB STATUS
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW SHOW ENGINE BDB LOGS 는 현재 BDB로그파일에 관한 상태 정보를 보여준다.그것은 다음 필드로 리턴한다:
CREATE FUNCTION
13.5.4.6 SHOW CREATE TABLE ● File

13.5.4.8 SHOW DATABASES 로그 파일로의 모든 경로.

● Type
로그파일 타입(버클리 DB 로그파일용 BDB).
13.5.4.13 SHOW INDEX ● Status
13.5.4.15 SHOW LOGS 로그파일 상태(파일을 이동할 수 없으면, FREE , 또는 트랜잭션 하부조직에의해 파일이 필요해지면, IN USE )

SHOW ENGINE INNODB STATUS 는 InnoDB 스토리지 엔진의 상태에 관한 더 많은 정보를 보여준다..
FUNCTION STATUS

:::MySQL Korea:::

InnoDB 모니터는 InnoDB 프로세싱에 관한 추가적인 정보를 제공한다. 14.2.11.1, “SHOW ENGINE INNODB
STATUS 와InnoDB 모니터”장을 참조하라
13.5.4.25 SHOW WARNINGS 이 문들에 있어 이전의 (지금은 반대인) 동의어들은 SHOW [BDB] LOGS 와 SHOW INNODB STATUS이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.10. SHOW ENGINES
13. SQL 문법(SQL Statement Syntax) SHOW [STORAGE] ENGINES

13.5.4 SHOW SHOW ENGINES 서버의 스토리지 엔진에 관한 상태 정보를 보여준다. 이것은 특별히 스토리지 엔진이 지원되는지 체크하고, 디
폴트 엔진이 무엇인지 보는데 사용된다. SHOW TABLE TYPES 는 반대되는 동의어이다.
mysql> SHOW ENGINES￦G
SHOW CREATE FUNCTION Engine: MyISAM
13.5.4.7 SHOW CREATE VIEW Support: DEFAULT

Comment: Default engine as of MySQL 3.23 with great performance
*************************** 2. row ***************************
Engine: MEMORY
13.5.4.14 SHOW INNODB STATUS Support: YES
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES Comment: Hash based, stored in memory, useful for temporary tables

*************************** 3. row ***************************

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST Engine: HEAP

Support: YES
Comment: Alias for MEMORY
13.5.4.24 SHOW VARIABLES *************************** 4. row ***************************
Engine: MERGE
Support: YES
Comment: Collection of identical MyISAM tables
*************************** 5. row ***************************
Engine: MRG_MYISAM
Support: YES
Comment: Alias for MERGE
*************************** 6. row ***************************
Engine: ISAM
Support: NO
Comment: Obsolete storage engine, now replaced by MyISAM
*************************** 7. row ***************************

:::MySQL Korea:::
Engine: MRG_ISAM
Support: NO
Comment: Obsolete storage engine, now replaced by MERGE
*************************** 8. row ***************************
Engine: InnoDB
Support: YES
Comment: Supports transactions, row-level locking, and foreign keys
*************************** 9. row ***************************
Engine: INNOBASE
Support: YES
Comment: Alias for INNODB
*************************** 10. row ***************************
Engine: BDB
Support: YES
Comment: Supports transactions and page-level locking
*************************** 11. row ***************************
Engine: BERKELEYDB

:::MySQL Korea:::
Support: YES
Comment: Alias for BDB
*************************** 12. row ***************************
Engine: NDBCLUSTER
Support: NO
Comment: Clustered, fault-tolerant, memory-based tables
*************************** 13. row ***************************
Engine: NDB
Support: NO
Comment: Alias for NDBCLUSTER
*************************** 14. row ***************************
Engine: EXAMPLE
Support: NO
Comment: Example storage engine
*************************** 15. row ***************************
Engine: ARCHIVE

:::MySQL Korea:::
Support: YES
Comment: Archive storage engine
*************************** 16. row ***************************
Engine: CSV
Support: NO
Comment: CSV storage engine
*************************** 17. row ***************************
Engine: FEDERATED
Support: YES
Comment: Federated MySQL storage engine
*************************** 18. row ***************************
Engine: BLACKHOLE
Support: YES
Comment: /dev/null storage engine (anything you write to it disappears)
Support 값은 특별한 스토리지 엔진이 지원되는지, 그리고 어떤 것이 디폴트 엔진인지 보여준다. 예를 들어, 만약 서버가 --
default-table-type=InnoDB 옵션으로 시작된다면, InnoDB로우의 Support 값은 DEFAULT 값을 갖는다. 4, 스토리지엔진과
테이블 타입. 장을 참조하라.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.11. SHOW ERRORS
13. SQL 문법(SQL Statement Syntax) SHOW ERRORS [LIMIT [offset,] row_count]
13.5.4 SHOW SHOW COUNT(*) ERRORS

이 문은 에러, 경고, 주의를 보여주는 대신에, 에러만을 보여준다는 것을 제외하고 SHOW WARNINGS와 비슷하다.
LIMIT 절은 SELECT문과 같은 신텍스를 갖는다. 13.2.7, “SELECT ”장을 참조하라.
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW SHOW COUNT(*) ERRORS 문은 에러의 숫자를 보여준다. error_count 변수로부터 에러의 갯수를 검색할 수 있
CREATE FUNCTION 다.:
13.5.4.7 SHOW CREATE VIEW SHOW COUNT(*) ERRORS;

SELECT @@error_count;
더 자세한 정보는 13.5.4.25, “SHOW WARNINGS ”장을 참조하라.
13.5.4.15 SHOW LOGS
FUNCTION STATUS

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.12. SHOW GRANTS
13. SQL 문법(SQL Statement Syntax) SHOW GRANTS FOR user

13.5.4 SHOW 이 문은 GRANT문 또는 MySQL 사용자 계정에 주어진 권한을 복사하기 위해 비롯된 문을 열거한다. 계정은 GRANT문과 같은 포
맷으로 명명된다; 예를들어, 'jeffrey'@'localhost'. 사용자와 계정이름의 호스트 부분은 User와 계정의 user 테이블 로우의 Host 컬
럼 값에 상응한다.
mysql> SHOW GRANTS FOR 'root'@'localhost';
13.5.4.5 SHOW CREATE PROCEDURE 와 +---------------------------------------------------------------------+
13.5.4.6 SHOW CREATE TABLE | Grants for root@localhost |

13.5.4.8 SHOW DATABASES +---------------------------------------------------------------------+

| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+
13.5.4.13 SHOW INDEX 서버에 연결하여 사용하는 계정에 주어진 권한을 열거하기 위해서, 다음의 문을 사용할 수 있다:
13.5.4.15 SHOW LOGS SHOW GRANTS;

13.5.4.17 SHOW PRIVILEGES SHOW GRANTS FOR CURRENT_USER;

SHOW FUNCTION STATUS SHOW GRANTS FOR CURRENT_USER();

:::MySQL Korea:::

SHOW GRANTS 는 명명된 계정에 명확히 주어진 권한만을 보여준다. 다른 권한들은 계정에서 이용할 수 있다. 그러나 그것들은 보
여주지 않는다. 예를 들어 익명의 계정이 존재한다면, 명명된 계정은 이 권한을 사용할 수 있지만 SHOW GRANTS는 그것을 보여주
지 않을 것이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.13. SHOW INDEX
13. SQL 문법(SQL Statement Syntax) SHOW INDEX FROM tbl_name [FROM db_name]
13.5.4 SHOW SHOW INDEX 는 테이블 인덱스 정보를 리턴한다. 포맷은 ODBD SQLStatistics 라 불리는 것과 비슷하다.

SHOW INDEX 는 다음 필드로 리턴한다:
● Table
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW 테이블 이름.
CREATE FUNCTION
13.5.4.6 SHOW CREATE TABLE ● Non_unique

13.5.4.8 SHOW DATABASES 인덱스가 중복될 수 없으면 0. 중복될 수 있으면 1.

● Key_name
인덱스 이름.
13.5.4.13 SHOW INDEX ● Seq_in_index
13.5.4.15 SHOW LOGS 1로 시작하는 인텍스의 컬럼 시퀀스 넘버

● Column_name
컬럼 이름.
FUNCTION STATUS

:::MySQL Korea:::

● Collation
13.5.4.21 SHOW TABLE STATUS 컬럼이 인덱스에서 정렬되는 방법. MySQL에서 이것은 ‘A’(오름차순) 또는 NULL(정렬되지 않은)값을 을
13.5.4.22 SHOW TABLES 가질 수 있다.
13.5.4.24 SHOW VARIABLES ● Cardinality

인덱스에서 유일한 값까지의 어림. 이것은 ANALYZE TABLE 이나 myisamchk -a를 실행하면 업데이트된
다. Cardinality 는 정수로 저장된 통계를 기준으로 계산되어, 값이 작은 테이블과 완전히 같을 필요는 없다. 카디
낼러티(Cardinality)가 높을수록, 조인(join)했을 때 MySQL을 사용할 기회가 많아진다.
● Sub_part
컬럼이 부분적으로 인덱스되어 있다면, 인덱스된 캐릭터의 숫자. 모든 컬럼이 인덱스되어 있다면, NULL
● Packed
키가 압축되어 있는 방법을 나타냄. 그렇지 않다면, NULL.
● Null
컬럼이 NULL을 포함하고 있으면 YES. 그렇지 않으면, MySQL 5.0.3과 그 이전버전에서 컬럼은 NO를 포함하
고 있다.
● Index_type
사용된 인덱스 방법(BTREE, FULLTEXT, HASH, RTREE).
● Comment
다양한 주의사항.

:::MySQL Korea:::
db_name.tbl_name 와 tbl_name FROM db_name 신텍스를 선택하여 사용할 수 있다. 이 두 문은 동일하다.:
SHOW INDEX FROM mytable FROM mydb;
SHOW INDEX FROM mydb.mytable;
SHOW KEYS 는SHOW INDEX와 같다. mysqlshow -k db_name tbl_name 명령으로 테이블의 인덱스를 열거할 수 있
다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.14. SHOW INNODB STATUS
13. SQL 문법(SQL Statement Syntax) SHOW INNODB STATUS

13.5.4 SHOW MySQL 5.0에서, 이것은 SHOW ENGINE INNODB STATUS에 대한 비추천 동의어이다. 13.5.4.9,
“SHOW ENGINE ”장을 참조하라..
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW CREATE
FUNCTION

13.5.4.15 SHOW LOGS
13.5.4.18 SHOW PROCEDURE STATUS 과 SHOW FUNCTION
STATUS

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.15. SHOW LOGS
13. SQL 문법(SQL Statement Syntax) SHOW [BDB] LOGS

13.5.4 SHOW MySQL 5.0에서, 이것은 SHOW ENGINE BDB LOGS에 대한 비추천 동의어이다. 13.5.4.9,
“SHOW ENGINE ”장을 참조하라..
13.5.4.15 SHOW LOGS

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.16. SHOW OPEN TABLES
13. SQL 문법(SQL Statement Syntax) SHOW OPEN TABLES [FROM db_name] [LIKE 'pattern']
13.5.4 SHOW SHOW OPEN TABLES 은 테이블 캐쉬(Cache)에 현재 오픈되어 있는 non-TEMPORARY 테이블을 열거한다. 7.4.8,
“MySQL은 테이블을 어떻게 열고 닫는가 ”장을 참조하라.
SHOW OPEN TABLES 은 다음 필드를 리턴한다:
13.5.4.4 SHOW CREATE DATABASE ● Database
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW
CREATE FUNCTION 테이블을 포함한 데이터베이스.
13.5.4.7 SHOW CREATE VIEW ● Table

테이블 이름.
● In_use
테이블이 현재 쿼리로 사용중인 횟수. 횟수가 0이라면, 테이블은 오픈되지만, 그렇지 않다면 현재 사용 중이다.
13.5.4.14 SHOW INNODB STATUS ● Name_locked
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES 테이블 이름이 잠겨있는지 여부. 이름잠금은 테이블 드롭이나 이름 재설정과 같은 실행에 사용된다.

FUNCTION STATUS

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST FROM 과 LIKE 절은MySQL 5.0.12.에서 사용된다.


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.17. SHOW PRIVILEGES
13. SQL 문법(SQL Statement Syntax) SHOW PRIVILEGES

13.5.4 SHOW SHOW PRIVILEGES 는 MySQl 서버가 지원하는 시스템 권한 리스트를 보여준다. 정확한 권한 리스트는 서버 버전에 따라 다
르다.
mysql> SHOW PRIVILEGES￦G
SHOW CREATE FUNCTION Privilege: Alter
13.5.4.7 SHOW CREATE VIEW Context: Tables

Comment: To alter the table
*************************** 2. row ***************************
Privilege: Alter routine
13.5.4.14 SHOW INNODB STATUS Context: Functions,Procedures
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES Comment: To alter or drop stored functions/procedures

*************************** 3. row ***************************

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST Privilege: Create

Context: Databases,Tables,Indexes
Comment: To create new databases and tables
13.5.4.24 SHOW VARIABLES *************************** 4. row ***************************
Privilege: Create routine
Context: Functions,Procedures
Comment: To use CREATE FUNCTION/PROCEDURE
*************************** 5. row ***************************
Privilege: Create temporary tables
Context: Databases
Comment: To use CREATE TEMPORARY TABLE
...

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.18. SHOW PROCEDURE STATUS 과 SHOW FUNCTION STATUS
13. SQL 문법(SQL Statement Syntax) SHOW {PROCEDURE | FUNCTION} STATUS [LIKE 'pattern']
13.5.4 SHOW 이 문은 MySQL 확장이다. 데이터베이스, 이름 , 타입, 생성자, 생성, 날짜변경 등과 같은 루틴들의 특성을 리턴한다. 패턴이 지
정되지 않았다면, 저장된 모든 프로시져 또는 기능에 관한 정보는 사용하는 문에 따라 열거된다.
mysql> SHOW FUNCTION STATUS LIKE 'hello'￦G
SHOW CREATE FUNCTION Db: test
13.5.4.7 SHOW CREATE VIEW Name: hello

Type: FUNCTION
Definer: testuser@localhost
Modified: 2004-08-03 15:29:37
13.5.4.14 SHOW INNODB STATUS Created: 2004-08-03 15:29:37
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES Security_type: DEFINER

Comment:

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST INFORMATION_SCHEMA에서ROUTINES 테이블로부터 저장된 루틴에 관한 정보를 얻을 수 있다. 20.14,
13.5.4.20 SHOW STATUS “INFORMATION_SCHEMA ROUTINES 테이블”장을 참조하라.


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.19. SHOW PROCESSLIST
13. SQL 문법(SQL Statement Syntax) SHOW [FULL] PROCESSLIST

13.5.4 SHOW SHOW PROCESSLIST 는 어떤 스레드가 작동하는지 보여준다. mysqladmin processlist 명령을 사용하는 정보를 얻을 수 있다.
SUPER 권한을 가졌다면, 모든 스레드를 볼 수 있다. 그렇지 않으면, 오로지 자신의 스레드만 볼 수 있다.(즉, 사용 중인 MySQL
계정과 연계된 스레드). 13.5.5.3, “KILL ”장을 참조하라. FULL 키워드를 사용하지 않는다면, 각 문의 처음 100개 문자만 Info
필드에 보인다.
“too many connections” 에러 메시지를 받아, 실행중인 것을 찾으려고 할 때, 이 문은 매우 유용하다. MySQL은 관리자가 항
13.5.4.6 SHOW CREATE TABLE 상 시스템에 접속해 점검할 수 있도록 SUPER권한을 가지는 계정에 의해 사용되는 하나의 별도 커넥션을 남겨둔다(이 권한을 모
13.5.4.7 SHOW CREATE VIEW 든 사용자에게 주지 않는다고 가정한다면).
13.5.4.9 SHOW ENGINE SHOW PROCESSLIST 의 아웃풋은 다음과 같다:

mysql> SHOW FULL PROCESSLIST￦G
*************************** 1. row ***************************
13.5.4.14 SHOW INNODB STATUS Id: 1
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES User: system user

13.5.4.18 SHOW PROCEDURE STATUS 과 Host:

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST db: NULL

Command: Connect
Time: 1030455
13.5.4.24 SHOW VARIABLES State: Waiting for master to send event
Info: NULL
*************************** 2. row ***************************
Id: 2
User: system user
Host:
db: NULL
Command: Connect
Time: 1004
State: Has read all relay log; waiting for the slave I/O thread to update it
Info: NULL
*************************** 3. row ***************************
Id: 3112

:::MySQL Korea:::
User: replikator
Host: artemis:2204
db: NULL
Time: 2144
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
*************************** 4. row ***************************
Id: 3113
User: replikator
Host: iconnect2:45781
db: NULL
Time: 2086
State: Has sent all binlog to slave; waiting for binlog to be updated
Info: NULL
*************************** 5. row ***************************

:::MySQL Korea:::
Id: 3123
User: stefan
Host: localhost
db: apollon
Command: Query
Time: 0
State: NULL
Info: SHOW FULL PROCESSLIST
컬럼은 다음과 같은 의미를 가진다:
● Id
접속 식별자.
● User
이 문을 사용하는 MySQL 사용자. 사용자가 system user라면, 내부적으로업무를 조정하기 위해 서버에 의해 파생된
non-클라이언트 스레드에 적용된다. 이것은 슬레이브 리플리케이션 또는 지연-로우 조절에 사용되는 I/O 또는 SQL 스
레드일 수 있다. system user의 경우, Host 컬럼에 정해진 호스트는 없다.
● Host

:::MySQL Korea:::
문을 사용중인 클라이언트의 호스트이름(호스트가 없는 system user 용 제외). SHOW PROCESSLIST 는 어떤 클라이

언트가 무슨 작업을 할지 결정을 더 쉽게 하기 위해 host_name:client_port 포맷에서 TCP/IP 연결용 호스트이름을 리포
트한다.
● db
만약 하나가 선택되면 디폴트 데이터베이스. 그렇지 않으면 NULL.
● Command
컬럼 값은 클라이언트/서버 프로토콜의 COM_xxx 명령에 상응한다. 5.2.4, “서버 상태 변수” 장을 참조하라.

Command 값은 다음 중 하나가 된다: Binlog Dump, Change user, Close stmt, Connect, Connect Out, Create DB,
Debug, Delayed insert, Drop DB, Error, Execute, Fetch, Field List, Init DB, Kill, Long Data, Ping, Prepare,
Processlist, Query, Quit, Refresh, Register Slave, Reset stmt, Set option, Shutdown, Sleep, Statistics, Table
Dump, Time
● Time
문이나 명령의 시작과 지금까지의 시간.
● State
다음 중 하나가 될 수 있는 실행, 경우, 상태: After create, Analyzing, Changing master, Checking master version,
Checking table, Connecting to master, Copying to group table, Copying to tmp table, Creating delayed handler,
Creating index, Creating sort index, Creating table from master dump, Creating tmp table, Execution of
init_command, FULLTEXT initialization, Finished reading one binlog; switching to next binlog, Flushing tables,
Killed, Killing slave, Locked, Making temp file , Opening master dump table, Opening table, Opening tables,
Processing request, Purging old relay logs, Queueing master event to the relay log, Reading event from the
relay log, Reading from net, Reading master dump table data, Rebuilding the index on master dump table,
Reconnecting after a failed binlog dump request, Reconnecting after a failed master event read, Registering
slave on master, Removing duplicates, Reopen tables, Repair by sorting, Repair done, Repair with keycache,

:::MySQL Korea:::
Requesting binlog dump, Rolling back, Saving state, Searching rows for update, Sending binlog event to slave,
Sending data, Sorting for group, Sorting for order, Sorting index, Sorting result, System lock, Table lock,
Thread initialized, Updating, User lock, Waiting for INSERT, Waiting for master to send event, Waiting for
master update, Waiting for slave mutex on exit, Waiting for table, Waiting for tables, Waiting for the next
event in relay log, Waiting on cond, Waiting to finalize termination, Waiting to reconnect after a failed binlog
dump request, Waiting to reconnect after a failed master event read, Writing to net, allocating local table,
cleaning up, closing tables, converting HEAP to MyISAM, copy to tmp table, creating table, deleting from main
table, deleting from reference tables, discard_or_import_tablespace, end, freeing items, got handler lock, got
old table, info, init, insert, logging slow query, login, preparing, purging old relay logs, query end, removing
tmp table, rename, rename result table, reschedule, setup, starting slave, statistics, storing row into queue,
unauthenticated user, update, updating, updating main table, updating reference tables, upgrading lock, waiting
for delay_list, waiting for handler insert, waiting for handler lock, waiting for handler open
가장 일반적인 State 값은 이 장의 다른 곳에 서술되어 있다. 다른 State값은 대부분 서버에서 버그를 찾는 데에만 유용하
다. 리플리케이션 서버를 위한 프로세스 상태에 관한 추가적인 정보는 6.3, “Replication Implementation Details”장
을 참조하라.
SHOW PROCESSLIST 문의 경우, State 값은 NULL이다.
● Info
스레드를 실행하는 문, 또는 어떤 문을 실행하지 않는다면 NULL
SHOW PROCESSLIST의 출력에 일반적으로 보이는 몇몇 State 값:
● Checking table
스레드는 테이블 체크 오퍼레이션을 실행중이다.
● Closing tables
스레드가 변경된 테이블 데이터를 디스크로 쏟아내고 사용된 테이블을 닫는 것을 의미한다. 이것은 빠른 오퍼레이션이다.
만약 그렇지 않다면, 풀(full) 디스크를 가지고 있지 않은지 그리고 디스크가 너무 과중하게 사용되지는 않는지 체크해야

:::MySQL Korea:::
한다.
● Connect Out
리플리케이션 슬레이브는 그것의 마스터와 연결되어 있다.
● Copying to tmp table
서버는 메모리에 있는 임시 테이블로 복사한다.
● Copying to tmp table on disk
서버가 디스크에 있는 임시 테이블로 복사한다. 임시 결과 세트는 tmp_table_size 보다 크고, 스레드는 메모리를 절약하
기 위해서 인-메모리에서 디스크 기반 포맷으로 임시 테이블을 변경시킨다.
● Creating tmp table
스레드는 쿼리의 결과 일부를 기억장치에 남겨두기 위해 임시 테이블을 생성한다.
● deleting from main table
서버는 복합테이블 삭제의 첫 번째 부분을 실행한다. 그것은 반드시 첫 번째 테이블부터 삭제하고, 다른 (레퍼런스) 테이
블로부터 삭제를 실행할 필드와 오프셋을 절약한다.
● deleting from reference tables
서버는 복합-테이블 삭제의 두 번째 부분을 실행하며, 다른 테이블로부터매치된 로우를 삭제한다
● Flushing tables
스레드는 FLUSH TABLES 를 실행하고 그 테이블을 종료하기 위해서 모든 스레드를 기다린다.
● FULLTEXT initialization

:::MySQL Korea:::
서버는 자연 언어처리 전문 검색을 준비한다.
● Killed
누군가 KILL 문을 스레드에 보내면 kill 플래그를 체크하여 다음에 중단해야 한다. 플래그는 MySQL의 각각의 메이저 루
프에서 점검된다. 그러나 몇몇의 경우, 스레드가 멈추는데 짧은 시간이 걸리곤 한다. 만약 스레드가 몇몇 다른 스레드에 의
해 잠겨있다면, kill은 다른 스레드가 잠금을 해제하자마자 효력을 나타낸다.
● Locked
쿼리는 다른 쿼리에 의해 잠긴다.
● Sending data
스레드는 SELECT문으로 로우를 프로세싱하며 데이터를 클라이언트로 보낸다.
● Sorting for group
스레드는 GROUP BY 를 만족시키도록 정렬된다.
● Sorting for order
스레드는 ORDER BY 를 만족시키도록 정렬된다.
● Opening tables
스레드는 테이블을 열려고 한다. 무언가 오픈을 방해하지 않는다면, 이것은 매우 빠른 프로시져이다. 예를 들어, ALTER
TABLE 또는 LOCK TABLE 문은 문이 끝날 때까지 테이블 오픈을 방해할 수 있다.
● Reading from net

:::MySQL Korea:::
서버는 네트워크로부터 패킷을 읽는다.
● Removing duplicates
초기단계에서 개별 오퍼레이션을 최적화 할 수 없는 것과 같은 그런 방법에서 쿼리는 SELECT DISTINCT를 사용하고

있다. 이런 이유로 결과를 클라이언트에게 전달하기 전에 모든 중복된 로우를 제거하기 위해서 MySQL은 별도의 단계가
필요하다.
● Reopen table
스레드는 테이블을 잠갔다. 그러나 잠근 이후에 뒤에 숨은 테이블 구성이 변경되었다는 것을 인지한다. 잠금을 해제하고
테이블을 종료하며 그것을 다시 오픈하려 한다.
● Repair by sorting
복구 코드는 인덱스를 생성하기 위해 사용된다.
● Repair with keycache
복구 코드는 키 캐쉬 메모리를 통해 하나씩 키를 생성하는데 사용한다. 이것은 Repair by sorting 보다 훨씬 느리다.
● Searching rows for update
스레드는 로우를 업데이트 하기 전에 모든 부합하는 로우를 찾기 위해 첫번째 단계를 행한다. 만약 UPDATE가 관련된 로
우를 찾는데 사용된 인덱스를 변경시킨다면, 이것을 실행해야 한다.
● Sleeping
새로운 문을 보내기 위해서 스레드는 클라이언트를 기다린다.
● statistics

:::MySQL Korea:::
서버는 쿼리 실행 플랜을 발전시키기 위해 통계를 계산한다.
● System lock
스레드는 테이블의 외부 시스템 잠금을 기다린다. 같은 테이블에 액세스하는복합 mysqld 서버를 사용하지 않는다면, --
skip-external-locking 옵션을 이용해 시스템 잠금 기능을 억제할 수 있다.
● unauthenticated user
클라이언트 커넥션과 결합되었으나 클라이언트 유저의 인증을 아직 받지 못한 스레드의 상태
● Upgrading lock
INSERT DELAYED 핸들러는 로우를 삽입하기 위해 테이블을 잠그려고 한다.
● Updating
스레드는 업데이트할 로우를 찾아 업데이트 한다.
● updating main table
서버는 복합-테이블 업데이트의 첫 번째 부분을 실행한다. 그것은 오로지첫번째 테이블만 업데이트 하며, 다른 (레퍼런
스) 테이블을 업데이트하는데 사용될 필드와 오프셋을 절약한다.
● updating reference tables
서버는 복합-테이블 업데이트의 두 번째 부분을 실행하고, 다른 테이블로부터 부합하는 로우를 업데이트 한다.
● User Lock
스레드는 GET_LOCK()을 기다린다.

:::MySQL Korea:::
● Waiting for tables
스레드는 테이블의 기초가 되는 체계가 변경되었다는 통보를 받았고, 새로운체계를 만들기 위해 테이블을 다시 오픈할 필
요가 있다. 그러나 테이블을 다시 열기 위해서, 모든 다른 스레드가 본 건에 대해 테이블을 종료할 때까지 기다려야 한다.
다른 스레드가 FLUSH TABLES를 사용하거나 또는 다음 문들 중 하나를 테이블에서 사용하면, 이런 경고가 발생한다.:

FLUSH TABLES tbl_name, ALTER TABLE, RENAME TABLE, REPAIR TABLE, ANALYZE TABLE, 또는
OPTIMIZE TABLE.
● waiting for handler insert
INSERT DELAYED 핸들러는 모든 팬딩된 삽입을 실행하고 새로운 것을기다린다.
● Writing to net
서버는 네트워크에 패킷을 쓴다.
대부분은 상태는 빠른 실행에 부합한다. 만약 한 스레드가 이런 상태로 오래 대기 중이라면, 조사할 필요가 있는 문제가 있을 수 있
다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.20. SHOW STATUS
13. SQL 문법(SQL Statement Syntax) SHOW [GLOBAL | SESSION] STATUS [LIKE 'pattern']
13.5.4 SHOW SHOW STATUS 는 서버 상태에 관한 정보를 제공한다. 이 정보로 mysqladmin extended-status 명령을 사용할 수 있다.

13.5.4.3 SHOW COLUMNS 부분적인 아웃풋은 여기에서 볼 수 있다. 이름과 값의 리스트는 사용자의 서버와 다를 수 있다. 각 변수의 의미는 5.2.4, “서버 상
13.5.4.4 SHOW CREATE DATABASE 태 변수”장을 참조하라.
SHOW CREATE FUNCTION mysql> SHOW STATUS;
13.5.4.7 SHOW CREATE VIEW +--------------------------+------------+

+--------------------------+------------+
13.5.4.12 SHOW GRANTS | Aborted_clients |0 |
13.5.4.14 SHOW INNODB STATUS | Aborted_connects |0 |
13.5.4.15 SHOW LOGS

13.5.4.16 SHOW OPEN TABLES | Bytes_received | 155372598 |

| Bytes_sent | 1176560426 |

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST | Connections | 30023 |

| Created_tmp_disk_tables | 0 |
| Created_tmp_tables | 8340 |
13.5.4.24 SHOW VARIABLES | Created_tmp_files | 60 |
...
| Open_tables |1 |
| Open_files |2 |
| Open_streams |0 |
| Opened_tables | 44600 |
| Questions | 2026873 |
...
| Table_locks_immediate | 1920382 |
| Table_locks_waited |0 |
| Threads_cached |0 |
| Threads_created | 30022 |
| Threads_connected |1 |

:::MySQL Korea:::
| Threads_running |1 |
| Uptime | 80380 |
+--------------------------+------------+
LIKE 절과 함께, 문은 오직 패턴에 상응하는 변수 만을 보여준다:
mysql> SHOW STATUS LIKE 'Key%';
+--------------------+----------+
+--------------------+----------+
| Key_blocks_used | 14955 |
| Key_read_requests | 96854827 |
| Key_reads | 162040 |
| Key_write_requests | 7589728 |
| Key_writes | 3813196 |
+--------------------+----------+
GLOBAL 과 SESSION 옵션은 MySQL 5.0.2에서 새로워졌다. GLOBAL 변경자로 , SHOW STATU는 MySQL에 연결된 모든
것의 상태 값을 보여준다. SESSION으로. 현재 연결의 상태 값을 보여준다. 만약 현재 변경자가 없다면, SESSION 이 디폴트이
다. LOCAL은 SESSION의 동의어이다.

:::MySQL Korea:::
몇몇 상태 변수는 하나의 글로벌 값을 가진다. 이런 경우, GLOBAL과 SESSION이 같은 값을 갖는다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.21. SHOW TABLE STATUS
13. SQL 문법(SQL Statement Syntax) SHOW TABLE STATUS [FROM db_name] [LIKE 'pattern']
13.5.4 SHOW SHOW TABLE STATUS 는SHOW TABLE와 같이 작동하지만, 각 테이블에 대한 많은 정보를 제공한다. mysqlshow --
status db_name 명령을 사용하는 이 리스트를 얻을 수 있다.
MySQL 5.0.1에서, 이 문은 뷰의 정보를 보여준다.
13.5.4.4 SHOW CREATE DATABASE SHOW TABLE STATUS 는 다음 필드를 리턴한다:
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW
CREATE FUNCTION ● Name
13.5.4.7 SHOW CREATE VIEW 테이블 이름

● Engine
테이블의 스토리지 엔진. "14. 스토리지 엔진과 테이블 타입"장을 참조하라.
● Version
13.5.4.14 SHOW INNODB STATUS 테이블의 .frm 파일의 버전 수.
13.5.4.15 SHOW LOGS
13.5.4.16 SHOW OPEN TABLES ● Row_format

로우 스토리지 포맷(Fixed, Dynamic, Compressed, Redundant, Compact). MySQL/InnoDB 5.0.3부터 InnoDB
SHOW FUNCTION STATUS 테이블의 포맷은 Redundant 또는 Compact 형식으로 보고된다. 5.0.3이전 버전에서 InnoDB 테이블은 항상

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST Redundant 포맷에 있었다.

● Rows
로우의 수. MyISAM과 같은 몇몇 스토리지 엔진은 정확한 값을 저장한다. InnoDB와 같은 다른 스토리지 엔진의 경
우, 이 값은 근사값이며, 실제 값과는 40~50% 이상 차이가 있다. 그런 경우, 정확한 값을 얻기 위해서 SELECT
COUNT(*)를 사용한다.
13.5.4.25 SHOW WARNINGS INFORMATION_SCHEMA 데이터 베이스에 있는 테이블에서 Rows 값은 NULL 이다.
● Avg_row_length
평균 로우 길이.
● Data_length
데이터 파일의 길이.
● Max_data_length
데이터 파일의 최대 길이. 이것은 테이블에 저장된 데이터의 바이트 총수이다.
● Index_length
인덱스 파일의 길이.
● Data_free
할당되었으나 사용되지 않은 바이트 수.
● Auto_increment
그 다음 AUTO_INCREMENT 값.

:::MySQL Korea:::
● Create_time
테이블이 생성되었을 때.
● Update_time
데이터 파일이 마지막으로 업데이트된 때. 몇몇 스토리지 엔진의 경우, 이 값은 NULL이다. 예를 들어, InnoDB는 테
이블스페이스에 있는 복합 테이블을 저장하고 데이터 파일 타임스탬프는 적용되지 않는다.
● Check_time
테이블이 마지막으로 체크된 때. 모든 스토리지 엔진이 이 시간에 업데이트되는 것은 아니다. 이런 경우 값은 항상

NULL이다.
● Collation
테이블의 캐릭터 셋과 정렬.
● Checksum
유요한 검사 합계 값.
● Create_options
CREATE TABLE 을 사용한 별도 옵션.
● Comment
테이블을 생성할 때 사용하는 코멘트(또는 MySQL이 테이블 정보에 엑세스할 수 없는 이유에 관한 정보)

:::MySQL Korea:::
테이블 코멘트에서, InnoDB 테이블은 테이블이 속한 테이블스페이스의 여유 공간을 보고한다. 공유 테이블스페이스에 위치

한 테이블의 경우, 이것은 공유 테이블스페이스의 여유 공간이다. 만약 복합 테이블스페이스를 사용하고, 테이블에 고유의 테
이블스페이스가 있다면, 여유 공간은 그 테이블만을 위한 것이다.
MEMORY 테이블의 경우, Data_length, Max_data_length, Index_length 값은 할당된 메모리의 실제 합계에 근접한다. 할당
알고리즘은 할당 연산 수를 줄이기 위해 다량으로 메모리를 확보한다.
MySQL 5.0.3부터, NDB Cluster 테이블의 경우, 이 문의 아웃풋은 BLOB 컬럼이 고려되었다는 것을 제외하고는
Avg_row_length 와 Data_length 컬럼에 적당한 값을 보여준다. 덧붙여, 복제 수는 이제 Comment 컬럼에서 볼 수 있다.
(number_of_replicas로써)
뷰의 경우, Name이 뷰 이름을 나타내고, Comment가 view를 말한다는 것을 제외하고 SHOW TABLE STATUS 에 의해 보
여지는 모든 필드는 NULL이다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.22. SHOW TABLES
13. SQL 문법(SQL Statement Syntax) SHOW [FULL] TABLES [FROM db_name] [LIKE 'pattern']
13.5.4 SHOW SHOW TABLES는 주어진 데이터베이스에 non-TEMPORARY 테이블을 기록한다. mysqlshow db_name 명령어를 사용해
서 이 리스트를 얻을 수 있다.
13.5.4.4 SHOW CREATE DATABASE MySQL 5.0.1 이전에는, SHOW TABLES의 아웃풋은 테이블 이름의 싱글 컬럼을 포함한다. MySQL 5.0.1부터, 이 문은 데
13.5.4.5 SHOW CREATE PROCEDURE 와 SHOW 이터베이스에 어떤 뷰들을 기록한다. MySQL 5.0.2에서 SHOW FULL TABLES가 두번째 아웃풋 컬럼을 보여주듯이 FULL
CREATE FUNCTION
조정자가 지원된다. 두 번째 컬럼 값은 테이블의 경우 BASE TABLE이고, 뷰의 경우 VIEW이다.
주의: 테이블에 대한 권한이 없다면, 테이블은 SHOW TABLES 또는 mysqlshow db_name 의 아웃풋을 보여주지 않는다.
13.5.4.15 SHOW LOGS

:::MySQL Korea:::


:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.23. SHOW TRIGGERS
13. SQL 문법(SQL Statement Syntax) SHOW TRIGGERS [FROM db_name] [LIKE expr]
13.5.4 SHOW SHOW TRIGGERS는 현재 MySQL 서버에 한정된 트리거를 기록한다. 이 문은 SUPER 권한을 요구한다. 이것은 MySQL
5.0.10에서 실행된다.
13.5.4.4 SHOW CREATE DATABASE 18.3.”트리거 사용” 장에 정의된 ins_sum 트리거의 경우, 이 문의 아웃풋은 아래와 같이 보여준다:
SHOW CREATE FUNCTION mysql> SHOW TRIGGERS LIKE 'acc%'￦G
13.5.4.7 SHOW CREATE VIEW *************************** 1. row ***************************

Trigger: ins_sum
Event: INSERT
13.5.4.12 SHOW GRANTS Table: account
13.5.4.14 SHOW INNODB STATUS Statement: SET @sum = @sum + NEW.amount
13.5.4.15 SHOW LOGS

13.5.4.16 SHOW OPEN TABLES Timing: BEFORE

Created: NULL

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST sql_mode:

Definer: myname@localhost
주의: SHOW TRIGGERS와 함께LIKE 절을 사용할 때, (expr) 부합하는 표현은 트리거에 공표된 테이블 이름과 비교된다. 그
러나 트리거의 이름과는 비교되지 않는다.:
13.5.4.25 SHOW WARNINGS mysql> SHOW TRIGGERS LIKE 'ins%';
이 문의 아웃풋에서 컬럼에 대한 간단한 설명은 다음과 같다:
● Trigger
트리거 이름.
● Event
트리거 활성화를 야기시키는 이벤트. 'INSERT', 'UPDATE', 또는 'DELETE' 중 하나.
● Table
트리거가 정의된 테이블.
● Statement
트리거가 활성화될 때 실행되는 문. 이것은 INFORMATION_SCHEMA.TRIGGERS 의 ACTION_STATEMENT 컬

럼에서 보여지는 텍스트와 같다.
● Timing

:::MySQL Korea:::
'BEFORE' 또는 'AFTER' 두 값 중 하나
● Created
현재, 이 컬럼값은 항상 NULL이다.
● sql_mode
사실상 트리거가 실행할 때 SQL 모드. 이 컬럼은 MySQL 5.0.11에 추가되었다.
● Definer
트리거를 생성하는 계정. 이 컬럼은 MySQL 5.0.17에 추가되었다.
SHOW TRIGGER를 실행하려면 SUPER 권한을 가지고 있어야 한다.
20.16, “INFORMATION_SCHEMA TRIGGERS 테이블”장을 참조하라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.24. SHOW VARIABLES
13. SQL 문법(SQL Statement Syntax) SHOW [GLOBAL | SESSION] VARIABLES [LIKE 'pattern']
13.5.4 SHOW SHOW VARIABLES MySQL 시스템 변수 값을 보여준다. mysqladmin variables 명령문을 사용하여 이 정보를 얻을 수 있다.

13.5.4.3 SHOW COLUMNS GLOBAL 변경자로, SHOW VARIABLES는 MySQL의 새로운 커넥션에 사용되는 값을 보여준다. SESSION으로, 실제로 현재 연결되
13.5.4.4 SHOW CREATE DATABASE 어 있는 값을 보여준다. 만약 변경자가 현재 없다면, SESSION이 디폴트이다. LOCAL은 SESSION과 동의어이다.
13.5.4.5 SHOW CREATE PROCEDURE
와 SHOW CREATE FUNCTION

13.5.4.7 SHOW CREATE VIEW 디폴트 시스템 변수 값이 적당하지 않다면, mysqld 가 시작할 때, 명령어 옵션을 사용하여 셋팅할 수 있고, 대부분은 SET 문으로 실행
13.5.4.8 SHOW DATABASES 시간에 변경된다. 5.2.3, “시스템 변수 사용” 장과13.5.3, “SET 신텍스”장을 참조하라.

부분적인 아웃풋은 아래와 같다. 이름과 값의 리스트는 서버와 다를 수 있다. 5.2.2, “서버 시스템 변수”장에 각 변수의 의미에 대해 기
13.5.4.12 SHOW GRANTS 술했으며, 7.5.2, “튜닝 서버 파라미터”장은 튜닝에 대한 정보를 제공한다.
13.5.4.14 SHOW INNODB STATUS mysql> SHOW VARIABLES;
13.5.4.15 SHOW LOGS

13.5.4.16 SHOW OPEN TABLES +---------------------------------+-------------------------------------+

13.5.4.18 SHOW PROCEDURE STATUS
과 SHOW FUNCTION STATUS

:::MySQL Korea:::
13.5.4.19 SHOW PROCESSLIST +---------------------------------+-------------------------------------+

| auto_increment_increment |1 |
| auto_increment_offset |1 |
13.5.4.24 SHOW VARIABLES | automatic_sp_privileges | ON |
| back_log | 50 |
| basedir |/ |
| bdb_cache_size | 8388600 |
| bdb_home | /var/lib/mysql/ |
| bdb_log_buffer_size | 32768 |
...
| max_connections | 100 |
| max_connect_errors | 10 |
| max_delayed_threads | 20 |
| max_error_count | 64 |
| max_heap_table_size | 16777216 |
| max_join_size | 4294967295 |

:::MySQL Korea:::
| max_relay_log_size |0 |
| max_sort_length | 1024 |
...
| time_zone | SYSTEM |
| timed_mutexes | OFF |
| tmp_table_size | 33554432 |
| tmpdir | |
| transaction_alloc_block_size | 8192 |
| transaction_prealloc_size | 4096 |
| tx_isolation | REPEATABLE-READ |
| updatable_views_with_limit | YES |
| version | 5.0.19-Max |
| version_comment | MySQL Community Edition - Max (GPL) |
| version_compile_machine | i686 |
| version_compile_os | pc-linux-gnu |
| wait_timeout | 28800 |
+---------------------------------+-------------------------------------+

:::MySQL Korea:::
LIKE 절로, 문은 패턴에 맞는 변수들만을 보여준다. 명확한 변수 이름을 얻기 위해서, 아래와 같이 LIKE 절을 이용하라.:
SHOW VARIABLES LIKE 'max_join_size';
SHOW SESSION VARIABLES LIKE 'max_join_size';
패턴에 적합한 변수 이름의 리스트를 얻기 위해서, LIKE절에 있는 % 와일드카드 문자(캐릭터)를 이용하라.:
SHOW VARIABLES LIKE '%size%';
SHOW GLOBAL VARIABLES LIKE '%size%';
와일드카드 문자(캐릭터)는 부합하는 패턴 내에서 어떤 포지션에서든지 사용될 수 있다. 엄격하게 말해서, ‘_’은 싱글 문자(캐릭터)
에 적합한 와일드카드이기 때문에, 글자 그대로 적합한 ‘￦_’로써 그것을 피해야한다. 실제로 이것은 그다지 필요하지 않다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.4.25. SHOW WARNINGS
13. SQL 문법(SQL Statement Syntax) SHOW WARNINGS [LIMIT [offset,] row_count]
13.5.4 SHOW SHOW COUNT(*) WARNINGS

SHOW WARNINGS 은 메시지를 생성한 마지막 문에서 기인된 에러, 경고, 주의 메세지를 보여준다. 만약 테이블을 사용한 마지
막 문이 메시지를 생성하지 않았다면, 아무것도 보여주지 않는다. 관련된 문, SHOW ERRORS는 에러만을 보여준다. 13.5.4.11,
“SHOW ERRORS 신텍스”장을 참조하라..
13.5.4.6 SHOW CREATE TABLE 메시지 리스트는 테이블을 사용한 각각 새로운 문으로 리셋된다.
SHOW COUNT(*) WARNINGS 문은 에러, 경고, 주의의 총 수를 보여준다. warning_count 변수로 이 숫자를 검색할 수 있다:
SHOW COUNT(*) WARNINGS;
13.5.4.13 SHOW INDEX SELECT @@warning_count;
13.5.4.15 SHOW LOGS 만약 max_error_count 시스템 변수가 낮게 셋팅되어 모든 메시지를 저장할 수 없다면, warning_count 값은 SHOW
13.5.4.16 SHOW OPEN TABLES WARNINGS 에 의해 보여지는 메시지 숫자보다 클 수 있다. 이 섹션에서 보여주는 예는 이것이 어떻게 발생할 수 있는지를 증명한
13.5.4.17 SHOW PRIVILEGES 다.


:::MySQL Korea:::

LIMIT 절은 SELECT 문에서와 같은 신텍스를 갖는다. 13.2.7, “SELECT 신텍스”장을 참조하라.
13.5.4.23 SHOW TRIGGERS MySQL 서버는 마지막 문에서 기인된 에러, 경고, 주의의 총 수를 반환한다. 만약 C API를 사용 중이라면, 이 값은
13.5.4.24 SHOW VARIABLES mysql_warning_count() 으로 얻을 수 있다. 22.2.3.71, “mysql_warning_count()”장을 참조하라.
경고는 LOAD DATA INFILE 와 같은 문과 INSERT, UPDATE, CREATE TABLE, ALTER TABLE과 같은 DML 문에 의해
발생된다.
다음 DROP TABLE 문은 주의로 귀착한다:
mysql> DROP TABLE IF EXISTS no_such_table;
+-------+------+-------------------------------+
+-------+------+-------------------------------+
| Note | 1051 | Unknown table 'no_such_table' |
+-------+------+-------------------------------+
CREATE TABLE 의 신텍스 경고와 INSERT의 변환 경고를 보여주는 예이다:
mysql> CREATE TABLE t1 (a TINYINT NOT NULL, b CHAR(4)) TYPE=MyISAM;

:::MySQL Korea:::
Query OK, 0 rows affected, 1 warning (0.00 sec)
*************************** 1. row ***************************
Level: Warning
Code: 1287
Message: 'TYPE=storage_engine' is deprecated, use
'ENGINE=storage_engine' instead
mysql> INSERT INTO t1 VALUES(10,'mysql'),(NULL,'test'),
-> (300,'Open Source');
Query OK, 3 rows affected, 4 warnings (0.01 sec)
*************************** 1. row ***************************

:::MySQL Korea:::
Level: Warning
Code: 1265
Message: Data truncated for column 'b' at row 1
*************************** 2. row ***************************
Level: Warning
Code: 1263
Message: Data truncated, NULL supplied to NOT NULL column 'a' at row 2
*************************** 3. row ***************************
Level: Warning
Code: 1264
Message: Data truncated, out of range for column 'a' at row 3
*************************** 4. row ***************************
Level: Warning
Code: 1265
Message: Data truncated for column 'b' at row 3
저장된 에러, 경고, 주의 메시지 최대 수는 max_error_count 시스템 변수로 컨트롤된다. 디폴트로 이 값은 64이다. 저장하려는 메

:::MySQL Korea:::
시지 숫자를 변경하기 위해서, max_error_count 값을 변경한다. 다음의 예에서, ALTER TABLE 문은 세 개의 경고 메시지를 만
든다. 그러나 max_error_count 가 1로 설정되어 있어, 오직 1개만 저장된다:
mysql> SHOW VARIABLES LIKE 'max_error_count';
+-----------------+-------+
+-----------------+-------+
| max_error_count | 64 |
+-----------------+-------+
mysql> SET max_error_count=1;
mysql> ALTER TABLE t1 MODIFY b CHAR;
Query OK, 3 rows affected, 3 warnings (0.00 sec)

:::MySQL Korea:::
mysql> SELECT @@warning_count;
+-----------------+
| @@warning_count |
+-----------------+
| 3|
+-----------------+
+---------+------+----------------------------------------+
+---------+------+----------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1 |
+---------+------+----------------------------------------+
경고기능을 억제하려면, max_error_count 를 0으로 설정한다. 이런 경우 warning_count 는 여전히 몇 개의 경고를 발생시켰는

지 보여준다. 그러나 메시지는 저장되지 않는다.

:::MySQL Korea:::
MySQL 5.0.3에서, 기록되지 않은 Note-단계 경고를 일으키기 위해, SQL_NOTES 세션 변수를 0으로 설정할 수 있다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.5. 기타 관리 문
13. SQL 문법(SQL Statement Syntax) 13.5.5.1. CACHE INDEX

13.5. 데이터베이스 관리문 13.5.5.2. FLUSH
13.5.5 기타 관리 문 13.5.5.3. KILL
13.5.5.1 CACHE INDEX 13.5.5.4. LOAD INDEX INTO CACHE
13.5.5.2 FLUSH 13.5.5.5. RESET
13.5.5.3 KILL
13.5.5.5 RESET
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.5.1 CACHE INDEX
13. SQL 문법(SQL Statement Syntax) CACHE INDEX

13.5.5 기타 관리 문 tbl_index_list [, tbl_index_list] ...

IN key_cache_name
13.5.5.2 FLUSH
13.5.5.3 KILL
13.5.5.5 RESET tbl_index_list:
tbl_name [[INDEX|KEY] (index_name[, index_name] ...)]
CACHE INDEX 문은 특정 키 캐쉬(cache)에 테이블 인덱스를 할당한다.이것은 MyISAM 테이블에서만 사용된다.
다음 문은 테이블 t1, t2, t3로부터 hot_cache 라 명명된 키 캐쉬(cache)에 인덱스를 할당한다:
mysql> CACHE INDEX t1, t2, t3 IN hot_cache;
+---------+--------------------+----------+----------+
+---------+--------------------+----------+----------+

:::MySQL Korea:::
+---------+--------------------+----------+----------+
CACHE INDEX 신텍스는 테이블로부터 특별한 인덱스들만 캐쉬로 할당되게 지정할 수 있도록 한다. 현재 실행되는 것은 모든 테
이블 인덱스를 캐쉬로 지정하기 대문에 테이블 이름 이외에 다른 것을 지정할 이유가 없다.
키 캐쉬(key cache)는 파라미터 셋팅 문으로 크기를 설정하거나 서버에 파라미터를 셋팅함으로써 생성될 수 있는 CACHE
INDEX 문에서 언급된다. 예를 들면:
mysql> SET GLOBAL keycache1.key_buffer_size=128*1024;
키 캐쉬(Key cache) 파라미터는 구성된 시스템 변수의 숫자로 엑세스될 수 있다. 5.2.3.1, “구조(Structured) 시스템 변수”장
을 참조하라
키 캐쉬(key cache)는 인덱스를 할당하기 전에 반드시 존재해야 한다.:
mysql> CACHE INDEX t1 IN non_existent_cache;
ERROR 1284 (HY000): Unknown key cache 'non_existent_cache'
디폴트로, 테이블 인덱스는 서버 스타스업(startup)에 생성된 메인(디폴트) 키 캐쉬로 할당된다. 키 캐쉬가 파괴될 때, 할당된 모
든 인덱스는 다시 디폴트 키 캐쉬로 할당된다.
인덱스 할당은 서버에 영향을 미친다; 만약 하나의 클라이언트가 인덱스를 주어진 캐쉬에 할당하면, 클라이언트가 쿼리를 사용한
다 할지라도 이 캐쉬는 인덱스를 포함하는 모든 쿼리에 사용된다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.5.2. FLUSH
13. SQL 문법(SQL Statement Syntax) FLUSH [LOCAL | NO_WRITE_TO_BINLOG] flush_option [, flush_option] ...
13.5.5 기타 관리 문 FLUSH 문은 MySQL이 사용한 다양한 내부 캐쉬를 제거하거나 다시 로드한다. FLUSH를 실행하기 위해서 RELOAD 권한이 반
드시 있어야 한다.
13.5.5.2 FLUSH
13.5.5.3 KILL
13.5.5.4 LOAD INDEX INTO CACHE RESET 문은 FLUSH와 비슷하다. 13.5.5.5, “RESET 신텍스”장을 참조하라.
13.5.5.5 RESET
flush_option 은 다음 중 하나가 될 수 있다:
● HOSTS
호스트 캐쉬 테이블을 비운다. 호스트 중 일부의 IP를 변경하거나 Host 'host_name' is blocked 이라는 에러 메시지를 받
는다면, 호스트 테이블을 비워야 한다. MySQL 서버에 접속하는 동안 주어진 호스트에 연속적으로
max_connect_errors 에러가 발생하면, MySQL은 무언가 잘못되었다고 판단하고, 더 이상의 접속요구로부터 호스트를
블록한다. 호스트 테이블을 비우면, 호스트를 다시 연결할 수 있게 된다. A.2.5, “Host 'host_name' is blocked”장을 참
조하라. --max_connect_errors=999999999 이 에러 메시지를 피하기 위해 --max_connect_errors=999999999
로 mysqld 를 시작할 수 있다.
● DES_KEY_FILE
서버 스타트업 타입에 --des-key-file 옵션으로 지정된 파일로부터 DES 키들을 다시 로드한다.
● LOGS

:::MySQL Korea:::
모든 로그 파일을 닫았다가 다시 연다. 바이너리 로깅이 가능하다면, 바이너리 로그 파일의 순서(시퀀스/sequence) 숫자

는 이전 파일에 비례하여 증가된다. 유닉스에서, 이것은 SIGHUP 시그널을 mysqld 서버로 보내는 것과 같다. (몇몇
mysqld가 SIGHUP과 SIGQUIT를 무시하는 Mac OS X 10.3 버전에서는 제외).
서버가 --log-error 옵션으로 시작되었다면, FLUSH LOGS 는 -old 첨자로 다시 명명된 에러 로그를 야기하고,
mysqld는 새로 빈 로그 파일을 생성한다. 만약 --log-error 옵션이 주어지지 않았다면, 새로 이름을 정해주는 일은 발
생하지 않는다.
● PRIVILEGES
mysql 데이터베이스에서 grant 테이블로부터의 권한을 다시 로드한다.
● QUERY CACHE
메모리를 더 잘 이용하기 위해서, 쿼리 캐쉬를 조각처리한다. FLUSH QUERY CACHE 는 RESET QUERY CACHE 와
달리 캐쉬로부터 어떤 쿼리도 옮기지 않는다.
● STATUS
대부분의 상태 변수를 제로(0)로 재설정한다. 이것은 쿼리를 디버깅할 때에만 사용할 수 있는 것이다. 1.8, “버그나 문제
를 리포트하는 방법”장을 참조하라
● {TABLE | TABLES} [tbl_name [, tbl_name] ...]
테이블 이름이 정해지지 않았으면, 열려있는 모든 테이블을 닫고, 사용 중인모든 테이블을 강제로 닫도록 한다. 이것은 또
한 쿼리 캐쉬를 비운다. 하나 또는 그 이상의 테이블 이름들로 주어진 테이블만을 비운다. FLUSH TABLES 는 RESET
QUERY CACHE 문처럼 쿼리 캐쉬로부터 온 모든 쿼리 결과를 삭제한다.
● TABLES WITH READ LOCK
열려있는 모든 테이블을 닫고 UNLOCK TABLES 를 실행할 때 까지, 리드록(read lock:읽기 잠금) 으로 모든 데이터베

:::MySQL Korea:::
으스에서 모든 테이블을 잠근다. 때에 맞게 스냅샷(snapshot)을 취할 수 있는 베리타스(Veritas)와 같은 파일시스템을

사용하고 있다면, 이것은 백업을 하는 매우 편리한 방법이다.
● USER_RESOURCES
모든 시간 당 사용자 리소스를 제로(0)으로 재설정한다. 이것은 시간 당 접속에 도달한 클라이언트, 쿼리, 또는 업데이트
제한이 즉시 활성화되게 한다. FLUSH USER_RESOURCES 는 최대 동시 접속에 제한을 적용하지 않는다. 13.5.1.3,
“GRANT ”장을 참조하라.
임의의 NO_WRITE_TO_BINLOG 키워드(또는 그 알리아스 LOCAL)를 사용하지 않는다면, FLUSH 문은 바이너리 로그로 쓰여
진다. MySQL 서버에서 리플리케이션 마스터로 사용된 FLUSH 문은 리플리케이션 슬레이브(slave)로 디폴트로 리플리케이션되
기 위해 그렇게 한다.
주의: FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, 그리고 FLUSH TABLES WITH READ LOCK 은 슬레이브로 리플
리케이션되면 문제를 야기시키기 때문에 어떤 경우에도 로그 인 되지 않는다.
flush-hosts, flush-logs, flush-privileges, flush-status, 또는 flush-tables 명령을 사용하여, mysqladmin 유틸리티로 이 문

에 엑세스 할 수 있다.
저장된 기능 또는 트리거 내에서 FLUSH 문을 이용하는 것은 MySQL 5.0에서 지원되지 않는다. 그러나 저장된 기능 또는 트리거
로부터 호출이 없는 한, 스토어드 프로시져에서 FLUSH를 사용해도 된다. I.1, “스토어드 루틴과 트리거에서의 제한”장을 참조하
라.

:::MySQL Korea:::
리플리케이션과 함께 RESET 문 사용방법에 대한 정보는 13.5.5.5, “RESET ”장을 참조하라.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.5.3. KILL
13. SQL 문법(SQL Statement Syntax) KILL [CONNECTION | QUERY] thread_id

13.5.5 기타 관리 문 mysqld 로의 연결은 하나의 분리된 스레드에서 실행된다. SHOW PROCESSLIST 문으로 실행되는 스레드를 볼 수 있으며,
KILL thread_id 문으로 스레드를 죽일 수 있다.
13.5.5.2 FLUSH
13.5.5.3 KILL
13.5.5.4 LOAD INDEX INTO CACHE IMySQL 5.0.0에서, KILL 은 임의의 CONNECTION 또는 QUERY 를 변경자로 한다:
13.5.5.5 RESET
● KILL CONNECTION 은 변경자가 없는 KILL 과 같다: 그것은 주어진 thread_id와 관련된 연결을 종결시킨다.
● KILL QUERY는 연결이 현재 실행 중인 문을 종결시킨다. 그러나 연결 그 자체는 그대로 둔다.
PROCESS 권한을 가지고 있다면, 모든 스레드를 볼 수 있다. SUPER 권한이 있다면, 모든 스레드와 문을 중단시킬 수 있다. 그렇
지 않으면, 오로지 자신의 스레드와 문 만을 보거나 죽일 수 있다.
스레드를 검토하고 죽이기 위해서 mysqladmin processlist 그리고 mysqladmin kill 명령을 사용할 수 있다.
주의: 임베디드 서버는 거의 호스트 어플리케이션 스레드 안에서 실행되기 때문에, 임베디드 MySQL 서버 라이브러리와 함께
KILL 을 사용할 수 있다. 그것은 그 자신의 연결 스레드를 생성하지 않는다.

:::MySQL Korea:::
KILL을 사용할 때, 스레드-지정 킬 플래그는 스레드 용으로 설정된다. 대부분의 경우에, 스레드를 죽이는데 다소간 시간이 걸린
다. 왜냐하면 킬 플래그가 일정 간격으로 체크되기 때문이다:
● In SELECT, ORDER BY, GROUP BY 루프들에 있어, 플래그는 로우 블록을 읽은 후에 체크된다. 킬 플래그가 설정되어
있다면, 문은 실행을 중단한다.
● ALTER TABLE동안에, 각 로우 블록이 오리지날 테이블로부터 읽혀지기 전에, 킬 플래그는 체크된다. 킬 플래그가 설정
되어 있다면, 문은 실행을 중단하고, 임시 테이블을 삭제된다.
● During UPDATE 또는 DELETE 실행 중에, 각 블록이 읽고, 각각 업데이트되거나 로우가 삭제된 이후에, 킬 플래그는 체
크된다. 킬 플래그가 설정되어 있다면, 문은 실행을 중단한다. 트랜잭션을 사용하지 않고 있다면, 변경이 롤백되지 않는다
는 점을 주의하라.
● GET_LOCK() 는 실행을 중단하고 NULL로 리턴한다.
● An INSERT DELAYED 스레드는 메모리에 있는 모든 로우를 빨리 비운다(입력한다) 그리고 나서 종료한다.
● 스레드가 테이블 록 조정자(명령: Locked)에 있다면, 테이블 록은 빨리 실행을 중단한다.
● 스레드가 쓰기 호출 안에서 여유 디스크 공간을 기다리고 있으면, 그 쓰기는 “disk full”이라는 에러 메시지와 함께 취소
된다.
● 경고: MyISAM 테이블에서 REPAIR TABLE 또는 OPTIMIZE TABLE 실행을 죽이면, 오류를 일으키고 쓸모없는 테이블
로 끝난다. 그것을 다시 최적화하거나 복구하기 전에는, 그런 테이블에 읽기나 쓰기는 실패한다. (중단 없이).

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.5.4. LOAD INDEX INTO CACHE
13. SQL 문법(SQL Statement Syntax) LOAD INDEX INTO CACHE

13.5.5 기타 관리 문 tbl_index_list [, tbl_index_list] ...

13.5.5.2 FLUSH
13.5.5.3 KILL
tbl_index_list:
13.5.5.5 RESET tbl_name
[[INDEX|KEY] (index_name[, index_name] ...)]
[IGNORE LEAVES]
LOAD INDEX INTO CACHE 문은 테이블 인덱스를 CACHE INDEX 문에 의해 명시적으로 할당하기 위해, 키 캐쉬에 미리 로드
해 놓거나 기본 키 캐쉬에 로드한다. LOAD INDEX INTO CACHE 는 MyISAM 테이블들에서 사용된다.
IGNORE LEAVES 변경자는 미리 로드될 인덱스의 non-leaf 노드들에 대한 블록들을 만든다.
다음 문은 테이블 t1과 t2인덱스의 노드(인덱스 블록)를 미리 로드한다:

:::MySQL Korea:::
mysql> LOAD INDEX INTO CACHE t1, t2 IGNORE LEAVES;
+---------+--------------+----------+----------+
+---------+--------------+----------+----------+
+---------+--------------+----------+----------+
이 문은 t1으로부터 모든 인덱스 블록을 미리 로드한다. 이것은 t2로부터 오직 non-leaf 노드만을 미리 로드한다.
LOAD INDEX INTO CACHE 신텍스로 테이블로부터 특별한 인덱스만을 미리 로드할 수 있도록 지정할 수 있다. 현재의 방법은
테이블 인덱스를 모두 캐쉬로 미리 로드한다. 그래서 테이블 이름과 다른 어떤 것을 지정할 필요가 없다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.5.5.5. RESET
13. SQL 문법(SQL Statement Syntax) RESET reset_option [, reset_option] ...

13.5.5 기타 관리 문 RESET 문은 여러 서버 오퍼레이션 상태를 지울 때 사용된다. RESET 을 실행하기 위해서 RELOAD 권한이 있어야 한다.

13.5.5.2 FLUSH
13.5.5.3 KILL RESET 은 FLUSH문의 강력한 버전처럼 실행한다. 13.5.5.2, “FLUSH ”장을 참조하라.
13.5.5.5 RESET reset_option 은 다음 중 하나가 될 수 있다:
● MASTER
인덱스 파일에 열거된 모든 바이너리 로그를 삭제하고, 빈 바이너리 로그인덱스 파일을 재설정한다. 그리고 새로운 바이너
리 로그 파일을 생성한다. (MySQL 3.23.26 버전에서 FLUSH MASTER 로 알려졌다) 13.6.1, “마스터 서버를 제어하
기 위한 SQL문”장을 참조하라.
● QUERY CACHE
쿼리 캐쉬로부터 모든 쿼리 결과를 삭제한다.
● SLAVE
마스터 바이너리 로그 안에서 슬레이브(slave)가 그 복제 위치(리플리케이션포지션)을 잊게 만든다. 존재하는 릴레이(교체) 로그

파일을 삭제하고, 새로운 릴레이 로그파일을 시작함으로써 재 설정된다. (MySQL 3.23.26 버전에서 FLUSH SLAVE 로 알려졌
다) 13.6.2, “슬레이브 서버를 제어하기 위한 SQL 문”장을 참조하라.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6. 리플리케이션(Replication) 문
13. SQL 문법(SQL Statement Syntax) 13.6.1. 마스터 서버 컨트롤을 위한 SQL 문

13.6. 리플리케이션(Replication) 문 13.6.2. 슬레이브 서브 컨트롤을 위한 SQL 문
13.6 리플리케이션(Replication) 문
13.6.1 마스터 서버 컨트롤을 위한 SQL 문 이 장은 replication 과 관련된 SQL문들에 대해 설명한다. SQL문들의 한 그룹은 master 서버를 제어하기 위해 사용한
13.6.1.1 PURGE MASTER LOGS 다. 다른 것은 slave 서버를 제어하기 위해 사용된다.

13.6.2.9 STOP SLAVE
:::MySQL Korea:::
제목검색
13.6.1. 마스터 서버 컨트롤을 위한 SQL 문

13. SQL 문법(SQL Statement Syntax) 13.6.1.1. PURGE MASTER LOGS

13.6. 리플리케이션(Replication) 문 13.6.1.2. RESET MASTER
13.6.1 마스터 서버 컨트롤을 위한 SQL 문 13.6.1.3. SET SQL_LOG_BIN
13.6.1.1 PURGE MASTER LOGS 13.6.1.4. SHOW BINLOG EVENTS
13.6.1.2 RESET MASTER 13.6.1.5. SHOW MASTER LOGS
13.6.1.3 SET SQL_LOG_BIN 13.6.1.6. SHOW MASTER STATUS

13.6.1.7. SHOW SLAVE HOSTS
13.6.1.7 SHOW SLAVE HOSTS 리플리케이션(Replication)은 SQL인터페이스를 통해 제어될 수 있다. 이 장은 master replication 서버를 관리 하는 SQL문들을
다룬다. 13.6.2 장 “Slave 서버 제어를 위한 SQL문들”에서 slave 서버 관리를 위한 SQL문에 대해 설명한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.1.1. PURGE MASTER LOGS
13. SQL 문법(SQL Statement Syntax) PURGE {MASTER | BINARY} LOGS TO 'log_name'
13.6. 리플리케이션(Replication) 문
13.6.1 마스터 서버 컨트롤을 위한 SQL 문 PURGE {MASTER | BINARY} LOGS BEFORE 'date'

지정된 log나 날짜 이전에 log index안에 기록된 모든 바이너리 로그들을 삭제 한다. 이 로그들은 또한 로그 인덱스 파일에 기록된
리스트들에서도 삭제 되고 주어진 로그는 첫 번째가 된다.
13.6.1.4 SHOW BINLOG EVENTS 예:
13.6.1.6 SHOW MASTER STATUS PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';
BEFORE 변수의 date 인자는 'YYYY-MM-DD hh:mm:ss' 형식이된다. MASTER 와 BINARY 는 동의어 이다.
이 문장은 slave들이 복제(replication)하는 동안 안전하게 실행 된다. 여러분은 이들을 중지할 필요가 없다. 여러분이 삭제 하려
는 로그들 중 하나를 동시에 읽도록 한 활성화된 slave가 있다면, 이 문장은 아무것도 하지 않고 error와 함께 실패 한다. 그러나
slave가 비 활성 상태이고 아직 읽고 있는 로그들의 하나를 삭제 하는 경우, slave는 복제 할 수 없게 된다.
로그들을 안전하게 삭제 하기 위해 다음의 절차를 따르도록 한다:

:::MySQL Korea:::
1. 각 slave서버에서 어떤 로그를 읽고 있는지 검사 하기 위해 SHOW SLAVE STATUS문을 사용한다.

2. SHOW MASTER LOGS문으로 master 서버상에서 로그 리스트를 얻는다.
3. 모든 slave에서 가장 빠른 로그를 결정한다. 이것은 target로그이다. 모든 slave들이 최근의 것들이라면 이것은 리스
트에서 가장 마지막 로그이다.
4. 여러분이 삭제 하려는 모든 로그들에 대한 백업을 만든다. ( 이 과정은 선택 사항이지만 권고 사항이기도 하다)
5. target로그 이전의 모든 로그들을 삭제 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.1.2. RESET MASTER
13. SQL 문법(SQL Statement Syntax) RESET MASTER

13.6.1 마스터 서버 컨트롤을 위한 SQL 문 인덱스 파일에 있는 모든 바이너리 로그들을 삭제한다. 바이너리 로그 파일을 empty상태로 하고 새로운 바이너리 로그 파일을 생
성한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.1.3. SET SQL_LOG_BIN
13. SQL 문법(SQL Statement Syntax) SET SQL_LOG_BIN = {0|1}

13.6.1 마스터 서버 컨트롤을 위한 SQL 문 Client가 SUPER권한을 가진 경우 현재 연결(SQL_LOG_BIN이 세션 변수이다)에 대한 로깅을 활성화 혹은 비 활성화 할 수 있
다. 이 문장은 client가 그 권한이 없는 경우에 에러와 함께 거부 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.1.4. SHOW BINLOG EVENTS
13. SQL 문법(SQL Statement Syntax) SHOW BINLOG EVENTS

13.6.1 마스터 서버 컨트롤을 위한 SQL 문 [IN 'log_name'] [FROM pos] [LIMIT [offset,] row_count]

바이너리 로그 안의 모든 이벤트를 보여준다. 여러분이 “log_name’을 명시 하지 않으면 첫번째 바이너리 로그가 display된다.
13.6.1.5 SHOW MASTER LOGS LIMIT 절은 SELECT문을 위한 것과 같은 구문을 가진다. 13.2.7장 “SELECT” 부분을 참조 하라.
Note: LIMIT절이 없이 SHOW BINLOG EVENTS 을 사용하는 경우 서버가 완전한 바이너리 로그의 내용을 클라이언트에게 주
기 위해 많은 시간과 자원 소비를 가져 올 수 있다(이것은 데이터를 변경하는 서버에 의해 실행되는 모든 SQL문을 포함한다).
SHOW BINLOG EVENTS에 대한 대안으로 추후 검사와 분석을 위해 text파일로 바이너리 로그를 저장하기 위해 mysqlbinlog
유틸리티를 사용하도록 한다. 8.9장 “mysqlbinlog-바이너리 로그파일 처리를 위한 유틸리티”부분을 참조하라.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.1.5. SHOW MASTER LOGS
13. SQL 문법(SQL Statement Syntax) SHOW MASTER LOGS

13.6.1 마스터 서버 컨트롤을 위한 SQL 문 SHOW BINARY LOGS

서버에서 바이너리 로그파일들을 나열한다. 이 문은 13.6.1.1장 “PURGE MASTER LOGS”에서 설명된 절차의 부분으로서 사
용되며 어떤 로그들이 삭제 될 수 있는 지 결정하기 위해 보여준다.
13.6.1.4 SHOW BINLOG EVENTS mysql> SHOW BINARY LOGS;
13.6.1.6 SHOW MASTER STATUS +---------------+-----------+
| Log_name | File_size |
+---------------+-----------+
| binlog.000015 | 724935 |
| binlog.000016 | 733481 |
+---------------+-----------+
SHOW BINARY LOGS 는 SHOW MASTER LOGS과 같다. File_Size 컬럼은 MySQL 5.0.7로 display된다.
13.6.1.6. SHOW MASTER STATUS

:::MySQL Korea:::
SHOW MASTER STATUS
Master의 바이너리 로그 파일에 대한 상태 정보를 제공한다.
예:
+---------------+----------+--------------+------------------+
| File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
+---------------+----------+--------------+------------------+

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.1.6. SHOW MASTER STATUS
13. SQL 문법(SQL Statement Syntax) SHOW MASTER STATUS

13.6.1 마스터 서버 컨트롤을 위한 SQL 문 Master의 바이너리 로그 파일에 대한 상태 정보를 제공한다.

예:
13.6.1.5 SHOW MASTER LOGS +---------------+----------+--------------+------------------+
13.6.1.7 SHOW SLAVE HOSTS | File | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
+---------------+----------+--------------+------------------+
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.1.7. SHOW SLAVE HOSTS
13. SQL 문법(SQL Statement Syntax) SHOW SLAVE HOSTS

13.6.1 마스터 서버 컨트롤을 위한 SQL 문 현재 master로 등록된 복제 slave의 리스트를 display한다. --report-host=slave_name 옵션으로 시작하지 않는 slave는 이
리스트에서 보기가 불가능 하다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2. 슬레이브 서버 컨트롤을 위한 SQL 문
13. SQL 문법(SQL Statement Syntax) 13.6.2.1. CHANGE MASTER TO

13.6. 리플리케이션(Replication) 문 13.6.2.2. LOAD DATA FROM MASTER
13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 13.6.2.3. LOAD TABLE tbl_name FROM MASTER
13.6.2.1 CHANGE MASTER TO 13.6.2.4. MASTER_POS_WAIT()
13.6.2.2 LOAD DATA FROM MASTER 13.6.2.5. RESET SLAVE

13.6.2.6. SET GLOBAL SQL_SLAVE_SKIP_COUNTER
13.6.2.7. SHOW SLAVE STATUS
13.6.2.8. START SLAVE
13.6.2.9. STOP SLAVE
복제는 SQL 인터페이스를 통해 제어 될 수 있다. 이 장은 복제 서버를 관리 하기 위한 문에 대해 설명한다. 13.6.1장
“Master 서버 제어를 위한 SQL 문” 부분에서 master서버를 제어하기 위한 SQL문들을 설명한다.
13.6.2.9 STOP SLAVE
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.1. CHANGE MASTER TO
13. SQL 문법(SQL Statement Syntax) CHANGE MASTER TO master_def [, master_def] ...

master_def:
MASTER_HOST = 'host_name'
13.6.2.5 RESET SLAVE | MASTER_USER = 'user_name'
13.6.2.7 SHOW SLAVE STATUS | MASTER_PASSWORD = 'password'

| MASTER_PORT = port_num
13.6.2.9 STOP SLAVE
| MASTER_CONNECT_RETRY = count
| MASTER_LOG_FILE = 'master_log_name'
| MASTER_LOG_POS = master_log_pos
| RELAY_LOG_FILE = 'relay_log_name'
| RELAY_LOG_POS = relay_log_pos
| MASTER_SSL = {0|1}

:::MySQL Korea:::
| MASTER_SSL_CA = 'ca_file_name'
| MASTER_SSL_CAPATH = 'ca_directory_name'
| MASTER_SSL_CERT = 'cert_file_name'
| MASTER_SSL_KEY = 'key_file_name'
| MASTER_SSL_CIPHER = 'cipher_list'
CHANGE MASTER TO 는 master 서버와 연결 및 통신을 위해 slave 서버가 사용하는 파라미터들을 변경한다. 이것은
master.info와 relay-log.inf 파일들의 내용을 업데이트 하기도 한다.
MASTER_USER, MASTER_PASSWORD, MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH,

MASTER_SSL_CERT, MASTER_SSL_KEY, and MASTER_SSL_CIPHER 는 그 master에 어떻게 연결 할지에 대한
정보를 제공한다.
SSL 옵션(MASTER_SSL, MASTER_SSL_CA, MASTER_SSL_CAPATH, MASTER_SSL_CERT,

MASTER_SSL_KEY, and MASTER_SSL_CIPHER)은 SSL 지원없이 컴파일된 slave들에서도 변경 될 수 있다. 그들
은 master.info 파일에 저장되나 여러분이 SSL지원을 활성화 한 서버를 사용하지 않는 이상 무시 된다.
여러분이 한 주어진 파라미터를 명시하지 않는 한 그것은 이전 값을 계속 가지고 있다. 예를 들면 MySQL master에 연결

하기 위한 비밀번호가 변경 되었다면 여러분은 새로운 비밀번호에 대해서 slave에게 이야기 하기 위해 이들 문장들을 사용
할 필요가 있다.
STOP SLAVE; -- if replication was running

:::MySQL Korea:::
CHANGE MASTER TO MASTER_PASSWORD='new3cret';
START SLAVE; -- if you want to restart replication
변경 하지 않는 파라미터를 명시할 필요는 없다. (host, port, user, and so forth).
MASTER_HOST 와MASTER_PORT 들은 master 호스트와 그 TCP/IP 포트의 호스트 이름들이다. MySQL의 다른 부

분들처럼 MASTER_HOST 가 localhost와 같다면 포트 번호는 무시될 것이다. (예를 들어 Unix 소켓이 사용될 수 있다
면)
MASTER_HOST 나MASTER_PORT를 명시 하면 slave는 master 서버가 이전과 다르다고 여긴다.( 심지어 여러분이
현재 값과 같은 호스트나 포트 값을 명시한다면) 이 경우 master 바이너리 로그 이름과 위치에 대한 이전 값들이 더 이상
적용 불가능 하다고 간주되어 여러분이 SQL문에서 MASTER_LOG_FILE과 MASTER_LOG_POS를 명시하지 않으면
Master_LOG_FILE=’’ 와 MASTER_LOG_POS=4로 암시적으로 적용된다.
MASTER_LOG_FILE 과MASTER_LOG_POS 들은 쓰레드가 시작하는 다음 시간에 master로부터 slave I/O쓰레드가

읽기를 시작해야 하는 좌표 값 들이다. 만약 여러분이 이들 중 하나를 명시하면, RELAY_LOG_FILE 나
RELAY_LOG_POS를 명시 할 수 없다. MASTER_LOG_FILE이나 MASTER_LOG_POS 둘다 명시 되지 않으면 slave
는 CHANGE MASTER 가 불려지기 전에 slave SQL thread의 마지막 좌표 값을 사용한다. 이것은 여러분이 단순히 변경
하기 원할 때에, 심지어 slave SQL 쓰레드가 slave I/O 쓰레드와 비교되어도, 복제에 불연속성이 없다는 것을 보증한다
CHANGE MASTER 는 여러분이 RELAY_LOG_FILE이나 RELAY_LOG_POS를 명시 하지 않는 이상 모든 relay log 파

일들을 삭제 하고 새로 시작한다. 이 경우 relay log들은 유지된다. Relay_log_purge 전역 변수는 묵시적으로 0으로 설정

:::MySQL Korea:::
된다.
CHANGE MASTER 는 master의 스냅샷(snapshot)을 가지며 로그와 그것에 부합하는 옵셋(offset)을 기록할 때 하나
의 slave를 설정하는데 유용하다. 스냅샷을 slave에 로딩한 후, slave에서 CHANGE MASTER TO
MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master 를 실행 시킬 수 있다.
다음 예는 master와 master의 바이너리 로그 좌표(coordinate)를 변경한다. 이것은 여러분이 master를 복제 하기 위해

slave를 설정하기 원할 때 사용된다:
CHANGE MASTER TO
MASTER_HOST='master2.mycompany.com',
MASTER_USER='replication',
MASTER_PASSWORD='bigs3cret',
MASTER_PORT=3306,
MASTER_LOG_FILE='master2-bin.001',
MASTER_LOG_POS=4,
MASTER_CONNECT_RETRY=10;
다음 예는 드물게 사용되는 연산을 보여준다. 이것은 여러분이 어떤 이유로 다시 실행되기 원하는 릴레이(relay)로그를
slave가 가진 경우에 사용된다. 여러분은 단지 CHANGE MASTER TO를 사용하고 SQL 쓰레드(START SLAVE
SQL_THREAD)를 시작 시키면 된다:

:::MySQL Korea:::
CHANGE MASTER TO
RELAY_LOG_FILE='slave-relay-bin.006',
RELAY_LOG_POS=4025;
여러분은 standalone를 가지고 비 복제 설정이나 다음 crash의 회복을 위해 비 slave 서버안에서 두번째 연산을 사용할
수 있다. 여러분의 서버가 손상을 입고 백업을 복원했다고 가정하자. 여러분은 myhost-bin.*의 이름으로 된 서버의 바이
너리 로그(relay 로그가 아닌 정규 바이너리 로그)를 재생하기 원한다. 맨 처음 여러분이 정확히 아래 프로시저를 따르지
않고 서버가 바이너리 로그를 삭제한 경우를 대비하기 위해 , 안전한 공간에 바이너리 로그들의 복사본을 백업한다. 추가
적인 안전을 위해 SET GLOBAL relay_log_purge=0을 사용하라. 그다음 –log-binary옵션 대신 –replicate-same-
server-id, --relay-log=myhost-bin(서버가 이 정규 바이너리 로그가 relay 로그라고 믿게 하기 위해)와 –skip-
slave-start 옵션을 사용하여 서버를 시작하라. 서버가 시작 후 다음 이 문장을 실행 하라.
CHANGE MASTER TO
RELAY_LOG_FILE='myhost-bin.153',
RELAY_LOG_POS=410,
MASTER_HOST='some_dummy_string';
START SLAVE SQL_THREAD;
서버는 자신의 바이너리 로그를 읽고 실행하여 crash 회복을 한다. 일단 회복(recovery)가 끝나면, STOP SLAVE를 실
행하여, 서버를 중지 시키고 master.info와 relay-log.info파일들을 삭제 한 다음 이 옵션들을 이용하여 서버를 재 시작한
다.
서버가 slave라고 생각하도록 하기 위해 MASTER_HOST옵션을 명시한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.2. LOAD DATA FROM MASTER
13. SQL 문법(SQL Statement Syntax) LOAD DATA FROM MASTER

13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 이 SQL문은 master의 스냅샷(snapshot)을 slave에 복사한다. 이것은 MASTER_LOG_FILE과 MASTER_LOG_POS
의 값들을 업데이트 하여 slave가 정확한 위치로부터 복제를 시작하도록 한다. –replicate-*-do-* 와 –replicate-*-
ignore-*옵션들로 명시된 테이블과 데이터베이스의 실행 규칙들이 지켜진다. 한 사용자가 --replicate-rewrite-
db="db1->db3" and --replicate-rewrite-db="db2->db3"와 같이 유일하지 않은 매핑을 설정하기 위해 이
옵션을 사용할 수 있기 때문에 , -–replicate-rewrite-db 이 고려되지 않는데 이는 master로부터 테이블들을 로딩할
때에 slave를 혼란하게 할 것이다.
13.6.2.8 START SLAVE 이 문의 사용은 다음 조건들에 의해 좌우 된다:
13.6.2.9 STOP SLAVE
• 이것은 MyISAM테이블들에 대해서만 작용한다. 비MyISAM테이블의 로딩 시도는 다음 에러를 유발한다.
ERROR 1189 (08S01): Net error reading from master
• 이것은 스냅샷을 갖는 동안 마스터에게 전역적인 읽기 잠금을 취하고 로드 연산 중에 master에 업데이트를 하지 못

하게 한다.
여러분이 큰 테이블들을 로딩한다면 master와 slave양쪽에서 net_read_timeout과 net_write_timeout의 값을 증가 시켜

야 한다. 5.2.2장 “서버 시스템 변수들”을 참조하라.

:::MySQL Korea:::
LOAD DATA FROM MASTER 는 mysql 데이터베이스에서 어떤 테이블도 복사 하지 않는 다는 것에 주의 하라. 이것

은 master와 slave에서 다른 유저와 권한을 갖기 쉽게 한다.
LOAD DATA FROM MASTER를 사용하기 위해 master에 연결하기 위해 사용되는 복제 계정이 master에 대해
RELOAD와 SUPER권한을 가져야 하고 여러분이 로드 하려는 모든 master 테이블들에 대해 SELECT 권한을 가져야 한
다. 사용자가 SELECT 권한을 갖지 않으면 모든 master 테이블들은LOAD DATA FROM MASTER에 의해 무시된다.
이는 master가 사용자로부터 그들을 숨기기 때문이다. LOAD DATA FROM MASTER는 로드하려는 master 데이터베
이스를 알기 위해 SHOW DATABASES를 호출한다. 그러나 SHOW DATABASES는 사용자가 같은 권한을 가진 데이터
베이스만 리턴한다. 13.5.4.8장 “SHOW DATABASES”를 참조 하라. slave측에서 LOAD DATA FROM MASTER
를 실행하는 사용자는 복사된 데이터베이스와 테이블들을 삭제 및 생성하는 권한을 가져야 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.3. LOAD TABLE tbl_name FROM MASTER
13. SQL 문법(SQL Statement Syntax) LOAD TABLE tbl_name FROM MASTER
13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 master에서 테이블의 복사본을 slave로 이전한다. 이문은 디버깅 LOAD DATA FROM MASTER 연산들로 구현되어 있
다. LOAD TABE를 사용하기 위해 master서버에 연결하기 위해 사용되는 계정은 master에 대해 RELAD 와 SUPER 권
한과 load하려는 master 테이블에 대한 SELECT권한을 가져야 한다. Slave 측에서 LOAD TABLE FROM MASTER를
실행 시키는 사용자는 그 테이블을 삭제 생성할 수 있는 권한들을 가져야 한다.
13.6.2.6 SET GLOBAL SQL_SLAVE_SKIP_COUNTER LOAD DATA FROM MASTER 을 위한 조건들은 여기서도 적용한다. 예를 들면 LOAD TABLE FROM MASTER는
13.6.2.7 SHOW SLAVE STATUS MyISAM테이블들에 대해서만 작용한다. LOAD DATA FROM MASTER에 대한 타임아웃 값도 적용된다.

13.6.2.9 STOP SLAVE
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.4. MASTER_POS_WAIT()
13. SQL 문법(SQL Statement Syntax) SELECT MASTER_POS_WAIT('master_log_file', master_log_pos)

13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 이것은 실제로는 SQL문이 아닌 하나의 함수이다. 이것은 slave가 master 의 바이너리 로그에서 주어진 위치에까지
event를 읽고 실행하도록 하기 위해 사용된다. 12.9.4장 “Miscellaneous 함수들”을 참조하라.
13.6.2.9 STOP SLAVE
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.5. RESET SLAVE
13. SQL 문법(SQL Statement Syntax) RESET SLAVE

13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 RESET SLAVE 는 slave로 하여금 master의 바이너리 로그 안에서 복제 위치를 잊도록 한다. 이 문은 깔끔한 시작을 위
해 사용 되는 것을 의미한다. 모든 relay로그와 master.info와 relay-log.info파일들을 삭제하고 새로운 relay 로그를 시
작한다.
13.6.2.5 RESET SLAVE Note: 모든 relay로그들은 slave SQL 쓰레드에 의해 완전히 실행되지 않았다 해도 삭제된다. (이것은 여러분이 STOP
13.6.2.6 SET GLOBAL SQL_SLAVE_SKIP_COUNTER SLAVE문을 실행 하거나 slave가 높게 load된 경우 복제 slave에 존재하기 쉬운 조건이다)
13.6.2.9 STOP SLAVE
Master.info파일에 저장되는 연결 정보는 시동 옵션들에 명시된 값들을 이용하여 즉시 리셋된다. 이 정보는 master 호스
트, master 포트, master 사용자 그리고 master 비밀번호와 같은 값들을 포함한다. Slave SQL쓰레드가 slave가 중지
될 때 임시 테이블의 복제 도중에 있고 RESET SLAVE가 실행 되었다면 이들 복제된 임시 테이블들은 slave에서 삭제된
다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.6. SET GLOBAL SQL_SLAVE_SKIP_COUNTER
13. SQL 문법(SQL Statement Syntax) SET GLOBAL SQL_SLAVE_SKIP_COUNTER = N

13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 이 문은 master로부터 다음 N event를 skip한다. 이것은 하나의 SQL문에 의해 유발된 복제 중지로부터 회복하는데 유용
하다.
13.6.2.4 MASTER_POS_WAIT() 이 문은 slave쓰레드가 실행 중이 아닐 때에만 유효하다. 그렇지 않으면 이것은 에러를 발생시킨다.
13.6.2.9 STOP SLAVE
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.7. SHOW SLAVE STATUS
13. SQL 문법(SQL Statement Syntax) SHOW SLAVE STATUS

13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 이 문은 slave 쓰레드들의 주요 인자들에 대한 상태 정보를 제공한다. 여러분이 mysql 클라이언트를 이용하여 이 문장을
실행하면 세미콜론을 사용하는 것보다 값들이 아래와 같이 수직으로 일관되게 위치하게 하여 읽기를 돕는 ￦G문장 종결자
를 사용할 수 있다:
mysql> SHOW SLAVE STATUS￦G
13.6.2.5 RESET SLAVE *************************** 1. row ***************************
13.6.2.7 SHOW SLAVE STATUS Slave_IO_State: Waiting for master to send event

Master_Host: localhost
13.6.2.9 STOP SLAVE
Master_User: root
Master_Port: 3306
Connect_Retry: 3
Master_Log_File: gbichot-bin.005
Read_Master_Log_Pos: 79
Relay_Log_File: gbichot-relay-bin.005

:::MySQL Korea:::
Relay_Log_Pos: 548
Relay_Master_Log_File: gbichot-bin.005
Slave_IO_Running: Yes
Slave_SQL_Running: Yes
Replicate_Do_DB:
Replicate_Ignore_DB:
Last_Errno: 0
Last_Error:
Skip_Counter: 0
Exec_Master_Log_Pos: 79
Relay_Log_Space: 552
Until_Condition: None
Until_Log_File:
Until_Log_Pos: 0
Master_SSL_Allowed: No
Master_SSL_CA_File:

:::MySQL Korea:::
Master_SSL_CA_Path:
Master_SSL_Cert:
Master_SSL_Cipher:
Master_SSL_Key:
Seconds_Behind_Master: 8
SHOW SLAVE STATUS 는 다음 필드들을 리턴한다:
• Slave_IO_State
Slave의 I/O쓰레드를 위한 SHOW PROCESSLIST의 결과에서 State 필드의복사. 이것은 어떤 쓰레드가 master에 연결
을 시도하고 master로부터 event를 기다리며 master에 재 연결을 하는 지에 대해 알려준다. 가능한 상태에 대한 내용은
6.3장 “Replication implementation Details”을 참조하라. 이것은 MySQL의 이전 버전(5.0.12 이전버전)에서 이 값
을 체크하는 것이 필요한데 이들 버전들에서 비 성공적으로 master에 연결을 시도하는 동안 쓰레드가 실행 될 수 있기 때
문이다. 이 필드는 여러분이 연결의 문제를 알도록 한다. SQL 쓰레드의 상태는 매우 간단하므로 복제 되지 않는다. 이것
이 실행 중인 경우, 문제가 없다. 그렇지 않다면 여러분은 Last_Error필드에서 에러를 찾을 수 있다.
• Master_Host
현재 master 호스트.
• Master_User
Master에 연결 하는데 사용되는 현재 사용자.
• Master_Port
현재 master 포트.
• Connect_Retry
--master-connect-retry 옵션의 현재 값.

:::MySQL Korea:::
• Master_Log_File
I/O쓰레드가 현재 읽고 있는 바이너리 로그 파일의 이름.
• Read_Master_Log_Pos
I/O쓰레드가 현재 master 바이너리 로그에서 읽은 곳까지의 위치.
• Relay_Log_File
SQL쓰레드가 현재 읽고 실행 하고 있는 relay 로그 파일의 이름.
• Relay_Log_Pos
SQL 쓰레드가 현재 relay 로그 에서 읽고 실행한 곳까지의 위치.
• Relay_Master_Log_File
SQL 쓰레드에 의해 실행된 최근의 event를 포함하고 있는 master 바이너리 로그 파일의 이름.
• Slave_IO_Running
I/O쓰레드가 시작되어 master에 성공적으로 연결되었는지의 여부. MySQL의이전 버전(4.1.14와 5.0.12이전)에서는,
slave가 master에 아직 연결 되지 않았을 지라도, I/O쓰레드가 시작되면 Slave_IO_Running이 YES이다.
• Slave_SQL_Running
SQL 쓰레드가 시작되었는지의 여부.
• Replicate_Do_DB, Replicate_Ignore_DB
--replicate-do-db 과 --replicate-ignore-db 옵션으로 명시된 데이터베이스 리스트.
• Replicate_Do_Table, Replicate_Ignore_Table, Replicate_Wild_Do_Table, Replicate_Wild_Ignore_Table

--replicate-do-table, --replicate-ignore-table, --replicate-wild-do-table, 과 --replicate-wild-
ignore_table 옵션으로 명시된 테이블의 리스트.
• Last_Errno, Last_Error
가장 최근에 사용된 쿼리에 의해 리턴된 에러 메시지와 번호. 에러 번호가 0 이거나 에러 메시지가 빈 문자열인 경우 “no

:::MySQL Korea:::
error”를 의미한다. 만약 Last_Error값이 empty가 아닌 경우, slave의 에러 로그에 하나의 메시지로 나타난다. 예를 들
면:
Last_Errno: 1051
Last_Error: error 'Unknown table 'z'' on query 'drop table z'
메시지는 테이블 z가 master에 존재하여 삭제 된 것을 지시한다. 그러나그것은 slave에는 존재하지 않고 DROP TABLE
은 slave에서 실패하였다. (이것은 여러분이 복제를 설정할 때 slave에 table의 복사를 잊어버릴 경우 발생 할 수 있다.)
• Skip_Counter
SQL_SLAVE_SKIP_COUNTER를 위해 가장 최근 사용된 값.
• Exec_Master_Log_Pos
Master의 바이너리 로그(Relay_Master_Log_File)로부터 SQL쓰레드에 의해 수행된 마지막 event의 위치. Master 바
이너리 로그 안의 (Relay_Master_Log_File, Exec_Master_Log_Pos)는 relay 로그 안의 (Relay_Log_File,
Relay_Log_Pos)와 일치 한다.
• Relay_Log_Space
존재하는 모든 relay 로그의 전체 사이즈
• Until_Condition, Until_Log_File, Until_Log_Pos

START SLAVE 문의UNTIL절에서 명시된 값들.
Until_Condition 은 다음과 같은 값들을 갖는다:
● UNTIL절이 명시 되지 않으면 None

● master바이너리 로그들 안에 주어진 위치까지 slave가 읽고 있으면 Master
● slave의 relay로그들 안에서 주어진 위치까지 slave가 읽고 있으면 Relay
Until_Log_File 와 Until_Log_Pos 은 SQL 쓰레드가 실행을 멈추는 위치를 정의하는 위치 값과 로그 파일 이름을 지정한
다.

:::MySQL Korea:::
• Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_CA_Path, Master_SSL_Cert,

Master_SSL_Cipher, Master_SSL_Key
이 필드들은 master에 연결하기 위해 slave에 의해 사용된 SSL 파라미터들을 보여준다.
Master_SSL_Allowed 는 다음과 같은 값들을 갖는다:
● master로의 SSL연결이 허락된다면

● master로의 SSL연결이 허락되지 않으면 No
● SSL 연결이 허락되었으나 slave서버가 SSL 지원 활성화 되도록 하지 않으면 Ignored
다른 SSL관련 필드들의 값들은 --master-ca, --master-capath, --master-cert, --master-cipher, 와--

master-key 옵션들의 값과 일치 한다.
• Seconds_Behind_Master
이 필드는 얼마나 slave가 “late”한지에 대한 지정이다:
● Slave SQL 쓰레드가 실행될 때 이 값은 그 쓰레드에 의해 실행된 master의 가장 최근 event의 timestamp 이후

경과된 경과 된 시간(초 단위)의 수이다.
● SQL 쓰레드가 slave I/O쓰레드를 따라잡고 I/O쓰레드로부터의 다른 event를 기다리는 idle상태가 되면 이 값은
zero이다.
본질적으로 이 필드는 slave SQL 쓰레드와 slave I/O 쓰레드 사이의 시간 차(초 단위)를 측정한다.
Master와 slave사이의 네트웍 연결이 빠르다면, slave I/O쓰레드는 master와 매우 가깝고 이 필드는 SQL 쓰레드가
master에 비해 얼마나 느린지에 대한 좋은 추정이 된다. 네트웍이 느린 경우 이것은 좋은 것이 되지 못한다. Slave SQL
쓰레드가 느린 읽기 slave I/O 쓰레드에 의해 따라 잡히기 때문에 I/O 쓰레드가 master에 비해 느린 경우라도,
Seconds_Behind_Master는 자주 0의 값을 보여준다. 다시 말하면 이 컬럼은 빠른 네트웍에서만 유용하다.
이 시간 차이 계산은 master와 slave가 구별하는 clock(clock 차이는 slave I/O쓰레드가 시작할 때 계산되고 on상태로
항상 유지 되도록 한다)이 없을지라도 작동 한다. Slave SQL쓰레드가 실행중이 아니거나 master에 연결되지 않은 경우

:::MySQL Korea:::
Seconds_Behind_Master 은 NULL 이다(이것은 “unknown”을 의미한다). 예를 들어 slave I/O쓰레드가 연결 전에

--master-connect-retry 옵션에 의해 주어진 시간(초)동안 수면상태라면, NULL이 보여지고 slave는 master가 무엇
을 하는지 알지 못하고 그것이 얼마나 늦을지 말할 수 없다.
이 필드는 하나의 제약을 갖는다. Timestamp가 복제를 통해 보존되는데 이는 ,master M1이 M0의 slave라면, M0의
binlog로부터 event를 복제하는데서 발생하는 M1의 binlog의 어떤 event도 그 evnet의 timestamp를 갖는다는 것을 의
미한다. 이것은 MySQL이 TIMESTAMP를 성공적으로 복제 하도록 한다. 그러나 This enables MySQL to replicate
TIMESTAMP successfully. However, the drawback for Seconds_Behind_Master 의 결점은 M1이 클라이언트로부
터 직접 update를 받은 경우, 때때로 M1의 event가 M0로부터 나오고 직접 update로부터 가장 최근의 timestamp이기
때문에, 그 값이 무작위로 벗어난다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.8. START SLAVE
13. SQL 문법(SQL Statement Syntax) START SLAVE [thread_type [, thread_type] ... ]
13.6.2 슬레이브 서버 컨트롤을 위한 SQL 문 START SLAVE [SQL_THREAD] UNTIL

MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
START SLAVE [SQL_THREAD] UNTIL
13.6.2.5 RESET SLAVE RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos
thread_type: IO_THREAD | SQL_THREAD
13.6.2.9 STOP SLAVE
thread_type 옵션을 갖지 않는 START SLAVE 는 slave 쓰레드의 양쪽에서 시작한다. I/O쓰레드는 master 서버에서 쿼
리들을 읽고 그것들을 relay 로그에 저장한다. SQL 쓰레드 relay 로그를 읽고 그 쿼리들을 실행한다. START SLAVE
는 SUPER 권한을 필요로 한다.
START SLAVE 가 slave 쓰레드들의 시작이 성공하면 어떤 에러없이 리턴한다. 그러나 이 경우에도 slave쓰레드가 시작
하고 뒤에 정지 할수 있다(예를 들면, master에 연결, 바이너리 로그 혹은 어떤 다른 문제들을 읽지 못하기 때문이다).
START SLAVE 는 여러분에게 이것에 대해 경고 하지 않는다. 여러분은 slave 쓰레드들에 의해 생성된 에러 메시지를 위
해 slave의 에러 로그를 체크하거나 그것들이 SHOW SLAVE STATUS로써 만족할만하게 실행되는 것을 체크해야 한
다.

:::MySQL Korea:::
어떤 쓰레드들이 시작하는지 명명하기 위해 그 문에 IO_THREAD와 SQL_THREAD를 추가 할 수 있다.
UNTIL 절은 SQL 쓰레드가 master 바이너리 로그나 slave relay로그들 안에서 주어진 위치에 이를 때까지 slave가 시작
하고 실행 되어야 함을 명시하기 위해 사용될 수 있다. SQL 쓰레드가 그 지점에 이르면 그것은 정지한다. 만약
SQL_THREAD옵션이 그 문장에서 명시되면 SQL 쓰레드만을 시작한다. SQL 쓰레드가 실행 중인 경우, UNTIL절은 무
시되고 경고가 발생한다.
하나의 UNTIL 절에 대해 여러분은 로그 파일이름과 위치를 지정해야 한다. Mater와 relay log옵션을 뒤섞지 말라.
UNTIL 조건은 STOP SLAVE문이나 UNTIL 절을 포함하지 않는 START SLAVE문에 의해 reset된다.
UNTIL 절은 복제를 디버깅하기 위해, 여러분이 slave가 한 문장을 복제하는 것을 피하기 원하는 지점 이전까지 복제를
진행하도록 하는데 유용할 수 있다. 예를 들면, 한 DROP TABLE문이 master에서 실행되었다면 여러분은 slave가 그 지
점 이상 실행되지 못하게 하기 위해 UNTIL을 사용할 수 있다. 어떤 event인지 찾기 위해, master 로그나 slave relay로
그와 함께 mysqlbinlog이나 SHOW BINLOG EVENTS문을 사용하라.
여러분이 slave가 섹션들에서 복제된 쿼리들을 실행하도록 하기 위해 UNTIL을 이용하고 있다면, SQL 쓰레드가 slaver
서버가 시작할 때 실행되는 것을 막기 위해 –skip-slave-start옵션과 함께 slave를 시작할 것을 권장한다. Command
라인에서 보다 option 파일에서 이 옵션을 사용하는 것이 아마도 최선 이며 이로 인해 예기치 못한 서버가 잊혀지지 않도
록 한다.

:::MySQL Korea:::
SHOW SLAVE STATUS 문은 UNTIL 조건의 현재 값들을 display하는 결과 필드들을 포함한다.
MySQL의 이전버전(4.0.5 이전)에서는, 이 문장은 SLAVE START로 호출되었다. 이 사용은 하위 호환성을 위해

MySQL 5.0에서도 여전히 받아 들이지만 무시 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.6.2.9. STOP SLAVE
13. SQL 문법(SQL Statement Syntax) STOP SLAVE [thread_type [, thread_type] ... ]

thread_type: IO_THREAD | SQL_THREAD
slave 쓰레드들을 중지한다. STOP SLAVE는 super 권한을 요구한다.
13.6.2.7 SHOW SLAVE STATUS START SLAVE처럼, 이 문장은 중지 되어야 할 쓰레드들을을 명명하기 위해 IO_THREAD와 SQL_THREAD 옵션들과
함께 사용될 수 있다.
13.6.2.9 STOP SLAVE
MySQL이전 버전(4.0.5이전)에서 이 문장은 SLAVE STOP를 호출한다. 이 사용은 하위 호환성을 위해 받아들여지나 사

용되지는 않는다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 13.7. Prepared 문을 위한 SQL 신텍스
13.7. Prepared 문을 위한 SQL 신텍스 MySQL 5.0은 서버 측에서 준비된 SQL문들을 제공한다. 이 제공은 MySQL4.1에서 구현된 효과적인 client/server 바이너리 프
13.7 Prepared 문을 위한 SQL 신텍스 로토콜의 이점을 이용하여 적절한 client 프로그래밍 인터페이스를 사용한다. 인터페이스는 MySQL C API client 라이브러리(C
프로그램용), MySQL Connector/J (Java 프로그램용) , MySQL Connector/Net.을 포함한다. 예를 들면 C API는 그 준비된 문
장 API 만든 함수 호출 집합을 제공한다. 22.2.4장 “C API Prepared Statements”부분을 참조하라. 다른 언어 인터페이스는 C
클라이언트 라이브러리 안에 링크(link)하여 바이너리 프로토콜을 사용하는 준비된 문장들에 대한 제공을 지원할 수 있다.
준비된 문들(prepared statements)에 대한 다른 대안적인 SQL 인터페이스가 가능하다. 이 인터페이스는 하나의 prepared
statement API를 통해 바이너리 프로토콜을 사용하는 것만큼 효과적 이지만 그것이 SQL 레벨에서 직접 가능한 것이기 때문에 프
로그래밍을 필요로 하지 않는다.:
• 여러분은 프로그래밍 인터페이스가 여러분에게 불가능할 때 이것을 사용할 수 있다.
• 여러분은 mysql 클라이언트 프로그램과 같이 server로 하여금 실행 되도록 하는 SQL 문들을 보낼 수 있도록 하는 어떤 프로
그램으로부터도 이것을 사용할 수 있다.
• 여러분은client가 client라이브러리의 이전 버전을 이용한다 해도 이것을 사용할 수 있다. 단지 요구되는 것은 여러분이

prepared statement들을 위해 SQL문을 제공하기에 충분한 server에 연결하도록 하는 것이다.
Prepared statements를 위한 SQL 문법은 다음과 같은 상황을 위해 사용 되어질 수 있다:

:::MySQL Korea:::
• 여러분은 이것을 코딩하기 전에 여러분의 응용 프로그램에서 prepared statement가 어떻게 작용하는지를 테스트하길 원한
다.
• 한 응용프로그램은 prepared statement를 실행 하는데 문제를 가지고 있고 여러분은 문제가 무엇인지 상호작용으로 결정하
기 원한다.
• Prepared statement를 가진 문제를 기술하는 테스트 경우를 생성하기 위해 여러분은 bug 리포트를 정리할 수 있다.
• 여러분은 prepared statements를 사용하길 필요로 하지만 그들을 지원하기 위해 프로그래밍 API에 대해 접근을 갖지 않는
다.
Prepared statements에 대한 SQL문법은 다음 세개의 SQL문들에 기반을 둔다.
• PREPARE stmt_name FROM preparable_stmt

PREPARE 문은 한 문장을 준비하고 후에 그 문장을 참조 하기 위해, 그것에 이름을 stmt_name으로 할당한다. 문장 이름은 대소
문자 구분을 하지 않는다. Preparable_stmt는 문장의 텍스트를 포함하는 문자열이거나 사용자 변수이다. 텍스트는 여러 개의 문장
들이 아닌, 하나의 SQL문을 대표해야 한다. 그 문장 안에서 ‘?’문자는 데이터 값들이 여러분이 그것을 나중에 실행 시킬 때 쿼리
에 속한 데이터 값들이 어디에 있는지를 지정하는 파라미터 표시자(marker)로서 사용될 수 있다. ‘?’ 문들은 여러분이 그것들
을 문자열 값에 묶으려 할 때 에도 인용 부호 안에 있을 수 없다. 파라미터 표시자들은 SQL 키워드들, 지정자 등을 위해서가 아니
라 데이터 값들이 나타나는 곳 에서만 사용될 수 있다.
주어진 이름과 함께 prepared 문이 존재하면, 새로운 문장이 준비되기 전에할당이 해제 된다. 이것은 만약 새로운 문장이 하나의
에러를 포함하고 준비될 수 없다면 에러가 리턴되고 주어진 이름으로 문장은 존재하지 않는다.
Prepared 문의 영역은 그것이 생성된 client세션이다. 다른 client들은 그것을 볼 수 없다.
• EXECUTE stmt_name [USING @var_name [, @var_name] ...]

:::MySQL Korea:::
한 문장을 준비한 후, 여러분은 그 준비된 문장 이름을 참조하는 EXECUTE 문과 함께 그것을 실행한다. 만일 준비된 문이 파라미
터 표시자를 가진다면 여러분은 파라미터들에 종속된 값들을 포함하는 사용자 변수들을 나열한 USING절을 제공해야 한다. 파라미
터 값들은 사용자 변수들에 의해 제공될 수 있으며, USING절은 그 문에서 파라미터 표시자들의 수만큼 많은 변수들을 정확하게 명
명해야만 한다.
여러분은 여러 차례에 걸쳐 주어진 준비된 문장을 실행 할 수 있으며 그것에 다른 변수들을 전달하거나 각각의 실행 이전에 다른 값
들을 변수들에 설정한다.
• {DEALLOCATE | DROP} PREPARE stmt_name

준비된 문장을 해제 하려면 DEALLOCATE PREPARE 문을 사용한다. 그것을 해제한 후 준비된 문장을 실행하려 한다면 에러를
리턴한다.
여러분이 이전에 준비된 문장을 해제하지 않은채 client 세션을 종료한다면 서버는 그것을 자동으로 해제 한다.
다음 SQL문들은 준비된 문들에서 사용될 수 있다: CREATE TABLE, DELETE, DO, INSERT, REPLACE, SELECT, SET,
UPDATE, 그리고 대부분의 SHOW 문장들. ANALYZE TABLE, OPTIMIZE TABLE, 그리고REPAIR TABLE 문은 MySQL
5.0.22에서부터 제공된다. 다른 문들은 아직 제공되지 않는다.
다음 예문들은 삼각형의 두 길이를 이용하여 빗변의 길이를 계산하는 한 문을 준비하기 위한 두개의 동일한 방법을 보여준다.
첫번째 예는 그 문의 텍스트를 제공하기 위해 문자열을 이용하여 준비된 문을 생성하는 방법을 보여준다:
mysql> PREPARE stmt1 FROM 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';
mysql> SET @a = 3;
mysql> SET @b = 4;
mysql> EXECUTE stmt1 USING @a, @b;

:::MySQL Korea:::
+------------+
| hypotenuse |
+------------+
| 5|
+------------+
mysql> DEALLOCATE PREPARE stmt1;
두 번째 예는 유사하지만 문장의 텍스트를 사용자 변수로서 제공한다:
mysql> SET @s = 'SELECT SQRT(POW(?,2) + POW(?,2)) AS hypotenuse';
mysql> PREPARE stmt2 FROM @s;
mysql> SET @a = 6;
mysql> SET @b = 8;
mysql> EXECUTE stmt2 USING @a, @b;
+------------+
| hypotenuse |
+------------+
| 10 |

:::MySQL Korea:::
+------------+
mysql> DEALLOCATE PREPARE stmt2;
MySQL 5.0.7에서부터, placeholder들은 준비된 문을 사용할 때 LIMIT절의 인자로 사용될 수 있다. 13.2.7장 “SELECT”을 참
조하라.
준비된 문을 위한SQL 문법은 중첩 방식(nested fashion)안에서 사용될수 없다. 즉, PREPARE에 전달된 문은 PREPARE,
EXCUTE 혹은 DEALOCATE PREPARE 문이 될 수 없다.
준비된 문들을 위한 SQL문법은 준비된 문 API 호출의 사용과는 다르다. 예를 들면 여러분은 PREPARE,EXCUTE,혹은
DEALLOCATE PRPARE문을 준비하기 위해 mysql_stmt_prepare() C API 함수를 사용할 수 없다.
준비된 문장들을 위한 SQL문법은 저장된 루틴 안이나 트리거들에서 사용될 수 없다. 이 제약은 저장 프로시져를 위해 MySQL
5.0.13에서도 유지되지만 저장 함수나 트리거에서는 적용되지 않는다.
준비된 문을 위한 SQL문법은 다중 문을 지원하지 않는다(즉, 한 문자열에 다중 문은 ‘;’문자로 구분된다.)

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 17. 스토어드 프로시저와 함수

17.1. 스토어드 루틴 및 그랜트 테이블
17. 스토어드 프로시저와 함수 17.2. 스토어드 프로시저 신텍스
17 스토어드 프로시저와 함수 17.2.1. CREATE PROCEDURE 및 CREATE FUNCTION 신텍스
17.1 스토어드 루틴과 그랜트 테이블 17.2.2. ALTER PROCEDURE 및 ALTER FUNCTION 신텍스
17.2 스토어드 프로시저 신텍스 17.2.3. DROP PROCEDURE 및 DROP FUNCTION 신텍스
17.2.1 CREATE PROCEDURE 와 CREATE FUNCTION 신텍스 17.2.4. SHOW CREATE PROCEDURE 및 SHOW CREATE FUNCTION 신텍스
17.2.5. SHOW PROCEDURE STATUS 및 SHOW FUNCTION STATUS 신텍스
17.2.2 ALTER PROCEDURE 및 ALTER FUNCTION 신텍스
17.2.6. CALL 명령문 신텍스
17.2.3 DROP PROCEDURE 및 DROP FUNCTION 신텍스
17.2.7. BEGIN ... END 복합 명령문 신텍스
17.2.4 CALL 명령문 신텍스
17.2.8. DECLARE 명령문 신텍스
17.2.5 BEGIN ..
17.2.9. 스토어드 루틴내의 변수
17.2.6 DECLARE 명령문 신텍스
17.2.10. 조건문 및 핸들러
17.2.7 스토어드 루틴내의 변수
17.2.11. 커서
17.2.7.1 DECLARE 로컬 변수 17.2.12. 제어 구성 요소 흐름
17.2.7.2 변수 SET 명령문 17.3. 스토어드 프로시저, 함수, 트리거, 및 리플리케이션: FAQ
17.2.7.3 SELECT .. 17.4. 스토어드 루틴 및 트리거의 바이너리 로깅
17.2.8 조건문 및 핸들러
17.2.8.1 DECLARE 조건문 MySQL 5.0은 루틴 (프로시저 및 함수)을 지원한다. 스토어드 프로시저란 서버 내에 저장할 수 있는 SQL 명령문
17.2.8.2 DECLARE 핸들러 의 조합을 의미한다. 일단 이것을 실행하면, 클라이언트는 개별 명령문을 다시 불러들이는 대신에 이 스토어드 프
17.2.9 커서(Cursors) 로시저를 참조하기만 하면 된다.
17.2.9.1 Cursors 선언하기 스토어드 루틴이 유용하게 사용되는 경우를 보면:
17.2.9.2 Cursor OPEN 명령문

● 다중의 클라이언트 애플리케이션이 서로 다른 언어로 쓰여진 경우, 또는 서로 다른 플랫폼에서 수행되어
17.2.9.3 Cursor FETCH 명령문
지는 경우에라도 동일한 데이터 베이스 기능을 수행해야 할 경우.
17.2.9.4 Cursor CLOSE 명령문
● 보안이 최우선 과제일 경우. 예를 들어, 은행에서는 스토어드 프로시저 및 함수를 모든 일반 기능에 적용

:::MySQL Korea:::
17.2.10 플로우 컨트롤(Flow Control) 구성 할 수 있다. 이를 통해 은행은 업무의 일관성 및 안전한 데이터 베이스 환경을 보장 받게 되며, 또한 루틴
17.2.10.1 IF 명령문 은 각 기능이 적절하게 등록되어짐을 보장하게 된다. 이러한 설정 내에서, 애플리케이션 및 사용자는 데이
17.2.10.2 CASE 명령문 터 베이스 테이블에 직접 접근하는 대신에 특정 스토어드 루틴만을 실행할 수 있게 된다.
17.2.10.3 LOOP 명령문

스토어드 루틴은 서버와 클라이언트간에 최소한의 정보만을 주고 받기 때문에 성능 향상을 제공 한다. 트레이드오
17.2.10.4 LEAVE 명령문
프(tradeoff)는 클라이언트 (애플리케이션)상에서 진행되는 업무량 보다 서버에서 진행되는 업무량이 많기 때문
17.2.10.5 ITERATE 명령문
에 데이터 베이스 서버상의 업무량을 증가시키는 것을 의미한다. 웹 서버와 같은 많은 클라이언트 장비가 단지 한
17.2.10.6 REPEAT 명령문
개 또는 적은 수의 데이터 베이스와 같이 업무를 진행한다고 가정해 보라.
17.2.10.7 WHILE 명령문
또한, 스토어드 루틴은 데이터 베이스 서버 내에 함수 라이브러리를 가질 수 있게 한다. 이 기능은 대부분의 현대적
17.3 스토어드 프로시저, 함수, 트리거, 및 리플리케이션 : FAQ 인 애플리케이션 언어가 공유하는 기능이다. 이러한 클라이언트 애플리케이션 언어의 특성을 사용하는 것은 데이
17.4 스토어드 루틴 및 트리거의 바이너리 로깅 터 베이스 영역을 벗어나 있는 프로그래머일 지라도 매우 유용하게 사용할 수 있는 기능이다.
MySQL은 스토어드 루틴에 대해 SQL:2003 신텍스를 준수하며, IBM의 DB2도 위의 신텍스를 동일하게 준수하
고 있다.
MySQL은 스토어드 루틴에 대해 계속 완성도를 높여가는 중이다. 이 장에서 언급하는 모든 신텍스는 계속 보완될
것이며, 어떠한 제약 사항 및 확장되는 내용은 적정한 곳에 문서화를 할 예정이다. 스토어드 루틴의 사용에 대한 보
다 자세한 제약 사항은 Section I.1, “스토어드 루틴 및 트리거상의 제약 사항” 에서 다루기로 한다.
스토어드 루틴에 대한 바이너리 로깅은 Section 17.4, “스토어드 루틴 및 트리거의 바이너리 로깅” 에서 다루기
로 한다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.1. 스토어드 루틴과 그랜트 테이블

스토어드 루틴은 mysql 데이터 베이스 안에 proc 테이블을 필요로 한다. 이 테이블은 MySQL 5.0이 설치되는 동안 생성된다. 만
17. 스토어드 프로시저와 함수 일 이전 버전을 5.0으로 업그레이드 할 경우라면, proc 테이블이 존재하도록 그랜트 테이블을 업그레이드 해야 함을 유의한다.
17.1. 스토어드 루틴과 그랜트 테이블 Section 5.6, “mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드” 를 참조.
17.1 스토어드 루틴과 그랜트 테이블 서버는 생성(create), 변경(alter), 또는 드롭(drop) 스토어드 루틴을 실행하는 명령문을 통해 mysql.proc테이블을 작성한다. 하
지만, 서버가 이 테이블의 수동 동작을 요청할 경우에는 지원하지 않는다.
MySQL 5.0.3 이후에는, 그랜트 시스템은 아래와 같이 스토어드 루틴을 계정 내에 포함시키게 된다:
● 스토어드 루틴을 생성하기 위해서는 CREATE ROUTINE 권한이 필요함

● 스토어드 루틴을 변경(alter) 또는 드롭(drop)하기 위해서는 ALTER ROUTINE 권한이 필요함.
● 스토어드 루틴을 실행하기 위해서는 EXECUTE 권한이 필요함. 하지만, 이 권한은 루틴의 생성자에게 자동으로 승인된다.
또한, 루틴에 대한 SQL SECURITY 특성은 DEFINER 이며, 이것은 해당 루틴을 실행하는데 연관된 루틴이 있는 데이터
베이스에 접근 권한이 있는 사용자를 활성화 시키게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2. 스토어드 프로시저 신텍스

17.2.1. CREATE PROCEDURE 와CREATE FUNCTION 신텍스
17. 스토어드 프로시저와 함수 17.2.2. ALTER PROCEDURE 와 ALTER FUNCTION 신텍스
17.2. 스토어드 프로시저 신텍스 17.2.3. DROP PROCEDURE 와 DROP FUNCTION 신텍스
17.2 스토어드 프로시저 신텍스 17.2.4. SHOW CREATE PROCEDURE 와 SHOW CREATE FUNCTION 신텍스
17.2.1 CREATE PROCEDURE 와 CREATE FUNCTION 신텍스 17.2.5. SHOW PROCEDURE STATUS 와 SHOW FUNCTION STATUS 신텍스
17.2.2 ALTER PROCEDURE 및 ALTER FUNCTION 신텍스 17.2.6. CALL 명령문 신텍스
17.2.3 DROP PROCEDURE 및 DROP FUNCTION 신텍스 17.2.7. BEGIN ... END 복합 명령문 신텍스
17.2.8. DECLARE 명령문 신텍스
17.2.4 CALL 명령문 신텍스
17.2.9. 스토어드 루틴내의 변수
17.2.5 BEGIN ..
17.2.10. 조건문과 핸들러
17.2.6 DECLARE 명령문 신텍스
17.2.11. 커서
17.2.12. 플로우 컨트롤(Flow Control) 구성
17.2.7.1 DECLARE 로컬 변수
17.2.7.2 변수 SET 명령문
하나의 스토어드 루틴은 프로시저거나 함수다. 스토어드 루틴은 CREATE PROCEDURE 와 CREATE
17.2.7.3 SELECT ..
FUNCTION 명령문을 가지고 생성된다. 하나의 프로시저는 하나의CALL 명령문으로 호출 되어지며, 결과 변수
17.2.8 조건문 및 핸들러 를 통해서만 외부로 값을 전달하게 된다. 함수는 다른 함수들과 마찬가지로(즉, 함수 이름을 호출 함으로서) 내부
17.2.8.1 DECLARE 조건문 명령문이 호출할 수 있으며, 스칼라 값을 돌려줄 수 있다. 스토어드 루틴은 다른 스토어드 루틴을 호출할 수도 있
17.2.8.2 DECLARE 핸들러 다. MySQL 5.0.1 이후에는, 스토어드 루틴 또는 함수는 특정 데이터 베이스와 연관 되어 지는데, 여기에 몇 가지
17.2.9 커서(Cursors) 임플리시트(implicit) 요소를 설명한다:
17.2.9.1 Cursors 선언하기
17.2.9.2 Cursor OPEN 명령문 ● 루틴이 호출되면, 하나의 임플리시트(implicit) USE db_name 이 실행된다(그리고 루틴이 종료되면 마
침). 스토어드 루틴내의 USE 명령문은 허용되지 않음.
● 데이터 베이스 이름으로 루틴 이름을 검증할 수 있다. 이것은 현재의 데이터 베이스 내에는 없는 루틴을 언
급하기 위해 사용될 수도 있다. 예를 들면, test 데이터 베이스와 관련된 스토어드 프로시저 p 또는 함수 f
17.2.10 플로우 컨트롤(Flow Control) 구성
를 호출하기 위해서는, CALL test.p() or test.f() 를 입력하면 된다 .

:::MySQL Korea:::
17.2.10.1 IF 명령문 ● 데이터 베이스가 드롭되는 경우에는, 이에 연관된 모든 스토어드 루틴도 같이 드롭된다.
17.2.10.2 CASE 명령문

(MySQL 5.0.0 에서는, 스토어드 루틴은 글로벌이며 데이터 베이스와는 연관이 없다. 스토어드 루틴은 호출자로
17.2.10.3 LOOP 명령문
부터 디폴트 데이터 베이스를 부여 받게 된다. 만일 USE db_name 이 루틴 내에서 실행된다면, 원래의 디폴트 데
이터 베이스는 루틴의 exit위에 재저장되게 된다..)
MySQL 은 스토어드 프로시저 내부에서 레귤러 SELECT 명령문(즉, 커서 또는 로컬 변수를 사용하지 않는)을 사
용할 수 있게 하는 매우 유용한 확장자를 지원한다. 이러한 쿼리의 결과 셋은 간단하게 클라이언트에 직접 전달된
다. 다중 SELECT 명령문은 다중 결과 셋을 만들며, 따라서 클라이언트는 반드시 다중 결과 셋을 지원하는
MySQL 클라이언트 라이브러리를 사용해야 한다. 이것은 클라리언트는 반드시 버전 4.1 이상의 최신 버전
MySQL 라이브러리를 사용해야 함을 의미한다. 클라이언트는 또한 이것이 연결될 때 CLIENT_MULTI_명령문
옵션을 지정해야 한다. C 프로그램의 경우, mysql_real_connect() C API 기능으로 처리할 수 있다.
(Section 22.2.3.51, “mysql_real_connect()” 참조).
이후의 섹션에서는 create, alter, drop, 및 스토어드 프로시저와 함수를 사용하는 신텍스에 대해 기술하도록 하겠
다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.1. CREATE PROCEDURE 와 CREATE FUNCTION 신텍스
17. 스토어드 프로시저와 함수 CREATE PROCEDURE sp_name ([proc_parameter[,...]])

17.2. 스토어드 프로시저 신텍스
17.2.1 CREATE PROCEDURE 와 CREATE [characteristic ...] routine_body
FUNCTION 신텍스
CREATE FUNCTION sp_name ([func_parameter[,...]])
RETURNS type
[characteristic ...] routine_body
proc_parameter:
[ IN | OUT | INOUT ] param_name type
func_parameter:
param_name type
type:
Any valid MySQL data type
characteristic:

:::MySQL Korea:::
LANGUAGE SQL
| [NOT] DETERMINISTIC
| { CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
| SQL SECURITY { DEFINER | INVOKER }
| COMMENT 'string'
routine_body:
Valid SQL procedure statement
이 명령문들은 스토어드 루틴을 생성한다. MySQL 5.0.3에서 보면, 이러한 명령문을 사용하기 위해서는, CREATE ROUTINE 에
대한 권한이 필요하게 된다. 만일 바이너리 로깅이 가능하다면, 이러한 명령문들은 SUPER 권한을 요청할 수도 있게 되는데, 이점
에 대해서는 Section 17.4, “스토어드 루틴 및 트리거에 바이너리로 로깅” 에서 언급하였다. MySQL은 자동으로 ALTER
ROUTINE 과 EXECUTE 권한을 루틴 생성자에게 부여한다.
루틴은 디폴트 데이터 베이스와 디폴트로 연결된다. 주어진 데이터
베이스와 루틴을 연결하기 위해서는, 루틴을 생성할 때 db_name.sp_name 과 같이 이름을 명확히 지정해야 한다.
만일 루틴의 이름이 SQL 함수 내부에 있는 이름과 일치하게 되면, 루틴을 정의할 때 이름과 따라오는 괄호 사이에 스페이스를 사
용해야 신텍스 에러를 피할 수 있다. 이것은 또한 나중에 루틴을 호출할 때에도 적용된다. 이러한 이유로 인해, 작성하는 스토어드
루틴에 대해서는 SQL내부의 함수 이름을 사용하지 말 것을 권장한다.
IGNORE_SPACE SQL 모드는 내부에 탑재된 함수에 적용되며, 스토어드 루틴에는 적용되지 않는다. IGNORE_SPACE의 활성화
에 상관 없이 루틴의 이름 후에 스페이스를 사용하는 것은 언제든지 가능하다.
괄호 안에는 파라미터 리스트가 반드시 항상 존재해야 한다. 만일 파라이터가 없으면, ()의 빈 파라미터가 쓰이게 된다. 각 파라미
터는 디폴트로 IN 파라미터가 된다. 파라미터에 다른 것을 지정하고자 할 경우에는, 파라미터 이름 앞에 키워드 OUT 또는 INOUT

:::MySQL Korea:::
를 사용하면 된다.
노트 : Specifying a parameter as IN, OUT, 또는 INOUT으로 파라미터를 지정할 경우는 PROCEDURE에 대해서만 가능하다.
(FUNCTION 파라미터는 항상 IN 파라미터로 간주된다.)
각 파라미터는 모든 가능한 데이터 타입을 사용하기 위해 선언될 수 있으나, COLLATE 속성은 사용할 수 없다.
RETURNS 구문은 FUNCTION 에 대해서만 명기할 수도 있는데, 이것이 필수적인 경우에만 해당된다. 이러한 경우, RETURN 구
문은 함수의 리턴 타입을 지정하며, 함수에는 반드시 RETURN value 명령문이 있어야 한다.
routine_body 는 유용한 SQL 프로시저 명령문으로 구성된다. 이것은 단순히 SELECT 또는 INSERT가 될 수도 있으며, 또는
BEGIN 과 END로 구성된 복합 명령문이 될 수도 있다. 복합 명령문 신텍스는 Section 17.2.7, “BEGIN ... END 복합 명령문 신
텍스”.에서 다루기로 한다. 복합 명령문은 선언문, 루프 및 다른 제어 구조 명령문을 포함할 수 있다. 이러한 명령문에 대한 신텍스
는 나중에 다루기로 다루기로 한다. 예를 들어, Section 17.2.8, “DECLARE 명령문 신텍스”, 및 Section 17.2.12, “Flow
Control Constructs”를 참조 하면 된다.
MySQL의 이전 버전에서 UDF(user-defined functions)를 지원하기 위해서 CREATE FUNCTION 명령문을 사용했다.
Section 24.2, “MySQL에 새로운 함수 추가”를 참조. UDF는 스토어드 함수가 지원되는 현 버전에도 계속 사용 가능하며, 이때
UDF는 외부 스토어드 함수로 간주된다. 하지만, 스토어드 함수는 UDF와 함께 자신의 이름 공간(namespace)를 공유한다는 점을
유의한다.
하나의 프로시저 또는 함수는 동일 입력 파라미터에 대해 항상 같은 결과를 만들어 낼 경우에는 “확정적(deterministic)”로 간주

되며, 그렇지 않을 경우에는 “비확정적(not deterministic)”으로 간주된다. 루틴 정의에서 DETERMINISTIC 또는 NOT
DETERMINISTIC 이 정해지지 않을 경우, 디폴트는 NOT DETERMINISTIC 이 된다.
리플리케이션을 위해서는, 비확정적 루틴을 만들기 위해서NOW() 함수 (또는 동의어) 또는 RAND() 함수를 사용할 필요는 없
다. NOW() 함수를 위해서는, 바이너리 로그가 타임 스탬프(timestamp) 및 복사본을 정확히 포함한다. RAND() 함수 또한 루틴
내에서 한번 호출 되어지면 정확히 복사본을 포함하게 된다. (루틴 실행 타임스탬프 및 랜덤 숫자 시드(random number seed)를
마스터 및 슬레이브에서 동일하게 여겨지는 임플리시트(implicit) 입력치로 생각할 수 있다)
현재의 버전에서는, DETERMINISTIC 특성은 사용 가능하지만, 옵티마이져에 의한 사용은 아직 불가능하다. 하지만, 바이너리 로

:::MySQL Korea:::
깅이 가능할 경우에는, 이러한 특성은 MySQL이 수용하는 루틴 정의에 영향을 미치게 된다. Section 17.4, “스토어드 루틴 및 트
리거에 대한 바이너리 로깅” 참조.
몇몇 특성들은 루틴이 사용하는 데이터의 속성에 대한 정보를 제공한다. CONTAINS SQL 은 데이터를 읽거나 쓰는 명령문을 갖
지 않는 루틴을 의미 한다. NO SQL 은 아무런 SQL명령문이 없는 루틴을 나타낸다. READS SQL DATA 은 데이터를 읽기는 하
지만 쓰지는 않는 명령문을 갖는 루틴을 표시하며, MODIFIES SQL DATA 는 데이터를 쓸 수도 있는 명령문을 갖는 루틴을 나타
낸다. CONTAINS SQL 은 확정적으로 이러한 특성이 주어지지 않았을 경우 디폴트가 된다. 이런 특성들은 단지 권고 사항일 뿐이
다. 데이터 베이스 서버는 이러한 명령문들을 루틴이 실행될 수 있는 명령문의 종류를 한정하는데 시용하지는 않는다.
SQL SECURITY 특성은 루틴을 실행하는 권한이 있는 사용자가 루틴의 생성자인지 아니면 루틴을 호출한 사용자인지를 명기할
때 사용될 수 있다. 디폴트 값은 DEFINER이다. 이러한 특성은 SQL:2003에 새롭게 추가된 것이다. 생성자 또는 호출자는 반드시
해당 루틴과 연관되어 있는 데이터 베이스에 접근할 수 있는 권한이 있어야 한다. MySQL 5.0.3버전에서는, 루틴을 실행하기 위해
서는 EXECUTE 권한이 필요하다. 이 권한을 가져야만 하는 사용자는 루틴 정의자 또는 호출자중 하나이어야 하고, 이것은 SQL
SECURITY특성이 어떻게 셋팅 되어지는지에 따라서 결정된다.
MySQL은 루틴이 생성될 때, 그리고 이 셋팅 값을 갖는 루틴이 제대로 실행될 때에는 언제나 유효한 sql_mode 시스템 변수 셋팅
값을 저장한다.
루틴이 호출되면, 임플리시트(implicit) USE db_name 이 실행된다(그리고 루틴이 종료되면 이것도 종료됨). 스토어드 루틴 안에
있는 USE 명령문은 사용할 수 없다.
MySQL 5.0.18까지는, 루틴 파라미터의 데이터 타입 또는 함수의 리턴 값을 아래와 같이 사용한다. 이 법칙은 DECLARE명령문

을 갖는 로컬 루틴 변수에도 동일하게 적용된다. (Section 17.2.9.1, “DECLARE 로컬 변수”) 참조.
● 할당(Assignments)은 데이터 타입이 일치하지 않고 오버 플로우가 발생하는지를 체크함. 컨버젼(Conversion) 및 오버

플로우 문제는 시스템 경고 또는 스트릭트 모드(strict mode)에서 에러의 원인이 됨.
● 데이터 타입의 문자에 대해서는, 만일 정의문안에 CHARACTER SET 구문이 있다면, 명기된 문자 셋 및 그 디폴트 값이
사용된다. 만일, 그러한 구문이 없는 경우에는, 데이터 베이스 문자 셋 및 정의문(collation)이 사용된다.
(character_set_database 및 collation_database 시스템 변수의 값에서 이것을 제공함.)
● 스칼라값만이 파라미터 또는 변수로 할당될 수 있다. 예를 들면, SET x = (SELECT 1, 2) 와 같은 명령문은 사용될 수 없
다.

:::MySQL Korea:::
MySQL 5.0.18 이전에는, 파라미터, 리턴값, 그리고 로컬 변수는 프로그래밍 식(expression)에 있는 아이템으로 간주되었고, 또
한 자동(silent)변환 및 자동 잘림(truncation)의 대상으로 간주되었다. 스토어드 함수는 sql_mode 셋팅을 무시한다.
COMMENT 구문은 MySQL의 확장자이며, 스토어드 루틴을 설명할 때 사용할 수 있다. 이러한 정보는 SHOW CREATE
PROCEDURE 및 SHOW CREATE FUNCTION 명령문으로 볼 수 있다.
MySQL 은 루틴이 CREATE 및 DROP과 같은 DDL명령문을 포함할 수 있도록 한다. 또한, MySQL은 스토어드 프로시저(스토어
드 함수가 아님) 가 COMMIT과 같은 SQL 트랜젝션을 갖는 것을 허용한다. 스토어드 함수는 익스플리시트(explicit) 또는 임플리
시트(implicit) 커밋(commit) 또는 롤백(rollback)을 수행하는 명령문을 포함할 수 없다. 이런 명령문을 지원하는 것은 SQL표준
안의 요구 사항이 아니며, 각 DBMS업체의 선택에 달려 있다.
스토어드 루틴은 LOAD DATA INFILE를 사용할 수 없다.
결과 셋을 리턴하는 명령문은 스토어드 함수 내에서는 사용할 수 없다. 이러한 것에는 컬럼 값을 변수 안으로 인출(fetch)하기 위
한 INTO를 사용하지 않는 SELECT 명령문, SHOW명령문, 그리고 EXPLAIN과 같은 명령문 등이 해당된다. 결과 셋을 리턴하는
함수 정의 시점을 결정할 수 있는 명령문에 대해서는, ‘ Not allowed to return a result set from a function
error’ (ER_SP_NO_RETSET_IN_FUNC)가 발생한다. 결과 셋을 리턴하기 위해 런타임만을 결정하는 명령문에 대해서는, ‘
PROCEDURE %s can't return a result set in the given context error’ (ER_SP_BADSELECT)가 발생한다.
Note: MySQL 5.0.10이전에는, CREATE FUNCTION 과 함께 생성된 스토어드 프로시저는 제한적인 예외 사항이 있기는 하지
만 테이블에 대한 참조를 가질 수 없었다. 이러한 스토어드 프로시저는 테이블 참조를 갖는 SET과 같은 명령문을 포함할 수 있는
데, 예를 들면 SET a:= (SELECT MAX(id) FROM t) 이며, 또한 값을 직접 변수 안으로 집어 넣는 SELECT 명령문, 예를 들면
SELECT i INTO var1 FROM t이 될 수 있다.
아래의 것은OUT 파라미터를 갖고 있는 단순한 스토어드 프로시저의 경우에 해당하는 예문이다. 이 예문은 mysql 클라이언트
delimiter 명령어를 사용해서 프로시저가 정의되는 동안 구분자를 ; 로부터 //로 변경하는 것을 나타낸다. 이것은 프로시저 몸체에
서 사용되어진 ; 구분 문자가 mysql 자체에서 해석되지 않고 서버로 전달될 수 있도록 하게 해준다.
mysql> delimiter //

:::MySQL Korea:::
mysql> CREATE PROCEDURE simpleproc (OUT param1 INT)
-> BEGIN
-> SELECT COUNT(*) INTO param1 FROM t;
-> END;
-> //
mysql> delimiter ;
mysql> CALL simpleproc(@a);
mysql> SELECT @a;
+------+
| @a |
+------+

:::MySQL Korea:::
|3 |
+------+
delimiter 명령어를 사용할 때에는, 백슬레쉬(‘￦’)를 사용하면 안 되는데, 이 문자는 MySQL에서는 escape문자로 사용되기 때
문이다
아래의 문장은 파라미터를 가져오고, SQL함수를 사용해서 동작을 하고, 결과치를 리턴하는 함수의 예문이다. 이 경우, delimiter
를 사용할 필요가 없는데, 함수 정의는 내부 ; 명령문 구분 문자를 갖고 있지 않기 때문이다:
mysql> CREATE FUNCTION hello (s CHAR(20)) RETURNS CHAR(50)
-> RETURN CONCAT('Hello, ',s,'!');
mysql> SELECT hello('world');
+----------------+
| hello('world') |
+----------------+
| Hello, world! |
+----------------+

:::MySQL Korea:::
스토어드 함수는 RETURNS 구문에서 명기한 데이터의 타입 값을 리턴한다. 만일, RETURN 명령문이 다른 타입의 값을 리턴할
경우에는, 올바른 타입으로 치환된다. 예를 들면, 함수가 ENUM 또는 SET 값을 리턴한다 하더라도, RETURN 명령문은 정수 값
을 리턴하게 되며, 함수로부터 리턴된 값은 SET 멤버의 셋의 ENUM멤버에 상응하는 스트링이 된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.2. ALTER PROCEDURE 및 ALTER FUNCTION 신텍스
17. 스토어드 프로시저와 함수 ALTER {PROCEDURE | FUNCTION} sp_name [characteristic ...]

17.2.2 ALTER PROCEDURE 및 ALTER characteristic:
FUNCTION 신텍스
{ CONTAINS SQL | NO SQL | READS SQL DATA | MODIFIES SQL DATA }
| SQL SECURITY { DEFINER | INVOKER }
| COMMENT 'string'
이 명령문은 스토어드 프로지서 또는 함수의 특성을 변경하고자 할 때 사용할 수 있다. MySQL 5.0.3의 경우, 루틴에 대해서
ALTER ROUTINE 권한이 있어야 한다. (이 권한은 루틴 생성자에게 자동으로 제공된다.) 만일, 바이너리 로깅이 활성화 되어지
면, 이 명령문은 SUPER권한도 동시에 요청하게 되는데, 이 사항에 대해서는Section 17.4, “스토어드 루틴 과 트리거에 대한 바
이너리 로깅”을 참조하면 된다.
ALTER PROCEDURE 또는 ALTER FUNCTION 명령문에는 하나 이상의 변경을 명기할 수 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.3. DROP PROCEDURE 및 DROP FUNCTION 신텍스
17. 스토어드 프로시저와 함수 DROP {PROCEDURE | FUNCTION} [IF EXISTS] sp_name

17.2.3 DROP PROCEDURE 및 DROP 이 명령문은 스토어드 프로시저 또는 함수를 드롭 하기 위해 사용된다. 즉, 명기된 루틴이 서버로부터 제거된다. MySQL 5.0.3의
FUNCTION 신텍스 경우, 루틴에 대한 ALTER ROUTINE 권한이 있어야 한다. (이 권한은 루틴 생성자에게 자동으로 제공된다.) IF EXISTS 구문은
MySQL의 확장자며, 만일 프로시저 또는 함수가 존재하지 않을 경우 발생하는 에러를 방지해 주는 역할을 한다. 경고문은 SHOW
WARNINGS를 통해 볼 수 있다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.4. CALL 명령문 신텍스
17. 스토어드 프로시저와 함수 CALL sp_name([parameter[,...]])

17.2.4 CALL 명령문 신텍스 CALL 명령문은 CREATE PROCEDURE으로 정의된 프로시저를 호출한다.
CALL 명령문은 OUT 또는 INOUT파라미터로 선언한 파라미터를 사용해서 그것을 호출한 곳에 값을 되돌려 줄 수 있다. 또한, 이
것은 해당되는 열의 수를 “returns” 해 주는데, 이 열의 수는 ROW_COUNT()함수를 호출 함으로서 SQL 레벨에서 클라이언트
프로그램이 확보할 수 있는 수 이며, mysql_affected_rows() C API 함수를 호출해서 C로부터 확보할 수 있는 값이기도 하다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.5. BEGIN ... END 복합 명령문 신텍스
17. 스토어드 프로시저와 함수 [begin_label:] BEGIN

17.2.5 BEGIN .. [statement_list]
END [end_label]
BEGIN ... END 신텍스는 복합 명령문을 작성하기 위해 사용되는데, 이것은 스토어드 루틴 및 트리거 내에서도 나타날 수 있다 복
합 명령문은 BEGIN과 END키워드로 둘러싸인 다중 명령문을 포함할 수 있다. statement_list 는 하나 또는 그 이상의 명령문 리스
트를 나타낸다. statement_list 안에 있는 각 명령문은 반드시 세미콜론(;)명령문 구분 문자로 종료 되어야 한다. Note that
statement_list 는 옵션 사항임의 고려해야 하는데, 이것은 (BEGIN END)와 같은 빈 복합 명령문도 유효한 문장임을 의미하는 것
이다.
다중 명령문의 사용은 클라이언트가 ; 명령문 구분 문자를 갖는 명령문 스트링을 보낼 수 있음을 요구한다. 이것은 delimiter 명령
어를 갖는 mysql 커맨드-라인 클라이언트에서 다루어진다. Changing end-of-statement 구분자인 ; 를 변경 함으로서 (예를 들
면, // 로), ; 가 루틴 안에서도 사용될 수 있도록 할 수 있다. Section 17.2.1, “CREATE PROCEDURE 및 CREATE
FUNCTION 신텍스”에서 예시를 참조하기 바람.
복합 명령문은 레이블화 될 수 있다. end_label 은 begin_label 이 표시되지 않으면 사용할 수 없다. 만일 두 개 모두 표시되면, 이
들은 동일한 것이 되어야 한다.
옵션 [NOT] ATOMIC 구문은 아직은 지원하지 않는다. 이것은 어떠한 트랜잭셔널 세이브포인트(transactional savepoint)도 명
령문의 시작에서 설정되지 않으며 이 문장에서 사용되는 BEGIN 구문이 현재의 트랜잭션에 영향을 주지 않는다는 것을 의미한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.6. DECLARE 명령문 신텍스
17. 스토어드 프로시저와 함수 DECLARE 명령문은 다양한 로컬 아이템을 루틴에서 정의하는데 사용된다:
17.2.6 DECLARE 명령문 신텍스 ● 로컬 변수. Section 17.2.7, “스토어드 루틴내의 변수” 참조.
● Conditions 및 handlers. Section 17.2.8, “Conditions 및 Handlers” 참조.
● Cursors. Section 17.2.9, “Cursors” 참조.
SIGNAL 및 RESIGNAL 명령문은 현재 지원하지 않는다.
DECLARE 는 오로지 BEGIN ... END 복합 명령문 내에서만 사용할 수 있으며 다른 어떤 명령문보다 먼저 시작을 해야 한다.
선언문은 반드시 특정 순서를 따라야 한다. 커서(Cursors)는 핸들러를 선언하기 전에 선언되어야 하며, 또한 변수와 컨디션은 커
서 또는 핸들러가 선언되기 전에 선언되어야 한다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.7. 스토어드 루틴내의 변수

17.2.7.1. DECLARE 로컬 변수
17. 스토어드 프로시저와 함수 17.2.7.2. 변수 SET 명령문
17.2. 스토어드 프로시저 신텍스 17.2.7.3. SELECT ... INTO 명령문
17.2.7.1 DECLARE 로컬 변수 루틴안에 있는 변수를 선언하거나 사용할 수 있다.

17.2.7.3 SELECT ..
:::MySQL Korea:::
제목검색
17.2.7.1. DECLARE 로컬 변수
17. 스토어드 프로시저와 함수 DECLARE var_name[,...] type [DEFAULT value]

17.2.7 스토어드 루틴내의 변수 이 명령문은 로컬 변수를 선언하는데 사용된다. 변수에 디폴트 값을 제공하기 위해서는, DEFAULT 구문을 포함시킨다. 하나의 수
식으로 값을 명기할 수 있다; 이 값이 상수(constant)일 필요는 없다. 만일DEFAULT 구문을 빠트리게 되면, 초기 값은 NULL이
된다.
17.2.7.3 SELECT ..
로컬 변수는 데이터 타입과 오버 플로우 체킹에 관련하여 루틴의 파라미터처럼 취급된다. Section 17.2.1, “CREATE
PROCEDURE 및 CREATE FUNCTION 신텍스” 참조.
로컬 변수의 범위는 변수가 선언되는 곳의 BEGIN ... END 블록으로 제한된다. 변수는 선언된 블록 내에서 네스티드(nested)된 블
록 안에서도 참조될 수 있는데, 이러한 블록들이 동일한 이름을 갖는 변수를 선언할 경우는 제외된다.
:::MySQL Korea:::
제목검색
17.2.7.2. 변수 SET 명령문

17. 스토어드 프로시저와 함수 SET var_name = expr [, var_name = expr] ...

17.2.7 스토어드 루틴내의 변수 스토어드 루틴내의 SET 명령문은 일반적인 SET 명령문의 확장된 버전이다. 참조된 변수는 루틴 내에서 선언된 것이거나, 또는 글
로벌 시스템 변수가 선언한 것이 될 수도 있다.
스토어드 루틴내의SET 명령문은 이미 존재하는(the pre-existing) SET 신텍스의 일부분처럼 실행된다. 이것은 서로 다른 변수
17.2.7.3 SELECT ..
의 타입(로컬로 선언된 변수 및 글로벌 및 세션 서버의 변수)이 서로 섞이는 곳에서 SET a=x, b=y, ... 의 확장된 신텍스를 허용한
다. 이것은 또한 로컬 변수와 시스템 변수에만 해당하는 몇몇 옵션들을 조합하는 것을 허용한다; 이럴 경우, 옵션들은 인식은 되지
만 무시되어 버린다.
:::MySQL Korea:::
제목검색
17.2.7.3. SELECT ... INTO 명령문

17. 스토어드 프로시저와 함수 SELECT col_name[,...] INTO var_name[,...] table_expr

17.2.7 스토어드 루틴내의 변수 이와 같은 SELECT 신텍스는 선택한 컬럼을 변수에 직접 저장한다. 따라서, 오로지 단일 열(single row)만이 복구될 수도 있다.
SELECT id,data INTO x,y FROM test.t1 LIMIT 1;
17.2.7.3 SELECT ..
사용자 변수 이름은 대소문자 구분을 하지 않는다. Section 9.3, “사용자 지정 변수” 참조.
Important : SQL 변수 이름은 컬럼 이름과 서로 달라야 한다. 만일, SELECT ... INTO 명령문과 같은 SQL 명령문이, 선언된 로
컬 변수와 컬럼의 이름이 동일한 참조를 하게 되면, MySQL은 참조를 변수의 이름으로 해석하게 된다. 예를 들어, 아래의 명령문에
서 보면, xname 은 xname column 이 아니라 xname 변수로 해석하게 된다 :
CREATE PROCEDURE sp1 (x VARCHAR(5))
BEGIN
DECLARE xname VARCHAR(5) DEFAULT 'bob';
DECLARE newname VARCHAR(5);
DECLARE xid INT;
SELECT xname,id INTO newname,xid

:::MySQL Korea:::
FROM table1 WHERE xname = xname;
SELECT newname;
END;
이 프로시저가 호출되면, newname 변수는 table1.xname 컬럼에 상관없이 ‘bob’이라는 값을 리턴한다.
Section I.1, “스토어드 루틴과 트리거상에서의 제약 사항”을 같이 참조하기 바람.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.8. 조건문 및 핸들러

17.2.8.1. DECLARE 조건문
17. 스토어드 프로시저와 함수 17.2.8.2. DECLARE 핸들러

17.2.8.1 DECLARE 조건문 어떤 컨디션은 특정 핸들링을 요구할 수도 있다. 이러한 컨디션들은 에러 문장과 관련될 수도 있으며, 또한 루틴내의 일반적인 플로
우 컨트롤과도 관련이 있게 된다.
17.2.8.2 DECLARE 핸들러
:::MySQL Korea:::
제목검색
17.2.8.1. DECLARE 조건문

17. 스토어드 프로시저와 함수 DECLARE condition_name CONDITION FOR condition_value

17.2.8 조건문 및 핸들러 condition_value:
17.2.8.1 DECLARE 조건문

SQLSTATE [VALUE] sqlstate_value
| mysql_error_code
이 명령문은 특정 핸들링을 필요로 하는 컨디션을 표시한다. 이것은 명기된 에러 컨디션이 있는 이름과 관련을 갖는다. 그 이름은
DECLARE HANDLER 명령문에서 순차적으로 사용될 수 있다. Section 17.2.8.2, “DECLARE Handlers” 참조.
A condition_value 는 SQLSTATE 값 또는 MySQL 에러 코드가 될 수도 있다.
:::MySQL Korea:::
제목검색
17.2.8.2. DECLARE 핸들러

17. 스토어드 프로시저와 함수 DECLARE handler_type HANDLER FOR condition_value[,...] statement


17.2.8.1 DECLARE 조건문
handler_type:
CONTINUE
| EXIT
| UNDO
condition_value:
SQLSTATE [VALUE] sqlstate_value
| condition_name
| SQLWARNING
| NOT FOUND
| SQLEXCEPTION

:::MySQL Korea:::
| mysql_error_code
DECLARE ... HANDLER 명령문은 핸들러를 지정하는데, 각 핸들러는 하나 또는 여러 개의 컨디션을 다루게 할 수 있다. 만일 이
러한 컨디션 중에서 하나가 발생하면, 지정된 statement 가 실행된다. statement 는 단순 명령문이 될 수도 있고(예를 들어, SET
var_name = value), 또는 BEGIN 과 END로 쓰여진 복합 명령문이 될 수도 있다. ( Section 17.2.5, “BEGIN ... END 복합 명령
문 신텍스” 참조).
CONTINUE 핸들러의 경우, 현 루틴의 실행은 핸들러 명령문의 실행 이후에 진행된다. EXIT 핸들러의 경우는, 핸들러가 선언된
곳의 BEGIN ... END 복합 명령문을 종료시킨다. (이것은 컨디션이 내부의 블록에서 발생될 경우에도 해당된다.) UNDO 핸들러
타입 명령문은 아직 지원되지 않는다.
만일 어떠한 핸들러도 선언되지 않은 상태에서 컨디션이 발생하면, 디폴트로 EXIT 핸들러가 실행된다.
condition_value 는 아래의 값 중에서 한가지가 될 수 있다:
● SQLSTATE 값 또는 MySQL 에러 코드.

● DECLARE ... CONDITION 으로 이전에 표시된 컨디션 이름. Section 17.2.8.1, “DECLARE Conditions” 참조.
● SQLWARNING 은 01로 시작되는 모든 SQLSTATE 코드의 축약형임.
● NOT FOUND 는 02로 시작되는 모든 SQLSTATE 코드의 축약형임.
● SQLEXCEPTION 은 SQLWARNING 또는 NOT FOUND 가 찾지 못하는 모든SQLSTATE 코드에 대한 축약형임.
예제:
mysql> CREATE TABLE test.t (s1 int,primary key (s1));
mysql> delimiter //

:::MySQL Korea:::
mysql> CREATE PROCEDURE handlerdemo ()
-> BEGIN
-> DECLARE CONTINUE HANDLER FOR SQLSTATE '23000' SET @x2 = 1;
-> SET @x = 1;
-> INSERT INTO test.t VALUES (1);
-> SET @x = 2;
-> INSERT INTO test.t VALUES (1);
-> SET @x = 3;
-> END;
-> //
mysql> CALL handlerdemo()//

:::MySQL Korea:::
mysql> SELECT @x//
+------+
| @x |
+------+
|3 |
+------+
위의 예제는 SQLSTATE 23000과 관련된 핸들러이며, 이것은 이중(double) 키 에러를 발생시킨다. @x 는 3이 되며, 이것은
MySQL이 프로시저의 마지막에 실행됨을 보여주는 것이다. 만일DECLARE CONTINUE HANDLER FOR SQLSTATE
'23000' SET @x2 = 1; 이 표시되지 않으면, MySQL은 두 번째 INSERT가 PRIMARY KEY 의 제한으로 인해 실패한 후에 디폴
트 경로(EXIT)을 실행하게 되며, SELECT @x는 2를 리턴하게 된다.
만일 컨디션을 무시하고자 하면, CONTINUE 핸들러를 빈 블록과 연결해서 선언하면 된다. 예를 들면:
DECLARE CONTINUE HANDLER FOR SQLWARNING BEGIN END;

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.9. 커서(Cursors)

17.2.9.1. Cursors 선언하기
17. 스토어드 프로시저와 함수 17.2.9.2. Cursor OPEN 명령문
17.2. 스토어드 프로시저 신텍스 17.2.9.3. Cursor FETCH 명령문
17.2.9 커서(Cursors) 17.2.9.4. Cursor CLOSE 명령문

단순한 커서는 스토어드 프로시저 및 함수 내부에서 지원된다. 신텍스는 임베디드 SQL와 같다. 커서는 현재까지 어센서티브
(asensitive)하며, 읽기 전용, 및 논-스크롤링(non-scrolling)하다. 어센서티브란 서버가 자신의 결과 테이블의 복사본을 만들
수 있거나 또는 만들지 못할 수도 있음을 의미하는 것이다. 커서는 핸들러를 선언하기 전에 선언되어야 하며, 변수와 컨디션은 커
서 또는 핸들러를 선언하기 전에 선언되어야 한다.
예제:
CREATE PROCEDURE curdemo()
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE a CHAR(16);
DECLARE b,c INT;
DECLARE cur1 CURSOR FOR SELECT id,data FROM test.t1;
DECLARE cur2 CURSOR FOR SELECT i FROM test.t2;

:::MySQL Korea:::
DECLARE CONTINUE HANDLER FOR SQLSTATE '02000' SET done = 1;
OPEN cur1;
OPEN cur2;
REPEAT
FETCH cur1 INTO a, b;
FETCH cur2 INTO c;
IF NOT done THEN
IF b < c THEN
INSERT INTO test.t3 VALUES (a,b);
ELSE
INSERT INTO test.t3 VALUES (a,c);
END IF;
END IF;
UNTIL done END REPEAT;

:::MySQL Korea:::
CLOSE cur1;
CLOSE cur2;
END

:::MySQL Korea:::
제목검색
17.2.9.1. Cursors 선언하기

17. 스토어드 프로시저와 함수 DECLARE cursor_name CURSOR FOR select_statement

17.2.9 커서(Cursors) 이 명령문은 커서를 선언하는 것이다. 다중 커서는 루틴 내에서 선언될 수도 있으나, 주어진 블록내의 각 커서는 반드시 서로 다른
이름을 가져야 한다 . SELECT 명령문은 INTO 구문을 가질 수 없다.
:::MySQL Korea:::
제목검색
17.2.9.2. Cursor OPEN 명령문

17. 스토어드 프로시저와 함수 OPEN cursor_name

17.2.9 커서(Cursors) 이 명령문은 이전에 선언한 커서를 연다.

:::MySQL Korea:::
제목검색
17.2.9.3. Cursor FETCH 명령문

17. 스토어드 프로시저와 함수 FETCH cursor_name INTO var_name [, var_name] ...

17.2.9 커서(Cursors) 이 명령문은 지정한 오픈 커서를 이용해서 바로 다음 열(만일 열이 존재한다면)을 가져온 다음, 커서 포인터를 전진 시킨
다.
:::MySQL Korea:::
제목검색
17.2.9.4. Cursor CLOSE 명령문

17. 스토어드 프로시저와 함수 CLOSE cursor_name

17.2.9 커서(Cursors) 이 명령문은 이전에 열어 놓은 커서를 닫는다.

만일 확실하게 닫혀지지 않으면, 커서는 커서가 선언된 복합 명령문의 마지막에서 닫히게 된다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.2.10. 플로우 컨트롤(Flow Control) 구성

17.2.10.1. IF 명령문
17. 스토어드 프로시저와 함수 17.2.10.2. CASE 명령문
17.2. 스토어드 프로시저 신텍스 17.2.10.3. LOOP 명령문
17.2.10 플로우 컨트롤(Flow Control) 구성 17.2.10.4. LEAVE 명령문
17.2.10.1 IF 명령문 17.2.10.5. ITERATE 명령문
17.2.10.2 CASE 명령문 17.2.10.6. REPEAT 명령문
17.2.10.3 LOOP 명령문 17.2.10.7. WHILE 명령문

IF, CASE, LOOP, WHILE, REPLACE ITERATE, 및 LEAVE 구성문은 모두 실행할 수 있다.
대부분의 이러한 구성문은 다른 명령문을 포함하고 있는데, 아래의 색션에서 열거하는 문법에 의해 구성 되어진다. 이런 구성문들
은 네스티드(nested)될 수 있다. 예를 들면, 하나의 IF 명령문은 WHILE 루프를 포함할 수 있고, 이 루프는 자체적으로 CASE 명
령문을 가질 수 있다.
FOR는 아직 지원되지 않는다.
:::MySQL Korea:::
제목검색
17.2.10.1. IF 명령문
17. 스토어드 프로시저와 함수 IF search_condition THEN statement_list

17.2.10 플로우 컨트롤(Flow Control) 구성 [ELSEIF search_condition THEN statement_list] ...
17.2.10.1 IF 명령문
[ELSE statement_list]
17.2.10.2 CASE 명령문
17.2.10.3 LOOP 명령문
END IF
17.2.10.5 ITERATE 명령문 IF 문장은 기본적인 조건문을 제공한다. 만일search_condition 의 조건에 맞으면, 이에 대응하는 SQL명령문 리스트가 실행된다.
17.2.10.6 REPEAT 명령문 만일 search_condition 의 조건이 일치하지 않으면, ELSE 구문에 있는 명령문 리스트가 실행된다. 각 statement_list 는 한 개 또
17.2.10.7 WHILE 명령문 는 그 이상의 명령문으로 구성된다.
Note: 또한, IF() 함수가 있는데, 여기에서 기술한 IF 명령문과 다른 형태로서, Section 12.2, “Control Flow Functions”를 참
조하기 바람.
:::MySQL Korea:::
제목검색
17.2.10.2. CASE 명령문

17. 스토어드 프로시저와 함수 CASE case_value

17.2.10 플로우 컨트롤(Flow Control) 구성 WHEN when_value THEN statement_list
17.2.10.1 IF 명령문
[WHEN when_value THEN statement_list] ...
17.2.10.2 CASE 명령문
17.2.10.3 LOOP 명령문
17.2.10.5 ITERATE 명령문 END CASE
17.2.10.7 WHILE 명령문 Or:
CASE
WHEN search_condition THEN statement_list
[WHEN search_condition THEN statement_list] ...
END CASE
스토어드 루틴에 대한CASE 명령문은 복합 조건문 구성을 실행한다. 만일 search_condition 의 조건이 일치하면, 이에 대응하는
SQL 명령문 리스트가 실행된다. 만일 일치하는 조건이 없는 경우에는, ELSE구문에 있는 명령문 리스트가 실행된다. 각
statement_list 는 한 개 또는 그 이상의 명령문으로 구성된다.

:::MySQL Korea:::
Note: 스토어드 루틴 내에서 사용하기 위한 CASE statement 의 신텍스는 Section 12.2, “Control Flow Functions”에서 다루
는 SQL CASE expression과는 약간 다른 형태이다. CASE 명령문은 ELSE NULL 구문을 가질 수 없으며, 또한 END 대신에
END CASE로 종료를 시킨다.

:::MySQL Korea:::
제목검색
17.2.10.3. LOOP 명령문

17. 스토어드 프로시저와 함수 [begin_label:] LOOP

17.2.10 플로우 컨트롤(Flow Control) 구성 statement_list
17.2.10.1 IF 명령문
END LOOP [end_label]
17.2.10.2 CASE 명령문
17.2.10.3 LOOP 명령문
LOOP 는 단일 루프 구성을 형성하고, 명령문의 반복 실행을 가능하게 해주며, 한 개 또는 그 이상의 명령문으로 구성 되어진다. 루
프안에 있는 명령문은 루프가 종료되기 전까지 계속 반복 실행을 한다; 일반적으로 이 명령문은 LEAVE 명령문과 함께 실행된다.
17.2.10.6 REPEAT 명령문 LOOP 명령문은 레이블화 시킬 수 있고, end_label 는 begin_label 을 표시한 후에 작성해야 한다. 양쪽 모두 표시할 때에는 동일
17.2.10.7 WHILE 명령문 한 이름을 사용해야 한다.
:::MySQL Korea:::
제목검색
17.2.10.4. LEAVE 명령문

17. 스토어드 프로시저와 함수 LEAVE label

17.2.10 플로우 컨트롤(Flow Control) 구성 이 명령문은 모든 레이블화된 플로우 제어 구성문을 빠져 나올 때 사용하는 명령문이다. 이것은 BEGIN ... END , 또는 루프 구성문
(LOOP, REPEAT, WHILE)안에서도 사용 가능하다.
17.2.10.1 IF 명령문
17.2.10.2 CASE 명령문
17.2.10.3 LOOP 명령문
:::MySQL Korea:::
제목검색
17.2.10.5. ITERATE 명령문

17. 스토어드 프로시저와 함수 ITERATE label

17.2.10 플로우 컨트롤(Flow Control) 구성 ITERATE 는 LOOP, REPEAT, 및 WHILE 명령문안에서만 사용할 수 있다. ITERATE 는 “루프를 다시 실행(do the loop
again)”의 의미이다.
17.2.10.1 IF 명령문
17.2.10.2 CASE 명령문
예제:
17.2.10.3 LOOP 명령문
CREATE PROCEDURE doiterate(p1 INT)
17.2.10.6 REPEAT 명령문 BEGIN
label1: LOOP
SET p1 = p1 + 1;
IF p1 < 10 THEN ITERATE label1; END IF;
LEAVE label1;
END LOOP label1;
SET @x = p1;
END

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
17.2.10.6. REPEAT 명령문

17. 스토어드 프로시저와 함수 [begin_label:] REPEAT

17.2.10.1 IF 명령문
UNTIL search_condition
17.2.10.2 CASE 명령문
17.2.10.3 LOOP 명령문
END REPEAT [end_label]
17.2.10.5 ITERATE 명령문 REPEAT 명령문 내에 있는 명령문 리스트는 search_condition 의 조건이 일치하는 동안 반복적으로 실행된다. 따라서,
17.2.10.6 REPEAT 명령문 REPEAT 는 항상 적어도 한번은 루프 안에 표현되어야 한다. statement_list 는 한 개 또는 그 이상의 명령문으로 구성된다.
REPEAT명령문은 레이블화 될 수 있다. end_label 는 begin_label 과 함께 표시되어야 한다. 양쪽 모두는 동일한 이름으로 표시되
어야 한다.
예제:
mysql> delimiter //
mysql> CREATE PROCEDURE dorepeat(p1 INT)
-> BEGIN
-> SET @x = 0;

:::MySQL Korea:::
-> REPEAT SET @x = @x + 1; UNTIL @x > p1 END REPEAT;
-> END
-> //
mysql> CALL dorepeat(1000)//
mysql> SELECT @x//
+------+
| @x |
+------+
| 1001 |
+------+

:::MySQL Korea:::
제목검색
17.2.10.7. WHILE 명령문

17. 스토어드 프로시저와 함수 [begin_label:] WHILE search_condition DO

17.2.10.1 IF 명령문
END WHILE [end_label]
17.2.10.2 CASE 명령문
17.2.10.3 LOOP 명령문
The statement list within a WHILE 명령문 내에 있는 명령문 리스트는 search_condition 조건이 일치하는 동안 반복적으로 실
행된다. statement_list 는 한 개 또는 그 이상의 명령문으로 구성된다.
17.2.10.6 REPEAT 명령문 WHILE 명령문은 레이블화할 수 있다. end_label 은 begin_label 과 함께 표시되어야 하고, 양쪽은 모두 동일한 이름을 사용하여
17.2.10.7 WHILE 명령문 야 한다.
예제:
CREATE PROCEDURE dowhile()
BEGIN
DECLARE v1 INT DEFAULT 5;
WHILE v1 > 0 DO
...

:::MySQL Korea:::
SET v1 = v1 - 1;
END WHILE;
END

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.3. 스토어드 프로시저, 함수, 트리거, 및 리플리케이션 : FAQ

MySQL 5.0의 스토어드 프로시저 및 함수를 리플리케이션과 함께 사용할 수 있습니까?
17. 스토어드 프로시저와 함수 예, 스토어드 프로시저 및 함수에서 수행되는 표준 동작은 마스터 MySQL서버에서 슬레이브 서버로 복사
17.3. 스토어드 프로시저, 함수, 트리거, 및 리 본이 전달됩니다. 이 기능에는 몇 가지 제약 사항이 있으며, 자세한 내용은 Section 17.4, “스토어드 루틴
플리케이션 : FAQ 과 트리거의 바이너리 로깅”을 참조하시기 바랍니다.
17.3 스토어드 프로시저, 함수, 트리거, 및 리플리
케이션 : FAQ ● 마스터 서버에서 생성된 스토어드 프로시저와 함수가 슬레이브 서버에 복사되어 집니까?
예, 마스터 서버상에서 정상적인 DDL명령문의 수행으로 생성된 스토어드 프로시저 와 함수는 슬레이브
서버로 복사본이 전달되며, 따라서 오브젝트는 양쪽 서버에 존재하게 됩니다. 스토어드 프로시저 및 함수
에 대한ALTER 및 DROP 명령문 역시 복사 되어 집니다.
● 스토어드 프로시저 및 함수의 내부에서는 어떻게 복사가 이루어 집니까?
MySQL은 스토어드 프로시저에서 일어나는 각 DML 이벤트를 기록하고, 각 각의 개별 동작을 슬레이브

서버에 복사합니다. 스토어드 프로시저를 실행하는 실제 호출은 복사되지 않습니다.
데이터를 변경하는 스토어드 함수는 함수 호출(function invocation)로 로그 되어지고, 각 함수 내에서 발
생하는 DML이벤트로 로그 되어지는 것은 아닙니다.
● 리플리케이션과 함께 스토어드 프로시저 및 함수를 사용하는데 있어서 특별히 보안적인 요구 사항이 필요

합니까?
예. 슬레이브 서버가 마스터 서버의 바이너리 로그로부터 명령문을 읽기 위해서는 권한이 있어야 하기 때
문에, 리플리케이션이 있는 스토어드 함수를 사용하기 위한 특정 보안 제약 사항이 있습니다. 만일 일반적
인 상황(특정 시점 복구를 위해)에서 리플리케이션 또는 바이너리 로깅이 실행되면, MySQL DBA는 이것
을 열기 위해 두 가지 보안 옵션을 가져야 합니다:

:::MySQL Korea:::
❍ 스토어드 함수를 생성하고자 하는 사용자는 반드시 SUPER 권한을 갖고 있어야 합니다.

❍ 다른 대안으로는, DBA이 log_bin_trust_function_creators 시스템 변수를 1로 설정할 수 있는데,
이렇게 하면 누구라도 표준 CREATE ROUTINE privilege권한을 갖고 스토어드 함수를 생성할 수
있게 됩니다.
Note: MySQL 5.0.16 이전에는, 이러한 제한 사항이 스토어드 프로시저에도 적용되었고 시스템 변수의
이름은log_bin_trust_routine_creators 입니다.
● 스토어드 프로시저와 함수의 동작을 복사하는 것에는 어떤 제약 사항이 있습니까?
스토어드 프로시저내에 임베디드 되어 있는Non-deterministic (랜덤) 또는 시간 기반 동작(time-

based action)은 올바르게 복사되지 않을 수도 있습니다. 이러한 것들의 속성 때문에, 무작위로 생기게 되
는 결과값은 예측할 수 없으며 정확히 재생산될 수도 없습니다. 따라서, 슬레이브에 복사되는 랜덤 동작은
마스터에서 수행되는 것과 장확히 미러(mirror)되지 않습니다. DETERMINISTIC으로 스토어드 함수
를 선언하거나, log_bin_trust_function_creators 의 시스템 변수를 0으로 설정하는 것이 랜덤값 실행
(random-valued opereation)을 호출하지 못하도록 하는 방법이라는 점을 알아두시기 바랍니다.
부가적으로, 스토어드 프로시저에 있는 이러한 동작들의 타이밍이 리플리케이션을 위해 사용된 바이너리
로그를 통해 재생산되지 않기 때문에 시간 기반 동작(time-based actions)은 슬레이브 상에서 재생산될
수 없습니다. 이것은 단지 이벤트만 기록하고 타이밍 제한치를 계산하는 것은 아닙니다.
마지막으로, 대단위 DML 동작(대량 삽입 같은)이 진행되는 동안 발생하는 에러를 위한 non-
transactional 테이블은, DML동작으로부터 서버는 부분적으로 업데이트 되지만 에러로 인해 슬레이브는
업데이트가 되지 않는 리플리케이션 이슈를 경험할 수도 있습니다. 이 문제에 대한 대비책으로는 IGNORE
키워드를 가지고 DML 행위를 하는 것인데, 이렇게 하면 에러를 유발하는 서버상의 업데이트는 무시되고,
에러를 유발하지 않는 업데이트는 슬레이브에 복사 되어 집니다.
● 앞에서 열거한 제약 사항으로 인해 MySQL의 특정 시간 복구(point-in-time) 기능이 영향을 받습니까?
리플리케이션에 영향을 주는 제한 사항은 특정 시간 복구에도 적용됩니다.
● 앞서 말한 제약 사항을 수정하기 위해 MySQL을 노력을 하고 있습니까?
MySQL 의 향후 버전에서는 리플리케이션을 어떻게 다룰 것인지에 대한 선택 방법을 제시할 것입니다:

:::MySQL Korea:::
❍ 명령문 기반 리플리케이션(Statement-based replication) (현 수행 방식).

❍ 로우 레벨(Row-level)리플리케이션(앞서 열거한 모든 제약 사항을 해결).
● 트리거는 리플리케이션과 같이 동작합니까?
Triggers and replication in MySQL 5.0에서 트리거와 리플리케이션은 다른 데이터 베이스 엔진에서와
똑같이 동작을 합니다: 마스터 서버상에서 트리거를 통해 수행되는 동작은 슬레이브에 복사되지 않습니
다. 대신에, MySQL마스터 서버상에 있는 테이블에 존재하는 트리거는 MySQL슬레이브 서버위에 이에
대응하는 테이블을 생성할 필요가 있는데, 이렇게 하면 트리거는 서버뿐만 아니라 슬레이브에서도 동작을
하게 됩니다.
● 서버에 있는 트리거를 통해 슬레이브에 어떻게 복사가 되어 집니까?
첫 번째, 마스터에 존재하는 트리거는 슬레이브상에서 재생성 되어야 합니다. 일단 이것이 수행되면, 레프
리케이션 플로우는 리플리케이션에 참여하는 다른 어떤 표준 DLM명령문처럼 동작을 합니다. 예를 들면,
AFTER삽입 트리거를 갖고 있는 EMP 테이블이 있고, 이것이 MySQL 마스터 서버에 존재한다고 가정합
니다. 동일한 EMP 테이블 및 AFTER 삽입 트리거는 슬레이브에도 역시 존재합니다. 리플리케이션 플로
우는 다음과 같습니다:
1. INSERT 명령문으로 EMP를 만듬.

2. EMP상의 AFTER트리거가 동작함.
3. INSERT 명령문이 바이너리 로그에 쓰여짐.
4. 리플리케이션 슬레이브가 INSERT 명령문을 가져와서 EMP 에 넣고 이것을 실행함.
5. 슬레이브에 있는 EMP상의 AFTER 트리거가 동작을 함.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 17.4. 스토어드 루틴 및 트리거의 바이너리 로깅

바이너리 로그는 데이터 베이스의 컨텐츠를 수정하는 SQL명령문에 대한 정보를 가지고 있다. 이러한 정보는 수정 사항을 설명하
17. 스토어드 프로시저와 함수 는 “이벤트(Event)”형태로 보관되어 진다. 바이너리 로그에는 두 가지 중요한 목적이 담겨 있다:
17.4. 스토어드 루틴 및 트리거의 바이너리 로
깅 ● 리플리케이션의 경우, 마스터 서버는 자신의 바이너리 로그에 포함된 이벤트를 자신의 슬레이브에 전달하는데, 이렇게 함
17.4 스토어드 루틴 및 트리거의 바이너리 로깅 으로서 서버에서 이루어진 데이터의 변경과 동일한 내용을 전달된 이벤트가 실행하도록 하게 한다 . Section 6.2, “리플리
케이션 구현 소개” 참조.
● 특정 데이터 복구 동작은 바이너리 로그의 사용을 요구한다. 백업 파일이 재저장된 후에, 백업이 이루어진 후 기록된 바이
너리 로그에 있는 이벤트가 재 실행된다. 이러한 이벤트들은 백업이 이루어지는 시점부터 데이터 베이스를 갱신하게 낸
다. Section 5.10.2.2, “복구를 위한 백업 사용하기” 참조.
이 섹션에서는 MySQL 5.0에 있는 스토어드 루틴(프로시저 및 함수)와 트리거에 관련된 바이너리 로깅의 개발을 설명하도록 하겠
다. 첫 번째로는 로깅 실행에서 발생하는 변경 사항에 대해 정리를 할 것이고, 그 다음에는 스토어드 루틴의 사용에서 있게 되는 실
행의 현재 조건문(current condition)에 대해 언급하기로 한다. 마지막으로, 언제 그리고 어떻게 다앵한 변경이 만들어 지는지에
대한 정보를 제공하는 실행에 대한 자세한 내용을 설명하겠다. 이러한 상세 내용들은 현재의 로깅 행위에 관련된 몇몇 사항이 이전
버전과는 어떻게 달리 실행되는지를 보여 준다.
일반적으로, 여기에서 설명하는 논제들은 바이너리 로깅이 SQL명령문 레벨에서 생긴다는 사실에서부터 출발한다. 향후의 MySQL
버전은 로우-레벨(row-level) 바이너리 로깅을 실행할 예정이며, SQL명령문의 실행으로 인해 각 개별 열(row)을 변경시키는
것을 열거할 것이다.
다른 것들은 고려하지 말고, --log-bin옵션으로 서버를 구동해서 바이너리 로깅을 활성화 시켰다고 가정하자.
( Section 5.12.3, “The Binary Log” 참조.) 만일 바이너리 로그가 활성화 되지 않는다면, 리플리케이션은 불가능하게 되거나,
또는 데이터 복구를 위한 바이너리 로그가 불가능하게 된다.
MySQL 5.0 에서 스토어드 루틴 로깅의 개발은 아래와 같이 요약할 수 있다 :
● MySQL 5.0.6 이전 버전 : 스토어드 루틴 로깅의 초기 실행에서, 스토어드 루틴과 CALL 명령문을 생성하는 명령문은 로
그 되지 않음. 이러한 누락은 리플리케이션과 데이터 복구에 문제를 야기할 수 있다.

:::MySQL Korea:::
● MySQL 5.0.6 : 스토어드 루틴과 CALL 명령문을 생성하는 명령문은 로그 되어짐. 스토어드 함수 호출은 데이터를 업데
이트 하도록 하는 명령문이 실행될 때 로그 되어 진다 (이러한 명령문들이 로그 되어졌기 때문에). 하지만, 비록 함수 자체
에서 데이터의 변경이 이루어 진다 하더라도, 데이터를 변경시키지 않는 SELECT와 같은 명령문이 실행될 때에는 로그 되
어지지 않는다; 이것은 문제를 일으키게 된다. 어떤 환경에서는, 서로 다른 시간 또는 서로 다른(서버 및 슬레이브)기계에
서 함수 및 프로시저가 실행된다면 서로 다른 영향을 받을 수 있기 때문에 데이터 복구 또는 리플리케이션 자체가 불안정
할 수 있다. 이런 문제를 처리하기 위해, 안정적인 루틴의 동일성을 제공하고, 충분한 권한을 갖고 있는 사용자에 의한 행위
를 제외한, 일반적으로 불안정한 루틴을 방지하기 위한 조치가 실행된다.
● MySQL 5.0.12: 스토어드 함수에 대해서는, 데이터를 변경시키는 함수 호출이 SELECT와 같이 로그 되지 않는(non-
logged)명령어 내에서 발생할 때, 서버는 그 함수를 호출하는 DO 명령문을 로그 시킴으로써 데이터가 복구되거나 슬레이
브 서버에 리플리케이션되는 동안 함수가 실행되도록 한다. 스토어드 프로시저에 대해서는, 서버는 CALL 명령문을 로그
시키지 못한다. 대신에, 서버는 CALL명령문의 결과로 실행되는 프로시저에 포함되어 있는 개별 명령문은 로그 시킨다. 이
것은 프로시저가 마스터 서버가 아닌 슬레이브 서버상에서 서로 다른 실행 경로를 따라 실행될 때 발생할 수 있는 문제들
을 제거한다.
● MySQL 5.0.16: MySQL 5.0.12에서 제공하는 프로시저 로깅 변경을 통해 불안정한 루틴상의 조건문이 스토어드 프로시
저에 대해 안정적으로 동작하도록 해 준다. 따라서, 이러한 조건문을 제어하는 사용자 인터페이스를 함수에 적용 되도록 수
정한다. 프로시저 생성자를 더 이상 제한 할 수 없게 되는 것이다.
● 앞에서 설명한 변경의 결과로, 바이너리 로깅이 활성화될 때에 다음에서 설명하는 조건문을 스토어드 함수에 적용할 수 있
게 된다. 이러한 조건문은 스토어드 프로시저 생성에는 적용되지 않는다.
● 스토어드 함수를 생성 또는 변경하기 위해서는, 일반적으로 CREATE ROUTINE 또는 ALTER ROUTINE 권한을 요구하
는 것에 더불어. 반드시 SUPER 권한을 가져야 한다.
● 스토어드 함수를 생성할 때에는, 그것이 확정적(deterministic)인지 또는 그것이 데이터를 수정하는 않는다는 것을 선언해
야 한다. 그렇지 않으면, 그 함수는 데이터 복구 또는 리플리케이션에 대해 덜 안정한 상태가 되어 버린다. 함수의 특성 중
에 두 가지가 여기에 적용된다 :
❍ DETERMINISTIC and NOT DETERMINISTIC 특성은 함수가 주어진 입력 값에 대해 항상 동일한 결과를 만드
는지 아닌지를 나타낸다. 어떤 특성도 주어지지 않으면, 디폴트는NOT DETERMINISTIC 이며, 따라서 함수를 확
정적인 것으로 선언하기 위해서는 DETERMINISTIC를 확실하게 지정해 주어야 한다.
❍ NOW() 함수(또는 동일 기능 함수) 또는 RAND()의 사용은 함수를 반드시 non-deterministic하게 만들어 주는
것은 아니다. NOW()의 경우, 바이너리 로그는 타임스탬프와 복사본은 올바르게 포함한다. 또한, RAND()도 함수
내에서 일단 한번 호출 되어 지면 정확하게 복사본을 만들게 된다. (함수 실행 타임스탬프 및 무작위 수는 마스터
서버 및 슬레이브 상에 있는 동일한 암시적 입력(implicit input)으로 간주할 수 있다.)

:::MySQL Korea:::
❍ CONTAINS SQL, NO SQL, READS SQL DATA, 및 MODIFIES SQL DATA 특성은 함수가 데이터를 읽거나
또는 쓰는 정보를 제공한다. NO SQL 또는 READS SQL DATA 는 함수가 데이터를 변경하지 않는다는 것을 나타
내는 것이다. 하지만 어떠한 특성도 주어지지 않으면 디폴트가 CONTAIN SQL이 되기 때문에 반드시 이러한 것
중에 하나를 명확히 지정해 주어야 한다.
CREATE FUNCTION 명령문이 디폴트로 수용되도록 하기 위해서는, DETERMINISTIC 또는 NO SQL 및 READS

SQL DATA 중에 한 개는 반드시 확실하게 표현되어야 한다. 그렇지 않으면 에러가 발생한다:
ERROR 1418 (HY000): This function has none of DETERMINISTIC, NO SQL,
or READS SQL DATA in its declaration and binary logging is enabled
(you *might* want to use the less safe log_bin_trust_function_creators
variable)
함수의 특성에 대한 평가는 생성자의 “honesty”를 근거로 한다: MySQL은 DETERMINISTIC으로 선언된 함수가
non-deterministic결과를 만드는 명령문을 갖고 있지 않음을 검사하지 않는다.
● 함수 생성(SUPER권한이 있어야 하며 함수가 deterministic으로 선언되거나 또는 데이터를 수정하지 않아야 함)에서 앞

에서 언급한 조건을 피하기 위해서는, 글로벌 시스템 변수log_bin_trust_function_creators 를 1로 설정 해야 한다. 디폴
트로는, 이 변수의 값은 0이지만, 아래와 같이 변경할 수 있다:
• mysql> SET GLOBAL log_bin_trust_function_creators = 1;

또한, 이 변수는 서버를 구동할 때 --log-bin-trust-function-creators 옵션을 사용해서 설정할 수 있다.
만일 바이너리 로깅이 활성화되지 않으면, log_bin_trust_function_creators 는 적용되지 않으며 루틴 생성을 위한
SUPER는 필요 없게 된다.
트리거는 스토어드 함수와 유사하고, 따라서 앞에서 언급한 주의 사항 역시 트리거에도 적용된다. 트리거에 대한 예외적인 사항은
다음과 같다: CREATE TRIGGER 는 옵셔널(optional) DETERMINISTIC 특성을 갖지 않기 때문에, 트리거는 항상
deterministic으로 간주된다. 하지만, 이러한 가정은 어떤 경우에서는 틀릴 수도 있다. 예를 들면, UUID() 함수는non-
deterministic (그리고 복사되지 않음)이다. 이러한 함수를 트리거에 사용할 경우에는 주의하여야 한다.
트리거는 테이블을 업데이트할 수 있으며(MySQL 5.0.10 버전 현재), 따라서 SUPER권한이 없고
log_bin_trust_function_creators 의 값이 0 이라면, CREATE TRIGGER 과 함께 나타나는 스토어드 함수에 대한 에러 메시지와
비슷한 에러가 발생하게 된다.
이 섹션의 나머지에서는 스토어드 루틴 로깅 개발에 대해서 상세하게 설명하기로 한다. 상세 설명 중에 몇 가지는 현재 스토어드 루
틴 사용에서 로깅 관련 조건문에 대한 이론적인 기본 지식을 제공하여 준다.

:::MySQL Korea:::
MySQL 5.0.6 이전 버전에서 루틴 로깅: 스토어드 루틴을 생성하고 사용하는 명령문이 바이너리 로그되는 것이 아니라, 스토어드
루틴내에서 선언된 명령문이 로그되어 진다. 아래의 명령문을 작성 하였다고 가정하자:
CREATE PROCEDURE mysp INSERT INTO t VALUES(1);
CALL mysp;
이 예에서 보면, INSERT 명령문만이 바이너리 로그에서 나타난다. CREATE PROCEDURE 와 CALL 명령문은 나타나지 않는
다. 바이너리 로그에서 루틴 관련(routine-related) 명령문이 없다는 것은 스토어드 루틴이 올바르게 복사되지 않았다는 것을 의
미한다. 이것은 또한 데이터 복구 동작에 대해, 바이너리 로그에 있는 이벤트의 재실행은 스토어드 루틴를 복구시키지 않는다는 것
을 의미하기도 한다.
MySQL 5.0.6에서 루틴 로깅 변경: 스토어드 루틴 생성과 CALL 명령문(그리고 관련된 리플리케이션 및 데이터 복구 문제)에 대
한 로깅 부재를 연결(address)하기 위해, 스토어드 루틴에 대한 바이너리 로깅의 특성은 여기에서 설명하였듯이 변경되었다. (아
래의 리스트중에 몇 가지 항목은 다음 버전에서 다루어지기 때문에 제외한다.)
● 서버는CREATE PROCEDURE, CREATE FUNCTION, ALTER PROCEDURE, ALTER FUNCTION, DROP

PROCEDURE, 및 DROP FUNCTION 명령문을 바이너리 로그에 쓴다. 또한, 서버는 프로시저내에서 실행되는 명령문이
아닌, CALL 명령문을 로그 한다. 아래의 명령문을 작성하였다고 가정하자:
• CREATE PROCEDURE mysp INSERT INTO t VALUES(1);

• CALL mysp;
이 예문에서 보면, CREATE PROCEDURE 및 CALL 명령문은 바이너리 로그에서 나타나지만, INSERT 명령문은 나타
나지 않는다. 이것은 MySQL 5.0.6 이전 버전에서 발생했던 INSERT만 로그되는 문제를 해결해 준다.
● CALL 명령문 로깅은 리플리케이션에 대한 보안 문제를 갖게 되는데, 두 가지 요소로 인해 이런 문제가 생긴다:

❍ 프로시저가 마스터와 슬레이브 서버상에 있는 서로 다른 실행 경로를 따라갈 수 있게 한다.
❍ 슬레이브에서 실행되는 명령문은 전체 권한을 갖고 있는 슬레이브 SQL 쓰레드(Thread)에 의해 실행된다.
비록 사용자가 루틴을 생성하기 위해서는 반드시 CREATE ROUTINE권한을 가져야 함을 의미 하지만, 전체 권한을 갖
는 SQL 쓰레드가 실행하는 명령문이 있는 슬레이브 위에서만 실행될 위험한 명령문을 작성할 수 있다. 예를 들면, 마스터
와 슬레이브 서버가 서버 ID 1과 2를 갖고 있다면, 마스터 서버의 사용자는 아래와 같이 불안정한 프로시저 unsafe_sp()
를 생성해서 호출할 수 있다:
mysql> delimiter //
mysql> CREATE PROCEDURE unsafe_sp ()

:::MySQL Korea:::
-> BEGIN
-> IF @@server_id=2 THEN DROP DATABASE accounting; END IF;
-> END;
-> //
mysql> delimiter ;
mysql> CALL unsafe_sp();
CREATE PROCEDURE 와 CALL 명령문은 바이너리 로그를 작성할 수 있고, 따라서 슬레이브는 이것을 실행할 수 있
다. 슬레이브 SQL 쓰레드는 전체 권한이 있기 때문에, accounting 데이터 베이스를 끝내는(drop) DROP DATABASE
명령문을 실행한다. 따라서, CALL 명령문은 마스터와 슬레이브에서 서로 다른 영향을 받게 되고, 이것은 리플리케이션이
안전하게 이루어 지지 않게 된다.
앞선 예문은 스토어드 프로시저를 사용하고 있으나, 바이너리 로그를 작성하는 명령문 내에서 호출되는 스토어드 함수에
대해서도 비슷한 문제가 발생한다: 함수 호출은 마스터와 슬레이브에 서로 다른 효과를 나타낸다.
바이너리 로깅을 갖는 서버에 대해 이러한 위험을 피하도록 하기 위해, MySQL 5.0.6은 스토어드 프로시저와 함수는 반드
시 일반적인 CREATE ROUTINE 권한을 요구하는 것과 아울러 SUPER권한을 갖도록 한다. 비슷하게, ALTER
PROCEDURE 또는 ALTER FUNCTION을 사용하기 위해서는, ALTER ROUTINE

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 18. 트리거

18.1. CREATE TRIGGER 신텍스
18. 트리거 18.2. DROP TRIGGER 신텍스
18 트리거 18.3. 트리거 사용하기
18.1 CREATE TRIGGER 신택스

18.2 DROP TRIGGER 신텍스 트리거에 대한 지원은 MySQL 5.0.2버전에서부터 지원한다. 트리거란 이름이 있는 데이터 베이스 오브젝트(named database
18.3 트리거 사용하기 object )로서, 테이블과 연관되어 있으며, 특정 이벤트가 테이블에 대해 발생하면 동작을 하게 된다. 예를 들면, 아래의 명령문은 하
나의 테이블과 하나의 INSERT 트리거를 생성한다. 트리거는 테이블의 컬럼에 삽입된 값들을 더하게 한다.:
mysql> CREATE TABLE account (acct_num INT, amount DECIMAL(10,2));
mysql> CREATE TRIGGER ins_sum BEFORE INSERT ON account

-> FOR EACH ROW SET @sum = @sum + NEW.amount;
이 장에서는 트리거를 생성하고 없애는 신텍스를 설명할 것이며, 트리거를 어떻게 사용하는지에 대한 예문을 보여 주기로 한다. 트
리거 사용의 제약 사항은 Section I.1, “스토어드 루틴과 트리거상의 제약 사항”을 참조하기 바란다. 바이너리 로깅이 트리거에
적용될 때의 제약 사항은 Section 17.4, “스토어드 루틴과 트리거의 바이너리 로깅”에서 다루었다.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 18.1. CREATE TRIGGER 신텍스
18. 트리거 CREATE

18.1. CREATE TRIGGER 신택스 [DEFINER = { user | CURRENT_USER }]
18.1 CREATE TRIGGER 신택스 TRIGGER trigger_name trigger_time trigger_event

ON tbl_name FOR EACH ROW trigger_stmt
이 명령문은 새로운 트리거를 생성한다. 트리거는 테이블과 연관된 이름이 있는 데이터 베이스 오브젝트이며, 특정 이벤트가 테이
블에 대해 발생할 경우 동작을 하게 된다. CREATE TRIGGER 는 MySQL 5.0.2에 추가된 기능이다. 현재까지는, 이것을 사용하
기 위해서는 SUPER 권한이 필요하다.
트리거는 tbl_name 로 명기된 테이블과 연결되어 있는데, 이것은 영구(Permanent)테이블을 참조하여야 한다. 트리거를
TEMPORARY테이블 또는 하나의 뷰(view)에 연결할 수는 없다.
트리거가 활성화되면, DEFINER 구문은 이 섹션의 후반부에 설명하는 적용 가능한 권한을 판단하게 된다.
trigger_time 는 트리거의 동작 시간이다. 이는 트리거를 명령문 실행 전에 활성화 시킬지 또는 후에 활성화 시킬지를 나타내는
BEFORE 또는 AFTER 가 될 수 있다.
trigger_event 는 트리거를 활성화 시키는 명령문의 종류를 나타낸다. trigger_event 는 아래의 것 중에 하나가 될 수 있다:
● INSERT: 트리거는 새로운 줄(row)이 테이블 속으로 삽입될 때마다 활성화 된다; 예를 들면, INSERT, LOAD DATA,
및 REPLACE 명령문을 통해서.
● UPDATE: 트리거는 하나의 줄이 수정될 때마다 활성화된다; 예를 들면, UPDATE 명령문을 통해.
● DELETE: 트리거는 하나의 줄이 테이블에서 삭제될 때마다 활성화 된다; 예를 들면, DELETE 및 REPLACE 명령문을 통
해.
trigger_event 는 트리거를 활성화 시킬 때 테이블 동작의 형태를 표현하는 것과 같이 SQL명령문의 문자 타입을 표현하지 않는다
는 점을 이해하는 것이 중요하다. 예를 들면, INSERT 트리거는 INSERT명령문 뿐만 아니라 LOAD DATA명령문에 의해서도 활
성화 되어지는데, 이것은 두 가지 명령문 모두 테이블에 줄을 삽입하기 때문이다.

:::MySQL Korea:::
INSERT INTO ... ON DUPLICATE KEY UPDATE ... 는 혼란스러움을 줄 수 있는 예문이다: BEFORE INSERT 트리거는 모
든 중에 대해 활성화가 되는데, AFTER INSERT 또는 BEFORE UPDATE 와 AFTER UPDATE 가 모두 따라오게 되는데, 줄이
이중화 되어 있는지에 따라 쓸 수 있다.
동일한 트리거 동작 시간 및 이벤트를 갖는 테이블에 대해서는 두 개의 트리거를 가질 수 없다. 예를 들면, 한 테이블에 대해 두 개
의 BEFORE UPDATE 트리거를 가질 수 없다. 하지만, 한 개의 BEFORE UPDATE 와 한 개의 BEFORE INSERT 트리거는 가
질 수 있거나, 또는 한 개의 BEFORE UPDATE 와 한 개의 AFTER UPDATE 트리거는 가질 수 있다.
trigger_stmt 는 트리거가 활성화될 때 실행할 수 있는 명령문이다. 만일, 다중 명령문을 실행하고자 한다면, BEGIN ... END 복합
명령문 구성을 사용하면 된다. 이것은 스토어드 루틴내에서 사용 가능한 동일한 명령문에서도 적용할 수 있다 Section 17.2.5,
“BEGIN ... END 복합 명령문 신텍스” 참조.
Note: 현재의 버전에서는, 연속적인 외국어 키 동작(cascaded foreign key actions )으로 트리거를 활성화 시킬 수는 없다. 이 제
약 사항은 가능한 한 빠른 시간 내에 수정될 예정이다.
Note: MySQL 5.0.10 이전에는, 이름을 가지고 직접 테이블을 참조할 수는 없었다. MySQL 5.0.10이후에는, 이 예문에서 보듯
이, testref 로 명기된 것과 같은 트리거를 사용할 수 있게 된다:
CREATE TABLE test1(a1 INT);
CREATE TABLE test2(a2 INT);
CREATE TABLE test3(a3 INT NOT NULL AUTO_INCREMENT PRIMARY KEY);
CREATE TABLE test4(
a4 INT NOT NULL AUTO_INCREMENT PRIMARY KEY,
b4 INT DEFAULT 0
);
DELIMITER |
CREATE TRIGGER testref BEFORE INSERT ON test1

FOR EACH ROW BEGIN
INSERT INTO test2 SET a2 = NEW.a1;
DELETE FROM test3 WHERE a3 = NEW.a1;
UPDATE test4 SET b4 = b4 + 1 WHERE a4 = NEW.a1;
END;
|

:::MySQL Korea:::
DELIMITER ;
INSERT INTO test3 (a3) VALUES

(NULL), (NULL), (NULL), (NULL), (NULL),
(NULL), (NULL), (NULL), (NULL), (NULL);
INSERT INTO test4 (a4) VALUES

(0), (0), (0), (0), (0), (0), (0), (0), (0), (0);
아래의 값을 테이블 test1에 아래와 같이 삽입을 한다고 가정하자:
mysql> INSERT INTO test1 VALUES
-> (1), (3), (1), (7), (1), (8), (4), (4);
결과적으로는, 아래와 같이 네 개의 테이블에 데이터가 있게 된다:

mysql> SELECT * FROM test1;
+------+
| a1 |
+------+
| 1|
| 3|
| 1|
| 7|
| 1|
| 8|
| 4|
| 4|
+------+

:::MySQL Korea:::

+------+
| a2 |
+------+
| 1|
| 3|
| 1|
| 7|
| 1|
| 8|
| 4|
| 4|
+------+

+----+
| a3 |
+----+

:::MySQL Korea:::
제목검색
18.2. DROP TRIGGER 신텍스
18. 트리거
DROP TRIGGER [schema_name.]trigger_name
18.2. DROP TRIGGER 신텍스
18.2 DROP TRIGGER 신텍스 이 명령문은 트리거를 드롭(drop) 시킨다. 스키마(데이터베이스)이름은 옵션 사항이다. 만일 스키마가 생략되면, 트리거는 디폴트
스키마로부터 드롭 된다. DROP TRIGGER은 MySQL 5.0.2에서 추가 되었다. 이것을 사용하기 위해서는 SUPER권한이 요구된
다.
Note: MySQL 5.0.10 이전에서는, 스키마 이름(table_name.trigger_name ) 대신에 테이블 이름이 필요하였다. MySQL 5의 이
전 버전에서 MySQL 5.0.10 또는 그 이상의 버전으로 업그레이드할 때에는, you must drop all triggers 업그레이드를 하기 전에
반드시 모든 트리거를 드롭 시키고 나중에 다시 재생성 시켜야 하며, 그렇게 하지 않으면 DROP TRIGGER 는 업그레이드 후에 동
작을 하지 않게 된다. 업그레이드 과정에 대한 제안에 대해서는 Section 2.10.2, “MySQL 4.1에서5.0으로 업그레이드 하기”를
참조하기 바람.
:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 18.3. 트리거 사용하기

트리거에 대한 지원은 MySQL 5.0.2에서부터 포함된다. 이 섹션에서는 트리거를 어떻게 사용하는지 그리고 트리거를 사용하는데
18. 트리거 있어서 어떤 제약 사항이 있는지에 대해 설명하기로 한다. 트리거의 제약 사항에 대한 추가적이 내용은 Section I.1, “스토어드 루
18.3. 트리거 사용하기 틴과 트리거상의 제약 사항”에서 제공하기로 한다.
18.3 트리거 사용하기 트리거는 테이블과 연관된 이름이 있는 데이터 베이스 오브젝트이며, 테이블에 대해 특정 이벤트가 발생하면 활성화된다. 어떤 트
리거는 테이블 안으로 삽입하고자 하는 값을 검사하는 기능을 수행하거나 또는 업데이트에서 호출한 값을 계산하는 기능을 수행한
다.
트리거는 테이블과 관련이 있고, 테이블에 대한 INSERT, DELETE 또는 UPDATE명령문이 실행될 때에 활성화가 정의된다. 트리
거는 이를 실행하는 명령문의 앞에서 또는 뒤에서 활성화 되도록 설정할 수 있다. 예를 들면, 트리거가 테이블에서 삭제되는 각 줄
(row)전에 활성화 되도록 할 수 있거나 또는 각 줄이 업데이트된 후에 활성화 되도록 할 수도 있다.
트리거를 생성 또는 드롭 시키기 위해서는, CREATE TRIGGER 또는 DROP TRIGGER 명령문을 사용한다. 이러한 명령문에 대
한 신텍스는 Section 18.1, “CREATE TRIGGER 신텍스”, 및 Section 18.2, “DROP TRIGGER 신텍스”에서 설명하였다.
INSERT명령문에 대한 테이블을 갖는 트리거와 관련된 간단한 예문을 보여주기로 한다. 이것은 테이블의 컬럼 중에 하나에 삽입
된 값을 더하는 연산자의 역할을 한다.
아래의 명령문은 테이블을 생성하고 이에 해당하는 트리거를 만들게 된다:
mysql> CREATE TABLE account (acct_num INT, amount DECIMAL(10,2));
mysql> CREATE TRIGGER ins_sum BEFORE INSERT ON account
-> FOR EACH ROW SET @sum = @sum + NEW.amount;
CREATE TRIGGER 명령문은 ins_sum이라는 이름의 트리거를 생성하며 이것은 account라는 테이블과 연관된다. 이것은 또한
트리거의 동작 시간, 트리거하는 이벤트, 그리고 트리거를 활성화 하면서 해야 할 일들을 지정한다:
● 키워드 BEFORE는 트리거 실행 시간을 가리킨다. 이와 같은 경우, 트리거는 각 줄이 테이블에 삽입되기 전에 실행되어야
한다. 다른 사용 가능한 키워드는 AFTER이다.
● 키워드 INSERT는 트리거를 실행시키는 이벤트를 가리킨다. 예를 들면, INSERT 명령문은 트리거 실행을 일으킨다. 여러
분은 또한 DELETE 와 UPDATE 명령문을 위한 트리거도 생성할 수가 있다.
● FOR EACH ROW에 따라오는 명령문은 트리거 실행을 일으키는 명령문을 정의하는데, 트리거를 하는 명령문에 의해 영향

:::MySQL Korea:::
을 받는 각 줄에 한번씩 발생하게 된다. 예문에서 보면, 트리거가 된 명령문은 amount 컬럼 안으로 삽입되는 값을 합하는
단순한 SET이 된다. 그 명령문은 “새로운 줄 속으로 삽입되어지는 amount 컬럼의 값”을 의미하는 NEW.amount 의 형
태로 컬럼을 참조하고 있다.
트리거를 사용하기 위해서는, 누산기 변수를 0으로 설정하고, INSERT 명령문을 실행하고, 그 다음에는 변수의 값이 어떻게 나오
는지 보자:
mysql> SET @sum = 0;
mysql> INSERT INTO account VALUES(137,14.98),(141,1937.50),(97,-100.00);
mysql> SELECT @sum AS 'Total amount inserted';
+-----------------------+
| Total amount inserted |
+-----------------------+
| 1852.48 |
+-----------------------+
이와 같은 경우, INSERT명령문이 실행된 다음에 나오는 @sum 의 값은 14.98 + 1937.50 - 100, or 1852.48이 된다.
트리거를 없애기 위해서는, DROP TRIGGER 명령문을 사용한다. 만일 트리거가 디폴트 스키마에 있지 않으면, 스키마의 이름을
정확히 지정해야 한다.:
mysql> DROP TRIGGER test.ins_sum;
트리거의 이름은 스키마 이름란에 존재해야 하고, 이것은 하나의 스키마에 있는 트리거들은 서로 다른 이름을 가져야 함을 의미한
다. 서로 다른 스키마에 있는 트리거들은 같은 이름을 가져도 된다..
트리거가 하나의 스키마에 대해 중복되지 않는 이름을 가져야 한다는 조건에 이외에도, 트리거를 생성하는데 있어서 몇 가지 다른
제약 사항도 있다. 특히, 하나의 테이블에는 동일한 활성화 시간 및 이벤트를 갖는 두 개의 트리거를 가질 수 없다. 예를 들면, 하나
의 테이블에 대해 두 개의 BEFORE INSERT 트리거 또는 두 개의 AFTER UPDATE 트리거를 가질 수 없다. 이것은 그다지 중요
하지 않은 제약 사항인데, 그 이유는 FOR EACH ROW 다음에BEGIN ... END 복합 명령문 구성을 사용해서 다중 명령문을 실행하
는 트리거를 정의할 수 있기 때문이다. (하나의 예문이 이 섹션 후반부에 있다.)
OLD 와 NEW 키워드를 사용해서 트리거에 의해 영향을 받는 줄에 있는 컬럼을 활성화 시킬 수 있다. (OLD 와 NEW 는 대소문자
구분을 하지 않음.) INSERT 트리거에는, NEW.col_name 만을 사용할 수 있다; 여기에는 이전 줄(old row)이 없다. DELETE 트
리거에는, OLD.col_name 만을 사용할 수 있다; 여기에는 새로운 줄(new row)이 없다. UPDATE 트리거에는, 줄(row)이 업데이
트되기 전에 그 줄에 있는 컬럼을 참조하도록 OLD.col_name 을 사용할 수 있으며, 줄이 업데이트된 후에 그 줄에 있는 컬럼을 참
조하도록 NEW.col_name 을 사용할 수 있다.
OLD 로 표시된 컬럼은 읽기 전용(read-only)이다. 만일 SELECT권한이 있다면 이것을 참조할 수는 있으나, 수정할 수는 없다.

:::MySQL Korea:::
NEW로 표시된 컬럼은, SELECT권한이 있다면, 참조될 수 있다. BEFORE 트리거에 있어서는, 이것에 대한 UPDATE권한이 있
는 경우에는 SET NEW.col_name = value 을 가지고 그 값을 변경할 수 있다. 이것은 트리거를 사용해서 새로운 줄에 삽입될 값
을 수정할 수 있거나 또는 줄을 업데이트할 수 있다는 것을 의미한다.
BEFORE 트리거에 있어서는, AUTO_INCREMENT 컬럼에 대한 NEW의 값은 0이 되며, 이 값은 실제로 새로운 기록이 삽입될
때 나오게 되는 자동 생성 시퀀스 숫자는 아니다.
OLD 와 NEW 는 트리거에 대한 MySQL의 확장 기능이다.
BEGIN ... END 명령문 구성을 사용해서, 다중 명령문을 실행하는 트리거를 정의할 수 있다. BEGIN 블록 안에서는, 조건문과 루
프 같은 스토어드 루틴 안에서 사용 가능한 다른 신텍스를 사용할 수도 있다. 하지만, 스토어드 루틴에 대한 것과 마찬가지로,
mysql 프로그램을 사용해서 다중 명령문을 실행하는 트리거를 정의하고자 한다면, 트리거 정의에서 ; 명령문 구획 문자를 사용하
기 위해서는MYSQL명령문 구획 문자(delimiter)를 재 정의하는 것이 필요하다. 다음의 예문은 이런 점을 표현하는 것이다. 여기에
서 UPDATE 트리거는 각 줄의 업데이트에 사용되는 새로운 값을 검사하도록 정의되며, 그리고 그 값이 0에서부터 100의 범위 내
에 있도록 수정한다. 이것은 값이 줄을 업데이트 하기 전에 검사되어야 하기 때문에 BEFORE 트리거가 되어야 한다:
mysql> delimiter //
mysql> CREATE TRIGGER upd_check BEFORE UPDATE ON account
-> FOR EACH ROW
-> BEGIN
-> IF NEW.amount < 0 THEN
-> SET NEW.amount = 0;
-> ELSEIF NEW.amount > 100 THEN
-> SET NEW.amount = 100;
-> END IF;
-> END;//
mysql> delimiter ;
이렇게 하면 스토어드 프로시저를 개별적으로 정의하고 그 다음에 간단한 CALL명령문을 사용하는 트리거로부터 호출하는 것을
더 쉽게 할 수 있다. 이것은 또한 몇몇 트리거 내에서부터 동일한 루틴을 호출하고자 할 경우에 장점을 가지게 된다.
트리거가 활성화 될 때 실행하는 명령문에는 몇 가지 제약 사항이 존재한다:
● 트리거는 데이터를 클라이언트에 돌려 주는 스토어드 프로시저 또는 동적(dynamic)SQL을 사용하는 스토어드 프로시저

를 호출하는 CALL명령문은 사용할 수 없다. (스토어드 프로시저가 OUT 또는 INOUT파라미터를 통해서 데이터를 트리거
에 돌려 주는 것은 허용된다.)
● 트리거는 START TRANSACTION, COMMIT, 또는ROLLBACK과 같은 확정적(explicitly)으로 또는 암시적

:::MySQL Korea:::
(implicitly)으로 트랜잭션을 시작 또는 종료하는 명령문은 사용할 수 없다.

● MySQL 5.0.10 이전 버전에서는, 트리거는 이름을 가지고 테이블 직접 참조를 할 수 없다.
MySQL은 트리거 실행 동안에 발생하는 에러를 아래와 같이 처리한다:
● BEFORE 트리거가 실패(fails)할 경우, 이에 대응하는 줄에 대한 동작은 수행되지 않는다.

● AFTER 트리거는 BEFORE트리거(존재 한다면)와 줄에 대한 동작 모두 성공적으로 실행될 경우에만 실행된다.
● BEFORE 또는 AFTER트리거의 실행 동안 발생되는 에러는 트리거 호출을 일으키는 전체 명령문의 실패를 일으킨다.
● 트랜잭션 테이블에 대해서는, 트리거의 실패(이에 따른 전체 명령문 실패)는 명령문에 의해 진행된 모든 데이터 변경의 롤
백을 일으키게 된다. 비 트랜잭션 테이블(non-transactional tables)에 대해서는, 이러한 롤백은 일어날 수 없으며, 따라
서 비록 명령문이 실패한다 하더라도, 에러가 발생한 시점 이전에 진행된 어떠한 데이터 변경도 그대로 유지된다.

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ Chapter 19. 뷰(Views)

19.1. ALTER VIEW 신텍스
19. 뷰(Views) 19.2. CREATE VIEW 신텍스
19 뷰(Views) 19.3. DROP VIEW 신텍스
19.1 ALTER VIEW 신텍스 19.4. SHOW CREATE VIEW 신텍스

뷰(Views) (업데이트 가능한 뷰 포함)는 MySQL Server 5.0에서부터 지원되며, 5.0.1및 이후 버전부터는 바이너리 릴리즈에서
19.2 CREATE VIEW 신텍스
사용 가능하다.
이 장에서는 아래의 주제에 대해 다루기로 한다:
● CREATE VIEW 또는 ALTER VIEW를 가지고 뷰를 생성하기 또는 변경하기

● DROP VIEW를 가지고 뷰를 없애기
● SHOW CREATE VIEW를 가지고 뷰의 메타 데이터를 보여 주기
뷰의 사용 제약 사항에 대해서는 Section I.4, “뷰의 사용 제약 사항”에서 설명하기로 한다.

이전 버전에서 5.0.1버전으로 업그레이드를 한 후 뷰를 사용하기 위해서는, 그랜트 테이블이 뷰 관련(view-related) 권한을 가지
도록 업그레이드 해야 한다. Section 5.6, “mysql_fix_privilege_tables — MySQL 시스템 테이블 업그레이드”을 참조할 것.
:::MySQL Korea:::
제목검색
19. 뷰(Views)
ALTER
19.1 ALTER VIEW 신텍스 [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]
[DEFINER = { user | CURRENT_USER }]
[SQL SECURITY { DEFINER | INVOKER }]
VIEW view_name [(column_list)]
AS select_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]
이 명령문은 현재 존재하는 뷰의 정의를 변경하는 것이다. 신텍스는 CREATE VIEW에서와 비슷하다. Section 19.2,
“CREATE VIEW 신텍스”를 참조. 이 명령문은 뷰에 대해 CREATE VIEW 및 DROP 권한을 요구하고, 그리고 각 컬럼에 대한
몇 가지 권한은 SELECT명령문에 있는 것을 참조하였다..
이 명령문은 MySQL 5.0.1에서 추가 되었다. DEFINER 및 SQL SECURITY 구문은 MySQL 5.0.16에서 사용될 것인데, 뷰 호출
시점에 접속 권한을 검사할 때 사용되는 보안 문장을 지정하는데 사용된다.자세한 내용은 Section 19.2, “CREATE VIEW 신텍
스”를 참조 한다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
19.2. CREATE VIEW신텍스

CREATE
19. 뷰(Views) [OR REPLACE]
19.2. CREATE VIEW 신텍스 [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]
19.2 CREATE VIEW 신텍스 [DEFINER = { user | CURRENT_USER }]
[SQL SECURITY { DEFINER | INVOKER }]
VIEW view_name [(column_list)]
AS select_statement
[WITH [CASCADED | LOCAL] CHECK OPTION]
이 명령문은 새로운 뷰를 생성하거나, 또는 OR REPLACE구문이 있다면 현재 있는 뷰를 대체한다. select_statement는 뷰의 정의

를 제공하는SELECT명령문이다. 이 명령문은 베이스 테이블(base table) 또는 다른 뷰에서 선택(select)을 할 수 있다.
이 명령문은 뷰에 대해 CREATE VIEW권한을 요구하며, SELECT명령문에 의해 선택된 각 컬럼에 대해서도 별도의 권한을 요구
하게 된다. SELECT명령문에서 사용된 컬럼에 대해서는 반드시 SELECT권한을 가져야 한다. 만일OR REPLACE구문이 존재하
면, 뷰에 대해서 DROP권한도 있어야만 한다.
뷰는 데이터 베이스에 소속된다. 디폴트로는, 새로운 뷰는 디폴트 데이터 베이스에서 생성된다. 주어진 데이터 베이스에서 확정적
으로 뷰를 생성하기 위해서는, 뷰를 생성할 때 db_name.view_name처럼 이름을 지정 해야 한다.
mysql> CREATE VIEW test.v AS SELECT * FROM t;
베이스 테이블 및 뷰는 하나의 데이터 베이스에서 동일한 이름 공간(namespace)를 공유한다. 따라서, 데이터 베이스는 동일한 이
름을 갖는 베이스 테이블과 뷰를 가질 수 없다.
뷰는 중복되지 않는 고유의 컬럼 이름을 가져야만 하는데, 베이스 테이블도 마찬가지다. 디폴트로는, SELECT명령문으로 추출한
컬럼의 이름은 뷰 컬럼 이름으로 사용된다. 뷰 컬럼에 대해 확정적인 이름을 정의하기 위해서는, 선택적인column_list구문이 콤
마-구분 식별자(comma-separated identifiers) 리스토로서 주어질 수 있다. column_list안에 있는 이름의 숫자는 반드시
SELECT명령문으로 추출한 컬럼의 숫자와 일치하여야 한다.
SELECT명령문으로 추출한 컬럼은 테이블 컬럼에 대한 단순 참조가 될 수 있다. 이러한 컬럼은 함수, 항수값(constant value), 오
퍼레이터(operator), 및 기타의 것을 사용하는 수식이 될 수도 있다.

:::MySQL Korea:::
검증되지 않은 테이블 또는 SELECT명령문에 있는 뷰 이름은 디폴트 데이터 베이스에 관련해서 해석된다. 뷰는 적절한 데이터 베
이스 이름을 가진 테이블 또는 뷰의 검증을 통해 다른 데이터 베이스에 있는 테이블 또는 뷰를 참조할 수 있다.
뷰는 많은 종류의 SELECT명령문을 가지고 생성할 수 있다. 뷰는 베이스 테이블 또는 다른 뷰를 참조할 수 있다. 뷰는 결합
(join), UNION, 및 서브쿼리(subqueries)를 사용할 수 있다. SELECT명령문은 다른 테이블을 참조할 필요는 없다. 아래의 예문
은 다른 테이블로부터 두 개의 컬럼을 선택하는 뷰를 정의하는 것인데, 이것은 또한 이렇게 선택한 컬럼으로부터 계산된 수식을 정
의하기도 한다:
mysql> CREATE TABLE t (qty INT, price INT);
mysql> INSERT INTO t VALUES(3, 50);
mysql> CREATE VIEW v AS SELECT qty, price, qty*price AS value FROM t;
mysql> SELECT * FROM v;
+------+-------+-------+
| qty | price | value |
+------+-------+-------+
| 3| 50 | 150 |
+------+-------+-------+
뷰의 정의에는 아래와 같은 제약 사항이 있다:
● SELECT명령문은 FROM구문에 있는 서브쿼리를 가질 수 없다.

● SELECT명령문은 시스템 또는 사용자 변수를 참조할 수 없다.
● SELECT명령문은 준비 명령문 파라미터(prepared statement parameters)을 참조할 수 없다.
● 스토어드 루틴 내에서는, 뷰 정의는 루틴 파라미터 또는 로컬 변수를 참조할 수 없다.
● 테이블 또는 뷰가 정의문 내에서 참조되기 위해서는 이미 존재해 있어야 한다. 하지만, 뷰가 생성된 후에는, 정의문이 참조
하는 테이블 또는 뷰를 없애는 것(drop)은 가능하다. 이런 종류의 문제에 대한 뷰 정의를 검사하기 위해서는, CHECK
TABLE명령문을 사용한다.
● 뷰 정의문은 TEMPORARY테이블을 참조할 수 없으며, 사용자는 EMPORARY를 생성할 수 없다.
● 뷰 정의문에 있는 테이블은 반드시 이미 존재해 있어야 한다.
● 트리거를 뷰에 연관 지을 수는 없다.
뷰 정의문에 ORDER BY를 사용할 수 있으나, 명령문 자체에 ORDER BY가 있는 명령문을 사용하는 뷰로부터 선택하는 것은 무시
된다.
정의문안에 있는 다른 옵션 또는 구문에 대해서는, 뷰를 참조하는 명령문의 옵션 또는 구문에 추가될 수는 있으나, 그 효과는 정의

:::MySQL Korea:::
되지 않는다. 예를 들면, 뷰 정의문이LIMIT구문을 포함한다면, 그리고 자체에 LIMIT구문을 갖는 명령문을 사용해서 뷰에서 선택
을 한다면, 그것이 어떤 제한을 적용하는지 정의되지 않는다. 이와 동일한 원칙이 SELECT키워드 뒤에 나오는 ALL, DISTINCT,
또는 SQL_SMALL_RESULT와 같은 옵션에도 적용되며, 또한INTO, FOR UPDATE, LOCK IN SHARE MODE, 및
PROCEDURE구문에도 적용된다.
만일 뷰를 생성한 후, 변경한 시스템 변수를 가지고 쿼리 프로세싱 환경을 변경시키면, 뷰로부터 얻게 되는 결과는 영향을 받는다:
mysql> CREATE VIEW v AS SELECT CHARSET(CHAR(65)), COLLATION(CHAR(65));
mysql> SET NAMES 'latin1';


+-------------------+---------------------+
| CHARSET(CHAR(65)) | COLLATION(CHAR(65)) |
+-------------------+---------------------+
| latin1 | latin1_swedish_ci |
+-------------------+---------------------+
mysql> SET NAMES 'utf8';


+-------------------+---------------------+
| CHARSET(CHAR(65)) | COLLATION(CHAR(65)) |
+-------------------+---------------------+
| utf8 | utf8_general_ci |
+-------------------+---------------------+
DEFINER및 SQL SECURITY구문은 뷰 호출 시에 접근 권한을 검사할 때 사용되는 보안 문장을 나타낸다. 이런 기능들은
MySQL 5.0.13에 추가된 것이나, MySQL 5.0.16 까지는 효과를 나타내지 않는다.

:::MySQL Korea:::
CURRENT_USER는 또한 CURRENT_USER()방식으로 주어질 수도 있다.

SQL SECURITY DEFINER특성을 가지고 정의된 루틴 안에서는, CURRENT_USER는 루틴 생성자(routine creator)를 리턴한
다. 이것은 또한 만일 뷰 정의문이 CURRENT USER의 DEFINER값을 갖고 있다면, 그와 같은 루틴내 안에서 정의된 뷰에도 영향
을 주게 된다.
디폴트 DEFINER값은CREATE VIEW를 실행하는 사용자가 된다. (이것은 DEFINER = CURRENT_USER형태와 같다) 만일
user값이 주어진다면, 그것은 'user_name'@'host_name'포맷의 MySQL 계정이 될 것이다. (이 포맷은 GRANT명령문에서 사용
되는 것과 같은 포맷이다). user_name와 host_name값이 모두 필요하다.
여러분이 DEFINER구문을 지정하면, 여러분이 SUPER 권한이 없는 한 자신 이외의 다른 사용자 값을 설정할 수 없게 된다. 이러
한 규칙은 리걸(legal) DEFINER사용자 값을 결정한다:
● SUPER권한이 없다면, 유일한 리걸(legal) user값은 여러분 자신의 계정만 된다. 다른 계정에 디파이너(definer)를 설정
할 수가 없다.
● SUPER권한이 있다면, 모든 리걸 계정 이름을 지정할 수 있다. 만약에 계정이 실제로 존재하지 않으면, 경고문이 나오게 된
다.
SQL SECURITY는 뷰가 실행될 때 뷰에 대한 접근 권한을 검사를 하기 위해 사용되는 계정이 어떤 것인지를 결정한다. 리걸 특성

값은 DEFINER과 INVOKER가 된다. 이 값들은 뷰를 정의하거나 또는 호출한 사용자에 의해서만 뷰가 각각 실행되어야 한다는 것
을 가리킨다. 디폴트 SQL SECURITY값은 DEFINER이다.
MySQL 5.0.16 (DEFINER와 SQL SECURITY구문이 구현되었을 때) 이후로, 뷰 권한은 아래와 같이 검사된다:
● 뷰 정의 시점에는, 뷰 생성기(creator)는 반드시 뷰가 접근하는 최상위 레벨의 오브젝트를 사용할 수 있는 권한이 있어야
한다. 예를 들면, 뷰 정의문이 스토어드 함수를 참조한다면, 함수를 호출하는데 필요한 권한만을 검사한다. 함수가 구동될
때에 필요한 권한은 함수가 실행될 때에만 검사된다: 함수에 대한 여러 가지 호출에 대해서는, 함수내의 서로 다른 실행 플
랜이 선택 된다.
● 뷰 실행 시점에는, 뷰가 접근하는 오브젝트에 대한 권한은 뷰 생성시 또는 호출기가 가지고 있는 권한에 대응해서 검사되는
데, SQL SECURITY특성이 각각 DEFINER인지 또는 INVOKER인지에 따라서 결정된다.

● 만약에 뷰 실행이 스토어드 함수의 실행을 발생 시킨다면, 함수내에서 실행되는 명령문에 대한 권한 검사는 함수가
DEFINER또는 INVOKER의 SQL SECURITY특성을 가지고 정의 되었는지에 따라 진행된다. 보안 특성이 DEFINER라
면, 함수는 이 생성기의 권한을 가지고 구동된다. 특성이 INVOKER라면, 함수는 뷰의 SQL SECURITY특성에 의해 결정
된 권한을 가지고 구동된다.

:::MySQL Korea:::
MySQL 5.0.16 (DEFINER와 SQL SECURITY구문이 구현 되기 전에) 이전에는, 뷰에서 사용되는 오브젝트에 대한 요구 권한은
뷰 생성 시점에 검사 되었다.
예제: 뷰는 스토어드 함수에 의존 하며, 다른 스토어드 루틴을 호출하는 함수에도 의존하기도 한다. 예를 들면, 아래의 뷰는 스토어
드 함수 f()를 호출한다:
CREATE VIEW v AS SELECT * FROM t WHERE t.id = f(t.name);
f()가 아래와 같은 명령문을 가지고 있다고 가정하자:
IF name IS NULL then
CALL p1();
ELSE
CALL p2();
END IF;
f()안에 있는 명령문 실행을 위해 필요한 권한은 need to be checked when f()이 실행될 때 검사할 필요가 있다. 이것은 f()안에
있는 실행 경로에 따라, p1()또는 p2()에 필요한 권한이 요구 된다는 것을 의미한다. 이러한 권한들은 런타임 시에 검사될 필요가
있고, 이러한 권한을 가지고 있어야 하는 사용자는 함수 f()와 뷰 v의 SQL SECURITY값을 가지고 결정된다.
뷰에 대한DEFINER와 SQL SECURITY구문은 표준 SQL에 대한 확장이다. 표준 SQL에서, 뷰는 SQL SECURITY INVOKER에
대한 규칙을 사용해서 다루어 진다.
MySQL 5.0.13 이전에 생성된 뷰를 호출 한다면, 그러한 뷰는 마치 SQL SECURITY INVOKER구문과 여러분 계정과 동일한
DEFINER값을 가지고 생성된 것처럼 취급된다. 하지만, 실제의 디파이너(definer)는 알려져 있지 않기 때문에, MySQL은 경고문
을 발생 시키게 된다. 경고문을 없애기 위해서는, 뷰를 재 생성해서 뷰 정의문이 DEFINER구문을 포함하도록 하는 것 만으로도 충
분하다.
선택 사항인 ALGORITHM구문은 표준 SQL에 대한 MySQL 확장이다. ALGORITHM은 세가지 값을 가진다: MERGE,
TEMPTABLE, or UNDEFINED. 디폴트 알고리즘은 ALGORITHM구문이 존재하지 않는다면, UNDEFINED이 된다. 알고리즘
은 MySQL이 뷰를 처리하는 방법에 영향을 준다.
MERGE의 경우, 뷰와 뷰 정의문을 참조하는 명령문의 문장은 명령문의 부분과 상응되는 뷰 대체 정의문 부분과 병합된다.
TEMPTABLE의 경우, 뷰에서 나온 결과는 임시 테이블 속으로 들어가게 되는데, 이것은 명령문을 실행하기 위해 사용된다.
UNDEFINED의 경우, MySQL은 사용할 알고리즘을 선택한다. 가능하다면 MySQL은 MERGE를 선호하게 되는데, 왜냐하면
MERGE는 일반적으로 보다 효율적이며 또한 뷰는 임시 테이블이 사용되는 경우에는 업데이트를 할 수 없기 때문이다.
확실하게 TEMPTABLE가 선택되는 경우는 임시 테이블이 생성되고 임시 테이블이 명령문 수행을 마치기 위해 사용되기 전에 잠
금이 언더라잉(underlying) 테이블에서 릴리즈될 수 있을 경우만 해당된다. 이것의 결과로 잠금 릴리즈가 MERGE알고리즘 보다
빨리 구현되며, 따라서 뷰를 사용하는 다른 클라이언트가 더 이상 갇히지 않게 된다.
뷰 알고리즘은 세 가지 이유로 UNDEFINED될 수 있다:

:::MySQL Korea:::
● CREATE VIEW명령문안에 ALGORITHM구문이 전혀 없다.

● CREATE VIEW명령문이 명확한 ALGORITHM = UNDEFINED구문을 가지고 있다.
● ALGORITHM = MERGE이 임시 테이블을 가지고서 만 처리되는 뷰를 위해 지정된다. 이와 같은 경우, MySQL은 경고문
을 내 보내고 알고리즘을 UNDEFINED으로 설정한다.
앞에서 언급을 했듯이, MERGE는 뷰를 참조하는 명령문 속으로 뷰 정의문을 병합 시키는 방식으로 처리된다. 아래의 예제에서는
MERGE알고리즘이 어떻게 동작되는지에 대해 간단하게 설명을 하고 있다. 이 예제는 뷰 v_merge가 다음과 같은 정의를 가지고
있다고 가정한다:
CREATE ALGORITHM = MERGE VIEW v_merge (vc1, vc2) AS
SELECT c1, c2 FROM t WHERE c3 > 100;
Example 1: 다음의 명령문을 입력한다고 가정한다:
SELECT * FROM v_merge;
MySQL은 명령문을 아래와 같이 처리한다:
● v_merge은 t이 된다.
● *은 vc1, vc2가 되고, 이것은 c1, c2에 대응된다.
● 뷰 WHERE구문이 추가된다.
실행될 명령문은 아래와 같이 된다:

SELECT c1, c2 FROM t WHERE c3 > 100;
Example 2: 아래의 명령문을 입력한다고 하자:
SELECT * FROM v_merge WHERE vc1 < 100;
이 명령문은 이전의 것과 비슷하게 처리되지만, vc1 < 100이 c1 < 100이 되고 뷰 WHERE구문이 AND을 사용해서 WHERE구
문에 추가되는 것은 다르다. (그리고 구문의 일부분이 정확한 우선권을 가지고 실행되도록 하기 위해 괄호가 추가 된다). 실행되어
야 할 명령문은 다음이 된다:
SELECT c1, c2 FROM t WHERE (c3 > 100) AND (c1 < 100);
실행될 명령문은 아래의 형태의 WHERE구문을 가지게 된다:
WHERE (select WHERE) AND (view WHERE)
MERGE알고리즘은 뷰에 있는 줄과 언더라잉(underlying) 테이블에 있는 줄과 일대일 대응 관계가 되는 것을 요구한다. 만약에 이
러한 대응 관계가 이루어지지 않으면, 임시 테이블이 대신 사용되어야 한다. 만약에 뷰가 아래의 구성 중에 하나라도 가지고 있으

:::MySQL Korea:::
면 일대일 대응 관계의 부족이 발생한다:
● Aggregate functions (SUM(), MIN(), MAX(), COUNT(), 등등)
● DISTINCT
● GROUP BY
● HAVING
● UNION or UNION ALL
● 문자 값만을 참조 (이와 같은 경우, 언더라잉(underlying) 테이블에 없게 된다)
어떤 뷰들은 업데이트가 가능하다. 즉, 여러분은you can use them in statements such as UPDATE, DELETE, 또는 INSERT
와 같은 명령문에 있는 뷰들을 사용해서 언더라인 테이블의 내용을 업데이트 할 수가 있다. 또한, 업데이트가 되지 않도록 뷰를 구
성할 수도 있다. 보다 특징적으로 하기 위해서, 뷰는 아래의 것 중에 하나를 가지고 있으면 업데이트가 되지 않는다:
● Aggregate functions (SUM(), MIN(), MAX(), COUNT(), 등등)
● DISTINCT
● GROUP BY
● HAVING
● UNION또는 UNION ALL
● 선택한 리스트에 있는 서브 쿼리
● 조인(Join)
● FROM구문에 있는 업데이트할 수 없는(non-updatable) 뷰

● FROM구문에 있는 테이블을 참조하는 WHERE구문에 있는 서브쿼리
● 문자 값만을 참조 (이와 같은 경우, 업데이트할 언더라잉 테이블이 없다)
● ALGORITHM = TEMPTABLE (임시 테이블 사용은 항상 뷰를 업데이트 불가능 한 것으로 만든다)
삽입이 가능하게 끔 하는 것과 관련해서는 (INSERT명령문을 가지고 업데이트가 될 수 있도록), 업데이트가 가능한 뷰는 뷰 컬럼

에 대해 아래의 부가적인 요구 사항이 만족된다면 삽입 가능해(insertable) 진다:
● 뷰 컬럼 이름이 중복 사용되지 말아야 한다.

● 뷰는 디폴트 값을 가지고 있지 않는 베이스 테이블에 있는 모든 컬럼을 가지고 있어야 한다.
● 뷰 컬럼은 단순 컬럼 참조(simple column reference)만 하고 컬럼을 가져오지는(derived column) 않는다. 획득하는 컬

:::MySQL Korea:::
럼(derived column)은 수식에서 얻어지는 것이다. 아래에 획득하는 컬럼의 예가 있다:
• 3.14159
• col1 + 3
• UPPER(col2)
• col3 / col4
• (subquery)
단순 컬럼 참조와 획득 컬럼을 모두 갖고 있는 뷰는 삽입이 불가능 하지만, 획득되지 않은 컬럼만을 업데이트 하는 것은 가능하다.
아래의 뷰를 고려해 보자:
CREATE VIEW v AS SELECT col1, 1 AS col2 FROM t;
이 뷰는 col2가 수식에서 얻어진 것이기 때문에 삽입 불가능한 것이 된다. 하지만 업데이트가 col2를 업데이트 하고자 시도하지 않
는다면 업데이트 가능하다. 이러한 업데이트는 허용된다:
UPDATE v SET col1 = 0;
이러한 업데이트는 허용되지 않는데, 그 이유는 획득한 컬럼을 업데이트 하려는 시도를 하기 때문이다:
UPDATE v SET col2 = 0;
때로는 다중-테이블 뷰가 MERGE를 가지고 처리될 수 있다는 가정하에서는 업데이트 가능한 것으로 만드는 것이 가능하다. 이렇
게 동작 시키기 위해서는, 뷰는 반드시 내부 조인(inner join)(외부 조인(outer join 또는 UNION이 아님)을 사용해야 한다. 또한,
뷰 정의문에 있는 단일 테이블만이 업데이트 될 수 있는데, 따라서 SET구문은 뷰 안에 있는 테이블 중의 하나로부터 컬럼 만을 지
명해야 한다. UNION ALL을 사용하는 뷰는 비록 이론적으로는 업데이트 가능한 것이지만 업데이트가 될 수가 없다. 그 이유는 이
런 뷰를 처리하기 위해서 서버는 임시 테이블을 사용하기 때문이다.
다중-테이블 업데이트 가능 뷰에 대해서는, INSERT가 단일 테이블 안으로 삽입 동작을 하는 것은 가능하다. DELETE는 지원되
지 않는다.
select_statement에 있는 WHERE구문이 트루(true)인 경우를 제외하고, 업데이트 뷰가 줄을 업데이트 또는 삽입하지 못하도록
WITH CHECK OPTION구문을 제공할 수 있다.
업데이트 뷰에 대한 WITH CHECK OPTION구문에서, LOCAL과 CASCADED키워드는 뷰가 다른 뷰의 형태로 정의 될 때 검사
테스트의 범위를 결정한다. LOCAL키워드는 정의 되는 뷰에만 CHECK OPTION을 제한한다. CASCADED구문은 언더라잉
(underlying)뷰의 값도 함께 검사를 하도록 만든다. 아무런 키워드도 주어지지 않는다면, 디폴트는 CASCADED가 된다. 아래의
테이블 정의문과 뷰 셋을 검토해 보자:
mysql> CREATE TABLE t1 (a INT);
mysql> CREATE VIEW v1 AS SELECT * FROM t1 WHERE a < 2
-> WITH CHECK OPTION;

:::MySQL Korea:::
mysql> CREATE VIEW v2 AS SELECT * FROM v1 WHERE a > 0

-> WITH LOCAL CHECK OPTION;
mysql> CREATE VIEW v3 AS SELECT * FROM v1 WHERE a > 0
-> WITH CASCADED CHECK OPTION;
여기에서, v2와 v3뷰는 다른 뷰, v1의 형태로 정의되었다. v2는 LOCAL검사 옵션을 가지고 있는데, 따라서 삽입은 v2검사에 대응
해서만 테스트 된다. v3는 CASCADED검사 옵션을 가지고 있는데, 따라서 삽입은 자신의 검사에 대해서만 아니라, 언더라잉 뷰 검
사에 대응해서도 테스트 된다. 아래의 명령문은 이러한 차이점을 보여 주는 것이다:
mysql> INSERT INTO v2 VALUES (2);
mysql> INSERT INTO v3 VALUES (2);
ERROR 1369 (HY000): CHECK OPTION failed 'test.v3'
뷰의 업데이트 능력은 updatable_views_with_limit시스템 변수의 값에 의해 영향을 받을 수도 있다. Section 5.2.2, “서버시스템
변수”를 참조할 것.

:::MySQL Korea:::
제목검색
Chapter 20. INFORMATION_SCHEMA 데이터 베이스
20. INFORMATION_SCHEMA 데이터 베이스 20.1. INFORMATION_SCHEMA SCHEMATA 테이블
20 INFORMATION_SCHEMA 데이터 베이스 20.2. INFORMATION_SCHEMA TABLES 테이블
20.1 INFORMATION_SCHEMA SCHEMATA 테이블 20.3. INFORMATION_SCHEMA COLUMNS 테이블

20.4. INFORMATION_SCHEMA STATISTICS 테이블
20.2 INFORMATION_SCHEMA TABLES 테이블
20.5. INFORMATION_SCHEMA USER_PRIVILEGES 테이블
20.3 INFORMATION_SCHEMA COLUMNS 테이블
20.6. INFORMATION_SCHEMA SCHEMA_PRIVILEGES 테이블
20.4 INFORMATION_SCHEMA STATISTICS 테이블
20.7. INFORMATION_SCHEMA TABLE_PRIVILEGES 테이블
20.5 INFORMATION_SCHEMA USER_PRIVILEGES 테이블
20.8. INFORMATION_SCHEMA COLUMN_PRIVILEGES 테이블
20.6 INFORMATION_SCHEMA SCHEMA_PRIVILEGES 테이블
20.9. INFORMATION_SCHEMA CHARACTER_SETS 테이블
20.7 INFORMATION_SCHEMA TABLE_PRIVILEGES 테이블
20.10. INFORMATION_SCHEMA COLLATIONS 테이블
20.8 INFORMATION_SCHEMA COLUMN_PRIVILEGES 테이블
20.11.INFORMATION_SCHEMA COLLATION_CHARACTER_SET_APPLICABILITY 테이블
20.9 INFORMATION_SCHEMA CHARACTER_SETS 테이블 20.12. INFORMATION_SCHEMA TABLE_CONSTRAINTS 테이블
20.10 INFORMATION_SCHEMA COLLATIONS 테이블 20.13. INFORMATION_SCHEMA KEY_COLUMN_USAGE 테이블
20.11 INFORMATION_SCHEMA 20.14. INFORMATION_SCHEMA ROUTINES 테이블
COLLATION_CHARACTER_SET_APPLICABILITY 테이블 20.15. INFORMATION_SCHEMA VIEWS 테이블
20.12 INFORMATION_SCHEMA TABLE_CONSTRAINTS 테이블 20.16. INFORMATION_SCHEMA TRIGGERS 테이블
20.13 INFORMATION_SCHEMA KEY_COLUMN_USAGE 테이블 20.17. 다른 INFORMATION_SCHEMA 테이블
20.14 INFORMATION_SCHEMA ROUTINES 테이블 20.18. SHOW 명령문에 대한 확장
20.15 INFORMATION_SCHEMA VIEWS 테이블
20.16 INFORMATION_SCHEMA TRIGGERS 테이블
INFORMATION_SCHEMA는 데이터 베이스의 메타 데이터에 접속할 수 있게 한다.
20.17 이외의 INFORMATION_SCHEMA 테이블
20.18 SHOW 명령문에 대한 확장
메타 데이터(Metadata) 란 데이터의 데이터로서, 데이터베이스 또는 테이블의 이름, 컬럼의 데이터 타입, 또
는 접근 권한과 같은 것을 말한다. 경우에 따라서, 이러한 정보들을 일컫는 용어로는 데이터 사전(data

:::MySQL Korea:::
dictionary) 과 시스템 카탈로그(system catalog)가 있다
INFORMATION_SCHEMA 는 정보 데이터 베이스로서, MySQL서버가 운영하는 모든 다른 데이터 베이스

에 대한 정보를 저장하는 장소이다. INFORMATION_SCHEMA 내부에는 몇 가지 읽기 전용 테이블이 있
다. 그런 테이블은 실제로는 베이스 테이블이 아닌 뷰이며, 따라서 이것들과 연관된 어떤 파일도 실제로 볼 수
는 없다.
여기에 예문이 하나 있다:
mysql> SELECT table_name, table_type, engine
-> FROM information_schema.tables
-> WHERE table_schema = 'db5'
-> ORDER BY table_name DESC;
+------------+------------+--------+
| table_name | table_type | engine |
+------------+------------+--------+
| v56 | VIEW | NULL |
|v | VIEW | NULL |
| tables | BASE TABLE | MyISAM |

:::MySQL Korea:::
| t7 | BASE TABLE | MyISAM |
|t | BASE TABLE | MyISAM |
| pk | BASE TABLE | InnoDB |
| loop | BASE TABLE | MyISAM |
| kurs | BASE TABLE | MyISAM |
|k | BASE TABLE | MyISAM |
| into | BASE TABLE | MyISAM |
| goto | BASE TABLE | MyISAM |
| fk2 | BASE TABLE | InnoDB |
| fk | BASE TABLE | InnoDB |
+------------+------------+--------+
설명: 명령문은 데이터 베이스 db5에 있는 모든 테이블의 리스트를 알파벳의 역순으로 요구하고, 세 가지로
정보를 보여준다: 테이블의 이름, 타입, 그리고 저장 엔진(storage engine).
각 MySQL 사용자는 이러한 테이블에 접근할 권한이 있는데, 사용자가 적당한 접근 권한을 갖고 있는 오브젝

:::MySQL Korea:::
트에 대응하는 테이블의 줄에 대해서도 마찬가지이다.
SELECT ... FROM INFORMATION_SCHEMA 명령문은 MySQL이 지원하는 다양한 SHOW명령문

(SHOW DATABASES, SHOW TABLES 등)이 제공하는 정보 접근에 대한 방법보다 더욱 효과적인 방법
을 제공한다. SELECT 는 SHOW와 비교해서 다음과 같은 장점을 갖는다:
• 이것은 코드의 규칙(Codd's rules)을 수행한다. 즉, 모든 접근은 테이블상에서 이루어 진다.
• 새로운 명령문 신택스에 대해 배울 필요가 없다. SELECT가 어떻게 동작하는지를 알기 때문

에, 오브젝트의 이름을 배우기만 하면 된다.
• 단지 한 개가 아니라, 수백 개의 다양한 결과를 가질 수 있다. 이것은 다양한 메타 데이터를 원

하는 수 많은 어플리케이션의 요구에 대해 유연하게 대응할 수 있게 한다.
• 다른 모든 데이터 베이스도 이런 형태로 동작을 하기 때문에 마이그래이션이 보다 수월해진다.
하지만, SHOW가 MySQL 사용자에게 보다 일반적으로 사용되고 있기 때문에, 그리고 SHOW를 삭제하는
것이 보다 혼란을 야기할 수도 있기 때문에, 재래 방식의 신택스가 갖는 장점은 계속 지원되고 있다. 사실,
MySQL 5.0에는 SHOW의 기능이 보다 발전 되어 있으며, Section 20.18, “SHOW 명령문에 대한 확
장”에서 자세히 다루기로 한다.
SHOW명령문을 사용하기 위한 권한과 INFORMATION_SCHEMA 에서 정보를 선택하기 위해 필요한 권

한 사이에는 차이점이 없다. 어느 경우에나, 오브젝트에 대한 정보를 보기 위해서는 그것에 대한 적당한 권한
을 가져야만 한다.
MySQL에서 INFORMATION_SCHEMA 테이블 구조에 대한 실행은 ANSI/ISO SQL:2003 standard

Part 11 Schemata를 준수한다. MySQL은 SQL:2003 core feature F021 Basic information schema 와
적당한 호환을 유지하고자 한다.
SQL Server 2000 (이것도 표준을 따르고 있음)사용자는 매우 유사한 내용을 발견할 것이다. 하지만,
MySQL은 자체의 목적과는 관련이 없는 많은 컬럼을 포함시키지 않았고, MySQL 고유의 컬럼들을 포함시켰
다. 이러한 컬럼 중의 하나가 INFORMATION_SCHEMA.TABLES 테이블에 있는ENGINE 컬럼이다.
다른 DBMS가 이것을 syscat 또는 system등의 다양한 이름으로 사용하고는 있으나, 표준 이름은

:::MySQL Korea:::
INFORMATION_SCHEMA이다.
사실, 비록 서버가 이 이름으로 데이터 베이스 디렉토리를 생성하지는 않지만, MySQL에는

INFORMATION_SCHEMA이름의 데이터 베이스가 있다. INFORMATION_SCHEMA 를 USE명령문을 갖
는 다폴트 데이터 베이스로 선택하는 것은 가능하지만, 테이블의 내용을 읽을 경우에만 가능하다. 이러한 테
이블 안으로 데이터를 삽입, 업데이트, 또는 삭제의 작업은 할 수가 없다.
다음의 섹션에서는 INFORMATION_SCHEMA 내에 있는 각 테이블 및 컬럼을 설명하기로 한다. 각 컬럼의

경우, 세 부분의 정보가 있게 된다:
• “표준 이름(Standard Name)”은 컬럼에 대한 표준 SQL이름을 나타낸다.
• “SHOW 이름”은 가장 근접해 있는SHOW명령문 내에 있는 대응 필드 이름이 무엇인지를 나

타낸다.
• “비고(Remarks)”는 사용 가능한 추가적인 정보를 제공한다. 이 필드가 NULL이면, 이것은

컬럼의 값이 항상 NULL임을 의미한다.
표준SQL, DB2, SQL Server, 또는 Oracle에서 지정되어 있는 이름들의 사용을 피하기 위해, MySQL은
“MySQL 확장(extention)”이라고 표시해 놓은 변경 컬럼들을 사용한다. (예를 들면, MySQL은
TABLES 테이블에서 COLLATION 을 TABLE_COLLATION으로 변경해 놓았다) 사용이 지정되어 있는
단어의 리스트는 여기를 참조할 것: http://www.dbazine.com/gulutzan5.shtml.
문자 컬럼에 대한 정의(예를 들면, TABLES.TABLE_NAME)은 일반적으로 N이 적어도 64인 VARCHAR

(N) CHARACTER SET utf8 가 된다.
각 섹션은 INFORMATION_SCHEMA 에서 정보를 추출하는 SELECT 명령문에 대응하는 SHOW 명령문

에 대해 설명한다.
Note: 현재의 버전까지는, 몇가지 누락된 컬럼 및 제대로 동작하지 않는 컬럼이 있는데, MySQL은 꾸준히 이러
한 문제를 해결할 예정이다

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
상위메뉴리스트 ◆ 20.1. INFORMATION_SCHEMA SCHEMATA 테이블
20. INFORMATION_SCHEMA 데이터 베이스 하나의 스키마는 하나의 데이터 베이스이며, 따라서SCHEMATA 테이블은 데이터 베이스의 정보를 제공한
20.1. INFORMATION_SCHEMA SCHEMATA 테이 다.

블
20.1 INFORMATION_SCHEMA SCHEMATA 테이블 Standard Name SHOW name Remarks
CATALOG_NAME - NULL
SCHEMA_NAME Database
DEFAULT_CHARACTER_SET_NAME
DEFAULT_COLLATION_NAME
SQL_PATH NULL
Notes:
• DEFAULT_COLLATION_NAME 는 MySQL 5.0.6에서 추가되었다.
아래의 명령문은 동일한 기능을 제공한다:
SELECT SCHEMA_NAME AS `Database`
FROM INFORMATION_SCHEMA.SCHEMATA
[WHERE SCHEMA_NAME LIKE 'wild']

:::MySQL Korea:::
SHOW DATABASES
[LIKE 'wild']

:::MySQL Korea:::
제목검색
20.2. INFORMATION_SCHEMA TABLES 테이블
20. INFORMATION_SCHEMA 데이터 베이스
TABLES 은 데이터 베이스에 있는 테이블에 대한 정보를 제공한다.
20.2. INFORMATION_SCHEMA TABLES 테이블
20.2 INFORMATION_SCHEMA TABLES 테이블

Standard Name SHOW name Remarks
TABLE_CATALOG NULL
TABLE_SCHEMA Table_...
TABLE_NAME Table_...
TABLE_TYPE
ENGINE Engine MySQL extension
VERSION Version MySQL extension
ROW_FORMAT Row_format MySQL extension
TABLE_ROWS Rows MySQL extension
AVG_ROW_LENGTH Avg_row_length MySQL extension
DATA_LENGTH Data_length MySQL extension
MAX_DATA_LENGTH Max_data_length MySQL extension
INDEX_LENGTH Index_length MySQL extension
DATA_FREE Data_free MySQL extension
AUTO_INCREMENT Auto_increment MySQL extension
CREATE_TIME Create_time MySQL extension
UPDATE_TIME Update_time MySQL extension

:::MySQL Korea:::
CHECK_TIME Check_time MySQL extension
TABLE_COLLATION Collation MySQL extension
CHECKSUM Checksum MySQL extension
CREATE_OPTIONS Create_options MySQL extension
TABLE_COMMENT Comment MySQL extension
Notes:
• TABLE_SCHEMA 과 TABLE_NAME 은 SHOW 에서 나타나는 단일 필드이며, 예를 들면 Table_in_db1.
• TABLE_TYPE 는BASE TABLE 또는 VIEW이어야 한다. 만일 테이블이 임시적(temporary)이라면,

TABLE_TYPE = TEMPORARY 이 된다. (임시 뷰(temporary views)는 없다.)
• 만일, 테이블이 INFORMATION_SCHEMA 데이터 베이스에 있다면, TABLE_ROWS 컬럼은 NULL 이 된

다. InnoDB 테이블의 경우, 줄 계산(row count)은 SQL 옵티마이제이션(optimization)에서 사용되는 추정치일
뿐이다.
• MySQL은 테이블의 디폴트 문자열 셋을 갖고 있지 않다. TABLE_COLLATION 은 삭제 되었는데, 왜냐하면

조사 이름(collation names )은 문자열 이름 셋을 가지고 시작하기 때문이다.
아래의 명령문은 동일한 기능을 제공한다:
SELECT table_name FROM INFORMATION_SCHEMA.TABLES
[WHERE table_schema = 'db_name']
[WHERE|AND table_name LIKE 'wild']
SHOW TABLES

:::MySQL Korea:::
[FROM db_name]
[LIKE 'wild']

:::MySQL Korea:::
제목검색
20.3. INFORMATION_SCHEMA COLUMNS 테이블
20. INFORMATION_SCHEMA 데이터 베이스 COLUMNS 테이블은 테이블에 있는 컬럼이 정보를 제공한다.
20.3. INFORMATION_SCHEMA COLUMNS

테이블 Standard Name SHOW name Remarks
20.3 INFORMATION_SCHEMA COLUMNS 테이 TABLE_CATALOG NULL
블
TABLE_SCHEMA
TABLE_NAME
COLUMN_NAME Field
ORDINAL_POSITION see notes
COLUMN_DEFAULT Default
IS_NULLABLE Null
DATA_TYPE Type
CHARACTER_MAXIMUM_LENGTH Type
CHARACTER_OCTET_LENGTH
NUMERIC_PRECISION Type
NUMERIC_SCALE Type
CHARACTER_SET_NAME
COLLATION_NAME Collation
COLUMN_TYPE Type MySQL extension
COLUMN_KEY Key MySQL extension

:::MySQL Korea:::
EXTRA Extra MySQL extension
COLUMN_COMMENT Comment MySQL extension
Notes:
• SHOW에는, 몇몇 서로 다른 COLUMNS 컬럼에서 얻는 Type 표현 값을 표현한다.
• 때때로 ORDER BY ORDINAL_POSITION 를 사용할 경우가 있기 때문에 ORDINAL_POSITION 는 필요하게 된

다. SHOW와는 달리, SELECT 는 자동 오더링(automatic ordering)을 갖고 있지 않다.
• CHARACTER_OCTET_LENGTH 는, 다중 바이트(multi-byte)문자열 셋을 제외하고는,

CHARACTER_MAXIMUM_LENGTH와 같은 형태이어야 한다.
• CHARACTER_SET_NAME 는 Collation에서 얻어낼 수 있다. 예를 들면, SHOW FULL COLUMNS FROM t를

말하고, 그리고 Collation 에서 latin1_swedish_ci 의 값을 볼 수 있다면, 문자열 셋은 첫 번째 밑줄 앞에 있는 값이 된
다: latin1.
아래의 명령문들은 거의 유사한 결과를 만들어 낸다:
SELECT COLUMN_NAME, DATA_TYPE, IS_NULLABLE, COLUMN_DEFAULT
FROM INFORMATION_SCHEMA.COLUMNS
WHERE table_name = 'tbl_name'
[AND table_schema = 'db_name']
[AND column_name LIKE 'wild']
SHOW COLUMNS
FROM tbl_name

:::MySQL Korea:::
[FROM db_name]
[LIKE 'wild']

:::MySQL Korea:::
제목검색
20.4. INFORMATION_SCHEMA STATISTICS 테이블
STATISTICS 테이블은 테이블 인덱스에 대한 정보를 제공한다.
20.4. INFORMATION_SCHEMA STATISTICS 테이
블
20.4 INFORMATION_SCHEMA STATISTICS 테이블
TABLE_CATALOG NULL
TABLE_SCHEMA = Database
TABLE_NAME Table
NON_UNIQUE Non_unique
INDEX_SCHEMA = Database
INDEX_NAME Key_name
SEQ_IN_INDEX Seq_in_index
COLUMN_NAME Column_name
COLLATION Collation
CARDINALITY Cardinality
SUB_PART Sub_part MySQL extension
PACKED Packed MySQL extension
NULLABLE Null MySQL extension
INDEX_TYPE Index_type MySQL extension
COMMENT Comment MySQL extension

:::MySQL Korea:::
Notes:
• 인덱스에 대한 표준 테이블은 없다. 이전의 리스트는 SQL Server 2000이 sp_statistics 에 대해 돌려주
는 값과 비슷한 것인데, MySQL이QUALIFIER 의 이름을 CATALOG로 변경한 것과, OWNER 의 이름을
SCHEMA로 변경한 것은 예외이다.
분명하게, SHOW INDEX로부터 나온 앞선 테이블 및 결과 값들은 모두 동일한 곳에서 얻은 것이다. 따라서 상

호 관련성은 이미 매우 밀접하다.
아래의 명령어들은 동일한 기능을 실행한다:
SELECT * FROM INFORMATION_SCHEMA.STATISTICS
WHERE table_name = 'tbl_name'
[AND table_schema = 'db_name']
SHOW INDEX
FROM tbl_name
[FROM db_name]

:::MySQL Korea:::
제목검색
20.5. INFORMATION_SCHEMA USER_PRIVILEGES 테이블
USER_PRIVILEGES 테이블은 글로벌 권한에 대한 정보를 제공한다. 이러한 정보는 mysql.user 그랜트 테이
20.5. INFORMATION_SCHEMA
블에서 얻어진다.
USER_PRIVILEGES 테이블
20.5 INFORMATION_SCHEMA USER_PRIVILEGES

테이블
GRANTEE 'user_name'@'host_name' value
TABLE_CATALOG NULL
PRIVILEGE_TYPE
IS_GRANTABLE
Notes:
이것은 비 표준(non-standard table) 테이블이다. 이것은 mysql.user 에서 값을 가져 온다.
:::MySQL Korea:::
제목검색
20.6. INFORMATION_SCHEMA SCHEMA_PRIVILEGES 테이블

SCHEMA_PRIVILEGES 테이블은 스키마(데이터 베이스)권한에 대한 정보를 제공한다. 이것은 mysql.db 그랜트 테이
블에서 얻어진다.
SCHEMA_PRIVILEGES 테이블
20.6 INFORMATION_SCHEMA
SCHEMA_PRIVILEGES 테이블 Standard Name SHOW name Remarks
TABLE_CATALOG NULL
TABLE_SCHEMA
PRIVILEGE_TYPE
IS_GRANTABLE
Notes:
• 이것은 비 표준(non-standard table) 테이블이다. 이것은 mysql.db 테이블에서 값을 얻을 수 있다.
:::MySQL Korea:::
제목검색
20.7. INFORMATION_SCHEMA TABLE_PRIVILEGES 테이블

TABLE_PRIVILEGES 테이블은 테이블 권한에 대한 정보를 제공한다. 이것은mysql.tables_priv 그랜트 테이블에서 얻어
진다.
TABLE_PRIVILEGES 테이블
TABLE_PRIVILEGES 테이블 Standard Name SHOW name Remarks
TABLE_CATALOG NULL
TABLE_SCHEMA
TABLE_NAME
PRIVILEGE_TYPE
IS_GRANTABLE
아래의 명령문들은 동일한 기능을 제공하지 않는다:
SELECT ... FROM INFORMATION_SCHEMA.TABLE_PRIVILEGES
SHOW GRANTS ...
PRIVILEGE_TYPE 는 이러한 값 중에 한 개만 가질 수 있다: SELECT, INSERT, UPDATE, REFERENCES, ALTER,

INDEX, DROP, CREATE VIEW.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
20.8. INFORMATION_SCHEMA COLUMN_PRIVILEGES 테이블

COLUMN_PRIVILEGES 테이블은 컬럼 권한에 대한 정보를 제공한다. 이것은mysql.columns_priv 그랜트 테이블에서 얻어
진다.
COLUMN_PRIVILEGES 테이블
COLUMN_PRIVILEGES 테이블 Standard Name SHOW name Remarks
TABLE_CATALOG NULL
TABLE_SCHEMA
TABLE_NAME
COLUMN_NAME
PRIVILEGE_TYPE
IS_GRANTABLE
Notes:
• SHOW FULL COLUMNS에서 얻어진 결과에서, 권한들은 하나의 필드 및 소문자로 표현된 것에 있는 모든 것

들인데, 예를 들면, select,insert,update,references이 해당된다. COLUMN_PRIVILEGES에서는, 대문자로 표현
된 것에 있는 줄(row)당 하나의 권한이 있게 된다.
• PRIVILEGE_TYPE 는 다음의 값 중에 한가지만 가질 수 있다: SELECT, INSERT, UPDATE,

REFERENCES.
• 만일 사용자가GRANT OPTION 권한을 갖는다면, IS_GRANTABLE 는 YES이어야 한다. 그렇지 않으면,

IS_GRANTABLE 은 NO이어야 한다. 결과 값은 별개의 권한으로 GRANT OPTION를 리스트 하지는 않는다.

:::MySQL Korea:::
아래의 명령문들은 동일한 기능을 수행하지 않는다:
SELECT ... FROM INFORMATION_SCHEMA.COLUMN_PRIVILEGES
SHOW GRANTS ...

:::MySQL Korea:::
제목검색
20.9. INFORMATION_SCHEMA CHARACTER_SETS 테이블
CHARACTER_SETS 테이블은 사용 가능한 문자열 셋에 대한 정보를 준다.
CHARACTER_SETS 테이블
20.9 INFORMATION_SCHEMA CHARACTER_SETS
테이블 CHARACTER_SET_NAME Charset
DEFAULT_COLLATE_NAME Default collation
DESCRIPION Description MySQL extension
MAXLEN Maxlen MySQL extension
Notes:
• MySQL은 두 개의 비 표준 컬럼을 추가하였고, SHOW CHARACTER SET 에서 얻어지는 결과에 있는

Description 및 Maxlen이 이에 해당한다.
아래의 명령문들은 동일한 기능을 수행한다:
SELECT * FROM INFORMATION_SCHEMA.CHARACTER_SETS
[WHERE name LIKE 'wild']
SHOW CHARACTER SET

:::MySQL Korea:::
[LIKE 'wild']

:::MySQL Korea:::
제목검색
20.10. INFORMATION_SCHEMA COLLATIONS 테이블
COLLATIONS 테이블은 각 문자열 셋에 대한 조사(collation)에 대한 정보를 제공한다.
COLLATIONS 테이블
20.10 INFORMATION_SCHEMA COLLATIONS
테이블 COLLATION_NAME Collation
Notes:
• MySQL은 다섯 개의 비 표준 컬럼을 추가하였고, SHOW COLLATION 에서 얻어지는 결과에 있는 Charset, Id,

Default, Compiled, 및 Sortlen 컬럼이 이에 해당한다.
아래의 명령문들은 동일한 기능을 수행한다:
SELECT COLLATION_NAME FROM INFORMATION_SCHEMA.COLLATIONS
[WHERE collation_name LIKE 'wild']
SHOW COLLATION
[LIKE 'wild']
:::MySQL Korea:::
제목검색

COLLATION_CHARACTER_SET_APPLICABILITY 테이블
COLLATION_CHARACTER_SET_APPLICABILITY 테이블은 어떤 조사(collation)에 어떤 문자열 셋이
적용되는지를 표시한다. 컬럼들은 SHOW COLLATION 로 얻어내는 첫 번째 두 표시 필드와 일치한다.
COLLATION_NAME Collation
CHARACTER_SET_NAME Charset
:::MySQL Korea:::
제목검색
20.12. INFORMATION_SCHEMA TABLE_CONSTRAINTS 테이블
TABLE_CONSTRAINTS 테이블은 어떤 테이블이 제약 사항을 갖고 있는지 설명한다.
TABLE_CONSTRAINTS 테이블
20.12 INFORMATION_SCHEMA TABLE_CONSTRAINTS 테
이블 CONSTRAINT_CATALOG NULL
CONSTRAINT_SCHEMA
CONSTRAINT_NAME
TABLE_SCHEMA
TABLE_NAME
CONSTRAINT_TYPE
Notes:
• CONSTRAINT_TYPE 값은UNIQUE, PRIMARY KEY, 또는 FOREIGN KEY가 될 수 있다.
• UNIQUE 및 PRIMARY KEY 정보는 Non_unique 필드가 0일 때 SHOW INDEX로부터 얻는 결과값

에 있는 Key_name 필드로부터 얻는 것과 같은 정보이다.
• CONSTRAINT_TYPE 컬럼은 다음과 같은 값 중에 하나를 가질 수 있다: UNIQUE, PRIMARY

KEY, FOREIGN KEY, CHECK. 이것은 CHAR ( ENUM이 아님) 컬럼이다. CHECK 값은 MySQL이
CHECK을 지원하지 않는 한 사용할 수 없다.

:::MySQL Korea:::

:::MySQL Korea:::
제목검색
20.13. INFORMATION_SCHEMA KEY_COLUMN_USAGE 테이블
KEY_COLUMN_USAGE 테이블은 제약 사항을 갖고 있는 키 컬럼(key column)을 설명한다.
KEY_COLUMN_USAGE 테이블
KEY_COLUMN_USAGE 테이블 CONSTRAINT_CATALOG NULL
CONSTRAINT_SCHEMA
CONSTRAINT_NAME
TABLE_CATALOG
TABLE_SCHEMA
TABLE_NAME
COLUMN_NAME
ORDINAL_POSITION
POSITION_IN_UNIQUE_CONSTRAINT
REFERENCED_TABLE_SCHEMA
REFERENCED_TABLE_NAME
REFERENCED_COLUMN_NAME
Notes:
• 만일 외국어 키에 대해 제약 사항이 있다면, 이것은 외국어 키에 대한 컬럼이며, 외국어 키 참조 컬럼은 아닌 것

이다.

:::MySQL Korea:::
• ORDINAL_POSITION의 값은 제약 사항 안에 있는 컬럼의 위치이며, 테이블 안에 있는 컬럼의 위치는 아니다.

컬럼 위치는 1에서부터 시작해서 숫자로 매기어 진다.
• POSITION_IN_UNIQUE_CONSTRAINT 의 값은 유일하면서 주요한 키(unique and primary-key) 에 대한

제약 사항에 대해서는NULL 이 된다. 외국어 키 제약에 대해서는, 참조되는 테이블에 있는 키에서 서수로 표현된다.
예를 들면, t1 과 t3로 쓰여진 두 개의 테이블이 있고 다음과 같은 정의를 갖는다고 가정하자::
CREATE TABLE t1
s1 INT,
s2 INT,
s3 INT,
PRIMARY KEY(s3)
) ENGINE=InnoDB;
CREATE TABLE t3
s1 INT,
s2 INT,
s3 INT,

:::MySQL Korea:::
KEY(s1),
CONSTRAINT CO FOREIGN KEY (s2) REFERENCES t1(s3)
) ENGINE=InnoDB;
이 두 개의 테이블에 대해, KEY_COLUMN_USAGE 테이블은 두 개의 줄을 갖는다:
o 한 개의 줄은, CONSTRAINT_NAME = 'PRIMARY', TABLE_NAME = 't1', COLUMN_NAME =

's3', ORDINAL_POSITION = 1, POSITION_IN_UNIQUE_CONSTRAINT = NULL.
o 나머지 한 개는, CONSTRAINT_NAME = 'CO', TABLE_NAME = 't3', COLUMN_NAME = 's2',

ORDINAL_POSITION = 1, POSITION_IN_UNIQUE_CONSTRAINT = 1.
• REFERENCED_TABLE_SCHEMA, REFERENCED_TABLE_NAME, 및
REFERENCED_COLUMN_NAME 은 MySQL 5.0.6에서 추가 되었다.

:::MySQL Korea:::
제목검색
20.14. INFORMATION_SCHEMA ROUTINES 테이블
ROUTINES 테이블은 스토어드 루틴(프로시저 및 함수 모두)에 대한 정보를 제공한다. 현재의 버전까지는, ROUTINES
20.14. INFORMATION_SCHEMA ROUTINES 테이
테이블은 사용자 정의 함수(UDF)를 포함하지는 않는다.
블
20.14 INFORMATION_SCHEMA ROUTINES 테이블

“mysql.proc 이름”으로 표현된 컬럼은 mysql.proc 테이블 컬럼을 나타내는데, 이것은 INFORMATION_SCHEMA.
ROUTINES 테이블 컬럼에 해당한다.
Standard Name mysql.proc name Remarks
SPECIFIC_NAME specific_name
ROUTINE_CATALOG NULL
ROUTINE_SCHEMA db
ROUTINE_NAME name
ROUTINE_TYPE type {PROCEDURE|FUNCTION}
DTD_IDENTIFIER (data type descriptor)
ROUTINE_BODY SQL
ROUTINE_DEFINITION body
EXTERNAL_NAME NULL
EXTERNAL_LANGUAGE language NULL
PARAMETER_STYLE SQL
IS_DETERMINISTIC is_deterministic
SQL_DATA_ACCESS sql_data_access

:::MySQL Korea:::
SQL_PATH NULL
SECURITY_TYPE security_type
CREATED created
LAST_ALTERED modified
SQL_MODE sql_mode MySQL extension
ROUTINE_COMMENT comment MySQL extension
DEFINER definer MySQL extension
Notes:
• MySQL 은EXTERNAL_LANGUAGE를 계산한다:
o 만일 mysql.proc.language='SQL'이면, EXTERNAL_LANGUAGE 는 NULL 이다.
o 그렇지 않으면, EXTERNAL_LANGUAGE 는 mysql.proc.language에 있는 것이 된다. 하지만,

MySQL은 외부 언어(external languages)를 아직 갖고 있지 않기 때문에, 그 값은 항상NULL.

:::MySQL Korea:::
제목검색
20.15. INFORMATION_SCHEMA VIEWS 테이블
VIEWS 테이블은 데이터 베이스에 있는 뷰에 대한 정보를 제공한다. 이 테이블에 접근하기 위해서는 SHOW VIEW 권한을
20.15. INFORMATION_SCHEMA VIEWS 테이블
가져야 한다.
20.15 INFORMATION_SCHEMA VIEWS 테이블
TABLE_CATALOG NULL
TABLE_SCHEMA
TABLE_NAME
VIEW_DEFINITION
CHECK_OPTION
IS_UPDATABLE
DEFINER
SECURITY_TYPE
Notes:
• VIEW_DEFINITION 컬럼은 SHOW CREATE VIEW가 만들어내는 Create Table 필드에 있는 것들이다.
SELECT 이전에 있는 단어는 건너뛰고 WITH CHECK OPTION의 단어도 건너 뛰자. 원래의 명령문이 다음과 같
다고 가정하자:
• CREATE VIEW v AS
• SELECT s2,s1 FROM t

:::MySQL Korea:::
• WHERE s1 > 5
• ORDER BY s1
• WITH CHECK OPTION;
그러면, 뷰 정의문은 다음과 같이 보일 것이다:
SELECT s2,s1 FROM t WHERE s1 > 5 ORDER BY s1
• CHECK_OPTION 컬럼은 항상 NONE의 값을 갖는다.
• IS_UPDATABLE 컬럼은 뷰가 업데이트 가능하면YES 이고, 그렇지 않으면 NO 이다.
• DEFINER 및 SECURITY_TYPE 컬럼은 MySQL 5.0.14에서 추가 되었다. DEFINER는 뷰를 정의하는 사용

자를 가리킨다. SECURITY_TYPE 은 DEFINER 또는 INVOKER의 값을 갖는다.

:::MySQL Korea:::
제목검색
20.16. INFORMATION_SCHEMA TRIGGERS 테이블
TRIGGERS 테이블은 트리거에 대한 정보를 제공한다. 이 테이블에 접근하기 위해서는 SUPER권한이 있어야 한다.
20.16. INFORMATION_SCHEMA TRIGGERS 테
이블
20.16 INFORMATION_SCHEMA TRIGGERS 테이블
TRIGGER_CATALOG NULL
TRIGGER_SCHEMA
TRIGGER_NAME Trigger
EVENT_MANIPULATION Event
EVENT_OBJECT_CATALOG NULL
EVENT_OBJECT_SCHEMA
EVENT_OBJECT_TABLE Table
ACTION_ORDER 0
ACTION_CONDITION NULL
ACTION_STATEMENT Statement
ACTION_ORIENTATION ROW
ACTION_TIMING Timing
ACTION_REFERENCE_OLD_TABLE NULL
ACTION_REFERENCE_NEW_TABLE NULL
ACTION_REFERENCE_OLD_ROW OLD
ACTION_REFERENCE_NEW_ROW NEW

:::MySQL Korea:::
CREATED NULL (0)
SQL_MODE
DEFINER
Notes:
• TRIGGERS 테이블은 MySQL 5.0.10에서 추가되었다.
• TRIGGER_SCHEMA 및 TRIGGER_NAME 컬럼은 각각 트리거가 일어나는 데이터 베이스의 이름과 트리거

의 이름을 갖고 있다.
• EVENT_MANIPULATION 컬럼은 'INSERT', 'DELETE', 'UPDATE'중의 하나의 값을 갖는다.
• Chapter 18, Triggers에서 설명하였듯이, 모든 트리거는 정확히 하나의 테이블과 연결이 된다.
EVENT_OBJECT_SCHEMA 및 EVENT_OBJECT_TABLE 컬럼은 이 테이블이 발생하는 데이터 베이스의 이름
과 테이블의 이름을 갖는다.
• ACTION_ORDER 명령문은 동일한 테이블에 있는 모든 유사 트리거의 리스트 안에서 발생하는 트리거의 동

작을 서수로 갖는다. 현재의 버전까지는, 이 값은0인데, 왜냐하면 동일한 테이블에서 동일한
EVENT_MANIPULATION 및 ACTION_TIMING 는 한 개 이상을 가질 수 없기 때문이다.
• ACTION_STATEMENT 컬럼은 트리거가 호출될 때 실행되는 명령문을 갖는다. 이것은 SHOW TRIGGERS
로부터 나오는 결과값에 대해 Statement 컬럼에서 문장이 표시될 때에도 동일하다. 이 문장은UTF-8 엔코딩
(encoding)을 사용한다는 점을 주의하자.
• ACTION_ORIENTATION 컬럼은 항상 'ROW'값을 갖는다.
• ACTION_TIMING 컬럼은 'BEFORE' 또는 'AFTER'의 값 중에 하나를 갖는다.
• 컬럼 ACTION_REFERENCE_OLD_ROW 및 ACTION_REFERENCE_NEW_ROW 는 이전(old)과 새로운

(new)컬럼 식별자(identifiers)를 각각 갖는다. 이것은 ACTION_REFERENCE_OLD_ROW 는 항상 'OLD' 의 값
을 가지며 ACTION_REFERENCE_NEW_ROW 는 'NEW'의 값을 갖는다는 것을 의미한다.
• SQL_MODE 컬럼은 트리거가 생성되었을 때(따라서 현재의 서버 SQL모드가 무엇이든지 상관없이 트리거가
호출될 때마다 영향을 받는) 실제로 영향을 받는 서버 SQL모드를 보여준다. 이 컬럼에 대한 가능한 범위는
sql_mode 시스템 변수의 범위와 같다. Section 5.2.5, “서버 SQL 모드” 참조.

:::MySQL Korea:::
• DEFINER 컬럼은 MySQL 5.0.17에서 추가 되었다. DEFINER 는 트리거를 정의하는 것을 표시한다.
• 현재까지는 아래의 컬럼은 NULL값이다: TRIGGER_CATALOG, EVENT_OBJECT_CATALOG,

ACTION_CONDITION, ACTION_REFERENCE_OLD_TABLE, ACTION_REFERENCE_NEW_TABLE, 및
CREATED.
예를 들면, . Section 18.3, “Using Triggers”에서 설명하는 ins_sum 트리거를 보자:
mysql> SELECT * FROM INFORMATION_SCHEMA.TRIGGERS￦G
*************************** 1. row ***************************
TRIGGER_CATALOG: NULL
TRIGGER_SCHEMA: test
TRIGGER_NAME: ins_sum
EVENT_MANIPULATION: INSERT
EVENT_OBJECT_CATALOG: NULL
EVENT_OBJECT_SCHEMA: test
EVENT_OBJECT_TABLE: account
ACTION_ORDER: 0
ACTION_CONDITION: NULL
ACTION_STATEMENT: SET @sum = @sum + NEW.amount
ACTION_ORIENTATION: ROW

:::MySQL Korea:::
ACTION_TIMING: BEFORE
ACTION_REFERENCE_OLD_TABLE: NULL
ACTION_REFERENCE_NEW_TABLE: NULL
ACTION_REFERENCE_OLD_ROW: OLD
ACTION_REFERENCE_NEW_ROW: NEW
CREATED: NULL
SQL_MODE:
DEFINER: me@localhost
또한 Section 13.5.4.22, “SHOW TRIGGERS 신택스”를 참조하자.

:::MySQL Korea:::
제목검색
20.17. 이외의 INFORMATION_SCHEMA 테이블
MySQL은 부가적인 INFORMATION_SCHEMA 테이블을 사용하고자 한다. 특히, PARAMETERS 및
20.17. 이외의 INFORMATION_SCHEMA 테이블
REFERENTIAL_CONSTRAINTS 테이블에 대한 필요성을 알고 있다.
20.17 이외의 INFORMATION_SCHEMA 테이블
:::MySQL Korea:::
제목검색
20.18. SHOW 명령문에 대한 확장
20. INFORMATION_SCHEMA 데이터
SHOW 명령문에 대한 몇 가지 확장이 INFORMATION_SCHEMA 의 실행과 관련되어 제공된다:
베이스
20.18. SHOW 명령문에 대한 확장

• SHOW는 INFORMATION_SCHEMA 자체의 구조에 대한 정보를 얻기 위해 사용될 수 있다.
20.18 SHOW 명령문에 대한 확장
• 몇 가지 SHOW 문장은 어떤 줄을 표시할 지 지정하는데 있어서 보다 유연성을 제공해 주는 WHERE 구문을 사용할 수 있
다.
이러한 확장은 MySQL 5.0.3이후에 사용 가능하다.
INFORMATION_SCHEMA 는 하나의 정보 테이블이며, 따라서 이 이름은 SHOW DATABASES 에서 얻어지는 결과에 포함된다. 비
슷하게, SHOW TABLES 은 테이블의 리스트를 얻기 위해 INFORMATION_SCHEMA 과 함께 사용될 수 있다:
mysql> SHOW TABLES FROM INFORMATION_SCHEMA;
+---------------------------------------+
| Tables_in_information_schema |
+---------------------------------------+
| CHARACTER_SETS |
| COLLATIONS |
| COLLATION_CHARACTER_SET_APPLICABILITY |

:::MySQL Korea:::
| COLUMNS |
| COLUMN_PRIVILEGES |
| KEY_COLUMN_USAGE |
| ROUTINES |
| SCHEMATA |
| SCHEMA_PRIVILEGES |
| STATISTICS |
| TABLES |
| TABLE_CONSTRAINTS |
| TABLE_PRIVILEGES |
| TRIGGERS |
| USER_PRIVILEGES |
| VIEWS |
+---------------------------------------+
SHOW COLUMNS 및 DESCRIBE 는 개별 INFORMATION_SCHEMA 테이블에 있는 컬럼에 대한 정보를 표시할 수 있다.

:::MySQL Korea:::
몇몇 SHOW 명령문은 WHERE 구문을 사용하기 위해 확장된 것이다:
SHOW CHARACTER SET
SHOW COLLATION
SHOW COLUMNS
SHOW DATABASES
SHOW KEYS
SHOW OPEN TABLES
SHOW PROCEDURE STATUS
SHOW STATUS
SHOW TABLE STATUS
SHOW TABLES
SHOW VARIABLES
WHERE 구문은, 만약 있다면, SHOW 명령문으로 표시되는 컬럼 이름에 대비해서 평가된다. 예를 들면, SHOW CHARACTER SET 명
령문은 다음과 같은 컬럼을 만들어 낸다:
+----------+-----------------------------+---------------------+--------+

:::MySQL Korea:::
+----------+-----------------------------+---------------------+--------+
| dec8 | DEC West European | dec8_swedish_ci | 1|
| cp850 | DOS West European | cp850_general_ci | 1|
| hp8 | HP West European | hp8_english_ci | 1|
| koi8r | KOI8-R Relcom Russian | koi8r_general_ci | 1|
...
WHERE 구문을 SHOW CHARACTER SET과 함께 사용하기 위해서는, 컬럼의 이름들을 참조하여야 한다. 하나의 예로서, 아래의 명
령문은 디폴트 조사(collation)가 스트링 'japanese'를 갖는 문자열 셋의 정보를 나타낸다:
mysql> SHOW CHARACTER SET WHERE `Default collation` LIKE '%japanese%';
+---------+---------------------------+---------------------+--------+
+---------+---------------------------+---------------------+--------+

:::MySQL Korea:::
| cp932 | SJIS for Windows Japanese | cp932_japanese_ci | 2|
| eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci | 3|
+---------+---------------------------+---------------------+--------+
이 명령문은 다중-바이트 문자열 셋을 표현한다:
mysql> SHOW CHARACTER SET WHERE Maxlen > 1;
+---------+---------------------------+---------------------+--------+
+---------+---------------------------+---------------------+--------+
| euckr | EUC-KR Korean | euckr_korean_ci | 2|
| gb2312 | GB2312 Simplified Chinese | gb2312_chinese_ci | 2|
| gbk | GBK Simplified Chinese | gbk_chinese_ci | 2|
| utf8 | UTF-8 Unicode | utf8_general_ci | 3|

:::MySQL Korea:::
| ucs2 | UCS-2 Unicode | ucs2_general_ci | 2|
| cp932 | SJIS for Windows Japanese | cp932_japanese_ci | 2|
| eucjpms | UJIS for Windows Japanese | eucjpms_japanese_ci | 3|
+---------+---------------------------+---------------------+--------+

MySQL Korean Manual

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

MySQL Korean Manual

Uploaded by

Copyright:

Available Formats

:::MySQL Korea:::

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

MySQL 한글 매뉴얼에 대하여..

8 클라이언트 및 유틸리티 프로그램

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

상위메뉴리스트 ◆ Chapter 2. MySQL 설치 및 업그레이드 하기

2. MySQL 설치 및 업그레이드 하기 2.1. 일반 설치 사항

2 MySQL 설치 및 업그레이드 하기 2.1.1. MySQL이 지원하는 OS

2.1 일반 설치 사항 2.1.2. 설치할 MySQL 배포판 선택하기

2.1.1 MySQL이 지원하는 OS 2.1.3. MySQL 다운 로드 하기

2.3.1 설치 패키지 선택 하기 2.3.13. 윈도우에서 MySQL 설치 문제 해결(Troubleshooting)

2.3.2 자동 설치기를 사용한 MySQL 설치 2.3.14. 윈도우에서MySQL 업그레이드 하기

2.3.3 MySQL 설치 마법사 사용 하기 2.3.15. 유닉스상의 MySQL과 윈도우상의 MySQL 비교

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=0&scate=0&idx=55 (1 / 4)2006-08-03 오후 3:15:15

2.3.3.1 설치 마법사 소개 2.5. Mac OS X에 MySQL 설치하기

2.3.3.2 MySQL설치 마법사 다운 로드 및 시작 하기 2.6. NetWare에 MySQL 설치하기

2.3.3.3 설치 타입 선택 하기 2.7. 다른 유사 유닉스에 MySQL 설치하기

2.3.4.8 동시 접속 다이어로그 2.10.1. MySQL 5.0에서 업그레이드 하기

2.3.4.9 네트워킹 및 스트릭트(strict) 모드 옵션 다이어로그 2.10.2. MySQL 4.1에서 5.0으로 업그레이드 하기

2.3.4.10 문자 셋 다이어로그 2.10.3. MySQL 데이터 베이스를 다른 머신으로 복사하기

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=0&scate=0&idx=55 (2 / 4)2006-08-03 오후 3:15:15

2.9.1 윈도우에서 MySQL설치후 해야 할 과정 용해서 MySQL 설치하기”의 지침을 따를 것.

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=0&scate=0&idx=55 (3 / 4)2006-08-03 오후 3:15:15

야 한다.Section 2.13, “Perl 설치 노트”를 참조할 것.

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=0&scate=0&idx=55 (4 / 4)2006-08-03 오후 3:15:15

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

2. MySQL 설치 및 업그레이드 하기 2.1.1. MySQL이 지원하는 OS(Operating Systems)

2.1 일반 설치 사항 2.1.3. MySQL 가져 오기

2.1.4.1 MD5 체크썸 검증

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

상위메뉴리스트 ◆ 2.1.1. MySQL이 지원하는 OS

2. MySQL 설치 및 업그레이드 하기 이 섹션에서는 MySQL을 구동시키는데 사용할 수 있는 OS 리스트를 설명한다.

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=1&idx=57 (1 / 3)2006-08-03 오후 3:17:25

모든 플랫폼이 MySQL을 잘 구동시키는 것은 아니다. 어떤 플랫폼이 미션 크리티컬(mission-critical)한 고부하(high-load)의

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=1&idx=57 (2 / 3)2006-08-03 오후 3:17:25

● 수많은 사용자가 유사한 구성 환경의 플랫폼에서 성공적으로 MySQL을 구동하였다.

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=1&idx=57 (3 / 3)2006-08-03 오후 3:17:25

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

상위메뉴리스트 ◆ 2.1.2. MySQL 설치 배포판 선택하기

2.1.2.1 설치할 MySQL 버전 선택하기 2.1.2.5. MySQL AB사가 컴파일한 바이너리들

2.1.2.2 배포판 포맷 선택하기

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

2.1.2.1. 설치할 MySQL 버전 선택하기

2.1.2 MYSQL 설치 배포판 선택하기 를 갖게 된다:

2.1.2.1 설치할 MySQL 버전 선택하기

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=2&idx=59 (1 / 4)2006-08-03 오후 3:21:32

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=2&idx=59 (2 / 4)2006-08-03 오후 3:21:32

이 없는 경우에 알파에서 베타로 버전을 변경시킨다..

● 알씨(rc) 는 릴리즈 후보를 나타낸다; 즉, 일정 기간 동안 아무런 문제없이 잘 구동되는 베타 버전을 의미한다. 단지

MySQL 은 대부분의 다른 제품과는 다소 차이가 있는 명명 계획(naming scheme)을 사용한다. 일반적으로는, 어떠한 버전

모든 릴리즈는 적어도 아래의 툴을 사용해서 테스트 된다:

mysql-test 디렉토리는 광범위한 테스트 케이스를 갖고 있다. 우리는 가상으로 모든 서버 바이너리에 대해 이 테스

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=2&idx=59 (3 / 4)2006-08-03 오후 3:21:32

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=2&idx=59 (4 / 4)2006-08-03 오후 3:21:32

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

2.1.2.2. 배포판 포맷 선택하기

2.1.2.2 배포판 포맷 선택하기

어떤 환경하에서는, 여러분은 소스 배포판으로 설치하는 것이 더 유익할 수 도 있을 것이다:

● 여러분은 MySQL을 특정 위치에 설치하길 원할 수도 있다. 표준 바이너리 배포판은 어떤 위치에도 설치를 할 수 있지

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=2&idx=60 (1 / 2)2006-08-03 오후 3:21:57

❍ --with-berkeley-db (모든 플랫폼에는 사용 가능하지 않음)

http://www.mysqlkorea.com/develop/sub_07.html?lcate=2&mcate=1&scate=2&idx=60 (2 / 2)2006-08-03 오후 3:21:57

MySQLkorea.com의 사이트를 오픈하였습니다 많은 이용바랍니다. 최다 검색어 : select

2.1.2.3. 릴리즈는 언제 어떻게 발표되는가