MySQL 4.1 참조 설명서

This is a translation of the MySQL Reference Manual that can be found at dev.mysql.com. The original Reference Manual is in English, and this translation is not necessarily as up to date as the English version.

Copyright 1997-2006 MySQL AB

This documentation is NOT distributed under a GPL license. Use of this documentation is subject to the following terms: You may create a printed copy of this documentation solely for your own personal use. Conversion to other formats is allowed as long as the actual content is not altered or edited in any way. You shall not publish or distribute this documentation in any form or on any media, except if you distribute the documentation in a manner similar to how MySQL disseminates it (that is, electronically for download on a website with the software) or on a CD-ROM or similar medium, provided however that the documentation is disseminated together with the software on the same medium. Any other use, such as any dissemination of printed copies or use of this documentation, in whole or in part, in another publication, requires the prior written consent from an authorized representative of MySQL AB. MySQL AB reserves any and all rights to this documentation not expressly granted above.

Please email <docs@mysql.com> for more information or if you are interested in doing a translation.

개요

Document generated on: 2006-08-10

목차

Preface
1. 일반 정보
1.1. 이 메뉴얼에 대해
1.1.1. 이 메뉴얼의 표기 규칙
1.2. MySQL 데이타베이스 관리 시스템의 개요
1.2.1. MySQL 의 역사
1.2.2. MySQL 의 주된 기능
1.2.3. MySQL 의 안정성
1.2.4. MySQL 테이블의 최대 사이즈
1.2.5. 서기 2000 해대응
1.3. MySQL AB 의 개요
1.3.1. MySQL AB 의 비즈니스 모델과 서비스
1.3.2. 문의처
1.4. MySQL 의 서포트와 라이센스
1.4.1. MySQL AB 에 의해서 제공되는 서포트
1.4.2. MySQL 그리고 사용되고 있는 저작권과 라이센스
1.4.3. MySQL 라이센스
1.4.4. MySQL AB 의 로고와 상표
1.5. MySQL 의 개발 도로지도
1.5.1. MySQL 4.0 의 개요
1.5.2. MySQL 4.1 의 개요
1.5.3. MySQL 5.0 , 차기 개발 릴리스
1.6. MySQL 의 향후(TODO )
1.6.1. 4.1 그리고 계획되고 있는 신기능
1.6.2. 5.0 그리고 계획되고 있는 신기능
1.6.3. 5.1 그리고 계획되고 있는 신기능
1.6.4. 가까운 장래에 계획되고 있는 신기능
1.6.5. 중기적인 장래에 계획되고 있는 신기능
1.6.6. 계획되어 있지 않은 신기능
1.7. MySQL 의 정보원
1.7.1. MySQL 메일링 리스트
1.7.2. IRC (인터넷 릴레이 채팅)의 MySQL 커뮤니티 지원
1.8. MySQL 의 표준에의 준거
1.8.1. MySQL 하지만 준거하는 표준
1.8.2. ANSI 모드로의 MySQL 의 실행
1.8.3. SQL-92 표준에 대한다 MySQL 확장 기능
1.8.4. MySQL (와)과 SQL-92 (와)과의 차이
1.8.5. MySQL 에 있어서의 제약의 처리
1.8.6. MySQL 의 기존의 에러와 설계상의 문제
2. MySQL 의 인스톨
2.1. 표준 MySQL 의 퀵 인스톨
2.1.1. Windows 에의 MySQL 의 인스톨
2.1.2. Linux 에의 MySQL 의 인스톨
2.1.3. Mac OS X 에의 MySQL 의 인스톨
2.1.4. NetWare 에의 MySQL 의 인스톨
2.2. 인스톨 관련의 일반적인 문제
2.2.1. MySQL 의 입수방법
2.2.2. MD5 체크 섬 또는 GnuPG 에 의한 패키지 완전성의 검증
2.2.3. MySQL 하지만 서포트하고 있는 operating system
2.2.4. 사용해야 할 MySQL 의 버젼
2.2.5. 인스톨 레이아웃
2.2.6. 릴리스의 방법과 시기
2.2.7. 릴리스 이념 - 릴리스에 기존의 버그가 없다
2.2.8. MySQL AB 하지만 컴파일 했다 MySQL 바이너리
2.2.9. MySQL 바이너리 디스트리뷰션의 인스톨
2.3. MySQL 소스 디스트리뷰션의 인스톨
2.3.1. 퀵 인스톨의 개요
2.3.2. 패치의 적용
2.3.3. 일반적인 configure 옵션
2.3.4. 개발 소스 트리로부터의 인스톨
2.3.5. MySQL 의 컴파일에 관한 문제에의 대처
2.3.6. MIT-pthreads 에 관한 주의 사항
2.3.7. Windows 위에서 소스로부터 MySQL (을)를 인스톨 한다
2.4. 인스톨 후의 설정과 테스트
2.4.1. mysql_install_db 의 실행에 관한 문제
2.4.2. MySQL 서버의 기동에 관한 문제
2.4.3. MySQL (을)를 자동적으로 기동 및 정?~ 한다
2.5. MySQL 의 업그레이드와 다운 그레이드
2.5.1. 버젼 4.0 (으)로부터 4.1 에의 업그레이드
2.5.2. 버젼 3.23 (으)로부터 4.0 에의 업그레이드
2.5.3. 버젼 3.22 (으)로부터 3.23 에의 업그레이드
2.5.4. 버젼 3.21 (으)로부터 3.22 에의 업그레이드
2.5.5. 버젼 3.20 (으)로부터 3.21 에의 업그레이드
2.5.6. 권한 테이블의 업그레이드
2.5.7. 다른 Archie 텍 차에의 이행
2.5.8. Windows 위에서의 MySQL 의 업그레이드
2.6. operating system 고유의 주의 사항
2.6.1. Windows 의 주의 사항
2.6.2. Linux 의 주의 사항(모든 Linux 버젼)
2.6.3. Solaris 의 주의 사항
2.6.4. BSD 의 주의 사항
2.6.5. Mac OS X 의 주의 사항
2.6.6. 그 외의 Unix 의 주의 사항
2.6.7. OS/2 의 주의 사항
2.6.8. Novell NetWare 의 주의 사항
2.6.9. BeOS 의 주의 사항
2.7. Perl 인스톨에 대한 코멘트
2.7.1. Unix 에의 Perl 의 인스톨
2.7.2. Windows 에의 ActiveState Perl 의 인스톨
2.7.3. Perl DBI/DBD 인터페이스 사용시의 문제
3. MySQL 튜토리얼
3.1. 서버에의 접속 및 서버로부터의 절단
3.2. 쿼리의 입력
3.3. 데이타베이스의 작성 및 사용
3.3.1. 데이타베이스의 작성 및 선택
3.3.2. 테이블의 작성
3.3.3. 테이블에의 데이터의 로드
3.3.4. 테이블에서의 정보의 취득
3.4. 데이타베이스 및 테이블에 관한 정보의 취득
3.5. 배치 모드로의 mysql 의 사용
3.6. 일반적인 쿼리의 예
3.6.1. 컬럼의 최대치
3.6.2. 특정의 컬럼의 최대치가 격납되고 있는 레코드
3.6.3. 그룹마다의 컬럼의 최대치
3.6.4. 특정의 필드의 그룹마다의 최대치가 격납되고 있는 레코드
3.6.5. 유저 변수의 사용
3.6.6. 외부 키의 사용
3.6.7. 2 개의 키를 사용한 검색
3.6.8. 매일의 방문수의 계산
3.6.9. AUTO_INCREMENT 의 사용
3.7. 쌍생아 연구 프로젝트의 쿼리
3.7.1. 미방문의 모든 쌍생아의 검색
3.7.2. 쌍생아의 조의 스테이터스를 정리한 표의 작성
3.8. Apache (으)로의 MySQL 의 사용
4. 데이타베이스 관리
4.1. MySQL 의 콘피개
4.1.1. mysqld 커멘드 라인 옵션
4.1.2. my.cnf 옵션 설정 파일
4.2. 같은 머신상에서 복수의 MySQL 서버를 실행한다
4.2.1. Windows 위에서 복수의 서버를 실행한다
4.2.2. Unix 위에서 복수의 서버를 실행한다
4.2.3. 복수 서버 환경에서 클라이언트 프로그램을 사용한다
4.3. 일반적인 시큐러티 관련 사항과 MySQL 액세스 제어 시스템
4.3.1. 일반적인 시큐러티 가이드 라인
4.3.2. MySQL 의 크래커 대책
4.3.3. 시큐러티 관련의 mysqld 스타트 업 옵션
4.3.4. LOAD DATA LOCAL 의 시큐러티 관련 사항
4.3.5. 권한 시스템이 실시하는 것
4.3.6. 권한 시스템은 어떻게 기능할까
4.3.7. MySQL 하지만 제공하는 권한
4.3.8. MySQL 서버에의 접속
4.3.9. 액세스 제어의 단계 1: 접속 확인
4.3.10. 액세스 제어의 단계 2: 요구 확인
4.3.11. MySQL 4.1 의 패스워드 해시
4.3.12. Access denied 에러의 원인
4.4. MySQL 의 유저 관리
4.4.1. GRANT 및 REVOKE 의 구문
4.4.2. MySQL 의 유저명과 패스워드
4.4.3. 권한의 변경은 언제 반영될까
4.4.4. MySQL 권한의 초기설정
4.4.5. MySQL 에의 신규 유저의 추가
4.4.6. MySQL 유저의 삭제
4.4.7. 유저 자원의 제한
4.4.8. 패스워드의 설정
4.4.9. 패스워드의 시큐러티
4.4.10. 안전한 접속의 사용
4.5. 장해의 예방과 리커버리
4.5.1. 데이타베이스의 백업
4.5.2. BACKUP TABLE 구문
4.5.3. RESTORE TABLE 구문
4.5.4. CHECK TABLE 구문
4.5.5. REPAIR TABLE 구문
4.5.6. myisamchk (을)를 사용한 테이블의 보수와 크래쉬의 리커버리
4.5.7. 테이블 보수 계획
4.5.8. 테이블 정보의 취득
4.6. 데이타베이스 관리 언어 레퍼런스
4.6.1. OPTIMIZE TABLE 구문
4.6.2. ANALYZE TABLE 구문
4.6.3. CHECKSUM TABLE 구문
4.6.4. FLUSH 구문
4.6.5. RESET 구문
4.6.6. PURGE MASTER LOGS 구문
4.6.7. KILL 구문
4.6.8. SHOW 구문
4.7. MySQL 의 로컬라이즈와 국제적인 사용
4.7.1. 데이터 및 소트용 캐릭터 세트
4.7.2. 영어 이외의 에러 메세지
4.7.3. 새로운 캐릭터 세트의 추가
4.7.4. 캐릭터 정의 배열
4.7.5. 문자열 조합 서포트
4.7.6. 멀티 바이트 문자 서포트
4.7.7. 캐릭터 세트에 관한 문제
4.8. MySQL 서버 사이드의 스크립트와 유틸리티
4.8.1. 서버 사이드의 스크립트와 유틸리티의 개요
4.8.2. mysqld_safe (mysqld 의 나팔)
4.8.3. mysqld_multi (복수의 MySQL 서버를 관리하는 프로그램)
4.8.4. myisampack (MySQL 압축 독해 전용 테이블 제네레이터)
4.8.5. mysqld-max (확장 mysqld 서버)
4.9. MySQL 클라이언트 사이드의 스크립트와 유틸리티
4.9.1. 클라이언트 사이드의 스크립트와 유틸리티의 개요
4.9.2. mysql (커멘드 라인 툴)
4.9.3. mysqlcc (MySQL 컨트롤 센터)
4.9.4. mysqladmin (MySQL 서버의 관리)
4.9.5. mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)
4.9.6. mysqlcheck (을)를 사용한 테이블의 보수와 크래쉬의 리커버리
4.9.7. mysqldump (테이블 구조와 데이터의 덤프)
4.9.8. mysqlhotcopy (MySQL 의 데이타베이스와 테이블의 카피)
4.9.9. mysqlimport (텍스트 파일로부터의 데이터의 임포트)
4.9.10. mysqlshow (데이타베이스, 테이블, 및 컬럼의 표시)
4.9.11. mysql_config (클라이언트를 컴파일하기 위한 컴파일 옵션의 취득)
4.9.12. perror (에러 코드의 설명)
4.9.13. 텍스트 파일로부터 SQL 커멘드를 실행하는 방법
4.10. MySQL 로그 파일
4.10.1. 에러 로그
4.10.2. 일반 쿼리 로그
4.10.3. 갱신 로그
4.10.4. 바이너리 로그
4.10.5. 슬로우 쿼리 로그
4.10.6. 로그 파일의 보수
4.11. MySQL 의 replication
4.11.1. 처음에
4.11.2. replication 실장의 개요
4.11.3. replication의 실장의 상세
4.11.4. replication의 셋업 방법
4.11.5. replication 기능과 기존의 문제
4.11.6. replication 스타트 업 옵션
4.11.7. 마스터 서버를 제어한다 SQL 스테이트먼트
4.11.8. 슬레이브 서버를 제어한다 SQL 스테이트먼트
4.11.9. replication FAQ
4.11.10. replication의 트러블 슈팅
4.11.11. replication 버그의 리포트
5. MySQL 의 최적화
5.1. 최적화의 개요
5.1.1. MySQL 의 설계상의 제약과 트레이드 오프
5.1.2. 이식성
5.1.3. MySQL 사용 실적
5.1.4. MySQL 벤치마크스트
5.1.5. 독자적인 벤치마크의 사용
5.2. SELECT 스테이트먼트 및 그 외의 쿼리의 최적화
5.2.1. EXPLAIN 구문(SELECT 에 관한 정보의 취득)
5.2.2. 쿼리 퍼포먼스의 추정
5.2.3. SELECT 쿼리의 속도
5.2.4. MySQL 에 의한다 WHERE 마디의 최적화
5.2.5. MySQL 에 의한다 IS NULL 의 최적화
5.2.6. MySQL 에 의한다 DISTINCT 의 최적화
5.2.7. MySQL 에 의한다 LEFT JOIN (와)과 RIGHT JOIN 의 최적화
5.2.8. MySQL 에 의한다 ORDER BY 의 최적화
5.2.9. MySQL 에 의한다 LIMIT 의 최적화
5.2.10. INSERT 쿼리의 속도
5.2.11. UPDATE 쿼리의 속도
5.2.12. DELETE 쿼리의 속도
5.2.13. 그 외의 최적화의 힌트
5.3. 락 관련의 문제
5.3.1. MySQL 의 테이블 락 방법
5.3.2. 테이블 락 관련의 문제
5.4. 데이타베이스 구조의 최적화
5.4.1. 설계상의 선택
5.4.2. 데이터의 소형화
5.4.3. MySQL (으)로의 인덱스의 사용
5.4.4. 컬럼 인덱스
5.4.5. 복합 인덱스
5.4.6. MySQL 의 오픈 테이블의 카운트 방법
5.4.7. MySQL (으)로의 테이블의 오픈과 클로우즈의 방법
5.4.8. 1 개의 데이타베이스에 대량의 테이블을 작성했을 경우의 결점
5.5. MySQL 서버의 최적화
5.5.1. 시스템, 컴파일 시간 및 스타트 업 파라미터의 튜닝
5.5.2. 서버 파라미터의 튜닝
5.5.3. MySQL 의 속도에 대한 컴파일과 링크의 영향
5.5.4. MySQL (으)로의 메모리의 사용
5.5.5. MySQL 의 DNS 의 사용
5.5.6. SET 구문
5.6. 디스크 관련의 문제
5.6.1. 기호 연결의 사용
6. MySQL SQL 언어 레퍼런스
6.1. 언어 구조
6.1.1. 리터럴: 문자열과 수치의 기술 방법
6.1.2. 데이타베이스명, 테이블명, 인덱스명, 컬럼명, 앨리어스(alias)명
6.1.3. 이름에 있어서의 케이스 의존
6.1.4. 유저 변수
6.1.5. 시스템 변수
6.1.6. 코멘트 구문
6.1.7. MySQL (으)로의 예약어(reserved word)의 취급
6.2. 컬럼형
6.2.1. 수치형
6.2.2. 일자와 시각형
6.2.3. 문자열형
6.2.4. 올바른 컬럼형의 선택
6.2.5. 다른 데이타베이스 엔진의 컬럼형의 사용
6.2.6. 각 컬럼형에 필요한 기억용량
6.3. SELECT 마디와 WHERE 마디로 사용하는 함수
6.3.1. 각 데이터형 공통의 연산자와 함수
6.3.2. 문자열 함수
6.3.3. 수치 함수
6.3.4. 일자와 시각 함수
6.3.5. 캐스트 함수
6.3.6. 그 외의 함수
6.3.7. GROUP BY 마디로 사용하는 함수와 수식자
6.4. 데이터의 조작: SELECT ,INSERT ,UPDATE ,DELETE
6.4.1. SELECT 구문
6.4.2. 서브 쿼리 구문
6.4.3. INSERT 구문
6.4.4. UPDATE 구문
6.4.5. DELETE 구문
6.4.6. TRUNCATE 구문
6.4.7. REPLACE 구문
6.4.8. LOAD DATA INFILE 구문
6.4.9. HANDLER 구문
6.4.10. DO 구문
6.5. 데이터 정의: CREATE ,DROP ,ALTER
6.5.1. CREATE DATABASE 구문
6.5.2. DROP DATABASE 구문
6.5.3. CREATE TABLE 구문
6.5.4. ALTER TABLE 구문
6.5.5. RENAME TABLE 구문
6.5.6. DROP TABLE 구문
6.5.7. CREATE INDEX 구문
6.5.8. DROP INDEX 구문
6.6. MySQL 기본 유저 유틸리티 커멘드
6.6.1. USE 구문
6.6.2. DESCRIBE 구문(컬럼에 관한 정보의 취득)
6.7. MySQL 트랜잭션(transaction) 커멘드와 락 커멘드
6.7.1. START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문
6.7.2. 롤백(rollback) 할 수 없는 스테이트먼트
6.7.3. 암묵적인 코?~ 트를 일으키는 스테이트먼트
6.7.4. SAVEPOINT 및 ROLLBACK TO SAVEPOINT 구문
6.7.5. LOCK TABLES 및 UNLOCK TABLES 구문
6.7.6. SET TRANSACTION 구문
6.8. MySQL 풀텍스트 검색
6.8.1. 풀텍스트 검색에 있어서의 제약
6.8.2. MySQL 풀텍스트 검색의 조정
6.8.3. 풀텍스트 검색에 관련한다 TODO 항목
6.9. MySQL 쿼리 캐쉬
6.9.1. 쿼리 캐쉬의 동작
6.9.2. 쿼리 캐쉬의 설정
6.9.3. SELECT (으)로의 쿼리 캐쉬 옵션
6.9.4. 쿼리 캐쉬의 스테이터스와 보수
7. MySQL 의 테이블형
7.1. MyISAM 테이블
7.1.1. 키에 필요한 영역
7.1.2. MyISAM 테이블 형식
7.1.3. MyISAM 테이블의 문제
7.2. MERGE 테이블
7.2.1. MERGE 테이블의 문제
7.3. ISAM 테이블
7.4. HEAP 테이블
7.5. InnoDB 테이블
7.5.1. InnoDB 테이블의 개요
7.5.2. MySQL 버젼 3.23 (으)로의 InnoDB
7.5.3. InnoDB 기동 옵션
7.5.4. InnoDB 테이블 스페이스의 작성
7.5.5. InnoDB 테이블의 작성
7.5.6. InnoDB 데이터 파일과 로그 파일의 추가와 삭제
7.5.7. InnoDB 데이타베이스의 백업과 리커버리
7.5.8. InnoDB 데이타베이스를 다른 머신으로 이동한다
7.5.9. InnoDB 트랜잭션(transaction) 모델과 락
7.5.10. 퍼포먼스 튜닝의 힌트
7.5.11. 마르치바죠닝의 실장
7.5.12. 테이블과 인덱스의 구조
7.5.13. 파일 영역의 관리와 디스크 I/O
7.5.14. 에러 처리
7.5.15. InnoDB 테이블의 제한 사항
7.5.16. InnoDB 의 변경 이력
7.5.17. InnoDB 에 대한 문의처
7.6. BDB 또는 BerkeleyDB 테이블
7.6.1. BDB 테이블의 개요
7.6.2. BDB 의 인스톨
7.6.3. BDB 기동 옵션
7.6.4. BDB 테이블의 특성
7.6.5. 가까운 장래에 수정할 필요가 있다 BDB 의 문제
7.6.6. BDB 그리고 서포트되고 있는 operating system
7.6.7. BDB 테이블의 제한 사항
7.6.8. BDB 테이블을 사용할 경우에 일어날 수 있는 에러
8. MaxDB 의 개요
8.1. MaxDB 의 역사
8.2. 라이센스와 서포트
8.3. MaxDB 의 기본 개념
8.4. MaxDB (와)과 MySQL 의 차이점
8.5. MaxDB (와)과 MySQL 의 상호 운용성
8.6. MaxDB 관련 링크
8.7. MaxDB 의 예약어(reserved word)
9. 각국 캐릭터 세트와 Unicode
9.1. 일반의 캐릭터 세트 및 조합 순서
9.2. MySQL 에 있어서의 캐릭터 세트 및 조합 순서
9.3. 디폴트의 캐릭터 세트 및 조합 순서의 결정
9.3.1. 서버의 캐릭터 세트 및 조합 순서
9.3.2. 데이타베이스의 캐릭터 세트 및 조합 순서
9.3.3. 테이블의 캐릭터 세트 및 조합 순서
9.3.4. 컬럼의 캐릭터 세트 및 조합 순서
9.3.5. 캐릭터 세트와 조합 순서의 할당의 예
9.3.6. 접속의 캐릭터 세트 및 조합 순서
9.3.7. 문자열 리터럴의 캐릭터 세트 및 조합 순서
9.3.8. SQL 쿼리의 각 부분에 있어서의 COLLATE 절
9.3.9. COLLATE 마디의 우선 순위
9.3.10. BINARY 연산자
9.3.11. 조합 순서를 결정하는 것이 어려운 특수한 케이스
9.3.12. 조합 순서는 적절한 캐릭터 세트에 대응하고 있는 것
9.3.13. 조합 순서가 가져오는 결과의 예
9.4. 캐릭터 세트의 서포트에 의한 영향을 받는 연산
9.4.1. 결과 문자열
9.4.2. CONVERT()
9.4.3. CAST()
9.4.4. SHOW CHARACTER SET
9.4.5. SHOW COLLATION
9.4.6. SHOW CREATE DATABASE
9.4.7. SHOW FULL COLUMNS
9.5. Unicode 의 서포트
9.6. 메타데이타용의 UTF8
9.7. 다른 DBMS (와)과의 호환성
9.8. 신규 캐릭터 세트 설정 파일의 형식
9.9. 각국 캐릭터 세트
9.10. MySQL 4.0 (으)로부터의 업그레이드
9.10.1. 4.0 캐릭터 세트 및 대응한다 4.1 캐릭터 세트/ 조합 순서의 페어
9.11. MySQL 그리고 서포트되는 캐릭터 세트와 조합 순서
9.11.1. Unicode 캐릭터 세트
9.11.2. 플랫폼 고유의 캐릭터 세트
9.11.3. 남유럽 및 중동의 캐릭터 세트
9.11.4. 아시아의 캐릭터 세트
9.11.5. 발트어 캐릭터 세트
9.11.6. 키릴어 캐릭터 세트
9.11.7. 중앙 유럽의 캐릭터 세트
9.11.8. 서유럽의 캐릭터 세트
10. MySQL 에 있어서의 공간 정보의 기능
10.1. 처음에
10.2. OpenGIS Geometry 모델
10.2.1. Geometry Class 계층
10.2.2. Geometry 클래스
10.2.3. 클래스 Point
10.2.4. Curve 클래스
10.2.5. LineString 클래스
10.2.6. Surface 클래스
10.2.7. Polygon 클래스
10.2.8. GeometryCollection 클래스
10.2.9. MultiPoint 클래스
10.2.10. MultiCurve 클래스
10.2.11. MultiLineString 클래스
10.2.12. MultiSurface 클래스
10.2.13. MultiPolygon 클래스
10.3. 서포트되고 있는 공간 데이터 형식
10.3.1. Well-Known Text (WKT ) 형식
10.3.2. Well-Known Binary (WKB ) 형식
10.4. 공간적으로 유효한 MySQL 데이타베이스의 작성
10.4.1. MySQL 공간 데이터형
10.4.2. 공간 정보의 값의 작성
10.4.3. 공간 정보 컬럼의 작성
10.4.4. 공간 정보 컬럼에게의 데이터 입력
10.4.5. 공간 데이터의 혼잡
10.5. 공간 정보의 분석
10.5.1. 지오메트리의 형식을 변환하는 함수
10.5.2. Geometry 프롭퍼티 분석 함수
10.5.3. 기존 지오메트리로부터 신규 지오메트리를 작성하는 함수
10.5.4. Geometry Object간의 공간적 관계를 테스트하기 위한 함수
10.5.5. 최소 외접 구형(MBR )에 있어서의 관계
10.5.6. 지오메트리간의 공간 관계를 테스트하는 함수
10.6. 공간 분석의 최적화
10.6.1. 공간 인덱스의 작성
10.6.2. 공간 인덱스의 사용
10.7. MySQL 의 적합성과 호환성
10.7.1. 아직 실장되어 있지 않다 GIS 기능
11. MySQL API
11.1. MySQL C API
11.1.1. C API 데이터형
11.1.2. C API 함수의 개요
11.1.3. C API 함수의 설명
11.1.4. C API 의 Prepared Statements
11.1.5. C API 의 Prepared Statement의 데이터형
11.1.6. C API 의 Prepared Statement 함수의 개요
11.1.7. C API 의 Prepared Statement 함수의 설명
11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급
11.1.9. C API 에 있어서의 일자치 및 시각치의 취급
11.1.10. C API 스레드 함수의 설명
11.1.11. C API 편입 서버 함수의 설명
11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제
11.1.13. 클라이언트 프로그램의 빌드
11.1.14. 스레드 클라이언트의 작성 방법
11.1.15. 편입 MySQL 서버 라이브러리 libmysqld
11.2. MySQL 의 ODBC 서포트
11.2.1. MyODBC 의 인스톨 방법
11.2.2. ODBC 아드?~ 니스트레이타의 필드의 설정 방법법
11.2.3. MyODBC 의 접속 파라미터
11.2.4. MyODBC 에 관한 문제를 보고하는 방법
11.2.5. MyODBC (와)과 제휴해 동작하는 것이 알려져 있는 프로그램
11.2.6. ODBC 그리고 AUTO_INCREMENT 속성을 가지는 컬럼의 값을 취득하는 방법
11.2.7. MyODBC 에 관한 문제의 보고
11.3. MySQL 의 Java 접속(JDBC )
11.4. MySQL PHP API
11.4.1. MySQL 및 PHP (이)가 좋게 있는 문제
11.5. MySQL Perl API
11.5.1. DBI (와)과 DBD::mysql
11.5.2. DBI 인터페이스
11.5.3. DBI/DBD 에 관한 그 외의 정보
11.6. MySQL C++ API
11.6.1. Borland C++
11.7. MySQL Python API
11.8. MySQL Tcl API
11.9. MySQL Eiffel Wrapper
12. MySQL 의 에러 처리
12.1. 돌려주어지는 에러
13. MySQL 의 확장
13.1. MySQL 의 내부 정보
13.1.1. MySQL 의 스레드
13.1.2. MySQL 테스트 스위트
13.2. MySQL 에의 새로운 함수의 추가
13.2.1. CREATE FUNCTION/DROP FUNCTION 의 구문
13.2.2. 새로운 유저 정의 함수의 추가
13.2.3. 새로운 네이티브 함수의 추가
13.3. MySQL 에의 새로운 프로시저의 추가
13.3.1. 프로시저의 분석
13.3.2. 프로시저의 작성
A. 문제와 일반적인 에러
A.1. 문제의 원인을 찔러?~ 방법
A.2. MySQL 사용시에 자주 있는 에러
A.2.1. Access denied 에러
A.2.2. MySQL server has gone away 에러
A.2.3. Can't connect to [local] MySQL server 에러
A.2.4. Client does not support authentication protocol 에러
A.2.5. Host '...' is blocked 에러
A.2.6. Too many connections 에러
A.2.7. Some non-transactional changed tables couldn't be rolled back 에러
A.2.8. Out of memory 에러
A.2.9. Packet too large 에러
A.2.10. 통신 에러/Aborted connection
A.2.11. The table is full 에러
A.2.12. Can't create/write to file 에러
A.2.13. 클라이언트로의 Commands out of sync 에러
A.2.14. Ignoring user 에러
A.2.15. Table 'xxx' doesn't exist 에러
A.2.16. Can't initialize character set xxx 에러
A.2.17. File Not Found 에러
A.3. 인스톨 관련의 문제
A.3.1. MySQL 클라이언트 라이브러리에 링크시의 문제
A.3.2. 일반 유저로 MySQL (을)를 실행하는 방법
A.3.3. 파일 액세스권의 문제
A.4. 관리 관련의 문제
A.4.1. MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것
A.4.2. 잊은 루트 패스워드를 리셋트 하는 방법
A.4.3. 풀 디스크시의 MySQL 의 동작
A.4.4. MySQL 하지만 임시 파일을 격납하는 장소
A.4.5. MySQL 소켓 파일 /tmp/mysql.sock 의 보호 또는 변경 방법
A.4.6. 타임 존의 문제
A.5. 쿼리 관련의 문제
A.5.1. 검색시의 케이스 의존
A.5.2. DATE 컬럼 사용시의 문제
A.5.3. NULL 값의 문제
A.5.4. alias 의 문제
A.5.5. 관련 테이블에서의 레코드의 삭제
A.5.6. 부정합레코드의 문제 해결
A.5.7. 부동 소수점 비교의 문제
A.6. Optimizer 관련의 문제
A.6.1. 테이블 스캔을 회피하는 방법
A.7. 테이블 정의 관련의 문제
A.7.1. ALTER TABLE 의 문제
A.7.2. 테이블의 컬럼 순서를 변경하는 방법
A.7.3. 텐포라리테이불의 문제
B. 제공된 프로그램
B.1. API
B.2. 컨버터
B.3. 유틸리티
C. 협력자
C.1. MySQL AB 의 개발자
C.2. MySQL 에의의 공헌자
C.3. 문서 작성자 및 번역자
C.4. MySQL 그리고 사용되고 있는 라이브러리와 MySQL 부속의 라이브러리
C.5. MySQL (을)를 서포트하는 패키지
C.6. MySQL 의 작성에 사용한 툴
C.7. MySQL 의 서포터
D. MySQL Change History
D.1. Changes in release 5.0.0 (Development)
D.2. Changes in release 4.1.x (Alpha)
D.2.1. Changes in release 4.1.2 (not released yet)
D.2.2. Changes in release 4.1.1 (01 Dec 2003)
D.2.3. Changes in release 4.1.0 (03 Apr 2003: Alpha)
D.3. Changes in release 4.0.x (Production)
D.3.1. Changes in release 4.0.17 (not released yet)
D.3.2. Changes in release 4.0.16 (17 Oct 2003)
D.3.3. Changes in release 4.0.15 (03 Sep 2003)
D.3.4. Changes in release 4.0.14 (18 Jul 2003)
D.3.5. Changes in release 4.0.13 (16 May 2003)
D.3.6. Changes in release 4.0.12 (15 Mar 2003: Production)
D.3.7. Changes in release 4.0.11 (20 Feb 2003)
D.3.8. Changes in release 4.0.10 (29 Jan 2003)
D.3.9. Changes in release 4.0.9 (09 Jan 2003)
D.3.10. Changes in release 4.0.8 (07 Jan 2003)
D.3.11. Changes in release 4.0.7 (20 Dec 2002)
D.3.12. Changes in release 4.0.6 (14 Dec 2002: Gamma)
D.3.13. Changes in release 4.0.5 (13 Nov 2002)
D.3.14. Changes in release 4.0.4 (29 Sep 2002)
D.3.15. Changes in release 4.0.3 (26 Aug 2002: Beta)
D.3.16. Changes in release 4.0.2 (01 Jul 2002)
D.3.17. Changes in release 4.0.1 (23 Dec 2001)
D.3.18. Changes in release 4.0.0 (Oct 2001: Alpha)
D.4. Changes in release 3.23.x (Recent; still supported)
D.4.1. Changes in release 3.23.59 (not released yet)
D.4.2. Changes in release 3.23.58 (11 Sep 2003)
D.4.3. Changes in release 3.23.57 (06 Jun 2003)
D.4.4. Changes in release 3.23.56 (13 Mar 2003)
D.4.5. Changes in release 3.23.55 (23 Jan 2003)
D.4.6. Changes in release 3.23.54 (05 Dec 2002)
D.4.7. Changes in release 3.23.53 (09 Oct 2002)
D.4.8. Changes in release 3.23.52 (14 Aug 2002)
D.4.9. Changes in release 3.23.51 (31 May 2002)
D.4.10. Changes in release 3.23.50 (21 Apr 2002)
D.4.11. Changes in release 3.23.49
D.4.12. Changes in release 3.23.48 (07 Feb 2002)
D.4.13. Changes in release 3.23.47 (27 Dec 2001)
D.4.14. Changes in release 3.23.46 (29 Nov 2001)
D.4.15. Changes in release 3.23.45 (22 Nov 2001)
D.4.16. Changes in release 3.23.44 (31 Oct 2001)
D.4.17. Changes in release 3.23.43 (04 Oct 2001)
D.4.18. Changes in release 3.23.42 (08 Sep 2001)
D.4.19. Changes in release 3.23.41 (11 Aug 2001)
D.4.20. Changes in release 3.23.40
D.4.21. Changes in release 3.23.39 (12 Jun 2001)
D.4.22. Changes in release 3.23.38 (09 May 2001)
D.4.23. Changes in release 3.23.37 (17 Apr 2001)
D.4.24. Changes in release 3.23.36 (27 Mar 2001)
D.4.25. Changes in release 3.23.35 (15 Mar 2001)
D.4.26. Changes in release 3.23.34a
D.4.27. Changes in release 3.23.34 (10 Mar 2001)
D.4.28. Changes in release 3.23.33 (09 Feb 2001)
D.4.29. Changes in release 3.23.32 (22 Jan 2001: Production)
D.4.30. Changes in release 3.23.31 (17 Jan 2001)
D.4.31. Changes in release 3.23.30 (04 Jan 2001)
D.4.32. Changes in release 3.23.29 (16 Dec 2000)
D.4.33. Changes in release 3.23.28 (22 Nov 2000: Gamma)
D.4.34. Changes in release 3.23.27 (24 Oct 2000)
D.4.35. Changes in release 3.23.26 (18 Oct 2000)
D.4.36. Changes in release 3.23.25 (29 Sep 2000)
D.4.37. Changes in release 3.23.24 (08 Sep 2000)
D.4.38. Changes in release 3.23.23 (01 Sep 2000)
D.4.39. Changes in release 3.23.22 (31 Jul 2000)
D.4.40. Changes in release 3.23.21
D.4.41. Changes in release 3.23.20
D.4.42. Changes in release 3.23.19
D.4.43. Changes in release 3.23.18
D.4.44. Changes in release 3.23.17
D.4.45. Changes in release 3.23.16
D.4.46. Changes in release 3.23.15 (May 2000: Beta)
D.4.47. Changes in release 3.23.14
D.4.48. Changes in release 3.23.13
D.4.49. Changes in release 3.23.12 (07 Mar 2000)
D.4.50. Changes in release 3.23.11
D.4.51. Changes in release 3.23.10
D.4.52. Changes in release 3.23.9
D.4.53. Changes in release 3.23.8 (02 Jan 2000)
D.4.54. Changes in release 3.23.7 (10 Dec 1999)
D.4.55. Changes in release 3.23.6
D.4.56. Changes in release 3.23.5 (20 Oct 1999)
D.4.57. Changes in release 3.23.4 (28 Sep 1999)
D.4.58. Changes in release 3.23.3
D.4.59. Changes in release 3.23.2 (09 Aug 1999)
D.4.60. Changes in release 3.23.1
D.4.61. Changes in release 3.23.0 (05 Aug 1999: Alpha)
D.5. Changes in release 3.22.x (Old; discontinued)
D.5.1. Changes in release 3.22.35
D.5.2. Changes in release 3.22.34
D.5.3. Changes in release 3.22.33
D.5.4. Changes in release 3.22.32 (14 Feb 2000)
D.5.5. Changes in release 3.22.31
D.5.6. Changes in release 3.22.30
D.5.7. Changes in release 3.22.29 (02 Jan 2000)
D.5.8. Changes in release 3.22.28 (20 Oct 1999)
D.5.9. Changes in release 3.22.27
D.5.10. Changes in release 3.22.26 (16 Sep 1999)
D.5.11. Changes in release 3.22.25
D.5.12. Changes in release 3.22.24 (05 Jul 1999)
D.5.13. Changes in release 3.22.23 (08 Jun 1999)
D.5.14. Changes in release 3.22.22 (30 Apr 1999)
D.5.15. Changes in release 3.22.21
D.5.16. Changes in release 3.22.20 (18 Mar 1999)
D.5.17. Changes in release 3.22.19 (Mar 1999: Production)
D.5.18. Changes in release 3.22.18
D.5.19. Changes in release 3.22.17
D.5.20. Changes in release 3.22.16 (Feb 1999: Gamma)
D.5.21. Changes in release 3.22.15
D.5.22. Changes in release 3.22.14
D.5.23. Changes in release 3.22.13
D.5.24. Changes in release 3.22.12
D.5.25. Changes in release 3.22.11
D.5.26. Changes in release 3.22.10
D.5.27. Changes in release 3.22.9
D.5.28. Changes in release 3.22.8
D.5.29. Changes in release 3.22.7 (Sep 1998: Beta)
D.5.30. Changes in release 3.22.6
D.5.31. Changes in release 3.22.5
D.5.32. Changes in release 3.22.4
D.5.33. Changes in release 3.22.3
D.5.34. Changes in release 3.22.2
D.5.35. Changes in release 3.22.1 (Jun 1998: Alpha)
D.5.36. Changes in release 3.22.0
D.6. Changes in release 3.21.x
D.6.1. Changes in release 3.21.33
D.6.2. Changes in release 3.21.32
D.6.3. Changes in release 3.21.31
D.6.4. Changes in release 3.21.30
D.6.5. Changes in release 3.21.29
D.6.6. Changes in release 3.21.28
D.6.7. Changes in release 3.21.27
D.6.8. Changes in release 3.21.26
D.6.9. Changes in release 3.21.25
D.6.10. Changes in release 3.21.24
D.6.11. Changes in release 3.21.23
D.6.12. Changes in release 3.21.22
D.6.13. Changes in release 3.21.21a
D.6.14. Changes in release 3.21.21
D.6.15. Changes in release 3.21.20
D.6.16. Changes in release 3.21.19
D.6.17. Changes in release 3.21.18
D.6.18. Changes in release 3.21.17
D.6.19. Changes in release 3.21.16
D.6.20. Changes in release 3.21.15
D.6.21. Changes in release 3.21.14b
D.6.22. Changes in release 3.21.14a
D.6.23. Changes in release 3.21.13
D.6.24. Changes in release 3.21.12
D.6.25. Changes in release 3.21.11
D.6.26. Changes in release 3.21.10
D.6.27. Changes in release 3.21.9
D.6.28. Changes in release 3.21.8
D.6.29. Changes in release 3.21.7
D.6.30. Changes in release 3.21.6
D.6.31. Changes in release 3.21.5
D.6.32. Changes in release 3.21.4
D.6.33. Changes in release 3.21.3
D.6.34. Changes in release 3.21.2
D.6.35. Changes in release 3.21.0
D.7. Changes in release 3.20.x
D.7.1. Changes in release 3.20.18
D.7.2. Changes in release 3.20.17
D.7.3. Changes in release 3.20.16
D.7.4. Changes in release 3.20.15
D.7.5. Changes in release 3.20.14
D.7.6. Changes in release 3.20.13
D.7.7. Changes in release 3.20.11
D.7.8. Changes in release 3.20.10
D.7.9. Changes in release 3.20.9
D.7.10. Changes in release 3.20.8
D.7.11. Changes in release 3.20.7
D.7.12. Changes in release 3.20.6
D.7.13. Changes in release 3.20.3
D.7.14. Changes in release 3.20.0
D.8. Changes in release 3.19.x
D.8.1. Changes in release 3.19.5
D.8.2. Changes in release 3.19.4
D.8.3. Changes in release 3.19.3
E. 타시스템에의 이식
E.1. MySQL 서버의 디버그
E.1.1. MYSQL 의 컴파일(디버그용)
E.1.2. 트레이스 파일의 작성
E.1.3. mysqld 의 디버그(gdb 사용)
E.1.4. 스택 트레이스의 사용
E.1.5. mysqld 에 있어서의 에러의 원인을 로그 파일을 사용해 특정한다
E.1.6. 테이블이 파손했을 경우에 시험대를 작성한다
E.2. MySQL 클라이언트의 디버그
E.3. DBUG 패키지
E.4. 락 방법
E.5. RTS 스레드에 관한 코멘트
E.6. 다른 스레드패키지간의 차이
F. 환경 변수
G. MySQL 의 정규 표현
H. GNU General Public License


Preface

이것은 MySQL 데이타베이스 시스템 의 참조 설명서입니다.버젼 5.0.6-beta 의 MySQL 서버 에 붙어 기술하고 있습니다.변경점을 항상 설명하고 있습니다.그 때문에, 낡은 버젼(3.23 또는 4.0 제품판등)을 사용하고 있는 경우에서도, 이 메뉴얼은 참고가 됩니다.버젼 5.0 (개발판)의 레퍼런스도 있습니다.


제1 장 일반 정보

목차

1.1. 이 메뉴얼에 대해
1.1.1. 이 메뉴얼의 표기 규칙
1.2. MySQL 데이타베이스 관리 시스템의 개요
1.2.1. MySQL 의 역사
1.2.2. MySQL 의 주된 기능
1.2.3. MySQL 의 안정성
1.2.4. MySQL 테이블의 최대 사이즈
1.2.5. 서기 2000 해대응
1.3. MySQL AB 의 개요
1.3.1. MySQL AB 의 비즈니스 모델과 서비스
1.3.2. 문의처
1.4. MySQL 의 서포트와 라이센스
1.4.1. MySQL AB 에 의해서 제공되는 서포트
1.4.2. MySQL 그리고 사용되고 있는 저작권과 라이센스
1.4.3. MySQL 라이센스
1.4.4. MySQL AB 의 로고와 상표
1.5. MySQL 의 개발 도로지도
1.5.1. MySQL 4.0 의 개요
1.5.2. MySQL 4.1 의 개요
1.5.3. MySQL 5.0 , 차기 개발 릴리스
1.6. MySQL 의 향후(TODO )
1.6.1. 4.1 그리고 계획되고 있는 신기능
1.6.2. 5.0 그리고 계획되고 있는 신기능
1.6.3. 5.1 그리고 계획되고 있는 신기능
1.6.4. 가까운 장래에 계획되고 있는 신기능
1.6.5. 중기적인 장래에 계획되고 있는 신기능
1.6.6. 계획되어 있지 않은 신기능
1.7. MySQL 의 정보원
1.7.1. MySQL 메일링 리스트
1.7.2. IRC (인터넷 릴레이 채팅)의 MySQL 커뮤니티 지원
1.8. MySQL 의 표준에의 준거
1.8.1. MySQL 하지만 준거하는 표준
1.8.2. ANSI 모드로의 MySQL 의 실행
1.8.3. SQL-92 표준에 대한다 MySQL 확장 기능
1.8.4. MySQL (와)과 SQL-92 (와)과의 차이
1.8.5. MySQL 에 있어서의 제약의 처리
1.8.6. MySQL 의 기존의 에러와 설계상의 문제

MySQL (R) 소프트웨어에 의해서, 매우 고속으로 견뢰한 multi-thread 형식의 multiuser SQL (Structured Query Language ) 데이터 베이스 서버가 실현됩니다.MySQL 서버 (은)는,?~ 션크리티칼로 부하가 높은 운용 시스템에도, 대규모로 전개되는 소프트웨어에의 편입에도 대응하도록(듯이) 설계되고 있습니다.MySQL (은)는,MySQL AB 의 상표입니다.

MySQL 소프트웨어는 듀얼 라이센스 제품입니다.유저는,GNU 일반 공중 이용 허락 계약서 (http://www.fsf.org/licenses/ )의 조건에 근거해 오픈 소스/ 프리 소프트웨어 제품으로서 MySQL 소프트웨어를 사용하는 일도,MySQL AB (으)로부터 표준의 상용 라이센스를 구입할 수도 있습니다. See 항1.4. 「MySQL 의 서포트와 라이센스」 .

MySQL 의 Web 사이트(http://www.mysql.com/ )에는,MySQL 소프트웨어에 관한 최신 정보가 게재되고 있습니다.

이 메뉴얼로 특히 흥미로운 섹션은 이하대로입니다.

  • MySQL 데이터 베이스 서버 의 배경에 있는 회사에 관한 정보에 대해서는, 항1.3. 「MySQL AB 의 개요」 (을)를 참조.

  • MySQL 데이터 베이스 서버 의 기능에 관한 설명에 대해서는, 항1.2.2. 「MySQL 의 주된 기능」 (을)를 참조.

  • 인스톨의 순서에 대해서는, 장 2. MySQL 의 인스톨 (을)를 참조.

  • 새로운 아키텍쳐 또는 operating system에의 MySQL Database Software 의 이식에 관한 힌트에 대해서는, 부록 E. 타시스템에의 이식 (을)를 참조.

  • 버젼 4.0 릴리스로부터의 업그레이드에 관한 정보에 대해서는, 항2.5.1. 「버젼 4.0 (으)로부터 4.1 에의 업그레이드」 (을)를 참조.

  • 버젼 3.23 릴리스로부터의 업그레이드에 관한 정보에 대해서는, 항2.5.2. 「버젼 3.23 (으)로부터 4.0 에의 업그레이드」 (을)를 참조.

  • 버젼 3.22 릴리스로부터의 업그레이드에 관한 정보에 대해서는, 항2.5.3. 「버젼 3.22 (으)로부터 3.23 에의 업그레이드」 (을)를 참조.

  • MySQL 데이터 베이스 서버 의 튜토리얼에 대해서는, 장 3. MySQL 튜토리얼 (을)를 참조.

  • SQL 의 샘플과 벤치마크 정보에 대해서는, 벤치마크 디렉토리(디스트리뷰션의 sql-bench )(을)를 참조.

  • 신기능과 버그 수정의 이력에 대해서는, 부록 D. MySQL Change History (을)를 참조.

  • 기존의 버그나 기능상의 문제의 일람에 대해서는, 항1.8.6. 「MySQL 의 기존의 에러와 설계상의 문제」 (을)를 참조.

  • 향후의 계획에 대해서는, 항1.6. 「MySQL 의 향후(TODO )」 (을)를 참조.

  • 이 프로젝트에의 전공헌자의 일람에 대해서는, 부록 C. 협력자 (을)를 참조.

중요:

에러(많은 경우, 버그로 불립니다)의 보고는, 질문이나 코멘트와 같게, 통상의 MySQL 메일링 리스트에 전송해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 . See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

Unix 그럼,mysqlbug 스크립트를 사용해 버그 리포트를 생성합니다(Windows 디스트리뷰션에 대해서는,basedir 에 파일 mysqlbug.txt 하지만 있습니다.이 파일을 버그 리포트의 템플릿으로서 사용해 주세요).

소스 디스트리뷰션에 대해서는,mysqlbug 스크립트는 scripts 디렉토리에 있습니다.바이너리 디스트리뷰션에 대해서는,mysqlbug 하 bin 디렉토리(MySQL 서버 RPM 패키지의 경우는 /usr/bin )에 있습니다.

MySQL 서버 그리고 중대한 시큐러티 버그를 찾아냈을 경우는,<security@mysql.com> 에 전자 메일을 전송해 주세요.

1.1. 이 메뉴얼에 대해

이것은,MySQL 의 참조 설명서입니다.버젼 5.0.6-beta 의 MySQL 에 붙어 기술하고 있습니다.기능에 관한 변경은 항상, 버젼에 언급해 설명하고 있습니다.그 때문에, 낡은 버젼의 MySQL 소프트웨어(3.23 또는 4.0 제품판등)을 사용하고 있는 경우에서도, 이 메뉴얼은 참고가 됩니다.버젼 5.0 (개발판)의 레퍼런스도 있습니다.

이것은 참조 설명서이므로,SQL (이)나 RDB의 개념에 관한 일반적인 설명은 기재하고 있지 않습니다.

MySQL 데이타베이스 소프트웨어 (은)는 계속하고 개발을 하고 있으므로, 메뉴얼도 빈번히 갱신됩니다.이 메뉴얼의 최신판은,http://www.mysql.com/documentation/ (으)로부터 HTML ,PDF ,Windows HLP 판등이 다양한 형식에서 입수할 수 있습니다.

원래의 문서는 Texinfo 파일입니다.HTML 판은, 변경되었다 texi2html (을)를 사용해 자동적으로 생성됩니다.plaintext판과 Info 판은,makeinfo (을)를 사용해 생성됩니다.PostScript 판은,texi2dvi (와)과 dvips (을)를 사용해 생성됩니다.PDF 판은,pdftex (을)를 사용해 생성됩니다.

메뉴얼내에서 정보를 찾아내는 것이 곤란한 경우는,http://www.mysql.com/doc/ 에 있는 검색 가능한 버젼을 시험해 보세요.

이 메뉴얼에의 추가나 수정에 관한 제안은, 메뉴얼 팀(<docs@mysql.com> )에 전송해 주세요.

이 메뉴얼은 당초,David Axmark (와)과 Michael (Monty) Widenius 에 의해서 집필되었습니다.현재는,Arjen Lentz ,Paul DuBois , 및 Stefan Hinz (으)로 구성된다 MySQL 메뉴얼 팀에 의해서 관리되고 있습니다.그 외 다수의 공헌자에 대해서는, 부록 C. 협력자 (을)를 참조해 주세요.

이 메뉴얼의 저작권(2003-2006 )(은)는, 스웨덴의 회사 MySQL AB 하지만 소유하고 있습니다. See 항1.4.2. 「MySQL 그리고 사용되고 있는 저작권과 라이센스」 .

1.1.1. 이 메뉴얼의 표기 규칙

이 메뉴얼은, 이하의 표기 규칙에 따라서 기재되어 있습니다.

  • constant

    고정폭폰트는, 커멘드의 이름이나 옵션,SQL 스테이트먼트, 데이타베이스명, 테이블명, 컬럼명,C 코드,Perl 코드, 및 환경 변수에 사용한다.례:``mysqladmin 의 동작을 확인하려면 ,--help 옵션을 지정해 호출한다.''

  • filename

    인용부호로 둘러싸인 고정폭폰트는, 파일명 및 패스명에 사용한다.례:`` 디스트리뷰션은,/usr/local/ 디렉토리하에 인스톨 된다.''

  • ‘c ＇

    인용부호로 둘러싸인 고정폭폰트는, 문자의 순서를 나타내는 경우에도 사용한다.례:`` 와일드 카드를 지정하려면 ,‘% ＇ 문자를 사용한다.''

  • italic

    이탤릭 폰트는, 이와 같이 강조하는 경우에 사용한다.

  • boldface

    굵은 글씨 폰트는, 겉(표)의 표제나 특히 강한 강조 (을)를 나타내는 경우에 사용한다.

특정의 프로그램으로부터 커멘드를 실행할 필요가 있는 것을 나타내는 경우, 커멘드의 전에 프로그램과 prompt를 기술합니다.예를 들어,shell> (은)는 로그인 쉘로부터 실행하는 커멘드를 나타내,mysql> 하 mysql 클라이언트 프로그램으로부터 실행하는 커멘드를 나타냅니다.

shell>
쉘 커멘드
mysql> mysql
커멘드

`` 쉘'' (은)는 커멘드 인터프리터입니다.Unix 그럼 통상,sh (이)나 csh 등의 프로그램입니다.Windows 그럼,Windows 콘솔로 통상 실행된다 command.com (이)나 cmd.exe 입니다.

쉘 커멘드는,Bourne 쉘 구문을 사용해 나타냅니다.csh 형식의 쉘을 사용하고 있는 경우는, 다소 다른 커멘드를 발행해야 하는 것이 있습니다.예를 들어, 환경 변수를 설정해, 커멘드를 실행하는 순서는,Bourne 쉘 구문에서는 다음과 같이 됩니다.

shell> VARNAME=value some_command

csh 또는 tcsh 의 경우는, 이 순서를 다음과 같이 실행합니다.

shell> setenv VARNAME value
shell> some_command

데이타베이스명, 테이블명, 및 컬럼명은 많은 경우, 커멘드에 대입할 필요가 있습니다.이러한 대입이 필요한 것을 나타내는 경우, 이 메뉴얼에서는 db_name ,tbl_name , 및 col_name (을)를 사용합니다.예를 들어, 다음과 같은 스테이트먼트가 있다고 합니다.

mysql> SELECT col_name FROM db_name.tbl_name;

이것은, 같은 스테이트먼트를 입력하는 경우, 데이타베이스명, 테이블명, 및 컬럼명을 스스로 지정하는 것을 의미합니다.예를 들어, 다음과 같이 됩니다.

mysql> SELECT author_name FROM biblio_db.author_list;

SQL 키워드는 대문자와 소문자를 구별하지 않기 때문에, 대문자로 기술되는 일도 소문자로 기술되기도 합니다.다만, 이 메뉴얼에서는 대문자를 사용합니다.

구문의 설명으로 생략 가능한 단어나 마디를 나타내는 경우, 모퉁이나 개(‘[ ＇ 및 ‘] ＇)(을)를 사용합니다.예를 들어, 다음의 스테이트먼트에서는,IF EXISTS (은)는 생략 가능합니다.

DROP TABLE [IF EXISTS] tbl_name

구문 요소가 복수의 선택 후보로 구성되는 경우, 그러한 후보를 종선(‘| ＇)(으)로 단락짓습니다.선택 후보의 어느쪽이든을 선택 할 수 있다 경우는, 다음과 같이, 그러한 후보를 모퉁이나 개(‘[ ＇ 및 ‘] ＇) 안에 열거합니다.

TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

선택 후보의 어느쪽이든을 선택 해야 한다 경우는, 다음과 같이, 그러한 후보를 안이나 개(‘{ ＇ 및 ‘} ＇) 안에 열거합니다.

{DESCRIBE | DESC} tbl_name {col_name | wild}


1.2. MySQL 데이타베이스 관리 시스템의 개요

MySQL (은)는 가장 잘 알려져 있다 오픈 소스 SQL 데이타베이스 관리 시스템으로,MySQL AB 에 의해서 개발, 제공, 서포트를 하고 있습니다.MySQL AB 하 MySQL 의 개발자에 의해서 창설된 영리 회사에서,MySQL 데이타베이스 관리 시스템에 관련하는 서비스를 제공하는 것으로 비즈니스를 구축하고 있습니다. See 항1.3. 「MySQL AB 의 개요」 .

MySQL 의 Web 사이트(http://www.mysql.com/ )에는,MySQL 소프트웨어와 MySQL AB 에 관한 최신 정보가 게재되고 있습니다.

  • MySQL (은)는 데이타베이스 관리 시스템이다.

    데이타베이스는, 구조화 된 데이터의 집합이다.데이타베이스에는, 간단한 쇼핑 리스트로부터 회화의 갤러리, 또는 사내 네트워크의 방대한 양의 정보 등, 다양한 것이 있다.컴퓨터 데이타베이스에 격납되고 있는 데이터에 대해서 추가, 액세스, 및 처리등을 실시하려면 ,MySQL 서버와 같은 데이타베이스 관리 시스템이 필요하다.컴퓨터는 대량의 데이터의 처리에 매우 우수하므로, 데이타베이스 관리 시스템은, 스탠드얼론의 유틸리티 또는 다른 어플리케이션의 일부로서 데이터 처리의 중심적인 역할을 완수한다.

  • MySQL (은)는 RDB 관리 시스템이다.

    RDB에서는,1 개가 큰 보관 영역에 모든 데이터가 격납되는 것이 아니라, 개별의 테이블에 데이터가 격납된다.이것에 의해, 속도와 유연성이 향상한다.``MySQL'' 의 SQL 하 ``Structured Query Language'' (을)를 나타낸다.SQL (은)는 데이타베이스에의 액세스에 사용되는 가장 일반적인 표준화 언어로,ANSI/ISO SQL 표준에 의해서 정의되고 있다(SQL 표준은 1986 년 이?~ 개발이 반복해져 복수의 버젼이 있다.이 메뉴얼에서는,``SQL-92'' 하 1992 해에 릴리스 된 표준,``SQL-99'' 하 1999 해에 릴리스 된 표준,``SQL:2003'' 하 2003 년반에 릴리스 예정의 표준을 나타낸다.``SQL 표준'' 그렇다고 하는 용어는, 임의의 시점에 있어서의 현행 버젼의 SQL 표준을 나타내는 경우에 사용한다).

  • MySQL 소프트웨어는 오픈 소스 이다.

    오픈 소스 (이)란, 누구나가 그 소프트웨어를 사용해, 변경할 수 있는 것을 의미한다.MySQL 소프트웨어는, 누구나가 무료로 인터넷으로부터 다운로드해, 사용할 수 있다.필요에 따라서, 원시 코드를 조사해 요구에 맞추어 변경할 수 있다.MySQL 소프트웨어에서는,GPL (GNU 일반 공중 이용 허락 계약서 (http://www.fsf.org/licenses/ ))에 근거하고, 다양한 상황으로의 소프트웨어의 사용에 대해 허가되고 있는 사항과 금?~ 되고 있는 사항이 규정되고 있다.GPL 그럼 무례한 경우나 상용 어플리케이션에 MySQL 코드를 짜넣을 필요가 있는 경우는, 상용 라이센스판을 구입할 수 있다. See 항1.4.3. 「MySQL 라이센스」 .

  • MySQL 데이터 베이스 서버를 사용하는 메리트

    MySQL 데이터 베이스 서버 (은)는, 매우 고속으로 신뢰성이 있어, 간단하게 사용할 수 있다.그것을 요구하고 있던 것이라면, 꼭 시험해 주셨으면 한다.또,MySQL 서버 에는, 유저와 밀접하게 협력해 개발된 실용적인 기능이 갖춰지고 있다.벤치마크 페이지로, 다른 데이타베이스 관리 시스템과 MySQL 서버 의 퍼포먼스를 비교할 수 있다. See 항5.1.4. 「MySQL 벤치마크스트」 .

    MySQL 서버 (은)는 당초, 기존의 솔루션보다 훨씬 빠르고 대규모 데이타베이스를 처리하는 것을 목적으로 해 개발되어 대부분을 요구되는 운용 환경에서 몇 년간에 걸쳐서 사용되고 있다.계속 개발을 하고 있지만,MySQL 서버 (은)는 현재, 편리하고 다채로운 기능을 갖추고 있다.그 접속성, 속도, 안전성에 의해서,MySQL 서버 (은)는 인터넷상의 데이타베이스에의 액세스에 매우 적합하다.

  • MySQL 서버의 기술적인 기능

    상세한 기술 정보에 대해서는, 장 6. MySQL SQL 언어 레퍼런스 (을)를 참조.MySQL 데이타베이스 소프트웨어 (은)는, 다양한 연구 최종 단계를 서포트하는 multi-thread 형식의 SQL 서버, 복수가 다른 클라이언트 프로그램 및 라이브러리, 관리툴, 폭넓은 아프리케이션프로그라?~ 그인타페스(API )(으)로부터 완성되는 클라이언트/ 서버 시스템이다.

    또,MySQL 서버 (은)는 어플리케이션에의 링크가 가능한 multi-thread 라이브러리로서 제공되고 있어 한층 더 소규모로 고속의, 관리하기 쉬운 제품을 만들어 낼 수 있다.

  • MySQL (을)를 서포트하는 다수의 소프트웨어

    필요한 어플리케이션이나 언어로 벌써 MySQL 데이터 베이스 서버 하지만 서포트되고 있다고 생각된다.

MySQL 의 정식적 발음은 ``My Ess Que Ell'' 그렇지만(``my sequel'' (이)가 아닙니다),``my sequel'' (이)라고 발음하거나 로컬라이즈 된 다른 방법으로 발음해도 괜찮습니다.

1.2.1. MySQL 의 역사

당초는, 고속으로 저레벨인 독자적인(ISAM ) 루틴을 사용해 테이블에 접속하기 위해서 mSQL (을)를 사용할 생각이었습니다.그러나, 몇개의 테스트를 실시한 결과,mSQL (은)는 그만큼 고속으로 도 유연하지도 않기 때문에, 요구에 맞지 않는다고 하는 결론에 이르렀습니다.이것이 요인이 되고, 우리의 데이타베이스에의 새롭다 SQL 인터페이스를 개발하게 되었습니다.다만,mSQL (와)과 거의 같다 API 인터페이스를 사용하기로 했습니다.이 API (을)를 선택한 것은,mSQL 그리고 사용하기 위해서 기술된 써드파티의 코드를 MySQL 그리고 사용하기 위해서 간단하게 이식할 수 있도록 하기 (위해)때문입니다.

MySQL (이)라는 이름의 유래는 분명하지는 않습니다.당사의 기본 디렉토리 및 다수의 라이브러리나 툴에는,10 연이상에 걸쳐서 ``my'' 그렇다고 하는 프리픽스가 사용되고 있습니다.또, 공동 창설자 Monty Widenius 의 딸(아가씨)의 이름도 My 입니다.그 때문에, 이 중의 어느 쪽이 MySQL 의 이름의 유래가 되었는지는, 우리에 있어서도 아직껏 수수께끼입니다.

MySQL 의 돌고래(당사의 로고)의 이름은 Sakila 입니다.Sakila (은)는, 당사의 「돌고래의 네?~ 그」콘테스트에서, 유저에 의해서 제안된 방대한 수의 이름중에서 MySQL AB 의 창설자가 선택한 것입니다.이 이름을 제안한 것은, 아프리카의 스와질란드 출신의 Ambrose Twebaze 그렇다고 하는 오픈 소스 소프트웨어의 개발자였습니다.Ambrose 에 의하면,Sakila (이)라는 이름은, 스와질란드의 현지어인 시스와티어에 루트가 있는 것입니다.또,Sakila (은)는,Ambrose 의 출생국인 우간다에 가까운, 탄자니아의 아르샤에 있는 마을의 이름이기도 합니다.

1.2.2. MySQL 의 주된 기능

MySQL 데이타베이스 소프트웨어 의 중요한 특징의 일부를 이하로 설명합니다. See 항1.5.1. 「MySQL 4.0 의 개요」 .

  • 내부 및 이식성

    • C 및 C++ 그리고 기술되고 있다.

    • 다양한 컴파일러로 테스트되고 있다.

    • 다양한 플랫폼에서 동작한다. See 항2.2.3. 「MySQL 하지만 서포트하고 있는 operating system」 .

    • 이식성을 위해서 GNU Automake ,Autoconf , 및 Libtool (을)를 사용하고 있다.

    • C ,C++ ,Eiffel ,Java ,Perl ,PHP ,Python ,Ruby , 및 Tcl 의 API 하지만 사용 가능하다. See 장 11. MySQL API .

    • 카네르스레드를 사용한 완전한 multi-thread.그 때문에, 사용 가능한 경우, 복수의 CPU (을)를 간단하게 사용할 수 있다.

    • 트랜잭션(transaction) 스토리지 엔진과 비트랜잭션(transaction) 스토리지 엔진을 갖추고 있다.

    • 인덱스 압축을 갖춘 매우 고속의 B-tree 디스크 테이블(MyISAM )(을)를 사용하고 있다.

    • 다른 스토리지 엔진의 추가가 비교적 용이하다.이것은, 사내 데이타베이스에의 SQL 인터페이스를 추가하는 경우에 편리하다.

    • 스레드베이스의 매우 고속의 메모리 할당 시스템.

    • 최적화되었다 one-sweep multi-join (을)를 사용한 매우 신속한 결합.

    • 텐포라리테이불로서 사용되는 메모리내 해시 테이블.

    • 고도로 최적화된 클래스 라이브러리로부터 SQL 함수가 실장되기 위해, 최대한의 속도가 확보된다.통상은, 쿼리의 초기화 후에 메모리 할당을 할 것은 없다.

    • MySQL 코드는 Purify (시판의 메모리 리크 검출 시스템)(와)과 Valgrind (으)로 불린다 GPL 툴(http://developer.kde.org/~sewardj/ )(을)를 사용해 테스트되고 있다.

    • 클라이언트/ 서버 또는 짜넣어(링크) 버젼으로서 사용 가능하다.

  • 컬럼형

    • 다수의 컬럼형: 1 ,2 ,3 ,4 , 및 8 아르바이트장의 부호 첨부/ 부호 없음 정수,FLOAT ,DOUBLE ,CHAR ,VARCHAR ,TEXT ,BLOB ,DATE ,TIME ,DATETIME ,TIMESTAMP ,YEAR ,SET , 및 ENUM 형. See 항6.2. 「컬럼형」 .

    • 고정장 및 가변장의 레코드.

  • 커멘드와 함수

    • 쿼리의 SELECT 마디 및 WHERE 마디로의 연산자와 함수의 완전한 서포트.예를 들어, 다음과 같이 사용할 수 있다.

      mysql> SELECT CONCAT(first_name, " ", last_name)
    -> FROM tbl_name
    -> WHERE income/dependents > 10000 AND age > 30;

    • SQL 의 GROUP BY 마디 및 ORDER BY 마디의 완전한 서포트.그룹 함수(COUNT() ,COUNT(DISTINCT ...) ,AVG() ,STD() ,SUM() ,MAX() ,MIN() , 및 GROUP_CONCAT() )의 서포트.

    • 표준의 SQL 구문 및 ODBC 구문으로의 LEFT OUTER JOIN 및 RIGHT OUTER JOIN 의 서포트.

    • SQL-92 그리고 필요한, 테이블 및 컬럼에 있어서의 앨리어스(alias)의 서포트.

    • DELETE ,INSERT ,REPLACE , 및 UPDATE (은)는, 변경된(영향을 받은) 레코드의 수를 돌려준다.서버에 접속할 때에 플래그를 설정하는 것으로, 대신에 일치한 레코드의 수를 돌려주는 것도 가능하다.

    • MySQL 고유의 SHOW 커멘드를 사용하면, 데이타베이스, 테이블, 및 인덱스에 관한 정보를 취득할 수 있다.EXPLAIN 커멘드를 사용하면, Optimizer에 의한 쿼리의 해결 방법을 결정할 수 있다.

    • 함수명은, 테이블명이나 컬럼명으로 충돌하지 않는다.예를 들어,ABS (은)는 유효한 컬럼명이다.함수 호출로, 함수명과 그 후에 계속 된다 ‘( ＇ (와)과의 사이에 스페이스를 사용할 수 없는 점이 유일한 제한 사항이다. See 항6.1.7. 「MySQL (으)로의 예약어(reserved word)의 취급」 .

    • 동일한 쿼리에 다양한 데이타베이스내의 테이블을 혼재시킬 수 있다(버젼 3.22 이?~ ).

  • 시큐러티

    • 매우 유연하고 안전한 특권 및 패스워드 시스템.호스트 베이스의 검증이 가능하다.서버에 접속할 때에 모든 패스워드 트래픽이 암호화되므로, 패스워드는 안전하다.

  • 확장성과 범위

    • 대규모 데이타베이스를 처리한다.당사는,MySQL 서버 (을)를 사용해 50,000,000 레코드가 격납된 데이타베이스를 처리하고 있다.또,MySQL 서버 (을)를 사용해 60,000 테이블, 약 5,000,000,000 레코드를 처리하고 있는 유저도 있다.

    • 각 테이블로 최고 32 개의 인덱스가 사용 가능하다.각 인덱스는,1 (으)로부터 16 개의 컬럼 또는 컬럼의 일부에서 구성된다.인덱스의 최대폭은 500 아르바이트이다(이것은,MySQL 서버 의 컴파일시로 변경 가능하다).인덱스에서는,CHAR 형태 또는 VARCHAR 형태의 컬럼의 프리픽스를 사용할 수 있다.

  • 접속성

    • 클라이언트는, 모든 플랫폼에서 TCP/IP 소켓을 사용해 MySQL 서버에 접속할 수 있다.NT 파?~ 리(NT ,2000 , 또는 XP ) 의 Windows 시스템에서는, 클라이언트는 이름 파이프를 사용해 접속할 수 있다.Unix 시스템에서는,Unix 도메인 소켓 파일을 사용해 접속할 수 있다.

    • Connector/ODBC 인터페이스에 의해서,ODBC (Open-DataBase-Connectivity ) 접속을 사용하는 클라이언트 프로그램에 MySQL 서포트가 제공된다.예를 들어,MS Access (을)를 사용해 MySQL 서버에 접속할 수 있다.클라이언트는,Windows (와)과 Unix 의 어디에서 실행되고 있어도 상관없다.Connector/ODBC 소스가 사용 가능하다.다른 많은 기능과 같게,ODBC 2.5 의 모든 기능이 서포트된다. See 항11.2. 「MySQL 의 ODBC 서포트」 .

  • 로컬라이즈

    • 서버로부터 클라이언트에 다수의 언어로 에러 메세지를 송신할 수 있다. See 항4.7.2. 「영어 이외의 에러 메세지」 .

    • ISO-8859-1 (Latin1 ),german ,big5 ,ujis 등이 다양한 캐릭터 세트의 완전한 서포트.예를 들어, Scandinavia어의 문자 ‘â ＇,‘ä ＇, 및 ‘ö ＇ (을)를 테이블명이나 컬럼명으로 사용할 수 있다.

    • 모든 데이터가, 선택한 캐릭터 세트로 보존된다.통상의 문자열 컬럼의 비교는 모두, 대문자와 소문자를 구별하지 않는다.

    • 소트는, 선택한 캐릭터 세트에 근거해 행해진다(디폴트는 스웨덴어에 의한 소트).이것은,MySQL 서버의 기동시로 변경할 수 있다.매우 고도의 소트의 예에 대해서는, 체코어의 소트 코드를 참조.MySQL 서버 그럼 다양한 캐릭터 세트가 서포트되고 있어 컴파일시 및 실행시로 지정할 수 있다.

  • 클라이언트와 툴

    • MySQL 서버에는, 테이블의 체크, 최적화, 및 수복을 실시한다 SQL 스테이트먼트의 서포트가 짜넣어지고 있다.이러한 스테이트먼트는,mysqlcheck 클라이언트를 개입시켜 커멘드 라인으로부터 사용 가능하다.또,MySQL 에는,MyISAM 테이블로 이러한 조작을 실행하기 위한 myisamchk 그렇다고 하는 매우 고속의 커멘드 라인 유틸리티가 짜넣어지고 있다. See 장 4. 데이타베이스 관리 .

    • --help 또는 -? 옵션을 지정해 호출하면, 모든 MySQL 프로그램으로 on-line help를 참조할 수 있다.

1.2.3. MySQL 의 안정성

이 섹션에서는,``MySQL 서버의 안정성'' (와)과 `` 프로젝트에 있어서의 MySQL 서버의 신뢰성'' 그렇다고 하는 문제를 취급합니다.이러한 문제를 분명히 해, 다수의 잠재 유저에게 관련하는 중요한 질문에 답합니다.이 섹션에 기재되어 있는 정보는, 문제의 특정이나 사용 방법의 보고가 매우 활발하게 행해지고 있는 메일링 리스트로부터 수집한 데이터에 근거하고 있습니다.

원래의 코드는 1980 연대 초기에 기술된 것으로, 안정된 코드 베이스가 되고 있습니다.또,ISAM 테이블 형식에는 하위 호환성이 유지되고 있습니다.MySQL AB 의 전신이다 TcX 그럼,1996 년반이래,MySQL 코드는 프로젝트로 문제 없게 동작하고 있었습니다.MySQL 데이타베이스 소프트웨어 하지만 보다 넓고 일반적으로 릴리스 되자마자, 새로운 유저가 `` 테스트되어 있지 않은 코드'' (을)를 몇개인가 찾아냈습니다.그것이?~ 의 새로운 릴리스 마다, 이식성에 관한 문제는 적게 되고 있습니다(또 한편에서는, 새로운 릴리스 마다 다수의 신기능이 추가되고 있습니다).

MySQL 서버 의 각 릴리스는 항상 실용적입니다.문제가 발생하는 것은, 유저가 `` 그레이 존'' 의 코드를 사용하려고 했을 때 뿐입니다.무엇보다, 새로운 유저는 그레이 존이란 무엇인가를 모릅니다.그 때문에, 이 섹션에서는, 현시점에서 인식되고 있는 그 영역을 설명합니다.설명은 주로,MySQL 서버 의 버젼 3.23 및 4.0 (을)를 대상으로 합니다.최신 버젼에서는, 버그 섹션에 기재되어 있는 설계 관련의 버그를 제외해, 보고되고 있는 기존의 버그는 모두 수정되고 있습니다. See 항1.8.6. 「MySQL 의 기존의 에러와 설계상의 문제」 .

MySQL 서버 (은)는, 복수층의 독립한 모듈로 구성되어 있습니다.새로운 모듈의 일부와 그러한 테스트 스테이터스를 이하에 나타냅니다.

  • replication --- 감마

    replication에 의한 대규모 서버 그룹이 운용되고 있어 양호한 결과를 얻고 있다.MySQL 4.x 그럼, 확장된 replication 기능에 대한 대처가 계속해 행해지고 있다.

  • InnoDB 테이블 --- 안정(3.23.49 이?~ 의 3.23 )

    InnoDB 트랜잭션(transaction) 스토리지 엔진은,MySQL 3.23 트리의 버젼 3.23.49 이?~ 그리고 안정되어 있다고 선언되고 있다.InnoDB (은)는, 대규모이고 부하가 높은 운용 시스템으로 사용되고 있다.

  • BDB 테이블 --- 감마

    Berkeley DB 코드는 매우 안정되어 있지만,MySQL 서버 그럼 계속 BDB 트랜잭션(transaction) 스토리지 엔진 인터페이스의 개량을 실시하고 있다.그 때문에, 다른 테이블형과 같이 충분히 테스트되려면 당분간 시간이 필요하다.

  • 풀텍스트 검색 --- 베타

    풀텍스트 검색은 동작하지만, 아직 광범위하게는 사용되어 있지 않다.MySQL 4.0 에는, 중요한 확장 기능이 실장되고 있다.

  • MyODBC 3.51 (ODBC SDK 3.51 (을)를 사용) --- 안정

    넓게 운용되고 있다.ODBC 드라이버나 기반이 되고 있는 데이터 베이스 서버와는 무관계의, 어플리케이션에 관련하고 있다고 생각되는 문제가 발생하고 있다.

  • MyISAM 테이블의 자동 리커버리 --- 감마

    이 스테이터스는,MyISAM 스토리지 엔진의 새로운 코드에만 해당한다.이 코드에서는, 테이블을 열 때에, 전에 그 테이블이 올바르게 닫혀졌는지가 체크되어 올바르게 닫혀지지 않은 경우는 테이블의 자동 체크/ 수복이 실행된다.

  • 일괄 삽입 --- 알파

    다수의 레코드를 보다 빠르게 삽입하기 위한 MySQL 4.0 에 있어서의 MyISAM 테이블의 신기능이다.

  • 락 --- 감마

    이것은 시스템 의존이다.일부의 시스템에서는, operating system 표준의 락(fcntl() )(을)를 사용하는 것에 큰 문제가 있다.이러한 경우,--skip-external-locking 플래그를 지정해 mysqld (을)를 실행할 필요가 있다.문제는, 일부의 Linux 시스템과NFS 에 의해서 마운트된 파일 시스템 사용시의 SunOS 그리고 발생하는 것이 확인되고 있다.

MySQL AB 그럼, 고품질의 서포트를 유료로 고객에게 제공하고 있습니다.또, 누구나가 질문할 수 있는 코?~ 니티리소스로서 MySQL 메일링 리스트를 제공하고 있습니다.

버그는 통상, 패치에 의해서 시급히 수정됩니다.중대한 버그에 대해서는, 대부분의 경우, 새로운 릴리스가 제공됩니다.

1.2.4. MySQL 테이블의 최대 사이즈

MySQL 버젼 3.22 그럼, 테이블의 사이즈는 4 GB (4 기가바이트)에 제한되고 있었습니다.MySQL 버젼 3.23 의 MyISAM 테이블형에서는, 테이블의 최대 사이즈가 800 만테라바이트(2^63 아르바이트)에 증가했습니다.유효한 테이블의 사이즈가 이와 같이 커진 것으로, 현재는,MySQL 데이타베이스에 효과적인 테이블의 최대 사이즈는 통상,MySQL 내부의 제한이 아니고, operating system의 파일 사이즈에 관한 제한에 의해서 정해집니다.

다음의 겉(표)는, operating system의 파일 사이즈에 관한 제한의 예를 나타내고 있습니다.

operating system | 파일 사이즈의 제한
Linux-Intel 32-bit | 2 GB ,LFS 사용의 경우는 그 이상
Linux-Alpha | 8 TB (? )
Solaris 2.5.1 | 2 GB (패치에 의해 4GB 까지 가능)
Solaris 2.6 | 4 GB (플래그에 의해 변경 가능)
Solaris 2.7 Intel | 4 GB
Solaris 2.7 UltraSPARC | 512 GB

Linux 2.2 그럼,ext2 파일 시스템용의 LFS 패치를 사용하는 것으로,2 GB 보다 큰 사이즈의 테이블을 사용할 수 있습니다.또,Linux 2.4 에는 ReiserFS 및 ext3 하지만 짜넣어지고 있어 이것들을 사용하는 것으로 큰 파일이 서포트됩니다.현재의 Linux 디스트리뷰션의 대부분은 커넬 2.4 에 근거하고 있어 필요한 Large File Support (LFS ) 패치 모든 것이 벌써 짜넣어지고 있습니다.그러나, 그런데도, 유효한 최대 파일 사이즈는 몇개의 요인에 의해서 좌우됩니다.그 중의 1 개가,MySQL 테이블을 격납하기 위해서 사용되는 파일 시스템입니다.

Linux 에 있어서의 LFS 의 상세한 것에 대하여는,Andreas Jaeger 의 「Large File Support in Linux 」(http://www.suse.de/~aj/linux_lfs.html )(을)를 참조해 주세요.

디폴트에서는,MySQL 그럼 유효한 최대 사이즈가 약 4 GB 의 내부 구조를 가진다 MyISAM 테이블이 작성됩니다.SHOW TABLE STATUS 커멘드 또는 myisamchk -dv table_name (을)를 사용하고, 테이블의 최대 사이즈를 체크할 수 있습니다. See 항4.6.8. 「SHOW 구문」 .

4 GB 보다 큰 사이즈의 테이블이 필요한 경우( operating system로 대규모 파일이 서포트되고 있으면),CREATE TABLE 스테이트먼트로 AVG_ROW_LENGTH 및 MAX_ROWS 옵션을 지정할 수 있습니다.4 GB (을)를 넘는 테이블을 작성하려면 , 이러한 옵션을 사용해 주세요.See 항6.5.3. 「CREATE TABLE 구문」 .또,ALTER TABLE (을)를 사용하고, 다음에 이러한 옵션을 설정할 수도 있습니다. See 항6.5.4. 「ALTER TABLE 구문」 .

MyISAM 테이블의 파일 사이즈에 관한 제한으로 대처하는 방법으로서 그 밖에 다음과 같은 방법이 있습니다.

  • 읽기 전용의 대규모 테이블의 경우,myisampack (을)를 사용해 테이블을 압축할 수 있다.myisampack 그럼 통상, 테이블이 적어도 50% 압축되므로, 결과적으로 훨씬 큰 테이블을 사용하는 것이 가능하다.또,myisampack (을)를 사용하고, 복수의 테이블을 1 개의 테이블에 머지 할 수도 있다. See 항4.8.4. 「myisampack (MySQL 압축 독해 전용 테이블 제네레이터)」 .

  • 또,MyISAM 데이터 파일에 관한 operating system의 파일 제한으로 대처하는 방법으로서RAID 옵션을 사용할 수도 있다. See 항6.5.3. 「CREATE TABLE 구문」 .

  • MySQL 에 짜넣어지고 있다 MERGE 라이브러리를 사용하고, 동일한 테이블의 집합을 1 개의 테이블로서 처리할 수도 있다.See 항7.2. 「MERGE 테이블」 .

1.2.5. 서기 2000 해대응

MySQL 서버 자체는, 서기 2000 해(Y2K ) 대응에 관해서는 아무 문제도 없습니다.

  • MySQL 서버 그럼,TIMESTAMP 값에 대해서는 일자를 2037 해에 처리한다 Unix 시간 함수를 사용한다.DATE 값 및 DATETIME 값에 대해서는,9999 해까지의 일자가 사용 가능하다.

  • MySQL 일자 함수 모든 것이 1 개의 파일 sql/time.cc 에 격납되어 서기 2000 해에 대응하듯이 매우 신중하게 코드화 되고 있다.

  • MySQL 버젼 3.22 이?~ 그럼,YEAR 형태의 컬럼에 0 해 및 1901 해부터 2155 해까지의 해를 1 아르바이트로 격납해,2 자리수 또는 4 자리수로 표시할 수 있다.2 자리수의 해는 모두,1970 해부터 2069 해까지의 범위에 있다고 보여진다.즉,YEAR 형태의 컬럼에 01 (을)를 격납했을 경우,MySQL 서버 그럼 2001 (으)로서 처리된다.

다음의 간단한 예로,MySQL 서버 에 2030 해까지의 일자에 관한 문제가 없는 것을 나타내 보입니다.

mysql> DROP TABLE IF EXISTS y2k;
Query OK, 0 rows affected (0.01 sec)

mysql> CREATE TABLE y2k (date DATE,
    ->                   date_time DATETIME,
    ->                   time_stamp TIMESTAMP);
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO y2k VALUES
    -> ("1998-12-31","1998-12-31 23:59:59",19981231235959),
    -> ("1999-01-01","1999-01-01 00:00:00",19990101000000),
    -> ("1999-09-09","1999-09-09 23:59:59",19990909235959),
    -> ("2000-01-01","2000-01-01 00:00:00",20000101000000),
    -> ("2000-02-28","2000-02-28 00:00:00",20000228000000),
    -> ("2000-02-29","2000-02-29 00:00:00",20000229000000),
    -> ("2000-03-01","2000-03-01 00:00:00",20000301000000),
    -> ("2000-12-31","2000-12-31 23:59:59",20001231235959),
    -> ("2001-01-01","2001-01-01 00:00:00",20010101000000),
    -> ("2004-12-31","2004-12-31 23:59:59",20041231235959),
    -> ("2005-01-01","2005-01-01 00:00:00",20050101000000),
    -> ("2030-01-01","2030-01-01 00:00:00",20300101000000),
    -> ("2050-01-01","2050-01-01 00:00:00",20500101000000);
Query OK, 13 rows affected (0.01 sec)
Records: 13  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM y2k;
+------------+---------------------+----------------+
| date       | date_time           | time_stamp     |
+------------+---------------------+----------------+
| 1998-12-31 | 1998-12-31 23:59:59 | 19981231235959 |
| 1999-01-01 | 1999-01-01 00:00:00 | 19990101000000 |
| 1999-09-09 | 1999-09-09 23:59:59 | 19990909235959 |
| 2000-01-01 | 2000-01-01 00:00:00 | 20000101000000 |
| 2000-02-28 | 2000-02-28 00:00:00 | 20000228000000 |
| 2000-02-29 | 2000-02-29 00:00:00 | 20000229000000 |
| 2000-03-01 | 2000-03-01 00:00:00 | 20000301000000 |
| 2000-12-31 | 2000-12-31 23:59:59 | 20001231235959 |
| 2001-01-01 | 2001-01-01 00:00:00 | 20010101000000 |
| 2004-12-31 | 2004-12-31 23:59:59 | 20041231235959 |
| 2005-01-01 | 2005-01-01 00:00:00 | 20050101000000 |
| 2030-01-01 | 2030-01-01 00:00:00 | 20300101000000 |
| 2050-01-01 | 2050-01-01 00:00:00 | 00000000000000 |
+------------+---------------------+----------------+
13 rows in set (0.00 sec)

TIMESTAMP 형태의 컬럼의 마지막 값이 제로가 되어 있는 것은, 마지막 해(2050 )(이)가 TIMESTAMP 의 상한을 넘고 있기 (위해)때문입니다.TIMESTAMP 데이터형은 현재의 시각을 격납하기 위해서 사용되어32 비트 머신에서는 19700101000000 (으)로부터 20300101000000 까지의 값(부호 첨부의 값)을 서포트합니다.64 비트 머신에서는,2106 까지의 값(부호 없음의 값)을 처리합니다.

이 예는,DATE 및 DATETIME 데이터형에도 일자의 사용에 관한 문제가 없는 것을 나타내 보이고 있습니다.이러한 데이터형에서는,9999 해까지의 일자가 처리됩니다.

MySQL 서버 자체는 Y2K 에 대응하고 있습니다만,Y2K 에 대응하고 있지 않는 어플리케이션과 함께 사용하면, 문제가 발생하는 일이 있습니다.예를 들어, 많은 낡은 어플리케이션에서는,4 자리수의 값이 아니고, 애매한 2 자리수의 값을 사용해 해의 격납이나 처리를 합니다.이 문제는, 값이 `` 없다'' 일을 나타내는 경우에 00 (이)나 99 등의 값을 사용하는 어플리케이션에서는, 한층 더 복잡하게 될 가능성이 있습니다.각각의 어플리케이션은 다양한 프로그래머에 의해서 기술되고 있어 프로그래머 마다 다른 규칙이나 일자 처리 함수를 사용하고 있을 가능성이 있으므로, 이러한 문제를 수정하는 것은 곤란한 경우가 있습니다.

그 때문에,MySQL 서버 에 Y2K 문제가 없어도, 어플리케이션으로서 애매하지 않은 정보를 제공하는 것이 필요합니다.해를 나타낸다 2 자리수의 값을 포함한 애매한 일자 입력 데이터의 처리에 관한 MySQL 서버 의 룰에 대해서는, 항6.2.2.1. 「서기 2000 해문제와 일자형」 (을)를 참조해 주세요.


1.3. MySQL AB 의 개요

MySQL AB 하 MySQL 의 창시자와 주된 개발자의 회사에서, 처음은 David Axmark ,Allan Larsson , 및 Michael ``Monty'' Widenius 에 의해서 스웨덴에 창설되었습니다.

MySQL 서버의 개발자는 모두, 당사의 종업원입니다.당사는, 온 세상의 다수의 나라의 사람들로부터 완성되는 가상 조직입니다.매일 넷을 사용해 서로, 또는 유저, 서포터, 및 파트나와 넓고 코?~ 니케이션을 도모하고 있습니다.

당사는,MySQL 소프트웨어의 개발과 새로운 유저에게의 당사의 데이타베이스의 보급에 전념하고 있습니다.MySQL AB (은)는,MySQL 의 원시 코드,MySQL 의 로고와 상표, 및 이 메뉴얼의 저작권을 소유하고 있습니다. See 항1.2. 「MySQL 데이타베이스 관리 시스템의 개요」 .

MySQL 의 본질적 가치가,MySQL 및 오픈 소스 에의 당사의 헌신을 나타내고 있습니다.

당사는,MySQL 데이타베이스 소프트웨어 하지만 다음과 같은 것임을 바라고 있습니다.

  • 온 세상에서 가장 넓게 사용되는, 세계 최고의 데이타베이스이다.

  • 누구나가 입수할 수 있어 가격이 적당하다.

  • 사용하기 쉽다.

  • 속도와 안전성을 확보하면서, 개량을 계속한다.

  • 즐겁게 사용 및 개량할 수 있다.

  • 버그가 없다.

MySQL AB (와)과 MySQL AB 의 종업원은, 이하를 유의하고 있습니다.

  • 오픈 소스 의 이념을 추진해, 오픈 소스 코?~ 니티를 서포트한다.

  • 건전한 멤버이다.

  • 당사의 가치관과 생각을 공유하는 파트나를 우선한다.

  • 전자 메일에 회답해, 서포트를 제공한다.

  • 다른 사람과 네트워크로 연결해진 가상 기업이다.

  • 소프트웨어의 특허권에 반대하는 입장을 취한다.

MySQL 의 Web 사이트(http://www.mysql.com/ )에는,MySQL (와)과 MySQL AB 에 관한 최신 정보가 게재되고 있습니다.

회사명의 ``AB'' 의 부분은, 스웨덴어의 ``aktiebolag'' , 즉 `` 주식회사'' 의 두자어입니다.따라서,``MySQL 주식회사'' 그렇다고 하는 의미입니다.실제,MySQL AB 의 자회사로서MySQL Inc. (이)나 MySQL GmbH 등이 있습니다.이러한 자회사는 각각, 미국과 독일에 있습니다.

1.3.1. MySQL AB 의 비즈니스 모델과 서비스

당사에 가장 잘 전해지는 질문의 1 개가 `` 제품을 무상으로 제공해 어떻게 채산을 취하고 있습니까?'' (이)라는 것입니다.이것에 대한 회답은 다음과 같습니다.

MySQL AB (은)는, 서포트, 서비스, 상용 라이센스, 및 로열티로 이익을 올리고 있습니다.당사에서는, 이러한 수익을 제품 개발이나 MySQL 비즈니스의 확대에 충당하고 있습니다.

당사는, 창설 이래, 항상 이익을 올리고 있습니다.2001 년 10 달에는, 대표적인 북유럽의 투자가와 몇명의 자금 원조자로부터 사업 투자를 받았습니다.이 투자는, 당사의 비즈니스 모델을 굳혀 계속적인 성장의 기반을 확립하기 위해서 사용되고 있습니다.

1.3.1.1. 서포트

MySQL AB (은)는,MySQL 데이타베이스의 창시자와 주된 개발자가 소유해, 경영하고 있습니다.개발자는, 고객이나 그 외의 유저의 요구나 문제를 항상 파악해 두기 위해서, 서포트의 제공에 임하고 있습니다.당사의 서포트는 모두, 경험 풍부한 개발자에 의해서 제공됩니다.실제, 어려운 질문에는,MySQL 서버 의 가장 중요한 작성자이다 Michael Monty Widenius 하지만 회답합니다. See 항1.4.1. 「MySQL AB 에 의해서 제공되는 서포트」 .

상세와 다양한 레벨의 서포트의 신청에 대해서는,http://www.mysql.com/support/ (을)를 참조하는지, 당사의 판매 스탭(<sales@mysql.com> )에 문의해 주세요.

1.3.1.2. 트레이닝과 검정

MySQL AB (은)는,MySQL 관련의 트레이닝을 온 세상에서 실시하고 있습니다.당사에서는, 개방된 코스와 기업 고유의 요구에 맞춘 사내 트레이닝용 코스의 양쪽 모두를 준비하고 있습니다.또, 당사의 파트나이다 MySQL 인정 트레이닝 센터 에 의한다 MySQL 트레이닝 도 있습니다.

당사의 트레이닝 교재에는, 당사의 메뉴얼로 사용되고 있는 것과 같은 샘플 데이타베이스나 샘플 어플리케이션이 사용되고 있습니다.또, 교재는 최신판의 MySQL (을)를 반영하듯이 항상 갱신되고 있습니다.게다가 당사의 강사는 개발 팀에 의해서 서포트되고 있기 때문에, 트레이닝의 질과 코스 교재의 계속적인 개발을 보증하겠습니다.또, 트레이닝중에 발생한 질문에는 반드시 대답합니다.

트레이닝 코스에 참가하는 것으로,MySQL 어플리케이션의 목표를 달성할 수 있습니다.게다가 이하를 실현될 수 있습니다.

  • 시간을 절약한다.

  • 어플리케이션의 퍼포먼스를 향상시킨다.

  • 여분의 하드웨어의 필요성을 저감 또는 배제하고, 코스트를 삭감한다.

  • 시큐러티를 강화한다.

  • 고객 및 동료의 만족도를 향상시킨다.

  • MySQL 검정 의 준비를 한다.

수강자로서 또는 트레이닝파트나로서 당사의 트레이닝에 관심을 가지고 계신 분은, 트레이닝 섹션(http://www.mysql.com/training/ )(을)를 참조하는지, 당사(<training@mysql.com> )에 문의해 주세요.

MySQL 검정 프로그램 의 상세한 것에 대하여는,http://www.mysql.com/certification/ (을)를 참조해 주세요.

1.3.1.3. 컨설팅

MySQL AB (와)과 그 인정 파트나 (은)는, 온 세상의 MySQL 서버 유저 및 독자적인 소프트웨어에 MySQL 서버 (을)를 짜넣는 유저에게 컨설팅 서비스를 제공하고 있습니다.

당사의 컨설턴트는, 데이타베이스의 설계와 조정, 효율적인 쿼리의 작성, 최적인 퍼포먼스를 확보하기 위한 플랫폼의 조정, 이행에 관한 문제의 해결, replication의 설정, 견뢰한 트랜잭션(transaction) 어플리케이션의 구축등을 돕겠습니다.또, 대규모 전개를 목적으로 하고, 독자적인 제품이나 어플리케이션에 MySQL 서버 (을)를 짜넣는 고객의 도움도 하겠습니다.

당사의 컨설턴트는, 개발 팀과 밀접하게 협력하고 있습니다.그 때문에, 전문적인 서비스의 기술적인 품질을 보증하겠습니다.컨설팅은,2 일간의 파워 스타트 세션으로부터, 몇주간, 몇개월에도 건너는 프로젝트까지 다양합니다.당사의 전문가는,MySQL 서버 만을 취급하는 것은 아닙니다.PHP (이)나 Perl 등의 프로그라?~ 그 언어 및 스크립트 언어에 대해서도 대응합니다.

컨설팅 서비스 및 콘사르팅파트나에 관심을 가지고 계신 분은, 당사의 Web 사이트의 컨설팅 섹션(http://www.mysql.com/consulting/ )(을)를 참조하는지, 컨설팅 스탭(<consulting@mysql.com> )에 문의해 주세요.

1.3.1.4. 상용 라이센스

MySQL 데이타베이스는,GNU 일반 공중 이용 허락 계약서 (GPL )에 근거해 릴리스 되고 있습니다.즉,MySQL 소프트웨어는,GPL 의 아래, 무상으로 사용할 수 있습니다.다만,GPL 의 조건(어플리케이션도 GPL 에 근거하지 않으면 안 된다고 하는 요건등)에 구속되고 싶지 않은 경우는,MySQL AB (으)로부터 같은 제품의 상용 라이센스를 구입할 수 있습니다.http://www.mysql.com/products/pricing.html (을)를 참조해 주세요.MySQL AB 하 MySQL 의 원시 코드의 저작권을 소유하고 있으므로, 듀얼 라이센스 (을)를 채용하고,GPL 및 상용 라이센스아래에서 같은 제품을 제공할 수 있습니다.이것에 의해, 오픈 소스 에의 MySQL AB 의 대처에 영향이 생길 것은 없습니다.상용 라이센스가 필요한 경우의 상세한 것에 대하여는, 항1.4.3. 「MySQL 라이센스」 (을)를 참조해 주세요.

당사는,MySQL 서버 에 가치를 추가하는 써드파티의 오픈 소스 GPL 소프트웨어의 상용 라이센스도 판매하고 있습니다.알기 쉬운 예로서ACID 서포트, 행 레벨의 락, 크래쉬 리커버리,마르치바죠닝, 외부 키 서포트등을 제공한다 InnoDB 트랜잭션(transaction) 스토리지 엔진이 있습니다. See 항7.5. 「InnoDB 테이블」 .

1.3.1.5. 파트나 제휴

MySQL AB 에는, 트레이닝 코스, 컨설팅과 서포트, 출판,MySQL 및 관련 제품의 재판과 제공을 취급하는 세계적인 파트나프로그람이 있습니다.MySQL AB 파트나 하 Web 사이트(http://www.mysql.com/ )에서 공개되는 것과 동시에, 개개의 제품을 구별해, 비즈니스를 촉진하기 위해서 특수한 버젼의 MySQL 의 상표를 사용할 권리를 얻을 수 있습니다.

MySQL AB 파트나 에 관심을 가지고 계신 분은,<partner@mysql.com> 에 전자 메일을 전송해 주세요.

MySQL 라는 말과 MySQL 의 돌고래의 로고는,MySQL AB 의 상표입니다.See 항1.4.4. 「MySQL AB 의 로고와 상표」 .이러한 상표는,MySQL 의 창시자가 몇 년에 걸쳐 쌓아 올려 온 의의 깊은 가치를 나타내고 있습니다.

MySQL 의 Web 사이트(http://www.mysql.com/ )(은)는, 개발자나 유저에게 잘 알려져 있습니다.2001 년 10 달에는,1,000 만회의 페이지 액세스가 있었습니다.당사의 Web 사이트로의 방문자는, 소프트웨어와 하드웨어의 양쪽 모두에 대해 구입의 결정과 추천을 실시하는 그룹입니다.방문자의 12% 하지만 정식으로 구입을 결정해, 구입의 결정에 전혀 관련하지 않는 것은 불과 9% 입니다.65% (을)를 넘는 방문자가 과거 반년 이내에 1 건이상의 온라인 거래를 실시했던 적이 있어,70% 의 방문자는 그 후수개월 안에 거래를 예정하고 있습니다.

1.3.2. 문의처

MySQL 의 Web 사이트(http://www.mysql.com/ )에는,MySQL (와)과 MySQL AB 에 관한 최신 정보가 게재되고 있습니다.

당사의 뉴스 릴리스(http://www.mysql.com/news/ )에 게재되어 있지 않은 프레스 관련의 서비스나 질문에 대해서는,<press@mysql.com> 에 전자 메일을 전송해 주세요.

MySQL AB (와)과 유효한 서포트 계약을 맺고 있는 분은,MySQL 소프트웨어에 관한 기술적인 질문에 대한 명확한 회답을 시기적절하게 얻을 수 있습니다.상세한 것에 대하여는, 항1.4.1. 「MySQL AB 에 의해서 제공되는 서포트」 (을)를 참조해 주세요.또는,Web 사이트의 http://www.mysql.com/support/ (을)를 참조하는지,<sales@mysql.com> 에 전자 메일을 전송해 주세요.

MySQL 트레이닝에 대해서는, 트레이닝 섹션(http://www.mysql.com/training/ )(을)를 참조해 주세요.인터넷에 액세스 할 수 없는 경우는,MySQL AB 의 트레이닝 스탭(<training@mysql.com> )에 전자 메일로 문의해 주세요. See 항1.3.1.2. 「트레이닝과 검정」 .

MySQL 검정 프로그램 에 대해서는,http://www.mysql.com/certification/ (을)를 참조해 주세요. See 항1.3.1.2. 「트레이닝과 검정」 .

컨설팅에 관심을 가지고 계신 분은,Web 사이트의 컨설팅 섹션(http://www.mysql.com/consulting/ )(을)를 참조해 주세요.인터넷에 액세스 할 수 없는 경우는,MySQL AB 의 컨설팅 스탭(<consulting@mysql.com> )에 전자 메일로 문의해 주세요. See 항1.3.1.3. 「컨설팅」 .

https://order.mysql.com/ 그럼, 상용 라이센스를 온라인으로 구입할 수 있습니다.또,MySQL AB 에 FAX 그리고 구입 신청서를 송신하는 방법을 참조할 수도 있습니다.라이센스의 상세한 것에 대하여는,http://www.mysql.com/products/pricing.html (을)를 참조해 주세요.라이센스에 관한 질문이 있는 경우나 하이 볼륨 라이센스 계약의 견적이 필요한 경우는,Web 사이트(http://www.mysql.com/ )에 있는 문의 용지에 기입하는지,<licensing@mysql.com> (라이센스에 관한 질문) 또는 <sales@mysql.com> (판매 견적)에 전자 메일을 전송해 주세요. See 항1.4.3. 「MySQL 라이센스」 .

MySQL AB (와)과의 파트나 제휴에 관심을 가지고 계신 기업은,<partner@mysql.com> 에 전자 메일을 전송해 주세요. See 항1.3.1.5. 「파트나 제휴」 .

MySQL 의 상표 폴리시의 상세한 것에 대하여는,http://www.mysql.com/company/trademark.html (을)를 참조하는지,<trademark@mysql.com> 에 전자 메일을 전송해 주세요. See 항1.4.4. 「MySQL AB 의 로고와 상표」 .

채용 섹션(http://www.mysql.com/company/jobs/ )에 게재되고 있다 MySQL AB 의 직종에 관심을 가지고 계신 분은,<jobs@mysql.com> 에 전자 메일을 전송해 주세요.이력서는, 첨부 파일로서 송신하는 것이 아니라, 전자 메일 메세지의 마지막에 plaintext 형식에서 기재해 주세요.

다수의 유저 사이의 일반적인 디스커션에 대해서는, 해당하는 메일링 리스트를 참조해 주세요. See 항1.7.1. 「MySQL 메일링 리스트」 .

에러(많은 경우, 버그로 불립니다)의 보고는, 질문이나 코멘트와 같게, 통상의 MySQL 메일링 리스트에 전송해 주세요.See 항1.7.1.1. 「MySQL 메일링 리스트」 .MySQL 서버 그리고 중대한 시큐러티 버그를 찾아냈을 경우는,<security@mysql.com> 에 전자 메일을 전송해 주세요. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

공개 가능한 벤치마크 결과를 가지고 계신 분은,<benchmarks@mysql.com> 에 전자 메일로 문의해 주세요.

이 메뉴얼에의 추가나 수정에 관한 제안에 대해서는, 메뉴얼 팀(<docs@mysql.com> )에 전자 메일을 전송해 주세요.

MySQL 의 Web 사이트(http://www.mysql.com/ )의 운영이나 내용에 관한 질문이나 코멘트에 대해서는,<webmaster@mysql.com> 에 전자 메일을 전송해 주세요.

MySQL AB 에는 프라이버시 폴리시가 있습니다.http://www.mysql.com/company/privacy.html (을)를 참조해 주세요.이 폴리시에 관한 질문에 대해서는,<privacy@mysql.com> 에 전자 메일을 전송해 주세요.

그 외의 질문에 대해서는 모두,<info@mysql.com> 에 전자 메일을 전송해 주세요.


1.4. MySQL 의 서포트와 라이센스

이 섹션에서는,MySQL 의 서포트 및 라이센스에 관한 결정에 대해 설명합니다.

1.4.1. MySQL AB 에 의해서 제공되는 서포트

MySQL AB (으)로부터의 테크니컬 서포트에서는,MySQL 데이타베이스 엔진을 코드화하는 소프트웨어 엔지니어로부터 고객 개개의 문제에 응한 회답이 제공됩니다.

당사는, 테크니컬 서포트를 넓고, 포괄적으로 파악합니다.고객에게 있어서 중요한 MySQL 소프트웨어에 관한 대부분의 문제는, 당사에 있어서도 중요합니다.유저는 통상, 다양한 커멘드나 유틸리티를 사용하는 방법, 퍼포먼스 보틀 넥을 제거하는 방법, 크래쉬 한 시스템을 restore 하는 방법,MySQL 에 대한 operating system나 네트워크의 영향을 이해하는 방법, 백업 및 리커버리에 관한 베스트 프랙티스를 설정하는 방법,API (을)를 이용하는 방법 등에 대한 헬프를 필요로 하고 있습니다.당사의 서포트는, 할 수 있는 한 돕는 것을 유의하고 있습니다만,MySQL 서버와 독자적인 유틸리티만을 대상으로 해,MySQL 서버에 액세스 하는 써드파티 제품은 대상으로 하고 있지 않습니다.

다양한 서포트 옵션의 상세한 것에 대하여는,http://www.mysql.com/support/ (을)를 참조해 주세요.여기에서는, 서포트 계약을 온라인으로 신청할 수도 있습니다.인터넷에 액세스 할 수 없는 경우는, 판매 스탭(<sales@mysql.com> )에 전자 메일로 문의해 주세요.

테크니컬 서포트는 생명보험과 같은 것입니다.생명보험이 없어도 몇 년간이나 쾌적하게 살 수 있습니다만, 그 때가 오면, 매우 중요하게 됩니다.그러나, 그리고 보험에 들어간 것은 너무 늦습니다.중요한 어플리케이션에 MySQL 서버 (을)를 사용하고 있는 경우, 문제가 돌연 발생했을 때에, 자신만큼으로 모든 것을 해결하는 것은 매우 시간이 걸립니다.그러한 경우,MySQL AB 그리고 채용하고 있는 경험 풍부한 MySQL 의 트러블 슈팅 담당자에게의 직접적인 액세스가 필요하게 되는 일이 있습니다.

1.4.2. MySQL 그리고 사용되고 있는 저작권과 라이센스

MySQL AB (은)는,MySQL 의 원시 코드,MySQL 의 로고와 상표, 및 이 메뉴얼의 저작권을 소유하고 있습니다.See 항1.3. 「MySQL AB 의 개요」 .MySQL 디스트리뷰션에는, 다양한 라이센스가 관련하고 있습니다.

  1. 서버,mysqlclient 라이브러리, 클라이언트, 및 GNU readline 라이브러리내의 MySQL 고유의 소스는 모두,GNU 일반 공중 이용 허락 계약서 의 대상이다.See 부록 H. GNU General Public License .이 라이센스의 텍스트는, 디스트리뷰션의 파일 COPYING 에 있다.

  2. GNU getopt 라이브러리는,GNU 열등 일반 공중 이용 허락 계약서 의 대상이다.http://www.fsf.org/licenses/ (을)를 참조.

  3. 소스(regexp 라이브러리)의 일부는,Berkeley 스타일의 저작권의 대상이다.

  4. MySQL 의 낡은 버젼(3.22 이전)에는, 한층 더 엄밀한 라이센스(http://www.mysql.com/products/mypl.html )(이)가 적용된다.개개의 버젼의 메뉴얼을 참조.

  5. MySQL 의 참조 설명서는 현재,GPL 스타일의 라이센스하에서는 제공되어 없다 .이 메뉴얼의 사용에는, 이하의 조건이 적용된다.

    • 다른 형식에의 변환이 가능하다.다만, 실제의 내용을 변경하거나 편집하거나 할 수 없다.

    • 개인적인 사용을 목적으로 하는 경우, 메뉴얼을 인쇄할 수 있다.

    • 인쇄한 메뉴얼의 판매나 다른 출판물로의 메뉴얼의 사용 등, 그 외의 사용 방법에 대해서는 모두,MySQL AB (으)로부터의 서면에 의한 사전의 합의가 필요하다.

    상세나 번역에 관심을 가지고 계신 분은,<docs@mysql.com> 에 전자 메일을 전송해 주세요.

MySQL 라이센스의 시행에 대해서는, 항1.4.3. 「MySQL 라이센스」 (을)를 참조해 주세요. 항1.4.4. 「MySQL AB 의 로고와 상표」 도 참조해 주세요.

1.4.3. MySQL 라이센스

MySQL 소프트웨어는, 가장 잘 알려져 있다고 생각된다 오픈 소스 라이센스이다 GNU 일반 공중 이용 허락 계약서 (GPL )에 근거해 릴리스 되고 있습니다.GPL 라이센스의 정식적 조건에 대해서는,http://www.fsf.org/licenses/ (을)를 참조해 주세요.http://www.fsf.org/licenses/gpl-faq.html 및 http://www.gnu.org/philosophy/enforcing-gpl.html 도 참조해 주세요.

MySQL 소프트웨어는 GPL 에 근거해 릴리스 되고 있으므로, 많은 경우, 무상으로 사용할 수 있습니다.다만, 특정의 용도에 대해서는,https://order.mysql.com/ 그리고 MySQL AB (으)로부터 상용 라이센스를 구입하지 않으면 안 되는 경우가 있습니다.상세한 것에 대하여는,http://www.mysql.com/products/licensing.html (을)를 참조해 주세요.

MySQL 의 낡은 버젼(3.22 이전)에는, 한층 더 엄밀한 라이센스(http://www.mysql.com/products/mypl.html )(이)가 적용됩니다.개개의 버젼의 메뉴얼을 참조해 주세요.

상용 라이센스,GPL , 또는 낡다 MySQL 라이센스에 근거해 MySQL 소프트웨어를 사용해도,MySQL AB 의 상표를 사용할 권리가 자동적으로 주어지는 것은 아닌 것에 주의해 주세요. See 항1.4.4. 「MySQL AB 의 로고와 상표」 .

1.4.3.1. 상용 라이센스에 근거한다 MySQL 소프트웨어의 사용

GPL 라이센스는, 프로그램이 GPL 프로그램에 링크하고 있는 경우, 작성된 제품의 모든 부분의 원시 코드도 모두 GPL 에 근거해 릴리스 할 필요가 있다고 하는 의미로, 전염성이 있습니다.이 GPL 요건에 따르지 않는 경우, 라이센스 조건에 위반하게 되어,GPL 프로그램을 사용할 권리를 모두 잃습니다.또, 손해를 받는 위험을 무릅쓰게도 됩니다.

이하와 같은 경우, 상용 라이센스가 필요합니다.

  • MySQL 소프트웨어의 GPL 코드와 프로그램을 링크해, 상용 제품을 작성하기 위해(때문에), 또는 추가한 비 GPL 코드를 다른 이유로 클로우즈 소스로 하기 위해서, 작성하는 제품에 GPL 에 근거하는 라이센스를 부여하지 않는 경우.상용 라이센스를 구입하면,MySQL 소프트웨어를 사용할 때에, 같은 코드에서도 GPL 하지만 적용되지 않게 된다.

  • MySQL 소프트웨어 마셔 (을)를 사용하는 비 GPL 어플리케이션을 제공해,MySQL 소프트웨어와 함께 출하하는 경우.이 타입의 솔루션은, 네트워크 경유로 행해져도 링크하고 있다고 보여진다.

  • GPL 라이센스아래에서 필요하게 되는 원시 코드의 제공을 실시하지 않고 ,MySQL 소프트웨어의 카피를 제공하는 경우.

  • 형식상은 상용 라이센스가 필요하지 않아도,MySQL 데이타베이스의 향후의 개발을 서포트하는 경우.MySQL AB (으)로부터 서포트를 직접 구입하는 것은,MySQL 소프트웨어의 개발에 공헌하는 이제(벌써) 1 개가 좋은 방법이다.또, 유저에게도 직접 메리트가 있다. See 항1.4.1. 「MySQL AB 에 의해서 제공되는 서포트」 .

라이센스를 요구하는 경우,MySQL 소프트웨어의 각 인스톨에 1 개씩 필요합니다.이것은,1 받침대의 머신상의 CPU 의 수에는 관계 없습니다.또, 서버에 접속하는 클라이언트의 수에 이론상의 제한은 없습니다.

상용 라이센스에 대해서는, 당사의 Web 사이트(http://www.mysql.com/products/licensing.html )(을)를 참조해 주세요.서포트 계약에 대해서는,http://www.mysql.com/support/ (을)를 참조해 주세요.특수한 요구가 있는 경우나 인터넷에 액세스 할 수 없는 경우는, 판매 스탭(<sales@mysql.com> )에 전자 메일로 문의해 주세요.

1.4.3.2. GPL 에 근거한다 MySQL 소프트웨어의 무상 사용

GPL 의 조건에 따라서 있는 경우,GPL 아래에서 MySQL 소프트웨어를 무상으로 사용할 수 있습니다.GPL 에 관한 일반적인 질문에 대한 회답등의 상세한 것에 대하여는,Free Software Foundation 의 일반적인 FAQ (http://www.fsf.org/licenses/gpl-faq.html )(을)를 참조해 주세요.일반적으로, 이하와 같은 경우에 GPL (을)를 사용합니다.

  • 독자적인 어플리케이션과 GPL 에 근거한다 MySQL 의 원시 코드의 양쪽 모두를 제품과 함께 제공하는 경우.

  • 상용으로서 디스트리뷰션을 판매하는 경우에서도, 기능에 관해서 MySQL 시스템에 링크하고 있지 않는, 또는 MySQL 시스템에 의존하고 있지 않는 다른 프로그램과 번들 되었다 MySQL 의 원시 코드를 제공하는 경우.이것은,GPL 라이센스에서는 단지 집약으로 불린다.

  • MySQL 시스템의 어느 부분도 제공하지 않는 경우, 무상으로 사용할 수 있다.

  • 인터넷 서비스 프로바이더(ISP )(으)로서MySQL 서버를 사용했다 Web 호스팅을 고객에게 제공하는 경우.당사는,MySQL 서포트가 있다 ISP (을)를 사용하도록(듯이) 추천 하고 있다.이것은,MySQL 의 인스톨에 관해서 발생할 수 있는 문제를 해결하기 위한 자원이, 실제로 그러한 ISP 에 있다고 하는 신뢰감을 얻을 수 있기 때문에 있다.ISP 에 MySQL 서버 의 상용 라이센스가 없어도, 적절한 패치가 적용되고 있는 것을 확인할 수 있도록, 고객에게 적어도 MySQL 인스톨의 소스에의 읽어내 액세스권을 부여할 필요가 있다.

  • MySQL 데이타베이스 소프트웨어를 Web 서버와 함께 사용하는 경우(제공하는 제품이 아닌 한), 상용 라이센스는 불필요하다.MySQL 서버 (을)를 사용하는 시판의 Web 서버를 실행하는 경우도, 같이이다.이것은,MySQL 시스템의 어느 부분도 제공하지 않기 때문이다.다만, 이 경우,MySQL 소프트웨어에 의해서 기업이 서포트되고 있으므로,MySQL 서포트를 구입해 주도록(듯이) 희망한다.

MySQL 데이타베이스 소프트웨어의 사용에 상용 라이센스가 불필요한 경우에서도,MySQL AB (으)로부터 서포트를 구입하는 것을 추천합니다.이것에 의해,MySQL 의 개발에 공헌하게 되는 것과 동시에, 고객 자신도 직접 메리트를 얻을 수 있습니다. See 항1.4.1. 「MySQL AB 에 의해서 제공되는 서포트」 .

MySQL 데이타베이스 소프트웨어의 사용에 의해서 이익을 얻는 상용 문맥으로 MySQL 데이타베이스 소프트웨어를 사용하는 경우는, 몇개의 레벨의 서포트를 구입하는 것으로 MySQL 소프트웨어의 개발의 도움을 부탁하고 있습니다.MySQL 데이타베이스가 고객의 비즈니스에 도움이 되고 있다면, 이번은 고객이 MySQL AB 에 손을 빌려 주세요(그렇지 않으면 서포트에 관한 질문을 하는 경우, 많은 노력을 필요로 한 성과를 무상으로 사용하고 있을 뿐만 아니라, 당사에 무상으로 서포트를 제공하도록(듯이) 의뢰하고 있게도 됩니다).

1.4.4. MySQL AB 의 로고와 상표

Web 사이트, 서적, 또는 박스 제품에 MySQL AB 의 돌고래의 로고를 게재하고 싶다고 한다 MySQL 데이타베이스 유저가 다수 계(오)십니다.당사는 이것을 환영해, 추천 있습니다만,MySQL 라는 말과 MySQL 의 돌고래의 로고는 MySQL AB 의 상표이며,http://www.mysql.com/company/trademark.html 에 기재되어 있는 당사의 상표 폴리시에 따라서 사용할 필요가 있는 것에 주의해 주세요.

1.4.4.1. MySQL 의 오리지날 로고

MySQL 의 돌고래의 로고는,2001 해에 핀란드의 광고 대리점 Priority 에 의해서 디자인 된 것입니다.머리가 좋고, 민첩하고 날씬한 동물이므로, 데이터의 대해원을 손쉽게라고 진행되는 것으로부터,MySQL 데이타베이스에 적절한 심볼로서 돌고래가 선택되었습니다.또, 우리도 돌고래를 좋아했습니다.

MySQL 의 오리지날 로고를 사용할 수 있는 것은,MySQL AB 의 대표자와 서면에 의한 합의에 의해서 사용이 허가된 유저만입니다.

1.4.4.2. 서면에 의한 허가없이 사용할 수 있다 MySQL 의 로고

당사는,Web 사이트(http://www.mysql.com/press/logos.html )(으)로부터 다운로드해,MySQL AB (으)로부터의 서면에 의한 허가없이 써드파티의 Web 사이트에서 사용할 수 있는 특수한 조건부 사용 로고를 디자인하고 있습니다.이러한 로고의 사용에는 전혀 제한은 없습니다만, 이름대로, 당사의 상표 폴리시가 적용됩니다.상표 폴리시도,Web 사이트에서 참조할 수 있습니다.로고를 사용하는 경우는, 상표 폴리시를 자주(잘) 읽어 주세요.기본적인 조건은 이하대로입니다.

  • http://www.mysql.com/ 사이트에 표시되고 있도록(듯이), 필요한 로고를 사용한다.필요에 따라서 로고의 사이즈를 변경할 수 있지만, 색이나 디자인을 변경하거나 그래픽을 변경하거나 할 수 없다.

  • MySQL 의 상표를 게재하는 사이트의 작성자 및 소유자가 MySQL AB (이)가 아니고, 유저 자신인 것을 명확하게 한다.

  • MySQL AB (이)나 MySQL AB 의 상표의 가치에 마이너스가 되는 사용법을 하지 않는다.당사는,MySQL AB 의 상표의 사용권을 무효로 할 권리를 유보하고 있다.

  • Web 사이트에서 상표를 사용하는 경우, 클릭하면, 직접 http://www.mysql.com/ 에 점프 하도록(듯이) 한다.

  • 어플리케이션으로 GPL 에 근거한다 MySQL 데이타베이스를 사용하는 경우, 어플리케이션은 오픈 소스 인 것과 동시에,MySQL 서버에 접속 가능하지 않으면 안 된다.

요구에 맞춘 특별한 조정에 관한 질문에 대해서는,<trademark@mysql.com> 에 전자 메일로 문의해 주세요.

1.4.4.3. MySQL 의 로고의 사용에 서면에 의한 허가가 필요한 경우

이하의 경우,MySQL 의 로고를 사용하려면 ,MySQL AB (으)로부터의 서면에 의한 허가가 사전에 필요합니다.

  • Web 사이트 이외의 장소에 MySQL AB 의 로고를 게재하는 경우

  • 전술의 조건부 사용 로고 이외의 MySQL AB 의 로고를 Web 사이트나 그 외의 장소에 게재하는 경우

법률상 및 상업상의 이유로부터, 당사는, 제품이나 서적 등에 둘 수 있다 MySQL 의 상표의 사용을 감시합니다.통상, 상용 제품에 MySQL AB 의 로고를 게재하는 경우에는 요금을 받습니다.수익의 일부가 MySQL 데이타베이스의 향후의 개발자금으로서 사용되는 것이 적절하다고 생각하기 (위해)때문입니다.

1.4.4.4. MySQL AB 의 파트너쉽 로고

MySQL 의 파트너쉽 로고를 사용할 수 있는 것은,MySQL AB (와)과 서면에 의한 파트너쉽 계약을 맺고 있는 기업 및 개인만입니다.파트너쉽에는,MySQL 의 강사 또는 컨설턴트로서의 인정도 포함됩니다.상세한 것에 대하여는, 항1.3.1.5. 「파트나 제휴」 (을)를 참조해 주세요.

1.4.4.5. 인쇄 텍스트 또는 프레젠테이션에 있어서의 MySQL 라는 말의 사용

MySQL AB 하 MySQL 데이타베이스의 참조를 환영합니다만,MySQL 라는 말은 MySQL AB 의 상표인 것에 주의해 주세요.그 때문에, 텍스트내에서 MySQL 라는 말을 최초로 사용하는 개소나 가장 눈에 띄도록(듯이) 사용하는 개소에는 상표 기호(TM )(을)를 더해 필요에 따라서,MySQL 하지만 MySQL AB 의 상표인 것을 기재할 필요가 있습니다.상세한 것에 대하여는, 상표 폴리시(http://www.mysql.com/company/trademark.html )(을)를 참조해 주세요.

1.4.4.6. 기업명 및 제품명에 있어서의 MySQL 라는 말의 사용

제품명, 기업명, 또는 인터넷 도메인명에 MySQL 라는 말을 사용하는 경우는,MySQL AB (으)로부터의 서면에 의한 허가가 필요합니다.


1.5. MySQL 의 개발 도로지도

이 섹션에서는,MySQL 4.0 ,4.1 ,5.0 , 및 5.1 그리고 실장 또는 계획되고 있는 주된 기능을 포함한,MySQL 의 개발 도로지도의 snapshot를 제공합니다.버젼 시리즈마다의 정보에 대해서는, 이하의 섹션을 참조해 주세요.다음의 겉(표)는, 가장 요망이 있던 기능의 일부에 대한 계획을 집계한 것입니다.

기능 | MySQL 버젼
UNION | 4.0
서브 쿼리 | 4.1
R-tree | 4.1 (MyISAM 테이블용)
Stored Procedure | 5.0
뷰 | 5.0 또는 5.1
커서 | 5.0
외부 키 | 5.1 (InnoDB 에 대해서는 3.23 그리고 실장이 끝난 상태)
Trigger | 5.1
Full OUTER JOIN | 5.1
제약 | 5.1

1.5.1. MySQL 4.0 의 개요

유저가 오랫동안 기다려 바라고 있었다 MySQL 서버 4.0 하지만 운용 스테이터스로 사용 가능하게 되었습니다.

MySQL 4.0 (은)는,http://www.mysql.com/ 및 당사의?~ 라로부터 다운로드할 수 있습니다.MySQL 4.0 (은)는 다수의 유저에 의해서 테스트되어 다수의 대규모 사이트에서 운용되고 있습니다.

MySQL 서버 4.0 의 주된 신기능은, 당사의 기존의 비즈니스 및 코?~ 니티유자 전용으로 설계되고 있어?~ 션크리티칼로 부하가 높은 데이타베이스 시스템에 대응한 솔루션으로서 MySQL 데이타베이스 소프트웨어를 확장합니다.편입 데이타베이스의 유저를 대상으로 한 신기능도 있습니다.

MySQL 4.0 (은)는,2003 년 3 달에 릴리스 된 버젼 4.0.12 그리고, 운용에 대해 안정되어 있다고 선언되었습니다.그 때문에, 향후,4.0 시리즈에 대해서는 버그 수정만을 해 낡다 3.23 시리즈에 대해서는 중대한 버그 수정만을 하게 됩니다. See 항2.5.2. 「버젼 3.23 (으)로부터 4.0 에의 업그레이드」 .

벌써 사용 가능한 MySQL 4.1 (알파 버전)에는,MySQL 소프트웨어의 신기능이 추가됩니다. See 항1.5.2. 「MySQL 4.1 의 개요」 .

1.5.1.1. MySQL 4.0 그리고 사용 가능한 기능

  • 속도의 향상

    • MySQL 4.0 에는 쿼리 캐쉬가 있어, 반복 쿼리를 사용하는 어플리케이션의 속도를 큰폭으로 향상시킬 수 있다. See 항6.9. 「MySQL 쿼리 캐쉬」 .

    • 버젼 4.0 그럼, 일괄 INSERT 스테이트먼트, 팩 된 인덱스의 검색,FULLTEXT 인덱스의 작성, 및 COUNT(DISTINCT) 등, 몇개의 영역에서 MySQL 서버의 속도가 한층 더 향상하고 있다.

  • 편입 MySQL 서버의 도입

    • 새로운 편입 서버 라이브러리를 사용하면, 스탠드얼론 어플리케이션 및 짜넣어 어플리케이션을 용이하게 작성할 수 있다.편입 서버는, 클라이언트/ 서버 환경에서 MySQL (을)를 사용한다 1 개의 방법이다. See 항1.5.1.2. 「편입 MySQL 서버」 .

  • 표준으로서의 InnoDB 스토리지 엔진

    • InnoDB 스토리지 엔진이 MySQL 서버의 표준 기능으로서 제공되게 되었다.즉,ACID 트랜잭션(transaction)의 완전 서포트, 연쇄 UPDATE 및 DELETE (을)를 사용한 외부 키, 및 행 레벨의 락이 표준 기능이 되고 있다. See 항7.5. 「InnoDB 테이블」 .

  • 신기능

    • MySQL 서버 4.0 의 확장되었다 FULLTEXT 검색 기능에 의해서, 큰 텍스트의 FULLTEXT 인덱스가, 바이너리와 자연 언어의 양쪽 모두의 검색 논리로 작성 가능하게 되었다.최소 워드장을 커스터마이즈 해, 임의의 자연 언어로 독자적인 스톱 워드 일람을 정의할 수 있기 위해,MySQL 서버상에 새로운 어플리케이션 세트를 구축할 수 있다. See 항6.8. 「MySQL 풀텍스트 검색」 .

  • 표준에의 준거, 이식성, 및 이행

    • 다른 데이타베이스 시스템으로부터 MySQL 서버에의 이행을 용이하게 하는 기능으로서(Oracle 에 있다)TRUNCATE TABLE 하지만 있다.

    • MySQL 서버로 UNION 스테이트먼트가 서포트되게 되었다.이것은, 다수의 유저가 오랫동안 기다려 바라고 있던 표준의 SQL 기능이다.

    • MySQL 하지만 Novell NetWare 6.0 플랫폼상에서 네이티브에 가동하게 되었다. See 항2.6.8. 「Novell NetWare 의 주의 사항」 .

  • 국제화

    • 독일, 오스트리아, 및 스위스의 유저 전용으로 MySQL 그리고 새로운 캐릭터 세트 latin1_de 하지만 서포트되게 되어, 독일어의 소트순서 그럼, 모음 변이를 포함한 단어가 독일의 전화번호부와 같은 순서로 소트 된다.

  • 편리한 사용의 향상

    새로운 유저 전용의 기능을 실장하는 프로세스에서도, 기존의 유저의 충실한 코?~ 니티로부터의 요망을 잊을 것은 없습니다.

    • 대부분의 mysqld 파라미터(스타트 업 옵션)가, 서버를 정?~ 하지 않아도 설정할 수 있게 되었다.이것은, 데이타베이스 관리자(DBA )에 있어서 편리한 기능이다. See 항5.5.6. 「SET 구문」 .

    • 복수 테이블의 DELETE 및 UPDATE 스테이트먼트가 추가되었다.

    • MyISAM 스토리지 엔진에 테이블 레벨의(이전과 같이 데이타베이스 레벨만이 아니다) 기호 연결의 서포트가 추가되었다.또,Windows 그럼, 데이타베이스 레벨에 있어서의 기호 연결의 처리가 디폴트로 유효하다.

    • 새롭게 추가된 함수 SQL_CALC_FOUND_ROWS (와)과 FOUND_ROWS() (을)를 사용하면,LIMIT 마디를 포함한다 SELECT 쿼리가 그 때를 포함하지 않는 경우에 돌려주는 레코드의 수를 조사할 수 있다.

이 메뉴얼의 뉴스 섹션에, 기능의 상세한 일람이 있습니다. See 항D.3. 「Changes in release 4.0.x (Production) 」 .

1.5.1.2. 편입 MySQL 서버

libmysqld 에 의해서,MySQL 서버는 어플리케이션의 대규모 전개에 대응합니다.편입 MySQL 서버 라이브러리를 사용하면, 다양한 어플리케이션이나 전자기기에 MySQL 서버를 짜넣을 수 있습니다.그러한 어플리케이션이나 전자기기의 최종 사용자에는, 실제는 그러한 기본으로 되어 있는 데이타베이스가 있는 것은 모릅니다.편입 MySQL 서버는, 인터넷 기기, 퍼블릭 철도 매점, 하드웨어와 소프트웨어가 짜 합쳐진 turnkey 장치, 고성능 인터넷 서버,CD-ROM 그리고 배포되고 있는 독립 언어형 데이타베이스등의 배후에서의 사용에 최적입니다.

libmysqld (이)가 많은 유저는,MySQL 의 듀얼 라이센스 의 혜택을 받습니다.GPL 에 구속되고 싶지 않은 유저는, 상용 라이센스에 근거해 소프트웨어를 사용할 수도 있습니다.편입 MySQL 라이브러리에서는 통상의 클라이언트 라이브러리와 같은 인터페이스가 사용되고 있으므로, 사용하기 쉽게, 편리합니다. See 항11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld 」 .

1.5.2. MySQL 4.1 의 개요

MySQL 서버 4.0 (은)는, 서브 쿼리나 Unicode 등의 신기능(버젼 4.1 그리고 실장) 및 SQL-99 Stored Procedure의 개발(버젼 5.0 그리고 실장)의 기초가 되고 있습니다.이러한 기능은, 당사의 고객으로부터의 요망이 가장 높은 것입니다.

이러한 추가 기능에 의해서,MySQL 데이터 베이스 서버의 비평가는,MySQL 데이타베이스 관리 시스템의 문제를 지적할 때에, 지금까지 이상으로 상상력이 필요하게 됩니다.그 안정성, 속도, 편리한 사용으로 벌써 잘 알려져 있다 MySQL 서버는, 매우 대부분을 바라는 구입자의 조건 리스트를 채울 수 있습니다.

1.5.2.1. MySQL 4.1 그리고 사용 가능한 기능

이 섹션에 기재되어 있는 기능은,MySQL 4.1 에 실장되고 있습니다.MySQL 4.1 에는, 그 밖에도 계획되고 있는 기능이 있습니다. See 항1.6.1. 「4.1 그리고 계획되고 있는 신기능」 .

Stored Procedure 등, 코드화 되는 대부분의 신기능은 MySQL 5.0 그리고 사용할 수 있게 됩니다. See 항1.6.2. 「5.0 그리고 계획되고 있는 신기능」 .

  • 서브 쿼리와 파생 테이블의 서포트

    • 서브 쿼리란, 다른 스테이트먼트내에 네스트 되었다 SELECT 스테이트먼트이다.파생 테이블(이름이 없는 뷰)이란, 다른 스테이트먼트의 FROM 절내의 서브 쿼리이다. See 항6.4.2. 「서브 쿼리 구문」 .

  • 속도의 향상

    • 준비된 스테이트먼트와 파라미터의 바인딩에 의한, 보다 빠른 바이너리 프로토콜. See 항11.1.4. 「C API 의 프리페아드스테이트먼트」 .

    • HEAP 테이블에 대해 B-TREE 인덱스의 작성이 서포트되게 되어, 정확하지 않은 검색의 응답 시간이 큰폭으로 단축된다.

  • 신기능

    • CREATE TABLE table_name2 LIKE table_name1 (을)를 사용하는 것으로, 기존의 테이블과 완전히 같은 구조의 새로운 테이블을 1 개의 스테이트먼트로 작성할 수 있다.

    • OpenGIS 공간 데이터형(지리 데이터)의 서포트. See 장 10. MySQL 에 있어서의 공간 정보의 기능 .

    • SSL 접속을 개입시킨 replication를 실행할 수 있다.

  • 표준에의 준거, 이식성, 및 이행

    • 새로운 클라이언트/ 서버 프로토콜에 의해,1 개의 결과 뿐만이 아니라, 복수의 경고를 클라이언트에 건네주는 기능이 추가된다.이것에 의해, 데이터의 일괄 로드등의 작업이 추적하기 쉬워진다.SHOW WARNINGS (은)는, 마지막 커멘드의 경고를 표시한다. See 항4.6.8.9. 「SHOW WARNINGS | ERRORS 」 .

  • 국제화

    • 어플리케이션으로 각국어를 사용하는 유저 베이스의 확대에 대응하기 위해서,MySQL 소프트웨어에서는,utf8 및 ucs2 캐릭터 세트에 의한 폭넓다 Unicode 서포트가 제공되게 되었다.

    • 컬럼, 테이블, 및 데이타베이스 마다 캐릭터 세트를 정의할 수 있게 되었다.이것에 의해, 특히 다언어 Web 사이트를 대상으로 한 어플리케이션 설계로 고도의 유연성이 실현된다.

    • 개선된 이 캐릭터 세트 서포트에 대해서는, 장 9. 각국 캐릭터 세트와 Unicode (을)를 참조.

  • 편리한 사용의 향상

    • 잘 전해지는 요망에 따르고,SQL 스테이트먼트에 관한 헬프 정보를 취득하기 위해서 사용할 수 있는 서버 베이스의 HELP 커멘드를 추가했다.서버측에서 이 정보를 취득할 수 있는 메리트는, 정보가 항상 그 특정의 서버 버젼에 해당하는 점이다.이 정보는 SQL 스테이트먼트를 발행하는 것으로 참조할 수 있으므로, 임의의 클라이언트를 거기에 액세스 하도록(듯이) 기술할 수 있다.예를 들어,mysql 커멘드 라인 클라이언트는 이 기능을 사용할 수 있도록 변경되고 있다.

    • 새로운 클라이언트/ 서버 프로토콜에서는,1 회의 호출로 복수의 스테이트먼트를 발행할 수 있다. See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」 .

    • 새로운 클라이언트/ 서버 프로토콜에서는, 복수의 결과 세트를 돌려줄 수도 있다.이것은, 예를 들어, 복수의 스테이트먼트를 송신한 결과적으로 행해지는 일이 있다(전의 항목을 참조).

    • 새롭다 INSERT ... ON DUPLICATE KEY UPDATE ... 구문이 실장되었다.이 구문을 사용하면,INSERT 에 의해서 PRIMARY 또는 UNIQUE 키(인덱스)로 중복이 발생했을 경우에 기존의 레코드를 갱신 할 수 있다. See 항6.4.3. 「INSERT 구문」 .

    • 새로운 집약 함수 GROUP_CONCAT() (을)를 실장했다.이 함수에 의해서, 그룹화 된 레코드의 컬럼을 1 개의 결과 문자열에 연결하는 매우 편리한 기능이 추가된다. See 항6.3.7. 「GROUP BY 마디로 사용하는 함수와 수식자」 .

이 메뉴얼의 뉴스 섹션에, 기능의 상세한 일람이 있습니다. See 항D.2. 「Changes in release 4.1.x (Alpha) 」 .

1.5.2.2. 단계적 롤 아웃

MySQL 4.1 에는, 새로운 기능이 추가됩니다.알파 버전은, 벌써 다운로드할 수 있습니다. See 항1.5.2.3. 「즉시의 개발 용도에의 대응」 .

버젼 4.1 에 추가되는 기능은, 거의 확정하고 있습니다.벌써, 버젼 5.0 (을)를 향해서 새로운 개발을 하고 있습니다.MySQL 4.1 하 알파 (한층 더 신기능이 추가/ 변경될 가능성이 있을 단계), 베타 (기능이 고정되어 버그 수정만을 할 단계), 감마 (제품판으로서의 릴리스를 수주일 후에 앞둔 단계)(이)라고 하는 스텝을 더듬습니다.이 프로세스의 마지막으로,MySQL 4.1 (은)는 새로운 제품판이 됩니다.

1.5.2.3. 즉시의 개발 용도에의 대응

현재,MySQL 4.1 (은)는 알파 단계에 있어,http://www.mysql.com/downloads/mysql-4.1.html 그리고 바이너리 릴리스를 다운로드할 수 있습니다.모든 바이너리 릴리스는, 테스트하는 플랫폼에서 에러가 발생하는 일 없이, 일련의 광범위한 테스트에 합격하고 있습니다. See 항D.2. 「Changes in release 4.1.x (Alpha) 」 .

MySQL 4.1 의 최신의 개발 소스의 사용을 희망하는 유저를 위해서,4.1 BitKeeper 리포지터리(repository)를 공개하고 있습니다. See 항2.3.4. 「개발 소스 트리로부터의 인스톨」 .

1.5.3. MySQL 5.0 , 차기 개발 릴리스

MySQL 의 새로운 개발은, Stored Procedure등의 신기능을 특징으로 한다 5.0 릴리스에 초점이 놓여져 있습니다. See 항1.6.2. 「5.0 그리고 계획되고 있는 신기능」 .

MySQL 개발의 최전선의 참조를 희망하는 유저를 위해서,MySQL 버젼 5.0 의 BitKeeper 리포지터리(repository)를 공개하고 있습니다. See 항2.3.4. 「개발 소스 트리로부터의 인스톨」 .


1.6. MySQL 의 향후(TODO )

이 섹션에서는,MySQL 서버 에 실장 예정의 기능의 개요를 설명합니다.일람은 버젼 마다 나뉘고 있어 항목은 거의, 실장되는 순서에 줄지어 있습니다.

주의: 특정의 기능을 시급히 필요로 하는 기업 레벨의 유저는, 지원 옵션에 대해 <sales@mysql.com> 에 문의해 주세요.스폰서 기업으로부터의 특정의 목적으로 좁힌 자금 제공에 의해서, 그 목적을 위해서 특별한 자원을 할당할 수 있습니다.과거에 자금 제공을 받은 기능의 예로서 replication가 있습니다.

1.6.1. 4.1 그리고 계획되고 있는 신기능

이하의 기능은,MySQL 4.1 에 아직 실장은 되고 있지 않습니다만,MySQL 4.1 하지만 베타 단계로 이행하기 전에 실장될 예정입니다.MySQL 4.1 에 벌써 실장되고 있는 기능의 일람에 대해서는, 항1.5.2.1. 「MySQL 4.1 그리고 사용 가능한 기능」 (을)를 참조해 주세요.

  • 안정되었다 OpenSSL 서포트(MySQL 4.0 그렇지만 기본적으로는 서포트되고 있지만,100% 테스트되고 있는 것은 아니다).

  • 준비된 스테이트먼트의 것보다 상세한 테스트.

  • 1 개의 테이블로 사용하는 복수의 캐릭터 세트의 것보다 상세한 테스트.

1.6.2. 5.0 그리고 계획되고 있는 신기능

MySQL 5.0 에는, 이하의 기능이 짜넣어질 예정입니다.다수의 개발자가 다양한 프로젝트로 작업하고 있으므로, 그 밖에도 많은 기능이 있는 것에 주의해 주세요.이러한 기능의 일부는,MySQL 4.1 에 추가될 가능성도 있습니다.MySQL 4.1 에 벌써 실장되고 있는 기능의 일람에 대해서는, 항1.5.2.1. 「MySQL 4.1 그리고 사용 가능한 기능」 (을)를 참조해 주세요.

MySQL 개발의 최전선의 참조를 희망하는 유저를 위해서,MySQL 버젼 5.0 의 BitKeeper 리포지터리(repository)를 공개하고 있습니다. See 항2.3.4. 「개발 소스 트리로부터의 인스톨」 .

  • Stored Procedure

    • Stored Procedure는, 현재 실장중이다.이 시도는 SQL-99 에 근거하는 것으로,Oracle PL/SQL 에 유사한(다만, 같지 않다) 기본 구문을 사용한다.또, 외부 언어로 훅 한다 SQL-99 체제, 및(가능한 경우)PL/SQL (이)나 T-SQL 등과의 호환성도 실장할 예정이다.

  • 신기능

    • 기본적인 커서 서포트.

    • MyISAM 테이블로 인덱스가 R-TREE 인덱스로서 작성되도록(듯이) 명시적으로 지정하는 기능.4.1 그럼, 지리 데이터(GIS 데이터형)에 붙어 R-TREE 인덱스가 내부에서 사용되지만, 필요에 따라서 작성할 수 없다.

    • HEAP 테이블의 가변장 레코드.

  • 표준에의 준거, 이식성, 및 이행

    • VARCHAR 의 완전한 서포트(255 (을)를 넘는 컬럼장, 후속의 스페이스를 삭제하지 않는다)의 추가(MyISAM 스토리지 엔진에서는 벌써 이것이 서포트되고 있지만, 유저 레벨에서는 아직 사용할 수 없다).

  • 속도의 향상

    • SHOW COLUMNS FROM table_name (컬럼명의 표시를 가능하게 하기 위해서 mysql 클라이언트에 의해서 사용된다)에 의해서, 테이블은 아니고 정의 파일만이 열리도록(듯이) 한다.이것에 의해서, 사용되는 메모리가 적어도 되는 것과 동시에, 속도가 아득하게 향상한다.

    • MyISAM 테이블의 DELETE 그리고 레코드 캐쉬를 사용할 수 있도록 한다.그러기 위해서는,.MYD 파일을 갱신할 때에 스레드레코드캐슈를 갱신할 필요가 있다.

    • 메모리내(HEAP ) 테이블의 개량.

      • 가변장 레코드

      • 보다 신속한 레코드 처리(카피의 삭감)

  • 국제화

    • SET CHARACTER SET (을)를 사용하는 경우, 문자열 뿐만이 아니라, 쿼리 전체가 한 번에 변환되도록(듯이) 할 필요가 있다.이것에 의해서, 유저는 데이타베이스명, 테이블명, 및 컬럼명으로 변환된 문자를 사용할 수 있게 된다.

  • 편리한 사용의 향상

    • 액티브한 MERGE 테이블로 사용되고 있는 테이블에 대해서 RENAME TABLE (을)를 발행했을 경우에 테이블이 파손할 가능성이 있는 문제의 해결.

1.6.3. 5.1 그리고 계획되고 있는 신기능

  • 신기능

    • 모든 테이블형으로의 FOREIGN KEY 의 서포트.

    • 컬럼 레벨의 제약.

    • 긴급시의 replication.

    • 퍼포먼스에의 영향이 매우 적은 온라인 백업.온라인 백업에 의해서, 마스터를 정?~ 하지 않고 새로운 replication 슬레이브를 간단하게 추가할 수 있게 된다.

  • 속도의 향상

    • 텍스트 베이스가 새로운 테이블 정의 파일 형식(.frm 파일)과 테이블 정의에 사용되는 테이블 캐쉬.이것에 의해서, 테이블 구조의 쿼리가 고속으로 되는 것과 동시에, 보다 효율적인 외부 키 서포트가 실현된다.

    • 1 비트를 사용하도록(듯이) BIT 형태를 최적화한다(현재,BIT 하 1 아르바이트를 필요로 해,TINYINT 의 동의어로서 다루어지고 있다).

  • 편리한 사용의 향상

    • 클라이언트/ 서버 프로토콜에, 장시간 실행되고 있는 커멘드의 진척 상황을 참조하는 옵션을 추가한다.

    • RENAME DATABASE (을)를 실장한다.모든 스토리지 엔진에 대해 이것을 안전하게 하려면 , 이하와 같이 동작할 필요가 있다.

      • 새로운 데이타베이스를 작성한다.

      • RENAME 커멘드를 사용해 행해지도록(듯이), 모든 테이블에 대해서, 다른 데이타베이스에의 테이블의 이름 변경을 실시한다.

      • 원래의 데이타베이스를 파기한다.

    • 내부 파일 인터페이스의 변경.이것에 의해서, 모든 파일 처리가 아득하게 일반적으로 되는 것과 동시에,RAID (와)과 같이 간단하게 확장자(extension)를 추가할 수 있게 된다.

1.6.4. 가까운 장래에 계획되고 있는 신기능

  • 신기능

    • 트리 형식(계층장)의 구조를 검색한다 Oracle (와)과 같은 CONNECT BY PRIOR ... .

    • 부족한 모든 SQL-92 및 ODBC 3.0 형태를 추가한다.

    • SUM(DISTINCT) (을)를 추가한다.

    • 테이블의 독해가 락 되고 있는 경우, 테이블의 최후로 동시 삽입을 실시한다 INSERT SQL_CONCURRENT 및 mysqld --concurrent-insert .

    • UPDATE TABLE foo SET @a=a+b,a=@a, b=@a+c (와)과 같이,UPDATE 스테이트먼트로의 변수의 갱신을 유효하게 한다.

    • 유저 변수가 갱신되는 경우,SELECT id, @a:=COUNT(*), SUM(sum_col)/@a FROM table_name GROUP BY id (와)과 같이 GROUP BY (와)과 함께 사용할 수 있도록 변경한다.

    • TIMESTAMP 및 AUTO_INCREMENT 필드를 갱신하지 않게 LOAD DATA INFILE 에 IMAGE 옵션을 추가한다.

    • 다음과 같이 동작한다 LOAD DATA INFILE ... UPDATE 구문을 추가한다.

      • 주키가 있는 테이블에 대해서, 입력 레코드에 주키치가 포함되어 있는 경우, 그 주키치와 일치하는 기존의 레코드는 그 외의 입력 컬럼으로부터 갱신된다.다만, 입력 레코드에 없다 컬럼에 대응하는 컬럼은 그대로 된다.

      • 주키가 있는 테이블에 대해서, 입력 레코드에 주키치가 포함되지 않은 경우나 키의 일부가 없는 경우, 레코드는 LOAD DATA INFILE ... REPLACE INTO (으)로서 처리된다.

    • LOAD DATA INFILE 그리고 다음과 같은 구문이 인식되도록(듯이) 한다.

      LOAD DATA INFILE 'file_name.txt' INTO TABLE tbl_name
     TEXT_FIELDS (text_field1, text_field2, text_field3)
     SET table_field1=CONCAT(text_field1, text_field2),
         table_field3=23
     IGNORE text_field3

      이것을 사용하면, 텍스트 파일내의 여분의 컬럼을 스킵 하거나 읽어낸 데이터의 식에 근거해 컬럼을 갱신하거나 할 수 있다.

    • SET 형태의 컬럼을 사용하는 새로운 함수.

      • ADD_TO_SET(value,set)

      • REMOVE_FROM_SET(value,set)

    • 쿼리의 도중에 mysql (을)를 정?~ 하는 경우, 다른 접속을 열어, 실행중의 원래의 쿼리를 종료할 필요가 있다.또는, 서버로 이것이 검출되도록(듯이) 할 필요가 있다.

    • 시스템 테이블로서 사용할 수 있도록, 테이블 정보의 스토리지 엔진 인터페이스를 추가한다.이것은, 모든 테이블에 관한 정보를 요구했을 경우에는 다소 늦어지지만, 매우 유연하다.기본적인 테이블 정보를 대상으로 했다 SHOW INFO FROM tbl_name 하지만 실장된다.

    • SELECT a FROM table_name1 LEFT JOIN table_name2 USING (a) (을)를 유효하게 한다.이 경우,a (은)는,table_name1 테이블에 유래하면 상정된다.

    • UPDATE 스테이트먼트의 DELETE 및 REPLACE 옵션(이것에 의해서, 갱신시에 중복 키 에러가 발생했을 경우, 레코드가 삭제되게 된다).

    • 초의 소수부를 격납하도록(듯이) DATETIME 의 서식을 변경한다.

    • 현재의 라이브러리 대신에, 새롭다 GNU regexp 라이브러리를 사용할 수 있도록 한다(새로운 라이브러리는, 현재의 라이브러리보다 아득하게 고속으로 있다).

  • 표준에의 준거, 이식성, 및 이행

    • 컬럼에 자동 DEFAULT 값이 추가되지 않게 한다.DEFAULT 하지만 없는 컬럼에 대해서는,INSERT 스테이트먼트에 값이 없는 경우, 에러를 생성한다.

    • ANY() ,EVERY() , 및 SOME() 그룹 함수를 추가한다.표준의 SQL 그럼, 이것들은 불형의 컬럼만으로 동작하지만,0 값을 FALSE ,0 이외의 값을 TRUE (으)로서 처리하는 것으로, 모든 컬럼/ 식에서 동작하도록(듯이) 확장할 수 있다.

    • MAX(column) 의 형태를 컬럼형과 같게 되도록(듯이) 고정한다.

      mysql> CREATE TABLE t1 (a DATE);
mysql> INSERT INTO t1 VALUES (NOW());
mysql> CREATE TABLE t2 SELECT MAX(a) FROM t1;
mysql> SHOW COLUMNS FROM t2;

  • 속도의 향상

    • 정의된 수를 넘는 스레드로 동시에 MyISAM 리커버리가 실행되지 않게 한다.

    • 필요에 따라서 동시 삽입을 사용하도록(듯이) INSERT ... SELECT (을)를 변경한다.

    • 당분간 사용되어 있지 않은 경우, 지연 키가 설정되어 있는 테이블의 키 페이지를 정기적으로 플래시 하는 옵션을 추가한다.

    • 키 부분에서의 결합을 유효하게 한다(최적화의 문제).

    • Windows (으)로의 pread()/pwrite() 의 시?~ 레이션을 추가하고, 동시 삽입을 유효하게 한다.

    • 가장 빈번히 히트 하는 테이블, 복수 테이블의 결합이 실행되는 빈도 등에 관한 정보를 해석할 수 있는 로그 파일 analyzer를 추가한다.이것은, 아득하게 효율적인 쿼리를 실행하도록(듯이) 최적화할 수 있는 영역이나 테이블 설계를 특정하는데 있어서 편리하다.

  • 국제화

  • 편리한 사용의 향상

    • SELECT MIN(column) ... GROUP BY 의 실행시에, 원의 필드형을 돌려준다.

    • long_query_time (을)를 마이크로 세컨드 단위로 상세하게 지정할 수 있도록 한다.

    • PACK 또는 COMPRESS 조작을 실행할 수 있도록,myisampack 코드를 서버에 링크한다.

    • 인덱스 파일이 가득 찼을 경우에 리커버리 할 수 있도록(듯이),INSERT/DELETE/UPDATE 시간에 텐포라리키밧파캐슈를 추가한다.

    • 다른 디스크에 기호 연결 되고 있는 테이블로 ALTER TABLE (을)를 실행하는 경우, 그 디스크에 텐포라리테이불을 작성한다.

    • 타임 존이 다른 일자의 처리를 용이하게 하기 위해서, 타임 존 정보를 적절히 처리한다 DATE/DATETIME 형태를 실장한다.

    • 스레드를 사용하지 않고 모든 라이브러리(MyISAM 등)을 컴파일 할 수 있도록(듯이),configure (을)를 고정한다.

    • LIMIT @a,@b (와)과 같이,SQL 변수를 LIMIT 의 인수로서 사용할 수 있도록 한다.

    • mysql (으)로부터 Web 브라우저에의 자동 출력.

    • LOCK DATABASES ( 및 다양한 옵션).

    • SHOW STATUS 에 의해서 나타내지는 다양한 수치.레코드의 독해 및 갱신.1 개의 테이블에 대한다 SELECT 및 결합을 사용했다 SELECT . SELECT 된 테이블의 평균수.ORDER BY 및 GROUP BY 쿼리의 수.

    • mysqladmin copy database new-database .이 때문에는,COPY 조작을 mysqld 에 추가할 필요가 있다.

    • 프로세스 일람의 출력에 쿼리/ 스레드의 수가 나타나도록(듯이) 한다.

    • 호스트명 캐쉬에 관한 정보를 출력하기 위한 SHOW HOSTS .

    • 계산된 컬럼에 대해서, 공백 문자열로부터 NULL 에 테이블명을 변경한다.

    • SELECT COUNT(*)*(id+0) FROM table_name GROUP BY id 의 경우, 숫자 -> 문자열 -> 숫자라고 하는 변환을 피하기 위해서, 수치에 대해서 Item_copy_string (을)를 사용하지 않는다.

    • INSERT DELAYED (을)를 실행하는 클라이언트가 ALTER TABLE 에 의해서 정?~ 되지 않게 변경한다.

    • UPDATE 마디로 컬럼이 참조되고 있는 경우, 갱신이 개시되기 전의 낡은 값이 컬럼에 포함되도록(듯이) 고정한다.

  • 새로운 operating system

    • LynxOS 에의 MySQL 클라이언트의 이식.

1.6.5. 중기적인 장래에 계획되고 있는 신기능

  • 함수 get_changed_tables(timeout,table1,table2,...) (을)를 실장한다.

  • 가능한 경우, 테이블의 독해로 memmap 하지만 사용되도록(듯이) 변경한다.현시점에서는, 압축된 테이블만으로 memmap 하지만 사용되고 있다.

  • 자동 타임 스탬프 코드를 보다 적절한 것으로 한다.SET TIMESTAMP=#; (을)를 사용해 갱신 로그에 타임 스탬프를 추가한다.

  • 속도를 향상시키기 위해서, 몇개의 장소에서 읽어내/ 기입 상호 배타 락(mutex) (을)를 사용한다.

  • 신풀(완전한 기능 장비까지 단계적으로 실장). See 항1.8.4.6. 「뷰」 .

  • 테이블, 텐포라리테이불, 또는 임시 파일로 에러 23 (열려 있는 파일이 충분하지 않다)(이)가 발생했을 경우, 일부의 테이블을 자동적으로 닫는다.

  • 정수의 전반을 개량한다.식에서 col_name=n 하지만 발견되면, 정수 n 의 경우, 진묘쵸우에 기록되어 있는 일의 다른 col_name (을)를 n 에 치환한다.현시점에서는, 단순한 케이스만으로 이것을 하고 있다.

  • 가능한 경우, 계산식을 사용해 모든 정수식을 변경한다.

  • 키 = 식을 최적화한다.현시점에서는, 키 = 필드 또는 키 = 정수만이 최적화되고 있다.

  • 보다 적절한 코드화를 위해서 카피 함수의 일부를 결합한다.

  • 사이즈를 삭감해, 보다 적절한 에러 메세지를 취득하도록(듯이),sql_yacc.yy (을)를 인 라인 파서로 변경한다(5 일).

  • 함수내의 다양한 수의 인수에 대해 1 살의 룰만이 사용되도록(듯이) 파서를 변경한다.

  • 명령부에서 완전한 계산명을 사용한다(ACCESS97 에 대응).

  • MINUS ,INTERSECT , 및 FULL OUTER JOIN (현시점에서는,UNION (4.0 )(와)과 LEFT|RIGHT OUTER JOIN 하지만 서포트되고 있다).

  • 쿼리에 시간제한을 설정하기 위해서,SQL_OPTION MAX_SELECT_TIME=# (을)를 사용할 수 있도록 한다.

  • 갱신 로그로부터 데이타베이스에의 기입을 가능하게 한다.

  • 결과 세트의 최후로부터 데이터를 취득할 수 있도록 LIMIT (을)를 확장한다.

  • 클라이언트의 접속/ 독해/ 기입 기능에 관한 경고.

  • mysqld_safe 에 대한 변경에는 주의가 필요하다.Debian 하지만 준거하려고 하고 있다 FSSTND 에 따라서,PID 파일은 /var/run/<progname>.pid 에, 로그 파일은 /var/log 에 격납될 필요가 있다."pidfile" 및 "log" 의 최초의 선언에 "DATADIR" (을)를 삽입하면, 이러한 파일의 장소를 1 개의 스테이트먼트로 변경할 수 있으므로, 편리하다.

  • 클라이언트가 로그를 요구할 수 있도록 한다.

  • gzip 에 의해서 압축된 파일을 스테이트먼트로 읽어들일 수 있도록(듯이),LOAD DATA INFILE 에 zlib() 의 사용을 추가한다.

  • BLOB 형태의 컬럼의 소트 및 그룹화를 고정한다(현시점에서는, 부분적으로 해결되고 있다).

  • 스레드를 카운트 할 때에 semaphore를 사용하도록(듯이) 변경한다.우선,MIT-pthreads 의 semaphore 라이브러리를 실장할 필요가 있다.

  • 외모를 포함한다 JOIN 의 완전 서포트를 추가한다.

  • 싱글스 레드/ 접속 대신에, 스레드의 풀을 이용해 쿼리를 처리한다.

  • GET_LOCK() 그리고 복수의 락을 취득할 수 있도록 한다.이것을 실행했을 경우, 이 변경에 의해서 발생할 가능성이 있는 데드 록도 처리할 필요가 있다.

시간은, 실제의 시간이 아니고, 작업량에 근거해서 기록되고 있습니다.

1.6.6. 계획되어 있지 않은 신기능

SQL-92/SQL-99 에의 완전한 준거를 목표로 하고 있습니다.실장을 계획하고 있지 않는 기능은 없습니다.


1.7. MySQL 의 정보원

1.7.1. MySQL 메일링 리스트

이 섹션에서는 MySQL 메일링 리스트의 개요를 설명하는 것과 동시에, 리스트의 사용 방법에 관한 가이드 라인을 제공합니다.메일링 리스트를 구독하면, 리스트에의 모든 투고가 전자 메일 메세지로서 송신됩니다.또, 자신의 질문이나 회답을 리스트에 송신할 수도 있습니다.

1.7.1.1. MySQL 메일링 리스트

이 섹션에 기재되어 있는 메일링 리스트를 구독하는 경우 또는 구독을 안?~ 하는 경우는,http://lists.mysql.com/ 에 액세스 해 주세요.구독 또는 구독중?~ 에 관한 메세지는 어느 메일링 리스트에도 송신하지 말아 주세요 .송신했을 경우, 그 메세지가 다수의 다른 유저에게 자동적으로 전달되어 버립니다.

로컬 사이트에 MySQL 메일링 리스트의 구독자가 다수 있는 경우,lists.mysql.com (으)로부터 사이트에 송신된 메세지가 로컬 리스트에 전달되도록(듯이), 로컬의 메일링 리스트가 작성되고 있는 경우가 있습니다.이러한 경우, 로컬의 MySQL 리스트에의 추가 또는 리스트로부터의 삭제에 대해서는, 시스템 관리 책임자에 문의해 주세요.

메일 프로그램내의 개별의 메일 박스에 메일링 리스트가 송신되도록(듯이) 하려면 , 메세지헤더에 근거해 필터를 설정해 주세요.List-ID: 또는 Delivered-To: 헤더를 사용하고, 리스트의 메세지를 식별할 수 있습니다.

MySQL 메일링 리스트는 이하대로입니다.

  • announce

    이 리스트는, 새로운 버젼의 MySQL 및 관련하는 프로그램의 통지에 사용된다.이것은, 모든 MySQL 유저가 구독할 필요가 있는, 볼륨의 작은 리스트이다.

  • mysql

    이것은,MySQL 에 관한 일반적인 디스커션에 사용되는 메인의 리스트이다.토픽에 따라서는, 보다 전문적인 리스트로 디스커션을 실시하는 편이 좋은 것도 있다.적절하지 않은 리스트에 투고하면, 회답을 얻을 수 없는 것이 있다.

  • mysql-digest

    이것은, 다이제스트 형식의 mysql 리스트이다.이 리스트를 구독하면, 전리스트의 메세지를 받아들이게 된다.이것은,1 일 1 회 큰 메일 메세지로서 송신된다.

  • bugs

    이것은,MySQL 의 최신 릴리스이?~ 에 보고된 문제를 항상 파악해 두고 싶은 유저나, 버그의 검출과 수정의 프로세스에 적극적으로 참가하고 싶은 유저에게 있어서 흥미로운 리스트이다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

  • bugs-digest

    이것은, 다이제스트 형식의 bugs 리스트이다.

  • internals

    이 리스트는,MySQL 코드에 종사하는 사람을 대상으로 하고 있다.또,MySQL 의 개발 및 포스트패치에 관한 디스커션을 실시하는 포럼이기도 하다.

  • internals-digest

    이것은, 다이제스트 형식의 internals 리스트이다.

  • mysqldoc

    이 리스트는,MySQL AB 의 종업원, 번역자, 및 그 외의 코?~ 니티멘바 등,MySQL 의 메뉴얼에 종사하는 사람을 대상으로 하고 있다.

  • mysqldoc-digest

    이것은, 다이제스트 형식의 mysqldoc 리스트이다.

  • benchmarks

    이 리스트는, 퍼포먼스에 관한 문제에 관심이 있는 사람을 대상으로 하고 있다.데이타베이스의 퍼포먼스(MySQL 에 한정되지 않는다)에 관한 디스커션이 중심이지만, 커넬, 파일 시스템, 디스크 시스템의 퍼포먼스 등, 보다 광범위한 카테고리도 포함된다.

  • benchmarks-digest

    이것은, 다이제스트 형식의 benchmarks 리스트이다.

  • packagers

    이 리스트는,MySQL 의 패키지 및 디스트리뷰션에 관한 디스커션에 사용된다.이것은,MySQL 의 패키지에 관한 아이디어나, 서포트 떠날 수 있어 모든 플랫폼 및 operating system로 가능한 한 같은 MySQL 의 외관을 확보하기 위한 아이디어를 교환하기 위해서 디스트리뷰션 관리자에 의해서 사용되는 포럼이다.

  • packagers-digest

    이것은, 다이제스트 형식의 packagers 리스트이다.

  • java

    이 리스트는,MySQL 서버 및 Java 에 관한 디스커션에 사용된다.MySQL Connector/J (을)를 포함한,JDBC 드라이버에 관한 디스커션에 사용되는 것이 대부분이다.

  • java-digest

    이것은, 다이제스트 형식의 java 리스트이다.

  • win32

    이 리스트는,Windows 9x/Me/NT/2000/XP 등의 Microsoft operating system로 실행된다 MySQL 소프트웨어에 관한 모든 토픽에 사용된다.

  • win32-digest

    이것은, 다이제스트 형식의 win32 리스트이다.

  • myodbc

    이 리스트는,ODBC (을)를 사용했다 MySQL 서버에의 접속에 관한 모든 토픽에 사용된다.

  • myodbc-digest

    이것은, 다이제스트 형식의 myodbc 리스트이다.

  • mysqlcc

    이 리스트는,MySQL Control Center 그래피컬 클라이언트에 관한 모든 토픽에 사용된다.

  • mysqlcc-digest

    이것은, 다이제스트 형식의 mysqlcc 리스트이다.

  • plusplus

    이 리스트는,MySQL 에의 C++ API (을)를 사용한 프로그라?~ 그에 관한 모든 토픽에 사용된다.

  • plusplus-digest

    이것은, 다이제스트 형식의 plusplus 리스트이다.

  • msql-mysql-modules

    이 리스트는, 현재 DBD-mysql (으)로 불리고 있다 msql-mysql-modules (을)를 사용했다 MySQL 의 Perl 서포트에 관한 모든 토픽에 사용된다.

  • msql-mysql-modules-digest

    이것은, 다이제스트 형식의 msql-mysql-modules 리스트이다.

질문에 대한 회답이 MySQL 메일링 리스트로부터 얻을 수 없었던 경우,MySQL AB (으)로부터 유료로 서포트를 받는 방법이 있습니다.그 경우는,MySQL 의 개발자와 직접 연락을 할 수 있습니다. See 항1.4.1. 「MySQL AB 에 의해서 제공되는 서포트」 .

이하는, 영어 이외의 언어에 의한다 MySQL 메일링 리스트입니다.이러한 리스트는 MySQL AB 하지만 운영하고 있는 것은 아니기 때문에, 품질은 보증하지 않습니다.

  • <mysql-france-subscribe@yahoogroups.com> 프랑스어의 메일링 리스트 , <list@tinc.net> 한국어의 메일링 리스트

    이 리스트에 subscribe mysql your@e-mail.address (을)를 전자 메일로 전송해 주세요.

  • <mysql-de-request@lists.4t2.com> 독일어의 메일링 리스트

    이 리스트에 subscribe mysql-de your@e-mail.address (을)를 전자 메일로 전송해 주세요.이 메일링 리스트에 대해서는,http://www.4t2.com/mysql/ (을)를 참조해 주세요.

  • <mysql-br-request@listas.linkway.com.br> 포르투갈어의 메일링 리스트

    이 리스트에 subscribe mysql-br your@e-mail.address (을)를 전자 메일로 전송해 주세요.

  • <mysql-alta@elistas.net> 스페인어의 메일링 리스트

    이 리스트에 subscribe mysql your@e-mail.address (을)를 전자 메일로 전송해 주세요.

1.7.1.2. 질문 또는 버그의 보고

버그 리포트 또는 질문을 투고하기 전에, 이하를 가 주세요.

  • 다음의 장소에서 MySQL 의 온라인 메뉴얼을 검색한다. http://www.mysql.com/doc/ 메뉴얼은, 항상 최신 상태로 해 두기 위해서, 새롭게 발견된 문제에 대한 해결책에 의해서 빈번히 갱신되고 있다.문제에 대한 해결책이 새로운 버젼에 벌써 짜넣어지고 있을 가능성이 높기 때문에, 변경 이력에 관한 부록(http://www.mysql.com/doc/en/News.html )(은)는 특히 편리하다.

  • 버그 데이타베이스(http://bugs.mysql.com/ )(을)를 검색하고, 버그가 벌써 보고/ 해결되고 있는지 어떤지를 확인한다.

  • 다음의 장소에서 MySQL 메일링 리스트의 어카이브(archive)를 검색한다. http://lists.mysql.com/

  • 또,http://www.mysql.com/search/ (을)를 사용하고,http://www.mysql.com/ 에 있다 Web 페이지 모든 것(메뉴얼을 포함한다)을 검색할 수도 있다.

메뉴얼이나 어카이브(archive)로 회답을 찾아낼 수 없었던 경우, 로컬의 MySQL 의 전문가와 함께 조사해 주세요.그런데도 질문에 대한 회답을 찾아낼 수 없었던 경우는, 당사에 문의하기 전에, 다음의 섹션에 기재되어 있는 가이드 라인에 따라서 MySQL 메일링 리스트에 메일을 전송해 주세요.

1.7.1.3. 버그 또는 문제를 보고하는 방법

당사의 버그 데이타베이스는 공개되고 있으므로, 모든 유저가 http://bugs.mysql.com/ 그리고 참조 및 검색할 수 있습니다.시스템에 로그인하면, 새로운 리포트를 입력할 수도 있습니다.

적절한 버그 리포트를 작성하려면 인내가 필요합니다만, 최초로 올바르게 작성해 두면, 당사에 있어서도 유저 자신에 있어서도 시간의 절약이 됩니다.버그의 상세한 시험대를 포함한 적절한 버그 리포트의 경우, 다음의 릴리스로 버그가 수정될 가능성이 매우 높아집니다.이 섹션에서는, 당사에 있어서 너무, 또는 전혀 도움이 되지 않는 작업에 유저가 시간을 소비하지 않아도 되도록(듯이), 리포트를 올바르게 작성하는 방법을 설명합니다.

버그 리포트(또는 문제에 관한 리포트)의 생성에는 mysqlbug 스크립트를 사용하는 것을 추천합니다.mysqlbug (은)는,scripts 디렉토리(소스 디스트리뷰션) 및 MySQL 인스톨 디렉토리하의 bin 디렉토리(바이너리 디스트리뷰션)에 있습니다.mysqlbug (을)를 사용할 수 없는 경우에서도(Windows (을)를 사용하고 있는 경우 등), 이 섹션에 기록되고 있는 필요한 정보 모든 것을 리포트에 기재할 필요가 있습니다(가장 중요한 것은, operating system의 설명과 MySQL 버젼입니다).

mysqlbug 스크립트를 사용하면, 이하의 정보의 대부분을 자동적으로 확인할 수 있으므로, 간단하게 리포트를 생성할 수 있습니다.다만, 중요한 정보가 부족한 경우는, 그 정보를 메세지에 추가해 주세요.이 섹션을 잘 읽고, 여기에 적어져 모든 정보를 리포트에 기재해 주세요.

할 수 있으면,MySQL 서버의 최신의 제품판 또는 개발판을 사용해 문제를 테스트하고 나서 투고해 주세요.누구나가 기재되어 있는 시험대로 mysql test < script (을)를 사용하는 것만으로 버그를 재현하거나 버그 리포트에 포함되어 있는 쉘 또는 Perl 스크립트를 실행하거나 할 수 있도록(듯이) 할 필요가 있습니다.

버그 데이타베이스(http://bugs.mysql.com/ )에 투고된 모든 버그는, 다음의 MySQL 릴리스로 수정 또는 문서화 됩니다.소규모의 코드의 변경만으로 문제를 수정할 수 있는 경우는, 당사에서도 문제를 수정하는 패치를 투고합니다.

버그를 보고하는 장소는 통상,http://bugs.mysql.com/ 입니다.

MySQL 그리고 중대한 시큐러티 버그를 찾아냈을 경우는,<security@mysql.com> 에 전자 메일을 전송해 주세요.

재현 가능한 버그 리포트가 있는 경우, 버그 데이타베이스(http://bugs.mysql.com/ )에 보고해 주세요.이 경우도, 우선 mysqlbug 스크립트를 실행하고, 시스템에 관한 정보를 확인하는 것을 추천합니다.재현 가능한 버그는, 다음의 MySQL 릴리스로 수정될 가능성이 높아집니다.

다른 문제를 보고하는 경우는,MySQL 메일링 리스트의 어느쪽이든을 사용해 주세요.

정보가 너무 많은 메세지에 대응할 수 있습니다만, 너무 적은 메세지에 대응할 수 없습니다.많은 경우, 문제의 원인을 알 수 있고 있다고 생각, 세부를 중요하지 않다고 생각하기 위해, 사실을 생략 해 버립니다.기재할지를 헤매었을 때는, 기재하는 것을 추천합니다.최초로 충분한 정보를 기재하지 않았기(위해)때문에 재차 질문하고, 회답을 기다리지 않으면 안 되게 되는 것보다도, 리포트에 몇 줄기를 추가하는 것이, 아득하게 시간이 절약될 뿐만 아니라, 번거롭지는 않습니다

버그 리포트로 가장 자주 있는 잘못은,(a) 사용하고 있다 MySQL 디스트리뷰션의 버젼 번호를 기재하고 있지 않는,(b) MySQL 서버가 인스톨 되고 있는 플랫폼의 설명(플랫폼의 종류 및 버젼 번호를 포함한다)이 충분하지 않다고 하는 것입니다.이것은 매우 중요한 정보이므로, 대부분의 경우, 이 정보가 기재되지 않은 버그 리포트는 도움이 되지 않습니다.`` 이 기능을 사용할 수 없는 것은 왜입니까?'' 그렇다고 하는 질문을 받는 일이 자주 있습니다.그 경우, 요구한 기능이 그 MySQL 버젼에 실장되어 있지 않거나, 리포트에 기재되어 있는 버그가 새롭다 MySQL 버젼으로 벌써 수정되어 있거나 하는 일이 있습니다.에러가 플랫폼 의존인 경우도 있습니다.그러한 경우, operating system나 플랫폼의 버젼 번호를 모르고 문제를 수정하는 것은 거의 불가능합니다.

또, 컴파일러가 문제에 관련하고 있는 경우는, 컴파일러에 관한 정보도 기재해 주세요.유저가 컴파일러의 버그를 찾아내면,MySQL 관련의 문제이다고 생각하는 일이 자주 있습니다.대부분의 컴파일러는 항상 개발중이므로, 버젼 마다 개량되고 있습니다.문제가 컴파일러에 관련하는 것일지를 판단하려면 , 사용하고 있는 컴파일러를 알 필요가 있습니다.컴파일에 관한 모든 문제는 버그라고 봐, 적당 보고해 주세요.

문제에 관한 적절한 설명이 버그 리포트에 기재되어 있으면, 가장 효과적입니다.그 때문에, 문제로 연결된 모든 조작의 적절한 예를 들어 문제 자체를 상세하게 기술해 주세요.가장 효과적인 리포트는, 버그나 문제를 재현하는 방법을 나타내는 상세한 예가 기재된 것입니다. See 항E.1.6. 「테이블이 파손했을 경우에 시험대를 작성한다」 .

프로그램으로 에러 메세지가 생성되었을 경우, 그 메세지를 리포트에 기재하는 것이 매우 중요합니다.프로그램을 사용하는 어카이브(archive)로부터 정보를 검색하려고 하는 경우, 보고된 에러 메세지가 프로그램으로 생성된 것과 정확하게 일치하고 있는 것이 효과적입니다(대문자 소문자의 차이에도 주의해 주세요).에러 메세지를 기억하는 것이 아니라, 메세지 전체를 리포트에 카피해 붙여 주세요.

MyODBC 에 관한 문제가 있는 경우,MyODBC 트레이스 파일을 생성해, 리포트 모두 송신해 주세요. See 항11.2.7. 「MyODBC 에 관한 문제의 보고」 .

리포트를 읽는 유저의 대부분이 80 자리수 디스플레이를 사용합니다.따라서,mysql 커멘드 라인 툴을 사용해 리포트 또는 샘플을 생성할 때 , 그러한 디스플레이의 유효한 폭을 넘는 출력에 대해서는,--vertical 옵션(또는 \G 스테이트먼트 종단 기호)를 사용할 필요가 있습니다(예를 들어,EXPLAIN SELECT 스테이트먼트의 경우.이 섹션의 후술의 샘플을 참조).

리포트에는 이하의 정보를 기재해 주세요.

  • 사용하고 있다 MySQL 디스트리뷰션의 버젼 번호(MySQL 버젼 4.0.12 등).실행하고 있는 버젼을 확인하려면 ,mysqladmin version (을)를 실행한다.mysqladmin (은)는,MySQL 인스톨 디렉토리하의 bin 디렉토리에 있다.

  • 문제가 발생한 머신의 제조원과 모델.

  • operating system의 이름과 버젼.대부분의 operating system에서는, 이 정보를 취득하려면 ,Unix 커멘드 uname -a (을)를 실행한다.Windows (을)를 사용하고 있는 경우, 이름과 버젼 번호를 취득하려면 , 통상 `` 마이 컴퓨터'' 아이콘을 더블 클릭 해,`` 헬프/ 버젼 정보'' 메뉴를 풀다운 한다.

  • 메모리(실메모리와 가상 메모리)의 양이 관련하기도 한다.관련하고 있다고 생각되는 경우는, 이러한 값을 기재한다.

  • MySQL 소프트웨어의 소스 디스트리뷰션을 사용하고 있는 경우, 사용하고 있는 컴파일러의 이름과 버젼 번호가 필요하다.바이너리 디스트리뷰션을 사용하고 있는 경우는, 디스트리뷰션명이 필요하다.

  • 컴파일시에 문제가 발생했을 경우, 정확한 에러 메세지, 및 에러가 발생한 파일내의 문제가 있는 코드 부근의 몇 줄기의 문맥을 기재한다.

  • mysqld 하지만 정?~ 했을 경우,mysqld 의 크래쉬의 원인이 된 쿼리도 보고할 필요가 있다.통상, 로그를 유효하게 해 mysqld (을)를 실행하면, 이것을 검출할 수 있다. See 항E.1.5. 「mysqld 에 있어서의 에러의 원인을 로그 파일을 사용해 특정한다」 .

  • 데이타베이스 테이블이 문제에 관련하고 있는 경우,mysqldump --no-data db_name tbl_name1 tbl_name2 ... (으)로부터의 출력을 기재한다.이것을 실시하는 것은 매우 간단하지만, 데이타베이스내의 테이블에 관한 정보를 취득하는 강력한 방법이다.이 정보는, 발생한 상황과 같은 상황을 재현할 때에 도움이 된다.

  • SELECT 스테이트먼트의 속도에 관한 버그나 문제에 대해서는, 반드시 EXPLAIN SELECT ... 의 출력과 적어도 SELECT 스테이트먼트에 의해서 생성된 레코드의 수를 기재할 필요가 있다.또, 관련하는 각 테이블의 SHOW CREATE TABLE tbl_name (으)로부터의 출력도 기재한다.발생한 상황을 설명하는 정보가 상세하다(정도)만큼, 적확한 회답을 얻을 수 있을 가능성이 높아진다.다음은, 매우 적절한 버그 리포트의 예이다(당연한 일이면서,mysqlbug 스크립트를 사용해 투고된 것이다).

    mysql 커멘드 라인 툴을 사용해 실행한 샘플(출력폭이 80 자리수 디스플레이 장치의 출력폭을 넘는 스테이트먼트에의 \G 스테이트먼트 종단 기호의 사용에 주의)

    mysql> SHOW VARIABLES;
mysql> SHOW COLUMNS FROM ...\G
<SHOW COLUMNS
(으)로부터의 출력>
mysql> EXPLAIN SELECT ...\G
       <EXPLAIN
(으)로부터의 출력>
mysql> FLUSH STATUS;
mysql> SELECT ...;
       <
쿼리의 실행에 필요로 한 시간을 포함한,
       SELECT
(으)로부터의 간략한 출력>
mysql> SHOW STATUS;
       <SHOW STATUS
(으)로부터의 출력>

  • mysqld 의 실행중에 버그 또는 문제가 발생했을 경우, 그 이상을 재현하는 입력 스크립트를 제공한다.이 스크립트에는, 필요한 원시 파일을 포함할 필요가 있다.스크립트에 의해서 재현되는 상황이 실제로 발생한 상황에 가까운 만큼, 효과적이다.재현 가능한 시험대를 작성할 수 있는 경우는, 우선적으로 처리되도록(듯이) http://bugs.mysql.com/ 에 그 시험대를 투고한다.

    스크립트를 제공할 수 없는 경우는, 적어도 mysqladmin variables extended-status processlist (으)로부터의 출력을 메일에 기재하고, 시스템의 동작에 관한 정보를 제공할 필요가 있다.

  • 몇 줄기에서는 시험대를 재현할 수 없는 경우나, 테스트 테이블이 너무 커서 메일링 리스트에 송신할 수 없는 경우(10 레코드를 넘는 테이블),mysqldump (을)를 사용해 테이블을 덤프 해, 문제를 설명한다 README 파일을 작성할 필요가 있다.

    tar (와)과 gzip 또는 zip (을)를 사용해 파일의 압축 어카이브(archive)를 작성해,ftp (을)를 사용해 그 어카이브(archive)를 ftp://support.mysql.com/pub/mysql/secret/ 에 전송 한다.그 후, 버그 데이타베이스(http://bugs.mysql.com/ )에 문제를 입력한다.

  • MySQL 서버로 쿼리에 의해서 올바르지 않은 결과가 생성되었다고 생각하는 경우, 결과 뿐만이 아니라, 올바르다고 생각하는 결과와 그 생각의 근거를 나타내는 설명도 기재한다.

  • 문제의 샘플을 제공할 때 , 새로운 이름을 사용하는 것보다도, 실제의 상황으로 사용하고 있는 변수명이나 테이블명등을 사용하는 것이 적절하다.문제가, 변수나 테이블의 이름에 관련하고 있을 가능성이 있기 때문에 있다.이러한 케이스는 거의 없다고 생각되지만, 후회하는 것보다도 안전책을 취해야 하는 것이다.결국, 실제의 상황에 근거한 샘플을 제공하는 것이 유저에게 있어서 간단한 것과 동시에, 당사에 있어서도 효율적이다.데이터를 다른 유저에게 공개하고 싶지 않은 경우는,ftp (을)를 사용해 ftp://support.mysql.com/pub/mysql/secret/ 에 전송 할 수 있다.데이터가 실제로 최고 기밀이며, 당사에도 공개하고 싶지 않은 경우는, 다른 이름을 사용한 샘플을 제공할 수도 있지만, 이것은 마지막 선택사항이다.

  • 가능한 경우, 관련하는 프로그램의 모든 옵션을 기재한다.예를 들어,mysqld demon를 개시할 때에 사용한 옵션이나 MySQL 클라이언트 프로그램의 실행에 사용한 옵션을 기재한다.mysqld ,mysql (와)과 같은 프로그램의 옵션이나 configure 스크립트의 옵션은 많은 경우, 회답에의 단서가 되어, 매우 중요하다.이것들을 기재하는 것은, 결코 쓸데 없지 않다.Perl (이)나 PHP 등의 모듈을 사용하고 있는 경우는, 그러한 버젼 번호도 기재한다.

  • 질문이 특권 시스템에 관련하는 경우,mysqlaccess 의 출력,mysqladmin reload 의 출력, 및 접속하려고 했을 때에 표시된 모든 에러 메세지를 기재한다.권한을 테스트할 때 , 우선 mysqlaccess (을)를 실행한다.그 후,mysqladmin reload version (을)를 실행해, 문제가 발생한 프로그램에 접속한다.mysqlaccess (은)는,MySQL 인스톨 디렉토리하의 bin 디렉토리에 있다.

  • 버그의 패치를 작성했을 경우, 그것을 포함한다.다만, 당사는 패치만을 필요로 하고 있는 것은 아니다.패치에 의해서 수정되는 버그를 나타내는 시험대등이 필요한 정보가 기재되지 않은 경우, 당사는 그 패치를 사용하지 않는다.당사가 패치에 관련하는 문제를 찾아내는 경우도 있으면, 패치를 전혀 이해할 수 없는 경우도 있다.그러한 경우는, 패치를 사용할 수 없다.

    패치의 목적을 정확하게 확인할 수 없는 경우, 당사는 그 패치를 사용하지 않는다.이 경우, 시험대가 도움이 되게 된다.발생할 가능성이 있는 모든 상황이 패치에 의해서 처리되는 것을 나타낼 필요가 있다.패치가 기능하지 않는 경계선 케이스가 발견되었을 경우(그것이 보기 드문 케이스에서도), 그 패치는 도움이 되지 않을 가능성이 있다.

  • 무엇이 버그인지, 그 버그가 왜 발생하는지, 그 버그가 무엇에 관련하는지를 추측하는 것은, 통상, 실수이다.MySQL 팀조차도, 최초로 디버거를 사용하지 않고 그러한 일을 추측하고, 버그의 실제의 원인을 특정할 수 없다.

  • 유저 자신으로 문제를 해결하려고 한 것을 다른 유저가 알도록(듯이), 참조 설명서나 메일 어카이브(archive)를 확인한 것을 버그 리포트에 기재한다.

  • 해석 에러 하지만 발생했을 경우, 구문을 상세하게 확인할 필요가 있다.구문에 문제가 발견되지 않았던 경우는, 사용하고 있는 구문이 현재의 버젼의 MySQL 서버로 서포트되어 있지 않을 가능성이 매우 높다.현재의 버젼을 사용하고 있는 경우, 사용하고 있는 구문이 http://www.mysql.com/doc/ 의 메뉴얼로 다루어지지 않으면, 그 쿼리는 MySQL 서버로 서포트되어 있지 않다.그 경우는, 스스로 구문을 실장하는지,<licensing@mysql.com> 에 전자 메일을 송신하고, 그 구문을 실장하도록(듯이) 의뢰 할 수 밖에 없다.

    사용하고 있는 구문이 메뉴얼로 다루어지고 있어도, 낡은 버젼의 MySQL 서버를 사용하고 있는 경우는,MySQL 의 변경 이력으로 구문이 실장되었던 시기를 확인할 필요가 있다.이 경우는, 새로운 버젼의 MySQL 서버에 업그레이드 하는 방법이 있다. See 부록 D. MySQL Change History .

  • 데이터가 망가져 있는 점이 문제인 경우나, 특정의 테이블에 액세스 했을 때에 에러가 발생했을 경우,myisamchk 또는 CHECK TABLE (와)과 REPAIR TABLE (을)를 사용하고, 우선 테이블을 체크하고 나서, 수복을 시도할 필요가 있다. See 장 4. 데이타베이스 관리 .

  • 테이블이 빈번히 망가지는 경우, 그 문제가 발생하는 상황과 이유를 특정할 필요가 있다.이 경우,mysql-data-directory/'hostname'.err 파일에, 발생한 문제에 관한 정보가 격납되고 있는 일이 있다.See 항4.10.1. 「에러 로그」 .이 파일내의 관련하는 정보를 버그 리포트에 기재한다.통상, 갱신의 도중에 mysqld 하지만 정?~ 되지 않는 이상mysqld 에 의해서 테이블이 파괴되는 것은 없다 .mysqld 하지만 정?~ 한 원인이 특정되면, 당사는 그 문제의 해결책을 아득하게 간단하게 제공할 수 있다. See 항A.1. 「문제의 원인을 찔러?~ 방법」 .

  • 가능한 경우, 최신 버젼의 MySQL 서버를 다운로드해 인스톨 해, 이것에 의해서 문제가 해결될지를 확인한다.MySQL 소프트웨어의 모든 버젼이 상세하게 테스트되고 있기 때문에, 문제 없게 동작할 것이다.모두에 있어 최대한의 하위 호환성이 확보되고 있기 때문에,MySQL 의 버젼을 문제 없게 바꿀 수 있으면 당사는 확신하고 있다. See 항2.2.4. 「사용해야 할 MySQL 의 버젼」 .

서포트 계약을 맺고 있는 고객은, 다른 유저가 같은 문제에 조우하고 있는지 어떤지(또, 그 문제가 해결되고 있는지 어떤지)를 확인하기 위해서 해당하는 메일링 리스트에 버그 리포트를 투고할 뿐만 아니라, 우선적으로 처리되도록(듯이) <mysql-support@mysql.com> 에도 투고해 주세요.

MyODBC 에 있어서의 버그의 보고에 대해서는, 항11.2.4. 「MyODBC 에 관한 문제를 보고하는 방법」 (을)를 참조해 주세요.

일반적인 문제에 대한 해결책에 대해서는, 부록 A. 문제와 일반적인 에러 (을)를 참조해 주세요.

메일링 리스트가 아니고, 개인 앞으로 회답이 송신되었을 경우, 문제의 해결에 도움이 된 회답이 다른 유저에게도 도움이 되도록(듯이), 회답을 요약해 메일링 리스트에 송신하는 것이 에티켓이다고 생각합니다.

1.7.1.4. 메일링 리스트로 질문에 회답할 때의 가이드 라인

다수의 유저에게 있어서 흥미롭다고 생각되는 회답에 대해서는, 질문한 개인에게 직접 답장하는 것이 아니라, 메일링 리스트에 투고할 수 있습니다.그 경우, 원의 투고자 이외의 유저에게도 도움이 되도록(듯이), 일반적인 회답을 하도록 해 주세요.리스트에 투고할 때 , 회답이 전의 회답과 중복 하고 있지 않는 것을 확인해 주세요.

원래의 메세지 전체를 인용하는 것이 아니라, 질문의 중요한 부분을 회답에 요약해 주세요.

HTML 모드가 온이 되어 있는 브라우저로부터 메일 메세지를 투고하지 말아 주세요.많은 유저는 브라우저로 메일을 읽지 않습니다.

1.7.2. IRC (인터넷 릴레이 채팅)의 MySQL 커뮤니티

다양한 MySQL 메일링 리스트에 가세해IRC ( 인터넷 릴레이 채팅 )에도 경험 풍부한 코?~ 니티가 있습니다.이하는, 당사가 현재 파악하고 있는 가장 뛰어난 네트워크/ 채널입니다.

  • freenode (서버에 대해서는,http://www.freenode.net/ (을)를 참조)

    • #mysql MySQL 에 관한 질문이 중심이지만, 다른 데이타베이스나 SQL 에 관한 질문도 받아들이고 있다.

    • #mysqlphp MySQL+PHP 그렇다고 하는 일반적인 조합해에 관한 질문.

    • #mysqlperl 이제(벌써) 1 개의 일반적인 조합해MySQL+Perl 에 관한 질문.

  • EFnet (서버에 대해서는,http://www.efnet.org/ (을)를 참조)

    • #mysql MySQL 에 관한 질문.

IRC 네트워크에 접속한다 IRC 클라이언트 소프트웨어를 찾고 있는 경우는,X-Chat (http://www.xchat.org/ )(을)를 참조해 주세요.X-Chat (GPL 라이센스)는,Unix 및 Windows 플랫폼에서 사용할 수 있습니다.


1.8. MySQL 의 표준에의 준거

이 섹션에서는,MySQL (와)과 ANSI/ISO SQL 표준과의 관련을 설명합니다.MySQL 서버에는 SQL 표준에 대한 다수의 확장 기능이 있습니다.여기에서는, 그러한 확장 기능과 사용 방법을 설명합니다.또,MySQL 서버에 부족한 기능과 차이를 해결하는 방법에 관한 정보도 제공합니다.

당사의 목표는, 정당한 이유 없고, 모든 용도에 대해서 MySQL 서버의 편리한 사용을 제한하지 않는 것입니다.생각할 수 있는 모든 용도에 대응하는 개발을 실시하는 자원이 갖추어져 있지 않아도, 새로운 영역에서 MySQL 서버를 사용하려고 하고 있는 유저를 항상 기쁘게 원조해, 어드바이스를 제공합니다.

제품에 관한 당사의 주된 목표의 1 개는, 속도나 신뢰성을 희생하는 일 없이,SQL-99 표준에의 준거를 향해서 개발을 계속하는 것입니다.대부분의 유저에게 있어서 MySQL 서버가 큰폭으로 사용하기 쉽게 된다면, 당사는 SQL 에 대한 확장 기능이나 SQL 이외의 기능의 서포트를 적극적으로 추가합니다(MySQL 서버 4.0 의 새롭다 HANDLER 인터페이스는, 이 방침의 일례입니다. See 항6.4.9. 「HANDLER 구문」 .)

당사는, 부하가 높다 Web/ 로그의 사용과?~ 션크리티칼인 연중무휴의 사용의 양쪽 모두에 대응하기 위해서, 트랜잭션 데이터 베이스와 비트랜잭션 데이터 베이스의 서포트를 계속합니다.

MySQL 서버는, 소규모의 컴퓨터 시스템으로 중 규모의 데이타베이스(1,000 만 ~ 1 억레코드, 또는 1 테이블 근처 약 100 MB )(을)를 사용하는 것을 목적으로 해 최초부터 설계되었습니다.테라바이트 규모의 데이타베이스에서도 적절히 동작하는 것과 동시에, 소형 디바이스나 짜넣어 용도에 의해 적합한 소규모의 MySQL (을)를 컴파일 할 수 있도록(듯이),MySQL 서버의 확장을 계속합니다.MySQL 서버의 컴팩트한 설계에 의해서, 소스 트리로 경합 하는 일 없이, 이러한 어느 방향도 실현될 수 있습니다.

현시점에서는, 리얼타임의 서포트는 생각하고 있지 않습니다(다만, replication 서비스를 사용하고, 벌써 많은 일을 실행할 수 있습니다).

데이타베이스 클러스터의 서포트는, 새로운 스토리지 엔진의 실장에 의해서 2004 연내에 개시될 예정입니다.

데이터 베이스 서버로의 XML 서포트의 제공을 생각하고 있습니다.

1.8.1. MySQL 하지만 준거하는 표준

엔트리 레벨은 SQL-92 입니다.ODBC 레벨은 0 ~ 3.51 입니다.

코드의 속도와 품질을 희생하는 일 없이,SQL-99 표준을 완전하게 서포트하는 것을 목표로 하고 있습니다.

1.8.2. ANSI 모드로의 MySQL 의 실행

--ansi 또는 --sql-mode=ANSI 옵션을 지정해 mysqld (을)를 개시하면,MySQL 서버의 동작은 다음과 같이 바뀝니다.

  • || (은)는,OR 의 동의어가 아니고, 문자열 연결 연산자가 된다.

  • ‘" ＇ (은)는, 문자열 인용부호가 아니고,MySQL 서버의 ‘` ＇ 인용부호와 같이 식별자 인용부호로서 다루어진다.‘` ＇ (은)는,ANSI 모드에서도 식별자의 인용에 사용할 수 있다.즉, 문자열의 인용에 이중 인용부호를 사용할 수 없다.이중 인용부호를 사용하면, 식별자로서 해석되어 버리기 때문에 있다.

  • 함수명과 ‘( ＇ 의 사이에 스페이스를 몇 개에서도 배치할 수 있다.이것에 의해서, 모든 함수명이 예약어(reserved word)로서 다루어진다.그 때문에, 예약어(reserved word)가 되고 있는 데이타베이스명, 테이블명, 또는 컬럼명에 액세스 하려면 , 그러한 이름을 인용부호로 둘러쌀 필요가 있다.예를 들어,USER() 함수가 있으므로,mysql 데이타베이스내의 user 테이블의 이름과 그 테이블내의 User 컬럼의 이름이 예약어(reserved word)가 되기 위해, 이것들을 인용부호로 둘러싸지 않으면 안 된다.

    SELECT "User" FROM mysql."user";

  • REAL (은)는,DOUBLE 의 동의어가 아니고,FLOAT 의 동의어가 된다.

  • 디폴트의 트랜잭션(transaction) 분리 레벨은,SERIALIZABLE 된다. See 항6.7.6. 「SET TRANSACTION 구문」 .

  • 필드 일람에 없다 GROUP BY 그리고 필드/ 식을 사용할 수 있다.

ANSI 모드로 서버를 실행하는 것은, 이하의 옵션을 지정해 서버를 기동하는 것과 같은 것입니다.

--sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY
--transaction-isolation=SERIALIZABLE

MySQL 4.1 그럼, 다음의 2 개의 스테이트먼트로 같은 동작을 실현할 수 있습니다.

SET GLOBAL TRANSACTION ISOLATION LEVEL SERIALIZABLE;
SET GLOBAL sql_mode =
  "REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY";

MySQL 4.1.1 그럼,sql_mode 옵션을 다음과 같이 사용할 수도 있습니다.

SET GLOBAL sql_mode="ansi";

이 경우,sql_mode 변수의 값은,ANSI 모드에 관련하는 모든 옵션으로 설정됩니다.결과를 확인하려면 , 이하를 실행합니다.

mysql> SET GLOBAL sql_mode="ansi";
mysql> SELECT @@GLOBAL.sql_mode;
+---------------------------------------------------------------------------+
| @global.sql_mode                                                          |
+---------------------------------------------------------------------------+
| REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY |
+---------------------------------------------------------------------------+
1 row in set (0.00 sec)

1.8.3. SQL-92 표준에 대한다 MySQL 확장 기능

MySQL 서버에는, 다른 SQL 데이타베이스에는 없는 확장 기능이 있습니다.그러한 확장 기능을 사용했을 경우, 다른 SQL 서버에 코드를 이식할 수 없게 될테니 주의해 주세요.경우에 따라서는,MySQL 확장 기능을 포함한 코드를 기술해도,/*! ... */ 형식의 코멘트를 사용하는 것으로 이식할 수 있습니다.그 경우,MySQL 서버에서는, 다른 MySQL 스테이트먼트와 같게 코멘트내의 코드가 해석 및 실행됩니다만, 다른 SQL 서버에서는 확장 기능이 무시됩니다.다음에 예를 나타냅니다.

SELECT /*! STRAIGHT_JOIN */ col_name FROM table1,table2 WHERE ...

'!' 의 뒤로 버젼 번호를 추가하면,MySQL 버젼이, 사용되고 있는 버젼 번호이?~ 의 경우에게만, 구문이 실행됩니다.

CREATE /*!32302 TEMPORARY */ TABLE t (a INT);

즉, 버젼 3.23.02 이?~ (을)를 사용하고 있는 경우,MySQL 서버로 TEMPORARY 키워드가 사용됩니다.

이하는,MySQL 확장 기능의 일람입니다.

  • 필드형 MEDIUMINT ,SET ,ENUM , 및 다양한 BLOB 및 TEXT 형.

  • 필드 속성 AUTO_INCREMENT ,BINARY ,NULL ,UNSIGNED , 및 ZEROFILL .

  • 모든 문자열 비교는, 디폴트에서는 대문자와 소문자를 구별하지 않고, 현재의 캐릭터 세트(디폴트에서는 ISO-8859-1 Latin1 )(으)로 결정할 수 있던 소트순서로 행해진다.이것을 변경하려면 ,BINARY 속성을 지정해 컬럼을 선언하는지,BINARY 캐스트를 사용하고,MySQL 서버 호스트로 사용된다 ASCII 의 순서에 따라서 비교를 하도록(듯이) 할 필요가 있다.

  • MySQL 서버에서는, 각 데이타베이스는 MySQL 데이터 디렉토리하의 디렉토리에, 데이타베이스내의 테이블은 데이타베이스 디렉토리내의 파일명에 맵 된다.

    이것에는, 다음과 같은 의미가 있다.

    • 대부분의 Unix 시스템과 같이 파일명으로 대문자와 소문자가 구별되는 operating system상의 MySQL 서버에서는, 데이타베이스명 및 테이블명은 대문자와 소문자를 구별한다. See 항6.1.3. 「이름에 있어서의 케이스 의존」 .

    • 데이타베이스명, 테이블명, 인덱스명, 컬럼명, 또는 앨리어스(alias)명을 숫자로 시작할 수 있다(다만, 숫자만으로부터 완성되는 이름을 사용할 수 없다).

    • 표준의 시스템 커멘드를 사용하고, 테이블의 백업, 이름의 변경, 이동, 삭제, 및 카피를 실시할 수 있다.예를 들어, 테이블의 이름을 변경하려면 , 테이블에 대응한다 .MYD ,.MYI , 및 .frm 파일의 이름을 변경한다.

  • SQL 스테이트먼트로,db_name.tbl_name 구문을 사용하고, 다양한 데이타베이스내의 테이블에 액세스 할 수 있다.같은 기능을 갖추었다 SQL 서버도 있지만, 이것은 유저 스페이스 (으)로 불린다.MySQL 서버에서는,CREATE TABLE ralph.my_table...IN my_tablespace (와)과 같은 테이블 스페이스는 서포트되지 않는다.

  • 수치 컬럼으로 LIKE (을)를 사용할 수 있다.

  • SELECT 스테이트먼트로의 INTO OUTFILE 및 STRAIGHT_JOIN 의 사용. See 항6.4.1. 「SELECT 구문」 .

  • SELECT 스테이트먼트로의 SQL_SMALL_RESULT 옵션.

  • 테이블의 결합 방법에 관한 설명을 취득한다 EXPLAIN SELECT .

  • 인덱스명, 필드의 프리픽스상의 인덱스, 및 CREATE TABLE 스테이트먼트로의 INDEX 또는 KEY 의 사용. See 항6.5.3. 「CREATE TABLE 구문」 .

  • CREATE TABLE (으)로의 TEMPORARY 또는 IF NOT EXISTS 의 사용.

  • list 에 복수의 요소가 있다 COUNT(DISTINCT list) 의 사용.

  • ALTER TABLE 스테이트먼트로의 CHANGE col_name ,DROP col_name ,DROP INDEX ,IGNORE , 또는 RENAME 의 사용. See 항6.5.4. 「ALTER TABLE 구문」 .

  • RENAME TABLE 의 사용. See 항6.5.5. 「RENAME TABLE 구문」 .

  • ALTER TABLE 스테이트먼트로의 복수의 ADD ,ALTER ,DROP , 또는 CHANGE 마디의 사용.

  • DROP TABLE (으)로의 키워드 IF EXISTS 의 사용.

  • 1 개의 DROP TABLE 스테이트먼트로 복수의 테이블을 파기할 수 있다.

  • UPDATE 및 DELETE 스테이트먼트의 ORDER BY 및 LIMIT 절.

  • INSERT INTO ... SET col_name = ... 구문.

  • INSERT 및 REPLACE 스테이트먼트의 DELAYED 절.

  • INSERT ,REPLACE ,DELETE , 및 UPDATE 스테이트먼트의 LOW_PRIORITY 절.

  • LOAD DATA INFILE 의 사용.많은 경우, 이 구문은 Oracle 의 LOAD DATA INFILE (와)과 호환성이 있다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

  • ANALYZE TABLE ,CHECK TABLE ,OPTIMIZE TABLE , 및 REPAIR TABLE 스테이트먼트.

  • SHOW 스테이트먼트. See 항4.6.8. 「SHOW 구문」 .

  • ‘' ＇ 뿐만이 아니고,‘" ＇ 또는 ‘' ＇ 그리고 문자열을 둘러쌀 수 있다.

  • 이스케이프 문자 ‘\ ＇ 의 사용.

  • SET 스테이트먼트. See 항5.5.6. 「SET 구문」 .

  • GROUP BY 부에서, 선택한 모든 컬럼의 이름을 열거할 필요가 없다.이것에 의해, 극히 일부에서는 있지만, 극히 일반적인 쿼리의 퍼포먼스가 향상한다. See 항6.3.7. 「GROUP BY 마디로 사용하는 함수와 수식자」 .

  • GROUP BY 그리고 ASC 및 DESC (을)를 지정할 수 있다.

  • 다른 SQL 환경을 사용하고 있던 유저에게 알기 쉽게,MySQL 서버에서는 다수의 함수의 앨리어스(alias)가 서포트되고 있다.예를 들어, 모든 문자열 함수로, 표준의 SQL 구문과 ODBC 구문의 양쪽 모두가 서포트되고 있다.

  • MySQL 서버에서는,C 프로그라?~ 그 언어와 같이,|| 및 && 연산자가 논리 OR 및 AND (을)를 의미한다고 해석된다.MySQL 서버에서는,|| (와)과 OR , 및 && (와)과 AND (은)는 동의어이다.이 뛰어난 구문을 위해서,MySQL 서버에서는, 문자열의 연결에 표준 SQL-99 의 || 연산자를 사용할 수 없다.대신에,CONCAT() (을)를 사용한다.CONCAT() 에는 인수를 몇 개에서도 사용할 수 있으므로,|| 연산자의 사용을 MySQL 서버로 변환하는 것은 간단하다.

  • CREATE DATABASE 또는 DROP DATABASE . See 항6.5.1. 「CREATE DATABASE 구문」 .

  • % 연산자는 MOD() 의 동의어이다.따라서,N % M 하 MOD(N,M) (와)과 같다.% (은)는,C 프로그래머를 대상으로 하고, 또 PostgreSQL (와)과의 호환성을 확보하기 위해서 서포트되고 있다.

  • = ,<> ,<= ,< ,>= ,> ,<< ,>> ,<=> ,AND ,OR , 또는 LIKE 연산자를,SELECT 스테이트먼트의 FROM 의 좌측의 컬럼 비교로 사용할 수 있다.다음에 예를 나타낸다.

    mysql> SELECT col1=1 AND col2=2 FROM tbl_name;

  • LAST_INSERT_ID() 함수. See 항11.1.3.32. 「mysql_insert_id() 」 .

  • REGEXP 및 NOT REGEXP 확장 정규 표현 연산자.

  • 1 개 또는 복수의 인수를 사용한다 CONCAT() 또는 CHAR() (MySQL 서버에서는, 이러한 함수는 인수를 몇 개에서도 사용할 수 있다).

  •             BIT_COUNT()
,CASE
,ELT()
,FROM_DAYS()
,FORMAT()
,IF()
,PASSWORD()
,ENCRYPT()
,MD5()
,ENCODE()
,DECODE()
,PERIOD_ADD()
,PERIOD_DIFF()
,TO_DAYS()
, 또는
            WEEKDAY()
함수.

  • 부분 문자열을 삭제한다 TRIM() 의 사용.SQL-99 그럼,1 개의 문자 밖에 삭제할 수 없다.

  • GROUP BY 함수 STD() ,BIT_OR() ,BIT_AND() ,BIT_XOR() , 및 GROUP_CONCAT() . See 항6.3.7. 「GROUP BY 마디로 사용하는 함수와 수식자」 .

  • DELETE + INSERT 의 대신의 REPLACE 의 사용. See 항6.4.7. 「REPLACE 구문」 .

  • FLUSH ,RESET , 및 DO 스테이트먼트.

  • 다음과 같이,:= (을)를 사용해 스테이트먼트내에서 변수를 설정할 수 있다.

    SELECT @a:=SUM(total),@b=COUNT(*),@a/@b AS avg FROM test_table;
SELECT @t1:=(@t2:=1)+@t3:=4,@t1,@t2,@t3;

1.8.4. MySQL (와)과 SQL-92 (와)과의 차이

MySQL 서버를 ANSI SQL 표준(SQL-92/SQL-99 ) 및 ODBC SQL 표준에 준거한 것으로 하는 것을 목표로 하고 있습니다만, 이하와 같이,MySQL 서버가 다른 동작을 나타내는 일이 있습니다.

  • VARCHAR 형태의 컬럼에서는, 값이 격납될 때에 후속의 스페이스가 삭제된다. See 항1.8.6. 「MySQL 의 기존의 에러와 설계상의 문제」 .

  • CHAR 형태의 컬럼이 자동적으로 VARCHAR 형태의 컬럼으로 변경되는 일이 있다. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 .

  • 테이블을 삭제해도, 테이블의 특권이 자동적으로 삭제되지 않는다.테이블의 특권을 취소하려면 , 명시적으로 REVOKE (을)를 발행할 필요가 있다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

우선 순위에 따라서 늘어놓을 수 있던, 새로운 확장 기능이 MySQL 서버에 추가되는 시기를 나타내는 일람에 대해서는, 온라인의 MySQL TODO 리스트(http://www.mysql.com/doc/en/TODO.html )(을)를 참조해 주세요.이것은, 이 메뉴얼의 TODO 리스트의 최신판입니다. See 항1.6. 「MySQL 의 향후(TODO )」 .

1.8.4.1. 서브 쿼리

MySQL 버젼 4.1 그럼, 서브 쿼리와 파생 테이블(이름이 없는 뷰)이 서포트되고 있습니다. See 항6.4.2. 「서브 쿼리 구문」 .

4.1 보다 전의 버젼의 MySQL 에 대해서는, 결합등의 방법에 의해서, 대부분의 서브 쿼리를 다시 기술할 수 있습니다. See 항6.4.2.11. 「초기의 MySQL 버젼에 맞춘 서브 쿼리의 개서」 .

1.8.4.2. SELECT INTO TABLE

MySQL 서버에서는,Sybase SQL 확장 기능 SELECT ... INTO TABLE ... (은)는 아직 서포트되고 있지 않습니다.대신에,SQL-99 구문 INSERT INTO ... SELECT ... 하지만 서포트되고 있습니다.이것들은, 기본적으로는 같습니다. See 항6.4.3.1. 「INSERT ... SELECT 구문」 .

INSERT INTO tblTemp2 (fldID)
       SELECT tblTemp1.fldOrder_ID
       FROM tblTemp1 WHERE tblTemp1.fldOrder_ID > 100;

또,SELECT INTO OUTFILE... 또는 CREATE TABLE ... SELECT (을)를 사용할 수도 있습니다.

1.8.4.3. 트랜잭션(transaction)와 아트?~ 크오페레이션

MySQL 서버(버젼 3.23-max 및 모든 버젼 4.0 이?~ )에서는,InnoDB 및 BDB 트랜잭션(transaction) 스토리지 엔진 그리고 트랜잭션(transaction)가 서포트되고 있습니다.InnoDB (은)는, 완전하게 ACID 에 준거하고 있습니다. See 장 7. MySQL 의 테이블형 .

MySQL 서버의 그 외의 비트랜잭션(transaction) 테이블형(MyISAM 등)은,`` 아트?~ 크오페레이션'' (으)로 불리는 다른 데이터 정합성의 패러다임(paradigm)에 따릅니다.트랜잭션(transaction)의 관점에서는,MyISAM 테이블은 사실상, 항상 AUTOCOMMIT=1 모드로 동작한다고 말할 수 있습니다.아트?~ 크오페레이션에서는 많은 경우, 퍼포먼스의 높이에 적합한 정합성이 확보됩니다.

양쪽 모두의 패러다임(paradigm)를 서포트한다 MySQL 서버에서는, 유저는 아트?~ 크오페레이션의 속도를 필요로 하는지, 어플리케이션으로 트랜잭션(transaction) 기능을 사용할 필요가 있는지를 선택할 수 있습니다.이 선택은, 테이블 마다 실시할 수 있습니다.

대부분의 경우, 트랜잭션(transaction) 테이블형과 비트랜잭션(transaction) 테이블형의 어느 쪽을 선택할까의 결정적 수단이 되는 것은 퍼포먼스입니다.트랜잭션(transaction) 테이블의 경우, 훨씬 큰 메모리와 디스크 영역이 필요하고,CPU 의 오버헤드도 커집니다.그러나,InnoDB (와)과 같은 트랜잭션(transaction) 테이블형에는 특유의 기능도 다수 있습니다.MySQL 서버의 모듈 설계에 의해서, 이러한 다양한 스토리지 엔진 모든 것을 동시에 사용할 수 있으므로, 다양한 요건에 맞추고, 모든 조건으로 최적인 퍼포먼스를 확보하는 것이 가능합니다.

그러나,MySQL 서버의 기능을 사용하고, 비트랜잭션(transaction)의 MyISAM 테이블에서도 엄밀한 정합성을 확보하려면 어떻게 하면 좋은 것일까요.또, 비트랜잭션(transaction) 테이블의 기능은 트랜잭션(transaction) 테이블형에 어떻게 대항할 수 있는 것입니까.

  1. 트랜잭션(transaction) 패러다임(paradigm)에서는, 중대한 상황으로 COMMIT (은)는 아니고 ROLLBACK 의 호출해에 의존하도록(듯이) 어플리케이션이 작성되고 있는 경우, 트랜잭션(transaction)가 편리하다.또, 트랜잭션(transaction)에서는, 완료하고 있지 않는 갱신이나 실패한 활동이 데이타베이스에 코?~ 트 될 것은 없다.서버에는 자동 롤백(rollback)를 실시할 기회가 주어져 데이타베이스는 보호된다.

    MySQL 서버에서는, 대부분의 경우, 갱신전에 간단한 체크를 짜넣거나 데이타베이스의 부정합을 체크하고, 부정합이 발생했을 경우에는 자동적으로 수복 또는 경고하는 간단한 스크립트를 실행하거나 하는 것으로, 발생할 가능성이 있는 문제를 해결할 수 있다.MySQL 로그를 사용하거나 다른 로그를 1 개추가하거나 하는 것만으로, 통상, 데이터의 정합성이 없어지는 일 없이, 완전하게 테이블을 수복할 수 있다.

  2. 대부분의 경우, 중요한 트랜잭션(transaction) 갱신은 아트?~ 크인 갱신에 다시 기술할 수 있다.통상, 트랜잭션(transaction)에 의해서 해결되는 정합성의 문제는 모두,LOCK TABLES 또는 아트?~ 크인 갱신을 사용해 해결할 수 있다.이것에 의해서, 서버가 자동적으로 정?~ 그러자(면) 하는, 트랜잭션 데이터 베이스 시스템과 공통되는 문제가 회피된다.

  3. 서버가 정?~ 그러자(면), 트랜잭션(transaction) 시스템에서도 데이터가 없어질 가능성이 있다.개개의 시스템의 차이는, 데이터가 없어질 가능성이 있는 시간이 얼마나 짧을것인가 라고 하는 점 뿐이다.100% 안전한 시스템은 없고,`` 충분히 안전'' 뿐이다.가장 안전한 트랜잭션 데이터 베이스 시스템이라고 말해진다 Oracle 조차도, 그러한 상황에서는 데이터가 없어지는 일이 있다고 보고되고 있다.

    MySQL 서버를 안전하게 사용하려면, 트랜잭션(transaction) 테이블을 사용할지에 관계없이, 백업을 작성해, 바이너리 로그를 온으로 하면 좋은 것뿐이다.이것에 의해, 다른 트랜잭션 데이터 베이스 시스템으로 가능한 것 같게, 어떠한 상황으로부터도 리커버리 할 수 있다.사용하는 데이타베이스 시스템에 관계없이, 어떠한 경우에서도 백업을 작성하는 것이 바람직한 것은 당연하다.

트랜잭션(transaction) 패러다임(paradigm)에는 장점과 단점이 있습니다.다수의 유저 및 어플리케이션 개발자는, 정?~ 하지만 발생한다, 또는 정?~ 하지만 필요한 문제에 관한 코드화의 용이함에 의지하고 있습니다.그러나, 아트?~ 크오페레이션의 패러다임(paradigm)에 익숙하지 않거나, 트랜잭션(transaction)가 자세하다고 하는 경우에서도, 비트랜잭션(transaction) 테이블의 속도가, 가장 고속으로 최적으로 조정된 트랜잭션(transaction) 테이블의 속도의 3 배로부터 5 배도 빠르다고 하는 장점을 생각해 보세요.

정합성이 가장 중요한 상황에서는,MySQL 서버는, 비트랜잭션(transaction) 테이블에서도 트랜잭션(transaction) 레벨의 신뢰성과 정합성을 제공합니다.LOCK TABLES (을)를 사용하고 테이블을 잠그면, 정합성 체크를 할 때까지, 모든 갱신이 연기됩니다.독해 락(기입 락의 역)만이 설정되어 있는 경우, 독해와 삽입은 계속해 실시할 수 있습니다.새롭게 삽입한 레코드는, 독해가 락 되고 있는 클라이언트에는, 독해 락이 해제될 때까지 표시되지 않습니다.INSERT DELAYED (을)를 사용하면, 락이 해제될 때까지 삽입을 로컬 큐에 넣을 수 있어 클라이언트는 삽입이 완료할 때까지 대기할 필요는 없습니다. See 항6.4.3.2. 「INSERT DELAYED 구문」 .

여기서 말한다 `` 아트?~ 크'' (이)란, 마법과 같은 것이 아닙니다.개개의 갱신의 실행중은, 다른 유저가 그것을 방해할 수 없게 하는 것과 동시에, 자동 롤백(rollback)(별로 주위를 기울이지 않았던 경우에, 트랜잭션(transaction) 테이블로 행해지는 일이 있습니다)를 하지 않게 할 수 있다고 할 뿐입니다.또,MySQL 서버에서는, 더티 리드를 하기도 없습니다.

비트랜잭션(transaction) 테이블을 사용할 때의 테크닉은, 이하대로입니다.

  • LOCK TABLES (을)를 사용하고, 통상은 트랜잭션(transaction)를 필요로 하는 루프를 코드화할 수 있다.그 때문에, 실행중에 레코드를 갱신하는 커서가 불필요하다.

  • ROLLBACK (을)를 사용하지 않게, 이하의 방법을 사용할 수 있다.

    1. LOCK TABLES ... (을)를 사용하고, 액세스 하는 모든 테이블을 잠근다.

    2. 조건을 테스트한다.

    3. 모두에게 문제가 없으면, 갱신한다.

    4. UNLOCK TABLES (을)를 사용하고, 락을 해제한다.

    이것은 통상, 롤백(rollback)을 할 가능성이 있는 트랜잭션(transaction)를 사용하는 것보다도, 훨씬 빠른 방법이다.다만, 갱신의 도중에 스레드가 정?~ 되었을 경우는, 이 방법에서는 대응할 수 없다.그 경우, 모든 락이 해제되지만, 일부의 갱신이 실행되어 있지 않을 가능성이 있다.

  • 함수를 사용하고,1 회의 조작으로 레코드를 갱신할 수도 있다.다음과 같은 테크닉을 사용하면, 매우 효율적인 어플리케이션을 취득할 수 있다.

    • 현재의 값에 관련해 필드를 변경한다.

    • 실제로 변경된 필드만을 갱신한다.

    예를 들어, 고객 정보에 대해서 갱신을 실시하는 경우, 변경된 고객 데이터만을 갱신해, 변경된 데이터, 또는 변경된 데이터에 의존하는 데이터가 원래의 레코드와 비교해 변경되어 있지 않은 것만을 테스트한다.변경된 데이터의 테스트는,UPDATE 스테이트먼트로 WHERE 마디를 사용해 행해진다.레코드가 갱신되지 않았던 경우,''Some of the data you have changed has been changed by another user.'' 그렇다고 하는 메세지가 클라이언트에 표시된다.그 경우, 윈도우에 원래의 레코드와 새로운 레코드를 표시하고, 사용할 필요가 있는 고객 레코드의 버젼을 유저가 결정할 수 있도록(듯이) 한다.

    이것에 의해서, 컬럼 락 과 유사하지만, 현재의 값에 관련하는 값을 사용하고, 컬럼의 일부만이 갱신되는 점으로, 실제는 컬럼 락보다 뛰어난 기능이 실현된다.즉, 일반적인 UPDATE 스테이트먼트는 다음과 같이 된다.

    UPDATE tablename SET pay_back=pay_back+125;

UPDATE customer
  SET
    customer_date='current_date',
    address='new address',
    phone='new phone',
    money_he_owes_us=money_he_owes_us-125
  WHERE
    customer_id=id AND address='old address' AND phone='old phone';

    이것은 매우 효율적으로, 다른 클라이언트가 pay_back 또는 money_he_owes_us 컬럼의 값을 변경하고 있어도 동작한다.

  • 많은 경우, 유저는, 복수의 테이블의 일의의 식별자를 관리하기 위해서 ROLLBACK (이)나 LOCK TABLES (을)를 사용하고 있었다.이것은,AUTO_INCREMENT 컬럼 및 SQL 함수 LAST_INSERT_ID() 또는 C API 함수 mysql_insert_id() (을)를 사용하는 것으로, 아득하게 효율적으로 처리할 수 있다. See 항11.1.3.32. 「mysql_insert_id() 」 .

    통상, 행 레벨의 락을 코드화할 수 있다.상황에 따라서는 실제로 이것이 필요해서,InnoDB 테이블에서는 행 레벨의 락이 서포트되고 있다.MyISAM 그럼, 테이블로 플래그 컬럼을 사용해, 이하와 같은 일을 실행할 수 있다.

    UPDATE tbl_name SET row_flag=1 WHERE id=ID;

    레코드가 발견되어, 원의 레코드로 row_flag 하지만 벌써 1 (이)가 아니게 되고 있었을 경우,MySQL (은)는, 영향을 받은 레코드가 수라고 해 1 (을)를 돌려준다.

    MySQL 서버에서는 전술의 쿼리가 다음과 같이 변경된다고 생각할 수 있다.

    UPDATE tbl_name SET row_flag=1 WHERE id=ID AND row_flag <> 1;

1.8.4.4. Stored Procedure와 Trigger

Stored Procedure는, 버젼 5.0 개발 트리로 실장됩니다. See 항2.3.4. 「개발 소스 트리로부터의 인스톨」 .

이 시도는 SQL-99 에 근거하는 것으로,Oracle PL/SQL 에 유사한(다만, 같지는 않습니다) 기본 구문을 사용합니다.이것에 가세해 외부 언어로 훅 한다 SQL-99 체제도 실장합니다.

Stored Procedure는, 서버로 컴파일 해, 격납할 수 있다 SQL 커멘드세트입니다.이것을 하면, 클라이언트는 쿼리 전체의 재발행을 반복할 필요가 없고, Stored Procedure를 참조할 수 있습니다.그 결과, 쿼리를 한 번 해석하는 것만으로 끝나, 서버와 클라이언트간에 송신되는 정보가 적게 되므로, 전체적인 퍼포먼스가 향상합니다.또, 서버에 함수의 라이브러리를 작성하는 것으로, 개념 레벨을 높일 수도 있습니다.다만, 서버측에서 행해지는 작업이 증가해 클라이언트(어플리케이션) 측에서 행해지는 작업이 적게 되므로, Stored Procedure에 의해서 데이터 베이스 서버 시스템의 부하가 높아집니다.

Trigger는,MySQL 버젼 5.1 그리고 실장될 예정입니다.Trigger는, 실질적으로는 Stored Procedure의 일종으로, 특정의 이벤트가 발생하면 불려 갑니다.예를 들어, 트랜잭션(transaction) 테이블에서 레코드가 삭제될 때마다 Trigger 되는 Stored Procedure나, 모든 트랜잭션(transaction)가 삭제되면, 고객 테이블에서 대응하는 고객을 자동적으로 삭제하는 Stored Procedure를 설정할 수 있습니다.

1.8.4.5. 외부 키

MySQL 서버 3.23.44 이?~ 그럼,CASCADE ,ON DELETE , 및 ON UPDATE (을)를 포함한 외부 키 제약의 체크가 InnoDB 테이블로 서포트되고 있습니다. See 항7.5.5.2. 「FOREIGN KEY 제약」 .

다른 테이블형에 대해서는,MySQL 서버에서는 현재,CREATE TABLE 커멘드로 FOREIGN KEY 구문만이 해석됩니다만, 이 정보는 사용/ 보존되지 않습니다.가까운 시일내에, 이 정보가 테이블 사양 파일에 보존되어mysqldump 및 ODBC 에 의해서 취득할 수 있도록, 이 실장을 확장할 예정입니다.한층 더 그 후에는,MyISAM 테이블에 대해서도 외부 키 제약을 실장할 예정입니다.

SQL 의 외부 키는 테이블의 결합에 사용되는 것이 아니라, 참조 정합성(외부 키 제약)의 체크와 확보에 사용됩니다.SELECT 스테이트먼트를 사용해 복수의 테이블에서 결과를 얻으려면 , 다음과 같이 테이블을 결합합니다.

SELECT * FROM table1,table2 WHERE table1.id = table2.id;

See 항6.4.1.1. 「JOIN 구문」 . See 항3.6.6. 「외부 키의 사용」 .

제약으로서 사용할 때, 어플리케이션에 의해서 MyISAM 테이블에 적절한 순서로 레코드가 삽입되는 경우는, 외부 키를 사용할 필요는 없습니다.

MyISAM 테이블에 대해서는,ON DELETE 하지만 실장되어 있지 않다고 하는 문제에 대처하려면 , 외부 키가 있는 테이블에서 레코드를 삭제할 때에 적절한 DELETE 스테이트먼트를 어플리케이션에 추가합니다.실제, 이 방법은 외부 키를 사용하는 경우와 같은 정도 간단하고(경우에 따라서는, 이 분이 간단합니다), 이식성은 그것보다 훨씬 높아집니다.

MySQL 서버 4.0 그럼, 복수 테이블의 삭제를 사용하고,1 개의 커멘드로 다수의 테이블에서 레코드를 삭제할 수 있습니다. See 항6.4.5. 「DELETE 구문」 .

ON DELETE ... (을)를 포함하지 않는다 FOREIGN KEY 구문은 많은 경우, 자동 WHERE 마디를 생성한다 ODBC 어플리케이션에 의해서 사용됩니다.

외부 키를 잘못해 사용하면, 심각한 문제가 발생하는 일이 있을테니 주의해 주세요.적절히 사용했을 경우에서도, 외부 키의 서포트는, 참조 정합성의 문제를 해결하는데 있어서 도움이 되는 것은 있어도, 중요한 해결책으로는 되지 않습니다.

외부 키를 사용하는 메리트는, 이하대로입니다.

  • 관계가 적절히 설계되고 있는 경우, 외부 키 제약에 의해서, 프로그래머가 데이타베이스로 부정합을 일으키는 것이 적게 된다.

  • 연쇄 갱신 및 삭제를 사용하면, 클라이언트 코드를 단순화 할 수 있다.

  • 적절히 설계된 외부 키르르는, 테이블간의 관계의 기술에 도움이 된다.

외부 키를 사용하는 디메리트는, 이하대로입니다.

  • 키 관계를 설계하는데 있어서 범하기 쉬운 실수에 의해서, 순환 룰, 연쇄 삭제의 부적절한 조합등이 심각한 문제가 생기는 일이 있다.

  • 데이타베이스 레벨로의 여분의 체크에 의해서, 퍼포먼스에 영향이 생긴다.그 때문에, 일부의 주요한 상용 어플리케이션에서는, 어플리케이션 레벨로 이 논리가 코드화 되고 있다.

  • DBA 에 있어서, 개개의 테이블의 백업이나 restore가 매우 곤란하게 되어, 경우에 따라서는 불가능하게 되는 복잡한 관계의 위상기하학을 작성하는 것은 좀처럼 없다.

1.8.4.6. 뷰

뷰는 현재 실장중에서,MySQL 서버 버젼 5.0 또는 5.1 그리고 실장됩니다.

지금까지,MySQL 서버는, 어플리케이션 작성자가 데이타베이스의 사용을 완전하게 제어할 수 있는 어플리케이션이나 Web 시스템으로 가장 많이 사용되어 왔습니다.그러나, 시간의 경과와 함께 용도는 바뀌어 오고 있어 뷰를 중요시하는 유저가 증가하고 있습니다.

이름이 없는 뷰( 파생 테이블 ,SELECT 의 FROM 절내의 서브 쿼리)는, 버젼 4.1 그리고 벌써 실장되고 있습니다.

뷰는,1 개의 테이블과 같이 일련의 관계(테이블)에 유저가 액세스 할 수 있도록(듯이) 해, 유저의 액세스를 그것에만 제한하는 경우에 편리합니다.또, 뷰를 사용하고, 레코드(특정의 테이블의 부분집합)에의 액세스를 제한할 수도 있습니다.MySQL 서버에는 고도의 특권 시스템이 있으므로, 컬럼에게의 액세스를 제한하는 경우에는 뷰를 사용할 필요는 없습니다. See 항4.3. 「일반적인 시큐러티 관련 사항과 MySQL 액세스 제어 시스템」 .

다수의 DBMS 그럼, 뷰에 대한 갱신을 실시할 수 없습니다.대신에, 개개의 테이블에 대해서 갱신을 실행할 필요가 있습니다.당사는 뷰의 실장을 설계할 때에, 이론적으로 갱신 가능한 모든 뷰는 실제로도 갱신 가능하지 않으면 안 된다고 하는, RDB 시스템에 관한 `` 콧드의 룰 #6'' 에 SQL 의 범위내에서 가능한 한 준거하는 것을 목표로 하고 있습니다.

1.8.4.7. 코멘트의 개시 기호로서의 '--'

일부의 다른 SQL 데이타베이스에서는, 코멘트를 개시하기 위해서 '--' 하지만 사용됩니다.MySQL 서버에서는, 코멘트 개시 문자로서 ‘# ＇ 하지만 사용됩니다.또,C 코멘트 스타일의 /* this is a comment */ (을)를 사용할 수도 있습니다. See 항6.1.6. 「코멘트 구문」 .

MySQL 서버 버젼 3.23.3 이?~ 그럼,'--' 코멘트 스타일을 사용할 수 있습니다.다만, 코멘트의 뒤에 스페이스(또는, 개행등의 제어 문자)가 계속 되는 경우에 한정합니다.이것은, 이 코멘트 스타일에 의해서,!payment! 의 값을 자동적으로 삽입하는 다음과 같은 코드를 사용한 자동 생성의 SQL 쿼리로 다수의 문제가 발생하고 있었기 때문입니다.

UPDATE tbl_name SET credit=credit-!payment!

payment 의 값이 음수의 경우, 어떻게 될까를 생각해 보세요.SQL 그럼 1--1 하지만 유효해서, 코멘트를 '--' 그리고 개시할 수 있도록 했을 경우의 영향은 중대합니다.

MySQL 서버 버젼 3.23.3 이?~ 그리고 코멘트의 이 방법의 실장을 사용했을 경우,1-- This is a comment (은)는 실제로 안전합니다.

이제(벌써) 1 개의 안전한 기능은,mysql 커멘드 라인 클라이언트에 의해서 '--' 그리고 시작되는 모든 행이 삭제된다고 하는 것입니다.

이하의 정보는,3.23.3 보다 전의 버젼의 MySQL (을)를 실행하고 있는 경우에게만 관련합니다.

텍스트 파일의 SQL 프로그램에 '--' 코멘트가 포함되어 있는 경우, 다음의 커멘드를 사용할 필요가 있습니다.

shell> replace " --" " #" < text-file-with-funny-comments.sql \
         | mysql database

통상의 다음의 커멘드 대신에, 상기의 커멘드를 사용해 주세요.

shell> mysql database < text-file-with-funny-comments.sql

또, 커멘드 파일을 `` 그 자리에서'' 편집하고,'--' 코멘트를 ‘# ＇ 코멘트로 변경할 수도 있습니다.

shell> replace " --" " #" -- text-file-with-funny-comments.sql

다음의 커멘드로 바탕으로 되돌려 주세요.

shell> replace " #" " --" -- text-file-with-funny-comments.sql

1.8.5. MySQL 에 있어서의 제약의 처리

MySQL 그럼 트랜잭션(transaction) 테이블과 롤백(rollback)이 유효하지 않은 비트랜잭션(transaction) 테이블의 양쪽 모두를 사용할 수 있으므로,MySQL (와)과 다른 데이타베이스와는 제약의 처리가 다소 다릅니다.

에러시에 롤백(rollback) 할 수 없는 비트랜잭션(transaction) 테이블로 다수의 레코드를 갱신했을 경우의 처리를 실장하지 않으면 안됩니다.

기본적인 개념은, 검출 가능한 에러를 컴파일시에 생성해, 받은 에러로부터 실행시에 리커버리 한다고 하는 것입니다.대부분의 경우에 이것이 실장되고 있습니다만, 아직 모두에 임해서 실장되고 있는 것은 아닙니다. See 항1.6.4. 「가까운 장래에 계획되고 있는 신기능」 .

MySQL 에 있어서의 기본적인 옵션은, 도중에 스테이트먼트를 안?~ 하는지, 문제로부터 리커버리 하기 위해서 할 수 있는 한 일을 실시해서, 처리를 속행할까입니다.

다양한 종류의 제약에 관한 문제를 이하로 설명합니다.

1.8.5.1. PRIMARY KEY/UNIQUE KEY 제약

통상, 주키, 유니크 키, 또는 외부 키 위반을 일으키는 레코드의 삽입/ 갱신 (을)를 실시하려고 하면, 에러가 발생합니다.InnoDB (와)과 같은 트랜잭션(transaction) 스토리지 엔진을 사용하고 있는 경우,MySQL 그럼 트랜잭션(transaction)가 자동적으로 롤백(rollback) 됩니다.비트랜잭션(transaction) 스토리지 엔진을 사용하고 있는 경우,MySQL (은)는 에러가 발생한 레코드로 정?~ 해, 나머지의 레코드는 미처리대로 됩니다.

이 문제를 해결하기 위해서,MySQL 그럼, 키 위반이 발생할 가능성이 있는 대부분의 커멘드에 IGNORE 지시문의 서포트를 추가했습니다(INSERT IGNORE ... 등).이 경우, 키 위반은 무시되어 계속다음의 레코드가 처리됩니다.MySQL 에 있어서의 처리에 관한 정보를 취득하려면 ,mysql_info() API 함수를 사용합니다.MySQL 버젼 4.1 그럼 SHOW WARNINGS 커멘드를 사용합니다. See 항11.1.3.30. 「mysql_info() 」 . See 항4.6.8.9. 「SHOW WARNINGS | ERRORS 」 .

현시점에서는, 외부 키가 서포트되고 있는 것은 InnoDB 테이블만입니다.See 항7.5.5.2. 「FOREIGN KEY 제약」 .MyISAM 테이블로의 외부 키 서포트는,MySQL 5.0 소스 트리로 실장될 예정입니다.

1.8.5.2. NOT NULL 및 DEFAULT 값제약

비트랜잭션(transaction) 테이블을 간단하게 처리할 수 있도록,MySQL 의 모든 필드에는 디폴트치가 설정되어 있습니다.

NOT NULL 컬럼에 있어서의 NULL (이)나 수치 컬럼에 있어서의 너무 큰 수치와 같이 ' 올바르지 않다' 값을 컬럼에 삽입했을 경우,MySQL 그럼 에러를 생성하는 것이 아니라, 컬럼을 ' 최적 가능치' (으)로 설정합니다.수치에 대해서는,0 , 사용 가능한 최소치, 또는 사용 가능한 최대치입니다.문자열에 대해서는, 공백 문자열, 또는 컬럼내에서 사용 가능한 최장 문자열입니다.

즉,NULL 값을 사용할 수 없는 컬럼에 NULL (을)를 격납하려고 하면,0 또는 '' (공백 문자열)(이)가 대신에 격납됩니다.단일 레코드의 삽입에 대해서는, 이 후자의 동작을 -DDONT_USE_DEFAULT_FIELDS 컴파일 옵션을 사용해 변경할 수 있습니다.See 항2.3.3. 「일반적인 configure 옵션」 .이 경우, 비 NULL 값을 필요로 하는 모든 컬럼에 대해 명시적으로 값을 지정하지 않는 한,INSERT 스테이트먼트로 에러가 생성됩니다.

전술의 룰의 이유는, 쿼리의 실행이 개시되기 전에 이러한 조건을 체크할 수 없기 때문입니다.복수의 레코드를 갱신한 다음에 문제가 발생했을 경우, 테이블형으로 서포트되어 있지 않을 가능성이 있기 위해, 단지 롤백(rollback) 할 수 없습니다.정?~ 그러자(면) 하는 옵션은, 이 경우, 갱신이 ' 미완료' 때문에, 최악의 시나리오가 될 가능성이 있으므로, 적절하지는 않습니다.' 할 수 있는 한 일을 실시해' , 아무것도 문제가 발생하고 있지 않는 것으로서 처리를 속행하는 것이 적절합니다.MySQL 5.0 그럼, 자동 필드 변환에 관한 경고와 트랜잭션(transaction) 테이블만을 사용하는 스테이트먼트로 허가되어 있지 않은 필드 할당을 했을 경우에 스테이트먼트를 롤백(rollback) 할 수 있는 옵션을 제공하는 것으로, 이것을 개선할 예정입니다.

이것은, 통상, 필드의 내용을 체크하기 위해서 MySQL (을)를 사용하는 것이 아니라, 어플리케이션으로 이것을 처리해야 하는 것을 의미합니다.

1.8.5.3. ENUM 및 SET 제약

MySQL 4.x 그럼,ENUM (은)는 실제의 제약이 아니고, 특정의 값세트만을 사용할 수 있는 필드를 격납하기 위한보다 효율적인 방법입니다.이것은,NOT NULL 하지만 받아들일 수 없는 것과 같은 이유에 의합니다. See 항1.8.5.2. 「NOT NULL 및 DEFAULT 값제약」 .

ENUM 필드에 올바르지 않은 값을 삽입했을 경우, 예약된 열거수 0 (으)로 설정되어 문자열 문맥에서는 공백 문자열로서 표시됩니다. See 항6.2.3.3. 「ENUM 형태」 .

SET 필드에 올바르지 않은 값을 삽입했을 경우, 그 값은 무시됩니다. See 항6.2.3.4. 「SET 형태」 .

1.8.6. MySQL 의 기존의 에러와 설계상의 문제

1.8.6.1. 그 후의 MySQL 버젼으로 수정되었다 3.23 의 에러

이하의 기존의 에러/ 버그는,MySQL 3.23 그럼 수정되고 있지 않습니다.이러한 수정에는, 보다 심각한 다른 버그를 일으킬 가능성이 있는 다수의 코드 변경이 관련하기 (위해)때문입니다.또, 이러한 버그는 ' 비치명적' 또는 ' 허용 범위' (으)로서 분류되고 있습니다.

  • 복수의 테이블에 대해서 LOCK TABLE (을)를 실행한 후, 다른 스레드가 테이블을 잠그려 하고 있는 동안에 같은 접속으로 그러한 테이블의 어느 쪽인가에 대해 DROP TABLE (을)를 실행했을 경우, 데드 록이 발생하는 일이 있다.다만, 관련하는 스레드의 모두에게 KILL (을)를 실행하는 것으로, 이 문제를 해결할 수 있다.4.0.12 그리고 수정이 끝난 상태.

  • 테이블중 한쪽이 하늘의 경우,SELECT MAX(key_column) FROM t1,t2,t3... 하지만 NULL (을)를 돌려주는 대신에, 컬럼의 최대치를 돌려준다.4.0.11 그리고 수정이 끝난 상태.

  • 락 되었다 HEAP 테이블로,WHERE (을)를 포함하지 않는다 DELETE FROM heap_table 하지만 동작하지 않는다.

1.8.6.2. MySQL 의 미해결의 버그와 설계상의 문제

이하의 기존의 문제는, 우선해 수정됩니다.

  • FLUSH TABLES WITH READ LOCK 에 의해서 CREATE TABLE 또는 COMMIT 하지만 블록 되지 않고, 테이블 및 바이너리 로그의 완전 백업을 실행하면, 바이너리 로그의 위치에 관한 문제가 발생한다.

  • BDB 테이블로의 ANALYZE TABLE 에 의해서,mysqld (을)를 재실행할 때까지 테이블을 사용할 수 없게 되는 일이 있다.이 문제가 발생했을 경우는,MySQL 에러 파일에 다음과 같은 에러가 생성된다.

    001207 22:07:56  bdb:  log_flush: LSN past current end-of-log

  • MySQL 그럼 FROM 부에서 외모를 사용할 수 있지만, 자동적으로 무시된다.에러를 생성하지 않는 이유는, 쿼리를 자동적으로 생성하는 많은 클라이언트로, 불필요한 경우에서도 FROM 부에 외모를 덧붙일 수 있기 때문에 있다.

  • 같은 쿼리내에서 다수의 RIGHT JOINS (을)를 연결했을 경우나 LEFT 및 RIGHT 결합을 조합했을 경우,LEFT 결합 전의 테이블 또는 RIGHT 결합 전의 테이블에 대해 NULL 행만이 생성되므로, 올바른 결과를 얻을 수 없는 것이 있다.이것은,FROM 부에 있어서의 외모의 서포트의 추가와 동시에,5.0 그리고 수정할 예정이다.

  • 멀티 스테이트먼트 트랜잭션(transaction)를 실행하고 있다 BDB 테이블에서는, 그러한 트랜잭션(transaction) 모든 것이 완료할 때까지 ALTER TABLE (을)를 실행하지 않는다(대부분의 경우, 트랜잭션(transaction)는 무시된다).

  • ANALYZE TABLE ,OPTIMIZE TABLE , 및 REPAIR TABLE 에 의해서,INSERT DELAYED (을)를 사용하고 있는 테이블로 문제가 발생하는 일이 있다.

  • LOCK TABLE ... 및 FLUSH TABLES ... (을)를 실행해도, 처리가 진행중의 미완료의 트랜잭션(transaction)가 테이블에 없다고는 할 수 없다.

  • BDB 테이블을 여는데 다소 시간이 걸린다.데이타베이스에 다수의 BDB 테이블이 있을 때,-A 옵션을 사용하고 있지 않는 경우나 rehash (을)를 사용하고 있는 경우, 데이타베이스상에서 mysql 클라이언트를 사용하는데 시간이 걸린다.이것은, 큰 테이블 캐쉬가 있는 경우에 특히 현저하다.

  • replication에서는 쿼리 레벨의 로그가 사용된다.즉, 마스터에 의해서, 실행된 쿼리가 바이너리 로그에 써진다.이것은 매우 빠르고, 컴팩트하고 효율적인 로그 방법이며, 대부분의 경우에 문제 없게 기능한다.실제로 발생한 예를 (들)물었던 적은 없지만, 데이터의 변경이 비결정론적, 즉 쿼리Optimizer의 판단으로 행해지도록(듯이) 쿼리가 설계되고 있는 경우(replication의 외부에서도, 통상은 적절한 방법이 아니다), 마스터 및 슬레이브의 데이터가 이론적으로 다를 가능성이 있다.예를 들어, 다음과 같은 경우이다.

    • AUTO_INCREMENT 컬럼에 제로 또는 NULL 값을 삽입한다 CREATE ... SELECT 또는 INSERT ... SELECT 스테이트먼트.

    • ON DELETE CASCADE 프롭퍼티가 설정된 외부 키가 있는 테이블에서 레코드를 삭제하는 경우의 DELETE .

    • 삽입되는 데이터에 중복 하는 키치가 있는 경우의 REPLACE ... SELECT ,INSERT IGNORE ... SELECT .

    이러한 쿼리 모두에게 결정론적 순서를 보증한다 ORDER BY 마디가 없는 경우뿐이다 .

    실제, 예를 들어,ORDER BY 하지만 없다 INSERT ... SELECT 의 경우,SELECT (은)는, 마스터 및 슬레이브로 Optimizer에 의해서 행해지는 선택에 따라서는, 다른 순서로 레코드를 돌려주는 일이 있다(그 결과, 레코드에 다른 랭크가 설정되어auto_increment 컬럼으로 다른 수를 취득하게 된다).마스터와 슬레이브로 쿼리가 달라 최적화되는 것은, 이하의 경우뿐이다.

    • 2 개의 쿼리에 의해서 사용되는 파일이, 정확하게는 같지 않다.예를 들어,OPTIMIZE TABLE 하지만 마스터 테이블에서는 실행되었지만, 슬레이브 테이블에서는 실행되지 않았던 경우 등이다(이것을 수정하기 위해서,MySQL 4.1.1 이?~ 그럼,OPTIMIZE ,ANALYZE , 및 REPAIR 하지만 바이너리 로그에 써진다).

    • 마스터와 슬레이브로 다른 스토리지 엔진에 테이블이 격납되고 있다(슬레이브와 마스터로 다른 스토리지 엔진을 사용할 수 있다.예를 들어, 슬레이브가 사용 가능한 디스크 영역이 적은 경우, 마스터에서는 InnoDB (을)를 사용해, 슬레이브에서는 MyISAM (을)를 사용할 수 있다).

    • MySQL 버퍼의 사이즈(key_buffer_size 등)이, 마스터와 슬레이브로 다르다.

    • 마스터와 슬레이브로 다르다 MySQL 버젼이 실행되고 있어 Optimizer의 코드가 이러한 버젼간에 다르다.

    또, 이 문제는,mysqlbinlog|mysql 에 의한 데이타베이스의 restore에도 영향을 미치는 일이 있다.

    모든 케이스로 이 문제를 회피하는 가장 간단한 방법은, 이러한 비결정론적인 쿼리에 ORDER BY 마디를 추가하고, 레코드가 항상 같은 순서로 격납/ 변경되도록(듯이) 하는 것이다.향후의 MySQL 버젼에서는, 필요에 따라서 자동적으로 ORDER BY 마디가 추가되도록(듯이) 할 예정이다.

이하의 기존의 문제는, 가까운 시일내에 수정됩니다.

  • 텐포라리테이불을 사용해 해결할 필요가 있는 쿼리로 RPAD 함수, 또는 최종적으로 우측으로 공백을 추가하는 다른 문자열 함수를 사용했을 경우, 모든 결과 문자열로 우측의 공백이 삭제된다.다음에, 이 쿼리의 예를 나타낸다.

    SELECT RPAD(t1.field1, 50, ' ') AS f2, RPAD(t2.field2, 50, ' ') AS f1 FROM table1 as t1 LEFT JOIN table2 AS t2 ON t1.record=t2.joinID ORDER BY t2.record;

    이 버그의 최종적인 결과는, 생성되는 필드의 우측의 공백을 취득할 수 없게 되는 것이다.

    이 동작은, 모든 버젼의 MySQL (으)로 보여진다.

    이 원인은, 텐포라리테이불로서 최초로 사용된다 HEAP 테이블로 VARCHAR 형태의 컬럼을 처리할 수 없는 것이다.

    이 동작은,4.1 시리즈의 몇개의 릴리스로 수정될 예정이다.

  • 테이블 정의 파일의 격납 방법을 위해서, 테이블명, 컬럼명, 또는 열거에 문자 255 (CHAR(255) )(을)를 사용할 수 없다.이것은, 새로운 테이블 정의 파일 형식이 도입되는 버젼 5.1 그리고 수정될 예정이다.

  • SET CHARACTER SET (을)를 사용했을 경우, 데이타베이스명, 테이블명, 및 컬럼명으로 변환된 문자를 사용할 수 없다.

  • LIKE ... ESCAPE 그리고 ESCAPE (와)과 함께 _ 또는 % (을)를 사용할 수 없다.

  • DECIMAL 형태의 컬럼에 다양한 형식(+01.00 ,1.00 ,01.00 )(으)로 숫자가 격납되고 있는 경우,GROUP BY 에 의해서 각 치가 다른 값으로 해서 보여지는 일이 있다.

  • WHERE 없이 DELETE FROM merge_table (을)를 사용하면, 테이블에 대한 매핑만이 소거되어 맵 된 테이블의 내용은 일절 삭제되지 않는다.

  • MIT-pthreads (을)를 사용했을 경우, 다른 디렉토리에 서버를 구축할 수 없다.이것에는 MIT-pthreads 의 변경이 필요해서, 이것을 수정할 예정은 없다. See 항2.3.6. 「MIT-pthreads 에 관한 주의 사항」 .

  • GROUP BY ,ORDER BY , 또는 DISTINCT 그리고 BLOB 값을 `` 확실히'' 사용할 수 없다.이러한 경우에 BLOB 값을 비교했을 경우, 최초의 max_sort_length 아르바이트(디폴트는 1024 )만이 사용된다.이것은,mysqld 의 -O max_sort_length 옵션을 사용해 변경할 수 있다.대부분의 경우의 회피책은,SELECT DISTINCT LEFT(blob,2048) FROM tbl_name (와)과 같이 부분 문자열을 사용하는 것이다.

  • BIGINT 또는 DOUBLE 그리고 계산이 실행된다(통상은 어느 쪽의 길이도 64 비트).취득하는 정도는 함수에 따라서 다르다.일반적인 룰로서 비트 함수는 BIGINT 정도,IF 및 ELT() 하 BIGINT 또는 DOUBLE 정도, 나머지는 DOUBLE 정도로 실행된다.비트 필드 이외에 붙어서는, 부호 없음의 긴 값이 63 비트(9223372036854775807 )보다 큰 값에 해결되는 경우, 그러한 값을 사용하지 않게 할 필요가 있다.MySQL 서버 4.0 그럼,3.23 에 비해 BIGINT 의 처리가 향상하고 있다.

  • BLOB 형태 및 TEXT 형태의 컬럼을 제외한 모든 문자열 컬럼으로, 취득시에 후속의 스페이스 모든 것이 자동적으로 삭제된다.CHAR 형태의 경우, 이것에는 문제는 없고,SQL-92 에 준거한 기능이라고 볼 수 있다.버그는,MySQL 서버로 VARCHAR 형태의 컬럼이와 같이 처리되는 점이다.

  • 1 개의 테이블에 ENUM 형태 및 SET 형태의 컬럼을 255 개까지 밖에 작성할 수 없다.

  • MySQL 그럼 현재,MIN() ,MAX() , 및 그 외의 집약 함수에 대하고,ENUM 형태와 SET 형태의 컬럼이 세트내의 문자열의 상대적인 위치가 아니고, 문자열치에 의해서 비교된다.

  • mysqld_safe 에 의해서,mysqld (으)로부터 mysqld 로그에 모든 메세지가 리디렉트 된다.이것에 관한 1 개의 문제로서mysqladmin refresh (을)를 실행하고 로그를 닫은 후, 한번 더 열렸을 경우,stdout 및 stderr 하지만 계속원의 로그에 리디렉트 되는 점이 있다.--log (을)를 광범위하게 사용하는 경우,'hostname'.log (은)는 아니고 'hostname'.err 에 로그가 기록되도록(듯이) mysqld_safe (을)를 편집하고, 원의 로그를 삭제해,mysqladmin refresh (을)를 실행하는 것으로, 원의 로그의 스페이스를 간단하게 해방할 수 있도록 할 필요가 있다.

  • UPDATE 스테이트먼트로, 컬럼이 왼쪽에서 오른쪽으로 갱신된다.갱신된 컬럼을 참조했을 경우, 원의 값은 아니고 갱신된 값을 취득한다.예를 들어, 다음과 같은 커멘드가 있다고 한다.

    mysql> UPDATE tbl_name SET KEY=KEY+1,KEY=KEY+1;

    이 경우,KEY 하 1 (이)가 아니고,2 에 의해서 갱신된다.

  • 1 개의 쿼리로 복수의 텐포라리테이불을 참조할 수 있지만, 특정의 텐포라리테이불을 여러 차례 참조할 수 없다.예를 들어, 다음의 쿼리는 동작하지 않는다.

    mysql> SELECT * FROM temporary_table, temporary_table AS t2;

  • RENAME 하지만,TEMPORARY 테이블, 또는 MERGE 테이블내에서 사용되고 있는 테이블로 동작하지 않는다.

  • 결합으로 ' 비표시의' 컬럼을 사용하고 있는 경우와 사용하고 있지 않는 경우로, Optimizer에 의해서 DISTINCT 하지만 달라 처리되는 일이 있다.결합에서는, 비표시의 컬럼은 결과의 일부로서 카운트 되지만(표시되어 있지 않은 경우도 마찬가지), 통상의 쿼리에서는, 비표시의 컬럼은 DISTINCT 비교에 관련하지 않는다.DISTINCT (을)를 실행했을 경우도 비표시의 컬럼이 비교되지 않게, 향후 이것을 변경할 예정이다.

    이 예는 이하대로이다.

    SELECT DISTINCT mp3id FROM band_downloads
       WHERE userid = 9 ORDER BY id DESC;

    및

    SELECT DISTINCT band_downloads.mp3id
       FROM band_downloads,band_mp3
       WHERE band_downloads.userid = 9
       AND band_mp3.id = band_downloads.mp3id
       ORDER BY band_downloads.id DESC;

    2 번째의 예의 경우,MySQL 서버 3.23.x 그럼, 결과 세트로 2 개의 같은 레코드를 취득하는 일이 있다(비표시의 id 컬럼이 다른 경우가 있기 위해).

    이 문제는, 결과에 ORDER BY 컬럼이 없는 쿼리만으로 발생한다.이것은,SQL-92 그럼 허가되어 있지 않다.

  • MySQL 서버에서는 트랜잭션(transaction)를 서포트하지 않기 위해(때문에) 데이터를 롤백(rollback) 할 수 없는 테이블형을 사용할 수 있으므로,MySQL 서버와 다른 SQL 서버에서는 동작이 다소 다르다.이것은 단지,MySQL 서버에서는 SQL 커멘드에 대해서 롤백(rollback)가 실행되지 않게 하기 위한(해)이다.이것은, 어플리케이션으로 컬럼치를 체크할 필요가 있을 때는 다소 불편한 경우가 있지만, 다른 방법에서는 매우 곤란한 최적화를 MySQL 서버로 실행할 수 있으므로, 실질적으로는 속도가 큰폭으로 향상한다.

    컬럼을 올바르지 않은 값으로 설정했을 경우, 롤백(rollback)를 하는 대신에, 컬럼에 취할 수 있는 값의 쳐 최적인 값 하지만 격납된다.

    • 수치 컬럼에 범위외의 값을 격납하려고 했을 경우, 사용 가능한 최소치 또는 최대치가 대신에 격납된다.

    • 수치 컬럼에 숫자 이외로 시작되는 문자열을 격납하려고 했을 경우,0 하지만 격납된다.

    • NULL 값을 사용할 수 없는 컬럼에 NULL (을)를 격납하려고 했을 경우,0 또는 '' (공백 문자열)(이)가 대신에 격납된다(다만, 이 동작은,-DDONT_USE_DEFAULT_FIELDS 컴파일 옵션을 사용해 변경할 수 있다).

    • MySQL 그럼,DATE 형태 및 DATETIME 형태의 컬럼에 올바르지 않은 일자치(2000-02-31 (이)나 2000-02-00 등)을 격납할 수 있다.그 생각은, 일자를 검증하는 것은 SQL 서버의 역할은 아니라고 하는 것이다.MySQL 그리고 일자를 격납해, 같은 일자를 정확하게 취득할 수 있는 경우, 그 일자는 격납된다.일자가 전혀 올바르지 않은(서버로 일자를 격납할 수 없다) 경우는, 특수한 일자치 0000-00-00 하지만 컬럼에 격납된다.

    • ENUM 형태의 컬럼을 서포트되어 있지 않은 값으로 설정했을 경우, 에러치이다 공백 문자열 (으)로 설정된다.수치의 경우는,0 (으)로 설정된다.

    • SET 형태의 컬럼을 서포트되어 있지 않은 값으로 설정했을 경우, 그 값은 무시된다.

  • 하늘세트를 돌려주는 쿼리로 PROCEDURE (을)를 실행했을 경우,PROCEDURE 에 의해서 컬럼이 변환되지 않는 것이 있다.

  • MERGE 형태의 테이블을 작성할 때에, 기본으로 되는 테이블의 형태에 호환성이 있을지가 체크되지 않는다.

  • MySQL 서버에서는 아직,NaN ,-Inf , 및 Inf 값을 배정도로 처리할 수 없다.이것들을 사용했을 경우, 데이터를 export 및 임포트 하려고 하면 문제가 발생한다.중간적인 해결책으로서NaN (을)를 NULL (가능한 경우),-Inf 및 Inf (을)를 각각 사용 가능한 최소 및 최대 배정도 값으로 변경할 필요가 있다.

  • ALTER TABLE (을)를 사용해 MERGE 테이블로 사용되고 있는 테이블에 UNIQUE 인덱스를 추가한 후,ALTER TABLE (을)를 사용해 MERGE 테이블에 통상의 인덱스를 추가하면, 일의가 아닌 낡은 키가 테이블에 존재하고 있었을 경우, 테이블로 키의 순서가 바뀐다.이것은, 중복 키를 가능한 한 빨리 검출할 수 있도록,ALTER TABLE 하지만 UNIQUE 키를 통상의 키의 전에 배치하기 위해(때문에)이다.

이하는,MySQL 의 초기의 버젼에 있어서의 기존의 버그입니다.

  • LOCK TABLES (을)를 사용해 락 되고 있는 다수의 테이블 중 1 개의 테이블로 DROP TABLE (을)를 실행했을 경우, 항스레드를 취득하는 일이 있다.

  • 이하의 경우, 코어덤프를 취득하는 일이 있다.

    • 지연 삽입 핸들러가 테이블에의 삽입을 보류하고 있는 경우.

    • WRITE (을)를 포함한다 LOCK table .

    • FLUSH TABLES .

  • MySQL 서버 버젼 3.23.2 보다 전은, 같은 키로 WHERE (을)를 사용해 키를 갱신했다 UPDATE 그리고 에러가 발생하는 일이 있었다.이것은, 그 키가 레코드의 검색에 사용되어 같은 레코드가 여러 차례 검출되는 일이 있었기 때문이다.다음에 예를 나타낸다.

    UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100;

    회피책은 다음과 같다.

    mysql> UPDATE tbl_name SET KEY=KEY+1 WHERE KEY+0 > 100;

    이것이 기능하는 것은,MySQL 서버에서는 WHERE 절내의 식에 인덱스가 사용되지 않기 때문이다.

  • MySQL 서버 버젼 3.23 보다 전은, 모든 수치형이 고정 소수점형 필드로서 다루어지고 있었다.그 때문에, 고정 소수점형 필드의 소수부 자리수를 지정해야 했다.모든 결과가, 정확한 소수부 자리수로 돌려주어지고 있었다.

플랫폼 고유의 버그에 대해서는, 컴파일 및 이식에 관한 섹션을 참조해 주세요. See 항2.3. 「MySQL 소스 디스트리뷰션의 인스톨」 . See 부록 E. 타시스템에의 이식 .


제2 장 MySQL 의 인스톨

목차

2.1. 표준 MySQL 의 퀵 인스톨
2.1.1. Windows 에의 MySQL 의 인스톨
2.1.2. Linux 에의 MySQL 의 인스톨
2.1.3. Mac OS X 에의 MySQL 의 인스톨
2.1.4. NetWare 에의 MySQL 의 인스톨
2.2. 인스톨 관련의 일반적인 문제
2.2.1. MySQL 의 입수방법
2.2.2. MD5 체크 섬 또는 GnuPG 에 의한 패키지 완전성의 검증
2.2.3. MySQL 하지만 서포트하고 있는 operating system
2.2.4. 사용해야 할 MySQL 의 버젼
2.2.5. 인스톨 레이아웃
2.2.6. 릴리스의 방법과 시기
2.2.7. 릴리스 이념 - 릴리스에 기존의 버그가 없다
2.2.8. MySQL AB 하지만 컴파일 했다 MySQL 바이너리
2.2.9. MySQL 바이너리 디스트리뷰션의 인스톨
2.3. MySQL 소스 디스트리뷰션의 인스톨
2.3.1. 퀵 인스톨의 개요
2.3.2. 패치의 적용
2.3.3. 일반적인 configure 옵션
2.3.4. 개발 소스 트리로부터의 인스톨
2.3.5. MySQL 의 컴파일에 관한 문제에의 대처
2.3.6. MIT-pthreads 에 관한 주의 사항
2.3.7. Windows 위에서 소스로부터 MySQL (을)를 인스톨 한다
2.4. 인스톨 후의 설정과 테스트
2.4.1. mysql_install_db 의 실행에 관한 문제
2.4.2. MySQL 서버의 기동에 관한 문제
2.4.3. MySQL (을)를 자동적으로 기동 및 정?~ 한다
2.5. MySQL 의 업그레이드와 다운 그레이드
2.5.1. 버젼 4.0 (으)로부터 4.1 에의 업그레이드
2.5.2. 버젼 3.23 (으)로부터 4.0 에의 업그레이드
2.5.3. 버젼 3.22 (으)로부터 3.23 에의 업그레이드
2.5.4. 버젼 3.21 (으)로부터 3.22 에의 업그레이드
2.5.5. 버젼 3.20 (으)로부터 3.21 에의 업그레이드
2.5.6. 권한 테이블의 업그레이드
2.5.7. 다른 Archie 텍 차에의 이행
2.5.8. Windows 위에서의 MySQL 의 업그레이드
2.6. operating system 고유의 주의 사항
2.6.1. Windows 의 주의 사항
2.6.2. Linux 의 주의 사항(모든 Linux 버젼)
2.6.3. Solaris 의 주의 사항
2.6.4. BSD 의 주의 사항
2.6.5. Mac OS X 의 주의 사항
2.6.6. 그 외의 Unix 의 주의 사항
2.6.7. OS/2 의 주의 사항
2.6.8. Novell NetWare 의 주의 사항
2.6.9. BeOS 의 주의 사항
2.7. Perl 인스톨에 대한 코멘트
2.7.1. Unix 에의 Perl 의 인스톨
2.7.2. Windows 에의 ActiveState Perl 의 인스톨
2.7.3. Perl DBI/DBD 인터페이스 사용시의 문제

이 장에서는,MySQL 의 입수방법과 인스톨 방법에 대해 설명합니다.

  • MySQL (을)를 입수할 수 있는 사이트의 일람에 대해서는, 항2.2.1. 「MySQL 의 입수방법」 (을)를 참조.

  • 서포트되고 있는 플랫폼을 확인하려면 , 항2.2.3. 「MySQL 하지만 서포트하고 있는 operating system」 (을)를 참조.서포트 떠날 수 있어 모든 시스템이,MySQL 의 실행에 똑같이 적합하다고는 할 수 없는 것에 주의한다. 일부의 시스템은, 다른 시스템보다 훨씬고 견뢰해서 효율적이다.상세한 것에 대하여는, 항2.2.3. 「MySQL 하지만 서포트하고 있는 operating system」 (을)를 참조.

  • MySQL 의 몇개의 버젼에 대해서는, 바이너리 디스트리뷰션과 소스 디스트리뷰션의 양쪽 모두가 준비되어 있다.또, 최신의 개발을 확인하고 싶은 유저나 새로운 코드의 테스트에 협력하고 싶은 유저를 위해서, 당사의 현재의 소스 트리에도 공개하고 있다.사용해야 할 디스트리뷰션의 버젼과 타입을 판단하려면 , 항2.2.4. 「사용해야 할 MySQL 의 버젼」 (을)를 참조.판단이 서지 않는 경우는, 바이너리 디스트리뷰션을 사용한다.

  • 바이너리 디스트리뷰션과 소스 디스트리뷰션의 인스톨 순서에 대해서는, 각각, 항2.2.9. 「MySQL 바이너리 디스트리뷰션의 인스톨」 (와)과 항2.3. 「MySQL 소스 디스트리뷰션의 인스톨」 (을)를 참조.각 순서 세트에는, 발생할 가능성이 있는 시스템 고유의 문제에 관한 섹션이 포함되어 있다.

  • 인스톨 후의 순서에 대해서는, 항2.4. 「인스톨 후의 설정과 테스트」 (을)를 참조.이러한 순서는, 바이너리 디스트리뷰션과 소스 디스트리뷰션의 어느 쪽을 사용해 MySQL (을)를 인스톨 하는 경우에도 적용된다.

2.1. 표준 MySQL 의 퀵 인스톨

이 장에서는, 각각의 플랫폼의 네이티브 패키지화 형식을 사용해 패키지가 제공되고 있는 플랫폼에의 MySQL 의 인스톨에 대해 설명합니다.다만, 그 외의 다양한 플랫폼용의 MySQL 바이너리 디스트리뷰션도 준비되어 있습니다.모든 플랫폼에 적용되는 패키지의 일반 인스톨 순서에 대해서는, 항2.2.9. 「MySQL 바이너리 디스트리뷰션의 인스톨」 (을)를 참조해 주세요.

입수할 수 있는 그 외의 바이너리 디스트리뷰션과 그 입수방법의 상세한 것에 대하여는, 항2.2. 「인스톨 관련의 일반적인 문제」 (을)를 참조해 주세요.

2.1.1. Windows 에의 MySQL 의 인스톨

Windows (으)로의 MySQL 의 인스톨은, 이하의 스텝이 됩니다.

  1. 디스트리뷰션의 인스톨

  2. 옵션 설정 파일의 설정(필요시)

  3. 사용하는 서버의 선택

  4. 서버의 기동

Windows 용 MySQL (은)는, 이하의2 종류의 형식에서 제공됩니다.

  • 바이너리 디스트리뷰션.셋업 프로그램이 포함되어 있어 이 프로그램에 의해서 필요한 것이 모두 인스톨 되므로, 서버를 즉시 기동할 수 있다.

  • 소스 디스트리뷰션.VC++ 6.0 컴파일러를 사용해 실행 파일을 빌드하기 위한 모든 코드와 서포트 파일이 포함되어 있다. See 항2.3.7. 「Windows 위에서 소스로부터 MySQL (을)를 인스톨 한다」 .

일반적으로는, 바이너리 디스트리뷰션을 사용하는 것을 추천합니다.이 디스트리뷰션이 단순하고,MySQL 의 셋업과 실행에 추가의 툴을 필요로 하지 않기 때문입니다.

2.1.1.1. Windows 시스템 요건

Windows 그리고 MySQL (을)를 실행하는 경우의 요건은 이하대로입니다.

  • 9x ,Me ,NT ,2000 ,XP 등의 32 비트의 Windows operating system. NT 파?~ 리(Windows NT ,2000 , 및 XP )에서는,MySQL 서버를 서비스로서 실행할 수 있다. See 항2.1.1.7. 「Windows NT ,2000 , 또는 XP (으)로의 MySQL 의 기동」 .

  • TCP/IP 프로토콜 서포트.

  • Windows 용 MySQL 바이너리 디스트리뷰션의 카피.이것은,http://www.mysql.com/downloads/ (으)로부터 다운로드할 수 있다.

    주의: 디스트리뷰션 파일은,zip 형식에서 제공됩니다.다운로드 프로세스중의 파일의 파손을 피하기 위해서, resume functions를 가지는 적절한 FTP 클라이언트를 사용하는 것을 추천합니다.

  • 디스트리뷰션 파일을 unpack하기 위한 ZIP 프로그램.

  • 요건에 응한 데이타베이스의 unpack, 인스톨, 작성을 행하기 위한 충분한 빈영역이 하드 디스크 드라이브상에 있는 것.

  • ODBC (을)를 경유해 MySQL 서버에 접속할 예정의 경우는,MyODBC 드라이버도 필요하다. See 항11.2. 「MySQL 의 ODBC 서포트」 .

  • 4 GB 보다 큰 사이즈의 테이블이 필요한 경우는,NTFS 또는 그것보다 새로운 파일 시스템에 MySQL (을)를 인스톨 한다.테이블을 작성할 경우에,MAX_ROWS (와)과 AVG_ROW_LENGTH (을)를 반드시 사용한다. See 항6.5.3. 「CREATE TABLE 구문」 .

2.1.1.2. Windows 바이너리 디스트리뷰션의 인스톨

바이너리 디스트리뷰션을 사용해 Windows 에 MySQL (을)를 인스톨 하려면 , 이하의 순서에 따라서 실시합니다.

  1. Windows NT ,2000 , 또는 XP 하지만 탑재된 머신으로 작업하는 경우는, 반드시 관리자 권한을 가지는 유저로서 로그인한다.

  2. 구버젼의 MySQL 인스톨을 업그레이드 하는 경우는, 현재의 서버를 정?~ 할 필요가 있다. Windows NT ,2000 , 또는 XP 하지만 탑재된 머신으로,Windows 서비스로서 서버를 실행하고 있는 경우는, 커멘드 prompt로 이하와 같이 입력해 서버를 정?~ 한다.

    C:\> NET STOP MySQL

    업그레이드 후에 다른 서버를 사용할 예정의 경우(mysqld (은)는 아니고 mysqld-max (을)를 실행하는 경우등)은, 이하와 같이 입력해 기존의 서비스를 삭제한다.

    C:\mysql\bin> mysqld --remove

    업그레이드 후에 서비스를 재인스톨 해 적절한 서버를 사용할 수 있다.

    MySQL 서버를 서비스로서 실행하고 있지 않는 경우는, 이하와 같이 입력해 서버를 정?~ 한다.

    C:\mysql\bin> mysqladmin -u root shutdown

  3. WinMySQLAdmin 프로그램을 실행하고 있는 경우는, 이 프로그램을 종료한다.

  4. 텐포라리디레크트리에 디스트리뷰션 파일을 전개한다.

  5. setup.exe 프로그램을 실행하고, 인스톨 프로세스를 개시한다. 디폴트의 디렉토리(C:\mysql ) 이외의 장소에 MySQL (을)를 인스톨 하는 경우는,Browse 버튼을 사용하고, 목적의 디렉토리를 지정한다.MySQL (을)를 디폴트 이외의 장소에 인스톨 하면, 서버를 기동할 때마다 그 자리소를 지정해야 하게 된다.이것을 실시하는 가장 간단한 방법은, 항2.1.1.3. 「Windows MySQL 환경의 준비」 그리고 설명하도록(듯이), 옵션 설정 파일을 사용하는 것이다.

  6. 인스톨 프로세스를 종료한다.

2.1.1.3. Windows MySQL 환경의 준비

서버를 실행할 경우에 기동 옵션을 지정할 필요가 있는 경우는, 커멘드 라인으로 기동 옵션을 지정하는지, 옵션 설정 파일에 기동 옵션을 배치합니다.서버를 기동할 때마다 사용되는 옵션의 경우, 옵션 설정 파일을 사용해 MySQL 의 옵션을 지정하는 것이 편리합니다.이 방법은, 이하와 같은 경우에 특히 편리합니다.

  • 인스톨 디렉토리 또는 데이터 디렉토리의 장소가 디폴트의 장소(C:\mysql (와)과 C:\mysql\data )(와)과 다른 경우.

  • 서버의 설정을 조정할 필요가 있는 경우. 예를 들어,MySQL 버젼 3.23 의 InnoDB 트랜잭션(transaction) 테이블을 사용하려면 ,InnoDB 의 데이터 파일과 로그 파일을 격납하기 위한 2 개의 디렉토리(C:\ibdata (와)과 C:\iblogs 등)을 수동으로 작성해야 한다. 또, 항7.5.3. 「InnoDB 기동 옵션」 그리고 설명하도록(듯이), 옵션 설정 파일에 행을 추가할 필요도 있다 (MySQL 4.0 이?~ 그럼,InnoDB (은)는 디폴트로 데이터 디렉토리에 데이터 파일과 로그 파일을 작성한다.따라서,InnoDB 의 설정은 필수는 아니다. 다만, 필요에 따라서 명시적으로 설정할 수도 있지만, 그 경우도 옵션 설정 파일을 사용하면 편리하다).

Windows 그럼,MySQL 인스톨러는,MySQL 의 인스톨처의 디렉토리의 직하에 데이터 디렉토리를 격납합니다.다른 장소의 데이터 디렉토리를 사용하는 경우는,data 디렉토리의 내용 전체를 그 새로운 장소에 카피해 주세요.예를 들어, 디폴트에서는, 인스톨러는,MySQL (을)를 C:\mysql 에, 데이터 디렉토리를 C:\mysql\data 에 각각 격납합니다.E:\mydata 의 데이터 디렉토리를 사용하는 경우는, 이하의 2 개의 처리를 실시할 필요가 있습니다.

  • 데이터 디렉토리를 C:\mysql\data (으)로부터 E:\mydata (으)로 이동한다.

  • 서버를 기동할 때마다,--datadir 옵션을 사용해 새로운 데이터 디렉토리의 장소를 지정한다.

MySQL 서버는,Windows 위에서 기동하면,Windows 디렉토리에 있다 my.ini 파일내와 C:\my.cnf 파일내에서 옵션을 찾습니다.통상,Windows 디렉토리에는,C:\WINDOWS (이)나 C:\WinNT (와)과 같은 이름이 붙어 있습니다.이하의 커멘드를 사용하고,%WINDIR% 환경 변수의 값으로부터 정확한 장소를 판별할 수 있습니다.

C:\> echo %WINDIR%

MySQL (은)는, 최초로 my.ini 파일내에서 옵션을 찾아, 다음에 my.cnf 파일내에서 옵션을 찾습니다.그러나, 혼란을 피하기 위해서,1 개의 파일만을 사용하는 것을 추천합니다.C: 드라이브가 부트 드라이브는 아닐 때에 PC 하지만 부트 로더를 사용하는 경우는,my.ini 파일 밖에 사용할 수 없습니다.어느 쪽의 파일을 사용하는 경우에서도, 파일은 plaintext 파일이 아니면 안됩니다.

옵션 설정 파일의 작성이나 수정은,Notepad 프로그램등의 텍스트 문자 편집기를 사용해 실시할 수 있습니다.예를 들어,MySQL 하지만 D:\mysql 에 인스톨 되고 있고, 데이터 디렉토리가 D:\mydata\data (으)로서 배치되어 있는 경우는, 옵션 설정 파일을 작성하고, 이하와 같이 [mysqld] 섹션을 설정하고,basedir 파라미터와 datadir 파라미터의 값을 지정할 수 있습니다.

[mysqld]
# set basedir to your installation path
basedir=D:/mysql
# set datadir to the location of your data directory
datadir=D:/mydata/data

주의: Windows 의 패스명은, 옵션 설정 파일내에서 backslash는 아니고 slash를 사용해 지정합니다.backslash를 사용하는 경우는, slash를 쌍꺼풀 수술을 할 필요가 있습니다.

옵션 설정 파일을 관리하는 이제(벌써) 1 개의 방법은,WinMySQLAdmin 툴을 사용하는 방법입니다.MySQL 인스톨의 bin 디렉토리에,WinMySQLAdmin (와)과 그 사용 설명이 포함된 헬프 파일이 있습니다.WinMySQLAdmin 에는 옵션 설정 파일을 편집하는 기능이 있습니다만, 이하의 점에 주의해 주세요.

  • WinMySQLAdmin (은)는,%WINDIR%\my.ini 파일만을 사용한다.

  • WinMySQLAdmin (은)는,C:\my.cnf 파일을 검출하면, 이 파일의 이름을 C:\my_cnf.bak (으)로 변경해 사실상 무효로 한다.

이것으로, 서버의 기동을 테스트할 준비를 할 수 있었습니다.

2.1.1.4. Windows 서버의 선택

MySQL 3.23.38 이?~ ,Windows 디스트리뷰션에 표준의 MySQL (와)과 MySQL-Max 의 양쪽 모두의 서버 바이너리가 포함되게 되었습니다. 이하에 각종의 MySQL 서버의 일람을 나타냅니다.이 중에서 서버를 선택할 수 있습니다.

바이너리 | 설명
mysqld | 디버그 코드 및 자동 메모리 할당의 체크, 기호 연결의 기능,InnoDB 테이블 및 BDB 테이블을 짜넣어 컴파일 되고 있다.
mysqld-opt | 최적화된 바이너리.버젼 4.0 이?~ ,InnoDB 하지만 유효하게 되어 있다.4.0 보다 전의 버젼에서는, 이 서버에 트랜잭션(transaction) 테이블의 기능은 포함되지 않았다.
mysqld-nt | 이름 파이프의 기능을 짜넣어 NT/2000/XP 전용으로 최적화된 바이너리.
mysqld-max | 기호 연결과InnoDB 테이블 및 BDB 테이블을 짜넣어 최적화된 바이너리.
mysqld-max-nt | mysqld-max (와)과 닮아 있지만, 이름 파이프의 기능을 짜넣어 컴파일 되고 있다.

상기의 바이너리는 모두, 최신의 Intel 프로세서 전용으로 최적화되고 있습니다만,Intel i386 클래스 이상의 모든 프로세서로 동작합니다.

mysqld-nt 서버 또는 mysqld-max-nt 서버는, 이름 파이프 접속을 서포트합니다.이러한 서버의 어느 쪽인지를 사용하는 경우, 이름 파이프의 사용에는 이하의 제약이 있는 것에 유의해 주세요.

  • 서버는, 이름 파이프를 서포트한다 Windows 의 버젼(NT ,2000 ,XP )(으)로 실행할 필요가 있다.

  • 버젼 3.23.50 에서는,--enable-named-pipe 옵션을 사용해 서버를 기동했을 경우에게만, 이름 파이프가 유효하게 된다.

  • 이러한 서버는,Windows 98 또는 Me 그리고 실행할 수 있지만,TCP/IP 하지만 인스톨 되고 있는 경우에 한정된다.즉, 이름 파이프를 사용한 접속은 할 수 없다.

  • Windows 95 그럼, 이러한 서버를 사용할 수 없다.

2.1.1.5. 서버를 처음으로 기동한다

Windows 95 ,98 , 또는 Me 그럼,MySQL 클라이언트는 항상 TCP/IP (을)를 사용해 서버에 접속합니다.Windows NT ,2000 ,XP 등의 NT 베이스의 시스템에서는, 클라이언트에는 2 개의 선택사항이 있습니다.즉,TCP/IP (을)를 사용하는지, 서버가 이름 파이프 접속을 서포트하고 있는 경우는 이름 파이프를 사용합니다.

서버 바이너리의 실행의 상세한 것에 대하여는, 항2.1.1.3. 「Windows MySQL 환경의 준비」 (을)를 참조해 주세요.

이 섹션에서는,MySQL 서버의 기동 방법의 일반적인 개요를 설명합니다. 특정의 버젼의 Windows 에 고유의 상세한 것에 대하여는, 후속의 각 섹션으로 설명합니다.

이러한 각 섹션으로 나타나는 예에서는,MySQL 하지만 디폴트의 장소이다 C:\mysql 에 인스톨 되고 있는 것이 전제가 되고 있습니다.MySQL (을)를 다른 장소에 인스톨 하고 있는 경우는, 예에 나타나고 있는 패스명을 조정해 주세요.

테스트는, 콘솔 윈도우(``DOS 창'' )의 커멘드 prompt로부터 실시하는 것을 추천합니다.이 방법을 취하면, 서버로부터의 스테이터스 메세지를 보기 쉬운 윈도우로 표시할 수 있습니다.설정에 문제가 있는 경우에, 이러한 메세지에 의해서 문제의 특정과 수정이 용이하게 됩니다.

서버가 격납되고 있는 디렉토리에 있는 것을 확인하고 나서, 이하의 커멘드를 입력합니다.

shell> 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
InnoDB: Log file c:\iblogs\ib_logfile1 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile1 size to 31457280
InnoDB: Log file c:\iblogs\ib_logfile2 did not exist: new to be created
InnoDB: Setting log file c:\iblogs\ib_logfile2 size to 31457280
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: '4.0.14-log'  socket: ''  port: 3306

계속 되고, 서버가 생성한 그 외의 진단 출력이 콘솔에 출력됩니다.새로운 콘솔 윈도우를 열고, 그 윈도우로 클라이언트 프로그램을 실행할 수 있습니다.

--console 옵션을 생략 하면, 진단 출력은 데이터 디렉토리내의 에러 로그에 써집니다.에러 로그는,.err 확장자(extension)를 가지는 파일입니다.

2.1.1.6. Windows 95 ,98 , 또는 Me (으)로의 MySQL 의 기동

Windows 95 ,98 , 또는 Me 그럼,MySQL 하 TCP/IP (을)를 사용해 클라이언트를 서버에 접속합니다(이것에 의해서, 네트워크상의 모든 머신이 MySQL 서버에 접속할 수 있습니다).그 때문에,MySQL (을)를 기동하기 전에,TCP/IP 하지만 인스톨 되고 있는 것을 확인할 필요가 있습니다.TCP/IP (은)는,Windows 의 CD-ROM 에 거둘 수 있고 있습니다.

주의: 구릴리스의 Windows 95 (OSR2 등)을 사용하고 있는 경우는, 구버젼의 Winsock 패키지가 인스톨 되고 있을 가능성이 있습니다.MySQL 하 Winsock 2 (을)를 필요로 합니다.최신의 Winsock (은)는,http://www.microsoft.com/ (으)로부터 입수할 수 있습니다.Windows 98 (은)는,Winsock 2 라이브러리를 갖추고 있습니다.따라서, 라이브러리를 갱신할 필요는 없습니다.

mysqld 서버를 기동하려면 , 콘솔 윈도우(``DOS'' 윈도우)를 기동하고, 이하의 커멘드를 입력합니다.

shell> C:\mysql\bin\mysqld

이 커멘드에 의해서, 백그라운드에서 mysqld 하지만 기동됩니다.따라서, 서버가 기동한 후, 다른 커멘드 prompt가 표시됩니다.주의: Windows NT ,2000 ,XP 그리고 이 방법으로 서버를 기동하면, 서버는 foreground로 실행되어 서버의 실행이 종료할 때까지 커멘드 prompt는 표시되지 않습니다. 그 때문에, 서버의 실행중은, 다른 콘솔 윈도우를 열어 클라이언트 프로그램을 실행할 필요가 있습니다.

이하의 커멘드를 실행하고,MySQL 서버를 정?~ 할 수 있습니다.

shell> C:\mysql\bin\mysqladmin -u root shutdown

이 커멘드는,MySQL 관리 유틸리티 mysqladmin (을)를 기동하고, 서버에 접속해 슛다운 하도록 지시합니다.이 커멘드는,MySQL 권한 시스템으로의 디폴트의 관리자 어카운트이다 root (으)로서 접속합니다.MySQL 권한 시스템내의 유저는,Windows 의 로그인 유저와는 완전하게 독립하고 있습니다.

mysqld 하지만 기동하지 않는 경우는, 에러 로그를 체크하고, 문제의 원인을 나타내는 메세지가 써지지 않은지 어떤지를 확인해 주세요. 에러 로그는,C:\mysql\data 디렉토리에 있습니다.이것은,.err 그렇다고 하는 사픽스가 붙은 파일입니다.또,mysqld --console (으)로서 서버를 기동할 수도 있습니다.그 경우, 문제를 해결하는데 도움이 되는 유익한 정보가 화면에 표시됩니다.

마지막 선택사항은,--standalone --debug (을)를 지정해 mysqld (을)를 기동하는 방법입니다. 이 경우,mysqld (은)는,mysqld 하지만 기동하지 않는 이유를 로그 파일 C:\mysqld.trace 에 씁니다. See 항E.1.2. 「트레이스 파일의 작성」 .

mysqld --help (을)를 사용하면,mysqld 하지만 인식할 수 있는 모든 옵션이 표시됩니다.

2.1.1.7. Windows NT ,2000 , 또는 XP (으)로의 MySQL 의 기동

NT 파?~ 리(Windows NT ,2000 , 또는 XP )에서는,MySQL (을)를 Windows 서비스로서 인스톨 해 실행하는 것을 추천합니다.Windows 의 기동시 또는 정?~ 시간에,MySQL 서버가 자동적으로 기동 또는 정?~ 됩니다.서비스로서 인스톨 된 서버는,NET 커멘드를 사용해 커멘드 라인으로부터 제어하는지,Services 유틸리티를 사용해 제어할 수 있습니다.

Services 유틸리티(Windows Service Control Manager )(은)는,Windows Control Panel (Windows 2000 의Administrative Tools 의 아래)에 있습니다.이 커멘드 라인으로부터 서버의 인스톨이나 삭제의 조작을 실행하고 있는 동안은,Services 유틸리티를 종료하는 것을 추천합니다.이것에 의해서, 어떤 종류의 예기치 않은 에러가 방?~ 됩니다.

Windows NT 4 그리고,MySQL (을)를 TCP/IP (와)과 연동시키려면 ,Service Pack 3 이상을 인스톨 할 필요가 있습니다.

MySQL (을)를 Windows 서비스로서 인스톨 하기 전에, 우선, 이하의 커멘드를 사용해 현재의 서버를 정?~ 해 주세요(서버가 가동하고 있는 경우).

shell> C:\mysql\bin\mysqladmin -u root shutdown

이 커멘드는,MySQL 관리 유틸리티 mysqladmin (을)를 기동하고, 서버에 접속해 슛다운 하도록 지시합니다.이 커멘드는,MySQL 권한 시스템내의 디폴트의 관리자 어카운트이다 root (으)로서 접속합니다.MySQL 권한 시스템내의 유저는,Windows 의 로그인 유저로부터 완전하게 독립하고 있습니다.

다음에, 이하의 커멘드로 서버를 서비스로서 인스톨 합니다.

shell> mysqld --install

서버명만을 사용해 mysqld (을)를 서비스로서 인스톨 할 때에 문제가 발생했을 경우는, 완전 패스명을 사용해 인스톨 해 보세요.

shell> C:\mysql\bin\mysqld --install

MySQL 4.0.2 이?~ 그럼,--install 옵션의 뒤로 특정의 서비스명을 지정할 수 있습니다.게다가MySQL 4.0.3 이?~ 그럼, 서비스명의 뒤로 --defaults-file 옵션을 지정하고, 기동시의 옵션을 취득하는 장소를 서버에 나타낼 수 있습니다.서버가 사용하는 서비스명과 옵션 설정 파일은, 이하의 룰에 따라서 결정됩니다.

  • 서비스명을 지정하지 않으면 서버는 디폴트 서비스명 MySQL (을)를 사용해, 디폴트의 옵션 설정 파일의 [mysqld] 그룹으로부터 옵션을 읽어낸다.

  • --install 옵션의 뒤로 서비스명을 지정하면, 서버는 [mysqld] 옵션 그룹을 무시해, 그 서비스와 같은 이름의 그룹으로부터 옵션을 읽어낸다.서버는, 디폴트의 옵션 설정 파일로부터 옵션을 읽어낸다.

  • 서비스명의 뒤로 --defaults-file 옵션을 지정하면, 서버는 디폴트의 옵션 설정 파일을 무시해, 지정 파일의 [mysqld] 그룹만으로부터 옵션을 읽어낸다.

주의: 4.0.17 보다 전의 MySQL 버젼에서는,Windows 서비스로서 인스톨 된 서버의 패스명이나 서비스명에 스페이스가 포함되어 있으면, 기동시에 문제가 발생합니다.따라서,C:\Program Files 등의 디렉토리에 MySQL (을)를 인스톨 하거나 스페이스를 포함한 서비스명을 사용하거나 하는 것은 피해 주세요.

통상대로 --install (을)를 사용해 서버를 인스톨 했을 경우는, 서버는 MySQL 의 서비스명으로 인스톨 됩니다.

한층 더 복잡한 예로서 이하의 커멘드를 고찰해 보겠습니다.

shell> C:\mysql\bin\mysqld --install mysql --defaults-file=C:\my-opts.cnf

여기에서는,--install 옵션의 뒤로 서비스를 지정해 있습니다.이 커멘드로 --defaults-file 옵션을 지정하지 않으면 서버는 표준의 옵션 설정 파일로부터 [mysql] 그룹을 읽어냅니다(이 옵션 그룹은 mysql 클라이언트 프로그램이 사용하는 것이기 위해, 이것은 추천 할 수 없습니다).다만,--defaults-file 옵션을 지정해 있기 때문에, 서버는, 지정 파일의 [mysqld] 옵션 그룹만으로부터 옵션을 읽어냅니다.

MySQL 서비스를 기동하기 전에,Windows 서비스 유틸리티로 ``Start parameters'' (으)로서 옵션을 지정할 수도 있습니다.

MySQL 서버를 서비스로서 인스톨 하면,Windows 하지만 기동할 때마다 MySQL 서비스가 자동적으로 기동됩니다.서비스는, 서비스 유틸리티로부터 직접 기동하는지, 커멘드 NET START MYSQL (을)를 사용해 기동할 수도 있습니다.NET 커멘드는, 케이스 의존이 아닙니다.

주의: mysqld (은)는, 서비스로서 실행되면 콘솔 윈도우에 액세스 할 수 없기 때문에, 콘솔 윈도우에 메세지는 표시되지 않습니다.mysqld 하지만 기동하지 않는 경우는, 에러 로그를 체크하고, 문제의 원인을 나타내는 메세지가 써지지 않은지 어떤지를 확인해 주세요. 에러 로그는,C:\mysql\data 디렉토리에 있습니다.이것은,.err 그렇다고 하는 사픽스가 붙은 파일입니다.

서비스로서 가동하고 있다 mysqld (은)는, 서비스 유틸리티,NET STOP MYSQL 커멘드, 또는 mysqladmin shutdown 커멘드를 사용해 정?~ 할 수 있습니다.Windows 하지만 슛다운 할 경우에 서비스가 가동하고 있는 경우는,Windows 에 의해서 서버가 자동적으로 정?~ 됩니다.

MySQL 버젼 3.23.44 에서는, 부트 프로세스중에 서비스를 자동적으로 기동시키고 싶지 않은 경우,Manual 서비스로서 서버를 인스톨 할 수 있습니다.그 경우는, 이하와 같이,--install 옵션이 아니고,--install-manual 옵션을 사용합니다.

shell> C:\mysql\bin\mysqld --install-manual

서비스로서 인스톨 된 서버를 삭제하려면 , 서버가 가동하고 있는 경우는, 우선 서버를 정?~ 합니다.다음에,--remove 옵션을 사용하고, 서버를 삭제합니다.

shell> mysqld --remove

MySQL 서비스 자동 슛다운의 1 개의 문제는,3.23.49 보다 전의 버젼의 MySQL 의 경우,Windows 하지만 슛다운의 완료까지 몇초간 밖에 대기하지 않고, 이 제한 시간을 초과하면 데이터 베이스 서버 프로세스가 강제 종료된다고 하는 점입니다.이것에 의해서, 문제가 발생하는 일이 있었습니다(예를 들어,InnoDB 스토리지 엔진은 다음 번의 기동시에 크래쉬 리커버리를 실행할 필요가 있는 등).MySQL 버젼 3.23.49 이?~ (은)는,MySQL 서버의 슛다운의 완료까지의 Windows 의 대기 시간이 연장되고 있습니다.이 대기 시간이라도 인스톨에 충분하지 않다고 생각되는 경우, 가장 안전한 것은,MySQL 서버를 서비스로서 실행하지 않는 것입니다.대신에,MySQL 서버의 기동은 커멘드 라인 prompt로부터 실시해, 정?~ 하 mysqladmin shutdown (을)를 사용해 가 주세요.

MySQL 서버의 정?~ 시간에 대기 시간을 연장하는 듯 Windows 에 지시하기 위한 변경은,Windows 2000 및 XP 에는 유효합니다만,Windows NT 에는 유효하지는 않습니다.Windows NT 의 경우, 서비스의 슛다운을 위한 대기 시간은 20 초에만, 이 시간이 경과하면, 서비스 프로세스는 강제 종료됩니다.레지스터리 편집기 \winnt\system32\regedt32.exe (을)를 끊어 레지스트리 트리내의 HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control 의 WaitToKillServiceTimeout 의 값을 편집하고, 이 디폴트치를 늘릴 수 있습니다.디폴트치보다 큰 새로운 값을?~ 리초단위로 지정합니다(예를 들어, 값 120000 (을)를 지정하면,Windows NT (은)는 최대로 120 초간 대기합니다).

mysqld (을)를 서비스로서 기동하지 않는 경우는,NT 베이스 이외의 Windows 의 버젼의 경우와 같게 커멘드 라인으로부터 기동할 수 있습니다.순서에 대해서는, 항2.1.1.6. 「Windows 95 ,98 , 또는 Me (으)로의 MySQL 의 기동」 (을)를 참조해 주세요.

2.1.1.8. Windows (으)로의 MySQL 의 실행

MySQL (은)는, 모든 Windows 플랫폼에서 TCP/IP (을)를 서포트합니다.mysqld-nt 서버와 mysql-max-nt 서버는,NT ,2000 , 및 XP 그리고 이름 파이프를 서포트합니다. 다만, 디폴트에서는, 플랫폼에 관계없이 TCP/IP 하지만 사용됩니다.

  • 많은 Windows 설정에서는, 이름 파이프는, 사실상 TCP/IP 보다 저속이다.

  • 이름 파이프를 사용했을 경우,MySQL 서버를 슛다운 할 때에 문제가 발생하는 일이 있다.

3.23.50 이?~ 의 버젼의 mysqld-nt 및 mysql-max-nt 의 경우,--enable-named-pipe 옵션을 사용해 이러한 서버를 기동했을 때에 마셔 이름 파이프가 유효하게 됩니다.

--pipe 옵션을 지정하는지, 호스트명으로서 . (피리어드)(을)를 지정하고,MySQL 클라이언트에 강제적으로 이름 파이프를 사용시킬 수 있습니다.파이프의 이름은,--socket 옵션을 사용해 지정합니다.MySQL 4.1 그럼,--protocol=PIPE 옵션을 사용해 주세요.

이하의 몇개의 커멘드를 실행하고,MySQL 서버가 동작하고 있을지를 테스트할 수 있습니다.

C:\> C:\mysql\bin\mysqlshow
C:\> C:\mysql\bin\mysqlshow -u root mysql
C:\> C:\mysql\bin\mysqladmin version status proc
C:\> C:\mysql\bin\mysql test

Windows 9x/Me 위에서, 접속에 대한다 mysqld 의 응답이 늦은 경우는, 사용하고 있다 DNS 에 문제가 있을 가능성이 있습니다.그 경우는,--skip-name-resolve 옵션을 사용해 mysqld (을)를 기동해,MySQL 권한 테이블의 Host 컬럼의 localhost (와)과 IP 번호만을 사용합니다.

MySQL 커멘드 라인 툴에는 이하의 2 개의 버젼이 있습니다.

바이너리 | 설명
mysql | 네이티브 Windows 위에 컴파일 되어서 한정된 텍스트 편집 기능을 제공한다.
mysqlc | Cygnus GNU 컴파일러와 라이브러리를 짜넣어 컴파일 되어readline 의 편집 기능을 제공한다.

mysqlc (을)를 사용하는 경우는,mysqlc 하지만 검출할 수 있는 장소에 cygwinb19.dll 라이브러리의 카피를 인스톨 할 필요가 있습니다.MySQL 의 최신의 디스트리뷰션에서는,mysqlc (와)과 같은 디렉토리에 이 라이브러리가 포함되어 있습니다(사용하시는 MySQL 인스톨의 기본 디렉토리아래의 bin 디렉토리).사용하시는 디스트리뷰션의 bin 디렉토리에 cygwinb19.dll 라이브러리가 없는 경우는,lib 디렉토리내에서 이 라이브러리를 찾아,Windows 시스템 디렉토리(\Windows\system 인가, 이것에 유사한 장소)에 카피합니다.

Windows 의 디폴트의 권한의 설정에서는, 로컬 유저는, 패스워드 없이 전데이타베이스에 대해서 모든 조작을 실시할 수 있게 되어 있습니다.MySQL (을)를 보다 안전하게 하기 위해서, 모든 유저에게 패스워드를 설정해,Host='localhost' (와)과 User='' 하지만 기술되었다 mysql.user 테이블의 레코드를 삭제해 주세요.

또,root 유저의 패스워드도 추가해 주세요.이하의 예에서는, 우선 전권한을 가지는 익명 유저를 삭제해, 다음에 root 유저 패스워드를 설정합니다.

C:\> C:\mysql\bin\mysql mysql
mysql> DELETE FROM user WHERE Host='localhost' AND User='';
mysql> FLUSH PRIVILEGES;
mysql> QUIT
C:\> C:\mysql\bin\mysqladmin -u root password your_password

패스워드를 설정한 다음에 mysqld 서버를 슛다운 하는 경우는, 이 커멘드를 사용해 슛다운 할 수 있습니다.

C:\> mysqladmin --user=root --password=your_password shutdown

MySQL 버젼 3.21 의 낡다 Windows 쉐어웨어 디스트리뷰션의 서버를 사용하고 있는 경우, 패스워드를 설정하기 위한 mysqladmin 커멘드는parse error near 'SET password' 그렇다고 하는 에러에 의해서 실패합니다.이 문제는, 이 버젼보다 새롭다 MySQL 에 업그레이드 하는 것으로 해결됩니다.

최신 버젼의 MySQL 그럼,GRANT 커멘드와 REVOKE 커멘드를 사용하고, 새로운 유저의 추가와 특권의 변경을 간단하게 실시할 수 있습니다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

2.1.2. Linux 에의 MySQL 의 인스톨

Linux 에 MySQL (을)를 인스톨 하는 경우는,RPM 패키지를 사용하는 것을 추천합니다.MySQL RPM (은)는, 현재,SuSE Linux 7.3 시스템상에서 빌드 되고 있습니다만,rpm (을)를 서포트해 glibc (을)를 사용하는 대부분의 버젼의 Linux 위에서 동작합니다.

RPM 파일에 관한 문제가 발생했을 경우(예를 들어,``Sorry, the host 'xxxx' could not be looked up'' 그렇다고 하는 에러가 표시되었을 경우)는, 항2.6.2.1. 「Linux 의 주의 사항 (바이너리 디스트리뷰션)」 (을)를 참조해 주세요.

대부분의 경우,MySQL-server 패키지와 MySQL-client 패키지를 인스톨 하는 것만으로 끝납니다.최소 인스톨의 경우는, 그 외의 패키지는 필요 없습니다. 추가 기능을 갖추었다 MySQL Max 서버를 실행하고 싶은 경우는,MySQL-server RPM (을)를 인스톨 한 후에 MySQL-Max RPM (을)를 인스톨 해 주세요. See 항4.8.5. 「mysqld-max (확장 mysqld 서버)」 .

MySQL 4.0 패키지의 인스톨중에 의존관계(dependencies) 에러가 발생했을 경우(예를 들어,``error: removing these packages would break dependencies: libmysqlclient.so.10 is needed by ...'' ),MySQL-shared-compat 패키지도 인스톨 할 필요가 있습니다.이 패키지에는, 하위 호환성을 위해서 양쪽 모두의 공유 라이브러리(MySQL 4.0 의 libmysqlclient.so.12 (와)과 MySQL 3.23 의 libmysqlclient.so.10 )(이)가 포함되어 있습니다.

많은 Linux 디스트리뷰션에게는 아직 MySQL 3.23 하지만 동고 되고 있어 어플리케이션을 동적으로 링크해 디스크 영역을 절약하고 있습니다.이러한 공유 라이브러리가 별개의 패키지(MySQL-shared 등)에 포함되어 있는 경우는, 이 패키지를 인스톨 하고,MySQL 서버 및 클라이언트의 패키지를 업그레이드 하는 것만으로 충분합니다(이러한 패키지는 정적으로 링크되어 공유 라이브러리에 의존하지 않습니다).MySQL 서버와 같은 패키지에 공유 라이브러리가 포함되어 있는 디스트리뷰션의 경우(Red Hat Linux 등)은, 버젼 3.23 의 MySQL-shared RPM (을)를 인스톨 하는지,MySQL-shared-compat 패키지를 사용합니다.

이하의 RPM 패키지가 준비되어 있습니다.

  • MySQL-server-VERSION.i386.rpm

    MySQL 서버.다른 머신상에서 가동하고 있다 MySQL 서버에 접속할 만한 경우를 제외하고, 이 패키지가 필요.주의: MySQL 4.0.10 보다 전의 버젼에서는, 이 패키지는 MySQL-VERSION.i386.rpm (으)로 불리고 있었다.

  • MySQL-Max-VERSION.i386.rpm

    MySQL Max 서버.이 서버에는,MySQL-server RPM 의 서버에는 포함되지 않은 추가 기능이 있다.MySQL-Max RPM 하 MySQL-server RPM 에 의존하므로, 우선 MySQL-server 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 3.23 (와)과 MySQL 4.0 의 양쪽 모두의 공유 라이브러리가 포함되어 있다.MySQL 3.23 에 동적으로 링크되는 어플리케이션을 인스톨 하고 있는 경우에, 라이브러리의 의존관계(dependencies)를 부수지 않고 MySQL 4.0 에 업그레이드 하고 싶을 때는,MySQL-shared 대신에 이 패키지를 인스톨 한다.이 패키지는,MySQL 4.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

최소 인스톨을 실시하려면 , 이하의 커멘드를 실행합니다.

shell> rpm -i MySQL-server-VERSION.i386.rpm MySQL-client-VERSION.i386.rpm

클라이언트 패키지만을 인스톨 하려면 , 이하의 커멘드를 실행합니다.

shell> rpm -i MySQL-client-VERSION.i386.rpm

RPM 에는, 패키지를 인스톨 하기 전에 그 완전성과 신뢰성을 검증하는 기능이 갖춰져 있습니다.이 기능의 상세한 것에 대하여는, 항2.2.2. 「MD5 체크 섬 또는 GnuPG 에 의한 패키지 완전성의 검증」 (을)를 참조해 주세요.

서버 RPM (은)는,/var/lib/mysql 디렉토리아래에 데이터를 배치합니다.또, 부트시에 서버를 자동적으로 기동하기 위한 적절한 엔트리를 /etc/init.d/ 에 작성합니다(따라서, 구버젼의 인스톨을 실행하고 있어, 기동 스크립트로 변경을 더하고 있는 경우, 새로운 버젼의 RPM 의 인스톨시에 그 스크립트가 없어지지 않게 하기 위해서는 스크립트의 카피를 작성할 필요가 있습니다).시스템 기동시에 MySQL 하지만 자동적으로 기동되도록(듯이) 하는 방법에 대해서는, 항2.4.3. 「MySQL (을)를 자동적으로 기동 및 정?~ 한다」 (을)를 참조해 주세요.

/etc/init.d 의 초기화 스크립트를 서포트하고 있지 않는 구버젼의 Linux 디스트리뷰션에 MySQL RPM (을)를 인스톨 한다(직접 또는 symlink (을)를 사용해) 경우는, 초기화 스크립트가 실제로 인스톨 되는 장소를 가리키는 기호 연결을 작성해 주세요.예를 들어, 그 자리소가 /etc/rc.d/init.d 인 경우,RPM (을)를 인스톨 하기 전에 이하의 커멘드를 사용하고, 그 자리소를 가리키는 기호 연결로서 /etc/init.d (을)를 작성합니다.

shell> cd /etc; ln -s rc.d/init.d .

다만,/etc/init.d (을)를 사용하는 이 새로운 디렉토리 레이아웃은,LSB (Linux Standard Base )에 준거하기 위해서 필요하다 것으로, 최신의 모든 주요 Linux 디스트리뷰션에서는 벌써 서포트되고 있습니다.

인스톨 한다 RPM 파일에 MySQL-server 하지만 포함되어 있는 경우는, 인스톨 후에 mysqld demon가 기동합니다. 이것으로,MySQL 의 사용을 개시할 수 있게 되었습니다. See 항2.4. 「인스톨 후의 설정과 테스트」 .

무엇인가 문제가 있었을 경우는, 바이너리 인스톨의 장을 참조해 주세요. See 항2.2.9. 「MySQL 바이너리 디스트리뷰션의 인스톨」 .

2.1.3. Mac OS X 에의 MySQL 의 인스톨

MySQL 4.0.11 에서는, 바이너리 tarball 디스트리뷰션은 아니고 Mac OS X PKG 바이너리 패키지를 사용하고,Mac OS X 10.2 (``Jaguar'' )에 MySQL (을)를 인스톨 할 수 있게 되었습니다.주의: 이 패키지는, 이것보다 낡은 버젼의 Mac OS X (10.1.x 등)은 서포트하고 있지 않습니다.

패키지는, 디스크 이미지(.dmg ) 파일내에 있습니다.우선, finder내에서 이 파일의 아이콘을 더블 클릭 해 마운트할 필요가 있습니다.디스크 이미지 파일을 마운트하면, 이미지가 마운트되어 그 내용이 표시됩니다.

주의: 인스톨을 속행하기 전에,MySQL Manager Application (Mac OS X Server 위에서)를 사용할까 커멘드 라인으로 mysqladmin shutdown (을)를 사용하고, 가동하고 있는 모든 MySQL 서버 인스턴스를 반드시 슛다운 해 주세요.

MySQL PKG (을)를 실제로 인스톨 하려면 , 패키지의 아이콘을 더블 클릭 합니다.이것에 의해,Mac OS Package Installer 하지만 기동됩니다.이 인스톨러의 지시에 따라서 MySQL 의 인스톨을 실시합니다.

MySQL 의 Mac OS X PKG (은)는, 자신을 /usr/local/mysql-<version> 에 인스톨 합니다.또, 새로운 장소를 가리키는 기호 연결 /usr/local/mysql 도 인스톨 합니다./usr/local/mysql (이)라는 이름의 디렉토리가 벌써 존재하는 경우는, 우선 그 디렉토리의 이름을 /usr/local/mysql.bak (으)로 변경합니다.게다가 인스톨 후에 mysql_install_db (을)를 실행하고,mysql 데이타베이스에 권한 테이블을 인스톨 합니다.

인스톨 레이아웃은, 바이너리 디스트리뷰션의 인스톨 레이아웃 과 유사합니다.즉, 모든 MySQL 바이너리가 /usr/local/mysql/bin 디렉토리에 배치됩니다. MySQL 소켓 파일은, 디폴트로 /tmp/mysql.sock (으)로서 작성됩니다. See 항2.2.5. 「인스톨 레이아웃」 .

MySQL 인스톨에는,mysql (이)라는 이름의 Mac OS X 유저 어카운트가 필요합니다(Mac OS X 10.2 이?~ 의 경우, 이 이름을 가지는 유저 어카운트가 디폴트로 존재합니다).

Mac OS X Server (을)를 실행하고 있는 경우,MySQL (은)는 벌써 인스톨 되고 있습니다.

  • Mac OS X Server 10.2 ~ 10.2.2 에는 MySQL 3.23.51 하지만 인스톨 되고 있다.

  • Mac OS X Server 10.2.3 ~ 10.2.6 에는 MySQL 3.23.53 하지만 동고 되고 있다.

  • Mac OS X Server 10.3 에는 MySQL 4.0.14 하지만 동고 되고 있다.

여기에서는, 공식의 MySQL Mac OS X PKG 의 인스톨에 대한 봐 설명합니다.반드시,MySQL 의 인스톨에 관한 Apple 의 헬프를 참조해 주세요(``Help View'' 어플리케이션을 실행하고,``Mac OS X Server'' 헬프를 선택해,``MySQL'' (을)를 검색하고,``Installing MySQL'' 그렇다고 하는 항목을 참조해 주세요).

특히,Mac OS X Server 위의 프리 인스톨판의 MySQL (은)는,mysqld_safe 커멘드는 아니고 safe_mysqld 커멘드로 기동하는 것에 주의해 주세요.

http://www.entropy.ch (으)로부터 입수했다 Marc Liyanage 의 Mac OS X 용 MySQL 패키지를 사용하고 있는 경우는, 동씨의 페이지에 나타나고 있는 바이너리 인스톨 레이아웃에 의한 패키지의 갱신 순서 설명에 따르는 것만으로 끝납니다.

Marc 의 3.23.xx 버젼 또는 Mac OS X Server 버젼의 MySQL (으)로부터 공식의 MySQL PKG 에 업그레이드 하는 경우는, 몇개의 새로운 시큐러티 특권이 추가되고 있으므로, 기존의 MySQL 특권 테이블을 현재의 형식으로 변환할 필요도 있습니다. See 항2.5.6. 「권한 테이블의 업그레이드」 .

또, 시스템의 부트 업시에 MySQL (을)를 자동적으로 기동하는 경우는,MySQL Startup Item (을)를 인스톨 할 필요가 있습니다.MySQL 4.0.15 에서는,MySQL Startup Item 하 Mac OS X 인스톨 디스크 이미지의 일부로서 별개의 인스톨 패키지가 되고 있습니다.MySQLStartupItem.pkg 아이콘을 더블 클릭 해, 지시에 따라서 인스톨 합니다.

주의: 이 인스톨은 1 회만 실시합니다.MySQL 패키지를 업그레이드 할 때마다 Startup Item (을)를 인스톨 할 필요는 없습니다.

Mac OS X 패키지 인스톨러에 버그가 있기 위해, 인스톨처 디스크 선택 화면에 You cannot install this software on this disk. (null) 그렇다고 하는 에러 메세지가 표시되는 일이 있습니다.이 에러가 발생했을 경우는,Go Back 버튼을 클릭하고 앞에 화면으로 돌아옵니다.다음에,Continue (을)를 클릭하고, 한번 더 인스톨처 디스크 선택 화면으로 나아가, 적절한 인스톨처 디스크를 선택할 수 있습니다.이 문제는,Apple 에 보고가 끝난 상태로, 현재 동사에서 조사중입니다.

Startup Item (은)는,/Library/StartupItems/MySQL 에 인스톨 됩니다. 이것에 의해서, 시스템 설정 파일 /etc/hostconfig 에 변수 MYSQLCOM=-YES- 하지만 추가됩니다.MySQL 의 자동 기동을 무효로 하는 경우는, 이 변수를 MYSQLCOM=-NO- (으)로 변경합니다.

Mac OS X Server 그럼,Startup Item 인스톨 스크립트가 자동적으로 /etc/hostconfig 의 변수 MYSQL (을)를 MYSQL=-NO- (으)로 변경하고, 디폴트 MySQL 인스톨의 기동을 무효로 합니다.이것은, 부트 업시의 충돌을 회피하기 위해서 행해집니다.다만, 벌써 가동하고 있다 MySQL 서버가 슛다운 될 것은 없습니다.

인스톨 후는, 타?~ 널 윈도우로 이하의 커멘드를 실행해 MySQL (을)를 기동할 수 있습니다.이 작업을 실시하려면 관리자 특권이 필요한 것으로 주의해 주세요.

Startup Item (을)를 인스톨 했을 경우는, 이하의 커멘드를 입력합니다.

shell> sudo /Library/StartupItems/MySQL/MySQL start
(
필요하면 패스워드를 입력)
(Control-D
인가 "exit"
(을)를 넣고 쉘로부터 빠진다)

Startup Item (을)를 사용하지 않는 경우는, 이하의 커멘드 순서를 입력합니다.

shell> cd /usr/local/mysql
shell> sudo ./bin/mysqld_safe
(
필요하면 패스워드를 입력)
(Control-Z)
shell> bg
(Control-D
인가 "exit"
(을)를 넣고 쉘로부터 빠진다)

이것으로,/usr/local/mysql/bin/mysql 등을 실행해 MySQL 서버에 접속할 수 있게 되었습니다.

처음 MySQL (을)를 인스톨 했을 경우는, 반드시,MySQL root 유저의 패스워드를 설정해 주세요 .

패스워드의 설정은, 이하의 2 개의 커멘드를 사용해 실시합니다.

/usr/local/mysql/bin/mysqladmin -u root password <password>
/usr/local/mysql/bin/mysqladmin -u root -h `hostname` password <password>

2 행목의 hostname 커멘드는, 반드시, 박크크트 (` )(으)로 둘러싸 주세요.그렇게 하는 것으로, 쉘은, 이 커멘드를 그 출력(이 시스템의 호스트명)에 옮겨놓을 수 있습니다.

이하와 같이 쉘의 resource file에 앨리어스(alias)를 추가하고, 커멘드 라인으로부터 mysql 및 mysqladmin 에 액세스 할 수도 있습니다.

alias mysql '/usr/local/mysql/bin/mysql'
alias mysqladmin '/usr/local/mysql/bin/mysqladmin'

혹은, 예를 들어 이하의 행을 $HOME/.tcshrc 에 추가하고,$PATH 환경 변수에 /usr/local/mysql/bin (을)를 추가할 수 있습니다.

setenv PATH ${PATH}:/usr/local/mysql/bin

새롭다 MySQL PKG (을)를 인스톨 해도 기존의 인스톨의 디렉토리는 삭제되지 않는 것에 주의해 주세요.Mac OS X 인스톨러에는, 이전에 인스톨 된 패키지를 적절히 업그레이드 하기 위해서 필요한 기능은 아직 갖춰지고 있지 않습니다.

구버젼의 MySQL 데이타베이스 파일을 카피해, 새로운 버젼을 정상적으로 기동한 후, 디스크 영역 절약을 위해서 구버젼의 인스톨 파일을 삭제하는 것을 추천합니다. 게다가/Library/Receipts/mysql-<version>.pkg 에 있는 구버젼의 Package Receipt 디렉토리도 삭제해 주세요.

2.1.4. NetWare 에의 MySQL 의 인스톨

버젼 4.0.11 이?~ ,Novell NetWare 향해라 MySQL 서버가 바이너리 패키지 형식에서 제공되고 있습니다.NetWare 서버는,MySQL (을)를 호스트 하기 위해서 이하의 요건을 채우지 않으면 안됩니다.

  • NetWare 버젼 6.5 또는 Support Pack 3 하지만 인스톨 되었다 NetWare 6.0 (Support Pack 3 하 http://support.novell.com/filefinder/13659/index.html 그리고 입수할 수 있다). 시스템은, 각 버젼의 NetWare (을)를 실행하기 위한 Novell 의 필요 조건을 채워 있을 필요가 있다.

  • MySQL 데이터와 바이너리 자체가 NSS 볼륨에 인스톨 되고 있는 것(종래의 볼륨은 서포트되어 있지 않다).

NetWare 용바이너리 패키지는,http://www.mysql.com/downloads/ 그리고 입수할 수 있습니다.

NetWare 6.0 그리고 MySQL (을)를 실행하는 경우는, 커멘드 라인으로 --skip-external-locking 옵션을 지정하는 것을 강하게 추천합니다.또,myisamchk (은)는 외부 락을 이용하므로,myisamchk (은)는 아니고 CHECK TABLE 및 REPAIR TABLE (을)를 사용할 필요도 있습니다. NetWare 6.0 그럼, 외부 락에 관한 기존의 문제가 있습니다.이 문제는 NetWare 6.5 그럼 해결되고 있습니다.

2.1.4.1. NetWare 용 MySQL 바이너리의 인스톨

  1. 기존의 인스톨로부터 업그레이드 하는 경우는,MySQL 서버를 정?~ 한다. MySQL 서버의 정?~ (은)는, 써버 콘솔로부터 이하의 커멘드를 사용해 실시한다.

    SERVER:  mysqladmin -u root shutdown

  2. MySQL 의 인스톨 장소에 액세스 할 수 있는 클라이언트 머신으로부터 목적의 서버에 로그 온 한다.

  3. 바이너리 패키지 zip 파일을 서버에 추출한다.반드시,zip 파일의 패스를 사용할 수 있도록 한다.파일을 단순하게 SYS:\ 에 추출해도 문제는 없다.

    기존의 인스톨로부터 업그레이드 하는 경우는, 여기서 my.cnf 외에 데이터 디렉토리(SYS:MYSQL\DATA 등)을 카피할 필요가 있는 경우가 있다(데이터 디렉토리를 커스터마이즈 하고 있는 경우).그 후, 구버젼의 MySQL 의 카피를 삭제할 수 있다.

  4. 필요에 따라서, 디렉토리의 이름을 보다 일관성이 있는 사용 싼 이름으로 변경한다.SYS:MYSQL (이)라는 이름의 사용을 추천한다(이 메뉴얼의 예에서는, 일반적으로 인스톨 디렉토리를 가리키는데 이 이름을 사용하고 있다).

  5. 써버 콘솔로,MySQL NLM 하지만 격납되고 있는 디렉토리의 검색 패스를 추가한다.예를 들어, 이하와 같이 입력한다.

    SERVER:  SEARCH ADD SYS:MYSQL\BIN

  6. 필요에 따라서, 써버 콘솔로 mysql_install_db (을)를 실행해 초기 데이타베이스를 인스톨 한다.

  7. 써버 콘솔로 mysqld_safe (을)를 사용해 MySQL 서버를 기동한다.

  8. 인스톨을 완료하려면 ,autoexec.ncf 에 이하의 커멘드도 추가할 필요가 있다.예를 들어,MySQL 인스톨이 SYS:MYSQL 에 있어,MySQL (을)를 자동적으로 기동하는 경우는, 이하의 행을 추가한다.

    #Starts the MySQL 4.0.x database server
SEARCH ADD SYS:MYSQL\BIN
MYSQLD_SAFE

    NetWare 6.0 (을)를 사용하고 있는 경우는,--skip-external-locking 플래그를 추가한다.

    #Starts the MySQL 4.0.x database server
SEARCH ADD SYS:MYSQL\BIN
MYSQLD_SAFE --skip-external-locking

서버상에 기존의 MySQL 인스톨이 있는 경우는, 반드시,autoexec.ncf 에 기존의 MySQL 기동 커멘드가 없는가 체크하고, 필요에 따라서 그러한 기동 커멘드를 편집 또는 삭제한다.


2.2. 인스톨 관련의 일반적인 문제

2.2.1. MySQL 의 입수방법

최신의 버젼과 다운로드 순서에 대해서는,MySQL 의 홈 페이지(http://www.mysql.com/ )(을)를 참조해 주세요.

주요?~ 라는,http://mirrors.sunsite.dk/mysql/ 에 있습니다.

MySQL Web/ 다운로드?~ 라의 최신의 완전한 일람에 대해서는,http://www.mysql.com/downloads/mirrors.html (을)를 참조해 주세요. 이 사이트에서는,MySQL ?~ 라사이트가 되는 방법과 부적절한?~ 라나 무효인?~ 라의 보고 방법에 대한 정보도 제공하고 있습니다.

2.2.2. MD5 체크 섬 또는 GnuPG 에 의한 패키지 완전성의 검증

목적에 맞았다 MySQL 패키지를 다운로드한 후, 인스톨 하기 전에, 그 패키지가 파손하고 있지 않는 것, 그리고 개찬되어 있지 않은 것을 확인할 필요가 있습니다.

MySQL AB (은)는,MD5 checksums 라고GnuPG 에 의한 암호화 서명이다 GNU Privacy Guard 의 2 종류의 완전성 체크 수단을 제공하고 있습니다.

MD5 Checksum 의 검증

패키지를 다운로드한 후,MD5 체크 섬이 MySQL 다운로드 페이지에 기재되어 있는 것과 일치하고 있을지를 확인해 주세요.각 패키지에는 개별의 체크 섬이 있습니다.이하의 커멘드를 사용해 체크 섬을 검증할 수 있습니다.

shell> md5sum <package>

주의: operating system에 따라서는,md5sum 커멘드가 서포트되어 있지 않은 것이 있습니다.일부의 operating system에서는, 이 커멘드를 md5 (이)라는 이름으로 부르고 있습니다.또, 이 커멘드를 전혀 제공하고 있지 않는 operating system도 있습니다.Linux 그럼, 이 커멘드는 다양한 플랫폼에서 사용할 수 있다 GNU Text Utilities 패키지에 짜넣어지고 있습니다.http://www.gnu.org/software/textutils/ (으)로부터 원시 코드를 입수할 수도 있습니다.OpenSSL (을)를 인스톨 하고 있는 경우는, 이 커멘드 대신에 openssl md5 <package> 커멘드를 사용할 수도 있습니다.md5 커멘드의 DOS/Windows 실장은,http://www.fourmilab.ch/md5/ (으)로부터 입수할 수 있습니다.

례:

shell> md5sum mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz
155836a7ed8c93aee6728a827a6aa153
                mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz

결과의 체크 섬이, 다운로드 페이지로 각 패키지의 직하에 기재되어 있는 것과 일치하고 있을지를 확인합니다.

GnuPG 에 의한 서명 체크

패키지의 완전성을 검증하기 위한보다 신뢰성의 높은 방법은, 암호화 서명을 사용하는 방법입니다.MySQL AB (은)는,GNU Privacy Guard (GnuPG )(을)를 사용합니다.이것은,Phil Zimmermann 하지만 개발한 매우 유명한 Pretty Good Privacy (PGP )에 대신한다 오픈 소스 의 소프트웨어입니다. OpenPGP/GnuPG 의 상세와GnuPG 의 입수방법 및 사용하시는 시스템에의 인스톨 방법에 대해서는,http://www.gnupg.org/ 및 http://www.openpgp.org/ (을)를 참조해 주세요.대부분의 Linux 디스트리뷰션에는, 디폴트로 GnuPG 하지만 인스톨 되고 있습니다.

MySQL 4.0.10 (2003 년 2 월) 이?~ ,MySQL AB (은)는 다운로드 가능 패키지에 GnuPG 에 의한 서명을 붙이고 있습니다.암호화 서명은, 파일의 완전성과 신뢰성을 검증하기 위한보다 신뢰성의 높은 방법입니다.

특정의 패키지의 서명을 검증하려면 , 우선 MySQL AB 의 공개 GPG 빌드 키 <build@mysql.com> 의 카피를 입수할 필요가 있습니다.이하에 기재한 것을 직접 컷 앤드 페이스트 하는지,http://www.keyserver.net/ (으)로부터 입수해 주세요.

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):

-----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
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==
=YJkx
-----END PGP PUBLIC KEY BLOCK-----

이 키는,gpg --import (을)를 사용해 공개 GPG 키 링에 임포트 할 수 있습니다.공개 키의 처리 방법에 대해서는,GPG 의 메뉴얼을 참조해 주세요.

공개 빌드 키를 다운로드해 임포트 하면, 필요한 MySQL 패키지와 거기에 대응하는 서명(이것도 다운로드 페이지로부터 입수할 수 있습니다)을 다운로드합니다. 서명에는,.asc 그렇다고 하는 파일명 확장자(extension)가 붙어 있습니다.예를 들어,mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz 의 서명은,mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz.asc 입니다. 패키지와 서명의 양쪽 모두의 파일이 같은 디렉토리에 격납되고 있는 것을 확인하고 나서, 이하의 커멘드를 실행하고, 패키지 파일의 서명을 검증합니다.

shell> gpg --verify <package>.asc

Example:

shell> gpg --verify mysql-standard-4.0.10-gamma-pc-linux-i686.tar.gz.asc
gpg: Warning: using insecure memory!
gpg: Signature made Mon 03 Feb 2003 08:50:39 PM MET using DSA key ID 5072E1F5
gpg: Good signature from
     "MySQL Package signing key (www.mysql.com) <build@mysql.com>"

"Good signature" 그렇다고 하는 메세지가 표시되면, 문제 없습니다.

RPM 에 의한 서명 체크

RPM 패키지의 경우, 별개의 서명은 없습니다.RPM 패키지에는 GPG 서명과 MD5 체크 섬 하지만 짜넣어지고 있습니다.이 서명과 MD5 체크 섬은, 이하의 커멘드를 실행해 검증할 수 있습니다.

shell> rpm --checksig <package>.rpm

Example:

shell> rpm --checksig MySQL-server-4.0.10-0.i386.rpm
MySQL-server-4.0.10-0.i386.rpm: md5 gpg OK

주의: RPM 4.1 (을)를 사용하고 있는 경우,GPG 공개 키 링에 임포트 했음에도 불구하고,(GPG) NOT OK (MISSING KEYS: GPG#5072e1f5) 그렇다고 하는 메세지가 표시되면, 우선 RPM 키 링에 키를 임포트 할 필요가 있습니다.RPM 4.1 그럼 GPG 키 링( 및 GPG 자체)의 사용이 안?~ 되어 자신의 키 링이 유지되고 있습니다(이것은,RPM 하지만 시스템 와이드인 어플리케이션이며,GPG 공개 키 링은 유저 고유의 파일이기 (위해)때문입니다).MySQL 공개 키를 RPM 키 링에 임포트 하는 경우는, 이하의 커멘드를 사용해 주세요.

shell> rpm --import <pubkey>

Example:

shell> rpm --import mysql_pubkey.asc

MD5 체크 섬 또는 GPG 서명이 일치하지 않는 경우는, 우선 다른?~ 라사이트로부터 패키지를 한번 더 다운로드해 보세요.재차, 패키지의 완전성을 검증할 수 없었던 경우는, 그 패키지의 완전명으로 이용한 다운로드 사이트를 기재하고, 전자 메일로 당사에 알려주세요(주소는 <webmaster@mysql.com> 또는 <build@mysql.com> ).

2.2.3. MySQL 하지만 서포트하고 있는 operating system

당사에서는 GNU Autoconf (을)를 사용하고 있으므로, 정상적으로 기능한다 Posix 스레드 및 C++ 컴파일러에 의해서 모든 최신의 시스템에 MySQL (을)를 이식할 수 있습니다(클라이언트 코드만을 컴파일 하는 경우는,C++ 컴파일러는 필요합니다만 스레드는 불필요합니다).당사에서는, 주로 Linux (SuSE 및 Red Hat ),FreeBSD , 및 Sun Solaris (버젼 8 및 9 ) 위에서 MySQL 소프트웨어를 사용 및 개발하고 있습니다

많은 operating system에서는, 네이티브스레드는 최신 버젼의OS 에서만 유효한 것으로 주의해 주세요.MySQL (은)는, 이하의 operating system와 스레드패키지의 편성으로 정상적으로 컴파일 하는 것이 보고되고 있습니다.

  • AIX 4.x ,5.x (와)과 네이티브스레드. See 항2.6.6.4. 「IBM-AIX 의 주의 사항」 .

  • Amiga

  • BSDI 2.x (와)과 MIT-pthreads 패키지. See 항2.6.4.5. 「BSD/OS 버젼 2.x 의 주의 사항」 .

  • BSDI 3.0 ,3.1 , 및 4.x (와)과 네이티브스레드. See 항2.6.4.5. 「BSD/OS 버젼 2.x 의 주의 사항」 .

  • SCO OpenServer (와)과 최신의 이식판의 FSU Pthreads 패키지. See 항2.6.6.9. 「SCO 의 주의 사항」 .

  • SCO UnixWare 7.1.x .See 항2.6.6.10. 「SCO UnixWare 버젼 7.1.x 의 주의 사항」 .

  • DEC Unix 4.x (와)과 네이티브스레드. See 항2.6.6.6. 「Alpha-DEC-UNIX (Tru64 )의 주의 사항」 .

  • FreeBSD 2.x (와)과 MIT-pthreads 패키지. See 항2.6.4.1. 「FreeBSD 의 주의 사항」 .

  • FreeBSD 3.x 및 4.x (와)과 네이티브스레드. See 항2.6.4.1. 「FreeBSD 의 주의 사항」 .

  • FreeBSD 4.x (와)과 Linuxthreads . See 항2.6.4.1. 「FreeBSD 의 주의 사항」 .

  • HP-UX 10.20 (와)과 DCE 스레드 또는 MIT-pthreads 패키지. See 항2.6.6.2. 「HP-UX 버젼 10.20 의 주의 사항」 .

  • HP-UX 11.x (와)과 네이티브스레드. See 항2.6.6.3. 「HP-UX 버젼 11.x 의 주의 사항」 .

  • Linux 2.0+ (와)과 LinuxThreads 0.7.1+ 또는 glibc 2.0.7+ . See 항2.6.2. 「Linux 의 주의 사항(모든 Linux 버젼)」 .

  • Mac OS X .See 항2.6.5. 「Mac OS X 의 주의 사항」 .

  • NetBSD 1.3/1.4 Intel 및 NetBSD 1.3 Alpha (GNU make 하지만 필요). See 항2.6.4.2. 「NetBSD 의 주의 사항」 .

  • Novell NetWare 6.0 . See 항2.6.8. 「Novell NetWare 의 주의 사항」 .

  • OpenBSD 2.5 이?~ 의 버젼과 네이티브스레드.OpenBSD 2.5 보다 전의 버젼과 MIT-pthreads 패키지. See 항2.6.4.3. 「OpenBSD 2.5 의 주의 사항」 .

  • OS/2 Warp 3,FixPack 29 및 OS/2 Warp 4, FixPack 4 .See 항2.6.7. 「OS/2 의 주의 사항」 .

  • SGI Irix 6.x (와)과 네이티브스레드. See 항2.6.6.8. 「SGI Irix 의 주의 사항」 .

  • Solaris 2.5 이?~ (와)과 SPARC 및 x86 위의 네이티브스레드. See 항2.6.3. 「Solaris 의 주의 사항」 .

  • SunOS 4.x (와)과 MIT-pthreads 패키지. See 항2.6.3. 「Solaris 의 주의 사항」 .

  • Tru64 Unix

  • Windows 9x ,Me ,NT ,2000 , 및 XP . See 항2.6.1. 「Windows 의 주의 사항」 .

주의: 모든 시스템이,MySQL 의 실행에 똑같이 적합하다고는 할 수 없습니다.특정의 플랫폼이 고부하로?~ 션크리티칼인 MySQL 서버에 어느 정도 적합할까는, 이하의 요인에 의해서 정해집니다.

  • 스레드라이브라리의 전반적인 안정성.다른 점으로 높은 평가를 얻고 있는 플랫폼으로도,MySQL 하지만 호출하는 스레드라이브라리의 코드가 불안정한 경우는, 그 이외의 모든 점으로 완벽해도,MySQL 의 동작은 불안정하게 된다.

  • 커넬 및 스레드라이브라리 또는 그 어느쪽이든가 멀티 프로세서 시스템상에서 SMP (을)를 활용할 수 있을지.즉, 프로세스가 스레드를 작성했을 경우에, 그 스레드는 원래의 프로세스와는 다르다 CPU 위에서 동작할 수 없으면 안 된다.

  • 커넬/ 스레드라이브라리가, 과잉인 콘텍스트 스위칭을 실시하는 일 없이, 상호 배타 락(mutex) (을)를 빈번히 취득/ 해방하는 많은 스레드를, 실행할 수 있을지. 즉,pthread_mutex_lock() 의 실장이 CPU 시간을 낳는 것에 너무 중점을 두어서 경우, 그것으로 MySQL 의 퍼포먼스는 크게 손상되게 된다.이 문제에 대처하지 않으면CPU (을)를 머신에 추가하면 MySQL 의 처리 속도가 실질적으로 늦어진다.

  • 파일 시스템의 전반적인 안정성과 퍼포먼스

  • 파일 시스템이 테이블이 큰 경우에 큰 파일을 효율적으로 처리할 수 있을지.

  • 플랫폼에 관한 MySQL AB 의 전문 지식의 레벨.MySQL AB (은)는, 숙지하고 있는 플랫폼에 대해서는, 컴파일시에 유효하게 되는 플랫폼 고유의 최적화나 수정을 도입한다.또,MySQL 전용으로 시스템 설정을 최적화하는 방법에 대해 조언 할 수도 있다.

  • 비슷한 설정을 한 환경에 대해서,MySQL AB 하지만 사내에서 실시한 테스트의 양.

  • 목적의 플랫폼상에서 MySQL (을)를 문제 없게 실행한 유저의 수.이 수가 많으면, 플랫폼 고유의 예기치 못한 문제가 발생할 가능성이 매우 낮아진다.

이상의 기준으로부터, 현시점에서 MySQL (을)를 실행하는데 최적인 플랫폼은,SuSE Linux 8.2 ,2.4 커넬, 및 ReiserFS (또는 유사한 Linux 디스트리뷰션)을 탑재했다 x86 라고Solaris (2.7 ~ 9 )(을)를 탑재했다 SPARC 입니다.FreeBSD (은)는 제 3 정도입니다만, 스레드라이브라리가 개선되면 베스트 그룹에 동료로 할 것입니다.또,MySQL 하지만 컴파일 되어 정상적으로 동작하는(안정성과 퍼포먼스의 레벨이 완전히 같지는 않다고 해도) 다른 모든 플랫폼을 언제의 날이나 베스트 그룹에 포함할 수 있게 되는 것을 당사는 간절히 희망하고 있습니다.그러기 위해서는,MySQL 하지만 의존한다 OS (이)나 라이브러리의 개발자와 협력해 당사가 노력할 필요가 있습니다.그러한 컴퍼넌트의 어느쪽이든을 개선하는 것에 흥미가 있어, 그 개발에 영향을 주는 입장에 있어,MySQL 의 동작을 개선하기 위해서 필요한 일에 대한 상세한 설명이 필요한 유저는,MySQL 의 사내 메일링 리스트에 전자 메일을 전송해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 .

상기의 비교는, 각 OS 의 전반적인 우열을 붙이기 위한 것이 아닙니다.여기에서는, 특정 용도(즉 MySQL 의 실행)을 위해서 특정의 OS (을)를 선택하는 것에 초점을 맞추고 있어 그 점에 관한 봐 플랫폼을 비교하고 있습니다.이것을 염두에 두면, 이 비교에 한층 더 많은 논점을 포함했을 경우는, 결과는 다른 것이 됩니다.있다 OS 하지만 다른 OS 보다 우수한 이유가, 단지 당사가 그 플랫폼의 테스트와 최적화에 다른 플랫폼보다 많은 노력을 소비했기 때문에 뿐인 것도 있습니다. 여기에서는, 사용하시는 셋업내에서 MySQL (을)를 사용하는 플랫폼을 결정할 때에 참고로 해주시도록 당사의 소견을 말하고 있는에 지나지 않습니다.

2.2.4. 사용해야 할 MySQL 의 버젼

최초로, 최신의 개발판 릴리스와 최신의 제품판(안정판) 릴리스의 어느 쪽을 사용할까를 결정합니다.

  • 처음 MySQL (을)를 사용을 개시하는 경우나, 전용의 바이너리 디스트리뷰션이 없는 시스템에 MySQL (을)를 이식하는 경우는, 통상은 제품판 릴리스(현버젼은 4.0 )(을)를 선택하는 것을 추천한다. 주의: 모든 MySQL 릴리스는, 릴리스전에 MySQL 벤치마크와 광범위한 테스트스트에 의해서 체크되고 있다(개발판 릴리스의 경우도 마찬가지).

  • 그 이외의 경우, 기존의 구버젼의 시스템을 업그레이드 하고 싶지만, 심리스가 아닌 업그레이드를 사용하는 것이 불안한 경우는, 사용하고 있는 같은 브랜치를 최신의 것에 업그레이드 한다(최신의 버젼이, 사용하고 있는 것보다 새로운 경우).최신 버젼에서는, 중대한 버그만이 수정되어 비교적 작고 안전한 변경을 하고 있다.

다음에, 소스 디스트리뷰션과 바이너리 디스트리뷰션의 어느 쪽을 사용할까를 결정합니다.사용하시는 플랫폼용의 바이너리 디스트리뷰션이 있는 경우, 바이너리 디스트리뷰션을 사용해 주세요.이것은, 일반적으로 소스 디스트리뷰션보다 인스톨이 간단하기 때문에입니다.

이하의 경우는, 소스 인스톨을 사용하는 것이 잘 되갈 가능성이 있습니다.

  • MySQL (을)를 명시적으로 지정한 장소에 인스톨 하는 경우(표준의 바이너리 디스트리뷰션은, 임의의 장소에서 `` 실행 가능'' 하지만, 더 한층의 유연성을 얻을 수 있다).

  • 다양한 유저의 요건을 채울 수 있도록(듯이),2 종류의 바이너리 버젼이 준비되어 있다.1 개는 비트랜잭션(transaction) 스토리지 엔진을 짜넣어 컴파일 된 바이너리(고속으로 작은 바이너리)로, 이제(벌써) 1 개는 트랜잭션(transaction) 세이프 테이블등의 가장 중요한 기능이 짜넣어진 바이너리이다.어느 쪽의 버젼도 같은 소스 디스트리뷰션으로부터 컴파일 되고 있다.모든 MySQL 네이티브 클라이언트는, 양쪽 모두의 MySQL 버젼에 접속할 수 있다.

    확장 MySQL 바이너리 디스트리뷰션에는,-max 그렇다고 하는 사픽스가 붙어 있어mysqld-max (와)과 같은 옵션이 지정되어 있다. See 항4.8.5. 「mysqld-max (확장 mysqld 서버)」 .

    MySQL-Max RPM (을)를 사용하는 경우는, 우선 표준의 MySQL-server RPM (을)를 인스톨 할 필요가 있다.

  • 표준의 바이너리 디스트리뷰션에 포함되지 않은 추가 기능을 mysqld 에 짜넣는 경우.이하에, 가장 자주(잘) 사용되는 추가 옵션의 일람을 나타낸다.

    • --with-innodb (MySQL 4.0 이?~ 의 경우는 디폴트)

    • --with-berkeley-db (사용할 수 없는 플랫폼도 있다)

    • --with-raid

    • --with-libwrap

    • --with-named-z-libs (일부의 바이너리용)

    • --with-debug[=full]

  • 디폴트의 바이너리 디스트리뷰션은, 통상, 모든 캐릭터 세트의 서포트를 짜넣어 컴파일 되어 같은 프로셋사파?~ 리의 각종 프로세서상에서 동작한다.

    MySQL 서버를 보다 고속화하고 싶은 경우는, 필요한 캐릭터 세트의 서포트만을 짜넣어 MySQL 서버를 재컴파일 할 필요가 있다.그 때는, 보다 적절한 컴파일러(pgcc 등)을 사용하는지, 사용하고 있는 프로세서 전용에 의해 최적화된 컴파일러 옵션을 사용한다.

  • 버그를 찾아내고,MySQL 개발 팀에 보고하면, 패치가 송부된다.그 패치를 소스 디스트리뷰션에 적용하고, 버그를 수정할 필요가 있다.

  • MySQL (을)를 구성한다 C 및 C++ 의 코드의 독해나 수정을 실시하는 경우는, 소스 디스트리뷰션을 입수한다.원시 코드는, 항상 최고의 메뉴얼이 된다.또, 소스 디스트리뷰션에는, 바이너리 디스트리뷰션보다 많은 테스트나 샘플이 포함되어 있다.

MySQL 의 이름부 스킴에서는,3 개의 숫자와 1 개의 사픽스로 구성되는 릴리스 번호가 사용됩니다.예를 들어,mysql-4.1.0-alpha (와)과 같은 릴리스명은, 이하와 같이 해석됩니다.

  • 최초의 숫자(4 )(은)는, 메이저 버젼 번호이며, 동시에 파일 형식도 나타내고 있다.버젼 4 의 전릴리스는 같은 파일 형식을 가지고 있다.

  • 2 번째의 숫자(1 )(은)는 릴리스 레벨이다.

  • 3 번째의 숫자(0 )(은)는, 릴리스 레벨내의 버젼 번호이다.이 숫자는, 새로운 디스트리뷰션 마다 증가해 간다.통상은, 선택한 릴리스 레벨의 최신의 버젼이 필요하다.

  • 사픽스(alpha )(은)는, 릴리스의 안정성의 레벨을 나타낸다. 이하와 같은 사픽스가 있다.

    • alpha (은)는, 그 릴리스에 100% (은)는 테스트되어 있지 않은 새로운 코드가 포함되어 있는 것을 나타내고 있다.기존의 버그(통상은 없다)는, 「News 」의 섹션에 기재된다.See 부록 D. MySQL Change History . 대부분의 alpha 릴리스에는 새로운 커멘드와 확장 기능도 포함되어 있다. alpha 릴리스에서는, 큰 코드 변경이 일어나는 개발을 할 가능성이 있지만, 릴리스의 전에 모든 것이 테스트되고 있다.MySQL 릴리스에는 기존의 버그는 없다.

    • beta (은)는, 모든 새로운 코드가 테스트되고 있는 것을 나타내고 있다.낡은 코드를 파괴하는 큰 새로운 기능은 추가되어 있지 않다.기존의 버그는 없다.적어도 1 개월간,alpha 버젼으로 중대한 버그가 보고되지 않고, 낡은 커멘드의 신뢰성을 내리는 기능을 추가할 계획이 없는 경우는, 버젼은 알파로부터 베타로 바뀐다.

    • gamma (은)는, 일정기간 나돌고 있고, 정상적으로 동작한다고 생각되는 베타 버젼이다.작은 수정만이 추가된다.이것은, 다른 많은 기업에서 릴리스로 불리고 있는 것이다.

    • 사픽스가 붙지 않은 경우는, 그 버젼이 다양한 사이트에서 플랫폼 고유의 버그 이외의 버그가 보고되는 일 없이 일정기간 가동하고 있던 것을 의미한다.그러한 릴리스에는 중대한 버그 수정만이 적용된다.이것은, 제품판(안정판) 릴리스로 불리고 있는 것이다.

MySQL 개발 프로세스에서는, 단계가 다른 다양한 버젼이 공존합니다.당연, 구버젼의 시리즈의 관련 버그 수정은 신버젼에 전파 됩니다.

  • 이전의 안정판/ 제품판 시리즈 3.23 의 경우, 신버젼은 중대한 버그의 경우만 릴리스 된다.

  • 현행의 시리즈 4.0 (은)는, 안정판/ 제품판 레벨의 품질로, 버그 수정을 위해서 새로운 버젼이 릴리스 되고 있다.코드의 안정성에 영향을 미치는 신기능은 추가되어 있지 않다.

  • alpha 브랜치 4.1 그럼, 중요한 신기능이 추가되고 있다.개발 시스템으로 사용 및 테스트하기 위한 소스와 바이너리가 준비되어 있다.

  • 개발 브랜치 5.0 (은)는,BitKeeper 트리로부터 마셔 입수할 수 있다.

MySQL 의 모든 버젼은, 표준 테스트와 benchmark test를 해 비교적 안전하다라고 하는 것이 확인되고 있습니다.표준 테스트는, 과거에 발견된 모든 버그를 체크하기 위해서 시간의 경과와 함께 확장되고 있으므로, 테스트스트는 항상 개량되고 있습니다.

주의: 모든 릴리스는 적어도 이하의 테스트가 실행되고 있습니다.

  • 내부 테스트스트

    mysql-test 디렉토리에는 충실한 시험대 세트가 포함되어 있다.

    이러한 테스트는, 사실상 모든 서버 바이너리에 대해서 행해진다.

  • MySQL 벤치마크스트

    이 테스트스트는, 각종의 일반적 쿼리를 실행한다.이것은, 또, 최신의 일련의 최적화가 실제로 코드를 고속화할지를 확인하기 위한 테스트이기도 하다. See 항5.1.4. 「MySQL 벤치마크스트」 .

  • crash-me 테스트

    데이타베이스가 서포트하는 기능과 그 능력과 제약의 판정이 시행된다. See 항5.1.4. 「MySQL 벤치마크스트」 .

이제(벌써) 1 개의 테스트는, 당사가 사내의 실가동 환경에서 적어도 1 받침대의 머신상에서 최신의 MySQL 버젼을 사용하는 것입니다.당사에는 100 기가바이트를 넘는 처리용 데이터가 있습니다.

2.2.5. 인스톨 레이아웃

여기에서는, 바이너리 디스트리뷰션 및 소스 디스트리뷰션의 인스톨에 의해서 작성되는 디렉토리의 디폴트 레이아웃에 대해 설명합니다.

바이너리 디스트리뷰션은, 선택한 인스톨 장소(통상은 /usr/local/mysql )(으)로 unpack 하는 것으로 인스톨 되어 그 자리소에 이하의 디렉토리를 작성합니다.

디렉토리 | 디렉토리의 내용
bin | 클라이언트 프로그램과 mysqld 서버
data | 로그 파일, 데이타베이스
docs | 문서, 변경 로그
include | 인클루드(헤더) 파일
lib | 라이브러리
scripts | mysql_install_db
share/mysql | 에러 메세지 파일
sql-bench | 벤치마크

소스 디스트리뷰션은, 콘피개 해 컴파일 한 후에 인스톨 됩니다.디폴트에서는, 인스톨 스텝에 의해서, 이하의 서브 디렉토리내의 /usr/local 의 아래에 파일이 인스톨 됩니다.

디렉토리 | 디렉토리의 내용
bin | 클라이언트 프로그램과 스크립트
include/mysql | 인클루드(헤더) 파일
info | Info 형식의 메뉴얼
lib/mysql | 라이브러리
libexec | mysqld 서버
share/mysql | 에러 메세지 파일
sql-bench | 벤치마크와 crash-me 테스트
var | 데이타베이스와 로그 파일

인스톨 디렉토리내에서는, 소스 인스톨의 레이아웃은, 바이너리 인스톨의 레이아웃과는 이하와 같이 다릅니다.

  • mysqld 서버는,bin 디렉토리가 아니고,libexec 디렉토리에 인스톨 된다.

  • 데이터 디렉토리는 data (은)는 아니고 var 이다.

  • mysql_install_db (은)는,/usr/local/mysql/scripts 디렉토리가 아니고,/usr/local/bin 디렉토리에 인스톨 된다.

  • 헤더 파일과 라이브러리의 디렉토리는,include (와)과 lib (이)가 아니고,include/mysql (와)과 lib/mysql 이다.

스크립트 scripts/make_binary_distribution (을)를 실행하고, 컴파일 된 소스 디스트리뷰션으로부터 독자적인 바이너리 인스톨을 작성할 수 있습니다.

2.2.6. 릴리스의 방법과 시기

MySQL AB 사내에서 MySQL (은)는 매우 급속히 진화하고 있어, 당사는 다른 MySQL 유저와 이것을 공유하고 싶다고 생각하고 있습니다.다른 유저가 필요로 하고 있다고 생각되는 매우 유용한 기능이 있는 경우는, 릴리스를 작성합니다.

또, 간단하게 실장할 수 있는 기능을 요구하고 있는 유저의 지원에도 노력하고 있습니다.라이센스 유저, 특히 확장 전자 메일 서포트 대상의 유저가 무엇을 요망하고 있을까에 주의해, 이러한 유저를 지원하는 노력을 실시하고 있습니다.

유저는 새로운 릴리스를 다운로드할 필요는 없습니다.정말로 필요한 것이 새로운 릴리스에 포함되어 있는 경우는, 「News 」의 섹션으로 통지됩니다. See 부록 D. MySQL Change History .

MySQL (을)를 갱신하는 경우, 당사는 이하의 폴리시를 사용합니다.

  • 마이너 갱신을 할 때마다, 버젼 문자열의 마지막 숫자가 증분 된다. 중요한 신기능이 있는 경우나 구버젼과의 몇 안 되는 비호환성이 있는 경우는, 버젼 문자열의 2 번째의 숫자가 증분 된다.파일 형식이 변경되었을 경우는, 최초의 숫자가 증분 된다.

  • 제품판(안정 테스트가 끝난) 릴리스는,1 해에 약 1 ~ 2 회공개되게 되어 있지만, 작은 버그가 발견되었을 경우는, 버그 수정만을 포함한 릴리스가 공개된다.

  • 운용 릴리스/ 구릴리스에 대한 버그 수정은, 약 4 ~ 8 주 마다 공개된다.

  • 메이저 릴리스에 대해서는,MySQL AB 에 의해서 일부의 플랫폼용의 바이너리 디스트리뷰션이 작성된다. 제삼자가, 그 외의 시스템용의 바이너리 디스트리뷰션을 작성하는 일이 있지만, 그 빈도는 적다.

  • 통상,MySQL AB 하지만 작은 버그를 발견해 수정했을 경우는 곧바로 패치를 공개한다.이러한 패치는, 즉시 BitKeeper 공개 리포지터리(repository)에 격납된다.또, 다음의 릴리스에도 짜넣어진다.

  • 중대하지 않지만 문제를 일으키는 버그는,MySQL 소스 리포지터리(repository)에 추가되어 다음의 릴리스로 수정된다.

  • 만일, 릴리스에 중대한 버그가 있었을 경우는, 당사는 가능한 한 신속하게 새로운 릴리스를 작성한다.타사에도 이 작업을 부탁하고 싶다.

현행의 제품판 릴리스는, 버젼 4.0 입니다.액티브한 개발은 벌써 버젼 4.1 및 5.0 에 진행되고 있습니다.버젼 4.0 의 버그의 수정과3.23 시리즈의 중대한 버그의 수정은 향후도 계속됩니다. 당사는, 완전한 개발 동결은 좋아로 하지 않습니다.이것에 의해서, 버그 수정과 " 실시해야 한다" 일이 방치되게 되기 때문입니다." 일부 동결" 그렇다고 하는 것은," 벌써 가동하고 있는 것에 거의 틀림없이 영향을 주지 않는다" 작은 변경이 추가되는 일이 있는 것을 의미합니다.

MySQL 그럼, 대부분 외제품과는 조금 다른 이름부 스킴이 사용됩니다. 일반적으로, 새로운 버젼으로 옮겨지는 일 없이 2 주간 공개된 버젼은, 사용해도 비교적 안전합니다. See 항2.2.4. 「사용해야 할 MySQL 의 버젼」 .

2.2.7. 릴리스 이념 - 릴리스에 기존의 버그가 없다

당사는, 릴리스에 버그가 없게 하기 위해서 많은 시간으로 노력을 소비하고 있습니다. 당사가 아는 한, 기존의 ' 중대한' 재현 가능한 버그가 있다 MySQL 버젼은 1 개도 릴리스 되고 있지 않습니다.

중대한 버그란, 통상의 사용으로 MySQL (을)를 크래쉬 시키는, 일반적인 쿼리에 대해서 잘못된 응답을 돌려주는 버그, 또는 시큐러티에 문제가 있는 버그입니다.

설계상의 결정에 의존하는 미해결의 장해, 버그, 문제는 모두 문서화 되고 있습니다. See 항1.8.6. 「MySQL 의 기존의 에러와 설계상의 문제」 .

당사의 목표는, 안정판의 MySQL 하지만 불안정하게 되는 위험을 무릅쓰는 일 없이, 수정 가능한 것은 모두 수정하는 것입니다.경우에 의해서, 이것은, 개발판의 문제는 수정할 수 있지만, 안정판(제품판)의 문제는 수정할 수 없다고 하는 것을 의미합니다.당연, 그러한 문제는, 유저에게 알리기 위해서 문서화 됩니다.

이하에, 당사의 빌드 프로세스의 구조를 설명합니다.

  • 커스터머 서포트 리스트,MySQL 사외 메일링 리스트, 및 버그 데이타베이스(http://bugs.mysql.com/ )(으)로부터 버그를 모니터 한다.

  • 유효한 버젼에 관해서 보고된 모든 버그가 버그 데이타베이스에 입력된다.

  • 버그가 수정되면, 그 버그의 시험대를 작성하고, 당사의 테스트 시스템에 짜넣어, 버그가 재현하지 않는 것을 확인한다(수정이 끝난 버그의 약 90% 에는 시험대가 있다).

  • 또,MySQL 에 추가되는 모든 신기능에 대해 시험대가 작성된다.

  • 새롭다 MySQL 릴리스의 작성을 개시하기 전에,MySQL 버젼(3.23.x (이)나 4.0.x 등)에 대해 보고된 모든 재현 가능한 버그를 확실히 수정한다.MySQL 의 내부의 설계상의 하등의 결정이 이유로 수정이 불가능한 버그가 있는 경우는, 그것을 메뉴얼에 기재한다. See 항1.8.6. 「MySQL 의 기존의 에러와 설계상의 문제」 .

  • 전용의 바이너리가 서포트 떠날 수 있어 모든 플랫폼(15 이상의 플랫폼) 위에서 빌드를 실시해, 그러한 모든 플랫폼상에서 당사의 테스트스트와 벤치마크스트를 실행한다.

  • 테스트 또는 벤치마크스트가 실패한 플랫폼의 바이너리는 공개되지 않는다.소스의 일반적인 에러인 경우는, 그것을 수정해, 모든 시스템으로 최초부터 빌드와 테스트를 재실행한다.

  • 빌드 및 테스트의 프로세스(2 ,3 일을 필요로 한다) 안에, 중대한 버그(코어덤프를 발생시키는 버그 등)에 관한 보고를 받아들였을 경우는, 그 버그를 수정한 다음, 빌드 프로세스를 재개한다.

  • http://www.mysql.com/ 그리고 바이너리를 공개한 후,mysql (와)과 announce 의 메일링 리스트로 고지 메일을 송신한다. See 항1.7.1.1. 「MySQL 메일링 리스트」 . 고지 메세지에는, 릴리스에 대한 모든 변경과 릴리스에 관한 기존의 문제의 일람이 기재된다 (릴리스 노트에 「기존의 문제」의 섹션이 필요했어는, 그저 한 줌의 릴리스 뿐이다).

  • 유저가 MySQL 의 최신의 기능에 신속히 액세스 할 수 있도록(듯이),4 ~ 8 주간 마다 새롭다 MySQL 릴리스를 실시한다. 원시 코드의 snapshot는 매일 작성되어http://downloads.mysql.com/snapshots.php 에서 공개된다.

  • 릴리스 후에, 특정의 플랫폼상의 빌드에(그런데도) 중대한 문제가 있었다고 하는 버그 리포트를 받았을 경우는, 버그를 즉시 수정해, 그 플랫폼용의 새롭다 'a' 릴리스를 빌드 한다.당사의 거대한 유저 기반 덕분에, 문제는 신속히 발견된다.

  • 당사는, 뛰어난 릴리스를 작성하는 것에 관계해 높은 실적을 가진다.과거의 150 릴리스에 대하고, 새로운 빌드를 실시할 필요가 있던 것은 10 릴리스 미만이다(그 중의 3 개는, 당사의 빌드 머신의 1 개로 glibc 라이브러리에 결함이 있었기 때문에서 만났다.이것을 찔러?~ 의 것에 긴 시간을 필요로 했다).

2.2.8. MySQL AB 하지만 컴파일 했다 MySQL 바이너리

MySQL AB (은)는, 서비스로서 MySQL 의 일련의 바이너리 디스트리뷰션을 제공합니다.이러한 바이너리 디스트리뷰션은, 사내에서 컴파일 하는지, 유저가 당사에 머신에의 액세스를 제공해 주는 장소에서 컴파일 됩니다.

플랫폼 고유의 패키지 형식에서 제공하는 바이너리( 항2.1. 「표준 MySQL 의 퀵 인스톨」 (을)를 참조) 외에,tar 형식의 압축 어카이브(archive)(.tar.gz )에 의해서 다양한 플랫폼용의 바이너리 디스트리뷰션도 제공합니다.

이러한 디스트리뷰션은,Build-tools/Do-compile 스크립트를 사용해 생성됩니다.이 스크립트는, 원시 코드를 컴파일 해,scripts/make_binary_distribution (을)를 사용해 바이너리 tar.gz 어카이브(archive)를 작성합니다.이러한 바이너리는, 이하의 컴파일러와 옵션에 의해서 콘피개 및 빌드 됩니다.

MySQL AB 의 개발 시스템으로 빌드 되는 바이너리는 이하대로입니다.

  • Linux 2.4.xx x86 with gcc 2.95.3

    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.xx Intel Itanium 2 with ecc (Intel C++ Itanium Compiler 7.0)

    CC=ecc CFLAGS="-O2 -tpp2 -ip -nolib_inline" CXX=ecc
CXXFLAGS="-O2 -tpp2 -ip -nolib_inline" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --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 --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared --disable-shared

  • 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 --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

  • Sun Solaris 8 x86 with gcc 3.2.3

    CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors
-fno-exceptions -fno-rtti" ./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 --disable-shared
--with-innodb

  • Sun Solaris 8 sparc with gcc 3.2

    CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=no --with-named-curses-libs=-lcurses --disable-shared

  • Sun Solaris 8 sparc 64bit 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 -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=no --with-named-curses-libs=-lcurses --disable-shared

  • Sun Solaris 9 sparc with gcc 2.95.3

    CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --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 -mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --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
--localstatedir=/usr/local/mysql/data
--libexecdir=/usr/local/mysql/bin
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-named-z-libs=no
--disable-shared --with-innodb

  • IBM AIX 5.1.0 ppc with gcc 3.3

    CFLAGS="-O2 -mcpu=powerpc -Wa,-many" CXX=gcc CXXFLAGS="-O2 -mcpu=powerpc -Wa,-many -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --with-server-suffix="-pro" --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --disable-shared

  • HP-UX 10.20 pa-risc1.1 with gcc 3.1

    CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc CXXFLAGS="-DHPUX -I/opt/dce /include -felide-constructors -fno-exceptions -fno-rtti -O3 -fPIC" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-pthread --with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC --disable-shared

  • HP-UX 11.11 pa-risc2.0 64bit with aCC (HP ANSI C++ B3910B A.03.33)

    CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

  • HP-UX 11.11 pa-risc2.0 32bit with aCC (HP ANSI C++ B3910B A.03.33)

    CC=cc CXX=aCC CFLAGS="+DAportable"
CXXFLAGS="+DAportable" ./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 --disable-shared
--with-innodb

  • Apple Mac OS X 10.2 powerpc with gcc 3.1

    CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

  • FreeBSD 4.7 i386 with gcc 2.95.4

    CFLAGS=-DHAVE_BROKEN_REALPATH ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --with-named-z-libs=not-used --disable-shared

  • QNX Neutrino 6.2.1 i386 with gcc 2.95.3qnx-nto 20010315

    CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

이하의 바이너리는, 다른 유저에 의해서 MySQL AB 에 제공된 써드파티의 시스템상에서 빌드 되고 있습니다.이러한 바이너리는, 호의에 의해서 제공되고 있습니다.MySQL AB (은)는, 이러한 시스템을 완전하게 관리하고 있는 것은 아니기 때문에, 이러한 시스템상에서 빌드 된 바이너리에 대해서는 한정된 서포트 밖에 제공할 수 없습니다.

  • SCO Unix 3.2v5.0.6 i386 with gcc 2.95.3

    CFLAGS="-O3 -mpentium" LDFLAGS=-static CXX=gcc
CXXFLAGS="-O3 -mpentium -felide-constructors" ./configure
--prefix=/usr/local/mysql --with-extra-charsets=complex
--enable-thread-safe-client --enable-local-infile
--with-named-z-libs=no --enable-thread-safe-client
--disable-shared

  • SCO OpenUnix 8.0.0 i386 with CC 3.2

    CC=cc CFLAGS="-O" CXX=CC ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --with-named-z-libs=no --enable-thread-safe-client --disable-shared

  • Compaq Tru64 OSF/1 V5.1 732 alpha with cc/cxx (Compaq C V6.3-029i / DIGITAL C++ V6.1-027)

    CC="cc -pthread" CFLAGS="-O4 -ansi_alias -ansi_args
-fast -inline speed -speculate all" CXX="cxx -pthread"
CXXFLAGS="-O4 -ansi_alias -fast -inline speed -speculate all
-noexceptions -nortti" ./configure --prefix=/usr/local/mysql
--with-extra-charsets=complex --enable-thread-safe-client
--enable-local-infile --with-prefix=/usr/local/mysql
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
--disable-shared --with-mysqld-ldflags=-all-static

  • SGI Irix 6.5 IP32 with gcc 3.0.1

    CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --disable-shared

  • FreeBSD 5.0 sparc64 with gcc 3.2.1

    CFLAGS=-DHAVE_BROKEN_REALPATH ./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 --disable-shared
--with-innodb

이하의 컴파일 옵션은,MySQL AB 하지만 일찌기 제공하고 있던 바이너리 패키지에 사용되고 있던 것입니다.이러한 바이너리는 현재는 갱신되고 있지 않습니다만, 참고를 위해서 여기에 컴파일 옵션을 기재합니다.

  • Linux 2.2.xx sparc with egcs 1.1.2

    CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-extra-charsets=complex --enable-thread-safe-client --enable-local-infile --enable-assembler --disable-shared

  • Linux 2.2.x with x686 with gcc 2.95.2

    CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler --with-mysqld-ldflags=-all-static --disable-shared --with-extra-charsets=complex

  • SunOS 4.1.4 2 sun4c with gcc 2.7.2.1

    CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors" ./configure --prefix=/usr/local/mysql --disable-shared --with-extra-charsets=complex --enable-assembler

  • SunOS 5.5.1 (and above) sun4u with egcs 1.0.3a or 2.90.27 or gcc 2.95.2 and newer

    CC=gcc CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql --with-low-memory --with-extra-charsets=complex --enable-assembler

  • SunOS 5.6 i86pc with gcc 2.8.1

    CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql --with-low-memory
--with-extra-charsets=complex

  • BSDI BSD/OS 3.1 i386 with gcc 2.7.2.1

    CC=gcc CXX=gcc CXXFLAGS=-O ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex

  • BSDI BSD/OS 2.1 i386 with gcc 2.7.2

    CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex

  • AIX 2 4 with gcc 2.7.2.2

    CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure
--prefix=/usr/local/mysql
--with-extra-charsets=complex

상기의 몇개의 설정에 관해서 한층 더 최적인 옵션을 가지고 계신 분은, 그 옵션을 MySQL 사내 메일링 리스트에 수시 전송해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 .

MySQL 버젼3.22 보다 전의 RPM 디스트리뷰션은, 유저에 의한 기증입니다.버젼 3.22 이?~ 의 RPM (은)는,MySQL AB 에 의해서 작성되고 있습니다.

MySQL 의 디버그 버젼을 컴파일 하는 경우는, 전술의 configure 행에 --with-debug 옵션 또는 --with-debug=full 옵션을 추가해, 모든 -fomit-frame-pointer 옵션을 삭제해 주세요.

Windows 디스트리뷰션에 대해서는, 항2.1.1. 「Windows 에의 MySQL 의 인스톨」 (을)를 참조해 주세요.

2.2.9. MySQL 바이너리 디스트리뷰션의 인스톨

여기에서는, 다양한 플랫폼용의 MySQL 바이너리 디스트리뷰션(.tar.gz 어카이브(archive))에 대해 설명합니다(상세한 일람에 대해서는, 항2.2.8. 「MySQL AB 하지만 컴파일 했다 MySQL 바이너리」 (을)를 참조해 주세요).

이러한 일반적인 패키지 외에, 선택한 플랫폼의 플랫폼 고유의 패키지 형식의 바이너리도 제공하고 있습니다. 이러한 패키지의 인스톨 방법의 상세한 것에 대하여는, 항2.1. 「표준 MySQL 의 퀵 인스톨」 (을)를 참조해 주세요.

일반적인 MySQL 바이너리 디스트리뷰션은,gzip 형식에서 압축되었다 GNU tar 어카이브(archive)(.tar.gz )(으)로서 패키지화되고 있습니다.MySQL 바이너리 디스트리뷰션을 인스톨 하기 위해서는 이하의 툴이 필요합니다.

  • 디스트리뷰션을 해동하기 위한 GNU gunzip .

  • 디스트리뷰션을 unpack하기 위한 적절한 tar 프로그램.GNU tar (은)는, 유효한 것으로 알려져 있다. operating system에 프리 인스톨 되고 있다 tar 실장안에는, 긴 파일명 등에 관한 문제가 발생하는 것이 알려져 있는 것이 있다(Sun tar 등).그 경우는, 우선 GNU tar (을)를 인스톨 한다.

문제가 발생했을 경우는,MySQL 메일링 리스트에 질문을 투고할 경우에, 반드시 mysqlbug (을)를 사용해 주세요 .그 문제가 버그가 아닌 경우에서도,mysqlbug (은)는, 다른 유저가 같은 문제를 해결할 때에 도움이 되는 시스템 정보를 수집합니다.mysqlbug (을)를 사용하지 않으면 문제를 해결할 수 있을 가능성이 작아집니다.디스트리뷰션을 unpack 하면,bin 디렉토리에 mysqlbug 하지만 격납됩니다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

MySQL 바이너리 디스트리뷰션을 인스톨 해 사용하기 위해서 실행할 필요가 있는 기본적인 커멘드는, 이하대로입니다.

shell> groupadd mysql
shell> useradd -g 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
shell> chown -R root  .
shell> chown -R mysql data
shell> chgrp -R mysql .
shell> bin/mysqld_safe --user=mysql &

4.0 보다 전의 버젼의 MySQL (을)를 사용하고 있는 경우는, 마지막 커멘드의 bin/mysqld_safe (을)를 bin/safe_mysqld 에 옮겨놓아 주세요.

DBI 및 DBD-mysql Perl 모듈을 인스톨 하고 있는 경우는,bin/mysql_setpermission 스크립트를 사용해 새로운 유저를 추가할 수 있습니다.

이하에 상세한 설명을 나타냅니다.

바이너리 디스트리뷰션을 인스톨 하려면 , 이하의 스텝에 따라서 처리를 실시한 후, 항2.4. 「인스톨 후의 설정과 테스트」 에 진행되어, 인스톨 후의 설정과 테스트를 실시합니다.

  1. 디스트리뷰션의 unpack처로 하는 디렉토리를 결정해 그 디렉토리로 이동한다.이하의 예에서는, 디스트리뷰션은 /usr/local 에 unpack 된다(따라서, 이?~ 의 조작 설명은,/usr/local 안에 파일 및 디렉토리를 작성하기 위한 액세스권을 유저가 가지고 있는 것을 전제로 해서 쓰여져 있다. 그 디렉토리가 보호되고 있는 경우는,root (으)로서 인스톨을 실행할 필요가 있다).

  2. 항2.2.1. 「MySQL 의 입수방법」 에 기재되어 있는 몇개의 사이트로부터 디스트리뷰션 파일을 입수한다.

    MySQL 바이너리 디스트리뷰션은, 압축되었다 tar 어카이브(archive)로서 제공되어mysql-VERSION-OS.tar.gz 등의 이름이 붙어 있다.이 경우,VERSION (은)는 버젼 번호(3.21.15 등)을 나타내,OS (은)는 그 디스트리뷰션이 대상으로 하는 operating system를 나타낸다(pc-linux-gnu-i586 등). 주의: 모든 바이너리는, 같다 MySQL 소스 디스트리뷰션으로부터 빌드 되고 있다

  3. mysqld 의 실행시에 사용하는 유저와 그룹을 추가한다.

    shell> groupadd mysql
shell> useradd -g mysql mysql

    상기의 커멘드로,mysql 그룹과 mysql 유저가 추가된다.useradd (와)과 groupadd 의 구문은,Unix 의 버젼의 종류에 의해서 조금 다르다.이러한 커멘드는, 각각,adduser 및 addgroup (으)로 불리기도 한다. 유저와 그룹을 mysql 이외의 이름으로 해도 상관없다.

  4. 이하의 커멘드로, 목적의 인스톨 디렉토리로 이동한다.

    shell> cd /usr/local

  5. 디스트리뷰션을 unpack 한다.이것에 의해서, 인스톨 디렉토리가 작성된다. 다음에, 그 디렉토리에의 기호 연결을 작성한다.

    shell> gunzip < /path/to/mysql-VERSION-OS.tar.gz | tar xvf -
shell> ln -s full-path-to-mysql-VERSION-OS mysql

    GNU tar (을)를 사용하고, 최초의 행을 이하의 대체 커멘드에 옮겨놓고, 디스트리뷰션의 전개와 추출을 한 번에 실시할 수도 있다.

    shell> tar zxvf /path/to/mysql-VERSION-OS.tar.gz

    최초의 커멘드로,mysql-VERSION-OS (이)라는 이름의 디렉토리가 작성된다.2 번째의 커멘드로, 그 디렉토리에의 기호 연결이 작성된다.이것에 의해서, 인스톨 디렉토리를 /usr/local/mysql (으)로서 보다 간단하게 참조할 수 있게 된다.

  6. 이하의 커멘드로, 인스톨 디렉토리로 이동한다.

    shell> cd mysql

    mysql 디렉토리내에는, 몇개의 파일과 서브 디렉토리가 있다. 인스톨을 위해서 가장 중요한 것은,bin 서브 디렉토리와 scripts 서브 디렉토리이다.

    • bin

      이 디렉토리에는 클라이언트 프로그램과 서버가 격납되고 있다. 쉘이 MySQL 프로그램을 올바르게 검색하도록(듯이),PATH 환경 변수에 이 디렉토리의 완전 패스명을 추가할 필요가 있다. See 부록 F. 환경 변수 .

    • scripts

      이 디렉토리에는, 서버 액세스권을 보존하는 권한 테이블이 격납되었다 mysql 데이타베이스의 초기화에 사용한다 mysql_install_db 스크립트가 격납되고 있다.

  7. mysqlaccess (을)를 사용하는 경우, 표준 이외의 장소에 MySQL 디스트리뷰션이 있을 때는,mysqlaccess 하지만 mysql 클라이언트를 검색하는 장소를 변경할 필요가 있다.18 행목정도에 있다 bin/mysqlaccess 스크립트를 편집한다.이하와 같은 행을 검색한다.

    $MYSQL     = '/usr/local/bin/mysql';    # path to mysql executable

    mysql 하지만 실제로 격납되고 있는 시스템내의 장소를 반영하도록(듯이) 패스를 변경한다.이 처리를 실시하지 않으면mysqlaccess (을)를 실행했을 때에 Broken pipe 그렇다고 하는 에러가 표시된다.

  8. 이하의 커멘드로,MySQL 권한 테이블을 작성한다(처음 MySQL (을)를 인스톨 하는 경우에게만 필요).

    shell> scripts/mysql_install_db

    주의: 버젼 3.22.10 보다 전의 MySQL 버젼에서는,mysql_install_db (을)를 실행하면 MySQL 서버가 기동되고 있었다.현버젼에서는,MySQL 서버는 기동되지 않는다.

  9. 바이너리의 소유자를 root (으)로 변경해, 데이터 디렉토리의 소유자를 mysqld 의 실행시에 사용하는 유저로 변경한다.

    shell> chown -R root  /usr/local/mysql/.
shell> chown -R mysql /usr/local/mysql/data
shell> chgrp -R mysql /usr/local/mysql/.

    최초의 커멘드로 파일의 owner 속성이 root 유저로 변경되어2 번째의 커멘드로 data 디렉토리의 owner 속성이 mysql 유저로 변경된다.3 번째의 커멘드로,group 속성이 mysql 그룹으로 변경된다.

  10. Perl 의 DBI/DBD 인터페이스의 서포트를 인스톨 하는 경우는, 항2.7. 「Perl 인스톨에 대한 코멘트」 (을)를 참조.

  11. 머신의 부트시에 MySQL (을)를 자동적으로 기동시키는 경우는, 사용하고 있는 시스템의 기동 파일이 격납되고 있는 장소에 support-files/mysql.server (을)를 카피한다.상세한 것에 대하여는,support-files/mysql.server 스크립트 자체와 항2.4.3. 「MySQL (을)를 자동적으로 기동 및 정?~ 한다」 (을)를 참조.

모든 것을 unpack 해 인스톨 하면, 디스트리뷰션의 초기화와 테스트를 실시해 주세요.

이하의 커멘드로 MySQL 서버를 기동할 수 있습니다.

shell> bin/mysqld_safe --user=mysql &

4.0 보다 전의 버젼의 MySQL (을)를 사용하고 있는 경우는, 이 커멘드의 bin/mysqld_safe (을)를 bin/safe_mysqld 에 옮겨놓아 주세요.

다음에, 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 에 진행되어,See 항2.4. 「인스톨 후의 설정과 테스트」 (을)를 참조해 주세요.


2.3. MySQL 소스 디스트리뷰션의 인스톨

소스의 인스톨에 진행되기 전에, 사용하고 있는 플랫폼용의 바이너리가 입수 가능할지와 그것이 자신의 시스템으로 잘 기능할지를 우선 확인합니다.당사는, 바이너리를 최적인 옵션으로 빌드 하도록(듯이) 진력하고 있습니다.

소스로부터 MySQL 빌드 해 인스톨 하기 위해서는 이하의 툴이 필요합니다.

  • 디스트리뷰션을 신장하기 위한 GNU gunzip .

  • 디스트리뷰션을 unpack하기 위한 적절한 tar 프로그램.GNU tar (은)는, 유효한 것으로 알려져 있다. operating system에 프리 인스톨 되고 있다 tar 실장안에는, 긴 파일명 등에 관한 문제가 발생하는 것이 알려져 있는 것이 있다(Sun tar 등).그 경우는, 우선 GNU tar (을)를 인스톨 한다.

  • 올바르게 기능한다 ANSI C++ 컴파일러.올바르게 기능하는 것이 알려져 있는 컴파일러로서는,2.95.2 이?~ 의 gcc ,1.0.2 이?~ 의 egcs ,egcs 2.91.66 ,SGI C++ , 및 SunPro C++ 등이 있다.gcc (을)를 사용하는 경우는,libg++ (은)는 필요없다.gcc 2.7.x 에는,sql/sql_base.cc 등의 전혀 문제가 없다 C++ 파일을 컴파일 할 수 없게 된다고 하는 버그가 있다.gcc 2.7.x 밖에 없는 경우,MySQL (을)를 컴파일 하기 위해서는,gcc (을)를 업그레이드 할 필요가 있다. gcc 또,2.8.1 (은)는, 일부의 플랫폼에서 문제가 발생하는 것이 알려져 있다.따라서, 사용하고 있는 플랫폼용의 새로운 컴파일러가 존재하는 경우는,2.8.1 의 사용은 피할 필요가 있다.

    MySQL 버젼 3.23.x (을)를 컴파일 하는 경우는,gcc 2.95.2 이?~ 의 사용을 추천 한다.

  • 적절한 make 프로그램.GNU make (은)는, 어느 경우에서도 추천 되는 것이어, 필수도 있다.문제가 있었을 경우는,GNU make 3.75 이?~ 의 사용을 추천한다.

-fno-exceptions 옵션을 인식할 수 있는 최신 버젼의 gcc (을)를 사용하고 있는 경우는, 이 옵션을 사용하는 것이 매우 중요 입니다.이 옵션을 사용하지 않으면 무질서하게 크래쉬 하는 바이너리를 컴파일 해 버리게 될 수 있습니다.또,-fno-exceptions (와)과 함께,-felide-constructors 및 -fno-rtti (을)를 사용하는 일도 추천합니다.판단이 서지 않는은, 이하를 실시해 주세요.

CFLAGS="-O3" CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions \
       -fno-rtti" ./configure --prefix=/usr/local/mysql --enable-assembler \
       --with-mysqld-ldflags=-all-static

대부분의 시스템에서는, 이것에 의해서 고속으로 안정된 바이너리가 제공됩니다.

문제가 발생했을 경우는,MySQL 메일링 리스트에 질문을 투고할 경우에, 반드시 mysqlbug (을)를 사용해 주세요 .그 문제가 버그가 아닌 경우에서도,mysqlbug (은)는, 다른 유저가 같은 문제를 해결할 때에 도움이 되는 시스템 정보를 수집합니다.mysqlbug (을)를 사용하지 않으면 문제를 해결할 수 있을 가능성이 작아집니다.디스트리뷰션을 unpack 하면,scripts 디렉토리에 mysqlbug 하지만 격납됩니다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

2.3.1. 퀵 인스톨의 개요

MySQL 소스 디스트리뷰션을 인스톨 하기 위해서 실행할 필요가 있는 기본적인 커멘드는, 이하대로입니다.

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> scripts/mysql_install_db
shell> chown -R root  /usr/local/mysql
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql
shell> cp support-files/my-medium.cnf /etc/my.cnf
shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &

버젼 4.0 보다 전의 MySQL (을)를 사용하고 있는 경우는, 마지막 커멘드의 bin/mysqld_safe (을)를 bin/safe_mysqld 에 옮겨놓아 주세요.

InnoDB 테이블의 서포트가 필요한 경우는,/etc/my.cnf 파일을 편집하고,innodb_... 그리고 시작되는 파라미터의 전에 있다 # 문자를 삭제해 주세요. See 항4.1.2. 「my.cnf 옵션 설정 파일」 (와)과 항7.5.3. 「InnoDB 기동 옵션」 (을)를 참조해 주세요.

소스 RPM (으)로부터 개시하는 경우는, 이하의 커멘드를 실행합니다.

shell> rpm --rebuild --clean MySQL-VERSION.src.rpm

이것에 의해서, 인스톨 할 수 있는 바이너리 RPM 하지만 작성됩니다.

DBI 및 DBD-mysql Perl 모듈을 인스톨 하고 있는 경우는,bin/mysql_setpermission 스크립트를 사용해 새로운 유저를 추가할 수 있습니다.

이하에 상세한 설명을 나타냅니다.

소스 디스트리뷰션을 인스톨 하려면 , 이하의 스텝에 따라서 처리를 실시한 후, 항2.4. 「인스톨 후의 설정과 테스트」 에 진행되어, 포스트인스톨 초기화와 테스트를 실시합니다.

  1. 디스트리뷰션의 unpack처로 하는 디렉토리를 결정해 그 디렉토리로 이동한다.

  2. 항2.2.1. 「MySQL 의 입수방법」 에 기재되어 있는 몇개의 사이트로부터 디스트리뷰션 파일을 입수한다.

  3. MySQL 그리고 Berkeley DB 테이블을 사용하는 것을 생각하고 있는 경우는,Berkeley DB 원시 코드의 패치 적용이 끝난 버젼을 입수할 필요가 있다.다음에 진행되기 전에,Berkeley DB 테이블에 관한 장을 읽는 것을 추천한다. See 항7.6. 「BDB 또는 BerkeleyDB 테이블」 .

    MySQL 소스 디스트리뷰션은,tar 형식의 압축 어카이브(archive)로서 제공되어mysql-VERSION.tar.gz 등의 이름이 붙어 있다.이 경우,VERSION (은)는,5.0.6-beta 등의 버젼 번호이다.

  4. mysqld 의 실행시에 사용하는 유저와 그룹을 추가한다.

    shell> groupadd mysql
shell> useradd -g mysql mysql

    상기의 커멘드로,mysql 그룹과 mysql 유저가 추가된다.useradd (와)과 groupadd 의 구문은,Unix 의 버젼의 종류에 의해서 조금 다르다.이러한 커멘드는, 각각,adduser 및 addgroup (으)로 불리기도 한다. 유저와 그룹을 mysql 이외의 이름으로 해도 상관없다.

  5. 디스트리뷰션을 커런트 디렉토리에 unpack 한다.

    shell> gunzip < /path/to/mysql-VERSION.tar.gz | tar xvf -

    이 커멘드에 의해서,mysql-VERSION (이)라는 이름의 디렉토리가 작성된다.

  6. unpack 한 디스트리뷰션의 최상위디렉토리로 이동한다.

    shell> cd mysql-VERSION

    주의: 현시점에서는, 최상위디렉토리로부터 MySQL (을)를 콘피개 해 빌드 한다.다른 디렉토리에서 MySQL (을)를 빌드 할 수 없다.

  7. 콘피개 하고, 컴파일 한다.

    shell> ./configure --prefix=/usr/local/mysql
shell> make

    configure (을)를 실행할 경우에, 몇개의 옵션을 지정할 수 있다. 옵션의 일람이 필요한 경우는,./configure --help (을)를 실행한다. 항2.3.3. 「일반적인 configure 옵션」 그럼, 한층 더 편리한 몇개의 옵션에 대해 설명한다.

    configure 하지만 실패해,MySQL 메일링 리스트에 메일을 송신하고 지원을 요구하는 경우는,config.log 안의, 문제의 해결에 도움이 된다고 생각되는 행을 메일에 포함한다.configure 하지만 중단했을 경우는,configure (으)로부터의 출력의 마지막 2 ,3 행도 포함한다.mysqlbug 스크립트를 사용하고, 버그 리포트를 투고한다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

    컴파일이 실패했을 경우는, 항2.3.5. 「MySQL 의 컴파일에 관한 문제에의 대처」 그리고, 수많은 일반적인 문제에 관한 헬프를 참조.

  8. 이하의 커멘드로, 모든 것을 인스톨 한다.

    shell> make install

    이 커멘드는,root (으)로서 실행할 필요가 있는 경우가 있다.

  9. 이하의 커멘드로,MySQL 권한 테이블을 작성합니다(처음 MySQL (을)를 인스톨 하는 경우에게만 필요).

    shell> scripts/mysql_install_db

    주의: 버젼 3.22.10 보다 전의 MySQL 버젼에서는,mysql_install_db (을)를 실행하면 MySQL 서버가 기동되고 있었다.현버젼에서는,MySQL 서버는 기동되지 않는다.

  10. 바이너리의 소유자를 root (으)로 변경해, 데이터 디렉토리의 소유자를 mysqld 의 실행시에 사용하는 유저로 변경한다.

    shell> chown -R root  /usr/local/mysql
shell> chown -R mysql /usr/local/mysql/var
shell> chgrp -R mysql /usr/local/mysql

    최초의 커멘드로 파일의 owner 속성이 root 유저로 변경되어2 번째의 커멘드로 데이터 디렉토리의 owner 속성이 mysql 유저로 변경된다.3 번째의 커멘드로,group 속성이 mysql 그룹으로 변경된다.

  11. Perl 의 DBI/DBD 인터페이스의 서포트를 인스톨 하는 경우는, 항2.7. 「Perl 인스톨에 대한 코멘트」 (을)를 참조.

  12. 머신의 부트시에 MySQL (을)를 자동적으로 기동시키는 경우는, 사용하고 있는 시스템의 기동 파일이 격납되고 있는 장소에 support-files/mysql.server (을)를 카피한다.상세한 것에 대하여는,support-files/mysql.server 스크립트 자체와 항2.4.3. 「MySQL (을)를 자동적으로 기동 및 정?~ 한다」 (을)를 참조.

모든 것을 인스톨 하면, 이하의 커멘드를 사용해 디스트리뷰션의 초기화와 테스트를 실시해 주세요.

shell> /usr/local/mysql/bin/mysqld_safe --user=mysql &

버젼 4.0 보다 전의 MySQL (을)를 사용하고 있는 경우는, 이 커멘드의 mysqld_safe (을)를 safe_mysqld 에 옮겨놓아 주세요.

그 커멘드가,mysqld daemon ended 그렇다고 하는 에러로 곧바로 실패했을 경우는, 파일 mysql-data-directory/'hostname'.err 에 어떠한 정보가 기술되고 있습니다. 원인으로서는, 벌써 다른 mysqld 서버를 실행하고 있는 것을 생각할 수 있습니다. See 항4.2. 「같은 머신상에서 복수의 MySQL 서버를 실행한다」 .

다음에, 항2.4. 「인스톨 후의 설정과 테스트」 에 진행됩니다.

2.3.2. 패치의 적용

패치는, 메일링 리스트 또는 MySQL 의 Web 사이트(http://www.mysql.com/downloads/patches.html )의 「patches 」에리어에 가끔 공개됩니다.

메일링 리스트에 있는 패치를 적용하려면 , 패치가 포함된 메세지를 파일에 보존해,MySQL 소스 트리의 최상위디렉토리로 이동해 이하의 커멘드를 실행합니다.

shell> patch -p1 < patch-file-name
shell> rm config.cache
shell> make clean

FTP 사이트에 있는 패치는, plaintext 파일 또는 gzip 그리고 압축된 파일로서 배포됩니다.plaintext의 패치의 적용은, 메일링 리스트의 패치의 개소에서 설명한 방법으로 실시합니다.압축된 패치를 적용하려면 ,MySQL 소스 트리의 최상위디렉토리로 이동하고, 이하의 커멘드를 실행합니다.

shell> gunzip < patch-file-name.gz | patch -p1
shell> rm config.cache
shell> make clean

패치를 적용한 후에, 통상의 소스 인스톨 순서에 따릅니다만,./configure 스텝으로부터 개시합니다.make install 스텝을 실행하면,MySQL 서버를 재기동합니다.

make install (을)를 실행하기 전에, 현재 가동하고 있는 서버를 정?~ 시킬 필요가 있습니다(서버를 정?~ 시키려면 mysqladmin shutdown (을)를 사용합니다).일부의 시스템에서는, 새로운 버젼의 프로그램이 현재 실행되고 있는 버젼을 옮겨놓는 경우는, 새로운 버젼의 인스톨이 허가되지 않는 것이 있습니다.

2.3.3. 일반적인 configure 옵션

configure 스크립트를 사용하면,MySQL 디스트리뷰션의 설정을 자유롭게 조정할 수 있습니다.설정 방법법의 조정은, 통상은 configure 커멘드 라인으로 옵션을 사용해 실시합니다.또, 환경 변수를 사용해 configure (을)를 조정할 수도 있습니다.See 부록 F. 환경 변수 . configure 하지만 서포트하는 옵션의 일람이 필요한 경우는, 이하의 커멘드를 실행합니다.

shell> ./configure --help

여기에서는, 넓게 사용되고 있다 configure 옵션의 일부를 설명합니다.

  • MySQL 의 클라이언트 라이브러리와 클라이언트 프로그램만을 컴파일 하고, 서버를 컴파일 하지 않는 경우는, 이하와 같이 --without-server 옵션을 사용한다.

    shell> ./configure --without-server

    C++ 컴파일러가 없는 경우는,mysql (은)는 컴파일을 실행하지 않는다(mysql 하 C++ (을)를 필요로 하는 유일한 클라이언트 프로그램) .그 경우는,configure 의,C++ 컴파일러를 테스트하는 코드를 삭제해,--without-server 옵션을 지정해 ./configure (을)를 실행한다.compile 스텝은 여전히 mysql 의 빌드를 시행하지만,mysql.cc 에 관한 경고는 무시해도 상관없다(make 하지만 정?~ 하면,make -k (을)를 실행하고, 에러가 발생해도 나머지의 빌드를 속행하도록 지시한다).

  • 편입의 MySQL 서버 라이브러리(libmysqld.a )(이)가 필요한 경우는,--with-embedded-server 옵션을 사용한다.

  • 로그 파일과 데이타베이스 디렉토리를 /usr/local/var 의 아래에 배치하지 않는 경우는, 이하의 언젠가 와 유사했다 configure 커멘드를 사용한다.

    shell> ./configure --prefix=/usr/local/mysql
shell> ./configure --prefix=/usr/local \
           --localstatedir=/usr/local/mysql/data

    최초의 커멘드에서는, 디폴트의 /usr/local (은)는 아니고 /usr/local/mysql 에 모든 것이 인스톨 되도록(듯이) 인스토르프리픽스가 변경된다.2 번째의 커멘드에서는, 디폴트의 인스토르프리픽스는 유지되지만, 데이타베이스 디렉토리의 디폴트의 장소(통상은 /usr/local/var )(이)가 무효로 되어/usr/local/mysql/data (으)로 변경된다.이러한 옵션은,MySQL (을)를 컴파일 한 후에, 옵션 설정 파일로 변경할 수 있다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

  • Unix (을)를 사용하고 있어,MySQL 소켓 파일을 디폴트의 장소(통상은,/tmp 또는 /var/run ) 이외의 장소에 배치하는 경우는, 이하와 같은 configure 커멘드를 사용한다.

    shell> ./configure --with-unix-socket-path=/usr/local/mysql/tmp/mysql.sock

    주의: 지정하는 파일은 절대 패스명이 아니면 안된다. 또, 다음에 MySQL 옵션 설정 파일을 사용하고, 장소 mysql.sock (을)를 변경할 수도 있다. See 항A.4.5. 「MySQL 소켓 파일 /tmp/mysql.sock 의 보호 또는 변경 방법」 .

  • 정적으로 링크된 프로그램을 컴파일 하는 경우(바이너리 디스트리뷰션의 작성, 고속화, 일부의 Red Hat Linux 디스트리뷰션의 문제의 회피등을 (위해)때문에에), 이하와 같은 configure 커멘드를 실행합니다.

    shell> ./configure --with-client-ldflags=-all-static \
           --with-mysqld-ldflags=-all-static

  • gcc (을)를 사용하고 있어,libg++ 또는 libstdc++ 하지만 인스톨 되어 있지 않은 경우,C++ 컴파일러로서 gcc (을)를 사용하도록(듯이) configure (을)를 설정할 수 있다.

    shell> CC=gcc CXX=gcc ./configure

    C++ 컴파일러로서 gcc (을)를 사용하면,libg++ 또는 libstdc++ 에의 링크는 시행되지 않는다.상기의 라이브러리가 인스톨 되고 있는 경우에서도, 이러한 라이브러리의 일부의 버젼은 과거에 MySQL 유저에게 있어서 미지의 문제를 일으켰던 적이 있으므로, 이와 같이 처리하는 것을 추천한다.

    이하에, 사용하고 있는 컴파일러에 따라 설정하는 일반적인 환경 변수를 몇개인가 나타내 보인다.

    컴파일러 | 추천 옵션
    gcc 2.7.2.1 | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors"
    egcs 1.0.3a | CC=gcc CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti"
    gcc 2.95.2 | CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -felide-constructors -fno-exceptions -fno-rtti"
    pgcc 2.90.29 이?~ | CFLAGS="-O3 -mpentiumpro -mstack-align-double" CXX=gcc CXXFLAGS="-O3 -mpentiumpro -mstack-align-double -felide-constructors -fno-exceptions -fno-rtti"

    대부분의 경우, 상기의 겉(표)에 기재되어 있는 옵션을 사용하고,configure 행에 이하의 옵션을 추가하고,MySQL 바이너리를 적당히 최적화할 수 있다.

    --prefix=/usr/local/mysql --enable-assembler \
--with-mysqld-ldflags=-all-static

    즉, 최신의 모든 gcc 버젼 전용의 완전한 configure 행은, 이하와 같은 것이 된다.

    CFLAGS="-O3 -mpentiumpro" CXX=gcc CXXFLAGS="-O3 -mpentiumpro \
-felide-constructors -fno-exceptions -fno-rtti" ./configure \
--prefix=/usr/local/mysql --enable-assembler \
--with-mysqld-ldflags=-all-static

    당사가 MySQL Web 사이트(http://www.mysql.com/ )(으)로 제공하는 바이너리는 모두, 완전하게 최적화되어 컴파일 되고 있어 대부분의 유저에게 있어서 최적이다.See 항2.2.8. 「MySQL AB 하지만 컴파일 했다 MySQL 바이너리」 . 한층 더 고속의 바이너리를 작성하기 위해서 유저가 미조정할 수 있는 설정이 몇개인가 있지만, 이것은 상급 유저 전용이다. See 항5.5.3. 「MySQL 의 속도에 대한 컴파일과 링크의 영향」 .

    빌드가 실패해, 컴파일러 또는 링커가 공유 라이브러리 libmysqlclient.so.# (‘# ＇ (은)는 버젼 번호입니다)를 작성할 수 없다고 하는 에러가 생성되었을 경우는,configure 에 --disable-shared 옵션을 지정해 이 문제에 대처할 수 있다.이 경우,configure (은)는 공유 라이브러리 libmysqlclient.so.# (을)를 빌드 하지 않는다.

  • 비 NULL 속성의 컬럼(즉,NULL (으)로 하는 것이 허락되지 않는 컬럼)에 DEFAULT 의 값을 사용하지 않게 MySQL (을)를 콘피개 할 수 있다. See 항1.8.5.2. 「NOT NULL 및 DEFAULT 값제약」 .

    shell> CXXFLAGS=-DDONT_USE_DEFAULT_FIELDS ./configure

  • MySQL (은)는, 디폴트로 ISO-8859-1 (Latin1) 캐릭터 세트를 사용한다.디폴트의 캐릭터 세트를 변경하려면 , 이하와 같이 --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 의 언젠가이다. See 항4.7.1. 「데이터 및 소트용 캐릭터 세트」 .

    서버와 클라이언트의 사이에 문자를 변환하는 경우는,SET CHARACTER SET 커멘드에 주목한다. See 항5.5.6. 「SET 구문」 .

    경고: 테이블을 작성한 후로 캐릭터 세트를 변경하는 경우는, 모든 테이블로 myisamchk -r -q --set-character-set=charset (을)를 실행할 필요가 있다.이것을 실시하지 않으면 인덱스가 올바르고 소트 되지 않는 것이 있다(MySQL (을)를 인스톨 해, 몇개의 테이블을 작성해, 다른 캐릭터 세트를 사용하도록(듯이) MySQL (을)를 콘피개 다시 하고, 그 MySQL (을)를 재인스톨 했을 경우에, 이 문제가 일어날 가능성이 있다).

    --with-extra-charsets=LIST 옵션을 사용하고, 서버에 컴파일 하는 추가의 캐릭터 세트를 정의할 수 있다.

    이 경우,LIST (은)는, 콤마로 단락지은 캐릭터 세트의 리스트, 동적으로 로드할 수 없는 모든 문자를 포함하기 위한 complex , 또는 모든 캐릭터 세트를 바이너리에 포함하기 위한 all 의 언젠가이다.

  • 코드를 디버그 하도록(듯이) MySQL (을)를 콘피개 하려면 ,--with-debug 옵션을 사용한다.

    shell> ./configure --with-debug

    이것에 의해서, 에러를 검출해, 에러의 내용에 관한 출력을 제공하는 안전한 메모 리어 locator가 짜넣어진다. See 항E.1. 「MySQL 서버의 디버그」 .

  • 클라이언트 프로그램이 스레드를 사용하는 경우,--enable-thread-safe-client configure 옵션을 사용하고,MySQL 클라이언트 라이브러리의 스레드세이후바젼을 컴파일 할 필요도 있다.이것에 의해서, 스레드아프리케이션과 링크시킨다 libmysqlclient_r 라이브러리가 작성된다. See 항11.1.14. 「스레드 클라이언트의 작성 방법」 .

  • 특정의 시스템에 관계하는 옵션에 대해서는, 이 메뉴얼의 시스템 고유의 섹션을 참조. See 항2.6. 「 operating system 고유의 주의 사항」 .

2.3.4. 개발 소스 트리로부터의 인스톨

주의: 이 섹션은, 당사의 새로운 코드의 테스트에 협력하는 것에 관심이 있는 경우에게만 읽어 주세요.MySQL (을)를 빌드 해 시스템상에서 가동시킬 만한 경우는, 표준의 릴리스 디스트리뷰션(소스 디스트리뷰션 또는 바이너리 디스트리뷰션)을 사용해 주세요.

최신의 개발 소스 트리를 입수하려면 , 이하의 설명에 따라 주세요.

  1. http://www.bitmover.com/cgi-bin/download.cgi (으)로부터 BitKeeper (을)를 다운로드한다.당사의 리포지터리(repository)에 액세스 하려면 ,Bitkeeper 3.0 이?~ 하지만 필요하다.

  2. 지시에 따라서, 다운로드했다 BitKeeper (을)를 인스톨 한다.

  3. BitKeeper (을)를 인스톨 하면, 우선, 작업하는 디렉토리로 이동한다.다음에, 이하의 몇개의 커멘드를 사용하고, 필요한 MySQL 버젼 브랜치를 카피한다.

    3.23 ( 구버젼) 브랜치를 카피하려면 , 이하의 커멘드를 사용한다.

    shell> bk clone bk://mysql.bkbits.net/mysql-3.23 mysql-3.23

    4.0 (안정판/ 제품판) 브랜치를 카피하려면 , 이하의 커멘드를 사용한다.

    shell> bk clone bk://mysql.bkbits.net/mysql-4.0 mysql-4.0

    4.1 alpha 브랜치를 카피하려면 , 이하의 커멘드를 사용한다.

    shell> bk clone bk://mysql.bkbits.net/mysql-4.1 mysql-4.1

    5.0 개발 브랜치를 카피하려면 , 이하의 커멘드를 사용한다.

    shell> bk clone bk://mysql.bkbits.net/mysql-5.0 mysql-5.0

    상기의 예에서는, 커런트 디렉토리의,mysql-3.23/ ,mysql-4.0/ ,mysql-4.1/ ,mysql-5.0/ 의 몇개의 서브 디렉토리에 소스 트리가 셋업 된다.

    파이어 월(fire wall)의 배후에 있고,HTTP 접속 밖에 개시할 수 없는 경우는,HTTP (을)를 통해서 BitKeeper (을)를 사용할 수도 있다.

    프록시 서버를 사용할 필요가 있는 경우는, 사용하는 프록시를 가리키도록(듯이) 환경 변수 http_proxy (을)를 설정한다

    shell> export http_proxy="http://your.proxy.server:8080/"

    다음에, 카피를 실행할 경우에,bk:// (을)를 http:// 에 옮겨놓는다.예를 들어, 이하와 같이 지정한다.

    shell> bk clone http://mysql.bkbits.net/mysql-4.1 mysql-4.1

    접속의 속도에 의해서, 소스 트리의 초기 다운로드에는 다소 시간이 걸리는 일이 있다.

  4. 다음의 일련의 커멘드를 실행하려면 ,GNU make ,autoconf 2.53 ( 이?~) ,automake 1.5 ,libtool 1.4 , 및 m4 하지만 필요하다.많은 operating system에는 독자적인 make 실장이 탑재되고 있지만, 미지의 에러 메세지가 출력되어 컴파일이 실패할 가능성이 높다.따라서, 반드시 GNU make (gmake (으)로 불리기도 한다)를 사용한다.

    다행히, 많은 operating system는 GNU 툴 체인이 프리 인스톨 되고 있는지, 인스톨 가능한 GNU 툴의 패키지를 제공한다.어느 경우도, 이하의 장소로부터 다운로드할 수도 있다.

    • http://www.gnu.org/software/autoconf/

    • http://www.gnu.org/software/automake/

    • http://www.gnu.org/software/libtool/

    • http://www.gnu.org/software/make/

    MySQL 4.1 (을)를 콘피개 하는 경우는,GNU bison 1.75 도 필요하다.구버젼의 bison (은)는, 다음과 같은 에러를 보고하는 일이 있다. sql_yacc.yy:#####: fatal error: maximum table size (32767) exceeded . 주의: 실제로 최대 테이블 사이즈를 초과하고 있는 것은 아니다.이 에러는, 구버젼의 bison 의 버그가 원인으로 발생한다.

    버젼 4.1 보다 전의 MySQL 버젼은, 다른 yacc 실장(BSD yacc 91.7.30 등)에 의해도 컴파일 한다.4.1 이?~ 의 버젼의 경우는,GNU bison (은)는 필요 조건이다.

    쉘로 실행하는 표준적인 커멘드는 이하대로이다.

    cd mysql-4.0
bk -r edit
aclocal; autoheader; autoconf; automake
(cd innobase; aclocal; autoheader; autoconf; automake) # for InnoDB
(cd bdb/dist; sh s_all ) # for Berkeley DB
./configure  # Add your favorite options here
make

    이 단계에서 미지의 에러가 발생했을 경우는,libtool 하지만 실제로 인스톨 되고 있는지 어떤지를 체크한다.

    당사의 표준 configure 스크립트의 콜렉션은,BUILD/ 서브 디렉토리에 있다.수고를 생략하고 싶은 경우는,BUILD/compile-pentium-debug (을)를 사용할 수도 있다.다른 Archie 텍 차상에서 컴파일 하려면 , 이 스크립트로부터 Pentium 고유의 플래그를 삭제해 수정한다.

  5. 빌드가 완료하면,make install (을)를 실행한다.실가동 머신상에서 이것을 실시하는 경우는, 이 커멘드에 의해서 가동중의 릴리스 인스톨이 덧쓰기된다고 하는 점에 주의한다.다른 MySQL 하지만 인스톨 되고 있는 경우는,prefix ,with-tcp-port ,unix-socket-path 의 각 옵션에 실가동 서버로 사용하고 있는 값과 다른 값을 설정하고,./configure (을)를 실행하는 것을 추천한다.

  6. 새로운 인스톨을 혹사 하고, 새로운 기능을 크래쉬 시켜 본다.make test 의 실행으로부터 시작한다. See 항13.1.2. 「MySQL 테스트 스위트」 .

  7. make 의 단계에 도달해도, 디스트리뷰션이 컴파일 할 수 없는 경우는,http://bugs.mysql.com/ 에 있는 버그 데이타베이스에 보고를 부탁하고 싶다.필요한 GNU 툴의 최신 버젼이 인스톨 되고 있고, 그러한 툴이 설정 파일의 처리중에 크래쉬 하는 경우도 마찬가지이다. 다만,aclocal (을)를 실행해 command not found 그렇다고 하는 에러나 유사한 문제가 발생했을 경우는, 보고는 불필요하다.대신에, 필요한 툴이 모두 인스톨 되고 있는지 어떤지라고 쉘이 그러한 툴을 검출할 수 있도록 PATH 변수가 올바르게 설정되어 있는지 어떤지를 확인한다.

  8. 소스 트리를 취득하기 위한 최초의 bk clone 조작의 뒤, 정기적으로 bk pull (을)를 실행해 갱신을 입수한다.

  9. bk sccstool (을)를 사용하고, 트리의 변경 이력으로 모든 diff (을)를 조사할 수 있다.불명한 diff (이)나 코드가 있었을 경우는,MySQL 의 내부 메일링 리스트에 메일을 전송해 주셨으면 싶다. See 항1.7.1.1. 「MySQL 메일링 리스트」 . 또, 무언가에 관한 수정안이 있는 경우도, 같은 주소에 패치를 첨부한 메일을 전송해 주셨으면 싶다. bk diffs (은)는, 유저가 소스를 변경하면 패치를 작성해 준다.아이디어를 코드로 할 시간이 없는 경우는, 설명만으로도 전송해 주셨으면 싶다.

  10. BitKeeper 에는,bk helptool (을)를 사용해 액세스 할 수 있는 편리한 헬프 유틸리티가 있다.

  11. 주의: 어느 코?~ 트(bk ci 또는 bk citool )도, 당사의 내부 메일링 리스트에의 체인지 세트를 포함한 메세지의 투고나,ChangeSet 코멘트만이 포함된 통상의 openlogging.org 서브?~ 션을 Trigger 할 것은 없다. 일반적으로, 코?~ 트를 사용할 필요는 없다(공개 트리는 bk push (을)를 허가하지 않기 때문에)가, 전술했다 bk diffs 메소드는 사용한다.

ChangeSet , 코멘트, 원시 코드는, 예를 들어 MySQL 4.1 의 경우는 http://mysql.bkbits.net:8080/mysql-4.1 그리고 검색할 수도 있습니다.

메뉴얼은, 독립한 트리에 격납되고 있습니다.이 트리는, 이하의 커멘드를 사용해 카피할 수 있습니다.

shell> bk clone bk://mysql.bkbits.net/mysqldoc mysqldoc

MySQL Control Center (와)과 Connector/ODBC 의 공개 BitKeeper 트리도 있습니다.이러한 트리는, 각각 이하의 커멘드로 카피할 수 있습니다.

MySQL Control Center (을)를 카피하려면 , 이하의 커멘드를 사용해 주세요.

shell> bk clone http://mysql.bkbits.net/mysqlcc mysqlcc

Connector/ODBC (을)를 카피하려면 , 이하의 커멘드를 사용해 주세요.

shell> bk clone http://mysql.bkbits.net/myodbc3 myodbc3

2.3.5. MySQL 의 컴파일에 관한 문제에의 대처

모든 MySQL 프로그램은,gcc (을)를 사용하고,Solaris 또는 Linux 위에서 경고를 받아들이는 일 없이 예쁘게 컴파일 할 수 있습니다.다른 시스템상에서는, 시스템 인클루드 파일의 차이가 원인으로 경고가 발생하는 일이 있습니다.MIT-pthreads (을)를 사용하고 있는 경우에 발생할 가능성이 있는 경고에 대해서는, 항2.3.6. 「MIT-pthreads 에 관한 주의 사항」 (을)를 참조해 주세요.그 이외의 문제에 대해서는, 이하의 일람을 체크해 주세요.

많은 문제는, 해결에 재 configure 하지만 필요합니다. 재 configure 하지만 필요한 경우는, 이하의 점에 유의해 주세요.

  • configure (을)를 1 번실행한 후에 이제(벌써) 1 번실행하면, 전회의 기동시에 수집한 정보를 사용하는 일이 있다.이 정보는,config.cache 에 격납되고 있다.configure (은)는, 기동시에 이 파일을 찾아, 파일이 존재하는 경우는, 그 정보가 현재도 적절한 것과 상정해 파일의 내용을 읽어낸다. 재 configure 하는 경우는, 이 상정은 무효이다.

  • configure (을)를 실행할 때마다 make (을)를 실행해 재컴파일 할 필요가 있다.다만, 이전의 빌드가 낡은 오브젝트 파일은 다른 설정 옵션을 사용해 컴파일 되고 있으므로, 최초로 그러한 오브젝트 파일을 삭제할 필요가 있다.

낡은 검출 정보나 오브젝트 파일이 사용되는 것을 막기 위해서,configure (을)를 재실행하기 전에 이하의 커멘드를 실행합니다.

shell> rm config.cache
shell> make clean

또는,make distclean (을)를 실행합니다.

이하의 일람으로,MySQL 의 컴파일가끔 자주(잘) 발생하는 것을 알 수 있고 있는 몇개의 문제를 설명합니다.

  • sql_yacc.cc 의 컴파일시에 여기에 나타나고 있는 에러가 발생했을 경우는, 메모리 또는 스왑 영역이 부족할 가능성이 있다.

    Internal compiler error: program cc1plus got fatal signal 11

인가
Out of virtual memory

인가
Virtual memory exhausted

    여기서 문제인 것은,gcc 하지만 인 라인 함수를 갖추었다 sql_yacc.cc (을)를 컴파일 하기 위해서 대량의 메모리를 필요로 하는 것이다.--with-low-memory 옵션을 지정해 configure (을)를 실행한다.

    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++ 에 관련한 컴파일시의 문제가 발생하기도 한다.

    이러한 문제의 원인의 1 개는,g++ 하지만 없는지,g++ 하지만 있어도 libg++ 또는 libstdc++ 하지만 없는 것이다.config.log 파일을 조사하면, 이 파일에,C++ 컴파일러가 기능하지 않는 정확한 이유가 기술되고 있을 것이다.이러한 문제에 대처하기 위해서,C++ 컴파일러로서 gcc (을)를 사용할 수 있다.환경 변수 CXX (을)를 "gcc -O3" (으)로 한다.예를 들어, 이하와 같이 지정한다.

    shell> CXX="gcc -O3" ./configure

    gcc (은)는,g++ (와)과 같게 C++ 소스를 컴파일 하지만, 디폴트에서는 libg++ 또는 libstdc++ 에는 링크하지 않는다.

    당연히, 이러한 문제를 수정하는 이제(벌써) 1 개의 방법은,g++ ,libg++ , 및 libstdc++ (을)를 인스톨 하는 것이다.그러나,libg++ 또는 libstdc++ (을)를 MySQL (와)과 함께 사용하는 것은 추천하지 않는다.mysqld 의 바이너리 사이즈를 늘리는 것만으로 아무 이점도 없기 때문이다. 이러한 라이브러리의 버젼안에는,MySQL 유저에게 있어서 미지의 문제를 과거에 일으킨 것도 있다.

    GNU gcc 버젼 3 이?~ (을)를 사용하고 있어,RAID 기능(RAID 테이블형의 상세한 것에 대하여는 항6.5.3. 「CREATE TABLE 구문」 (을)를 참조)를 짜넣었다 MySQL (을)를 컴파일 하는 경우도,C++ 컴파일러로서 gcc (을)를 사용할 필요가 있다.--with-raid 옵션을 사용해 컴파일 하도록(듯이) MySQL (을)를 콘피개 하고 있을 때, 링크 단계에서 이하의 몇개의 같은 에러가 발생했을 경우는, 전술의 환경 변수 CXX (을)를 정의해 C++ 컴파일러로서 gcc (을)를 사용해 본다.

    gcc -O3 -DDBUG_OFF -rdynamic -o isamchk isamchk.o sort.o  libnisam.a
../mysys/libmysys.a ../dbug/libdbug.a ../strings/libmystrings.a -lpthread
-lz -lcrypt -lnsl -lm -lpthread
../mysys/libmysys.a(raid.o)(.text+0x79): In function `my_raid_create':
: undefined reference to `operator new(unsigned)'
../mysys/libmysys.a(raid.o)(.text+0xdd): In function `my_raid_create':
: undefined reference to `operator delete(void*)'
../mysys/libmysys.a(raid.o)(.text+0x129): In function `my_raid_open':
: undefined reference to `operator new(unsigned)'
../mysys/libmysys.a(raid.o)(.text+0x189): In function `my_raid_open':
: undefined reference to `operator delete(void*)'
../mysys/libmysys.a(raid.o)(.text+0x64b): In function `my_raid_close':
: undefined reference to `operator delete(void*)'
collect2: ld returned 1 exit status

  • 이하의 몇개의 같은 에러로 컴파일이 실패했을 경우는,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

    Solaris (와)과 FreeBSD (은)는, 복잡한 make 프로그램이 짜넣어지고 있는 것으로 알려져 있다.

    GNU make 버젼 3.75 (은)는, 정상적으로 기능하는 것이 알려져 있다.

  • C 컴파일러 또는C++ 컴파일러가 사용하는 플래그를 정의하는 경우는,CFLAGS 및 CXXFLAGS 그렇다고 하는 환경 변수에 그러한 플래그를 추가해 정의한다.같이CC 및 CXX (을)를 사용해 컴파일러명을 지정할 수도 있다.이하에 예를 나타낸다.

    shell> CC=gcc
shell> CFLAGS=-O3
shell> CXX=gcc
shell> CXXFLAGS=-O3
shell> export CC CFLAGS CXX CXXFLAGS

    다양한 시스템으로 유용하다라고 하는 것이 알고 있는 플래그의 일람에 대해서는, 항2.2.8. 「MySQL AB 하지만 컴파일 했다 MySQL 바이너리」 (을)를 참조.

  • 이하와 같은 에러 메세지가 출력되었을 경우는,gcc 컴파일러를 업그레이드 할 필요가 있다.

    client/libmysql.c:273: parse error before `__attribute__'

    gcc 2.8.1 (은)는 올바르게 기능하는 것이 알려져 있지만, 당사에서는 gcc 2.95.X 의 사용을 추천한다.

  • 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

    사용하고 있는 operating system에 따르고,XXX (을)를 size_t 또는 int (으)로 변경한다(주의: configure 하 config.h (을)를 생성하므로,configure (을)를 실행할 때마다 이 처리를 실시할 필요가 있다).

  • sql_yacc.cc 파일은,sql_yacc.yy (으)로부터 생성된다.MySQL 에는 생성 끝난 카피가 부속되어 있으므로, 통상은 빌드 프로세스가 sql_yacc.cc (을)를 작성할 필요는 없다.다만, 이 파일을 재작성할 필요가 있는 경우는, 이하의 에러가 출력된다.

    "sql_yacc.yy", line xxx fatal: default action causes potential...

    이 에러는, 사용하고 있다 yacc 의 버젼으로는 불충분한 것을 나타내고 있다. 대부분의 경우,bison (GNU 버젼의 yacc )(을)를 인스톨 하고, 현재의 yacc 대신에 사용할 필요가 있다.

  • mysqld 또는 MySQL 클라이언트를 디버그 할 필요가 있는 경우는,--with-debug 옵션을 지정해 configure (을)를 실행한다.다음에, 재컴파일 하고, 클라이언트를 새로운 클라이언트 라이브러리에 링크한다. See 항E.2. 「MySQL 클라이언트의 디버그」 .

  • Linux (SuSE Linux 8.1 (이)나 Red Hat Linux 7.3 등)으로, 이하와 같은 compile error가 출력되었을 경우

    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++ 하지만 인스톨 되어 있지 않으면 이 테스트로 올바르지 않은 결과가 돌려주어진다.이 문제에 대처하려면 , 이하의 2 개의 방법이 있다.

    • GNU C++ g++ 하지만 인스톨 되고 있는 것을 확인한다.필요한 패키지의 이름은,Linux 디스트리뷰션의 종류에 따라 gpp 또는 gcc-c++ 이다.

    • CXX 환경 변수를 gcc (으)로 설정하고,C++ 컴파일러로서 gcc (을)를 사용한다.

      export CXX="gcc"

    주의: 다음에 configure (을)를 재실행할 필요가 있습니다.

2.3.6. MIT-pthreads 에 관한 주의 사항

여기에서는,MIT-pthreads 의 사용에 관계하는 몇개의 문제를 설명합니다.

주의: Linux 그럼,MIT-pthreads (을)를 사용 하지 않는다 그리고, 인스톨 되고 있다 LinuxThreads 실장을 사용해 주세요. See 항2.6.2. 「Linux 의 주의 사항(모든 Linux 버젼)」 .

시스템에 네이티브스레드서포트가 준비되어 있지 않은 경우는,MIT-pthreads 패키지를 사용해 MySQL (을)를 빌드 할 필요가 있습니다.그러한 시스템으로서는, 구버젼의 FreeBSD 시스템,SunOS 4.x ,Solaris 2.4 이전등이 있습니다. See 항2.2.3. 「MySQL 하지만 서포트하고 있는 operating system」 .

주의: MySQL 4.0.2 에서는, 소스 디스트리뷰션에 MIT-pthreads (은)는 포함되어 있지 않습니다.이 패키지가 필요한 경우는,http://www.mysql.com/Downloads/Contrib/pthreads-1_60_beta6-mysql.tar.gz (으)로부터 따로 다운로드해 주세요.

다운로드하면, 이 소스 어카이브(archive)를 MySQL 소스 디렉토리의 최상위로 전개합니다.이것에 의해서,mit-pthreads 그렇다고 하는 서브 디렉토리가 새롭게 작성됩니다.

  • 거의 시스템에서는,--with-mit-threads 옵션을 지정해 configure (을)를 실행하고, 강제적으로 MIT-pthreads (을)를 사용시킬 수 있다.

    shell> ./configure --with-mit-threads

    MIT-pthreads (을)를 사용하고 있는 경우는, 이 코드에의 변경을 최소한으로 억제하고 싶기 때문에, 소스 디렉토리 이외의 장소에의 빌드는 서포트되어 있지 않다.

  • MIT-pthreads (을)를 사용할지를 판단하는 체크는, 서버 코드를 처리하는 설정 프로세스의 일환으로서 밖에 행해지지 않는다.--without-server (을)를 사용해 디스트리뷰션을 콘피개 해 클라이언트 코드만을 빌드 했을 경우는, 클라이언트는 MIT-pthreads (을)를 사용할지를 판단하지 못하고, 디폴트로 Unix 소켓 접속을 사용한다. 일부의 플랫폼에서는,MIT-pthreads 의 아래에서 Unix 소켓이 기능하지 않기 때문에, 클라이언트 프로그램을 실행할 경우에 -h 또는 --host (을)를 사용할 필요가 있다.

  • MIT-pthreads (을)를 사용해 MySQL (을)를 컴파일 했을 경우는, 퍼포먼스상의 이유로부터, 디폴트로 시스템 락이 무효가 된다.--external-locking 옵션을 사용하고, 시스템 락의 사용을 서버에 지시할 수 있다.이것은, 같은 데이터 파일에 대해서 2 개의 MySQL 서버를 실행할 수 있도록 하는 경우에게만 필요하다(이러한 처리는 추천 하지 않는다).

  • pthread bind() 커멘드가 소켓에의 바인드에 실패해, 에러 메세지가 표시되지 않는 것이 있다(이것은, 적어도 Solaris 위에서는 발생한다).따라서, 서버에의 모든 접속이 실패하는 것이 된다.이하에 예를 나타낸다.

    shell> mysqladmin version
mysqladmin: connect to server at '' failed;
error: 'Can't connect to mysql server on localhost (146)'

    이 문제의 해결책은,mysqld 서버를 강제 종료해 재기동하는 것이다. 이것은, 당사에서 서버를 강제적으로 정?~ 하자마자 재기동했을 때에, 우연히 발견된 방법이다.

  • MIT-pthreads 그럼,sleep() 시스템 콜에 대해서 SIGINT (브레이크)에 의한 세치기를 실시할 수 없다.이것은,mysqladmin --sleep (을)를 실행했을 때에 마셔 안다.sleep() 콜이 종료하고 나서, 세치기가 실행되어 프로세스가 정?~ 한다.

  • 링크시에, 이하와 같은 경고 메세지가 표시되는 일이 있다(적어도 Solaris 그럼 발생한다).이러한 메세지는 무시해 상관없다.

    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
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 `int strtoll(...)'
implicit declaration of function `int strtoul(...)'

  • MIT-pthreads (와)과 제휴해 동작한다 readline (은)는 아직 없다(이것은, 필요가 없는 것이지만, 흥미가 있는 유저도 있을지도 모르다).

2.3.7. Windows 위에서 소스로부터 MySQL (을)를 인스톨 한다

여기에서는,Windows 위에서 버젼 4.1 이?~ 의 소스로부터 MySQL 바이너리를 빌드 하는 방법을 설명합니다.표준의 소스 디스트리뷰션 또는 최신의 개발 소스가 격납되고 있다 BitKeeper 트리로부터 바이너리를 빌드 하는 경우의 순서가 기재되어 있습니다.

주의: 여기에 기재되어 있는 순서는, 최신의 소스 디스트리뷰션 또는 BitKeeper 트리로 입수했다 MySQL (을)를 Windows 위에서 테스트하는 유저만을 대상으로 하고 있습니다. 스스로 소스로부터 빌드 했다 MySQL 서버를 실가동 환경에서 사용하는 것은 추천하지 않습니다.통상, 가장 바람직한 것은,MySQL AB 하지만 특히 Windows 위에서 최적인 퍼포먼스를 달성하도록(듯이) 빌드 한, 프리컴파일 되었다 MySQL 바이너리 디스트리뷰션을 사용하는 것입니다. 바이너리 디스트리뷰션의 인스톨 순서에 대해서는, 항2.1.1. 「Windows 에의 MySQL 의 인스톨」 (을)를 참조해 주세요.

Windows 위에서 MySQL (을)를 빌드 하려면 , 사용하고 있다 Windows 시스템에 이하의 컴파일러와 자원이 없으면 안됩니다.

  • VC++ 6.0 컴파일러(SP 4 또는 5 (와)과 프리프로세서 패키지로 갱신한 것). 프리프로세서 패키지는, macro assembler에 있어서 필요하다. 상세한 것에 대하여는, 이하의 사이트를 참조. http://msdn.microsoft.com/vstudio/downloads/updates/sp/vs6/sp5/faq.aspx .

  • 약 45 MB 의 디스크 영역

  • 64 MB 의 RAM

또,Windows 용무의 MySQL 소스 디스트리뷰션도 필요합니다.MySQL 버젼 4.1 이?~ 의 소스 디스트리뷰션을 입수하는 방법은, 이하의2 대로입니다.

  1. 관심이 있는 버젼의 MySQL 의 MySQL AB 하지만 패키지화한 소스 디스트리뷰션을 입수한다.판매 전의 포장 된 소스 디스트리뷰션은,MySQL 의 릴리스가 끝난 버젼용의 것이 준비되어 있어http://www.mysql.com/downloads/ (으)로부터 입수할 수 있다.

  2. 최신의 BitKeeper 개발자 소스 트리로부터 스스로 소스 디스트리뷰션을 패키지화한다.이것을 실시하는 경우는,Unix 시스템상에서 패키지를 작성하고 나서, 사용하고 있다 Windows 시스템에 전송 할 필요가 있다(설정 및 빌드의 스텝안에는 Unix 위에서 밖에 동작하지 않는 툴이 필요한 것이 있기 위해).따라서,BitKeeper (을)를 이용하는 경우는 이하의 것이 필요하다.

    • Unix (을)를 실행하고 있는 시스템인가,Linux 등의 Unix 좋아하는 시스템

    • 그 시스템용의 BitKeeper 3.0 .BitKeeper (은)는,http://www.bitkeeper.com/ (으)로부터 입수할 수 있다.

Windows 소스 디스트리뷰션을 사용하는 경우는, 직접 항2.3.7.1. 「VC++ (을)를 사용했다 MySQL 의 빌드」 에 진행해 주세요.BitKeeper 트리로부터 빌드 하는 경우는, 항2.3.7.2. 「최신의 개발 소스로부터 Windows 소스 패키지를 작성한다」 에 진행해 주세요.

예상대로 동작하지 않는 것을 찾아냈을 경우나,Windows (으)로의 현재의 빌드 프로세스의 개량 방법에 관해서 제안이 있는 경우는,win32 메일링 리스트에 메세지를 보내 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 .

2.3.7.1. VC++ (을)를 사용했다 MySQL 의 빌드

주의: MySQL 4.1 이?~ 의 VC++ 워크 스페이스 파일은,Microsoft Visual Studio 6.0 이?~ (7.0/.NET )의 버젼과 호환성이 있어, 릴리스전에 MySQL AB 의 스탭에 의해서 테스트되고 있습니다.

MySQL 의 빌드는, 이하의 순서로 실시합니다.

  1. 작업 디렉토리를 작성한다(workdir 등).

  2. WinZip 인가,.zip 파일을 읽어낼 수 있는 그 외의 Windows 툴을 사용하고, 상기의 디렉토리에 소스 디스트리뷰션을 unpack 한다.

  3. VC++ 6.0 컴파일러를 기동한다.

  4. ［File ］메뉴로,［Open Workspace ］(을)를 선택한다.

  5. 작업 디렉토리에 있다 mysql.dsw 워크 스페이스를 연다.

  6. ［Build ］메뉴로,［Set Active Configuration ］메뉴를 선택한다.

  7. 화면상에서 클릭하고,［mysqld - Win32 Debug ］(을)를 선택해,［OK ］(을)를 클릭한다.

  8. F7 키를 눌러, 디버그 서버, 라이브러리, 및 클라이언트 어플리케이션의 빌드를 개시한다.

  9. 같이 필요한 릴리스 버젼을 컴파일 한다.

  10. 프로그램 및 라이브러리의 디버그 버젼은,client_debug 디렉토리 및 lib_debug 디렉토리에 있다. 프로그램 및 라이브러리의 릴리스 버젼은,client_release 디렉토리 및 lib_release 디렉토리에 있다. 주의: 디버그 버젼과 릴리스 버젼의 양쪽 모두를 빌드 하는 경우는,［Build ］메뉴로［build all ］옵션을 선택한다.

  11. 서버를 테스트한다.상기의 순서로 빌드 한 서버에서는, 디폴트로 MySQL 베이스 디렉토리와 데이터 디렉토리가 C:\mysql 및 C:\mysql\data 이라고 상정된다.소스 트리의 루트 디렉토리와 그 데이터 디렉토리를 베이스 디렉토리 및 데이터 디렉토리로서 사용해 서버를 테스트하는 경우는, 서버에 그러한 패스명을 통지할 필요가 있다.이 처리를 실시하려면 , 커멘드 라인으로 --basedir 옵션과 --datadir 옵션을 지정하는지, 옵션 설정 파일(Windows 디렉토리에 있다 C:\my.cnf 파일 또는 my.ini 파일)에 적절한 옵션을 배치한다.사용하고 싶은 기존의 데이터 디렉토리가 다른 장소에 있는 경우는, 그 패스명을 지정한다.

  12. 사용하는 서버에 따르고,client_release 디렉토리 또는 client_debug 디렉토리로부터 서버를 기동한다.일반적인 서버의 기동 순서에 대해서는, 항2.1.1. 「Windows 에의 MySQL 의 인스톨」 (을)를 참조. 다른 베이스 디렉토리 또는 데이터 디렉토리를 사용하는 경우는, 거기에 맞추어 순서를 변경할 필요가 있다.

  13. 설정에 근거해 서버가 스탠드얼론 또는 서비스로서 가동하고 있을 때,client_release 디렉토리 또는 client_debug 디렉토리에 있다 mysql 의 대화형 커멘드 라인 유틸리티로부터 그 서버에 접속한다.

빌드 한 프로그램이 올바르게 동작하는 것을 확인하면, 서버를 정?~ 합니다.다음에, 이하의 순서로 MySQL (을)를 인스톨 합니다.

  1. MySQL (을)를 인스톨 하는 디렉토리를 작성한다.예를 들어,C:\mysql 에 인스톨 하는 경우는, 이하의 커멘드를 사용한다.

    C:
mkdir \mysql
mkdir \mysql\bin
mkdir \mysql\data
mkdir \mysql\share
mkdir \mysql\scripts

    그 외의 클라이언트를 컴파일 해 MySQL 에 링크하는 경우는, 추가의 디렉토리도 작성한다.

    mkdir \mysql\include
mkdir \mysql\lib
mkdir \mysql\lib\debug
mkdir \mysql\lib\opt

    MySQL 의 벤치마크를 실행하는 경우는, 이하의 디렉토리를 작성한다.

    mkdir \mysql\sql-bench

    벤치마크를 실행하려면 ,Perl 하지만 필요하다.

  2. workdir 디렉토리로부터 이하의 디렉토리를 C:\mysql 디렉토리에 카피한다.

    copy client_release\*.exe C:\mysql\bin
copy client_debug\mysqld.exe C:\mysql\bin\mysqld-debug.exe
xcopy scripts\*.* C:\mysql\scripts /E
xcopy share\*.* C:\mysql\share /E

    그 외의 클라이언트를 컴파일 해 MySQL 에 링크하는 경우는, 이하의 커멘드도 실행한다.

    copy lib_debug\mysqlclient.lib C:\mysql\lib\debug
copy lib_debug\libmysql.* C:\mysql\lib\debug
copy lib_debug\zlib.* C:\mysql\lib\debug
copy lib_release\mysqlclient.lib C:\mysql\lib\opt
copy lib_release\libmysql.* C:\mysql\lib\opt
copy lib_release\zlib.* C:\mysql\lib\opt
copy include\*.h C:\mysql\include
copy libmysql\libmysql.def C:\mysql\include

    MySQL 의 벤치마크를 실행하는 경우는, 이하의 커멘드도 실행한다.

    xcopy sql-bench\*.* C:\mysql\bench /E

Windows 바이너리 디스트리뷰션의 경우와 같게 서버를 설정해 기동합니다. See 항2.1.1. 「Windows 에의 MySQL 의 인스톨」 .

2.3.7.2. 최신의 개발 소스로부터 Windows 소스 패키지를 작성한다

현재의 BitKeeper 소스 트리로부터 최신의 Windows 소스 패키지를 빌드 하려면 , 이하의 순서로 실시합니다. 주의: 이 순서는,Unix 또는 Unix 좋아하는 operating system를 실행하고 있는 시스템상에서 실시할 필요가 있습니다(이 순서는,Linux 등의 경우에 유효하다라고 하는 것이 알려져 있습니다).

  1. MySQL 의 BitKeeper 소스 트리를 카피한다(필요에 따라서, 버젼 4.1 이?~ ).소스 트리의 카피 방법의 상세한 것에 대하여는, 항2.3.4. 「개발 소스 트리로부터의 인스톨」 의 설명을 참조.

  2. 서버 바이너리가 필요하기 때문에, 디스트리뷰션을 콘피개 해 빌드 한다.이것을 실시한다 1 개의 방법은, 소스 트리의 최상위디렉토리에서 이하의 커멘드를 실행하는 것이다.

    shell> ./BUILD/compile-pentium-max

  3. 빌드 프로세스가 정상적으로 완료한 것을 확인하면, 소스 트리의 최상위디렉토리로부터 이하의 유틸리티 스크립트를 실행한다.

    shell> ./scripts/make_win_src_distribution

    이 스크립트에 의해서,Windows 시스템상에서 사용한다 Windows 소스 패키지가 작성된다.필요에 따라서, 이 스크립트에 다른 옵션을 지정할 수 있다.지정할 수 있는 옵션은 이하대로이다.

    --debug
디버그.패키지는 작성하지 않는다.
--tmp     tmp
(을)를 지정한다.
--suffix
패키지의 이름의 사픽스를 지정.
--dirname
파일을 카피하는 디렉토리명.
--silent
파일의 처리 경과의 상세를 출력하지 않는다.
--tar     tar.gz
패키지를 .zip
패키지 대신에 작성.
--help
헬프의 표시.

    디폴트에서는,make_win_src_distribution (은)는,mysql-VERSION-win-src.zip (이)라는 이름의 zip 형식의 압축 어카이브(archive)를 작성한다.이 경우,VERSION 하 사용하고 있다 MySQL 소스 트리의 버젼을 나타낸다.

  4. 작성했다 Windows 소스 패키지를 Windows 머신에 카피 또는 업 로드한다.소스 패키지의 컴파일은, 항2.3.7.1. 「VC++ (을)를 사용했다 MySQL 의 빌드」 에 기재되어 있는 순서로 실시한다.


2.4. 인스톨 후의 설정과 테스트

MySQL (을)를 인스톨 하면(바이너리 디스트리뷰션 또는 소스 디스트리뷰션으로부터), 권한 테이블을 초기화하고, 서버를 기동해, 서버가 정상적으로 동작하는 것을 확인할 필요가 있습니다.시스템의 기동시 및 슛다운시에 서버가 자동적으로 기동 및 정?~ 하도록(듯이) 설정할 수도 있습니다.

소스 디스트리뷰션으로부터 인스톨 하는 경우는, 통상, 이하와 같이 권한 테이블을 인스톨 해 서버를 기동합니다.

shell> ./scripts/mysql_install_db
shell> cd mysql_installation_directory
shell> ./bin/mysqld_safe --user=mysql &

바이너리 디스트리뷰션(RPM 패키지 또는 pkg 패키지)의 경우는, 이하를 실행합니다.

shell> cd mysql_installation_directory
shell> ./scripts/mysql_install_db
shell> ./bin/mysqld_safe --user=mysql &

mysql_install_db 스크립트는, 모든 권한을 관리한다 mysql 데이타베이스와MySQL 의 테스트에 사용할 수 있다 test 데이타베이스를 작성합니다.게다가mysql_install_db (을)를 실행하는 유저와 root 유저의 권한 엔트리도 작성합니다.이러한 엔트리는 패스워드 없이 작성됩니다. mysqld_safe 스크립트는,mysqld 서버를 기동합니다(버젼 4.0 보다 전의 MySQL (을)를 사용하고 있는 경우는,mysqld_safe (은)는 아니고 safe_mysqld (을)를 사용합니다).

mysql_install_db (은)는, 낡은 권한 테이블을 덧쓰기하지 않기 때문에, 어떠한 상황으로 실행해도 안전합니다.test 데이타베이스가 필요없는 경우는, 서버를 기동한 후에 mysqladmin -u root drop test (을)를 사용해 이 데이타베이스를 삭제할 수 있습니다.

테스트는,MySQL 디스트리뷰션의 최상위디렉토리로부터 간단하게 실행할 수 있습니다.바이너리 디스트리뷰션의 경우, 최상위디렉토리는 인스톨 디렉토리입니다(통상은 /usr/local/mysql 등).소스 디스트리뷰션의 경우는, 최상위디렉토리는 MySQL 소스 트리의 메인 디렉토리입니다.

이하의 각 항에 나타나는 커멘드에서는,BINDIR 하 mysqladmin (이)나 mysqld_safe 등의 프로그램이 인스톨 되고 있는 장소의 패스를 나타냅니다.바이너리 디스트리뷰션의 경우,BINDIR (은)는 디스트리뷰션내의 bin 디렉토리입니다.소스 디스트리뷰션의 경우,configure (을)를 실행했을 때에 /usr/local 이외의 인스톨 디렉토리를 지정하고 있지 않는 한,BINDIR (은)는 통상은 /usr/local/bin 입니다. EXECDIR (은)는,mysqld 서버가 인스톨 되고 있는 장소입니다.바이너리 디스트리뷰션의 경우, 이것은 BINDIR (와)과 같습니다.소스 디스트리뷰션의 경우,EXECDIR (은)는 통상은 /usr/local/libexec 입니다.

테스트에 대해 상세하게 설명합니다.

  1. 필요에 따라서,mysqld 서버를 기동하고,MySQL 권한 테이블을 초기화한다.이것은, 통상 mysql_install_db 스크립트를 사용해 실시한다.

    shell> scripts/mysql_install_db

    MySQL 권한 테이블에는,MySQL 서버에 접속할 수 있는 유저의 호스트나 권한의 정보가 기록되고 있다.

    일반적으로,mysql_install_db (은)는, 처음 MySQL (을)를 인스톨 했을 때에 마셔 실행할 필요가 있다.따라서, 기존의 인스톨을 업그레이드 하는 경우는, 이 스텝은 스킵 할 수 있다(다만,mysql_install_db (은)는 사용해도 매우 안전하고, 기존의 테이블을 갱신할 것은 없기 때문에, 판단이 서지 않는 경우는 mysql_install_db (을)를 실행해 상관없다).

    mysql_install_db (은)는,mysql 데이타베이스에 6 개의 테이블(user ,db ,host ,tables_priv ,columns_priv , 및 func )(을)를 작성한다.초기 권한의 설명에 대해서는, 항4.4.4. 「MySQL 권한의 초기설정」 (을)를 참조. 간단하게 설명하면, 초기 권한은,MySQL root 유저에게 모든 조작을 허가해, 전유저에게 test (이)라는 이름인가,test_ 그리고 시작되는 이름을 가지는 데이타베이스를 작성 또는 사용하는 허가를 준다.

    권한 테이블을 설정하지 않으면 서버를 기동했을 때에 로그 파일에 이하의 에러가 기록된다.

    mysqld: Can't find file: 'host.frm'

    MySQL 바이너리 디스트리뷰션의 경우에도,./bin/mysqld_safe (을)를 실행해 MySQL (을)를 기동하지 않으면 이 에러가 발생한다. See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 .

    mysql_install_db (은)는,Unix root 어카운트로 실행할 필요가 있는 일이 있다. 다만, 필요에 따라서, 데이타베이스 디렉토리내의 파일에 대해서 독해와 기입의 액세스권이 있는 일반의 어카운트(root 이외의 Unix 의 어카운트)로, MySQL 서버를 실행할 수도 있다.일반의 어카운트로 MySQL (을)를 실행하는 순서에 대해서는, 항A.3.2. 「일반 유저로 MySQL (을)를 실행하는 방법」 (을)를 참조.

    mysql_install_db 그리고 문제가 발생하는 경우는, 항2.4.1. 「mysql_install_db 의 실행에 관한 문제」 (을)를 참조.

    MySQL 디스트리뷰션으로 제공된다 mysql_install_db 스크립트를 실행하는 대신 실시할 수 있는 몇개의 수단이 있다.

    • mysql_install_db (을)를 실행하기 전에, 이 스크립트를 편집하고, 권한 테이블에 인스톨 되고 있는 초기의 권한을 변경할 수 있다.스크립트의 변경에 의해, 같은 권한을 가지는 복수의 머신에 MySQL (을)를 인스톨 하는 경우에 편리하다.이 경우, 통상은,mysql.user 테이블과 mysql.db 테이블에 몇개의 INSERT 스테이트먼트를 추가하는 것만으로 끝난다.

    • 권한 테이블을 인스톨 한 후에 테이블의 내용을 변경하는 경우는,mysql_install_db (을)를 실행하고,mysql -u root mysql (을)를 사용해 MySQL root 유저로서 권한 테이블에 접속해,SQL 스테이트먼트를 발행해 권한 테이블을 직접 수정한다.

    • 작성 끝난 권한 테이블을 완전하게 다시 작성할 수 있다.테이블을 벌써 인스톨 있어,mysql_install_db (을)를 편집한 후에 다시 작성하는 경우에, 이것을 실시할 필요가 있다.

    이러한 대체 수단의 상세한 것에 대하여는, 항4.4.4. 「MySQL 권한의 초기설정」 (을)를 참조.

  2. 이하와 같이 MySQL 서버를 기동한다.

    shell> cd mysql_installation_directory
shell> bin/mysqld_safe &

    버젼 4.0 보다 전의 MySQL (을)를 사용하고 있는 경우는, 마지막 커멘드의 bin/mysqld_safe (을)를 bin/safe_mysqld 에 옮겨놓는다.

    서버의 기동시에 문제가 발생했을 경우는, 항2.4.2. 「MySQL 서버의 기동에 관한 문제」 (을)를 참조.

  3. mysqladmin (을)를 사용하고, 서버가 가동하고 있는 것을 확인한다.이하의 커멘드에 의해서, 서버가 가동하고 있어 접속에 응답하고 있는 것을 체크하기 위한 간단한 테스트가 실행된다.

    shell> BINDIR/mysqladmin version
shell> BINDIR/mysqladmin variables

    mysqladmin version (으)로부터의 출력은, 사용하고 있는 플랫폼과 MySQL 의 버젼에 의해서 조금 다르지만, 이하에 나타낸 것 과 유사한 내용이 된다.

    shell> BINDIR/mysqladmin version
mysqladmin  Ver 8.14 Distrib 3.23.32, for linux on i586
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          3.23.32-debug
Protocol version        10
Connection              Localhost via Unix socket
TCP port                3306
UNIX socket             /tmp/mysql.sock
Uptime:                 16 sec

Threads: 1  Questions: 9  Slow queries: 0
Opens: 7  Flush tables: 2  Open tables: 0
Queries per second avg: 0.000
Memory in use: 132K  Max memory used: 16773K

    BINDIR/mysqladmin (을)를 사용하면 그 밖에 어떠한 일을 실시할 수 있는지를 파악하려면 ,--help 옵션을 지정해 기동한다.

  4. 서버를 슛다운 할 수 있을지를 확인한다.

    shell> BINDIR/mysqladmin -u root shutdown

  5. 서버를 재기동할 수 있을지를 확인합니다.이 확인은,mysqld_safe (을)를 사용하는지, 직접 mysqld (을)를 기동해 실시한다.이하에 예를 나타낸다.

    shell> BINDIR/mysqld_safe --log &

    mysqld_safe 하지만 실패했을 경우는,MySQL 의 인스톨 디렉토리로부터 실행한다(인스톨 디렉토리 이외의 디렉토리로 이동하고 있는 경우).그런데도 실패하는 경우는, 항2.4.2. 「MySQL 서버의 기동에 관한 문제」 (을)를 참조.

  6. 몇개의 간단한 테스트를 실행하고, 서버가 가동하고 있는 것을 확인한다. 출력은, 이하에 나타내는 것 과 유사한 내용이 된다.

    shell> BINDIR/mysqlshow
+-----------+
| Databases |
+-----------+
| mysql     |
+-----------+

shell> BINDIR/mysqlshow mysql
Database: mysql
+--------------+
|    Tables    |
+--------------+
| columns_priv |
| db           |
| func         |
| host         |
| tables_priv  |
| user         |
+--------------+

shell> BINDIR/mysql -e "SELECT host,db,user FROM db" mysql
+------+--------+------+
| host | db     | user |
+------+--------+------+
| %    | test   |      |
| %    | test_% |      |
+------+--------+------+

    또,sql-bench 디렉토리(MySQL 인스톨 디렉토리아래)에, 벤치마크스트가 있다.이 벤치마크스트를 사용하면, 각종의 플랫폼상에서의 MySQL 의 동작을 비교할 수 있다.벤치마크스트는,Perl 그리고 기술되고 있어Perl DBI 모듈을 사용해 데이타베이스에 의존하지 않는 인터페이스를 각종의 데이타베이스에 제공한다.벤치마크스트를 실행하려면 , 이하의 추가의 Perl 모듈이 필요하다.

    DBI
DBD-mysql
Data-Dumper
Data-ShowTable

    이러한 모듈은,CPAN (http://www.cpan.org/ )(으)로부터 입수할 수 있다. See 항2.7.1. 「Unix 에의 Perl 의 인스톨」 .

    sql-bench/Results 디렉토리에는, 다양한 데이타베이스나 플랫폼의 벤치마크스트의 실행 결과가 포함되어 있다.모든 테스트를 실행하려면 , 이하의 커멘드를 실행한다.

    shell> cd sql-bench
shell> run-all-tests

    sql-bench 디렉토리가 없는 경우는, 바이너리 디스트리뷰션용의 RPM (을)를 사용하고 있을 가능성이 있다(소스 디스트리뷰션의 RPM 에는 벤치마크 디렉토리가 포함되어 있다).그 경우, 벤치마크스트를 사용하려면 , 최초로 벤치마크스트를 인스톨 할 필요가 있다.MySQL 버젼 3.22 이?~ 그럼, 벤치마크의 코드와 데이터가 포함되었다 mysql-bench-VERSION-i386.rpm (이)라는 이름의 벤치마크 RPM 파일이 있다.

    소스 디스트리뷰션을 사용하고 있는 경우는,tests 서브 디렉토리에 있는 테스트를 실행할 수도 있다.예를 들어,auto_increment.tst (을)를 실행하려면 , 이하의 커멘드를 실행한다.

    shell> BINDIR/mysql -vvf test < ./tests/auto_increment.tst

    결과는,./tests/auto_increment.res 파일에 출력된다.

2.4.1. mysql_install_db 의 실행에 관한 문제

mysql_install_db 스크립트의 목적은, 새롭다 MySQL 권한 테이블을 생성하는 것입니다.이 스크립트가 그 외의 데이터에 영향을 미칠 것은 없습니다. MySQL 권한 테이블이 벌써 인스톨 되고 있는 경우는, 아무것도 실시하지 않습니다.

권한 테이블을 다시 작성하는 경우는,mysqld 서버를 정?~ 하고(서버가 가동하고 있는 경우), 이하와 같은 커멘드를 실행합니다.

shell> mv mysql-data-directory/mysql mysql-data-directory/mysql-old
shell> mysql_install_db

여기에서는,mysql_install_db 의 실행시에 발생할 가능성이 있는 문제에 대해 설명합니다.

  • mysql_install_db 하지만 권한 테이블을 인스톨 하지 않는다

    mysql_install_db 하지만 권한 테이블의 인스톨에 실패해, 이하의 메세지를 표시한 후에 종료하는 일이 있다.

    starting mysqld daemon with databases from XXXXXX
mysql daemon ended

    이 경우는, 로그 파일을 자세하게 조사할 필요가 있다.로그는, 에러 메세지에 표시되고 있다 XXXXXX 디렉토리에 있다.로그에는 mysqld 하지만 기동하지 않는 원인이 나타난다.무엇이 일어났는지 모르는 경우는,mysqlbug (을)를 사용해 버그 리포트를 투고할 경우에 이 로그를 포함한다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

  • mysqld demon가 벌써 가동하고 있다

    이 경우는,mysql_install_db (을)를 실행할 필요는 없다.mysql_install_db (은)는,MySQL (을)를 처음으로 인스톨 할 경우에 1 회만 실행할 필요가 있다.

  • mysqld demon가 가동하고 있을 때, 다른 mysqld demon를 인스톨 할 수 없다

    이 문제는, 기존의 MySQL 인스톨이 있는 경우에, 테스트를 위해나, 동시에 2 개의 인스톨을 가동시키기 위해서 다른 장소에 새로운 인스톨을 배치할 경우에 발생한다.일반적으로,2 번째의 서버를 실행할 경우에 일어나는 문제는, 그 서버가 기존의 서버와 같은 소켓이나 포토를 사용하려고 하는 것이다. 이 경우는, 다음의 에러 메세지가 표시된다.Can't start server: Bind on TCP/IP port: Address already in use 또는 Can't start server: Bind on unix socket... . See 항4.2. 「같은 머신상에서 복수의 MySQL 서버를 실행한다」 .

  • /tmp 에 대한 기입 액세스권이 없다

    디폴트의 장소(/tmp 안)에 있는 소켓 파일을 작성하기 위한 기입 액세스권이 없는 경우나,/tmp, 안에 임시 파일을 작성하기 위한 액세스권이 없는 경우에,mysql_install_db 의 실행시나,mysqld 의 기동시 또는 사용시에 에러가 표시된다.

    이하의 커멘드를 실행하고, 다른 소켓과 텐포라리디레크트리를 지정할 수 있다.

    shell> TMPDIR=/some_tmp_dir/
shell> MYSQL_UNIX_PORT=/some_tmp_dir/mysqld.sock
shell> export TMPDIR MYSQL_UNIX_PORT

    항A.4.5. 「MySQL 소켓 파일 /tmp/mysql.sock 의 보호 또는 변경 방법」 (을)를 참조.

    some_tmp_dir 에는, 자신이 써 액세스권을 가지는 디렉토리의 패스를 지정한다. See 부록 F. 환경 변수 .

    이 후, 이하의 커멘드를 사용하고,mysql_install_db (을)를 실행해, 서버를 기동할 수 있다.

    shell> scripts/mysql_install_db
shell> BINDIR/mysqld_safe &

  • mysqld 하지만 곧바로 크래쉬 한다

    2.0.7-5 보다 전의 버젼의 glibc (을)를 갖추었다 Red Hat 버젼 5.0 (을)를 실행하고 있는 경우,glibc 의 모든 패치가 인스톨 되고 있는 것을 확인할 필요가 있다. MySQL 메일 어카이브(archive)에는, 이것에 관한 대량의 정보가 있다.메일 어카이브(archive)에의 링크는,http://lists.mysql.com/ (으)로부터 온라인으로 이용할 수 있다. 항2.6.2. 「Linux 의 주의 사항(모든 Linux 버젼)」 도 참조.

    또,--skip-grant-tables 옵션을 지정해 mysqld (을)를 수동으로 기동해,mysql (을)를 사용해 스스로 특권 정보를 추가할 수도 있다.

    shell> BINDIR/mysqld_safe --skip-grant-tables &
shell> BINDIR/mysql -u root mysql

    mysql (으)로부터,mysql_install_db 그리고 SQL 커멘드를 수동으로 실행한다.다음에, 반드시 mysqladmin flush-privileges 또는mysqladmin reload (을)를 실행해 서버에 권한 테이블의 재로드를 지시한다.

2.4.2. MySQL 서버의 기동에 관한 문제

트랜잭션(transaction)(InnoDB ,BDB )(을)를 서포트하는 테이블을 사용하는 경우는, 최초로 my.cnf 파일을 작성하고, 사용할 예정의 테이블형용의 기동 옵션을 설정해 둘 필요가 있습니다. See 장 7. MySQL 의 테이블형 .

통상은, 이하의 몇개의 방법으로 mysqld 서버를 기동합니다.

  • mysql.server (을)를 실행한다.이 스크립트는, 주로 시스템의 기동과 슛다운 시에 사용된다.상세한 것에 대하여는, 항2.4.3. 「MySQL (을)를 자동적으로 기동 및 정?~ 한다」 (을)를 참조.

  • mysqld_safe (을)를 실행한다.이 스크립트는,mysqld 의 적절한 옵션을 판별해, 그러한 옵션을 지정해 mysqld (을)를 실행한다. See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 .

  • Windows NT/2000/XP 의 경우는, 항2.1.1.7. 「Windows NT ,2000 , 또는 XP (으)로의 MySQL 의 기동」 (을)를 참조.

  • mysqld (을)를 직접 기동한다.

기동했다 mysqld demon는, 디렉토리를 데이터 디렉토리로 변경합니다.이 디렉토리에서,mysqld (은)는, 로그 파일과 pid (프로세스ID ) 파일을 써, 데이타베이스를 검색합니다.

데이터 디렉토리(datadir 변수) 의 장소는, 디스트리뷰션의 컴파일시에 짜넣어집니다.다만,mysqld 하지만 실제로 존재하는 시스템상의 장소 이외의 장소에 데이터 디렉토리가 있으면,mysqld (은)는 올바르게 동작하지 않습니다.패스에 문제가 있는 경우는,--help 옵션을 지정해 mysqld (을)를 기동하고,mysqld 하지만 허가하는 옵션과 디폴트의 패스 설정을 확인할 수 있습니다.mysqld 에의 커멘드 라인 인수로서 올바른 패스명을 지정하고, 디폴트 설정을 무효로 할 수 있습니다(이러한 옵션은,mysqld_safe 그렇지만과 같이 사용할 수 있습니다).

통상,mysqld 에 지시할 필요가 있는 것은,MySQL 하지만 인스톨 되고 있는 베이스 디렉토리 뿐입니다.베이스 디렉토리의 지정은,--basedir 옵션을 사용해 실시할 수 있습니다.또,--help (을)를 사용하고, 패스 옵션을 변경했을 경우의 영향을 체크할 수도 있습니다(주의: --help (은)는,mysqld 커멘드 라인의 마지막에 지정한다 필요가 있습니다 ).이하에 예를 나타냅니다.

shell> EXECDIR/mysqld --basedir=/usr/local --help

필요한 패스 설정을 결정하면,--help 옵션을 지정하지 않고 서버를 기동합니다.

어느 방법으로 서버를 기동했을 경우에서도, 서버가 정상적으로 기동하지 않을 때는, 로그 파일을 체크하고 원인을 찔러?~ 일이 생길지 확인합니다.로그 파일은, 데이터 디렉토리(통상, 바이너리 디스트리뷰션의 경우는 /usr/local/mysql/data , 소스 디스트리뷰션의 경우는 /usr/local/var ,Windows 위에서는 \mysql\data\mysql.err )입니다.데이터 디렉토리내에서 host_name.err (이)나 host_name.log 의 형식의 이름을 가지는 파일을 찾습니다.이 경우,host_name (은)는, 사용하고 있는 서버 호스트의 이름입니다.다음에, 이하의 커멘드를 실행하고, 그러한 파일의 마지막 몇 줄기를 체크합니다.

shell> tail host_name.err
shell> tail host_name.log

로그 파일내에서 이하와 같은 기술을 찾습니다.

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

이것은,--bdb-no-recover (을)를 지정하지 말아줘 mysqld (을)를 기동한 것과Berkeley DB 하지만 데이타베이스를 리커버리 할 경우에 로그 파일에 문제가 있는 것을 발견한 것을 의미하고 있습니다.속행할 수 있도록 하려면 , 데이타베이스 디렉토리에 있는 기존의 Berkeley DB 의 로그 파일을, 다음에 조사할 수 있는 다른 장소로 이동합니다.로그 파일에는,log.0000000001 (이)라는 이름이 붙어 있습니다.이 경우, 숫자는 시간의 경과와 함께 증가합니다

BDB 테이블을 서포트하고 있다 mysqld (을)를 기동하려고 하고 코어를 토했을 경우는,BDB 리커버리 로그에 문제가 있을지도 모릅니다.그 경우는,--bdb-no-recover (을)를 지정해 mysqld (을)를 기동해 보겠습니다.이 방법으로 서버가 정상적으로 기동했을 경우는, 데이터 디렉토리로부터 모든 log.* 파일을 삭제하고, 한번 더 mysqld (을)를 기동해 보겠습니다.

이하의 에러가 표시되었을 경우는,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 서버가 가동하고 있지 않는 것을 확인합니다.다른 서버가 가동하고 있지 않는 것이 확인할 수 있으면, 커멘드 telnet 호스트명 TCP/IP 포토 번호 (을)를 실행하고,Enter 키를 2 ,3 회 누릅니다.telnet: Unable to connect to remote host: Connection refused (와)과 같은 에러 메세지가 출력되지 않는 경우는,mysqld 하지만 사용하려고 했다 TCP/IP 포토는 다른 프로그램에 의해서 사용되고 있습니다. 항2.4.1. 「mysql_install_db 의 실행에 관한 문제」 및 항4.2. 「같은 머신상에서 복수의 MySQL 서버를 실행한다」 (을)를 참조해 주세요.

mysqld 하지만 현재 가동하고 있는 경우는, 이하의 커멘드를 실행하고,mysqld 하지만 사용하고 있는 패스 설정을 조사할 수 있습니다.

shell> mysqladmin variables

또는

shell> mysqladmin -h 'your-host-name' variables

mysqld 의 기동시에 Errcode 13 (Permission denied (을)를 나타낸다)가 표시되었을 경우는,MySQL 데이타베이스 또는 로그 디렉토리내의 파일의 독해/ 기입 권한이 없었던 것을 의미합니다.이 경우,Unix root 어카운트로 mysqld (을)를 기동하는지, 관련하는 파일 및 디렉토리를 mysqld (을)를 실행한다 Unix 어카운트를 사용할 수 있도록, 그러한 파일 및 디렉토리의 액세스권을 변경합니다.

mysqld_safe 에 의해서 서버가 기동되었는데, 그 서버에 접속할 수 없는 경우는,/etc/hosts 에 이하와 같은 엔트리가 있을지를 확인합니다.

127.0.0.1       localhost

이 문제는, 정상적으로 기능하는 스레드라이브라리가 없고,MySQL 하지만MIT-pthreads (을)를 사용하도록(듯이) 콘피개 되고 있는 시스템으로 발생합니다.

mysqld (을)를 기동시킬 수 없는 경우는, 트레이스 파일을 작성하고 문제를 찾아냅니다. See 항E.1.2. 「트레이스 파일의 작성」 .

InnoDB 테이블을 사용하고 있는 경우는, 항7.5.3. 「InnoDB 기동 옵션」 (을)를 참조해 주세요.

BDB (Berkeley DB ) 테이블을 사용하고 있는 경우는, 항7.6.3. 「BDB 기동 옵션」 (을)를 잘 이해해 두어 주세요.

2.4.3. MySQL (을)를 자동적으로 기동 및 정?~ 한다

mysql.server 스크립트와 mysqld_safe 스크립트를 사용하면, 시스템의 기동시에 서버를 자동적으로 기동할 수 있습니다.mysql.server (은)는, 서버를 정?~ 하는 경우에도 사용할 수 있습니다.

mysql.server 스크립트에 start 인수 또는 stop 인수를 지정해 기동하면, 서버를 기동 또는 정?~ 할 수 있습니다.

shell> mysql.server start
shell> mysql.server stop

mysql.server (은)는,MySQL 인스톨 디렉토리아래의 share/mysql 디렉토리인가,MySQL 소스 트리의 support-files 디렉토리에 있습니다.

주의: Linux RPM 패키지(MySQL-server-VERSION.rpm )(을)를 사용하고 있는 경우는,mysql.server 스크립트는 /etc/init.d/mysql (으)로서 벌써 인스톨 되고 있습니다.따라서, 수동으로 이 스크립트를 인스톨 할 필요는 없습니다.Linux RPM 패키지의 상세한 것에 대하여는, 항2.1.2. 「Linux 에의 MySQL 의 인스톨」 (을)를 참조해 주세요.

Mac OS X 그럼, 다른 MySQL Startup Item 패키지를 인스톨 하고, 시스템 부트 업시에 MySQL 하지만 자동적으로 기동할 수 있도록 할 수 있습니다. 상세한 것에 대하여는, 항2.1.3. 「Mac OS X 에의 MySQL 의 인스톨」 (을)를 참조해 주세요.

mysql.server (은)는, 서버를 기동하기 전에 디렉토리를 MySQL 인스톨 디렉토리로 변경하고 나서,mysqld_safe (을)를 기동합니다. 인스톨 한 바이너리 디스트리뷰션이 표준 이외의 장소에 있는 경우는,mysql.server (을)를 편집할 필요가 있습니다.mysqld_safe (을)를 실행하기 전에 적절한 디렉토리로 변경한다(cd ) 같게,mysql.server (을)를 수정합니다.서버를 특정의 유저로서 실행하는 경우는, 이 섹션으로 설명하도록(듯이) 적절한 user 행을 /etc/my.cnf 파일에 추가합니다.

mysql.server stop (은)는, 서버에 시그널을 보내 정?~ 시킵니다. mysqladmin shutdown (을)를 실행하고, 서버를 수동으로 정?~ 시킬 수도 있습니다.

/etc/rc* 파일내의 적절한 장소에 이러한 기동 커멘드 및 정?~ 커멘드를 추가할 필요가 있습니다.

최신의 Linux 디스트리뷰션에서는,mysql.server 파일을 /etc/init.d 디렉토리( 구버젼의 Red Hat 시스템의 경우는 /etc/rc.d/init.d )에 카피하는 것만으로 끝납니다.그 후, 이하의 커멘드를 실행하고, 시스템 부트시에 MySQL 하지만 기동할 수 있도록 합니다.

shell> chkconfig --add mysql.server

FreeBSD 그럼, 통상, 기동 스크립트는 /usr/local/etc/rc.d/ 에 격납됩니다. rc(8) 메뉴얼 페이지에는, 이 디렉토리에 있는 스크립트의 basename 하지만 시르그로브파탄 *.sh 에 매치해, 실행 가능한 경우만, 실행되면 기술되어 있습니다.이 디렉토리내의 그 외의 파일이나 디렉토리는, 자동적으로 무시됩니다.즉,FreeBSD 그럼, 자동 기동을 유효하게 하려면 , 파일 mysql.server (을)를 /usr/local/etc/rc.d/mysql.server.sh (으)로서 인스톨 할 필요가 있습니다.

일부의 operating system에서는, 상기의 방법 대신에,/etc/rc.local 또는 /etc/init.d/boot.local (을)를 사용하고, 부트 업시에 그 외의 서비스를 기동할 수도 있습니다.이 방법으로 MySQL (을)를 기동하려면 , 이하와 같은 기술을 말미에 추가합니다.

shell> /bin/sh -c 'cd /usr/local/mysql; ./bin/mysqld_safe --user=mysql &'

글로벌 /etc/my.cnf 파일에 mysql.server 의 옵션을 추가할 수도 있습니다.표준적인 /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 스크립트는,datadir ,basedir , 및 pid-file 의 각 옵션을 인식합니다..

이하의 겉(표)에, 각 기동 스크립트가, 옵션 설정 파일로부터 읽어내는 옵션 그룹을 나타냅니다.

스크립트 | 옵션 그룹
mysqld | [mysqld] ,[server] , 및 [mysqld-major-version]
mysql.server | [mysql.server] ,[mysqld] , 및 [server]
mysqld_safe | [mysqld] ,[server] , 및 [mysqld_safe]

하위 호환성을 위해서,mysql.server 하 [mysql_server] 그룹도 읽어내,mysqld_safe 하 [safe_mysqld] 그룹도 읽어냅니다.그러나, 이러한 대신에 [mysql.server] 그룹과 [mysqld_safe] 그룹을 사용하도록(듯이) 옵션 설정 파일을 갱신할 필요가 있습니다.

See 항4.1.2. 「my.cnf 옵션 설정 파일」 .


2.5. MySQL 의 업그레이드와 다운 그레이드

업그레이드를 실시하기 전에, 기존의 데이타베이스를 백업 할 필요가 있습니다.

같은 베이스 버젼의 MySQL 인 한,MySQL 의 데이터 파일을 같은 Archie 텍 차상이 다른 버젼의 플랫폼으로 이동할 수 있습니다.현재의 베이스 버젼은 4 입니다.

MySQL (을)를 운용중으로 캐릭터 세트를 변경하는 경우는, 모든 테이블로 myisamchk -r -q --set-character-set=charset (을)를 실행할 필요가 있습니다.이 처리를 실시하지 않으면 캐릭터 세트를 변경한 것에 의해서 소트 순서도 변경되는 일이 있기 위해, 인덱스가 올바르고 순서 붙이지 않을 수 없는 것이 있습니다.

새로운 버젼에 불안을 느끼는 경우는, 언제라도, 구버젼의 mysqld 의 이름을 mysqld-old-version-number (와)과 같은 이름으로 변경할 수 있습니다. 그처럼 해 두면, 새로운 버젼의 mysqld 하지만 예기치 않은 동작을 했을 때에, 그 mysqld (을)를 슛다운 해 구버젼의 mysqld 그리고 재기동하는 것만으로 끝납니다.

업그레이드 후에, 재컴파일 한 클라이언트 프로그램으로 Commands out of sync (이)나 예기치 않은 코어덤프등의 문제가 발생했을 경우는, 프로그램의 컴파일시에 구버젼의 헤더 파일이나 라이브러리 파일을 사용한 가능성이 있습니다.이 경우,mysql.h 파일 및 libmysqlclient.a 라이브러리의 일자를 체크하고, 그것들이 새롭다 MySQL 디스트리뷰션의 것일지를 확인합니다.새롭다 MySQL 디스트리뷰션의 것이 아닌 경우는, 프로그램을 재컴파일 해 주세요.

새롭다 mysqld 서버가 기동하지 않는, 또는 패스워드 없이 접속할 수 없는등의 문제가 발생했을 경우는, 구버젼의 인스톨의 my.cnf 파일이 있는지 없는지를 체크합니다.이것은,program-name --print-defaults (을)를 사용해 체크할 수 있습니다.. 프로그램명 이외의 것이 출력되었을 경우는, 서버의 동작에 영향을 미치는 액티브한 my.cnf 파일이 있습니다.

새로운 릴리스의 MySQL (을)를 인스톨 할 때는 항상,Perl DBD-mysql 모듈의 재빌드와 재인스톨을 실시하는 것을 추천합니다.같은 것은,Python MySQLdb 모듈등의 그 외의 MySQL 인터페이스에 대해서도 들어맞읍니다.

2.5.1. 버젼 4.0 (으)로부터 4.1 에의 업그레이드

MySQL 4.0 (와)과 MySQL 4.1 그럼, 중대한 버그를 수정해,MySQL (와)과 ANSI SQL 표준과의 호환성을 향상시키기 위해서 몇개의 눈에 띄는 동작이 변경되고 있습니다.이러한 변경은, 어플리케이션에 영향을 미치는 일이 있습니다.

일부의 4.1 의 동작은, 완전하게 4.1 에 업그레이드 하기 전에 4.0 그리고 테스트할 수 있습니다.비교적 최근의 MySQL 4.0 릴리스(4.0.12 이?~ )에는,mysqld 용무의 --new 기동 옵션이 추가되고 있습니다.

이 옵션을 사용하면, 가장 중대한 변경을 했다 4.1 의 동작이 제공됩니다. SET @@new=1 커멘드를 사용해 특정의 클라이언트 접속에 대해서 이러한 동작을 유효하게 하거나 유효하게 되어 있는 경우는 SET @@new=0 커멘드를 사용하고 무효로 할 수 있습니다.

4.1 의 변경점에 의해서 영향을 받는다고 생각되는 경우는,4.1 에 업그레이드 하기 전에, 최신의 MySQL 4.0 버젼을 다운로드하고, 설정 파일에 이하를 추가해,--new 옵션을 지정해 그 MySQL (을)를 실행하는 것을 추천합니다.

[mysqld-4.0]
new

이와 같이 하면,4.0 위에서, 새로운 기능을 동작시키고, 어플리케이션이 그것들과 제휴해 정상적으로 기능할지를, 확인할 수 있습니다.이것은,4.1 이?~ 에의 완전 업그레이드를 실시할 때, 고생하지 않고 부드럽게 이행 하는데 도움이 됩니다.상기의 방법으로 이것을 실시하면, 잘못해 --new 옵션을 지정해 4.1 버젼을 실행할 것은 없습니다.

이하에서는, 어플리케이션에 영향을 미칠 가능성이 있는 변경점이나, 버젼 4.1 에 업그레이드 할 경우에 주의할 필요가 있는 변경점에 대해 설명합니다.

  • TIMESTAMP (은)는,'YYYY-MM-DD HH:MM:SS' 형식의 문자열로서 돌려주어지게 되었다(4.0.12 이?~ 그럼,--new 옵션을 사용해 이 점에 관해서 4.1 (와)과 같이 동작시킬 수 있다).버젼 4.0 (와)과 같이 값을 수치로서 돌려주도록(듯이) 하는 경우는,TIMESTAMP 컬럼을 취득할 경우에, 그러한 컬럼에 +0 (을)를 추가한다.

    mysql> SELECT ts_col + 0 FROM tbl_name;

    TIMESTAMP 컬럼의 자리수 지정의 서포트는 안?~ 되었다. 예를 들어, 컬럼을 TIMESTAMP(10) (이)라고 선언해도,(10) (은)는 무시된다.

    이러한 변경은, 표준 SQL 에 준거하기 위해서 필요했다.향후의 버젼으로, 한층 더 변경을 해(이 변경과 하위 호환성이 있다), 타임 스탬프장으로 초의 소수부의 자리수를 필요한 만큼 지정할 수 있게 될 예정.

  • 0xFFDF 등의 바이너리치는, 수치는 아니고 문자열이다고 보여지게 되었다.이것에 의해서, 문자열을 바이너리치로서 입력하는 것이 편리한 캐릭터 세트의 몇개의 문제가 수정된다.이 변경에서는, 바이너리치를 정수로서 수치 비교하는 경우는, 이하와 같이 CAST() (을)를 사용할 필요가 있다.

    mysql> SELECT CAST(0xFEFF AS UNSIGNED INTEGER) < CAST(0xFF AS UNSIGNED INTEGER);
        -> 0

    CAST() (을)를 사용하지 않으면 이하와 같이 문자열 비교를 한다.

    mysql> SELECT 0xFEFF < 0xFF;
        -> 1

    수치 문맥으로의 바이너리 항목의 사용이나,= 연산자를 사용한 바이너리 항목의 비교는, 종래대로 기능한다(4.0.13 이?~ 그럼,--new 옵션을 사용해 이 점에 관해서 4.1 (와)과 같이 동작시킬 수 있다).

  • DATE 값,DATETIME 값, 또는 TIME 값을 생성하는 함수의 경우, 클라이언트에 돌려주어지는 결과는 시간이 가지는 형태에 수정되고 있다.예를 들어,MySQL 4.1 그럼, 이하와 같은 결과가 돌려주어진다.

    mysql> SELECT CAST("2001-1-1" as DATETIME);
    -> '2001-01-01 00:00:00'

    MySQL 4.0 그럼, 이하와 같이 다른 결과가 돌려주어진다.

    mysql> SELECT CAST("2001-1-1" as DATETIME);
    -> '2001-01-01'

  • AUTO_INCREMENT 컬럼에 DEFAULT 값을 지정할 수 없게 되었다(4.0 그럼 DEFAULT 값은 자동적으로 무시된다.4.1 그럼 에러가 발생한다).

  • LIMIT (은)는 부의 인수를 받아들이지 않게 되었다. -1 대신에 18446744073709551615 (을)를 사용한다.

  • SERIALIZE (은)는,sql_mode 변수의 유효한 옵션치는 아니게 되었다.대신에,SET TRANSACTION ISOLATION LEVEL SERIALIZABLE (을)를 사용한다.SERIALIZE (은)는,mysqld 의 --sql-mode 옵션이라고 해도 유효한 것은 없어졌다.대신에,--transaction-isolation=SERIALIZABLE (을)를 사용한다.

  • 모든 테이블과 문자열 컬럼이 캐릭터 세트를 가지게 되었다. See 장 9. 각국 캐릭터 세트와 Unicode . 캐릭터 세트 정보는,SHOW CREATE TABLE (와)과 mysqldump 에 의해서 표시된다 (MySQL 버젼 4.0.6 이?~ (은)는, 새로운 덤프 파일을 읽어낼 수 있다.이것보다 전의 버젼은, 새로운 덤프 파일을 읽어낼 수 없다).

  • 4.1 그럼,.frm 파일로 사용되는 테이블 정의 형식이 조금 변경되고 있다.4.0.11 이?~ 의 MySQL 4.0 버젼은, 이 새롭다 .frm 형식을 직접독 읽어낼 수 있지만, 이것보다 전의 버젼은 새로운 형식을 읽어낼 수 없다. 버젼 4.1 의 테이블을 4.0.11 보다 전의 버젼으로 이동할 필요가 있는 경우는,mysqldump (을)를 사용한다. See 항4.9.7. 「mysqldump (테이블 구조와 데이터의 덤프)」 .

  • 동일한 Windows 머신상에서 복수의 서버를 실행하는 경우는, 모든 머신상에서 다르다 --shared_memory_base_name 옵션을 사용할 필요가 있다.

  • UDF 함수에의 인터페이스가 조금 변경되었다.집약 함수 XXX() 마다 xxx_clear() 함수를 선언해야 하게 되었다.

일반적으로, 이전의 MySQL 버젼으로부터 4.1 에 업그레이드 하는 경우는, 이하의 스텝을 실행할 필요가 있다.

  • 전술의 변경점을 체크하고, 사용하고 있는 어플리케이션에 영향을 미치는 변경이 있을지를 확인한다.

  • 항D.2. 「Changes in release 4.1.x (Alpha) 」 (을)를 읽고,4.1 그리고 사용할 수 있는 중요한 신기능을 확인한다.

  • Windows 위에서 MySQL 서버를 실행하는 경우는, 항2.5.8. 「Windows 위에서의 MySQL 의 업그레이드」 도 참조.

  • 업그레이드 후에, 패스워드를 안전하게 처리하기 위해서 필요한, 길어진 새롭다 Password 컬럼을 생성하도록(듯이) 권한 테이블을 갱신한다.테이블의 갱신은,mysql_fix_privilege_tables (을)를 사용해 실시한다.순서에 대해서는, 항2.5.6. 「권한 테이블의 업그레이드」 (을)를 참조.

4.1 그럼, 보다 강력한 시큐러티를 실현하도록(듯이) 패스워드의 해시 메카니즘이 변경되고 있습니다.다만,4.0 이전의 클라이언트 라이브러리를 사용하는 클라이언트가 있는 경우에, 호환성의 문제가 발생하는 일이 있습니다(4.1 에 업그레이드 되어 있지 않은 리모트 호스트로부터 클라이언트가 접속하는 상황에서는 4.0 클라이언트가 있을 가능성이 매우 높습니다).생각할 수 있는 몇개의 업그레이드 방침을 이하에 나타냅니다.구버젼의 클라이언트와의 호환성의 목표와 시큐러티의 목표의 사이에 다양한 트레이드 오프가 존재합니다.

  • 4.1 에 업그레이드 하지 않는다.동작은 변화하지 않지만, 당연히 4.1 클라이언트/ 서버 프로토콜에 의해서 제공되는 신기능도 일절 사용할 수 없다(MySQL 4.1 에는, 프리페아드스테이트먼트나 복수 결과 세트등의 기능을 제공하는 확장 클라이언트/ 서버 프로토콜이 짜넣어지고 있다). See 항11.1.4. 「C API 의 프리페아드스테이트먼트」 .

  • 4.1 에 업그레이드 하고,mysql_fix_privilege_tables 스크립트를 실행하고, 긴 패스워드 해시를 격납할 수 있도록 user 테이블의 Password 컬럼을 확장한다.다만,--old-passwords 옵션을 지정해 서버를 실행하고,4.1 보다 전의 버젼의 클라이언트가 계속해 짧은 해시의 클라이언트 어카운트에 접속할 수 있게 해 하위 호환성을 실현한다 모든 클라이언트가 4.1 에 업그레이드 되면, 최종적으로 --old-passwords 서버 옵션의 사용을 안?~ 할 수 있는 또,MySQL 어카운트의 패스워드를, 보다 안전하고 새로운 형식을 사용하도록(듯이) 변경할 수도 있다

  • 4.1 에 업그레이드 하고,mysql_fix_privilege_tables 스크립트를 실행하고,user 테이블의 Password 컬럼을 확장한다.모든 클라이언트가 4.1 에 업그레이드 되고 있는 것을 알 수 있고 있는 경우는,--old-passwords 옵션을 지정하지 않고 서버를 실행한다.대신에, 기존의 모든 어카운트의 패스워드를, 새로운 형식을 가지도록(듯이) 변경한다.순수한 4.1 인스톨이 가장 안전하다.

클라이언트 인증과 패스워드 변경 조작에 관계하는 패스워드 해시의 예비 지식에 대해서는, 항4.3.11. 「MySQL 4.1 의 패스워드 해시」 (을)를 참조해 주세요.

2.5.2. 버젼 3.23 (으)로부터 4.0 에의 업그레이드

일반적으로, 이전의 MySQL 버젼으로부터 4.0 에 업그레이드 하는 경우는, 이하를 실행할 필요가 있습니다.

  • 업그레이드 후에, 권한 테이블을 갱신해 새로운 특권과 기능을 추가한다.테이블의 갱신은,mysql_fix_privilege_tables 스크립트를 사용해 실시한다.순서에 대해서는, 항2.5.6. 「권한 테이블의 업그레이드」 (을)를 참조.

  • 폐?~ 예정의 옵션을 사용하지 않게 MySQL 기동 스크립트 또는 옵션 설정 파일을 편집한다.폐?~ 예정의 옵션에 대해서는, 이 섹션의 후반에 설명한다.

  • mysql_convert_table_format 스크립트를 사용하고, 구버젼의 ISAM 파일을 MyISAM 파일로 변환한다(이 스크립트는,Perl 스크립트이기 위해,DBI (을)를 인스톨 할 필요가 있다).특정의 데이타베이스내의 테이블을 변환하려면 , 이하의 커멘드를 사용한다.

    shell> mysql_convert_table_format
데이타베이스명

    주의: 이 커멘드는, 데이타베이스내의 모든 테이블이 ISAM 테이블 또는 MyISAM 테이블인 경우에게만 사용한다.다른 형태의 테이블을 MyISAM (으)로 변환하지 않게 하려면 , 커멘드 라인의 데이타베이스명의 뒤로 ISAM 테이블의 이름을 명시적으로 열기한다.

    그 밖에, 테이블을 MyISAM (으)로 변환하기 위한 ALTER TABLE table_name TYPE=MyISAM 스테이트먼트를 각 ISAM 테이블에 대해서 발행할 수도 있다.

    특정의 테이블의 테이블형을 확인하려면 , 이하의 스테이트먼트를 사용한다.

    mysql> SHOW TABLE STATUS LIKE 'tbl_name';

  • 공유 라이브러리(Perl DBD-mysql 모드등)을 사용한다 MySQL 클라이언트가 없는 것을 확인한다.libmysqlclient.so 그리고 사용되는 데이터 구조가 변경되었으므로, 그러한 클라이언트가 있는 경우는, 그러한 클라이언트를 재컴파일 할 필요가 있다. 같은 것은,Python MySQLdb 모듈등의 그 외의 MySQL 인터페이스에 대해서도 들어맞는다.

상기의 처리를 실시하지 않아도 MySQL 4.0 (은)는 동작합니다만, 새로운 시큐러티 특권을 사용할 수 없기 때문에, 다음에 MySQL 4.1 이?~ 에 업그레이드 할 경우에 문제가 발생하는 일이 있습니다.ISAM 파일 형식은,MySQL 4.0 그럼 계속 기능합니다만, 폐?~ 예정이며,MySQL 4.1 그럼 무효화됩니다(디폴트에서는 컴파일 되지 않는다).대신에,MyISAM 테이블이 사용됩니다.

구버젼의 클라이언트는, 버젼 4.0 서버와 지장 없게 제휴해 동작합니다.

상기의 처리를 실시했을 경우에서도,MySQL 4.0 시리즈로 문제가 발생했을 때는,MySQL 3.23.52 이?~ 에 다운 그레이드 할 수 있습니다.그 경우,mysqldump (을)를 사용하고, 풀 텍스트 인덱스를 사용하는 모든 테이블을 덤프 해, 덤프 파일을 3.23 서버에 재로드할 필요가 있습니다. 이것은,4.0 그럼 풀 텍스트 인덱스 작성에 새로운 형식이 사용되기 (위해)때문입니다.

이하에서는, 버젼 4.0 에 업그레이드 할 경우에 주의할 필요가 있는 점에 대해 한층 더 자세하게 설명합니다.

  • MySQL 4.0 의 mysql.user 테이블에는 다수의 새로운 권한이 있다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

    이러한 새로운 권한을 기능시키기 위해서는, 권한 테이블을 갱신할 필요가 있다. 갱신의 순서에 대해서는, 항2.5.6. 「권한 테이블의 업그레이드」 (을)를 참조. 권한 테이블을 갱신할 때까지는, 모든 유저가 SHOW DATABASES 권한,CREATE TEMPORARY TABLES 권한, 및 LOCK TABLES 권한을 가진다.SUPER 권한과 EXECUTE 권한은,PROCESS (으)로부터 자신의 값을 취득한다. REPLICATION SLAVE 권한과 REPLICATION CLIENT 권한은,FILE (으)로부터 자신의 값을 취득한다.

    새로운 유저를 작성하는 스크립트가 있는 경우는, 새로운 권한을 사용하도록(듯이) 그러한 스크립트를 변경할 필요가 있다.그러한 스크립트로 GRANT 커멘드를 사용하고 있지 않는 경우는, 권한 테이블을 직접 변경하는 대신에 GRANT (을)를 사용하도록(듯이) 스크립트를 변경하는 좋을 기회이다.

    4.0.2 이?~ 그럼, 옵션 --safe-show-database (은)는 폐?~ 되어 어떤 동작도 하지 않는다. See 항4.3.3. 「시큐러티 관련의 mysqld 스타트 업 옵션」 .

    버젼 4.0.2 그리고, 새로운 유저에 대해서 Access denied 에러가 발생했을 경우는, 지금까지는 필요가 없었다 몇개의 새로운 권한이 필요한지 어떤지를 체크한다.특히, 새로운 슬레이브에 대해서는 FILE 대신에 REPLICATION SLAVE 하지만 필요.

  • safe_mysqld (은)는,mysqld_safe (이)라는 이름으로 변경되었다.하위 호환성을 위해서, 당분간의 사이, 바이너리 디스트리뷰션에는 mysqld_safe 에의 기호 연결로서 safe_mysqld 하지만 포함할 수 있고 있다.

  • InnoDB 하지만 바이너리 디스트리뷰션에 디폴트로 짜넣어지게 되었다. MySQL (을)를 소스로부터 빌드 했을 경우는, 디폴트로 InnoDB 하지만 짜넣어진다. InnoDB 하지만 유효하게 되어 있는 서버를 기동하는 경우,InnoDB (을)를 사용하지 않고 메모리를 절약하고 싶을 때는,--skip-innodb 서버 기동 옵션을 사용한다.InnoDB (을)를 짜넣지 마 MySQL (을)를 컴파일 하려면 ,--without-innodb 옵션을 지정해 configure (을)를 실행한다.

  • 기동 파라미터 myisam_max_extra_sort_file_size 및 myisam_max_extra_sort_file_size (은)는, 아르바이트 단위로 지정되게 되었다(4.0.3 보다 전의 버젼에서는메가바이트 단위로 지정되어 있었다).

  • MyISAM/ISAM 파일의 외부 시스템 락은, 디폴트로 오프로 설정되게 되었다.이것은,--external-locking (을)를 실행하고 온으로 할 수 있다(다만, 통상은 온으로 할 필요는 없다).

  • 이하의 기동 변수 및 기동 옵션의 이름이 변경되었다.

    변경전의 이름 | 변경 후의 이름
    myisam_bulk_insert_tree_size | bulk_insert_buffer_size
    query_cache_startup_type | query_cache_type
    record_buffer | read_buffer_size
    record_rnd_buffer | read_rnd_buffer_size
    sort_buffer | sort_buffer_size
    warnings | log-warnings
    --err-log | --log-error (mysqld_safe 용)

    record_buffer ,sort_buffer , 및 warnings 의 각 기동 옵션은,MySQL 4.0 그렇지만 기능하지만, 폐?~ 예정이다.

  • 이하의 SQL 변수의 이름이 변경되었다.

    변경전의 이름 | 변경 후의 이름
    SQL_BIG_TABLES | BIG_TABLES
    SQL_LOW_PRIORITY_UPDATES | LOW_PRIORITY_UPDATES
    SQL_MAX_JOIN_SIZE | MAX_JOIN_SIZE
    SQL_QUERY_CACHE_TYPE | QUERY_CACHE_TYPE

    변경전의 이름은,MySQL 4.0 그렇지만 기능하지만, 폐?~ 예정이다.

  • SET SQL_SLAVE_SKIP_COUNTER=# 대신에 SET GLOBAL SQL_SLAVE_SKIP_COUNTER=# (을)를 사용할 필요가 있다.

  • mysqld 기동 옵션 --skip-locking 및 --enable-locking (은)는, 각각,--skip-external-locking 및 --external-locking (이)라는 이름으로 변경되었다.

  • SHOW MASTER STATUS (은)는, 바이너리 로그가 유효하게 되지 않은 경우는 하늘세트를 돌려주게 되었다.

  • SHOW SLAVE STATUS (은)는, 슬레이브가 초기화되어 있지 않은 경우는 하늘세트를 돌려주게 되었다.

  • mysqld 의 --temp-pool 옵션은 디폴트로 유효하게 될 대로 되었다.이 옵션을 사용하면, 일부의 operating system(가장 현저한 것은 Linux )(으)로 퍼포먼스가 향상하기 위해(때문에)이다.

  • DOUBLE 컬럼과 FLOAT 컬럼은,UNSIGNED 플래그를 받아들이게 되었다(이전에는, 이러한 컬럼에서는 UNSIGNED (은)는 무시되고 있었다).

  • MySQL 4.0.11 이?~ 그럼,ORDER BY col_name DESC (은)는,NULL 값을 마지막으로 한다.3.23 (와)과 4.0.11 보다 전의 4.0 버젼에서는, 경우에 따라 차이가 났다.

  • SHOW INDEX 의 컬럼은 3.23 보다 2 개 증가하고 있다(Null (와)과 Index_type ).

  • CHECK ,LOCALTIME , 및 LOCALTIMESTAMP (은)는 예약어(reserved word)가 되었다.

  • 비트마다의 연산자(| ,& ,<< ,>> , 및 ~ )의 결과는, 부호없이 되었다.부호 첨부의 결과가 필요한 문맥으로 이것들을 사용하면, 문제를 일으키는 일이 있다. See 항6.3.5. 「캐스트 함수」 .

  • 주의: 정수치의 감산으로 어느 쪽인지 한편의 정수치가 UNSIGNED 형태의 경우, 결과의 값은 부호없이 된다.즉,MySQL 4.0 에 업그레이드 하기 전에, 어플리케이션을 체크하고, 부호 없음의 엔티티로부터 값을 공제하고, 부의 대답을 얻고 싶은 경우나, 정수 컬럼으로부터 부호 없음의 값을 공제하는 경우가 없는가를 확인한다.mysqld (을)를 기동할 경우에 --sql-mode=NO_UNSIGNED_SUBTRACTION 옵션을 사용하면, 이 동작을 무효로 할 수 있다. See 항6.3.5. 「캐스트 함수」 .

  • 테이블로 MATCH ... AGAINST (... IN BOOLEAN MODE) (을)를 사용하려면 ,REPAIR TABLE table_name USE_FRM 그리고 테이블을 재빌드 할 필요가 있다.

  • LOCATE() (와)과 INSTR() (은)는, 몇개의 인수가 바이너리 문자열인 경우에 케이스 의존이 된다.그 이외의 경우는, 케이스비의존이다.

  • STRCMP() (은)는, 비교를 실행할 경우에 현재의 캐릭터 세트를 사용하게 되었다.즉, 디폴트의 비교 동작은 케이스비의존이 되었다.

  • HEX(string) (은)는,string 그리고 16 진수에 변환된 문자를 돌려준다.수치를 16 진수로 변환하고 싶은 경우는, 반드시, 수치 인수를 지정해 HEX() (을)를 호출한다.

  • 3.23 그럼,INSERT INTO ... SELECT (은)는, 항상 IGNORE 하지만 유효하게 되어 있었다. 4.0.1 그럼,IGNORE 하지만 지정되어 있지 않은 한,MySQL (은)는 에러가 발생하면 디폴트로 정?~ 한다(그리고, 경우에 따라 롤백(rollback) 한다).

  • CFLAGS=-DUSE_OLD_FUNCTIONS (을)를 지정해 MySQL (을)를 컴파일 하고 있지 않는 한, 구버젼의 C API 함수 mysql_drop_db() ,mysql_create_db() , 및 mysql_connect() (은)는 서포트되지 않게 되었다.다만, 대신에 새롭다 4.0 API (을)를 사용하도록(듯이) 클라이언트 프로그램을 변경하는 것이 바람직하다.

  • MYSQL_FIELD 구조체의 length 및 max_length (은)는,unsigned int (으)로부터 unsigned long (으)로 변경되었다.함수의 printf() 클래스의 인수로서 이것들을 사용했을 경우에, 경고 메세지가 생성되는 일이 있는 이외는, 이 변경에 의해서 문제가 발생할 것은 없다.

  • 테이블에서 모든 레코드를 삭제하는 경우나, 삭제된 레코드의 수의 카운트를 취득할 필요가 없는 경우는,TRUNCATE TABLE (을)를 사용할 필요가 있다(4.0 그럼 DELETE FROM table_name 하지만 레코드 카운트를 돌려주어,TRUNCATE TABLE (은)는 속도가 올랐다).

  • TRUNCATE TABLE 또는 DROP DATABASE (을)를 실행할 경우에, 액티브한 LOCK TABLES 또는 트랜잭션(transaction)가 있으면, 에러가 발생한다.

  • 정수를 사용해 BIGINT 컬럼에 값을 격납할 필요가 있다(MySQL 3.23 그럼 문자열을 사용하고 있었다).계속 문자열을 사용할 수도 있지만, 정수를 사용하는 것이 효율적이다.

  • SHOW OPEN TABLES 의 형식이 변경되었다.

  • multi-thread화 된 클라이언트는,mysql_thread_init() 및 mysql_thread_end() (을)를 사용할 필요가 있다. See 항11.1.14. 「스레드 클라이언트의 작성 방법」 .

  • Perl DBD::mysql 모듈을 재컴파일 하는 경우는,DBD-mysql 버젼 1.2218 이?~ (을)를 입수할 필요가 있다.이것은,1.2218 보다 전의 버젼의 DBD 모듈에서는, 폐?~ (이)가 되었다 mysql_drop_db() 콜이 사용되기 때문에 있다. 버젼 2.1022 이?~ 하지만 추천 된다.

  • 4.0 그럼,RAND(seed) 하 3.23 의 경우와는 다른 난수계를 돌려준다.이 변경은,RAND(seed) (와)과 RAND(seed+1) (을)를 한층 더 명확하게 구별하기 위해서 행해졌다.

  • IFNULL(A,B) 에 의해서 돌려주어지는 디폴트의 형태는,A 및 B 의 형태중에서, 보다 ' 총칭적인' 분이 설정되게 되었다(총칭성의 정도의 높은 순서에 늘어놓으면, 문자열,REAL ,INTEGER 된다).

Windows 위에서 MySQL 서버를 실행하는 경우는, 항2.5.8. 「Windows 위에서의 MySQL 의 업그레이드」 도 참조해 주세요.replication를 사용하는 경우는, 항4.11.2. 「replication 실장의 개요」 도 참조해 주세요.

2.5.3. 버젼 3.22 (으)로부터 3.23 에의 업그레이드

MySQL 버젼 3.23 (은)는, 새롭다 MyISAM 형태와 이전의 ISAM 형태의 테이블을 서포트합니다.버젼 3.23 그리고 이전의 테이블을 사용하는 경우에, 그러한 테이블을 변환할 필요는 없습니다.디폴트에서는, 새로운 테이블은 모두,MyISAM 형태로 작성됩니다(다만,--default-table-type=isam 옵션을 지정해 mysqld (을)를 기동했을 경우를 제외합니다).ISAM 테이블은,ALTER TABLE table_name TYPE=MyISAM 또는 Perl 스크립트 mysql_convert_table_format (을)를 사용해 MyISAM 형식으로 변환할 수 있습니다.

버젼 3.22 및 3.21 의 클라이언트는, 버젼 3.23 서버와 지장 없게 제휴해 동작합니다.

이하에서는, 버젼 3.23 에 업그레이드 할 경우에 주의할 필요가 있는 사항에 대해 설명합니다.

  • tis620 캐릭터 세트를 사용하는 테이블은 모두,myisamchk -r 또는 REPAIR TABLE 그리고 수복할 필요가 있다.

  • 상징적에 링크된 데이타베이스에 DROP DATABASE (을)를 실행했을 경우, 링크와 원래의 데이타베이스의 양쪽 모두가 삭제된다(3.22 그럼,configure 하 readlink() 시스템 콜의 사용 가능성을 검출하지 않기 때문에, 이것은 행해지지 않았다).

  • OPTIMIZE TABLE (은)는,MyISAM 테이블에만 대응하게 되었다. 이외의 테이블형의 테이블을 최적화하려면 ,ALTER TABLE (을)를 사용한다. OPTIMIZE TABLE 의 실행중은, 다른 스레드에 사용되는 것을 막기 위해서 테이블이 락 되게 되었다.

  • MySQL 클라이언트 mysql (은)는, 디폴트로 --no-named-commands (-g) (을)를 지정해 기동되게 되었다.이 옵션은,--enable-named-commands (-G) (을)를 지정하고 무효로 할 수 있다.경우에 의해서, 이것에 의해서 비호환성의 문제가 발생하는 일이 있다(세?~ 코론 없음의 이름 커멘드를 사용한다 SQL 스크립트등의 경우).제 1 행목의 롱 형식의 커멘드는 계속해 유효하다.

  • 일자의 부분을 처리하는 일자 함수(MONTH() 등)은,0000-00-00 일자의 경우에 0 (을)를 돌려주게 되었다(MySQL 3.22 그럼, 이러한 함수는 NULL (을)를 돌려주고 있었다).

  • ISAM 테이블에 german 문자 소트 순서를 사용하고 있는 경우는,isamchk -r (을)를 사용해 그러한 테이블을 수복할 필요가 있다.이것은, 이 소트 순서에 몇개의 변경이 더해졌기 때문이다.

  • IF() 의 디폴트의 반환값의 형태는, 최초의 인수에만 의존하는 것이 아니라, 양쪽 모두의 인수에 의존하게 되었다.

  • AUTO_INCREMENT 컬럼을 사용해 부의 수를 격납하지 않게 한다.부의 수를 격납했을 경우에,-1 (으)로부터 0 에 랩 할 경우에 문제가 발생했기 때문이다.AUTO_INCREMENT 컬럼에게는 0 (을)를 격납해서는 안 된다.CHECK TABLE (은)는,0 값에 대해서 경고를 돌려준다.0 값은 테이블을 덤프 해 restore 했을 경우에, 변화하는 일이 있기 때문에 있다.MyISAM 테이블의 AUTO_INCREMENT (은)는, 보다 낮은 레벨로 처리되게 되어, 이전보다 꽤 고속으로 되어 있다.게다가MyISAM 테이블에서는, 테이블에서 레코드를 삭제했을 경우에서도, 낡은 번호는 재이용되지 않게 되었다.

  • CASE ,DELAYED ,ELSE ,END ,FULLTEXT ,INNER ,RIGHT ,THEN , 및 WHEN (은)는 예약어(reserved word)가 되었다.

  • FLOAT(X) (은)는, 진정한 부동 소수점형이 되어, 소수부의 자리수가 고정된 값이 아니게 되었다.

  • DECIMAL(length,dec) 형태를 사용해 컬럼을 선언할 경우에,length 인수에 부호와 소수점의 위치가 포함되지 않게 되었다.

  • TIME 문자열은, 이하의 몇개의 형식으로 하지 않으면 안 되게 되었다. [[[DAYS] [H]H:]MM:]SS[.fraction] 또는 [[[[[H]H]H]H]MM]SS[.fraction] .

  • LIKE (은)는,= 연산자의 경우와 같은 문자 비교 룰을 사용해 문자열을 비교하게 되었다.구버젼의 동작이 필요한 경우는,CXXFLAGS=-DLIKE_CMP_TOUPPER 플래그를 지정해 MySQL (을)를 컴파일 한다.

  • REGEXP (은)는, 어느 쪽의 문자열도 바이너리 문자열이 아닌 경우는 케이스비의존이 되었다.

  • MyISAM (.MYI ) 테이블을 체크 또는 수복하는 경우는,CHECK TABLE 스테이트먼트 또는 myisamchk 커멘드를 사용할 필요가 있다.ISAM (.ISM ) 테이블의 경우는,isamchk 커멘드를 사용한다.

  • mysqldump 파일에 MySQL 버젼 3.22 (와)과 버젼 3.23 의 사이의 호환성을 갖게하고 싶은 경우는,mysqldump 에 --opt 옵션 또는 --all 옵션을 지정하지 않는다.

  • DATE_FORMAT() 에의 모든 콜을 체크하고, 각 서식 문자의 전에 ‘% ＇ 하지만 있는 것을 확인한다 (MySQL 버젼 3.22 이?~ 그리고, 이 구문은 벌써 허가되고 있다).

  • mysql_fetch_fields_direct() (은)는 함수가 되어(지금까지는 매크로),MYSQL_FIELD 대신에 MYSQL_FIELD 에의 포인터를 돌려주게 되었다.

  • mysql_num_fields() (은)는,MYSQL* 오브젝트에 대해서 사용할 수 없게 되었다(인수로서 MYSQL_RES* 값을 받는 함수가 되었다).MYSQL* 오브젝트에는, 대신에 mysql_field_count() (을)를 사용한다.

  • MySQL 버젼 3.22 그럼,SELECT DISTINCT ... 의 출력은, 대부분의 경우 소트 되었다.버젼 3.23 그럼, 소트 된 출력을 취득하려면 ,GROUP BY 또는 ORDER BY (을)를 사용할 필요가 있다.

  • SUM() (은)는, 일치하는 레코드가 없는 경우에 0 대신에 NULL (을)를 돌려주게 되었다.이것은,SQL-99 에 대응한 것이다.

  • NULL 값을 가진다 AND 또는 OR (은)는,0 대신에 NULL (을)를 돌려주게 되었다.이것은, 주로,NOT NULL = NULL (와)과 같이,AND/OR 식에서 NOT (을)를 사용하는 쿼리에 영향을 미친다.

  • LPAD() 및 RPAD() (은)는, 결과의 문자열이 length 인수보다 긴 경우에, 그 문자열을 짧게 하게 되었다.

2.5.4. 버젼 3.21 (으)로부터 3.22 에의 업그레이드

버젼 3.21 (와)과 버젼 3.22 의 사이에서는 호환성에 영향을 주는 변경은 행해지고 있지 않습니다. 유일한 함정은,DATE 형태 컬럼으로 작성된 새로운 테이블에서는, 새로운 방법으로 일자가 격납되는 것입니다.구버젼의 mysqld (으)로부터 이러한 새로운 컬럼에 액세스 할 수 없습니다.

MySQL 버젼 3.22 (을)를 인스톨 한 후에, 새로운 서버를 기동하고,mysql_fix_privilege_tables 스크립트를 실행할 필요가 있습니다.이 스크립트에 의해서,GRANT 커멘드를 사용하기 위해서 필요한 새로운 권한이 추가됩니다.이 처리를 하지 않으면ALTER TABLE ,CREATE INDEX , 또는 DROP INDEX (을)를 사용하려고 했을 때에,Access denied 하지만 돌려주어집니다.권한 테이블의 갱신의 순서에 대해서는, 항2.5.6. 「권한 테이블의 업그레이드」 (을)를 참조해 주세요.

mysql_real_connect() 에의 C API 인터페이스는 변경되었습니다.이 함수를 호출하는 구버젼의 클라이언트 프로그램이 있는 경우는, 새롭다 db 인수에 0 (을)를 지정합니다(또는 db 요소를 송신하도록(듯이) 클라이언트의 코드를 다시 작성합니다).또,mysql_real_connect() (을)를 호출하기 전에 mysql_init() (을)를 호출할 필요도 있습니다.이 변경은, 새롭다 mysql_options() 함수가 MYSQL 핸들러 구조에 옵션을 보존할 수 있듯이 하기 위해서 행해졌습니다.

mysqld 변수 key_buffer (은)는,key_buffer_size (이)라는 이름으로 변경되었습니다.다만, 기동 파일에서는 이전의 이름을 계속해 사용할 수 있습니다.

2.5.5. 버젼 3.20 (으)로부터 3.21 에의 업그레이드

버젼 3.20.28 보다 전의 버젼을 실행하고 있고, 버젼 3.21 (으)로 전환하는 경우는, 이하를 실시할 필요가 있습니다.

--old-protocol 옵션을 지정해 mysqld 버젼 3.21 서버를 기동하고, 그 서버를 버젼 3.20 디스트리뷰션으로부터의 클라이언트와 함께 사용할 수 있습니다.이 경우, 새로운 클라이언트 함수 mysql_errno() (은)는, 서버 에러는 돌려주지 않고,CR_UNKNOWN_ERROR 만을 돌려줍니다(다만, 이 함수는 클라이언트 에러에 대해서는 기능합니다).또, 서버는, 새로운 방식이 아니고,3.21 보다 전의 낡다 password() 체크 방식을 사용합니다.

mysqld 에 --old-protocol 옵션을 사용 하지 않는다 경우는, 이하의 변경을 실시할 필요가 있습니다.

  • 모든 클라이언트 코드를 재컴파일 한다.ODBC (을)를 사용하고 있는 경우는, 새롭다 MyODBC 2.x 드라이버를 입수하는 것.

  • scripts/add_long_password 스크립트를 실행하고,mysql.user 테이블의 Password 필드를 CHAR(16) (으)로 변환한다.

  • 모든 패스워드를 mysql.user 테이블에 다시 할당한다(31 비트의 패스워드는 아니고 62 비트의 패스워드를 취득하기 위해(때문에)).

  • 테이블 형식은 변경되어 있지 않기 때문에, 테이블을 변환할 필요는 없다.

MySQL 버젼 3.20.28 이?~ 그럼, 클라이언트에 영향을 미치는 일 없이 새롭다 user 테이블 형식을 처리할 수 있습니다.버젼 3.20.28 보다 전의 MySQL 버젼을 사용하고 있는 경우,user 테이블을 변환하면, 패스워드는 그 MySQL 그럼 무효가 됩니다.따라서, 안전을 위해서, 최초로 버젼 3.20.28 이상으로 업그레이드 하고 나서, 버젼 3.21 에 업그레이드 해 주세요.

새로운 클라이언트 코드는 3.20.x mysqld 서버와 제휴해 동작합니다.따라서,3.21.x 그리고 문제가 발생했을 경우는, 클라이언트를 재컴파일 하지 않아도 기존의 3.20.x 서버를 사용할 수 있습니다.

mysqld 에 --old-protocol 옵션을 사용하지 않으면 구버젼의 클라이언트는 접속하지 못하고, 이하의 에러 메세지를 출력합니다.

ERROR: Protocol mismatch. Server Version = 10 Client Version = 9

새롭다 Perl DBI/DBD 인터페이스는, 구버젼의 mysqlperl 인터페이스도 서포트합니다.mysqlperl (을)를 사용하는 경우로 유일 변경할 필요가 있는 것은,connect() 함수의 인수입니다. 새로운 인수는,host ,database ,user , 및 password 입니다(주의: user 인수와 password 인수는 순서가 바뀌었습니다). See 항11.5.2. 「DBI 인터페이스」 .

이하의 변경은, 구버젼의 어플리케이션의 쿼리에 영향을 미치는 일이 있습니다.

  • HAVING 하 ORDER BY 마디의 전으로 지정하지 않으면 안 되게 되었다.

  • LOCATE() 의 파라미터의 순서를 바꿔 넣을 수 있었다.

  • 몇개의 새로운 예약어(reserved word)가 있다.가장 주목해야할 것은,DATE ,TIME , 및 TIMESTAMP 이다.

2.5.6. 권한 테이블의 업그레이드

일부의 릴리스에서는, 권한 테이블(mysql 데이타베이스내의 테이블)의 구조가 변경되어 새로운 권한 또는 기능이 추가되고 있습니다.새로운 버젼의 MySQL 에 갱신했을 때에 권한 테이블이 확실히 최신의 것이도록(듯이) 하려면 , 권한 테이블도 갱신할 필요가 있습니다.

Unix 시스템 또는 Unix 좋아하는 시스템에서는, 이하와 같이 mysql_fix_privilege_tables 스크립트를 실행해 권한 테이블을 갱신합니다.

shell> mysql_fix_privilege_tables

이 스크립트는, 서버의 가동중에 실행하지 않으면 안됩니다.이 스크립트는, 로컬 호스트상에서 가동하고 있는 서버에 root (으)로서 접속합니다. root 어카운트가 패스워드를 필요로 하는 경우는, 커멘드 라인으로 패스워드를 지정합니다.MySQL 4.1 이?~ 의 버젼의 경우는, 이하와 같이 패스워드를 지정합니다.

shell> mysql_fix_privilege_tables --password=root_password

MySQL 4.1 보다 전의 버젼의 경우는, 이하와 같이 패스워드를 지정합니다.

shell> mysql_fix_privilege_tables root_password

mysql_fix_privilege_tables 스크립트는, 권한 테이블을 현행의 형식으로 변환하기 위해서 필요한 처리를 실행합니다.스크립트의 실행중에 몇개의 Duplicate column name 경고가 표시되는 일이 있습니다.이러한 경고는 무시해 괜찮습니다.

스크립트의 실행 후에, 서버를 정?~ 하고 나서, 재기동합니다.

Windows 시스템에서는,MySQL 4.0.15 까지는, 권한 테이블을 간단하게 갱신하는 방법은 없습니다.버젼 4.0.15 이?~ 그럼,mysql 클라이언트를 사용해 실행할 수 있다 mysql_fix_privilege_tables.sql SQL 스크립트가 MySQL 디스트리뷰션에 포함되어 있습니다.MySQL 하지만 C:\mysql 에 인스톨 되고 있는 경우, 커멘드는 이하와 같이 됩니다.

C:\mysql\bin> mysql -u root -p mysql

mysql> SOURCE C:\mysql\scripts\mysql_fix_privilege_tables.sql

MySQL 하지만 이외의 디렉토리에 인스톨 되고 있는 경우는, 패스명을 거기에 맞추어 변경해 주세요.

이 커멘드는,root 의 패스워드의 입력을 요구하는 prompt를 표시합니다.prompt가 표시되면 패스워드를 입력합니다.

Unix 의 순서의 경우와 같게,mysql 하지만 mysql_fix_privilege_tables.sql 스크립트의 스테이트먼트를 처리하고 있을 때 몇개의 Duplicate column name 경고가 표시되는 일이 있습니다.이러한 경고는, 무시해 괜찮습니다.

스크립트의 실행 후에, 서버를 정?~ 하고 나서, 재기동합니다.

2.5.7. 다른 Archie 텍 차에의 이행

MySQL 버젼 3.23 (을)를 사용하고 있는 경우, 같은 부동 소수점 형식을 서포트하는 다른 Archie 텍 차간으로,MyISAM 테이블의 .frm ,.MYI , 및 .MYD 의 각 파일을 카피할 수 있습니다(MySQL (은)는 아르바이트 스왑의 문제를 처리합니다). See 항7.1. 「MyISAM 테이블」 .

MySQL ISAM 데이터 파일 및 인덱스 파일(각각,.ISD 및 *.ISM )(은)는, Archie 텍 차 의존이며, 경우에 따라서는 OS 에도 의존합니다.현재의 머신과는 다른 Archie 텍 차 또는 OS (을)를 가지는 다른 머신에 어플리케이션을 이동하고 싶은 경우, 그 머신에 파일을 단순하게 카피하는 것 만으로는, 데이타베이스를 이동할 수 없습니다.대신에,mysqldump (을)를 사용해 주세요.

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

결과를 파일에 보존해, 그 파일을 이동처의 머신에 전송 하고, 그 머신상의 데이타베이스에 로드할 수도 있습니다.예를 들어, 이하와 같이, 이동원의 머신상의 파일에 데이타베이스를 덤프 합니다.

shell> mysqldump --quick db_name | gzip > db_name.contents.gz

(이 예로 작성되는 파일은 압축되고 있습니다.) 데이타베이스의 내용이 격납된 파일을 이동처의 머신에 전송 해, 그 머신상에서 이하의 커멘드를 실행합니다.

shell> mysqladmin create db_name
shell> gunzip < db_name.contents.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           #
데이타베이스 작성
shell> cat DUMPDIR/*.sql | mysql db_name   #
테이블 작성
shell> mysqlimport db_name DUMPDIR/*.txt   # load data into tables

또,mysql 데이타베이스도 잊지 않고 카피해 주세요.이 데이타베이스에는, 권한 테이블 (user ,db ,host ) 하지만 격납되고 있기 (위해)때문입니다.mysql 데이타베이스를 배치할 때까지는, 이동처의 머신상에서 MySQL root 유저로서 커멘드를 실행할 필요가 있습니다.

mysql 데이타베이스를 이동처의 머신에 데이타베이스를 임포트 하면,mysqladmin flush-privileges (을)를 실행하고, 서버에 권한 테이블 정보를 재로드 시킵니다.

2.5.8. Windows 위에서의 MySQL 의 업그레이드

Windows 위에서 MySQL (을)를 업그레이드 하는 경우는, 이하의 순서에 따라서 실시합니다.

  1. 최신의Windows 용 MySQL 디스트리뷰션을 다운로드한다.

  2. 보수를 위한 서버의 정?~ 하지만 용서되는, 사용율의 낮은 시간대를 선택한다.

  3. 액티브하게 되어 있는 유저에게 보수를 위해서 정?~ 하는 것을 통지한다.

  4. 가동하고 있다 MySQL 서버를 정?~ 한다(MySQL (을)를 서비스로서 실행하고 있는 경우는 NET STOP mysql 또는 Services 유틸리티, 그 이외의 경우는 mysqladmin shutdown (을)를 사용한다).

  5. WinMySQLAdmin 프로그램을 실행하고 있는 경우는, 이 프로그램을 종료한다.

  6. 현재 사용중의 데이터( 디폴트에서는 c:\mysql\data ) (을)를 만약을 위해 백업 한다.

  7. WinZip 의［Install ］버튼을 클릭해, 인스톨 스크립트의 인스톨 스텝에 따라서,Windows 디스트리뷰션의 인스톨 스크립트를 실행한다.

  8. 구버젼의 MySQL (통상은 C:\mysql 에 있다)를 덧쓰기하는지,C:\mysql4 등의 다른 디렉토리에 인스톨 한다.구버젼을 덧쓰기하는 것을 추천 한다.다만,data 하지만 덧쓰기되지 않게 주의한다.

  9. 서버를 재기동한다(MySQL (을)를 서비스로서 실행하고 있는 경우는 NET START mysql , 그 이외의 경우는 직접 mysqld (을)를 기동한다).

  10. 권한 테이블을 갱신한다.갱신의 순서에 대해서는, 항2.5.6. 「권한 테이블의 업그레이드」 (을)를 참조.

생각할 수 있는 에러 상황은 이하대로입니다.

A system error has occurred.
System error 1067 has occurred.
The process terminated unexpectedly.

이 에러는,my.cnf 파일(디폴트에서는 C:\my.cnf )에,MySQL 하지만 인식할 수 없는 옵션이 포함되어 있는 것을 나타내고 있습니다.MySQL 하지만 my.cnf 파일을 사용하지 않게 하기 위해서 이 파일의 이름을 my_cnf.old 등에 변경하고,MySQL (을)를 재기동하고, 이것이 사실일지를 확인합니다.사실인 것을 확인하면, 원인이 된 옵션을 특정할 필요가 있습니다.새롭다 my.cnf 파일을 작성하고, 서버의 기동이 실패하는 원인이 되는 옵션을 특정할 때까지, 낡은 파일의 각 파트를 그 파일로 이동합니다(1 개의 파트를 이동할 때마다 서버를 재기동합니다).


2.6. operating system 고유의 주의 사항

2.6.1. Windows 의 주의 사항

여기에서는,Windows 위에서 MySQL (을)를 사용하는 경우에 고유의 문제에 대해 설명합니다.

2.6.1.1. SSH (을)를 사용해 Windows (으)로부터 MySQL 에 리모트 접속한다

여기에서는,SSH (을)를 사용해 리모트의 MySQL 서버와의 안전한 접속을 확립하기 위한 접속 방법에 대해 설명합니다(David Carlson 기(<dcarlson@mplcomm.com> )).

  1. 사용하고 있는 머신에 SSH 클라이언트를 인스톨 한다.사용해 보고 가장 우수한 유상의 SSH 클라이언트는,http://www.vandyke.com/ 의 SecureCRT 이다. 이제(벌써) 1 개는,http://www.f-secure.com/ 의 f-secure 이다.프리 소프트웨어에 대해서는,Google (http://directory.google.com/Top/Computers/Security/Products_and_Tools/Cryptography/SSH/Clients/Windows/ )(으)로 검색할 수 있다.

  2. Windows SSH 클라이언트를 기동한다. Host_Name = yourmysqlserver_URL_or_IP (을)를 설정한다. userid=your_userid (을)를 설정하고, 서버에 로그인한다.이 userid 값은,MySQL 어카운트의 유저명과 같지 않아도 상관없다.

  3. 포토 전송을 설정한다.리모트 전송(local_port: 3306 ,remote_host: yourmysqlservername_or_ip ,remote_port: 3306 (을)를 설정)인가, 로컬 전송(port: 3306 ,host: localhost ,remote port: 3306 (을)를 설정)을 실행한다.

  4. 모든 것을 보존한다.보존하지 않으면 다음 번도 상기의 설정을 실시하지 않으면 안 되게 된다.

  5. 작성했다 SSH 세션으로 서버에 로그인한다.

  6. Windows 머신상에서,ODBC 어플리케이션(Access 등)을 기동한다.

  7. Windows 위에 새로운 파일을 작성해, 통상대로 ODBC 드라이버를 사용해 MySQL 에 링크한다.다만,MySQL 호스트 서버로서yourmysqlservername (은)는 아니고 localhost (을)를 입력한다.

이것으로,SSH (을)를 사용해 암호화된,MySQL 에의 ODBC 접속이 확립되었습니다.

2.6.1.2. Windows 위에서의 MySQL 클라이언트의 컴파일

원시 파일내에서는,mysql.h 의 전에 my_global.h (을)를 인클루드 해 주세요.

#include <my_global.h>
#include <mysql.h>

my_global.h 에는,Windows 위에서 프로그램을 컴파일 하는 경우에 Windows (와)과의 호환성을 위해서 필요한 그 외의 파일(windows.h 등)이 인클루드 되고 있습니다.

코드는, 동적인 libmysql.lib 라이브러리(요구에 따라 libmysql.dll (을)를 로드하는 단순한 나팔)에 링크하는 일도, 정적인 mysqlclient.lib 라이브러리에 링크할 수도 있습니다.

주의: MySQL 클라이언트 라이브러리는 스레드화 된 라이브러리로서 컴파일 되므로, 코드도 multi-thread화 되도록(듯이) 컴파일 할 필요가 있습니다.

2.6.1.3. Windows 위의 MySQL (와)과 Unix 위의 MySQL 의 비교

Windows 용무의 MySQL (은)는, 매우 안정되어 있는 것을 스스로 증명했습니다.Windows 버젼의 MySQL 에는, 거기에 대응한다 Unix 버젼과 같은 기능이 짜넣어지고 있습니다만, 이하의 예외가 있습니다.

  • Windows 95 (와)과 스레드

    Windows 95 (은)는, 스레드 생성마다 약 200 아르바이트의 메인 메모리를 리크 한다. MySQL 에 접속할 때마다 새로운 스레드가 생성되기 위해, 서버가 다수의 접속을 처리하는 경우는,Windows 95 위에서 mysqld (을)를 장시간 실행하지 않는다.그 외의 버젼의 Windows 그럼 이 버그는 없다.

  • 동시 독해

    MySQL (은)는,pread() 호출 및 pwrite() 호출해에 의존하고,INSERT (와)과 SELECT 의 혼재를 가능하게 하고 있다.현시점에서는, 당사는 상호 배타 락(mutex )(을)를 사용해 pread()/pwrite() (을)를 에?~ 레이트 하고 있다.장기적으로는, 처리 속도를 향상시키기 위해서NT/2000/XP 위에서 readfile()/writefile() 인터페이스를 사용할 수 있도록, 파일 레벨의 인터페이스를 가상 인터페이스에 옮겨놓을 예정이다. 현재의 실장에서는,MySQL 하지만 사용할 수 있는 오픈 파일의 수는 1024 개에 제한되고 있다.따라서,NT/2000/XP 위에서는,Unix 의 경우와 같은 수의 동시 실행 스레드를 실행할 수 없다.

  • 블록 독해

    MySQL (은)는, 접속 마다 블록 독해를 사용한다.이것에는, 이하와 같은 의미가 있다.

    • Unix 버젼의 MySQL 의 경우와 같이 8 시간 후에 접속이 자동적으로 절단 되는 것은 없다.

    • 접속이 행 했을 경우,MySQL (을)를 강제 종료하지 않아도 절단 할 수 있다.

    • mysqladmin kill (은)는 sleeve 상태의 접속에서는 기능하지 않는다.

    • sleeve 상태의 접속이 있는 한,mysqladmin shutdown 하지만 중단할 것은 없다.

    이 문제에 대해서는, 당사의 Windows 개발자가 적절한 회피책을 생각해 냈을 때에 수정할 예정이다.

  • DROP DATABASE

    스레드가 사용하고 있는 데이타베이스를 파기할 수 없다.

  • 태스크 매니저로부터 MySQL (을)를 강제 종료한다

    태스크 매니저 또는 Windows 95 의 슛다운 유틸리티를 사용해 MySQL (을)를 강제 종료할 수 없다.MySQL (을)를 정?~ 하려면 ,mysqladmin shutdown (을)를 사용한다.

  • 케이스비의존의 이름

    Windows 그럼, 파일명은 케이스비의존이다.따라서 MySQL 의 데이타베이스명과 테이블명도 Windows 그럼 케이스비의존이다.유일한 제약은, 소정의 스테이트먼트 전체를 통해서 같은 케이스를 사용해 데이타베이스명과 테이블명을 지정할 필요가 있는 것이다. See 항6.1.3. 「이름에 있어서의 케이스 의존」 .

  • ‘\ ＇ 디렉토리 문자

    Windows 95 의 패스명의 구성요소는,‘\ ＇ 문자로 단락지어진다.이것은,MySQL 냄새나도 이스케이프 문자이다.LOAD DATA INFILE 또는 SELECT ... INTO OUTFILE (을)를 사용하는 경우는, 이하와 같이 ‘/ ＇ 문자로 단락짓는다 Unix 스타일의 파일명을 사용한다.

    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;

  • 파이프의 문제

    파이프는,Windows 의 커멘드 라인 prompt에서는 확실히는 기능하지 않는다.파이프에 문자 ^Z / CHAR(24) 하지만 포함되어 있는 경우는,Windows (은)는,End-Of-File (EOF )(을)를 검출했다고 보고, 프로그램을 안?~ 한다.

    이것은, 주로, 이하와 같이 바이너리 로그를 적용하려고 했을 때에 발생하는 문제이다.

    mysqlbinlog binary-log-name | mysql --user=root

    로그를 적용할 경우에 문제가 발생해,^Z / CHAR(24) 문자가 원인이다고 생각되는 경우는, 이하의 회피책을 취한다.

    mysqlbinlog binary-log-file --result-file=/tmp/bin.sql
mysql --user=root --execute "source /tmp/bin.sql"

    2 번째의 커멘드는, 바이너리 데이터가 포함되어 있을 가능성이 있다 SQL 파일을 확실히 읽어 취 취하는 경우에도 사용할 수 있다.

  • Can't open named pipe 에러

    최신의 MySQL 클라이언트 프로그램을 짜넣었다 NT 위에서 MySQL 버젼 3.22 서버를 사용하고 있는 경우에, 이하의 에러가 발생하는 일이 있다.

    error 2017: can't open named pipe to host: . pipe...

    이 에러는, 릴리스 버젼의 MySQL 하지만NT 위에서는 디폴트로 이름 파이프를 사용하는 것이 원인으로 발생한다.새롭다 MySQL 클라이언트에 --host=localhost 옵션을 사용해 이 에러를 회피하는지, 이하의 정보를 격납한 옵션 설정 파일 C:\my.cnf (을)를 작성한다.

    [client]
host = localhost

    버젼 3.23.50 이?~ 그럼,--enable-named-pipe 옵션을 지정해 mysqld-nt 또는 mysqld-max-nt (을)를 기동했을 경우에게만, 이름 파이프가 유효하게 된다.

  • Access denied for user 에러

    MySQL 클라이언트 프로그램을 실행하고, 같은 머신상에서 가동하고 있는 서버에의 접속을 시도했을 때에,Access denied for user: 'some-user@unknown' to database 'mysql' 그렇다고 하는 에러가 표시되었을 경우는,MySQL 하지만 호스트 명분을 세워 구해결할 수 없었던 것을 의미한다.

    이 에러를 수정하려면 , 이하의 정보를 격납했다 \windows\hosts 파일을 작성한다.

    127.0.0.1       localhost

  • ALTER TABLE

    ALTER TABLE 스테이트먼트의 실행중은, 다른 스레드에 의해서 사용되는 것을 막기 위해서 테이블이 락 된다.이것은,Windows 위에서는 다른 스레드가 사용중의 파일을 삭제할 수 없다고 하는 사실에 대처할 필요가 있다.장래, 이 문제의 해결책이 발견될 가능성이 있다.

  • DROP TABLE

    Windows 그럼,MERGE 테이블이 사용하고 있는 테이블에 대해서 DROP TABLE (을)를 실행할 수 없다.이것은,MERGE 핸들러가 실행하는 테이블 매핑을 MySQL 의 상위 레이어가 인식하지 않기 때문이다.Windows 그럼 열려 있는 파일을 파기할 수 없기 때문에, 대상의 테이블을 파기하기 전에,FLUSH TABLES 그리고 모든 MERGE 테이블을 플래시 하는지,MERGE 테이블을 파기할 필요가 있다.이것에 대해서는, 뷰를 도입할 경우에 수정할 예정이다.

  • DATA DIRECTORY (와)과 INDEX DIRECTORY

    Windows 그럼,CREATE TABLE 의 DATA DIRECTORY 옵션과 INDEX DIRECTORY 옵션은 무시된다.이것은,Windows 하지만 기호 연결을 서포트하고 있지 않기 때문이다.

Windows 위의 MySQL 의 개량에 협력해 주시는 유저를 위해서, 미해결의 문제를 이하에 나타낸다.

  • MySQL 에 사용하기 쉬운 기동 아이콘 또는 슛다운 아이콘을 추가한다.

  • 태스크 매니저로부터 mysqld (을)를 강제 종료할 수 있으면 매우 편리하다. 당분간은,mysqladmin shutdown (을)를 사용할 필요가 있다.

  • mysql 커멘드 라인 툴로 사용하기 위해(때문에) Windows 에 readline (을)를 이식한다.

  • GUI 버젼의 표준 MySQL 클라이언트(mysql ,mysqlshow ,mysqladmin , 및 mysqldump )(이)가 있으면 편리하다.

  • net.c 의 소켓 독해 및 기입의 함수가 끼어들어 가능하게 되면 편리하다.이것에 의해서,Windows 그리고 mysqladmin kill (을)를 사용하고, 열려 있는 스레드를 강제 종료할 수 있게 된다.

  • Windows 에 의해서 제공되는 것보다 고속으로 스레드세이후인 인크리먼트(increment)/ 감소 메소드를 사용하는 매크로를 추가한다.

2.6.2. Linux 의 주의 사항(모든 Linux 버젼)

glibc 에 관한 이하의 주의 사항은,MySQL (을)를 스스로 빌드 하는 경우에게만 적용됩니다.x86 머신상에서 Linux (을)를 실행하고 있는 경우, 당사가 제공하는 바이너리를 사용하는 것이 훨씬 적절합니다.당사의 바이너리는, 고부하인 서버에 적절한 것 하기 위해서, 최적인 컴파일러 옵션을 사용하고, 당사가 고안 한 최적인 패치 적용이 끝난 버젼의 glibc (을)를 링크하고 있습니다.일반의 유저에게 있어서, 다수의 동시 접속이나 2GB 의 제한을 넘는 테이블이 있는 구성이어도, 대부분의 경우, 당사의 바이너리는 최선의 선택입니다.이하의 텍스트를 읽고, 어떻게 해야 하는가 판단이 서지 않는 경우는, 최초로 당사의 바이너리를 시험해 자사의 요건을 채울지를 확인해, 충분하지 않은 것을 알 수 있었을 경우에게만 독자적인 빌드를 검토해 주세요.그 경우는, 부족한 점을 당사에 알려주세요.다음 번의 바이너리의 빌드 시에 참고로 하겠습니다.

MySQL (은)는,Linux 위에서 LinuxThreads (을)를 사용합니다.glibc2 하지만 짜넣어지지 않은 구버젼의 Linux (을)를 사용하고 있는 경우는,MySQL (을)를 컴파일 하기 전에 LinuxThreads (을)를 인스톨 할 필요가 있습니다.LinuxThreads (은)는,http://www.mysql.com/downloads/os-linux.html 그리고 입수할 수 있습니다.

주의: SMP 시스템상의 Linux 2.2.14 (와)과 MySQL 그리고 미지의 문제가 발생했던 적이 있습니다.SMP 시스템을 사용하고 있는 경우는, 가능한 한 신속하게 Linux 2.4 에 업그레이드 하는 것을 추천합니다.이것에 의해서, 시스템의 처리 속도와 안정성이 향상합니다.

주의: 버젼 2.1.1 이전의 버젼의 glibc (은)는,INSERT DELAYED 스테이트먼트를 발행했을 때에 사용된다 pthread_mutex_timedwait 처리에 중대한 버그가 있습니다.glibc (을)를 업그레이드 할 때까지는,INSERT DELAYED (을)를 사용하지 않는 것을 추천합니다.

1,000 (을)를 넘는 동시 접속을 예정하고 있는 경우는,LinuxThreads 에 몇개의 변경을 더해 재컴파일 해, 새롭다 libpthread.a (을)를 MySQL 에 재링크할 필요가 있습니다. sysdeps/unix/sysv/linux/bits/local_lim.h 의 PTHREAD_THREADS_MAX (을)를 4096 (으)로 늘려,linuxthreads/internals.h 의 STACK_SIZE (을)를 256 KB (으)로 줄여 주세요.이 패스는 glibc 의 루트로부터의 상대 패스입니다. 주의: STACK_SIZE 하지만 디폴트치의 2MB 인 경우,MySQL (은)는 약 600 ~ 1,000 접속으로 불안정하게 됩니다.

MySQL 하지만 충분한 수의 파일 또는 접속을 열지 않는 경우는, 그 수의 파일을 처리하도록(듯이) Linux (을)를 설정하고 있지 않을 가능성이 있습니다.

Linux 2.2 이?~ 그럼, 이하를 실행하고, 할당할 수 있고 있는 파일 핸들의 수를 체크할 수 있습니다.

cat /proc/sys/fs/file-max
cat /proc/sys/fs/dquot-max
cat /proc/sys/fs/super-max

16 MB (을)를 넘는 메모리가 있는 경우는,init 스크립트(SuSE Linux 의 /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

root 어카운트로 커멘드 라인으로부터 상기의 커멘드를 실행할 수도 있습니다만, 다음 번에 컴퓨터가 리부트했을 때에 그러한 설정은 없어집니다.

혹은,sysctl 툴을 사용하고, 부트시에 이하의 파라미터를 설정할 수도 있습니다.이 툴은, 많은 Linux 디스트리뷰션으로 사용되고 있습니다(SuSE Linux 8.0 이?~ ,SuSE 그렇지만 이 툴이 추가되고 있습니다)./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

이것에 의해서,MySQL (은)는 최대로 8,192 의 접속 및 파일을 작성할 수 있게 됩니다.

LinuxThreads 의 STACK_SIZE 정수는, address 공간으로의 스레드스탁크의 스페이싱을 제어합니다.address 공간은, 개별의 스레드의 스택에 충분한 스페이스를 제공할 수 있는 정도로 크지 않으면 안됩니다, 몇개의 스레드의 스택이 글로벌인 mysqld 데이터 무디어져 익지 않는 정도로 작지 않으면 안됩니다.mmap() 의 Linux 실장은, 벌써 사용되고 있는 주소를 맵 아웃 하도록(듯이) 지시받으면, 에러를 돌려주지 않고 , 맵 끝난 영역을 정상적으로 맵 해제하고, 페이지 전체의 데이터를 소거하는 것이 실험으로 밝혀지고 있습니다.mysqld (이)나 그 외의 스레드아프리케이션의 안전성은, 스레드를 작성하는 코드의 " 신사적인" 동작에 걸려 있습니다.유저는, 임의의 시점에서 가동하고 있는 스레드의 수가, 스레드스탁크가 global heap로부터 떨어져 있을 수 있는 정도로 작아지도록(듯이)하기 위한 조치를 취할 필요가 있습니다.mysqld 그럼,max_connections 변수에 적절한 값을 설정해 이 " 신사적인" 동작을 강제할 필요가 있습니다.

스스로 MySQL (을)를 빌드 하는 경우,LinuxThreads 에 패치를 적용하는 작업을 하고 싶지 않으면,max_connections (을)를 500 이하의 값으로 설정해 주세요, 큰 키 버퍼나 큰 heap 테이블 등,mysqld 하지만 대량의 메모리를 할당하지 않으면 안 되는 것이 있는 경우나,2G 의 패치가 적용되었다 2.2 커넬을 실행하고 있는 경우는, 한층 더 작은 값을 설정합니다.당사의 바이너리 또는 RPM 버젼 3.23.25 이?~ (을)를 사용하고 있는 경우는, 대량의 데이터를 가지는 키 버퍼 또는 heap 테이블이 없으면,max_connections (을)를 1500 (으)로 설정해도 괜찮습니다.LinuxThreads 의 STACK_SIZE 의 값을 작게 하면 할수록, 스레드를 지장 없게 작성할 수 있게 됩니다.128K (으)로부터 256K 까지의 범위의 값을 추천 합니다.

다수의 동시 접속을 사용하는 경우,fork 폭탄 공격을 피하기 위해서, child process의 fork (이)나 복제의 프로세스에 패널티를 과한다고 하는,2.2 커넬의 " 기능" 에 골치를 썩이는 일이 있습니다.이것에 의해, 동시 실행 클라이언트의 수를 늘리면,MySQL 하지만 잘 스케일 하지 않게 됩니다.싱글 CPU 시스템에서는, 스레드 생성이 매우 늦어지는 것으로 이것이 밝혀졌습니다.이것은,MySQL 에 접속하는데 긴 시간이 걸려(1 분 정도), 접속을 절단 하는데도 같다시간이 걸리는 것을 의미합니다.멀티 CPU 시스템에서는, 클라이언트수의 증가에 수반하고, 쿼리 속도가 서서히 떨어져 가는 것이 관측되었습니다.해결법을 찾아내는 과정에서, 유저의 1 사람으로부터 커넬 패치를 받았습니다.이 유저의 사이트에서는 이 패치가 큰 효과를 올리고 있는 것이었습니다.이 패치는,http://www.mysql.com/Downloads/Patches/linux-fork.patch 그리고 입수할 수 있습니다.당사는, 개발 시스템과 실가동 시스템의 양쪽 모두로, 이 패치에 매우 광범위하게 미치는 테스트를 실행했습니다.이 패치는, 어떤 문제도 일으키는 일 없이 MySQL 의 퍼포먼스를 큰폭으로 향상시켰습니다.2.2 커넬상에서 고부하의 서버를 실행하고 있는 유저에게, 이 패치를 추천합니다.2.4 커넬에서는 이 문제는 수정되고 있습니다.따라서, 시스템의 현재의 퍼포먼스에 만족하지 않은 경우는,2.2 커넬에 패치를 적용하는 것보다도,2.4 커넬에 업그레이드 하는 것(분)이 간단합니다.2.4 커넬은, 이 공정 버그가 수정된 것 외에, 뛰어났다 SMP 부스트도 제공합니다.

2 CPU 머신으로 버젼 2.4 위의 MySQL (을)를 테스트한 결과,MySQL 의 스케이라비리티가 매우 향상하는 것을 알 수 있었습니다.1,000 클라이언트에 이를 때까지 쿼리 throughput가 저하하는 것은 실질적으로 전무로,MySQL 의 슬캘링 팩터(1 클라이언트로의 throughput에 대한 최대 throughput의 비율로서 산출된다)는 180% (이었)였습니다. 4 CPU 시스템에서도 같은 결과가 관찰되었습니다.클라이언트수가 1,000 에 이를 때까지 실질적으로 속도 저하는 없고, 슬캘링 팩터는 300% (이었)였습니다.따라서, 고부하 SMP 서버의 경우는, 현시점에서 2.4 커넬을 사용하는 것을 강하게 추천합니다.최대 퍼포먼스를 달성하려면 ,2.4 커넬상에서 가장 높은 우선 순위를 설정해 mysqld 프로세스를 실행하는 것이 불가결하다라고 하는 것이 알았습니다. 이것을 실시하려면 ,renice -20 $$ 커멘드를 mysqld_safe 에 추가합니다.4 CPU 머신상에서의 테스트에서는, 우선 순위를 높게 하면,400 클라이언트로의 throughput가 60% 증가했습니다.

또, 현재, 당사는,4-way 시스템 및 8-way 시스템으로 2.4 커넬상의 MySQL 의 퍼포먼스가 얼마나 향상할까에 대한 정보를 수집중입니다.이러한 시스템에 액세스 할 수 있어 어떠한 벤치마크를 실시했을 경우는, 결과를 <docs@mysql.com> 에 전송해 주세요.장래, 이 메뉴얼에 그러한 결과를 기재합니다.

특히 SMP 시스템상에서 현저한,MySQL 의 퍼포먼스를 크게 해치는 이제(벌써) 1 개의 문제가 있습니다.glibc-2.1 의 LinuxThreads 의 상호 배타 락(mutex )의 실장은, 단시간만 상호 배타 락을 보관 유지하는 다수의 스레드를 가지는 프로그램에 악영향을 미칩니다.짓궂은 일로,SMP 시스템에서는,MySQL (을)를 미수정의 LinuxThreads 에 링크하고 있는 경우, 많은 경우, 머신으로부터 프로세서를 떼어내면 MySQL 의 퍼포먼스가 향상합니다.당사는, 이 동작을 수정하기 위한 ,glibc 2.1.3 용무의 패치를 준비했습니다(http://www.mysql.com/Downloads/Linux/linuxthreads-2.1-patch ).

MySQL 버젼 3.23.36 (은)는,glibc-2.2.2 의 아다프티브록크를 사용합니다.이것은,glibc-2.1.3 의 패치 적용 끝난 상호 배타 락보다 한층 더 적절합니다.다만, 상황에 의해서 glibc-2.2.2 의 현재의 상호 배타 락의 코드는 오버 스핀 해, 이것에 의해서 MySQL 의 퍼포먼스는 손상되는 것에 주의해 주세요.mysqld 프로세스의 우선 순위를 가장 높은 것으로 변경하는 것으로, 이 상황이 발생할 가능성을 내릴 수 있습니다.오버 스핀 동작은, 패치로 수정할 수도 있었습니다.이 패치는,http://www.mysql.com/Downloads/Linux/linuxthreads-2.2.2.patch 그리고 입수할 수 있습니다. 이 패치는, 오버 스핀, 스레드의 최대수, 및 스탁스페이싱의 수정을 일체화한 것입니다.patch -p0 </tmp/linuxthreads-2.2.2.patch 의 linuxthreads 디렉토리에서 패치를 적용할 필요가 있습니다. glibc-2.2 의 장래의 릴리스에 어떠한 형태로 이 패치가 짜넣어지는 것이 바람직합니다.어쨌든,glibc-2.2.2 에 링크하고 있는 경우는,STACK_SIZE (와)과 PTHREAD_THREADS_MAX (을)를 수정할 필요가 있습니다.장래, 디폴트가 고부하의 MySQL 설정으로서 허용 할 수 있는 값에 수정되고, 그 결과 유저 자신의 빌드가 ./configure; make; make install 까지 줄어 드는 것이 바람직합니다.

상기의 패치를 사용해 libpthread.a 의 정적 라이브러리를 별로 빌드 해,MySQL 에 정적으로 링크하기 위해서 마셔 사용하는 것을 추천합니다.이러한 패치가 MySQL 에 있어서 안전하고,MySQL 의 퍼포먼스를 큰폭으로 향상시키는 것은 알고 있습니다만, 그 외의 어플리케이션에 대해서는 알고 있지 않습니다.그 외의 어플리케이션을 이 라이브러리의 패치 적용이 끝난 버젼에 링크하는 경우나, 패치 적용 끝난 공유 버젼을 빌드 해 시스템에 인스톨 하는 경우는,LinuxThreads 에 의존하는 그 외의 어플리케이션에 관해서는 유저 자신의 책임으로 가 주세요.

MySQL 의 인스톨시에 미지의 문제가 발생했을 경우나, 일반적인 유틸리티가 행 했을 경우는, 그것이 라이브러리 또는 컴파일러에 관련하는 것일 가능성이 높습니다.그 경우는, 당사의 바이너리를 사용하는 것으로 그러한 문제는 해결됩니다.

바이너리 디스트리뷰션의 기존의 문제의 1 개는 libc (을)를 사용하는 구버젼의 Linux 시스템(Red Hat 4.x (이)나 Slackware 등)에 관련하는 것으로, 호스트명 해결로 중대하지 않은 문제가 몇개인가 발생합니다. See 항2.6.2.1. 「Linux 의 주의 사항 (바이너리 디스트리뷰션)」 .

LinuxThreads (을)를 사용하고 있는 경우는, 최소로 3 개의 프로세스가 가동하고 있는 것이 확인됩니다.이것들은, 실제는 스레드로,1 개는 LinuxThreads 매니저용의 스레드,1 개는 접속을 처리하는 스레드,1 개는 알람과 시그널을 처리하는 스레드입니다.

주의: Linux 커넬과 LinuxThreads 라이브러리는, 디폴트에서는 1,024 의 스레드 밖에 가질 수 없습니다.따라서, 패치미적용의 시스템에서는,MySQL 에의 접속은 최대로 1,021 밖에 사용할 수 없습니다.이 제한을 회피하는 방법에 대해서는 http://www.volano.com/linuxnotes.html 페이지를 참조해 주세요.

ps 그리고 dead 상태의 mysqld demon 프로세스가 표시되었을 경우는, 통상은,MySQL 에 버그가 있는지, 망가진 테이블이 있는 것을 의미합니다. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

SIGSEGV 시그널로 mysqld 하지만 정?~ 했을 경우에 Linux 위에서 코어덤프를 취득하려면 ,--core-file 옵션을 지정해 mysqld (을)를 기동합니다.주의: ulimit -c 1000000 (을)를 mysqld_safe 에 추가하는지,--core-file-size=1000000 (을)를 지정해 mysqld_safe (을)를 기동하고, 코어 파일의 사이즈를 늘립니다. See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 .

독자적인 MySQL 클라이언트를 링크하고 있을 때, 이하의 에러가 발생했을 경우

ld.so.1: ./my: fatal: libmysqlclient.so.4:
open failed: No such file or directory

그것들을 실행할 경우에, 이하의 몇개의 방법으로 문제를 회피할 수 있습니다.

  • -Lpath 대신에, 이하의 플래그를 설정해 클라이언트를 링크한다. -Wl,r/path-libmysqlclient.so .

  • libmysqclient.so (을)를 /usr/lib 에 카피한다.

  • 클라이언트를 실행하기 전에,libmysqlclient.so 하지만 배치되어 있는 디렉토리의 패스명을 LD_RUN_PATH 환경 변수에 추가한다.

후지쯔 컴파일러 (fcc / FCC) (을)를 사용하고 있는 경우는,MySQL 의 컴파일로 몇개의 문제가 발생합니다.이것은,Linux 헤더 파일이 매우 gcc 지향이기 (위해)때문입니다.

fcc/FCC (을)를 사용하는 경우는, 이하의 configure 행이 유효합니다.

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 --prefix=/usr/local/mysql \
--enable-assembler --with-mysqld-ldflags=-all-static --disable-shared \
--with-low-memory

2.6.2.1. Linux 의 주의 사항 (바이너리 디스트리뷰션)

MySQL (은)는,Linux 버젼 2.0 이?~ (을)를 필요로 합니다.

경고: 일부의 MySQL 유저로부터Linux 커넬 2.2.14 (을)를 사용한다 MySQL 그리고 중대한 안정성의 문제가 발생했던 것이 보고되고 있습니다.이 커넬을 사용하고 있는 경우는, 커넬 2.2.19 이?~ 또는 커넬 2.4 에 업그레이드 해 주세요.멀티 CPU 머신을 사용하고 있는 경우는, 커넬 2.4 에 의해서 처리 속도가 비약적으로 향상하므로, 사용을 검토해 주세요.

바이너리 릴리스는,-static 그리고 링크됩니다.따라서, 통상은 사용하는 시스템 라이브러리의 버젼을 신경쓸 필요는 없습니다.또,LinuxThreads (을)를 인스톨 할 필요도 없습니다.-static 그리고 링크된 프로그램은, 동적으로 링크된 프로그램보다 조금 큽니다만, 속도도 조금(3 ~ 5% ) 오릅니다.다만, 정적으로 링크된 프로그램에는 유저 정의 함수(UDF )(을)를 사용할 수 없는 것이 1 개의 문제입니다.UDF (을)를 작성 또는 사용하는 경우(C 또는 C++ 의 프로그래머의 경우만)은, 동적 링크를 사용해 MySQL (을)를 스스로 컴파일 할 필요가 있습니다.

glibc2 시스템이 아니고,libc 베이스의 시스템을 사용하고 있는 경우는, 바이너리 릴리스로 호스트명 해결과 getpwnam() 에 관련하는 문제가 발생하는 것이 많습니다(이것은,glibc 하지만,-static 그리고 컴파일 되고 있는 경우에서도, 외부 라이브러리에 의존해 호스트명과 getpwent() (을)를 해결하는 것이 원인입니다).그 경우,mysql_install_db (을)를 실행했을 때에 이하의 에러 메세지가 표시됩니다.

Sorry, the host 'xxxx' could not be looked up

또는,--user 옵션을 지정해 mysqld (을)를 실행했을 때에, 이하의 에러가 표시됩니다.

getpwnam: No such file or directory

이 문제는, 이하의 몇개의 방법으로 해결할 수 있습니다.

  • MySQL 소스 디스트리뷰션(RPM 또는 tar.gz 디스트리뷰션)을 입수하고, 그것을 인스톨 한다.

  • mysql_install_db --force (을)를 실행한다.이 경우,mysql_install_db 의 resolveip 테스트는 실행되지 않습니다.이 방법의 약점은, 권한 테이블로 호스트명을 사용할 수 없기 때문에, 대신에 IP 번호를 사용하지 않으면 안 되는 것입니다(localhost 의 경우는 제외하다).--force (을)를 서포트하고 있지 않는 구버젼의 MySQL 릴리스를 사용하고 있는 경우, 에디터를 사용해 mysql_install 의 resolveip 테스트를 삭제할 필요가 있습니다.

  • --user (을)를 사용하는 대신에 su (을)를 지정해 mysqld (을)를 기동한다.

MySQL 의 Linux-Intel 바이너리와 RPM 릴리스는, 최고의 속도를 실현하도록(듯이) 콘피개 되고 있습니다.당사는, 항상, 입수 가능한 최고 속도가 안정된 컴파일러를 사용하도록(듯이) 노력하고 있습니다.

MySQL 의 Perl 서포트는,Perl 5.004_03 이?~ 의 버젼을 필요로 합니다.

일부의 Linux 2.2 버젼에서는,TCP/IP (을)를 개입시켜 mysqld 서버에 다수의 접속을 실시하면,Resource temporarily unavailable 그렇다고 하는 에러가 발생하는 일이 있습니다.

문제는,Linux 그럼,TCP/IP 소켓을 닫고 나서, 그 소켓이 실제로 시스템에 의해서 해방될 때까지 에 지연이 있는 것입니다.한정된 수의 TCP/IP 슬롯용의 스페이스 밖에 없기 때문에,TCP/IP (을)를 개입시켜 test-connect 벤치마크를 실행하고 있는 경우 등, 단시간에 너무 많은 수의 새롭다 TCP/IP 접속을 실행하면, 상기의 에러가 발생합니다.

다양한Linux 메일링 리스트에 이 문제를 몇회나 메일로 보냈습니다만, 적절한 해결법은 아직껏 얻어지고 있지 않습니다.

이 문제의 ' 수정 방법' (으)로서 유일 알려져 있는 것은, 데이터 베이스 서버와 클라이언트를 같은 머신상에서 실행하고 있는 경우에, 클라이언트로 영속적인 접속을 사용할까 소켓 파일을 사용하는 것입니다, 장래,Linux 2.4 커넬로 이 문제가 수정되는 것이 바람직합니다.

2.6.2.2. Linux x86 의 주의 사항

MySQL (은)는,libc 버젼 5.4.12 이?~ (을)를 필요로 합니다.MySQL 하지만 libc 5.4.46 (와)과 제휴해 정상적으로 동작하는 것은 알려져 있습니다.glibc 버젼 2.0.6 이?~ 도 정상적으로 기능할 것입니다.Red Hat 제의 glibc RPM 에는 몇개의 문제가 있었습니다.따라서, 문제가 발생했을 경우는, 갱신이 있는지 없는지 체크해 주세요. glibc 2.0.7-19 및 2.0.7-29 의 RPM (은)는, 정상적으로 기능하는 것이 알려져 있습니다.

Red Hat 8.0 이?~ 의 glibc 2.2.x 라이브러리를 사용하고 있는 경우는,--thread-stack=192K 옵션을 지정해 mysqld (을)를 기동해 주세요 (MySQL 4 보다 전의 버젼의 경우는 -O thread_stack=192K (을)를 사용해 주세요).이 옵션을 사용하지 않으면mysqld 하 gethostbyaddr() 그리고 정?~ 합니다.이것은, 새롭다 glibc 라이브러리가 이 콜을 위해서 128KB (을)를 넘는 스택 사이즈를 필요로 하기 (위해)때문입니다.MySQL 4.0.10 이?~ 그럼, 이 스택 사이즈가 디폴트가 되었습니다.

gcc 3.0 (을)를 사용해 MySQL (을)를 컴파일 하는 경우는, 컴파일의 전에 libstdc++v3 라이브러리를 인스톨 할 필요가 있습니다.이 라이브러리를 인스톨 하지 않으면 링크시에 __cxa_pure_virtual 심볼이 발견되지 않는다고 하는 에러가 출력됩니다.

일부의 구버젼의 Linux 디스트리뷰션에서는,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.

이 에러 메세지의 지시에 따라서,1 개의 언더 스코아 밖에 없다 _P 매크로에, 언더 스코아를 이제(벌써) 1 개추가하고 나서, 재실행합니다.

컴파일중에 몇개의 경고가 표시되는 일이 있습니다.이하에 나타낸 경고는 무시해 괜찮습니다.

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'

mysql.server (은)는,MySQL 인스톨 디렉토리아래의 share/mysql 디렉토리인가,MySQL 소스 트리의 support-files 디렉토리에 있습니다.

mysqld 하지만 기동시에 반드시 코어덤프 하는 경우는, 구버젼의 /lib/libc.a (을)를 사용하고 있는 것이 문제일 가능성이 있습니다.이 파일의 이름을 변경하고,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

2.6.2.3. Linux SPARC 의 주의 사항

일부의 실장으로,readdir_r() 하지만 망가져 있습니다.SHOW DATABASES 하지만 항상 하늘세트를 돌려준다고 하는 현상이 발생합니다.이 문제는, 설정한 후, 컴파일 하기 전에,config.h (으)로부터 HAVE_READDIR_R (을)를 삭제하는 것으로 수정할 수 있습니다.

2.6.2.4. Linux Alpha 의 주의 사항

MySQL 버젼 3.23.12 (은)는,Linux-Alpha 위에서 테스트된 최초의 MySQL 버젼입니다.Linux-Alpha 위에서 MySQL (을)를 사용할 예정의 경우는, 반드시 이 버젼이?~ 의 MySQL (을)를 사용해 주세요.

Alpha 위의MySQL (은)는, 당사의 벤치마크와 테스트스트를 사용해 테스트되었습니다만, 적정하게 동작한다고 생각됩니다.

현재, 당사는,Alpha EV6 프로세서를 탑재했다 Compaq DS20 머신상에서,SuSE Linux 7.0 for AXP , 커넬 2.4.4-SMP ,Compaq 의 C 컴파일러(V6.2-505 ), 및 Compaq 의 C++ 컴파일러(V6.3-006 ) 그리고 MySQL 바이너리 패키지를 빌드중입니다.

상기의 컴파일러는,http://www.support.compaq.com/alpha-tools/ 에 있습니다.gcc 대신에 이러한 컴파일러를 사용하는 것으로,MySQL 의 퍼포먼스가 약 9 ~ 14% 향상합니다.

주의: MySQL 버젼 3.23.52 및 4.0.2 까지는, 바이너리는 최신의 CPU 만을 대상으로 최적화되고 있었습니다(-fast 컴파일 옵션을 사용해).이것은,Alpha EV6 프로세서를 사용하고 있는 경우에게만 당사의 바이너리를 사용할 수 있는 것을 의미합니다.

그 후의 릴리스에서는, 바이너리가 확실히 모든 Alpha 프로세서상에서 동작하도록(듯이) 하는,-arch generic 플래그가 컴파일 옵션에 더해졌습니다.또, 당사에서는, 라이브러리의 문제를 회피하기 위해서 정적으로 컴파일 합니다.

CC=ccc CFLAGS="-fast -arch generic" CXX=cxx \
CXXFLAGS="-fast -arch generic -noexceptions -nortti" \
./configure --prefix=/usr/local/mysql --disable-shared \
--with-extra-charsets=complex --enable-thread-safe-client \
--with-mysqld-ldflags=-non_shared --with-client-ldflags=-non_shared

egcs (을)를 사용하는 경우는, 이하의 configure 행을 사용합니다.

CFLAGS="-O3 -fomit-frame-pointer" CXX=gcc \
CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors \
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
--disable-shared

Linux-Alpha 위에서 MySQL (을)를 실행했을 경우의 기존의 문제는 이하대로입니다.

  • gdb 4.18 그럼 MySQL 등의 스레드아프리케이션의 디버그가 정상적으로 행해지지 않는다.대신에,gdb 5.1 (을)를 다운로드해 사용한다.

  • gcc (을)를 사용하고 있는 경우에,mysqld (을)를 정적으로 링크하려고 하면, 결과의 이미지가 기동시에 코어덤프 한다.따라서,gcc (와)과 함께 --with-mysqld-ldflags=-all-static (을)를 사용 하지 않는다 같게 한다.

2.6.2.5. Linux PowerPC 의 주의 사항

MySQL (은)는, 최신의 glibc 패키지를 갖추었다 MkLinux 위에서 정상적으로 동작합니다(glibc 2.0.7 그리고 테스트가 끝난 상태).

2.6.2.6. Linux MIPS 의 주의 사항

Qube2 (Linux Mips ) 위에서 MySQL (을)를 기능시키려면 , 최신의 glibc 라이브러리가 필요합니다(glibc-2.0.7-29C2 (은)는 정상적으로 기능하는 것이 알려져 있습니다).또,egcs C++ 컴파일러(egcs-1.0.2-9 , 또는 gcc 2.95.2 이?~ )(을)를 사용할 필요도 있습니다.

2.6.2.7. Linux IA-64 의 주의 사항

Linux IA-64 위에서MySQL (을)를 컴파일 시키려면 , 이하의 compile 행을 사용합니다 (gcc-2.96 (을)를 사용).

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
"--with-comment=Official MySQL binary" --with-extra-charsets=complex

IA-64 그럼,MySQL 클라이언트 바이너리는 공유 라이브러리를 사용합니다.이것은,/usr/local/mysql 이외의 장소에 바이너리 디스트리뷰션을 인스톨 했을 경우는,libmysqlclient.so (을)를 인스톨 한 디렉토리의 패스를,/etc/ld.so.conf 파일 또는 LD_LIBRARY_PATH 환경 변수의 값에 추가할 필요가 있는 것을 의미합니다.

See 항A.3.1. 「MySQL 클라이언트 라이브러리에 링크시의 문제」 .

2.6.3. Solaris 의 주의 사항

Solaris 그럼,MySQL 디스트리뷰션을 unpack 하기 전에서도 문제가 발생하는 일이 있습니다.Solaris tar (은)는 긴 파일명을 처리할 수 없기 때문에,MySQL (을)를 unpack 할 경우에 이하와 같은 에러가 표시되는 일이 있습니다.

x mysql-3.22.12-beta/bench/Results/ATIS-mysql_odbc-NT_4.0-cmp-db2,\
informix,ms-sql,mysql,oracle,solid,sybase, 0 bytes, 0 tape blocks
tar: directory checksum error

이 경우,GNU tar (gtar )(을)를 사용하고, 디스트리뷰션을 unpack 할 필요가 있습니다Solaris 용무의 프리컴파일이 끝난 카피는,http://www.mysql.com/downloads/os-solaris.html 에 있습니다.

Sun 의 네이티브스레드는,Solaris 2.5 이?~ 에서만 기능합니다.버젼 2.4 이전의 Solaris 의 경우는,MySQL (은)는 자동적으로 MIT-pthreads (을)를 사용합니다. See 항2.3.6. 「MIT-pthreads 에 관한 주의 사항」 .

configure 시간에 이하의 에러가 출력되는 경우

checking for restartable system calls... configure: error can not run test
programs while cross compiling

이 에러는, 컴파일러에 문제가 있는 것을 의미합니다. 이 경우, 컴파일러를 새로운 버젼에 업그레이드 할 필요가 있습니다.config.cache 파일에 이하의 행을 삽입하는 것으로, 이 문제를 해결할 수 있기도 합니다.

ac_cv_sys_restartable_syscalls=${ac_cv_sys_restartable_syscalls='no'}

SPARC 위에서 Solaris (을)를 사용하고 있는 경우, 추천 되는 컴파일러는 gcc 2.95.2 또는 3.2 입니다.이러한 컴파일러는,http://gcc.gnu.org/ 에 있습니다. 주의: egcs 1.1.1 및 gcc 2.8.1 (은)는,SPARC 위에서는 적정하게 기능하지 않습니다.

gcc 2.95.2 (을)를 사용하고 있는 경우는, 이하의 configure 행을 추천 합니다.

CC=gcc CFLAGS="-O3" \
CXX=gcc CXXFLAGS="-O3 -felide-constructors -fno-exceptions -fno-rtti" \
./configure --prefix=/usr/local/mysql --with-low-memory --enable-assembler

UltraSPARC (을)를 사용하고 있는 경우는,"-mcpu=v8 -Wa,-xarch=v8plusa" (을)를 CFLAGS 및 CXXFLAGS 에 추가하는 것으로 퍼포먼스를 4% 향상할 수 있습니다.

Sun 의 Forte 5.0 이?~ 의 컴파일러를 사용하고 있는 경우는,configure (을)를 이하와 같이 실행할 수 있습니다.

CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt" \
CXX=CC CXXFLAGS="-noex -mt" \
./configure --prefix=/usr/local/mysql --enable-assembler

이하의 컴파일 플래그를 지정해 Sun 의 Forte 컴파일러를 사용하고,64 비트의 바이너리를 작성할 수 있습니다.

CC=cc CFLAGS="-Xa -fast -native -xstrconst -mt -xarch=v9" \
CXX=CC CXXFLAGS="-noex -mt -xarch=v9" ASFLAGS="-xarch=v9" \
./configure --prefix=/usr/local/mysql --enable-assembler

gcc (을)를 사용해 64 비트의 Solaris 바이너리를 작성하려면 ,CFLAGS 및 CXXFLAGS 에 -m64 (을)를 추가합니다.주의: 이것은,MySQL 4.0 이?~ 만으로 기능합니다.MySQL 3.23 에는 이것을 서포트하기 위해서 필요한 변경이 포함되어 있지 않습니다.

MySQL 벤치마크에서는,UltraSPARC 위에서 32 비트 모드로 Forte 5.0 (을)를 사용했을 경우,-mcpu 플래그를 지정해 gcc 3.2 (을)를 사용했을 경우와 비교해 속도가 4% 향상했습니다.

64 비트 바이너리를 작성했을 경우,32 비트 바이너리보다 속도가 4% 저하합니다만, 그 대신에 mysqld (은)는 보다 많은 스레드와 메모리를 처리할 수 있습니다.

fdatasync 또는 sched_yield 그리고 문제가 발생했을 경우는,configure 행에 LIBS=-lrt (을)를 추가하는 것으로 그 문제를 수정할 수 있습니다.

이하의 단락은,WorkShop 5.3 보다 전의 버젼의 컴파일러에게만 관련하는 것입니다.

configure 스크립트를 편집해 이하의 행을 변경할 필요가 있는 경우도 있습니다.

#if !defined(__STDC__) || __STDC__ != 1

이것을 다음과 같이 변경합니다.

#if !defined(__STDC__)

-Xc 옵션을 지정해 __STDC__ (을)를 유효하게 하면,Sun 의 컴파일러는 Solaris 의 pthread.h 헤더 파일로 컴파일 할 수 없습니다.이것은 Sun 의 버그입니다(컴파일러 또는 인클루드 파일이 망가져 있습니다).

mysqld (을)를 실행했을 때에, 이하와 같은 에러 메세지가 출력되었을 경우는, multi-thread 옵션(-mt )(을)를 유효하게 하고 있지 않다 Sun 의 컴파일러를 사용해 MySQL (을)를 컴파일 하려고 하고 있습니다.

libc internal error: _rmutex_unlock: rmutex not held

CFLAGS 및 CXXFLAGS 에 -mt (을)를 추가하고, 재실행해 주세요.

SFW 버젼의 gcc (Solaris 8 에 부속되어 있다)를 사용하고 있는 경우는,configure (을)를 실행하기 전에,LD_LIBRARY_PATH 환경 변수에 /opt/sfw/lib (을)를 추가할 필요가 있습니다.

sunfreeware.com (으)로부터 입수할 수 있다 gcc (을)를 사용하고 있는 경우는, 많은 문제가 발생하는 일이 있습니다.문제를 회피하기 위해서는,gcc 및 GNU binutils (을)를 실행하는 머신상에서, 그것들을 재컴파일 할 필요가 있습니다.

gcc (을)를 사용해 MySQL (을)를 컴파일 하고 있을 때 이하의 에러가 출력되었을 경우는, 그 gcc 하지만 사용하고 있다 Solaris 의 버젼용으로 콘피개 되어 있지 않은 것을 의미합니다.

shell> gcc -O3 -g -O2 -DDBUG_OFF  -o thr_alarm ...
./thr_alarm.c: In function `signal_hand':
./thr_alarm.c:556: too many arguments to function `sigwait'

이 경우에 실시해야 할 (일)것은, 최신 버젼의 gcc (을)를 입수해, 현재의 gcc 컴파일러를 사용해 그것을 컴파일 하는 것입니다.적어도 Solaris 2.5 의 경우,gcc 의 거의 모든 바이너리 버젼에 낡아서 이용에 적합하지 않는 인클루드 파일이 짜넣어지고 있어 그것들에 의해서, 스레드를 사용하는 모든 프로그램(그리고, 아마 그 외의 프로그램도)이 파괴됩니다.

Solaris (은)는, 정적 버젼의 시스템 라이브러리(libpthreads 및 libdl )(은)는 일절 제공하지 않습니다.따라서,--static (을)를 지정해 MySQL (을)를 컴파일 할 수 없습니다.이 옵션을 지정해 컴파일 하면, 이하의 에러가 표시됩니다.

ld: fatal: library -ldl: not found

또는

undefined reference to `dlopen'

또는

cannot find -lrt

너무 많은 수의 프로세스가 매우 신속히 mysqld 에 접속을 시도하면,MySQL 로그에 이하의 에러가 출력됩니다.

Error in accept: Protocol error

이 문제를 회피하기 위해서,--set-variable back_log=50 옵션을 지정해 서버를 기동해 보세요. 주의: --set-variable=name=value 구문 및 -O name=value 구문은,MySQL 4.0 이?~ 폐?~ 되었습니다.대신에,--back_log=50 (을)를 사용해 주세요. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

독자적인 MySQL 클라이언트를 링크하고 있는 경우, 그 클라이언트를 실행했을 때에, 이하의 에러가 발생하는 일이 있습니다.

ld.so.1: ./my: 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 환경 변수에 추가한다.

configure 하지만 -lz 그리고 링크할 때에 문제가 발생해,zlib (을)를 인스톨 하고 있지 않는 경우, 이하의 2 개의 선택사항이 있습니다.

  • 압축된 통신 프로토콜을 사용할 수 있도록 하는 경우는,ftp.gnu.org (으)로부터 zlib (을)를 입수해 인스톨 할 필요가 있다.

  • --with-named-z-libs=no (을)를 지정해 콘피개 한다.

gcc (을)를 사용하고 있고, 유저 정의 함수(UDF )(을)를 MySQL 에 로드할 때에 문제가 발생했을 경우는, 그 UDF (을)를 링크하는 행에 -lgcc (을)를 추가해 보세요.

MySQL (을)를 자동적으로 기동시키는 경우는,/etc/init.d 에 support-files/mysql.server (을)를 카피하고,/etc/rc3.d/S99mysql.server (이)라는 이름으로 그 디렉토리에의 기호 연결을 작성합니다.

Solaris 그럼 setuid() 어플리케이션의 코어 파일이 서포트되어 있지 않기 때문에,--user 옵션을 지정해 있는 경우,mysqld (으)로부터 코어 파일을 취득할 수 없습니다.

2.6.3.1. Solaris 2.7 및 2.8 의 주의 사항

Solaris 2.7 및 2.8 위에서는,Solaris 2.6 바이너리를 통상대로 사용할 수 있습니다.Solaris 2.6 의 대부분의 문제는,Solaris 2.7 및 2.8 의 경우에도 들어맞읍니다.

주의: MySQL 버젼 3.23.4 이?~ (은)는, 새로운 버젼의 Solaris (을)를 자동 검출할 수 있기 위해, 이하의 문제의 회피를 가능하게 합니다.

Solaris 2.7 및 2.8 의 인클루드 파일에는 몇개의 버그가 있습니다.gcc (을)를 사용하고 있는 경우에, 이하의 에러가 발생하는 일이 있습니다.

/usr/include/widec.h:42: warning: `getwc' redefined
/usr/include/wchar.h:326: warning: this is the location of the previous
definition

이 경우, 이하를 실행해 이 문제를 해결할 수 있습니다.

/usr/include/widec.h (을)를 .../lib/gcc-lib/os/gcc-version/include 에 카피하고, 이하의 행 41 (을)를 변경합니다.

#if     !defined(lint) && !defined(__lint)

이것을 다음과 같이 변경합니다.

#if     !defined(lint) && !defined(__lint) && !defined(getwc)

또는, 직접 /usr/include/widec.h (을)를 편집합니다.어느 경우도, 수정한 후,config.cache (을)를 삭제하고,configure (을)를 재실행해 주세요.

make (을)를 실행했을 때에 이하와 같은 에러가 발생했을 경우는,configure 하지만 curses.h 파일을 검출할 수 없었던 것이 원인입니다(/usr/include/widec.h 에 에러가 있을 가능성이 높습니다).

In file included from mysql.cc:50:
/usr/include/term.h:1060: syntax error before `,'
/usr/include/term.h:1081: syntax error before `;'

이 문제를 해결하려면 , 이하의 어느쪽이든을 실행합니다.

  • CFLAGS=-DHAVE_CURSES_H CXXFLAGS=-DHAVE_CURSES_H ./configure (을)를 지정해 콘피개 한다.

  • 전술과 같이 /usr/include/widec.h (을)를 편집해,configure (을)를 재실행한다.

  • config.h 파일로부터 #define HAVE_TERM 행을 삭제해,make (을)를 재실행한다.

클라이언트 프로그램을 링크하고 있을 때, 링커가 -lz (을)를 검출할 수 없다고 하는 문제가 발생했을 경우는,libz.so 파일이 /usr/local/lib 에 인스톨 되고 있는 것이 문제일 가능성이 높습니다.이 문제는, 이하의 몇개의 방법으로 해결할 수 있습니다.

  • /usr/local/lib (을)를 LD_LIBRARY_PATH 에 카피한다.

  • /lib 에 있다 libz.so 에의 링크를 추가한다.

  • Solaris 8 (을)를 사용하고 있는 경우는,Solaris 8 의 CD 디스트리뷰션에 있는 옵션의 zlib (을)를 인스톨 할 수 있다.

  • --with-named-z-libs=no 옵션을 지정하고,MySQL (을)를 콘피개 한다.

2.6.3.2. Solaris x86 의 주의 사항

x86 위의 Solaris 8 그럼,strip (을)를 사용해 디버그 심볼을 삭제하면,mysqld 하지만 코어덤프 합니다.

Solaris x86 위에서 gcc 또는 egcs (을)를 사용하고 있고, 로드안의 코어덤프로 문제가 발생했을 경우는, 이하의 configure (을)를 사용해 주세요.

CC=gcc CFLAGS="-O3 -fomit-frame-pointer -DHAVE_CURSES_H" \
CXX=gcc \
CXXFLAGS="-O3 -fomit-frame-pointer -felide-constructors -fno-exceptions \
-fno-rtti -DHAVE_CURSES_H" \
./configure --prefix=/usr/local/mysql

이것에 의해서,libstdc++ 라이브러리와 C++ 예외에 관한 문제가 회피됩니다.

이 커멘드를 사용해도 문제가 해결하지 않는 경우는, 디버그 버젼을 컴파일 하고, 트레이스 파일을 사용하는지,gdb 그리고 그 디버그 버젼을 실행합니다. See 항E.1.3. 「mysqld 의 디버그(gdb 사용)」 .

2.6.4. BSD 의 주의 사항

여기에서는, 각종의 BSD 라고 각각의 개별의 버젼에 대해 설명합니다.

2.6.4.1. FreeBSD 의 주의 사항

스레드패키지가 보다 통합되고 있으므로 FreeBSD 4.x 이?~ (을)를 추천 합니다.

가장 간단한, 따라서 가장 바람직한 인스톨 방법은,mysql-server (와)과 mysql-client 의 ports (http://www.freebsd.org/ 그리고 입수할 수 있다)를 사용하는 것입니다.

이러한 ports (을)를 사용하면 이하를 실현될 수 있습니다.

  • 사용하고 있다 FreeBSD 에 최적인 MySQL .

  • 자동 설정 및 빌드.

  • /usr/local/etc/rc.d 에 인스톨 된 기동 스크립트.

  • pkg_info -L (을)를 사용하고, 인스톨 되고 있는 파일을 확인하는 것이 가능.그 머신에 MySQL 하지만 불필요하게 되면,pkg_delete (을)를 사용해 그러한 파일을 모두 삭제하는 것이 가능.

FreeBSD 2.x 그럼 MIT-pthreads (을)를, 버젼 3 이?~ 그럼 네이티브스레드를, 각각 사용하는 것을 추천합니다.일부의 후기 2.2 x 버젼에서는, 네이티브스레드를 사용해 실행할 수 있습니다만,mysqld (을)를 슛다운 할 때에 문제가 발생하는 일이 있습니다.

FreeBSD 위의 일부의 함수 호출은, 아직 완전하게는 스레드세이후가 아닙니다.가장 현저한 것은,MySQL 하지만 호스트명을 IP 주소로 변환하기 위해서 사용한다 gethostbyname() 함수입니다.특정의 상황하로,mysqld 프로세스는, 돌연,CPU 부하 100% 상태를 일으키고, 응답 불능이 됩니다.이 상태가 발생하면,--skip-name-resolve 옵션을 사용해 MySQL (을)를 기동해 보세요.

혹은,FreeBSD 4.x 위에서 MySQL (을)를 LinuxThreads 라이브러리에 링크합니다.이것에 의해서, 네이티브의 FreeBSD 스레드 실장이 가진다 2 ,3 의 문제가 회피됩니다.LinuxThreads (와)과 네이티브스레드의 매우 뛰어난 비교에 대해서는,"FreeBSD or Linux for your MySQL Server?" 그렇다고 한다 Jeremy Zawodny 의 기사(http://jeremy.zawodny.com/blog/archives/000697.html )(을)를 참조해 주세요.

FreeBSD 그리고 LinuxThreads (을)를 사용했을 경우의 기존의 문제는 이하대로입니다.

  • wait_timeout (은)는 기능하고 있지 않다(FreeBSD/LinuxThreads 의 시그널 처리의 문제일 가능성이 있다).이 문제는,FreeBSD 5.0 그리고 수정될 예정이 되고 있다. 영속적인 접속이 클로우즈 되지 않고 장시간 행 한다고 하는 현상이 발생한다.

MySQL Makefile (을)를 사용하려면 ,GNU make (gmake )(이)가 기능하고 있을 필요가 있습니다.MySQL (을)를 컴파일 하는 경우는, 최초로 GNU make (을)를 인스톨 할 필요가 있습니다.

네임 리절버의 설정에 잘못이 없게 해 주세요.설정에 잘못이 있으면,mysqld 에 접속할 경우에 리절버가 지연 또는 실패하는 일이 있습니다.

/etc/hosts 파일의 localhost 엔트리가 정확한 것을 확인해 주세요.정확하지 않으면 데이타베이스에 접속할 때에 문제가 발생합니다./etc/hosts 파일은, 이하의 행으로 시작되지 않으면 안됩니다.

127.0.0.1       localhost localhost.your.domain

gcc (2.95.2 이?~ )(을)를 사용해 FreeBSD 위에서 MySQL 의 컴파일과 인스톨을 실시하는 경우는, 이하와 같이 실시하는 것을 추천합니다.

CC=gcc CFLAGS="-O2 -fno-strength-reduce" \
CXX=gcc CXXFLAGS="-O2 -fno-rtti -fno-exceptions -felide-constructors \
-fno-strength-reduce" \
./configure --prefix=/usr/local/mysql --enable-assembler
gmake
gmake install
./scripts/mysql_install_db
cd /usr/local/mysql
./bin/mysqld_safe &

configure 하지만 MIT-pthreads (을)를 사용하는 것을 알 수 있었을 경우는,MIT-pthreads 의 주의 사항을 읽어 주세요. See 항2.3.6. 「MIT-pthreads 에 관한 주의 사항」 .

make install 하지만 /usr/include/pthreads (을)를 검출할 수 없다고 하는 에러를 출력했을 경우는,configure 하지만 MIT-pthreads 하지만 필요한 일을 검출하지 않았던 것을 의미합니다.이 에러는, 이하의 커멘드를 실행해 수정합니다.

shell> rm config.cache
shell> ./configure --with-mit-threads

FreeBSD (은)는, 디폴트의 파일 핸들의 상한이 매우 낮게 설정되어 있는 일도 알려져 있습니다.See 항A.2.17. 「File Not Found 에러」 . mysqld_safe 의 ulimit -n 섹션의 코멘트를 해제하는지,/etc/login.conf 그리고 mysqld 유저에 대한 상한을 늘려 cap_mkdb /etc/login.conf 그리고 재빌드 합니다. 또, 디폴트의 값을 사용하지 않는 경우는, 반드시 이 유저에게 적절한 클래스를 설정해 주세요(chpass mysqld-user-name 하지만 사용할 수 있다). See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 .

메모리에 여유가 있는 경우는,MySQL 하지만 512 MB (을)를 넘는다 RAM (을)를 취득할 수 있도록 커넬을 재빌드 하는 것을 검토해 주세요. 상세 정보가 필요한 경우는,LINT 설정 파일의 option MAXDSIZ (을)를 조사해 주세요.

MySQL 의 현재의 일자에 관한 문제가 발생했을 경우는,TZ 변수를 설정하는 것으로 아마 해결합니다. See 부록 F. 환경 변수 .

안전하고 안정된 시스템으로 하려면 ,-RELEASE (와)과 지정되었다 FreeBSD 커넬만을 사용해 주세요.

2.6.4.2. NetBSD 의 주의 사항

NetBSD 위에서 컴파일 하려면 ,GNU make 하지만 필요합니다.GNU make 하지만 없으면make 하지만 C++ 파일로 lint (을)를 실행했을 때에 크래쉬 합니다.

2.6.4.3. OpenBSD 2.5 의 주의 사항

OpenBSD 버젼 2.5 그럼, 네이티브스레드를 사용해 이하의 옵션을 지정해 MySQL (을)를 컴파일 할 수 있습니다.

CFLAGS=-pthread CXXFLAGS=-pthread ./configure --with-mit-threads=no

2.6.4.4. OpenBSD 2.8 의 주의 사항

OpenBSD 2.8 에는 MySQL 그리고 문제를 발생시키는 스레드의 버그가 있는 것이 유저로부터 보고되고 있습니다.OpenBSD 개발자는 이 문제를 수정했습니다만,2001 년 1 월 25 일 현재에 ``-current'' 브랜치로 밖에 이용할 수 없습니다. 이 스레드의 버그에 의해서 발생하는 현상으로서 슬로우 리스폰스, 고부하, 고 CPU 사용율, 크래쉬가 있습니다.

테이블이나 디렉토리를 열려고 했을 때에,Error in accept:: Bad file descriptor 그렇다고 하는 에러 또는 에러 9 하지만 발생했을 경우, 문제는 MySQL 에 충분한 파일 디스크립터를 할당하지 않은 것이라고 생각할 수 있습니다.

이 경우, 이하의 옵션을 지정하고,root (으)로서 mysqld_safe (을)를 기동해 보세요.

shell> mysqld_safe --user=mysql --open-files-limit=2048 &

2.6.4.5. BSD/OS 버젼 2.x 의 주의 사항

MySQL (을)를 컴파일 하고 있을 때 이하의 에러가 발생했을 경우는,ulimit 값이 너무 낮습니다.

item_func.h: In method `Item_func_ge::Item_func_ge(const Item_func_ge &)':
item_func.h:28: virtual memory exhausted
make[2]: *** [item_func.o] Error 1

ulimit -v 80000 (을)를 사용해 make (을)를 재실행해 보세요.이 방법으로 효과가 없고,sh (을)를 사용하고 있는 경우는,csh 또는 sh (을)를 바꾸어 보세요.bash (와)과 ulimit 에 관한 문제가 BSDI 유저로부터 보고되고 있습니다.

gcc (을)를 사용하고 있는 경우는,sql_yacc.cc 의 컴파일을 가능하게 하기 위해서 configure 에 --with-low-memory 플래그를 사용할 필요도 있을지도 모릅니다.

MySQL 의 현재의 일자에 관한 문제가 발생했을 경우는,TZ 변수를 설정하는 것으로 해결한다고 생각할 수 있습니다. See 부록 F. 환경 변수 .

2.6.4.6. BSD/OS 버젼 3.x 의 주의 사항

BSD/OS 버젼 3.1 에 업그레이드 해 주세요.그것이 불가능한 경우는,BSDI patch M300-038 (을)를 인스톨 해 주세요.

MySQL (을)를 콘피개 할 때는 이하와 같이 합니다.

shell> env CXX=shlicc++ CC=shlicc2 \
       ./configure \
           --prefix=/usr/local/mysql \
           --localstatedir=/var/mysql \
           --without-perl \
           --with-unix-socket-path=/var/mysql/mysql.sock

이하의 라인도 유효하다라고 하는 것이 알려져 있습니다.

shell> env CC=gcc CXX=gcc CXXFLAGS=-O3 \
       ./configure \
           --prefix=/usr/local/mysql \
           --with-unix-socket-path=/var/mysql/mysql.sock

필요에 따라서 디렉토리의 장소를 변경해도 괜찮습니다.또, 어느 장소도 지정하지 않고 디폴트를 사용할 수도 있습니다.

고부하의 상황으로 퍼포먼스에 문제가 있는 경우는,mysqld 에 --skip-thread-priority 옵션을 사용해 보세요.이것에 의해서, 모든 스레드가 같은 우선 순위로 실행됩니다.BSDI 버젼 3.1 그럼, 이것에 의해서 퍼포먼스가 향상합니다(적어도 BSDI 하지만 스레드스케쥬라를 수정할 때까지).

컴파일중에 virtual memory exhausted 그렇다고 하는 에러가 발생했을 경우는,ulimit -v 80000 (을)를 사용해 make (을)를 재실행해 보세요. 이 방법으로 효과가 없고,sh (을)를 사용하고 있는 경우는,csh 또는 sh (을)를 바꾸어 보세요.bash (와)과 ulimit 에 관한 문제가 BSDI 유저로부터 보고되고 있습니다.

2.6.4.7. BSD/OS 버젼 4.x 의 주의 사항

BSDI 버젼 4.x 에는 스레드 관련의 버그가 몇개인가 있습니다.BSDI 버젼 4.x 위에서 MySQL (을)를 사용하는 경우는, 모든 스레드 관련의 패치를 인스톨 해 주세요.적어도 M400-023 (은)는 인스톨 할 필요가 있습니다.

BSDI 버젼 4.x 시스템에서는, 공유 라이브러리에 관한 문제가 발생하는 일이 있습니다. mysqladmin 등의 클라이언트 프로그램을 실행할 수 없다고 하는 현상이 발생합니다.이 경우,configure 에 --disable-shared 옵션을 지정하고, 공유 라이브러리를 사용하지 않게 재콘피개 할 필요가 있습니다.

mysqld 바이너리가 당분간 경과하면 테이블을 열지 않게 된다고 하는 문제가 BSDI 4.0.1 위에서 발생했던 적이 있습니다.이것은, 라이브러리 또는 시스템 관련의 어떠한 버그에 의해서, 유저가 요구하고 있지 않는데 mysqld 하지만 커런트 디렉토리를 변경했기 때문입니다.

이 문제는,3.23.34 이?~ 에 업그레이드 하는지,configure (을)를 실행한 후,make (을)를 실행하기 전에 config.h (으)로부터 #define HAVE_REALPATH 행을 삭제하는 것으로 해결합니다.

주의: 이것은,BSDI 위에서, 데이타베이스 디렉토리를 다른 데이타베이스 디렉토리에 기호 연결 하는 일도, 테이블을 다른 데이타베이스에 기호 연결 하는 것도 할 수 없는 것을 의미합니다(다른 디스크에의 기호 연결을 작성할 수 있습니다).

2.6.5. Mac OS X 의 주의 사항

2.6.5.1. Mac OS X 10.x

MySQL 하 Mac OS X 10.x (Darwin ) 위에서 문제 없게 기능합니다.이 OS 용무의 pthread 패치는 필요 없습니다.

이것은,Mac OS X 10.x Server 에도 들어맞읍니다.서버 플랫폼용의 컴파일은, 클라이언트 버젼의 Mac OS X 의 경우와 같습니다.다만,MySQL (은)는, 서버 에 프리 인스톨 되고 있는 것에 주의해 주세요.

당사의 Mac OS X 용바이너리는, 이하의 configure 행으로 Darwin 6.3 위에서 컴파일 됩니다.

CC=gcc CFLAGS="-O3 -fno-omit-frame-pointer" CXX=gcc \
CXXFLAGS="-O3 -fno-omit-frame-pointer -felide-constructors \
-fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
--with-extra-charsets=complex --enable-thread-safe-client \
--enable-local-infile --disable-shared

See 항2.1.3. 「Mac OS X 에의 MySQL 의 인스톨」 .

2.6.5.2. Mac OS X Server 1.2 (Rhapsody )

MySQL on Mac OS X Server 1.2 (별명 Rhapsody ) 위에서MySQL (을)를 콘피개 하기 전에, 우선,http://www.prnet.de/RegEx/mysql.html 에 있다 pthread 패키지를 인스톨 할 필요가 있습니다.

See 항2.1.3. 「Mac OS X 에의 MySQL 의 인스톨」 .

2.6.6. 그 외의 Unix 의 주의 사항

2.6.6.1. 바이너리 디스트리뷰션의 경우의 HP-UX 의 주의 사항

HP-UX 용 MySQL 의 바이너리 디스트리뷰션의 몇개인가는,HP 의 depot 파일 및 tar 파일로서 배포됩니다.depot 파일을 사용하려면 ,HP-UX 10.x 이?~ (을)를 실행하고 있고,HP's software depot tools 에 액세스 할 수 없으면 안됩니다.

HP 버젼의 MySQL (은)는,HP-UX 10.20 (을)를 실행한다 HP 9000/8xx 서버상에서 컴파일 되어MIT-pthreads (을)를 사용합니다.이 구성으로 MySQL 하지만 적절히 동작하는 것이 알려져 있습니다.MySQL 버젼 3.22.26 이?~ (은)는,HP 의 네이티브스레드패키지를 사용해 빌드 할 수도 있습니다.

그 외의 유효한 구성

  • HP-UX 10.20 이?~ (을)를 실행하고 있다 HP 9000/7xx

  • HP-UX 10.30 이?~ (을)를 실행하고 있다 HP 9000/8xx

이하의 구성에서는, 거의 확실히 정상적으로 기능하지 않습니다.

  • HP-UX 10.x (10.2 보다 전)을 실행한다 HP 9000/7xx 또는 8xx

  • HP-UX 9.x (을)를 실행한다 HP 9000/7xx 또는 8xx

디스트리뷰션을 인스톨 하려면 , 이하의 몇개의 커멘드를 사용합니다.이 경우,/path/to/depot 하 depot 파일의 완전 패스명입니다.

  • 서버, 클라이언트, 개발툴 등, 모든 것을 인스톨 하는 경우

    shell> /usr/sbin/swinstall -s /path/to/depot mysql.full

  • 서버만을 인스톨 하는 경우

    shell> /usr/sbin/swinstall -s /path/to/depot mysql.server

  • 클라이언트 패키지만을 인스톨 하는 경우

    shell> /usr/sbin/swinstall -s /path/to/depot mysql.client

  • 개발툴만을 인스톨 하는 경우

    shell> /usr/sbin/swinstall -s /path/to/depot mysql.developer

depot (은)는, 바이너리와 라이브러리를 /opt/mysql 에 배치해, 데이터를 /var/opt/mysql 에 배치합니다.또, 부트시에 서버를 자동적으로 기동하기 위한 적절한 엔트리를 /etc/init.d (와)과 /etc/rc2.d 에 작성하는 당연합니다만, 인스톨 하려면 root 일 필요가 있습니다.

HP-UX tar.gz 디스트리뷰션을 인스톨 하려면 ,GNU 의 tar 하지만 없으면 안됩니다.

2.6.6.2. HP-UX 버젼 10.20 의 주의 사항

HP-UX 위에서 MySQL (을)를 컴파일 하고 있을 때, 작은 문제가 몇개인가 발생합니다.HP-UX 의 네이티브 컴파일러 대신에 gcc (을)를 사용하는 것을 추천합니다.이것은,gcc (분)편이 뛰어난 코드를 생성하기 (위해)때문입니다.

HP-UX 그럼 gcc 2.95 (을)를 사용하는 것을 추천합니다.높은 레벨의 최적화 플래그(-O6 등) (은)는,HP-UX 위에서는 안전하지 않을 가능성이 있으므로 사용하지 말아 주세요.

gcc 2.95 (을)를 사용하는 경우는, 이하의 configure 행이 유효합니다.

CFLAGS="-I/opt/dce/include -fpic" \
CXXFLAGS="-I/opt/dce/include -felide-constructors -fno-exceptions \
-fno-rtti" CXX=gcc ./configure --with-pthread \
--with-named-thread-libs='-ldce' --prefix=/usr/local/mysql --disable-shared

gcc 3.1 (을)를 사용하는 경우는, 이하의 configure 행이 유효합니다.

CFLAGS="-DHPUX -I/opt/dce/include -O3 -fPIC" CXX=gcc \
CXXFLAGS="-DHPUX -I/opt/dce/include -felide-constructors -fno-exceptions \
-fno-rtti -O3 -fPIC" ./configure --prefix=/usr/local/mysql \
--with-extra-charsets=complex --enable-thread-safe-client \
--enable-local-infile  --with-pthread \
--with-named-thread-libs=-ldce --with-lib-ccflags=-fPIC
--disable-shared

2.6.6.3. HP-UX 버젼 11.x 의 주의 사항

HP-UX 버젼 11.x 의 경우는,MySQL 버젼 3.23.15 이?~ (을)를 추천 합니다.

표준의 HP-UX 라이브러리에는 몇개의 중대한 버그가 있기 위해,HP-UX 11.0 위에서 MySQL (을)를 실행하기 전에 이하의 패치를 인스톨 할 필요가 있습니다.

PHKL_22840 Streams cumulative
PHNE_22397 ARPA cumulative

이것에 의해서, 스레드아프리케이션으로,recv() (으)로부터 EWOULDBLOCK (을)를,accept() (으)로부터 EBADF (을)를 받는다고 하는 문제가 해결됩니다.

패치미적용의 HP-UX 11.x 시스템상에서 gcc 2.95.1 (을)를 사용하고 있는 경우, 이하의 에러가 발생합니다.

In file included from /usr/include/unistd.h:11,
                 from ../include/global.h:125,
                 from mysql_priv.h:15,
                 from item.cc:19:
/usr/include/sys/unistd.h:184: declaration of C function ...
/usr/include/sys/pthread.h:440: previous declaration ...
In file included from item.h:306,
                 from mysql_priv.h:158,
                 from item.cc:19:

문제는,HP-UX 의 pthreads_atfork() 의 정의에 정합성이 없는 것입니다. /usr/include/sys/unistd.h:184 (와)과 /usr/include/sys/pthread.h:440 에, 모순된 프로토 타입이 있습니다(자세한 것은 이하로 말합니다).

1 개의 해결법은,/usr/include/sys/unistd.h (을)를 mysql/include 에 카피하고,unistd.h (을)를 편집하고,pthread.h 안의 정의와 일치하도록(듯이) 변경하는 것입니다.이하에 diff (을)를 나타냅니다.

183,184c183,184
<      extern int pthread_atfork(void (*prepare)(), void (*parent)(),
<                                                void (*child)());
---
>      extern int pthread_atfork(void (*prepare)(void), void (*parent)(void),
>                                                void (*child)(void));

이 다음은, 이하의 configure 행이 기능합니다.

CFLAGS="-fomit-frame-pointer -O3 -fpic" CXX=gcc \
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti -O3" \
./configure --prefix=/usr/local/mysql --disable-shared

HP-UX 컴파일러와 함께 MySQL 4.0.5 (을)를 사용하고 있는 경우는, 이하를 사용할 수 있습니다 (cc B.11.11.04 그리고 테스트가 끝난 상태).

CC=cc CXX=aCC CFLAGS=+DD64 CXXFLAGS=+DD64 ./configure --with-extra-character-set=complex

이하와 같은 에러는 무시해 괜찮습니다.

aCC: warning 901: unknown option: `-3': use +help for online documentation

configure 시간에 이하의 에러가 출력되는 경우

checking for cc option to accept ANSI C... no
configure: error: MySQL requires a ANSI C compiler (and a C++ compiler).
Try gcc. See the Installation chapter in the Reference Manual.

HP-UX 의 C 및 C++ 컴파일러에의 패스 전에 K&R 컴파일러에의 패스가 없는 것을 확인합니다.

컴파일 성과인 이제(벌써) 1 개의 이유는, 위에서 +DD64 플래그를 정의하고 있지 않는 것입니다.

HP-UX 11 마시자 1 개의 가능성은,HP-UX 10.20 용무의 MySQL 바이너리를 사용하는 것입니다. 이러한 바이너리가 HP-UX 11.00 그리고 정상적으로 기능하는 것이 유저로부터 보고되고 있습니다.문제가 발생했을 경우는, 반드시 HP-UX 의 패치의 레벨을 체크해 주세요.

2.6.6.4. IBM-AIX 의 주의 사항

xlC 의 자동 검출이 Autoconf 매운 구 되어 있기 때문에,MySQL (을)를 컴파일 할 경우에는 이하와 같은 configure 의 지정이 필요합니다(이 예에서는,IBM 컴파일러를 사용하고 있습니다).

export CC="xlc_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192 "
export CXX="xlC_r -ma -O3 -qstrict -qoptimize=3 -qmaxmem=8192"
export CFLAGS="-I /usr/local/include"
export LDFLAGS="-L /usr/local/lib"
export CPPFLAGS=$CFLAGS
export CXXFLAGS=$CFLAGS

./configure --prefix=/usr/local \
                --localstatedir=/var/mysql \
                --sysconfdir=/etc/mysql \
                --sbindir='/usr/local/bin' \
                --libexecdir='/usr/local/bin' \
                --enable-thread-safe-client \
                --enable-large-files

상기는,MySQL 디스트리뷰션을 컴파일 할 때에 사용되는 옵션으로,http://www-frec.bull.com/ 에 있습니다.

상기의 configure 행으로 -O3 (을)를 -O2 (으)로 변경했을 경우는,-qstrict 옵션도 삭제할 필요가 있습니다(이것은,IBM C 컴파일러의 제한입니다).

gcc 또는 egcs (을)를 사용해 MySQL (을)를 컴파일 하는 경우는,-fno-exceptions 플래그를 사용한다 필요가 있습니다 .gcc 및 egcs 의 예외 처리가 스레드세이후가 아니기 때문입니다(이것은,egcs 1.1 (을)를 사용해 테스트되고 있습니다).IBM 어셈블러에도 좋게 개인가의 기존의 문제가 있습니다.이러한 문제를 위해서, 이 어셈블러를 gcc (와)과 함께 사용했을 경우에, 불량 코드가 생성되는 일이 있습니다.

AIX 위에서는,egcs 및 gcc 2.95 (와)과 함께 이하의 configure 행을 사용하는 것을 추천합니다.

CC="gcc -pipe -mcpu=power -Wa,-many" \
CXX="gcc -pipe -mcpu=power -Wa,-many" \
CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti" \
./configure --prefix=/usr/local/mysql --with-low-memory

-Wa,-many (은)는, 컴파일을 성공시키기 위해서 필요합니다.IBM (은)는, 이 문제를 인식하고 있습니다만, 회피 방법이 있기 위해 수정을 서두르고 있지 않습니다.gcc 2.95 에 -fno-exceptions 하지만 필요할지는 모릅니다만,MySQL (은)는 예외를 사용하지 않는 데다가, 이 옵션에 의해서 코드가 고속화하므로,egcs 및 gcc 에는 항상 이 옵션을 사용하는 것을 추천합니다.

어셈블러 코드로 문제가 발생하는 경우는, 사용하고 있다 CPU (와)과 일치하도록(듯이) -mcpu=xxx (을)를 변경해 보세요.통상은,power2 ,power , 또는 powerpc (을)를 지정할 필요가 있겠지요.혹은,604 또는 604e (을)를 지정할 필요가 있을지도 모릅니다.확증은 없습니다만, 대부분의 경우 "power" (을)를 지정해도 문제 없습니다(power2 머신상에서 만나도 같이).

CPU 하지만 무엇으로 있을지 모르는 경우는,"uname -m" (을)를 실행해 주세요.xxyyyyyymmss 의 형식을 가지는,"000514676700" (와)과 같은 문자열이 돌려주어집니다.이 경우,xx (와)과 ss (은)는 항상 0 ,yyyyyy (은)는 일의의 시스템 ID ,mm 하 CPU planar의 ID 입니다.http://publib.boulder.ibm.com/doc_link/en_US/a_doc_lib/cmds/aixcmds5/uname.htm 에 이러한 값의 겉(표)가 있습니다. 이것에 의해서 머신의 종류와 형태를 알 수 있습니다.이 머신의 종류와 형태로, 사용하고 있다 CPU 의 종류를 특정할 수 있습니다.

시그널에 관한 문제가 발생했을 경우 (고부하의 상황으로 MySQL 하지만 돌연정?~ 한다), 스레드와 시그널에 관한 OS 의 버그를 찾아낸 가능성이 있습니다.이 경우, 이하의 커멘드를 사용해 콘피개 하는 것으로, 시그널을 사용하지 않게 MySQL 에 지시할 수 있습니다.

shell> CFLAGS=-DDONT_USE_THR_ALARM CXX=gcc \
       CXXFLAGS="-felide-constructors -fno-exceptions -fno-rtti \
       -DDONT_USE_THR_ALARM" \
       ./configure --prefix=/usr/local/mysql --with-debug --with-low-memory

이것은,MySQL 의 퍼포먼스에는 영향을 주지 않습니다만, 접속상에서 " sleeve 상태" 의 클라이언트를,mysqladmin kill 또는 mysqladmin shutdown (을)를 사용해 강제 종료할 수 없게 된다고 하는 부작용이 있습니다.대신에, 클라이언트는 자신이 다음 번 커멘드를 발행했을 때에 정?~ 합니다.

AIX 의 일부의 버젼에서는,libbind.a (와)과 링크하면 getservbyname 하지만 코어덤프 합니다.이것은 AIX 의 버그이므로,IBM 에 보고할 필요가 있습니다.

AIX 4.2.1 (와)과 gcc (을)를 사용하는 경우, 이하의 변경을 실시할 필요가 있습니다.

설정의 뒤에,config.h (와)과 include/my_config.h (을)를 편집하고, 이하의 행을 변경합니다.

#define HAVE_SNPRINTF 1

이것을 이하와 같이 변경합니다.

#undef HAVE_SNPRINTF

마지막으로,mysqld.cc 의 initgoups 에 프로토 타입을 추가할 필요가 있습니다.

#ifdef _AIX41
extern "C" int initgroups(const char *,int);
#endif

mysqld 프로세스에 대량의 메모리를 할당할 필요가 있는 경우는,'ulimit -d unlimited' (을)를 설정하는 것 만으로는 충분하지는 않습니다.경우에 의해서,mysqld_safe 그리고 이하와 같이 설정할 필요도 있습니다.

export LDR_CNTRL='MAXDATA=0x80000000'

이하의 사이트에, 대량의 메모리의 사용에 대한 상세 정보가 있습니다. http://publib16.boulder.ibm.com/pseries/en_US/aixprggd/genprogc/lrg_prg_support.htm .

2.6.6.5. SunOS 4 의 주의 사항

SunOS 4 그럼,MySQL (을)를 컴파일 하기 위해서 MIT-pthreads 하지만 필요합니다.이것은,GNU make 하지만 필요한 것을 의미합니다.

일부의 SunOS 4 시스템은, 동적 라이브러리와 libtool 에 문제가 있습니다. 이하의 configure 행을 실행하면, 이 문제를 회피할 수 있습니다.

shell> ./configure --disable-shared --with-mysqld-ldflags=-all-static

readline (을)를 컴파일 하고 있을 때, 중복 정의에 관한 경고가 표시되는 일이 있습니다. 이러한 경고는 무시해 괜찮습니다.

mysqld (을)를 컴파일 하고 있을 때,implicit declaration of function 그렇다고 하는 경고가 표시됩니다.이러한 경고는 무시해 괜찮습니다.

2.6.6.6. Alpha-DEC-UNIX (Tru64 )의 주의 사항

Digital Unix 위에서 egcs 1.1.2 (을)를 사용하고 있는 경우는,gcc 2.95.2 에 업그레이드 해 주세요.이것은,DEC 위의 egcs 에 몇개의 중대한 버그가 있기 때문에입니다.

Digital Unix 위에서 스레드프로그람을 컴파일 하는 경우, 메뉴얼에서는,cc 및 cxx 의 -pthread 옵션과 라이브러리 -lmach -lexc (-lpthread 외에)를 사용하는 것이 추천 되고 있습니다.이하와 같은 configure (을)를 실행해 주세요.

CC="cc -pthread" CXX="cxx -pthread -O" \
./configure --with-named-thread-libs="-lpthread -lmach -lexc -lc"

mysqld (을)를 컴파일 하고 있을 때, 이하와 같은 몇개의 경고가 표시되는 일이 있습니다.

mysqld.cc: In function void handle_connections()':
mysqld.cc:626: passing long unsigned int *' as argument 3 of
accept(int,sockadddr *, int *)'

이러한 경고는 무시해도 괜찮습니다.이러한 경고는,configure 하지만 검출할 수 있는 것은 에러만으로, 경고는 검출할 수 없기 위해(때문에) 발생합니다.

직접 커멘드 라인으로부터 서버를 기동했을 경우에, 로그아웃 하면 서버가 정?~ 그러자(면) 하는 문제가 발생하는 일이 있습니다(로그아웃 하면, 아직 끝나지 않은 프로세스는 SIGHUP 시그널을 수신합니다).그 경우는, 이하와 같이 서버를 기동합니다.

shell> nohup mysqld [options] &

nohup (은)는, 그 뒤로 지정된 커멘드에, 단말로부터 송신되었다 SIGHUP 시그널을 무시시킵니다.혹은,mysqld_safe (을)를 실행해 서버를 기동합니다.mysqld_safe (은)는,nohup (을)를 사용해 mysqld (을)를 기동합니다. See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 .

mysys/get_opt.c (을)를 컴파일 하고 있을 때 문제가 발생했을 경우는, 파일의 선두로부터 #define _NO_PROTO 그렇다고 하는 행을 삭제해 주세요.

Compaq 의 CC 컴파일러를 사용하고 있는 경우는, 이하의 configure 행이 유효합니다.

CC="cc -pthread"
CFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host"
CXX="cxx -pthread"
CXXFLAGS="-O4 -ansi_alias -ansi_args -fast -inline speed all -arch host \
-noexceptions -nortti"
export CC CFLAGS CXX CXXFLAGS
./configure \
--prefix=/usr/local/mysql \
--with-low-memory \
--enable-large-files \
--enable-shared=yes \
--with-named-thread-libs="-lpthread -lmach -lexc -lc"
gnumake

상기와 같이 공유 라이브러리를 유효하게 해 컴파일 하고 있을 때,mysql 의 링크중에 libtool 그리고 문제가 발생했을 경우는, 이하의 커멘드를 발행해 그 문제를 회피할 수 있습니다.

cd mysql
/bin/sh ../libtool --mode=link cxx -pthread  -O3 -DDBUG_OFF \
-O4 -ansi_alias -ansi_args -fast -inline speed \
-speculate all \ -arch host  -DUNDEF_HAVE_GETHOSTBYNAME_R \
-o mysql  mysql.o readline.o sql_string.o completion_hash.o \
../readline/libreadline.a -lcurses \
../libmysql/.libs/libmysqlclient.so  -lm
cd ..
gnumake
gnumake install
scripts/mysql_install_db

2.6.6.7. Alpha-DEC-OSF/1 의 주의 사항

DEC 의 CC 및 gcc 하지만 인스톨 되고 있는 경우, 컴파일로 문제가 발생하면, 이하와 같은 configure (을)를 실행해 보세요.

CC=cc CFLAGS=-O CXX=gcc CXXFLAGS=-O3 \
./configure --prefix=/usr/local/mysql

c_asm.h 파일로 문제가 발생했을 경우는, 이하의 커멘드로 ' 다?~ -' 의 c_asm.h 파일을 작성해 사용해 주세요.

touch include/c_asm.h
CC=gcc CFLAGS=-I./include \
CXX=gcc CXXFLAGS=-O3 \
./configure --prefix=/usr/local/mysql

주의: ld 프로그램에 관한 이하의 문제는, 최신의 DEC (Compaq ) 패치 킷을 이하의 사이트로부터 다운로드해 수정할 수 있습니다. http://ftp.support.compaq.com/public/unix/ .

OSF/1 V4.0D 및 컴파일러 "DEC C V5.6-071 on Digital Unix V4.0 (Rev. 878)" 그럼, 컴파일러에 몇개의 미지의 동작이 있습니다(미정도리의 asm 심볼). /bin/ld 도 망가져 있는 것처럼 생각됩니다(mysqld 의 링크중에 _exit undefined 에러가 발생하는 문제).이 시스템에서는,/bin/ld (을)를 OSF 4.0C 의 버젼에 옮겨놓은 후, 이하의 configure 행을 사용해 MySQL (을)를 컴파일 할 수 있었습니다.

CC=gcc CXX=gcc CXXFLAGS=-O3 ./configure --prefix=/usr/local/mysql

Digital 컴파일러 "C++ V6.1-029" (을)를 사용하는 경우는, 이하의 지정이 유효합니다.

CC=cc -pthread
CFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \
       -arch host
CXX=cxx -pthread
CXXFLAGS=-O4 -ansi_alias -ansi_args -fast -inline speed -speculate all \
          -arch host -noexceptions -nortti
export CC CFLAGS CXX CXXFLAGS
./configure --prefix=/usr/mysql/mysql --with-mysqld-ldflags=-all-static \
            --disable-shared --with-named-thread-libs="-lmach -lexc -lc"

OSF/1 의 일부의 버젼에서는,alloca() 함수가 망가져 있습니다.config.h 의 'HAVE_ALLOCA' (을)를 정의하는 행을 삭제하고, 이 문제를 해결합니다.

alloca() 함수도 /usr/include/alloca.h 에 올바르지 않은 프로토 타입을 가지는 일이 있습니다.그 결과 표시되는 경고는 무시해 괜찮습니다.

configure (은)는, 이하의 스레드라이브라리를 자동적으로 사용합니다. --with-named-thread-libs="-lpthread -lmach -lexc -lc" .

gcc (을)를 사용하고 있는 경우는, 이하와 같이 configure (을)를 실행해 보세요.

shell> CFLAGS=-D_PTHREAD_USE_D4 CXX=gcc CXXFLAGS=-O3 ./configure ...

시그널에 관한 문제가 발생했을 경우 (고부하의 상황으로 MySQL 하지만 돌연정?~ 한다), 스레드와 시그널에 관한 OS 의 버그를 찾아낸 가능성이 있습니다.이 경우, 이하의 커멘드를 사용해 설정하는 것으로, 시그널을 사용하지 않게 MySQL 에 지시할 수 있습니다.

shell> CFLAGS=-DDONT_USE_THR_ALARM \
       CXXFLAGS=-DDONT_USE_THR_ALARM \
       ./configure ...

이것은,MySQL 의 퍼포먼스에는 영향을 주지 않습니다만, 접속상에서 " sleeve 상태" 의 클라이언트를,mysqladmin kill 또는 mysqladmin shutdown (을)를 사용해 강제 종료할 수 없게 된다고 하는 부작용이 있습니다.대신에, 클라이언트는 자신이 다음 번 커멘드를 발행했을 때에 정?~ 합니다.

gcc 2.95.2 (을)를 사용하고 있는 경우, 이하의 compile error가 발생할 가능성이 높습니다.

sql_acl.cc:1456: Internal compiler error in `scan_region', at except.c:2566
Please submit a full bug report.

이것을 수정하려면 ,sql 디렉토리로 이동하고, 말미의 gcc 행을 `` 컷 앤드 페이스트'' 합니다만,-O3 하 -O0 (으)로 변경합니다(또는, 컴파일행에 -O 옵션이 없는 경우는,-O0 (을)를 gcc 의 직후에 추가합니다).이 처리가 끝나면, 최상위의 디렉토리로 돌아오고,make (을)를 재실행합니다.

2.6.6.8. SGI Irix 의 주의 사항

Irix Version 6.5.3 이?~ (을)를 사용하고 있는 경우,CAP_SCHED_MGT 특권을 가지는 유저(root 등)으로서 mysqld (을)를 실행했을 경우인가, 이하의 쉘 커멘드를 사용해 mysqld 서버에 이 특권을 주었을 경우에게만,mysqld (은)는 스레드를 작성할 수 있습니다.

shell> chcap "CAP_SCHED_MGT+epi" /opt/mysql/libexec/mysqld

경우에 의해서,configure (을)를 실행한 후, 컴파일 하기 전에 config.h 그리고 몇개의 심볼을 재정의할 필요가 있습니다.

Irix 의 일부의 버젼에서는,alloca() 함수가 망가져 있습니다.SELECT 스테이트먼트로 mysqld 서버가 정?~ 하는 경우는,config.h (으)로부터 HAVE_ALLOC (와)과 HAVE_ALLOCA_H (을)를 정의하고 있는 행을 삭제해 주세요. mysqladmin create 하지만 기능하지 않는 경우는,config.h (으)로부터 HAVE_READDIR_R (을)를 정의하고 있는 행을 삭제합니다.경우에 의해서,HAVE_TERM_H 행도 삭제할 필요가 있습니다.

SGI 그럼, 이하의 페이지에 있는 모든 패치를 정리해 인스톨 하는 것을 추천 하고 있습니다. http://support.sgi.com/surfzone/patches/patchset/6.2_indigo.rps.html

적어도, 최신의 커넬 롤업, 최신의 rld 롤업, 및 최신의 libc 롤업만은 인스톨 해 주세요.

pthread 의 서포트를 위해서, 이하의 페이지에 있는 모든 POSIX 패치가 필요합니다.

http://support.sgi.com/surfzone/patches/patchset/6.2_posix.rps.html

mysql.cc (을)를 컴파일 하고 있을 때, 이하와 같은 에러가 발생하는 일이 있습니다.

"/usr/include/curses.h", line 82: error(1084): invalid combination of type

MySQL 소스 트리의 최상위의 디렉토리에서, 이하를 입력합니다.

shell> extra/replace bool curses_bool < /usr/include/curses.h \
> include/curses.h
shell> make

스케줄링에 관한 문제도 보고되고 있습니다.1 개의 스레드만이 가동하고 있는 경우, 퍼포먼스가 낮아집니다.다른 클라이언트를 기동하고, 이 문제를 회피해 주세요.이것에 의해서, 이제(벌써) 1 분의 스레드의 실행 속도가 2 ~ 10 배가 되는 일이 있습니다.이것은,Irix 스레드에 관한 불명점이 많은 문제입니다.이 문제를 수정할 수 있을 때까지 임시적인 해결법을 찾아내지 않으면 안됩니다.

gcc (을)를 사용해 컴파일 하고 있는 경우는, 이하의 configure 커멘드를 사용할 수 있습니다.

CC=gcc CXX=gcc CXXFLAGS=-O3 \
./configure --prefix=/usr/local/mysql --enable-thread-safe-client \
--with-named-thread-libs=-lpthread

Irix 6.5.11 위에서 네이티브의 Irix C 컴파일러 및 C++ 컴파일러의 버젼 7.3.1.2 (을)를 사용하고 있는 경우, 이하가 유효하다라고 하는 것이 보고되고 있습니다.

CC=cc CXX=CC CFLAGS='-O3 -n32 -TARG:platform=IP22 -I/usr/local/include \
-L/usr/local/lib' CXXFLAGS='-O3 -n32 -TARG:platform=IP22 \
-I/usr/local/include -L/usr/local/lib' ./configure \
--prefix=/usr/local/mysql --with-innodb --with-berkeley-db \
--with-libwrap=/usr/local \
--with-named-curses-libs=/usr/local/lib/libncurses.a

2.6.6.9. SCO 의 주의 사항

현행의 이식판은,``sco3.2v5.0.5'' ,``sco3.2v5.0.6'' , 및 ``sco3.2v5.0.7'' 의 시스템상에서만 테스트되고 있습니다.``sco 3.2v4.2'' 에의 이식판에서도 큰 진전이 있었습니다.

현시점에서,OpenServer 위에서 추천 되는 컴파일러는 gcc 2.95.2 입니다.이 컴파일러를 사용하면, 이하의 커멘드만으로 MySQL (을)를 컴파일 할 수 있습니다.

CC=gcc CXX=gcc ./configure ... (options)

  1. OpenServer 5.0.x 의 경우는,Skunkware 의 gcc-2.95.2p1 이?~ (을)를 사용할 필요가 있다.gcc-2.95.2p1 (을)를 입수하려면 ,http://www.sco.com/skunkware/ 그리고 브라우저판의 OpenServer 패키지를 선택하는지,ftp 사이트 ftp2.caldera.com 의pub/skunkware/osr5/devtools/gcc 디렉토리에 ftp 접속한다.

  2. 이 제품과 개발 시스템을 위한 GCC 2.5.x 의 이식이 필요하다.이것들은, 이 버젼의 SCO Unix 위에 존재할 필요가 있다.GCC Dev 시스템만을 사용할 수 없다.

  3. 최초로,FSU Pthreads 패키지를 입수하고, 그것을 인스톨 할 필요가 있다. FSU Pthreads 패키지는,http://moss.csc.ncsu.edu/~mueller/ftp/pub/PART/pthreads.tar.gz 에 있다. 또,http://www.mysql.com/Downloads/SCO/FSU-threads-3.5c.tar.gz (으)로부터 프리컴파일 된 패키지를 입수할 수도 있다.

  4. FSU Pthreads (은)는,SCO Unix 4.2 그리고 tcpip (을)를 사용해 컴파일 할 수 있다.혹은,GCC 2.5.x ODT 또는 OS 3.0 의 적정한 이식판을 사용해 SCO Development System 하지만 인스톨 된,OpenServer 3.0 또는 Open Desktop 3.0 (OS 3.0 ODT 3.0 )에서는,GCC 2.5.x 의 적정한 이식판이 필요하다.적정한 이식판을 사용하지 않으면 많은 문제가 발생한다.이 제품의 이식에는,SCO Unix Development system 하지만 필요하다.이것이 없으면 필요한 라이브러리와 링커가 부족하다.

  5. FSU Pthreads (을)를 시스템에 빌드 하려면 , 이하의 순서로 실시한다.

    1. threads/src 디렉토리에서 ./configure (을)를 실행해,SCO OpenServer 옵션을 선택한다.이 커멘드에 의해서,Makefile.SCO5 하지만 Makefile 에 카피된다.

    2. make (을)를 실행한다.

    3. 디폴트의 /usr/include 디렉토리에 인스톨 하려면 ,root (으)로서 로그인하고,thread/src 디렉토리로 이동해(cd ),make install (을)를 실행한다.

  6. MySQL (을)를 컴파일 할 때는, 반드시 GNU make (을)를 사용한다.

  7. root (으)로서 mysqld_safe (을)를 기동하지 않으면 아마 프로세스 정답 110 개(디폴트)의 오픈 파일 밖에 취득하지 않는다.mysqld (은)는, 이것에 관한 주기를 로그 파일에 쓴다.

  8. SCO 3.2V5.0.5 그럼,FSU Pthreads 버젼 3.5c 이?~ (을)를 사용할 필요가 있다. 또,gcc 2.95.2 이?~ (을)를 사용할 필요도 있다.

    이하의 configure 커멘드가 유효하다.

    shell> ./configure --prefix=/usr/local/mysql --disable-shared

  9. SCO 3.2V4.2 그럼,FSU Pthreads 버젼 3.5c 이?~ (을)를 사용할 필요가 있다. 이하의 configure 커멘드가 유효하다.

    shell> CFLAGS="-D_XOPEN_XPG4" CXX=gcc CXXFLAGS="-D_XOPEN_XPG4" \
       ./configure \
           --prefix=/usr/local/mysql \
           --with-named-thread-libs="-lgthreads -lsocket -lgen -lgthreads" \
           --with-named-curses-libs="-lcurses"

    인클루드 파일에 관한 문제가 발생하는 일이 있다.이 경우,http://www.mysql.com/Downloads/SCO/SCO-3.2v4.2-includes.tar.gz 그리고, 새롭다 SCO 고유의 인클루드 파일을 찾아낸다. MySQL 소스 트리의 include 디렉토리에 이 파일을 unpack 한다.

SCO development 의 주의 사항

  • MySQL (은)는, 자동적으로 FSU Pthreads (을)를 검출하고,-lgthreads -lsocket -lgthreads (을)를 사용해 mysqld (을)를 링크한다.

  • SCO development 라이브러리는,FSU Pthreads 에 재입 가능하다. SCO (은)는, 자사의 라이브러리의 함수는 재입 가능한가들 ,FSU Pthreads 그렇지만 재입 가능하다는 두라고 공언하고 있다.OpenServer 위의 FSU Pthreads (은)는,SCO 스킴을 사용해 재입 가능한 라이브러리를 작성한다.

  • FSU Pthreads (http://www.mysql.com/ 에 있는 버젼이?~ )(은)는,GNU malloc 그리고 링크된 상태로 제공된다.메모리 사용율에 관한 문제가 발생했을 경우는,libgthreads.a (와)과 libgthreads.so 에 gmalloc.o 하지만 인클루드 되고 있는 것을 확인한다.

  •               FSU Pthreads
그리고,pthread

대응의 시스템 콜은,read()
,write()
,getmsg()
,connect()
,accept()
,select()
, 및
              wait()
이다.

  • CSSA-2001-SCO.35.2 (이 패치는 erg711905-dscr_remap 시큐러티 패치(버젼 2.0.0 )(으)로서 「custom 」에 리스트 되고 있다)는 FSU 스레드를 파괴해,mysqld (을)를 불안정하게 한다.OpenServer 5.0.6 머신상에서 mysqld (을)를 실행하는 경우는, 이 패치를 삭제할 필요가 있다.

  • SCO (은)는,ftp://ftp.sco.com/pub/openserver5 (OpenServer 5.0.x 용무)로 operating system 패치를 제공하고 있다.

  • SCO (은)는, 시큐러티 수정 프로그램과 libsocket.so.2 (을)를 ftp://ftp.sco.com/pub/security/OpenServer 및 ftp://ftp.sco.com/pub/security/sse (OpenServer 5.0.x 용무)로 제공하고 있다.

  • OSR506 보다 전의 버젼의 시큐러티 수정 프로그램.또,OSR506 보다 전의 버젼의 시스템에의 인스톨에 관한 설명이 포함되었다 libsocket.so.2 (와)과 libresolv.so.1 의 양쪽 모두로서ftp://stage.caldera.com/pub/security/openserver/ 또는 ftp://stage.caldera.com/pub/security/openserver/CSSA-2001-SCO.10/ 에 있다 telnetd 수정 프로그램.

    MySQL 의 컴파일이나 사용을 시도하기 전에, 상기의 패치를 인스톨 하는 것을 추천한다.

SCO 에 DBI (을)를 인스톨 하는 경우는,DBI-xxx (와)과 각 서브 디렉토리에 포함되어 있다 Makefile (을)를 편집할 필요가 있습니다.

주의: 이하는,gcc 2.95.2 이?~ (을)를 상정한 것입니다.

변경전:
변경 후:
CC = cc                               CC = gcc
CCCDLFLAGS = -KPIC -W1,-Bexport       CCCDLFLAGS = -fpic
CCDLFLAGS = -wl,-Bexport              CCDLFLAGS =

LD = ld                               LD = gcc -G -fpic
LDDLFLAGS = -G -L/usr/local/lib       LDDLFLAGS = -L/usr/local/lib
LDFLAGS = -belf -L/usr/local/lib      LDFLAGS = -L/usr/local/lib

LD = ld                               LD = gcc -G -fpic
OPTIMISE = -Od                        OPTIMISE = -O1

변경전:
CCCFLAGS = -belf -dy -w0 -U M_XENIX -DPERL_SCO5 -I/usr/local/include

변경 후:
CCFLAGS = -U M_XENIX -DPERL_SCO5 -I/usr/local/include

icc 또는 cc 그리고 컴파일 되었다 DBI 모듈을 Perl dynaloader 하지만 로드하지 않기 때문에, 이와 같이 처리할 필요가 있습니다.

Perl (은)는,cc 그리고 컴파일 되면 가장 자주(잘) 기능합니다.

2.6.6.10. SCO UnixWare 버젼 7.1.x 의 주의 사항

MySQL 의 버젼 3.22.13 이?~ 의 MySQL 의 버젼과 UnixWare 7.1.0 의 버젼을 사용할 필요가 있습니다.이것은, 이러한 버젼으로 UnixWare 위의 이식성과 OS 에 관한 문제가 몇개인가 수정되고 있기 (위해)때문입니다.

UnixWare 버젼 7.1.x 위에서 이하의 configure 커멘드를 사용해 MySQL (을)를 컴파일 할 수 있었습니다.

CC=cc CXX=CC ./configure --prefix=/usr/local/mysql

gcc (을)를 사용하는 경우는,gcc 2.95.2 이?~ (을)를 인스톨 할 필요가 있습니다.

CC=gcc CXX=g++ ./configure --prefix=/usr/local/mysql

  1. SCO (은)는,ftp://ftp.sco.com/pub/unixware7 (UnixWare 7.1.1 및 7.1.3 )(와)과 ftp://ftp.sco.com/pub/openunix8 (OpenUNIX 8.0.0 )(으)로, operating system 패치를 제공하고 있다.

  2. SCO (은)는,ftp://ftp.sco.com/pub/security/OpenUNIX (OpenUNIX ) 및 ftp://ftp.sco.com/pub/security/sse (UnixWare )(으)로, 시큐러티 수정 프로그램에 대한 정보를 제공하고 있다.

2.6.7. OS/2 의 주의 사항

MySQL (은)는, 다수의 오픈 파일을 사용합니다.그 때문에,CONFIG.SYS 파일에 이하와 같은 기술을 추가할 필요가 있습니다.

SET EMXOPT=-c -n -h1024

이 처리를 실시하지 않으면 아마 이하의 에러가 발생합니다.

File 'xxxx' not found (Errcode: 24)

OS/2 Warp 3 그리고 MySQL (을)를 사용하는 경우는,FixPack 29 이?~ 하지만 필요합니다.OS/2 Warp 4 그리고 MySQL (을)를 사용하는 경우는,FixPack 4 이?~ 하지만 필요합니다.이것은,Pthreads 라이브러리의 요건입니다.MySQL (은)는,HPFS ,FAT32 등, 긴 파일명을 서포트하는 파티션에 인스톨 할 필요가 있습니다.

INSTALL.CMD 스크립트는,OS/2 의 CMD.EXE (으)로부터 실행하지 않으면 안되어,4OS2.EXE 등의 치환 쉘에서는 기능하지 않는 것이 있습니다.

scripts/mysql-install-db 스크립트는, 이름이 변경되었습니다.현재,install.cmd (으)로 불리고 있는 이 스크립트는,REXX 스크립트로, 디폴트의 MySQL 시큐러티 설정을 셋업 해,MySQL 용무의 워크프레이스시르아이콘을 작성합니다.

동적 모듈 서포트는, 컴파일은 되고 있습니다만, 완전하게는 테스트되고 있지 않습니다.동적 모듈은,Pthreads 런 타임 라이브러리를 사용해 컴파일 할 필요가 있습니다.

gcc -Zdll -Zmt -Zcrtdll=pthrdrtl -I../include -I../regex -I.. \
    -o example udf_example.cc -L../lib -lmysqlclient udf_example.def
mv example.dll example.udf

주의:OS/2 (으)로의 제한을 위해서,UDF 모듈명의 어간 줄기는 8 문자를 넘을 수 없습니다.모듈은,/mysql2/udf 디렉토리에 격납됩니다.safe-mysqld.cmd 스크립트는 이 디렉토리를 BEGINLIBPATH 환경 변수로 설정합니다.UDF 모듈을 사용하고 있는 경우, 지정한 확장자(extension)는 무시됩니다.확장자(extension)는 .udf (와)과 가정됩니다. 예를 들어,Unix 그럼, 공유 모듈이 example.so (이)라는 이름의 경우, 이하와 같은 커멘드로 거기로부터 함수를 로드합니다.

mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example.so";

OS/2 그럼, 모듈이 example.udf (이)라는 이름에서 만나도, 유저는 모듈 확장자(extension)를 지정하지 않습니다.

mysql> CREATE FUNCTION metaphon RETURNS STRING SONAME "example";

2.6.8. Novell NetWare 의 주의 사항

NetWare 에의 MySQL 의 이식은,Novell 주도로 행해진 작업입니다.Novell 의 유저는,NetWare 6.5 (을)를 실행하는 모든 서버에 대한 자동적인 상용 라이센스를 갖추었다 MySQL 바이너리가,NetWare 6.5 에 번들 되는 것을 환영할 것입니다.

See 항2.1.4. 「NetWare 에의 MySQL 의 인스톨」 .

NetWare 용무의 MySQL (은)는,Metrowerks CodeWarrior for NetWare (와)과 특별한 크로스 컴파일 버젼의 GNU autotool 의 편성을 사용해 컴파일 되고 있습니다.향후,NetWare 용무의 MySQL (을)를 빌드와 최적화에 관한 상세 정보가 필요하게 되면, 이 섹션을 한번 더 참조해 주세요.

2.6.9. BeOS 의 주의 사항

당사는, 과거에 MySQL (을)를 BeOS 에 80% 이식한다고 말한다 BeOS 의 개발자와 이야기했던 적이 있습니다만, 그 후 연락은 없습니다.


2.7. Perl 인스톨에 대한 코멘트

2.7.1. Unix 에의 Perl 의 인스톨

MySQL (은)는,DBI/DBD 클라이언트 인터페이스라고 하는 형태로 Perl (을)를 서포트합니다.See 항11.5. 「MySQL Perl API 」 . Perl DBD/DBI 클라이언트 코드는,Perl 버젼 5.004 이?~ (을)를 필요로 합니다.이것보다 전의 버젼의 Perl (을)를 사용하고 있는 경우는, 이 인터페이스는 정상적으로 기능하지 않습니다 .

MySQL 의 Perl 모듈의 작성에는,MySQL 클라이언트의 개발 환경( 헤더 파일이나 libmysqlclient 라이브러리) (을)를 인스톨 하는 것이 필요합니다. RPM 파일로부터 MySQL (을)를 인스톨 했을 경우는, 개발 환경은 MySQL-devel RPM 에 포함되어 있습니다.MySQL-devel 패키지를 인스톨 하고 있는 것을 확인해 주세요.

버젼 3.22.8 이?~ ,Perl 의 모듈은 메인의MySQL 디스트리뷰션과는 별도로 배포되고 있습니다.Perl 모듈을 인스톨 하는 경우는,http://www.mysql.com/downloads/api-dbi.html (으)로부터 필요한 파일을 입수할 수 있습니다.

Perl 모듈의 디스트리뷰션은,tar 형식의 압축 어카이브(archive)로서 제공되어MODULE-VERSION.tar.gz 등의 이름이 붙어 있습니다.이 경우,MODULE (은)는 모듈명으로,VERSION (은)는 버젼 번호입니다.Data-Dumper ,DBI ,DBD-mysql 의 각 디스트리뷰션을 입수하고, 이 차례로 그것들을 인스톨 할 필요가 있습니다.인스톨 순서에 대해서는, 이하를 참조해 주세요. 여기에서는,Data-Dumper 모듈의 경우의 예로 설명합니다만,3 개의 디스트리뷰션 모두로 순서는 같습니다.

  1. 디스트리뷰션을 커런트 디렉토리에 unpack 한다.

    shell> gunzip < Data-Dumper-VERSION.tar.gz | tar xvf -

    이 커멘드에 의해서,Data-Dumper-VERSION (이)라는 이름의 디렉토리가 작성된다.

  2. unpack 한 디스트리뷰션의 최상위디렉토리로 이동한다.

    shell> cd Data-Dumper-VERSION

  3. 디스트리뷰션을 빌드 하고, 모든 것을 컴파일 한다.

    shell> perl Makefile.PL
shell> make
shell> make test
shell> make install

make test 커멘드는, 모듈이 정상적으로 기능하는 것을 확인하므로 중요합니다.주의: DBD-mysql 의 인스톨시에 이 커멘드를 실행해 인터페이스 코드를 실행하는 경우는,MySQL 서버가 가동하고 있지 않으면 안됩니다.가동하고 있지 않으면 테스트는 실패합니다.

새로운 릴리스의 MySQL (을)를 인스톨 할 때는 항상,DBD-mysql 디스트리뷰션의 재빌드와 재인스톨을 실시하는 것을 추천합니다.MySQL (을)를 업그레이드 한 후에 모든 DBI 스크립트가 실패한다라고 하는 현상을 깨달았을 경우는, 특히 추천 합니다.

시스템 디렉토리에 Perl 모듈을 인스톨 하는 권한이 없는 경우나, 로컬의 Perl 모듈을 인스톨 하는 경우는, 이하를 참조해 주세요.

http://servers.digitaldaze.com/extensions/perl/modules.html#modules

Installing New Modules that Require Locally Installed Modules 그렇다고 하는 표제아래를 조사해 주세요.

2.7.2. Windows 에의 ActiveState Perl 의 인스톨

Windows 그럼, 이하를 실행하고,ActiveState Perl 하지만 짜넣어졌다 MySQL DBD 모듈을 인스톨 할 필요가 있습니다.

  • http://www.activestate.com/Products/ActivePerl/ (으)로부터 ActiveState Perl (을)를 입수해 인스톨 한다.

  • 콘솔 윈도우(``DOS 윈도우'' )(을)를 연다.

  • 필요에 따라서,HTTP_proxy 변수를 설정한다.예를 들어, 이하의 커멘드를 사용한다.

    set HTTP_proxy=my.proxy.com:3128

  • PPM(Perl Package Module) 프로그램을 기동한다.

    C:\> c:\perl\bin\ppm.pl

  • DBI (을)를 아직 인스톨 하고 있지 않는 경우는, 여기서 인스톨 한다.

    ppm> install DBI

  • 상기의 커멘드가 성공하면, 이하의 커멘드를 실행한다.

    install \
ftp://ftp.de.uu.net/pub/CPAN/authors/id/JWIED/DBD-mysql-1.2212.x86.ppd

상기의 커멘드는, 적어도 ActiveState Perl 버젼 5.6 의 경우는 유효합니다.

이 커멘드가 정상적으로 기능하지 않는 경우는, 대신에 MyODBC 드라이버를 인스톨 하고,ODBC (을)를 통해서 MySQL 서버에 접속해 주세요.

use DBI;
$dbh= DBI->connect("DBI:ODBC:$dsn",$user,$password) ||
  die "Got error $DBI::errstr when connecting to $dsn\n";

2.7.3. Perl DBI/DBD 인터페이스 사용시의 문제

../mysql/mysql.so 모듈을 검출할 수 없다고 하는 메세지가 Perl (으)로부터 출력되었을 경우는,Perl 하지만 공유 라이브러리 libmysqlclient.so (을)를 찾아낼 수 없었던 것을 의미합니다.

이 문제는, 이하의 몇개의 방법으로 해결할 수 있습니다.

  • perl Makefile.PL (은)는 아니고 perl Makefile.PL -static -config (을)를 사용하고,DBD-mysql (을)를 컴파일 한다.

  • 다른 공유 라이브러리가 배치되어 있는 디렉토리(아마,/usr/lib 또는/lib )에 libmysqlclient.so (을)를 카피한다.

  • Linux 그럼,libmysqlclient.so 하지만 배치되어 있는 디렉토리의 패스명을 /etc/ld.so.conf 파일에 추가할 수 있다.

  • libmysqlclient.so 하지만 배치되어 있는 디렉토리의 패스명을 LD_RUN_PATH 환경 변수에 추가한다.

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 클라이언트를 컴파일 할 경우에,make (으)로부터의 mysql.so 에 관한 출력을 체크해 주세요).-L 옵션에 의해서, 시스템내의 libgcc.a 하지만 배치되어 있는 디렉토리의 패스명이 지정됩니다.

이 문제의 이제(벌써) 1 개의 원인은,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 (을)를 실행하고, 최초부터 인스톨을 실시합니다.

동적 링크(SCO 등)을 서포트하고 있지 않는 시스템상에서 Perl 모듈을 사용하는 경우는,DBI (와)과 DBD-mysql 하지만 짜넣어진 정적 버젼의 Perl (을)를 작성합니다.이것이 잘 되는 방법은,DBI 코드가 링크되었다 Perl 의 버젼을 작성하고, 현재의 Perl 의 위에 인스톨 하는 것입니다.다음에, 그것을 사용하고,DBD 코드가 추가로 링크되었다 Perl 의 버젼을 빌드 하고, 인스톨 합니다.

SCO 그럼, 이하의 환경 변수가 설정되어 있을 필요가 있습니다.

shell> LD_LIBRARY_PATH=/lib:/usr/lib:/usr/local/lib:/usr/progressive/lib
or
shell> LD_LIBRARY_PATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\
/usr/progressive/lib:/usr/skunk/lib
shell> LIBPATH=/usr/lib:/lib:/usr/local/lib:/usr/ccs/lib:\
/usr/progressive/lib:/usr/skunk/lib
shell> MANPATH=scohelp:/usr/man:/usr/local1/man:/usr/local/man:\
/usr/skunk/man:

최초로,DBI 디스트리뷰션이 배치되어 있는 디렉토리에서 이하의 커멘드를 실행하고, 정적으로 링크되었다 DBI 모듈이 짜넣어졌다 Perl (을)를 작성합니다.

shell> perl Makefile.PL -static -config
shell> make
shell> make install
shell> make perl

그 후, 작성했다 Perl (을)를 인스톨 할 필요가 있습니다.make perl 의 출력에, 인스톨을 실시하기 위해서 실행할 필요가 있는 정확한 make 커멘드가 나타납니다.SCO 의 경우는,make -f Makefile.aperl inst_perl MAP_TARGET=perl 입니다.

다음에, 지금 작성했다 Perl (을)를 사용하고,DBD-mysql 디스트리뷰션이 배치되어 있는 디렉토리에서 이하의 커멘드를 실행하고, 역시 정적으로 링크되었다 DBD::mysql 모듈이 짜넣어졌다 Perl (을)를 이제(벌써) 1 개작성합니다.

shell> perl Makefile.PL -static -config
shell> make
shell> make install
shell> make perl

마지막으로, 이 새롭다 Perl (을)를 인스톨 할 필요가 있습니다.여기에서도,make perl 의 출력에, 사용하는 커멘드가 나타납니다.


제3 장 MySQL 튜토리얼

목차

3.1. 서버에의 접속 및 서버로부터의 절단
3.2. 쿼리의 입력
3.3. 데이타베이스의 작성 및 사용
3.3.1. 데이타베이스의 작성 및 선택
3.3.2. 테이블의 작성
3.3.3. 테이블에의 데이터의 로드
3.3.4. 테이블에서의 정보의 취득
3.4. 데이타베이스 및 테이블에 관한 정보의 취득
3.5. 배치 모드로의 mysql 의 사용
3.6. 일반적인 쿼리의 예
3.6.1. 컬럼의 최대치
3.6.2. 특정의 컬럼의 최대치가 격납되고 있는 레코드
3.6.3. 그룹마다의 컬럼의 최대치
3.6.4. 특정의 필드의 그룹마다의 최대치가 격납되고 있는 레코드
3.6.5. 유저 변수의 사용
3.6.6. 외부 키의 사용
3.6.7. 2 개의 키를 사용한 검색
3.6.8. 매일의 방문수의 계산
3.6.9. AUTO_INCREMENT 의 사용
3.7. 쌍생아 연구 프로젝트의 쿼리
3.7.1. 미방문의 모든 쌍생아의 검색
3.7.2. 쌍생아의 조의 스테이터스를 정리한 표의 작성
3.8. Apache (으)로의 MySQL 의 사용

이 장은,mysql 클라이언트 프로그램을 사용해 간단한 데이타베이스를 작성해, 사용하는 방법에 대해 설명한다 MySQL 튜토리얼입니다. mysql (`` 타?~ 널 모니터'' 또는 단지 `` 모니터'' (이)라고도 불린다)는,MySQL 서버에의 접속, 쿼리의 실행, 및 결과의 표시의 각 기능을 가지는 대화식 프로그램입니다.mysql (은)는, 배치 모드에서도 사용할 수 있습니다.쿼리를 기술한 파일을 미리 작성해 두어, 그 파일의 내용을 실행하도록(듯이) mysql 에 지시합니다.이 장에서는,mysql 남을 수 있는들 2 개의 사용 방법에 대해 설명합니다.

--help 옵션을 지정해 mysql (을)를 호출하면, 그 옵션의 일람이 표시됩니다.

shell> mysql --help

이 장에서는, 머신에 mysql 하지만 인스톨 되고 있는 것, 및 MySQL 서버에 접속할 수 있는 환경에 있는 것을 전제로 하고 있습니다.일전에제가 성립하지 않는 경우는,MySQL 관리자에게 문의해 주세요. 자신 하지만 MySQL 관리자인 경우, 이 메뉴얼의 다른 섹션을 참조할 필요가 있습니다.

이 장에서는, 데이타베이스를 설정해 사용할 때까지의 과정에 대해서, 최초부터 끝까지 설명합니다.기존의 데이타베이스에 접속하는 방법으로 관심이 있는 경우는, 데이타베이스 및 거기에 포함되는 테이블의 작성 방법에 대해 설명하고 있는 섹션은 날려도 괜찮습니다.

이 장은 기본적으로 튜토리얼로서 기술되고 있으므로, 상세한 설명의 상당수는 생략 되고 있습니다.이 장으로 설명하고 있는 내용의 상세한 것에 대하여는, 이 메뉴얼의 관련 섹션을 참조해 주세요.

3.1. 서버에의 접속 및 서버로부터의 절단

서버에 접속하려면 , 통상 mysql (을)를 호출할 때에 MySQL 유저명 및, 대부분의 경우, 패스워드를 입력할 필요가 있습니다.로그인하는 머신과 서버가 동작하고 있는 머신이 다른 경우는, 호스트명도 입력할 필요가 있습니다.접속할 때에 필요한 접속 파라미터(사용하는 호스트명, 유저명, 및 패스워드)에 대해서는, 관리자에게 문의해 주세요.올바른 접속 파라미터를 알 수 있으면, 이하와 같이 그것들을 지정하는 것으로, 서버에 접속할 수 있습니다.

shell> mysql -h host -u user -p
Enter password: ********

******** (은)는 패스워드를 나타냅니다.패스워드는,mysql 하지만 Enter password: prompt를 표시하고 나서 입력합니다.

패스워드가 올바르면,mysql> prompt의 뒤에 이하와 같은 welcome message가 표시됩니다.

shell> mysql -h host -u user -p
Enter password: ********
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 25338 to server version: 4.0.14-log

Type 'help;' or '\h' for help. Type '\c' to clear the buffer.

mysql>

prompt는,mysql 하지만 유저로부터의 커멘드 입력을 받아들일 수 있는 상태인 것을 나타냅니다.

MySQL 의 인스톨 방법에 따라서는, 로컬 호스트상에서 동작하는 서버에 익명 유저(이름이 없는 유저)로서 접속할 수 있습니다.사용하고 있는 머신에 그러한 방법으로 MySQL 하지만 인스톨 되고 있는 경우, 이하와 같이 아무것도 옵션을 지정하지 말아줘 mysql (을)를 호출해도,MySQL 서버에 접속할 수 있습니다.

shell> mysql

서버에 정상적으로 접속한 다음은,mysql> prompt로 QUIT (또는 \q ) (이)라고 입력하는 것으로, 언제라도 서버로부터 절단 할 수 있습니다.

mysql> QUIT
Bye

Unix 위에서는,Ctrl-D 키를 눌러 서버로부터 절단 할 수도 있습니다.

이하의 섹션에 나타내는 예의 대부분은, 서버에 접속한 상태인 것을 전제로 하고 있습니다.mysql> prompt가 표시되고 있는 경우는, 서버에 접속하고 있는 것을 나타냅니다.


3.2. 쿼리의 입력

전의 섹션으로 설명한 것처럼, 서버에 접속하고 있는 것을 확인합니다.서버에 접속하고 있는 것을 확인하는 것 만으로는 사용하는 데이타베이스의 선택은 행해지지 않습니다만, 여기에서는 그래서 충분합니다.지금의 시점에서는, 테이블의 작성, 테이블에의 데이터 로드, 및 테이블에서의 데이터 취득을 실행하는 방법보다, 쿼리를 발행하는 방법을 배우는 것이 중요합니다.이 섹션에서는,mysql 하지만 동작하는 메카니즘에 익숙하기 위한 다양한 쿼리를 사용하면서, 커멘드 입력의 기본적인 원칙에 대해 설명합니다.

이하의 커멘드는, 서버에 그 버젼 번호와 현재의 일자를 조회하는 간단한 커멘드입니다.mysql> prompt의 뒤에 이하대로 입력해,Enter (을)를 눌러 주세요.

mysql> SELECT VERSION(), CURRENT_DATE;
+--------------+--------------+
| VERSION()    | CURRENT_DATE |
+--------------+--------------+
| 3.22.20a-log | 1999-03-19   |
+--------------+--------------+
1 row in set (0.01 sec)
mysql>

이 쿼리에 의해서,mysql 에 대한 다양한 것을 압니다.

  • 통상, 커멘드는 SQL 스테이트먼트의 뒤에 세?~ 코론을 기술하는 형식에서 입력한다(세?~ 코론이 불필요한 경우도 있어, 예를 들어 전술의 QUIT 하지만 거기에 해당한다.다른 예외에 대해서는 후술 한다).

  • 커멘드를 발행하면,mysql (은)는 그것을 서버에 송신해 실행을 의뢰해, 돌려주어진 결과를 표시한다.그리고,mysql> prompt를 재차 표시하고, 다음의 커멘드 입력을 받아들일 수 있는 상태인 것을 나타낸다.

  • 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 |
+-------------+---------+
|    0.707107 |      25 |
+-------------+---------+

지금까지의 예로 사용한 쿼리는 비교적 짧은 단일행 스테이트먼트였지만, 단일행에 복수 스테이트먼트를 입력할 수도 있습니다.이 경우도, 각 스테이트먼트의 말미에 세?~ 코론을 입력할 뿐입니다.

mysql> SELECT VERSION(); SELECT NOW();
+--------------+
| VERSION()    |
+--------------+
| 3.22.20a-log |
+--------------+

+---------------------+
| NOW()               |
+---------------------+
| 1999-03-19 00:15:33 |
+---------------------+

커멘드는 1 행에 거둘 필요는 없고, 긴 커멘드를 복수행에 걸쳐서 기술해도 문제 없습니다.mysql (은)는, 입력행의 마지막이 아니고, 세?~ 코론을 스테이트먼트의 마지막이라고 판단해 처리합니다.즉,mysql 에의 입력은 프리 포맷이며, 입력된 행은, 세?~ 코론이 읽힐 때까지 실행되지 않습니다.

이하에 간단한 복수행 스테이트먼트를 나타냅니다.

mysql> SELECT
    -> USER()
    -> ,
    -> CURRENT_DATE;
+--------------------+--------------+
| USER()             | CURRENT_DATE |
+--------------------+--------------+
| joesmith@localhost | 1999-03-18   |
+--------------------+--------------+

이 예를 보면, 쿼리의 최초의 행을 입력한 후에, prompt가 mysql> (으)로부터 -> (으)로 변해있습니다.mysql (은)는, 이와 같이 prompt를 바꾸는 것에 의해서, 도중까지 입력된 스테이트먼트의 나머지의 부분의 입력을 기다리고 있는 것을 나타냅니다.prompt에는 유용한 정보가 표시됩니다.이 정보에 주목하는 것으로,mysql 하지만 현재무엇을 기다리고 있는지를 알 수 있습니다.

도중까지 입력한 커멘드의 실행을 캔슬하는 경우는,\c (을)를 입력합니다.

mysql> SELECT
    -> USER()
    -> \c
mysql>

이 예에서도 prompt에 주목해 주세요.\c (을)를 입력하면 prompt는 mysql> 에 바뀌어,mysql 하지만 새로운 커멘드의 입력을 기다리고 있는 것이 나타납니다.

표시될 가능성이 있는 prompt와 그것이 의미한다 mysql 상태에 대해서, 이하의 겉(표)에 나타냅니다.

prompt | 의미
mysql> | 새로운 커멘드의 입력 대기
-> | 복수행 커멘드로 다음의 행의 입력 대기
'> | 단일 인용부호(‘' ＇)(으)로 시작되는 문자열을 읽어들여 안의 다음의 행의 입력 대기
"> | 이중 인용부호(‘" ＇)(으)로 시작되는 문자열을 읽어들여 안의 다음의 행의 입력 대기
`> | 박크크트 기호(‘` ＇)(으)로 시작되는 식별자를 읽어들여 안의 다음의 행의 입력 대기

단일행의 커멘드를 발행할 생각으로 말미의 세?~ 코론의 입력을 잊었기 때문에, 복수행 스테이트먼트가 되어 버리는 경우가 자주 있습니다.이 경우,mysql (은)는 입력 대기가 됩니다.

mysql> SELECT USER()
    ->

이 경우(스테이트먼트의 입력을 완료한 생각인데 -> prompt가 표시될 뿐), 대부분은 mysql (은)는 세?~ 코론이 입력되는 것을 기다리고 있는 상태입니다.표시되는 prompt의 의미를 알아차리지 않는 경우, 대처법을 알 수 있을 때까지 당분간 걸릴지도 모릅니다.이 스테이트먼트를 완료하려면 , 세?~ 코론을 입력합니다.거기에 따라 mysql 하지만 입력된 스테이트먼트를 실행합니다.

mysql> SELECT USER()
    -> ;
+--------------------+
| USER()             |
+--------------------+
| joesmith@localhost |
+--------------------+

'> 및 "> 의 2 개의 prompt는, 문자열의 입력중에 표시됩니다.MySQL 그럼, 문자열을 ‘' ＇ 또는 ‘" ＇ 그리고 둘러싸 표기할 수 있습니다('hello' ,"goodbye" 등).또,mysql 그럼, 복수행에 걸치는 문자열을 입력할 수 있습니다.표시되는 prompt가 '> 또는 "> 의 경우,‘' ＇ 또는 ‘" ＇ 의 어느 쪽인가의 인용부호로 시작된 문자열을 포함한 행을 입력하고 있는 도중에 있어, 그 문자열의 마지막을 나타내는 인용부호가 아직 입력되어 있지 않은 것을 의미합니다.이 동작은, 실제로 복수행에 걸치는 문자열을 입력하고 있는 경우는 문제가 되지 않습니다만, 실제로 그러한 케이스는 많은 것일까요.아니오, 그만큼 많지는 않습니다.오히려,'> 및 "> 의 prompt가 표시되는 것으로, 무심코 인용부호를 입력하는 것을 잊었던 것에 전교인가 되는 경우가 대부분입니다.예를 나타냅니다.

mysql> SELECT * FROM my_table WHERE name = "Smith AND age < 30;
    ">

이러한 SELECT 스테이트먼트를 입력하고 나서 Enter (을)를 누르고, 결과가 표시되는 것을 기다리고 있어도, 아무것도 표시되지 않습니다.이 경우, 이 쿼리에 왜 이렇게 시간이 걸리는지를 이상하게 생각하기 전에,"> prompt의 의미를 깨달을 필요가 있습니다.이 prompt는,mysql 하지만 입력 도중의 문자열의 나머지의 부분이 입력되는 것을 기다리고 있는 것을 나타냅니다(이 스테이트먼트에는,"Smith 그리고 시작되는 문자열의 마지막을 나타내는 인용부호가 없다고 하는 에러가 있습니다).

이 경우, 무엇을 하면 좋을까요.가장 간단한 방법은 커멘드를 캔슬하는 것입니다.다만, 이 경우는 \c (을)를 입력하는 것 만으로는 캔슬할 수 없습니다.그 입력은, 현재 도중까지 입력되고 있는 문자열의 일부로서 mysql 에 해석되기 (위해)때문입니다.대신에, 우선 문자열의 마지막을 나타내는 인용부호를 입력해(이것에 의해서 mysql 하지만 문자열의 마지막을 인식한다), 그리고 \c (을)를 입력합니다.

mysql> SELECT * FROM my_table WHERE name = "Smith AND age < 30;
    "> "\c
mysql>

prompt가 mysql> 에 돌아와,mysql 하지만 새로운 커멘드의 입력을 기다리고 있는 것이 나타납니다.

`> prompt는,'> 및 "> 의 2 개의 prompt를 닮아 있습니다만, 박크크트로 둘러싸인 식별자의 입력이 완료하고 있지 않는 것을 나타내 보입니다.

'> ,"> , 및 `> 의 각 prompt의 의미를 아는 것은 중요합니다.이것을 깨닫지 못하면 문자열의 마지막의 입력을 잊었을 경우에, 그 후 입력한 내용이,QUIT 도 포함하고, 모두 mysql 에 무시됩니다.이러한 상태가 되면, 특히 현재의 커멘드를 캔슬하기 전에 문자열의 마지막을 나타내는 인용부호를 입력할 필요가 있는 것을 모르는 경우는, 매우 혼란합니다.


3.3. 데이타베이스의 작성 및 사용

커멘드의 입력 방법을 알 수 있었더니, 다음은 데이타베이스에 액세스 합니다.

자택에서 다양한 애완동물을 기르고 있고, 각각 붙어 다양한 정보를 기록하는 것을 생각합니다.데이터를 격납하기 위한 테이블을 작성해, 필요한 정보를 로드하는 것으로, 그것을 실현할 수 있습니다.테이블에서 데이터를 취득하는 것으로, 애완동물에 관한 다양한 질문에 답할 수도 있습니다.여기에서는, 이하의 작업 순서에 대해 설명합니다.

  • 데이타베이스를 작성한다.

  • 테이블을 작성한다.

  • 테이블에 데이터를 로드한다.

  • 다양한 방법으로 테이블에서 데이터를 취득한다.

  • 복수의 테이블을 사용한다.

애완동물 데이타베이스는 단순합니다만(의도적), 같은 종류의 데이타베이스가 실제로 사용되는 상황은 얼마든지 생각할 수 있습니다.예를 들어, 농가가 가축을 관리하거나 수의가 병력을 기록할 때에, 같은 데이타베이스를 사용할 수 있습니다.몇개의 쿼리와 샘플 데이터를 포함한 애완동물 데이타베이스의 디스트리뷰션은,MySQL Web 사이트로부터 입수할 수 있습니다.디스트리뷰션은, 압축 tar 형식(http://www.mysql.com/Downloads/Contrib/Examples/menagerie.tar.gz ) 또는 Zip 형식(http://www.mysql.com/Downloads/Contrib/Examples/menagerie.zip )(으)로 제공되고 있습니다.

SHOW 스테이트먼트를 실행하면, 현재 서버상에 존재하는 데이타베이스의 일람을 표시할 수 있습니다.

mysql> SHOW DATABASES;
+----------+
| Database |
+----------+
| mysql    |
| test     |
| tmp      |
+----------+

많은 경우, 표시되는 데이타베이스의 일람은 위의 예와 실제의 머신에서는 다릅니다만,mysql 및 test 의 2 개의 데이타베이스는 어느 쪽에도 포함되어 있다고 생각됩니다.mysql 데이타베이스는, 유저 특권의 정의에 사용하므로 필수입니다.test 데이타베이스는, 유저가 테스트에 사용하는 작업장소로서 제공되고 있습니다.

주의: SHOW DATABASES 특권이 없는 경우는 모든 데이타베이스는 표시할 수 없습니다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

test 데이타베이스가 존재하고 있는 경우, 액세스 해 보겠습니다.

mysql> USE test
Database changed

주의: USE (은)는,QUIT (와)과 같이, 세?~ 코론을 말미에 붙일 필요는 없습니다(세?~ 코론을 붙여도 악영향은 없습니다).USE 스테이트먼트는 다른 의미로 특별합니다.이 스테이트먼트는 단일행으로 입력할 필요가 있습니다.

test 데이타베이스를 사용하고(액세스권이 있는 경우), 이?~ 의 예를 시험할 수 있습니다만, 그 때에 이 데이타베이스에 작성한 오브젝트는, 이 데이타베이스에 액세스 할 수 있는 것 외의 유저에 의해서 삭제될 가능성이 있습니다.그 때문에, 독자적인 데이타베이스를 사용시켜 줄 수 있도록(듯이) MySQL 관리자에게 의뢰할 필요가 있습니다.여기에서는 menagerie (이)라는 이름의 데이타베이스를 사용하는 것으로 합니다.관리자는 이하와 같은 커멘드를 실행할 필요가 있습니다.

mysql> GRANT ALL ON menagerie.* TO 'your_mysql_name'@'your_client_host';

여기서,your_mysql_name (은)는 사용한다 MySQL 유저명,your_client_host (은)는 서버에 접속할 때에 사용하는 호스트입니다.

3.3.1. 데이타베이스의 작성 및 선택

관리자가, 권한을 설정할 때에 데이타베이스도 작성했을 경우는, 그것을 곧바로 사용하기 시작할 수 있습니다.그렇지 않으면, 스스로 데이타베이스를 작성할 필요가 있습니다.

mysql> CREATE DATABASE menagerie;

Unix 의 경우, 데이타베이스명은(SQL 키워드와는 달라) 대문자와 소문자가 구별됩니다.따라서, 상기의 커멘드로 작성한 데이타베이스를 참조할 때는 반드시 menagerie (와)과 지정할 필요가 있습니다.Menagerie (이)나 MENAGERIE 등을 지정해도 참조할 수 없습니다.이것은, 테이블명에서도 같습니다(Windows 의 경우는 이 제한은 적용되지 않지만,1 개의 쿼리내에서 사용하는 데이타베이스명 및 테이블명에서는, 대문자와 소문자의 지정 방법을 통일할 필요가 있습니다).

데이타베이스를 작성한 것 만으로는, 그 데이타베이스의 선택은 행해지지 않습니다.명시적으로 선택할 필요가 있습니다.menagerie (을)를 경향 데이타베이스로 하려면 , 이하의 커멘드를 사용합니다.

mysql> USE menagerie
Database changed

데이타베이스를 작성할 필요가 있는 것은 1 회 뿐입니다만, 데이타베이스의 선택은,mysql 세션을 개시할 때마다 실행할 필요가 있습니다.데이타베이스는, 상기의 예의 같게 USE 스테이트먼트를 발행해 선택합니다.다른 방법으로서mysql (을)를 호출하는 커멘드 라인으로 데이타베이스를 선택할 수도 있습니다.그 경우는, 필요한 접속 파라미터를 기술한 후에 데이타베이스명을 추가할 뿐입니다.예를 나타냅니다.

shell> mysql -h host -u user -p menagerie
Enter password: ********

주의: 상기의 예에서는 menagerie (은)는 패스워드가 아닙니다.패스워드를 커멘드 라인의 -p 옵션의 다음에 지정하는 경우는, 스페이스를 비우지 않고 기술합니다(예를 들어,-p mypassword (이)가 아니고,-pmypassword (와)과 지정한다).다만, 패스워드를 커멘드 라인에 기술하면, 같은 머신에 로그인하고 있는 것 외의 유저로부터 그 패스워드가 참조 가능한 상태가 되므로, 그러한 지정 방법은 추천 할 수 없습니다.

3.3.2. 테이블의 작성

데이타베이스의 작성은 간단합니다.다만, 이하의 SHOW TABLES 의 결과로 밝혀지도록(듯이), 현재는 하늘인 채입니다.

mysql> SHOW TABLES;
Empty set (0.00 sec)

어려운 것은, 데이타베이스의 구조, 즉 필요한 테이블과 각각의 컬럼을 결정하는 것입니다.

우선, 애완동물마다의 레코드를 가지는 테이블을 작성합니다.이 테이블에는 pet (이)라는 이름을 붙이고, 적어도 동물의 이름만은 격납할 필요가 있습니다.이름만으로는 테이블을 작성하는 의미가 별로 없기 때문에, 다른 정보도 격납할 필요가 있습니다.예를 들어, 가족안의 복수의 인물이 애완동물을 기르고 있는 경우, 애완동물마다의 주인을 알고 싶은 경우가 있습니다.또, 종류나 성별등의 기본 정보를 기록할 수도 있습니다.

연령에 대해서는 어떨까요.연령도 중요한 정보입니다만, 그것을 데이타베이스에 격납하는 것은 적절하지는 않습니다.연령은 시간의 경과와 함께 변화하므로, 기록을 빈번히 갱신할 필요가 있기 때문에입니다.대신에, 생일등의 고정치를 격납하는 편이 적절합니다.그러면, 필요한 때에 현재의 일자와 생일과의 차분을 계산하고 연령을 알 수 있습니다.MySQL 에는 일자 계산을 행하기 위한 함수가 준비되어 있으므로, 이것은 어려운 일이 아닙니다.연령 대신에 생일을 격납하는 것에는, 다른 장점도 있습니다.

  • 데이타베이스를 사용하고, 애완동물의 이번 생일을 알리는, 등의 작업을 실행할 수 있다(주의: 애완동물의 생일을 알리는 쿼리 등 어처구니없다고 생각할지도 모르지만, 인간적인 행동을 하기 위해서 컴퓨터를 사용한다고 하는 의미에서는, 비즈니스 데이타베이스를 사용해 생일 축하를 줄 필요가 있는 고객을 조사하는 경우의 쿼리와 같다).

  • 현재의 일자 이외의 일자에 관련한 연령을 계산할 수 있다.예를 들어, 데이타베이스에 기일을 격납하면, 애완동물이 죽었을 때의 연령을 간단하게 계산할 수 있다.

pet 테이블에 격납하면 편리한 정보를 그 밖에도 생각날지도 모릅니다만, 지금까지 든 이름, 주인, 종류, 성별, 생일, 기일에만, 현재는 충분합니다.

CREATE TABLE 스테이트먼트를 사용해 테이블의 레이아웃을 지정합니다.

mysql> CREATE TABLE pet (name VARCHAR(20), owner VARCHAR(20),
    -> species VARCHAR(20), sex CHAR(1), birth DATE, death DATE);

name ,owner , 및 species 의 각 컬럼의 값은 길이가 고정은 아니기 때문에, 데이터형으로서는 VARCHAR 하지만 적합합니다.이러한 컬럼의 길이는 모두 같은 필요는 없습니다.또,20 문자일 필요도 없습니다.1 (으)로부터 255 의 범위에서 최적이라고 생각되는 길이를 지정할 수 있습니다(지정한 길이가 적절하지 않고, 나중에 더 긴 필드가 필요한 것을 알았을 경우를 위해서,MySQL 에는 ALTER TABLE 스테이트먼트가 준비되어 있다).

애완동물의 기록으로 성별을 나타내려면 ,"m" (와)과 "f" , 또는 "male" (와)과 "female" 등, 다양한 표기를 생각할 수 있습니다.여기는,"m" (와)과 "f" 의 1 문자의 값을 사용하는 것이 가장 간단합니다.

birth 및 death 의 각 컬럼에 DATE 데이터형을 사용하는 것은 자명한 선택입니다.

이것으로 테이블을 작성할 수 있었습니다.SHOW TABLES (을)를 실행하면, 이하의 정보가 출력됩니다.

mysql> SHOW TABLES;
+---------------------+
| Tables in menagerie |
+---------------------+
| pet                 |
+---------------------+

테이블이 상정대로 작성된 것을 확인하기 위해서,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 (은)는, 테이블의 컬럼의 이름이나 그 데이터형을 잊었을 경우 등, 언제라도 사용할 수 있습니다.

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 |

여기에서는 하늘의 테이블을 사용하므로, 거기에 데이터를 추가하는 간단한 방법은, 애완동물마다의 행을 기술한 텍스트 파일을 작성해,1 개의 스테이트먼트로 그 파일의 내용을 로드합니다.

여기에서는,CREATE TABLE 스테이트먼트로 기술한 컬럼의 차례로 맞추고,1 행에 1 레코드의 형식에서 탭으로 단락지은 값을 기술한 텍스트 파일 pet.txt (을)를 작성합니다.값이 없는 경우(성별을 모르는 경우나 생존중의 애완동물의 기일 등), 대신에 NULL 값을 사용할 수 있습니다.텍스트 파일로 그것을 표현하려면 ,\N (backslash와 대문자의 N )(을)를 사용합니다.예를 들어, 새의 Whistler 의 레코드는 이하와 같이 됩니다.

name | owner | species | sex | birth | death
Whistler | Gwen | bird | \N | 1997-12-09 | \N

텍스트 파일 pet.txt (을)를 pet 테이블에 로드하려면 , 이하의 커멘드를 사용합니다.

mysql> LOAD DATA LOCAL INFILE "pet.txt" INTO TABLE pet;

필요에 따라서, 컬럼의 단락 문자 및 개행 코드를,LOAD DATA 스테이트먼트로 명시적으로 지정할 수 있습니다.디폴트는 각각 탭과 LF 입니다.상기의 스테이트먼트로 텍스트 파일 pet.txt (을)를 올바르게 읽어들이려면 , 디폴트로 충분합니다.

이 스테이트먼트로 에러가 발생하는 경우, 사용하고 있다 MySQL 인스톨로,LOCAL INFILE 기능이 디폴트로 유효하게 되지 않은 것을 생각할 수 있습니다.이것을 변경하는 방법에 대해서는, 항4.3.4. 「LOAD DATA LOCAL 의 시큐러티 관련 사항」 (을)를 참조해 주세요.

새로운 레코드를 1 레코드씩 추가하는 경우는,INSERT 스테이트먼트를 사용합니다.CREATE TABLE 스테이트먼트로 기술한 컬럼의 차례로 맞추어 각 컬럼의 값을 지정하는 것이, 가장 간단한 형식입니다.Diane 하지만 Puffball (이)라는 이름의 햄스터를 새롭게 기르기로 했을 경우를 생각합니다.이 새로운 레코드를 추가하려면 , 이하와 같이 INSERT 스테이트먼트를 사용합니다.

mysql> INSERT INTO pet
    -> VALUES ('Puffball','Diane','hamster','f','1999-03-30',NULL);

주의: 여기에서는, 일자와 문자열의 값은 인용부호로 둘러싼 문자열로서 지정되어 있습니다.또,INSERT 스테이트먼트에서는 NULL (을)를 직접 기술해 불명한 값을 표현할 수 있습니다.이 경우는 LOAD DATA 그리고 사용했다 \N (은)는 사용하지 않습니다.

이 예로부터, 하늘의 테이블에 데이터를 추가할 경우에 복수의 INSERT 스테이트먼트를 사용하면,1 개의 LOAD DATA 스테이트먼트를 사용하는 것 보다 훨씬 많은 문자를 입력할 필요가 있는 것을 압니다.

3.3.4. 테이블에서의 정보의 취득

테이블에서 정보를 취득하려면 ,SELECT 스테이트먼트를 사용합니다.이 스테이트먼트의 일반적인 형식을 이하에 나타냅니다.

SELECT what_to_select
FROM which_table
WHERE conditions_to_satisfy;

what_to_select (은)는, 취득하는 컬럼을 나타냅니다.여기에는 컬럼의 리스트를 지정합니다.* (을)를 지정했을 경우는 `` 모든 컬럼'' (을)를 나타냅니다.which_table (은)는, 데이터의 취득원의 테이블을 나타냅니다.WHERE 마디는 생략 가능합니다.지정하는 경우는, 취득 대상이 되는 레코드가 채워야 할 조건을 conditions_to_satisfy (으)로 지정합니다.

3.3.4.1. 전데이터의 SELECT

이하에 나타낸다 SELECT 의 가장 간단한 형식을 실행하면, 테이블의 전데이터를 취득합니다.

mysql> SELECT * FROM pet;
+----------+--------+---------+------+------------+------------+
| name     | owner  | species | sex  | birth      | death      |
+----------+--------+---------+------+------------+------------+
| Fluffy   | Harold | cat     | f    | 1993-02-04 | NULL       |
| 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       |
| Puffball | Diane  | hamster | f    | 1999-03-30 | NULL       |
+----------+--------+---------+------+------------+------------+

이 형식의 SELECT (을)를 사용하는 예로서 초기 데이터를 테이블에 로드한 직후에, 테이블의 전데이터를 확인하는 경우가 있습니다.예를 들어,Bowser 의 생일이 올바르지 않은 것이 아닐까 생각했다고 합니다.혈통서를 조사했는데, 올바른 태생년은 1979 해는 아니고 1989 해인 것을 알 수 있었습니다.

이 경우, 데이터를 수정하려면 , 적어도 2 개의 방법이 있습니다.

  • 텍스트 파일 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 에 의해서 해당 레코드만이 변경되어 테이블을 재로드할 필요는 없다.

3.3.4.2. 특정의 레코드의 SELECT

전의 섹션으로 나타내 보인 것처럼, 테이블 전체를 읽어내는 것은 간단합니다.SELECT 스테이트먼트로 WHERE 마디를 생략 하면, 테이블 전체를 취득할 수 있습니다.그러나, 통상은, 특히 대규모 테이블의 경우는, 테이블 전체를 읽어낼 것은 없습니다.특정의 질문에 회답한다고 하고는 자른 목적이 있어, 그 때문에(위해) 필요한 정보를 취득하기 위한 제약을 지정하는 것이 보통입니다.여기서, 애완동물에 관한 질문이라고 하는 관점으로부터, 그 회답을 나타내는 몇개의 SELECT 쿼리에 대해 설명합니다.

테이블에서 특정의 레코드만을 선택할 수 있습니다.예를 들어,Bowser 의 생일이 변경된 것을 확인하려면 , 이하와 같이 Bowser 의 레코드를 선택합니다.

mysql> SELECT * FROM pet WHERE name = "Bowser";
+--------+-------+---------+------+------------+------------+
| name   | owner | species | sex  | birth      | death      |
+--------+-------+---------+------+------------+------------+
| Bowser | Diane | dog     | m    | 1989-08-31 | 1995-07-29 |
+--------+-------+---------+------+------------+------------+

이 출력으로부터, 태생년이 1979 해부터 1989 해에 올바르게 변경되었던 것이 확인할 수 있습니다.

문자열의 비교로는, 통상은 대문자와 소문자는 구별되지 않습니다.따라서,"bowser" (이)나 "BOWSER" 등을 지정해도, 쿼리로부터 돌려주어지는 결과는 같습니다.

조건은,name 이외의 컬럼에도 지정할 수 있습니다.예를 들어,1998 해이후에 태어난 애완동물을 조사하려면 ,birth 컬럼에 조건을 지정합니다.

mysql> SELECT * FROM pet WHERE birth >= "1998-1-1";
+----------+-------+---------+------+------------+-------+
| name     | owner | species | sex  | birth      | death |
+----------+-------+---------+------+------------+-------+
| Chirpy   | Gwen  | bird    | f    | 1998-09-11 | NULL  |
| Puffball | Diane | hamster | f    | 1999-03-30 | NULL  |
+----------+-------+---------+------+------------+-------+

조건은 조합할 수 있습니다.예를 들어, 메스의 개를 조사하려면 이하와 같이 조건을 지정합니다.

mysql> SELECT * FROM pet WHERE species = "dog" AND sex = "f";
+-------+--------+---------+------+------------+-------+
| name  | owner  | species | sex  | birth      | death |
+-------+--------+---------+------+------------+-------+
| Buffy | Harold | dog     | f    | 1989-05-13 | NULL  |
+-------+--------+---------+------+------------+-------+

상기의 쿼리에서는,AND 논리 연산자를 사용하고 있습니다.그 외에,OR 연산자도 있습니다.

mysql> SELECT * FROM pet WHERE species = "snake" OR species = "bird";
+----------+-------+---------+------+------------+-------+
| name     | owner | species | sex  | birth      | death |
+----------+-------+---------+------+------------+-------+
| Chirpy   | Gwen  | bird    | f    | 1998-09-11 | NULL  |
| Whistler | Gwen  | bird    | NULL | 1997-12-09 | NULL  |
| 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");
+-------+--------+---------+------+------------+-------+
| name  | owner  | species | sex  | birth      | death |
+-------+--------+---------+------+------------+-------+
| Claws | Gwen   | cat     | m    | 1994-03-17 | NULL  |
| Buffy | Harold | dog     | f    | 1989-05-13 | NULL  |
+-------+--------+---------+------+------------+-------+

3.3.4.3. 특정의 컬럼의 SELECT

테이블의 레코드 전체를 표시할 필요가 없는 경우, 표시하는 컬럼만을 콤마로 단락지어 지정합니다.예를 들어, 애완동물의 생일만을 취득하려면 ,name 컬럼과 birth 컬럼을 선택합니다.

mysql> SELECT name, birth FROM pet;
+----------+------------+
| name     | birth      |
+----------+------------+
| Fluffy   | 1993-02-04 |
| Claws    | 1994-03-17 |
| Buffy    | 1989-05-13 |
| Fang     | 1990-08-27 |
| Bowser   | 1989-08-31 |
| Chirpy   | 1998-09-11 |
| Whistler | 1997-12-09 |
| Slim     | 1996-04-29 |
| Puffball | 1999-03-30 |
+----------+------------+

애완동물의 주인을 취득하려면 , 이하의 쿼리를 사용합니다.

mysql> SELECT owner FROM pet;
+--------+
| owner  |
+--------+
| Harold |
| Gwen   |
| Harold |
| Benny  |
| Diane  |
| Gwen   |
| Gwen   |
| Benny  |
| Diane  |
+--------+

이 경우, 쿼리가 각 레코드의 owner 필드의 값을 단지 취득하고 있으므로, 중복 하고 있는 값이 있는 것에 주의해 주세요.출력하는 데이터의 양을 최소한으로 하려면 , 키워드 DISTINCT (을)를 추가해 일의인 레코드를 1 회만 취득합니다.

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";
+--------+---------+------------+
| 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 |
+--------+---------+------------+

3.3.4.4. 레코드의 소트

지금까지의 예에서는, 쿼리로부터 돌려주어진 레코드는 무순서로 표시되고 있습니다.레코드의 표시 순서에 어떠한 의미가 있으면, 쿼리의 출력을 조사하는 것이 간단하게 되는 경우가 자주 있습니다.쿼리의 결과를 소트 하려면 ,ORDER BY 마디를 사용합니다.

애완동물의 생일을 일자순서로 취득하려면 , 이하의 쿼리를 사용합니다.

mysql> SELECT name, birth FROM pet ORDER BY birth;
+----------+------------+
| name     | birth      |
+----------+------------+
| Buffy    | 1989-05-13 |
| Bowser   | 1989-08-31 |
| Fang     | 1990-08-27 |
| Fluffy   | 1993-02-04 |
| Claws    | 1994-03-17 |
| Slim     | 1996-04-29 |
| 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 |
| 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 |
| Bowser   | dog     | 1989-08-31 |
| Buffy    | dog     | 1989-05-13 |
| Puffball | hamster | 1999-03-30 |
| Slim     | snake   | 1996-04-29 |
+----------+---------+------------+

주의: DESC 키워드는 그 직전에 기술된 컬럼(birth )에게만 적용됩니다.species 컬럼의 소트 순서에는 영향을 주지 않습니다.

3.3.4.5. 일자 계산

MySQL 그럼, 연령 계산이나 일자의 일부의 추출 등, 일자 계산을 실행하기 위한 다양한 함수가 준비되어 있습니다.

각각의 애완동물의 연령을 취득하려면 , 현재의 일자와 생일의 해의 부분의 차이를 요구해 현재의 일자의 세월의 부분이 생일의 세월의 부분보다 역년에 빠른 경우는, 한층 더 거기로부터 1 (을)를 당긴다고 하는 계산을 합니다.이하의 쿼리는, 각각의 애완동물에 대해서, 생일, 현재의 일자, 및 연령을 돌려줍니다.

mysql> SELECT name, birth, CURDATE(),
    -> (YEAR(CURDATE())-YEAR(birth))
    -> - (RIGHT(CURDATE(),5)<RIGHT(birth,5))
    -> AS age
    -> FROM pet;
+----------+------------+------------+------+
| name     | birth      | CURDATE()  | age  |
+----------+------------+------------+------+
| Fluffy   | 1993-02-04 | 2003-08-19 |   10 |
| 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 (역년)(을)를 나타내는 우단의 5 문자를 추출합니다.MM-DD 의 값을 비교하는 식은 1 또는 0 에 평가되어 거기에 따라 CURDATE() 하지만 birth 보다 역년에 빠르다고 판단되는 경우는, 나이차로부터 한층 더 1 (을)를 당깁니다.출력하는 컬럼의 라벨은, 식 전체라면 너무 길므로, 앨리어스(alias)(age )(을)를 사용하고, 알기 쉽게 합니다.

이대로도 쿼리는 동작합니다만, 결과를 어떠한 순서로 소트 하면, 그 내용을 조사하기 쉬워집니다.거기에는,ORDER BY name 마디를 추가하고, 이름으로 소트 한 결과를 출력합니다.

mysql> SELECT name, birth, CURDATE(),
    -> (YEAR(CURDATE())-YEAR(birth))
    -> - (RIGHT(CURDATE(),5)<RIGHT(birth,5))
    -> AS age
    -> FROM pet ORDER BY name;
+----------+------------+------------+------+
| name     | birth      | CURDATE()  | age  |
+----------+------------+------------+------+
| 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 |
+----------+------------+------------+------+

name (이)가 아니고,age (을)를 사용해 출력을 소트 하려면 , 다른 ORDER BY 마디를 사용합니다.

mysql> SELECT name, birth, CURDATE(),
    -> (YEAR(CURDATE())-YEAR(birth))
    -> - (RIGHT(CURDATE(),5)<RIGHT(birth,5))
    -> AS age
    -> FROM pet ORDER BY age;
+----------+------------+------------+------+
| name     | birth      | CURDATE()  | 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 |
| 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 하지만 특별한 값이며, 통상의 비교 연산자를 사용해 비교할 수 없기 때문입니다.이것에 대해서는, 다음에 설명합니다. See 항3.3.4.6. 「NULL 값의 사용」 .

다음 달에 생일을 맞이하는 애완동물을 취득하는 경우는 어떻게 하면 좋을까요.이 경우의 계산에서는, 해와 일의 부분은 필요없고,birth 컬럼의 달의 부분만큼을 추출할 필요가 있습니다.MySQL 그럼,YEAR() ,MONTH() , 및 DAYOFMONTH() 등, 일자의 일부를 추출하는 함수가 준비되어 있습니다.여기에서는,MONTH() 하지만 적합합니다.그 동작을 조사하려면 ,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 달이다고 합니다.그 경우, 달의 값은 4 (이어)여, 이하와 같이 지정하고,5 달(5 )(으)로 태어난 애완동물을 취득합니다.

mysql> SELECT name, birth FROM pet WHERE MONTH(birth) = 5;
+-------+------------+
| name  | birth      |
+-------+------------+
| Buffy | 1989-05-13 |
+-------+------------+

현재가 12 달의 경우는 다소 복잡하게 됩니다.12 달(12 )에 단순하게 1 (을)를 더해 다음달(13 )(으)로 태어난 애완동물을 취득하려고 해도, 그러한 달은 존재하지 않기 때문에 성공하지 않습니다.이 경우는 1 달(1 )(으)로 태어난 애완동물을 취득할 필요가 있습니다.

현재가 어느 달이어도 동작하는 쿼리를 작성할 수도 있습니다.이 경우, 쿼리로 특정의 월수를 지정할 필요는 없습니다.DATE_ADD() (을)를 사용하면, 지정된 일자에 기간을 가산할 수 있습니다.CURDATE() 의 값에 1 개월을 가산해, 그 결과로부터 MONTH() (을)를 사용해 달의 부분을 추출하면, 애완동물의 생일을 조사하는 달을 알 수 있습니다.

mysql> SELECT name, birth FROM pet
    -> WHERE MONTH(birth) = MONTH(DATE_ADD(CURDATE(), INTERVAL 1 MONTH));

현재의 달(잉여 함수(MOD )(을)를 사용해 현재가 12 달의 경우는 0 (으)로 한다)에 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 달(11 )의 다음이 1 달(1 )(이)가 됩니다.

3.3.4.6. NULL 값의 사용

NULL 값에 대해서는, 익숙해질 때까지는 당황하는 점이 있을지도 모릅니다.개념적으로는,NULL (은)는 아무것도 없는 값 또는 불명한 값을 의미해, 다른 값과는 다소 다른 취급하는 방법을 합니다.NULL 화도인지를 조사하는 경우,= ,< , 또는 <> 등의 산술 비교 연산자는 사용할 수 없습니다.이것을 스스로 시험하려면 , 이하의 쿼리를 실행합니다.

mysql> SELECT 1 = NULL, 1 <> NULL, 1 < NULL, 1 > NULL;
+----------+-----------+----------+----------+
| 1 = NULL | 1 <> NULL | 1 < NULL | 1 > NULL |
+----------+-----------+----------+----------+
|     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 |
+-----------+---------------+
|         0 |             1 |
+-----------+---------------+

주의: MySQL 그럼,0 또는 NULL 하 false ( 위) (을)를 의미해, 그 이외는 true ( 진) (을)를 의미합니다.불리언 값 연산에서는,true (을)를 나타내는 디폴트치는 1 입니다.

이와 같이 NULL (은)는 특별한 취급 방법을 하므로, 전의 섹션에서는 애완동물이 죽어 있는지 어떤지를 판단할 때에 death <> NULL (이)가 아니고,death IS NOT NULL (을)를 사용했습니다.

GROUP BY 그럼,2 개의 NULL 값은 동일하다고 보입니다.

ORDER BY (을)를 처리하는 경우,NULL 값은,ORDER BY ... ASC 그럼 선두에 표시되어ORDER BY ... DESC 그럼 마지막에 표시됩니다.

주의: MySQL 4.0.2 (으)로부터 4.0.10 그럼,NULL 값이 올바르게 처리되어 있지 않기 때문에, 소트가 승순인가?~ 순서인가에 관계없이, 항상 선두에 표시됩니다.

3.3.4.7. 패턴 매치

MySQL 그럼, 표준의 SQL 의 패턴 매치 뿐만이 아니라,Unix 의 vi ,grep , 및 sed 등의 유틸리티로 사용되고 있는 것과 같은, 확장 정규 표현에 근거하는 패턴 매치도 준비되어 있습니다.

SQL 의 패턴 매치에서는, 임의의 1 문자에 일치한다 ‘_ ＇ (이)나, 임의의 수(0 문자도 포함한다)의 문자에 일치한다 ‘% ＇ (을)를 사용할 수 있습니다.MySQL 그럼,SQL 패턴은, 디폴트에서는, 대문자와 소문자가 구별되지 않습니다.여기에서는 몇개의 예를 나타냅니다.주의: SQL 패턴을 사용하는 경우는 = 또는 <> (이)가 아니고,LIKE 또는 NOT LIKE 의 비교 연산자를 사용합니다.

‘b ＇ 그리고 시작되는 이름을 취득하려면 , 이하의 쿼리를 실행합니다.

mysql> SELECT * FROM pet WHERE name LIKE "b%";
+--------+--------+---------+------+------------+------------+
| name   | owner  | species | sex  | birth      | death      |
+--------+--------+---------+------+------------+------------+
| Buffy  | Harold | dog     | f    | 1989-05-13 | NULL       |
| Bowser | Diane  | dog     | m    | 1989-08-31 | 1995-07-29 |
+--------+--------+---------+------+------------+------------+

'fy' 그리고 끝나는 이름을 취득하려면 , 이하의 쿼리를 실행합니다.

mysql> SELECT * FROM pet WHERE name LIKE "%fy";
+--------+--------+---------+------+------------+-------+
| name   | owner  | species | sex  | birth      | death |
+--------+--------+---------+------+------------+-------+
| Fluffy | Harold | cat     | f    | 1993-02-04 | NULL  |
| Buffy  | Harold | dog     | f    | 1989-05-13 | NULL  |
+--------+--------+---------+------+------------+-------+

‘w ＇ (을)를 포함한 이름을 취득하려면 , 이하의 쿼리를 실행합니다.

mysql> SELECT * FROM pet WHERE name LIKE "%w%";
+----------+-------+---------+------+------------+------------+
| name     | owner | species | sex  | birth      | death      |
+----------+-------+---------+------+------------+------------+
| Claws    | Gwen  | cat     | m    | 1994-03-17 | NULL       |
| Bowser   | Diane | dog     | m    | 1989-08-31 | 1995-07-29 |
| Whistler | Gwen  | bird    | NULL | 1997-12-09 | NULL       |
+----------+-------+---------+------+------------+------------+

정확히 5 문자의 이름을 취득하려면 ,‘_ ＇ 패턴 문자를 5 회 반복한 패턴을 사용합니다.

mysql> SELECT * FROM pet WHERE name LIKE "_____";
+-------+--------+---------+------+------------+-------+
| name  | owner  | species | sex  | birth      | death |
+-------+--------+---------+------+------------+-------+
| Claws | Gwen   | cat     | m    | 1994-03-17 | NULL  |
| Buffy | Harold | dog     | f    | 1989-05-13 | NULL  |
+-------+--------+---------+------+------------+-------+

MySQL 하지만 제공하는 이제(벌써) 1 개의 패턴 매치에서는, 확장 정규 표현을 사용합니다.이런 종류의 패턴이 일치하고 있을지를 조사하려면 ,REGEXP 및 NOT REGEXP (또는 그 동의어의 RLIKE 및 NOT RLIKE )(을)를 사용합니다.

확장 정규 표현의 특징의 일부를 이하에 나타냅니다.

  • ‘. ＇ (은)는 임의의 1 문자에 일치한다.

  • 문자 클래스 '[...]' (은)는, 모퉁이나 개내의 임의의 문자에 일치한다.예를 들어,'[abc]' 하 ‘a ＇,‘b ＇, 또는 ‘c ＇ 에 일치한다.문자의 범위를 지정하려면 , 데쉬를 사용한다.'[a-z]' (은)는 임의의 알파벳에 일치해,'[0-9]' (은)는 임의의 숫자에 일치한다.

  • ‘* ＇ (은)는, 그 전에 기술되었다 1 문자 분의 표현의 0 개이상의 반복과 일치한다.예를 들어,'x*' (은)는 임의의 수의 ‘x ＇ (와)과 일치해,'[0-9]*' (은)는 임의의 수의 숫자로 일치한다.'.*' (은)는 임의의 수의 임의의 문자와 일치한다.

  • REGEXP 패턴 매치는, 그 패턴이, 조합하는 값의 임의의 장소에 나타나고 있는 경우에 성공한다(LIKE 패턴 매치는 이것과는 다르고, 그 패턴이, 조합하는 값과 완전하게 일치하는 경우에게만 성공한다).

  • 조합하는 값의 선두와의 일치를 조사하려면 , 패턴의 선두에 ‘^ ＇ (을)를 지정해, 말미와의 일치를 조사하려면 , 패턴의 말미에 ‘$ ＇ (을)를 지정한다.

확장 정규 표현의 동작을 조사하기 위해서, 전출의 LIKE (을)를 사용한 쿼리를, 여기에서는 REGEXP (을)를 사용하도록(듯이) 고쳐 쓰고 있습니다.

‘b ＇ 그리고 시작되는 이름을 취득하려면 , 이름의 선두와 일치할지를 조합시키기 위해서 ‘^ ＇ (을)를 지정합니다.

mysql> SELECT * FROM pet WHERE name REGEXP "^b";
+--------+--------+---------+------+------------+------------+
| name   | owner  | species | sex  | birth      | death      |
+--------+--------+---------+------+------------+------------+
| Buffy  | Harold | dog     | f    | 1989-05-13 | NULL       |
| Bowser | Diane  | dog     | m    | 1989-08-31 | 1995-07-29 |
+--------+--------+---------+------+------------+------------+

MySQL 버젼 3.23.4 보다 전의 버젼에서는,REGEXP 그럼 대문자와 소문자가 구별되므로, 상기의 쿼리는 아무것도 결과를 돌려주지 않습니다.이 경우, 대문자 또는 소문자의 ‘b ＇ 의 어느 쪽일까하고 조합하려면 , 이하의 쿼리를 사용합니다.

mysql> SELECT * FROM pet WHERE name REGEXP "^[bB]";

MySQL 3.23.4 이?~ 의 버젼에서는,REGEXP 의 비교로 실제로 대문자와 소문자를 구별시키려면 ,BINARY 키워드를 사용해 몇개의 문자열을 바이너리 문자열로 합니다.이하의 쿼리는, 소문자의 ‘b ＇ 그리고 시작되는 이름과만 일치합니다.

mysql> SELECT * FROM pet WHERE name REGEXP BINARY "^b";

'fy' 그리고 끝나는 이름을 취득하려면 , 이름의 말미와 일치할지를 조합시키기 위해서 ‘$ ＇ (을)를 지정합니다.

mysql> SELECT * FROM pet WHERE name REGEXP "fy$";
+--------+--------+---------+------+------------+-------+
| name   | owner  | species | sex  | birth      | death |
+--------+--------+---------+------+------------+-------+
| Fluffy | Harold | cat     | f    | 1993-02-04 | NULL  |
| Buffy  | Harold | dog     | f    | 1989-05-13 | NULL  |
+--------+--------+---------+------+------------+-------+

‘w ＇ (을)를 포함한 이름을 취득하려면 , 이하의 쿼리를 실행합니다.

mysql> SELECT * FROM pet WHERE name REGEXP "w";
+----------+-------+---------+------+------------+------------+
| name     | owner | species | sex  | birth      | death      |
+----------+-------+---------+------+------------+------------+
| Claws    | Gwen  | cat     | m    | 1994-03-17 | NULL       |
| Bowser   | Diane | dog     | m    | 1989-08-31 | 1995-07-29 |
| Whistler | Gwen  | bird    | NULL | 1997-12-09 | NULL       |
+----------+-------+---------+------+------------+------------+

정규 표현 패턴은, 값의 임의의 위치에 패턴이 있으면 일치하므로, 와일드 카드를 패턴의 양측으로 기술하고,SQL 패턴을 사용하는 경우와 같이 패턴을 값전체와 일치시킬 필요는 없습니다.

정확히 5 문자의 이름을 취득하려면 ,‘^ ＇ (와)과 ‘$ ＇ (을)를 사용해 각각 이름의 선두와 말미에 일치시켜, 그 사이에 ‘. ＇ (을)를 5 회 반복해 지정합니다.

mysql> SELECT * FROM pet WHERE name REGEXP "^.....$";
+-------+--------+---------+------+------------+-------+
| name  | owner  | species | sex  | birth      | death |
+-------+--------+---------+------+------------+-------+
| Claws | Gwen   | cat     | m    | 1994-03-17 | NULL  |
| Buffy | Harold | dog     | f    | 1989-05-13 | NULL  |
+-------+--------+---------+------+------------+-------+

전의 쿼리로 ``n 회반복'' 연산자이다 '{n}' (을)를 사용할 수도 있습니다.

mysql> SELECT * FROM pet WHERE name REGEXP "^.{5}$";
+-------+--------+---------+------+------------+-------+
| name  | owner  | species | sex  | birth      | death |
+-------+--------+---------+------+------------+-------+
| Claws | Gwen   | cat     | m    | 1994-03-17 | NULL  |
| Buffy | Harold | dog     | f    | 1989-05-13 | NULL  |
+-------+--------+---------+------+------------+-------+

3.3.4.8. 레코드의 카운트

데이타베이스는 `` 어떤 종류의 데이터는 테이블에 몇회 출현할까'' 그렇다고 하는 질문에 답하기 위해서 자주(잘) 사용됩니다.예를 들어, 자신이 기르고 있는 애완동물의 수나, 주인 마다 기르고 있는 애완동물의 수를 조사하거나 애완동물에 관한 다양한 개체수조사를 실행할 수 있습니다.

기르고 있는 애완동물의 총수를 카운트 하는 것은,``pet 테이블에는 몇건의 레코드가 있을까'' 그렇다고 하는 질문과 같습니다.이것은, 이 테이블에서는 1 마리의 애완동물에 대해 1 레코드를 사용하고 있기 (위해)때문입니다.COUNT(*) (은)는 레코드의 수를 카운트 합니다.따라서, 기르고 있는 애완동물의 총수를 카운트 하려면 , 이하와 같은 쿼리를 사용합니다.

mysql> SELECT COUNT(*) FROM pet;
+----------+
| COUNT(*) |
+----------+
|        9 |
+----------+

전에, 애완동물의 주인의 이름을 취득하는 쿼리를 사용했습니다.COUNT() (을)를 사용하면, 주인 마다 기르고 있는 애완동물의 수를 카운트 할 수 있습니다.

mysql> SELECT owner, COUNT(*) FROM pet GROUP BY owner;
+--------+----------+
| owner  | COUNT(*) |
+--------+----------+
| Benny  |        2 |
| Diane  |        2 |
| Gwen   |        3 |
| Harold |        2 |
+--------+----------+

owner 마다의 모든 레코드를 그룹화 하기 위해서 GROUP BY (을)를 사용하고 있는 것에 주의해 주세요.이것을 지정하지 않는 경우, 이하의 에러 메세지가 표시됩니다.

mysql> SELECT owner, COUNT(*) FROM pet;
ERROR 1140: 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;
+---------+----------+
| 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 |
| 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 |
+---------+------+----------+

COUNT() (을)를 사용하는 경우, 테이블 전체를 취득할 필요는 없습니다.예를 들어, 전의 쿼리로 개와 고양이만을 카운트 하는 경우, 이하의 쿼리를 실행합니다.

mysql> SELECT species, sex, COUNT(*) FROM pet
    -> WHERE species = "dog" OR species = "cat"
    -> GROUP BY species, sex;
+---------+------+----------+
| species | sex  | COUNT(*) |
+---------+------+----------+
| 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;
+---------+------+----------+
| species | sex  | COUNT(*) |
+---------+------+----------+
| bird    | f    |        1 |
| cat     | f    |        1 |
| cat     | m    |        1 |
| dog     | f    |        1 |
| dog     | m    |        2 |
| hamster | f    |        1 |
| snake   | m    |        1 |
+---------+------+----------+

3.3.4.9. 복수 테이블의 사용

pet 테이블에서는 기르고 있는 애완동물의 데이터를 관리하고 있습니다.애완동물에 관한 그 외의 정보, 예를 들어 수의에 다닌 회수나 출산한 날 등, 그 일생에 발생하는 이벤트등을 기록하는 경우는, 다른 테이블을 작성할 필요가 있습니다.이 테이블은 어떠한 구성입니까.이 테이블에 필요한 컬럼을 이하에 나타냅니다.

  • 각 이벤트가 어느 애완동물에 관련한 것일까를 나타내기 위한 애완동물명

  • 이벤트 발생 일시

  • 이벤트에 대한 설명

  • 이벤트를 카테고리별로 분류할 수 있도록(듯이) 하는 경우는, 이벤트의 종류

이러한 검토 사항을 근거로 해event 테이블의 CREATE TABLE 스테이트먼트는 이하와 같이 됩니다.

mysql> CREATE TABLE event (name VARCHAR(20), date DATE,
    -> 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
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

이러한 레코드를 로드합니다.

mysql> LOAD DATA LOCAL INFILE "event.txt" INTO TABLE event;

pet 테이블에 대해서 실행한 쿼리로부터 학습한 내용을 참고로 하면,event 테이블로부터도 다양한 데이터를 취득할 수 있습니다.기본적인 생각은 같습니다.다만,event 테이블만으로는 질문에 회답할 수 없는 경우가 있습니다.그것은 어떠한 경우입니까.

각각의 애완동물이 출산했을 때의 연령을 조사하는 경우를 생각합니다.벌써 2 개의 일자로부터 연령을 계산하는 방법에 대해서는 설명했습니다.모친의 출산일은 event 테이블에 격납되고 있습니다만, 그 날의 모친의 연령을 조사하려면 모친의 생일이 필요합니다.이 생일은 pet 테이블에 격납되고 있습니다.이것은, 쿼리로 2 개의 테이블을 참조할 필요가 있는 것을 의미합니다.

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 type = "litter";
+--------+------+-----------------------------+
| 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         |
+--------+------+-----------------------------+

이 쿼리에 대해서는, 주목해야 할 점이 많이 있습니다.

  • 이 쿼리는 2 개의 테이블에서 정보를 취득할 필요가 있으므로,FROM 마디에는 그것들 2 개의 테이블명을 열거하고 있다.

  • 복수의 테이블의 정보를 조합하는(결합한다) 경우, 한편의 테이블의 레코드와 이제(벌써) 한편의 테이블의 레코드를 일치시키는 방법을 지정할 필요가 있다.어느 쪽의 테이블에도 name 컬럼이 있으므로, 이것은 간단하게 지정할 수 있다.이 쿼리에서는,WHERE 마디로 name 의 값을 사용해 2 개의 테이블의 레코드를 일치시키고 있다.

  • name 컬럼은 어느 쪽의 테이블에도 존재하므로, 그 컬럼을 참조하는 경우는 어느 쪽의 테이블의 컬럼인지를 지정할 필요가 있다.테이블을 지정하려면 , 컬럼명의 전에 테이블명을 전치 한다.

결합을 실행하는 경우, 반드시 2 개가 다른 테이블을 사용할 필요는 없습니다.테이블의 레코드를 같은 테이블외의 레코드와 비교하는 경우에는, 테이블을 그 자체와 결합시키면 편리합니다.예를 들어, 애완동물 중(안)에서 번식시키는 편성을 찾는 경우,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";
+--------+------+--------+------+---------+
| name   | sex  | name   | sex  | species |
+--------+------+--------+------+---------+
| Fluffy | f    | Claws  | m    | cat     |
| Buffy  | f    | Fang   | m    | dog     |
| Buffy  | f    | Bowser | m    | dog     |
+--------+------+--------+------+---------+

이 쿼리에서는, 컬럼을 참조하기 위해서, 테이블명에 앨리어스(alias)를 지정하고, 각각의 컬럼의 참조가, 어느 쪽의 테이블 인스턴스와 관련지을 수 있고 있을까를 분명히 알도록(듯이) 하고 있습니다.


3.4. 데이타베이스 및 테이블에 관한 정보의 취득

데이타베이스나 테이블의 이름을 잊었을 경우, 또는 특정의 테이블의 구조(컬럼명등)를 잊었을 경우, 어떻게 하면 좋을까요.MySQL 그럼, 서포트하는 데이타베이스 및 테이블의 정보를 제공하는 스테이트먼트를 다수 준비하는 것으로, 이러한 문제를 해결합니다.

SHOW DATABASES (은)는, 벌써 설명했던 대로, 서버가 관리하는 데이타베이스의 일람을 표시합니다.현재 선택되고 있는 데이타베이스를 취득하려면 ,DATABASE() 함수를 사용합니다.

mysql> SELECT DATABASE();
+------------+
| DATABASE() |
+------------+
| menagerie  |
+------------+

아직 어느 데이타베이스도 선택하고 있지 않는 경우는,NULL 하지만 돌려주어집니다(MySQL 4.1.1 보다 전의 버젼에서는 하늘의 문자열).

경향 데이타베이스에 포함되는 테이블을 취득하려면 (테이블명을 모르는 경우 등), 이하의 커멘드를 실행합니다.

mysql> SHOW TABLES;
+---------------------+
| Tables in menagerie |
+---------------------+
| event               |
| pet                 |
+---------------------+

테이블의 구조를 취득하려면 ,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    |       |
+---------+-------------+------+-----+---------+-------+

Field (은)는 컬럼명,Type (은)는 컬럼의 데이터형,NULL (은)는 컬럼에 NULL 값을 격납할 수 있을지,Key (은)는 컬럼에 인덱스가 부가되고 있는지 어떤지,Default (은)는 컬럼의 디폴트치를, 각각 나타내 보입니다.

테이블에 인덱스가 부가되고 있는 경우,SHOW INDEX FROM tbl_name (을)를 실행하면 그 정보를 취득할 수 있습니다.


3.5. 배치 모드로의 mysql 의 사용

지금까지의 섹션에서는,mysql (을)를 대화식에 사용하고, 쿼리를 입력해, 결과를 표시시키고 있었습니다.mysql (은)는, 배치 모드에서도 실행할 수 있습니다.배치 모드로 실행하려면 , 실행하는 커멘드를 파일에 기술해, 그 파일로부터 입력을 읽어들이도록(듯이) mysql 에 지시합니다.

shell> mysql < batch-file

Windows 위에서 mysql (을)를 실행하고 있고, 파일에 포함되는 특수 문자에 의해서 문제가 발생하는 경우, 이하와 같이 지정합니다.

dos> mysql -e "source batch-file"

커멘드 라인으로 접속 파라미터를 지정할 필요가 있는 경우, 이하와 같은 커멘드를 실행합니다.

shell> mysql -h host -u user -p < batch-file
Enter password: ********

배치 모드로 mysql (을)를 실행하는 경우, 우선 스크립트 파일을 작성하고 나서 그것을 실행합니다.

스크립트 파일에 포함되는 스테이트먼트의 일부에서 에러가 발생했을 경우도, 그 후의 처리를 계속시키는 경우는,--force 커멘드 라인 옵션을 지정할 필요가 있습니다.

스크립트를 사용하는 이유를 이하에 나타냅니다.

  • 쿼리를 반복해 실행하는 경우(예를 들어, 매일 또는 매주), 그것을 스크립트로 하는 것에 의해서, 실행할 때마다 같은 쿼리를 입력하는 수고를 생략할 수 있다.

  • 스크립트 파일을 카피해 편집하는 것에 의해서, 같은 기존의 쿼리로부터 새로운 쿼리를 작성할 수 있다.

  • 쿼리의 개발중은, 특히, 복수행에 걸치는 커멘드 또는 복수 스테이트먼트에 의한 일련의 커멘드를 사용하는 쿼리의 경우, 배치 모드로 실행할 수 있으면 편리하다.어디엔가 실수가 있어도, 모든 것을 재입력할 필요는 없다.스크립트 파일을 편집해 실수를 수정해,mysql 에 그것을 실행하도록(듯이) 지시하는 것만으로 좋다.

  • 대량의 데이터를 출력하는 쿼리가 있는 경우, 화면상에서 데이터가 단번에 스크롤 올라가는 것을 보는 것이 아니라, 출력을 페이지 표시 커멘드에 건네주어 1 페이지 단위로 표시시킬 수 있다.

    shell> mysql < batch-file | more

  • 출력을 파일에 수중에 넣고, 다음에 사용할 수 있다.

    shell> mysql < batch-file > mysql.out

  • 스스로 작성한 스크립트를 배포하는 것으로, 타인에게도 같은 커멘드를 실행시킬 수 있다.

  • 예를 들어 cron 작업으로부터 쿼리를 실행하는 경우 등, 대화식에서 처리할 수 없는 경우가 있다.이 경우는, 배치 모드를 사용할 필요가 있다.

mysql (을)를 배치 모드로 실행하는 경우, 그 출력 형식은, 대화식에 실행하는 경우와는 다릅니다(보다 간결하게 출력된다).예를 들어,mysql (을)를 대화식에 실행하는 경우,SELECT DISTINCT species FROM pet 의 출력은 이하와 같이 됩니다.

+---------+
| species |
+---------+
| bird    |
| cat     |
| dog     |
| hamster |
| snake   |
+---------+

배치 모드로 실행했을 경우는, 이하와 같이 출력됩니다.

species
bird
cat
dog
hamster
snake

배치 모드에서도 대화식과 같은 출력 형식에서 데이터를 취득하려면 ,mysql -t (을)를 사용합니다.실행하고 있는 커멘드를 출력에 에코 하려면 ,mysql -vvv (을)를 사용합니다.

source 커멘드를 사용하면,mysql prompt로부터에서도 스크립트를 실행할 수 있습니다.

mysql> source filename;


3.6. 일반적인 쿼리의 예

여기에서는,MySQL 에 관한 일반적인 문제를 해결하는 방법의 예를 나타냅니다.

일부의 예에서는, 테이블 shop (을)를 사용합니다.이 테이블에는, 업자(딜러)의 물품(품번) 마다의 가격이 격납됩니다.각 업자는 물품 마다 1 개의 정가를 매기고 있는 것으로 해, (article, dealer )(이)가 레코드의 프라이머리 키가 됩니다.

커멘드 라인 툴 mysql (을)를 호출하고, 데이타베이스를 선택합니다.

shell> mysql your-database-name

(대부분의 MySQL 인스톨로, 데이타베이스명 test (을)를 사용할 수 있습니다)

이하의 스테이트먼트를 실행하면, 테이블을 작성해, 데이터를 추가할 수 있습니다.

mysql> CREATE TABLE shop (
    -> 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 |
|    0003 | C      |  1.69 |
|    0003 | D      |  1.25 |
|    0004 | D      | 19.95 |
+---------+--------+-------+

3.6.1. 컬럼의 최대치

`` 품번이 가장 큰 물품은 ?''

SELECT MAX(article) AS article FROM shop;

+---------+
| article |
+---------+
|       4 |
+---------+

3.6.2. 특정의 컬럼의 최대치가 격납되고 있는 레코드

`` 가장 고가의 물품의 수, 업자, 및 가격은 ?''

SQL-99 ( 및 MySQL 버젼 4.1 이상)에서는, 서브 쿼리를 사용하면 간단하게 할 수 있습니다.

SELECT article, dealer, price
FROM   shop
WHERE  price=(SELECT MAX(price) FROM shop);

MySQL 버젼 4.1 보다 전의 버젼에서는,2 단계로 나누어 실행합니다.

  1. SELECT 스테이트먼트를 사용하고, 최고치를 테이블에서 취득한다.

    mysql> SELECT MAX(price) FROM shop;
+------------+
| MAX(price) |
+------------+
|      19.95 |
+------------+

  2. 위의 쿼리로 표시된 값 19.95 (을)를 최고치로서 사용하는 쿼리를 작성해, 대응하는 레코드를 검색 및 표시한다.

    mysql> SELECT article, dealer, price
    -> FROM   shop
    -> WHERE  price=19.95;
+---------+--------+-------+
| article | dealer | price |
+---------+--------+-------+
|    0004 | D      | 19.95 |
+---------+--------+-------+

이외에, 모든 레코드를 가격의?~ 순서로 소트 해,MySQL 고유의 LIMIT 마디를 사용해 선두의 레코드만을 취득하는 방법도 있습니다.

SELECT article, dealer, price
FROM   shop
ORDER BY price DESC
LIMIT 1;

주의: 가격이 19.95 의 물품이 다수 있는 경우,LIMIT 마디를 사용한 방법에서는, 그 중의 1 개 밖에 취득할 수 없습니다.

3.6.3. 그룹마다의 컬럼의 최대치

`` 물품마다의 최고치는 ?''

SELECT article, MAX(price) AS price
FROM   shop
GROUP BY article

+---------+-------+
| article | price |
+---------+-------+
|    0001 |  3.99 |
|    0002 | 10.99 |
|    0003 |  1.69 |
|    0004 | 19.95 |
+---------+-------+

3.6.4. 특정의 필드의 그룹마다의 최대치가 격납되고 있는 레코드

`` 물품 마다 최고치를 매기고 있는 업자(복수가능)는 ?''

SQL-99 ( 및 MySQL 버젼 4.1 이?~ )에서는, 이하에 나타내는 서브 쿼리를 사용해 이 문제를 해결할 수 있습니다.

SELECT article, dealer, price
FROM   shop s1
WHERE  price=(SELECT MAX(s2.price)
              FROM shop s2
              WHERE s1.article = s2.article);

MySQL 버젼 4.1 보다 전의 버젼에서는, 복수의 단계로 나누어 실행하는 것이 최적입니다.

  1. (물품, 최고치) 의 편성의 일람을 취득한다.

  2. 물품 마다, 최고치를 격납하고 있는 레코드를 취득한다.

이것은, 텐포라리테이불과 결합을 사용하면, 간단하게 실행할 수 있습니다.

CREATE TEMPORARY TABLE tmp (
        article INT(4) UNSIGNED ZEROFILL DEFAULT '0000' NOT NULL,
        price   DOUBLE(16,2)             DEFAULT '0.00' NOT NULL);

LOCK TABLES shop READ;

INSERT INTO tmp SELECT article, MAX(price) FROM shop GROUP BY article;

SELECT shop.article, dealer, shop.price FROM shop, tmp
WHERE shop.article=tmp.article AND shop.price=tmp.price;

UNLOCK TABLES;

DROP TABLE tmp;

TEMPORARY 테이블을 사용하지 않는 경우는,tmp 테이블도 잠글 필요가 있습니다.

`` 이것을 1 개의 쿼리로 실행할 수 있습니까 ?''

할 수 있습니다.다만,MAX (와)과 CONCAT (을)를 사용한, 비효율적인 수단을 사용할 필요가 있습니다.

SELECT article,
       SUBSTRING( MAX( CONCAT(LPAD(price,6,'0'),dealer) ), 7) AS dealer,
  0.00+LEFT(      MAX( CONCAT(LPAD(price,6,'0'),dealer) ), 6) AS price
FROM   shop
GROUP BY article;

+---------+--------+-------+
| article | dealer | price |
+---------+--------+-------+
|    0001 | B      |  3.99 |
|    0002 | A      | 10.99 |
|    0003 | C      |  1.69 |
|    0004 | D      | 19.95 |
+---------+--------+-------+

이 방법은, 클라이언트측에서 연결한 컬럼의 분할을 실행하면, 다소 효율 좋게 할 수 있습니다.

3.6.5. 유저 변수의 사용

MySQL 유저 변수를 사용하면, 클라이언트측에서 일시 변수를 사용하지 않고 결과를 기억할 수 있습니다. See 항6.1.4. 「유저 변수」 .

예를 들어, 최고치 및 최저가를 매길 수 있고 있는 물품을 취득하려면 , 이하의 쿼리를 실행합니다.

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 |
+---------+--------+-------+

3.6.6. 외부 키의 사용

MySQL 버젼 3.23.44 이?~ 그럼,InnoDB 테이블로 외부 키의 제약의 체크를 서포트하고 있습니다.See 항7.5. 「InnoDB 테이블」 . 항1.8.4.5. 「외부 키」 도 참조해 주세요.

실제로는 외부 키를 사용하지 않아도 2 개의 테이블을 결합할 수 있습니다.InnoDB 이외의 종류의 테이블의 경우,MySQL 하지만 현재 실행하지 않는 것은,1 ) CHECK (을)를 실행하고, 사용하고 있는 키가 테이블 또는 참조하고 있는 테이블에 실제로 존재할지를 확인하는 것,2 ) 외부 키가 정의되고 있는 테이블에서 자동적으로 레코드를 삭제하는 것, 의 2 개 뿐입니다.키를 사용해 테이블을 결합하면, 아무 문제도 없게 동작합니다.

CREATE TABLE person (
    id SMALLINT UNSIGNED NOT NULL AUTO_INCREMENT,
    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');

INSERT INTO shirt VALUES
(NULL, 'polo', 'blue', LAST_INSERT_ID()),
(NULL, 'dress', 'white', LAST_INSERT_ID()),
(NULL, 't-shirt', 'blue', LAST_INSERT_ID());

INSERT INTO person VALUES (NULL, 'Lilliana Angelovska');

INSERT INTO shirt VALUES
(NULL, 'dress', 'orange', LAST_INSERT_ID()),
(NULL, 'polo', 'red', LAST_INSERT_ID()),
(NULL, 'dress', 'blue', LAST_INSERT_ID()),
(NULL, 't-shirt', 'white', LAST_INSERT_ID());

SELECT * FROM person;
+----+---------------------+
| 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 |
|  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 |
+----+-------+--------+-------+

3.6.7. 2 개의 키를 사용한 검색

MySQL 그럼,OR 그리고 결합되었다 2 개가 다른 키를 사용한 검색은, 아직 최적화되고 있지 않습니다(1 개의 키를 복수의 OR 의 부분에서 사용하는 검색은 매우 최적화가 진행되고 있다).

SELECT field1_index, field2_index FROM test_table
WHERE field1_index = '1' OR  field2_index = '1'

이것은, 일반적인 케이스로 그러한 검색을 효율적으로 처리하는 방법을 찾아&A 시간이 없기 때문입니다(한편,AND 의 처리는 현재는 완전하게 일반화되어 지극히 효율적으로 동작하고 있습니다).

MySQL 4.0 이?~ 그럼,2 개가 다르다 SELECT 스테이트먼트의 출력을 결합한다 UNION (을)를 사용하는 것으로, 이 문제를 효율적으로 해결할 수 있습니다.See 항6.4.1.2. 「UNION 구문」 . 각각의 SELECT 스테이트먼트를 사용한 검색에서는 1 개의 키만이 사용되므로, 그것을 최적화할 수 있습니다.

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 4.0 보다 전의 버젼에서는,TEMPORARY 테이블 및 다르다 SELECT 스테이트먼트를 사용하는 것으로 같은 효과를 얻을 수 있습니다.이러한 최적화는,SQL 서버가 부적절한 순서로 최적화를 실행해 버리는, 매우 복잡한 쿼리를 실행하는 경우에도 최적입니다.

CREATE TEMPORARY TABLE tmp
SELECT field1_index, field2_index FROM test_table WHERE field1_index = '1';
INSERT INTO tmp
SELECT field1_index, field2_index FROM test_table WHERE field2_index = '1';
SELECT * from tmp;
DROP TABLE tmp;

이 해결 방법은, 실제로는 2 개의 쿼리의 UNION (와)과 같습니다.

3.6.8. 매일의 방문수의 계산

비트 그룹 함수를 사용하고, 어느 유저가 Web 페이지를 방문한 달 마다의 날짜를 계산하는 방법의 예를 이하에 나타냅니다.

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);

이 테이블에는, 유저가 페이지를 방문한 일자를 나타내는 연월일이 격납됩니다.달 마다의 방문 날짜를 취득하려면 , 이하의 쿼리를 실행합니다.

SELECT year,month,BIT_COUNT(BIT_OR(1<<day)) AS days FROM t1
       GROUP BY year,month;

이하의 결과가 표시됩니다.

+------+-------+------+
| year | month | days |
+------+-------+------+
| 2000 |    01 |    3 |
| 2000 |    02 |    2 |
+------+-------+------+

이 쿼리에서는, 세월의 편성에 대해서 다른 일자가 몇회 출현할까를, 자동적으로 중복 데이터를 제거하는 것에 의해서 계산하고 있습니다.

3.6.9. AUTO_INCREMENT 의 사용

AUTO_INCREMENT 속성을 사용하면, 새롭게 추가하는 레코드를 식별하기 위한 일의인 값을 생성할 수 있습니다.

CREATE TABLE animals (
             id MEDIUMINT NOT NULL AUTO_INCREMENT,
             name CHAR(30) NOT NULL,
             PRIMARY KEY (id)
             );
INSERT INTO animals (name) VALUES ("dog"),("cat"),("penguin"),
                                  ("lax"),("whale"),("ostrich");
SELECT * FROM animals;

이하의 결과가 표시됩니다.

+----+---------+
| id | name    |
+----+---------+
|  1 | dog     |
|  2 | cat     |
|  3 | penguin |
|  4 | lax     |
|  5 | whale   |
|  6 | ostrich |
+----+---------+

SQL 함수 LAST_INSERT_ID() 또는 C API 함수 mysql_insert_id() (을)를 사용하면, 마지막에 생성했다 AUTO_INCREMENT 의 값을 취득할 수 있습니다. 주의: 복수 레코드를 동시에 삽입하는 경우, LAST_INSERT_ID()/mysql_insert_id() (은)는, 실제로는 최초로 삽입한 레코드의 AUTO_INCREMENT 의 값을 돌려줍니다.이것에 의해, replication 설정의 경우에, 다른 서버에서도 올바르고 복수행의 삽입을 재현할 수 있습니다.

MyISAM 테이블과 BDB 테이블에서는, 복합 인덱스의2 손톱의 컬럼에 AUTO_INCREMENT (을)를 지정할 수 있습니다.이 경우,AUTO_INCREMENT 컬럼으로 생성되는 값은,MAX(auto_increment_column)+1) WHERE prefix=given-prefix (으)로서 계산됩니다.이것은, 데이터를 순서 첨부의 그룹에 분할하는 경우에 편리합니다.

CREATE TABLE animals (
             grp ENUM('fish','mammal','bird') NOT NULL,
             id MEDIUMINT NOT NULL AUTO_INCREMENT,
             name CHAR(30) NOT NULL,
             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;

이하의 결과가 표시됩니다.

+--------+----+---------+
| 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 하지만 재사용될 것은 없다).


3.7. 쌍생아 연구 프로젝트의 쿼리

Analytikerna 및 Lentus 그리고, 당사는 대규모 연구 프로젝트의 시스템 업무 및 현장 업무를 담당하고 있습니다.이 프로젝트는,Institute of Environmental Medicine at Karolinska Institutet Stockholm 및 Section on Clinical Research in Aging and Psychology at the University of Southern California 의 협동 작업으로서 행해지고 있습니다.

이 프로젝트에서는, 스웨덴 국내의 66 나이 이상의 모든 쌍생아에게 전화로 인터뷰 하는 예비 심사를 실시합니다.일정한 조건을 만족한 쌍생아는, 다음의 스테이지로 나아갑니다.이 스테이지에서는, 프로젝트에 참가를 희망하는 쌍생아를, 의사와 간호사로부터 되는 팀이 방문합니다.거기서, 신체검사, 신경 심리학적 검사, 임상시험, 신경 화상, 정신 상태 평가, 및 가계 수집등의 작업을 합니다.게다가 의학적 및 환경적인 위험 인자에 관한 데이터도 수집됩니다.

쌍생아 연구의 상세한 것에 대하여는,http://www.mep.ki.se/twinreg/index_en.html (을)를 참조해 주세요.

프로젝트의 후반 부분은 Perl 및 MySQL (을)를 사용해 작성했다 Web 인터페이스에 의해서 관리되고 있습니다.

인터뷰로부터 얻을 수 있던 데이터는 모두, 매일 저녁 MySQL 데이타베이스에 격납됩니다.

3.7.1. 미방문의 모든 쌍생아의 검색

이하의 쿼리는, 프로젝트의 후반 부분으로 나아가는 쌍생아를 결정하기 위해서 사용합니다.

SELECT
        CONCAT(p1.id, p1.tvab) + 0 AS tvid,
        CONCAT(p1.christian_name, " ", p1.surname) AS Name,
        p1.postal_code AS Code,
        p1.city AS City,
        pg.abrev AS Area,
        IF(td.participation = "Aborted", "A", " ") AS A,
        p1.dead AS dead1,
        l.event AS event1,
        td.suspect AS tsuspect1,
        id.suspect AS isuspect1,
        td.severe AS tsevere1,
        id.severe AS isevere1,
        p2.dead AS dead2,
        l2.event AS event2,
        h2.nurse AS nurse2,
        h2.doctor AS doctor2,
        td2.suspect AS tsuspect2,
        id2.suspect AS isuspect2,
        td2.severe AS tsevere2,
        id2.severe AS isevere2,
        l.finish_date
FROM
        twin_project AS tp
        /* For Twin 1 */
        LEFT JOIN twin_data AS td ON tp.id = td.id
                  AND tp.tvab = td.tvab
        LEFT JOIN informant_data AS id ON tp.id = id.id
                  AND tp.tvab = id.tvab
        LEFT JOIN harmony AS h ON tp.id = h.id
                  AND tp.tvab = h.tvab
        LEFT JOIN lentus AS l ON tp.id = l.id
                  AND tp.tvab = l.tvab
        /* For Twin 2 */
        LEFT JOIN twin_data AS td2 ON p2.id = td2.id
                  AND p2.tvab = td2.tvab
        LEFT JOIN informant_data AS id2 ON p2.id = id2.id
                  AND p2.tvab = id2.tvab
        LEFT JOIN harmony AS h2 ON p2.id = h2.id
                  AND p2.tvab = h2.tvab
        LEFT JOIN lentus AS l2 ON p2.id = l2.id
                  AND p2.tvab = l2.tvab,
        person_data AS p1,
        person_data AS p2,
        postal_groups AS pg
WHERE
        /* p1 gets main twin and p2 gets his/her twin. */
        /* ptvab is a field inverted from tvab */
        p1.id = tp.id AND p1.tvab = tp.tvab AND
        p2.id = p1.id AND p2.ptvab = p1.tvab AND
        /* Just the sceening survey */
        tp.survey_no = 5 AND
        /* Skip if partner died before 65 but allow emigration (dead=9) */
        (p2.dead = 0 OR p2.dead = 9 OR
         (p2.dead = 1 AND
          (p2.death_date = 0 OR
           (((TO_DAYS(p2.death_date) - TO_DAYS(p2.birthday)) / 365)
            >= 65))))
        AND
        (
        /* Twin is suspect */
        (td.future_contact = 'Yes' AND td.suspect = 2) OR
        /* Twin is suspect - Informant is Blessed */
        (td.future_contact = 'Yes' AND td.suspect = 1
                                   AND id.suspect = 1) OR
        /* No twin - Informant is Blessed */
        (ISNULL(td.suspect) AND id.suspect = 1
                            AND id.future_contact = 'Yes') OR
        /* Twin broken off - Informant is Blessed */
        (td.participation = 'Aborted'
         AND id.suspect = 1 AND id.future_contact = 'Yes') OR
        /* Twin broken off - No inform - Have partner */
        (td.participation = 'Aborted' AND ISNULL(id.suspect)
                                      AND p2.dead = 0))
        AND
        l.event = 'Finished'
        /* Get at area code */
        AND SUBSTRING(p1.postal_code, 1, 2) = pg.code
        /* Not already distributed */
        AND (h.nurse IS NULL OR h.nurse=00 OR h.doctor=00)
        /* Has not refused or been aborted */
        AND NOT (h.status = 'Refused' OR h.status = 'Aborted'
        OR h.status = 'Died' OR h.status = 'Other')
ORDER BY
        tvid;

쿼리의 일부에 도착해 간단하게 설명합니다.

  • CONCAT(p1.id, p1.tvab) + 0 AS tvid

    id (와)과 tvab (을)를 연결한 값을, 수치로서의 비교에 의해서 소트 한다.연결한 결과에 0 (을)를 가산하는 것으로,MySQL (은)는 그 결과를 수치로서 취급한다.

  • 컬럼 id

    쌍생아의 조를 식별한다.이것은 모든 테이블로 키로서 사용된다.

  • 컬럼 tvab

    쌍생아의 조안의 개인을 식별한다.이 값은 1 또는 2 의 어딘가에 된다.

  • 컬럼 ptvab

    tvab 의 반대의 값.tvab 하지만 1 의 경우, 이 값은 2 (이어)여, 그 역도 마찬가지이다.이 컬럼은, 입력량을 줄이기 위해와MySQL 하지만 쿼리를 최적화하기 쉽게 하기 위해서 정의되고 있다.

이 쿼리는, 특히, 같은 테이블을 사용한 결합(p1 (와)과 p2 )(으)로 테이블을 참조하는 방법을 나타내고 있습니다.이 예에서는, 쌍생아의 한편이 65 나이 이전에 사망해 있을지의 확인에 사용되고 있습니다.사망해 있는 경우, 그 레코드는 돌려주어지지 않습니다.

위에서 설명한 컬럼은, 쌍생아 관련의 모든 테이블로 정의되고 있습니다.쿼리의 실행 속도를 향상하기 위해서,id,tvab 의 양쪽 모두(모든 테이블) 및 id,ptvab (person_data )(을)를 키로 하고 있습니다.

당사의 실가동 머신(200MHz UltraSPARC )에서는, 이 쿼리는 150 ~ 200 건의 레코드를 돌려주어, 소요 시간은 1 초미만입니다.

상기의 쿼리로 사용되고 있는 각 테이블의 현재의 레코드수를 이하에 나타냅니다.

테이블 | 레코드수
person_data | 71074
lentus | 5291
twin_project | 5286
twin_data | 2012
informant_data | 663
harmony | 381
postal_groups | 100

3.7.2. 쌍생아의 조의 스테이터스를 정리한 표의 작성

인터뷰가 끝나면,event (으)로 불리는 스테이터스 코드를 할당합니다.이하의 쿼리는, 모든 쌍생아를 이벤트로 그룹화 한 표를 표시합니다.이 표에는, 쌍생아의 양쪽 모두에 인터뷰가 끝난 조의 수, 한편에 인터뷰가 끝났지만 이제(벌써) 한편에는 거절 당한 수, 등이 나타납니다.

SELECT
        t1.event,
        t2.event,
        COUNT(*)
FROM
        lentus AS t1,
        lentus AS t2,
        twin_project AS tp
WHERE
        /* We are looking at one pair at a time */
        t1.id = tp.id
        AND t1.tvab=tp.tvab
        AND t1.id = t2.id
        /* Just the sceening survey */
        AND tp.survey_no = 5
        /* This makes each pair only appear once */
        AND t1.tvab='1' AND t2.tvab='2'
GROUP BY
        t1.event, t2.event;


3.8. Apache (으)로의 MySQL 의 사용

MySQL 데이타베이스를 사용해 유저를 인증해, 로그 파일을 MySQL 의 테이블에 쓰는 프로그램이 있습니다.

Apache 설정 파일에 이하의 설정을 추가하는 것으로,MySQL 에 간단하게 읽어들일 수 있도록(듯이) Apache 의 로그 형식을 변경할 수 있습니다.

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 table_name
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"' ESCAPED BY '\\'

LogFormat 행이 로그 파일에 쓰는 데이터에 대응하고, 지정하는 테이블의 컬럼을 작성할 필요가 있습니다.


제4 장 데이타베이스 관리

목차

4.1. MySQL 의 콘피개
4.1.1. mysqld 커멘드 라인 옵션
4.1.2. my.cnf 옵션 설정 파일
4.2. 같은 머신상에서 복수의 MySQL 서버를 실행한다
4.2.1. Windows 위에서 복수의 서버를 실행한다
4.2.2. Unix 위에서 복수의 서버를 실행한다
4.2.3. 복수 서버 환경에서 클라이언트 프로그램을 사용한다
4.3. 일반적인 시큐러티 관련 사항과 MySQL 액세스 제어 시스템
4.3.1. 일반적인 시큐러티 가이드 라인
4.3.2. MySQL 의 크래커 대책
4.3.3. 시큐러티 관련의 mysqld 스타트 업 옵션
4.3.4. LOAD DATA LOCAL 의 시큐러티 관련 사항
4.3.5. 권한 시스템이 실시하는 것
4.3.6. 권한 시스템은 어떻게 기능할까
4.3.7. MySQL 하지만 제공하는 권한
4.3.8. MySQL 서버에의 접속
4.3.9. 액세스 제어의 단계 1: 접속 확인
4.3.10. 액세스 제어의 단계 2: 요구 확인
4.3.11. MySQL 4.1 의 패스워드 해시
4.3.12. Access denied 에러의 원인
4.4. MySQL 의 유저 관리
4.4.1. GRANT 및 REVOKE 의 구문
4.4.2. MySQL 의 유저명과 패스워드
4.4.3. 권한의 변경은 언제 반영될까
4.4.4. MySQL 권한의 초기설정
4.4.5. MySQL 에의 신규 유저의 추가
4.4.6. MySQL 유저의 삭제
4.4.7. 유저 자원의 제한
4.4.8. 패스워드의 설정
4.4.9. 패스워드의 시큐러티
4.4.10. 안전한 접속의 사용
4.5. 장해의 예방과 리커버리
4.5.1. 데이타베이스의 백업
4.5.2. BACKUP TABLE 구문
4.5.3. RESTORE TABLE 구문
4.5.4. CHECK TABLE 구문
4.5.5. REPAIR TABLE 구문
4.5.6. myisamchk (을)를 사용한 테이블의 보수와 크래쉬의 리커버리
4.5.7. 테이블 보수 계획
4.5.8. 테이블 정보의 취득
4.6. 데이타베이스 관리 언어 레퍼런스
4.6.1. OPTIMIZE TABLE 구문
4.6.2. ANALYZE TABLE 구문
4.6.3. CHECKSUM TABLE 구문
4.6.4. FLUSH 구문
4.6.5. RESET 구문
4.6.6. PURGE MASTER LOGS 구문
4.6.7. KILL 구문
4.6.8. SHOW 구문
4.7. MySQL 의 로컬라이즈와 국제적인 사용
4.7.1. 데이터 및 소트용 캐릭터 세트
4.7.2. 영어 이외의 에러 메세지
4.7.3. 새로운 캐릭터 세트의 추가
4.7.4. 캐릭터 정의 배열
4.7.5. 문자열 조합 서포트
4.7.6. 멀티 바이트 문자 서포트
4.7.7. 캐릭터 세트에 관한 문제
4.8. MySQL 서버 사이드의 스크립트와 유틸리티
4.8.1. 서버 사이드의 스크립트와 유틸리티의 개요
4.8.2. mysqld_safe (mysqld 의 나팔)
4.8.3. mysqld_multi (복수의 MySQL 서버를 관리하는 프로그램)
4.8.4. myisampack (MySQL 압축 독해 전용 테이블 제네레이터)
4.8.5. mysqld-max (확장 mysqld 서버)
4.9. MySQL 클라이언트 사이드의 스크립트와 유틸리티
4.9.1. 클라이언트 사이드의 스크립트와 유틸리티의 개요
4.9.2. mysql (커멘드 라인 툴)
4.9.3. mysqlcc (MySQL 컨트롤 센터)
4.9.4. mysqladmin (MySQL 서버의 관리)
4.9.5. mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)
4.9.6. mysqlcheck (을)를 사용한 테이블의 보수와 크래쉬의 리커버리
4.9.7. mysqldump (테이블 구조와 데이터의 덤프)
4.9.8. mysqlhotcopy (MySQL 의 데이타베이스와 테이블의 카피)
4.9.9. mysqlimport (텍스트 파일로부터의 데이터의 임포트)
4.9.10. mysqlshow (데이타베이스, 테이블, 및 컬럼의 표시)
4.9.11. mysql_config (클라이언트를 컴파일하기 위한 컴파일 옵션의 취득)
4.9.12. perror (에러 코드의 설명)
4.9.13. 텍스트 파일로부터 SQL 커멘드를 실행하는 방법
4.10. MySQL 로그 파일
4.10.1. 에러 로그
4.10.2. 일반 쿼리 로그
4.10.3. 갱신 로그
4.10.4. 바이너리 로그
4.10.5. 슬로우 쿼리 로그
4.10.6. 로그 파일의 보수
4.11. MySQL 의 replication
4.11.1. 처음에
4.11.2. replication 실장의 개요
4.11.3. replication의 실장의 상세
4.11.4. replication의 셋업 방법
4.11.5. replication 기능과 기존의 문제
4.11.6. replication 스타트 업 옵션
4.11.7. 마스터 서버를 제어한다 SQL 스테이트먼트
4.11.8. 슬레이브 서버를 제어한다 SQL 스테이트먼트
4.11.9. replication FAQ
4.11.10. replication의 트러블 슈팅
4.11.11. replication 버그의 리포트

4.1. MySQL 의 콘피개

4.1.1. mysqld 커멘드 라인 옵션

통상,mysqld 옵션은 옵션 설정 파일로부터 관리해 주세요. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

mysqld (와)과 mysqld.server 하 mysqld 그룹과 server 그룹으로부터 옵션을 읽어들입니다. mysqld_safe 하 mysqld ,server ,mysqld_safe ,safe_mysqld 의 각 그룹으로부터 옵션을 읽어들입니다. 편입 MySQL 서버는 통상,server ,embedded , 및 xxxxx_SERVER (으)로부터 옵션을 읽어들입니다.여기서,xxxxx (은)는 어플리케이션의 이름입니다.

mysqld 에는, 많은 커멘드 라인 옵션이 있습니다.이하, 일반적인 커멘드 라인 옵션에 대해 설명합니다. 완전한 옵션 일람을 참조하려면 ,mysqld --help (을)를 실행해 주세요. replication용의 옵션에 대해서는, 다른 섹션으로 설명합니다. 항4.11.6. 「replication 스타트 업 옵션」 (을)를 참조해 주세요.

  • --ansi

    MySQL 구문이 아니고,SQL-99 구문을 사용한다. See 항1.8.2. 「ANSI 모드로의 MySQL 의 실행」 .

  • -b, --basedir=path

    인스톨 디렉토리의 패스.모든 패스는 통상, 이 패스로부터의 상대 패스로 해결된다.

  • --big-tables

    모든 텐포라리셋트를 파일에 보존하는 것으로써, 큰 결과 세트를 가능하게 한다.이것에 의해 대부분의 'table full' 에러가 해결되지만, 메모리내 테이블만으로 충분하는 쿼리의 실행 속도도 늦어진다.MySQL 버젼 3.23.2 이?~ , 작은 텐포라리테이불의 경우는 메모리를 사용해, 필요에 따라서 자동적으로 디스크 테이블에 바뀌게 되어 있다.

  • --bind-address=IP

    바인드 한다 IP 주소.

  • --console

    --log-error 하지만 지정되어 있는 경우에서도,stderr/stdout 에 에러 로그 메세지를 쓴다.이 옵션을 사용했을 경우,Windows 그럼 mysqld 에 의해 콘솔 화면이 열린 채로 있다.

  • --character-sets-dir=path

    캐릭터 세트가 격납되고 있는 디렉토리. See 항4.7.1. 「데이터 및 소트용 캐릭터 세트」 .

  • --chroot=path

    기동시에 chroot 환경에 mysqld demon를 배치한다.MySQL 4.0 이?~ 의 추천 시큐러티 설정(MySQL 3.23 그럼, 완전하게 닫았다 chroot 형무소를 제공할 수 없다). 다만,LOAD DATA INFILE (와)과 SELECT ... INTO OUTFILE 에 제약이 더해진다.

  • --core-file

    mysqld 하지만 이상종료(ABEND) 했을 경우에, 코어 파일을 작성한다.시스템에 따라서는,mysqld_safe 에 --core-file-size (을)를 지정하는 것도 필요하게 된다. See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 . 주의: --user 옵션도 사용하고 있는 경우,Solaris 등 시스템에서는 코어 파일을 작성할 수 없다.

  • -h, --datadir=path

    데이타베이스 루트의 패스.

  • --debug[...]=

    MySQL (을)를 --with-debug 그리고 콘피개 하고 있는 경우, 이 옵션을 사용해 mysqld 의 동작을 나타내는 트레이스 파일을 취득할 수 있다. See 항E.1.2. 「트레이스 파일의 작성」 .

  • --default-character-set=charset

    디폴트의 캐릭터 세트를 설정한다. See 항4.7.1. 「데이터 및 소트용 캐릭터 세트」 .

  • --default-table-type=type

    디폴트의 테이블형을 설정한다. See 장 7. MySQL 의 테이블형 .

  • --delay-key-write[= OFF | ON | ALL]

    MyISAM 그리고,DELAYED KEYS (을)를 어떻게 사용하는지 지정한다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

  • --delay-key-write-for-all-tables (MySQL 4.0.3 그럼,--delay-key-write=ALL (을)를 사용)

    모든 MyISAM 테이블에 대하고, 기입간의 키 버퍼를 플래시 하지 않는다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

  • --des-key-file=filename

    DES_ENCRYPT() 및 DES_DECRYPT() 하지만 사용하는 디폴트 키를 이 파일로부터 읽어낸다.

  • --enable-external-locking (이전에는 --enable-locking )

    시스템 락을 유효하게 한다.주의: lockd 하지만 완전하게는 기능하지 않는 시스템(Linux 등)으로 이 옵션을 사용하면,mysqld 하지만 데드 록이 될 가능성이 높아진다.

  • --enable-named-pipe

    이름 파이프의 서포트를 유효화한다(Windows NT/2000/XP 마셔).

  • -T, --exit-info

    mysqld 서버의 디버그에 사용할 수 있는, 복수가 다른 플래그의 비트 마스크.완전하게 이해하고 있지 않는 한, 이 옵션은 사용하지 않는 것.

  • --flush

    각 SQL 커멘드 실행 후, 디스크에의 변경을 모두 플래시 한다.통상,MySQL (은)는 각 SQL 커멘드의 뒤, 디스크에의 변경의 기입만을 실시해, 디스크에의 동기 처리는 operating system에 맡긴다. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

  • -?, --help

    쇼트 헬프를 표시해 종료한다.

  • --init-file=file

    기동시에, 이 파일로부터 SQL 커멘드를 읽어낸다.

  • -L, --language=...

    클라이언트 에러 메세지에 사용하는 언어.풀 패스로 지정할 수 있다. See 항4.7.2. 「영어 이외의 에러 메세지」 .

  • -l, --log[=file]

    접속과 쿼리를 로그 파일에 기록한다. See 항4.10.2. 「일반 쿼리 로그」 .

  • --log-bin=[file]

    데이터를 변경하는 쿼리를 모두 로그 파일에 기록한다.백업 및 replication용으로 사용한다. See 항4.10.4. 「바이너리 로그」 .

  • --log-bin-index[=file]

    바이너리 로그 파일명의 인덱스 파일. See 항4.10.4. 「바이너리 로그」 .

  • --log-error[=file]

    에러 메세지 및 스타트 업 메세지를 이 로그 파일에 기록한다. See 항4.10.1. 「에러 로그」 .

  • --log-isam[=file]

    ISAM 및 MyISAM 의 변경을 모두 로그 파일에 기록한다(ISAM 및 MyISAM 의 디버그시만 사용).

  • --log-long-format

    추가 정보를 로그 파일에 기록한다(갱신 로그, 바이너리 갱신 로그, 슬로우 쿼리 로그 등, 유효화 떠날 수 있어 모든 로그).예를 들어, 쿼리의 유저명과 타임 스탬프가 기록된다.--log-slow-queries (와)과 --log-long-format (을)를 사용하고 있는 경우, 인덱스를 사용하지 않는 쿼리도, 슬로우 쿼리 로그에 기록된다. 주의: --log-long-format 하 MySQL 버젼 4.1 그리고 폐?~ 되어--log-short-format 하지만 도입되고 있다(long log format 하지만 버젼 4.1 이?~ 의 디폴트 설정이 되었다).또,MySQL 4.1 (으)로부터, 인덱스를 사용하지 않는 쿼리를 슬로우 쿼리 로그에 기록하기 위한 --log-queries-not-using-indexes 옵션이 이용 가능하게 되어 있다.

  • --log-queries-not-using-indexes

    이 옵션을 --log-slow-queries (와)과 함께 사용하면, 인덱스를 사용하지 않는 쿼리도, 슬로우 쿼리 로그에 기록된다.이 옵션은 MySQL 4.1 그리고 도입되었다. See 항4.10.5. 「슬로우 쿼리 로그」 .

  • --log-short-format

    로그 파일(갱신 로그, 바이너리 갱신 로그, 슬로우 쿼리 로그 등, 유효화 떠날 수 있어 모든 로그)에 기록되는 정보가 적게 된다.예를 들어, 쿼리의 유저명과 타임 스탬프가 기록되지 않게 된다.이 옵션은 MySQL 4.1 그리고 도입.

  • --log-slow-queries[=file]

    실행 시간이 long_query_time 초를 넘은 쿼리를 모두 로그 파일에 기록한다. 주의: 기록되는 디폴트의 정보량은 MySQL 4.1 그리고 변경되었다.상세한 것에 대하여는,--log-long-format 옵션 및 --log-long-format 옵션의 설명을 참조. See 항4.10.5. 「슬로우 쿼리 로그」 .

  • --log-update[=file]

    지정이 없으면, 갱신을 file.# 에 기록한다.# (은)는 일의의 번호. See 항4.10.3. 「갱신 로그」 . 갱신 로그는 MySQL 5.0 그리고 폐?~ 되므로, 대신에 바이너리 로그(--log-bin )(을)를 사용하는 것. See 항4.10.4. 「바이너리 로그」 . 버젼 5.0 에서는,--log-update (을)를 사용하면 단지 바이너리 로그가 유효하게 된다.

  • --low-priority-updates

    테이블 편집 조작(INSERT ,DELETE ,UPDATE )의 우선 순위가 선택보다 낮아진다.{INSERT | REPLACE | UPDATE | DELETE} LOW_PRIORITY ... (을)를 사용해 1 개의 쿼리만 우선 순위를 낮게 하거나SET LOW_PRIORITY_UPDATES=1 (을)를 사용해 1 개의 스레드내에서의 우선 순위를 변경할 수도 있다. See 항5.3.2. 「테이블 락 관련의 문제」 .

  • --memlock

    메모리내의 mysqld 프로세스를 잠근다.이것은, 사용하고 있는 시스템이 mlockall() 시스템 콜을 서포트하고 있는 경우(Solaris 등)만으로 사용 가능. operating system가 원인으로 mysqld 의 스왑이 발생한다고 하는 문제가 있는 경우, 그 해결에 도움이 된다. 주의: 이 옵션을 사용하려면 , 서버를 root (으)로서 기동하는 것이 필요하게 되지만, 이것은 시큐러티상 바람직하지 않다.

  • --myisam-recover [=option[,option...]]

    옵션은,DEFAULT ,BACKUP ,FORCE , 및 QUICK 의 임의의 편성.이 옵션을 무효로 하려면 , 이것을 명시적으로 "" (으)로 설정한다.이 옵션을 사용하면,mysqld (은)는 테이블을 열 때, 테이블에 크래쉬의 마크가 뒤따르지 않은지, 즉 테이블이 올바르게 닫혀지고 있는지 어떤지를 체크한다 (마지막 옵션은,--skip-external-locking (을)를 사용하고 있는 경우만 유효).테이블에 크래쉬 마크가 뒤따르고 있었을 경우,mysqld (은)는 테이블을 체크한다.테이블이 파손하고 있었을 경우,mysqld (은)는 수복을 시도한다.

    이하의 옵션에 의해, 수복 방법이 결정된다.

    옵션 | 설명
    DEFAULT | --myisam-recover 그리고 어느 옵션도 지정하지 않는 것과 같다.
    BACKUP | 수복시에 데이터 테이블이 변경되었을 경우,table_name.MYD 데이터 파일의 백업을 table_name-datetime.BAK (으)로서 보존한다.
    FORCE | .MYD 파일로부터 복수의 레코드가 없어지는 경우에서도 수복을 실행한다.
    QUICK | 삭제 블록이 없는 경우, 테이블내의 레코드를 체크하지 않는다.

    테이블을 자동적으로 수복하기 전에,MySQL (은)는 그것을 에러 로그에 추가한다.유저의 개입없이 거의 모든 문제를 리커버리 할 수 있도록(듯이) 하려면 , 옵션 BACKUP,FORCE (을)를 사용한다.이것에 의해, 몇개의 레코드가 삭제되는 경우에서도 테이블의 수복을 하지만, 낡은 데이터 파일이 백업으로서 남으므로 다음에 조사할 수 있다.

  • --new

    버젼 4.0.12 (으)로부터 사용 가능해진 옵션.--new 옵션을 사용하면, 특정의 국면에서 서버를 4.1 (와)과 같이 동작시킬 수 있어 간단하게 4.0 (으)로부터 4.1 에 업그레이드 할 수 있다.

    • TIMESTAMP 하지만,'YYYY-MM-DD HH:MM:SS' 형식의 문자열로서 돌아간다. See 항6.2. 「컬럼형」 .

  • --pid-file=path

    mysqld_safe 에 의해서 사용된다 PID 파일의 패스.

  • -P, --port=...

    TCP/IP 접속을 릿슨 하는 포토 번호.

  • -o, --old-protocol

    매우 낡은 클라이언트와의 호환성을 위해서 3.20 프로토콜을 사용한다. See 항2.5.5. 「버젼 3.20 (으)로부터 3.21 에의 업그레이드」 .

  • --one-thread

    1 스레드만 사용한다(Linux (으)로의 디버그용). 이 옵션은, 서버의 디버그가 유효하게 되어 있는 경우만 사용 가능. See 항E.1. 「MySQL 서버의 디버그」 .

  • --open-files-limit=

    mysqld 그리고 사용 가능한 파일 기술자의 수를 변경할 수 있다. 이것이 설정되어 있지 않은지, 또는 0 (으)로 설정되어 있는 경우,mysqld (은)는,setrlimit() 그리고 사용하는 값을 사용해 파일 기술자를 예약한다.이 값이 0 의 경우,mysqld 하 max_connections*5 또는 max_connections + table_cache*2 의 언젠가 큰 값을 파일 수라고 해 예약한다.mysqld 그리고 ' Too many open files ' 의 에러가 나오는 경우, 이 값을 크게 한다.

  • -O, --set-variable=name=value

    변수에 값을 설정한다.--help 에 의해 변수 일람을 표시할 수 있다.모든 변수의 상세한 것에 대하여는, 이 메뉴얼의 SHOW VARIABLES 섹션을 참조. See 항4.6.8.4. 「SHOW VARIABLES 」 . 이것들 변수를 최적화하는 방법에 대해서는, 「서버 파라미터의 튜닝」섹션을 참조. 주의: --set-variable= 변수명= 치 및 -O 변수명= 치 구문은,MySQL 4.0 그리고 폐?~ .대신에 -- 변수명= 치 (을)를 사용하는 것. See 항5.5.2. 「서버 파라미터의 튜닝」 .

    MySQL 4.0.2 그럼 변수를 -- 변수명= 치 그리고 직접 설정할 수 있으므로,set-variable (은)는 필요없게 되었다.

    SET 그리고 설정 가능한 스타트 업 옵션의 최대치를 제한하려면 ,--maximum-variable-name 커멘드 라인 옵션을 사용해 정의한다. See 항5.5.6. 「SET 구문」 .

    주의: 변수에 값을 설정하면, 그 값이 설정 가능 범위에 들어가도록(듯이), 또 사용 알고리즘에 맞듯이 자동적으로 변수치가 수정된다.

  • --safe-mode

    몇개의 최적화 스테이지를 스킵 한다.

  • --safe-show-database

    이 옵션을 사용해 SHOW DATABASES 커멘드를 실행하면, 그 유저가 어떠한 권한을 가지고 있는 데이타베이스만이 반환값으로서 돌아간다. 버젼 4.0.2 (으)로부터 모든 유저가 SHOW DATABASES 권한을 가지게 되었으므로, 이 옵션은 폐?~ 되어 아무것도 하지 않는다(이 옵션은 디폴트로 유효). See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

  • --safe-user-create

    이것을 유효하게 했을 경우, 유저에게 mysql.user 테이블 혹은 그 테이블내의 컬럼에게의 INSERT 권한이 없으면, 그 유저는 GRANT 커멘드를 사용해 신규 유저를 작성할 수 없다.

  • --skip-bdb

    BDB 테이블의 사용을 무효로 한다.메모리의 절약 및 연산 처리의 스피드업에 도움이 된다.

  • --skip-concurrent-insert

    MyISAM 테이블로 SELECT (와)과 INSERT (을)를 동시에 실행할 수 없게 한다(이것은, 이 기능에 버그가 있다고 생각되는 경우만 사용하는 것).

  • --skip-delay-key-write

    MySQL 4.0.3 그럼, 대신에 --delay-key-write=OFF (을)를 사용한다. 모든 테이블의 DELAY_KEY_WRITE 옵션을 무시한다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

  • --skip-grant-tables

    서버가 일절의 권한 시스템을 사용하지 않게 한다.이것에 의해 모든 사람이, 모든 데이타베이스에 풀 액세스 할 수 있게 된다(실행중의 서버에 권한 테이블을 다시 사용시키려면 ,mysqladmin flush-privileges 또는 mysqladmin reload (을)를 실행한다).

  • --skip-host-cache

    IP 에의 이름 해석에, 호스트명 캐쉬를 사용하지 않고, 접속 마다 DNS 서버에 대해 쿼리를 발행한다. See 항5.5.5. 「MySQL 의 DNS 의 사용」 .

  • --skip-innodb

    Innodb 테이블의 사용을 무효로 한다.메모리와 디스크 영역의 절약 및 연산 처리의 스피드업에 도움이 된다.

  • --skip-external-locking (이전에는 --skip-locking )

    시스템 락을 사용하지 않는다.isamchk 또는 myisamchk (을)를 사용하려면 , 서버를 슛다운 할 필요가 있다. See 항1.2.3. 「MySQL 의 안정성」 . 주의: MySQL 버젼 3.23 그럼,REPAIR 및 CHECK (을)를 사용해 MyISAM 테이블을 수복하거나 체크할 수 있다.

  • --skip-name-resolve

    호스트명을 해결하지 않는다.권한 테이블의 Host 컬럼의 값이 모두 IP 주소 또는 localhost 인 것이 필요하다. See 항5.5.5. 「MySQL 의 DNS 의 사용」 .

  • --skip-networking

    TCP 포토를 일절 릿슨 하지 않는다.mysqld (와)과의 교환은 모두, 이름 파이프 또는 Unix 소켓을 개입시켜 실시할 필요가 있다.로컬로부터의 접속 요구만이 허가되고 있는 시스템에 대하고, 특히 이 옵션이 추천 된다. See 항5.5.5. 「MySQL 의 DNS 의 사용」 .

  • --skip-new

    새로워서 잘못되어 있을 가능성이 있는 루틴을 사용하지 않는다.

  • --skip-symlink

    4.0.13 그리고 폐?~ .대신에 --skip-symbolic-links (을)를 사용하는 것.

  • --symbolic-links, --skip-symbolic-links

    기호 연결의 서포트를 유효 또는 무효로 한다.이 옵션은,Windows (와)과 Unix 그럼 효과가 다르다.

    Windows 그리고 기호 연결을 유효하게 하면, 실제의 디렉토리에의 패스가 포함된다 directory.sym 파일의 작성에 의해, 데이타베이스 디렉토리에의 기호 연결을 작성할 수 있게 된다. See 항5.6.1.3. 「Windows 위의 데이타베이스에 대한 기호 연결의 사용」 .

    Unix 그리고 기호 연결을 유효하게 하면,CREATE TABLE 스테이트먼트의 INDEX DIRECTORY 옵션 또는 DATA DIRECTORY 옵션으로 MyISAM 의 인덱스 파일 또는 데이터 파일을 별디렉토리에 링크할 수 있게 된다.테이블을 삭제하거나 이름을 변경하면, 그 기호 연결이 포인트 하는 파일도 삭제 또는 이름 변경된다.

  • --skip-safemalloc

    MySQL (을)를 --with-debug=full 그리고 콘피개 하고 있으면, 모든 프로그램이, 메모리의 할당시와 해방시에 반드시 메모리의 오버 런을 체크한다.이 체크에는 시간이 걸리기 위해, 이 체크를 실시하지 않고 끝나는 서버에 대해서는,--skip-safemalloc 옵션에 의해 체크를 스킵 할 수 있다.

  • --skip-show-database

    유저가 SHOW DATABASES 권한을 가지고 있지 않은 경우에,SHOW DATABASES 커멘드를 무효로 한다.

  • --skip-stack-trace

    스택 트레이스를 쓰지 않는다.이 옵션은, 디버거로 mysqld (을)를 실행할 경우에 도움이 된다.시스템에 따라서는, 코어 파일을 취득하기 위해서 이 옵션의 사용이 필요한 경우도 있다. See 항E.1. 「MySQL 서버의 디버그」 .

  • --skip-thread-priority

    응답 시간을 짧게하기 위해(때문에), 스레드 우선도의 사용을 무효로 한다.

  • --socket=path

    Unix 그럼, 로컬 접속에 사용하는 소켓 파일(디폴트에서는 /tmp/mysql.sock ). Windows 그럼, 이름 파이프를 사용하는 로컬 접속용 파이프명(디폴트에서는 MySQL ).

  • --sql-mode=value[,value[,value...]]

    옵션치로서 다음의 임의의 편성을 설정할 수 있다. REAL_AS_FLOAT ,PIPES_AS_CONCAT ,ANSI_QUOTES ,IGNORE_SPACE ,ONLY_FULL_GROUP_BY ,NO_UNSIGNED_SUBTRACTION ,NO_AUTO_VALUE_ON_ZERO ,NO_TABLE_OPTIONS ,NO_FIELD_OPTIONS ,NO_KEY_OPTIONS ,NO_DIR_IN_CREATE ,MYSQL323 ,MYSQL40 ,DB2 ,MAXDB ,MSSQL ,ORACLE ,POSTGRESQL , 및 ANSI . 리셋트 하려면 , 값을 공백으로 한다(--sql-mode="" ).

    NO_AUTO_VALUE_ON_ZERO (은)는,AUTO_INCREMENT 컬럼의 처리에 영향을 준다.통상,NULL 또는 0 의 어느쪽이든을 컬럼에 삽입하는 것으로써, 컬럼의 다음의 순서 번호를 생성한다. NO_AUTO_VALUE_ON_ZERO (을)를 지정하면,0 의 이 기능이 억제되기 위해,NULL 만이 다음의 순서 번호를 생성하게 된다.이 모드는,0 하지만 테이블의 AUTO_INCREMENT 컬럼에 보존되고 있는 경우에 도움이 된다(이것은 추천 되고 있는 방법은 아니지만).예를 들어,mysqldump 그리고 테이블을 덤프 하고 나서 재독 봐 경우,MySQL (은)는 통상,0 값에 조우했을 때에 신규 순서 번호를 생성하기 위해(때문에), 덤프 된 테이블과 재독 봐 테이블의 내용이 다른 결과가 된다.이 경우, 덤프 한 파일을 재독 봐 전에 NO_AUTO_VALUE_ON_ZERO (을)를 유효하게 하는 곳의 문제가 해결한다(이 옵션이 사용 가능하게 되었다 MySQL 4.1.1 이?~ ,mysqldump 에 의한 덤프 출력에는, 자동적으로 NO_AUTO_VALUE_ON_ZERO (을)를 유효하게하기 위한 스테이트먼트가 포함되어 있다).

    다른 서버와의 호환성을 위해서 사용하는 옵션치도 있다. 이것들을 지정하는 것으로써,SHOW CREATE TABLE 의 실행 결과로부터, 이전의 버젼의 MySQL 또는 다른 데이터 베이스 서버를 이해할 수 없는 출력이 제외된다. 이러한 옵션치를 사용하면,CREATE TABLE 스테이트먼트의 다른 서버에의 이식성이 높아진다.

    • NO_TABLE_OPTIONS ,NO_FIELD_OPTIONS ,NO_DIR_IN_CREATE , 및 NO_KEY_OPTIONS (을)를 사용하면, 테이블 옵션이나, 컬럼 또는 인덱스 정의에 관한 옵션이 제외된다.

    • MYSQL323 (와)과 MYSQL40 (은)는,MySQL 3.23 (와)과 MySQL 4.0 (와)과의 호환용.

    • 다른 서버와의 호환성을 유지하기 위한 치는,DB2 ,MAXDB ,MSSQL ,ORACLE , 및 POSTGRESQL .

    mysqldump 하 SHOW CREATE TABLE (을)를 사용하고, 덤프 출력에 포함한 테이블 작성 스테이트먼트를 취득하기 위해(때문에), 이러한 옵션은 mysqldump 의 출력에도 영향을 준다.

    옵션치의 몇개인가는, 값세트 또는 그룹의 약칭이므로, 영향은 복잡하게 된다. 예를 들어,--sql-mode=ANSI (또는 --ansi ) 옵션을 사용하고, 서버에 ANSI 모드로 실행하도록(듯이) 명령할 수 있다.이것은 이하의 커멘드 라인 옵션을 양쪽 모두 지정하는 것과 같다.

    --sql-mode=REAL_AS_FLOAT,PIPES_AS_CONCAT,ANSI_QUOTES,IGNORE_SPACE,ONLY_FULL_GROUP_BY
--transaction-isolation=SERIALIZABLE

    주의: 이 방법으로 ANSI 모드를 지정하면, 트랜잭션(transaction) 분리 레벨을 설정하게도 된다. ANSI 모드로의 서버의 실행에 대해서는, 항1.8.2. 「ANSI 모드로의 MySQL 의 실행」 (을)를 참조.

    다른 `` 그룹'' 값은,DB2 ,MAXDB ,MSSQL ,ORACLE , 및 POSTGRESQL . 이러한 어느 값을 지정해도,PIPES_AS_CONCAT ,ANSI_QUOTES ,IGNORE_SPACE ,NO_TABLE_OPTIONS ,NO_FIELD_OPTIONS , 및 NO_KEY_OPTIONS 값이 유효하게 된다.

    --sql-mode 옵션은 MySQL 3.23.41 그리고 추가되었다. NO_UNSIGNED_SUBTRACTION 값은 4.0.0 그리고 추가되었다. NO_DIR_IN_CREATE 하 4.0.15 그리고 추가되었다. NO_AUTO_VALUE_ON_ZERO ,NO_TABLE_OPTIONS ,NO_FIELD_OPTIONS ,NO_KEY_OPTIONS ,MYSQL323 ,MYSQL40 ,DB2 ,MAXDB ,MSSQL ,ORACLE ,POSTGRESQL , 및 ANSI 하 4.1.1 그리고 추가되었다.

  • --temp-pool

    이 옵션을 사용하면, 서버에 의해서 작성되는 대부분의 임시 파일이, 각각 일의의 이름이 아니고, 작은 이름세트를 사용한다.이것은, 많은 신규 파일이 다른 이름으로 작성되어 그것을 Linux 커넬이 처리하는 문제를 회피하기 위해(때문에)이다.Linux 그럼, 메모리가 디스크 캐쉬 프로그램이 아니고, 디렉토리 엔트리 캐쉬에 할당할 수 있기 위해, 이전의 동작에서는 메모리의 `` 리크'' 하지만 발생하기 쉽다.

  • --transaction-isolation={ READ-UNCOMMITTED | READ-COMMITTED | REPEATABLE-READ | SERIALIZABLE }

    디폴트의 트랜잭션(transaction) 분리 레벨을 설정한다. See 항6.7.6. 「SET TRANSACTION 구문」 .

  • -t, --tmpdir=path

    임시 파일의 작성에 사용되는 디렉토리의 패스.임시 파일을 보존하려면 너무 작은 파티션상에 디폴트의 /tmp 디렉토리가 있는 경우, 이 옵션이 도움이 된다. MySQL 4.1 이?~ , 복수의 패스의 지정이 가능하게 되어 있다.이러한 패스는 라운드로빈 방식으로 사용된다.Unix 그럼 코론(‘: ＇)(을)를,Windows 그럼 세?~ 코론(‘; ＇)(을)를 사용하고 패스를 단락짓는다. 메모리베이스의 파일 시스템을 가리키도록(듯이) tmpdir (을)를 설정하는 것은 가능.다만,MySQL 서버가 슬레이브의 경우는 할 수 없다.슬레이브의 경우, 머신이 리부트해도 텐포라리테이불의 replication 또는 LOAD DATA INFILE 의 replication 처리를 속행하기 위한 임시 파일이 필요하다.그 때문에, 머신의 리부트로 소거되는 메모리베이스의 tmpdir (은)는 적합하지 않는다.디스크 베이스의 tmpdir 하지만 필요.

  • -u, --user={user_name | user_id}

    mysqld 서버를, 유저명 user_name 또는 유저 ID user_id (을)를 가지는 유저로서 실행한다 (여기서의 `` 유저'' (은)는, 권한 테이블에 리스트 되었다 MySQL 유저가 아니고, 시스템 로그인어카운트를 가리킨다).

    이 옵션은,mysqld (을)를 root 어카운트로 기동하는 경우, 필수 이다. 기동 순서중에 서버가 그 유저 ID (을)를 변경해,root (이)가 아니고, 그 특정의 유저로서 실행한다. See 항4.3.2. 「MySQL 의 크래커 대책」 .

    MySQL 3.23.56 및 4.0.12 이?~ 그럼, 유저가 --user=root 옵션을 my.cnf 파일에 추가한다고 한다(결과, 서버는 root (으)로서 가동) 시큐러티 홀을 회피하기 위해(때문에),mysqld (은)는 지정된 최초의 --user 옵션만을 사용해, 복수의 --user 옵션이 있었을 경우는 경고를 출력한다./etc/my.cnf 및 datadir/my.cnf 안의 옵션은, 커멘드 라인 옵션의 전에 처리되기 위해,--user 옵션을 /etc/my.cnf 에 포함해 root 이외의 값을 지정하는 것을 추천 한다./etc/my.cnf 안의 옵션은 다른 --user 옵션에서 먼저 검출되어 서버는 확실히 root 이외의 유저로서 실행되어 다른 --user 옵션이 검출된다고 경고가 출력된다.

  • -V, --version

    버젼 정보를 표시해 종료한다.

  • -W, --log-warnings

    Aborted connection... 등의 경고를 .err 파일에 출력한다.replication를 사용하는 경우는, 이 옵션을 유효하게 하는 것을 추천 한다(네트워크 에러나 재접속에 관한 메세지 등, 현재무엇이 일어나고 있을까에 대한 정보를 보다 많이 취득할 수 있다). See 항A.2.10. 「통신 에러/Aborted connection 」 .

    이 옵션은 이전의 --warnings .

실행중의 서버에 대해서, 대부분의 값을 SET 커멘드로 변경할 수 있습니다. See 항5.5.6. 「SET 구문」 .

4.1.2. my.cnf 옵션 설정 파일

MySQL 그럼 버젼 3.22 이?~ , 서버와 클라이언트의 디폴트 스타트 업 옵션을 옵션 설정 파일로부터 읽어낼 수 있게 되어 있습니다.

Windows 그럼,MySQL (은)는 디폴트 옵션을 이하의 파일로부터 읽어냅니다.

파일명 | 용도
windows-directory\my.ini | 글로벌 옵션
C:\my.cnf | 글로벌 옵션

windows-directory 하 Windows 디렉토리의 보존 장소입니다.

Unix 그럼,MySQL (은)는 디폴트 옵션을 이하의 파일로부터 읽어냅니다.

파일명 | 용도
/etc/my.cnf | 글로벌 옵션
DATADIR/my.cnf | 서버 고유 옵션
defaults-extra-file | --defaults-extra-file=path 그리고 지정된 파일
~/.my.cnf | 유저 고유 옵션

DATADIR 하 MySQL 데이터 디렉토리입니다(통상, 바이너리 인스톨의 경우는 /usr/local/mysql/data , 소스 인스톨의 경우는 /usr/local/var ). 주의: 이것은, 콘피개시로 지정된 디렉토리입니다.mysqld 기동시에 --datadir 그리고 지정한 디렉토리가 아닙니다.서버는 커멘드 라인의 인수를 처리하기 전에 옵션 설정 파일을 찾기 위해,--datadir 에 의한 지정은, 서버가 옵션 설정 파일을 찾는 장소에 영향을 주지 않습니다.

주의: Windows 그럼, 옵션 설정 파일내의 모든 패스를 ‘\ ＇ (이)가 아니고,‘/ ＇ 그리고 지정해 주세요.‘\ ＇ 하 MySQL 의 이스케이프 문자이기 위해,‘\ ＇ (을)를 사용하는 경우는 2 회지정할 필요가 있습니다.

MySQL (은)는, 옵션 설정 파일을 상기의 순서로 읽어내려고 합니다.복수의 옵션 설정 파일이 존재하는 경우, 다음에 읽어내진 파일로 지정되어 있는 옵션이, 먼저 읽어내진 파일내의 동일 옵션에서 우선됩니다.커멘드 라인으로 지정된 옵션은, 옵션 설정 파일로 지정된 옵션보다 우선됩니다.옵션에 따라서는, 환경 변수를 사용하고 지정할 수 있는 것도 있습니다. 커멘드 라인 또는 옵션 설정 파일로 지정된 옵션이, 환경 변수치보다 우선됩니다. See 부록 F. 환경 변수 .

옵션 설정 파일을 서포트하는 프로그램은,mysql ,mysqladmin ,mysqld ,mysqld_safe ,mysql.server ,mysqldump ,mysqlimport ,mysqlshow ,mysqlcheck ,myisamchk , 및 myisampack 입니다.

버젼 4.0.2 보다 ,loose 프리픽스를 커멘드 라인 옵션(또는 my.cnf 의 옵션)에 사용할 수 있습니다.옵션의 전에 loose (을)를 붙이면, 옵션이 미지의 경우에서도, 그것을 읽어낸 프로그램은 에러 종료하지 않고, 이하의 경고를 출력합니다.

shell> mysql --loose-no-such-option

MySQL 프로그램 실행시에 커멘드 라인으로 지정할 수 있는 긴 옵션은, 옵션 설정 파일로 지정할 수 있습니다(데쉬2 개를 앞에 두고 붙이지 않는다).사용 가능한 옵션의 일람을 표시하려면 ,--help 옵션 첨부로 그 프로그램을 실행해 주세요.

옵션 설정 파일에는, 이하의 형식의 행을 포함할 수 있습니다.

  • #comment

    코멘트행은,‘# ＇ 또는 ‘; ＇ 그리고 시작한다.MySQL 4.0.14 보다 , 코멘트를 행의 도중부터에서도 개시할 수 있게 되었다.공백행은 무시된다.

  • [group]

    group (은)는, 옵션을 설정하는 프로그램 또는 그룹의 이름.그룹행의 뒤의 option 행 또는 set-variable 행은 모두 그 그룹에 적용된다.이것은, 옵션 설정 파일의 최후, 또는 다른 그룹행이 지정될 때까지 유효.

  • option

    이것은, 커멘드 라인의 --option (와)과 동등.

  • option=value

    이것은, 커멘드 라인의 --option=value (와)과 동등.주의: 옵션의 인수에 코멘트 문자가 포함되는 경우, 인수를 이중 인용부호로 둘러쌀 필요가 있다.

  • set-variable = name=value

    이것은, 커멘드 라인의 --set-variable=name=value (와)과 동등. 주의: --set-variable 하 MySQL 4.0 그리고 폐?~ 되었다.MySQL 4.0 그럼, 프로그램 변수명을 옵션명으로서 사용할 수 있다.커멘드 라인에서는,--name=value (을)를 사용한다.옵션 설정 파일에서는,name=value (을)를 사용한다.

[client] 그룹에 의해, 모든 MySQL 클라이언트(mysqld (은)는 아니고)에 적용되는 옵션을 지정할 수 있습니다.이것은, 서버에 접속할 때에 사용하는 패스워드를 지정하기 위한 이상적인 그룹입니다(다만, 관리자 이외의 유저가 옵션 설정 파일을 읽고 쓰기할 수 없게 해 주세요).

특정의 버젼의 mysqld 서버만이 읽어낼 수 있는 옵션을 작성하려면 ,[mysqld-4.0] ,[mysqld-4.1] 등을 사용합니다.

[mysqld-4.0]
new

상기의 new 옵션은,MySQL 서버 버젼 4.0.x 에서만 사용됩니다.

주의: 옵션 및 값에 대해서, 그 전후에 있는 공백은 자동적으로 삭제됩니다.escape sequence '\b' ,'\t' ,'\n' ,'\r' ,'\\' , 및 '\s' (을)를 값문자열에 사용할 수 있습니다('\s' == blank ).

다음에, 일반적인 글로벌 옵션 설정 파일의 예를 나타냅니다.

[client]
port=3306
socket=/tmp/mysql.sock

[mysqld]
port=3306
socket=/tmp/mysql.sock
set-variable = key_buffer_size=16M
set-variable = max_allowed_packet=1M

[mysqldump]
quick

다음에, 일반적인 유저 옵션 설정 파일의 예를 나타냅니다.

[client]
#
이하의 패스워드는, 표준의 MySQL
클라이언트 모두에 사용됩니다
password="my_password"

[mysql]
no-auto-rehash
set-variable = connect_timeout=2

[mysqlhotcopy]
interactive-timeout

소스 디스트리뷰션이 있으면,my-xxxx.cnf (이)라는 이름의 설정 파일의 샘플이 support-files 디렉토리에 포함되어 있습니다. 바이너리 디스트리뷰션의 경우는,DIR/support-files 디렉토리에 있습니다.여기서,DIR 하 MySQL 인스톨 디렉토리의 패스입니다(통상,C:\mysql 또는 /usr/local/mysql ).현재, 소, 나카, 다이, 및 특대 시스템용의 샘플 설정 파일이 준비되어 있습니다.my-xxxx.cnf (을)를 자신의 홈 디렉토리에 카피하고, 이름을 .my.cnf (으)로 변경해, 이 파일을 사용해 보세요.

옵션 설정 파일을 서포트한다 MySQL 프로그램은 모두, 이하의 옵션을 서포트합니다.

옵션 | 설명
--no-defaults | 옵션 설정 파일을 일절 읽어내지 않는다.
--print-defaults | 프로그램명과 취득하는 모든 옵션을 출력한다.
--defaults-file=full-path-to-default-file | 지정된 설정 파일만을 사용한다.
--defaults-extra-file=full-path-to-default-file | 글로벌 설정 파일을 읽어낸 후, 유저 설정 파일의 전에 이 설정 파일을 읽어낸다.

주의: 이러한 옵션은, 커멘드행의 최초로 둘 필요가 있습니다.다만,--print-defaults 만일 수 있는은,--defaults-file 또는 --defaults-extra-file 의 직후에 둘 수 있습니다.

개발자를 위한 주의: 옵션 설정 파일의 처리로서는, 커멘드 라인 인수를 처리하기 전에, 옵션 설정 파일내의 모든 합치하는 옵션(해당 그룹의 옵션)이 처리되게 되어 있습니다.여러 차례 지정되어 있는 옵션의 마지막 인스턴스를 사용하는 프로그램에 있어서는, 이 처리로 문제 없습니다.여러 차례 지정되어 있는 옵션을 처리하지만, 옵션 설정 파일은 읽어내지 않는 구식의 프로그램에 대해서는,2 행 추가하는 것만으로 그 기능을 장비할 수 있습니다. 그방법에 대해서는, 표준 MySQL 클라이언트의 몇개의 원시 코드를 확인해 주세요.

셸 스크립트로,my_print_defaults 커멘드를 사용해 옵션 설정 파일을 해석할 수 있습니다.이하의 예는,[client] 그룹과 [mysql] 그룹에 속하는 옵션의 표시 요구가 있었을 경우에,my_print_defaults 하지만 생성할 가능성이 있는 출력입니다.

shell> my_print_defaults client mysql
--port=3306
--socket=/tmp/mysql.sock
--no-auto-rehash


4.2. 같은 머신상에서 복수의 MySQL 서버를 실행한다

경우에 따라서는, 같은 머신상에서 복수의 mysqld 서버를 실행하는 것이 필요하게 됩니다.예를 들어, 기존의 가동 환경대로 하고, 새롭다 MySQL 릴리스를 테스트하고 싶은 경우를 생각할 수 있습니다. 또, 유저 마다 다르다 mysqld 서버에의 액세스권을 주는 경우 등도 있습니다(예를 들어, 고객 마다 독립했다 MySQL 인스톨을 제공하는 인터넷 서비스 프로바이더 등).

단일의 머신상에서 복수의 서버를 실행하려면 , 몇개의 파라미터로 서버 고유의 값을 설정할 필요가 있습니다.이것들은 커멘드 라인 또는 옵션 설정 파일로 설정할 수 있습니다. 항4.1.1. 「mysqld 커멘드 라인 옵션」 및 항4.1.2. 「my.cnf 옵션 설정 파일」 (을)를 참조해 주세요.

적어도 이하의 옵션은 서버 마다 다릅니다.

  • --port=port_num

  • --socket=path

  • --shared-memory-base-name=name (Windows 마셔,MySQL 4.1 그리고 도입)

  • --pid-file=path (Unix 마셔)

--port (은)는,TCP/IP 접속의 포토 번호를 제어합니다. --socket (은)는,Unix 그럼 소켓 파일 패스를,Windows 그럼 이름 파이프의 이름을 제어합니다(이름 파이프 접속을 서포트하고 있는 서버 에 대해서만,Windows 위에서 일의의 파이프명을 지정할 필요가 있습니다). --shared-memory-base-name (은)는,Windows 서버가 사용하는 공유 메모리명을 지정합니다.이것에 의해, 클라이언트는 그 공유 메모리를 개입시키고 접속할 수 있게 됩니다. --pid-file (은)는,Unix 서버가 프로세스 ID (을)를 쓰는 파일의 이름을 나타냅니다.

이하의 옵션을 사용하는 경우, 서버 마다 다른 값을 설정할 필요가 있습니다.

  • --log=path

  • --log-bin=path

  • --log-update=path

  • --log-error=path

  • --log-isam=path

  • --bdb-logdir=path

퍼포먼스를 높이려면 , 이하의 옵션을 서버 마다 개별적으로 설정해, 부하를 복수의 디스크에 분산합니다.

  • --tmpdir=path

  • --bdb-tmpdir=path

복수의 텐포라리디레크트리를 상기와 같이 설정해, 어느 MySQL 서버에 어느 임시 파일이 속하는지 알기 쉽게 해 두는 것을 추천 합니다.

일반적으로, 데이터 디렉토리에 대해서도, 각 서버가 다른 디렉토리를 사용하도록(듯이) 합니다.이것은 --datadir=path 옵션으로 지정합니다.

경고: 2 개의 서버로부터 같은 데이타베이스의 데이터를 갱신하지 않게 해 주세요.사용하고 있는 operating system가 장해로부터의 보호를 행하는 시스템 락을 서포트하고 있지 않는 경우, 예기치 않은 사태가 발생할 가능성이 있습니다.또, 복수의 서버가 같은 데이터 디렉토리를 사용해, 로그가 유효하게 되어 있는 경우, 적절한 옵션을 사용해 각 서버에 다른 로그 파일명을 지정할 필요가 있습니다.그렇게 하지 않으면 서버는 같은 파일에 로그 해 버립니다.

서버간으로의 데이터 디렉토리 공유에 관한 이 경고는,NFS 환경에도 들어맞읍니다.NFS 환경에서 복수의 MySQL 서버에 같은 데이터 디렉토리에의 액세스를 인정하는 것은 피해 주세요 .

  • 주요한 문제는,NFS 하지만 속도의 보틀 넥이 되는 것. NFS (은)는 그러한 사용을 고려하고 있지 않다.

  • 2 개이상의 서버가 서로 간섭하지 않게 하는 일도 곤란.통상,NFS 파일 락은 lockd demon에 의해서 처리되지만, 현재로서는, 어떠한 상황에서도 100% 의 신뢰성으로 락을 실행할 수 있는 플랫폼은 존재하지 않는다.

간단한 방법을 선택해 주세요.NFS 그리고 복수의 서버에 데이터 디렉토리를 공유시키는 아이디어는 좋은 아이디어가 아닙니다. 또, 복수의 CPU (을)를 가진다 1 받침대의 컴퓨터를 준비해, 스레드를 효율적으로 처리하는 operating system를 사용하는 것을 추천 합니다.

복수의 MySQL 인스톨을 다른 로케이션으로 실시하는 경우,--basedir=path 옵션을 사용해 각 서버에 대해서 베이스 디렉토리를 지정해, 각 서버가 각각 다른 데이터 디렉토리, 로그 파일, 및 PID 파일을 사용하도록 할 수 있습니다(이러한 값의 디폴트는, 베이스 디렉토리에 대립되어 결정됩니다).그 경우, 그 밖에 지정할 필요가 있는 옵션은 --socket (와)과 --port 뿐입니다.예를 들어,.tar 파일 바이너리 디스트리뷰션을 사용해 MySQL 의 복수의 버젼을 인스톨 한다고 합니다.이것들은 다른 로케이션에 인스톨 되므로, 대응하는 베이스 디렉토리 이하로 ./bin/mysqld_safe 커멘드를 사용하고, 각 인스톨의 서버를 기동할 수 있습니다. mysqld_safe 하지만,mysqld 에 건네주는 적절한 --basedir 옵션을 특정하므로,--socket 옵션과 --port 옵션을 mysqld_safe (으)로 설정하는 것만으로 끝납니다.

이하의 섹션으로 설명하도록(듯이), 환경 변수의 설정 또는 적절한 커멘드 라인 옵션의 지정에 의해, 추가 서버를 기동하는 것이 가능합니다.다만, 보다 영속적으로 복수의 서버를 실행할 필요가 있는 경우에는, 옵션 설정 파일을 사용해 각 서버 고유의 옵션치를 지정하는 방법이 편리합니다.

4.2.1. Windows 위에서 복수의 서버를 실행한다

적절한 파라미터를 사용해, 커멘드 라인으로부터 서버를 수동으로 기동하는 것으로써,Windows 위에서 복수의 서버를 실행할 수 있습니다.Windows NT 베이스의 시스템에서는, 복수의 서버를 Windows 서비스로서 인스톨 해,Windows 서비스로서 실행하는 방법도 있습니다.커멘드 라인으로부터, 또는 서비스로서 MySQL 서버를 실행하는 방법에 대한 일반적인 설명은, 항2.6.1. 「Windows 의 주의 사항」 에 기재되어 있습니다.이 섹션에서는, 데이터 디렉토리 등, 서버 고유하다라고 하는 것이 필요한 스타트 업 옵션치를 서버 마다 설정해 서버를 기동하는 방법에 대해 설명합니다(이러한 옵션에 대해서는, 항4.2. 「같은 머신상에서 복수의 MySQL 서버를 실행한다」 (을)를 참조해 주세요).

4.2.1.1. 커멘드 라인으로부터 복수의 Windows 서버를 기동한다

커멘드 라인으로부터 수동으로 복수의 서버를 기동하려면 , 커멘드 라인 또는 옵션 설정 파일로 필요한 옵션을 지정합니다.옵션 설정 파일로 옵션을 설정하는 것이 편리합니다만, 각 서버에 독자적인 옵션 세트를 확실히 설정할 필요가 있습니다.이것을 실시하려면 각 서버용의 옵션 설정 파일을 작성해, 서버 기동시에 --defaults-file (을)를 사용해 그 서버에 파일명을 지정합니다.

예를 들어,mysqld (을)를, 데이터 디렉토리 C:\mydata1 (을)를 사용해 포토 3307 그리고 실행해,mysqld-max (을)를, 데이터 디렉토리 C:\mydata2 (을)를 사용해 포토 3308 그리고 실행한다고 합니다.이 때문에는,2 개의 옵션 설정 파일을 작성합니다.예를 들어, 이하와 같은 C:\my-opts1.cnf 파일을 작성합니다.

[mysqld]
datadir = C:/mydata1
port = 3307

다음에, 이하와 같은 2 번째의 파일 C:\my-opts2.cnf (을)를 작성합니다.

[mysqld]
datadir = C:/mydata2
port = 3308

그리고, 각각의 옵션 설정 파일을 사용해 각 서버를 기동합니다.

shell> mysqld --defaults-file=C:\my-opts1.cnf
shell> mysqld-max --defaults-file=C:\my-opts2.cnf

Windows NT 그럼, 서버가 foreground로 기동하기 위해(때문에),2 개의 커멘드를 다른 콘솔 윈도우로 실행할 필요가 있습니다.

서버를 슛다운 하려면 , 해당하는 포토 번호에 접속할 필요가 있습니다.

shell> mysqladmin --port=3307 shutdown
shell> mysqladmin --port=3308 shutdown

이 예의 같게 설정되어 있는 서버는, 클라이언트에 대해서 TCP/IP 접속을 허가합니다.이름 파이프 접속도 가능하게 하려면 ,mysqld-nt 서버 또는 mysqld-max-nt 서버를 사용해, 이름 파이프를 유효하게 하는 옵션을 지정해, 그 이름을 지정합니다(이름 파이프 접속을 서포트하는 서버는, 각각 고유의 파이프명을 사용하는 것이 필요합니다).예를 들어,C:\my-opts1.cnf 파일을 이하와 같이 수정합니다.

[mysqld]
datadir = C:/mydata1
port = 3307
enable-named-pipe
socket = mypipe1

그리고, 서버를 다음과 같이 기동합니다.

shell> mysqld-nt --defaults-file=C:\my-opts1.cnf

2 번째의 서버로 사용한다 C:\my-opts2.cnf 도 이와 같이 수정합니다.

4.2.1.2. 복수의 Windows 서버를 서비스로서 기동한다

Windows NT 베이스의 시스템에서는,MySQL 서버를 Windows 서비스로서 실행할 수 있습니다.단일의 MySQL 서비스의 인스톨, 제어, 및 삭제의 순서에 대해서는, 항2.1.1.7. 「Windows NT ,2000 , 또는 XP (으)로의 MySQL 의 기동」 (을)를 참조해 주세요.

MySQL 4.0.2 보다 , 복수의 서버를 서비스로서 인스톨 할 수 있게 되어 있습니다. 그 경우, 각 서버가 다른 서비스명을 사용하는 것이 필요합니다.또, 서버 마다 일의인 것이 필요한 그 외의 파라미터에도 주의가 필요합니다.

이하의 순서는,C:\mysql-4.0.8 및 C:\mysql-4.0.17 에 인스톨 되었다 2 개가 다르다 MySQL 버젼으로부터 mysqld-nt 서버를 실행하는 경우를 상정하고 있습니다(예를 들어, 본가동 서버로서 4.0.8 (을)를 실행하고 있을 때, 업그레이드전에 4.0.17 (을)를 테스트하는 경우 등).

--install 옵션으로 MySQL 서비스를 인스톨 하는 경우, 이하의 원칙이 들어맞읍니다.

  • 서비스명을 지정하지 않으면 서버는 MySQL 의 디폴트 서비스명을 사용해, 표준 옵션 설정 파일의 [mysqld] 그룹으로부터 옵션을 읽어낸다.

  • --install 옵션의 다음에 서비스명을 지정하면, 서버는 [mysqld] 옵션 그룹을 무시해, 서비스와 같은 이름의 그룹으로부터 옵션을 읽어낸다.서버는, 표준 옵션 설정 파일로부터 옵션을 읽어낸다.

  • 서비스명의 뒤에 --defaults-file 옵션을 지정하면, 서버는 표준 옵션 설정 파일을 무시해, 지정 파일의 [mysqld] 그룹으로부터 마셔 옵션을 읽어낸다.

이러한 원칙은,--install-manual 옵션을 사용해 서버를 인스톨 했을 경우에도 들어맞읍니다.

이상의 정보에 근거하고, 복수의 서비스를 셋업 하는 방법은 몇개인가 있습니다. 다음에, 몇개의 예를 나타냅니다.머지않아를 시험하는 경우에서도, 최초로 기존의 MySQL 서비스를 슛다운 해 삭제해 두는 것이 필요합니다.

  • 표준 옵션 설정 파일의 1 개로, 모든 서비스에 옵션을 지정한다. 이것을 실시하는 경우는, 각 서버에 다른 이름을 사용한다. 예를 들어,4.0.8 mysqld-nt (을)를 mysqld1 의 서비스명으로 실행해,4.0.17 mysqld-nt (을)를 mysqld2 의 서비스명으로 실행하는 경우, 4.0.8 에는 [mysqld1] 그룹을,4.0.17 에는 [mysqld2] 그룹을 사용할 수 있다. 예를 들어, 이하와 같이 C:\my.cnf (을)를 셋업 할 수 있다.

    # options for mysqld1 service
[mysqld1]
basedir = C:/mysql-4.0.8
port = 3307
enable-named-pipe
socket = mypipe1

# options for mysqld2 service
[mysqld2]
basedir = C:/mysql-4.0.17
port = 3308
enable-named-pipe
socket = mypipe2

    Windows 하지만 각 서비스용이 올바른 실행 가능 프로그램을 등록할 수 있도록, 서버의 풀 패스명을 지정하고, 이하와 같이 서비스를 인스톨 한다.

    shell> C:\mysql-4.0.8\bin\mysqld-nt --install mysqld1
shell> C:\mysql-4.0.17\bin\mysqld-nt --install mysqld2

    서비스를 개시하려면 , 서비스 매니저를 사용하는지, 적절한 서비스명으로 NET START (을)를 사용한다.

    shell> NET START mysqld1
shell> NET START mysqld2

    서비스를 정?~ 하려면 , 서비스 매니저를 사용하는지, 적절한 서비스명으로 NET STOP (을)를 사용한다.

    shell> NET STOP mysqld1
shell> NET STOP mysqld2

    주의: MySQL 4.0.17 보다 전의 버젼에서는, 디폴트 서비스명(MySQL )(을)를 사용해 인스톨 된 서버인가,mysqld 의 서비스명으로 명시적으로 인스톨 된 서버만이, 표준 옵션 설정 파일의 [mysqld] 그룹을 읽어냅니다.4.0.17 이?~ 그럼, 다른 서비스명을 사용해 인스톨 된 서버에서도, 표준 옵션 설정 파일을 읽어내는 서버이면 모두,[mysqld] 그룹을 읽어냅니다.이것에 의해, 모든 MySQL 서비스에 적용하는 옵션용으로 [mysqld] 그룹을 사용해, 각 서비스의 이름을 붙일 수 있었던 옵션 그룹을, 그 서비스명으로 인스톨 된 서버용으로 사용할 수 있습니다.

  • 개별의 파일로 각 서버에 옵션을 지정해, 서비스의 인스톨시에 --defaults-file (을)를 사용하고, 각 서버에 어느 파일을 사용하는지 지정한다.이 때, 각 파일에 [mysqld] 그룹을 사용해 옵션을 리스트업 하는 것이 필요.

    이 방법으로 4.0.8 mysqld-nt 의 옵션을 지정하려면 , 이하와 같은 C:\my-opts1.cnf 파일을 작성한다.

    [mysqld]
basedir = C:/mysql-4.0.8
port = 3307
enable-named-pipe
socket = mypipe1

    4.0.17 mysqld-nt 에 대해서는, 이하와 같은 C:\my-opts2.cnf 파일을 작성한다.

    [mysqld]
basedir = C:/mysql-4.0.17
port = 3308
enable-named-pipe
socket = mypipe2

    이하와 같이 서비스를 인스톨 한다( 각 커멘드는 1 행으로 입력).

    shell> C:\mysql-4.0.8\bin\mysqld-nt --install mysqld1
           --defaults-file=C:\my-opts1.cnf
shell> C:\mysql-4.0.17\bin\mysqld-nt --install mysqld2
           --defaults-file=C:\my-opts2.cnf

    MySQL 서버를 서비스로서 인스톨 할 때에 --defaults-file 옵션을 사용하려면 , 옵션의 전에 서비스명을 붙일 필요가 있다.

    서비스의 인스톨 후, 기동과 정?~ (은)는 전의 예와 같이 실시한다.

복수의 서비스를 삭제하려면 ,mysqld --remove (을)를 사용해 1 개씩 삭제합니다.삭제하는 서비스가 디폴트명이 아닌 경우는,--remove 옵션의 뒤에 서비스명을 지정합니다.

4.2.2. Unix 위에서 복수의 서버를 실행한다

복수의 서버를 Unix 위에서 실행하는 가장 간단한 방법은, 다르다 TCP/IP 포토와 소켓 파일을 사용하도록(듯이) 해 서버를 컴파일 해, 각각이 다른 네트워크 인터페이스로 접속하도록(듯이) 하는 것입니다.또, 각 인스톨을 다른 베이스 디렉토리에서 컴파일 하는 것으로써, 데이터 디렉토리, 로그 파일, 및 PID 파일의 장소를 서버별로 할 수 있습니다.

기존 서버가 디폴트의 포토 번호와 소켓 파일로 콘피개 되고 있다고 합니다.새로운 서버를 다른 파라미터로 콘피개 하려면 , 이하와 같이 configure 커멘드를 사용합니다.

shell> ./configure --with-tcp-port=port_number \
             --with-unix-socket-path=file_name \
             --prefix=/usr/local/mysql-4.0.17

여기서,port_number (와)과 file_name 에, 디폴트 이외의 포토 번호와 소켓 파일의 패스명을 지정합니다.및,--prefix 의 값도, 기존의 MySQL 인스톨의 장소와는 다른 인스톨 디렉토리를 지정합니다.

MySQL 서버가 특정의 포토 번호를 릿슨 하고 있는 경우, 이하의 커멘드를 사용하고, 베이스 디렉토리나 소켓명 등, 중요한 변수의 값을 확인할 수 있습니다.

shell> mysqladmin --host=host_name --port=port_number variables

이 커멘드로 표시되는 정보에 의해, 추가 서버를 설정할 경우에 어느 옵션치를 사용 해선 안 된다 가가와 빌립니다.

주의: ``localhost'' (을)를 호스트명으로서 지정하면,mysqladmin 하 TCP/IP (이)가 아니고,Unix 소켓 접속을 디폴트 사용합니다. MySQL 4.1 그럼,--protocol={TCP | SOCKET | PIPE | MEMORY} 옵션을 사용하고, 사용하는 접속 프로토콜을 명시적으로 지정할 수 있습니다.

다른 소켓 파일 및 TCP/IP 포토 번호로 기동하기 위해서, 새롭게 MySQL 서버를 컴파일 할 필요는 없습니다.실행시에 값을 지정하는 것도 가능합니다.이것을 실시한다 1 개의 방법으로서 커멘드 라인 옵션의 사용이 있습니다.

shell> /path/to/mysqld_safe --socket=file_name --port=port_number

2 번째의 서버에 다른 데이타베이스 디렉토리를 사용하기 위해(때문에),--datadir=path 옵션을 mysqld_safe 에 건네줍니다.

같은 효과를 얻는 다른 방법으로서 환경 변수를 사용해 소켓명과 포토 번호를 설정할 수도 있습니다.

shell> MYSQL_UNIX_PORT=/tmp/mysqld-new.sock
shell> MYSQL_TCP_PORT=3307
shell> export MYSQL_UNIX_PORT MYSQL_TCP_PORT
shell> scripts/mysql_install_db
shell> bin/mysqld_safe &

이 방법을 사용하면, 테스트용으로 2 번째의 서버를 재빠르게 기동할 수 있습니다.이 방법의 장점은, 상기의 쉘로부터 호출한 어느 클라이언트 프로그램에도 이 환경 변수가 적용되는 점입니다.그 때문에, 이러한 클라이언트의 접속은 자동적으로 2 번째의 서버에 다이렉트 됩니다.

부록 F. 환경 변수 에,mysqld (을)를 제어하는 다른 환경 변수의 일람이 기재되어 있습니다.

자동 서버 실행에서는, 부트시에 실행되는 스타트 업 스크립트에 의해, 서버 마다 이하의 커멘드가 1 회씩 실행될 필요가 있습니다.그 때, 각 커멘드에 대해서 적절한 옵션 설정 파일의 패스를 설정합니다.

mysqld_safe --defaults-file=path-to-option-file

각 옵션 설정 파일에는, 특정의 서버에 고유의 옵션치가 포함되어 있는 것이 필요합니다.

Unix 그럼,mysqld_multi 스크립트를 사용해 복수의 서버를 개시할 수도 있습니다. See 항4.8.3. 「mysqld_multi (복수의 MySQL 서버를 관리하는 프로그램)」 .

4.2.3. 복수 서버 환경에서 클라이언트 프로그램을 사용한다

클라이언트에 컴파일 된 네트워크 인터페이스 이외의 네트워크 인터페이스를 릿슨 하고 있다 MySQL 서버에 그 클라이언트로부터 접속하려면 , 이하의 몇개의 방법을 실행합니다.

  • TCP/IP 경유로 리모트 호스트에게 접속하는 경우는 --host=host_name --port=port_number 그리고 클라이언트를 개시한다.Unix 소켓 또는 Windows 의 이름 파이프를 사용해 로컬 호스트에게 접속하는 경우는 --host=localhost --socket=file_name 그리고 클라이언트를 개시한다.

  • MySQL 4.1 그럼,TCP/IP 경유로 접속하는 경우는 --protocol=tcp (을)를,Unix 소켓을 사용하는 경우는 --protocol=socket (을)를, 이름 파이프를 사용하는 경우는 --protocol=pipe (을)를, 공유 메모리를 사용하는 경우에는 --protocol=memory (을)를 지정해 클라이언트를 개시한다.TCP/IP 접속에서는,--host 옵션과 --port 옵션을 지정하는 것이 필요한 경우도 있다.다른 접속 타입에서는, 경우에 따라서는,--socket 옵션으로 소켓 또는 이름 파이프명을 지정하거나--shared-memory-base-name 옵션으로 공유 메모리명을 지정하는 것이 필요하게 된다.

  • Unix 그럼, 클라이언트를 기동하기 전에,MYSQL_UNIX_PORT 환경 변수와 MYSQL_TCP_PORT 환경 변수를 설정해 Unix 소켓 및 TCP/IP 포토 번호를 지정한다. 특정의 소켓 또는 포토를 영속적으로 사용하는 경우, 이러한 환경 변수를 설정하는 커멘드를 .login 파일에 두고, 로그인마다 이러한 환경 변수가 적용되도록 할 수 있다. See 부록 F. 환경 변수 .

  • 옵션 설정 파일의 [client] 그룹에 디폴트 소켓과 TCP/IP 포토를 지정한다.예를 들어,Windows 그럼 C:\my.cnf (을)를,Unix 그럼 홈 디렉토리의 .my.cnf 파일을 사용할 수 있다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

  • C 프로그램에서는, 포토 또는 소켓 인수를 mysql_real_connect() 의 호출로 지정할 수 있다.또,mysql_options() (을)를 호출하고, 프로그램에 옵션 설정 파일을 읽어내게 할 수도 있다. See 항11.1.3. 「C API 함수의 설명」 .

  • Perl DBD::mysql 모듈을 사용하고 있는 경우,MySQL 옵션 설정 파일로부터 옵션을 읽어낼 수 있다.다음에 예를 나타낸다.

    $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);

    See 항11.5.2. 「DBI 인터페이스」 .


4.3. 일반적인 시큐러티 관련 사항과 MySQL 액세스 제어 시스템

MySQL 에는, 비표준입니다만, 상급의 시큐러티 및 권한 시스템이 있습니다.이 섹션에서는, 그 기능에 대해 설명합니다.

4.3.1. 일반적인 시큐러티 가이드 라인

인터넷에 접속된 컴퓨터로 MySQL (을)를 사용하는 유저는 모두, 이 섹션을 읽고, 빈발하고 있는 시큐러티 침해를 회피하도록 해 주세요.

도청 감청, 개찬, 재생, 서비스 방해 등, 모든 타입의 공격에 대해서,MySQL 서버 뿐만이 아니라, 서버 호스트 전체를, 최대한의 노력을 가지고 보호하는 것이 필요합니다.여기에서는, 가용성 및 내장해성의 모두에 대해서는 커버하고 있지 않습니다.

MySQL 그럼, 모든 접속, 쿼리 등, 유저가 실행할 가능성이 있는 조작에 대해서, 그 시큐러티를, 액세스 제어 리스트(ACL )(을)를 베이스로 해 보호하고 있습니다.MySQL 클라이언트와 서버간의 SSL 암호화 접속도 서포트하고 있습니다.여기서 설명하는 개념의 상당수는,MySQL 고유하지는 않습니다.거의 모든 어플리케이션에 들어맞읍니다.

MySQL (을)를 실행할 때 , 가능한 한 이하의 가이드 라인에 따라 주세요.

  • mysql root 유저 이외의 누구에게도 mysql 데이타베이스의 user 테이블에의 액세스권을 주지 않는 것. 이것은 매우 중요하다. MySQL 그럼, 암호화된 패스워드가 실제의 패스워드이다. user 테이블내의 리스트에 포함되어 있는 패스워드를 파악해 그 어카운트의 리스트에 포함되어 있는 호스트에 대한 액세스권을 가지는 사람은 누구라도, 간단하게 그 유저로서 로그인할 수 있다 .

  • MySQL 액세스권한시스템을 이해하는 것.MySQL 에의 액세스를 제어하려면 GRANT 커멘드와 REVOKE 커멘드를 사용한다.필요 이상의 권한을 유저로 설정하지 않는 것.모든 호스트에 대한 권한은 결코 주지 않는 것.

    대조표

    • mysql -u root (을)를 시험한다.패스워드 없이 서버에 정상적으로 접속할 수 있는 것 같다면 문제가 있다.이 경우, 모든 권한을 가진다 root 유저로서MySQL 서버에 접속할 수 있는 것이다. 특히 root 패스워드의 설정에 관한 항목에 주의하고,MySQL 인스톨 순서를 재검토하는 것.

    • SHOW GRANTS 커멘드를 사용하고, 누가 무엇에 액세스 할 수 있는지를 체크한다.REVOKE 커멘드를 사용해 불필요한 권한을 삭제한다.

  • 데이타베이스에는, 텍스트 형식의 패스워드를 보존하지 않는 것.컴퓨터가 크랙 되었을 때, 패스워드의 완전한 리스트가 빼앗겨 부정사용 되는 결과가 된다.MD5() ,SHA1() , 또는 다른 한방향 핫싱 함수를 사용한다.

  • 사전을 사용해 패스워드를 선택하지 않는다.특수 프로그램으로 해독되어 버린다.``xfish98'' (와)과 같은 패스워드도 좋지 않다.표준 QWERTY 키보드로 ``fish'' (을)를 1 렬좌로 타이프 쳤다 ``duag98'' 등을 추천.또,``Mary had a little lamb'' 의 머리 글자를 취해 ``Mhall'' (으)로 하는 것도 좋다. 이 방법이라고 기억하기 쉽고, 또 외부인이 유추 하는 일도 곤란.

  • 파이어 월(fire wall)에 투자한다.이것에 의해, 적어도 50% 의 공격을 막을 수 있다.MySQL (을)를 파이어 월(fire wall)내 즉 비무장지대에 배치한다.

    대조표

    • nmap 등의 툴을 사용하고, 인터넷으로부터 자신의 포토를 스캔 해 본다.MySQL (은)는 디폴트로 포토 3306 (을)를 사용한다.이 포토는, 신뢰 받지 않은 호스트로부터 액세스 할 수 있어선 안 된다.그 밖에도,MySQL 포토가 열려 있을지 확인하는 간단한 방법으로서 리모트 컴퓨터로부터 이하의 커멘드를 실행한다고 하는 방법이 있다.여기서,server_host 하 MySQL 서버의 호스트명이다.

      shell> telnet server_host 3306

      접속할 수 있어 의미불명한 문자가 돌아가면 포토가 열려 있다.열어 두는 정당한 이유가 없는 한, 파이어 월(fire wall) 또는 라우터로 닫아 둔다.telnet 하지만 행 하는지, 접속이 거부되면 정상적이다.즉, 포토는 닫고 있다.

  • 유저가 입력하는 데이터를 신뢰하지 않는 것.Web 폼,URL , 그 외의 어플리케이션으로부터 특수 문자 또는 이스케이프 문자 순서가 입력되어 부정 조작을 할 가능성이 있다.유저가 ``; DROP DATABASE mysql;'' 등이 같은 입력을 해도, 어플리케이션이 안전하게 유지되도록(듯이) 해야 한다.이것은 극단적인 예이지만 예방 대책을 강구해 두지 않으면 크래커에 의한 같은 수단에 의해서, 중대한 시큐러티 리크나 데이터의 분실이 발생할 가능성이 있다.

    또, 수치 데이터도 체크하는 것.문자열만을 보호하는 것은, 자주 있다?~ 스이다.공개되고 있는 데이터만의 데이타베이스는 보호할 필요가 없다고 하는 생각도 자주 있을 생각이지만, 이것도 잘못되어 있다.그러한 데이타베이스에도, 서비스 방해 타입의 공격이 가능하다.이 타입의 공격을 막는 가장 심플한 방법은, 수치 정수를 어퍼스트로피로 둘러싸는 것.SELECT * FROM table WHERE ID=234 (이)가 아니고,SELECT * FROM table WHERE ID='234' (와)과 같이 한다. MySQL (은)는 자동적의 이 문자열을 수치로 변환해, 비수치 기호를 삭제한다.

    대조표

    • 모든 Web 어플리케이션

      • 모든 Web 폼으로 ‘' ＇ 및 ‘" ＇ (을)를 입력해 본다.어떠한 MySQL 에러가 발생했을 경우는, 곧바로 그 문제를 조사한다.

      • URL 그리고 %22 (‘" ＇),%23 (‘# ＇), 및 %27 (‘' ＇)(을)를 추가해 동적 URL 의 수정을 시도한다.

      • 전의 예의 문자를 포함한 동적 URL 의 데이터형을 수치형으로부터 문자형으로 변경한다.이러한 공격이 있어도 어플리케이션이 영향을 받지 않게 한다.

      • 수치 필드에 수치가 아니고, 문자, 스페이스, 및 특수 기호를 입력해 본다.MySQL 에 건네주는 일 없이 어플리케이션이 그러한 값을 삭제하는지, 에러를 생성하는 것이 필요하다.값이 체크되지 않고 MySQL 에 건너면 매우 위험하다.

      • MySQL 에 건네주기 전에 데이터 사이즈를 체크한다.

      • 관리 목적으로 사용하는 유저명과는 다른 유저명으로, 어플리케이션을 데이타베이스에 접속시킨다.어플리케이션에, 필요 이상의 액세스권을 설정하지 않는다.

    • PHP 의 유저

      • addslashes() 함수를 체크한다. PHP 4.0.3 보다 ,mysql_escape_string() 함수가 이용 가능하게 되어 있다.이것은,MySQL C API 의 같은 이름의 함수를 베이스로 하고 있다.

    • MySQL C API 의 유저

      • mysql_real_escape_string() API 호출을 체크한다.

    • MySQL++ 의 유저

      • 쿼리 스트림의 escape 및 quote 의 수식자를 체크한다.

    • Perl DBI 의 유저

      • quote() 메소드를 체크하는지, 플레이스홀더를 사용한다.

    • Java JDBC 의 유저

      • PreparedStatement 오브젝트 및 플레이스홀더를 사용한다.

  • 인터넷상에서 암호화되어 있지 않은 데이터를 송신하지 않는 것.이러한 데이터는, 악의가 있는 제삼자에 의해서 도청되어 악용 될 가능성이 있다.SSL (이)나 SSH 등의 암호화 프로토콜을 사용한다.MySQL 그럼, 버젼 4.0.0 보다 내부 SSL 접속을 서포트하고 있다. SSH 포토 전송을 사용하고, 암호화( 및 압축)된 통신 터널을 작성할 수 있다.

  • tcpdump 유틸리티 및 strings 유틸리티의 사용법을 이해하는 것.대부분의 경우, 이하와 같은 커멘드로,MySQL 데이터 스트림이 암호화되고 있는지 어떤지를 체크할 수 있다.

    shell> tcpdump -l -i eth0 -w - src or dst port 3306 | strings

    이것은,Linux 시스템으로 유효.다른 시스템에서도, 조금 수정하는 것만으로 사용할 수 있다. 경고: 데이터를 볼 수 없어도, 반드시 실제로 암호화되고 있다고는 할 수 없다.고도의 시큐러티가 필요한 경우는, 전문가에게 상담하는 것.

4.3.2. MySQL 의 크래커 대책

MySQL 서버에 접속할 때, 통상은 패스워드를 사용합니다.패스워드는 텍스트 형식에서 송신되는 것은 아닙니다만, 암호화 알고리즘은 그만큼 강력한 것이 아닙니다.클라이언트와 서버간의 트래픽을 도청할 수 있으면, 크래커는 조금의 노력으로 패스워드를 찾아 맞힐 수 있습니다.클라이언트와 서버간의 접속이 신뢰 받지 않은 네트워크를 통과하는 경우에는,SSH 터널을 사용해 통신을 암호화해 주세요.

그 외의 정보는 모두 텍스트로서 전송 되므로, 그 접속을 볼 수 있는 사람은 누구라도 그러한 정보를 읽을 수 있습니다.이것에 불안을 느끼는 경우는, 압축 프로토콜(MySQL 버젼 3.22 이?~ )(을)를 사용해 트래픽의 해독을 보다 곤란하게 할 수 있습니다.시큐러티를 한층 더 높이려면 ,ssh (을)를 사용해 주세요. 오픈 소스 의 ssh 클라이언트는 http://www.openssh.org/ 에, 상용 ssh 클라이언트는 http://www.ssh.com/ 에 있습니다.이것을 사용하면,MySQL 서버와 MySQL 클라이언트간에 암호화 TCP/IP 접속을 이용할 수 있습니다.

MySQL 4.0 (을)를 사용하고 있는 경우, 내부 OpenSSL 서포트도 이용할 수 있습니다. See 항4.4.10. 「안전한 접속의 사용」 .

MySQL 시스템의 시큐러티를 확보하기 위해서는, 이하의 사항을 강하게 추천 합니다.

  • 모든 MySQL 유저에게 패스워드를 사용한다.other_user 에 패스워드가 설정되어 있지 않으면, 누구라도 mysql -u other_user db_name (으)로서 간단하게 타인이 되어 끝내 로그인할 수 있다.클라이언트/ 서버형의 어플리케이션에서는, 클라이언트측에서 임의의 유저명을 지정할 수 있는 것이 일반적.mysql_install_db 스크립트를 실행전에 편집하는 것으로써, 모든 유저의 패스워드를 변경할 수 있다.또,MySQL root 유저의 패스워드만 변경하려면 , 이하와 같이 실시한다.

    shell> mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('new_password')
    ->             WHERE user='root';
mysql> FLUSH PRIVILEGES;

  • MySQL demon를 Unix root 어카운트로 실행하지 않는 것.이것은,FILE 권한이 있는 유저이면 누구라도 root (예를 들어 ~root/.bashrc )(으)로서 파일을 작성 가능하게 되므로, 매우 위험하다.이것을 막기 위해,--user=root 옵션을 사용해 직접 지정되었을 경우를 제외해,mysqld 하 root (으)로서 실행하는 것을 거부하게 되어 있다.

    mysqld (은)는, 보통 권한 없음 유저로서 실행할 수 있다. 새롭다 Unix 어카운트 mysql (을)를 작성해 한층 더 시큐러티를 높일 수도 있다.다른 Unix 어카운트로 mysqld (을)를 실행하는 경우,user 테이블내의 root 유저명을 변경할 필요는 없다.MySQL 유저명과 Unix 어카운트명은 서로 관계없다.다른 Unix 어카운트로 mysqld (을)를 개시하려면 , 서버의 데이터 디렉토리에 있다 my.cnf 또는 /etc/my.cnf 의 옵션 설정 파일의 [mysqld] 그룹에, 어카운트명을 지정한다 user 행을 추가한다.다음에 예를 나타낸다.

    [mysqld]
user=mysql

    이것으로, 서버를 수동으로 기동했을 경우도,mysqld_safe 또는 mysql.server (을)를 사용해 기동했을 경우에서도, 지정의 어카운트로 서버가 기동한다. 상세한 것에 대하여는, 항A.3.2. 「일반 유저로 MySQL (을)를 실행하는 방법」 (을)를 참조.

  • 테이블에의 기호 연결을 서포트하지 않는다(이것은 --skip-symlink 옵션으로 무효로 할 수 있다).이것은,root 그리고 mysqld (을)를 실행하는 경우,mysqld 데이터 디렉토리에의 써 권한이 있는 모든 유저가, 시스템의 모든 파일을 삭제할 수 있게 되므로, 특히 중요하다. See 항5.6.1.2. 「Unix 위의 테이블에 대한 기호 연결의 사용」 .

  • mysqld (을)를 실행한다 Unix 어카운트인 만큼, 데이타베이스 디렉토리의 독해 권한과 써 권한이 있는 것을 확인한다.

  • PROCESS 권한을 모든 유저에게는 주지 않는다.mysqladmin processlist 의 출력에는, 현재 실행중의 쿼리의 텍스트가 표시된다.그 때문에, 이 커멘드를 실행할 수 있는 유저는,UPDATE user SET password=PASSWORD('not_secure') 쿼리를 실행하는 다른 유저를 특정할 수 있을 가능성이 있다.

    mysqld (은)는,PROCESS 권한을 가지는 유저용으로 특별 접속범위를 예약하고 있으므로, 모든 통상 접속이 사용중의 경우에서도,MySQL root 유저는 로그인해 서버 상태를 체크할 수 있다.

  • FILE 권한을 모든 유저에게는 주지 않는다.이 권한을 가지는 유저는,mysqld demon의 권한으로 파일 시스템의 어느 장소에라도 파일을 쓸 수 있다.안전 대책으로서SELECT ... INTO OUTFILE 그리고 생성되는 파일에 대해서는 누구라도 써 가능하지만, 기존의 파일에는 쓸 수 없게 되어 있다.

    FILE 권한은, 서버를 실행하고 있다 Unix 유저가 액세스 할 수 있는 모든 독해 가능 파일을 읽는 경우에도 사용된다.또, 유저가 어떠한 권한을 가지고 있는 경향 데이타베이스에 임의의 파일을 읽어들일 수 있다. 이것은, 부정사용 될 가능성이 있다.예를 들어,LOAD DATA (을)를 사용해 /etc/passwd (을)를 테이블에 로드해,SELECT 그리고 읽을 수 있다.

  • DNS (을)를 신뢰하지 않는 경우, 권한 테이블로, 호스트명은 아니고 IP 주소를 사용하는 것.어쨌든, 와일드 카드를 포함한 호스트명을 사용해 권한 테이블을 작성할 때 특히 주의가 필요하다.

  • 단일 유저의 접속수를 제한하는 경우는,mysqld 그리고 max_user_connections 변수를 설정한다.

4.3.3. 시큐러티 관련의 mysqld 스타트 업 옵션

시큐러티에 영향을 준다 mysqld 옵션은 이하대로입니다.

  • --local-infile[=(0|1)]

    --local-infile=0 (을)를 사용하면,LOAD DATA LOCAL INFILE (을)를 사용할 수 없게 된다.

  • --safe-show-database

    이 옵션을 사용하면,SHOW DATABASES 커멘드로, 그 유저가 어떠한 권한을 가지고 있는 데이타베이스만이 돌려주어진다. 현재는,SHOW DATABASES 권한이 존재하기 위해(때문에), 버젼 4.0.2 이?~ , 이 옵션은 폐?~ 되고 있어 아무것도 하지 않는다(디폴트로 유효하게 되어 있다). See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

  • --safe-user-create

    이 옵션이 유효하게 되어 있는 경우, 유저에게 mysql.user 테이블에의 INSERT 권한이 없으면, 그 유저는 GRANT 커멘드를 사용해 신규 유저를 작성할 수 없다.유저가 사전 설정된 권한으로 신규 유저를 작성할 수 있도록 하려면 , 그 유저에게 이하의 권한을 설정하는 것이 필요하다.

    mysql> GRANT INSERT(user) ON mysql.user TO 'user'@'hostname';

    이것으로, 유저는 권한 컬럼을 직접 변경할 수 없지만,GRANT 커멘드를 사용해 다른 유저에게 권한을 줄 수 있게 된다.

  • --skip-grant-tables

    서버가 권한 시스템을 전혀 사용하지 않게 한다.이것에 의해 모든 사람이, 모든 데이타베이스에 풀 액세스 할 수 있게 된다.실행중의 서버에 권한 테이블을 다시 사용시키기 위해서는,mysqladmin flush-privileges , mysqladmin reload 또는 FLUSH PRIVILEGES; (을)를 실행하면 좋다.

  • --skip-name-resolve

    호스트명을 해결하지 않는다.권한 테이블의 Host 컬럼치는 모두 IP 주소인가 localhost (이)가 아니면 안된다.

  • --skip-networking

    TCP/IP 경유의 접속을 인정하지 않는다.mysqld 에의 접속을 모두 Unix 소켓으로 실시한다. 이 옵션은,3.23.27 보다 전의 MySQL 버젼으로 MIT-pthreads 패키지를 이용하고 있는 것 적합하지 않는다.그 당시 ,Unix 소켓은 MIT-pthreads 에 의해서 서포트되어 있지 않았으니까이다.

  • --skip-show-database

    SHOW DATABASES 권한이 없는 유저에게 SHOW DATABASES 커멘드의 사용을 인정하지 않는다.버젼 4.0.2 (으)로부터, 이 옵션은 필요없게 되었다.현재는,SHOW DATABASES 권한을 할당할 수 있는 것으로 커멘드를 사용할 수 있게 되어 있다.

4.3.4. LOAD DATA LOCAL 의 시큐러티 관련 사항

MySQL 3.23.49 및 MySQL 4.0.2 (Windows 그럼 4.0.13 )(으)로,LOAD DATA LOCAL 에 관한 시큐러티 대책으로 하고 있어 구두인가의 새로운 옵션이 추가되었습니다.

이 커멘드에는 다음과 같은 잠재적인 문제가 2 개 있습니다.

파일의 독해가 서버측으로부터 개시되기 위해, 이론적으로는, 개악 했다 MySQL 서버를 작성해 두면, 클라이언트가 테이블에 대해서 쿼리를 실행했을 때에, 그 클라이언트 컴퓨터상에 존재하는 모든 파일( 커런트 유저가 읽어내 권을 가진다) (을)를, 개악 했다 MySQL 서버를 읽어낼 수 있는 것이 됩니다.

클라이언트가 Web 서버로부터 접속한다 Web 환경에서는, 유저는 LOAD DATA LOCAL (을)를 사용하고,Web 서버 프로세스가 읽어내 액세스권을 가지는 어느 파일에서도 읽어낼 수 있습니다(유저가 SQL 서버에 대해서 모든 커멘드를 실행할 수 있는 경우).

이것에는 2 개의 해결 방법이 있습니다.

MySQL (을)를 --enable-local-infile 그리고 콘피개 하고 있지 않으면,mysql_options(... MYSQL_OPT_LOCAL_INFILE, 0) (을)를 호출하지 않는 클라이언트는 LOAD DATA LOCAL (을)를 사용할 수 없습니다. See 항11.1.3.40. 「mysql_options() 」 .

mysql 커멘드 라인 클라이언트에 대해서는,--local-infile[=1] 옵션으로 LOAD DATA LOCAL (을)를 유효하게 할 수 있어--local-infile=0 옵션으로 무효로 할 수 있습니다.

디폴트에서는, 모든 MySQL 클라이언트와 라이브러리가 --enable-local-infile 그리고 컴파일 되어MySQL 3.23.48 이전과의 호환성이 유지되게 되어 있습니다.

MySQL 서버로 모든 LOAD DATA LOCAL 커멘드를 무효로 하려면 ,mysqld (을)를 --local-infile=0 그리고 개시합니다.

LOAD DATA LOCAL INFILE 하지만 서버 또는 클라이언트로 무효가 되어 있는 경우, 다음의 에러 메세지(1148 )(이)가 표시됩니다.

The used command is not allowed with this MySQL version

4.3.5. 권한 시스템이 실시하는 것

MySQL 권한 시스템은, 주로, 임의의 호스트로부터 접속한 유저를 인증해, 그 유저를, 데이타베이스상에 등록되어 있는 권한(SELECT ,INSERT ,UPDATE ,DELETE )(와)과 관련짓습니다.

게다가 익명 유저를 작성해,LOAD DATA INFILE (이)나 관리 조작 기능 등 MySQL 고유의 기능을 실행하기 위한 권한을 설정합니다.

4.3.6. 권한 시스템은 어떻게 기능할까

MySQL 권한 시스템은, 모든 유저가 각각 허가된 조작만을 실행할 수 있도록 합니다.MySQL 서버에 접속하면, 유저의 ID 하 접속원의 호스트 및 지정한 유저명 에 의해서 특정됩니다.권한 시스템은, 유저 ID (와)과 실시하고 싶은 조작 에 따라 권한을 설정합니다.

MySQL 그럼, 호스트명과 유저명을 사용해 유저를 인증합니다.1 살의 유저명이 인터넷상의 어디서에서도 같은 유저를 나타내고 있다고 하는 보증이 없기 때문입니다.예를 들어,office.com (으)로부터 접속한 유저 joe (은)는,elsewhere.com (으)로부터 접속했다 joe (와)과 동일 인물이라고는 할 수 없습니다. MySQL 그럼, 같은 유저명에서도 다른 호스트로부터 접속하는 유저 사이에 구별하는 것으로써, 이것을 처리하고 있습니다.joe 에 대해서,office.com (으)로부터 접속했을 경우의 권한 세트와elsewhere.com (으)로부터 접속했을 경우의 권한 세트를 따로 따로 설정할 수 있습니다.

MySQL 의 액세스 제어에는 2 단계가 있습니다.

  • 단계 1: 유저에게 접속하는 권한이 있을지 서버가 체크한다.

  • 단계 2: 접속할 수 있었을 경우, 요구 마다 그것을 실행할 수 있는 권한이 있을지 서버가 체크한다.예를 들어, 데이타베이스가 있는 테이블에서 레코드를 SELECT 하거나 데이타베이스의 테이블을 DROP 하려고 하면, 유저에게 그 테이블의 SELECT 권한이 있을지, 혹은 데이타베이스의 DROP 권한이 있을지를 서버가 체크한다.

주의: 접속중으로 권한이 변경되었을 경우(유저 자신 또는 제삼자에 의해서), 반드시 그 변경은 다음의 쿼리에 반영되지 않습니다.상세한 것에 대하여는, 항4.4.3. 「권한의 변경은 언제 반영될까」 (을)를 참조해 주세요.

서버는 액세스 제어의 양쪽 모두의 단계에서,mysql 데이타베이스의 user ,db ,host 의 각 테이블을 사용합니다.이러한 권한 테이블의 필드를 이하에 나타냅니다.

테이블명 | user | db | host
스코프 필드 | Host | Host | Host
 | User | Db | Db
 | Password | User |
권한 필드 | Select_priv | Select_priv | Select_priv
 | Insert_priv | Insert_priv | Insert_priv
 | Update_priv | Update_priv | Update_priv
 | Delete_priv | Delete_priv | Delete_priv
 | Index_priv | Index_priv | Index_priv
 | Alter_priv | Alter_priv | Alter_priv
 | Create_priv | Create_priv | Create_priv
 | Drop_priv | Drop_priv | Drop_priv
 | Grant_priv | Grant_priv | Grant_priv
 | References_priv | References_priv | References_priv
 | Reload_priv |  |
 | Shutdown_priv |  |
 | Process_priv |  |
 | File_priv |  |
 | Show_db_priv |  |
 | Super_priv |  |
 | Create_tmp_table_priv | Create_tmp_table_priv | Create_tmp_table_priv
 | Lock_tables_priv | Lock_tables_priv | Lock_tables_priv
 | Execute_priv |  |
 | Repl_slave_priv |  |
 | Repl_client_priv |  |
 | ssl_type |  |
 | ssl_cypher |  |
 | x509_issuer |  |
 | x509_cubject |  |
 | max_questions |  |
 | max_updates |  |
 | max_connections |  |

액세스 제어의 2 단계눈(요구 확인)으로, 요구가 테이블에 관련하는 것인 경우, 서버가 한층 더 tables_priv 테이블 및 columns_priv 테이블을 참조하는 일이 있습니다.이러한 테이블의 필드를 이하에 나타냅니다.

테이블명 | tables_priv | columns_priv
스코프 필드 | Host | Host
 | Db | Db
 | User | User
 | Table_name | Table_name
 |  | Column_name
권한 필드 | Table_priv | Column_priv
 | Column_priv |
그 외의 필드 | Timestamp | Timestamp
 | Grantor |

각 권한 테이블에는, 스코프 필드와 권한 필드가 있습니다.

스코프 필드는, 테이블의 각 등록의 범위를 특정합니다.예를 들어,Host (와)과 User 의 값이 'thomas.loc.gov' 및 'bob' 이다 user 테이블 엔트리는,thomas.loc.gov 호스트로부터 서버에 접속하려고 한다 bob (을)를 인증합니다.같이Host ,User ,Db 의 각 필드의 값이 'thomas.loc.gov' ,'bob' , 및 'reports' 이다 db 테이블 엔트리는,thomas.loc.gov 호스트로부터 reports 데이타베이스에 접속하려고 한다 bob (을)를 인증합니다.tables_priv 테이블 및 columns_priv 테이블에는, 각 엔트리에 허가되고 있는 테이블 또는 테이블과 컬럼의 편성을 나타내는 스코프 필드가 포함되어 있습니다.

액세스를 체크하는 목적에 있어서,Host 값은 대문자와 소문자의 구별이 없습니다.User ,Password ,Db , 및 Table_name 의 값에 대해서는 대문자와 소문자가 구별됩니다. Column_name 값은,MySQL 버젼 3.22.12 이?~ 그럼 대문자와 소문자가 구별되지 않게 되어 있습니다.

권한 필드는, 테이블내의 엔트리 마다 설정되어 있는 권한, 즉 무슨 조작을 실행할 수 있는지를 나타냅니다.서버는 다양한 권한 테이블의 정보를 조합하고, 유저의 권한에 대한 완전한 기술을 생성합니다. 이 동작에 적용되는 룰에 대해서는, 항4.3.10. 「액세스 제어의 단계 2: 요구 확인」 (을)를 참조해 주세요.

스코프 필드는 문자열입니다.여기서 나타나고 있도록(듯이), 각각의 디폴트치는 하늘의 문자열입니다.

필드명 | 형 | 주의
Host | CHAR(60) |
User | CHAR(16) |
Password | CHAR(16) |
Db | CHAR(64) | (tables_priv 테이블 및 columns_priv 테이블에서는 CHAR(60) )
Table_name | CHAR(60) |
Column_name | CHAR(60) |

user ,db ,host 의 각 테이블에서는, 모든 권한 필드가 ENUM('N','Y') (으)로서 선언됩니다.각각의 값은 'N' 또는 'Y' 그리고, 디폴트치는 'N' 입니다.

tables_priv 테이블 및 columns_priv 테이블에서는, 권한 필드는 SET 필드로서 선언됩니다.

테이블명 | 필드명 | 설정 가능한 요소
tables_priv | Table_priv | 'Select', 'Insert', 'Update', 'Delete', 'Create', 'Drop', 'Grant', 'References', 'Index', 'Alter'
tables_priv | Column_priv | 'Select', 'Insert', 'Update', 'References'
columns_priv | Column_priv | 'Select', 'Insert', 'Update', 'References'

이하, 서버가 권한 테이블을 어떻게 사용할까 간결하게 설명합니다.

  • user 테이블의 스코프 필드에 의해, 착신한 접속을 허가하는지 거부할까 결정한다.허가된 접속에 대해서,user 테이블로 설정되어 있는 권한은 모두, 그 유저의 글로벌(슈퍼 유저) 권한이 된다. 이러한 권한은, 서버의 모든 데이타베이스에 적용된다.

  • db 테이블과 host 테이블은 함께 사용된다.

    • db 테이블의 스코프 필드에 의해, 어느 유저가 어느 호스트로부터 어느 데이타베이스에 액세스 할 수 있을까를 결정한다.권한 필드로부터, 무슨 조작이 허가되고 있을까 판단한다.

    • host 테이블은, 임의의 db 테이블 엔트리를 몇개의 호스트에게 적용하는 경우,db 테이블을 보완하는 것으로서 사용된다.예를 들어,1 사람의 유저에게 네트워크내의 몇개의 호스트로부터 데이타베이스에 액세스 하는 것을 허가하는 경우, 유저의 db 테이블 엔트리의 Host 값을 공백대로 해 두어, 그러한 호스트의 각 엔트리를 host 테이블에 입력한다.이 메카니즘의 상세한 것에 대하여는, 항4.3.10. 「액세스 제어의 단계 2: 요구 확인」 (을)를 참조.

  • tables_priv 테이블 및 columns_priv 테이블은 db 테이블을 닮아 있지만, 보다 상세한 설정이 가능.데이타베이스 레벨이 아니고, 테이블 및 컬럼 레벨로 적용된다.

주의: 관리자 권한(RELOAD ,SHUTDOWN 등)은,user 테이블에서만 지정합니다.관리 조작은 데이타베이스 고유하지 않고, 서버 그 자체로 실시하는 조작이므로, 이 권한을 다른 권한 테이블로 설정할 필요는 없습니다.실제, 관리 조작을 실행할 수 있을지 결정할 때 ,user 테이블을 참조하는 것만으로 끝납니다.

FILE 권한도 user 테이블만으로 지정합니다. 이것은 관리자 권한이 아닙니다만, 서버 호스트상에서의 파일의 읽고 쓰기는, 액세스 하고 있는 데이타베이스에 의존하지 않습니다.

mysqld 서버는 권한 테이블의 내용을, 기동시에 1 회 읽어냅니다.권한 테이블에의 변경의 반영에 대해서는, 항4.4.3. 「권한의 변경은 언제 반영될까」 (을)를 참조해 주세요.

권한 테이블의 내용을 변경하는 경우, 그 변경에 의해서, 목적의 권한이 적절히 설정되어 있는 것을 확인해 주세요.문제 진단의 헬프에 대해서는, 항4.3.12. 「Access denied 에러의 원인」 (을)를 참조해 주세요.시큐러티에 관한 어드바이스에 대해서는, 항4.3.2. 「MySQL 의 크래커 대책」 (을)를 참조해 주세요.

편리한 진단 툴로서mysqlaccess 스크립트가 있습니다.이것은,Yves Carlier 하지만 MySQL 디스트리뷰션용으로 제공한 것입니다.이 툴의 동작을 확인하고 싶은 경우에는,mysqlaccess (을)를 --help 옵션으로 기동해 주세요. 주의: mysqlaccess 하 user ,db , 및 host 테이블만을 사용해 액세스를 체크합니다.테이블 또는 컬럼 레벨의 권한은 체크하지 않습니다.

4.3.7. MySQL 하지만 제공하는 권한

유저 권한에 관한 정보는,mysql 데이타베이스(mysql (이)라는 이름의 데이타베이스)의 user ,db ,host ,tables_priv ,columns_priv 의 각 테이블에 보존되고 있습니다.MySQL 서버는 기동시와 항4.4.3. 「권한의 변경은 언제 반영될까」 그리고 설명되고 있는 상황하에 대하고, 이러한 테이블을 읽어냅니다.

이하, 이 메뉴얼로 사용되고 있다 MySQL 버젼 4.0.2 제공의 권한명을, 거기에 관련지을 수 있고 있는 테이블 컬럼명 및 그 적용 범위와 함께 나타내 보입니다.각 권한의 의미에 대해서는, 항4.4.1. 「GRANT 및 REVOKE 의 구문」 (을)를 참조해 주세요.

권한 | 컬럼 | 적용 범위
ALTER | Alter_priv | 테이블
DELETE | Delete_priv | 테이블
INDEX | Index_priv | 테이블
INSERT | Insert_priv | 테이블
SELECT | Select_priv | 테이블
UPDATE | Update_priv | 테이블
CREATE | Create_priv | 데이타베이스, 테이블, 또는 인덱스
DROP | Drop_priv | 데이타베이스 또는 테이블
GRANT | Grant_priv | 데이타베이스 또는 테이블
REFERENCES | References_priv | 데이타베이스 또는 테이블
CREATE TEMPORARY TABLES | Create_tmp_table_priv | 서버 관리
EXECUTE | Execute_priv | 서버 관리
FILE | File_priv | 서버상의 파일 액세스
LOCK TABLES | Lock_tables_priv | 서버 관리
PROCESS | Process_priv | 서버 관리
RELOAD | Reload_priv | 서버 관리
REPLICATION CLIENT | Repl_client_priv | 서버 관리
REPLICATION SLAVE | Repl_slave_priv | 서버 관리
SHOW DATABASES | Show_db_priv | 서버 관리
SHUTDOWN | Shutdown_priv | 서버 관리
SUPER | Super_priv | 서버 관리

SELECT ,INSERT ,UPDATE ,DELETE 의 각 권한은, 데이타베이스상의 기존 테이블의 레코드에 대한 각 조작을 허가하는 것입니다.

SELECT 스테이트먼트는, 테이블에서 레코드를 실제로 꺼내는 경우만,SELECT 권한이 필요합니다.서버의 데이타베이스에의 액세스권이 없어도 실행할 수 있다 SELECT 스테이트먼트도 있습니다.예를 들어,mysql 클라이언트를 심플한 계산기로서 사용하는 경우입니다.

mysql> SELECT 1+1;
mysql> SELECT PI()*2;

INDEX 권한에서는, 인덱스를 작성 또는 파기(삭제)할 수 있습니다.

ALTER 권한에서는,ALTER TABLE (을)를 사용할 수 있습니다.

CREATE 및 DROP 권한에서는, 신규 데이타베이스 및 테이블의 작성, 기존 데이타베이스 및 테이블의 파기(삭제)를 실시할 수 있습니다.

주의: 유저에게 mysql 데이타베이스에 대한다 DROP 권한을 주면, 그 유저는 MySQL 액세스권한이 보존되고 있는 데이타베이스를 파기할 수 있는 것이 되므로 주의가 필요합니다.

GRANT 권한에서는, 유저가 소유하고 있는 권한을 다른 유저에게 줄 수 있습니다.

FILE 권한에서는,LOAD DATA INFILE 및 SELECT ... INTO OUTFILE 스테이트먼트를 사용해 서버상에서 파일의 읽고 쓰기를 실시할 수 있습니다.이 권한이 주어진 유저는 누구라도,MySQL 서버에 의해서 액세스 가능한 독해 가능 파일을 모두 읽을 수 있어 또 MySQL 서버에 의해서 쓸 수 있는 어느 디렉토리에도 신규 독해 가능 파일을 작성할 수 있습니다. 이 유저는 또, 경향 데이타베이스 디렉토리내의 모든 파일을 읽을 수 있습니다. 다만, 기존 파일의 변경은 할 수 없습니다.

이것들 이외의 권한은,mysqladmin 프로그램을 사용해 실행되는 관리 조작용으로 사용됩니다.이하의 겉(표)로, 어느 관리 권한으로 어느 mysqladmin 커멘드를 실행할 수 있는지를 나타냅니다.

권한 | 실행 가능한 커멘드
RELOAD | reload ,refresh ,flush-privileges ,flush-hosts ,flush-logs ,flush-tables
SHUTDOWN | shutdown
PROCESS | processlist
SUPER | kill

reload 커멘드는, 권한 테이블을 재독 봐 서버에 명령합니다.refresh 커멘드는, 모든 테이블을 플래시 해, 로그 파일을 열어 닫습니다.flush-privileges 하 reload 의 동의어입니다.다른 flush-* 커멘드도 refresh (와)과 같은 기능을 완수합니다만, 범위가 한정되어 있어 상황에 의해서 구분하여 사용해 주세요.예를 들어, 로그 파일만을 플래시 하려면 ,refresh 대신에 flush-logs (을)를 사용합니다.

shutdown 커멘드는 서버를 슛다운 합니다.

processlist 커멘드는, 서버로 실행중의 스레드에 관한 정보를 표시합니다.kill 커멘드는 서바스레드를 강제 종료합니다.유저는 언제라도 자신의 스레드를 표시 및 강제 종료할 수 있습니다만, 다른 유저에 의해서 개시된 스레드를 표시하려면 PROCESS 권한이, 강제 종료하려면 SUPER 권한이 필요합니다. See 항4.6.7. 「KILL 구문」 .

일반적인 지침으로서 유저에게는 그 유저가 필요로 하는 권한만을 주세요.또, 이하의 권한을 줄 때 주의가 필요합니다.

  • GRANT 권한은, 유저가 자신의 권한을 다른 유저에게 줄 수 있다.2 사람의 유저가 다른 권한을 가져, 양쪽 모두 GRANT 권한이 있는 경우, 서로의 권한을 조합할 수 있다.

  • ALTER 권한은, 테이블의 이름을 변경하는 것으로써, 권한 시스템을 붕괴시킬 수 있다.

  • FILE 권한을 악용 하면, 서버의 독해 가능 파일 또는 경향 데이타베이스 디렉토리의 파일을 데이타베이스 테이블에 읽어들이고,SELECT (을)를 사용해 그 내용에 액세스 할 수 있다.

  • SHUTDOWN 권한을 악용 하면, 서버를 종료하고, 다른 유저에게의 서비스 방해를 실시할 수 있다.

  • PROCESS 권한은, 패스워드의 설정이나 변경을 실시하는 쿼리등도 포함해 현재 실행중의 쿼리의 plaintext를 표시할 수 있다.

  • mysql 데이타베이스의 권한이 있으면, 패스워드 및 그 외의 액세스권한정보를 변경할 수 있다(패스워드는 암호화되어 보존되고 있기 때문에, 악의가 있는 유저가 단지 읽어내도 텍스트 형식의 패스워드를 알 수 없다).mysql.user 패스워드 컬럼에 액세스 할 수 있으면, 그것을 사용해 특정 유저의 MySQL 서버에 로그인할 수 있다(필요하게 되는 권한을 가지고 있으면, 그 유저는 패스워드를 고쳐 쓸 수도 있다).

MySQL 권한 시스템에서는 달성할 수 없는 것도 몇개인가 있습니다.

  • 특정 유저로부터의 액세스를 거부하도록(듯이) 명시적으로 지정할 수 없다. 즉, 유저를 특정하고, 그 접속을 거부할 수 없다.

  • 데이타베이스내의 테이블의 작성 및 파기의 권한을 유저에게 주어 그것과 동시에 데이타베이스의 작성 및 파기를 할 수 없게는 지정할 수 없다.

4.3.8. MySQL 서버에의 접속

MySQL 클라이언트에서는 통상,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= (와)과 거기에 계속 되는 패스워드의 사이에 스페이스는 들어가지 않습니다 .

주의: 커멘드 라인으로 패스워드를 지정하는 것은 안전하지는 않습니다. 같은 시스템내의 어느 유저라도,ps auxww (와)과 같은 커멘드를 사용하고 패스워드를 아는 것이 가능하게 됩니다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

mysql (은)는, 커멘드 라인으로 지정되지 않았던 접속 파라미터에 이하의 디폴트치를 사용합니다.

  • 디폴트 호스트명은 localhost .

  • 디폴트 유저명은 유저의 Unix 로그인명.

  • -p 하지만 지정되지 않으면, 패스워드는 없음이 된다.

따라서,Unix 유저 joe 그럼, 이하의 커멘드가 모두 같은 의미가 됩니다.

shell> mysql -h localhost -u joe
shell> mysql -h localhost
shell> mysql -u joe
shell> mysql

다른 MySQL 클라이언트에서도 같습니다.

Unix 시스템에서는, 접속시에 다른 디폴트치를 사용하도록(듯이) 설정할 수 있습니다.이것에 의해, 클라이언트 프로그램을 기동할 때마다 커멘드 라인으로 지정할 필요가 없어집니다.설정 방법법은 2 개 있습니다.

  • 홈 디렉토리내에 있다 .my.cnf 설정 파일의 [client] 섹션으로 접속 파라미터를 지정한다.이 섹션은 이하와 같이 된다.

    [client]
host=host_name
user=user_name
password=your_pass

    See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

  • 환경 변수를 사용해 접속 파라미터를 지정한다.mysql 의 호스트는,MYSQL_HOST (을)를 사용해 지정할 수 있다.MySQL 유저명은,USER (을)를 사용해 지정할 수 있다(Windows 마셔).패스워드는,MYSQL_PWD (을)를 사용해 지정할 수 있다(다만, 이것은 안전하지 않다.다음의 섹션을 참조). See 부록 F. 환경 변수 .

4.3.9. 액세스 제어의 단계 1: 접속 확인

유저가 MySQL 서버에 접속하려고 했을 경우, 그 유저 ID , 및 그것을 올바른 패스워드로 증명해 할 수 있을지에 의해서, 서버는 접속의 허가 또는 거부를 실시합니다.패스워드가 올바르지 않은 경우, 서버는 액세스를 완전하게 거부합니다.올바르면, 서버는 접속을 허가해, 단계 2 에 진행되고 요구를 기다립니다.

유저 ID (은)는,2 개의 정보에 근거합니다.

  • 접속원의 호스트

  • MySQL 유저명

ID 체크에는,user 테이블의 3 개의 스코프 필드(Host ,User ,Password )(이)가 사용됩니다.user 테이블 엔트리가, 지정된 호스트명과 유저명에 일치해, 입력한 패스워드가 올발랐던 경우만, 접속이 허가됩니다.

user 테이블의 스코프 필드에는 다음의 방법으로 값을 지정할 수 있습니다.

  • Host 값에는 호스트명 또는 IP 주소를 사용할 수 있다.로컬 호스트를 지정하는 경우는 'localhost' (을)를 사용한다.

  • 와일드 카드 문자 ‘% ＇ 및 ‘_ ＇ (을)를 Host 필드에 사용할 수 있다.

  • Host 값으로서의 '%' (은)는, 모든 호스트명을 의미한다.

  • 공백의 Host 값은, 해당하는 호스트명에 일치한다 host 테이블에 의해서 결정하는 것을 의미한다. 상세한 것에 대하여는, 다음의 장을 참조.

  • MySQL 버젼 3.23 보다 ,IP 주소로서 지정한다 Host 값에, 네트워크 주소를 나타내기 위한 넷 마스크를 사용할 수 있게 되어 있다.다음에 예를 나타낸다.

    mysql> GRANT ALL PRIVILEGES ON db.*
    -> TO david@'192.58.197.0/255.255.255.0';

    이것에 의해, 이하의 조건에 들어맞는다 IP (으)로부터 누구라도 접속할 수 있게 된다.

    user_ip & netmask = host_ip.

    위의 예에서는,192.58.197.0 ~ 192.58.197.255 사이의 IP 모든 것이 MySQL 서버에 접속할 수 있다.

  • User 필드에 와일드 카드 문자는 사용할 수 없지만, 공백의 값은 사용할 수 있어 이것은 임의의 유저명으로 일치한다. user 테이블 엔트리에 공백의 유저명이 있어, 접속이 공백 유저에게 매치했을 경우, 그 유저는 클라이언트가 실제로 지정한 이름의 유저가 아니고, 익명 유저(이름 없음의 유저)라고 보여진다.이 경우, 접속중(단계 2 의 사이)에 행해지는 후속의 액세스 체크는 모두, 공백의 유저명으로 행해진다.

  • Password 필드는 공백으로 할 수 있다.이것은 어느 패스워드에도 일치한다고 하는 의미가 아니고, 그 유저가 패스워드 지정하지 않고 접속할 필요가 있다고 하는 의미이다.

공백은 아니다 Password 값은, 암호화 패스워드를 나타냅니다. MySQL 그럼, 패스워드를 평문텍스트에서는 보존하지 않습니다.접속하려고 하는 유저가 입력한 패스워드는, 암호화됩니다(PASSWORD() 함수를 사용).클라이언트 및 서버가 패스워드의 확인을 실시할 때, 그 암호화된 패스워드가 사용됩니다(이 때, 그 접속을 사용하고, 암호화된 패스워드가 전송 될 것은 없습니다).주의: MySQL (으)로부터 보면 암호화된 패스워드가 실제의 패스워드이므로, 암호화 패스워드에 누구에게도 액세스 할 수 없게 해 주세요.특히, 일반의 유저에게 mysql 데이타베이스내의 테이블의 독해 액세스권을 주지 않아 주세요. 버젼 4.1 보다 ,MySQL (은)는 종래와는 다른 패스워드 및 로그인 메카니즘을 채용하고 있어TCP/IP 패킷이 훔쳐 봐 되거나mysql 데이타베이스가 capther 되었을 경우에서도 안전하게 되어 있습니다.

이하의 예는,user 테이블 엔트리의 Host 값 및 User 값의 다양한 조합이 어떻게 착신의 접속에 적용되는지를 나타낸 것입니다.

Host 치 | User 치 | 엔트리에 의해서 허가되는 접속
'thomas.loc.gov' | 'fred' | thomas.loc.gov (으)로부터 접속한다 fred
'thomas.loc.gov' | '' | thomas.loc.gov (으)로부터 접속하는 모든 유저
'%' | 'fred' | 임의의 호스트로부터 접속한다 fred
'%' | '' | 임의의 호스트로부터 접속하는 모든 유저
'%.loc.gov' | 'fred' | loc.gov 도메인내의 임의의 호스트로부터 접속한다 fred
'x.y.%' | 'fred' | x.y.net ,x.y.com ,x.y.edu 등에서 접속한다 fred (이것은 실용적이지 않다)
'144.155.166.177' | 'fred' | IP 주소 144.155.166.177 의 호스트로부터 접속한다 fred
'144.155.166.%' | 'fred' | 144.155.166 클래스 C 서스네트워크의 임의의 호스트로부터 접속한다 fred
'144.155.166.0/255.255.255.0' | 'fred' | 1 개상의 예와 같다

Host 필드에서는 IP 의 와일드 카드치를 사용할 수 있으므로(예를 들어,'144.155.166.%' 그리고, 서스네트워크의 모든 호스트에게 일치), 호스트를 144.155.166.somewhere.com 등이라고 이름 붙여 이 기능이 악용 될 가능성이 있습니다.이것을 막기 위해,MySQL 하 수치나 닷으로 시작되는 호스트명을 인정하지 않습니다 .따라서,1.2.foo.com 등의 호스트명은, 권한 테이블의 Host 컬럼과 결코 일치하지 않습니다.IP 주소만 IP 와일드 카드치와의 맞대어가 가능합니다.

어느 접속이,user 테이블의 복수의 엔트리와 일치하는 일이 있습니다.예를 들어,thomas.loc.gov (으)로부터의 fred 에 의한 접속은, 상기의 겉(표)의 몇개의 엔트리와 일치합니다.복수의 엔트리가 일치했을 경우, 서버는 다음과 같이 엔트리를 선택합니다.기동시에 user 테이블을 읽어들인 후, 그것을 소트 합니다.유저가 접속하려고 했을 때, 그 소트순서로 엔트리와의 맞대어를 실시합니다.그리고 최초로 일치한 엔트리를 사용합니다.

user 테이블의 소트는 이하와 같이 행해집니다.user 테이블이 이하의 내용이다고 합니다.

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| %         | root     | ...
| %         | jeffrey  | ...
| localhost | root     | ...
| localhost |          | ...
+-----------+----------+-

서버가 테이블을 읽어들이면, 가장 구체적인 Host 값을 최초로 가져 옵니다(Host 컬럼의 '%' 하 `` 임의의 호스트'' (을)를 의미해, 구체성이 낮다고 됩니다).같다 Host 값의 엔트리간으로, 가장 구체적인 User 값을 최초로 가져 옵니다(공백의 User 값은 `` 임의의 유저'' (을)를 의미해, 구체성이 낮다고 됩니다).소트 되었다 user 테이블은 이하와 같이 됩니다.

+-----------+----------+-
| Host      | User     | ...
+-----------+----------+-
| localhost | root     | ...
| localhost |          | ...
| %         | jeffrey  | ...
| %         | root     | ...
+-----------+----------+-

접속이 시도되면, 서버는 소트 된 엔트리로 맞대어를 실시해, 최초로 일치한 것을 사용합니다.localhost (으)로부터의 jeffrey 에 의한 접속에 대해서는,Host 컬럼이 'localhost' 의 엔트리가 최초로 일치합니다.이러한 쳐, 공백 유저명의 엔트리가 접속 호스트명과 유저명의 양쪽 모두로 일치합니다('%'/'jeffrey' 엔트리도 일치합니다만, 이것은 테이블내에서의 최초의 맞대어에는 되지 않습니다).

이제(벌써) 1 개예를 나타냅니다.user 테이블이 이하의 내용이다고 합니다.

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| %              | jeffrey  | ...
| thomas.loc.gov |          | ...
+----------------+----------+-

소트 된 테이블은 이하와 같이 됩니다.

+----------------+----------+-
| Host           | User     | ...
+----------------+----------+-
| thomas.loc.gov |          | ...
| %              | jeffrey  | ...
+----------------+----------+-

thomas.loc.gov (으)로부터의 jeffrey 에 의한 접속은 최초의 엔트리와 일치해,whitehouse.gov (으)로부터의 jeffrey 에 의한 접속은 2 번째의 엔트리와 일치합니다.

서버가 접속이 맞대어를 실시할 때, 지정된 유저명을 명시적으로 나타내는 모든 엔트리가 최초로 사용되면 오해하기 쉽상입니다.이것은 잘못되어 있습니다.상기의 예에서도 알도록(듯이),thomas.loc.gov (으)로부터의 jeffrey 에 의한 접속은,'jeffrey' 하지만 User 필드치인 엔트리가 아니고, 유저명 없음의 엔트리와 최초로 일치합니다.

서버에의 접속이 잘 되지 않는 경우,user 테이블을 출력하고, 최초가 맞대어가 어떤 것이나 확인해 주세요. 정상적으로 접속을 해도, 권한이 예기 한 것과 다른 경우,CURRENT_USER() 함수(버젼 4.0.6 그리고 도입)을 사용하고, 그 접속에 실제로 일치하고 있는 유저와 호스트의 편성을 확인할 수 있습니다. See 항6.3.6.2. 「그 외의 각종 함수」 .

4.3.10. 액세스 제어의 단계 2: 요구 확인

접속이 확립하면, 서버는 단계 2 (으)로 이행합니다.그 접속으로의 요구 마다, 서버는 유저에게 그것을 실행할 수 있는 권한이 있을지를, 조작 타입에 근거해 체크합니다.여기서, 권한 테이블의 권한 필드가 관계해 옵니다.권한은,user ,db ,host ,tables_priv ,columns_priv 의 테이블로 설정할 수 있습니다.권한 테이블의 설정은,GRANT 커멘드와 REVOKE 커멘드로 실시합니다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 . 각 권한 테이블의 필드의 리스트에 대해서는, 항4.3.6. 「권한 시스템은 어떻게 기능할까」 (을)를 참조해 주세요.

user 테이블은, 경향 데이타베이스에 관계없이, 유저에 대해서 글로벌하게 권한을 설정합니다.예를 들어,user 테이블로 DELETE 권한이 설정된 유저는, 그 서버 호스트의 어느 데이타베이스의 레코드에서도 삭제할 수 있습니다.즉,user 테이블로 허가된 권한은 슈퍼 유저 권한입니다.user 테이블로 권한을 설정하는 대상은, 서버 관리자나 데이타베이스 관리자등의 슈퍼 유저만 해 두는 것이 현명합니다.다른 유저에 대해서는,user 테이블의 권한을 'N' (으)로 설정해 두어,db 테이블 및 host 테이블을 사용해 데이타베이스 의존으로 권한을 설정해 주세요.

db 테이블 및 host 테이블은, 데이타베이스 의존의 권한을 설정합니다. 스코프 필드에는 다음의 방법으로 값을 지정할 수 있습니다.

  • 와일드 카드 문자의 ‘% ＇ 및 ‘_ ＇ (을)를, 양테이블의 Host 필드와 Db 필드에서 사용할 수 있다.예를 들어,‘_ ＇ 문자를 데이타베이스명의 일부로서 사용하려면 ,GRANT 커멘드로 '\_' (으)로서 지정한다.

  • db 테이블의 '%' Host 값은,`` 임의의 호스트'' (을)를 의미한다.db 테이블의 공백의 Host 값은,``host 테이블을 참조하는 것'' (을)를 의미한다.

  • host 테이블의 '%' 또는 공백의 Host 값은,`` 임의의 호스트'' (을)를 의미한다.

  • 양테이블에 대해 '%' 또는 공백의 Db 값은,`` 임의의 데이타베이스'' (을)를 의미한다.

  • 양테이블에 대해 공백의 User 값은, 익명 유저를 의미한다.

db 테이블 및 host 테이블은, 서버 기동시에 읽어내져 소트 됩니다(user 테이블 읽기와 동시).db 테이블은 Host ,Db , 및 User 의 스코프 필드에서 소트 되어host 테이블은 Host (와)과 Db 의 스코프 필드에서 소트 됩니다.user 테이블에서는, 가장 구체적인 값이 최초로, 가장 추상적인 값이 마지막에 소트 되어 서버에 의한 엔트리가 맞대어에서는, 최초로 일치한 엔트리가 사용됩니다.

tables_priv 테이블과 columns_priv 테이블은 각각, 테이블 의존 및 컬럼 의존의 권한을 설정합니다.스코프 필드에는 다음의 방법으로 값을 지정할 수 있습니다.

  • 와일드 카드 문자의 ‘% ＇ 및 ‘_ ＇ (을)를 양테이블의 Host 필드에서 사용할 수 있다.

  • 양테이블에 대해 '%' 또는 공백의 Host 값은,`` 임의의 호스트'' (을)를 의미한다.

  • 양테이블의 Db ,Table_name ,Column_name 의 각 필드에서, 와일드 카드 및 공백을 사용할 수 없다.

tables_priv 테이블 및 columns_priv 테이블은,Host ,Db , 및 User 의 필드에서 소트 됩니다.이것은 db 테이블의 소트와 같습니다만, 와일드 카드의 사용이 Host 필드에만 한정되므로, 보다 심플합니다.

이하, 요구 확인 프로세스에 대해 설명합니다.액세스 체크의 원시 코드를 알고 있는 독자는, 여기서의 설명과 코드로 사용되는 알고리즘에 조금 차이가 있는 것에 깨달아지겠지만, 설명은 코드가 실제로 실시하는 것과 같고, 차이는 설명을 심플하게하기 위한의 것입니다.

관리 요구(SHUTDOWN ,RELOAD 등)에 대해서, 서버는 user 테이블 엔트리만을 체크합니다.관리 권한을 지정하는 것은 이 테이블뿐이기 (위해)때문입니다.그 엔트리가 요구된 조작을 허가하고 있는 경우는 액세스가 인정되어 그렇지 않은 경우는 거부됩니다.예를 들어,mysqladmin shutdown (을)를 실행하려고 해도,user 테이블 엔트리로 SHUTDOWN 권한이 설정되어 있지 않으면,db 테이블이나 host 테이블을 체크하는 일 없이 액세스는 거부됩니다(이러한 테이블에는 Shutdown_priv 컬럼이 없고, 체크의 필요성이 없습니다).

데이타베이스 관련의 요구(INSERT ,UPDATE 등)에 대해서는, 서버는 최초로,user 테이블 엔트리로 유저의 글로벌(슈퍼 유저) 권한을 체크합니다.여기서, 요구되고 있는 조작이 허가되고 있으면, 액세스가 인정됩니다.user 테이블의 글로벌 권한으로는 충분하지 않은 경우, 서버는 유저의 데이타베이스에 관한 권한을 db 테이블 및 host 테이블로 체크합니다.

  1. 서버는,db 테이블의 Host ,Db ,User 의 각 필드를 체크한다.Host 필드와 User 필드에서는, 접속 유저의 호스트명과 MySQL 유저명이 체크된다.Db 필드에서는, 유저가 액세스 하려고 하고 있는 데이타베이스가 체크된다.Host 및 User 에 해당하는 엔트리가 없는 경우, 액세스는 거부된다.

  2. db 테이블에, 매치하는 엔트리가 있어, 그 Host 필드가 공백이 아니면, 그 엔트리가, 유저의 데이타베이스에 대한 권한을 정의한다.

  3. db 테이블에 있는, 매치하는 엔트리의 Host 필드가 공백의 경우, 이것은 host 테이블이, 데이타베이스에 액세스 할 수 있는 호스트를 지정하는 것을 의미한다.이 경우,host 테이블의 Host 필드와 Db 필드가 체크된다. host 테이블내에 매치하는 엔트리가 없으면, 액세스는 거부된다.매치하는 엔트리가 있으면, 유저의 데이타베이스에 대한 권한이,db 및 host 테이블 엔트리의(화집합에서는 없고 ) 공통 집합으로서 계산된다.이것은, 양쪽 모두의 엔트리로 'Y' (으)로 설정되어 있는 권한을 가리킨다.이와 같이,db 테이블 엔트리로 전반적인 권한을 설정해,host 테이블 엔트리로 호스트 마다 권한을 제한할 수 있다.

서버는,db 및 host 테이블 엔트리로부터 데이타베이스에 대한 권한을 특정하면, 그러한 권한을 user 테이블로 설정되어 있는 글로벌 권한으로 서로 더합니다.그 결과, 요구되고 있는 조작이 허가되고 있으면, 액세스가 인정됩니다.그렇지 않은 경우, 서버는 tables_priv 테이블과 columns_priv 테이블로 유저의 테이블 권한과 컬럼 권한을 체크해, 이것들을 유저의 권한으로 추가합니다.그 결과에 근거해, 액세스가 허가 또는 거부됩니다.

불리언 값으로 나타내면, 상기의 유저 권한 산출법은 이하와 같이 정리할 수 있습니다.

글로벌 권한
OR (database
액세스권 AND host
액세스권)
OR table
액세스권
OR column
액세스권

user 안의 글로벌 권한이 충분하지 않은 경우에, 서버가 그 불충분한 글로벌 권한을, 데이타베이스, 테이블, 및 컬럼 권한과 서로 더하는 이유는 이해하기 어려울지도 하지 않았습니다. 그 이유는, 요구에 복수의 권한이 필요한 경우가 있기 때문입니다.예를 들어,INSERT ... SELECT 스테이트먼트를 실행하려면 ,INSERT 권한 및 SELECT 권한의 양쪽 모두가 필요합니다. 그 중 1 개의 권한이 user 테이블내의 엔트리에 있어, 이제(벌써) 1 개의 권한이 db 테이블내의 엔트리에 있는 경우가 있습니다.그 경우, 요구를 실행하는데 필요한 권한을 유저는 가지고 있습니다만, 서버는 어느 쪽인지 한편의 테이블만으로는 판단할 수 없습니다.이 경우, 양테이블의 엔트리에 있는 권한을 조합할 필요가 있습니다.

host 테이블을 사용하고, 시큐러티로 보호된 서버의 리스트를 관리할 수 있습니다.

TcX DataKonsult AB 그럼,host 테이블에, 로컬 네트워크상의 모든 컴퓨터의 일람을 넣고 있습니다.이것들에 모든 권한을 설정해 있습니다.

host 테이블을 사용하고, 시큐러티로 보호 되어 있지 않다 호스트를 나타낼 수도 있습니다. 시큐러티로 보호되어 있지 않은 공개 에리어내에, 컴퓨터 public.your.domain 하지만 있다고 합니다.이하와 같이,host 테이블의 엔트리를 사용하고, 네트워크내의 그 컴퓨터 이외의 전호스트에게 액세스를 허가할 수 있습니다.

+--------------------+----+-
| Host               | Db | ...
+--------------------+----+-
| public.your.domain | %  | ... (
전권한을 'N'
에 세트)
| %.your.domain      | %  | ... (
전권한을 'Y'
에 세트)
+--------------------+----+-

당연, 권한 테이블은 항상 테스트해(mysqlaccess 등을 사용), 액세스권한이 목적대로 설정되어 있는 것을 확인해 주세요.

4.3.11. MySQL 4.1 의 패스워드 해시

MySQL 유저 어카운트는,mysql 데이타베이스의 user 테이블에 리스트업 되고 있습니다.각 MySQL 어카운트에는 패스워드를 할당할 수 있습니다만,user 테이블의 Password 컬럼에 보존되는 것은 평문텍스트의 패스워드가 아니고, 패스워드로부터 계산된 해시치입니다.패스워드 해시치는,PASSWORD() 함수에 의해서 계산됩니다.

MySQL (은)는, 클라이언트와 서버간 통신의 2 개의 국면으로 패스워드를 사용합니다.

  • 우선, 클라이언트가 서버에 접속하려고 할 때, 초기 인증 스텝으로서 클라이언트는 패스워드를 제시한다.이 패스워드는, 클라이언트가 사용을 희망하는 어카운트의, 유저 테이블에 보존된 해시치와 일치하고 있을 필요가 있다.

  • 다음에, 클라이언트가 접속한 후, 클라이언트는,user 테이블에 포함되어 있는 패스워드 해시를 설정 또는 변경할 수 있다(적절한 권한이 있는 경우).이 때문에는, 클라이언트는,PASSWORD() 함수를 사용해 패스워드 해시를 생성하는지,GRANT 또는 SET PASSWORD 스테이트먼트를 사용한다.

즉, 클라이언트가 최초로 접속하려고 할 때, 서버가 인증하는데 해시치를 사용 합니다.접속한 클라이언트가 PASSWORD() 함수를 실행하거나GRANT 또는 SET PASSWORD 스테이트먼트를 사용해 패스워드의 설정 또는 변경을 실시하면, 서버가 해시치를 생성 합니다.

패스워드 해시 메카니즘은 MySQL 4.1 그리고 갱신되어 시큐러티가 향상해, 패스워드 도난의 위험성이 적게 되고 있습니다. 다만, 이 새로운 메카니즘은 4.1 서버와 4.1 클라이언트 밖에 이해할 수 없기 때문에, 호환성의 문제가 있습니다. 4.1 클라이언트는 패스워드 해시의 신구 메카니즘의 양쪽 모두를 이해할 수 있으므로,4.1 보다 전의 서버라도 접속할 수 있습니다.그러나,4.1 보다 전의 클라이언트가 4.1 서버에 접속하려고 하면, 문제가 발생할 가능성이 있습니다.예를 들어,4.0 mysql 클라이언트가 4.1 서버에 접속하려고 하면, 이하의 에러 메세지가 표시될 가능성이 있습니다.

shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

이하, 이전의 패스워드 메카니즘과 새로운 패스워드 메카니즘과의 달라, 및 서버를 4.1 에 업그레이드 했을 때에 4.1 보다 전의 클라이언트와 호환성을 유지하는 방법에 대해 설명합니다.

주의: 여기서의 설명은 4.1 (와)과 그 이전의 동작을 대비하는 것입니다만, 여기서 설명한다 4.1 의 동작은 실제로는 4.1.1 (으)로부터의 것입니다.MySQL 4.1.0 의 동작은,4.1.1 이?~ 그리고 도입된 메카니즘과 조금 다릅니다.4.1.0 (와)과 그것이?~ 의 버젼과의 차이에 대해서는, 다음에 설명합니다.

MySQL 4.1 보다 전은,PASSWORD() 함수에 의해서 계산되는 패스워드 해시는 16 아르바이트장이었습니다.다음에 예를 나타냅니다.

mysql> SELECT PASSWORD('mypass');
+--------------------+
| PASSWORD('mypass') |
+--------------------+
| 6f8c114b58f2ce9e   |
+--------------------+

MySQL 4.1 보다 전은,user 테이블의 Password 컬럼(해시가 보존되는 장소)도 16 아르바이트장이었습니다.

MySQL 4.1 (으)로부터,PASSWORD() 함수가, 보다 길다 41 아르바이트의 해시치를 생성하게 되어 있습니다.

mysql> SELECT PASSWORD('mypass');
+-----------------------------------------------+
| PASSWORD('mypass')                            |
+-----------------------------------------------+
| *43c8aa34cdc98eddd3de1fe9a9c2c2a9f92bb2098d75 |
+-----------------------------------------------+

따라서, 이 길이의 값을 보존하기 위해(때문에),user 테이블의 Password 컬럼도 41 아르바이트장인 것이 필요합니다.

  • MySQL 4.1 의 신규 인스톨을 실행하면,Password 컬럼은 자동적으로 41 아르바이트장이 된다.

  • 구버젼을 4.1 에 업그레이드 했을 경우,mysql_fix_privilege_tables 스크립트를 실행해 Password 컬럼을 16 아르바이트장으로부터 41 아르바이트장으로 변경할 필요가 있다.이 스크립트는 기존의 패스워드치를 변경하지 않는다.기존의 것은 16 아르바이트장의 까지 있다.

확장되었다 Password 컬럼은, 신구 어느 쪽의 형식의 패스워드 해시도 보존할 수 있습니다.주어진 패스워드 해시치의 형식은 다음의 2 개의 차이에 의해 판단됩니다.

  • 16 아르바이트와 41 아르바이트라고 하는 길이 자체가 다르다.

  • 2 번째의 차이로서는, 새로운 형식의 패스워드 해시는 항상 ‘* ＇ 문자로 시작되어, 구형식의 패스워드는 그 이외의 문자로 시작된다.

긴 패스워드 해시 형식이 암호화의 면에서 뛰어나 클라이언트 인증에 대해 구형식의 짧은 해시보다 시큐러티가 높다고 말할 수 있습니다.

패스워드 해시의 장단의 차이는, 인증시에 서버가 패스워드를 사용하는 방법이라고 패스워드를 변경하는 접속 클라이언트에 대해서 서버가 패스워드 해시를 생성하는 방법에 관계해 옵니다.

인증시에 서버가 패스워드를 사용하는 방법은,Password 컬럼의 폭에 의해 다음과 같은 영향을 받습니다.

  • 컬럼이 짧은 경우, 짧은 해시 인증만이 사용된다.

  • 컬럼이 긴 경우, 장단의 해시 어디라도 보존할 수 있어 서버는 어느 쪽의 형식에서도 사용할 수 있다.

    • 4.1 보다 전의 클라이언트는 접속은 할 수 있어도, 구해시 메카니즘 밖에 이해할 수 없기 때문에, 짧은 해시의 어카운트 밖에 인증할 수 없다.

    • 4.1 클라이언트는, 장단 어느 쪽의 해시의 어카운트에서도 인증할 수 있다.

짧은 해시의 어카운트에서도,4.1 클라이언트가 구클라이언트보다 인증 프로세스의 시큐러티가 조금 향상하고 있습니다.인증의 시큐러티는 이하의 순서로 높아집니다.

  • 짧은 패스워드 해시의 어카운트에 대한다 4.1 보다 전의 클라이언트 인증

  • 짧은 패스워드 해시의 어카운트에 대한다 4.1 클라이언트 인증

  • 긴 패스워드 해시의 어카운트에 대한다 4.1 클라이언트 인증

접속 클라이언트에 대해서 서버가 패스워드 해시를 생성하는 방법은,Password 컬럼의 폭과 --old-passwords 옵션에 의해 영향을 받습니다.4.1 서버는, 다음의 조건이 채워졌을 경우만, 긴 해시를 생성합니다. Password 컬럼이 긴 해시치를 보존할 수 있는 길이인 것, 및 --old-passwords 옵션이 지정되어 있지 않은 것이 필요합니다. 이러한 조건은 이하와 같이 적용됩니다.

  • Password 컬럼이 긴 해시를 보존할 수 있는 길이(41 아르바이트)인 것. 컬럼이 갱신되지 않고,4.1 보다 전의 길이(16 아르바이트)인 채라고, 클라이언트가 PASSWORD() ,GRANT , 또는 SET PASSWORD (을)를 사용해 패스워드 변경 조작을 실시했을 때, 긴 해시가 들어가지 않는 것을 서버가 인식해, 짧은 해시를 생성한다 (4.1 에 업그레이드 했지만,mysql_fix_privilege_tables 스크립트를 실행하지 않고,Password 컬럼이 길어지지 않은 경우에 이와 같이 된다).

  • Password 컬럼이 길면, 장단 어느 쪽의 패스워드 해시도 보존할 수 있다.이 경우, 서버가 --old-passwords 옵션으로 기동되어 있지 않으면,PASSWORD() ,GRANT , 및 SET PASSWORD 에 의해 긴 해시가 생성된다. 이 옵션이 지정되어 있으면, 강제적으로 짧은 패스워드 해시가 생성된다.

--old-passwords 옵션의 목적은, 서버가 긴 패스워드 해시를 생성하는 환경에 있고,4.1 보다 전의 클라이언트와 하위 호환성을 유지할 수 있도록(듯이) 하는 것입니다.이것은 인증에는 영향을 주지 않습니다만(4.1 클라이언트는 긴 패스워드 해시의 어카운트를 사용할 수 있다), 패스워드 변경 조작의 결과로서 user 테이블로 긴 패스워드 해시가 생성되는 것을 막습니다.긴 패스워드 해시가 생성되면, 그 어카운트는 4.1 보다 전의 클라이언트에서는 사용할 수 없게 됩니다.--old-passwords 옵션을 지정하지 않는 경우, 이하의 시나리오가 상정됩니다.

  • 구클라이언트가, 짧은 패스워드 해시의 어카운트에 접속한다.

  • 클라이언트가 어카운트의 패스워드를 변경한다.--old-passwords 하지만 지정되어 있지 않은 경우, 어카운트에 대해서 긴 패스워드 해시가 생성된다.

  • 다음 번, 구클라이언트가 이 어카운트에 접속하려고 해도, 인증시에 어카운트가 신규 해시 메카니즘을 필요로 하기 위해, 접속할 수 없다.user 테이블로 어카운트에 대해서 긴 패스워드 해시가 생성되었을 경우,4.1 클라이언트만 그것을 인증할 수 있다.4.1 보다 전의 클라이언트에서는 긴 해시를 이해할 수 없다.

이 시나리오에서는,4.1 보다 전의 구클라이언트를 서포트할 필요가 있는 경우,--old-passwords 옵션을 사용하지 않고 4.1 서버를 기동하는 것은 위험한 것을 나타내고 있습니다.--old-passwords (을)를 지정해 서버를 기동하는 것으로써, 패스워드 변경 조작을 실시해도 긴 패스워드 해시는 생성되지 않습니다.따라서, 구클라이언트가 어카운트에 액세스 할 수 없게 되는 일이 없습니다( 구클라이언트가, 패스워드 변경시, 우발적으로 긴 패스워드 해시를 생성해 스스로를 록아웃 할 것은 없습니다).

--old-passwords 옵션의 결점은,4.1 클라이언트에서도, 패스워드 작성 또는 변경시에 짧은 해시를 사용하는 것입니다.그 때문에, 긴 패스워드 해시에 의한 높은 시큐러티를 활용할 수 없습니다.4.1 클라이언트용 등에 긴 해시의 어카운트를 작성하고 싶은 경우에는,--old-passwords 없이 서버를 실행할 필요가 있습니다.

4.1 서버의 실행에는 이하의 시나리오가 상정됩니다.

시나리오 1. user 테이블의 짧다 Password 컬럼

  • Password 컬럼에게는 짧은 해시만 보존할 수 있다.

  • 서버는 클라이언트 인증시, 짧은 해시만을 사용한다.

  • 접속 클라이언트는,PASSWORD() ,GRANT , 또는 SET PASSWORD (을)를 사용하는 패스워드 해시 생성 조작으로 짧은 해시만을 사용한다.어카운트의 패스워드를 변경하면, 반드시 짧은 패스워드 해시가 된다.

  • --old-passwords 옵션은 사용할 수 있지만, 의미가 없다.짧다 Password 컬럼에서는, 서버는 짧은 패스워드 해시 밖에 생성하지 않는다.

시나리오 2. 길다 Password 컬럼, 서버를 --old-passwords 옵션 없이 기동

  • Password 컬럼에게는 장단 어느 해시도 보존할 수 있다.

  • 4.1 클라이언트는, 장단 어느 쪽의 해시의 어카운트에서도 인증할 수 있다.

  • 4.1 보다 전의 클라이언트는, 짧은 해시의 어카운트만 인증할 수 있다.

  • 접속 클라이언트는,PASSWORD() ,GRANT , 또는 SET PASSWORD (을)를 사용하는 패스워드 해시 생성 조작으로 긴 해시만을 사용한다.어카운트의 패스워드를 변경하면, 반드시 긴 패스워드 해시가 된다.

  • OLD_PASSWORD() (을)를 사용하고, 명시적으로 짧은 해시를 생성하도록 할 수 있다.예를 들어, 어카운트에 짧은 패스워드를 할당하려면 , 이하와 같이 UPDATE (을)를 사용한다.

    mysql> UPDATE user SET Password = OLD_PASSWORD('mypass')
    -> WHERE Host = 'some_host' AND User = 'some_user';
mysql> FLUSH PRIVILEGES;

상술한 것처럼, 이 시나리오에서는, 짧은 패스워드 해시의 어카운트에,4.1 보다 전의 클라이언트가 액세스 할 수 없게 되는 위험성이 있습니다.GRANT ,SET PASSWORD , 또는 PASSWORD() (을)를 사용해 어카운트의 패스워드를 변경하면, 신규 패스워드 해시가 길어지기 위해,4.1 보다 전의 클라이언트는,4.1 에 업그레이드 하지 않으면 그 어카운트를 인증할 수 없게 됩니다.

시나리오 3. 길다 Password 컬럼, 서버를 --old-passwords 옵션으로 기동

  • Password 컬럼에게는 장단 어느 해시도 보존할 수 있다.

  • 4.1 클라이언트는 장단 어느 해시의 어카운트에서도 인증할 수 있다(주의: 긴 해시의 작성은, 서버를 --old-passwords 없이 기동했을 때만 가능).

  • 4.1 보다 전의 클라이언트는, 짧은 해시의 어카운트만 인증할 수 있다.

  • 접속 클라이언트는,PASSWORD() ,GRANT , 또는 SET PASSWORD (을)를 사용하는 패스워드 해시 생성 조작으로 짧은 해시만을 사용한다.어카운트의 패스워드를 변경하면, 반드시 짧은 패스워드 해시가 된다.

이 시나리오에서는,--old-passwords 에 의해서 긴 해시가 생성되지 않기 때문에, 긴 패스워드 해시의 어카운트를 작성할 수 없습니다.또,--old-passwords 옵션을 사용하기 전에 긴 해시의 어카운트를 작성했을 경우에서도,--old-passwords 의 유효시에 어카운트의 패스워드를 변경하면 짧은 패스워드가 되어 버리므로, 긴 해시가 가지는 시큐러티상의 이점이 없어집니다.

이러한 시나리오의 결점은 각각 이하와 같이 요약할 수 있습니다.

시나리오 1. 시큐러티의 높은 인증을 제공하는 긴 해시를 활용할 수 없다.

시나리오 2. OLD_PASSWORD() (을)를 사용하지 않고 로 패스워드를 변경하면, 짧은 해시의 어카운트에 4.1 보다 전의 클라이언트가 액세스 할 수 없게 된다.

시나리오 3. --old-passwords 에 의해서, 짧은 해시의 어카운트가 액세스 불능이 되는 것은 막아지지만, 긴 해시를 패스워드 변경하면 짧은 해시가 되어 버려,--old-passwords 하지만 유효한 동안은 그것을 원의 길이에 되돌릴 수 없다.

응용 프로그램에 대한 패스워드 해시 변경의 영향

MySQL 4.1 에 업그레이드 하면, 독자적인 목적으로 PASSWORD() (을)를 사용해 패스워드를 생성하는 어플리케이션과의 호환성에 문제가 생깁니다.본래,PASSWORD() 하 MySQL 유저의 패스워드 관리 전용이므로, 어플리케이션으로 이것을 실행해야 하지는 않습니다.그러나 현재 상태로서는, 몇개의 어플리케이션이 독자적인 목적으로 PASSWORD() (을)를 사용하고 있습니다.4.1 에 업그레이드 해, 긴 패스워드 해시가 생성되는 상태로 서버를 실행하면, 독자적인 목적으로 PASSWORD() (을)를 사용하는 어플리케이션은 망가집니다.추천 되는 대처법은, 어플리케이션을 수정해 SHA1() 또는 MD5() 등, 다른 함수를 사용해 해시치를 생성하도록(듯이) 설정하는 것입니다. 그것이 가능하지 않으면,OLD_PASSWORD() 함수를 사용할 수 있습니다.이것은, 구형식의 짧은 해시를 생성하기 위한의 것입니다(주의: 다만,OLD_PASSWORD() (은)는 장래 서포트되지 않게 될 가능성이 있습니다).

짧은 해시를 생성하는 상태로 서버가 실행중의 경우,OLD_PASSWORD() (은)는 이용 가능합니다만,PASSWORD() (와)과 같게 됩니다.

MySQL 4.1.0 의 패스워드 해시는 4.1.1 이?~ 의 패스워드 해시와 다릅니다. 4.1.0 의 차이는 이하대로입니다.

  • 패스워드 해시는 41 아르바이트가 아니고,45 아르바이트장이다.

  • PASSWORD() 함수는 반복해 불가.즉, 특정의 인수 X 그리고, 연속해 PASSWORD(X) (을)를 호출하면 다른 결과가 생성된다.

4.3.12. Access denied 에러의 원인

MySQL 서버에 접속하려고 해 Access denied 에러가 발생했을 경우의 대처법을, 이하에 나타냅니다.

  • MySQL 의 인스톨 후,mysql_install_db 스크립트를 실행해 권한 테이블을 초기설정 하고 있지 않으면, 이것을 실시한다. See 항4.4.4. 「MySQL 권한의 초기설정」 . 이하의 커멘드를 실행해 초기 권한을 테스트한다.

    shell> mysql -u root test

    에러가 발생하는 일 없이 접속할 수 있을 것이다.또,MySQL 데이타베이스 디렉토리에 user.MYD 파일이 있는 것을 확인한다. 통상, 이것은 PATH/var/mysql/user.MYD 이다.여기서 PATH (은)는,MySQL 인스톨처 디렉토리의 패스명이다.

  • 초기 인스톨 후, 서버에 접속해 유저와 그 액세스권을 셋업 한다.

    shell> mysql -u root mysql

    MySQL root 유저에게는, 최초 패스워드가 없기 때문에, 문제 없게 접속할 수 있을 것이다.이것은 시큐러티상의 리스크이기도 하기 위해, 다른 MySQL 유저를 셋업 할 때, 동시에 root 패스워드도 설정해야 한다.

    root (으)로서 접속하려고 해 이하의 에러가 표시되었을 경우

    Access denied for user: '@unknown' to database mysql

    이것은,user 테이블의 User 컬럼에 'root' 값이 없고,mysqld 하지만 클라이언트의 호스트명을 해결할 수 없는 것을 의미한다.이 경우,--skip-grant-tables 옵션으로 서버를 재기동해,/etc/hosts 파일 또는 \windows\hosts 파일을 편집해 호스트의 엔트리를 추가할 필요가 있다.

  • 이하의 에러가 발생했을 경우

    shell> mysqladmin -u root -pxxxx ver
Access denied for user: 'root@localhost' (Using password: YES)

    입력한 패스워드가 올바르지 않은 것을 의미한다. See 항4.4.8. 「패스워드의 설정」 .

    root 의 패스워드를 잊었을 경우,--skip-grant-tables 옵션으로 mysqld (을)를 재기동해 패스워드를 변경할 수 있다. See 항A.4.2. 「잊은 루트 패스워드를 리셋트 하는 방법」 .

    패스워드를 지정하고 있지 않음에도 불구하고 상기의 에러가 발생하는 경우, 어떠한 my.cnf 파일에 올바르지 않은 패스워드가 존재하고 있는 것을 의미한다.See 항4.1.2. 「my.cnf 옵션 설정 파일」 . 이하와 같이 --no-defaults 옵션을 사용하면, 옵션 설정 파일의 사용을 피할 수 있다.

    shell> mysqladmin --no-defaults -u root ver

  • 기존의 MySQL 인스톨을, 버젼 3.22.11 보다 전부터 버젼 3.22.11 이?~ 에 업그레이드 한 다음에,mysql_fix_privilege_tables 스크립트를 실행하고 있지 않으면, 이것을 실행한다.GRANT 스테이트먼트가 도입되었다 MySQL 버젼 3.22.11 그럼, 권한 테이블의 구조가 변경되고 있다. See 항2.5.6. 「권한 테이블의 업그레이드」 .

  • 세션 도중에 권한이 변경되고 있는 것 같으면, 슈퍼 유저가 변경한 가능성이 있다.권한 테이블을 재독 봐 , 새로운 클라이언트 접속에 영향을 주어, 또, 항4.4.3. 「권한의 변경은 언제 반영될까」 그리고 설명되고 있도록(듯이), 기존의 접속에도 영향을 준다.

  • 패스워드가 기능하지 않는 경우에 INSERT ,UPDATE , 또는 SET PASSWORD 스테이트먼트를 사용해 패스워드를 설정할 때 PASSWORD() 함수를 사용하는 것이 필요하다.GRANT ... IDENTIFIED BY 스테이트먼트 또는 mysqladmin password 커멘드를 사용해 패스워드를 지정하는 경우에는,PASSWORD() 함수는 불필요하다. See 항4.4.8. 「패스워드의 설정」 .

  • localhost (은)는, 유저의 로컬 호스트명의 동의어이다.또, 호스트를 명시적으로 지정하지 않고 클라이언트가 접속하려고 했을 경우의 디폴트 호스트이기도 하다.다만,MIT-pthread (을)를 사용하는 버젼 3.23.27 보다 전의 MySQL (을)를 사용하고 있는 경우,localhost 에의 접속은 행해지지 않는다(localhost 접속은 Unix 소켓을 사용해 행해지지만, 이것은 당시의 MIT-pthread 에는 서포트되어 있지 않았다).이러한 시스템으로 이 문제를 회피하려면 ,--host 옵션을 사용해 서버 호스트를 명시적으로 지정한다.이것에 의해,mysqld 서버에의 TCP/IP 접속을 한다.이 경우, 서버 호스트의 user 테이블 엔트리에 실제의 호스트명이 있는 것이 필요하다(이것은, 서버와 같은 호스트상에서 클라이언트 프로그램을 실행하고 있는 경우도 마찬가지이다).

  • mysql -u user_name db_name 그리고 데이타베이스에 접속하려고 해 Access denied 에러가 발생하는 경우,user 테이블에 문제가 있을 가능성이 있다.mysql -u root mysql (을)를 실행해, 이하의 SQL 스테이트먼트를 실행하고, 이것을 체크한다.

    mysql> SELECT * FROM user;

    이 결과에, 사용 컴퓨터의 호스트명 및 MySQL 유저명으로 매치한다 Host 컬럼 및 User 컬럼의 엔트리가 포함되지 않으면 안 된다.

  • Access denied 에러 메세지에는, 로그인하려고 하고 있는 유저명, 접속원의 호스트, 및 패스워드를 사용했는지가 나타난다.통상, 에러 메세지로 표시된 호스트명과 유저명에 완전하게 매치하는 엔트리가 1 개,user 테이블에 존재하고 있지 않으면 안 된다.Using password: NO (을)를 포함한 에러 메세지가 표시되었을 경우, 패스워드 없이 로그인하려고 한 것을 의미한다.

  • MySQL 서버를 실행하고 있는 호스트 이외의 호스트로부터 접속하려고 해 이하의 에러가 발생하는 경우, 그 호스트와 일치하는 레코드가 user 테이블에 없다고 하는 것이다.

    Host ... is not allowed to connect to this MySQL server

    이것을 해결하려면 , 커멘드 라인 툴 mysql (을)를 서버 호스트상에서 사용하고,user ,db , 또는 host 테이블에, 접속하려고 하고 있는 유저와 호스트명의 편성의 레코드를 추가해,mysqladmin flush-privileges (을)를 실행한다. 실행하고 있다 MySQL 하지만 버젼 3.22 (이)가 아니고, 접속하려고 하고 있는 컴퓨터의 IP 주소 또는 호스트명을 모르는 경우,user 테이블의 Host 컬럼에 '%' (을)를 설정해, 서버머신상에서 --log 옵션을 사용해 mysqld (을)를 재기동한다.클라이언트 머신으로부터 접속을 시행하면,MySQL 로그의 정보에 의해, 실제의 접속이 어떻게 행해졌는지 안다.다음에,user 테이블 엔트리의 '%' 의 값을, 로그로 표시된 실제의 호스트명에 옮겨놓는다.그렇게 하지 않으면 시스템의 시큐러티를 유지할 수 없다.

    Linux 위에서 이 문제가 발생했을 경우, 생각할 수 있는 다른 원인으로서는, 사용하고 있다 glibc (와)과는 다른 버젼의 glibc 그리고 컴파일 된 바이너리 MySQL 버젼을 사용하고 있는 것을 들 수 있다.이 경우,OS/glibc (을)를 업그레이드 하는지, 소스 MySQL 버젼을 다운로드해 스스로 컴파일 한다.소스 RPM (은)는 통상, 컴파일 및 인스톨이 간단해서, 이것은 큰 문제는 아니다.

  • 호스트명으로 접속하려고 했음에도 불구하고, 에러 메세지에 호스트명이 표시되지 않는, 또는 호스트명이 IP 그리고 표시되는 경우

    shell> mysqladmin -u root -pxxxx -h some-hostname ver
Access denied for user: 'root@' (Using password: YES)

    이것은,IP (으)로부터 호스트명에 역당겨 하려고 했을 때에 MySQL 그리고 에러가 발생한 것을 의미한다.이 경우,mysqladmin flush-hosts (을)를 실행해 내부 DNS 캐쉬를 리셋트 할 수 있다. See 항5.5.5. 「MySQL 의 DNS 의 사용」 .

    항구적인 해결 방법

    • DNS 서버로의 문제점을 찾아내 그것을 수정한다.

    • MySQL 권한 테이블로, 호스트명 대신에 IP (을)를 지정한다.

    • --skip-name-resolve 옵션으로 mysqld (을)를 개시한다.

    • --skip-host-cache 옵션으로 mysqld (을)를 개시한다.

    • 같은 머신상에서 서버와 클라이언트를 실행하고 있는 경우는,localhost 에 접속한다.

    • /etc/hosts 에 클라이언트 머신명을 기입한다.

  • mysql -u root test (은)는 정상 종료하는데 mysql -h your_hostname -u root test 그럼 Access denied 되는 경우,user 테이블에 올바른 호스트명이 없을 가능성이 있다. 통상, 이러한 경우,user 테이블 엔트리의 Host 값이 완전 수식되어 있지 않은 호스트명을 지정해, 시스템의 이름 해석 루틴이 완전 수식된 도메인명을 돌려주고 있다(또는 그 역). 예를 들어,user 테이블에 호스트 'tcx' 의 엔트리가 있지만,DNS 에 MySQL 에 호스트명으로서 'tcx.subnet.se' (을)를 지시했을 경우, 이것은 기능하지 않는다.이 경우,Host 컬럼치로서 호스트의 IP 주소를 가진다 user 테이블 엔트리를 추가해 본다.또는,Host 값으로 해서 'tcx.%' 등의 와일드 카드를 포함한다 user 테이블 엔트리를 추가할 수도 있다.다만,‘% ＇ 그리고 끝나는 호스트명의 사용은, 안전하지 않다 의로, 추천 할 수 없다 .

  • mysql -u user_name test (은)는 정상 종료하는데,mysql -u user_name other_db_name 그럼 에러가 발생하는 경우,db 테이블에 other_db_name 의 엔트리가 없다.

  • 서버머신에서는 mysql -u user_name db_name 하지만 동작하는데, 다른 클라이언트 머신에서는 mysql -h host_name -u user_name db_name 하지만 동작하지 않는 경우,user 테이블 또는 db 테이블에 클라이언트 머신이 등록되지 않았다.

  • Access denied 의 원인을 모르는 경우는,user 테이블에서 Host 값에 와일드 카드가 포함되어 있는 엔트리(‘% ＇ 또는 ‘_ ＇ (을)를 포함한 엔트리)를 모두 삭제한다. 자주 있는 실수는,Host='%' 및 User='some user' 의 신규 엔트리를 삽입해, 이것으로, 동일 머신으로부터 접속할 때 localhost (을)를 지정할 수 있다고 생각하고 있는 것이다.이것이 잘 되지 않는 이유는, 디폴트 권한으로서Host='localhost' 및 User='' 의 엔트리가 포함되어 있기 때문에 있다.Host 값이 'localhost' 의 경우,'%' 보다 구체적이기 때문에,localhost (으)로부터의 접속시에 새로운 엔트리보다 디폴트 권한이 우선된다.올바른 지정의 방법은,Host='localhost' 및 User='some_user' 의 2 번째의 엔트리를 삽입하는지,Host='localhost' 및 User='' 의 엔트리를 삭제하는 것이다.

  • 이하의 에러가 발생했을 경우,db 테이블 또는 host 테이블에 문제가 있을 가능성이 있다.

    Access to database denied

    db 테이블의 Host 컬럼에 공백치가 있는 경우, 그 db 테이블 엔트리에 대해서 호스트를 지정하는 엔트리가 1 개이상,host 테이블에 존재하고 있는 것을 확인한다.

    SQL 커멘드 SELECT ...INTO OUTFILE 또는 LOAD DATA INFILE 사용시에 에러가 발생하는 경우,user 테이블의 해당 엔트리로 FILE 권한이 유효화 되어 있지 않다고 생각할 수 있다.

  • 클라이언트 프로그램은, 옵션 설정 파일 또는 환경 변수로 지정된 접속 파라미터를 사용한다.See 부록 F. 환경 변수 . 커멘드 라인으로 접속 파라미터를 지정하지 않았을 때에, 클라이언트가 잘못된 디폴트의 접속 파라미터를 보내고 있는 것 같으면, 홈 디렉토리의 .my.cnf 파일 및 환경 변수를 확인한다.시스템 레벨의 MySQL 옵션 설정 파일도 확인할 수 있지만, 여기서 클라이언트 접속 파라미터가 지정되어 있을 가능성은 낮다.See 항4.1.2. 「my.cnf 옵션 설정 파일」 . 클라이언트를 옵션 없이 실행해 Access denied 하지만 발생하는 경우, 옵션 설정 파일에 낡은 패스워드가 지정되어 있지 않은가 확인한다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

  • 권한 테이블을(INSERT 또는 UPDATE 스테이트먼트를 사용해) 직접 변경했을 경우, 그 변경은 무시된 것처럼 보이는 일이 있다.서버에 권한 테이블을 재독 봐 시키려면 ,FLUSH PRIVILEGES 스테이트먼트를 발행할까 mysqladmin flush-privileges 커멘드를 실행할 필요가 있다.이것을 실시하지 않는 경우, 변경은 다음 번의 서버 재기동시까지 유효가 되지 않는다.UPDATE 커멘드로 root 패스워드를 설정해도, 권한을 플래시 할 때까지는, 패스워드가 변경된 것을 서버가 아직 인식하지 않기 때문에, 그 패스워드를 지정할 필요는 없다.

  • Perl ,PHP ,Ruby ,Python , 또는 ODBC 프로그램으로 액세스에 문제가 있었을 경우,mysql -u user_name db_name 또는 mysql -u user_name -pyour_pass db_name (을)를 사용해 접속해 본다.mysql 클라이언트를 사용해 접속할 수 있는 경우, 문제는 프로그램에 있어, 액세스권한에는 없다. 주의: -p (와)과 패스워드의 사이에 스페이스는 들어갈 수 없다.또,--password=your_pass 구문을 사용해 패스워드를 지정할 수도 있다.-p 옵션만을 사용했을 경우, 패스워드가 요구된다.

  • 테스트용으로,--skip-grant-tables 옵션으로 mysqld demon를 개시한다.다음에 MySQL 권한 테이블을 변경해, 변경에 의해서 의도한 결과가 얻어지고 있는지 어떤지 mysqlaccess 스크립트를 사용해 체크할 수 있다.변경이 의도했던 대로이면,mysqladmin flush-privileges (을)를 실행해, 새로운 권한 테이블을 사용해 기동하도록(듯이) mysqld 서버에 지시한다. 주의: 권한 테이블을 재독 봐,--skip-grant-tables 옵션이 무효가 된다.이것에 의해, 서버를 슛다운 해 재기동하는 일 없이, 권한 테이블의 사용을 시작할 수 있다.

  • 상기의 머지않아로도 잘 되지 않는 경우는, 디버그 옵션(--debug=d,general,query 등)으로 mysqld demon를 개시한다.시험 받은 접속에 관한 호스트 정보, 유저 정보, 및 발행된 각 커멘드에 관한 정보가 출력된다. See 항E.1.2. 「트레이스 파일의 작성」 .

  • MySQL 권한 테이블에 관한 그 외의 문제가 발생해, 그 취지 메일링 리스트에 투고하는 경우는,MySQL 권한 테이블의 덤프도 반드시 제공하는 것.mysqldump mysql 커멘드를 사용하면 권한 테이블을 덤프 할 수 있다.문제를 투고할 때는, 반드시 mysqlbug 스크립트를 사용하는 것.See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 . mysqldump (을)를 실행할 때,--skip-grant-tables 그리고 mysqld (을)를 재기동하는 것이 필요한 경우도 있다.


4.4. MySQL 의 유저 관리

4.4.1. GRANT 및 REVOKE 의 구문

GRANT priv_type [(column_list)] [, priv_type [(column_list)] ...]
    ON {tbl_name | * | *.* | db_name.*}
    TO user_name [IDENTIFIED BY [PASSWORD] 'password']
        [, user_name [IDENTIFIED BY [PASSWORD] 'password'] ...]
    [REQUIRE
        NONE |
        [{SSL| X509}]
        [CIPHER cipher [AND]]
        [ISSUER issuer [AND]]
        [SUBJECT subject]]
    [WITH [GRANT OPTION | MAX_QUERIES_PER_HOUR # |
                          MAX_UPDATES_PER_HOUR # |
                          MAX_CONNECTIONS_PER_HOUR #]]

REVOKE priv_type [(column_list)] [, priv_type [(column_list)] ...]
    ON {tbl_name | * | *.* | db_name.*}
    FROM user_name [, user_name ...]

GRANT (은)는,MySQL 버젼 3.22.11 이?~ 그리고 실장되고 있습니다.그것보다 전의 MySQL 버젼에서는,GRANT 스테이트먼트는 아무것도 하지 않습니다.

시스템 관리 책임자는,GRANT 커멘드와 REVOKE 커멘드를 사용하고, 유저를 작성해,MySQL 유저에 대해서 다음의 4 개의 레벨의 권한을 주거나 취소할 수 있습니다.

  • 글로벌 레벨

    글로벌 권한은 특정의 서버상의 모든 데이타베이스에 적용된다.이러한 권한은,mysql.user 테이블에 보존된다. GRANT ALL ON *.* 및 REVOKE ALL ON *.* (은)는, 글로벌 권한의 부여 및 취소만을 실시한다.

  • 데이타베이스 레벨

    데이타베이스 권한은, 지정한 데이타베이스의 모든 테이블에 적용된다.이러한 권한은,mysql.db 테이블 및 mysql.host 테이블에 보존된다. GRANT ALL ON db.* 및 REVOKE ALL ON db.* (은)는, 데이타베이스 권한의 부여 및 취소만을 실시한다.

  • 테이블 레벨

    테이블 권한은, 지정한 테이블의 모든 컬럼에 적용된다.이러한 권한은,mysql.tables_priv 테이블에 보존된다. GRANT ALL ON db.table 및 REVOKE ALL ON db.table (은)는, 테이블 권한의 부여 및 취소만을 실시한다.

  • 컬럼 레벨

    컬럼 권한은, 지정한 테이블의 하나의 컬럼에 적용된다.이러한 권한은,mysql.columns_priv 테이블에 보존된다. REVOKE (을)를 사용할 때는, 대상이 되는 컬럼을 지정하는 것이 필요하다.

GRANT 및 REVOKE 스테이트먼트의 priv_type 에는 이하의 어느쪽이든을 지정할 수 있습니다.

ALL [PRIVILEGES] | WITH GRANT OPTION 이외의 모든 권한을 설정
ALTER | ALTER TABLE 의 사용을 허가
CREATE | CREATE TABLE 의 사용을 허가
CREATE TEMPORARY TABLES | CREATE TEMPORARY TABLE 의 사용을 허가
DELETE | DELETE 의 사용을 허가
DROP | DROP TABLE 의 사용을 허가
EXECUTE | Stored Procedure의 사용을 허가(MySQL 5.0 )
FILE | SELECT ... INTO OUTFILE 및 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 | replication의 슬레이브에 필요(마스터로부터 바이너리 로그를 읽어내기 위해)
SELECT | SELECT 의 사용을 허가
SHOW DATABASES | SHOW DATABASES 에 의해 모든 데이타베이스가 표시된다
SHUTDOWN | mysqladmin shutdown 의 사용을 허가
SUPER | 최대 접속수에 이르고 있어도 접속을 1 개만 허가해, 커멘드 CHANGE MASTER ,KILL thread ,mysqladmin debug ,PURGE MASTER LOGS , 및 SET GLOBAL 의 실행을 허가
UPDATE | UPDATE 의 사용을 허가
USAGE | `` 권한 없음'' 의 동의어
GRANT OPTION | WITH GRANT OPTION 의 동의어

USAGE (을)를 사용하면, 권한 없음의 유저를 작성할 수 있습니다.

CREATE TEMPORARY TABLES ,EXECUTE ,LOCK TABLES ,REPLICATION ... ,SHOW DATABASES , 및 SUPER (은)는, 버젼 4.0.2 그리고 새롭게 도입된 권한입니다.4.0.2 에 업그레이드 한 다음에 이러한 권한을 사용하려면 ,mysql_fix_privilege_tables 스크립트를 실행할 필요가 있습니다. See 항2.5.6. 「권한 테이블의 업그레이드」 .

낡다 MySQL 버젼에서는,PROCESS 권한이 새롭다 SUPER 권한과 같은 기능을 합니다.

유저의 GRANT 권한을 취소하려면 , 다음과 같이 priv_type 값으로 해서 GRANT OPTION (을)를 사용합니다.

mysql> REVOKE GRANT OPTION ON ... FROM ...;

테이블에 대해서 지정할 수 있다 priv_type 값은,SELECT ,INSERT ,UPDATE ,DELETE ,CREATE ,DROP ,GRANT OPTION ,INDEX , 및 ALTER 뿐입니다.

컬럼에 대해서 지정할 수 있다(즉,column_list 마디를 사용하는 경우의)priv_type 값은,SELECT ,INSERT , 및 UPDATE 뿐입니다.

MySQL 그럼, 데이타베이스가 존재하지 않는 경우에서도 데이타베이스 레벨의 권한을 작성할 수 있어 데이타베이스 사용의 준비를 실시할 수 있습니다. 다만 현재로서는, 테이블이 존재하지 않는 경우에는 테이블 레벨의 권한은 작성할 수 없습니다.테이블이나 데이타베이스를 파기했을 경우에서도,MySQL 하지만 자동적으로 권한을 취소할 것은 없습니다.

글로벌 권한은 ON *.* 구문을 사용해 설정할 수 있습니다.데이타베이스 권한은 ON db_name.* 구문을 사용해 설정할 수 있습니다.ON * (을)를 지정했을 때에 경향 데이타베이스가 있으면, 그 데이타베이스의 권한이 설정됩니다. 경고: ON * (을)를 지정했을 때에 경향 데이타베이스가 없으면 , 글로벌 권한으로 영향을 줍니다.

주의: GRANT 커멘드로 데이타베이스명을 지정할 때,‘_ ＇ 및 ‘% ＇ 와일드 카드를 사용할 수 있습니다.데이타베이스명의 일부로서 예를 들어 ‘_ ＇ 문자를 사용하고 싶은 경우,GRANT 커멘드에서는 GRANT ... ON `foo\_bar`.* TO ... 등과 같이,'\_' (으)로서 지정하도록(듯이) 해 주세요.그렇게 하지 않으면 와일드 카드 패턴에 일치하는 다른 데이타베이스에도 유저가 액세스 할 수 있게 됩니다.

MySQL 그럼, 임의의 호스트의 유저에게 권한을 부여할 수 있도록,user_name 값을 user@host 형식에서 지정할 수 있게 되어 있습니다.특수 문자(‘- ＇ 등)을 포함한다 user 문자열을 지정하거나 특수 문자 또는 와일드 카드 문자(‘% ＇ 등)을 포함한다 host 문자열을 지정하고 싶은 경우, 유저명 또는 호스트명을 인용부호로 둘러쌀 수 있습니다(예를 들어,'test-user'@'test-hostname' ).

호스트명에 와일드 카드를 사용할 수 있습니다.예를 들어,user@'%.loc.gov' 하 loc.gov 도메인의 어느 호스트의 user 에도 들어맞아,user@'144.155.166.%' 하 144.155.166 클래스 C 목의 호스트의 user 에도 들어맞읍니다.

심플한 형식 user 하 user@"%" 의 동의어입니다.

MySQL 그럼, 유저명으로의 와일드 카드 사용을 서포트하고 있지 않습니다.익명 유저의 정의에는,User='' 의 엔트리를 mysql.user 테이블에 삽입하는지,GRANT 커멘드로 공백명의 유저를 작성합니다.

주의: 익명 유저가 MySQL 서버에 접속할 수 있게 하는 경우, 모든 로컬 유저에 대해서,user@localhost (으)로서 권한을 설정할 필요가 있습니다.그렇게 하지 않으면 유저가 로컬 머신으로부터 MySQL 서버에 로그인하려고 했을 때에,mysql.user 테이블의 로컬 호스트의 익명 유저 엔트리가 사용되기 때문입니다.

이것을 확인하려면 , 이하의 쿼리를 실행합니다.

mysql> SELECT Host,User FROM mysql.user WHERE User='';

현재로서는,GRANT 그럼 호스트, 테이블, 데이타베이스, 및 컬럼의 이름에 최대 60 문자까지 사용할 수 있습니다.유저명은 최대 16 문자까지입니다.

테이블 또는 컬럼에 대한 권한은,4 개의 레벨의 권한의 논리합(OR )(으)로 형성됩니다.예를 들어,mysql.user 테이블로 유저에게 글로벌 SELECT 권한이 설정되어 있는 경우, 이것이 데이타베이스, 테이블, 또는 컬럼 레벨의 엔트리로 거부될 것은 없습니다.

컬럼에 대한 권한은 이하와 같이 계산됩니다.

global privileges
OR (database privileges AND host privileges)
OR table privileges
OR column privileges

많은 경우, 유저에게의 권한 설정에는 권한 레벨을 1 개 밖에 사용하지 않기 때문에, 위에서 설명한 바와 같이 복잡하게는 되지 않습니다.권한 체크 프로시저의 상세한 것에 대하여는, 항4.3. 「일반적인 시큐러티 관련 사항과 MySQL 액세스 제어 시스템」 (을)를 참조해 주세요.

mysql.user 테이블에 존재하지 않는 유저와 호스트명의 조합해에 권한을 부여하면, 그 엔트리는 테이블에 추가되어DELETE 커멘드로 삭제될 때까지 거기에 남습니다.즉,GRANT 그리고 user 테이블 엔트리를 작성할 수 있습니다만,REVOKE 그럼 그 엔트리를 삭제할 수 없습니다.삭제하려면 명시적으로 DELETE (을)를 사용할 필요가 있습니다.

MySQL 버젼 3.22.12 이?~ 그럼, 신규 유저가 작성되었을 경우, 또는 글로벌 권한을 부여하는 경우,IDENTIFIED BY 마디로 패스워드가 지정되어 있으면, 그것이 그 유저의 패스워드가 됩니다.벌써 유저에게 패스워드가 있는 경우는, 새로운 패스워드로 옮겨집니다.

텍스트 형식에서 패스워드를 송신하는 것이 바람직하지 않으면,PASSWORD 옵션을 사용하고,SQL 함수 PASSWORD() 또는 C API 함수 make_scrambled_password(char *to, const char *password) 그리고 생성한 암호화 패스워드를 설정할 수 있습니다.

경고: 신규 유저를 작성했을 때,IDENTIFIED BY 마디를 지정하지 않으면 그 유저는 패스워드없이 됩니다.즉, 위험합니다.

패스워드의 설정에는,SET PASSWORD 커멘드를 사용할 수도 있습니다. See 항5.5.6. 「SET 구문」 .

데이타베이스에 대한 권한을 설정하는 경우, 필요에 따라서 mysql.db 테이블에 엔트리가 작성됩니다.REVOKE 그리고 그 데이타베이스의 모든 권한이 삭제되면, 이 엔트리도 삭제됩니다.

유저가 테이블에 어떤 권한도 가지고 있지 않은 경우,SHOW TABLES 스테이트먼트등에서 테이블의 리스트를 요구해도, 테이블은 표시되지 않습니다.SHOW DATABASES 그렇지만 같습니다.

WITH GRANT OPTION 마디를 사용하면, 유저는 자신이 소유하는 권한을 다른 유저에게 줄 수 있습니다. GRANT 권한을 유저로 설정할 때는 주의가 필요합니다.2 사람의 유저가 서로의 권한을 조합하는 것이 가능하게 되기 때문입니다.

MAX_QUERIES_PER_HOUR # ,MAX_UPDATES_PER_HOUR # , 및 MAX_CONNECTIONS_PER_HOUR # 하 MySQL 버젼 4.0.2 그리고 새롭게 도입되었습니다. 이러한 옵션은,1 시간에 유저가 실행할 수 있는 쿼리, 갱신, 및 로그인의 회수를 제한합니다.# 하지만 0 (디폴트)의 경우, 그 유저에게 제한은 없다고 하는 것입니다. See 항4.4.7. 「유저 자원의 제한」 . 주의: 기존 유저에게 추가 권한을 설정하는 일 없이 이러한 옵션을 지정하려면 ,GRANT USAGE ON *.* ... WITH MAX_... (을)를 사용합니다.

자기 자신이 가지고 있지 않은 권한을 다른 유저에게 줄 수 없습니다.GRANT 권한에서는, 자신이 소유하는 권한만을 다른 유저에게 줄 수 있습니다.

어느 레벨의 GRANT 권한을 유저로 설정하면, 그 유저가 그 레벨로 소유하는( 및 장래 소유한다) 모든 권한을, 그 유저는 다른 유저로 설정할 수 있는 것에 주의해 주세요. 어느 유저에게 데이타베이스에 대한다 INSERT 권한을 부여했다고 가정합니다.다음에 데이타베이스의 SELECT 권한을 부여할 때 WITH GRANT OPTION (을)를 지정했을 경우, 그 유저는 SELECT 권한 뿐만이 아니라 INSERT 권한도 다른 유저에게 줄 수 있습니다.한층 더 데이타베이스의 UPDATE 권한을 그 유저에게 주면, 그 유저는 INSERT ,SELECT , 및 UPDATE 권한을 다른 유저에게 줄 수 있게 됩니다.

ALTER 권한은 일반 유저에게는 부여하지 말아 주세요.설정하면, 그 유저는 테이블의 이름을 변경하고, 권한 시스템을 찢을 수 있게 됩니다.

주의: 1 사람의 유저에게만 테이블 권한 또는 컬럼 권한을 설정했을 경우에서도, 서버는 모든 유저의 테이블 권한과 컬럼 권한을 조사하기 위해,MySQL 의 처리 속도는 조금 저하합니다.

mysqld 의 기동시, 모든 권한이 메모리에 읽힙니다. 데이타베이스 권한, 테이블 권한, 및 컬럼 권한은 곧바로 반영됩니다만, 유저 레벨의 권한은 유저가 다음 번 접속했을 때에 유효가 됩니다. GRANT 또는 REVOKE 에 의해서 행해진 권한 테이블에의 변경에 대해서는, 서버는 즉석에서 인식합니다. INSERT ,UPDATE 등을 사용해 수동으로 권한 테이블을 변경했을 경우,FLUSH PRIVILEGES 스테이트먼트 또는 mysqladmin flush-privileges (을)를 실행해 서버에 권한 테이블을 재독 봐 시킬 필요가 있습니다. See 항4.4.3. 「권한의 변경은 언제 반영될까」 .

GRANT 의 표준 SQL 의 버젼과 MySQL 버젼으로의 최대의 차이는 이하대로입니다.

  • MySQL 의 권한은, 유저명만이 아니고, 유저명과 호스트명의 편성으로 지정된다.

  • SQL-99 에는 글로벌 권한 및 데이타베이스 레벨의 권한이 없고,MySQL 하지만 서포트하는 타입의 권한 모든 것을 서포트하지 않는다. MySQL (은)는,SQL-99 의 TRIGGER 권한과 UNDER 권한을 서포트하지 않는다.

  • SQL-99 권한은, 계층적으로 구성되어 있다.어느 유저를 삭제하면, 그 유저로 설정 떠날 수 있어 모든 권한이 삭제된다.MySQL 그럼, 설정된 권한이 자동적으로 삭제될 것은 없고, 필요한 경우는 스스로 취소할 필요가 있다.

  • MySQL 그럼, 테이블의 일부의 컬럼으로 INSERT 권한이 설정되어 있는 경우, 그 테이블에 대해서 INSERT 스테이트먼트를 실행할 수 있다.이 경우,INSERT 권한이 없는 컬럼에게는 디폴트치가 설정된다.SQL-99 그럼, 모든 컬럼으로 INSERT 권한이 필요하다.

  • SQL99 그리고 테이블을 파기하면, 그 테이블의 모든 권한이 삭제된다. SQL-99 그럼,1 개의 권한을 취소하면, 그 권한을 베이스로 하는 모든 권한도 삭제된다.MySQL 그리고 권한을 파기하려면 , 명시적으로 REVOKE 커멘드를 사용할까 MySQL 권한 테이블을 조작하는 것이 필요하다.

REQUIRE 의 사용법에 대해서는, 항4.4.10. 「안전한 접속의 사용」 (을)를 참조해 주세요.

4.4.2. MySQL 의 유저명과 패스워드

MySQL (으)로의 유저명 및 패스워드의 사용법과Unix 및 Windows (으)로의 사용법에는 몇개의 차이점이 있습니다.

  • MySQL 그리고 인증 목적으로 사용하는 패스워드는,Unix 유저명(로그인명)이나 Windows 유저명과는 관계없다.대부분의 MySQL 클라이언트는 디폴트로, 현재의 Unix 유저명을 MySQL 유저명으로서 로그인하려고 하지만, 이것은 편리성이기 때문에 뿐이다. 클라이언트 프로그램으로,-u 옵션 또는 --user 옵션에 의해 다른 이름을 지정하는 것이 가능하다.이것은, 모든 MySQL 유저명에 패스워드를 설정하지 않으면 데이타베이스를 안전하게 유지할 수 없는 것을 의미한다.패스워드를 설정하지 않으면, 누구라도 임의의 이름으로 서버에의 접속을 시도할 수 있어 패스워드가 없는 이름을 지정하면 접속에 성공해 버린다.

  • MySQL 유저명에는 최대 16 문자까지 사용할 수 있지만,Unix 유저명은 통상 8 문자까지.

  • MySQL 패스워드는,Unix 패스워드와 관계없다.Unix 머신에 로그인하는 패스워드와 그 머신으로 데이타베이스에 액세스하기 위한 패스워드에는 관련성이 없다.

  • MySQL 그럼,Unix 로그인 프로세스로 사용되는 알고리즘과는 다른 알고리즘으로, 패스워드를 암호화한다.PASSWORD() 함수 및 ENCRYPT() 함수의 상세한 것에 대하여는, 항6.3.6.2. 「그 외의 각종 함수」 (을)를 참조.주의: 패스워드가 ' 암호화' 되어 격납되고 있어도, 그 ' 암호화' 된 패스워드를 아는 것만으로 MySQL 서버에 접속할 수 있다. 버젼 4.1 보다 ,MySQL (은)는 종래와는 다른 패스워드와 로그인 메카니즘을 채용하고 있어TCP/IP 패킷이 스니후 되거나mysql 데이타베이스가 capther 되었을 경우에서도 시큐러티를 보관 유지할 수 있게 되어 있다.

MySQL 유저 및 그 권한은 통상,GRANT 커멘드로 작성합니다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

MySQL 서버에 커멘드 라인 클라이언트로 로그인하는 경우는,--password=your-password 그리고 패스워드를 지정해 주세요. See 항4.3.8. 「MySQL 서버에의 접속」 .

mysql --user=monty --password=guess database_name

클라이언트에 패스워드를 요구시키고 싶은 경우에는, 인수 없이 --password (을)를 사용합니다.

mysql --user=monty --password database_name

또는 다음의 짧은 형식

mysql -u monty -p database_name

주의: 상기의 예로, 패스워드가 'database_name' (뜻)이유에서는 없습니다 .

-p 옵션을 사용해 패스워드를 지정하려면 , 이하와 같이 실시합니다.

mysql -u monty -pguess database_name

시스템에 따라서는,MySQL 하지만 패스워드를 요구할 때의 라이브러리 콜에 의해, 자동적으로 패스워드가 8 문자에 절약할 수 있습니다.MySQL 의 내부에서는, 패스워드장에 제한은 없습니다.

4.4.3. 권한의 변경은 언제 반영될까

mysqld 의 기동시, 모든 권한 테이블이 메모리에 읽혀 이 시점에서 유효가 됩니다.

GRANT ,REVOKE , 또는 SET PASSWORD (을)를 사용해 간 권한 테이블의 변경은, 곧바로 서버에 인식됩니다.

INSERT ,UPDATE 등을 사용해 수동으로 권한 테이블을 변경했을 경우,FLUSH PRIVILEGES 스테이트먼트,mysqladmin flush-privileges , 또는 mysqladmin reload (을)를 실행해 서버에 권한 테이블을 재독 봐 시킬 필요가 있습니다.그렇게 하지 않으면, 서버를 재기동할 때까지, 변경은 반영되지 않습니다 .권한 테이블을 수동으로 변경한 후, 권한의 재독 봐 포함을 잊으면, 당연히 변경은 반영되지 않습니다.

서버가 권한 테이블의 변경을 인식하면, 기존의 클라이언트 접속은 이하와 같은 영향을 받습니다.

  • 테이블 권한과 컬럼 권한의 변경은, 클라이언트의 다음 번의 요구로부터 반영된다.

  • 데이타베이스 권한의 변경은, 다음 번의 USE db_name 커멘드로부터 반영된다.

  • 글로벌 권한의 변경 및 패스워드의 변경은, 클라이언트의 다음 번의 접속으로부터 반영된다.

4.4.4. MySQL 권한의 초기설정

MySQL 의 인스톨 후,scripts/mysql_install_db (을)를 실행해 액세스권한을 초기설정 합니다. See 항2.3.1. 「퀵 인스톨의 개요」 . mysql_install_db 스크립트는 mysqld 서버를 기동해, 이하의 권한을 포함하도록(듯이) 권한 테이블을 초기화합니다.

  • MySQL root 유저가, 모든 조작을 실행할 수 있는 슈퍼 유저로서 작성된다.접속은, 로컬 호스트로부터 실시할 필요가 있다.

    주의: 초기 상태에서는,root 패스워드는 공백 때문에, 누구라도 root 유저로서 패스워드 없음 그리고 접속할 수 있어 모든 권한을 얻을 수 있다.

  • 'test' (이)라는 이름의 데이타베이스, 또는 'test_' 그리고 시작되는 이름의 데이타베이스에 대해 모든 조작을 실행할 수 있는 익명 유저가 작성된다.접속은, 로컬 호스트로부터 실시할 필요가 있다.어느 로컬 유저라도 패스워드 없이 접속할 수 있어 그 경우, 익명 유저로서 다루어지는 것을 의미한다.

  • 그 외의 권한은 거부된다.예를 들어, 일반 유저는 mysqladmin shutdown (이)나 mysqladmin processlist (을)를 사용할 수 없다.

주의: Windows 의 디폴트 권한과는 다릅니다. See 항2.1.1.8. 「Windows (으)로의 MySQL 의 실행」 .

초기 인스톨시는 액세스가 개방되고 있는 상태이므로, 인스톨 후는 우선,MySQL root 유저에게 패스워드를 설정해 주세요.이것은 이하와 같이 실시합니다(주의: PASSWORD() 함수를 사용해 패스워드를 지정합니다).

shell> mysql -u root mysql
mysql> SET PASSWORD FOR root@localhost=PASSWORD('new_password');

'new_password' 에, 사용하는 패스워드를 지정합니다.

방법을 이해하고 있으면, 권한 테이블을 직접 조작할 수도 있습니다.

shell> mysql -u root mysql
mysql> UPDATE user SET Password=PASSWORD('new_password')
    ->     WHERE user='root';
mysql> FLUSH PRIVILEGES;

mysqladmin 커멘드를 사용해도, 패스워드를 설정할 수 있습니다.

shell> mysqladmin -u root password new_password

mysql 데이타베이스의 기입 권한 및 갱신 권한이 있는 유저만이, 다른 유저의 패스워드를 변경할 수 있습니다.모든 일반 유저(익명 유저 이외)는, 상기의 커멘드 또는 SET PASSWORD=PASSWORD('new_password') (을)를 사용해 자신의 패스워드만을 변경할 수 있습니다.

주의: UPDATE (을)를 사용해 user 테이블로 직접 패스워드를 갱신하는 경우,FLUSH PRIVILEGES (을)를 사용해 서버에 권한 테이블을 재독 봐 시킬 필요가 있습니다.그렇게 하지 않는다고 변경이 인식되지 않습니다.

root 패스워드를 일단 설정하면 그것이?~ ,root (으)로서 서버에 접속할 때는 항상 그 패스워드를 입력할 필요가 있습니다.

추가 설정이나 테스트를 실시하고 있는 한중간에 패스워드를 입력하지 않고 끝나도록(듯이),root 패스워드를 공백대로 하고 싶은 경우도 있겠지요.그러나, 실가동으로 사용하기 전에는 반드시 패스워드를 설정해 주세요.

디폴트 권한의 설정에 대해서는,scripts/mysql_install_db 스크립트를 참조해 주세요.이 스크립트는, 다른 유저를 추가할 때에 그 기본으로서 사용할 수 있습니다.

상기의 초기 권한과는 다른 초기 권한을 설정하고 싶은 경우에는,mysql_install_db (을)를 편집하고 나서 실행해 주세요.

권한 테이블을 완전하게 재생성하려면 ,mysql 데이타베이스가 포함되는 디렉토리내의 .frm ,.MYI , 및 .MYD 파일을 모두 삭제합니다(이 디렉토리는, 데이터 디렉토리아래에 있다 mysql (이)라는 이름의 디렉토리입니다.데이터 디렉토리는 mysqld --help (을)를 실행한다고 표시됩니다).그리고, 필요에 따라서 권한을 편집하고 나서,mysql_install_db 스크립트를 실행합니다.

주의: MySQL 버젼 3.22.10 보다 전에서는,.frm 파일을 삭제하지 말아 주세요.무심코 삭제해 버렸을 경우는,mysql_install_db (을)를 실행하기 전에,MySQL 디스트리뷰션으로부터 다시 카피해 주세요.

4.4.5. MySQL 에의 신규 유저의 추가

유저의 추가에는,2 개의 방법이 있습니다.GRANT 스테이트먼트를 사용하는 방법과MySQL 권한 테이블을 직접 조작하는 방법입니다.정확하고 에러가 발생하기 어렵다 GRANT 스테이트먼트의 사용을 추천 합니다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

유저의 작성 및 관리에 사용할 수 있는 기여 프로그램도 몇개인가 있습니다(phpMyAdmin 등).

이하의 예에서는,mysql 클라이언트를 사용해 신규 유저를 설정하는 방법을 나타냅니다.이 예에서는, 전의 섹션으로 설명한 디폴트 설정에 따라서 권한이 셋업 되고 있는 것을 전제로 하고 있습니다.그 때문에 변경을 실시하려면 ,mysqld (을)를 실행하고 있는 머신에 로그인하고 있는 것,MySQL root 유저로서 접속하고 있는 것,root 유저에게 mysql 데이타베이스에 대한다 INSERT 권한과 RELOAD 관리자 권한이 있는 것이 필요 조건이 됩니다.또,root 유저 패스워드를 변경하고 있는 경우, 여기서,mysql 커멘드를 사용해 그 패스워드를 지정할 필요가 있습니다.

우선,mysql 프로그램을 사용해 서버에 MySQL root 유저로서 접속합니다.

shell> mysql --user=root mysql

다음에,GRANT 스테이트먼트를 실행해 신규 유저를 추가할 수 있습니다.

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 스테이트먼트에서는, 이하의 3 사람의 신규 유저가 추가됩니다.

  • monty

    어디에서라도 서버에 접속할 수 있는 완전한 슈퍼 유저.다만, 패스워드 'some_pass' 의 사용이 필요.주의: GRANT 스테이트먼트를 monty@localhost (와)과 monty@"%" 의 양쪽 모두에 대해서 발행하는 것이 필요하다.localhost 의 엔트리를 추가하지 않으면 로컬 호스트로부터 접속했을 때,mysql_install_db 에 의해서 작성되었다 localhost 의 엔트리가,Host 필드치가 보다 구체적이고,user 테이블의 소트 순서로 상위가 되기 위해 우선되게 된다.

  • admin

    localhost (으)로부터 패스워드 없이 접속할 수 있어RELOAD 및 PROCESS 의 관리 권한이 있는 유저.이 유저는,mysqladmin reload ,mysqladmin refresh ,mysqladmin flush-* 의 각 커멘드, 및 mysqladmin processlist (을)를 실행할 수 있다.데이타베이스 레벨의 권한은 설정되어 있지 않다(GRANT 스테이트먼트를 실행해 다음에 추가할 수 있다).

  • dummy

    패스워드 없이 로컬 호스트로부터 마셔 접속할 수 있는 유저.권한은 설정되어 있지 않다.USAGE 권한 타입에 의해, 이러한 권한 없음의 유저를 작성할 수 있다.이것은, 모든 글로벌 권한을 'N' (으)로 설정하는 것과 같은 것이다.이것은, 다음에 이 어카운트에 고유의 권한을 설정하는 것을 상정하고 있다.

INSERT 스테이트먼트를 발행해 서버에 권한 테이블을 재차 읽어들이게 하는 것으로, 같은 유저 액세스 정보를 직접 추가할 수도 있습니다.

shell> mysql --user=root mysql
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','');
mysql> FLUSH PRIVILEGES;

MySQL 버젼에 따라서는, 상기 'Y' 값의 수가 다른 경우가 있습니다(3.22.11 보다 전의 버젼에서는 권한 컬럼이 적고,4.0.2 이?~ 그럼 많아집니다).admin 유저에 대해서는, 버젼 3.22.11 이?~ 그리고 이용 가능하게 되었다 SET (을)를 사용하는 확장 INSERT 구문이 사용되고 있습니다.

주의: 슈퍼 유저를 설정하는 경우는, 권한 필드를 'Y' (으)로 설정했다 user 테이블 엔트리를 작성하는 것만으로 끝납니다.db 테이블이나 host 테이블의 엔트리는 필요 없습니다.

마지막 INSERT 스테이트먼트(dummy 유저)에서는,user 테이블 레코드의 Host ,User , 및 Password 컬럼만이 값을 할당할 수 있고 있습니다.권한 컬럼은 어느 것도 명시적으로 설정되어 있지 않기 때문에,MySQL (은)는 이것들 모두에게 디폴트치의 'N' (을)를 설정합니다.이것은,GRANT USAGE (와)과 같은 기능입니다.

이하의 예에서는, 유저 custom (을)를 추가합니다.이 유저는 bankaccount 데이타베이스에는 로컬 호스트로부터 마셔,expenses 데이타베이스에는 호스트 whitehouse.gov (으)로부터 마셔,customer 데이타베이스에는 호스트 server.domain (으)로부터 마셔 액세스 할 수 있다고 합니다.3 살의 호스트 모두로 패스워드 obscure (을)를 사용합니다.

GRANT 스테이트먼트를 사용해 이 유저의 권한을 설정하려면 , 이하의 커멘드를 실행합니다.

shell> mysql --user=root mysql
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON bankaccount.*
    ->     TO custom@localhost
    ->     IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON expenses.*
    ->     TO custom@'whitehouse.gov'
    ->     IDENTIFIED BY 'obscure';
mysql> GRANT SELECT,INSERT,UPDATE,DELETE,CREATE,DROP
    ->     ON customer.*
    ->     TO custom@'server.domain'
    ->     IDENTIFIED BY 'obscure';

권한 테이블을 직접 변경해 유저의 권한을 설정하려면 , 이하의 커멘드를 실행합니다(주의: 마지막 FLUSH PRIVILEGES 에 주목).

shell> mysql --user=root mysql
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('localhost','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('whitehouse.gov','custom',PASSWORD('obscure'));
mysql> INSERT INTO user (Host,User,Password)
    -> 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');
mysql> INSERT INTO db
    -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
    ->  Create_priv,Drop_priv)
    -> VALUES
    -> ('whitehouse.gov','expenses','custom','Y','Y','Y','Y','Y','Y');
mysql> INSERT INTO db
    -> (Host,Db,User,Select_priv,Insert_priv,Update_priv,Delete_priv,
    ->  Create_priv,Drop_priv)
    -> VALUES('server.domain','customer','custom','Y','Y','Y','Y','Y','Y');
mysql> FLUSH PRIVILEGES;

INSERT 스테이트먼트를 사용한 전의 예와 같이,MySQL 의 버젼에 따라서는 'Y' 의 값의 수가 다릅니다.

최초의 3 개의 INSERT 스테이트먼트는 user 테이블 엔트리를 추가해, 유저 custom 하지만 다양한 호스트로부터 지정의 패스워드로 접속할 수 있게 합니다만, 권한에 대해서는 아무것도 설정해 있지 않습니다(권한은 모두, 디폴트치의 'N' (으)로 설정되어 있습니다).다음의 3 개의 INSERT 스테이트먼트는,db 테이블 엔트리를 추가해,custom 에 bankaccount ,expenses ,customer 의 각 데이타베이스에 대한 권한을 설정합니다.이러한 권한은, 적절한 호스트로부터 액세스 했을 때에만 적용되는 것입니다.권한 테이블을 직접 변경했을 경우,FLUSH PRIVILEGES (을)를 사용해 서버에 권한 테이블을 재차 읽어들이게 해 권한의 변경을 반영시킬 필요가 있습니다.

특정의 유저에게, 어느 도메인(예를 들어 mydomain.com )의 모든 머신으로부터의 액세스를 허가하려면 , 이하와 같은 GRANT 스테이트먼트를 실행합니다.

mysql> GRANT ...
    ->     ON *.*
    ->     TO myusername@'%.mydomain.com'
    ->     IDENTIFIED BY 'mypassword';

권한 테이블을 직접 변경하고 같은 것을 실시하려면 , 이하를 실행합니다.

mysql> INSERT INTO user VALUES ('%.mydomain.com', 'myusername',
    ->             PASSWORD('mypassword'),...);
mysql> FLUSH PRIVILEGES;

4.4.6. MySQL 유저의 삭제

DROP USER user_name

이 커멘드는 MySQL 4.1.1 그리고 추가된 커멘드입니다.

이 커멘드에 의해, 권한을 가지지 않는 유저가 삭제됩니다.

MySQL (으)로부터 유저를 삭제하려면 , 이하의 순서에 따릅니다.

  1. SHOW PRIVILEGES (을)를 사용해 유저의 권한을 확인한다. See 항4.6.8.11. 「SHOW PRIVILEGES 」 .

  2. REVOKE (을)를 사용해 유저로부터 권한을 모두 삭제한다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

  3. DROP USER (을)를 사용해 유저를 삭제한다.

낡다 MySQL 버젼을 사용하고 있는 경우는, 우선 권한을 취소하고 나서 유저를 삭제합니다.

mysql> DELETE FROM mysql.user WHERE user='username' and host='hostname';
mysql> FLUSH PRIVILEGES;

4.4.7. 유저 자원의 제한

MySQL 4.0.2 이?~ , 특정의 자원을 유저 마다 제한할 수 있게 되었습니다.

지금까지는,MySQL 서버 자원의 사용을 제한하려면 , 스타트 업 변수의 max_user_connections (을)를 제로 이외의 값으로 설정할 수 밖에 없었습니다.그러나 이 방법은 글로벌하게 적용되기 위해, 인터넷 서비스 프로바이더가 관심이 있는 개별 유저의 관리에는 사용할 수 없었습니다.

그 때문에, 개별 유저 레벨로 3 개의 자원을 관리하는 방법이 도입되었습니다.

  • 시간 단위의 전쿼리수: 1 유저가 실행할 수 있는 쿼리.

  • 시간 단위의 전갱신수: 테이블 또는 데이타베이스를 변경하는 쿼리.

  • 시간 단위의 접속수: 1 시간에 새롭게 열리는 접속.

상기 문맥의 1 유저란 user 테이블의 1 엔트리입니다.이 엔트리는 user 컬럼과 host 컬럼에 의해서 식별됩니다.

제한을 설정하지 않는 한, 모든 유저는 디폴트로, 상기 자원을 제한없이 사용할 수 있습니다.이러한 제한은, 이하의 구문을 사용해 글로벌인 GRANT (*.*) 그리고 마셔 설정할 수 있습니다.

GRANT ... WITH MAX_QUERIES_PER_HOUR N1
               MAX_UPDATES_PER_HOUR N2
               MAX_CONNECTIONS_PER_HOUR N3;

상기의 자원은 어떠한 조합에서도 지정 가능합니다. N1 ,N2 , 및 N3 (은)는 정수로, 시간 단위의 카운트수를 나타냅니다.

유저가 시간 단위의 접속수에 이르면, 그 1 시간이 경과할 때까지, 이?~ 의 접속은 거부됩니다.같이 유저가 쿼리 또는 갱신의 제한 회수에 이르면, 그 1 시간이 경과할 때까지, 이?~ 의 쿼리 또는 갱신은 거부됩니다.어느 경우도, 적절한 에러 메세지가 표시됩니다.

특정 유저의 현재의 사용치를 플래시(제로로 설정) 하려면 , 상기의 임의의 마디의 GRANT 스테이트먼트를 발행합니다.그 때 GRANT 스테이트먼트의 값을 현재의 값으로 합니다.

또, 모든 유저의 현재의 값을 플래시 하려면 , 권한을 재독 봐 (서버 내부에서 실시하는지,mysqladmin reload (을)를 사용),FLUSH USER_RESOURCES 커멘드를 실행합니다.

자원 제한 기능은, 단일 유저에게 자원을 제한한다 GRANT 마디가 설정되자마자 유효하게 됩니다.

이 기능을 유효화하는 전제 조건으로서scripts 서브 디렉토리에 있는 테이블 작성 스크립트 mysql_install_db 및 mysql_install_db.sh 그리고 정의되고 있는 추가 컬럼이,mysql 데이타베이스의 user 테이블에 포함되어 있는 것이 필요합니다.

4.4.8. 패스워드의 설정

대부분의 경우에 대하고, 유저와 패스워드의 설정에는 GRANT (을)를 사용합니다.이하의 방법은 상급 유저 대상입니다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

전의 섹션에서는, 예를 이용해 중요한 원칙을 나타냈습니다.INSERT 또는 UPDATE 스테이트먼트를 사용해 공백이 아닌 패스워드를 보존할 때 ,PASSWORD() 함수를 사용해 암호화해야 한다고 하는 것입니다.이것은,user 테이블이 패스워드를 평문텍스트가 아니고, 암호화된 형식에서 보존하기 (위해)때문입니다.예를 들어, 이 원칙을 잊고, 이하와 같이 패스워드를 설정해 버렸다고 합니다.

shell> mysql -u root mysql
mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('%','jeffrey','biscuit');
mysql> FLUSH PRIVILEGES;

이 경우, 평문텍스트의 'biscuit' 하지만, 패스워드로서 user 테이블에 보존됩니다.유저 jeffrey 하지만 이 패스워드를 사용해 서버에 접속하려고 하면,mysql 클라이언트는 PASSWORD() 그리고 그것을 암호화해, 암호화되었다 패스워드와 서버로부터 취득한 랜덤 번호에 근거해 인증 벡터를 생성해, 그것을 서버에 송신합니다. 서버는 user 테이블의 password 값(이 경우, 암호화되어 있지 않다 'biscuit' )(을)를 사용해 같은 계산을 실행해, 결과를 비교합니다. 비교는 실패해, 서버는 접속을 거부합니다.

shell> mysql -u jeffrey -pbiscuit test
Access denied

user 테이블에 패스워드를 삽입할 때, 패스워드는 암호화해 둘 필요가 있습니다.따라서,INSERT 스테이트먼트를 이하와 같이 지정합니다.

mysql> INSERT INTO user (Host,User,Password)
    -> VALUES('%','jeffrey',PASSWORD('biscuit'));

SET PASSWORD 스테이트먼트를 사용할 때도,PASSWORD() 함수를 사용할 필요가 있습니다.

mysql> SET PASSWORD FOR jeffrey@"%" = PASSWORD('biscuit');

GRANT ... IDENTIFIED BY 스테이트먼트 또는 mysqladmin password 커멘드를 사용해 패스워드를 설정하는 경우,PASSWORD() 함수는 필요 없습니다.양쪽 모두 패스워드를 암호화하므로, 이하와 같이 패스워드를 'biscuit' (와)과 지정합니다.

mysql> GRANT USAGE ON *.* TO jeffrey@"%" IDENTIFIED BY 'biscuit';

또는

shell> mysqladmin -u jeffrey password biscuit

주의: PASSWORD() (은)는,Unix 의 패스워드 암호화와는 다릅니다. See 항4.4.2. 「MySQL 의 유저명과 패스워드」 .

4.4.9. 패스워드의 시큐러티

자신의 패스워드를 다른 유저가 아는 방법으로 지정하는 것은 위험합니다. 클라이언트 프로그램을 실행할 때, 패스워드의 지정에 사용할 수 있는 방법을 이하에 나타냅니다.각각의 위험도에 대해서도 나타내 보입니다.

  • 일반 유저에게 mysql.user 테이블에의 액세스권을 주어선 안 된다.암호화되고 있는 패스워드를 알 수 있던 것만으로, 그 유저로서 로그인하는 것이 가능하게 된다.패스워드의 암호화는, 진짜 패스워드를 타인에게 보여지지 않게 하기 위한(해)만의 것이다(다른 어플리케이션으로 닮은 패스워드를 사용하는 경우에 대비해).

  • -pyour_pass 옵션 또는 --password=your_pass 옵션을 커멘드 라인으로 사용한다.이것은 편리하지만 안전하지 않다.다른 유저가 커멘드 라인을 표시하기 위해(때문에) 기동한다 ps 등의 시스템 스테이터스 프로그램에는 패스워드가 보여 버린다(MySQL 클라이언트는 통상, 초기화 순서에 대해 커멘드 라인 인수를 제로로 덧쓰기하지만, 짧은 인터벌이 있어 그 사이는 보여 버린다).

  • -p 옵션 또는 --password 옵션을 사용한다(your_pass 값을 지정하지 않는다).이 경우, 클라이언트 프로그램은 단말로부터의 패스워드 입력을 요구한다.

    shell> mysql -u user_name -p
Enter password: ********

    ‘* ＇ 문자는 패스워드를 나타낸다.

    이 방법이라면 다른 유저에게는 안보이기 때문에, 커멘드 라인으로 패스워드를 지정하는 것보다도 안전하다.다만, 이 패스워드 입력 방법은, 대화식에서 실행하는 프로그램에게만 적합하다.비대화식에서 실행하는 스크립트로부터 클라이언트를 기동하는 경우, 단말로부터 패스워드를 입력할 기회가 없다.시스템에 따라서는, 스크립트의 최초의 행을 틀려 패스워드라고 해석해 버리는 것도 있다.

  • 설정 파일에 패스워드를 보존한다.예를 들어, 자신의 홈 디렉토리에 있다 .my.cnf 파일의 [client] 섹션에 패스워드를 기입할 수 있다.

    [client]
password=your_pass

    패스워드를 .my.cnf 에 보존하는 경우, 아무도 그 파일을 읽고 쓰기할 수 없게 해 두는 것이 필요하다.파일의 액세스 모드는 400 또는 600 (으)로 해 두는 것. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

  • MYSQL_PWD 환경 변수에 패스워드를 보존할 수 있다.그러나 이 방법은 매우 위험해서, 사용해서는 안된다. ps 의 버젼에 따라서는, 실행중의 프로세스 환경을 표시하는 옵션이 있다.MYSQL_PWD (을)를 설정해 있으면 누구에게나 패스워드를 들켜 버린다.그러한 버젼의 ps 하지만 없는 시스템에서도, 프로세스 환경을 표시하는 다른 방법이 없다고 상정하는 것은 위험하다. See 부록 F. 환경 변수 .

이상을 총괄하면, 가장 안전한 방법은, 클라이언트 프로그램에 패스워드를 요구시키는지, 적절히 보호되었다 .my.cnf 파일에 패스워드를 지정하는 것입니다.

4.4.10. 안전한 접속의 사용

4.4.10.1. 기본 개념

버젼 4.0.0 보다 ,MySQL 하 SSL 암호화 접속을 서포트하고 있습니다.MySQL 하지만 어떻게 SSL (을)를 사용하는지 이해하려면 ,SSL (와)과 X509 의 기본 개념을 빠뜨릴 수 없습니다.기본 개념을 이해하고 있는 독자는, 이 섹션을 읽어 날려 주세요.

디폴트에서는,MySQL (은)는 클라이언트와 서버간에 암호화되어 있지 않은 접속을 사용합니다.즉, 타인이 모든 트래픽 및 송수신 데이터를 훔쳐 보는 것이 가능한 접속입니다.또, 클라이언트와 서버간에 전송중의 데이터를 개찬하는 것도 가능합니다.공개 네트워크로의 정보의 교환에서도 안전성이 요구되는 경우가 있습니다.그러한 경우, 암호화되어 있지 않은 접속은 적합하지 않습니다.

SSL (이)란, 복수가 다른 암호화 알고리즘을 사용하고, 공개 네트워크로 수신하는 데이터의 신뢰성을 보증하기 위한 프로토콜입니다.데이터의 변경, 소실, 및 재생을 검지하는 메카니즘이 있습니다.SSL 에는 또,X509 규격을 사용한다 ID 인증을 인식 및 제공하기 위한 알고리즘도 짜넣어지고 있습니다.

암호화란, 데이터를 읽어내 불가능하게 하는 기술입니다.실제, 오늘의 사회에서는, 암호화 알고리즘에 의하고 말이야들 되는 시큐러티가 요구되고 있습니다.암호화 메세지의 차례를 변경하거나 같은 데이터를 2 회재생하는 등, 다양한 종류의 공격에 대한 내성이 필요하고 있습니다.

X509 (이)란, 인터넷상에서 ID 인증을 가능하게 하는 규격입니다.이것은, 전자 상거래 어플리케이션으로 가장 일반적으로 사용되고 있습니다.기본적으로는,`` 인증국'' (으)로 불리는 회사가 전자 증명서를 필요로 하는 사람에게 할당한다고 하는 방법을 취합니다.증명서는,2 개의 암호화 키(공개 키와 비밀 키)가 있는 비대칭 암호화 알고리즘을 사용하고 있습니다.증명서의 소유자는, 다른 사람에게 증명서를 제시해 자신의 ID (을)를 증명합니다.증명서에는, 소유자의 공개 키가 포함되어 있습니다.이 공개 키로 암호화된 데이터는 모두, 대응하는 비밀 키가 없으면 해독할 수 없습니다.비밀 키는 증명서의 소유자가 보관 유지하고 있습니다.

MySQL (은)는 디폴트에서는 암호화 접속을 사용하지 않습니다.사용하면, 클라이언트와 서버의 프로토콜이 꽤 늦어지기 때문입니다.어떠한 기능을 추가했을 경우에서도 컴퓨터에는 부하가 걸립니다.데이터의 암호화도 예외가 아니고,CPU (을)를 큰폭으로 소비하고 시간이 걸려,MySQL 의 주요 태스크를 늦추는 원인이 됩니다.그 때문에 디폴트에서는,MySQL (은)는 속도가 우선되고 있습니다.

SSL ,X509 , 및 암호화에 대해 한층 더 상세를 알려면 , 인터넷 검색 엔진을 이용해 필요한 정보를 검색해 주세요.

4.4.10.2. 필요 조건

안전한 접속을 MySQL 그리고 사용하려면 , 이하를 실행할 필요가 있습니다.

  1. OpenSSL 라이브러리를 인스톨 한다.OpenSSL 0.9.6 (을)를 인스톨 했다 MySQL (은)는 테스트가 끝난 상태. http://www.openssl.org/ .

  2. MySQL (을)를 --with-vio --with-openssl 그리고 콘피개 한다.

  3. 낡다 MySQL 버젼을 사용하고 있는 경우,mysql.user 테이블에 새롭다 SSL 관련 컬럼을 추가할 필요가 있다. 이 처리는, 권한 테이블이 MySQL 4.0.0 보다 전의 버젼의 경우에 필요하다.순서에 대해서는 항2.5.6. 「권한 테이블의 업그레이드」 (을)를 참조.

  4. 실행중의 mysqld 서버가 OpenSSL (을)를 서포트하고 있는지 체크하려면 ,SHOW VARIABLES LIKE 'have_openssl' 하지만 YES (을)를 돌려줄지를 확인한다.

4.4.10.3. MySQL (으)로의 SSL 증명서의 설정

이하,MySQL (으)로의 SSL 증명서의 설정예입니다.

DIR=`pwd`/openssl
PRIV=$DIR/private

mkdir $DIR $PRIV $DIR/newcerts
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

#
# 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:
# -----
# 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 []:

#
# 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:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# ..++++++
# ..........++++++
# writing new private key to '/home/monty/openssl/server-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# 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 server
# Email Address []:
#
# Please enter the following 'extra' attributes
# 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

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# 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
# 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:
# Using configuration from /home/monty/openssl/openssl.cnf
# Generating a 1024 bit RSA private key
# .....................................++++++
# .............................................++++++
# writing new private key to '/home/monty/openssl/client-key.pem'
# Enter PEM pass phrase:
# Verifying password - Enter PEM pass phrase:
# -----
# 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 user
# Email Address []:
#
# 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

# Sample output:
# Using configuration from /home/monty/openssl/openssl.cnf
# Enter PEM pass phrase:
# 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
# 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 " " '
' > $DIR/my.cnf

#
# To test MySQL

mysqld --defaults-file=$DIR/my.cnf &

mysql --defaults-file=$DIR/my.cnf

mysql-source-dist/SSL 디렉토리에 있는 데모 증명서를 참조하도록(듯이) 상기의 my.cnf 파일을 수정하는 것에 의해서, 설정을 테스트할 수 있습니다.

4.4.10.4. SSL GRANT 옵션

MySQL (은)는, 통상의 유저명과 패스워드의 스킴에 가세해X509 증명서 속성을 체크할 수 있습니다.통상의 옵션도 모두 필요합니다(유저명, 패스워드,IP address mask, 데이타베이스/ 테이블명).

접속의 제한에는 몇개의 시나리오가 있습니다.

  • SSL 또는 X509 옵션이 없는 경우, 유저명으로 패스워드가 올바르면, 암호화 및 비암호화 모든 접속이 허가된다.

  • REQUIRE SSL 옵션은, 서버가 SSL 암호화 접속만을 허가하도록(듯이) 제한한다. 주의: 비 SSL 접속을 허가한다 ACL 레코드가 있는 경우, 이 옵션은 제외할 수 있다.

    mysql> GRANT ALL PRIVILEGES ON test.* TO root@localhost
    -> IDENTIFIED BY 'goodsecret' REQUIRE SSL;

  • REQUIRE X509 (은)는, 클라이언트에 유효한 증명서가 필요한 일을 의미하지만, 어느 증명서, 발행자, 및 주제가 아니면 안 된다고 하는 지정은 없다. CA 증명서의 서명을 확인할 수 있으면, 그래서 충분하다.

    mysql> GRANT ALL PRIVILEGES ON test.* TO root@localhost
    -> IDENTIFIED BY 'goodsecret' REQUIRE X509;

  • REQUIRE ISSUER 'issuer' (은)는, 접속 시행에 제한을 더한다. 클라이언트는,CA 'issuer' 에 의해서 발행된 유효한 X509 증명서를 제시할 필요가 있다. X509 증명서를 사용하는 것은, 암호화의 사용을 의미하고 있어,SSL 옵션은 불필요하다.

    mysql> GRANT ALL PRIVILEGES ON test.* TO root@localhost
    -> IDENTIFIED BY 'goodsecret'
    -> REQUIRE ISSUER 'C=FI, ST=Some-State, L=Helsinki,
    '> O=MySQL Finland AB, CN=Tonu Samuel/Email=tonu@mysql.com';

  • REQUIRE SUBJECT 'subject' 그럼, 주제 'subject' 하지만 유효한 X509 증명서가 클라이언트에 필요하다.클라이언트가 유효한 증명서를 제시해도,'subject' 하지만 다른 경우, 접속은 거부된다.

    mysql> GRANT ALL PRIVILEGES ON test.* TO root@localhost
    -> IDENTIFIED BY 'goodsecret'
    -> REQUIRE SUBJECT 'C=EE, ST=Some-State, L=Tallinn,
    '> O=MySQL demo client certificate,
    '> CN=Tonu Samuel/Email=tonu@mysql.com';

  • REQUIRE CIPHER 'cipher' (은)는, 강력한 암호와 키장의 사용을 의무화 한다.짧은 암호화 키의 낡은 알고리즘을 사용했을 경우,SSL 자체도 강력한 것은 없어진다.이 옵션을 사용하는 것으로써, 접속 허가의 조건으로서 특정의 암호화를 지정할 수 있다.

    mysql> GRANT ALL PRIVILEGES ON test.* TO root@localhost
    -> IDENTIFIED BY 'goodsecret'
    -> REQUIRE CIPHER 'EDH-RSA-DES-CBC3-SHA';

    SUBJECT ,ISSUER , 및 CIPHER 의 옵션은, 이하와 같이 REQUIRE 마디로 조합할 수 있다.

    mysql> GRANT ALL PRIVILEGES ON test.* TO root@localhost
    -> IDENTIFIED BY 'goodsecret'
    -> REQUIRE SUBJECT 'C=EE, ST=Some-State, L=Tallinn,
    '> O=MySQL demo client certificate,
    '> CN=Tonu Samuel/Email=tonu@mysql.com'
    -> AND ISSUER 'C=FI, ST=Some-State, L=Helsinki,
    '> O=MySQL Finland AB, CN=Tonu Samuel/Email=tonu@mysql.com'
    -> AND CIPHER 'EDH-RSA-DES-CBC3-SHA';

    MySQL 4.0.4 이?~ ,REQUIRE 옵션간의 AND 키워드는 임의가 되어 있다.

    옵션은 어떤 순서라도 지정할 수 있지만, 같은 옵션을 2 회지정할 수 없다.

4.4.10.5. SSL 커멘드 라인 옵션

이하의 겉(표)는,SSL , 증명서 파일, 및 키파일의 사용을 지정하기 위한 옵션을 집계한 것입니다. 이러한 옵션은 MySQL 4.0 (으)로부터 도입된 것입니다.이러한 옵션은, 커멘드 라인에서도 옵션 설정 파일에서도 사용할 수 있습니다.

  • --ssl

    서버에 대해서는, 서버가 SSL 접속을 허가하도록(듯이) 지정한다. 클라이언트 프로그램에 대해서는,SSL (을)를 사용해 서버에 접속하는 것을 허가한다. 이 옵션만으로는 SSL 접속의 사용은 보증되지 않는다. --ssl-ca ,--ssl-cert , 및 --ssl-key 옵션도 지정할 필요가 있다.

    주의: 이 옵션에서는,SSL 접속이 필수 되지 않는다. 예를 들어, 서버 또는 클라이언트가 SSL 서포트 없이 컴파일 되고 있는 경우, 통상의 암호화되어 있지 않은 접속이 사용된다.

    SSL 접속만의 사용을 확실히 보증하려면 , 우선,GRANT 스테이트먼트로 REQUIRE SSL 마디를 포함한 어카운트를 서버에 작성하는 것이 필요. 그리고 이 어카운트를 사용해 서버에 접속한다.이 때, 서버와 클라이언트의 양쪽 모두로 SSL 서포트가 유효하게 되어 있는 것이 필요하다.

    이 옵션을 사용하고, 접속에 SSL (을)를 사용하지 않게 지정할 수 있다. 이 경우, 옵션을 --skip-ssl 또는 --ssl=0 (으)로서 지정한다.

  • --ssl-ca=file_name

    신뢰 받았다 SSL 인증국의 일람이 포함되는 파일의 패스.

  • --ssl-capath=directory_name

    PEM 형식이 신뢰 받았다 CA 증명서가 보존되고 있는 디렉토리의 패스.

  • --ssl-cert=file_name

    안전한 접속을 확립하기 위해서 사용한다 SSL 증명서 파일의 이름.

  • --ssl-cipher=cipher_list

    SSL 암호화에 사용할 수 있는 암호의 일람. cipher_list (은)는,openssl ciphers 커멘드와 같은 형식이다.

    례: --ssl-cipher=ALL:-AES:-EXP

  • --ssl-key=file_name

    안전한 접속을 확립하기 위해서 사용한다 SSL 키파일의 이름.


4.5. 장해의 예방과 리커버리

4.5.1. 데이타베이스의 백업

MySQL 테이블은 파일로서 보존되기 위해, 백업이 간단합니다.일관한 백업을 실시하려면 , 그 테이블에 대해서 LOCK TABLES (을)를 실행하고 나서,FLUSH TABLES (을)를 실행합니다. See 항6.7.5. 「LOCK TABLES 및 UNLOCK TABLES 구문」 . See 항4.6.4. 「FLUSH 구문」 . 독해 락만이 필요해서, 데이타베이스 디렉토리의 파일을 카피하고 있는 동안도, 다른 스레드는 테이블에 대해서 쿼리를 속행할 수 있습니다.FLUSH TABLE (은)는, 백업을 개시하기 전에, 캐쉬되고 있는 페이지를 모두 디스크에 쓰기 위해서 필요합니다.

3.23.56 (으)로부터 4.0.12 그럼, 시큐러티상의 리스크가 있기 위해,BACKUP TABLE 그리고 기존 파일의 덧쓰기는 할 수 없게 되어 있습니다.

테이블을 SQL 레벨로 백업 하려면 ,SELECT INTO OUTFILE 또는 BACKUP TABLE (을)를 사용합니다. See 항6.4.1. 「SELECT 구문」 . See 항4.5.2. 「BACKUP TABLE 구문」 .

데이타베이스의 백업에는,mysqldump 프로그램 또는 mysqlhotcopy script (을)를 사용할 수도 있습니다. See 항4.9.7. 「mysqldump (테이블 구조와 데이터의 덤프)」 . See 항4.9.8. 「mysqlhotcopy (MySQL 의 데이타베이스와 테이블의 카피)」 .

  1. 데이타베이스를 풀백 올라간다.

    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 테이블과 ISAM 테이블에게만 유효.

  2. mysqld 하지만 실행중이면 일단 정?~ 해,--log-bin[=file_name] 옵션으로 재기동한다.See 항4.10.4. 「바이너리 로그」 . mysqldump 실행 후에 행해진 데이터의 변경을 레프리케이트하기 위한 정보가, 바이너리 로그 파일에 의해 제공된다.

MySQL 서버가 슬레이브의 경우, 어느 백업 방법을 선택해도, 슬레이브의 데이터를 백업 할 때,master.info 파일과 relay-log.info 파일도 백업 해 주세요.이러한 파일은, 슬레이브의 데이터를 restore 후, replication를 재개할 경우에 필요합니다.슬레이브가, replication를 실시한다 LOAD DATA INFILE 커멘드의 대상이 되고 있었을 경우,SQL_LOAD-* 파일도 백업 해 주세요.이 파일은,--slave-load-tmpdir 옵션에 의해서 지정되어 있는 디렉토리에 있습니다(이 파일의 장소가 지정되어 있지 않은 경우, 디폴트로, 이 장소는 tmpdir 변수의 값이 됩니다).중단되고 있었다 LOAD DATA INFILE 처리의 replication를 재개하기 위해서 슬레이브는 이러한 파일을 필요로 합니다.

무엇인가를 restore 할 필요가 있는 경우, 최초로 REPAIR TABLE 또는 myisamchk -r (을)를 사용해 테이블의 리커버리를 시도해 주세요.대부분의 경우, 이것으로 성공할 것입니다.myisamchk 그리고 리커버리 할 수 없었던 경우, 이하를 실행합니다.이것은,--log-bin 그리고 MySQL (을)를 기동하고 있는 경우에게만 가능한 방법입니다. 항4.10.4. 「바이너리 로그」 (을)를 참조해 주세요.

  1. 오리지날의 mysqldump 백업, 또는 바이너리 백업을 restore 한다.

  2. 이하의 커멘드를 실행하고, 바이너리 로그내의 갱신을 재실행한다.

    shell> mysqlbinlog hostname-bin.[0-9]* | mysql

    경우에 따르고, 특정의 위치에서 후의 바이너리 로그만을 재실행한다(통상은, restore 한 백업의 일자이?~ 의, 부정한 쿼리 이외의 모든 바이너리 로그를 재실행한다). mysqlbinlog 유틸리티 및 그 사용법의 상세한 것에 대하여는, 항4.9.5. 「mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)」 (을)를 참조.

    갱신 로그(MySQL 5.0 그리고 폐?~ )(을)를 사용하고 있는 경우, 갱신 로그의 내용을 이하와 같이 실행할 수 있다.

    shell> ls -1 -t -r hostname.[0-9]* | xargs cat | mysql

    ls (은)는, 모든 갱신 로그 파일을 올바른 순서로 취득하기 위해서 사용합니다.

SELECT * INTO OUTFILE 'file_name' FROM tbl_name 그리고 선택적 백업을 실시해,LOAD DATA INFILE 'file_name' REPLACE ... 그리고 restore 할 수도 있습니다.중복 테이블을 피하기 위해, 테이블에 PRIMARY KEY 또는 UNIQUE 키가 필요합니다.REPLACE 키워드를 사용하면, 유니크 키가 신규 레코드와 구레코드로 중복 하고 있었을 경우에, 구레코드가 신규 레코드로 옮겨놓을 수 있습니다.

백업에 수반해 퍼포먼스상의 문제가 발생하는 경우, replication를 셋업 하고, 마스터는 아니고 슬레이브상에서 백업을 실행하는 것으로써 이 문제를 해결할 수 있다. See 항4.11.1. 「처음에」 .

Veritas 파일 시스템을 사용하고 있는 경우, 이하를 실행할 수 있습니다.

  1. 클라이언트(또는 Perl )(으)로부터,FLUSH TABLES WITH READ LOCK (을)를 실행한다.

  2. 다른 쉘로부터,mount vxfs snapshot (을)를 실행한다.

  3. 최초의 클라이언트로부터,UNLOCK TABLES (을)를 실행한다.

  4. snapshot로부터 파일을 카피한다.

  5. snapshot의 마운트를 해제한다.

4.5.2. BACKUP TABLE 구문

BACKUP TABLE tbl_name[,tbl_name...] TO '/path/to/backup/directory'

디스크에 버퍼 되고 있는 변경을 플래시 한 다음에, 테이블을 restore 하는데 최저한 필요한 수의 테이블 파일을 백업 디렉토리에 카피합니다.현재로서는, 이 커멘드는 MyISAM 테이블에게만 유효합니다. MyISAM 테이블에 대해서,.frm 정의 파일과 .MYD 데이터 파일을 카피합니다.이것들 2 개의 파일로부터 인덱스 파일을 재차 빌드 할 수 있습니다.

이 커멘드를 사용하기 전에, 항4.5.1. 「데이타베이스의 백업」 (을)를 참조해 주세요.

백업중, 각 테이블이 처리되고 있는 동안 그 테이블에게만 읽어내 락이 걸립니다.복수의 테이블을 1 회의 snapshot로 백업 하는 경우는, 우선 LOCK TABLES (을)를 실행하고, 그 그룹내의 각 테이블에 대해서 읽어내 락을 걸쳐 둘 필요가 있습니다.

이 커멘드는, 이하의 컬럼으로 구성되는 테이블을 돌려줍니다.

컬럼 | 치
Table | 테이블명
Op | 항상 backup
Msg_type | status ,error ,info ,warning 의 언젠가
Msg_text | 메세지

주의: BACKUP TABLE (은)는,MySQL 버젼 3.23.25 이?~ 에서만 사용할 수 있습니다.

4.5.3. RESTORE TABLE 구문

RESTORE TABLE tbl_name[,tbl_name...] FROM '/path/to/backup/directory'

BACKUP TABLE 그리고 작성된 백업으로부터,1 개 또는 복수의 테이블을 restore 합니다.기존 테이블에는 덧쓰기되지 않습니다.기존 테이블 위에 restore 하려고 하면, 에러가 됩니다.인덱스를 재차 빌드 할 필요가 있기 위해, restore는 백업보다 시간이 걸립니다.키가 많으면 많을수록, 시간이 걸립니다.BACKUP TABLE (와)과 같이,RESTORE TABLE (은)는 현재로서는,MyISAM 테이블에게만 유효합니다.

이 커멘드는, 이하의 컬럼으로 구성되는 테이블을 돌려줍니다.

컬럼 | 치
Table | 테이블명
Op | 항상 restore
Msg_type | status ,error ,info ,warning 의 언젠가
Msg_text | 메세지

4.5.4. CHECK TABLE 구문

CHECK TABLE tbl_name[,tbl_name...] [option [option...]]

option = QUICK | FAST | MEDIUM | EXTENDED | CHANGED

CHECK TABLE (은)는,MyISAM 테이블과 InnoDB 테이블에게만 유효합니다.MyISAM 테이블의 경우, 이 테이블로 myisamchk --medium-check table_name (을)를 실행하는 것과 같습니다.

옵션을 아무것도 지정하지 않으면,MEDIUM 하지만 사용됩니다.

1 개 또는 복수의 테이블의 에러를 체크합니다.MyISAM 테이블에서는, 키 통계가 갱신됩니다.이 커멘드는, 이하의 컬럼으로 구성되는 테이블을 돌려줍니다.

컬럼 | 치
Table | 테이블명
Op | 항상 check
Msg_type | status ,error ,info ,warning 의 언젠가
Msg_text | 메세지

주의: 이 스테이트먼트는, 체크한 각 테이블에 관한 많은 정보 레코드를 생성합니다. 정상적인 경우,Msg_type 하 status 그리고,Msg_text (은)는 통상 OK (이)가 됩니다. OK 또는 Table is already up to date 하지만 얻을 수 있지 않으면, 테이블의 수복을 필요라고 생각할 수 있습니다.See 항4.5.6. 「myisamchk (을)를 사용한 테이블의 보수와 크래쉬의 리커버리」 . Table is already up to date (은)는, 테이블의 스토리지 매니저가, 그 테이블에 체크가 필요없다고 판단한 것을 의미합니다.

이하의 체크 타입이 있습니다.

타입 | 의미
QUICK | 부정 링크를 체크하기 위한 레코드 스캔을 실행하지 않는다.
FAST | 올바르게 닫혀지지 않았던 테이블만을 체크한다.
CHANGED | 전회의 체크 후로 변경된 테이블과 올바르게 닫혀지지 않았던 테이블만을 체크한다.
MEDIUM | 레코드를 스캔 하고, 삭제된 링크가 문제 없었던 것을 확인한다.또, 레코드의 키 체크 섬을 계산해, 키의 계산된 체크 섬을 사용해 확인한다.
EXTENDED | 각 레코드로 모든 키의 완전 키룩크압을 실행한다.테이블의 정합성이 100% 보증되지만, 시간이 걸린다.

동적 사이즈의 MyISAM 테이블에서는, 체크가 개시되었을 경우, 항상 MEDIUM 체크가 실행됩니다.정적 사이즈의 레코드는 파손하고 있는 것이 매우 보기 드물어서,QUICK 및 FAST 그리고 레코드 스캔을 스킵 합니다.

체크 옵션은 이하와 같이 조합할 수 있습니다.이하의 예에서는, 테이블이 올바르게 닫혀졌는지를 확인하는 퀵 체크를 실시합니다.

CHECK TABLE test_table FAST QUICK;

주의: 경우에 따라서는 CHECK TABLE (은)는 테이블을 변경합니다.이것은, 테이블에 'corrupted' 또는 'not closed properly' 그렇다고 하는 마크가 있는데,CHECK TABLE 하지만 테이블내에 문제를 발견하지 않았던 경우에 발생합니다.이 경우,CHECK TABLE (은)는 테이블을 OK (와)과 마크 합니다.

테이블이 파손하고 있는 경우, 데이터 부분보다 인덱스에 문제가 있는 것이 가능성이 높습니다.상기의 체크 타입은 모두, 인덱스를 완전하게 체크하므로 대부분의 에러는 발견할 수 있습니다.

문제가 없다고 생각되는 테이블을 체크하는 경우, 체크 옵션을 사용하지 않는지, 또는 QUICK 옵션을 사용합니다.QUICK (은)는, 서두르고 있을 때, 및 데이터 파일의 에러가 놓쳐질지도 모른다고 하는 매우 작은 위험성을 무시할 수 있는 경우에 사용합니다.대부분의 경우,MySQL (은)는 통상대로 사용하고 있으면, 데이터 파일의 에러를 발견합니다.발견했을 경우, 그 테이블에는 'corrupted' 의 마크가 뒤따라, 수복할 때까지 그 테이블은 사용할 수 없습니다.

FAST 및 CHANGED (은)는, 테이블을 가끔 체크하고 싶은 경우에, 스크립트로부터(예를 들어 cron (으)로부터) 실행되는 것을 상정하고 있습니다.통상은,CHANGED 보다 FAST 의 분을 사용해 주세요(이것이 들어맞지 않는 것은,MyISAM 코드내에 버그가 의심되는 경우만입니다).

EXTENDED (은)는, 통상의 체크 후에,MySQL 하지만 레코드를 갱신하거나 키로 레코드를 검색하려고 했을 때에, 부자연스러운 에러가 발생하는 경우에게만 사용합니다(통상의 체크가 정상적으로 종료한 다음에 에러가 발생하는 것은 매우 보기 드문 일입니다).

CHECK TABLE 그리고 보고되는 문제안에는, 자동적으로 수정되지 않는 것이 있습니다.

  • Found row where the auto_increment column has the value 0 .

    이것은,AUTO_INCREMENT 인덱스 컬럼의 값이 0 (이)가 되어 있는 레코드가 테이블에 있는 것을 의미한다(UPDATE 스테이트먼트로 명시적으로 AUTO_INCREMENT 컬럼치를 0 (으)로 설정하면, 이 컬럼이 0 의 레코드를 작성하는 것은 가능하다).

    이것 자체는 에러는 아니지만, 테이블을 덤프 해 restore 하려고 하거나 테이블로 ALTER TABLE (을)를 실행하려고 하면 문제가 발생한다.이 경우,AUTO_INCREMENT 컬럼은 AUTO_INCREMENT 컬럼의 룰에 근거해 값을 변경하기 위해(때문에), 중복 키 에러등의 원인이 된다.

    경고를 지우려면 ,UPDATE 스테이트먼트를 실행해 이 컬럼치를 0 이외의 값으로 설정한다.

4.5.5. REPAIR TABLE 구문

REPAIR [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...] [QUICK] [EXTENDED] [USE_FRM]

REPAIR TABLE 하 MyISAM 테이블에게만 유효하고, 이 테이블로 myisamchk -r table_name (을)를 실행하는 것과 같습니다.

통상이면, 이 커멘드를 사용할 것은 없습니다만, 장해가 발생했을 경우,REPAIR TABLE (을)를 사용하면, 대부분의 경우,MyISAM 테이블의 모든 데이타를 뽑아 되돌릴 수 있습니다.테이블이 빈번히 파손하는 것 같으면, 그 원인을 찔러?~ 째라고,REPAIR TABLE (을)를 사용할 필요가 없어지도록 해 주세요. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 . See 항7.1.3. 「MyISAM 테이블의 문제」 .

REPAIR TABLE (은)는, 파손한 가능성이 있는 테이블을 수복합니다.이 커멘드는, 이하의 컬럼으로 구성되는 테이블을 돌려줍니다.

컬럼 | 치
Table | 테이블명
Op | 항상 repair
Msg_type | status ,error ,info ,warning 의 언젠가
Msg_text | 메세지

주의: 이 스테이트먼트는, 수복한 각 테이블에 관한 많은 정보 레코드를 생성합니다. 정상적인 경우,Msg_type 하 status 그리고,Msg_text (은)는 통상 OK (이)가 됩니다.OK (을)를 얻을 수 없는 경우는,myisamchk --safe-recover 그리고 테이블의 수복을 시도해 주세요.REPAIR TABLE 그럼 아직 myisamchk 의 모든 옵션을 커버하고 있지 않습니다.장래는, 이 커멘드를 보다 유연성의 높은 것으로 할 예정입니다.

QUICK (을)를 지정했을 경우,REPAIR TABLE (은)는 인덱스 트리만을 수복하려고 합니다.

EXTENDED (을)를 사용하면,MySQL (은)는 소트 마다 인덱스를 생성하는 것이 아니라, 레코드 마다 인덱스를 생성합니다.확실히 압축되는 길다 CHAR 키를 사용하고 있는 경우 등, 고정장 키를 소트 하는 것보다 이 방법이 적합합니다.이 타입의 수복은,myisamchk --safe-recover 그리고 실행되는 수복과 거의 같습니다.

MySQL 4.0.2 (으)로부터,REPAIR 에 USE_FRM 모드가 도입되고 있습니다. .MYI 파일이 없는, 또는 그 헤더가 파손하고 있는 경우에 이 모드를 사용합니다. 이 모드에서는,.frm 파일의 정보를 사용해 테이블이 재차 작성됩니다.이러한 수복은,myisamchk 그럼 할 수 없습니다.

경고: REPAIR TABLE (을)를 실행중에 mysqld (이)가 종료되어 버렸을 경우, 다른 커멘드를 실행하기 전에 이제(벌써) 1 회 REPAIR (을)를 반드시 실행해 주세요(물론, 항상 백업으로부터 개시하는 것을 추천 합니다).최악의 경우, 데이터 파일에 관한 정보가 없는 신규의 깨끗한 인덱스 파일이 생기는 일이 있어, 다음의 커멘드로 데이터 파일이 덧쓰기되어 버릴 가능성이 있습니다.이것은 별로 없는 것입니다만, 가능성으로서는 있으므로, 주의가 필요합니다.

MySQL 4.1.1 보다 전에서는,REPAIR 커멘드는 바이너리 로그에 써지지 않습니다.MySQL 4.1.1 이?~ , 임의의 NO_WRITE_TO_BINLOG 키워드(또는 그 앨리어스(alias)의 LOCAL )(을)를 사용하지 않는 한, 이 커멘드는 바이너리 로그에 써집니다.

4.5.6. myisamchk (을)를 사용한 테이블의 보수와 크래쉬의 리커버리

MySQL 버젼 3.23.13 이?~ ,CHECK TABLE 커멘드를 사용해 MyISAM 테이블을 체크할 수 있게 되었습니다.See 항4.5.4. 「CHECK TABLE 구문」 . 테이블의 수복에는 REPAIR TABLE 커멘드를 사용할 수 있습니다. See 항4.5.5. 「REPAIR TABLE 구문」 .

MyISAM 테이블(.MYI 및 .MYD )의 체크 및 수복에는 myisamchk 유틸리티를 사용해 주세요.ISAM 테이블(.ISM 및 .ISD )의 체크 및 수복에는 isamchk 유틸리티를 사용합니다. See 장 7. MySQL 의 테이블형 .

이하의 설명은 myisamchk 에 붙어입니다만, 구 isamchk 에도 모두 들어맞읍니다.

myisamchk 유틸리티를 사용하고, 데이타베이스 테이블의 정보를 취득하거나 테이블의 체크, 수복, 및 최적화를 실행할 수 있습니다.이하의 섹션에서는,myisamchk 의 기동 방법(옵션의 설명도 포함한다), 테이블 보수의 스케줄, 및 다양한 myisamchk 기능에 대해 설명합니다.

많은 경우,OPTIMIZE TABLES 커멘드를 사용해 테이블의 최적화와 수복을 실시할 수도 있습니다만,myisamchk 에 비하면 시간이 걸려, 중대 에러의 경우는 신뢰성도 높지는 않습니다.그 반면,OPTIMIZE TABLE (은)는 사용이 간단하고, 테이블의 플래시를 걱정할 필요가 없습니다. See 항4.6.1. 「OPTIMIZE TABLE 구문」 .

myisamchk 에 의한 수복은 신뢰성이 뛰어납니다만, 수복을 실행한다(즉 테이블에 많은 변경을 더한다) 전에 , 백업을 작성해 두는 것이 필요합니다.

4.5.6.1. myisamchk 기동 구문

myisamchk (은)는 이하와 같이 기동합니다.

shell> myisamchk [options] tbl_name

options (은)는,myisamchk 하지만 실행하는 것을 지정합니다.그것들에 대해서는 여기서 설명합니다(myisamchk --help (을)를 실행하면, 옵션의 일람을 취득할 수 있습니다).옵션을 지정하지 않으면,myisamchk (은)는 테이블의 체크만을 실시합니다.상세 정보를 취득하거나myisamchk 에 수정을 실행시키려면 , 여기서 설명하는 옵션을 지정하는 것이 필요합니다.

tbl_name (은)는, 체크 및 수복 대상이 되는 데이타베이스 테이블명입니다.데이타베이스 디렉토리 이외의 장소에서 myisamchk (을)를 실행하는 경우,myisamchk 에 대해서 파일의 패스를 지정할 필요가 있습니다.실제,myisamchk (은)는 처리 대상의 파일이 데이타베이스 디렉토리에 있을지를 문제삼지 않습니다.데이타베이스 테이블의 파일을 다른 장소에 카피해, 거기서 리커버리 조작을 실행할 수도 있습니다.

myisamchk 커멘드 라인에 복수의 테이블명을 지정할 수도 있습니다.또, 인덱스 파일명(.MYI 사픽스 첨부)를 지정할 수도 있습니다.*.MYI 패턴을 사용하면 1 개의 디렉토리내의 모든 테이블을 지정할 수 있습니다. 예를 들어, 커런트 디렉토리가 데이타베이스 디렉토리인 경우, 이하와 같이 하면 디렉토리내의 전테이블을 체크할 수 있습니다.

shell> myisamchk *.MYI

커런트 디렉토리가 데이타베이스 디렉토리가 아닌 경우, 이하와 같이 디렉토리의 패스를 지정하는 것으로써, 그 전테이블을 체크할 수 있습니다.

shell> myisamchk /path/to/database_dir/*.MYI

MySQL 데이터 디렉토리의 패스에 와일드 카드를 사용하는 것으로써, 전데이타베이스의 모든 테이블을 체크할 수도 있습니다.

shell> myisamchk /path/to/datadir/*/*.MYI

모든 테이블에 대해서 간단하게 체크를 실시하는 경우, 이하의 방법을 추천 합니다.

myisamchk --silent --fast /path/to/datadir/*/*.MYI
isamchk --silent /path/to/datadir/*/*.ISM

모든 테이블을 체크해, 파손하고 있던 테이블을 모두 수복하려면 , 이하를 실행합니다.

myisamchk --silent --force --fast --update-state -O key_buffer=64M \
          -O sort_buffer=64M -O read_buffer=1M -O write_buffer=1M \
          /path/to/datadir/*/*.MYI
isamchk --silent --force -O key_buffer=64M -O sort_buffer=64M \
        -O read_buffer=1M -O write_buffer=1M /path/to/datadir/*/*.ISM

이 예에서는,64 메가바이트 이상의 빈 용량이 있는 것을 전제로 하고 있습니다.

주의: 이하의 에러가 발생하는 경우가 있습니다.

myisamchk: warning: 1 clients is using or hasn't closed the table properly

이것은, 다른 프로그램(mysqld 서버등)에 의해서 갱신되어 아직 닫혀지지 않은 파일, 또는 올바르게 닫혀지지 않은 파일의 테이블을 체크하려고 하고 있는 것입니다.

mysqld (을)를 실행중이면,FLUSH TABLES 그리고 모든 테이블의 동기와 클로우즈를 강제적으로 실행해,myisamchk (을)를 실행하는 동안은 다른 누구에게도 테이블을 사용시키지 않게 해 주세요.MySQL 버젼 3.23 그리고, 이 문제를 회피하는 가장 간단한 방법은,myisamchk 대신에 CHECK TABLE (을)를 사용해 테이블을 체크하는 것입니다.

4.5.6.2. myisamchk 의 일반적인 옵션

myisamchk (은)는, 이하의 옵션을 서포트합니다.

  • -# 또는 --debug=debug_options

    디버그 로그를 출력한다.debug_options 문자열에는,'d:t:o,filename' 하지만 자주(잘) 사용된다.

  • -? 또는 --help

    헬프 메세지를 표시해 종료한다.

  • -O name=value, --set-variable=name=value

    변수의 값을 지정한다. 주의: --set-variable=name=value 및 -O name=value 구문은 MySQL 4.0 그리고 폐?~ .대신에 --name=value (을)를 사용하는 것. myisamchk 그리고 사용할 수 있는 변수와 그 디폴트치는,myisamchk --help 그리고 확인할 수 있다.

    변수 | 치
    key_buffer_size | 523264
    read_buffer_size | 262136
    write_buffer_size | 262136
    sort_buffer_size | 2097144
    sort_key_blocks | 16
    decode_bits | 9

    sort_buffer_size (은)는, 키의 소트에 의해서 키가 수복되었을 경우에 사용한다.이것은,--recover (을)를 사용하면 통상 발생하는 상태.

    key_buffer_size (은)는,--extended-check (을)를 사용해 테이블을 체크하고 있는 경우나, 통상의 삽입과 같이, 키를 테이블의 레코드 마다 삽입하는 것으로써 키가 수복되는 경우에 사용한다.이하의 경우에, 키 버퍼에 의한 수복이 사용된다.

    • --safe-recover (을)를 사용하는 경우.

    • 키파일을 직접 작성했을 경우보다 키를 소트 했을 경우가, 필요한 임시 파일이 2 배이상의 크기가 되는 경우.소트중은 키 전체를 보존해 둘 필요가 있기 위해,CHAR 키,VARCHAR 키, 또는 TEXT 키의 사이즈가 큰 경우에 이 케이스가 발생한다.텐포라리 영역이 풍부하게 있어, 소트에 의한 수복을 myisamchk 에 실행시킬 수 있는 경우는,--sort-recover 옵션을 사용할 수 있다.

    키 버퍼에 의한 수복은, 소트에 의한 수복보다 디스크 영역은 적어도 되지만, 처리 속도는 늦어진다.

    빠른 수복을 바라보는 경우는, 상기의 변수를 이용 가능 메모리의 1/4 (으)로 설정한다.상기 버퍼는 1 번에 1 개만 사용되기 위해, 양쪽 모두의 변수를 큰 값으로 설정할 수 있다.

  • -s 또는 --silent

    사일런트 모드.에러 발생시만 출력한다.-s (을)를 2 회지정하면(-ss ),myisamchk (은)는 한층 더 출력이 적게 된다.

  • -v 또는 --verbose

    장황 모드.상세 정보를 출력한다.-d 및 -e (와)과 병용 할 수 있다.-v (을)를 여러 차례 지정하면(-vv ,-vvv 등), 보다 장황하게 된다.

  • -V 또는 --version

    myisamchk 의 버젼 정보를 출력해 종료한다.

  • -w 또는 --wait

    테이블이 락 되고 있는 경우에 에러를 내지 않고, 테이블의 락이 해제될 때까지 대기한다.주의: 그 테이블에 대해서 --skip-external-locking 옵션 첨부의 mysqld 하지만 실행하고 있는 경우, 그 테이블은 다른 myisamchk 커멘드에 의해서만 락 된다.

4.5.6.3. myisamchk 의 체크 옵션

  • -c 또는 --check

    테이블의 에러를 체크한다.myisamchk 에 대해서 명시적으로 이 옵션을 덧쓰기하는 옵션을 지정하지 않으면, 이것이 디폴트 처리가 된다.

  • -e 또는 --extend-check

    테이블을 완전하게 체크한다(인덱스가 많은 경우, 처리 시간이 걸린다).이 옵션은, 극단적인 경우에만 사용한다.통상,myisamchk 또는 myisamchk --medium-check 그리고 테이블의 에러를 검출할 수 있다.

    --extended-check (을)를 사용해, 메모리가 풍부하게 있는 경우,key_buffer_size 의 값을 크게 설정해야 한다.

  • -F 또는 --fast

    올바르게 닫혀지지 않았던 테이블만을 체크한다.

  • -C 또는 --check-only-changed

    전회의 체크이?~ (으)로 변경된 테이블만을 체크한다.

  • -f 또는 --force

    myisamchk 그리고 테이블에 에러가 검출되었을 경우,myisamchk (을)를 -r (수복)(으)로 재기동한다.

  • -i 또는 --information

    체크한 테이블의 통계를 출력한다.

  • -m 또는 --medium-check

    extended-check 보다 빠르지만, 모든 에러는 찾아낼 수 없다. 그러나, 대부분의 경우는 이것으로 충분하다.

  • -U 또는 --update-state

    테이블을 언제 체크했는지, 그 때 테이블이 파손하고 있었는지를 .MYI 파일에 기록한다.이 옵션은,--check-only-changed 옵션을 최대한 유효하게 활용하기 위해서 사용한다.다만,mysqld 서버가 그 테이블을 사용하고 있어,mysqld (을)를 --skip-external-locking 그리고 실행하고 있는 경우는, 이 옵션을 사용해선 안 된다.

  • -T 또는 --read-only

    테이블에 체크 끝난 마킹을 하지 않는다.mysqld --skip-external-locking 등이 같은, 락을 사용하지 않는 다른 어플리케이션에 의해서 사용되고 있는 테이블을,myisamchk (을)를 사용해 체크하는 경우, 이 옵션이 편리하다.

4.5.6.4. myisamchk 의 수복 옵션

이하의 옵션은,myisamchk (을)를 -r 또는 -o 그리고 기동했을 경우에 사용할 수 있습니다.

  • -B 또는 --backup

    .MYD 파일의 백업을 filename-time.BAK (으)로서 작성한다.

  • --correct-checksum

    테이블의 체크 섬 정보를 수정한다.

  • -D # 또는 --data-file-length=#

    데이터 파일의 최대장(데이터 파일이 'full' 그리고 재생성될 때).

  • -e 또는 --extend-check

    데이터 파일로부터 가능한 모든 레코드의 리커버리를 시도한다. 통상, 이 옵션에서는 가베지레코드도 많이 발견된다.그 밖에 손이 없을 때 이외는, 이 옵션은 사용하지 않게 한다.

  • -f 또는 --force

    정?~ 하지 않고, 낡은 임시 파일(table_name.TMD )(을)를 덧쓰기한다.

  • -k # 또는 --keys-used=#

    ISAM (을)를 사용하고 있는 경우,ISAM 스토리지 엔진이 최초의 # 인덱스만을 갱신하도록(듯이) 지정한다.MyISAM (을)를 사용하고 있는 경우는, 각 바이너리 비트가 1 개의 키에 대응하고 있으므로, 어느 키를 사용할까는 비트 계산을 해 지정한다. 이 옵션을 사용하고, 삽입을 고속화할 수 있다.무효화된 인덱스를 다시 유효하게 하려면 ,myisamchk -r (을)를 사용한다.

  • -l 또는 --no-symlinks

    기호 연결을 사용하지 않는다.통상,myisamchk (은)는 기호 연결이 가리키는 테이블을 수복한다.이 옵션은 MySQL 4.0 에는 없다.MySQL 4.0 그럼 수복중에 기호 연결이 삭제되지 않기 때문이다.

  • -p 또는 --parallel-recover

    -r 및 -n (와)과 같은 테크닉을 사용하지만, 모든 키를 복수의 스레드로 병렬처리 한다. 이 옵션은 MySQL 4.0.2 그리고 도입. 이것은, 알파 코드이다.사용에는 리스크가 수반한다.

  • -r 또는 --recover

    대부분의 에러를 수복할 수 있다.다만, 유니크 키가 일의가 아닌 에러의 경우에는 대응할 수 없다(ISAM 테이블 또는 MyISAM 테이블에서는 매우 드문 에러이다). 테이블을 리커버리 하는 경우는, 우선 이 옵션을 시험한다.-r 그럼 테이블을 리커버리 할 수 없으면 myisamchk 에 의해 보고되었을 경우만,-o (을)를 실행한다.주의: 좀처럼 없는 것이지만 -r 하지만 실패했을 경우에서도, 데이터 파일은 손상을 받지 않는다. 메모리가 풍부하게 있는 경우는,sort_buffer_size 의 사이즈를 크게 해야 한다.

  • -o 또는 --safe-recover

    낡은 리커버리 방식을 사용한다(모든 레코드를 차례대로 읽어내, 검출된 레코드에 근거해 모든 인덱스 트리를 갱신한다).이것은 -r 보다 꽤 늦지만,-r 그리고 처리할 수 없는 경우에도 대응한다.이 리커버리 방식은,-r 보다 디스크 용량의 사용이 적어도 된다.통상은 최초로 -r 그리고 수복을 시도하고, 거기에 실패했을 경우만 -o (을)를 사용한다.

    메모리가 풍부하게 있는 경우는,key_buffer_size 의 사이즈를 크게 해야 한다.

  • -n 또는 --sort-recover

    임시 파일이 매우 큰 경우에서도, 키 해결을 위해서 myisamchk 에 소트를 강제한다.

  • --character-sets-dir=...

    캐릭터 세트가 격납되고 있는 디렉토리.

  • --set-character-set=name

    인덱스에 의해서 사용되는 캐릭터 세트를 변경한다.

  • -t 또는 --tmpdir=path

    임시 파일을 보존하는 패스.이것을 설정하지 않는 경우,myisamchk (은)는 이것에 환경 변수 TMPDIR (을)를 사용한다. MySQL 4.1 이?~ ,tmpdir 그리고, 복수의 패스를 코론 : 그리고 단락짓고 설정할 수 있게 되어 있다(Windows 그럼 세?~ 코론 ; ).이것은, 라운드로빈 방식으로 사용된다.

  • -q 또는 --quick

    데이터 파일을 수정하지 않는 것에보다 , 수복을 빠르게 실시한다.-q (을)를 2 회지정하면, 중복 키의 경우에,myisamchk 에 오리지날의 데이터 파일의 수정을 강제한다.

  • -u 또는 --unpack

    myisampack 그리고 팩 된 파일을 unpack 한다.

4.5.6.5. myisamchk 의 그 외의 옵션

이하는,myisamchk 그리고 실행할 수 있는, 테이블의 수복 및 체크 이외의 조작입니다.

  • -a 또는 --analyze

    키의 분포를 분석한다.이 옵션을 사용하는 것으로써, 결합 Optimizer가, 테이블의 결합 순서나 사용해야 할 키를 보다 적확하게 판단할 수 있게 되기 위해, 결합 퍼포먼스가 향상한다. myisamchk --describe --verbose table_name' 또는 MySQL 그리고 SHOW KEYS (을)를 사용하는 것으로써, 키의 분포를 확인할 수 있다.

  • -d 또는 --description

    테이블에 관한 정보를 출력한다.

  • -A 또는 --set-auto-increment[=value]

    지정의 값이상으로 AUTO_INCREMENT (을)를 개시한다.여기서 값을 지정하지 않으면, 다음의 AUTO_INCREMENT 값은, 오토 키에 사용된 최고치에 1 (을)를 더한 값이 된다.

  • -S 또는 --sort-index

    인덱스 트리 블록을?~ 순서에 소트 한다. 검색이 최적화되어 키에 의한 테이블 스캔이 빨라진다.

  • -R 또는 --sort-records=#

    인덱스에 따라서 레코드를 소트 한다.이 소트에 의해, 데이터가 정리되어 이 인덱스로의 SELECT (이)나 ORDER BY 의 처리 속도가 빨라진다(최초의 소트는 매우 늦어진다). 테이블의 인덱스 번호를 조사하려면 SHOW INDEX (을)를 사용한다.테이블의 인덱스가 myisamchk 하지만 검출하는 순서로 표시된다.인덱스 번호는 1 (으)로부터 시작된다.

4.5.6.6. myisamchk 의 메모리 사용

myisamchk (을)를 실행하는 경우, 메모리의 배분이 중요한 문제가 됩니다. myisamchk (은)는,-O 옵션으로 지정한 사이즈 이상의 메모리는 사용하지 않습니다.매우 큰 파일에 대해서 myisamchk (을)를 사용하는 경우, 메모리의 사용량을 최초로 결정해 둬 주세요.수복 처리에 사용하는 메모리의 디폴트치는 약 3 메가바이트입니다.큰 값을 사용하면,myisamchk 의 처리를 고속화할 수 있습니다.예를 들어,32 메가바이트 이상의 RAM 하지만 있는 경우, 이하와 같이 옵션을 지정할 수 있습니다(필요에 따라서 다른 옵션도 추가합니다).

shell> myisamchk -O sort=16M -O key=16M -O read=1M -O write=1M ...

대부분의 경우,-O sort=16M 그리고 충분합니다.

myisamchk (은)는,TMPDIR 의 임시 파일을 사용하는 것에 주의해 주세요.TMPDIR 하지만 메모 refile 시스템을 포인트 하고 있으면, 곧바로 메모리 부족 에러가 됩니다.이 에러가 발생하는 경우에는,TMPDIR (을)를, 용량의 큰 디렉토리를 가리키도록(듯이) 설정해,myisamchk (을)를 재기동합니다.

수복시도,myisamchk (은)는 큰 디스크 용량을 필요로 합니다.

  • 레코드 파일 사이즈의 2 배(오리지날과 카피의 분 ).--quick 그리고 수복을 실행하는 경우, 인덱스 파일만이 재생성되기 위해, 이 용량은 불필요하다.오리지날의 레코드 파일과 같은 디스크상에 이 용량이 필요하다.

  • 낡은 인덱스 파일과 옮겨놓을 수 있는 새로운 인덱스 파일의 용량.낡은 인덱스 파일은 최초로 잘라 버릴 수 있기 위해, 통상, 이 용량은 무시된다. 오리지날의 인덱스 파일과 같은 디스크상에 이 용량이 필요하다.

  • --recover 또는 --sort-recover (을)를 사용하는 경우(--safe-recover (을)를 사용하는 경우는 포함되지 않는다), 소트 버퍼용의 용량으로서 (largest_key + row_pointer_length)*number_of_rows * 2 하지만 필요하다. 키의 길이 및 레코드 포인터의 길이를 확인하려면 ,myisamchk -dv table (을)를 사용한다. 이 용량은, 텐포라리디스크에 할당할 수 있다(TMPDIR 또는 --tmpdir=# 그리고 지정).

수복중에 디스크 용량에 관한 문제가 발생했을 경우는,--recover 대신에 --safe-recover (을)를 사용할 수 있습니다.

4.5.6.7. myisamchk (을)를 사용한 크래쉬의 리커버리

mysqld (을)를 --skip-external-locking 그리고 실행하고 있는 경우(Linux 등의 시스템에서는 디폴트),mysqld 하지만 사용하고 있는 같은 테이블을 myisamchk 그리고 체크해도 신뢰할 수 없습니다.myisamchk 의 실행중,mysqld (으)로부터 테이블에 액세스 하는 유저가 확실히 없는 경우만,mysqladmin flush-tables (을)를 실행하고 나서 테이블을 체크합니다.테이블에 액세스 하는 유저가 있을지 확신할 수 없는 경우에는, 테이블을 체크하는 동안,mysqld (을)를 정?~ 할 필요가 있습니다.mysqld 하지만 테이블을 갱신하고 있을 때 myisamchk (을)를 실행하면, 테이블이 파손하고 있지 않는 경우에서도 파손의 경고가 나올 가능성이 있습니다.

--skip-external-locking (을)를 사용하고 있지 않으면, 언제라도 myisamchk (을)를 사용해 테이블을 체크할 수 있습니다.이전, 테이블을 갱신하려고 하는 클라이언트는 모두,myisamchk 의 준비가 갖추어지는 것을 기다리고 나서 실행합니다.

myisamchk (을)를 사용해 테이블을 수복 또는 최적화하는 경우, 반드시 ,mysqld 서버가 그 테이블을 사용하고 있지 않는 것을 확인해 주세요(--skip-external-locking (을)를 사용하고 있는 경우도 같습니다). mysqld (을)를 정?~ 하지 않는 경우는, 적어도 mysqladmin flush-tables (을)를 myisamchk 의 전에 실행해 주세요. 서버와 myisamchk 하지만 동시에 테이블에 액세스 하면, 테이블이 파손할 우려가 있습니다 .

이 장에서는,MySQL 데이타베이스의 데이터 파손의 체크 방법 및 그 대처 방법에 대해 설명합니다.테이블이 빈번히 파손하는 경우는, 원인을 찔러?~ 필요가 있습니다. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

MyISAM 테이블의 섹션으로, 테이블이 파손하는 원인을 나타내고 있습니다. See 항7.1.3. 「MyISAM 테이블의 문제」 .

크래쉬를 리커버리 할 때 , 데이타베이스내의 테이블 tbl_name 의 각각이 데이타베이스 디렉토리내의 다음의 3 개의 파일에 대응하고 있는 것을 이해해 둘 필요가 있습니다.

파일 | 용도
tbl_name.frm | 테이블 정의 파일
tbl_name.MYD | 데이터 파일
tbl_name.MYI | 인덱스 파일

이것들 3 개의 파일 타입은 모두 다양한 형태로 파손할 가능성이 있습니다만, 특히 데이터 파일과 인덱스 파일에 문제가 자주(잘) 발생합니다.

myisamchk (은)는,.MYD (데이터) 파일의 카피를 레코드 마다 생성합니다.수복의 최종 단계에서 낡다 .MYD 파일을 삭제해, 신규 파일을 오리지날의 이름으로 변경합니다.--quick (을)를 사용하고 있는 경우,myisamchk (은)는 텐포라리 .MYD 파일을 생성하지 않습니다만, 대신에 .MYD 파일이 정상적이다라고 간주,.MYD 파일에 손보지 않고 신규 인덱스 파일만을 생성합니다..MYD 파일에 문제가 있었을 경우는 myisamchk 하지만 자동적으로 검지해 수복을 안?~ 하기 위한(해), 이 방법도 안전합니다.2 개의 --quick 옵션을 myisamchk (으)로 설정할 수도 있습니다.이 경우,myisamchk (은)는 몇개의 에러(중복 키등)에서도 안?~ 하지 않고,.MYD 파일을 수정해 해결하려고 합니다.통상의 수복 처리에 디스크의 빈 용량에서는 부족한 경우에게만,2 개의 --quick 옵션지정이 도움이 됩니다.이 경우, 적어도 myisamchk (을)를 실행하기 전에 백업을 작성해 두어 주세요.

4.5.6.8. 테이블의 에러 체크 방법

MyISAM 테이블을 체크하려면 , 이하의 커멘드를 사용합니다.

  • myisamchk tbl_name

    이것으로, 에러의 대부분은 발견할 수 있다.이것으로 발견할 수 없는 에러는, 데이터 파일 만 에 관련하는 파손이다(이것은 매우 희귀).테이블을 체크하는 경우, 통상,myisamchk (을)를 옵션 없음인가,-s 또는 --silent 의 옵션으로 실행한다.

  • myisamchk -m tbl_name

    이것으로, 에러의 대부분은 발견할 수 있다.이 커멘드를 실행하면, 최초로 모든 인덱스 엔트리의 에러가 체크되어 다음에 모든 레코드가 읽힌다.레코드의 모든 키의 체크 섬이 계산되어 그 결과가 인덱스 트리의 키의 체크 섬과 일치할지 확인된다.

  • myisamchk -e tbl_name

    이 커멘드를 실행하면, 모든 데이터의 완전한 체크를 한다(-e 하 ``extended check'' ).각 레코드의 모든 키가 읽어내져 체크되어 올바른 레코드가 가리켜지고 있을까 확인된다.이 조작은, 많은 키가 있는 큰 테이블에서는 시간이 걸린다.myisamchk (은)는 통상, 최초의 에러가 발견된 시점에서 정?~ 한다.상세 정보를 얻으려면 ,--verbose (-v ) 옵션을 추가한다.이것에 의해,myisamchk (은)는 최대 20 의 에러가 검출될 때까지 처리를 속행한다. 통상은, 테이블명 이외의 인수를 지정하지 않는다 myisamchk 만으로 충분하다.

  • myisamchk -e -i tbl_name

    전의 커멘드와 닮아 있지만,-i 옵션에 의해서 myisamchk 하지만 통계 정보도 출력한다.

4.5.6.9. 테이블의 수복 방법

이 섹션에서는,MyISAM 테이블(.MYI 및 .MYD 의 확장자(extension))에 대해서 myisamchk (을)를 사용하는 방법에 대해 설명합니다.ISAM 테이블(.ISM 및 .ISD 의 확장자(extension))에 대해서는,isamchk (을)를 사용해 주세요.

MySQL 버젼 3.23.14 이?~ ,REPAIR TABLE 커멘드로 MyISAM 테이블을 수복할 수 있게 되어 있습니다. See 항4.5.5. 「REPAIR TABLE 구문」 .

테이블 파손의 증상으로서는, 쿼리가 예기 하지 않고 중단하거나 이하와 같은 에러가 발생합니다.

  • tbl_name.frm is locked against change

  • Can't find file tbl_name.MYI (Errcode: ###)

  • Unexpected end of file

  • Record file is crashed

  • Got error ### from table handler

    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
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 )(은)는, 단순한 수복에서 고칠 수 있는 에러는 아니다.이 경우, 이하의 커멘드를 실행하는 것이 필요.

    mysql> ALTER TABLE table MAX_ROWS=xxx AVG_ROW_LENGTH=yyy;

    이 수법은, 에러 136 (no more room in index file )에 대해서도 사용할 수 있다.

다른 경우에 대해서는 테이블을 수복할 필요가 있습니다.통상은,myisamchk 그리고 대부분의 에러를 검출해 수복할 수 있습니다.

수복 프로세스는, 이하 설명하도록(듯이) 4 단계로 구성됩니다.개시하기 전에, 데이타베이스 디렉토리에 이동(cd ) 해 테이블 파일의 액세스권을 확인해 주세요.mysqld (을)를 실행한다 Unix 유저에게 읽어내 권한이 있는 것을 확인합니다(이 확인을 실시하는 유저에게도 이러한 파일에의 액세스권이 필요).파일을 수정할 필요가 있는 경우는, 기입 권한도 필요합니다.

MySQL 버젼 3.23.16 이?~ (을)를 사용하고 있는 경우는,CHECK 커멘드와 REPAIR 커멘드를 사용해 MyISAM 테이블의 체크 및 수복을 실행할 수 있습니다(가능한 한, 이러한 커멘드를 사용해 주세요). See 항4.5.4. 「CHECK TABLE 구문」 . See 항4.5.5. 「REPAIR TABLE 구문」 .

테이블 보수에 관한 섹션으로,isamchk 및 myisamchk 의 옵션을 설명하고 있습니다. See 항4.5.6. 「myisamchk (을)를 사용한 테이블의 보수와 크래쉬의 리커버리」 .

이러한 커멘드로 실패했을 경우, 또는 isamchk 및 myisamchk 의 확장 기능을 사용하는 경우에 대해, 이하의 설명을 참고로 해 수복 작업을 실시해 주세요.

커멘드 라인을 사용해 테이블을 수복하는 경우, 우선,mysqld 서버를 슛다운 할 필요가 있습니다.주의: mysqladmin shutdown (을)를 리모트 서버로부터 실행했을 경우,mysqladmin 하지만 돌아와도 당분간의 사이,mysqld 서버는 슛다운 하지 않습니다.모든 쿼리가 정?~ 해 모든 키가 디스크에 플래시 된 시점에서 슛다운 합니다.

단계 1: 테이블의 체크

myisamchk *.MYI 또는 시간에 여유가 있으면 myisamchk -e *.MYI (을)를 실행합니다.-s (사일런트) 옵션을 사용하면, 불필요한 정보는 출력되지 않습니다.

mysqld 서버가 종료하고 있는 경우,--update 옵션을 사용해 myisamchk 하지만 테이블에 'checked' 의 마크를 붙이도록(듯이) 합니다.

myisamchk 하지만 에러를 돌려준 테이블만, 수복할 필요가 있습니다.그러한 테이블에 대해서는, 단계 2 에 진행됩니다.

체크시에 복잡한 에러(out of memory 에러등)이 발생했을 경우, 혹은 myisamchk 하지만 크래쉬 했을 경우는 단계 3 에 진행됩니다.

단계 2: 간단하고 안전한 수복

주의: 수복을 빠르게 실시하려면 ,-O sort_buffer=# -O key_buffer=# (# (은)는 이용 가능 메모리의 약 4 분의 1 )(을)를 모든 isamchk/myisamchk 커멘드에 추가합니다.

최초로 myisamchk -r -q tbl_name (-r -q 하 `` 퀵 리커버리 모드'' 의 뜻)을 실행합니다.이것에 의해, 데이터 파일을 변경하지 않고 인덱스 파일의 수복만을 합니다.데이터 파일에 있어야 할 물건이 모두 있어, 삭제 링크가 데이터 파일내의 올바른 장소를 가리키고 있으면, 테이블은 정상적으로 수복됩니다.성공하면, 다음의 테이블의 수복을 개시합니다.실패했을 경우는 이하의 순서를 실행합니다.

  1. 우선, 데이터 파일의 백업을 작성한다.

  2. myisamchk -r tbl_name (-r 하 `` 리커버리 모드'' 의 뜻)을 사용한다.이것에 의해, 부정한 레코드와 삭제된 레코드가 데이터 파일로부터 삭제되어 인덱스 파일이 재구축 된다.

  3. 전의 스텝이 실패했을 경우,myisamchk --safe-recover tbl_name (을)를 사용한다. 세이프 리커버리 모드에 의해, 낡은 리커버리 형식이 사용되어 통상의 리커버리 모드에서는 처리할 수 없는 수복을 한다.다만, 시간이 걸린다.

수복시에 복잡한 에러(out of memory 에러등)이 발생했을 경우, 혹은 myisamchk 하지만 크래쉬 했을 경우는 단계 3 에 진행됩니다.

단계 3: 곤란한 수복

인덱스 파일의 최초의 16K 블록이 파손 또는 부정한 정보를 포함한 경우, 혹은 인덱스 파일이 없는 경우만, 이 단계로 나아갑니다.이 단계에서는, 새로운 인덱스 파일을 작성할 필요가 있습니다.이하를 실행해 주세요.

  1. 데이터 파일을 안전한 장소로 이동한다.

  2. 테이블 기술 파일을 사용하고, 새로운(공백의) 데이터와 인덱스 파일을 작성한다.

    shell> mysql db_name
mysql> SET AUTOCOMMIT=1;
mysql> TRUNCATE TABLE table_name;
mysql> quit

    사용하고 있다 SQL 버젼에 TRUNCATE TABLE 하지만 없는 경우는, 대신에 DELETE FROM table_name (을)를 사용한다.

  3. 낡은 데이터 파일을, 새롭게 작성한 데이터 파일에 카피한다 (단지 낡은 파일을 새로운 파일로 이동하는 것이 아니라, 만일에 대비해 원의 장소에도 남겨 둔다).

단계 2 에 돌아옵니다.이것으로,myisamchk -r -q 하지만 기능할 것입니다(엔들레스 루프가 되지 않을 것입니다).

MySQL 4.0.2 보다 , 이 순서 전체를 자동으로 실행한다 REPAIR ... USE_FRM 도 사용할 수 있게 되었습니다.

단계 4: 매우 곤란한 수복

기술 파일도 크래쉬 하고 있는 경우에게만 이 단계로 나아갑니다.다만, 테이블 작성 후에 기술 파일이 변경될 것은 없기 때문에, 통상은 발생하지 않는 상황입니다.

  1. 백업으로부터 기술 파일을 restore 해, 단계 3 에 돌아온다.인덱스 파일을 restore 해 단계 2 에 돌아올 수도 있다.후자의 경우,myisamchk -r (을)를 실행한다.

  2. 백업이 없는 경우에서도, 테이블이 어떻게 작성되었는지 정확하게 알고 있으면, 다른 데이타베이스에 테이블의 카피를 작성한다.테이블의 카피를 작성한 데이타베이스로부터, 새로운 데이터 파일을 삭제해, 기술 파일과 인덱스 파일을, 크래쉬 한 데이타베이스로 이동한다.이것으로 새로운 기술 파일과 인덱스 파일이 생겨 데이터 파일은 전의 것이 그대로 남는다.단계 2 에 돌아와, 인덱스 파일을 재구축 한다.

4.5.6.10. 테이블의 최적화

단편화한 레코드를 결합하거나 레코드의 삭제 또는 갱신에 의해서 발생한 쓸데 없는 스페이스를 제거하려면 ,myisamchk (을)를 리커버리 모드로 실행합니다.

shell> myisamchk -r tbl_name

같이SQL 의 OPTIMIZE TABLE 스테이트먼트를 사용하고, 테이블을 최적화할 수도 있습니다.OPTIMIZE TABLE (은)는 테이블의 수복과 키 분석을 실시해, 한층 더 인덱스 트리를 소트 하고, 키 주사의 처리 속도를 올립니다. 또,OPTIMIZE TABLE (을)를 사용했을 경우, 서버측에서 모든 처리를 하기 위해, 유틸리티와 서버간에 불필요한 교환이 발생하지 않습니다. See 항4.6.1. 「OPTIMIZE TABLE 구문」 .

myisamchk 에는, 테이블의 퍼포먼스를 향상시키기 위한 옵션이 많이 준비되어 있습니다.

  • -S, --sort-index

  • -R index_num, --sort-records=index_num

  • -a, --analyze

옵션의 상세한 설명에 대해서는,See 항4.5.6.1. 「myisamchk 기동 구문」 (을)를 참조해 주세요.

4.5.7. 테이블 보수 계획

MySQL 버젼 3.23.13 이?~ ,CHECK TABLE 커멘드를 사용해 MyISAM 테이블을 체크할 수 있게 되었습니다.See 항4.5.4. 「CHECK TABLE 구문」 . 테이블의 수복은 REPAIR TABLE 커멘드로 실시할 수 있습니다. See 항4.5.5. 「REPAIR TABLE 구문」 .

문제가 발생하는 것을 기다리는 것보다, 정기적으로 테이블 체크를 실시하는 것을 추천 합니다.보수 목적에서는,myisamchk -s (을)를 사용해 테이블을 체크할 수 있습니다.-s 옵션(--silent 의 단축형)을 사용하면, 사일런트 모드로 myisamchk 하지만 실행되어 에러 발생시만 메세지가 출력됩니다.

또, 서버가 기동할 때마다 테이블을 체크한다고 하는 방법도 있습니다. 예를 들어, 갱신의 도중에 머신이 리부트되었을 경우, 영향을 받은 가능성이 있는 테이블을 모두 체크할 필요가 있습니다(즉,`` 파손의 가능성이 있는 테이블'' (을)를 체크합니다).리부트 후에 낡다 .pid (프로세스 ID ) 파일이 남아 있었을 경우,mysqld_safe 에 테스트를 추가하고, 직전의 24 시간 이내로 변경된 테이블의 체크를 myisamchk 그리고 실행할 수 있습니다..pid 파일은 mysqld 기동시에 작성되어 정상 종료시에 삭제됩니다.시스템 기동시에 .pid 파일이 존재하고 있으면,mysqld 하지만 이상종료(ABEND) 한 것이 됩니다.

보다 완전한 테스트를 실시하려면 ,.pid 파일의 작성 후로 변경된 모든 테이블을 체크한다고 하는 방법도 있습니다.

통상의 시스템 운용중에도 정기적으로 테이블을 체크해 주세요.MySQL AB 그럼, 주에 한 번 cron 작업을 실행해 중요한 테이블을 체크하고 있습니다.crontab 파일은 이하와 같이 됩니다.

35 0 * * 0 /path/to/myisamchk --fast --silent /path/to/datadir/*/*.MYI

이것으로, 크래쉬 한 테이블에 관한 정보가 출력되므로, 필요에 따라서 검사 및 수복을 실시할 수 있습니다.

최근 몇년, 예상외의 테이블 파손(하드웨어 트러블 이외에 밤파손)은 발생하고 있지 않았기 때문에, 당사에서는 주에 한 번의 체크로 충분히로 하고 있습니다.

최초 중은,myisamchk -s (을)를 매일 저녁 실행하고, 직전의 24 시간 이내에 갱신된 모든 테이블을 체크하도록(듯이) 합니다.잠시 후에,MySQL 의 신뢰성의 높이를 실감할 수 있을 것입니다.

통상,MySQL 테이블의 보수는 그만큼 빈번히 실시할 필요는 없습니다.동적 사이즈의 레코드(VARCHAR 컬럼,BLOB 컬럼, 또는 TEXT 컬럼)이 있는 테이블을 변경하거나 많은 레코드가 삭제된 테이블이 있는 경우에는, 달에 한 번 정도, 최적화를 실시해 테이블의 영역을 해방하는 것을 추천 합니다.

이것을 실시하려면 , 목적의 테이블로 OPTIMIZE TABLE (을)를 실행하는지,mysqld 서버를 정?~ 해 이하를 실행합니다.

isamchk -r --silent --sort-index -O sort_buffer_size=16M */*.ISM
myisamchk -r --silent --sort-index  -O sort_buffer_size=16M */*.MYI

4.5.8. 테이블 정보의 취득

테이블에 관한 정보 또는 그 통계를 취득하려면 , 이하의 커멘드를 실행합니다.이러한 정보에 대해서는 다음에 자세하게 설명합니다.

  • myisamchk -d tbl_name myisamchk (을)를 ``describe 모드'' 그리고 실행해, 테이블 정보를 생성한다.--skip-external-locking 옵션을 사용해 MySQL 서버를 기동했을 경우,myisamchk (은)는, 실행중에 갱신된 테이블에 대해서 에러를 보고하는 경우가 있다.그러나,myisamchk 하 describe 모드에서는 테이블을 변경하지 않기 때문에, 데이터 파괴의 위험성은 없다.

  • myisamchk -d -v tbl_name myisamchk 의 실행중의 처리에 관한 상세한 정보를 취득하려면 ,-v (을)를 추가해 장황 모드로 실행한다.

  • myisamchk -eis tbl_name 테이블의 최대중요 정보만 표시한다.테이블 전체를 읽어내게 되므로, 시간이 걸린다.

  • myisamchk -eiv tbl_name -eis (와)과 거의 같지만, 이 옵션을 사용하면, 진행중의 처리도 표시된다.

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
8   138   4   multip. unsigned long
9   177   4   multip. unsigned long
    193   1           text

myisamchk -d -v 에 의한 출력예

MyISAM file:         company
Record format:       Fixed length
File-version:        1
Creation time:       1999-10-30 12:12:51
Recover time:        1999-10-31 19:13:01
Status:              checked
Data records:           1403698  Deleted blocks:              0
Datafile parts:         1403698  Deleted data:                0
Datafilepointer (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
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
8   138   4   multip. unsigned long              87 85036032      1024
9   177   4   multip. unsigned long             178 96481280      1024
    193   1           text

myisamchk -eis 에 의한 출력예

Checking MyISAM file: company
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
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
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
Data records: 1403698   Deleted blocks:       0
- 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:
index  9:
No recordlinks
- check index reference
- check data record references index: 1
Key:  1:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 2
Key:  2:  Keyblocks used:  98%  Packed:   50%  Max levels:  4
- check data record references index: 3
Key:  3:  Keyblocks used:  97%  Packed:    0%  Max levels:  4
- check data record references index: 4
Key:  4:  Keyblocks used:  99%  Packed:   60%  Max levels:  3
- check data record references index: 5
Key:  5:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 6
Key:  6:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 7
Key:  7:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 8
Key:  8:  Keyblocks used:  99%  Packed:    0%  Max levels:  3
- check data record references index: 9
Key:  9:  Keyblocks used:  98%  Packed:    0%  Max levels:  4
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
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

상기의 예로 사용된 테이블의 데이터 파일 및 인덱스 파일의 사이즈는 이하대로입니다.

-rw-rw-r--   1 monty    tcx     317235748 Jan 12 17:30 company.MYD
-rw-rw-r--   1 davida   tcx      96482304 Jan 12 18:35 company.MYI

이하,myisamchk 하지만 생성하는 정보의 타입에 대해 설명합니다.`` 키파일'' (와)과는 인덱스 파일입니다.`` 레코드'' (와)과 `` 로'' (은)는 동의어입니다.

  • ISAM file ISAM (인덱스) 파일의 이름.

  • Isam-version ISAM 형식의 버젼.현재는 항상 2 .

  • Creation time 데이터 파일의 작성 일시.

  • Recover time 인덱스 또는 데이터 파일이 전회 재구축 된 일시.

  • Data records 테이블내의 레코드수.

  • Deleted blocks 예약이 끝난 영역을 아직 점유 하고 있는 삭제 끝난 블록수. 테이블을 최적화하고, 이 영역을 최소로 할 수 있다. See 항4.5.6.10. 「테이블의 최적화」 .

  • Data file:Parts 동적인 레코드 형식에 대해서는, 존재하는 데이터 블록수.단편화 된 레코드가 없는 최적화된 테이블에 대해서는,Data records (와)과 같다.

  • Deleted data 영역이 해방되어 있지 않은 삭제가 끝난 데이터의 아르바이트수. 테이블을 최적화하고, 이 영역을 최소로 할 수 있다. See 항4.5.6.10. 「테이블의 최적화」 .

  • Data file pointer 데이터 파일 포인터의 사이즈(아르바이트 단위).통상은 2 ,3 ,4 , 또는 5 아르바이트.대부분의 테이블은 2 아르바이트로 충분하지만, 현재로서는,MySQL 그리고 제어할 수 없다.고정 테이블에서는, 이것은 레코드 주소.동적 테이블에서는, 아르바이트 주소.

  • Keyfile pointer 인덱스 파일 포인터의 사이즈(아르바이트 단위).통상은 1 ,2 , 또는 3 아르바이트.대부분의 테이블은 2 아르바이트로 충분하지만,MySQL 에 의해서 자동적으로 계산된다.항상 블록 주소이다.

  • Max datafile length 테이블의 데이터 파일(.MYD 파일)의 최대장(아르바이트 단위).

  • Max keyfile length 테이블의 키파일(.MYI 파일)의 최대장(아르바이트 단위).

  • Recordlength 각 레코드가 사용하는 영역 사이즈(아르바이트 단위).

  • Record format 테이블 레코드의 격납 형식. 상기의 예에서는 Fixed length (을)를 사용. 그 밖에,Compressed 및 Packed 하지만 있다.

  • table description 테이블내의 모든 키의 일람.각 키에 대해서, 이하의 저레벨 정보가 표시된다.

    • Key 키 번호.

    • Start 인덱스부가 시작되는 레코드내의 위치.

    • Len 인덱스부의 길이.팩 된 수치의 경우, 이것은 항상 그 컬럼의 전체 길이가 된다.문자열의 경우, 문자열 컬럼의 프리픽스를 인덱스로 할 수 있기 위해, 인덱스화 된 컬럼의 전체 길이보다 짧아지는 경우가 있다.

    • Index unique 또는 multip. (복수).이 인덱스에 값의 중복이 인정되고 있는지 어떤지를 나타낸다.

    • Type 인덱스부의 데이터형.packed ,stripped , 또는 empty 의 몇개의 ISAM 데이터형.

    • Root 루트 인덱스 블록의 주소.

    • Blocksize 각 인덱스 블록의 사이즈.디폴트에서는 1024 이지만, 컴파일시로 변경 가능.

    • Rec/key Optimizer에 의해서 사용되는 통계치.이 키의 값 마다의 레코드수를 나타낸다.유니크 키의 값은 항상 1 .이것은,myisamchk -a 그리고 테이블이 로드(또는 크게 변경) 되면 갱신된다.전혀 갱신되지 않는 경우는, 디폴트치의 30 된다.

  • 위의 최초의 예의 9 번째의 키는 2 개의 파트를 가지는 멀티 파트 키.

  • Keyblocks used 사용된 키 블록의 퍼센트.예로 사용된 테이블은 myisamchk 그리고 재구성된지 얼마되지 않아, 값은 매우 비싸다(이론적인 최대치에 매우 가깝다).

  • Packed MySQL (은)는 공통의 사픽스로 키의 팩을 시도한다.이것은,CHAR ,VARCHAR ,DECIMAL 의 각 키에게만 사용할 수 있다.이름과 같이 긴 문자열에서는, 팩에 의해 사용 영역을 크게 줄일 수 있다.위의 3 번째의 예에서는,4 번째의 키가 10 문자장으로, 영역이 60 퍼센트 감소하고 있다.

  • Max levels 이 키의 B-tree 의 깊이.긴 키가 있는 큰 테이블에서는, 값이 비싸진다.

  • Records 테이블내의 레코드수.

  • M.recordlength 레코드의 평균의 길이.고정장 레코드의 테이블에서는, 이것은 실제의 레코드장이 된다.

  • Packed MySQL (은)는, 문자열의 최후로부터 스페이스를 삭제한다.Packed 값은, 이것에 의해서 절약된 퍼센트를 나타낸다.

  • Recordspace used 사용되고 있는 데이터 파일의 퍼센트.

  • Empty space 사용되어 있지 않은 데이터 파일의 퍼센트.

  • Blocks/Record 레코드마다의 평균 블록수(단편화 레코드를 구성하는 링크수).이것은, 고정 형식 테이블에서는 항상 1.0 .이 값은 가능한 한,1.0 에 가까운 시일내에 해 둔다.너무 커졌을 경우는,myisamchk 그리고 재편성 할 수 있다. See 항4.5.6.10. 「테이블의 최적화」 .

  • Recordblocks 사용되고 있는 블록(링크) 수.고정 형식에서는, 레코드수와 같게 된다.

  • Deleteblocks 삭제된 블록(링크) 수.

  • Recorddata 사용되고 있는 데이터 파일의 아르바이트수.

  • Deleted data 삭제된(사용되어 있지 않다) 데이터 파일의 아르바이트수.

  • Lost space 레코드의 길이를 짧게 해 갱신했을 경우, 영역이 얼마인가 없어진다.그 없어진 영역의 합계 바이트수.

  • Linkdata 동적 테이블 형식에서는, 레코드의 단편이 포인터로 링크되고 있다(각각 4 ~ 7 아르바이트).Linkdata (은)는, 그러한 포인터 모두에게 사용되고 있는 스토리지량의 합계를 나타낸다.

테이블이 myisampack 그리고 압축되고 있는 경우,myisamchk -d (을)를 실행하면, 각 테이블 컬럼에 관한 추가 정보가 출력됩니다.이러한 정보 및 그 의미에 대해서는, 항4.8.4. 「myisampack (MySQL 압축 독해 전용 테이블 제네레이터)」 (을)를 참조해 주세요.


4.6. 데이타베이스 관리 언어 레퍼런스

4.6.1. OPTIMIZE TABLE 구문

OPTIMIZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name]...

OPTIMIZE TABLE (은)는, 테이블의 대부분을 삭제하거나 가변장 레코드를 가지는 테이블(VARCHAR 컬럼,BLOB 컬럼, 또는 TEXT 컬럼을 가지는 테이블)에 많은 변경을 더했을 경우에 사용합니다. 삭제된 레코드는 링크된 리스트에 보관 유지되어 원의 레코드 위치는, 후속의 INSERT 조작에 의해 재이용됩니다.OPTIMIZE TABLE (을)를 사용해 미사용 영역을 해방해, 데이터 파일을 최적화할 수 있습니다.

대부분의 경우,OPTIMIZE TABLE (을)를 실행할 필요는 없습니다.가변장 레코드에 갱신을 많이 실시하는 경우에서도, 주 또는 달에 한 번, 특정의 테이블인 만큼 실행하는 것만으로 충분합니다.

현재로서는,OPTIMIZE TABLE 하 MyISAM 테이블과 BDB 테이블에게만 유효합니다.BDB 테이블에서는,OPTIMIZE TABLE (은)는 현재 ANALYZE TABLE 에 맵 됩니다. See 항4.6.2. 「ANALYZE TABLE 구문」 .

mysqld (을)를 --skip-new 또는 --safe-mode 그리고 기동하는 것으로써,OPTIMIZE TABLE (을)를 다른 테이블 타입이라도 사용할 수 있게 됩니다.그러나 이 경우,OPTIMIZE TABLE 하 ALTER TABLE 에 맵 됩니다.

OPTIMIZE TABLE (은)는 이하와 같이 동작합니다.

  • 테이블에 삭제된 레코드 또는 분할된 레코드가 있는 경우, 테이블을 수복한다.

  • 인덱스 페이지가 소트 되어 있지 않은 경우, 소트 한다.

  • 통계가 최신이 아니면( 및 인덱스의 소트에 의한 수복을 할 수 없었던 경우) 통계를 갱신한다.

주의: OPTIMIZE TABLE 의 실행중, 테이블은 락 됩니다.

MySQL 4.1.1 보다 전의 버젼을 사용하고 있는 경우,OPTIMIZE 커멘드는 바이너리 로그에 기록되지 않습니다.MySQL 4.1.1 이?~ (을)를 사용하고 있는 경우는, 옵션의 NO_WRITE_TO_BINLOG 키워드(또는 그 앨리어스(alias)의 LOCAL )(을)를 사용하고 있지 않는 한, 바이너리 로그에 기록됩니다.

4.6.2. ANALYZE TABLE 구문

ANALYZE [LOCAL | NO_WRITE_TO_BINLOG] TABLE tbl_name[,tbl_name...]

테이블의 키 분포를 분석해 보존합니다.분석중, 테이블은 읽어내 락 됩니다.이 커멘드는,MyISAM 테이블과 BDB 테이블에 대해서 사용할 수 있습니다.

이것은, 테이블에 대해서 myisamchk -a (을)를 실행하는 것과 같습니다.

정수를 조건으로 하지 않는 결합을 실행하는 경우,MySQL (은)는 보존된 키 분포를 사용하고, 테이블의 결합 순서를 결정합니다.

이 커멘드는, 이하의 컬럼으로 구성되는 테이블을 돌려줍니다.

컬럼 | 치
Table | 테이블명
Op | 항상 analyze
Msg_type | status ,error ,info ,warning 의 언젠가
Msg_text | 메세지

보존된 키 분포를 체크하려면 ,SHOW INDEX 커멘드를 사용합니다. See 항4.6.8.1. 「데이타베이스, 테이블, 컬럼, 및 인덱스에 관한 정보의 취득」 .

전회의 ANALYZE TABLE 커멘드를 실행한 다음에 테이블이 변경되어 있지 않은 경우, 테이블에 대해서 재차 분석은 실행되지 않습니다.

MySQL 4.1.1 보다 전의 버젼을 사용하고 있는 경우,ANALYZE 커멘드는 바이너리 로그에 기록되지 않습니다.MySQL 4.1.1 이?~ (을)를 사용하고 있는 경우는, 옵션의 NO_WRITE_TO_BINLOG 키워드(또는 그 앨리어스(alias)의 LOCAL )(을)를 사용하고 있지 않는 한, 바이너리 로그에 기록됩니다.

4.6.3. CHECKSUM TABLE 구문

CHECKSUM TABLE tbl_name[,tbl_name ...] [ QUICK | EXTENDED ]

테이블의 체크 섬을 보고합니다.QUICK (을)를 지정했을 경우, 현시점의 테이블의 체크 섬이 보고됩니다.또는, 테이블이 체크 섬을 서포트하고 있지 않는 경우는 NULL 하지만 돌려주어집니다.이 처리 시간은 매우 짧아서 끝납니다.EXTENDED 모드에서는, 테이블 전체가 레코드 마다 읽어내져 체크 섬이 계산됩니다.큰 테이블의 경우는 시간이 걸립니다.디폴트에서는(QUICK 그렇지만 EXTENDED 도 아닌 경우), 테이블이 체크 섬을 서포트하고 있으면, 현시점의 체크 섬이 돌려주어져 서포트하고 있지 않으면, 테이블이 스캔 됩니다.

이 커멘드는,MySQL 4.1.1 그리고 도입되었습니다.

4.6.4. FLUSH 구문

FLUSH [LOCAL | NO_WRITE_TO_BINLOG] flush_option [,flush_option] ...

MySQL 하지만 사용하고 있는 내장형 캐쉬를 소거하려면 ,FLUSH 커멘드를 사용합니다.FLUSH (을)를 실행하려면 ,RELOAD 권한이 필요합니다.

flush_option 에는, 이하의 어느쪽이든을 지정할 수 있습니다.

옵션 | 설명
HOSTS | 호스트 캐쉬 테이블을 비운다.호스트가 IP 주소를 변경했을 경우나, 에러 메세지 Host ... is blocked 하지만 표시되는 경우에는, 호스트 테이블을 플래시 하는 것이 필요하다.MySQL 서버와의 접속중에, 특정의 호스트의 1 개의 레코드로 max_connect_errors (을)를 넘는 에러가 발생했을 경우,MySQL (은)는 문제가 있다고 판단해, 이후, 호스트로부터의 접속 요구를 블록 한다. 호스트 테이블을 플래시 하면, 호스트가 다시 접속 가능하게 된다.See 항A.2.5. 「Host '...' is blocked 에러」 . mysqld (을)를 -O max_connect_errors=999999999 그리고 기동하면, 이 에러를 회피할 수 있다.
DES_KEY_FILE | 서버 기동시에 --des-key-file 옵션으로 지정된 파일로부터,DES 키를 재차 읽어들인다.
LOGS | 모든 로그 파일을 닫고, 다시 연다. 갱신 로그 파일 또는 바이너리 로그 파일을 확장자(extension) 없이 지정해 있는 경우, 로그 파일의 확장자(extension) 번호는 전의 파일에 1 (을)를 가산한 수가 된다.파일명에 확장자(extension)를 사용하고 있는 경우,MySQL (은)는 갱신 로그 파일을 닫고, 다시 연다. See 항4.10.3. 「갱신 로그」 . 이것은,SIGHUP 시그널을 mysqld 서버에 송신하는 것과 같다.
PRIVILEGES | mysql 데이타베이스의 권한 테이블에서 권한을 재독 봐.
QUERY CACHE | 쿼리 캐쉬를 최적화해, 메모리의 사용 효율을 높인다.이 커멘드는 RESET QUERY CACHE 과는 달리, 캐쉬로부터 쿼리를 삭제하지 않는다.
TABLES | 열려 있는 테이블을 모두 닫는다.사용중의 테이블도 강제적으로 닫는다.이것에 의해, 쿼리 캐쉬도 플래시 된다.
[TABLE | TABLES] tbl_name [,tbl_name...] | 지정한 테이블만을 플래시 한다.
TABLES WITH READ LOCK | 열려 있는 테이블을 모두 닫아 모든 데이타베이스의 전테이블을 읽어내 잠근다.이 락은 UNLOCK TABLES (을)를 실행할 때까지 해제되지 않는다.적당 snapshot를 취할 수 있다 Veritas 등의 파일 시스템을 사용하고 있는 경우에는, 이 커멘드가 백업의 작성에 매우 편리하다.
STATUS | 대부분의 스테이터스 변수를 0 에 리셋트 한다.이것은, 쿼리를 디버그 할 경우에 마셔 사용한다.
USER_RESOURCES | 모든 유저 자원을 0 에 리셋트 한다.이것에 의해, 블록 되고 있던 유저도 재차 로그인 가능하게 된다. See 항4.4.7. 「유저 자원의 제한」 .

MySQL 4.1.1 보다 전의 버젼을 사용하고 있는 경우,FLUSH 커멘드는 바이너리 로그에 기록되지 않습니다.MySQL 4.1.1 이?~ 의 버젼을 사용하고 있는 경우에는, 옵션의 NO_WRITE_TO_BINLOG 키워드(또는 그 앨리어스(alias)의 LOCAL )(을)를 사용하고 있지 않는 한, 바이너리 로그에 기록됩니다.또, 이 커멘드에 LOGS ,MASTER ,SLAVE ,TABLES WITH READ LOCK 의 몇개의 인수가 포함되는 경우도, 바이너리 로그에 기록되지 않습니다.이러한 인수는 슬레이브에 레프리케이트 되면 문제가 발생할 가능성이 있습니다.

상기 커멘드 중 몇개인가에는,mysqladmin 유틸리티로 flush-hosts ,flush-logs ,flush-privileges , flush-status ,flush-tables 의 각 커멘드를 사용해 액세스 할 수도 있습니다.

replication로 사용한다 RESET 커멘드도 참조해 주세요. See 항4.6.5. 「RESET 구문」 .

4.6.5. RESET 구문

RESET reset_option [,reset_option] ...

RESET 커멘드는 설정을 리셋트 합니다.FLUSH 커멘드의 것보다 강력한 버젼이라고 해도 기능합니다. See 항4.6.4. 「FLUSH 구문」 .

RESET (을)를 실행하려면 ,RELOAD 권한이 필요합니다.

옵션 | 설명
MASTER | 인덱스 파일내의 모든 바이너리 로그를 삭제해, 바이너리 로그인 덱스 파일을 공백에 리셋트 한다.이것은, 이전의 FLUSH MASTER . See 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 .
SLAVE | 슬레이브로부터, 마스터 바이너리 로그내의 자신의 replication 위치를 소거한다.이것은, 이전의 FLUSH SLAVE . See 항4.11.8. 「슬레이브 서버를 제어한다 SQL 스테이트먼트」 .
QUERY CACHE | 쿼리 캐쉬로부터 모든 쿼리 결과를 삭제한다.

4.6.6. PURGE MASTER LOGS 구문

PURGE {MASTER|BINARY} LOGS TO binlog_name
PURGE {MASTER|BINARY} LOGS BEFORE date

이 커멘드는, 지정한 바이너리 로그 또는 지정일보다 전의 바이너리 로그를 모두 삭제하는 경우에 사용합니다. See 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 .

PURGE MASTER LOGS 의 동의어로서 PURGE BINARY LOGS 하지만 MySQL 4.1.1 (으)로부터 이용 가능하게 되어 있습니다.

4.6.7. KILL 구문

KILL thread_id

mysqld 의 각 접속은 스레드 마다 행해집니다.SHOW PROCESSLIST 커멘드로, 어느 스레드가 사용되고 있을까 알 수 있습니다.또,KILL thread_id 커멘드로, 스레드를 강제 종료할 수 있습니다.

PROCESS 권한이 있으면, 모든 스레드를 조회할 수 있습니다. SUPER 권한이 있으면, 모든 스레드를 강제 종료할 수 있습니다. 상기의 권한이 없는 경우는, 자신의 스레드만 조회 및 강제 종료할 수 있습니다.

mysqladmin processlist 커멘드 및 mysqladmin kill 커멘드에서도, 스레드를 확인 및 강제 종료할 수 있습니다.

주의: 현재로서는, 편입 MySQL 서버 라이브러리에서는 KILL (을)를 사용할 수 없습니다.편입 서버는, 호스트 어플리케이션의 스레드 내부에서 실행하는 것만으로, 독자적인 접속 스레드는 작성하지 않습니다.

KILL (을)를 실행하면, 스레드 고유의 kill flag 하지만 스레드로 설정됩니다.

키르후라그는 일정 간격으로 체크되기 위해, 많은 경우, 스레드가 종료하기까지 당분간 시간이 걸립니다.

  • SELECT ,ORDER BY ,GROUP BY 의 각 루프에서는, 레코드의 블록이 1 개 읽어내질 때마다 플래그가 체크됩니다.키르후라그가 설정되어 있으면, 스테이트먼트는 정?~ 합니다.

  • ALTER TABLE (을)를 실행했을 경우, 오리지날의 테이블에서 레코드의 각 블록이 읽어내지기 전에, 키르후라그가 체크됩니다.키르후라그가 설정되어 있으면 커멘드는 정?~ 해, 텐포라리테이불은 삭제됩니다.

  • UPDATE 또는 DELETE (을)를 실행했을 경우, 각 블록이 읽어내진 후, 및 갱신 레코드 또는 삭제 레코드의 다음에, 키르후라그가 체크됩니다.키르후라그가 설정되어 있으면, 스테이트먼트는 정?~ 합니다.주의: 트랜잭션(transaction)를 사용하고 있지 않는 경우, 변경은 롤백(rollback) 되지 않습니다.

  • GET_LOCK() 하 NULL 그리고 정?~ 합니다.

  • INSERT DELAYED 스레드는, 그 메모리에 있는 모든 레코드를 재빠르게 플래시 해, 종료합니다.

  • 스레드가 테이블 락 핸들러내에 있는 경우(Locked 상태), 테이블 락이 재빠르게 해제됩니다.

  • 스레드가 write 콜로 비어 디스크 용량을 기다리고 있는 경우,disk full 의 에러 메세지로 기입이 정?~ 합니다.

4.6.8. SHOW 구문

   SHOW DATABASES [LIKE wild]

인가 SHOW [OPEN] TABLES [FROM db_name] [LIKE wild]

인가 SHOW [FULL] COLUMNS FROM tbl_name [FROM db_name] [LIKE wild]

인가 SHOW INDEX FROM tbl_name [FROM db_name]

인가 SHOW TABLE STATUS [FROM db_name] [LIKE wild]

인가 SHOW STATUS [LIKE wild]

인가 SHOW VARIABLES [LIKE wild]

인가 SHOW [BDB] LOGS

인가 SHOW [FULL] PROCESSLIST

인가 SHOW GRANTS FOR user

인가 SHOW CREATE TABLE table_name

인가 SHOW MASTER STATUS

인가 SHOW MASTER LOGS

인가 SHOW SLAVE STATUS

인가 SHOW WARNINGS [LIMIT row_count]

인가 SHOW ERRORS [LIMIT row_count]

인가 SHOW TABLE TYPES

SHOW (을)를 실행하면, 데이타베이스 정보, 테이블 정보, 컬럼 정보, 또는 서버의 스테이터스 정보가 제공됩니다.LIKE wild (을)를 사용했을 경우,wild 문자열내에 SQL 의 ‘% ＇ 및 ‘_ ＇ 의 와일드 카드 문자를 사용할 수 있습니다.

4.6.8.1. 데이타베이스, 테이블, 컬럼, 및 인덱스에 관한 정보의 취득

tbl_name FROM db_name 구문 대신에 db_name.tbl_name (을)를 사용할 수도 있습니다.이하의 2 개의 스테이트먼트는 같습니다.

mysql> SHOW INDEX FROM mytable FROM mydb;
mysql> SHOW INDEX FROM mydb.mytable;

SHOW DATABASES (은)는,MySQL 서버 호스트상의 데이타베이스를 일람표 나타내 보입니다. mysqlshow 커멘드 라인 툴을 사용해도, 이 일람을 취득할 수 있습니다. 버젼 4.0.2 그럼, 유저에게 글로벌 SHOW DATABASES 권한이 없는 경우, 그 유저가 어떠한 권한을 가지는 데이타베이스만 표시됩니다.

SHOW TABLES (은)는, 지정한 데이타베이스의 테이블을 일람표 나타내 보입니다.mysqlshow db_name 커멘드를 사용해도, 이 일람을 취득할 수 있습니다.

주의: 유저에게 테이블에 대한 권한이 아무것도 없는 경우,SHOW TABLES 및 mysqlshow db_name 의 출력에 그 테이블은 포함되지 않습니다.

SHOW OPEN TABLES (은)는, 테이블 캐쉬로 현재 열려 있는 테이블을 일람표 나타내 보입니다.See 항5.4.7. 「MySQL (으)로의 테이블의 오픈과 클로우즈의 방법」 . Comment 필드는, 테이블이 몇회 캐시어 되어 , 사용 되었는지를 나타냅니다.

SHOW COLUMNS (은)는, 지정한 테이블의 컬럼을 일람표 나타내 보입니다.FULL 옵션을 지정했을 경우, 유저가 각 컬럼에 가지는 권한도 표시됩니다.컬럼 정보로 나타나는 컬럼의 형태는,CREATE TABLE 스테이트먼트로 지정한 것과 다르고 있는 경우가 있습니다.이것은, 컬럼의 형태가 MySQL 에 의해서 자동적으로 변경되는 것이 있기 때문에입니다. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 . MySQL 4.1 (으)로부터,FULL 키워드에 의해, 컬럼별 코멘트도 표시되게 되었습니다.

DESCRIBE 스테이트먼트에서도 SHOW COLUMNS (와)과 같은 정보가 출력됩니다. See 항6.6.2. 「DESCRIBE 구문(컬럼에 관한 정보의 취득)」 .

SHOW FIELDS 하 SHOW COLUMNS 의 동의어로,SHOW KEYS 하 SHOW INDEX 의 동의어입니다.mysqlshow db_name tbl_name 및 mysqlshow -k db_name tbl_name 그렇지만, 테이블의 컬럼 또는 인덱스를 일람표시 할 수 있습니다.

SHOW INDEX (은)는,ODBC (으)로의 SQLStatistics 호출과 잘 닮은 형식에서 인덱스 정보를 돌려줍니다.이하의 컬럼이 돌려주어집니다.

컬럼 | 의미
Table | 테이블명.
Non_unique | 인덱스에 중복이 용서되지 않는 경우는 0 , 용서되는 경우에는 1 .
Key_name | 인덱스명.
Seq_in_index | 인덱스의 컬럼 순서 번호.1 (으)로부터 시작된다.
Column_name | 컬럼명.
Collation | 인덱스로의 컬럼의 소트 방법. MySQL 그럼 이것은 ‘A ＇(승순) 또는 NULL (소트 하지 않는다)(이)가 된다.
Cardinality | 인덱스내의 독특한 값의 수. 이것은,isamchk -a 의 실행에 의해서 갱신된다.
Sub_part | 컬럼이 부분적으로 인덱스가 되어 있는 경우는, 인덱스가 되어 있는 문자수. 키 전체가 인덱스가 되어 있는 경우는 NULL .
Null | 컬럼에 NULL (을)를 포함할 수 있으면 'YES' .
Index_type | 사용되는 인덱스 방식.
Comment | 다양한 코멘트.현재로서는,MySQL 4.0.2 보다 전의 버젼에서는, 인덱스가 FULLTEXT 지 아닌지를 표시.

주의: Cardinality (은)는 정수로 보존된 통계 정보에 근거해 카운트 되기 위해, 작은 테이블에 대해서는 정확하다라고 한정하지 않습니다.

Null 컬럼 및 Index_type 컬럼은 MySQL 4.0.2 그리고 추가되었습니다.

4.6.8.2. SHOW TABLE STATUS

SHOW TABLE STATUS [FROM db_name] [LIKE wild]

SHOW TABLE STATUS (버젼 3.23 그리고 도입)은 SHOW STATUS (와)과 닮은 기능을 합니다만, 각 테이블에 관한 많은 정보를 제공합니다.mysqlshow --status db_name 커멘드를 사용해도, 이 일람을 취득할 수 있습니다. 이하의 컬럼이 돌려주어집니다.

컬럼 | 의미
Name | 테이블명.
Type | 테이블형. See 장 7. MySQL 의 테이블형 .
Row_format | 레코드의 보존 형식(Fixed ,Dynamic , 또는 Compressed ).
Rows | 레코드의 수.
Avg_row_length | 레코드의 평균장.
Data_length | 데이터 파일의 길이.
Max_data_length | 데이터 파일의 최대장. 고정 레코드 형식에서는, 테이블의 레코드의 최대수가 된다. 동적 레코드 형식에서는, 테이블에 보존할 수 있는 데이터 바이트수의 합계(데이터 포인터 사이즈의 사용이 전제).
Index_length | 인덱스 파일의 크기.
Data_free | 할당할 수 있고 있지만 미사용의 아르바이트수.
Auto_increment | 다음의 자동 인크리먼트(increment)치.
Create_time | 테이블 작성 시각.
Update_time | 전회의 데이터 파일 갱신 시각.
Check_time | 전회의 테이블 체크 시각.
Collation | 테이블의 캐릭터 세트와 조합 순서(4.1.1 그리고 도입).
Checksum | 체크 섬치(있는 경우)(4.1.1 그리고 도입).
Create_options | CREATE TABLE 그리고 사용되는 확장 옵션.
Comment | 테이블 작성시의 코멘트(또는 MySQL 하지만 테이블 정보로 액세스 할 수 없는 이유).

InnoDB 테이블에서는, 테이블 코멘트에 테이블의 빈영역이 보고됩니다.

4.6.8.3. SHOW STATUS

SHOW STATUS (은)는, 서버의 스테이터스 정보를 제공합니다(mysqladmin extended-status (와)과 같이).출력은 이하와 같이 됩니다(형식과 수치는 경우에 따라서 다릅니다).

+--------------------------+------------+
| Variable_name            | Value      |
+--------------------------+------------+
| Aborted_clients          | 0          |
| Aborted_connects         | 0          |
| Bytes_received           | 155372598  |
| Bytes_sent               | 1176560426 |
| Connections              | 30023      |
| Created_tmp_disk_tables  | 0          |
| Created_tmp_tables       | 8340       |
| Created_tmp_files        | 60         |
| Delayed_insert_threads   | 0          |
| Delayed_writes           | 0          |
| Delayed_errors           | 0          |
| Flush_commands           | 1          |
| Handler_delete           | 462604     |
| Handler_read_first       | 105881     |
| Handler_read_key         | 27820558   |
| Handler_read_next        | 390681754  |
| Handler_read_prev        | 6022500    |
| Handler_read_rnd         | 30546748   |
| Handler_read_rnd_next    | 246216530  |
| Handler_update           | 16945404   |
| Handler_write            | 60356676   |
| Key_blocks_used          | 14955      |
| Key_read_requests        | 96854827   |
| Key_reads                | 162040     |
| Key_write_requests       | 7589728    |
| Key_writes               | 3813196    |
| Max_used_connections     | 0          |
| Not_flushed_key_blocks   | 0          |
| Not_flushed_delayed_rows | 0          |
| Open_tables              | 1          |
| Open_files               | 2          |
| Open_streams             | 0          |
| Opened_tables            | 44600      |
| Questions                | 2026873    |
| Select_full_join         | 0          |
| Select_full_range_join   | 0          |
| Select_range             | 99646      |
| Select_range_check       | 0          |
| Select_scan              | 30802      |
| Slave_running            | OFF        |
| Slave_open_temp_tables   | 0          |
| Slow_launch_threads      | 0          |
| Slow_queries             | 0          |
| Sort_merge_passes        | 30         |
| Sort_range               | 500        |
| Sort_rows                | 30296250   |
| Sort_scan                | 4650       |
| Table_locks_immediate    | 1920382    |
| Table_locks_waited       | 0          |
| Threads_cached           | 0          |
| Threads_created          | 30022      |
| Threads_connected        | 1          |
| Threads_running          | 1          |
| Uptime                   | 80380      |
+--------------------------+------------+

상기의 스테이터스 변수에는 각각 이하와 같은 의미가 있습니다.

변수 | 의미
Aborted_clients | 접속을 닫기 전에 클라이언트가 종료해 버렸기 때문에 중단된 접속수. See 항A.2.10. 「통신 에러/Aborted connection 」 .
Aborted_connects | MySQL 서버에의 접속 시행 실패 회수. See 항A.2.10. 「통신 에러/Aborted connection 」 .
Bytes_received | 모든 클라이언트로부터 수신한 아르바이트수.
Bytes_sent | 모든 클라이언트에 송신된 아르바이트수.
Com_xxx | 각 xxx 커멘드의 실행 회수.
Connections | MySQL 서버에의 접속 시행 회수.
Created_tmp_disk_tables | 스테이트먼트 실행중에, 디스크상에 작성된 암묵적 텐포라리테이불의 수.
Created_tmp_tables | 스테이트먼트 실행중에, 메모리상에 작성된 암묵적 텐포라리테이불의 수.
Created_tmp_files | mysqld 하지만 작성한 임시 파일의 수.
Delayed_insert_threads | INSERT DELAYED 한드라스레드의 수.
Delayed_writes | INSERT DELAYED 그리고 써진 레코드의 수.
Delayed_errors | 에러 발생( 중복 키 의 가능성이 높다)에 의해,INSERT DELAYED 그리고 써진 레코드의 수.
Flush_commands | FLUSH 커멘드의 실행 회수.
Handler_commit | 내부 COMMIT 커멘드수.
Handler_delete | 테이블에서 레코드가 삭제된 회수.
Handler_read_first | 최초의 엔트리가 인덱스로부터 읽어내진 회수. 이 값이 큰 경우, 서버가 몇번이나 풀 인덱스 스캔을 실행하고 있다고 생각할 수 있다.예를 들어,SELECT col1 FROM foo (을)를 실행했을 때에 col1 하지만 인덱스가 되어 있으면 그렇게 된다.
Handler_read_key | 키에 근거하는 레코드 독해 요구의 회수.이 값이 큰 경우, 쿼리 및 테이블이 적절히 인덱스화 되고 있다고 생각할 수 있다.
Handler_read_next | 키 순서로의 다음의 레코드의 독해 요구의 회수.범위 지정을 해 인덱스 컬럼에 대해서 쿼리를 실행하면, 이것이 인크리먼트(increment) 된다.인덱스 스캔을 실행해도 인크리먼트(increment) 된다.
Handler_read_prev | 키 순서로의 전의 레코드의 독해 요구의 회수.이것은 주로,ORDER BY ... DESC (을)를 최적화하는데 사용된다.
Handler_read_rnd | 고정 위치에 근거하는 레코드 독해 요구의 회수. 결과의 소트를 필요로 하는 쿼리를 많이 실행하면, 이 값이 커진다.
Handler_read_rnd_next | 데이터 파일로의 다음의 레코드의 독해 요구의 회수. 테이블 스캔이 많이 실행되면, 이 값이 커진다.이 경우, 일반적으로, 테이블이 적절히 인덱스화 되어 있지 않은지, 쿼리가 인덱스를 유효하게 이용하고 있지 않는가를 의미한다.
Handler_rollback | 내부 ROLLBACK 커멘드수.
Handler_update | 테이블내의 레코드의 갱신 요구 회수.
Handler_write | 테이블에의 레코드의 삽입 요구 회수.
Key_blocks_used | 키 캐쉬의 사용 블록수.
Key_read_requests | 캐쉬로부터의 키 블록 독해 요구 회수.
Key_reads | 디스크로부터의 키 블록의 물리적 독해 회수.
Key_write_requests | 캐쉬에의 키 블록의 기입 요구 회수.
Key_writes | 디스크에의 키 블록의 물리적 기입 회수.
Max_used_connections | 동시 사용 가능한 최대 접속수.
Not_flushed_key_blocks | 변경되었지만, 디스크에의 플래시는 아직 되어 있지 않은 키 캐쉬의 키 블록.
Not_flushed_delayed_rows | INSERT DELAY 큐로 기입을 기다리고 있는 레코드의 수.
Open_tables | 열려 있는 테이블의 수.
Open_files | 열려 있는 파일의 수.
Open_streams | 열려 있는 스트림의 수(주로 로그용으로 사용).
Opened_tables | 열린 테이블의 수.
Rpl_status | fail-safe인 replication의 스테이터스( 아직 사용되어 있지 않다).
Select_full_join | 키를 사용하지 않는 결합의 수(이 값이 0 (이)가 아닌 경우, 테이블의 인덱스를 체크할 필요가 있다).
Select_full_range_join | 참조 테이블로 범위 지정의 검색을 사용한 결합의 수.
Select_range | 최초의 테이블의 범위 지정된 부분만을 사용한 결합의 수(통상, 이 값이 커도 문제는 되지 않는다).
Select_scan | 최초의 테이블로 풀 스캔을 실시한 결합의 수.
Select_range_check | 각 레코드의 다음에 키 사용을 체크하는, 키를 사용하지 않는 결합의 수(이 값이 0 (이)가 아닌 경우, 테이블의 인덱스를 체크할 필요가 있다).
Questions | 서버에 송신된 쿼리의 수.
Slave_open_temp_tables | 스레이브스레드에 의해서 현재 열리고 있는 텐포라리테이불의 수.
Slave_running | 마스터에 접속되고 있는 슬레이브의 경우는 ON .
Slow_launch_threads | 생성에 slow_launch_time 보다 시간이 걸린 스레드의 수.
Slow_queries | long_query_time 초부터 시간이 걸린 쿼리의 수. See 항4.10.5. 「슬로우 쿼리 로그」 .
Sort_merge_passes | 소트 알고리즘으로 필요했던 머지 패스의 회수.이 값이 크면,sort_buffer 의 값을 크게 하는 것을 고려해야 한다.
Sort_range | 범위 지정으로 행해진 소트의 회수.
Sort_rows | 소트 된 레코드의 수.
Sort_scan | 테이블의 스캔에 의해서 실행된 소트의 회수.
ssl_xxx | SSL 에 의해서 사용되는 변수( 아직 도입되어 있지 않다).
Table_locks_immediate | 테이블 락이 곧바로 실행된 회수.3.23.33 그리고 도입.
Table_locks_waited | 테이블 락이 빨리는 실행되지 않고, 대기가 필요했던 회수.이 값이 큰 경우, 퍼포먼스상의 문제가 있다.우선 쿼리를 최적화해, 다음에 테이블을 분할할까 replication를 사용해야 한다.3.23.33 그리고 도입.
Threads_cached | 스레드캐슈내의 스레드수.
Threads_connected | 현재 열려 있는 접속의 수.
Threads_created | 접속을 처리하기 위해서 작성된 스레드의 수.
Threads_running | sleeve 상태로 되어 있지 않은 스레드의 수.
Uptime | 서버의 가동초수.

보충 코멘트

  • Opened_tables 값이 큰 경우,table_cache 변수가 너무 작다고 생각할 수 있다.

  • Key_reads 값이 큰 경우,key_buffer_size 변수가 너무 작다고 생각할 수 있다. 캐쉬?~ 슬레이트 (은)는,Key_reads/Key_read_requests 그리고 계산된다.

  • Handler_read_rnd 값이 큰 경우,MySQL 하지만 테이블 전체를 스캔 할 필요가 있는 쿼리가 너무 많은지, 키를 적절히 사용하지 않는 결합이 있다고 생각할 수 있다.

  • Threads_created 값이 큰 경우,thread_cache_size 변수를 크게 하는 것을 고려해야 한다.캐쉬 히트 레이트는,Threads_created/Connections 그리고 계산된다.

  • Created_tmp_disk_tables 값이 큰 경우,tmp_table_size 변수를 크게 하고, 디스크 베이스는 아니고 메모리베이스로 텐포라리테이불을 취득할 수 있도록 한다.

4.6.8.4. SHOW VARIABLES

SHOW [GLOBAL | SESSION] VARIABLES [LIKE wild]

SHOW VARIABLES (은)는,MySQL 시스템 변수의 값을 표시합니다. GLOBAL 옵션 및 SESSION 옵션은 MySQL 4.0.3 그리고 추가되었습니다. GLOBAL 그럼,MySQL 의 신규 접속에 사용되는 변수를 얻을 수 있습니다.SESSION 그럼, 현재의 접속에 유효한 값을 얻을 수 있습니다.옵션을 특히 지정하지 않으면,SESSION 하지만 사용됩니다.

디폴트치가 적당하지 않은 경우에는,mysqld 기동시에 커멘드 라인 옵션을 사용하고, 이러한 변수의 대부분을 변경할 수 있습니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 . SET 스테이트먼트로부터에서도, 대부분의 변수를 변경할 수 있습니다. See 항5.5.6. 「SET 구문」 .

SHOW VARIABLES 의 출력은 이하와 같이 됩니다(형식과 수치는 경우에 따라서 다릅니다). mysqladmin variables 커멘드를 사용해도 같은 정보를 취득할 수 있습니다.

+---------------------------------+------------------------------+
| Variable_name                   | Value                        |
+---------------------------------+------------------------------|
| back_log                        | 50                           |
| basedir                         | /usr/local/mysql             |
| bdb_cache_size                  | 8388572                      |
| bdb_log_buffer_size             | 32768                        |
| bdb_home                        | /usr/local/mysql             |
| bdb_max_lock                    | 10000                        |
| bdb_logdir                      |                              |
| bdb_shared_data                 | OFF                          |
| bdb_tmpdir                      | /tmp/                        |
| bdb_version                     | Sleepycat Software: ...      |
| binlog_cache_size               | 32768                        |
| bulk_insert_buffer_size         | 8388608                      |
| character_set                   | latin1                       |
| character_sets                  | latin1 big5 czech euc_kr     |
| concurrent_insert               | ON                           |
| connect_timeout                 | 5                            |
| convert_character_set           |                              |
| datadir                         | /usr/local/mysql/data/       |
| delay_key_write                 | ON                           |
| delayed_insert_limit            | 100                          |
| delayed_insert_timeout          | 300                          |
| delayed_queue_size              | 1000                         |
| flush                           | OFF                          |
| flush_time                      | 0                            |
| ft_boolean_syntax               | + -><()~*:""&|               |
| ft_min_word_len                 | 4                            |
| ft_max_word_len                 | 84                           |
| ft_query_expansion_limit        | 20                           |
| ft_stopword_file                | (built-in)                   |
| have_bdb                        | YES                          |
| have_innodb                     | YES                          |
| have_isam                       | YES                          |
| have_raid                       | NO                           |
| have_symlink                    | DISABLED                     |
| have_openssl                    | YES                          |
| have_query_cache                | YES                          |
| init_file                       |                              |
| innodb_additional_mem_pool_size | 1048576                      |
| innodb_buffer_pool_size         | 8388608                      |
| innodb_data_file_path           | ibdata1:10M:autoextend       |
| innodb_data_home_dir            |                              |
| innodb_file_io_threads          | 4                            |
| innodb_force_recovery           | 0                            |
| innodb_thread_concurrency       | 8                            |
| innodb_flush_log_at_trx_commit  | 1                            |
| innodb_fast_shutdown            | ON                           |
| innodb_flush_method             |                              |
| innodb_lock_wait_timeout        | 50                           |
| innodb_log_arch_dir             |                              |
| innodb_log_archive              | OFF                          |
| innodb_log_buffer_size          | 1048576                      |
| innodb_log_file_size            | 5242880                      |
| innodb_log_files_in_group       | 2                            |
| innodb_log_group_home_dir       | ./                           |
| innodb_mirrored_log_groups      | 1                            |
| interactive_timeout             | 28800                        |
| join_buffer_size                | 131072                       |
| key_buffer_size                 | 16773120                     |
| language                        | /usr/local/mysql/share/...   |
| large_files_support             | ON                           |
| local_infile                    | ON                           |
| locked_in_memory                | OFF                          |
| log                             | OFF                          |
| log_update                      | OFF                          |
| log_bin                         | OFF                          |
| log_slave_updates               | OFF                          |
| log_slow_queries                | OFF                          |
| log_warnings                    | OFF                          |
| long_query_time                 | 10                           |
| low_priority_updates            | OFF                          |
| lower_case_table_names          | OFF                          |
| max_allowed_packet              | 1047552                      |
| max_binlog_cache_size           | 4294967295                   |
| max_binlog_size                 | 1073741824                   |
| max_connections                 | 100                          |
| max_connect_errors              | 10                           |
| max_delayed_threads             | 20                           |
| max_heap_table_size             | 16777216                     |
| max_join_size                   | 4294967295                   |
| max_relay_log_size              | 0                            |
| max_sort_length                 | 1024                         |
| max_user_connections            | 0                            |
| max_tmp_tables                  | 32                           |
| max_write_lock_count            | 4294967295                   |
| myisam_max_extra_sort_file_size | 268435456                    |
| myisam_repair_threads           | 1                            |
| myisam_max_sort_file_size       | 2147483647                   |
| myisam_recover_options          | force                        |
| myisam_sort_buffer_size         | 8388608                      |
| net_buffer_length               | 16384                        |
| net_read_timeout                | 30                           |
| net_retry_count                 | 10                           |
| net_write_timeout               | 60                           |
| open_files_limit                | 1024                         |
| pid_file                        | /usr/local/mysql/name.pid    |
| port                            | 3306                         |
| protocol_version                | 10                           |
| query_cache_limit               | 1048576                      |
| query_cache_size                | 0                            |
| query_cache_type                | ON                           |
| read_buffer_size                | 131072                       |
| read_rnd_buffer_size            | 262144                       |
| rpl_recovery_rank               | 0                            |
| safe_show_database              | OFF                          |
| server_id                       | 0                            |
| slave_net_timeout               | 3600                         |
| skip_external_locking           | ON                           |
| skip_networking                 | OFF                          |
| skip_show_database              | OFF                          |
| slow_launch_time                | 2                            |
| socket                          | /tmp/mysql.sock              |
| sort_buffer_size                | 2097116                      |
| sql_mode                        |                              |
| table_cache                     | 64                           |
| table_type                      | MYISAM                       |
| thread_cache_size               | 3                            |
| thread_stack                    | 131072                       |
| tx_isolation                    | READ-COMMITTED               |
| timezone                        | EEST                         |
| tmp_table_size                  | 33554432                     |
| tmpdir                          | /tmp/:/mnt/hd2/tmp/          |
| version                         | 4.0.4-beta                   |
| wait_timeout                    | 28800                        |
+---------------------------------+------------------------------+

이하, 각 옵션에 대해 설명합니다.

버퍼 사이즈, 길이, 및 스택 사이즈의 값은 아르바이트 단위입니다. ‘K ＇ 또는 ‘M ＇ 의 사픽스를 값에 매기면, 각각 킬로바이트,메가바이트를 나타냅니다.예를 들어,16M 하 16 메가바이트입니다.사픽스의 대문자와 소문자는 구별되지 않습니다.16M (와)과 16m (은)는 같습니다.

  • ansi_mode . mysqld 하지만 --ansi 옵션으로 기동하고 있는 경우는 ON . See 항1.8.2. 「ANSI 모드로의 MySQL 의 실행」 .

  • back_log MySQL 그리고 보관 유지할 수 있는 미해결의 접속 요구수.이것은, 매우 짧은 동안에 메인의 MySQL 스레드에 매우 많은 접속 요구가 집중했을 때에 기능한다.그리고, 메인스레드가 접속을 체크해, 신규 스레드를 개시하는데 얼마인가의 시간(그저 적지만)이 걸린다.back_log 값은,MySQL 하지만 순간적으로 신규 요구에의 회답을 정?~ 할 때까지의 이 단시간에, 스택 가능한 요구의 수를 나타낸다.단시간에 많은 접속 요구가 예상되는 경우만, 이 값을 크게 할 필요가 있다.

    바꾸어 말하면, 이 값은,TCP/IP 접속의 릿슨큐의 사이즈이다.사용하고 있는 operating system 그 자체에도, 이 큐 사이즈의 제한이 있다.상세한 것에 대하여는,Unix listen(2) 시스템 콜의 메뉴얼 페이지를 참조.이 변수의 최대치에 대해서,OS 의 문서를 참조하는 것이 필요하다.back_log (을)를 operating system의 제한치보다 크게 해도, 효과는 없다.

  • basedir --basedir 옵션의 값.

  • bdb_cache_size BDB 테이블의 인덱스와 레코드를 캐쉬하기 위해서 할당할 수 있었던 버퍼.BDB 테이블을 사용하지 않는 경우,mysqld (을)를 --skip-bdb 옵션으로 기동하고, 이 캐쉬에 메모리를 사용하지 않게 한다.

  • bdb_log_buffer_size BDB 테이블의 인덱스와 레코드를 캐쉬하기 위해서 할당할 수 있었던 버퍼.BDB 테이블을 사용하지 않는 경우, 이 값을 0 (으)로 설정하는지,mysqld (을)를 --skip-bdb 옵션으로 기동하고, 이 캐쉬에 메모리를 사용하지 않게 한다.

  • bdb_home --bdb-home 옵션의 값.

  • bdb_max_lock BDB 테이블로 유효하게 할 수 있는 락의 최대수(디폴트에서는 10,000 ).긴 트랜잭션(transaction)를 실행하고 있을 때나,mysqld 하지만 대량의 레코드를 사용해 쿼리를 실행하고 있을 때,bdb: Lock table is out of available locks 또는 Got error 12 from ... 그렇다고 하는 에러가 발생하는 경우에는, 이 수치를 크게 할 필요가 있다.

  • bdb_logdir --bdb-logdir 옵션의 값.

  • bdb_shared_data --bdb-shared-data (을)를 사용하고 있는 경우는 ON .

  • bdb_tmpdir --bdb-tmpdir 옵션의 값.

  • binlog_cache_size . 트랜잭션(transaction)중에 바이너리 로그에 대한다 SQL 스테이트먼트를 보관 유지하는 캐쉬의 사이즈.큰 멀티 스테이트먼트 트랜잭션(transaction)를 빈번히 사용하는 경우, 이 값을 크고 하는 것으로써 퍼포먼스를 향상할 수 있다. See 항6.7.1. 「START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문」 .

  • bulk_insert_buffer_size (이전에는 myisam_bulk_insert_tree_size ) MyISAM (은)는 특수한 트리상의 캐쉬를 사용하고, 벌크 INSERT (INSERT ... SELECT ,INSERT ... VALUES (...), (...), ... ,LOAD DATA INFILE )(을)를 고속화한다.이 변수에 의해, 스레드마다의 캐쉬 트리의 사이즈가 제한된다(아르바이트 단위).이 값을 0 (으)로 설정하면, 최적화는 무효가 된다. 주의: 이 캐쉬는, 공백이 아닌 테이블에 값을 추가하는 경우에게만 사용된다.디폴트치는 8 메가바이트이다.

  • character_set 디폴트의 캐릭터 세트.

  • character_sets 서포트되는 캐릭터 세트.

  • concurrent_inserts ON 의 경우(디폴트),SELECT 쿼리를 MyISAM 테이블로 실행할 때, 동시에 INSERT 도 실행할 수 있다.이 옵션을 오프로 하려면 ,mysqld (을)를 --safe 또는 --skip-new 그리고 기동한다.

  • connect_timeout mysqld 서버가,Bad handshake (을)를 돌려주기까지 접속 패킷을 기다리는 초수.

  • datadir --datadir 옵션의 값.

  • delay_key_write MyISAM 테이블의 옵션.이하의 몇개의 값을 지정할 수 있다.

    OFF | CREATE TABLE ... DELAYED_KEY_WRITE (은)는 모두 무시된다.
    ON | (디폴트)CREATE TABLE 의 DELAY_KEY_WRITE 옵션이 채용된다.
    ALL | 새롭게 열리는 모든 테이블을,DELAY_KEY_WRITE 옵션으로 작성된 것처럼 취급한다.

    DELAY_KEY_WRITE 하지만 유효의 경우, 이 옵션의 테이블의 키 버퍼는, 인덱스의 갱신 마다는 플래시 되지 않고, 테이블을 닫을 때만 플래시 된다.이것에 의해, 키의 기입은 꽤 빨라지지만, 이것을 사용하는 경우에는,myisamchk --fast --force 에 의해 모든 테이블을 자동적으로 체크해야 한다.

  • delayed_insert_limit delayed_insert_limit 레코드를 삽입 후,INSERT DELAYED 핸들러는, 보류중의 SELECT 스테이트먼트가 없는가 체크한다.어느 경우, 핸들러는 처리를 속행하기 전에 보류중의 스테이트먼트의 실행을 허가한다.

  • delayed_insert_timeout INSERT DELAYED 스레드가 INSERT 스테이트먼트를 대기하는 시간.

  • delayed_queue_size INSERT DELAYED (을)를 처리하기 위해서 할당할 수 있는 큐의 사이즈(레코드 단위).큐가 가득 차면,INSERT DELAYED (을)를 실행하는 모든 클라이언트는, 큐에 빈 곳이 생길 때까지 대기한다.

  • flush MySQL (을)를 --flush 옵션으로 기동했을 경우는 ON .

  • flush_time 이것을 0 이외의 값으로 설정하면,flush_time 초 마다 모든 테이블이 닫혀진다(자원의 해방과 미플래시 데이터의 디스크에의 동기를 위해).Windows 9x/Me , 그 외 자원이 매우 적은 시스템의 경우만, 이 옵션을 추천.

  • ft_boolean_syntax MATCH ... AGAINST(... IN BOOLEAN MODE) 그리고 서포트되고 있는 연산자의 일람. See 항6.8. 「MySQL 풀텍스트 검색」 .

  • ft_min_word_len FULLTEXT 인덱스내의 단어의 최단장. 주의: 이 변수를 변경 후,FULLTEXT 인덱스를 재빌드 할 필요가 있다. 이 옵션은 MySQL 4.0 그리고 도입되었다.

  • ft_max_word_len FULLTEXT 인덱스내의 단어의 최대장. 주의: 이 변수를 변경 후,FULLTEXT 인덱스를 재빌드 할 필요가 있다. 이 옵션은 MySQL 4.0 그리고 도입되었다.

  • ft_query_expansion_limit 쿼리 확장(MATCH ... AGAINST (... WITH QUERY EXPANSION) )(으)로 사용되는 최상위매치수.이 옵션은 MySQL 4.1.1 그리고 도입되었다.

  • ft_stopword_file 풀텍스트 검색의 스톱 워드 리스트가 포함되어 있는 파일.파일내의 모든 스톱 워드가 사용된다.코멘트는 사용 되지 않는다 .디폴트에서는, 스톱 워드의 편입 리스트가 사용된다(myisam/ft_static.c 그리고 정의되고 있는 리스트).이 파라미터를 공백의 문자열("" )(으)로 설정하면, 스톱 워드의 필터링이 무효가 된다. 주의: 이 변수를 변경 후,FULLTEXT 인덱스를 재빌드 할 필요가 있다. 이 옵션은 MySQL 4.0.10 그리고 도입되었다.

  • have_innodb mysqld 하지만 InnoDB 테이블을 서포트하는 경우는 YES .--skip-innodb 하지만 사용되고 있는 경우는 DISABLED .

  • have_bdb mysqld 하지만 Berkeley DB 테이블을 서포트하는 경우는 YES .--skip-bdb 하지만 사용되고 있는 경우는 DISABLED .

  • have_raid mysqld 하지만 RAID 옵션을 서포트하는 경우는 YES .

  • have_openssl mysqld 하지만 클라이언트와 서버간의 프로토콜에 SSL (암호화)(을)를 서포트하는 경우는,YES .

  • init_file 서버의 기동시에 --init-file 옵션으로 지정된 파일의 이름.이것은, 서버의 기동시에, 서버가 실행한다 SQL 스테이트먼트의 파일이다.

  • interactive_timeout 대화식 접속을 종료하기 전에, 서버가 액티버티를 대기하는 초수.대화형 클라이언트는,mysql_real_connect() 그리고 CLIENT_INTERACTIVE 옵션을 사용하는 클라이언트로서 정의된다.wait_timeout 도 참조.

  • join_buffer_size 완전 결합(인덱스를 사용하지 않는 결합)에 사용되는 버퍼의 사이즈.2 개의 테이블간의 완전 결합 마다 버퍼를 할당할 수 있다.인덱스를 추가할 수 없는 경우에, 완전 결합을 빠르게 하는 목적으로 이 값을 크게 한다(통상, 결합을 빠르게 하는 최선의 방법은 인덱스의 추가이다).

  • key_buffer_size 인덱스 블록은 버퍼 되어 모든 스레드에 의해서 공유된다.key_buffer_size (은)는, 인덱스 블록용으로 사용되는 버퍼의 사이즈이다.

    인덱스 처리(모든 독해와 복수 기입)의 퍼포먼스를 향상시키기 위해, 이 값은 가능한 한 크게 한다.주로 MySQL (을)를 실행한다 256M 머신에서는,64M 하지만 일반적이다.다만, 이것을 너무 크게 하면 (예를 들어, 메모리 합계의 50% 이상 등), 시스템이 페이징을 개시해, 처리 속도가 매우 늦어질 가능성이 있다.MySQL 그럼 데이터 독해를 캐쉬하지 않기 때문에,OS 파일 시스템의 캐쉬용으로 영역을 확보해 두는 것이 필요하다.

    키 버퍼의 퍼포먼스를 확인하려면 ,SHOW STATUS (을)를 실행해,Key_read_requests ,Key_reads ,Key_write_requests ,Key_writes 의 각 변수를 조사한다.Key_reads/Key_read_request 의 비율은 통상,0.01 보다 작다.Key_write/Key_write_requests 의 비율은, 조작이 거의 갱신과 삭제만의 경우, 통상은 약 1 (이)가 된다.그러나, 동시에 많은 영향이 있는 갱신을 빈번히 실시하는 경우나,DELAY_KEY_WRITE (을)를 사용하는 경우는 꽤 작아지기도 한다. See 항4.6.8. 「SHOW 구문」 .

    많은 레코드를 동시에 쓰는 경우에 한층 더 속도를 올리려면 ,LOCK TABLES (을)를 사용한다. See 항6.7.5. 「LOCK TABLES 및 UNLOCK TABLES 구문」 .

  • language 에러 메세지에 사용하는 언어.

  • large_file_support mysqld 하지만, 큰 파일을 서포트하는 옵션으로 컴파일 되고 있는 경우.

  • locked_in_memory mysqld 하지만,--memlock 그리고 메모리에 락 되고 있는 경우.

  • log 모든 쿼리의 로그를 유효하게 하고 있는 경우.

  • log_update 갱신 로그를 유효하게 하고 있는 경우.

  • log_bin 바이너리 로그를 유효하게 하고 있는 경우.

  • log_slave_updates 슬레이브로부터의 갱신을 로그에 기록하는 경우.

  • long_query_time 쿼리가 이 값(초단위)보다 시간이 걸리면,Slow_queries 카운터가 인크리먼트(increment) 된다.--log-slow-queries (을)를 사용하고 있는 경우, 쿼리는 슬로우 쿼리 로그 파일에 기록된다.이 값은 실제의 시간이며,CPU 시간은 아니다.따라서, 부하의 가벼운 시스템에서는 해 귀의치보다 아래의 쿼리도, 부하의 무거운 시스템에서는 해 귀의치보다 위가 되는 경우가 있다. See 항4.10.5. 「슬로우 쿼리 로그」 .

  • lower_case_table_names 1 (으)로 설정하면, 테이블명이 소문자로 디스크에 격납되어 테이블명의 비교로 대문자와 소문자가 구별되지 않게 된다.버젼 4.0.2 이?~ , 이 옵션은 데이타베이스명에도 적용되게 되었다.4.1.1 에서는, 테이블 앨리어스(alias)에도 적용되게 되었다. See 항6.1.3. 「이름에 있어서의 케이스 의존」 .

  • max_allowed_packet 1 패킷의 최대 사이즈.메세지 버퍼는 net_buffer_length 아르바이트에 초기화되지만, 필요에 따라서 max_allowed_packet 아르바이트까지 크게 할 수 있다.이 디폴트치는, 큰(아마 부정) 패킷을 받으려면 너무 작다.큰 BLOB 컬럼을 사용하고 있는 경우에는, 이 값을 크게 할 필요가 있다.사용하는 최대의 BLOB (와)과 같은 크기에 해야 한다.max_allowed_packet 의 프로토콜 제한은 MySQL 3.23 그리고 16MB ,MySQL 4.0 그리고 1GB 이다.

  • max_binlog_cache_size 트랜잭션(transaction)로 이것보다 많은 메모리가 필요하게 되면,"Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage" 에러가 발생한다.

  • max_binlog_size 3.23.33 그리고 도입되었다.바이너리(replication) 로그 파일에의 기입이, 이 값을 넘는 경우, 로그를 로테이트 한다.설정 가능치는,4096 아르바이트(MySQL 버젼 4.0.14 보다 전은 1024 )(으)로부터 1 기가바이트.디폴트는 1GB .주의: 트랜잭션(transaction)를 사용하고 있는 경우, 트랜잭션(transaction)는 1 개의 정리로 바이너리 로그에 써지기 위해, 복수의 바이너리 로그에 분할될 것은 없다.따라서, 큰 트랜잭션(transaction)가 있는 경우, 바이너리 로그가 max_binlog_size 보다 커질 가능성이 있다.max_relay_log_size (MySQL 4.0.14 그리고 도입)이 0 의 경우,max_binlog_size 하지만 릴레이 로그에도 적용된다.

  • max_connections 인정되는 동시 클라이언트의 수.이 값을 크게 하면,mysqld 하지만 필요로 하는 파일 기술자의 수가 많아진다.파일 기술자의 제한에 대해서는, 이하를 참조. See 항A.2.6. 「Too many connections 에러」 .

  • max_connect_errors 호스트로부터의 접속중단회수가 이 값보다 커졌을 경우, 그것이?~ , 그 호스트로부터의 접속은 블록 된다.호스트의 블록을 해제하는데는,FLUSH HOSTS 커멘드를 사용한다.

  • max_delayed_threads INSERT DELAYED 스테이트먼트 처리에, 이 수보다 많은 스레드를 개시하지 않는다.모든 INSERT DELAYED 스레드가 사용된 후에 데이터를 신규 테이블에 삽입하려고 하면, 그 레코드는 DELAYED 속성이 지정되어 있지 않은 것으로서 삽입된다.이것을 0 (으)로 설정하면,max_delayed 스레드는 생성되지 않는다.

  • max_heap_table_size 이 변수는, 그것이?~ , 새롭게 생성된다 HEAP 테이블의 최대 사이즈를 설정한다.이 변수의 값을 사용하고,HEAP 테이블의 MAX_ROWS 값이 계산된다.이 변수의 설정은, 기존의 HEAP 테이블에는 영향을 주지 않는다.다만,CREATE TABLE ,TRUNCATE TABLE 등의 스테이트먼트로 재생성하거나ALTER TABLE 그리고 변경했을 경우는 적용된다.

  • max_join_size max_join_size (을)를 넘는 레코드를 읽어내는 결합에서는 에러를 출력한다.WHERE 마디 없이 시간이 걸리는 몇백만의 레코드를 돌려주는 결합을 실행하는 유저가 있는 경우에, 이 값을 설정한다.

  • max_relay_log_size 4.0.14 그리고 도입.릴레이 로그(replication 슬레이브에 의해서 사용되는 로그.see 항4.11.3. 「replication의 실장의 상세」 )에의 기입이 지정치를 넘는 경우, 릴레이 로그를 로테이트 한다.이 변수에 의해, 릴레이 로그와 바이너리 로그에 다른 사이즈의 제약을 더할 수 있다.다만, 이 변수를 0 (으)로 설정하면,max_binlog_size 하지만 바이너리 로그와 릴레이 로그의 양쪽 모두에 적용된다.max_relay_log_size 에는 0 , 또는 4097 이상 1GB 미만의 값을 설정할 수 있다.디폴트치는 0 .

  • max_seeks_for_key 키에 의한 레코드 검색의 최대 회수를 제한한다.MySQL Optimizer는, 키스 왈가닥으로 테이블에서 레코드를 검색할 경우에, 키의 기수에는 관계없이, 키 검색의 회수를 이 지정치까지와 상정한다.이 값을 낮고(100 정도에) 설정하는 것으로써,MySQL (은)는 테이블 스캔은 아니고 키스 왈가닥을 우선적으로 실시하게 된다.

  • max_sort_length BLOB 값 또는 TEXT 값을 소트 할 경우에 사용하는 아르바이트수( 각 치의 최초의 max_sort_length 아르바이트만이 사용되어 나머지는 무시된다).

  • max_user_connections 단일 유저의 액티브 접속의 최대수(0 = 제한 없음).

  • max_tmp_tables 이 옵션은 아직 이용 불가.1 개의 클라이언트가 동시에 열어 둘 수 있는 텐포라리테이불의 최대수.

  • max_write_lock_count 이 회수의 기입 락 후, 사이에 읽어내 락을 인정한다.

  • myisam_recover_options --myisam-recover 옵션의 값.

  • myisam_sort_buffer_size REPAIR (을)를 실행할 때, 혹은 CREATE INDEX 또는 ALTER TABLE (을)를 사용해 인덱스를 작성할 경우에, 인덱스의 소트에 할당할 수 있는 버퍼.

  • myisam_max_extra_sort_file_size . 인덱스의 고속 작성으로 사용되는 임시 파일이, 키 캐쉬를 사용하는 경우보다, 지정되어 있는 사이즈분 큰 경우, 키 캐쉬 방식이 사용된다.이것은 주로, 큰 테이블의 긴 문자 키에, 처리 속도가 늦은 키 캐쉬 방식을 이용해 인덱스를 작성시키는 경우에 사용한다. 주의: 이 파라미터의 값은,4.0.3 보다 전의 버젼에서는메가바이트 단위, 이 버젼에서는 아르바이트 단위.

  • myisam_repair_threads . 이 값이 1 보다 큰 경우,Repair by sorting 프로세스중,MyISAM 테이블 인덱스가, 각각 독자적인 스레드로 평행 해 작성된다. 주의: multi-thread 수복은, 현재 아직 alpha 단계.

  • myisam_max_sort_file_size REPAIR ,ALTER TABLE , 또는 LOAD DATA INFILE (을)를 사용한 인덱스의 재생성시,MySQL 하지만 사용할 수 있는 임시 파일의 최대 사이즈.파일 사이즈가 이것보다 큰 경우, 인덱스는 키 캐쉬에 의해서 작성된다(시간이 걸린다). 주의: 이 파라미터의 값은,4.0.3 보다 전의 버젼에서는메가바이트 단위, 이 버젼에서는 아르바이트 단위.

  • net_buffer_length 쿼리와 쿼리의 사이, 통신 버퍼는 이 사이즈에 리셋트 된다.통상, 이것은 변경 해서는 안되지만, 메모리가 매우 작은 경우에는, 예측되는 쿼리 사이즈로 설정할 수 있다.이것은, 클라이언트에 의해서 송신된다 SQL 스테이트먼트의 예측되는 길이.스테이트먼트가 이 길이를 넘었을 경우, 버퍼는 자동적으로 max_allowed_packet 아르바이트까지 확대된다.

  • net_read_timeout 독해를 정?~ 하기 전에, 접속으로부터의 데이터를 대기하는 초수.주의: 접속으로부터의 데이터가 기대되지 않는 경우, 타임 아웃은 write_timeout 에 의해서 정의된다.slave_net_timeout 도 참조.

  • net_retry_count 통신 포토의 독해가 중단했을 경우에, 실행할 수 있는 재시행 회수.FreeBSD 그럼, 내부 중단이 모든 스레드에 통지되기 위해, 이 값을 크게 해야 한다.

  • net_write_timeout 기입을 정?~ 하기 전에, 블록이 접속에 써지는 것을 기다리는 초수.

  • open_files_limit 시스템이 mysqld 에 열리는 것을 허가하는 파일의 수.이것은 시스템으로 지정되어 있는 실제의 값이며, 기동시의 파라미터로서 mysqld (으)로 지정한 것과는 다른 경우가 있다.MySQL 하지만 오픈 파일수를 변경할 수 없는 시스템에서는 0 (이)가 된다.

  • pid_file --pid-file 옵션의 값.

  • port --port 옵션의 값.

  • protocol_version MySQL 서버에 의해서 사용되는 프로토콜 버젼.

  • range_alloc_block_size 범위의 최적화로 할당할 수 있는 블록의 사이즈.

  • read_buffer_size (이전에는 record_buffer ) 차례차례 스캔을 실행하는 각 스레드는, 스캔 하는 각 테이블에 이 사이즈의 버퍼를 할당한다.많은 차례차례 스캔을 실행하는 경우에는, 이 값을 크게 하는 것이 필요하다.

  • read_rnd_buffer_size (이전에는 record_rnd_buffer ) 소트 후, 소트 된 순서로 레코드를 읽어낼 때, 디스크 검색을 실시하지 않게, 레코드를 이 버퍼로부터 읽어낸다.이 값을 크게 설정하면,ORDER BY (을)를 큰폭으로 향상할 수 있다.이것은 스레드 고유의 변수이기 위해, 이것을 글로벌하게 크게 설정해서는 안되지만, 몇개의 특별 큰 쿼리를 실행할 때만 변경한다.

  • query_alloc_block_size 쿼리의 해석 및 실행시에 작성되는 오브젝트에 할당할 수 있는 메모리 할당 블록의 사이즈.메모리의 단편화에 문제가 있는 경우, 이것을 조금 크게 하면 개선할 가능성이 있다.

  • query_cache_limit 이것보다 큰 결과는 캐쉬하지 않는다(디폴트는 1M ).

  • query_cache_size 낡은 쿼리의 결과를 보존하기 위해서 할당할 수 있었던 메모리.이 값을 0 (으)로 하면, 쿼리 캐쉬는 무효가 된다(디폴트).

  • query_cache_type 다음의 몇개의 값(수치만)을 설정할 수 있다.

    치 | 앨리어스(alias) | 코멘트
    0 | OFF | 결과의 캐쉬 및 읽기를 실시하지 않는다.
    1 | ON | SELECT SQL_NO_CACHE ... 쿼리를 제외한 모든 결과를 캐쉬한다.
    2 | DEMAND | SELECT SQL_CACHE ... 쿼리만 캐쉬한다.

  • query_prealloc_size 쿼리의 해석 및 실행시에 사용되는 영속 버퍼의 사이즈.이 버퍼는 쿼리와 쿼리의 사이에서도 해방되지 않는다.이론적으로는, 이 값을 `` 충분히 크고'' 설정하는 것으로써,MySQL 하 malloc() 호출을 1 회도 실행하는 일 없이 쿼리를 실행할 수 있다.

  • safe_show_database 유저가 데이타베이스 권한 또는 테이블 권한을 전혀 가지지 않는 데이타베이스는 표시하지 않는다.이것은, 다른 유저가 권한을 가지는 데이타베이스를 표시할 수 없게 되므로, 시큐러티의 향상에 도움이 된다.skip_show_database 도 참조.

  • server_id --server-id 옵션의 값.

  • skip_locking mysqld 하지만 외부 락을 사용하는 경우는 OFF .

  • skip_networking 로컬(소켓) 접속만을 인정하는 경우는 ON .

  • skip_show_database 유저에게 PROCESS 권한이 없는 경우,SHOW DATABASES 의 실행을 인정하지 않는다.이것은, 다른 유저가 권한을 가지는 데이타베이스를 표시할 수 없게 되므로, 시큐러티의 향상에 도움이 된다.safe_show_database 도 참조.

  • slave_net_timeout 독해를 정?~ 하기 전에, 마스터/ 슬레이브 접속으로부터의 데이터를 대기하는 초수.

  • slow_launch_time 스레드의 작성에 이 값(초단위)보다 시간이 걸리면,Slow_launch_threads 카운터가 인크리먼트(increment) 된다.

  • socket 서버에 의해서 사용된다 Unix 소켓.

  • sort_buffer_size 소트를 실행할 필요가 있는 각 스레드가 이 사이즈의 버퍼를 할당한다.ORDER BY 조작 또는 GROUP BY 조작을 빠르게 하려면 , 이 값을 크게 한다. See 항A.4.4. 「MySQL 하지만 임시 파일을 격납하는 장소」 .

  • table_cache 모든 스레드로의 오픈 테이블수.이 값을 크게 하면,mysqld 하지만 필요로 하는 파일 기술자의 수가 많아진다.테이블 캐쉬를 크게 할 필요가 있을지 체크하려면 ,Opened_tables 변수를 조사한다. See 항4.6.8.3. 「SHOW STATUS 」 . 이 변수가 크고,FLUSH TABLES (모든 테이블을 닫아 다시 연다)(을)를 별로 실행하지 않는 것이면,table_cache 변수의 값을 크게 하는 것이 필요하다.

    테이블 캐쉬의 상세한 것에 대하여는, 항5.4.7. 「MySQL (으)로의 테이블의 오픈과 클로우즈의 방법」 (을)를 참조.

  • table_type 디폴트의 테이블형.

  • thread_cache_size 재이용을 위해서 캐쉬 로 유지하는 스레드수.클라이언트가 접속을 절단 했을 때에, 이전의 스레드수가 thread_cache_size 이하이면, 그 클라이언트의 스레드는 캐쉬에 들어간다.새로운 스레드는 모두 캐쉬로부터 받아들여져 캐쉬가 하늘의 경우만, 새로운 스레드가 작성된다.새로운 접속이 많이 발생하는 경우, 이 변수를 크고 하는 것으로써 퍼포먼스를 향상할 수 있다(스레드 실장이 이미 이상적인 상태이면, 그만큼 퍼포먼스는 향상하지 않는다).Connections 스테이터스 변수와 Threads_created 스테이터스 변수(상세한 것에 대하여는,see 항4.6.8.3. 「SHOW STATUS 」 )의 차이를 조사하는 것으로, 스레드캐슈의 효율성을 확인할 수 있다.

  • thread_concurrency Solaris 그럼,mysqld (은)는 이 값으로 thr_setconcurrency() (을)를 호출한다. thr_setconcurrency() 에 의해, 어플리케이션은, 동시에 실행하는 이상적인 스레드수를 스레드시스템으로 지정한다.

  • thread_stack 각 스레드의 스택 사이즈.crash-me 테스트에 의해서 검지되는 제한의 대부분이 이 값에 의존한다.통상의 조작에서는 디폴트로 충분하다. See 항5.1.4. 「MySQL 벤치마크스트」 .

  • timezone 서버의 타임 존.

  • tmp_table_size 메모리내의 텐포라리테이불이 이 사이즈를 넘으면,MySQL (은)는 자동적으로 이것을 디스크상의 MyISAM 테이블로 변환한다.상세한 GROUP BY 쿼리를 빈번히 실시해, 메모리에 여유가 있는 경우는,tmp_table_size 값을 크게 한다.

  • tmpdir 임시 파일 및 텐포라리테이불용 디렉토리.MySQL 4.1 이?~ , 복수의 패스를 코론 : (Windows 그럼 세?~ 코론 ; )(으)로 단락짓고 설정할 수 있게 되어 있다.이것은, 라운드로빈 방식으로 사용된다.이 기능은, 복수의 물리 디스크에 부하를 분산하는 목적으로 사용할 수 있다.메모리베이스의 파일 시스템을 가리키도록(듯이) tmpdir (을)를 설정하는 것은 가능.다만,MySQL 서버가 슬레이브의 경우는 할 수 없다.슬레이브의 경우, 머신이 리부트해도 텐포라리테이불의 replication 또는 LOAD DATA INFILE 의 replication 처리를 속행하기 위한 임시 파일이 필요하다.그 때문에, 머신의 리부트로 소거되는 메모리베이스의 tmpdir (은)는 적합하지 않는다.디스크 베이스의 tmpdir 하지만 필요.

  • transaction_alloc_block_size 코?~ 트 할 경우에, 바이너리 로그에 보존되는 트랜잭션(transaction)의 일부인 쿼리를 보존하기 위해서 할당할 수 있는 메모리 할당 블록의 사이즈.

  • transaction_prealloc_block_size transaction_alloc_blocks 의 영속적 버퍼.쿼리와 쿼리의 사이에서도 해방되지 않는다.통상의 트랜잭션(transaction)의 모든 쿼리에 대응할 수 있도록 `` 충분히 크고'' 설정하면,malloc() (을)를 몇번이나 호출하지 않고 끝난다.

  • version 서버의 버젼 번호.

  • wait_timeout 대화식이 아닌 접속을 종료하기 전에, 서버가 액티버티를 대기하는 초수.

    스레드 개시시,SESSION.WAIT_TIMEOUT (은)는,GLOBAL.WAIT_TIMEOUT 또는 GLOBAL.INTERACTIVE_TIMEOUT 에 의해서 초기화된다.어느 쪽이 될까는, 클라이언트의 타입(CLIENT_INTERACTIVE 접속 옵션으로 정의)에 의존한다.interactive_timeout 도 참조.

이것들 변수의 튜닝 방법에 대해서는,MySQL 의 튜닝에 관한 섹션을 참조해 주세요. See 항5.5.2. 「서버 파라미터의 튜닝」 .

4.6.8.5. SHOW [BDB] LOGS

SHOW LOGS (은)는, 기존의 로그 파일에 관한 스테이터스 정보를 표시합니다.현재는,Berkeley DB 로그 파일의 정보를 표시할 뿐(만큼)이므로, 그 앨리어스(alias)는(MySQL 4.1.1 그리고 도입) SHOW BDB LOGS 입니다.

  • File (은)는, 로그 파일의 풀 패스를 나타낸다.

  • Type (은)는, 로그 파일의 타입(Berkeley DB 로그 파일에서는 BDB )(을)를 나타낸다.

  • Status (은)는, 로그 파일의 스테이터스(파일을 삭제할 수 있는 경우는 FREE , 파일이 트랜잭션(transaction) 하부조직에 의해서 필요하게 되고 있는 경우는 IN USE )(을)를 나타낸다.

4.6.8.6. SHOW PROCESSLIST

SHOW [FULL] PROCESSLIST (은)는, 실행중의 스레드를 표시합니다. mysqladmin processlist 커멘드에서도 이 정보를 취득할 수 있습니다.SUPER 권한이 있으면, 모든 스레드를 표시할 수 있습니다.이 권한이 없는 경우는, 자신의 스레드만 표시할 수 있습니다. See 항4.6.7. 「KILL 구문」 . FULL 옵션을 사용하고 있지 않는 경우, 각 쿼리의 최초의 100 문자만이 표시됩니다.

4.0.12 이?~ ,MySQL 하 TCP/IP 접속의 호스트명을 hostname:client_port 형식에서 보고하므로, 어느 클라이언트가 무엇을 실시하고 있을까 알기 쉬워지고 있습니다.

이 커멘드는,'too many connections' 에러 메세지가 표시되고 원인을 알고 싶을 때에 편리합니다.MySQL (은)는,SUPER 권한을 가지는 클라이언트를 위해서 1 개의 특별 접속범위를 예약하고 있어, 언제라도 시스템에 로그인하고 체크할 수 있게 되어 있습니다(유저 전원에게 이 권한을 주지 않게 해 주세요).

mysqladmin processlist 그리고 확인할 수 있는 일반적인 상태는 이하대로입니다.

  • Checking table 스레드가 테이블의 자동 체크를 실행하고 있다.

  • Closing tables 스레드가, 변경된 테이블 데이터를 디스크에 플래시 해, 사용한 테이블을 닫고 있다.이것에는 통상 그만큼 시간이 걸리지 않는다.시간이 걸리는 경우, 디스크의 사용율을 체크할 필요가 있다.

  • Connect Out 마스터에 접속하고 있는 슬레이브.

  • Copying to tmp table on disk 텐포라리 결과 세트가 tmp_table_size 보다 크고, 스레드가 메모리베이스의 텐포라리테이불을 디스크 베이스로 변경하고, 메모리의 절약을 도모하고 있다.

  • Creating tmp table 스레드는, 쿼리의 결과의 일부를 보관 유지하기 위한 텐포라리테이불을 작성중.

  • deleting from main table 복수 테이블을 삭제하는 최초의 단계에서, 최초의 테이블을 삭제중.

  • deleting from reference tables 복수 테이블을 삭제한다 2 번째의 단계에서, 다른 테이블에서, 일치한 레코드를 삭제중.

  • Flushing tables 스레드가 FLUSH TABLES (을)를 실행중.모든 스레드에 의해 그 테이블이 닫혀지는 것을 기다리고 있다.

  • Killed 누군가가 스레드를 강제 종료가 명령을 내렸기 때문에, 다음 번의 키르후라그체크시에 강제 종료된다.MySQL 그럼 큰 각 루프로 플래그가 체크되지만, 그런데도 스레드 종료에는 조금 시간이 걸리는 경우가 있다.스레드가 다른 스레드에 의해서 락 되고 있는 경우, 그 락이 해제되었더니 강제 종료가 실행된다.

  • Sending data 스레드는 SELECT 스테이트먼트의 레코드를 처리중에서, 한편 클라이언트에 데이터를 송신중.

  • Sorting for group 스레드는,GROUP BY 의 소트를 실행중.

  • Sorting for order 스레드는,ORDER BY 의 소트를 실행중.

  • Opening tables 스레드가 테이블을 열려 하고 있다.이것은, 무엇인가가 방해하고 있지 않으면 곧바로 끝날 것이다.예를 들어,ALTER TABLE (이)나 LOCK TABLE 등에 의해, 그 커멘드의 종료시까지 테이블이 열리지 않는 것이 있다.

  • Removing duplicates 쿼리로 SELECT DISTINCT 하지만 사용되었지만,MySQL (은)는 초기 단계에서 중복을 제외하는 최적화를 실행할 수 없었다.이 때문에,MySQL (은)는 결과를 클라이언트에 송신하기 전에, 중복 레코드를 삭제할 단계를 밟을 필요가 있다.

  • Reopen table 스레드는 테이블의 락을 취득했지만, 락 취득 후, 아래의 테이블 구조가 변경되고 있는 것을 인식했다.이 때문에, 락을 해제해, 테이블을 닫고, 다시 열려 하고 있다.

  • Repair by sorting 수복 코드가 소트를 사용해 인덱스를 작성하다.

  • Repair with keycache 수복 코드가, 키 캐쉬에 의해, 키를 1 개씩 작성하다.이것은,Repair by sorting 보다 큰폭으로 시간이 걸린다.

  • Searching rows for update 스레드가 레코드 갱신의 초기 단계로서 갱신 대상의 일치 레코드를 검색중이다.레코드 검색에 사용하는 인덱스를 UPDATE 하지만 변경하면, 이 단계가 필요하다.

  • Sleeping 스레드가, 클라이언트로부터 새로운 커멘드가 송신되는 것을 기다리고 있다.

  • System lock 스레드가, 테이블의 외부 시스템 락을 기다리고 있다.같은 테이블에 액세스 하는 복수의 mysqld 서버를 사용하고 있지 않는 경우,--skip-external-locking 옵션으로 시스템 락을 무효로 할 수 있다.

  • Upgrading lock INSERT DELAYED 핸들러가, 레코드 삽입을 위해서 테이블을 잠그려 하고 있다.

  • Updating 스레드가 갱신 대상 레코드를 검색해 갱신하고 있다.

  • User Lock 스레드가 GET_LOCK() (을)를 기다리고 있다.

  • Waiting for tables 아래의 테이블 구조가 변경되고 있기 때문에, 테이블을 다시 열어 새로운 구조를 취득할 필요가 있다고 하는 통지를 스레드가 받았다.테이블을 다시 열기 위해서 는, 다른 모든 스레드가 그 테이블을 닫는 것을 기다릴 필요가 있다.

    이 통지는, 다른 스레드가 그 테이블에 대해서 FLUSH TABLES ,FLUSH TABLES table_name ,ALTER TABLE ,RENAME TABLE ,REPAIR TABLE ,ANALYZE TABLE ,OPTIMIZE TABLE 의 어느쪽이든을 실행하고 있는 경우에 발생한다.

  • waiting for handler insert INSERT DELAYED 핸들러가 모든 삽입 처리를 완료해, 신규의 삽입을 대기중이다.

대부분의 상태는 곧바로 끝납니다.몇초도 같은 상태가 계속 되는 경우는, 문제가 있을 가능성이 있으므로, 조사가 필요합니다.

그 밖에도 설명하고 있지 않는 상태가 있습니다만, 그 대부분은 mysqld 의 버그 발견에 도움이 되는 것입니다.

4.6.8.7. SHOW GRANTS

SHOW GRANTS FOR user (은)는, 유저의 권한을 복제하기 위해서 발행할 필요가 있다 grant 커멘드를 열거합니다.

mysql> SHOW GRANTS FOR root@localhost;
+---------------------------------------------------------------------+
| Grants for root@localhost                                           |
+---------------------------------------------------------------------+
| GRANT ALL PRIVILEGES ON *.* TO 'root'@'localhost' WITH GRANT OPTION |
+---------------------------------------------------------------------+

현재의 세션의 권한을 열거하려면 ,CURRENT_USER() 함수(버젼 4.0.6 그리고 도입)을 사용하고, 그 세션으로 인증되고 있는 유저를 확인할 수 있습니다. See 항6.3.6.2. 「그 외의 각종 함수」 .

4.6.8.8. SHOW CREATE TABLE

지정한 테이블을 작성한다 CREATE TABLE 스테이트먼트를 표시합니다.

mysql> SHOW CREATE TABLE t\G
*************************** 1. row ***************************
       Table: t
Create Table: CREATE TABLE t (
  id INT(11) default NULL auto_increment,
  s char(60) default NULL,
  PRIMARY KEY (id)
) TYPE=MyISAM

SHOW CREATE TABLE 그리고 표시되는 테이블명과 컬럼명은,SQL_QUOTE_SHOW_CREATE 옵션의 값에 따라서 인용부호로 둘러싸입니다. 항5.5.6. 「SET 구문」 .

4.6.8.9. SHOW WARNINGS | ERRORS

SHOW WARNINGS [LIMIT row_count]
SHOW ERRORS [LIMIT row_count]

이 커멘드는,MySQL 4.1.0 그리고 도입되었습니다.

이것은, 전회의 커멘드로의 에러, 경고, 및 코멘트를 표시합니다.에러 및 경고는, 테이블을 사용하는 신규 커멘드 마다 리셋트 됩니다.

MySQL 서버는, 전회의 커멘드로 발생한 경고와 에러의 합계수를 돌려줍니다.이것은,mysql_warning_count() (을)를 호출하는 것에 의해서 취득할 수 있습니다.

max_error_count 까지의 메세지가 보존됩니다(글로벌 및 스레드 고유 변수).

@error_count 그리고 에러수를,@warning_count 그리고 경고수를 취득할 수 있습니다.

SHOW WARNINGS 그럼 전회의 커멘드로 발생한 에러, 경고, 및 코멘트가 모두 표시되어SHOW ERRORS 그럼 에러만이 표시됩니다.

mysql> DROP TABLE IF EXISTS no_such_table;
mysql> SHOW WARNINGS;

+-------+------+-------------------------------+
| Level | Code | Message                       |
+-------+------+-------------------------------+
| Note  | 1051 | Unknown table 'no_such_table' |
+-------+------+-------------------------------+

주의: MySQL 4.1.0 그럼 경고의 체제가 추가되었을 뿐이므로,MySQL 커멘드의 상당수는 경고를 생성하지 않습니다.4.1.1 그럼,LOAD DATA INFILE , 및 INSERT ,UPDATE ,ALTER 등의 DML 스테이트먼트의 모든 종류의 경고를 서포트합니다.

이하, 삽입 스테이트먼트의 변환 경고를 생성하는 간단한 예를 나타냅니다.

mysql> create table t1(a tinyint NOT NULL, b char(4));
Query OK, 0 rows affected (0.00 sec)

mysql> insert into t1 values(10,'mysql'),(NULL,'test'),(300,'open source');
Query OK, 3 rows affected, 4 warnings (0.15 sec)
Records: 3  Duplicates: 0  Warnings: 4

mysql> show warnings;
+---------+------+---------------------------------------------------------------+
| Level   | Code | Message                                                       |
+---------+------+---------------------------------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1                        |
| Warning | 1261 | Data truncated, NULL supplied to NOT NULL column 'a' at row 2 |
| Warning | 1262 | Data truncated, out of range for column 'a' at row 3          |
| Warning | 1263 | Data truncated for column 'b' at row 3                        |
+---------+------+---------------------------------------------------------------+
4 rows in set (0.00 sec)

경고의 최대수는, 서버 변수 'max_error_count' ,SET max_error_count=[count] (을)를 사용해 지정할 수 있습니다.디폴트는 64 입니다.이 변수를 '0' 에 리셋트 하면 이 설정을 무효 할 수 있습니다.max_error_count 하지만 0 의 경우에서도, 경고가 몇회 발생했는지 표시됩니다만, 메세지는 보존되지 않습니다.

예를 들어, 상기의 예로의 이하의 ALTER 테이블 스테이트먼트의 경우,max_error_count=1 (으)로 설정하면, 경고가 3 회발생해도, 돌려주어지는 경고 메세지는 1 개만으로 됩니다.

mysql> show variables like 'max_error_count';
+-----------------+-------+
| Variable_name   | Value |
+-----------------+-------+
| max_error_count | 64    |
+-----------------+-------+
1 row in set (0.00 sec)

mysql> set max_error_count=1;
Query OK, 0 rows affected (0.00 sec)

mysql> alter table t1 modify b char;
Query OK, 3 rows affected, 3 warnings (0.00 sec)
Records: 3  Duplicates: 0  Warnings: 3

mysql> show warnings;
+---------+------+----------------------------------------+
| Level   | Code | Message                                |
+---------+------+----------------------------------------+
| Warning | 1263 | Data truncated for column 'b' at row 1 |
+---------+------+----------------------------------------+
1 row in set (0.00 sec)

mysql>

4.6.8.10. SHOW TABLE TYPES

SHOW TABLE TYPES

이 커멘드는,MySQL 4.1.0 그리고 도입되었습니다.

SHOW TABLE TYPES (은)는, 테이블형에 관한 스테이터스 정보를 표시합니다.이 커멘드는, 테이블형이 서포트되고 있는지 어떤지, 및 디폴트의 테이블형을 확인하는데 사용됩니다.

mysql> SHOW TABLE TYPES;

+--------+---------+-----------------------------------------------------------+
| Type   | Support | Comment                                                   |
+--------+---------+-----------------------------------------------------------+
| MyISAM | DEFAULT | Default type from 3.23 with great performance             |
| HEAP   | YES     | Hash based, stored in memory, useful for temporary tables |
| MERGE  | YES     | Collection of identical MyISAM tables                     |
| ISAM   | YES     | Obsolete table type; Is replaced by MyISAM                |
| InnoDB | YES     | Supports transactions, row-level locking and foreign keys |
| BDB    | NO      | Supports transactions and page-level locking              |
+--------+---------+-----------------------------------------------------------+
6 rows in set (0.00 sec)

'Support' 필드의 DEFAULT (은)는, 그 테이블형이 서포트되고 있는 것으로, 테이블형이 디폴트인 것을 나타냅니다.서버를 --default-table-type=InnoDB 그리고 기동했을 경우,InnoDB 의 'Support' 필드치가 DEFAULT (이)가 됩니다.

4.6.8.11. SHOW PRIVILEGES

SHOW PRIVILEGES

이 커멘드는,MySQL 4.1.0 그리고 도입되었습니다.

SHOW PRIVILEGES (은)는, 아래의 MySQL 서버가 서포트하는 시스템 권한을 일람표 나타내 보입니다.

mysql> show privileges;
+------------+--------------------------+-------------------------------------------------------+
| Privilege  | Context                  | Comment                                               |
+------------+--------------------------+-------------------------------------------------------+
| Select     | Tables                   | To retrieve rows from table                           |
| Insert     | Tables                   | To insert data into tables                            |
| Update     | Tables                   | To update existing rows                               |
| Delete     | Tables                   | To delete existing rows                               |
| Index      | Tables                   | To create or drop indexes                             |
| Alter      | Tables                   | To alter the table                                    |
| Create     | Databases,Tables,Indexes | To create new databases and tables                    |
| Drop       | Databases,Tables         | To drop databases and tables                          |
| Grant      | Databases,Tables         | To give to other users those privileges you possess   |
| References | Databases,Tables         | To have references on tables                          |
| Reload     | Server Admin             | To reload or refresh tables, logs and privileges      |
| Shutdown   | Server Admin             | To shutdown the server                                |
| Process    | Server Admin             | To view the plain text of currently executing queries |
| File       | File access on server    | To read and write files on the server                 |
+------------+--------------------------+-------------------------------------------------------+
14 rows in set (0.00 sec)


4.7. MySQL 의 로컬라이즈와 국제적인 사용

4.7.1. 데이터 및 소트용 캐릭터 세트

디폴트에서는,MySQL (은)는 스웨덴어 및 핀란드어에 따라서 소트 된다 ISO-8859-1 (Latin1 ) 캐릭터 세트를 사용합니다.이것은, 미국과 서유럽에 적절한 캐릭터 세트입니다.

표준 MySQL 바이너리는,--with-extra-charsets=complex 그리고 컴파일 됩니다.이것에 의해, 모든 표준 프로그램에 코드가 추가되어 바이너리내에서 latin1 (와)과 모든 멀티 바이트 캐릭터 세트를 처리할 수 있게 됩니다.다른 캐릭터 세트가 필요한 경우는, 캐릭터 세트 정의 파일로부터 로드합니다.

캐릭터 세트에 의해, 이름에 사용할 수 있는 문자와SELECT 스테이트먼트의 ORDER BY 마디 및 GROUP BY 마디로의 문자열의 소트 방법이 결정됩니다.

서버 기동시에 --default-character-set 옵션으로 캐릭터 세트를 변경할 수 있습니다.이용 가능한 캐릭터 세트는,--with-charset=charset 옵션과 --with-extra-charsets= list-of-charset | complex | all | none 옵션이 configure (이)가 되어 있는지 어떤지, 및 SHAREDIR/charsets/Index 에 포함되어 있는 캐릭터 세트 설정 파일에 의존합니다. See 항2.3.3. 「일반적인 configure 옵션」 .

MySQL 의 실행중으로 캐릭터 세트를 변경했을 경우(소트 순서가 바뀔 가능성도 있습니다), 모든 테이블로 myisamchk -r -q --set-character-set=charset (을)를 실행할 필요가 있습니다.이것을 실시하지 않는 경우, 인덱스가 올바른 순서가 아니게 될 가능성이 있습니다.

클라이언트가 MySQL 서버에 접속하면, 서버는 디폴트의 캐릭터 세트를 클라이언트에 보냅니다.클라이언트는, 이 접속용으로서 그 캐릭터 세트로 전환합니다.

SQL 쿼리의 문자열을 이스케이프 하는 경우는,mysql_real_escape_string() (을)를 사용해 주세요.최초의 파라미터로서 MYSQL 접속 핸들을 사용하는 것 이외,mysql_real_escape_string() (은)는 구 mysql_escape_string() 함수와 같습니다.

서버의 인스톨 패스 이외의 패스로 클라이언트가 컴파일 되고 있어MySQL (을)를 콘피개 한 유저가 모든 캐릭터 세트를 MySQL 바이너리에 짜넣지 않은 경우, 서버가 클라이언트와는 다른 캐릭터 세트로 실행하고 있을 때 필요한 추가 캐릭터 세트의 장소를, 클라이언트로 지정할 필요가 있습니다.

이것은,MySQL 옵션 설정 파일로 지정할 수 있습니다.

[client]
character-sets-dir=/usr/local/mysql/share/mysql/charsets

여기서, 패스는, 동적 MySQL 캐릭터 세트가 보존되고 있는 디렉토리를 가리킵니다.

이하와 같이, 클라이언트에 특정의 캐릭터 세트의 사용을 강제하는 것도 가능합니다.

[client]
default-character-set=character-set-name

그러나, 통상은 필요 없습니다.

4.7.1.1. 독일어 캐릭터 세트

독일어의 소트 순서가 필요한 경우,mysqld (을)를 --default-character-set=latin1_de 그리고 기동합니다.이것에는, 이하와 같은 특징이 있습니다.

문자열의 소트 및 비교시, 비교의 실행전에 이하의 문자열의 매핑이 실행된다.

ä  ->  ae
ö  ->  oe
ü  ->  ue
ß  ->  ss

엑센트 문자는 모두, 대응하는 엑센트 없음의 대문자에 변환됩니다.또, 모든 문자가 대문자에 변환됩니다.

문자열을 LIKE 그리고 비교할 때 ,1 문자로부터 2 문자에의 매핑은 실행되지 않습니다.모든 문자가 대문자에 변환됩니다.Ü ,ü ,Ö ,ö ,Ä , 및 ä 이외, 모든 문자로부터 엑센트가 삭제됩니다.

4.7.2. 영어 이외의 에러 메세지

mysqld 그럼, 이하의 언어로 에러 메세지를 출력할 수 있습니다. 초콜렛어, 덴마크어, 네델란드어, 영어(디폴트), 에스토니아어, 프랑스어, 독일어, 희랍어, 헝가리어, 이탈리아어, 일본어, 한국어, 노르웨이어, 신노르웨이어, 폴란드어, 포르투갈어, 루마니아어, 러시아어, 슬로바키아어, 스페인어, 및 스웨덴어.

특정의 언어로 mysqld (을)를 기동하려면 ,--language=lang 또는 -L lang 옵션을 사용합니다.다음에 예를 나타냅니다.

shell> mysqld --language=swedish

또는

shell> mysqld --language=/usr/local/share/swedish

주의: 언어명은 모두 소문자로 지정합니다.

언어 파일은(디폴트로)mysql_base_dir/share/LANGUAGE/ 에 있습니다.

에러 메세지 파일을 갱신하려면 ,errmsg.txt 파일을 편집해, 이하의 커멘드를 실행해 errmsg.sys 파일을 생성합니다.

shell> comp_err errmsg.txt errmsg.sys

MySQL (을)를 새로운 버젼에 업그레이드 했을 경우, 이 변경을, 신규 errmsg.txt 파일에서도 똑같이 가 주세요.

4.7.3. 새로운 캐릭터 세트의 추가

다른 캐릭터 세트를 MySQL 에 추가하려면 , 이하의 순서를 실행합니다.

캐릭터 세트가 심플한 것이나 컴플렉스인 물건인지를 판단합니다.캐릭터 세트가, 소트를 위해서 특수 문자 조합 루틴을 필요로 하지 않고, 멀티 바이트 문자의 서포트도 필요한 차면, 그것은 심플합니다.어느 쪽인지를 필요로 하는 경우, 그것은 컴플렉스입니다.

예를 들어,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 말을 차지한다.

    See 항4.7.4. 「캐릭터 정의 배열」 .

  3. 캐릭터 세트명을,configure.in 의 CHARSETS_AVAILABLE 리스트 및 COMPILED_CHARSETS 리스트에 추가한다.

  4. 재콘피개 해 재컴파일 해, 테스트한다.

컴플렉스인 캐릭터 세트의 경우, 이하를 실행합니다.

  1. MySQL 소스 디스트리뷰션에 strings/ctype-MYSET.c 파일을 작성한다.

  2. MYSET (을)를 sql/share/charsets/Index 파일의 마지막에 추가한다.이것에 일의의 번호를 할당한다.

  3. strings/ctype-big5.c 등, 기존의 ctype-*.c 파일의 1 개를 보고, 무슨 정의가 필요한가 조사한다.주의: 파일내의 배열명은,ctype_MYSET ,to_lower_MYSET 등인 것이 필요.이것은, 심플한 캐릭터 세트의 배열에 대응한다. See 항4.7.4. 「캐릭터 정의 배열」 .

  4. 파일의 선두 부근에, 이하와 같은 코멘트를 둔다.

    /*
 * This comment is parsed by configure to create ctype.c,
 * so don't change it unless you know what you are doing.
 *
 * .configure. number_MYSET=MYNUMBER
 * .configure. strxfrm_multiply_MYSET=N
 * .configure. mbmaxlen_MYSET=N
 */

    configure 프로그램은 이 코멘트를 사용하고, 자동적으로 캐릭터 세트를 MySQL 라이브러리에 짜넣는다.

    strxfrm_multiply 행 및 mbmaxlen 행에 대해서는, 후속 섹션으로 설명한다.이것들은 각각, 문자열 조합 함수 또는 멀티 바이트 캐릭터 세트 함수가 필요한 경우에 짜넣는다.

  5. 다음에, 이하의 함수를 작성한다.

    • my_strncoll_MYSET()

    • my_strcoll_MYSET()

    • my_strxfrm_MYSET()

    • my_like_range_MYSET()

    See 항4.7.5. 「문자열 조합 서포트」 .

  6. 캐릭터 세트명을,configure.in 의 CHARSETS_AVAILABLE 리스트 및 COMPILED_CHARSETS 리스트에 추가한다.

  7. 재콘피개 해 재컴파일 해, 테스트한다.

sql/share/charsets/README 파일에, 보다 상세한 설명이 포함되어 있습니다.

MySQL 디스트리뷰션에의 캐릭터 세트의 편입을 희망하는 경우에는,MySQL internals 메일링 리스트에 패치를 메일 해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 .

4.7.4. 캐릭터 정의 배열

to_lower[] (와)과 to_upper[] (은)는, 캐릭터 세트의 각 멤버에 대응하는, 대문자와 소문자가 격납되는 심플한 배열입니다.다음에 예를 나타냅니다.

to_lower['A']
하 'a'
(을)를 포함한다
to_upper['a']
하 'A'
(을)를 포함한다

sort_order[] (은)는, 문자를 어떠한 차례로 비교해 소트 하는지를 나타내는 맵입니다.많은 경우(모든 캐릭터 세트에 대해가 아닙니다만), 이것은 to_upper[] (와)과 같습니다(소트로 대문자와 소문자가 구별되지 않습니다).MySQL (은)는,sort_order[character] 의 값에 근거해 문자를 소트 합니다.한층 더 복잡한 소트 룰에 관해서는, 후술의 문자열 조합의 설명을 참조해 주세요. See 항4.7.5. 「문자열 조합 서포트」 .

ctype[] (은)는 비트치의 배열로,1 문자가 1 요소입니다.주의: to_lower[] ,to_upper[] , 및 sort_order[] (은)는 문자치로 인덱스화 됩니다만,ctype[] (은)는 문자치 + 1 그리고 인덱스화 됩니다.이것은,EOF (을)를 처리하는 것이 필요했다고 나무의 낡은 레가시입니다.

m_ctype.h 에, 이하의 비트 마스크 정의가 있습니다.

#define _U      01      /* Uppercase */
#define _L      02      /* Lowercase */
#define _N      04      /* Numeral (digit) */
#define _S      010     /* Spacing character */
#define _P      020     /* Punctuation */
#define _C      040     /* Control character */
#define _B      0100    /* Blank */
#define _X      0200    /* heXadecimal digit */

각 문자의 ctype[] 엔트리는, 문자를 지정하는 비트 마스크치의 편성이 되어 있을 필요가 있습니다.예를 들어,'A' (은)는 대문자(_U )인 것과 동시에 16 진수(_X )(이)라도 있으므로,ctype['A'+1] 에는 이하의 값이 포함됩니다.

_U + _X = 01 + 0200 = 0201

4.7.5. 문자열 조합 서포트

사용하는 언어의 소트 룰이, 심플한 sort_order[] 테이블로 처리하려면 너무 복잡한 경우, 문자열 조합을 실시할 필요가 있습니다.

현재로서는, 이것에 관한 최선의 문서는, 벌써 실장되고 있는 캐릭터 세트입니다.예를 들어,big5 ,czech ,gbk ,sjis ,tis160 등의 캐릭터 세트를 봐 주세요.

파일의 선두의 특수 코멘트로,strxfrm_multiply_MYSET=N 값을 지정할 필요가 있습니다.N 에는,my_strxfrm_MYSET 그리고 문자열을 커질 수 있는 최대 비율(정의 정수)을 설정해 주세요.

4.7.6. 멀티 바이트 문자 서포트

멀티 바이트 문자를 포함한 새로운 캐릭터 세트의 서포트를 추가하는 경우, 멀티 바이트 문자 함수를 사용할 필요가 있습니다.

현재로서는, 이것에 관한 최선의 문서는, 벌써 실장되고 있는 캐릭터 세트입니다.예를 들어,euc_kr ,gb2312 ,gbk ,sjis ,ujis 등의 캐릭터 세트를 참조해 주세요.이것들은,strings 디렉토리의 ctype-'charset'.c 파일에 실장되고 있습니다.

원시 파일의 선두의 특수 코멘트로 mbmaxlen_MYSET=N 값을 지정할 필요가 있습니다.N 에는, 캐릭터 세트내의 최대 문자의 아르바이트수를 설정해 주세요.

4.7.7. 캐릭터 세트에 관한 문제

사용하고 있는 바이너리에 컴파일 되어 있지 않은 캐릭터 세트를 사용하면, 몇개의 문제가 발생할 가능성이 있습니다.

  • 프로그램이 인식하고 있는 패스에, 캐릭터 세트가 보존되어 있지 않다(디폴트는 /usr/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 table_name 그리고 확인할 수 있습니다.


4.8. MySQL 서버 사이드의 스크립트와 유틸리티

4.8.1. 서버 사이드의 스크립트와 유틸리티의 개요

모든 MySQL 프로그램이 많은 다양한 옵션을 사용합니다.그러나, 모든 MySQL 프로그램에 --help 옵션이 준비되어 있어 이 옵션을 사용하는 것으로써, 그 프로그램의 모든 옵션의 설명을 표시할 수 있습니다.예를 들어,mysql --help (을)를 시험해 보세요.

모든 표준 프로그램의 디폴트 옵션은, 옵션 설정 파일로 덧쓰기할 수 있습니다. 항4.1.2. 「my.cnf 옵션 설정 파일」 .

이하의 일람은, 서버 사이드의 MySQL 프로그램을 간단하게 설명한 것입니다.

  • myisamchk

    MySQL 테이블의 기술, 체크, 최적화, 및 수복을 실시하는 유틸리티.myisamchk 에는 많은 기능이 있기 위해, 다른 장으로 설명한다. See 장 4. 데이타베이스 관리 .

  • make_binary_distribution

    컴파일된 MySQL 의 바이너리 릴리스를 작성한다.작성한 릴리스는, 다른 MySQL 유저가 이용할 수 있도록,FTP 경유로 support.mysql.com 의 /pub/mysql/Incoming 에 송신할 수 있다.

  • mysqlbug

    MySQL 버그 리포트 스크립트.이 스크립트는,MySQL 리스트에 버그 리포트를 제출할 때, 반드시 사용한다.

  • mysqld

    SQL demon.항상 가동하고 있는 것이 필요하다.

  • mysql_install_db

    MySQL 권한 테이블을 디폴트 권한으로 작성한다.이것은 통상, 최초로 MySQL (을)를 시스템에 인스톨 할 때,1 회만 실행한다.

4.8.2. mysqld_safe (mysqld 의 나팔)

mysqld_safe (은)는,mysqld demon를 Unix 그리고 기동할 때의 추천 되는 방법입니다.mysqld_safe 에 의해, 에러 발생시에 서버를 재기동하거나 런타임 정보를 로그 파일에 기록하는 등의 세이프티 기능이 더해집니다.

주의: MySQL 4.0 보다 전은,mysqld_safe 하 safe_mysqld (이)라는 이름이었습니다.하위 호환성을 유지하기 위해(때문에), 당분간의 사이,MySQL 바이너리 디스트리뷰션에는 mysqld_safe 에의 기호 연결로서 safe_mysqld 하지만 포함할 수 있고 있습니다.

--mysqld=# 또는 --mysqld-version=# (을)를 사용하지 않는 경우,mysqld_safe (은)는,mysqld-max (이)라는 이름의 실행 가능 파일이 있으면 이것을 사용합니다.이 파일이 없으면,mysqld_safe 하 mysqld (을)를 개시합니다.이것에 의해,mysqld 대신에 mysqld-max 하지만 사용될지의 테스트를 간단하게 실행할 수 있습니다.mysqld-max (을)를 mysqld (이)가 있는 장소에 카피하는 것만으로, 전자가 사용됩니다.

통상,mysqld_safe 스크립트는 편집하지 말아 주세요.대신에,my.cnf 파일의 [mysqld_safe] 섹션의 mysqld_safe 에 옵션을 설정합니다.mysqld_safe (은)는, 옵션 설정 파일의 [mysqld] ,[server] ,[mysqld_safe] 의 각 섹션으로부터 모든 옵션을 읽어냅니다(하위 호환성 때문에,[safe_mysqld] 섹션으로부터도 옵션이 읽어내집니다). See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

주의: mysqld_safe 에 대한 커멘드 라인 옵션은 모두 mysqld 에게 건네집니다.mysqld 하지만 서포트하고 있지 않는 옵션을 mysqld_safe 그리고 사용하려면 , 옵션 설정 파일로 그 옵션을 지정할 필요가 있습니다.

mysqld_safe 의 옵션의 대부분은,mysqld 의 옵션과 같습니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

mysqld_safe (은)는, 이하의 옵션을 서포트합니다.

  • --basedir=path , --core-file-size=#

    mysqld 하지만 작성할 수 있는 코어 파일의 사이즈.ulimit -c 에게 건네진다.

  • --datadir=path , --defaults-extra-file=path , --defaults-file=path , --err-log=path (4.0 그리고 폐?~ .대신에 --log-error (을)를 사용하는 것) , --log-error=path

    상기 파일에 에러 로그를 쓴다. See 항4.10.1. 「에러 로그」 .

  • --ledir=path

    mysqld 의 패스.

  • --log=path , --mysqld=mysqld-version

    ledir 디렉토리내에 있는 기동한다 mysqld 버젼의 이름.

  • --mysqld-version=version

    --mysqld= (와)과 같지만, 여기에서는 mysqld 의 사픽스만 지정한다. 예를 들어,--mysqld-version=max (을)를 사용하면,mysqld_safe 하 ledir/mysqld-max 버젼을 기동한다.--mysqld-version 의 인수가 공백의 경우,ledir/mysqld 하지만 사용된다.

  • --nice=# (MySQL 4.0.14 그리고 추가) , --no-defaults , --open-files-limit=#

    mysqld 하지만 열릴 수 있는 파일의 수.ulimit -n 에게 건네진다.주의: 이것을 정상적으로 기능시키려면 ,mysqld_safe (을)를 root (으)로서 기동할 필요가 있다.

  • --pid-file=path , --port=# , --socket=path , --timezone=#

    타임 존(TZ ) 변수를, 이 파라미터의 값으로 설정한다.

  • --user=#

mysqld_safe 스크립트는,MySQL 의 소스 버젼 또는 바이너리 버젼의 어디에서 인스톨 된 서버에서도 기동할 수 있도록 기술되고 있습니다.서버가 다소 다른 장소에 인스톨 되고 있어도 문제 없습니다.mysqld_safe (은)는, 이하의 몇개의 조건이 채워져 있는 것을 필요로 합니다.

  • mysqld_safe (을)를 기동하는 디렉토리와의 상대 관계로 서버와 데이타베이스를 검출할 수 있다.mysqld_safe (은)는, 그 작업 디렉토리 이하로,bin 디렉토리와 data 디렉토리(바이너리 디스트리뷰션의 경우), 또는 libexec 디렉토리와 var 디렉토리(소스 디스트리뷰션의 경우)를 찾는다.MySQL 인스톨 디렉토리(예를 들어, 바이너리 디스트리뷰션의 경우는 /usr/local/mysql )(으)로부터 mysqld_safe (을)를 실행하는 경우, 이 조건이 채워져 있는 것이 필요하다.

  • 서버 및 데이타베이스를 작업 디렉토리와의 상대 관계로 검출할 수 없는 경우,mysqld_safe (은)는 절대 패스에 의해서 검출하려고 한다.통상, 이 장소는,/usr/local/libexec (이)나 /usr/local/var (이)가 된다.실제의 장소는, 디스트리뷰션이 빌드 되었을 때에 결정되어 여기로부터 mysqld_safe 하지만 기동한다.MySQL 하지만 표준의 장소에 인스톨 되고 있는 경우, 이 절대 패스가 올바른 것이 필요하게 된다.

mysqld_safe (은)는 그 작업 디렉토리에 대립되어 서버와 데이타베이스를 찾기 위해,MySQL 인스톨 디렉토리로부터 mysqld_safe (을)를 개시한다면,MySQL 의 바이너리 디스트리뷰션은 어디에라도 인스톨 할 수 있습니다.

shell> cd mysql_installation_directory
shell> bin/mysqld_safe &

MySQL 인스톨 디렉토리로부터 기동해도 mysqld_safe 하지만 실패하는 경우, 시스템에 있어서 올바르다 mysqld 의 패스와 패스명 옵션이 사용되도록(듯이) 수정합니다.주의: MySQL (을)를 업그레이드 하면,mysqld_safe 의 수정 버젼은 덧쓰기됩니다.재인스톨 할 수 있도록(듯이), 편집 버젼의 카피를 취해 둬 주세요.

4.8.3. mysqld_multi (복수의 MySQL 서버를 관리하는 프로그램)

mysqld_multi (은)는, 다양한 Unix 소켓 및 TCP/IP 포토를 릿슨 하는 복수의 mysqld 프로세스를 관리하기 위한 프로그램입니다.

이 프로그램은,[mysqld#] (이)라는 이름의 그룹을 my.cnf (또는 --config-file=... 옵션으로 지정된 파일)로부터 검색합니다.여기서,# 하 1 그리고 시작되는 임의의 정의 수입니다.이 번호는, 이하의 설명으로는 옵션 그룹 번호, 또는 GNR (이)라고 부릅니다.그룹 번호는 옵션 그룹을 식별해, 기동하거나 정?~ 하거나 또는 스테이터스 정보를 취득하는 서버를 지정한다 mysqld_multi 의 인수로서 사용합니다.이러한 그룹에 포함되는 옵션은,mysqld 의 기동에 사용되는 통상의 [mysqld] 그룹과 같습니다( 항2.4.3. 「MySQL (을)를 자동적으로 기동 및 정?~ 한다」 등을 참조해 주세요).다만,mysqld_multi 그럼, 각 그룹에, 각 mysqld 프로세스로 사용되는 포토나 소켓등을 지정하는 옵션이 포함되어 있는 것이 필요합니다.

mysqld_multi (은)는, 이하의 구문으로 기동합니다.

   mysqld_multi [OPTIONS] {start|stop|report} [GNR,GNR,GNR...]

인가 mysqld_multi [OPTIONS] {start|stop|report} [GNR-GNR,GNR,GNR-GNR,...]

각 GNR (은)는, 옵션 그룹 번호를 나타냅니다.임의의 GNR (을)를 개시, 정?~ , 또는 보고할 수 있어 복수의 GNR (을)를 동시에 개시, 정?~ , 또는 보고할 수도 있습니다.옵션 설정 파일의 설정예를 표시하려면 , 이하의 커멘드를 실행합니다.

shell> mysqld_multi --example

리스트내의 GNR 의 값은 콤마로 단락짓거나 데쉬 기호로 결합할 수 있습니다.결합의 경우,GNR1-GNR2 사이의 모든 GNR 하지만 대상이 됩니다.GNR 인수를 지정하지 않았던 경우, 리스트내의 모든 그룹이 기동, 정?~ , 또는 보고됩니다.주의: GNR 리스트에는 공백 스페이스를 사용할 수 없습니다.공백 스페이스를 삽입하면, 스페이스의 뒤는 무시됩니다.

mysqld_multi (은)는, 이하의 옵션을 서포트합니다.

  • --config-file=...

    대체 설정 파일.주의: 이것은, 이 프로그램의 옵션([mysqld_multi] 그룹)에는 영향을 주지 않고,[mysqld#] 그룹에게만 영향을 준다.이 옵션이 없는 경우, 통상의 my.cnf 파일로부터 모든 것이 검색된다.

  • --example

    옵션 설정 파일예를 표시한다.

  • --help

    헬프를 출력해 종료한다.

  • --log=...

    로그 파일.로그 파일의 완전 패스와 이름.주의: 이 파일이 존재하고 있으면, 모든 것이 로그 파일에 기록된다.

  • --mysqladmin=...

    서버의 슛다운에 사용한다 mysqladmin 바이너리.

  • --mysqld=...

    사용한다 mysqld 바이너리.주의: 이 옵션에 mysqld_safe (을)를 지정할 수도 있다.이 옵션은,mysqld 에게 건네진다.환경 변수 PATH 하지만 mysqld (을)를 지정해 있는 것을 확인하는지,mysqld_safe (을)를 수정한다.

  • --no-log

    로그를 로그 파일이 아니고,stdout 에 쓴다.디폴트에서는 로그 파일이 유효하게 되어 있다.

  • --password=...

    mysqladmin 의 유저의 패스워드.

  • --tcp-ip

    Unix 소켓이 아니고,TCP/IP 포토로 각 MySQL 서버에 접속한다.이것은, 서버의 정?~ (와)과 보고에 영향을 준다.소켓 파일이 없어도 서버는 아직 실행 가능하지만,TCP/IP 포토 경유의 액세스에 한정된다.디폴트에서는,Unix 소켓이 사용된다.

  • --user=...

    mysqladmin 의 MySQL 유저.

  • --version

    버젼 번호를 출력해 종료한다.

mysqld_multi 에 관한 보충 코멘트

  • mysqladmin 프로그램등을 사용해 mysqld 서비스를 정?~ 한다 MySQL 유저의 패스워드와 유저명이, 액세스 되는 모든 데이터 디렉토리(mysql 데이타베이스에의 액세스) 용무의 패스워드와 유저명과 같은 것을 확인하는 것.또, 유저에게 SHUTDOWN 권한이 있는 일도 확인한다.많은 데이터 디렉토리가 있어,MySQL root 유저의 패스워드가 다른 많은 mysql 데이타베이스가 있는 경우, 이하와 같이 같은 패스워드를 사용하는 공통 multi_admin 유저를 작성할 수 있다.이하, 그 예.

    shell> mysql -u root -S /tmp/mysql.sock -proot_password -e
"GRANT SHUTDOWN ON *.* TO multi_admin@localhost IDENTIFIED BY 'multipass'"

    See 항4.3.6. 「권한 시스템은 어떻게 기능할까」 . 각 데이터 디렉토리에서 실행하는 각 mysqld 에 대해서 이 커멘드를 실행할 필요가 있다(소켓 -S=... 마셔 변경한다).

  • pid-file (은)는,mysqld_safe (을)를 사용해 mysqld (을)를 기동하는 경우(예를 들어,--mysqld=mysqld_safe ) 매우 중요하다.모든 mysqld 에 독자적인 pid-file 하지만 필요하다.여기서 mysqld (을)를 직접 사용하지 않고 mysqld_safe (을)를 사용하는 이점은,kill -9 그리고 송신되는 시그널이나, 그 외 부분화 에러(MySQL 그럼 발생해선 안 되는 것이지만) 등에 의해 mysqld 프로세스가 강제 종료했을 경우에서도,mysqld_safe 하지만 모든 mysqld 프로세스를 `` 보호'' 해, 재기동하는 것이다.주의: mysqld_safe 스크립트는, 특정의 장소로부터 기동하는 것이 필요한 경우가 있다.즉,mysqld_multi (을)를 개시하기 전에, 특정의 디렉토리에 cd 하는 것이 필요한 경우가 있다.기동시에 문제가 발생했을 경우는,mysqld_safe 스크립트를 확인.특히 이하의 행을 체크한다.

    --------------------------------------------------------------------------
MY_PWD=`pwd`
Check if we are starting this relative (for the binary release)
if test -d /data/mysql -a -f ./share/mysql/english/errmsg.sys -a \
-x ./bin/mysqld
--------------------------------------------------------------------------

    See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 .

    상기의 테스트가 잘 되지 않으면, 문제가 발생할 가능성이 있다.

  • 같은 데이터 디렉토리에서, 복수의 mysqld 서버를 개시하는 것에는 위험이 수반한다.완전하게 이해 하고 있지 않는 한, 다른 데이터 디렉토리를 사용해야 한다.

  • 각 mysqld 에 대해서 다른 소켓 파일과 TCP/IP 포토가 지정되어 있는 것이 필요하다.

  • 1 번째와 5 번째의 mysqld 그룹은, 예로부터 의도적으로 제외되어 있다.설정 파일에는 ' 공행' (을)를 넣어 두는 것이 가능하다.이것에 의해, 유연성이 높아진다.mysqlds 의 개시와 정?~ 의 순서는, 설정 파일로의 순서에 의존한다.

  • 이 프로그램으로 GNR (을)를 사용해 특정 그룹을 참조하려면 , 그룹명의 최후로 번호를 지정한다. 예를 들어,[mysqld17] (이)라는 이름의 그룹의 GNR 하 17 이다.

  • mysqld 그리고 --user 옵션을 사용하려면 ,mysqld_multi 스크립트를 Unix root 유저로서 실행할 필요가 있다.설정 파일에 이 옵션이 있어도 문제는 없다.슈퍼 유저가 아닌 유저가 자신의 Unix 어카운트로 mysqld (을)를 개시하고 있는 경우에서도, 경고가 발생하는 것만으로 있다. 중요: 특정의 mysqld 프로세스를 개시하고 있다 그 Unix 유저가 pid-file 및 데이터 디렉토리의 독해 권한과 써 권한을(데이터 디렉토리의 경우는 실행권한도) 가지고 있는 것을 확인하는 것.완전하게 이해 하고 있지 않는 한, 이 목적으로 Unix root 어카운트를 사용해선 안 된다 .

  • 최대중요: mysqld 서버에게 건네지는 옵션의 의미, 및 mysqld 프로세스를 개별적으로 사용하는 것이 바람직하다 이유 (을)를 이해해 두는 것.같은 데이터 디렉토리에서 복수의 서버를 기동해도, 스레드시스템에서는 퍼포먼스의 향상은 바랄 수 없다 .

See 항4.2. 「같은 머신상에서 복수의 MySQL 서버를 실행한다」 .

이하,mysqld_multi 의 설정이 포함되는 설정 파일의 예입니다.

# 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
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]
socket     = /tmp/mysql.sock3
port       = 3308
pid-file   = /usr/local/mysql/var3/hostname.pid3
datadir    = /usr/local/mysql/var3
language   = /usr/local/share/mysql/swedish
user       = monty

[mysqld4]
socket     = /tmp/mysql.sock4
port       = 3309
pid-file   = /usr/local/mysql/var4/hostname.pid4
datadir    = /usr/local/mysql/var4
language   = /usr/local/share/mysql/estonia
user       = tonu

[mysqld6]
socket     = /tmp/mysql.sock6
port       = 3311
pid-file   = /usr/local/mysql/var6/hostname.pid6
datadir    = /usr/local/mysql/var6
language   = /usr/local/share/mysql/japanese
user       = jani

See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

4.8.4. myisampack (MySQL 압축 독해 전용 테이블 제네레이터)

myisampack 하 MyISAM 테이블의 압축에,pack_isam 하 ISAM 테이블의 압축에 사용합니다.ISAM 테이블은 폐?~ 되고 있기 때문에, 여기에서는 myisampack 에 한해서 이야기를 진행시킵니다만,myisampack 에 대해 설명하는 것은 모두,pack_isam 에도 들어맞읍니다.

myisampack (은)는, 테이블내의 각 컬럼을 개별적으로 압축합니다.테이블을 열었을 때, 컬럼을 전개하기 위한 정보가 메모리에 읽힙니다.이것에 의해, 개개의 레코드에 액세스 할 때의 퍼포먼스가 향상합니다.이 경우,Stacker (을)를 MS-DOS 그리고 사용할 때와 같이 큰 디스크 블록이 아니고,1 개의 레코드만을 해동하는 것만으로 끝납니다. 통상,myisampack (은)는 데이터 파일을 40% ~ 70% 압축합니다.

MySQL (은)는, 압축 테이블로 메모리맙핑(mmap() )(을)를 사용해,mmap() 하지만 기능하지 않는 경우는, 통상의 파일의 독해/ 기입 사용법으로 돌아옵니다.

이하에 주의해 주세요.

  • 팩 후, 테이블은 읽어내 전용이 된다.이것은,CD 에 팩 된 테이블에의 액세스 등, 독해 전용으로 좋다는 판단으로부터 그렇게 해서 있는 것이다.팩 된 테이블에의 써 기능의 실현도 개발 계획에는 들어가 있지만, 우선 순위는 높지 않다.

  • myisampack (은)는,BLOB 컬럼 또는 TEXT 컬럼도 팩 할 수 있다. 낡다 pack_isam (ISAM 테이블용)에서는 팩 할 수 없다.

myisampack (은)는 이하의 커멘드로 기동합니다.

shell> myisampack [options] filename ...

각 파일명은, 인덱스(.MYI ) 파일명이 되어 있는 것이 필요합니다.데이터 디렉토리가 커런트 디렉토리가 아니면, 파일의 패스를 지정해 주세요..MYI 확장자(extension)는 생략 가능합니다.

myisampack (은)는, 이하의 옵션을 서포트합니다.

  • -b, --backup

    테이블의 백업을 tbl_name.OLD (으)로서 작성한다.

  • -#, --debug=debug_options

    디버그 로그를 출력한다.debug_options 문자열에는,'d:t:o,filename' 하지만 자주(잘) 사용된다.

  • -f, --force

    테이블이 커져 버리는 경우, 임시 파일이 존재하는 경우에서도 테이블의 팩을 강제한다.myisampack (은)는, 테이블의 압축중,tbl_name.TMD (이)라는 이름의 임시 파일을 생성한다.myisampack (을)를 강제 종료했을 경우,.TMD 파일이 삭제되지 않는 경우가 있다.통상,tbl_name.TMD 하지만 있으면,myisampack (은)는 에러를 출력해 종료한다.--force (을)를 사용하면, 임시 파일의 유무에 관련되지 않고 myisampack (은)는 테이블을 팩 한다.

  • -?, --help

    헬프 메세지를 표시해 종료한다.

  • -j big_tbl_name, --join=big_tbl_name

    커멘드 라인으로 지정된 모든 테이블을 결합해 1 개의 테이블 big_tbl_name (으)로 한다.결합하는 테이블은 모두, 동일(같은 컬럼명, 같은 형태, 같은 인덱스등)의 테이블인 것이 필요 이다.

  • -p #, --packlength=#

    레코드 헤이안중기의 연호존사이즈를 아르바이트 단위로 지정한다.값은 1 ,2 , 또는 3 인 것이 필요.myisampack (은)는, 모든 레코드를 1 ,2 , 또는 3 아르바이트의 길이 포인터로 보존한다.대부분의 경우,myisampack (은)는 파일을 팩 하기 전에, 올바른 길이를 판단할 수 있지만, 팩중에 한층 더 짧아도 좋은 것을 인식하는 경우가 있다.이 경우,myisampack (은)는, 다음 번 같은 파일을 팩 할 경우에, 레코드장을 짧게 할 수 있다고 하는 메모를 출력한다.

  • -s, --silent

    사일런트 모드.에러 발생시만 출력한다.

  • -t, --test

    실제로는 테이블을 팩 하지 않고, 팩 테스트만 실행한다.

  • -T dir_name, --tmp_dir=dir_name

    텐포라리테이불을 쓰는 디렉토리를 지정한다.

  • -v, --verbose

    장황 모드.팩의 진척 및 결과에 관한 정보를 출력한다.

  • -V, --version

    버젼 정보를 표시해 종료한다.

  • -w, --wait

    테이블이 사용중의 경우, 대기해 재시행한다.mysqld 서버가 --skip-external-locking 옵션으로 기동 강요하는 경우, 패킹 프로세스중에 테이블이 갱신될 가능성이 있으면,myisampack (을)를 사용해서는 안된다.

이하의 커멘드 순서는, 일반적인 테이블 압축을 나타내고 있습니다.

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
Data records:              1192  Deleted blocks:              0
Datafile: Parts:           1192  Deleted data:                0
Datafile pointer (bytes):     2  Keyfile pointer (bytes):     2
Max datafile length:   54657023  Max keyfile length:   33554431
Recordlength:               834
Record format: Fixed length

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
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
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
87.14%

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
Data records:              1192  Deleted blocks:              0
Datafile: Parts:           1192  Deleted data:                0
Datafilepointer (bytes):      3  Keyfile pointer (bytes):     1
Max datafile length:   16777215  Max keyfile length:     131071
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
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
10    132   35     no endspace, not_always, no empty    6     9
11    167   4      zerofill(1)                          2     9
12    171   16     no endspace, not_always, no empty    5     9
13    187   35     no endspace, not_always, no empty    6     9
14    222   4      zerofill(1)                          2     9
15    226   16     no endspace, not_always, no empty    5     9
16    242   20     no endspace, not_always              8     9
17    262   20     no endspace, no empty                8     9
18    282   20     no endspace, no empty                5     9
19    302   30     no endspace, no empty                6     9
20    332   4      always zero                          2     9
21    336   4      always zero                          2     9
22    340   1                                           3     9
23    341   8      table-lookup                         9     0
24    349   8      table-lookup                        10     0
25    357   8      always zero                          2     9
26    365   2                                           2     9
27    367   2      no zeros, zerofill(1)                2     9
28    369   4      no zeros, zerofill(1)                2     9
29    373   4      table-lookup                        11     0
30    377   1                                           3     9
31    378   2      no zeros, zerofill(1)                2     9
32    380   8      no zeros                             2     9
33    388   4      always zero                          2     9
34    392   4      table-lookup                        12     0
35    396   4      no zeros, zerofill(1)               13     9
36    400   4      no zeros, zerofill(1)                2     9
37    404   1                                           2     9
38    405   4      no zeros                             2     9
39    409   4      always zero                          2     9
40    413   4      no zeros                             2     9
41    417   4      always zero                          2     9
42    421   4      no zeros                             2     9
43    425   4      always zero                          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
48    481   79     no endspace, no empty               15     9
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
56    827   4      no zeros, zerofill(2)                2     9
57    831   4      no zeros, zerofill(1)                2     9

이하,myisampack 에 의해서 출력되는 정보에 대해 설명합니다.

  • normal

    팩이 사용되지 않았던 컬럼의 수.

  • empty-space

    값이 공백 스페이스만의 컬럼의 수.이것들은 1 비트가 된다.

  • empty-zero

    값이 바이너리의 0 만의 컬럼의 수.이것들은 1 비트가 된다.

  • empty-fill

    정수 컬럼으로, 그 형태의 전바이트 범위를 차지하지 않은 컬럼의 수.이것들은, 보다 작은 형태에 변환된다(예를 들어,INTEGER 컬럼을 MEDIUMINT (으)로 변경한다).

  • pre-space

    수치 컬럼 가운데, 값의 선두에 공백 스페이스가 있는 컬럼의 수.이 경우, 각 치에는 선두 스페이스의 카운트가 포함된다.

  • end-space

    말미에 공백 스페이스가 있는 컬럼의 수.이 경우, 각 치에는 말미 스페이스의 카운트가 포함된다.

  • table-lookup

    컬럼에 복수의 값이 조금 밖에 없고, 하프맨 압축 전에 ENUM 에 변환되었다.

  • zero

    모든 값이 제로인 컬럼의 수.

  • Original trees

    하프맨 트리의 초기 번호.

  • After join

    영역을 절약하기 위해서 트리를 결합한 후에 남은, 독립한 하프맨 트리의 수.

테이블이 압축된 다음에 myisamchk -dvv (을)를 실행하면, 각 필드에 대한 이하의 추가 정보가 출력됩니다.

  • Type

    필드형에는 이하의 기술아이가 들어온다.

    • constant

      모든 레코드가 같은 값.

    • no endspace

      엔드 스페이스를 보존하지 않는다.

    • no endspace, not_always

      엔드 스페이스를 보존하지 않고, 모든 값으로 엔드 스페이스 압축을 실행하지 않는다.

    • no endspace, no empty

      엔드 스페이스를 보존하지 않는다.공백치를 보존하지 않는다.

    • table-lookup

      컬럼이 ENUM 에 변환되었다.

    • zerofill(n)

      치내의 가장 중요한 n 아르바이트는 항상 0 그래서, 보존하지 않는다.

    • no zeros

      제로를 보존하지 않는다.

    • always zero

      0 값을 1 비트로 보존한다.

  • Huff tree

    필드에 관련지을 수 있고 있는 하프맨 트리.

  • Bits

    하프맨 트리로 사용되고 있는 비트수.

pack_isam 또는 myisampack (을)를 실행 후,isamchk 또는 myisamchk (을)를 실행해 인덱스를 재생성할 필요가 있습니다.이 때,MySQL Optimizer의 효율성을 올리기 위해서, 인덱스 블록을 소트 해, 통계를 작성해 둘 수도 있습니다.

myisamchk -rq --analyze --sort-index table_name.MYI
isamchk   -rq --analyze --sort-index table_name.ISM

팩 된 테이블을 MySQL 데이타베이스 디렉토리에 인스톨 한 후,mysqladmin flush-tables (을)를 실행하고,mysqld 하지만 새로운 테이블을 사용해 기동하도록 해 주세요.

팩 된 테이블을 unpack 하려면 ,--unpack 옵션으로 isamchk 또는 myisamchk (을)를 실행합니다.

4.8.5. mysqld-max (확장 mysqld 서버)

mysqld-max (은)는, 이하의 옵션으로 콘피개 되었다 MySQL 서버(mysqld )입니다.

옵션 | 코멘트
--with-server-suffix=-max | -max 사픽스를 mysqld 버젼 문자열에 추가.
--with-innodb | InnoDB 테이블의 서포트(MySQL 3.23 마셔).
--with-bdb | Berkeley DB (BDB ) 테이블의 서포트.
CFLAGS=-DUSE_SYMDIR | Windows (으)로의 기호 연결의 서포트.

InnoDB 서포트를 유효화하는 옵션은,MySQL 3.23 에서만 필요합니다.MySQL 4 이?~ 그럼,InnoDB (은)는 디폴트로 포함되어 있습니다.

MySQL-Max 바이너리는 http://www.mysql.com/downloads/mysql-max-4.0.html 에 있습니다.

Windows MySQL 바이너리 디스트리뷰션에는, 표준 mysqld.exe 바이너리와 mysqld-max.exe 바이너리의 양쪽 모두가 포함되어 있습니다. http://www.mysql.com/downloads/mysql-4.0.html . See 항2.1.1. 「Windows 에의 MySQL 의 인스톨」 .

주의: BerkeleyDB (BDB )(은)는 모든 플랫폼에서 이용할 수 있는 것은 아니고,BDB (을)를 서포트하지 않는다 Max 바이너리도 있습니다.서포트되고 있는 테이블형을 확인하려면 , 이하의 쿼리를 실행합니다.

mysql> SHOW VARIABLES LIKE "have_%";
+------------------+----------+
| Variable_name    | Value    |
+------------------+----------+
| have_bdb         | NO       |
| have_crypt       | YES      |
| have_innodb      | YES      |
| have_isam        | YES      |
| have_raid        | NO       |
| have_symlink     | DISABLED |
| have_openssl     | NO       |
| have_query_cache | YES      |
+------------------+----------+

2 번째의 컬럼의 값에는 이하의 의미가 있습니다.

치 | 의미
YES | 옵션은 유효화 되고 있어 사용 가능하다.
NO | MySQL (은)는, 이 옵션을 서포트하도록(듯이)는 컴파일 되어 있지 않다.
DISABLED | mysqld 하지만 --skip-xxxx 그리고 기동했는지, 이 옵션을 유효화하기 위해서 필요한 옵션이 부족한 상태로 mysqld 하지만 기동했기 때문에,xxxx 옵션이 무효가 되어 있다.이 경우,hostname.err 파일에, 이 옵션이 무효가 되어 있는 이유가 나타난다.

주의: InnoDB 테이블을 MySQL 버젼 3.23 그리고 작성할 수 있도록 하려면 , 적어도 innodb_data_file_path 옵션을 포함하도록(듯이) 스타트 업 옵션을 편집한다 필요 하지만 있습니다. See 항7.5.2. 「MySQL 버젼 3.23 (으)로의 InnoDB 」 .

BDB 테이블의 퍼포먼스를 향상시키려면 , 그것을 위한 설정 옵션도 몇개인가 추가하는 것이 필요합니다. See 항7.6.3. 「BDB 기동 옵션」 .

mysqld_safe (은)는 자동적으로,-max 사픽스의 mysqld 바이너리를 개시하려고 합니다.이 기능에 의해, 기존의 인스톨로 다른 mysqld 바이너리를 간단하게 테스트할 수 있습니다.필요한 옵션으로 configure (을)를 실행해, 신규 mysqld 바이너리를, 낡다 mysqld 바이너리와 같은 디렉토리에 mysqld-max (으)로서 인스톨 합니다. See 항4.8.2. 「mysqld_safe (mysqld 의 나팔)」 .

Linux 그럼,MySQL-Max RPM (은)는 상기의 mysqld_safe 기능을 사용합니다(이것은 단지 mysqld-max 실행 가능 파일을 인스톨 할 뿐(만큼)이므로,mysqld_safe 의 재기동시,mysqld_safe (은)는 자동적으로 이 실행 가능 파일을 사용합니다).

이하의 겉(표)는,MySQL-Max 바이너리에 어느 테이블형이 포함되어 있는지를 나타낸 것입니다.

시스템 | BDB | InnoDB
Windows/NT | Y | Y
AIX 4.3 | N | Y
HP-UX 11.0 | N | Y
Linux-Alpha | N | Y
Linux-Intel | Y | Y
Linux-IA-64 | N | Y
Solaris-Intel | N | Y
Solaris-SPARC | Y | Y
SCO OSR5 | Y | Y
UnixWare | Y | Y
Mac OS X | N | Y

주의: MySQL 4 이?~ , 디폴트로 InnoDB 하지만 포함되게 되었으므로,InnoDB 용무의 MySQL Max 서버는 필요없게 되었습니다.


4.9. MySQL 클라이언트 사이드의 스크립트와 유틸리티

4.9.1. 클라이언트 사이드의 스크립트와 유틸리티의 개요

mysqlclient 라이브러리를 사용해 서버와 통신한다 MySQL 클라이언트는 모두, 이하의 환경 변수를 사용합니다.

이름 | 설명
MYSQL_UNIX_PORT | 디폴트 소켓.localhost (와)과의 접속에 사용.
MYSQL_TCP_PORT | 디폴트의 TCP/IP 포토.
MYSQL_PWD | 디폴트의 패스워드.
MYSQL_DEBUG | 디버그시의 디버그 트레이스 옵션.
TMPDIR | 텐포라리테이불 또는 임시 파일이 작성되는 디렉토리.

MYSQL_PWD (을)를 사용하는 것은 안전한 방법이 아닙니다. See 항4.3.8. 「MySQL 서버에의 접속」 .

Unix 그럼,mysql 클라이언트는,MYSQL_HISTFILE 환경 변수로 지정된 파일을 사용해 커멘드 라인 이력을 보존합니다.역사 파일의 디폴트치는 $HOME/.mysql_history 입니다.여기서,$HOME 하 HOME 환경 변수의 값입니다. See 부록 F. 환경 변수 .

쿼리 이력이 기록된 파일을 필요로 하지 않는 경우에는, 우선,.mysql_history 하지만 존재하는 경우는 그것을 삭제해, 다음에 이하의 어느쪽이든을 실행합니다.

  • MYSQL_HISTFILE 변수를 /dev/null (으)로 설정한다.이 설정을 로그인 마다 유효하게 하려면 , 이 설정을 쉘의 스타트 업 파일에 입력한다.

  • .mysql_histfile (을)를 /dev/null 에의 기호 연결로서 작성한다.

    shell> ln -s /dev/null $HOME/.mysql_history

    이것은,1 번실행하는 것만으로 좋다.

모든 MySQL 프로그램이 많은 다양한 옵션을 사용합니다.그러나, 모든 MySQL 프로그램에 --help 옵션이 준비되어 있어 이 옵션을 사용하는 것으로써, 그 프로그램의 모든 옵션의 설명을 표시할 수 있습니다.예를 들어,mysql --help (을)를 시험해 보세요.

모든 표준 클라이언트 프로그램의 디폴트 옵션은, 옵션 설정 파일로 덧쓰기할 수 있습니다. 항4.1.2. 「my.cnf 옵션 설정 파일」 .

이하의 일람은, 클라이언트 사이드의 MySQL 프로그램을 간단하게 설명한 것입니다.

  • msql2mysql

    mSQL 프로그램을 MySQL (으)로 변환하는 셸 스크립트.모든 케이스에 대응하는 것은 아니지만, 변환시에 최초로 시행해야할 것이다.

  • mysql

    대화적으로 쿼리를 입력하거나 배치 모드로 파일로부터 쿼리를 실행하기 위한 커멘드 라인 툴. See 항4.9.2. 「mysql (커멘드 라인 툴)」 .

  • mysqlcc

    이 프로그램은, 서버와 대화하기 위한 그래피컬 인터페이스를 제공한다. See 항4.9.3. 「mysqlcc (MySQL 컨트롤 센터)」 .

  • mysqlaccess

    호스트, 유저, 및 데이타베이스의 편성의 액세스권한을 체크하는 스크립트.

  • mysqladmin

    데이타베이스를 작성 또는 파기하거나 권한 테이블을 재차 읽어들이거나 테이블을 디스크에 플래시 하거나 로그 파일을 재차 여는 등의 관리 조작을 실행하는 유틸리티.mysqladmin (은)는, 서버로부터 버젼 정보, 프로세스 정보, 및 스테이터스 정보를 취득하기 위해서도 사용할 수 있다. See 항4.9.4. 「mysqladmin (MySQL 서버의 관리)」 .

  • mysqlbinlog

    바이너리 로그로부터 쿼리를 읽어내기 위한 유틸리티.크래쉬시, 낡은 백업으로 리커버리 하기 위해서 사용할 수 있다. See 항4.9.5. 「mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)」 .

  • mysqldump

    MySQL 데이타베이스를 SQL 스테이트먼트 또는 탭 단락의 텍스트 파일로서 파일에 덤프 한다.Igor Romanenko 제공의 확장 프리 소프트웨어. See 항4.9.7. 「mysqldump (테이블 구조와 데이터의 덤프)」 .

  • mysqlimport

    LOAD DATA INFILE (을)를 사용해 각 테이블에 텍스트 파일을 임포트 한다. See 항4.9.9. 「mysqlimport (텍스트 파일로부터의 데이터의 임포트)」 .

  • mysqlshow

    데이타베이스, 테이블, 컬럼, 및 인덱스에 관한 정보를 표시한다.

  • replace

    msql2mysql 에 의해서 사용되는 유틸리티 프로그램.다만, 그 이외에도 사용 범위는 넓다.replace (은)는, 파일이나 표준 입력내의 문자열을 변경한다.유한 스테이트 머신을 사용하고, 최초로 긴 문자열이 맞대어를 실시한다.문자열의 교체에 사용할 수 있다.예를 들어 이하의 커멘드는, 지정 파일내의 a (와)과 b (을)를 바꿔 넣는다.

    shell> replace a b b a -- file1 file2 ...

4.9.2. mysql (커멘드 라인 툴)

mysql (은)는 심플한 SQL 쉘입니다(GNU readline 기능이 있다).대화 형식과 비대화 형식을 서포트하고 있습니다.대화 형식에서 사용했을 경우, 쿼리 결과는 ASCII 테이블 형식에서 표시됩니다.비대화 형식(필터등)에서 사용했을 경우, 결과는 탭 단락 형식에서 표시됩니다(출력 형식은, 커멘드 라인 옵션으로 변경할 수 있습니다).이하와 같이 간단하게에 스크립트를 실행할 수 있습니다.

shell> mysql database < script.sql > output.tab

클라이언트로 메모리 부족에 의한 문제가 발생했을 경우,--quick 옵션을 사용합니다.이것에 의해,mysql 하 mysql_store_result() (이)가 아니고,mysql_use_result() (을)를 사용해 결과 세트를 취득합니다.

mysql 의 사용은 매우 간단합니다.mysql database 또는 mysql --user=user_name --password=your_password database (와)과 같이, 개시합니다.SQL 스테이트먼트를 입력해,‘; ＇,'\g' , 또는 '\G' 그리고 종료해 Enter 키를 누릅니다.

mysql (은)는, 이하의 옵션을 서포트합니다.

  • -?, --help

    헬프를 표시해 종료한다.

  • -A, --no-auto-rehash

    자동 리핫슈를 실행하지 않는다.테이블 및 필드를 완성시키려면 ,' 리핫슈' (을)를 실행할 필요가 있다.이 옵션에 의해,mysql 의 기동이 빨라진다.

  • --prompt=...

    mysql prompt를 지정의 형식으로 설정한다.

  • -b, --no-beep

    에러시의 beep음을 오프로 한다.

  • -B, --batch

    결과를 탭으로 단락지어, 각 레코드가 1 행이 되도록(듯이) 출력한다.역사 파일에서는 사용하지 않는 것.

  • --character-sets-dir=...

    캐릭터 세트가 격납되고 있는 디렉토리.

  • -C, --compress

    서버/ 클라이언트 프로토콜로 압축을 사용한다.

  • -#, --debug[=...]

    디버그 로그.디폴트는 'd:t:o,/tmp/mysql.trace' .

  • -D, --database=...

    사용하는 데이타베이스.이 옵션은 주로,my.cnf 파일로 사용한다.

  • --default-character-set=...

    디폴트의 캐릭터 세트를 설정한다.

  • -e, --execute=...

    커멘드를 실행해 종료한다(--batch (와)과 같은 출력).

  • -E, --vertical

    쿼리(레코드)를 세로 방향에 출력한다.이 옵션을 지정하지 않아도, 스테이트먼트를 \G 그리고 종료하면, 똑같이 출력할 수 있다.

  • -f, --force

    SQL 에러가 발생해도 속행한다.

  • -g, --no-named-commands

    이름 커멘드가 무효가 된다.\* 형식만 사용한다.또는 세?~ 코론(‘; ＇)(으)로 끝나는 행의 최초로 마셔 이름 커멘드를 사용한다.버젼 10.9 이?~ , 클라이언트는 기동시에, 디폴트로 이 옵션을 유효 (으)로 하게 되어 있다.다만,-g 옵션에서는, 롱 형식의 커멘드는 최초의 행으로부터 기능한다.

  • -G, --enable-named-commands

    이름 커멘드가 유효 (이)가 된다.롱 형식의 커멘드도 쇼트의 \* 커멘드와 같이, 유효하게 된다.

  • -i, --ignore-space

    함수명의 뒤의 스페이스를 무시한다.

  • -h, --host=...

    지정의 호스트에게 접속한다.

  • -H, --html

    HTML 출력을 생성한다.

  • -X, --xml

    XML 출력을 생성한다.

  • -L, --skip-line-numbers

    에러의 행 번호를 쓰지 않는다.이것은, 에러 메세지가 포함되는 결과 파일을 비교할 때에 사용한다.

  • --no-pager

    pager를 무효로 해,stdout 에 출력한다.대화식 헬프(\h )도 참조.

  • --no-tee

    출력 파일을 무효로 한다.대화식 헬프(\h )도 참조.

  • -n, --unbuffered

    쿼리 마다 버퍼를 플래시 한다.

  • -N, --skip-column-names

    결과에 컬럼명을 쓰지 않는다.

  • -O, --set-variable=name=value

    변수에 값을 설정한다.--help 에 의해, 변수가 일람표 나타난다. 주의: --set-variable=name=value 및 -O name=value 구문은,MySQL 4.0 그리고 폐?~ .대신에 --name=value (을)를 사용하는 것.

  • -o, --one-database

    디폴트의 데이타베이스만을 갱신한다.바이너리 로그내의 다른 데이타베이스를 갱신하지 않는 경우에 사용한다.

  • --pager[=...]

    출력 타입.디폴트는 ENV 변수의 PAGER 이다.유효한 pager는,less ,more ,cat [> filename] 등.대화식 헬프(\h )도 참조.이 옵션은 배치 모드에서는 무효.pager는 Unix 에서만 동작한다.

  • -p[password], --password[=...]

    서버 접속시에 사용하는 패스워드.패스워드를 커멘드 라인으로 지정하지 않았던 경우, prompt가 표시된다.주의: 쇼트 형식의 -p (을)를 사용하는 경우, 옵션과 패스워드의 사이에 스페이스를 들어갈 수 있어선 안 된다.

  • -P port_num, --port=port_num

    접속에 사용한다 TCP/IP 포토 번호.

  • --protocol=(TCP | SOCKET | PIPE | MEMORY)

    사용하는 접속 프로토콜을 지정한다.MySQL 4.1 그리고 도입.

  • -q, --quick

    결과를 캐쉬하지 않고, 행 마다 출력한다.출력이 중단했을 경우, 서버가 늦어질 가능성이 있다.역사 파일은 사용하지 않는다.

  • -r, --raw

    이스케이프 변환 없이 컬럼치를 써낸다.--batch (와)과 함께 사용.

  • --reconnect

    접속이 없어졌을 경우, 서버에의 재접속을 자동적으로 1 번만 시행한다.

  • -s, --silent

    사일런트 모드.

  • -S --socket=...

    접속에 사용하는 소켓 파일.

  • -t --table

    겉(표) 형식에서 출력.이것은, 비배치 모드로의 디폴트이다.

  • -T, --debug-info

    종료시에 디버그 정보를 출력한다.

  • --tee=...

    출력 파일에 모두 출력한다.대화식 헬프(\h )도 참조.배치 모드에서는 무효.

  • -u, --user=#

    커런트 유저가 아닌 경우의 로그인 유저.

  • -U, --safe-updates[=#], --i-am-a-dummy[=#]

    키를 사용한다 UPDATE (와)과 DELETE 마셔 허가한다.이 옵션에 대해서는, 상세를 다음에 설명한다.이 옵션이 my.cnf 파일에 포함되어 있는 경우,--safe-updates=0 그리고 리셋트 할 수 있다.

  • -v, --verbose

    장황 출력(-v -v -v 그리고 표출력 형식이 된다).

  • -V, --version

    버젼 정보를 출력해 종료한다.

  • -w, --wait

    접속이 절단 되었을 경우, 정?~ 하지 않고 대기해 재시행한다.

-O 또는 --set-variable 에는, 이하의 변수도 설정할 수 있습니다.주의: --set-variable=name=value 및 -O name=value 구문은,MySQL 4.0 그리고 폐?~ .대신에 --name=value (을)를 사용해 주세요.

변수명 | 디폴트 | 설명
connect_timeout | 0 | 접속 타임 아웃의 초수.
local-infile | 0 | LOAD DATA INFILE 의 LOCAL 기능의 무효화(0 ) 또는 유효화(1 ).
max_allowed_packet | 16777216 | 서버간으로의 송수신 가능한 최대 패킷장.
net_buffer_length | 16384 | TCP/IP 및 소켓 접속용 버퍼.
select_limit | 1000 | --safe-updates 사용시의 SELECT 의 자동 제한.
max_join_size | 1000000 | --safe-updates 사용시에 1 회의 결합으로 취급하는 레코드의 자동 제한.

mysql 클라이언트가 서버에 쿼리를 송신하고 있을 때 접속이 절단 되었을 경우, 클라이언트는 자동적으로 재접속을 시행해, 쿼리를 재차 송신합니다.주의: 재접속에 성공했을 경우에서도, 최초의 접속이 종료한 시점에서, 전회의 세션 오브젝트(텐포라리테이불, 유저 변수, 세션 변수)는 모두 없어져 있습니다.따라서, 상기의 동작에는 리스크가 수반합니다.예를 들어, 이하의 예의 경우, 유저가 깨닫지 못한 동안에 서버가 슛다운 해, 재기동하고 있습니다.

mysql> set @a=1;
Query OK, 0 rows affected (0.05 sec)

mysql> insert into t values(@a);
ERROR 2006: MySQL server has gone away
No connection. Trying to reconnect...
Connection id:    1
Current database: test

Query OK, 1 row affected (1.30 sec)

mysql> select * from t;
+------+
| a    |
+------+
| NULL |
+------+
1 row in set (0.05 sec)

이 경우,@a 유저 변수는 접속의 절단과 동시에 없어져 재접속 후는 미정도리가 되어 있습니다.이 리스크를 회피하려면 ,mysql 클라이언트를 --disable-reconnect 옵션으로 개시합니다.

커멘드 라인으로 'help' (을)를 입력하면,mysql 하지만 서포트하는 커멘드를 출력할 수 있습니다.

mysql> help

MySQL commands:
help      (\h)    Display this text.
?         (\h)    Synonym for `help'.
clear     (\c)    Clear command.
connect   (\r)    Reconnect to the server.
                  Optional arguments are db and host.
delimiter (\d)    Set query delimiter.
edit      (\e)    Edit command with $EDITOR.
ego       (\G)    Send command to mysql server,
                  display result vertically.
exit      (\q)    Exit mysql. Same as quit.
go        (\g)    Send command to mysql server.
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.

edit ,nopager ,pager ,system 의 각 커멘드는 Unix 에서만 동작합니다.

status 커멘드를 실행하면, 접속 정보와 사용하고 있는 서버의 정보를 취득할 수 있습니다.--safe-updates 모드로 status (을)를 실행하면, 쿼리에 영향을 준다 mysql 변수치도 출력됩니다.

초심자에게 편리한 스타트 업 옵션으로서--safe-updates (MySQL 버젼 3.23.11 그리고 도입)이 있습니다(또는, 어디선가 DELETE FROM table_name (을)를 실행하고 있지만 WHERE 마디를 잊은 유저의 경우는 --i-am-a-dummy ).이 옵션을 사용하면, 접속시,mysql (은)는 이하의 커멘드를 MySQL 서버에 송신합니다.

SET SQL_SAFE_UPDATES=1,SQL_SELECT_LIMIT=#select_limit#,
    SQL_MAX_JOIN_SIZE=#max_join_size#"

여기서 #select_limit# (와)과 #max_join_size# (은)는,mysql 커멘드 라인으로부터 설정할 수 있는 변수입니다. See 항5.5.6. 「SET 구문」 .

효과는 이하대로입니다.

  • WHERE 부분에 키 제약이 없으면,UPDATE 스테이트먼트 또는 DELETE 스테이트먼트를 실행할 수 없다.다만,LIMIT (을)를 사용하면 UPDATE/DELETE (을)를 강제 실행할 수 있다.

    UPDATE table_name SET not_key_column=# WHERE not_key_column=# LIMIT 1;

  • 큰 결과는 모두, 자동적으로 #select_limit# 레코드의 제한을 받는다.

  • #max_join_size 이상의 레코드를 체크할 필요가 있을 듯 하는 SELECT 스테이트먼트는 정?~ 한다.

mysql 클라이언트에 관한 힌트

데이터에 따라서는, 횡방향이 아니고, 세로 방향에 표시하는 편이 보기 쉬운 경우가 있습니다.예를 들어 개행을 포함한 긴 텍스트에서는, 세로 방향에 출력하는 것이 읽기 쉬워집니다.

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:

Thimble> Hi.  I think this is a good idea.  Is anyone familiar with UTF-8
Thimble> or Unicode? Otherwise, I'll put this on my TODO list and see what
Thimble> happens.

Yes, please do that.

Regards,
Monty
     file: inbox-jani-1
     hash: 190402944
1 row in set (0.09 sec)

로그에는,tee 옵션을 사용할 수 있습니다.tee 하 --tee=... 옵션으로 기동할 수 있습니다.또는,tee 커멘드로 대화식에 커멘드 라인으로부터 기동할 수도 있습니다.화면에 표시되는 데이터는 모두, 지정의 파일에도 기록됩니다.이것은, 디버그 목적으로도 매우 도움이 됩니다.tee (은)는,notee 그리고 커멘드 라인으로부터 무효로 할 수 있습니다.tee (을)를 다시 실행하면, 로그가 재개됩니다.파라미터 없음의 경우, 전회의 파일이 사용됩니다.주의: tee (은)는, 커멘드 마다(다음의 커멘드를 기다리는 커멘드 라인이 표시되기 직전에), 결과를 파일에 플래시 합니다.

Unix 의 less ,more , 그 외 같은 프로그램의 대화식 모드로 결과를 참조하거나 검색하려면 ,--pager[=...] 옵션을 사용합니다.인수가 없는 경우,mysql 클라이언트는 PAGER 환경 변수를 찾고,pager (을)를 그 값으로 설정합니다. pager (은)는,pager 커멘드로 대화식 커멘드 라인으로부터 개시할 수 있어nopager 커멘드로 무효로 할 수 있습니다.커멘드는 임의의 인수를 취해,pager 하지만 그 값으로 설정됩니다.pager 커멘드는 인수 없이도 호출할 수 있습니다만,--pager 옵션이 사용되고 있는 것이 필요하게 됩니다.그렇게 하지 않으면,pager (은)는 디폴트로 stdout (이)가 됩니다.pager (은)는,Windows 에는 없다 popen() 함수를 사용하기 위해(때문에),Unix 에서만 유효합니다.Windows 그럼 대신에 tee 옵션을 사용할 수 있습니다.다만 상황에 따라서는,pager 만큼 편리하지는 않습니다.

pager 에 관한 힌트

  • 파일에의 기입에 사용할 수 있다.

    mysql> pager cat > /tmp/log.txt

    이것으로, 결과가 파일에게만 출력된다.또, 사용하고 싶은 프로그램의 임의의 옵션을 pager 그리고 건네줄 수 있다.

    mysql> pager less -n -i -S

  • 상기 예의 -S 옵션에 주목.이것은, 결과를 참조할 때에 매우 도움이 된다.이 옵션을 횡방향의 표시(\g 또는 ‘; ＇ 그리고 커멘드를 종료), 및 세로 방향의 표시(\G 그리고 커멘드를 종료)로 시험해 보면 안다.매우 폭의 넓은 결과 세트는 화면상에서 보기 나쁜 경우가 있어,-S 옵션을 less (으)로 설정하는 것으로써, 대화식의 less 그리고, 화면폭보다 긴 행이 다음의 행까지 계속 되는 일 없이, 결과 세트를 왼쪽에서 오른쪽으로 표시할 수 있다.이 방법에 의해, 결과 세트를 매우 보기 쉽게 할 수 있다.대화식의 less 그리고,-S 에 의해 이 모드의 온 오프를 바꿀 수 있다.less 에 관한 상세한 것에 대하여는 'h' (을)를 참조.

  • 결과의 처리에는, 매우 복잡한 방법을 조합할 수 있다.이하의 예에서는, 결과를,/dr1 (와)과 /dr2 에 마운트되고 있다 2 개가 다른 하드 디스크상의 2 개가 다른 디렉토리에 있다 2 개의 파일에 기록해, 화면상에서는 less 그리고 표시한다.

    mysql> pager cat | tee /dr1/tmp/res.txt | \
tee /dr2/tmp/res2.txt | less -n -i -S

상기의 2 개의 함수를 조합하는 것도 가능합니다.tee (을)를 유효하게 해,pager (을)를 'less' (으)로 설정하는 것으로써,Unix 'less' 그리고 결과를 참조하면서 동시에 1 개의 파일에 모든 것을 기록할 수 있습니다.pager 그리고 사용된다 Unix 의 tee (와)과 mysql 클라이언트의 편입 tee 하지만 있습니다만, 편입 tee 하 tee 하지만 이용할 수 없는 경우에서도 사용할 수 있습니다.또, 편입 tee (은)는 화면에서 출력된 것 모든 것을 로그 파일에 기록합니다만,pager 그리고 사용된다 Unix tee (은)는 그만큼 많은 일을 기록하지 않습니다.마지막으로, 대화식 tee (분)편이 온/ 오프를 바꾸기 쉽다고 하는 점이 있습니다.파일에 무엇인가를 기록하고 싶지만, 가끔 기능을 오프에도 하고 싶다고 하는 경우에 편리합니다.

MySQL 버젼 4.0.2 (으)로부터,mysql 커멘드 라인 클라이언트로 prompt를 변경할 수 있게 되었습니다.

이하의 prompt 옵션을 사용할 수 있습니다.

옵션 | 설명
\v | mysqld 버젼
\d | 사용중의 데이타베이스
\h | 접속 호스트
\p | 접속 포토
\u | 유저명
\U | 완전 유저명@ 호스트
\\ | ‘\ ＇
\n | 신규 개행
\t | 탭
\ | 스페이스
\_ | 스페이스
\R | 24 시간 형식(0 ~ 23 )
\r | 표준시간 형식(1 ~ 12 )
\m | 분
\y | 2 형년
\Y | 4 형년
\D | 완전 일자 형식
\s | 초
\w | 3 문자 형식으로의 요일(Mon ,Tue 등)
\P | am/pm
\o | 숫자에 의한 달
\O | 3 문자 형식으로의 달(Jan ,Feb 등)
\c | 커멘드 실행 마다 카운트 하는 카운터

‘\ ＇ 에 그 이외의 문자가 계속 되면, 단지 그 문자가 됩니다.

prompt는 이하의 장소에서 설정할 수 있습니다.

  • 환경 변수

    MYSQL_PS1 환경 변수를 prompt 문자열로 설정할 수 있다.다음에 예를 나타낸다.

    shell> export MYSQL_PS1="(\u@\h) [\d]> "

  • my.cnf , .my.cnf

    MySQL 설정 파일의 mysql 그룹에서 prompt 옵션을 설정할 수 있다.다음에 예를 나타낸다.

    [mysql]
prompt=(\u@\h) [\d]>\_

  • 커멘드 라인

    mysql 의 커멘드 라인으로 --prompt 옵션을 설정할 수 있다. 다음에 예를 나타낸다.

    shell> mysql --prompt="(\u@\h) [\d]> "

(user@host) [database]>

  • 대화식

    prompt (또는 \R )(을)를 사용해 대화식으로 prompt를 변경할 수도 있다.다음에 예를 나타낸다.

    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>

4.9.3. mysqlcc (MySQL 컨트롤 센터)

mysqlcc (MySQL 컨트롤 센터)는 플랫폼에 의존하지 않는 클라이언트로,MySQL 데이터 베이스 서버에의 그래피컬 유저 인터페이스(GUI )(을)를 제공합니다.대화 사용을 서포트해, 구문 강조나 탭 완성의 기능도 포함됩니다.데이타베이스, 테이블, 및 서버의 관리도 할 수 있습니다.

현재,mysqlcc 하 Windows 플랫폼과 Linux 플랫폼에서 동작합니다.

mysqlcc 하 MySQL 디스트리뷰션에는 포함되어 있지 않습니다만,http://www.mysql.com/downloads/ (으)로부터 다운로드할 수 있습니다.

mysqlcc (은)는, 이하의 옵션을 서포트합니다.

  • -?, --help

    헬프를 표시해 종료한다.

  • -b, --blocking_queries

    쿼리의 블록을 사용한다.

  • -C, --compress

    서버/ 클라이언트 프로토콜로 압축을 사용한다.

  • -c, --connection_name=name

    --server 의 동의어.

  • -d, --database=...

    사용하는 데이타베이스.이것은 주로,my.cnf 파일로 사용.

  • -H, --history_size=#

    쿼리 윈도우의 역사 사이즈.

  • -h, --host=...

    지정의 호스트에게 접속한다.

  • -p[password], --password[=...]

    서버 접속시에 사용하는 패스워드.패스워드를 커멘드 라인으로 지정하지 않았던 경우, prompt가 표시된다.주의: 쇼트 형식의 -p (을)를 사용하는 경우, 옵션과 패스워드의 사이에 스페이스를 들어갈 수 있어선 안 된다.

  • -g, --plugins_path=name

    MySQL 컨트롤 센터의 플러그 인이 놓여져 있는 디렉토리의 패스.

  • -P port_num, --port=port_num

    접속에 사용한다 TCP/IP 포토 번호.

  • -q, --query

    기동시에 쿼리 윈도우를 연다.

  • -r, --register

    기동시에 'Register Server' 다이얼로그를 연다.

  • -s, --server=name

    MySQL 컨트롤 센터의 접속명.

  • -S --socket=...

    접속에 사용하는 소켓 파일.

  • -y, --syntax

    구문 강조 및 완성을 유효화.

  • -Y, --syntax_file=name

    완성하는 구문 파일.

  • -T, --translations_path=name

    MySQL 컨트롤 센터 번역이 놓여져 있는 디렉토리의 패스.

  • -u, --user=#

    커런트 유저가 아닌 경우의 로그인 유저.

  • -V, --version

    버젼 정보를 출력해 종료한다.

-O 또는 --set-variable 에는 이하의 변수도 설정할 수 있습니다. 주의: --set-variable=name=value 및 -O name=value 구문은,MySQL 4.0 그리고 폐?~ 되었습니다.대신에 --name=value (을)를 사용해 주세요.

변수명 | 디폴트 | 설명
connect_timeout | 0 | 접속 타임 아웃까지의 초수.
local-infile | 0 | LOAD DATA INFILE 의 LOCAL 기능의 무효화(0 ) 또는 유효화(1 ).
max_allowed_packet | 16777216 | 서버간으로의 송수신 가능한 최대 패킷장.
net_buffer_length | 16384 | TCP/IP 및 소켓 접속용 버퍼.
select_limit | 1000 | --safe-updates 사용시의 SELECT 의 자동 제한.
max_join_size | 1000000 | --safe-updates 사용시에 1 회의 결합으로 취급하는 레코드의 자동 제한.

4.9.4. mysqladmin (MySQL 서버의 관리)

관리 조작을 실행하기 위한 유틸리티입니다.구문은 이하대로입니다.

shell> mysqladmin [OPTIONS] command [command-option] command ...

사용하고 있는 버젼의 mysqladmin 하지만 서포트하는 옵션 일람을 표시하려면 ,mysqladmin --help (을)를 실행합니다.

현재의 mysqladmin (은)는 이하의 커멘드를 서포트하고 있습니다.

  • create databasename

    새로운 데이타베이스를 작성한다.

  • drop databasename

    데이타베이스와 그 모든 테이블을 삭제한다.

  • extended-status

    서버로부터 확장 스테이터스 메세지를 취득한다.

  • flush-hosts

    캐쉬된 모든 호스트를 플래시 한다.

  • flush-logs

    모든 로그를 플래시 한다.

  • flush-tables

    모든 테이블을 플래시 한다.

  • flush-privileges

    권한 테이블을 재독 봐(reload (와)과 같다).

  • kill id,id,...

    mysql 스레드를 강제 종료한다.

  • password

    신규 패스워드를 설정한다.구패스워드를 신규 패스워드로 변경한다.

  • ping

    mysqld 하지만 가동중인지 어떤지를 확인한다.

  • processlist

    서버로 아크티브스레드를 일람표시 한다.SHOW PROCESSLIST 스테이트먼트와 같다.--verbose 옵션이 지정되어 있는 경우,SHOW FULL PROCESSLIST 의 출력을 닮은 결과가 출력된다.

  • reload

    권한 테이블을 재차 읽어들인다.

  • refresh

    모든 테이블을 플래시 해, 로그 파일을 닫아 또 연다.

  • shutdown

    서버를 슛다운 한다.

  • slave-start

    스레이브레프리케이션스레드를 개시한다.

  • slave-stop

    스레이브레프리케이션스레드를 정?~ 한다.

  • status

    서버로부터 짧은 스테이터스 메세지를 취득한다.

  • variables

    이용 가능한 변수를 출력한다.

  • version

    서버로부터 버젼 정보를 취득한다.

커멘드는 모두, 각각 독자적인 프레픽스로 단축 가능합니다.다음에 예를 나타냅니다.

shell> mysqladmin proc stat
+----+-------+-----------+----+-------------+------+-------+------+
| Id | User  | Host      | db | Command     | Time | State | Info |
+----+-------+-----------+----+-------------+------+-------+------+
| 6  | monty | localhost |    | Processlist | 0    |       |      |
+----+-------+-----------+----+-------------+------+-------+------+
Uptime: 10077  Threads: 1  Questions: 9  Slow queries: 0
Opens: 6 Flush tables: 1  Open tables: 2
Memory in use: 1092K  Max memory used: 1116K

mysqladmin status 커멘드의 결과에는, 이하의 컬럼이 포함됩니다.

컬럼 | 설명
Uptime | MySQL 서버나 가동하고 있는 초수.
Threads | 아크티브스레드(클라이언트)의 수.
Questions | mysqld 하지만 기동하고 나서 클라이언트로부터 발행된 질문의 수.
Slow queries | long_query_time 초부터 시간이 걸린 쿼리. See 항4.10.5. 「슬로우 쿼리 로그」 .
Opens | mysqld 하지만 열린 테이블의 수.
Flush tables | flush ... ,refresh ,reload 의 각 커멘드의 회수.
Open tables | 현재 열려 있는 테이블의 수.
Memory in use | mysqld 코드에 의해서 직접 할당할 수 있고 있는 메모리(MySQL 하지만 --with-debug=full 그리고 컴파일 되고 있는 경우에게만 이용 가능).
Max memory used | mysqld 코드에 의해서 직접 할당할 수 있고 있는 최대 메모리(MySQL 하지만 --with-debug=full 그리고 컴파일 되고 있는 경우에게만 이용 가능).

소켓으로(즉 mysqld 하지만 실행하고 있는 컴퓨터로)mysqladmin shutdown (을)를 실행하면,mysqld 의 정상 종료를 확인하기 위해(때문에),mysqladmin 하 MySQL pid-file 하지만 삭제되는 것을 기다립니다.

4.9.5. mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)

mysqlbinlog 유틸리티를 사용하고, 바이너리 로그 파일(see 항4.10.4. 「바이너리 로그」 )(을)를 조사할 수 있습니다.

shell> mysqlbinlog hostname-bin.001

상기의 예에서는, 바이너리 로그 hostname-bin.001 에 포함되는 모든 쿼리가, 쿼리에 걸린 시간, 쿼리를 발행한 스레드의 ID , 쿼리 발행시의 타임 스탬프등의 정보와 함께 출력됩니다.

mysqlbinlog 의 출력을 mysql 클라이언트에 송신할 수 있습니다.이것은, 낡은 백업으로 리커버리 할 경우에 사용합니다(see 항4.5.1. 「데이타베이스의 백업」 ).

shell> mysqlbinlog hostname-bin.001 | mysql

또는

shell> mysqlbinlog hostname-bin.[0-9]* | mysql

또,mysqlbinlog 의 출력을 텍스트 파일에 리디렉트 해, 그 텍스트 파일을 편집(어떠한 이유로 실행하고 싶지 않은 쿼리를 삭제)해, 텍스트 파일로부터 mysql 에 대해서 쿼리를 실행할 수도 있습니다.

mysqlbinlog 에는 position=# 옵션이 있어, 바이너리 로그로의 오프셋이 # 이상의 쿼리만을 출력할 수 있습니다.

MySQL 서버로 실행하는 바이너리 로그가 다수 있는 경우, 단일의 MySQL 접속으로 실행하는 것이 안전합니다.이하는, 안전하지 않은 예입니다.

shell> mysqlbinlog hostname-bin.001 | mysql # DANGER!!
shell> mysqlbinlog hostname-bin.002 | mysql # DANGER!!

최초의 바이너리 로그에 CREATE TEMPORARY TABLE 하지만 포함되어2 번째의 바이너리 로그에 이 텐포라리테이불을 사용하는 쿼리가 포함되어 있으면, 문제가 발생합니다.최초의 mysql (이)가 종료되면, 텐포라리테이불이 파기되므로,2 번째의 mysql 하 ``unknown table'' (을)를 보고하게 됩니다.이것이, 모든 바이너리 로그를 단일의 접속으로 실행해야 할 이유입니다.텐포라리테이불을 사용하는 경우에는 특별히 조심해 주세요.2 개의 방법이 있습니다.

shell> mysqlbinlog hostname-bin.001 hostname-bin.002 | mysql

shell> mysqlbinlog hostname-bin.001 >  /tmp/queries.sql
shell> mysqlbinlog hostname-bin.002 >> /tmp/queries.sql
shell> mysql -e "source /tmp/queries.sql"

MySQL 4.0.14 이?~ ,mysqlbinlog (은)는, 바이너리 로그로부터 LOAD DATA INFILE (을)를 실행하기 위한 mysql 에 대한 적절한 입력을 제공할 수 있게 되어 있습니다.로드하는 데이터가 바이너리 로그에 포함되기 위해(이것은 MySQL 4.0 의 경우입니다.MySQL 3.23 그럼 로드 된 데이터가 바이너리 로그에 써지지 않기 때문에, 바이너리 로그의 내용을 실행하려면 오리지날 파일이 필요했습니다),mysqlbinlog (은)는 이 데이터를 임시 파일에 카피해 LOAD DATA INFILE 커멘드를 출력해,mysql 에 이 임시 파일을 로드 시킵니다.임시 파일이 작성되는 디폴트의 디렉토리는 텐포라리디레크트리입니다.이것은,mysqlbinlog 의 local-load 옵션으로 변경할 수 있습니다.

MySQL 4.1 보다 전은, 같은 이름의 텐포라리테이불을 사용하는 복수가 다른 스레드의 쿼리가 바이너리 로그에 포함되어 있었습니다.그 때문에, 이러한 쿼리가 섞여 있는 경우,mysqlbinlog 하 mysql 에 대해서 적절한 출력을 제공할 수 없었습니다.이것은,MySQL 4.1 그리고 해결되고 있습니다.

또,mysqlbinlog --read-from-remote-server (을)를 사용하고, 리모트 MySQL 서버로부터 직접 바이너리 로그를 읽어내는 것도 가능합니다.다만, 보다 간단하게, 가동중의 MySQL 서버에 바이너리 로그를 적용할 수 있듯이 하기 위한(해), 이것은 머지않아 폐?~ 할 예정입니다.

상세한 것에 대하여는,mysqlbinlog --help (을)를 실행해 주세요.

4.9.6. mysqlcheck (을)를 사용한 테이블의 보수와 크래쉬의 리커버리

MySQL 버젼 3.23.38 이?~ ,MyISAM 테이블의 체크 및 수복을 위해서 새로운 툴을 이용할 수 있게 되어 있습니다.myisamchk (와)과의 차이는,myisamchk 하지만, 서버가 실행하고 있지 않을 때에 사용하는데 대해,mysqlcheck 하 mysqld 서버가 실행하고 있을 때 사용합니다.테이블의 체크 또는 수복마다 서버를 정?~ 할 필요가 없어졌습니다.

mysqlcheck (은)는,MySQL 서버 커멘드 CHECK ,REPAIR ,ANALYZE , 및 OPTIMIZE (을)를 이용하고, 편리한 테이블의 보수 및 크래쉬로부터의 리커버리 방법을 제공합니다.

mysqlcheck (을)를 개시하는 방법은 3 개 있습니다.

shell> mysqlcheck [OPTIONS] database [tables]
shell> mysqlcheck [OPTIONS] --databases DB1 [DB2 DB3...]
shell> mysqlcheck [OPTIONS] --all-databases

데이타베이스 및 테이블의 선택에 관해서는,mysqldump (와)과 닮은 방법이 됩니다.

mysqlcheck 에는, 다른 클라이언트에는 없는 특수 기능이 있습니다.디폴트의 동작인 테이블 체크(-c )(을)를, 바이너리의 이름을 변경하는 것에 의해서 변경할 수 있습니다.디폴트로 테이블을 수복하는 툴이 필요하면,mysqlcheck (을)를 mysqlrepair 그렇다고 하는 새로운 이름으로 하드 드라이브에 카피하는지,mysqlrepair 에의 기호 연결을 작성해, 그 기호 연결의 이름을 mysqlrepair (으)로 합니다.mysqlrepair (을)를 기동하면, 디폴트로 테이블이 수복됩니다.

mysqlcheck 의 디폴트 동작을 변경하기 위해서 사용할 수 있는 이름은 이하대로입니다.

mysqlrepair:   The default option will be -r
mysqlanalyze:  The default option will be -a
mysqloptimize: The default option will be -o

이하,mysqlcheck 그리고 사용 가능한 옵션의 일람입니다.사용하고 있는 버젼으로의 서포트 상태를 확인하려면 ,mysqlcheck --help (을)를 실행해 주세요.

  • -A, --all-databases

    모든 데이타베이스를 체크한다.이것은, 모든 데이타베이스를 선택한 상태로 --databases (을)를 실행하는 것과 같다.

  • -1, --all-in-1

    테이블 마다 쿼리를 1 개씩 작성하는 것이 아니라, 데이타베이스 마다 정리해 모든 쿼리를 실행한다.테이블명은 콤마로 단락짓는다.

  • -a, --analyze

    지정한 테이블을 분석한다.

  • --auto-repair

    체크한 테이블이 파손하고 있었을 경우, 자동적으로 수복한다.파손한 테이블이 있었을 경우, 모든 테이블의 체크가 끝나고 나서 수복을 한다.

  • -#, --debug=...

    디버그 로그를 출력한다.이것은,'d:t:o,filename' 인 것이 많다.

  • --character-sets-dir=...

    캐릭터 세트가 격납되고 있는 디렉토리.

  • -c, --check

    테이블의 에러를 체크한다.

  • -C, --check-only-changed

    전회의 체크이?~ (으)로 변경된 테이블과 올바르게 닫혀지지 않았던 테이블만을 체크한다.

  • --compress

    서버/ 클라이언트 프로토콜로 압축을 사용한다.

  • -?, --help

    헬프 메세지를 표시해 종료한다.

  • -B, --databases

    몇개의 데이타베이스를 체크한다.주의: 여기에서는, 테이블을 지정하지 않는다.이름의 인수는 모두, 데이타베이스명으로서 다루어진다.

  • --default-character-set=...

    디폴트의 캐릭터 세트를 설정한다.

  • -F, --fast

    올바르게 닫혀지지 않았던 테이블만을 체크한다.

  • -f, --force

    SQL 에러가 발생해도 속행한다.

  • -e, --extended

    이 옵션을 CHECK TABLE (와)과 함께 사용하면, 테이블의 정합성이 100 퍼센트 보증되지만, 시간이 걸린다.

    이 옵션을 REPAIR TABLE (와)과 함께 사용했을 경우, 테이블의 확장 수복을 한다.다만, 시간이 걸릴 뿐만 아니라, 쓸데 없는 레코드도 많이 생성될 가능성이 있다.

  • -h, --host=...

    호스트에게 접속한다.

  • -m, --medium-check

    extended-check 보다 빠르지만, 전에러의 99.99% 밖에 찾아낼 수 없다.그러나, 대부분의 경우 이것으로 충분하다.

  • -o, --optimize

    테이블을 최적화한다.

  • -p, --password[=...]

    서버 접속시에 사용하는 패스워드.패스워드를 지정하지 않으면, prompt가 표시된다.

  • -P, --port=...

    TCP/IP 접속에 사용하는 포토 번호.

  • --protocol=(TCP | SOCKET | PIPE | MEMORY)

    사용하는 접속 프로토콜을 지정한다.MySQL 4.1 그리고 도입.

  • -q, --quick

    이 옵션을 CHECK TABLE (와)과 함께 사용하면, 부정 링크를 체크하는 레코드 스캔을 하지 않는다.이것이 최고 속도의 체크이다.

    이 옵션을 REPAIR TABLE (와)과 함께 사용하면, 인덱스 트리의 수복만이 실행된다.이것이, 최고 속도의 테이블의 수복이다.

  • -r, --repair

    대부분의 에러를 수복할 수 있다, 다만, 유니크 키가 일의가 아닌 에러에는 대응할 수 없다.

  • -s, --silent

    에러 메세지만을 출력한다.

  • -S, --socket=...

    접속에 사용하는 소켓 파일.

  • --tables

    --databases (-B ) 옵션을 덧쓰기한다.이 옵션의 뒤의 인수는 모두, 테이블명으로 보여진다.

  • -u, --user=#

    커런트 유저가 아닌 경우의 로그인 유저.

  • -v, --verbose

    다양한 단계의 정보를 출력한다.

  • -V, --version

    버젼 정보를 출력해 종료한다.

4.9.7. mysqldump (테이블 구조와 데이터의 덤프)

백업용의 데이타베이스 또는 데이타베이스의 집합을 덤프 하거나 다른 SQL 서버(MySQL 서버일 필요는 없다)에 데이터를 이동하기 위한 유틸리티입니다.덤프에는, 테이블 작성이나 입력을 위한 SQL 스테이트먼트가 포함됩니다.

같은 서버상에서 백업을 실시하는 경우에는,mysqlhotcopy 의 분의 사용을 고려해 주세요. See 항4.9.8. 「mysqlhotcopy (MySQL 의 데이타베이스와 테이블의 카피)」 .

    mysqldump [OPTIONS] database [tables]

인가  mysqldump [OPTIONS] --databases [OPTIONS] DB1 [DB2 DB3...]

인가  mysqldump [OPTIONS] --all-databases [OPTIONS]

테이블을 지정하지 않거나,--databases 옵션 또는 --all-databases 옵션을 사용하면, 데이타베이스 전체가 덤프 됩니다.

사용하고 있는 버젼의 mysqldump 하지만 서포트하는 옵션의 일람을 조회하려면 ,mysqldump --help (을)를 실행합니다.

주의: mysqldump (을)를 --quick 또는 --opt 없이 실행하면,mysqldump (은)는 결과를 덤프 하기 전에, 결과 세트 전체를 메모리에 로드합니다.이것은, 큰 데이타베이스를 덤프 할 때, 문제가 될 가능성이 있습니다.

주의: mysqldump 프로그램의 새로운 카피를 사용하고 있는 경우로, 매우 낡다 MySQL 서버에 읽어들이는 덤프를 실시할 때는,--opt 옵션 또는 -e 옵션은 사용하지 말아 주세요.

mysqldump (은)는, 이하의 옵션을 서포트합니다.

  • --add-locks

    각 테이블 덤프의 전에 LOCK TABLES (을)를 추가해, 후에 UNLOCK TABLE (을)를 추가한다(MySQL 에의 삽입을 빠르게하기 위해(때문에)).

  • --add-drop-table

    각 작성 스테이트먼트의 전에 drop table (을)를 추가한다.

  • -A, --all-databases

    모든 데이타베이스를 덤프 한다.이것은, 모든 데이타베이스를 선택한 상태로 --databases (을)를 실행하는 것과 같다.

  • -a, --all

    MySQL 고유의 작성 옵션을 모두 포함한다.

  • --allow-keywords

    키워드인 컬럼명의 작성을 인정한다.각 컬럼명의 선두에 테이블명을 덧붙이는 것이 필요.

  • -c, --complete-insert

    완전한 삽입 스테이트먼트(컬럼명도 지정)를 사용한다.

  • -C, --compress

    클라이언트와 서버의 양쪽 모두가 압축을 서포트하는 경우, 클라이언트와 서버간의 정보를 모두 압축한다.

  • -B, --databases

    몇개의 데이타베이스를 덤프 한다.주의: 여기에서는, 테이블명을 지정하지 않는다.이름의 인수는 모두, 데이타베이스명으로서 다루어진다. 출력되는 각 신규 데이타베이스의 전에 USE db_name; 하지만 추가된다.

  • --delayed

    INSERT DELAYED 커멘드로 레코드를 삽입한다.

  • -e, --extended-insert

    새로운 복수행 INSERT 구문을 사용한다(한층 더 컴팩트하고 빠른 삽입 스테이트먼트를 제공).

  • -#, --debug[=option_string]

    프로그램의 트레이스 사용(debug 목적).

  • --help

    헬프 메세지를 표시해 종료한다.

  • --fields-terminated-by=... ,
--fields-enclosed-by=... ,
--fields-optionally-enclosed-by=... ,
--fields-escaped-by=... ,
--lines-terminated-by=...

    이러한 옵션은 -T 옵션과 함께 사용한다.LOAD DATA INFILE 의 대응하는 마디와 같은 의미를 가진다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

  • -F, --flush-logs

    덤프를 개시하기 전에,MySQL 서버내의 로그 파일을 플래시 한다.주의: 이 옵션을 --all-databases (또는 -A ) 옵션과 조합해 사용했을 경우, 로그는 각 데이타베이스의 덤프 마다 플래시 된다.

  • -f, --force,

    테이블 덤프중에SQL 에러가 발생해도 속행한다.

  • -h, --host=..

    지정한 호스트의 MySQL 서버로부터 데이터를 덤프 한다.디폴트의 호스트는 localhost .

  • -l, --lock-tables.

    덤프를 개시하기 전에 모든 테이블을 잠근다.테이블은 READ LOCAL 그리고 락 되어MyISAM 테이블의 경우는 동시 삽입이 가능하게 된다.

    주의: 복수의 데이타베이스를 덤프 하는 경우,--lock-tables (은)는 각 데이타베이스를 개별적으로 잠근다.따라서, 이 옵션을 사용했을 경우, 데이타베이스간으로의 테이블의 논리 정합성은 보증되지 않는다. 다른 데이타베이스의 테이블은, 완전하게 다른 상태로 덤프 될 가능성이 있다.

  • -K, --disable-keys

    /*!40000 ALTER TABLE tb_name DISABLE KEYS */; 및 /*!40000 ALTER TABLE tb_name ENABLE KEYS */; 하지만 출력에 포함된다.이것에 의해, 인덱스가, 모든 데이터가 삽입 빗나간 후에 작성되기 위해,MySQL 4.0 서버에의 데이터의 로드가 빨라진다.

  • -n, --no-create-db

    CREATE DATABASE /*!32312 IF NOT EXISTS*/ db_name; 하지만 출력에 포함되지 않는다.--databases 옵션 또는 --all-databases 옵션을 지정했을 경우는, 상기의 행이 추가된다.

  • -t, --no-create-info

    테이블 작성 정보(CREATE TABLE 스테이트먼트)를 쓰지 않는다.

  • -d, --no-data

    테이블의 레코드 정보를 일절 쓰지 않는다.테이블의 구조만을 덤프 하는 경우, 매우 편리하다.

  • --opt

    --quick --add-drop-table --add-locks --extended-insert --lock-tables (와)과 같다.MySQL 서버에 읽어들이기 위한 최고 속도 덤프를 제공한다.

  • -pyour_pass, --password[=your_pass]

    서버 접속시에 사용하는 패스워드.'=your_pass' 부분을 지정하지 않으면,mysqldump 에 의해서 패스워드의 prompt가 표시된다.

  • -P, --port=...

    TCP/IP 접속에 사용하는 포토 번호.

  • --protocol=(TCP | SOCKET | PIPE | MEMORY)

    사용하는 접속 프로토콜을 지정한다.MySQL 4.1 그리고 도입.

  • -q, --quick

    쿼리를 버퍼 하지 않고,stdou 에 직접 덤프 한다.이것을 실시하려면 ,mysql_use_result() (을)를 사용한다.큰 덤프 시에 특히 편리하다.

  • -Q, --quote-names

    테이블명 및 컬럼명을 ‘` ＇ 문자로 둘러싼다.

  • -r, --result-file=...

    지정한 파일에의 직접 출력.이 옵션은 MSDOS 그리고 사용한다.개행 '\n' 하지만 '\n\r' (개행 + 복귀)에 변환되는 것을 막기 때문에 있다.

  • --single-transaction

    이 옵션은, 서버로부터 데이터를 덤프 하기 전에,BEGIN SQL 커멘드를 발행한다.이것은,InnoDB 테이블과 READ_COMMITTED 트랜잭션(transaction) 분리 레벨로 특별히 도움이 된다.이 모드에서는, 어느 어플리케이션도 블록 하는 일 없이,BEGIN 하지만 발행되었을 때의 데이타베이스의 정합한 상태를 덤프 할 수 있다.

    이 옵션을 사용할 때는, 트랜잭션(transaction) 테이블만이 정합 상태로 덤프 되는 것에 주의한다.예를 들어, 이 옵션으로 덤프 되었다 MyISAM 테이블 또는 HEAP 테이블은, 변경되고 있을 가능성이 있다.

    --single-transaction 옵션은 버젼 4.0.2 그리고 추가되었다. 이 옵션은 --lock-tables 옵션과는 상호 배타적이다.LOCK TABLES (은)는, 전의 트랜잭션(transaction)를 벌써 코?~ 트 하고 있기 때문에 있다.

  • -S /path/to/socket, --socket=/path/to/socket

    localhost (디폴트 호스트)(와)과의 접속에 사용하는 소켓 파일.

  • --tables

    --databases (-B ) 옵션을 덧쓰기한다.

  • -T, --tab=path-to-some-directory

    각 테이블에 대한다 SQL CREATE 커멘드가 포함된다 table_name.sql 파일, 및 각 테이블에 대한 데이터가 포함된다 table_name.txt 파일을 작성한다..txt 파일의 형식은,--fields-xxx 옵션 및 --lines--xxx 옵션에 근거한다. 주의: 이 옵션은,mysqldump 하지만 mysqld demon와 같은 머신으로 실행하고 있는 경우만 유효.FILE 권한이 있다 MySQL 어카운트를 사용하는 것이 필요.또,mysqld (을)를 실행하고 있는 로그인 유저 또는 그룹(통상은 유저 mysql , 그룹 mysql )에, 지정한 장소에서의 파일의 작성 및 써 권한이 필요.

  • -u user_name, --user=user_name

    서버와의 접속에 사용한다 MySQL 유저명.디폴트치는 유저의 Unix 로그인명.

  • -O name=value, --set-variable=name=value

    변수의 값을 지정한다.지정 가능한 변수는 이하에 나타낸다.주의: --set-variable=name=value 및 -O name=value 구문은,MySQL 4.0 그리고 폐?~ .대신에 --name=value (을)를 사용하는 것.

  • -v, --verbose

    장황 모드.프로그램의 실행 내용에 관한 상세 정보를 출력한다.

  • -V, --version

    버젼 정보를 출력해 종료한다.

  • -w, --where='where-condition'

    선택한 레코드만을 덤프 한다.주의: 반드시 인용부호로 둘러싸는 것.

    "--where=user='jimf'" "-wuserid>1" "-wuserid<1"

  • -X, --xml

    1 개의 데이타베이스를 정형식의 XML (으)로서 덤프.

  • -x, --first-slave

    모든 데이타베이스의 모든 테이블을 락.

  • --master-data

    --first-slave (와)과 거의 같지만,CHANGE MASTER TO 커멘드를 출력한다.마스터의 이 SQL 덤프를 사용해 슬레이브를 셋업 하고 있었을 경우, 이 커멘드에 의해, 다음에 마스터의 바이너리 로그내의 올바른 위치로부터 슬레이브를 개시시킬 수 있다.

  • -O net_buffer_length=#, 여기서 # < 16M

    복수 레코드 삽입 스테이트먼트를 작성했을 때에(--extended-insert 옵션 또는 --opt 옵션과 같이),mysqldump 하 net_buffer_length 까지의 길이의 레코드를 작성한다.이 변수를 크게 하는 경우에는,MySQL 서버의 max_allowed_packet 변수가 net_buffer_length 보다 큰 것을 확인한다.

일반적으로,mysqldump (은)는 데이타베이스 전체의 백업에 사용됩니다. See 항4.5.1. 「데이타베이스의 백업」 .

shell> mysqldump --opt database > backup-file.sql

이것을, 이하의 커멘드로 MySQL 에 되돌릴 수 있습니다.

shell> mysql database < backup-file.sql

또는

shell> mysql -e "source /path-to-backup/backup-file.sql" database

데이타베이스의 정보를 다른 MySQL 서버로 이동할 수도 있습니다.

shell> mysqldump --opt database | mysql ---host=remote-host -C database

1 개의 커멘드로 복수의 데이타베이스를 덤프 할 수 있습니다.

shell> mysqldump --databases database1 [database2 ...] > my_databases.sql

모든 데이타베이스를 선택하려면 , 이하와 같이 합니다.

shell> mysqldump --all-databases > all_databases.sql

4.9.8. mysqlhotcopy (MySQL 의 데이타베이스와 테이블의 카피)

mysqlhotcopy (은)는,LOCK TABLES ,FLUSH TABLES , 및 cp (또는 scp )(을)를 사용하고, 재빠르게 데이타베이스의 백업을 실시한다 Perl 스크립트입니다.이것은, 데이타베이스나 단일의 테이블의 백업을 실시하는 최고 속도의 방법입니다만, 데이타베이스 디렉토리가 있는 동일 머신에서만 실행할 수 없습니다. mysqlhotcopy (은)는,Unix 마셔, 및 MyISAM 테이블과 ISAM 테이블에서만 사용할 수 있습니다.

mysqlhotcopy db_name [/path/to/new_directory]

mysqlhotcopy db_name_1 ... db_name_n /path/to/new_directory

mysqlhotcopy db_name./regex/

mysqlhotcopy (은)는, 이하의 옵션을 서포트합니다.

  • -?, --help

    헬프 화면을 표시해 종료한다.

  • -u, --user=#

    데이타베이스에 로그인하는 유저.

  • -p, --password=#

    서버와의 접속에 사용하는 패스워드.

  • -P, --port=#

    로컬 서버와의 접속에 사용하는 포토.

  • -S, --socket=#

    로컬 서버와의 접속에 사용하는 소켓.

  • --allowold

    타겟이 존재하고 있는 경우도 정?~ 하지 않는다(_old (을)를 추가해 이름 변경).

  • --keepold

    완료시, 전의(이름을 변경한) 타겟을 삭제하지 않는다.

  • --noindices

    백업을 작게 해 처리 속도를 빠르게하기 위해(때문에), 카피에 완전 인덱스 파일을 포함하지 않는다. 인덱스는 다음에,myisamchk -rq. 그리고 재구성할 수 있다.

  • --method=#

    카피 방법(cp 또는 scp ).

  • -q, --quiet

    에러 이외는 출력하지 않는다.

  • --debug

    디버그를 유효하게 한다.

  • -n, --dryrun

    액션을 실행하지 않고 보고한다.

  • --regexp=#

    regexp (와)과 일치하는 이름의 데이타베이스를 모두 카피한다.

  • --suffix=#

    카피되는 데이타베이스명의 사픽스.

  • --checkpoint=#

    지정한 데이타베이스 테이블에 체크 포인트 엔트리를 삽입한다.

  • --flushlog

    모든 테이블이 락 된 후, 로그를 플래시 한다.

  • --tmpdir=#

    텐포라리디레크트리(/tmp 의 대신 ).

perldoc mysqlhotcopy (을)를 사용하고,mysqlhotcopy 의 한층 더 자세한 문서를 취득할 수 있습니다.

mysqlhotcopy (은)는, 옵션 설정 파일로부터 [client] 그룹 및 [mysqlhotcopy] 그룹을 읽어냅니다.

mysqlhotcopy (을)를 실행하려면 , 백업 디렉토리에의 써 액세스권과 카피하려고 하고 있는 테이블의 SELECT 권한, 및 MySQL RELOAD 권한(FLUSH TABLES (을)를 실행하기 위해(때문에))가 필요합니다.

4.9.9. mysqlimport (텍스트 파일로부터의 데이터의 임포트)

mysqlimport (은)는,LOAD DATA INFILE SQL 스테이트먼트의 커멘드 라인 인터페이스를 제공합니다.mysqlimport 의 대부분의 옵션이,LOAD DATA INFILE 의 옵션에 대응하고 있습니다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

mysqlimport (은)는 이하와 같이 해 기동합니다.

shell> mysqlimport [options] database textfile1 [textfile2 ...]

커멘드 라인으로 지정한 각 텍스트 파일에 대해서,mysqlimport (은)는, 파일명의 확장자(extension)를 삭제해, 그 결과를 사용하고, 어느 테이블에 파일의 내용을 임포트 할까 결정합니다.예를 들어,patient.txt ,patient.text , 및 patient (이)라는 이름의 파일은, 모두,patient (이)라는 이름의 테이블에 임포트 됩니다.

mysqlimport (은)는, 이하의 옵션을 서포트합니다.

  • -c, --columns=...

    이 옵션은, 콤마 단락의 필드명 일람을 인수로서 취한다. 필드 일람을 사용해 적절한 LOAD DATA INFILE 커멘드를 작성해, 그것을 MySQL 에 건네준다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

  • -C, --compress

    클라이언트와 서버의 양쪽 모두가 압축을 서포트하는 경우, 클라이언트와 서버간의 정보를 모두 압축한다.

  • -#, --debug[=option_string]

    프로그램의 트레이스 사용(debug 목적).

  • -d, --delete

    텍스트 파일을 임포트 하기 전에 테이블을 비운다.

  • --fields-terminated-by=... ,
--fields-enclosed-by=... ,
--fields-optionally-enclosed-by=... ,
--fields-escaped-by=... ,
--lines-terminated-by=...

    이러한 옵션은,LOAD DATA INFILE 의 대응하는 마디와 같은 의미를 가진다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

  • -f, --force

    에러를 무시한다.예를 들어, 텍스트 파일용의 테이블이 존재하지 않는 경우에서도, 나머지의 파일의 처리를 속행한다.--force (을)를 지정하지 않는 경우, 테이블이 존재하지 않으면 mysqlimport (은)는 종료한다.

  • --help

    헬프 메세지를 표시해 종료한다.

  • -h host_name, --host=host_name

    지정한 호스트의 MySQL 서버에 데이터를 임포트 한다.디폴트의 호스트는 localhost .

  • -i, --ignore

    --replace 옵션의 설명을 참조.

  • --ignore-lines=n

    데이터 파일의 최초의 n 행을 무시한다.

  • -l, --lock-tables

    텍스트 파일을 처리하기 전에, 모든 테이블에의 기입을 잠근다.이것에 의해, 그 서버상의 모든 테이블이 동기화 된다.

  • -L, --local

    클라이언트로부터 입력 파일을 읽어낸다.디폴트에서는,localhost (디폴트 호스트)에 접속했을 경우, 텍스트 파일은 서버에 있으면 상정된다.

  • -pyour_pass, --password[=your_pass]

    서버와의 접속에 사용하는 패스워드.'=your_pass' 부분을 지정하지 않으면,mysqlimport 에 의해서 패스워드의 prompt가 표시된다.

  • -P port_num, --port=port_num

    접속에 사용한다 TCP/IP 포토 번호.

  • --protocol=(TCP | SOCKET | PIPE | MEMORY)

    사용하는 접속 프로토콜을 지정한다.MySQL 4.1 그리고 도입.

  • -r, --replace

    --replace 옵션 및 --ignore 옵션은, 기존 레코드의 값과 중복 하는 유니크 키치를 가지는 입력 레코드의 처리를 제어한다.--replace (을)를 지정했을 경우, 신규 레코드가 같은 유니크 키치를 가지는 기존 레코드를 덧쓰기한다.IGNORE (을)를 지정하면, 유니크 키치가 기존의 레코드의 값과 중복 하는 입력 레코드는 무시된다.어느쪽이나 지정하지 않는 경우, 중복 키치가 검출되면 에러가 되어, 텍스트 파일의 나머지의 부분이 무시된다.

  • -s, --silent

    사일런트 모드.에러 발생시만 출력한다.

  • -S /path/to/socket, --socket=/path/to/socket

    localhost (디폴트 호스트)(와)과의 접속에 사용하는 소켓 파일.

  • -u user_name, --user=user_name

    서버와의 접속에 사용한다 MySQL 유저명.디폴트치는 유저의 Unix 로그인명.

  • -v, --verbose

    장황 모드.프로그램의 실행 내용에 관한 상세를 출력한다.

  • -V, --version

    버젼 정보를 출력해 종료한다.

이하는,mysqlimport 사용의 예입니다.

$ mysql --version
mysql  Ver 9.33 Distrib 3.22.25, for pc-linux-gnu (i686)
$ uname -a
Linux xxx.com 2.2.5-15 #1 Mon Apr 19 22:21:09 EDT 1999 i586 unknown
$ mysql -e 'CREATE TABLE imptest(id INT, n VARCHAR(30))' test
$ ed
a
100     Max Sydow
101     Count Dracula
.
w imptest.txt
32
q
$ 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
$ mysqlimport --local test imptest.txt
test.imptest: Records: 2  Deleted: 0  Skipped: 0  Warnings: 0
$ mysql -e 'SELECT * FROM imptest' test
+------+---------------+
| id   | n             |
+------+---------------+
|  100 | Max Sydow     |
|  101 | Count Dracula |
+------+---------------+

4.9.10. mysqlshow (데이타베이스, 테이블, 및 컬럼의 표시)

mysqlshow (을)를 사용하면, 기존의 데이타베이스, 테이블, 및 컬럼을 재빠르게 표시할 수 있습니다.

mysql 프로그램에서는,SHOW 커멘드로 같은 정보를 표시할 수 있습니다. See 항4.6.8. 「SHOW 구문」 .

mysqlshow (은)는 이하와 같이 해 기동합니다.

shell> mysqlshow [OPTIONS] [database [table [column]]]

  • 데이타베이스를 지정하지 않으면, 일치하는 모든 데이타베이스가 표시된다.

  • 테이블을 지정하지 않으면, 데이타베이스내에서 일치하는 모든 데이타베이스가 표시된다.

  • 컬럼을 지정하지 않으면, 테이블내에서 일치하는 컬럼 및 컬럼형이 모두 표시된다.

주의: 새롭다 MySQL 버젼에서는, 유저가 권한을 가지고 있는 데이타베이스, 테이블, 컬럼만이 표시됩니다.

마지막 인수에 쉘 또는 SQL 와일드 카드(* ,? ,% , 또는 _ )(이)가 포함되는 경우, 와일드 카드에 일치하는 것만이 표시됩니다.데이타베이스명에 언더 스코아가 포함되는 경우, 테이블 및 컬럼을 올바르게 취득하기 위해서, 이것들을 백래쉬로 이스케이프 처리해 주세요(Unix 쉘에 따라서는 2 개 필요합니다).'*' 하 SQL '%' 와일드 카드에,'?' 하 SQL '_' 와일드 카드에 변환됩니다.이것은,_ (을)를 포함한 있는 테이블의 컬럼을 표시하려고 했을 때에, 혼란이 생깁니다.이 경우,mysqlshow (은)는, 이 패턴에 일치하는 테이블명을 표시합니다. 이것은, 커멘드 라인의 마지막에 % (을)를 다른 인수로서 추가하는 것으로, 간단하게 해결할 수 있습니다.

4.9.11. mysql_config (클라이언트를 컴파일하기 위한 컴파일 옵션의 취득)

mysql_config (은)는,MySQL 클라이언트를 컴파일 해, 그 클라이언트를 MySQL 에 접속하는 방법에 대한 도움이 되는 정보를 제공합니다.

mysql_config (은)는, 이하의 옵션을 서포트합니다.

  • --cflags

    인클루드 파일을 찾아내기 위한 컴파일러 플래그, 및 중요한 컴파일 플래그와 콘바이라 정의.이것들은 libmysqlclient 라이브러리를 컴파일 할 경우에 사용된다.

  • --include

    MySQL 인클루드 파일을 찾아내기 위한 컴파일 옵션(통상은 이 대신에 --cflags (을)를 사용한다).

  • --libs

    MySQL 클라이언트 라이브러리에 링크할 필요가 있는 라이브러리와 옵션.

  • --libs_r

    스레드세이후 MySQL 클라이언트 라이브러리에 링크할 필요가 있는 라이브러리와 옵션.

  • --socket

    디폴트의 소켓명.MySQL (을)를 콘피개 할 경우에 정의된다.

  • --port

    디폴트의 포토 번호.MySQL (을)를 콘피개 할 경우에 정의된다.

  • --version

    MySQL 디스트리뷰션의 버젼 번호와 버젼.

  • --libmysqld-libs or --embedded

    MySQL 편입 서버에 링크할 필요가 있는 라이브러리와 옵션.

옵션을 지정하지 않고 mysql_config (을)를 실행하면, 서포트하는 모든 옵션과 모든 옵션치가 출력됩니다.

shell> mysql_config
Usage: /usr/local/mysql/bin/mysql_config [OPTIONS]
Options:
        --cflags         [-I/usr/local/mysql/include/mysql -mcpu=pentiumpro]
        --include        [-I/usr/local/mysql/include/mysql]
        --libs           [-L/usr/local/mysql/lib/mysql -lmysqlclient -lz -lcrypt -lnsl -lm -L/usr/lib -lssl -lcrypto]
        --libs_r         [-L/usr/local/mysql/lib/mysql -lmysqlclient_r -lpthread -lz -lcrypt -lnsl -lm -lpthread]
        --socket         [/tmp/mysql.sock]
        --port           [3306]
        --version        [4.0.16]
        --libmysqld-libs [-L/usr/local/mysql/lib/mysql -lmysqld -lpthread -lz -lcrypt -lnsl -lm -lpthread -lrt]

이 스크립트를 사용해 이하와 같이 지정하는 것으로,MySQL 클라이언트를 컴파일 할 수 있습니다.

CFG=/usr/local/mysql/bin/mysql_config
sh -c "gcc -o progname `$CFG --cflags` progname.c `$CFG --libs`"

4.9.12. perror (에러 코드의 설명)

MySQL (은)는, 대부분의 시스템 에러에 대해서, 내부의 텍스트 메세지에 가세해message ... (errno: #) 또는 message ... (Errcode: #) 의 몇개의 형식의 시스템 에러 코드를 출력합니다.

에러 코드의 의미를 조사하려면 , 시스템의 문서를 참조하는지,perror 유틸리티를 사용합니다.

perror (은)는, 시스템 에러 코드, 또는 MyISAM/ISAM 스토리지 엔진(테이블 핸들러) 에러 코드의 설명을 출력합니다.

perror (은)는 이하와 같이 해 기동합니다.

shell> perror [OPTIONS] [ERRORCODE [ERRORCODE...]]

Example:

shell> perror 13 64
Error code  13:  Permission denied
Error code  64:  Machine is not on the network

주의: 에러 메세지는, 대부분이 시스템 의존입니다.

4.9.13. 텍스트 파일로부터 SQL 커멘드를 실행하는 방법

mysql 클라이언트는, 통상, 이하와 같이 대화적으로 사용합니다.

shell> mysql database

그러나,SQL 커멘드를 파일에 입력하고, 그 파일로부터 mysql 에 읽어내게 하는 것도 가능합니다.이것을 실시하려면 , 실행하는 커멘드를 포함한 텍스트 파일 text_file (을)를 작성합니다. 그리고, 이하와 같이 mysql (을)를 기동합니다.

shell> mysql database < text_file

텍스트 파일을 USE db_name 스테이트먼트로 개시할 수도 있습니다.이 경우, 커멘드 라인으로 데이타베이스명을 지정할 필요는 없습니다.

shell> mysql < text_file

벌써 mysql (을)를 실행중의 경우,source 커멘드를 사용해 SQL 스크립트를 실행할 수 있습니다.

mysql> source filename;

배치 모드의 상세한 것에 대하여는, 항3.5. 「배치 모드로의 mysql 의 사용」 (을)를 참조해 주세요.


4.10. MySQL 로그 파일

MySQL 에는 몇개의 종류의 로그 파일이 있어,mysqld 안에서 무엇이 발생하고 있을까 조사할 수 있습니다.

로그 파일 | 설명
에러 로그 | mysqld 의 기동, 실행, 및 정?~ 그리고 발생한 문제.
isam 로그 | ISAM 테이블에의 변경이 모두 기록.isam 코드의 디버그에만 사용.
일반 쿼리 로그 | 접속의 정보와 실행된 쿼리.
갱신 로그 | 폐?~ .데이터를 변경한 모든 스테이트먼트를 보존.
바이너리 로그 | 무엇인가를 변경한 모든 스테이트먼트를 보존.replication에도 사용.
슬로우 로그 | long_query_time 초부터 시간이 걸린 쿼리, 또는 인덱스를 사용하지 않았던 쿼리를 모두 보존.

로그는 모두,mysqld 데이터 디렉토리에 있습니다.mysqld 그리고 로그 파일을 재차 열려면(혹은 새로운 로그로 전환한다) ,FLUSH LOGS (을)를 실행합니다. See 항4.6.4. 「FLUSH 구문」 .

4.10.1. 에러 로그

에러 로그 파일에는,mysqld 의 기동 시각과 정?~ 시각, 및 실행중에 발생한 에러에 관한 정보가 기록됩니다.

mysqld 하지만 이상종료(ABEND) 해 mysqld_safe 하지만 mysqld (을)를 재기동할 필요가 있는 경우,mysqld_safe (은)는 이 파일에 restarted mysqld 행을 씁니다.자동 체크 또는 자동 수복이 필요한 테이블을 mysqld 하지만 찾아냈을 경우, 경고도 기록됩니다.

일부의 operating system에서는,mysqld 하지만 이상종료(ABEND) 한 개소의 스택 트레이스가 에러 로그에 기록됩니다.이것을 사용하면,mysqld 하지만 어느 시점에서 이상종료(ABEND) 했는지 압니다. See 항E.1.4. 「스택 트레이스의 사용」 .

MySQL 4.0.10 이?~ ,mysqld 하지만 에러 로그 파일을 보존하는 장소를 --log-error[=filename] 옵션으로 지정할 수 있게 되어 있습니다.파일명을 지정하지 않으면,mysqld 하 Unix 그럼 mysql-data-dir/'hostname'.err (을)를,Windows 그럼 \mysql\data\mysql.err (을)를 사용합니다. flush logs (을)를 실행하면, 낡은 파일에는 --old 의 프리픽스가 붙어,mysqld 하지만 하늘의 신규 로그 파일을 작성합니다.

구 MySQL 버젼에서는, 에러 로그 처리는 mysqld_safe 에 의해서 행해져 에러 파일은 'hostname'.err 에 리디렉트 됩니다.이 파일명은,--err-log=filename 옵션으로 변경할 수 있습니다.

--log-error (을)를 지정하지 않는 경우, 또는 --console 옵션을 사용했을 경우에는, 에러는 stderr (단말)에 써집니다.

Windows 그럼,--console (을)를 지정하지 않으면, 출력은 항상 .err 파일에 써집니다.

4.10.2. 일반 쿼리 로그

mysqld 안에서 무엇이 발생하고 있을까 확인하고 싶은 경우에는,--log[=file] 옵션을 사용해 mysqld (을)를 기동합니다.이것에 의해, 모든 접속과 쿼리가 로그 파일(디폴트는 'hostname'.log )에 기록됩니다.이 로그는, 클라이언트 측에 에러의 원인이 있다고 생각할 수 있어mysqld 에 대해서 클라이언트가 무엇을 송신했는지 조사할 때 매우 도움이 됩니다.

낡은 버젼(MySQL 3.23.4 (으)로부터 3.23.8 )의 mysql.server 스크립트는,safe_mysqld 에, 일반 쿼리 로그를 유효화한다 --log 옵션을 건네줍니다.실가동 환경에서 MySQL 의 기동시의 퍼포먼스를 향상시킬 필요가 있는 경우에는,--log 옵션을 mysql.server (으)로부터 삭제하는지,--log-bin (으)로 변경합니다. See 항4.10.4. 「바이너리 로그」 .

이 로그의 엔트리는,mysqld 하지만 쿼리를 받은 시점에서 써집니다.이것은, 스테이트먼트가 실행된 순서와는 다른 경우가 있습니다.또, 갱신 로그 및 바이너리 로그와도 대비적입니다.갱신 로그 및 바이너리 로그는, 쿼리가 실행된 후, 락이 해제되기 전에 써집니다.

4.10.3. 갱신 로그

주의: 갱신 로그는 폐?~ 되어 대신에 바이너리 로그가 사용됩니다.See 항4.10.4. 「바이너리 로그」 . 바이너리 로그는, 이전의 갱신 로그의 기능을 모두 갖추어 더해 다른 기능도 추가되고 있습니다.MySQL 5.0 그리고 갱신 로그는 없어집니다 .

mysqld (을)를 --log-update[=file_name] 옵션으로 기동하면, 데이터를 갱신하는 모든 SQL 커멘드가 로그 파일에 기록됩니다.파일명을 지정하지 않으면, 호스트 머신의 이름이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하지 않는 경우, 파일은 데이터 디렉토리에 작성됩니다.file_name 에 확장자(extension)가 없는 경우,mysqld 하file_name.### 의 형식에서 로그 파일명을 생성합니다.여기서 ### (은)는,mysqladmin refresh ,mysqladmin flush-logs , 및 FLUSH LOGS 스테이트먼트가 실행될 때마다, 및 서버가 재기동할 때마다 인크리먼트(increment) 되는 번호입니다.

주의: 상기 스킴이 유효하기 때문에 , 갱신 로그가 사용하는 디렉토리내에서는, 갱신 로그 + 어떠한 확장자(extension) 등, 번호라고 오인되는 파일명의 파일을 작성 해서는 안됩니다.

--log 옵션 또는 -l 옵션을 사용했을 경우,mysqld 하 hostname.log (이)라는 이름의 일반 로그 파일을 작성합니다.재기동이나 리프레쉬를 실시해도 신규 로그 파일은 생성되지 않습니다(일단 닫고, 재차 열 뿐입니다).이 경우, 이하와 같이 해(Unix 상) 로그 파일을 카피할 수 있습니다.

mv hostname.log hostname-old.log
mysqladmin flush-logs
cp hostname-old.log to-backup-directory
rm hostname-old.log

갱신 로그는, 데이터를 실제로 갱신한 스테이트먼트만을 기록합니다.UPDATE 또는 DELETE 의 WHERE 지정으로 레코드가 발견되지 않았던 경우, 그 스테이트먼트는 로그에 써지지 않습니다.컬럼의 값을, 벌써 있는 같은 값으로 갱신했다 UPDATE 스테이트먼트도 스킵 됩니다.

갱신 로그의 기입은, 쿼리가 완료한 직후에 락의 해제전에, 또는 코?~ 트의 전에 행해집니다.이 때문에, 로그는 실행 순서대로 써집니다.

갱신 로그 파일로부터 데이타베이스를 갱신하려면 , 이하를 실행합니다.여기에서는, 갱신 로그명의 형식을 file_name.### (와)과 가정하고 있습니다.

shell> ls -1 -t -r file_name.[0-9]* | xargs cat | mysql

ls (은)는, 모든 로그 파일을 올바른 순서로 취득하기 위해서 사용합니다.

이것은, 크래쉬 후에 백업파일 상태에까지 되돌린다, 혹은 백업 후부터 크래쉬까지의 사이의 갱신을 반복하는 경우 등에 도움이 됩니다.

4.10.4. 바이너리 로그

바이너리 로그는, 이전의 갱신 로그 대신에 되는 것입니다.갱신 로그는 MySQL 5.0 (이)가 아니게 됩니다.바이너리 로그에는, 갱신 로그로 이용 가능했던 정보가 모두, 보다 효율적 한편 트랜잭션(transaction) 세이프인 방법으로 포함됩니다.

바이너리 로그는 이전의 갱신 로그와 같이, 데이터를 실제로 갱신하는 스테이트먼트만을 기록합니다.UPDATE 또는 DELETE 의 WHERE 지정으로 레코드가 발견되지 않았던 경우, 그 스테이트먼트는 로그에 써지지 않습니다.컬럼의 값을, 벌써 있는 같은 값으로 갱신했다 UPDATE 스테이트먼트도 스킵 됩니다.

바이너리 로그에는, 백업 후의 갱신이 모두 기록됩니다.바이너리 로그의 주된 목적은, restore시에, 데이타베이스에 대해서 가능한 한 백업 후의 갱신을 실행할 수 있도록 하는 것입니다.

바이너리 로그는, 마스터로부터 슬레이브에 replication를 실시할 때도 사용합니다. See 항4.11. 「MySQL 의 replication」 .

바이너리 로그에는, 데이타베이스를 갱신한 각 쿼리에 걸린 시간의 정보도 포함됩니다.데이터를 변경하지 않았던 쿼리는 포함되지 않습니다.문제가 있는 쿼리를 찾아내는 등의 목적으로 모든 쿼리를 기록하고 싶은 경우에는, 일반 쿼리 로그를 사용해 주세요. See 항4.10.2. 「일반 쿼리 로그」 .

mysqld (을)를 --log-bin[=file_name] 옵션으로 기동하면, 데이터를 갱신한 모든 SQL 커멘드가 로그 파일에 기록됩니다.파일명을 지정하지 않으면, 호스트 머신의 이름에 -bin (을)를 붙인 것이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하고 있지 않는 경우에는, 파일은 데이터 디렉토리에 작성됩니다.

--log-bin=filename.extension 그리고 확장자(extension)를 지정했을 경우, 확장자(extension)는 삭제됩니다.

mysqld (은)는, 바이너리 로그 파일명에 숫자의 확장자(extension)를 추가합니다.이 번호는,mysqladmin refresh ,mysqladmin flush-logs , 및 FLUSH LOGS 스테이트먼트가 실행될 때마다, 또는 서버가 재기동할 때마다 인크리먼트(increment) 됩니다.바이너리 로그의 사이즈가 max_binlog_size 에 이르면, 새로운 바이너리 로그가 자동적으로 작성됩니다.주의: 트랜잭션(transaction)를 사용하고 있는 경우, 트랜잭션(transaction)는 1 개의 정리로 바이너리 로그에 써지기 위해, 복수의 바이너리 로그에 분할될 것은 없습니다.따라서, 큰 트랜잭션(transaction)가 있는 경우, 바이너리 로그가 max_binlog_size 보다 커질 가능성이 있습니다.

모든 바이너리 로그 파일을 삭제하려면 ,RESET MASTER 커멘드(see 항4.6.5. 「RESET 구문」 )(을)를 사용합니다.일부의 파일을 삭제하려면 ,PURGE MASTER LOGS (see 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 )(을)를 사용합니다.

mysqld 그리고 이하의 옵션을 사용해, 무엇을 바이너리 로그에 기록할까 제어할 수 있습니다(겉(표)의 뒤의 설명을 반드시 읽어 주세요).

옵션 | 설명
binlog-do-db=database_name | 경향 데이타베이스(USE 에 의해서 선택된 데이타베이스)가 'database_name' 의 경우, 갱신을 바이너리 로그에 기록하도록(듯이) 마스터에 지시한다.그 이외의 명시적으로 지정되어 있지 않은 데이타베이스는 모두 무시한다.주의: 경향 데이타베이스내에서만 갱신을 실시하는 것이 확실한 경우에, 이 옵션을 사용하는 것(예: binlog-do-db=some_database ). 예상하기 힘든 동작예: 서버를 binlog-do-db=sales 그리고 기동해,USE prices; UPDATE sales.january SET amount=amount+1000; (을)를 실행했을 경우, 이 쿼리는 바이너리 로그에는 써지지 않다.
binlog-ignore-db=database_name | 경향 데이타베이스(USE 에 의해서 선택된 데이타베이스)가 'database_name' 의 경우, 갱신을 바이너리 로그에 기록하지 않게 마스터에 지시한다.주의: 경향 데이타베이스내에서만 갱신을 실시하는 것이 확실한 경우에, 이 옵션을 사용하는 것(예: binlog-ignore-db=some_database ). 예상하기 힘든 동작예: 서버를 binlog-ignore-db=sales 그리고 기동해,USE prices; UPDATE sales.january SET amount=amount+1000; (을)를 실행했을 경우, 이 쿼리는 바이너리 로그에 써진다.

쿼리를 바이너리 로그에 쓸지의 평가는, 이하의 순서로 행해집니다.

  1. binlog-do-db 룰 또는 binlog-ignore-db 룰이 있을까.

    • No: 쿼리를 바이너리 로그에 써 종료한다.

    • Yes: 다음의 스텝으로 옮긴다.

  2. 룰(binlog-do-db 또는 binlog-ignore-db , 혹은 그 양쪽 모두)가 존재한다.경향 데이타베이스가 있을까(USE 하지만 선택하고 있는 데이타베이스가 있을까).

    • No: 쿼리를 쓰지 마 종료한다.

    • Yes: 다음의 스텝으로 옮긴다.

  3. 경향 데이타베이스가 있다.binlog-do-db 룰은 있을까.

    • Yes: 경향 데이타베이스가 binlog-do-db 룰의 어느 쪽인가에 일치하고 있을까.

      • Yes: 쿼리를 써 종료한다.

      • No: 쿼리를 쓰지 마 종료한다.

    • No: 다음의 스텝으로 옮긴다.

  4. binlog-ignore-db 룰이 존재한다. 경향 데이타베이스가 binlog-ignore-db 룰의 어느 쪽인가에 일치하고 있을까.

    • Yes: 쿼리를 쓰지 말고 종료한다.

    • No: 쿼리를 써 종료한다.

따라서, 예를 들어 binlog-do-db=sales 만으로 실행중의 슬레이브는, 경향 데이타베이스가 sales (이)가 아닌 쿼리를 일절 바이너리 로그에 쓰지 않습니다(즉,binlog-do-db 하 `` 다른 데이타베이스를 무시한다'' 그렇다고 하게도 됩니다).

어느 바이너리 로그 파일이 사용되었는지 알도록(듯이),mysqld (은)는 바이너리 로그인 덱스 파일도 작성합니다.이 파일에, 사용된 바이너리 로그 파일 모든 이름이 포함됩니다.디폴트에서는, 이 파일의 이름은 바이너리 로그 파일명에 확장자(extension) '.index' (을)를 붙인 것이 됩니다. 바이너리 로그인 덱스 파일의 이름을 변경하려면 ,--log-bin-index=[filename] 옵션을 사용합니다. mysqld 의 실행중은, 이 파일을 수동으로 편집하지 말아 주세요.mysqld 하지만 혼란하는 원인이 됩니다.

replication를 사용하고 있는 경우, 슬레이브가 필요로 하고 있는 동안은, 낡은 바이너리 로그 파일을 삭제하지 말아 주세요. 예를 들어,mysqladmin flush-logs (을)를 매일 실행하는 경우,3 일 경과한 로그를 모두 삭제하도록(듯이) 합니다.이러한 로그는 수동으로 삭제할 수도 있습니다만, 바이너리 로그인 덱스 파일도 안전하게 갱신할 수 있다 PURGE MASTER LOGS (see 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 )(을)를 사용해 삭제하는 것을 추천 합니다.이 커멘드는,MySQL 4.1 (으)로부터 일자 인수를 지정할 수 있게 되어 있습니다.

SUPER 권한으로의 접속에서는,SET SQL_LOG_BIN=0 (을)를 사용하고, 쿼리의 바이너리 로그를 무효로 할 수 있습니다. See 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 .

바이너리 로그 파일을 조사하려면 ,mysqlbinlog 유틸리티를 사용합니다. 예를 들어, 이하와 같이 바이너리 로그로부터 MySQL 서버를 갱신할 수 있습니다.

shell> mysqlbinlog log-file | mysql -h server_name

mysqlbinlog 유틸리티 및 그 사용법에 관한 상세한 것에 대하여는, 항4.9.5. 「mysqlbinlog (바이너리 로그로부터 쿼리를 실행한다)」 (을)를 참조해 주세요.

BEGIN [WORK] 또는 SET AUTOCOMMIT=0 (을)를 사용하고 있는 경우는, 이전의 갱신 로그는 아니고 MySQL 바이너리 로그를 백업용으로 사용해 주세요.갱신 로그는 MySQL 5.0 (이)가 아니게 됩니다.

바이너리 로그의 기입은, 쿼리가 완료한 직후에 락의 해제전에, 또는 코?~ 트의 전에 행해집니다.이 때문에, 로그는 실행 순서대로 써집니다.

비트랜잭션(transaction) 테이블의 갱신은 실행 직후에 바이너리 로그에 보존됩니다.BDB 테이블이나 InnoDB 테이블등의 트랜잭션(transaction) 테이블에서는, 테이블을 변경하는 모든 갱신(UPDATE ,DELETE , 또는 INSERT )(은)는,COMMIT 커멘드가 서버에 송신될 때까지 캐쉬됩니다.mysqld (은)는,COMMIT 하지만 실행되기 전에 트랜잭션(transaction) 전체를 바이너리 로그에 씁니다. 모든 스레드가, 최초로, 쿼리를 버퍼 한다 binlog_cache_size 의 버퍼를 할당합니다.쿼리가 이것보다 큰 경우, 스레드는 임시 파일을 열어 트랜잭션(transaction)를 보존합니다.스레드가 종료하면 임시 파일은 삭제됩니다.

max_binlog_cache_size (디폴트는 4G )(을)를 사용하고, 복수 쿼리 트랜잭션(transaction)의 캐쉬에 사용하는 토탈 사이즈를 제한할 수 있습니다.트랜잭션(transaction)가 이것보다 큰 경우, 에러가 되어 롤백(rollback) 합니다.

갱신 로그 또는 바이너리 로그를 사용하고 있는 경우에,CREATE ... SELECT 또는 INSERT ... SELECT (을)를 사용하면, 동시 삽입이 통상의 삽입에 변환됩니다. 이것은, 백업에 로그를 적용했을 때에, 테이블의 정확한 카피를 작성하기 위한 조치입니다.

4.10.5. 슬로우 쿼리 로그

mysqld (을)를 --log-slow-queries[=file_name] 옵션으로 기동하면, 실행에 long_query_time 초보다 길게 걸렸다 SQL 커멘드가 모두 로그 파일에 써집니다.최초의 테이블 락에 걸린 시간은 실행 시간에 포함되지 않습니다.

슬로우 쿼리 로그는, 쿼리 실행 후, 모든 락이 해제된 후에 써집니다.이것은, 스테이트먼트가 실행된 순서와는 다른 경우가 있습니다.

파일명을 지정하지 않으면, 호스트 머신의 이름에 -slow.log (을)를 붙인 것이 디폴트명이 됩니다.파일명을 지정해, 패스를 지정하지 않는 경우, 파일은 데이터 디렉토리에 작성됩니다.

슬로우 쿼리 로그는, 실행에 시간이 걸려, 최적화의 대상이 되는 쿼리를 찾아내기 위해서 사용할 수 있습니다.큰 로그에서는, 이것은 어려운 작업이 됩니다.mysqldumpslow 커멘드를 사용하면, 로그의 쿼리 요약을 취득할 수 있습니다.

--log-long-format (을)를 사용하면, 인덱스를 사용하지 않았던 쿼리도 출력됩니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

4.10.6. 로그 파일의 보수

MySQL 서버에서는 몇개의 종류의 로그 파일이 생성되어 실행 내용을 간단하게 확인할 수 있습니다.See 항4.10. 「MySQL 로그 파일」 . 다만, 로그가 디스크 영역을 점유 너무 하지 않게 이러한 파일을 정기적으로 클린 업 할 필요가 있습니다.

MySQL (을)를 로그 파일과 함께 사용하는 경우, 정기적으로 낡은 파일을 삭제 또는 백업 해, 새로운 파일로 로그를 개시하도록 해 주세요. See 항4.5.1. 「데이타베이스의 백업」 .

Linux (Red Hat ) 인스톨에서는,mysql-log-rotate 스크립트를 사용하고, 낡은 로그 파일의 처리를 자동적으로 실시할 수 있습니다.RPM 디스트리뷰션으로부터 MySQL (을)를 인스톨 하고 있으면, 이 스크립트는 자동적으로 인스톨 되고 있을 것입니다.주의: replication용으로 바이너리 로그를 사용하고 있는 경우, 이 스크립트의 사용에는 주의가 필요합니다.

다른 시스템에서는, 로그 파일을 처리하기 위한 짧은 스크립트를 스스로 인스톨 할 필요가 있습니다.이 스크립트는,cron (으)로부터 개시합니다.

새로운 로그 파일의 사용을 MySQL 에 강제하려면 ,mysqladmin flush-logs (을)를 사용하는지,SQL 커멘드 FLUSH LOGS (을)를 사용합니다. MySQL 버젼 3.21 (을)를 사용하고 있는 경우,mysqladmin refresh (을)를 사용할 필요가 있습니다.

상기 커멘드는 이하를 실행합니다.

  • 일반 로그(--log ) 또는 슬로우 쿼리 로그(--log-slow-queries )(이)가 사용되고 있는 경우, 로그 파일(디폴트에서는 mysql.log (와)과 `hostname`-slow.log )(을)를 닫아 다시 연다.

  • 갱신 로그(--log-update )(이)가 사용되고 있는 경우, 갱신 로그를 닫고,1 개번호가 큰 신규 로그 파일을 연다.

갱신 로그만을 사용하고 있는 경우는, 로그를 플래시 하고, 낡은 갱신 로그 파일을 백업으로 이동하는 것만으로 끝납니다. 통상의 로그를 사용하고 있는 경우는, 이하와 같이 실시합니다.

shell> cd mysql-data-directory
shell> mv mysql.log mysql.old
shell> mysqladmin flush-logs

다음에, 백업을 작성해,mysql.old (을)를 삭제합니다.


4.11. MySQL 의 replication

1 개의 MySQL 서버에 있는 데이타베이스를 다른 서버에 복제할 수 있는 replication 기능은,MySQL 버젼 3.23.15 그리고 도입되었습니다.이 섹션에서는,MySQL 의 다양한 replication 기능에 대해 설명합니다.이 섹션은, replication로 이용 가능한 옵션의 레퍼런스라고 해도 도움이 됩니다.우선 replication에 대해 설명해, 그 실장 방법을 해설합니다.후반으로는,FAQ , 및 발생 할 수 있는 문제의 설명과 그 해결 방법을 기술합니다.

당사의 Web 사이트 http://www.mysql.com/ (을)를 정기적으로 액세스 해, 이 섹션의 최신판에 대충 훑어봐 두는 것을 추천 합니다.replication는 항상 개량되고 있어 빈번히 메뉴얼을 최신의 정보로 갱신하고 있습니다.

4.11.1. 처음에

버젼 3.23.15 (으)로부터,MySQL (은)는 한방향 replication를 내부적으로 서포트하고 있습니다.1 개의 서버가 마스터로서 기능해, 다른 1 개 또는 복수의 서버가 슬레이브가 됩니다.마스터 서버가 갱신의 바이너리 로그를 보관 유지합니다(see 항4.10.4. 「바이너리 로그」 ). 또, 바이너리 로그의 인덱스 파일도 보관 유지해, 로그의 로테이션을 기록합니다.각 슬레이브는 접속시, 전회 replication에 성공으로 하고 있는 갱신의 위치를 마스터에 통지해, 그것이?~ 의 갱신을 실행해, 그 후 블록 하고, 마스터로부터의 신규 갱신의 통지를 기다립니다.

replication 서버를 체인장에 구성하면, 슬레이브는 다른 서버에 대한 마스터라고 해도 기능할 수 있습니다.

주의: replication를 사용하는 경우, 테이블의 갱신은 모두 마스터 서버로 실행할 필요가 있습니다.그렇지 않은 경우, 유저가 마스터의 테이블로 간 갱신과 슬레이브의 테이블로 간 갱신과의 사이에 경합이 발생합니다.

한방향 replication는, 견뢰성, 속도, 및 시스템 관리의 면에서 우수합니다.

  • 마스터/ 슬레이브 셋업에 의해 견뢰성이 향상한다. 마스터로 문제가 있었을 경우, 백업으로서 슬레이브로 전환할 수 있다.

  • 클라이언트 쿼리의 부하를 마스터와 슬레이브에 분산하는 것에 의해서 속도를 향상할 수 있어 그 결과 클라이언트의 응답 시간이 짧아진다. SELECT 쿼리를 슬레이브에 송신하는 것으로써, 마스터의 쿼리 처리 부하를 경감할 수 있다.데이터를 변경하는 쿼리는, 마스터와 슬레이브의 정합성을 유지하기 위해, 마스터에 송신할 필요가 있다.load sharing 전략은, 갱신 이외의 쿼리가 많은 경우만 효과가 있다.통상, 이 경우가 많다.

  • 그 외에도, replication를 사용하면, 마스터는 아니고 슬레이브로 백업을 실시할 수 있다고 하는 이점이 있다. See 항4.5.1. 「데이타베이스의 백업」 .

4.11.2. replication 실장의 개요

MySQL replication는, 마스터 서버가, 데이타베이스에 대한 모든 변경(갱신, 삭제등)을 바이너리 로그(see 항4.10.4. 「바이너리 로그」 )에 기록하는 것을 기본으로 하고 있습니다.각 슬레이브 서버는, 마스터가 그 바이너리 로그에 기록한 쿼리를 마스터로부터 받아, 데이터의 카피상에서 같은 쿼리를 실행할 수 있습니다.

바이너리 로그는, 단지, 어느 특정의 시각(바이너리 로그를 유효하게 한 순간)부터의 기록인 것을 이해하는 것이 중요 입니다.슬레이브에는 모두, 마스터로 바이너리 로그를 유효하게 한 순간의 master data 베이스의 카피가 필요합니다. 바이너리 로그가 개시되었을 때 의 마스터상의 데이터와는 다른 데이터로 슬레이브를 개시하면, 그 슬레이브는 실패합니다.

이하의 겉(표)는,MySQL (이)가 다른 버젼간으로의 마스터/ 슬레이브 replication의 호환성을 나타낸 것입니다.

 |  | 마스터 | 마스터 | 마스터 | 마스터
 |  | 3.23.33 이?~ | 4.0.0 | 4.0.1 | 4.0.3 이?~
슬레이브 | 3.23.33 이?~ | yes | no | no | no
슬레이브 | 4.0.0 | no | yes | no | no
슬레이브 | 4.0.1 | yes | no | yes | no
슬레이브 | 4.0.3 이?~ | yes | no | no | yes

replication 기능은 항상보다 강력한 기능으로 변화하고 있으므로, 최신의 MySQL 버젼을 항상 사용하는 것을 추천 합니다.버젼 4.0 에 대해서는, 마스터와 슬레이브의 양쪽 모두에 같은 버젼의 사용을 추천 합니다.예외로서MySQL 4.0.2 (은)는 replication 목적으로는 적합하지 않습니다.

주의: 마스터를 MySQL 3.23 (으)로부터 MySQL 4.0 (또는 4.1 )에 업그레이드 하는 경우, 낡다 3.23 바이너리 로그를 사용해 replication를 재개하지 말아 주세요.4.0 슬레이브가 혼란하는 원인이 됩니다.업그레이드 하는 마스터가 3.23 그리고, 슬레이브가 4.0 의 경우는 이하의 방법으로 안전하게 업그레이드 할 수 있습니다.

  1. 마스터로의 갱신을 모두 블록 한다(FLUSH TABLES WITH READ LOCK ).

  2. 모든 슬레이브가 마스터의 갱신을 따라 잡는 것을 기다린다(마스터로 SHOW MASTER STATUS (을)를 사용해, 슬레이브로 SELECT MASTER_POS_WAIT() (을)를 사용한다).그리고, 슬레이브로 STOP SLAVE (을)를 실행한다.

  3. 마스터의 MySQL (을)를 슛다운 해, 마스터를 MySQL 4.0 에 업그레이드 한다.

  4. 마스터로 MySQL (을)를 재기동한다.마스터가 새롭게 작성 물러날 수 있었던 바이너리 로그의 이름 <name> (을)를 기록한다.파일의 이름을 취득하려면 , 마스터로 SHOW MASTER STATUS (을)를 실행한다.각 슬레이브에 이하의 커멘드를 실행한다.

    mysql> CHANGE MASTER TO MASTER_LOG_FILE='<name>', MASTER_LOG_POS=4;
mysql> START SLAVE;

슬레이브도 3.23 (으)로부터 4.0 에 업그레이드 할 필요가 있는 경우는, 최초로 슬레이브를 업그레이드 해 주세요.각각을 슛다운 해, 업그레이드 하고 나서 재기동합니다. 그리고, 상기의 순서로 마스터를 업그레이드 합니다.

4.0.0 이?~ ,LOAD DATA FROM MASTER (을)를 사용해 슬레이브를 셋업 할 수 있게 되어 있습니다.현재로서는,LOAD DATA FROM MASTER 하지만 동작하는 것은, 마스터의 테이블이 모두 MyISAM 형태의 경우 뿐입니다.또, 이 스테이트먼트에서는 글로벌하게 READ 락이 걸리기 위해, 테이블을 마스터로부터 전송 하고 있는 동안은 기입할 수 없게 됩니다.MySQL 5.0 그리고 락 프리의 핫 테이블 백업이 도입되면, 글로벌의 READ 락은 필요없게 됩니다.

이러한 제한 때문에, 현시점에서는, 마스터의 데이터 세트가 비교적 작은 경우, 또는 마스터의 READ 락이 길어져도 상관없는 경우만,LOAD DATA FROM MASTER (을)를 사용해 주세요.LOAD DATA FROM MASTER 의 실제의 속도는 시스템에 따라서 다릅니다만, 대체로의 기준으로서는, 데이터 파일 1 메가바이트 근처 1 초로 생각해 주세요.이것은, 마스터와 슬레이브가 동등의 700 MHz Pentium 그리고,100 MBit/ 초 네트워크의 접속을 상정한 기준입니다.어디까지나 대체로의 기준입니다.

일단 슬레이브를 적절히 설정해 실행하면, 슬레이브는 마스터에 접속해 갱신 처리를 기다립니다.마스터와의 접속이 끊어졌을 경우, 재접속할 수 있을 때까지 정기적으로 접속을 재시행해, 접속할 수 있으면 갱신의 릿슨을 재개합니다.재시행의 간격은,--master-connect-retry 옵션으로 제어합니다.디폴트는 60 초입니다.

각 슬레이브는, 종료시점을 기록하고 있습니다.마스터 서버측에서는, 몇의 슬레이브가 존재해, 어떤 것이 언제 갱신되었는지를 기록하고 있지 않습니다.

4.11.3. replication의 실장의 상세

replication에는 3 개의 스레드가 관련하고 있습니다.1 개가 마스터,2 개가 슬레이브의 스레드입니다. START SLAVE 하지만 발행되면,I/O 스레드가 슬레이브에 작성됩니다.이것은 마스터에 접속해, 마스터의 바이너리 로그에 기록되고 있는 쿼리의 송신을 요구합니다. 다음에, 이러한 바이너리 로그를 송신하기 위한 스레드가 마스터에 작성됩니다.이 스레드는, 마스터의 SHOW PROCESSLIST 출력으로 Binlog Dump (으)로서 식별할 수 있습니다. I/O 스레드는, 마스터 Binlog Dump 스레드가 송신한 것을 읽어내, 슬레이브내의 릴레이 로그로 불리는 데이터 디렉토리의 로컬 파일에 카피합니다. 마지막으로,SQL 스레드가 슬레이브에 작성됩니다.이것은 릴레이 로그를 읽어내, 거기에 포함되는 쿼리를 실행합니다.

주의: 마스터에는, 접속하고 있는 슬레이브 서버 1 개에 대해,1 개의 스레드가 있습니다.

SHOW PROCESSLIST (을)를 사용하면, replication에 관한 마스터 및 슬레이브로의 처리 내용을 확인할 수 있습니다.

이하의 예로,3 개의 스레드가 SHOW PROCESSLIST 그리고 어떻게 표시될까 나타내 보입니다.출력 형식은,MySQL 버젼 4.0.15 의 SHOW PROCESSLIST 의 것입니다.구버젼에 비해 State 컬럼의 내용이 충실합니다.

마스터 서버에서는, 이하와 같은 출력이 됩니다.

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

슬레이브 서버에서는, 이하와 같은 출력이 됩니다.

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:
     db: NULL
Command: Connect
   Time: 11
  State: Has read all relay log; waiting for the slave I/O thread to update it
   Info: NULL

여기에서는, 스레드 Id 2 하지만 마스터입니다.스레드 Id 10 (은)는 슬레이브의 I/O 스레드입니다.스레드 Id 11 (은)는 슬레이브의 SQL 스레드입니다.Time 컬럼의 값에 의해, 슬레이브가 마스터와 비교해 어느 정도 늦을까 압니다(see 항4.11.9. 「replication FAQ 」 ).

이하의 일람은, 마스터의 Binlog Dump 스레드의 State 컬럼에 표시되는 일반적인 상태를 집계한 것입니다.이 스레드가 마스터 서버에 없으면, replication는 실행되어 있지 않다고 하는 것입니다.

  • Sending binlog event to slave

    바이너리 로그는 이벤트로 구성된다.통상, 이벤트란, 쿼리와 그 외의 정보가 짜 합쳐진 것이다.이 스테이터스는, 스레드가, 바이너리로부터 이벤트를 읽어내, 그것을 슬레이브에 송신중이라고 하는 것이다.

  • Finished reading one binlog; switching to next binlog

    스레드는 1 개의 바이너리 로그 파일의 독해를 완료해, 슬레이브에 송신하기 위해서 다음의 파일을 열고 있는 도중에 있다.

  • Has sent all binlog to slave; waiting for binlog to be updated

    스레드는 모든 바이너리 로그 파일의 독해를 완료해, 아이돌 상태이다.스레드는, 마스터로 실행되는 새로운 갱신 쿼리의 결과로서, 바이너리 로그에 새로운 이벤트가 써지는 것을 기다리고 있다.

  • Waiting to finalize termination

    스레드정?~ 안에 순간적으로 발생하는 상태.

이하는, 슬레이브 서버의 I/O 스레드의 State 컬럼에 표시되는 일반적인 상태입니다.MySQL 4.1.1 이?~ , 이 상태는 SHOW SLAVE STATUS 출력의 Slave_IO_State 컬럼에도 표시됩니다.그 때문에,SHOW SLAVE STATUS (을)를 사용하는 것만으로 현상을 파악할 수 있습니다.

  • Connecting to master

    스레드는, 마스터에의 접속을 시행중이다.

  • Checking master version

    마스터에의 접속이 확립한 직후, 순간적으로 발생하는 상태.

  • Registering slave on master

    마스터에의 접속이 확립한 직후, 순간적으로 발생하는 상태.

  • Requesting binlog dump

    마스터에의 접속이 확립한 직후, 순간적으로 발생하는 상태.스레드는, 바이너리 로그의 내용을 마스터에 요구한다.바이너리 로그 파일의 이름과 장소가 최초로 마스터에 송신된다.

  • Waiting to reconnect after a failed binlog dump request

    바이너리 로그 덤프 요구가 실패했을(접속 절단에 의해서) 경우, 스레드는 sleeve중 이 상태가 된다.스레드는 재시행하기 전에,master-connect-retry 초간 sleeve 상태가 된다.

  • Reconnecting after a failed binlog dump request

    다음에, 스레드는 마스터에의 재접속을 시행한다.

  • Waiting for master to send event

    스레드는 접속을 완료해, 바이너리 로그 이벤트의 도착을 기다리고 있다.마스터가 아이돌 상태이면, 이 상태가 길게 계속 되는 경우가 있다.대기가 slave_read_timeout 초간 계속 되면, 타임 아웃이 발생한다.그 시점에서 스레드는 접속이 절단 했다고 봐, 재접속을 시행한다.

  • Queueing master event to the relay log

    스레드가 이벤트의 독해를 완료해,SQL 스레드가 그 이벤트를 처리할 수 있도록 릴레이 로그에 카피중이다.

  • Waiting to reconnect after a failed master event read

    독해중에 에러가 발생했다(접속 절단이기 때문에).스레드는 접속을 재시행하기 전에,master-connect-retry 초간 sleeve 상태가 된다.

  • 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

    relay_log_space_limit 의 값이 0 이외로 설정되어 있지만, 릴레이 로그가 너무 커져서 , 그 합계 사이즈가 이 값을 넘었다.SQL 스레드가 릴레이 로그의 내용을 처리해 릴레이 로그 파일을 삭제해, 영역에 여유가 생겨 오는 것을 I/O 스레드는 기다리고 있다.

  • Waiting for slave mutex on exit

    스레드정?~ 안에 순간적으로 발생하는 상태.

이하는, 슬레이브 서버의 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 4.0.2 보다 전은, 슬레이브의 I/O 스레드와 SQL 스레드는 1 개의 스레드에 정리하고 있어 릴레이 로그 파일은 사용되고 있지 않았습니다. 2 개의 스레드를 사용하는 이점은, 쿼리의 독해와 쿼리의 실행을 2 개의 독립한 태스크로 나눌 수 있는 것입니다.그 때문에, 쿼리 실행이 늦어도 쿼리 독해가 늦어질 것은 없습니다.예를 들어, 슬레이브 서버가 당분간의 사이 실행하지 않았던 경우에서도, 슬레이브가 기동하면,I/O 스레드가 바이너리 로그의 모든 내용을 재빠르게 읽어냅니다.SQL 스레드가 꽤 늦고 , 따라잡는데 수시간 걸린다고 해도 영향을 받지 않습니다.SQL 스레드가 읽어낸 쿼리를 모두 실행하기 전에 슬레이브가 정?~ 해도, 적어도 I/O 스레드가 쿼리의 읽기를 완료하고 있으므로, 쿼리의 카피는 슬레이브의 릴레이 로그에 로컬로 안전하게 보존되고 있어 다음 번 슬레이브가 기동했을 때에 실행할 수 있습니다.이 때문에, 마스터에서는 바이너리 로그를 삭제할 수 있습니다.슬레이브가 그 내용을 읽어 출 하는 것을 기다릴 필요는 없기 때문입니다.

디폴트에서는, 릴레이 로그의 이름은 host_name-relay-bin.nnn 형식이 됩니다.여기서,host_name (은)는 슬레이브 서버의 호스트명,nnn (은)는 순서 번호입니다. 연속한 릴레이 로그 파일에서는, 순서 번호는 001 (으)로부터 시작되는 연속한 번호가 됩니다. 슬레이브는, 현재 사용중의 릴레이 로그의 기록을 인덱스 파일 로 유지합니다.디폴트의 릴레이 로그인 덱스 파일명은 host_name-relay-bin.index 입니다. 디폴트에서는, 이러한 파일은 슬레이브의 데이터 디렉토리에 작성됩니다.디폴트의 파일명은,--relay-log 및 --relay-log-index 의 각 서버 옵션으로 덧쓰기할 수 있습니다.

릴레이 로그는 바이너리 로그와 같은 형식이므로,mysqlbinlog 그리고 읽어낼 수 있습니다.릴레이 로그는 필요가 없어지면(그 이벤트가 모두 실행되면),SQL 스레드에 의해서 자동적으로 삭제됩니다.SQL 스레드가 자동적으로 실시하기 위해, 릴레이 로그를 삭제하는 커멘드는 없습니다.다만,MySQL 4.0.14 에서는 FLUSH LOGS 하지만 릴레이 로그를 로테이트 하기 위한(해),SQL 하지만 삭제하는 타이?~ 그에 영향을 줍니다.

새로운 릴레이 로그는, 이하의 조건으로 작성됩니다.

  • 슬레이브 서버의 기동 후, 최초로 I/O 스레드가 개시되었을 때(MySQL 5.0 그럼, 최초의 I/O 스레드 개시시 뿐만이 아니라,I/O 스레드가 개시될 때마다 신규 릴레이 로그가 작성된다).

  • FLUSH LOGS 스테이트먼트의 실행시(4.0.14 이?~ ).

  • 현재의 릴레이 로그 파일의 사이즈가 너무 커졌을 때.`` 너무 크다'' 화도인가는 이하의 변수로 결정된다.

    • max_relay_log_size (max_relay_log_size > 0 의 경우)

    • max_binlog_size (max_relay_log_size = 0 또는 MySQL 버젼이 4.0.14 보다 낡은 경우)

슬레이브 replication 서버는,2 개의 작은 파일을 데이터 디렉토리에 작성합니다.이러한 파일의 이름은 디폴트로,master.info 및 relay-log.info (이)가 됩니다.이러한 파일에는,SHOW SLAVE STATUS 스테이트먼트(이 커멘드의 설명에 대해서는,see 항4.11.8. 「슬레이브 서버를 제어한다 SQL 스테이트먼트」 )의 출력에 포함되는 정보가 보존됩니다.디스크 파일로서 슬레이브가 슛다운 해도 보관 유지됩니다.다음 번 슬레이브가 기동했을 때, 마스터로부터의 바이너리 로그 독해와 릴레이 로그의 처리가 어디까지 진행되고 있을까의 정보를, 슬레이브는 이러한 파일로부터 읽어낼 수 있습니다.

master.info 파일은 I/O 스레드에 의해서 갱신됩니다.이 파일내의 행과 SHOW SLAVE STATUS 의 출력 결과내의 컬럼과의 대응은 이하대로입니다.

행 | 설명
1 | Master_Log_File
2 | Read_Master_Log_Pos
3 | Master_Host
4 | Master_User
5 | 패스워드(SHOW SLAVE STATUS 그럼 표시되지 않는다)
6 | Master_Port
7 | Connect_Retry

relay-log.info 파일은 SQL 스레드에 의해서 갱신됩니다.파일내의 행과 SHOW SLAVE STATUS 의 출력 결과내의 컬럼과의 대응은 이하대로입니다.

행 | 설명
1 | Relay_Log_File
2 | Relay_Log_Pos
3 | Relay_Master_Log_File
4 | Exec_Master_Log_Pos

슬레이브의 데이터를 백업 할 때, 릴레이 로그 파일과 함께 이것들 2 개의 작은 파일도 백업 해 주세요.슬레이브의 데이터를 restore 후, replication를 재회하는데 필요합니다.릴레이 로그를 잃었을 경우에서도 relay-log.info 파일이 있으면,SQL 스레드가 마스터 바이너리 로그를 어디까지 실행했는지 조사할 수 있습니다.그러면,CHANGE MASTER TO (을)를 MASTER_RELAY_LOG 옵션 및 MASTER_RELAY_POS 옵션과 함께 사용하고, 그 개소로부터 바이너리 로그를 재독 봐 취하도록(듯이) 슬레이브에 지시할 수 있습니다.이것은 물론, 바이너리 로그가 아직 마스터 서버에 존재하는 것이 전제가 됩니다.

슬레이브가,LOAD DATA INFILE 스테이트먼트도 replication 하지 않으면 안 되는 경우,SQL_LOAD-* 파일도 백업 해 주세요.이 파일은, 이 목적으로 슬레이브가 사용하는 디렉토리내에 있습니다.LOAD DATA INFILE 스테이트먼트가 중단되고 있었을 경우, replication를 재개하기 위해서 슬레이브는 이러한 파일을 필요로 합니다.디렉토리의 장소는,--slave-load-tmpdir 옵션을 사용해 지정합니다.지정하지 않으면, 디폴트치는 tmpdir 변수의 값이 됩니다.

4.11.4. replication의 셋업 방법

이하, 버젼 4.1 의 MySQL 서버에 대한 완전한 replication의 셋업 방법에 대해 간단하게 설명합니다. 모든 데이타베이스의 replication를 희망해, 과거에 replication의 설정을 전혀 가서 않은 경우를 전제로 하고 있습니다. 이하의 순서를 실행하려면 , 마스터 서버를 일단 슛다운 할 필요가 있습니다.

이하 순서에서는,1 개의 슬레이브를 셋업 하고 있을 뿐입니다만, 똑같이 복수의 슬레이브를 셋업 할 수 있습니다.

이 방법이 가장 간단하고 알기 쉽습니다만, 유일한 방법이 아닙니다.예를 들어, 마스터의 데이터의 snapshot가 벌써 있어, 마스터에 서버 ID 하지만 설정되어 바이너리 로그가 유효하게 되어 있으면, 마스터를 슛다운 하거나 갱신을 블록 하지 않아도 슬레이브를 셋업 할 수 있습니다.상세한 것에 대하여는, 항4.11.9. 「replication FAQ 」 (을)를 참조해 주세요.

MySQL replication의 셋업을 관리하는 경우는, 이 장전체를 잘 읽어, 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 및 항4.11.8. 「슬레이브 서버를 제어한다 SQL 스테이트먼트」 그리고 설명 떠날 수 있어 모든 커멘드를 시험해 보세요.또, 항4.11.6. 「replication 스타트 업 옵션」 그리고 설명되고 있다 my.cnf 의 replication 스타트 업 옵션에도 정통해 주세요.

주의: 여기서의 순서 및 후속 섹션으로 설명하는 replication SQL 스테이트먼트의 실행에는,SUPER 권한이 필요합니다.MySQL 4.0.2 보다 전에서는, 대신에 PROCESS 권한을 사용합니다.

  1. 마스터와 슬레이브에 MySQL 의 최근의 버젼이 인스톨 되고 있는 것을 확인한다.또, 항4.11.2. 「replication 실장의 개요」 의 겉(표)로, 그러한 버젼에 호환성이 있는 것을 확인한다.

    버그에 대해서는, 그 문제가 최신의 릴리스로 존재하는 것을 확인하고 나서 보고하는 것.

  2. 슬레이브 서버가 접속에 사용한다 MySQL 유저를 마스터 서버로 설정한다.이 유저에게는,REPLICATION SLAVE 권한을 줄 필요가 있다(MySQL 버젼이 4.0.2 보다 낡은 경우는, 대신에 FILE 권한을 준다).MySQL 유저가 replication 목적만의 것이면(추천), 그 밖에 권한을 설정할 필요는 없다.

    슬레이브의 호스트명을, 각 슬레이브 서버가 그 유저를 사용해 마스터에 접속할 수 있도록 설정한다.예를 들어, 어느 호스트로부터에서도 마스터에 액세스 할 수 있다 repl (이)라는 이름의 유저를 작성하려면 , 이하의 커멘드를 사용한다.

    mysql> GRANT REPLICATION SLAVE ON *.* TO repl@'%' IDENTIFIED BY '<password>';

    MySQL 버젼이 4.0.2 보다 낡은 경우는, 대신에 이하의 커멘드를 사용한다.

    mysql> GRANT FILE ON *.* TO repl@'%' IDENTIFIED BY '<password>';

    LOAD TABLE FROM MASTER 스테이트먼트 또는 LOAD DATA FROM MASTER 스테이트먼트를 슬레이브 호스트로부터 사용할 예정이면, 이 MySQL 유저에게 한층 더 권한을 설정할 필요가 있다.

    • MySQL 유저에게 SUPER 및 RELOAD 의 각 글로벌 권한을 설정한다.

    • 로드 대상의 모든 테이블에 대한다 SELECT 권한을 설정한다.MySQL 유저가 SELECT (을)를 실행할 수 없는 마스터 테이블은,LOAD DATA FROM MASTER 그리고 무시된다.

  3. MyISAM 테이블을 사용하는 경우,FLUSH TABLES WITH READ LOCK 커멘드를 실행해 모든 테이블을 플래시 해, 쿼리 기입을 블록 한다.

    mysql> FLUSH TABLES WITH READ LOCK;

    그리고, 마스터 서버의 데이터의 snapshot을 찍는다.

    snapshot를 작성하는 가장 간단한 방법은, 어카이브(archive) 프로그램(Unix 그럼 tar ,Windows 그럼 PowerArchiver ,WinRAR ,WinZip 등)을 사용하고, 마스터의 데이터 디렉토리에 데이타베이스의 어카이브(archive)를 작성하는 것이다. 예를 들어,tar (을)를 사용해 모든 데이타베이스를 포함한 어카이브(archive)를 작성하려면 , 커런트 디렉토리를 마스터 서버의 데이터 디렉토리로 변경하고, 이하의 커멘드를 실행한다.

    shell> tar -cvf /tmp/mysql-snapshot.tar .

    this_db (이)라는 이름의 데이타베이스만을 어카이브(archive)에 포함하는 경우는, 이하의 커멘드를 사용한다.

    shell> tar -cvf /tmp/mysql-snapshot.tar ./this_db

    그리고 archive파일을, 슬레이브 서버 호스트의 /tmp 디렉토리에 카피한다.그 머신으로, 커런트 디렉토리를 슬레이브의 데이터 디렉토리로 변경해, 이하의 커멘드를 사용해 archive파일을 unpack 한다.

    shell> tar -xvf /tmp/mysql-snapshot.tar

    경우에 따라서는,mysql 데이타베이스의 replication가 필요하지 않은 것도 있다.그 경우는, 어카이브(archive)로부터 이 데이타베이스를 제외할 수 있다.또, 어카이브(archive)에, 로그 파일, 즉 master.info 파일 또는 relay-log.info 파일을 포함할 필요는 없다.

    FLUSH TABLES WITH READ LOCK 에 의해서 걸 수 있었던 독해 락이 유효한 동안에, 마스터상의 현재의 바이너리 로그명과 오프셋치를 읽어낸다.

    mysql > SHOW MASTER STATUS;
+---------------+----------+--------------+------------------+
| File          | Position | Binlog_Do_DB | Binlog_Ignore_DB |
+---------------+----------+--------------+------------------+
| mysql-bin.003 | 73       | test,bar     | foo,manual,mysql |
+---------------+----------+--------------+------------------+
1 row in set (0.06 sec)

    File 컬럼은 로그의 이름을,Position (은)는 오프셋을 나타낸다.상기의 예에서는, 바이너리 로그치는 mysql-bin.003 그리고 오프셋은 73 이다.값을 기록해 둔다.다음에 슬레이브를 셋업 할 경우에, 이러한 값이 필요하다.

    snapshot를 작성해 로그명과 오프셋을 기록하면, 마스터의 기입을 재차 유효하게 할 수 있다.

    mysql> UNLOCK TABLES;

    InnoDB 테이블을 사용하고 있는 경우,InnoDB Hot Backup 툴을 사용하는 것이 이상적이다.이 툴은,MySQL 코머셜 라이센스, 서포트, 또는 백업 툴 그 자체를 구입하는 것에 의해서 사용할 수 있다.이 툴은, 마스터 서버를 일절 잠그지 않고 정합한 snapshot를 작성해, 다음에 슬레이브로 사용할 수 있도록, snapshot에 대응하는 로그명과 오프셋을 기록한다.이 툴의 상세한 것에 대하여는,http://www.innodb.com/order.php (을)를 참조.

    Hot Backup 툴을 사용하지 않고,InnoDB 테이블의 snapshot를 작성하는 가장 빠른 방법은, 마스터 서버를 슛다운 해,InnoDB 의 데이터 파일과 로그, 및 테이블 정의 파일(.frm )(을)를 카피하는 것이다.현재의 로그 파일과 오프셋을 기록하려면 , 서버를 슛다운 하기 전에 이하를 실행한다.

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

    다음에,SHOW MASTER STATUS 의 출력으로부터 로그명으로 오프셋을 앞에 두고 둔다.로그명으로 오프셋을 가까이 두면, 테이블의 락을 해제하지 않고 서버를 슛다운 한다.락을 해제하지 않는 것은, snapshot가 현재의 로그 파일과 오프셋에 대응하고 있는 상태를 유지하기 위해(때문에)이다.

    shell> mysqladmin -uroot shutdown

    MyISAM 테이블과 InnoDB 테이블의 양쪽 모두에 적용할 수 있는 대체 수단으로서 상기의 바이너리 카피 대신에, 마스터의 SQL 덤프를 사용할 수 있다.이것을 실시하려면 , 마스터로 mysqldump --master-data (을)를 실행해, 다음에 그 SQL 덤프를 슬레이브에 실행한다.다만, 이것은 바이너리 카피보다 시간이 걸린다.

    마스터가,--log-bin (을)를 유효하게 하지 않고 가동하고 있었을 경우,SHOW MASTER STATUS 또는 mysqldump 그리고 표시되는 로그명과 위치의 값은 공백이 된다.이 경우는, 로그명으로서 공백 문자열('' )(을)를, 오프셋치로서 4 (을)를 기록해 둔다.

  4. 마스터 호스트의 my.cnf 파일의 [mysqld] 섹션에 log-bin 옵션이 포함되어 있는 것을 확인한다.이 섹션에는,server-id=master_id 옵션도 포함되어 있을 필요가 있다.여기서,master_id (은)는,1 (으)로부터 2^32 - 1 까지의 정수치이다.다음에 예를 나타낸다.

    [mysqld]
log-bin
server-id=1

    이러한 옵션이 없으면, 추가하고 나서, 서버를 재기동한다.

  5. 슬레이브 서버로서 사용하는 서버를 정?~ 해, 그 my.cnf 파일에 이하를 추가한다.

    [mysqld]
server-id=slave_id

    slave_id 값은 master_id 값과 같이,1 (으)로부터 2^32 - 1 까지의 정수치이다.게다가 슬레이브의 ID (은)는 마스터의 ID (와)과 다르고 있는 것이 매우 중요하다.다음에 예를 나타낸다.

    [mysqld]
server-id=2

    복수의 슬레이브를 셋업 하는 경우, 각각의 server-id 하지만 마스터의 것과 달리, 또 슬레이브끼리라도 다르도록(듯이) 한다.server-id 의 값은 IP 주소와 같은 것이라고 생각해도 좋다.이러한 ID (은)는, 레프리케이션파트나의 코?~ 니티내에서, 각 서버 인스턴스를 일의에 식별한다.

    server-id 값을 지정하지 않는 경우,master-host (을)를 지정하고 있지 않으면 1 (으)로 설정된다.그 이외는 2 (으)로 설정된다.주의: server-id 하지만 없으면, 마스터는 모든 슬레이브로부터의 접속을 거부해, 슬레이브는 마스터에의 접속을 거부한다.따라서,server-id 의 생략은 바이너리 로그에 의한 백업에서만 정당화 된다.

  6. 마스터 서버의 데이터의 바이너리 백업을 작성했을 경우, 슬레이브를 개시하기 전에, 이 백업을 슬레이브 서버의 데이터 디렉토리에 카피한다.파일 및 디렉토리의 권한이 올바른 것을 확인한다.MySQL (을)를 실행하고 있는 유저에게는, 마스터와 같이, 그러한 파일 및 디렉토리에 대한 독해 및 써 권한이 필요하다.

    mysqldump (을)를 사용해 백업을 작성했을 경우, 최초로 슬레이브를 개시한다(다음의 스텝을 참조).

  7. 슬레이브 서버를 기동한다.replication를 실행하고 있었을 경우에는,--skip-slave-start 옵션으로 슬레이브 서버를 기동한다.또,--log-warnings 옵션을 사용해 슬레이브 서버를 기동하는 것도 좋다.그렇다면, 문제(네트워크나 접속 관련등의 문제)에 관한 메세지가 많이 출력된다.

  8. mysqldump (을)를 사용해 마스터 서버의 데이터의 백업을 작성했을 경우, 덤프 파일을 슬레이브 서버에 로드한다.

    shell> mysql -u root -p < dump_file.sql

  9. <> 안의 값을 실제의 시스템의 값에 옮겨놓고, 슬레이브로 이하의 커멘드를 실행한다.

    mysql> CHANGE MASTER TO
    ->     MASTER_HOST='<master host name>',
    ->     MASTER_USER='<replication user name>',
    ->     MASTER_PASSWORD='<replication password>',
    ->     MASTER_LOG_FILE='<recorded log file name>',
    ->     MASTER_LOG_POS=<recorded log offset>;

    이하의 겉(표)는, 이러한 변수의 최대 문자열장이다.

    MASTER_HOST | 60
    MASTER_USER | 16
    MASTER_PASSWORD | 32
    MASTER_LOG_FILE | 255

  10. 스레이브스레드를 개시한다.

    mysql> START SLAVE;

이 순서를 완료하면, 슬레이브는 마스터에 접속해, snapshot 이후의 갱신을 실행합니다.

마스터에 server-id (을)를 설정하는 것을 잊었을 경우, 슬레이브는 마스터에 접속할 수 없습니다.

슬레이브에 server-id (을)를 설정하는 것을 잊었을 경우, 에러 로그에 이하의 에러가 출력됩니다.

Warning: one should set server_id to a non-0 value if master_host is set.
The server will not act as a slave.

다른 이유로 슬레이브가 replication를 실행할 수 없는 경우도, 슬레이브의 에러 파일에 에러 메세지가 표시됩니다.

슬레이브가 replication를 개시하면, 그 데이터 디렉토리에 master.info 파일과 relay-log.info 파일이 작성됩니다.슬레이브는 이것들 2 개의 파일을 사용하고, 마스터의 바이너리 로그의 처리 진척을 기록합니다.완전하게 이해하고 있지 않는 한, 이러한 파일을 삭제하거나 편집 하지 말아 주세요 .충분히 이해해 실시하는 경우에는,CHANGE MASTER TO 커멘드의 사용을 추천 합니다.

주의: master.info 의 내용에는, 커멘드 라인 또는 my.cnf 그리고 지정되는 옵션에서 우선되는 것이 있습니다. 상세한 것에 대하여는, 항4.11.6. 「replication 스타트 업 옵션」 (을)를 참조해 주세요.

snapshot를 한 번 작성하면, 그것을 사용해 상기 순서의 슬레이브의 부분을 반복하고, 다른 슬레이브를 설정할 수 있습니다.마스터의 snapshot를 새롭게 작성할 필요는 없습니다.

4.11.5. replication 기능과 기존의 문제

이하, 서포트되고 있는 것으로 서포트되어 있지 않은 것에 대해 설명합니다.

  • replication는,AUTO_INCREMENT ,LAST_INSERT_ID() , 및 TIMESTAMP 의 값으로 올바르게 실행된다.

  • USER() 함수 및 LOAD_FILE() 함수는 변경없이 레프리케이트 되기 위해, 슬레이브에서는 잘 기능하지 않는다.이것은,4.1.1 보다 낡은 버젼의 슬레이브의 CONNECTION_ID() 에도 들어맞는다. MySQL 4.1 의 새롭다 PASSWORD() 함수는,4.1.1 이?~ 의 마스터에서는 정상적으로 레프리케이트 할 수 있지만, 슬레이브가 4.1.0 이?~ 인 것이 전제 조건이 된다.슬레이브가 낡고,PASSWORD() (을)를 4.1.x 마스터로부터 레프리케이트 할 필요가 있는 경우,--old-password 옵션으로 마스터를 기동한다.

  • SQL_MODE ,UNIQUE_CHECKS ,SQL_SELECT_LIMIT ,SQL_AUTO_IS_NULL ,TABLE_TYPE 의 각 변수는 현재로서는 레프리케이트 되지 않는다.FOREIGN_KEY_CHECKS (은)는 버젼 4.0.14 (으)로부터 레프리케이트 된다.

  • 마스터와 슬레이브에서는, 같은 캐릭터 세트(--default-character-set )(을)를 사용할 필요가 있다.그렇게 하지 않으면 마스터의 캐릭터 세트로 일의라고 인식되는 키가, 슬레이브의 캐릭터 세트에서는 일의라고 보여지지 않는 경우가 있기 위해, 슬레이브로 중복 키 에러가 발생할 가능성이 있다.

  • 마스터로 트랜잭션(transaction) 테이블을 사용해, 슬레이브로 비트랜잭션(transaction) 테이블을 사용(동일 테이블로)하고 있는 경우, 슬레이브가 BEGIN/COMMIT 블록의 도중에 정?~ 그러자(면), 다음 번 슬레이브가 BEGIN 블록의 처음부터 개시한다고 하는 문제가 발생한다. 이 문제는 가까운 장래, 해결할 예정이다.

  • 유저 변수를 사용하는 갱신 쿼리는,3.23 및 4.0 그리고 정상적으로 레프리케이트 되지 않는다.이것은 4.1 그리고 해결되고 있다.주의: 버젼 5.0 이?~ , 유저 변수명의 대문자와 소문자는 구별되지 않게 되므로,5.0 (와)과 그 전의 버젼과의 사이에 replication를 설정할 때는 주의가 필요하다.

  • 마스터와 슬레이브가 양쪽 모두 4.1.1 이?~ 의 경우, 슬레이브는 SSL (을)를 사용해 마스터에 접속할 수 있다.

  • 실제로 발생한 예를 (들)물었던 적은 없지만, 데이터의 변경이 비결정론적, 즉 쿼리Optimizer의 판단으로 행해지도록(듯이) 쿼리가 설계되고 있는 경우(replication외에서도, 통상, 이 방법은 적절한 방법이 아니다), 논리적이게는, 마스터와 슬레이브의 데이터가 다를 가능성이 있다.상세한 것에 대하여는, 항1.8.6.2. 「MySQL 의 미해결의 버그와 설계상의 문제」 (을)를 참조.

  • MySQL 4.1.1 보다 전에서는,FLUSH ,ANALYZE ,OPTIMIZE ,REPAIR 의 각 커멘드는 바이너리 로그에 보존되지 않고, 따라서 슬레이브에 레프리케이트 되지 않는다.이러한 커멘드는 아무것도 변경하지 않기 때문에, 통상은 문제는 아니다.그러나,GRANT 스테이트먼트를 사용하지 않고 MySQL 권한 테이블을 직접 갱신해,mysql 권한 테이블을 레프리케이트 했을 경우, 새로운 권한을 유효화하려면 , 슬레이브로 FLUSH PRIVILEGES (을)를 실행하는 것이 필요하다.또,MERGE 테이블에 포함된다 MyISAM 테이블의 이름을 변경할 경우에 FLUSH TABLES (을)를 사용했을 경우, 슬레이브로 FLUSH TABLES (을)를 수동으로 실행할 필요가 있다. MySQL 4.1.1 이?~ ,NO_WRITE_TO_BINLOG (또는 앨리어스(alias)의 LOCAL )(을)를 지정하지 않는 한, 이러한 커멘드는 바이너리 로그에 써진다(FLUSH LOGS ,FLUSH MASTER ,FLUSH SLAVE ,FLUSH TABLES WITH READ LOCK (은)는 제외하다). 구문예에 대해서는, 항4.6.4. 「FLUSH 구문」 (을)를 참조.

  • MySQL (은)는,1 개의 마스터와 복수의 슬레이브 구성만 서포트한다.장래는, 경향 마스터로 문제가 발생했을 경우에 마스터를 자동 변경하는 알고리즘을 추가할 예정이다.또, 복수의 슬레이브에 SELECT 쿼리를 송신하는 것에 의해서 load sharing를 실시한다 `` 에이전트'' 처리도 도입할 예정이다.

  • 텐포라리테이불도 레프리케이트 된다.다만, 스레이브스레드 뿐만이 아니라 슬레이브 서버도 슛다운 해, 그 때, 아직 슬레이브로 실행하고 있지 않는 갱신 스테이트먼트로 사용되는 텐포라리테이불을 레프리케이트 하고 있었을 경우, 그 텐포라리테이불은 레프리케이트 되지 않는다.슬레이브를 슛다운 하면, 다음 번, 슬레이브를 기동했을 때, 갱신에 필요한 텐포라리테이불은 이용할 수 없다.이 문제를 회피하려면 , 텐포라리테이불이 열려 있는 동안, 슬레이브를 슛다운 하지 않는다.대신에, 이하의 순서를 실행한다.

    1. STOP SLAVE 스테이트먼트를 실행한다.

    2. SHOW STATUS (을)를 사용하고,Slave_open_temp_tables 변수의 값을 체크한다.

    3. 값이 0 이면,mysqladmin shutdown 커멘드를 실행해 슬레이브를 슛다운 한다.

    4. 값이 0 (이)가 아니면,START SLAVE 그리고 스레이브스레드를 재개한다.

    5. 다음 번도 상기 순서를 반복한다.

    이 문제는, 가까운 장래 해결할 예정이다.

  • log-slave-updates (을)를 유효하게 하면, 순환적인 마스터/ 슬레이브 관계로 서버를 접속해도 안전하다.주의: 다만, 다른 서버간으로, 다른 순서로 간 갱신이 일으킬 문제를 처리하도록(듯이), 클라이언트 코드를 기술해 두지 않으면, 많은 쿼리는 이런 종류의 셋업으로 올바르게 기능하지 않는다.

    즉, 이하와 같은 셋업이 가능하다.

    A -> B -> C -> A

    서버 ID (은)는, 바이너리 로그 이벤트내에서 encode 된다.A (은)는,A 하지만 작성한 이벤트를 인식할 수 있으므로,A (은)는 그 이벤트를 실행하지 않고, 엔들레스 루프는 발생하지 않는다.그러나, 이 순환 셋업은, 테이블간에 경합이 생기지 않는 갱신만을 실시하고 있는 경우 밖에 기능하지 않는다.즉,A (와)과 C 에 데이터를 삽입하는 경우,C (으)로의 레코드 삽입과 경합 하는 키의 레코드를 A 에 삽입할 수 없다.또, 갱신이 적용되는 순서가 중요한 경우,2 개의 서버로 같은 복수의 레코드를 갱신하는 것도 할 수 없다.

  • 슬레이브로 쿼리에 에러가 발생하면, 슬레이브의 SQL 스레드는 강제 종료해, 슬레이브 에러 로그에 메세지가 써진다.이 경우, 슬레이브에 수동으로 접속해, 에러의 원인(테이블이 존재하지 않는 등)을 해결해,START SLAVE (을)를 실행한다.

  • 마스터에의 접속이 없어졌을 경우, 슬레이브는 곧바로 재접속을 시행한다.그것이 실패했을 경우, 슬레이브는 master-connect-retry 초(디폴트는 60 ) 마다 재시행한다.이 때문에, 마스터를 슛다운 해, 당분간 다음에 재기동해도 안전하다.슬레이브는 또, 네트워크 접속정?~ 에도 대응할 수 있다.다만, 슬레이브가 네트워크정?~ (을)를 인식하는 것은, 마스터로부터 slave_net_timeout 초간, 어떤 데이터도 받지 않았던 다음에 있다.그 때문에, 네트워크정?~ 의 시간이 짧은 경우는,slave_net_timeout 의 값을 작게 해야 한다. See 항4.6.8.4. 「SHOW VARIABLES 」 .

  • 슬레이브의 슛다운을 깨끗하게 실시하면, 어디서 replication가 종료했는지 기록되므로, 안전하다.깨끗하지 않은 슛다운에서는, 시스템 종료전에 디스크 캐쉬 프로그램이 동기화 되어 있지 않은 경우는 특히, 문제가 발생할 가능성이 있다.성능이 높은 UPS 장치를 준비하면, 시스템의 내장해성은 꽤 향상한다.

  • MyISAM 테이블의 비트랜잭션(transaction)성에 의해, 테이블의 갱신을 일부만 실행하고 에러 코드를 돌려주는 쿼리가 나타날 가능성이 있다.복수 레코드 삽입으로 1 개의 레코드가 키 제약에 위반하고 있었을 경우나, 긴 갱신 쿼리가 일부의 레코드만을 갱신한 후에 강제 종료되었을 경우에, 발생한다.이것이 마스터로 발생했을 경우, 에러 코드가 정당하고, 한편 쿼리 실행 결과도 같은 에러 코드였을 때 이외, 스레이브스레드는 종료해, 데이타베이스 관리자의 판단을 기다린다.이 에러 코드 확인 동작이 바람직하지 않은 경우는,--slave-skip-errors 옵션으로 일부(또는 전부)의 에러를 무시할 수 있다.이 옵션은,MySQL 버젼 3.23.47 보다 사용 가능.

  • BEGIN/COMMIT 세그먼트(segment) 내부에서, 비트랜잭션(transaction) 테이블에서 트랜잭션(transaction) 테이블을 갱신하는 경우, 트랜잭션(transaction)가 코?~ 트 하기 전에 비트랜잭션(transaction) 테이블을 변경하는 스레드가 있으면, 바이너리 로그에의 갱신이 비동기가 된다.이것은, 트랜잭션(transaction)의 바이너리 로그에의 기입이 코?~ 트 후에 행해지기 때문에 있다.

  • 버젼 4.0.15 보다 전에서는, 비트랜잭션(transaction) 테이블에의 갱신은, 갱신 실행 후 곧바로 바이너리 로그에 써져 트랜잭션(transaction) 테이블에의 변경은,COMMIT 시간에 써지는지, 또는 ROLLBACK (을)를 사용했을 경우는 전혀 써지지 않다.백업 또는 replication로 바이너리 로그를 사용하는 경우, 동일 트랜잭션(transaction)로 트랜잭션(transaction) 테이블과 비트랜잭션(transaction) 테이블의 갱신을 실시할 때는, 이 점에 주의하지 않으면 안 된다.트랜잭션(transaction) 테이블과 비트랜잭션(transaction) 테이블의 갱신이 혼재한 트랜잭션(transaction)로의 로그 동작은, 버젼 4.0.15 그리고 변경되어 이 문제는 해결되었다(바이너리 로그로의 쿼리의 기입 순서에 문제는 없어져,ROLLBACK 의 경우에서도 필요한 쿼리는 모두 바이너리 로그에 써지게 되었다).다만, 최초의 접속의 트랜잭션(transaction)가 완료하고 있지 않는 시점에서,2 번째의 접속이 비트랜잭션(transaction) 테이블을 갱신했을 경우의 문제는 남아 있다(2 번째의 접속의 갱신은 실행 후 곧 써지기 위해, 차례가 혼란할 가능성은 아직 있다).

이하의 겉(표)는,MySQL 3.23 그리고 문제였던 물건을 MySQL 4.0 그리고 해결한 사항입니다.

  • LOAD DATA INFILE (은)는, 갱신 전달시에 데이터 파일이 마스터 서버에 있으면, 올바르게 처리된다.

  • LOAD LOCAL DATA INFILE (은)는 스킵 된다.

  • 3.23 그럼, 갱신내의 RAND() (은)는 올바르고 레프리케이트 되지 않았다.RAND() 하지만 포함되는 갱신을 레프리케이트 하고 있는 경우는,RAND(some_non_rand_expr) (을)를 사용한다. 예를 들어,RAND() 에의 인수에 UNIX_TIMESTAMP() (을)를 사용할 수 있다.이것은 4.0 그리고 해결되었다.

4.11.6. replication 스타트 업 옵션

마스터와 슬레이브의 양쪽 모두로,server-id 옵션을 사용해 각 서버에 일의의 replication ID (을)를 설정할 필요가 있습니다.마스터와 서버 각각,1 (으)로부터 2^32 - 1 까지의 정수로부터 일의의 번호를 할당합니다. 예를 들어,server-id=3 (와)과 같이 설정합니다.

마스터 서버로 사용할 수 있는, 바이너리 로그를 제어하는 옵션에 대해서는, 항4.10.4. 「바이너리 로그」 그리고 설명하고 있습니다.

이하의 겉(표)는, 슬레이브 서버로 사용할 수 있는 옵션을 설명한 것입니다. 커멘드 라인 또는 옵션 설정 파일로 지정할 수 있습니다.

주의: replication에서는, 이하의 옵션을 특수한 방법으로 처리합니다.

  • --master-host

  • --master-user

  • --master-password

  • --master-port

  • --master-connect-retry

슬레이브 서버의 기동시에 master.info 파일이 존재하지 않는 경우, 옵션 설정 파일 또는 커멘드 라인으로 지정한 값이 사용됩니다.이것은, 서버를 replication 슬레이브로서 처음으로 기동했을 경우나,RESET SLAVE (을)를 실행해 슬레이브 서버를 슛다운 해, 재기동했을 경우 등에 일어나는 것입니다.

슬레이브 서버의 기동시에 master.info 파일이 존재하는 경우는, 이 파일의 값이 사용됩니다.옵션 설정 파일 또는 커멘드 라인의 대응하는 옵션치는 무시 됩니다.

my.cnf 파일로 다음의 옵션을 지정해 있으면 가정합니다.

[mysqld]
master-host=this_host

서버를 replication 슬레이브로서 처음으로 기동했을 때, 서버는 my.cnf 파일로부터 이 옵션을 읽어내 사용합니다.서버는 다음에 그 값을 master.info 파일에 기록합니다.다음 번 서버를 기동했을 때, 서버는 master.info 파일로부터 마셔 마스터 호스트치를 읽어냅니다.my.cnf 파일을 변경해 다른 마스터 호스트를 지정해도, 반영되지 않습니다.마스터 호스트치를 변경하고 싶은 경우에는, CHANGE MASTER TO (을)를 사용할 필요가 있습니다.

MySQL 4.1.1 이?~ , 이하의 옵션도 특수한 방법으로 처리됩니다.

  • --master-ssl

  • --master-ssl-ca

  • --master-ssl-capath

  • --master-ssl-cert

  • --master-ssl-cipher

  • --master-ssl-key

이러한 옵션에 대응하는 값이 master.info 파일에 포함되어 있습니다.더하고,4.1.1 의 파일 형식에서는, 최초의 행에, 파일내의 행수가 나타납니다.낡은 서버를 4.1.1 에 업그레이드 하면, 새로운 서버의 기동시에,master.info (은)는 자동적으로 새로운 형식에 업그레이드 됩니다(4.1.1 이?~ 의 것을 4.1.1 보다 전의 버젼에 다운 그레이드 했을 경우, 낡은 서버를 최초로 기동하기 전에, 파일의 최초의 행을 수동으로 삭제할 필요가 있습니다).

서버는, 스타트 업 옵션보다 기존의 master.info 파일을 우선하므로, 경우에 따라서는, 이러한 값에는 스타트 업 옵션을 사용하지 않고,CHANGE MASTER TO 스테이트먼트를 사용해 지정하는 것이 적합합니다. 항4.11.8.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

이하의 일람은, replication 제어에 사용할 수 있는 스타트 업 옵션의 설명입니다.

  • --log-slave-updates

    슬레이브의 SQL 스레드로 실행된 갱신을, 슬레이브의 바이너리 로그에 기록하도록(듯이) 슬레이브에 지시한다.디폴트에서는 오프.이 옵션을 유효하게 하려면 , 바이너리 로그를 유효하게 해(--log-bin 옵션을 사용해) 슬레이브를 기동할 필요가 있다.replication 서버를 체인장에 구성하려면 ,--log-slave-updates (을)를 사용한다.예를 들어, 다음과 같이 셋업 할 수 있다.

    A -> B -> C

    A (은)는 슬레이브 B 의 마스터로서 기능해,B (은)는 슬레이브 C 의 마스터로서 기능한다.B 하지만 마스터이기도 하고, 슬레이브이기도 한 이 구성에서는,--log-slave-updates 옵션으로 B (을)를 기동할 필요가 있다.A (와)과 B (은)는 양쪽 모두, 바이너리 로그를 유효하게 해 기동할 필요가 있다.

  • --log-warnings

    슬레이브에 의해 상세한 메세지를 출력시킨다.예를 들어, 네트워크 또는 접속이 절단 된 다음에 재접속에 성공했다고 하는 메세지나, 각 스레이브스레드가 어떻게 개시했는지를 붙은 정보 메세지를 출력할 수 있다.

    이 옵션은 replication의 사용에만 한정되지 않는다.다양한 서버 액티버티에 관한 통지를 출력한다.

  • --master-host=host

    마스터 replication 서버의 호스트명 또는 IP 주소를 지정한다.이 옵션을 지정하지 않으면, 스레이브스레드는 개시할 수 없다.master.info 의 값을 읽어낼 수 있는 경우는, 파일에 쓰여져 있는 값이 우선된다.이 옵션명은 --bootstrap-master-host 등에 해야 했다고 말하는 의견도 있지만, 현재, 그대로 --master-host 하지만 사용되고 있다.

  • --master-user=username

    마스터에의 접속시, 스레이브스레드가 인증에 사용하는 어카운트의 유저명.어카운트에는 REPLICATION SLAVE 권한이 필요(MySQL 4.0.2 보다 전에서는,FILE 권한이 필요).마스터 유저가 설정되어 있지 않은 경우, 유저 test (와)과 상정한다.master.info 의 값을 읽어낼 수 있는 경우는, 이 값이 우선된다.

  • --master-password=password

    마스터에의 접속시, 스레이브스레드가 인증에 사용하는 어카운트의 패스워드.설정하지 않으면, 공백 패스워드라고 보여진다.master.info 의 값을 읽어낼 수 있는 경우는, 이 값이 우선된다.

  • --master-port=port_number

    마스터가 릿슨 하는 포토.설정하지 않으면,MYSQL_PORT 의 컴파일 된 설정이 채용된다.configure 옵션을 사용하고 있지 않으면, 이것은 3306 된다.master.info 의 값을 읽어낼 수 있는 경우, 그 값이 우선된다.

  • --master-connect-retry=seconds

    마스터가 다운했을 경우, 또는 접속이 없어졌을 경우, 스레이브스레드가 마스터에의 접속을 재시행하기 전에, sleeve 상태로 대기하는 초수.디폴트는 60 이다.master.info 의 값을 읽어낼 수 있는 경우는, 그 값이 우선된다.

  • --master-info-file=filename

    슬레이브가 마스터에 관한 정보를 기록하기 위한 파일명을 지정한다.디폴트에서는, 데이터 디렉토리의 mysql.info .

  • --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 사용에 의한 마스터 서버에의 안전한 replication 접속을 셋업 하기 위해서 사용한다.이러한 의미는, 항4.4.10.5. 「SSL 커멘드 라인 옵션」 그리고 설명했다 --ssl ,--ssl-ca ,--ssl-capath ,--ssl-cert ,--ssl-cipher ,--ssl-key 의 각 옵션과 같다.

    이러한 옵션은,MySQL 4.1.1 (으)로부터 사용 가능하다.

  • --max-relay-log-size=#

    릴레이 로그를 자동적으로 로테이트 할 때에 사용한다. See 항4.6.8.4. 「SHOW VARIABLES 」 .

  • --relay-log=filename

    릴레이 로그의 장소와 이름을 지정한다.이것을 사용하고, 호스트명에 의존하지 않는 릴레이 로그명을 지정할 수 있다.또, 릴레이 로그가 커지는 경향이 있어( 및 max_relay_log_size 의 값을 작게 하고 싶지 않은 경우로), 릴레이 로그를 데이터 디렉토리와는 다른 영역에 둘 필요가 있는 경우에도 이 옵션을 사용할 수 있다.혹은, 복수의 디스크에 부하를 분산해 처리 속도를 올리는 경우에도 이 옵션을 사용할 수 있다.

  • --relay-log-index=filename

    릴레이 로그인 덱스 파일의 장소와 이름을 지정한다.

  • --relay-log-info-file=filename

    relay-log.info 에 다른 이름을 지정하거나 이 파일을 데이터 디렉토리와는 다른 디렉토리에 배치한다.

  • --relay-log-purge=0|1

    릴레이 로그 파일이 불필요하게 되었을 때의 자동 퍼지를 유효 또는 무효로 한다.이것은,SET GLOBAL RELAY_LOG_PURGE=0|1 그리고 동적으로 변경할 수 있는 글로벌 변수이다.디폴트치는 1 .

    이 옵션은 MySQL 4.1.1 (으)로부터 이용 가능.

  • --relay-log-space-limit=#

    슬레이브의 전릴레이 로그의 합계 사이즈 조건을 설정한다(0 하 `` 무제한'' 그렇다고 하는 의미).슬래이브 머신의 하드 디스크가 작은 경우에 편리하다.한도에 이르면,SQL 스레드가, 쿼리를 다 실행해 불필요하게 된 릴레이 로그를 삭제할 때까지,I/O 스레드는 일시정?~ 한다(마스터의 바이너리 로그를 읽어내지 않는다).주의: 이 제한은 절대치는 아니다.SQL 스레드가 릴레이 로그를 삭제하기 위해서 한층 더 이벤트를 필요로 하는 경우가 있어, 그 경우는 삭제가 가능하게 될 때까지,I/O 스레드는 제한을 넘어 속행한다.속행하지 않으면 데드 록이 발생한다(MySQL 4.0.13 보다 전에서는 발생하고 있었다). --relay-log-space-limit (은)는,--max-relay-log-size 값의 2 배보다 작게 설정해선 안 된다.또,--max-relay-log-size 하지만 0 의 경우는 --max-binlog-size 값의 2 배보다 작게 설정해선 안 된다.작게 설정했을 경우,--relay-log-space-limit 하지만 초과하고 있기 위해서 I/O 스레드가 대기하고 있는 동안,SQL 스레드에는 퍼지 할 수 있는 릴레이 로그가 없고,I/O 스레드는 일시적으로 --relay-log-space-limit (을)를 무시하게 된다.

  • --replicate-do-table=db_name.table_name

    지정한 테이블에 대한 쿼리만 replication를 한정하도록(듯이) 스레이브스레드에 지시한다.복수의 테이블을 지정하려면 , 커멘드를 여러 차례, 각 테이블에 1 회씩 사용한다.이것은,--replicate-do-db (와)과는 대조적으로, 데이타베이스를 걸친 갱신용으로 사용한다.이 일람의 뒤의 설명을 참조.

  • --replicate-ignore-table=db_name.table_name

    지정한 테이블을 갱신하는 쿼리를 레프리케이트 하지 않는 것을 스레이브스레드에 지시한다(그 커멘드가 동시에 다른 테이블을 갱신하는 경우에서도).무시하는 테이블을 복수 지정하려면 , 커멘드를 여러 차례, 각 테이블에 1 회씩 사용한다.이것은,--replicate-ignore-db (와)과는 대조적으로, 데이타베이스를 걸친 갱신용으로 사용한다.이 일람의 뒤의 설명을 참조.

  • --replicate-wild-do-table=db_name.table_name

    지정한 와일드 카드 패턴에 일치하는 테이블에 대한 쿼리만을, replication 하는 것을 스레이브스레드에 지시한다.복수의 테이블을 지정하려면 , 커멘드를 여러 차례, 각 테이블에 1 회씩 사용한다.이것은, 데이타베이스를 걸친 갱신용으로 사용한다.이 일람의 뒤의 설명을 참조.

    례: --replicate-wild-do-table=foo%.bar% (은)는,foo 그리고 시작되는 데이타베이스의 bar 그리고 시작되는 테이블을 사용하는 갱신만을 레프리케이트 한다.

    주의: --replicate-wild-do-table=foo%.% (을)를 사용하면, 이 룰은 CREATE DATABASE 및 DROP DATABASE 에도 전파 해, 데이타베이스명이 데이타베이스 패턴(여기에서는 foo% )에 일치했을 경우, 이것들 2 개의 것한 스테이트먼트가 레프리케이트 된다(이것은,% 하지만 패턴인 것에 의해서 일으켜진다).

    와일드 카드 문자 _ (와)과 % 의 이스케이프에도 주의가 필요하다.예를 들어,my_own%db 데이타베이스(데이타베이스의 정확한 이름)의 모든 테이블을 레프리케이트 해,my1ownAABCdb 데이타베이스의 테이블은 레프리케이트 하지 않는 경우,_ 및 % (을)를 이스케이프 한다.이 경우,replicate-wild-do-table=my\_own\%db (와)과 같이 실행한다.이 옵션을 커멘드 라인으로부터 지정했을 경우, 시스템에 따라서는 \ (을)를 이스케이프 할 필요가 있다(예를 들어 bash 쉘에서는,--replicate-wild-do-table=my\\_own\\%db (이)라고 입력할 필요가 있다).

  • --replicate-wild-ignore-table=db_name.table_name

    지정한 와일드 카드 패턴에 일치하는 테이블에 대한 쿼리를 레프리케이트 하지 않는 것을 스레이브스레드에 지시한다.무시하는 테이블을 복수 지정하려면 , 커멘드를 여러 차례, 각 테이블에 1 회씩 사용한다.이것은, 데이타베이스를 걸친 갱신용으로 사용한다.이 일람의 뒤의 설명을 참조.

    례: --replicate-wild-ignore-table=foo%.bar% (은)는,foo 그리고 시작되는 데이타베이스의 bar 그리고 시작되는 테이블을 사용하는 갱신을 레프리케이트 하지 않는다.

    주의: --replicate-wild-ignore-table=foo%.% (을)를 실행하면, 룰은 CREATE DATABASE 및 DROP DATABASE 에도 전파 해, 데이타베이스명이 데이타베이스 패턴(여기에서는 foo% )에 일치와 이것들 2 개의 것한 스테이트먼트가 레프리케이트 된다(이것은,% 하지만 패턴인 것에 의해서 일으켜진다).

    와일드 카드 문자 _ (와)과 % 의 이스케이프에도 주의가 필요하다.replicate-wild-do-table 의 설명을 참조.

  • --replicate-do-db=database_name

    경향 데이타베이스(USE 에 의해서 선택된 데이타베이스)가 database_name 의 경우에, 이 데이타베이스에 대한 쿼리만을 replication 하도록(듯이) 슬레이브에 지시한다. 복수의 데이타베이스를 지정하려면 , 커멘드를 여러 차례, 각 데이타베이스에 1 회씩 사용한다.주의: UPDATE some_db.some_table SET foo='bar' 등, 데이타베이스를 걸치는 쿼리는, 다른 데이타베이스가 선택되어 있거나 데이타베이스가 선택되어 있지 않으면, 레프리케이트 되지 않는다.데이타베이스를 걸치는 갱신이 필요한 경우는,3.23.28 이?~ (을)를 사용해,--replicate-wild-do-table=db_name.% (을)를 사용한다.이 일람의 뒤의 설명을 참조.

    예상하기 힘든 동작예: 슬레이브를 --replicate-do-db=sales 그리고 기동해,USE prices; UPDATE sales.january SET amount=amount+1000; (을)를 실행했을 경우, 이 쿼리는 레프리케이트 되지 않는다.

    데이타베이스를 걸치는 갱신이 필요한 경우는, 대신에 --replicate-wild-do-table=db_name.% (을)를 사용한다.

    이 `` 경향 데이타베이스만 체크한다'' 그렇다고 하는 동작은, 복수의 데이타베이스에 걸치는 복수의 테이블의 삭제나 갱신의 경우, 커멘드로부터만으로는 쿼리를 레프리케이트해야할 것인가 어떤가 판별이 어렵다고 하는 것이 주된 이유가 된다.또, 경향 데이타베이스만 체크하는 것이 빠르다.

  • --replicate-ignore-db=database_name

    경향 데이타베이스(USE 에 의해서 선택된 데이타베이스)가 database_name 인 경우에, 이 데이타베이스에 대한 쿼리를 레프리케이트 하지 않게 슬레이브에 지시한다.무시하는 데이타베이스를 복수 지정하려면 , 커멘드를 여러 차례, 각 데이타베이스에 1 회씩 사용한다.테이블을 걸치는 갱신을 실시해, 그러한 갱신을 레프리케이트 하지 않는 경우에는, 이 옵션을 사용해서는 안된다.이 일람의 뒤의 설명을 참조.

    예상하기 힘든 동작예: 슬레이브를 --replicate-ignore-db=sales 그리고 기동해,USE prices; UPDATE sales.january SET amount=amount+1000; (을)를 실행했을 경우, 이 쿼리는 레프리케이트 된다.

    데이타베이스를 걸치는 갱신이 필요한 경우에는, 대신에 --replicate-wild-ignore-table=db_name.% (을)를 사용한다.

  • --replicate-rewrite-db=from_name->to_name

    경향 데이타베이스(USE 에 의해서 선택된 데이타베이스)가 마스터의 from_name 인 경우,to_name (으)로 변환하도록(듯이) 슬레이브에 지시한다.테이블에 관련하는 스테이트먼트만이 영향을 받아(CREATE DATABASE ,DROP DATABASE 에는 영향을 주지 않는다), 한편 from_name 하지만 마스터의 경향 데이타베이스인 경우만 영향이 있다.이것은, 데이타베이스를 걸친 갱신에는 기능하지 않는다.주의: 변환은,--replicate-* 룰이 테스트되기 전에 행해진다.

    례: replicate-rewrite-db=master_db_name->slave_db_name

  • --report-host=host

    슬레이브의 등록중에 마스터에 보고되는 슬레이브의 호스트명 또는 IP 주소.이것들은 SHOW SLAVE HOSTS 의 출력에 표시된다.슬레이브에 스스로를 마스터에 등록시키지 않는 경우, 설정하지 않는 채로 해 둔다.주의: 슬레이브의 접속 후, 마스터가 TCP/IP 소켓으로부터 슬레이브의 IP 주소를 읽어내는 것 만으로는 충분하지 않다.NAT 및 다른 루팅의 사정에 의해, 이 IP (은)는, 마스터 또는 다른 호스트로부터 슬레이브에 접속하는데 유효하지 않은 경우가 있다.

    이 옵션은 MySQL 4.0.0 (으)로부터 이용 가능.

  • --report-port=port_number

    슬레이브의 등록중에 마스터에 보고하는 슬레이브의 접속 포토.슬레이브가 디폴트 이외의 포토를 릿슨 하는 경우, 또는, 마스터나 그 외의 클라이언트와 슬레이브간에 특수한 터널이 있는 경우만, 이것을 설정한다.모르는 경우는, 이 옵션은 설정하지 않고 둔다.

    이 옵션은 MySQL 4.0.0 (으)로부터 이용 가능.

  • --skip-slave-start

    서버의 기동시에 스레이브스레드를 개시하지 않게 슬레이브 서버에 지시한다.유저가 다음에 START SLAVE (을)를 사용하고, 스레이브스레드를 개시할 수 있다.

  • --slave_compressed_protocol=#

    슬레이브와 클라이언트의 양쪽 모두가 압축을 서포트하고 있으면, 값이 1 의 경우, 그 프로토콜에 압축이 사용된다.

  • --slave-load-tmpdir=filename

    이 옵션은 디폴트에서는,tmpdir 변수의 값과 같게 된다.슬레이브 SQL 스레드가 LOAD DATA INFILE 커멘드를 레프리케이트 할 때, 로드하는 파일을 릴레이 로그로부터 임시 파일에 추출하고, 그것을 테이블에 로드한다.마스터에 로드 된 파일이 매우 큰 경우, 슬레이브의 임시 파일도 거대하게 된다.그 때문에,tmpdir (와)과는 다른 큰 디스크에 임시 파일을 두는 것이 필요하게 되는 경우에, 이 옵션을 사용한다.그 경우, 릴레이 로그도 커지기 위해,--relay-log 옵션도 사용할 수 있다.--slave-load-tmpdir (은)는, 메모리베이스가 아니고, 디스크 베이스의 파일 시스템을 포인트 하는 것이 필요.이것은,LOAD DATA INFILE 의 레프리케이트에 사용된 임시 파일이, 머신을 리부트해도 남아 있는 것이 슬레이브에 있어서 필요하기 때문에이다.

  • --slave-net-timeout=#

    접속이 절단 되었다고 판단해 접속을 재시행할 때, 그 때문에(위해) 독해를 안?~ 하기 전에, 마스터로부터의 데이터를 기다리는 초수.최초의 재시행은, 이 타임 아웃 직후에 행해진다.재시행의 간격은,--master-connect-retry 옵션으로 제어한다.

  • --slave-skip-errors= [err_code1,err_code2,... | all]

    지정한 에러를 쿼리가 돌려주어도, replication를 속행하도록(듯이) 슬레이브 SQL 스레드에 지시한다.통상, 에러가 발생하면 replication는 정?~ 해, 유저는 데이터의 부정합을 수동으로 해결할 수 있다.왜 에러 발생하는지 원인을 완전하게 이해하고 있지 않는 경우에는, 이 옵션을 사용해선 안 된다.replication의 셋업에 문제가 없고, 클라이언트 프로그램에도 버그가 없고, 및 MySQL 자체에도 버그가 없으면, 에러로 안?~ (이)가 될 것은 없을 것이다.이 옵션을 남용하면, 슬레이브가 마스터와 크고 비동기가 되어, 유저에게는 문제 발생의 원인도 모르게 된다.

    에러 코드에는, 슬레이브 에러 로그의 에러 메세지 및 SHOW SLAVE STATUS 의 출력에 나타나는 번호를 사용할 필요가 있다.에러 메세지의 전일람은, 소스 디스트리뷰션내의 Docs/mysqld_error.txt 에 기재되어 있다. 서버의 에러 코드의 일람은, 항12.1. 「돌려주어지는 에러」 에도 기재되어 있다.

    all 의 값을 사용해 모든 에러 메세지를 무시할 수도 있지만, 이것은 사용해서는 안된다.말할 필요도 없이, 그것을 사용하면 데이터의 정합성이 보증되지 않는다.사용했을 경우, 슬레이브의 데이터가 마스터의 데이터와 달라 버릴 가능성이 충분히 있다.

    례:

    --slave-skip-errors=1062,1053
--slave-skip-errors=all

이러한 옵션 중 몇개인가는, 모든 --replicate-* 옵션과 같이, 슬레이브 서버의 기동시만 설정할 수 있어 실행중은 설정할 수 없습니다.이것은, 장래 해결할 예정입니다.

이하는, 슬레이브가 쿼리를 실행하는지 무시할까를 결정하기 위한 r--eplicate-* 룰의 평가 순서입니다.

  1. --replicate-do-db 룰 또는 --replicate-ignore-db 룰이 있을까.

    • Yes: --binlog-do-db 및 --binlog-ignore-db (와)과 같이 그것들을 테스트한다(see 항4.10.4. 「바이너리 로그」 ).그 결과를 본다.

      • ignore the query: 무시해 종료한다.

      • execute the query: 빨리는 실행하지 않고, 결정을 보류해 다음의 스텝에 진행된다.

    • No: 다음의 스텝으로 옮긴다.

  2. --replicate-*-table 룰은 있을까.

    • No: 쿼리를 실행해 종료한다.

    • Yes: 다음의 스텝으로 옮긴다.갱신되는 테이블만, 룰이라고 비교된다(INSERT INTO sales SELECT * FROM prices 그럼,sales 마셔 룰이라고 비교된다).복수의 테이블이 갱신되는(복수 테이블 스테이트먼트의) 경우, 최초로 일치한 테이블(``do'' 또는 ``ignore'' (와)과 일치하는 테이블)이 대상이 된다(최초의 테이블이 룰이라고 비교되어 그래서 결정할 수 없는 경우는 2 번째의 테이블이 룰이라고 비교된다).

  3. --replicate-do-table 룰은 있을까.

    • Yes: 테이블이 어느 쪽인가에 일치할까.

      • Yes: 쿼리를 실행해 종료한다.

      • No: 다음의 스텝으로 옮긴다.

    • No: 다음의 스텝으로 옮긴다.

  4. --replicate-ignore-table 룰은 있을까.

    • Yes: 테이블이 어느 쪽인가에 일치할까

      • Yes: 쿼리를 무시해 종료한다.

      • No: 다음의 스텝으로 옮긴다.

    • No: 다음의 스텝으로 옮긴다.

  5. --replicate-wild-do-table 룰은 있을까.

    • Yes: 테이블이 어느 쪽인가에 일치할까.

      • Yes: 쿼리를 실행해 종료한다.

      • No: 다음의 스텝으로 옮긴다.

    • No: 다음의 스텝으로 옮긴다.

  6. --replicate-wild-ignore-table 룰은 있을까.

    • Yes: 테이블이 어느 쪽인가에 일치할까.

      • Yes: 쿼리를 무시해 종료한다.

      • No: 다음의 스텝으로 옮긴다.

    • No: 다음의 스텝으로 옮긴다.

  7. --replicate-*-table 룰은 모두 일치하지 않았다. 이러한 룰로 테스트하는 테이블은 그 밖에 있을까.

    • Yes: 루프 한다.

    • No: 갱신 대상의 모든 테이블을 테스트했지만, 어느 룰에도 일치하지 않았다. --replicate-do-table 또는 --replicate-wild-do-table 룰이 있을까.

      • Yes: 쿼리를 무시해 종료한다.

      • No: 쿼리를 실행해 종료한다.

4.11.7. 마스터 서버를 제어한다 SQL 스테이트먼트

replication는 SQL 인터페이스로 제어할 수 있습니다.이 섹션에서는, 마스터 replication 서버를 관리하기 위한 스테이트먼트에 대해 설명합니다. 항4.11.8. 「슬레이브 서버를 제어한다 SQL 스테이트먼트」 그럼, 슬레이브 서버를 관리하기 위한 스테이트먼트에 대해 설명하고 있습니다.

4.11.7.1. PURGE MASTER LOGS

PURGE {MASTER|BINARY} LOGS TO 'log_name'
PURGE {MASTER|BINARY} LOGS BEFORE 'date'

지정한 로그 또는 지정한 일자보다 전의, 로그인 덱스에 리스트 된 바이너리 로그를 모두 삭제합니다.로그인 덱스 파일내에 기록된 리스트로부터도 로그가 삭제되므로, 지정한 로그가 최초로 됩니다.

례:

PURGE MASTER LOGS TO 'mysql-bin.010';
PURGE MASTER LOGS BEFORE '2003-04-02 22:46:26';

BEFORE 변수는 MySQL 4.1 (으)로부터 이용 가능하게 되어 있습니다.그 일자 인수의 형식은 'YYYY-MM-DD hh:mm:ss' 입니다.MASTER (와)과 BINARY (은)는 동의어입니다만,BINARY 하 MySQL 4.1.1 이?~ 에서만 사용할 수 있습니다.

삭제하려고 하고 있는 로그의 어느쪽이든을, 액티브한 슬레이브가 읽어내 안이면, 이 커멘드는 아무것도 실행하지 않고, 에러가 됩니다.다만, sleeve 상태의 슬레이브가 있어, 그것이 다음에 읽어낼 예정의 로그를 퍼지 해 버리면, 그 슬레이브가 활동을 재개해도 replication를 실행할 수 없습니다.슬레이브가 replication를 실행중에 커멘드를 실행해도 안전합니다.중?~ 할 필요는 없습니다.

최초로 SHOW SLAVE STATUS (을)를 실행해 모든 슬레이브를 체크해, 어느 로그를 읽어내 안일까 조사해SHOW MASTER LOGS (을)를 실행해 마스터의 로그 일람을 표시합니다.모든 슬레이브로 최초의 로그를 찾아내(전슬레이브가 최신 상태에 갱신되고 있으면, 이것은 일람의 마지막 로그가 됩니다), 삭제하려고 해 모든 로그를 백업 해(임의), 목적의 로그까지를 퍼지 합니다.

4.11.7.2. RESET MASTER

RESET MASTER

인덱스 파일에 리스트 된 모든 바이너리 로그를 삭제해, 바이너리 로그인 덱스 파일을 공백에 리셋트 합니다.

이 스테이트먼트는 MySQL 3.23.26 보다 전은 FLUSH MASTER (이)라는 이름이었습니다.

4.11.7.3. SET SQL_LOG_BIN

SET SQL_LOG_BIN = {0|1}

클라이언트가 SUPER 권한의 어카운트를 사용해 접속하고 있는 경우, 현재의 접속(SQL_LOG_BIN (은)는 세션 변수)로의 바이너리 로그의 무효/ 유효를 바꿉니다.클라이언트에 그 권한이 없는 경우, 이 스테이트먼트는 무시됩니다.

4.11.7.4. SHOW BINLOG EVENTS

SHOW BINLOG EVENTS [ IN 'log_name' ] [ FROM pos ] [ LIMIT [offset,] row_count ]

바이너리 로그내의 이벤트를 표시합니다.'log_name' (을)를 지정하지 않으면, 최초의 바이너리 로그가 표시됩니다.

이 스테이트먼트는 MySQL 4.0 (으)로부터 이용 가능합니다.

4.11.7.5. SHOW MASTER STATUS

SHOW MASTER STATUS

마스터의 바이너리 로그의 스테이터스 정보를 제공합니다.

4.11.7.6. SHOW MASTER LOGS

SHOW MASTER LOGS

마스터의 바이너리 로그를 일람표 나타내 보입니다.이 커멘드는 PURGE MASTER LOGS (을)를 사용하기 전에 실행하고, 얼마나 삭제해야할 것인가 조사합니다.

4.11.7.7. SHOW SLAVE HOSTS

SHOW SLAVE HOSTS

마스터에 현재 등록되어 있는 슬레이브의 일람을 표시합니다. 주의: --report-host=slave_name 옵션으로 기동하고 있지 않는 슬레이브는, 이 일람에는 표시되지 않습니다.

4.11.8. 슬레이브 서버를 제어한다 SQL 스테이트먼트

replication는 SQL 인터페이스로 제어할 수 있습니다.이 섹션에서는, 슬레이브 replication 서버를 관리하기 위한 스테이트먼트에 대해 설명합니다. 마스터 서버를 관리하는 스테이트먼트에 대해서는, 항4.11.7. 「마스터 서버를 제어한다 SQL 스테이트먼트」 그리고 설명하고 있습니다.

4.11.8.1. CHANGE MASTER TO

CHANGE MASTER TO master_def [, master_def] ...

master_def =
      MASTER_HOST = 'host_name'
    | MASTER_USER = 'user_name'
    | MASTER_PASSWORD = 'password'
    | MASTER_PORT = port_num
    | 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}
    | 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'

슬레이브 서버가 마스터 서버와의 접속 및 통신을 위해서 사용하고 있는 파라미터를 변경합니다. 이하, 가능한 master_def 의 값을 나타냅니다.

릴레이 로그 옵션(RELAY_LOG_FILE (와)과 RELAY_LOG_POS )(은)는,MySQL 4.0 (으)로부터 이용 가능합니다.

SSL 옵션(MASTER_SSL ,MASTER_SSL_CA ,MASTER_SSL_CAPATH ,MASTER_SSL_CERT ,MASTER_SSL_KEY , 및 MASTER_SSL_CIPHER )(은)는,MySQL 4.1.1 (으)로부터 이용 가능합니다.이러한 옵션은,SSL 서포트 없이 컴파일 되고 있는 슬레이브로도 변경할 수 있습니다.이것은 master.info 파일에 보존됩니다만,SSL 서포트가 유효하게 되어 있는 서버를 사용할 때까지는 무시됩니다.

례:

mysql> 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;
mysql> CHANGE MASTER TO
    ->     RELAY_LOG_FILE='slave-relay-bin.006',
    ->     RELAY_LOG_POS=4025;

MASTER_USER ,MASTER_PASSWORD ,MASTER_SSL ,MASTER_SSL_CA ,MASTER_SSL_CAPATH ,MASTER_SSL_CERT ,MASTER_SSL_KEY , 및 MASTER_SSL_CIPHER (은)는, 슬레이브가 마스터에 접속하기 위해서 필요한 정보입니다.이러한 정보를 지정하지 않으면, 이전의 값이 그대로 사용됩니다.예를 들어,MySQL 마스터에의 접속 패스워드가 변경되었을 경우는, 이하를 실행해,

mysql> STOP SLAVE; -- if replication was running
mysql> CHANGE MASTER TO MASTER_PASSWORD='new3cret';
mysql> START SLAVE; -- if you want to restart replication

슬레이브에 대해서 새로운 패스워드를 지정합니다.변경하지 않는 정보(호스트, 포토, 유저등)에 대해서는 지정할 필요가 없습니다.

MASTER_HOST (와)과 MASTER_PORT (은)는, 마스터 호스트의 호스트명 또는 IP 주소와 그 TCP 포토입니다.주의: MASTER_HOST 하지만 localhost (와)과 같은 경우,MySQL 외 부분과 같이, 포토는 무시되는 일이 있습니다(Unix 소켓을 이용할 수 있는 경우 등).

MASTER_HOST 또는 MASTER_PORT (을)를 지정했을 경우, 슬레이브는, 마스터 서버가 이전과는 다르면 상정합니다(호스트 또는 포토의 값을 이전과 같게 지정했을 경우에서도).이 경우, 마스터 바이너리 로그의 이름과 위치의 낡은 값은 적용 불가라고 판단되기 위해, 커멘드로 MASTER_LOG_FILE (와)과 MASTER_LOG_POS (을)를 지정하지 않으면,MASTER_LOG_FILE='' (와)과 MASTER_LOG_POS=4 하지만 자동적으로 추가됩니다.

MASTER_LOG_FILE (와)과 MASTER_LOG_POS (은)는, 슬레이브의 I/O 스레드가 다음 번 개시했을 때에 마스터로부터 독해를 개시하는 장소의 좌표입니다.이러한 어느쪽이든을 지정했을 경우,RELAY_LOG_FILE 또는 RELAY_LOG_POS (을)를 지정할 수 없습니다. MASTER_LOG_FILE (와)과 MASTER_LOG_POS 의 모두 지정하지 않으면,CHANGE MASTER 발행전의 슬레이브 SQL 스레드 의 마지막 좌표가 사용됩니다.이것에 의해, 슬레이브 SQL 스레드가 슬레이브 I/O 스레드보다 늦은 경우에서도, 예를 들어 패스워드만을 변경할 때 등, replication에 중단되어가 생기지 않습니다.이 안전한 동작은,MySQL 4.0.17 (으)로부터 4.1.1 그리고 도입되었습니다.이러한 버젼의 전은,CHANGE MASTER 발행전의 슬레이브 I/O 스레드의 마지막 좌표가 사용되고 있었습니다.그 때문에,SQL 스레드가 마스터로부터의 이벤트를 잃어, replication가 파탄하는 일이 있었습니다.

CHANGE MASTER 하 모든 릴레이 로그를 삭제 합니다(신규 릴레이 로그를 개시).다만,RELAY_LOG_FILE 또는 RELAY_LOG_POS (을)를 지정했을 경우는 이것을 실행하지 않습니다.릴레이 로그는 보관 유지됩니다(MySQL 4.1.1 (으)로부터,RELAY_LOG_PURGE 글로벌 변수는 사일런트로 0 (으)로 설정됩니다).CHANGE MASTER TO (은)는,master.info (와)과 relay-log.info (을)를 갱신합니다.

CHANGE MASTER (은)는, 마스터의 snapshot가 있어, 그 snapshot가 대응하는 마스터의 로그와 오프셋을 기록하고 있을 때의 슬레이브의 셋업에 편리합니다.snapshot의 restore 후, 슬레이브로 CHANGE MASTER TO MASTER_LOG_FILE='log_name_on_master', MASTER_LOG_POS=log_offset_on_master (을)를 실행할 수 있습니다.

상기의 최초의 예(CHANGE MASTER TO MASTER_HOST='master2.mycompany.com' etc )(은)는, 마스터와 마스터의 바이너리 로그의 좌표를 변경합니다.이것은, 슬레이브에 마스터의 레프리케이트를 실행시키는 경우입니다. 2 번째의 예는, 사용 빈도는 낮습니다만, 어떠한 이유로 슬레이브의 릴레이 로그를 재차 실행하는 경우입니다.이 때, 마스터에 접속할 필요는 없고,CHANGE MASTER TO (을)를 실행해 SQL 스레드를 개시할 뿐입니다(START SLAVE SQL_THREAD ). 이것은, replication 이외로, 스탠드얼론으로 비슬레이브의 서버의 크래쉬 후의 리커버리에도 사용할 수 있습니다. 서버가 크래쉬 해, 백업을 restore 했다고 합니다. 서버의 바이너리 로그(릴레이 로그는 아니고 통상의 바이너리 로그)를 재차 실행합니다.이 로그의 이름을 myhost-bin.* (와)과 가정합니다.만일, 이하의 순서에 충실히 따르지 않고, 서버에 바이너리 로그를 퍼지 시켜 버린 사태에 대비하고, 우선, 이러한 바이너리 로그의 백업 카피를 안전한 장소에 작성해 둡니다. MySQL 4.1.1 이?~ (을)를 사용하고 있는 경우, 한층 더 안전 대책으로서 SET GLOBAL RELAY_LOG_PURGE=0 (을)를 실행합니다. 다음에,log-bin 없이, 새로운(이전과는 다른) 서버 ID ,relay-log=myhost-bin (서버에, 통상의 바이너리 로그를 릴레이 로그라고 믿어 버리게 하기 위해), 및 skip-slave-start 그리고 서버를 기동해, 이하의 스테이트먼트를 발행합니다.

mysql> CHANGE MASTER TO
    ->     RELAY_LOG_FILE='myhost-bin.153',
    ->     RELAY_LOG_POS=410,
    ->     MASTER_HOST='some_dummy_string';
mysql> START SLAVE SQL_THREAD;

서버는 스스로의 바이너리 로그를 읽어내 실행해, 크래쉬 리커버리를 달성합니다.리커버리가 완료하면,STOP SLAVE (을)를 실행해 서버를 슛다운 해,master.info (와)과 relay-log.info (을)를 삭제하고, 원의 옵션으로 서버를 재기동합니다. 현재로서는, 서버에 슬레이브이다고 믿어 버리게 하기 위해서,MASTER_HOST 의 지정(다?~ -값으로도)는 필수입니다.또, 이전과는 다른 서버 ID 의 지정도 필요합니다.그렇게 하지 않으면 서버는 자신의 ID (이)가 붙은 이벤트를 보고 순환 replication이라고 착각 해, 그 이벤트를 스킵 해 버립니다.장래, 이것들에 대처하는 옵션을 추가할 예정입니다.

4.11.8.2. LOAD DATA FROM MASTER

LOAD DATA FROM MASTER

마스터의 snapshot를 찍어, 슬레이브에 카피합니다. 슬레이브가 올바른 위치로부터 replication를 개시할 수 있도록,MASTER_LOG_FILE (와)과 MASTER_LOG_POS 의 값을 갱신합니다.replicate-* 옵션으로 지정한 테이블과 데이타베이스의 제외 룰도 적용됩니다.

이 스테이트먼트의 사용에는 이하의 조건이 있습니다.

  • 이것은,MyISAM 테이블 에 대해서만 유효.

  • snapshot의 작성중, 글로벌 독해 락이 걸리므로, 로드안의 마스터로의 갱신을 할 수 없게 된다.

장래, 이 스테이트먼트를 InnoDB 테이블에서도 사용할 수 있도록 해, 또 비블록의 온라인 백업 기능에 의해서 글로벌 독해 락의 필요성도 없앨 예정입니다.

큰 테이블을 로드할 때, 경우에 따라서는, 마스터와 슬레이브의 양쪽 모두로 net_read_timeout (와)과 net_write_timeout 의 값을 크게 하는 것이 필요하게 됩니다. 항4.6.8.4. 「SHOW VARIABLES 」 (을)를 참조해 주세요.

주의: LOAD DATA FROM MASTER (은)는,mysql 데이타베이스의 테이블을 카피 하지 않습니다 .이것은, 마스터와 슬레이브에 대해서 복수가 다른 유저와 권한을 설정하기 쉽게하기 위한 조치입니다.

이 스테이트먼트에서는, 마스터에의 접속에 사용한다 MySQL 유저가, 마스터에 대한다 RELOAD 권한과 SUPER 권한, 및 로드하는 모든 마스터 테이블에 대한다 SELECT 권한을 가지고 있는 것이 전제가 됩니다.유저에게 SELECT 권한이 없는 마스터의 테이블은 모두,LOAD DATA FROM MASTER 그럼 무시됩니다.마스터는, 그러한 테이블을 그 유저에게는 표시하지 않기 때문입니다.LOAD DATA FROM MASTER 하 SHOW DATABASES (을)를 호출해 어느 master data 베이스를 로드할까 조사합니다만,SHOW DATABASES (은)는 유저에게 권한이 있는 데이타베이스만을 돌려줍니다. 항4.6.8.1. 「데이타베이스, 테이블, 컬럼, 및 인덱스에 관한 정보의 취득」 (을)를 참조해 주세요. 슬레이브측에서는,LOAD DATA FROM MASTER (을)를 발행하는 유저에게, 해당하는 데이타베이스와 테이블을 파기 및 작성할 수 있는 권한이 필요합니다.

4.11.8.3. LOAD TABLE tbl_name FROM MASTER

LOAD TABLE tbl_name FROM MASTER

마스터로부터 슬레이브에 테이블의 카피를 다운로드합니다.이 스테이트먼트는 주로 LOAD DATA FROM MASTER (을)를 디버그 하기 위해서 도입되었습니다. 마스터 서버에의 접속에 사용한다 MySQL 유저에게, 마스터에 대한다 RELOAD 권한과 SUPER 권한, 및 로드하는 마스터 테이블에 대한다 SELECT 권한이 필요합니다. 슬레이브측에서는,LOAD TABLE FROM MASTER (을)를 발행하는 유저에게, 해당하는 테이블을 파기 및 작성하는 권한이 필요합니다. 전술의 LOAD DATA FROM MASTER 항목의 타임 아웃에 관한 설명을 참조해 주세요.여기에서도 적용됩니다.또,LOAD DATA FROM MASTER 의 제약이 여기에서도 들어맞으므로, 설명을 참조해 주세요(예를 들어,LOAD TABLE FROM MASTER 하 MyISAM 테이블에서만 사용할 수 있습니다).

4.11.8.4. MASTER_POS_WAIT()

SELECT MASTER_POS_WAIT('master_log_file', master_log_pos)

이것은 함수이며, 커멘드가 아닙니다.이것은, 마스터 바이너리 로그의 지정 위치까지 슬레이브가 달하고 있는(독해와 실행을 종료하고 있다) 것을 확인하기 위해서 사용합니다.상세한 것에 대하여는, 항6.3.6.2. 「그 외의 각종 함수」 (을)를 참조해 주세요.

4.11.8.5. RESET SLAVE

RESET SLAVE

슬레이브의 마스터 바이너리 로그로의 replication 위치를, 슬레이브에 잊게 합니다. 이 스테이트먼트는, 깨끗한 개시를 위해서 사용합니다.이것에 의해,master.info 파일과 relay-log.info 파일, 및 모든 릴레이 로그가 삭제되어 새로운 릴레이 로그가 개시됩니다. 주의: 슬레이브의 SQL 스레드에 의해서 완전하게 실행되어 있지 않은 경우에서도, 모든 릴레이 로그가 삭제됩니다(부하가 높은 replication 서버나,STOP SLAVE 스테이트먼트를 발행하고 있는 경우에 이 상태가 발생하기 쉬워집니다).master.info 파일에 보존되고 있는 접속 정보는, 대응하는 스타트 업 옵션으로 값이 지정되어 있으면, 곧바로 그 값에 리셋트 됩니다. 이 정보에는, 마스터 호스트, 마스터 포토, 마스터 유저, 및 master password등의 값이 포함됩니다. 슬레이브 SQL 스레드가 정?~ 했을 때에, 텐포라리테이불의 레프리케이트중에서 만났을 경우,RESET SLAVE 하지만 발행되어 레프리케이트 된 텐포라리테이불은 슬레이브로부터 삭제됩니다.

이 스테이트먼트는 MySQL 3.23.26 보다 전은 FLUSH SLAVE (이)라는 이름이었습니다.

4.11.8.6. SET GLOBAL SQL_SLAVE_SKIP_COUNTER

SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n

마스터의 다음의 n 이벤트를 스킵 합니다.이것은, 스테이트먼트에 의한 replication 중단을 리커버리 하는데 도움이 됩니다.

이 스테이트먼트는, 스레이브스레드가 실행하고 있지 않는 경우에게만 유효합니다. 실행중에는 에러가 됩니다.

MySQL 4.0 보다 전의 버젼을 사용하고 있는 경우에는, 스테이트먼트로부터 GLOBAL 키워드를 제외해 주세요.

4.11.8.7. SHOW SLAVE STATUS

SHOW SLAVE STATUS

스레이브스레드의 중요한 파라미터의 스테이터스 정보를 제공합니다.mysql 클라이언트를 사용해 이 스테이트먼트를 발행하는 경우, 세?~ 코론 대신에 \G 스테이트먼트 종단 기호를 사용하고, 읽기 쉬운 세로 방향의 레이아웃으로 할 수 있습니다.

mysql> SHOW SLAVE STATUS\G
*************************** 1. row ***************************
       Slave_IO_State: Waiting for master to send event
          Master_Host: localhost
          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
        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:
   Master_SSL_CA_Path:
      Master_SSL_Cert:
    Master_SSL_Cipher:
       Master_SSL_Key:
Seconds_Behind_Master: 8

MySQL 의 버젼에 따라서는, 여기서 나타내 보인 필드가 모두 표시되지 않는 경우도 있습니다.특히,MySQL 4.1.1 에게만 존재하는 필드도 있습니다.

SHOW SLAVE STATUS 그리고 표시되는 필드에는, 이하의 의미가 있습니다.

  • Slave_IO_State

    슬레이브 I/O 스레드의 SHOW PROCESSLIST 출력의 State 컬럼의 카피.이 스레드가 마스터에 접속하려고 하고 있는지, 마스터로부터의 이벤트를 기다리고 있는지, 마스터에 재접속하고 있는지, 등을 나타낸다.가능한 스테이터스에 대해서는, 항4.11.2. 「replication 실장의 개요」 (을)를 참조.스레드는 실행중이지만, 마스터와의 접속이 잘 되지 않는등의 상황에서는, 이 컬럼의 확인이 필요하다.접속으로 문제가 있는 경우에, 그것을 나타낼 수 있는 것은 이 컬럼 뿐이다.반대로,SQL 스레드의 경우, 심플하기 때문에, 그 스테이터스는 카피되지 않는다.실행중이면, 아무것도 문제는 없다.SQL 스레드가 실행하고 있지 않으면,Last_Error 컬럼(후술)에 에러가 표시된다.

    이 필드는 MySQL 4.1.1 그리고 도입되었다.

  • Master_Host

    현재의 마스터 호스트.

  • Master_User

    마스터에의 접속에 사용하는 현재의 유저.

  • Master_Port

    현재의 마스터 포토.

  • Connect_Retry

    master-connect-retry 의 현재가.

  • Master_Log_File

    I/O 스레드가 현재 독해중의 마스터의 바이너리 로그 파일명.

  • Read_Master_Log_Pos

    I/O 스레드가 마스터의 바이너리 로그로 그때까지 독해를 완료한 위치.

  • Relay_Log_File

    SQL 스레드가 현재 독해 및 실행중의 릴레이 로그 파일명.

  • Relay_Log_Pos

    SQL 스레드가 릴레이 로그내에서 그때까지 읽어내 및 실행을 완료한 위치.

  • Relay_Master_Log_File

    SQL 스레드에 의해서 실행된 마지막 이벤트를 포함한 마스터의 바이너리 로그 파일명.

  • Slave_IO_Running

    I/O 스레드가 개시되었는지를 나타낸다.

  • 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 의 각 옵션으로 테이블이 지정되어 있으면, 그 일람.

    이러한 필드는,MySQL 4.1.1 그리고 도입되었다.

  • Last_Errno

    마지막에 실행한 쿼리가 돌려준 에러 번호. 0 의 값은 `` 에러가 없다'' 일을 의미한다.

  • Last_Error

    마지막에 실행한 쿼리가 돌려준 에러 메세지. 례:

    Last_Errno: 1051
Last_Error: error 'Unknown table 'z'' on query 'drop table z'

    이 메세지는, 마스터에 있던 테이블 z 하지만 파기되고 있지만, 슬레이브에는 존재하지 않기 때문에,DROP TABLE (을)를 실행할 수 없었다고 하는 것을 나타낸다.이것은, replication의 셋업시에 테이블을 슬레이브에 카피하는 것을 잊었을 경우에 발생한다.

    공백 문자열은 `` 에러가 없다'' 일을 의미한다. Last_Error 값이 공백이 아닌 경우, 슬레이브의 에러 로그에도 메세지가 표시된다.

  • Skip_Counter

    SQL_SLAVE_SKIP_COUNTER 그리고 마지막에 사용된 값.

  • Exec_Master_Log_Pos

    마스터의 바이너리 로그(Relay_Master_Log_File ) 안의,SQL 스레드에 의해서 실행된 마지막 이벤트의 위치.마스터의 바이너리 로그의(Relay_Master_Log_File,Exec_Master_Log_Pos )(은)는, 릴레이 로그의(Relay_Log_File,Relay_Log_Pos )에 대응한다.

  • Relay_Log_Space

    기존 릴레이 로그 모든 합계 사이즈.

  • Until_Condition, Until_Log_File, Until_Log_Pos

    START SLAVE 스테이트먼트의 UNTIL 마디로 지정된 값.

    Until_Condition 에는 이하의 값이 있다.

    • None UNTIL 마디가 지정되어 있지 않은 경우.

    • Master 슬레이브가, 마스터의 바이너리 로그의 지정 위치까지를 독해중인 경우.

    • Relay 슬레이브가, 그 릴레이 로그의 지정 위치까지를 독해중인 경우.

    Until_Log_File (와)과 Until_Log_Pos (은)는,SQL 스레드가 실행을 안?~ 하는 포인트를 정의하는 로그 파일명과 위치를 나타낸다.

    이러한 필드는,MySQL 4.1.1 그리고 도입되었다.

  • Master_SSL_Allowed, Master_SSL_CA_File, Master_SSL_CA_Path, Master_SSL_Cert, Master_SSL_Cipher, Master_SSL_Key

    이러한 필드는, 슬레이브가 마스터에 접속하기 위해서 사용한다 SSL 파라미터가 있는 경우, 그것을 나타낸다.

    Master_SSL_Allowed 에는 이하의 값이 있다.

    • Yes 마스터에의 SSL 접속이 허가되고 있는 경우.

    • No 마스터에의 SSL 접속이 허가되어 있지 않은 경우.

    • Ignored SSL 서포트가 유효화 되어 있지 않은 슬레이브에 의해서 SSL 접속이 허가되고 있는 경우.

    다른 필드의 값은,--master-ca ,--master-capath ,--master-cert ,--master-cipher ,--master-key 의 각 옵션의 값에 대응한다.

    이러한 필드는,MySQL 4.1.1 그리고 도입되었다.

  • Seconds_Behind_Master

    슬레이브 SQL 스레드에 의해서 실행된 마지막 마스터 이벤트의 타임 스탬프로부터 경과한 초수.아직 이벤트가 전혀 발생하고 있지 않는 경우, 혹은 CHANGE MASTER 및 RESET SLAVE (으)로부터 이벤트가 발생하고 있지 않는 경우는 NULL 값이 된다.이 컬럼에 의해, 슬레이브가 얼마나 `` 늦다'' 인지를 알 수 있다.마스터와 슬레이브로 동일한 시계를 사용하고 있지 않아도 문제 없다.

    이 필드는 MySQL 4.1.1 그리고 도입되었다.

4.11.8.8. START SLAVE

START SLAVE [thread_name [, thread_name] ... ]
START SLAVE [SQL_THREAD] UNTIL
    MASTER_LOG_FILE = 'log_name', MASTER_LOG_POS = log_pos
START SLAVE [SQL_THREAD] UNTIL
    RELAY_LOG_FILE = 'log_name', RELAY_LOG_POS = log_pos

thread_name = IO_THREAD | SQL_THREAD

START SLAVE (은)는 옵션 없이, 양쪽 모두의 스레이브스레드를 개시합니다.I/O 스레드는, 마스터 서버로부터 쿼리를 읽어내, 릴레이 로그에 보존합니다.SQL 스레드는 릴레이 로그로부터 쿼리를 읽어내, 실행합니다. 주의: START SLAVE 하지만 스레이브스레드의 개시에 성공하면, 에러 없이 돌아옵니다.다만, 그 경우에서도, 스레이브스레드가 개시한 후에 정?~ 하는 일이 있습니다(마스터에의 접속에 실패하거나 바이너리 로그의 읽어내에 실패했을 경우 등).START SLAVE (은)는, 그러한 경우에 경고를 내지 않습니다.에러 로그내에서, 스레이브스레드에 의해서 생성되는 에러 메세지를 체크하는지,SHOW SLAVE STATUS (을)를 실행해 스레드가 적절히 실행하고 있을지를 체크할 필요가 있습니다.

MySQL 4.0.2 그리고, 스테이트먼트에 IO_THREAD 옵션 또는 SQL_THREAD 옵션을 추가하고, 어느 쪽의 스레드를 개시할까 지정할 수 있게 되었습니다.

MySQL 4.1.1 이?~ ,UNTIL 마디를 추가하고, 마스터 바이너리 로그 또는 슬레이브 릴레이 로그의 지정 포인트에 SQL 스레드가 도달하기까지 슬레이브를 개시하도록(듯이) 지정할 수 있습니다.SQL 스레드가 그 포인트에 이르면, 정?~ 합니다.스테이트먼트로 SQL_THREAD 옵션이 지정되어 있으면,SQL 스레드만을 개시합니다.그렇지 않은 경우는, 양쪽 모두의 스레드를 개시합니다.SQL 스레드가 벌써 실행중의 경우,UNTIL 마디는 무시되어 경고가 출력됩니다.

UNTIL 마디에서는, 로그 파일명과 위치의 양쪽 모두를 지정할 필요가 있습니다.마스터 옵션과 릴레이 로그 옵션을 혼동 하지 말아 주세요.

UNTIL 조건은, 후속의 STOP SLAVE 스테이트먼트, 또는 UNTIL 마디를 포함하지 않는다 START SLAVE 스테이트먼트, 또는 서버의 재기동으로 리셋트 됩니다.

UNTIL 마디는, replication의 디버그나, 특정의 스테이트먼트를 슬레이브에 레프리케이트 시키고 싶지 않은 경우, 그 직전까지 레프리케이트 할 경우에 사용합니다.예를 들어, 마스터로 DROP TABLE 스테이트먼트를 실행하고 있지만, 이것이 현명하지 않았던 경우,UNTIL (을)를 사용해 그 직전까지를 레프리케이트 하도록(듯이) 슬레이브에 지시할 수 있습니다. 이벤트를 조사하려면 , 마스터 로그 또는 릴레이 로그로 mysqlbinlog (을)를 사용하는지,SHOW BINLOG EVENTS 스테이트먼트를 사용합니다.

UNTIL (을)를 사용해 슬레이브에 섹션마다의 쿼리의 replication를 실행시키는 경우는,--skip-slave-start 옵션으로 슬레이브를 기동해, 슬레이브의 기동과 동시에 SQL 스레드를 개시하지 않게 하는 것을 추천 합니다.이 옵션은, 예기치 않은 서버의 재기동에 대비하고, 커멘드 라인은 아니고 옵션 파일로 사용하는 것이 좋을 것입니다.

SHOW SLAVE STATUS 스테이트먼트에는,UNTIL 조건의 현재의 값을 표시하는 출력 필드가 포함됩니다.

이 커멘드는,MySQL 4.0.5 보다 전은 SLAVE START (으)로 불리고 있었습니다. 당분간은,SLAVE START 도 하위 호환성을 위해서 인정됩니다만, 장래는 폐?~ 됩니다.

4.11.8.9. STOP SLAVE

STOP SLAVE [thread_name [, thread_name] ... ]

thread_name = IO_THREAD | SQL_THREAD

스레이브스레드를 정?~ 합니다. START SLAVE (와)과 같이, 이 스테이트먼트는 IO_THREAD 옵션과 SQL_THREAD 옵션을 사용하고, 어느 쪽의 스레드를 정?~ 할까 지정할 수 있습니다.

이 커멘드는,MySQL 4.0.5 보다 전은 SLAVE STOP (으)로 불리고 있었습니다. 당분간은,SLAVE STOP 도 하위 호환성을 위해서 인정됩니다만, 장래는 폐?~ 됩니다.

4.11.9. replication FAQ

Q: 마스터가 벌써 실행중에서 그것을 정?~ 하고 싶지 않은 경우, 어떻게 슬레이브를 셋업 합니까.

A: 몇개의 방법이 있습니다.마스터의 백업을 작성되어 있어, snapshot에 대응하는 바이너리 로그명과 오프셋을 기록(SHOW MASTER STATUS 의 출력으로부터) 되어 있는 경우는, 이하를 실행합니다.

  1. 슬레이브에 일의의 서버 ID 하지만 할당할 수 있고 있는 것을 확인한다.

  2. 각 파라미터에 적절한 값을 할당해 이하의 스테이트먼트를 슬레이브로 실행한다.

    mysql> CHANGE MASTER TO
    ->     MASTER_HOST='master_host-name',
    ->     MASTER_USER='master_user_name',
    ->     MASTER_PASSWORD='master_pass',
    ->     MASTER_LOG_FILE='recorded_log_name',
    ->     MASTER_LOG_POS=recorded_log_pos;

  3. 슬레이브로 START SLAVE (을)를 실행한다.

마스터의 백업이 없는 경우, 이하의 방법으로 재빠르게 확실히 슬레이브의 셋업을 실행할 수 있습니다.

  1. FLUSH TABLES WITH READ LOCK

  2. gtar zcf /tmp/backup.tar.gz /var/lib/mysql (또는, 이 바리에이션)

  3. SHOW MASTER STATUS (다음에 필요하기 위해, 출력을 반드시 기록해 둔다)

  4. UNLOCK TABLES

대체 수단으로서 상기의 바이너리 카피 대신에, 마스터의 SQL 덤프를 사용할 수도 있습니다.이것을 실시하려면 , 마스터로 mysqldump --master-data (을)를 실행해, 다음에 그 SQL 덤프를 슬레이브로 실행합니다.다만, 이것은 바이너리 카피보다 시간이 걸립니다.

2 개의 방법의 어느 쪽을 사용하는 경우에서도, 그 후, snapshot가 있어, 로그명 및 오프셋치를 기록하는 경우의 지시에 따라 주세요.같은 snapshot를 사용해 복수의 슬레이브를 셋업 할 수 있습니다.일단 마스터의 snapshot를 작성하면, 마스터의 바이너리 로그가 손상을 받지 않는 이상 몇일후에서도, 경우에 따라서는 1개월 다음에도 그 snapshot를 사용해 슬레이브를 셋업 할 수 있습니다.이론적으로는, 대기할 수 있는 시간은 무한합니다.현실적인 제약으로서는, 마스터의 디스크 빈 용량이 낡은 로그에 의해서 줄어 들어 가는 것으로, 슬레이브가 마스터를 따라 잡는데 시간이 걸리는 것을 들 수 있습니다.

LOAD DATA FROM MASTER (을)를 사용할 수도 있습니다.이것은 snapshot를 찍어, 슬레이브에 그것을 restore 하고, 슬레이브상의 로그명과 오프셋을 조정하는 것을, 전부 동시에 실행할 수 있는 편리한 커멘드입니다.장래는,LOAD DATA FROM MASTER 하지만 슬레이브 셋업의 추천 방법이 됩니다.다만, 이 커멘드를 사용했을 경우, 독해 락이 장시간 걸릴 가능성이 있습니다.이 커멘드는 아직 이상으로 하는 효율성에서는 실장되고 있지 않습니다.큰 테이블이 있는 경우, 현시점에서의 추천 방법은,FLUSH TABLES WITH READ LOCK (을)를 실행 후의 로컬 tar snapshot입니다.

Q: 슬레이브는 항상 마스터에 접속해 둘 필요가 있습니까.

A: 아니오, 그 필요는 없습니다.슬레이브는 몇 시간이라도, 혹은 몇일간이라도 슛다운 해 두거나 비접속으로 해 두어도, 재접속해 마스터의 갱신을 따라 잡을 수 있습니다.예를 들어, 마스터와 슬레이브의 관계를 다이얼 업 링크로 셋업 해, 링크 업을 산발적 한편 단시간으로 설정할 수 있습니다.이 경우, 무엇인가 특수한 대책을 세우지 않으면 임의의 시점에서 슬레이브가 마스터와 동기 되고 있는 보증은 없습니다.장래, 적어도 1 개의 슬레이브가 동기 할 때까지 마스터를 블록 하는 옵션을 추가할 예정입니다.

Q: 슬레이브가 마스터와 비교해 얼마나 늦을까 를 알려면 어떻게 하면 좋습니까.즉, 슬레이브에 의해서 레프리케이트 된 마지막 쿼리의 일자를 아는 방법은 있습니까.

A: 슬레이브가 4.1.1 이?~ 의 경우는,SHOW SLAVE STATUS 의 Seconds_Behind_Master 컬럼을 참조합니다.이것보다 전의 버젼에 대해서는, 다음과 같이 됩니다.슬레이브 SQL 스레드가 존재하는 경우, 즉SHOW PROCESSLIST 그리고 표시되는 경우(MySQL 3.23 그럼, 스레이브스레드가 존재하는 경우, 즉 스레이브스레드가 SHOW PROCESSLIST 그리고 표시되는 경우)(see 항4.11.3. 「replication의 실장의 상세」 ), 및 그 스레드가 마스터로부터 읽어낸 이벤트를 최저 1 회는 실행하고 있는 경우만, 슬레이브에 의해서 레프리케이트 된 마지막 쿼리의 일자를 알 수 있습니다.실제, 슬레이브 SQL 스레드가 마스터로부터 읽어낸 이벤트를 실행하면, 이 스레드는 자신의 시간을 그 이벤트의 타임 스탬프에 수정합니다(이것이,TIMESTAMP 도 레프리케이트 하는 이유입니다).결과,SHOW PROCESSLIST 출력의 Time 컬럼으로 슬레이브 SQL 스레드에 대해서 표시되는 초수는, 마지막에 레프리케이트 된 이벤트의 타임 스탬프와 슬래이브 머신의 실제의 시각의 차이가 됩니다.이것을 사용하고, 마지막에 레프리케이트 된 이벤트의 일자를 특정할 수 있습니다.주의: 슬레이브가 마스터로부터 절단 되어 1 시간 경과하고 나서 재접속했을 경우,SHOW PROCESSLIST 의 Time 컬럼으로 슬레이브 SQL 스레드가 3600 의 값을 표시하는 경우가 있습니다.이것은, 슬레이브가 실행하고 있는 쿼리가, 타임 스탬프로부터 1 시간 경과하고 있기 (위해)때문입니다.

Q: 슬레이브가 따라잡을 때까지 마스터의 갱신을 블록 하려면 어떻게 합니까.

A: 이하의 순서를 실행합니다.

  1. 마스터로, 이하의 커멘드를 실행한다.

    mysql> FLUSH TABLES WITH READ LOCK;
mysql> SHOW MASTER STATUS;

    SHOW 스테이트먼트의 출력으로부터 로그명과 오프셋을 기록한다.

  2. 슬레이브로 이하의 커멘드를 실행한다.여기서,MASTER_POS_WAIT() 함수의 인수인 replication 좌표는, 전의 스텝에서 기록한 값.

    mysql> SELECT MASTER_POS_WAIT('log_name', log_offset);

    지정의 로그 파일 및 오프셋에 슬레이브가 도달할 때까지,SELECT 스테이트먼트에 의해서 블록 된다.도달한 시점에서 슬레이브는 마스터와 동기 있어, 여기개로 스테이트먼트가 돌아온다.

  3. 마스터로 이하의 스테이트먼트를 발행해, 마스터에 의한 갱신 처리의 재개를 허가한다.

    mysql> UNLOCK TABLES;

Q: 후타카타향replication를 셋업 할 경우에 주의해야 할 점은 있습니까.

A: MySQL replication에서는, 현재로서는, 분산(서버간의) 갱신의 원자성을 보증하기 위한 마스터와 슬레이브간의 록킹프로트콜을 서포트하고 있지 않습니다.즉, 클라이언트 A 하지만 co-master 1 에 갱신을 실시해, 그것을 co-master 2 에 전파 하기 전에, 클라이언트 B 하지만 co-master 2 에 코우신을 실시해서, 클라이언트 A 의 갱신이 co-master 1 그리고 간 것과는 바뀌어 버릴 가능성이 있습니다.이 경우,co-master 2 (으)로부터의 갱신이 모두 전파 한 다음에 있어도, 클라이언트 A 의 갱신이 co-master 2 에 전해졌을 때,co-master 1 (와)과는 다른 테이블이 생성됩니다.이 때문에, 어떠한 순서에서도 갱신이 안전하게 행해진다고 하는 확증이 있는 경우, 또는 클라이언트 코드로 갱신 순서의 부정하게 대처할 수 있는 경우 이외는, 후타카타향replication로 2 개의 서버를 체인장으로 설정하지 말아 주세요.

또 갱신에 대해서는, 후타카타향replication는 그만큼 퍼포먼스 향상에 도움이 되지 않는 것도 인식해 주세요.서버는 양쪽 모두 각각,1 개의 서버 때와 같은 양의 갱신을 실시합니다.차이는, 다른 서버로부터 발생한 갱신이 1 개의 스레이브스레드로 시리얼화 되기 위해, 락의 경합이 적게 되는 것 정도입니다.그 이점도, 네트워크 지연에 의해서 상쇄되어 버립니다.

Q: replication를 사용해 시스템의 퍼포먼스를 개선하는 방법은 있습니까.

A: 1 개의 서버를 마스터로서 셋업 해, 모든 기입을 거기에 다이렉트 합니다.그리고 예산과 스페이스가 허용 하는 한 많은 슬레이브를 셋업 해, 마스터와 복수의 슬레이브로 독해를 분산합니다.--skip-bdb ,--low-priority-updates , 및 --delay-key-write=ALL 그리고 슬레이브를 기동하면, 슬레이브의 속도가 향상합니다.이 경우, 슬레이브는 속도를 올리기 위해,BDB 테이블 대신에 비트랜잭션(transaction)의 MyISAM 테이블을 사용합니다.

Q: 퍼포먼스 개선 replication를 사용하는 어플리케이션을 작성하고 싶습니다만, 클라이언트 코드는 어떻게 하면 좋습니까.

A: 코드내의 데이타베이스 액세스를 담당하는 부분이 적절히 추상화 즉 모듈화되고 있으면, 레프리케이트의 셋업으로 실행할 수 있도록 변환하는 것은 부드럽고 간단합니다.데이타베이스 액세스의 실장 부분을 변경해, 모든 기입을 마스터에, 그리고 독해를 마스터나 슬레이브에 송신하도록(듯이) 합니다.사용하시는 코드에 이 레벨의 추상화가 되지 않으면, replication 시스템을 1 (으)로부터 셋업 합니다.우선 이하의 함수로, 나팔 라이브러리 또는 모듈을 작성합니다.

  • safe_writer_connect()

  • safe_reader_connect()

  • safe_reader_query()

  • safe_writer_query()

각 함수명의 safe_ (은)는, 함수가 모든 에러 조건을 처리하는 것을 의미합니다.물론, 함수에는 다른 이름을 사용하는 것도 가능합니다.중요한 (일)것은, 독해를 위한 접속, 기입을 위한 접속, 독해 실행, 및 기입 실행으로 통합 인터페이스를 가지는 것입니다.

다음에, 나팔 라이브러리를 사용하도록(듯이) 클라이언트 코드를 변환합니다.이 프로세스는 처음은 고통일지도 모릅니다만, 장기적으로 보면 손해는 없습니다.방금전 설명한 어프로치를 사용하는 어플리케이션은 모두, 마스터/ 슬레이브 구성의 이점을 활용할 수 있습니다.이것은, 슬레이브가 복수의 경우에서도 같습니다.코드는 보수가 매우 간단하고, 트러블 슈팅 옵션의 추가도 시간이 들지 않습니다.1 개인가 2 개의 함수를 수정하는 것만으로, 각 쿼리에 걸린 시간을 로그 하거나 수천의 쿼리중에서 어느 쿼리가 에러의 원인이 되었는지를 특정하는 것등을 할 수 있습니다.

코드 작성의 경험이 풍부하면,replace 유틸리티를 사용해 변환 태스크를 자동화할 수도 있습니다.이 유틸리티는 MySQL 의 표준 디스트리뷰션에 포함되어 있습니다.또, 독자적인 Perl 스크립트를 작성할 수도 있습니다. 코드가 인식 가능한 패턴에 따라서 있으면 이상적입니다.그렇지 않은 경우는, 고쳐 쓰는 것이 좋을 것입니다.혹은 적어도,1 개의 패턴이 되어 있도록 해 주세요.

Q: MySQL replication에 의해서, 어떠한 경우에 얼마나 시스템의 퍼포먼스를 개선할 수 있습니까.

A: MySQL replication는, 독해 빈도가 높고, 기입 빈도가 낮은 시스템으로 가장 위력을 발휘합니다.단일 마스터와 복수 슬레이브의 셋업을 사용하는 것으로써, 이론적으로는 네트워크 대역폭의 한계 또는 마스터를 처리할 수 있는 갱신 부하의 한계까지 슬레이브를 추가하는 것으로써, 시스템을 확장할 수 있습니다.

추가하는 이점이 없어질 때까지 몇의 슬레이브를 추가할 수 있는지, 또 사이트의 퍼포먼스를 얼마나 개선할 수 있을까를 판단하려면 , 쿼리 패턴을 알아, 실증적으로(벤치마크를 사용해) 통상의 마스터와 통상의 슬레이브의 사이의 독해(매초마다의 읽어내, 또는 max_reads )(와)과 기입 throughput의 관계를 조사할 필요가 있습니다.여기에서는, 예로서 가상 시스템의 replication로의 단순화 한 계산을 나타냅니다.

시스템 부하가 10% 의 기입과 90% 의 독해로 구성되어max_reads 하지만 1200 - 2 * max_writes 이라고 가정합니다. 즉, 기입이 없으면 시스템은 매초 1200 의 독해를 실행할 수 있습니다.기입의 평균은 읽어내 평균의 2 배 걸립니다.그리고 그 관계는 직선적입니다. 마스터와 각 슬레이브의 능력은 같고,1 마스터와 N 슬레이브가 있으면 상정합니다.각 서버(마스터 또는 슬레이브)는 이하와 같이 됩니다.

reads = 1200 - 2 * writes (벤치마크로부터)

reads = 9* writes / (N + 1) (독해는 분산되지만, 기입은 모든 서버로 행해진다)

9*writes/(N+1) + 2 * writes = 1200

writes = 1200/(2 + 9/(N+1)

이 분석에 의해, 이하의 결론을 이끌어 낼 수 있습니다.

  • N = 0 (replication가 없는 것을 의미한다)의 경우, 시스템은 1200/11 , 즉 매초 109 기입을 처리할 수 있다(어플리케이션의 성질상, 독해가 9 배가 된다).

  • N = 1 의 경우, 매초 184 의 기입까지 처리할 수 있다.

  • N = 8 의 경우, 매초 400 의 기입까지 처리할 수 있다.

  • N = 17 이면,480 의 기입이 된다.

  • N 하지만 무한하게 가까워지면(예산도 무한대에 부풀어 오르지만), 매초 600 의 기입에 가깝게 되어, system throughput는 5.5 배가 된다.그러나,8 서버만으로 4 배 가깝게가 되어 있다.

주의: 이 계산에서는 시스템 대역을 무한으로서 상정하고 있어, 현실의 장면에서는 중요해질지도 모르는 요인을 몇개인가 무시하고 있습니다.많은 경우,N 어플리케이션 슬레이브를 추가했을 경우의 결과를 정확하게 예측하는 상기와 같은 계산을 실시하는 것은 어렵다고 말할 수 있습니다.그러나, 이하의 질문으로부터, replication에 의해서 시스템의 퍼포먼스가 개선될지, 또 어느 정도 개선되는지, 어느 정도 판단할 수 있겠지요.

  • 시스템의 독해와 기입의 비율은 어느 정도인가.

  • 독해를 줄였을 경우,1 개의 서버로 처리할 수 있는 기입 부하를 어느 정도 늘릴 수 있을까.

  • 네트워크의 대역폭을 사용할 수 있는 슬레이브수의 상한은 몇개인가.

Q: 장황성과 고가용성을 실현하도록(듯이) replication를 사용하려면 어떻게 하면 좋습니까.

A: 현재 사용 가능한 기능으로,1 개의 마스터와 1 개의 슬레이브(또는 복수의 슬레이브)를 셋업 할 필요가 있습니다.그리고, 마스터의 가동 상태를 감시해, 실패시에 어플리케이션과 슬레이브로 마스터의 변경을 지시하는 스크립트를 작성합니다.이하의 가이드 라인을 참고로 해 주세요.

  • 슬레이브로 마스터를 변경하도록 지시하려면 ,CHANGE MASTER TO 커멘드를 사용한다.

  • 어플리케이션에 마스터의 장소를 인식 하게 하기 위해서는, 마스터에 동적 DNS 엔트리를 채용하면 좋다.bind 그리고,nsupdate (을)를 사용해 DNS (을)를 동적으로 갱신할 수 있다.

  • --log-bin 옵션을 지정해,--log-slave-updates 없이 슬레이브를 실행한다.STOP SLAVE 및 RESET MASTER (을)를 실행해, 다른 슬레이브로 CHANGE MASTER TO (을)를 실행하는 것으로써, 슬레이브가 마스터가 될 준비를 할 수 있다.예를 들어, 이하의 셋업이 있으면 가정한다.`M'' (은)는 마스터,``S'' (은)는 슬레이브,``WC'' (은)는 데이타베이스 독해 및 기입을 발행하는 클라이언트를 의미한다.데이타베이스 독해만을 발행하는 클라이언트는, 변환의 필요가 없기 때문에, 여기에서는 고려되어 있지 않다.

           WC
        \
         v
 WC----> M
       / | \
      /  |  \
     v   v   v
    S1   S2  S3

    S1 (S2 및 S3 (와)과 같이)는,--log-bin (을)를 사용해,--log-slave-updates 없이 실행하고 있는 슬레이브이다.S1 그리고 실행되는 기입은 M (으)로부터의 replication만이므로,S1 의 바이너리 로그는 공백 이다(S1 하 --log-slave-updates 없이 실행되고 있다). 어떠한 이유로 M 하지만 이용할 수 없게 되었기 때문에,S1 (을)를 새로운 마스터로 한다(모든 WC (을)를 S1 에 다이렉트 해,S2 (와)과 S3 하지만 S1 (을)를 레프리케이트 하도록(듯이) 설정한다).

    모든 슬레이브로, 자신의 릴레이 로그에 있는 모든 쿼리를 처리한 것을 확인한다.각 슬레이브로 STOP SLAVE IO_THREAD (을)를 발행해,SHOW PROCESSLIST 의 출력으로 Has read all relay log 하지만 표시되는 것을 확인한다.모든 슬레이브로 이것을 확인하면, 새로운 환경으로 설정할 수 있다.모든 슬레이브로 STOP SLAVE (을)를 발행해, 마스터에 승격하는 슬레이브에 RESET MASTER (을)를, 다른 슬레이브에는 CHANGE MASTER (을)를 실행한다.

    이것으로,M 에 액세스 한다 WC 네 없어진다.모든 WC 에, 쿼리를 S1 에 송신하도록 지시한다.이것이?~ ,WC 에 의해서 S1 에 송신된 쿼리는 모두,S1 의 바이너리 로그에 써진다.S1 의 바이너리 로그에는,M (이)가 종료된 시점 이?~ 에 S1 에 송신된 쿼리가 모두 정확하게 포함된다. S2 ( 및 S3 )(으)로,STOP SLAVE ,CHANGE MASTER TO MASTER_HOST='S1' (을)를 실행한다('S1' 에는 S1 의 실제의 호스트명이 들어간다).CHANGE MASTER 그리고,S2 또는 S3 (으)로부터 S1 에 접속하기 위한 전정보(유저, 패스워드, 포토)를 추가한다.CHANGE MASTER 그리고,S1 의 바이너리 로그의 이름이나 위치를 지정할 필요는 없다.그것이 최초의 바이너리 로그이며, 위치가 4 인 것을 알 수 있고 있어 이러한 값은 CHANGE MASTER 의 디폴트가 되고 있기 때문이다.마지막으로,S2 (와)과 S3 그리고 START SLAVE (을)를 실행하면, 이하와 같이 된다.

           WC
      /
      |
 WC   |  M(unavailable)
  \   |
   \  |
    v v
     S1<--S2  S3
      ^       |
      +-------+

    M 하지만 재가동하면,S2 및 S3 (와)과 같이 CHANGE MASTER (을)를 실행하는 것만으로 끝난다.그렇다면 M 하 S1 의 슬레이브가 되어, 다운하고 나서 실행되었다 WC 기입을 모두 픽업 한다.M (을)를 마스터에 되돌리려면(그것이 제일 강력한 머신이다, 라고 하는 이유등에서) ,S1 (와)과 M 의 입장을 반대로 해 전회의 순서를 반복한다.이 때,S1 ,S2 ,S3 (을)를 M 의 슬레이브로 하기 전에,M 그리고 RESET MASTER (을)를 실행하는 것을 잊어서는 안된다.그렇게 하지 않으면M 하지만 비가동이 되기 전의 낡다 WC 기입도 주워 버린다.

현재, 자동 마스터 선택 시스템을 MySQL 에 통합할 방향으로 나아가고 있습니다만, 그것이 실현될 때까지는, 스스로 감시 툴을 작성해 주세요.

4.11.10. replication의 트러블 슈팅

지시에 따라서 설정했음에도 불구하고, replication 셋업이 기능하지 않는 경우는, 우선, 이하의 항목을 체크해 주세요.

  • 에러 로그의 메세지를 체크한다 .많은 유저가 이것을 최초로 실행하지 않고 많은 시간을 낭비하고 있다.

  • 마스터가 바이너리 로그에 기록하고 있을지.SHOW MASTER STATUS 그리고 체크한다.기록하고 있으면,Position (은)는 제로 이외의 값이 되어 있다.그렇지 않은 경우, 마스터에 log-bin 옵션을 설정해 있는 것, 및 server-id (을)를 설정해 있는 것을 확인한다.

  • 슬레이브가 실행하고 있을지.SHOW SLAVE STATUS (을)를 실행해,Slave_IO_Running (와)과 Slave_SQL_Running 의 값이 양쪽 모두 Yes 인 것을 체크한다.그렇지 않으면, 슬레이브 옵션을 확인한다.

  • 슬레이브가 실행하고 있는 경우, 슬레이브가 마스터와의 접속을 확립해 있을지.SHOW PROCESSLIST (을)를 실행해,I/O 스레드와 SQL 스레드를 찾아내(그 표시에 대해서는,see 항4.11.3. 「replication의 실장의 상세」 ), 그 State 컬럼을 체크한다.Connecting to master 이면, replication 유저의 마스터로의 권한, 마스터 호스트명,DNS 설정, 마스터가 실제로 실행하고 있을지, 마스터가 슬레이브로부터 액세스 가능할지를 조사한다.

  • 슬레이브가 이전에는 실행하고 있었지만 현재는 정?~ 하고 있는 경우, 그 이유는 통상, 마스터로 성공한 쿼리가 슬레이브로 실패했던 것에 있다.마스터의 snapshot를 적절히 작성하고 있어, 스레이브스레드외에서 슬레이브의 데이터를 변경하고 있지 않으면, 이것은 발생하지 않을 것이다.발생했을 경우는 버그라고 생각할 수 있으므로, 다음의 버그 리포트의 섹션을 참조.

  • 마스터로 성공한 쿼리가 슬레이브에서는 실행하지 못하고, 완전 데이타베이스재동기(슬레이브의 데이타베이스를 삭제해, 마스터의 신규 snapshot를 카피한다)의 실행이 어려운 경우, 이하를 시험한다.

    • 최초로, 슬레이브의 테이블이 마스터의 테이블과 다르지 않은가 확인한다.차이가 났을 경우, 어떻게 그것이 발생했는지를 판별한다.버그의 가능성도 있다.http://www.mysql.com/documentation 그리고 온라인 MySQL 메뉴얼의 변경 로그를 읽어, 그것이 기존의 버그인지 어떤지, 또 벌써 해결되고 있는 것일지 확인한다. 다음에, 슬레이브의 테이블을 마스터의 테이블과 같은 같게 변경하고,START SLAVE (을)를 실행한다.

    • 상기를 가서도 잘 기능하지 않는 경우, 또는 상기가 할 수 없는 경우는, 필요에 따라서 수동으로 갱신해, 마스터로부터의 다음의 갱신을 무시해도 안전할지를 판단한다.

    • 다음의 쿼리를 스킵 하기로 결정했을 경우, 이하의 스테이트먼트를 발행한다.

      mysql> SET GLOBAL SQL_SLAVE_SKIP_COUNTER = n;
mysql> START SLAVE;

      쿼리가 AUTO_INCREMENT 또는 LAST_INSERT_ID() (을)를 사용하지 않는 경우,n 의 값은 1 (으)로 한다.사용하는 경우, 값은 2 (으)로 한다.AUTO_INCREMENT 또는 LAST_INSERT_ID() (을)를 사용하는 쿼리에 2 의 값을 사용하는 이유는, 그 쿼리는 마스터의 바이너리 로그로 이벤트를 2 개사용하기 때문이다.

    • 최신의 버젼에 업그레이드 해, 낡은 버그를 확실히 회피한다.

    • 슬레이브가 마스터와 완벽하게 동기 해 개시해, 스레이브스레드외에서 아무도 테이블을 갱신하고 있지 않다고 확신이 있는 경우는, 버그를 보고한다.

4.11.11. replication 버그의 리포트

유저 에러가 없음에도 불구하고 replication가 기능하지 않는, 또는 불안정하다라고 판단하면, 당사에 버그 리포트를 보내 주세요.버그를 트럭 다운하기 위해서, 가능한 한 많은 정보가 필요합니다.어느 정도의 시간으로 노력을 소비해 버그 리포트를 준비해 주세요.

버그가 재현 가능한 경우, 버그 데이타베이스(http://bugs.mysql.com/ )에 입력해 주세요.팬텀 문제(의도적으로 재현할 수 없는 것)가 있는 경우, 이하의 순서에 따릅니다.

  1. 유저 에러가 없는 것을 확인한다.예를 들어, 슬레이브를 스레이브스레드외에서 갱신하면, 데이터의 동기가 없어져 갱신으로 유니크 키 위반이 된다.이 경우, 스레이브스레드는 정?~ 해, 유저가 수동으로 클린 업 하고 동기를 되찾는 것을 기다린다.이것은 replication의 문제는 아니다.replication를 방해하는 외부 간섭의 문제이다.

  2. --log-slave-updates 옵션 및 --log-bin 옵션으로 슬레이브를 실행한다.이것에 의해, 슬레이브는 받은 갱신을 자신의 바이너리 로그에 기록한다.

  3. replication 상태를 리셋트 하기 전에, 모든 증거를 보존한다.정보가 없거나 적은 경우에는, 문제의 트랙킹에 시간이 걸린다.이하와 같은 증거를 수집하는 것.

    • 마스터로부터의 모든 바이너리 로그

    • 슬레이브로부터의 모든 바이너리 로그

    • 문제 발견시의 마스터로의 SHOW MASTER STATUS 출력

    • 문제 발견시의 마스터로의 SHOW SLAVE STATUS 출력

    • 마스터 및 슬레이브의 에러 로그

  4. mysqlbinlog (을)를 사용해 바이너리 로그를 조사한다.예를 들어 이하를 실행하고, 문제가 있는 쿼리를 찾아낼 수 있다.

    shell> mysqlbinlog -j pos_from_slave_status /path/to/log_from_slave_status | head

팬텀 문제의 증거를 수집하면, 우선 개별의 시험대로 분류하는 노력을 해 주세요.그 후, 버그 데이타베이스(http://bugs.mysql.com/ )에, 그 문제를, 가능한 한 많은 정보와 함께 입력합니다.


제5 장 MySQL 의 최적화

목차

5.1. 최적화의 개요
5.1.1. MySQL 의 설계상의 제약과 트레이드 오프
5.1.2. 이식성
5.1.3. MySQL 사용 실적
5.1.4. MySQL 벤치마크스트
5.1.5. 독자적인 벤치마크의 사용
5.2. SELECT 스테이트먼트 및 그 외의 쿼리의 최적화
5.2.1. EXPLAIN 구문(SELECT 에 관한 정보의 취득)
5.2.2. 쿼리 퍼포먼스의 추정
5.2.3. SELECT 쿼리의 속도
5.2.4. MySQL 에 의한다 WHERE 마디의 최적화
5.2.5. MySQL 에 의한다 IS NULL 의 최적화
5.2.6. MySQL 에 의한다 DISTINCT 의 최적화
5.2.7. MySQL 에 의한다 LEFT JOIN (와)과 RIGHT JOIN 의 최적화
5.2.8. MySQL 에 의한다 ORDER BY 의 최적화
5.2.9. MySQL 에 의한다 LIMIT 의 최적화
5.2.10. INSERT 쿼리의 속도
5.2.11. UPDATE 쿼리의 속도
5.2.12. DELETE 쿼리의 속도
5.2.13. 그 외의 최적화의 힌트
5.3. 락 관련의 문제
5.3.1. MySQL 의 테이블 락 방법
5.3.2. 테이블 락 관련의 문제
5.4. 데이타베이스 구조의 최적화
5.4.1. 설계상의 선택
5.4.2. 데이터의 소형화
5.4.3. MySQL (으)로의 인덱스의 사용
5.4.4. 컬럼 인덱스
5.4.5. 복합 인덱스
5.4.6. MySQL 의 오픈 테이블의 카운트 방법
5.4.7. MySQL (으)로의 테이블의 오픈과 클로우즈의 방법
5.4.8. 1 개의 데이타베이스에 대량의 테이블을 작성했을 경우의 결점
5.5. MySQL 서버의 최적화
5.5.1. 시스템, 컴파일 시간 및 스타트 업 파라미터의 튜닝
5.5.2. 서버 파라미터의 튜닝
5.5.3. MySQL 의 속도에 대한 컴파일과 링크의 영향
5.5.4. MySQL (으)로의 메모리의 사용
5.5.5. MySQL 의 DNS 의 사용
5.5.6. SET 구문
5.6. 디스크 관련의 문제
5.6.1. 기호 연결의 사용

최적화는, 시스템 전체의 이해가 필요하기 때문에, 복잡한 작업입니다.시스템이나 어플리케이션에 관한 지식이 풍부하지 않아도 부분적인 로컬의 최적화는 가능합니다만, 보다 고도의 최적화가 필요하게 과연 구할 수 있는 지식도 고도로 됩니다.

이 장에서는,MySQL 최적화의 방법 설명해, 그 예도 몇개인가 소개합니다.다만, 항상 시스템의 속도를 한층 더 올리는 보완적인 방법도 있습니다만, 난도도 높아지는 것을 기억해 둬 주세요.

5.1. 최적화의 개요

말할 필요도 없이, 시스템의 속도를 올릴 때에 가장 중요한 요소는 기본 설계입니다.또, 사용하는 시스템의 용도 및 그 보틀 넥을 인식해 둘 필요도 있습니다.

가장 일반적인 보틀 넥은 아래와 같은 대로입니다.

  • 디스크 시크. 디스크가 1 개의 데이터를 검색하려면 시간이 걸린다.1999 해의 최신의 디스크에서는, 통상 이것에 걸리는 평균 시간이 10 ms 미만이기 위해, 이론적으로는 1 초간에 100 의 시크를 실행할 수 있게 된다.새로운 디스크에서는 이 시간의 개선이 완만하고,1 개의 테이블의 최적화가 매우 곤란하다.이것을 최적화하는 방법으로서 복수의 디스크에 데이터를 분산하는 것을 들 수 있다.

  • 디스크의 독해와 써. 디스크가 적절한 위치에 있는 경우, 데이터의 독해가 필요하게 된다.1999 해의 최신의 디스크에서는,1 개의 디스크로 약 10 - 20 MB 의 독해가 가능하게 된다.이것은, 복수의 디스크로부터 병행한 독해가 가능하기 때문에, 시크와 비교해 최적화가 용이하다.

  • CPU 사이클. 메인 메모리에 데이터가 있는 경우(또는 벌써 거기에 존재하고 있는 경우), 결과를 얻기 위해서는 처리가 필요하게 된다.메모리와 비교해 테이블이 작은 경우는, 가장 일반적인 제한 요인이 된다.그러나, 테이블이 작아도, 일반적으로 속도상의 문제는 발생하지 않는다.

  • 메모리 대역폭. CPU 캐쉬의 적정량보다 많이 CPU 하지만 데이터를 필요로 하는 경우, 메인 메모리의 대역폭이 보틀 넥이 된다.이것은, 대부분의 시스템에 일반적인 문제는 아니지만, 인식해 둘 필요가 있다.

5.1.1. MySQL 의 설계상의 제약과 트레이드 오프

MyISAM 스토리지 엔진의 사용시에,MySQL 그럼 매우 고속의 테이블 락(복수 리더/ 단일 라이터)가 사용됩니다.이 테이블형의 최대의 문제는, 같은 테이블에 대해서 복수의 UPDATE (와)과 늦다 SELECT 하지만 혼재하는 경우에 발생합니다.테이블로 이러한 문제가 발생했을 경우는, 다른 테이블형을 사용해도 괜찮습니다. See 장 7. MySQL 의 테이블형 .

MySQL (은)는 트랜잭션(transaction) 테이블, 비트랜잭션(transaction) 테이블의 양쪽 모두로 기능합니다. 비트랜잭션(transaction) 테이블(어떠한 에러 발생했을 경우에 롤백(rollback)를 할 수 없다)로의 동작을 부드럽게 하기 위한(해),MySQL 에는 다음의 룰이 있습니다.

  • 모든 컬럼에 디폴트치가 있다.

  • NOT NULL 컬럼에 대해서 NULL 등의 ' 올바르지 않다' 값을 삽입했을 경우나, 수치열의 수치가 너무 큰 경우,MySQL 그럼 에러를 발생하는 것이 아니라,' 취할 수 있는 가능한 값 중 최적치' 에 값을 설정한다.수치의 경우는 0 그리고, 가능한 최소치나 최대치가 된다.문자열의 경우는, 공백 문자나 컬럼의 최대 길이에 맞춘 문자열이 된다.

  • 계산식은 모두, 에러 상태를 표시하는 것이 아니라, 사용 가능한 값을 돌려준다.예를 들어,1/0 의 경우는,NULL (을)를 돌려준다.

이 상세한 것에 대하여는,See 항1.8.5. 「MySQL 에 있어서의 제약의 처리」 (을)를 참조해 주세요.

이것은, 필드 내용의 체크에 MySQL (을)를 사용하는 것이 아니라, 이 체크를 어플리케이션으로 실행할 필요가 있는 것을 의미합니다.

5.1.2. 이식성

SQL 서버는 SQL 의 다양한 부분을 실장하고 있으므로, 이식 가능한 SQL 어플리케이션의 작성이 가능해집니다.매우 단순한 SELECT (이)나 INSERT (은)는 용이합니다만, 필요한 일이 증가하면 증가할수록, 작성이 어려워집니다.다수의 데이타베이스를 사용하면서 민첩한 속도가 요구되는 어플리케이션의 경우는, 한층 더 난도가 오릅니다.

복잡한 어플리케이션을 이식 가능하게 하려면 ,함께 가동할 필요가 있다 SQL 서버수를 선택할 필요가 있습니다.

MySQL crash-me 프로그램(Web 페이지 http://www.mysql.com/information/crash-me.php )(을)를 사용하면, 데이터 베이스 서버의 선택에 사용할 수 있는 함수, 데이터형, 제약을 조사할 수 있습니다.현재의 Crash-me (은)는 가능한 일 모든 테스트를 실행할 수 있다고는 결코 말할 수 없습니다만, 약 450 항목의 테스트가 폭넓게 행해지고 있습니다.

예를 들어,Infomix (이)나 DB2 의 사용을 가능하게 하려면 ,18 문자를 넘는 컬럼명은 사용할 수 없습니다.

MySQL 벤치마크와 crash-me 프로그램은 모두 데이타베이스에의 의존도가 매우 낮아지고 있습니다.이러한 프로그램이 어떻게 처리되고 있을까를 조사하는 것에 의해서, 데이타베이스에 의존하지 않는 어플리케이션을 작성할 때에 필요한 일에 관한 감각을 얻을 수 있습니다.벤치마크 자체는,MySQL 소스 디스트리뷰션의 sql-bench 디렉토리에 있습니다.이것은 Perl - DBI 데이타베이스 인터페이스(문제의 액세스 부분을 해결한다)로 작성되고 있습니다.

이 벤치마크의 결과에 대해서는,http://www.mysql.com/information/benchmarks.html (을)를 참조해 주세요.

이러한 결과로부터도 알도록(듯이), 데이타베이스의 모두에게 어떠한 약점이 있습니다.바꾸어 말하면, 동작의 상위를 부르는 다양한 설계상의 장해가 있습니다.

데이타베이스의 독립성의 획득을 목표로 하는 경우는,SQL 서버 각각의 보틀 넥을 올바르게 이해할 필요가 있습니다.MySQL 그럼, 매우 고속으로 레코드의 취득과 갱신을 합니다만,1 개의 테이블상에 저속의 리더와 라이터가 혼재하는 것에 문제가 있습니다.이것과는 달라,Oracle 그럼, 갱신 직후의 레코드가 디스크에 보존되기 전에 그 레코드에 액세스 하려고 할 때에 큰 문제가 있습니다.일반적으로 트랜잭션 데이터 베이스의 경우, 로그 테이블로부터의 요약 테이블의 생성시는 행 락이 거의 도움이 되지 않고, 문제가 낳기 쉬워지고 있습니다.

어플리케이션을 실제로 데이타베이스비의존으로 하려면 , 데이터 조작에 사용하는 간단한 확장 가능 인터페이스를 정의할 필요가 있습니다.대부분의 시스템에서는 C++ 하지만 사용할 수 있기 위해, 데이타베이스에 C++ 클래스 인터페이스를 사용하는 것은 당연하게 이루어지고 있습니다.

어느 데이타베이스에 고유의 기능을 사용하는 경우(MySQL 의 REPLACE 커멘드등)은, 다른 SQL 서버로 그 기능을 실장할 수 있도록 하는 메소드를 코드화할 필요가 있습니다(다만 저속화합니다).MySQL (을)를 사용하면,/*! */ 구문을 사용해 MySQL 고유의 키워드를 쿼리에 추가할 수 있습니다./**/ 안의 코드는, 그 외의 SQL 서버의 대부분으로 코멘트로서 처리(무시)됩니다.

일부의 Web 어플리케이션과 같이 정확성보다 퍼포먼스가 중시되는 경우는, 모든 결과를 캐쉬하는 어플리케이션 레이어를 작성하면, 한층 더 퍼포먼스를 개선할 수 있습니다.일정한 기간 후에 낡은 결과를 ' 기한 마감' 하는 것으로, 캐쉬를 적당히 최신 상태 로 유지할 수 있습니다.이것에 의해, 캐쉬를 동적으로 확대해, 통상의 상황으로 돌아올 때까지 타임 아웃 기한을 고속으로 설정하고, 고부하의 스파이크를 처리하는 메소드가 제공됩니다.

이 경우, 테이블 작성 정보로 캐쉬의 초기 사이즈와 통상시에 테이블이 리프레쉬 되는 빈도에 관한 정보가 짜넣어집니다.

5.1.3. MySQL 사용 실적

MySQL 의 초기 개발 당시는, 최대 고객에 맞추어 MySQL 의 기능이 개발되어 왔습니다.이 기능은, 스웨덴의 최대 소매상 몇 회사 전용으로 데이터 도매상을 처리하는 것입니다.

모든 점포로부터 보너스 카드 거래 모든 요약을 매주 취득해, 점포의 소유자가 고객에 대한 광고 캠페인의 효과를 조사할 때에 도움이 되는 정보를 제공하도록(듯이) 요구되고 있습니다.

이 데이터는 매우 대량(1 개월에 약 700 만의 요약 거래)로, 유저에게의 제시에 필요한 4-10 연간의 데이터를 보유하고 있습니다. 이 데이터로부터 새로운 리포트에 ' 즉시' 액세스 할 수 있도록(듯이) 하고 싶다고 하는 고객으로부터의 요구가 매주 있었습니다.

1 개월 마다 모든 정보를 압축 ' 트랜잭션(transaction)' 테이블에 격납하는 것으로 이 요구를 해결했습니다.트랜잭션(transaction) 테이블에서 다양한 기준(제품 그룹, 고객 ID , 점포등)에 의해서 분류된 요약 테이블을 생성하는 단순한 매크로(스크립트) 세트를 개발하고 있습니다.리포트는 Web 페이지 형식에서,Web 페이지를 해석해,SQL 스테이트먼트를 실행하고, 결과를 삽입하는, 짧다 Perl 스크립트로부터 동적으로 생성됩니다.PHP 인가 mod_perl 의 사용 쪽이 적합하다고도 말할 수 있습니다만, 그 당시는 이용할 수 없었습니다.

그래피컬 데이터에 대해서는,SQL 쿼리의 결과(이 결과에 처리를 더해)로부터 GIF (을)를 생성하는 간단한 툴을 C 그리고 작성했습니다.이것도 HTML 파일을 해석한다 Perl 스크립트로부터 동적으로 실행됩니다.

대부분의 경우, 기존의 스크립트를 카피해, 그 SQL 쿼리를 수정하는 것으로 신규의 리포트를 간단하게 실행할 수 있습니다.상황에 따라서는, 기존의 요약 테이블에 필드를 추가하거나 신규의 테이블을 생성하는 것이 필요한 경우도 있습니다만, 이것도 디스크상에 모든 트랜잭션(transaction) 테이블을 보존하고 있기 때문에 매우 용이한 일입니다(현재, 적어도 50 G 의 트랜잭션(transaction) 테이블과 그 외의 200 G 의 고객 데이터를 보관 유지하고 있습니다).

고객은,ODBC 에 의해서 요약 테이블에 직접 액세스 할 수 있어 상급 유저이면 각자 데이터를 처리할 수 있습니다.

매우 적당한 규모의 Sun Ultra SPARCstation (2x200 Mhz )(을)를 사용한 처리에서는 아무것도 문제가 발생하고 있지 않습니다.최근 서버의 1 개를 2 CPU 400 Mhz UltraSPARC 에 업그레이드 해, 제품 레벨로의 트랜잭션(transaction) 처리의 개시를 계획하고 있습니다.이 처리에서는 데이터가 10 배증가 하게 됩니다.시스템에 디스크를 추가하는 것만으로 이것에 대응할 수 있다고 생각하고 있습니다.

염가로 CPU 능력을 증강할 수 있도록 Intel-Linux 그렇지만 실험을 실시하고 있습니다.현재, 바이너리의 이식 가능 데이타베이스 포맷(버젼 3.23 의 신기능)이 있어, 어플리케이션의 일부에의 사용을 개시하게 되어 있습니다.

당초,Linux 그럼 저로부터 중간 정도의 부하로의 퍼포먼스가 뛰어나Solaris 그럼 디스크 IO 하지만 매우 높기 때문에 고부하를 달성하려고 할 때의 퍼포먼스가 뛰어난다고 하는 감촉을 얻었습니다만, 현재로서는 이것에 관한 결론은 나와 있지 않습니다.Linux 커넬의 개발자라는 협의의 결과, 이것은,Linux 의 일괄 처리 작업에 할당할 수 있는 자원이 너무 많다고 대화적인 퍼포먼스가 매우 낮아지는 부작용의 가능성도 리.이것에 의해서 대량의 배치가 진행중에 매우 저속이 되어, 응답 불가 상태가 발생합니다.장래의 Linux 커넬에서는 이 처리가 개선되겠지요.

5.1.4. MySQL 벤치마크스트

이 섹션에서는,MySQL 벤치마크스트( 및 crash-me )의 기술적 기술을 기재할 예정입니다만, 이 기술은 아직 작성되고 있지 않습니다.현재 상태로서는,MySQL 소스 디스트리뷰션의 sql-bench 디렉토리에 있는 코드와 결과를 확인하는 것으로 벤치마크에 관한 힌트를 얻을 수 있습니다.

이 벤치마크스트는,SQL 실장의 퍼포먼스를 향상 또는 저하시키는 조작을 유저에게 나타내는 것을 목적으로 하고 있습니다.

이 벤치마크는 싱글스 레드이기 위해, 실행되는 조작의 최단 시간이 측정되고 있는 것에 주의해 주세요.장래는 이 벤치마크스트에 multi-thread의 테스트도 다수 추가할 예정입니다.

아래 표는,Windows NT 4.0 컴퓨터상에서 ODBC (을)를 개입시켜 몇개의 데이터 베이스 서버에 액세스 했을 경우의 벤치마크 결과의 비교를 나타내고 있습니다.

인덱스 마다 2,000,000 레코드의 독해 | 초 | 초
mysql | 367 | 249
mysql_odbc | 464 |
db2_odbc | 1206 |
informix_odbc | 121126 |
ms-sql_odbc | 1634 |
oracle_odbc | 20800 |
solid_odbc | 877 |
sybase_odbc | 17614 |
350,768 레코드의 삽입 | 초 | 초
mysql | 381 | 206
mysql_odbc | 619 |
db2_odbc | 3460 |
informix_odbc | 2692 |
ms-sql_odbc | 4012 |
oracle_odbc | 11291 |
solid_odbc | 1801 |
sybase_odbc | 4802 |

최초의 테스트에서는,8M 의 인덱스 캐쉬 사이즈로 MySQL 하지만 실행되었습니다.

이외에도 벤치마크 결과를 http://www.mysql.com/information/benchmarks.html 의 사이트에 수집하고 있습니다.

Oracle (은)는 삭제의 의뢰가 있었기 때문에 포함되어 있지 않습니다.Oracle 의 벤치마크는 모두,Oracle (으)로부터 제공됩니다.상기의 벤치마크는 표준의 인스톨이 1 클라이언트에 대해서 실행할 수 있는 것을 나타내는 것을 상정하고 있기 때문에,Oracle 의 벤치마크는 매우 편향이 있다고 확신하고 있습니다.

벤치마크스트를 사용하려면 , 이하의 요건을 채울 필요가 있습니다.

  • 벤치마크스트는,MySQL 소스 디스트리뷰션에 의해서 제공되기 위해, 소스 디스트리뷰션이 필요하다.http://www.mysql.com/downloads/ 의 사이트로부터 릴리스 되고 있는 디스트리뷰션을 다운로드하는지, 현재의 개발 트리(see 항2.3.4. 「개발 소스 트리로부터의 인스톨」 )(을)를 사용할 수 있다.

  • 벤치마크 스크립트는 Perl 그리고 작성되어 데이터 베이스 서버에의 액세스에는 Perl DBI 모듈을 사용하고 있기 때문에,DBI 의 인스톨이 필요하다.테스트 대상의 서버의 각각 서버 전용의 DBD 드라이버도 필요하다. 예를 들어,MySQL ,PostgreSQL ,DB2 (을)를 테스트하려면 ,DBD::mysql ,DBD::Pg ,DBD::DB2 의 모듈을 인스톨 할 필요가 있다.

벤치마크스트는,MySQL 소스 디스트리뷰션의 sql-bench 디렉토리에 있습니다. benchmark test를 실행하려면 , 로케이션을 그 디렉토리로 변경해,run-all-tests 스크립트를 실행합니다.

shell> cd sql-bench
shell> perl run-all-tests --server=server_name

server_name (은)는 서포트되는 서버의 1 개를 나타냅니다.run-all-tests --help (을)를 호출하면, 모든 옵션과 서포트 대상 서버의 일람을 취득할 수 있습니다.

crash-me 그럼, 데이타베이스가 서포트하는 기능과 실제의 쿼리를 실행했을 경우의 기능과 제약의 판정이 시행됩니다.예를 들어, 이하에 대한 판정을 합니다.

  • 서포트되는 컬럼형

  • 서포트되는 인덱스수

  • 서포트되는 함수

  • 사용 가능한 쿼리의 사이즈

  • 사용 가능한 VARCHAR 컬럼의 사이즈

다양한 데이타베이스에 관한 crash-me 의 결과는,http://www.mysql.com/information/crash-me.php 의 사이트에 있습니다.

5.1.5. 독자적인 벤치마크의 사용

확실히 어플리케이션과 데이타베이스의 벤치마크를 실시해, 보틀 넥을 검출해 둘 필요가 있습니다.이것을 수정(또는, 보틀 넥을 `` 다?~ -모듈'' 에 치환) 하는 것에 의해서, 다음의 보틀 넥( 등)의 확인이 용이하게 됩니다.현재의 어플리케이션의 종합적인 퍼포먼스를 허용 할 수 있는 것이어도, 실제로 퍼포먼스의 강화가 재촉당하는 경우에 대비하고, 적어도 보틀 넥 각각 대하고 계획을 세워 해결 방법을 판정해 둘 필요가 있습니다.

이식 가능한 벤치마크 프로그램의 예로서MySQL 벤치마크스트를 채택합니다.See 항5.1.4. 「MySQL 벤치마크스트」 .이 스트로부터 임의의 프로그램을 선택해, 필요하게 맞추어 수정할 수 있습니다.이것에 의해서, 각각의 문제에 대해서 복수의 해결 방법을 시행하고, 실제로 가장 고속을 얻을 수 있는 것은 어떤 것일까에 임해서 테스트할 수 있습니다.

이외의 무료의 벤치마크스트에 Open Source Database Benchmark 하지만 있어, 이것은 http://osdb.sourceforge.net/ 그리고 입수할 수 있습니다.

일반적으로는, 시스템의 부하가 매우 높은 상황에게만 문제가 발생합니다.부하의 문제가(테스트제의) 본가동의 시스템으로 발생했다고 문의해 오는 고객이 다수 있었습니다.대부분의 경우, 퍼포먼스에 관련되는 문제는 기본적인 설계상의 문제(고부하시의 테이블 스캔의 불량 )인가 operating system나 라이브러리의 문제가 원인이라고 판명되어 있습니다.대부분은, 시스템이 아직 본가동에 들어가 있지 않은 경우 쪽이 문제의 수정이 아득하게 용이합니다.

이러한 문제를 회피하려면 , 상정 가능한 최악의 부하로 어플리케이션 전체의 벤치마크에 있는 정도 힘을 쏟을 필요가 있습니다.이것에는 Super Smack (을)를 사용할 수 있습니다.이것은,http://www.mysql.com/Downloads/super-smack/super-smack-1.0.tar.gz 그리고 입수할 수 있습니다. 그 이름(Smack = 쳐 깨뜨려)대로, 시스템에 한계까지 부하를 걸칠 수 있기 위해, 반드시 개발 시스템에서만 사용하도록 해 주세요.


5.2. SELECT 스테이트먼트 및 그 외의 쿼리의 최적화

제 1 에 모든 쿼리에 영향을 미치는 것이 1 개 있습니다.액세스권 시스템의 셋업의 complex system가 더하는 만큼, 오버헤드도 증가합니다.

GRANT 스테이트먼트를 아무것도 실행하고 있지 않는 경우는,MySQL 에 의해서 액세스권 체크가 다소 최적화됩니다.대량의 처리가 필요한 때는,GRANT (을)를 사용하지 않는 것으로 시간을 절약할 수 있는 경우도 있습니다.GRANT (을)를 사용했을 경우는, 액세스권 체크가 많아져, 오버헤드가 증가합니다.

명시적인 MySQL 함수에 관련되는 문제가 있는 경우는, 항상 MySQL 클라이언트로 이 함수의 계시를 실시할 수 있습니다.

mysql> SELECT BENCHMARK(1000000,1+1);
+------------------------+
| BENCHMARK(1000000,1+1) |
+------------------------+
|                      0 |
+------------------------+
1 row in set (0.32 sec)

이것은,PentiumII 400MHz 위에서 MySQL 에 의해서 1,000,000 의 + 식을 0.32 초간에 실행할 수 있는 것을 나타내고 있습니다. MySQL 함수는 모두 최적화되고 있습니다만, 예외도 약간 있습니다.BENCHMARK(loop_count,expression) (은)는 쿼리에 함수상의 문제가 있을지를 조사할 때에 최적의 툴입니다.

5.2.1. EXPLAIN 구문(SELECT 에 관한 정보의 취득)

    EXPLAIN tbl_name

인가  EXPLAIN SELECT select_options

EXPLAIN tbl_name (은)는,DESCRIBE tbl_name 또는 SHOW COLUMNS FROM tbl_name 의 동의어입니다.

키워드 EXPLAIN (을)를 SELECT 스테이트먼트의 전에 두었을 경우,MySQL 에 의해서 테이블의 결합 상황과 순서에 관한 정보가 제공되어 테이블의 SELECT 의 처리 방법이 설명됩니다.

EXPLAIN (을)를 이용하면, 보다 빠르게 레코드를 검색한다 SELECT (을)를 얻기 위해서, 어느 때 테이블에 인덱스를 추가해야 할까를 확인할 수 있습니다.

최적화 방법의 선택에 영향을 미치는 키의, 카디나리티등의 테이블 통계를 갱신하기 위해서,ANALYZE TABLE (을)를 정기적으로 실행할 필요가 있습니다. See 항4.6.2. 「ANALYZE TABLE 구문」 .

또, Optimizer가, 테이블을 최적인 순서로 결합하고 있을지도 확인할 수 있습니다. Optimizer가 특정의 차례로 결합을 실시하도록(듯이) 강제하려면 ,SELECT 스테이트먼트에 STRAIGHT_JOIN 마디를 추가합니다.

비단순 결합의 경우,EXPLAIN 하 SELECT 스테이트먼트로 사용되는 각 테이블에 관한 정보를 돌려줍니다. 테이블은, 읽어내진 순서에 따라서 일람표 나타납니다. MySQL (은)는, 단일 스위프다결합 메소드를 사용해 모든 결합을 해결합니다.이것은,MySQL 하지만 최초의 테이블에서 레코드를 읽어내고 나서, 제 2 의 테이블, 제 3 의 테이블이라고 하는 순서로, 일치하는 레코드의 검색을 실시하는 것을 의미합니다. 모든 테이블의 처리가 끝나면, 선택한 컬럼과 한층 더 일치 레코드가 있는 테이블이 검색될 때까지의 테이블 일람의 백 트럭이 출력됩니다. 다음의 레코드는 이 테이블에서 읽어내져 처리가 다음의 테이블에서 속행됩니다.

MySQL 버젼 4.1 그럼,EXPLAIN 출력이 변경되어UNION 스테이트먼트, 서브 쿼리, 파생 테이블등의 구조로의 기능이 개선되고 있습니다.가장 중요한 (일)것은,id (와)과 select_type 그렇다고 한다 2 개의 새로운 컬럼이 추가된 것입니다.

EXPLAIN 의 출력은, 다음의 컬럼으로 구성됩니다.

  • id

    SELECT 에 할당할 수 있었다 ID .쿼리내에 있어서의 이 SELECT 의 순서 번호.

  • select_type

    SELECT 마디의 종류, 다음중 한쪽이 나타난다.

    • SIMPLE

      단순한 SELECT (UNION (이)나 서브 쿼리를 사용하지 않는다).

    • PRIMARY

      최외부의 SELECT

    • UNION

      UNION 안의 제 2 및 그것이?~ 의 SELECT 스테이트먼트.

    • DEPENDENT UNION

      UNION 안의 제 2 및 그것이?~ 의 SELECT 스테이트먼트, 외측의 서브 쿼리에 의존한다.

    • SUBQUERY

      서브 쿼리내의 제 1 SELECT .

    • DEPENDENT SUBQUERY

      제 1 SELECT , 외측의 서브 쿼리에 의존한다.

    • DERIVED

      파생 테이블 SELECT (FROM 절내의 서브 쿼리).

  • table

    결과를 얻기 위해서 참조하는 테이블.

  • type

    결합형.각 결합형을 최적인 것으로부터 순서에 소개한다.

    • system

      1 레코드만으로 구성되는 테이블(= 시스템 테이블).이것은,const 결합형의 특수한 케이스이다.

    • const

      테이블에, 일치하는 레코드가 최대로 1 개 있어, 쿼리의 개시시에 읽어내진다.레코드가 1 개 밖에 없기 때문에, 이 레코드의 컬럼의 값은 Optimizer에 의해서 정수로 보여진다.const 테이블은,1 회 밖에 읽어내지지 않기 때문에, 매우 고속으로 있다.

      const (은)는,PRIMARY/UNIQUE 키를 정수와 비교하는 경우에 사용된다.

      SELECT * FROM const_table WHERE primary_key=1;

SELECT * FROM const_table
WHERE primary_key_part1=1 AND primary_key_part2=2;

    • eq_ref

      전의 테이블의 레코드의 편성의 각각 대하고, 이 테이블에서 1 레코드씩 읽어내진다.이것은,const 형태 이외로 최적인 결합형이다.결합으로 인덱스의 모든 부분이 사용되어 이 인덱스가 UNIQUE 또는 PRIMARY KEY 인 경우에 사용된다.

      = 연산자라고 비교되는 인덱스가 쳐진 컬럼에게는,eq_ref (을)를 사용할 수 있다.비교 대상의 아이템은 정수에서도, 이 테이블 이전에 읽어내진 테이블의 컬럼을 사용하는 식에서도 상관없다.

      아래와 같은 예에서는,ref_table 그리고 eq_ref 하지만 사용된다.

      SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;

    • ref

      전의 테이블의 레코드의 편성의 각각 대하고, 인덱스치에 매치하는 모든 레코드가 이 테이블에서 읽어내진다.ref (은)는, 인덱스의 좌단의 선두 부분만이 결합으로 사용되는 경우, 또는 인덱스가 UNIQUE (이)나 PRIMARY KEY (이)가 아닌 경우(즉, 이 결합에 대하고, 인덱스치로부터1 개의 레코드를SELECT 할 수 없는 경우)에 사용된다.이 결합형은, 사용되는 인덱스와 일치하는 레코드가 수레코드 밖에 없는 경우에 적절하고 있다.

      = 연산자라고 비교되는 인덱스가 쳐진 컬럼에게는,ref 하지만 사용된다.

      아래와 같은 예에서는,ref_table 그리고 ref 하지만 나타난다.

      SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table
WHERE ref_table.key_column_part1=other_table.column
AND ref_table.key_column_part2=1;

    • ref_or_null

      ref (와)과 같지만,NULL (을)를 사용한 레코드의 보충 검색도 추가로 실행된다. See 항5.2.5. 「MySQL 에 의한다 IS NULL 의 최적화」 .

      SELECT * FROM ref_table WHERE key_column=expr OR key_column IS NULL;

      이 결합형의 최적화는,MySQL 4.1.1 의 신기능으로, 주로 서브 쿼리를 해결하는 경우에 사용된다.

    • range

      인덱스를 사용하고, 일정한 범위에 있는 레코드만이 꺼내진다.key 컬럼에 사용되는 인덱스가 나타난다. key_len 에는 사용되는 최장의 인덱스 부분이 기재된다. 이 형태에서는,ref 컬럼이 NULL (이)가 된다.

      range (은)는, 인덱스를 치고 있는 컬럼이 = ,<> ,> ,>= ,< ,<= ,IS NULL ,<=> ,BETWEEN , 및 IN (을)를 사용해 정수로 비교되는 경우에 사용된다.

      SELECT * FROM range_table WHERE key_column = 10;

SELECT * FROM range_table WHERE key_column BETWEEN 10 and 20;

SELECT * FROM range_table WHERE key_column IN (10,20,30);

SELECT * FROM range_table WHERE key_part1= 10 and key_part2 IN (10,20,30);

    • index

      이것은, 인덱스 트리만이 스캔 되는 점을 제외하고 ALL (와)과 같다.일반적으로 인덱스 파일은 데이터 파일보다 작기 때문에, 통상은 ALL 보다 고속으로 있다.

      이것은, 쿼리로 1 인덱스의 구성 부분인 컬럼만이 사용되는 경우에게만 사용된다.

    • ALL

      전의 테이블의 레코드의 편성의 각각 대하고, 풀 테이블 스캔이 실행된다.일반적으로, 테이블이 const 의 지정이 없는 제 1 테이블의 경우에는 적합하지 않고, 그 외의 경우는 모두 매우 당돌하다.통상은, 한층 더 인덱스를 추가하는 것으로 ALL (을)를 회피해, 정수치 또는 이전의 테이블의 컬럼치를 기준에 레코드를 꺼내도록(듯이) 할 수 있다.

  • possible_keys

    possible_keys 컬럼은, 이 테이블내의 레코드의 검색에 MySQL 그리고 사용 가능한 인덱스를 나타낸다.이 컬럼은 테이블의 순서에는 전혀 의존하지 않는 것에 주의한다.즉,possible_keys 의 키의 일부는, 생성된 테이블의 순서에서는 사실상 사용할 수 없게 된다.

    이 컬럼이 NULL 의 경우는, 대응하는 인덱스가 없다.이 경우는,WHERE 마디로 인덱스 작성에 적절한 컬럼을 1 개이상 참조하고 있을지를 조사하는 것으로 쿼리의 퍼포먼스를 개선할 수 있다.참조하고 있는 경우는 적절한 인덱스를 작성해, 재차 EXPLAIN (을)를 사용해 쿼리를 체크한다. See 항6.5.4. 「ALTER TABLE 구문」 .

    테이블에 있는 인덱스를 조사하려면 SHOW INDEX FROM tbl_name (을)를 사용한다.

  • key

    key 컬럼은,MySQL 하지만 실제로 사용을 결정한 키(인덱스)를 나타낸다.선택된 인덱스가 없는 경우, 이 키는 NULL (이)가 된다.MySQL 그리고 possible_keys 컬럼에 기재된 키가 사용되도록(듯이) 강제하려면 , 쿼리로 USE KEY/IGNORE KEY (을)를 사용한다. See 항6.4.1. 「SELECT 구문」 .

    또, 테이블로 myisamchk --analyze (see 항4.5.6.1. 「myisamchk 기동 구문」 ) 또는 ANALYZE TABLE (see 항4.6.2. 「ANALYZE TABLE 구문」 )(을)를 실행하는 일도, Optimizer로 보다 적합한 인덱스를 선택할 때에 도움이 된다.

  • key_len

    key_len 컬럼은,MySQL 하지만 사용을 결정한 키의 길이를 나타낸다.key 하지만 NULL 의 경우, 이 길이는 NULL (이)가 된다.이것에 의해서, 복합 키로 MySQL 하지만 실제로 사용하는 파트수가 나타나는 것에 주의한다.

  • ref

    ref 컬럼은, 테이블에서 레코드를 선택할 때에 key (와)과 함께 사용되는 컬럼 또는 정수를 나타낸다.

  • rows

    rows 컬럼은, 쿼리의 실행에 임하여 조사할 필요가 있으면 MySQL 에 의해서 판정된 레코드의 수를 나타낸다.

  • Extra

    이 컬럼에게는,MySQL 그리고 어떻게 쿼리가 해결될까에 관한 추가 정보가 기재된다.이하는, 이 컬럼에 기재할 수 있는 각종 텍스트 문자열의 설명이다.

    • Distinct

      매치한 최초의 레코드가 검색되면,MySQL (은)는 현재의 레코드의 편성에 의한 그 후의 레코드 검색을 속행하지 않는 것을 나타내 보인다.

    • Not exists

      MySQL 그리고 쿼리에 대한다 LEFT JOIN 최적화를 실행할 수 있어LEFT JOIN 에 일치하는 레코드가 1 개검색되면, 전의 레코드의 편성에 의한 그 후의 테이블의 레코드에 대해서는 조사하지 않는 것을 나타내 보인다.

      이 예는 이하대로이다.

      SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id
WHERE t2.id IS NULL;

      t2.id 하지만 NOT NULL 그리고 정의되고 있다고 한다.이 경우,MySQL 그리고 t1 하지만 스캔 되어t1.id 그리고 t2 안의 레코드의 룩 업을 한다.MySQL 에 의해서 t2 안의 매치하는 레코드가 검색되면,t2 하 t2.id (은)는 아니라고 인식되어t2 안의 같다 id (을)를 가지는 나머지의 레코드의 스캔은 행해지지 않는다.바꾸어 말하면,t2 에 있는 매치하는 레코드의 수에 관련되지 않고,MySQL 그리고 실행이 필요한 (일)것은 t1 의 레코드의 각각 대하고,t2 의 룩 업을 1 회실행하는 것 뿐이다.

    • range checked for each record (index map: #)

      MySQL 그리고 사용에 적절한 실제의 인덱스를 검색할 수 없었던 것을 나타낸다.대체로서 선행 테이블의 레코드의 편성의 각각 대하고, 사용하는 인덱스(존재하는 경우)의 체크가 실행되어 이 인덱스가 테이블에서의 레코드의 꺼내에 사용된다.매우 고속으로 는 없지만, 인덱스 없음의 결합과 비교하면 고속으로 있다.

    • Using filesort

      레코드를 소트 해 꺼내는 방법을 결정하려면 ,MySQL (은)는 패스를 여분으로 실행하지 않으면 안 되는 것을 나타내 보인다. join type 에 따라서 모든 레코드를 스캔 해,WHERE 조건에 일치하는 모든 레코드에, 소트 키 + 행 포인터를 격납하고, 소트는 실행된다. 그 후 키가 소트 된다. 마지막으로, 소트 된 순서에 레코드가 꺼내진다.

    • Using index

      인덱스 트리의 정보만을 사용해 컬럼 정보가 테이블에서 꺼내져 실제의 레코드를 읽어내는 그 후의 검색을 실행할 필요가 없는 것을 나타내 보인다.이것은, 그 테이블로 사용된 컬럼이 모두 동일 인덱스의 구성 부분인 경우에 실행할 수 있다.

    • Using temporary

      쿼리의 해결에 MySQL 그리고 결과를 보관 유지하는 텐포라리테이불의 작성이 필요한 것을 나타낸다.이것은 일반적으로,GROUP BY (을)를 실행한 컬럼 세트와 다른 컬럼 세트에 대해서 ORDER BY (을)를 실행했을 경우에 발생한다.

    • Using where

      다음의 테이블과의 일치를 조사할 수 있는 레코드 또는 클라이언트에 송신되는 레코드의 한정에 WHERE 마디가 사용되는 것을 나타낸다.이 정보가 없고, 테이블의 형태가 ALL 또는 index 인 경우는 쿼리가 정상적으로 실행되지 않는 것이 있다(테이블의 모든 레코드의 취득이나 검사를 의도하고 있지 않는 경우).

    쿼리를 최대한 고속으로 실행할 필요가 있는 경우는,Using filesort (와)과 Using temporary 에 주의할 필요가 있다.

EXPLAIN 출력의 rows 컬럼의 모든 값을 곱셈 하는 것으로, 결합이 어느 정도 적합한지를 나타내는 지침을 취득할 수 있습니다.이것은, 쿼리의 실행시에 MySQL 그리고 조사할 필요가 있는 레코드수의 개요를 나타냅니다.이 수치는,max_join_size 변수로 쿼리를 제한할 때에도 사용됩니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

아래와 같은 예는,EXPLAIN 에 의해서 얻을 수 있던 정보를 사용하고,JOIN (을)를 누진적으로 최적화하는 방법을 나타내고 있습니다.

여기에서는,EXPLAIN (을)를 사용하고,SELECT 스테이트먼트를 조사한다고 합니다.

EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,
            tt.ProjectReference, tt.EstimatedShipDate,
            tt.ActualShipDate, tt.ClientID,
            tt.ServiceCodes, tt.RepetitiveID,
            tt.CurrentProcess, tt.CurrentDPPerson,
            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;

이 예에서는 이하와 같이 상정하고 있습니다.

  • 비교 대상의 컬럼은 이하와 같이 선언됩니다.

    테이블 | 컬럼 | 컬럼의 형태
    tt | ActualPC | CHAR(10)
    tt | AssignedPC | CHAR(10)
    tt | ClientID | CHAR(10)
    et | EMPLOYID | CHAR(15)
    do | CUSTNMBR | CHAR(15)

  • 테이블에는 이하의 인덱스가 있습니다.

    테이블 | 인덱스
    tt | ActualPC
    tt | AssignedPC
    tt | ClientID
    et | EMPLOYID (주키)
    do | CUSTNMBR (주키)

  • tt.ActualPC 값의 분포가 균일하지 않다.

당초, 최적화의 실행전은,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,ClientID,ActualPC NULL NULL    NULL 3872
      range checked for each record (key map: 35)

각 테이블로 type 하지만 ALL 이기 위해, 이 출력은 MySQL 하지만 모든 테이블의 데카르트적을 생성하면 나타내 보이고 있습니다.각 테이블의 레코드의 수의 적의 분량을 조사할 필요가 있기 위해, 이것은 매우 시간이 걸립니다.이 예의 경우는, 레코드의 수가 74 * 2135 * 74 * 3872 = 45,268,558,720 (이)가 됩니다.테이블이 이것보다 큰 경우는, 한층 더 시간이 걸린다고 생각할 수 있습니다.

여기서의 문제의 1 개는, 선언의 방법이 다르면 MySQL 그리고 컬럼의 인덱스를 효율적으로 사용할 수 없는 것에 있습니다.이 예에서는,VARCHAR (와)과 CHAR 하지만 다른 길이로 선언되어 있지 않으면 같게 됩니다.tt.ActualPC 하지만 CHAR(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 (을)를 실행해 보면, 이하의 결과를 얻을 수 있었습니다.

table type   possible_keys   key     key_len ref         rows    Extra
tt    ALL    AssignedPC,ClientID,ActualPC NULL NULL NULL 3872    Using where
do    ALL    PRIMARY         NULL    NULL    NULL        2135
      range checked for each record (key map: 1)
et_1  ALL    PRIMARY         NULL    NULL    NULL        74
      range checked for each record (key map: 1)
et    eq_ref PRIMARY         PRIMARY 15      tt.ActualPC 1

이것도 완전하지는 않습니다만, 꽤 개선되고 있습니다(rows 값의 적이 74 의 계수분만큼 감소).이 버젼의 경우 실행에 몇 초 걸립니다.

제 2 의 변경을 더하면,tt.AssignedPC = et_1.EMPLOYID (와)과 tt.ClientID = do.CUSTNMBR 의 비교로의 컬럼장의 불일치를 해소할 수 있습니다.

mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),
    ->                MODIFY ClientID   VARCHAR(15);

여기에서는,EXPLAIN (으)로부터 이하의 출력이 생성됩니다.

table type   possible_keys   key      key_len ref           rows Extra
et    ALL    PRIMARY         NULL     NULL    NULL          74
tt    ref    AssignedPC,     ActualPC 15      et.EMPLOYID   52   Using where
             ClientID,
             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 에 나타낼 수 있습니다.

shell> myisamchk --analyze PATH_TO_MYSQL_DATABASE/tt
shell> mysqladmin refresh

이것으로 결합이 완전하게 되어,EXPLAIN 그리고 이하의 결과가 생성됩니다.

table type   possible_keys key     key_len ref           rows Extra
tt    ALL    AssignedPC    NULL    NULL    NULL          3872 Using where
             ClientID,
             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 결합 Optimizer의 학습에 의한 추측인 것에 주의해 주세요.쿼리를 최적화하려면 , 이 수치가 실제로 가까운 것일지를 확인할 필요가 있습니다.실제와 동떨어지고 있는 경우는,SELECT 스테이트먼트로 STRAIGHT_JOIN (을)를 사용해,FROM 마디로 테이블의 순서를 바꾸어 일람표 나타내 보여 보면 퍼포먼스를 개선할 수 있습니다.

5.2.2. 쿼리 퍼포먼스의 추정

대부분의 경우, 디스크 시크를 카운트 해 퍼포먼스를 추정할 수 있습니다. 작은 테이블의 경우는 일반적으로 1 개의 디스크 시크로 레코드를 검색할 수 있습니다(인덱스가 캐쉬되는 것이 많기 때문에).큰 테이블의 경우의 추정에서는, (B++ 트리 인덱스를 사용해)log(row_count) / log(index_block_length / 3 * 2 / (index_length + data_pointer_length)) + 1 의 시크가 레코드의 검색에 필요하게 됩니다.

MySQL 그럼, 인덱스 블록이 통상 1,024 아르바이트로, 데이터 포인터는 통상 4 아르바이트입니다.인덱스의 길이가 3 (중위의 정수)의 500,000 레코드의 테이블의 경우는 이하와 같이 됩니다. log(500,000)/log(1024/3*2/(3+4)) + 1 = 4 시크

위의 인덱스에서는 약 500,000 * 7 * 3/2 = 5.2M 하지만 필요하게 되기 위해(일반적인 상황으로서 index buffer의 2/3 하지만 사용되고 있으면 상정), 메모리에 인덱스의 대부분이 있어,OS (으)로부터 데이터를 읽어내, 레코드를 검색하려면 ,1 회인가 2 회의 호출로 끝난다고 추정됩니다.

다만, 기입에 대해서는, 상기의 예로 신규 인덱스의 배치 장소를 찾아내는데 4 시크의 요구가, 또, 인덱스의 갱신과 레코드의 기입에 통상 2 시크가 필요하게 됩니다.

이것은, 어플리케이션이 대수 N 의 분만큼 저속이 된다고 하는 의미는 아닌 것에 주의해 주세요.OS 또는 SQL 서버로 모든 것이 캐쉬되고 있는 한, 테이블이 확대해도 속도의 저하는 불과입니다.데이터를 캐쉬할 수 없을 정도 증가하면, 디스크 시크(대수 N 의 분만큼 증가한다)에 의해서 최종적으로 어플리케이션이 바인드 될 때까지 큰폭으로 속도의 저하가 시작됩니다.이것을 회피하려면 , 데이터의 증가에 맞추어 인덱스 캐쉬도 확대합니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

5.2.3. SELECT 쿼리의 속도

일반적으로, 저속의 SELECT ... WHERE 의 속도를 올릴 필요가 있는 경우는, 우선, 인덱스를 추가할 수 있을지를 체크합니다.See 항5.4.3. 「MySQL (으)로의 인덱스의 사용」 .일반적으로 복수의 테이블간의 참조는 모두 인덱스를 사용해 실행할 필요가 있습니다.EXPLAIN 커멘드를 사용하고,SELECT 에 사용되는 인덱스를 판정할 수 있습니다. See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

일반적인 힌트

  • MySQL 에 의한 쿼리의 최적화를 용이하게 하려면 , 관련 데이터를 로드한 후에 테이블에 대해서 myisamchk --analyze (을)를 실행한다.이것은 인덱스를 위해서, 같은 값이 있는 레코드의 평균치를 갱신한다(유니크 인덱스의 경우, 이것은 항상 1 (이)가 된다).MySQL (은)는 이것을 사용하고,2 개의 테이블을 ' 비정수식' 그리고 접속할 때에 선택하는 인덱스를 판정한다. SHOW INDEX FROM table_name (을)를 실행해 Cardinality 컬럼을 조사하면,analyze 의 실행 결과를 체크할 수 있다.

  • 인덱스에 따라서 인덱스와 데이터를 소트 하려면 myisamchk --sort-index --sort-records=1 (인덱스 1 그리고 소트 하는 경우)를 사용한다.속도를 올리려면 , 모든 레코드의 읽어내에 유니크 인덱스를 사용해, 그 인덱스에 따른 순서로 독해를 실시하도록(듯이) 추천 된다.다만, 이 소트에서는 기입의 최적화는 하지 못하고, 테이블이 큰 경우는 시간이 걸린다.

5.2.4. MySQL 에 의한다 WHERE 마디의 최적화

WHERE 의 최적화는, 대부분의 경우 SELECT (와)과 함께 사용되기 위해,SELECT 부분에 적용됩니다만,DELETE (이)나 UPDATE 의 스테이트먼트의 WHERE 에도 같은 최적화가 적용됩니다.

또, 이 섹션은 완전한 것은 아니기 때문에, 주의가 필요합니다.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)

  • 정수의 꺾어 접어.

       (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)
-> B=5 OR B=6

  • 인덱스가 사용하는 정수식이 평가되는 것은,1 회에 한정된다.

  • WHERE 하지만 없는 단일 테이블의 COUNT(*) (은)는,MyISAM (와)과 HEAP 테이블의 테이블 정보로부터 직접 꺼내진다. 이것은, 테이블 1 개만으로 사용하는 경우는 모든 NOT NULL 식에서도 실행된다.

  • 무효 정수식의 조기 검출.MySQL (은)는 실행 불가능한 SELECT 스테이트먼트가 있는 경우, 그것을 신속히 검출해, 결과적으로 레코드를 돌려주지 않는다.

  • GROUP BY 또는 그룹 함수(COUNT() ,MIN() ... )(을)를 사용하지 않는 경우,HAVING 하 WHERE (와)과 머지 된다.

  • 서브 결합의 각각, 단순한 WHERE 하지만 구조화 되어 서브 결합 마다 신속히 WHERE 평가를 취득해, 가능한 한 신속히 레코드를 스킵 한다.

  • 쿼리내의 다른 모든 테이블의 전에, 우선, 모든 정수 테이블이 읽힌다. 정수 테이블과는 이하의 것을 가리킨다.

    • 공백 테이블 또는 1 레코드만의 테이블.

    • UNIQUE 인덱스 또는 PRIMARY KEY (을)를 사용한다 WHERE 마디와 함께 사용되는 테이블로, 인덱스 부분의 모든 것이 정수식과 함께 사용되어 그 인덱스 부분이 NOT NULL (으)로서 정의되고 있는 경우.

    이하의 테이블은 모두 정수 테이블로서 사용된다.

    mysql> SELECT * FROM t WHERE primary_key=1;
mysql> SELECT * FROM t1,t2
    ->          WHERE t1.primary_key=1 AND t2.primary_key=t1.id;

  • 테이블을 결합하는 최적인 결합의 편성은, 모든 가능성을 시행해 보는 것으로 발견된다.ORDER BY 및 GROUP BY 안의 모든 컬럼이 1 개의 테이블에 존재하는 경우, 결합을 실시할 때는 제일에 이 테이블이 선택된다.

  • ORDER BY 마디와 그것과 다르다 GROUP BY 마디가 있는 경우, 혹은,ORDER BY 또는 GROUP BY 에 결합 큐의 제 1 테이블과는 다른 테이블의 컬럼이 포함되어 있는 경우는, 텐포라리테이불이 작성된다.

  • SQL_SMALL_RESULT (을)를 사용하는 경우,MySQL 그럼 메모리내의 텐포라리테이불이 사용된다.

  • 테이블 인덱스 마다 쿼리를 해 스팬이 레코드의 30% 미만인 최적 인덱스가 사용된다.이러한 인덱스가 검색되지 않는 경우는, 퀵 테이블 스캔이 사용된다.

  • 상황에 따라서는,MySQL 그리고 데이터 파일의 참조도 하지 않고 인덱스로부터 레코드를 읽어낼 수 있는 경우도 있다.인덱스로부터 사용되는 컬럼의 모든 것이 수치형의 경우, 쿼리의 해결에는 인덱스 트리만이 사용된다.

  • 레코드의 각각이 출력되기 전에,HAVING 마디와 일치하지 않는 레코드는 스킵 된다.

매우 고속의 쿼리의 샘플을 몇개인가 소개합니다.

mysql> SELECT COUNT(*) FROM tbl_name;
mysql> SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;
mysql> SELECT MAX(key_part2) FROM tbl_name
    ->        WHERE key_part_1=constant;
mysql> SELECT ... FROM tbl_name
    ->        ORDER BY key_part1,key_part2,... LIMIT 10;
mysql> SELECT ... FROM tbl_name
    ->        ORDER BY key_part1 DESC,key_part2 DESC,... LIMIT 10;

다음의 쿼리는, 인덱스 트리만을 사용해 해결됩니다(인덱스가 있는 컬럼이 수치형이라고 상정).

mysql> SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;
mysql> SELECT COUNT(*) FROM tbl_name
    ->        WHERE key_part1=val1 AND key_part2=val2;
mysql> SELECT key_part2 FROM tbl_name GROUP BY key_part1;

The following queries use indexing to retrieve the rows in sorted order without a separate sorting pass: 다음의 쿼리는, 소트의 패스를 나누는 일 없이, 소트 한 레코드를 꺼내기 위해서 인덱스를 사용합니다.

mysql> SELECT ... FROM tbl_name
    ->            ORDER BY key_part1,key_part2,... ;
mysql> SELECT ... FROM tbl_name
    ->            ORDER BY key_part1 DESC,key_part2 DESC,... ;

5.2.5. MySQL 에 의한다 IS NULL 의 최적화

MySQL 그럼,column = constant_value 의 경우와 같은 최적화를 column IS NULL 에 대해서도 실행할 수 있습니다.예를 들어,MySQL 그럼, 인덱스와 범위를 사용하고,IS NULL 그리고 NULL (을)를 검색할 수 있습니다.

SELECT * FROM table_name WHERE key_col IS NULL;

SELECT * FROM table_name WHERE key_col <=> NULL;

SELECT * FROM table_name WHERE key_col=# OR key_col=# OR key_col IS NULL

OUTER JOIN 에 사용되지 않는 테이블상에서,WHERE 절내에서 column_name IS NULL 그리고 정의된 것을 NOT NULL (와)과 사용하는 경우, 그 식은 소거해 최적화됩니다.

MySQL 4.1.1 그럼,column = expr AND column IS NULL 의 편성을 최적화하는 기능이 추가되고 있습니다.이 최적화가 사용되는 경우는,EXPLAIN 하 ref_or_null (을)를 표시합니다.

이 최적화는, 모든 키 부분에서 IS NULL (을)를 1 개처리할 수 있습니다.

최적 된 쿼리의 샘플을 몇개인가 소개합니다(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;

SELECT * FROM t1,t2 WHERE (t1.a=t2.a OR t2.a IS NULL) AND t2.b=t1.b;

SELECT * FROM t1,t2 WHERE t1.a=t2.a AND (t2.b=t1.b OR t2.b IS NULL);

SELECT * FROM t1,t2 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 키가 있는 레코드의 검색을 실행합니다.

이 최적화에서는,1 개의 IS NULL 레벨 밖에 처리할 수 없는 것에 주의가 필요합니다.

SELECT * FROM t1,t2 where (t1.a=t2.a AND t2.a IS NULL) OR (t1.b=t2.b AND t2.b IS NULL);

이 상황으로 MySQL 하 (t1.a=t2.a AND t2.a IS NULL) 의 부분에 대해서 키의 룩 업을 실행할 뿐으로,b 의 키 부분은 사용할 수 없습니다.

5.2.6. MySQL 에 의한다 DISTINCT 의 최적화

DISTINCT 하지만 ORDER BY (와)과 짜 합쳐져서 이용되면, 많은 경우는 텐포라리테이불이 필요하게 됩니다.

DISTINCT 하 GROUP BY (을)를 동반할 가능성이 높기 때문에,SELECT 되지 않는 필드를 ORDER BY 또는 HAVING 했을 때에, 어떻게 MySQL 하지만 기능하는지를 인식해 둘 필요가 있습니다. See 항6.3.7.3. 「비표시의 필드에 대한다 GROUP BY 」 .

LIMIT row_count (을)를 DISTINCT (와)과 함께 사용했을 경우,MySQL (은)는 일의의 레코드를 row_count 행 검색하면 즉시 검색을 정?~ 합니다.

사용하는 테이블내의 컬럼을 사용하지 않는 경우,MySQL (은)는 최초로 매치하는 레코드를 검색하면 즉시 미사용 테이블의 스캔을 정?~ 합니다.

SELECT DISTINCT t1.a FROM t1,t2 WHERE t1.a=t2.a;

여기에서는,t1 하지만 t2 의 전에 사용되어(EXPLAIN 에 의한 체크),t2 그리고 최초의 레코드가 검색되면 t2 (으)로부터의 독해(t1 의 특정의 레코드)를 정?~ 합니다.

5.2.7. MySQL 에 의한다 LEFT JOIN (와)과 RIGHT JOIN 의 최적화

MySQL 의 A LEFT JOIN B join_condition (은)는 이하와 같이 실장됩니다.

  • 테이블 B (은)는 테이블 A (와)과 A 하지만 의존하는 모든 테이블에 의존하도록(듯이) 설정된다.

  • 테이블 A (은)는,LEFT JOIN 조건으로 사용되는 모든 테이블(B (을)를 제외한다)에 의존하도록(듯이) 설정된다.

  • LEFT JOIN 조건은, 테이블 B (으)로부터의 레코드의 취득 방법의 판정에 사용된다(바꾸어 말하면,WHERE 마디의 조건은 모두 사용되지 않는다).

  • 어느 테이블이 모든 테이블의 뒤에 읽어내지는 경우를 제외해, 통상의 최적화 모두를 한다.의존관계(dependencies)가 순환하고 있는 경우는,MySQL (으)로부터 에러가 출력된다.

  • 표준의 WHERE 최적화 모든 것이 실행된다.

  • A 에 WHERE 마디의 조건에 매치하는 레코드가 있어,B 에 ON 조건에 매치하는 레코드가 없는 경우,B 의 컬럼의 값이 NULL (으)로 설정된 레코드가 생성된다.

  • 테이블의 어느 쪽인가에 존재하지 않는 레코드를 검색할 때에 LEFT JOIN (을)를 사용하고 있고, 한편,WHERE 절내에서,NOT NULL (이)라고 정의했다 column_name (을)를 column_name IS NULL 그리고 평가했을 경우, MySQL 하 LEFT JOIN 조건에 일치하는 레코드를 1 개검색하면, 그 다음은 레코드의 검색(특정의 키 편성의 것)을 정?~ 한다.

RIGHT JOIN 의 실장은 LEFT JOIN (와)과 유사합니다.

테이블 독해 순서는 LEFT JOIN (와)과 STRAIGHT JOIN 에 의해서 강제당하기 위해, 체크 대상의 테이블 순열이 감소해, 결합 Optimizer(테이블의 결합 순서를 계산한다)의 동작의 속도가 한층 더 오릅니다.

상기는, 해당하는 종류의 쿼리를 실행했을 경우인 것에 주의해 주세요.

SELECT * FROM a,b LEFT JOIN c ON (c.key=a.key) LEFT JOIN d (d.key=a.key)
         WHERE b.key=d.key

LEFT JOIN 하지만 d 의 전에 읽어내도록(듯이) 강제하기 위해(때문에),MySQL 그럼 b 의 완전 스캔이 실행됩니다.

이 상황은 쿼리를 이하와 같이 변경해 수정합니다.

SELECT * FROM b,a LEFT JOIN c ON (c.key=a.key) LEFT JOIN d (d.key=a.key)
         WHERE b.key=d.key

4.0.14 이?~ ,MySQL 그럼 이하의 LEFT JOIN 최적화를 합니다.

생성되었다 NULL 레코드로 WHERE 조건이 항상 false 인 경우,LEFT JOIN (은)는 통상의 결합으로 변경됩니다.

예를 들어,t2 컬럼이 NULL 이다고 하면, 이하의 쿼리의 WHERE 마디는 false (이)가 되기 위해, 통상의 결합으로 변환해도 문제 없습니다.

SELECT * FROM t1 LEFT t2 ON (column) WHERE t2.column2 =5;
->
SELECT * FROM t1,t2 WHERE t2.column2=5 AND t1.column=t2.column;

이것으로 쿼리를 개선할 수 있는 경우,MySQL 하지만 테이블 t1 (을)를 읽어내기 전에 테이블 t2 (을)를 사용할 수 있게 되기 위해 스피드가 향상합니다.테이블의 순서를 지정해 강제하는 경우는 STRAIGHT JOIN (을)를 사용합니다.

5.2.8. MySQL 에 의한다 ORDER BY 의 최적화

여분의 소트를 실시하지 않고 ORDER BY 또는 GROUP BY 의 요구에 응하기 위해서,MySQL (은)는 인덱스를 사용하는 경우가 있습니다.

모든 사용되어 있지 않은 인덱스 부분과 다른 부분이 WHERE 절내에서 정수인 컬럼인 경우,ORDER BY 하지만 인덱스에 완전하게 성냥 하지 않는 경우에서도 이 인덱스를 사용할 수 있습니다. 다음의 쿼리에서는 인덱스를 사용해 ORDER BY / GROUP BY 부분을 해결합니다.

SELECT * FROM t1 ORDER BY key_part1,key_part2,...
SELECT * FROM t1 WHERE key_part1=constant ORDER BY key_part2
SELECT * FROM t1 WHERE key_part1=constant GROUP BY key_part2
SELECT * FROM t1 ORDER BY key_part1 DESC,key_part2 DESC
SELECT * FROM t1 WHERE key_part1=1 ORDER BY key_part1 DESC,key_part2 DESC

MySQL 그리고 ORDER BY 의 해결에 인덱스를 사용 할 수 없다 경우는 이하대로입니다(이 경우도 MySQL 하 WHERE 마디의 조건에 일치하는 레코드의 검색에 인덱스를 사용합니다).

  • 복수의 키에 대해서 ORDER BY (을)를 실행하는 경우.

    SELECT * FROM t1 ORDER BY key1,key2

  • 연속하지 않는 키 부분에 대해서 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

  • ORDER BY 그리고 많은 테이블과 컬럼을 결합하고 있고, 그것들 모두가 레코드의 꺼내에 사용되는 최초의 비 const 테이블이 아닌 경우(이것은 EXPLAIN 그리고 출력되는 최초의 테이블로, 한편,const 메소드를 사용하고 있지 않는 테이블).

  • ORDER BY (와)과 GROUP BY 식이 다른 경우.

  • 사용된 테이블 인덱스가, 줄 순서에 레코드를 격납하고 있지 않는 인덱스 타입의 경우(HEAP 테이블의 HASH 인덱스 등).

MySQL 그리고 결과의 소트가 필요한 경우는, 이하의 알고리즘이 사용됩니다.

  • 키 또는 테이블 스캔에 따라서 모든 레코드가 읽어내진다. WHERE 마디에 일치하지 않는 레코드는 스킵 된다.

  • 소트 키가 버퍼(사이즈 sort_buffer )에 격납된다.

  • 버퍼가 만배가 되면,qsort 하지만 실행되어 결과가 임시 파일에 격납된다.포인터는 소트 블록에 보존된다(모든 레코드가 소트 버퍼에 적합하는 경우는, 임시 파일이 작성되지 않는다).

  • 모든 레코드가 읽어내질 때까지 상기 항목이 반복된다.

  • MERGEBUFF (7 ) 영역까지, 다른 임시 파일의 1 블록에 멀티 머지가 실행된다.최초의 파일의 전블록이 2 손톱의 파일에 배치될 때까지 반복된다.

  • 나머지가 MERGEBUFF2 (15 ) 블록 미만이 될 때까지, 이하가 반복된다.

  • 최종 멀티 머지에서는, 레코드에 대한 포인터(소트 키의 최종 부분)만이 결과 파일에 써진다.

  • 다음에,sql/records.cc 의 코드가 사용되어 결과 파일의 포인터에 의해서 소트 된 순서로 독해를 한다.이것을 최적화하기 위해(때문에) 로 포인터의 큰 블록을 읽어들여, 그 소트를 실시하고 나서 소트 된 순서로 record buffer에 레코드를 읽어낸다(read_rnd_buffer_size ).

EXPLAIN SELECT ... ORDER BY (을)를 사용하면,MySQL 그리고 인덱스를 사용해 쿼리를 해결할 수 있을지를 체크할 수 있습니다.extra 컬럼에 Using filesort 하지만 출력되었을 경우는,MySQL 그리고 ORDER BY 의 해결에 인덱스를 사용할 수 없습니다. See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

한층 더 ORDER BY 의 속도를 올릴 필요가 있는 경우는 우선, 소트 국면을 실행할 필요없고 MySQL 그리고 인덱스를 사용할 수 있을지를 조사합니다.이것이 불가능한 경우는, 이하를 실행할 수 있습니다.

  • sort_buffer_size 변수의 값을 늘린다.

  • read_rnd_buffer_size 변수의 값을 늘린다.

  • tmpdir 에 빈영역이 대량으로 있는 전용 디스크상의 디렉토리를 지정한다. MySQL 4.1 이?~ (을)를 사용하고 있는 경우,tmpdir 에 대해서 코론 : (Windows 의 경우는 세?~ 코론 ; )(으)로 단락지은 패스의 일람을 설정하는 것으로, 복수의 물리 디스크간의 부하를 분산시킬 수 있다.이 물리 디스크는, 라운드로빈 방법으로 사용된다. 주의: 이러한 패스는, 동일 디스크의 복수의 파티션이 아니고, 다르다 물리 디스크일 필요가 있다.

디폴트에서는, 쿼리로 ORDER BY x,y[,...] (와)과 지정했을 경우와 같게 MySQL 에 의해서 모든 GROUP BY x,y[,...] 쿼리가 소트 됩니다.ORDER BY 마디를 명시적으로 기술했을 경우, 소트는 발생하지만,MySQL (은)는 스피드를 해치는 일 없이 그것을 최적화합니다. 쿼리에 GROUP BY 하지만 포함되어 있고, 만약 결과의 소트의 오버헤드를 회피하고 싶다면,ORDER BY NULL (을)를 지정하는 것으로 소트를 억?~ 할 수 있습니다.

INSERT INTO foo SELECT a,COUNT(*) FROM bar GROUP BY a ORDER BY NULL;

5.2.9. MySQL 에 의한다 LIMIT 의 최적화

HAVING (을)를 사용하는 것이 아니라 LIMIT row_count (을)를 사용하고 있는 경우,MySQL 에 의한 쿼리의 처리 방법이 다른 경우가 있습니다.

  • LIMIT (을)를 사용해 수레코드 밖에 선택하고 있지 않으면 풀 테이블 스캔을 할 것 같은 경우에,MySQL (은)는 인덱스를 사용하는 일이 있다.

  • ORDER BY (와)과 함께 LIMIT row_count (을)를 사용하고 있는 경우,MySQL 그럼 모든 테이블이 소트 되는 것이 아니라, 최초의 row_count 레코드의 검색을 한 시점에서 즉시 소트를 종료한다.

  • LIMIT row_count (을)를 DISTINCT (와)과 아울러 사용했을 경우,MySQL (은)는 일의의 row_count 행의 레코드를 검색하면 즉시 정?~ 한다.

  • GROUP BY 하지만 키를 차례로 읽는(또는 키의 소트를 실행해 읽는다) 일로 해결할 수 있어 키의 값이 바뀔 때까지 요약이 계산되는 경우도 있다.이 경우,LIMIT row_count 그럼 불필요한 GROUP BY 값의 계산이 모두 행해지지 않게 된다.

  • MySQL 하지만 최초의 # 레코드를 클라이언트에 송신하면, 쿼리가 안?~ 된다(SQL_CALC_FOUND_ROWS (을)를 사용하고 있지 않는 경우).

  • LIMIT 0 (은)는 항상 신속히 하늘세트를 돌려준다.이것은, 쿼리의 체크 및 결과적으로 돌아가는 컬럼의 컬럼형의 취득에 도움이 된다.

  • 서버로 텐포라리테이불을 사용해 쿼리가 해결되는 경우,LIMIT row_count 하지만 필요한 영역의 계산에 사용된다.

5.2.10. INSERT 쿼리의 속도

레코드 삽입의 시간 구성의 개요는 다음과 같습니다.

  • 접속: (3 )

  • 서버에의 쿼리의 송신: (2 )

  • 쿼리의 해석: (2 )

  • 레코드 삽입: (1 x 레코드 사이즈)

  • 인덱스 삽입: (1 x 인덱스수)

  • 클로우즈: (1 )

여기에 나타낸 수치는, 시간 전체를 비례적으로 배분한 것입니다.테이블을 여는 초기 오버헤드는 산입되고 있지 않습니다(이것은 동시 실행 쿼리의 각각으로 1 회실행됩니다).

테이블의 사이즈에 의해서 대수 N 의 분만큼 인덱스 삽입의 속도가 저하합니다(B 트리).

삽입의 속도를 올리는 방법

  • 1 개의 클라이언트로부터 동시에 다수의 레코드를 삽입하는 경우는 다양한 INSERT 스테이트먼트를 사용한다.이것으로 독립했다 INSERT 스테이트먼트의 사용시와 비교해 큰폭으로(경우에 따라서는 수배) 속도가 오른다.하늘이 아닌 테이블에 데이터를 추가하는 경우는, 한층 더 속도를 올리기 위해서 bulk_insert_buffer_size 변수를 조정한다. See 항4.6.8.4. 「SHOW VARIABLES 」 .

  • 다른 복수의 클라이언트로부터 대량의 레코드를 삽입하는 경우는,INSERT DELAYED 스테이트먼트를 사용하면 속도를 올릴 수 있다. See 항6.4.3. 「INSERT 구문」 .

  • MyISAM 테이블에서는, 테이블에 삭제된 레코드가 없는 경우,SELECT 의 실행과 동시에 레코드를 삽입할 수 있는 것에 주의한다.

  • 텍스트 파일로부터 테이블을 로드하는 경우는 LOAD DATA INFILE (을)를 사용한다.통상, 이것은 INSERT 스테이트먼트를 다수 사용하는 경우와 비교하고,20 배속도가 오른다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

  • 테이블에 인덱스가 다수 있는 경우, 조작을 조금 추가하는 것만으로 LOAD DATA INFILE 의 실행 속도를 한층 더 올릴 수 있다.이하의 순서를 사용한다.

    1. CREATE TABLE (을)를 사용하고, 테이블을 작성한다.mysql (이)나 Perl-DBI 등을 사용한다.

    2. FLUSH TABLES 스테이트먼트 또는 쉘 커멘드 mysqladmin flush-tables (을)를 실행한다.

    3. myisamchk --keys-used=0 -rq /path/to/db/tbl_name (을)를 사용한다.이것으로 테이블에서 모든 인덱스의 사용이 삭제된다.

    4. LOAD DATA INFILE (을)를 사용해, 테이블에 데이터를 삽입한다.이것은 인덱스를 전혀 갱신하지 않기 때문에, 매우 고속으로 된다.

    5. 테이블을 읽어내 전용으로 하는 경우는,myisampack (을)를 실행해 테이블을 작게 한다. See 항7.1.2.3. 「압축 테이블의 특성」 .

    6. myisamchk -r -q /path/to/db/tbl_name (을)를 사용해 인덱스를 작성 다시 한다.이것은, 디스크에 쓰기 전에 메모리에 인덱스 트리를 작성하고, 디스크 시크를 회피하기 위해(때문에) 매우 고속으로 된다.생성된 인덱스 트리는 완전하게 밸런스가 놓치고 있다.

    7. FLUSH TABLES 스테이트먼트 또는 쉘 커멘드 mysqladmin flush-tables (을)를 실행한다.

    하늘의 테이블에 삽입하는 경우는,LOAD DATA INFILE (은)는 상기의 최적화를 실행합니다.상기 순서와의 주된 차이점은,myisamchk 에 인덱스 작성용의 텐포라리메모리를 큰폭으로 할당할 수 있는 점입니다.

    MySQL 4.0 이?~ (은)는,myisamchk --keys-used=0 -rq /path/to/db/tbl_name 대신에 ALTER TABLE tbl_name DISABLE KEYS (을)를, 또 myisamchk -r -q /path/to/db/tbl_name 대신에 ALTER TABLE tbl_name ENABLE KEYS (을)를 사용할 수도 있습니다.이와 같이 하면,FLUSH TABLES 스텝을 스킵 할 수도 있습니다.

  • 복수 스테이트먼트를 사용해 실행되는 삽입의 속도를, 테이블을 잠그는 것에 의해서 올릴 수 있다.

    mysql> LOCK TABLES a WRITE;
mysql> INSERT INTO a VALUES (1,23),(2,34),(4,33);
mysql> INSERT INTO a VALUES (8,26),(6,29);
mysql> UNLOCK TABLES;

    주된 속도의 차이점은, 모든 INSERT 스테이트먼트의 완료 후에 index buffer가 1 회만 디스크에 플래시 되는 것이다.통상은,INSERT 스테이트먼트의 수와 같다, index buffer의 플래시를 한다.모든 레코드를 1 개의 스테이트먼트로 삽입할 수 있는 경우는 락의 필요가 없다.

    트랜잭션(transaction) 테이블의 경우는,LOCK TABLES (은)는 아니고 BEGIN/COMMIT (을)를 사용해 속도의 개선을 도모한다.

    락은 복수의 동시 접속 테스트의 합계 시간도 단축하지만, 일부의 스레드의 최대 대기 시간은 길어진다(락 시에 대기하기 위해(때문에)).다음의 예를 참조해 주세요.

    스레드 1
하 1000
레코드를 인서트

스레드 2, 3, 4
하 1
레코드를 인서트

스레드 5
하 1000
레코드를 인서트

    락을 사용하지 않는 경우,2 ,3 ,4 하 1 (와)과 5 의 전에 종료한다.락을 사용했을 경우는,2 ,3 ,4 하 1 (와)과 5 의 전에는 종료하지 않는 확률이 높아지지만, 합계 시간은 약 40% 단축된다.

    MySQL 그럼,INSERT ,UPDATE , 및 DELETE 의 연산이 매우 빠르기 때문에, 약 5 개보다 많은 삽입이나 1 레코드 갱신하기 전에 락을 추가하면 종합적인 퍼포먼스를 개선할 수 있다.1 행으로 매우 다수의 삽입을 실행하는 경우는, 가끔( 약 1,000 레코드마다)LOCK TABLES 에 UNLOCK TABLES (을)를 계속해 실행하고, 다른 스레드로부터의 테이블에의 액세스를 가능하게 할 수 있다.이것이라도 파포만의 증가를 얻을 수 있다.

    말할 필요도 없이, 데이터의 로드에는 LOAD DATA INFILE 쪽이 큰폭으로 고속으로 있다.

LOAD DATA INFILE (와)과 INSERT 의 양쪽 모두의 속도를 한층 더 개선하려면 , 키 버퍼를 확장합니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

5.2.11. UPDATE 쿼리의 속도

갱신 쿼리는,SELECT 쿼리와 같게 최적화됩니다만, 기입 오버헤드가 가산됩니다.기입의 속도는 갱신 대상의 데이터의 사이즈 및 갱신 대상의 인덱스수에 따라서 다릅니다.변경이 없는 인덱스는 갱신되지 않습니다.

갱신의 속도를 올리는 이제(벌써) 1 개의 방법은, 갱신을 지연 해 1 행으로 다수의 갱신을 나중에 실시하는 것입니다.1 행으로의 다수의 갱신은, 테이블을 잠그는 것과 동시에 실시하는 경우와 비교해 큰폭으로 고속으로 실행할 수 있습니다.

가변장 레코드의 경우는, 합계의 길이가 지금보다 긴 것에 레코드를 갱신하면, 레코드가 분할되는 경우가 있는 것에 주의합니다.이 때문에, 빈번히 이것을 실행하는 경우는, 가끔 OPTIMIZE TABLE 하는 것이 중요하게 됩니다. See 항4.6.1. 「OPTIMIZE TABLE 구문」 .

5.2.12. DELETE 쿼리의 속도

테이블내의 모든 레코드를 삭제하는 경우는,TRUNCATE TABLE table_name (을)를 사용합니다. See 항6.4.6. 「TRUNCATE 구문」 .

레코드 삭제에 필요로 하는 시간은, 완전하게 인덱스수에 비례합니다.레코드 삭제의 속도를 올리려면 , 인덱스 캐쉬의 사이즈를 확대합니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

5.2.13. 그 외의 최적화의 힌트

시스템 고속화를 위한 힌트(무순서)

  • 접속 오버헤드를 회피하려면 , 데이타베이스에 대해서 영속적인 접속을 사용한다.영속적인 접속을 사용하지 않고 데이타베이스에 대해서 다수의 신규 접속을 실행하는 경우는,thread_cache_size 변수의 값의 변경이 필요하게 되는 일이 있다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

  • 항상 모든 쿼리가 테이블내에 작성한 인덱스를 실제로 사용하고 있는 것을 확인한다.MySQL 그럼,EXPLAIN 커멘드로 이것을 실행할 수 있다. See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

  • 대량으로 갱신되었다 MyISAM 테이블에 대해서 복잡한 SELECT 쿼리를 사용하지 않게 한다.이것으로 테이블 락을 회피한다.

  • 삭제된 레코드가 없다 MyISAM 테이블의 경우는, 다른 쿼리로 그 테이블에서의 독해를 하는 것과 동시에 레코드를 삽입할 수 있다.이것이 당신에게 있어서 중요하면, 레코드의 삭제가 불필요한 메소드나, 대량의 레코드 삭제 후의 OPTIMIZE TABLE 의 실행을 검토한다.

  • expr1,expr2... 의 순서에 따라서 빈번히 레코드를 읽어내는 경우는,ALTER TABLE ... ORDER BY expr1,expr2... (을)를 사용한다.테이블이 큰폭으로 변경된 후에 이 옵션을 사용하면, 퍼포먼스를 개선할 수 있다.

  • 다른 컬럼의 정보를 기본으로 했다 ' 해시 되었다' 컬럼을 도입하는 것이 도움이 되는 경우가 있다.이 컬럼이 짧은 것으로, 일의성이 있는 경우는, 다수의 컬럼에 큰 인덱스를 사용하는 것보다 큰폭으로 고속화할 수 있다.MySQL 그럼, 추가 컬럼의 사용이 이하와 같이 매우 용이하다. SELECT * FROM table_name WHERE hash=MD5(CONCAT(col1,col2)) AND col_1='constant' AND col_2='constant'

  • 대량으로 변경이 있는 테이블은 모두 VARCHAR (이)나 BLOB 의 컬럼을 사용하지 않게 한다.VARCHAR 또는 BLOB 컬럼을 1 개사용하면 레코드가 즉시 가변장이 되어 버린다. See 장 7. MySQL 의 테이블형 .

  • 일반적으로,1 개의 테이블을 복수의 테이블에 분할하는 것은, 레코드가 ' 크고' 되는 것만으로 고속화의 역에는 서지 않는다.레코드에 액세스 할 때의, 가장 큰 퍼포먼스 요인은, 레코드의 최초의 아르바이트를 찾아내기 위한 디스크 시크이다.데이터의 검색 후, 대부분의 신규 디스크에서는, 대다수의 어플리케이션에 충분한 속도로 레코드 전체를 읽어낼 수 있다.테이블의 분할이 실제로 유효한 상황은, 고정장 테이블에의 변경이 가능한 가변장 테이블(상기 참조)의 경우인가, 테이블의 스캔을 매우 빈번히 필요로 하면서도 대부분의 컬럼을 결과에 필요로 하지 않는 경우뿐이다. See 장 7. MySQL 의 테이블형 .

  • 다수의 레코드의 정보로부터 계산하는 빈도를 매우 높게 할 필요가 있는 경우(카운트의 경우 등), 새로운 테이블을 도입해, 리얼타임에 카운터를 갱신하는 편이 아득하게 적합하다.UPDATE table SET count=count+1 WHERE index_column=constant (와)과 같은 갱신은 매우 고속으로 할 수 있다.

    실제 이것은,MyISAM (이)나 ISAM (와)과 같이 테이블 락(복수 리더/ 단일 라이터)만의 MySQL 테이블형을 사용하는 경우에 매우 중요하다.또, 이러한 경우는 행 락 매니저로 필요한 작업이 적게 되기 위해, 대부분의 데이타베이스로 퍼포먼스가 개선된다.

  • 큰 로그 테이블로부터 통계를 수집할 필요가 있는 경우는, 테이블 전체를 스캔 하는 것이 아니라, 요약 테이블을 사용한다.요약의 관리는, 리얼타임에 통계를 실행하는 경우와 비교해 매우 고속으로 된다.어떠한 변경이 있는(업무상의 결정에 따라) 경우는, 로그로부터 신규에 요약 테이블을 재생성하는 편이, 실행 어플리케이션의 변경보다 아득하게 고속으로 있다.

  • 가능하면, 리포트를 리얼타임인가 집계인가의 어느 쪽인가에 분류하도록(듯이) 추천 한다.집계 리포트에 필요한 데이터는, 요약 테이블에서 생성되어 요약 테이블은 실데이터로부터 생성된다.

  • 컬럼에 디폴트치가 있는 이점을 살린다.삽입 대상의 값이 디폴트치와 상위한 경우만 명시적으로 값을 삽입한다.이것으로,MySQL 하지만 필요로 하는 해석 작업이 경감되어 삽입의 속도가 개선된다.

  • 상황에 따라서는, 데이터를 BLOB 에 팩 해, 격납하는 편이 편리하다.이러한 경우는,BLOB 에의 팩 및 팩 해제를 실시하는 코드를 어플리케이션에 추가할 필요가 있지만, 어느 스테이지에 있어서의 대량의 액세스를 생략 할 수 있게 된다. 이것은, 고정장 테이블 구조에 준거하지 않는 데이터가 있는 경우에 실용적이다.

  • 통상은, 모든 데이터가 장황하게 안 되게 할 필요가 있다(데이타베이스세오리의 제 3 정규화)가, 고속화를 도모할 필요가 있는 경우는 데이터등의 복제나 요약 테이블의 작성을 싶은 하지 않다.

  • Stored Procedure나 UDF (유저 정의 함수)(은)는 퍼포먼스의 향상에 도움이 되는 수단이다.다만, 이것을 서포트하지 않는 데이타베이스를 사용하는 경우는, 항상 대체의(속도가 늦다) 방법도 준비할 필요가 있다.

  • 어플리케이션의 쿼리와 응답을 캐쉬하는 것, 및 삽입과 갱신의 동시 실행을 시행하는 것은 반드시 고속화에 도움이 된다.데이타베이스로 락 테이블이 서포트되는 경우(MySQL (이)나 Oracle 등)은, 이것에 의해서 확실히 모든 갱신 후에 인덱스 캐쉬가 1 회만 플래시 되도록 할 수 있다.

  • 데이터의 쓰는 타이?~ 그를 알 필요가 없는 경우는,INSERT /*! DELAYED */ (을)를 사용한다.다수의 레코드가 1 회의 디스크에의 기입으로 써지기 위해, 이것으로 고속화를 도모할 수 있다.

  • SELECT 의 우선을 올리는 경우는,INSERT /*! LOW_PRIORITY */ (을)를 사용한다.

  • SELECT 하지만 큐를 점프 하도록(듯이) 하는 경우는,SELECT /*! HIGH_PRIORITY */ (을)를 사용한다.바꾸어 말하면, 기입 대기중의 유저가 있는 경우에서도,SELECT (을)를 실행할 수 있게 된다.

  • 1 개의 SQL 커멘드로 다수의 레코드를 격납하려면 , 복수행의 INSERT 스테이트먼트를 사용한다(이것은 다수의 SQL 그리고 서포트되고 있다).

  • 대량의 데이터를 로드하는 경우는 LOAD DATA INFILE (을)를 사용한다.이것은 통상의 삽입보다 고속으로 된다.

  • 일의의 값으로 하려면 AUTO_INCREMENT 컬럼을 사용한다.

  • 일정한 간격으로 OPTIMIZE TABLE (을)를 사용하고, 동적 테이블의 단편화를 회피한다. See 항4.6.1. 「OPTIMIZE TABLE 구문」 .

  • 가능하면 HEAP (을)를 사용하고 고속화를 도모할 수 있도록(듯이) 한다. See 장 7. MySQL 의 테이블형 .

  • 통상의 Web 서버 셋업을 사용하는 경우는, 화상을 파일로서 격납한다.바꾸어 말하면, 데이타베이스내에는 파일 참조만을 격납한다.이 주된 이유는, 통상의 Web 서버 쪽이 데이타베이스 컨텐츠와 비교해 파일의 캐쉬가 뛰어나기 때문에 있다.이 때문에, 파일을 사용하는 편이 시스템의 고속화를 용이하게 도모할 수 있다.

  • 빈번히 액세스 되는 비위기 데이터(쿠키 없이 유저에게 마지막에 표시된 배너의 정보등)에는 메모리테이불을 사용한다.

  • 다른 테이블로 동일 정보를 취급하는 컬럼은, 같은 선언을 해, 같은 이름을 붙인다.버젼 3.23 이전에는 이와 같이 하지 않으면 결합의 속도가 늦어진다.

    이름은 가능한 한 단순한 것 으로 유지한다(커스터머 테이블에서는 customer_name (은)는 아니고 name (을)를 사용한다).다른 SQL 서버에 이식 가능하게 하는 것을 고려한다면, 이름을 18 문자 미만으로 한다.

  • 고속화가 크게 필요하게 되는 경우는, 복수의 SQL 서버가 서포트하는 데이터 스토리지의 저레벨 인터페이스를 조사할 필요가 있다.예를 들어,MySQL MyISAM 에 직접 액세스 하는 것에 의해서,SQL 인터페이스 사용시와 비교해 2-5 배의 속도를 얻을 수 있기도 하다. 이것을 실행 가능하게 하려면 , 데이터를 어플리케이션과 같은 서버에 배치해, 또 통상은 1 프로세스만으로부터 액세스 하도록(듯이) 할 필요가 있다(외부 파일 락이 매우 저속인 모아 두어).상기의 문제는,MySQL 서버에 저레벨의 MyISAM 커멘드를 도입하는 것으로 해소할 수 있다(필요에 따라서 퍼포먼스를 개선하는 용이한 수단의 1 개).데이타베이스 인터페이스를 신중하게 설계하는 것으로, 이런 종류의 최적화를 용이하게 서포트할 수 있다.

  • 많은 경우, 텍스트 파일에 액세스 하는 것과 비교하고, 데이타베이스로부터 데이터에 액세스 하는 편이 고속으로 있다.이 이유는 일반적으로 텍스트 파일(수치 데이터 사용시)보다 데이타베이스 쪽이 보다 컴팩트하고, 필요한 디스크 액세스가 적은 것에 밤.또, 텍스트 파일을 해석해 레코드와 컬럼의 경계를 검색할 필요가 없기 때문에, 코드도 절약할 수 있다.

  • replication에서도 고속화를 도모할 수 있다. See 항4.11. 「MySQL 의 replication」 .

  • DELAY_KEY_WRITE=1 옵션으로 테이블을 정의하면, 파일이 닫혀질 때까지 디스크에 로그가 기록되지 않기 때문에 인덱스 갱신의 속도가 오른다. 이 결점은, 도중에 mysqld 의 강제 종료가 발생했을 경우에 테이블에 문제가 없는 것을 확인하기 위해(때문에),mysqld (을)를 개시하기 전에, 테이블에 대해서 myisamchk (을)를 실행할 필요가 있는 것이다.키 정보는 항상 데이터로부터 생성 가능하기 때문에,DELAY_KEY_WRITE (을)를 사용해도 아무것도 소실은 하지 않는다.


5.3. 락 관련의 문제

5.3.1. MySQL 의 테이블 락 방법

락 메소드 각각 대한 설명은 부록에 있습니다. See 항E.4. 「락 방법」 .

InnoDB 형태와 BDB 형태의 테이블을 제외해,MySQL 의 락은 모두 데드 록 프리입니다. 이것은, 항상 쿼리의 개시시에 필요한 모든 락을 요구해, 또, 항상 같은 순서로 테이블을 잠그는 것에 의해서 관리됩니다.

InnoDB 형태의 테이블은, 행 락을 자동적으로 취득해,BDB 형태의 테이블은, 트랜잭션(transaction)의 개시시는 아니고 SQL 스테이트먼트의 처리시에 페이지 락을 자동 취득합니다.

MySQL 하 WRITE 락에 이하의 락 방법을 사용합니다.

  • 테이블에 락이 없는 경우는, 기입 락을 배치한다.

  • 그 외의 경우는, 기입 락 큐에 락 요구를 배치한다.

MySQL 하 READ 락에 이하의 락 방법을 사용합니다.

  • 테이블에 써 락이 없는 경우는, 독해 락을 배치한다.

  • 그 외의 경우는, 독해 락 큐에 락 요구를 배치한다.

락이 해제되면, 우선 써 락 큐의 스레드로 락이 사용 가능하게 되어, 그 후 독해 락 큐의 스레드로 이용 가능하게 됩니다.

이것은,1 개의 테이블에 대해서 갱신이 다수 있는 경우에, 갱신이 모두 없어질 때까지 SELECT 스테이트먼트가 대기하는 것을 의미합니다.

테이블에 대해서 다수의 INSERT 및 SELECT 조작을 실시할 필요가 있는 경우, 이러한 대기를 회피하려면 , 텐포라리테이불에 레코드를 삽입해, 일정한 간격으로 텐포라리테이불로부터의 레코드로 실테이블을 갱신합니다.

이것은 이하의 코드로 실행할 수 있습니다.

mysql> LOCK TABLES real_table WRITE, insert_table WRITE;
mysql> INSERT INTO real_table SELECT * FROM insert_table;
mysql> TRUNCATE TABLE insert_table;
mysql> UNLOCK TABLES;

특정의 상황으로 꺼내에 우선 순위를 설정하려면 ,LOW_PRIORITY 옵션을 INSERT ,UPDATE 또는 DELETE 에, 혹은 HIGH_PRIORITY 옵션을 SELECT 에 사용합니다.또,--low-priority-updates 옵션으로 mysqld (을)를 개시해도 같은 효과를 얻을 수 있습니다.

SQL_BUFFER_RESULT 의 사용도 테이블 락을 단축하는데 도움이 됩니다. See 항6.4.1. 「SELECT 구문」 .

게다가1 개의 큐를 사용하도록(듯이) mysys/thr_lock.c 의 락 코드를 변경할 수도 있습니다.이 경우는, 기입 락과 읽어내 락의 우선도가 같게 되어, 어플리케이션에 따라서는 고속화에 도움이 됩니다.

5.3.2. 테이블 락 관련의 문제

MySQL 의 테이블 락 코드는 데드 록 프리입니다.

MySQL (은)는,InnoDB 테이블과 BDB 테이블을 제외한 모든 테이블형에 테이블 락을 사용하고, 매우 고속의 락을 실현합니다.대형의 테이블의 경우, 대부분의 어플리케이션으로 행 락과 비교해 테이블 락 쪽이 아득하게 우수합니다만, 이것에는 위험도 있습니다.

InnoDB 테이블과 BDB 테이블의 경우는,MySQL 그리고 LOCK TABLES 에 의해서 명시적 테이블을 잠그었을 경우만 테이블 락이 사용됩니다. InnoDB (은)는 자동행 레벨 락을 사용해,BDB (은)는 페이지 레벨 락을 사용해 트랜잭션(transaction)의 독립을 확실히 하기 위한(해), 이러한 테이블형에는,LOCK TABLES (을)를 전혀 사용하지 않게 추천 합니다.

MySQL 버젼 3.23.7 이?~ (은)는,MyISAM 테이블에의 레코드의 삽입을, 다른 스레드가 동일 테이블에서 독해를 실시하는 것과 동시에 실행할 수 있게 되었습니다.현재로서는, 삽입 실행시에 테이블의 레코드 삭제 후의 홀이 없는 경우에게만, 이 기능이 사용 가능하게 되기 위해 주의가 필요합니다.모든 홀에 신규의 데이터가 입력되면, 동시 삽입이 자동적으로 재차 가능하게 됩니다.

테이블 락에 의해, 동시에 다수의 스레드가 테이블에서의 독해를 실시할 수 있습니다만, 어느 스레드가 테이블에의 기입을 실시할 때는, 우선 배타적 연산을 할 필요가 있습니다.갱신시는, 특정의 테이블에 액세스 하려고 하는 다른 모든 스레드가, 갱신의 준비를 할 수 있을 때까지 대기합니다.

일반적으로 테이블의 갱신은 SELECT 보다 중요하다고 보여지기 위해, 테이블을 갱신하는 스테이트먼트는 모두, 테이블에서 정보를 꺼내는 스테이트먼트보다 우선도가 높아집니다.이것에 의해, 갱신에서는 특정의 테이블에 대해서 대량의 무거운 쿼리가 사용되기 위해, 갱신이 ' 자원고갈' 에 노출되지 않는 것이 확실히 됩니다(이것은, 갱신을 실행하는 스테이트먼트를 LOW_PRIORITY (와)과 함께 사용하는지,SELECT 스테이트먼트와 함께 HIGH_PRIORITY (을)를 사용하는 것으로 변경할 수 있습니다).

MySQL 버젼 3.23.7 이?~ (은)는,max_write_lock_count 변수를 사용하고, 테이블에 대한 삽입이 일정 몇 줄기 깨진 후에,MySQL 에 의해서 테이블의 사용을 대기하고 있다 SELECT 스테이트먼트의 모두에게 높은 우선도를 강제적으로 설정할 수 있게 되었습니다.

다만, 테이블 락은 이하의 시나리오에는 적합하지 않습니다.

  • 클라이언트가 실행에 장시간 걸린다 SELECT (을)를 사용한다.

  • 그 후, 다른 클라이언트가 사용 테이블에 대해서 UPDATE (을)를 사용한다.이 클라이언트는 SELECT 하지만 완료할 때까지 대기가 필요하게 된다.

  • 다른 클라이언트가 동일 테이블에 대해서 한층 더 SELECT 스테이트먼트를 사용한다.UPDATE 하 SELECT 보다 우선도가 높기 때문에, 이 SELECT 하 UPDATE 하지만 완료할 때까지 대기가 필요하게 된다.또, 최초의 SELECT 의 완료를 기다릴 필요도 있다.

  • full disk 등에 의해 스레드가 대기중의 경우, 그 테이블에의 액세스가 필요한 모든 스레드가 추가의 디스크 용량이 사용 가능하게 될 때까지 대기 상태에 놓여진다.

이 문제에 대응하는 해결책은 이하대로입니다.

  • SELECT 스테이트먼트의 실행의 고속화를 시행한다.이것에는 요약 테이블의 작성이 필요한 경우도 있다.

  • --low-priority-updates 의 옵션으로 mysqld (을)를 개시한다.이것은, 테이블을 갱신(변경) 하는 모든 스테이트먼트의 우선도를 SELECT 스테이트먼트의 우선도보다 낮게 한다.이 경우, 전의 시나리오의 마지막 SELECT 스테이트먼트가 INSERT 스테이트먼트보다 전에 실행되게 된다.

  • LOW_PRIORITY 속성을 사용하고, 특정의 INSERT ,UPDATE , 또는 DELETE 스테이트먼트의 우선도를 낮게 설정할 수 있다.

  • max_write_lock_count 의 값을 낮게 해 mysqld (을)를 개시해, 일정수의 WRITE 락의 뒤에 READ 락을 설정한다.

  • SQL 커멘드 SET LOW_PRIORITY_UPDATES=1 (을)를 사용하면, 특정의 스레드로부터의 갱신 모든 것이 낮은 우선도로 실행되도록(듯이) 지정할 수 있다. See 항5.5.6. 「SET 구문」 .

  • HIGH_PRIORITY 속성을 사용하면, 특정의 SELECT 의 중요도를 높게 지정할 수 있다. See 항6.4.1. 「SELECT 구문」 .

  • SELECT (와)과 결합했다 INSERT 에 문제가 있는 경우는,SELECT 스테이트먼트와 INSERT 스테이트먼트의 동시 서포트가 가능하게 되기 위해, 신규의 MyISAM 테이블을 사용하도록(듯이) 바꾼다.

  • INSERT 스테이트먼트와 SELECT 스테이트먼트의 혼재가 많은 경우,INSERT 의 DELAYED 속성에 의해서 문제가 해결되는 확률이 높다. See 항6.4.3. 「INSERT 구문」 .

  • SELECT (와)과 DELETE 에 문제가 있는 경우,DELETE 에 LIMIT 옵션을 사용하면 해결할 수 있는 경우가 있다. See 항6.4.5. 「DELETE 구문」 .


5.4. 데이타베이스 구조의 최적화

5.4.1. 설계상의 선택

MySQL (은)는 로 데이터와 인덱스 데이터를 다른 파일에 격납합니다.그 외의 데이타베이스의 대부분(대부분)는, 로 데이터와 인덱스 데이터가 같은 파일에 혼재하고 있습니다.현재의 매우 많은 시스템으로 MySQL 의 선택 쪽이 우수하다고 확신하고 있습니다.

로 데이터의 격납 방법에는, 각 컬럼의 정보를 독립한 영역에 격납하는 방법도 있습니다(예: SDBM ,Focus 등).이것은, 복수의 컬럼에 액세스 하는 모든 쿼리로 퍼포먼스에 영향을 미칩니다.퍼포먼스는 복수의 칼럼에의 액세스를 개시하면 즉시 저속화하기 위해, 이러한 모델은 범용 데이타베이스에는 적합하지 않는다고 확신하고 있습니다.

일반적으로 인덱스와 데이터가 함께 격납되고 있는 경우도 많이 있습니다(Oracle ,Sybase 등의 경우).이 경우는, 레코드 정보를 인덱스의 리프 페이지로 검색합니다.이 레이아웃으로 우수한 점은, 많은 경우 인덱스의 캐쉬 방법 나름으로 디스크의 독해를 절약할 수 있는 것에 있습니다.이 레이아웃의 결점은 이하대로입니다.

  • 데이터의 취득시에 인덱스 전체를 읽어낼 필요가 있기 위해, 테이블 스캔의 속도가 큰폭으로 내린다.

  • 쿼리로 데이타를 뽑기 시작할 때에 인덱스 테이블만의 사용을 할 수 없다.

  • 노드로부터 인덱스를 복제할 필요가 있기 위해(레코드는 노드에 격납할 수 없는 것에 밤), 대량의 영역이 소비된다.

  • 삭제가 있으면 테이블의 속도가 점차 저하한다(통상, 삭제에서는 노드의 인덱스가 갱신되지 않기 때문에).

  • 인덱스 데이터만의 캐쉬가 곤란하다.

5.4.2. 데이터의 소형화

가장 기본적인 최적화의 1 개에 데이터( 및 인덱스)가 차지하는 디스크 영역을 가능한 한 줄이는 일이 있습니다.이것으로, 디스크의 독해가 고속화해, 사용 메모리도 일반적으로 감소하기 위해(때문에), 대폭적인 개선을 도모할 수 있습니다.컬럼이 작으면 인덱스 작성으로 소비되는 자원도 적게 됩니다.

MySQL 그럼 다양한 테이블형과 레코드 형식이 서포트됩니다. 적절한 테이블 형식을 선택하는 것으로, 퍼포먼스를 큰폭으로 개선할 수 있습니다. See 장 7. MySQL 의 테이블형 .

여기서 소개하는 기법을 사용하면, 테이블의 퍼포먼스 개선과 스토리지 영역의 최소화를 도모할 수 있습니다.

  • 가능한 한 효율성의 높은(최소)의 형태를 사용한다.MySQL 에는 디스크 영역과 메모리를 절약할 수 있는 전용의 형태가 있다.

  • 가능한 경우는, 작은 테이블의 취득에는 작은 정수형을 사용한다.예를 들어,INT 보다 ,MEDIUMINT 쪽이 적합한 경우도 자주 있다.

  • 가능한 한, 컬럼에 NOT NULL (을)를 선언한다.이것으로 모든 것이 고속화되어1 컬럼 정답 1 비트를 절약할 수 있다.어플리케이션으로 실제로 NULL 하지만 필요한 경우는, 반드시 사용할 필요가 있기 위해, 주의가 필요하다.디폴트로 모든 컬럼에 이것을 설정하는 것은 피한다.

  • 가변장 컬럼(VARCHAR ,TEXT ,BLOB 등)이 전혀 없는 경우는 고정장 레코드 형식을 사용한다.이것으로 속도가 오르지만, 영역의 소비도 증가한다. See 항7.1.2. 「MyISAM 테이블 형식」

  • 테이블의 프라이머리 인덱스를 가능한 한 짧게 한다.이것으로, 레코드의 식별이 용이하게 되어 효율화를 도모할 수 있다.

  • 테이블 마다 사용하는 스토리지와 인덱스의 방법을 설정할 필요가 있다. See 장 7. MySQL 의 테이블형 .

  • 인덱스의 작성은 필요한 것인 만큼 한정한다.인덱스는 꺼내가 뛰어나지만, 고속 보존이 필요한 경우는 적합하지 않는다.컬럼의 편성을 사용해 테이블을 검색해, 테이블에 액세스 하는 경우가 대부분이면, 인덱스를 작성한다.인덱스의 최초의 부분은, 가장 사용 빈도의 높은 컬럼으로 할 필요가 있다. 항상 다수의 컬럼을 사용하는 경우는, 보다 중복 하고 있는 컬럼을 먼저 사용하면 인덱스의 압축을 개선할 수 있다.

  • 문자열의 최초의 수문자에, 일의의 프리픽스가 있는 컬럼이 많은 경우는, 이 프리픽스만을 인덱스화하는 편이 좋다.MySQL 하 CHAR 형태 컬럼의 부분 인덱스를 서포트한다.짧은 인덱스의 속도가 빠른 이유는, 점유 디스크 영역이 작은 일 만이 아니고, 인덱스 캐쉬로의 히트가 많아져, 소요 디스크 시크가 적게 되게도 밤. See 항5.5.2. 「서버 파라미터의 튜닝」 .

  • 상황에 따라서는, 스캔의 빈도가 높은 테이블을 2 개로 분할하는 편이 유리한 경우도 있다.이것은 특히, 동적 테이블로, 테이블 스캔 시에 대응하는 레코드의 검색에 작은 정적 테이블의 사용이 가능한 경우에 들어맞는다.

5.4.3. MySQL (으)로의 인덱스의 사용

인덱스는, 컬럼이 특정의 값을 가지는 레코드의 신속한 검색에 사용됩니다.인덱스가 없으면MySQL 하지만 레코드를 찾아내기 위해서, 최초의 레코드로부터 개시해, 테이블 전체를 읽어내면이 필요하게 됩니다.테이블이 커지면, 이것에 코스트가 듭니다.쿼리 대상의 컬럼에 인덱스가 있으면,MySQL (은)는 모든 데이터를 찾는 일 없이, 데이터 파일의 도중에 있는 시크 대상 포지션을 신속히 취득할 수 있습니다.테이블에 1000 레코드 있는 경우, 시퀀셜에 읽어내는 경우와 비교해 적어도 100 배는 고속화할 수 있습니다.1000 레코드의 거의 모두에게 액세스 할 필요가 있는 경우는, 디스크 시크가 최소가 되기 위해, 시퀀셜에 읽는 편이 빨라지는 것에 주의해 주세요.

MySQL 인덱스의 모두(PRIMARY KEY ,UNIQUE , 및 INDEX )(은)는,B 트리에 격납됩니다.문자열의 머리에 있는 공백과 마지막에 있는 공백은 자동적으로 압축됩니다. See 항6.5.7. 「CREATE INDEX 구문」 .

인덱스의 용도는 이하대로입니다.

  • WHERE 마디의 조건에 일치하는 레코드를 신속히 검색한다.

  • 결합 실행시에 다른 테이블의 레코드를 꺼낸다.

  • 인덱스화 된 특정의 컬럼의 MAX() 값이나 MIN() 값을 검색한다.이것은,WHERE key_part_# = 모든 키 부분의 정수 < N (을)를 사용하고 있을지를 체크하는 프리프로세서에 의해서 최적화된다.이 경우,MySQL 그럼 단일 키의 룩 업을 실행해,MIN() 식을 정수에 치환한다.모든 식이 정수에 치환되면, 즉시 쿼리의 응답이 돌려주어진다.

    SELECT MIN(key_part2),MAX(key_part2) FROM table_name WHERE key_part1=10

  • 사용 가능 키의 좌단의 선두 부분에서 소트나 그룹화가 실행되고 있는 경우, 테이블의 소트나 그룹화를 실행한다(예: ORDER BY key_part_1,key_part_2 ).모든 키 부분의 뒤로 DESC 하지만 있는 경우는, 키가 반대의 순서로 읽어내진다. See 항5.2.8. 「MySQL 에 의한다 ORDER BY 의 최적화」 .

  • 상황에 따라서는, 데이터 파일을 참조하지 않고 값을 꺼내도록(듯이) 쿼리를 최적화할 수 있다.어느 테이블로 사용 컬럼의 모든 것이 수치형으로, 키의 좌단의 선두 부분을 구성해 있는 경우는, 인덱스 트리로부터 매우 고속으로 값을 꺼낼 수 있다.

    SELECT key_part3 FROM table_name WHERE key_part1=1

다음의 SELECT 스테이트먼트를 지정했다고 합니다.

mysql> SELECT * FROM tbl_name WHERE col1=val1 AND col2=val2;

col1 (와)과 col2 에 복합 인덱스가 존재하는 경우, 대응하는 레코드를 직접 읽어낼 수 있습니다.col1 (와)과 col2 에 독립한 단일 컬럼 인덱스가 존재하는 경우, 검색되는 레코드의 적은 인덱스를 판정해, 그 인덱스를 레코드의 읽어내에 사용하고, 가장 제한성의 높은 인덱스의 검색이 시행됩니다.

테이블에 복합 인덱스가 있는 경우, Optimizer에서는 인덱스의 좌단의 선두 부분의 어느쪽이든을 레코드의 검색에 사용할 수 있습니다.예를 들어,(col1, col2, col3) 에 3 컬럼의 인덱스가 있는 경우,(col1) ,(col1, col2) , 및 (col1, col2, col3) 에 대해서, 인덱스의 검색 기능을 사용할 수 있습니다.

컬럼이 인덱스의 좌단의 선두 부분을 구성하고 있지 않는 경우,MySQL 그럼, 부분 인덱스를 사용할 수 없게 됩니다.이하의 SELECT 스테이트먼트가 있다고 합니다.

mysql> SELECT * FROM tbl_name WHERE col1=val1;
mysql> SELECT * FROM tbl_name WHERE col2=val2;
mysql> SELECT * FROM tbl_name WHERE col2=val2 AND col3=val3;

인덱스가 (col1, col2, col3) 에 존재하는 경우, 최초의 쿼리만이 인덱스를 사용할 수 있습니다.2 손톱과 3 손톱의 쿼리에는, 인덱스화한 컬럼이 필요합니다만,(col2) (와)과 (col2, col3) 하 (col1, col2, col3) 의 좌단의 프리픽스가 아닙니다

MySQL (은)는,LIKE 의 인수가 와일드 카드 문자로 시작되지 않는 문자열 정수인 경우에,LIKE 비교에도 인덱스를 사용합니다.예를 들어, 이하의 SELECT 스테이트먼트에서는 인덱스가 사용됩니다.

mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Patrick%";
mysql> SELECT * FROM tbl_name WHERE key_col LIKE "Pat%_ck%";

최초의 스테이트먼트에서는 "Patrick" <= key_col < "Patricl" (이)가 있는 레코드만이 고려됩니다.2 손톱의 스테이트먼트에서는 "Pat" <= key_col < "Pau" (이)가 있는 레코드만이 고려됩니다.

이하의 SELECT 스테이트먼트에서는 인덱스가 사용되지 않습니다.

mysql> SELECT * FROM tbl_name WHERE key_col LIKE "%Patrick%";
mysql> SELECT * FROM tbl_name WHERE key_col LIKE other_col;

최초의 스테이트먼트에서는 LIKE 하지만 와일드 카드 문자로 시작되어 있습니다.2 손톱의 스테이트먼트에서는 LIKE 값이 정수가 아닙니다.

MySQL 4.0 그럼 이외의 LIKE 의 최적화도 실행됩니다.... LIKE "%string%" (을)를 사용해,string 하지만 3 문자보다 긴 경우,MySQL 하 Turbo Boyer-Moore 알고리즘을 사용하고, 문자열의 패턴을 초기화하고 나서, 이 패턴을 사용해 검색을 재빠르게 실행합니다.

column_name IS NULL (을)를 사용한 검색에서는,column_name 에 인덱스가 쳐지고 있는 경우에 인덱스가 사용됩니다.

통상 MySQL (은)는, 검색하는 레코드를 줄이기 위해서, 인덱스를 사용합니다.인덱스는, 이하의 연산자로 비교하는 컬럼에 사용됩니다. = ,> ,>= ,< ,<= ,BETWEEN , 또는,'something%' 등의 와일드 카드 이외의 프리픽스로 시작되는 패턴에 대한다 LIKE .

WHERE 절내의 모든 AND 에 걸리지 않은 인덱스는, 쿼리의 최적화에 사용되지 않습니다.바꾸어 말하면, 인덱스의 사용을 가능하게 하려면 , 인덱스의 선두 부분이 모든 AND 그룹에서 사용되고 있을 필요가 있습니다.

다음의 WHERE 마디에서는 인덱스가 사용됩니다.

... WHERE index_part1=1 AND index_part2=2 AND other_column=3
... WHERE index=1 OR A=10 AND index=2      /* index = 1 OR index = 2 */
... WHERE index_part1='hello' AND index_part_3=5
          /* optimized like "index_part1='hello'" */
... WHERE index1=1 AND index2=2 OR index1=3 AND index3=3;
          /* Can use index on index1 but not on index2 or index 3 */

다음의 WHERE 마디에서는 인덱스가 사용 되지 않습니다 .

... WHERE index_part2=1 AND index_part3=2  /* index_part_1 is not used */
... WHERE index=1 OR A=10                  /* Index is not used in
                                                        both AND parts */
... WHERE index_part1=1 OR index_part2=10  /* No index spans all rows  */

MySQL 그럼 이용 가능한 경우에서도 인덱스가 사용되지 않는 경우가 있는 것에 주의해 주세요.이 일례로서 인덱스의 사용에 의해서,MySQL 하지만 테이블의 30% (을)를 넘는 레코드에 액세스 할 필요가 생기는 경우를 들 수 있습니다(이 경우는, 필요한 시크가 큰폭으로 감소하기 위해(때문에), 테이블 스캔 쪽이 고속으로 될 가능성이 높아집니다). 다만 이 쿼리에, 레코드의 일부만을 꺼낸다 LIMIT 하지만 사용되고 있는 경우, 결과로 돌려주어지는 소수의 레코드를 신속히 검색할 수 있기 위해,MySQL (은)는 인덱스를 사용합니다.

5.4.4. 컬럼 인덱스

MySQL 의 모든 컬럼형에는 인덱스를 칠 수 있습니다.SELECT 조작의 퍼포먼스의 개선에는, 대응하는 컬럼에 인덱스를 사용하는 것이 최선의 방법입니다.

테이블 근처의 최대 인덱스수와 인덱스의 최대장은, 스토리지 엔진 마다 정의됩니다.See 장 7. MySQL 의 테이블형 .스토리지 엔진의 모두로,1 테이블 근처 16 이상의 인덱스와 256 아르바이트 이상의 인덱스장이 서포트됩니다.

CHAR 형태 및 VARCHAR 형태의 컬럼에서는, 컬럼의 선두 부분을 인덱스화할 수 있습니다.이것은, 컬럼 전체를 인덱스화하는 경우와 비교해 큰폭으로 고속으로 되어, 소요 디스크 영역도 적어도 됩니다.컬럼의 선두 부분을 인덱스화한다 CREATE TABLE 스테이트먼트 구문은 다음과 같이 됩니다.

INDEX index_name (col_name(length))

이 예에서는,name 컬럼의 최초의 10 문자의 인덱스가 작성됩니다.

mysql> CREATE TABLE test (
    ->        name CHAR(200) NOT NULL,
    ->        INDEX index_name (name(10)));

BLOB 형태 및 TEXT 형태의 컬럼에서는, 컬럼의 선두 부분을 인덱스화할 필요가 있습니다.인덱스를 칠 수 있는 부분의 최대장은 255 아르바이트입니다.

MySQL 버젼 3.23.23 이?~ (은)는, 특수한 FULLTEXT 인덱스도 작성할 수 있습니다.이것은 풀텍스트 검색에 사용됩니다.FULLTEXT 인덱스는,MyISAM 테이블형에서만,CHAR ,VARCHAR , 및 TEXT 컬럼에 한해서 서포트됩니다. 풀 텍스트 인덱스의 작성은 항상 컬럼 전체를 대상으로 하고, 선두 부분(프리픽스)의 인덱스화는 행해지지 않습니다.상세한 것에 대하여는, 항6.8. 「MySQL 풀텍스트 검색」 (을)를 참조해 주세요.

5.4.5. 복합 인덱스

MySQL 그럼 복수의 컬럼에 대한 인덱스를 작성할 수 있습니다.인덱스는 최대 15 컬럼으로 구성할 수 있습니다(CHAR 및 VARCHAR 컬럼에서는 컬럼의 선두 부분을 인덱스의 부분으로서 사용할 수도 있습니다).

복수 컬럼의 인덱스(복합 인덱스)는, 인덱스화 된 컬럼의 값을 연결하는 것에 의해서 생성된 값이 포함되어 소트화 된 배열이라고 볼 수 있습니다.

MySQL 그럼,WHERE 절내에서 인덱스의 제 1 컬럼을 지정하는 경우, 다른 컬럼의 값을 지정하지 않아도, 쿼리를 고속화할 수 있도록 복합 인덱스가 사용됩니다.

다음과 같은 테이블이 정의되고 있다고 합니다.

mysql> CREATE TABLE test (
    ->       id INT NOT NULL,
    ->       last_name CHAR(30) NOT NULL,
    ->       first_name CHAR(30) NOT NULL,
    ->       PRIMARY KEY (id),
    ->       INDEX name (last_name,first_name));

여기서, 인덱스 name (은)는,last_name (와)과 first_name 에 대한 인덱스입니다.이 인덱스는,last_name 의 범위, 또는 last_name (와)과 first_name 의 양쪽 모두의 범위의 값을 지정하는 쿼리에 사용할 수 있습니다. 따라서,name 인덱스는 다음과 같은 쿼리에 사용됩니다.

mysql> SELECT * FROM test WHERE last_name="Widenius";

mysql> SELECT * FROM test WHERE last_name="Widenius"
    ->                    AND first_name="Michael";

mysql> SELECT * FROM test WHERE last_name="Widenius"
    ->                    AND (first_name="Michael" OR first_name="Monty");

mysql> SELECT * FROM test WHERE last_name="Widenius"
    ->                    AND first_name >="M" AND first_name < "N";

그러나, 다음의 쿼리에는 name 인덱스가 사용 되지 않습니다 .

mysql> SELECT * FROM test WHERE first_name="Michael";

mysql> SELECT * FROM test WHERE last_name="Widenius"
    ->                    OR first_name="Michael";

MySQL 그리고 인덱스를 사용해 쿼리 퍼포먼스를 개선하는 방법의 상세한 것에 대하여는, 항5.4.3. 「MySQL (으)로의 인덱스의 사용」 (을)를 참조해 주세요.

5.4.6. MySQL 의 오픈 테이블의 카운트 방법

mysqladmin status (을)를 실행하면, 이하의 출력이 표시됩니다.

Uptime: 426 Running threads: 1 Questions: 11082 Reloads: 1 Open tables: 12

테이블이 6 개 밖에 없는 경우에 Open tables 값이 12 (이)라고 표시되는 것에, 당혹해 하는 경우도 있습니다.

MySQL (은)는 multi-thread화 되고 있기 때문에, 다수의 클라이언트가 동시에 같은 것에 대해서 쿼리를 사용하는 일이 있습니다.2 개의 쿠라이안트스레드로 1 개의 파일에 다른 스테이터스가 발생하는 문제를 최소로 하기 위해, 동시에 실행하고 있는 스레드가 각각으로 무관계하게 테이블을 엽니다.이것은 메모리의 소비를 늘립니다만, 일반적으로 퍼포먼스는 향상합니다.ISAM 테이블과 MyISAM 테이블의 경우는, 테이블을 연 각각의 클라이언트에 데이터 파일에 대한 파일 기술자가 필요하게 됩니다.이 테이블형에서는, 인덱스 파일에 대한 파일 기술자가 모든 스레드로 공유됩니다.

다음의 섹션에서도 이 토픽에 대해 한층 더 설명합니다. See 항5.4.7. 「MySQL (으)로의 테이블의 오픈과 클로우즈의 방법」 .

5.4.7. MySQL (으)로의 테이블의 오픈과 클로우즈의 방법

table_cache ,max_connections , 및 max_tmp_tables 서버 변수는, 서버가 열린 상태로 보관 유지할 수 있는 파일의 최대수에 영향을 줍니다. 이러한 값의 1 개이상을 증가하면,OS 에 의해서 제한되고 있다 1 프로세스가 가질 수 있는 파일 기술자의 최대수까지 실행이 가능하게 됩니다.시스템 마다 방법은 다양합니다만, 다수의 operating system로 오픈 파일의 제한치를 올릴 수 있습니다. 제한치의 확대가 가능할지의 판정, 및 그 실행 방법에 대해서는, 사용하는 operating system의 문서를 참조해 주세요.

table_cache 하 max_connections (와)과 관계합니다.예를 들어, 동시 접속수가 200 의 경우, 최저 200 * n 의 테이블 캐쉬 사이즈가 필요합니다.이 n (은)는 결합으로 사용하는 테이블수의 최대치를 나타냅니다.또, 텐포라리테이불과 파일용의 파일 기술자도 필요합니다.

당신의 operating system가 table_cache 의 설정에 따른 파일 기술자의 수를 처리할 수 있는 것을 확인해 주세요.table_cache 의 설정이 너무 높으면,MySQL 하지만 파일 기술자를 다 써 버려 접속을 거부해, 쿼리의 실행을 할 수 없게 되어, 신뢰성이 큰폭으로 저하합니다.또,MyISAM 스토리지 엔진에서는1 개의 테이블 마다 2 개의 파일 기술자가 필요한 것도 고려에 넣을 필요가 있습니다.--open-files-limit=# 스타트 업 옵션을 사용하면,MySQL 그리고 사용 가능한 파일 기술자수를 확대할 수 있습니다. See 항A.2.17. 「File Not Found 에러」 .

오픈 테이블의 캐쉬는,table_cache 엔트리 레벨에 보관 유지됩니다.디폴트치는 64 입니다.이것은,-O table_cache=# 옵션 mysqld 에게 주는 것으로 변경할 수 있습니다.MySQL (은)는 일시적으로 한층 더 많은 테이블을 열어 쿼리의 실행을 실현하는 일이 있습니다.

이하의 상황에서는, 사용되어 있지 않은 테이블이 닫혀져 테이블 캐쉬로부터 삭제됩니다.

  • 캐쉬가 만배 때에, 캐쉬에 없는 테이블을 스레드가 열리려고 했을 경우.

  • 캐쉬에 table_cache (을)를 넘는 엔트리가 있어, 어느 스레드가 테이블의 사용을 끝냈을 경우.

  • 몇개의 유저가 mysqladmin refresh 또는 mysqladmin flush-tables (을)를 실행했을 경우.

  • 몇개의 유저가 FLUSH TABLES 스테이트먼트를 실행했을 경우.

테이블 캐쉬가 만배가 되면, 서버에서는 이하의 순서에 따라서 사용하는 캐쉬 엔트리를 할당합니다.

  • 현재 사용중이 아닌 테이블은, 마지막에 사용했을 때가 낡은 것으로부터 순서에 릴리스 된다.

  • 캐쉬가 만배로 릴리스 가능한 테이블이 없고, 새롭게 테이블을 열 필요가 있는 경우는, 필요에 따라서 캐쉬가 일시적으로 확장된다.

  • 캐쉬가 일시적으로 확장된 상황으로, 사용중의 테이블이 사용되지 않게 되었을 때는, 그 테이블이 닫혀져 캐쉬로부터 릴리스 된다.

테이블은 동시 액세스의 각각으로 열립니다.즉,2 개의 스레드로 같은 테이블에 액세스 하는 경우, 또는 1 개의 스레드가 동일 쿼리로 테이블에 2 회액세스 하는 경우(테이블을 동일 테이블에 결합하는 경우등)는, 테이블 (을)를 2 회 열 필요가 있게 됩니다. 몇개의 테이블을 최초로 열 때에 2 개의 파일 기술자가 할당할 수 있어 그 후 한층 더 그 테이블을 사용하는 경우는 파일 기술자가 1 개만 할당할 수 있습니다.최초의 오픈시의 2 손톱의 기술자는, 인덱스 파일에 사용되어 이 기술자는 모든 스레드로 공유됩니다.

HANDLER table_name OPEN 스테이트먼트를 사용하고 테이블을 여는 경우는, 전용 테이블 오브젝트를 스레드에 할당할 수 있습니다. 이 테이블 오브젝트는 다른 스레드와 공유되지 않고, 스레드가 HANDLER table_name CLOSE (을)를 호출하는지, 스레드가 종료할 때까지 닫혀지지 않습니다. See 항6.4.9. 「HANDLER 구문」 . 이 경우는 테이블이 테이블 캐쉬에 되돌려집니다(캐쉬가 만배가 아닌 경우).

테이블 캐쉬가 너무 작을지 어떨지는,mysqld 의 Opened_tables 변수의 체크로 확인할 수 있습니다.비록 많은 FLUSH TABLES (을)를 실행하고 있지 않는 경우에서도, 이 값이 매우 큰 경우는, 테이블 캐쉬 사이즈를 확장할 필요가 있습니다. See 항4.6.8.3. 「SHOW STATUS 」 .

5.4.8. 1 개의 데이타베이스에 대량의 테이블을 작성했을 경우의 결점

디렉토리에 파일이 다수 있는 경우, 오픈, 클로우즈, 및 작성의 동작이 저속이 됩니다.다수의 테이블에 대해서 SELECT 스테이트먼트를 실행했을 경우, 필요한 테이블을 열 때 마다, 다른 테이블을 닫는 것이 필요하게 되기 위해, 테이블 캐쉬가 만배의 경우에 오버헤드가 조금 발생합니다.이 오버헤드는, 테이블 캐쉬를 확대하는 것으로 경감할 수 있습니다.


5.5. MySQL 서버의 최적화

5.5.1. 시스템, 컴파일 시간 및 스타트 업 파라미터의 튜닝

시스템 레벨의 요소는, 그 일부를 초기 단계로 결정할 필요가 있기 위해, 이 이야기로부터 시작합니다.이것에 해당하지 않는 경우는, 시스템을 크게 바꾸는 것이 중요하지 않기 때문에 있으면, 이 섹션은 간단하게 대충 훑어보면 충분합니다.다만, 이 레벨로 변경을 실시하는 것으로 어느 정도 개선할 수 있는지를 자각해 두는 것은 반드시 도움이 됩니다.

사용하는 operating system는 매우 중요합니다.복수 CPU 의 컴퓨터를 사용한다면,Solaris (스레드 실장 기능이 우수하다) 또는 Linux (2.2 커넬의 SMP 서포트가 우수하다)가 좋을 것입니다. 또, 구버젼의 Linux 커넬의 디폴트에는 2G 파일 사이즈의 제한이 있습니다.이 커넬로 2G 보다 큰 파일이 아무래도 필요한 경우는,ext2 파일 시스템의 LFS (Large File System ) 패치를 입수할 필요가 있습니다. 이외의 ReiserFS (이)나 XFS 등에는 2G 의 제한이 없습니다.

많은 플랫폼상에서,MySQL (을)를 실전 가동시키지 않기 때문에, 가능하면 선택전에 후보의 플랫폼의 테스트를 실행하는 것을 추천 합니다.

그 외의 힌트:

  • RAM 하지만 충분히 있는 경우는, 스왑 디바이스 모든 것을 삭제할 수 있다. operating system에 따라서는, 빈메모리가 있는 경우에서도 스왑 디바이스가 사용되는 일이 있다.

  • --skip-external-locking MySQL 옵션을 사용하고, 외부 락을 회피한다.실행하고 있는 것이 1 서버 뿐인 한, 여기에 따른 MySQL 의 기능에 대한 영향은 없다.myisamchk (을)를 실행하기 전에 서버의 기록을 취하는(또는 대응하는 테이블을 잠그어, 플래시 한다) 일을 잊지 않게 한다.일부의 시스템은, 외부 락이 전혀 기능하지 않기 때문에, 이 옵션이 필수가 된다.

    MySQL 4.0 이?~ ,--skip-external-locking 옵션은 디폴트로 온이 되어 있다. 그 이전은,MIT-pthread 에 의한 컴파일시에 디폴트로 온이 되어 있다.이것은 flock() 하지만 모든 플랫폼에서 MIT-pthread 에 의해 완전하게 서포트되고 있는 것은 아닌 것에 밤.Linux 파일 락은 안전하지 않기 때문에,Linux 그렇지만 디폴트로 온이 되어 있다.

    --skip-external-locking (을)를 사용할 수 없는 상황은, 동일 데이터에 대해서 복수의 MySQL 서버 (클라이언트는 아니다)(을)를 실행하고 있는 경우와 서버에 대해서 처음에 테이블의 플래시와 락을 실시하는 지시를 내리지 않고 , 테이블에 대해서 myisamchk (을)를 실행하는 경우에 한정된다.

    --skip-external-locking (을)를 사용하고 있는 경우에서도LOCK TABLES/UNLOCK TABLES (은)는 사용할 수 있다.

5.5.2. 서버 파라미터의 튜닝

mysqld 서버로 사용되는 디폴트의 버퍼 사이즈는 다음의 커멘드로 확인할 수 있습니다.

shell> mysqld --help

이 커멘드에 의해서,mysqld 옵션과 설정 가능한 변수 모든 일람이 생성됩니다.이 출력에는, 디폴트의 변수치도 기재되어 이하와 같이 표시됩니다.

back_log                 current value: 5
bdb_cache_size           current value: 1048540
binlog_cache_size        current value: 32768
connect_timeout          current value: 5
delayed_insert_timeout   current value: 300
delayed_insert_limit     current value: 100
delayed_queue_size       current value: 1000
flush_time               current value: 0
interactive_timeout      current value: 28800
join_buffer_size         current value: 131072
key_buffer_size          current value: 1048540
lower_case_table_names   current value: 0
long_query_time          current value: 10
max_allowed_packet       current value: 1048576
max_binlog_cache_size    current value: 4294967295
max_connections          current value: 100
max_connect_errors       current value: 10
max_delayed_threads      current value: 20
max_heap_table_size      current value: 16777216
max_join_size            current value: 4294967295
max_sort_length          current value: 1024
max_tmp_tables           current value: 32
max_write_lock_count     current value: 4294967295
myisam_sort_buffer_size  current value: 8388608
net_buffer_length        current value: 16384
net_retry_count          current value: 10
net_read_timeout         current value: 30
net_write_timeout        current value: 60
read_buffer_size         current value: 131072
read_rnd_buffer_size     current value: 262144
slow_launch_time         current value: 2
sort_buffer              current value: 2097116
table_cache              current value: 64
thread_concurrency       current value: 10
tmp_table_size           current value: 1048576
thread_stack             current value: 131072
wait_timeout             current value: 28800

현재 실행중의 mysqld 서버가 있는 경우는, 다음의 스테이트먼트로 변수에 실제로 사용되고 있는 값을 조사할 수 있습니다.

mysql> SHOW VARIABLES;

또, 다음의 스테이트먼트에서는, 실행중의 서버의 통계나 스테이터스 인디케이터(indicator)를 조사할 수 있습니다.

mysql> SHOW STATUS;

모든 변수의 상세 설명에 대해서는, 본메뉴얼의 SHOW VARIABLES 섹션을 참조해 주세요. See 항4.6.8.4. 「SHOW VARIABLES 」 . 스테이터스 변수 상세한 것에 대하여는, 항4.6.8.3. 「SHOW STATUS 」 (을)를 참조해 주세요.

서버 변수와 스테이터스 정보는,mysqladmin 그렇지만 입수할 수 있습니다.

shell> mysqladmin variables
shell> mysqladmin extended-status

MySQL (은)는 매우 측정할 수 있는 알고리즘을 사용하고 있기 때문에, 통상은 실행시의 메모리 소비가 매우 작아집니다.그러나,MySQL 에 대한 메모리를 많이 할당하면, 통상은 퍼포먼스가 향상합니다.

MySQL 서버를 튜닝 할 때에 사용되는 가장 중요한 변수는 key_buffer_size (와)과 table_cache 의 2 개입니다.다른 변수의 변경을 실시하기 전에 이 변수를 미리 적절히 설정해 두는 것으로 자신이 붙습니다.

이하에 전형적인 변수를 실행시로 설정해 있는 예를 나타냅니다.이 예는 mysqld_safe 스크립트를 사용해,--name=value 구문으로 변수 name (을)를 값 value (으)로 설정해 있습니다.이 구문은,MySQL 4.0 (으)로부터 이용할 수 있습니다.구버젼의 MySQL 의 경우는, 이하의 차이점을 고려해 주세요.

  • mysqld_safe (이)가 아니고,safe_mysqld (을)를 사용한다.

  • --set-variable=name=value 또는 -O name=value 구문을 사용해 변수를 설정한다.

  • _size 그리고 끝나는 변수명은 _size 없이의 지정이 필요한 경우가 있다.예를 들어,sort_buffer_size 의 구명은 sort_buffer 이다.read_buffer_size 의 구명은 record_buffer 이다.서버 버젼으로 인식되는 변수를 조사할 때는 mysqld --help (을)를 사용한다.

최소 256M 의 메모리로 다수의 테이블이 있어, 중간 정도의 클라이언트로 최대의 퍼포먼스를 얻으려면 , 다음과 같이 사용합니다.

shell> mysqld_safe --key_buffer_size=64M --table_cache=256 \
           --sort_buffer_size=4M --read_buffer_size=1M &

메모리가 128M 그리고, 테이블은 소수로 대량의 소트의 실행이 필요한 경우는, 다음과 같이 사용할 수 있습니다.

shell> mysqld_safe --key_buffer_size=16M --sort_buffer_size=1M

메모리가 거의 없게 대량의 접속이 있는 경우는, 다음과 같이 사용합니다.

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 -O 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 하지만 격납되어 시스템 최적화의 베이스로서 사용할 수 있습니다.

동시 접속이 매우 많은 경우, 접속 마다 mysqld 그리고 사용되는 메모리를 매우 작게 하고 있지 않으면 스왑의 문제가 발생하는 일이 있습니다.말할 필요도 없이, 모든 접속에 사용 가능한 메모리가 충분히 있는 경우는 mysqld 의 퍼포먼스가 향상합니다.

mysqld 또는 mysqld_safe 의 커멘드 라인으로 옵션을 지정했을 경우, 그 서버의 호출로 밖에 유효성이 보관 유지되지 않는 것에 주의해 주세요. 서버 실행마다 옵션을 사용하는 경우는, 옵션 설정 파일에 배치합니다.

파라미터 변경의 유효성을 조사하려면 , 다음과 같이 실행합니다.

shell> mysqld --key_buffer_size=32m --help

반드시 --help (을)를 마지막으로 지정합니다.마지막에 하지 않으면 커멘드 라인의 그것이?~ 에 기재된 옵션의 효과가 출력에 반영되지 않습니다.

5.5.3. MySQL 의 속도에 대한 컴파일과 링크의 영향

이하의 테스트의 대부분은,MySQL 벤치마크를 사용했다 Linux 그리고 실행되고 있습니다만, 이외의 operating system 및 작업의 부담량에 대해서도 일정한 지침이 됩니다.

-static (와)과 링크했을 경우에 최고 속도의 바이너리를 얻을 수 있습니다.

Linux 위에서는,pgcc 및 -O3 그리고 컴파일 했을 경우에 최고 속도의 코드를 얻을 수 있습니다.이러한 옵션으로 sql_yacc.cc (을)를 컴파일 하는 경우는,gcc/pgcc 그리고 함수의 모든 것을 인 라인으로 할 때에 대량의 메모리가 요구되기 위해 약 200M 의 메모리가 필요합니다.MySQL 의 콘피개시에 CXX=gcc 도 설정하고,libstdc++ 라이브러리(이것은 불필요합니다)가 포함되지 않게 합니다.pgcc 의 일부의 버젼에서는, 생성된 코드를 x586 타입의 프로세서(AMD 등) 모두로 동작 가능하게 하는 컴파일러 옵션을 사용해도, 코드가 순정 Pentium 프로세서로 밖에 실행할 수 없기 때문에 주의가 필요합니다.

적절한 컴파일러 및 컴파일러 옵션을 사용하는 것으로, 어플리케이션의 속도가 10 －30% 개선됩니다.이것은 각자 SQL 서버를 컴파일 하는 경우에 특히 중요합니다.

Cygnus CodeFusion (와)과 Fujitsu 컴파일러의 양쪽 모두를 테스트했습니다만, 모두 버그 프리가 아니고, 최적화를 온으로 해 MySQL (을)를 컴파일 하려면 불충분했습니다.

MySQL 의 컴파일시는, 사용하는 캐릭터 세트의 서포트만을 포함합니다(옵션 --with-charset=xxx ). 표준의 MySQL 바이너리 디스트리뷰션은, 모든 캐릭터 세트를 서포트하도록(듯이) 컴파일 되고 있습니다.

이하에 실시한 측정 결과의 일부를 소개합니다.

  • pgcc (을)를 사용해, 모든 것을 -O6 그리고 컴파일 했을 경우,mysqld 서버는 gcc 2.95.2 (와)과 비교해 1% 속도가 오른다.

  • 동적으로 링크했을 경우(-static 없음)은, 결과가 Linux 위에서 13% 늦어졌다.클라이언트 어플리케이션에는 동적 링크의 MySQL 라이브러리를 사용할 수 있는 것에 주의한다.이것은, 서버의 퍼포먼스 카미에대이다.

  • strip libexec/mysqld (을)를 사용해 mysqld 바이너리를 스트립 하면, 생성된 바이너리의 속도를 4% 까지 올려진다.

  • 동일 호스트상에서 실행되는 클라이언트로부터 서버에의 접속으로,Unix 소켓 파일이 아니고,TCP/IP 그리고 접속하면,7.5% 퍼포먼스가 늦어졌다(호스트명 localhost 에 접속하는 경우,MySQL 그럼 디폴트로 소켓 파일이 사용된다).

  • 클라이언트로부터 서버에의 TCP/IP 접속으로 다른 호스트에게 있는 리모트 서버에 접속했을 경우,100M 이서네트(ethernet)에 의한 접속에서도, 동일 호스트상의 로컬 서버에 접속했을 경우와 비교하고,8-11% 늦어졌다.

  • 암호화한 접속(내부 SSL 서포트에 의한 모든 데이터의 암호화)를 사용해 benchmark test를 실행했을 경우, 퍼포먼스가 55% 늦어졌다.

  • --with-debug=full 그리고 컴파일 하면, 대부분의 쿼리가 20% 늦어진다. 일부의 쿼리는 꽤 길게 걸렸다(예를 들어 MySQL 벤치마크는 35% 의 속도 저하).--with-debug (을)를 사용하면, 이 속도 저하는 15% 그리고 끝난다.--with-debug=full 그리고 컴파일 되었다 mysqld 버젼은,--skip-safemalloc 옵션으로 기동하면 실행시의 메모리체크를 무효화할 수 있다.이 경우의 최종적인 결과는,--with-debug 그리고 구성했을 경우에 매우 가깝게 된다.

  • Sun UltraSPARC-IIe, Forte 5.0 (은)는,gcc 3.2 보다 4% 속도가 올랐다.

  • Sun UltraSPARC-IIe, Forte 5.0 그럼,64 비트 모드보다 32 비트 모드 쪽이 4% 빨랐다.

  • gcc 2.95.2 for UltraSPARC 에 옵션 -mcpu=v8 -Wa,-xarch=v8plusa (을)를 붙여 컴파일 하면, 퍼포먼스가 4% 개선했다.

  • Solaris 2.5.1, MIT-pthreads (은)는, 단일 프로세서상에서 Solaris 네이티브스레드보다 8-12% 늦었다.CPU 의 부하가 증가하는 곳의 차이는 한층 더 확대한다.

  • --log-bin (을)를 사용해 실행하면 mysqld 하지만 1% 늦어졌다.

  • 프레임 포인터 -fomit-frame-pointer 또는 -fomit-frame-pointer -ffixed-ebp 없이 gcc (을)를 사용해 Linux-x86 그리고 컴파일 하면,mysqld 하지만 1-4% 빨라졌다.

pgcc 에 의한 컴파일에 MySQL AB 제공의 MySQL-Linux 디스트리뷰션을 사용했지만,AMD 그리고 실행되지 않는 코드를 생성하는 버그가 pgcc 에 있었기 때문에, 통상의 gcc 의 사용에 되돌리지 않을 수 없었습니다.이 버그가 해결될 때까지 gcc 의 사용을 속행합니다. 다만,AMD 이외의 컴퓨터를 사용하는 경우는,pgcc 그리고 컴파일 하면 고속의 바이너리를 얻을 수 있습니다.표준의 MySQL Linux 바이너리는, 속도 및 이식성을 높이기 위해 정적으로 링크되고 있습니다.

5.5.4. MySQL (으)로의 메모리의 사용

이하의 일람은,mysqld 서버로의 메모리의 사용 방법의 일부를 나타내고 있습니다.가능한 경우는, 메모리 사용에 관련하는 서버 변수명도 기재되어 있습니다.

  • 키 버퍼(변수 key_buffer_size )(은)는 모든 스레드로 공유된다.서버가 사용하는 이외의 버퍼는 필요에 따라서 할당할 수 있다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

  • 각각의 접속은, 스택(디폴트 64K , 변수 thread_stack ), 접속 버퍼(변수 net_buffer_length ), 및 결과 버퍼(net_buffer_length )의 스레드 고유 영역을 사용한다.접속 버퍼와 결과 버퍼는 필요에 따라서 max_allowed_packet 까지 동적으로 확장된다.쿼리의 실행중은 현재의 쿼리 문자열의 카피도 할당할 수 있다.

  • 모든 스레드로 같은 베이스메모리가 공유된다.

  • 압축 ISAM 및 MyISAM 테이블만이 메모리에 맵 된다.이것은,4 GB 의 32 빗트메모리 영역에서는 대형의 대부분의 테이블에 충분할 만큼(정도)는 크지 않은 것에 밤.64 비트 주소 영역이 있는 시스템이 일반적으로 되면, 메모리 맵 의 일반 서포트의 추가가 가능하게 된다.

  • 테이블의 차례차례 스캔을 실시하는 요구는 각각, 독해 버퍼(변수 read_buffer_size )(을)를 할당한다.

  • 레코드를 `` 랜덤인'' 순서로 읽어내는 경우(소트 후 등), 랜덤 독해 버퍼를 할당할 수 있는 디스크 시크가 회피된다(변수 read_rnd_buffer_size ).

  • 결합은 모두 1 회의 수수로 실행되어 대부분의 결합은 텐포라리테이불을 사용하지 않고 실행된다.텐포라리테이불의 대부분은 메모리베이스(HEAP ) 테이블이다.레코드장의 큰 텐포라리테이불(모든 컬럼장의 합계로서 산출)이나 BLOB 컬럼이 포함되는 텐포라리테이불은 디스크상에 격납된다.

    버젼 3.23.2 보다 전의 MySQL 에는, 메모리내의 HEAP 테이블이 tmp_table_size 의 사이즈를 넘었을 경우에 에러 The table tbl_name is full 하지만 출력되는 문제가 있었다.3.23.2 이?~ , 이 문제는 필요에 따라서 메모리내 HEAP 테이블을 디스크 베이스 MyISAM 테이블로 변경되는 것으로 자동적으로 처리된다.이 문제를 회피하려면 ,tmp_table_size 옵션을 mysqld (으)로 설정하는지, 클라이언트 프로그램으로 SQL 옵션 BIG_TABLES (을)를 설정하는 것으로, 텐포라리테이불의 사이즈를 확장한다.See 항5.5.6. 「SET 구문」 .MySQL 버젼 3.20 그럼, 텐포라리테이불의 최대 사이즈가 record_buffer*16 에서 만났다.이 버젼을 사용하고 있는 경우는,record_buffer 의 값을 확대할 필요가 있다.또,--big-tables 옵션으로 mysqld (을)를 기동하고, 항상 텐포라리테이불을 디스크에 격납할 수도 있다.다만, 이것은 복잡한 쿼리의 대부분으로 처리 속도에 영향을 미친다.

  • 소트를 실행하는 요구의 대부분으로, 소트 버퍼 및 결과 세트 사이즈에 응했다 0 (으)로부터 2 개의 임시 파일을 할당할 수 있다. See 항A.4.4. 「MySQL 하지만 임시 파일을 격납하는 장소」 .

  • 해석 및 계산의 거의 모든 것이, 로컬 메모 restore로 실행된다.작은 아이템에는 메모리오버헤드가 불필요하고, 통상의 저속 메모리의 할당 및 해방은 회피된다.메모리는, 예측외의 규모의 문자열의 경우만 할당할 수 있어 이것은,malloc() 및 free() 그리고 실행된다.

  • 인덱스 파일은 각각 1 회 열려 데이터 파일은, 동시 실행 스레드 마다 1 회 열린다.동시 스레드의 각각 대하고, 테이블 구조, 각 컬럼의 컬럼 구조, 사이즈 3 * n 의 버퍼를 할당할 수 있다(n (은)는, 레코드의 최대장, 다만 BLOB 컬럼은 계산외).BLOB 컬럼은,5 (으)로부터 8 아르바이트에 BLOB 데이터의 길이를 가산한 아르바이트수를 사용한다.ISAM 및 MyISAM 스토리지 엔진은, 내부 사용을 위한 추가 레코드를 1 개사용한다.

  • BLOB 컬럼이 있는 테이블의 각각으로, 큰 BLOB 값을 읽어들이기 위해서 버퍼가 동적으로 확장된다.테이블을 스캔 하는 경우는, 최대 BLOB 값과 같은 크기의 버퍼를 할당할 수 있다.

  • 사용중 테이블 모든 핸들러 구조가 캐쉬에 보존되어FIFO 형식에서 관리된다.일반적으로 캐쉬에는 64 의 엔트리가 있다.테이블이 동시에 2 개의 실행 스레드로 사용되고 있는 경우, 캐쉬에는 그 테이블의 엔트리가 2 개 배치된다. See 항5.4.7. 「MySQL (으)로의 테이블의 오픈과 클로우즈의 방법」 .

  • mysqladmin flush-tables 커멘드(또는 FLUSH TABLES 스테이트먼트)에 의해서, 사용중이 아닌 테이블 모든 것이 닫혀져 현재 실행중의 스레드의 종료시에 사용중의 테이블 모든 것이 닫혀지도록(듯이) 지정된다.이것으로 효율적으로 사용중 메모리에 빈 곳을 만들 수 있다.

ps 및 그 외의 스테이터스 프로그램에 의해서,mysqld 하지만 대량의 메모리를 사용하고 있는 것을 나타내는 리포트를 하는 일이 있습니다.이것은, 복수의 메모리아드레스로의 스레드스탁크에 의해서 발생합니다.예를 들어,Solaris 버젼의 ps 그럼 스택간의 사용하고 있지 않는 메모리가 사용 메모리에 카운트 됩니다.이것은,swap -s 그리고 사용 가능 스왑을 체크하는 것으로 검증할 수 있습니다.시판의 메모리 리크 검출 장치로 mysqld (을)를 테스트해, 메모리 리크가 없으면 판명되어 있습니다.

5.5.5. MySQL 의 DNS 의 사용

새로운 클라이언트가 mysqld 에 접속하면,mysqld 에 의해서 요구를 처리하는 신규의 스레드가 작성됩니다.이 스레드에서는, 우선 호스트명이 호스트명 캐쉬에 있을지가 체크됩니다.없는 경우는, 호스트명의 해결이 시행됩니다.

  • operating system가 스레드세이후의 gethostbyaddr_r() (와)과 gethostbyname_r() 의 호출을 서포트하고 있는 경우, 스레드에서는 이것을 사용해 호스트명의 해결이 실행된다.

  • operating system가 스레드세이후의 호출을 서포트하고 있지 않는 경우, 스레드에서는 상호 배제 락을 실시해, 대신에 gethostbyaddr() (와)과 gethostbyname() 하지만 불려 간다.이 경우, 다른 스레드에서는 최초의 스레드가 상호 배제 락을 해제할 때까지 호스트명 캐쉬내의 호스트명을 해결할 수 없게 되는 것에 주의한다.

--skip-name-resolve (을)를 mysqld 옵션을 지정해 기동하면,DNS 호스트명 룩 업을 무효화할 수 있습니다.다만, 이 경우는,MySQL 권한 테이블로 IP 번호 밖에 사용할 수 없게 됩니다.

매우 저속의 DNS (와)과 다수의 호스트가 있는 경우는,--skip-name-resolve 그리고 DNS 룩 업을 무효화하는지,HOST_CACHE_SIZE 의 정의(디폴트치: 128 )(을)를 확장해,mysqld (을)를 재컴파일 하는 것으로, 퍼포먼스를 개선할 수 있습니다.

--skip-host-cache 옵션을 사용해 서버를 기동하면, 호스트명 캐쉬를 무효화할 수 있습니다.호스트명의 캐쉬를 클리어 하려면 ,FLUSH HOSTS 스테이트먼트를 사용하는지,mysqladmin flush-hosts 커멘드를 실행합니다.

TCP/IP 접속 모든 것을 인정하지 않는 경우는,--skip-networking 옵션을 지정해 mysqld (을)를 개시합니다.

5.5.6. SET 구문

SET [GLOBAL | SESSION] sql_variable=expression,
    [[GLOBAL | SESSION] sql_variable=expression] ...

SET (은)는, 서버나 클라이언트의 동작에 영향을 미치는 다양한 옵션을 설정합니다.

이하의 예는, 변수의 설정에 사용할 수 있는 각종의 구문을 나타내고 있습니다.

구버젼의 MySQL 그럼,SET OPTION 구문의 사용을 허가하고 있었습니다만, 지금은 폐?~ 되고 있습니다.

MySQL 4.0.3 그럼,GLOBAL 옵션,SESSION 옵션, 및 가장 중요한 스타트 업 변수에의 액세스를 추가하고 있습니다.

LOCAL (은)는,SESSION 의 동의어로서 사용할 수 있습니다.

1 개의 커멘드 라인에 복수의 변수를 설정하는 경우는, 마지막 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;

@@variable_name 구문은,MySQL 구문과 그 외의 데이타베이스와의 호환성을 보관 유지를 목적으로 서포트되고 있습니다.

이 메뉴얼의 시스템 변수의 섹션으로 설정 가능한 다양한 시스템 변수에 관한 설명이 있습니다. See 항6.1.5. 「시스템 변수」 .

SESSION (디폴트)(을)를 사용하고 있는 경우, 현재의 세션을 종료할 때까지, 혹은 이 옵션에 다른 값을 설정할 때까지, 설정한 옵션이 유효하게 됩니다.SUPER 특권을 필요로 한다 GLOBAL (을)를 사용했을 경우, 서버의 재기동을 할 때까지 옵션이 기억되어 신규 접속시도 사용됩니다.옵션을 영속적으로 하는 경우는, 옵션 설정 파일로 설정합니다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

부적절한 사용을 막기 위해,SET SESSION 그리고 밖에 사용할 수 없는 변수와 함께 SET GLOBAL (을)를 사용했을 경우나, 글로벌 변수에 SET GLOBAL (을)를 사용하지 않는 경우에는 MySQL (으)로부터 에러가 출력됩니다.

SESSION 변수를 GLOBAL 값에, 혹은 GLOBAL 값을 MySQL 의 디폴트치로 설정하는 경우는,DEFAULT (으)로서 설정할 수 있습니다.

SET max_join_size=DEFAULT;

이것은 이하와 동일하게 됩니다.

SET @@session.max_join_size=@@global.max_join_size;

SET 커멘드로 설정 가능한 서버 변수에 최대치를 설정해 제한하는 경우,--maximum-variable-name 커멘드 라인 옵션을 사용해 최대치를 지정할 수 있습니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

SHOW VARIABLES (을)를 사용하면, 대부분의 변수의 일람이 출력됩니다. See 항4.6.8.4. 「SHOW VARIABLES 」 . @@[global.|local.]variable_name 구문을 사용하면 특정의 변수의 값을 취득할 수 있습니다.

SHOW VARIABLES like "max_join_size";
SHOW GLOBAL VARIABLES like "max_join_size";
SELECT @@max_join_size, @@global.max_join_size;

이하에, 비표준 SET 구문을 사용하는 변수 및 그 외의 변수의 일부에 도착해 설명합니다.이외의 변수 정의는, 시스템 변수 섹션의 스타트 업 옵션의 부분 또는 SHOW VARIABLES 의 설명에 기재되어 있습니다. See 항6.1.5. 「시스템 변수」 . See 항4.1.1. 「mysqld 커멘드 라인 옵션」 . See 항4.6.8.4. 「SHOW VARIABLES 」 .

  • AUTOCOMMIT= 0 | 1

    1 (으)로 설정하면, 테이블에 대한 변경 모든 것이 즉시 실행된다.트랜잭션(transaction)를 유효하게 하는 경우는,BEGIN 스테이트먼트를 사용할 필요가 있다.See 항6.7.1. 「START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문」 .0 (으)로 설정했을 경우는, 그 트랜잭션(transaction)를 COMMIT 그리고 받아 들이는지,ROLLBACK 그리고 취소할 필요가 있다. See 항6.7.1. 「START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문」 . AUTOCOMMIT 모드를 0 (으)로부터 1 (으)로 변경하면, 열려 있는 모든 트랜잭션(transaction)에 대해서 MySQL 하지만 COMMIT (을)를 자동 실행하기 위해(때문에) 주의가 필요하다.

  • BIG_TABLES = 0 | 1

    1 (으)로 설정하면, 텐포라리테이불의 모든 것이 메모리는 아니고 디스크에 격납된다.이것에 의해서 속도가 조금 저하하지만, 큰 텐포라리테이불을 필요로 하는 대규모 SELECT 조작에서도 에러 The table tbl_name is full 하지만 출력되지 않게 된다.새롭게 접속했을 경우의 디폴트치는 0 (메모리내 텐포라리테이불을 사용)이다. 이 변수는 구칭 SQL_BIG_TABLES 에서 만났다.MySQL 4.0 그럼,MySQL 에 의해서 필요에 따라서 메모리내 테이블이 디스크 베이스 테이블에 자동변역되기 위해, 통상 이 변수의 설정이 필요한 상황은 없다.

  • CHARACTER SET character_set_name | DEFAULT

    이것은, 클라이언트와의 사이에 교환되는 모든 문자열로 지정의 매핑을 실시한다. 현재,character_set_name 의 유일한 옵션은 cp1251_koi8 뿐이지만,MySQL 소스 디스트리뷰션의 sql/convert.cc 파일을 편집해 용이하게 신규의 매핑을 추가할 수 있다.디폴트의 매핑은,DEFAULT 의 character_set_name 값을 사용해 restore 할 수 있다.

    CHARACTER SET 옵션을 설정하는 구문은, 다른 옵션을 설정하는 구문과는 다르기 위해 주의가 필요하다.

  • DATE_FORMAT = format_str

    서버로 DATE 값을 문자열로 변환하는 방법을 설정한다.이 변수는, 글로벌 옵션, 로컬 옵션, 커멘드 라인 옵션의 머지않아에서도 사용할 수 있다.format_str 의 지정에는 GET_FORMAT() 함수의 사용이 편리하다. See 항6.3.4. 「일자와 시각 함수」 (을)를 참조.

  • DATETIME_FORMAT = format_str

    서버로 DATETIME 값을 문자열로 변환하는 방법을 설정한다.이 변수는, 글로벌 옵션, 로컬 옵션, 커멘드 라인 옵션의 머지않아에서도 사용할 수 있다.format_str 의 지정에는 GET_FORMAT() 함수의 사용이 편리하다. See 항6.3.4. 「일자와 시각 함수」 (을)를 참조.

  • INSERT_ID = #

    다음의 INSERT (이)나 ALTER TABLE 커멘드로 사용된다 AUTO_INCREMENT 값을 설정한다.이것은 주로 바이너리 로그와 함께 사용된다.

  • LAST_INSERT_ID = #

    LAST_INSERT_ID() (으)로부터 돌려주어지는 값을 설정한다.이것은, 테이블을 갱신하는 커멘드로 LAST_INSERT_ID() 함수를 사용했을 경우에 바이너리 로그에 격납된다.

  • LOW_PRIORITY_UPDATES = 0 | 1

    1 (으)로 설정했을 경우, 모든 INSERT ,UPDATE ,DELETE , 및 LOCK TABLE WRITE 스테이트먼트가, 같은 테이블에 대해서 실행되고 있다 SELECT (이)나 LOCK TABLE READ 하지만 없어질 때까지 대기한다. 이 변수는 구칭 SQL_LOW_PRIORITY_UPDATES 에서 만났다.

  • MAX_JOIN_SIZE = value | DEFAULT

    value (을)를 넘는 레코드의 편성을 조사하는 것이 필요한 SELECT 스테이트먼트, 또는 value (을)를 넘는 디스크 시크의 실행이 전망된다 SELECT 스테이트먼트를 허가하지 않는다.이 값을 설정하면, 키의 사용이 부적절하고 장시간 걸린다고 전망된다 SELECT 스테이트먼트를 포착할 수 있다.DEFAULT 이외의 값으로 설정하면,SQL_BIG_SELECTS 값이 0 에 리셋트 된다.SQL_BIG_SELECTS 값을 설정 다시 하면,SQL_MAX_JOIN_SIZE 변수는 무시된다.mysqld (을)를 --max_join_size=value 옵션을 지정해 기동하면, 이 변수에 디폴트치를 설정할 수 있다.이 변수는 구칭 SQL_MAX_JOIN_SIZE 에서 만났다.

    쿼리 결과가 벌써 쿼리 캐쉬에 있는 경우는, 결과가 벌써 계산되고 있어 클라이언트에의 송신에 의한 부하가 서버에 걸리지 않기 때문에, 결과 사이즈의 체크는 실행되지 않는다.

  • PASSWORD = PASSWORD (' 패스워드' )

    현재의 유저의 패스워드를 설정한다.모든 비익명 유저는 각자의 패스워드를 변경할 수 있다.

  • PASSWORD FOR user = PASSWORD (' 패스워드' )

    현재의 서버 호스트의 특정 유저의 패스워드를 설정한다.이 실행은,mysql 데이타베이스에의 액세스가 있는 유저에게 한정된다.유저는 user@hostname 의 형식에서 지정할 필요가 있다.user (와)과 hostname (은)는,mysql.user 테이블 엔트리의 User 컬럼과 Host 컬럼의 기재대로 할 필요가 있다.예를 들어,User 필드와 Host 필드의 엔트리가 'bob' 및 '%.loc.gov' 의 경우는 다음과 같이 입력한다.

    mysql> SET PASSWORD FOR 'bob'@'%.loc.gov' = PASSWORD('newpass');

    이것은 이하와 동일하게 된다.

    mysql> UPDATE mysql.user SET Password=PASSWORD('newpass')
    ->                   WHERE User='bob' AND Host='%.loc.gov';
mysql> FLUSH PRIVILEGES;

  • QUERY_CACHE_TYPE = OFF | ON | DEMAND , QUERY_CACHE_TYPE = 0 | 1 | 2

    스레드에 쿼리 캐쉬 설정을 실시한다.

    옵션 | 설명
    0 또는 OFF | 결과의 캐쉬나 취득을 실시하지 않는다.
    1 또는 ON | SELECT SQL_NO_CACHE ... 쿼리를 제외한 모든 결과를 캐쉬한다.
    2 또는 DEMAND (은)는, | SELECT SQL_CACHE ... 쿼리만을 캐쉬한다.

  • SQL_AUTO_IS_NULL = 0 | 1

    1 (디폴트)(으)로 설정하면,WHERE auto_increment_column IS NULL 의 구조를 사용해 AUTO_INCREMENT 컬럼이 포함되는 테이블로 마지막에 삽입된 레코드를 검색할 수 있다.이것은,Access 등의 ODBC 프로그램의 일부에서 사용된다.

  • SQL_BIG_SELECTS = 0 | 1

    0 (으)로 설정하면, 장시간 필요로 한다고 전망된다(Optimizer에 의해서 MAX_JOIN_SIZE 의 값을 넘는 레코드수를 조사할 수 있다고 전망된다)SELECT 스테이트먼트가 MySQL 에 의해서 안?~ 된다. 이것은 부적절한 WHERE 스테이트먼트가 사용되었을 경우에 도움이 된다.새롭게 접속했을 경우의 디폴트치는 1 그리고, 모든 1 스테이트먼트가 허가된다.

    MAX_JOIN_SIZE (을)를 DEFAULT 이외의 값으로 설정하면,SQL_BIG_SELECTS 하지만 0 (으)로 설정된다.

  • SQL_BUFFER_RESULT = 0 | 1

    SQL_BUFFER_RESULT 하 SELECT 스테이트먼트로부터의 결과를 강제적으로 텐포라리테이불에 넣는다.이것은,MySQL 에 의한 테이블 락 해제의 조기화와 결과 세트의 클라이언트에의 송신에 장시간 걸리는 경우에 도움이 된다.

  • SQL_LOG_BIN = 0 | 1

    0 (으)로 설정하면, 클라이언트에 SUPER 특권이 있는 경우, 그 클라이언트에 관한 바이너리 로그에의 로그 기록을 하지 않게 된다.

  • SQL_LOG_OFF = 0 | 1

    1 (으)로 설정하면, 클라이언트에 SUPER 특권이 있는 경우, 그 클라이언트에 관한 표준 로그에의 로그 기록을 하지 않게 된다.

  • SQL_LOG_UPDATE = 0 | 1

    0 (으)로 설정하면, 클라이언트에 SUPER 특권이 있는 경우, 그 클라이언트에 관한 갱신 로그에의 로그 기록을 하지 않게 된다. 버젼 5.0 이?~ (은)는 이 변수가 폐?~ 되고 있다.

  • SQL_QUOTE_SHOW_CREATE = 0 | 1

    1 (으)로 설정하면,SHOW CREATE TABLE 그리고 테이블명과 컬럼명이 쿼츠 된다.이것은 디폴트로 온 (이)가 되어 있어, 멀티 바이트 문자등을 사용한 컬럼명을 가지는 테이블의 replication를 가능하게 한다. 항4.6.8.8. 「SHOW CREATE TABLE 」 .

  • SQL_SAFE_UPDATES = 0 | 1

    1 (으)로 설정하면,MySQL 에 의해서 WHERE 마디로 키나 LIMIT (을)를 사용하지 않는다 UPDATE 또는 DELETE 스테이트먼트가 안?~ 된다.이것으로, 손입력으로 SQL 스테이트먼트를 작성했을 경우에 잘못된 갱신의 포착이 실현된다.

  • SQL_SELECT_LIMIT = value | DEFAULT

    SELECT 스테이트먼트로부터 돌려주어지는 레코드의 최대수.SELECT 에 LIMIT 마디가 있는 경우,SQL_SELECT_LIMIT 의 값보다 LIMIT 쪽이 우선된다.새롭게 접속했을 경우의 디폴트치는 `` 무제한'' 이다.이 제한을 변경했을 경우,DEFAULT 의 SQL_SELECT_LIMIT 값을 사용해 디폴트치를 restore 할 수 있다.

  • TIMESTAMP = timestamp_value | DEFAULT

    클라이언트에 시간을 설정한다.이것은, 레코드의 restore에 바이너리 로그를 사용하는 경우, 오리지날( 로그가 기록된 시점) 의 타임 스탬프로 하기 위해서 사용된다.timestamp_value 하 MySQL 타임 스탬프는 아니고 Unix 기준 시점의 타임 스탬프로 할 필요가 있다.

  • TIME_FORMAT = format_str

    서버로 TIME 값을 문자열로 변환하는 방법을 설정한다.이 변수는, 글로벌 옵션, 로컬 옵션, 커멘드 라인 옵션의 머지않아에서도 사용할 수 있다.format_str 의 지정에는 GET_FORMAT() 함수의 사용이 편리하다. See 항6.3.4. 「일자와 시각 함수」 (을)를 참조.


5.6. 디스크 관련의 문제

  • 전술과 같이, 디스크 시크는 퍼포먼스에 대한 큰 보틀 넥이다.이 문제는, 데이터가 확대해, 효율적인 캐쉬가 실행 불능이 되는 만큼 커지는 것에 따라 명백하게 된다.대규모 데이타베이스로, 사실상 랜덤에 데이터에 액세스 하는 경우, 독해에서는 최저 1 회, 기입에서는 최저 2 회의 디스크 시크가 필요하게 되는 것을 알 수 있다.이 문제를 최소로 하려면 , 시크 회수를 줄이도록(듯이) 디스크를 사용한다.

  • 복수의 디스크에 대해서 파일을 기호 연결 하는지, 스트라이핑을 실시해서, 이용 가능한 디스크 스핀들수를 증가한다( 및 거기에 따른 시크의 오버헤드를 경감한다).

    • 기호 연결의 사용

      MyISAM 테이블의 경우, 통상의 데이터 디렉토리내의 위치로부터 다른 디스크에의 인덱스 파일이나 데이터 파일의 기호 연결을 실시한다(스트라이핑도 가능).이것에 의해서, 디스크가 다른 용도에 사용되어 있지 않으면, 시크와 읽어내 시간이 모두 개선된다. See 항5.6.1. 「기호 연결의 사용」 .

    • 스트라이핑

      스트라이핑은, 디스크가 다수 있는 경우에, 제 1 블록을 제 1 디스크에, 제 2 블록은 제 2 디스크에, 제 N 블록은(N mod number_of_disks ) 디스크에라고 하는 배치를 의미한다.이것에 의해, 통상의 데이터 사이즈가 스트라이프 사이즈보다 작은(또는 완전하게 일치하고 있다) 경우에 퍼포먼스가 큰폭으로 개선한다.스트라이핑은 operating system과 스트라이프 사이즈에의 의존성이 매우 높기 때문에, 스트라이프 사이즈를 여러가지로 바꾸면서 어플리케이션의 벤치마크를 실시한다. See 항5.1.5. 「독자적인 벤치마크의 사용」 .

      스트라이핑의 속도는 파라미터에 의해서 크고 다른 것에 주의한다.스트라이핑파라메이타의 설정 방법법과 디스크수에 의해서 자리수 차이의 차이가 발생한다.랜덤 억세스인가 차례차례 액세스의 어느 최적화를 실시할까의 선택이 필요한 일로 주의한다.

  • 신뢰성을 높이기 위해,RAID 0+1 (스트라이핑 + ?~ 라링)의 사용이 필요한 경우,N 개의 드라이브의 데이터의 보관 유지에 2*N 개의 드라이브가 필요하게 된다.재무상의 여유가 있는 경우는 이것이 최적인 선택사항이 된다.그러나, 처리의 효율화에 볼륨 관리 소프트웨어에의 투자가 필요한 일도 있다.

  • 데이터의 종류의 중대성에 따라 RAID 레벨을 바꾸는 선택도 추천 된다.예를 들어, 호스트 정보나 로그등의 중요도의 높은 데이터는,RAID 0+1 또는 RAID N 디스크에 격납해, 재생성이 가능하고 중요성이 중간 정도의 데이터는 RAID 0 디스크에 격납하는 것등을 할 수 있다.RAID N (은)는, 패리티 비트의 갱신에 시간이 걸리기 위해, 기입이 많으면 문제가 되는 경우가 있다.

  • Linux 의 경우,hdparm (을)를 사용해 디스크의 인터페이스를 구성하는 것으로 퍼포먼스를 큰폭으로 개선할 수 있다(부하시에 100% 개선할 수 있는 것도 드물지 않다).다음의 예는,MySQL ( 및 그 외의 다수의 어플리케이션)에 매우 적합했다 hdparm 옵션이다.

    hdparm -m 16 -d 1

    상기를 사용했을 경우의 퍼포먼스와 신뢰성은 사용 하드웨어에 의존하기 위해(때문에),hdparm 의 사용후는 시스템을 종합적으로 테스트하도록(듯이) 강하게 추천 한다.상세한 것에 대하여는,hdparm 의 페이지를 참조.hdparm 의 사용이 적절하지 않은 경우는, 파일 시스템의 손상이 발생하는 일이 있기 위해, 테스트때 네등이나 글자째 모든 백업을 취해 둘 필요가 있다.

  • 데이타베이스가 사용하는 파일 시스템의 파라미터를 설정할 수도 있다.

    • 파일에의 최종 액세스시를 인식할 필요가 없는(데이터 베이스 서버에서는 중요도가 낮다) 경우,-o noatime 옵션을 사용해 파일 시스템을 마운트할 수 있다.이것으로, 파일 시스템의 i 노드에의 최종 액세스 시간의 갱신이 스킵 되어 일부의 디스크 시크를 회피할 수 있다.

    • 다수의 operating system로,-o async 옵션을 사용해 디스크를 마운트해, 파일 시스템이 비동기에 갱신되도록(듯이) 설정할 수 있다.사용하고 있는 컴퓨터가 적당히 안정되어 있는 경우는, 신뢰성을 해치지 않고 한층 더 퍼포먼스를 개선할 수 있다(Linux 그럼 이 플래그가 디폴트로 온이 되어 있다).

5.6.1. 기호 연결의 사용

테이블과 데이타베이스를 데이타베이스 디렉토리로부터 다른 위치로 이동해, 새로운 위치에의 기호 연결에 치환할 수 있습니다. 이것은, 예를 들어, 데이타베이스를 비어 영역이 많은 파일 시스템으로 이동해, 테이블을 다른 디스크에 분산하는 것으로 시스템의 속도를 올리는 경우 등에 실행할 수 있습니다.

이 추천 되는 실행 방법은, 데이타베이스만 다른 디스크에의 기호 연결을 실시해, 마지막 수단으로서만 테이블의 기호 연결을 실시하는 것입니다.

5.6.1.1. Unix 위의 데이타베이스에 대한 기호 연결의 사용

Unix 의 경우, 데이타베이스의 기호 연결은, 우선, 빈영역이 있는 디스크에 디렉토리를 작성해, 다음에 MySQL 데이타베이스 디렉토리로부터 그 디렉토리에의 기호 연결을 작성합니다.

shell> mkdir /dr1/databases/test
shell> ln -s /dr1/databases/test mysqld-datadir

MySQL (은)는,1 개의 디렉토리에 대해서 복수의 데이타베이스를 링크시키는 것을 서포트하고 있지 않습니다.데이타베이스 디렉토리를 기호 연결에 치환하면, 복수의 데이타베이스에 기호 연결을 치지 않는 이상 문제 없게 기능합니다. 만일 MySQL 데이터 디렉토리에 데이타베이스 db1 하지만 있는 경우에,db1 (을)를 가리키는 기호 연결 db2 (을)를 작성한다고 합니다.

shell> cd /path/to/datadir
shell> ln -s db1 db2

이것으로,db1 의 테이블 tbl_a 하지만,db2 의 테이블 tbl_a (이)라고 해도 표시됩니다.어느 스레드로 db1.tbl_a 하지만 갱신되어 다른 스레드로 db2.tbl_a 하지만 갱신되면, 문제가 발생합니다.

이와 같이 하는 것이 실제로 필요한 경우는,mysys/mf_format.c 그리고 다음의 코드를 변경할 필요가 있습니다.

if (flag & 32 || (!lstat(to,&stat_buff) && S_ISLNK(stat_buff.st_mode)))

이것을 다음과 같이 합니다.

if (1)

Windows 그럼,-DUSE_SYMDIR (을)를 사용해 MySQL (을)를 컴파일 하고, 디렉토리에의 내부 기호 연결을 사용할 수 있습니다.이것에 의해서, 복수의 데이타베이스를 복수의 디스크에 배치할 수 있게 됩니다. See 항5.6.1.3. 「Windows 위의 데이타베이스에 대한 기호 연결의 사용」 .

5.6.1.2. Unix 위의 테이블에 대한 기호 연결의 사용

MySQL 4.0 보다 전은, 테이블의 기호 연결의 실행을 매우 신중하게 실시할 필요가 있었습니다.기호 연결을 하고 있는 테이블로,ALTER TABLE ,REPAIR TABLE , 혹은 OPTIMIZE TABLE (을)를 실행할 때에, 기호 연결이 삭제되어 오리지날 파일에 치환된다고 하는 문제가 있었습니다.이러한 스테이트먼트는, 데이타베이스 디렉토리에 임시 파일을 작성해, 스테이트먼트의 조작이 완료하면 오리지날 파일과 임시 파일의 치환을 하는 사양이기 위해, 이 문제가 발생했습니다.

realpath() 의 호출의 기능이 완전하지 않은 시스템에서는 테이블의 기호 연결을 실시하지 말아 주세요(적어도,Linux (와)과 Solaris 그럼 realpath() 하지만 서포트되고 있습니다).

MySQL 4.0 그럼 MyISAM 테이블에서만 기호 연결이 완전 서포트되고 있습니다.이외의 테이블형으로 상기의 커멘드를 사용하면, 예상외의 문제의 발생의 우려가 있습니다.

MySQL 4.0 (으)로의 기호 연결의 처리는, 다음과 같이 기능합니다(대부분이 MyISAM 테이블에만 적합합니다).

  • 데이터 디렉토리에는 항상 테이블 정의 파일, 데이터 파일 및 인덱스 파일이 있다.데이터 파일과 인덱스 파일은, 다른 장소로 이동해, 데이터 디렉토리내에서 기호 연결에 의해서 치환할 수 있다.정의 파일은 이것을 할 수 없다.

  • 데이터 파일과 인덱스 파일은, 각각 독립해 다른 디렉토리에 기호 연결을 작성할 수 있다.

  • 기호 연결은, operating system 레벨(mysqld 하지만 실행되어 있지 않은 경우), 또는 SQL 그리고 CREATE TABLE 에 DATA DIRECTORY 및 INDEX DIRECTORY 옵션을 지정해 실행할 수 있다. See 항6.5.3. 「CREATE TABLE 구문」 .

  • myisamchk (은)는, 데이터 파일이나 인덱스 파일의 기호 연결을 옮겨놓지 않는다. myisamchk (은)는 링크로 지시해지고 있는 파일에 직접 작용한다.임시 파일은 모두 데이터 파일이나 인덱스 파일이 배치되어 있는 것과 같은 디렉토리에 작성된다.

  • 기호 연결을 사용하고 있는 테이블을 드롭 하면, 기호 연결과 기호 연결이 가리키고 있는 파일의 양쪽 모두가 드롭 된다.이 때문에,root (으)로서 mysqld (을)를 실행해서는 안되고, 또,MySQL 데이타베이스 디렉토리에의 써 액세스를 유저에게 허가해야 하는 것도 아니다.

  • ALTER TABLE RENAME (을)를 사용해 테이블의 이름을 변경해, 테이블을 다른 데이타베이스로 이동하지 않는 경우, 데이타베이스 디렉토리의 기호 연결의 이름이 새로운 이름으로 변경되어 데이터 파일과 인덱스 파일도 거기에 따라서 이름이 변경된다.

  • ALTER TABLE RENAME (을)를 사용해 테이블을 다른 데이타베이스로 이동하면, 테이블이 다른 데이타베이스 디렉토리에 이동되어 그것까지 있던 기호 연결과 그것이 가리키는 파일이 삭제된다(신규 테이블의 기호 연결은 작성되지 않는다).

  • 기호 연결을 사용하고 있지 않는 경우는,mysqld 에 --skip-symlink 옵션을 지정해 사용해, 확실히 아무도 데이터 디렉토리의 밖에서 파일의 드롭이나 이름의 변경을 실시한다 mysqld (을)를 사용할 수 없게 한다.

서포트되어 있지 않은 사항

  • ALTER TABLE 그럼 DATA DIRECTORY (와)과 INDEX DIRECTORY 테이블 옵션이 무시된다.

  • MySQL 4.0.15 보다 전은, 테이블에 기호 연결이 있는 경우,SHOW CREATE TABLE 그리고 리포트를 하지 않는다.이것은,SHOW CREATE TABLE (을)를 사용해 CREATE TABLE 스테이트먼트를 생성한다 mysqldump 에 대해서도 같이이다.

  • BACKUP TABLE (와)과 RESTORE TABLE 그럼 기호 연결이 고려되지 않는다.

  • frm 파일은 기호 연결로 하는 것이 전혀 할 수 없다 (전술과 같이, 데이터 파일과 인덱스 파일만 기호 연결로 할 수 있다). 이것을 실행했을 경우(동의어 작성 등), 올바른 결과를 얻을 수 없게 된다. MySQL 데이터 디렉토리에 데이타베이스 db1 하지만 있어, 이 데이타베이스에는 테이블 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 하지만 갱신되면, 문제가 발생한다.쿼리 캐쉬가 속여져서(tbl1 하지만 갱신되어 있지 않다고 판단되어 최신이 아닌 결과가 돌려주어진다),tbl2 에 대한다 ALTER 커멘드도 에러가 된다.

5.6.1.3. Windows 위의 데이타베이스에 대한 기호 연결의 사용

MySQL 버젼 3.23.16 (으)로부터,MySQL 디스트리뷰션의 mysqld-max 및 mysql-max-nt 서버가 -DUSE_SYMDIR 옵션으로 컴파일 되게 되었습니다.이것에 의해, 기호 연결을 설정해 다른 디스크에 데이타베이스 디렉토리를 배치할 수 있습니다. 링크의 설정 순서는 다릅니다만, 기능은 Unix 의 기호 연결과 같습니다.

Windows 그럼, 대상 디렉토리에의 패스가 기재된 파일을 작성해 MySQL 데이타베이스에 대한 기호 연결을 작성합니다.파일명 db_name.sym (을)를 사용해 데이터 디렉토리에 파일을 보존합니다.이 db_name (은)는 데이타베이스명입니다.

예를 들어,MySQL 데이터 디렉토리가 C:\mysql\data 그리고, 데이타베이스 foo (을)를 D:\data\foo 에 배치하는 경우, 패스명 D:\data\foo\ 하지만 기재된 파일 C:\mysql\data\foo.sym (을)를 작성할 필요가 있습니다.이와 같이 하면, 데이타베이스 foo 에 작성 떠날 수 있어 모든 테이블이 D:\data\foo 에 작성됩니다. 이 작업에는 D:\data\foo 디렉토리가 존재하고 있을 필요가 있습니다.또, 데이타베이스명의 디렉토리가 MySQL 데이터 디렉토리에 있으면 기호 연결이 사용되지 않게 되기 위해, 주의가 필요합니다.바꾸어 말하면, 벌써 foo (이)라는 이름의 데이타베이스 디렉토리가 데이터 디렉토리에 있는 경우, 이것을 D:\data (으)로 이동하지 않으면 기호 연결이 유효하게 안 되게 됩니다(문제를 회피하기 위해(때문에), 데이타베이스 디렉토리의 이동시는 서버를 실행하지 말아 주세요).

어느 테이블을 여는 경우에서도 속도가 저하하기 위해, 이것을 서포트하도록(듯이) MySQL (을)를 컴파일 했을 경우에서도, 디폴트에서는 유효화 되고 있지 않습니다.기호 연결을 유효화하려면 ,my.cnf 또는 my.ini 파일을 다음의 엔트리에 입력할 필요가 있습니다.

[mysqld]
symbolic-links

MySQL 4.0 그럼, 기호 연결이 디폴트로 유효화 되고 있습니다.불요의 경우는,skip-symbolic-links 옵션으로 무효화할 수 있습니다.


제6 장 MySQL SQL 언어 레퍼런스

목차

6.1. 언어 구조
6.1.1. 리터럴: 문자열과 수치의 기술 방법
6.1.2. 데이타베이스명, 테이블명, 인덱스명, 컬럼명, 앨리어스(alias)명
6.1.3. 이름에 있어서의 케이스 의존
6.1.4. 유저 변수
6.1.5. 시스템 변수
6.1.6. 코멘트 구문
6.1.7. MySQL (으)로의 예약어(reserved word)의 취급
6.2. 컬럼형
6.2.1. 수치형
6.2.2. 일자와 시각형
6.2.3. 문자열형
6.2.4. 올바른 컬럼형의 선택
6.2.5. 다른 데이타베이스 엔진의 컬럼형의 사용
6.2.6. 각 컬럼형에 필요한 기억용량
6.3. SELECT 마디와 WHERE 마디로 사용하는 함수
6.3.1. 각 데이터형 공통의 연산자와 함수
6.3.2. 문자열 함수
6.3.3. 수치 함수
6.3.4. 일자와 시각 함수
6.3.5. 캐스트 함수
6.3.6. 그 외의 함수
6.3.7. GROUP BY 마디로 사용하는 함수와 수식자
6.4. 데이터의 조작: SELECT ,INSERT ,UPDATE ,DELETE
6.4.1. SELECT 구문
6.4.2. 서브 쿼리 구문
6.4.3. INSERT 구문
6.4.4. UPDATE 구문
6.4.5. DELETE 구문
6.4.6. TRUNCATE 구문
6.4.7. REPLACE 구문
6.4.8. LOAD DATA INFILE 구문
6.4.9. HANDLER 구문
6.4.10. DO 구문
6.5. 데이터 정의: CREATE ,DROP ,ALTER
6.5.1. CREATE DATABASE 구문
6.5.2. DROP DATABASE 구문
6.5.3. CREATE TABLE 구문
6.5.4. ALTER TABLE 구문
6.5.5. RENAME TABLE 구문
6.5.6. DROP TABLE 구문
6.5.7. CREATE INDEX 구문
6.5.8. DROP INDEX 구문
6.6. MySQL 기본 유저 유틸리티 커멘드
6.6.1. USE 구문
6.6.2. DESCRIBE 구문(컬럼에 관한 정보의 취득)
6.7. MySQL 트랜잭션(transaction) 커멘드와 락 커멘드
6.7.1. START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문
6.7.2. 롤백(rollback) 할 수 없는 스테이트먼트
6.7.3. 암묵적인 코?~ 트를 일으키는 스테이트먼트
6.7.4. SAVEPOINT 및 ROLLBACK TO SAVEPOINT 구문
6.7.5. LOCK TABLES 및 UNLOCK TABLES 구문
6.7.6. SET TRANSACTION 구문
6.8. MySQL 풀텍스트 검색
6.8.1. 풀텍스트 검색에 있어서의 제약
6.8.2. MySQL 풀텍스트 검색의 조정
6.8.3. 풀텍스트 검색에 관련한다 TODO 항목
6.9. MySQL 쿼리 캐쉬
6.9.1. 쿼리 캐쉬의 동작
6.9.2. 쿼리 캐쉬의 설정
6.9.3. SELECT (으)로의 쿼리 캐쉬 옵션
6.9.4. 쿼리 캐쉬의 스테이터스와 보수

MySQL (은)는 매우 복잡하면서, 직감적으로 사용할 수 있는 기억 싸다 SQL 인터페이스입니다.이 장에서는,MySQL (을)를 효율적 한편 효과적으로 사용하기 위해서 알아 둘 필요가 있는, 다양한 커멘드, 데이터형, 및 함수에 대해 설명합니다.또, 이 장으로부터,MySQL 에 짜 모든 기능에 대해 참조할 수도 있습니다.다방면에 걸치는 인덱스중에서 각각의 내용을 참조하는 것에 의해서, 이 장을 효과적으로 사용할 수 있습니다.

6.1. 언어 구조

6.1.1. 리터럴: 문자열과 수치의 기술 방법

이 섹션에서는,MySQL 그리고 문자열과 수치를 기술하는 다양한 방법을 설명합니다. 또,MySQL 그리고 이러한 기본 데이터형을 처리할 때에 조우할 것이다, 다양한 뉘앙스와 `` 이해 사항'' 에 대해서도 취급합니다.

6.1.1.1. 문자열

문자열은, 단일 인용부호 (‘' ＇) 또는 이중 인용부호(‘" ＇)(으)로 둘러싸인 문자의 줄(순서)입니다(ANSI 모드로의 실행시는 인용부호만).다음에 예를 나타냅니다.

'a string'
"another string"

일부의 순서는, 개개의 문자열내에서 특별한 의미를 가집니다.이러한 순서는, 모두, 이스케이프 문자 (으)로서 알려진 backslash(‘\ ＇)(으)로 시작됩니다.MySQL 그럼, 다음의 escape sequence가 인식됩니다.

  • \0

    ASCII 0 (NUL ) 문자.

  • \'

    단일 인용부호(‘' ＇).

  • \"

    이중 인용부호(‘" ＇).

  • \b

    백 스페이스 문자.

  • \n

    개행 문자(LF) .

  • \r

    복귀 개행 문자(CR) .

  • \t

    탭 문자.

  • \z

    ASCII(26) (Control-Z ).이 문자를 코드화하는 것에 의해서,ASCII(26) 하지만 Windows 그럼 END-OF-FILE (을)를 나타낸다고 하는 문제를 회피할 수 있다(ASCII(26) 그럼,mysql database < filename (을)를 사용하는 경우에 문제가 발생한다).

  • \\

    backslash(‘\ ＇) 문자.

  • \%

    ‘% ＇ 문자.이것은,‘% ＇ (을)를 그대로 사용했을 때에 와일드 카드 문자로서 해석되어 버리는 문맥으로 ‘% ＇ 자체를 검색하는 경우에 사용한다. See 항6.3.2.1. 「문자열 비교 함수」 .

  • \_

    ‘_ ＇ 문자.이것은,‘_ ＇ (을)를 그대로 사용했을 때에 와일드 카드 문자로서 해석되어 버리는 문맥으로 ‘_ ＇ 자체를 검색하는 경우에 사용한다. See 항6.3.2.1. 「문자열 비교 함수」 .

문자열의 일부의 문맥에서는,'\%' 또는 '\_' (을)를 사용했을 때에,‘% ＇ (와)과 ‘_ ＇ 대신에, 문자열 '\%' (와)과 '\_' 하지만 각각 돌려주어지는 것에 주의해 주세요.

문자열에 인용부호를 포함하는 방법은, 몇개인가 있습니다.

  • ‘' ＇ 그리고 둘러싼 문자열내에서 ‘' ＇ (을)를 사용하는 경우, 문자열내의 ‘' ＇ 하 '''' (와)과 기술할 수 있다.

  • ‘" ＇ 그리고 둘러싼 문자열내에서 ‘" ＇ (을)를 사용하는 경우, 문자열내의 ‘" ＇ 하 '""' (와)과 기술할 수 있다.

  • 인용부호의 직전에 이스케이프 문자(‘\ ＇)(을)를 사용할 수 있다.

  • ‘" ＇ 그리고 둘러싼 문자열내에서 ‘' ＇ (을)를 사용하는 경우는,‘' ＇ (을)를 2 개 계속해 입력하거나 이스케이프 하거나의 특별한 처치를 실시할 필요는 없다.같이‘' ＇ 그리고 둘러싼 문자열내에서 ‘" ＇ (을)를 사용하는 경우도, 특별 취급 할 필요는 없다.

다음의 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> SELECT "This\nIs\nFour\nlines";
+--------------------+
| This
Is
Four
lines |
+--------------------+

문자열의 컬럼(BLOB 등)에 바이너리 데이터를 삽입하는 경우, 다음의 문자는 escape sequence를 사용해 표현할 필요가 있습니다.

  • NUL

    ASCII 0 .이 문자는 '\0' ( backslash + ASCII ‘0 ＇ 문자)로 표현한다.

  • \

    ASCII 92 , backslash.'\\' (으)로서 표현한다.

  • '

    ASCII 39 , 단일 인용부호.'\'' (으)로서 표현한다.

  • "

    ASCII 34 , 이중 인용부호.'\"' (으)로서 표현한다.

C 코드를 쓰는 경우는,INSERT 스테이트먼트의 문자를 이스케이프 하는 목적으로 C API 함수 mysql_real_escape_string() (을)를 사용할 수 있습니다.See 항11.1.2. 「C API 함수의 개요」 .Perl 그럼,DBI 패키지의 quote 메소드를 사용하고, 특수 문자를 적절한 escape sequence로 변환할 수 있습니다.See 항11.5.2. 「DBI 인터페이스」 .

상기의 특수 문자중 한쪽이 포함되어 있을 가능성이 있는 문자열에는, 반드시 이스케이프 함수를 사용하도록(듯이) 합니다.

또는,MySQL API (이)가 많은 물건이 일종의 플레이스홀더 기능을 갖추고 있기 때문에, 이 기능을 사용해 쿼리 문자열에 특수한 마커를 삽입해, 쿼리의 발행시에 데이터치를 그러한 마커에 바인드 할 수도 있습니다.이 경우, 치내의 특수 문자의 이스케이프 처리가 API 에 의해서 자동으로 행해집니다.

6.1.1.2. 수치

정수는 숫자의 열로서 표현됩니다.부동 소수점에서는, 소수를 단락짓기 위해서 ‘. ＇ 하지만 사용됩니다.어느 쪽의 형태의 수치에서도, 선두에 ‘- ＇ (을)를 붙이는 것에 의해서, 음수를 나타낼 수 있습니다.

유효한 정수의 예:

1221
0
-32

유효한 부동 소수점수(실수)의 예:

294.42
-32032.6809e+10
148.00

부동 소수점의 문맥으로 정수를 사용할 수도 있습니다.이 경우, 정수는 동등의 부동 소수점수(실수)로서 해석됩니다.

버젼 4.1.0 이?~ , 정수 TRUE 하 1 (으)로서 평가되어 정수 FALSE 하 0 (으)로서 평가됩니다.

6.1.1.3. 16 진치

MySQL 그럼,16 진치를 서포트하고 있습니다.수치의 문맥에서는,16 진치는 정수(64 비트 정도)와 같이 동작합니다.문자열의 문맥에서는,16 진치는 바이너리 문자열과 같이 동작합니다.이 경우,16 진수의 각 페어가 1 문자에 변환됩니다.

mysql> SELECT x'4D7953514C';
         -> MySQL
mysql> SELECT 0xa+0;
         -> 10
mysql> SELECT 0x5061756c;
         -> Paul

MySQL 4.1 ( 및 --new 옵션을 사용했다 MySQL 4.0 )에서는,16 진치의 디폴트의 데이터형은 문자열입니다.16 진치의 문자열이 확실히 수치로서 다루어지도록(듯이) 하려면 , 그 문자열에 대해서 CAST( ... AS UNSIGNED) (을)를 사용합니다.

x'hexstring' 구문(4.0 의 신기능)은 표준 SQL 에 근거하고 있어0x 구문은 ODBC 에 근거하고 있습니다.16 진문자열은,BLOB 컬럼의 값을 제공하는 목적으로,ODBC 에 의해서 사용되는 일이 자주 있습니다. 문자열 또는 수치를 16 진형식의 문자열로 변환하려면 ,HEX() 함수를 사용할 수 있습니다.

6.1.1.4. NULL 치

NULL 값은 `` 데이터 없음'' (을)를 의미해, 수치형으로의 0 (이)나 문자열형으로의 공문자열등의 값과는 다릅니다. See 항A.5.3. 「NULL 값의 문제」 .

텍스트 파일의 임포트 또는 export 형식(LOAD DATA INFILE ,SELECT ... INTO OUTFILE )의 사용시,NULL 하 \N 그리고 표현할 수 있습니다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

6.1.2. 데이타베이스명, 테이블명, 인덱스명, 컬럼명, 앨리어스(alias)명

MySQL 그럼, 데이타베이스명, 테이블명, 인덱스명, 및 앨리어스(alias)명에는, 모두 같은 규칙이 적용됩니다.

주의: 식별자(데이타베이스명, 테이블명, 컬럼명)를 ‘` ＇ 그리고 인용할 수가 있습니다.MySQL 버젼 3.23.6 이?~ 그럼,ANSI 모드로 실행했을 때는,‘" ＇ 도 식별자의 인용 처리에 사용할 수 있습니다. See 항1.8.2. 「ANSI 모드로의 MySQL 의 실행」 .

식별자 | 최대장(아르바이트) | 사용 가능한 문자
데이타베이스 | 64 | 디렉토리명에 사용 가능한 모든 문자(다만,‘/ ＇,‘\ ＇, 및 ‘. ＇ (을)를 제외한다)
테이블 | 64 | 파일명에 사용 가능한 모든 문자(다만,‘/ ＇ (와)과 ‘. ＇ (을)를 제외한다)
컬럼 | 64 | 모든 문자
앨리어스(alias) | 255 | 모든 문자

상기에 보충하고,ASCII(0) ,ASCII(255) , 및 인용 문자는 모두 식별자내에서는 사용할 수 없는 것에 주의해 주세요.

식별자가 예약어(reserved word)인 경우나, 식별자에 특수 문자가 포함되어 있는 경우는, 인용부호로서 사용한 박크크트( 「` 」) 문자로 그 식별자를 반드시 둘러쌀 필요가 있습니다.

mysql> SELECT * FROM `select` WHERE `select`.id > 100;

See 항6.1.7. 「MySQL (으)로의 예약어(reserved word)의 취급」 .

MAXDB 또는 ANSI_QUOTES 모드로 MySQL (을)를 실행하는 경우는, 식별자를 둘러싸는 인용부호로서 이중 인용부호도 사용할 수 있습니다.

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);
Query OK, 0 rows affected (0.00 sec)

See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

버젼 3.23.6 보다 전의 MySQL 버젼 그럼, 이름에 관해서 다음의 규칙이 적용됩니다.

  • 개개의 이름은, 현재의 캐릭터 세트에 따른 영숫자, 및 ‘_ ＇ (와)과 ‘$ ＇ 그리고 구성할 수 있다.디폴트의 캐릭터 세트는 ISO-8859-1 Latin1 .이 캐릭터 세트는, mysqld 에 --default-character-set 옵션을 지정하는 것으로써 변경 가능. See 항4.7.1. 「데이터 및 소트용 캐릭터 세트」 .

  • 개개의 이름에서는, 이름에 사용 가능한 임의의 문자를, 선두 문자로 할 수 있다.선두를 숫자로 하는 일도 가능(이 점은, 다른 많은 데이타베이스 시스템과 다르다).다만, 숫자 만 (으)로 구성되는 이름은 사용할 수 없다.

  • ‘. ＇ 문자는 이름에는 사용할 수 없다.이 문자는, 컬럼을 참조하기 위한 확장 형식에서 사용된다(이것에 대해서는 후술 한다).

1e (와)과 같은 이름은, 사용하지 말아 주세요.이것은,1e+1 (와)과 같은 식이 애매하게 되기 (위해)때문입니다.1e+1 (은)는, 식 1e + 1 (으)로서 또는 수치 1e+1 (으)로서 해석됩니다.

MySQL 그럼, 다음의 형식의 어느쪽이든을 사용해 컬럼을 참조할 수 있습니다.

컬럼 참조 | 의미
col_name | 이 이름 컬럼이 짜넣어진 쿼리로 사용되고 있는 테이블내의 컬럼 col_name .
tbl_name.col_name | 경향 데이타베이스의 테이블 col_name 안의 컬럼 tbl_name .
db_name.tbl_name.col_name | 데이타베이스 db_name 의 테이블 tbl_name 안의 컬럼 col_name .이 형식은 MySQL Version 3.22 이?~ 그리고 사용 가능.
`column_name` | 그 자체가 키워드인지, 그 중에 특수 문자를 포함하고 있는 컬럼.

대상이 되는 참조가 애매한 경우, 컬럼 참조 전에 tbl_name (이)나 db_name.tbl_name (을)를 붙일 필요가 있습니다. 예를 들어, 테이블 t1 (와)과 t2 의 각각 동명의 컬럼 c 하지만 있어,t1 (와)과 t2 의 양쪽 모두를 사용한다 SELECT 스테이트먼트로 c (을)를 읽어낸다고 합니다.이 경우 c (은)는, 스테이트먼트로 사용되고 있다 2 개의 테이블중에서 일의인 컬럼을 나타내는 것이 아니고, 애매하기 때문에,t1.c 또는 t2.c (와)과 기술하는 것에 의해서, 어느 쪽의 테이블이 대상이나 지정할 필요가 있습니다.같이 데이타베이스 db1 의 테이블 t (와)과 데이타베이스 db2 의 테이블 t 에 포함되어 있는 컬럼을 꺼내는 경우는, 각각의 테이블의 컬럼을 db1.t.col_name ,db2.t.col_name (으)로서 참조합니다.

구문 .tbl_name (은)는 경향 데이타베이스의 테이블 tbl_name (을)를 의미합니다.이 구문은 ODBC (와)과의 호환성을 확보하는 목적으로 허용 되고 있습니다.이것은, 일부의 ODBC 프로그램으로 테이블명의 선두에 ‘. ＇ 문자를 붙일 수 있기 (위해)때문입니다.

6.1.3. 이름에 있어서의 케이스 의존

MySQL 에 두고, 데이타베이스와 테이블은, 디렉토리와 그러한 디렉토리내의 파일에 대응하고 있습니다.그 때문에, 베이스가 되고 있는 operating system로 대문자와 소문자가 구별되는 경우(케이스 의존), 데이타베이스명과 테이블명에서도 대문자와 소문자가 구별됩니다.즉,Windows 그럼 데이타베이스명과 테이블명으로 대문자와 소문자는 구별되지 않고, 대부분의 종류의 Unix 그럼 대문자와 소문자가 구별되게 됩니다.다만, 중요한 예외가 1 개 있습니다.Mac OS X 그리고 디폴트의 HFS+ 파일 시스템을 사용하고 있는 경우입니다. 그러나,Mac OS X 하 UFS 볼륨도 서포트하고 있습니다.UFS 볼륨에서는 Unix 의 경우와 같이 Mac OS X 그렇지만 대문자와 소문자가 구별됩니다. See 항1.8.3. 「SQL-92 표준에 대한다 MySQL 확장 기능」 .

주의: Windows 그럼 데이타베이스명과 테이블명으로 대문자와 소문자는 구별되지 않습니다만(케이스비의존), 같은 쿼리내에서 다른 케이스를 사용해 같은 데이타베이스나 테이블을 참조하지 않게 해 주세요.다음의 쿼리에서는, 같은 테이블이 my_table 및 MY_TABLE (으)로서 참조되고 있습니다.따라서, 이 쿼리는 기능하지 않습니다.

mysql> SELECT * FROM my_table WHERE MY_TABLE.col=1;

컬럼명과 컬럼의 앨리어스(alias)는, 모든 상황에 있어 케이스비의존입니다.

테이블의 앨리어스(alias)는 케이스 의존입니다.다음의 쿼리에서는, 같은 앨리어스(alias)가 a 및 A (으)로서 참조되고 있습니다.따라서, 이 쿼리는 기능하지 않습니다.

mysql> SELECT col_name FROM tbl_name AS a
    ->                 WHERE a.col_name = 1 OR A.col_name = 2;

데이타베이스명이나 테이블명에 대문자와 소문자의 어느 쪽을 사용했는지 기억하기 어려운 경우는, 데이타베이스와 테이블은 반드시 소문자의 이름으로 작성하는 등이 일관한 규칙을 제정하도록(듯이) 합니다.

이 문제에 대처한다 1 개의 방법은,mysqld 의 선두에 -O lower_case_table_names=1 (을)를 붙이는 것입니다.이 옵션의 디폴트는 Windows 그럼 1 그리고,Unix 그럼 0 입니다.

lower_case_table_names 하지만 1 의 경우,MySQL 그럼, 보관 및 룩 업시에 모든 테이블명이 소문자에 변환됩니다(버젼 4.0.2 이?~ , 이 옵션은 데이타베이스명에도 적용됩니다.4.1.1 이?~ , 이 옵션은 테이블 앨리어스(alias)에도 적용됩니다).

이 옵션을 변경하는 경우는, 최초로 원래의 테이블명을 소문자로 변환하고 나서 mysqld (을)를 기동할 필요가 있습니다.

MyISAM 파일을 Windows (으)로부터 Unix 의 디스크로 이동했을 경우,mysql_fix_extensions 툴을 사용하고, 지정한 각 데이타베이스 디렉토리내의 파일 확장자(extension)의 케이스(소문자의 .frm , 대문자의 .MYI 및 .MYD )(을)를 수정할 필요가 있는 경우가 있습니다 mysql_fix_extensions 하 scripts 서브 디렉토리에 있습니다.

6.1.4. 유저 변수

MySQL 그럼,@variablename 구문으로의 접속마다의 유저 변수를 서포트하고 있습니다.변수명은, 현재의 캐릭터 세트내의 영숫자, 및 ‘_ ＇,‘$ ＇,‘. ＇ 그리고 구성할 수 있습니다.디폴트의 캐릭터 세트는 ISO-8859-1 Latin1 입니다.이 캐릭터 세트는,--default-character-set 옵션을 지정했다 mysqld 그리고 변경 가능합니다.See 항4.7.1. 「데이터 및 소트용 캐릭터 세트」 .유저 변수명은, 버젼 5.0 이?~ 의 버젼에서는 케이스비의존으로, 버젼 5.0 보다 전의 버젼에서는 케이스 의존입니다.

변수는 초기화할 필요는 없습니다.변수의 값은 디폴트에서는 NULL (이어)여, 정수, 실수, 또는 문자열치를 격납할 수 있습니다.스레드의 모든 변수는, 그 스레드가 종료하면 자동적으로 해방됩니다.

변수는 SET 구문을 사용해 설정할 수 있습니다.

SET @variable= { integer expression | real expression | string expression }
[,@variable= ...].

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 number LINES 마디 등, 수치가 명시적으로 요구되고 있는 문맥으로의 사용은 포함되지 않습니다.

주의: SELECT 문장에 대해서는, 각각의 식은, 클라이언트에 보내졌을 때에 처음 평가됩니다.따라서,HAVING ,GROUP BY ,ORDER BY 마디에 대하고,SELECT 부로 설정된 변수를 포함한 식을 참조할 수 없습니다.예를 들어, 다음의 문장은, 기대대로 기능하지 않습니다.

mysql> SELECT (@aa:=id) AS a, (@aa+3) AS b FROM table_name HAVING b=5;

그 이유는,@aa 의 값이 현재의 레코드의 값이 아니고, 전에 받은 레코드의 id 값이기 (위해)때문입니다.

원칙으로서 변수에의 값의 대입과 사용의 양쪽 모두 의 처리를, 같은 스테이트먼트에서는 실시하지 말아 주세요.

변수의 설정과 그 사용을 같은 스테이트먼트로 갔을 경우, 변수의 디폴트의 결과형이 그 스테이트먼트의 개시시에 있어서의 그 변수의 데이터형에 근거해 정해져 버린다, 라고 하는 문제도 있습니다(값이 대입되어 있지 않은 변수는 NULL 값을 받아,STRING 형태이라고 상정됩니다).이 예를 다음에 나타냅니다.

mysql> SET @a="test";
mysql> SELECT @a,(@a:=20) FROM table_name;

이 경우,MySQL 그럼, 컬럼 1 하지만 문자열로서 클라이언트에 보고됩니다.그리고,2 번째의 레코드로 @a 하지만 수치로 설정되는 것에도 불구하고,@a 에의 모든 액세스가 문자열에 변환됩니다.스테이트먼트의 실행 후,@a (은)는 수치로 간주해지게 됩니다.

이 경우, 무엇인가 문제가 있는 경우는, 변수의 설정과 그 사용을 같은 스테이트먼트로 실시하지 않게 하는지, 혹은 그 변수를 사용하기 전에 값을 0 ,0.0 , 또는 "" (으)로 설정하도록(듯이) 합니다.

6.1.5. 시스템 변수

MySQL 4.0.3 이?~ 그럼, 많은 시스템 변수나 접속 변수에 액세스하기 쉬워지고 있습니다.그러한 변수의 대부분은, 서버를 정?~ 하는 일 없이 변경할 수 있습니다.

시스템 변수에는, 현재의 접속인 만큼 해당하는 스레드 고유(접속 고유) 변수와 글로벌 이벤트의 설정에 사용되는 글로벌 변수의 2 개의 종류가 있습니다. 글로벌 변수는, 새로운 접속에 대응하는 스레드 고유 변수의 초기치를 설정하기 위해서도 사용됩니다.

mysqld 의 기동시에는, 커멘드 라인 인수와 옵션 파일로부터 모든 글로벌 변수가 초기화됩니다.이 값은 SET GLOBAL 커멘드를 사용해 변경할 수 있습니다.새로운 스레드가 작성되면, 글로벌 변수로부터 스레드 고유 변수가 초기화됩니다.이 값은 새롭다 SET GLOBAL 커멘드를 발행해도 변경되지 않습니다.

GLOBAL 변수의 값을 설정하려면 , 다음의 구문의 어느쪽이든을 사용합니다(여기에서는, 변수의 예로서 sort_buffer_size (을)를 사용합니다).

SET GLOBAL sort_buffer_size=value;
SET @@global.sort_buffer_size=value;

SESSION 변수의 값을 설정하려면 , 다음의 구문의 어느쪽이든을 사용할 수 있습니다.

SET SESSION sort_buffer_size=value;
SET @@session.sort_buffer_size=value;
SET sort_buffer_size=value;

GLOBAL (와)과 SESSION 의 어느쪽이나 지정하지 않으면SESSION 하지만 사용됩니다. See 항5.5.6. 「SET 구문」 .

LOCAL 하 SESSION 의 동의어입니다.

GLOBAL 변수의 값을 꺼내려면 , 다음의 커멘드의 어느쪽이든을 사용할 수 있습니다.

SELECT @@global.sort_buffer_size;
SHOW GLOBAL VARIABLES like 'sort_buffer_size';

SESSION 변수의 값을 꺼내려면 , 다음의 커멘드의 어느쪽이든을 사용할 수 있습니다.

SELECT @@session.sort_buffer_size;
SHOW SESSION VARIABLES like 'sort_buffer_size';

@@variable_name 구문으로 변수를 꺼낸다 때에 GLOBAL (와)과 SESSION 의 어느쪽이나 지정하지 않으면MySQL 그럼, 스레드 고유(SESSION )의 값이 있는 경우는, 그 값이 돌려주어집니다.스레드 고유의 값이 없는 경우는, 글로벌치가 돌려주어집니다.

GLOBAL 의 값 밖에 존재하지 않는 변수의 경우, 꺼내에는 GLOBAL (와)과 지정할 필요는 없습니다만, 설정에는 GLOBAL (와)과 지정할 필요가 있습니다.이것은, 나중에, 동명의 스레드 고유 변수를 도입하거나 삭제하거나 할 경우에 문제가 발생하지 않게 하기 (위해)때문입니다.이 경우, 자신의 접속 뿐만이 아니라, 서버 상태 그 자체를 잘못해 변경해 버릴 가능성이 있습니다.

다음의 일람에, 변경 및 꺼내 대상이 되는 모든 변수와 그러한 변수로 GLOBAL (와)과 SESSION 의 어느 쪽을 사용할 수 있는지를 나타냅니다.

변수명 | 값의 데이터형 | 타입
autocommit | bool | SESSION
big_tables | bool | SESSION
binlog_cache_size | num | GLOBAL
bulk_insert_buffer_size | num | GLOBAL | SESSION
concurrent_insert | bool | GLOBAL
connect_timeout | num | GLOBAL
convert_character_set | string | SESSION
delay_key_write | OFF | ON | ALL | GLOBAL
delayed_insert_limit | num | GLOBAL
delayed_insert_timeout | num | GLOBAL
delayed_queue_size | num | GLOBAL
error_count | num | SESSION
flush | bool | GLOBAL
flush_time | num | GLOBAL
foreign_key_checks | bool | SESSION
identity | num | SESSION
insert_id | bool | SESSION
interactive_timeout | num | GLOBAL | SESSION
join_buffer_size | num | GLOBAL | SESSION
key_buffer_size | num | GLOBAL
last_insert_id | bool | SESSION
local_infile | bool | GLOBAL
log_warnings | bool | GLOBAL
long_query_time | num | GLOBAL | SESSION
low_priority_updates | bool | GLOBAL | SESSION
max_allowed_packet | num | GLOBAL | SESSION
max_binlog_cache_size | num | GLOBAL
max_binlog_size | num | GLOBAL
max_connect_errors | num | GLOBAL
max_connections | num | GLOBAL
max_error_count | num | GLOBAL | SESSION
max_delayed_threads | num | GLOBAL
max_heap_table_size | num | GLOBAL | SESSION
max_join_size | num | GLOBAL | SESSION
max_relay_log_size | num | GLOBAL
max_sort_length | num | GLOBAL | SESSION
max_tmp_tables | num | GLOBAL
max_user_connections | num | GLOBAL
max_write_lock_count | num | GLOBAL
myisam_max_extra_sort_file_size | num | GLOBAL | SESSION
myisam_repair_threads | num | GLOBAL | SESSION
myisam_max_sort_file_size | num | GLOBAL | SESSION
myisam_sort_buffer_size | num | GLOBAL | SESSION
net_buffer_length | num | GLOBAL | SESSION
net_read_timeout | num | GLOBAL | SESSION
net_retry_count | num | GLOBAL | SESSION
net_write_timeout | num | GLOBAL | SESSION
query_cache_limit | num | GLOBAL
query_cache_size | num | GLOBAL
query_cache_type | enum | GLOBAL
read_buffer_size | num | GLOBAL | SESSION
read_rnd_buffer_size | num | GLOBAL | SESSION
rpl_recovery_rank | num | GLOBAL
safe_show_database | bool | GLOBAL
server_id | num | GLOBAL
slave_compressed_protocol | bool | GLOBAL
slave_net_timeout | num | GLOBAL
slow_launch_time | num | GLOBAL
sort_buffer_size | num | GLOBAL | SESSION
sql_auto_is_null | bool | SESSION
sql_big_selects | bool | SESSION
sql_big_tables | bool | SESSION
sql_buffer_result | bool | SESSION
sql_log_binlog | bool | SESSION
sql_log_off | bool | SESSION
sql_log_update | bool | SESSION
sql_low_priority_updates | bool | GLOBAL | SESSION
sql_max_join_size | num | GLOBAL | SESSION
sql_quote_show_create | bool | SESSION
sql_safe_updates | bool | SESSION
sql_select_limit | bool | SESSION
sql_slave_skip_counter | num | GLOBAL
sql_warnings | bool | SESSION
table_cache | num | GLOBAL
table_type | enum | GLOBAL | SESSION
thread_cache_size | num | GLOBAL
timestamp | bool | SESSION
tmp_table_size | enum | GLOBAL | SESSION
tx_isolation | enum | GLOBAL | SESSION
wait_timeout | num | GLOBAL | SESSION
warning_count | num | SESSION
unique_checks | bool | SESSION

값의 데이터형이 num 되고 있는 변수에는, 수치를 설정할 수 있습니다. bool 되고 있는 변수에는,0 ,1 ,ON , 또는 OFF (을)를 설정할 수 있습니다. enum 형태의 변수에는, 통상, 그 변수에 대해서 이용 가능한 값의 1 개를 설정할 수 있습니다만, 해당의 enum (열거) 값에 대응하는 수치를 설정할 수도 있습니다(최초의 열거치는 0 입니다).

이러한 변수의 몇개인가에 대해 설명합니다.

변수 | 설명
identity | last_insert_id 의 앨리어스(alias)(Sybase (와)과의 호환성을 확보하기 위해(때문에))
sql_low_priority_updates | low_priority_updates 의 앨리어스(alias)
sql_max_join_size | max_join_size 의 앨리어스(alias)
version | VERSION() 의 앨리어스(alias)(Sybase (? )(와)과의 호환성을 확보하기 위해(때문에))

그 외의 변수에 대해서는, 스타트 업 옵션,SHOW VARIABLES , 및 SET 에 관한 섹션으로 설명하고 있습니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 . See 항4.6.8.4. 「SHOW VARIABLES 」 . See 항5.5.6. 「SET 구문」 .

6.1.6. 코멘트 구문

MySQL 서버에서는, 코멘트 스타일로서# (줄 끝까지) ,-- (줄 끝까지) , 및 /* (행중 또는 복수행)*/ (을)를 서포트하고 있습니다.

mysql> SELECT 1+1;     #
이 코멘트는 줄 끝까지 계속 된다
mysql> SELECT 1+1;     --
이 코멘트는 줄 끝까지 계속 된다
mysql> SELECT 1 /*
이것은 행중 코멘트 */ + 1;
mysql> SELECT 1+
/*

이것은

복수행 코멘트
*/
1;

-- (데쉬2 개)의 코멘트 스타일에서는,2 번째의 데쉬의 뒤에 스페이스를 1 개이상 삽입할 필요가 있는 것에 주의해 주세요.

서버는 상기의 코멘트 구문을 이해합니다만,mysql 클라이언트로의 /* ... */ 코멘트의 해석에는 일정한 제약이 있습니다.

  • 단일 인용부호와 이중 인용부호는, 코멘트내에서 만나도, 인용 문자열의 개시를 나타내는 것으로서 해석된다.그 코멘트내에, 최초의 인용부호와 일치하는 이제(벌써) 1 개의 인용부호가 없는 경우, 파서는 그 코멘트의 종료를 인식하지 않는다.mysql (을)를 대화적으로 실행하고 있는 경우는, prompt가 mysql> (으)로부터 '> 또는 "> (으)로 바뀌기 위해, 파서가 코멘트의 종료를 인식 못하고 있는 것을 알 수 있다.

  • 세?~ 코론은, 현재의 SQL 스테이트먼트의 종료를 나타내는 것으로서 해석되어 세?~ 코론의 뒤는, 다음의 스테이트먼트의 개시를 나타내는 것으로서 해석된다.

이러한 제약은,mysql (을)를 대화적으로 실행하는 경우와mysql < some-file (을)를 사용하고, 커멘드를 격납한 파일로부터 입력을 읽어내는 듯 mysql 에 지시하는 경우의 양쪽 모두에 적용됩니다.

2 번째의 데쉬의 뒤에 스페이스가 1 개도 없는 경우,SQL-99 의 코멘트 스타일 '--' 하 MySQL 그리고 유효로 여겨지지 않습니다. See 항1.8.4.7. 「코멘트의 개시 기호로서의 '--' 」 .

6.1.7. MySQL (으)로의 예약어(reserved word)의 취급

일반적인 문제의 1 개로서TIMESTAMP (이)나 GROUP 등,MySQL 에 짜넣어지고 있는 데이터형이나 함수의 이름을 사용하는 컬럼명을 포함한 테이블의 작성에 관련하는 문제가 있습니다.이러한 컬럼명을 포함한 테이블의 작성은 가능합니다(예를 들어,ABS (은)는 컬럼명으로서 사용 가능합니다).그러나, 디폴트에서는, 함수의 호출시에, 함수명으로 거기에 계속 된다 ‘( ＇ 문자와의 사이에 공백을 삽입할 수 없습니다.이것은, 함수 호출을 컬럼명의 참조와 구별하기 (위해)때문입니다.

--ansi 또는 --sql-mode=IGNORE_SPACE 옵션을 지정해 서버를 기동했을 경우는, 함수 호출로, 함수명으로 거기에 계속 된다 ‘( ＇ 문자와의 사이에 공백을 삽입할 수 있습니다.이러한 옵션을 지정하면, 함수명이 예약어(reserved word)로서 다루어지게 됩니다.그 때문에, 함수명과 동일한 컬럼명은, 항6.1.2. 「데이타베이스명, 테이블명, 인덱스명, 컬럼명, 앨리어스(alias)명」 그리고 설명하고 있도록(듯이) 인용부호로 둘러쌀 필요가 있습니다.

이하의 말은 MySQL 에 두어 명시적으로 예약되고 있습니다.이러한 말의 대부분(예를 들어,GROUP )(은)는,SQL-92 그럼, 컬럼명 또는 테이블명으로서의 사용을 금?~ 되고 있습니다. 몇개의 말은,MySQL 그리고 그러한 말을 필요로 해, (현재)MySQL 그리고 yacc 파서가 사용되고 있는 것부터 예약되고 있습니다.

ADD | ALL | ALTER
ANALYZE | AND | AS
ASC | BEFORE | BETWEEN
BIGINT | BINARY | BLOB
BOTH | BY | CASCADE
CASE | CHANGE | CHAR
CHARACTER | CHECK | COLLATE
COLUMN | COLUMNS | CONSTRAINT
CONVERT | CREATE | CROSS
CURRENT_DATE | CURRENT_TIME | CURRENT_TIMESTAMP
CURRENT_USER | DATABASE | DATABASES
DAY_HOUR | DAY_MICROSECOND | DAY_MINUTE
DAY_SECOND | DEC | DECIMAL
DEFAULT | DELAYED | DELETE
DESC | DESCRIBE | DISTINCT
DISTINCTROW | DIV | DOUBLE
DROP | DUAL | ELSE
ENCLOSED | ESCAPED | EXISTS
EXPLAIN | FALSE | FIELDS
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
INSERT | INT | INT1
INT2 | INT3 | INT4
INT8 | INTEGER | INTERVAL
INTO | IS | JOIN
KEY | KEYS | KILL
LEADING | LEFT | LIKE
LIMIT | LINES | LOAD
LOCALTIME | LOCALTIMESTAMP | LOCK
LONG | LONGBLOB | LONGTEXT
LOW_PRIORITY | MATCH | MEDIUMBLOB
MEDIUMINT | MEDIUMTEXT | MIDDLEINT
MINUTE_MICROSECOND | MINUTE_SECOND | MOD
NATURAL | NOT | NO_WRITE_TO_BINLOG
NULL | NUMERIC | ON
OPTIMIZE | OPTION | OPTIONALLY
OR | ORDER | OUTER
OUTFILE | PRECISION | PRIMARY
PRIVILEGES | PROCEDURE | PURGE
RAID0 | READ | REAL
REFERENCES | REGEXP | RENAME
REPLACE | REQUIRE | RESTRICT
REVOKE | RIGHT | RLIKE
SECOND_MICROSECOND | SELECT | SEPARATOR
SET | SHOW | SMALLINT
SONAME | SPATIAL | SQL_BIG_RESULT
SQL_CALC_FOUND_ROWS | SQL_SMALL_RESULT | SSL
STARTING | STRAIGHT_JOIN | TABLE
TABLES | TERMINATED | THEN
TINYBLOB | TINYINT | TINYTEXT
TO | TRAILING | TRUE
UNION | UNIQUE | UNLOCK
UNSIGNED | UPDATE | USAGE
USE | USING | UTC_DATE
UTC_TIME | UTC_TIMESTAMP | VALUES
VARBINARY | VARCHAR | VARCHARACTER
VARYING | WHEN | WHERE
WITH | WRITE | X509
XOR | YEAR_MONTH | ZEROFILL

이하의 심볼(위의 겉(표)에 포함되는 것) 하 SQL-99 그럼 사용을 금?~ 되고 있습니다만,MySQL 그럼 컬럼명 또는 테이블명으로서 사용 가능합니다.이것은, 그러한 이름이 극히 일반적인 것이며, 많은 사람들에게 벌써 사용되고 있기 (위해)때문입니다.

  • ACTION

  • BIT

  • DATE

  • ENUM

  • NO

  • TEXT

  • TIME

  • TIMESTAMP


6.2. 컬럼형

MySQL 그럼, 복수의 컬럼형을 서포트하고 있습니다.이러한 컬럼형은, 수치형, 일자와 시각형, 문자열(문자) 형의 3 개의 카테고리로 분류할 수 있습니다.이 섹션에서는, 우선, 사용할 수 있는 컬럼형의 개요를 나타내, 각 컬럼형으로 필요한 기억용량에 대해 간단하게 설명합니다.그 후, 각 카테고리의 컬럼형의 특성을 자세하게 설명합니다. 개요는 굳이 간단하게 정리해 있습니다.값의 유효한 지정 형식 등, 개개의 컬럼형의 추가 정보에 대해서는, 각각의 상세한 설명을 참조해 주세요.

이하에,MySQL 그리고 서포트하고 있는 컬럼형을 나타냅니다. 설명내에서는, 다음의 코드 문자를 사용합니다.

  • M

    최대 표시 사이즈를 나타낸다.정식적 최대 표시 사이즈는 255 .

  • D

    소수점형에 적용되어 소수점 이하의 자리수를 나타낸다.최대치는 30 하지만,M-2 보다 크게 하지 않게 한다.

모퉁이나 개(‘[ ＇ (와)과 ‘] ＇)(은)는, 옵션의 형태 지정자의 일부인 것을 나타냅니다.

컬럼에 대해서 ZEROFILL (을)를 지정하면, 그 컬럼에 UNSIGNED 속성이 자동으로 추가되는 것에 주의해 주세요.

경고: 정수치의 감산으로, 어느 쪽인지 한편의 정수치가 UNSIGNED 형태의 경우, 결과의 값은 부호없이 됩니다. See 항6.3.5. 「캐스트 함수」 .

  • TINYINT[(M)] [UNSIGNED] [ZEROFILL]

    매우 작은 정수.부호 첨부의 범위는 -128 ~ 127 .부호 없음의 범위는 0 ~ 255 .

  • BIT , BOOL , BOOLEAN

    모두 TINYINT(1) 의 동의어. 동의어 BOOLEAN (은)는 버젼 4.1.0 그리고 추가되었다.

    불형의 완전한 처리는 SQL-99 에 근거해 도입된다.

  • 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 형태의 컬럼에 관해서는, 다음의 점에 대해 주의하는 것.

    • 모든 산술 연산은 부호 첨부 BIGINT 또는 DOUBLE 형태의 값을 사용해 행해진다.그 때문에,9223372036854775807 (63 비트)를 넘는, 부호 없음의 큰 정수는, 비트 함수 이외에서는 사용하지 않게 한다.비트 함수 이외로 이러한 큰 정수를 사용하면,BIGINT (으)로부터 DOUBLE 에의 변환시에 발생하는 둥근 오차의 영향으로, 결과의 마지막 자리수의 일부에 잘못이 나오는 경우가 있다.

      다음의 경우,SQL 4.0 그럼 BIGINT (을)를 처리할 수 있다.

      • 정수를 사용하고, 부호 없음의 큰 값을 BIGINT 컬럼에 격납하는 경우

      • MIN(big_int_column) 및 MAX(big_int_column) 에 두어

      • 연산자(+ ,- ,* 등)의 사용시에 양쪽 모두의 오퍼랜드가 정수의 경우

    • 문자열로서 격납하면, 정확한 정수치를 BIGINT 컬럼에 항상 격납할 수 있다.이 경우, 배정도 표현을 개재하지 않는, 문자열로부터 수치에의 변환이 실행된다.

    • ‘- ＇,‘+ ＇, 및 ‘* ＇ 그리고 양쪽 모두의 인수가 정수치 때는,BIGINT 연산이 사용된다.따라서,2 개의 큰 정수(또는 정수를 돌려주는 함수의 결과)를 곱셈 하는 경우, 결과가 9223372036854775807 보다 크면 예기치 않은 결과가 돌려주어지는 경우가 있다.

  • FLOAT(precision) [UNSIGNED] [ZEROFILL]

    부동 소수점수(실수).precision (은)는, 단정도 부동 소수점수(실수)의 경우는 <=24 그리고, 배정도 부동 소수점수(실수)의 경우는 25 ~ 53 의 사이.이러한 형태는 이 바로 후에 설명한다 FLOAT 형태와 DOUBLE 형태에 유사하고 있다. FLOAT(X) (은)는 대응한다 FLOAT 형태 및 DOUBLE 형태와 범위는 같지만, 표시 사이즈와 소수부 자리수는 정의되지 않는다.

    MySQL 버젼 3.23 그럼, 이것은 진정한 부동 소수점치.그 이전의 MySQL 버젼에서는,FLOAT(precision) 의 소수부는 항상 2 자리수가 된다.

    MySQL 의 계산은 모두 배정도로 행해지기 위해,FLOAT 의 사용시에는 예기치 않은 문제가 발생하는 경우가 있는 것에 주의한다. See 항A.5.6. 「부정합레코드의 문제 해결」 .

    이 구문은 ODBC (와)과의 호환성을 확보하기 위해서 제공되고 있다.

  • FLOAT[(M,D)] [UNSIGNED] [ZEROFILL]

    단정도 부동 소수점수(실수).사용 가능한 값은 -3.402823466E+38 ~ -1.175494351E-38 ,0 , 및 1.175494351E-38 ~ 3.402823466E+38 .UNSIGNED (을)를 지정했을 경우, 음수는 사용할 수 없다.M (은)는 표시폭으로,D (은)는 소수부 자리수.인수가 없다 FLOAT (이)나,X 하지만 24 이하의 FLOAT(X) (은)는, 단정도 부동 소수점수(실수)를 나타낸다.

  • DOUBLE[(M,D)] [UNSIGNED] [ZEROFILL]

    배정도 부동 소수점수(실수). 사용 가능한 값은 -1.7976931348623157E+308 ~ -2.2250738585072014E-308 ,0 , 및 2.2250738585072014E-308 ~ 1.7976931348623157E+308 .UNSIGNED (을)를 지정했을 경우, 음수는 사용할 수 없다.M (은)는 표시폭으로,D (은)는 소수부 자리수.인수가 없다 DOUBLE (이)나,X 하지만 25 이상 53 이하이다 FLOAT(X) (은)는, 배정도 부동 소수점수(실수)를 나타낸다.

  • DOUBLE PRECISION[(M,D)] [UNSIGNED] [ZEROFILL] , REAL[(M,D)] [UNSIGNED] [ZEROFILL]

    모두 DOUBLE 의 동의어.

  • DECIMAL[(M[,D])] [UNSIGNED] [ZEROFILL]

    unpack 부동 소수점수(실수).CHAR 컬럼과 같이 동작한다.`` unpack'' (이)란, 그 수치가, 각 형에 1 문자씩 사용해 문자열로서 격납되는 것을 의미한다.M 그럼, 소수점과 음수에 사용된다 ‘- ＇ 기호는 카운트 되지 않는다(그러나, 이러한 유익의 스페이스는 확보된다).D 하지만 0 의 경우, 값은 소수점도 소수부도 가지지 않는다.DECIMAL 값의 최대 범위는,DOUBLE (와)과 같지만, 개개의 DECIMAL 컬럼의 실제의 범위는,M (와)과 D 의 값에 의해서 제한된다.UNSIGNED (을)를 지정했을 경우, 음수는 사용할 수 없다.

    D (을)를 생략 했을 경우, 디폴트는 0 .M (을)를 생략 했을 경우, 디폴트는 10 .

    MySQL 버젼 3.23 보다 전의 버젼에서는,M 인수에, 부호와 소수점에 필요한 스페이스를 포함할 필요가 있다.

  • DEC[(M[,D])] [UNSIGNED] [ZEROFILL] , NUMERIC[(M[,D])] [UNSIGNED] [ZEROFILL] , FIXED[(M[,D])] [UNSIGNED] [ZEROFILL]

    모두 DECIMAL 의 동의어.

    FIXED 앨리어스(alias)는, 다른 서버와의 호환성을 확보하는 목적으로, 버젼 4.1.0 그리고 추가되었다.

  • DATE

    일자.서포트하고 있는 범위는,'1000-01-01' ~ '9999-12-31' .MySQL 그럼,DATE 값은 'YYYY-MM-DD' 형식에서 표시되지만,DATE 컬럼에게의 값의 할당에는 문자열 또는 수치의 어느쪽이든을 사용할 수 있다. See 항6.2.2.2. 「DATETIME ,DATE ,TIMESTAMP 형태」 .

  • DATETIME

    일자와 시각의 편성.서포트하고 있는 범위는,'1000-01-01 00:00:00' ~ '9999-12-31 23:59:59' .MySQL 그럼,DATETIME 값은 'YYYY-MM-DD HH:MM:SS' 형식에서 표시되지만,DATETIME 컬럼에게의 값의 할당에는 문자열 또는 수치의 어느쪽이든을 사용할 수 있다.

    See 항6.2.2.2. 「DATETIME ,DATE ,TIMESTAMP 형태」 .

  • TIMESTAMP[(M)]

    타임 스탬프.범위는 '1970-01-01 00:00:00' ~ 2037 해의 일정한 시점.

    MySQL 4.0 이전의 버젼에서는,TIMESTAMP 값은,M 하지만 14 (또는 지정 없음),12 ,8 , 또는 6 의 어떤 것일까에 따르고,YYYYMMDDHHMMSS ,YYMMDDHHMMSS ,YYYYMMDD , 또는 YYMMDD 형식에서 표시되지만,TIMESTAMP 컬럼에게의 값의 할당에는 문자열 또는 수치의 어느쪽이든을 사용할 수 있다.

    MySQL 4.1 이?~ 그럼,TIMESTAMP 하 'YYYY-MM-DD HH:MM:SS' 형식의 문자열로서 돌려주어진다.수치로서 돌려주어지도록(듯이) 하려면 , 타임 스탬프 컬럼에 +0 (을)를 추가한다.다른 타임 스탬프장은 서포트하고 있지 않다.버젼 4.0.12 이?~ ,--new 옵션을 사용하는 것으로, 버젼 4.1 (와)과 같이 서버를 동작시킬 수 있다.

    TIMESTAMP 컬럼에 값을 지정하지 않으면 마지막에 행해진 조작의 일자와 시각이 자동적으로 설정되기 위해, 이 컬럼은 INSERT 조작이나 UPDATE 조작의 일자와 시각을 기록하는데 도움이 된다.또, 이 컬럼에 NULL 값을 할당하는 것에 의해서, 현재의 일자와 시각을 컬럼으로 설정할 수 있다. See 항6.2.2. 「일자와 시각형」 .

    M 인수는,TIMESTAMP 컬럼의 표시 방법에게만 작용한다. 이 값은 항상 4 아르바이트로 격납된다.

    M 하지만 8 또는 14 의 TIMESTAMP(M) 컬럼은 수치로서 보고되어 그 외의 TIMESTAMP(M) 컬럼은 문자열로서 보고되는 것에 주의한다.이것은 단지, 이러한 데이터형의 테이블의 덤프와 restore를 확실히 실행할 수 있도록 하는 것을 목적으로 하고 있다. See 항6.2.2.2. 「DATETIME ,DATE ,TIMESTAMP 형태」 .

  • TIME

    시각.범위는 '-838:59:59' ~ '838:59:59' . MySQL 그럼,TIME 값은 'HH:MM:SS' 형식에서 표시되지만,TIME 컬럼에게의 값의 할당에는 문자열 또는 수치의 어느쪽이든을 사용할 수 있다. See 항6.2.2.3. 「TIME 형태」 .

  • YEAR[(2|4)]

    2 자리수 또는 4 자리수의 형식의 해(디폴트는 4 자리수).사용 가능한 값은,4 자리수 형식에서는 1901 ~ 2155 (와)과 0000 ,2 자리수 형식에서는 1970 ~ 2069 (70 ~ 69 ).MySQL 그럼,YEAR 값은 YYYY 형식에서 표시되지만,YEAR 컬럼에게의 값의 할당에는 문자열 또는 수치의 어느쪽이든을 사용할 수 있다(YEAR 형태는 MySQL 버젼 3.22 보다 전의 버젼에서는 사용할 수 없다). See 항6.2.2.4. 「YEAR 형태」 .

  • [NATIONAL] CHAR(M) [BINARY | ASCII | UNICODE]

    고정장의 문자열.격납시에는, 지정의 길이가 되도록, 우측으로 스페이스가 파묻힌다.M 의 범위는 0 ~ 255 문자(3.23 보다 전의 MySQL 버젼에서는 1 ~ 255 ). 값의 꺼내 때에는, 후속의 스페이스가 삭제된다.BINARY 키워드를 지정하지 않는 경우,CHAR 형태의 값의 소트와 비교는, 디폴트의 캐릭터 세트에 근거해 케이스비의존 방식으로 행해진다.

    버젼 4.1.0 이?~ 그럼,255 보다 크다 M 값을 지정하면, 컬럼형이 TEXT 형태에 변환된다.

    이것은 호환성을 고려한 기능.

    NATIONAL CHAR (또는, 이것에 대응하는 단축 형식 NCHAR )(은)는,SQL-99 에 있어서의,CHAR 컬럼으로 디폴트의 CHARACTER 세트를 사용하는 것을 정의하는 방법.MySQL 그럼, 이것은 디폴트.

    CHAR 하 CHARACTER 의 생략형.

    버젼 4.1.0 이?~ 그럼,latin1 캐릭터 세트를 CHAR 컬럼에 할당한다 ASCII 속성을 지정할 수 있다.

    버젼 4.1.1 이?~ 그럼,ucs2 캐릭터 세트를 CHAR 컬럼에 할당한다 UNICODE 속성을 지정할 수 있다.

    MySQL 그럼,CHAR(0) 형태의 컬럼을 작성할 수 있다.이것은, 주로, 컬럼 자체는 필요로 하지만, 그 컬럼의 값을 실제로 사용할 것은 없는, 이라고 하는 낡은 어플리케이션에 대응할 필요가 있을 때 도움이 된다.또,2 개의 값 밖에 받지 않는 컬럼이 필요한 경우에도 매우 도움이 된다. CHAR(0) 하 NOT NULL (으)로서는 정의되지 않고,1 비트만 차지해NULL 또는 "" 의 2 개의 값 밖에 받지 않는다. See 항6.2.3.1. 「CHAR 형태와 VARCHAR 형태」 .

  • CHAR

    CHAR(1) 의 동의어.

  • [NATIONAL] VARCHAR(M) [BINARY]

    가변장 문자열. 주의: 후속의 스페이스는 값의 격납시에 삭제된다(이것은 SQL-99 의 사양과는 다르다).M 의 범위는 0 ~ 255 문자(MySQL 버젼 4.0.2 그럼 1 ~ 255 ). BINARY 키워드를 지정하지 않으면VARCHAR 값의 소트와 비교는, 케이스비의존 방식으로 행해진다. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 .

    버젼 4.1.0 이?~ 그럼,255 보다 크다 M 값을 지정하면, 컬럼형이 TEXT 형태에 변환된다. 이것은 호환성을 고려한 기능.

    VARCHAR 하 CHARACTER VARYING 의 생략형.

    See 항6.2.3.1. 「CHAR 형태와 VARCHAR 형태」 .

  • TINYBLOB , TINYTEXT

    최대장이 255 (2^8 - 1 ) 문자의 BLOB 형태 또는 TEXT 형태의 컬럼. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 . See 항6.2.3.2. 「BLOB 형태와 TEXT 형태」 .

  • BLOB , TEXT

    최대장이 65535 (2^16 - 1 ) 문자의 BLOB 형태 또는 TEXT 형태의 컬럼. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 . See 항6.2.3.2. 「BLOB 형태와 TEXT 형태」 .

  • MEDIUMBLOB , MEDIUMTEXT

    최대장이 16777215 (2^24 - 1 ) 문자의 BLOB 형태 또는 TEXT 형태의 컬럼. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 . See 항6.2.3.2. 「BLOB 형태와 TEXT 형태」 .

  • LONGBLOB , LONGTEXT

    최대장이 4294967295 또는 4G (2^32 - 1 ) 아르바이트의 BLOB 형태 또는 TEXT 형태의 컬럼. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 . MySQL 버젼 3.23 까지, 서버/ 클라이언트 프로토콜 및 MyISAM 테이블에서는, 통신 패킷 또는 테이블 레코드 마다 16M 의 제약이 있었다.버젼 4.x 이?~ ,LONGTEXT 형태 또는 LONGBLOB 형태의 컬럼으로 허용 되는 최대장은, 클라이언트/ 서버 프로토콜간의 통신 버퍼 및 사용 가능한 메모리량에 따라서 조정된 최대 패킷 사이즈에 의해서 정해진다. See 항6.2.3.2. 「BLOB 형태와 TEXT 형태」 .

  • ENUM('value1','value2',...)

    열거.값의 리스트 'value1' ,'value2' ,... ,NULL 또는 특수한 "" 에러치로부터 선택된,1 개의 값만 가질 수 있는 문자열 오브젝트.ENUM 에는 최대 65535 의 중복이 없는 값을 짜넣을 수 있다. See 항6.2.3.3. 「ENUM 형태」 .

  • SET('value1','value2',...)

    세트.0 개이상의 값을 가질 수 있는 문자열 오브젝트.이러한 값은 모두 값의 리스트 'value1', 'value2', ... (으)로부터 선택할 필요가 있다.1 개의 SET 에는, 최대 64 개의 요소를 짜넣을 수 있다. See 항6.2.3.4. 「SET 형태」 .

6.2.1. 수치형

MySQL 그럼,SQL-92 의 모든 수치 데이터형을 서포트하고 있습니다.이러한 데이터형은, 정확한 수치 데이터형(NUMERIC ,DECIMAL ,INTEGER ,SMALLINT ) 뿐만이 아니고, 근사 수치 데이터형(FLOAT ,REAL ,DOUBLE PRECISION )(을)를 포함합니다.키워드 INT 하 INTEGER 의 동의어로, 키워드 DEC 하 DECIMAL 의 동의어입니다.

MySQL 그럼,NUMERIC 형태와 DECIMAL 형태는,SQL-92 표준으로 사용 가능한 데이터형과 같은 데이터형으로서 실장됩니다.이러한 데이터형은, 금액 데이터에 관한 값 등, 정확한 정도로 보존하는 것이 중요해지는 값에 대해서 사용됩니다.이러한 몇개의 형태의 컬럼을 선언할 때 , 다음과 같이, 정도와 스케일을 지정할 수 있습니다(통상, 이것들이 지정됩니다).

    salary DECIMAL(5,2)

이 예로,5 (precision) (은)는, 값에 대해서 격납된다 10 진수의 자리수를 나타내,2 (scale) (은)는, 소수점에 이어 격납되는 자리수를 나타냅니다.따라서, 이 경우,salary 컬럼에 격납할 수 있는 값의 범위는,-99.99 ~ 99.99 (이)가 됩니다(MySQL 그럼, 정수의 부호를 격납할 필요가 없기 때문에, 이 컬럼에게는, 실제로는,999.99 까지의 수치를 격납할 수 있습니다).

SQL-92 그럼, 구문 DECIMAL(p) 하 DECIMAL(p,0) (와)과 같습니다.같이 구문 DECIMAL 하 DECIMAL(p,0) (와)과 같습니다.이 경우,p 의 값을 결정하는 실장을 실시할 수 있습니다.MySQL 그럼, 현재로서는,DECIMAL 및 NUMERIC 데이터형의 이러한 이형을 서포트하고 있지 않습니다.통상, 이러한 형태의 주된 이점은 정도와 스케일을 명시적으로 제어할 수 있는 것에 의하기 위해, 이것은 그만큼 문제로는 되지 않습니다.

DECIMAL 값과 NUMERIC 값은, 값의 소수부의 정도를 유지하기 위해(때문에), 바이너리의 부동 소수점수(실수)로서가 아니고, 문자열로서 격납됩니다.값의 각 형, 소수점(scale > 0 의 경우), 그리고 ‘- ＇ 부호(음수의 경우)에 대해서,1 문자가 사용됩니다.scale 하지만 0 의 경우,DECIMAL 값과 NUMERIC 값에는 소수점도 소수부도 포함되지 않습니다.

DECIMAL 값과 NUMERIC 값의 최대 범위는 DOUBLE 값과 같습니다만, 개개의 DECIMAL 또는 NUMERIC 컬럼의 실제의 범위는, 개개의 컬럼의 precision 또는 scale 에 의해서 제한됩니다.지정되어 있다 scale 그리고 허용 되는 자리수를 넘는 자리수를 소수부에 가지는 값을 컬럼이 할당할 수 있었을 경우, 값은 지정되어 있다 scale 에 맞추어 말 수 있습니다.지정되어 있다(또는 디폴트의)precision (와)과 scale 에 의해서 암묵적으로 지정된 범위를 넘는 크기의 값이 DECIMAL 또는 NUMERIC 컬럼이 할당할 수 있었을 경우, 그 범위의 최대치가 격납됩니다.

SQL-92 표준의 확장으로서MySQL 그럼, 전출의 겉(표)에 들고 있도록(듯이),TINYINT ,MEDIUMINT , 및 BIGINT 형태도 서포트하고 있습니다.이제(벌써) 1 개의 확장으로서MySQL 에는,INT(4) (와)과 같이, 형태의 기본 키워드에 이어 정수치의 표시폭을 외모내로 지정할 수 있는 옵션이 있습니다.이 옵션의 표시폭의 지정은, 컬럼으로 지정된 폭보다 작은 폭을 가지는 값으로 표시의 좌측을 묻는 목적으로 사용됩니다만, 그 컬럼에 격납할 수 있는 값의 범위가 제한되거나 그 컬럼으로 지정된 폭을 넘는 폭을 가지는 값의 자리수가 제한 되거나 할 것은 없습니다.옵션의 확장 속성 ZEROFILL (와)과 배합해 사용했을 경우, 디폴트의 스페이스에 대신하고 제로가 파묻힙니다. 예를 들어,INT(5) ZEROFILL (으)로서 선언된 컬럼의 경우, 값 4 하 00004 (으)로서 꺼내집니다.주의: 정수 컬럼의 표시폭보다 큰 값을 격납하면,MySQL 그리고 일부의 복잡한 결합의 텐포라리테이불을 생성할 경우에 문제가 발생하는 일이 있습니다.이 경우, 데이터는 어디까지나 본래의 컬럼폭에 맞고 있는 것으로서 다루어집니다.

모든 정수형에는, 옵션(비표준) 속성 UNSIGNED (을)를 설정할 수 있습니다.부호 없음의 값은, 정수치만을 입력할 수 있도록 하고 싶은 컬럼으로, 약간 큰 수치 범위를 필요로 하는 경우에 사용할 수 있습니다.

MySQL 4.0.2 이?~ 그럼, 부동 소수점형에도 UNSIGNED (을)를 설정할 수 있습니다. 이 속성이 지정되어 있으면, 정수형의 경우와 같이, 컬럼에 음수의 값을 격납할 수 없게 됩니다만, 정수형과는 달라, 컬럼치 위의 범위는 바뀌지 않습니다.

FLOAT 형태는 근사 수치 데이터형을 표현하는 목적으로 사용됩니다. SQL-92 표준에서는, 키워드 FLOAT 에 계속 될까 개내에 옵션의 정도를 비트로 지정할 수 있습니다(지수의 범위는 지정할 수 없습니다).이 옵션의 정도 지정은 MySQL 실장에서도 서포트하고 있습니다.정도를 지정하지 않고 컬럼에 대해서 FLOAT 키워드를 사용했을 경우,MySQL 그럼 4 아르바이트를 사용해 값이 격납됩니다.FLOAT 키워드에 이어 외모내에 2 개의 숫자를 지정하는 가변의 구문도 사용할 수 있습니다.이 옵션에서는, 최초의 숫자는 값에 필요한 아르바이트 단위의 기억용량을 나타내,2 번째의 숫자는 격납 및 표시하는 소수부의 자리수를 나타냅니다(DECIMAL 및 NUMERIC (와)과 같이).MySQL 그럼, 컬럼에 대해서 지정되어 있는 소수부 자리수를 넘는 수의 자리수를 격납하려고 하면, 격납시에 값을 말 수 있어 여분의 자리수가 삭제됩니다.

REAL 형태와 DOUBLE PRECISION 형태에서는 정도의 지정은 실시할 수 없습니다.SQL-92 표준의 확장으로서MySQL 그럼,DOUBLE 형태는 DOUBLE PRECISION 형태의 동의어로서 인식됩니다.SQL-92 표준에서는,REAL 형태의 정도는 DOUBLE PRECISION 형태로 사용되고 있는 정도보다 작지 않으면 안 되는데 대해,MySQL 그럼, 이러한 양쪽 모두가 8 아르바이트의 배정도 부동 소수점치로서 실장됩니다(비 ``ANSI 모드'' 그리고 실행했을 경우). 최대한의 이식성을 확보하기 위해서는, 근사 수치 데이터치의 격납을 필요로 하는 코드에서는,FLOAT 또는 DOUBLE PRECISION 의 사용시에 정도와 소수부의 자리수를 모두 지정하지 않게 합니다.

수치형의 컬럼에, 그 컬럼형으로 허용 되고 있는 범위를 넘는 값을 격납하려고 하면,MySQL 그럼, 값은 허용 범위의 최대치 또는 최저치에 말 수 있어 격납됩니다.

예를 들어,INT 컬럼의 범위는 -2147483648 (으)로부터 2147483647 입니다.이 경우,INT 컬럼에 -9999999999 그렇다고 하는 값을 삽입하려고 하면, 값은 범위의 최저치에 말 수 있어-2147483648 (으)로서 격납됩니다.같이9999999999 그렇다고 하는 값을 삽입하려고 하면, 값은 2147483647 (으)로서 격납됩니다.

INT 컬럼이 UNSIGNED (으)로서 설정되어 있는 경우, 이 컬럼의 범위의 사이즈는 바뀌지 않습니다만, 최소치와 최대치는 각각 0 (와)과 4294967295 (이)가 됩니다. 따라서,-9999999999 및 9999999999 그렇다고 하는 값을 격납하려고 하면, 이 컬럼에게는 각각 0 및 4294967296 그렇다고 하는 값이 격납됩니다.

ALTER TABLE ,LOAD DATA INFILE ,UPDATE , 및 복수행의 INSERT 스테이트먼트에서는, 잘라 흘리기에 의한 값의 변환은 `` 경고'' (으)로서 보고됩니다.

형 | 아르바이트 | 최소치 | 최대치
TINYINT | 1 | -128 | 127
SMALLINT | 2 | -32768 | 32767
MEDIUMINT | 3 | -8388608 | 8388607
INT | 4 | -2147483648 | 2147483647
BIGINT | 8 | -9223372036854775808 | 9223372036854775807

6.2.2. 일자와 시각형

일자와 시각형에는,DATETIME ,DATE ,TIMESTAMP ,TIME ,YEAR 하지만 있습니다.이러한 형태의 컬럼은, 모두, 일정한 범위의 올바른 값을 받습니다만, 그 외에, 실제로는 부정한 값을 지정할 경우에 사용된다 `` 제로'' 의 값도 받습니다.MySQL 그럼,' 엄밀' 에는 올바르지 않은 일부의 일자치(1999-11-31 등)도 격납 가능한 것으로 주의해 주세요. 이것은, 일자 체크는 어플리케이션으로 실행되므로 SQL 서버측에서 실시할 필요는 없는, 이라고 하는 전제에 서있기 (위해)때문입니다.일자 체크를 ' 신속' 에 실시하기 위해서,MySQL 그럼, 지정된 달이 0 ~ 12 의 범위에 있을지라고 지정된 일자가 0 ~ 31 의 범위에 있을지 마셔 체크합니다.이러한 범위에 0 하지만 포함되어 있는 이유는,MySQL 그럼,DATE 또는 DATETIME 컬럼의 날의 값 또는 세월의 값이 제로인 일자의 격납이 허용 되고 있기 (위해)때문입니다.이것은, 생일을 격납할 필요가 있는 어플리케이션으로 정확한 일자를 모를 때 등에 매우 도움이 됩니다.이 경우, 단지 1999-00-00 (이)나 1999-01-00 등으로 해서, 일자를 격납합니다(이러한 일자를 지정했을 경우,DATE_SUB() (이)나 DATE_ADD 등의 함수에 의해서 올바른 값이 돌아가면 상정할 수 없습니다).

이하에, 일자와 시각형에 관해서 유의해야 할 일반 고려사항을 몇개인가 나타내 보입니다.

  • MySQL 그럼, 개개의 일자 또는 시각형의 값의 취득은 표준 형식에서 행해지지만, 입력한 값(예를 들어, 일자 또는 시각형에 할당하는 값, 또는 이러한 형태와 비교하는 값의 지정시등)에 대해서는, 다양한 형식에서 해석이 시도된다.다만, 서포트하고 있는 형식은, 이?~ 의 섹션으로 설명하고 있는 형식에 한정된다.올바른 값을 지정하는 것이 전제가 되기 위해, 비서포트 형식에서 값을 지정하면, 예측할 수 없는 결과가 발생하는 경우가 있다.

  • MySQL 그럼, 값의 해석이 복수의 형식에서 시도되지만, 일자치의 해부분은 반드시 좌단과 상정된다.일자는, 해- 월- 일의 순서(예: '98-09-04' )(으)로 지정할 필요가 있다.일반적으로 사용되고 있는 달- 일- 해나 일- 월- 해의 순서(예: '09-04-98' ,'04-09-98' )(은)는 사용하지 않는다.

  • MySQL 그럼, 일자 또는 시각형의 값을 수치형의 문맥으로 사용했을 경우, 일자 또는 시각형의 값은 수치에 자동적으로 변환된다.그 반대의 경우도, 같은 변환을 한다.

  • MySQL 그럼, 일자 또는 시각형으로 범위외의 값이나 부정한 값(이 섹션의 최초의 부분을 참조)을 입력하면, 값은 그 형태의 `` 제로'' 값에 변환된다(이 예외로서 범위외의 TIME 값은 TIME 형태의 범위의 최대치 또는 최소치에 잘라 떨어진다).다음의 겉(표)에, 각각의 형태의 `` 제로'' 값을 나타낸다.

    컬럼형 | `` 제로'' 치
    DATETIME | '0000-00-00 00:00:00'
    DATE | '0000-00-00'
    TIMESTAMP | 00000000000000 (길이는 표시 사이즈에 의존)
    TIME | '00:00:00'
    YEAR | 0000

  • `` 제로'' 값은 특수한 값이지만, 위의 겉(표)에 나타낸 값을 사용하는 것에 의해서,`` 제로'' 값을 명시적으로 격납 또는 참조할 수 있다.또, 이 그 밖에, 보다 간단하게 기술할 수 있는 값 '0' 또는 0 도,`` 제로'' 값의 격납 또는 참조에 사용할 수 있다.

  • ODBC 그럼, 일자 또는 시각형의 값 `` 제로'' (을)를 처리할 수 없기 때문에,MyODBC 버젼 2.50.12 이?~ 그럼,MyODBC (을)를 통해 일자 또는 시각형의 값 `` 제로'' (을)를 사용하면, 자동적으로 NULL 에 변환된다.

6.2.2.1. 서기 2000 해문제와 일자형

MySQL 자체는 서기 2000 해문제에 대응하고 있습니다만(see 항1.2.5. 「서기 2000 해대응」 ),MySQL 에의 입력치가 이 문제에 대응하고 있지 않는 경우가 있습니다.2 자리수의 해의 값을 가지는 입력치는, 세기를 모르기 때문에 모두 애매합니다.MySQL 그럼 해의 값은 내부에서 4 자리수를 사용해 격납되기 위해, 이러한 값은 4 자리수 형식으로 변환할 필요가 있습니다.

DATETIME 형태,DATE 형태,TIMESTAMP 형태,YEAR 형태의 컬럼에서 만나지 않는다해의 값을 포함한 일자가 지정되었을 경우,MySQL 그럼, 다음의 규칙에 따라서 그러한 일자가 해석됩니다.

  • 범위 00-69 의 해의 값은 2000-2069 에 변환

  • 범위 70-99 의 해의 값은 1970-1999 에 변환

이러한 규칙에서는, 입력한 데이터가 무엇을 나타낼까에 관해서, 단지, 타당한 추측을 할 뿐입니다.MySQL 그리고 사용되는 발견적 수법으로 올바른 해의 값이 생성되지 않는 경우는,4 자리수의 해의 값을 포함한, 애매하지 않은 값을 입력해 주세요.

ORDER BY 그럼,2 자리수의 YEAR/DATE/DATETIME 형태가 올바르고 소트 됩니다.

일부의 함수(MIN() (이)나 MAX() 등)에서는,TIMESTAMP/DATE 형태의 값이 수치에 변환되는 것에 주의해 주세요.따라서,2 자리수의 해를 가지는 타임 스탬프는 이러한 함수에서는 정상적으로 기능하지 않습니다.이 경우의 수정 방법으로서는,TIMESTAMP/DATE (을)를 4 자리수의 해형식으로 변환하는지, 또는 MIN(DATE_ADD(timestamp,INTERVAL 0 DAYS)) (와)과 같은 것을 사용합니다.

6.2.2.2. 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' 입니다.

TIMESTAMP 컬럼형의 특성과 동작은,MySQL 의 버젼과 서버로의 SQL 실행 모드에 따라 다릅니다.

MAXDB 모드로의 실행시의 TIMESTAMP 의 동작

MySQL (을)를 MAXDB 모드로 실행하고 있는 경우,TIMESTAMP 하 DATETIME (와)과 같이 동작합니다.TIMESTAMP 컬럼의 자동 갱신(다음의 단락으로 설명) 하행 깨지지 않습니다.MySQL 의 MAXDB 모드로의 실행은, 버젼 4.1.1 이?~ 그리고 가능합니다.See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

MAXDB 모드로 실행하고 있지 않을 때의 TIMESTAMP 의 동작

TIMESTAMP 컬럼형에서는,INSERT 또는 UPDATE 조작에 대해서 현재의 일자와 시각을 자동적으로 지정할 수 있습니다.TIMESTAMP 컬럼이 다수 있는 경우는, 최초의 컬럼만이 자동으로 갱신됩니다.

최초의 TIMESTAMP 컬럼의 자동 갱신은, 다음의 몇개의 조건으로 발생합니다.

  • INSERT 또는 LOAD DATA INFILE 스테이트먼트로, 컬럼이 명시적으로 지정되어 있지 않은 경우.

  • UPDATE 스테이트먼트 및 그 외의 어떠한 컬럼 변경치로 컬럼이 명시적으로 지정되어 있지 않은 경우(주의: 컬럼에 벌써 설정되어 있는 값을 설정하려고 한다 UPDATE 그럼,TIMESTAMP 컬럼은 갱신되지 않는다.컬럼에 현재의 값을 설정하려고 해도,MySQL 그럼, 효율성을 고려해 갱신 조작이 무시된다).

  • TIMESTAMP 컬럼에 값 NULL 하지만 명시적으로 설정되었을 경우.

2 번째 이?~ 의 TIMESTAMP 컬럼에도, 현재의 일자와 시각을 설정할 수 있습니다.컬럼에 NULL 또는 NOW() (을)를 설정합니다.

TIMESTAMP 형태의 몇개의 컬럼에 현재의 일자와 시각 이외의 값을 설정하려면 , 그 컬럼에 대해서, 필요한 값을 명시적으로 설정합니다.이것은, 최초의 TIMESTAMP 컬럼에 대해서도 같습니다.이 특성은, 다음에 나타내도록(듯이), 레코드의 작성시에 TIMESTAMP 컬럼에 현재의 일시를 설정해, 그 후 그 레코드의 갱신시에는 설정제의 값을 변경하지 않게 하는 경우 등에 도움이 됩니다.

  • 레코드의 작성시에,MySQL 에 의해서 컬럼을 설정한다. 그것에 의해, 그 컬럼이 현재의 일자와 시각에 초기화된다.

  • 그 레코드의 다른 컬럼에 대해서 후속의 코우신을 실시했을 때에는,TIMESTAMP 컬럼에 그 컬럼의 현재의 값을 명시적으로 설정한다.

그렇다고는 해도,DATETIME 컬럼을 사용해 레코드의 작성시에 값을 NOW() 에 초기화해, 후속의 갱신시에는 그대로 해 둔다는 것도, 간편한 방법입니다.

MAXDB 모드로의 실행시의 TIMESTAMP 의 특성

MySQL (을)를 MAXDB 모드로 실행하고 있는 경우,TIMESTAMP 하 DATETIME 멈춘 구 바뀌지 않습니다.격납과 표시에는 같은 형식이 사용되어 또 값의 범위도 같습니다.MySQL 의 MAXDB 모드로의 실행은, 버젼 4.1.1 이?~ 그리고 가능합니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

MAXDB 모드로 실행하고 있지 않을 때의,MySQL 4.1 이?~ (으)로의 TIMESTAMP 의 특성

MySQL 4.1.0 그럼,TIMESTAMP 컬럼의 격납 및 표시에는, DATETIME 컬럼과 같은 형식이 사용됩니다.따라서, 다음의 단락으로 설명하고 있는 방법으로 좁게 하거나 넓히거나 할 수 없습니다.즉,TIMESTAMP(2) (이)나 TIMESTAMP(4) 등은 사용할 수 없게 됩니다.그 이외의 특성은, 이전의 MySQL 버젼과 같습니다.

MySQL 4.1 보다 전의 버젼에 있어서의 TIMESTAMP 의 특성

TIMESTAMP 값은 1970 해의 시작으로부터 2037 해의 일정한 시점까지를 범위로 해, 시간 분해가능은 1 초입니다.값은 수치로서 표시됩니다.

MySQL 그리고 TIMESTAMP 형태의 값의 취득과 표시에 사용되는 형식은, 다음의 겉(표)에 나타내도록(듯이), 표시 사이즈에 따라서 다릅니다.최장의 TIMESTAMP 형식은 14 자리수입니다만,TIMESTAMP 형태의 컬럼은 더 짧은 표시 사이즈로 작성할 수도 있습니다.

컬럼형 | 표시 형식
TIMESTAMP(14) | YYYYMMDDHHMMSS
TIMESTAMP(12) | YYMMDDHHMMSS
TIMESTAMP(10) | YYMMDDHHMM
TIMESTAMP(8) | YYYYMMDD
TIMESTAMP(6) | YYMMDD
TIMESTAMP(4) | YYMM
TIMESTAMP(2) | YY

TIMESTAMP 형태의 컬럼에서는, 표시 사이즈에 관계없이, 격납 사이즈는 모두 같습니다.가장 일반적인 표시 사이즈는 6 ,8 ,12 ,14 입니다.테이블의 작성시에 임의의 표시 사이즈를 지정할 수 있습니다만, 값 0 (와)과 14 (을)를 넘는 값은 강제적으로 14 (으)로 설정됩니다.1 ~ 13 의 홀수치의 사이즈는 강제적으로 바로 위의 짝수로 설정됩니다.

주의: 버젼 4.1 이?~ ,TIMESTAMP 하 'YYYY-MM-DD HH:MM:SS' 형식의 문자열로서 돌려주어집니다.그 외의 타임 스탬프장의 서포트는 안?~ 되었습니다.

DATETIME ,DATE ,TIMESTAMP 형태의 값은, 이하의 일련의 공통 형식의 어느쪽이든을 사용해 지정할 수 있습니다.

  • 'YYYY-MM-DD HH:MM:SS' 또는 'YY-MM-DD HH:MM:SS' 형식의 문자열로서 지정.`` 유연'' 구문이 허용 된다 --- 일자 부분과 시각 부분의 단락 기호로서 임의의 구두점 문자를 사용할 수 있다. 예를 들어,'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' 형식의 문자열로서 지정. 이 경우도 `` 유연'' 구문이 허용 된다.예를 들어,'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' (이)가 된다.

  • 'YYYYMMDD' 또는 '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 값은, 각각의 형태의 `` 제로'' 값('0000-00-00 00:00:00' ,'0000-00-00' ,00000000000000 )에 변환됩니다.

일자 부분의 단락 기호를 포함한 문자열로서 값을 지정하는 경우,10 보다 적은 달 또는 날의 값을 2 자리수로 지정할 필요는 없습니다.'1979-6-9' 하 '1979-06-09' (와)과 같은 의미가 됩니다.같이 시각 부분의 단락 기호를 포함한 문자열로서 값을 지정하는 경우,10 보다 적을 시, 분 , 또는 초의 값을 2 자리수로 지정할 필요는 없습니다.'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 형식이며, 최초의 2 자리수가 해이라고 상정됩니다.이것들 이외의 길이의 수치는, 가장 가까운 길이가 되도록(듯이) 선두에 제로가 추가된 수치로서 해석됩니다.

단락 없음의 문자열로서 지정한 값은, 그 문자열의 길이에 근거해 해석됩니다.문자열이 8 문자 또는 14 문자의 경우, 최초의 4 문자가 해이라고 상정됩니다.그 이외의 길이의 문자열의 경우, 최초의 2 문자가 해이다고 해석됩니다.문자열은, 거기에 포함되어 있는 각 부분에 대응하고, 왼쪽에서 오른쪽으로, 년, 월, 일, 시, 분, 초의 값으로 해서 해석됩니다.따라서,6 문자보다 적은 문자열은 사용할 수 없습니다.예를 들어,1999 년 3 달을 나타내는 값으로 해서 '9903' (을)를 지정하면,MySQL 그럼, 테이블에 일자치로서 `` 제로'' 하지만 격납됩니다.이것은, 해와 달의 값이 99 (와)과 03 (으)로서 지정되어 있어도 날의 부분이 전혀 없는 것으로부터, 올바른 일자는 아니기 때문입니다.그러나,MySQL 3.23 이?~ 그럼, 결핍 하고 있는 달 또는 날의 부분을 나타내는 제로의 값을 명시적으로 지정할 수 있습니다.예를 들어,'990300' (와)과 지정하는 것으로,'1999-03-00' 그렇다고 하는 일자치를 격납할 수 있습니다.

TIMESTAMP 컬럼에서는, 올바른 값은, 표시 사이즈에 관계없이, 그 값이 지정되었을 때의 완전한 정도로 격납됩니다.이것은, 암묵적으로 다음 일을 의미합니다.

  • 컬럼형이 TIMESTAMP(4) 또는 TIMESTAMP(2) 의 경우에서도, 반드시 년, 달, 일을 지정할 필요가 있다.이 모든 것을 지정하지 않으면 값은 올바른 일자는 되지 않고,0 하지만 격납된다.

  • ALTER TABLE (을)를 사용해 표시 자리수의 작은 TIMESTAMP 컬럼의 자리수를 펼치면, 그것까지 `` 비표시'' (이)가 되어 있던 정보가 표시된다.

  • 같이TIMESTAMP 컬럼을 좁게 해도, 단지, 값을 표시했을 때에 표시되는 정보가 적게 되는 것만으로, 정보 자체가 없어지는 것은 아니다.

  • TIMESTAMP 형태의 값은 완전한 정도로 격납되지만, 기반의 격납치에 대해서 직접 작용하는 함수는 UNIX_TIMESTAMP() 뿐이다.다른 함수는, 꺼내져 형식 설정된 값에 작용한다.따라서,HOUR() (이)나 SECOND() 등의 함수는, 형식 설정된 값에 TIMESTAMP 값의 해당의 부분이 포함되지 않은 경우, 사용할 수 없다.예를 들어,TIMESTAMP 컬럼의 HH 부분은, 표시 사이즈가 10 이상이 아니다고 표시되지 않기 때문에, 그것보다 짧다 TIMESTAMP 값에 대해서 HOUR() 조작을 실시해도, 무의미한 값 밖에 얻을 수 없다.

어느 일자형의 값을 다른 일자형의 오브젝트에 할당하는 것은, 어느 정도까지는 가능합니다.그러나, 어떠한 값의 변화나 정보의 소실이 일어날 가능성이 있습니다.

  • DATE 형태의 값을 DATETIME 또는 TIMESTAMP 형태의 오브젝트에 할당했을 경우, 값에 시각 정보가 포함되지 않기 때문에, 결과의 값의 시각 부분은 '00:00:00' (으)로 설정된다.

  • DATETIME 또는 TIMESTAMP 형태의 값을 DATE 형태의 오브젝트에 할당했을 경우,DATE 형태에는 시각 정보가 격납되지 않기 때문에, 결과의 값의 시각 부분은 삭제된다.

  • DATETIME ,DATE , 및 TIMESTAMP 형태의 값은 모두, 같은 형식 세트로 지정할 수 있지만, 값의 범위에 대해서는, 모든 형태로 같을인 것은 아니다.예를 들어,TIMESTAMP 형태의 값은,1970 보다 앞에 두거나2037 보다 뒤로 할 수 없다.따라서,'1968-01-01' 등의 일자는,DATETIME 형태나 DATE 형태의 값으로서는 올바르지만,TIMESTAMP 형태의 값으로서는 올바르지 않기 때문에, 이러한 오브젝트에 할당하면, 값은 0 에 변환된다.

일자치를 지정할 때 , 다음의 점에 주의해 주세요.

  • 문자열로서 지정하는 값으로 허용 되는 유연한 형식은, 헷갈린 것이 있다. 예를 들어,'10:11:12' 등의 값은,‘: ＇ 단락 기호의 탓으로 시각치와 같이 보이지만, 일자의 문맥으로 사용했을 경우는, 해 '2010-11-12' (으)로서 해석된다.치 '10:45:15' (은)는,'45' 하지만 올바른 달은 아니기 때문에,'0000-00-00' 에 변환된다.

  • MySQL 서버에서는, 일 00-31 , 달 00-12 , 해 1000-9999 의 유효성에 관한 기본 체크만 실행된다.이 범위외의 일자는 모두 0000-00-00 에 되돌려진다. 이 경우,2002-04-31 (와)과 같이 잘못된 일자도 격납 가능한 것으로 주의한다.Web 어플리케이션에서는, 추가의 체크를 실시하지 않고 , 폼으로부터 데이터를 격납할 수 있다.일자가 유효한 것인지 어떤지 확인하려면 , 어플리케이션으로 체크를 실시할 필요가 있다.

  • 2 자리수로 지정된 해의 값은, 몇세기인가 모르기 때문에, 애매하다.MySQL 그럼, 다음의 규칙에 근거하고,2 자리수의 해의 값이 해석된다.

    • 범위 00-69 의 해의 값은 2000-2069 에 변환

    • 범위 70-99 의 해의 값은 1970-1999 에 변환

6.2.2.3. TIME 형

MySQL 그럼,TIME 형태의 값의 취득과 표시는,'HH:MM:SS' 형식(시간의 부분이 큰 값으로는 'HHH:MM:SS' 형식)으로 행해집니다.TIME 값의 범위는 '-838:59:59' ~ '838:59:59' 입니다.시간의 부분이 큰 이유는,TIME 형태가 1 일의 시각을 표현하기 위해(때문에) 뿐만이 아니고, 경과시간이나 2 개의 이벤트간의 간격을 표현하기 위해서 사용되는 경우가 있기 때문에입니다.1 일의 시각은 24 때 이상이 될 것은 없습니다만, 이벤트간의 경과시간은 24 시간을 크게 웃돌거나 마이너스가 되거나 하는 일이 있습니다.

TIME 형태의 값은, 다음에 나타내는 다양한 형식에서 지정할 수 있습니다.

  • 'D HH:MM:SS.fraction' 형식의 문자열로서 지정(주의: MySQL 그럼, 소수부는 현재 시각 컬럼에 격납되지 않는다).`` 유연'' 구문으로서HH:MM:SS.fraction ,HH:MM:SS ,HH:MM ,D HH:MM:SS ,D HH:MM ,D HH ,SS 의 어느쪽이든도 사용할 수 있다.이 경우,D 하 0 ~ 33 의 사이의 날.

  • 단락 기호가 없는,'HHMMSS' 형식의 문자열(시각으로서 적절한 것)로서 지정.예를 들어,'101112' 하 '10:11:12' (으)로서 인식되지만,'109712' (은)는 올바르지 않기 때문에(와케베분이 부적절),'00:00:00' (이)가 된다.

  • HHMMSS 형식의 수치(시각으로서 적절한 것)로서 지정. 예를 들어,101112 하 '10:11:12' (으)로서 인식된다.대체 형식으로서SS ,MMSS ,HHMMSS ,HHMMSS.fraction 도 인식된다.MySQL 그럼, 소수 부분은 현재 격납되지 않는 것에 주의한다.

  • TIME 형태의 문맥으로 허용 되는 값을 돌려주는,CURRENT_TIME 등의 함수의 결과로서 지정.

TIME 형태의 값을 시각 부분의 단락 기호를 포함한 문자열로서 지정하는 경우,10 보다 적을 시, 분 , 또는 초의 값을 2 자리수로 지정할 필요는 없습니다.'8:3:2' 하 '08:03:02' (와)과 같습니다.

TIME 형태의 컬럼에 `` 짧다'' TIME 값을 할당할 때는 주의해 주세요.MySQL 그럼, 코론이 없는 경우, 우측의 자리수가 초를 나타낸다고 하는 전제에 끊어 값을 해석합니다(이 경우,TIME 형태의 값은 1 일의 시각이 아니고, 경과시간으로서 해석됩니다).예를 들어,'1112' (이)나 1112 (은)는,'11:12:00' (11 시 12 분 )을 나타내는 것처럼 보입니다만,MySQL 그럼,'00:11:12' (11 분 12 초)로서 해석됩니다. 같이'12' (이)나 12 하 '00:00:12' (으)로서 해석됩니다. 그에 대해, 코론이 있다 TIME 값은, 항상 1 일의 시각으로서 다루어집니다.그 때문에,'11:12' (은)는,'00:11:12' (은)는 아니고 '11:12:00' (을)를 의미합니다.

올바른 값 가운데,TIME 형태의 범위외의 값은, 범위의 최대치 또는 최소치에 잘라 떨어집니다.예를 들어,'-850:00:00' (와)과 '850:00:00' (은)는, 각각 '-838:59:59' (와)과 '838:59:59' 에 변환됩니다.

부정한 TIME 값은 '00:00:00' 에 변환됩니다.'00:00:00' 자체는 정당한 TIME 값입니다만, 원의 값이 '00:00:00' (으)로서 지정되었는지, 그렇지 않으면 부정한 값이었는가를, 테이블에 격납되고 있다 '00:00:00' 값으로부터 분별할 수 없는 것에 주의해 주세요.

6.2.2.4. YEAR 형

YEAR 형태는, 해를 표현할 경우에 사용한다 1 아르바이트의 형태입니다.

MySQL 그럼,YEAR 형태의 값의 취득과 표시는 YYYY 형식에서 행해집니다.범위는 1901 ~ 2155 입니다.

YEAR 형태의 값은, 다음에 나타내는 다양한 형식에서 지정할 수 있습니다.

  • 범위 '1901' ~ '2155' 의,4 자리수의 문자열로서 지정.

  • 범위 1901 ~ 2155 의,4 자리수의 수치로서 지정.

  • 범위 '00' ~ '99' 의,2 자리수의 문자열로서 지정.범위 '00' ~ '69' (와)과 '70' ~ '99' 의 값은, 각각 범위 2000 ~ 2069 (와)과 1970 ~ 1999 의 YEAR 값에 변환된다.

  • 범위 1 ~ 99 의,2 자리수의 수치로서 지정.범위 1 ~ 69 (와)과 70 ~ 99 의 값은, 각각 범위 2001 ~ 2069 (와)과 1970 ~ 1999 의 YEAR 값에 변환된다.주의: 2 자리수의 수치의 범위는,2 자리수의 문자열의 범위와 다소 다르다.수치로서 지정했을 경우, 제로를 직접 입력해 2000 (이)라고 해석시킬 수 없다.2000 (이)라고 해석시키려면 , 반드시 문자열의 '0' 또는 '00' (으)로서 지정할 필요가 있다.수치로서 지정하면,0000 (으)로서 해석된다.

  • YEAR 형태의 문맥으로 허용 되는 값을 돌려주는,NOW() 등의 함수의 결과로서 지정.

부정한 YEAR 값은 0000 에 변환됩니다.

6.2.3. 문자열형

문자열형에는,CHAR ,VARCHAR ,BLOB ,TEXT ,ENUM ,SET 하지만 있습니다.이 섹션에서는, 이러한 형태의 기능을 나타내는 것과 동시에, 각각의 기억용량과 쿼리로의 사용 방법에 대해 설명합니다.

형 | 최대 사이즈 | 아르바이트
TINYTEXT 또는 TINYBLOB | 2^8-1 | 255
TEXT 또는 BLOB | 2^16-1 (64K-1 ) | 65535
MEDIUMTEXT 또는 MEDIUMBLOB | 2^24-1 (16M-1 ) | 16777215
LONGBLOB | 2^32-1 (4G-1 ) | 4294967295

6.2.3.1. CHAR 형태와 VARCHAR 형

CHAR 형태와 VARCHAR 형태는 닮습니다만, 격납 및 꺼내 방법이 다릅니다.

CHAR 형태의 컬럼의 길이는, 테이블의 작성시에 선언한 길이에 고정됩니다.이 길이로서1 ~ 255 의 임의의 값을 지정할 수 있습니다(MySQL 버젼 3.23 이?~ 그럼,CHAR 형태의 길이로서0 ~ 255 하지만 가능) .CHAR 형태의 값은, 격납시에, 지정된 길이가 되도록(듯이) 우측으로 스페이스가 파묻힙니다.CHAR 값의 꺼내 때에는, 후속의 스페이스가 삭제됩니다.

VARCHAR 형태의 컬럼의 값은 가변장의 문자열입니다.VARCHAR 컬럼은,CHAR 컬럼 같이,1 ~ 255 의 사이의 임의의 길이로서 선언할 수 있습니다.그러나,CHAR 형태의 값과는 달라,VARCHAR 형태의 값은, 필요한 문자와 길이를 기록하기 위한 1 아르바이트만으로 격납됩니다.값에 묻어 처리를 할 것은 없습니다.값의 격납시, 후속의 스페이스는 삭제됩니다(이 스페이스의 삭제는 SQL-99 의 사양과 다릅니다).격납시나 꺼내 때에, 케이스의 변환 처리는 행해지지 않습니다.

CHAR 형태 또는 VARCHAR 형태의 컬럼에, 그 컬럼의 최대장을 넘는 값을 할당하면, 컬럼의 사이즈에 맞추고 값을 잘라 버릴 수 있습니다.

다음의 겉(표)에, 다양한 문자열치를 CHAR(4) 형태와 VARCHAR(4) 형태의 컬럼을 격납했을 때의 결과에 근거하는, 이러한 컬럼형의 차이에 대해 나타내 보입니다.

치 | CHAR(4) | 필요한 기억용량 | VARCHAR(4) | 필요한 기억용량
'' | ' ' | 4 아르바이트 | '' | 1 아르바이트
'ab' | 'ab ' | 4 아르바이트 | 'ab' | 3 아르바이트
'abcd' | 'abcd' | 4 아르바이트 | 'abcd' | 5 아르바이트
'abcdefgh' | 'abcd' | 4 아르바이트 | 'abcd' | 5 아르바이트

CHAR 형태의 컬럼에서는, 값의 꺼내 때에 후속의 스페이스가 삭제되기 위해,CHAR(4) 형태와 VARCHAR(4) 형태로부터 꺼낸 값은 각각의 경우로 바뀌지 않습니다.

CHAR 형태와 VARCHAR 형태의 컬럼치의 소트와 비교는, 테이블의 작성시에 BINARY 속성이 지정되어 있는 경우를 제외하고, 케이스비의존 방식으로 행해집니다.BINARY 속성은, 컬럼치의 소트와 비교를,MySQL 서버가 가동하고 있는 머신의 ASCII 순서에 따라서, 케이스 의존 방식으로 실시하는 것을 나타냅니다.BINARY 속성은 컬럼의 격납 방법과 취득 방법에는 영향을 주지 않습니다.

버젼 4.1.0 이?~ 그럼, 컬럼형 CHAR BYTE 하지만 CHAR BINARY (으)로서 사용됩니다.이것은 호환성을 고려한 기능입니다.

BINARY 속성은 강고한 속성입니다.BINARY (으)로서 설정한 컬럼을 식에서 사용하면, 그 식 전체가 BINARY 값으로 해서 비교됩니다.

MySQL 그럼,CHAR 형태나 VARCHAR 형태의 컬럼의 형태가, 테이블의 작성시로 암묵적으로 변경되는 경우가 있습니다. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 .

6.2.3.2. BLOB 형태와 TEXT 형

BLOB 형태는, 가변장의 데이터를 격납할 수 있는, 큰 바이너리 오브젝트입니다.TINYBLOB ,BLOB ,MEDIUMBLOB ,LONGBLOB 의 4 개의 BLOB 형태에서는, 격납 가능한 값의 최대장의 봐가 다릅니다.

See 항6.2.6. 「 각 컬럼형에 필요한 기억용량」 .

TINYTEXT ,TEXT ,MEDIUMTEXT ,LONGTEXT 의 4 개의 TEXT 형태는,4 개의 BLOB 형태에 대응하고 있어, 최대장과 기억용량이 각각의 BLOB 형태와 같습니다.BLOB 형태와 TEXT 형태의 유일한 차이는, 소트와 비교가,BLOB 값으로는 케이스 의존 방식으로 행해져 TEXT 값으로는 케이스비의존 방식으로 행해지는 점입니다.즉,TEXT 형태는 대문자와 소문자를 구별하지 않는다 BLOB 형태라고 생각할 수 있습니다.격납시나 꺼내 때에, 케이스의 변환 처리는 행해지지 않습니다.

BLOB 형태 또는 TEXT 형태의 컬럼에 그 컬럼형의 최대장을 넘는 값을 할당하면, 컬럼의 사이즈에 맞추고 값을 잘라 버릴 수 있습니다.

대부분의 면에 있고,TEXT 형태의 컬럼은, 임의의 길이로 설정할 수 있다 VARCHAR 형태의 컬럼으로 간주할 수 있습니다.같이BLOB 형태의 컬럼에 대해서는,VARCHAR BINARY 형태의 컬럼으로 간주할 수 있습니다.차이점은 이하대로입니다.

  • MySQL 버젼 3.23.2 이?~ 그럼,BLOB 형태와 TEXT 형태의 컬럼에게는, 인덱스를 붙일 수 있다.그것보다 전의 MySQL 버젼에서는, 인덱스는 서포트하고 있지 않다.

  • VARCHAR 형태의 컬럼에서는 값의 격납시에 후속의 스페이스가 삭제되지만,BLOB 형태와 TEXT 형태의 컬럼에서는 이 삭제는 행해지지 않는다.

  • BLOB 형태와 TEXT 형태의 컬럼에게는,DEFAULT 값은 설정할 수 없다.

버젼 4.1.0 이?~ 그럼,LONG 형태와 LONG VARCHAR 형태는 MEDIUMTEXT 데이터형에 맵 됩니다.이것은 호환성을 고려한 기능입니다.

MyODBC 그럼,BLOB 형태의 값은 LONGVARBINARY (으)로서 정의되어TEXT 형태의 값은 LONGVARCHAR (으)로서 정의됩니다.

BLOB 형태와 TEXT 형태의 값은 극도로 길어지는 일이 있기 위해, 이러한 값의 사용시에는, 다음에 나타내는 일정한 제약이 적용됩니다.

  • GROUP BY 또는 ORDER BY (을)를 BLOB 형태 또는 TEXT 형태의 컬럼에 사용하는 경우, 컬럼의 값을 고정장의 오브젝트로 변환할 필요가 있다.표준적인 변환 방법으로서는, 다음과 같이,SUBSTRING 함수를 사용한다.

    mysql> SELECT comment FROM tbl_name,SUBSTRING(comment,20) AS substr
    ->                 ORDER BY substr;

    이 변환을 실시하지 않으면 소트시에 컬럼의 최초의 max_sort_length 아르바이트만이 사용된다.max_sort_length 의 디폴트치는 1024 .이 값은,mysqld 서버의 기동시에 -O 옵션을 지정하는 것에 의해서 변경 가능.다음에 나타내도록(듯이), 컬럼의 위치를 지정하는지, 앨리어스(alias)를 사용하는 것에 의해서,BLOB 형태 또는 TEXT 형태의 값을 포함한 식에 대해서 그룹화 조작을 실시할 수 있다.

    mysql> SELECT id,SUBSTRING(blob_col,1,100) FROM tbl_name GROUP BY 2;
mysql> SELECT id,SUBSTRING(blob_col,1,100) AS b FROM tbl_name GROUP BY b;

  • BLOB 형태 또는 TEXT 형태 오브젝트의 최대 사이즈는, 그 형태에 의해서 정해지지만, 클라이언트와 서버간에 실제로 송신할 수 있는 최대치는 사용 가능한 메모리량과 통신 버퍼의 사이즈로 정해진다.메세지 버퍼의 사이즈(max_allowed_packet )(은)는 변경할 수 있지만, 서버측과 클라이언트측의 양쪽 모두로 변경을 실시할 필요가 있다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

주의: BLOB 형태 또는 TEXT 형태의 각각의 값은, 내부에서, 개별적으로 할당할 수 있었던 오브젝트로서 표현됩니다.이것은 다른 모든 컬럼형과 다릅니다.다른 컬럼형에서는, 테이블이 열렸을 때에, 컬럼 마다 1 번만 기억 영역을 할당할 수 있습니다.

6.2.3.3. ENUM 형

ENUM 형태는, 테이블의 작성시에 컬럼의 사양으로 명시적으로 열거된 사용 가능한 값의 리스트로부터, 통상, 값이 선택되는 문자열 오브젝트입니다.

다음에 나타내도록(듯이), 일정한 상황에서는, 하늘의 문자열("" ) 또는 NULL 도 값으로 해서 사용할 수 있습니다.

  • 부정한 값(사용 가능한 값의 리스트에 포함되지 않는 문자열)을 ENUM 형태의 컬럼에 삽입하면, 특수한 에러치로서 하늘의 문자열이 삽입된다.이 문자열은 수치 0 (을)를 가지기 위해,' 통상' 의 하늘의 문자열과는 구별할 수 있다(이것에 대해서는 후술).

  • ENUM 형태가 NULL (으)로서 선언되고 있는 경우, 그 컬럼에서는 NULL 도 올바른 값이 되어, 디폴트치는 NULL (이)가 된다.ENUM 형태가 NOT NULL (으)로서 선언되고 있는 경우는, 사용 가능한 값의 최초의 요소가 디폴트치로서 사용된다.

다음에 나타내도록(듯이), 각 열거치에는 인덱스를 붙일 수 있다.

  • 컬럼의 사양의 사용 가능한 요소의 리스트에 포함되는 값은 1 (으)로부터 순서에 번호 붙여 된다.

  • 하늘의 문자열 에러치의 인덱스치는 0 .따라서, 다음의 SELECT 스테이트먼트에서는, 무효인 ENUM 하지만 할당할 수 있고 있는 레코드를 검색할 수 있다.

    mysql> SELECT * FROM tbl_name WHERE enum_col=0;

  • NULL 값의 인덱스는 NULL .

예를 들어,ENUM("one", "two", "three") (으)로서 지정된 컬럼의 경우, 다음의 값의 어느쪽이든을 취합니다.각각의 값으로는, 대응하는 인덱스도 나타내 보이고 있습니다.

치 | 인덱스
NULL | NULL
"" | 0
"one" | 1
"two" | 2
"three" | 3

열거에는, 최대 65535 개의 요소를 짜넣을 수 있습니다.

3.23.51 이?~ ,ENUM 값의 후속의 스페이스는 테이블의 작성시에 자동으로 삭제됩니다.

ENUM 형태의 컬럼에 값을 할당할 때 , 대문자와 소문자의 구별은 없습니다.그 후, 컬럼으로부터 꺼내지는 값으로는, 대문자와 소문자가 구별됩니다.이 구별은, 테이블의 작성시에 사용 가능한 값으로 해서 지정된 값에 근거해 정해집니다.

ENUM 형태의 값을 수치의 문맥으로 꺼내면, 그 컬럼치의 인덱스가 돌려주어집니다.예를 들어,ENUM 형태의 컬럼으로부터 다음과 같은 수치를 꺼낼 수 있습니다.

mysql> SELECT enum_col+0 FROM tbl_name;

ENUM 형태의 컬럼에 수치를 격납하면, 그 수치는 인덱스로서 다루어져 그 인덱스를 가지는 열거 요소가 값으로 해서 격납됩니다(다만,LOAD DATA 냄새났다가 다르고, 모든 입력이 문자열로서 다루어집니다). 헷갈리기 때문에,ENUM 형태의 문자열에는 수치를 포함하지 않게 해 주세요.

ENUM 형태의 값은, 컬럼의 사양으로 열거 요소가 리스트 되었을 때의 순서에 의거해 소트 됩니다(즉,ENUM (은)는 인덱스 번호순서에 소트 됩니다).예를 들어,ENUM("a", "b") 의 경우,"a" 하 "b" 의 전에 소트 됩니다만,ENUM("b", "a") 의 경우는,"b" 하지만 "a" 의 전에 소트 됩니다.하늘의 문자열은 하늘 이외의 문자열의 전에 소트 되어NULL 값은 그 외 모든 열거치의 전에 소트 됩니다. 예기치 않은 결과가 일어나지 않게,ENUM 리스트는 알파벳순서로 지정하도록(듯이) 합니다.또,GROUP BY CONCAT(col) (을)를 사용하고, 컬럼이 인덱스 번호순서가 아니고, 알파벳순서에 확실히 소트 되도록(듯이) 할 수도 있습니다.

ENUM 형태의 컬럼의 사용 가능한 모든 값이 필요한 경우는,SHOW COLUMNS FROM table_name LIKE enum_column_name (을)를 사용해,2 번째의 컬럼으로 ENUM 정의를 해석합니다.

6.2.3.4. SET 형

SET 형태는, 제로 이상의 값을 가질 수 있는 문자열 오브젝트입니다.이러한 값은 모두 테이블의 작성시로 지정된 사용 가능한 값의 리스트로부터 선택할 필요가 있습니다.SET 형태의 컬럼치가 복수의 요소로 구성되는 경우는, 각 요소간을 콤마(‘, ＇)(으)로 단락짓습니다.이것으로부터,SET 요소의 값자체에는, 콤마를 사용할 수 없습니다.

예를 들어,SET("one", "two") NOT NULL (으)로서 지정된 컬럼은, 다음에 나타내는 값의 어느쪽이든을 취합니다.

""
"one"
"two"
"one,two"

SET 에는 최대 64 개가 다른 요소를 짜넣을 수 있습니다.

3.23.51 이?~ ,SET 값의 후속의 스페이스는 테이블의 작성시에 자동으로 삭제됩니다.

MySQL 그럼,SET 값은 수치로서 격납됩니다.격납치의 최하위의 비트가 최초세트 요소에 대응합니다.SET 값을 수치형의 문맥으로 꺼내면, 꺼내지는 값은, 컬럼치를 구성하는 세트 요소에 대응하는 비트 세트를 가집니다.예를 들어, 다음과 같이,SET 형태의 컬럼으로부터 수치를 꺼낼 수 있습니다.

mysql> SELECT set_col+0 FROM tbl_name;

SET 형태의 컬럼에 수치를 격납하는 경우, 그 수치의 바이너리 표현으로 설정된 비트에 의해서, 컬럼치세트 요소가 정해집니다.예를 들어, 컬럼이 SET("a","b","c","d") (으)로서 지정되어 있다고 합니다.이 경우, 세트 요소는 다음의 비트치를 가집니다.

SET 요소 | 10 진수 | 2 진수
a | 1 | 0001
b | 2 | 0010
c | 4 | 0100
d | 8 | 1000

이 컬럼에 값 9 (을)를 할당했을 경우,2 진수에서는 1001 (이)가 되기 위해,SET 값의 1 번째와 4 번째의 요소이다 "a" (와)과 "d" 하지만 선택되어 결과의 값은 "a,d" (이)가 됩니다.

SET 요소를 복수 가지는 값으로는, 값의 삽입시에는, 요소를 열기하는 순서는 중요하지는 않습니다.값 중(안)에서 특정의 요소를 열기하는 회수도 중요하지는 않습니다. 그 후, 값을 꺼낼 때는, 치내의 각 요소는 1 회만 출현해, 테이블의 작성시로 지정된 순서로 각각의 요소가 열기됩니다.예를 들어, 컬럼이 SET("a","b","c","d") (으)로서 지정되어 있는 경우, 이 컬럼의 값을 꺼냈을 때에는,"a,d" ,"d,a" ,"d,a,a,d,d" (은)는 모두 "a,d" (으)로서 표현됩니다.

SET 형태의 컬럼에 비서포트치를 설정하면, 그 값은 무시됩니다.

SET 형태의 값은 수치로서 소트 됩니다.NULL 값은 비 NULL SET 값보다 전에 소트 됩니다.

다음에 나타내도록(듯이), 통상,SET 형태의 컬럼에 대한다 SELECT 조작에는,LIKE 연산자 또는 FIND_IN_SET() 함수를 사용합니다.

mysql> SELECT * FROM tbl_name WHERE set_col LIKE '%value%';
mysql> SELECT * FROM tbl_name WHERE FIND_IN_SET('value',set_col)>0;

다음의 스테이트먼트도 유효합니다.

mysql> SELECT * FROM tbl_name WHERE set_col = 'val1,val2';
mysql> SELECT * FROM tbl_name WHERE set_col & 1;

이러한 스테이트먼트의 최초의 것으로는, 완전하게 일치하는 것이 검색됩니다.2 번째의 스테이트먼트에서는, 최초세트 요소를 가지는 값이 검색됩니다.

SET 형태의 컬럼의 사용 가능한 모든 값이 필요한 경우는,SHOW COLUMNS FROM table_name LIKE set_column_name (을)를 사용해,2 번째의 컬럼으로 SET 정의를 해석합니다.

6.2.4. 올바른 컬럼형의 선택

기억 영역을 가장 효율적으로 사용하기 위해서는, 각각의 경우에 가장 적합한 형태를 선택하도록(듯이) 합니다.예를 들어,1 ~ 99999 의 범위의 정수를 격납하는 컬럼에게는,MEDIUMINT UNSIGNED 형태가 가장 적합합니다.

일반적인 문제의 1 개로서 금액치의 정확한 표현이 있습니다.이 경우,MySQL 그럼,DECIMAL 형태를 사용해야 합니다.이 형태는 문자열로서 격납되기 위해, 정확함이 없어질 것은 없습니다.정확함이 그만큼 중요하지 않은 경우는,DOUBLE 형태로도 늦지 않습니다.

고정밀도가 필요한 경우는,BIGINT (으)로서 격납되는 고정 소수점형에 언제라도 변환할 수 있습니다.거기에 따르고, 모든 계산을 정수로 실시해, 필요에 따라서, 결과를 부동 소수점치에 다시 변환할 수 있습니다.

6.2.5. 다른 데이타베이스 엔진의 컬럼형의 사용

다른 벤더의 SQL 실장용으로 기술된 코드를 사용하기 쉽게 하기 위해서,MySQL 그럼, 다음의 겉(표)에 나타내는 컬럼형이 맵 됩니다.이 매핑에 의해서, 다른 데이타베이스 엔진으로부터 MySQL 에의 테이블 정의의 이식을 간단하게 실시할 수 있게 되어 있습니다.

다른 벤더의 형태 | MySQL 의 형태
BINARY(NUM) | CHAR(NUM) BINARY
CHAR VARYING(NUM) | VARCHAR(NUM)
FLOAT4 | FLOAT
FLOAT8 | DOUBLE
INT1 | TINYINT
INT2 | SMALLINT
INT3 | MEDIUMINT
INT4 | INT
INT8 | BIGINT
LONG VARBINARY | MEDIUMBLOB
LONG VARCHAR | MEDIUMTEXT
MIDDLEINT | MEDIUMINT
VARBINARY(NUM) | VARCHAR(NUM) BINARY

컬럼형의 매핑은, 테이블의 작성시에 행해집니다.다른 벤더로 사용되고 있는 형태로 테이블을 작성한 후에 DESCRIBE tbl_name 스테이트먼트를 발행하면, 그 형태에 대응한다 MySQL 의 형태를 사용한 테이블 구조가 보고됩니다.

6.2.6. 각 컬럼형에 필요한 기억용량

이하에,MySQL 그리고 서포트하고 있는 각 컬럼형에 필요한 기억용량을 카테고리별로 나타냅니다.

수치형에 필요한 기억용량

컬럼형 | 필요한 기억용량
TINYINT | 1 아르바이트
SMALLINT | 2 아르바이트
MEDIUMINT | 3 아르바이트
INT | 4 아르바이트
INTEGER | 4 아르바이트
BIGINT | 8 아르바이트
FLOAT(X) | X <= 24 의 경우는 4 아르바이트,25 <= X <= 53 의 경우는 8 아르바이트
FLOAT | 4 아르바이트
DOUBLE | 8 아르바이트
DOUBLE PRECISION | 8 아르바이트
REAL | 8 아르바이트
DECIMAL(M,D) | D > 0 의 경우는 M+2 아르바이트,D = 0 의 경우는 M+1 아르바이트(M < D 의 경우는 D+2 아르바이트)
NUMERIC(M,D) | D > 0 의 경우는 M+2 아르바이트,D = 0 의 경우는 M+1 아르바이트(M < D 의 경우는 D+2 아르바이트)

일자형과 시각형에 필요한 기억용량

컬럼형 | 필요한 기억용량
DATE | 3 아르바이트
DATETIME | 8 아르바이트
TIMESTAMP | 4 아르바이트
TIME | 3 아르바이트
YEAR | 1 아르바이트

문자열형에 필요한 기억용량

컬럼형 | 필요한 기억용량
CHAR(M) | M 아르바이트(1 <= M <= 255 )
VARCHAR(M) | L+1 아르바이트(L <= M 그리고, 한편 1 <= M <= 255 )
TINYBLOB ,TINYTEXT | L+1 아르바이트(L < 2^8 )
BLOB ,TEXT | L+2 아르바이트(L < 2^16 )
MEDIUMBLOB ,MEDIUMTEXT | L+3 아르바이트(L < 2^24 )
LONGBLOB ,LONGTEXT | L+4 아르바이트(L < 2^32 )
ENUM('value1','value2',...) | 열거치의 수(최대 65535 개의 값)에 따르고,1 또는 2 아르바이트
SET('value1','value2',...) | 세트 요소의 수(최대 64 개의 요소)에 따르고,1 ,2 ,3 ,4 ,8 아르바이트의 언젠가

VARCHAR 형태, 및 BLOB 형태와 TEXT 형태는 가변장이며, 필요한 기억용량은, 그 형태로 사용할 수 있는 최대 사이즈가 아니고, 컬럼치의 실제의 길이(위의 겉(표)의 L )에 따라 정해집니다.예를 들어,VARCHAR(10) 의 컬럼에게는, 최대 10 문자의 길이의 문자열을 격납할 수 있습니다.실제로 필요한 기억용량은, 문자열의 길이(L )에, 그 문자열의 길이를 기록하기 위해서 필요한 1 아르바이트를 더한 것입니다.'abcd' 그렇다고 하는 문자열의 경우,L 하 4 (이어)여, 필요한 기억용량은 5 아르바이트가 됩니다.

BLOB 형태와 TEXT 형태에서는, 그 형태로 사용할 수 있는 최대장에 따르고, 컬럼치의 길이를 기록하기 위해서,1 ,2 ,3 , 또는 4 아르바이트가 필요하게 됩니다 See 항6.2.3.2. 「BLOB 형태와 TEXT 형태」 .

테이블에 가변장의 컬럼형이 포함되어 있는 경우, 기록 형식도 가변장이 됩니다. 주의: MySQL 그럼, 테이블의 작성시, 일정한 조건하에서 컬럼이 가변장형으로부터 고정장형(또는 그 역)에 변환되는 경우가 있습니다. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 .

ENUM 형태 오브젝트의 사이즈는, 다른 열거치의 수로 정해집니다.사용 가능한 값의 수가 255 까지의 열거에는,1 아르바이트가 사용됩니다.값의 수가 65535 까지의 열거에는,2 아르바이트가 사용됩니다. See 항6.2.3.3. 「ENUM 형태」 .

SET 형태 오브젝트의 사이즈는, 다른 세트 요소의 수로 정해집니다.세트의 사이즈가 N 의 경우, 그 오브젝트는 (N+7)/8 아르바이트(1 ,2 ,3 ,4 , 또는 8 아르바이트에 끝맺어)를 점유 합니다.SET 에는 최대 64 개의 요소를 짜넣을 수 있습니다. See 항6.2.3.4. 「SET 형태」 .

MyISAM 테이블의 1 개의 레코드의 최대 사이즈는 65534 아르바이트입니다.각 BLOB 형태와 TEXT 형태는, 이 사이즈에 대해서 5 ~ 9 아르바이트 밖에 점유 하지 않습니다.


6.3. SELECT 마디와 WHERE 마디로 사용하는 함수

SQL 스테이트먼트내의 select_expression 또는 where_definition (은)는, 이하에 설명하는 함수를 사용한 임의의 식에서 구성할 수 있습니다.

NULL (을)를 포함한 식은, 그 식에 포함되어 있는 연산자와 함수에 관한 기술로 특히 거절이 없으면, 항상 NULL 값을 생성합니다.

주의: 함수명으로 거기에 계속 될까 이전에는, 공백은 삽입할 수 없습니다.이것은, 함수 호출과 함수와 우연히 같은 이름을 가지는 테이블 또는 컬럼의 참조를,MySQL 의 파서를 구별할 수 있도록 하기 (위해)때문입니다.그러나, 인수의 주위에는 스페이스를 삽입할 수 있습니다.

--ansi (을)를 지정해 mysqld (을)를 기동하는지, 또는 mysql_connect() 에 CLIENT_IGNORE_SPACE (을)를 사용하면,MySQL 그리고 함수명의 뒤의 스페이스가 허용 되게 됩니다만, 이와 같이 했을 경우, 모든 함수명이 예약어(reserved word)가 됩니다. See 항1.8.2. 「ANSI 모드로의 MySQL 의 실행」 .

간결하게 하기 위한(해),mysql 프로그램의 출력예에서는, 출력을 생략 형식에서 나타내 보입니다.예를 들어, 다음의 출력의 경우,

mysql> SELECT MOD(29,9);
1 rows in set (0.00 sec)

+-----------+
| mod(29,9) |
+-----------+
|         2 |
+-----------+

예에서는, 다음과 같이 나타내 보입니다.

mysql> SELECT MOD(29,9);
        -> 2

6.3.1. 각 데이터형 공통의 연산자와 함수

6.3.1.1. 외모

( ... )

식으로의 평가를 특정의 순서로 실시하도록(듯이) 강제하려면 , 다음과 같이 외모를 사용합니다.

mysql> SELECT 1+2*3;
        -> 7
mysql> SELECT (1+2)*3;
        -> 9

6.3.1.2. 비교 연산자

비교 연산은,1 (TRUE ),0 (FALSE ), 또는 NULL 의 값을 돌려줍니다.이러한 함수는, 수치와 문자열의 양쪽 모두에 작용합니다.필요에 따라서, 문자열은 수치에, 수치는 문자열에, 자동적으로 변환됩니다(Perl (와)과 같이).

MySQL 그럼, 비교는 다음의 규칙에 근거해 행해집니다.

  • 어느 쪽인지 또는 양쪽 모두의 인수가 NULL 의 경우,<=> 연산자를 사용하고 있을 때를 제외하고, 비교 결과는 NULL (이)가 된다.

  • 비교 연산의 양쪽 모두의 인수가 문자열의 경우, 그것들은 문자열로서 비교된다.

  • 양쪽 모두의 인수가 정수의 경우, 그것들은 정수로서 비교된다.

  • 16 진치는, 수치와 비교하는 경우를 제외하고, 바이너리 문자열로서 다루어진다.

  • 인수의 어느 쪽인지가 TIMESTAMP 또는 DATETIME 형태의 컬럼으로, 이제(벌써) 한편이 정수의 경우, 정수는 비교의 실행전에 타임 스탬프에 변환된다.이것은 ODBC (와)과의 호환성을 확보하기 위해서 행해진다.

  • 그 외의 모든 경우에는, 인수는 부동 소수점수(실수)(실수)로서 비교된다.

디폴트에서는, 문자열의 비교는, 현재의 캐릭터 세트(디폴트에서는 ISO-8859-1 Latin1 .이것은 영어라도 매우 자주(잘) 동작한다)를 사용하고, 케이스비의존 방식으로 행해집니다.

몇개의 표준 연산자(= (이)나 <> 등.LIKE (은)는 포함하지 않는다)를 사용해 케이스비의존 문자열을 비교하는 경우, 후속의 공백(스페이스, 탭, 개행 복귀)은 무시됩니다.

mysql> SELECT "a" ="A \n";
        -> 1

이하의 예는, 비교 연산으로의 문자열로부터 수치에의 변환을 나타낸 것입니다.

mysql> SELECT 1 > '6x';
         -> 0
mysql> SELECT 7 > '6x';
         -> 1
mysql> SELECT 0 > 'x6';
         -> 0
mysql> SELECT 0 = 'x6';
         -> 1

주의: 다음과 같이, 문자열형의 컬럼을 수치형과 비교하는 경우,MySQL 그럼, 인덱스를 사용한 값의 신속한 검색은 실행할 수 없습니다.

SELECT * FROM table_name WHERE string_key=1

그 이유는, 값 1 (을)를 돌려줄 가능성이 있는 다양한 문자열("1" ," 1" ,"1a" 등)이 있기 때문에입니다.

  • =

    동일하다

    mysql> SELECT 1 = 0;
        -> 0
mysql> SELECT '0' = 0;
        -> 1
mysql> SELECT '0.0' = 0;
        -> 1
mysql> SELECT '0.01' = 0;
        -> 0
mysql> SELECT '.01' = 0.01;
        -> 1

  • <> , !=

    동일하지 않다

    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> SELECT 2 >= 2;
        -> 1

  • >

    보다 크다

    mysql> SELECT 2 > 2;
        -> 0

  • <=>

    동일하다(NULL 대응)

    mysql> SELECT 1 <=> 1, NULL <=> NULL, 1 <=> NULL;
        -> 1 1 0

  • IS NULL , IS NOT NULL

    값이 NULL 나다니지 않는가의 테스트

    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

    다른 프로그램에 대해서 적절히 동작하도록(듯이),MySQL 그럼,IS NULL 의 사용시에 대해 다음의 추가 기능을 서포트하고 있다.

    • 직전에 삽입된 레코드의 검색

      SELECT * FROM tbl_name WHERE auto_col IS NULL

      이것을 무효화하려면 ,SQL_AUTO_IS_NULL=0 (을)를 설정한다. See 항5.5.6. 「SET 구문」 .

    • NOT NULL DATE 형태와 DATETIME 형태의 컬럼으로의, 특수한 일자 0000-00-00 의 검색

      SELECT * FROM tbl_name WHERE date_column IS NULL

      이것은, 일부의 ODBC 어플리케이션으로 필요하게 된다(ODBC 그럼 0000-00-00 일자를 서포트하고 있지 않기 때문에).

  • expr BETWEEN min AND max

    expr 하지만 min 이상으로,max 이하의 경우는 1 (을)를 돌려준다.그 이외의 경우는,0 (을)를 돌려준다.모든 인수가 같은 형태의 경우, 이것은 식 (min <= expr AND expr <= max) (와)과 같다.인수의 형태가 다른 경우, 전술의 규칙에 의거해 형태 변환이 실행된다.이 경우, 형태 변환은 3 개 모든 인수에 적용된다. 주의: 4.0.5 보다 전의 버젼에서는, 인수는 expr 의 형태에 변환되고 있었다.

    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) (와)과 같다.

  • expr IN (value,...)

    expr 하지만 IN 리스트의 몇개의 값 때는 1 (을)를 돌려준다.그 이외의 경우는 0 (을)를 돌려준다.모든 값이 정수라면, 값은 모두 expr 의 형태에 근거해 평가되어 소트 된다.그 후, 바이너리 검색에 의해서 아이템이 검색된다.따라서,IN 의 값리스트가 정수만으로 구성되어 있는 경우,IN (은)는 매우 신속히 행해진다.expr 하지만 케이스 의존의 문자열식의 경우, 문자열의 비교는 케이스 의존 방식으로 행해진다.

    mysql> SELECT 2 IN (0,3,5,'wefwf');
        -> 0
mysql> SELECT 'wefwf' IN (0,3,5,'wefwf');
        -> 1

    IN 리스트의 값의 수는,max_allowed_packet 값에만 따라 제한된다.

    4.1 이?~ (SQL-99 표준에 준거하기 위해(때문에)),IN 그럼, 좌측의 식이 NULL 의 경우 뿐만이 아니라, 리스트에 일치하는 것이 발견되지 않고, 리스트내의 식의 1 개가 NULL 의 경우에도 NULL 하지만 돌아간다.

    MySQL 버젼 4.1 이?~ 그럼,IN() 마디에 서브 쿼리를 짜넣을 수도 있다. See 항6.4.2.3. 「ANY ,IN ,SOME (와)과 함께 사용한 서브 쿼리」 .

  • expr NOT IN (value,...)

    NOT (expr IN (value,...)) (와)과 같다.

  • ISNULL(expr)

    expr 하지만 NULL 의 경우는 1 (을)를 돌려준다.그 이외의 경우는 0 (을)를 돌려준다.

    mysql> SELECT ISNULL(1+1);
        -> 0
mysql> SELECT ISNULL(1/0);
        -> 1

    주의: = (을)를 사용했다 NULL 값의 비교는 항상 false (이)가 된다.

  • COALESCE(list)

    리스트내의 최초의 비 NULL 요소를 돌려준다.

    mysql> SELECT COALESCE(NULL,1);
        -> 1
mysql> SELECT COALESCE(NULL,NULL,NULL);
        -> NULL

  • INTERVAL(N,N1,N2,N3,...)

    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

6.3.1.3. 논리 연산자

SQL 그럼, 모든 논리 연산자는,TRUE ,FALSE , 또는 NULL (UNKNOWN )(을)를 돌려줍니다. MySQL 그럼, 이것은 1 (TRUE ),0 (FALSE ),NULL (으)로서 실장되고 있습니다.대부분의 경우, 이러한 값은 다르다 SQL 데이타베이스간에 공통되고 있습니다만, 경우에 따라서는,TRUE 에 대해서 제로 이외의 값이 돌아가기도 합니다.

  • NOT , !

    논리 NOT . 오퍼랜드가 0 의 경우는 1 (을)를 돌려주어, 제로가 아닌 경우는 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> SELECT ! 1+1;
        -> 1

    마지막 예의 경우, 식이 (!1)+1 (와)과 같게 평가되기 위해,1 하지만 돌아간다.

  • AND , &&

    논리적. 모든 오퍼랜드가 제로에서도 NULL 도 아닌 경우는 1 (을)를 돌려주어,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

    주의: 4.0.5 보다 전의 버젼의 MySQL 그럼,NULL 하지만 검출되면, 사용 가능한 0 값을 체크하는 프로세스가 계속되지 않고 , 평가가 정?~ 된다.그 때문에, 이러한 버젼의 경우,SELECT (NULL AND 0) 그럼 0 (은)는 아니고 NULL 하지만 돌아간다. 버젼 4.0.5 그럼, 계속해 가능한 한 최적화를 도모하는 한편으로, 항상 SQL 표준으로 규정되었던 대로의 결과가 되도록(듯이) 코드가 재설계되고 있다.

  • OR , ||

    논리합. 몇개의 오퍼랜드가 비제로의 경우는 1 (을)를 돌려주어, 몇개의 오퍼랜드가 NULL 의 경우는 NULL (을)를 돌려줍니다.그 이외의 경우는 0 (을)를 돌려준다.

    mysql> SELECT 1 || 1;
        -> 1
mysql> SELECT 1 || 0;
        -> 1
mysql> SELECT 0 || 0;
        -> 0
mysql> SELECT 0 || NULL;
        -> NULL
mysql> SELECT 1 || NULL;
        -> 1

  • XOR

    배타 논리합. 몇개의 오퍼랜드가 NULL 의 경우는 NULL (을)를 돌려준다. NULL 이외의 오퍼랜드에 대해서는, 홀수개의 오퍼랜드가 비제로의 경우는 1 (을)를 돌려주어, 그 이외의 경우는 0 (을)를 돌려준다.

    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

    a XOR b (은)는 수학적으로 (a AND (NOT b)) OR ((NOT a) and b) (와)과 등가.

    XOR (은)는 버젼 4.0.2 그리고 추가되었다.

6.3.1.4. flow control 함수

  • CASE value WHEN [compare-value] THEN result [WHEN [compare-value] THEN result ...][ELSE result] END , CASE WHEN [condition] THEN result [WHEN [condition] THEN result ...][ELSE result] END

    최초의 식에서는,value=compare-value 이다 result (을)를 돌려준다.2 번째의 식에서는, 최초의 조건이 true (이)라면, 그 result 값을 돌려준다.일치하는 결과가 검출되지 않는 경우는,ELSE 후의 result 값을 돌려준다.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

    반환값의 형태(INTEGER ,DOUBLE , 또는 STRING )(은)는 최초의 반환값(최초의 THEN 후의 식)의 형태와 같다.

  • IF(expr1,expr2,expr3)

    expr1 하지만 TRUE (expr1 <> 0 및 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 이외의 컬럼의 형태가 된다(이 동작은 MySQL 4.0.3 그리고 새롭게 도입되었다).

    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) 의 테스트를 하기 때문에 있다.이것으로는 기대한 결과를 얻을 수 없는 경우가 있다.2 번째의 식에서는, 원의 부동 소수점치가 제로 이외의 값인지 어떤지 비교에 의해서 테스트된다.비교의 결과는 정수로서 사용된다.

    IF() 의 디폴트의 반환값형은,MySQL 버젼 3.23 그럼 다음과 같이 계산된다(디폴트의 반환값형은 텐포라리테이불에의 격납시에 중요하게 되는 경우가 있다).

    식 | 반환값
    expr2 또는 expr3 하지만 문자열을 돌려준다. | 문자열
    expr2 또는 expr3 하지만 부동 소수점치를 돌려준다. | 부동 소수점
    expr2 또는 expr3 하지만 정수를 돌려준다. | 정수

    expr2 (와)과 expr3 하지만 문자열의 경우, 양쪽 모두의 문자열이 케이스비의존 때는 결과도 케이스비의존이 된다(버젼 3.23.51 이?~ ).

  • IFNULL(expr1,expr2)

    expr1 하지만 NULL (이)가 아닌 경우는 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'

    MySQL 4.0.6 이?~ 그럼,IFNULL(expr1,expr2) 의 디폴트의 결과치는,2 개의 식의 것보다 `` 일반적'' 분(STRING ,REAL 또는 INTEGER 의 순서)가 된다.그 이전의 MySQL 버젼과의 차이는, 식에 근거하는 테이블의 작성시나,IFNULL() (으)로부터 얻을 수 있던 값을 MySQL 그리고 내부적으로 텐포라리테이불에 격납할 필요가 있을 때 가장 현저하다.

    CREATE TABLE foo SELECT IFNULL(1,"test") as test;

    MySQL 4.0.6 그럼, 컬럼 ' 테스트' 의 형태는 CHAR(4) 하지만, 그 이전의 버젼에서는,BIGINT .

  • NULLIF(expr1,expr2)

    expr1 = expr2 하지만 TRUE 의 경우는 NULL (을)를 돌려주어, 그 이외의 경우는 expr1 (을)를 돌려준다. 이것은 CASE WHEN x = y THEN NULL ELSE x END (와)과 같다.

    mysql> SELECT NULLIF(1,1);
        -> NULL
mysql> SELECT NULLIF(1,2);
        -> 1

    주의: MySQL 그럼, 인수가 동일하지 않은 경우,expr1 하 2 회평가된다.

6.3.2. 문자열 함수

문자열 함수에서는, 결과가 max_allowed_packet 서버 파라미터의 설정보다 길어지면,NULL 하지만 돌아갑니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

문자열의 위치를 처리하는 함수에서는, 최초의 위치는 1 (으)로서 번호 붙여 됩니다.

  • ASCII(str)

    문자열 str 의 좌단의 문자의 ASCII 코드치를 돌려준다.str 하지만 하늘의 문자열 때는 0 (을)를 돌려준다.str 하지만 NULL 때는 NULL (을)를 돌려준다.

    mysql> SELECT ASCII('2');
        -> 50
mysql> SELECT ASCII(2);
        -> 50
mysql> SELECT ASCII('dx');
        -> 100

    ORD() 함수도 참조.

  • BIN(N)

    longlong (BIGINT ) 형태의 수치이다 N 의 바이너리의 문자열식을 돌려준다.이것은 CONV(N,10,2) (와)과 같다.N 하지만 NULL 때는 NULL (을)를 돌려준다.

    mysql> SELECT BIN(12);
        -> '1100'

  • BIT_LENGTH(str)

    문자열 str 의 길이를 비트로 돌려준다.

    mysql> SELECT BIT_LENGTH('text');
        -> 32

  • CHAR(N,...)

    인수를 정수로서 해석해, 그러한 정수의 ASCII 코드치로 표현된 문자로부터 완성되는 문자열을 돌려준다.NULL 값은 스킵 된다.

    mysql> SELECT CHAR(77,121,83,81,'76');
        -> 'MySQL'
mysql> SELECT CHAR(77,77.3,'77.3');
        -> 'MMM'

  • CHAR_LENGTH(str)

    문자열 str 의 길이(문자수)를 돌려준다. 멀티 바이트 문자는 1 문자로 간주해진다. 따라서,5 개의 멀티 바이트 문자로 구성되는 문자열의 경우,LENGTH() 그럼 10 하지만 돌아가지만,CHAR_LENGTH() 그럼 5 하지만 돌아간다.

  • CHARACTER_LENGTH(str)

    CHARACTER_LENGTH() 하 CHAR_LENGTH() 의 동의어.

  • CONCAT(str1,str2,...)

    인수를 연결한 결과의 문자열을 돌려준다.몇개의 인수가 NULL 때는 NULL (을)를 돌려준다.3 개이상의 인수의 지정이 가능. 수치형의 인수는 동등의 문자열 형식에 변환된다.

    mysql> SELECT CONCAT('My', 'S', 'QL');
        -> 'MySQL'
mysql> SELECT CONCAT('My', NULL, 'QL');
        -> NULL
mysql> SELECT CONCAT(14.3);
        -> '14.3'

  • CONCAT_WS(separator, str1, str2,...)

    CONCAT_WS() 하 CONCAT() 의 특수형으로, 단락 문자 첨부의 CONCAT (CONCAT With Separator ).최초의 인수는 나머지의 인수의 단락 문자이다. 이 단락 문자는 연결하는 각 문자열의 사이에 삽입된다. 단락 문자는 나머지의 인수 같이, 문자열로서 지정할 수 있다.단락 문자가 NULL 의 경우, 결과는 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'

    MySQL 4.1.1 보다 전의 버젼의 CONCAT_WS() 그럼,NULL 값 뿐만이 아니라, 하늘의 문자열도 스킵 된다.

  • CONV(N,from_base,to_base)

    수치를, 진수가 다른 수치로 변환한다.수치 N (을)를 from_base 진수로부터 to_base 진수로 변환한 수치의 문자열 표현을 돌려준다.몇개의 인수가 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);
        -> '40'

  • ELT(N,str1,str2,str3,...)

    N = 1 때는 str1 (을)를 돌려주어,N = 2 때는 str2 (을)를 돌려준다(이하 같이).N 하지만 1 보다 작은지, 인수의 수보다 큰 경우는,NULL (을)를 돌려준다.ELT() 하 FIELD() 의 역.

    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' (으)로 지정된 수치에 대해,1 의 비트를 'on' 그리고 지정된 문자열로 표현해,0 의 비트를 'off' 그리고 지정된 문자열로 표현한 문자열을 돌려준다.각 문자열의 사이는 'separator' (으)로 지정된 단락 문자' (디폴트는 ',' )(으)로 단락지어져'number_of_bits' (으)로 지정된 비트수(디폴트는 64 )만이 표시된다.

    mysql> SELECT EXPORT_SET(5,'Y','N',',',4)
        -> Y,N,Y,N

  • FIELD(str,str1,str2,str3,...)

    str1, str2, str3, ... 리스트내의 str 의 인덱스를 돌려준다. str 하지만 검출되지 않는 경우는 0 (을)를 돌려준다. FIELD() 하 ELT() 의 역.

    mysql> SELECT FIELD('ej', 'Hej', 'ej', 'Heja', 'hej', 'foo');
        -> 2
mysql> SELECT FIELD('fo', 'Hej', 'ej', 'Heja', 'hej', 'foo');
        -> 0

  • FIND_IN_SET(str,strlist)

    N 개의 부분 문자열로 구성되는 리스트 strlist 에, 문자열 str 하지만 포함되어 있는 경우는,1 (으)로부터 N 까지의 몇개의 값을 돌려준다.문자열의 리스트는, 각각의 사이를 ‘, ＇ 문자로 단락지어진 각 부분 문자열로 구성되는 문자열이다.최초의 인수가 정수 문자열로,2 번째의 인수가 SET 형태의 컬럼의 경우,FIND_IN_SET() 함수는 비트 연산을 사용하도록(듯이) 최적화된다. str 하지만 strlist 에 포함되지 않은 경우나,strlist 하지만 하늘의 문자열의 경우는,0 (을)를 돌려준다.어느 쪽의 인수도 NULL 의 경우는,NULL (을)를 돌려준다. 최초의 인수에 콤마 ‘, ＇ 하지만 포함되어 있으면, 이 함수는 올바르게 동작하지 않는다.

    mysql> SELECT FIND_IN_SET('b','a,b,c,d');
        -> 2

  • HEX(N_or_S)

    N_OR_S 하지만 수치의 경우,longlong (BIGINT ) 형태의 수치이다 N 의 16 진치의 문자열 표현을 돌려준다. 이것은 CONV(N,10,16) (와)과 같다.

    N_OR_S 하지만 문자열의 경우는,N_OR_S 의 각 문자를 2 자리수의 16 진수로 변환했다 N_OR_S 의 16 진문자열을 돌려준다.이것은 0xff 문자열의 역.

    mysql> SELECT HEX(255);
        -> 'FF'
mysql> SELECT HEX("abc");
        -> 616263
mysql> SELECT 0x616263;
        -> "abc"
mysql> SELECT HEX('
아');
        -> 'A4A2'   ; #
주의 EUC-JP
코드로의 결과

  • INSERT(str,pos,len,newstr)

    str 안의, 위치 pos (으)로부터 시작되는 길이 len 의 부분 문자열을 문자열 newstr 에 옮겨놓은 문자열을 돌려준다.

    mysql> SELECT INSERT('Quadratic', 3, 4, 'What');
        -> 'QuWhattic'
mysql> SELECT INSERT('
만나 이식해', 3, 2, '
인가');
        ->
사랑이나

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • INSTR(str,substr)

    문자열 str 에 최초로 출현하는 부분 문자열 substr 의 위치를 돌려준다.이것은 LOCATE() 의 2 개의 인수를 사용하는 형식과 같지만, 인수의 순서가 바뀌고 있다.

    mysql> SELECT INSTR('foobarbar', 'bar');
        -> 4
mysql> SELECT INSTR('xbar', 'foobar');
        -> 0
mysql> SELECT INSTR('
만나 이식해', '
');
        -> 3

    이 함수는 멀티 바이트 문자에 대응하고 있다. MySQL 3.23 그럼, 이 함수에서는 대문자와 소문자가 구별되지만(케이스 의존), 버젼 4.0 그럼, 어느 쪽인가의 인수가 바이너리 문자열의 경우에게만 케이스 의존이 된다.

  • LCASE(str)

    LCASE() 하 LOWER() 의 동의어.

  • LEFT(str,len)

    문자열 str 의 좌단에 있는 길이 len 의 문자를 돌려준다.

    mysql> SELECT LEFT('foobarbar', 5);
        -> 'fooba'
mysql> SELECT LEFT('
만나 이식해', 2);
        -> '
사랑'

  • LENGTH(str)

    문자열 str 의 길이(아르바이트)를 돌려준다.1 개의 멀티 바이트 문자는 복수 바이트가 된다. 따라서,5 개의 2 아르바이트 문자로 구성되는 문자열의 경우,LENGTH() 그럼 10 하지만 돌아가지만,CHAR_LENGTH() 그럼 5 하지만 돌아간다.

    mysql> SELECT LENGTH('text');
        -> 4
mysql> SELECT LENGTH('
만나 이식해');
        -> 10

  • LOAD_FILE(file_name)

    파일을 읽어내, 파일의 내용을 문자열로서 돌려준다.파일은 서버상에 존재하지 않으면 안되어, 파일의 풀 패스명을 지정할 필요가 있다.또,FILE 권한이 필요하다.파일은 전유저가 읽어내 가능하지 않으면 안되어,max_allowed_packet 보다 작은 사이즈가 아니면 안된다.

    파일이 존재하지 않는 경우나, 상기의 이유의 어느 쪽인가에 따라 읽어내 불가능한 경우, 이 함수는 NULL (을)를 돌려준다.

    mysql> UPDATE tbl_name
           SET blob_column=LOAD_FILE("/tmp/picture")
           WHERE id=1;

    MySQL 버젼 3.23 이외의 버젼을 사용하고 있는 경우는, 파일의 독해를 어플리케이션내에서 실시해, 그 후 INSERT/UPDATE 스테이트먼트를 작성하고, 어플리케이션으로부터 데이타베이스에 파일의 내용을 써낼 필요가 있다.MySQL++ 라이브러리를 사용하고 있는 경우는, 이것을 실시하는 방법의 1 개를 http://www.mysql.com/documentation/mysql++/mysql++-examples.html 그리고 참조할 수 있다.

  • LOCATE(substr,str) , LOCATE(substr,str,pos)

    최초의 구문은, 문자열 str 에 최초로 출현하는 부분 문자열 substr 의 위치를 돌려준다. 2 번째의 구문은, 문자열 str 의 위치 pos 이?~ 에 최초로 출현하는 부분 문자열 substr 의 위치를 돌려준다. str 안에 substr 하지만 존재하지 않는 경우는 0 (을)를 돌려준다.

    mysql> SELECT LOCATE('bar', 'foobarbar');
        -> 4
mysql> SELECT LOCATE('xbar', 'foobar');
        -> 0
mysql> SELECT LOCATE('bar', 'foobarbar',5);
        -> 7
mysql> SELECT LOCATE('
네', '
만나 이식해 왕네');
        -> 4
mysql> SELECT LOCATE('
네', '
만나 이식해 왕네', 5);
        -> 7

    이 함수는 멀티 바이트 문자에 대응하고 있다. MySQL 3.23 그럼, 이 함수에서는 대문자와 소문자가 구별되지만(케이스 의존), 버젼 4.0 그럼, 어느 쪽인가의 인수가 바이너리 문자열의 경우에게만 케이스 의존이 된다.

  • LOWER(str)

    str 의 모든 문자를 현재의 캐릭터 세트(디폴트는 ISO-8859-1 Latin1 )의 매핑에 근거해 소문자로 변경한 문자열을 돌려준다.

    mysql> SELECT LOWER('QUADRATICALLY');
        -> 'quadratically'
mysql> SELECT LOWER('
만나 이식해');
        -> '
만나 이식해'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • LPAD(str,len,padstr)

    문자열 str 하지만 len (으)로 지정된 길이의 문자가 되도록,str 의 좌측으로 문자열 padstr (을)를 묻은 문자열을 돌려준다.str 하지만 len 보다 긴 경우는, 반환값은 len 의 길이의 문자로 줄일 수 있다.

    mysql> SELECT LPAD('hi',4,'??');
        -> '??hi'

#
버젼4.1
이상에서는 이하와 같이 됩니다.
mysql> SELECT LPAD('
아 말한다', 5 , 'X');
        -> 'XX
아 말한다'

#
버젼4.1
미만에서는 이하와 같이 됩니다.
mysql> SELECT LPAD('
아 말한다', 8 , 'X');
        -> 'XX
아 말한다'
mysql> SELECT LPAD('
아 말한다', 8 , '
');
        -> '
아 말한다'
mysql> SELECT LPAD('
아 말한다', 5 , 'X');
        -> '
사랑 ' ; #
주의.최후는1byte

  • LTRIM(str)

    문자열 str (으)로부터 선두의 스페이스 문자를 삭제한 문자열을 돌려준다.

    mysql> SELECT LTRIM('  barbar');
        -> '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(0,'a','b','c');
        -> ''

  • MID(str,pos,len)

    MID(str,pos,len) 하 SUBSTRING(str,pos,len) 의 동의어.

  • OCT(N)

    longlong 형태의 수치이다 N 의 8 진치의 문자열 표현을 돌려준다.이것은 CONV(N,10,8) (와)과 같다. N 하지만 NULL 때는 NULL (을)를 돌려준다.

    mysql> SELECT OCT(12);
        -> '14'

  • OCTET_LENGTH(str)

    OCTET_LENGTH() 하 LENGTH() 의 동의어.

  • ORD(str)

    문자열 str 의 좌단의 문자가 멀티 바이트 문자의 경우에, 다음의 식을 사용해 계산한, 그 문자를 구성하는 각 문자의 ASCII 코드치를 돌려준다.(( 최초의 아르바이트의 ASCII 코드)*256+(2 번째의 아르바이트의 ASCII 코드))[*256+3 번째의 아르바이트의 ASCII 코드...] 좌단의 문자가 멀티 바이트 문자가 아닐 때는,ASCII() 함수를 사용했을 경우와 같은 값을 돌려준다.

    mysql> SELECT ORD('2');
        -> 50
mysql> SELECT ORD('
아');
        -> 42146   ; #
주의 EUC-JP
코드로의 결과

  • POSITION(substr IN str)

    POSITION(substr IN str) 하 LOCATE(substr,str) 의 동의어.

  • QUOTE(str)

    지정된 문자열을,SQL 스테이트먼트로 올바른 이스케이프 데이터치로서 사용할 수 있도록 인용부호로 둘러싼 문자열을 돌려준다.결과의 문자열은 단일 인용부호로 둘러싸여 문자열내에 단일 인용부호(‘' ＇), backslash(‘\ ＇),ASCII NUL ,Control-Z 하지만 포함되어 있는 경우는 그 직전에 backslash가 삽입된다.인수가 NULL 의 경우는,``NULL'' 그렇다고 하는 말이 단일 인용부호로 둘러싸이지 않고 돌려주어진다. QUOTE() 함수는 MySQL 버젼 4.0.3 그리고 추가되었다.

    mysql> SELECT QUOTE("Don't");
        -> 'Don\'t!'
mysql> SELECT QUOTE(NULL);
        -> NULL

  • REPEAT(str,count)

    문자열 str (을)를,count (으)로 지정된 회수만 반복한 문자열을 돌려준다.count <= 0 의 경우는, 하늘의 문자열을 돌려준다.str 또는 count 하지만 NULL 의 경우는,NULL (을)를 돌려준다.

    mysql> SELECT REPEAT('MySQL', 3);
        -> 'MySQLMySQLMySQL'
mysql> SELECT REPEAT('
', 3);
        -> '
천민'

  • REPLACE(str,from_str,to_str)

    문자열 str 에 포함되는 문자열 from_str (을)를 모두 문자열 to_str 에 치환한 문자열을 돌려준다.

    mysql> SELECT REPLACE('www.mysql.com', 'w', 'Ww');
        -> 'WwWwWw.mysql.com'
mysql> SELECT REPLACE('
서로 만나 이식해', '
있어', '
');
        -> '
내일 내일 이식해'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • REVERSE(str)

    문자열 str 안의 문자의 순서를 반대로 한 문자열을 돌려준다.

    mysql> SELECT REVERSE('abc');
        -> 'cba'
mysql> SELECT REVERSE('
만나 이식해');
        -> '
있어 아'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • RIGHT(str,len)

    문자열 str 의 우단에 있는 길이 len 의 문자를 돌려준다.

    mysql> SELECT RIGHT('foobarbar', 4);
        -> 'rbar'
mysql> SELECT RIGHT('
만나 이식해', 4);
        -> '
말하는'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • RPAD(str,len,padstr)

    문자열 str 하지만 len (으)로 지정된 길이의 문자가 되도록,str 의 우측으로 문자열 padstr (을)를 묻은 문자열을 돌려준다.str 하지만 len 보다 긴 경우는, 반환값은 len 의 길이의 문자로 줄일 수 있다.

    mysql> SELECT RPAD('hi',5,'?');
        -> 'hi???'

#
버젼4.1
이상에서는 이하와 같이 됩니다.
mysql> SELECT RPAD('
사랑', 5, '
');
        -> '
사랑우우'

#
버젼4.1
미만에서는 이하와 같이 됩니다.
mysql> SELECT RPAD('
사랑', 5, 'X');
        -> '
사랑X'
mysql> SELECT RPAD('
사랑', 5, '
');
        -> '
사랑 '  ; #
주의:
최후는 멀티 바이트 문자의 상위1byte

  • RTRIM(str)

    문자열 str (으)로부터 후속의 스페이스 문자를 삭제한 문자열을 돌려준다.

    mysql> SELECT RTRIM('barbar   ');
        -> 'barbar'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • SOUNDEX(str)

    문자열 str 의 soundex 문자열을 돌려준다.발음이 닮았다 2 개의 문자열의 soundex 문자열은 같은 것이 된다.표준의 soundex 문자열의 길이는 4 문자이지만,SOUNDEX() 함수는 임의의 길이의 문자열을 돌려준다.돌려주어진 값에 대해서 SUBSTRING() (을)를 사용하면, 표준의 soundex 문자열을 얻을 수 있다.지정된 문자열내의 영숫자 이외의 문자는 무시된다.A ~ Z 의 범위외의 각국어의 알파벳 문자는 모두 모음으로서 다루어진다.

    mysql> SELECT SOUNDEX('Hello');
        -> 'H400'
mysql> SELECT SOUNDEX('Quadratically');
        -> 'Q36324'

  • expr1 SOUNDS LIKE expr2

    SOUNDEX(expr1)=SOUNDEX(expr2) (와)과 같다(버젼 4.1 이?~ 에서만 이용 가능).

  • SPACE(N)

    N (으)로 지정된 수의 스페이스 문자로 구성되는 문자열을 돌려준다.

    mysql> SELECT SPACE(6);
        -> '      '

  • SUBSTRING(str,pos) , SUBSTRING(str FROM pos) , SUBSTRING(str,pos,len) , SUBSTRING(str FROM pos FOR len)

    len 인수가 없는 형식의 경우는, 문자열 str 안의 위치 pos 이?~ 의 부분 문자열을 돌려준다. len 인수가 있는 형식의 경우는, 문자열 str 의 위치 pos 이?~ 의,len (으)로 지정된 길이의 부분 문자열을 돌려준다. FROM (을)를 사용하는 형식은 SQL-92 의 구문.

    mysql> SELECT SUBSTRING('Quadratically',5);
        -> 'ratically'
mysql> SELECT SUBSTRING('foobarbar' FROM 4);
        -> 'barbar'
mysql> SELECT SUBSTRING('Quadratically',5,6);
        -> 'ratica'
mysql> SELECT SUBSTRING('
만나 이식해 언덕 국화와', 5);
        -> '
언덕 국화와'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • SUBSTRING_INDEX(str,delim,count)

    문자열 str (으)로부터,delim (으)로 지정된 단락 기호의 count 개목의 출현 위치의 직전까지의 부분 문자열을 돌려준다. count (으)로 지정된 수가 정수의 경우는, (왼쪽에서 세어) 지정된 수의 마지막 단락 기호의 좌측에 있는 모든 문자를 돌려준다. count (으)로 지정된 수가 음수의 경우는, ( 오른쪽에서 세어) 지정된 수의 마지막 단락 기호의 우측에 있는 모든 문자를 돌려준다.

    mysql> SELECT SUBSTRING_INDEX('www.mysql.com', '.', 2);
        -> 'www.mysql'
mysql> SELECT SUBSTRING_INDEX('www.mysql.com', '.', -2);
        -> 'mysql.com'
mysql> SELECT SUBSTRING_INDEX('
사랑응 이식해 은혜나 나무', '
응', 2);
        -> '
사랑응 이식해'
mysql> SELECT SUBSTRING_INDEX('
사랑응 이식해 은혜나 나무', '
응', -2);
        -> '
이식해 은혜나 나무'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • TRIM([[BOTH | LEADING | TRAILING] [remstr] FROM] str)

    remstr (으)로 지정된 모든 프리픽스 또는 사픽스(혹은 그 양쪽 모두)를, 문자열 str (으)로부터 삭제한 문자열을 돌려준다.지정자 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'
mysql> SELECT TRIM(BOTH '
' FROM '
만나 이식해');
        -> '
사랑 위'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

  • UCASE(str)

    UCASE() 하 UPPER() 의 동의어.

  • UPPER(str)

    str 의 모든 문자를 현재의 캐릭터 세트(디폴트는 ISO-8859-1 Latin1 )의 매핑에 근거해 대문자로 변경한 문자열을 돌려준다.

    mysql> SELECT UPPER('Hej');
        -> 'HEJ'
mysql> SELECT UPPER('
에 있어');
        -> '
에 있어'

    이 함수는 멀티 바이트 문자에 대응하고 있다.

6.3.2.1. 문자열 비교 함수

MySQL 그럼, 필요에 따라서 수치로부터 문자열에의, 또 문자열로부터 수치에의 변환이 자동으로 행해집니다.

mysql> SELECT 1+"1";
        -> 2
mysql> SELECT CONCAT(2,' test');
        -> '2 test'

수치를 문자열에 명시적으로 변환하려면 , 대상의 수치를 인수로서 CONCAT() 에 건네줍니다.

문자열 함수의 인수로서 바이너리 문자열을 지정했을 경우, 돌려주어지는 문자열도 바이너리 문자열이 됩니다.문자열에 변환된 수치는 바이너리 문자열로서 다루어집니다.이것은 비교에게만 영향을 줍니다.

통상, 문자열의 비교로 몇개의 식이 케이스 의존의 경우, 비교는 케이스 의존 방식으로 실행됩니다.

  • expr LIKE pat [ESCAPE 'escape-char']

    SQL 의 단순한 정규 표현 비교를 사용한 패턴 매치.1 (TRUE ) 또는 0 (FALSE )(을)를 돌려준다.LIKE 그럼, 다음의 2 개의 와일드 카드 문자를 패턴내에서 사용할 수 있다.

    문자 설명
    % 임의의 수의 문자(제로 문자를 포함한다)와 일치한다.
    _ 엄밀하게 1 개의 문자와 일치한다.

    mysql> SELECT 'David!' LIKE 'David_';
        -> 1
mysql> SELECT 'David!' LIKE '%D%v%';
        -> 1

    와일드 카드 문자를 통상의 문자로서 취급하는 경우는, 직전에 이스케이프 문자를 붙인다.특정의 ESCAPE 문자를 지정하지 않으면‘\ ＇ (을)를 이스케이프 문자로서 사용하는 것으로 간주해진다.

    문자열 설명
    \% 1 개의 % 문자와 일치한다.
    \_ 1 개의 _ 문자와 일치한다.

    mysql> SELECT 'David!' LIKE 'David\_';
        -> 0
mysql> SELECT 'David_' LIKE 'David\_';
        -> 1

    다른 이스케이프 문자를 지정하는 경우는, 다음과 같이,ESCAPE 마디를 사용한다.

    mysql> SELECT 'David_' LIKE 'David|_' ESCAPE '|';
        -> 1

    다음의 2 개의 스테이트먼트는, 오퍼랜드의 어느 쪽인지 한편이 바이너리 문자열의 경우, 문자열의 비교가 케이스 의존 방식으로 행해지는 것을 나타내고 있다.

    mysql> SELECT 'abc' LIKE 'ABC';
        -> 1
mysql> SELECT 'abc' LIKE BINARY 'ABC';
        -> 0

    LIKE (은)는 수치식에서 사용할 수 있다(이것은 SQL-99 의 LIKE 에 대한다 MySQL 의 확장).

    mysql> SELECT 10 LIKE '1%';
        -> 1
mysql> SELECT '
있어 아' LIKE '%
있어%';
        -> 1
mysql> SELECT '
이아' LIKE '%
있어%';
        -> 0
#
주의： EUC-JP
코드로,'
이아'
하 0xA5A4A4A2
.'
있어'
하 0xA4A4
.

    주의:MySQL 그럼 문자열로 C 의 이스케이프 구문('\n' 등)을 사용하기 위해(때문에),LIKE 의 문자열에 ‘\ ＇ (을)를 삽입할 때는,2 배의 수의 ‘\ ＇ (을)를 사용할 필요가 있다.예를 들어,'\n' (을)를 검색하는 경우는,'\\n' (와)과 지정한다.또,‘\ ＇ (을)를 검색하는 경우는,'\\\\' (와)과 지정한다(backslash는 파서에 의해서 한 번 제거되어 패턴 매치의 실행시에 한번 더 제거된다.그리고, 남았다 1 개의 backslash가 매칭의 대상이 된다).

  • MATCH (col1,col2,...)AGAINST (expr [IN BOOLEAN MODE | WITH QUERY EXPANSION] )

    MATCH ... AGAINST() (은)는 풀텍스트 검색에 사용되어 컬럼 (col1,col2,...) 의 텍스트와 쿼리 expr 의 텍스트와의 관련성(유사도)을 돌려준다.관련성은 정의 부동 소수점수(실수)로 표현된다.관련성이 제로 때는, 유사성이 전혀 없는 것을 의미한다. MATCH ... AGAINST() 하 MySQL 버젼 3.23.23 이?~ 그리고 이용할 수 있다.IN BOOLEAN MODE 확장은 버젼 4.0.1 그리고 추가되어WITH QUERY EXPANSION 하 4.1.1 그리고 추가되었다. 상세 및 사용예에 대해서는, 항6.8. 「MySQL 풀텍스트 검색」 (을)를 참조.

  • expr NOT LIKE pat [ESCAPE 'escape-char']

    NOT (expr LIKE pat [ESCAPE 'escape-char']) (와)과 같다.

  • expr NOT REGEXP pat , expr NOT RLIKE pat

    NOT (expr REGEXP pat) (와)과 같다.

  • expr REGEXP pat , expr RLIKE pat

    패턴 pat 에 대한 문자열식 expr 의 패턴 매치를 실행한다.패턴으로서 확장 정규 표현을 사용할 수 있다. See 부록 G. MySQL 의 정규 표현 . expr 하지만 pat (와)과 매치하는 경우는 1 (을)를 돌려주어, 성냥 하지 않는 경우는 0 (을)를 돌려준다.RLIKE (은)는,mSQL (와)과의 호환성을 확보하기 위한 ,REGEXP 의 동의어. 주의:MySQL 그럼, 문자열로 C 의 이스케이프 구문('\n' 등)을 사용하기 위해(때문에),REGEXP 의 문자열에 ‘\ ＇ (을)를 삽입할 때는,2 배의 수의 ‘\ ＇ (을)를 사용할 필요가 있다. MySQL 버젼 3.23.4 이?~ 그럼,REGEXP (은)는 통상(비바이너리)의 문자열에 대해서는 케이스비의존.

    mysql> SELECT 'Monty!' REGEXP 'm%y%%';
        -> 0
mysql> SELECT 'Monty!' REGEXP '.*';
        -> 1
mysql> SELECT 'new*\n*line' REGEXP 'new\\*.\\*line';
        -> 1
mysql> SELECT "a" REGEXP "A", "a" REGEXP BINARY "A";
        -> 1  0
mysql> SELECT "a" REGEXP "^[a-d]";
        -> 1

    REGEXP (와)과 RLIKE 그럼, 현재의 캐릭터 세트(디폴트에서는 ISO-8859-1 Latin1 )에 근거해 문자의 형태가 결정된다.

  • STRCMP(expr1,expr2)

    STRCMP() 양쪽 모두의 문자열이 같은 것인 경우는 0 (을)를 돌려주어, 현재의 소트순서로 최초의 인수가 2 번째의 인수보다 작은 경우는 -1 (을)를 돌려주어, 그 이외의 경우는 -1 (을)를 돌려준다.

    mysql> SELECT STRCMP('text', 'text2');
        -> -1
mysql> SELECT STRCMP('text2', 'text');
        -> 1
mysql> SELECT STRCMP('text', 'text');
        -> 0

6.3.2.2. 케이스 의존성

  • BINARY

    BINARY 연산자는 이 연산자의 뒤에 계속 되는 문자열을 바이너리 문자열에 캐스트 한다. 이 연산자를 사용하면,BINARY 또는 BLOB (으)로서 정의되어 있지 않은 컬럼에 대해서도, 강제적으로 케이스 의존으로 한 컬럼의 비교를 간단하게 실시할 수 있다.

    mysql> SELECT "a" = "A";
        -> 1
mysql> SELECT BINARY "a" = "A";
        -> 0

    BINARY string 하 CAST(string AS BINARY) 의 생략형. See 항6.3.5. 「캐스트 함수」 . BINARY 하 MySQL 버젼 3.23.0 그리고 도입되었다.

    주의: MySQL 의 일부의 문맥에서는, 인덱스 첨부의 컬럼을 BINARY 에 캐스트 하면, 인덱스를 효율적으로 사용할 수 없게 된다.

BLOB 형태의 문자열을 케이스비의존 방식으로 비교할 필요가 있는 경우는, 비교의 실행전에 BLOB (으)로부터 대문자로 변환하는 것에 의해서, 항상 이 비교가 가능하게 됩니다.

SELECT 'A' LIKE UPPER(blob_col) FROM table_name;

곧, 다른 캐릭터 세트간의 캐스트를 도입할 예정입니다.이 도입에 의해서, 문자열의 비교를 한층 더 유연하게 실행할 수 있게 됩니다.

6.3.3. 수치 함수

6.3.3.1. 산술 연산

통상의 산술 연산자를 이용할 수 있습니다.주의: ‘- ＇,‘+ ＇,‘* ＇ 그리고, 양쪽 모두의 인수가 정수의 경우, 결과는 BIGINT (64 비트)의 정도로 계산됩니다. 어느 쪽인지 한편의 인수가 부호 없음의 정수로, 이제(벌써) 한편도 정수의 경우, 결과는 부합 없음의 정수가 됩니다. See 항6.3.5. 「캐스트 함수」 .

  • +

    가산

    mysql> SELECT 3+5;
        -> 8

  • -

    감산

    mysql> SELECT 3-5;
        -> -2

  • *

    곱셈

    mysql> SELECT 3*5;
        -> 15
mysql> SELECT 18014398509481984*18014398509481984.0;
        -> 324518553658426726783156020576256.0
mysql> SELECT 18014398509481984*18014398509481984;
        -> 0

    마지막 식의 결과는 올바르지 않다.이것은, 이 정수 곱셈의 결과가 BIGINT 계산의 64 비트의 범위를 넘기 위해.

  • /

    제산

    mysql> SELECT 3/5;
        -> 0.60

    제로로 나누면 결과는 NULL (이)가 된다.

    mysql> SELECT 102/(1-1);
        -> NULL

    제산이 BIGINT 연산으로 계산되는 것은, 결과가 정수에 변환되는 문맥으로 그 연산이 실행되었을 경우에 한정된다.

6.3.3.2. 수학 함수

모든 수학 함수는 에러의 경우 NULL (을)를 돌려줍니다.

  • -

    단항 마이너스.인수의 부호를 변경한다.

    mysql> SELECT - 2;
        -> -2

    주의: BIGINT 형태의 값에 대해서 이 연산자를 사용하면, 반환값은 BIGINT (이)가 된다.따라서, 값이 -2^63 (이)가 될 가능성이 있는 정수에 대해서는 - 의 사용을 피한다.

  • ABS(X)

    X 의 절대치를 돌려준다.

    mysql> SELECT ABS(2);
        -> 2
mysql> SELECT ABS(-32);
        -> 32

    이 함수는 BIGINT 형태의 값에 대해서 사용해도 문제 없다.

  • ACOS(X)

    X 의 아크 코사인(즉, 코사인이 X 인 값)을 돌려준다.X 하지만 -1 (으)로부터 1 의 범위에 없을 때는 NULL (을)를 돌려준다.

    mysql> SELECT ACOS(1);
        -> 0.000000
mysql> SELECT ACOS(1.0001);
        -> NULL
mysql> SELECT ACOS(0);
        -> 1.570796

  • ASIN(X)

    X 의 아크 싸인(즉, 싸인이 X 인 값)을 돌려준다.X 하지만 -1 ~ 1 의 범위에 없을 때는 NULL (을)를 돌려준다.

    mysql> SELECT ASIN(0.2);
        -> 0.201358
mysql> SELECT ASIN('foo');
        -> 0.000000

  • ATAN(X)

    X 의 arctangent(즉, 탄젠트가 X 인 값)을 돌려준다.

    mysql> SELECT ATAN(2);
        -> 1.107149
mysql> SELECT ATAN(-2);
        -> -1.107149

  • ATAN(Y,X) , ATAN2(Y,X)

    2 개의 변수 X (와)과 Y 의 arctangent를 돌려준다.이것은 Y / X 에 의한 arctangent의 계산과 닮아 있지만, 다른 점으로서 이 경우, 양쪽 모두의 인수의 부호에 근거해 결과의 4분?~ 하지만 결정된다.

    mysql> SELECT ATAN(-2,2);
        -> -0.785398
mysql> SELECT ATAN2(PI(),0);
        -> 1.570796

  • CEILING(X) , CEIL(X)

    X 이상의 가장 작은 정수치를 돌려준다.

    mysql> SELECT CEILING(1.23);
        -> 2
mysql> SELECT CEIL(-1.23);
        -> -1

    CEIL() 앨리어스(alias)는 버젼 4.0.6 그리고 추가되었다.

    주의: 반환값은 BIGINT 에 변환된다.

  • COS(X)

    X (라디안)의 코사인을 돌려준다.

    mysql> SELECT COS(PI());
        -> -1.000000

  • COT(X)

    X 의 코탄젠트를 돌려준다.

    mysql> SELECT COT(12);
        -> -1.57267341
mysql> SELECT COT(0);
        -> NULL

  • CRC32(expr)

    순회 장황 검사치를 계산해,32 비트의 부호 없음의 값을 돌려준다. 인수가 NULL 의 경우, 결과는 NULL (이)가 된다.인수에서는, 문자열의 지정이 전제가 된다.문자열 이외의 값을 지정해도, 문자열로서 다루어진다.

    mysql> SELECT CRC32('MySQL');
        -> 3259397556

    CRC32() 하 MySQL 4.1.0 이?~ 그리고 이용할 수 있다.

  • DEGREES(X)

    인수 X (을)를 라디안으로부터 번으로 변환해 돌려준다.

    mysql> SELECT DEGREES(PI());
        -> 180.000000

  • DIV

    정수의 제산. FLOOR() (와)과 같이.다만,BIGINT 형태의 값에 대응하고 있다.

    mysql> SELECT 5 DIV 2
        -> 2

    DIV 하 MySQL 4.1.0 의 신기능.

  • EXP(X)

    e (자연대수의 바닥)(을)를 X 승 한 값을 돌려준다.

    mysql> SELECT EXP(2);
        -> 7.389056
mysql> SELECT EXP(-2);
        -> 0.135335

  • FLOOR(X)

    X 이하의 가장 큰 정수치를 돌려준다.

    mysql> SELECT FLOOR(1.23);
        -> 1
mysql> SELECT FLOOR(-1.23);
        -> -2

    주의: 반환값은 BIGINT 에 변환된다.

  • GREATEST(X,Y,...)

    가장 큰(즉, 가장 큰 값을 지정된) 인수를 돌려준다. 각 인수의 비교는 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"

    버젼 3.22.5 보다 전의 MySQL 그럼,GREATEST 대신에 MAX() (을)를 사용할 수 있다.

  • LEAST(X,Y,...)

    지정되었다 2 개이상의 인수 중(안)에서, 가장 작은(즉, 가장 작은 값을 지정된) 인수를 돌려준다. 각 인수의 비교는, 다음의 규칙에 근거해 행해진다.

    • 반환값이 INTEGER 의 문맥으로 사용되는 경우, 또는 모든 인수에 정수치가 지정되어 있는 경우는, 각 인수는 정수로서 비교된다.

    • 반환값이 REAL 의 문맥으로 사용되는 경우, 또는 모든 인수에 실수가 지정되어 있는 경우는, 각 인수는 실수로서 비교된다.

    • 몇개의 인수가 케이스 의존 문자열인 경우는, 각 인수는 케이스 의존 문자열로서 비교된다.

    • 그 외의 경우, 인수는 케이스비의존 문자열로서 비교된다.

    mysql> SELECT LEAST(2,0);
        -> 0
mysql> SELECT LEAST(34.0,3.0,5.0,767.0);
        -> 3.0
mysql> SELECT LEAST("B","A","C");
        -> "A"

    버젼 3.22.5 보다 전의 MySQL 그럼,LEAST 대신에 MIN() (을)를 사용할 수 있다.

  • LN(X)

    X 의 자연대수를 돌려준다.

    mysql> SELECT LN(2);
        -> 0.693147
mysql> SELECT LN(-2);
        -> NULL

    이 함수는 MySQL 버젼 4.0.3 그리고 추가되었다. MySQL 에 있어서의 LOG(X) 의 동의어.

  • LOG(X) , LOG(B,X)

    파라미터 1 개로 불려 갔을 경우, 이 함수는 X 의 자연대수를 돌려준다.

    mysql> SELECT LOG(2);
        -> 0.693147
mysql> SELECT LOG(-2);
        -> NULL

    파라미터 2 개로 불려 갔을 경우, 이 함수는 임의의 바닥 B 에 대한다 X 의 자연대수를 돌려준다.

    mysql> SELECT LOG(2,65536);
        -> 16.000000
mysql> SELECT LOG(1,100);
        -> NULL

    임의의 바닥을 지정할 수 있는 옵션은 MySQL 버젼 4.0.3 그리고 추가되었다. LOG(B,X) 하 LOG(X)/LOG(B) (와)과 같다.

  • LOG2(X)

    2 (을)를 바닥으로 한다 X 의 자연대수를 돌려준다.

    mysql> SELECT LOG2(65536);
        -> 16.000000
mysql> SELECT LOG2(-100);
        -> NULL

    LOG2() (은)는, 특정의 수치의 격납에 몇 비트 필요한가 조사하는데 도움이 된다. 이 함수는 MySQL 버젼 4.0.3 그리고 추가되었다. 그것보다 전의 버젼에서는, 대신에 LOG(X)/LOG(2) (을)를 사용할 수 있다.

  • LOG10(X)

    10 (을)를 바닥으로 한다 X 의 자연대수를 돌려준다.

    mysql> SELECT LOG10(2);
        -> 0.301030
mysql> SELECT LOG10(100);
        -> 2.000000
mysql> SELECT LOG10(-100);
        -> NULL

  • MOD(N,M) , %

    모듈로(C 의 % 연산자에 비슷하다). N (을)를 M 그리고 나누었을 때의 나머지를 돌려준다.

    mysql> SELECT MOD(234, 10);
        -> 4
mysql> SELECT 253 % 7;
        -> 1
mysql> SELECT MOD(29,9);
        -> 2
mysql> SELECT 29 MOD 9;
        -> 2

    이 함수는 BIGINT 형태의 값에 사용해도 문제 없다. 마지막 예는 MySQL 4.1 에서만 유효.

  • PI()

    π 의 값을 돌려준다.소수부의 표시 자리수는 디폴트로 5 자리수이지만,MySQL 의 내부에서는,π 에 완전한 배정도가 사용된다.

    mysql> SELECT PI();
        -> 3.141593
mysql> SELECT PI()+0.000000000000000000;
        -> 3.141592653589793116

  • POW(X,Y) , POWER(X,Y)

    X (을)를 Y 승 한 값을 돌려준다.

    mysql> SELECT POW(2,2);
        -> 4.000000
mysql> SELECT POW(2,-2);
        -> 0.250000

  • RADIANS(X)

    인수 X (을)를 번으로부터 라디안으로 변환해 돌려준다.

    mysql> SELECT RADIANS(90);
        -> 1.570796

  • RAND() , RAND(N)

    0 ~ 1.0 의 범위의 랜덤인 부동 소수점수(실수)를 돌려준다. 정수의 인수 N 하지만 지정되었을 경우, 그 정수가 배정치(반복해 가능한 수열을 생성)로서 사용된다.

    mysql> SELECT RAND();
        -> 0.9233482386203
mysql> SELECT RAND(20);
        -> 0.15888261251047
mysql> SELECT RAND(20);
        -> 0.15888261251047
mysql> SELECT RAND();
        -> 0.63553050033332
mysql> SELECT RAND();
        -> 0.70100469486881

    ORDER BY 마디에서는 컬럼이 여러 차례 평가되기 위해,RAND() 의 값을 포함한 컬럼은,ORDER BY 마디에서는 사용할 수 없다. 그러나, 버젼 3.23 이?~ 그럼,SELECT * FROM table_name ORDER BY RAND() (을)를 사용할 수 있다.

    이것은,SELECT * FROM table1,table2 WHERE a=b AND c<d ORDER BY RAND() LIMIT 1000 세트로부터 랜덤인 샘플을 얻는데 도움이 된다.

    주의: WHERE 마디의 RAND() (은)는,WHERE 하지만 실행될 때마다 재평가된다.

    RAND() (은)는 완전한 난수 제네레이터가 아니고, 오히려 같다 MySQL 버젼의 플랫폼간에 이식 가능한 난수를 수시, 재빠르게 생성하기 위한 방법으로서 이용할 수 있다.

  • ROUND(X) , ROUND(X,D)

    인수 X (을)를 가장 가까운 정수에 만 값을 돌려준다. 인수가 2 개의 형식에서는, 소수부의 자리수를 D (으)로 지정된 자리수에 말다.

    mysql> SELECT ROUND(-1.23);
        -> -1
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

    주의: 인수의 값이 2 개의 정수의 중간에 있는 경우의 ROUND() 의 동작은,C 라이브러리의 실장에 따라 정해진다.실장에 따르고, 가장 가까운 짝수에 말 수 있는 경우와 항상 끝맺어 또는 인하할 수 있는 경우, 혹은 항상 제로 방향으로 둥근 경우가 있다.특정의 둥근 방법을 필요로 하는 경우는, 이 함수가 아니고,TRUNCATE() (이)나 FLOOR() 등이 명확하게 정의된 함수를 사용하도록(듯이) 한다.

  • SIGN(X)

    X 하지만 음수인가, 제로인가, 정수인가에 따르고, 이 인수의 부호를 -1 ,0 , 또는 1 (으)로서 돌려준다.

    mysql> SELECT SIGN(-32);
        -> -1
mysql> SELECT SIGN(0);
        -> 0
mysql> SELECT SIGN(234);
        -> 1

  • SIN(X)

    X (라디안)의 싸인을 돌려준다.

    mysql> SELECT SIN(PI());
        -> 0.000000

  • SQRT(X)

    X 의 음수가 아닌 평방근을 돌려준다.

    mysql> SELECT SQRT(4);
        -> 2.000000
mysql> SELECT SQRT(20);
        -> 4.472136

  • TAN(X)

    X (라디안)의 탄젠트를 돌려준다.

    mysql> SELECT TAN(PI()+1);
        -> 1.557408

  • TRUNCATE(X,D)

    수치 X 의 소수부를 D (으)로 지정된 자리수에 버린 값을 돌려준다.D 하지만 0 의 경우, 결과의 값은 소수점도 소수부도 가지지 않는다.

    mysql> SELECT TRUNCATE(1.223,1);
        -> 1.2
mysql> SELECT TRUNCATE(1.999,1);
        -> 1.9
mysql> SELECT TRUNCATE(1.999,0);
        -> 1
mysql> SELECT TRUNCATE(-1.999,1);
        -> -1.9

    MySQL 3.23.51 이?~ , 모든 수치는 제로 방향으로 말 수 있다.

    D 하지만 음수의 경우, 그 수치의 소수부 이외의 부분도 제로가 된다.

    mysql> SELECT TRUNCATE(122,-2);
       -> 100

    주의: 소수는 통상, 정확한 수치로서가 아니고, 배정도의 값으로 해서 컴퓨터에 격납되기 위해, 다음과 같은 이상한 결과가 나오는 일이 있다.

    mysql> SELECT TRUNCATE(10.28*100,0);
       -> 1027

    이것은,10.28 하지만 실제로는 10.2799999999999999 (와)과 같은 값으로 해서 격납되는 것에 의해서 발생한다.

6.3.4. 일자와 시각 함수

이 섹션에서는, 시간에 관계하는 값의 조작에 사용할 수 있는 함수에 대해 설명합니다. 일자와 시각의 각 데이터형의 범위와 값을 지정할 때의 유효한 형식에 대해서는, 항6.2.2. 「일자와 시각형」 (을)를 참조해 주세요.

일자 함수의 사용예를 다음에 나타냅니다.이 쿼리에서는, 과거 30 일 이내의 일자의 date_col 값을 가지는 모든 레코드가 선택됩니다.

mysql> SELECT something FROM tbl_name
           WHERE TO_DAYS(NOW()) - TO_DAYS(date_col) <= 30;

(이 쿼리에서는, 장래의 일자를 가지는 레코드도 선택됩니다.)

일자치를 전제로 하는 함수는, 통상, 일자 시각치를 받아 들이고, 시각 부분을 무시합니다.시각치를 전제로 하는 함수는, 통상, 일자 시각치를 받아 들이고, 일자 부분을 무시합니다.

현재의 일자 또는 시각을 각각 돌려주는 함수는, 쿼리 마다, 그 쿼리의 개시시에 1 회만 평가됩니다.따라서,1 개의 쿼리내에서 NOW() 등의 함수를 몇번이나 참조해도, 항상 같은 결과가 됩니다.이 원칙은,CURDATE() ,CURTIME() ,UTC_DATE() ,UTC_TIME() ,UTC_TIMESTAMP() , 및 이러한 모든 동의어에와 같이 적용됩니다.

이하의 함수의 설명으로 나타내 보이고 있는 반환값의 범위는, 완전한 일자에 대해서 적용됩니다.일자가 `` 제로'' 값이거나'2001-11-00' 등이 불완전한 일자인 경우, 일자의 일부를 꺼내는 함수에서는 0 하지만 돌아갑니다.예를 들어,DAYOFMONTH('2001-11-00') 에서는 0 하지만 돌아갑니다.

  • ADDDATE(date,INTERVAL expr type) , ADDDATE(expr,days)

    2 번째의 인수의 INTERVAL (을)를 지정하는 형식에서 호출했을 경우,ADDDATE() 하 DATE_ADD() (이)라고 동의어가 된다.관련하는 함수 SUBDATE() 하 DATE_SUB() 의 동의어.

    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'

    2 번째의 구문은 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.expr 에는 일자식이나 일자 시각식을 지정해,days 에는 expr 에 가세하는 날짜를 지정한다.

    mysql> SELECT ADDDATE('1998-01-02', 31);
        -> '1998-02-02'

  • ADDTIME(expr,expr2)

    ADDTIME() 그럼,expr 에 expr2 (을)를 더한 결과가 돌려주어진다. expr 에는 일자식이나 일자 시각식을 지정해,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'

    ADDTIME() 하 MySQL 4.1.1 그리고 추가되었다.

  • 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

  • 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'

    DATE() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • DATEDIFF(expr,expr2)

    DATEDIFF() (은)는 개시일 expr (와)과 종료일 expr2 (와)과의 사이의 날짜를 돌려준다. expr (와)과 expr2 에는, 일자식인가, 일자 시각식을 지정한다. 계산은 값의 일자 부분에만 기초를 두어 행해진다.

    mysql> SELECT DATEDIFF('1997-12-31 23:59:59','1997-12-30');
        -> 1
mysql> SELECT DATEDIFF('1997-11-31 23:59:59','1997-12-31');
        -> -30

    DATEDIFF() 하 MySQL 4.1.1 그리고 추가되었다.

  • DATE_ADD(date,INTERVAL expr type) , DATE_SUB(date,INTERVAL expr type)

    이러한 함수에서는 일자 연산이 실행된다.

    MySQL 버젼 3.23 이?~ 그럼,+ 연산자의 어느 쪽인가의 측에INTERVAL expr type (을)를 사용할 수 있다.이 경우, 이제(벌써) 한편의 옆의 식에는 일자치 또는 일자 시각치를 지정한다. - 연산자를 사용하는 경우는, 연산자의 우측에게만 INTERVAL expr type (을)를 사용할 수 있다.이것은, 일자치 또는 일자 시각치를 간격으로부터 공제해도 의미가 없기 때문에(아래의 예를 참조).

    date 에는, 개시일로 한다 DATETIME 또는 DATE 값을 지정한다.expr 에는, 개시일에 가세한다, 또는 개시일부터 공제하는 간격치를 나타내는 식을 문자열로서 지정한다.선두에 ‘- ＇ (을)를 붙여 부의 간격을 나타낼 수도 있다.type 에는, 식의 해석 방법을 나타내는 키워드를 지정한다.

    다음의 겉(표)에,type 인수와 expr 인수가 어떻게 관련하는지를 나타낸다.

    type 치 | 전제가 된다 expr 의 형식
    SECOND | SECONDS
    MINUTE | MINUTES
    HOUR | HOURS
    DAY | DAYS
    MONTH | MONTHS
    YEAR | YEARS
    MINUTE_SECOND | 'MINUTES:SECONDS'
    HOUR_MINUTE | 'HOURS:MINUTES'
    DAY_HOUR | 'DAYS HOURS'
    YEAR_MONTH | 'YEARS-MONTHS'
    HOUR_SECOND | 'HOURS:MINUTES:SECONDS'
    DAY_MINUTE | 'DAYS HOURS:MINUTES'
    DAY_SECOND | 'DAYS HOURS:MINUTES:SECONDS'
    DAY_MICROSECOND | 'DAYS.MICROSECONDS'
    HOUR_MICROSECOND | 'HOURS.MICROSECONDS'
    MINUTE_MICROSECOND | 'MINUTES.MICROSECONDS'
    SECOND_MICROSECOND | 'SECONDS.MICROSECONDS'
    MICROSECOND | 'MICROSECONDS'

    type 치 DAY_MICROSECOND ,HOUR_MICROSECOND ,MINUTE_MICROSECOND ,SECOND_MICROSECOND ,MICROSECOND (은)는,MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

    MySQL 그럼,expr 의 형식에서 임의의 구두점 기호를 사용할 수 있다. 위의 겉(표)에서는, 이러한 구두점 기호의 일부를 나타내고 있다.date 인수에 DATE 형태의 값을 지정해, 계산에 YEAR ,MONTH ,DAY 부분만을 짜넣는(즉, 시각 부분은 포함하지 않는다) 경우, 결과는 DATE 형태의 값이 된다.그 이외의 경우,DATETIME 형태의 값이 돌려주어진다.

    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'
mysql> SELECT DATE_ADD('1997-12-31 23:59:59',
    ->                 INTERVAL 1 DAY);
        -> '1998-01-01 23:59:59'
mysql> SELECT DATE_ADD('1997-12-31 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'
mysql> SELECT DATE_ADD('1998-01-01 00:00:00',
    ->                 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> SELECT DATE_ADD('1992-12-31 23:59:59.000002',
    ->                 INTERVAL '1.999999' SECOND_MICROSECOND);
        -> '1993-01-01 00:00:01.000001'

    지정한 간격치가 너무 짧은 경우(즉,type 키워드에 의해서 상정되는 간격 부분의 일부를 포함하지 않은 경우),MySQL 그럼, 간격치의 좌단의 부분이 없다고 보인다.예를 들어,type (을)를 DAY_SECOND (으)로서 지정하면,expr 의 값은, 일, 시, 분, 초의 각부로 구성되면 상정된다.이 경우,'1:10' (와)과 같은 값을 지정하면, 값은 일 부분과 시간 부분을 가지지 않고, 분으로 초를 나타낸다고 해석된다.즉,'1:10' DAY_SECOND (와)과 지정했을 경우,'1:10' MINUTE_SECOND (와)과 지정했을 경우와 같이 해석되게 된다.이것은,MySQL 그리고 TIME 값이 1 일의 시각은 아니고 경과시간으로서 해석되는데 비슷하다.

    주의：시각 부분을 가지는 값을 일자치에 가세하거나 일자값으로부터 공제하거나 하면, 결과는 자동적으로 일자 시각형의 값에 변환된다.

    mysql> SELECT DATE_ADD('1999-01-01', INTERVAL 1 DAY);
        -> '1999-01-02'
mysql> SELECT DATE_ADD('1999-01-01', INTERVAL 1 HOUR);
        -> '1999-01-01 01:00:00'

    잘못된 일자를 사용하면, 결과는 NULL (이)가 된다.MONTH ,YEAR_MONTH ,YEAR 의 어느쪽이든을 더한 결과의 일자가, 새로운 달의 최대 날짜보다 큰 경우, 새로운 달의 최대 날짜에 조정된다.

    mysql> SELECT DATE_ADD('1998-01-30', interval 1 month);
        -> '1998-02-28'

    주의: 상기의 예로, 키워드 INTERVAL (와)과 type 지정자는 케이스비의존.

  • DATE_FORMAT(date,format)

    format 문자열에 맞추고,date 값을 형식 설정한다.format 문자열에서는, 다음의 지정자를 사용할 수 있다.

    지정자 | 설명
    %M | 달의 이름(January..December ).
    %W | 요일명(Sunday..Saturday ).
    %D | 영어의 사픽스 첨부의 일자(0th ,1st ,2nd ,3rd 등).
    %Y | 4 자리수의 수치로 나타낸 해.
    %y | 2 자리수의 수치로 나타낸 해.
    %X | 일요일을 주의 첫날로 했을 경우의 주에 사용하는,4 자리수의 수치로 나타낸 해.%V (와)과 조합해 사용.
    %x | 월요일을 주의 첫날로 했을 경우의 주에 사용하는,4 자리수의 수치로 나타낸 해.%v (와)과 조합해 사용.
    %a | 약식의 요일명(Sun..Sat ).
    %d | 수치로 나타낸 일자(00..31 ).
    %e | 수치로 나타낸 일자(0..31 ).
    %m | 수치로 나타낸 달(00..12 ).
    %c | 수치로 나타낸 달(0..12 ).
    %b | 약식의 월명(Jan..Dec ).
    %j | 연간을 통한 날(001..366 ).
    %H | 때(00..23 ).
    %k | 때(0..23 ).
    %h | 때(01..12 ).
    %I | 때(01..12 ).
    %l | 때(1..12 ).
    %i | 수치로 나타낸 만큼(00..59 ).
    %r | 12 시간 형식의 시각(hh:mm:ss 에 이어 AM 또는 PM ).
    %T | 24 시간 형식의 시각(hh:mm:ss ).
    %S | 초(00..59 ).
    %s | 초(00..59 ).
    %f | 마이크로 세컨드(000000..999999 ).
    %p | AM 또는 PM
    %w | 요일(0=Sunday..6=Saturday ).
    %U | 일요일을 주의 첫날로 했을 경우의 주(00..53 ).
    %u | 월요일을 주의 첫날로 했을 경우의 주(00..53 ).
    %V | 일요일을 주의 첫날로 했을 경우의 주(01..53 ).%X (와)과 조합해 사용.
    %v | 월요일을 주의 첫날로 했을 경우의 주(01..53 ).%x (와)과 조합해 사용.
    %% 리터럴의 ‘% ＇.

    그 외의 문자는 모두, 해석되지 않고 그대로 결과에 카피된다.

    %f 형식 지정자는 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

    MySQL 버젼 3.23 이?~ 그럼, 형식 지정자 문자의 전에 ‘% ＇ 문자를 삽입할 필요가 있다.그것보다 전의 버젼의 MySQL 그럼,‘% ＇ 의 사용은 임의.

    달과 일의 지정자의 범위가 제로로부터 시작되어 있는 이유는,MySQL 3.23 이?~ 그럼,'2004-00-00' (와)과 같이 불완전한 일자의 격납이 허용 되기 위해.

    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> 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'

  • DAY(date)

    DAY() 하 DAYOFMONTH() 의 동의어. MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • DAYNAME(date)

    date (으)로 지정된 일자의 요일명을 돌려준다.

    mysql> SELECT DAYNAME('1998-02-05');
        -> 'Thursday'

  • DAYOFMONTH(date)

    date (으)로 지정된 일자에 대해,1 ~ 31 의 범위의 날을 돌려준다.

    mysql> SELECT DAYOFMONTH('1998-02-03');
        -> 3

  • DAYOFWEEK(date)

    date 의 요일 인덱스(1 = 일요일,2 = 월요일,... 7 = 토요일)을 돌려준다.이러한 인덱스치는 ODBC 표준에 대응하고 있다.

    mysql> SELECT DAYOFWEEK('1998-02-03');
        -> 3

  • DAYOFYEAR(date)

    date (으)로 지정된 일자에 대해,1 ~ 366 의 범위의 연간을 통한 날을 돌려준다.

    mysql> SELECT DAYOFYEAR('1998-02-03');
        -> 34

  • EXTRACT(type 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_DAYS() 그럼, 태양력(1582 해)보다 전의 값의 지정은 상정하고 있지 않다.이것은, 달력이 변경되었을 때에 없어진 날짜가 고려되지 않기 때문이다.

  • FROM_UNIXTIME(unix_timestamp) , FROM_UNIXTIME(unix_timestamp,format)

    문자열과 수치의 어느 쪽의 문맥으로 사용되고 있을까에 따르고,unix_timestamp 의 값을 'YYYY-MM-DD HH:MM:SS' 또는 YYYYMMDDHHMMSS 형식에서 돌려준다.

    mysql> SELECT FROM_UNIXTIME(875996580);
        -> '1997-10-04 22:23:00'
mysql> SELECT FROM_UNIXTIME(875996580) + 0;
        -> 19971004222300

    format (을)를 지정했을 경우, 결과는 format 문자열에 근거해 형식 설정된다.format 에는,DATE_FORMAT() 함수의 입력치와 같은 지정자를 짜넣을 수 있다.

    mysql> SELECT FROM_UNIXTIME(UNIX_TIMESTAMP(),
    ->                      '%Y %D %M %h:%i:%s %x');
        -> '2003 6th August 06:22:58 2003'

  • GET_FORMAT(DATE | TIME | TIMESTAMP, 'EUR' | 'USA' | 'JIS' | 'ISO' | 'INTERNAL')

    포맷의 문자열을 돌려준다.이 함수는,DATE_FORMAT() 함수나 STR_TO_DATE() 함수로 조합해 사용하거나 서버 변수 DATE_FORMAT ,TIME_FORMAT ,DATETIME_FORMAT (을)를 설정하거나 할 경우에 도움이 된다.최초의 인수에는 3 개의 입력 가능치가 있어,2 번째의 인수에는 5 개의 입력 가능치가 있기 위해, 결과적으로 돌려주어지는 포맷 문자열은 전부 15 가지 있다(사용되는 지정자에 대해서는,DATE_FORMAT() 함수의 설명에 포함되어 있는 표를 참조).

    함수 호출 | 결과
    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(TIMESTAMP,'USA') | '%Y-%m-%d-%H.%i.%s'
    GET_FORMAT(TIMESTAMP,'JIS') | '%Y-%m-%d %H:%i:%s'
    GET_FORMAT(TIMESTAMP,'ISO') | '%Y-%m-%d %H:%i:%s'
    GET_FORMAT(TIMESTAMP,'EUR') | '%Y-%m-%d-%H.%i.%s'
    GET_FORMAT(TIMESTAMP,'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'

    ISO 형식은 ISO 8601 (이)가 아니고,ISO 9075 .

    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
mysql> SET DATE_FORMAT=GET_FORMAT(DATE, 'USA'); SELECT '2003-10-31';
        -> 10-31-2003

    GET_FORMAT() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다. See 항5.5.6. 「SET 구문」 (을)를 참조.

  • HOUR(time)

    time (으)로 지정된 시각의 시간 부분의 값을 돌려준다.반환값의 범위는,1 일의 시간을 나타내는 값의 경우는 0 (으)로부터 23 .

    mysql> SELECT HOUR('10:05:03');
        -> 10

    그러나,TIME 값의 범위는, 실제로는 이것보다 훨씬 넓기 때문에,23 보다 큰 값이 HOUR (으)로서 돌아가는 일이 있다.

    mysql> SELECT HOUR('272:59:59');
        -> 272

  • LAST_DAY(date)

    지정된 일자 또는 일자 시각의 값에 대해, 그 값이 포함되는 달의 마지막 날을 돌려준다.인수가 무효인 경우는,NULL (을)를 돌려준다.

    mysql> SELECT LAST_DAY('2003-02-05'), LAST_DAY('2004-02-05');
        -> '2003-02-28', '2004-02-29'
mysql> SELECT LAST_DAY('2004-01-01 01:01:01');
        -> '2004-01-31'
mysql> SELECT LAST_DAY('2003-03-32');
        -> NULL

    LAST_DAY() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • LOCALTIME , LOCALTIME()

    LOCALTIME (와)과 LOCALTIME() 하 NOW() 의 동의어.

  • LOCALTIMESTAMP , LOCALTIMESTAMP()

    LOCALTIMESTAMP (와)과 LOCALTIMESTAMP() 하 NOW() 의 동의어.

  • MAKEDATE(year,dayofyear)

    지정된 해의 값과 연간을 통한 날의 값에 대응하는 일자를 돌려준다. dayofyear 에는,0 보다 큰 값을 지정할 필요가 있다.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

    MAKEDATE() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • MAKETIME(hour,minute,second)

    인수 hour ,minute ,second (으)로 지정된 값으로부터 계산한 시각치를 돌려준다.

    mysql> SELECT MAKETIME(12,15,30);
        -> '12:15:30'

    MAKETIME() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • MICROSECOND(expr)

    시각식 또는 일자 시각식 expr (으)로부터 마이크로 세컨드를,0 ~ 999999 의 범위내의 수치로서 돌려준다.

    mysql> SELECT MICROSECOND('12:00:00.123456');
        -> 123456
mysql> SELECT MICROSECOND('1997-12-31 23:59:59.000010');
        -> 10

    MICROSECOND() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • MINUTE(time)

    time (으)로 지정된 시각의 분을,0 ~ 59 의 범위의 값으로 해서 돌려준다.

    mysql> SELECT MINUTE('98-02-03 10:05:03');
        -> 5

  • MONTH(date)

    date (으)로 지정된 일자의 달을,1 ~ 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();
        -> '1997-12-15 23:50:26'
mysql> SELECT NOW() + 0;
        -> 19971215235026

  • PERIOD_ADD(P,N)

    N (으)로 지정된 월수를 기간 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> SELECT PERIOD_DIFF(9802,199703);
        -> 11

  • QUARTER(date)

    date (으)로 지정된 일자에 대응하는 4분기를,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 (을)를 취해,DATETIME 형태의 값을 돌려준다.

    str (으)로 지정한 일자, 시각, 또는 일자 시각의 값이,format (으)로 지정한 형식에서 돌려주어진다.format 에 사용할 수 있는 지정자에 대해서는,DATE_FORMAT() 함수의 설명에 있는 표를 참조.다른 문자는 모두, 해석되지 않고 문자 대로 수취된다. str 에 잘못된 일자, 시각, 또는 일자 시각이 포함되어 있는 경우,STR_TO_DATE() 하 NULL (을)를 돌려준다.

mysql> SELECT STR_TO_DATE('03.10.2003 09.20', '%d.%m.%Y %H.%i')
        -> 2003-10-03 09:20:00
mysql> SELECT STR_TO_DATE('10rap', '%crap')
        -> 0000-10-00 00:00:00
mysql> SELECT STR_TO_DATE('2003-15-10 00:00:00', '%Y-%m-%d %H:%i:%s')
        -> NULL

    STR_TO_DATE() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • SUBDATE(date,INTERVAL expr type) , SUBDATE(expr,days)

    2 번째의 인수의 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'

    2 번째의 구문은 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.expr 에는 일자식이나 일자 시각식을 지정해,days 에는 expr (으)로부터 공제하는 날짜를 지정한다.

    mysql> SELECT SUBDATE('1998-01-02 12:00:00', 31);
        -> '1997-12-02 12:00:00'

  • SUBTIME(expr,expr2)

    SUBTIME() 그럼,expr (으)로부터 expr2 (을)를 공제한 결과가 돌려주어진다. expr 에는 일자식이나 일자 시각식을 지정해,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'

    SUBTIME() 하 MySQL 4.1.1 그리고 추가되었다.

  • SYSDATE()

    SYSDATE() 하 NOW() 의 동의어.

  • 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'

    TIME() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • TIMEDIFF(expr,expr2)

    TIMEDIFF() 그럼, 개시시각 expr (와)과 종료시각 expr2 의 사이의 시간이 돌려주어진다. expr (와)과 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'

    TIMEDIFF() 하 MySQL 4.1.1 그리고 추가되었다.

  • TIMESTAMP(expr) , TIMESTAMP(expr,expr2)

    인수가 1 개의 경우는, 일자식 또는 일자 시각식 expr (을)를 일자 시각치로서 돌려준다. 인수가 2 개의 경우는, 일자식 또는 일자 시각식 expr 에 시각식 expr2 (을)를 더한 결과를 일자 시각치로서 돌려준다.

    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'

    TIMESTAMP() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • 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'

  • 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

    TO_DAYS() 그럼, 태양력(1582 해)보다 전의 값의 지정은 상정하고 있지 않다.이것은, 달력이 변경되었을 때에 없어진 날짜가 고려되지 않기 때문에.

  • UNIX_TIMESTAMP() , UNIX_TIMESTAMP(date)

    인수 없이 불려 갔을 경우,Unix 타임 스탬프('1970-01-01 00:00:00' GMT (으)로부터의 초수)를 부호 없음의 정수로서 돌려준다.date 인수를 지정해 불려 갔을 경우,UNIX_TIMESTAMP() (은)는 인수로 지정된 일자를 '1970-01-01 00:00:00' GMT (으)로부터의 초 수라고 해 돌려준다.인수 date 에는,DATE 형태 문자열,DATETIME 형태 문자열,TIMESTAMP 형태의 값,YYMMDD 또는 YYYYMMDD 의 형식의 현지시간의 어느쪽이든을 지정할 수 있다.

    mysql> SELECT UNIX_TIMESTAMP();
        -> 882226357
mysql> SELECT UNIX_TIMESTAMP('1997-10-04 22:23:00');
        -> 875996580

    UNIX_TIMESTAMP (을)를 TIMESTAMP 형태의 컬럼에 사용하면.`` 문자열로부터 Unix 타임 스탬프에의'' 암묵적인 변환을 실시하지 않고 , 내부의 타임 스탬프치가 직접 돌려주어진다. UNIX_TIMESTAMP() 에 범위외의 일자를 건네주면,0 하지만 돌려주어지지만, 이 경우, 실행되는 체크는 기본 체크(해 1970 ~ 2037 , 달 01 ~ 12 , 일 01 ~ 31 )에 한정된다.

    UNIX_TIMESTAMP() 컬럼값을 공제하는 경우, 결과를 부호 정수에 캐스트 할 필요가 있는 경우가 있다. See 항6.3.5. 「캐스트 함수」 .

  • UTC_DATE , UTC_DATE()

    문자열과 수치의 어느 쪽의 문맥으로 사용되고 있을까에 따르고,'YYYY-MM-DD' 또는 YYYYMMDD 형식의 값으로서 현재의 UTC 일자를 돌려준다.

    mysql> SELECT UTC_DATE(), UTC_DATE() + 0;
        -> '2003-08-14', 20030814

    UTC_DATE() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • UTC_TIME , UTC_TIME()

    문자열과 수치의 어느 쪽의 문맥으로 사용되고 있을까에 따르고,'HH:MM:SS' 또는 HHMMSS 형식의 값으로서 현재의 UTC 시각을 돌려준다.

    mysql> SELECT UTC_TIME(), UTC_TIME() + 0;
        -> '18:07:53', 180753

    UTC_TIME() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • UTC_TIMESTAMP , UTC_TIMESTAMP()

    문자열과 수치의 어느 쪽의 문맥으로 사용되고 있을까에 따르고,'YYYY-MM-DD HH:MM:SS' 또는 YYYYMMDDHHMMSS 형식의 값으로서 현재의 UTC 의 일자와 시각을 돌려준다.

    mysql> SELECT UTC_TIMESTAMP(), UTC_TIMESTAMP() + 0;
        -> '2003-08-14 18:08:04', 20030814180804

    UTC_TIMESTAMP() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • WEEK(date [,mode])

    date (으)로 지정된 일자에 대응하는 주수를 돌려준다. 인수를 2 개 취하는 형식의 WEEK() 그럼, 주를 일요일과 월요일의 어느 쪽에서 개시할까, 반환값의 범위를 0 ~ 53 (와)과 1 ~ 52 의 어느 쪽으로 하는지를 지정할 수 있다.mode 인수를 생략 했을 경우는,default_week_format 서버 변수의 값(또는 MySQL 4.0 이전의 버젼에서는 0) 하지만 적용된다. See 항5.5.6. 「SET 구문」 .

    다음의 겉(표)에,mode 인수의 동작을 나타낸다.

    치 | 의미
    0 | 일요일부터 주를 개시.반환값의 범위는 0 ~ 53 .주 1 (은)는 그 해에 개시되는 최초의 주.
    1 | 월요일부터 주를 개시.반환값의 범위는 0 ~ 53 .주 1 하 4 일 이상의 날을 가지는 그 해의 최초의 주.
    2 | 일요일부터 주를 개시.반환값의 범위는 1 ~ 53 .주 1 (은)는 그 해에 개시되는 최초의 주.
    3 | 월요일부터 주를 개시.반환값의 범위는 1 ~ 53 .주 1 하 4 일 이상의 날을 가지는 그 해의 최초의 주.
    4 | 일요일부터 주를 개시.반환값의 범위는 0 ~ 53 .주 1 하 4 일 이상의 날을 가지는 그 해의 최초의 주.
    5 | 월요일부터 주를 개시.반환값의 범위는 0 ~ 53 .주 1 (은)는 그 해에 개시되는 최초의 주.
    6 | 일요일부터 주를 개시.반환값의 범위는 1 ~ 53 .주 1 하 4 일 이상의 날을 가지는 그 해의 최초의 주.
    7 | 월요일부터 주를 개시.반환값의 범위는 1 ~ 53 .주 1 (은)는 그 해에 개시되는 최초의 주.

    mode 치 3 하 MySQL 4.0.5 이?~ 그리고 사용할 수 있다. mode 치 4 이상은 MySQL 4.0.17 이?~ 그리고 사용할 수 있다.

    mysql> SELECT WEEK('1998-02-20');
        -> 7
mysql> SELECT WEEK('1998-02-20',0);
        -> 7
mysql> SELECT WEEK('1998-02-20',1);
        -> 8
mysql> SELECT WEEK('1998-12-31',1);
        -> 53

    주의: 버젼 4.0 그리고,WEEK(date,0) (은)는 미국의 달력에 맞추어 변경되었다.그 이전의 버젼에서는,WEEK() 의 계산은 미국의 일자에 대해서 올바르게 행해지지 않았다(사실상, 모든 경우로,WEEK(date) (와)과 WEEK(date,0) 그리고 결과가 잘못하고 있었다).

    주의: 지정된 일자가 전년의 마지막 주에 해당하는 경우, 옵션의 mode 인수로서 2 ,3 ,6 ,7 중 한쪽이 지정되어 있지 않으면MySQL (으)로부터 값 0 하지만 돌아간다.

    mysql> SELECT YEAR('2000-01-01'), WEEK('2000-01-01',0);
        -> 2000, 0

    이 경우, 지정된 일자는 실제로는 1999 해의 52 주목에 포함되기 위해,WEEK() 함수의 결과로서 값 52 (을)를 돌려주어야 한다고 하는 생각도 있지만,MySQL 그럼 그처럼은 하지 않고, 값 0 (을)를 돌려주도록(듯이) 했다.이것은, 이 함수에 의해서, 어디까지나 `` 지정된 해의 주수'' 하지만 돌려주어지듯이 하기 위한(해)이다.그렇게 하는 것으로, 일자로부터 일자 부분을 꺼내는 다른 함수로 조합해 WEEK() 함수를 사용했을 경우의 신뢰성이 확보된다.

    결과의 평가를, 지정한 일자의 주의 첫날이 포함되는 해에 관련해 실시하려면 , 옵션의 mode 인수로서 2 ,3 ,6 ,7 의 어느쪽이든을 지정하도록(듯이) 한다.

    mysql> SELECT WEEK('2000-01-01',2);
        -> 52

    또는,YEARWEEK() 함수를 사용한다.

    mysql> SELECT YEARWEEK('2000-01-01');
        -> 199952
mysql> SELECT MID(YEARWEEK('2000-01-01'),5,2);
        -> '52'

  • WEEKDAY(date)

    date (으)로 지정된 일자의 요일 인덱스(0 = 월요일,1 = 화요일,... 6 = 일요일)을 돌려준다.

    mysql> SELECT WEEKDAY('1998-02-03 22:23:00');
        -> 1
mysql> SELECT WEEKDAY('1997-11-05');
        -> 2

  • WEEKOFYEAR(date)

    지정된 일자의 달력상의 주를,1 ~ 53 의 수치로서 돌려준다.

    mysql> SELECT WEEKOFYEAR('1998-02-20');
        -> 8

    WEEKOFYEAR() 하 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • YEAR(date)

    date (으)로 지정된 일자의 해를,1000 ~ 9999 의 수치로서 돌려준다.

    mysql> SELECT YEAR('98-02-03');
        -> 1998

  • YEARWEEK(date) , YEARWEEK(date,start)

    지정된 일자의 해와 주를 돌려준다.start 인수는,WEEK() 에 대한다 start 인수와 완전히 똑같이 작용한다.주의: date 인수로 지정된 일자의 주가 그 해의 최초의 주인 경우와 마지막 주인 경우, 결과의 해가 date 인수의 해와 다른 일이 있다.

    mysql> SELECT YEARWEEK('1987-01-01');
        -> 198653

    결과의 주수는, 옵션 인수 0 또는 1 (을)를 지정했다 WEEK() 함수로 돌아가는 값과 다르다.WEEK() 함수에서는, 지정한 해의 문맥으로 주수가 돌려주어진다.

6.3.5. 캐스트 함수

CAST() 함수와 CONVERT() 함수는, 어느 데이터형의 값으로부터 다른 데이터형의 값을 생성하는 목적으로 사용할 수 있습니다.구문은 이하대로입니다.

CAST(expression AS type)
CONVERT(expression,type)
CONVERT(expr USING transcoding_name)

type 에는, 다음의 몇개의 데이터형을 지정할 수 있습니다.

  • BINARY

  • CHAR

  • DATE

  • DATETIME

  • SIGNED {INTEGER}

  • TIME

  • UNSIGNED {INTEGER}

CAST() (와)과 CONVERT() 하 MySQL 4.0.2 이?~ 그리고 사용할 수 있습니다. 변환형 CHAR 하 4.0.6 이?~ 그리고 사용 가능합니다. USING (을)를 지정한다 CONVERT() (은)는,4.1.0 이?~ 그리고 사용 가능합니다.

CAST() (와)과 CONVERT(... USING ...) 하 SQL-99 의 구문입니다. USING (을)를 지정하지 않는다 CONVERT() 하 ODBC 의 구문입니다.

캐스트 함수는,CREATE ... SELECT 스테이트먼트로 특정의 형태의 컬럼을 작성할 필요가 있을 때 도움이 됩니다.

CREATE TABLE new_table SELECT CAST('2000-01-01' AS DATE);

또, 캐스트 함수는 ENUM 형태의 컬럼을 어휘의 순서로 소트 할 경우에도 도움이 됩니다.통상,ENUM 형태의 컬럼의 소트는, 내부의 수치에 근거해 행해집니다.값을 CHAR 형태에 캐스트 하면, 어휘의 순서로 소트 되게 됩니다.

SELECT enum_col FROM tbl_name ORDER BY CAST(enum_col AS CHAR);

CAST(string AS BINARY) 하 BINARY string (와)과 같습니다. CAST(expr AS CHAR) 그럼, 지정한 식이 디폴트의 캐릭터 세트의 문자열로서 다루어집니다.

주의: MysQL 4.0 그럼,DATE ,DATETIME ,TIME 형태의 컬럼에 CAST() 조작을 실시했을 경우, 컬럼이 특정의 형태로서 마크 되는 것만으로, 컬럼치가 바뀌는 것은 아닙니다.

MySQL 4.1.0 그럼, 컬럼치는, 유저에게 보내질 때 적절한 컬럼형에 변환됩니다(이것은, 클라이언트에의 일자 정보의 송신에 있어서의,4.1 의 새로운 프로토콜의 기능입니다).

mysql> SELECT CAST(NOW() AS DATE);
       -> 2003-05-26

후속의 MySQL 버젼(아마 4.1.2 인가 5.0 )에서는,CONCAT("Date: ",CAST(NOW() AS DATE)) (와)과 같은, 보다 복잡한 식의 일부로서 CAST (을)를 사용했을 경우에도, 결과의 데이터형이 적절히 변환되도록(듯이) 수정할 예정입니다.

데이터를 다른 형식에서 꺼낼 때는,CAST() (은)는 사용하지 않고, 대신에,LEFT (이)나 EXTRACT() (와)과 같은 문자열 함수를 사용해 주세요. See 항6.3.4. 「일자와 시각 함수」 .

문자열을 수치에 캐스트 할 경우에는, 통상은, 특히 아무것도 하지 않고, 그대로 그 문자열을 수치로서 사용합니다.

mysql> SELECT 1+'1';
       -> 2

문자열의 문맥으로 수치를 사용하면, 수치는 BINARY 문자열에 자동으로 변환됩니다.

mysql> SELECT CONCAT("hello you ",2);
       ->  "hello you 2"

MySQL 그럼, 부호 첨부와 부호 없음의 어디라도,64 비트치의 연산을 서포트하고 있습니다. 수치 연산(+ 등)으로 어느 쪽인지 한편의 오퍼랜드가 unsigned integer 의 경우, 결과의 값은 부호없이 됩니다. 다만, 캐스트 연산자 SIGNED (와)과 UNSIGNED (을)를 사용하는 것에 의해서, 각각 부호 붙어, 또는 부호 없음의 64 비트 정수에 캐스트 할 수 있습니다.

mysql> SELECT CAST(1-2 AS UNSIGNED)
        -> 18446744073709551615
mysql> SELECT CAST(CAST(1-2 AS UNSIGNED) AS SIGNED);
        -> -1

주의: 어느 쪽인지 한편의 오퍼랜드가 부동 소수점수(실수)의 경우, 결과의 값은 부동 소수점수(실수)가 되어, 상기의 규칙은 적용되지 않습니다(이 문맥에서는,DECIMAL 형태의 값은 부동 소수점수(실수)로 간주해집니다).

mysql> SELECT CAST(1 AS UNSIGNED) - 2.0;
        -> -1.0

산술 연산에 문자열을 사용하면, 그 문자열은 부동 소수점수(실수)에 변환됩니다.

부호 없음의 값의 취급에 대해서는,BIGINT 형태의 값에 적절히 대응하도록,MySQL 4.0 그리고 변경되었습니다.MySQL 4.0 (와)과 3.23 의 양쪽 모두로 실행하는 코드가 있을 때(통상, 이 경우,CAST() 함수는 사용할 수 없다), 다음의 방법에 의해서,2 개의 부호 없음 정수 컬럼의 감산의 실행시에 부호 첨부의 결과치를 얻을 수 있습니다.

SELECT (unsigned_column_1+0.0)-(unsigned_column_2+0.0);

이 방법에서는, 감산의 실행전에 양쪽 모두의 컬럼을 부동 소수점형으로 변환하고 있습니다.

이전의 MySQL 어플리케이션의 UNSIGNED 형태의 컬럼을 MySQL 4.0 에 이식했을 경우에 문제가 있을 때는,mysqld 의 기동시에 --sql-mode=NO_UNSIGNED_SUBTRACTION 옵션을 지정합니다.주의: 이 옵션을 지정했을 경우,BIGINT UNSIGNED 컬럼형을 효율적으로 사용할 수 없습니다.

USING (을)를 지정한다 CONVERT() (은)는, 데이터의 캐릭터 세트를 다른 캐릭터 세트로 변환할 때 사용합니다.MySQL 그럼, 트랜스 코딩명은 대응하는 캐릭터 세트명과 같습니다.예를 들어, 다음의 스테이트먼트에서는, 서버의 디폴트의 캐릭터 세트에 근거하는 문자열 'abc' 하지만,utf8 캐릭터 세트의 대응하는 문자열에 변환됩니다.

SELECT CONVERT('abc' USING utf8);

6.3.6. 그 외의 함수

6.3.6.1. 비트 함수

MySQL 그럼, 비트 연산에 BIGINT (64 비트) 연산을 사용합니다.따라서, 이하의 비트 연산자의 범위는 최대 64 비트가 됩니다.

  • |

    비트마다의 OR .

    mysql> SELECT 29 | 15;
        -> 31

    결과는 부합 없음의 64 비트 정수.

  • &

    비트마다의 AND .

    mysql> SELECT 29 & 15;
        -> 13

    결과는 부합 없음의 64 비트 정수.

  • ^

    비트마다의 XOR .

    mysql> SELECT 1 ^ 1;
        -> 0
mysql> SELECT 1 ^ 0;
        -> 1
mysql> SELECT 11 ^ 3;
        -> 8

    결과는 부합 없음의 64 비트 정수.

    XOR (은)는 버젼 4.0.2 그리고 추가되었다.

  • <<

    longlong (BIGINT ) 값의 비트를 왼쪽으로 시프트 한다.

    mysql> SELECT 1 << 2;
        -> 4

    결과는 부합 없음의 64 비트 정수.

  • >>

    longlong (BIGINT ) 값의 비트를 오른쪽으로 시프트 한다.

    mysql> SELECT 4 >> 2;
        -> 1

    결과는 부합 없음의 64 비트 정수.

  • ~

    모든 비트를 반전시킨다.

    mysql> SELECT 5 & ~1;
        -> 4

    결과는 부합 없음의 64 비트 정수.

  • BIT_COUNT(N)

    인수 N (으)로 지정된 수치를 2 진표기했을 때에 1 (으)로 설정되는 비트수를 돌려준다.

    mysql> SELECT BIT_COUNT(29);
        -> 4

6.3.6.2. 그 외의 각종 함수

  • AES_ENCRYPT(string,key_string) , AES_DECRYPT(string,key_string)

    이러한 함수에서는, 공식의 AES (Advanced Encryption Standard ) 알고리즘(이전,Rijndael (으)로 불리고 있던 것)를 사용해 데이터의 암호화와 해독을 실행할 수 있다. encode에 사용되는 키장은 128 비트이지만, 소스를 변경하는 것에 의해서,256 비트까지 확장할 수 있다.MySQL 그럼 128 비트를 선택하고 있다.그 이유는, 그 편이 신속하고, 한편 통상, 안전성도 충분히 확보할 수 있기 위해.

    입력 인수는 임의의 길이로 할 수 있다.어느 쪽인가의 인수로서 NULL (을)를 지정했을 경우, 이 함수의 결과도 NULL (이)가 된다.

    AES (은)는 블록 레벨의 알고리즘이기 위해, 고르지 않음의 길이의 문자열의 encode시에는 매입을 한다.따라서, 결과의 문자열의 길이는 16*(trunc(string_length/16)+1) (으)로서 계산할 수 있다.

    AES_DECRYPT() 그럼, 무효인 데이터나 잘못된 매입이 검출되면,NULL 하지만 돌려주어진다.그러나, 입력 데이터나 키가 무효에서도,AES_DECRYPT() (으)로부터 NULL 이외의 값(가베지등)이 돌려주어지는 일이 있다.

    쿼리를 다음과 같이 변경하는 것에 의해서,AES 함수를 사용해 암호 형식에서 데이터를 격납할 수 있다.

    INSERT INTO t VALUES (1,AES_ENCRYPT('text','password'));

    각 쿼리의 접속을 통한 키의 전송을 실시하지 않게 하면, 한층 더 시큐러티를 강화할 수 있다.이 경우, 키는 접속시에 서버측의 변수에 격납한다.

    SELECT @password:='my password';
INSERT INTO t VALUES (1,AES_ENCRYPT('text',@password));

    AES_ENCRYPT() (와)과 AES_DECRYPT() (은)는 버젼 4.0.2 그리고 추가되었다.이 2 개는, 현재로서는 MySQL 그리고 사용 가능한, 암호화 방식으로서 가장 안전성의 높은 암호화 함수로서 간주할 수 있다.

  • BENCHMARK(count,expr)

    BENCHMARK() 함수는,expr (으)로 지정된 식을 count (으)로 지정된 회수만 반복해 실행한다.이 함수는,MySQL (으)로의 식의 처리 속도를 계측하기 위해서 사용할 수 있다.결과의 값으로서는, 항상 0 하지만 돌아간다.이 함수를 mysql 클라이언트로 사용하는 것에 의해서, 쿼리의 실행 시간을 리포트할 수 있다.

    mysql> SELECT BENCHMARK(1000000,ENCODE("hello","goodbye"));
+----------------------------------------------+
| BENCHMARK(1000000,ENCODE("hello","goodbye")) |
+----------------------------------------------+
|                                            0 |
+----------------------------------------------+
1 row in set (4.74 sec)

    리포트되는 시간은, 서버측의 CPU 시간이 아니고, 클라이언트측의 경과시간이다.BENCHMARK() (을)를 몇차례 실행해, 결과를 분석하는 것에 의해서, 서버머신의 부하가 어느 정도인가 조사할 수 있다.

  • COMPRESS(string_to_compress)

    문자열을 압축한다.

    mysql> SELECT LENGTH(COMPRESS(REPEAT("a",1000)));
        -> 21
mysql> SELECT LENGTH(COMPRESS(""));
        -> 0
mysql> SELECT LENGTH(COMPRESS("a"));
        -> 13
mysql> SELECT LENGTH(COMPRESS(REPEAT("a",16)));
        -> 15

    COMPRESS() 하 MySQL 버젼 4.1.1 그리고 추가되었다. 이 함수를 사용하기 위해서는,zlib 등의 압축 라이브러리를 사용해 MySQL (을)를 컴파일 해 둘 필요가 있다.컴파일을 실시하지 않으면 반환값은 항상 NULL (이)가 된다.

    압축한 문자열의 내용은 다음의 방법으로 격납된다.

    • 하늘의 문자열은 하늘의 문자열로서 격납된다.

    • 하늘 이외의 문자열은, 우선 4 아르바이트의 길이의 비압축 문자열로서 격납되어(하위 바이트가 앞), 그 후 gzip 에 의해서 문자열이 압축된다.문자열이 스페이스에서 끝나 있는 경우는, 추가의 ‘. ＇ 하지만 삽입된다.이것은, 결과를 CHAR 형태 또는 VARCHAR 형태의 컬럼에 격납하는 경우에 말미의 스페이스의 절취로 문제가 발생하지 않게 하기 위한(해).그러나,CHAR 형태나 VARCHAR 형태 컬럼에게의 압축 문자열의 격납은 추천 되지 않는다.대신에,BLOB 형태의 컬럼을 사용하도록(듯이) 한다.

  • CONNECTION_ID()

    접속의 접속 ID (스레드 ID )(을)를 돌려준다. 각 접속에는 그 접속 고유의 일의인 ID 하지만 할당할 수 있다.

    mysql> SELECT CONNECTION_ID();
        -> 23786

  • CURRENT_USER()

    현재의 세션의 인증에 사용된 유저명과 호스트명을 돌려준다.이 값은 액세스권한의 평가에 사용되는 어카운트에 대응하고 있다.USER() 의 값과는 다른 경우가 있다.

    mysql> SELECT USER();
        -> 'davida@localhost'
mysql> SELECT * FROM mysql.user;
        -> ERROR 1044: Access denied for user: '@localhost' to database 'mysql'
mysql> SELECT CURRENT_USER();
        -> '@localhost'

    위의 예에서는, 클라이언트가 유저명으로서 davida (을)를 지정해 있다(USER() 의 값에 의해)에도 불구하고, 서버는 익명 유저 어카운트로 클라이언트의 인증을 실시하고 있다(CURRENT_USER() 값의 유저명의 부분이 하늘)의를 알 수 있다.이러한 일이 일어나는 원인의 1 개로서davida 의 권한 테이블에 어카운트가 등록되지 않은 경우를 생각할 수 있다.

  • DATABASE()

    경향 데이타베이스명을 돌려준다.

    mysql> SELECT DATABASE();
        -> 'test'

    경향 데이타베이스가 없는 경우,DATABASE() (은)는,MySQL 4.1.1 이?~ 그럼 NULL (을)를 돌려주어, 그 이전의 버젼에서는 하늘의 문자열을 돌려준다.

  • DECODE(crypt_str,pass_str)

    pass_str (으)로 지정된 문자열을 패스워드로서 사용하고, 암호화된 문자열 crypt_str (을)를 해독한다.crypt_str 하 ENCODE() (으)로부터 돌려주어진 문자열이 아니면 안된다.

  • ENCODE(str,pass_str)

    pass_str (으)로 지정된 문자열을 패스워드로서 사용하고,str (을)를 암호화한다. 암호화된 결과를 해독하려면 , DECODE() (을)를 사용한다.

    결과적으로,string (와)과 같은 길이의 바이너리 문자열이 돌려주어진다. 이 문자열을 컬럼에 보존하려면 ,BLOB 형태의 컬럼을 사용한다.

  • DES_DECRYPT(string_to_decrypt [, key_string])

    DES_ENCRYPT() 그리고 암호화된 문자열을 해독한다.

    주의: 이 함수는,MySQL 그리고 SSL 의 서포트가 짜넣어지고 있는 경우에게만 기능한다. See 항4.4.10. 「안전한 접속의 사용」 .

    key_string 인수가 지정되어 있지 않은 경우,DES_DECRYPT() (은)는 암호화 문자열의 최초의 아르바이트를 조사하고, 원의 문자열의 암호화에 사용되었다 DES 키 번호를 판별해,des-key-file (으)로부터 키를 읽어내 메세지의 암호화를 해제한다.이것을 실시하기 위해서는, 유저는 SUPER 권한을 가지고 있지 않으면 안 된다.

    이 함수에 key_string 인수를 건네주었을 경우, 이 인수로 지정한 문자열이 메세지의 암호화를 해제하는 키로서 사용된다.

    string_to_decrypt (으)로 지정한 문자열이 암호화된 문자열로서 MySQL 에 인식되지 않는 경우, 지정한 문자열이 그대로 돌려주어진다.

    에러시에는,NULL 하지만 돌려주어진다.

  • DES_ENCRYPT(string_to_encrypt [, (key_number | key_string) ] )

    지정된 키를 사용하고,Triple-DES 알고리즘에 의해서 문자열의 암호화를 해제한다.

    주의: 이 함수는,MySQL 그리고 SSL 의 서포트가 짜넣어지고 있는 경우에게만 기능한다. See 항4.4.10. 「안전한 접속의 사용」 .

    사용하는 암호화 키는 다음의 방법으로 선택된다.

    인수 | 설명
    인수가 1 개만 | des-key-file 파일내의 최초의 키를 사용.
    키 번호 | des-key-file 파일내의, 지정된 키(0 ~ 9 )(을)를 사용.
    문자열 | key_string (으)로 지정된 문자열을 사용해 string_to_encrypt 의 암호화를 해제.

    함수의 결과로서, 바이너리 문자열이 돌려주어진다.이 문자열의 최초의 문자는 CHAR(128 | key_number) (이)가 된다.

    128 (은)는 암호화된 키를 분별하기 쉽게 하는 목적으로 추가된다. 문자열 키를 사용하면,key_number 하 127 (이)가 된다.

    에러시에는,NULL 하지만 돌려주어진다.

    결과의 문자열장은 new_length= org_length + (8-(org_length % 8))+1 (이)가 된다.

    des-key-file 의 형식은 다음대로.

    key_number des_key_string
key_number des_key_string

    각 key_number 하 0 ~ 9 의 범위의 번호가 아니면 안된다.파일내의 행은 임의의 순서로 할 수 있다.des_key_string (은)는, 메세지의 암호화에 사용하는 문자열.번호와 키의 사이에는,1 개이상의 스페이스를 삽입한다.최초의 키는,DES_ENCRYPT() 에 키 인수를 아무것도 지정하지 않는 경우에 사용되는 디폴트의 키.

    FLUSH DES_KEY_FILE 커멘드를 사용하면,MySQL 에 키파일로부터 새로운 키치를 읽어내게 할 수 있다.이 커멘드를 사용하려면 ,Reload_priv 권한이 필요하게 된다.

    디폴트 키세트를 준비해 두는 이점의 1 개는, 암호화된 컬럼치가 존재할지 어플리케이션으로 체크할 수 있는 것이다.이 경우, 그러한 값을 해독할 권리를 최종 사용자에게 줄 필요는 없다.

    mysql> SELECT customer_address FROM customer_table WHERE
       crypted_credit_card = DES_ENCRYPT("credit_card_number");

  • ENCRYPT(str[,salt])

    Unix 의 crypt() 시스템 콜을 사용하고,str (으)로 지정된 문자열을 암호화한다.salt 인수는,2 개의 문자로부터 완성되는 문자열이 아니면 안된다(MySQL 버젼 3.22.16 이?~ 그럼,salt 에 2 문자를 넘는 길이의 문자열을 지정할 수 있다).

    mysql> SELECT ENCRYPT("hello");
        -> 'VxuFAJXVARROc'

    일부의 시스템에서는,ENCRYPT() 하 str (으)로 지정된 문자열의 최초의 8 문자 이외의 모든 문자를 무시한다.이 동작은, 기반이 된다 crypt() 시스템 콜의 실장에 의해서 정해진다.

    사용 시스템으로 crypt() (을)를 이용할 수 없는 경우,ENCRYPT() (은)는 항상 NULL (을)를 돌려준다.그 때문에,ENCRYPT() 의 대용으로서MD5() 또는 SHA1() 의 사용이 추천 된다.이러한 2 개의 함수는 모든 플랫폼에서 이용할 수 있다.

  • FORMAT(X,D)

    X (으)로 지정된 수치의 소수부를,D (으)로 지정된 자리수에 말고,'#,###,###.##' (와)과 같은 형식으로 설정해, 결과를 문자열로서 돌려준다. 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'

  • FOUND_ROWS()

    SELECT 스테이트먼트에 LIMIT 마디를 짜넣는 것에 의해서, 서버가 클라이언트에 돌려주는 레코드수를 제한할 수 있다. 상황에 따라서는,LIMIT (을)를 지정하지 않았던 경우에 몇 개의 레코드가 돌려주어질까를, 스테이트먼트를 재차 실행하는 일 없이 확인하고 싶은 것이 있다. 이 레코드수를 확인하려면 SELECT 스테이트먼트에 SQL_CALC_FOUND_ROWS 옵션을 지정해, 그 후 FOUND_ROWS() (을)를 호출한다.

    mysql> SELECT SQL_CALC_FOUND_ROWS * FROM tbl_name
       WHERE id > 100 LIMIT 10;
mysql> SELECT FOUND_ROWS();

    2 번째의 SELECT 그럼, 최초의 SELECT (을)를 LIMIT 마디 없이 실행했을 경우에 돌려주어지는 레코드수를 나타내는 수가 돌아간다(선행한다 SELECT 스테이트먼트에 SQL_CALC_FOUND_ROWS 옵션이 포함되지 않으면FOUND_ROWS() 하 LIMIT 하지만 사용되지 않는 경우와는 다른,LIMIT 하지만 사용되었을 때의 결과를 돌려준다).

    주의: SELECT SQL_CALC_FOUND_ROWS ... (을)를 사용했을 경우,MySQL 그럼 완전한 결과 세트에 포함되는 레코드수를 계산할 필요가 생긴다.그러나, 이 경우, 결과 세트를 클라이언트에 보낼 필요가 없기 때문에,LIMIT 없이 재차 쿼리를 실행하는 것보다 시간이 걸리지 않는다.

    SQL_CALC_FOUND_ROWS (와)과 FOUND_ROWS() (은)는, 쿼리로 돌려주어지는 레코드수를 제한할 필요가 있는 경우에, 완전한 결과 세트에 포함되는 레코드수를(쿼리를 재실행하는 일 없이) 확인하고 싶을 때에 도움이 된다.예로서 검색 결과의 다른 섹션을 나타내는 페이지로의 링크를 포함한 페이지 화면을 표시한다 Web 스크립트를 들 수 있다.FOUND_ROWS() (을)를 사용하면, 결과의 나머지의 부분을 표시하는데 앞으로 무슨 페이지 필요한가 확인할 수 있다.

    SQL_CALC_FOUND_ROWS (와)과 FOUND_ROWS() (을)를 UNION 쿼리로 사용했을 경우, 단순한 SELECT 스테이트먼트로 사용했을 경우보다 복잡하게 된다.이것은,LIMIT 하지만 UNION 안의 복수의 장소에서 일어날 수 있기 때문에 있다.LIMIT (은)는,UNION 안의 개개의 SELECT 스테이트먼트에 적용하는 일도,UNION 의 결과 전체에 글로벌하게 적용할 수도 있다.

    UNION 에 대해서 SQL_CALC_FOUND_ROWS (을)를 사용하는 목적은, 이 옵션에 의해서, 글로벌인 LIMIT (을)를 지정하지 않았던 경우에 돌려주어지는 레코드수를 확인할 수 있는 것에 있다. UNION (으)로의 SQL_CALC_FOUND_ROWS 의 사용에는, 이하의 조건이 적용된다.

    • UNION 의 최초의 SELECT 에 SQL_CALC_FOUND_ROWS 키워드가 지정되어 있지 않으면 안 된다.

    • FOUND_ROWS() 의 값은 UNION ALL 의 사용시만 정확하게 된다. ALL 없이 UNION (을)를 사용했을 경우, 중복의 삭제를 하기 위해,FOUND_ROWS() 의 값은 근사치에 지나지 않는다.

    • UNION 안에 LIMIT 하지만 존재하지 않는 경우,SQL_CALC_FOUND_ROWS (은)는 무시되어UNION (을)를 처리하기 위해서 작성된 텐포라리테이불내의 레코드수가 돌려주어진다.

    SQL_CALC_FOUND_ROWS (와)과 FOUND_ROWS() 하 MySQL 버젼 4.0.0 이?~ 그리고 사용할 수 있다.

  • GET_LOCK(str,timeout)

    str (으)로 지정된 이름의 락을 취득하려고 시도한다.이 경우,timeout (으)로 지정된 초수를 타임 아웃으로 한다.정상적으로 락이 취득되었을 때는 1 (을)를 돌려주어, 락의 취득이 타임 아웃이 되었다(지정된 이름이 다른 클라이언트에 의해서 벌써 락 되고 있는 경우 등) 때는 0 (을)를 돌려주어, 에러가 발생했다(메모리 부족이나,mysqladmin kill 그리고 스레드가 강제 종료되었을 경우 등) 때는 NULL (을)를 돌려준다.락은,RELEASE_LOCK() 하지만 실행되는지, 새롭다 GET_LOCK() 하지만 실행되는지, 또는 스레드가 종료하는(정상 종료 또는 이상종료(ABEND))와 해제된다.

    이 함수는 어플리케이션의 락을 실행하거나 레코드의 락을 시?~ 레이션 하거나 하는 목적으로 사용할 수 있다.이름은 서버 전체의 범위에서 유효하다. 1 개의 클라이언트가 있는 이름의 락을 얻고 있는 경우,GET_LOCK() (은)는, 그 이름의 락에 대한, 다른 클라이언트로부터의 모든 요구를 블록 한다. 어느 이름의 락을 기초로 하면, 각 클라이언트간으로의 동기를 받아들이게 하는 동작이 가능하다：

    mysql> SELECT GET_LOCK("lock1",10);
        -> 1
mysql> SELECT IS_FREE_LOCK("lock2");
        -> 1
mysql> SELECT GET_LOCK("lock2",10);
        -> 1
mysql> SELECT RELEASE_LOCK("lock2");
        -> 1
mysql> SELECT RELEASE_LOCK("lock1");
        -> NULL

    주의: 2 번째의 RELEASE_LOCK() 호출에서는 NULL 하지만 돌려주어진다.이것은, 락 "lock1" 하지만 2 번째의 GET_LOCK() 호출에 의해서 자동적으로 해제되기 위해.

  • INET_ATON(expr)

    문자열로서 지정된, 닷 10 진표기의 네트워크 주소를, 그 주소의 수치를 나타내는 정수로서 돌려준다. 주소로서4 아르바이트 또는 8 아르바이트의 주소를 지정할 수 있다.

    mysql> SELECT INET_ATON("209.207.224.40");
       ->  3520061480

    생성되는 수치는, 항상 네트워크 바이트 오더로 생성된다.예를 들어, 위의 예의 수치는,209*256^3 + 207*256^2 + 224*256 +40 (으)로서 계산된다.

  • INET_NTOA(expr)

    수치로서 표현된 네트워크 주소(4 또는 8 아르바이트)를, 닷 10 진표기의 주소(문자열)로서 돌려준다.

    mysql> SELECT INET_NTOA(3520061480);
       ->  "209.207.224.40"

  • IS_FREE_LOCK(str)

    str (으)로 지정된 이름을 가지는 락이 해방되고 있는지 어떤지(즉, 락 되어 있지 않은지 어떤지) 확인한다. 락이 해방되고 있는(아무도 그 락을 사용하고 있지 않다) 경우는 1 (을)를 돌려주어, 그 락이 사용되고 있는 경우는 0 (을)를 돌려주어, 에러가 발생했을(인수에 잘못이 있는 등) 경우는 NULL (을)를 돌려준다.

  • LAST_INSERT_ID([expr])

    AUTO_INCREMENT 컬럼에 삽입된 값 가운데, 마지막에 자동 생성된 값을 돌려준다.

    mysql> SELECT LAST_INSERT_ID();
        -> 195

    생성된 마지막 ID (은)는, 접속 마다 서버로 유지된다.따라서, 이 함수로부터 개개의 클라이언트에 돌려주어지는 값은, 그 클라이언트에 의해서 생성된 최신의 AUTO_INCREMENT 값이다.이 값은, 다른 클라이언트가 각각의 AUTO_INCREMENT 값을 생성해도, 거기에 따라 영향을 받을 것은 없다.이 동작에 의해서, 다른 클라이언트의 활동 에 관계없이, 또, 락이나 트랜잭션(transaction)를 필요로 하는 일 없이, 자신의 ID (을)를 확실히 꺼낼 수 있다.

    비매직치(즉,NULL 그렇지만 0 도 아닌 값)을 가지는 레코드의 AUTO_INCREMENT 컬럼을 갱신해도,LAST_INSERT_ID() 의 값은 변경되지 않는다.

    INSERT 스테이트먼트로 동시에 복수의 레코드를 삽입했을 경우,LAST_INSERT_ID() (은)는 최초로 삽입된 레코드의 값을 돌려준다.이것은, 같다 INSERT 스테이트먼트를 다른 몇개의 서버에 대해서 간단하게 재생성할 수 있듯이 하기 위한(해)이다.

    LAST_INSERT_ID() 의 인수로서 expr (을)를 지정했을 경우, 인수의 값이 함수로부터 돌려주어져 이 값이 LAST_INSERT_ID() 에 의해서 돌려주어지는 다음의 값으로 해서 설정된다.이것은 순서의 시?~ 레이션에 사용할 수 있다.

    우선, 테이블을 작성한다.

    mysql> CREATE TABLE sequence (id INT NOT NULL);
mysql> INSERT INTO sequence VALUES (0);

    그 후, 이 테이블을 사용해 순서 번호를 다음과 같이 생성할 수 있다.

    mysql> UPDATE sequence SET id=LAST_INSERT_ID(id+1);

    순서의 생성은 LAST_INSERT_ID() (을)를 호출하지 않아도 가능하지만, 이 함수를 이와 같이 사용했을 경우,ID 값이 마지막에 자동 생성된 값으로 해서 서버에 유지된다(multiuser 대응). 새롭다 ID (은)는,MySQL 그리고 통상의 AUTO_INCREMENT 값을 읽어낼 때 것과 같이 꺼낼 수 있다.예를 들어,LAST_INSERT_ID() (인수는 모두 이루어)에서는, 새롭다 ID 하지만 돌려주어진다.C API 함수 mysql_insert_id() 도 이 ID 값의 취득에 사용할 수 있다.

    주의: mysql_insert_id() 하지만 갱신되는 것은,INSERT 스테이트먼트나 UPDATE 스테이트먼트가 나중이 되기 위해,SELECT (이)나 SET 등의 다른 SQL 스테이트먼트의 실행 후에,C API 함수를 사용해 LAST_INSERT_ID(expr) 의 값을 꺼낼 수 없다. See 항11.1.3.32. 「mysql_insert_id() 」 .

  • MASTER_POS_WAIT(log_name, log_pos [, timeout])

    슬레이브가 마스터 로그의 지정된 위치에 이르는(즉, 지정된 위치까지 갱신을 모두 읽어내 적용한다)까지 블록 한다.마스터 정보가 초기화되어 있지 않은 경우나, 인수에 잘못이 있는 경우는,NULL (을)를 돌려준다.슬레이브가 실행되어 있지 않은 경우는, 슬레이브가 개시되어 지정된 위치까지 도달하는지, 이것을 통과할 때까지, 블록 해 대기한다.슬레이브가 지정된 위치를 벌써 통과하고 있는 경우, 이 함수는 즉시 돌아온다.

    timeout (4.0.10 그리고 도입)이 지정되어 있는 경우는,timeout (으)로 지정된 초수가 경과하면 대기를 안?~ 한다.timeout 값은 0 보다 크지 않으면 안 된다.제로나 부의 timeout 값은 타임 아웃 없음을 의미한다.반환값으로서 지정된 위치에 도달하기까지 대기하지 않으면이라면 산 로그 이벤트의 수가 돌려주어진다.에러시에는,NULL 하지만 돌려주어져 타임 아웃을 초과했을 경우는 -1 하지만 돌려주어진다.

    이 커멘드는 마스터와 슬레이브의 동기화에 도움이 된다.

  • MD5(string)

    지정된 문자열의 MD5 128 비트 체크 섬을 계산한다.값은 32 비트의 16 진수로서 돌려주어진다.이 값은, 해시 키등으로 해서 사용할 수 있다.

    mysql> SELECT MD5("testing");
        -> 'ae2b1fca515949e5d54fb22b8ed95575'

    이것은 "RSA Data Security, Inc. 의 MD5 Message-Digest Algorithm" .

  • PASSWORD(str) , OLD_PASSWORD(str)

    평문텍스트의 패스워드 str (으)로부터 패스워드 문자열을 계산한다.이것은,user 권한 테이블의 Password 컬럼에 격납한다 MySQL 패스워드의 암호화에 사용되는 함수.

    mysql> SELECT PASSWORD('badpwd');
        -> '7f84554057dd964b'

    PASSWORD() 의 암호화는 가역은 아니다.

    PASSWORD() (은)는, 패스워드의 암호화를 Unix 패스워드의 암호화와 같은 방법에서는 실시하지 않는다.ENCRYPT() (을)를 참조.

    주의: PASSWORD() 함수는,MySQL 서버의 인증 시스템으로 사용된다.어플리케이션에서는 사용 하지 않는다 일. 어플리케이션용으로는,MD5() 인가 SHA1() (을)를 대신에 사용한다. 어플리케이션으로의 패스워드와 인증의 안전한 처리의 상세한 것에 대하여는, RFC-2195 도 참조.

  • RELEASE_LOCK(str)

    GET_LOCK() 에 의해서 취득된, 문자열 str (을)를 이름으로서 가지는 락을 해제한다.그 락이 해제되었을 경우는 1 (을)를 돌려주어, 그 락이 이 스레드에 의해서 락 되고 있으므로 않은 경우는 0 (을)를 반환(이 경우, 락은 해제되지 않는다), 지정된 락이 존재하지 않는 경우는 NULL (을)를 돌려준다(그 락이 GET_LOCK() (을)를 호출해 취득되었으므로 않는 경우나, 벌써 해제되고 있는 경우, 그 락은 존재하지 않게 된다).

    DO 스테이트먼트를 RELEASE_LOCK() 그리고 사용하면 편리하다. See 항6.4.10. 「DO 구문」 .

  • SESSION_USER()

    SESSION_USER() 하 USER() 의 동의어.

  • SHA1(string) , SHA(string)

    지정된 문자열에 대해서,RFC 3174 (Secure Hash Algorithm )에 정의되었다 SHA1 160 비트 체크 섬을 계산한다.값은 40 자리수의 16 진수로서 돌려주어진다.입력 인수가 NULL 의 경우는,NULL 하지만 돌려주어진다. 이 함수의 용도의 1 개로서 반환값을 해시 키로서 사용할 수 있다.또, 이 함수는, 패스워드를 격납하기 위한 안전한 암호화 함수라고 해도 사용할 수 있다.

    mysql> SELECT SHA1("abc");
        -> 'a9993e364706816aba3e25717850c26c9cd0d89d'

    SHA1() (은)는 버젼 4.0.2 그리고 추가되었다.이 함수는 MD5() 보다 한층 더 안전도가 높은 암호화 함수로 간주할 수 있다. SHA() 하 SHA1() 의 동의어.

  • SYSTEM_USER()

    SYSTEM_USER() 하 USER() 의 동의어.

  • UNCOMPRESS(string_to_uncompress)

    COMPRESS() 함수에 의해서 압축된 문자열의 압축을 해제한다.

    mysql> SELECT UNCOMPRESS(COMPRESS("any string"));
        -> 'any string'

    UNCOMPRESS() 하 MySQL 버젼 4.1.1 그리고 추가되었다. 이 함수를 사용하기 위해서는,zlib 등의 압축 라이브러리를 사용해 MySQL (을)를 컴파일 해 둘 필요가 있다.컴파일을 실시하지 않으면 반환값은 항상 NULL (이)가 된다.

  • UNCOMPRESSED_LENGTH(compressed_string)

    압축 문자열의 압축전의 길이를 돌려준다.

    mysql> SELECT UNCOMPRESSED_LENGTH(COMPRESS(REPEAT("a",30)));
        -> 30

    UNCOMPRESSED_LENGTH() 하 MySQL 버젼 4.1.1 그리고 추가되었다.

  • USER()

    현재의 MySQL 유저명과 호스트명을 돌려준다.

    mysql> SELECT USER();
        -> 'davida@localhost'

    반환값은, 서버에의 접속시로 지정한 유저명과 접속원의 클라이언트 호스트를 나타낸다(MySQL 버젼 3.22.11 보다 전의 버젼에서는, 이 함수의 반환값에는 클라이언트 호스트명은 포함되지 않는다).

    다음과 같이 했을 경우, 값에 호스트명의 부분이 포함되어 있는지 어떤지에 관계없이, 유저명의 부분만큼을 꺼낼 수도 있다.

    mysql> SELECT SUBSTRING_INDEX(USER(),"@",1);
        -> 'davida'

  • VERSION()

    MySQL 서버의 버젼을 나타내는 문자열을 돌려준다.

    mysql> SELECT VERSION();
        -> '3.23.13-log'

    주의: 버젼의 뒤로 -log 하지만 붙어 있는 경우, 로그가 유효하게 되어 있는 것을 나타낸다.

6.3.7. GROUP BY 마디로 사용하는 함수와 수식자

6.3.7.1. GROUP BY 함수

GROUP BY 마디를 포함하지 않는 스테이트먼트로 그룹 함수를 사용하면, 모든 레코드에 대해서 그룹화 조작을 실행하는 것과 같게 됩니다.

  • AVG(expr)

    expr 의 평균치를 돌려준다.

    mysql> SELECT student_name, AVG(test_score)
    ->        FROM student
    ->        GROUP BY student_name;

  • BIT_AND(expr)

    expr 의 모든 비트에 대한 비트마다의 AND (을)를 돌려준다.이 계산은 64 비트(BIGINT )의 정도로 실행된다.

    MySQL 4.0.17 이?~ 그럼, 매치하는 레코드가 없는 경우, 이 함수는 18446744073709551615 (을)를 돌려준다(이것은 모든 비트를 1 (으)로 설정한, 부호 없음의 BIGINT 값). 4.0.17 보다 전의 버젼에서는, 매치하는 레코드가 없는 경우, 이 함수는 -1 (을)를 돌려준다.

  • BIT_OR(expr)

    expr 의 모든 비트에 대한 비트마다의 OR (을)를 돌려준다.이 계산은 64 비트(BIGINT )의 정도로 실행된다.

    매치하는 레코드가 없는 경우, 이 함수는 0 (을)를 돌려준다.

  • BIT_XOR(expr)

    expr 의 모든 비트에 대한 비트마다의 XOR (을)를 돌려준다.이 계산은 64 비트(BIGINT )의 정도로 실행된다.

    매치하는 레코드가 없는 경우, 이 함수는 0 (을)를 돌려준다.

    이 함수는 MySQL 4.1.1 이?~ 그리고 사용할 수 있다.

  • COUNT(expr)

    SELECT 스테이트먼트로 꺼내진 레코드 가운데,NULL 이외의 값의 수의 카운트를 돌려준다.

    mysql> SELECT student.student_name,COUNT(*)
    ->        FROM student,course
    ->        WHERE student.student_id=course.student_id
    ->        GROUP BY student_name;

    COUNT(*) (은)는, 레코드에 NULL 값이 포함되어 있는지 어떤지에 관계없이, 꺼내진 레코드수의 카운트를 돌려준다고 하는 점으로 다소 다르다.

    SELECT 그리고 1 개의 테이블에서 값을 꺼내, 다른 컬럼에게서는 값을 꺼내지 않고, 한편 WHERE 마디가 없는 경우,COUNT(*) (은)는 신속히 돌아오도록(듯이) 최적화된다.다음에 예를 나타낸다.

    mysql> SELECT COUNT(*) FROM student;

    이 최적화는,MyISAM 테이블과 ISAM 테이블에게만 적용된다.이것은, 이 2 개의 테이블형에서는 정확한 레코드 카운트가 격납되어 신속히 액세스 할 수 있기 때문에 있다.트랜잭션(transaction) 스토리지 엔진(InnodB, BDB )의 경우, 복수의 트랜잭션(transaction)가 발생해, 각각이 카운트에 영향을 주는 경우가 있기 위해, 정확한 레코드 카운트의 격납은 보다 어려워진다.

  • COUNT(DISTINCT expr,[expr...])

    NULL 이외가 다른 각 치의 수의 카운트를 돌려준다.

    mysql> SELECT COUNT(DISTINCT results) FROM student;

    MySQL 그럼, 식의 리스트를 지정하는 것에 의해서,NULL (을)를 포함하지 않는, 중복이 없는 식이 배합해의 수를 얻을 수 있다. SQL-99 그럼,COUNT(DISTINCT ...) 안에서 모든 식을 연결할 필요가 있다.

  • GROUP_CONCAT(expr)

    완전한 구문

    GROUP_CONCAT([DISTINCT] expr [,expr ...]
             [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC] [,col ...]]
             [SEPARATOR str_val])

    이 함수는 MySQL 버젼 4.1 그리고 추가되었다. 이 함수는 그룹내의 값을 연결한 결과의 문자열을 돌려준다.

    mysql> SELECT student_name,
    ->        GROUP_CONCAT(test_score)
    ->        FROM student
    ->        GROUP BY student_name;

또는
mysql> SELECT student_name,
    ->        GROUP_CONCAT(DISTINCT test_score
    ->                     ORDER BY test_score DESC SEPARATOR " ")
    ->        FROM student
    ->        GROUP BY student_name;

    MySQL 그럼, 식의 편성의 연결치를 얻을 수 있다. DISTINCT (을)를 사용하는 것으로, 중복 하는 값은 배제할 수 있다. 결과의 값을 소트 하려면 ,ORDER BY 마디를 사용한다. 반대의 순서로 소트 하려면 ,ORDER BY 마디로 소트 키로 하는 컬럼의 이름에 DESC (?~ 순서) 키워드를 붙인다.디폴트는 승순이지만, 승순을 명시적으로 지정하려면 ,ASC 키워드를 지정한다. SEPARATOR (은)는 결과의 값과 값의 사이에 삽입하는 문자열치를 나타낸다.디폴트는 콤마('","' ).단락 기호를 전혀 사용하지 않는 경우는,SEPARATOR "" (와)과 지정한다.

    사용 가능한 최대장은, 변수 group_concat_max_len (을)를 옵션 설정 파일에 기술하는 것으로 설정할 수 있다. 설정을 SQL 쿼리로 실시하는 구문은 다음대로.

    SET [SESSION | GLOBAL] group_concat_max_len = unsigned_integer;

    최대장이 설정되어 있는 경우, 결과는 이 최대장에 맞추어 잘라 버릴 수 있다.

    GROUP_CONCAT() 함수는,Sybase SQL Anywhere 그리고 서포트되고 있는 기본의 LIST() 함수를 확장한 실장이다. 컬럼이 1 개만으로, 그 외의 옵션이 지정되어 있지 않은 경우,GROUP_CONCAT() (은)는 기능이 꽤 제한되고 있다 LIST() (와)과 하위 호환이 된다.다만,LIST() 에는 디폴트의 소트 순서는 있다.

  • MIN(expr) , MAX(expr)

    expr 의 최소치 또는 최대치를 돌려준다.MIN() (와)과 MAX() (은)는 문자열 인수를 취할 수 있다.그 경우, 최소 또는 최대의 문자열치를 돌려준다. See 항5.4.3. 「MySQL (으)로의 인덱스의 사용」 .

    mysql> SELECT student_name, MIN(test_score), MAX(test_score)
    ->        FROM student
    ->        GROUP BY student_name;

    MySQL 그럼, 현재로서는,MIN() (와)과 MAX() (이)나 그 외의 집약 함수에 대해 ENUM 형태와 SET 형태의 컬럼의 비교를, 세트내에서의 문자열의 상대적인 위치는 아니고 각각의 문자열치에 근거해 가고 있다. 이것은 개정될 예정.

  • STD(expr) , STDDEV(expr)

    expr 의 표준 편차(VARIANCE() 의 평방근)을 돌려준다.이것은 SQL-99 에 대한 확장.이 함수의 STDDEV() 의 형식은 Oracle (와)과의 호환성을 확보하기 위해서 제공되고 있다.

  • SUM(expr)

    expr 의 합계를 돌려준다.주의: 반환값세트에 레코드가 포함되지 않은 경우,NULL (을)를 돌려준다.

  • VARIANCE(expr)

    expr 의 표준 편차를 돌려준다(레코드는 샘플이 아니고, 모집단 전체로 간주해진다.그 때문에, 이 함수는 레코드수를 분모로서 취한다).이것은 SQL-99 에 대한 확장(버젼 4.1 이?~ 그리고 사용 가능).

6.3.7.2. GROUP BY 의 수식자

MySQL 4.1.1 이?~ 그럼,GROUP BY 마디에 WITH ROLLUP 수식자를 사용하는 것에 의해서, 합계 출력에 추가의 레코드를 삽입할 수 있습니다.이러한 추가 레코드는 상위 레벨(상위 집약)의 집계 연산을 나타냅니다.그 때문에,ROLLUP 그럼, 복수의 분석 레벨로의 의문에 1 회의 쿼리로 대답할 수 있습니다.예를 들어, 이 수식자는,OLAP (온라인 분석 처리)(을)를 서포트하는 목적으로 사용할 수 있습니다.

예로서sales (이)라는 이름의 테이블에, 매상의 이익을 기록하기 위한 year ,country ,product ,profit (이)라는 이름의 컬럼이 있다고 합니다.

CREATE TABLE sales
(
    year    INT NOT NULL,
    country VARCHAR(20) NOT NULL,
    product VARCHAR(32) NOT NULL,
    profit  INT
);

이 테이블의 내용은, 다음과 같이, 단순한 GROUP BY 마디의 사용에 의해, 집계할 수 있습니다.

mysql> SELECT year, SUM(profit) FROM sales GROUP BY year;
+------+-------------+
| year | SUM(profit) |
+------+-------------+
| 2000 |        4525 |
| 2001 |        3010 |
+------+-------------+

이 출력에서는 매년도의 총이익을 알 수 있습니다만, 모든 연도의 이익을 합계한 총이익을 조사할 필요가 있는 경우는, 개개의 값을 스스로 더하는지, 또는 한번 더 쿼리를 실행하지 않으면 안됩니다.

그러나,ROLLUP (을)를 사용하면,2 개의 레벨의 분석을 1 회의 쿼리로 실행할 수 있습니다. GROUP BY 마디에 WITH ROLLUP 수식자를 추가하면, 쿼리로 모든 연도치를 더한 총계를 나타내는 레코드가 별도로 생성됩니다.

mysql> SELECT year, SUM(profit) FROM sales GROUP BY year WITH ROLLUP;
+------+-------------+
| year | SUM(profit) |
+------+-------------+
| 2000 |        4525 |
| 2001 |        3010 |
| NULL |        7535 |
+------+-------------+

총계의 상위 집약행은,year 컬럼의 값 NULL 에 의해서 나타납니다.

ROLLUP (은)는,GROUP BY 컬럼이 다수 있는 경우, 보다 복잡하게 작용합니다.이 경우, 마지막 그룹화 컬럼 이외의 장소에서 `` 브레이크'' (값의 변화)(이)가 있으면, 그때 그때 쿼리로 추가의 상위 집약의 집계 레코드가 생성됩니다.

예를 들어,ROLLUP (을)를 지정하고 있지 않는 경우에,sales 테이블의,year ,country ,product 에 근거하는 집계가 다음과 같이 출력된다고 합니다.

mysql> SELECT year, country, product, SUM(profit)
    -> FROM sales
    -> GROUP BY year, country, product;
+------+---------+------------+-------------+
| year | country | product    | SUM(profit) |
+------+---------+------------+-------------+
| 2000 | Finland | Computer   |        1500 |
| 2000 | Finland | Phone      |         100 |
| 2000 | India   | Calculator |         150 |
| 2000 | India   | Computer   |        1200 |
| 2000 | USA     | Calculator |          75 |
| 2000 | USA     | Computer   |        1500 |
| 2001 | Finland | Phone      |          10 |
| 2001 | USA     | Calculator |          50 |
| 2001 | USA     | Computer   |        2700 |
| 2001 | USA     | TV         |         250 |
+------+---------+------------+-------------+

이 출력은, 해/ 국/ 제품 레벨로의 분석에 있어서의 집계치만을 나타내고 있습니다.ROLLUP (을)를 추가하면, 쿼리로 몇개의 추가의 레코드가 생성됩니다.

mysql> SELECT year, country, product, SUM(profit)
    -> FROM sales
    -> GROUP BY year, country, product WITH ROLLUP;
+------+---------+------------+-------------+
| year | country | product    | SUM(profit) |
+------+---------+------------+-------------+
| 2000 | Finland | Computer   |        1500 |
| 2000 | Finland | Phone      |         100 |
| 2000 | Finland | NULL       |        1600 |
| 2000 | India   | Calculator |         150 |
| 2000 | India   | Computer   |        1200 |
| 2000 | India   | NULL       |        1350 |
| 2000 | USA     | Calculator |          75 |
| 2000 | USA     | Computer   |        1500 |
| 2000 | USA     | NULL       |        1575 |
| 2000 | NULL    | NULL       |        4525 |
| 2001 | Finland | Phone      |          10 |
| 2001 | Finland | NULL       |          10 |
| 2001 | USA     | Calculator |          50 |
| 2001 | USA     | Computer   |        2700 |
| 2001 | USA     | TV         |         250 |
| 2001 | USA     | NULL       |        3000 |
| 2001 | NULL    | NULL       |        3010 |
| NULL | NULL    | NULL       |        7535 |
+------+---------+------------+-------------+

이 쿼리의 경우,ROLLUP (을)를 추가하면, 단지 1 레벨이 아니고,4 레벨로의 분석에 있어서의 집계 정보가 출력에 짜넣어집니다.ROLLUP 의 출력은 다음과 같이 해석됩니다.

  • 특정의 연도와 나라에 대응하는 각 제품 레코드 세트의 뒤에, 제품마다의 모두 값의 합계를 나타내는 추가의 집계 레코드가 1 개씩 생성된다.이러한 레코드에서는,product 컬럼의 값이 NULL (으)로 설정된다.

  • 특정의 연도에 대응하는 각 레코드 세트의 뒤에, 나라마다, 제품마다의 모든 값의 합계를 나타내는 추가의 집계 레코드가 1 개씩 생성된다.이러한 레코드에서는,country 컬럼과 products 컬럼의 값이 NULL (으)로 설정된다.

  • 마지막으로, 다른 모든 레코드의 뒤에, 연도마다, 나라마다, 제품마다의 모든 값의 총계를 나타내는 추가의 집계 레코드가 1 개생성된다.이 레코드에서는,year ,country ,products 의 각 컬럼의 값이 NULL (으)로 설정된다.

ROLLUP 사용시의 그 외의 고려사항

이하에,MySQL 에 있어서의 ROLLUP 의 실장 고유의 동작에 대해서, 몇개인가 설명합니다.

ROLLUP 의 사용시에는,ORDER BY 마디를 사용해 결과를 소트 할 수 없습니다(ROLLUP (와)과 ORDER BY (은)는 상호 배타적입니다).그러나, 소트 순서를 어느 정도 제어하는 것은 가능합니다. MySQL 그리고 GROUP BY (을)를 사용하면 결과가 소트 됩니다.또,GROUP BY 리스트로 지정한 컬럼에 명시적인 ASC 또는 DESC 키워드를 붙이는 것에 의해서, 개개의 컬럼의 소트 순서를 지정할 수 있습니다(이 경우도,ROLLUP 에 의해서 추가되는 상위 레벨의 집계 레코드는, 소트 순서와는 관계되어 없고, 각각의 계산의 대상이 된 레코드의 뒤에 표시됩니다).

LIMIT (을)를 사용하면, 클라이언트에 돌려주어지는 레코드의 수를 제한할 수 있습니다.LIMIT 하 ROLLUP 의 후에 적용되기 위해, 제한은 ROLLUP 에 의해서 삽입되는 추가의 레코드에도 적용됩니다.다음에 예를 나타냅니다.

mysql> SELECT year, country, product, SUM(profit)
    -> FROM sales
    -> GROUP BY year, country, product WITH ROLLUP
    -> LIMIT 5;
+------+---------+------------+-------------+
| year | country | product    | SUM(profit) |
+------+---------+------------+-------------+
| 2000 | Finland | Computer   |        1500 |
| 2000 | Finland | Phone      |         100 |
| 2000 | Finland | NULL       |        1600 |
| 2000 | India   | Calculator |         150 |
| 2000 | India   | Computer   |        1200 |
+------+---------+------------+-------------+

주의: LIMIT (을)를 ROLLUP (와)과 함께 사용하면, 상위 집약 레코드를 이해하기 위한 문맥이 적게 되기 위해, 생성되는 결과의 해석이 어려워지는 일이 있습니다.

각 상위 집약 레코드의 NULL 인디케이터(indicator)는, 각 레코드가 클라이언트에 보내질 때 생성됩니다.서버는, 값이 바뀐 좌단의 컬럼의 뒤에,GROUP BY 마디로 지정된 각 컬럼을 확인합니다. 이러한 컬럼명과 어휘가 일치하는 이름을 가지는 컬럼이 결과 세트에 있으면, 그 컬럼의 값을 NULL (으)로 설정합니다(컬럼 번호에 의한 컬럼의 그룹화가 지정되어 있는 경우, 서버는 NULL (으)로 설정하는 컬럼을 번호로 식별합니다).

상위 집약 레코드의 NULL 값은 쿼리 처리의 뒤쪽의 단계에서 결과 세트에 짜넣어지기 위해, 쿼리 자체 중(안)에서 상위 집약 레코드를 NULL 값으로 해서 테스트할 수 없습니다.예를 들어, 쿼리에 HAVING product IS NULL (을)를 추가하고, 상위 집약 레코드 이외의 모든 출력을 배제할 수 없습니다.

그에 대해, 클라이언트측에서는,NULL 값이 표시되기 위해,MySQL 쿠라이안트프로그라?~ 그인타페스를 사용해 NULL 값으로 해서 테스트할 수 있습니다.

6.3.7.3. 비표시의 필드에 대한다 GROUP BY

MySQL 그럼 GROUP BY 의 사용을 확장하고 있습니다.GROUP BY 부분에 없는 컬럼이나 계산을 SELECT 식에서 사용할 수 있습니다.이것은, 그 그룹의 사용 가능한 모든 값 (을)를 나타냅니다.이 기능에 의해, 불요 항목에 대한 소트나 그룹화를 실시하지 않는 것으로, 퍼포먼스를 향상시킬 수 있습니다.예를 들어, 다음의 쿼리의 경우,customer.name (을)를 그룹화 할 필요는 없습니다.

mysql> SELECT order.custid,customer.name,MAX(payments)
    ->        FROM order,customer
    ->        WHERE order.custid = customer.custid
    ->        GROUP BY order.custid;

표준 SQL 그럼,customer.name (을)를 GROUP BY 마디에 짜넣을 필요가 있습니다.MySQL 그럼, 비 ANSI 모드로의 실행시에는 이 컬럼명은 불필요합니다.

GROUP BY 부분으로부터 없애는 컬럼이 그룹내에서 일의인 물건이 아닌 경우는, 이 기능을 사용하지 말아 주세요 .예측 불가능한 결과가 됩니다.

경우에 따라서는,MIN() (와)과 MAX() (을)를 사용하는 것에 의해서, 일의인 물건이 아닌 컬럼의 값을 꺼낼 수 있습니다.다음의 예에서는,sort 컬럼의 값이 가장 작은 레코드의 column 값을 얻을 수 있습니다.

SUBSTR(MIN(CONCAT(RPAD(sort,6,' '),column)),7)

See 항3.6.4. 「특정의 필드의 그룹마다의 최대치가 격납되고 있는 레코드」 .

주의: MySQL 버젼 3.22 (또는 이것보다 전의 버젼)(을)를 사용하고 있는 경우나,SQL-99 에 따를 필요가 있는 경우,GROUP BY 마디와 ORDER BY 마디에서는 식은 사용할 수 없습니다.이 제약은 식의 앨리어스(alias)를 사용하는 것에 의해서 회피할 수 있습니다.

mysql> SELECT id,FLOOR(value/100) AS val FROM tbl_name
    ->        GROUP BY id,val ORDER BY val;

MySQL 버젼 3.23 그럼, 다음과 같이 합니다.

mysql> SELECT id,FLOOR(value/100) FROM tbl_name ORDER BY RAND();


6.4. 데이터의 조작: SELECT ,INSERT ,UPDATE ,DELETE

6.4.1. SELECT 구문

SELECT [STRAIGHT_JOIN]
       [SQL_SMALL_RESULT] [SQL_BIG_RESULT] [SQL_BUFFER_RESULT]
       [SQL_CACHE | SQL_NO_CACHE] [SQL_CALC_FOUND_ROWS] [HIGH_PRIORITY]
       [DISTINCT | DISTINCTROW | ALL]
    select_expression,...
    [INTO {OUTFILE | DUMPFILE} 'file_name' export_options]
    [FROM table_references
      [WHERE where_definition]
      [GROUP BY {unsigned_integer | col_name | formula} [ASC | DESC], ...
        [WITH ROLLUP]]
      [HAVING where_definition]
      [ORDER BY {unsigned_integer | col_name | formula} [ASC | DESC] ,...]
      [LIMIT [offset,] row_count | row_count OFFSET offset]
      [PROCEDURE procedure_name(argument_list)]
      [FOR UPDATE | LOCK IN SHARE MODE]]

SELECT 하1 개이상의 테이블에서 레코드를 선택해 꺼낼 때 사용합니다. 각 select_expression (은)는, 꺼내는 컬럼을 나타냅니다. SELECT (은)는, 어느 테이블도 참조하는 일 없이, 계산에 의해서 구할 수 있던 레코드를 꺼낼 때도 사용할 수 있습니다.

다음에 예를 나타냅니다.

mysql> SELECT 1 + 1;
         -> 2

사용하는 마디는 모두, 구문의 설명으로 나타내 보이고 있는 순서와 완전히 같은 순서로 기술할 필요가 있습니다.예를 들어,HAVING 마디는 모든 GROUP BY 마디의 뒤에, 또 모든 ORDER BY 마디의 전에 배치하지 않으면 안됩니다.

  • SELECT 식에는,AS alias_name (을)를 사용해 앨리어스(alias)를 지정할 수 있다. 이 앨리어스(alias)는 식의 컬럼명으로서 사용되는 것으로,ORDER BY 마디 또는 HAVING 마디와 함께 사용할 수 있다.다음에 예를 나타낸다.

    mysql> SELECT CONCAT(last_name,', ',first_name) AS full_name
    FROM mytable ORDER BY full_name;

    SELECT 식의 앨리어스(alias)의 지정시,AS 키워드는 생략 할 수 있다. 전의 예는, 다음과 같이 기술하는 일도 가능.

    mysql> SELECT CONCAT(last_name,', ',first_name) full_name
    FROM mytable ORDER BY full_name;

    AS (은)는 생략 할 수 있기 위해,2 개의 SELECT 식의 사이에 콤마를 붙여 잊으면 미묘한 문제가 생기는 일이 있다.이 경우,2 번째의 식은 MySQL 에 의해서 앨리어스(alias)명으로서 해석된다.예를 들어, 다음의 스테이트먼트로,columnb (은)는 앨리어스(alias)명으로 간주해진다.

    mysql> SELECT columna columnb FROM mytable;

  • WHERE 마디에서는 컬럼명의 앨리어스(alias)는 사용할 수 없다.이것은,WHERE 마디의 실행 시점에서 컬럼치가 아직 판별되지 않는 것이 있기 위해. See 항A.5.4. 「alias 의 문제」 .

  • FROM table_references 마디는, 레코드의 꺼내 원의 테이블을 나타낸다.복수의 테이블을 지정하는 경우는, 결합 조작을 실행한다.결합 구문에 대해서는, 항6.4.1.1. 「JOIN 구문」 (을)를 참조. 지정하는 각 테이블에 대해서, 필요에 따라서, 그 테이블의 앨리어스(alias)를 지정할 수 있다.

    table_name [[AS] alias] [[USE INDEX (key_list)] | [IGNORE INDEX (key_list)] | FORCE INDEX (key_list)]]

    MySQL 버젼 3.23.12 이?~ 그럼, 테이블에서의 데이터의 꺼내 때에, 어느 인덱스를 사용해야할 것인가 MySQL 에 알리기 위한 힌트를 지정할 수 있다.이것은,EXPLAIN 그리고 MySQL 하지만 사용 가능한 인덱스의 리스트중에서 잘못된 인덱스를 사용하고 있는 것이 밝혀졌을 때에 도움이 된다.USE INDEX (key_list) (와)과 지정하는 것에 의해서, 사용 가능한 인덱스중에서 특정의 인덱스를 사용해 테이블내의 레코드를 검색하는 듯 MySQL 에 지시할 수 있다.이제(벌써) 1 개의 IGNORE INDEX (key_list) 구문은, 특정의 인덱스를 사용하지 않게 MySQL 에 지시할 경우에 사용한다.

    MySQL 4.0.9 그럼,FORCE INDEX 도 사용할 수 있다.이것은 USE INDEX (key_list) (와)과 같이 동작하지만, 다른 점으로서 이 구문의 경우, 테이블의 스캔은 매우 코스트가 걸린다고 하는 전제에 선다.즉, 테이블의 스캔이 실행되는 것은, 어느 인덱스를 사용해도 테이블내의 레코드를 검색할 수 없는 경우에 한정된다.

    USE/IGNORE/FORCE KEY 하 USE/IGNORE/FORCE INDEX 의 동의어.

    주의: USE/IGNORE/FORCE INDEX (은)는,MySQL 그리고 테이블내의 레코드의 검색 방법과 결합의 실행 방법을 결정할 때 어느 인덱스를 사용하는지, 라고 하는 점에게만 영향을 준다.ORDER BY (이)나 GROUP BY 의 해결시에 인덱스를 사용할지 영향을 주지 않는다.

    MySQL 4.0.14 그럼,MySQL 에 테이블의 스캔보다 키의 스캔을 우선시키기 위한 대체 방법으로서SET MAX_SEEKS_FOR_KEY=value 도 사용할 수 있다.

  • 테이블은(경향 데이타베이스내의 것이라면)tbl_name (으)로서 참조할 수 있다.데이타베이스를 명시적으로 지정하는 경우는,dbname.tbl_name (으)로서 참조한다. 컬럼은,col_name ,tbl_name.col_name , 또는 db_name.tbl_name.col_name (으)로서 참조할 수 있다.SELECT 스테이트먼트로 컬럼을 참조할 경우에는, 그 참조가 애매하게 안 되는 한, 컬럼명의 전에 tbl_name (이)나 db_name.tbl_name (을)를 붙일 필요는 없다.보다 명시적인 컬럼 참조 형식이 필요한 애매한 예에 대해서는, 항6.1.2. 「데이타베이스명, 테이블명, 인덱스명, 컬럼명, 앨리어스(alias)명」 (을)를 참조.

  • 버젼 4.1.0 이?~ 그럼, 어느 테이블도 참조되지 않는 상황에 있고, 다?~ -테이블명으로서 DUAL (을)를 지정할 수 있다.이것은 오로지 호환성을 고려한 기능이다.일부의 다른 서버에서는 이 구문이 필요하다.

    mysql> SELECT 1 + 1 FROM DUAL;
         -> 2

  • 테이블 참조에는,tbl_name [AS] alias_name (을)를 사용해 앨리어스(alias)를 지정할 수 있다.

    mysql> SELECT t1.name, t2.salary FROM employee AS t1, info AS t2
    ->        WHERE t1.name = t2.name;
mysql> SELECT t1.name, t2.salary FROM employee t1, info t2
    ->        WHERE t1.name = t2.name;

  • 출력용으로 선택되는 컬럼은,ORDER BY 마디와 GROUP BY 마디에 대하고, 컬럼명, 컬럼 앨리어스(alias), 또는 컬럼 위치를 사용해 참조할 수 있다.컬럼 위치는 1 (으)로부터 시작된다.

    mysql> SELECT college, region, seed FROM tournament
    ->        ORDER BY region, seed;
mysql> SELECT college, region AS r, seed AS s FROM tournament
    ->        ORDER BY r, s;
mysql> SELECT college, region, seed FROM tournament
    ->        ORDER BY 2, 3;

    반대의 순서로 소트 하려면 ,ORDER BY 마디에 대하고 소트 키로 하는 컬럼의 이름에 DESC (?~ 순서) 키워드를 붙인다. 디폴트는 승순이지만, 승순을 명시적으로 지정하려면 ,ASC 키워드를 지정한다.

  • WHERE 마디에서는,MySQL 그리고 서포트하고 있는 임의의 기능을 사용할 수 있지만, 예외로서 집약(집계) 기능만은 사용할 수 없다. See 항6.3. 「SELECT 마디와 WHERE 마디로 사용하는 함수」 .

  • HAVING 마디에서는,select_expression 그리고 지정한 임의의 컬럼 또는 앨리어스(alias)를 참조할 수 있다.이 마디는, 처리의 끝나 근처가 되고(항목이 클라이언트에 보내지기 직전), 최적화되는 일 없이 적용된다(LIMIT 하 HAVING 의 후에 적용).WHERE 마디에 짜넣어야 할 항목에 대해서는,HAVING (을)를 사용해서는 안 된다.예를 들어, 다음과 같이 기술하지 않게 한다.

    mysql> SELECT col_name FROM tbl_name HAVING col_name > 0;

    정확하게는 다음과 같이 기술한다.

    mysql> SELECT col_name FROM tbl_name WHERE col_name > 0;

    MySQL 버젼 3.22.5 이?~ 그럼, 다음과 같은 쿼리도 사용할 수 있다.

    mysql> SELECT user,MAX(salary) FROM users
    ->        GROUP BY user HAVING MAX(salary)>10;

    그것보다 전의 MySQL 버젼에서는, 대신에 다음과 같이 기술한다.

    mysql> SELECT user,MAX(salary) AS sum FROM users
    ->        group by user HAVING sum>10;

  • DISTINCT ,DISTINCTROW ,ALL 의 각 옵션에서는, 중복 레코드를 돌려줄지를 지정한다.디폴트(ALL )에서는, 매치하는 모든 레코드가 돌려주어진다.DISTINCT (와)과 DISTINCTROW (은)는 동의어로, 이것들을 지정했을 경우, 결과 세트로부터 중복 레코드가 삭제된다.

  • STRAIGHT_JOIN (와)과 HIGH_PRIORITY , 및 SQL_ 그리고 시작되는 각 옵션은,SQL-99 에 대한다 MySQL 의 확장.

    • STRAIGHT_JOIN 그럼, Optimizer에,FROM 마디로 지정된 순서로 강제적으로 테이블을 결합시킬 수 있다.Optimizer가 최적이지 않은 순서로 테이블을 결합할 경우에는, 이 옵션을 사용하는 것에 의해서, 쿼리를 고속화할 수 있다. See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

    • HIGH_PRIORITY (을)를 지정하면,SELECT 스테이트먼트가 테이블을 갱신하는 스테이트먼트보다 우선된다.이 옵션은, 매우 신속히 처리되어 한편 즉시 실행할 필요가 있는 쿼리 에 대해서만 사용하도록(듯이) 한다.SELECT HIGH_PRIORITY 쿼리는, 대상의 테이블이 읽어내용으로 락 되면, 비록 테이블이 해방되는 것을 기다리고 있는 갱신 스테이트먼트가 있어도, 실행된다.

    • SQL_BIG_RESULT (은)는,GROUP BY 또는 DISTINCT (와)과 함께 사용할 수 있어 거기에 따르고, 결과 세트에 많은 레코드가 짜넣어지는 것을 Optimizer에 통지할 수 있다.이 경우,MySQL 그리고, 디스크 베이스의 일시 테이블이 필요에 따라서 직접 사용된다. 또, 이 경우,GROUP BY 요소의 키로 일시 테이블을 처리하는 것보다 소트를 실시하는 편이 우선된다.

    • SQL_BUFFER_RESULT 그럼, 결과가 일시 테이블에 강제적으로 격납된다.결과 세트를 클라이언트에 보내는데 시간이 걸리는 경우에는, 이 옵션을 지정하는 것에 의해서,MySQL 에 의한 테이블의 락을 빨리 해방시킬 수 있다.

    • SQL_SMALL_RESULT 하 MySQL 고유의 옵션.이 옵션을 GROUP BY 또는 DISTINCT (와)과 함께 사용하는 것으로, 결과 세트가 작은 것이 되는 것을 Optimizer에 통지할 수 있다.이 경우, 소트를 실시하는 대신에, 신속한 일시 테이블을 사용해 결과의 테이블이 격납된다.MySQL 버젼 3.23 그럼, 통상, 이 옵션을 사용할 필요는 없다.

    • SQL_CALC_FOUND_ROWS (버젼 4.0.0 이?~ )에서는,LIMIT 마디를 무시했을 경우에 결과 세트에 포함되는 모든 레코드수를 계산하는 듯 MySQL 에 지시할 수 있다. 그 후,SELECT FOUND_ROWS() (을)를 사용하고, 계산된 레코드수를 꺼낼 수 있다. See 항6.3.6.2. 「그 외의 각종 함수」 .

      주의: 4.1.0 보다 전의 버젼에서는,LIMIT 0 (을)를 지정했을 경우, 이 옵션은 기능하지 않는다.이 경우, 신속히 돌아오도록(듯이) 최적화된다(그 결과, 레코드 카운트는 0 (이)가 된다). See 항5.2.9. 「MySQL 에 의한다 LIMIT 의 최적화」 .

    • SQL_CACHE 그럼,QUERY_CACHE_TYPE=2 (DEMAND )(을)를 사용했을 경우에, 쿼리의 결과를 쿼리 캐쉬에 격납하는 듯 MySQL 에 지시할 수 있다. See 항6.9. 「MySQL 쿼리 캐쉬」 . UNION 또는 서브 쿼리를 사용한 쿼리에서는, 이 옵션은 쿼리의 모든 SELECT 스테이트먼트로 적용된다.

    • SQL_NO_CACHE 그럼, 쿼리의 결과를 쿼리 캐쉬에 격납하지 않게,MySQL 에 지시할 수 있다. See 항6.9. 「MySQL 쿼리 캐쉬」 . UNION 또는 서브 쿼리를 사용한 쿼리에서는, 이 옵션은 쿼리의 모든 SELECT 스테이트먼트로 적용된다.

  • GROUP BY (을)를 사용하면,GROUP BY 의 모든 필드에 대해서 ORDER BY (을)를 사용했을 경우와 같이, 출력 레코드가 GROUP BY (으)로 지정한 기준에 근거해 소트 된다.MySQL 그럼,GROUP BY 마디를 확장하고 있어, 이 마디로 지정한 컬럼의 뒤에 ASC (와)과 DESC 의 어느쪽이든을 지정할 수 있다.

    SELECT a,COUNT(b) FROM test_table GROUP BY a DESC

  • MySQL 그럼,GROUP BY 의 사용을 확장하고 있어,GROUP BY 마디로 지정하지 않은 필드도 선택할 수 있다. 쿼리로 기대한 결과를 얻을 수 없는 경우는,GROUP BY 의 설명을 참조. See 항6.3.7. 「GROUP BY 마디로 사용하는 함수와 수식자」 .

  • MySQL 4.1.1 이?~ ,GROUP BY 에는 WITH ROLLUP 수식자를 사용할 수 있다. See 항6.3.7.2. 「GROUP BY 의 수식자」 .

  • LIMIT 마디를 사용하면,SELECT 스테이트먼트로 돌려주어지는 레코드수를 제한할 수 있다.LIMIT 하 1 개 또는 2 개의 수치 인수를 취한다.이러한 인수는 정수 정수가 아니면 안된다.

    인수가 1 개의 경우, 그 값은, 반환값으로서 돌려주는, 결과 세트의 모두로부터의 레코드수를 나타낸다. 인수가 2 개의 경우, 최초의 인수는 반환값으로서 돌려주는 최초의 레코드까지의 오프셋을 나타내,2 번째의 인수는 반환값으로서 돌려주는 최대 레코드수를 나타낸다.최초의 레코드의 오프셋치는 0 (1 (은)는 아니다).

    PostgreSQL (와)과의 호환성을 확보하기 위해(때문에),MySQL 그럼 LIMIT row_count OFFSET offset 구문도 서포트하고 있다.

    mysql> SELECT * FROM table LIMIT 5,10;  # Retrieve rows 6-15

    특정의 오프셋 위치로부터 결과 세트의 마지막까지의 모든 레코드를 꺼내려면 ,2 번째의 파라미터에 큰 수치를 지정할 수 있다.

    mysql> SELECT * FROM table LIMIT 95,18446744073709551615; # Retrieve rows 96-last.

    인수가 1 개의 경우, 그 값은 반환값으로서 돌려주는 최대 레코드수를 나타낸다.

    mysql> SELECT * FROM table LIMIT 5;     # Retrieve first 5 rows

    즉,LIMIT n 하 LIMIT 0,n (와)과 지정하는 것과 같다.

  • SELECT ... INTO OUTFILE 'file_name' 형식의 SELECT 그럼,SELECT 한 레코드가 파일에 써진다.파일은 서버 호스트상에 작성된다.기존의 파일을 지정할 수 없다(이 제한은, 특히,/etc/passwd 등의 데이타베이스 테이블이나 파일이 파괴되지 않게 하기 위한(해)).이 형식의 SELECT (을)를 사용하려면 , 서버 호스트에 대한다 FILE 권한이 필요하다.

    SELECT ... INTO OUTFILE 스테이트먼트의 용도는, 주로, 서버머신상의 테이블의 덤프를 극히 신속히 실행할 수 있도록 하는 것이다.서버 호스트 이외의 호스트에게 결과의 파일을 작성할 필요가 있을 때는,SELECT ... INTO OUTFILE (은)는 사용할 수 없다.이 경우, 대신에,mysqldump --tab (이)나 mysql -e "SELECT ..." > outfile 등의 클라이언트 프로그램을 사용해 파일을 생성한다.

    SELECT ... INTO OUTFILE 하 LOAD DATA INFILE 의 역.이 스테이트먼트의 export_options 부분의 구문은,LOAD DATA INFILE 스테이트먼트로 사용된다 FIELDS 및 LINES 마디와 같은 구성이 되어 있다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

    결과의 텍스트 파일에서는, 이하의 문자만이 ESCAPED BY 지정의 문자로 이스케이프 된다.

    • ESCAPED BY 지정 문자 자체

    • FIELDS TERMINATED BY 지정의 최초의 문자

    • LINES TERMINATED BY 지정의 최초의 문자

    또,ASCII 0 (은)는,ESCAPED BY 의 지정 문자의 뒤로 0 (ASCII 48 )(을)를 붙인 것에 변환된다.

    상기의 문자를 이스케이프 하는 이유는, 파일을 확실히 다시 읽을 수 있도록(듯이) 하려면 ,FIELDS TERMINATED BY ,ESCAPED BY ,LINES TERMINATED BY 지정되어 있는 문자를 모두 이스케이프 해야 한다 싶은.ASCII 0 (은)는 일부의 pager로의 표시를 용이화하기 위해서 이스케이프 된다.

    결과의 파일은 SQL 의 구문에 따를 필요는 없기 때문에, 그 외의 이스케이프 처리는 필요없다.

    다음에, 많은 낡은 프로그램으로 사용되고 있는 형식에서 파일을 생성하는 예를 나타낸다.

    SELECT a,b,a+b INTO OUTFILE "/tmp/result.text"
FIELDS TERMINATED BY ',' OPTIONALLY ENCLOSED BY '"'
LINES TERMINATED BY "\n"
FROM test_table;

  • INTO OUTFILE 대신에 INTO DUMPFILE (을)를 사용하면,MySQL 에 의해서 파일에 1 개의 레코드만이 써진다.이 경우, 컬럼이나 행의 종료는 아무것도 포함되지 않고, 이스케이프 처리도 전혀 행해지지 않는다.이것은, 파일에 BLOB 값을 격납할 경우에 도움이 된다.

  • 주의: INTO OUTFILE (와)과 INTO DUMPFILE 그리고 작성되는 파일은, 서버 호스트상에 있는 어카운트로 써 가능한가도 모른다.그 이유는,MySQL 서버를 실행하고 있는 어카운트로, 그것들 파일을 작성하기 때문이어, 작성된 파일은 그 어카운트가 오너가 되어 있기 때문이다(mysqld 하 root (으)로서 실행 해서는 안된다). 파일의 내용을 조작할 수 있도록 하려면 , 파일을 전유저 써 가능하게 할 필요가 있다.

  • PROCEDURE 마디에는, 결과 세트내의 데이터의 처리에 사용하는 프로시저를 지정한다.예에 대해서는, 항13.3.1. 「프로시저의 분석」 (을)를 참조.

  • 페이지 락 또는 행 락 기능이 있는 스토리지 엔진에 대해서 FOR UPDATE (을)를 사용하면, 현재의 트랜잭션(transaction)가 종료할 때까지, 검사 대상의 레코드는 기입에 대해서 락 된다.

6.4.1.1. JOIN 구문

MySQL 그럼,SELECT 스테이트먼트로의 이하의 JOIN 구문의 사용을 서포트하고 있습니다.

table_reference, table_reference
table_reference [INNER | CROSS] JOIN table_reference [join_condition]
table_reference STRAIGHT_JOIN table_reference
table_reference LEFT [OUTER] JOIN table_reference [join_condition]
table_reference NATURAL [LEFT [OUTER]] JOIN table_reference
{ OJ table_reference LEFT OUTER JOIN table_reference ON conditional_expr }
table_reference RIGHT [OUTER] JOIN table_reference [join_condition]
table_reference NATURAL [RIGHT [OUTER]] JOIN table_reference

table_reference (은)는 다음과 같이 정의합니다.

table_name [[AS] alias] [[USE INDEX (key_list)] | [IGNORE INDEX (key_list)] | [FORCE INDEX (key_list)]]

join_condition (은)는 다음과 같이 정의합니다.

ON conditional_expr |
USING (column_list)

결과 세트에 포함하는 레코드를 제한하기 위해서 사용한다 ON 부분에는, 통상, 조건은 아무것도 지정하지 않습니다.그러한 조건은 WHERE 마디로 지정합니다.다만, 이 규칙에는 예외가 있습니다.

주의:INNER JOIN 구문으로 join_condition (을)를 사용할 수 있는 것은,MySQL 3.23.17 이?~ 에 한정됩니다.같이JOIN (와)과 CROSS JOIN 에 관해서도,MySQL 4.0.11 이?~ 에서만 조건을 지정할 수 있습니다.

위의 구문 리스트의 마지막에 들었다 LEFT OUTER JOIN 구문은, 단지 ODBC (와)과의 호환성을 확보하기 위한의 것입니다.

  • 테이블 참조에서는,tbl_name AS alias_name 또는 tbl_name alias_name (을)를 사용해 앨리어스(alias)을 지정할 수 있다.

    mysql> SELECT t1.name, t2.salary FROM employee AS t1, info AS t2
    ->        WHERE t1.name = t2.name;

  • ON 조건구에는,WHERE 마디로 사용할 수 있는 형식의 임의의 조건을 지정할 수 있다.

  • LEFT JOIN 의 ON 또는 USING 부분에 우측의 테이블에 매치하는 레코드가 없는 경우, 모든 컬럼을 NULL (으)로 설정했다 1 개의 레코드가 우측의 테이블로서 사용된다.이 규칙에 근거하고, 대응하는 레코드가 다른 테이블에 존재하지 않는 레코드를 테이블내에서 검색할 수 있다.

    mysql> SELECT table1.* FROM table1
    ->        LEFT JOIN table2 ON table1.id=table2.id
    ->        WHERE table2.id IS NULL;

    이 예에서는,table2 에 존재하지 않는다 id 값을 가지는 모든 레코드(table2 에 대응하는 레코드가 없는 모든 레코드)가 table1 그리고 검색된다.당연, 이 경우,table2.id 하지만 NOT NULL (으)로서 선언되고 있는 것이 전제가 된다. See 항5.2.7. 「MySQL 에 의한다 LEFT JOIN (와)과 RIGHT JOIN 의 최적화」 .

  • USING (column_list) 마디로 지정하는 컬럼 리스트내의 컬럼은, 양쪽 모두의 테이블에 존재해야 한다.다음의 2 개의 마디는 같은 것을 의미한다.

    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

  • 2 개의 테이블의 NATURAL [LEFT] JOIN 의 정의는, 양쪽 모두의 테이블에 존재하는 모든 컬럼을 지정했다 USING 마디를 가진다 INNER JOIN 또는 LEFT JOIN (와)과 같은 의미가 된다.

  • INNER JOIN (와)과 , (콤마)(은)는, 결합 조건이 지정되어 있지 않은 경우, 같은 의미가 되어, 어느 쪽에 대해서도, 지정된 테이블간에 데카르트적이 생성된다(즉, 최초의 테이블의 각 레코드가 2 번째의 테이블의 모든 레코드에 결합된다).

  • RIGHT JOIN 하 LEFT JOIN 의 유사 기능.코드를 데이타베이스간에 이식 가능하게 하려면 ,RIGHT JOIN (은)는 아니고 LEFT JOIN (을)를 사용하도록(듯이) 한다.

  • STRAIGHT_JOIN 하 JOIN (와)과 같은 것이지만, 다른 점으로서STRAIGHT_JOIN 그럼 항상 우측의 테이블의 전에 좌측의 테이블이 읽어내진다.이 구문은, 결합 Optimizer에 의해서 테이블이 잘못된 순서로 늘어놓을 수 있다고 하는(보기 드문) 사태에 대처하기 위해서 사용할 수 있다.

  • MySQL 버젼 3.23.12 이?~ 그럼, 테이블에서의 데이터의 꺼내 때에, 어느 인덱스를 사용해야할 것인가 MySQL 에 알리기 위한 힌트를 지정할 수 있다.이것은,EXPLAIN 그리고 MySQL 하지만 사용 가능한 인덱스의 리스트중에서 잘못된 인덱스를 사용하고 있는 것이 밝혀졌을 때에 도움이 된다.USE INDEX (key_list) (와)과 지정하는 것에 의해서, 사용 가능한 인덱스중에서 특정의 인덱스를 사용해 테이블내의 레코드를 검색하는 듯 MySQL 에 지시할 수 있다.이제(벌써) 1 개의 IGNORE INDEX (key_list) 구문은, 특정의 인덱스를 사용하지 않게 MySQL 에 지시할 경우에 사용한다.

    MySQL 4.0.9 그럼,FORCE INDEX 도 사용할 수 있다.이것은 USE INDEX (key_list) (와)과 같이 동작하지만, 다른 점으로서 이 구문의 경우, 테이블의 스캔은 매우 코스트가 와 말하는 전제에 선다.즉, 테이블의 스캔이 실행되는 것은, 어느 인덱스를 사용해도 테이블내의 레코드를 검색할 수 없는 경우에 한정된다.

    USE/IGNORE KEY 하 USE/IGNORE INDEX 의 동의어.

주의: USE/IGNORE/FORCE INDEX (은)는,MySQL 그리고 테이블내의 레코드의 검색 방법과 결합의 실행 방법을 결정할 때 어느 인덱스를 사용하는지, 라고 하는 점에게만에 영향을 줍니다.ORDER BY (이)나 GROUP BY 의 해결시에 인덱스를 사용할지 영향을 주지 않습니다.

이하에, 예를 몇개인가 나타내 보입니다.

mysql> SELECT * FROM table1,table2 WHERE table1.id=table2.id;
mysql> SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id;
mysql> SELECT * FROM table1 LEFT JOIN table2 USING (id);
mysql> SELECT * FROM table1 LEFT JOIN table2 ON table1.id=table2.id
    ->          LEFT JOIN table3 ON table2.id=table3.id;
mysql> SELECT * FROM table1 USE INDEX (key1,key2)
    ->          WHERE key1=1 AND key2=2 AND key3=3;
mysql> SELECT * FROM table1 IGNORE INDEX (key3)
    ->          WHERE key1=1 AND key2=2 AND key3=3;

See 항5.2.7. 「MySQL 에 의한다 LEFT JOIN (와)과 RIGHT JOIN 의 최적화」 .

6.4.1.2. UNION 구문

SELECT ...
UNION [ALL]
SELECT ...
  [UNION
   SELECT ...]

UNION 하 MySQL 4.0.0 그리고 도입되었습니다.

UNION (은)는, 많은 SELECT 스테이트먼트를 1 개의 결과 세트에 결합하기 위해서 사용합니다.

SELECT 의 select_expression 부분의 컬럼 리스트에는, 같은 형태의 컬럼을 지정합니다.최초의 SELECT 쿼리로 지정한 컬럼명이, 돌려주어지는 결과의 컬럼명으로서 사용됩니다.

이러한 SELECT 커멘드는 통상의 SELECT 커멘드입니다만, 다음의 제한이 적용됩니다.

  • 마지막 SELECT 커멘드에게만 INTO OUTFILE (을)를 지정할 수 있다.

UNION 에 키워드 ALL (을)를 붙이지 않으면 총결과 세트에 대해서 DISTINCT (을)를 지정했을 경우와 같이, 중복 하지 않는 일의인 레코드만이 돌려주어집니다.ALL (을)를 지정하면, 실행된 모든 SELECT 스테이트먼트로부터, 일치하는 모든 레코드가 돌려주어집니다.

UNION 의 총결과에 대해서 ORDER BY (을)를 적용할 필요가 있을 때는, 외모를 사용합니다.

(SELECT a FROM table_name WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM table_name WHERE a=11 AND B=2 ORDER BY a LIMIT 10)
ORDER BY a;

UNION 의 결과 세트내의 컬럼의 형태와 길이에서는, 모든 SELECT 스테이트먼트로 꺼내진 값이 고려됩니다. MySQL 4.1.1 보다 전의 버젼의 UNION 그럼, 최초의 SELECT 그리고 사용된 값에만 기초를 두어 결과의 형태와 길이가 정해진다, 라고 하는 제약이 있었습니다. 이 경우, 예를 들어, 최초의 SELECT 의 값보다 긴 값이 2 번째의 SELECT 그리고 꺼내지면, 잘라서 버림을 하는 일이 있습니다.

mysql> SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);
+---------------+
| REPEAT('a',1) |
+---------------+
| a             |
| b             |
+---------------+

MySQL 4.1.1 이?~ , 이 제약은 없어졌습니다.

mysql> SELECT REPEAT('a',1) UNION SELECT REPEAT('b',10);
+---------------+
| REPEAT('a',1) |
+---------------+
| a             |
| bbbbbbbbbb    |
+---------------+

6.4.2. 서브 쿼리 구문

서브 쿼리는, 다른 스테이트먼트에 포함되었다 SELECT 스테이트먼트입니다. 다음에 예를 나타냅니다.

SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);

위의 예로, SELECT * FROM t1 ... 하 외측의 쿼리 (또는 외측의 스테이트먼트 )(이어)여,(SELECT column1 FROM t2) 하 서브 쿼리 입니다. 말하자면, 서브 쿼리는 외측의 쿼리내에 네스트 되고 있게 됩니다.실제의 곳, 서브 쿼리내에 한층 더 서브 쿼리를 네스트 해, 쿼리를 몇 겹이나 상자화할 수 있습니다. 서브 쿼리는 반드시 외모로 둘러쌀 필요가 있습니다.

MySQL 버젼 4.1 이?~ 그럼, 표준 SQL 그리고 규정되고 있는 서브 쿼리의 모든 형식과 조작에 가세해MySQL 고유의 몇개의 기능을 서포트하고 있습니다.서브 쿼리를 사용하는 주된 이점은 다음과 같습니다.

  • 쿼리의 각 부분이 서로 분리되도록(듯이), 쿼리를 기술할 수 있다.

  • 복잡한 결합이나 집합 처리를 필요로 하는 조작을, 그러한 처리를 실시하지 않고 실행할 수 있다.

  • (많은 사람들의 의견으로서) 판독하기 쉽다. 사실, 초기의 SQL 하지만 `` 구조화 문의 언어'' (으)로 불리게 된 계기는, 서브 쿼리에 있다.

버젼 4.0 보다 전의 MySQL 그럼, 서브 쿼리의 사용을 피하거나 그 사용에 대처할 필요가 있었습니다만, 지금부터 코드를 쓰기 시작하는 사람들은, 서브 쿼리가 툴 킷의 매우 편리한 요소인 것을 알 수 있을 것입니다.

다음의 스테이트먼트예는, 표준 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)));

4.1 보다 전의 버젼의 MySQL 에 대해서는, 결합등의 방법에 의해서, 대부분의 서브 쿼리를 다시 기술할 수 있습니다. See 항6.4.2.11. 「초기의 MySQL 버젼에 맞춘 서브 쿼리의 개서」 .

6.4.2.1. 스칼라 오퍼랜드로서의 서브 쿼리

가장 단순한 형식( 스칼라 부문의해)에서는, 서브 쿼리는 단순한 오퍼랜드입니다(스칼라부문의와 대립하는 것으로서 행 또는 테이블 부문의가 있습니다.이것들에 대해서는 후술 합니다).따라서, 서브 쿼리는, 올바른 컬럼치나 리터럴이 사용되고 있는 곳(중)이라면 어디에서라도 사용할 수 있어 또, 다른 모든 오퍼랜드와 같이, 데이터형, 길이, 값이 NULL (이)가 되는 경우가 있을지의 구별등의 특성을 가집니다. 다음에 예를 나타냅니다.

CREATE TABLE t1 (s1 INT, s2 CHAR(5) NOT NULL);
SELECT (SELECT s2 FROM t1);

위의 SELECT 안의 서브 쿼리의 데이터형은 CHAR 그리고, 길이는 5 입니다.또,CREATE TABLE 시간에 대해 유효한 디폴트의 캐릭터 세트와 조합 순서를 가지고 있어 컬럼치가 NULL 의 경우가 있는 것이 나타나고 있습니다.사실, 거의 모든 서브 쿼리는 NULL (이)가 되는 경우가 있습니다.이것은, 예에 있도록(듯이) 테이블이 하늘의 경우, 서브 쿼리의 값이 NULL (이)가 되기 (위해)때문입니다. 다음에 나타내는, 몇 안 되는 제약이 있습니다.

  • 서브 쿼리의 외측의 스테이트먼트로서는,SELECT ,INSERT ,UPDATE ,DELETE ,SET ,DO 의 어느쪽이든을 사용할 수 있다.

  • 서브 쿼리에는, 통상의 SELECT 에 짜넣을 수 있는 임의의 키워드 또는 마디(DISTINCT ,GROUP BY ,ORDER BY ,LIMIT , 결합, 힌트,UNION 구조, 코멘트, 함수등)을 짜넣을 수 있다.

그 때문에, 이?~ 의 섹션에서는, 어느 쪽인가 하면 간소한 구조 (SELECT column1 FROM t1) (을)를 포함한 예를 나타내고 있습니다만, 실제의 코드에는 더 다양하고 복잡한 구조가 포함되면 상상해 주세요.

예를 들어, 다음과 같이 2 개의 테이블을 만든다고 합니다.

CREATE TABLE t1 (s1 INT);
INSERT INTO t1 VALUES (1);
CREATE TABLE t2 (s1 INT);
INSERT INTO t2 VALUES (2);

그 후,SELECT (을)를 실행합니다.

SELECT (SELECT s1 FROM t2) FROM t1;

결과는 2 (이)가 됩니다.왜냐하면,t2 에는, 컬럼 s1 (을)를 가지는 레코드가 있어,s1 의 값은 2 이기 (위해)때문입니다.

서브 쿼리는 식의 일부로 할 수 있습니다.함수의 오퍼랜드로 할 때는, 외모를 잊지 말아 주세요. 다음에 예를 나타냅니다.

SELECT UPPER((SELECT s1 FROM t1)) FROM t2;

6.4.2.2. 서브 쿼리를 사용한 비교

서브 쿼리의 가장 일반적은 사용법은, 다음의 형식의 것입니다.

<non-subquery operand> <comparison operator> (<subquery>)

<comparison operator> 에는, 다음의 어느쪽이든을 지정합니다.

= > < >= <= <>

다음에 예를 나타냅니다.

... 'a' = (SELECT column1 FROM t1)

이전에는, 서브 쿼리를 배치하는 올바른 위치는 비교의 우측으로 한정되어 있었습니다.일부의 낡다 DBMS 그리고, 지금도 이 제약이 적용되고 있는 일이 있습니다.

다음에 나타내는 것은, 결합에서는 처리할 수 없는, 일반적인 형식의 서브 쿼리를 사용한 비교의 예입니다.이 예에서는, 테이블 t2 의 최대치로 동일한 모든 값이 테이블 t1 그리고 검색됩니다.

SELECT column1 FROM t1
       WHERE column1 = (SELECT MAX(column2) FROM t2);

이제(벌써) 1 개예를 나타냅니다.테이블의 1 개에 대한 집약이 포함되어 있기 때문에, 이 경우도 결합에서는 처리할 수 없습니다.이 예에서는,2 회출현하는 값을 가지는 모든 레코드가 테이블 t1 그리고 검색됩니다.

SELECT * FROM t1
       WHERE 2 = (SELECT COUNT(column1) FROM t1);

6.4.2.3. ANY ,IN ,SOME (와)과 함께 사용한 서브 쿼리

구문

<operand> <comparison operator> ANY (<subquery>)
<operand> IN (<subquery>)
<operand> <comparison operator> SOME (<subquery>)

ANY 그렇다고 하는 말은 비교 연산자의 뒤로 지정하는 것으로,`` 서브 쿼리가 돌려주는 레코드의 ANY (어느쪽이든)에 대해서 비교가 TRUE 의 경우 TRUE (을)를 돌려준다'' 일을 나타냅니다. 다음에 예를 나타냅니다.

SELECT s1 FROM t1 WHERE s1 > ANY (SELECT s1 FROM t2);

테이블 t1 에 {10} 그렇다고 하는 값을 포함한 레코드가 있다고 합니다. 테이블 t2 에 포함되어 있는 값이 {21,14,7} 의 경우, 이 식은 TRUE (이)가 됩니다.왜냐하면 t2 에,10 보다 작다 7 그렇다고 하는 값이 존재하기 때문입니다. 테이블 t2 에 포함되어 있는 값이 {20,10} 의 경우나, 테이블 t2 하지만 하늘의 경우, 이 식은 FALSE (이)가 됩니다. 테이블 t2 에 포함되어 있는 값이 {NULL,NULL,NULL} 의 경우, 이 식은 UNKNOWN (이)가 됩니다.

IN 그렇다고 하는 말은 = ANY 의 앨리어스(alias)입니다.따라서, 다음의 2 개의 스테이트먼트는 같습니다.

SELECT s1 FROM t1 WHERE s1 = ANY (SELECT s1 FROM t2);
SELECT s1 FROM t1 WHERE s1 IN    (SELECT s1 FROM t2);

SOME 그렇다고 하는 말은 ANY 의 앨리어스(alias)입니다.따라서, 다음의 2 개의 스테이트먼트는 같습니다.

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'' 그렇다고 하는 영어의 프레이즈를, 대부분의 사람은 ``a (와)과 동일하다 b (은)는 전혀 존재하지 않는다'' 그렇다고 하는 의미에 받습니다.그러나,SQL 구문에서는 의미가 다릅니다.ANY 대신에 <> SOME (을)를 사용하는 것에 의해서, 이 쿼리의 진짜 의미를 누구나가 확실히 이해할 수 있도록 할 수 있습니다.

6.4.2.4. ALL (와)과 함께 사용한 서브 쿼리

구문

<operand> <comparison operator> ALL (<subquery>)

ALL 그렇다고 하는 말은 비교 연산자의 뒤로 지정하는 것으로,`` 서브 쿼리가 돌려주는 레코드의 ALL (모두)에 대해서 비교가 TRUE 의 경우 TRUE (을)를 돌려준다'' 일을 나타냅니다. 다음에 예를 나타냅니다.

SELECT s1 FROM t1 WHERE s1 > ALL (SELECT s1 FROM t2);

테이블 t1 에 {10} 그렇다고 하는 값을 포함한 레코드가 있다고 합니다. 테이블 t2 에 포함되어 있는 값이 {-5,0,+5} 의 경우, 이 식은 TRUE (이)가 됩니다.왜냐하면 t2 에 포함되어 있는 값은 모두 10 보다 작기 때문입니다. 테이블 t2 에 포함되어 있는 값이 {12,6,NULL,-100} 의 경우, 이 식은 FALSE (이)가 됩니다.왜냐하면 t2 에,10 보다 크다 12 그렇다고 하는 값이 1 개존재하기 때문입니다. 테이블 t2 에 포함되어 있는 값이 {0,NULL,1} 의 경우, 이 식은 UNKNOWN (이)가 됩니다.

마지막으로, 테이블 t2 하지만 하늘의 경우, 결과는 TRUE (이)가 됩니다. 이 경우, 결과는 UNKNOWN (이)가 될 생각 싶어집니다만, 실제로는 TRUE 입니다.이해하기 어려울지도 모릅니다만,

SELECT * FROM t1 WHERE 1 > ALL (SELECT s1 FROM t2);

위의 예의 경우, 테이블 t2 하지만 하늘이라면 TRUE (이)가 됩니다만,

SELECT * FROM t1 WHERE 1 > (SELECT s1 FROM t2);

위의 예의 경우, 테이블 t2 하지만 하늘이라면 결과는 UNKNOWN (이)가 됩니다.

SELECT * FROM t1 WHERE 1 > ALL (SELECT MAX(s1) FROM t2);

게다가 위의 예의 경우도, 테이블 t2 하지만 하늘이라면 결과는 UNKNOWN (이)가 됩니다. 일반적으로,NULL 값을 가지는 테이블 (와)과 하늘의 테이블 (은)는, 경계선의 케이스 입니다.서브 쿼리의 코드를 쓸 때는, 이 2 개의 가능성을 항상 염두에 두도록 해 주세요.

6.4.2.5. 상관부문의

상관부문의 (이)란, 그 중에 포함되는 컬럼의 참조가 외측의 쿼리에도 포함되어 있는 서브 쿼리를 말합니다. 다음에 예를 나타냅니다.

SELECT * FROM t1 WHERE column1 = ANY
       (SELECT column1 FROM t2 WHERE t2.column2 = t1.column2);

주의: 위의 예의 서브 쿼리에는,t1 의 참조가 포함되어 있습니다만, 이 서브 쿼리의 FROM 마디에서는 테이블 t1 에 대해서는 언급되고 있지 않습니다.그 때문에,MySQL 에 의해서 서브 쿼리의 외측을 조사할 수 있어 외측의 쿼리로 t1 하지만 검출됩니다.

테이블 t1 에,column1 = 5 그리고, column2 = 6 인 레코드가 포함되어 있어 테이블 t2 에,column1 = 5 그리고,column2 = 7 인 레코드가 포함되어 있다고 합니다.... WHERE column1 = ANY (SELECT column1 FROM t2) 그렇다고 하는 간단한 식의 결과는 TRUE (이)가 됩니다만, 이 예의 경우, 서브 쿼리내의 WHERE 마디가 FALSE (이)가 되므로(7 <> 5 이기 위해), 서브 쿼리 전체는 FALSE (이)가 됩니다.

스코프의 규칙: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));

위의 예에서는,SELECT column1 FROM t2 AS x ... 에 의해서 t2 의 이름이 변경되는 것부터,x.column2 (은)는 테이블 t2 의 컬럼이 아니면 안됩니다.SELECT column1 FROM t1 ... 하 쭉 떨어졌다 외측의 쿼리이므로,x.column2 (은)는 테이블 t1 의 컬럼이 아닙니다.

HAVING 마디나 ORDER BY 마디의 서브 쿼리에 대해서도,MySQL 그럼, 외측의 선택 리스트로 지정된 컬럼명을 조사할 수 있습니다.

MySQL 그럼, 상관 쿼리를 사용하지 않게 비공식에 추천 하고 있습니다.상관 쿼리는 구성이 복잡화 할 뿐만 아니라, 실행에도 보다 많은 시간이 걸립니다.

6.4.2.6. EXISTS (와)과 NOT EXISTS

서브 쿼리로 값이 전혀 돌아가지 않는 경우,EXISTS <subquery> 하 TRUE (이)가 되어,NOT EXISTS <subquery> 하 FALSE (이)가 됩니다. 다음에 예를 나타냅니다.

SELECT column1 FROM t1 WHERE EXISTS (SELECT * FROM t2);

종래,EXISTS 서브 쿼리는 SELECT * 그리고 개시합니다만,SELECT 5 (이)나 SELECT column1 등과 같이, 어떻게 개시해도 괜찮습니다.이러한 서브 쿼리내의 SELECT 리스트는 MySQL 그리고 무시되기 위해, 중요하지는 않습니다.

위의 예로,t2 에 레코드가 포함되어 있으면, 비록 그 레코드에 포함되어 있는 값이 NULL 에서 만나도,EXISTS 조건은 TRUE (이)가 됩니다.그러나, 이 예는 현실적이지는 않습니다.왜냐하면, 대부분의 경우,[NOT] EXISTS 서브 쿼리에는 상관이 포함되기 (위해)때문입니다. 다음에, 보다 현실에 맞은 예를 몇개인가 나타내 보입니다.

례: 1 개이상의 도시에 존재하는 것은, 어느 종류의 점포입니까.

SELECT DISTINCT store_type FROM Stores
  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
                    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 마디가 포함되어 있습니다.형식적으로는, 이 쿼리는 ``Stores 에 존재하지 않는 점포가 포함되는 도시는 존재할까'' 그렇다고 하는 의문에 답하는 것입니다만, 오히려, 네스트 되고 있다 NOT EXISTS 에 의해서,``x (은)는 모든 y 에 대해서 TRUE 인가'' 그렇다고 하는 의문의 대답을 얻을 수 있다고 하는 편이 간단합니다.

6.4.2.7. 행부문의

여기까지의 내용은, 스칼라부문의 -- 즉, 단일의 컬럼치를 돌려준다 -- 서브 쿼리에 대한 물건이었습니다. 행부문의 (이)란, 단일의 레코드치를 돌려주는 이형서브 쿼리입니다.따라서, 복수의 컬럼치를 돌려주는 일이 있습니다. 다음에 예를 2 개 나타내 보입니다.

SELECT * FROM t1 WHERE (1,2) = (SELECT column1, column2 FROM t2);
SELECT * FROM t1 WHERE ROW(1,2) = (SELECT column1, column2 FROM t2);

column1 = 1 그리고,column2 = 2 인 레코드가 테이블 t2 에 포함되어 있는 경우, 이러한 쿼리는 어느쪽이나 TRUE (이)가 됩니다.

식 (1,2) 하 constructor　 　 (으)로 불리기도 해, 다른 문맥에서도 정식으로 사용할 수 있습니다.다음에, 예를 나타냅니다.

SELECT * FROM t1 WHERE (column1,column2) = (1,1);

위의 스테이트먼트는 다음의 것과 같습니다.

SELECT * FROM t1 WHERE column1 = 1 AND column2 = 1;

그러나, 통상, constructor　 　 은, 복수의 컬럼을 돌려주는 서브 쿼리를 사용한 비교로 사용됩니다.예를 들어, 다음의 쿼리는,`` 테이블 t2 에 중복 하는 레코드를 가지는 모든 레코드를 t1 그리고 검색한다'' 그렇다고 하는 요구에 대응합니다.

SELECT column1,column2,column3
       FROM t1
       WHERE (column1,column2,column3) IN
             (SELECT column1,column2,column3 FROM t2);

6.4.2.8. FROM 마디의 서브 쿼리

서브 쿼리는 SELECT 스테이트먼트의 FROM 마디로 정식으로 사용할 수 있습니다. 실제의 구문은 다음과 같습니다.

SELECT ... FROM (<subquery>) AS <name> ...

FROM 마디의 테이블에는 이름이 필요하기 때문에,AS <name> 마디는 반드시 지정할 필요가 있습니다.<subquery> 선택 리스트내의 컬럼은 모두 일의인 이름을 가지고 있지 않으면 안됩니다.이 구문에 대해서는, 이 메뉴얼의 다른 장소에서,`` 파생 테이블'' 그렇다고 하는 용어에 관련해 설명하고 있습니다.

예를 들어, 다음과 같은 테이블이 있으면 상정해 주세요.

CREATE TABLE t1 (s1 INT, s2 CHAR(5), s3 FLOAT);

이 테이블에 근거하고,FROM 마디의 서브 쿼리 기능을 사용하려면 , 다음과 같이 기술합니다.

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

이제(벌써) 1 개예를 나타냅니다.그룹화 된 테이블의 합계의 평균치를 확인할 필요가 있다고 합니다.이 경우, 다음의 쿼리는 기능하지 않습니다.

SELECT AVG(SUM(column1)) FROM t1 GROUP BY column1;

그러나, 다음의 쿼리를 사용하면, 필요한 정보를 얻을 수 있습니다.

SELECT AVG(sum_column1)
       FROM (SELECT SUM(column1) AS sum_column1
             FROM t1 GROUP BY column1) AS t1;

주의: 서브 쿼리로 사용되고 있는 컬럼명 (sum_column1) (은)는 외측의 쿼리로 인식됩니다.

현재로서는,FROM 마디의 서브 쿼리를 상관 쿼리로 할 수 없습니다.

6.4.2.9. 서브 쿼리의 에러

서브 쿼리인 만큼 적용되는 새로운 귀가 에러가 몇개인가 있습니다. 이 섹션에서는, 그러한 에러를 하나로 정리해 중요한 점을 따라가는 개나 설명합니다.

  • ERROR 1235 (ER_NOT_SUPPORTED_YET)
SQLSTATE = 42000
Message = "This version of MySQL doesn't yet support
'LIMIT & IN/ALL/ANY/SOME subquery'"

    이것은, 다음의 스테이트먼트가 기능하지 않는 것을 의미한다.

    SELECT * FROM t1 WHERE s1 IN (SELECT s2 FROM t2 ORDER BY s1 LIMIT 1)

    다만, 이것은, 일부의 초기의 버젼(MySQL 4.1.1 등)에게만 적용된다.

  • ERROR 1240 (ER_CARDINALITY_COL)
SQLSTATE = 21000
Message = "Operand should contain 1 column(s)"

    이 에러는 다음과 같은 경우에 발생한다.

    SELECT (SELECT column1, column2 FROM t2) FROM t1;

    비교를 목적으로 하는 것이라면, 복수의 컬럼을 돌려주는 서브 쿼리를 사용할 수 있다. See 항6.4.2.7. 「행부 문의해」 . 그러나, 다른 문맥에서는, 서브 쿼리는 스칼라 오퍼랜드가 아니면 안된다.

  • ERROR 1241 (ER_SUBSELECT_NO_1_ROW)
SQLSTATE = 21000
Message = "Subquery returns more than 1 row"

    이 에러는 다음과 같은 경우에 발생한다.

    SELECT * FROM t1 WHERE column1 = (SELECT column1 FROM t2);

    다만, 이것은 t2 에 복수의 레코드가 존재하는 경우에 한정된다.예를 들어, 이 에러는 오랫동안 사용되고 있는 코드로 발생하는 일이 있다.즉, 서브 쿼리로 돌려줄 수 있는 레코드수에 영향을 주는 변경을 누군가가 간 것 같은 경우이다.1 개에 한정하지 않고 임의의 수의 레코드를 오브젝트로 검출하도록(듯이) 할 때의 올바른 스테이트먼트는, 다음과 같이 된다.

    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);

서브 쿼리는 SELECT 스테이트먼트와 같이,UPDATE 스테이트먼트나 DELETE 스테이트먼트에서도 정식으로 사용할 수 있으므로,UPDATE 스테이트먼트내의 할당해에 서브 쿼리를 사용해도 문제 없습니다. 그러나, 서브 쿼리의 FROM 마디와 갱신 대상의 양쪽 모두에 같은 테이블(이 경우, 테이블 t1 )(을)를 사용할 수 없습니다.

통상, 서브 쿼리가 에러가 되면, 스테이트먼트 전체가 에러가 됩니다.

6.4.2.10. 서브 쿼리의 최적화

개발은 현재 진행형으로 진행되고 있기 때문에, 장기간 유효한 최적화의 힌트라고 하는 것은 없습니다.여기에서는, 몇개의 테크닉에 대해 설명합니다.

  • 서브 쿼리의 레코드수나 레코드의 순서에 영향을 주는 서브 쿼리절을 사용한다.다음은 그 예.

    SELECT * FROM t1 WHERE t1.column1 IN
  (SELECT column1 FROM t2 ORDER BY column1);
SELECT * FROM t1 WHERE t1.column1 IN
  (SELECT DISTINCT column1 FROM t2);
SELECT * FROM t1 WHERE EXISTS
  (SELECT * FROM t2 LIMIT 1);

  • 결합을 서브 쿼리에 옮겨놓는다.다음은 그 예.

    SELECT DISTINCT column1 FROM t1 WHERE t1.column1 IN (
  SELECT column1 FROM t2);

    위의 스테이트먼트는 다음의 스테이트먼트 대신에 사용할 수 있다.

    SELECT DISTINCT t1.column1 FROM t1, t2
  WHERE t1.column1 = t2.column1;

  • 서브 쿼리의 외측에서 안쪽에 마디를 이동한다.다음은 그 예.

    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);

    이제(벌써) 1 개의 예.

    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);

    위의 스테이트먼트는 다음의 스테이트먼트 대신에 사용할 수 있다.

    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 (은)는 아니고 = ANY (을)를 사용한다.

상기의 테크닉을 사용하면, 프로그램의 실행이 빨라지거나 늦어지거나 하는 경우가 있습니다.MySQL 의 BENCHMARK() 함수등의 기능을 사용하면, 각각의 상황에 있어 무엇이 적절한가, 조사할 수 있습니다.구버젼과의 호환성을 확보하는 경우를 제외하고, 결합에의 변환에 대해서는 별로 신경쓰지 말아 주세요.

MySQL 자체가 실시하는 최적화로서 다음의 것이 있습니다.

  1. 비상관부문의는 1 번 밖에 실행되지 않는다(EXPLAIN (을)를 사용하고, 지정된 서브 쿼리가 실제로 비상관부문의 화도나 확인할 수 있다)

  2. IN/ALL/ANY/SOME 서브 쿼리는, 서브 쿼리내의 선택 리스트 컬럼이 인덱스 첨부일 가능성이 있기 위해, 고쳐 써진다.

  3. 다음의 형식의 서브 쿼리는 인덱스 룩 업 함수로 옮겨놓을 수 있다.

    ... IN (SELECT indexed_column FROM single_table ...)

    인덱스 룩 업 함수는,EXPLAIN 그럼 특수한 결합형으로서 기술된다.

  4. 다음의 형식의 식은,MIN 또는 MAX (을)를 포함한 식에서 확장된다(NULL 값이나 하늘세트가 포함되어 있는 경우를 제외하다).

    value {ALL|ANY|SOME} {> | < | >= | <=} (non-correlated subquery)

    례

    WHERE 5 > ALL (SELECT x FROM t)

    위의 식은 다음과 같이 처리된다.

    WHERE 5 > (SELECT MAX(x) FROM t)

MySQL Internals Manual (MySQL 내부 정보 메뉴얼)에 ``How MySQL Transforms Subqueries (MySQL 에 의한 서브 쿼리의 변환)'' 그렇다고 하는 장이 있습니다.이 메뉴얼을 참조하려면 ,MySQL 의 소스 패키지를 다운로드하고,internals.texi 그렇다고 하는 파일을 찾아 주세요.

6.4.2.11. 초기의 MySQL 버젼에 맞춘 서브 쿼리의 개서

버젼 4.0 까지는, 네스트 된 쿼리의 서포트는,INSERT ... SELECT ... 형식과 REPLACE ... SELECT ... 형식인 만큼 한정되고 있습니다. 그 외의 문맥에서는,IN() 구조를 사용할 수 있습니다.

서브 쿼리를 포함한 쿼리는, 많은 경우, 서브 쿼리 없음의 쿼리에 고쳐 쓸 수 있습니다.

SELECT * FROM t1 WHERE id IN (SELECT id FROM t2);

위의 쿼리는 다음과 같이 고쳐 쓸 수 있습니다.

SELECT t1.* FROM t1,t2 WHERE t1.id=t2.id;

다음의 쿼리의 경우,

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);

다음과 같이 고쳐 쓸 수 있습니다.

SELECT table1.* FROM table1 LEFT JOIN table2 ON table1.id=table2.id
                                       WHERE table2.id IS NULL;

LEFT [OUTER] JOIN (은)는 동등의 서브 쿼리보다 신속히 실행되는 일이 있습니다.왜냐하면,LEFT [OUTER] JOIN 쪽이 서버에 의한 최적화가 보다 적절히 행해지는 것이 있기 때문에입니다.이것은,MySQL Server 뿐만이 아니고, 서버 일반적으로 대해 말할 수 있습니다. SQL-92 보다 전은 외부 결합이 존재하지 않았기 때문에, 그것까지, 서브 쿼리는 특정의 처리를 실시하는 유일한 방법이었습니다.그러나 현재,MySQL 서버를 시작으로 하는 최신의 데이타베이스 시스템에서는, 다양한 형태의 외부 결합을 제공하고 있습니다.

보다 복잡한 서브 쿼리에서는, 많은 경우, 서브 쿼리를 보관 유지하기 위한 텐포라리테이불을 작성할 수 있습니다.그러나, 일부의 케이스에서는, 이 방법은 유효하지는 않습니다.이러한 케이스의 상당수는,DELETE 스테이트먼트로 발생합니다.이 경우, 표준 SQL 그럼, 결합을 서포트하고 있지 않습니다(서브 쿼리내를 제외하다).이 상황에는, 다음의 3 개의 방법의 어느쪽이든으로 대처할 수 있습니다.

  • 제 1 의 선택사항: MySQL 버젼 4.1 에 업그레이드 한다.

  • 제 2 의 선택사항: 수속형 프로그라?~ 그 언어(Perl (이)나 PHP 등)을 사용해,SELECT 쿼리를 송신해 삭제 대상의 레코드의 주키를 취득해, 그 후, 그러한 값을 사용해 DELETE 스테이트먼트(DELETE FROM ... WHERE ... IN (key1, key2, ...) )(을)를 구축한다.

  • 제 3 의 선택사항: 대화식 SQL 그리고,MySQL 의 확장 CONCAT() (을)를 사용해( 표준의 || 연산자 대신에),DELETE 스테이트먼트세트를 자동으로 구축한다. 다음은 그 예.

    SELECT CONCAT('DELETE FROM tab1 WHERE pkid = ', "'", tab1.pkid, "'", ';')
  FROM tab1, tab2
 WHERE tab1.col1 = tab2.col2;

    이 쿼리를 스크립트 파일에 보관하는 것에 의해서, 파일로부터의 입력을 mysql 커멘드 라인 인터프리터에 리디렉트 해, 한층 더 인터프리터의 2 번째의 인스턴스에 출력을 건네줄 수 있다.

    shell> mysql --skip-column-names mydb < myscript.sql | mysql mydb

MySQL 서버 4.0 그럼, 복수 테이블의 DELETE 스테이트먼트를 서포트하고 있습니다.이러한 스테이트먼트를 사용하면,1 개의 테이블의 데이터 뿐만이 아니라, 복수의 테이블의 데이터에 근거하는 레코드를 한 번에 효율적으로 삭제할 수 있습니다. 버젼 4.0 이?~ 그럼, 복수 테이블의 UPDATE 스테이트먼트도 서포트하고 있습니다.

6.4.3. INSERT 구문

    INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
        [INTO] tbl_name [(col_name,...)]
        VALUES ((expression | DEFAULT),...),(...),...
        [ ON DUPLICATE KEY UPDATE col_name=expression, ... ]

또는  INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
        [INTO] tbl_name [(col_name,...)]
        SELECT ...

또는  INSERT [LOW_PRIORITY | DELAYED] [IGNORE]
        [INTO] tbl_name
        SET col_name=(expression | DEFAULT), ...
        [ ON DUPLICATE KEY UPDATE col_name=expression, ... ]

INSERT 스테이트먼트에서는, 기존의 테이블에 새로운 레코드가 삽입됩니다.INSERT ... VALUES 형식의 INSERT 그럼, 명시적으로 지정한 값에 근거하는 레코드가 삽입됩니다.INSERT ... SELECT 형식의 INSERT 그럼, 다른 1 개 또는 복수의 테이블에서 선택된 레코드가 삽입됩니다.복수의 값의 리스트를 가진다 INSERT ... VALUES 형식은,MySQL 버젼 3.22.5 이?~ 그리고 서포트하고 있습니다.col_name=expression 구문은 MySQL 버젼 3.22.10 이?~ 그리고 서포트하고 있습니다.

tbl_name 에는, 레코드를 삽입하는 테이블을 지정합니다.컬럼명의 리스트 또는 SET 마디에는, 그 스테이트먼트로 값을 지정하는 대상의 컬럼을 지정합니다.

  • INSERT ... VALUES 또는 INSERT ... SELECT 그리고 컬럼 리스트를 지정하지 않는 경우,VALUES() 리스트 또는 SELECT 그리고, 테이블의 모든 컬럼의 값을 제공할 필요가 있다.테이블내의 컬럼의 순서를 모르는 경우는,DESCRIBE tbl_name (을)를 사용하고 순서를 조사한다.

  • 값이 명시적으로 지정되어 있지 않은 컬럼은, 그 컬럼의 디폴트로 설정된다.예를 들어, 컬럼 리스트로 테이블의 방법의 컬럼이 지정되어 있지 않은 경우, 지정되어 있지 않은 컬럼은 그 디폴트치로 설정된다.디폴트치의 할당에 대해서는, 항6.5.3. 「CREATE TABLE 구문」 그리고 설명하고 있다.

    키워드 DEFAULT (을)를 사용하고, 컬럼에 디폴트치를 설정할 수도 있다(MySQL 4.0.3 의 신기능).이 경우, 불완전한 VALUES() 리스트(테이블내의 모든 컬럼의 각 치를 포함하지 않은 리스트)를 기술하지 않아도 되기 위해, 일부의 몇 안 되는 컬럼을 제외한 모든 컬럼에 값을 할당한다 INSERT 스테이트먼트를 쓰기 쉬워진다. 이 키워드를 사용하지 않는 경우,VALUES() 리스트의 각 치에 대응하는 컬럼명의 리스트를 기술해야 한다.

    MySQL 그럼, 항상 모든 필드에 디폴트치가 있다.디폴트치의 존재는,MySQL 하지만 트랜잭션(transaction) 테이블과 비트랜잭션(transaction) 테이블의 어느쪽이나 처리할 수 있도록하기 위한 필요 조건이 되고 있다.

    MySQL 그럼, 필드 내용의 체크는 데이터 베이스 서버는 아니고 어플리케이션측에서 실시한다, 라고 하는 견해에 서있다.

  • expression 그럼, 값리스트에 먼저 설정된 임의의 컬럼을 참조할 수 있다.예를 들어, 다음과 같이 기술할 수 있다.

    mysql> INSERT INTO tbl_name (col1,col2) VALUES(15,col1*2);

    그러나, 다음과 같이는 기술할 수 없다.

    mysql> INSERT INTO tbl_name (col1,col2) VALUES(col2*2,15);

  • 키워드 DELAYED 하지만 지정되어 있으면, 서버는 레코드를 버퍼에 삽입한다.그 후,INSERT DELAYED 스테이트먼트를 발행한 클라이언트는 처리를 속행할 수 있다.테이블이 사용되고 있으면, 서버는 레코드를 보관 유지한다.테이블이 해방되면, 서버는 레코드의 삽입을 개시해, 그 테이블에 대한 새로운 독해 요구가 없는가 정기적으로 체크한다.새로운 독해 요구가 있으면, 그 테이블이 다시 해방될 때까지, 지연 된 레코드의 큐의 처리는 중단된다.

  • 키워드 LOW_PRIORITY 하지만 지정되어 있는 경우, 다른 클라이언트에 의한 그 테이블에서의 독해가 없어질 때까지,INSERT 의 실행은 늦추어진다.이것에는, 기존의 클라이언트의 독해중, 및 INSERT LOW_PRIORITY 스테이트먼트의 대기중에 독해를 개시한 다른 클라이언트도 포함된다.따라서, 읽어내 과다한 환경의 경우,INSERT LOW_PRIORITY 스테이트먼트를 발행한 클라이언트는 장시간(또는 영속적으로) 대기 당하는 일이 있다(그에 대해 INSERT DELAYED 그럼, 클라이언트는 즉시 처리를 속행할 수 있다).See 항6.4.3.2. 「INSERT DELAYED 구문」 주의: LOW_PRIORITY 그럼 동시 삽입이 무효가 되기 위해, 이 옵션은 통상 MyISAM 테이블에 대해서는 사용하지 않는다. See 항7.1. 「MyISAM 테이블」 .

  • 많은 레코드의 INSERT 그리고 키워드 IGNORE 하지만 지정되어 있으면, 테이블의 기존의 PRIMARY 또는 UNIQUE 키와 중복 하는 레코드는 모두 무시되어 삽입되지 않는다.IGNORE 하지만 지정되어 있지 않은 경우에 기존의 키치를 중복 해 가지는 레코드가 있으면, 삽입 처리가 중단된다.C API 함수 mysql_info() 그럼, 테이블에 삽입된 레코드수를 조사할 수 있다.

  • ON DUPLICATE KEY UPDATE 마디(MySQL 4.1.0 의 신기능)이 지정되어 있는 경우에,PRIMARY 또는 UNIQUE 키로의 중복치의 생성을 부르는 레코드가 삽입되면, 낡은 레코드의 UPDATE 하지만 실행된다.다음에 예를 나타낸다.

    mysql> INSERT INTO table (a,b,c) VALUES (1,2,3)
    -> ON DUPLICATE KEY UPDATE c=c+1;

    이 커멘드에서는,a 하지만 UNIQUE (으)로서 선언되고 있고, 한편 벌써 1 번, 값 1 (을)를 보관 유지하고 있는 경우, 다음의 커멘드와 같게 된다.

    mysql> UPDATE table SET c=c+1 WHERE a=1;

    주의: 컬럼 b 도 일의인 경우,UPDATE 커멘드는 다음과 같이 된다.

    mysql> UPDATE table SET c=c+1 WHERE a=1 OR b=2 LIMIT 1;

    a=1 OR b=2 하지만 복수의 레코드에 일치하는 경우,1 개의 레코드만이 갱신된다.통상, 복수의 UNIQUE 키를 가지는 테이블에 대해서는 ON DUPLICATE KEY 마디를 사용하지 않게 한다.

    MySQL 4.1.1 이?~ 그럼, 함수 VALUES(col_name) (을)를 사용하고,INSERT ... UPDATE 커멘드의 INSERT 부분의 컬럼치를 참조할 수 있다.이것은, 중복 키의 충돌이 없는 경우에 삽입되는 값이다.이 함수는 복수행의 삽입시에 특별히 도움이 된다.당연,VALUES() 함수는 INSERT ... UPDATE 커멘드에서만 의미를 가져, 그 이외의 커멘드로 사용했을 경우는 NULL 하지만 돌려주어진다.

    다음에 예를 나타낸다.

    mysql> INSERT INTO table (a,b,c) VALUES (1,2,3),(4,5,6)
    -> ON DUPLICATE KEY UPDATE c=VALUES(a)+VALUES(b);

    위의 커멘드는 다음의 커멘드와 같다.

    mysql> INSERT INTO table (a,b,c) VALUES (1,2,3)
    -> ON DUPLICATE KEY UPDATE c=3;
mysql> INSERT INTO table (a,b,c) VALUES (4,5,6)
    -> ON DUPLICATE KEY UPDATE c=9;

    ON DUPLICATE KEY UPDATE 하지만 지정되어 있는 경우,DELAYED 옵션은 무시된다.

  • MySQL 의 콘피개시에 DONT_USE_DEFAULT_FIELDS 옵션이 지정되어 있는 경우,NULL 이외의 값을 필요로 하는 모든 컬럼에 명시적으로 값을 지정하지 않으면INSERT 스테이트먼트로 에러가 생성된다. See 항2.3.3. 「일반적인 configure 옵션」 .

  • AUTO_INCREMENT 컬럼에 사용되고 있는 값은,mysql_insert_id 함수를 사용해 확인할 수 있다. See 항11.1.3.32. 「mysql_insert_id() 」 .

INSERT ... SELECT 또는 INSERT ... VALUES 스테이트먼트를 복수의 값의 리스트 첨부로 사용하는 경우는,C API 함수 mysql_info() (을)를 사용해 쿼리에 관한 정보를 취득할 수 있습니다.정보 문자열의 형식은 다음과 같습니다.

Records: 100 Duplicates: 0 Warnings: 0

Duplicates (은)는, 특정의 기존의 유니크 인덱스치와 중복 하게 되기 위해 삽입되지 않았던 레코드수를 나타냅니다. Warnings (은)는, 어떠한 문제가 있는 컬럼치를 삽입하려고 한 회수를 나타냅니다.Warnings (경고)(은)는 다음의 몇개의 조건아래에 발생합니다.

  • NOT NULL (으)로서 선언되고 있는 컬럼에게의 NULL 의 삽입. 이 경우, 컬럼에게는 그 컬럼형에 대응하는 디폴트치가 설정된다. 즉, 수치형의 컬럼에서는 0 , 문자열형의 컬럼에서는 하늘의 문자열('' ), 일자와 시각형의 컬럼에서는 `` 제로'' 값이 적용된다.

  • 수치형의 컬럼에게의, 그 컬럼의 값의 범위를 넘는 값의 설정. 이 경우, 값은 범위의 최대치 또는 최소치에 잘라 떨어진다.

  • 수치형의 컬럼에게의 '10.34 a' 등의 값의 설정.이 경우, 후속의 가베지는 제거되어 나머지의 수치의 부분만큼이 삽입된다.값이 수치로서 의미를 만들어내지 않는 경우, 컬럼의 값은 0 (으)로 설정된다.

  • CHAR 형태,VARCHAR 형태,TEXT 형태, 또는 BLOB 형태의 컬럼에게의, 그 컬럼의 최대장을 넘는 문자열의 삽입.이 경우, 값은 컬럼의 최대장에 맞추어 잘라 버릴 수 있다.

  • 일자 또는 시각형의 컬럼에게의, 그 컬럼형에 부적절한 값의 삽입.이 경우, 컬럼의 값은 그 형태에 대응하는 제로치로 설정된다.

6.4.3.1. INSERT ... SELECT 구문

INSERT [LOW_PRIORITY] [IGNORE] [INTO] tbl_name [(column list)] SELECT ...

INSERT ... SELECT 스테이트먼트에서는,1 개 또는 복수의 테이블의 수많은 레코드를 다른 1 개의 테이블에 재빠르게 삽입할 수 있습니다.

INSERT INTO tblTemp2 (fldID) SELECT tblTemp1.fldOrder_ID FROM tblTemp1 WHERE
tblTemp1.fldOrder_ID > 100;

INSERT ... SELECT 스테이트먼트에서는, 이하의 조건이 적용됩니다.

  • MySQL 4.0.1 보다 전의 버젼에서는,INSERT ... SELECT (은)는 암묵적으로 IGNORE 모드로 동작한다.MySQL 4.0.1 이?~ 그럼, 중복 키 위반을 일으키는 레코드를 무시하려면 ,IGNORE (을)를 명시적으로 지정하지 않으면 안 된다.

  • MySQL 4.0.14 보다 전의 버젼에서는,INSERT 스테이트먼트의 대상 테이블을 쿼리의 SELECT 부분의 FROM 마디에 나타낼 수 없다. 이 제약은 4.0.14 (이)가 아니게 되었다.

  • AUTO_INCREMENT 컬럼은 통상 대로 기능한다.

  • C 프로그램에서는,C API 함수 mysql_info() (을)를 사용해 쿼리에 관한 정보를 취득할 수 있다. See 항6.4.3. 「INSERT 구문」 .

  • 바이너리 로그를 사용해 원의 테이블을 확실히 재작성할 수 있듯이 하기 위한(해),MySQL 그럼,INSERT ... SELECT 실행중의 동시 삽입은 실시할 수 없다.

이전의 레코드를 덧쓰기하려면 ,INSERT 대신에 REPLACE (을)를 사용합니다.이전의 레코드의 값과 중복 하는 유니크 키치를 가지는 새로운 레코드의 처리에 관해서,REPLACE 하 INSERT IGNORE 에 대립하는 기능을 합니다.즉, 새로운 레코드가 폐기되는 것이 아니라, 새로운 레코드에 의해서 이전의 레코드를 옮겨놓을 수 있습니다.

6.4.3.2. INSERT DELAYED 구문

INSERT DELAYED ...

INSERT 의 완료를 기다릴 수 없는 클라이언트가 있는 경우,MySQL 고유의 옵션이다 DELAYED (을)를 지정했다 INSERT 스테이트먼트가 매우 도움이 됩니다.이러한 클라이언트의 문제는,MySQL (을)를 사용해 로그를 기록하는 한편으로, 완료까지 시간이 걸린다 SELECT (이)나 UPDATE 스테이트먼트를 정기적으로 실행하고 있는 경우에 잘 일어납니다.DELAYED (은)는,MySQL 버젼 3.22.15 그리고 도입된,SQL-92 에 대한다 MySQL 의 확장입니다.

INSERT DELAYED (은)는,ISAM 및 MyISAM 테이블 에 대해서만 작용합니다.주의: MyISAM 테이블에서는, 데이터 파일의 중앙에 비어 블록이 없는 경우, 동시 SELECT (와)과 동시 INSERT 하지만 가능하기 때문에,MyISAM 테이블로 INSERT DELAYED (을)를 사용할 필요는 거의 없습니다. See 항7.1. 「MyISAM 테이블」 .

INSERT DELAYED (을)를 사용하면, 클라이언트는 즉시 처리의 속행이 허가됩니다.그리고, 테이블이 다른 스레드에 의해서 사용되어 있지 않으면, 레코드가 삽입됩니다.

INSERT DELAYED 마시자 1 개의 주된 이점은, 많은 클라이언트에 의한 삽입이 1 개에 정리하고,1 블록에 써지는 것입니다.이 경우, 수많은 삽입을 개별적으로 실시하는 것보다, 처리 속도가 훨씬 빨라집니다.

주의: 현재로서는, 큐에 넣어진 레코드는, 테이블에 삽입될 때까지는 단지 메모리에 격납되고 있는에 지나지 않습니다.즉,mysqld (을)를 kill -9 에 의해서 강제 종료했을 경우나,mysqld 하지만 예기치 않은 상황으로 돌연 종료했을 경우, 디스크에 써지지 않은 큐안의 레코드는 모두 소실합니다.

이하에,INSERT 또는 REPLACE 스테이트먼트로 DELAYED 옵션을 지정했을 경우의 처리에 대해 자세하게 설명합니다.이 설명중,`` 스레드'' 하 INSERT DELAYED 커멘드를 받은 스레드를 가리켜,`` 핸들러'' (은)는 개개의 테이블의 INSERT DELAYED 스테이트를 모두 처리하는 스레드를 가리킵니다.

  • 스레드가 몇개의 테이블에 대한다 DELAYED 스테이트먼트를 실행하면, 그 테이블의 모든 DELAYED 스테이트먼트를 처리하는 한드라스레드가 작성된다(이러한 핸들러가 벌써 존재하지 않는 경우).

  • 스레드는, 핸들러가 DELAYED 락을 벌써 취득하고 있는지 체크해, 아직의 경우는 락을 취득하도록(듯이) 핸들러에 지시한다.DELAYED 락은, 다른 스레드가 그 테이블에 대한다 READ 또는 WRITE 락을 가지고 있는 경우에서도 취득할 수 있다.다만, 그 경우 핸들러는, 반드시 최신의 테이블 구조를 얻을 수 있도록, 모든 ALTER TABLE 락 또는 FLUSH TABLES 하지만 완료할 때까지 대기한다.

  • 스레드는 INSERT 스테이트먼트를 실행한다.다만, 이 경우, 스레드는 레코드를 테이블에 쓰는 대신에, 한드라스레드가 관리하는 큐에 마지막 레코드의 카피를 넣는다.구문 에러가 있는 경우는 스레드에 의해서 검출되어 클라이언트 프로그램에 보고된다.

  • 클라이언트는 중복의 수나 결과의 레코드의 AUTO_INCREMENT 값은 모두 보고할 수 없다.INSERT (은)는 삽입 처리가 완료하기 전으로 돌아오기 위해, 클라이언트는 이러한 정보를 서버로부터 취득할 수 없다.C API (을)를 사용하고 있는 경우, 같은 이유로,mysql_info() 함수에서도, 의미가 있는 정보는 아무것도 돌려주어지지 않다.

  • 바이너리 로그는, 레코드가 테이블에 삽입되면, 한드라스레드에 의해서 갱신된다.복수의 레코드의 삽입시로는, 바이너리 로그는 최초의 레코드가 삽입된 시점에서 갱신된다.

  • 각 delayed_insert_limit 레코드가 써지면, 그때 그때, 핸들러는 아직 보류중이 되어 있다 SELECT 스테이트먼트가 없는가 체크한다.어느 경우, 핸들러는 처리를 속행하기 전에 보류중의 스테이트먼트의 실행을 허가한다.

  • 핸들러의 큐에 레코드가 굳이 없어지면, 테이블의 락이 해제된다.delayed_insert_timeout (으)로 지정된 초수가 경과하기 전에, 새롭다 INSERT DELAYED 커멘드가 건네받지 않으면 핸들러는 종료한다.

  • delayed_queue_size (으)로 지정된 수를 넘는 레코드가 특정의 핸들러 큐에 벌써 보류가 되어 있으면,INSERT DELAYED (을)를 요구하고 있는 스레드는 큐에 빈 공간이 생길 때까지 대기한다.이것은,mysqld 서버로 지연 메모리큐의 메모리를 모두 사용해 버리지 않게 하기 위한(해)이다.

  • 한드라스레드는 MySQL 프로세스 리스트의 Command 컬럼에 delayed_insert (으)로서 표시된다.FLUSH TABLES 커멘드를 실행하는지, 또는 KILL thread_id (을)를 사용해 강제 종료하면, 한드라스레드는 강제 종료된다.그러나, 이 경우 한드라스레드는, 큐내의 모든 레코드를 테이블에 격납하고 나서 종료한다.이전, 한드라스레드는 다른 스레드로부터의 새롭다 INSERT 커멘드를 전혀 받아 들이지 않는다.이 후에 INSERT DELAYED 커멘드를 실행하면, 새로운 한드라스레드가 작성된다.

    주의: 이것은, 벌써 실행되고 있다 INSERT DELAYED 하지만 존재하는 경우, 통상의 INSERT 커멘드보다 INSERT DELAYED 커멘드가 우선되는 것을 의미한다.다른 갱신 커멘드는,INSERT DELAYED 큐가 비우는지, 누군가가 한드라스레드를 강제 종료할까(KILL thread_id (을)를 사용하고), 또는 누군가가 FLUSH TABLES (을)를 실행할 때까지 대기해야 한다.

  • 이하의 스테이터스 변수에서는,INSERT DELAYED 커멘드의 정보가 제공된다.

    변수 | 의미
    Delayed_insert_threads | 한드라스레드의 수
    Delayed_writes | INSERT DELAYED 그리고 써진 레코드수
    Not_flushed_delayed_rows | 써 기다리는 레코드수

    이러한 변수를 표시하려면 ,SHOW STATUS 스테이트먼트를 발행하는지, 또는 mysqladmin extended-status 커멘드를 실행한다.

주의: 대상의 테이블이 사용중이 아닌 경우,INSERT DELAYED (은)는 통상의 INSERT 보다 늦어집니다.또,INSERT DELAYED (을)를 사용하는 각 테이블에 대응하는 스레드를 개별적으로 처리하기 위해서 서버로 추가의 오버헤드가 발생합니다.그 때문에,INSERT DELAYED (은)는 아무래도 사용할 필요가 있을 때 마셔 사용해 주세요.

6.4.4. UPDATE 구문

UPDATE [LOW_PRIORITY] [IGNORE] tbl_name
    SET col_name1=expr1 [, col_name2=expr2 ...]
    [WHERE where_definition]
    [ORDER BY ...]
    [LIMIT row_count]

또는

UPDATE [LOW_PRIORITY] [IGNORE] tbl_name [, tbl_name ...]
    SET col_name1=expr1 [, col_name2=expr2 ...]
    [WHERE where_definition]

UPDATE (은)는 기존의 테이블 레코드의 컬럼을 새로운 값으로 갱신합니다. SET 마디는 값의 변경 대상의 컬럼과 값을 나타냅니다.WHERE 마디가 있는 경우, 이 마디는 갱신하는 레코드를 나타냅니다.갱신 대상의 레코드가 지정되어 있지 않은 경우는, 모든 레코드가 갱신됩니다.ORDER BY 마디가 지정되어 있으면, 거기로 지정된 순서로 레코드가 갱신됩니다.

키워드 LOW_PRIORITY 하지만 지정되어 있으면, 다른 클라이언트에 의한 그 테이블에서의 독해가 없어질 때까지,UPDATE 의 실행은 늦추어집니다.

키워드 IGNORE 하지만 지정되어 있으면, 갱신중에 중복 키 에러가 발생해도 갱신 스테이트먼트는 중단되지 않습니다.충돌을 발생시키는 레코드는 갱신되지 않습니다.

진묘쵸우에 기록되어 있는 일의 tbl_name (으)로부터 컬럼이 액세스 되는 경우,UPDATE (은)는 그 컬럼의 현재의 값을 사용합니다.예를 들어 다음의 스테이트먼트로,age 컬럼의 값은 이 컬럼의 현재의 값보다 1 만 많은 값으로 설정됩니다.

mysql> UPDATE persondata SET age=age+1;

UPDATE (은)는 왼쪽에서 오른쪽에 평가됩니다.예를 들어, 다음의 스테이트먼트에서는,age 컬럼의 값이 우선 2 배로 되어 그 후, 가산됩니다.

mysql> UPDATE persondata SET age=age*2, age=age+1;

컬럼의 값이 그 컬럼의 현재의 값으로 설정되는 경우,MySQL (은)는 그것이 현재의 값인 것을 인식해, 갱신 처리를 실시하지 않습니다.

UPDATE (은)는 실제로 변경된 레코드수를 돌려줍니다. MySQL 버젼 3.22 이?~ 그럼,C API 함수 mysql_info() (을)를 사용하면, 갱신된 레코드수와 UPDATE 의 실행중에 발생한 경고의 수가 돌려주어집니다. NOT NULL (으)로서 선언된 컬럼에 대해서 NULL 값을 설정해, 이 컬럼을 갱신하면, 그 컬럼에게는 그 컬럼형에 대응하는 디폴트치가 설정되어 경고의 카운트가 가산됩니다.디폴트치는 수치형에서는 0 (이어)여, 문자열형에서는 하늘의 문자열('' )(이어)여, 일자와 시각형에서는 `` 제로'' 값입니다.

MySQL 버젼 3.23 이?~ 그럼,LIMIT row_count (을)를 사용해 UPDATE 의 스코프를 제한할 수 있습니다.LIMIT 마디는 다음과 같이 기능합니다.

  • MySQL 4.0.13 보다 전의 버젼에서는,LIMIT 에 의한 제한은 영향을 받은 레코드에 근거해서 적용된다. WHERE 마디의 지정에 매치하는 레코드가,row_count (으)로 지정된 수만큼 변경되면, 스테이트먼트는 즉시 정?~ 한다.

  • 4.0.13 이?~ 그럼,LIMIT 에 의한 제한은 매치한 레코드에 근거해서 적용된다.WHERE 마디의 지정에 매치하는 레코드가,row_count (으)로 지정된 수만큼 검출되면, 그러한 레코드를 실제로 변경 떠날 수 있었는지 로부터 원않다, 스테이트먼트는 즉시 종료한다.

ORDER BY 하지만 사용되고 있는 경우(MySQL 4.0.0 이?~ 그리고 사용 가능), 레코드는 지정된 순서로 갱신됩니다.ORDER BY 마디는, 실제로는,LIMIT (와)과 조합해 사용했을 경우에게만 도움이 됩니다.

MySQL 버젼 4.0.4 이?~ 그럼, 복수의 테이블에 대한다 UPDATE 조작도 실행 가능합니다.

UPDATE items,month SET items.price=month.price
WHERE items.id=month.id;

위의 예에서는, 콤마 연산자를 사용한 내부 결합을 나타내고 있습니다만, 복수 테이블의 UPDATE 스테이트먼트에서는,LEFT JOIN 등,SELECT 스테이트먼트로 사용 가능한 임의의 결합형을 사용할 수 있습니다.

주의: 복수 테이블의 UPDATE 그럼,ORDER BY (와)과 LIMIT (은)는 모두 사용할 수 없습니다.

6.4.5. DELETE 구문

DELETE [LOW_PRIORITY] [QUICK] [IGNORE] FROM table_name
       [WHERE where_definition]
       [ORDER BY ...]
       [LIMIT row_count]

또는

DELETE [LOW_PRIORITY] [QUICK] [IGNORE] table_name[.*] [, table_name[.*] ...]
       FROM table-references
       [WHERE where_definition]

또는

DELETE [LOW_PRIORITY] [QUICK] [IGNORE]
       FROM table_name[.*] [, table_name[.*] ...]
       USING table-references
       [WHERE where_definition]

DELETE (은)는,where_definition 그리고 지정되어 있는 조건에 매치하는 레코드를,table_name (으)로 지정되어 있는 테이블에서 삭제해, 삭제한 레코드의 수를 돌려줍니다.

WHERE 마디가 지정되어 있지 않다 DELETE 그럼, 모든 레코드가 삭제됩니다.AUTOCOMMIT 모드로 실행되었을 경우,WHERE 마디 없음의 DELETE 하 TRUNCATE (와)과 같이 동작합니다.See 항6.4.6. 「TRUNCATE 구문」 .MySQL 3.23 그럼,WHERE 마디가 없다 DELETE (은)는 영향을 받은 레코드 수라고 해 값제로를 돌려줍니다.

모든 레코드의 삭제시에, 삭제된 레코드수를 확인할 필요가 있는 경우, 처리 속도가 늦어져도 상관없으면, 다음의 형식의 DELETE 스테이트먼트를 사용할 수 있습니다.

mysql> DELETE FROM table_name WHERE 1>0;

주의: 이 형식의 경우, 레코드가 한 번에 1 개씩 삭제되기 위해,WHERE 마디가 없다 DELETE FROM table_name 보다 아득하게 처리가 늦어집니다.

키워드 LOW_PRIORITY 하지만 지정되어 있으면, 다른 클라이언트에 의한 그 테이블에서의 독해가 없어질 때까지,DELETE 의 실행은 늦추어집니다.

MyISAM 테이블의 경우,QUICK 그렇다고 하는 말이 지정되어 있으면, 삭제시에 스토리지 엔진으로 인덱스의 리프를 머지 하지 않습니다.그 때문에, 일부의 삭제 조작에서는, 처리가 신속화됩니다.

삭제 조작의 속도는, 항5.2.12. 「DELETE 쿼리의 속도」 그리고 설명하고 있는 요인에도 영향을 받습니다.

옵션 IGNORE 하지만 지정되어 있으면,MySQL (은)는 레코드의 삭제중에 모든 에러를 무시합니다.해석 단계에서 발생한 에러는 통상의 방법으로 처리됩니다.이 옵션의 사용에 의해서 무시된 에러는 경고로서 돌려주어집니다.이 옵션은 버젼 4.1.1 그리고 도입되었습니다.

MyISAM 테이블의 경우, 삭제된 레코드는 링크된 리스트에 유지되어 원의 레코드 위치가 후속의 INSERT 조작으로 재이용됩니다.사용되어 있지 않은 스페이스를 되찾아 파일의 사이즈를 삭감하려면 ,OPTIMIZE TABLE 스테이트먼트 또는 myisamchk 유틸리티를 사용해 테이블을 재편성 합니다. 이 경우,OPTIMIZE TABLE (분)편이 간단합니다만,myisamchk (분)편이 처리가 신속합니다. 항4.6.1. 「OPTIMIZE TABLE 구문」 및 항4.5.6.10. 「테이블의 최적화」 (을)를 참조해 주세요.

복수 테이블의 삭제의 최초의 형식은,MySQL 4.0.0 이?~ 그리고 서포트하고 있습니다. 복수 테이블의 삭제의 2 번째의 형식은,MySQL 4.0.2 이?~ 그리고 서포트하고 있습니다.

복수 테이블의 삭제에서는,FROM 마디의 전 , 또는 USING 마디의 전에 리스트 된 테이블내의 일치하는 레코드만이 삭제됩니다.그 때문에, 많은 테이블의 레코드를 한 번에 삭제할 수 있는 것과 동시에, 검색에 사용하는 그 외의 테이블을 지정할 수 있습니다.

테이블명의 뒤에 .* (을)를 붙이는 것은, 단지 Access (와)과의 호환성을 확보하기 (위해)때문입니다.

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

이러한 예에서는, 테이블 t1 (와)과 t2 안의 일치하는 레코드만이 삭제됩니다.

위의 예에서는 콤마 연산자를 사용한 내부 결합을 나타내고 있습니다만, 복수 테이블의 DELETE 스테이트먼트에서는,LEFT JOIN 등,SELECT 스테이트먼트로 사용 가능한 임의의 결합형을 사용할 수 있습니다.

ORDER BY 하지만 사용되고 있는 경우(MySQL 4.0.0 이?~ 그리고 사용 가능), 레코드는 지정된 순서로 삭제됩니다.ORDER BY 마디는, 실제로는,LIMIT (와)과 조합해 사용했을 경우에게만 도움이 됩니다.다음에 예를 나타냅니다.

DELETE FROM somelog
WHERE user = 'jcole'
ORDER BY timestamp
LIMIT 1

이 경우, WHERE 마디의 지정에 일치하는 레코드로 가장 낡은 엔트리(timestamp 값에 근거한다)가 삭제됩니다.

DELETE 에 MySQL 고유의 옵션이다 LIMIT row_count (을)를 지정하면, 클라이언트에 제어를 되돌리기 전에 삭제하는 최대 레코드수를 서버에 지시할 수 있습니다.이 옵션은, 특정의 DELETE 커멘드로 실행에 별로 시간이 걸리지 않게 할 필요가 있을 때 사용할 수 있습니다.이 경우, 영향을 받은 레코드의 수가 LIMIT 값보다 작아질 때까지,DELETE 커멘드를 단순하게 반복할 수 있습니다.

MySQL 4.0 이?~ 그럼,DELETE 스테이트먼트에 복수의 테이블을 지정하는 것에 의해서, 복수 테이블에 있어서의 특정의 조건에 따르고,1 개이상의 테이블에서 레코드를 삭제할 수 있습니다.그러나, 복수 테이블의 DELETE 그럼,ORDER BY (와)과 LIMIT (은)는 모두 사용할 수 없습니다.

6.4.6. TRUNCATE 구문

TRUNCATE TABLE table_name

3.23 그럼,TRUNCATE TABLE 하 COMMIT; DELETE FROM table_name 에 맵 된다. See 항6.4.5. 「DELETE 구문」 .

TRUNCATE TABLE (은)는 다음의 점으로 DELETE FROM ... (와)과 다릅니다.

  • 잘라서 버림 조작에서는, 테이블이 파기되어 재작성된다.이 조작은, 레코드를 1 개씩 삭제하는 것보다 아득하게 신속히 처리된다.

  • 잘라서 버림 조작은 트랜잭션(transaction) 세이프는 아니다.액티브한 트랜잭션(transaction)나 액티브한 테이블의 락이 있으면, 에러가 된다.

  • 삭제된 레코드수는 돌려주어지지 않다.

  • 테이블 정의 파일 table_name.frm 하지만 유효하다 한정해, 데이터나 인덱스의 파일이 파손해도, 이 방법으로 테이블을 재작성할 수 있다.

TRUNCATE TABLE 하 Oracle 의 SQL 확장입니다. 이 스테이트먼트는 MySQL 3.23.28 그리고 추가되었습니다.다만,3.23.28 ~ 3.23.32 그럼, 키워드 TABLE (을)를 생략 할 필요가 있습니다.

6.4.7. REPLACE 구문

    REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name [(col_name,...)]
        VALUES (expression,...),(...),...

또는  REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name [(col_name,...)]
        SELECT ...

또는  REPLACE [LOW_PRIORITY | DELAYED]
        [INTO] tbl_name
        SET col_name=expression, col_name=expression,...

REPLACE 하 INSERT (와)과 거의 똑같이 동작합니다만, 유일 다른 점으로서UNIQUE 인덱스 또는 PRIMARY KEY 에 관해서 새로운 레코드와 같은 값이 테이블내의 이전의 레코드에 포함되어 있으면, 이전의 레코드가 삭제되고 나서 새로운 레코드가 삽입됩니다. See 항6.4.3. 「INSERT 구문」 .

즉,REPLACE 스테이트먼트에서는, 이전부터 있는 레코드의 값에는 액세스 할 수 없게 됩니다.일부의 초기 버젼의 MySQL 그럼, 이 액세스가 가능과 같이 보였습니다만, 이것은 버그이며, 수정되었습니다.

REPLACE (을)를 사용하기 위해서는, 대상의 테이블에 대한다 INSERT 권한과 DELETE 권한이 필요합니다.

REPLACE 커멘드의 사용시, 이전의 레코드 1 개가 새로운 레코드로 옮겨놓을 수 있으면,mysql_affected_rows() 에 의해서 2 하지만 돌려주어집니다.이것은 중복의 삭제 후에 레코드가 1 개삽입되었기 때문입니다.

이것에 근거해, 영향을 받은 레코드의 값이 1 (추가)(와)과 2 (치환)의 어느 쪽인지 체크하는 것에 의해서,REPLACE 에 의해서 레코드가 1 개추가되었는지, 또는 옮겨놓을 수 있었는지를 간단하게 판별할 수 있습니다.

주의: 테이블에 UNIQUE 인덱스 또는 PRIMARY KEY 하지만 설정되어 있지 않은 경우,REPLACE 커멘드를 사용해도 의미가 없습니다.이 경우, 새로운 레코드가 기존의 것과 중복 하고 있을지의 판별로 사용하는 인덱스가 없기 때문에,REPLACE 커멘드는 INSERT (와)과 같게 됩니다.

이하는, 사용되는 알고리즘을 상세하게 나타내 보인 것입니다(이 알고리즘은 LOAD DATA ... REPLACE 그렇지만 사용됩니다).

- Insert the row into the table
  - While duplicate key error for primary or unique key
    - Revert changed keys
    - Read conflicting row from the table through the duplicate key value
    - Delete conflicting row
    - Try again to insert the original primary key and unique keys in the tree

6.4.8. LOAD DATA INFILE 구문

LOAD DATA [LOW_PRIORITY | CONCURRENT] [LOCAL] INFILE 'file_name.txt'
    [REPLACE | IGNORE]
    INTO TABLE tbl_name
    [FIELDS
        [TERMINATED BY '\t']
        [[OPTIONALLY] ENCLOSED BY '']
        [ESCAPED BY '\\' ]
    ]
    [LINES
        [STARTING BY '']
        [TERMINATED BY '\n']
    ]
    [IGNORE number LINES]
    [(col_name,...)]

LOAD DATA INFILE 스테이트먼트는, 텍스트 파일로부터 테이블에 레코드를 고속으로 읽어냅니다.LOCAL 키워드가 지정되어 있는 경우, 이 키워드는 접속의 클라이언트 측에 관련해 해석됩니다.LOCAL 하지만 지정되어 있으면, 클라이언트 호스트상의 클라이언트 프로그램에 의해서 파일이 읽어내지고 서버에 보내집니다.LOCAL 하지만 지정되어 있지 않은 경우, 파일은 서버 호스트상에 존재하지 않으면 안되어, 서버에 의해서 직접 읽어내지지 않으면 안됩니다(LOCAL 하 MySQL 버젼 3.22.6 이?~ 그리고 사용할 수 있습니다).

시큐러티상의 이유로부터, 서버에 존재하는 텍스트 파일을 읽어낼 때는, 그 파일이 데이타베이스 디렉토리에 존재하는지, 또는 전유저가 그 파일을 읽어내 가능하지 않으면 안됩니다.또, 서버의 파일에 대해서 LOAD DATA INFILE (을)를 사용하려면 , 서버 호스트로의 FILE 권한이 필요하게 됩니다.

See 항4.3.7. 「MySQL 하지만 제공하는 권한」 .

MySQL 3.23.49 (와)과 MySQL 4.0.2 (Windows 그럼 4.0.13 ) 이?~ 그럼,LOCAL (은)는 서버와 서버 클라이언트의 양쪽 모두로 이것이 유효로서 설정되어 있는 경우에게만 기능합니다.예를 들어,--local-infile=0 (을)를 지정해 mysqld (을)를 기동했을 경우,LOCAL (은)는 기능하지 않습니다. See 항4.3.4. 「LOAD DATA LOCAL 의 시큐러티 관련 사항」 .

키워드 LOW_PRIORITY (을)를 지정하면,LOAD DATA 스테이트먼트의 실행은, 다른 클라이언트에 의한 테이블에서의 독해가 종료할 때까지 늦추어집니다.

MyISAM 테이블에 대해서 키워드 CONCURRENT (을)를 지정하면,LOAD DATA 의 실행중에 다른 스레드가 이 테이블에서 데이타를 뽑기 시작할 수 있습니다.당연히, 이 옵션의 사용은, 동시에 테이블을 사용하고 있는 다른 스레드가 없어도,LOAD DATA 의 퍼포먼스에 다소 영향을 줍니다.

LOCAL (을)를 지정했을 경우, 파일의 내용을 접속에 의해서 클라이언트로부터 서버에 보내지 않으면 안 되기 때문에, 서버가 파일에 직접 액세스 하는 경우보다 처리가 약간 늦어집니다.그 반면, 로컬 파일의 로드에는 FILE 권한은 필요 없습니다.

버젼 3.23.24 보다 전의 버젼의 MySQL (을)를 사용하고 있는 경우는,LOAD DATA INFILE (을)를 사용해 FIFO (으)로부터 읽어낼 수 없습니다.FIFO (으)로부터 읽어낼 필요가 있는 경우는(gunzip 의 출력 등), 대신에 LOAD DATA LOCAL INFILE (을)를 사용합니다.

데이터 파일의 로드는,mysqlimport 유틸리티에서도 실행할 수 있습니다.이 경우,LOAD DATA INFILE 커멘드가 서버에 보내집니다.--local 옵션을 지정했다 mysqlimport 그럼, 데이터 파일이 클라이언트 호스트로부터 읽어내집니다.--compress 옵션을 지정하면, 클라이언트와 서버로 압축된 프로토콜이 서포트되고 있는 경우에, 속도의 늦은 네트워크의 퍼포먼스를 잘 할 수 있습니다.

파일이 서버 호스트상에 있는 경우, 서버는 다음의 규칙에 따릅니다.

  • 절대 패스명이 지정되어 있는 경우, 서버는 그 패스명을 그대로 사용한다.

  • 상대 패스명이 지정되어 있는 경우, 서버는 서버의 데이터 디렉토리를 기준으로 해 파일을 검색한다.

  • 디렉토리의 지정없이 파일명이 지정되어 있는 경우, 서버는 경향 데이타베이스의 데이타베이스 디렉토리에서 파일을 검색한다.

주의: 이러한 규칙에 근거해,./myfile.txt (이)라는 이름의 파일은 서버의 데이터 디렉토리로부터 읽어내지는데 대해,myfile.txt (이)라는 이름의 같은 파일에 대해서는 경향 데이타베이스의 데이타베이스 디렉토리로부터 읽어내집니다.예를 들어, 다음의 LOAD DATA 스테이트먼트에서는,db2 데이타베이스내의 테이블에의 파일의 로드가 명시적으로 지정되어 있습니다만, 파일 data.txt (은)는 경향 데이타베이스이다 db1 의 데이타베이스 디렉토리로부터 읽어내집니다.

mysql> USE db1;
mysql> LOAD DATA INFILE "data.txt" INTO TABLE db2.my_table;

REPLACE 키워드와 IGNORE 키워드에서는, 기존의 레코드의 값과 중복 하는 유니크 키치를 가지는 입력 레코드의 처리가 제어됩니다.

REPLACE 하지만 지정되어 있는 경우, 입력 레코드에 의해서 기존의 레코드를 옮겨놓을 수 있습니다(즉, 레코드의 프라이머리 또는 유니크 인덱스의 값이 기존의 레코드의 값과 같은 경우, 그 레코드에 의해서 기존의 레코드를 옮겨놓을 수 있습니다). See 항6.4.7. 「REPLACE 구문」 .

IGNORE 하지만 지정되어 있는 경우, 유니크 키치가 기존의 레코드의 값과 중복 하는 입력 레코드가 스킵 됩니다. 어느 쪽의 옵션도 지정되어 있지 않은 경우, 동작은 LOCAL 키워드가 지정되어 있는지 어떤지에 따라서 다릅니다. LOCAL 하지만 지정되어 있지 않은 경우, 중복 한 키의 값이 검출되면 에러가 되어, 텍스트 파일의 나머지의 부분이 무시됩니다. LOCAL 하지만 지정되어 있는 경우, 디폴트의 동작은 IGNORE 하지만 지정되어 있는 경우와 같습니다.왜냐하면, 서버는 처리의 한중간에 파일의 송신을 정?~ 할 수 없기 때문입니다.

로드시에 외부 키 제약을 무시하려면 ,LOAD DATA 의 실행전에 SET FOREIGN_KEY_CHECKS=0 (을)를 지정합니다.

하늘의 MyISAM 테이블에 대해서 LOAD DATA INFILE (을)를 사용하면, 비독특한 인덱스의 모든 것이 다른 배치에 작성됩니다(REPAIR 의 경우와 같이).인덱스가 많이 있는 경우, 통상, 이것에 의해서 LOAD DATA INFILE 의 처리가 아득하게 신속화됩니다.통상, 이 처리는 매우 신속합니다만, 극단적인 케이스에서는,ALTER TABLE .. DISABLE KEYS 그리고 인덱스를 무효로 한 후,ALTER TABLE .. ENABLE KEYS (을)를 사용해 인덱스를 재작성하는 것이 한층 더 신속히 인덱스를 작성할 수 있기도 합니다. See 항4.5.6. 「myisamchk (을)를 사용한 테이블의 보수와 크래쉬의 리커버리」 .

LOAD DATA INFILE 하 SELECT ... INTO OUTFILE 의 역입니다. See 항6.4.1. 「SELECT 구문」 . 테이블에서 파일에 데이터를 쓰려면 ,SELECT ... INTO OUTFILE (을)를 사용합니다. 파일을 다시 테이블에 읽어내려면 ,LOAD DATA INFILE (을)를 사용합니다. FIELDS 마디와 LINES 마디의 구문은, 어느 쪽의 커멘드에서도 같습니다.어느 쪽의 마디도 옵션으로서 지정할 수 있습니다만, 이러한 마디를 양쪽 모두 지정하는 경우는,FIELDS (을)를 LINES 보다 전으로 지정할 필요가 있습니다.

FIELDS 마디를 지정하는 경우는, 그 때의 종속절(TERMINATED BY ,[OPTIONALLY] ENCLOSED BY ,ESCAPED BY ) 도 옵션으로서 지정할 수 있습니다만, 적어도 이러한 우리 1 개는 반드시 지정할 필요가 있습니다.

FIELDS 마디를 지정하지 않는 경우, 디폴트는 다음과 같이 기술했을 경우와 같습니다.

FIELDS TERMINATED BY '\t' ENCLOSED BY '' ESCAPED BY '\\'

LINES 마디를 지정하지 않는 경우, 디폴트는 다음과 같이 기술했을 경우와 같습니다.

LINES TERMINATED BY '\n'

주의: Winodows 그럼 행 종단 기호로서 2 문자를 사용하고 있기 때문에, 텍스트 파일을 Windows 시스템으로 생성했을 경우는, 통상, 위의 기술을 LINES TERMINATED BY '\r\n' (으)로 변경할 필요가 있습니다.wordpad 등의 일부의 프로그램에서는, 행 종단 기호로서 \r (을)를 사용할 수 있습니다.

독해 대상행의 모두에게 존재하는 프리픽스를 스킵 할 필요가 있을 때는,LINES STARTING BY prefix_string (을)를 사용할 수 있습니다.

따라서, 디폴트의 LOAD DATA INFILE (은)는 입력 데이터의 독해시에 다음과 같이 동작합니다.

  • 개행 문자에서는, 행의 경계를 찾는다.

  • LINES STARTING BY prefix 하지만 지정되어 있는 경우, 프리픽스가 검출될 때까지 읽어내, 프리픽스의 뒤에 있는 문자로부터 다시 독해를 개시한다.행에 프리픽스가 포함되지 않은 경우는, 그 행을 스킵 한다.

  • 탭 문자에서는, 행을 필드에 단락짓는다.

  • 필드는 어느 인용 문자에도 둘러싸이지 않았다고 간주한다.

  • ‘\ ＇ 에 계속 되는 탭, 개행,‘\ ＇ 의 각 문자는, 필드치의 일부를 이루는 리터럴 문자로서 해석한다.

반대로, 디폴트의 SELECT ... INTO OUTFILE (은)는 출력의 기입시에 다음과 같이 동작합니다.

  • 필드간에는 탭 문자를 쓴다.

  • 필드는 인용 문자로 둘러싸지 않는다.

  • 필드치내의 탭, 개행,‘\ ＇ 의 각 문자는, 각각 ‘\ ＇ 그리고 이스케이프 한다.

  • 줄 끝에는 개행 문자를 쓴다.

주의: FIELDS ESCAPED BY '\\' (와)과 기술할 때 , 단일 backslash로서 읽어내게 하는 값을 나타내는 것으로서 backslash를 2 개지정할 필요가 있습니다.

IGNORE number LINES 옵션은, 파일의 선두에 있는 행을 무시시키는 목적으로 사용합니다.예를 들어, 다음과 같이,IGNORE 1 LINES (와)과 지정하는 것에 의해서, 컬럼명이 포함된 최초의 헤더행(1 행)을 스킵 시킬 수 있습니다.

mysql> LOAD DATA INFILE "/tmp/file_name" INTO TABLE test IGNORE 1 LINES;

SELECT ... INTO OUTFILE (와)과 LOAD DATA INFILE (을)를 병행해 사용하고, 데이타베이스로부터 파일에 데이터를 써, 그 후 파일로부터 데이타베이스에 다시 읽어내는 경우는, 필드와 행의 처리에 관한 양쪽 모두의 커멘드의 옵션이 일치하고 있지 않으면 안됩니다.일치하고 있지 않는 경우, 파일의 내용이 LOAD DATA INFILE 에 의해서 올바르게 해석되지 않습니다.예를 들어,SELECT ... INTO OUTFILE (을)를 사용하고, 콤마로 단락지어진 필드를 가지는 파일을 쓴다고 합니다.

mysql> SELECT * INTO OUTFILE 'data.txt'
    ->          FIELDS TERMINATED BY ','
    ->          FROM ...;

콤마로 단락지어진 파일을 다시 읽어내는 올바른 스테이트먼트는, 다음과 같이 됩니다.

mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2
    ->           FIELDS TERMINATED BY ',';

위의 스테이트먼트가 아니고, 다음에 나타내는 스테이트먼트로 파일을 읽어내려고 하면, 처리는 올바르게 행해지지 않습니다.왜냐하면, 이 스테이트먼트에서는, 필드간에 탭 문자를 찾는 듯 LOAD DATA INFILE 에 지시하고 있기 (위해)때문입니다.

mysql> LOAD DATA INFILE 'data.txt' INTO TABLE table2
    ->           FIELDS TERMINATED BY '\t';

이 경우, 입력 파일의 각 행이 단일의 필드로서 해석되어 버립니다.

LOAD DATA INFILE 그럼, 외부 소스로부터 얻을 수 있던 파일을 읽어낼 수도 있습니다.예를 들어,dBASE 형식의 파일에는, 콤마로 단락지어져 한편 이중 인용부호로 둘러싸인 필드가 포함되어 있습니다.파일의 각 행의 종단이 개행 문자에 의해서 나타나고 있는 경우, 이 파일을 로드하려면 다음의 커멘드를 사용합니다.이 커멘드에서는, 이 파일의 필드와 행의 처리에 관한 옵션을 지정해 있습니다.

mysql> LOAD DATA INFILE 'data.txt' INTO TABLE tbl_name
    ->           FIELDS TERMINATED BY ',' ENCLOSED BY '"'
    ->           LINES TERMINATED BY '\n';

필드나 행의 각 처리 옵션에는, 모두 하늘의 문자열('' )(을)를 지정할 수 있습니다.하늘의 문자열이 아닌 경우,FIELDS [OPTIONALLY] ENCLOSED BY (와)과 FIELDS ESCAPED BY 의 값은 단일의 문자가 아니면 안됩니다.FIELDS TERMINATED BY (와)과 LINES TERMINATED BY 의 값에는, 복수의 문자도 사용할 수 있습니다.예를 들어, 종단에 개행/ 복귀의 페어가 붙은 행을 쓰거나 이러한 행을 포함한 파일을 읽어내는 경우는,LINES TERMINATED BY '\r\n' 마디를 지정합니다.

예를 들어,%% 의 행으로 단락지어진 농담집의 파일을 SQL 테이블에 읽어내는 경우는, 다음과 같이 기술합니다.

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 그럼, 필드의 인용 처리가 제어됩니다.출력(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 형태와 VARCHAR 형태의 필드를 둘러싸기 위해인 만큼 사용됩니다.

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 지정 문자가 포함되는 경우는, 직전에 ESCAPED BY 지정 문자를 붙이는 것에 의해서 이스케이프 됩니다.주의: ESCAPED BY 에 하늘의 문자열을 지정하면, 생성된 출력을 LOAD DATA INFILE 하지만 올바르게 읽어낼 수 없는 것이 있습니다.예를 들어, 이스케이프 문자가 하늘의 경우, 전출의 예의 출력은 다음과 같이 표시됩니다.4 행목의 2 번째의 필드에는, 인용부호에 잇고 콤마가 포함되어 있습니다.이 콤마는 필드의(실제로는 종단 기호는 아닌데) 종단 기호와 같이 보입니다.

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 지정 문자로 시작되어 있는 경우, 후속의 ENCLOSED BY 지정 문자는, 그 뒤로 필드 또는 행의 TERMINATED BY 지정 문자열이 있는 경우에게만, 필드치의 종단으로서 해석됩니다. 애매성을 배제하기 위해(때문에),ENCLOSED BY 지정 문자를 필드내에서 통상의 문자로서 사용하는 경우,2 회 계속해 사용하는 것으로 통상의 1 문자로서 해석시킬 수 있습니다.예를 들어,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 에 하늘 이외의 문자가 지정되어 있는 경우, 출력으로 그 문자가 다음의 문자의 전에 붙일 수 있습니다.

  • FIELDS ESCAPED BY 지정 문자 자체

  • FIELDS [OPTIONALLY] ENCLOSED BY 지정 문자

  • FIELDS TERMINATED BY (와)과 LINES TERMINATED BY (으)로 지정된 값의 최초의 문자

  • ASCII 0 (이스케이프 문자에 이어 실제로 기술되는 것은, 제로치의 아르바이트는 아니고 ASCII '0' )

FIELDS ESCAPED BY 의 지정이 하늘의 경우, 어느 문자도 이스케이프 처리되지 않습니다. 데이터의 필드치에 상기의 문자가 포함되어 있는 경우는 특히, 이스케이프 문자로서 공문자는 지정해야 하지는 않습니다.

입력으로는,FIELDS ESCAPED BY 에 하늘 이외의 문자가 지정되어 있는 경우, 그 문자는 제거되어 거기에 계속 되는 문자가 필드치의 일부로서 통상의 문자와 같이 해석됩니다.다만,‘0 ＇ 또는 ‘N ＇ 하지만 이스케이프 되고 있는 경우(예를 들어, 이스케이프 문자가 ‘\ ＇ 의 경우의 \0 또는 \N )(은)는 예외입니다.이러한 문자열은 ASCII 0 (제로치의 아르바이트) 및 NULL (으)로서 해석됩니다.아래와 같은 NULL 의 처리에 관한 규칙을 참조해 주세요.

‘\ ＇ (을)를 사용한 이스케이프 구문의 상세한 것에 대하여는, 항6.1.1. 「리터럴: 문자열과 수치의 기술 방법」 (을)를 참조해 주세요.

경우에 따라서는, 다음에 나타내도록(듯이), 필드와 행의 각 처리 옵션이 서로 작용하는 일이 있습니다.

  • LINES TERMINATED BY 에 하늘의 문자열이 지정되어 있고,FIELDS TERMINATED BY 에 하늘 이외의 문자열이 지정되어 있는 경우, 행의 종단도 FIELDS TERMINATED BY 지정 문자열에 의해서 나타난다.

  • FIELDS TERMINATED BY (와)과 FIELDS ENCLOSED BY 의 값이 어느쪽이나 하늘('' )의 경우, 고정 레코드(단락지어 없음)의 형식이 사용된다. 고정장 레코드의 형식에서는, 필드 사이에 단락지어 기호는 사용되지 않는다(행 종단 기호는 사용 가능).대신에, 컬럼의 `` 표시'' 폭에 근거해 컬럼치가 읽고 쓰기된다.예를 들어, 컬럼이 INT(7) (으)로서 선언되고 있는 경우, 그 컬럼의 값은 7 문자의 필드를 사용해 써진다.인력시에는, 그 컬럼의 값은,7 문자를 읽어내는 것에 의해서 취득된다.

    이 경우도, 각 행의 분리에는,LINES TERMINATED BY 하지만 사용된다.1 행에 모든 필드가 포함되지 않은 경우, 나머지의 필드에는 각각의 디폴트치가 설정된다.행 종단 기호가 없는 경우는, 종단 기호를 '' (으)로서 지정하도록(듯이) 한다.이 경우, 텍스트 파일에 각 레코드의 모든 필드가 포함되지 않으면 안 된다.

    고정장 레코드 형식은,NULL 값의 처리에도 영향을 줍니다.아래와 같이를 참조. 주의: 멀티 바이트 문자의 캐릭터 세트를 사용하고 있는 경우, 고정 사이즈 형식은 기능하지 않는다.

NULL 값의 처리는, 사용되고 있다 FIELDS 옵션과 LINES 옵션에 따라서 다릅니다.

  • FIELDS (와)과 LINES 의 값이 디폴트의 경우, 출력으로는 NULL 하지만 \N (으)로서 써져 입력으로는 \N 하지만 NULL (으)로서 읽어내진다(ESCAPED BY 지정 문자가 ‘\ ＇ 의 경우).

  • FIELDS ENCLOSED BY 에 하늘 이외의 문자가 지정되어 있는 경우, 리터럴의 NULL (을)를 값으로 해서 가지는 필드는 NULL 값으로 해서 읽어내진다(이것은,FIELDS ENCLOSED BY 지정 문자로 둘러싸인 말 NULL 하지만, 문자열 'NULL' (으)로서 읽어내지는 것과 다르다).

  • FIELDS ESCAPED BY 의 지정이 하늘의 경우,NULL 하 NULL 그렇다고 하는 말로서 써진다.

  • 고정장 레코드 형식(FIELDS TERMINATED BY (와)과 FIELDS ENCLOSED BY 의 양쪽 모두의 지정이 하늘의 경우)에서는,NULL (은)는 하늘의 문자열로서 써진다.주의: 거기에 따르고, 파일에의 써 때에, 테이블내의 NULL 값과 하늘의 문자열의 양쪽 모두가 하늘의 문자열로서 써지기 위해, 그것들을 구별할 수 없게 된다.파일을 다시 읽어낼 때 이것들을 구별할 수 있도록 할 필요가 있는 경우는, 고정 레코드 형식은 사용하지 않게 한다.

다음에 나타내는 케이스는 LOAD DATA INFILE 그리고 서포트하고 있지 않습니다.

  • 고정장 사이즈의 레코드(FIELDS TERMINATED BY (와)과 FIELDS ENCLOSED BY 의 지정이 어느쪽이나 하늘)과 BLOB 또는 TEXT 형태의 컬럼.

  • 1 개의 단락 기호가 다른 단락 문자와 완전히 같은가, 다른 단락 기호의 선두의 부분과 같은 경우,LOAD DATA INFILE (은)는 입력을 올바르게 해석할 수 없다.예를 들어, 다음의 FIELDS 마디에서는 문제가 발생한다.

    FIELDS TERMINATED BY '"' ENCLOSED BY '"'

  • FIELDS ESCAPED BY 의 지정이 하늘의 경우,FIELDS ENCLOSED BY 또는 LINES TERMINATED BY 의 지정 문자에 이어 FIELDS TERMINATED BY 지정치가 있으면,LOAD DATA INFILE (은)는 필드 또는 행의 독해를 잘못해 빨리 정?~ 한다. 이것은, 필드 또는 행의 값의 종단을 LOAD DATA INFILE 하지만 올바르게 판별할 수 없기 위해(때문에) 일어난다.

다음의 예에서는,persondata 테이블의 모든 컬럼이 로드 됩니다.

mysql> LOAD DATA INFILE 'persondata.txt' INTO TABLE persondata;

필드 리스트는 지정되어 있지 않기 때문에,LOAD DATA INFILE (은)는 입력 레코드에 각 테이블 컬럼의 필드가 포함되어 있으면 간주합니다.디폴트의 FIELDS 값과 LINES 값이 사용됩니다.

테이블의 일부의 컬럼만 로드하는 경우는, 필드 리스트를 지정합니다.

mysql> LOAD DATA INFILE 'persondata.txt'
    ->           INTO TABLE persondata (col1,col2,...);

입력 파일내의 필드의 순서가 테이블의 컬럼의 순서와 다른 경우도, 필드 리스트를 지정할 필요가 있습니다.리스트를 지정하지 않으면 입력 필드와 테이블의 각 컬럼을 어떻게 일치시키면 좋은가 MySQL 그리고 인식할 수 없습니다.

레코드에 포함되어 있는 필드의 수가 부족한 경우, 입력 필드가 결핍 하고 있는 컬럼에게는 디폴트치가 설정됩니다.디폴트치의 할당에 대해서는, 항6.5.3. 「CREATE TABLE 구문」 그리고 설명하고 있습니다.

하늘의 필드치는 필드치가 결핍 하고 있는 경우와는 다른 해석을 하십니다.

  • 문자열형의 컬럼의 경우는, 값으로 해서 하늘의 문자열이 설정된다.

  • 수치형의 컬럼의 경우는, 값으로 해서 0 하지만 설정된다.

  • 일자와 시각형의 컬럼의 경우는, 값으로서 그 형태에 대응한다 `` 제로'' 값이 설정된다. See 항6.2.2. 「일자와 시각형」 .

주의: 이것들은,INSERT (이)나 UPDATE 스테이트먼트로 문자열형, 수치형, 일자 또는 시각형의 컬럼에 공백의 문자열을 명시적으로 할당했을 경우와 같은 값입니다.

TIMESTAMP 형태의 컬럼에서는, 그 컬럼에 NULL 값(즉 \N )(이)가 있을 때인가, 필드 리스트의 지정시에 그 TIMESTAMP 형태의 컬럼이 생략 되고 있었을 때만(이것은 최초의 TIMESTAMP 컬럼 에 대해서만 적용), 컬럼의 값으로 해서 현재의 일시가 설정됩니다.

입력 레코드에 포함되는 필드가 너무 많은 경우, 여분의 필드는 무시되어 경고수가 가산됩니다.주의: MySQL 4.1.1 보다 전의 버젼에서는, 경고는 발생한 어떠한 문제를 나타내는 수로 밖에 없었습니다. MySQL 4.1.1 그럼,SHOW WARNINGS 에 의해서, 발생한 문제의 상세를 표시할 수 있습니다.

LOAD DATA INFILE (은)는 모든 입력을 문자열로서 간주하기 위해,INSERT 스테이트먼트의 경우와는 달라,ENUM 형태나 SET 형태의 컬럼에 수치를 사용할 수 없습니다.ENUM 형태와 SET 형태의 값은 모두 문자열로서 지정할 필요가 있습니다.

C API (을)를 사용하고 있는 경우는,LOAD DATA INFILE 쿼리의 완료시에 API 함수 mysql_info() (을)를 호출하는 것에 의해서, 쿼리에 관한 정보를 취득할 수 있습니다.정보 문자열의 형식은 다음과 같습니다.

Records: 1  Deleted: 0  Skipped: 0  Warnings: 0

Warnings (경고)(은)는,INSERT 스테이트먼트(see 항6.4.3. 「INSERT 구문」 )(으)로 값을 삽입할 때와 같은 상황으로 발생합니다만, 그 외에, 입력 레코드에 포함되는 필드가 너무 많은 경우와 너무 적은 경우에도 경고가 생성됩니다.경고는 어디에도 격납되지 않습니다.단지, 경고의 수를, 처리가 정상적으로 행해졌는지를 나타내는 인디케이터(indicator)로서 이용할 수 있을 뿐입니다.

경고가 출력되었을 경우에 그 정확한 이유를 확인할 필요가 있을 때는,1 개의 방법으로서SELECT ... INTO OUTFILE (을)를 사용해 다른 파일에 출력해, 원의 입력 파일과 비교할 수 있습니다.

LOAD DATA 에 파이프로부터 읽어내게 할 필요가 있는 경우는, 다음의 방법을 사용할 수 있습니다.

mkfifo /mysql/db/x/x
chmod 666 /mysql/db/x/x
cat < /dev/tcp/10.1.1.12/4711 > /nt/mysql/db/x/x
mysql -e "LOAD DATA INFILE 'x' INTO TABLE x" x

3.23.25 보다 전의 버젼의 MySQL (을)를 사용하고 있는 경우는, 상기의 방법은 LOAD DATA LOCAL INFILE 에서만 사용 가능합니다.

MySQL 4.1.1 그럼,SHOW WARNINGS (을)를 사용하고,max_error_count (으)로 지정된 수의 경고의 최초의 리스트를 취득할 수 있습니다. See 항4.6.8.9. 「SHOW WARNINGS | ERRORS 」 .

INSERT (와)과 LOAD DATA INFILE 의 효율성의 비교나,LOAD DATA INFILE 의 신속화의 상세한 것에 대하여는,See 항5.2.10. 「INSERT 쿼리의 속도」 .

6.4.9. HANDLER 구문

HANDLER tbl_name OPEN [ AS alias ]
HANDLER tbl_name READ index_name { = | >= | <= | < } (value1,value2,...)
    [ WHERE ... ] [LIMIT ... ]
HANDLER tbl_name READ index_name { FIRST | NEXT | PREV | LAST }
    [ WHERE ... ] [LIMIT ... ]
HANDLER tbl_name READ { FIRST | NEXT }
    [ WHERE ... ] [LIMIT ... ]
HANDLER tbl_name CLOSE

HANDLER 스테이트먼트에서는,MyISAM 테이블의 스토리지 엔진 인터페이스에 직접 액세스 할 수 있습니다.

최초의 형식의 HANDLER 스테이트먼트에서는, 테이블이 열려 후속의 HANDLER ... READ 스테이트먼트로의 액세스가 가능하게 됩니다. 이 테이블 오브젝트는 다른 스레드와 공유되어 있지 않기 때문에, 그 스레드가 HANDLER tbl_name CLOSE (을)를 호출하는지, 또는 그 스레드가 종료할 때까지, 테이블 오브젝트가 닫혀질 것은 없습니다.

2 번째의 형식의 HANDLER 스테이트먼트에서는, 지정한 인덱스가 지정한 값에 매치해, 한편 WHERE 조건을 채워 있다 1 개(또는,LIMIT 마디의 지정에 근거하는 복수)의 레코드가 읽어내집니다.복합 인덱스가 있는 경우는, 대상의 인덱스 컬럼치를 콤마로 단락지어진 리스트로서 지정합니다.이 경우, 인덱스의 모든 컬럼의 각 치를 지정하는지, 또는 인덱스 컬럼의 좌단의 프리픽스의 값을 지정합니다.예를 들어,col_a ,col_b ,col_c (이)라는 이름의 3 살의 컬럼이 이 순서로 인덱스에 포함되어 있다고 합니다. HANDLER 스테이트먼트에서는, 인덱스의 3 개 모든 컬럼의 값을 지정하는지, 또는 좌단의 프리픽스의 컬럼의 값을 지정할 수 있습니다.다음에 예를 나타냅니다.

HANDLER ... index_name = (col_a_val,col_b_val,col_c_val) ...
HANDLER ... index_name = (col_a_val,col_b_val) ...
HANDLER ... index_name = (col_a_val) ...

3 번째의 형식의 HANDLER 스테이트먼트에서는,WHERE 조건을 채워 있다 1 개(또는,LIMIT 마디의 지정에 근거하는 복수)의 레코드가 테이블에서 인덱스의 순서로 읽어내집니다.

4 번째의 형식의 HANDLER 스테이트먼트(인덱스의 지정 없음)에서는,WHERE 조건을 채워 있다 1 개(또는,LIMIT 마디의 지정에 근거하는 복수)의 레코드가 테이블에서 그의 레코드 순서(데이터 파일에 격납되고 있는 순서)로 읽어내집니다.테이블의 풀 스캔을 실시할 필요가 있는 경우, 이 형식은 HANDLER tbl_name READ index_name 형식보다 신속합니다.

HANDLER ... CLOSE 그럼,HANDLER ... OPEN 그리고 열린 테이블이 닫혀집니다.

주의:PRIMARY KEY 의 HANDLER 인터페이스를 사용하고 있는 경우는,HANDLER tbl READ `PRIMARY` > (...) (와)과 같이, 키워드 PRIMARY (을)를 박크크트 기호로 반드시 둘러쌉니다.

HANDLER (은)는, 약간 저레벨의 스테이트먼트입니다.예를 들어, 정합성은 확보되지 않습니다.즉,HANDLER ... OPEN (은)는 테이블의 snapshot를 취하는 것에서는 없고 , 테이블의 락도 실시하지 않습니다 .그 때문에,HANDLER ... OPEN 의 발행 후에, 테이블 데이터가 변경될(그 스레드 또는 다른 스레드에 의해서) 가능성이 있습니다.이러한 변경은 HANDLER ... NEXT 스캔이나 HANDLER ... PREV 스캔에서는 부분적 밖에 나타나지 않는 것이 있습니다.

통상의 SQL 대신에 이 인터페이스를 사용하는 이유는, 다음과 같습니다.

  • 다음의 이유로,SELECT 보다 처리가 신속.

    • HANDLER OPEN 그럼, 지정한 스토리지 엔진을 스레드에 할당할 수 있다.

    • 실행되는 해석이 적다.

    • Optimizer나 쿼리 체크의 오버헤드가 없다.

    • 2 개의 핸들러 요구간으로, 사용 테이블을 잠글 필요가 없다.

    • 핸들러 인터페이스에서는, 정합성이 있는 데이터의 제공은 중요해지지 않기 때문에( 예를 들어, 더티 리드가 가능),SQL 에 의해서 통상 허가되지 않는 최적화를 스토리지 엔진으로 실행할 수 있다.

  • ISAM (와)과 같은 MySQL 인터페이스를 사용하는 어플리케이션의 이식을 훨씬 용이하게 실행할 수 있다.

  • SQL 그럼 어려운(경우에 따라서는 불가능한) 방법으로, 데이타베이스를 스캔 할 수 있다.데이타베이스의 대화식 유저 인터페이스를 제공하는 어플리케이션을 처리하는 경우에는, 데이터를 참조하는 방법으로서 핸들러 인터페이스를 사용하는 편이 보다 자연스럽다.

6.4.10. DO 구문

DO expression, [expression, ...]

위의 구문에서는, 식이 실행됩니다만, 결과는 아무것도 돌려주어지지 않습니다.이것은 SELECT expression, expression 의 생략형입니다만, 결과가 필요없는 경우에는, 처리 속도가 약간 빠르다고 하는 이점이 있습니다.

이 구문은, 주로,RELEASE_LOCK 등과 같이 부차적인 영향이 있는 함수에 사용하면 편리합니다.


6.5. 데이터 정의: CREATE ,DROP ,ALTER

6.5.1. CREATE DATABASE 구문

CREATE DATABASE [IF NOT EXISTS] db_name

CREATE DATABASE 그럼, 지정한 이름의 데이타베이스가 작성됩니다.

사용 가능한 데이타베이스명의 규칙은, 항6.1.2. 「데이타베이스명, 테이블명, 인덱스명, 컬럼명, 앨리어스(alias)명」 그리고 설명하고 있습니다.IF NOT EXISTS (을)를 지정하고 있지 않을 때에, 데이타베이스가 이미 존재하고 있으면, 에러가 발생합니다.

MySQL 그럼, 데이타베이스는, 대응하는 파일을 그 내부에 포함한 디렉토리로서 실장됩니다.작성 당초의 데이타베이스에는 테이블은 아무것도 없기 때문에,CREATE DATABASE 스테이트먼트의 실행에서는,MySQL 데이터 디렉토리아래에 디렉토리가 작성될 뿐입니다.

데이타베이스의 작성은 mysqladmin 그렇지만 가능합니다. See 항4.9. 「MySQL 클라이언트 사이드의 스크립트와 유틸리티」 .

6.5.2. DROP DATABASE 구문

DROP DATABASE [IF EXISTS] db_name

DROP DATABASE 그럼, 데이타베이스내의 모든 테이블이 파기되어 데이타베이스가 삭제됩니다.기호 연결이 있는 데이타베이스에 대해서 DROP DATABASE (을)를 실행하면, 링크와 원래의 데이타베이스와의 양쪽 모두가 삭제됩니다. 이 커멘드의 사용시에는, 충분히 주의해 주세요.

DROP DATABASE 그럼, 데이타베이스 디렉토리로부터 삭제된 파일의 수가 돌려주어집니다.MyISAM 테이블의 경우, 통상, 각 테이블이 .MYD ,.MYI ,.frm 의 3 개의 파일에 대응하고 있기 때문에, 파일수는 테이블수의 3 배가 됩니다.

DROP DATABASE 커멘드에서는, 다음의 확장자(extension)를 가지는 모든 파일이, 지정한 데이타베이스 디렉토리로부터 삭제됩니다.

확장자(extension) | 확장자(extension) | 확장자(extension) | 확장자(extension)
.BAK | .DAT | .HSH | .ISD
.ISM | .ISM | .MRG | .MYD
.MYI | .db | .frm |

2 자리수의 수치로 구성되는 서브 디렉토리(RAID 디렉토리)도 모두 삭제됩니다.

MySQL 버젼 3.22 이?~ 그럼, 키워드 IF EXISTS (을)를 사용하고, 데이타베이스가 존재하지 않는 경우에 발생하는 에러를 회피할 수 있습니다.

데이타베이스의 파기는 mysqladmin 그렇지만 가능합니다. See 항4.9. 「MySQL 클라이언트 사이드의 스크립트와 유틸리티」 .

6.5.3. CREATE TABLE 구문

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 [)];

create_definition:
    col_name type [NOT NULL | NULL] [DEFAULT default_value] [AUTO_INCREMENT]
            [[PRIMARY] KEY] [COMMENT 'string'] [reference_definition]
  | [CONSTRAINT [symbol]] PRIMARY KEY (index_col_name,...)
  | KEY [index_name] (index_col_name,...)
  | INDEX [index_name] (index_col_name,...)
  | [CONSTRAINT [symbol]] UNIQUE [INDEX] [index_name] (index_col_name,...)
  | FULLTEXT [INDEX] [index_name] (index_col_name,...)
  | [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (index_col_name,...)
            [reference_definition]
  | CHECK (expr)

type:
    TINYINT[(length)] [UNSIGNED] [ZEROFILL]
  | SMALLINT[(length)] [UNSIGNED] [ZEROFILL]
  | 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]
  | CHAR(length) [BINARY | ASCII | UNICODE]
  | VARCHAR(length) [BINARY]
  | DATE
  | TIME
  | TIMESTAMP
  | DATETIME
  | TINYBLOB
  | BLOB
  | MEDIUMBLOB
  | LONGBLOB
  | TINYTEXT
  | TEXT
  | MEDIUMTEXT
  | LONGTEXT
  | ENUM(value1,value2,value3,...)
  | SET(value1,value2,value3,...)

index_col_name:
        col_name [(length)] [ASC | DESC]

reference_definition:
        REFERENCES tbl_name [(index_col_name,...)]
                   [MATCH FULL | MATCH PARTIAL]
                   [ON DELETE reference_option]
                   [ON UPDATE reference_option]

reference_option:
        RESTRICT | CASCADE | SET NULL | NO ACTION | SET DEFAULT

table_options: table_option [table_option] ...

table_option:
    TYPE = {BDB | HEAP | ISAM | InnoDB | MERGE | MRG_MYISAM | MYISAM }
  | AUTO_INCREMENT = #
  | AVG_ROW_LENGTH = #
  | CHECKSUM = {0 | 1}
  | COMMENT = 'string'
  | MAX_ROWS = #
  | MIN_ROWS = #
  | PACK_KEYS = {0 | 1 | DEFAULT}
  | PASSWORD = 'string'
  | DELAY_KEY_WRITE = {0 | 1}
  | ROW_FORMAT = { DEFAULT | DYNAMIC | FIXED | COMPRESSED }
  | RAID_TYPE = { 1 | STRIPED | RAID0 } RAID_CHUNKS=#  RAID_CHUNKSIZE=#
  | UNION = (table_name,[table_name...])
  | INSERT_METHOD = { NO | FIRST | LAST }
  | DATA DIRECTORY = 'absolute path to directory'
  | INDEX DIRECTORY = 'absolute path to directory'
  | DEFAULT CHARACTER SET character_set_name [COLLATE collation_name]

select_statement:
    [IGNORE | REPLACE] [AS] SELECT ...     (Some legal select statement)

CREATE TABLE 그럼, 지정한 이름의 테이블이 작성됩니다. 사용 가능한 테이블명의 규칙은, 항6.1.2. 「데이타베이스명, 테이블명, 인덱스명, 컬럼명, 앨리어스(alias)명」 그리고 설명하고 있습니다. 디폴트에서는, 테이블은 경향 데이타베이스에 작성됩니다. 테이블이 벌써 존재하는 경우, 경향 데이타베이스가 없는 경우, 또는 데이타베이스가 존재하지 않는 경우에는, 에러가 발생합니다.

MySQL 버젼 3.22 이?~ 그럼, 테이블명을 db_name.tbl_name 의 형식에서 지정하는 것으로, 지정한 데이타베이스에 테이블을 작성할 수 있습니다. 이것은, 경향 데이타베이스의 유무에 관계없이 유효합니다.

MySQL 버젼 3.23 이?~ 그럼, 테이블의 작성시에 TEMPORARY 키워드를 지정할 수 있습니다.텐포라리테이불은 현재의 접속동안만 유효하고, 접속이 닫으면 자동으로 삭제됩니다.그 때문에, 다르다 2 개의 접속이 같은 텐포라리테이불명을 사용할 수 있습니다.이 경우, 각각의 접속의 텐포라리테이불간에 충돌이 발생하거나 동명의 기존의 테이블과의 사이에 콘후크리트가 발생하거나 할 것은 없습니다(기존의 테이블은 텐포라리테이불이 삭제될 때까지 표시되지 않습니다).MySQL 4.0.2 이?~ 그럼, 텐포라리테이불의 작성에는,CREATE TEMPORARY TABLES 권한이 필요합니다.

MySQL 버젼 3.23 이?~ 그럼, 키워드 IF NOT EXISTS (을)를 사용하고, 테이블이 벌써 존재하는 경우에 발생하는 에러를 회피할 수 있습니다.주의: 기존의 테이블의 구조가,CREATE TABLE 스테이트먼트로 지정된 테이블의 구조와 같을지는 검증되지 않습니다.

버젼 4.1.0 이?~ 그럼, 속성 SERIAL (을)를 BIGINT NOT NULL AUTO_INCREMENT UNIQUE 의 앨리어스(alias)로서 사용할 수 있습니다.이것은 호환성을 고려한 기능입니다.

MySQL 3.23 이?~ 그럼,CREATE TABLE 스테이트먼트의 마지막에 SELECT 스테이트먼트를 추가하는 것에 의해서,1 개의 테이블에서 다른 테이블을 작성할 수 있습니다.

CREATE TABLE new_tbl SELECT * FROM orig_tbl;

인덱스는 새로운 테이블에 미루어지지 않습니다.또, 일부의 컬럼형의 변환을 하는 경우가 있습니다.예를 들어,AUTO_INCREMENT 속성은 유지되지 않고,VARCHAR 형태의 컬럼은 CHAR 형태의 컬럼이 되는 일이 있습니다.

CREATE ... SELECT 그리고 테이블을 작성할 경우에는, 쿼리내의 함수 호출이나 식에 대해서 반드시 앨리어스(alias)를 지정하도록(듯이) 합니다.앨리어스(alias)를 지정하지 않으면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 4.1 이?~ 그럼, 생성되는 컬럼의 형태를 명시적으로 지정할 수 있습니다.

CREATE TABLE foo (a tinyint not null) SELECT b+1 AS 'a' FROM bar;

MySQL 4.1 그럼,LIKE 그렇지만, 다른 테이블의 정의에 근거해 새로운 테이블(원의 테이블의 컬럼 속성이나 인덱스를 모두 포함한다)을 작성할 수 있습니다.

CREATE TABLE new_tbl LIKE orig_tbl;

CREATE TABLE ... LIKE 그럼, 원의 테이블로 지정되었다 DATA DIRECTORY (이)나 INDEX DIRECTORY 의 테이블 옵션은 모두 카피되지 않습니다.

데이타베이스 디렉토리내의 일부의 파일에는, 각 테이블의 tbl_name 하지만 반영됩니다.MyISAM 형태의 테이블의 경우, 다음과 같이 됩니다.

파일 | 용도
tbl_name.frm | 테이블 형식(정의) 파일
tbl_name.MYD | 데이터 파일
tbl_name.MYI | 인덱스 파일

다양한 컬럼형의 특성의 상세한 것에 대하여는, 항6.2. 「컬럼형」 (을)를 참조해 주세요.

  • NULL 도 NOT NULL 도 지정되어 있지 않은 경우, 컬럼은 NULL 하지만 지정되어 있을 때 것과 같이 처리된다.

  • 정수형 컬럼은 추가 속성 AUTO_INCREMENT (을)를 가질 수 있다. 인덱스 첨부의 AUTO_INCREMENT 컬럼에 NULL (추천) 또는 0 (을)를 삽입하면, 그 컬럼에게는 연속치의 다음의 값이 설정된다. 통상, 이것은 value+1 (이)가 된다(value (은)는 테이블에 현재 격납되고 있는 그 컬럼의 최대치). AUTO_INCREMENT 하 1 (으)로부터 개시된다. See 항11.1.3.32. 「mysql_insert_id() 」 .

    MySQL 4.1.1 이?~ 그럼,--sql-mode 서버 옵션 또는 sql_mode 서버 변수에 대해서 NO_AUTO_VALUE_ON_ZERO 플래그를 지정하는 것에 의해서, 새로운 연속치를 생성하는 대신에,AUTO_INCREMENT 컬럼에 0 (을)를 0 (으)로서 격납할 수 있다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

    AUTO_INCREMENT 컬럼의 최대치가 들어간 레코드를 삭제했을 경우, 그 값은 ISAM 테이블이나 BDB 테이블에서는 재이용되지만,MyISAM 테이블이나 InnoDB 테이블에서는 재이용되지 않는다.DELETE FROM table_name (WHERE 마디 없음)을 AUTOCOMMIT 모드로 실행해 테이블내의 모든 레코드를 삭제했을 경우,InnoDB (을)를 제외하는 모든 테이블형으로, 연속치가 처음부터 개시된다. See 항7.5.12.5. 「InnoDB (으)로의 AUTO_INCREMENT 컬럼의 구조」 .

    주의: AUTO_INCREMENT 컬럼은 테이블 마다 1 개만 존재할 수 있다.이 컬럼에게는 인덱스를 붙일 필요가 있어, 또 DEFAULT 값은 설정할 수 없다. MySQL 버젼 3.23 그럼,AUTO_INCREMENT 컬럼은, 정의 값만을 가지는 경우에게만 올바르게 기능한다.부의 수치가 삽입되면, 그 값은 극히 큰 정수로서 보인다. 이것은, 수치가 정의 수로부터 부의 수에 `` 되풀이한다'' 풀어에 발생하는 정도의 문제를 회피하기 위해(때문에)와0 하지만 들어갔다 AUTO_INCREMENT 컬럼이 잘못해 취득되지 않게 하기 위한(해)이다.

    MyISAM 테이블과 BDB 테이블에서는, 복합 인덱스로 AUTO_INCREMENT 세칸다리카람을 지정할 수 있다. See 항3.6.9. 「AUTO_INCREMENT 의 사용」 .

    MySQL (와)과 일부의 ODBC 어플리케이션과의 호환성을 확보하기 위해(때문에), 마지막에 삽입된 레코드의 AUTO_INCREMENT 값을 다음의 쿼리로 검출할 수 있다.

    SELECT * FROM tbl_name WHERE auto_col IS NULL

  • TIMESTAMP 형태 컬럼에서는, 다른 컬럼형과는 다른 방법으로 NULL 값이 처리된다.TIMESTAMP 형태 컬럼에게는,NULL (은)는 격납할 수 없다.컬럼에 NULL (을)를 삽입하면, 컬럼의 값으로 해서 현재의 일시가 설정된다.TIMESTAMP 형태의 컬럼은 이와 같이 동작하기 위해(때문에),NULL 속성과 NOT NULL 속성은 통상대로는 적용되지 않고, 그것들을 지정해도 무시된다.

    그 한편,TIMESTAMP 형태의 컬럼을 MySQL 클라이언트에 있어서 사용하기 쉽게 하기 위해서, 서버는, (실제로는,TIMESTAMP 형태 컬럼에게는 NULL 값은 격납되지 않음에도 불구하고)TIMESTAMP 형태 컬럼에 대해서,NULL 값의 할당이 가능(true )(이)라고 보고한다.DESCRIBE tbl_name (을)를 사용해 테이블에 관한 기술을 취득하면, 이것을 확인할 수 있다.

    주의: TIMESTAMP 형태의 컬럼에, 값으로 해서 0 (을)를 설정하는 것은,NULL (을)를 설정하는 것과는 다르다.0 하 TIMESTAMP 형태의 유효한 값이다.

  • DEFAULT 값은 정수가 아니면 안되어, 함수나 식을 사용할 수 없다.

    DEFAULT 값이 지정되어 있지 않은 경우, 그 컬럼에게는, 다음의 방법으로,MySQL 에 의해서 DEFAULT 값을 자동적으로 할당할 수 있다.

    값으로 해서 NULL (을)를 잡히는 컬럼의 경우, 디폴트치는 NULL (이)가 된다.

    NOT NULL (으)로서 선언되고 있는 컬럼의 경우, 디폴트치는 각각의 컬럼형에 의해서 정해진다.

    • AUTO_INCREMENT 속성을 가진다고 선언되어 있지 않은 수치형 컬럼의 경우, 디폴트는 0 .AUTO_INCREMENT 컬럼의 경우, 디폴트치는 연속치의 다음의 값이 된다.

    • TIMESTAMP 형태 이외의 일자와 시각형의 경우, 디폴트는 그 형태에 대응하는 제로치.테이블내의 최초의 TIMESTAMP 형태 컬럼의 디폴트치는, 현재의 일시가 된다. See 항6.2.2. 「일자와 시각형」 .

    • ENUM 형태 이외의 문자열형의 경우, 디폴트치는 하늘의 문자열.ENUM 의 경우, 디폴트치는 최초의 열거치가 된다.

    디폴트치는 정수가 아니면 안된다.따라서, 일자 컬럼의 디폴트치로서NOW() (이)나 CURRENT_DATE 등의 함수를 설정할 수 없다.

  • COMMENT 옵션에서는, 컬럼에 관한 코멘트를 지정할 수 있다. 코멘트는 SHOW CREATE TABLE 스테이트먼트와 SHOW FULL COLUMNS 그리고 표시된다. 이 옵션은 MySQL 4.1 (으)로부터 이용 가능(그 이전의 버젼에서는, 사용은 가능하지만 무시된다).

  • KEY (은)는, 통상 INDEX 의 동의어. 버젼 4.1 이?~ , 키 속성 PRIMARY KEY (은)는 단지 KEY (으)로서 지정할 수도 있다.이 기능은 다른 데이타베이스와의 호환성을 고려해 실장되었다.

  • MySQL 그럼,UNIQUE 키에는 중복이 없는 값 이외는 격납할 수 없다. 기존의 레코드의 키와 같은 키를 가지는 새로운 레코드를 추가하려고 하면, 에러가 발생한다.

  • PRIMARY KEY (은)는, 모든 키 컬럼이 NOT NULL (으)로서 정의되어 있지 않으면 안 되는 유니크 KEY 이다.NOT NULL (으)로서 명시적으로 정의되어 있지 않으면 암묵적(한편 자동적)으로 NOT NULL (으)로 설정된다.MySQL 에 두고, 이 키는 PRIMARY (으)로 불린다.개개의 테이블은 PRIMARY KEY (을)를 1 개만 가질 수 있다. PRIMARY KEY 하지만 없는 경우에, 어떠한 어플리케이션이 테이블의 PRIMARY KEY (을)를 요구하면,MySQL 그럼,NULL 컬럼을 전혀 가지지 않는 최초의 UNIQUE 키가 PRIMARY KEY (으)로서 돌려주어진다.

  • 복합 인덱스를 PRIMARY KEY (으)로 할 수도 있다.그러나, 컬럼의 사양으로 PRIMARY KEY 키 속성을 사용해 복합 인덱스는 작성할 수 없다.그처럼 해도, 단일의 컬럼이 프라이머리로서 마크 되는 것에 지나지 않는다. 이 경우, 별로 PRIMARY KEY(index_col_name, ...) 마디를 사용할 필요가 있다.

  • UNIQUE 인덱스에서는, 인덱스의 모든 값에 중복이 없는 상태가 아니면 안된다.다만, 예외로서 그 인덱스의 컬럼의 1 개로 NULL 값이 격납 가능한 경우, 복수의 NULL 값을 격납할 수 있다. 이 예외는 BDB 형태의 테이블에는 적용되지 않는다.BDB 형태의 테이블에는 단일의 NULL 마셔 격납 가능.

  • PRIMARY 키 또는 UNIQUE 키가 단일의 컬럼으로 구성되어 있고, 그 컬럼형이 정수형의 경우, 그 키는 _rowid (으)로서 참조할 수도 있다(버젼 3.23.11 의 신기능).

  • PRIMARY KEY (이)가 아닌 인덱스에 이름을 할당하지 않으면 그 인덱스는 index_col_name 의 최초의 컬럼명과 같은 이름을 할당할 수 있어 그 인덱스를 일의(유니크)인 것으로 하기 위한 옵션의 사픽스(_2 ,_3 ,... )(이)가 붙일 수 있다.테이블의 인덱스명은 SHOW INDEX FROM tbl_name (을)를 사용해 확인할 수 있다. See 항4.6.8.1. 「데이타베이스, 테이블, 컬럼, 및 인덱스에 관한 정보의 취득」 .

  • NULL 값을 가질 수 있는 컬럼에 대한 인덱스의 작성은,MyISAM ,InnoDB ,BDB 의 각 테이블형에서만 서포트하고 있다.그 외의 테이블에서는, 컬럼이 NOT NULL (와)과 선언되어 있지 않으면 에러가 된다.

  • 인덱스의 지정으로 col_name(length) 구문을 사용하는 것에 의해서,CHAR 형태 또는 VARCHAR 형태 컬럼의 최초부터 length (으)로 지정한 길이의 아르바이트만을 사용하는 인덱스를 작성할 수 있다.이 방법으로, 인덱스 파일의 사이즈를 꽤 작게 할 수 있다. See 항5.4.4. 「컬럼 인덱스」 .

  • BLOB 형태와 TEXT 형태의 컬럼의 인덱스의 작성은,MyISAM 테이블과(MySQL 4.0.14 이?~ 의)InnoDB 테이블에서만 서포트하고 있다.BLOB 형태 또는 TEXT 형태의 컬럼에 인덱스를 붙일 때는, 인덱스의 길이(최대 255 아르바이트)를 반드시 지정할 필요가 있다.다음에 예를 나타낸다.

    CREATE TABLE test (blob_col BLOB, INDEX(blob_col(10)));

  • index_col_name 의 지정에서는, 마지막에 ASC 또는 DESC (을)를 붙일 수 있다. 이러한 키워드는, 승순 또는?~ 순서에 의한 인덱스치의 격납을 지정할 수 있도록 하는 향후의 확장에 대응하고 있다.현시점에서는, 이러한 키워드는 해석되지만 무시된다.인덱스치는 항상 승순으로 격납된다.

  • TEXT 형태 또는 BLOB 형태의 컬럼으로 ORDER BY 또는 GROUP BY 하지만 사용되고 있으면, 서버는, 최초의 부분의, max_sort_length 서버 변수가 나타내 보이는 수의 아르바이트만을 사용해 값을 소트 한다. See 항6.2.3.2. 「BLOB 형태와 TEXT 형태」 .

  • MySQL 버젼 3.23.23 이?~ 그럼, 특수한 FULLTEXT 인덱스도 작성할 수 있다.이것은 풀텍스트 검색에 사용된다.FULLTEXT 인덱스는,MyISAM 테이블에서만 서포트하고 있다.이 인덱스는,CHAR 형태,VARCHAR 형태,TEXT 형태의 컬럼으로부터 마셔 작성할 수 있다. 인덱스의 작성은 항상 컬럼 전체에 대해서 행해진다.부분적인 인덱스의 작성은 행해지지 않는다.처리의 상세한 것에 대하여는, 항6.8. 「MySQL 풀텍스트 검색」 (을)를 참조.

  • MySQL 버젼 3.23.44 이?~ 그럼,InnoDB 테이블로 외부 키 제약의 체크를 서포트하고 있다.See 항7.5. 「InnoDB 테이블」 . 주의: InnoDB (으)로의 FOREIGN KEY 구문은 위에 나타낸 구문보다 제한되고 있다.참조 테이블의 컬럼명은, 반드시 명시적으로 지정할 필요가 있다. InnoDB 그럼,MySQL 3.23.50 이?~ , 외부 키에 대한다 ON DELETE 액션을, 또 MySQL 4.0.8 이?~ 그럼 ON UPDATE 액션을 서포트하고 있다. 정확한 구문에 대해서는, 이 메뉴얼의 InnoDB 의 섹션을 참조. See 항7.5.5.2. 「FOREIGN KEY 제약」 . 다른 테이블형에 대해서는,MySQL 서버는 CREATE TABLE 커멘드의 FOREIGN KEY ,CHECK ,REFERENCES 의 각 구문을 해석하지만, 그 이상의 처리는 실시하지 않는다. See 항1.8.4.5. 「외부 키」 .

  • MyISAM 테이블과 ISAM 테이블의 경우, 각 NULL 컬럼은 1 비트 여분으로 사용하고, 가장 가까운 아르바이트에 끝맺을 수 있다. 아르바이트로의 최대 레코드장은 다음과 같이 계산된다.

    레코드장 = 1
             + (
컬럼장의 합계)
             + (NULL
컬럼의 수 + delete_flag + 7)/8
             + (
가변장 컬럼의 수)

    정적 레코드 형식의 테이블에서는,delete_flag 하 1 .정적 테이블에서는, 행 레코드로, 그 레코드가 삭제된 것인지를 나타내는 플래그용으로 1 비트가 사용된다.동적 테이블에서는, 이 플래그는 가변장 레코드의 머리에 격납되기 위해,delete_flag 하 0 (이)가 된다.

    이러한 계산은 InnoDB 테이블에는 적용되지 않는다.InnoDB 테이블에서는,NULL 컬럼의 격납 사이즈는 NOT NULL 컬럼과 비교해 변하지 않다.

  • table_options 옵션과 SELECT 옵션은 MySQL 버젼 3.23 이?~ 에서만 실장되고 있다.

    테이블형을 지정한다 TYPE 옵션은 다음의 값을 받는다.

    테이블형 | 설명
    BDB 또는 BerkeleyDB | 페이지의 락을 실시하는, 트랜잭션(transaction) 세이프 테이블. See 항7.6. 「BDB 또는 BerkeleyDB 테이블」 .
    HEAP | 이 테이블의 데이터는 메모리 밖에 격납되지 않는다. See 항7.4. 「HEAP 테이블」 .
    ISAM | 원래의 스토리지 엔진. See 항7.3. 「ISAM 테이블」 .
    InnoDB | 행 락을 실시하는, 트랜잭션(transaction) 세이프 테이블. See 항7.5. 「InnoDB 테이블」 .
    MERGE | 1 개의 테이블로서 사용된다 MyISAM 테이블의 모임. See 항7.2. 「MERGE 테이블」 .
    MRG_MyISAM | MERGE 의 앨리어스(alias).
    MyISAM | ISAM 에 대신하는, 바이너리의 이식이 가능한 새로운 스토리지 엔진. See 항7.1. 「MyISAM 테이블」 .

    See 장 7. MySQL 의 테이블형 .

    테이블형이 지정되어 있을 때, 그 테이블형을 사용할 수 없는 경우,MySQL 그럼, 대신에 MyISAM 하지만 사용된다. 예를 들어, 테이블 정의에 TYPE=BDB 옵션이 포함되어 있을 때,BDB 형태의 테이블을 MySQL 서버로 서포트하고 있지 않는 경우, 테이블은 MyISAM 테이블로서 작성된다.그 때문에, 마스터에 트랜잭션(transaction) 테이블이 있으면서, 슬레이브에서는 비트랜잭션(transaction) 테이블을 작성한다(속도를 올리기 위해)라고 한, replication 설정이 가능하게 된다.MySQL 4.1.1 그럼, 지정한 테이블형을 받아들일 수 없다고 경고가 출력된다.

    그 외의 테이블 옵션은, 테이블의 동작을 최적화하기 위해서 사용된다.대부분의 경우, 이것들은 모두 지정하지 않아 좋다. 이러한 옵션은, 특히 거절이 없는 한, 모든 테이블형에 적용된다.

    옵션 | 설명
    AUTO_INCREMENT | 테이블로 설정하는 다음의 AUTO_INCREMENT 값(MyISAM 테이블만.InnoDB 테이블의 최초의 AUTO_INCREMENT 값을 설정하려면 ,1 개 적은 값을 가지는 다?~ -레코드를 삽입해, 나중에 그 다?~ -레코드를 삭제한다).
    AVG_ROW_LENGTH | 테이블의 레코드의 길이의 평균의 근사치.가변 사이즈 레코드를 가지는 큰 테이블 이외에서는, 이 값을 설정할 필요는 없다.
    CHECKSUM | 모든 로의 체크삼을 MySQL 에 유지시키려면 , 이 값을 1 (으)로 설정하는(그것에 의해, 테이블의 갱신 속도는 약간 늦어지지만, 파손한 테이블을 찾아내기 쉬워진다)(MyISAM 테이블만).
    COMMENT | 테이블에 관한,60 문자의 코멘트.
    MAX_ROWS | 테이블에 격납할 예정의 최대 레코드수.
    MIN_ROWS | 테이블에 격납할 예정의 최소 레코드수.
    PACK_KEYS | 인덱스의 사이즈를 작게 하려면 , 이 값을 1 (으)로 설정한다.통상, 그것에 의해, 갱신 속도가 늦어지지만, 독해는 빨라진다(MyISAM 테이블과 ISAM 테이블만).이 값을 0 (으)로 설정하면, 키의 팩이 모두 무효화된다.이 값을 DEFAULT (으)로 설정하면(MySQL 4.0 의 경우), 스토리지 엔진에 의해서,CHAR 형태 또는 VARCHAR 형태의 긴 컬럼만이 팩 된다.
    PASSWORD | 패스워드를 사용해 .frm 파일을 암호화한다.표준의 MySQL 버젼에서는, 이 옵션을 지정해도 아무것도 행해지지 않는다.
    DELAY_KEY_WRITE | 테이블이 닫혀질 때까지 키 테이블의 갱신을 늦추려면 , 이 값을1 (으)로 설정한다(MyISAM 테이블만).
    ROW_FORMAT | 레코드의 격납 방법을 정의한다.현재, 이 옵션은, 형식으로서 DYNAMIC (와)과 FIXED (을)를 서포트하고 있다 MyISAM 테이블 에 대해서만 기능한다. See 항7.1.2. 「MyISAM 테이블 형식」 .

    MyISAM 테이블의 사용시에는,MySQL 그리고,MAX_ROWS * AVG_ROW_LENGTH 의 적에 의해서, 결과의 테이블이 어느 정도의 사이즈가 될까의 계산을 한다.상기의 옵션의 어느 것도 지정하지 않으면 테이블의 최대 사이즈는 4G (사용하고 있는 operating system로 2G 의 테이블 밖에 서포트되어 있지 않을 때는 2G )(이)가 된다.그 이유는, 단지 큰 파일이 필요하지 않은 경우에, 포인터의 사이즈를 억제하는 것에 의해서, 인덱스를 보다 작고, 보다 신속화하는 것에 있다.

    PACK_KEYS (을)를 지정하지 않으면 디폴트에서는, 문자열의 팩만 행해져 수치의 팩은 행해지지 않는다.PACK_KEYS=1 (와)과 지정하면, 수치도 팩 된다.

    바이너리 수치 키의 팩시에는,MySQL 에 의해서 프리픽스의 압축을 한다. 즉, 이것에 의해서 큰 이익을 얻을 수 있는 것은, 같은 수치가 많이 존재하는 경우에 한정된다.프리픽스의 압축에서는, 전의 키의 몇 바이트가 다음의 키와 같은가를 나타내는 추가의 1 아르바이트가 각 키로 필요하게 된다(주의: 압축의 퍼포먼스를 자주(잘) 하기 위한(해), 키의 직후에, 레코드의 포인터가 상위 바이트로부터 하위 바이트의 순서에 격납된다).따라서, 연속한다 2 개의 레코드에 같은 키가 많이 있을 때, 통상,`` 같다'' 키의 뒤에 계속 되는 것은 모두 2 아르바이트(레코드의 포인터도 포함해) 밖에 취하지 않는다.거기에 비교해 통상의 경우는, 후에 계속 되는 키로 storage_size_for_key + pointer_size 분 (통상 4 아르바이트) 필요하게 된다.그 한편, 모든 키가 완전히 다른 경우는,NULL 값을 가질 수 없는 각 키로 1 아르바이트 여분으로 사용된다(이 경우, 팩 된 키의 길이는, 키가 NULL 일지를 나타내는 아르바이트와 같은 아르바이트에 격납된다).

  • MySQL 3.23 이?~ 그럼,CREATE 스테이트먼트의 뒤에 SELECT (을)를 지정하면,SELECT 의 모든 요소에 대응하는 새로운 필드가 MySQL 에 의해서 작성된다.다음에 예를 나타낸다.

    mysql> CREATE TABLE test (a INT NOT NULL AUTO_INCREMENT,
    ->        PRIMARY KEY (a), KEY(b))
    ->        TYPE=MyISAM SELECT b,c FROM test2;

    이 경우,a ,b ,c 의 3 살의 컬럼을 가진다 MyISAM 테이블이 작성된다. 주의: SELECT 스테이트먼트로부터의 컬럼은, 테이블 위에 겹칠 수 있는 것이 아니라, 테이블의 우측으로 추가된다.다음에 예를 나타낸다.

    mysql> SELECT * FROM foo;
+---+
| n |
+---+
| 1 |
+---+

mysql> CREATE TABLE bar (m INT) SELECT n FROM foo;
Query OK, 1 row affected (0.02 sec)
Records: 1  Duplicates: 0  Warnings: 0

mysql> SELECT * FROM bar;
+------+---+
| m    | n |
+------+---+
| NULL | 1 |
+------+---+
1 row in set (0.00 sec)

    테이블 foo 의 각 레코드에 대응하는 레코드가,foo (으)로부터의 값과 새로운 컬럼의 디폴트치와 함께 bar 에 삽입된다.

    CREATE TABLE ... SELECT 그럼, 인덱스의 작성은 자동에서는 행해지지 않는다.이것은, 이 커멘드를 가능한 한 유연한 것으로 하기 때문에 있다.작성하는 테이블에 인덱스가 필요한 경우는,SELECT 스테이트먼트의 전에 인덱스를 지정한다.

    mysql> CREATE TABLE bar (UNIQUE (n)) SELECT n FROM foo;

    테이블에의 데이터의 카피시에 에러가 발생했을 경우, 데이터는 자동으로 삭제된다.

    SELECT 의 전에 IGNORE 또는 REPLACE (을)를 붙이는 것으로, 유니크 키치가 중복 하는 레코드의 처리 방법을 지정할 수 있다. IGNORE 의 경우, 새로운 레코드의 유니크 키치가 기존의 레코드의 값과 중복 하고 있으면, 그 새로운 레코드는 파기된다.REPLACE 의 경우, 새로운 레코드에 의해서, 같은 유니크 키치를 가지는 기존의 레코드가 치환된다.IGNORE (와)과 REPLACE 의 어느쪽이나 지정하고 있지 않는 경우, 유니크 키치의 중복이 검출되면 에러가 된다.

    갱신 로그나 바이너리 로그를 사용해 원의 테이블을 확실히 재작성할 수 있듯이 하기 위한(해),MySQL 그럼 CREATE TABLE ... SELECT 실행중의 동시 삽입은 실시할 수 없다.

  • RAID_TYPE 옵션에서는, 큰 파일을 서포트하고 있지 않는 operating system로 MyISAM 데이터 파일(인덱스 파일은 아니고)에 대한다 2G 또는 4G 의 제한을 넘을 수 있다.주의: 이 옵션은 큰 파일을 서포트하고 있는 파일 시스템에서는 추천 되지 않는다.

    다른 물리 디스크상에 RAID 디렉토리를 배치하는 것에 의해서 I/O 의 보틀 넥을 신속화할 수 있다.RAID_TYPE (은)는 모든 operating system로 기능하지만,MySQL 의 콘피개를 --with-raid (으)로서 가 둘 필요가 있다.현시점에서 사용 가능한 RAID_TYPE 하 STRIPED (1 (와)과 RAID0 (은)는 이 앨리어스(alias)).

    MyISAM 테이블에 대해서 RAID_TYPE=STRIPED (와)과 지정하면, 데이타베이스 디렉토리에,00 ,01 ,02 그렇다고 한다 RAID_CHUNKS 서브 디렉토리가 MyISAM 에 의해서 작성된다.이러한 디렉토리의 각각으로,table_name.MYD 하지만 MyISAM 에 의해서 작성된다.데이터 파일에의 데이터의 기입시,RAID 핸들러에 의해서, 최초의 RAID_CHUNKSIZE *1024 아르바이트가 최초의 파일에 맵 되어 다음의 RAID_CHUNKSIZE *1024 아르바이트가 다음의 파일에 맵 된다(이하 같이).

  • UNION (은)는, 동일 테이블의 콜렉션을 1 개의 것으로 해 사용하는 경우로 지정한다.이것은,MERGE 테이블 에 대해서만 기능한다. See 항7.2. 「MERGE 테이블」 .

    현재로서는,MERGE 테이블에 맵 하는 테이블에 대한다 SELECT ,UPDATE ,DELETE 의 각 권한이 필요하게 된다. 맵 대상의 테이블은 모두 MERGE 테이블과 같은 데이타베이스에 존재해야 한다.

  • MERGE 테이블에 데이터를 삽입하려면 , 레코드의 삽입처로 하는 테이블을 INSERT_METHOD 그리고 지정할 필요가 있다. INSERT_METHOD 하 MERGE 테이블에만 사용할 수 있는 옵션이다.See 항7.2. 「MERGE 테이블」 .이 옵션은 MySQL 4.0.0 그리고 도입되었다.

  • 작성된 테이블에서는, 최초로 PRIMARY 키가 놓여져서 계속 되어 모든 UNIQUE 키, 통상 키의 순서에 배치된다.그 때문에,MySQL Optimizer로 사용하는 키를 우선시킬 수 있어 또 중복 한다 UNIQUE 키를 보다 신속히 검출할 수 있다.

  • DATA DIRECTORY='directory' 또는 INDEX DIRECTORY='directory' (을)를 사용하는 것에 의해서, 스토리지 엔진의 데이터 파일과 인덱스 파일의 격납 장소를 지정할 수 있다.주의: 이 directory 에는, 대상의 디렉토리의 풀 패스(상대 패스는 아니고)를 지정한다.

    이것은,MySQL 4.0 에 두고,--skip-symlink 옵션은 지정하지 않을 때의 MyISAM 테이블 에 대해서만 기능한다. See 항5.6.1.2. 「Unix 위의 테이블에 대한 기호 연결의 사용」 .

6.5.3.1. 컬럼의 암묵적인 변경

경우에 따라서는,CREATE TABLE 스테이트먼트로 지정되어 있는 컬럼의 형태, 속성이,MySQL 에 의해서 암묵적으로 변경되는 일이 있습니다(이러한 변경은 ALTER TABLE 그렇지만 발생하는 경우가 있습니다).

  • 길이가 4 문자에 못 미친다 VARCHAR 형태의 컬럼은 CHAR 형태로 변경된다.

  • 테이블의 몇개의 컬럼이 가변장인 경우는, 결과적으로 그 레코드 전체가 가변장이 된다.따라서, 테이블에 가변장의 컬럼(VARCHAR ,TEXT ,BLOB )(이)가 포함되어 있는 경우, 길이가 3 문자를 넘는다 CHAR 형태의 컬럼은 모두 VARCHAR 형태 컬럼으로 변경된다.이것은 컬럼의 사용 방법에는 영향을 주지 않는다.MySQL 그럼,VARCHAR 형태는 단지 문자를 격납하는 이제(벌써) 1 개의 수단으로서 사용되고 있다.MySQL 그리고 이 변환이 실행되는 이유는, 스페이스를 절약해, 테이블 처리를 신속화하기 위해(때문에)이다. See 장 7. MySQL 의 테이블형 .

  • 버젼 4.1.0 이?~ 그럼,255 문자를 넘는 길이를 가진다 CHAR 형태 또는 VARCHAR 형태의 필드는 모두 TEXT 형태에 변환된다. 이것은 호환성을 고려한 기능.

  • TIMESTAMP 형태의 표시 사이즈는 2 ~ 14 의 범위의 짝수가 아니면 안된다. 표시 사이즈로서14 (을)를 넘는 수치나 0 (을)를 지정하면, 사이즈는 강제적으로 14 (으)로 설정된다.1 ~ 13 의 범위의 홀수치를 지정하면, 사이즈는 강제적으로 1 개상의 짝수로 설정된다.

  • TIMESTAMP 형태의 컬럼에게는 리터럴의 NULL (은)는 격납할 수 없다.이 컬럼에 NULL (을)를 삽입하면, 값으로 해서 현재의 일시가 설정된다.TIMESTAMP 형태의 컬럼은 이와 같이 동작하기 위해(때문에),NULL 속성과 NOT NULL 속성은 통상대로는 적용되지 않고, 그것들을 지정해도 무시된다.DESCRIBE tbl_name 그럼,TIMESTAMP 형태의 컬럼은 항상 NULL 값의 할당이 가능이라고 보고된다.

  • MySQL 그럼, 다른 SQL 데이타베이스 벤더가 사용하고 있는 일부의 컬럼형이 MySQL 의 컬럼형에 맵 된다. See 항6.2.5. 「다른 데이타베이스 엔진의 컬럼형의 사용」 .

지정한 이외의 컬럼형이 MySQL 에 의해서 사용되었는지 확인하려면 , 테이블의 작성 또는 변경 후에,DESCRIBE tbl_name 스테이트먼트를 발행합니다.

myisampack (을)를 사용해 테이블을 압축하면, 특정의 다른 컬럼형의 변경이 발생하는 경우가 있습니다. See 항7.1.2.3. 「압축 테이블의 특성」 .

6.5.4. ALTER TABLE 구문

ALTER [IGNORE] TABLE tbl_name alter_specification [, alter_specification ...]

alter_specification:
    ADD [COLUMN] create_definition [FIRST | AFTER column_name ]
  | ADD [COLUMN] (create_definition, create_definition,...)
  | ADD INDEX [index_name] (index_col_name,...)
  | ADD [CONSTRAINT [symbol]] PRIMARY KEY (index_col_name,...)
  | ADD [CONSTRAINT [symbol]] UNIQUE [index_name] (index_col_name,...)
  | ADD FULLTEXT [index_name] (index_col_name,...)
  | ADD [CONSTRAINT [symbol]] FOREIGN KEY [index_name] (index_col_name,...)
           [reference_definition]
  | ALTER [COLUMN] col_name {SET DEFAULT literal | DROP DEFAULT}
  | CHANGE [COLUMN] old_col_name create_definition
           [FIRST | AFTER column_name]
  | MODIFY [COLUMN] create_definition [FIRST | AFTER column_name]
  | DROP [COLUMN] col_name
  | DROP PRIMARY KEY
  | DROP INDEX index_name
  | DISABLE KEYS
  | ENABLE KEYS
  | RENAME [TO] new_tbl_name
  | ORDER BY col
  | CHARACTER SET character_set_name [COLLATE collation_name]
  | table_options

ALTER TABLE 그럼, 기존의 테이블의 구조를 변경할 수 있습니다. 예를 들어, 컬럼의 추가나 삭제, 인덱스의 작성이나 파괴, 기존의 컬럼의 형태 변경, 컬럼명이나 테이블명 자체의 변경등의 조작을 실행할 수 있습니다.또, 테이블 및 테이블형에 관한 코멘트를 변경할 수도 있습니다.

See 항6.5.3. 「CREATE TABLE 구문」 .

ALTER TABLE (을)를 사용해 컬럼의 사양을 변경했음에도 불구하고, 컬럼이 변경되어 있지 않으면 DESCRIBE tbl_name 그리고 나타났을 경우는, 항6.5.3.1. 「컬럼의 암묵적인 변경」 그리고 들고 있는 이유의 어느 쪽인가에보다 , 변경이 MySQL 에 의해서 무시된 가능성이 있습니다.예를 들어,VARCHAR 형태의 컬럼을 CHAR 형태로 변경하려고 했을 때에, 다른 가변장 컬럼이 테이블에 아직 포함되어 있으면, 이 컬럼에 대해서는 VARCHAR 형태가 계속해 사용됩니다.

ALTER TABLE 의 처리에서는, 원의 테이블의 일시적인 카피가 작성됩니다. 변경은 이 카피에 대해서 실행됩니다.그 후원의 테이블이 삭제되어 새로운 테이블의 이름이 변경됩니다.이 변경 처리는, 모든 갱신이, 에러가 되는 일 없이, 확실히 새로운 테이블에 자동으로 리디렉트 되도록(듯이) 실행됩니다.ALTER TABLE 의 실행중, 원의 테이블은 다른 클라이언트에 의해서 읽어내 가능합니다.이 테이블의 갱신과 테이블에의 기입은, 새로운 테이블의 준비가 갖추어질 때까지 정?~ 됩니다.

주의: RENAME 이외의 옵션을 ALTER TABLE (으)로 지정했을 경우는, 엄밀하게는 데이터를 카피할 필요가 없을 때(컬럼명의 변경시등)에서도, 반드시 텐포라리테이불이 MySQL 에 의해서 작성됩니다.이것에 대해서는 향후 수정할 예정입니다만, 통상 ALTER TABLE (은)는 그만큼 빈번히 사용되지 않기 때문에,TODO 리스트에 있어서의 이 수정의 우선 순위는 그만큼 높지는 않습니다. MyISAM 테이블에 대해서는,myisam_sort_buffer_size 변수에 비싼 값을 설정하는 것에 의해서, 인덱스의 재작성 부분(재작성 프로세스에서 가장 처리가 늦은 부분)을 신속화할 수 있습니다.

  • ALTER TABLE (을)를 사용하기 위해서는, 대상의 테이블에 대한다 ALTER ,INSERT ,CREATE 의 각 권한이 필요.

  • IGNORE 하 SQL-92 에 대한다 MySQL 의 확장. IGNORE 그럼, 중복 하는 유니크 키가 새로운 테이블에 존재하는 경우의 ALTER TABLE 의 동작이 제어된다. IGNORE (을)를 지정하지 않는 경우는, 카피 처리가 중단되어 롤백(rollback) 된다. IGNORE (을)를 지정하면, 중복 하는 유니크 키를 가지는 레코드가 있는 경우, 최초의 레코드만이 사용되어 그 외의 레코드가 삭제된다.

  • 1 개의 ALTER TABLE 스테이트먼트로, 복수의 ADD ,ALTER ,DROP ,CHANGE 마디를 발행할 수 있다.이것은 SQL-92 에 대한다 MySQL 의 확장.SQL-92 그럼,1 개의 ALTER TABLE 스테이트먼트로 이러한 언젠가 1 개의 마디 밖에 사용할 수 없다.

  • CHANGE col_name, DROP col_name (와)과 DROP INDEX 하 SQL-92 에 대한다 MySQL 의 확장.

  • MODIFY 하 ALTER TABLE 에 대한다 Oracle 의 확장.

  • 옵션의 말 COLUMN (은)는 순수한 노이즈 워드이며, 생략 가능.

  • 그 외의 옵션을 지정하지 말아줘 ALTER TABLE tbl_name RENAME TO new_name (을)를 사용하면, 단지 테이블 tbl_name 에 대응하는 파일의 이름이 MySQL 에 의해서 변경된다.텐포라리테이불을 작성할 필요는 없다. See 항6.5.5. 「RENAME TABLE 구문」 .

  • create_definition 마디에서는,ADD 및 CHANGE 용으로 CREATE TABLE (와)과 같은 구문이 사용된다.주의: 이 구문에는, 컬럼형 뿐만이 아니라, 컬럼명이 포함된다. See 항6.5.3. 「CREATE TABLE 구문」 .

  • 컬럼명의 변경에는,CHANGE old_col_name create_definition 마디를 사용할 수 있다.이 변경을 실시하려면 , 원의 컬럼명으로 새로운 컬럼명을 지정해, 한층 더 현재의 이 컬럼의 형태를 지정한다.예를 들어,INTEGER 형태의 컬럼 a 의 이름을 b (으)로 변경하려면 , 다음과 같이 한다.

    mysql> ALTER TABLE t1 CHANGE a b INTEGER;

    CHANGE 구문에서는, 컬럼의 이름은 아니고 형태를 변경하는 경우에도, 원의 컬럼명으로 새로운 컬럼명의 양쪽 모두를(비록 같아도) 지정할 필요가 있다. 다음에 예를 나타낸다.

    mysql> ALTER TABLE t1 CHANGE b b BIGINT NOT NULL;

    다만,MySQL 버젼 3.22.16a 이?~ 그럼,MODIFY (을)를 사용하는 것으로, 컬럼의 이름을 변경하는 일 없이, 컬럼의 형태 변경을 실행할 수 있다.

    mysql> ALTER TABLE t1 MODIFY b BIGINT NOT NULL;

  • 컬럼의 일부에 관한 인덱스가 있는 경우(예를 들어,VARCHAR 형태 컬럼의 최초의 10 문자의 인덱스가 있는 경우 등),CHANGE 또는 MODIFY (을)를 사용해 그 컬럼을 단축할 경우에는, 컬럼의 길이를, 인덱스가 작성되고 있는 문자의 수보다 짧게 할 수 없다.

  • CHANGE 또는 MODIFY (을)를 사용해 컬럼의 형태를 변경할 때 ,MySQL 에 의해서, 새로운 형태에의 데이터의 변환을 가능한 한 실행된다.

  • MySQL 버젼 3.22 이?~ 그럼,FIRST 또는 ADD ... AFTER col_name (을)를 사용하고, 테이블 레코드내의 특정의 위치에 컬럼을 추가할 수 있다.디폴트에서는, 레코드의 마지막에 컬럼이 추가된다. MySQL 버젼 4.0.1 이?~ 그럼,CHANGE (이)나 MODIFY 그렇지만,FIRST 및 AFTER 키워드를 사용할 수 있다.

  • ALTER COLUMN 그럼, 컬럼이 새로운 디폴트치를 지정하는지, 또는 이전의 디폴트치를 삭제할 수 있다. 이전의 디폴트를 삭제했을 경우, 그 컬럼으로 NULL 의 격납이 가능하면, 새로운 디폴트치는 NULL (이)가 된다.그 컬럼으로 NULL 의 격납이 불가능한 경우는, 항6.5.3. 「CREATE TABLE 구문」 그리고 설명하고 있는 디폴트치가 MySQL 에 의해서 할당할 수 있다.

  • DROP INDEX 그럼, 인덱스가 삭제된다.이것은,SQL-92 에 대한다 MySQL 의 확장.See 항6.5.8. 「DROP INDEX 구문」 .

  • 컬럼이 테이블에서 파기되었을 경우, 그 컬럼은 구성요소가 되어 모든 인덱스로부터도 삭제된다.인덱스를 구성하는 모든 컬럼이 파기되었을 경우는, 그 인덱스 자체도 파기된다.

  • 테이블에 컬럼이 1 개 밖에 포함되지 않는 경우, 그 컬럼을 파기할 수 없다. 테이블의 삭제를 실행하는 것이 목적인 경우는, 컬럼을 파기하는 것이 아니라,DROP TABLE (을)를 실행한다.

  • DROP PRIMARY KEY 그럼, 프라이머리 인덱스가 파기된다.프라이머리 인덱스가 존재하지 않는 경우는, 그 테이블의 최초의 UNIQUE 인덱스가 파기된다(명시적으로 지정되었다 PRIMARY KEY 하지만 전혀 존재하지 않는 경우는,MySQL 에 의해서, 최초의 UNIQUE 키가 PRIMARY KEY (으)로서 마크 된다).

    테이블에 UNIQUE INDEX 또는 PRIMARY KEY (을)를 추가하면, 그 값은 비 UNIQUE 모든 인덱스의 전에 격납된다.이것은,MySQL 그리고 중복 키를 가능한 한 신속히 검출할 수 있듯이 하기 위한(해)이다.

  • ORDER BY 그럼, 레코드를 특정의 순서로 나란해질 수 있던 새로운 테이블을 작성할 수 있다.주의: 삽입이나 삭제를 실시한 다음은, 테이블내의 원래의 순서는 유지되지 않는다.경우에 따라서는, 다음에 테이블내의 순서부의 기준으로 하는 컬럼에 근거하고, 테이블내의 순서를 설정해 두면,MySQL (으)로의 소트가 보다 용이화 되는 일이 있다.이 옵션은 주로, 레코드의 쿼리를 대부분 특정의 순서로 실시하는 것이 분명한 경우에 도움이 된다.테이블을 큰폭으로 변경한 후에 이 옵션을 사용하는 것에 의해서, 퍼포먼스가 좋아지는 경우가 있다.

  • MyISAM 테이블에 대해서 ALTER TABLE (을)를 사용하면, 비독특한 인덱스의 모든 것이 다른 배치에 작성된다(REPAIR 의 경우와 같이). 인덱스가 많이 있는 경우는, 이것에 의해서 ALTER TABLE 의 처리가 아득하게 신속화된다.

  • MySQL 4.0 이?~ 그럼, 상기의 기능을 명시적으로 유효화할 수 있다. 그러기 위해서는,ALTER TABLE ... DISABLE KEYS 에 의해서,MySQL 에 의한다 MyISAM 테이블의 비독특한 인덱스의 갱신을 정?~ 한다. 그 후,ALTER TABLE ... ENABLE KEYS 에 의해서, 결핍 하고 있는 인덱스를 재작성한다.MySQL 에 두고, 이 처리는 1 개씩 키를 삽입하는 처리보다 훨씬 빠른 특수 알고리즘을 사용해 실행되기 위해, 대량의 삽입에서는 키를 무효화하는 것에 의해서 처리가 큰폭으로 신속화된다.

  • C API 함수 mysql_info() (을)를 사용하면, 카피된 레코드의 수와 유니크 키치의 중복에 의해 삭제된 레코드의 수(IGNORE (을)를 지정했을 경우)를 확인할 수 있다.

  • ... ADD [CONSTRAINT [symbol]] FOREIGN KEY (...) REFERENCES ... (...) (와)과 ... DROP FOREIGN KEY ... (을)를 서포트하고 있다 InnoDB 형태의 테이블을 대상으로 하고 있는 경우를 제외하고,FOREIGN KEY ,CHECK ,REFERENCES 의 각 절에서는 실제로는 아무것도 행해지지 않는다. See 항7.5.5.2. 「FOREIGN KEY 제약」 . 다른 테이블형에 관해서는, 이 구문은 호환성을 확보하는 목적으로 제공되고 있다.즉, 다른 SQL 서버에 코드를 이식해, 참조를 포함한 테이블을 작성하는 어플리케이션을 실행하기 쉽게하기 위해(때문에)이다. See 항1.8.4. 「MySQL (와)과 SQL-92 (와)과의 차이」 .

  • ALTER TABLE 그럼, 테이블 옵션 DATA DIRECTORY (와)과 INDEX DIRECTORY (은)는 무시된다.

  • CHAR 형태,VARCHAR 형태,TEXT 형태의 모든 컬럼을 새로운 캐릭터 세트로 변경하려면 (예를 들어,MySQL 4.0.x (으)로부터 4.1.1 에 업그레이드 한 후 등에), 다음과 같이 한다.

    ALTER TABLE table_name CHARACTER SET character_set_name;

    주의: 다음의 커멘드에서는, 테이블의 default character set 밖에 변경되지 않는다.

    ALTER TABLE table_name DEFAULT CHARACTER SET character_set_name;

    default character set (이)란, 테이블에 추가한다(ALTER TABLE ... ADD column 등으로) 새로운 컬럼에 대해서 캐릭터 세트를 지정하지 않았던 경우에 사용되는 캐릭터 세트.

이하에,ALTER TABLE 에 사용예를 몇개인가 나타내 보입니다.우선, 다음의 커멘드로 테이블 t1 (을)를 작성한다고 합니다.

mysql> CREATE TABLE t1 (a INTEGER,b CHAR(10));

이 테이블의 이름을 t1 (으)로부터 t2 (으)로 변경하려면 , 다음과 같이 합니다.

mysql> ALTER TABLE t1 RENAME t2;

컬럼 a (을)를 INTEGER (으)로부터 TINYINT NOT NULL (으)로 변경해(이름은 바꾸지 않고 ), 한층 더 컬럼 b (을)를 CHAR(10) (으)로부터 CHAR(20) (으)로 변경해, 한편 이 컬럼의 이름을 b (으)로부터 c (으)로 변경하려면 , 다음과 같이 합니다.

mysql> ALTER TABLE t2 MODIFY a TINYINT NOT NULL, CHANGE b c CHAR(20);

d (이)라는 이름을 가진다 TIMESTAMP 형태의 새로운 컬럼을 추가하려면 , 다음과 같이 합니다.

mysql> ALTER TABLE t2 ADD d TIMESTAMP;

컬럼 d 에 인덱스를 추가해, 컬럼 a (을)를 주키로 하려면 , 다음과 같이 합니다.

mysql> ALTER TABLE t2 ADD INDEX (d), ADD PRIMARY KEY (a);

컬럼 c (을)를 삭제하려면 , 다음과 같이 합니다.

mysql> ALTER TABLE t2 DROP COLUMN c;

c (이)라는 이름을 가지는, 정수형의 새롭다 AUTO_INCREMENT 컬럼을 추가하려면 , 다음과 같이 합니다.

mysql> ALTER TABLE t2 ADD c INT UNSIGNED NOT NULL AUTO_INCREMENT,
           ADD INDEX (c);

주의： 위의 예로 c 의 인덱스를 작성한 것은,AUTO_INCREMENT 컬럼에게는 인덱스가 필요하기 때문에입니다.또,c (을)를 NOT NULL (으)로서 선언하고 있는 것은, 인덱스 컬럼은 값으로 해서 NULL (을)를 잡히지 않기 때문입니다.

AUTO_INCREMENT 컬럼을 추가하면, 컬럼치로서 연속 번호가 자동적으로 삽입됩니다.최초의 연속 번호를 설정하려면 ,ALTER TABLE 의 전에 SET INSERT_ID=value (을)를 실행하는지, 또는 AUTO_INCREMENT=value 테이블 옵션을 지정합니다. See 항5.5.6. 「SET 구문」 .

MyISAM 테이블에서는,AUTO_INCREMENT 컬럼을 변경하지 않는 한, 연속 번호는 영향을 받지 않습니다.AUTO_INCREMENT 컬럼을 파기한 후에 다른 AUTO_INCREMENT 컬럼을 추가하면, 다시 1 (으)로부터 채번 됩니다.

See 항A.7.1. 「ALTER TABLE 의 문제」 .

6.5.5. RENAME TABLE 구문

RENAME TABLE tbl_name TO new_tbl_name[, tbl_name2 TO new_tbl_name2,...]

이름의 변경은 원자적으로 실행됩니다.즉, 테이블명이 변경되고 있는 동안, 다른 스레드에서는 이러한 테이블의 어느 것에도 액세스 할 수 없게 됩니다.거기에 따르고, 테이블을 하늘의 테이블과 치환하는 것이 가능하게 됩니다.

:

CREATE TABLE new_table (...);
RENAME TABLE old_table TO backup_table, new_table TO old_table;

이름의 변경은 왼쪽에서 오른쪽에 실행되기 위해,2 개의 테이블의 이름을 교환하는 경우는, 다음과 같이 기술할 필요가 있습니다.

RENAME TABLE old_table    TO backup_table,
             new_table    TO old_table,
             backup_table TO new_table;

데이타베이스명을 변경할 수도 있습니다만, 그 경우는, 변경 후의 데이타베이스가 변경전의 데이타베이스와 같은 디스크상에 존재하고 있지 않으면 안됩니다.

RENAME TABLE current_db.tbl_name TO other_db.tbl_name;

락 된 테이블이나 액티브한 트랜잭션(transaction)가 있으면,RENAME (은)는 실행할 수 없습니다.또, 원의 테이블에 대한다 ALTER 권한과 DROP 권한, 새로운 테이블에 대한다 CREATE 권한과 INSERT 권한이 필요합니다.

MySQL 그리고 복수 테이블의 이름의 변경시에 에러가 발생했을 경우, 이름이 변경된 모든 테이블에 대해서 역방향의 이름의 변경 처리를 해 모든 것이 원래 상태에 되돌려집니다.

RENAME TABLE 하 MySQL 3.23.23 그리고 추가되었습니다.

6.5.6. DROP TABLE 구문

DROP [TEMPORARY] TABLE [IF EXISTS] tbl_name [, tbl_name,...] [RESTRICT | CASCADE]

DROP TABLE 그럼,1 개이상의 테이블이 삭제됩니다.테이블 데이터와 테이블 정의의 모든 것이 삭제 되기 위해, 이 커멘드는 신중하게 사용해 주세요.

MySQL 버젼 3.22 이?~ 그럼, 키워드 IF EXISTS (을)를 사용하는 것에 의해서, 지정한 테이블이 존재하지 않는 경우에 발생하는 에러를 회피할 수 있습니다.4.1 그럼,IF EXISTS (을)를 지정했을 경우, 존재하지 않는 모든 테이블에 관한 NOTE 하지만 출력됩니다. See 항4.6.8.9. 「SHOW WARNINGS | ERRORS 」 .

RESTRICT (와)과 CASCADE (은)는, 이식을 용이화하기 위한 것입니다. 현재로서는, 이것들을 지정해도 아무것도 행해지지 않습니다.

주의: DROP TABLE 그럼, 현재의 액티브한 트랜잭션(transaction)가 자동적으로 코?~ 트 됩니다(4.1 (을)를 사용하고 있고,TEMPORARY 키워드를 지정했을 경우를 제외하다).

옵션 TEMPORARY (은)는,4.0 그럼 무시됩니다.4.1 그럼, 이 옵션은 다음과 같이 동작합니다.

  • 텐포라리테이불의 파기만 실시한다.

  • 실행중의 트랜잭션(transaction)는 종료되지 않는다.

  • 액세스권의 체크는 행해지지 않는다.

TEMPORARY (은)는, 실제의 테이블이 잘못해 폐기되지 않게하기 위한 수단으로서 도움이 됩니다.

6.5.7. CREATE INDEX 구문

CREATE [UNIQUE|FULLTEXT] INDEX index_name
       ON tbl_name (index_col_name,...)

index_col_name:
        col_name [(length)] [ASC | DESC]

버젼 3.22 보다 전의 MySQL 의 경우,CREATE INDEX 스테이트먼트에서는 아무것도 실행되지 않습니다.버젼 3.22 이?~ 그럼,CREATE INDEX (은)는, 인덱스를 작성한다 ALTER TABLE 스테이트먼트에 맵 되고 있습니다.

See 항6.5.4. 「ALTER TABLE 구문」 .

통상, 테이블의 인덱스는 모두, 테이블 자체를 CREATE TABLE 그리고 작성할 경우에 함께 작성합니다. See 항6.5.3. 「CREATE TABLE 구문」 . CREATE INDEX 그럼, 기존의 테이블에 인덱스를 추가할 수 있습니다.

(col1,col2,...) 형식의 컬럼 리스트에서는, 복합 인덱스가 작성됩니다.인덱스치는, 리스트로 지정한 컬럼의 값을 연결해 작성됩니다.

CHAR 형태와 VARCHAR 형태에 대해서는, 컬럼의 일부만을 사용하는 인덱스를 작성할 수 있습니다.이 경우,col_name(length) 구문을 사용하고, 각 컬럼치의 최초부터 length (으)로 지정한 수의 아르바이트의 인덱스를 작성합니다(BLOB 형태와 TEXT 형태에서는, 프리픽스의 길이를 반드시 지정할 필요가 있습니다.length 에는 255 까지의 수치를 지정할 수 있습니다).다음의 스테이트먼트에서는,name 컬럼의 최초의 10 문자를 사용한 인덱스가 작성됩니다.

mysql> CREATE INDEX part_of_name ON customer (name(10));

대부분의 이름은 최초의 10 문자가 다르기 위해, 이 인덱스의 경우,name 컬럼 전체로부터 작성한 인덱스보다 훨씬 늦어지는 것은 없습니다. 또, 컬럼의 일부에서 인덱스를 작성하면 인덱스 파일의 사이즈를 큰폭으로 삭감할 수 있기 위해, 디스크 영역이 절약되는 것과 동시에,INSERT 조작이 신속화되는 경우가 있습니다.

주의: NULL 값을 가질 수 있는 컬럼에 대한 인덱스의 추가는,MySQL 버젼 3.23.2 이?~ 그리고 MyISAM ,InnoDB ,BDB 의 몇개의 테이블형을 사용하고 있는 경우에게만 가능합니다. BLOB 형태나 TEXT 형태의 컬럼에 대한 인덱스의 추가는,MySQL 버젼 3.23.2 이?~ 그리고 MyISAM 또는 BDB 의 몇개의 테이블형을 사용하고 있는 경우인가,MySQL 버젼 4.0.14 이?~ 그리고 InnoDB 테이블형을 사용하고 있는 경우에게만 가능합니다. BLOB 형태나 TEXT 형태 컬럼의 인덱스에서는, 프리픽스의 길이를 반드시 지정할 필요가 있습니다.

index_col_name 의 지정에서는, 마지막에 ASC 또는 DESC (을)를 붙일 수 있습니다. 이러한 키워드는, 승순 또는?~ 순서에 의한 인덱스치의 격납을 지정할 수 있도록 하는 향후의 확장에 대응하는 것입니다.현시점에서는, 이러한 키워드는 해석되어도 무시되어 인덱스치는 항상 승순으로 격납됩니다.

MySQL (으)로의 인덱스의 사용 방법의 상세한 것에 대하여는, 항5.4.3. 「MySQL (으)로의 인덱스의 사용」 (을)를 참조해 주세요.

FULLTEXT 인덱스에서는,MyISAM 테이블에 있어서의 CHAR 형태,VARCHAR 형태,TEXT 형태의 컬럼 에 대해서만, 인덱스를 작성할 수 있습니다.FULLTEXT 인덱스는 MySQL 버젼 3.23.23 이?~ 그리고 사용할 수 있습니다. 항6.8. 「MySQL 풀텍스트 검색」 .

6.5.8. DROP INDEX 구문

DROP INDEX index_name ON tbl_name

DROP INDEX 그럼,index_name (으)로 지정한 인덱스가 tbl_name (으)로 지정한 테이블에서 파기됩니다.버젼 3.22 보다 전의 MySQL 그럼,DROP INDEX 그럼 어떤 처리도 행해지지 않습니다.버젼 3.22 이?~ 그럼,DROP INDEX (은)는 인덱스를 파기한다 ALTER TABLE 스테이트먼트에 맵 되고 있습니다. See 항6.5.4. 「ALTER TABLE 구문」 .


6.6. MySQL 기본 유저 유틸리티 커멘드

6.6.1. USE 구문

USE db_name

USE db_name 스테이트먼트에서는,db_name (으)로 지정한 데이타베이스를, 후속의 쿼리의 디폴트의 데이타베이스로서 사용하는 듯 MySQL 에 지시할 수 있습니다.지정한 데이타베이스는, 세션의 종료까지, 또는 다른 USE 스테이트먼트를 발행할 때까지 경향 데이타베이스가 됩니다.

mysql> USE db1;
mysql> SELECT COUNT(*) FROM mytable;      # selects from db1.mytable
mysql> USE db2;
mysql> SELECT COUNT(*) FROM mytable;      # selects from db2.mytable

USE 스테이트먼트로 특정의 데이타베이스를 경향으로 해도, 거기에 따르고, 다른 데이타베이스의 테이블에 액세스 할 수 없게 되는 것은 아닙니다.다음의 예에서는,db1 데이타베이스의 author 테이블과db2 데이타베이스의 editor 테이블에 액세스 합니다.

mysql> USE db1;
mysql> SELECT author_name,editor_name FROM author,db2.editor
    ->        WHERE author.editor_id = db2.editor.editor_id;

USE 스테이트먼트는 Sybase (와)과의 호환성을 확보하기 위한의 것입니다.

6.6.2. DESCRIBE 구문(컬럼에 관한 정보의 취득)

{DESCRIBE | DESC} tbl_name [col_name | wild]

DESCRIBE 하 SHOW COLUMNS FROM 의 간략형입니다.

See 항4.6.8.1. 「데이타베이스, 테이블, 컬럼, 및 인덱스에 관한 정보의 취득」 .

DESCRIBE 그럼, 테이블의 컬럼에 관한 정보가 출력됩니다.col_name 에는, 컬럼명을 지정하는 것 외에,SQL 의 와일드 카드 문자 ‘% ＇ (와)과 ‘_ ＇ (을)를 포함한 문자열을 지정할 수 있습니다.이 경우, 이 문자열에 일치하는 이름을 가지는 컬럼명만이 출력됩니다.문자열을 인용부호로 이스케이프 할 필요는 없습니다.

컬럼 정보로 나타난 컬럼의 형태는, 그 컬럼의 CREATE TABLE 스테이트먼트로 지정한 것과 다르고 있는 경우가 있습니다.이것은, 컬럼의 형태가 MySQL 에 의해서 자동으로 변경되는 것이 있기 때문에입니다. See 항6.5.3.1. 「컬럼의 암묵적인 변경」 .

이 스테이트먼트는 Oracle (와)과의 호환성을 확보하기 위한의 것입니다.

SHOW 스테이트먼트에서도, 같은 정보가 출력됩니다. See 항4.6.8. 「SHOW 구문」 .


6.7. MySQL 트랜잭션(transaction) 커멘드와 락 커멘드

6.7.1. START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문

디폴트에서는,MySQL (은)는 자동코?~ 트모드로 가동합니다.이 경우, 테이블을 갱신(변경)하는 스테이트먼트를 실행하면,MySQL 에 의해서 즉시 그 갱신이 디스크에 격납됩니다.

트랜잭션(transaction) 세이프 테이블(InnoDB (이)나 BDB )(을)를 사용하고 있는 경우는, 다음의 커멘드를 사용해 MySQL (을)를 비자동코?~ 트모드로 설정할 수 있습니다.

SET AUTOCOMMIT=0

AUTOCOMMIT 변수를 제로로 설정해 자동코?~ 트모드를 무효로 한 다음은,COMMIT (을)를 사용해 변경 내용을 디스크에 격납하는지, 또는, 트랜잭션(transaction)의 개시 이래 간 변경을 무시하는 경우는 ROLLBACK (을)를 사용할 필요가 있습니다.

사람 계속의 스테이트먼트에만 대해 자동코?~ 트모드를 무효로 할 경우에는,START TRANSACTION 스테이트먼트를 사용할 수 있습니다.

:

START TRANSACTION;
SELECT @A:=SUM(salary) FROM table1 WHERE type=1;
UPDATE table2 SET summmary=@A WHERE type=1;
COMMIT;

트랜잭션(transaction)를 개시할 경우에는,START TRANSACTION 대신에 BEGIN (와)과 BEGIN WORK 도 사용할 수 있습니다. START TRANSACTION 하 MySQL 4.0.11 그리고 추가되었습니다.이것은 SQL-99 의 구문이며, 트랜잭션(transaction)를 수시 개시할 경우에는 이 구문이 추천 됩니다.BEGIN 하 MySQL 3.23.17 이?~ 그리고,BEGIN WORK 하 MySQL 3.23.19 이?~ 그리고 사용할 수 있습니다.

주의: 사용하고 있는 테이블이 트랜잭션(transaction) 세이프 테이블이 아닌 경우는, 자동코?~ 트모드의 스테이터스에 관계없이, 모든 변경이 즉시 격납됩니다.

비트랜잭션(transaction) 테이블을 갱신한 후에 ROLLBACK 스테이트먼트를 발행하면, 에러(ER_WARNING_NOT_COMPLETE_ROLLBACK )(이)가 경고로서 출력됩니다.트랜잭션(transaction) 세이프 테이블은 모두 restore 됩니다만, 비트랜잭션(transaction) 세이프 테이블은 변경되지 않습니다.

START TRANSACTION 또는 SET AUTOCOMMIT=0 (을)를 사용하고 있는 경우는, 이전의 갱신 로그의 대신에MySQL 바이너리 로그를 백업용으로 사용해 주세요.트랜잭션(transaction)는 COMMIT 그와 동시에 한묶음으로 바이너리 로그에 격납되기 위해, 롤백(rollback) 된 트랜잭션(transaction)가 격납될 것은 없습니다. See 항4.10.4. 「바이너리 로그」 .

트랜잭션(transaction)의 분리 레벨을 변경하려면 ,SET TRANSACTION ISOLATION LEVEL (을)를 사용합니다. See 항6.7.6. 「SET TRANSACTION 구문」 .

6.7.2. 롤백(rollback) 할 수 없는 스테이트먼트

일부의 스테이트먼트는 롤백(rollback) 할 수 없습니다.통상, 이러한 스테이트먼트로서 데이타베이스의 작성이나 파기를 실시하는 스테이트먼트나, 테이블의 작성, 파기, 변경을 실시하는 스테이트먼트등의 데이터 정의 언어(DDL ) 스테이트먼트가 있습니다.

경우에 따라서는, 이러한 스테이트먼트를 짜넣지 않게, 트랜잭션(transaction)를 설계할 필요가 있습니다. 롤백(rollback) 할 수 없는 스테이트먼트를 트랜잭션(transaction)의 초의 분으로 발행했을 때에, 그 후별의 스테이트먼트로 에러가 발생했을 경우, 트랜잭션(transaction)의 결과 전체를 ROLLBACK 스테이트먼트로 롤백(rollback) 할 수 없습니다.

6.7.3. 암묵적인 코?~ 트를 일으키는 스테이트먼트

다음의 커멘드에서는, 트랜잭션(transaction)가(커멘드의 실행전에 COMMIT (을)를 발행했을 경우와 같이) 암묵적으로 종료합니다.

커멘드 | 커멘드 | 커멘드
ALTER TABLE | BEGIN | CREATE INDEX
DROP DATABASE | DROP INDEX | DROP TABLE
LOAD MASTER DATA | LOCK TABLES | RENAME TABLE
SET AUTOCOMMIT=1 | START TRANSACTION | TRUNCATE

몇개의 테이블이 현재 락 되고 있는 경우는,UNLOCK TABLES 그렇지만 트랜잭션(transaction)가 종료합니다.MySQL 4.0.13 보다 전의 버젼에서는, 바이너리 갱신 로그가 유효하게 되어 있으면,CREATE TABLE 그렇지만 트랜잭션(transaction)가 종료합니다.

트랜잭션(transaction)는 네스트 할 수 없습니다.이것은,START TRANSACTION 스테이트먼트나 그 몇개의 동의어의 발행시에 현재의 트랜잭션(transaction)에 대해서 실행되는 암묵적인 COMMIT 의 영향에 의하는 것입니다.

6.7.4. SAVEPOINT 및 ROLLBACK TO SAVEPOINT 구문

MySQL 4.0.14 및 4.1.1 이?~ 그럼,InnoDB 그리고 SQL 커멘드 SAVEPOINT 및 ROLLBACK TO SAVEPOINT (을)를 서포트하고 있습니다.

SAVEPOINT identifier

이 스테이트먼트에서는,identifier (으)로 지정한 이름을 가지는 트랜잭션(transaction) 세이브 포인트가 설정됩니다.현재의 트랜잭션(transaction)에 동명의 세이브 포인트가 벌써 존재하는 경우는, 원의 세이브 포인트가 삭제되어 새로운 세이브 포인트가 설정됩니다.

ROLLBACK TO SAVEPOINT identifier

이 스테이트먼트에서는, 지정한 세이브 포인트까지 트랜잭션(transaction)가 롤백(rollback) 됩니다. 세이브 포인트의 설정 후에 이 트랜잭션(transaction)로 레코드에 대해서 간 변경은, 롤백(rollback)에 의해서 삭제됩니다만,InnoDB 그럼, 세이브 포인트의 뒤에 메모리에 격납된 행 락은 해제 되지 않습니다 (주의: 새롭게 삽입된 레코드에 대해서는, 락 정보는 레코드에 격납된 트랜잭션(transaction) ID 에 의해서 건네받습니다.락 자체가 별로 메모리에 격납될 것은 없습니다.이 경우, 레코드의 락은 취소해 처리로 해제됩니다). 지정한 세이브 포인트부터 후로 설정된 세이브 포인트는 삭제됩니다.

커멘드로 다음의 에러가 돌려주어졌을 경우는, 지정한 이름의 세이브 포인트가 존재하지 않는 것을 의미합니다.

ERROR 1181: Got error 153 during ROLLBACK

세이브 포인트를 지정하지 말아줘 COMMIT 또는 ROLLBACK (을)를 실행하면, 현재의 트랜잭션(transaction)의 세이브 포인트가 모두 삭제됩니다.

6.7.5. LOCK TABLES 및 UNLOCK TABLES 구문

LOCK TABLES tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE}
            [, tbl_name [AS alias] {READ [LOCAL] | [LOW_PRIORITY] WRITE} ...]
...
UNLOCK TABLES

LOCK TABLES 그럼, 현재의 스레드의 테이블이 락 됩니다.UNLOCK TABLES 그럼, 현재의 스레드가 보유하고 있는 락이 해제됩니다.현재의 스레드가 다른 LOCK TABLES (을)를 발행하거나 서버에의 접속이 닫혀지면, 현재의 스레드가 잠그고 있는 테이블의 락은 모두 암묵적으로 해제됩니다.

MySQL 4.0.2 그리고 LOCK TABLES (을)를 사용하려면 , 관련하는 테이블에 대한 글로벌인 LOCK TABLES 권한과 SELECT 권한이 필요합니다.MySQL 3.23 그럼, 관련하는 테이블에 대한다 SELECT ,insert ,DELETE ,UPDATE 의 각 권한이 필요합니다.

LOCK TABLES (을)를 사용하는 주된 이유는, 트랜잭션(transaction)를 에?~ 레이트 하거나 테이블의 갱신시에 처리를 신속화하거나 하기 (위해)때문입니다.이것에 대해서는, 자세하게 후술 합니다.

어느 스레드가 테이블에 대한다 READ 락을 취득하면, 그 스레드( 및 다른 모든 스레드)는 그 테이블에서의 독해만 실행할 수 있게 됩니다.어느 스레드가 테이블에 대한다 WRITE 락을 취득하면, 락을 보유하고 있는 스레드만이 그 테이블에서의 독해나 테이블에의 기입을 실행할 수 있게 됩니다.다른 스레드는 블록 됩니다.

READ LOCAL (와)과 READ 의 차이는,READ LOCAL 의 경우, 락의 보유중에, 콘후크리트를 발생시키지 않는다 INSERT 스테이트먼트를 실행할 수 있는 것입니다.그러나, 락의 보유중에 데이타베이스를 MySQL 의 외부에서 조작하려고 하는 경우는, 이 기능을 사용할 수 없습니다.

LOCK TABLES 의 사용시에는, 사용하는 테이블을 모두 잠그어, 또 쿼리로 사용하는 앨리어스(alias)와 같은 이름을 사용할 필요가 있습니다.1 개의 쿼리로 같은 테이블을 몇번이나 지정하는(앨리어스(alias)를 사용해) 경우는, 각 앨리어스(alias)에 대해서 락을 취득하지 않으면 안됩니다.

갱신을 가능한 한 빨리 처리하기 위해서,WRITE 락은, 통상,READ 락보다 우선됩니다.그 때문에, 어느 스레드가 READ 락을 취득해, 다른 스레드가 WRITE 락을 요구하고 있는 경우, 후속의 READ 락 요구는,WRITE 스레드가 락을 취득해, 그 후 그 락을 해제할 때까지 대기합니다.LOW_PRIORITY WRITE 락에서는, 그 스레드가 WRITE 락을 취득하기 전에, 다른 스레드가 READ 락을 취득할 수 있습니다.그 사이,LOW_PRIORITY WRITE 락을 발행한 스레드는 대기합니다.LOW_PRIORITY WRITE (은)는,READ 락을 취득하려고 하는 스레드가 전무가 될 때가 있다고 알고 있는 경우에게만 사용해 주세요.

LOCK TABLES (은)는 다음과 같이 기능합니다.

  1. 잠그는 테이블을 내부 정의된 순서(유저가 보았을 경우는 미정도리)로 소트 한다.

  2. 독해 락과 써 락으로 테이블이 락 되는 경우는, 독해 락보다 써 락을 우선한다.

  3. 한 번에 1 개의 테이블을 잠그어, 스레드가 모든 락을 취득할 때까지 락 처리를 반복한다.

이 폴리시에 의해서, 테이블의 락으로 데드 록의 발생이 회피됩니다.다만, 이 schema에 관해서는 주의해야 할 점이 그 밖에도 있습니다.

MySQL 그리고 테이블에 대해서 LOW_PRIORITY WRITE 락을 사용했을 경우, 그 스레드는 READ 락을 요구하는 다른 스레드가 없어질 때까지 만 대기해,READ (을)를 요구하는 다른 스레드가 없어진 시점에서 락을 취득합니다.그 스레드로 WRITE 락을 취득한 후에, 락 테이블 리스트의 다음의 테이블의 락을 취득하려고 대기하고 있을 때는, 다른 스레드가 모두 WRITE 락이 해제될 때까지 기다리게 됩니다.이것에 의해서 어플리케이션으로 심각한 문제가 발생하는 경우는, 일부의 테이블을 트랜잭션(transaction) 세이프 테이블로 변환하는 것을 검토해 주세요.

테이블의 락을 취득하려고 대기하고 있는 스레드를, 안전한 방법으로 강제 종료하려면 ,KILL (을)를 사용합니다. See 항4.6.7. 「KILL 구문」 .

주의: INSERT DELAYED 그리고 사용하고 있는 테이블은, 락 해야 하는 것은 없습니다 .왜냐하면, 이 경우,INSERT 하지만 독립한 스레드로 실행되기 (위해)때문입니다.

개개의 UPDATE 스테이트먼트에서는, 모두 처리가 원자적으로 행해지기 위해, 통상, 테이블을 잠글 필요는 없습니다.현재 실행중의 SQL 스테이트먼트가, 다른 스레드에 의해서 방해되는 것은 전혀 없습니다.그러나, 다음에 나타내도록(듯이), 테이블을 잠글 필요가 생기는 경우도 몇개인가 있습니다.

  • 일련의 테이블에 대해서 많은 조작을 실행하는 경우, 사용하는 테이블을 잠그는 것이 처리가 아득하게 신속히 된다.당연히, 이 경우의 단점은,READ 락 되고 있는 테이블에 대해서는, 어느 스레드도(락을 보유하고 있는 스레드도 포함한다) 이 테이블을 갱신할 수 없게 되어,WRITE 락 되고 있는 테이블에 대해서는, 락을 보유하고 있는 스레드 이외, 어느 스레드도 이 테이블을 읽어낼 수 없게 되는 것이다.

    LOCK TABLES 의 사용시에 몇개의 면에서 처리가 신속히 되는 이유는,MySQL 그리고 키의 캐쉬가 UNLOCK TABLES 하지만 불려 갈 때까지 플래시 되지 않기 때문이다(통상, 키의 캐쉬는 각 SQL 스테이트먼트의 뒤에 플래시 된다).거기에 따르고,MyISAM 테이블에 대한 삽입, 갱신, 삭제 처리가 신속화된다.

  • 트랜잭션(transaction)를 서포트하고 있지 않는 스토리지 엔진을 MySQL 그리고 사용하고 있는 경우,SELECT (와)과 UPDATE 의 사이에 다른 스레드에 끼어들어지지 않게 하려면 ,LOCK TABLES (을)를 사용할 필요가 있다.다음의 예에서는, 안전하게 처리를 실행하기 위해서 LOCK TABLES (을)를 발행할 필요가 있다.

    mysql> LOCK TABLES trans READ, customer WRITE;
mysql> SELECT SUM(value) FROM trans WHERE customer_id=some_id;
mysql> UPDATE customer SET total_value=sum_from_previous_statement
    ->        WHERE customer_id=some_id;
mysql> UNLOCK TABLES;

    LOCK TABLES (을)를 발행하지 않으면SELECT 스테이트먼트와 UPDATE 스테이트먼트의 실행동안에 다른 스레드가 trans 테이블에 새로운 레코드를 삽입해 버릴 가능성이 있다.

많은 경우, 자신의 가산을 실시하는 갱신(UPDATE customer SET value=value+new_value )(이)나 LAST_INSERT_ID() 함수의 사용에 의해,LOCK TABLES 의 사용을 피할 수 있습니다.

또, 유저 레벨의 락 함수 GET_LOCK() (와)과 RELEASE_LOCK() (을)를 사용해 문제를 해결할 수 있는 경우도 있습니다.이러한 락은 서버의 해시 테이블에 보존되어 고속으로 하기 위한(해) pthread_mutex_lock() (와)과 pthread_mutex_unlock() 그리고 실장됩니다. See 항6.3.6.2. 「그 외의 각종 함수」 .

락 폴리시의 상세한 것에 대하여는, 항5.3.1. 「MySQL 의 테이블 락 방법」 (을)를 참조해 주세요.

전데이타베이스의 전테이블을 읽어내 락으로 잠그려면 ,FLUSH TABLES WITH READ LOCK 커멘드를 사용합니다.See 항4.6.4. 「FLUSH 구문」 .특정의 시점의 snapshot를 취할 수 있는,Veritas 등의 파일 시스템을 사용하고 있는 경우에는, 이 커멘드가 백업을 작성할 경우에 매우 도움이 됩니다.

주의: LOCK TABLES (은)는 트랜잭션(transaction) 세이프가 아닙니다.액티브한 트랜잭션(transaction)는, 테이블 락의 시행전에 암묵적으로 코?~ 트 됩니다.

6.7.6. SET TRANSACTION 구문

SET [GLOBAL | SESSION] TRANSACTION ISOLATION LEVEL
{ READ UNCOMMITTED | READ COMMITTED | REPEATABLE READ | SERIALIZABLE }

이 구문에서는, 트랜잭션(transaction)의 분리 레벨이, 글로벌인 세션 전체 또는 다음의 트랜잭션(transaction)의 어느 쪽일까하고 해 설정됩니다.

디폴트의 동작에서는, 다음의( 아직 개시되어 있지 않다) 트랜잭션(transaction)의 분리 레벨이 설정됩니다.이 스테이트먼트에 GLOBAL 키워드를 사용하면, 그것이?~ 에 작성되는 모든 새로운 접속(기존의 접속은 대상외)에 대해서 글로벌하게 디폴트의 트랜잭션(transaction) 레벨이 설정됩니다. 이것을 실시하려면 ,SUPER 권한이 필요합니다.SESSION 키워드를 사용하면, 현재의 접속으로 실행되는 모든 새로운 트랜잭션(transaction)에 대해서 디폴트의 트랜잭션(transaction) 레벨이 설정됩니다.

InnoDB 트랜잭션(transaction)의 각 분리 레벨에 대해서는, 항7.5.9.1. 「InnoDB (와)과 SET ... TRANSACTION ISOLATION LEVEL ... 」 (을)를 참조해 주세요.MySQL 4.0.5 이?~ ,InnoDB 그럼 이러한 각 레벨을 서포트하고 있습니다.디폴트의 레벨은 REPEATABLE READ 입니다.

mysqld 의 디폴트의 글로벌 분리 레벨은,--transaction-isolation=... 그리고 설정할 수 있습니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .


6.8. MySQL 풀텍스트 검색

MATCH (col1,col2,...) AGAINST (expr [IN BOOLEAN MODE | WITH QUERY EXPANSION] )

버젼 3.23.23 이?~ ,MySQL 그럼 풀 텍스트 인덱스와 풀텍스트 검색을 서포트하고 있습니다. MySQL 의 풀 텍스트 인덱스는 FULLTEXT 형태의 인덱스입니다. FULLTEXT 인덱스는 MyISAM 테이블에게만 사용되어CHAR 형태,VARCHAR 형태,TEXT 형태의 몇개의 컬럼으로부터 작성할 수 있습니다.이 작성은 CREATE TABLE 시간에 실시할 수 있습니다만,ALTER TABLE 인가 CREATE INDEX (을)를 사용해 나중에 추가하는 것도 가능합니다.데이터 세트의 사이즈가 큰 경우는,FULLTEXT 인덱스를 가지지 않는 테이블에 데이터를 로드하고 나서,ALTER TABLE (또는 CREATE INDEX )(을)를 사용해 인덱스를 작성하는 것이 처리가 훨씬 신속합니다.벌써 FULLTEXT 인덱스를 가지고 있는 테이블에 데이터를 로드하면, 처리가 꽤 늦어지는 일이 있습니다.

풀텍스트 검색을 실행하려면 ,MATCH() 함수를 사용합니다.

mysql> CREATE TABLE articles (
    ->   id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
    ->   title VARCHAR(200),
    ->   body TEXT,
    ->   FULLTEXT (title,body)
    -> );
Query OK, 0 rows affected (0.00 sec)

mysql> INSERT INTO articles VALUES
    -> (NULL,'MySQL Tutorial', 'DBMS stands for DataBase ...'),
    -> (NULL,'How To Use MySQL Efficiently', 'After you went through a ...'),
    -> (NULL,'Optimizing MySQL','In this tutorial we will show ...'),
    -> (NULL,'1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
    -> (NULL,'MySQL vs. YourSQL', 'In the following database comparison ...'),
    -> (NULL,'MySQL Security', 'When configured properly, MySQL ...');
Query OK, 6 rows affected (0.00 sec)
Records: 6  Duplicates: 0  Warnings: 0

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 ...             |
+----+-------------------+------------------------------------------+
2 rows in set (0.00 sec)

MATCH() 함수에서는, 텍스트의 콜렉션(FULLTEXT 인덱스에 포함된다 1 개이상의 컬럼세트)에 대해서, 문자열의 자연 언어 검색이 실행됩니다.검색 문자열은 AGAINST() 의 인수로서 지정합니다.검색은 케이스비의존 방식으로 실행됩니다. MATCH() 에서는, 테이블의 각 레코드에 대해서, 관련성을 나타내는 값(즉, 검색 문자열과 그 레코드의 MATCH() 리스트로 지정한 컬럼의 텍스트와의 사이의 유사도)가 돌려주어집니다.

MATCH() (을)를 WHERE 마디로 사용하면(위의 예를 참조), 돌려주어지는 레코드는 관련성이 가장 높은 레코드로부터 낮은 레코드의 순서에 자동으로 소트 됩니다. 관련성을 나타내는 값은 부의 수가 아닌 부동 소수점수(실수)입니다.관련성이 제로 때는, 유사성이 전혀 없는 것을 의미합니다.관련성은, 레코드에 포함되는 워드수, 그 레코드에 포함되는 일의의 워드수, 콜렉션에 포함되는 합계 워드수, 특정의 워드를 포함한 문서(레코드) 수에 근거해 계산됩니다.

불리언 값 모드의 검색도 실행할 수 있습니다.이것에 대해서는 후술 합니다.

상기의 예는,MATCH() 함수의 기본적인 사용 방법을 나타낸 것입니다.레코드는 관련성이 높은 것으로부터 낮은 순서에 돌려주어집니다.

다음의 예는, 관련치를 명시적으로 꺼내는 방법을 나타낸 것입니다. WHERE 마디도 ORDER BY 마디도 없기 때문에, 돌려주어지는 레코드는 순서 붙일 수 있고 있지 않습니다.

mysql> SELECT id,MATCH (title,body) AGAINST ('Tutorial') FROM articles;
+----+-----------------------------------------+
| id | MATCH (title,body) AGAINST ('Tutorial') |
+----+-----------------------------------------+
|  1 |                        0.64840710366884 |
|  2 |                                       0 |
|  3 |                        0.66266459031789 |
|  4 |                                       0 |
|  5 |                                       0 |
|  6 |                                       0 |
+----+-----------------------------------------+
6 rows in set (0.00 sec)

다음의 예는 보다 복잡합니다.이 쿼리에서는, 관련성이 돌려주어져 관련성의 높은 것으로부터 낮은 순서에 레코드가 소트 됩니다.이 결과를 출력하기 위해서는,MATCH() (을)를 2 회지정합니다.거기에 따라 추가의 오버헤드가 발생할 것은 없습니다.왜냐하면,MySQL 의 Optimizer는 2 개의 MATCH() 호출이 같은 것이다고 인식해, 풀텍스트 검색 코드를 1 번 밖에 기동하지 않기 때문입니다.

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           |
+----+-------------------------------------+-----------------+
|  4 | 1. Never run mysqld as root. 2. ... | 1.5055546709332 |
|  6 | When configured properly, MySQL ... |   1.31140957288 |
+----+-------------------------------------+-----------------+
2 rows in set (0.00 sec)

버젼 4.1.1 이?~ , 풀텍스트 검색에서는 쿼리의 확장(특히, 그 이형의 `` 블라인드 쿼리 확장'' )(을)를 서포트하고 있습니다.통상, 이것은, 검색 어구가 너무 짧을 때 도움이 됩니다.검색 어구가 짧은 경우, 그 어구를 지정한 유저가 암묵적인 지식에 의지하고 있는 일이 자주 있습니다.암묵적인 지식이라고 한 것은, 통상, 풀텍스트 검색 엔진은 갖추고 있지 않습니다.예를 들어, 유저가 `` 데이타베이스'' 그렇다고 하는 어구를 검색하고 있는 경우, 실제로는 그 유저는, 단지 `` 데이타베이스'' 뿐만이 아니고,``MySQL'' ,``Oracle'' ,``DB2'' ,``RDBMS'' 그렇다고 하는 어구도 모두 `` 데이타베이스'' 에 일치해, 돌려주어질 것이라면 상정하고 있는 일이 있습니다.암묵적인 지식이란, 이러한 일을 의미합니다.

블라인드 쿼리 확장(자동 관련성 피드백)에서는, 검색이 2 회실행됩니다.2 번째의 검색의 검색 어구에는, 원의 검색 어구에, 최초의 검색으로 상위에 검출된 소수의 문서를 연결시킬 수 있던 것이 사용됩니다.따라서, 예를 들어, 이러한 문서의 1 개에 `` 데이타베이스'' 그렇다고 하는 말과 ``MySQL'' 그렇다고 하는 말이 포함되어 있는 경우,2 번째의 검색에서는,``MySQL'' 그렇다고 하는 말을 포함해,`` 데이타베이스'' 그렇다고 하는 말은 포함하지 않는 문서가 검색됩니다.또, 예를 들어,Georges Simenon 의 저서로 ``Maigret'' 경시에 관한 책을 검색하려고 할 때,``Maigret'' 의 스펠이 정확하게 모른다고 합니다.이 경우,``Megre and the reluctant witnesses'' (을)를 검색 어구로서 지정하면, 쿼리의 확장을 사용하지 않으면 ``Maigret and the Reluctant Witnesses'' 밖에 검출되지 않습니다.그러나, 쿼리의 확장을 사용하면,2 번째의 검색으로 ``Maigret'' 그렇다고 하는 말이 포함되는 모든 책이 검출됩니다.주의: 블라인드 쿼리 확장에서는, 관련하지 않는 문서가 돌려주어지는 것으로 노이즈가 큰폭으로 증가하기 쉽상입니다.그 때문에, 이 기능을 사용하는 의미가 있는 것은, 검색 어구가 비교적 짧은 경우에 한정됩니다.

MySQL 그럼, 매우 단순한 파서를 사용해 텍스트를 워드(말)에 분할합니다.`` 워드'' (이)란, 문자, 숫자,‘' ＇,‘_ ＇ (으)로 구성되는 문자열입니다.스톱 워드 리스트에 포함된다 `` 워드'' (이)나 너무 짧은 것은 무시됩니다.풀텍스트 검색으로 검출되는 워드의 디폴트의 최소장은 4 문자입니다.이 길이는 항6.8.2. 「MySQL 풀텍스트 검색의 조정」 의 설명에 따라서 변경 가능합니다.

콜렉션 및 쿼리에 포함되는 올바른 각 워드에는, 그 쿼리 또는 콜렉션으로의 그 워드의 중요도에 근거해 중량감이 설정됩니다.그 때문에, 많은 문서에 존재하는 워드는 낮고 중요 됩니다(중량감이 제로의 경우도 있습니다).왜냐하면, 그 워드는 그 콜렉션에 대해 의미치가 낮기 때문입니다.그 워드가 보기 드물게 밖에 존재하지 않는 경우는, 높고 중요 됩니다.그 후, 각 워드의 중량감이 결합되어 레코드의 관련성이 계산됩니다.

이러한 테크닉은, 사이즈의 큰 콜렉션의 경우에 가장 효과가 있습니다(실제로, 그것을 목적으로 해 꼼꼼하게 조정되고 있습니다).작은 테이블에서는, 워드의 분포는 각각의 의미치를 올바르게 반영하는 것은 되지 않고, 이 모델을 사용했을 경우, 기묘한 결과가 나오는 일이 있습니다.

mysql> SELECT * FROM articles WHERE MATCH (title,body) AGAINST ('MySQL');
Empty set (0.00 sec)

위의 예에서는,MySQL 그렇다고 하는 워드의 검색으로 아무것도 결과가 생성되지 않습니다.이것은, 이 워드가 반이상의 레코드에 존재하기 (위해)때문입니다.따라서, 이 워드는 사실상 스톱 워드(의미치가 제로의 워드)로서 다루어집니다.이것은 가장 바람직한 동작입니다.자연 언어의 쿼리의 경우 ,1 GB 의 테이블에서 1 개 간격으로 레코드가 돌려주어지는 것은 적절하지는 않습니다.

워드가 테이블의 반을 차지하는 레코드에 일치하는 경우, 관련하는 문서가 검출될 전망은 별로 없습니다.오히려, 무관계의 문서가 대량으로 검출될 가능성이 적지 않이 있습니다. 이것은, 검색 엔진을 사용해 인터넷으로 검색을 할 경우에 누구나가 빈번히 경험하는 것입니다.이러한 레코드에 해당의 데이터 세트에 대해 낮은 의미치가 설정되어 있는 이유는, 여기에 있습니다.

버젼 4.0.1 이?~ ,MySQL 그럼,IN BOOLEAN MODE 수식자를 사용해 불리언 값의 풀텍스트 검색도 실행할 수 있습니다.

mysql> SELECT * FROM articles WHERE MATCH (title,body)
    ->     AGAINST ('+MySQL -YourSQL' IN BOOLEAN MODE);
+----+------------------------------+-------------------------------------+
| id | title                        | body                                |
+----+------------------------------+-------------------------------------+
|  1 | MySQL Tutorial               | DBMS stands for DataBase ...        |
|  2 | How To Use MySQL Efficiently | After you went through a ...        |
|  3 | Optimizing MySQL             | In this tutorial we will show ...   |
|  4 | 1001 MySQL Tricks            | 1. Never run mysqld as root. 2. ... |
|  6 | MySQL Security               | When configured properly, MySQL ... |
+----+------------------------------+-------------------------------------+

이 쿼리에서는,MySQL 그렇다고 하는 워드를 포함해(주의: 50% 의 해 귀의치는 사용되지 않습니다),YourSQL 그렇다고 하는 워드는 포함하지 않는다 모든 레코드가 꺼내집니다.주의: 불리언 값 모드의 검색에서는, 관련치의 높은 것 순서의 레코드의 자동 소트는 행해지지 않습니다.이것은 위의 쿼리의 결과를 본다고 압니다.위의 쿼리에서는, 관련성이 가장 높은 레코드(MySQL 그렇다고 하는 워드를 2 개 포함한 레코드)가 최초로는 없고 마지막에 리스트 되고 있습니다.또, 불리언 값의 풀텍스트 검색은 FULLTEXT 인덱스가 없어도 기능합니다.다만, 이 경우, 처리 속도는 늦고 됩니다.

불리언 값의 풀텍스트 검색 기능에서는, 다음의 연산자를 서포트하고 있습니다.

  • +

    선행하는 플러스 기호는, 돌려주어지는 각 레코드에 그 워드가 존재해야 한다 일을 나타낸다.

  • -

    선행하는 마이너스 기호는, 돌려주어지는 각 레코드에 그 워드가 존재해서는 안 된다 일을 나타낸다.

  • 디폴트(플러스도 마이너스도 지정하지 않는 경우)에서는, 그 워드는 반드시 존재할 필요는 없지만, 그 워드를 포함한 레코드는 높게 평가된다.이것은,IN BOOLEAN MODE 수식자를 지정하고 있지 않다 MATCH() ... AGAINST() 의 동작에 유사한다.

  • < >

    이것들 2 개의 연산자는, 각 레코드에 할당할 수 있는 관련성의 값에 대한 개개의 워드의 공헌도를 변경하기 위해서 사용된다.< 연산자는 공헌도를 감소시켜,> 연산자는 공헌도를 증가시킨다. 아래의 예를 참조.

  • ( )

    외모는, 워드를 부차식에 그룹화 하기 위해서 사용된다.

  • ~

    선행하는 치르다는 부정 연산자로서 기능해, 레코드의 관련성에 대한 워드의 공헌도를 마이너스로 한다.이것은 노이즈 워드를 마크 하는데 도움이 된다.이러한 워드를 포함한 레코드는, 다른 워드보다 낮게 평가되지만,- 연산자를 사용했을 때와 같이 완전하게 제외되는 것은 아니다.

  • *

    asterisk는 잘라서 버림 연산자.다른 연산자와 달리, 이것은 워드의 전은 아니고 뒤 에 붙인다.

  • "

    이중 인용부호 " 그리고 둘러싼 어구는, 이 어구와 완전히 같다 어구를 포함한 레코드에게만 일치한다.

다음에, 예를 몇개인가 나타내 보입니다.

  • apple banana

    이러한 워드의 최저 1 개를 포함한 레코드가 검색된다.

  • +apple +juice

    ... 양쪽 모두의 워드를 포함한 레코드를 검색.

  • +apple macintosh

    ... 워드 ``apple'' (을)를 포함한 레코드를 검색.``apple'' 에 가세해 ``macintosh'' 그렇다고 하는 워드도 포함하고 있으면, 높게 평가된다.

  • +apple -macintosh

    ... 워드 ``apple'' (을)를 포함해,``macintosh'' (은)는 포함하지 않는 레코드를 검색.

  • +apple +(>turnover <strudel)

    ... ``apple'' (와)과 ``turnover'' , 또는 ``apple'' (와)과 ``strudel'' (을)를 포함한 레코드(2 개의 워드의 순서는 묻지 않는다)를 검색.다만,``apple pie'' 하 ``apple strudel'' 보다 높게 평가된다.

  • apple*

    ... ``apple'' ,``apples'' ,``applesauce'' ,``applet'' (은)는 모두 이것과 일치한다.

  • "some words"

    ... ``some words of wisdom'' (와)과는 일치하지만,``some noise words'' (와)과는 일치하지 않는다.

6.8.1. 풀텍스트 검색에 있어서의 제약

  • 풀텍스트 검색은 MyISAM 테이블에서만 가능.

  • 풀텍스트 검색은 UCS-2 그럼 사용할 수 없다(그러나,MySQL 4.1.1 이?~ 그럼,UTF-8 그리고 기능한다).

  • MATCH() 함수의 파라미터는 모두, 같다 FULLTEXT 인덱스의 일부를 이루는 같은 테이블의 컬럼이 아니면 안된다(IN BOOLEAN MODE 그리고 MATCH() (을)를 실행하는 경우를 제외하다).

  • FULLTEXT 인덱스의 컬럼은 모두 같은 캐릭터 세트를 사용하고 있지 않으면 안 된다.

  • MATCH() 의 컬럼 리스트는 테이블의 일부의 FULLTEXT 인덱스 정의의 컬럼 리스트와 정확하게 일치하고 있지 않으면 안 된다(IN BOOLEAN MODE 그리고 MATCH() (을)를 실행하는 경우를 제외하다).

  • AGAINST() 의 인수는 정수 문자열이 아니면 안된다.

6.8.2. MySQL 풀텍스트 검색의 조정

유감스럽지만, 유저에 의한 조정이 가능한 풀텍스트 검색의 파라미터는 현재로서는 조금 밖에 없습니다.그러나, 조정 가능한 파라미터의 추가는,TODO 리스트에 대해 우선도의 높은 위치에 랭크 되고 있습니다.MySQL 소스 디스트리뷰션(see 항2.3. 「MySQL 소스 디스트리뷰션의 인스톨」 )(이)가 있는 경우는, 풀텍스트 검색의 동작을 보다 상세하게 제어할 수 있습니다.

주의: 풀텍스트 검색은 검색의 효율을 잘 하도록(듯이) 꼼꼼하게 조정되고 있습니다.디폴트의 동작을 변경하면, 많은 경우, 결과적으로 검색 결과가 나빠집니다.MySQL 의 소스는, 충분한 지식이 없는 한 변경하지 말아 주세요.

이하에 설명하는 풀 텍스트 변수는, 서버의 기동시로 설정되어 있지 않으면 안됩니다.서버의 가동중에 이러한 변수를 동적으로 변경할 수 없습니다.

  • 인덱스를 작성하는 워드의 최소장은,MySQL 변수 ft_min_word_len 그리고 정의된다. See 항4.6.8.4. 「SHOW VARIABLES 」 . (이 변수는 MySQL 버젼 4.0 이?~ 에서만 사용할 수 있다). 디폴트치는 4 문자. 이 값을 필요한 값으로 변경하고,FULLTEXT 인덱스를 재빌드 한다. 예를 들어,3 문자의 워드를 검색 가능하게 하려면 , 옵션 파일에 이하의 행을 쓰는 것에 의해서 이 변수를 설정한다.

    [mysqld]
ft_min_word_len=3

    그 후, 서버를 재기동하고,FULLTEXT 인덱스를 재빌드 한다.

  • 스톱 워드 리스트는,ft_stopword_file 변수로 지정한 파일로부터 로드할 수 있다. See 항4.6.8.4. 「SHOW VARIABLES 」 . 스톱 워드 리스트를 변경한 후,FULLTEXT 인덱스를 재빌드 한다(이 변수는 MySQL 버젼 4.0.10 이?~ 에서만 사용할 수 있다).

  • 50% 의 해 귀의치는, 선택되고 있는 특정의 중요 설정으로 결정되어 있다. 이것을 무효로 하려면 ,myisam/ftdefs.h 의 다음의 행을 변경한다.

    #define GWS_IN_USE GWS_PROB

    다음과 같이 변경한다.

    #define GWS_IN_USE GWS_FREQ

    그 후,MySQL (을)를 재컴파일 한다. 이 경우, 인덱스를 재빌드 할 필요는 없다. 주의: 이 설정에 의해서,MATCH() 함수로 적절한 관련성을 나타내는 값을 얻을 수 있도록(듯이) 한다 MySQL 의 기능이 큰폭으로 약해진다. 실제로 이러한 일반적인 말을 검색할 필요가 있는 경우는, 오히려,IN BOOLEAN MODE (을)를 사용하고 검색을 실시하는 편이 좋다.이 경우,50% 의 해 귀의치가 고려되지 않는다.

  • 검색 엔진의 관리자가, 불리언 값의 풀 텍스트 검색에 사용하는 연산자를 변경하고 싶어지기도 한다.이러한 연산자는 ft_boolean_syntax 변수로 정의된다. See 항4.6.8.4. 「SHOW VARIABLES 」 . 그러나, 이 변수는 읽어내 전용이며, 값은 myisam/ft_static.c (으)로 설정되어 있다.

FULLTEXT 인덱스의 재구축이 필요하게 되는 풀 텍스트 관련의 변경의 경우,MyISAM 테이블에 대해서 이것을 실시하는 가장 간단한 방법은, 인덱스 파일을 재빌드 하는 다음의 스테이트먼트를 사용하는 것입니다.

mysql> REPAIR TABLE tbl_name QUICK;

6.8.3. 풀텍스트 검색에 관련한다 TODO 항목

  • FULLTEXT 인덱스를 사용하는 모든 조작의 신속화 .

  • 근접 연산자.

  • " 항상 인덱스 워드" 의 서포트.이것은,"C++" ,"AS/400" ,"TCP/IP" 등, 유저가 워드로서 인식시키고 싶은 임의의 문자열이다.

  • MERGE 테이블로의 풀텍스트 검색의 서포트.

  • UCS-2 의 서포트.

  • 스톱 워드 리스트를 데이터의 언어에 의존시킨다.

  • 스테?~ 그(= 어간의 추출.말할 필요도 없이, 데이터의 언어에 의존하는 추출).

  • 유저에 의한 제공이 가능한 범용 UDF 프리파사.

  • 모델의 것보다 한층 더의 유연화(CREATE/ALTER TABLE 의 FULLTEXT 에 조정 가능한 파라미터를 몇개인가 추가한다).


6.9. MySQL 쿼리 캐쉬

버젼 4.0.1 이?~ ,MySQL 서버 에는 Query Cache 기능이 있습니다. 쿼리 캐쉬의 사용시, 이 캐쉬에는,SELECT 쿼리의 텍스트와 클라이언트에 보내진 그 결과가 격납됩니다. 다음에 완전히 같은 쿼리를 받으면, 서버는 그 쿼리의 해석과 실행을 한번 더 반복하는 대신에, 쿼리 캐쉬로부터 결과를 꺼냅니다.

주의: 쿼리 캐쉬로부터 낡은 데이터가 돌려주어질 것은 없습니다.데이터가 변경되면, 쿼리 캐쉬의 관련하는 엔트리가 모두 플래시 됩니다.

(일부의) 테이블이 그만큼 빈번히는 변경되지 않고, 같은 쿼리가 몇번이나 실행되는 환경에서는, 쿼리 캐쉬가 매우 도움이 됩니다. 동적 컨텐츠를 대량으로 가지는 많은 Web 서버에서는, 이러한 상황이 일반적입니다.

쿼리 캐쉬의 퍼포먼스에 관한 데이터의 일부를, 이하에 나타냅니다(이러한 결과는,2 GB 의 RAM ,64 MB 의 쿼리 캐쉬를 탑재한다 Linux Alpha 2 x 500 MHz (으)로의 MySQL 벤치마크스트의 실행에 의해 생성된 것입니다)：

  • 실행하고 있는 쿼리가 모두 단순한 것(레코드가 1 개 밖에 없는 테이블에서 레코드를 1 개선택하는 등)면서 서로 다르기 위해서, 쿼리를 캐쉬할 수 없는 경우, 쿼리 캐쉬를 액티브하게 해 두는 것에 의한 오버헤드는 13% . 이것은 최악의 경우의 시나리오로 간주할 수 있다.현실에는, 쿼리는 이 예보다 훨씬 복잡하기 때문에, 통상 오버헤드는 꽤 낮아진다.

  • 레코드가 1 개만의 테이블로의 1 개의 레코드의 검색은 238% 신속화된다. 이것은, 캐쉬에 격납되고 있는 쿼리로 상정되는 신속화의 최소치에 가까운 수치이다.

  • 쿼리 캐쉬의 코드를 무효로 하려면 ,query_cache_size=0 (으)로서 설정한다. 쿼리 캐쉬 코드를 무효로 하면, 눈에 띈 오버헤드는 없어진다(쿼리 캐쉬는, 콘피개오프션 --without-query-cache (을)를 사용해 코드로부터 제외할 수 있다).

6.9.1. 쿼리 캐쉬의 동작

쿼리는 해석전에 비교되기 위해,

SELECT * FROM tbl_name

(와)과

Select * from tbl_name

(은)는, 쿼리 캐쉬로 다른 쿼리로 간주해집니다.완전하게 일치하는( 각 바이트가) 쿼리 이외, 동일하다고는 보이지 않습니다. 또, 예를 들어, 어느 클라이언트로 새로운 형식의 통신 프로토콜을 사용하고 있는 경우나, 다른 클라이언트가 사용하고 있는 것과는 다른 캐릭터 세트를 사용하고 있는 경우도, 같은 것이어야할 쿼리가 다른 것으로서 인식되는 일이 있습니다.

다른 데이타베이스를 사용하는 쿼리나, 사용 프로토콜의 버젼이 다른 쿼리, 또 디폴트의 캐릭터 세트가 다른 쿼리는, 모두 다른 쿼리로서 인식되어 따로 따로 캐쉬됩니다.

캐쉬는 SELECT SQL_CALC_FOUND_ROWS ... 및 SELECT FOUND_ROWS() ... 형태의 쿼리에서도 기능합니다.이것은, 검출된 레코드의 수도 캐쉬에 격납되기 (위해)때문입니다.

쿼리의 결과가 쿼리 캐쉬로부터 돌려주어졌을 경우, 스테이터스 변수 Com_select 의 값은 증가하지 않습니다만,Qcache_hits 의 값은 증가합니다. See 항6.9.4. 「쿼리 캐쉬의 스테이터스와 보수」 .

테이블이 변경되면(INSERT ,UPDATE ,DELETE ,TRUNCATE ,ALTER ,DROP TABLE|DATABASE 의 어느 쪽인가에 따르고), 그 테이블을(경우에 따라서는,MRG_MyISAM 테이블을 통해) 사용한 캐쉬내의 쿼리는 모두 무효가 되어, 캐쉬로부터 삭제됩니다.

변경되었다 InnoDB 트랜잭션(transaction) 테이블은,COMMIT 하지만 실행되면 무효화됩니다.

MySQL 4.0 그럼, 쿼리 캐쉬는 트랜잭션(transaction)내에서는 무효입니다(결과는 돌려주어지지 않습니다).MySQL 4.1.1 이?~ 그럼,InnoDB 테이블의 사용시, 쿼리 캐쉬는 트랜잭션(transaction)내에서도 기능합니다(테이블의 버젼 번호에 근거하고, 데이터가 아직 경향인지 어떤지가 검출됩니다).

MySQL 5.0 보다 전의 버젼에서는, 선행하는 코멘트로 시작되는 쿼리의 경우, 캐쉬에의 격납은 가능해도, 캐쉬로부터 취득할 수 없었습니다.이 문제는 MySQL 5.0 그리고 수정되고 있습니다.

다음의 함수의 어느쪽이든을 포함하고 있는 쿼리는, 캐쉬할 수 없습니다.

함수 | 함수 | 함수
User-Defined Functions | CONNECTION_ID | FOUND_ROWS
GET_LOCK | RELEASE_LOCK | LOAD_FILE
MASTER_POS_WAIT | NOW | SYSDATE
CURRENT_TIMESTAMP | CURDATE | CURRENT_DATE
CURTIME | CURRENT_TIME | DATABASE
ENCRYPT ( 파라미터를 1 개 가지는 것) | LAST_INSERT_ID | RAND
UNIX_TIMESTAMP ( 파라미터 없음) | USER | BENCHMARK

또, 유저 변수를 포함하고 있는 쿼리,mysql 시스템 데이타베이스를 참조하고 있는 쿼리,SELECT ... IN SHARE MODE ,SELECT ... INTO OUTFILE ... ,SELECT ... INTO DUMPFILE ... 의 몇개의 형식의 쿼리, 및 SELECT * FROM AUTOINCREMENT_FIELD IS NULL 형식의 쿼리(마지막에 삽입되었다 ID 의 꺼내 - ODBC 회피책)에 대해서도, 캐쉬할 수 없습니다.

다만,FOUND_ROWS() (은)는, 선행하는 쿼리가 캐쉬로부터 페치 된 것이어도 올바른 값을 돌려줍니다.

쿼리로 테이블을 아무것도 사용하지 않는, 또는 텐포라리테이불을 사용하는 경우나, 관련하는 테이블의 어느 쪽인가에 대하는 컬럼의 액세스권한을 유저가 가지고 있지 않은 경우, 쿼리는 캐쉬되지 않습니다.

MySQL 그럼, 쿼리를 쿼리 캐쉬로부터 읽어내기 전에, 관련하는 모든 데이타베이스와 테이블에 대한다 SELECT 권한을 유저가 가지고 있는지 체크합니다.이 권한을 유저가 가지고 있지 않은 경우, 캐쉬에 격납되고 있는 결과는 사용되지 않습니다.

6.9.2. 쿼리 캐쉬의 설정

mysqld 의 기동시에는, 커멘드 라인으로 mysqld 의 소수의 MySQL 시스템 변수가 쿼리 캐쉬에 의해 추가됩니다.이러한 시스템 변수는 옵션 설정 파일로 설정할 수 있습니다.

  • query_cache_limit 이것보다 큰 결과는 캐쉬하지 않는다(디폴트 1M ).

  • query_cache_min_res_unit

    이 변수는 버젼 4.1 이?~ 그리고 이용할 수 있다.

    쿼리의 결과(클라이언트에도 보내지는 데이터)는 결과의 꺼내 때에 쿼리 캐쉬에 격납된다.따라서, 통상, 데이터는 1 개의 큰 정리로서 처리되는 것은 아니다.쿼리 캐쉬에서는, 데이터를 격납하는 블록이 요구에 따라 할당할 수 있다.1 개의 블록이 가득 차면, 새로운 블록을 할당할 수 있다. 메모리 할당 처리는 코스트가 비싼(시간적으로) 모아 두어 쿼리 캐쉬로의 블록의 할당은,query_cache_min_res_unit (으)로 지정된 최소 사이즈로 행해진다. 쿼리가 실행되면, 마지막 결과 블록은 실제의 데이터 사이즈에 잘라 버릴 수 있어 사용하고 있지 않는 메모리가 해방된다.

    • query_cache_min_res_unit 의 디폴트치는 4 KB .대부분의 경우, 이것으로 충분하다.

    • 결과가 작은 쿼리가 많이 있는 경우는, 디폴트의 블록 사이즈를 사용하면 메모리가 fragment화하는 일이 있다(이것은 비어 블록(Qcache_free_blocks )의 수가 많아지는 것으로 안다.후랑먼트화하면, 메모리 부족에 따라 캐쉬로부터 쿼리가 삭제된다(Qcache_lowmem_prunes ) 일이 있다).그 경우는,query_cache_min_res_unit 의 값을 작게 한다.

    • 결과가 큰 쿼리가 대부분을 차지하는 경우는(Qcache_total_blocks 및 Qcache_queries_in_cache (을)를 참조),query_cache_min_res_unit 의 값을 크게 하는 것에 의해서, 퍼포먼스를 잘 할 수 있다.다만, 너무 너무 크게 하지 않게 주의하는 것(상기를 참조).

  • query_cache_size 이전의 쿼리의 결과를 격납하기 위해서 할당하는 메모리량(아르바이트 단위로 지정).이 값을 0 (으)로 하면, 쿼리 캐쉬는 무효(디폴트)가 된다.

  • query_cache_type 다음의 몇개의 값(수치만)을 설정할 수 있다.

    옵션 | 설명
    0 | (OFF - 캐쉬에의 격납, 결과의 취득을 모두 실시하지 않는다)
    1 | (ON .SELECT SQL_NO_CACHE ... 쿼리를 제외한 모든 결과를 캐쉬한다)
    2 | (DEMAND .SELECT SQL_CACHE ... 쿼리만 캐쉬한다)

쿼리 캐쉬의 동작은, 스레드(접속) 내에서 디폴트로부터 변경할 수 있습니다.구문은 다음과 같습니다.

QUERY_CACHE_TYPE = OFF | ON | DEMAND QUERY_CACHE_TYPE = 0 | 1 | 2

옵션 | 설명
0 또는 OFF | 캐쉬에의 격납, 결과의 취득을 모두 실시하지 않는다.
1 또는 ON | SELECT SQL_NO_CACHE ... 쿼리를 제외한 모든 결과를 캐쉬한다.
2 또는 DEMAND | SELECT SQL_CACHE ... 쿼리만 캐쉬한다.

6.9.3. SELECT (으)로의 쿼리 캐쉬 옵션

SELECT 쿼리에서는, 쿼리 캐쉬 관련의 다음의 2 개의 파라미터를 지정할 수 있습니다.

옵션 | 설명
SQL_CACHE | QUERY_CACHE_TYPE 하지만 DEMAND 의 경우, 쿼리를 캐쉬 가능하게 한다. QUERY_CACHE_TYPE 하지만 ON 의 경우, 이것이 디폴트. QUERY_CACHE_TYPE 하지만 OFF 의 경우, 아무것도 하지 않는다.
SQL_NO_CACHE | 이 쿼리를 캐쉬 불가로 한다.이 쿼리를 캐쉬에 격납하지 않는다.

6.9.4. 쿼리 캐쉬의 스테이터스와 보수

FLUSH QUERY CACHE 커멘드에서는, 쿼리 캐쉬를 데후라그먼트화하고, 메모리의 사용 효율을 잘 할 수 있습니다.이 커멘드를 발행해도, 캐쉬로부터 쿼리가 삭제될 것은 없습니다. FLUSH TABLES 그렇지만, 쿼리 캐쉬가 플래시 됩니다.

RESET QUERY CACHE 커멘드에서는, 모든 쿼리 결과가 쿼리 캐쉬로부터 삭제됩니다.

사용하고 있다 MySQL 버젼에 쿼리 캐쉬가 있을지 어떨지는, 다음의 커멘드로 확인할 수 있습니다.

mysql> SHOW VARIABLES LIKE 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+
1 row in set (0.00 sec)

쿼리 캐쉬의 퍼포먼스는,SHOW STATUS 그리고 감시할 수 있습니다.

변수 | 설명
Qcache_queries_in_cache | 캐쉬에 등록되어 있는 쿼리수
Qcache_inserts | 캐쉬에 추가된 쿼리수
Qcache_hits | 캐쉬 히트수
Qcache_lowmem_prunes | 메모리 부족을 위해서 캐쉬로부터 삭제된 쿼리수
Qcache_not_cached | 캐쉬되어 있지 않다(캐쉬 불가, 또는 QUERY_CACHE_TYPE 에 의해) 쿼리수
Qcache_free_memory | 쿼리 캐쉬의 빈메모리량
Qcache_free_blocks | 쿼리 캐쉬내의 빈메모리브록크수
Qcache_total_blocks | 쿼리 캐쉬내의 합계 블록수

합계 쿼리수 = Qcache_inserts + Qcache_hits + Qcache_not_cached

쿼리 캐쉬에서는 가변장 블록이 사용되기 위해,Qcache_total_blocks (와)과 Qcache_free_blocks 에 의해서, 쿼리 캐시 기억 장치의 fragment화가 나타나는 일이 있습니다. FLUSH QUERY CACHE (을)를 실행하면,1 개의(큰) 빈블록만이 남습니다.

주의: 각 쿼리에는, 최악이어도 2 블록 필요합니다(쿼리 텍스트용으로 1 블록, 쿼리 결과용으로 1 블록 이상).또, 쿼리로 사용되는 각 테이블용으로도 1 블록 필요합니다.다만, 복수의 쿼리로 같은 테이블을 사용하고 있는 경우는,1 블록의 할당으로 해결됩니다.

쿼리의 캐쉬 사이즈는,Qcache_lowmem_prunes 스테이터스 변수에 근거해 조정할 수 있습니다.이 값은, 새로운 쿼리를 격납할 수 있도록 메모리를 해방하기 위해서 캐쉬로부터 삭제된 쿼리수를 나타냅니다.쿼리 캐쉬에서는, 사용된 집 가장 낡다 (LRU ) 방침에 따라서, 캐쉬로부터 삭제하는 쿼리가 결정됩니다.


제7 장 MySQL 의 테이블형

목차

7.1. MyISAM 테이블
7.1.1. 키에 필요한 영역
7.1.2. MyISAM 테이블 형식
7.1.3. MyISAM 테이블의 문제
7.2. MERGE 테이블
7.2.1. MERGE 테이블의 문제
7.3. ISAM 테이블
7.4. HEAP 테이블
7.5. InnoDB 테이블
7.5.1. InnoDB 테이블의 개요
7.5.2. MySQL 버젼 3.23 (으)로의 InnoDB
7.5.3. InnoDB 기동 옵션
7.5.4. InnoDB 테이블 스페이스의 작성
7.5.5. InnoDB 테이블의 작성
7.5.6. InnoDB 데이터 파일과 로그 파일의 추가와 삭제
7.5.7. InnoDB 데이타베이스의 백업과 리커버리
7.5.8. InnoDB 데이타베이스를 다른 머신으로 이동한다
7.5.9. InnoDB 트랜잭션(transaction) 모델과 락
7.5.10. 퍼포먼스 튜닝의 힌트
7.5.11. 마르치바죠닝의 실장
7.5.12. 테이블과 인덱스의 구조
7.5.13. 파일 영역의 관리와 디스크 I/O
7.5.14. 에러 처리
7.5.15. InnoDB 테이블의 제한 사항
7.5.16. InnoDB 의 변경 이력
7.5.17. InnoDB 에 대한 문의처
7.6. BDB 또는 BerkeleyDB 테이블
7.6.1. BDB 테이블의 개요
7.6.2. BDB 의 인스톨
7.6.3. BDB 기동 옵션
7.6.4. BDB 테이블의 특성
7.6.5. 가까운 장래에 수정할 필요가 있다 BDB 의 문제
7.6.6. BDB 그리고 서포트되고 있는 operating system
7.6.7. BDB 테이블의 제한 사항
7.6.8. BDB 테이블을 사용할 경우에 일어날 수 있는 에러

MySQL 버젼 3.23.6 보다 ,3 종류의 기본 테이블 형식(ISAM ,HEAP ,MyISAM )(을)를 선택할 수 있게 되었습니다.이것보다 새롭다 MySQL 의 버젼에서는, 컴파일의 방법으로 따라 추가의 테이블형(InnoDB 또는 BDB )(을)를 서포트하고 있습니다.1 개의 데이타베이스에 다른 형태의 테이블을 수용할 수 있습니다.

새로운 테이블을 작성할 경우에, 그 테이블의 형태를 MySQL 에 통지할 수 있습니다.통상, 디폴트의 테이블형은 MyISAM 입니다.

MySQL 그럼, 테이블 정의와 컬럼 정의를 보관 유지한다 .frm 파일이 반드시 작성됩니다.테이블의 인덱스와 데이터는, 테이블형에 따르고, 이 파일 이외의 1 개이상의 파일에 격납됩니다.

컴파일 또는 액티브화 되어 있지 않은 테이블형을 사용하려고 하면,MySQL 에 의해서 그 테이블형 대신에 MyISAM 형태의 테이블이 작성됩니다.이 동작은, 다양한 테이블형을 서포트한다 MySQL 서버간에 테이블을 카피하는 경우에 편리합니다(대부분의 경우, 마스터 서버는 안전성을 높이기 위해서 트랜잭션(transaction) 스토리지 엔진을 서포트해, 슬레이브 서버는 처리 속도를 높이기 위해서 비트랜잭션(transaction) 스토리지 엔진만을 서포트하고 있습니다).

MySQL 의 초심자는, 이 테이블형의 자동 변경에 당황할지도 모릅니다.이 점에 대해서는, 버젼 4.1 그리고 새로운 클라이언트/ 서버 프로토콜에 경고를 도입해, 테이블형이 자동 변경될 때에 경고를 생성하는 방법으로 대응할 예정입니다.

ALTER TABLE 스테이트먼트를 사용하면, 테이블을 다른 형태로 변환할 수 있습니다. See 항6.5.4. 「ALTER TABLE 구문」 .

MySQL 그럼 2 종류의 테이블을 서포트하고 있는 것에 주의해 주세요.1 개는 트랜잭션(transaction) 세이프의 테이블(InnoDB (와)과 BDB ), 이제(벌써) 1 개는 비트랜잭션(transaction) 세이프의 테이블(HEAP ,ISAM ,MERGE ,MyISAM )입니다.

트랜잭션(transaction) 세이프의 테이블(TST )에는 다음의 이점이 있습니다.

  • 안전성이 높다.MySQL 의 크래쉬나 하드웨어 장해가 발생했을 경우에서도, 자동 리커버리에 의해서, 또는 백업과 트랜잭션(transaction) 로그로부터 데이터를 복원할 수 있다.

  • 다수의 스테이트먼트를 조합해 그것들 모든 것을 COMMIT 커멘드로 일괄해 받아들일 수 있다.

  • ROLLBACK (을)를 실행해 변경을 무효로 할 수 있다(오트코?~ 트모드로 실행하고 있지 않는 경우).

  • 갱신이 실패했을 경우는, 모든 변경이 restore 된다(NTST 테이블에서는, 행해진 모든 변경이 확정된다).

  • 테이블로 독해와 동시에 다수의 갱신을 하는 경우에, 뛰어난 concurrent processing를 실현한다.

InnoDB 테이블을 사용하려면 , 적어도 innodb_data_file_path 기동 옵션을 사용할 필요가 있는 것에 주의해 주세요. See 항7.5.3. 「InnoDB 기동 옵션」 .

비트랜잭션(transaction) 세이프의 테이블(NTST )에는 다음의 이점이 있습니다.

  • 트랜잭션(transaction)의 오버헤드가 없기 때문에, 처리가 아득하게 신속.

  • 트랜잭션(transaction)의 오버헤드가 없기 때문에, 사용하는 디스크 영역이 적어도 된다.

  • 적은 메모리로 갱신을 실행할 수 있다.

같은 스테이트먼트로 TST 테이블과 NTST 테이블을 조합하면, 양쪽 모두의 이점을 살릴 수 있습니다.

7.1. MyISAM 테이블

MyISAM (은)는,MySQL 버젼 3.23 (으)로의 디폴트의 테이블형입니다.이 형태는 ISAM 코드에 근거하고 있어 다수의 편리한 확장 기능을 갖추고 있습니다.

인덱스는 .MYI (MYIndex ) 확장자(extension)가 붙은 파일에, 데이터는 .MYD (MYData ) 확장자(extension)가 붙은 파일에 각각 격납됩니다.MyISAM 테이블은,myisamchk 유틸리티로 검사 및 수복할 수 있습니다.See 항4.5.6.7. 「myisamchk (을)를 사용한 크래쉬의 리커버리」 . 또,MyISAM 테이블을 myisampack 그리고 압축하는 것으로, 사용하는 영역을 큰폭으로 삭감할 수 있습니다. See 항4.8.4. 「myisampack (MySQL 압축 독해 전용 테이블 제네레이터)」 .

MyISAM 의 신기능은 다음과 같습니다.

  • MyISAM 파일에는, 테이블이 올바르게 닫혀졌는지를 나타내는 플래그가 있다.mysqld (을)를 기동할 때에 --myisam-recover (을)를 지정하면,MyISAM 테이블을 열 때에 그 테이블이 올바르게 닫혀졌는지가 자동적으로 검사되어 필요하면 수복된다.

  • 데이터 파일내에 비어 블록이 없는 테이블에 대해, 다른 스레드가 그 테이블에서 독해를 실시하는 것과 동시에 새로운 레코드를 INSERT 할 수 있다(동시 삽입).빈블록은, 대량의 데이터를 포함한 가변장 레코드에 포함되는 데이터의 길이가 짧아지는 갱신을 했을 경우, 또는 레코드를 삭제했을 경우에 발생한다.모든 빈블록을 다 사용하면, 그것 이후의 삽입은 다시 동시 삽입이 된다.

  • 큰 파일을 서포트하는 파일 시스템/ operating system로, 큰 파일(63 비트)가 서포트된다.

  • 모든 데이터가 하위 바이트로부터 순서에 격납된다.이것에 의해서, 데이터가 머신과 OS 에 의존하지 않게 된다.바이너리 이식성을 실현하기 위한 유일한 요건은,2 의 보수로 표현된 부호 정수(모든 머신으로 과거 20 연간 사용되고 있던 형식) 및 IEEE 부동 소수점 형식(같이 주류의 머신으로의 주요한 형식)을 머신으로 사용하는 것이다.머신에 대해 binary level compatibility성을 서포트하고 있지 않을 가능성이 있는 영역은, 매입 시스템만(특수한 프로세서를 사용하고 있는 경우가 있기 위해).

    데이터를 하위 바이트로부터 먼저 격납해도, 속도상 큰 문제는 없다.테이블 로내의 아르바이트는 통상 정렬되지 않고, 미정렬의 아르바이트를 차례로 읽어내는 조작은, 역순에 읽어내는 조작에 비해 그만큼 처리 능력을 필요로 하지 않기 때문에이다.또, 실제의 컬럼의 값을 읽어내는 코드도 다른 코드에 비해 속도가 중시되지 않는다.

  • 모든 수치 키를 상위 바이트로부터 먼저 격납하고, 인덱스의 압축 효율을 높이고 있다.

  • 1 개의 AUTO_INCREMENT 컬럼을 내부 처리하고 있다.MyISAM 그럼, 이 컬럼이 INSERT/UPDATE 그리고 자동 갱신된다.AUTO_INCREMENT 의 값은,myisamchk 그리고 리셋트 할 수 있다.이것에 의해서 AUTO_INCREMENT 컬럼의 처리가 빨라진다(최악이어도 10% ).또, 이전의 ISAM (와)과 같이 낡은 번호가 재사용되지 않는다.멀티 파트 키의 마지막 항목에 AUTO_INCREMENT 하지만 정의되고 있는 경우는, 이전의 동작이 계속해 유효가 되는 것에 주의한다.

  • 키 트리는, 소트 된 순서로 삽입되면(AUTO_INCREMENT 컬럼을 사용하고 있을 때 등), 분할되어 상위 노드에 키가 1 개만 포함되게 된다.이것에 의해서, 키 트리로의 영역 이용율이 향상한다.

  • BLOB 컬럼과 TEXT 컬럼에 인덱스를 작성할 수 있다.

  • 인덱스가 작성된 컬럼으로 NULL 값이 허가된다.이 경우,1 키 정답 0 ~ 1 아르바이트가 사용된다.

  • 최대 키장의 디폴트치는 500 아르바이트(재컴파일로 변경 가능).길이가 250 아르바이트를 넘는 키의 경우는, 디폴트의 1,024 아르바이트보다 큰 키 블록 사이즈가 사용된다.

  • 테이블 당의 최대 키수의 디폴트치는 32 .이 수치는,myisamchk (을)를 재컴파일 하지 않아도 64 까지 확대할 수 있다.

  • myisamchk (을)를 --update-state 부착으로 실행하면, 테이블이 검사필로서 마크 된다. myisamchk --fast (은)는, 이 마크가 없는 테이블만을 검사한다.

  • myisamchk -a (은)는, 키의 각 부분(ISAM (와)과 같이 키 전체 만이 아니고)에 관한 통계 정보를 격납한다.

  • 갱신/ 삽입과 삭제가 혼재하고 있는 경우에, 가변장 레코드가 fragment화 되는 것이 적게 되었다.이것은, 인접하는 삭제가 끝난 블록의 결합, 및 다음의 블록이 삭제되고 있는 경우의 블록의 확장이 자동적으로 행해지게 되었기 때문이다.

  • myisampack 그리고,BLOB 및 VARCHAR 컬럼을 팩 할 수 있다.

  • 데이터 파일과 인덱스 파일을 다른 디렉토리에 배치하고 속도를 높일 수 있다(CREATE TABLE 의 DATA/INDEX DIRECTORY="path" 옵션을 사용). See 항6.5.3. 「CREATE TABLE 구문」 .

MyISAM (은)는,MySQL 그리고 가까운 장래 사용 가능해지는 다음의 기능도 서포트하고 있습니다.

  • 진정한 VARCHAR 형태의 서포트.VARCHAR 컬럼은, 길이를 나타낸다 2 아르바이트의 값으로 시작된다.

  • VARCHAR (을)를 사용하는 테이블에는, 고정장과 가변장의 레코드를 수용할 수 있다.

  • VARCHAR 및 CHAR 하 64K 까지 가능.모든 키 세그먼트(segment)에는, 각각 독자적인 언어 정의가 있다.이것에 의해서,MySQL 그럼 컬럼 마다 언어 정의를 바꿀 수 있다.

  • 계산된 해시 인덱스를 UNIQUE 인덱스로서 사용할 수 있다.이것에 의해서, 테이블내의 컬럼의 임의의 편성을 UNIQUE 인덱스로 할 수 있다(다만, 계산되었다 UNIQUE 인덱스로의 검색은 불가능).

통상, 인덱스 파일은 ISAM 보다 MyISAM (분)편이 훨씬 작기 때문에 주의해 주세요.즉,MyISAM (은)는 일반적으로 ISAM 보다 적은 system resource를 사용합니다만, 압축된 인덱스에 데이터를 삽입할 때에 의해 많은 CPU 시간을 필요로 합니다.

다음에 나타낸다 mysqld 의 옵션을 사용하고,MyISAM 테이블의 동작을 변경할 수 있습니다. See 항4.6.8.4. 「SHOW VARIABLES 」 .

옵션 | 설명
--myisam-recover=# | 크래쉬 한 테이블의 자동 리커버리.
-O myisam_sort_buffer_size=# | 테이블을 리커버리 할 때에 사용되는 버퍼.
--delay-key-write=ALL | 모든 MyISAM 테이블에 대해서, 기입간에 키 버퍼를 플래시 하지 않는다.
-O myisam_max_extra_sort_file_size=# | 속도는 늦어도 안전한 키 캐쉬 인덱스 작성 방법을 어느 시점에서 사용할까를 MySQL 하지만 판단할 수 있도록(듯이) 한다. 주의: 이 파라미터를 지정하는 단위로서4.0.3 보다 전은메가바이트, 이 버젼에서는 아르바이트를 사용한다.
-O myisam_max_sort_file_size=# | 임시 파일이 이 값을 넘었을 경우에, 작성된 인덱스에 대해서 고속의 소트 인덱스 방법을 사용하지 않는다. 주의: 이 파라미터를 지정하는 단위로서4.0.3 보다 전은메가바이트, 이 버젼에서는 아르바이트를 사용한다.
-O bulk_insert_buffer_size=# | 벌크 삽입의 최적화로 사용되는 트리 캐쉬의 사이즈. 주의: 이것은 스레드 당의 제한치.

--myisam-recover=# (을)를 지정해 mysqld (을)를 기동하면, 자동 리커버리가 액티브화 됩니다.See 항4.1.1. 「mysqld 커멘드 라인 옵션」 . 테이블이 열릴 때에 검사됩니다.검사의 내용은, 테이블에 크래쉬의 마크가 뒤따르고 있는지 어떤지, 또는 테이블의 오픈 카운트 변수가 0 (이)가 아니고, 한편 --skip-external-locking 그리고 실행하고 있을지입니다.상기의 어느 쪽인지가 들어맞는 경우는, 다음의 처리를 합니다.

  • 테이블에 에러가 있는지 없는지가 검사된다.

  • 에러가 발견되었을 경우는, 테이블의 고속 수복(소트는 실시하지만 데이터 파일은 재구축 하지 않는다)을 시도한다.

  • 데이터 파일에 에러가 있기 위해서(중복 키 에러 등) 수복이 실패했을 경우는, 한번 더 수복을 시도하지만, 이번은 데이터 파일을 재구축 한다.

  • 이 수복이 실패했을 경우는, 이전의 수복 방법(소트 하지 않고 1 레코드씩 쓰는 방법)으로 재차 수복을 시도한다.이 방법으로, 어떠한 에러에서도 몇 안 되는 디스크 용량으로 수복할 수 있을 것이다.

myisam-recover 의 옵션으로서 FORCE (을)를 지정하지 않았던 경우에, 직전에 완료한 스테이트먼트로부터 모든 레코드를 리커버리 할 수 없을 때는, 자동 수복이 안?~ 되어 에러 파일에 다음의 에러 메세지가 써집니다.

Error: Couldn't repair table: test.g00pages

FORCE 옵션을 지정해 있었을 경우는, 상기의 메세지 대신에 다음의 경고가 에러 파일에 써집니다.

Warning: Found 344 of 354 rows when repairing ./test/g00pages

주의: BACKUP 옵션을 지정해 자동 리커버리를 실행하는 경우는,tablename-datetime.BAK (와)과 같은 이름의 파일을 데이타베이스 디렉토리로부터 백업 미디어에 자동적으로 이동한다 cron 스크립트를 준비할 필요가 있는 것에 주의해 주세요.

See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

7.1.1. 키에 필요한 영역

MySQL 그럼 다양한 인덱스를 서포트하고 있습니다만, 일반적으로 사용되는 것은 ISAM 또는 MyISAM 입니다.이것들은 B 트리 인덱스를 사용합니다.이 인덱스 파일의 사이즈는, 모든 키에 대해 ( 키장+4)/0.67 (을)를 계산해, 그것을 합계하는 것으로 대략적으로 산출할 수 있습니다(이것은, 모든 키가 소트 된 순서에 삽입되어 한편 키가 일절 압축되지 않는다고 하는, 최악의 케이스를 상정하고 있습니다).

문자열 인덱스에서는 공백이 압축됩니다.인덱스의 최초의 부분이 문자열의 경우는, 프리픽스도 압축됩니다.문자열 컬럼에 포함되는 후속의 공백이 긴 경우, 또는 그 컬럼이 VARCHAR 컬럼이기 위해서 그 길이가 풀로 사용되는 것이 없는 경우는, 공백의 압축에 의해서 인덱스 파일이 상기의 수치보다 작아집니다.프리픽스의 압축은, 문자열로 시작되는 키로 사용됩니다.동일한 프리픽스를 가지는 문자열이 다수 존재하는 경우는, 프리픽스의 압축이 도움이 됩니다.

MyISAM 테이블에서는, 테이블 작성시에 PACK_KEYS=1 (을)를 지정하는 것으로, 수치의 프리픽스를 압축할 수도 있습니다.이 기능은, 수치가 상위 바이트로부터 순서에 격납되는 경우에, 동일한 프리픽스를 가지는 정수 키가 다수 있을 때 도움이 됩니다.

7.1.2. MyISAM 테이블 형식

MyISAM (은)는,3 종류의 테이블형을 서포트합니다.그 중 2 개는, 사용하고 있는 컬럼의 형태에 따라 자동적으로 선택됩니다.3 번째의 압축 테이블은,myisampack 툴에 의해서만 작성됩니다.

BLOB 값을 가지지 않는 테이블을 CREATE 또는 ALTER 할 때에,ROW_FORMAT=# 테이블 옵션을 사용해 테이블 형식을 강제적으로 DYNAMIC 또는 FIXED (으)로 설정할 수 있습니다.장래적으로는,ALTER TABLE 에 ROW_FORMAT=compressed | default (을)를 지정하는 것으로, 테이블을 압축/ 전개할 수 있게 됩니다. See 항6.5.3. 「CREATE TABLE 구문」 .

7.1.2.1. 정적(고정장) 테이블의 특성

이것은 디폴트의 형식입니다.이 형식은, 테이블에 VARCHAR ,BLOB , 또는 TEXT 형태의 컬럼이 포함되지 않은 경우에 사용됩니다.

이 형식은 가장 단순하고 가장 안전합니다.또, 디스크상의 형식으로서는 가장 고속으로.속도가 빠른 것은, 디스크상에서 간단하게 데이터를 검출할 수 있기 (위해)때문입니다.검색의 대상이 인덱스와 정적 형식을 사용하고 있는 경우, 조작은 극히 단순합니다.단지 레코드의 번호에 레코드의 길이를 걸 뿐입니다.

또, 테이블을 스캔 할 때에도,1 회의 디스크 독해로 일정수의 레코드를 간단하게 읽어낼 수 있습니다.

고정 사이즈의 MyISAM 파일에 쓰고 있을 때 컴퓨터가 크래쉬 했을 경우의 보전성도 증명되고 있습니다.이 경우,myisamchk 에 의해서 각 레코드의 개시 위치와 종료 위치가 간단하게 산출해집니다.따라서, 통상은, 부분적으로 써진 레코드를 제외한 모든 레코드를 회복할 수 있습니다.MySQL 그럼 모든 인덱스를 언제라도 재구축 할 수 있는 것에 주의해 주세요.

  • CHAR ,NUMERIC ,DECIMAL 의 각 컬럼은, 그 컬럼장까지의 나머지의 부분이 공백에서 묻힌다.

  • 극히 고속.

  • 캐쉬가 용이.

  • 레코드가 고정 위치에 있기 위해, 크래쉬 후의 재구축이 용이.

  • myisamchk 그리고 재편성 할 필요가 없다.다만, 다수의 레코드를 삭제했기 때문에 빈 디스크 영역을 operating system에 되돌리는 경우를 제외하다.

  • 통상은 동적 테이블보다 많은 디스크 영역을 필요로 한다.

7.1.2.2. 동적 테이블의 특성

이 형식은, 테이블에 VARCHAR ,BLOB , 또는 TEXT 컬럼이 포함되어 있는 경우, 혹은 테이블이 ROW_FORMAT=dynamic 그리고 작성되었을 경우에 사용됩니다.

이 형식은 조금 복잡합니다.각 레코드에 각각의 길이를 기록한 헤더가 필요하기 때문입니다.1 개의 레코드가, 갱신에 의해서 길어졌기 때문에, 복수의 장소에 존재하게 될 가능성도 있습니다.

OPTIMIZE table 또는 myisamchk (을)를 사용하고, 테이블을 데후라그먼트화할 수 있습니다.VARCHAR 또는 BLOB 컬럼과 같은 테이블내에, 빈번히 액세스/ 변경하는 정적 데이터가 있는 경우는, fragment화를 회피하기 위해서 동적인 컬럼을 다른 테이블로 이동하면 좋을 것입니다.

  • 문자열 컬럼은 모두 동적이다(길이가 4 아르바이트 미만의 것을 제외하다).

  • 각 레코드의 선두에는, 어느 문자열 컬럼이 공백('' )(으)로, 어느 수치 컬럼이 제로인지를 나타내는 비트 맵이 붙어 있다(NULL 값을 포함한 컬럼과는 다르다).문자열 컬럼으로 후속의 공백을 없앤 후의 길이가 제로가 되었을 경우, 또는 수치 컬럼의 값이 제로인 경우는, 그러한 컬럼이 비트 맵으로 마크 되어 디스크에 보존되지 않는다.공백이 아닌 문자열은, 길이가 기록된 아르바이트에 문자열의 내용을 부가해 보존된다.

  • 통상은, 사용하는 디스크 영역이 고정장 테이블에 비해 훨씬 적다.

  • 각 레코드는, 요구되었을 뿐의 영역을 사용한다.레코드가 커지면, 필요에 따라서 그 레코드가 단편에 분할된다.그 결과, 레코드의 fragment화가 생긴다.

  • 레코드의 갱신에 의해서 레코드의 길이가 확장되면, 그 레코드가 fragment화 된다.이 경우는,myisamchk -r (을)를 가끔 실행하고, 퍼포먼스를 높일 필요가 있다.일부의 통계 정보에는,myisamchk -ei tbl_name (을)를 사용한다.

  • 레코드가 세세하고 fragment화 되고 링크(fragment)가 없어져 있을 가능성이 있기 위해, 크래쉬 후의 재구축은 용이하지 않다.

  • 동적인 사이즈의 레코드에 대해서는, 예기 되는 레코드의 길이를 다음의 방법으로 산출할 수 있다.

    3
+ (
필드수 + 7) / 8
+ (char
컬럼의 수)
+
수치 컬럼을 팩 한 사이즈
+
문자열의 길이
+ (NULL
컬럼의 수 + 7) / 8

    각 링크에는 6 아르바이트의 패널티가 있다.동적 레코드는, 갱신에 의해서 레코드가 확장될 때마다 링크된다.새로운 링크는 적어도 각각 20 아르바이트 있기 위해, 다음 번의 확장은 같은 링크로 행해진다고 생각할 수 있다.그렇지 않은 경우는, 새로운 링크가 발생한다.링크의 수는,myisamchk -ed 그리고 체크할 수 있다.모든 링크를 삭제하려면 ,myisamchk -r (을)를 사용한다.

7.1.2.3. 압축 테이블의 특성

이것은, 옵션의 myisampack 툴(ISAM 테이블에서는 pack_isam )(으)로 생성되는 독해 전용 테이블입니다.

  • MySQL 디스트리뷰션은,MySQL 하지만 GPL 판이 되기 전의 것도 포함하고, 모두 myisampack 그리고 압축된 테이블을 읽어낼 수 있다.

  • 압축 테이블은 극히 몇 안 되는 디스크 영역 밖에 사용하지 않는다.디스크 사용량이 최소한으로 억제되기 위해, 늦은 디스크(CD-ROM 등)을 사용하는 경우에 적절하고 있다.

  • 각 레코드는 따로 따로 압축된다(아크세스오버헤드가 극히 적다).레코드의 헤더는, 테이블로 가장 큰 레코드에 따라 고정된다(1 ~ 3 아르바이트).각 컬럼은 다른 방법으로 압축된다.압축 타입에는 다음의 것이 있다.

    • 통상은, 컬럼 마다 다른 하프맨 테이블이 존재한다.

    • 사픽스 공백의 압축.

    • 프리픽스 공백의 압축.

    • 치 0 의 수치는 1 비트로 격납한다.

    • 값의 범위가 작은 정수 컬럼은, 가능한 한 작은 형태를 사용해 격납한다.예를 들어,BIGINT 컬럼(8 아르바이트)의 모든 값이 0 ~ 255 의 범위내에 있는 경우는, 이 컬럼을 TINYINT 컬럼(1 아르바이트)로서 격납한다.

    • 컬럼의 가능치가 적은 경우는, 컬럼의 형태를 ENUM (으)로 변환한다.

    • 상기의 압축을 조합해 사용할 수도 있다.

  • 고정장 또는 가변장의 레코드를 처리할 수 있다.

  • myisamchk 그리고 압축을 해제할 수 있다.

7.1.3. MyISAM 테이블의 문제

MySQL 하지만 데이터의 격납에 사용하는 파일 형식은 광범위한 검사를 받고 있습니다만, 데이타베이스 테이블의 파손을 부를 수도 있는 상황은 항상 존재합니다.

7.1.3.1. MyISAM 테이블이 파손했을 경우

MyISAM (은)는 신뢰성이 높은 테이블 형식입니다만(테이블에 대한 모든 변경은 SQL 스테이트먼트로부터 제어가 돌아오기 전에 써집니다) , 그런데도 이하의 상황이 발생했을 경우는 테이블이 파손할 우려가 있습니다.

  • 기입의 도중에 mysqld 프로세스가 강제 종료되었을 경우.

  • 컴퓨터가 예기 하지 않고 슛다운 되었을 경우(컴퓨터의 전원이 잘렸을 경우 등).

  • 하드웨어 에러.

  • 가동중의 테이블로 외부 프로그램(myisamchk 등)을 사용했을 경우.

  • MySQL 또는 MyISAM 코드의 소프트웨어 버그.

테이블이 파손하면, 일반적으로 다음과 같은 현상을 볼 수 있습니다.

  • 테이블에서 데이터를 선택할 경우에,Incorrect key file for table: '...'. Try to repair it 그렇다고 하는 에러가 표시된다.

  • 쿼리가 테이블로 레코드를 검출할 수 없는, 또는 불완전한 데이터를 돌려준다.

테이블이 파손하고 있지 않는지 어떤지는,CHECK TABLE 커멘드로 확인할 수 있습니다. See 항4.5.4. 「CHECK TABLE 구문」 .

파손한 테이블은,REPAIR TABLE 그리고 수복할 수 있습니다. See 항4.5.5. 「REPAIR TABLE 구문」 . 또,mysqld 하지만 가동하고 있지 않을 때에,myisamchk 커멘드를 사용해 테이블을 수복할 수도 있습니다. myisamchk syntax .

테이블이 크게 파손하고 있는 경우는, 원인을 찔러?~ 필요가 있습니다. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

이 경우에 가장 중요한 것은,mysqld 하지만 강제 종료되었을 때에 테이블이 파손했는지를 확인하는 것입니다(이것은,mysqld 에러 파일에 restarted mysqld 그렇다고 하는 행이 최근 기록되었는지를 체크하는 것으로 간단하게 검증할 수 있습니다).이것이 해당하지 않는 경우는, 그 파손의 시험대를 작성해 볼 필요가 있습니다. See 항E.1.6. 「테이블이 파손했을 경우에 시험대를 작성한다」 .

7.1.3.2. 클라이언트가 테이블을 사용하고 있다, 또는 테이블을 적절히 닫지 않았다

각 MyISAM .MYI 파일의 헤더에는, 테이블이 적절히 닫혀지고 있는지를 체크하기 위한 카운터가 있습니다.

CHECK TABLE 또는 myisamchk (으)로부터 다음의 경고가 돌려주어지는 일이 있습니다.

# clients is using or hasn't closed the table properly

이것은, 이 카운터가 어긋나 있는 것을 의미합니다.테이블의 파손을 의미하고 있는 것은 아닙니다만, 적어도 테이블을 검사해 문제가 없는 것을 확인할 필요가 있습니다.

카운터의 구조는 다음과 같습니다.

  • MySQL 그리고 테이블이 최초로 갱신될 때, 인덱스 파일의 헤더내에 있는 카운터가 증가한다.

  • 그 후의 갱신에서는, 카운터는 변경되지 않는다.

  • FLUSH 에 의해서, 또는 테이블 캐쉬에 빈 곳이 없기 위해(때문에), 테이블의 마지막 인스턴스가 닫혀지면, 그때까지 테이블이 한 개소에서도 갱신되고 있으면 카운터가 감소한다.

  • 테이블을 수복하는지, 테이블을 검사해 문제가 없었던 경우는, 카운터가 제로에 리셋트 된다.

  • 테이블을 검사하는 다른 프로세스와의 상호작용에 수반하는 문제를 회피하기 위해(때문에), 카운터가 제로인 경우는, 테이블을 닫을 때에도 카운터가 감소하지 않는다.

즉, 카운터가 어긋날 가능성이 있는 것은, 다음의 경우에 한정됩니다.

  • MyISAM 테이블이 LOCK 및 FLUSH TABLES (을)를 사용하지 않고 카피되었다.

  • 갱신되고 나서 닫혀질 때까지 에 MySQL 하지만 크래쉬 했다(다만,MySQL (은)는 각 스테이트먼트로 생긴 모든 기입을 다음의 스테이트먼트까지 발행하기 위해(때문에), 테이블이 무사한 가능성도 있다).

  • mysqld 하지만 사용하고 있던 테이블로, 제삼자가 myisamchk --recover 또는 myisamchk --update-state (을)를 실행했다.

  • 있다 mysqld 서버가 사용하고 있는 테이블에 대해, 다른 mysqld 서버가 REPAIR 또는 CHECK (을)를 실행했다.이 경우,CHECK (은)는 실행해도 문제 없는(다만 다른 서버로부터 경고를 받는다)가,REPAIR (은)는 피할 필요가 있다.현시점에서는,REPAIR (을)를 실행하면 데이터 파일이 새로운 파일로 치환되어 그것이 다른 서버에 통지되지 않기 때문에이다.


7.2. MERGE 테이블

MERGE 테이블은,MySQL 버젼 3.23.25 그리고 새롭게 도입되었습니다.코드는 아직 감마판입니다만, 비교적 안정되어 있을 것입니다.

MERGE 테이블(MRG_MyISAM 테이블이라고도 불립니다)는,1 개의 테이블로서 사용할 수 있는 동일한 MyISAM 테이블의 집합입니다.테이블의 집합에는,SELECT ,DELETE ,UPDATE 만을 실행할 수 있습니다.MERGE 테이블에 대해서 DROP (을)를 실행하면,MERGE 의 사양만이 파기됩니다.

WHERE 없이 DELETE FROM merge_table (을)를 사용하면, 테이블에 대한 매핑만이 소거되어 맵 된 테이블의 내용은 삭제되지 않는 것에 주의해 주세요(이것은 4.1 그리고 수정할 예정입니다).

동일한 테이블이란, 모든 테이블이 동일한 컬럼 및 키 정보로 작성되고 있는 것을 의미합니다.컬럼의 팩 방법이 다른 테이블, 보관 유지하는 컬럼이 전혀 같지 않은 테이블, 혹은 키의 순서가 다른 테이블은 머지 할 수 없습니다.다만, 일부의 테이블은 myisampack 그리고 압축할 수 있습니다. See 항4.8.4. 「myisampack (MySQL 압축 독해 전용 테이블 제네레이터)」 .

MERGE 테이블을 작성하면,.frm 테이블 정의 파일 및 .MRG 테이블 리스트 파일이 작성됩니다..MRG 에는,1 개의 인덱스 파일로서 사용되는 복수의 인덱스 파일(.MYI 파일)의 리스트만이 포함되어 있습니다.4.1.1 보다 전의 버젼에서는, 사용되는 모든 테이블을 MERGE 테이블과 같은 데이타베이스에 배치할 필요가 있었습니다.

현재,MERGE 테이블에 맵 하는 테이블에 대해서는,SELECT ,UPDATE ,DELETE 의 각 특권이 필요합니다.

MERGE 테이블에는, 다음과 같은 효과가 있습니다.

  • 일련의 로그 테이블을 간단하게 관리할 수 있다.예를 들어, 매월의 데이터를 다른 파일에 수록해, 그러한 일부를 myisampack 그리고 압축한 후에,MERGE (을)를 작성해 그것들을 1 개의 파일로서 사용할 수 있다.

  • 처리 속도가 빨라진다.큰 독해 전용 테이블을 몇개의 기준에 근거해 분할해, 분할한 각 부분을 다른 디스크에 배치할 수 있다.이 경우,MERGE 테이블을 작성하면, 큰 테이블을 사용하는 경우에 비해 아득하게 처리가 빨라진다(RAID (을)를 사용했을 경우도 같은 효과를 얻을 수 있다).

  • 보다 효율적으로 검색할 수 있다.처리의 대상을 정확하게 파악하고 있으면, 일부의 쿼리에 대해서 분할된 테이블의 1 개로 검색을 실시해, 그 외의 쿼리에 대해서 MERGE (을)를 사용할 수 있다.다수의 다양한 MERGE 테이블을 액티브하게 할 수도 있다.이 경우, 파일이 중복 하고 있어도 상관없다.

  • 보다 효율적으로 수복할 수 있다.1 개의 큰 파일을 수복하는 것보다,MERGE 파일에 맵 된 파일을 개별적으로 수복하는 것이 간단하다.

  • 다수의 파일을 1 개의 파일로서 즉석에서 맵 할 수 있다.MERGE 테이블은, 개개의 테이블의 인덱스를 사용한다.MERGE 테이블 독자적인 인덱스를 보관 유지할 필요는 없다.이 때문에,MERGE 테이블의 집합의 작성 또는 재맵에는 거의 시간이 걸리지 않는다.MERGE 테이블을 작성할 때는, 키 정의를 지정할 필요가 있는 것에 주의한다.

  • 일련의 테이블을 온디멘드 또는 배치로 큰 테이블에 결합하는 경우는, 대신에 그러한 테이블에 대해서 온디멘드로 MERGE 테이블을 작성하는 것이 좋다.이 분이 시간이 걸리지 않고, 디스크 영역도 큰폭으로 절약할 수 있다.

  • operating system의 파일 사이즈 제한을 회피할 수 있다.

  • 1 개의 테이블상에서 MERGE (을)를 사용하는 것만으로, 테이블의 앨리어스(alias)/ 동의어를 작성할 수 있다.이것에 의해서 퍼포먼스가 특히 영향을 받을 것은 없다(독해마다 몇차례의 간접적인 호출과 memcpy() 의 호출이 발생할 뿐).

MERGE 테이블의 결점은 다음과 같습니다.

  • MERGE 테이블에는 동일한 MyISAM 테이블 밖에 사용할 수 없다.

  • REPLACE (을)를 사용할 수 없다.

  • MERGE 테이블은 보다 많은 파일 기술자를 사용한다.10 개의 테이블을 맵 한다 MERGE 테이블을 10 사람의 유저가 사용하고 있는 경우는,10 10 + 10 개의 파일 기술자를 사용하게 된다(10 사람의 유저에게 10 개씩의 데이터 파일과10 개의 공유 인덱스 파일).

  • 키의 독해가 늦다.키에 대해서 독해를 실시하면,MERGE 스토리지 엔진은 구성요소로 라고의 테이블에 대해서 독해를 발행하고, 지정된 키에 가장 일치하는 테이블을 체크한다.그 후에 "read-next" (을)를 실행하면,MERGE 스토리지 엔진은 읽어내 버퍼를 검색해 다음의 키를 검출한다.1 개의 키 버퍼가 모두 사용될 때까지 스토리지 엔진은 다음의 키 블록을 읽어내지 않는다.이 때문에,eq_ref 검색에서는 MERGE 키의 처리에 꽤 시간이 걸리지만,ref 검색에서는 그만큼 시간이 걸리지 않는다. See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

  • " 열려 있다" MERGE 테이블에 의해서 맵 되고 있는 테이블에는,DROP TABLE ,ALTER TABLE ,WHERE 마디 없음의 DELETE FROM table_name ,REPAIR TABLE ,TRUNCATE TABLE ,OPTIMIZE TABLE , 또는 ANALYZE TABLE (을)를 실행할 수 없다.이것을 실행하면,MERGE 테이블이 원래의 테이블을 참조할 우려가 있어, 예기치 않은 결과를 얻는 일이 있다.이 문제를 가장 간단하게 회피하려면 ,FLUSH TABLES 커멘드를 발행해 " 열려 있다" MERGE 테이블을 남기지 않게 한다.

MERGE 테이블을 작성할 경우에,1 개로 정리하고 싶은 테이블을 UNION=(list-of-tables) 그리고 지정할 필요가 있습니다.옵션으로서MERGE 테이블에의 삽입이 UNION 리스트내의 최초의 테이블과 마지막 테이블의 어디에서 행해질까를,INSERT_METHOD 그리고 지정할 수 있습니다.INSERT_METHOD (을)를 지정하지 않았던 경우, 또는 NO (을)를 지정했을 경우는,MERGE 테이블에 대한 모든 INSERT 커멘드로 에러가 돌려주어집니다.

다음의 예는,MERGE 테이블의 사용법을 나타내고 있습니다.

CREATE TABLE t1 (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, message CHAR(20));
CREATE TABLE t2 (a INT NOT NULL AUTO_INCREMENT PRIMARY KEY, message CHAR(20));
INSERT INTO t1 (message) VALUES ("Testing"),("table"),("t1");
INSERT INTO t2 (message) VALUES ("Testing"),("table"),("t2");
CREATE TABLE total (a INT NOT NULL AUTO_INCREMENT, message CHAR(20), KEY(a))
             TYPE=MERGE UNION=(t1,t2) INSERT_METHOD=LAST;
SELECT * FROM total;

total 테이블에서는 키가 일의가 되지 않기 때문에, 이 테이블에서는 UNIQUE 또는 PRIMARY KEY (을)를 작성하지 않는 것에 주의해 주세요.

MySQL 서버의 외부로부터 직접 .MRG 파일을 조작할 수도 있습니다.

shell> cd /mysql-data-directory/current-database
shell> ls -1 t1.MYI t2.MYI > total.MRG
shell> mysqladmin flush-tables

이것으로 다음과 같은 조작을 실행할 수 있게 됩니다.

mysql> SELECT * FROM total;
+---+---------+
| a | message |
+---+---------+
| 1 | Testing |
| 2 | table   |
| 3 | t1      |
| 1 | Testing |
| 2 | table   |
| 3 | t2      |
+---+---------+

주의: a 컬럼은,PRIMARY KEY (으)로서 선언되고 있습니다만, 실제로는 일의는 아닌 것에 주의해 주세요.MERGE 테이블에서는, 이것을 구성하는 일련의 MyISAM 테이블 전체에 걸치는 일의성을 확보 가능하지 않는가 들입니다.

MERGE 테이블을 맵 다시 하려면 , 다음의 몇개의 조작을 실행합니다.

  • 테이블에 대해서 DROP (을)를 실행해, 테이블을 재작성한다.

  • ALTER TABLE table_name UNION=(...) (을)를 사용한다.

  • .MRG 파일을 변경해,MERGE 테이블과 이것을 구성하는 모든 테이블에 대해서 FLUSH TABLE (을)를 발행하는 것으로, 스토리지 엔진이 새로운 정의 파일을 읽어내도록(듯이) 한다.

7.2.1. MERGE 테이블의 문제

다음에 드는 것은,MERGE 테이블에 관한 기존의 문제입니다.

  • MERGE 테이블에서는, 테이블 전체로 UNIQUE 제약을 보관 유지할 수 없다.INSERT (을)를 실행하면,INSERT_METHOD=xxx 에 따라 데이터가 최초 또는 마지막 테이블에 삽입된다.삽입처의 MyISAM 테이블에서는 그 데이터가 일의인 것이 보증되지만, 이 테이블은 다른 MyISAM 테이블에 대해 전혀 칸치 하지 않는다.

  • WHERE 없이 DELETE FROM merge_table (을)를 사용하면, 테이블에 대한 매핑만이 소거되어 맵 된 테이블의 내용은 일절 삭제되지 않는다.

  • 액티브한 MERGE 테이블로 사용되고 있는 테이블에 대해서 RENAME TABLE (을)를 실행하면, 테이블이 파손할 우려가 있다.이것은 MySQL 4.1.x 그리고 수정될 예정.

  • MERGE 형태의 테이블을 작성할 경우에, 그 구성요소가 되는 테이블의 형태에 호환성이 있는지, 또는 그 테이블 자체가 존재할지가 체크되지 않는다.MERGE 테이블이 사용될 때에, 맵 된 테이블간에 레코드장이 동일한지 어떤지가 MySQL 에 의해서 간단하게 체크되지만, 이것으로는 완전한 검증이 되지 않는다.

    이러한 방법으로 MERGE (을)를 테이블을 사용하고 있으면, 높은 확률로 미지의 문제가 발생한다.

  • ALTER TABLE (을)를 사용해 MERGE 테이블로 사용되고 있는 테이블에 UNIQUE 인덱스를 추가한 후에, 다시 ALTER TABLE (을)를 사용해 MERGE 테이블에 통상의 인덱스를 추가하면, 이전의 일의가 아닌 키가 테이블에 존재하고 있었을 경우에, 테이블에 대한 키의 순서가 바뀐다.이것은, 중복 키를 가능한 한 빨리 검출할 수 있도록,ALTER TABLE 하지만 UNIQUE 키를 통상의 키의 전에 배치하기 위해(때문에)이다.

  • Windows 그럼,MERGE 테이블이 사용하고 있는 테이블에 대해서 DROP TABLE (을)를 실행할 수 없다.이것은,MERGE 스토리지 엔진이 실행하는 테이블 매핑을 MySQL 의 상위 레이어가 인식하지 않기 때문이다.Windows 그럼 열려 있는 파일을 파기할 수 없기 때문에, 대상의 테이블을 파기하기 전에,FLUSH TABLES 그리고 모든 MERGE 테이블을 플래시 하는지,MERGE 테이블을 파기할 필요가 있다.이것에 대해서는, 뷰를 도입할 경우에 수정한다.


7.3. ISAM 테이블

MySQL 버젼 5.0 그럼,ISAM 테이블형이 폐?~ 됩니다.MySQL 4.1 그럼, 이 테이블형이 소스에 포함되어 있어도 컴파일 할 수 없습니다.이 테이블 핸들러의 실장으로서는 MyISAM (분)편이 우수하기 위해, 가능한 한 빨리 ISAM 테이블을 MyISAM 테이블로 변환할 필요가 있습니다.

ISAM (은)는,B 트리 인덱스를 사용합니다.인덱스는 .ISM 확장자(extension)가 붙은 파일에 보존되어 데이터는 .ISD 확장자(extension)가 붙은 파일에 보존됩니다.ISAM 테이블은,isamchk 유틸리티로 검사 및 수복할 수 있습니다. See 항4.5.6.7. 「myisamchk (을)를 사용한 크래쉬의 리커버리」 .

ISAM 에는, 다음의 기능과 특성이 있습니다.

  • 압축된 고정장의 키.

  • 고정 및 가변의 레코드장.

  • 16 개의 키와 1 키 정답 16 개의 부품.

  • 최대 키장은 256 아르바이트(디폴트).

  • 머신의 형식에서 데이터를 격납하기 위해(때문에), 고속이지만 머신과 OS 에 의존한다.

MyISAM 테이블에 들어맞는 것은, 대부분의 경우 ISAM 테이블에도 들어맞읍니다.See 항7.1. 「MyISAM 테이블」 .MyISAM 테이블과의 주된 차이점은 다음과 같습니다.

  • ISAM 테이블에서는,OS/ 플랫폼을 걸쳐 바이너리를 이식할 수 없다.

  • 4 GB (을)를 넘는 테이블을 처리할 수 없다.

  • 문자열로의 프리픽스의 압축만을 서포트한다.

  • 키의 제한치가 작다.

  • 동적인 테이블이 보다 빈번히 fragment화 된다.

  • 테이블의 압축에,myisampack (은)는 아니고 pack_isam 하지만 사용된다.

ISAM 테이블을 MyISAM 테이블로 변환해 mysqlcheck 등의 유틸리티를 사용할 수 있도록 하려면 ,ALTER TABLE 스테이트먼트를 사용합니다.

mysql> ALTER TABLE tbl_name TYPE = MYISAM;

편입식의 MySQL 그럼,ISAM 테이블이 서포트되지 않습니다.


7.4. HEAP 테이블

HEAP 테이블은, 해시 인덱스를 사용해, 메모리에 격납됩니다.이것에 의해서 처리는 빨라집니다만,MySQL 하지만 크래쉬 하면, 이 테이블에 격납된 모든 데이터가 없어집니다.HEAP (은)는, 텐포라리테이불로서 매우 편리합니다.

MySQL 의 내부 HEAP 테이블은, 오버플로우 에리어 없음의 100% 동적 해시를 사용합니다.면세표용의 여분의 영역은 필요 없습니다.또,HEAP 테이블에서는, 해시 테이블로 일반적으로 볼 수 있는 삭제 + 삽입에 수반하는 문제도 일어나지 않습니다.

mysql> CREATE TABLE test TYPE=HEAP SELECT ip,SUM(downloads) AS down
    ->                   FROM log_table GROUP BY ip;
mysql> SELECT COUNT(ip),AVG(down) FROM test;
mysql> DROP TABLE test;

다음에,HEAP 테이블을 사용할 때의 고려사항을 나타냅니다.

  • 잘못하고 메모리를 다 사용하는 것이 없게,CREATE 스테이트먼트에는 반드시 MAX_ROWS (을)를 지정한다.

  • 인덱스에는 = (와)과 <=> 밖에 사용할 수 없다(그 대신해 극히 고속).

  • HEAP 테이블에서는, 레코드의 검색에 키 전체를 사용 할 수 밖에 없다.한편 MyISAM 테이블에서는, 키의 임의의 프리픽스를 사용해 레코드를 검색할 수 있다.

  • HEAP 테이블은, 고정 레코드 장형식을 사용한다.

  • HEAP (은)는,BLOB 컬럼과 TEXT 컬럼을 서포트하지 않는다.

  • HEAP (은)는,AUTO_INCREMENT 컬럼을 서포트하지 않는다.

  • MySQL 4.0.2 보다 전의 버젼에서는,HEAP 하지만 NULL 컬럼의 인덱스를 서포트하지 않는다.

  • HEAP 테이블에서는 일의가 아닌 키를 사용할 수 있다(해시 테이블에서는 별로 사용되지 않는다).

  • HEAP 테이블은, 다른 테이블과 같게 모든 클라이언트간에 공유된다.

  • 다음의 엔트리를 차례로 검색할 수 없다(즉, 인덱스를 사용해 ORDER BY (을)를 실행할 수 없다).

  • HEAP 테이블의 데이터는, 작은 블록으로 할당할 수 있다.테이블은 100% 동적이다(삽입시).오버플로우 에리어도 여분의 키스 페이스도 필요없다.삭제된 레코드는 링크된 리스트에 보존되어 새로운 데이터를 테이블에 삽입할 때에 재사용된다.

  • 동시에 사용하는 모든 HEAP 테이블에 대해서 충분한 추가 메모리가 필요.

  • 메모리를 해방하려면 ,DELETE FROM heap_table ,TRUNCATE heap_table , 또는 DROP TABLE heap_table (을)를 실행할 필요가 있다.

  • MySQL 그럼,2 개의 값의 사이에 존재하는 대체로의 레코드수를 확인할 수 없다(이 값은, 사용하는 인덱스를 범위 Optimizer가 결정되기 위해서 사용한다).MyISAM 테이블을 HEAP 테이블로 변경하면, 이 점이 일부의 쿼리에 영향을 줄 가능성이 있다.

  • 잘못된 조작을 실시하지 않게,max_heap_table_size 보다 큰 사이즈의 HEAP 테이블은 작성할 수 없게 되어 있다.

HEAP 테이블로 1 개의 레코드에 필요한 메모리는, 다음과 같이 계산합니다.

SUM_OVER_ALL_KEYS(
키의 최대장 + sizeof(char*) * 2)
+ ALIGN(
레코드의 길이+1, sizeof(char*))

sizeof(char*) (은)는,32 비트 머신에서는 4 ,64 비트 머신에서는 8 입니다.


7.5. InnoDB 테이블

7.5.1. InnoDB 테이블의 개요

InnoDB (은)는,MySQL 에 있어서의, 코?~ 트, 롤백(rollback), 크래쉬 리커버리의 각 기능을 갖춘 트랜잭션(transaction) 세이프(ACID 준거)의 스토리지 엔진입니다.InnoDB (은)는, 행 레벨로 락을 실시해,SELECT 스테이트먼트로 Oracle 식의 비락의 독해 일관성(consistent read) (을)를 실현합니다.이러한 기능에 의해서, multiuser로의 병행성과 퍼포먼스가 향상합니다.InnoDB 그럼 락 에스칼레이션이 불필요합니다.InnoDB (으)로의 행 레벨 락은 몇 안 되는 스페이스 밖에 사용하지 않기 때문입니다.InnoDB (은)는,MySQL 그리고 FOREIGN KEY 제약을 최초로 서포트한 스토리지 엔진입니다.

InnoDB (은)는, 대용량의 데이터를 처리할 때에 최대한의 퍼포먼스를 실현하도록(듯이) 설계되고 있습니다.그 CPU 효율은, 아마 다른 디스크 베이스의 RDB 엔진의 어떤 것보다 우수합니다.

InnoDB (은)는, 높은 퍼포먼스를 필요로 하는 많은 대규모 데이타베이스 사이트에서 실제로 사용되고 있습니다.유명한 인터넷 뉴스 사이트의 Slashdot.org (은)는,InnoDB 위에서 가동하고 있습니다.Mytrix, Inc. 그럼,1 TB (을)를 넘는 데이터를 InnoDB 에 격납해, 다른 사이트에서는 InnoDB 그리고 1 초간에 평균 800 건의 삽입/ 갱신을 처리하고 있습니다.

기술적으로는,InnoDB 하 MySQL 의 데이타베이스 연구 최종 단계입니다.InnoDB (은)는, 데이터와 인덱스를 캐쉬하기 위한 전용의 버퍼 풀을 메인 메모리에 가지고 있습니다.InnoDB 의 테이블과 인덱스는 테이블 스페이스에 격납됩니다.이것은, 복수의 파일(또는 로 디바이스)로 구성되어 있는 경우가 있습니다.이 점은, 각 테이블을 개별의 파일에 격납한다 MyISAM 테이블 등과는 다릅니다.InnoDB 테이블은, 파일 사이즈가 2 GB 에 제한되고 있는 operating system상에서도, 임의의 사이즈로 할 수 있습니다.

InnoDB 에 관한 최신 정보는,http://www.innodb.com/ 그리고 참조할 수 있습니다.InnoDB 메뉴얼의 최신판도 이 사이트에 수록되고 있습니다.

InnoDB (은)는,MySQL (와)과 같다 GNU GPL License Version 2 (1991 년 6 달 붙여) 아래에서 릴리스 되고 있습니다.MySQL/InnoDB (을)를 배포하는 경우에, 어플리케이션이 GPL 라이센스의 제약을 채우지 않을 때는,https://order.mysql.com/?sub=pg&pg_no=1 (으)로부터 MySQL Pro 의 상용 라이센스를 구입할 필요가 있습니다.

7.5.2. MySQL 버젼 3.23 (으)로의 InnoDB

MySQL 버젼 4.0 보다 ,InnoDB (은)는 디폴트로 MySQL 에 짜넣어지고 있습니다.다음의 정보는,3.23 시리즈인 만큼 해당합니다.

InnoDB 테이블은,3.23.34a 보다 MySQL 소스 디스트리뷰션에 포함되게 되었습니다. 다만 3.23 시리즈에서는,InnoDB 하 MySQL-Max 바이너리 디스트리뷰션에만 짜넣어지고 있습니다.Windows 의 경우는,-Max 바이너리가 표준의 바이너리 디스트리뷰션에 포함되어 있습니다.

InnoDB (을)를 서포트한다 MySQL 의 바이너리 버젼을 다운로드했을 경우는,MySQL 의 메뉴얼에 따라서 MySQL 의 바이너리 버젼을 인스톨 해 주세요.벌써 MySQL-3.23 (을)를 인스톨 하고 있는 경우에 MySQL-Max (을)를 가장 간단하게 인스톨 하려면 , 서버의 실행 파일 mysqld (을)를,-Max 디스트리뷰션의 실행 파일로 옮겨놓습니다.MySQL (와)과 MySQL-Max (은)는, 서버의 실행 파일의 이름만이 다릅니다. See 항2.2.9. 「MySQL 바이너리 디스트리뷰션의 인스톨」 . See 항4.8.5. 「mysqld-max (확장 mysqld 서버)」 .

InnoDB (을)를 서포트한다 MySQL (을)를 컴파일 하려면 ,MySQL-3.23.34a 이?~ 의 버젼을 http://www.mysql.com/ (으)로부터 다운로드해,--with-innodb 옵션으로 MySQL (을)를 콘피개 합니다.MySQL 소스 디스트리뷰션의 인스톨에 대해서는,MySQL 의 메뉴얼을 참조해 주세요. See 항2.3. 「MySQL 소스 디스트리뷰션의 인스톨」 .

cd /path/to/source/of/mysql-3.23.37
./configure --with-innodb

MySQL-Max-3.23 그리고 InnoDB 테이블을 사용하려면 , 옵션 설정 파일 my.cnf (Windows 의 경우는 my.ini 그렇지만 가능)의 [mysqld] 섹션으로 설정 파라미터를 지정 하지 않으면 안됩니다 .

3.23 그럼, 적어도 innodb_data_file_path 그리고 데이터 파일의 이름과 사이즈를 지정할 필요가 있습니다.my.cnf 그리고 innodb_data_home_dir (을)를 지정하지 않는 경우는, 디폴트로 MySQL 의 datadir 에 이러한 파일이 작성됩니다.innodb_data_home_dir (을)를 하늘의 문자열로서 지정하면,innodb_data_file_path 그리고 데이터 파일에의 절대 패스를 지정할 수 있습니다.

이것을 최소한의 방법으로 변경하려면 ,[mysqld] 섹션에 다음의 행을 추가합니다.

innodb_data_file_path=ibdata:30M

다만, 높은 퍼포먼스를 얻으려면 , 추천 된 방법으로 옵션을 지정하는 것이 최선입니다. See 항7.5.3. 「InnoDB 기동 옵션」 .

7.5.3. InnoDB 기동 옵션

MySQL 버젼 3.23 그리고 InnoDB 테이블을 유효하게 하는 방법에 대해서는, 항7.5.2. 「MySQL 버젼 3.23 (으)로의 InnoDB 」 (을)를 참조해 주세요.

MySQL-4.0 그럼,InnoDB 테이블을 유효하게 하기 위해서 특히 무엇인가를 할 필요는 없습니다.

MySQL-4.0 및 MySQL-4.1 의 디폴트의 동작으로서MySQL 의 datadir 에 자동 확장한다 10 MB 의 ibdata1 파일이 1 개와5 MB 의 ib_logfile 로그 파일이 2 개작성됩니다(MySQL-4.0.0 및 4.0.1 의 데이터 파일은 64 MB 그리고, 자동 확장하지 않습니다).

주의: 높은 퍼포먼스를 얻으려면 , 이 후의 예에 나타나고 있다 InnoDB 의 각종 파라미터를 명시적으로 설정 할 필요가 있습니다 .

InnoDB 테이블을 사용하지 않는 경우는,MySQL 옵션 설정 파일에 skip-innodb 옵션을 지정해 InnoDB (을)를 동작시키지 않게 할 수 있습니다.

[mysqld]
skip-innodb

버젼 3.23.50 및 4.0.2 보다 ,innodb_data_file_path 행의 마지막 데이터 파일을, 자동 확장 파일 (으)로서 지정할 수 있게 되었습니다.그 경우의 innodb_data_file_path 의 구문은 다음과 같습니다.

innodb_data_file_path =
데이터 파일의 패스:
사이즈;
데이터 파일의 패스:
사이즈;...
...  ;
데이터 파일의 패스:
사이즈[:autoextend[:max:
사이즈]]

마지막 데이터 파일에 autoextend 옵션을 지정하면, 테이블 스페이스에 빈 곳이 없어졌을 경우에,InnoDB 하지만 마지막 데이터 파일을 확장합니다.1 회의 증분은 8 MB 입니다.다음에 예를 나타냅니다.

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:100M:autoextend
#
#
주의: innodb_data_home_dir
에 공문자를 지정했을 경우,
# innodb_data_file_path
에게 주는 패스는 절대 패스가 된다

이 예에서는,InnoDB 에 대해, 초기 사이즈가 100 MB 의 데이터 파일을 1 개만 작성해, 스페이스가 부족하게 되었을 경우에 8 MB 단위로 확장하도록(듯이) 지정해 있습니다.디스크가 가득 찼을 경우는, 예를 들어 다른 디스크에 새로운 데이터 파일을 추가할 수도 있습니다.그 경우는,autoextend 하지만 지정되어 있다 ibdata1 의 사이즈를 확인해, 그 사이즈가 1,024 1,024 아르바이트(= 1 MB )의 배수가 되도록(듯이) 만 값을 계산해, 계산으로 얻을 수 있던 값을 innodb_data_file_path 의 ibdata1 의 사이즈로서 명시적으로 지정할 필요가 있습니다.이것으로, 새로운 데이터 파일을 ibdata1 의 뒤로 추가할 수 있습니다.

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:988M;/disk2/ibdata2:50M:autoextend
#
#
주의:
이 예에서는 최초 100M
의 ibdata1
하지만,
# 888M (1024 * 1024
의 배수)
만 확장되고 있었으므로,988M
의 지정이 되어 있다.

파일 시스템의 최대 파일 사이즈가 2 GB 인 경우는 주의가 필요합니다.InnoDB (은)는,OS 의 최대 파일 사이즈를 고려하지 않습니다.이러한 파일 시스템에서는, 데이터 파일의 최대 사이즈를 지정할 필요가 있습니다.

innodb_data_home_dir =
innodb_data_file_path = /ibdata/ibdata1:100M:autoextend:max:2000M

단순한 my.cnf 의 예.128 MB 의 RAM (와)과 1 개의 하드 디스크를 탑재한 컴퓨터를 사용하고 있다고 합니다.다음에 나타내는 것은,InnoDB 의 my.cnf 또는 my.ini 에 있어서의 설정 파라미터의 예입니다.이 예에서는,MySQL-Max-3.23.50 이?~ , 또는 MySQL-4.0.2 이?~ 하지만 가동하고 있는 것을 상정하고 있습니다.이 예는,Unix (와)과 Windows 의 양쪽 모두로, 유저가 InnoDB 데이터 파일과 로그 파일을 복수의 디스크에 분산시키지 않는 경우에 적절하고 있습니다.이 설정 파라미터에 의해서, 자동 확장하는 데이터 파일 ibdata1 및 2 개의 InnoDB 로그 파일 ib_logfile0 (와)과 ib_logfile1 하지만,MySQL 의 datadir (일반적으로는 /mysql/data )에 작성됩니다. 또, 어카이브(archive) 된 작은 InnoDB 로그 파일 ib_arch_log_0000000000 도 datadir 에 작성됩니다.

[mysqld]
# You can write your other MySQL server options here
# ...
#                                  Datafile(s) must be able to
#                                  hold your data and indexes.
#                                  Make sure you have enough
#                                  free disk space.
innodb_data_file_path = ibdata1:10M:autoextend
#                                  Set buffer pool size to
#                                  50 - 80 % of your computer's
#                                  memory
innodb_buffer_pool_size=70M
innodb_additional_mem_pool_size=10M
#                                  Set the log file size to about
#                                  25 % of the buffer pool size
innodb_log_file_size=20M
innodb_log_buffer_size=8M
#                                  Set ..flush_log_at_trx_commit
#                                  to 0 if you can afford losing
#                                  some last transactions
innodb_flush_log_at_trx_commit=1

datadir 그리고 파일을 작성하는 권한이 MySQL 서버에 있을지를 확인해 주세요 .

일부의 파일 시스템에서는, 데이터 파일을 2 GB 미만으로 할 필요가 있는 것에 주의해 주세요. 로그 파일을 모두 맞춘 사이즈는,4 GB 미만이 아니면 안됩니다.또, 데이터 파일을 모두 맞춘 사이즈는,10 MB 이상이 아니면 안됩니다.

InnoDB 데이타베이스를 처음으로 작성할 경우에는, 커멘드 prompt로부터 MySQL 서버를 기동하는 것이 최선입니다. InnoDB 에 의해서 데이타베이스의 작성에 관한 정보가 화면에 출력되므로, 처리의 경과를 확인할 수 있습니다. 화면 출력의 예에 대해서는, 다음의 섹션을 참조해 주세요. 예를 들어,Windows 그럼 다음과 같이 해 mysqld-max.exe (을)를 기동하는 것으로써,MySQL 서버는 콘솔을 닫지 않게 됩니다.

your-path-to-mysqld\mysqld-max --console

Windows 그럼,my.cnf 또는 my.ini (을)를 어디에 배치하면 좋을까요. Windows (으)로의 규칙은 다음과 같습니다.

  • my.cnf 또는 my.ini 의 한편만을 작성할 필요가 있다.

  • my.cnf 파일은,C:\my.cnf (으)로 할 필요가 있다.

  • my.ini 파일은,C:\WINDOWS (이)나 C:\WINNT 등의 %WINDIR% 디렉토리 등에 배치할 필요가 있다.MS-DOS 의SET 커멘드를 사용하면,%WINDIR% 의 값을 출력할 수 있다.

  • PC 그리고 사용하는 부트 로더의 부트 드라이브가 C: 드라이브가 아닌 경우는,my.ini 파일 밖에 사용할 수 없다.

Unix 그럼, 어디서 옵션을 지정하면 좋을까요. Unix 그럼,mysqld 하지만 다음의 파일(존재하는 경우)로부터 다음의 순서로 옵션을 읽어냅니다.

  • /etc/my.cnf 글로벌 옵션

  • COMPILATION_DATADIR/my.cnf 서버 고유의 옵션

  • defaults-extra-file --defaults-extra-file=... 그리고 지정된 파일

  • ~/.my.cnf 유저 고유의 옵션

COMPILATION_DATADIR 하 MySQL 데이터 디렉토리에서,mysqld 하지만 컴파일 되었을 때에 ./configure 옵션으로서 지정된 것입니다(일반적으로는 바이너리 인스톨용의 /usr/local/mysql/data , 또는 소스 인스톨용의/usr/local/var ).

mysqld 하지만 그 my.cnf 또는 my.ini (을)를 어디에서 읽어낼지를 모르는 경우는, 서버에의 최초의 커멘드 라인 옵션으로서 패스를 지정할 수 있습니다(mysqld --defaults-file=your_path_to_my_cnf ).

InnoDB (은)는, 데이터 파일에의 디렉토리 패스를 결정하는 경우에,innodb_data_home_dir 에 정의된 패스의 텍스트를 innodb_data_file_path 안의 데이터 파일명 또는 패스의 텍스트와 결합해, 필요에 따라서 사이에 slash 또는 backslash를 삽입합니다.my.cnf 그리고 키워드 innodb_data_home_dir 하지만 전혀 지정되어 있지 않은 경우는,MySQL 의 datadir (을)를 의미한다 ' 닷' 디렉토리 ./ 하지만 디폴트로 사용됩니다.

고도의 my.cnf 의 예.2 GB 의 RAM (와)과 3 개의 60 GB 하드 디스크를 탑재했다 Linux 컴퓨터를 사용하고 있다고 합니다.하드 디스크의 디렉토리 패스는, 각각 / ,/dr2 ,/dr3 입니다.다음에 나타내는 것은,InnoDB 의 my.cnf 에 있어서의 설정 파라미터의 예입니다.

주의: 디렉토리는 InnoDB 에 의해서 작성되지 않기 때문에, 각자 작성할 필요가 있습니다. 데이터 및 로그 그룹의 홈 디렉토리를 작성하려면 ,Unix 또는 MS-DOS 의 mkdir 커멘드를 사용합니다.

[mysqld]
# You can write your other MySQL server options here
# ...
innodb_data_home_dir =
#                                  Datafiles must be able to
#                                  hold your data and indexes
innodb_data_file_path = /ibdata/ibdata1:2000M;/dr2/ibdata/ibdata2:2000M:autoextend
#                                  Set buffer pool size to
#                                  50 - 80 % of your computer's
#                                  memory, but make sure on Linux
#                                  x86 total memory usage is
#                                  < 2 GB
innodb_buffer_pool_size=1G
innodb_additional_mem_pool_size=20M
innodb_log_group_home_dir = /dr3/iblogs
#                                  .._log_arch_dir must be the same
#                                  as .._log_group_home_dir
innodb_log_arch_dir = /dr3/iblogs
innodb_log_files_in_group=3
#                                  Set the log file size to about
#                                  15 % of the buffer pool size
innodb_log_file_size=150M
innodb_log_buffer_size=8M
#                                  Set ..flush_log_at_trx_commit to
#                                  0 if you can afford losing
#                                  some last transactions
innodb_flush_log_at_trx_commit=1
innodb_lock_wait_timeout=50
#innodb_flush_method=fdatasync
#innodb_thread_concurrency=5

2 개의 데이터 파일을 다른 디스크에 배치했던 것에 주의해 주세요. InnoDB (은)는, 데이터 파일에 의해서 형성되는 테이블 스페이스를 보텀 업식에 묻어서 갑니다.경우에 따라서는, 모든 데이터를 같은 물리 디스크에 배치하지 않는 것이 퍼포먼스가 좋아집니다.로그 파일을 데이터와는 다른 디스크에 배치하면, 대부분의 경우 퍼포먼스는 좋아집니다. 로 디바이스 (을)를 데이터 파일로서 사용할 수도 있습니다.일부의 Unix 그럼, 이 방법으로 I/O 의 처리 속도가 향상합니다.my.cnf 그리고 이러한 데이터 파일을 지정하는 방법에 대해서는, 메뉴얼로 항7.5.13.1. 「디스크 I/O 」 에 관한 섹션을 참조해 주세요.

경고: Linux x86 그럼, 메모리 사용율의 설정을 너무 높게 하지 않게 주의해 주세요.glibc (은)는 프로세스 heap가 스레드스탁크보다 커지는 것을 허가하고 있어, 그 경우에 서버가 크래쉬 합니다.다음의 계산식을 봐 주세요.

innodb_buffer_pool_size + key_buffer_size +
max_connections * (sort_buffer_size + read_buffer_size) + max_connections * 2 MB

이 값이,2 GB 에 가까운지,2 GB (을)를 넘고 있으면 위험합니다.각 스레드는 스택을 사용해(통상은 2 MB .다만 MySQL AB 바이너리에서는 256 KB 마셔), 최악의 경우,sort_buffer_size + read_buffer_size 의 크기의 추가 메모리도 사용합니다.

다른 mysqld 서버 파라미터는 어떻게 조정하면 좋을까요.: 대부분의 유저에게 적합한 일반적인 값은 다음과 같습니다.

skip-locking
max_connections=200
read_buffer_size=1M
sort_buffer_size=1M
#                                  Set key_buffer_size to 5 - 50%
#                                  of your RAM depending on how
#                                  much you use MyISAM tables, but
#                                  keep key_buffer_size + InnoDB
#                                  buffer pool size < 80% of
#                                  your RAM
key_buffer_size=...

주의: 4.0 보다 전의 버젼에서는, 일부의 파라미터를 set-variable = innodb... = 123 (와)과 같이 지정할 필요가 있습니다.

각 설정 파라미터의 의미는 다음과 같습니다.

옵션 | 설명
innodb_file_per_table | 4.1.1 보다 이용 가능.이 옵션에 의해서,InnoDB (은)는 작성된 각 테이블을 독자적인 .ibd 파일에 격납하게 된다.복수의 테이블 스페이스에 관한 섹션을 참조.
innodb_data_home_dir | 디렉토리 패스안의, 모든 InnoDB 데이터 파일에 공통된 부분.my.cnf 그리고 이 옵션을 지정하지 않았던 경우의 디폴트는,MySQL 의 datadir .이 옵션에는 하늘의 문자열도 지정할 수 있다.그 경우,innodb_data_file_path 에 절대 파일 패스를 지정할 수 있다.
innodb_data_file_path | 개개의 데이터 파일에의 패스와 그 사이즈.각 데이터 파일에의 풀 디렉토리 패스는, 여기서 지정한 패스에 innodb_data_home_dir (을)를 연결하는 것으로 취득할 수 있다.파일 사이즈는메가바이트로 지정되기 위해, 상기와 같이 사이즈의 뒤에 'M' 하지만 부가되고 있다.InnoDB 하 'G' 그렇다고 하는 약칭도 인식한다.1 G 하 1,024 MB (을)를 의미한다.3.23.44 보다 , 큰 파일을 서포트하는 operating system로 4 GB (을)를 넘는 파일 사이즈도 설정할 수 있게 되었다.일부의 오퍼레이팅 시스템에서는, 파일을 2 GB 미만으로 할 필요가 있다.4.0 보다 ,innodb_data_file_path (을)를 지정하지 않는 경우의 디폴트의 동작으로서10 MB 의 자동 확장 데이터 파일 ibdata1 하지만 작성된다.파일의 합계 사이즈는,10 MB 이상이 아니면 안된다.
innodb_mirrored_log_groups | 데이타베이스를 위해서 보관 유지해 두는 로그 그룹의 카피의 수.현시점에서는 1 (으)로 설정할 필요가 있다.
innodb_log_group_home_dir | InnoDB 로그 파일에의 디렉토리 패스.my.cnf 그리고 이 옵션을 지정하지 않았던 경우는, 디폴트로 MySQL 의 datadir 하지만 설정된다.
innodb_log_files_in_group | 로그 그룹내의 로그 파일의 수.InnoDB (은)는 이러한 로그 파일에 순환적으로 기입을 실시한다.이 파라미터의 추천치와 디폴트치는 모두 2 .
innodb_log_file_size | 로그 그룹내의 각 로그 파일의 사이즈(메가바이트).실제적인 값의 범위는,1M (으)로부터, 아래에서 지정하는 버퍼 풀의 사이즈의 1/n 까지(n (은)는 그룹내의 로그 파일의 수).이 값이 큰 만큼, 버퍼 풀에서 필요한 체크 포인트 플래시의 회수가 줄어 들기 위해, 디스크 I/O 하지만 삭감된다.다만, 로그 파일이 크면 크래쉬 했을 경우의 리커버리에 시간이 걸린다.32 비트 컴퓨터에서는, 로그 파일의 합계 사이즈를 4 GB 미만으로 할 필요가 있다.디폴트는 5M .
innodb_log_buffer_size | InnoDB 하지만 디스크상의 로그 파일에 로그를 써내기 위해서 사용하는 버퍼의 사이즈.실제적인 값은 1M ~ 8M .log buffer를 크게 하면, 트란자크션코?~ 트까지 디스크에 로그를 써내는 일 없이 큰 트랜잭션(transaction)를 실행할 수 있다.큰 트랜잭션(transaction)가 있는 경우는, 이와 같이 log buffer를 크게 하는 것으로 디스크 I/O (을)를 삭감할 수 있다.
innodb_flush_log_at_trx_commit | 통상, 이 파라미터는 1 (으)로 설정한다.이것에 의해서, 트란자크션코?~ 트시에 로그가 디스크에 플래시 되어 트랜잭션(transaction)에 의한 변경이 확정되어 데이타베이스 크래쉬를 면한다.이러한 안전성을 필요로 하지 않고, 한편 작은 트랜잭션(transaction)를 실행하고 있는 경우는, 이 옵션을 0 또는 2 (으)로 설정해 로그에의 디스크 I/O (을)를 삭감할 수 있다.치 0 (을)를 지정하면, 로그 파일에의 로그의 써, 및 디스크에의 로그 파일의 플래시가1 초에 약1 회 밖에 행해지지 않게 된다.치 2 (을)를 지정하면, 로그 파일에의 로그의 기입은 코?~ 트마다 행해지지만, 디스크에의 로그 파일의 플래시는 1 초에 약 1 회 밖에 행해지지 않게 된다.MySQL-4.0.13 보다 디폴트치가 0 (으)로부터 1 (으)로 변경되었다.
innodb_log_arch_dir | 로그의 어카이브(archive)를 사용하는 경우에, 가득 찬 로그 파일이 어카이브(archive) 되는 디렉토리.현시점에서는, 이 파라미터를 innodb_log_group_home_dir (와)과 같은 값으로 설정할 필요가 있다.
innodb_log_archive | 현시점에서는, 이 파라미터를 0 (으)로 설정할 필요가 있다.백업으로부터의 리커버리는 MySQL 하지만 독자적인 로그 파일을 사용해 실시하기 위해, 현시점에서는 InnoDB 의 로그 파일을 어카이브(archive) 할 필요는 없다.
innodb_buffer_pool_size | InnoDB 하지만, 그 테이블의 데이터나 인덱스를 캐쉬하기 위해서 사용하는 메모리밧파의 사이즈.이 값이 큰 만큼, 테이블내의 데이터에의 액세스에 필요한 디스크 I/O 하지만 적게 된다.데이타베이스 전용 서버에서는, 이 파라미터를 머신의 물리 메모리의 80% 에까지 설정할 수 있다.다만, 물리 메모리의 경합에 의해서 operating system로 페이징이 발생할 가능성이 있기 위해, 너무 큰 값은 설정하지 않게 한다.
innodb_buffer_pool_awe_mem_mb | 32 비트판 Windows 의 AWE 메모리에 배치되는 버퍼 풀의 사이즈(MB ).4.1.0 (으)로부터 이용 가능하고,32 비트판 Windows 에게만 관계한다.사용한다 32 비트판 Windows operating system가,Address Windowing Extensions (AWE )(으)로 불린다 4 GB (을)를 넘는 메모리를 서포트하고 있는 경우는, 이 파라미터를 사용해 InnoDB 버퍼 풀을 AWE 물리 메모리에 할당할 수 있다.지정 가능한 최대치는,64000 .이 파라미터를 지정했을 경우,innodb_buffer_pool_size 하 mysqld 의 32 비트 address 공간에 있어서의 윈도우가 된다(이 address 공간으로 InnoDB 하지만 AWE 메모리를 맵 한다).그 경우의 innodb_buffer_pool_size 에 적절한 사이즈는 500M .
innodb_additional_mem_pool_size | InnoDB 하지만 데이터 딕쇼내리의 정보와 그 외의 내부 데이터 구조를 격납하기 위해서 사용하는 메모리프르의 사이즈.이 파라미터의 실제적인 값은 2M 이지만, 어플리케이션으로 사용하는 테이블의 수가 많은 만큼, 이 값을 크게 할 필요가 있다.InnoDB (은)는, 이 풀의 메모리를 다 써 버리면, operating system로부터 메모리를 할당하게 되어,MySQL 에러 로그에 경고 메세지를 쓴다.
innodb_file_io_threads | InnoDB 에 있어서의 파일 I/O 스레드의 수.통상, 이 값은 4 (으)로 할 필요가 있지만,Windows 그럼 이것보다 큰 수를 지정하면 디스크 I/O 의 면에서 유리하게 되는 경우가 있다.
innodb_lock_wait_timeout | 락 대기 상태가 되었다 InnoDB 트랜잭션(transaction)가 롤백(rollback) 될 때까지의 타임 아웃 시간(초).InnoDB (은)는, 그 락 테이블로 트랜잭션(transaction)의 데드 록을 자동적으로 검출해, 그 트랜잭션(transaction)를 롤백(rollback) 한다.LOCK TABLES 커멘드를 사용하는지, 또는 같은 트랜잭션(transaction)로 InnoDB 이외의 트랜잭션(transaction) 세이프의 스토리지 엔진을 사용하면,InnoDB 하지만 검출할 수 없는 데드 록이 발생하는 일이 있다.타임 아웃은, 이러한 상황의 해결에 도움이 된다.
innodb_flush_method | 3.23.40 보다 사용 가능.디폴트치는 fdatasync .이외에,O_DSYNC (을)를 지정할 수 있다.
innodb_force_recovery | 경고: 이 옵션은, 파손한 데이타베이스로부터 테이블을 덤프 할 필요가 있는 긴급사태에서만 정의할 필요가 있다.지정 가능한 값은 1 ~ 6 .각각의 값의 의미에 대해서는, 이 후의 「강제적인 리커버리」를 참조.InnoDB 그럼, 안전 대책으로서 이 옵션이 0 보다 클 때는 유저가 데이터를 변경할 수 없게 되어 있다.이 옵션은, 버젼 3.23.44 보다 사용 가능.

7.5.4. InnoDB 테이블 스페이스의 작성

MySQL 하지만 벌써 인스톨 되어my.cnf 의 편집도 끝나 필요한 InnoDB 설정 파라미터가 설정되어 있다고 합니다. MySQL (을)를 기동하기 전에,InnoDB 데이터 파일과 로그 파일용으로 지정한 디렉토리가 존재하는 것, 및 그러한 디렉토리에의 액세스권이 있는 것을 확인할 필요가 있습니다.InnoDB 에 의해서 작성되는 것은 파일만으로, 디렉토리는 작성되지 않습니다.데이터 파일과 로그 파일을 보존 가능한 한의 충분한 디스크 영역이 있는 일도 확인해 주세요.

MySQL (을)를 기동하면,InnoDB (은)는 데이터 파일과 로그 파일의 작성을 개시해, 다음과 같은 메세지를 출력합니다.

~/mysqlm/sql > mysqld
InnoDB: The first specified datafile /home/heikki/data/ibdata1
did not exist:
InnoDB: a new database to be created!
InnoDB: Setting file /home/heikki/data/ibdata1 size to 134217728
InnoDB: Database physically writes the file full: wait...
InnoDB: datafile /home/heikki/data/ibdata2 did not exist:
new to be created
InnoDB: Setting file /home/heikki/data/ibdata2 size to 262144000
InnoDB: Database physically writes the file full: wait...
InnoDB: Log file /home/heikki/data/logs/ib_logfile0 did not exist:
new to be created
InnoDB: Setting log file /home/heikki/data/logs/ib_logfile0 size to 5242880
InnoDB: Log file /home/heikki/data/logs/ib_logfile1 did not exist:
new to be created
InnoDB: Setting log file /home/heikki/data/logs/ib_logfile1 size to 5242880
InnoDB: Log file /home/heikki/data/logs/ib_logfile2 did not exist:
new to be created
InnoDB: Setting log file /home/heikki/data/logs/ib_logfile2 size to 5242880
InnoDB: Started
mysqld: ready for connections

이것으로, 새롭다 InnoDB 데이타베이스가 작성되었습니다.mysql 등의 통상 사용한다 MySQL 클라이언트 프로그램으로 MySQL 서버에 접속할 수 있습니다. mysqladmin shutdown 그리고 MySQL 서버를 슛다운 하면,InnoDB (으)로부터 다음과 같은 메세지가 출력됩니다

010321 18:33:34  mysqld: Normal shutdown
010321 18:33:34  mysqld: Shutdown Complete
InnoDB: Starting shutdown...
InnoDB: Shutdown completed

이것으로, 데이터 파일과 로그의 디렉토리를 참조할 수 있게 되어, 작성한 파일을 확인할 수 있습니다.로그 디렉토리에는,ib_arch_log_0000000000 (이)라는 이름 이 작은 파일도 작성됩니다.이것은, 데이타베이스 작성시에 작성된 파일로, 그 후에 InnoDB 하지만 로그의 어카이브(archive)를 오프로 전환하고 있습니다. MySQL (을)를 다시 기동하면, 다음과 같은 메세지가 출력됩니다.

~/mysqlm/sql > mysqld
InnoDB: Started
mysqld: ready for connections

7.5.4.1. 데이타베이스 작성시에 문제가 생겼을 경우

InnoDB 하지만 파일 조작중에 operating system 에러를 출력했을 경우, 통상은 다음중 한쪽이 원인입니다.

  • InnoDB 의 데이터 디렉토리 또는 로그 디렉토리를 작성하지 않았다.

  • mysqld 에, 이러한 디렉토리에서 파일을 작성할 권리가 없다.

  • mysqld 하지만 올바르다 my.cnf 또는 my.ini 파일을 읽어내지 않았기(위해)때문에, 유저가 지정한 옵션을 인식하고 있지 않다.

  • 디스크가 가득한가, 또는 디스크 쿼터가 초과하고 있다.

  • 작성한 서브 디렉토리의 이름이, 지정한 데이터 파일과 같게 되어 있다.

  • innodb_data_home_dir 또는 innodb_data_file_path 에 구문 에러가 있다.

InnoDB 데이타베이스의 작성으로 문제가 생겼을 경우는,InnoDB 하지만 작성한 모든 파일을 삭제할 필요가 있습니다.즉,MySQL 데이타베이스 디렉토리로부터, 모든 데이터 파일, 모든 로그 파일, 어카이브(archive) 된 작은 로그 파일을 삭제해,InnoDB 테이블을 작성했을 경우는, 이러한 테이블에 대응한다 .frm 파일도 삭제합니다.이것으로,InnoDB 데이타베이스를 다시 작성할 수 있습니다.

7.5.5. InnoDB 테이블의 작성

mysql test 그리고 MySQL 클라이언트를 기동했다고 합니다. InnoDB 형식의 테이블을 작성하려면 , 테이블을 작성한다 SQL 커멘드로,TYPE = InnoDB (을)를 지정할 필요가 있습니다.

CREATE TABLE CUSTOMER (A INT, B CHAR (20), INDEX (A)) TYPE = InnoDB;

이 SQL 커멘드에 의해서,my.cnf (으)로 지정한 데이터 파일로부터 완성된다 InnoDB 테이블 스페이스에, 테이블 및 컬럼 A 의 인덱스가 작성됩니다.한층 더 MySQL 에 의해서,MySQL 데이타베이스 디렉토리 test 에 CUSTOMER.frm 파일이 작성됩니다. 내부에서는,InnoDB 하지만 독자적인 데이터 딕쇼내리에 'test/CUSTOMER' 테이블의 엔트리를 추가합니다.따라서,MySQL 의 다른 데이타베이스에 같다 CUSTOMER (이)라는 이름의 테이블을 작성해도,InnoDB 내부에서 테이블명이 충돌할 것은 없습니다.

TYPE = InnoDB 그리고 작성한 임의의 테이블에 대해서 MySQL 의 테이블 스테이터스 커멘드를 발행하는 것으로,InnoDB 테이블 스페이스의 빈 용량을 조회할 수 있습니다.테이블 스페이스의 빈 용량은,SHOW 의 출력의 테이블 코멘트 섹션에 표시됩니다.다음에 예를 나타냅니다.

SHOW TABLE STATUS FROM test LIKE 'CUSTOMER';

SHOW 하지만 InnoDB 테이블에 대해 출력하는 통계 정보는 개산인 것에 주의해 주세요.이러한 정보는,SQL 문장 해석의 최적화로 사용됩니다.다만, 테이블과 인덱스에 예약되고 있는 사이즈(아르바이트 단위)는 정확합니다.

7.5.5.1. MyISAM 테이블에서 InnoDB 에의 변환

InnoDB 에는, 인덱스를 별도 작성하기 위한 특별한 최적화 기능이 없습니다. 이 때문에, 테이블을 export 해 임포트 해, 그 후에 인덱스를 작성 다시 해도 의미가 없습니다. 테이블을 가장 빠르고 InnoDB (으)로 변환하려면 ,InnoDB 테이블에 직접 데이터를 삽입합니다.즉,ALTER TABLE ... TYPE=INNODB (을)를 사용하든가, 혹은 같은 정의로 하늘의 InnoDB 테이블을 작성해,INSERT INTO ... SELECT * FROM ... 그리고 레코드를 삽입합니다.

삽입 처리를 관리하기 쉽게 하기 위해서, 큰 테이블은 분할해 삽입하면 좋을 것입니다.

INSERT INTO newtable SELECT * FROM oldtable
   WHERE yourkey > something AND yourkey <= somethingelse;

모든 데이터를 삽입한 후에, 테이블명을 변경할 수 있습니다.

큰 테이블을 변환할 때 ,InnoDB 의 버퍼 풀 사이즈를 크게 하고, 디스크 I/O (을)를 삭감할 필요가 있습니다.다만, 물리 메모리의 80% (을)를 넘지 않게 해 주세요. InnoDB 의 로그 파일 및 log buffer도 큰 사이즈로 설정합니다.

테이블 스페이스가 부족하지 않는 것을 확인합니다.InnoDB 테이블은,MyISAM 테이블보다 많은 영역을 사용합니다.ALTER TABLE 그리고 영역이 부족하게 되면, 롤백(rollback)가 실행됩니다.롤백(rollback)가 디스크 바운드 하면, 완료까지 수시간을 필요로 할 가능성이 있습니다. 삽입때는,InnoDB 하지만 삽입 버퍼를 사용하고 세칸다리인젝스레코드를 정리해 인덱스에 머지 합니다.이것에 의해서, 디스크 I/O 하지만 큰폭으로 삭감됩니다.롤백(rollback)에서는 이러한 메카니즘이 사용되지 않기 때문에, 삽입의 30 배의 시간이 걸리는 경우가 있습니다.

롤백(rollback)가 폭주했을 경우는, 데이타베이스에 귀중한 데이터가 없으면, 방대한 디스크 I/O 의 완료를 기다리는 것보다도, 데이타베이스 프로세스를 강제 종료해, 모든 InnoDB 데이터 파일과 로그 파일, 및 InnoDB 테이블의 .frm 파일을 삭제한 데다가, 재차 작업을 실행하는 것이 유리한 계책입니다.

7.5.5.2. FOREIGN KEY 제약

버젼 3.23.43b 보다 ,InnoDB 에 외부 키 제약이 장비되게 되었습니다. InnoDB (은)는, 데이터의 완전성을 지키기 위해서 유저가 외부 키 제약을 정의할 수 있도록 한 최초의 MySQL 테이블형입니다.

InnoDB 에 있어서의 외부 키 제약 정의의 구문은 다음과 같습니다.

[CONSTRAINT [symbol]] FOREIGN KEY (index_col_name, ...)
                  REFERENCES table_name (index_col_name, ...)
                  [ON DELETE {CASCADE | SET NULL | NO ACTION
                              | RESTRICT}]
                  [ON UPDATE {CASCADE | SET NULL | NO ACTION
                              | RESTRICT}]

어느 쪽의 테이블도 InnoDB 형태가 아니면 안됩니다. 테이블내에는, 외부 키 컬럼이 최초의 컬럼으로서 같은 순서로 열거되고 있는 인덱스가 필요합니다. 또, 참조 테이블내에는, 참조 컬럼이 최초의 컬럼으로서 같은 순서로 열거되고 있는 인덱스가 필요합니다.InnoDB (은)는, 외부 키 또는 참조 키에 대해서 자동적으로 인덱스를 작성하지 않습니다.따라서, 유저가 명시적으로 인덱스를 작성할 필요가 있습니다.외부 키의 체크를 고속화해, 테이블 스캔을 불필요하게 하려면 , 인덱스가 필요합니다.

외부 키와 참조 키의 대응하는 컬럼은, 형태를 변환하지 않아도 비교할 수 있도록,InnoDB 내부에서 같은 데이터형으로 할 필요가 있습니다. 정수형에 대해서는, 사이즈와 부호의 유무가 같지 않으면 안됩니다 . 문자열형의 길이는 같지 않아도 괜찮습니다. SET NULL 액션을 지정하는 경우는, 아이 테이블내의 컬럼을 NOT NULL (와)과 선언하고 있지 않은 것 (을)를 확인해 주세요.

MySQL 하지만 CREATE TABLE 스테이트먼트로 에러 번호 1005 (을)를 돌려주어, 에러 메세지 문자열에 errno 150 하지만 나타나고 있는 경우는, 외부 키 제약이 올바르게 작성되지 않았기(위해)때문에 테이블의 작성이 실패하고 있습니다. 같이ALTER TABLE 하지만 실패해 errno 150 하지만 나타났을 경우는, 변경된 테이블에 대해서 외부 키 정의가 잘못해 작성되고 있습니다.버젼 4.0.13 보다 ,SHOW INNODB STATUS (을)를 사용하고, 서버로 마지막에 발생했다 InnoDB 외부 키 에러의 상세한 설명을 참조할 수 있게 되었습니다.

버젼 3.23.50 보다 ,InnoDB 하 NULL 컬럼을 포함하고 있는 외부 키 또는 참조 키치로 외부 키 제약을 체크하지 않게 되었습니다.

표준 SQL (으)로부터의 일탈: 친테이블에 같은 참조 키치를 가지는 복수의 레코드가 있는 경우,InnoDB 의 외부 키 체크에서는, 같은 키치를 가지는 친레코드가 그 밖에 존재하지 않는 것으로서 처리를 합니다.예를 들어,RESTRICT 형태 제약을 정의해, 한편 복수의 친레코드를 가지는 아이 레코드가 존재하는 경우,InnoDB (은)는 이러한 친레코드의 삭제를 금?~ 합니다.

버젼 3.23.50 보다 ,ON DELETE CASCADE 마디 또는 ON DELETE SET NULL 마디를 외부 키 제약에 붙일 수도 있게 되었습니다.대응한다 ON UPDATE 옵션은,4.0.8 보다 이용 가능합니다.ON DELETE CASCADE 하지만 지정되어 있는 경우에 친테이블내의 레코드가 삭제되면,InnoDB (은)는 아이 테이블내에서 친레코드내의 참조 키치와 동일한 외부 키치를 가지는 모든 레코드를 자동적으로 삭제합니다.ON DELETE SET NULL 하지만 지정되어 있는 경우는, 아이 레코드가 자동적으로 갱신되고, 외부 키내의 컬럼이 SQL 의 NULL 값으로 설정됩니다.

표준 SQL (으)로부터의 일탈: ON UPDATE CASCADE 또는 ON UPDATE SET NULL (은)는, 캐스케이드중에 벌써 갱신한 테이블을 반복해 갱신하는 경우에,RESTRICT (와)과 같이 동작합니다.이것은, 캐스케이드 된 갱신으로부터 생기는 엔들레스 루프를 막기 (위해)때문입니다.한편, 자기 참조형의 ON DELETE SET NULL 하지만 4.0.13 (으)로부터 동작하게 되었습니다. 자기 참조형의 ON DELETE CASCADE (은)는, 이전부터 동작하고 있었습니다.

다음에 예를 나타냅니다.

CREATE TABLE parent(id INT NOT NULL, PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE child(id INT, parent_id INT, INDEX par_ind (parent_id),
             FOREIGN KEY (parent_id) REFERENCES parent(id)
             ON DELETE SET NULL
) TYPE=INNODB;

다음에 나타내는 것은 복잡한 예입니다.

CREATE TABLE product (category INT NOT NULL, id INT NOT NULL,
                      price DECIMAL,
                      PRIMARY KEY(category, id)) TYPE=INNODB;
CREATE TABLE customer (id INT NOT NULL,
                      PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE product_order (no INT NOT NULL AUTO_INCREMENT,
                      product_category INT NOT NULL,
                      product_id INT NOT NULL,
                      customer_id INT NOT NULL,
                      PRIMARY KEY(no),
                      INDEX (product_category, product_id),
                      FOREIGN KEY (product_category, product_id)
                        REFERENCES product(category, id)
                        ON UPDATE CASCADE ON DELETE RESTRICT,
                      INDEX (customer_id),
                      FOREIGN KEY (customer_id)
                        REFERENCES customer(id)) TYPE=INNODB;

버젼 3.23.50 보다 ,InnoDB 그럼 다음의 스테이트먼트에 의해서 새로운 외부 키 제약을 테이블에 추가할 수 있게 되었습니다.

ALTER TABLE yourtablename
ADD [CONSTRAINT [symbol]] FOREIGN KEY (...) REFERENCES anothertablename(...)
[on_delete_and_on_update_actions]

다만, 필요한 인덱스를 먼저 작성하는 것을 잊지 말아 주세요 .

버젼 4.0.13 보다 ,InnoDB 하지만 다음의 스테이트먼트를 서포트하게 되었습니다.

ALTER TABLE yourtablename DROP FOREIGN KEY internally_generated_foreign_key_id

외부 키를 파기하는 경우는,SHOW CREATE TABLE (을)를 사용하고, 내부에서 생성된 외부 키 ID (을)를 확인할 필요가 있습니다.

InnoDB 하지만 3.23.50 보다 전의 버젼인 경우는, 외부 키 제약을 가지는 테이블 또는 외부 키 제약으로 참조되는 테이블에 관련해 ALTER TABLE 또는 CREATE INDEX (을)를 사용하지 말아 주세요.ALTER TABLE (을)를 실행하면, 테이블에 정의 떠날 수 있어 모든 외부 키 제약이 삭제됩니다.ALTER TABLE (은)는, 참조 테이블에도 사용하지 말아 주세요.다만, schema를 변경하는 경우는 DROP TABLE 및 CREATE TABLE (을)를 사용합니다.MySQL (은)는,ALTER TABLE (을)를 실행할 경우에 내부적으로 RENAME TABLE (을)를 사용하는 경우가 있습니다.이 경우, 테이블을 참조하는 외부 키 제약으로 혼란이 생깁니다. CREATE INDEX 스테이트먼트는,MySQL 그럼 ALTER TABLE (으)로서 처리되기 위해, 이 스테이트먼트에도 이러한 제약이 적용됩니다.

InnoDB (은)는, 외부 키 체크를 실행할 때에, 참조하는 아이 레코드 또는 친레코드에 대해서 공유행 레벨 락을 설정합니다. InnoDB (은)는, 외부 키 제약을 즉석에서 체크합니다.체크가 트란자크션코?~ 트까지 연기될 것은 없습니다.

외부 키 제약을, 예를 들어 LOAD DATA 처리동안만 무시하는 경우는,SET FOREIGN_KEY_CHECKS=0 (을)를 실행합니다.

InnoDB 그럼, 외부 키 제약에 의해서 참조되고 있는 테이블에서도 파기할 수 있습니다.이 경우, 그 제약이 망가지게 됩니다.테이블을 파기하면, 그 작성 스테이트먼트로 정의된 제약도 파기됩니다.

파기된 테이블을 재작성하는 경우는, 그 테이블을 참조하는 외부 키 제약에 따른 정의를 테이블내로 설정할 필요가 있습니다.벌써 설명한 것처럼, 이 테이블에는, 올바른 이름과 형태를 가지는 컬럼, 및 참조 키상의 인덱스가 필요합니다. 이러한 조건이 채워지지 않으면MySQL (으)로부터 에러 번호 1005 하지만 돌려주어져 에러 메세지 문자열에 errno 150 하지만 나타납니다.

버젼 3.23.50 보다 , 다음의 스테이트먼트를 호출하면,InnoDB (으)로부터 테이블의 외부 키 정의가 돌려주어지게 되었습니다.

SHOW CREATE TABLE yourtablename

또,mysqldump 에 의해서 테이블의 올바른 정의와 함께 외부 키가 덤프 파일에 출력됩니다.

또, 다음의 스테이트먼트로 테이블 T 의 외부 키 제약도 열거할 수 있습니다.

SHOW TABLE STATUS FROM yourdatabasename LIKE 'T'

외부 키 제약은, 출력의 테이블 코멘트에 열거됩니다.

7.5.5.3. 복수 테이블 스페이스 - 각 테이블을 독자적인 .ibd 파일에 넣는다

중요: InnoDB-4.1.1 에 업그레이드 한 후에, 다운 그레이드 할 수 없습니다.그것은,InnoDB 의 이전의 버젼이 복수의 테이블 스페이스를 인식하지 않기 때문입니다.

MySQL-4.1.1 보다 , 각 InnoDB 테이블과 그 인덱스를, 그 테이블 독자적인 파일에 격납할 수 있게 되었습니다.각 테이블이 독자적인 테이블 스페이스에 격납되는 것부터, 이 기능은 복수 테이블 스페이스로 불립니다.

이 기능을 유효하게 하려면 ,my.cnf 의 [mysqld] 섹션에 다음의 행을 추가합니다.

innodb_file_per_table

이것에 의해서 InnoDB (은)는, 각 테이블이 속하고 있는 데이타베이스 디렉토리내에 있는 테이블 고유의 tablename.ibd 파일에, 각각의 테이블을 격납합니다.이것은 MyISAM 의 동작과 닮아 있습니다만,MyISAM 그럼 테이블이 데이터 파일 tablename.MYD (와)과 인덱스 파일 tablename.MYI (으)로 나눌 수 있습니다.InnoDB 의 경우는, 데이터와 인덱스의 양쪽 모두가 .ibd 파일에 격납됩니다.

my.cnf (으)로부터 행 innodb_file_per_table (을)를 삭제하면,InnoDB 에 의해서 다시 ibdata 파일내에 테이블이 작성됩니다.4.1.1 이?~ 의 버젼에 업그레이드 하기 전에 ibdata 파일에 격납되고 있던 낡은 테이블은 그대로 남겨져.ibd 파일에 변환될 것은 없습니다.

InnoDB 에는 시스템 테이블 스페이스가 필요하고,.ibd 파일만으로는 불충분합니다. 시스템 테이블 스페이스는, 지금까지 사용되고 있었다 ibdata 파일로 구성됩니다.InnoDB (은)는, 내부 데이터 딕쇼내리와 UNDO 로그를 시스템 테이블 스페이스에 배치합니다.

MyISAM 테이블과는 달라,.ibd 파일은 자유롭게 이동할 수 없습니다 .이것은, 테이블 정의가 InnoDB 시스템 테이블 스페이스에 격납되고 있기 때문에와InnoDB 그리고 트랜잭션(transaction) ID (와)과 로그 순서 번호의 정합성을 유지할 필요가 있기 때문에입니다.

종래의 RENAME 커멘드를 사용하고,.ibd 파일과 관련 테이블을, 어느 데이타베이스로부터 같다 MySQL/InnoDB 인스톨내에 있는 다른 데이타베이스로 옮길 수 있습니다.

RENAME TABLE olddatabasename.tablename TO newdatabasename.tablename;

같다 MySQL/InnoDB 인스톨로부터 취득했다 .ibd 파일의 클린 백업이 있는 경우는, 다음의 커멘드로 그 백업을 InnoDB 데이타베이스에 restore 할 수 있습니다.

ALTER TABLE tablename DISCARD TABLESPACE; /* CAUTION:
현재의 .ibd
파일을 삭제합니다! */
<
백업 했다 .ibd
파일을 적절한 장소에 둡니다>
ALTER TABLE tablename IMPORT TABLESPACE;

여기서의 깨끗하다고는, 다음 일을 의미하고 있습니다.

  • .ibd 파일내에, 트랜잭션(transaction)가 실행해 코?~ 트 되어 있지 않은 변경이 없다.

  • .ibd 파일에 머지 되어 있지 않은 삽입 버퍼 엔트리가 없다.

  • 삭제 마크 된 모든 인덱스 레코드가 .ibd 파일로부터 삭제되고 있다.

  • mysqld 에 의해서,.ibd 파일의 변경된 모든 페이지가 버퍼 풀로부터 파일에 플래시 되고 있다.

이러한 .ibd 파일의 클린 백업은, 다음의 방법으로 작성할 수 있습니다.

  • mysqld 서버의 모든 활동을 정?~ 해, 모든 트랜잭션(transaction)를 코?~ 트 한다.

  • SHOW INNODB STATUS 문장으로 데이타베이스에 액티브한 트랜잭션(transaction)가 없는 것이 나타나InnoDB 의 메인스레드가 Waiting for server activity (이)가 되는 것을 기다린다.이것으로,.ibd 파일의 카피를 작성할 수 있다.

깨끗한 .ibd 파일을 작성하는 이제(벌써) 1 개의 방법(유상)이 있습니다.

  • InnoDB 핫 백업을 사용해 InnoDB 의 데이터를 백업 한다.

  • 새로운 mysqld 서버를 백업 한 파일을 사용하도록(듯이) 해 기동해, 백업내의 .ibd 파일을 클린 업 한다.

TODO 에는, 깨끗한 .ibd 파일도 다른 MySQL/InnoDB (으)로 이동할 수 있도록(듯이) 하는 것을 들어지고 있습니다.그러기 위해서는,.ibd 파일내에서 트랜잭션(transaction) ID (와)과 로그 순서 번호를 리셋트 하는 것이 필요하게 됩니다.

7.5.6. InnoDB 데이터 파일과 로그 파일의 추가와 삭제

버젼 3.23.50 및 4.0.2 보다 ,InnoDB 의 마지막 데이터 파일에 autoextend (을)를 지정할 수 있게 되었습니다.혹은, 추가의 데이터 파일을 지정해 테이블 스페이스를 확대할 수 있습니다.그러기 위해서는,MySQL 서버를 슛다운 해,my.cnf 파일로 innodb_data_file_path 의 말미 에 새로운 데이터 파일을 추가해,MySQL 서버를 재기동합니다.

현시점에서는,InnoDB (으)로부터 데이터 파일을 삭제할 수 없습니다.데이타베이스의 사이즈를 작게 하려면 ,mysqldump 그리고 모든 테이블을 덤프 해, 새로운 데이타베이스를 작성해, 그 데이타베이스에 테이블을 임포트 할 필요가 있습니다.

InnoDB 로그 파일의 수 또는 사이즈를 변경하는 경우는,MySQL (을)를 슛다운 해, 에러 없게 슛다운 하는 것을 확인할 필요가 있습니다. 그 후에, 슛다운으로 문제가 발생했을 경우에 대비하고, 낡은 로그 파일을 안전한 장소에 카피합니다.이것들은 데이타베이스를 리커버리 할 때에 필요합니다.낡은 로그 파일을 로그 파일 디렉토리로부터 삭제해,my.cnf (을)를 편집하고 나서 MySQL (을)를 다시 기동합니다.기동시에,InnoDB (으)로부터 새로운 로그 파일을 작성한 것이 통지됩니다.

7.5.7. InnoDB 데이타베이스의 백업과 리커버리

안전한 데이타베이스 관리의 비결은, 정기적으로 백업을 취하는 것입니다.

InnoDB 핫 백업은, 가동중의 InnoDB 데이타베이스를 백업하기 위한 온라인 백업 툴입니다.InnoDB 핫 백업에서는, 데이타베이스를 슛다운 할 필요가 없고, 락이 설정되거나 통상의 데이타베이스 처리가 방해 되거나 하기도 없습니다.InnoDB 핫 백업은, 추가로 도입하는 유상의 툴로, 표준의 MySQL 디스트리뷰션에는 포함되어 있지 않습니다.상세 정보와 screen shot에 대해서는,InnoDB 핫 백업의 홈 페이지(http://www.innodb.com/manual.php )(을)를 참조해 주세요.

MySQL 서버를 슛다운 할 수 있는 경우는, 데이타베이스의 ' 바이너리' 백업을 취하기 위해서 다음의 작업을 실시할 필요가 있습니다.

  • MySQL 데이타베이스를 슛다운 해, 그것이 에러 없게 슛다운 하는 것을 확인한다.

  • 모든 데이터 파일을 안전한 장소에 카피한다.

  • 모든 InnoDB 로그 파일을 안전한 장소에 카피한다.

  • my.cnf 옵션 설정 파일을 안전한 장소에 카피한다.

  • InnoDB 테이블의 모든 .frm 파일을 안전한 장소에 카피한다.

상기의 바이너리 백업에 가세하고,mysqldump (을)를 사용해 정기적으로 테이블의 덤프를 취하도록 해 주세요.그 이유는, 바이노리필드가 깨닫기 전에 망가질 가능성이 있기 때문에입니다.덤프 된 테이블은 텍스트 파일에 격납됩니다.이것들은 인간에 의한 해독이 가능하고, 데이타베이스 바이노리필드보다 훨씬 단순합니다.덤프 된 파일에서는 테이블의 파손을 용이하게 확인할 수 있습니다.또, 이 파일의 형식은 단순하기 때문에, 중대한 테이블의 파손이 일어나는 확률도 낮아집니다.

데이타베이스의 바이너리 백업과 동시에 덤프를 취하는 것을 추천합니다.모든 테이블의 snapshot를 모순이 없는 상태로 덤프 하려면 , 모든 클라이언트를 데이타베이스로부터 셧아웃 할 필요가 있습니다.그 후에 바이너리 백업을 취하면, 데이타베이스의 모순이 없는 snapshot를 2 개의 형식에서 보관 유지하게 됩니다.

상기의 바이너리 백업으로부터 InnoDB 데이타베이스를 리커버리 할 수 있도록(듯이) 하려면 ,MySQL 의 일반적인 로그를 온으로 해 MySQL 데이타베이스를 실행할 필요가 있습니다.여기서의 일반적인 로그란,InnoDB 로그와는 관계가 없다 MySQL 서버의 로그 메카니즘을 의미합니다.

MySQL 서버 프로세스의 크래쉬로부터 리커버리 하는 경우에 필요한 작업은, 그 프로세스의 재기동 뿐입니다.InnoDB (은)는 자동적으로 로그를 체크해, 현시점까지의 데이타베이스의 롤 포워드를 실행합니다.InnoDB (은)는, 크래쉬시에 코?~ 트 되어 있지 않았던 트랜잭션(transaction)를 자동적으로 롤백(rollback) 합니다.리커버리의 사이,InnoDB (은)는 다음과 같은 메세지를 출력합니다.

~/mysqlm/sql > mysqld
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: Doing recovery: scanned up to log sequence number 0 13805056
InnoDB: Doing recovery: scanned up to log sequence number 0 13870592
InnoDB: Doing recovery: scanned up to log sequence number 0 13936128
...
InnoDB: Doing recovery: scanned up to log sequence number 0 20555264
InnoDB: Doing recovery: scanned up to log sequence number 0 20620800
InnoDB: Doing recovery: scanned up to log sequence number 0 20664692
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
InnoDB: Starting an apply batch of log records to the database...
InnoDB: Apply batch completed
InnoDB: Started
mysqld: ready for connections

데이타베이스의 파손 또는 디스크 장해가 발생했을 경우는, 백업으로부터 리커버리를 실행할 필요가 있습니다.데이타베이스가 망가졌을 경우는, 우선 망가지지 않은 백업을 찾습니다.MySQL 의 메뉴얼에 따라서,MySQL 의 일반 로그 파일로부터의 리커버리를 실행합니다.

7.5.7.1. 강제적인 리커버리

데이타베이스 페이지가 망가졌을 경우는,SELECT INTO OUTFILE (을)를 사용해 데이타베이스로부터 테이블을 덤프 할 수 있습니다.통상은, 대부분의 데이터가 손상을 받지 않고 정상적인 상태입니다.그런데 , 파손이 원인으로 SELECT * FROM table (이)나 InnoDB 의 백그라운드 처리가 크래쉬 또는 아서트 하거나InnoDB 의 롤 forward recovery마저도 크래쉬 하는 일이 있습니다.InnoDB 의 버젼 3.23.44 보다 ,InnoDB (을)를 강제적으로 기동할 수 있는 옵션이 my.cnf 에 추가되었습니다.또, 테이블을 덤프 할 수 있도록(듯이), 백그라운드 처리가 실행되지 않게 하는 일도 가능해졌습니다.예를 들어,my.cnf 그리고

innodb_force_recovery = 4

(을)를 설정할 수 있습니다.

innodb_force_recovery 의 선택사항은 아래에 올리고 있습니다. 데이타베이스에는, 이러한 옵션을 다른 용도로 사용하지 말아 주세요. InnoDB 그럼, 안전 대책으로서 이 옵션이 0 보다 클 때는 유저가 INSERT ,UPDATE , 또는 DELETE (을)를 실행할 수 없게 되어 있습니다.

버젼 3.23.53 및 4.0.4 보다 , 강제 리커버리가 사용되는 경우에서도, 테이블의 DROP 또는 CREATE (을)를 실행할 수 있습니다.롤백(rollback)로 크래쉬를 일으키고 있는 테이블을 특정할 수 있으면, 그 테이블을 파기할 수 있습니다. 또, 문제가 있는 대량 임포트 또는 ALTER TABLE 하지만 원인으로 폭주한 롤백(rollback)도, 이 방법으로 정?~ 할 수 있습니다. mysqld 프로세스를 강제 종료해,my.cnf 의 옵션 innodb_force_recovery=3 (을)를 사용하는 것으로, 롤백(rollback) 하지 않고 데이타베이스를 정상적인 상태에 되돌릴 수 있습니다. 그 후에, 롤백(rollback)가 폭주하는 원인이 된 테이블을 DROP 그리고 파기합니다.

아래에 열거되고 있는 각 옵션에서는, 그 번호가 큰 것이 보다 작은 번호의 대책을 모두 포함시키고 있습니다.나빠도 옵션 4 그리고 테이블을 덤프 할 수 있으면, 개개의 페이지가 파손해도 일부의 데이터가 없어질 뿐(만큼)이므로 비교적 안전합니다.옵션 6 에는 보다 극적인 영향력이 있습니다.데이타베이스 페이지가 낡은 상태인 채 남기 위해,B 트리나 그 외의 데이타베이스 구조에 한층 더 파손이 미칠 가능성이 있기 때문입니다.

  • 1 (SRV_FORCE_IGNORE_CORRUPT )에서는, 망가진 페이지가 검출되어도 서버가 실행된다.SELECT * FROM table 그리고 망가진 인덱스 레코드나 페이지를 뛰어넘도록 하면, 테이블을 덤프 할 때에 도움이 된다.

  • 2 (SRV_FORCE_NO_BACKGROUND )에서는, 메인스레드가 실행되지 않게 된다.퍼지 시에 크래쉬가 발생하는 경우는, 이 옵션에 의해서 그것이 회피된다.

  • 3 (SRV_FORCE_NO_TRX_UNDO )에서는, 리커버리 후에 트랜잭션(transaction) 롤백(rollback)가 실행되지 않는다.

  • 4 (SRV_FORCE_NO_IBUF_MERGE )에서는, 삽입 버퍼의 머지 조작도 실행되지 않게 된다.이 조작이 크래쉬를 일으키는 경우는, 실행하지 않는 것이 좋다.또, 테이블 통계 정보도 계산하지 않게 한다.

  • 5 (SRV_FORCE_NO_UNDO_LOG_SCAN )에서는, 데이타베이스 기동시에 UNDO 로그가 참조되지 않는다.InnoDB (은)는, 미완료의 트랜잭션(transaction)도 코?~ 트가 끝난 상태로서 취급한다.

  • 6 (SRV_FORCE_NO_LOG_REDO )에서는, 리커버리에 관련해 로그의 롤 포워드가 실행되지 않는다.

7.5.7.2. 체크 포인트

InnoDB 에는, 퍼지 체크 포인트로 불리는 체크 포인트 메카니즘이 실장되고 있습니다.InnoDB (은)는, 변경된 데이타베이스 페이지를 소규모의 배치 단위로 버퍼 풀로부터 플래시 합니다.버퍼 풀을 1 회의 배치로 플래시 할 필요는 없습니다.실제로 이것을 실시하면, 유저의 SQL 스테이트먼트의 처리가 일시적으로 정?~ 합니다.

크래쉬 리커버리 시에,InnoDB (은)는 로그 파일에 써진 체크 포인트 라벨을 검색합니다.InnoDB (은)는, 이 라벨보다 전에 실행된 데이타베이스에의 변경이, 데이타베이스의 디스크 이미지에 벌써 반영되고 있는 것을 인식하고 있습니다. 다음에 InnoDB (은)는, 로그 파일로 이 체크 포인트이?~ (을)를 스캔 해, 로그에 기록된 변경을 데이타베이스에 적용합니다.

InnoDB (은)는 로그 파일에의 기입을 순환적으로 실시합니다. InnoDB 에 의한 리커버리가 필요했을 경우는, 버퍼 풀내의 데이타베이스 페이지와 디스크상의 이미지의 불일치를 일으키고 있는 모든 코?~ 트 끝난 변경을, 로그 파일로부터 취득할 수 없으면 안됩니다.즉,InnoDB (은)는, 로그 파일을 순환적으로 재사용할 때에, 재사용하려고 하는 로그 파일에 기록된 변경이, 디스크상의 데이타베이스 페이지의 이미지에 벌써 반영되고 있는 것을 확인할 필요가 있습니다.그 때문에(위해) InnoDB (은)는 체크 포인트를 작성할 필요가 있어, 거기에는 변경된 데이타베이스 페이지를 디스크에 플래시 하는 처리가 수반합니다.

이러한 일로부터, 로그 파일을 크게 해 두면, 체크 포인트를 실행할 때의 디스크 I/O (을)를 삭감할 수 있다고 말할 수 있습니다.로그 파일의 합계 사이즈를, 버퍼 풀의 사이즈 이상으로 설정하는 것은 리에 필적하고 있습니다. 로그 파일을 크게 했을 경우의 난점으로서 데이타베이스에 적용하는 로그의 양이 증가하기 위해서, 크래쉬 리커버리에 시간이 걸릴 우려가 있습니다.

7.5.8. InnoDB 데이타베이스를 다른 머신으로 이동한다

Windows 그럼,InnoDB 하지만 데이타베이스명과 테이블명을 내부적으로 소문자로 격납합니다.바이너리 형식의 데이타베이스를 Unix (으)로부터 Windows 에, 또는 그 반대로 이동하려면 , 모든 테이블명과 데이타베이스명을 소문자로 할 필요가 있습니다.Unix 그리고 이것을 간단하게 실시하려면 ,my.cnf 의 [mysqld] 섹션에 다음의 행을 추가합니다.

lower_case_table_names=1

이것은, 테이블의 작성을 개시하기 전에 실시합니다.Windows 그럼, 디폴트로 1 (으)로 설정됩니다.

InnoDB 의 데이터 파일과 로그 파일은, 모든 플랫폼에서 binary level compatibility입니다.다만, 그러한 머신으로 부동 소수점수(실수)의 형식이 같다라고 하는 것이 필요합니다. InnoDB 데이타베이스는, 모든 관련 파일을 카피하는 것만으로 이동할 수 있습니다.관련 파일에 대해서는, 데이타베이스의 백업에 관한 전의 섹션을 참조해 주세요.머신간에 부동 소수점수(실수)의 형식이 차이가 나도, 테이블내에서 FLOAT 또는 DOUBLE 데이터형을 사용하고 있지 않으면 순서는 같습니다.즉, 관련 파일을 카피하는 것만으로 끝납니다.부동 소수점수(실수)의 형식이 차이가 나는 경우에, 테이블로 부동 소수점 데이터가 사용되고 있을 때는,mysqldump 및 mysqlimport (을)를 사용해 그러한 테이블을 이동할 필요가 있습니다.

퍼포먼스상의 힌트로서 데이터를 데이타베이스에 임포트 할 때는, 대량의 임포트 트랜잭션(transaction)에 의해서 생성되는 큰 롤백(rollback) 세그먼트(segment)에 대응 가능한 한의 충분한 테이블 스페이스가 있으면 상정하고, 오트코?~ 트모드를 오프로 합니다. 코?~ 트는, 테이블 전체 또는 테이블의 세그먼트(segment)를 임포트 한 후에 실행합니다.

7.5.9. InnoDB 트랜잭션(transaction) 모델과 락

InnoDB 트랜잭션(transaction) 모델의 목표는,마르치바죠닝의 데이타베이스가 뛰어난 특성을, 종래의 2 상락과 조합하는 것이었습니다. InnoDB (은)는, 행 레벨로 락을 실시해, 디폴트에서는 쿼리를 Oracle 식의 비락의 일관성 독해로서 실행합니다. InnoDB 의 락 테이블은 스페이스 효율의 높은 방법으로 격납되기 위해, 락 에스칼레이션은 불필요합니다.일반적으로는, 복수의 유저가 데이타베이스의 모든 레코드 또는 레코드의 랜덤인 부분집합을 잠글 수 있어InnoDB 그리고 메모리 부족이 발생하기도 없습니다.

InnoDB 그럼, 모든 유저 활동이 트랜잭션(transaction)의 내부에서 발생합니다.MySQL 그리고 오트코?~ 트모드가 사용되고 있는 경우는, 각 SQL 스테이트먼트가 1 개의 트랜잭션(transaction)가 됩니다. MySQL (은)는 항상 오트코?~ 트모드를 온으로 해 새로운 접속을 개시합니다.

SET AUTOCOMMIT = 0 그리고 오트코?~ 트모드가 오프가 되면, 유저가 항상 트랜잭션(transaction)를 열고 있다고 보여집니다.이 유저가 SQL 의 COMMIT 또는 ROLLBACK 스테이트먼트를 실행하면, 현재의 트랜잭션(transaction)가 종료해, 새로운 트랜잭션(transaction)가 개시됩니다.어느 쪽의 스테이트먼트도, 현재의 트랜잭션(transaction)로 설정된 모든 InnoDB 락을 해제합니다.COMMIT (을)를 실행하면, 현재의 트랜잭션(transaction)로 더해진 변경이 확정해, 다른 유저가 인식할 수 있는 상태가 됩니다.한편,ROLLBACK 스테이트먼트를 실행하면, 현재의 트랜잭션(transaction)에 의해서 더해진 모든 변경이 삭제됩니다.

접속에 AUTOCOMMIT = 1 하지만 설정되어 있는 경우에서도, 유저는 트랜잭션(transaction)를 실행할 수 있습니다.그 경우,START TRANSACTION 또는 BEGIN 그리고 트랜잭션(transaction)를 개시해,COMMIT 또는 ROLLBACK 그리고 트랜잭션(transaction)를 종료합니다.

7.5.9.1. InnoDB (와)과 SET ... TRANSACTION ISOLATION LEVEL ...

SQL-92 의 트랜잭션(transaction) 분리 레벨에 관한 InnoDB 의 디폴트는 REPEATABLE READ 입니다. 버젼 4.0.5 보다 ,InnoDB 하 SQL-92 표준으로 기술되고 있다 4 종류의 트랜잭션(transaction) 분리 레벨을 모두 제공하게 되었습니다. my.cnf 의 [mysqld] 섹션으로, 모든 접속에 대한 디폴트의 분리 레벨을 설정할 수 있습니다.

transaction-isolation = {READ-UNCOMMITTED | READ-COMMITTED
                         | REPEATABLE-READ | SERIALIZABLE}

유저는, 단일 세션의 분리 레벨 또는 새롭게 접속하는 모든 connection의 분리 레벨을,SET TRANSACTION 스테이트먼트로 변경할 수 있습니다.그 구문은 다음과 같습니다.

SET [SESSION | GLOBAL] TRANSACTION ISOLATION LEVEL
                       {READ UNCOMMITTED | READ COMMITTED
                        | REPEATABLE READ | SERIALIZABLE}

SQL 구문에서는 레벨명에 하이픈을 붙이지 않는 것에 주의해 주세요.

디폴트의 동작으로서 다음의( 아직 개시되어 있지 않다) 트랜잭션(transaction)의 분리 레벨이 설정됩니다.이 스테이트먼트에 GLOBAL 키워드를 사용하면, 그것이?~ 에 작성되는 모든 새로운 접속(기존의 접속은 대상외)에 대해서 글로벌하게 디폴트의 트랜잭션(transaction) 레벨이 설정됩니다. 이것을 실시하려면 ,SUPER 특권이 필요합니다.SESSION 키워드를 사용하면, 현재의 접속으로 실행되는 모든 새로운 트랜잭션(transaction)에 대해서 디폴트의 트랜잭션(transaction) 레벨이 설정됩니다.어느 클라이언트도, 자유롭게 세션 분리 레벨(트랜잭션(transaction)의 도중에 있어도) 또는 다음의 트랜잭션(transaction)의 분리 레벨을 변경할 수 있습니다. 3.23.50 보다 전의 버젼에서는,InnoDB 테이블에 SET TRANSACTION 하지만 작용하지 않았습니다.4.0.5 보다 전의 버젼에서는,REPEATABLE READ (와)과 SERIALIZABLE 만이 제공되고 있었습니다.

글로벌 및 세션의 트랜잭션(transaction) 분리 레벨은, 다음의 스테이트먼트로 확인할 수 있습니다.

SELECT @@global.tx_isolation;
SELECT @@tx_isolation;

행 레벨 락에서는,InnoDB 하지만 넥스트 키 록을 사용합니다. 즉, 인덱스 레코드에 가세해 인덱스 레코드의 전의 `` 갭'' 도 잠그는 것으로, 다른 유저가 그 인덱스 레코드의 직전에 삽입할 수 없게 합니다.여기서 말하는 넥스트 키 록이란, 인덱스 레코드와 그 전의 갭을 잠그는 락입니다. 갭 락이란, 어느 인덱스 레코드의 전의 갭만을 잠그는 락입니다.

InnoDB 에 있어서의 각 분리 레벨의 자세한 것은 다음과 같습니다.

  • READ UNCOMMITTED `` 더티 리드'' (이)라고도 불린다.락을 취득하지 않는다 SELECT 스테이트먼트가 실행되기 위해, 전의 버젼의 레코드가 참조되지 않는다. 따라서, 이 분리 레벨에서는 ' 일관했다' 독해가 되지 않는다. 그 이외의 경우, 이 레벨은 READ COMMITTED (와)과 같이 기능한다.

  • READ COMMITTED Oracle 에 약간 가까운 분리 레벨. 모든 SELECT ... FOR UPDATE 및 SELECT ... LOCK IN SHARE MODE 스테이트먼트는, 인덱스 레코드만을 잠그어, 그 전의 갭은 락 하지 않는다 .따라서, locked record의 다음에 새로운 레코드를 자유롭게 삽입할 수 있다. 일의의 검색 조건으로 유니크 인덱스를 사용한다 UPDATE 및 DELETE (은)는, 검출한 인덱스 레코드만을 잠그어, 그 전의 갭은 잠그지 않는다. 다만, 범위 지정이 있다 UPDATE 및 DELETE 그럼,InnoDB 하지만 계속 넥스트 키 록 또는 갭 락을 설정해, 그 범위에서 커버되는 갭에 다른 유저가 삽입할 수 없게 할 필요가 있다.이것은,MySQL 의 replication 및 리커버리가 기능하도록(듯이),`` 팬텀(환상) 행'' (을)를 블록 해야 하기 때문에이다. 일관성 독해 (은)는,Oracle (와)과 같이 동작한다.즉, 일관성 독해에서는, 같은 트랜잭션(transaction)내에서 만나도, 최신의 snapshot가 독자적으로 설정되어 읽어내진다.

  • REPEATABLE READ InnoDB 의 디폴트의 분리 레벨. SELECT ... FOR UPDATE, SELECT ... LOCK IN SHARE MODE, 일의의 검색 조건으로 유니크 인덱스를 사용한다 UPDATE 및 DELETE (은)는, 검출한 인덱스 레코드만을 잠그어, 그 전의 갭은 잠그지 않는다. 그 이외의 경우는, 이러한 조작으로 넥스트 키 록(다음의 키로 스캔 되는 인덱스의 범위를 락) 또는 갭 락이 사용되어 다른 유저에 의한 새로운 삽입이 블록 된다. 독해 일관성 에는, 전의 분리 레벨과의 사이에 중요한 차이가 있다.이 레벨에서는, 같은 트랜잭션(transaction)내의 모든 일관한 독해가, 최초의 독해로 확립된 snapshot를 읽어낸다.이 규칙에 의해서, 같은 트랜잭션(transaction)내에서 복수의 단순한 SELECT 스테이트먼트를 발행했을 경우에, 그러한 SELECT 스테이트먼트도 서로 일관한 상태가 된다.

  • SERIALIZABLE 전의 분리 레벨을 닮아 있지만, 단순한 SELECT 스테이트먼트가 모두 암묵적으로 SELECT ... LOCK IN SHARE MODE 에 변환된다.

7.5.9.2. 락을 취득하지 않는 독해 일관성

독해 일관성이란,InnoDB 하지만 그마르치바죠닝 기능을 사용하고, 어떤 시점으로의 데이타베이스의 snapshot를 쿼리에 제시하는 것을 의미합니다. 쿼리에는, 그 시점보다 전에 코?~ 트 된 트랜잭션(transaction)에 의한 변경만이 나타나 그 시점에서(보다) 후의 트랜잭션(transaction) 또는 코?~ 트 되어 있지 않은 트랜잭션(transaction)에 의한 변경은 나타나지 않습니다.예외로서 쿼리를 발행한 트랜잭션(transaction) 자체에 의한 변경은 쿼리에 나타납니다.

디폴트의 REPEATABLE READ 분리 레벨로 실행하고 있는 경우는, 최초의 독해 내용이 스납쇼트로서 보존되어 같은 트랜잭션(transaction)내의 모든 독해로, 그 snapshot로부터 내용이 읽어내집니다.보다 새로운 상태에 갱신하려면 , 현재의 트랜잭션(transaction)를 코?~ 트 해, 그 후에 새로운 쿼리를 발행합니다.

독해 일관성은 디폴트의 모드입니다.이 모드에서는,InnoDB 하지만 SELECT 스테이트먼트를 READ COMMITTED 및 REPEATABLE READ 분리 레벨로 처리합니다.독해 일관성에서는, 액세스 하는 테이블에 일절 락이 설정되지 않습니다.이 때문에, 독해 일관성이 테이블로 실행되고 있을 때도, 다른 유저는 이러한 테이블을 자유롭게 변경할 수 있습니다.

7.5.9.3. 락을 취득하는 독해 SELECT ... FOR UPDATE 및 SELECT ... LOCK IN SHARE MODE

독해 일관성은, 상황에 따라서는 불편한 경우가 있습니다. 테이블 CHILD 에 새로운 레코드를 추가하기 위해서, 테이블 PARENT 안에 이 아이 레코드의 부모가 벌써 존재하는 것을 확인한다고 합니다.

만일, 독해 일관성으로 테이블 PARENT (을)를 읽어내, 이 테이블로 아이 레코드의 부모의 존재를 확인했다고 합니다.이것으로 테이블 CHILD 에 아이 레코드를 확실히 추가할 수 있을까요.할 수 없습니다.이 처리동안에 다른 유저가 테이블 PARENT (으)로부터 친레코드를 삭제해도 깨닫지 못하기 때문입니다.

이것에 대처하려면 , 공유 락 모드 LOCK IN SHARE MODE 그리고 SELECT 문장을 실행합니다.

SELECT * FROM PARENT WHERE NAME = 'Jones' LOCK IN SHARE MODE;

공유 모드로 독해를 실행하면, 입수 가능한 최신의 데이터가 읽어내지고 읽어낸 레코드에 공유 모드 락이 설정됩니다. 그 최신 데이터가, 다른 유저의 아직 코?~ 트 되어 있지 않은 트랜잭션(transaction)에 속하고 있는 경우는, 그 트랜잭션(transaction)가 코?~ 트 될 때까지 대기합니다. 공유 모드 락에 의해서, 읽어낸 레코드는 다른 유저로부터 갱신 또는 삭제되지 않게 됩니다.상기의 쿼리로부터 부모이다 'Jones' 하지만 돌려주어진 것을 확인한 데다가, 테이블 CHILD 에 'Jones' 의 아이 레코드를 확실히 추가해, 트랜잭션(transaction)를 코?~ 트 할 수 있습니다. 이 예는, 어플리케이션 코드로 참조 정합성을 실장하는 방법을 나타내고 있습니다.

다른 예를 봅시다.테이블 CHILD_CODES 에 정수의 카운터 필드가 있습니다.이 테이블은, 테이블 CHILD 에 추가하는 각 자에게 일의의 식별자를 할당하기 위해서 사용합니다. 이 카운터의 현재의 값을 읽어내는 경우에, 독해 일관성 또는 공유 모드 독해가 적합하지 않는 것은 분명합니다.이것은, 데이타베이스의 2 사람의 유저에게 같은 카운터치가 돌려주어지기 위해서, 테이블에 같은 식별자를 가진다 2 살의 아이를 추가하게 되어, 중복 키 에러가 발생하기 (위해)때문입니다.

이 경우, 카운터의 독해와 인크리먼트(increment)를 실장하는 방법이 2 개 있습니다.(1 ) 카운터를 먼저 1 증가하고 나서 읽어내는 방법과(2 ) 카운터를 먼저 락 모드 FOR UPDATE 그리고 읽어내고 나서 인크리먼트(increment) 하는 방법입니다.

SELECT COUNTER_FIELD FROM CHILD_CODES FOR UPDATE;
UPDATE CHILD_CODES SET COUNTER_FIELD = COUNTER_FIELD + 1;

SELECT ... FOR UPDATE 그럼, 입수 가능한 최신의 데이터가 읽어내지고 읽어낸 각 레코드에 배타 락이 설정됩니다. 따라서, 검색되었다 SQL UPDATE 하지만 레코드로 설정하는 락과 같은 락이 설정됩니다.

7.5.9.4. 넥스트 키 록: 팬텀의 문제의 회피

InnoDB (은)는, 행 레벨의 락으로 넥스트 키 록으로 불리는 알고리즘을 사용합니다. InnoDB 하지만 행 레벨 락을 실시하는 것은, 테이블의 인덱스를 검색 또는 스캔 할 때에, 검출한 인덱스 레코드에 공유 락 또는 배타 락을 설정하기 (위해)때문입니다.이 때문에, 행 레벨 락은 정확하게는 인덱스 레코드 락으로 불립니다.

InnoDB 하지만 인덱스 레코드로 설정하는 락은, 그 인덱스 레코드의 전의 ' 갭' 에도 영향을 줍니다.어느 유저가 인덱스의 레코드 R 에 공유 락 또는 배타 락을 설정하면, 다른 유저는 인덱스순서로 R 의 직전에 새로운 인덱스 레코드를 삽입할 수 없게 됩니다. 이러한 갭의 락에는, 이른바 팬텀의 문제를 회피하는 목적이 있습니다.예를 들어, 테이블 CHILD (으)로부터 100 보다 크다 ID (을)를 가지는 모든 레코드를 읽어내 잠그어, 선택한 레코드에 대해서 필드를 갱신한다고 합니다.

SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;

테이블 CHILD 의 컬럼 ID 에 인덱스가 있다고 합니다.쿼리에서는,ID 하지만 100 보다 큰 최초의 레코드로부터 순서에 그 인덱스가 스캔 됩니다. 여기서, 인덱스 레코드로 설정된 락이 갭으로 행해지는 삽입을 록아웃 하지 않으면 테이블에 새로운 레코드가 삽입될 가능성이 있습니다.그 경우에, 트랜잭션(transaction)로 다음의 스테이트먼트를 한번 더 실행해 보겠습니다.

SELECT * FROM CHILD WHERE ID > 100 FOR UPDATE;

그러자(면), 쿼리로부터 돌려주어지는 결과 세트에 새로운 레코드가 포함되게 됩니다. 이것은, 트랜잭션(transaction)의 분리의 원칙에 반합니다. 즉, 트랜잭션(transaction)의 실행중은, 읽어낸 데이터가 변화하지 않는 것이 필요합니다.1조의 레코드를 1 개의 데이터 항목으로 보면, 새로운 ' 팬텀의' 레코드에 의해서, 이 분리의 원칙이 찢어지게 됩니다.

InnoDB 그럼, 인덱스를 스캔 할 때에, 인덱스내의 마지막 레코드의 뒤의 갭도 잠글 수 있습니다.전의 예와 같게,InnoDB 하지만 설정한 락에 의해서, 테이블내의 ID 하지만 100 보다 큰 개소에의 삽입이 방?~ 됩니다.

넥스트 키 록을 사용하고, 어플리케이션에 일의성의 체크를 실장할 수 있습니다.공유 모드로 데이터를 읽어내, 삽입하려고 하는 레코드에 중복을 볼 수 있지 않으면, 레코드를 확실히 삽입할 수 있습니다.또, 독해중은 대상이 되는 레코드의 후속의 레코드에 넥스트 키 록이 설정되고, 제삼자에 의한 중복 레코드의 삽입을 막습니다.이와 같이, 넥스트 키 록에 의해서, 테이블내에 존재하지 않는 것을 ' 락' 할 수 있습니다.

7.5.9.5. InnoDB 그리고 각종 SQL 스테이트먼트에 의해서 설정되는 락

  • SELECT ... FROM ...: 독해 일관성.데이타베이스의 snapshot를 읽어내, 락을 설정하지 않는다.

  • SELECT ... FROM ... LOCK IN SHARE MODE: 독해로 검출된 모든 인덱스 레코드에 공유 넥스트 키 록을 설정한다.

  • SELECT ... FROM ... FOR UPDATE: 독해로 검출된 모든 인덱스 레코드에 배타 넥스트 키 록을 설정한다.

  • INSERT INTO ... VALUES (...): 삽입된 레코드에 배타 락을 설정한다.이 락은 넥스트 키 록은 아니기 때문에, 삽입된 레코드의 전의 갭에 다른 유저가 레코드를 삽입할 가능성이 있다.중복 키 에러가 발생했을 경우는, 중복 하는 인덱스 레코드에 공유 락을 설정한다.

  • INSERT INTO T SELECT ... FROM S WHERE ...: T 에 삽입된 각 레코드에 배타(비넥스트 키) 락을 설정한다.독해 일관성으로서 S (을)를 검색하지만,MySQL 로그가 온이 되어 있는 경우는,S 에 공유 넥스트 키 록을 설정한다.후자의 경우에 InnoDB 하지만 락을 설정하는 이유는, 백업으로부터의 롤 forward recovery로, 모든 SQL 스테이트먼트를 원래의 조작과 완전히 똑같이 실행할 필요가 있기 때문에 있다.

  • CREATE TABLE ... SELECT ...: 전의 항목과 같게,SELECT (을)를 일관성이 있는 독해로서 또는 공유 락을 설정해 실행한다.

  • REPLACE (은)는, 유니크 키로 충돌이 없으면, 삽입과 같이 실행된다.충돌이 있는 경우는, 갱신 대상의 레코드에 배타 넥스트 키 록이 설정된다.

  • UPDATE ... SET ... WHERE ...: 검색으로 검출된 모든 레코드에 배타 넥스트 키 록을 설정한다.

  • DELETE FROM ... WHERE ...: 검색으로 검출된 모든 레코드에 배타 넥스트 키 록을 설정한다.

  • 테이블에 FOREIGN KEY 제약이 정의되고 있는 경우는, 제약 조건의 체크를 필요로 하는 모든 삽입, 갱신, 삭제에 의해서, 제약 체크를 위해서 참조하는 레코드에 공유행 레벨의 락이 설정된다.또, 제약이 실패했을 경우도,InnoDB 에 의해서 이러한 락이 설정된다.

  • LOCK TABLES ... : 테이블 락을 설정한다.이러한 락은, 실장시에 MySQL 의 코드 레이어에 의해서 설정된다.InnoDB 의 자동 데드 록 검출에서는, 이러한 테이블 락이 관계하는 데드 록을 검출할 수 없다. 상세한 것에 대하여는 다음의 섹션을 참조. 또,MySQL 하행 레벨의 락을 인식하지 않기 때문에, 다른 유저가 행 레벨 락을 설정해 있는 테이블상에서 테이블 락을 취득할 수 있다.다만, 거기에 따라 트랜잭션(transaction)의 완전성이 손상될 우려가 있다. See 항7.5.15. 「InnoDB 테이블의 제한 사항」 .

7.5.9.6. 데드 록의 검출과 롤백(rollback)

InnoDB (은)는, 트랜잭션(transaction)의 데드 록을 자동적으로 검출해, 그 트랜잭션(transaction)를 롤백(rollback) 해 데드 록을 회피합니다.버젼 4.0.5 보다 ,InnoDB (은)는 작은 편의 트랜잭션(transaction)를 선택해 롤백(rollback) 하게 됩니다.트랜잭션(transaction)의 사이즈는, 삽입, 갱신, 또는 삭제한 레코드의 수에 의해서 결정됩니다. 4.0.5 보다 전의 버젼의 InnoDB 그럼, 데드 록을 일으키는 락을 요구한 트랜잭션(transaction)를, 항상 롤백(rollback) 하고 있었습니다.

InnoDB (은)는,MySQL 의 LOCK TABLES 스테이트먼트가 설정한 락이 관계하는 데드 록, 또는 InnoDB 이외의 스토리지 엔진으로 설정된 락이 관계하는 데드 록을 검출할 수 없습니다.이러한 상황은,my.cnf 그리고 설정한다 innodb_lock_wait_timeout (을)를 사용해 해결할 필요가 있습니다.

InnoDB 하지만 트랜잭션(transaction)의 완전한 롤백(rollback)을 실행하면, 그 트랜잭션(transaction)의 모든 락이 해제됩니다.그런데 , 에러를 위해서 단일의 SQL 스테이트먼트만이 롤백(rollback) 되면,SQL 하지만 설정한 락의 일부가 보관 유지되는 경우가 있습니다.이것은,InnoDB 하지만 사용하는 행 락의 격납 형식에서는, 락을 설정했다 SQL 스테이트먼트를 나중에 특정할 수 없기 때문입니다.

7.5.9.7. InnoDB (으)로의 독해 일관성의 예

디폴트의 REPEATABLE READ 분리 레벨로 실행하고 있다고 합니다. 일관한 독해( 이 레벨에서는, 통상의 SELECT 스테이트먼트는 읽어내 일관성이 있다) 그럼, 쿼리가 데이타베이스를 참조할 때의 기준이 되는 타임 포인트를,InnoDB (은)는 트랜잭션(transaction)에 할당합니다.이렇게 하고, 타임 포인트를 할당할 수 있었던 후에( 세션마다의 snapshot를 취한 후에) , 다른 트랜잭션(transaction)가 레코드를 삭제해 코?~ 트 했다고 해도, 한 번 읽어낸 내용은 바뀌지 않습니다(트랜잭션(transaction)중의 독해 내용은 같습니다).삽입과 갱신도 같습니다.

할당할 수 있었던 타임 포인트를 먼저 진행하려면, 트랜잭션(transaction)를 코?~ 트 해, 새로운 SELECT (을)를 실행합니다.

이것은, 멀티 버젼 concurrent processing 제어(multi-versioned concurrency control) (으)로 불립니다.

유저 A
유저 B

              SET AUTOCOMMIT=0;      SET AUTOCOMMIT=0;

시간 경과
|             SELECT * FROM t;
|             empty set
|                                    INSERT INTO t VALUES (1, 2);
|
v             SELECT * FROM t;
              empty set
                                     COMMIT;

              SELECT * FROM t;
              empty set;

              COMMIT;

              SELECT * FROM t;
              ---------------------
              |    1    |    2    |
              ---------------------

이와 같이, 유저 B 하지만 삽입한 레코드를 유저 A 하지만 참조할 수 있는 것은,B 하지만 삽입을 코?~ 트 한 다음에,A 하지만 코?~ 트 한 나중이 됩니다.또,A 하지만 자신의 트랜잭션(transaction)를 코?~ 트 한 것으로, 시점이 B 의 코?~ 트보다 먼저 진행됩니다.

데이타베이스의 `` 최신의'' 상태를 참조하려면 , 공유 락을 이용한 독해를 사용할 필요가 있습니다.

SELECT * FROM t LOCK IN SHARE MODE;

7.5.9.8. 데드 록의 대처법

데드 록은 트랜잭션 데이터 베이스에 있어서의 종래부터의 문제입니다만, 일부의 트랜잭션(transaction)를 실행할 수 없어질수록 빈번히 발생하므로 없으면 위험하지는 않습니다.통상은, 어플리케이션을 작성할 때에, 데드 록을 위해서 롤백(rollback) 된 트랜잭션(transaction)를 재발행할 수 있도록 해 둘 필요가 있습니다.

InnoDB (은)는, 자동으로 행 레벨 락을 사용합니다.단일의 레코드를 삽입 또는 삭제할 만한 트랜잭션(transaction)에서도 데드 록이 발생합니다.그것은, 이러한 조작이 실제로는 원자성을 가지는 것이 아니고, 삽입/ 삭제하는 레코드의 인덱스 레코드(어쩌면 복수)에 자동적으로 락을 설정하기 (위해)때문입니다.

데드 록에 대처해, 데드 록의 발생 빈도를 줄이기 위한 방법을 다음에 나타냅니다.

  • MySQL 의 3.23.52 이?~ 또는 4.0.3 이?~ 의 버젼에서는,SHOW INNODB STATUS (을)를 사용해 마지막에 발생한 데드 록의 원인을 특정한다.이것은, 데드 록을 회피하도록(듯이) 어플리케이션을 조정할 때에 도움이 된다.

  • 데드 록으로 실패한 트랜잭션(transaction)를 재발행할 수 있도록 해 둔다.데드 록에는 위험성이 없기 때문에, 단지 재시행하면 좋다.

  • 트랜잭션(transaction)를 빈번히 코?~ 트 한다.작은 트랜잭션(transaction)는 충돌하는 것이 적다.

  • 락을 취득하는 독해 SELECT ... FOR UPDATE 또는 ... LOCK IN SHARE MODE (을)를 사용하고 있는 경우는, 보다 낮은 분리 레벨 READ COMMITTED (을)를 사용해 본다.

  • 테이블과 레코드에는 일정한 순서로 액세스 한다.이것에 의해서, 트랜잭션(transaction)가 정연하게 기다리는 행렬을 형성하게 되어, 데드 록이 발생하지 않게 된다.

  • 적절히 선택된 인덱스를 테이블에 추가한다.이것에 의해서, 쿼리가 스캔 하는 인덱스 레코드의 수, 및 설정하는 락의 수를 삭감할 수 있다. EXPLAIN SELECT (을)를 사용하고,MySQL 하지만 쿼리에 대해서 적절한 인덱스를 선택하는 것을 확인한다.

  • 락의 사용을 줄인다.SELECT 그리고 낡은 snapshot로부터 데이터가 돌려주어져도 상관없는 경우는, 이 스테이트먼트에 FOR UPDATE 마디나 LOCK IN SHARE MODE 마디를 추가하지 않게 한다.이 경우는,READ COMMITTED 분리 레벨을 사용하면 좋다.이 분리 레벨에서는, 같은 트랜잭션(transaction)내가 일관한 독해 각각이 독자적인 새로운 snapshot를 읽어내기 때문이다.

  • 어느 방법에서도 해결하지 않는 경우는, 테이블 레벨의 락 LOCK TABLES t1 WRITE, t2 READ, ... ; [do something with tables t1 and t2 here]; UNLOCK TABLES (을)를 사용해 트랜잭션(transaction)를 직렬화한다. 테이블 레벨의 락에 의해서, 트랜잭션(transaction)가 정연하게 기다리는 행렬에 줄서게 되어, 데드 록이 회피된다.LOCK TABLES (은)는,BEGIN 커멘드와 같게 트랜잭션(transaction)를 암묵적으로 개시해,UNLOCK TABLES (은)는,COMMIT 그리고 트랜잭션(transaction)를 암묵적으로 종료하는 것에 주의한다.

  • 트랜잭션(transaction)를 직렬화하는 이제(벌써) 1 개의 방법으로서 레코드가 1 개 밖에 없는 보조적인 ' semaphore' 테이블을 작성한다.각 트랜잭션(transaction)는, 이 레코드를 갱신하고 나서 다른 테이블에 액세스 한다.이렇게 하고, 모든 트랜잭션(transaction)가 직렬적으로 실행된다. MySQL 의 테이블 레벨 락에서는, 타임 아웃을 사용해 데드 록을 해결할 필요가 있다.

7.5.10. 퍼포먼스 튜닝의 힌트

  1. Unix 의 top 또는 Windows 의 태스크 매니저 그리고 표시된 프로세스의 CPU 사용율이 70% 미만인 경우, 아마 그 프로세스는 디스크 처리이다.트란자크션코?~ 트의 수가 너무 많은지, 버퍼 풀이 너무 작은 것을 생각할 수 있다. 버퍼 풀은 크게 하는 것이 좋지만, 물리 메모리의 80% (을)를 넘지 않게 한다.

  2. 복수의 변경 처리를 1 개의 트랜잭션(transaction)에 정리한다.InnoDB (은)는, 데이타베이스를 변경하는 트랜잭션(transaction)가 코?~ 트 될 때마다 로그를 디스크에 플래시 할 필요가 있다.일반적으로 디스크의 회전 속도는 최고에서도 1 초간에 167 회전(10000rpm 의 규격의 물건의 경우) 이기 위해, 디스크가 operating system를 속이지 않는 이상 코?~ 트의 회수도 같이 1 초간에 167 회에 제한된다.

  3. 최근코?~ 트 된 트랜잭션(transaction)의 일부를 잃어도 상관없는 경우는,my.cnf 의 파라미터 innodb_flush_log_at_trx_commit (을)를 0 (으)로 설정할 수 있다.InnoDB (은)는, 어쨌든 1 초간에 1 회로그를 플래시 하려고 한다.다만, 이 플래시는 보증되지 않는다.

  4. 로그 파일을 버퍼 풀과 같을 정도 크게 한다.InnoDB (은)는, 로그 파일의 끝까지 쓰면, 체크 포인트로 버퍼 풀의 변경된 내용을 디스크에 쓰지 않으면 안 된다.로그 파일이 작으면 불필요하게 몇번이나 디스크에 쓰게 된다.큰 로그 파일의 난점은, 리커버리에 시간이 걸리는 것이다.

  5. log buffer도 크게 할 필요가 있다(8 MB 등).

  6. (3.23.39 이?~ 에 관계) Linux 및 Unix 의 일부의 버젼에서는,Unix 의 fdatasync (이)나 그 외의 유사하는 방법을 사용해 파일을 디스크에 플래시 할 때에, 상당한 시간이 걸린다. InnoDB (은)는, 디폴트로 fdatasync 함수를 사용한다. 데이타베이스에 쓸 때의 퍼포먼스가 불만이면,my.cnf 의 innodb_flush_method (을)를 O_DSYNC (으)로 설정해도 상관없다.다만, 대부분의 시스템에서는 O_DSYNC (분)편이 처리가 늦어진다고 생각된다.

  7. InnoDB 에 데이터를 임포트 할 때는,autocommit 하지만 온(1) (으)로 되어 있지 않은 것을 확인한다.그 경우, 삽입마다 디스크에의 로그의 플래시가 요구된다. SQL 의 단순한 파일 임포트행의 전에 다음의 행을 추가한다.

    SET AUTOCOMMIT=0;

    한층 더 그 후에 다음의 행을 추가한다.

    COMMIT;

    mysqldump 의 옵션 --opt (을)를 사용하면, 상기와 같이 SET AUTOCOMMIT=0; ... COMMIT; 나팔로 둘러싸지 않아도, 덤프 파일을 취득해 InnoDB 테이블에 고속으로 임포트 할 수 있다.

  8. 대량으로 INSERT 할 때의 대규모 롤백(rollback)에 주의한다.InnoDB (은)는, 삽입 버퍼를 사용해 삽입시의 디스크 I/O (을)를 삭감하지만, 대응하는 롤백(rollback)에서는 그러한 메카니즘이 사용되지 않는다.디스크 바운드의 롤백(rollback)에는, 대응하는 삽입의 30 배의 시간이 걸린다.데이타베이스의 프로세스를 강제 종료해도, 데이타베이스 기동시에 재차 롤백(rollback)가 개시되므로 도움이 되지 않는다.롤백(rollback)의 폭주를 회피하려면, 롤백(rollback)가 CPU (와)과 메모리만으로 고속으로 실행되도록(듯이) 버퍼 풀을 확대하는지,InnoDB 데이타베이스 전체를 삭제 할 수 밖에 없다.

  9. 다른 대규모 디스크 바운드의 조작에도 주의한다. DROP TABLE 또는 TRUNCATE (MySQL-4.0 이?~ )(을)를 사용하고 테이블을 비운다.DELETE FROM yourtable (은)는 사용하지 않는다.

  10. 다수의 레코드를 삽입하는 경우는, 복수행의 INSERT (을)를 사용하고, 서버와 클라이언트간의 통신에 걸리는 오버헤드를 경감한다.

    INSERT INTO yourtable VALUES (1, 2), (5, 5);

    이 방법은,InnoDB 뿐만이 아니고 다른 테이블형에 삽입하는 경우에도 유효하다.

7.5.10.1. SHOW INNODB STATUS (와)과 InnoDB 모니터

버젼 3.23.42 보다 ,InnoDB 의 내부 상태에 관한 정보를 출력한다 InnoDB 모니터가 InnoDB 에 짜넣어졌습니다. 버젼 3.23.52 및 4.0.3 보다 ,SQL 커멘드 SHOW INNODB STATUS (을)를 사용하고, 표준 InnoDB 모니터의 출력을 SQL 클라이언트에 수중에 넣을 수 있게 되었습니다. 이 데이터는, 퍼포먼스 튜닝에 도움이 됩니다.mysql 대화형 SQL 클라이언트를 사용하고 있는 경우는, 스테이트먼트의 말미에 있는 세?~ 코론을 \G 에 옮겨놓는 것으로, 출력이 판독하기 쉬워집니다.

SHOW INNODB STATUS\G

InnoDB 모니터의 이제(벌써) 1 개의 사용법으로서 서버 mysqld 의 표준 출력에 InnoDB 모니터로부터 계속적으로 데이터를 쓸 수 있습니다(주의: MySQL 클라이언트에서는 아무것도 출력되지 않습니다). 이 기능을 온으로 하면,InnoDB 모니터는 약 15 초 마다 데이터를 출력하게 됩니다.mysqld (을)를 demon로서 실행하면, 통상은 이 출력이 MySQL datadir 안의 .err 로그에 출력됩니다. 이 데이터는, 퍼포먼스 튜닝에 도움이 됩니다. Windows 그리고 이 출력을 MS-DOS 커멘드 prompt에 리디렉트 하려면 ,MS-DOS 커멘드 prompt로부터 --console 옵션을 지정해 mysqld-max (을)를 실행할 필요가 있습니다.

별도 준비되어 있다 innodb_lock_monitor 그럼,innodb_monitor (으)로 같은 정보에 가세하고, 각 트랜잭션(transaction)가 설정한 락에 관한 정보도 출력됩니다.

출력되는 정보에는, 이하에 관한 데이터가 포함됩니다.

  • 트랜잭션(transaction)의 락의 취득 대기

  • 스레드의 semaphore 대기

  • 보류중의 파일 I/O 요구

  • 버퍼 풀의 통계 정보

  • InnoDB 의 메인스레드의 퍼지 및 삽입 버퍼 머지 활동

InnoDB 모니터는, 다음의 SQL 커멘드로 기동할 수 있습니다.

CREATE TABLE innodb_monitor (a INT) TYPE = innodb;

또, 다음의 커멘드로 정?~ 할 수 있습니다.

DROP TABLE innodb_monitor;

CREATE TABLE 구문은,MySQL SQL 파서를 통해 InnoDB 엔진에 커멘드를 건네주는 수단에 지나지 않습니다.작성된 테이블은 InnoDB 모니터와 완전히 무관계합니다.모니터의 실행중에 데이타베이스를 슛다운 해, 그 다음에 다시 모니터를 기동하는 경우는, 우선 작성한 테이블을 파기하지 않으면 새로운 CREATE TABLE 발행해 모니터를 기동할 수 없습니다. 이 구문은, 장래의 릴리스로 변경될 가능성이 있습니다.

다음에 나타내는 것은,InnoDB 모니터의 출력 샘플입니다.

================================
010809 18:45:06 INNODB MONITOR OUTPUT
================================
--------------------------
LOCKS HELD BY TRANSACTIONS
--------------------------
LOCK INFO:
Number of locks in the record hash table 1294
LOCKS FOR TRANSACTION ID 0 579342744
TABLE LOCK table test/mytable trx id 0 582333343 lock_mode IX

RECORD LOCKS space id 0 page no 12758 n bits 104 table test/mytable index
PRIMARY trx id 0 582333343 lock_mode X
Record lock, heap no 2 PHYSICAL RECORD: n_fields 74; 1-byte offs FALSE;
info bits 0
 0: len 4; hex 0001a801; asc ;; 1: len 6; hex 000022b5b39f; asc ";;
 2: len 7; hex 000002001e03ec; asc ;; 3: len 4; hex 00000001;
...
-----------------------------------------------
CURRENT SEMAPHORES RESERVED AND SEMAPHORE WAITS
-----------------------------------------------
SYNC INFO:
Sorry, cannot give mutex list info in non-debug version!
Sorry, cannot give rw-lock list info in non-debug version!
-----------------------------------------------------
SYNC ARRAY INFO: reservation count 6041054, signal count 2913432
4a239430 waited for by thread 49627477 op. S-LOCK file NOT KNOWN line 0
Mut ex 0 sp 5530989 r 62038708 sys 2155035;
rws 0 8257574 8025336; rwx 0 1121090 1848344
-----------------------------------------------------
CURRENT PENDING FILE I/O'S
--------------------------
Pending normal aio reads:
Reserved slot, messages 40157658 4a4a40b8
Reserved slot, messages 40157658 4a477e28
...
Reserved slot, messages 40157658 4a4424a8
Reserved slot, messages 40157658 4a39ea38
Total of 36 reserved aio slots
Pending aio writes:
Total of 0 reserved aio slots
Pending insert buffer aio reads:
Total of 0 reserved aio slots
Pending log writes or reads:
Reserved slot, messages 40158c98 40157f98
Total of 1 reserved aio slots
Pending synchronous reads or writes:
Total of 0 reserved aio slots
-----------
BUFFER POOL
-----------
LRU list length 8034
Free list length 0
Flush list length 999
Buffer pool size in pages 8192
Pending reads 39
Pending writes: LRU 0, flush list 0, single page 0
Pages read 31383918, created 51310, written 2985115
----------------------------
END OF INNODB MONITOR OUTPUT
============================
010809 18:45:22 InnoDB starts purge
010809 18:45:22 InnoDB purged 0 pages

이 출력을 따라가는 개인가의 주석이 있습니다.

  • LOCKS HELD BY TRANSACTIONS 섹션에 락 대기가 보고되고 있는 경우는, 어플리케이션으로 락이 경합 하고 있을 우려가 있다.이 출력으로부터, 트랜잭션(transaction)의 데드 록의 원인을 추적할 수도 있다.

  • univ.i 에 UNIV_SYNC_DEBUG (을)를 정의해 InnoDB (을)를 컴파일 하면,SYNC INFO 섹션에 예약 끝난 semaphore가 보고된다.

  • SYNC ARRAY INFO 섹션에는, semaphore를 기다리고 있는 스레드와 스레드가 스핀 또는 상호 배타 락(mutex) (이)나 읽고 쓰기 락으로의 대기를 필요로 한 회수에 관한 통계 정보가 보고된다.다수의 스레드가 semaphore를 기다리고 있는 경우는, 디스크 I/O 또는 InnoDB 내부의 경합이 원인이 되고 있을 가능성이 있다.경합의 원인으로서는, 다수의 쿼리를 병행해 처리하고 있는지, operating system로의 스레드의 스케줄링에 문제가 있는 것을 생각할 수 있다.

  • CURRENT PENDING FILE I/O'S 섹션에는, 보류중의 파일 I/O 요구가 열거된다.이 수가 많은 경우는, 작업 부하가 디스크 I/O 바운드인 것을 나타내고 있다.

  • BUFFER POOL 섹션에는, 읽고 쓰기된 페이지에 관한 통계 정보가 나타난다.이러한 수치로부터, 쿼리가 현재 실행하고 있는 데이터 파일 I/O 의 회수를 계산할 수 있다.

7.5.11. 마르치바죠닝의 실장

InnoDB (은)는마르치바죠닝의 데이타베이스이기 위해, 테이블 스페이스내의 낡은 버젼의 레코드에 관한 정보를 보관 유지하지 않으면 안됩니다.이 정보는, 롤백(rollback) 세그먼트(segment)에 격납됩니다. 롤백(rollback) 세그먼트(segment)는 Oracle 의 롤백(rollback) 세그먼트(segment)의 데이터 구조를 닮아 있습니다.

InnoDB (은)는 내부적으로, 데이타베이스에 격납되고 있는 각 레코드에 2 개의 필드를 부가합니다. 6 아르바이트의 필드에는, 레코드를 마지막으로 삽입 또는 갱신한 트랜잭션(transaction)의 식별자가 기록됩니다( 트랜잭션(transaction) ID) .삭제도 내부적으로는 갱신으로서 다루어져 레코드내의 특별한 비트에 삭제가 끝난 상태로서 마크 됩니다.각 레코드에는, 롤 포인터로 불린다 7 아르바이트의 필드도 부가됩니다.롤 포인터는, 롤백(rollback) 세그먼트(segment)에 써진 취소 로그 레코드를 가리킵니다.레코드가 갱신되었을 경우는, 갱신전의 레코드의 내용을 재구축 하기 위해서 필요한 정보가 취소해 로그 레코드에 기록됩니다.

InnoDB (은)는, 롤백(rollback) 세그먼트(segment)내의 정보를 사용하고, 트랜잭션(transaction)의 롤백(rollback)로 필요한 취소 조작을 실행합니다.또, 독해 일관성을 위해서, 이전의 버젼의 레코드를 구축하는 경우에도, 이 정보가 사용됩니다.

롤백(rollback) 세그먼트(segment)내의 UNDO 로그는, 삽입용의 UNDO 로그와 갱신용의 UNDO 로그로 나누어져 있습니다.삽입용의 UNDO 로그는, 트랜잭션(transaction) 롤백(rollback)에게만 필요하고, 트랜잭션(transaction)가 코?~ 트 되면 즉시 파기됩니다.갱신용의 UNDO 로그는, 독해 일관성에서도 사용되기 위해,InnoDB 하지만 snapshot를 할당한 트랜잭션(transaction)가 존재하지 않게 될 때까지 파기할 수 없습니다.이러한 트랜잭션(transaction)에서는, 독해 일관성으로 이전의 버젼의 레코드를 구축하기 위해서, 갱신용의 UNDO 로그의 정보가 필요한 경우가 있기 때문입니다.

트랜잭션(transaction)는 정기적으로 코?~ 트 할 필요가 있습니다.독해 일관성이 있는 것만을 발행하는 트랜잭션(transaction)도 같습니다. 그렇게 하지 않으면InnoDB 하지만 갱신용 UNDO 로그로부터 데이터를 파기할 수 없게 되어, 롤백(rollback) 세그먼트(segment)가 커지고, 테이블 스페이스가 가득 찰 우려가 있습니다.

롤백(rollback) 세그먼트(segment)에 있어서의 UNDO 로그 레코드의 물리 사이즈는, 통상, 대응하는 삽입 레코드 또는 갱신 레코드보다 작아집니다.롤백(rollback) 세그먼트(segment)에 필요한 영역을, 이러한 레코드장을 사용하고, 계산할 수 있습니다.

이마르치바죠닝의 기본 구상에서는,SQL 스테이트먼트로 레코드를 삭제해도, 빨리는 그 레코드가 데이타베이스로부터 물리적으로 삭제되지 않습니다. 삭제에 대해서 써진 갱신 취소 로그 레코드를 InnoDB 하지만 파기할 수 있게 된 시점에서, 대응하는 레코드와 그 인덱스 레코드가 데이타베이스로부터 물리적으로 삭제됩니다.이 삭제 조작은 퍼지로 불립니다.이 조작은 극히 고속으로 , 통상은 삭제를 실시했다 SQL 스테이트먼트와 동일한 정도의 시간 밖에 걸리지 않습니다.

7.5.12. 테이블과 인덱스의 구조

MySQL (은)는, 테이블의 데이터 딕쇼내리 정보를, 데이타베이스 디렉토리내의 .frm 파일에 보존합니다.그런데 ,InnoDB 형태의 테이블은, 테이블 스페이스내의 InnoDB 내부 데이터 딕쇼내리에도 독자적인 엔트리를 가지고 있습니다.MySQL (은)는, 테이블이나 데이타베이스를 파기할 경우에,.frm 파일 및 InnoDB 데이터 딕쇼내리내의 대응하는 엔트리의 양쪽 모두를 삭제할 필요가 있습니다. 이 때문에, 단지 .frm 파일을 이동하는 것 만으로는 데이타베이스간에 InnoDB 테이블을 이동할 수 없습니다.또,MySQL 3.23.43 이하의 버젼으로 InnoDB 형태의 테이블이 있으면 DROP DATABASE 하지만 기능하지 않았던 것도 이것이 원인입니다.

모든 InnoDB 테이블에는, 쿠라스타드인젝스로 불리는, 레코드의 데이터를 격납하는 특별한 인덱스가 있습니다.테이블로 PRIMARY KEY (을)를 정의하면, 주키의 인덱스가 쿠라스타드인젝스가 됩니다.

테이블에 주키를 정의하지 않는 경우는,InnoDB 에 의해서 내부적으로 쿠라스타드인젝스가 작성되어 거기서 InnoDB 하지만 테이블내의 레코드에 할당하는 로 ID 의 순서에 레코드를 늘어놓을 수 있습니다.로 ID 하 6 아르바이트의 필드에서, 새로운 레코드가 삽입되면 단순하게 수가 증가해 갈 것입니다.따라서, 로 ID 의 순서에 늘어놓을 수 있었던 레코드는, 물리적으로 삽입된 순서로 나란해지게 됩니다.

쿠라스타드인젝스를 개입시킨 레코드에의 액세스는 신속합니다.이것은, 인덱스 검색을 하는 페이지에 레코드 데이터가 배치되기 (위해)때문입니다.다른 많은 데이타베이스에서는, 데이터가 인덱스 레코드와는 다른 페이지에 전통적으로 격납되고 있습니다.일반적으로, 테이블이 큰 경우는, 쿠라스타드인젝스가 종래의 방법보다 디스크 I/O 하지만 적게 됩니다.

InnoDB 그럼, 비쿠라스타드인젝스(세칸다리인젝스라고도 불린다)의 레코드에 레코드의 주키치가 포함되어 있습니다.InnoDB (은)는 이 주키치를 사용하고, 쿠라스타드인젝스로부터 레코드를 검색합니다.주키가 길면 세칸다리인젝스의 사용하는 영역이 증가하는 것에 주의해 주세요.

7.5.12.1. 인덱스의 물리 구조

InnoDB 의 모든 인덱스는 B 트리로, 인덱스의 레코드는 트리의 리프 페이지에 격납됩니다.인덱스 페이지의 디폴트 사이즈는 16 KB 입니다.새로운 레코드가 삽입되면,InnoDB (은)는 페이지의 1/16 (을)를, 장래의 인덱스 레코드의 삽입이나 갱신에 대비해 비우려고 합니다.

인덱스 레코드가 시퀀셜(승순 또는?~ 순서)에 삽입되면, 인덱스 페이지의 약 15/16 까지가 가득 찹니다. 레코드가 랜덤에 삽입되었을 경우는, 페이지의 1/2 ~ 15/16 까지가 가득 찹니다.인덱스 페이지의 사용 용량이 1/2 미만이 되면,InnoDB (은)는 인덱스 트리를 축소해 페이지를 해방하려고 합니다.

7.5.12.2. 삽입 버퍼

데이타베이스 어플리케이션에서는, 주키가 일의의 식별자이며, 새로운 레코드가 주키의 승순으로 삽입되는 것이 일반적입니다.따라서, 쿠라스타드인젝스에의 삽입에서는, 디스크로부터의 랜덤인 독해를 필요로 하지 않습니다.

한편, 세칸다리인젝스는 통상 일의가 아니고, 세칸다리인젝스에의 삽입은 비교적 랜덤에 행해집니다. 이 때문에,InnoDB 그리고 특별한 메카니즘이 사용되는 일 없이, 다수의 랜덤인 디스크 I/O 하지만 발생합니다.

일의가 아닌 세칸다리인젝스에 인덱스 레코드가 삽입되는 경우는, 세칸다리인젝스페이지가 벌써 버퍼 풀내에 있을지가 InnoDB 에 의해서 체크됩니다.벌써 있는 경우는,InnoDB 에 의해서 인덱스 페이지에 직접 레코드가 삽입됩니다.버퍼 풀내에 인덱스 페이지가 없었던 경우는,InnoDB 에 의해서 특별한 삽입 버퍼 구조에 레코드가 삽입됩니다. 삽입 버퍼는, 그 전체가 버퍼 풀내에 들어가도록(듯이) 작게 되어 있기 위해, 이 버퍼에의 삽입은 극히 고속으로.

삽입 버퍼는, 데이타베이스내의 세칸다리인젝스트리에 정기적으로 머지 됩니다.인덱스 트리의 같은 페이지상에서 복수의 삽입을 머지 하는 것으로, 디스크 I/O (을)를 삭감할 수 있습니다. 삽입 버퍼에 의해서 테이블에의 삽입 속도가 최대 15 배에 높일 수 있는 것이 측정되고 있습니다.

7.5.12.3. 해시 인덱스

데이타베이스의 거의 전체가 메인 메모리내에 들어가는 경우에, 그 데이타베이스로 가장 빠르게 쿼리를 실행하려면 , 해시 인덱스를 사용합니다.InnoDB 에는, 테이블에 정의된 인덱스로 실행되는 검색을 감시하는 메카니즘이 있어, 해시 인덱스의 구축이 쿼리에 있어서 유익하다라고 InnoDB 하지만 판단했을 경우는, 자동적으로 그 인덱스가 구축됩니다.

다만, 해시 인덱스는 항상 테이블에 존재한다 B 트리 인덱스를 기본으로 구축되므로 주의가 필요합니다. InnoDB (은)는,B 트리 인덱스상에서 검출한 검색 패턴에 따르고, 임의의 길이의 키(B 트리에 정의된 키) 의 선두 부분에, 해시 인덱스를 구축할 수 있습니다. 해시 인덱스는 부분적이어도 괜찮습니다.즉,B 트리 인덱스 전체를 버퍼 풀에 캐쉬할 필요는 없습니다.InnoDB (은)는, 빈번히 액세스 되는 인덱스 페이지로의 요구에 따라 해시 인덱스를 구축합니다.

어떤 의미로는, 유연한 해시 인덱스의 메카니즘을 사용하고,InnoDB 하지만 충분히 여유가 있는 메인 메모리에 적응하는 것으로, 메인 메모리 데이타베이스의 아키텍쳐에 가까워지고 있습니다.

7.5.12.4. 물리적인 레코드 구조

  • InnoDB 안의 각 인덱스 레코드에는,6 아르바이트의 헤더가 포함된다.이 헤더는, 연속하는 레코드를 링크하기 위해(때문에)와 행 레벨 락으로 사용된다.

  • 쿠라스타드인젝스내의 레코드에는, 모든 유저 정의 컬럼의 필드가 포함된다.이것에 가세하고, 트랜잭션(transaction) ID 용무의 6 아르바이트의 필드와 롤 포인터용의 7 아르바이트의 필드가 1 개씩 포함되어 있다.

  • 유저가 테이블에 주키를 정의하고 있지 않는 경우는, 쿠라스타드인젝스의 각 레코드에 6 아르바이트의 로 ID 필드도 추가된다.

  • 세칸다리인젝스의 각 레코드에는, 쿠라스타드인젝스키에 대해서 정의된 모든 필드도 포함된다.

  • 레코드에는, 그 레코드의 각 필드에의 포인터도 포함된다. 레코드내의 필드장의 합계가 128 아르바이트 미만의 경우는 포인터가 1 아르바이트,128 아르바이트 이상의 경우는 포인터가 2 아르바이트가 된다.

7.5.12.5. InnoDB (으)로의 AUTO_INCREMENT 컬럼의 구조

데이타베이스 기동 후에, 오토 인크리먼트(increment) 컬럼이 정의된 테이블 T 에 유저가 최초로 삽입을 실시할 때에 그 컬럼에 명시적으로 값을 지정하지 않았던 경우는,InnoDB 에 의해서 SELECT MAX(auto-inc-column) FROM T 하지만 실행되어 그 결과의 값에 1 (을)를 더한 값이, 이 컬럼 및 테이블의 오토 인크리먼트(increment) 카운터에 할당할 수 있습니다. 이것을, 「테이블 T 의 오토 인크리먼트(increment) 카운터가 초기화되었다」라고 표현합니다.

InnoDB (은)는, 새롭게 작성된 테이블에 대한 오토 인크리먼트(increment) 카운터의 초기화로, 이것과 같은 순서를 실행합니다.

유저가 삽입시에 오토 인크리먼트(increment) 컬럼에 값 0 (을)를 지정하면,InnoDB (은)는 값이 지정되지 않았던 것으로 하고 레코드를 취급하는 것에 주의해 주세요.

오토 인크리먼트(increment) 카운터가 초기화된 후에, 유저가 오토 인크리먼트(increment) 컬럼의 값을 명시적으로 지정해 레코드를 삽입했을 때, 그 값이 현재의 카운터치보다 큰 경우는, 카운터는 지정된 값으로 설정됩니다.유저가 값을 명시적으로 지정하지 않았던 경우는,InnoDB 에 의해서 카운터가 1 개증가되어 그 새로운 값을 컬럼이 할당할 수 있습니다.

카운터로부터 값을 할당할 수 있을 때는, 오토 인크리먼트(increment)의 메카니즘에 의해서, 락과 트랜잭션(transaction)의 처리가 생략 됩니다.이 때문에, 카운터로부터 수치를 취득한 트랜잭션(transaction)를 롤백(rollback) 하면, 수치의 순서에 차이가 생기기도 합니다.

유저가 오토 인크리먼트(increment) 컬럼에 부의 값을 지정했을 경우, 또는, 정수형에 격납할 수 있는 최대의 정수치보다 큰 값을 지정했을 경우의, 오토 인크리먼트(increment)의 동작은 정의되고 있지 않습니다.

7.5.13. 파일 영역의 관리와 디스크 I/O

7.5.13.1. 디스크 I/O

InnoDB (은)는, 디스크 I/O 그리고 비동기 I/O (을)를 사용합니다.Windows NT 그럼, operating system가 제공하는 네이티브의 비동기 I/O 하지만 사용됩니다. Unix 그럼,InnoDB 에 짜넣어진 유사적인 비동기 I/O 하지만 사용됩니다.InnoDB (은)는, 다수의 I/O 스레드를 작성하고, 예측등의 I/O 조작에 대응합니다.장래의 버젼에서는,Windows NT 의 유사 aio , 및 Unix 의 네이티브 aio (장비되고 있는 경우)(이)가 추가로 서포트되게 됩니다.

Windows NT 그럼,InnoDB (은)는 버퍼 없음의 I/O (을)를 사용합니다.즉,InnoDB 하지만 읽고 쓰기하는 디스크 페이지가, operating system의 파일 캐쉬에 버퍼 되지 않습니다.이것에 의해서, 메모리의 사용 대역폭을 어느 정도 절약할 수 있습니다.

3.23.41 보다 ,InnoDB (은)는 이중 기입으로 불리는 참신한 파일 플래시 기법을 사용하게 되었습니다. 이 기법에 의해서, operating system의 크래쉬나 정전 후의 리커버리가 보다 안전하게 됩니다.또,fsync 조작의 필요성을 경감하는 것으로, 대부분의 Unix 후레이바로 퍼포먼스가 향상합니다.

이중 기입에서는,InnoDB 하지만 데이터 파일에 페이지를 쓰기 전에, 우선 이중 기입 버퍼로 불리는 인접하는 테이블 스페이스에, 그러한 페이지가 써집니다.기입 및 이중 기입 버퍼에의 플래시가 완료한 다음에 처음으로,InnoDB (은)는 데이터 파일의 적절한 장소에 페이지를 씁니다.이 페이지로의 기입의 한중간에 operating system가 크래쉬 했을 경우는,InnoDB 하지만 이중 기입 버퍼로부터 적절한 페이지의 카피를 찾아내고 리커버리를 실시합니다.

3.23.41 보다 로 디바이스도 데이터 파일로서 사용할 수 있게 되었습니다만, 이 테스트는 아직 완료하고 있지 않습니다.새로운 데이터 파일을 작성할 경우에,innodb_data_file_path 그리고 지정한 데이터 파일 사이즈의 직후에 newraw 키워드를 부가할 필요가 있습니다.파티션은, 적어도 지정한 사이즈와 같은 크기가 아니면 안됩니다. InnoDB (으)로의 1M 하 1,024 x 1,024 아르바이트입니다만, 통상의 디스크의 사양에서는,1 MB 하 1,000,000 아르바이트를 의미하는 것에 주의해 주세요.

innodb_data_file_path=/dev/hdd1:5Gnewraw;/dev/hdd2:2Gnewraw

서버를 재기동하기 전에, 키워드를 raw (으)로 변경 할 필요가 있습니다 .그렇게 하지 않으면 InnoDB 하지만 파티션을 덧쓰기합니다.

innodb_data_file_path=/dev/hdd1:5Graw;/dev/hdd2:2Graw

Unix 의 일부의 버젼에서는, 로 디바이스를 사용하는 것으로, 버퍼 없음의 I/O (을)를 실행할 수 있습니다.

로 디바이스를 사용할 때는,MySQL 서버를 실행한다 OS 의 어카운트에, 그러한 파티션( 상기예에서는/dev/hdd1) 에 대해서 읽고 쓰기할 수 있는 권한이 있는 것을 확인해 주세요.

InnoDB 에는, 예측 방법으로서 시퀀셜인 예측과 랜덤인 예측의 2 종류가 있습니다.시퀀셜인 예측에서는, 테이블 스페이스내의 세그먼트(segment)에의 액세스 패턴이 시퀀셜인 것을 InnoDB 하지만 검지합니다. 이 경우 InnoDB (은)는, 일련의 데이타베이스 페이지의 독해를 사전에 1 개로 정리해 I/O 시스템에 송신합니다.랜덤인 예측에서는, 테이블 스페이스내가 있는 영역이 버퍼 풀에 완전하게 읽어내지고 있는 한중간인 것을 InnoDB 하지만 검지합니다.이 경우,InnoDB (은)는 나머지의 독해를 I/O 시스템에 송신합니다.

7.5.13.2. 파일 영역 관리

옵션 설정 파일에 정의하는 데이터 파일로부터,InnoDB 의 테이블 스페이스가 구성됩니다.이러한 파일은, 단순하게 연결되어 테이블 스페이스가 됩니다.스트라이핑은 사용되지 않습니다. 현시점에서는, 테이블 스페이스의 어느 위치에 테이블을 할당할 수 있는지를 정의할 수 없습니다.다만, 새롭게 작성되는 테이블 스페이스에서는,InnoDB 하지만 말단에서 스페이스를 할당합니다.

테이블 스페이스는, 디폴트 사이즈가 16 KB 의 데이타베이스 페이지로 구성됩니다. 이러한 페이지는,64 개가 연속하는 페이지로부터 완성되는 extent에 그룹화 됩니다.InnoDB 그럼, 테이블 스페이스 내부의 ' 파일' (을)를 세그먼트(segment)라고 부릅니다.롤백(rollback) 세그먼트(segment)라는 이름은, 다소 오해를 부를 우려가 있습니다.이것은, 롤백(rollback) 세그먼트(segment)가 실제로는 테이블 스페이스내의 다수의 세그먼트(segment)를 포함하고 있기 (위해)때문입니다.

InnoDB 그럼, 각 인덱스에 2 개의 세그먼트(segment)를 할당할 수 있습니다.1 개는 B 트리의 비리프 노드용, 이제(벌써) 1 개는 리프 노드용입니다.이것에는, 데이터를 포함하고 있는 리프 노드로 연속성을 높이려는 의도가 있습니다.

테이블 스페이스내에서 세그먼트(segment)가 커지면,InnoDB (은)는 그 세그먼트(segment)에 최초의 32 페이지를 개별적으로 할당합니다.그 다음은, extent 전체를 세그먼트(segment)에 할당할 수 있습니다. InnoDB 그럼, 데이터의 연속성을 확보하기 위해서, 큰 세그먼트(segment)에 한 번에 최대 4 개의 extent를 추가할 수 있습니다.

테이블 스페이스에는, 다른 페이지의 비트 맵을 포함한 페이지가 있기 위해,InnoDB 테이블 스페이스내의 몇개의 extent는, 전체적으로는 아니고 개별의 페이지로서만 세그먼트(segment)에 할당할 수 있습니다.

쿼리 SHOW TABLE STATUS FROM ... LIKE ... (을)를 발행해 테이블 스페이스내의 빈영역을 조회하면,InnoDB (으)로부터 테이블 스페이스내의 완전하게 비어 있는 extent가 보고됩니다. InnoDB (은)는, 항상 몇개의 extent를 클린 업과 그 외의 내부적인 용도를 위해서 확보하고 있습니다.이러한 extent는 비어 영역에 포함되지 않습니다.

테이블에서 데이터를 삭제하면,InnoDB 에 의해서 대응한다 B 트리 인덱스가 축소됩니다.이것에 의해서 개개의 페이지 또는 extent가 테이블 스페이스에 해방되고, 다른 유저가 그 영역을 이용할 수 있게 될지 어떨지는, 삭제의 패턴에 따라서 다릅니다.테이블을 파기하는지, 또는 테이블에서 모든 레코드를 삭제하면, 다른 유저에게 확실히 영역이 해방됩니다.다만, 삭제된 레코드는, 트랜잭션(transaction) 롤백(rollback) 또는 일관한 독해로 그 레코드가 필요없게 된 후의 퍼지 조작으로 처음으로 물리적으로 삭제되는 것에 유의해 주세요.

7.5.13.3. InnoDB 테이블의 데후라그먼트화

InnoDB 테이블의 인덱스로 랜덤인 삽입 또는 삭제를 하면, 인덱스가 fragment화 되는 일이 있습니다. fragment화란, 디스크로의 인덱스 페이지의 물리적인 순서가, 페이지로의 레코드의 알파벳순서와 동떨어지고 있는 것, 또는 인덱스에 할당할 수 있었다 64 페이지의 블록내에 다수의 미사용 페이지가 있는 것을 의미합니다.

인덱스의 스캔을 빠르게 하려면 , 정기적으로 mysqldump (을)를 사용해 테이블을 텍스트 파일에 덤프 하고 나서 테이블을 파기해, 덤프로부터 테이블을 재로드합니다. 데후라그먼트화의 이제(벌써) 1 개의 방법으로서 테이블 변경 조작 ALTER TABLE tablename TYPE=InnoDB (을)를 실행합니다. 이것에 의해서,MySQL 하지만 테이블을 재구축 합니다.

인덱스에의 삽입이 항상 승순으로 행해져 레코드가 반드시 말미로부터 삭제되는 경우는,InnoDB 의 파일 영역 관리 알고리즘에 의해서 인덱스의 fragment화가 발생하지 않는 것이 보증됩니다.

7.5.14. 에러 처리

InnoDB (으)로의 에러 처리는, 반드시 SQL 표준에 명기되어 있는 대로가 아닙니다.SQL-99 그럼,SQL 스테이트먼트로 에러가 발생했을 경우는, 그 스테이트먼트로 롤백(rollback)를 실행하도록(듯이) 기술되고 있습니다.InnoDB 그럼, 스테이트먼트의 일부만, 또는 트랜잭션(transaction) 전체가 롤백(rollback) 되는 일이 있습니다. 다음의 리스트는,InnoDB (으)로의 에러 처리의 사양입니다.

  • 테이블 스페이스내에서 파일 영역을 다 써 버리면,MySQL 의 'Table is full' 에러가 발생해,InnoDB 하지만 SQL 스테이트먼트를 롤백(rollback) 한다.

  • 트랜잭션(transaction) 데드 록 또는 락 기다리는 타임 아웃이 발생하면,InnoDB 하지만 트랜잭션(transaction) 전체를 롤백(rollback) 한다.

  • 중복 키 에러가 발생했을 경우는,INSERT INTO ... SELECT ... (와)과 같은 스테이트먼트내에서 만나도, 그 특정의 레코드의 삽입만이 롤백(rollback) 된다. 이 사양은,SQL 스테이트먼트에 IGNORE 옵션을 지정하지 않았던 경우만 스테이트먼트가 롤백(rollback) 되도록(듯이) 변경될 예정.

  • 'row too long' 에러가 발생했을 경우는,SQL 스테이트먼트가 롤백(rollback) 된다.

  • 그 외의 에러는 주로 MySQL 의 코드 레이어에 의해서 검출되어 검출되었을 경우는 대응한다 SQL 스테이트먼트가 롤백(rollback) 된다.

7.5.15. InnoDB 테이블의 제한 사항

  • InnoDB 테이블은 풀 텍스트 인덱스를 서포트하지 않는다.

  • Windows 그럼,InnoDB 하지만 데이타베이스명과 테이블명을 내부적으로 항상 소문자로 격납한다.바이너리 형식의 데이타베이스를 Unix (와)과 Windows 의 사이에 이동하려면 , 모든 테이블명과 데이타베이스명을 소문자로 할 필요가 있다.

  • 경고: MySQL 시스템 테이블(mysql 데이타베이스의 부하의 테이블) (을)를 MyISAM (으)로부터 InnoDB 에 변환 해서는 안 된다 .이 변환은 서포트되어 있지 않다.변환해 버리면, 백업으로부터 이전의 시스템 테이블을 restore 하는지,mysql_install_db 스크립트로 시스템 테이블을 재구축 하지 않는 한,MySQL (을)를 재기동할 수 없게 된다.

  • SHOW TABLE STATUS (으)로부터 돌려주어진다 InnoDB 테이블의 통계 정보는, 테이블이 확보하고 있는 물리 사이즈를 제외하고 정확하지 않다. 레코드의 카운트는,SQL 의 최적화로 사용되는 대략의 추정치에 지나지 않는다.

  • 컬럼의 선두의 일부에 유니크 인덱스를 치려고 하면, 에러가 된다.

    CREATE TABLE T (A CHAR(20), B INT, UNIQUE (A(5))) TYPE = InnoDB;

    컬럼의 선두의 일부에 비독특한 인덱스를 치면,InnoDB (은)는 그 컬럼 전체에 인덱스를 작성한다.

  • INSERT DELAYED (은)는,InnoDB 테이블에서는 서포트되지 않는다.

  • MySQL 의 LOCK TABLES 조작에서는, 벌써 완료했다 SQL 스테이트먼트로 설정되었다 InnoDB 의 행 레벨 락이 고려되지 않는다.즉, 어느 테이블로 다른 유저의 트랜잭션(transaction)가 행 레벨 락을 설정해 있어도, 그 테이블로 테이블 락을 취득할 수 있다.따라서, 테이블로 실행한 조작이 다른 유저의 락과 충돌했을 경우는, 조작이 대기 상태가 될 가능성이 있다.또, 데드 록이 발생할 가능성도 있다.다만,InnoDB 에 의해서 설정되는 행 레벨 락에서는 항상 완전성이 배려되고 있기 때문에, 데드 록에 의해서 트랜잭션(transaction)의 완전성이 손상될 것은 없다. 또, 테이블 락을 위해서, 다른 트랜잭션(transaction)는 테이블상에서(모순되는 락 모드로) 행 레벨 락을 추가로 취득할 수 없게 된다.

  • 1 개의 테이블에 작성할 수 있는 컬럼은 1,000 개 까지이다.

  • DELETE FROM TABLE 그럼 테이블이 재생성되지 않지만, 대신에 모든 레코드가 1 개씩 삭제된다.이 처리는 그만큼 빠르지 않다.MySQL 의 장래의 버젼에서는, 처리의 빠르다 TRUNCATE (을)를 사용할 수 있게 된다.

  • InnoDB 의 디폴트의 데이타베이스 페이지 사이즈는 16 KB .코드를 재컴파일 하는 것으로, 이 사이즈는 8 KB ~ 64 KB (으)로 설정할 수 있다. InnoDB 의 3.23.40 이하의 버젼에서는, 레코드의 최대장이 데이타베이스 페이지의 반보다 약간 작다.소스 릴리스 3.23.41 보다 ,BLOB 및 TEXT 컬럼을 4 GB 미만으로 하는 것이 가능해졌다.레코드의 합계의 길이도 4 GB 미만이 아니면 안된다.InnoDB (은)는, 사이즈가 128 아르바이트 이하의 필드를 개별의 페이지에 격납하지 않는다.InnoDB 하지만 긴 필드를 다른 페이지에 격납하는 것으로 레코드를 변경했을 경우, 레코드의 나머지의 길이는 데이타베이스 페이지의 반보다 작지 않으면 안 된다.키의 최대장은 7,000 아르바이트이다.

  • 일부의 operating system에서는, 데이터 파일이 2 GB 미만이 아니면 안된다.로그 파일을 결합한 크기는,4 GB 미만이 아니면 안된다.

  • 테이블 스페이스의 최대 사이즈는,40 억 데이타베이스 페이지.이것은 테이블의 최대 사이즈이기도 하다.테이블 스페이스의 최소 사이즈는 10 MB .

  • MySQL 서버를 재기동했을 때에,InnoDB 하지만 AUTO_INCREMENT 컬럼의 낡은 값을 재사용하는 경우가 있다.

  • InnoDB 그럼,AUTO_INCREMENT 컬럼의 최초의 값을 CREATE TABLE ... AUTO_INCREMENT=... (또는 ALTER TABLE ... )(으)로 설정할 수 없다.최초의 값을 설정하려면 ,1 (을)를 공제한 값을 가지는 다?~ -의 레코드를 삽입해, 그 다음에 다?~ -의 레코드를 삭제한다.

7.5.16. InnoDB 의 변경 이력

7.5.16.1. MySQL/InnoDB-4.1.1 (2003 년 12 월 4 일)

  • InnoDB 그리고 복수 테이블 스페이스를 이용할 수 있게 되었다.InnoDB 형태의 각 테이블과 그 인덱스를 개별의 .ibd 파일에 격납해,.frm 파일의 격납처와 같다 MySQL 데이타베이스 디렉토리아래에 배치할 수 있다.

  • AUTOCOMMIT=0 의 경우, 또는 스테이트먼트가 BEGIN ... COMMIT 그리고 둘러싸여 있는 경우는,InnoDB 테이블에도 MySQL 의 쿼리 캐쉬를 사용할 수 있게 되었다.

  • 버퍼 풀의 사이즈를 8 MB 미만으로 설정하는 것으로,InnoDB 의 메모리 소비량을 수메가바이트 삭감할 수 있다.

  • Windows 그렇지만 로 디바이스를 사용할 수 있다.

7.5.16.2. MySQL/InnoDB-4.0.16 (2003 년 10 월 22 일)

  • 버그 수정: 메뉴얼로의 기술에 반해, 일의의 복합 인덱스로 일의의 완전 일치 검색 조건이 사용되었을 경우에, 락을 취득하는 독해로 InnoDB 하지만 2 개의 행 락을 설정해 있었다.단일 컬럼의 일의의 키에서는 올바르게 동작하고 있었다.

  • 버그 수정: 텐포라리테이불을 리커버리 하는 목적으로 명칭 변경 #sql... -> rsql... (을)를 이용했을 경우에,InnoDB 하지만 row_mysql_lock_data_dictionary() 그리고 아서트 하고 있었다.

  • MySQL 의 버그 데이타베이스에, 비위기인 미해결의 버그가 몇개인가 보고되고 있다.이러한 버그의 수정은, 다음에 릴리스 된다 4.1.1 에 자원이 배분되고 있기 위해서 연기되었다.

7.5.16.3. MySQL/InnoDB-3.23.58 (2003 년 9 월 15 일)

  • 버그 수정: mysqld 기동 후의 최초의 B 트리 페이지 분할로,InnoDB 하지만 인덱스 페이지 디렉토리를 파괴할 가능성이 있었다.현상으로서는,page0page.c 의 함수 page_dir_find_slot() 그리고 아서트에라가 발생하고 있었다.

  • 버그 수정: 극히 보기 드물기는 하지만, 롤백(rollback), 퍼지, 및 SELECT 하지만 동시에 발생했을 경우에,InnoDB 하지만 무관계한 레코드를 돌려주는 일이 있었다.

  • LOCK TABLES 의 내부에서 SELECT 하지만 사용되었을 경우에,btr0sea.c 빗장으로 행이 발생하지 않게 수정되었다.

  • 버그 수정: 단일의 DELETE 스테이트먼트가, 몇개의 로를 삭제한 후에 FOREIGN KEY 에러 또는 Table is full 에러로 실패했을 경우에,MySQL 하지만 SQL 스테이트먼트 전체를 롤백(rollback)하지 않았다.

7.5.16.4. MySQL/InnoDB-4.0.15 (2003 년 9 월 10 일)

  • 버그 수정: 레코드를 갱신한 것으로 최대장의 8,000 아르바이트(BLOB 및 TEXT 없이)를 초과했을 경우에,InnoDB (은)는 단지 쿠라스타드인젝스로부터 레코드를 삭제하고 있었다.같은 삽입으로,InnoDB 하지만 예약된 파일 영역의 extent를 리크 해, 그것이 다음의 mysqld 기동시까지 해방되지 않았다.

  • 버그 수정: 로그 파일이 비교적 작은 경우에 큰 BLOB 값을 사용하면, 큰 BLOB 조작 시에,InnoDB 하지만 최신의 체크 포인트의 뒤에 작성된 로그에 일시적으로 덧쓰기할 가능성이 있었다.그 시점에서 InnoDB 하지만 크래쉬 하면, 최신의 체크 포인트까지 로그를 스캔 할 수 없기 위해(때문에), 크래쉬 리커버리가 실패하고 있었다.이 버젼보다,InnoDB (은)는 최신의 체크 포인트가 충분히 새로운 것을 보증하게 되었다.이것을 보증할 수 없는 경우,InnoDB 하 MySQL 의 .err 로그에 경고를 출력해, 로그 파일을 확대하도록(듯이) 권고한다.

  • 버그 수정: innodb_fast_shutdown=0 (을)를 설정해도 작용하지 않았다.

  • 4.0.13 그리고 검출된 버그를 수정: CREATE TABLE 하지만 코멘트로 끝나 있으면, 메모리오바란이 발생할 가능성이 있었다.

  • 버그 수정: Windows 그리고 InnoDB 하지만 .err 로그에 Operating system error number .. in a file operation (을)를 출력할 때의 에러 번호의 설명이 잘못되어 있었다.회피책: Windows 의 에러 번호에 대해서는,http://www.innodb.com/ibman.php 의 섹션 13.2 (을)를 참조.

  • 버그 수정: 고정장의 CHAR 컬럼으로,t(a CHAR(200), PRIMARY KEY (a(10))) (와)과 같이 카람프리픽스 PRIMARY KEY (을)를 작성하면, 단순한 SELECT 그렇지만 InnoDB 하지만 크래쉬 하고 있었다.작성된 키가 PRIMARY (이)가 아닌 경우도,CHECK TABLE (으)로부터 테이블의 파손이 보고되고 있었다.

7.5.16.5. MySQL/InnoDB-4.0.14 (2003 년 7 월 22 일)

  • InnoDB 하지만 SQL 스테이트먼트 SAVEPOINT 및 ROLLBACK TO SAVEPOINT (을)를 서포트하게 되었다.구문에 대해서는,http://www.innodb.com/ibman.php#Savepoints (을)를 참조.

  • CREATE TABLE t (a BLOB, INDEX (a(10))) (와)과 같이, 카람프리픽스키를 작성할 수 있게 되었다.

  • Linux 및 FreeBSD 의 최신 버젼에서는,O_DIRECT (을)를 innodb_flush_method (으)로서 사용할 수도 있다.다만, 이러한 operating system로 예상되는 버그에 주의한다.

  • 데이터 페이지의 체크 섬 계산이 수정되었다.이전에는,OS 의 파일 시스템의 파손이 거의 깨달아지지 않았다.4.0.14 이?~ 의 버젼으로부터 4.0.14 미만의 버젼에 다운 그레이드 하면, 최초의 기동시에 InnoDB (으)로부터 다음의 경고가 출력되는 것에 주의한다.

    InnoDB: Warning: an inconsistent page in the doublewrite buffer
InnoDB: space id 2552202359 page number 8245, 127'th page in dblwr buf.

    다만, 이것은 위험하지 않기 때문에 무시해 상관없다.

  • 버퍼 풀 치환 알고리즘이 변경되고,LRU 리스트의 마지막 10% 에 치환가능인 페이지가 없는 경우에, 변경된 페이지가 플래시 되게 되었다.이것에 의해서, 프로세스가 독해와 기입을 실시하는 경우에, 디스크 I/O (을)를 삭감할 수 있다.

  • 버퍼 풀의 체크 포인트 플래시 알고리즘으로, 플래시 리스트의 마지막에 있는 페이지에 인접하는 페이지도 플래시 되게 되었다.이것에 의해서, 데이타베이스의 슛다운을 고속화할 수 있는 것과 동시에,InnoDB 의 로그 파일이 버퍼 풀에 비해 꽤 작은 경우에 디스크의 기입을 고속화할 수 있다.

  • 4.0.13 그럼,SHOW INNODB STATUS 그리고 최신의 UNIQUE KEY 에러에 관한 상세 정보가 출력되고 있었지만, 이 정보를 격납하면 REPLACE 의 속도가 크게 저하할 가능성이 있었다.이 정보가 격납 또는 출력되지 않게 되었다.

  • 버그 수정: MySQL replication로,SET FOREIGN_KEY_CHECKS=0 하지만 적절히 레프리케이트 되어 있지 않았다.하위 버젼의 3.23 에는 이 수정이 이식되지 않는다.

  • 버그 수정: 파라미터 innodb_max_dirty_pages_pct 그리고, 버퍼 풀내의 빈페이지가 고려되어 있지 않았다.이 때문에, 버퍼 풀내에 다수의 빈페이지가 있는 경우에서도, 필요이상으로 플래시 되는 일이 있었다.회피책: SET GLOBAL innodb_max_dirty_pages_pct = 100 .

  • 버그 수정: 대규모 인덱스 스캔을 하면, semaphore 대기가 길어지기 위해서, 파일 독해 요구로 자원이 부족해,InnoDB 하지만 아서트 할 가능성이 있었다.

  • 버그 수정: AUTOCOMMIT=1 의 경우에 바이나리로깅이 온으로 되어 있지 않으면MySQL 하지만 LOCK TABLES 의 내부에서 갱신을 실시한다 SQL 스테이트먼트의 뒤에 코?~ 트를 실행할 수 없었다.또,SELECT 스테이트먼트에서는 바이나리로깅 상태에 관계없이 코?~ 트가 실행되지 않았다.

  • 버그 수정: mysqld 기동 후의 최초의 B 트리 페이지 분할로,InnoDB 하지만 인덱스 페이지 디렉토리를 파괴할 가능성이 있었다.현상으로서는,page0page.c 의 page_dir_find_slot() 함수로 아서트가 발생하고 있었다.

  • 버그 수정: UPDATE CASCADE 마디를 수반한다 FOREIGN KEY 그리고, 친컬럼의 내부 스토리지장이 아이 컬럼과 다르고 있는 경우에 캐스케이드 된 갱신을 실행하면, 아이 테이블로 컬럼장이 부적절이 되어, 아이 테이블이 파손하고 있었다.MySQL 의 ' 암묵적인 컬럼 사양의 변경' (을)를 위해서 고정장의 CHAR 컬럼이 내부적으로 VARCHAR (으)로 변경되어 이 에러를 일으킬 가능성이 있다.

  • 버그 수정: latin1 이외의 캐릭터 세트가 사용되었을 경우, 및 FOREIGN KEY 그리고 친컬럼의 내부 스토리지장이 아이 컬럼과 다른 경우에, 아이 테이블에의 삽입이 모두 외부 키 에러로 실패하고 있었다.

  • 버그 수정: InnoDB 하지만, 쿠라스타드인젝스레코드가 발견되지 않는다고 하는 메세지를 돌려주거나 극히 보기 드물기는 하지만, 롤백(rollback), 퍼지, 및 SELECT 하지만 동시에 발생했을 경우에 무관계한 로를 돌려주거나 하는 일이 있었다.

  • LOCK TABLES 안에서 SELECT 하지만 사용되었을 경우에,btr0sea.c 빗장상에서 행이 발생하지 않게 수정되었다.

  • 버그 수정: 4.0.13 의 릴리스 노트의 기재에 반해,MySQL 의 바이나리로깅이 온이라고 그르프코?~ 트가 동작하지 않았다.

  • 버그 수정: Unix 그리고 os_event_wait() 하지만 적절히 기능하지 않았기(위해)때문에, 각종 로그 조작으로 자원의 고갈이 발생하고 있었다.

  • 버그 수정: 단일의 DELETE 스테이트먼트가 몇개의 로를 삭제한 후에 FOREIGN KEY 에러 또는 'Table is full error' 그리고 실패했을 경우에,MySQL 하 SQL 스테이트먼트 전체를 롤백(rollback) 하지 않고, 실패한 스테이트먼트를 바이너리 로그에 써, 그 때에 제로 이외의 error_code (을)를 보고하고 있었다.

  • 버그 수정: 테이블에는 최대 1,000 개의 컬럼을 수용할 수 있지만,InnoDB 하지만 CREATE TABLE 그리고 그 제한을 체크하지 않았기(위해)때문에, 테이블에 대한 후속의 INSERT 또는 SELECT 그리고 아서트가 발생할 가능성이 있었다.

7.5.16.6. MySQL/InnoDB-3.23.57 (2003 년 6 월 20 일)

  • innodb_flush_log_at_trx_commit 의 디폴트치가 0 (으)로부터 1 (으)로 변경되었다.이 새로운 릴리스에서는,my.cnf 그리고 이 값을 명시적으로 지정하지 않으면 값 1 하지만 설정되기 위해, 트란자크션코?~ 트마다 디스크에의 로그의 플래시가 발생해 어플리케이션의 실행 속도가 큰폭으로 저하한다.

  • 버그 수정: InnoDB 그리고, 테이블이 파기될 때에 pthread_mutex_destroy() 하지만 불려 가지 않았었다.그 때문에(위해),FreeBSD 및 그 외의 Linux 이외의 Unix 그리고 메모리 리크가 발생할 가능성이 있었다.

  • 버그 수정: 하늘이 아닌 인덱스 범위에 대해서 InnoDB 하지만 그 사이즈를 0 레코드라고 추정하면,MySQL (으)로부터 잘못해 ' 하늘 집합' 하지만 돌려주어질 가능성이 있었다.또, 인덱스 범위가 하늘이라고,MySQL (은)는 넥스트 키 록을 실행할 수 없었다.

  • 버그 수정: GROUP BY 및 DISTINCT 하지만 NULL 값을 부등으로서 취급하는 일이 있었다.

7.5.16.7. MySQL/InnoDB-4.0.13 (2003 년 5 월 20 일)

  • InnoDB 하지만 ALTER TABLE DROP FOREIGN KEY (을)를 서포트하게 되었다.외부 키를 파기하는 경우는,SHOW CREATE TABLE (을)를 사용하고, 내부에서 생성된 외부 키 ID (을)를 검출할 필요가 있다.

  • SHOW INNODB STATUS 그리고, 마지막에 검출되었다 FOREIGN KEY 에러 및 UNIQUE KEY 에러의 상세 정보가 출력되게 되었다.InnoDB 하지만 CREATE TABLE (으)로부터 에러 150 (을)를 돌려준 원인을 모르는 경우는, 이 스테이트먼트를 사용해 원인을 조사할 수 있다.

  • ANALYZE TABLE 하지만 InnoDB 형태의 테이블에서도 동작하게 되었다.이 스테이트먼트는, 각 인덱스 트리를 랜덤에 10 개소 조사해 거기에 응해 인덱스의 카디나리티의 추정치를 갱신한다.이것은 추정치에 지나지 않기 때문에,ANALYZE TABLE (을)를 실행할 때마다 다른 수치가 생성될 가능성이 있는 것에 주의한다.MySQL (은)는, 인젝스카디나리티의 추정치를 결합의 최적화에서만 사용한다.적절히 최적화되어 있지 않은 결합이 있는 경우는,ANALYZE TABLE (을)를 시험할 수 있다.

  • InnoDB 의 그르프코?~ 트 기능이,MySQL 의 바이너리 로그가 온이 되어 있는 경우도 동작하게 되었다.그르프코?~ 트를 액티브하게 하려면 , 쿠라이안트스레드의 수가 3 개이상이 아니면 안된다.

  • innodb_flush_log_at_trx_commit 의 디폴트치가 0 (으)로부터 1 (으)로 변경되었다.이 새로운 릴리스에서는,my.cnf 그리고 이 값을 명시적으로 지정하지 않으면 값 1 하지만 설정되기 위해, 트란자크션코?~ 트마다 디스크에의 로그의 플래시가 발생해 어플리케이션의 실행 속도가 큰폭으로 저하한다.

  • 설정 가능한 MySQL 글로벌 시스템 변수 innodb_max_dirty_pages_pct 하지만 추가되었다.이 변수는 0 ~ 100 의 정수이다. 디폴트치는 90 .InnoDB 의 메인스레드는, 많아도 이 퍼센티지가 항상 플래시 되지 않고 남도록(듯이), 버퍼 풀로부터 페이지를 플래시 하려고 한다.

  • innodb_force_recovery=6 의 경우에,InnoDB 하지만 파손 페이지를 이중 기입 버퍼에 근거해 수복하지 않게 되었다.

  • 버퍼 풀내의 메모리를 제로로 설정하지 않게 되었기 때문에,InnoDB 의 기동이 빨라졌다.

  • 버그 수정: MySQL 의 코멘트내에 'foreign key' 그렇다고 하는 키워드가 있으면,FOREIGN KEY 정의용의 InnoDB 파서로 혼란이 생기고 있었다.

  • 버그 수정: FOREIGN KEY 그리고 참조되고 있던 테이블을 파기해, 그 후에 일치하지 않는 컬럼형으로 같은 테이블을 작성하면,InnoDB 하지만 dict0load.c 의 dict_load_table() 함수로 아서트 할 가능성이 있었다.

  • 버그 수정: GROUP BY 및 DISTINCT 하지만 NULL 값을 부등으로서 취급하는 일이 있었다. 또, 인덱스의 범위가 하늘인 경우에,MySQL 하지만 넥스트 키 록을 실행할 수 없었다.

  • 버그 수정: MyISAM 테이블이 갱신되었을 때에 현재의 트랜잭션(transaction)는 코?~ 트 되지 않는다.이 때문에, 바이나리로깅이 유효해도,CREATE TABLE 그럼 InnoDB 트랜잭션(transaction)가 코?~ 트 되지 않는다.

  • 버그 수정: 삭제를 한 테이블은 ON DELETE SET NULL 그리고 변경할 수 없었지만, 이것을 가능하게 하고, 캐스케이드 된 조작으로 엔들레스 루프가 생기지 않도록 했다.

  • 버그 수정: 주키로의 일의의 검색으로 커서를 자리 매김을 한 다음에도 HANDLER PREV 및 NEXT (을)를 사용할 수 있게 되었다.

  • 버그 수정: MIN() 또는 MAX() 에 의해서 데드 록 또는 락 기다리는 타임 아웃이 발생했을 경우에,MySQL 하지만 에러를 돌려주지 않고 , 함수의 값으로 해서 NULL (을)를 돌려주고 있었다.

  • 버그 수정: 테이블이 파기될 때에,InnoDB 하지만 pthread_mutex_destroy() (을)를 호출하지 않았었다.그 때문에(위해),FreeBSD 및 그 외의 Linux 이외의 Unix 시스템으로 메모리 리크가 발생할 가능성이 있었다.

7.5.16.8. MySQL/InnoDB-4.1.0 (2003 년 4 월 3 일)

  • InnoDB 하지만,Windows (을)를 실행한다 32 비트의 Intel 컴퓨터로 밧파프르메모리를 64 GB 까지 서포트하게 되었다.이것이 실현된 것은,InnoDB 하지만 Windows 의 AWE 확장을 사용해 32 비트 프로세스의 4 GB 의 제한을 넘는 메모리에 대응할 수 있게 되었기 때문에.새로운 기동 변수 innodb_buffer_pool_awe_mem_mb 에 의해서,AWE 하지만 유효하게 되어, 버퍼 풀의 사이즈가메가바이트 단위로 설정된다.

  • 버퍼 헤더와 락 테이블의 사이즈가 삭감되었다.InnoDB 의 사용하는 메모리가 2% 적게 되었다.

7.5.16.9. MySQL/InnoDB-3.23.56 (2003 년 3 월 17 일)

  • InnoDB 의 쿼리 최적화에 있어서의 주요한 버그를 수정: SELECT ... WHERE indexcolumn < x 및 SELECT ... WHERE indexcolumn > x 그렇다고 하는 타입의 쿼리로, 적절히 선택할 수 있는 경우에서도 테이블이 스캔 될 가능성이 있었다.

  • MySQL 하지만 쿼리의 도중에 TL_IGNORE (을)를 지정해 store_lock (을)를 호출하는 경우에 발생하고 있던 버그가 수정되었다.

7.5.16.10. MySQL/InnoDB-4.0.12 (2003 년 3 월 18 일)

  • 크래쉬 리커버리 시에,InnoDB 하지만 트랜잭션(transaction) 롤백(rollback)의 진행 상황을 퍼센티지로 출력하게 되었다.

  • 버그/ 기능 수정: mysql_use_result() (을)를 사용하는 응용 프로그램으로,2 개이상의 접속을 사용해 SQL 쿼리를 송신하면,btr0sea.c 의 적응적인 해시 S- 빗장으로 데드 록이 발생할 가능성이 있었다.이것을 개선해,mysqld 하지만 SELECT (으)로부터의 데이터를 클라이언트에 건네줄 때마다 S- 빗장을 해방하도록(듯이) 했다.

  • 버그 수정: 하늘이 아닌 인덱스 범위에 대해서 InnoDB 하지만 그 사이즈를 0 레코드라고 추정하면,MySQL (으)로부터 잘못해 ' 하늘 집합' 하지만 돌려주어질 가능성이 있었다.또, 인덱스 범위가 하늘이라고,MySQL (은)는 넥스트 키 록을 실행할 수 없었다.

7.5.16.11. MySQL/InnoDB-4.0.11 (2003 년 2 월 25 일)

  • 4.0.10 그리고 검출된 버그를 수정: SELECT ... FROM ... ORDER BY ... DESC 하지만, 엔들레스 루프로 행 할 가능성이 있었다.

  • 미해결의 버그: MySQL replication로,SET FOREIGN_KEY_CHECKS=0 하지만 적절히 레프리케이트 되지 않는다.

7.5.16.12. MySQL/InnoDB-4.0.10 (2003 년 2 월 4 일)

  • MySQL (은)는,INSERT INTO t1 SELECT ... FROM t2 WHERE ... 그리고,t2 에 테이블 레벨의 리드 락이 설정되어 있었다.이 락이 설정되지 않게 되었다.

  • SHOW INNODB STATUS 의 최대 출력장이 200 KB 에 확대되었다.

  • InnoDB 의 쿼리 최적화에 있어서의 주요한 버그를 수정: SELECT ... WHERE indexcolumn < x 및 SELECT ... WHERE indexcolumn > x 그렇다고 하는 타입의 쿼리로, 적절히 선택할 수 있는 경우에서도 테이블이 스캔 될 가능성이 있었다.

  • 버그 수정: 주키의 인덱스 트리의 높이가 1 이다 BLOB 테이블로, 퍼지에 의해서 행이 발생할 가능성이 있었다.현상: btr_free_externally_stored_field() (으)로 설정되었다 X- 빗장에 의해서 발생하는 semaphore 대기.

  • 버그 수정: 새로운 핸들로 InnoDB 의 HANDLER 커멘드를 사용하면,ha_innobase::change_active_index() 그리고 mysqld 하지만 크래쉬 하고 있었다.

  • 버그 수정: MySQL 하지만,SELECT 스테이트먼트의 도중에 쿼리를 추정하면,btr0sea.c 의 적응적인 해시 인덱스 빗장으로 InnoDB 하지만 행 할 가능성이 있었다.

  • 버그 수정: 적응적인 해시 인덱스의 검색이 퍼지 또는 삽입과 동시에 실행되었을 경우에,InnoDB 하지만 테이블의 파손을 보고해,page_dir_find_owner_slot() 그리고 아서트 할 가능성이 있었다.

  • 버그 수정: Windows 2000 (이)가 있는 파일 시스템 snapshot 툴에 의해서,InnoDB 의 파일 기입이 에러 33 ERROR_LOCK_VIOLATION 그리고 실패할 가능성이 있었다. 동기 기입으로,InnoDB 하지만 기입을 1 초간격으로 100 회재시행하게 되었다.

  • 버그 수정: REPLACE INTO t1 SELECT ... 하지만,t1 에 오토 인크리먼트(increment) 컬럼이 있는 경우에 기능하지 않았다.

  • 미해결의 버그: MySQL replication로,SET FOREIGN_KEY_CHECKS=0 하지만 적절히 레프리케이트 되지 않는다.

7.5.16.13. MySQL/InnoDB-3.23.55 (2003 년 1 월 24 일)

  • MySQL (은)는,INSERT INTO t1 SELECT ... FROM t2 WHERE ... 그리고,t2 에 테이블 레벨의 독해 락이 설정되어 있었다.이 락이 설정되지 않게 되었다.

  • 버그 수정: 32 비트 컴퓨터로,InnoDB 의 로그 파일을 결합한 크기가 2 GB 이상이라고,InnoDB 하지만 잘못된 위치에 로그를 쓰고 있었다.이 때문에, 크래쉬 리커버리와 InnoDB 핫 백업이 로그 스캔으로 실패할 가능성이 있었다.

  • 버그 수정: 인덱스 커서의 restore가, 이론적으로 실패할 가능성이 있었다.

  • 버그 수정: btr0sea.c 의 함수 btr_search_info_update_slow (으)로의 아서트가,3 개의 스레드의 경합으로 이론적으로 실패할 가능성이 있었다.

  • 버그 수정: 주키의 인덱스 트리의 높이가 1 이다 BLOB 테이블로, 퍼지에 의해서 행이 발생할 가능성이 있었다.현상: btr_free_externally_stored_field() (으)로 설정되었다 X- 빗장에 의해서 발생하는 semaphore 대기.

  • 버그 수정: MySQL 하지만,SELECT 스테이트먼트의 도중에 쿼리를 추정하면,btr0sea.c 의 적응적인 해시 인덱스 빗장으로 InnoDB 하지만 행 할 가능성이 있었다.

  • 버그 수정: 적응적인 해시 인덱스의 검색이 퍼지 또는 삽입과 동시에 실행되었을 경우에,InnoDB 하지만 테이블의 파손을 보고해,page_dir_find_owner_slot() 그리고 아서트 할 가능성이 있었다.

  • 버그 수정: Windows 2000 (이)가 있는 파일 시스템 snapshot 툴에 의해서,InnoDB 의 파일 기입이 에러 33 ERROR_LOCK_VIOLATION 그리고 실패할 가능성이 있었다. 동기 기입으로,InnoDB 하지만 기입을 1 초간격으로 100 회재시행하게 되었다.

  • 미해결의 버그: MySQL replication로,SET FOREIGN_KEY_CHECKS=0 하지만 적절히 레프리케이트 되지 않는다.이 수정은 4.0.11 그리고 행해져3.23 에 이식될 가능성은 낮다.

  • InnoDB page0cur.c 의 함수 page_cur_search_with_match 그리고,InnoDB 하지만 같은 페이지로부터 영구적으로 움직이지 못하게 되는 버그가 수정되었다. 이 버그는, 테이블에 복수의 페이지가 있는 경우만 발생한다.

7.5.16.14. MySQL/InnoDB-4.0.9 (2003 년 1 월 14 일)

  • 경고 메세지 'InnoDB: Out of memory in additional memory pool' 하지만 삭제되었다.

  • 버그 수정: 32 비트 컴퓨터로,InnoDB 의 로그 파일을 결합한 크기가 2 GB 이상이라고,InnoDB 하지만 잘못된 위치에 로그를 쓰고 있었다.이 때문에, 크래쉬 리커버리와 InnoDB 핫 백업이 실패할 가능성이 있었다.

  • 버그 수정: 인덱스 커서의 restore가, 이론적으로 실패할 가능성이 있었다.

7.5.16.15. MySQL/InnoDB-4.0.8 (2003 년 1 월 7 일)

  • InnoDB 하지만 FOREIGN KEY (...) REFERENCES ...(...) [ON UPDATE CASCADE | ON UPDATE SET NULL | ON UPDATE RESTRICT | ON UPDATE NO ACTION] 도 서포트하게 되었다.

  • 테이블과 인덱스가 테이블 스페이스내에서 확보하는 영역이 4% 삭감되었다. 또, 기존의 테이블이 확보하는 영역도 삭감되었다.4.0.8 에 업그레이드 하면,SHOW TABLE STATUS 그리고 "InnoDB free" 에 표시되는 빈영역이 증가한다.

  • 버그 수정: 로의 주키를 갱신하면, 갱신되는 로의 2차 키를 참조하는 모든 외부 키로 외부 키 에러가 발생하고 있었다.또, 참조를 실시하는 외부 키 제약이, 인덱스의 최초의 컬럼만을 참조하는 경우에, 그 인덱스에 복수의 컬럼이 있으면, 그 외의 컬럼을 갱신할 때에 외부 키 에러가 발생하고 있었다.

  • 버그 수정: 같은 컬럼을 2 개 포함하고 있는 인덱스로 그 컬럼이 갱신되면, 테이블이 파손한다.InnoDB 그리고 이러한 인덱스가 작성되지 않게 되었다.

  • 버그 수정: 락을 취득한다 SELECT 그리고 데드 록 또는 락 대기 타임 아웃이 발생했을 경우에,.err 로그로부터 여분의 에러 149 및 150 하지만 출력되지 않게 되었다.

  • 버그 수정: btr0sea.c 의 함수 btr_search_info_update_slow (으)로의 아서트가,3 개의 스레드의 경합으로 이론적으로 실패할 가능성이 있었다.

  • 버그 수정: 세션의 트랜잭션(transaction) 분리 레벨을 REPEATABLE READ (으)로부터 다른 레벨로 설정하면,REPEATABLE READ 에 되돌릴 수 없었다.

7.5.16.16. MySQL/InnoDB-4.0.7 (2002 년 12 월 26 일)

  • 4.0.7 의 InnoDB (은)는, 기본적으로 4.0.6 (와)과 같다.

7.5.16.17. MySQL/InnoDB-4.0.6 (2002 년 12 월 19 일)

  • innodb_log_arch_dir (은)는,MySQL 에 관계하지 않기 때문에,my.cnf 그리고 이 파라미터를 지정할 필요가 없어졌다.

  • AUTOCOMMIT=1 모드의 LOAD DATA INFILE 하지만,1 MB 분의 바이너리 로그가 써질 때마다 암묵적으로 코?~ 트를 실행하지 않게 되었다.

  • 4.0.4 그리고 검출된 버그를 수정: LOCK TABLES ... READ LOCAL 그럼, 읽어내진 로에 행 락을 설정할 수 없었다.이 때문에,mysqldump 그리고 데드 록이나 락 대기 타임 아웃이 발생하고 있었다.

  • 4.0.4 그리고 검출되었다 2 개의 버그를 수정: AUTO_INCREMENT 그리고,REPLACE 하지만 카운터를 1 대로 할 가능성이 있었다. 데드 록 또는 락 대기 타임 아웃에서도 같은 문제가 발생할 가능성이 있었다.

  • 버그 수정: 텐포라리테이불로 TRUNCATE (을)를 실행하면,InnoDB 하지만 크래쉬 하고 있었다.

  • 4.0.5 그리고 검출된 버그를 수정: 바이나리로깅을 오프로 한 채로 INSERT INTO ... SELECT ... 또는 CREATE TABLE ... SELECT ... (을)를 실행하면,btr0sea.c 의 128 행목으로 작성된 semaphore로 InnoDB 하지만 행 할 가능성이 있었다. 회피책: 바이너리 로그를 온으로 한다.

  • 버그 수정: replication로, 멀티 스테이트먼트 트랜잭션(transaction)의 도중에 SLAVE STOP (을)를 발행하면,SLAVE START 하지만 트랜잭션(transaction)의 일부 밖에 실행하지 않게 될 가능성이 있었다.슬레이브가 크래쉬 후에 재기동되었을 경우도, 같은 에러가 발생할 가능성이 있었다.

7.5.16.18. MySQL/InnoDB-3.23.54 (2002 년 12 월 12 일)

  • 버그 수정: 인덱스 트리로의 범위의 엔드 포인트에의 패스가 루트내에서 벌써 분기 하고 있는 경우에,InnoDB 그리고 짧은 인덱스 범위의 사이즈가 큰폭으로 과장하고 추정되고 있었다. 이 때문에,SQL 쿼리로 불필요한 테이블 스캔이 실행될 가능성이 있었다.

  • 버그 수정: 테이블에 주키를 작성하지 않고 복수의 인덱스를 정의해, 그 중이 적어도 1 개를 유니크 인덱스로 하고, 그 모든 컬럼을 NOT NULL (으)로서 선언하면,ORDER BY 하지만 실패할 가능성이 있었다.

  • 버그 수정: ON DELETE CASCADE 에 관련하는 락 대기 타임 아웃에 의해서, 인덱스가 파손할 가능성이 있었다.

  • 버그 수정: 프라이머리 인덱스로부터 일의의 키를 사용해 SELECT (을)를 실행했을 경우에, 검색으로 일치한 레코드에 삭제 마크가 뒤따르고 있으면,InnoDB 하지만 잘못해 다음의 레코드를 돌려줄 가능성이 있었다.

  • 3.23.53 그리고 검출된 버그를 수정: LOCK TABLES ... READ LOCAL 그럼, 읽어내진 로에 행 락을 설정할 수 없었다.이 때문에,mysqldump 그리고 데드 록이나 락 대기 타임 아웃이 발생하고 있었다.

  • 버그 수정: 같은 컬럼을 2 개 포함하고 있는 인덱스로 그 컬럼이 갱신되면, 테이블이 파손한다.InnoDB 그리고 이러한 인덱스가 작성되지 않게 되었다.

7.5.16.19. MySQL/InnoDB-4.0.5 (2002 년 11 월 18 일)

  • InnoDB 하지만 트랜잭션(transaction) 분리 레벨 READ COMMITTED 및 READ UNCOMMITTED (을)를 서포트하게 되었다.READ COMMITTED 하 Oracle (을)를 엄밀하게 에?~ 레이트 하고 있기 때문에,Oracle (으)로부터 MySQL 에의 어플리케이션의 이식이 용이하게 된다.

  • 데드 록이 선택적으로 해소되게 되었다.즉, 로의 변경 또는 삽입이 적은 트랜잭션(transaction)를 선택해 희생하도록(듯이) 했다.

  • 외부 키의 정의로,my.cnf 의 lower_case_table_names 의 설정이 고려되게 되었다.

  • 외부 키 정의로 참조되는 테이블이 작성되는 테이블과 같은 데이타베이스에 있는 경우는,SHOW CREATE TABLE 그리고 외부 키 정의에 데이타베이스명이 출력되지 않는다.

  • InnoDB (은)는, 인덱스 페이지를 데이터 파일에 쓰기 전에, 그 대부분의 페이지에 대해서 정합성 체크를 실행한다.

  • innodb_force_recovery 에 0 보다 큰 값을 설정하면,InnoDB (은)는 테이블에 대해서 SELECT * FROM (을)를 실행할 때에, 파손한 인덱스 레코드와 페이지를 날린다.이것은 덤프 시에 도움이 된다.

  • InnoDB 하지만,Windows 2000 (와)과 XP 그리고 다시 버퍼 없음의 비동기 I/O (을)를 사용하게 되었다.NT ,95/98/ME 그럼 버퍼 없음의 시?~ 레이트 된 비동기 I/O 만이 사용된다.

  • 버그 수정: 인덱스 트리로의 범위의 엔드 포인트에의 패스가 루트내에서 벌써 분기 하고 있는 경우에,InnoDB 그리고 짧은 인덱스 범위의 사이즈가 큰폭으로 과장하고 추정되고 있었다.이 때문에,SQL 쿼리로 불필요한 테이블 스캔이 실행될 가능성이 있었다. 이 수정은, 하위의 3.23.54 에도 이식된다.

  • 3.23.52 ,4.0.3 ,4.0.4 그리고 검출된 버그를 수정: 일부의 Windows 95/98/ME 컴퓨터로,InnoDB 의 기동에 시간이 걸려, 크래쉬 하기도 했다.

  • 버그 수정: 락 기다리는 다음에 부여되었다 AUTO-INC 락이, 트랜잭션(transaction)가 종료할 때까지 유지되고 있었다.이것에 의해서, 불필요한 데드 록이 발생할 가능성이 있었다.

  • 버그 수정: SHOW INNODB STATUS ,innodb_monitor , 또는 innodb_lock_monitor 그리고,1 회의 리포트에 수백의 트랜잭션(transaction)를 출력할 필요가 있는 경우에 출력을 잘라 버릴 수 있으면,srv0srv.c 의 1621 행목으로 작성되었다 mutex 에 대한 다수의 대기를 에러 로그에 출력할 때에 InnoDB 하지만 행 하고 있었다.

  • 버그 수정: Unix 그리고 SHOW INNODB STATUS (을)를 실행하면, 평균 파일 독해 사이즈가 항상 0 아르바이트로서 보고되고 있었다.

  • 4.0.4 의 잠재적인 버그를 수정: InnoDB 하지만,MyISAM (와)과 같이 ORDER BY ... DESC (을)를 실행하게 되었다.

  • 버그 수정: 테이블상에서 롤백(rollback)가 실행되고 있을 때 DROP TABLE (을)를 실행하면, 크래쉬 또는 행이 발생할 가능성이 있었다.이것이 실제로 유저에게 있어서 문제이다고 보여졌을 경우만, 이 수정이 하위의 3.23 에도 이식된다.

  • 버그 수정: 테이블에 주키를 작성하지 않고 복수의 인덱스를 정의해, 그 중이 적어도 1 개를 유니크 인덱스로 하고, 그 모든 컬럼을 NOT NULL (으)로서 선언하면,ORDER BY 하지만 실패할 가능성이 있었다.

  • 버그 수정: ON DELETE CASCADE 에 관련하는 락 대기 타임 아웃에 의해서, 인덱스가 파손할 가능성이 있었다.

  • 버그 수정: 프라이머리 인덱스로부터 일의의 키를 사용해 SELECT (을)를 실행했을 경우에, 검색으로 일치한 레코드에 삭제 마크가 뒤따르고 있으면,InnoDB 하지만 다음의 레코드를 돌려줄 가능성이 있었다.

  • 미해결의 버그: 4.0.4 그리고,AUTO_INCREMENT 에 관한 2 개의 버그가 검출되었다.1 개는 REPLACE 하지만 카운터를 1 대로 할 가능성이 있는 것, 이제(벌써) 1 개는 데드 록 또는 락 대기 타임 아웃으로 같은 문제가 발생할 가능성이 있는 것이다.이것들은 4.0.6 그리고 수정된다.

7.5.16.20. MySQL/InnoDB-3.23.53 (2002 년 10 월 9 일)

  • Windows 그리고, 데이터 파일에 대해서 버퍼 없음의 디스크 I/O (을)를 다시 사용하게 되었다. 통상의 I/O 그럼,Windows XP 및 Windows 2000 (으)로의 독해의 퍼포먼스에 지장이 나온다고 생각된다.

  • 범위 추정 기능을 조정하고, 인덱스 범위의 스캔이 풀 인덱스 스캔보다 우선되도록(듯이) 했다.

  • innodb_force_recovery 하지만 설정되어 있는 경우에서도, 테이블을 파기 또는 작성할 수 있게 되었다.이것을 이용하고, 롤백(rollback) 또는 퍼지로 크래쉬를 일으키는 테이블을 파기하거나 테이블 임포트가 실패한 후의 리커버리로 롤백(rollback)가 폭주했을 경우에 테이블을 파기할 수 있다.

  • 3.23.52 ,4.0.3 ,4.0.4 그리고 검출된 버그를 수정: 일부의 Windows 95/98/ME 컴퓨터로,InnoDB 의 기동에 시간이 걸려, 크래쉬 하기도 했다.

  • 버그 수정: 고속 슛다운(디폴트)이, 퍼지 또는 삽입 버퍼의 머지에 의해서 늦어지는 일이 있었다.

  • 버그 수정: 독해 일관성으로, 가시의 로가 존재하지 않는 테이블에 대해서 대규모 SELECT (을)를 실행하면,btr0cur.c 의 310 행목으로 장시간(600 초보다 길다)의 semaphore 대기가 발생할 가능성이 있었다.

  • 버그 수정: 락 기다리는 다음에 부여되었다 AUTO-INC 락이, 트랜잭션(transaction)가 종료할 때까지 유지되고 있었다. 이것에 의해서, 불필요한 데드 록이 발생할 가능성이 있었다.

  • 버그 수정: LOCK TABLES 안에서 텐포라리테이불을 작성해, 그 테이블을 사용하면,ha_innobase.cc 그리고 아서트에라가 발생하고 있었다.

  • 버그 수정: SHOW INNODB STATUS ,innodb_monitor , 또는 innodb_lock_monitor 그리고,1 회의 리포트에 수백의 트랜잭션(transaction)를 출력할 필요가 있는 경우에 출력을 잘라 버릴 수 있으면,srv0srv.c 의 1621 행목으로 작성되었다?~ 텍스에 대한 다수의 대기를 에러 로그에 출력할 때에 InnoDB 하지만 행 하고 있었다.

  • 버그 수정: Unix 그리고 SHOW INNODB STATUS (을)를 실행하면, 평균 파일 독해 사이즈가 항상 0 아르바이트로서 보고되고 있었다.

7.5.16.21. MySQL/InnoDB-4.0.4 (2002 년 10 월 2 일)

  • Windows 그리고, 버퍼 없음의 디스크 I/O 하지만 다시 사용되게 되었다.통상의 I/O 그럼,Windows XP 및 Windows 2000 (으)로의 독해의 퍼포먼스에 지장이 나온다고 생각된다.

  • InnoDB 테이블의 최대 키장이 500 아르바이트로부터 1,024 아르바이트에 확대되었다.

  • SHOW TABLE STATUS 의 테이블 코멘트 필드가 확대되고, 외부 키 정의를 16,000 문자까지 출력할 수 있게 되었다.

  • 로의 삽입이 실행 직후에 에러로 실패했을 경우에, 오토 인크리먼트(increment) 카운터가 인크리먼트(increment) 되지 않게 되었다.

  • innodb_force_recovery 하지만 설정되어 있는 경우에서도, 테이블을 파기 또는 작성할 수 있게 되었다.이것을 이용하고, 롤백(rollback) 또는 퍼지로 크래쉬를 일으키는 테이블을 파기하거나 테이블 임포트가 실패한 후의 리커버리로 롤백(rollback)가 폭주했을 경우에 테이블을 파기할 수 있다.

  • 버그 수정: 4.0.3 그리고 ORDER BY primarykey DESC (을)를 사용하면,btr0pcur.c 의 203 행목으로 아서트에라가 발생하고 있었다.

  • 버그 수정: 고속 슛다운(디폴트)이, 퍼지 또는 삽입 버퍼의 머지에 의해서 늦어지는 일이 있었다.

  • 버그 수정: 독해 일관성으로, 가시의 로가 존재하지 않는 테이블에 대해서 대규모 SELECT (을)를 실행하면,btr0cur.c 의 310 행목으로 장시간(600 초보다 길다)의 semaphore 대기가 발생할 가능성이 있었다.

  • 버그 수정: MySQL 쿼리 캐쉬가 사용되었을 경우에,ON DELETE CASCADE 또는 ...SET NULL 그리고 변경이 실행되어도 쿼리 캐쉬가 무효가 되지 않았다.

  • 버그 수정: LOCK TABLES 안에서 텐포라리테이불을 작성해, 그 테이블을 사용하면,ha_innodb.cc 그리고 아서트에라가 발생하고 있었다.

  • 버그 수정: innodb_flush_log_at_trx_commit (을)를 1 (으)로 설정하면,SHOW VARIABLES 그리고 그 값이1,600 만으로서 표시되고 있었다.

7.5.16.22. MySQL/InnoDB-4.0.3 (2002 년 8 월 28 일)

  • 삽입 시에, 락을 취득하는 독해, 갱신, 또는 삭제를 기다려 그 넥스트 키 록을 해방할 필요가 있는 경우에, 불필요한 데드 록이 발생하지 않게 되었다.

  • MySQL 의 HANDLER SQL 커멘드가,InnoDB 형태의 테이블에서도 동작하게 되었다.InnoDB (은)는,HANDLER 의 독해를 항상 일관한 독해로서 실행한다.HANDLER (은)는, 다이렉트 액세스 패스로 해서 테이블의 인덱스를 개별적으로 읽어낸다.경우에 따라서는,HANDLER (을)를 서버측 커서 대신에 사용할 수 있다.

  • 4.0.2 (으)로의 버그를 수정: 단순한 삽입이어도,AIX 버젼이 크래쉬 할 가능성이 있었다.

  • 버그 수정: DROP TABLE 그리고, 테이블명에 문자 코드가 127 보다 큰 문자를 사용하면,pars0sym.c 의 155 행목으로 InnoDB 하지만 아서트 할 가능성이 있었다.

  • 소스로부터의 컴파일로,HP-UX-11 및 HP-UX-10.20 의 양쪽 모두에 작업 버젼이 제공되게 되었다.이전에는,4.0.2 의 소스가 11 에서만 기능해,3.23.52 의 소스가 10.20 에서만 기능하고 있었다.

  • 버그 수정: 64 비트의 Solaris 그리고 컴파일 하면,InnoDB 의 기동시에 버스 에러가 발생하고 있었다.

7.5.16.23. MySQL/InnoDB-3.23.52 (2002 년 8 월 16 일)

  • 3.23 의 기능 세트는, 이 버젼보다 동결된다.새로운 기능은 4.0 브랜치로 도입되어3.23 브랜치에서는 버그의 수정만을 한다.

  • CPU 바운드의 결합 쿼리가 많고로, 실행이 빨라졌다.Windows 그럼, 그 외의 CPU 바운드의 쿼리도 실행이 빨라졌다.

  • 새로운 SQL 커멘드 SHOW INNODB STATUS 에 의해서,InnoDB 모니터의 출력이 클라이언트에 돌려주어지게 되었다.InnoDB 모니터로, 마지막에 검출된 데드 록에 관한 상세 정보가 출력되게 되었다.

  • InnoDB 그럼,SQL 쿼리Optimizer가 인덱스만의 범위 스캔을 다용하는 대신에 풀 테이블 스캔을 사용하고 있었다.이것이 수정되었다.

  • BEGIN 및 COMMIT 하지만 트랜잭션(transaction) 주변의 바이너리 로그에 추가되게 되었다. MySQL replication로 트랜잭션(transaction)의 경계가 고려되게 되었다.이것으로, replication 슬레이브로 유저에게 반의 트랜잭션(transaction)가 표시되지 않게 된다.

  • 크래쉬 리커버리로, replication 슬레이브가 마스터 바이너리 로그의 어느 위치까지 리커버리 할 수 있었는지가 출력되게 되었다.

  • 새로운 설정 innodb_flush_log_at_trx_commit=2 에 의해서,InnoDB 하지만 코?~ 트마다 operating system의 파일 캐쉬에 로그를 쓰게 되었다.그 속도는, 설정 innodb_flush_log_at_trx_commit=0 (와)과 거의 같다.또 설정 2 에는, 크래쉬가 발생해도 operating system가 크래쉬 하지 않으면 코?~ 트 된 트랜잭션(transaction)가 없어지지 않는다고 하는 뛰어난 특징이 있다. operating system의 크래쉬 또는 정전이 발생했을 경우는, 설정 2 의 안전성이 설정 0 보다 낮아진다.

  • 로그 블록에 체크 섬 필드가 추가되었다.

  • 외부 키의 규칙이 고려되지 않는 임의의 순서로의 테이블 임포트에서는,SET FOREIGN_KEY_CHECKS=0 하지만 도움이 된다.

  • 세칸다리인젝스에 UNIQUE 제약을 설정해 있는 경우에 SET UNIQUE_CHECKS=0 (을)를 지정하면,InnoDB 에의 테이블의 임포트가 빨라진다. 이 플래그는, 입력 레코드가 UNIQUE 제약에 위반하지 않은 것이 확실한 경우만 사용할 수 있다.

  • SHOW TABLE STATUS 그리고, 상정된다 ON DELETE CASCADE (이)나 ON DELETE SET NULL 도 테이블의 코멘트 필드에 열거되게 되었다.

  • InnoDB 형태의 테이블로 CHECK TABLE (을)를 실행하면, 모든 테이블의 해시 인덱스도 체크되게 되었다.

  • ON DELETE CASCADE 또는 SET NULL (을)를 정의해, 친레코드로 참조 키를 갱신하면,InnoDB 에 의해서 아이 레코드가 삭제 또는 갱신되고 있었다.이 동작이 변경되어SQL-92 에 준거하게 되었다.즉, 에러 'Cannot delete parent row' 하지만 표시되게 되었다.

  • 오토 인크리먼트(increment)의 알고리즘이 개선되어 최초의 삽입 또는 SHOW TABLE STATUS 그리고 테이블의 오토 인크리먼트(increment) 카운터가 초기화되게 되었다. 이것에 의해서,SHOW TABLE STATUS 그리고 돌연 데드 록이 발생하는 것이 거의 없어졌다.

  • 데이터 파일에의 독해와 기입에 사용되고 있던 일부의 버퍼가 조정되었다. 이것에 의해서,Linux 그리고 버퍼 없음의 로 디바이스를 데이터 파일로서 사용할 수 있게 되었다.

  • 버그 수정: 대문자와 소문자를 변경할 만한 목적으로 테이블의 주키를 갱신했을 경우에, 주로 page0page.ic 의 515 행목으로 아서트에라가 발생할 가능성이 있었다.

  • 버그 수정: 외부 키 제약으로 참조되고 있는 레코드를 삭제 또는 갱신하는 경우에, 외부 키 체크로 락 대기가 발생하면, 그 체크로부터 잘못된 결과가 보고되는 일이 있다.이것은,ON DELETE... 조작에도 영향을 준다.

  • 버그 수정: InnoDB 그리고 데드 록 또는 락 대기 타임 아웃 에러가 발생하면,InnoDB (은)는 트랜잭션(transaction) 전체를 롤백(rollback) 하지만,MySQL 하지만 이전의 SQL 스테이트먼트를(InnoDB 하지만 그것들을 롤백(rollback) 한 후도) 바이너리 로그에 써낼 가능성이 있었다.이 때문에, 예를 들어 레프리케이트 된 데이타베이스간에 동기가 잡히지 않게 되는 일이 있었다.

  • 버그 수정: 코?~ 트의 도중에 데이타베이스가 크래쉬 했을 경우에, 리커버리로 테이블 스페이스의 페이지가 리크 되는 일이 있었다.

  • 버그 수정: latin1 이외의 캐릭터 세트를 my.cnf 그리고 지정했을 경우에, 메뉴얼의 기술에 반하고, 외부 키 제약의 문자열형 컬럼의 길이의 지정을 참조원테이블과 참조처 테이블로 같게 해야 했다.

  • 버그 수정: CREATE TABLE 의 실행중에 DROP TABLE 또는 DROP DATABASE (을)를 실행하면, 실패할 가능성이 있었다.

  • 버그 수정: 32 비트 컴퓨터로 2 GB (을)를 넘는 버퍼 풀을 설정했을 경우에,InnoDB 하지만 buf0buf.ic 의 214 행목으로 아서트 하고 있었다.

  • 버그 수정: 64 비트 컴퓨터로, 어느 컬럼에 SQL NULL (을)를 포함하고 있는 레코드를 갱신했을 경우에,UNDO 로그와 통상의 로그가 파손할 가능성이 있었다.

  • 버그 수정: innodb_log_monitor 그리고 페이지에 대해서 락 출력을 억제하면 행이 발생하고 있었다.

  • 버그 수정: HP-UX-10.20 버젼에서는,?~ 텍스에 의해서 InnoDB 코드의 모든 부분에서 리크, 경합, 크래쉬가 발생하고 있었다.

  • 버그 수정: AUTOCOMMIT 모드로 SELECT (을)를 실행한 직후에 RENAME TABLE (을)를 실행하면,RENAME 하지만 실패해,MySQL (으)로부터 에러 1192 하지만 돌려주어지고 있었다.

  • 버그 수정: 64 비트의 Solaris 그리고 컴파일 하면,InnoDB 의 기동시에 버스 에러가 발생하고 있었다.

7.5.16.24. MySQL/InnoDB-4.0.2 (2002 년 7 월 10 일)

  • InnoDB (은)는 기본적으로 InnoDB-3.23.51 (와)과 같다.

  • innodb_data_file_path 하지만 지정되지 않을 때는,InnoDB 하지만 데이타베이스 작성시에 10 MB 의 자동 확장 데이터 파일 ibdata1 (을)를 MySQL 의 데이터 디렉토리에 작성하게 되었다.4.0.1 그럼, 파일이 64 MB 에 고정되어 자동적으로 확장되지 않았다.

7.5.16.25. MySQL/InnoDB-3.23.51 (2002 년 6 월 12 일)

  • 버그 수정: 테이블내의 BLOB 또는 TEXT 컬럼에 SQL NULL 값이 포함되어 있으면, 결합으로 이러한 컬럼을 카피할 때에 세그포르트가 발생할 가능성이 있었다.

  • 버그 수정: ON DELETE CASCADE (을)를 지정해 자기 참조형의 외부 키 제약을 테이블에 추가했을 경우에 레코드를 삭제하면, 캐스케이드 삭제를 위해서 InnoDB 하지만 같은 레코드를 2 회 삭제하려고 해 아서트에라가 발생하고 있었다.

  • 버그 수정: MySQL 의 ' 유저 레벨 락' (을)를 사용하고 접속을 닫으면,InnoDB 하지만 ha_innobase.cc 의 302 행목으로 아서트 하는 경우가 있다.

7.5.16.26. MySQL/InnoDB-3.23.50 (2002 년 4 월 23 일)

  • InnoDB 하지만 자동 확장하는 마지막 데이터 파일을 서포트하게 되었다.데이타베이스 기동시에, 데이터 파일 전체를 먼저 할당할 필요가 없어졌다.

  • InnoDB 핫 백업 툴을 사용하기 쉽게 하기 위해서 몇개의 변경을 했다.이 독립했다 non-free 툴에서는, 서버를 슛다운 하거나 락을 설정하거나 하는 일 없이, 데이타베이스를 온라인으로 백업 할 수 있다.

  • 자동 확장하는 데이터 파일로 InnoDB 핫 백업 툴을 실행하는 경우는, 이 툴을 버젼 ibbackup-0.35 에 업그레이드 할 필요가 있다.

  • 크래쉬 리커버리로의 로그 스캔이 빨라졌다.

  • 이 서버 버젼보다, 핫 백업 툴이 백업 InnoDB 데이터 파일의 말미의 미사용 부분을 잘라 버리게 되었다.

  • 핫 백업 툴을 기능시키기 위해서,Windows 그리고 버퍼 없음의 I/O 또는 네이티브의 비동기 I/O (이)가 아니고,Unix (와)과 같이 시?~ 레이트 된 비동기 I/O 하지만 사용되게 되었다.

  • 외부 키로 ON DELETE CASCADE 또는 ON DELETE SET NULL 마디를 정의할 수 있게 되었다.

  • 외부 키 제약이,ALTER TABLE 및 CREATE INDEX 그리고 살아 남게 되었다.

  • 체크되는 외부 키 또는 참조 키에 포함되는 컬럼치중 한쪽이 SQL NULL 이라고, 외부 키 체크가 억제된다.이 동작은,Oracle 등과 호환이다.

  • SHOW CREATE TABLE 그리고 외부 키 제약도 열거되게 되었다.mysqldump 그렇지만, 테이블 정의내의 외부 키가 출력되게 되었다.

  • 새로운 외부 키 제약을,ALTER TABLE ... ADD CONSTRAINT FOREIGN KEY (...) REFERENCES ... (...) 그리고 추가할 수 있게 되었다.

  • 외부 키의 정의로, 테이블명과 컬럼명을 박크크트로 둘러쌀 수 있게 되었다.

  • MySQL 의 커멘드 SET TRANSACTION ISOLATION LEVEL ... 하지만,InnoDB 테이블에 다음과 같이 작용하게 되었다.트랜잭션(transaction)가 SERIALIZABLE (으)로서 정의되고 있는 경우,InnoDB (은)는 모든 독해 일관성에 개념상 LOCK IN SHARE MODE (을)를 추가한다.트랜잭션(transaction)가 그 이외의 분리 레벨로 정의되고 있는 경우,InnoDB (은)는 그 디폴트의 락 방법이다 REPEATABLE READ 에 따른다.

  • 오토 인크리먼트(increment) 카운터가 벌써 초기화되고 있는 경우에,SHOW TABLE STATUS 그리고 오토 인크리먼트(increment) 인덱스의 말미에 x- 락이 설정되지 않게 되었다.이것에 의해서,SHOW TABLE STATUS 그리고 돌연 데드 록이 발생하는 것이 거의 없어진다.

  • 버그 수정: CREATE TABLE 스테이트먼트로 문자열 'foreign' 의 후에 공백 이외의 문자가 계속 되고 있으면,FOREIGN KEY 파서로 혼란이 생겨 테이블 작성이 에러 150 그리고 실패하고 있었다.

7.5.16.27. MySQL/InnoDB-3.23.49 (2002 년 2 월 17 일)

  • 버그 수정: 쿼리가 실행되고 있는 데이타베이스에 대해서 DROP DATABASE (을)를 호출하면,MySQL 서버가 크래쉬 또는 행 할 가능성이 있었다.크래쉬에 대해서는 수정되었지만, 완전하게 수정되려면 ,MySQL 코드 레이어로의 변경을 기다릴 필요가 있다.

  • 버그 수정: Windows 그리고 DROP DATABASE (을)를 실행하려면 , 데이타베이스명을 소문자로 지정할 필요가 있었다.3.23.49 그리고 수정: Windows 그럼 대문자와 소문자가 구별되지 않게 되었다.Unix 그럼 계속 데이타베이스명으로 대문자와 소문자가 구별된다.

  • 버그 수정: latin1 이외의 캐릭터 세트를 디폴트의 캐릭터 세트로서 정의하면, 외부 키 제약의 정의가 dict0crea.c (으)로의 아서트에라로 실패해, 내부 에러 17 하지만 보고될 가능성이 있었다.

7.5.16.28. MySQL/InnoDB-3.23.48 (2002 년 2 월 9 일)

  • SQL Optimizer로, 테이블 스캔보다 빈번한 인덱스 검색이 우선되게 되었다.

  • 멀티 프로세서 탑재의 Linux 컴퓨터로, 복수의 대규모 SELECT 쿼리가 동시에 실행되었을 경우의 퍼포먼스상의 문제가 해소되었다. CPU 바운드의 대규모 SELECT 쿼리의 실행도, 모든 플랫폼에서 한결같게 빨라진다.

  • MySQL 의 바이너리 로그가 사용되는 경우에,InnoDB 하지만 크래쉬 리커버리 후에 최신의 MySQL 바이너리 로그 파일의 이름과 그 파일의 어느 위치까지 리커버리 할 수 있었는지(= 아르바이트 오프셋)을 출력하게 되었다.이것은, replication로 master data 베이스와 슬레이브 데이타베이스를 재동기 시키는 경우 등에 도움이 된다.

  • 인스톨의 문제로 도움이 되도록(듯이), 보다 알기 쉬운 에러 메세지가 추가되었다.

  • InnoDB 테이블 스페이스내에서 친테이블을 잃었다 MySQL 텐포라리테이불도 리커버리 할 수 있게 되었다.

  • 외부 키의 선언으로, 참조원정수 컬럼과 참조처 정수 컬럼으로 부호의 유무가 차이가 나는 경우에,InnoDB 하지만 그 선언을 조?~ 하게 되었다.

  • 버그 수정: SHOW CREATE TABLE 또는 SHOW TABLE STATUS (을)를 호출하면, 메모리가 파손해,mysqld 하지만 크래쉬 할 가능성이 있었다. 특히,SHOW CREATE TABLE (을)를 빈번히 호출한다 mysqldump 그럼 위험성이 높았다.

  • 버그 수정: Unix 그리고 InnoDB 테이블에 대해서 ALTER TABLE (와)과 쿼리를 동시에 실행했을 경우에,mysqld 하지만 row0row.c 의 474 행목으로 아서트에라를 일으켜 크래쉬 할 가능성이 있었다.

  • 버그 수정: 오토 인크리먼트(increment) 컬럼을 포함하고 있는 복수의 테이블에의 삽입이 1 개의 LOCK TABLES 안에 랩 되고 있으면,InnoDB 하지만 lock0lock.c 그리고 아서트 하고 있었다.

  • 3.23.47 그럼, 일의의 세칸다리인젝스에 복수의 NULL 값이 있어도 상관없었다. 그런데 ,CHECK TABLE 에서는 테이블이 파손하고 있다고 보고되고 있었다. CHECK TABLE 하지만 이 상황으로 에러를 보고하지 않게 되었다.

  • 버그 수정: 빅 endian를 채용한다 Sparc 등의 프로세서로 SHOW VARIABLES (을)를 실행하면,innodb_flush_log_at_trx_commit 등의 불리언 값의 기동 파라미터가, 온이어도 항상 OFF (이)라고 표시되고 있었다.

  • 버그 수정: Windows NT/2000 그리고 mysqld-max-nt (을)를 서비스로서 실행했을 경우에, 그 서비스의 슛다운이,InnoDB 슛다운의 완료를 기다리지 않고 실행되고 있었다.

7.5.16.29. MySQL/InnoDB-3.23.47 (2001 년 12 월 28 일)

  • 리커버리가, 특히 부하의 가벼운 시스템으로 빨라졌다.이것은, 백그라운드에서 보다 빈번히 체크 포인트가 실행되게 되었기 때문이다.

  • 일의의 세칸다리인젝스로 유사하는 복수의 키치에 SQL NULL 하지만 포함되어 있으면,InnoDB 하지만 그러한 값을 허가하게 되었다.이것으로,MyISAM 테이블과 같은 규칙이 되었다.

  • BLOB (을)를 포함하고 있는 테이블에 대해 InnoDB 하지만 레코드수를 추정하는 정도가 향상했다.

  • 외부 키 제약으로,InnoDB 하지만 컬럼명(Windows 그럼 테이블명도)의 대문자와 소문자를 구별하게 되었다.

  • InnoDB 그럼,CHAR 형태의 외부 키 컬럼에 의한다 VARCHAR 형태의 컬럼의 참조, 및 그 반대의 참조가 가능하다.MySQL 에 의해서, 일부의 컬럼의 형태가 CHAR (와)과 VARCHAR 의 사이에 암묵적으로 변경된다.이 변경이 외부 키의 선언을 방해하는 것이 없어졌다.

  • 로그 파일의 파손에 대한 리커버리가 강화되었다.

  • 텐포라리테이불을 생성하는 쿼리로부터, 불필요한 통계 정보의 계산이 제거되었다.일부의 ORDER BY 쿼리와 DISTINCT 쿼리의 실행이 빨라졌다.

  • InnoDB 테이블의 테이블 스캔이 주키를 통해 실행되고 있는 것을,MySQL 하지만 인식하게 되었다.이것에 의해서, 일부의 ORDER BY 쿼리로 소트가 불필요하게 된다.

  • InnoDB 테이블의 최대 키장이 다시 500 아르바이트에 제한되었다. MySQL 인터프리터는 이것보다 긴 키를 처리할 수 없다.

  • innodb_lock_wait_timeout 의 디폴트치가 무한으로부터 50 초로 변경되어innodb_file_io_threads 의 디폴트치가 9 (으)로부터 4 (으)로 변경되었다.

7.5.16.30. MySQL/InnoDB-4.0.1 (2001 년 12 월 23 일)

  • InnoDB 하 3.23.47 (와)과 같다.

  • 4.0.0 그럼,MySQL 인터프리터가 구문 LOCK IN SHARE MODE (을)를 인식하지 않았다.이것이 수정되었다.

  • 4.0.0 그럼, 트랜잭션(transaction) 테이블에 대해서 복수 테이블의 삭제를 실행할 수 없었다. 이것이 수정되었다.

7.5.16.31. MySQL/InnoDB-3.23.46 (2001 년 11 월 30 일)

  • 3.23.45 (와)과 같다.

7.5.16.32. MySQL/InnoDB-3.23.45 (2001 년 11 월 23 일)

  • 이것은 버그 수정용 릴리스이다.

  • 버젼 3.23.42 ~ .44 그럼,Windows 그리고 테이블을 작성할 때에, 데이타베이스명에 소문자를 사용하지 않으면 테이블에 액세스 할 수 없었다.이것이 3.23.45 그리고 수정되었다.

  • InnoDB 하지만 stdout (와)과 stderr (을)를 10 초 간격으로 플래시 하게 되었다.이것들이 파일에 리디렉트 되면, 에디터로 파일의 내용을 참조하기 쉬워진다.

  • .44 그럼,.frm 파일은 작성되고 있지만 InnoDB 에 존재하지 않는 테이블을 파기하면,trx0trx.c 의 178 행목으로 아서트에라가 발생하고 있었지만, 이것이 수정되었다.

  • 삽입 버퍼로의 버그가 수정되었다. 삽입 버퍼 트리가 모순된 상태가 되어, 크래쉬 및 리커버리의 크래쉬도 일으킬 가능성이 있었다.이 버그는, 특히 테이블의 대규모 임포트나 변경으로 발생하고 있었다.

  • 리커버리로의 버그가 수정되었다.InnoDB 하지만, 버퍼 풀에 비어 블록이 없는 것을 통지하는 경고 메세지를 표시해 끊임 없이 엔들레스 루프에 들어갈 가능성이 있었다.

  • 버그 수정: InnoDB 형태의 텐포라리테이불을 작성해, 그 테이블에 대해서 ALTER TABLE (을)를 실행하면,MySQL 서버가 크래쉬 할 가능성이 있었다.

  • MySQL 의 시스템 테이블 'mysql.user' ,'mysql.host' , 또는 'mysql.db' (을)를 InnoDB 형태로 작성할 수 없게 되었다.

  • srv0srv.c 의 1728 행목으로 아서트에라를 일으킬 우려가 있다 3.23.44 (으)로의 버그가 수정되었다.

7.5.16.33. MySQL/InnoDB-3.23.44 (2001 년 11 월 2 일)

  • InnoDB 테이블로 외부 키 제약을 정의할 수 있다.례: FOREIGN KEY (col1) REFERENCES table2(col2)

  • 파일 시스템으로 허가되고 있으면,4 GB (을)를 넘는 데이터 파일을 작성할 수 있다.

  • InnoDB 모니터가 개선되었다.이것에는,InnoDB 내부 데이터 딕쇼내리의 내용을 출력하기 위한 새로운 파라미터 innodb_table_monitor 도 포함된다.

  • DROP DATABASE 하지만 InnoDB 테이블에서도 동작하게 되었다.

  • 디폴트의 캐릭터 세트이다 latin1 의 엑센트 문자가,MySQL 의 순서에 따라서 늘어놓을 수 있게 되었다. 주의: latin1 (을)를 사용하고 있는 경우에, 인덱스가 붙었다 CHAR 컬럼에 127 보다 큰 코드의 문자를 삽입했을 때는,3.23.43 에 업그레이드 할 경우에, 테이블에 대해서 CHECK TABLE (을)를 실행할 필요가 있다.CHECK TABLE (으)로부터 에러가 돌려주어졌을 경우는, 테이블을 파기해 한번 더 임포트 할 필요가 있다.

  • InnoDB 에 의한 테이브르카디나리티의 추정치의 계산 정도가 향상했다.

  • 데드 록의 해결 방법이 변경되었다. .43 그럼 데드 록이 발생하면 SQL 스테이트먼트만이 롤백(rollback) 되지만,.44 그럼 트랜잭션(transaction) 전체가 롤백(rollback) 된다.

  • 데드 록, 락 대기 타임 아웃, 및 외부 키 제약 위반(친레코드가 없는, 아이 레코드가 존재한다)이, 각각 네이티브의 MySQL 에러 코드 1213 ,1205 ,1216 ,1217 (을)를 돌려주게 되었다.

  • my.cnf 의 새로운 파라미터 innodb_thread_concurrency (은)는, concurrent processing가 빈번히 행해지는 환경에서의 퍼포먼스 튜닝에 도움이 된다.

  • my.cnf 의 새로운 옵션 innodb_force_recovery (은)는, 파손한 데이타베이스로부터 테이블을 덤프 할 때에 도움이 된다.

  • my.cnf 의 새로운 옵션 innodb_fast_shutdown (은)는, 슛다운을 고속화한다.통상,InnoDB (은)는 슛다운시에 완전한 퍼지와 삽입 버퍼의 머지를 실행한다.

  • 최대 키장이 이전의 제한치이다 500 아르바이트로부터 7,000 아르바이트에 끌어 올려졌다.

  • 복수행 삽입을 수반하는 오토 인크리먼트(increment) 컬럼의 replication로의 버그가 수정되었다.

  • 인덱스가 붙은 세칸다리카람의 갱신으로, 대문자와 소문자가 변경될 때의 버그가 수정되었다.

  • 데이터 파일의 수가 24 개를 넘었을 경우에 발생하는 행이 수정되었다.

  • 하늘의 테이블에서 MAX(col) 하지만 선택될 때에,col 하지만 복합 인덱스의 최초의 컬럼이 아닌 경우에 발생하고 있던 크래쉬가 수정되었다.

  • 크래쉬의 원인이 될 수 있는 퍼지로의 버그가 수정되었다.

7.5.16.34. MySQL/InnoDB-3.23.43 (2001 년 10 월 4 일)

  • 기본적으로 InnoDB-3.23.42 (와)과 같다.

7.5.16.35. MySQL/InnoDB-3.23.42 (2001 년 9 월 9 일)

  • 8,000 아르바이트를 넘는 레코드의 주키가 갱신되었을 경우에 테이블이 파손하는 버그가 수정되었다.

  • InnoDB 모니터의 종류가,innodb_monitor ,innodb_lock_monitor ,innodb_tablespace_monitor 의 3 개가 되었다. innodb_monitor 그리고, 버퍼 풀의 히트율, 및 삽입, 갱신, 삭제, 독해를 한 레코드의 총수가 새롭게 출력되게 되었다.

  • RENAME TABLE (으)로의 버그가 수정되었다.

  • 오토 인크리먼트(increment) 컬럼을 수반하는 replication로의 버그가 수정되었다.

7.5.16.36. MySQL/InnoDB-3.23.41 (2001 년 8 월 13 일)

  • 4 GB 미만의 레코드를 서포트한다.이전의 제한은 8,000 아르바이트.

  • 이중 기입 파일 플래시 방식을 채용했다.

  • 로 디바이스를 데이터 파일로서 서포트한다.

  • InnoDB 모니터.

  • 행의 원인이 되는 복수의 버그, 및 ORDER BY 의 버그('Sort aborted' )(이)가 수정되었다.

7.5.16.37. MySQL/InnoDB-3.23.40 (2001 년 7 월 16 일)

  • 발생 빈도의 낮은 몇 개의 버그만이 수정되었다.

7.5.16.38. MySQL/InnoDB-3.23.39 (2001 년 6 월 13 일)

  • CHECK TABLE 하지만 InnoDB 테이블에서도 동작하게 되었다.

  • my.cnf 의 새로운 파라미터 innodb_unix_file_flush_method 하지만 추가되었다.이 파라미터는, 디스크 기입 퍼포먼스의 튜닝에 사용할 수 있다.

  • 오토 인크리먼트(increment) 컬럼이, 트랜잭션(transaction) 메카니즘을 통하지 않고 새로운 값을 취득하게 되었다.이것에 의해서, 새로운 값을 할당할 때의 CPU 시간이 삭감되어 트랜잭션(transaction) 데드 록이 배제된다.

  • 3.23.38 (으)로의 복수의 버그, 특히 롤백(rollback)로의 버그가 수정되었다.

7.5.16.39. MySQL/InnoDB-3.23.38 (2001 년 5 월 12 일)

  • 새로운 구문 SELECT ... LOCK IN SHARE MODE 하지만 도입되었다.

  • 디스크에의 기입을 할 때마다,InnoDB 하지만 fsync() (을)를 호출해, 써 또는 독해를 실시하는 모든 데이타베이스 페이지의 체크 섬을 계산해 디스크의 불편을 분명히 하게 되었다.

  • 복수의 버그가 수정되었다.

7.5.17. InnoDB 에 대한 문의처

InnoDB 엔진의 제조원이다 Innobase Oy 의 문의처는 다음과 같습니다. Web 사이트: http://www.innodb.com/ . 전자 메일: <sales@innodb.com>

phone: 358-9-6969 3250 (office) 358-40-5617367 (mobile)
Innobase Oy Inc.
World Trade Center Helsinki
Aleksanterinkatu 17
P.O.Box 800
00101 Helsinki
Finland


7.6. BDB 또는 BerkeleyDB 테이블

7.6.1. BDB 테이블의 개요

BerkeleyDB (http://www.sleepycat.com/ 그리고 입수 가능)은,MySQL 에 트랜잭션(transaction) 스토리지 엔진을 가져왔습니다.이 스토리지 엔진의 서포트는, 버젼 3.23.34 (으)로부터 MySQL 소스 디스트리뷰션에 짜넣어지게 되어,MySQL-Max 바이너리로 액티브화 됩니다.통상, 이 스토리지 엔진은 생략해 BDB (으)로 불립니다.

BDB 테이블은 크래쉬에 대한 내구성이 높고, 트랜잭션(transaction)로의 COMMIT 및 ROLLBACK 조작에도 대응합니다. MySQL 소스 디스트리뷰션에 부속된다 BDB 디스트리뷰션에는,MySQL 그리고 보다?~ 활에 동작하기 위한 소규모의 패치가 몇개인가 적용되고 있습니다. 패치가 적용되지 않았다 BDB 버젼은,MySQL 그리고 사용할 수 없습니다.

MySQL AB (은)는,Sleepycat 회사와 밀접하게 협력하면서,MySQL/BDB 인터페이스의 품질 유지에 노력하고 있습니다.

BDB 테이블의 서포트에 관해서는, 유저에 의한 문제의 특정을 지원 함과 동시에,BDB 테이블이 관계하는 모든 문제에 대한 재현 가능한 시험대의 작성을 지원하고 있습니다.작성된 시험대는 Sleepycat 회사에 보내져 동사의 지원을 받으면서 문제를 특정해 수정합니다.이와 같이 2 단계의 작업이 되기 위해,BDB 테이블의 문제는, 다른 스토리지 엔진보다 수정에 약간 시간이 걸리는 경우가 있습니다. 다만,BerkeleyDB 코드 자체는 지금까지 MySQL 이외가 많은 어플리케이션으로 사용되고 있기 때문에, 큰 문제가 발생하는 것은 생각할 수 있습니다. See 항1.4.1. 「MySQL AB 에 의해서 제공되는 서포트」 .

7.6.2. BDB 의 인스톨

BerkeleyDB (을)를 서포트한다 MySQL 의 바이너리 버젼을 다운로드했을 경우는,MySQL 의 바이너리 버젼을 인스톨하기 위한 지시에 따라 주세요. See 항2.2.9. 「MySQL 바이너리 디스트리뷰션의 인스톨」 . See 항4.8.5. 「mysqld-max (확장 mysqld 서버)」 .

Berkeley DB (을)를 서포트한다 MySQL (을)를 컴파일 하려면 ,MySQL 버젼 3.23.34 이?~ (을)를 다운로드해,--with-berkeley-db 옵션을 사용해 MySQL (을)를 콘피개 합니다. See 항2.3. 「MySQL 소스 디스트리뷰션의 인스톨」 .

cd /path/to/source/of/mysql-3.23.34
./configure --with-berkeley-db

자세한 최신 정보에 대해서는,BDB 디스트리뷰션 부속의 메뉴얼을 참조해 주세요.

Berkeley DB 자체는 충분히 테스트되고 있어 신뢰할 수 있습니다만,MySQL (와)과의 인터페이스는 아직 감마 품질이라고 보여지고 있습니다. 당사는, 이 인터페이스의 1 일도 빠른 안정화를 목표로 하고, 적극적으로 개선과 최적화를 실시하고 있습니다.

7.6.3. BDB 기동 옵션

AUTOCOMMIT=0 그리고 실행하고 있는 경우,BDB 테이블로의 변경은 COMMIT (을)를 실행할 때까지 반영되지 않습니다.코?~ 트 대신에 ROLLBACK (을)를 실행하면, 변경이 무효가 됩니다. See 항6.7.1. 「START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문」 .

AUTOCOMMIT=1 (디폴트)(으)로 실행하고 있는 경우는, 변경이 즉시 코?~ 트 됩니다.SQL 커멘드 BEGIN WORK 그리고 확장 트랜잭션(transaction)를 개시할 수 있습니다.그 경우,COMMIT (을)를 실행할 때까지(또는 변경의 ROLLBACK (을)를 실행할 때까지) 변경이 코?~ 트 되지 않습니다.

다음에 나타낸다 mysqld 의 옵션을 사용하면,BDB 테이블의 동작을 변경할 수 있습니다.

옵션 | 설명
--bdb-home=directory | BDB 테이블의 베이스 디렉토리.--datadir 에 사용하는 디렉토리와 같지 않으면 안 된다.
--bdb-lock-detect=# | Berkely 의 락 검출.DEFAULT ,OLDEST ,RANDOM , 또는 YOUNGEST 의 언젠가.
--bdb-logdir=directory | Berkeley DB 의 로그 파일 디렉토리.
--bdb-no-sync | 로그를 동기적으로 플래시 하지 않는다.
--bdb-no-recover | Berkeley DB (을)를 리커버리 모드로 기동하지 않는다.
--bdb-shared-data | Berkeley DB (을)를 멀티 프로세스 모드로 기동한다(Berkeley DB (을)를 초기화할 때에 DB_PRIVATE (을)를 사용하지 않는다).
--bdb-tmpdir=directory | Berkeley DB 의 임시 파일 디렉토리.
--skip-bdb | BDB 테이블의 사용을 무효로 한다.
-O bdb_max_lock=1000 | 락의 수의 상한을 설정한다. See 항4.6.8.4. 「SHOW VARIABLES 」 .

--skip-bdb (을)를 사용하면,MySQL 하 Berkeley DB 라이브러리를 초기화하지 않게 되기 위해, 대량의 메모리를 절약할 수 있습니다.이 옵션을 사용하고 있을 때는 BDB 테이블을 사용할 수 없습니다.BDB 테이블을 작성하려고 하면, 대신에 MyISAM 테이블이 작성됩니다.

BDB 테이블을 사용할 예정이면, 통상은 --bdb-no-recover (을)를 지정하지 않고 mysqld (을)를 기동할 필요가 있습니다.다만,BDB 로그 파일이 파손하고 있는 경우에 mysqld (을)를 기동하려고 하면, 문제가 발생할 가능성이 있습니다. See 항2.4.2. 「MySQL 서버의 기동에 관한 문제」 .

bdb_max_lock 그럼,BDB 테이블로 액티브하게 할 수 있는 락의 최대수(디폴트는 10,000 )(을)를 지정할 수 있습니다.긴 트랜잭션(transaction)를 실행하고 있을 때나,mysqld 하지만 쿼리의 계산으로 대량의 레코드를 조사하고 있을 때,bdb: Lock table is out of available locks 또는 Got error 12 from ... 그렇다고 하는 에러가 발생하는 경우는, 이 수치를 크게 해 주세요.

또, 대규모 트랜잭션(transaction)를 사용하는 경우는,binlog_cache_size 및 max_binlog_cache_size (을)를 변경할 수도 있습니다. See 항6.7.1. 「START TRANSACTION ,COMMIT ,ROLLBACK 의 각 구문」 .

7.6.4. BDB 테이블의 특성

  • BDB 스토리지 엔진은, 트랜잭션(transaction)를 롤백(rollback) 할 수 있도록(듯이) 로그 파일을 보관 유지하고 있다.퍼포먼스를 최대한으로 높이려면 ,--bdb-logdir 옵션을 사용해 이러한 로그 파일을 데이타베이스와는 다른 디스크에 배치할 필요가 있다.

  • MySQL (은)는, 새롭다 BDB 로그 파일이 개시될 때마다 체크 포인트를 실행해, 현재의 트랜잭션(transaction)에 불필요한 로그 파일을 삭제한다.FLUSH LOGS (을)를 임의의 시점에서 실행하고,Berkeley DB 테이블을 체크 포인트 할 수도 있다.

    장해 리커버리에는, 테이블 백업 및 MySQL 의 바이너리 로그를 사용할 필요가 있다. See 항4.5.1. 「데이타베이스의 백업」 .

    경고: 사용중이 낡은 로그 파일을 삭제하면, 문제가 발생했을 경우에 BDB 하지만 리커버리를 실행할 수 없게 되어, 데이터가 없어질 우려가 있다.

  • MySQL (은)는, 전에 읽어내진 레코드를 참조할 수 있도록, 각 BDB 테이블에 주키 (을)를 필요로 한다.유저가 이 키를 작성하지 않는 경우는,MySQL 에 의해서 은폐 주키 하지만 작성되어 관리된다.이 은폐 키는 길이가 5 아르바이트로, 삽입이 시행될 때마다 인크리먼트(increment) 된다.

  • BDB 테이블로 액세스 하는 모든 컬럼이, 같은 인덱스의 일부 또는 주키의 일부에서 있으면,MySQL (은)는 실제의 레코드에 액세스 하는 일 없이 쿼리를 실행할 수 있다.MyISAM 테이블에서는, 컬럼이 같은 인덱스의 일부인 경우만 이것이 들어맞는다.

  • 주키 (은)는, 로 데이터와 함께 격납되기 위해, 다른 어느 키보다 빠르게 처리된다.다른 키는 키 데이터 + 주키 (으)로서 격납되기 위해, 주키 (은)는 가능한 한 짧게 해 디스크를 절약해, 처리 속도를 높이는 것이 중요하다.

  • LOCK TABLES (은)는, 다른 테이블과 같게 BDB 테이블에서도 동작한다.LOCK TABLE (을)를 사용하지 않는 경우는,MySQL 에 의해서 테이블에 대한 내부적인 복수 기입의 락이 발행되어 다른 스레드가 테이블 락을 발행했을 경우에 테이블이 적절히 락 되게 된다.

  • BDB 테이블로의 내부 락은, 페이지 레벨로 행해진다.

  • BDB 테이블에서는 테이블내의 레코드수의 카운트가 관리되지 않기 때문에,SELECT COUNT(*) FROM table_name 에 시간이 걸린다.

  • BDB 테이블의 데이터는, 독립한 데이터 파일은 아니고 B 트리에 격납되기 위해, 차례차례 스캔에는 MyISAM 테이블보다 시간이 걸린다.

  • 어플리케이션에서는,BDB 테이블의 변경으로 발생하는 자동 롤백(rollback) 및 데드 록 에러를 수반하는 독해의 실패에 언제라도 대처할 수 있도록 해 둘 필요가 있다.

  • MyISAM 테이블의 키와는 달라, 키의 프리픽스 또는 사픽스는 압축되지 않는다.즉,BDB 테이블에서는 MyISAM 테이블에 비해 키 정보의 영역이 약간 크다.

  • BDB 테이블에는, 많은 경우, 키 트리의 도중에 새로운 레코드를 삽입할 수 있도록 빈틈이 비어 있다.이 때문에,BDB 테이블은 MyISAM 테이블보다 약간 커진다.

  • Optimizer에는, 테이블내의 대체로의 레코드수를 통지할 필요가 있다.MySQL (은)는, 삽입의 회수를 카운트 해, 그 수치를 BDB 테이블내의 독립한 세그먼트(segment)로 관리하는 것으로, 이것에 대응하고 있다.DELETE 또는 ROLLBACK 스테이트먼트를 대량으로 발행하지 않는 한, 이 수치는 MySQL Optimizer에 있어서 충분히 정확하지만,MySQL (은)는 클로우즈시까지 이 수치를 격납하지 않기 때문에,MySQL 하지만 돌연 중단되면 수치가 부정확하게 되는 경우가 있다.이 수치가 100% 정확하지 않아도, 치명적인 문제는 되지 않는다.레코드의 수는,ANALYZE TABLE 또는 OPTIMIZE TABLE (을)를 실행하는 것으로 갱신할 수 있다. See 항4.6.2. 「ANALYZE TABLE 구문」 . See 항4.6.1. 「OPTIMIZE TABLE 구문」 .

  • BDB 테이블로 디스크가 가득 차면, 에러(아마 에러 28 )(이)가 발생해, 트랜잭션(transaction)가 롤백(rollback) 된다.이것과는 대조적으로,MyISAM 테이블과 ISAM 테이블에서는, 충분한 빈디스크가 확보되는 것을 기다리고,mysqld 하지만 처리를 속행한다.

7.6.5. 가까운 장래에 수정할 필요가 있다 BDB 의 문제

  • 다수의 BDB 테이블을 동시에 열 때에 꽤 시간이 걸린다.BDB 테이블을 사용하는 경우는, 테이블 캐쉬를 별로 크게 하지 않게 한다(예를 들어 256 이하로 할) 필요가 있다.또,mysql 클라이언트로 --no-auto-rehash (을)를 사용할 필요가 있다.이것에 대해서는,4.0 그리고 부분적으로 수정할 예정이다.

  • SHOW TABLE STATUS 그리고 BDB 테이블에 관해서 제공되는 정보가 아직 충분하지 않다.

  • 퍼포먼스를 최적화한다.

  • 테이블을 스캔 할 경우에 페이지 락을 일절 사용하지 않게 변경한다.

7.6.6. BDB 그리고 서포트되고 있는 operating system

현재,BDB 스토리지 엔진은 다음의 operating system로 동작하는 것이 확인되고 있습니다.

  • Linux 2.x Intel

  • Sun Solaris (sparc 및 x86 )

  • FreeBSD 4.x/5.x (x86 ,sparc64 )

  • IBM AIX 4.3.x

  • SCO OpenServer

  • SCO UnixWare 7.1.x

다음의 operating system에서는 동작하지 않습니다.

  • Linux 2.x Alpha

  • Linux 2.x AMD64

  • Linux 2.x IA64

  • Linux 2.x s390

  • Max OS X

주의: 상기의 일람은 완전하지는 않습니다.정보가 들어가는 대로 갱신할 예정입니다.

BDB 테이블의 서포트 첨부로 MySQL (을)를 빌드 하는 경우에,mysqld (을)를 기동하면 로그 파일에 다음의 에러가 기록되는 일이 있습니다.

bdb: architecture lacks fast mutexes: applications cannot be threaded
Can't init databases

이것은, 사용하는 아키텍쳐로 BDB 테이블이 서포트되어 있지 않은 것을 의미합니다. 이 경우는,BDB 테이블의 서포트 없이 MySQL (을)를 빌드 다시 할 필요가 있습니다.

7.6.7. BDB 테이블의 제한 사항

다음에 드는 것은,BDB 테이블을 사용하는 경우의 제한 사항입니다.

  • BDB 테이블은,.db 파일에, 작성되었을 때의 이 파일에의 패스를 격납한다 (이것은, 기호 연결을 서포트하는 multiuser 환경에서 락을 검출할 수 있듯이 하기 위해서 행해진다).

    이 때문에,BDB 테이블은 디렉토리간에서 이동할 수 없다.

  • BDB 테이블의 백업을 취할 때는,mysqldump (을)를 사용하는지, 모든 table_name.db 파일과 BDB 로그 파일의 백업을 취할 필요가 있다.BDB 의 로그 파일은, 베이스 데이터 디렉토리에 있다 log.XXXXXXXXXX (10 자리수)라는 이름의 파일이다. BDB 스토리지 엔진은 미완료의 트랜잭션(transaction)를 로그 파일에 격납한다.이러한 로그는,mysqld 하지만 기동될 때 존재하고 있지 않으면 안 된다.

7.6.8. BDB 테이블을 사용할 경우에 일어날 수 있는 에러

  • mysqld (을)를 기동할 때에 hostname.err 로그 에 다음의 에러가 기록되는 일이 있다.

    bdb:  Ignoring log file: .../log.XXXXXXXXXX: unsupported log version #

    이것은, 새로운 버젼의 BDB 하지만 낡은 로그 파일 형식을 서포트하고 있지 않는 것을 의미한다.이 경우는, 데이타베이스 디렉토리로부터 모든 BDB 로그(log.XXXXXXXXXX 그렇다고 하는 형식의 이름을 가지는 파일)을 삭제해,mysqld (을)를 재기동할 필요가 있다.또, 낡다 BDB 테이블의 mysqldump --opt (을)를 실행한 데다가, 그 테이블을 삭제해, 덤프를 restore 하는 것이 좋다.

  • 오트코?~ 트모드로 실행하고 있지 않는 경우에, 다른 트랜잭션(transaction)로 참조되고 있는 테이블을 삭제하면,MySQL 에러 로그에 다음의 에러 메세지가 기록되는 일이 있다.

    001119 23:43:56  bdb:  Missing log fileid entry
001119 23:43:56  bdb:  txn_abort: Log undo failed for LSN:
                       1 3644744: Invalid

    이것은 치명적인 에러는 아니지만, 이 문제가 수정될 때까지는(작은 수정은 아니다), 오트코?~ 트모드가 아닐 때에 테이블을 삭제하지 않는 것이 좋다.


제8 장 MaxDB 의 개요

목차

8.1. MaxDB 의 역사
8.2. 라이센스와 서포트
8.3. MaxDB 의 기본 개념
8.4. MaxDB (와)과 MySQL 의 차이점
8.5. MaxDB (와)과 MySQL 의 상호 운용성
8.6. MaxDB 관련 링크
8.7. MaxDB 의 예약어(reserved word)

MaxDB (은)는, 엔터프라이즈 레벨의 데이타베이스입니다.이전에 SAP DB (으)로 불리고 있던 데이타베이스 관리 시스템이,MaxDB 그렇다고 하는 새로운 이름이 되었습니다.

8.1. MaxDB 의 역사

SAP DB 의 역사는 1980 연대 초로 거슬러 올라갑니다.그 당시 ,SAP DB 하 Adabas (상용 제품의 1 개)로서 개발되었습니다.이래, 이 데이타베이스는 몇차례에 걸쳐서 명칭이 변경되고 있습니다.독일의 워르드르후에 본사를 짓는다 SAP AG 하지만 데이타베이스 시스템의 개발을 계승한 시점에서는,SAP DB 그렇다고 하는 명칭이었습니다.

SAP 그럼, 견뢰한 SAP 어플리케이션의 모두에게 대응하는 단일의 스토리지 시스템으로서 기능하도록(듯이), 데이타베이스 시스템을 진화시켰습니다.그것이 R/3 입니다.SAP DB (은)는, 써드파티제 데이타베이스 시스템(Oracle ,Microsoft SQL Server ,IBM 의 DB2 등)에 대신하는 선택사항으로서 제공되었습니다.2000 년 10 달,SAP AG 하 GNU GPL 라이센스(see 부록 H. GNU General Public License )에 근거해 SAP DB (을)를 공개해, 오픈 소스 소프트웨어로 했습니다.2003 년 10 달,SAP AG 의 고객 중 2,000 회사 이상은, 자사의 메인 데이타베이스 시스템으로서 SAP DB (을)를 사용하고 있었습니다.또, 다른 2,000 회사 이상은, 자사의 메인 데이타베이스와는 다른 독립한 데이타베이스 시스템으로서 SAP DB (을)를 사용해,APO/LiveCache 솔루션의 일부로 하고 있었습니다.

2003 년 5 달,MySQL AB (와)과 SAP AG 의 사이에 기술 파트너십이 형성되었습니다.이 파트너십에 의해,MySQL AB 하 SAP DB 의 개발을 한층 더 추진해, 명칭을 변경할 수 있습니다.또,GNU GPL (see 부록 H. GNU General Public License )에 근거해 이 데이타베이스를 사용할 때의 제한으로 구속되는 것을 바라지 않는 고객에 대해, 명칭이 변경되었다 SAP DB 의 상용 라이센스를 판매할 권리도 부여됩니다.2003 년 8 달,MySQL AB 에 의해서 SAP DB 의 명칭은 MaxDB (으)로 변경되었습니다.


8.2. 라이센스와 서포트

MySQL AB (으)로부터 배포된 다른 제품에 관해서 제공된 라이센스(( 항1.4.3. 「MySQL 라이센스」 )에 근거해,MaxDB 도 사용하는 것이 가능합니다.따라서,GNU 일반 공중 이용 허락 계약서( 부록 H. GNU General Public License )(와)과 상용 라이센스( 항1.4. 「MySQL 의 서포트와 라이센스」 )에 근거해 MaxDB (을)를 사용할 수 있게 됩니다.

MySQL 그럼,SAP 유저 이외의 고객에 대해서 MaxDB 서포트를 제공할 예정입니다.

그러한 재브랜드화 버젼의 제 1 총알로서MaxDB 7.5.00 하지만 2003 해후기에 릴리스 되었습니다.


8.3. MaxDB 의 기본 개념

MaxDB (은)는, 클라이언트/ 서버 제품으로서 동작합니다.인스톨레이션 환경에서 온라인 트랜잭션(transaction)를 대량으로 처리하는 필요성을 채우기 위해서 개발되었습니다.온라인 백업과 데이타베이스 확장이 서포트되고 있습니다.Microsoft 클러스터 서버는 복수 서버 도입에 직접 대응하고 있습니다만, 다른 페르오바소류션은 메뉴얼로 스크립트화할 필요가 있습니다.데이타베이스 관리툴은,Windows 및 브라우저 베이스의 도입의 양쪽 모두로 제공됩니다.


8.4. MaxDB (와)과 MySQL 의 차이점

MaxDB (와)과 MySQL 의 주된 차이를 이하에 나타냅니다 ( 개요이며, 완전한 것이 아닙니다) .

  • MaxDB (은)는, 클라이언트/ 서버 시스템으로서 동작합니다.MySQL (은)는, 클라이언트/ 서버 시스템 또는 조입시스템으로서 실행할 수 있습니다.

  • MySQL 에 의해서 서포트되고 있는 플랫폼의 일부에서는,MaxDB 하지만 동작하지 않는 경우도 있습니다.예를 들어,MaxDB 하 IBM 의 OS/2 그럼 동작하지 않습니다.

  • MaxDB 그럼, 클라이언트/ 서버 통신에 전용 네트워크 프로토콜이 사용됩니다.그에 대해 MySQL 그럼,TCP/IP (SSL 암호화 있어/ 없음), 소켓(UNIX 좋아하는 시스템의 경우), 이름 파이프(Windows NT 파?~ 리시스템의 경우)중 한쪽이 사용됩니다.

  • MaxDB (은)는, Stored Procedure를 서포트하고 있습니다.MySQL 의 경우, Stored Procedure의 도입은 버젼 5.0 (으)로부터됩니다.MaxDB 그럼 SQL 확장을 개입시킨 Trigger의 프로그라?~ 그도 서포트하고 있습니다만, 이 기능은 MySQL 5.1 그리고 예정되어 있습니다.MaxDB (은)는, Stored Procedure 언어의 디버거를 내장하고 있습니다.또, 네스트 된 Trigger의 캐스케이드가 가능하고, 액션 및 행 단위의 복수 Trigger를 서포트합니다.

  • MaxDB 의 디스트리뷰션에는, 텍스트 베이스, 그래피컬 베이스,Web 베이스의 몇개의 유저 인터페이스가 포함되어 있습니다.MySQL 의 디스트리뷰션에는, 텍스트 베이스의 유저 인터페이스 밖에 포함되어 있지 않습니다.그래피컬 유저 인터페이스(MySQL Control Center )(은)는, 주요 디스트리뷰션과는 별도로 제공됩니다.MySQL 의 Web 베이스 유저 인터페이스는, 써드파티로부터 제공되고 있습니다.

  • MaxDB 하지만 서포트하는 다수의 프로그라?~ 그인타페스는,MySQL 그렇지만 서포트되고 있습니다.다만,RDO ,ADO ,.NET 하 MaxDB 그럼 서포트되지 않고, 모두 MySQL 그럼 서포트되고 있습니다.MaxDB 그럼,C/C++ 에서만 매입 SQL 하지만 서포트됩니다.

  • 이하의 관리 기능은 MaxDB 에 포함되어 있습니다만,MySQL 에는 포함되어 있지 않습니다. 시각, 이벤트, 경고에 의한 죠브스케쥬링이라고 경고해 귀의치에 근거하는 데이타베이스 관리자에게의 메세지 송신


8.5. MaxDB (와)과 MySQL 의 상호 운용성

최초의 7.5.00 버젼의 직후에 공개된다 MaxDB 버젼에는, 이하의 기능이 포함될 예정입니다.이러한 기능에 의해,MaxDB (와)과 MySQL 의 상호 운용성이 확보됩니다.

  • MySQL 프록시에서는,MySQL 프로토콜을 사용해 MaxDB 에 접속할 수 있게 됩니다.이것에 의해서,mysql 커멘드 라인 유저 인터페이스,mysqldump 덤프 유틸리티, 또는 mysqlimport 임포트 프로그램과 같이,MySQL 클라이언트 프로그램을 MaxDB 에 대해서 사용할 수 있습니다.mysqldump (을)를 사용하면, 데이터를 데이타베이스 시스템으로부터 덤프 해, 다른 데이타베이스 시스템에 export ( 파이프) 하는 것이 용이하게 됩니다.

  • MySQL (와)과 MaxDB 의 사이의 replication는 쌍방향으로 서포트됩니다.즉,MySQL (와)과 MaxDB 의 어느쪽이든을 마스터 replication 서버로서 사용할 수 있습니다.replication 구문을 모아 확장해, 양쪽 모두의 데이타베이스 시스템으로 같은 구문이 인식되도록(듯이) 하는 것이 장기적인 계획이 되고 있습니다. See 항4.11.1. 「처음에」 .


8.6. MaxDB 관련 링크

MaxDB 관련 정보의 메인 페이지는 http://www.mysql.com/maxdb 입니다.http://www.sapdb.org 의 게재 정보는 모두, 메인 페이지에 최종적으로 이동될 예정입니다.


8.7. MaxDB 의 예약어(reserved word)

MySQL (와)과 같이 MaxDB 에도, 특수한 의미를 가지는 다수의 예약어(reserved word)가 있습니다. 예약어(reserved word)는 통상, 데이타베이스명이나 테이블명 등, 식별자의 명칭으로서 사용할 수 없습니다.MaxDB 의 예약어(reserved word), 예약어(reserved word)의 사용 문맥, 대응하는 예약어(reserved word)가 MySQL 에 존재할지의 구별이, 이하의 겉(표)에 나타나고 있습니다.대응하는 예약어(reserved word)가 존재하는 경우,MySQL (으)로의 의미는 일치하기도 하면, 다소 다르기도 합니다.MaxDB 하지만 어느 점으로 MySQL (와)과 다른지를 나타내는 것이 주된 목적이므로, 이 일람은 완전한 내용이 아닙니다.

MySQL 의 예약어(reserved word) 일람에 대해서는,See 항6.1.7. 「MySQL (으)로의 예약어(reserved word)의 취급」 (을)를 참조해 주세요.

MaxDB 그리고 예약제 | MaxDB (으)로의 사용 문맥 | 대응한다 MySQL 의 예약어(reserved word)
@ | 식별자의 전에 붙일 수 있다(``@table'' 등). | 사용할 수 없다.
ADDDATE() | SQL 함수 | ADDDATE() .MySQL 버젼 4.1.1 그리고 추가.
ADDTIME() | SQL 함수 | ADDTIME() .MySQL 버젼 4.1.1 그리고 추가.
ALPHA | SQL 함수 | 유사하는 것이 존재하지 않는다.
ARRAY | 데이터형 | 실장되어 있지 않다.
ASCII() | SQL 함수 | ASCII() .다만, 다른 의미로 실장되고 있다.
AUTOCOMMIT | 트랜잭션(transaction).디폴트에서는 ON . | 트랜잭션(transaction).디폴트에서는 OFF .
BOOLEAN | 컬럼형.BOOLEAN 하 TRUE ,FALSE ,NULL 만을 값으로 해서 받는다. | BOOLEAN (을)를 MySQL 버젼 4.1.0 그리고 추가.BOOL 의 동의어이며,TINYINT(1) 에 매핑 되고 있다.NULL 외,TINYINT (와)과 같은 범위에서 정수치를 받는다.TRUE (와)과 FALSE (은)는,1 (와)과 0 의 앨리어스(alias)로서 사용할 수 있다.
CHECK | CHECK TABLE | CHECK TABLE .사용 방법은 유사하고 있지만, 동일하지 않다.
COLUMN | 컬럼형 | COLUMN .노이즈 워드.
CHAR() | SQL 함수 | CHAR() .동일한 구문.사용 방법은 유사하고 있지만, 동일하지 않다.
COMMIT | 데이터 정의 쿼리의 발행중에 트랜잭션(transaction)의 암묵적인 코?~ 트가 발생한다. | 데이터 정의 쿼리의 발행중(다만, 다른 쿼리도 다수 존재)에 트랜잭션(transaction)의 암묵적인 코?~ 트가 발생한다.
COSH() | SQL 함수 | 유사하는 것이 존재하지 않는다.
COT() | SQL 함수 | COT() .구문과 실장이 일치한다.
CREATE | SQL , 데이터 정의 언어 | CREATE
DATABASE | SQL 함수 | DATABASE() .DATABASE (은)는 다른 문맥으로 사용된다.예를 들어 CREATE DATABASE
DATE() | SQL 함수 | CURRENT_DATE
DATEDIFF() | SQL 함수 | DATEDIFF() .MySQL 버젼 4.1.1 그리고 추가
DAY() | SQL 함수 | 유사하는 것이 존재하지 않는다.
DAYOFWEEK() | SQL 함수 | DAYOFWEEK() .첫날(1 )의 디폴트는 MaxDB 그럼 월요일,MySQL 그럼 일요일이 되고 있다.
DISTINCT | SQL 함수 AVG, MAX, MIN, SUM | DISTINCT .다만,SELECT DISTINCT 그렇다고 하는 다른 문맥으로 사용된다.
DROP | 특히 DROP INDEX 그리고 | DROP INDEX .사용 방법은 유사하고 있지만, 동일하지 않다.
EBCDIC() | SQL 함수 | 유사하는 것이 존재하지 않는다.
EXPAND() | SQL 함수 | 유사하는 것이 존재하지 않는다.
EXPLAIN | 최적화 | EXPLAIN .사용 방법은 유사하고 있지만, 동일하지 않다.
FIXED() | SQL 함수 | 유사하는 것이 존재하지 않는다.
FLOAT() | SQL 함수 | 유사하는 것이 존재하지 않는다.
HEX() | SQL 함수 | HEX() .사용 방법은 유사하고 있지만, 동일하지 않다.
INDEX() | SQL 함수 | INSTR() 또는 LOCATE() .구문과 의미는 유사하고 있지만, 동일하지 않다.
INDEX | USE INDEX, IGNORE INDEX 및 유사하는 힌트가 SELECT ... USE INDEX (와)과 같이,SELECT 의 직후에 사용되고 있다. | USE INDEX, IGNORE INDEX 및 유사하는 힌트가 SELECT ... FROM ... USE INDEX 의 경우와 같이,SELECT 의 FROM 마디로 사용되고 있다.
INITCAP() | SQL 함수 | 유사하는 것이 존재하지 않는다.
LENGTH() | SQL 함수 | LENGTH() .구문은 동일하지만, 실장이 조금 다르다.
LFILL() | SQL 함수 | 유사하는 것이 존재하지 않는다.
LIKE | 비교 | LIKE .다만,MaxDB 에 준비되어 있는 확장 LIKE 하 MySQL 의 REGEX 에 유사하고 있다.
LIKE 와일드 카드 | MaxDB 그럼,``%'' ,``_'' ,``ctrl + 언더 스코아'' ,``ctrl + ↑'' ,``*'' ,``?'' 하지만 LIKE 와일드 카드로서 비교로 서포트된다. | MySQL 그럼,``%'' (와)과 ``_'' 하지만 LIKE 와일드 카드로서 비교로 서포트된다.
LPAD() | SQL 함수 | LPAD() .실장이 조금 다르다.
LTRIM() | SQL 함수 | LTRIM() .실장이 조금 다르다.
MAKEDATE() | SQL 함수 | MAKEDATE() .MySQL 버젼 4.1.1 그리고 추가
MAKETIME() | SQL 함수 | MAKETIME() .MySQL 버젼 4.1.1 그리고 추가
MAPCHAR() | SQL 함수 | 유사하는 것이 존재하지 않는다.
MICROSECOND() | SQL 함수 | MICROSECOND() .MySQL 버젼 4.1.1 그리고 추가
NOROUND() | SQL 함수 | 유사하는 것이 존재하지 않는다.
NULL | 컬럼형.비교 | NULL .오버플로우 또는 제로 제산의 원인이 되는 산술 연산으로부터 돌려주어지는 특별한 NULL 값이,MaxDB 그리고 서포트된다.그러한 특별한 값은,MySQL 그럼 서포트되지 않는다.
PI | SQL 함수 | PI() .구문과 실장은 동일하지만, 외모가 필요하게 된다.
REF | 데이터형 | 유사하는 것이 존재하지 않는다.
RFILL() | SQL 함수 | 유사하는 것이 존재하지 않는다.
ROWNO | WHERE 마디에 있어서의 술어 | LIMIT 마디에 유사하고 있다.
RPAD() | SQL 함수 | RPAD() .실장이 조금 다르다.
RTRIM() | SQL 함수 | RTRIM() .실장이 조금 다르다.
SEQUENCE | CREATE SEQUENCE, DROP SEQUENCE | AUTO_INCREMENT .개념은 유사하고 있지만, 실장이 다르다.
SINH() | SQL 함수 | 유사하는 것이 존재하지 않는다.
SOUNDS() | SQL 함수 | SOUNDEX() .구문이 조금 다르다.
STATISTICS | UPDATE STATISTICS | ANALYZE .개념은 유사하고 있지만, 실장이 다르다.
SUBSTR() | SQL 함수 | SUBSTRING() .실장이 조금 다르다.
SUBTIME() | SQL 함수 | SUBTIME() .MySQL 버젼 4.1.1 그리고 추가
SYNONYM | 데이터 정의 언어: CREATE [PUBLIC] SYNONYM ,RENAME SYNONYM ,DROP SYNONYM | 유사하는 것이 존재하지 않는다.
TANH() | SQL 함수 | 유사하는 것이 존재하지 않는다.
TIME() | SQL 함수 | CURRENT_TIME
TIMEDIFF() | SQL 함수 | TIMEDIFF() .MySQL 버젼 4.1.1 그리고 추가
TIMESTAMP() | SQL 함수 | TIMESTAMP() .MySQL 버젼 4.1.1 그리고 추가
DAYOFMONTH() (와)과 DAYOFYEAR() 의 인수로서의TIMESTAMP() | SQL 함수 | 유사하는 것이 존재하지 않는다.
TIMEZONE() | SQL 함수 | 유사하는 것이 존재하지 않는다.
TRANSACTION() | 현행 트랜잭션(transaction)의 ID (을)를 돌려준다. | 유사하는 것이 존재하지 않는다.
TRANSLATE() | SQL 함수 | REPLACE() .구문과 실장이 일치한다.
TRIM() | SQL 함수 | TRIM() .실장이 조금 다르다.
TRUNC() | SQL 함수 | TRUNCATE() .구문과 실장이 조금 다르다.
USE | mysql 커멘드 라인 유저 인터페이스 커멘드 | USE
USER | SQL 함수 | USER() .구문은 동일하지만, 실장이 다르다.외모가 필요하게 된다.
UTC_DIFF() | SQL 함수 | UTC_DATE() .UTC_DIFF() 의 결과를 계산하는 수단을 제공한다.
VALUE() | SQL 함수,COALESCE() 의 앨리어스(alias) | COALESCE() .구문과 실장이 일치한다.
VARIANCE() | SQL 함수 | 유사하는 것이 존재하지 않는다.
WEEKOFYEAR() | SQL 함수 | WEEKOFYEAR() .MySQL 버젼 4.1.1 그리고 추가


제9 장 각국 캐릭터 세트와 Unicode

목차

9.1. 일반의 캐릭터 세트 및 조합 순서
9.2. MySQL 에 있어서의 캐릭터 세트 및 조합 순서
9.3. 디폴트의 캐릭터 세트 및 조합 순서의 결정
9.3.1. 서버의 캐릭터 세트 및 조합 순서
9.3.2. 데이타베이스의 캐릭터 세트 및 조합 순서
9.3.3. 테이블의 캐릭터 세트 및 조합 순서
9.3.4. 컬럼의 캐릭터 세트 및 조합 순서
9.3.5. 캐릭터 세트와 조합 순서의 할당의 예
9.3.6. 접속의 캐릭터 세트 및 조합 순서
9.3.7. 문자열 리터럴의 캐릭터 세트 및 조합 순서
9.3.8. SQL 쿼리의 각 부분에 있어서의 COLLATE 절
9.3.9. COLLATE 마디의 우선 순위
9.3.10. BINARY 연산자
9.3.11. 조합 순서를 결정하는 것이 어려운 특수한 케이스
9.3.12. 조합 순서는 적절한 캐릭터 세트에 대응하고 있는 것
9.3.13. 조합 순서가 가져오는 결과의 예
9.4. 캐릭터 세트의 서포트에 의한 영향을 받는 연산
9.4.1. 결과 문자열
9.4.2. CONVERT()
9.4.3. CAST()
9.4.4. SHOW CHARACTER SET
9.4.5. SHOW COLLATION
9.4.6. SHOW CREATE DATABASE
9.4.7. SHOW FULL COLUMNS
9.5. Unicode 의 서포트
9.6. 메타데이타용의 UTF8
9.7. 다른 DBMS (와)과의 호환성
9.8. 신규 캐릭터 세트 설정 파일의 형식
9.9. 각국 캐릭터 세트
9.10. MySQL 4.0 (으)로부터의 업그레이드
9.10.1. 4.0 캐릭터 세트 및 대응한다 4.1 캐릭터 세트/ 조합 순서의 페어
9.11. MySQL 그리고 서포트되는 캐릭터 세트와 조합 순서
9.11.1. Unicode 캐릭터 세트
9.11.2. 플랫폼 고유의 캐릭터 세트
9.11.3. 남유럽 및 중동의 캐릭터 세트
9.11.4. 아시아의 캐릭터 세트
9.11.5. 발트어 캐릭터 세트
9.11.6. 키릴어 캐릭터 세트
9.11.7. 중앙 유럽의 캐릭터 세트
9.11.8. 서유럽의 캐릭터 세트

MySQL 버젼 4.1 의 추가 기능의 1 개로서 캐릭터 세트의 처리가 개선되었던 것이 들 수 있습니다.이 장에서는, 이하에 대해 설명합니다.

  • 캐릭터 세트와 조합 순서란

  • 멀티 레벨 디폴트 시스템

  • MySQL 4.1 (으)로의 새로운 구문

  • 영향을 받는 함수와 연산

  • 개별의 캐릭터 세트와 조합 순서의 의미

여기에서는,MySQL 4.1.1 (으)로의 실장에 근거해 기능을 설명합니다 (MySQL 4.1.0 에는, 이러한 기능의 전부는 없게 일부만이 존재합니다.또, 실장이 차이가 나는 기능도 있습니다).

9.1. 일반의 캐릭터 세트 및 조합 순서

캐릭터 세트 (이)란, 심볼과 encode세트입니다. 조합 순서 (이)란, 캐릭터 세트내의 문자를 비교하기 위한 룰을 모은 것입니다.가공의 캐릭터 세트를 예로 하고, 캐릭터 세트와 조합 순서의 차이를 봅시다.

다음의 4 문자로 구성되는 알파벳이 있다고 합니다 : ‘A ＇,‘B ＇,‘a ＇,‘b ＇다음과 같이, 각 문자에 대해서 번호를 지정합니다 : ‘A ＇ = 0 ,‘B ＇ = 1 ,‘a ＇ = 2 ,‘c ＇ = 3 문자 ‘A ＇ (은)는 심볼이며, 숫자 0 하 ‘A ＇ (을)를 encode 한 것입니다.4 문자의 모두각각의 encode를 조합한 것을 캐릭터 세트 (이)라고 부릅니다.

다음에, 문자열치 ‘A ＇ (와)과 ‘B ＇ (을)를 비교해 봅시다. 가장 간단하게 비교하려면 , encode를 확인합니다.‘A ＇ 하 0 ,‘B ＇ 하 1 입니다.0 하 1 보다 작기 때문에,‘A ＇ 하 ‘B ＇ 보다 작다고 표현할 수 있습니다.지금 여기서 간 것은, 캐릭터 세트에 대한 조합 순서의 적용입니다.조합 순서는 룰의 모임이며, 상기의 경우에 룰은 `` encode의 비교'' 만됩니다.이것은 가능한 조합 순서중에서 가장 단순한 것이며, 바이너리 조합 순서로 불리고 있습니다.

그러나, 소문자와 대문자를 동일하다고 표현하고 싶은 경우에는 어떻게 되는 것입니까.그 경우, 적어도 다음의 2 살의 룰이 필요합니다.(1) 소문자의 ‘a ＇ 및 ‘b ＇ 하지만 대문자의 ‘A ＇ 및 ‘B ＇ (와)과 같다라고 본다.(2) 그 후에 encode를 비교한다.이것은 대문자와 소문자를 구별하지 않는다 조합 순서로 불려 바이너리 조합 순서보다 조금 복잡합니다.

실제는, 대부분의 캐릭터 세트에 다수의 문자가 포함되어 있습니다.‘A ＇ (와)과 ‘B ＇ 만이 아니고, 알파벳의 전체로부터 구성되어 있습니다.때로는 복수의 알파벳이나, 수천 문자로부터 되는 동양의 서기 체계에, 많은 특수 기호나 종?~ 부가 부속되기도 합니다.또, 실제로는 대부분의 조합 순서에 많은 룰이 있습니다.대문자와 소문자가 구별되지 않는 것뿐이 아닙니다.엑센트가 구별되지 않는다(`` 엑센트'' (은)는, 독일어로의 ‘Ö ＇ (와)과 같이 문자에 추가되는 마크), 혹은 복수 문자 매핑(독일어 조합 순서의 어딘가에 둘 수 있다 ‘Ö ＇ = 'OE' 의 룰등)등의 룰이 있습니다.

MySQL 4.1 그럼 이하가 가능합니다.

  • 각종의 캐릭터 세트를 사용해 문자열을 보존한다.

  • 각종의 조합 순서를 사용해 문자열을 비교한다.

  • 같은 서버, 같은 데이타베이스, 혹은 같은 테이블내가 다른 캐릭터 세트 또는 조합 순서와 문자열을 결합한다.

  • 임의의 레벨로 캐릭터 세트와 조합 순서를 지정할 수 있도록 한다.

MySQL 4.1 (은)는 이러한 점에 대하고,MySQL 4.0 보다 아득하게 유연성이 있을 뿐만이 아니고, 다른 DBMS 에 크게 차이를 내고 있습니다.다만, 신기능을 효율적으로 사용하려면 , 이용 가능한 캐릭터 세트, 각 디폴트의 변경 방법, 각종의 열연산자에 의한 처리 내용을 알아 두지 않으면 안됩니다.


9.2. MySQL 에 있어서의 캐릭터 세트 및 조합 순서

캐릭터 세트에는, 적어도 1 개의 조합 순서가 포함되어 있어 복수의 조합 순서가 포함되어 있기도 합니다.

예를 들어, 캐릭터 세트 latin1 (``ISO-8859-1 서유럽 언어'' )에는 이하의 조합 순서가 포함되어 있습니다.

조합 순서 | 의미
latin1_bin | latin1 encode에 근거하는 바이너리
latin1_danish_ci | 덴마크어/ 노르웨이어
latin1_german1_ci | 독일어 DIN-1
latin1_german2_ci | 독일어 DIN-2
latin1_swedish_ci | 스웨덴어/ 핀란드어
latin1_general_ci | 멀티 링걸

주의:

  • 2 개가 다른 캐릭터 세트가 같은 조합 순서를 공유할 수 없습니다.

  • 각 캐릭터 세트에는, 디폴트 조합 순서 하지만 1 개존재합니다.예를 들어,latin1 의 디폴트 조합 순서는 latin1_swedish_ci 입니다.

조합 순서명에는 다음의 규칙이 적용됩니다.관련하는 캐릭터 세트의 이름으로 시작된다.통상은 언어명이 포함되어 있어_ci (대문자와 소문자가 구별되지 않는다),_cs (대문자와 소문자가 구별된다),_bin (바이너리)의 어느쪽이든으로 끝난다.


9.3. 디폴트의 캐릭터 세트 및 조합 순서의 결정

서버, 데이타베이스, 테이블, 접속의 4 단계에서, 캐릭터 세트와 조합 순서의 디폴트 설정이 준비되어 있습니다.이하의 설명은 복잡하게 보일지도 모릅니다만, 멀티 레벨의 디폴트 설정에서는 자연스럽고 명확한 결과를 얻을 수 있는 것이 실제로 판명되어 있습니다.

9.3.1. 서버의 캐릭터 세트 및 조합 순서

MySQL Server 에는 서버 캐릭터 세트와 서버 조합 순서가 있어, 모두 눌로 할 수 없습니다.

MySQL 그럼, 서버 캐릭터 세트와 서버 조합 순서가 다음과 같이 결정됩니다.

  • 서버 기동시에 유효한 옵션 설정에 따릅니다.

이 레벨에서는, 결정은 간단합니다.서버의 캐릭터 세트와 조합 순서는,mysqld 의 기동시에 사용하는 옵션에 의존합니다.--default-character-set=character_set_name (을)를 캐릭터 세트에 대해서 사용할 수 있어--default-collation=collation_name (을)를 조합 순서에 대해서 추가할 수도 있습니다.문자 코드를 지정하지 않는 것은,--default-character-set=latin1 (을)를 지정했을 경우와 같습니다.캐릭터 세트(예를 들어 latin1 )만을 지정해 조합 순서를 지정하지 않는 것은,--default-charset=latin1 --collation=latin1_swedish_ci (을)를 지정했을 경우와 같습니다.이것은 latin1 의 디폴트 조합 순서가 latin1_swedish_ci 이기 (위해)때문입니다. 따라서, 이하의 3 개의 커멘드를 실행하면, 모두 같은 결과가 됩니다.

shell> mysqld
shell> mysqld --default-character-set=latin1
shell> mysqld --default-character-set=latin1
           --default-collation=latin1_swedish_ci

설정을 변경하는 수단의 1 개는 재컴파일입니다.소스로부터의 빌드시에 디폴트의 서버 캐릭터 세트와 조합 순서를 변경하려면 ,--with-character-set (와)과 --with-collation (을)를 configure 의 인수로서 사용해 주세요.례:

shell> ./configure --with-character-set=latin1

또는

shell> ./configure --with-character-set=latin1
           --with-collation=latin1_german1_ci

mysqld (와)과 configure 그럼, 캐릭터 세트와 조합 순서의 유효성이 체크됩니다.편성이 유효하지 않은 경우, 각 프로그램에 의해서 에러 메세지가 표시되어 강제 종료됩니다.

9.3.2. 데이타베이스의 캐릭터 세트 및 조합 순서

각 데이타베이스에는 데이타베이스 캐릭터 세트와 데이타베이스 조합 순서가 있어, 모두 눌로 할 수 없습니다.CREATE DATABASE 및 ALTER DATABASE 커멘드에는 현재, 데이타베이스의 캐릭터 세트와 조합 순서를 지정하기 위한 옵션절이 있습니다.

CREATE DATABASE db_name
   [DEFAULT CHARACTER SET character_set_name [COLLATE collation_name]]

ALTER DATABASE db_name
    [DEFAULT CHARACTER SET character_set_name [COLLATE collation_name]]

례:

CREATE DATABASE db_name
   DEFAULT CHARACTER SET latin1 COLLATE latin1_swedish_ci;

MySQL 그럼, 데이타베이스 캐릭터 세트와 데이타베이스 조합 순서가 다음과 같이 선택됩니다.

  • CHARACTER SET X (와)과 COLLATE Y 의 양쪽 모두를 지정했을 경우는, 캐릭터 세트 X (와)과 조합 순서 Y .

  • CHARACTER SET X (을)를 지정해,COLLATE (을)를 지정하지 않았던 경우는, 캐릭터 세트 X (와)과 그 디폴트 조합 순서.

  • 그 외의 경우는, 서버 캐릭터 세트와 서버 조합 순서.

MySQL 의 CREATE DATABASE ... DEFAULT CHARACTER SET ... 구문은 표준 SQL CREATE SCHEMA ... CHARACTER SET ... 구문에 유사하고 있습니다.이 때문에, 캐릭터 세트와 조합 순서가 다른 복수의 데이타베이스를 동일한 MySQL 서버상에 작성할 수 있습니다.

테이블의 캐릭터 세트와 조합 순서가 CREATE TABLE 스테이트먼트로 지정되어 있지 않은 경우, 데이타베이스의 캐릭터 세트와 조합 순서는 디폴트치로서 사용됩니다.이것들에 다른 용도는 없습니다.

9.3.3. 테이블의 캐릭터 세트 및 조합 순서

각 테이블에는 테이블 캐릭터 세트와 테이블 조합 순서가 있어, 모두 눌로 할 수 없습니다.CREATE TABLE 및 ALTER TABLE 스테이트먼트에는 현재, 테이블의 캐릭터 세트와 조합 순서를 지정하기 위한 옵션절이 있습니다.

CREATE TABLE table_name ( column_list )
   [DEFAULT CHARACTER SET character_set_name [COLLATE collation_name]]

ALTER TABLE table_name
   [DEFAULT CHARACTER SET character_set_name] [COLLATE collation_name]

례:

CREATE TABLE t1 ( ... ) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

MySQL 그럼, 테이블 캐릭터 세트와 테이블 조합 순서가 다음과 같이 선택됩니다.

  • CHARACTER SET X (와)과 COLLATE Y 의 양쪽 모두를 지정했을 경우는, 캐릭터 세트 X (와)과 조합 순서 Y .

  • CHARACTER SET X (을)를 지정해,COLLATE (을)를 지정하지 않았던 경우는, 캐릭터 세트 X (와)과 그 디폴트 조합 순서.

  • 그 외의 경우는, 데이타베이스 캐릭터 세트와 데이타베이스 조합 순서.

컬럼의 캐릭터 세트와 조합 순서가 개별의 컬럼 정의로 지정되어 있지 않은 경우, 테이블의 캐릭터 세트와 조합 순서는 디폴트치로서 사용됩니다.테이블의 캐릭터 세트와 조합 순서는 MySQL 확장이며, 동등의 기능은 표준 SQL 에 존재하지 않습니다.

9.3.4. 컬럼의 캐릭터 세트 및 조합 순서

각 `` 문자'' 컬럼(CHAR ,VARCHAR 또는 TEXT 형태)에는 컬럼 캐릭터 세트와 컬럼 조합 순서가 있어, 모두 눌로 할 수 없습니다.컬럼 정의 구문에는 현재, 컬럼 캐릭터 세트와 컬럼 조합 순서를 지정하기 위한 옵션절이 있습니다.

column_name {CHAR | VARCHAR | TEXT} (column_length)
    [CHARACTER SET character_set_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 (와)과 그 디폴트 조합 순서.

  • 그 외의 경우는, 테이블 캐릭터 세트와 테이블 조합 순서.

CHARACTER SET 및 COLLATE 마디는 표준 SQL 입니다.

9.3.5. 캐릭터 세트와 조합 순서의 할당의 예

MySQL 그리고 디폴트의 캐릭터 세트와 조합 순서의 값이 어떻게 결정될까를, 이하의 예로 나타내 보입니다.

례 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 조합 순서가 컬럼으로 지정되어 있습니다.정의는 명시적이므로, 직접적이라고 말할 수 있습니다.덧붙여latin1 컬럼의 보존처가 latin2 테이블이 되어 있는 것에 문제는 없습니다.

례 2: 테이블 + 컬럼 정의

CREATE TABLE t1
(
   c1 CHAR(10) CHARACTER SET latin1
) DEFAULT CHARACTER SET latin1 COLLATE latin1_danish_ci;

여기에서는,latin1 캐릭터 세트와 디폴트 조합 순서가 컬럼으로 지정되어 있습니다.자연스러운 지정으로 보입니다만, 디폴트 조합 순서는 테이블 레벨로부터 받아들여지지 않습니다.latin1 의 디폴트 조합 순서는 항상 latin1_swedish_ci 입니다.따라서, 컬럼 c1 에는 latin1_danish_ci 의 조합 순서는 아니고 latin1_swedish_ci 의 조합 순서가 설정됩니다.

례 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 그럼, 데이타베이스 레벨까지 거슬러 올라가 처리가 결정됩니다.(데이타베이스의 설정은 테이블의 설정이 되어, 그리고 컬럼의 설정이 됩니다.) 따라서, 컬럼 c1 의 캐릭터 세트는 latin2 , 조합 순서는 latin2_czech_ci 됩니다.

9.3.6. 접속의 캐릭터 세트 및 조합 순서

각 접속에는 접속 캐릭터 세트와 접속 조합 순서가 있어, 모두 눌로 할 수 없습니다.실제로는 2 개의 접속 캐릭터 세트가 존재하기 위해(때문에), 양자의 구별이 필요한 경우는 `` 접속/ 리터럴'' 및 `` 접속/ 결과'' 의 호칭을 구사하고 있습니다.

`` 접속'' (이)란, 서버에의 접속시에 작성되는 것입니다.클라이언트는 접속을 개입시켜,SQL 스테이트먼트(쿼리등)를 서버에 송신합니다.서버에서는 접속을 개입시켜, 응답(결과 세트등)을 클라이언트에 돌려줍니다.이것에 의해서, 다음과 같은 의문이 생깁니다.(a) 클라이언트로부터 송신될 때에 어느 캐릭터 세트로 쿼리가 보내지는 것인가.(b) 서버에서는 쿼리를 수신한 후에 어느 캐릭터 세트로 변환하는 것인가.(c) 서버에서는 결과 세트 또는 에러 메세지를 클라이언트에 반송하기 전에 어느 캐릭터 세트로 변환하는 것인가.이것들은 세세하게 조정할 수 있습니다만, 디폴트를 적용할 수도 있습니다.디폴트를 적용하는 경우, 이 섹션을 날려 괜찮습니다.

접속 캐릭터 세트에 영향을 주는 스테이트먼트가 2 개존재합니다.

SET NAMES character_set_name
SET CHARACTER SET character_set_name

SET NAMES (은)는, 클라이언트로부터 송신된다 SQL 스테이트먼트의 캐릭터 세트를 나타냅니다.예를 들어,SET NAMES cp1251 하 「이 클라이언트로부터의 입력 메세지는 향후, 캐릭터 세트 cp1251 (이)가 됩니다」 (와)과 서버에 통지합니다.서버에서는 적당, 독자적인 캐릭터 세트로 자유롭게 변환할 수 있습니다.

SET CHARACTER SET (은)는, 클라이언트로부터 송신된다 SQL 스테이트먼트의 캐릭터 세트와 서버로부터 클라이언트에 돌려주어지는 결과 세트의 캐릭터 세트를 나타냅니다.그 때문에 SET CHARACTER SET (은)는,SET NAMES (을)를 포함하고 있는 것 외에 예를 들어 SELECT 스테이트먼트를 사용할 때에 어느 캐릭터 세트로 컬럼에 값이 보관 유지되는지를 나타냅니다.

례:column1 하지만 CHAR(5) CHARACTER SET latin2 (으)로서 정의되고 있다고 합니다.SET CHARACTER SET 하지만 지정되어 있지 않은 경우,SELECT column1 FROM t 에 대해 서버는, 캐릭터 세트 latin2 (을)를 사용해 column1 의 값을 모두 돌려줍니다.한편,SET CHARACTER SET latin1 하지만 지정되어 있는 경우, 서버는 송신전에 latin2 의 값을 latin1 (으)로 변환합니다.그러한 변환은 저속이며, 손실로 연결되기도 합니다.

SET NAMES 또는 SET CHARACTER SET 의 실행시에는,`` 접속 조합 순서'' 도 변경하고 있게 됩니다.다만, 접속 조합 순서는 정합성의 유지만을 목적으로 해 존재하고 있습니다.통상, 그 값은 중요하지는 않습니다.

mysql 클라이언트에서는, 기동할 때마다 SET NAMES (을)를 실행할 필요는 없습니다.--default-character-set-name 옵션 설정을 mysql 의 커멘드 라인인가, 옵션 파일에 추가할 수 있습니다. 예를 들어, 이하의 옵션 설정 파일의 설정에서는,mysql (을)를 실행할 때마다 접속 캐릭터 세트가 지정됩니다.

[mysql]
default-character-set-name=character_set_name

9.3.7. 문자열 리터럴의 캐릭터 세트 및 조합 순서

각 문자열 리터럴에는 캐릭터 세트와 조합 순서가 있어, 모두 눌로 할 수 없습니다.

문자열 리터럴에서는, 옵션으로서 캐라크타셋트인트로듀사와 COLLATE 마디를 지정할 수 있습니다.

[_character_set_name]'string' [COLLATE collation_name]

례:

SELECT 'string';
SELECT _latin1'string';
SELECT _latin1'string' COLLATE latin1_danish_ci;

단순한 스테이트먼트 SELECT 'string' 그럼, 접속/ 리터럴 캐릭터 세트가 사용됩니다.

_character_set_name (은)는 이전, 인트로듀사 (으)로 불리고 있었습니다.지정하면,`` 캐릭터 세트 X 의 문자열이 후속 한다'' 일이 파서에 통지됩니다. 상기는 유저의 혼란을 부르고 있었기 때문에, 여기서 강조해 둡니다만, 인트로듀사는 변환의 원인에는 안되어, 문자열의 값이 변경되지 않는 것을 나타내 보이는에 지나지 않습니다.표준적인 16 진리터럴 및 수치 16 진리터럴의 표기(x'literal' 및 0xnnnn )의 전과 ? (준비된 스테이트먼트를 프로그라?~ 그 언어 인터페이스로 사용할 때의 파라미터 대체)의 전에서도, 인트로듀사는 유효합니다.

례:

SELECT _latin1 x'AABBCC';
SELECT _latin1 0xAABBCC;
SELECT _latin1 ?;

MySQL 그럼, 리터럴의 캐릭터 세트 및 조합 순서가 다음과 같이 결정됩니다.

  • _X (와)과 COLLATE Y 의 양쪽 모두가 지정되었을 경우, 리터럴 캐릭터 세트는 X , 리터럴 조합 순서는 Y .

  • _X (은)는 지정되어 있어COLLATE 하지만 지정되어 있지 않은 경우, 리터럴 캐릭터 세트는 X , 리터럴 조합 순서는 X 의 디폴트 조합 순서.

  • 그 외의 경우는, 접속/ 리터럴의 캐릭터 세트 및 조합 순서.

례:

  • 문자열에 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 의 지정에 근거해 실장됩니다.

9.3.8. SQL 쿼리의 각 부분에 있어서의 COLLATE 절

COLLATE 마디에서는, 비교에 대한 디폴트 조합 순서가 무엇으로 저것, 무효로 할 수 있습니다.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
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;

  • HAVING (을)를 지정했을 경우

    SELECT k
FROM t1
GROUP BY k
HAVING k = _latin1 'Müller' COLLATE latin1_german2_ci;

9.3.9. COLLATE 마디의 우선 순위

COLLATE 마디는 우선 순위가 높다(|| 보다 위)의로, 식

x || y COLLATE z

(은)는 이하와 같은 의미가 됩니다.

x || (y COLLATE z)

9.3.10. BINARY 연산자

BINARY 연산자는,COLLATE 마디의 생략형입니다.예를 들어,BINARY 'x' 하 'x' COLLATE y (와)과 같고, 이 경우에 y (은)는 해당하는 바이너리 조합 순서의 명칭을 나타냅니다.예를 들어, 컬럼 a 의 캐릭터 세트가 latin1 이라고 가정하면, 이하의 쿼리는 어느쪽이나 같은 결과를 가져옵니다.

SELECT * FROM t1 ORDER BY BINARY a;
SELECT * FROM t1 ORDER BY a COLLATE latin1_bin;

주의: 어느 캐릭터 세트에도 바이너리 조합 순서가 있습니다.

9.3.11. 조합 순서를 결정하는 것이 어려운 특수한 케이스

대다수의 쿼리에서는,MySQL 하지만 어느 조합 순서에 의해 비교 연산을 실시할까는 명확하게 되어 있습니다.예를 들어 이하의 경우, 조합 순서가 `` 컬럼 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 그럼,`` 강제 가능'' 룰로 불리고 있던 방법으로 상기의 문제를 해결했습니다.이것에 대해서는, 이하의 발상이 기본이 되고 있습니다: x (와)과 'Y' 의 양쪽 모두에 조합 순서가 있으므로, 어느 쪽의 조합 순서를 우선할까를 판단하지 않으면 안 된다.복잡한 문제이지만, 이러한 룰로 대부분의 상황에 대응할 수 있다.

  • 명시적인 COLLATE 마디는 우선 순위가 4 .

  • 조합 순서가 다른 문자열 2 개의 연결은 우선 순위가 3 .

  • 컬럼의 조합 순서는 우선 순위가 2 .

  • 리터럴의 조합 순서는 우선 순위가 1 .

이러한 룰에 의해서, 애매함은 다음과 같이 해소됩니다.

  • 우선 순위가 가장 높은 조합 순서를 사용한다.

  • 쌍방의 우선 순위가 일치하는 경우, 조합 순서가 일치하지 않으면 에러가 된다.

례:

column1 = 'A' | column1 의 조합 순서를 사용한다.
column1 = 'A' COLLATE x | 'A' 의 조합 순서를 사용한다.
column1 COLLATE x = 'A' COLLATE y | 에러

9.3.12. 조합 순서는 적절한 캐릭터 세트에 대응하고 있는 것

각 캐릭터 세트에는 1 개이상의 조합 순서가 있어, 각 조합 순서는 1 개의 캐릭터 세트에 관련지을 수 있고 있는 것을 생각해 내 주세요.따라서, 다음의 스테이트먼트는 에러가 됩니다.latin2_bin 조합 순서는 latin1 캐릭터 세트에 대해서 유효하지 않기 때문입니다.

mysql> SELECT _latin1 'x' COLLATE latin2_bin;
ERROR 1251: COLLATION 'latin2_bin' is not valid
for CHARACTER SET 'latin1'

9.3.13. 조합 순서가 가져오는 결과의 예

테이블 T 의 컬럼 X 에 이하의 latin1 컬럼의 값이 설정되어 있다고 합니다.

Muffler
Müller
MX Systems
MySQL

게다가 이하의 스테이트먼트를 사용해 컬럼의 값을 취득했다고 합니다.

SELECT X FROM T ORDER BY X COLLATE collation_name;

다른 조합 순서에 대한 값의 순서는 이하와 같이 됩니다.

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

이 표는, 복수가 다른 조합 순서를 ORDER BY 마디로 사용한 결과의 일례입니다.이 예에서는,2 개의 점이 우에를 뒤따르고 있다 U 하지만 문제의 원인입니다.이 문자를 독일에서는 모음 변이라고 부르고 있습니다만, 우리는 분음 기호 첨부의 U (이)라고 부르고 있습니다.

최초의 컬럼에게는, 스웨덴어/ 핀란드어의 조합 룰을 사용했다SELECT 의 결과가 나타나고 있습니다.이 조합 룰에 의하면, 분음 기호 첨부의 U 하 Y (와)과 일치합니다.

2 번째의 컬럼에게는, 독일어의 DIN-1 룰을 사용했다 SELECT 의 결과가 나타나고 있습니다.이 룰에 의하면, 분음 기호 첨부의 U 하 U (와)과 일치합니다.

3 번째의 컬럼에게는, 독일어의 DIN-2 룰을 사용했다SELECT 의 결과가 나타나고 있습니다.이 룰에 의하면, 분음 기호 첨부의 U 하 UE (와)과 일치합니다.

3 개가 다른 조합 순서가,3 개가 다른 결과를 가져오고 있습니다.이것이야말로 정말로 MySQL 그리고 대처해야 할 상황입니다.적절한 조합 순서를 사용하면, 임의의 소트 순서를 선택할 수 있습니다.


9.4. 캐릭터 세트의 서포트에 의한 영향을 받는 연산

이 섹션에서는, 캐릭터 세트 정보를 계산에 넣는 연산에 대해 설명합니다.

9.4.1. 결과 문자열

MySQL 에는, 문자열을 돌려주는 다수의 연산자와 함수가 있습니다. 이 섹션에서는, 그러한 문자열의 캐릭터 세트와 조합 순서에 대해 해설하고 있습니다.

문자열의 입력을 취득해 문자열의 결과를 출력으로서 돌려주는 단순한 함수에서는, 출력의 캐릭터 세트 및 조합 순서는 주요한 입력의 캐릭터 세트 및 조합 순서와 같습니다.예를 들어 UPPER(X) (은)는, 캐릭터 세트 및 조합이 X (와)과 일치하는 문자열을 돌려줍니다. 같은 것은 이하에 대해서도 들어맞읍니다. INSTR(), LCASE(), LOWER(), LTRIM(), MID(), REPEAT(), REPLACE(), REVERSE(), RIGHT(), RPAD(), RTRIM(), SOUNDEX(), SUBSTRING(), TRIM(), UCASE(), UPPER() . (주의: REPLACE() 함수는 다른 모든 함수와는 달라, 문자열 입력의 조합 순서를 무시해, 대문자와 소문자가 구별되지 않는 비교를 매회 실행합니다.)

복수의 문자열 입력을 조합해 단일의 문자열 출력을 돌려주는 조작에는,SQL-99 의 `` 집약 룰'' 하지만 적용됩니다(이하를 참조).

  • 명시적인 COLLATE X 하지만 존재하는 경우는 X (을)를 사용한다.

  • 명시적인 COLLATE X (와)과 COLLATE Y 하지만 존재하는 경우는 에러가 된다.

  • 상기 이외의 경우로 모든 조합 순서가 X 일 때는 X (을)를 사용한다.

  • 그 외의 경우, 결과에 조합 순서는 포함되지 않는다.

예를 들어,CASE ... WHEN a THEN b WHEN b THEN c COLLATE X END (와)과 지정되어 있는 경우, 조합 순서는 X (이)가 됩니다.같은 것은 이하에 대해서도 들어맞읍니다. CONCAT(), GREATEST(), IF(), LEAST(), CASE, UNION, ||, ELT() .

문자 데이터로 변환하는 조작 때문에, 결과 문자열의 캐릭터 세트와 조합 순서는 접속/ 리터럴 캐릭터 세트 에 포함되어 있어 접속/ 리터럴 조합 순서 (을)를 가지고 있습니다. 이것은 이하에 대해서도 들어맞읍니다. CHAR(), CAST(), CONV(), FORMAT() . HEX(), SPACE() .

9.4.2. CONVERT()

CONVERT() (을)를 사용하면, 다른 캐릭터 세트간에 데이터를 변환할 수 있습니다.구문은 이하대로입니다.

CONVERT(expr USING transcoding_name)

MySQL 그럼, 트랜스 코딩명은 대응하는 캐릭터 세트명과 같습니다.

례:

SELECT CONVERT(_latin1'Müller' USING utf8);
INSERT INTO utf8table (utf8column)
   SELECT CONVERT(latin1field USING utf8) FROM latin1table;

CONVERT(... USING ...) (은)는,SQL-99 의 사양에 근거해 실장되고 있습니다.

9.4.3. CAST()

CAST() (을)를 사용해, 문자열을 다른 캐릭터 세트로 변환할 수도 있습니다.새로운 서식은 이하대로입니다.

CAST ( character_string AS character_data_type
    CHARACTER SET character_set_name )

례:

SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8);

COLLATE 마디를 CAST() 의 내부에서 사용할 수 없습니다만, 외부에서는 사용할 수 있습니다.따라서,CAST(... COLLATE ...) (은)는 무효입니다만,CAST(...) COLLATE ... (은)는 유효합니다.

례:

SELECT CAST(_latin1'test' AS CHAR CHARACTER SET utf8) COLLATE utf8_bin;

CAST() (을)를 CHARACTER SET 의 지정 없이 사용했을 경우, 캐릭터 세트와 조합 순서는 접속/ 리터럴 캐릭터 세트와 그 디폴트 조합 순서가 됩니다.CAST() (을)를 CHARACTER SET X 의 지정로 사용했을 경우, 캐릭터 세트는 X , 조합 순서는 X 의 디폴트 조합 순서가 됩니다.

9.4.4. SHOW CHARACTER SET

SHOW CHARACTER SET 커멘드를 실행하면, 사용 가능한 캐릭터 세트가 모두 표시됩니다. 옵션절 LIKE (을)를 지정하면, 조건에 매치하는 캐릭터 세트를 표시할 수 있습니다.

례:

mysql> SHOW CHARACTER SET LIKE 'latin%';
+---------+-----------------------------+-------------------+--------+
| Charset | Description                 | Default collation | Maxlen |
+---------+-----------------------------+-------------------+--------+
| latin1  | ISO 8859-1 West European    | latin1_swedish_ci |      1 |
| latin2  | ISO 8859-2 Central European | latin2_general_ci |      1 |
| latin5  | ISO 8859-9 Turkish          | latin5_turkish_ci |      1 |
| latin7  | ISO 8859-13 Baltic          | latin7_general_ci |      1 |
+---------+-----------------------------+-------------------+--------+
4 rows in set (0.00 sec)

위의 일람에 관한 주의:

  • Maxlen 컬럼은,1 문자를 격납하기 위한 최대 바이트수를 나타냅니다.

9.4.5. SHOW COLLATION

SHOW COLLATION 커멘드를 실행하면, 사용 가능한 캐릭터 세트가 모두 표시됩니다. 옵션절 LIKE (을)를 지정하면, 조건에 매치하는 조합 순서명이 표시됩니다.

mysql> SHOW COLLATION LIKE 'latin1%';
+-------------------+---------+----+---------+----------+---------+
| Collation         | Charset | Id | Default | Compiled | Sortlen |
+-------------------+---------+----+---------+----------+---------+
| latin1_german1_ci | latin1  |  5 |         |          |       0 |
| latin1_swedish_ci | latin1  |  8 | Yes     | Yes      |       0 |
| latin1_danish_ci  | latin1  | 15 |         |          |       0 |
| latin1_german2_ci | latin1  | 31 |         | Yes      |       2 |
| latin1_bin        | latin1  | 47 |         | Yes      |       0 |
| latin1_general_ci | latin1  | 48 |         |          |       0 |
| latin1_general_cs | latin1  | 49 |         |          |       0 |
+-------------------+---------+----+---------+----------+---------+
7 rows in set (0.00 sec)

Default 컬럼은, 조합 순서가 그 캐릭터 세트의 디폴트일지를 나타냅니다. Compiled (은)는, 캐릭터 세트가 서버에 컴파일 되고 있는지 어떤지를 나타냅니다. Sortlen (은)는, 캐릭터 세트로 소트 문자열을 표현하기 위해서 필요한 메모리의 용량에 관련합니다.

9.4.6. SHOW CREATE DATABASE

이하의 쿼리는, 지정된 데이타베이스를 작성한다 CREATE DATABASE 스테이트먼트를 나타냅니다.실행 결과에는, 데이타베이스 옵션이 모두 포함되어 있습니다.DEFAULT CHARACTER SET (와)과 COLLATE 하지만 서포트되고 있습니다.데이타베이스 옵션이 모두 보존되고 있는 단일의 텍스트 파일이 데이타베이스 디렉토리에 있습니다.

mysql> SHOW CREATE DATABASE a;
+----------+-----------------------------------------------------------+
| Database | Create Database
|
+----------+-----------------------------------------------------------+
| a        | CREATE DATABASE `a` /*!40100 DEFAULT CHARACTER SET macce
COLLATE macce_ci_ai */ |
+----------+-----------------------------------------------------------+
1 row in set (0.00 sec)

9.4.7. SHOW FULL COLUMNS

SHOW COLUMNS 스테이트먼트를 SHOW FULL COLUMNS (으)로서 호출했을 때는, 테이블의 컬럼의 조합 순서를 나타냅니다. 데이터형이 CHAR ,VARCHAR ,TEXT 의 언젠가인 컬럼은, 조합 순서가 NULL (이)가 되어 있지 않습니다.수치형과 문자형 이외의 컬럼은, 조합 순서가 NULL (이)가 되어 있습니다.례:

mysql> SHOW FULL COLUMNS FROM a;
+-------+---------+-------------------+------+-----+---------+-------+
| Field | Type    | Collation         | Null | Key | Default | Extra |
+-------+---------+-------------------+------+-----+---------+-------+
| a     | char(1) | latin1_swedish_ci | YES  |     | NULL    |       |
| b     | int(11) | NULL              | YES  |     | NULL    |       |
+-------+---------+-------------------+------+-----+---------+-------+
2 rows in set (0.02 sec)

캐릭터 세트는 표시 대상으로 포함되어 있지 않습니다.


9.5. Unicode 의 서포트

MySQL 버젼 4.1 이?~ ,Unicode 데이터를 보존하기 위해서 다음의 새로운 캐릭터 세트가 준비되어 있습니다: ucs2 (UCS-2 Unicode 캐릭터 세트) 및 utf8 (Unicode 캐릭터 세트의 UTF-8 encode).

  • UCS-2 (Unicode 의 바이너리 표현)에서는, 각 문자는 2 아르바이트의 Unicode (와)과 최상위의 아르바이트로 최초로 표현됩니다.례 : " 라틴 문자의 대문자 A" (은)는 코드 0x0041 그렇지만,2 아르바이트 순서 0x00 0x41 (으)로서 보존되고 있습니다." 키릴 문자의 소문자 YERU" (Unicode 0x044B )(은)는2 아르바이트 순서 0x04 0x4B (으)로서 보존되고 있습니다.Unicode 문자 및 대응하는 코드에 대해서는,Unicode Home Page (을)를 참조해 주세요.

    일시적인 제한:UCS-2 (은)는 클라이언트 캐릭터 세트로서는( 아직) 사용할 수 없습니다.즉,SET NAMES ucs2 (은)는 유효하지 않다고 하는 것입니다.

  • UTF8 캐릭터 세트(Unicode 표현의 변환)은,Unicode 데이터를 보존하는 다른 방법이며,RFC2279 에 근거해 실장되고 있습니다.다양한 Unicode 문자를 길이가 다른 아르바이트 순서에 적합시키는 것이,UTF8 캐릭터 세트의 개념입니다.

    • 기본적인 라틴 문자, 숫자, 구두점은 1 아르바이트를 사용합니다.

    • 유럽 및 중동의 스크립트 문자의 상당수는,2 아르바이트 순서에 적합합니다.확장 라틴 몬지(치르다, 장음, 예엑센트, 억음 엑센트 그 외의 엑센트 첨부), 키릴 몬지, 그리스 몬지, 아르메니아 문자, 헤브루 문자, 아라비아 문자, 시리아 문자 그 외.

    • 한국어, 중국어, 일본어의 표의 문자는,3 아르바이트 순서를 사용합니다.

    • 현시점에서는,MySQL UTF8 서포트에 4 아르바이트 순서는 포함되어 있지 않습니다.

    힌트: 스페이스를 UTF8 그리고 보존하려면 ,CHAR (은)는 아니고 VARCHAR (을)를 사용해 주세요. 그처럼 하지 않으면MySQL 그럼 CHAR(10) CHARACTER SET utf8 컬럼에 대해서 30 아르바이트를 확보하지 않으면 안됩니다.이것은, 사용 가능한 최대장이 30 아르바이트이기 (위해)때문입니다.


9.6. 메타데이타용의 UTF8

메타데이타란, 데이터에 대한 데이터입니다.데이타베이스의 내용이 되고 있는 데이터가 아니고, 데이타베이스에 대해 설명하는 데이터가 메타데이타입니다.따라서, 컬럼명, 데이타베이스명, 유저명, 버젼명외,SHOW (을)를 실행해 표시되는 문자열의 대부분이 메타데이타에 해당합니다.

모든 메타데이타는 캐릭터 세트가 일치하고 있을 필요가 있습니다(그렇게 되지 않은 경우,SHOW (은)는 올바르게 실행된다고는 할 수 없습니다.같은 컬럼에 포함되는 개개의 레코드의 캐릭터 세트가 일치하지 않을 가능성이 있기 때문입니다).한편, 모든 언어에 의한 모든 문자가 메타데이타에 포함되어 있을 필요가 있습니다(그렇게 되지 않은 경우, 유저가 컬럼이나 테이블의 명칭을 모국어로 설정할 수 없을 가능성이 있습니다).상기 2 개의 목적을 고려하기 위해(때문에),MySQL 그럼 메타데이타가 Unicode 캐릭터 세트(UTF8 )(으)로 보존됩니다.이것에 의해서 불편이 발생하지 않는 것은, 엑센트 문자를 사용하지 않는 경우입니다.사용하는 경우, 메타데이타의 캐릭터 세트가 UTF8 인 것을 인식할 필요가 있습니다.

즉,USER() ( 및 그 동의어 SESSION_USER() (와)과 SYSTEM_USER() ),CURRENT_USER() ,VERSION() 의 각 함수에서는,UTF8 캐릭터 세트가 디폴트로 사용됩니다.

다만, 컬럼의 헤더와 DESCRIBE 함수의 실행 결과가 디폴트로 UTF8 캐릭터 세트가 되는 것이 아닙니다 (SELECT column1 FROM t (와)과 지정하면, 명칭 column1 자체가 클라이언트의 캐릭터 세트에 의해 서버로부터 클라이언트에 돌려주어집니다.이 캐릭터 세트는,SET NAMES 스테이트먼트로 결정된 것입니다).

서버로부터 메타데이타의 결과가 UTF8 이외의 캐릭터 세트로 돌려주어지도록(듯이) 하려면 , (see 항9.3.6. 「접속의 캐릭터 세트 및 조합 순서」 )의 변환을 SET CHARACTER SET 에 의해서 서버에 실행시키는지, 변환이 클라이언트로 실행되도록(듯이) 설정합니다.클라이언트에 변환을 실행시키는 것이 항상 효율적입니다만, 이 옵션은 MySQL 4.x 의 제품 사이클 후기까지 사용할 수 없습니다.

예를 들어,USER() 함수를 비교 또는 할당을 위해서 단일의 스테이트먼트로 사용하고 있다고 합니다. MySQL 에는 자동변역 기능이 준비되어 있습니다.

SELECT * FROM Table1 WHERE USER() = latin1_column;

이 기능이 유효한 것은,latin1_column 의 내용이 UTF8 (으)로 자동적으로 변환되고 나서 비교를 하기 때문입니다.

INSERT INTO Table1 (latin1_column) SELECT USER();

이 기능이 유효한 것은,USER() 의 내용이 latin1 (으)로 자동적으로 변환되고 나서 할당을 하기 때문입니다. 자동변역 기능은 완전하게는 실장되고 있지 않습니다만, 장래의 버젼에서는 적절히 동작할 예정입니다.

자동변역 기능은 SQL 표준에 포함되어 있지 않습니다.다만, 어느 캐릭터 세트도(서포트되고 있는 문자에 관해서)Unicode 의 `` 부분집합'' 인 것이 SQL 표준의 문서에 기재되어 있습니다.「슈퍼 세트에 적용되는 것은 부분집합에도 적용된다」라고 하는 유명한 원칙이 있으므로,Unicode 의 조합 순서는 Unicode 이외의 문자열이라는 비교에도 적용할 수 있다고 생각할 수 있습니다.

버젼 4.1.1 주의: 이 시점으로부터,errmsg.txt 파일은 모두 UTF8 (이)가 됩니다.클라이언트의 캐릭터 세트에의 변환은, 메타데이타에 관해서는 자동적으로 행해집니다.결과 세트를 돌려주는 경우의 디폴트의 동작을 변경할 수 있습니다.


9.7. 다른 DBMS (와)과의 호환성

SAP DB 의 호환성에 관해, 이하의 2 개의 스테이트먼트는 같습니다.

CREATE TABLE t1 (f1 CHAR(n) UNICODE);
CREATE TABLE t1 (f1 CHAR(n) CHARACTER SET ucs2);


9.8. 신규 캐릭터 세트 설정 파일의 형식

MySQL 4.1 의 경우, 캐릭터 세트의 설정은 XML 파일에 보존됩니다.캐릭터 세트 마다 1 파일이 사용됩니다(이전의 버젼에서는, 캐릭터 세트 설정 정보는 .conf 파일에 보존되었습니다).


9.9. 각국 캐릭터 세트

MySQL-4.x (와)과 그 이전의 버젼에서는,NCHAR (와)과 CHAR (은)는 동의어였습니다.ANSI 그럼, 사전 정의 캐릭터 세트가 CHAR 컬럼으로 사용되도록(듯이) 지정하는 방법의 1 개로서 NCHAR 또는 NATIONAL CHAR (을)를 정의하고 있습니다.MySQL 그럼,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' (을)를 사용하고, 각국 캐릭터 세트의 문자열을 작성할 수 있습니다.

이하의 2 개의 스테이트먼트는 등가입니다.

SELECT N'some text';
SELECT _utf8'some text';


9.10. MySQL 4.0 (으)로부터의 업그레이드

여기에서는, 구버젼의 MySQL (으)로부터의 업그레이드에 대해 설명합니다.MySQL 4.1 그럼,MySQL 4.0 (와)과의 상위 호환성이 거의 완전하게 확보되고 있어 그 이유는 단지 기능의 대부분이 새로운 점에 있습니다.따라서, 충돌을 일으키는 요소는 구버젼에 존재하지 않습니다.다만, 차이점과 주의점이 몇개인가 있습니다.

최대중요:``MySQL 4.0 캐릭터 세트'' 에는,``MySQL 4.1 캐릭터 세트'' (와)과 ``MySQL 4.1 조합 순서'' 의 양쪽 모두의 특성이 포함되어 있습니다.그러나, 이것을 기억해 둘 필요는 없습니다.향후는, 같은 복합 오브젝트내에서 캐릭터 세트 또는 조합 순서 특성을 병존시키지 않을 예정입니다.

MySQL 에는 각국 캐릭터 세트에 관한 특별한 처리가 준비되어 있습니다. 4.1. NCHAR 하 CHAR (와)과 같지 않고,N'...' 리터럴은 '...' 리터럴과 같지는 않습니다.

마지막으로, 캐릭터 세트와 조합 순서에 관한 정보를 격납하기 위한 특별한 파일 형식이 있습니다.신규 설정 파일을 포함한다 /share/mysql/charsets/ 디렉토리의 재인스톨이 끝나고 있는 것을 확인해 주세요.

MySQL 4.0 그리고 작성한 데이터를 사용해,mysqld (을)를 4.1.x 디스트리뷰션으로부터 기동하려면 , 같은 캐릭터 세트와 조합 순서로 서버를 기동할 필요가 있습니다.이 경우, 데이터의 인덱스를 재작성할 필요는 없습니다.

상기를 실행하는 방법은 이하의 2 대로입니다.

shell> ./configure --with-character-set=... --with-collation=...
shell> ./mysqld --default-character-set=... --default-collation=...

예를 들어,mysql (을)를 MySQL 4.0 danish 캐릭터 세트와 함께 사용하는 경우,latin1 캐릭터 세트와 latin1_danish_ci 조합 순서를 사용할 필요가 있습니다.

shell> ./configure --with-character-set=latin1
           --with-collation=latin1_danish_ci
shell> ./mysqld --default-character-set=latin1
           --default-collation=latin1_danish_ci

다음의 섹션에 나타난 표를 사용해, 낡다 4.0 캐릭터 세트명과 거기에 대응한다 4.1 캐릭터 세트/ 조합 순서의 페어를 검색합니다.

9.10.1. 4.0 캐릭터 세트 및 대응한다 4.1 캐릭터 세트/ 조합 순서의 페어

ID | 4.0 캐릭터 세트 | 4.1 캐릭터 세트 | 4.1 조합 순서
1 | big5 | big5 | big5_chinese_ci
2 | czech | latin2 | latin2_czech_ci
3 | dec8 | dec8 | dec8_swedish_ci
4 | dos | cp850 | cp850_general_ci
5 | german1 | latin1 | latin1_german1_ci
6 | hp8 | hp8 | hp8_english_ci
7 | koi8_ru | koi8r | koi8r_general_ci
8 | latin1 | latin1 | latin1_swedish_ci
9 | latin2 | latin2 | latin2_general_ci
10 | swe7 | swe7 | swe7_swedish_ci
11 | usa7 | ascii | ascii_general_ci
12 | ujis | ujis | ujis_japanese_ci
13 | sjis | sjis | sjis_japanese_ci
14 | cp1251 | cp1251 | cp1251_bulgarian_ci
15 | danish | latin1 | latin1_danish_ci
16 | hebrew | hebrew | hebrew_general_ci
17 | win1251 | (removed) | (removed)
18 | tis620 | tis620 | tis620_thai_ci
19 | euc_kr | euckr | euckr_korean_ci
20 | estonia | latin7 | latin7_estonian_ci
21 | hungarian | latin2 | latin2_hungarian_ci
22 | koi8_ukr | koi8u | koi8u_ukrainian_ci
23 | win1251ukr | cp1251 | cp1251_ukrainian_ci
24 | gb2312 | gb2312 | gb2312_chinese_ci
25 | greek | greek | greek_general_ci
26 | win1250 | cp1250 | cp1250_general_ci
27 | croat | latin2 | latin2_croatian_ci
28 | gbk | gbk | gbk_chinese_ci
29 | cp1257 | cp1257 | cp1257_lithuanian_ci
30 | latin5 | latin5 | latin5_turkish_ci
31 | latin1_de | latin1 | latin1_german2_ci


9.11. MySQL 그리고 서포트되는 캐릭터 세트와 조합 순서

MySQL 그리고 서포트되는 캐릭터 세트와 조합 순서의 주석 일람을 이하에 나타냅니다.옵션과 인스톨시의 설정이 다르기 위해, 일람에 포함되어 있는 항목의 일부가 표시되지 않는 서버도 있습니다.또, 새로운 캐릭터 세트 또는 조합 순서의 정의는 간단해서, 일람에 포함되지 않은 항목이 표시되는 서버도 있습니다.

MySQL 그럼,30 (을)를 넘는 캐릭터 세트에 대해서 70 (을)를 넘는 조합 순서가 서포트되고 있습니다.

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   | ISO 8859-1 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 |
| cp1251   | Windows Cyrillic            | cp1251_bulgarian_ci |      1 |
| hebrew   | ISO 8859-8 Hebrew           | hebrew_general_ci   |      1 |
| tis620   | TIS620 Thai                 | tis620_thai_ci      |      1 |
| euckr    | EUC-KR Korean               | euckr_korean_ci     |      2 |
| 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 |
| armscii8 | ARMSCII-8 Armenian          | armscii8_general_ci |      1 |
| utf8     | UTF-8 Unicode               | utf8_general_ci     |      3 |
| ucs2     | UCS-2 Unicode               | ucs2_general_ci     |      2 |
| cp866    | DOS Russian                 | cp866_general_ci    |      1 |
| keybcs2  | DOS Kamenicky Czech-Slovak  | keybcs2_general_ci  |      1 |
| macce    | Mac Central European        | macce_general_ci    |      1 |
| macroman | Mac West European           | macroman_general_ci |      1 |
| cp852    | DOS Central European        | cp852_general_ci    |      1 |
| latin7   | ISO 8859-13 Baltic          | latin7_general_ci   |      1 |
| cp1256   | Windows Arabic              | cp1256_general_ci   |      1 |
| cp1257   | Windows Baltic              | cp1257_general_ci   |      1 |
| binary   | Binary pseudo charset       | binary              |      1 |
+----------+-----------------------------+---------------------+--------+
33 rows in set (0.01 sec)

주의: 모든 캐릭터 세트에 바이너리 조합 순서가 존재합니다.다만, 이?~ 의 설명에서는 바이너리 조합 순서에 대해 채택하지 않은 것도 있습니다.

9.11.1. Unicode 캐릭터 세트

Unicode 캐릭터 세트가 2 개존재하는 것은 말할 것도 없습니다.이러한 캐릭터 세트를 사용해, 약 650 의 언어로 텍스트를 보존할 수 있습니다.2 개의 새로운 캐릭터 세트에 대응하는 많은 조합 순서는 추가되고 있지 않습니다만, 머지 않아 추가될 예정입니다.현재, 대문자와 소문자 및 엑센트가 구별되지 않는 디폴트의 조합 순서외, 바이너리 조합 순서가 있습니다.

+---------+-----------------+-------------------+--------+
| Charset | Description     | Default collation | Maxlen |
+---------+-----------------+-------------------+--------+
| utf8    | UTF-8 Unicode   | utf8_general_ci   |      3 |
| ucs2    | UCS-2 Unicode   | ucs2_general_ci   |      2 |
+---------+-----------------+-------------------+--------+

9.11.2. 플랫폼 고유의 캐릭터 세트

+----------+-----------------------------+---------------------+--------+
| Charset  | Description                 | Default collation   | Maxlen |
+----------+-----------------------------+---------------------+--------+
| dec8     | DEC West European           | dec8_swedish_ci     |      1 |
| hp8      | HP West European            | hp8_english_ci      |      1 |
+----------+-----------------------------+---------------------+--------+

9.11.3. 남유럽 및 중동의 캐릭터 세트

+----------+-----------------------------+---------------------+--------+
| Charset  | Description                 | Default collation   | Maxlen |
+----------+-----------------------------+---------------------+--------+
| armscii8 | ARMSCII-8 Armenian          | armscii8_general_ci |      1 |
| cp1256   | Windows Arabic              | cp1256_general_ci   |      1 |
| hebrew   | ISO 8859-8 Hebrew           | hebrew_general_ci   |      1 |
| greek    | ISO 8859-7 Greek            | greek_general_ci    |      1 |
| latin5   | ISO 8859-9 Turkish          | latin5_turkish_ci   |      1 |
| geostd8  | Georgian                    | geostd8_general_ci  |      1 |
+----------+-----------------------------+---------------------+--------+

9.11.4. 아시아의 캐릭터 세트

서포트되고 있는 아시아의 캐릭터 세트에는, 중국어, 일본어, 한국어, 타이어가 포함되어 있습니다.이것들은 복잡한 경우가 있습니다.예를 들어, 중국어의 캐릭터 세트는 수천 종류의 문자에 대응하고 있지 않으면 안됩니다.

+----------+-----------------------------+---------------------+--------+
| Charset  | Description                 | Default collation   | Maxlen |
+----------+-----------------------------+---------------------+--------+
| big5     | Big5 Traditional Chinese    | big5_chinese_ci     |      2 |
| gb2312   | GB2312 Simplified Chinese   | gb2312_chinese_ci   |      2 |
| gbk      | GBK Simplified Chinese      | gbk_chinese_ci      |      2 |
| euckr    | EUC-KR Korean               | euckr_korean_ci     |      2 |
| ujis     | EUC-JP Japanese             | ujis_japanese_ci    |      3 |
| sjis     | Shift-JIS Japanese          | sjis_japanese_ci    |      2 |
| tis620   | TIS620 Thai                 | tis620_thai_ci      |      1 |
+----------+-----------------------------+---------------------+--------+

9.11.4.1. cp932 캐릭터 세트

왜cp932 캐릭터 세트가 필요한가

MySQL 에 있어서의sjis 캐릭터 세트는IANA 에 의해서 정의되었다Shift_JIS 캐릭터 세트에 상당해, JIS X0201 , 및JIS X0208 문자가 서포트됩니다( http://www.iana.org/assignments/character-sets (을)를 참조) .

그렇지만, 기술 용어로서 일반적으로 사용되고 있는“시프트JIS ”의 의미는 매우 애매하고, 자주 각 벤더가 독자적으로Shift_JIS (을)를 확장한 것까지 포함되는 일이 있습니다.

예를 들면, 일본어Windows 환경에서 사용되는 「 시프트JIS 」(은)는 Microsoft 에 의한다Shift_JIS 의 확장으로, 정식적 명칭은 Microsoft Windows Codepage : 932 혹은 cp932 그렇다고 합니다. cp932 그럼 Shift_JIS 그리고 서포트되는 문자에 가세해NEC 특수 문자, NEC 선정IBM 확장 문자,IBM 확장 문자라고 하는 각종 확장 문자가 서포트됩니다.

MySQL 4.1 이?~ , 많은 일본어 유저가 이것들 확장 문자등의 사용에 임해 문제에 직면해 왔습니다만, 이러한 문제는 이하의 요인에 의해서 생기고 있었습니다:

  • MySQL 하지만 자동적으로 캐릭터 세트의 변환을 실시한다.

  • 캐릭터 세트의 변환은Unicode(ucs2) (을)를 개입시켜 행해진다.

  • sjis 캐릭터 세트는 이것들 확장 문자의 변환을 서포트하고 있지 않다.

  • 이른바 「 시프트JIS 」라고 불리는 캐릭터 세트로부터Unicode 에의 변환에는 복수의 변환 룰이 존재해, 몇개의 문자는 변환 룰에 따라서 다르다Unicode 문자에 변환된다.MySQL 그럼 이러한 변환 룰 가운데, 하나 밖에 서포트되어 있지 않다 ( 자세한 것은 후술 한다) .

MySQL 의cp932 캐릭터 세트는 이러한 문제를 해결하는 듯 디자인 되어 있어MySQL 4.1.12 , 및5.0.3 이?~ 그리고 사용할 수 있습니다.

MySQL 4.1 보다 전에서는,sjis 캐릭터 세트의 사용에 임해 어떠한 「 시프트JIS 」문자를 사용해도 문제는 없었습니다만,4.1 이?~ 그럼,MySQL 하지만 캐릭터 세트의 변환을 서포트하게 된 때문, 다른 변환 룰을 가진다IANA 의 Shift_JIS (와)과cp932 (을)를 2종류의 캐릭터 세트로서 구별하는 것이 중요해집니다.

cp932 하sjis (와)과 어떻게 다를까

cp932 캐릭터 세트는 이하의 점으로 sjis (와)과 다릅니다:

  • cp932 그럼NEC 특수 문자,NEC 선정IBM 확장 문자,IBM 확장 문자가 서포트된다.

  • 몇개의cp932 문자에 대해서는, 둘이 다르다 코드 포인트로부터 동일한Unicode 코드 포인트에 변환된다. 따라서 이러한 문자를Unicode (으)로부터cp932 에 되돌릴 때 어느 쪽인가 하나의 코드 포인트가 선택되지 않으면 안 된다. 이 「 왕복 여행 변환 」에 대해서는,Microsoft 에 의해서 추천 되는 룰이 사용되고 있다 (http://support.microsoft.com/kb/170559/EN-US/ (을)를 참조) .

    이 변환 룰은 이하와 같다:

    • 해당 문자가JIS X 0208 문자와NEC 특수 문자의 양쪽 모두에 존재하는 경우에는, JIS X 0208 의 코드 포인트를 사용한다.

    • 해당 문자가NEC 특수 문자와IBM 확장 문자의 양쪽 모두에 존재하는 경우에는, NEC 특수 문자의 코드 포인트를 사용한다.

    • 해당 문자가NEC 선정IBM 확장 문자와IBM 확장 문자의 양쪽 모두에 존재하는 경우에는, IBM 확장 문자의 코드 포인트를 사용한다.

    cp932 문자의Unicode 코드 포인트에 관한 정보는, http://www.microsoft.com/globaldev/reference/dbcs/932.htm 에 있는 표를 참조.cp932 의 겉(표)에 기재되어 있는 문자 가운데, 아래에 네 자리수의 숫자가 표시되고 있는 것에 대해서는, 그 숫자는 대응한다Unicode (ucs2) 코드 포인트를 나타낸다.밑줄 첨부의 두 자리수의 값에 대해서는 이것들 두 자리수의 값으로 시작되는 일련의cp932 문자가 있는 것을 나타내, 이러한 값을 클릭하는 것으로, 그 두 자리수의 값으로 시작된다 cp932 문자, 및 그Unicode 코드 포인트가 표시된다.

    더욱 흥미가 있는 분은 이하의 링크를 참조.각각, 각 문자의 대응한다 Unicode 코드 포인트를 표시한다.

    • NEC 특수 문자:

      http://www.microsoft.com/globaldev/reference/dbcs/932/932_87.htm

    • NEC 선정IBM 확장 문자:

      http://www.microsoft.com/globaldev/reference/dbcs/932/932_ED.htm
http://www.microsoft.com/globaldev/reference/dbcs/932/932_EE.htm

    • IBM 확장 문자:

      http://www.microsoft.com/globaldev/reference/dbcs/932/932_FA.htm
http://www.microsoft.com/globaldev/reference/dbcs/932/932_FB.htm
http://www.microsoft.com/globaldev/reference/dbcs/932/932_FC.htm

  • 5.0.3 이?~ 그럼,eucjpms 캐릭터 세트와 조합해 사용하는 것으로, cp932 그리고 유저 정의 문자의 변환이 서포트되어 sjis/ujis 사이에서의 변환 문제에도 대응하고 있다. 자세한 것은http://www.opengroup.or.jp/jvc/cde/sjis-euc-e.html (을)를 참조.

  • 몇개의 문자에 대해서는,sjis (와)과cp932 그리고 ucs2 (와)과의 변환 룰이 다르다.이하의 겉(표)에서는 그 차이를 설명하고 있다.

    ucs2 에의 변환

    sjis/cp932 의 코드 포인트 | sjis → ucs2 변환 | cp932 → ucs2 변환
    5C | 005C | 005C
    7E | 007E | 007E
    815C | 2015 | 2015
    815F | 005C | FF3C
    8160 | 301C | FF5E
    8161 | 2016 | 2225
    817C | 2212 | FF0D
    8191 | 00A2 | FFE0
    8192 | 00A3 | FFE1
    81CA | 00AC | FFE2

    ucs2 (으)로부터의 변환:

    ucs2 의 코드 포인트 | ucs2 → sjis 변환 | ucs2 → cp932 변환
    005C | 815F | 5C
    007E | 7E | 7E
    00A2 | 8191 | 3F
    00A3 | 8192 | 3F
    00AC | 81CA | 3F
    2015 | 815C | 815C
    2016 | 8161 | 3F
    2212 | 817C | 3F
    2225 | 3F | 8161
    301C | 8160 | 3F
    FF0D | 3F | 817C
    FF3C | 3F | 815F
    FF5E | 3F | 8160
    FFE0 | 3F | 8191
    FFE1 | 3F | 8192
    FFE2 | 3F | 81CA

9.11.5. 발트어 캐릭터 세트

발트어 캐릭터 세트에는, 에스토니아어, 라트비아어, 리투아니아어가 포함되어 있습니다.현재 서포트되고 있는 발트어 캐릭터 세트는 이하의 2 개입니다:

  • latin7 (ISO 8859-13 발트어):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| latin7_estonian_cs   | latin7   | 20 |         |          |       0 |
| latin7_general_ci    | latin7   | 41 | Yes     |          |       0 |
| latin7_general_cs    | latin7   | 42 |         |          |       0 |
| latin7_bin           | latin7   | 79 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • cp1257 (Windows 발트어):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| cp1257_lithuanian_ci | cp1257   | 29 |         |          |       0 |
| cp1257_bin           | cp1257   | 58 |         |          |       0 |
| cp1257_general_ci    | cp1257   | 59 | Yes     |          |       0 |
+----------------------+----------+----+---------+----------+---------+

9.11.6. 키릴어 캐릭터 세트

벨라루스어, 불가리아어, 러시아어, 우크라이나어와 함께 사용하는 키릴어의 캐릭터 세트 및 조합 순서를 이하에 나타냅니다.

  • cp1251 (Windows 키릴어)

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| cp1251_bulgarian_ci  | cp1251   | 14 |         |          |       0 |
| cp1251_ukrainian_ci  | cp1251   | 23 |         |          |       0 |
| cp1251_bin           | cp1251   | 50 |         |          |       0 |
| cp1251_general_ci    | cp1251   | 51 | Yes     |          |       0 |
| cp1251_general_cs    | cp1251   | 52 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • cp866 (DOS 러시아어):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| cp866_general_ci     | cp866    | 36 | Yes     |          |       0 |
| cp866_bin            | cp866    | 68 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • koi8r (KOI8-R Relcom Russian ,Unix 위에서 주로 러시아어에 사용):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| koi8r_general_ci     | koi8r    |  7 | Yes     |          |       0 |
| koi8r_bin            | koi8r    | 74 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • koi8u (KOI8-R Ukrainian ,Unix 위에서 주로 우크라이나어에 사용):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| koi8u_general_ci     | koi8u    | 22 | Yes     |          |       0 |
| koi8u_bin            | koi8u    | 75 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

9.11.7. 중앙 유럽의 캐릭터 세트

체코, 슬로바키아, 헝가리, 루마니아, 슬로베니아, 크로아티아, 폴란드에서 사용되는 캐릭터 세트도 일부 서포트되고 있습니다.

  • cp1250 (Windows 중앙 유럽):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| cp1250_general_ci    | cp1250   | 26 | Yes     |          |       0 |
| cp1250_czech_ci      | cp1250   | 34 |         | Yes      |       2 |
| cp1250_bin           | cp1250   | 66 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • cp852 (DOS 중앙 유럽):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| cp852_general_ci     | cp852    | 40 | Yes     |          |       0 |
| cp852_bin            | cp852    | 81 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • macce (Mac 중앙 유럽):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| macce_general_ci     | macce    | 38 | Yes     |          |       0 |
| macce_bin            | macce    | 43 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • latin2 (ISO 8859-2 중앙 유럽):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| latin2_czech_ci      | latin2   |  2 |         | Yes      |       4 |
| latin2_general_ci    | latin2   |  9 | Yes     |          |       0 |
| latin2_hungarian_ci  | latin2   | 21 |         |          |       0 |
| latin2_croatian_ci   | latin2   | 27 |         |          |       0 |
| latin2_bin           | latin2   | 77 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • keybcs2 (DOS Kamenicky Czech-Slovak ):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| keybcs2_general_ci   | keybcs2  | 37 | Yes     |          |       0 |
| keybcs2_bin          | keybcs2  | 73 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

9.11.8. 서유럽의 캐릭터 세트

서유럽의 캐릭터 세트에는, 대부분의 서유럽 언어(프랑스어, 스페인어, 카타로니아어, 바스크어, 포르투갈어, 이탈리아어, 알바니아어, 네델란드어, 독일어, 덴마크어, 스웨덴어, 노르웨이어, 핀란드어, 펠로우어, 아이슬랜드어, 아일랜드어, 스코틀랜드어, 영어등)가 포함되어 있습니다.

  • latin1 (ISO 8859-1 서유럽):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| latin1_german1_ci    | latin1   |  5 |         |          |       0 |
| latin1_swedish_ci    | latin1   |  8 | Yes     | Yes      |       0 |
| latin1_danish_ci     | latin1   | 15 |         |          |       0 |
| latin1_german2_ci    | latin1   | 31 |         | Yes      |       2 |
| latin1_bin           | latin1   | 47 |         | Yes      |       0 |
| latin1_general_ci    | latin1   | 48 |         |          |       0 |
| latin1_general_cs    | latin1   | 49 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

    latin1_swedish_ci 조합 순서는,MySQL 유저의 대다수가 디폴트로서 사용하고 있다고 생각할 수 있습니다.일관해서 말해 온 것처럼, 이것은 스웨덴어/ 핀란드어의 조합 순서 룰에 근거하고 있습니다만, 스웨덴과 핀란드에는 의견이 다른 유저도 존재합니다.

    latin1_german1_ci 및 latin1_german2_ci 조합 순서는 DIN-1 및 DIN-2 표준에 근거합니다.여기서 DIN (이)란 Deutsches Institut für Normung (독일 공업 규격.ANSI 의 독일판)을 가리킵니다. DIN-1 (은)는 사전 조합,DIN-2 (은)는 전화번호부 조합으로 불리고 있습니다.

    • latin1_german1_ci (사전) 룰:

      ‘Ä ＇ = ‘A ＇, ‘Ö ＇ = ‘O ＇, ‘Ü ＇ = ‘U ＇, ‘ß ＇ = ‘s ＇

    • latin1_german2_ci (전화번호부) 룰:

      ‘Ä ＇ = 'AE', ‘Ö ＇ = 'OE', ‘Ü ＇ = 'UE', ‘ß ＇ = 'ss'

  • macroman (Mac 서유럽):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| macroman_general_ci  | macroman | 39 | Yes     |          |       0 |
| macroman_bin         | macroman | 53 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+

  • cp850 (DOS 서유럽):

    +----------------------+----------+----+---------+----------+---------+
| Collation            | Charset  | Id | Default | Compiled | Sortlen |
+----------------------+----------+----+---------+----------+---------+
| cp850_general_ci     | cp850    |  4 | Yes     |          |       0 |
| cp850_bin            | cp850    | 80 |         |          |       0 |
+----------------------+----------+----+---------+----------+---------+


제10 장 MySQL 에 있어서의 공간 정보의 기능

목차

10.1. 처음에
10.2. OpenGIS Geometry 모델
10.2.1. Geometry Class 계층
10.2.2. Geometry 클래스
10.2.3. 클래스 Point
10.2.4. Curve 클래스
10.2.5. LineString 클래스
10.2.6. Surface 클래스
10.2.7. Polygon 클래스
10.2.8. GeometryCollection 클래스
10.2.9. MultiPoint 클래스
10.2.10. MultiCurve 클래스
10.2.11. MultiLineString 클래스
10.2.12. MultiSurface 클래스
10.2.13. MultiPolygon 클래스
10.3. 서포트되고 있는 공간 데이터 형식
10.3.1. Well-Known Text (WKT ) 형식
10.3.2. Well-Known Binary (WKB ) 형식
10.4. 공간적으로 유효한 MySQL 데이타베이스의 작성
10.4.1. MySQL 공간 데이터형
10.4.2. 공간 정보의 값의 작성
10.4.3. 공간 정보 컬럼의 작성
10.4.4. 공간 정보 컬럼에게의 데이터 입력
10.4.5. 공간 데이터의 혼잡
10.5. 공간 정보의 분석
10.5.1. 지오메트리의 형식을 변환하는 함수
10.5.2. Geometry 프롭퍼티 분석 함수
10.5.3. 기존 지오메트리로부터 신규 지오메트리를 작성하는 함수
10.5.4. Geometry Object간의 공간적 관계를 테스트하기 위한 함수
10.5.5. 최소 외접 구형(MBR )에 있어서의 관계
10.5.6. 지오메트리간의 공간 관계를 테스트하는 함수
10.6. 공간 분석의 최적화
10.6.1. 공간 인덱스의 작성
10.6.2. 공간 인덱스의 사용
10.7. MySQL 의 적합성과 호환성
10.7.1. 아직 실장되어 있지 않다 GIS 기능

MySQL 4.1 그럼 공간 정보를 취급하는 기능이 도입되어 지리적 특성의 생성, 격납, 분석이 가능하게 되어 있습니다. 지리 정보는 현재,MyISAM 테이블 에 대해서만 사용할 수 있습니다.

이 아키라로 다루는 토픽은 이하대로입니다.

  • OpenGIS Geometry 모델에 있어서의 공간 정보를 취급하는 기능의 기본

  • 공간 데이터를 표현하기 위한 데이터 형식

  • MySQL 그리고 공간 데이터를 사용하는 방법

  • 공간 데이터에 대한 색인 작성의 사용

  • MySQL 하지만 OpenGIS 사양과 다른 점

10.1. 처음에

MySQL (은)는,Open GIS Consortium (OGC )의 사양에 준거한 공간 정보의 기능을 실장합니다.OGC (은)는, 합계 250 (을)를 넘는 단체로부터 되는 국제 컨소시엄입니다.가맹하고 있는 기업, 정부 기관, 대학에서는, 공개 가능한 개념 솔루션을 개발하고 있어, 그러한 솔루션은, 공간 데이터를 관리하는 모든 어플리케이션으로 사용할 수 있는 것입니다. OGC 의 Web 사이트는 http://www.opengis.org/ 입니다.

1997 해,Open GIS Consortium 하 OpenGIS (R) Simple Features Specifications For SQL (을)를 공개했습니다.이 문서에서는,SQL RDBMS (을)를 확장해 공간 데이터를 서포트하기 위한 개념적인 수법이 몇개인가 제안되고 있습니다.이 사양은,Open GIS Web 사이트(http://www.opengis.org/techno/implementation.htm )(으)로 입수 가능하고, 이 장의 보충 정보가 기재되어 있습니다.

MySQL (은)는,OGC 에 의해 제안되고 있다 Geometry Type를 가진다 SQL 환경의 부분집합을 실장합니다. 이것은, Geometry Type세트에 의해 확장되었다 SQL 환경입니다.지오메트리치를 가진다 SQL 컬럼은, Geometry Type의 컬럼으로서 실장됩니다.사양에는,SQL Geometry Type세트와 지오메트리치의 작성이라고 분석에 사용되는, 이러한 타입의 각종 함수에 대해 기술되고 있습니다.

지리적 특성 (와)과는, 실세계에 있고 위치를 가지는 존재를 가리킵니다. 지리적 특성의 예를 이하에 나타냅니다.

  • 실체.예를 들어 산, 연못, 도시.

  • 공간.예를 들어 우편번호 에리어, 열대 지방.

  • 정의 가능한 장소.예를 들어 교차 도로(2 개대로가 교차하는 지점).

또,geospatial( 지리 공간) 그렇다고 하는 용어가 사용되고 있는 문서를 찾아, 지리 공간에 도착해 자세한 정보를 얻을 수도 있습니다.

지오메트리 (은)는, 지리 정보의 기능을 나타내는 다른 용어입니다. 지오메트리 (은)는 본래, 수학의 한 분야인 기하학을 의미합니다. 이제(벌써) 1 개의 의미는 지도 작성법으로 유래해, 지도의 작성시에 사용되는 지리적인 특성을 가리킵니다.

이 장에서는, 지리적 특성 , 지리 공간 특성 , 지물 , 지오메트리 (을)를 모두 동의어로서 사용하고 있습니다. 사용 빈도가 가장 높은 용어는 지오메트리 입니다.

여기에서는, 지오메트리 (을)를 위치를 가져 존재를 나타내는 포인트 또는 포인트의 모임 (이)라고 정의합니다.


10.2. OpenGIS Geometry 모델

OGC 의 Geometry Type를 가진다 SQL 환경에서 제안되고 있는 Geometry Type세트는,OpenGIS Geometry 모델 에 근거합니다.이 모델에서는, 각 Geometry Object에 이하의 범용 특성이 있습니다.

  • 공간 참조계(오브젝트가 정의되는 좌표 공간을 나타낸다)에 관련지을 수 있고 있다.

  • Geometry Class에 속하고 있다.

10.2.1. Geometry Class 계층

Geometry Class의 계층은 이하대로입니다.

  • Geometry (인스턴스화할 수 없다)

    • Point (인스턴스화할 수 있다)

    • Curve (인스턴스 할 수 없다)

      • LineString (인스턴스화할 수 있다)

        • Line

        • LinearRing

    • Surface (인스턴스화할 수 없다)

      • Polygon (인스턴스화할 수 있다)

    • GeometryCollection (인스턴스화할 수 있다)

      • MultiPoint (인스턴스화할 수 있다)

      • MultiCurve (인스턴스화할 수 없다)

        • MultiPoint (인스턴스화할 수 있다)

      • MultiSurface (인스턴스화할 수 없다)

        • MultiPolygon (인스턴스화할 수 있다)

이러한 클래스의 일부는 추상 클래스(인스턴스화할 수 없는 클래스)입니다.즉, 이러한 클래스의 오브젝트를 작성할 수 없습니다.다른 클래스는 인스턴스화가 가능하고, 오브젝트를 작성할 수 있습니다. 각 클래스에는 프롭퍼티가 있어, 인스턴스화 가능한 클래스에는 아서트(유효한 클래스 인스턴스를 정의하는 룰)가 포함되어 있는 경우가 있습니다.

Geometry (은)는 기본 클래스입니다.이것은 추상 클래스입니다. Geometry 의 인스턴스화 가능 서브 클래스는,2 차원의 좌표 공간에 존재한다 0 차원,1 차원,2 차원의 Geometry Object에 제한되고 있습니다.인스턴스화 가능한 Geometry Class는 모두, 유효한 인스턴스가 위상적으로 닫도록(듯이) 정의되고 있습니다(모든 정의가 끝난 지오메트리에는 경계가 포함되어 있습니다).

기본 Geometry 클래스에는,Point ,Curve ,Surface ,GeometryCollection 의 서브 클래스가 있습니다.

  • Point 하 0 차원 오브젝트를 나타낸다.

  • Curve 하 1 차원 오브젝트를 나타낸다.이 클래스에는, 서브 클래스 LineString 외, 서브 서브 클래스 Line 및 LinearRing 하지만 속하고 있다.

  • Surface 하 2 차원 오브젝트용으로 설계되고 있어 그 아래에 서브 클래스 Polygon 하지만 있다.

  • GeometryCollection 에는,0 차원,1 차원,2 차원의 콜렉션 클래스,MultiPoint ,MultiLineString ,MultiPolygon 하지만 포함되어 있다.이러한 클래스는, 각각Point ,LineString ,Polygon 의 콜렉션이 되어 있는 지오메트리를 모델화하기 위한 것이다. MultiCurve (와)과 MultiSurface (은)는, 복수의 Curve (와)과 Surface (을)를 처리하는 콜렉션 인터페이스를 범용화하는 추상 슈퍼 클래스로서 도입되고 있다.

Geometry ,Curve ,Surface ,MultiCurve ,MultiSurface (은)는, 인스턴스화할 수 없는 클래스로서 정의됩니다. 이러한 클래스에는, 각각의 서브 클래스용 메소드의 공통 세트가 정의되고 있습니다.이것들은 확장 목적으로 포함되어 있습니다.

Point ,LineString ,Polygon ,GeometryCollection , MultiPoint ,MultiLineString ,MultiPolygon (은)는 인스턴스화가 가능한 클래스입니다.

10.2.2. Geometry 클래스

Geometry (은)는 계층 루트 클래스입니다.이것은 인스턴스화할 수 없는 클래스입니다만,Geometry 서브 클래스로부터 작성된 모든 지오메트리의 값에 대해서 공통된 다수의 프롭퍼티를 포함하고 있습니다. 이러한 프롭퍼티를 이하에 나타냅니다.특정의 서브 클래스에는 고유의 프롭퍼티가 있습니다만, 그것에 대해서는 후술 합니다.

지오메트리의 프롭퍼티

지오메트리치에는 이하의 프롭퍼티가 있습니다.

  • 타입 . 각 지오메트리는, 계층상의 인스턴스화 가능한 클래스의 어느 쪽인가에 속한다.

  • SRID (Spatial Reference Identifier = 공간 참조 식별자).지오메트리에 관련지을 수 있는 공간 참조계(Geometry Object가 정의되는 좌표 공간을 나타낸다)가, 이 값으로 식별된다.

  • 공간 참조계에 있어서의 좌표 .배정도(8 아르바이트)의 수치로 표현된다.공백 이외의 지오메트리에는, 적어도 1 조(X,Y )의 좌표가 포함되어 있다.공백의 지오메트리에는 좌표가 포함되지 않는다.

    좌표는 SRID 에 관련지을 수 있고 있다. 예를 들어, 다른 좌표계에서는, 양쪽 모두의 오브젝트의 좌표가 일치하고 있어도 오브젝트간의 거리가 일치하지 않는 것이 있다. 평면 좌표계로의 거리와 지심 좌표계(지구 표면상의 좌표)로의 거리는 같은 것은 아니기 때문에이다.

  • 내부 , 경계 , 외부 .

    모든 지오메트리는, 공간의 어딘가의 위치를 차지한다.지오메트리의 외부란, 지오메트리에 의해서 점유 되어 있지 않은 공간의 모든 것을 가리킨다.지오메트리의 내부란, 지오메트리에 의해서 점유 되고 있는 공간을 가리킨다.경계는, 지오메트리의 내부와 외부의 접촉면이다.

  • MBR (Minimum Bounding Rectangle = 최소 외접 구형) 또는 Envelope . 이것은 경계 지오메트리이며, 최소와 최대(X,Y )의 좌표로 형성된다.

    ((MINX MINY, MAXX MINY, MAXX MAXY, MINX MAXY, MINX MINY))

  • 단순 일까 비단순 일까의 성질. 몇개의 타입(LineString ,MultiPoint ,MultiLineString )의 지오메트리치는 단순 또는 비단순하게 된다.단순한가 비단순한가에 관한 판정은 각 타입으로 결정.

  • 닫고 있다 인가 닫지 않았다 인가의 성질. 몇개의 타입(LineString ,MultiString )의 지오메트리치는, 닫고 있다/ 닫지 않은 것 어느 쪽인가에 된다.닫고 있는지 어떤지에 관한 독자적인 판정은 각 타입으로 결정.

  • 공 인가 하늘이 아니다 인가의 성질. 지오메트리는,Point (을)를 가지지 않는 경우에 비운다. 공백 지오메트리의 외부, 내부, 경계는 정의되지 않는다(즉,NULL 값으로 표현된다). 공백 지오메트리는, 항상 단순하고 0 의 영역을 가지도록(듯이) 정의된다.

  • 차원 .지오메트리는,－1 ,0 ,1 ,2 의 몇개의 차원이 된다.

    • －1 (은)는, 지오메트리하늘인 것을 나타낸다.

    • 0 (은)는, 지오메트리에 길이와 영역이 없는 것을 나타내 보인다.

    • 1 (은)는, 지오메트리의 길이가 0 이외로 영역이 0 인 것을 나타낸다.

    • 2 (은)는, 지오메트리의 영역이 0 이외인 것을 나타낸다.

    Point 오브젝트는 0 차원.LineString 오브젝트는 1 차원.Polygon 오브젝트는 2 차원.MultiPoint ,MultiLineString , 및 MultiPolygon 오브젝트의 차원은, 각각의 구성요소의 차원과 같다.

10.2.3. 클래스 Point

Point (은)는, 좌표 공간에 있어서의 단일의 장소를 나타내는 지오메트리입니다.

Point 의 예

  • 축척이 큰 세계 지도에 다수의 도시가 포함되어 있는 경우,Point (은)는 각 도시를 나타낸다.

  • 시내 지도의 경우,Point (은)는 버스 정류장을 나타낸다.

Point 의 프롭퍼티

  • X 좌표치.

  • Y 좌표치.

  • Point (은)는,0 차원의 지오메트리로서 정의된다.

  • Point 의 경계는 하늘세트.

10.2.4. Curve 클래스

Curve 하 1 차원의 지오메트리이며, 통상은 일련의 Point 에 의해서 표현됩니다.Curve 의 특정의 서브 클래스에서는,Point 사이중삽이 정의됩니다.Curve (은)는 인스턴스화할 수 없는 클래스입니다.

Curve 의 프롭퍼티

  • 각 Point 의 좌표.

  • Curve (은)는,1 차원의 지오메트리로서 정의된다.

  • Curve (은)는, 같다 Point (을)를 2 회통과하지 않는 경우에는 단순하게 된다.

  • Curve (은)는, 개시 Point 하지만 종료 Point (와)과 일치하는 경우에 닫고 있다.

  • 닫았다 Curve (은)는 하늘이다.

  • 닫지 않았다 Curve 의 경계는,2 개의 종료 Point (으)로 구성된다.

  • 단순하고 닫고 있다 Curve 하 LinearRing 이다.

10.2.5. LineString 클래스

LineString (은)는,Point 사이가 직선 보간 되고 있다 Curve 입니다.

LineString 의 예

  • 세계 지도의 경우,LineString 오브젝트는 하천을 나타낸다.

  • 시내 지도의 경우,LineString 오브젝트는 대로를 나타낸다.

LineString 의 프롭퍼티

  • 연속한 포인트의 페어에 의해서 정의되었다 LineString 세그먼트(segment)의 좌표.

  • LineString (은)는,2 개의 Point 만으로 구성되는 경우에는 Line .

  • LineString (은)는, 닫고 있어 단순한 경우에는 LinearRing .

10.2.6. Surface 클래스

Surface 하 2 차원의 지오메트리입니다.인스턴스화할 수 없는 클래스이며, 그 아래에 속하는 인스턴스화 가능한 서브 클래스는 Polygon 뿐입니다.

Surface 의 프롭퍼티

  • Surface 하 2 차원의 지오메트리로서 정의된다.

  • OpenGIS 사양에서는, 단순한 Surface (은)는, 단일의 외부 경계와 0 이상의 내부 경계에 관련지을 수 있고 있는 단일의 `` 구간'' 만으로 구성되는 지오메트리로서 정의되고 있다.

  • 단순한 Surface 의 경계는, 외부 경계 및 내부 경계에 대응하는 닫았다 Curve 세트.

10.2.7. Polygon 클래스

Polygon (은)는, 복수의 옆을 가지는 지오메트리를 나타내는 평면 Surface 입니다.단일의 외부 경계 및 0 이상의 내부 경계에 의해서 정의됩니다.내부 경계는 각각 Polygon 안의 구멍을 정의합니다.

Polygon 의 예

  • 지역 지도의 경우,Polygon 오브젝트는 삼림, 지구 그 외를 나타낸다.

Polygon 의 아서트

  • Polygon 의 경계는, 외부 경계와 내부 경계를 형성한다 LinearRing 오브젝트(단순하고 닫고 있다 LineString 오브젝트)세트로 구성된다.

  • 2 개의 Ring 하지만 경계에서 사귈 것은 없다.Polygon 의 경계에 있다 Ring 하지만 Point 그리고 사귀는 것은 있다.다만, 그 경우는 접선으로서 사귈 뿐.

  • Polygon 에는, 절단선, 돌기, 함몰의 모두 있어서는 안된다.

  • 각 Polygon (은)는, 접속되었다 Point 세트이다.

  • 1 개이상의 구멍이 있다 Polygon 의 외부는 접속되어 있지 않다. 각각의 구멍은, 외부의 접속된 컴퍼넌트를 나타낸다.

상기의 아서트에서는,Polygon (은)는 단순한 지오메트리입니다.이러한 아서트에 의해,Polygon (은)는 단순한 지오메트리가 됩니다.

10.2.8. GeometryCollection 클래스

GeometryCollection (은)는 단일의 지오메트리입니다만, 임의 클래스의 지오메트리(1 개이상)의 콜렉션이 되고 있습니다.

GeometryCollection 에 포함되는 요소는 모두, 같은 좌표계에 존재하고 있지 않으면 안됩니다. GeometryCollection 그럼, 다른 제한을 요소에 부과하고 있지 않습니다.다만, 이?~ 그리고 설명한다 GeometryCollection 의 서브 클래스에 의해서 멤버쉽이 제한되는 일이 있습니다.제한은 이하에 근거합니다.

  • 요소 타입(예를 들어 MultiPoint 에는 Point 요소만 포함된다)

  • 차원

  • 요소간의 공간적 중복의 정도에 대한 제한

10.2.9. MultiPoint 클래스

MultiPoint (은)는,Point 요소로 구성되는 지오메트리코레크션입니다.각 포인트는 접속되지 않고, 순서 붙일 수 있어도 있지 않습니다.

MultiPoint 의 예

  • 세계 지도의 경우,Multipoint (은)는 작은 군도를 나타낸다.

  • 시내 지도의 경우,Multipoint (은)는 티켓 판매 체인점을 나타낸다.

MultiPoint 의 프롭퍼티

  • MultiPoint (은)는,0 차원의 지오메트리로서 정의된다.

  • MultiPoint (은)는, 같다(좌표치가 일치한다) Point 값의 페어가 없는 경우에는 단순하다.

  • MultiPoint 의 경계는 하늘세트.

10.2.10. MultiCurve 클래스

MultiCurve (은)는,Curve 요소로 구성되는 지오메트리코레크션입니다.MultiCurve (은)는 인스턴스화할 수 없는 클래스입니다.

MultiCurve 의 프롭퍼티

  • MultiCurve (은)는,1 차원의 지오메트리로서 정의된다.

  • MultiCurve 하지만 단순해요는, 그 요소가 모두 단순하고, 모든 2 요소의 교점만이 2 요소의 경계상의 포인트에 존재하는 경우 뿐이다.

  • MultiCurve (을)를 취득하려면 , 다음의 ``mod 2 union rule'' (별명은 odd-even rule )(을)를 적용한다. 즉,MultiCurve 요소로 홀수의 경계에 있다 Point (은)는,MultiCurve 의 경계에 있다.

  • MultiCurve (은)는, 모든 요소가 닫고 있는 경우에 닫고 있다.

  • 닫았다 MultiCurve (은)는 항상 하늘이다.

10.2.11. MultiLineString 클래스

MultiLineString (은)는,LineString 요소로 구성된다 MultiCurve 지오메트리코레크션입니다.

MultiLineString 의 예

  • 지역 지도의 경우,MultiLineString (은)는 수계 또는 간선도로망을 나타낸다.

10.2.12. MultiSurface 클래스

MultiSurface (은)는, 지표면요소로 구성되는 지오메트리코레크션입니다. MultiSurface (은)는 인스턴스화할 수 없는 클래스이며, 그 아래에 속하는 인스턴스화 가능한 서브 클래스는 MultiPolygon 뿐입니다.

MultiSurface 의 아서트

  • MultiSurface 그럼,2 개의 Surface 의 내부가 교차할 것은 없다.

  • MultiSurface 그럼, 언젠가 2 개의 요소의 경계가 유한의 점수로 교차하는 일이 있다.

10.2.13. MultiPolygon 클래스

MultiPolygon (은)는,Polygon 요소로 구성된다 MultiSurface 오브젝트입니다.

MultiPolygon 의 예

  • 지역 지도의 경우,MultiPolygon (은)는 호수와 늪계를 나타낸다.

MultiPolygon 의 아서트

  • MultiPolygon 의 요소가 되어 있다 2 개의 Polygon 값의 내부가 교차할 것은 없다.

  • MultiPolygon 의 요소가 되어 있는 언젠가 2 개의 Polygon 값에 있어서의 경계도 교차할 것은 없고, 유한 포인트수로 접촉하는 일이 있는 것만으로 있다. (전술한 아서트에 대해도, 교차는 금?~ 되고 있다.)

  • MultiPolygon 에는, 절단선, 돌기, 함몰의 모두 있어서는 안된다.MultiPolygon (은)는, 통상이 닫았다 Point 세트이다.

  • 1 개이상의 Polygon (으)로 구성된다 MultiPolygon 의 내부는 접속되어 있지 않다.MultiPolygon 내부의 접속된 컴퍼넌트의 수는,MultiPolygon 에 있어서의 Polygon 값의 수로 일치한다.

MultiPolygon 의 프롭퍼티

  • MultiPolygon 하 2 차원의 지오메트리로서 정의된다.

  • MultiPolygon 의 경계는,Polygon 요소의 경계에 대응하는 닫았다 Curve (LineString 값)세트이다.

  • MultiPolygon 의 경계내의 각 Curve (은)는, 단일의 요소 Polygon 의 경계에 해당된다.

  • 요소 Polygon 의 경계의 각 Curve (은)는,MultiPolygon 의 경계에 속한다.


10.3. 서포트되고 있는 공간 데이터 형식

이 섹션에서는, 쿼리로 Geometry Object를 표현하기 위해서 사용되는 표준적인 공간 데이터 형식에 대해 설명합니다. 구체적으로는, 이하의 데이터 형식이 대상이 됩니다.

  • Well-Known Text (WKT ) 형식

  • Well-Known Binary (WKB ) 형식

MySQL 그리고 지오메트리치가 내부적으로 보존되는 형식은,WKT 형식에서도 WKB 형식이기도 하지 않습니다.

10.3.1. Well-Known Text (WKT ) 형식

지오메트리의 Well-Known Text (WKT ) 표현은, 지오메트리데이타를 ASCII 형식에서 교환하기 위한의 것입니다.

Geometry Object의 WKT 의 예

  • Point:

    POINT(15 20)

    주의: Point 좌표는 콤마 없이 지정된다.

  • Point 하지만 4 개 있다 LineString .

    LINESTRING(0 0, 10 10, 20 25, 50 60)

  • 외부 Ring (와)과 내부 Ring 하지만 1 개씩 있다 Polygon .

    POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7, 5 5))

  • Point 값이 3 개 있다 MultiPoint .

    MULTIPOINT(0 0, 20 20, 60 60)

  • LineString 값이 2 개 있다 MultiLineString .

    MULTILINESTRING((10 10, 20 20), (15 15, 30 15))

  • Polygon 값이 2 개 있다 MultiPolygon .

    MULTIPOLYGON(((0 0,10 0,10 10,0 10,0 0)),((5 5,7 5,7 7,5 7, 5 5)))

  • 2 개의 Point 값과 1 개의 LineString (으)로 구성된다 GeometryCollection .

    GEOMETRYCOLLECTION(POINT(10 10), POINT(30 30), LINESTRING(15 15, 20 20))

WKT 값을 기술하기 위한 정식적 프로덕션 룰을 지정한다 Backus-Naur 문법에 대해서는, 이 장의 첫머리에서 언급되고 있다 OGC 시방서를 참조해 주세요.

10.3.2. Well-Known Binary (WKB ) 형식

지오 시학치의 Well-Known Binary (WKB ) 표현은,OpenGIS 사양에 의해서 정의되고 있습니다. 또,ISO ``SQL/MM Part 3: Spatial'' 표준에서도 정의되고 있습니다.

지오 시학 WKB 정보를 포함한다 BLOB 값으로 표현되는 바이너리 스트림으로서 지오메트리치를 교환하기 위해서,WKB (을)를 사용합니다.

1 아르바이트의 부호 없음 정수,4 아르바이트의 부호 없음 정수,8 아르바이트의 배정도 수치(IEEE 754 형식)이 WKB 에 의해서 사용됩니다.1 아르바이트는 8 비트입니다.

예를 들어 WKB 값이 POINT(1 1) 에 대응하는 경우, 이 값은 다음의 21 아르바이트의 연속(여기에서는 2 자리수의 16 진수로 1 아르바이트)로 구성됩니다.

0101000000000000000000F03F000000000000F03F

상기의 수치는 이하의 구성요소에 분할할 수 있습니다.

Byte order : 01
WKB type   : 01000000
X          : 000000000000F03F
Y          : 000000000000F03F

구성요소의 표현은 이하대로입니다.

  • 아르바이트 순위는 0 또는 1 (이어)여, 각각 little endian와 빅 endian에 의한 격납을 나타낸다.little endian와 빅 endian에 의한 아르바이트 순위는, 각각 네트워크 데이터 표현(NDR )(와)과 외부 데이터 표현(XDR )(으)로서도 알려져 있다.

  • WKB 타입은, Geometry Type를 나타내는 코드이다.1 ~ 7 의 값은 각각,Point ,LineString ,Polygon ,MultiPoint ,MultiLineString ,MultiPolygon ,GeometryCollection (을)를 나타낸다.

  • Point 의 값은 X (와)과 Y 의 좌표를 포함하고 있어 각각 배정도의 값으로 해서 표현된다.

보다 복잡한 지오메트리치에 대응한다 WKB 값은, 보다 복잡한 데이터 구조로 표현됩니다(상세한 것에 대하여는 OpenGIS 사양을 참조해 주세요).


10.4. 공간적으로 유효한 MySQL 데이타베이스의 작성

이 섹션에서는,MySQL 그리고 공간 데이터를 표현하기 위해서 사용할 수 있는 데이터형과 공간치의 작성 및 검색에 사용할 수 있는 함수에 대해 설명합니다.

10.4.1. MySQL 공간 데이터형

MySQL 에는,OpenGIS Geometry 모델의 클래스 계층내의 클래스에 대응하는 데이터형세트가 준비되어 있습니다.이러한 데이터형에는, 단일 지오메트리치를 보관 유지하는 것도 있습니다.

  • GEOMETRY

  • POINT

  • LINESTRING

  • POLYGON

GEOMETRY (은)는, 단일치 데이터형중에서 가장 범용적이고, 어느 타입의 지오메트리치에서도 격납할 수 있습니다. 다른 단일치 데이터형에서는, 특정 한편 단일의 Geometry Type에 값이 제한됩니다.

상기 이외의 데이터형에서는, 값의 콜렉션이 보관 유지됩니다.

  • MULTIPOINT

  • MULTILINESTRING

  • MULTIPOLYGON

  • GEOMETRYCOLLECTION

GEOMETRYCOLLECTION 그럼, 모든 타입의 오브젝트의 콜렉션을 격납할 수 있습니다.다른 콜렉션 타입에서는, 콜렉션 멤버는 특정의 Geometry Type를 가지는 것에 제한됩니다.

10.4.2. 공간 정보의 값의 작성

이 섹션에서는,Well-Known Text 및 Well-Known Binary 함수(OpenGIS 표준으로 정의)와 MySQL 고유의 함수를 사용해 공간 정보의 값을 작성하는 방법에 대해 설명합니다.

10.4.2.1. WKT 함수에 의한 지오메트리치의 작성

MySQL 에는,Well-Known Text 표현( 및 옵션으로서 공간 참조계 ID (SRID )) (을)를 입력 파라미터로서 받아, 대응하는 지오메트리를 돌려주는 함수가 다수 준비되어 있습니다.

GeomFromText() (은)는, 임의의 Geometry Type의 WKT (을)를 최초의 인수로서 받습니다.타입 고유의 작성 함수도 준비되어 있어 이것들은 각 Geometry Type의 지오메트리치를 생성하기 위해서 사용됩니다.

  • GeomFromText(wkt[,srid]) , GeometryFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고, 임의의 타입의 지오메트리치를 생성한다.

  • PointFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고,POINT 값을 생성한다.

  • LineFromText(wkt[,srid]) , LineStringFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고,LINESTRING 값을 생성한다.

  • PolyFromText(wkt[,srid]) , PolygonFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고,POLYGON 값을 생성한다.

  • MPointFromText(wkt[,srid]) , MultiPointFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고,MULTIPOINT 값을 생성한다.

  • MLineFromText(wkt[,srid]) , MultiLineStringFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고,MULTILINESTRING 값을 생성한다.

  • MPolyFromText(wkt[,srid]) , MultiPolygonFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고,MULTIPOLYGON 값을 생성한다.

  • GeomCollFromText(wkt[,srid]) , GeometryCollectionFromText(wkt[,srid])

    WKT 표현과 SRID (을)를 사용하고,GEOMETRYCOLLECTION 값을 생성한다.

Ring 또는 닫았다 LineString 값의 콜렉션의 WKT 표현에 근거해 Polygon 값 또는 MultiPolygon 값을 생성하기 위한 옵션 함수에 대해서도,OpenGIS 사양에 기술되고 있습니다.이러한 값은 교차할 수 있습니다.이러한 함수는,MySQL 에 아직 실장되고 있지 않습니다.

  • BdPolyFromText(wkt,srid)

    닫았다 LineString 값으로부터 완성되는 임의의 콜렉션이 포함되어 있다 MultiLineString 값(WKT 형식)으로부터 Polygon 값을 생성한다.

  • BdMPolyFromText(wkt,srid)

    닫았다 LineString 값으로부터 완성되는 임의의 콜렉션이 포함되어 있다 MultiLineString 값(WKT 형식)으로부터 MultiPolygon 값을 생성한다.

10.4.2.2. WKB 함수에 의한 지오메트리치의 작성

Well-Known Binary 표현이 포함되어 있다 BLOB ( 및 옵션으로서 공간 참조계 ID (SRID ))를 입력 파라미터로서 받아, 대응하는 지오메트리를 돌려주는 함수가 MySQL 에 다수 준비되어 있습니다.

GeomFromWKT() (은)는, 임의의 Geometry Type의 WKB (을)를 최초의 인수로서 받습니다.타입 고유의 작성 함수도 준비되어 있어 이것들은 각 Geometry Type의 지오메트리치를 생성하기 위해서 사용됩니다.

  • GeomFromWKB(wkb[,srid]) , GeometryFromWKB(wkt[,srid])

    WKB 표현과 SRID (을)를 사용하고, 임의의 타입의 지오메트리치를 생성한다.

  • PointFromWKB(wkb[,srid])

    WKB 표현과 SRID (을)를 사용하고,POINT 값을 생성한다.

  • LineFromWKB(wkb[,srid]) , LineStringFromWKB(wkb[,srid])

    WKB 표현과 SRID (을)를 사용하고,LINESTRING 값을 생성한다.

  • PolyFromWKB(wkb[,srid]) , PolygonFromWKB(wkb[,srid])

    WKB 표현과 SRID (을)를 사용하고,POLYGON 값을 생성한다.

  • MPointFromWKB(wkb[,srid]) , MultiPointFromWKB(wkb[,srid])

    WKB 표현과 SRID (을)를 사용하고,MULTIPOINT 값을 생성한다.

  • MLineFromWKB(wkb[,srid]) , MultiLineStringFromWKB(wkb[,srid])

    WKB 표현과 SRID (을)를 사용하고,MULTILINESTRING 값을 생성한다.

  • MPolyFromWKB(wkb[,srid]) , MultiPolygonFromWKB(wkb[,srid])

    WKB 표현과 SRID (을)를 사용하고,MULTIPOLYGON 값을 생성한다.

  • GeomCollFromWKB(wkb[,srid]) , GeometryCollectionFromWKB(wkt[,srid])

    WKB 표현과 SRID (을)를 사용하고,GEOMETRYCOLLECTION 값을 생성한다.

Ring 또는 닫았다 LineString 값의 콜렉션의 WKB 표현에 근거해 Polygon 또는 MultiPolygon (을)를 생성하기 위한 옵션 함수에 대해서도,OpenGIS 사양에 기술되고 있습니다.이러한 값은 교차할 수 있습니다.이러한 함수는,MySQL 에 아직 실장되고 있지 않습니다.

  • BdPolyFromWKB(wkb,srid)

    닫았다 LineString 값으로부터 완성되는 임의의 콜렉션이 포함되어 있다 MultiLineString 값(WKB 형식)으로부터 Polygon 값을 생성한다.

  • BdMPolyFromWKB(wkb,srid)

    닫았다 LineString 값으로부터 완성되는 임의의 콜렉션이 포함되어 있다 MultiLineString 값(WKB 형식)으로부터 MultiPolygon 값을 생성한다.

10.4.2.3. MySQL 고유의 함수에 의한 지오메트리치의 작성

주의: 이 섹션으로 채택하는 함수는,MySQL 에 아직 실장되고 있지 않습니다.

지오메트리 WKB 표현을 작성할 때에 도움이 되는 함수가 MySQL 에 준비되어 있습니다.이 섹션으로 설명하는 함수는,OpenGIS 사양에 대한다 MySQL 확장입니다.이러한 함수의 결과,SRID (이)가 없는 지오메트리치의 WKB 표현을 포함한다 BLOB 값이 돌려주어집니다. 이러한 함수의 결과는,GeomFromWKB() 함수 파?~ 리에 포함되는 어느 함수에 대해서도, 최초의 인수로서 대용할 수 있습니다.

  • Point(x,y)

    좌표를 사용해 WKB Point (을)를 생성한다.

  • MultiPoint(pt1,pt2,...)

    WKB Point 인수를 사용해 WKB MultiPoint 값을 생성한다. 몇개의 인수가 WKBPoint (이)가 아닌 경우, 돌아가 값은 NULL (이)가 된다.

  • LineString(pt1,pt2,...)

    WKB Point 인수로부터 WKB LineString 값을 생성한다.몇개의 인수가 WKB Point (이)가 아닌 경우, 돌아가 값은 NULL (이)가 된다.Point 인수가 2 개에 못 미친 경우, 돌아가 값은 NULL (이)가 된다.

  • MultiLineString(ls1,ls2,...)

    WKB LineString 인수를 사용해 WKB MultiLineString 값을 생성한다.몇개의 인수가 LineString (이)가 아닌 경우, 돌아가 값은 NULL (이)가 된다.

  • Polygon(ls1,ls2,...)

    WKB LineString 인수로부터 WKB Polygon 값을 생성한다.몇개의 인수가 LinearRing 의WKB (을)를 나타내지 않는 경우(닫고 있는 단순한 LineString (이)가 아닌 경우), 돌아가 값은 NULL (이)가 된다.

  • MultiPolygon(poly1,poly2,...)

    WKB Polygon 인수로부터 WKB MultiPolygon 값을 생성한다. 몇개의 인수가 WKB Polygon (이)가 아닌 경우, 돌아가 값은 NULL (이)가 된다.

  • GeometryCollection(g1,g2,...)

    WKB GeometryCollection (을)를 생성한다.몇개의 인수가 지오메트리의 WKB 표현으로서 적절하지 않은 경우, 돌아가 값은 NULL (이)가 된다.

10.4.3. 공간 정보 컬럼의 작성

Geometry Type에 대해서 공간 정보 컬럼을 작성하는 표준적인 방법이 MySQL 에 준비되어 있습니다(예를 들어 CREATE TABLE 또는 ALTER TABLE (을)를 사용). 공간 정보 컬럼은 현재,MyISAM 테이블 에 대해서만 서포트되고 있습니다.

  • CREATE TABLE 스테이트먼트를 사용해, 공간 정보 컬럼이 있는 테이블을 작성한다.

    mysql> CREATE TABLE geom (g GEOMETRY);
Query OK, 0 rows affected (0.02 sec)

  • ALTER TABLE 스테이트먼트를 사용해, 기존 테이블에 공간 정보 컬럼을 추가하거나 기존 테이블의 공간 정보 컬럼을 파기하거나 한다.

    mysql> ALTER TABLE geom ADD pt POINT;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0
mysql> ALTER TABLE geom DROP pt;
Query OK, 0 rows affected (0.00 sec)
Records: 0  Duplicates: 0  Warnings: 0

10.4.4. 공간 정보 컬럼에게의 데이터 입력

작성한 공간 정보 컬럼에게는, 공간 데이터를 입력할 수 있습니다.

값은 내부 지오메트리 형식에서 격납할 필요가 있습니다만,Well-Known Text (WKT ) 또는 Well-Known Binary (WKB ) 형식으로부터 내부 지오메트리 형식으로 변환하는 것도 가능합니다.WKT 값을 내부 지오메트리 형식으로 변환해 지오메트리치를 테이블에 삽입하는 방법을, 이하의 예에 나타냅니다.

이 변환은,INSERT 스테이트먼트로 직접 실행할 수 있습니다.

INSERT INTO geom VALUES (GeomFromText('POINT(1 1)'));

SET @g = 'POINT(1 1)';
INSERT INTO geom VALUES (GeomFromText(@g));

INSERT 의 전에 변환이 실행되는 경우도 있습니다.

SET @g = GeomFromText('POINT(1 1)');
INSERT INTO geom VALUES (@g);

이하의 예에서는, 보다 복잡한 지오메트리를 테이블에 삽입하고 있습니다.

SET @g = 'LINESTRING(0 0,1 1,2 2)';
INSERT INTO geom VALUES (GeomFromText(@g));

SET @g = 'POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7, 5 5))';
INSERT INTO geom VALUES (GeomFromText(@g));

SET @g = 'GEOMETRYCOLLECTION(POINT(1 1),LINESTRING(0 0,1 1,2 2,3 3,4 4))';
INSERT INTO geom VALUES (GeomFromText(@g));

전술하고 싶은 차이의 예에서도,GeomFromText() (을)를 사용해 지오메트리치를 작성합니다.타입 고유의 함수를 사용할 수도 있습니다.

SET @g = 'POINT(1 1)';
INSERT INTO geom VALUES (PointFromText(@g));

SET @g = 'LINESTRING(0 0,1 1,2 2)';
INSERT INTO geom VALUES (LineStringFromText(@g));

SET @g = 'POLYGON((0 0,10 0,10 10,0 10,0 0),(5 5,7 5,7 7,5 7, 5 5))';
INSERT INTO geom VALUES (PolygonFromText(@g));

SET @g = 'GEOMETRYCOLLECTION(POINT(1 1),LINESTRING(0 0,1 1,2 2,3 3,4 4))';
INSERT INTO geom VALUES (GeomCollFromText(@g));

주의: 클라이언트 응용 프로그램은, 지오메트리치의 WKB 표현을 사용하는 경우, 올바른 형식의 WKB (을)를 쿼리로 서버에 송신하지 않으면 안됩니다.이 요건을 채우려면 몇개의 방법이 있습니다.예를 들어, 이하와 같이 합니다.

  • POINT(1 1) 값을 16 진리터럴 구문으로 삽입한다.

    mysql> INSERT INTO geom VALUES
    -> (GeomFromWKB(0x0101000000000000000000F03F000000000000F03F));

  • ODBC 어플리케이션은 WKB 표현을 송신해, 그것을 플레이스홀더에 바인드 할 수 있다(BLOB 형태의 인수를 사용).

    INSERT INTO geom VALUES (GeomFromWKB(?))

    다른 프로그라?~ 그인타페스에서도, 유사한 플레이스홀더 기구가 서포트되고 있는 경우가 있다.

  • C 프로그램에서는,mysql_real_escape_string() (을)를 사용해 바이너리치를 이스케이프 해, 서버에 송신되는 쿼리 문자열에 결과를 수중에 넣을 수 있다. See 항11.1.3.44. 「mysql_real_escape_string() 」 .

10.4.5. 공간 데이터의 혼잡

테이블에 격납된 지오메트리치는, 내부 형식으로 변환해 수중에 넣을 수 있습니다.이 값은 WKT 또는 WKB 형식으로 변환할 수도 있습니다.

10.4.5.1. 공간 데이터의 혼잡(내부 형식을 사용)

내부 형식에 의한 지오메트리치의 혼잡은, 테이블간의 전송에 유효합니다.

CREATE TABLE geom2 (g GEOMETRY) SELECT g FROM geom;

10.4.5.2. 공간 데이터의 혼잡(WKT 형식을 사용)

AsText() 함수에서는, 지오메트리치를 텍스트로서 사용할 수 있습니다.이 함수는, 지오메트리를 내부 형식으로부터 WKT 문자열로 변환합니다.

mysql> SELECT AsText(g) FROM geom;
+-------------------------+
| AsText(p1)              |
+-------------------------+
| POINT(1 1)              |
| LINESTRING(0 0,1 1,2 2) |
+-------------------------+

10.4.5.3. 공간 데이터의 혼잡(WKB 형식을 사용)

AsBinary() 함수에서는, 지오메트리치를 바이너리로서 사용할 수 있습니다. 이 함수는, 지오메트리를 내부 형식으로부터 BLOB (WKB 값을 포함한다)로 변환합니다.

SELECT AsBinary(g) FROM geom;


10.5. 공간 정보의 분석

공간 정보 컬럼에 값을 입력한 다음은, 쿼리라고 분석을 실시할 수 있습니다.공간 데이터에 대해서 각종의 조작을 실행하기 위한 함수가 MySQL 에 준비되어 있습니다.이러한 함수는, 실행하는 조작에 근거해 4 개의 주요한 카테고리로 분류됩니다.

  • 각종 형식간에 지오메트리를 변환하는 함수

  • 지오메트리의 질적 또는 양적 프롭퍼티에의 액세스를 제공하는 함수

  • 2 개의 지오메트리의 관계를 기술하는 함수

  • 기존 지오메트리로부터 신규 지오메트리를 작성하는 함수

이하와 같이 많은 상황으로, 공간 정보의 분석 함수를 사용할 수 있습니다.

  • 인터랙티브인 SQL 프로그램(mysql ,MySQLCC 등).

  • MySQL 클라이언트 API (을)를 서포트하는 언어로 기술된 응용 프로그램.

10.5.1. 지오메트리의 형식을 변환하는 함수

MySQL 그리고 서포트되고 있는 이하의 함수에서는,WKT 또는 WKB 형식과 내부 형식간에서 지오메트리치를 변환할 수 있습니다.

  • GeomFromText(wkt[,srid])

    문자열치를 WKT 표현으로부터 내부 지오메트리 형식으로 변환해, 결과를 돌려준다. 타입 고유의 함수도 많이 서포트되고 있다(PointFromText() ,LineFromText() 등). 항10.4.2.1. 「WKT 함수에 의한 지오메트리치의 작성」 참조..

  • GeomFromWKB(wkb[,srid])

    바이너리치를 WKB 표현으로부터 내부 지오메트리 형식으로 변환해, 결과를 돌려준다. 타입 고유의 함수도 많이 서포트되고 있다(PointFromWKB() ,LineFromWKB() 등). 항10.4.2.2. 「WKB 함수에 의한 지오메트리치의 작성」 참조.

  • AsText(g)

    내부 지오메트리 형식의 값을 WKT 표현으로 변환해, 결과 문자열을 돌려준다.

    mysql> SET @g = 'LineString(1 1,2 2,3 3)';
mysql> SELECT AsText(GeomFromText(@g));
+--------------------------+
| AsText(GeomFromText(@G)) |
+--------------------------+
| LINESTRING(1 1,2 2,3 3)  |
+--------------------------+

  • AsBinary(g)

    내부 지오메트리 형식의 값을 WKB 표현으로 변환해, 결과의 바이너리치를 돌려준다.

10.5.2. Geometry 프롭퍼티 분석 함수

이 그룹에 속하는 함수는, 지오메트리치를 인수로서 사용해, 지오메트리의 질적 또는 양적 프롭퍼티를 돌려줍니다.일부의 함수에서는, 인수의 타입이 제한되고 있습니다.그러한 함수는, 인수의 Geometry Type가 부정한 경우에 NULL (을)를 돌려줍니다.예를 들어, 오브젝트 타입이 Polygon (와)과 MultiPolygon 의 머지않아도 아닌 경우,Area() 하 NULL (을)를 돌려줍니다.

10.5.2.1. 범용 Geometry 프롭퍼티 분석 함수

이 섹션에 열거되고 있는 함수에는 인수에 대한 제한은 없고, 어느 타입의 지오메트리치도 받아 들여집니다.

  • GeometryType(g)

    지오메트리인스탄스 g 하지만 멤버가 되어 있는 Geometry Type의 명칭을 문자열로서 돌려준다. 이 명칭은, 인스턴스화 가능한 Geometry 서브 클래스의 1 개에 대응한다.

    mysql> SELECT GeometryType(GeomFromText('POINT(1 1)'));
+------------------------------------------+
| GeometryType(GeomFromText('POINT(1 1)')) |
+------------------------------------------+
| POINT                                    |
+------------------------------------------+

  • Dimension(g)

    지오메트리치 g 고유의 차원을 돌려준다.결과는 －1 ,0 ,1 ,2 의 언젠가(이러한 값의 의미에 대해서는 항10.2.2. 「Geometry 클래스」 (을)를 참조).

    mysql> SELECT Dimension(GeomFromText('LineString(1 1,2 2)'));
+------------------------------------------------+
| Dimension(GeomFromText('LineString(1 1,2 2)')) |
+------------------------------------------------+
|                                              1 |
+------------------------------------------------+

  • SRID(g)

    지오메트리치 g 의 공간 참조계 ID (을)를 나타내는 정수를 돌려준다.

    mysql> SELECT SRID(GeomFromText('LineString(1 1,2 2)',101));
+-----------------------------------------------+
| SRID(GeomFromText('LineString(1 1,2 2)',101)) |
+-----------------------------------------------+
|                                           101 |
+-----------------------------------------------+

  • Envelope(g)

    지오메트리치 g 의 최소 외접 구형(MBR )(을)를 돌려준다. 결과는 Polygon 값으로 해서 돌려준다.

    mysql> SELECT AsText(Envelope(GeomFromText('LineString(1 1,2 2)')));
+-------------------------------------------------------+
| AsText(Envelope(GeomFromText('LineString(1 1,2 2)'))) |
+-------------------------------------------------------+
| POLYGON((1 1,2 1,2 2,1 2,1 1))                        |
+-------------------------------------------------------+

    경계 박스의 코너 포인트에 의해서,Polygon 하지만 정의된다.

    POLYGON((MINX MINY, MAXX MINY, MAXX MAXY, MINX MAXY, MINX MINY))

OpenGIS 사양에서는 이하의 함수도 정의하고 있습니다만, 이것들은 MySQL 그리고 아직 실장되고 있지 않습니다.

  • Boundary(g)

    지오메트리치 g 의 편성 경계의 마지막이 되는 지오메트리를 돌려준다.

  • IsEmpty(g)

    지오메트리치 g 하지만 공백 지오메트리이면 1 , 공백이 아니면 0 , 인수가 NULL 이면 －1 (을)를 돌려준다. 지오메트리하늘의 경우, 하늘의 Point 세트를 나타낸다.

  • IsSimple(g)

    현재, 이 함수는 플레이스홀더가 되고 있어 사용해서는 안된다. 실장되었을 경우의 기능에 대해서는, 이하대로.

    지오메트리치 g 에 부정한(자기 교차나 자기 접촉이 일어나고 있다) 지오메트리 Point 하지만 없는 경우,1 (을)를 돌려준다.IsSimple() (은)는, 인수가 단순하면 0 , 인수가 NULL 이면 －1 (을)를 돌려준다.

    인스턴스화 가능한 각 Geometry Class에 대해서는 해당하는 섹션으로 설명했지만, 거기서, 그 클래스의 인스턴스가 비단순과 분류되는 경우의 특정의 조건에 대해 설명하고 있다.

10.5.2.2. Point 프롭퍼티 분석 함수

Point 하X 좌표와 Y 좌표로부터 구성됩니다만, 이것들은 이하의 함수를 사용해 취득할 수 있습니다.

  • X(p)

    Point p 의 X 좌표치를 배정도의 수치로서 돌려준다.

    mysql> SELECT X(GeomFromText('Point(56.7 53.34)'));
+--------------------------------------+
| X(GeomFromText('Point(56.7 53.34)')) |
+--------------------------------------+
|                                 56.7 |
+--------------------------------------+

  • Y(p)

    Point p 의 Y 좌표치를 배정도의 수치로서 돌려준다.

    mysql> SELECT Y(GeomFromText('Point(56.7 53.34)'));
+--------------------------------------+
| Y(GeomFromText('Point(56.7 53.34)')) |
+--------------------------------------+
|                                53.34 |
+--------------------------------------+

10.5.2.3. LineString 프롭퍼티 분석 함수

LineString 하 Point 값으로 구성됩니다.LineString 에 관해, 그 특정 Point (을)를 추출하는지, 포함되어 있다 Point 수를 카운트 하는지, 그 길이를 취득할 수 있습니다.

  • EndPoint(ls)

    LineString 치 ls 의 종점이 되고 있다 Point (을)를 돌려준다.

    mysql> SELECT AsText(EndPoint(GeomFromText('LineString(1 1,2 2,3 3)')));
+------------------------------------------------------------+
| AsText(EndPoint(GeomFromText('LineString(1 1,2 2,3 3)')))  |
+------------------------------------------------------------+
| POINT(3 3)                                                 |
+------------------------------------------------------------+

  • GLength(ls)

    관련하는 공간 참조에 있어서의 LineString 치 ls 의 길이를 배정도의 수치로서 돌려준다.

    mysql> SELECT GLength(GeomFromText('LineString(1 1,2 2,3 3)'));
+--------------------------------------------------+
| GLength(GeomFromText('LineString(1 1,2 2,3 3)')) |
+--------------------------------------------------+
|                                  2.8284271247462 |
+--------------------------------------------------+

  • IsClosed(ls)

    LineString 치 ls 하지만 닫고 있다(StartPoint() 값과 EndPoint() 값이 일치한다) 경우,1 (을)를 돌려준다. ls 하지만 닫지 않으면 0 ,NULL 이면 －1 (을)를 돌려준다.

    mysql> SELECT IsClosed(GeomFromText('LineString(1 1,2 2,3 3)'));
+---------------------------------------------------+
| IsClosed(GeomFromText('LineString(1 1,2 2,3 3)')) |
+---------------------------------------------------+
|                                                 0 |
+---------------------------------------------------+

  • NumPoints(ls)

    LineString 치 ls 에 있어서의 Point 수를 돌려준다.

    mysql> SELECT NumPoints(GeomFromText('LineString(1 1,2 2,3 3)'));
+----------------------------------------------------+
| NumPoints(GeomFromText('LineString(1 1,2 2,3 3)')) |
+----------------------------------------------------+
|                                                  3 |
+----------------------------------------------------+

  • PointN(ls,n)

    LineString 치 ls 에 있어서의 n 번째의 Point (을)를 돌려준다. Point 번호는 1 (으)로부터 시작된다.

    mysql> SELECT AsText(PointN(GeomFromText('LineString(1 1,2 2,3 3)'),2));
+-----------------------------------------------------------+
| AsText(PointN(GeomFromText('LineString(1 1,2 2,3 3)'),2)) |
+-----------------------------------------------------------+
| POINT(2 2)                                                |
+-----------------------------------------------------------+

  • StartPoint(ls)

    LineString 치 ls 의 시점이 되고 있다 Point (을)를 돌려준다.

    mysql> SELECT AsText(StartPoint(GeomFromText('LineString(1 1,2 2,3 3)')));
+-------------------------------------------------------------+
| AsText(StartPoint(GeomFromText('LineString(1 1,2 2,3 3)'))) |
+-------------------------------------------------------------+
| POINT(1 1)                                                  |
+-------------------------------------------------------------+

OpenGIS 사양에서는 이하의 함수도 정의하고 있습니다만, 이것은 MySQL 그리고 아직 실장되고 있지 않습니다.

  • IsRing(ls)

    LineString 치 ls 하지만 닫고 있어(StartPoint() 값과 EndPoint() 값이 일치), 한편, 단순하다(같다 Point (을)를 2 회이상 통과하지 않는다) 경우,1 (을)를 돌려준다. ls 하지만 Ring (이)가 아니면 0 ,NULL 이면 －1 (을)를 돌려준다.

10.5.2.4. MultiLineString 프롭퍼티 분석 함수

  • GLength(mls)

    MultiLineString 치 mls 의 길이를 배정도의 수치로서 돌려준다.mls 의 길이는, 요소의 길이를 합계한 값과 일치한다.

    mysql> SELECT GLength(GeomFromText('MultiLineString((1 1,2 2,3 3),(4 4,5 5))'));
+-------------------------------------------------------------------+
| GLength(GeomFromText('MultiLineString((1 1,2 2,3 3),(4 4,5 5))')) |
+-------------------------------------------------------------------+
|                                                   4.2426406871193 |
+-------------------------------------------------------------------+

  • IsClosed(mls)

    MultiLineString 치 mls 하지만 닫고 있다(mls 그리고 각 LineString 에 대한다 StartPoint() 값과 EndPoint() 값이 일치한다) 경우,1 (을)를 돌려준다. mls 하지만 닫지 않으면 0 ,NULL 이면 －1 (을)를 돌려준다.

    mysql> SELECT IsClosed(GeomFromText('MultiLineString((1 1,2 2,3 3),(4 4,5 5))'));
+--------------------------------------------------------------------+
| IsClosed(GeomFromText('MultiLineString((1 1,2 2,3 3),(4 4,5 5))')) |
+--------------------------------------------------------------------+
|                                                                  0 |
+--------------------------------------------------------------------+

10.5.2.5. Polygon 프롭퍼티 분석 함수

  • Area(poly)

    공간 참조계로의 측정에 근거하고,Polygon 치 poly 의 영역을 배정도의 수치로서 돌려준다.

    mysql> SELECT Area(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))'));
+----------------------------------------------------------------------------+
| Area(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))')) |
+----------------------------------------------------------------------------+
|                                                                          8 |
+----------------------------------------------------------------------------+

  • NumInteriorRings(poly)

    Polygon 치 poly 에 있어서의 내부 Ring 수를 돌려준다.

    mysql> SELECT NumInteriorRings(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))'));
+----------------------------------------------------------------------------------------+
| NumInteriorRings(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))')) |
+----------------------------------------------------------------------------------------+
|                                                                                      1 |
+----------------------------------------------------------------------------------------+

  • ExteriorRing(poly)

    Polygon 치 poly 의 외부 Ring (을)를 LineString (으)로서 돌려준다.

    mysql> SELECT AsText(ExteriorRing(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))')));
+--------------------------------------------------------------------------------------------+
| AsText(ExteriorRing(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))'))) |
+--------------------------------------------------------------------------------------------+
| LINESTRING(0 0,0 3,3 3,3 0,0 0)                                                            |
+--------------------------------------------------------------------------------------------+

  • InteriorRingN(poly,n)

    Polygon 치 poly 의 n 번째의 내부 Ring (을)를 LineString (으)로서 돌려준다. Ring 번호는 1 (으)로부터 시작된다.

    mysql> SELECT AsText(InteriorRingN(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))'),1));
+-----------------------------------------------------------------------------------------------+
| AsText(InteriorRingN(GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1))'),1)) |
+-----------------------------------------------------------------------------------------------+
| LINESTRING(1 1,1 2,2 2,2 1,1 1)                                                               |
+-----------------------------------------------------------------------------------------------+

OpenGIS 사양에서는 이하의 함수도 정의하고 있습니다만, 이것들은 MySQL 그리고 아직 실장되고 있지 않습니다.

  • Centroid(poly)

    Polygon 치 poly 의 수학적인 중심을 Point (으)로서 돌려준다.결과가 Polygon 위에 존재하는 것은 보증되지 않는다.

  • PointOnSurface(poly)

    Polygon 치 poly 에 존재하는 것이 보증된다 Point 값을 돌려준다.

10.5.2.6. MultiPolygon 프롭퍼티 분석 함수

  • Area(mpoly)

    공간 참조계로의 측정에 근거하고,MultiPolygon 치 mpoly 의 영역을 배정도의 수치로서 돌려준다.

    mysql> SELECT Area(GeomFromText('MultiPolygon(((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1)))'));
+-----------------------------------------------------------------------------------+
| Area(GeomFromText('MultiPolygon(((0 0,0 3,3 3,3 0,0 0),(1 1,1 2,2 2,2 1,1 1)))')) |
+-----------------------------------------------------------------------------------+
|                                                                                 8 |
+-----------------------------------------------------------------------------------+

OpenGIS 사양에서는 이하의 함수도 정의하고 있습니다만, 이것들은 MySQL 그리고 아직 실장되고 있지 않습니다.

  • Centroid(mpoly)

    MultiPolygon 치 mpoly 의 수학적인 중심을 Point (으)로서 돌려준다.결과가 MultiPolygon 위에 존재하는 것은 보증되지 않는다.

  • PointOnSurface(mpoly)

    MultiPolygon 치 mpoly 위에 존재하는 것이 보증된다 Point 값을 돌려준다.

10.5.2.7. GeometryCollection 프롭퍼티 분석 함수

  • NumGeometries(gc)

    GeometryCollection 치 gc 에 있어서의 지오메트리수를 돌려준다.

    mysql> SELECT NumGeometries(GeomFromText('GeometryCollection(Point(1 1),LineString(2 2, 3 3))'));
+------------------------------------------------------------------------------------+
| NumGeometries(GeomFromText('GeometryCollection(Point(1 1),LineString(2 2, 3 3))')) |
+------------------------------------------------------------------------------------+
|                                                                                  2 |
+------------------------------------------------------------------------------------+

  • GeometryN(gc,n)

    GeometryCollection 치 gc 에 있어서의 n 번째의 지오메트리를 돌려준다.지오메트리 번호는 1 (으)로부터 시작된다.

    mysql> SELECT AsText(GeometryN(GeomFromText('GeometryCollection(Point(1 1),LineString(2 2, 3 3))'),1));
+------------------------------------------------------------------------------------------+
| AsText(GeometryN(GeomFromText('GeometryCollection(Point(1 1),LineString(2 2, 3 3))'),1)) |
+------------------------------------------------------------------------------------------+
| POINT(1 1)                                                                               |
+------------------------------------------------------------------------------------------+

10.5.3. 기존 지오메트리로부터 신규 지오메트리를 작성하는 함수

10.5.3.1. 신규 지오메트리를 작성하는 함수

섹션 항10.5.2. 「Geometry 프롭퍼티 분석 함수」 그럼, 기존 지오메트리로부터 신규 지오메트리를 구축하는 함수를 몇개인가 채택했습니다.

  • Envelope(g)

  • StartPoint(ls)

  • EndPoint(ls)

  • PointN(ls,n)

  • ExteriorRing(poly)

  • InteriorRingN(poly,n)

  • GeometryN(gc,n)

10.5.3.2. 공간 정보의 연산자

OpenGIS 그럼, 지오메트리를 작성할 수 있는 그 외의 함수가 많이 제안되고 있습니다.이것들은, 공간 연산자를 실장하도록(듯이) 설계되고 있습니다.

그러한 함수는 MySQL 그럼 실장되지 않고, 장래의 릴리스로 실장될 예정입니다.

  • Intersection(g1,g2)

    지오메트리치 g1 및 g2 의 Point 세트 교차를 나타내는 지오메트리를 돌려준다.

  • Union(g1,g2)

    지오메트리치 g1 및 g2 의 Point 세트 접합을 나타내는 지오메트리를 돌려준다.

  • Difference(g1,g2)

    지오메트리치 g1 및 g2 의 Point 세트 차이를 나타내는 지오메트리를 돌려준다.

  • SymDifference(g1,g2)

    지오메트리치 g1 및 g2 의 Point 세트 대칭 차이를 나타내는 지오메트리를 돌려준다.

  • Buffer(g,d)

    지오메트리치 g (으)로부터의 거리가 d 의 거리 이하가 되어 모든 Point (을)를 나타내는 지오메트리를 돌려준다.

  • ConvexHull(g)

    지오메트리치 g 의 철포를 나타내는 지오메트리를 돌려준다.

10.5.4. Geometry Object간의 공간적 관계를 테스트하기 위한 함수

이러한 섹션으로 설명되고 있는 함수는,2 개의 지오메트리를 입력 파라미터로서 받아, 지오메트리간의 질적 또는 양적인 관계를 돌려줍니다.

10.5.5. 최소 외접 구형(MBR )에 있어서의 관계

지오메트리 g1 및 g2 의 최소 외접 구형간의 관계를 테스트할 수 있는 함수가 MySQL 에 준비되어 있습니다. 예를 들어, 이하의 함수가 있습니다.

  • MBRContains(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 의 최소 외접 구형에 g2 의 최소 외접 구형이 포함되어 있는지 어떤지를 나타낸다.

    mysql> SET @g1 = GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0))');
mysql> SET @g2 = GeomFromText('Point(1 1)');
mysql> SELECT MBRContains(@g1,@g2), MBRContains(@g2,@g1);
----------------------+----------------------+
| MBRContains(@g1,@g2) | MBRContains(@g2,@g1) |
+----------------------+----------------------+
|                    1 |                    0 |
+----------------------+----------------------+

  • MBRWithin(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 의 최소 외접 구형이 g2 의 최소 외접 구형에 포함되어 있는지 어떤지를 나타낸다.

    mysql> SET @g1 = GeomFromText('Polygon((0 0,0 3,3 3,3 0,0 0))');
mysql> SET @g2 = GeomFromText('Polygon((0 0,0 5,5 5,5 0,0 0))');
mysql> SELECT MBRWithin(@g1,@g2), MBRWithin(@g2,@g1);
+--------------------+--------------------+
| MBRWithin(@g1,@g2) | MBRWithin(@g2,@g1) |
+--------------------+--------------------+
|                  1 |                  0 |
+--------------------+--------------------+

  • MBRDisjoint(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로, 지오메트리 g1 (와)과 g2 의 2 개의 최소 외접 구형이 분리하고 있는(교차하고 있지 않다) 화도인지를 나타낸다.

  • MBREquals(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로, 지오메트리 g1 (와)과 g2 의 2 개의 최소 외접 구형이 같을지를 나타낸다.

  • MBRIntersects(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로, 지오메트리 g1 (와)과 g2 의 2 개의 최소 외접 구형이 교차하고 있는 어떨까를 나타낸다.

  • MBROverlaps(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로, 지오메트리 g1 (와)과 g2 의 2 개의 최소 외접 구형이 겹치고 있는지 어떤지를 나타낸다.

  • MBRTouches(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로, 지오메트리 g1 (와)과 g2 의 2 개의 최소 외접 구형이 접촉하고 있는 어떨까를 나타낸다.

10.5.6. 지오메트리간의 공간 관계를 테스트하는 함수

OpenGIS 사양에서는 이하의 함수를 정의하고 있습니다만, 이것들은 MySQL 그리고 아직 실장되고 있지 않습니다.장래의 릴리스로 실장될 예정입니다. 실장되면,MBR 베이스의 서포트 뿐만 아니라, 공간 분석의 완전한 서포트가 제공됩니다.

이러한 함수는,2 개의 지오메트리치 g1 및 g2 그리고 동작합니다.

  • Contains(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 에 g2 하지만 완전하게 포함되어 있는지 어떤지를 나타낸다.

  • Crosses(g1,g2)

    g1 하지만 g2 (와)과 공간적으로 크로스 하는 경우,1 (을)를 돌려준다. g1 하지만 Polygon 또는 MultiPolygon 이든가, 혹은 g2 하지만 Point 또는 MultiPoint 인 경우,NULL (을)를 돌려준다. 그 외의 경우는 0 (을)를 돌려준다.

    공간적으로 크로스 한다 그렇다고 하는 표현은, 이하의 프롭퍼티를 가진다 2 개의 지정된 지오메트리의 관계를 나타낸다.

    • 2 개의 지오메트리는 교차한다.

    • 교차한 부분이 단일의 지오메트리가 되어, 그 지오메트리의 차원은 지정되었다 2 개의 지오메트리의 최대 차원보다1 개 작아진다.

    • 교차한 부분은, 지정되었다 2 개의 지오메트리와 동일하지 않다.

  • Disjoint(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 (와)과 g2 하지만 공간적으로 분리하고 있는(교차하지 않는다) 화도인지를 나타낸다.

  • Equals(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 (와)과 g2 하지만 공간적으로 동일한지 어떤지를 나타낸다.

  • Intersects(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 (와)과 g2 하지만 공간적으로 교차하는 어떨까를 나타낸다.

  • Overlaps(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 (와)과 g2 하지만 공간적으로 겹칠지를 나타낸다. 공간적으로 겹친다 그렇다고 하는 용어가 사용되는 것은,2 개의 지오메트리의 교차 부분이 단일의 지오메트리가 되어, 그 지오메트리는 지정되었다 2 개의 지오메트리와 차원이 일치하지만, 어느 쪽의 지오메트리와도 동일하지 않은 경우이다.

  • Touches(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 (와)과 g2 하지만 공간적으로 접촉하는 어떨까를 나타낸다.2 개의 지오메트리 공간적으로 접촉 하는 것은, 지오메트리 내부는 교차하지 않지만, 한편의 지오메트리의 경계가 한편의 지오메트리의 경계 또는 내부와 교차하는 경우이다.

  • Within(g1,g2)

    1 또는 0 (을)를 돌려주는 것으로,g1 하지만 g2 에 공간적으로 포함되어 있는지 어떤지를 나타낸다.

  • Distance(g1,g2)

    2 개의 지오메트리에 있어서의 임의의 2 Point 의 최단 거리를 배정도의 수치로서 돌려준다.

  • Related(g1,g2,pattern_matrix)

    1 또는 0 (을)를 돌려주는 것으로,pattern_matrix 에 의해서 지정된 공간 관계가 g1 (와)과 g2 의 사이에 존재할지를 나타낸다. 인수가 NULL 인 경우는 －1 (을)를 돌려준다. 패턴 행렬은 문자열이다.패턴 행렬에 대해서는, 이 함수가 실장된 시점에서 여기에 기재한다.


10.6. 공간 분석의 최적화

벌써 알려져 있는 것입니다만, 비공간 데이타베이스로의 검색 조작은 인덱스를 사용해 최적화할 수 있습니다.이것은, 공간 데이타베이스에 대해서도 들어맞읍니다. 다양한 다차원 인덱스 작성 방법이 고안 되고 있어 그것들을 활용하면 공간 검색을 최적화할 수 있습니다.대표적인 예를 이하에 나타냅니다.

  • 지정된 포인트가 포함되어 있는 오브젝트를 모두 검색하는 포인트 쿼리.

  • 지정된 영역이 포함되어 있는 오브젝트를 모두 검색하는 영역 쿼리.

MySQL 그럼, 2차 분할 알고리즘을 이용했다 R-Tree (을)를 사용해 공간 컬럼에 인덱스를 붙입니다.공간 인덱스는, 지오메트리의 MBR (을)를 사용해 작성됩니다. 많은 지오메트리에 대해서는,MBR (은)는 지오메트리를 둘러싸는 최소 구형입니다.수평 또는 수직인 LineString 에 대해서는,MBR 하 LineString 에 축퇴 한 구형입니다. Point 에 대해서는,MBR 하 Point 에 축퇴 한 구형입니다.

10.6.1. 공간 인덱스의 작성

MySQL 그럼 공간 인덱스를 작성할 수 있습니다.작성시에 사용하는 구문은, 통상의 인덱스를 작성하기 위한 구문을 닮아 있습니다만,SPATIAL 키워드로 확장되고 있습니다. 현재 인덱스 붙여 되고 있는 공간 컬럼은,NOT NULL (이)라고 선언되지 않으면 안됩니다.공간 인덱스를 작성하는 방법을 이하의 예에 나타냅니다.

  • CREATE TABLE (을)를 사용하는 경우.

    mysql> CREATE TABLE geom (g GEOMETRY NOT NULL, SPATIAL INDEX(g));

  • ALTER TABLE (을)를 사용하는 경우.

    mysql> ALTER TABLE geom ADD SPATIAL INDEX(g);

  • CREATE INDEX (을)를 사용하는 경우.

    mysql> CREATE SPATIAL INDEX sp_index ON geom (g);

공간 인덱스를 파기하려면 ,ALTER TABLE 또는 DROP INDEX (을)를 사용합니다.

  • ALTER TABLE (을)를 사용하는 경우.

    mysql> ALTER TABLE geom DROP INDEX g;

  • DROP INDEX (을)를 사용하는 경우.

    mysql> DROP INDEX sp_index ON geom;

례: 테이블 geom 에 32,000 개를 넘는 지오메트리 격납되고 있어 이것들이 GEOMETRY 형태의 g 그리고 보존되고 있다고 합니다. 이 테이블에는 AUTO_INCREMENT 컬럼 fid 도 있어, 이 컬럼에 오브젝트 ID 값이 보존됩니다.

mysql> SHOW FIELDS FROM geom;
+-------+----------+------+-----+---------+----------------+
| Field | Type     | Null | Key | Default | Extra          |
+-------+----------+------+-----+---------+----------------+
| fid   | int(11)  |      | PRI | NULL    | auto_increment |
| g     | geometry |      |     |         |                |
+-------+----------+------+-----+---------+----------------+
2 rows in set (0.00 sec)

mysql> SELECT COUNT(*) FROM geom;
+----------+
| count(*) |
+----------+
|    32376 |
+----------+
1 row in set (0.00 sec)

컬럼 g 그리고 공간 인덱스를 추가하려면 , 이하의 스테이트먼트를 사용합니다.

mysql> ALTER TABLE geom ADD SPATIAL INDEX(g);
Query OK, 32376 rows affected (4.05 sec)
Records: 32376  Duplicates: 0  Warnings: 0

10.6.2. 공간 인덱스의 사용

MBRContains() (이)나 MBRWithin() 등의 함수를 WHERE 구로 사용하는 쿼리의 검색으로 공간 인덱스를 사용할 수 있을지가, Optimizer에 의해서 확인됩니다. 예를 들어, 지정된 구형에 포함되어 있는 오브젝트를 모두 검색할 필요가 있다고 합니다.

mysql> SELECT fid,AsText(g) FROM geom WHERE
mysql> MBRContains(GeomFromText('Polygon((30000 15000,31000 15000,31000 16000,30000 16000,30000 15000))'),g);
+-----+-----------------------------------------------------------------------------+
| fid | AsText(g)                                                                   |
+-----+-----------------------------------------------------------------------------+
|  21 | LINESTRING(30350.4 15828.8,30350.6 15845,30333.8 15845,30333.8 15828.8)     |
|  22 | LINESTRING(30350.6 15871.4,30350.6 15887.8,30334 15887.8,30334 15871.4)     |
|  23 | LINESTRING(30350.6 15914.2,30350.6 15930.4,30334 15930.4,30334 15914.2)     |
|  24 | LINESTRING(30290.2 15823,30290.2 15839.4,30273.4 15839.4,30273.4 15823)     |
|  25 | LINESTRING(30291.4 15866.2,30291.6 15882.4,30274.8 15882.4,30274.8 15866.2) |
|  26 | LINESTRING(30291.6 15918.2,30291.6 15934.4,30275 15934.4,30275 15918.2)     |
| 249 | LINESTRING(30337.8 15938.6,30337.8 15946.8,30320.4 15946.8,30320.4 15938.4) |
|   1 | LINESTRING(30250.4 15129.2,30248.8 15138.4,30238.2 15136.4,30240 15127.2)   |
|   2 | LINESTRING(30220.2 15122.8,30217.2 15137.8,30207.6 15136,30210.4 15121)     |
|   3 | LINESTRING(30179 15114.4,30176.6 15129.4,30167 15128,30169 15113)           |
|   4 | LINESTRING(30155.2 15121.4,30140.4 15118.6,30142 15109,30157 15111.6)       |
|   5 | LINESTRING(30192.4 15085,30177.6 15082.2,30179.2 15072.4,30194.2 15075.2)   |
|   6 | LINESTRING(30244 15087,30229 15086.2,30229.4 15076.4,30244.6 15077)         |
|   7 | LINESTRING(30200.6 15059.4,30185.6 15058.6,30186 15048.8,30201.2 15049.4)   |
|  10 | LINESTRING(30179.6 15017.8,30181 15002.8,30190.8 15003.6,30189.6 15019)     |
|  11 | LINESTRING(30154.2 15000.4,30168.6 15004.8,30166 15014.2,30151.2 15009.8)   |
|  13 | LINESTRING(30105 15065.8,30108.4 15050.8,30118 15053,30114.6 15067.8)       |
| 154 | LINESTRING(30276.2 15143.8,30261.4 15141,30263 15131.4,30278 15134)         |
| 155 | LINESTRING(30269.8 15084,30269.4 15093.4,30258.6 15093,30259 15083.4)       |
| 157 | LINESTRING(30128.2 15011,30113.2 15010.2,30113.6 15000.4,30128.8 15001)     |
+-----+-----------------------------------------------------------------------------+
20 rows in set (0.00 sec)

이 쿼리가 어떻게 실행될까를,EXPLAIN (을)를 사용해 확인합니다.

mysql> EXPLAIN SELECT fid,AsText(g) FROM geom WHERE
mysql> MBRContains(GeomFromText('Polygon((30000 15000,31000 15000,31000 16000,30000 16000,30000 15000))'),g);
+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+
| id | select_type | table | type  | possible_keys | key  | key_len | ref  | rows | Extra       |
+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+
|  1 | SIMPLE      | geom  | range | g             | g    |      32 | NULL |   50 | Using where |
+----+-------------+-------+-------+---------------+------+---------+------+------+-------------+
1 row in set (0.00 sec)

공간 인덱스가 없으면 어떻게 되는지를 확인합니다.

mysql> EXPLAIN SELECT fid,AsText(g) FROM g IGNORE INDEX (g) WHERE
mysql> MBRContains(GeomFromText('Polygon((30000 15000,31000 15000,31000 16000,30000 16000,30000 15000))'),g);
+----+-------------+-------+------+---------------+------+---------+------+-------+-------------+
| id | select_type | table | type | possible_keys | key  | key_len | ref  | rows  | Extra       |
+----+-------------+-------+------+---------------+------+---------+------+-------+-------------+
|  1 | SIMPLE      | geom  | ALL  | NULL          | NULL |    NULL | NULL | 32376 | Using where |
+----+-------------+-------+------+---------------+------+---------+------+-------+-------------+
1 row in set (0.00 sec)

상기의 쿼리를 실행해, 사용 가능한 공간 키를 무시합니다.

mysql> SELECT fid,AsText(g) FROM geom IGNORE INDEX (g) WHERE
mysql> MBRContains(GeomFromText('Polygon((30000 15000,31000 15000,31000 16000,30000 16000,30000 15000))'),g);
+-----+-----------------------------------------------------------------------------+
| fid | AsText(g)                                                                   |
+-----+-----------------------------------------------------------------------------+
|   1 | LINESTRING(30250.4 15129.2,30248.8 15138.4,30238.2 15136.4,30240 15127.2)   |
|   2 | LINESTRING(30220.2 15122.8,30217.2 15137.8,30207.6 15136,30210.4 15121)     |
|   3 | LINESTRING(30179 15114.4,30176.6 15129.4,30167 15128,30169 15113)           |
|   4 | LINESTRING(30155.2 15121.4,30140.4 15118.6,30142 15109,30157 15111.6)       |
|   5 | LINESTRING(30192.4 15085,30177.6 15082.2,30179.2 15072.4,30194.2 15075.2)   |
|   6 | LINESTRING(30244 15087,30229 15086.2,30229.4 15076.4,30244.6 15077)         |
|   7 | LINESTRING(30200.6 15059.4,30185.6 15058.6,30186 15048.8,30201.2 15049.4)   |
|  10 | LINESTRING(30179.6 15017.8,30181 15002.8,30190.8 15003.6,30189.6 15019)     |
|  11 | LINESTRING(30154.2 15000.4,30168.6 15004.8,30166 15014.2,30151.2 15009.8)   |
|  13 | LINESTRING(30105 15065.8,30108.4 15050.8,30118 15053,30114.6 15067.8)       |
|  21 | LINESTRING(30350.4 15828.8,30350.6 15845,30333.8 15845,30333.8 15828.8)     |
|  22 | LINESTRING(30350.6 15871.4,30350.6 15887.8,30334 15887.8,30334 15871.4)     |
|  23 | LINESTRING(30350.6 15914.2,30350.6 15930.4,30334 15930.4,30334 15914.2)     |
|  24 | LINESTRING(30290.2 15823,30290.2 15839.4,30273.4 15839.4,30273.4 15823)     |
|  25 | LINESTRING(30291.4 15866.2,30291.6 15882.4,30274.8 15882.4,30274.8 15866.2) |
|  26 | LINESTRING(30291.6 15918.2,30291.6 15934.4,30275 15934.4,30275 15918.2)     |
| 154 | LINESTRING(30276.2 15143.8,30261.4 15141,30263 15131.4,30278 15134)         |
| 155 | LINESTRING(30269.8 15084,30269.4 15093.4,30258.6 15093,30259 15083.4)       |
| 157 | LINESTRING(30128.2 15011,30113.2 15010.2,30113.6 15000.4,30128.8 15001)     |
| 249 | LINESTRING(30337.8 15938.6,30337.8 15946.8,30320.4 15946.8,30320.4 15938.4) |
+-----+-----------------------------------------------------------------------------+
20 rows in set (0.46 sec)

공간 인덱스를 사용하지 않으면 이 쿼리의 실행 시간은 0.00 초부터 0.46 초에 증대합니다.

장래의 릴리스에서는, 공간 인덱스를 사용해 다른 함수도 최적화되게 됩니다. See 항10.5.4. 「Geometry Object간의 공간적 관계를 테스트하기 위한 함수」 .


10.7. MySQL 의 적합성과 호환성

10.7.1. 아직 실장되어 있지 않은 GIS 기능

  • 추가의 메타데이타뷰

    OpenGIS 사양에는, 추가의 메타데이타뷰가 몇개인가 제안되고 있다. 예를 들어, 시스템뷰 GEOMETRY_COLUMNS 에는 지오메트리카람의 설명이 있어, 1 행이 데이타베이스내의 각 지오메트리카람에 대응하고 있다.

  • 공간 정보 컬럼을 추가/파기하기 위한 함수

    OpenGIS 에서는, 특별한 함수 AddGeometryColumn() 과 DropGeometryColumn() (을)를 사용해 컬럼을 추가 또는 파기할 수 있게 되어 있다.MySQL 그럼, 컬럼을 추가 또는 파기하기 위해서 ALTER TABLE,CREATE INDEX,DROP INDEX 스테이트먼트를 대용한다.

  • 공간 참조계와 그 ID(SRID) 관련

    • Length(),Area() 등의 함수는 평면 좌표계에 대응하고 있다.

    • 모든 오브젝트는 현재, 같은 평면 좌표계에 있는 것이라고 생각되고 있다.

  • LineString 및 MultiLineString 상의 OpenGIS 함수 Length() 는 현재, MySQL 에서는 GLength() (으)로서 불려 가지 않으면 안 된다.

    이 함수와 기존의 SQL 함수 Length()(캐릭터 라인치를 계산)가 경합 하는 것이 문제이며, 이 함수가 문자 문맥과 공간 문맥의 어디에서 불려 갔는지 구별할 수 없는 것이 있다.어떠한 방법으로 이 문제를 해결하는지, 다른 함수명을 결정할 필요가 있다.


제11장 MySQL API

목차

11.1. MySQL C API
11.1.1. C API 데이터형
11.1.2. C API 함수의 개요
11.1.3. C API 함수의 설명
11.1.4. C API 의 Prepared Statements
11.1.5. C API 의 Prepared Statement의 데이터형
11.1.6. C API 의 Prepared Statement 함수의 개요
11.1.7. C API 의 Prepared Statement 함수의 설명
11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급
11.1.9. C API 에 있어서의 일자치 및 시각치의 취급
11.1.10. C API thread 함수의 설명
11.1.11. C API 편입 서버 함수의 설명
11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제
11.1.13. 클라이언트 프로그램의 빌드
11.1.14. thread 클라이언트의 작성 방법
11.1.15. 편입 MySQL 서버 라이브러리 libmysqld
11.2. MySQL 의 ODBC 서포트
11.2.1. MyODBC 의 인스톨 방법
11.2.2. ODBC 어드미니스트레이터의 필드의 설정 방법법
11.2.3. MyODBC 의 접속 파라미터
11.2.4. MyODBC 에 관한 문제를 보고하는 방법
11.2.5. MyODBC 와 제휴해 동작하는 것이 알려져 있는 프로그램
11.2.6. ODBC 로 AUTO_INCREMENT 속성을 가지는 컬럼의 값을 취득하는 방법
11.2.7. MyODBC 에 관한 문제의 보고
11.3. MySQL 의 Java 접속(JDBC)
11.4. MySQL PHP API
11.4.1. MySQL 및 PHP 가 좋게 있는 문제
11.5. MySQL Perl API
11.5.1. DBI 와 DBD::mysql
11.5.2. DBI 인터페이스
11.5.3. DBI/DBD 에 관한 그 외의 정보
11.6. MySQL C++ API
11.6.1. Borland C++
11.7. MySQL Python API
11.8. MySQL Tcl API
11.9. MySQL Eiffel Wrapper

이 장에서는, MySQL 로 사용할 수 있는 API 의 입수 장소 및 사용 방법에 대해 설명합니다.가장 풍부한 종류가 준비되어 있는 것이 C API 입니다.이것은 MySQL 팀이 개발하고 있습니다.발설어전용의 API (은)는, 이 C API 를 베이스로 해 개발되고 있습니다.

11.1. MySQL C API

C API 코드는, MySQL (와)과 함께 배포되고 있습니다.C API 코드는 mysqlclient 라이브러리에 격납되어 C 프로그램은 이 코드를 사용해 데이타베이스에 액세스 할 수 있습니다.

MySQL 의 소스 디스트리뷰션에 포함되는 클라이언트의 상당수는 C 로 기술되고 있습니다.C API 의 사용 방법을 알 수 있는 것 같은 코드예를 찾고 있는 경우는, 이러한 클라이언트를 참고로 해 주세요.클라이언트는, MySQL 소스 디스트리뷰션의 clients 디렉토리에 격납되고 있습니다.

다른 클라이언트 API(Connector/J 를 제외하는 모든 API)의 상당수는,mysqlclient 라이브러리를 사용해 MySQL 서버와 통신합니다.이 라이브러리를 사용하면(자), 예를 들어 환경 변수를 참조할 수 있으므로, 다른 클라이언트 프로그램과 대부분의 환경 변수를 공용할 수 있게 됩니다.공용할 수 있는 환경 변수의 일람에 대해서는,항 4.9. 「MySQL 클라이언트 사이드의 스크립트와 유틸리티」 (을)를 참조해 주세요.

클라이언트를 사용할 수 있는 통신 버퍼 사이즈에는 상한이 있습니다.내부적으로 할당할 수 있고 있는 버퍼 사이즈(16 킬로바이트)는, 최대 16 메가바이트까지 자동적으로 증가합니다.버퍼 사이즈가 증가하는 것은 버퍼의 요구량이 증가했을 경우 뿐이어서, 디폴트의 최대치를 늘렸다고 해 사용 자원이 증가하는 것은 아닙니다.이 사이즈 체크에서는, 잘못한 쿼리나 통신 패킷을 주로 체크합니다.

통신 버퍼 사이즈는, SQL 스테이트먼트 1 개(클라이언트로부터 서버에의 트래픽) 및 결과 데이터 1 행(서버로부터 클라이언트에의 트래픽)을 격납 가능한 한의 크기가 필요합니다.각 thread의 통신 버퍼는, 쿼리나 레코드를 처리할 수 있도록(듯이), 그 최대치까지 동적으로 확대됩니다.예를 들어, 최대 16 메가바이트의 데이터를 격납한다 BLOB 값을 처리하는 경우, 통신 버퍼 사이즈의 최대치는(서버와 클라이언트의 양쪽 모두로) 적어도 16 메가바이트일 필요가 있습니다.클라이언트의 디폴트의 최대치는 16 메가바이트입니다만, 서버의 디폴트의 최대치는 1 메가바이트입니다.서버의 디폴트의 최대치를 늘리려면 , 서버의 기동시에 max_allowed_packet 의 값을 변경합니다. See 항 5.5.2. 「서버 파라미터의 튜닝」.

MySQL 서버는, 쿼리가 끝날 때마다 통신 버퍼 사이즈를 net_buffer_length (으)로 줄입니다.클라이언트측에서는, 접속이 절단 되어 메모리가 해방될 때까지, 그 접속에 할당할 수 있었던 버퍼 사이즈가 줄어들 것은 없습니다.

thread를 사용하는 프로그래밍에 대해서는,항 11.1.14. 「thread 클라이언트의 작성 방법」 (을)를 참조해 주세요.동일 프로그램내에 "서버" 와 "클라이언트" 하지만 존재한다( 및 외부의 MySQL 서버와 통신하지 않는다) 스탠드얼론 어플리케이션의 작성에 대해서는,항 11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld」 (을)를 참조해 주세요.

11.1.1. C API 데이터형

  • MYSQL

    이 구조체는, 1 개의 데이타베이스 접속에의 핸들을 나타낸다.대부분의 MySQL 함수로 사용된다.

  • MYSQL_RES

    이 구조체는, 레코드를 돌려주는 쿼리(SELECT,SHOW,EXPLAIN,DESCRIBE)의 결과를 나타낸다.이 섹션에서는, 쿼리로부터 돌려주어진 정보를 결과 세트 라고 부른다.

  • MYSQL_ROW

    1 행의 데이터의 타입 세이프인 표현.현재는, 아르바이트 캐릭터 라인의 배열로서 실장되고 있다(필드에는 바이너리 데이터가 격납되는 경우가 있어, 그러한 데이터에서는 내부적으로 누르바이트가 사용될 가능성이 있으므로, 아르바이트 캐릭터 라인을 눌 종단 캐릭터 라인으로서 취급할 수 없다).레코드를 취득하려면 ,mysql_fetch_row() (을)를 호출한다.

  • MYSQL_FIELD

    이 구조체에는, 필드의 이름, 형태, 사이즈 등, 필드에 관한 정보가 격납된다.멤버의 상세한 것에 대하여는, 이하로 설명한다. 각 필드에 대해서 mysql_fetch_field() (을)를 반복해 호출하는 것에 의해, 대응한다 MYSQL_FIELD 구조체를 취득할 수 있다.필드치는 이 구조체의 일부에서는 없고,MYSQL_ROW 구조체에 포함된다.

  • MYSQL_FIELD_OFFSET

    MySQL 필드 일람에 대한 오프셋(offset)의 안전한 형태 표현(mysql_field_seek() 하지만 사용).오프셋(offset)는 레코드 내부에서의 필드 번호이며, 0 (으)로부터 시작된다.

  • my_ulonglong

    레코드의 수를 나타내기 위한 형태이며,mysql_affected_rows(),mysql_num_rows(), 및 mysql_insert_id() 그리고 사용된다.0 으로부터 1.84e19 까지의 범위의 값을 나타낸다.

    일부의 시스템에서는,my_ulonglong 형태의 값을 출력하려고 해도, 정상적으로 출력되지 않는다.이 형태의 값을 출력하려면 ,unsigned long 로 변환해,%lu 포맷을 사용한다.이하에 예를 나타낸다.

    printf ("Number of rows: %lu\n", (unsigned long) mysql_num_rows(result));

MYSQL_FIELD 구조체의 멤버를 이하에 나타냅니다.

  • char * name

    필드의 이름.눌 종단 캐릭터 라인.

  • char * table

    이 필드가 계산 결과 데이터의 필드가 아닌 경우, 이 필드가 속하는 테이블의 이름.계산 결과 데이터의 필드의 경우,table 의 값은 공문자열이 된다.

  • char * def

    이 필드의 디폴트치.눌 종단 캐릭터 라인.mysql_list_fields() (을)를 사용할 때만 설정된다.

  • enum enum_field_types type

    필드의 형태. type 의 값은 다음의 어느 쪽인가에 된다.

    형태의 치 | 형의 설명
    FIELD_TYPE_TINY | TINYINT 필드
    FIELD_TYPE_SHORT | SMALLINT 필드
    FIELD_TYPE_LONG | INTEGER 필드
    FIELD_TYPE_INT24 | MEDIUMINT 필드
    FIELD_TYPE_LONGLONG | BIGINT 필드
    FIELD_TYPE_DECIMAL | DECIMAL 또는 NUMERIC 필드
    FIELD_TYPE_FLOAT | FLOAT 필드
    FIELD_TYPE_DOUBLE | DOUBLE 또는 REAL 필드
    FIELD_TYPE_TIMESTAMP | TIMESTAMP 필드
    FIELD_TYPE_DATE | DATE 필드
    FIELD_TYPE_TIME | TIME 필드
    FIELD_TYPE_DATETIME | DATETIME 필드
    FIELD_TYPE_YEAR | YEAR 필드
    FIELD_TYPE_STRING | CHAR 필드
    FIELD_TYPE_VAR_STRING | VARCHAR 필드
    FIELD_TYPE_BLOB | BLOB 또는 TEXT 필드(max_length (을)를 사용해 최대장을 결정)
    FIELD_TYPE_SET | SET 필드
    FIELD_TYPE_ENUM | ENUM 필드
    FIELD_TYPE_NULL | NULL 형 필드
    FIELD_TYPE_CHAR | 폐지(대신에 FIELD_TYPE_TINY (을)를 사용하는 것)

    IS_NUM() 매크로를 사용하면(자), 필드가 수치형인지 어떤지를 조사할 수가 있다.type 의 값을 IS_NUM() 에 건네주면(자), 필드가 수치형의 경우는 TRUE (이)라고 평가된다.

    if (IS_NUM(field->type))
    printf("Field is numeric\n");

  • unsigned int length

    필드의 폭.테이블 정의로 지정된 값에 따른다.

  • unsigned int max_length

    결과 세트의 필드의 최대폭(결과 세트에 실제로 존재하는 레코드의 필드치의 최대장).mysql_store_result() 또는 mysql_list_fields() (을)를 사용했을 경우, 이 값은 필드의 최대장을 나타낸다.mysql_use_result() (을)를 사용했을 경우, 이 값은 0 이 된다.

  • unsigned int flags

    필드의 다양한 상태를 나타내는 비트 플래그.flags 값은, 0 또는 이하의 비트가 1 개이상 설정된 값이 된다.

    플래그의 값 | 플래그의 설명
    NOT_NULL_FLAG | NULL 를 설정할 수 없는 필드
    PRI_KEY_FLAG | 주키의 일부를 구성하는 필드
    UNIQUE_KEY_FLAG | 일의인 키의 일부를 구성하는 필드
    MULTIPLE_KEY_FLAG | 일의가 아닌 키의 일부를 구성하는 필드
    UNSIGNED_FLAG | UNSIGNED 속성을 가지는 필드
    ZEROFILL_FLAG | ZEROFILL 속성을 가지는 필드
    BINARY_FLAG | BINARY 속성을 가지는 필드
    AUTO_INCREMENT_FLAG | AUTO_INCREMENT 속성을 가지는 필드
    ENUM_FLAG | ENUM 형의 필드(폐지)
    SET_FLAG | SET 형의 필드(폐지)
    BLOB_FLAG | BLOB 형 또는 TEXT 형태의 필드(폐지)
    TIMESTAMP_FLAG | TIMESTAMP 형의 필드(폐지)

    BLOB_FLAG,ENUM_FLAG,SET_FLAG, 및 TIMESTAMP_FLAG 의 각 플래그는, 필드의 속성은 아니고 형태를 나타내고 있으므로, 폐지되고 있다.대신에,field->type (을)를 FIELD_TYPE_BLOB,FIELD_TYPE_ENUM,FIELD_TYPE_SET, 또는 FIELD_TYPE_TIMESTAMP (와)과 비교하는 (분)편이 바람직하다.

    다음에,flags 값의 전형적인 사용예를 나타낸다.

    if (field->flags & NOT_NULL_FLAG)
    printf("Field can't be null\n");

    이하의 매크로를 사용하면(자),flags 값을 조사해 불리언 값으로 결과를 얻을 수 있다.

    플래그 상태 | 설명
    IS_NOT_NULL(flags) | 이 필드가 NOT NULL (으)로서 정의되고 있는 경우는 True.
    IS_PRI_KEY(flags) | 이 필드가 주키의 경우는 True.
    IS_BLOB(flags) | 이 필드가 BLOB 또는 TEXT 의 경우는 True (폐지.대신에 field->type 에 의한 비교를 추천).

  • unsigned int decimals

    수치 필드의 소수부 자리수.

11.1.2. C API 함수의 개요

여기에서는, C API 그리고 제공되고 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이후의 섹션으로 설명합니다. See 항 11.1.3. 「C API 함수의 설명」.

함수 | 설명
mysql_affected_rows() | 마지막에 실행되었다 UPDATE,DELETE, 또는 INSERT 의 몇개의 쿼리에 의해 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_change_user() | 오픈된 접속의 유저 및 데이타베이스를 변경한다.
mysql_character_set_name() | 접속의 디폴트의 캐릭터 세트의 이름을 돌려준다.
mysql_close() | 서버 접속을 절단 한다.
mysql_connect() | MySQL 서버에 접속한다.이 함수는 폐지되고 있으므로, 대신에 mysql_real_connect() (을)를 사용하는 것.
mysql_create_db() | 데이타베이스를 작성한다.이 함수는 폐지되고 있으므로, 대신에 SQL 커멘드 CREATE DATABASE (을)를 사용하는 것.
mysql_data_seek() | 쿼리 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_debug() | 지정된 캐릭터 라인으로 DBUG_PUSH (을)를 실행한다.
mysql_drop_db() | 데이타베이스를 파기한다.이 함수는 폐지되고 있으므로, 대신에 SQL 커멘드 DROP DATABASE (을)를 사용하는 것.
mysql_dump_debug_info() | 디버그 정보를 로그에 기입하도록(듯이) 서버에 지시한다.
mysql_eof() | 결과 세트의 마지막 레코드가 읽혔는지 어떠했는지를 판정한다. 이 함수는 폐지되고 있어 대신에 mysql_errno() 또는 mysql_error() 를 사용할 수 있다.
mysql_errno() | 마지막에 불려 간 MySQL 함수의 에러 번호를 돌려준다.
mysql_error() | 마지막에 불려 간 MySQL 함수의 에러를 돌려준다.
mysql_escape_string() | 캐릭터 라인에 포함되는 특수 문자를 이스케이프 해, SQL 스테이트먼트로 사용할 수 있도록(듯이) 한다.
mysql_fetch_field() | 테이블의 다음의 필드의 형태를 돌려준다.
mysql_fetch_field_direct() | 필드 번호로 지정된 테이블 필드의 형태를 돌려준다.
mysql_fetch_fields() | 모든 필드 구조체의 배열을 돌려준다.
mysql_fetch_lengths() | 현재의 레코드의 모든 컬럼에 대해 그 길이를 돌려준다.
mysql_fetch_row() | 결과 세트의 다음의 레코드를 취득한다.
mysql_field_seek() | 지정된 컬럼에 컬럼 커서를 이동한다.
mysql_field_count() | 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려준다.
mysql_field_tell() | 마지막에 실행된 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려준다.
mysql_free_result() | 결과 세트로 사용한 메모리를 해방한다.
mysql_get_client_info() | 클라이언트의 버젼 정보를 캐릭터 라인으로서 돌려준다.
mysql_get_client_version() | 클라이언트의 버젼 정보를 정수로서 돌려준다.
mysql_get_host_info() | 접속을 기술하는 캐릭터 라인을 돌려준다.
mysql_get_server_version() | 서버의 버젼 번호를 정수로서 돌려준다(4.1 의 신기능).
mysql_get_proto_info() | 접속에 사용하고 있는 프로토콜의 버젼을 돌려준다.
mysql_get_server_info() | 서버의 버젼 번호를 돌려준다.
mysql_info() | 마지막에 실행된 쿼리에 관한 정보를 돌려준다.
mysql_init() | MYSQL 구조체를 취득 또는 초기화한다.
mysql_insert_id() | 전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려준다.
mysql_kill() | 지정된 thread를 강제 종료한다.
mysql_list_dbs() | 단순한 정규 표현에 일치하는 데이타베이스명을 돌려준다.
mysql_list_fields() | 단순한 정규 표현에 일치하는 필드명을 돌려준다.
mysql_list_processes() | 현재의 서버 thread의 일람을 돌려준다.
mysql_list_tables() | 단순한 정규 표현에 일치하는 테이블명을 돌려준다.
mysql_num_fields() | 결과 세트의 컬럼수를 돌려준다.
mysql_num_rows() | 결과 세트의 레코드수를 돌려준다.
mysql_options() | mysql_connect() 의 접속 옵션을 설정한다.
mysql_ping() | 서버에의 접속이 정상적인지 어떤지를 확인해, 필요하면 재접속한다.
mysql_query() | 눌 종단 캐릭터 라인으로서 지정되어 있는 SQL 쿼리를 실행한다.
mysql_real_connect() | MySQL 서버에 접속한다.
mysql_real_escape_string() | 접속의 현재의 캐릭터 세트를 고려해, 캐릭터 라인에 포함되는 특수 문자를 이스케이프 해, SQL 스테이트먼트로 사용할 수 있도록(듯이) 한다.
mysql_real_query() | 아르바이트 캐릭터 라인으로서 지정되어 있는 SQL 쿼리를 실행한다.
mysql_reload() | 권한 테이블의 재독 보고 포함을 서버에 지시한다.
mysql_row_seek() | mysql_row_tell() (으)로부터 돌려주어진 값을 오프셋(offset)로서 결과 세트내의 레코드에 시크 한다.
mysql_row_tell() | 레코드 커서의 위치를 돌려준다.
mysql_select_db() | 데이타베이스를 선택한다.
mysql_set_server_option() | 접속의 옵션(multi-statements 등)을 설정한다.
mysql_sqlstate() | 마지막에 발생한 에러의 SQLSTATE 에러 코드를 돌려준다.
mysql_shutdown() | 데이터 베이스 서버를 슛다운 한다.
mysql_stat() | 서버 스테이터스를 캐릭터 라인으로서 돌려준다.
mysql_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_thread_id() | 현재의 thread ID 를 돌려준다.
mysql_thread_safe() | 클라이언트가 thread 세이프로서 컴파일 되고 있는 경우는 1 을 돌려준다.
mysql_use_result() | 레코드 단위의 결과 세트의 취득을 개시한다.
mysql_warning_count() | 전회 실행한 SQL 스테이트먼트의 경고수를 돌려준다.
mysql_commit() | 트랜잭션(transaction)를 위탁한다(4.1 의 신기능).
mysql_rollback() | 트랜잭션(transaction)를 롤백(rollback) 한다(4.1 의 신기능).
mysql_autocommit() | 자동 위탁 모드의 온/오프를 바꾼다(4.1 의 신기능).
mysql_more_results() | 아직 취득하고 있지 않는 결과 세트가 존재하는지 어떤지를 조사한다(4.1 의 신기능).
mysql_next_result() | 멀티 쿼리를 실행하고 있는 경우, 다음의 결과 세트를 취득해, 돌려준다(4.1 의 신기능).

서버에 접속하려면 ,mysql_init() (을)를 호출해 접속 핸들러를 초기화해, 다음에 그 핸들러( 및 호스트명, 유저명, 패스워드등의 그 외의 정보)를 파라미터로서 mysql_real_connect() (을)를 호출합니다.접속이 확립했을 때,mysql_real_connect() 에 의해 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.접속이 필요없게 되면(자),mysql_close() (을)를 호출해 접속을 절단 합니다.

접속이 액티브한 경우, 클라이언트는 mysql_query() 또는 mysql_real_query() (을)를 사용해 서버에 SQL 쿼리를 송신할 수 있습니다.이 2 개의 차이는,mysql_query() (은)는 쿼리를 눌 종단 캐릭터 라인으로서mysql_real_query() (은)는 쿼리를 아르바이트 캐릭터 라인으로서 각각 받습니다.캐릭터 라인에 바이너리 데이터가 포함되는(누르바이트가 포함될 가능성이 있다) 경우는,mysql_real_query() (을)를 사용할 필요가 있습니다.

비 SELECT 쿼리(예를 들어,INSERT,UPDATE,DELETE)를 실행했을 경우, 변경된(영향을 받은) 레코드의 수를 알려면 ,mysql_affected_rows() (을)를 호출합니다.

SELECT 쿼리를 실행했을 경우, 선택된 레코드를 결과 세트로서 취득합니다(주의: SHOW,DESCRIBE, 및 EXPLAIN (와)과 같이, 레코드를 돌려준다고 하는 점으로 SELECT (을)를 닮아 있는 스테이트먼트가 있어, 이것들은 SELECT 스테이트먼트와 같게 취급할 필요가 있습니다).

클라이언트가 결과 세트를 처리하는 방법은 2 개 있습니다.1 개는,mysql_store_result() (을)를 호출해 결과 세트 전체를 일괄해 취득하는 방법입니다.이 함수는, 쿼리로부터 돌려주어진 모든 레코드를 서버로부터 취득해, 클라이언트에 보존합니다.이제(벌써) 1 개(살)은,mysql_use_result() (을)를 호출해, 클라이언트가 레코드 단위로 결과 세트의 취득을 개시하는 방법입니다.이 함수는 결과 세트를 취득하는 처리의 초기화는 실시합니다만, 실제로는 서버로부터 레코드를 받고 있지 않습니다.

어느 쪽의 경우도, 레코드에 액세스 하려면 mysql_fetch_row() (을)를 호출합니다.mysql_store_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는, 벌써 서버로부터 취득되고 있는 레코드에 액세스 합니다.mysql_use_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는 실제로 서버로부터 레코드를 취득합니다.각 레코드의 데이터 사이즈는,mysql_fetch_lengths() (을)를 호출하는 것에 의해 알 수가 있습니다.

결과 세트가 필요없게 되면(자),mysql_free_result() (을)를 호출해, 사용하고 있던 메모리를 해방합니다.

2 개의 취득 메카니즘은, 상황에 따라 구분하여 사용합니다.클라이언트 프로그램은, 필요에 따라서 가장 적절한 방법을 선택할 필요가 있습니다.실제로는,mysql_store_result() (을)를 다용하는 경향이 있습니다.

mysql_store_result() 의 장점은, 모든 레코드가 클라이언트에 취득이 끝난 상태이므로, 레코드에 차례차례 액세스 가능할 뿐만 아니라,mysql_data_seek() 또는 mysql_row_seek() (을)를 사용해 결과 세트내에서의 경향 레코드의 위치를 변경하는 것에 의해, 결과 세트내를 전후로 이동할 수 있는 것입니다.결과 세트에 포함되는 레코드수를 알려면 ,mysql_num_rows() (을)를 호출합니다.한편, 결과 세트가 큰 경우의 mysql_store_result() 의 메모리 요건은 매우 어려운 경우가 있어, 메모리 부족이 발생할 가능성은 높아집니다.

mysql_use_result() 의 장점은, 한 번에 1 행의 레코드 밖에 보관 유지하지 않기 때문에, 클라이언트가 결과 세트로 사용하는 메모리가 적어도 되는 것입니다(또, 메모리 할당의 오버헤드가 적기 때문에 mysql_use_result() 의 실행 속도도 향상합니다).단점은, 서버를 구속하지 않게 각 레코드에 대한 처리를 단시간에 끝낼 필요가 있는 것, 결과 세트내의 레코드에 대한 랜덤 억세스 기능이 없는 것(차례차례 액세스만), 모든 레코드를 취득할 때까지 결과 세트에 포함되는 레코드수를 모르는 것입니다.게다가 찾고 있던 정보가 차례차례 액세스의 도중에 발견되었을 경우에서도, 끝까지 모든 레코드를 취득할 필요가 있습니다 .

클라이언트는 API (을)를 사용하는 것으로, 쿼리가 SELECT 화도인가를 몰라도, 쿼리에 대해서 적절히 응답하는(필요에 따라서 레코드를 취득한다) 일이 생깁니다.그러기 위해서는,mysql_query()(또는 mysql_real_query())를 호출할 때마다 mysql_store_result() (을)를 호출합니다.이 호출이 정상 종료했을 경우, 쿼리는 SELECT (이었)였던 것으로 되고, 레코드를 읽어들일 수가 있습니다.호출이 실패했을 경우,mysql_field_count() (을)를 호출해, 이 결과가 쿼리의 결과로서 예상된 것이었는지 아닌지를 판단합니다.mysql_field_count() 하지만 0 (을)를 돌려주었을 경우, 쿼리가 돌려준 데이터는 없고(INSERT,UPDATE,DELETE 등의 쿼리였던 일을 의미한다), 레코드를 돌려주는 쿼리는 아니었다고 판단됩니다.mysql_field_count() 하지만 0 이외의 값을 돌려주었을 경우, 레코드를 돌려주어야할 쿼리가 실행되었지만, 아무것도 돌려주지 않았다고 판단됩니다.이것은,SELECT 쿼리가 실패한 것을 의미합니다.여기에 나타낸 방법의 코딩예에 대해서는,mysql_field_count() 의 설명을 참조해 주세요.

mysql_store_result() 및 mysql_use_result() (은)는 어느쪽이나, 결과 세트를 구성하는 필드에 관한 정보(필드의 수, 이름, 형태등)를 취득합니다.레코드의 필드 정보에 차례차례 액세스 하려면 ,mysql_fetch_field() (을)를 반복해 호출하는지, 또는 레코드의 필드 번호를 지정해 mysql_fetch_field_direct() (을)를 호출합니다.현재의 필드 커서의 위치를 변경하려면 ,mysql_field_seek() (을)를 호출합니다.필드 커서의 위치를 변경하면(자), 그 후에 불려 갔다 mysql_fetch_field() 의 동작에 영향을 줍니다.mysql_fetch_fields() (을)를 호출하면(자), 모든 필드의 정보를 일괄해 취득할 수 있습니다.

에러를 검출해, 보고하는 경우,mysql_errno() 및 mysql_error() (을)를 사용해 에러 정보에 액세스 합니다.이 2 개의 함수는, 마지막에 불려 간, 성공 또는 실패의 가능성이 있는 함수의 에러 코드 또는 에러 메세지를 돌려줍니다.이 결과에 의해, 에러가 발생한 타이밍과 그 내용을 판단합니다.

11.1.3. C API 함수의 설명

여기의 설명 중(안)에서, 파라미터 또는 반환값에 NULL 하지만 사용되고 있는 경우, 이것은 C 언어에 있어서의 NULL 를 나타내고 있어 MySQL 에 있어서의 NULL 치가 아닙니다.

값을 돌려주는 함수는, 일반적으로 포인터 또는 정수를 돌려줍니다.특히 지정되어 있지 않은 한, 포인터를 돌려주는 함수가 비 NULL 값을 돌려주었을 경우는 정상 종료를,NULL 값을 돌려주었을 경우는 에러를 나타냅니다.같이 정수를 돌려주는 함수가 0 을 돌려주었을 경우는 정상 종료를, 0 이외의 값을 돌려주었을 경우는 에러를 나타냅니다.주의: ``0 이외'' 그렇다고 하는 것에, 그 이상의 의미는 없습니다.함수 설명에 특히 기술이 없는 한, 0 이외의 값에 대해서 비교 테스트는 필요 없습니다.

if (result)                   /* correct */
    ... error ...

if (result < 0)               /* incorrect */
    ... error ...

if (result == -1)             /* incorrect */
    ... error ...

함수가 돌려주는 에러에 대해서는, 함수 설명안의 「 에러 」서브 섹션을 참조해 주세요.발생한 에러를 조사하려면 ,mysql_errno() (을)를 호출합니다.mysql_error() (을)를 호출하면(자), 에러 내용의 캐릭터 라인 표현을 취득할 수 있습니다.

11.1.3.1. mysql_affected_rows()

my_ulonglong mysql_affected_rows(MYSQL *mysql)

설명

마지막에 불려 간 UPDATE 에 의해 변경된 레코드수, 마지막에 불려 갔다 DELETE 에 의해 삭제된 레코드수, 또는 마지막에 불려 갔다 INSERT 에 의해 삽입된 레코드수를 돌려줍니다.UPDATE,DELETE, 또는 INSERT 의 몇개의 스테이트먼트에 대해 mysql_query() (을)를 호출한 후에, 이 함수를 호출합니다.SELECT 스테이트먼트의 경우,mysql_affected_rows() (을)를 호출하면(자),mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타냅니다.-1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_store_result() 를 호출하기 전에 mysql_affected_rows() 하지만 불려 간 것을 나타냅니다.

에러

없습니다.

례

mysql_query(&mysql,"UPDATE products SET cost=cost*1.25 WHERE group=10");
printf("%ld products updated", (long) mysql_affected_rows(&mysql));

mysqld 에 접속할 때에 플래그 CLIENT_FOUND_ROWS 하지만 지정되어 있는 경우,mysql_affected_rows() (은)는 UPDATE 스테이트먼트의 WHERE 마디에 일치하는 레코드수를 돌려줍니다.

주의: REPLACE 커멘드로 기존의 레코드가 새로운 레코드로 옮겨놓을 수 있었을 경우는 mysql_affected_rows() 는 2 (을)를 돌려줍니다.이것은, 레코드가 1 행 삽입된 다음에 중복 한 레코드가 삭제되었기 때문입니다.

11.1.3.2. mysql_change_user()

my_bool mysql_change_user(MYSQL *mysql, const char *user, const char *password, const char *db)

설명

유저를 변경해,db 그리고 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

이 함수는, MySQL 3.23.3 으로 도입되었습니다.

mysql_change_user() (은)는, 지정한 유저가 인증되지 않는 경우, 또는 그 유저가 데이타베이스를 사용하는 권한을 가지지 않는 경우에, 실패합니다.이 경우, 유저 및 데이타베이스는 변경되지 않습니다.

디폴트 데이타베이스를 사용하지 않는 경우,db 파라미터를 NULL (으)로 설정합니다.

MySQL 4.0.6 이후, 이 커멘드는, 새로운 접속이 확립했을 경우는 항상, 임의의 액티브한 트랜잭션(transaction)의 ROLLBACK 의 실행, 모든 텐포라리테이불의 클로우즈, 락 된 모든 테이블의 언로크, 및 상태의 리셋트를 실시합니다.이 처리는, 유저가 변경되지 않았던 경우도 반드시 행해집니다.

반환값

정상 종료했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

mysql_real_connect() 하지만 돌려주는 에러와 같다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • ER_UNKNOWN_COM_ERROR

    MySQL 서버로 이 커멘드가 실장되어 있지 않다(버젼이 낡다고 생각된다).

  • ER_ACCESS_DENIED_ERROR

    유저 또는 패스워드가 올바르지 않다.

  • ER_BAD_DB_ERROR

    데이타베이스가 존재하지 않는다.

  • ER_DBACCESS_DENIED_ERROR

    유저가 데이타베이스에의 액세스권을 가지고 있지 않다.

  • ER_WRONG_DB_NAME

    데이타베이스명이 너무 길다.

례

if (mysql_change_user(&mysql, "user", "password", "new_database"))
{
   fprintf(stderr, "Failed to change user.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.3. mysql_character_set_name()

const char *mysql_character_set_name(MYSQL *mysql)

설명

현재의 접속의 디폴트의 캐릭터 세트를 돌려줍니다.

반환값

디폴트의 캐릭터 세트.

에러

없습니다.

11.1.3.4. mysql_close()

void mysql_close(MYSQL *mysql)

설명

벌써 오픈되고 있는 접속을 클로우즈 합니다.mysql 그리고 나타나는 접속 핸들이 mysql_init() 또는 mysql_connect() 에 의해 자동적으로 할당할 수 있었던 핸들이었던 경우는,mysql_close() 그리고 할당이 해제됩니다.

반환값

없습니다.

에러

없습니다.

11.1.3.5. mysql_connect()

MYSQL *mysql_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd)

설명

이 함수는 폐지되고 있습니다.대신에 mysql_real_connect() (을)를 사용해 주세요.

mysql_connect() (은)는,host 상에서 실행하고 있는 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 의미는,mysql_real_connect() 에서의 대응하는 파라미터와 같습니다만, 접속 파라미터에 NULL (을)를 건네줄 수가 있다고 하는 차이가 있습니다.이 경우, C API (은)는 접속 구조체에 자동적으로 메모리를 할당합니다.이 메모리는 mysql_close() (을)를 호출하는 것에 의해 해방됩니다.이 방법에는, 접속에 실패했을 때에 에러 메세지를 취득할 수 없다고 하는 단점이 있습니다(mysql_errno() 또는 mysql_error() (으)로부터 에러 정보를 취득하기에는 유효한 MYSQL 포인터를 건네줄 필요가 있습니다).

반환값

mysql_real_connect() 와 같습니다.

에러

mysql_real_connect() 와 같습니다.

11.1.3.6. mysql_create_db()

int mysql_create_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름으로 데이타베이스를 작성합니다.

이 함수는 폐지되고 있습니다.대신에,mysql_query() (을)를 사용해 CREATE DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 작성되었을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_create_db(&mysql, "my_database"))
{
   fprintf(stderr, "Failed to create new database.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.7. mysql_data_seek()

void mysql_data_seek(MYSQL_RES *result, my_ulonglong offset)

설명

쿼리 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_data_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.3.8. mysql_debug()

void mysql_debug(const char *debug)

설명

지정된 캐릭터 라인으로 DBUG_PUSH (을)를 실행합니다.mysql_debug() (은)는, Fred Fish 디버그 라이브러리를 사용합니다.이 함수를 사용하려면 , 디버그를 서포트하기 위한 클라이언트 라이브러리를 컴파일 할 필요가 있습니다. See 항E.1. 「MySQL 서버의 디버그」. See 항E.2. 「MySQL 클라이언트의 디버그」.

반환값

없습니다.

에러

없습니다.

례

다음의 코드를 실행하면(자), 클라이언트 라이브러리에 의해 클라이언트 머신의 /tmp/client.trace 에 트레이스 파일이 생성됩니다.

mysql_debug("d:t:O, /tmp/client.trace");

11.1.3.9. mysql_drop_db()

int mysql_drop_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름의 데이타베이스를 파기합니다.

이 함수는 폐지되고 있습니다.대신에,mysql_query() (을)를 사용해 DROP DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 파기되었을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_drop_db(&mysql, "my_database"))
  fprintf(stderr, "Failed to drop the database: Error: %s\n",
          mysql_error(&mysql));

11.1.3.10. mysql_dump_debug_info()

int mysql_dump_debug_info(MYSQL *mysql)

설명

디버그 정보를 로그에 기입하도록(듯이) 서버에 지시합니다.접속 유저가 SUPER 특권을 가지지 않는 경우는 정상적으로 동작하지 않습니다.

반환값

정상적으로 동작했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.11. mysql_eof()

my_bool mysql_eof(MYSQL_RES *result)

설명

이 함수는 폐지되고 있습니다.대신에 mysql_errno() 또는 mysql_error() 를 사용할 수 있습니다.

mysql_eof() (은)는, 결과 세트의 마지막 레코드가 읽혔는지 어떠했는지를 판정합니다.

mysql_store_result() (을)를 호출해 결과 세트를 취득하는 경우, 클라이언트는 1 회의 동작으로 결과 세트 전체를 받습니다.이 경우,mysql_fetch_row() (을)를 호출해 반환값이 NULL 이면, 벌써 결과 세트의 마지막에 도달하고 있던 것을 알 수 있으므로,mysql_eof() (을)를 호출할 필요는 없습니다.mysql_store_result() (와)과 함께 사용하는 경우,mysql_eof() (은)는 항상 true 를 돌려줍니다.

한편,mysql_use_result() (을)를 사용해 결과 세트의 취득을 개시했을 경우는,mysql_fetch_row() (을)를 반복해 호출하는 것에 의해 그 레코드를 1 행씩 서버로부터 취득합니다.이 순서를 실행하고 있는 도중에 접속에 이상이 발생하는 경우가 있으므로,mysql_fetch_row() (을)를 호출해 반환값이 NULL 에서 만나도, 그것이 반드시 결과 세트의 마지막에 정상적으로 도달한 것을 의미하는 것은 아닙니다.이 경우는,mysql_eof() (을)를 사용하는 것에 의해, 어떤 상황인가를 판단할 수 있습니다.mysql_eof() (은)는, 결과 세트의 마지막에 도달하고 있었을 경우는 0 이외, 에러가 발생하고 있었을 경우는 0 (을)를 돌려줍니다.

mysql_eof() 는, 역사적으로는 표준의 MySQL 에러 함수이다 mysql_errno() 및 mysql_error() 의 전신입니다.이러한 에러 함수는 같은 정보를 돌려주므로, 벌써 폐지되고 있다 mysql_eof() 보다 우선해 사용해 주세요(실제,mysql_eof() 하지만 돌려주는 것은 불리언 값만으로, 에러 함수는 에러 발생 이유를 나타내는 것보다 많은 정보를 돌려줍니다).

반환값

에러가 발생하고 있지 않는 경우는 0.결과 세트의 마지막에 도달하고 있었을 경우는 0 이외.

에러

없습니다.

례

mysql_eof() 에는 다음과 같은 사용법이 생각됩니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(!mysql_eof(result))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

다만, 표준의 MySQL 에러 함수를 다음과 같이 사용하면, 같은 동작을 실현할 수 있습니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(mysql_errno(&mysql))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

11.1.3.12. mysql_errno()

unsigned int mysql_errno(MYSQL *mysql)

설명

mysql_errno() (은)는,mysql 그리고 지정되는 접속에 대해, 마지막에 불려 간, 성공 또는 실패할 가능성이 있다 API 함수의 에러 코드를 돌려줍니다.반환값이 0 의 경우, 에러는 발생하고 있지 않습니다.클라이언트의 에러 메세지 번호의 일람은, MySQL errmsg.h 헤더 파일에 기술되고 있습니다.서버의 에러 메세지 번호의 일람은,mysqld_error.h 에 기술되고 있습니다.MySQL 소스 디스트리뷰션에 포함되는 파일 Docs/mysqld_error.txt 에는, 모든 에러 메세지 및 에러 번호의 일람이 기술되고 있습니다.서버의 에러 코드의 일람은,항 12.1. 「돌려주어지는 에러」 에도 기재되어 있습니다.

주의: mysql_fetch_row() 등의 일부의 함수는, 성공했을 경우에 mysql_errno() 를 설정하지 않습니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_errno() (을)를 리셋트 한다고 생각해 주세요.

반환값

마지막에 불려 간 mysql_xxx 함수가 실패하고 있었을 경우는 그 에러 코드.0 (은)는 에러가 발생하지 않았던 것을 나타냅니다.

에러

없습니다.

11.1.3.13. mysql_error()

const char *mysql_error(MYSQL *mysql)

설명

mysql_error() (은)는,mysql 그리고 지정된 접속에 대해, 마지막에 불려 갔다 API 함수가 실패했을 때의 에러 메세지를 눌 종단 캐릭터 라인으로서 돌려줍니다.함수가 실패하지 않았던 경우,mysql_error() 의 반환값은 그 전의 에러 메세지인가, 에러가 전혀 발생하고 있지 않는 경우는 공문자열이 됩니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_error() (을)를 리셋트 한다고 생각해 주세요.

mysql_errno (을)를 리셋트 하는 함수에서는, 다음의 2 개의 비교는 동등합니다.

if(mysql_errno(&mysql))
{
    // an error occurred
}

if(mysql_error(&mysql)[0] != '\0')
{
    // an error occurred
}

클라이언트의 에러 메세지의 언어는, MySQL 클라이언트 라이브러리를 재컴파일 하는 것에 의해 변경할 수 있습니다.현재는, 복수가 다른 언어로 에러 메세지를 돌려줄 수가 있습니다. See 항 4.7.2. 「영어 이외의 에러 메세지」.

반환값

에러의 내용을 설명하는 눌 종단 캐릭터 라인.에러가 발생하고 있지 않는 경우는 공문자열.

에러

없습니다.

11.1.3.14. mysql_escape_string()

이 함수 대신에 mysql_real_escape_string() (을)를 사용해 주세요.

mysql_real_escape_string() (은)는 선두의 인수로서 접속 핸들러를 받아, 현재의 캐릭터 세트에 따라 캐릭터 라인을 이스케이프 합니다만, 그 2 점을 제외하면, 이 함수와 mysql_real_escape_string() (은)는 같습니다.mysql_escape_string() (은)는 접속 핸들러를 인수로서 받지 않습니다.또, 현재의 캐릭터 세트는 참조하지 않습니다.

11.1.3.15. mysql_fetch_field()

MYSQL_FIELD *mysql_fetch_field(MYSQL_RES *result)

설명

결과 세트에 포함되는 1 살의 컬럼의 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.결과 세트에 포함되는 모든 컬럼의 정의를 취득하려면 , 이 함수를 반복해 호출합니다.정의를 취득하는 컬럼이 남지 않은 경우,mysql_fetch_field() (은)는 NULL 를 돌려줍니다.

새롭고 SELECT 쿼리를 실행할 때마다,mysql_fetch_field() (은)는 선두의 컬럼의 정의를 돌려주도록(듯이) 리셋트 됩니다.또,mysql_field_seek() (을)를 호출했을 경우도,mysql_fetch_field() 하지만 돌려주는 필드가 바뀝니다.

mysql_query() (을)를 호출해 테이블에 대해서 SELECT 를 실행한 후 mysql_store_result() (을)를 호출하지 않았던 경우,mysql_fetch_field() (을)를 호출해 BLOB 필드의 길이를 요구하면(자), 디폴트의 BLOB 장(8 킬로바이트)이 돌려주어집니다(MySQL 는 BLOB 의 최대장을 모르기 때문에 8 킬로바이트를 돌려줍니다.이 값은 장래 설정 가능한 값으로 할 필요가 있습니다).결과 세트를 취득한 후는, 그 쿼리에 있어서의 이 컬럼의 최대치의 길이가 field->max_length 에게 건네집니다.

반환값

현재의 컬럼의 MYSQL_FIELD 구조체.컬럼이 남지 않은 경우는 NULL.

에러

없습니다.

례

MYSQL_FIELD *field;

while((field = mysql_fetch_field(result)))
{
    printf("field name %s\n", field->name);
}

11.1.3.16. mysql_fetch_fields()

MYSQL_FIELD *mysql_fetch_fields(MYSQL_RES *result)

설명

결과 세트의 모든 MYSQL_FIELD 구조체의 배열을 돌려줍니다.각 구조체에는, 결과 세트에 포함된다 1 살의 컬럼의 필드 정의가 격납되고 있습니다.

반환값

결과 세트에 포함되는 모든 컬럼의 MYSQL_FIELD 구조체의 배열.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *fields;

num_fields = mysql_num_fields(result);
fields = mysql_fetch_fields(result);
for(i = 0; i < num_fields; i++)
{
   printf("Field %u is %s\n", i, fields[i].name);
}

11.1.3.17. mysql_fetch_field_direct()

MYSQL_FIELD *mysql_fetch_field_direct(MYSQL_RES *result, unsigned int fieldnr)

설명

필드 번호 fieldnr 그리고 지정되는 결과 세트의 컬럼의 필드 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.이 함수를 사용하면, 임의의 컬럼의 정의를 취득할 수 있습니다.fieldnr 의 값은 0 으로부터 mysql_num_fields(result)-1 의 범위에서 지정합니다.

반환값

지정한 컬럼의 MYSQL_FIELD 구조체.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *field;

num_fields = mysql_num_fields(result);
for(i = 0; i < num_fields; i++)
{
    field = mysql_fetch_field_direct(result, i);
    printf("Field %u is %s\n", i, field->name);
}

11.1.3.18. mysql_fetch_lengths()

unsigned long *mysql_fetch_lengths(MYSQL_RES *result)

설명

결과 세트내의 경향 레코드의 컬럼의 길이를 돌려줍니다.필드치를 카피하려고 하는 경우, 이 함수를 사용하면 strlen() (을)를 호출하지 않아도 길이를 취득할 수 있으므로 편리합니다.또, 결과 세트에 바이너리 데이터가 포함되어 있는 경우,strlen() (은)는 눌 문자가 포함되는 필드의 길이를 올바르게 돌려주지 않기 때문에, 이 함수를 사용해 데이터 사이즈를 조사할 필요가 있습니다 .

하늘의 컬럼 및 NULL 값을 포함한 컬럼의 길이는 0 입니다.이 2 개를 구별하는 방법에 대해서는,mysql_fetch_row() 의 설명을 참조해 주세요.

반환값

각 컬럼의 사이즈(눌 종단 문자는 세지 않는다)를 나타낸다 unsigned long 정수의 배열.에러가 발생했을 경우는 NULL.

에러

mysql_fetch_lengths() (은)는 결과 세트의 경향 레코드에서만 유효합니다.mysql_fetch_row() (을)를 호출하기 전 또는 결과 세트의 모든 레코드를 취득한 다음에 불려 갔을 경우는 NULL 를 돌려줍니다.

례

MYSQL_ROW row;
unsigned long *lengths;
unsigned int num_fields;
unsigned int i;

row = mysql_fetch_row(result);
if (row)
{
    num_fields = mysql_num_fields(result);
    lengths = mysql_fetch_lengths(result);
    for(i = 0; i < num_fields; i++)
    {
         printf("Column %u is %lu bytes in length.\n", i, lengths[i]);
    }
}

11.1.3.19. mysql_fetch_row()

MYSQL_ROW mysql_fetch_row(MYSQL_RES *result)

설명

결과 세트의 다음의 레코드를 취득합니다.mysql_store_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않으면 NULL (을)를 돌려줍니다.mysql_use_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않은지, 또는 에러가 발생했을 때에 NULL 를 돌려줍니다.

레코드에 포함되는 값의 수는 mysql_num_fields(result) 에 의해 취득합니다.mysql_fetch_row() (을)를 호출해 그 반환값이 row 에 격납되고 있는 경우, 값에의 포인터는 row[0] 으로부터 row[mysql_num_fields(result)-1] (와)과 같이 나타내집니다.NULL 포인터는, 레코드의 값이 NULL 치인 것을 나타냅니다.

mysql_fetch_lengths() (을)를 호출하면(자), 레코드의 필드치의 길이를 취득할 수 있습니다.하늘의 필드 및 NULL (을)를 포함한 필드의 길이는 어느쪽이나 0 그렇지만, 그 필드의 포인터를 조사하는 것에 의해 그 2 개(살)을 구별할 수 있습니다.포인터가 NULL 의 경우, 필드의 값은 NULL 입니다.그 이외의 경우, 필드는 하늘입니다.

반환값

다음의 레코드의 MYSQL_ROW 구조체.취득하는 레코드가 남지 않은지, 에러가 발생했을 경우는 NULL.

에러

주의: mysql_fetch_row() 를 1 회 호출하고 나서, 다음에 호출할 때까지 에 에러가 리셋트 될 것은 없습니다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

MYSQL_ROW row;
unsigned int num_fields;
unsigned int i;

num_fields = mysql_num_fields(result);
while ((row = mysql_fetch_row(result)))
{
   unsigned long *lengths;
   lengths = mysql_fetch_lengths(result);
   for(i = 0; i < num_fields; i++)
   {
       printf("[%.*s] ", (int) lengths[i], row[i] ? row[i] : "NULL");
   }
   printf("\n");
}

11.1.3.20. mysql_field_count()

unsigned int mysql_field_count(MYSQL *mysql)

MySQL 3.22.24 보다 낡은 버젼을 사용하고 있는 경우, 이 함수 대신에 unsigned int mysql_num_fields(MYSQL *mysql) (을)를 사용해 주세요.

설명

현재의 접속으로 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려줍니다.

통상 이 함수는,mysql_store_result() 하지만 NULL (을)를 돌려주었을 때(결과 세트 포인터가 돌려주어지지 않았을 때)에 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해, 클라이언트 프로그램은, 쿼리가 SELECT(또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항 11.1.12.1. 「mysql_query() 가 정상적으로 종료한 다음에 mysql_store_result() 가 NULL 를 돌려주는 경우가 있는 것은 왠지」.

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql, query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if(mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
        else // mysql_store_result() should have returned data
        {
            fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
    }
}

mysql_field_count(&mysql) 의 호출 부분을 mysql_errno(&mysql) 에 옮겨놓는 방법도 있습니다.이 경우, 스테이트먼트가 SELECT (이었)였는지 아닌지는,mysql_field_count() 하지만 돌려주는 값으로부터 추측하는 것이 아니라,mysql_store_result() 하지만 돌려주는 에러를 직접 조사하고 판단합니다.

11.1.3.21. mysql_field_seek()

MYSQL_FIELD_OFFSET mysql_field_seek(MYSQL_RES *result, MYSQL_FIELD_OFFSET offset)

설명

필드 커서의 위치를 지정된 오프셋(offset)로 설정합니다.다음에 mysql_fetch_field() (을)를 호출하면(자), 그 오프셋(offset)에 관련지을 수 있었던 컬럼의 필드 정의를 돌려줍니다.

레코드의 선두에 시크 하려면 ,offset 값에 0 을 건네줍니다.

반환값

시크 하기 전의 필드 커서의 값.

에러

없습니다.

11.1.3.22. mysql_field_tell()

MYSQL_FIELD_OFFSET mysql_field_tell(MYSQL_RES *result)

설명

마지막에 실행되었다 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려줍니다.이 반환값을,mysql_field_seek() 에 인수로서 건네줄 수가 있습니다.

반환값

필드 커서의 현재의 오프셋(offset).

에러

없습니다.

11.1.3.23. mysql_free_result()

void mysql_free_result(MYSQL_RES *result)

설명

mysql_store_result(),mysql_use_result(),mysql_list_dbs() 등이 결과 세트에 할당한 메모리를 해방합니다.결과 세트가 필요없게 되면(자),mysql_free_result() (을)를 호출해, 사용하고 있던 메모리를 해방합니다.

반환값

없습니다.

에러

없습니다.

11.1.3.24. mysql_get_client_info()

char *mysql_get_client_info(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 캐릭터 라인을 돌려줍니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 캐릭터 라인.

에러

없습니다.

11.1.3.25. mysql_get_client_version()

unsigned long mysql_get_client_version(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 정수를 돌려줍니다.이 값은 XYYZZ 그렇다고 하는 형식에서 나타내져X (은)는 메이저 버젼,YY (은)는 릴리스 레벨,ZZ (은)는 릴리스 레벨내의 버젼 번호입니다.예를 들어,40102 (은)는, 클라이언트의 라이브러리 버젼이 4.1.2 인 것을 나타냅니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 정수.

에러

없습니다.

11.1.3.26. mysql_get_host_info()

char *mysql_get_host_info(MYSQL *mysql)

설명

사용하고 있는 접속의 타입을 나타내는 캐릭터 라인을 돌려줍니다.이 캐릭터 라인에는 서버의 호스트명도 포함됩니다.

반환값

서버의 호스트명 및 접속 타입을 나타내는 캐릭터 라인.

에러

없습니다.

11.1.3.27. mysql_get_proto_info()

unsigned int mysql_get_proto_info(MYSQL *mysql)

설명

현재의 접속에 사용하고 있는 프로토콜의 버젼을 돌려줍니다.

반환값

현재의 접속에 사용하고 있는 프로토콜의 버젼을 나타낸다 unsigned 정수.

에러

없습니다.

11.1.3.28. mysql_get_server_info()

char *mysql_get_server_info(MYSQL *mysql)

설명

서버의 버젼 번호를 나타내는 캐릭터 라인을 돌려줍니다.

반환값

서버의 버젼 번호를 나타내는 캐릭터 라인.

에러

없습니다.

11.1.3.29. mysql_get_server_version()

unsigned long mysql_get_server_version(MYSQL *mysql)

설명

서버의 버젼 번호를 정수로서 돌려줍니다(4.1 의 신기능).

반환값

MySQL 서버의 버젼을 다음의 형식에서 나타내는 번호.

main_version*10000 + minor_version *100 + sub_version

예를 들어, 버젼이 4.1.0 의 경우, 반환값은 40100 입니다.

이 값을 사용하면(자), 클라이언트 프로그램은 서버의 버젼으로부터 특정의 기능이 존재하는지 어떤지를 간단하게 판단할 수 있습니다.

에러

없습니다.

11.1.3.30. mysql_info()

char *mysql_info(MYSQL *mysql)

설명

마지막에 실행한 쿼리에 관한 정보를 나타내는 캐릭터 라인을 취득합니다.다만, 대상이 되는 것은, 이하의 일람에 포함되는 스테이트먼트만입니다.마지막에 실행했던 것이 다른 스테이트먼트의 쿼리였던 경우는,mysql_info() (은)는 NULL (을)를 돌려줍니다.캐릭터 라인의 형식은, 이하에 설명하도록(듯이), 쿼리의 타입에 따라서 다릅니다.숫자는 예로서 가리킨 것입니다.실제의 캐릭터 라인에는 실행한 쿼리에 맞은 값이 사용됩니다.

  • INSERT INTO ...SELECT ...

    캐릭터 라인의 형식: Records: 100 Duplicates: 0 Warnings: 0

  • INSERT INTO ...VALUES (...), (...), (...)...

    캐릭터 라인의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • LOAD DATA INFILE ...

    캐릭터 라인의 형식: Records: 1 Deleted: 0 Skipped: 0 Warnings: 0

  • ALTER TABLE

    캐릭터 라인의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • UPDATE

    캐릭터 라인의 형식:Rows matched: 40 Changed: 40 Warnings: 0

주의: mysql_info() 는,INSERT ... VALUES 스테이트먼트가 복수 레코드를 삽입하는 형식의 경우에 한정해(복수의 값리스트가 지정되었을 경우에 한정해),NULL 이외의 값을 돌려줍니다.

반환값

마지막에 실행한 쿼리에 관한 정보를 나타내는 캐릭터 라인.쿼리의 정보가 없는 경우는 NULL.

에러

없습니다.

11.1.3.31. mysql_init()

MYSQL *mysql_init(MYSQL *mysql)

설명

mysql_real_connect() 에 적응한다 MYSQL 오브젝트를 할당해 또는 초기화합니다.mysql 에 NULL 포인터를 건네주었을 경우, 함수는 새로운 오브젝트에 메모리를 할당해 초기화해, 그것을 돌려줍니다.그 이외의 값을 건네주었을 경우는, 오브젝트를 초기화해, 그 주소를 돌려줍니다.mysql_init() 하지만 새로운 오브젝트에 메모리를 할당했을 경우, 그 메모리는 mysql_close() (을)를 호출해 접속을 클로우즈 할 때에 해방됩니다.

반환값

초기화된 MYSQL* 핸들.새로운 오브젝트에 할당하는 충분한 메모리가 없었던 경우는 NULL.

에러

메모리가 부족했을 경우는 NULL 를 돌려줍니다.

11.1.3.32. mysql_insert_id()

my_ulonglong mysql_insert_id(MYSQL *mysql)

설명

전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려줍니다.이 함수는,AUTO_INCREMENT 필드를 포함한 테이블에 대해서 INSERT 쿼리를 실행한 다음에 사용합니다.

주의: mysql_insert_id() (은)는, 전회 실행된 쿼리로 AUTO_INCREMENT 값이 생성되지 않았던 경우는,0 (을)를 돌려줍니다.장래를 위해서(때문에) 그 값을 보존할 필요가 있는 경우는, 그것을 생성하는 쿼리의 직후에 mysql_insert_id() (을)를 호출할 필요가 있습니다.

전회 실행된 쿼리가 에러를 돌려주었을 경우에 대해서는,mysql_insert_id() 의 값은 미정도리입니다.

mysql_insert_id() (은)는,AUTO_INCREMENT 값을 생성하는지, 또는 컬럼치를 LAST_INSERT_ID(expr) 로 설정한다 INSERT 스테이트먼트 및 UPDATE 스테이트먼트의 실행 후에 갱신됩니다. See 항 6.3.6.2. 「그 외의 각종 함수」.

주의: SQL LAST_INSERT_ID() 함수의 값에는, 반드시 마지막에 생성되었다 AUTO_INCREMENT 값이 포함됩니다.이 값은 서버에 보관 유지되므로, 어느 쿼리를 실행하고 나서 다음의 쿼리를 실행할 때까지 에 리셋트 될 것은 없습니다.

반환값

전회 실행된 쿼리에 의해 갱신되었다 AUTO_INCREMENT 필드의 값.현재의 접속으로 아직 1 회도 쿼리가 실행되어 있지 않았던 경우, 또는 전회 실행된 쿼리로 AUTO_INCREMENT 값이 갱신되지 않았던 경우, 0 을 돌려줍니다.

에러

없습니다.

11.1.3.33. mysql_kill()

int mysql_kill(MYSQL *mysql, unsigned long pid)

설명

pid 그리고 지정하는 thread를 강제 종료하도록(듯이), 서버에 요구합니다.

반환값

정상 종료했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.34. mysql_list_dbs()

MYSQL_RES *mysql_list_dbs(MYSQL *mysql, const char *wild)

설명

서버상의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 데이타베이스명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘%＇ 또는 ‘_＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 데이타베이스명이 일치합니다.mysql_list_dbs() (을)를 호출하면(자), 쿼리 SHOW databases [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.35. mysql_list_fields()

MYSQL_RES *mysql_list_fields(MYSQL *mysql, const char *table, const char *wild)

설명

지정된 테이블의 필드로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 필드명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘%＇ 또는 ‘_＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 필드명이 일치합니다.mysql_list_fields() (을)를 호출하면(자), 쿼리 SHOW COLUMNS FROM tbl_name [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

주의: mysql_list_fields() 대신에 SHOW COLUMNS FROM tbl_name (을)를 사용하는 것을 추천 합니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.36. mysql_list_processes()

MYSQL_RES *mysql_list_processes(MYSQL *mysql)

설명

현재의 서버 thread의 일람을 나타내는 결과 세트를 돌려줍니다.이것은,mysqladmin processlist 또는 SHOW PROCESSLIST 쿼리가 돌려주는 정보와 같은 타입의 정보입니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.37. mysql_list_tables()

MYSQL_RES *mysql_list_tables(MYSQL *mysql, const char *wild)

설명

현재의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 테이블명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘%＇ 또는 ‘_＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 테이블명이 일치합니다.mysql_list_tables() (을)를 호출하면(자), 쿼리 SHOW tables [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.38. mysql_num_fields()

unsigned int mysql_num_fields(MYSQL_RES *result)

또는

unsigned int mysql_num_fields(MYSQL *mysql)

2 번째의 형식은, MySQL 3.22.24 이후에서는 동작하지 않습니다.MYSQL* 인수를 건네주려면 , 이 함수 대신에 unsigned int mysql_field_count(MYSQL *mysql) 를 사용할 필요가 있습니다.

설명

결과 세트의 컬럼수를 돌려줍니다.

주의: 결과 세트에의 포인터 또는 접속 핸들에의 포인터의 어느 쪽을 사용해도, 컬럼수를 취득할 수 있습니다.mysql_store_result() 또는 mysql_use_result() 가 NULL (을)를 돌려주었을 경우(결과 세트 포인터가 돌려주어지지 않았던 경우)는, 접속 핸들을 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해, 클라이언트 프로그램은, 쿼리가 SELECT(또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항 11.1.12.1. 「mysql_query() 가 정상적으로 종료한 다음에 mysql_store_result() 가 NULL 를 돌려주는 경우가 있는 것은 왠지」.

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql, query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if (mysql_errno(&mysql))
        {
           fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
        else if (mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
    }
}

(쿼리가 결과 세트를 돌려주는 것을 알 수 있고 있는 경우)mysql_errno(&mysql) (을)를 호출하는 대신에 mysql_field_count(&mysql) 가 0 (을)를 돌려주는지 어떤지를 조사하는 방법도 있습니다.이것은, 0 (을)를 돌려주는 것은, 어떠한 이상이 발생했을 경우만이기 때문입니다.

11.1.3.39. mysql_num_rows()

my_ulonglong mysql_num_rows(MYSQL_RES *result)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_num_rows() 의 사용법은,mysql_store_result() 와 mysql_use_result() 의 어느 쪽을 사용해 결과 세트를 취득할까에 의해 정해집니다.mysql_store_result() (을)를 사용하는 경우, 곧바로 mysql_num_rows() (을)를 호출할 수가 있습니다.mysql_use_result() (을)를 사용하는 경우, 결과 세트에 포함되는 모든 레코드를 취득할 때까지는,mysql_num_rows() (은)는 올바른 값을 돌려주지 않습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.3.40. mysql_options()

int mysql_options(MYSQL *mysql, enum mysql_option option, const char *arg)

설명

이 함수를 사용해, 접속 옵션을 추가 설정해, 접속의 동작을 바꿀 수가 있습니다.이 함수를 여러 차례 호출하는 것으로, 복수의 옵션을 설정할 수 있습니다.

mysql_options()
(은)는,mysql_init() 를 실행하고 나서
mysql_connect() 또는
mysql_real_connect()
(을)를 호출할 때까지 에 호출할 필요가 있습니다.

option 인수는, 설정하는 옵션입니다.arg 인수는 그 옵션으로 설정하는 값입니다.옵션이 정수의 경우,arg 에는 정수치에의 포인터를 건네줄 필요가 있습니다.

설정 가능한 옵션의 값을 다음에 나타냅니다.

옵션 | 인수의 형태 | 기능
MYSQL_OPT_CONNECT_TIMEOUT | unsigned int * | 접속의 타임 아웃 시간(초단위).
MYSQL_OPT_READ_TIMEOUT | unsigned int * | 서버로부터의 읽기 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_WRITE_TIMEOUT | unsigned int * | 서버에의 기입해 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_COMPRESS | 미사용 | 압축된 클라이언트/서버 프로토콜을 사용.
MYSQL_OPT_LOCAL_INFILE | unsigned int 에의 생략 가능한 포인터 | 포인터가 지정되지 않는지, 또는 0 은 아니다 unsigned int 에의 포인터가 지정되었을 경우, 커멘드 LOAD LOCAL INFILE 는 유효.
MYSQL_OPT_NAMED_PIPE | 미사용 | 이름 첨부 파이프를 사용해 NT 상에서 동작하는 MySQL 서버에 접속.
MYSQL_INIT_COMMAND | char * | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
MYSQL_READ_DEFAULT_FILE | char * | my.cnf (이)가 아니고, 지정된 옵션 설정 파일로부터 옵션을 읽어들인다.
MYSQL_READ_DEFAULT_GROUP | char * | my.cnf 의 지정된 그룹 또는 MYSQL_READ_DEFAULT_FILE 그리고 지정된 파일로부터 옵션을 읽어들인다.
MYSQL_OPT_PROTOCOL | unsigned int * | 사용하는 프로토콜의 타입.mysql.h 그리고 정의되고 있다 mysql_protocol_type 의 열거치의 어느쪽이든 1 개(살)인 것.
MYSQL_SHARED_MEMORY_BASE_NAME | char* | 서버와의 통신에 사용하는 이름 첨부 공유 메모리오브제크트.접속 상대의 mysqld 서버가 사용하는 옵션 -shared-memory-base-name (와)과 같은 값을 지정할 필요가 있다.

주의: MYSQL_READ_DEFAULT_FILE 또는 MYSQL_READ_DEFAULT_GROUP (을)를 사용하는 경우는, 그룹 client 가 항상 읽힙니다.

옵션 설정 파일의 지정된 그룹에는 이하의 옵션을 지정 가능합니다.

옵션 | 설명
connect-timeout | 접속의 타임 아웃 시간(초단위).Linux 그럼, 서버로부터 최초의 응답을 기다리는 경우에도 이 타임 아웃 시간을 사용한다.
compress | 압축된 클라이언트/서버 프로토콜을 사용.
database | 접속 커멘드로 데이타베이스가 지정되지 않았던 경우에 접속하는 데이타베이스.
debug | 디버그 옵션.
disable-local-infile | LOAD DATA LOCAL 의 사용을 무효로 한다.
host | 디폴트의 호스트명.
init-command | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
interactive-timeout | mysql_real_connect() 로 CLIENT_INTERACTIVE (을)를 지정하는 것과 같다. See 항 11.1.3.43. 「mysql_real_connect()」.
local-infile[=(0|1)] | 인수가 지정되지 않는지, 또는 0 이외의 인수가 지정되었을 경우에 LOAD DATA LOCAL 의 사용을 유효하게 한다.
max_allowed_packet | 클라이언트가 서버로부터 읽어들여 가능한 패킷의 최대 사이즈.
password | 디폴트의 패스워드.
pipe | 이름 첨부 파이프를 사용해 NT 상에서 동작하는 MySQL 서버에 접속.
protocol=(TCP | SOCKET | PIPE | MEMORY) | 서버에 접속할 경우에 사용하는 프로토콜을 선택(4.1 의 신기능).
port | 디폴트의 포토 번호.
return-found-rows | UPDATE (을)를 사용했을 때에 갱신된 레코드가 아니고, 검색 결과의 레코드를 돌려주도록(듯이),mysql_info() 에 지시한다.
shared-memory-base-name=name | 서버와의 접속에 사용하는 공유 메모리의 이름(디폴트는 "MySQL").MySQL 4.1 의 신기능.
socket | 디폴트의 소켓 번호.
user | 디폴트의 유저.

주의: timeout 대신에 connect-timeout 하지만 제공되고 있습니다만,timeout 도 당분간은 사용할 수 있습니다.

옵션 설정 파일의 상세한 것에 대하여는,항 4.1.2. 「my.cnf 옵션 설정 파일」 (을)를 참조해 주세요.

반환값

정상 종료했을 경우는 0.불명한 옵션을 사용했을 경우는 0 이외.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql, MYSQL_OPT_COMPRESS, 0);
mysql_options(&mysql, MYSQL_READ_DEFAULT_GROUP,"odbc");
if (!mysql_real_connect(&mysql,"host","user","passwd","database", 0, NULL, 0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는, 압축된 클라이언트/서버 프로토콜을 사용하는 것, 및 my.cnf 파일의 odbc 섹션의 옵션을 추가로 읽어들이는 것을, 클라이언트에 요구하고 있습니다.

11.1.3.41. mysql_ping()

int mysql_ping(MYSQL *mysql)

설명

서버에의 접속이 정상적인지 어떤지를 확인합니다.절단 되고 있었을 경우는, 자동적으로 재접속을 시도합니다.

장시간에 걸쳐서 아이돌 상태였던 클라이언트는 이 함수를 사용하는 것에 의해, 서버에 의해 접속이 절단되어 있지 않은지 어떤지를 조사해, 필요하면 재접속할 수가 있습니다.

반환값

서버와의 접속이 정상적인 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.42. mysql_query()

int mysql_query(MYSQL *mysql, const char *query)

설명

눌 종단 캐릭터 라인 query 그리고 지정된 SQL 쿼리를 실행합니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세미콜론(‘;＇) 또는 \g (을)를 추가할 필요는 없습니다.

mysql_query() (은)는 바이너리 데이터를 포함한 쿼리를 취급할 수가 없습니다.그러한 쿼리에서는 대신에 mysql_real_query() (을)를 사용할 필요가 있습니다(바이너리 데이터에는 '\0' 하지만 포함될 가능성이 있어,mysql_query() (은)는 그것을 쿼리 캐릭터 라인의 마지막으로서 해석해 버리기 (위해)때문에).

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항 11.1.3.20. 「mysql_field_count()」.

반환값

쿼리가 정상적으로 동작했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.43. mysql_real_connect()

MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned long client_flag)

설명

mysql_real_connect() (은)는,host 로 동작하고 있는 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_real_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 지정 방법을 다음에 나타냅니다.

  • 1 번째의 파라미터에는, 기존의 MYSQL 구조체의 주소를 지정한다.mysql_real_connect() (을)를 호출하기 전에,mysql_init() (을)를 호출해 MYSQL 구조체를 초기화할 필요가 있다.mysql_options() (을)를 사용하면(자), 다양한 접속 옵션을 변경할 수 있다. See 항 11.1.3.40. 「mysql_options()」.

  • host 파라미터에는, 호스트명 또는 IP 주소의 어느 쪽인지를 지정한다.host 에 NULL 또는 캐릭터 라인 "localhost" (을)를 지정했을 경우, 로컬 호스트에게 접속하는 것으로 간주해진다.OS 하지만 소켓(Unix) 또는 이름 첨부 파이프(Windows)를 서포트하고 있는 경우, TCP/IP 대신에 그것들을 사용해 서버에 접속한다.

  • user 파라미터에는 유저의 MySQL 로그인 ID (을)를 지정한다.user 에 NULL 또는 공문자열 "" (을)를 지정했을 경우, 현재의 유저를 사용하는 것으로 간주해진다.Unix 그럼 현재의 로그인명이 사용된다.Windows 그리고 ODBC (을)를 사용하는 경우는, 현재의 유저명을 명시적으로 지정할 필요가 있다. See 항 11.2.2. 「ODBC 어드미니스트레이터의 필드의 설정 방법법」.

  • passwd 파라미터에는 user 의 패스워드를 지정한다.passwd 에 NULL (을)를 지정했을 경우,user 테이블의 엔트리의 패스워드 필드에 아무것도 지정되어 있지 않은(하늘이다) 유저만이 체크 대상이 된다.데이타베이스 관리자는, 이 기능을 사용해, 패스워드를 지정해 있는지 어떤지에 의해 유저에게 다른 특권을 준다고 한다 MySQL 특권 시스템을 셋업 할 수 있다.

    주의:패스워드의 암호화는 클라이언트 API 에 의해 자동적으로 처리되므로,mysql_real_connect() (을)를 호출하기 전에 패스워드의 암호화는 불필요하다.

  • db 파라미터에는 데이타베이스명을 지정한다.db 하지만 NULL (이)가 아닌 경우, 이 값이 접속의 디폴트 데이타베이스로서 설정된다.

  • port 파라미터에 0 이외의 값을 지정했을 경우, 이 값이 TCP/IP 접속의 포토 번호로서 사용된다.주의: 접속의 타입은 host 파라미터에 의해 결정된다.

  • unix_socket 파라미터에 NULL 이외의 값을 지정했을 경우, 이 캐릭터 라인이 소켓 또는 이름 첨부 파이프에 사용된다.주의: 접속의 타입은 host 파라미터에 의해 결정된다.

  • client_flag 파라미터에는 통상 0 (을)를 지정하지만, 지극히 특수한 상황에서는 이하에 나타내는 플래그를 조합해 지정할 수 있다.

    플래그명 | 플래그의 설명
    CLIENT_COMPRESS | 압축 프로토콜을 사용.
    CLIENT_FOUND_ROWS | 영향을 받은 레코드의 수가 아니고, 검색 결과의(일치한) 레코드의 수를 돌려준다.
    CLIENT_IGNORE_SPACE | 함수명의 말미의 공백을 무시한다.모든 함수명을 예약어(reserved word)로 한다.
    CLIENT_INTERACTIVE | 아이돌 상태가(wait_timeout 초는 아니고)interactive_timeout 초계속하면(자) 접속을 클로우즈 한다.
    CLIENT_LOCAL_FILES | LOAD DATA LOCAL 의 처리를 유효하게 한다.
    CLIENT_MULTI_STATEMENTS | 클라이언트가 복수행 쿼리(‘;＇ (을)를 스테이트먼트의 단락으로 한다)를 송신할 가능성이 있는 것을 서버에 통지한다.이 플래그가 설정되어 있지 않은 경우, 복수행 쿼리는 무효.MySQL 4.1 의 신기능.
    CLIENT_MULTI_RESULTS | 클라이언트가 복수 쿼리 또는 Stored Procedure에 의해 취득한 복수의 결과 세트를 처리할 수 있는 것을 서버에 통지한다.CLIENT_MULTI_STATEMENTS 하지만 설정되어 있는 경우, 이 플래그는 자동적으로 설정된다.MySQL 4.1 의 신기능.
    CLIENT_NO_SCHEMA | db_name.tbl_name.col_name 그렇다고 하는 구문의 사용을 금지한다.이것은 ODCB 향해의 구문이다.이 구문을 사용했을 경우, 파서로 에러가 발생한다.이 구문은 일부의 ODBC 프로그램으로 버그를 트랩 하기 위해서 사용한다.
    CLIENT_ODBC | 클라이언트가 ODBC 경유인 것을 통지한다.이 경우,mysqld (은)는 ODBC 클라이언트에 적절한 처리를 실시한다.
    CLIENT_SSL | SSL(암호화 프로토콜)를 사용한다.응용 프로그램에서는 이 플래그를 설정하지 않는 것.이것은 클라이언트 라이브러리가 내부에서 설정하는 플래그이다.

반환값

접속이 정상적으로 확립했을 경우는 MYSQL* 접속 핸들.접속이 확립하지 않았던 경우는 NULL.접속이 확립했을 경우, 반환값은 1 번째의 파라미터의 값과 같습니다.

에러

  • CR_CONN_HOST_ERROR

    MySQL 서버에의 접속이 확립하지 않았다.

  • CR_CONNECTION_ERROR

    로컬의 MySQL 서버에의 접속이 확립하지 않았다.

  • CR_IPSOCK_ERROR

    IP 소켓의 작성에 실패했다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SOCKET_CREATE_ERROR

    Unix 소켓의 작성에 실패했다.

  • CR_UNKNOWN_HOST

    호스트명의 IP 주소가 발견되지 않았다.

  • CR_VERSION_ERROR

    서버에 접속할 때에, 다른 프로토콜 버젼의 클라이언트 라이브러리를 사용했기 때문에, 프로토콜의 불일치가 발생했다.이 에러는,--old-protocol 옵션을 지정하지 않고 기동한 새로운 버젼의 서버에, 매우 낡은 버젼의 클라이언트 라이브러리를 사용해 접속을 시도했을 경우에 발생할 가능성이 있다.

  • CR_NAMEDPIPEOPEN_ERROR

    Windows 그리고 이름 첨부 파이프의 작성에 실패했다.

  • CR_NAMEDPIPEWAIT_ERROR

    Windows 그리고 이름 첨부 파이프의 대기에 실패했다.

  • CR_NAMEDPIPESETSTATE_ERROR

    Windows 그리고 파이프 핸들러의 취득에 실패했다.

  • CR_SERVER_LOST

    connect_timeout 하지만 정의 값이며,connect_timeout 초경과해도 서버에 접속할 수 없었다.또는 init-command 의 실행중에 서버가 다운했다.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql, MYSQL_READ_DEFAULT_GROUP,"your_prog_name");
if (!mysql_real_connect(&mysql,"host","user","passwd","database", 0, NULL, 0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는 mysql_options() (을)를 호출해 MySQL 라이브러리가 my.cnf 파일의 [client] 및 [your_prog_name] 섹션을 읽어들이도록(듯이) 설정해 있습니다.이와 같이 설정하는 것으로, 비표준적인 방법으로 셋업 되었다 MySQL 에 대해서도 이 프로그램이 정상적으로 동작하는 것을 보증합니다.

주의: 접속이 확립했을 때,mysql_real_connect() 에 의해 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.

11.1.3.44. mysql_real_escape_string()

unsigned long mysql_real_escape_string(MYSQL *mysql, char *to, const char *from, unsigned long length)

설명

이 함수는, SQL 스테이트먼트로 사용할 수 있는 정당한 SQL 캐릭터 라인을 작성하기 위해서 사용합니다. See 항 6.1.1.1. 「캐릭터 라인」.

from (으)로 지정한 캐릭터 라인이, 이스케이프 된 SQL 캐릭터 라인에 encode 됩니다.이 때, 접속의 현재의 캐릭터 세트가 고려됩니다.encode 한 결과는 to (으)로 설정되어 말미에는 캐릭터 라인의 마지막을 나타내는 누르바이트가 부가됩니다.encode 되는 문자는,NUL(ASCII 0), '\n', '\r',‘\＇,‘'＇,‘"＇, 및 Ctrl-Z 키(see 항 6.1.1. 「리터럴:캐릭터 라인과 수치의 기술 방법」)입니다(엄밀하게 말하면,MySQL 그리고 이스케이프 할 필요가 있는 것은 쿼리내에서 캐릭터 라인을 인용하기 위한 backslash 및 인용부호 뿐입니다만, 이 함수에서는 로그 파일을 읽기 쉽게 하기 위해서 다른 문자도 이스케이프 합니다).

from 로 지정하는 캐릭터 라인의 길이는 length 아르바이트일 필요가 있습니다.to 버퍼에는, 적어도 length*2+1 아르바이트의 메모리를 할당할 필요가 있습니다(최악의 경우, 1 문자 encode 하는데 2 아르바이트가 필요한 가능성이 있어, 한층 더 캐릭터 라인의 마지막을 나타내는 누르바이트를 격납할 필요가 있습니다).mysql_real_escape_string() 하지만 복귀했을 때,to 에는 눌 종단 캐릭터 라인이 격납되고 있습니다.반환값은 encode 후의 캐릭터 라인의 길이입니다.다만, 캐릭터 라인의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

례

char query[1000], *end;

end = strmov(query,"INSERT INTO test_table values(");
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"What's this", 11);
*end++ = '\'';
*end++ = ', ';
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"binary data: \0\r\n", 16);
*end++ = '\'';
*end++ = ')';

if (mysql_real_query(&mysql, query, (unsigned int) (end - query)))
{
   fprintf(stderr, "Failed to insert row, Error: %s\n",
           mysql_error(&mysql));
}

이 예로 사용되고 있는 strmov() 함수는,mysqlclient 라이브러리에 격납되고 있습니다.strcpy() (와)과 같은 처리를 실시합니다만, 1 번째의 파라미터로 지정된 캐릭터 라인의 마지막을 나타내는 누르바이트에의 포인터를 돌려줍니다.

반환값

to (으)로 설정된 값의 길이.다만, 캐릭터 라인의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

에러

없습니다.

11.1.3.45.mysql_real_query()

int mysql_real_query(MYSQL *mysql, const char *query, unsigned long length)

설명

query 그리고 지정한 캐릭터 라인으로 나타내지는 SQL 쿼리를 실행합니다.이 캐릭터 라인의 길이는 length 아르바이트일 필요가 있습니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세미콜론(‘;＇) 또는 \g (을)를 추가할 필요는 없습니다.

바이너리 데이터에는 '\0' 문자가 포함될 가능성이 있으므로, 그러한 데이터를 포함한 쿼리의 경우는,mysql_query() (이)가 아니고,mysql_real_query() (을)를 사용할 필요가 있습니다 .또,mysql_real_query() (은)는 쿼리 캐릭터 라인에 대해서 strlen() (을)를 호출하지 않기 때문에,mysql_query() 보다 고속으로 동작합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항 11.1.3.20. 「mysql_field_count()」.

반환값

쿼리가 정상적으로 동작했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.46. mysql_reload()

int mysql_reload(MYSQL *mysql)

설명

권한 테이블의 재독 보고 포함을 MySQL 서버에 요구합니다.접속 유저에게는 RELOAD 특권이 필요합니다.

이 함수는 폐지되고 있습니다.대신에,mysql_query() (을)를 사용해 FLUSH PRIVILEGES 스테이트먼트를 발행해 주세요.

반환값

정상 종료했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.47. mysql_row_seek()

MYSQL_ROW_OFFSET mysql_row_seek(MYSQL_RES *result, MYSQL_ROW_OFFSET offset)

설명

쿼리 결과 세트의 임의의 레코드에 로 커서를 설정합니다.offset 의 값은 레코드 오프셋(offset)이며,mysql_row_tell() 또는 mysql_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_data_seek() (을)를 사용합니다.

mysql_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수가 있습니다.

에러

없습니다.

11.1.3.48. mysql_row_tell()

MYSQL_ROW_OFFSET mysql_row_tell(MYSQL_RES *result)

설명

마지막에 실행된 mysql_fetch_row() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_row_seek() 에 인수로서 건네줄 수가 있습니다.

mysql_row_tell()
(은)는,mysql_use_result()
의 다음에는 없고,mysql_store_result()
의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋(offset).

에러

없습니다.

11.1.3.49. mysql_select_db()

int mysql_select_db(MYSQL *mysql, const char *db)

설명

db 로 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

접속 유저가 데이타베이스를 사용하는 권한을 가지는 유저로서 인증되지 않는 경우,mysql_select_db() (은)는 실패합니다.

반환값

정상 종료했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.50. mysql_set_server_option()

int mysql_set_server_option(MYSQL *mysql, enum enum_mysql_set_option option)

설명

접속의 옵션을 유효 또는 무효로 합니다.option 에는 이하의 어느 쪽인가의치를 지정할 수 있습니다.

MYSQL_OPTION_MULTI_STATEMENTS_ON | 복수 스테이트먼트의 서포트를 유효하게 한다.
MYSQL_OPTION_MULTI_STATEMENTS_OFF | 복수 스테이트먼트의 서포트를 무효로 한다.

반환값

정상 종료했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • ER_UNKNOWN_COM_ERROR

    서버가 mysql_set_server_option() (을)를 서포트하고 있지 않았다(서버가 4.1.1 보다 낡은 버젼의 경우)인가, 또는 서버가 설정하려고 한 옵션을 서포트하고 있지 않았다.

11.1.3.51. mysql_shutdown()

int mysql_shutdown(MYSQL *mysql)

설명

데이터 베이스 서버에 슛다운 하도록(듯이) 요구합니다.접속 유저에게는 SHUTDOWN 특권이 필요합니다.

반환값

정상 종료했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.52. mysql_sqlstate()

const char *mysql_sqlstate(MYSQL *mysql)

설명

마지막에 발생한 에러의 SQLSTATE 에러 코드를 포함한 눌 종단 캐릭터 라인을 돌려줍니다.에러 코드는 5 문자로 나타납니다.'00000' (은)는,``에러가 없는''일을 의미합니다.값은 ANSI SQL 및 ODBC 에 의해 규정되고 있습니다.생각되는 값의 일람에 대해서는,항 12.1. 「돌려주어지는 에러」 (을)를 참조해 주세요.

주의: 모든 MySQL 에러가 SQLSTATE 에 매핑 되고 있는 것은 아닙니다.매핑되어 있지 않은 에러의 경우는 'HY000'(일반 에러)가 사용됩니다.

이 함수는 MySQL 4.1.1 으로 추가되었습니다.

반환값

SQLSTATE 에러 코드를 포함한 눌 종단 캐릭터 라인.

관련 항목

See 항 11.1.3.12. 「mysql_errno()」. See
항 11.1.3.13. 「mysql_error()」. See
항 11.1.7.18. 「mysql_stmt_sqlstate()」.

11.1.3.53. mysql_ssl_set()

int mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca, const char *capath, const char *cipher)

설명

mysql_ssl_set() 는, SSL (을)를 사용해, 시큐러티로 보호된 접속을 확립하기 위해서 사용합니다.mysql_real_connect() 의 전에 호출할 필요가 있습니다.

mysql_ssl_set() (은)는, 클라이언트 라이브러리에서 OpenSSL 서포트가 유효하게 되지 않은 경우는 아무것도 하지 않습니다.

mysql 는,mysql_init() (으)로부터 돌려주어진 접속 핸들러입니다.다른 파라미터의 지정 방법을 다음에 나타냅니다.

  • key 파라미터에는, 비밀 키파일에의 패스명을 지정한다.

  • cert 파라미터에는, 증명서 파일에의 패스명을 지정한다.

  • ca 파라미터에는, 인증국 발행의 증명서 파일에의 패스명을 지정한다.

  • capath 파라미터에는, PEM 형식의 신뢰된 CA 증명서가 격납된 디렉토리에의 패스명을 지정한다.

  • cipher 파라미터에는, SSL 암호화에 사용할 수 있는 암호의 일람을 지정한다.

사용하지 않는 SSL 파라미터에는 NULL 를 지정할 수 있습니다.

반환값

이 함수는 항상 0 (을)를 돌려줍니다.SSL 하지만 올바르고 셋업되어 있지 않은 경우, 접속을 시도하면(자) mysql_real_connect() 하지만 에러를 돌려줍니다.

11.1.3.54. mysql_stat()

char *mysql_stat(MYSQL *mysql)

설명

mysqladmin status 커멘드의 출력과 같은 정보를 포함한 캐릭터 라인을 돌려줍니다.이 정보에는, 사용 가능 시간(초단위), 실행중의 thread수, 질문의 수, 재로드 회수, 및 오픈되고 있는 테이블의 수가 포함됩니다.

반환값

서버 스테이터스를 나타내는 캐릭터 라인.에러가 발생했을 경우는 NULL.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.55. mysql_store_result()

MYSQL_RES *mysql_store_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT,SHOW,DESCRIBE,EXPLAIN)에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

다른 쿼리에서는 mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요는 없습니다만, 모든 케이스로 mysql_store_result() (을)를 호출해도, 이상이 발생하거나 눈에 띈 동작을 하는 일은 없습니다.mysql_store_result() 하지만 0 (을)를 돌려주는지 어떤지를 조사하는 것으로, 쿼리로 결과 세트가 생성되었는지 어떠했는지를 검출할 수 있습니다.이것에 대해서는 후술 합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항 11.1.3.20. 「mysql_field_count()」.

mysql_store_result() (은)는, 쿼리의 결과 세트 전체를 클라이언트에 읽어들여,MYSQL_RES 구조체에 메모리를 할당해 이 구조체에 결과 세트를 격납합니다.

쿼리가 결과 세트를 돌려주지 않는 경우(예를 들어, 쿼리가 INSERT 스테이트먼트였던 경우),mysql_store_result() (은)는 누르포인타를 돌려줍니다.

또, 결과 세트의 읽어들여에 실패했을 경우도,mysql_store_result() (은)는 누르포인타를 돌려줍니다.에러가 발생했는지 어떠했는지를 조사하려면 ,mysql_error() 하지만 누르포인타를 돌려주지 않는지 어떤지,mysql_errno() 하지만 0 이외의 값을 돌려주는지 어떤지, 또는 mysql_field_count() 가 0 이외의 값을 돌려주는지 어떤지를 조사합니다.

돌려주는 레코드가 존재하지 않는 경우는 하늘의 결과 세트가 돌려주어집니다(하늘의 결과 세트는, 반환값으로서의 누르포인타와는 다릅니다).

mysql_store_result() (을)를 호출해, 반환값이 누르포인타 이외였던 경우,mysql_num_rows() (을)를 호출하면(자) 결과 세트에 포함되는 레코드수를 취득할 수 있습니다.

mysql_fetch_row() (을)를 호출하면(자), 결과 세트로부터 레코드를 취득할 수 있습니다.mysql_row_seek() 및 mysql_row_tell() (을)를 호출하면(자), 결과 세트내의 경향 레코드의 위치를 설정 및 취득할 수 있습니다.

결과 세트가 필요없게 되면(자),mysql_free_result() (을)를 호출할 필요가 있습니다.

See 항 11.1.12.1. 「mysql_query() 가 정상적으로 종료한 다음에 mysql_store_result() 가 NULL 를 돌려주는 경우가 있는 것은 왠지」.

반환값

결과 세트가 격납된 MYSQL_RES 구조체.에러가 발생했을 경우는 NULL.

에러

mysql_store_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno 를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.56. mysql_thread_id()

unsigned long mysql_thread_id(MYSQL *mysql)

설명

현재의 접속의 thread ID (을)를 돌려줍니다.이 반환값을,mysql_kill() 에 인수로서 건네주어 thread를 강제 종료할 수가 있습니다.

현재의 접속이 절단 되어mysql_ping() (을)를 사용해 재접속했을 경우, thread ID (은)는 다른 값이 됩니다.이것은, 취득한 thread ID (을)를 보관해 다음에 사용할 수 없는 것을 의미합니다.thread ID 하지만 필요하게 되었을 때에, 취득할 필요가 있습니다.

반환값

현재의 접속의 thread ID.

에러

없습니다.

11.1.3.57. mysql_use_result()

MYSQL_RES *mysql_use_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT,SHOW,DESCRIBE,EXPLAIN)에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

mysql_use_result() (은)는, 결과 세트의 취득을 개시합니다만,mysql_store_result() (와)과 같이 실제로 결과 세트를 클라이언트에 읽어들이는 것은 아닙니다.대신에,mysql_fetch_row() (을)를 호출해, 1 행씩 개별적으로 취득할 필요가 있습니다.그 경우, 쿼리의 결과는 직접 서버로부터 읽혀 텐포라리테이불이나 로컬 버퍼에는 격납되지 않습니다.이것은 mysql_store_result() (을)를 사용하는 경우보다 다소 고속으로 있어, 사용하는 메모리도 적어도 됩니다.클라이언트는, 경향 레코드 및 max_allowed_packet 아르바이트까지 증가할 가능성이 있는 통신 버퍼에 메모리를 할당할 뿐입니다.

한편, 각각의 레코드에 대한 클라이언트측에서의 처리량이 많은 경우, 또는 유저가 ^S (을)를 입력할(스크롤을 정지할) 가능성이 있는 화면에 데이터를 출력하는 경우는,mysql_use_result() 의 사용은 피할 필요가 있습니다.그러한 처리의 경우, 서버의 동작이 정지해, 읽어내지고 있는 데이터가 격납되고 있는 테이블을 다른 thread를 갱신할 수 없게 됩니다.

mysql_use_result() (을)를 사용하는 경우,NULL 하지만 돌려주어질 때까지 mysql_fetch_row() (을)를 반복해 호출할 필요가 있습니다.그렇게 하지 않으면 취득되지 않았던 레코드가, 다음에 실행하는 쿼리의 결과 세트의 일부로서 돌려주어집니다.취득되지 않았던 레코드가 남아 있는 경우, C API 는 에러 Commands out of sync; you can't run this command now 를 돌려줍니다.

mysql_use_result()
하지만 돌려준 결과 세트에 대해서
mysql_data_seek(),mysql_row_seek(),mysql_row_tell(),mysql_num_rows(), 또는
mysql_affected_rows()
(을)를 사용할 수 없습니다.또,mysql_use_result()
하지만 완료할 때까지는 다른 쿼리를 발행할 수 없습니다(다만, 모든 레코드를 취득한 다음에 있으면
mysql_num_rows()
(은)는 취득한 레코드의 수를 정확하게 돌려줍니다).

결과 세트가 필요없게 되면(자),mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

MYSQL_RES 구조체.에러가 발생했을 경우는 NULL.

에러

mysql_use_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno 를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.58. mysql_warning_count()

unsigned int mysql_warning_count(MYSQL *mysql)

설명

전회 실행된 SQL 스테이트먼트의 실행중에 발생한 경고수를 돌려줍니다.이 함수는, MySQL 4.1 으로 추가되었습니다.

반환값

경고수.

에러

없습니다.

11.1.3.59. mysql_commit()

my_bool mysql_commit(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 위탁합니다.이 함수는, MySQL 4.1 으로 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.60. mysql_rollback()

my_bool mysql_rollback(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 롤백(rollback) 합니다.이 함수는, MySQL 4.1 으로 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.61. mysql_autocommit()

my_bool mysql_autocommit(MYSQL *mysql, my_bool mode)

설명

mode 가 1 의 경우는 자동 위탁 모드를 유효하게,mode 하지만 0 의 경우는 무효로 합니다.이 함수는, MySQL 4.1 으로 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.62. mysql_more_results()

my_bool mysql_more_results(MYSQL *mysql)

설명

현재 실행하고 있는 쿼리 외에 아직 취득하고 있지 않는 결과 세트가 존재해, 어플리케이션이 mysql_next_result() (을)를 호출해 취득할 필요가 있는 경우는, true (을)를 돌려줍니다.이 함수는, MySQL 4.1 그리고 추가되었습니다.

반환값

취득되어 있지 않은 결과 세트가 존재하는 경우는 TRUE(1).취득되어 있지 않은 결과 세트가 존재하지 않는 경우는 FALSE(0).

주의: 대부분의 경우, 이 함수 대신에 mysql_next_result() (을)를 호출해 취득되어 있지 않은 결과 세트가 있는지 어떤지를 조사해, 존재하는 경우는 다음의 결과 세트를 개시합니다.

See 항 11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」. See 항 11.1.3.63. 「mysql_next_result()」.

에러

없습니다.

11.1.3.63. mysql_next_result()

int mysql_next_result(MYSQL *mysql)

설명

취득되어 있지 않은 결과 세트가 존재하는 경우,mysql_next_result() (은)는 다음의 쿼리의 결과 세트를 읽어들여, 스테이터스를 어플리케이션에 돌려줍니다.이 함수는, MySQL 4.1 으로 추가되었습니다.

주의: 전의 쿼리가 결과 세트를 돌려주고 있었을 경우,mysql_free_result() (을)를 호출할 필요가 있습니다.

mysql_next_result() (을)를 호출한 후, 접속 상태는 다음의 쿼리에 대해 mysql_real_query() (을)를 호출한 후와 같게 됩니다.이것은, 이 함수를 호출한 후, 이 접속으로 mysql_store_result(),mysql_warning_count(),mysql_affected_rows() 등을 호출할 수가 있는 것을 의미합니다.

mysql_next_result() 하지만 에러를 돌려주었을 경우, 다른 스테이트먼트는 실행되지 않습니다.또, 취득되어 있지 않은 결과 세트도 존재하지 않습니다.

See 항 11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」.

반환값

호출이 정상적으로 동작해, 취득하는 결과 세트가 존재하고 있었을 경우는 0, 취득하는 결과 세트가 존재하지 않았던 경우는 -1, 에러가 발생했을 경우는 정의 값.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.예를 들어, 전의 결과 세트로 mysql_use_result() 하지만 불려 가지 않았던 경우에 이 에러가 발생한다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.4. C API 의 Prepared Statements

MySQL 4.1 그럼, 프리페아드스테이트먼트를 사용하기 위한 클라이언트/서버 프로토콜이 제공되고 있습니다.이 기능은,MYSQL_STMT 스테이트먼트 핸들러 데이터 구조체를 사용합니다.프리페아드스테이트먼트의 실행은, 스테이트먼트를 반복해 실행하는 경우에 효율적인 방법입니다.스테이트먼트는, 실행할 준비를 갖추기 위해서(때문에), 우선 해석됩니다.그 후, prepare 함수로부터 돌려주어지는 스테이트먼트 핸들을 사용해, 1 회이상 실행됩니다.

프리페아드스테이트먼트의 실행은, 해석이 1 회 밖에 행해지지 않기 때문에, 스테이트먼트를 직접 여러 차례 실행하는 것보다도 고속으로.스테이트먼트를 직접 실행했을 경우, 그때마다 쿼리의 해석을 합니다.프리페아드스테이트먼트를 실행하는 경우, 네트워크 트래픽도, 파라미터로서 데이터를 송신할 경우에 발생할 뿐(만큼)이므로, 삭감할 수 있습니다.

그 외에도, 프리페아드스테이트먼트의 실행에서는 바이너리 프로토콜을 사용하므로, 클라이언트 및 서버간의 데이터 전송의 효율이 향상한다고 하는 이점이 있습니다.프리페아드스테이트먼트는, 복수 쿼리를 실행할 때의 입력 및 출력의 바인딩도 서포트합니다.

11.1.5. C API 의 Prepared Statement의 데이터형

주의 : 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

프리페아드스테이트먼트는, 주로 MYSQL_STMT 및 MYSQL_BIND 의 각 데이터 구조체를 사용합니다.그 외에, 시간적인 데이터를 전송 하기 위해서 MYSQL_TIME 를 사용합니다.

  • MYSQL_STMT

    이 구조체는, 프리페아드스테이트먼트를 나타낸다.프리페아드스테이트먼트는,mysql_prepare() (을)를 호출해 작성한다.이 함수는,MYSQL_STMT 에의 포인터인 스테이트먼트 핸들을 돌려준다.이 핸들은, 그 후에 불려 가는 모든 스테이트먼트 관련의 함수로 사용된다.

    MYSQL_STMT 구조체의 멤버를 어플리케이션이 사용할 것은 없다.

    1 개의 접속에 복수의 스테이트먼트 핸들을 관련지을 수가 있다.관련짓는 핸들수는, 사용할 수 있는 system resource에 의해 제한된다.

  • MYSQL_BIND

    이 구조체는, 쿼리의 입력(데이터치가 서버에 송신된다) 및 출력(결과치가 서버로부터 돌려주어진다)의 양쪽 모두로 사용된다.입력의 경우,mysql_bind_param() 에 건네주어 파라미터 데이터치를 버퍼에 바인드 해,mysql_execute() 하지만 사용할 수 있도록(듯이) 한다.출력의 경우,mysql_bind_result() 에 건네주어 결과 세트를 버퍼에 바인드 해,mysql_fetch() 그리고 레코드를 취득할 때에 사용할 수 있도록(듯이) 한다.

    MYSQL_BIND 구조체에서는, 이하에 나타내는 멤버를 응용 프로그램을 사용할 수 있다.어느 멤버도 입력 및 출력의 어느 쪽에도 사용하지만, 데이터 전송의 방향에 따라서 다른 목적으로 사용하는 경우가 있다.

    • enum enum_field_types buffer_type

      버퍼의 형태.사용할 수 있다 buffer_type 의 값의 리스트를, 이 섹션의 후반에 나타낸다.입력의 경우,buffer_type (은)는 쿼리 파라미터에 바인드 하는 값의 형태를 나타낸다.출력의 경우, 결과 세트의 버퍼로 받는 값의 형태를 나타낸다.

    • void *buffer

      입력의 경우, 쿼리 파라미터의 데이터치가 보존되는 버퍼에의 포인터.출력의 경우, 결과 세트의 컬럼치를 돌려주는 버퍼에의 포인터.컬럼형이 수치의 경우,buffer (은)는 적절한 C 언어의 형태의 변수에의 포인터로 할 필요가 있다(UNSIGNED 속성을 가지는 컬럼에 변수를 관련짓고 있는 경우, 변수는 C 언어의 unsigned 형태로 할 필요가 있다).컬럼형이 일자 및 시각의 경우,buffer (은)는 MYSQL_TIME 구조체에의 포인터로 할 필요가 있다.컬럼형이 캐릭터 라인 및 바이너리 캐릭터 라인의 경우,buffer (은)는 문자 버퍼에의 포인터로 할 필요가 있다.

    • unsigned long buffer_length

      아르바이트 단위로 나타냈다 *buffer 의 실제의 사이즈.이 값은, 버퍼에 격납할 수 있는 데이터의 최대 사이즈를 나타낸다.C 의 문자 데이터 및 바이너리 데이터의 경우,buffer_length 의 값은,mysql_bind_param() 그리고 사용하는 경우는 *buffer 하지만 가리키는 데이터의 길이, 또는 mysql_bind_result() 그리고 사용하는 경우는 버퍼에 취득할 수 있는 최대 데이터 아르바이트수를 지정한다.

    • unsigned long *length

      unsigned long 변수에의 포인터.*buffer 에 격납하는 데이터의 실제의 아르바이트수를 나타낸다.length (은)는, 격납하는 데이터가 C 의 문자 데이터 또는 바이너리 데이터의 경우에 사용한다.입력 파라미터 데이터를 바인드 하는 경우,length (은)는,*buffer 에 격납하는 파라미터치의 길이를 나타낸다 unsigned long 변수를 가리킨다.이것은 mysql_execute() 그리고 사용된다.length 하지만 누르포인타의 경우, 프로토콜은 모든 문자 데이터 및 바이너리 데이터가 눌로 종단 되고 있으면(자) 가정한다.출력치를 바인드 하는 경우,mysql_fetch() (은)는, 돌려주는 데이터의 컬럼치의 길이를 length 하지만 포인트 하는 변수로 설정한다.

      수치 데이터형 또는 시간적인 데이터형의 경우, 데이터치의 길이는 buffer_type 의 값에 의해 정해지므로,length (은)는 무시된다.

    • my_bool *is_null

      my_bool 변수에의 포인터.값이 NULL 의 경우는 true,NULL 이외의 경우는 false.입력의 경우,*is_null (을)를 true (으)로 설정하는 것에 의해, 쿼리 파라미터로서 NULL 값을 건네주고 있는 것을 나타낸다.출력의 경우, 쿼리가 돌려주는 값이 NULL 때에 레코드를 취득하면(자), 이 값이 true 로 설정된다.

  • MYSQL_TIME

    이 구조체는, 서버와 직접 DATE,TIME,DATETIME, 및 TIMESTAMP 데이터를 송수신 하기 위해서 사용한다.거기에는,MYSQL_BIND 구조체의 buffer_type 멤버를 몇개의 시간을 나타내는 형태로 설정해,buffer 멤버를 MYSQL_TIME 구조체를 포인트 하도록(듯이) 설정한다.

    MYSQL_TIME 구조체의 멤버를 이하에 나타낸다.

    • unsigned int year

      년.

    • unsigned int month

      월.

    • unsigned int day

      일.

    • unsigned int hour

      시.

    • unsigned int minute

      분.

    • unsigned int second

      초.

    • my_bool neg

      시간이 부화도인지를 나타내는 불리언 값 플래그.

    • unsigned long second_part

      초의 소수부.현재는 미사용.

    MYSQL_TIME 구조체의 멤버는, 사용하는 시간적인 형태에 대응하는 부분만큼이 사용된다.year,month, 및 day 의 각 멤버는,DATE,DATETIME, 및 TIMESTAMP 의 값에 사용한다.hour,minute, 및 second 의 각 멤버는,TIME,DATETIME, 및 TIMESTAMP 의 값에 사용한다. See 항 11.1.9. 「C API 에 있어서의 일자치 및 시각치의 취급」.

MYSQL_BIND 구조체의 buffer_type 멤버로 지정할 수 있는 값을 이하의 겉(표)에 나타냅니다.이 표에는, 각각의 buffer_type 의 값에 가장 가까운 SQL 의 데이터형을 나타내, 한층 더 수치형과 시간적인 값의 형태에 대해서는 대응한다 C 의 데이터형도 가리킵니다.

buffer_type 치 | SQL 의 데이터형 | C 의 데이터형
MYSQL_TYPE_TINY | TINYINT | char
MYSQL_TYPE_SHORT | SMALLINT | short int
MYSQL_TYPE_LONG | INT | long int
MYSQL_TYPE_LONGLONG | BIGINT | long long int
MYSQL_TYPE_FLOAT | FLOAT | float
MYSQL_TYPE_DOUBLE | DOUBLE | double
MYSQL_TYPE_TIME | TIME | MYSQL_TIME
MYSQL_TYPE_DATE | DATE | MYSQL_TIME
MYSQL_TYPE_DATETIME | DATETIME | MYSQL_TIME
MYSQL_TYPE_TIMESTAMP | TIMESTAMP | MYSQL_TIME
MYSQL_TYPE_STRING | CHAR |
MYSQL_TYPE_VAR_STRING | VARCHAR |
MYSQL_TYPE_TINY_BLOB | TINYBLOB/TINYTEXT |
MYSQL_TYPE_BLOB | BLOB/TEXT |
MYSQL_TYPE_MEDIUM_BLOB | MEDIUMBLOB/MEDIUMTEXT |
MYSQL_TYPE_LONG_BLOB | LONGBLOB/LONGTEXT |

암묵의 데이터형 변환은 어느 방향에도 행해질 가능성이 있습니다.

11.1.6. C API 의 Prepared Statement 함수의 개요

주의 : 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

여기에서는, 프리페아드스테이트먼트의 처리에 사용할 수 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이후의 섹션으로 설명합니다. See 항 11.1.7. 「C API 의 Prepared Statement 함수의 설명」.

함수 | 설명
mysql_prepare() | SQL 캐릭터 라인을 실행하기 위한 프리컴파일을 실시한다.
mysql_param_count() | 프리페아드스테이트먼트의 파라미터수를 돌려준다.
mysql_get_metadata() | 프리페아드스테이트먼트메타데이타를 결과 세트 형식에서 돌려준다.
mysql_bind_param() | 어플리케이션 데이터 버퍼를, 프리페아드스테이트먼트내의 파라미터 마커에 관련짓는다.
mysql_execute() | 프리페아드스테이트먼트를 실행한다.
mysql_stmt_affected_rows() | 마지막에 실행되었다 UPDATE,DELETE, 또는 INSERT 의 몇개의 쿼리에 의해 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_bind_result() | 어플리케이션 데이터 버퍼를, 결과 세트의 컬럼에 관련짓는다.
mysql_stmt_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_stmt_data_seek() | 스테이트먼트의 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_stmt_row_seek() | mysql_stmt_row_tell() (으)로부터 돌려주어진 값을 오프셋(offset)로서 스테이트먼트의 결과 세트내의 레코드에 시크 한다.
mysql_stmt_row_tell() | 스테이트먼트의 레코드 커서의 위치를 돌려준다.
mysql_stmt_num_rows() | 버퍼에 격납된 스테이트먼트의 결과 세트 전체의 레코드수를 돌려준다.
mysql_fetch() | 결과 세트의 다음의 레코드의 데이터를 취득해, 바인드 된 모든 컬럼의 데이터를 돌려준다.
mysql_stmt_close() | 프리페아드스테이트먼트가 사용하고 있던 메모리를 해방한다.
mysql_stmt_errno() | 마지막에 실행된 스테이트먼트의 에러 번호를 돌려준다.
mysql_stmt_error() | 마지막에 실행된 스테이트먼트의 에러 메세지를 돌려준다.
mysql_stmt_sqlstate() | 마지막에 실행한 스테이트먼트의 SQLSTATE 에러 코드를 돌려준다.
mysql_send_long_data() | long 형 데이터를 분리해 서버에 송신한다.

mysql_prepare()
(을)를 호출해 스테이트먼트 핸들을 프리컴파일 해, 초기화합니다.다음에
mysql_bind_param()
(을)를 호출해 파라미터 데이터를 건네주어,mysql_execute()
(을)를 호출해 쿼리를 실행합니다.mysql_bind_param()
경유로 건네주는 버퍼에 격납한 파라미터치를 변경해,mysql_execute()
(을)를 반복 실행할 수도 있습니다.

쿼리가 SELECT 스테이트먼트의 경우, 또는 결과 세트를 생성하는 그 외의 쿼리의 경우,mysql_prepare() (은)는 mysql_get_metadata() 를 사용해 MYSQL_RES 결과 세트 형식에서 결과 세트의 메타데이타 정보도 돌려줍니다.

결과를 격납하는 버퍼를 mysql_bind_result() (을)를 사용해 건네주는 것에 의해,mysql_fetch() (은)는 자동적으로 그 버퍼에 데이터를 돌려줍니다.여기에서는 1 행씩의 취득을 합니다.

옵션으로서 is_long_data=1 또는 length=MYSQL_LONG_DATA 또는 -2 (을)를 지정했다 MYSQL_BIND 구조체를 mysql_bind_param() 그리고 건네주면(자),mysql_send_long_data() (을)를 사용해 텍스트 데이터 또는 바이너리 데이터를 분리해 서버에 송신할 수 있습니다.

스테이트먼트의 실행이 완료하면(자),mysql_stmt_close() (을)를 호출해 스테이트먼트 핸들을 클로우즈 해, 핸들에 관련 붙일 수 있어 모든 자원을 해방할 필요가 있습니다.

mysql_get_metadata() 를 호출해 SELECT 스테이트먼트의 결과 셋트메타데이타를 취득하고 있었을 경우도,mysql_free_result() (을)를 호출해 해방할 필요가 있습니다.

실행 스텝

스테이트먼트를 프리컴파일 해 실행하려면 , 어플리케이션으로 이하의 스텝에 따라 처리합니다.

  1. SQL 스테이트먼트를 포함한 캐릭터 라인을 파라미터로서 mysql_prepare() (을)를 호출한다.프리컴파일이 정상적으로 종료했을 경우,mysql_prepare() (은)는 유효한 스테이트먼트 핸들러를 어플리케이션에 돌려준다.

  2. 결과 세트를 생성하는 쿼리를 실행하는 경우,mysql_get_metadata() (을)를 호출해 결과 셋트메타데이타를 취득한다.이 메타데이타는 그것 자신이 결과 세트 형식이다.다만, 쿼리가 돌려주는 레코드를 포함한 결과 세트와는 따로 건네받는다.결과 셋트메타데이타에는, 결과 세트에 포함되는 컬럼수 및 각 컬럼에 관한 정보가 포함된다.

  3. mysql_bind_param() (을)를 사용해, 파라미터의 값을 설정한다.모든 파라미터의 값을 설정할 필요가 있다.값이 설정되어 있지 않은 파라미터가 남아 있으면(자), 에러가 돌려주어지거나 예상외의 결과가 발생한다.

  4. mysql_execute() (을)를 호출해 스테이트먼트를 실행한다.

  5. 결과 세트를 생성하는 쿼리를 실행했을 경우,mysql_bind_result() (을)를 호출해, 레코드의 값을 취득하기 위한 데이터 버퍼를 바인드 한다.

  6. mysql_fetch() 를 호출해, 1 행 분의 데이터를 버퍼에 취득한다.모든 레코드의 데이터를 취득할 수 있을 때까지 이것을 반복한다.

  7. 필요에 따라서 스텝 3 에서 6 까지를 반복해, 파라미터의 값을 변경하면서 스테이트먼트를 재실행한다.

mysql_prepare() 하지만 불려 갔을 경우에 실행되는 MySQL 클라이언트/서버의 프로토콜을 이하에 나타냅니다.

  • 서버는 쿼리를 해석해, 스테이트먼트 ID (을)를 할당해, OK 스테이터스를 클라이언트에 답장한다.결과 세트를 생성하는 쿼리의 경우는, 게다가 파라미터의 합계수, 컬럼수, 및 그 메타 정보를 송신한다.이 호출로, 서버는 쿼리의 모든 구문 및 의미를 확인한다.

  • 클라이언트는 이 스테이트먼트 ID (을)를 사용해 그 후의 처리를 실행한다.이 ID (을)를 사용해, 서버는 스테이트먼트 풀중에서 사용하는 스테이트먼트를 식별한다.또, 클라이언트는 스테이트먼트 핸들을 이 ID 에 할당해 핸들을 어플리케이션에 돌려준다.

mysql_execute() 하지만 불려 갔을 경우에 실행되는 MySQL 클라이언트/서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는 스테이트먼트 핸들을 사용해, 서버에 파라미터 데이터를 송신한다.

  • 서버는 클라이언트로부터 건네받은 ID (을)를 사용해 스테이트먼트를 식별해, 파라미터 마커를 새롭게 건네받은 데이터에 옮겨놓아 쿼리를 실행한다.결과 세트를 생성하는 쿼리를 실행했을 경우, 서버는 데이터를 클라이언트에 답장한다.결과 세트를 생성하지 않는 쿼리를 실행했을 경우, 서버는 OK 스테이터스 및 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려준다.

mysql_fetch() 하지만 불려 갔을 경우에 실행되는 MySQL 클라이언트/서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는, 패킷으로부터 1 행분씩 데이터를 읽어들여, 필요에 따라서 데이터 변환하면서 어플리케이션 데이터 버퍼에 격납한다.어플리케이션 버퍼의 형태가 서버로부터 돌려주어진 필드의 형태와 같은 경우는, 직접적으로 변환을 한다.

mysql_stmt_errno(),mysql_stmt_error(), 및 mysql_stmt_sqlstate() (을)를 사용하면(자), 각각 스테이트먼트의 에러 코드, 에러 메세지, 및 SQLSTATE 치를 취득할 수 있습니다.

11.1.7. C API 의 Prepared Statement 함수의 설명

쿼리를 프리컴파일 해 실행하려면 , 이하의 함수를 사용합니다.

11.1.7.1. mysql_prepare()

MYSQL_STMT * mysql_prepare(MYSQL *mysql, const char *query, unsigned long length)

설명

눌 종단 캐릭터 라인 query 그리고 지정된 SQL 쿼리를 프리컴파일 해, 그 후의 처리에 사용하는 스테이트먼트 핸들을 돌려줍니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세미콜론(‘;＇) 또는 \g (을)를 추가할 필요는 없습니다.

어플리케이션은, SQL 캐릭터 라인의 적당한 위치에 물음표(‘?＇)(을)를 묻는 것으로, SQL 스테이트먼트로 1 개이상의 파라미터 마커를 사용할 수 있습니다.

마커는, SQL 스테이트먼트의 특정의 위치에 파묻혔을 경우에게만 적정하게 처리됩니다.예를 들어, 마커는 INSERT 스테이트먼트의 VALUES() 의 리스트로 레코드로 설정하는 컬럼의 값을 지정하는 부분, 또는 WHERE 마디로 컬럼의 값과 비교하는 값을 지정하는 부분에 사용할 수 있습니다.그러나,SELECT 스테이트먼트가 돌려주는 컬럼을 지정하는 선택 리스트로 식별자(테이블 또는 컬럼의 이름등)로서 사용하거나 등호(=)등의 바이너리 연산자의 양쪽 모두의 오퍼랜드를 지정할 수 없습니다.파라미터의 형태를 결정할 수가 없기 때문에, 후자의 제약이 필요하게 됩니다.일반적으로, 파라미터는, 데이터 조작 언어(DML) 스테이트먼트에서만 적정하게 처리되어 데이터 정의 언어(DDL) 스테이트먼트에서는 처리되지 않습니다.

파라미터 마커는, 스테이트먼트를 실행하기 전에,mysql_bind_param() (을)를 사용해 어플리케이션 변수에 바인드 할 필요가 있습니다.

반환값

컴파일이 정상적으로 종료했을 경우는 MYSQL_STMT 구조체에의 포인터.에러가 발생했을 경우는 NULL.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

컴파일이 실패했을 경우(mysql_prepare() 하지만 NULL (을)를 돌려주었을 경우), 에러 메세지는 mysql_error() (을)를 호출하는 것에 의해 취득할 수 있습니다.

례

mysql_prepare() 의 사용 방법에 대해서는,항 11.1.7.5. 「mysql_execute()」 의 「예」를 참조해 주세요.

11.1.7.2. mysql_param_count()

unsigned long mysql_param_count(MYSQL_STMT *stmt)

설명

프리컴파일 된 스테이트먼트에 포함되는 파라미터 마커의 수를 돌려줍니다.

반환값

스테이트먼트에 포함되는 파라미터수를 나타낸다 unsigned long 정수.

에러

없습니다.

례

mysql_param_count() 의 사용 방법에 대해서는,항 11.1.7.5. 「mysql_execute()」 의 「예」를 참조해 주세요.

11.1.7.3. mysql_get_metadata()

MYSQL_RES *mysql_get_metadata(MYSQL_STMT *stmt)

설명

mysql_prepare() 에게 건네진 스테이트먼트가 결과 세트를 생성하는 것인 경우,mysql_get_metadata() (은)는 MYSQL_RES 구조체에의 포인터라고 하는 형태로 결과 셋트메타데이타를 돌려줍니다.이 구조체를 사용해, 필드의 합계수 및 개개의 필드 정보등의 메타 정보를 처리할 수 있습니다.이 결과 세트에의 포인터는, 결과 셋트메타데이타를 처리하는 이하의 필드 베이스의 API 함수에 인수로서 건네줄 수가 있습니다.

  • mysql_num_fields()

  • mysql_fetch_field()

  • mysql_fetch_field_direct()

  • mysql_fetch_fields()

  • mysql_field_count()

  • mysql_field_seek()

  • mysql_field_tell()

  • mysql_free_result()

결과 세트 구조체는, 사용할 필요가 없어지면(자) mysql_free_result() 에 건네주어 해방할 필요가 있습니다.이것은,mysql_store_result() (을)를 호출해 취득한 결과 세트를 해방하는 방법과 닮아 있습니다.

mysql_get_metadata() (으)로부터 돌려주어지는 결과 세트에는, 메타데이타만이 포함됩니다.레코드 데이터는 포함되지 않습니다.레코드를 취득하려면 , 스테이트먼트 핸들을 파라미터로서 mysql_fetch() 를 호출합니다.

반환값

MYSQL_RES 구조체.프리컴파일 한 쿼리의 메타 정보가 존재하지 않는 경우는 NULL.

에러

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_get_metadata() 의 사용 방법에 대해서는,항 11.1.7.13. 「mysql_fetch()」 의 「예」를 참조해 주세요.

11.1.7.4. mysql_bind_param()

my_bool mysql_bind_param(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_param() (은)는,mysql_prepare() 에게 건네진 SQL 스테이트먼트에 포함되는 파라미터 마커의 데이터를 바인드 하기 위해서 사용합니다.데이터는 MYSQL_BIND 구조체를 사용해 건네줍니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 쿼리에 포함되는 각 ‘?＇ 파라미터에 대응하는 요소가 포함되어 있으면(자) 가정합니다.

예를 들어, 이하의 스테이트먼트를 프리컴파일 한다고 합니다.

INSERT INTO mytbl VALUES(?,?,?)

파라미터를 바인드 하는 경우,MYSQL_BIND 구조체에는 3 개의 요소가 필요하고, 이하와 같이 선언할 수 있습니다.

MYSQL_BIND bind[3];

설정할 필요가 있는 MYSQL_BIND 의 각 요소의 멤버에 대해서는,항 11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_NO_PARAMETERS_EXISTS

    바인드 하는 파라미터가 존재하지 않는다.

  • CR_INVALID_BUFFER_USE

    이것이 long 데이터를 분리해 건네주기 위한 바인드인가, 및 버퍼의 형태가 캐릭터 라인 이외 또는 바이너리 이외인지를 나타낸다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_param() 의 사용 방법에 대해서는,항 11.1.7.5. 「mysql_execute()」 의 「예」를 참조해 주세요.

11.1.7.5. mysql_execute()

int mysql_execute(MYSQL_STMT *stmt)

설명

mysql_execute() (은)는, 스테이트먼트 핸들에 관련지을 수 있고 있는 프리컴파일 된 쿼리를 실행합니다.이 호출 시에, 현재 바인드 되고 있는 파라미터 마커의 값이 서버에 송신되어 서버는 마커를 여기서 건네받은 데이터로 옮겨놓습니다.

스테이트먼트가 UPDATE,DELETE, 또는 INSERT 의 경우,mysql_stmt_affected_rows() (을)를 호출하는 것에 의해, 변경, 삭제, 또는 삽입된 레코드의 합계수를 취득할 수 있습니다.이것이 SELECT 등의 결과 세트를 생성하는 쿼리의 경우, 최초로 mysql_fetch() (을)를 호출해 데이터를 취득하고 나서, 다른 쿼리 처리를 필요로 하는 함수를 호출할 필요가 있습니다.결과를 취득하는 방법의 상세한 것에 대하여는,항 11.1.7.13. 「mysql_fetch()」 (을)를 참조해 주세요.

반환값

정상적으로 실행했을 경우는 0.에러가 발생했을 경우는 0 이외.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해 취득할 수 있습니다.

에러

  • CR_NO_PREPARE_QUERY

    실행하기 전에 프리컴파일 된 쿼리가 존재하지 않는다.

  • CR_ALL_PARAMS_NOT_BOUND

    건네받지 않은 파라미터 데이터가 있다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

이하의 예에서는,mysql_prepare(),mysql_param_count(),mysql_bind_param(),mysql_execute(), 및 mysql_stmt_affected_rows() (을)를 사용해, 테이블을 작성해, 데이터를 삽입하는 방법을 나타냅니다.mysql 변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define DROP_SAMPLE_TABLE "DROP TABLE IF EXISTS test_table"
#define CREATE_SAMPLE_TABLE "CREATE TABLE test_table(col1 INT,\
                                                 col2 VARCHAR(40),\
                                                 col3 SMALLINT,\
                                                 col4 TIMESTAMP)"
#define INSERT_SAMPLE "INSERT INTO test_table(col1, col2, col3) VALUES(?,?,?)"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[3];
my_ulonglong  affected_rows;
int           param_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
unsigned long str_length;
my_bool       is_null;

if (mysql_query(mysql, DROP_SAMPLE_TABLE))
{
  fprintf(stderr, " DROP TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

if (mysql_query(mysql, CREATE_SAMPLE_TABLE))
{
  fprintf(stderr, " CREATE TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

/* Prepare an INSERT query with 3 parameters */
/* (the TIMESTAMP column is not named; it will */
/* be set to the current date and time) */
stmt = mysql_prepare(mysql, INSERT_SAMPLE, strlen(INSERT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), INSERT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, INSERT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in INSERT: %d\n", param_count);

if (param_count != 3) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Bind the data for all 3 parameters */

/* INTEGER PARAM */
/* This is a number type, so there is no need to specify buffer_length */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *) &int_data;
bind[0].is_null= 0;
bind[0].length= 0;

/* STRING PARAM */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *) str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= 0;
bind[1].length= &str_length;

/* SMALLINT PARAM */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *) &small_data;
bind[2].is_null= &is_null;
bind[2].length= 0;

/* Bind the buffers */
if (mysql_bind_param(stmt, bind))
{
  fprintf(stderr, " mysql_bind_param() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Specify the data values for the first row */
int_data= 10;             /* integer */
strncpy(str_data, "MySQL", STRING_SIZE); /* string  */
str_length= strlen(str_data);

/* INSERT SMALLINT data as NULL */
is_null= 1;

/* Execute the INSERT statement - 1*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), 1 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total number of affected rows */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 1): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Specify data values for second row, then re-execute the statement */
int_data= 1000;
strncpy(str_data, "The most popular open source database", STRING_SIZE);
str_length= strlen(str_data);
small_data= 1000;         /* smallint */
is_null= 0;               /* reset */

/* Execute the INSERT statement - 2*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute, 2 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total rows affected */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 2): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Close the statement */
if (mysql_stmt_close(stmt))
{
  fprintf(stderr, " failed while closing the statement\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

주의 : Prepared Statement 함수를 사용한 완전한 예에 대해서는, 파일 tests/mysql_client_test.c (을)를 참조해 주세요.이 파일은, MySQL 소스 디스트리뷰션 또는 BitKeeper 소스 리포지터리(repository)로부터 취득할 수 있습니다.

11.1.7.6. mysql_stmt_affected_rows()

my_ulonglong mysql_stmt_affected_rows(MYSQL_STMT *stmt)

설명

마지막에 실행된 스테이트먼트에 의해 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려줍니다.UPDATE,DELETE, 또는 INSERT 의 몇개의 스테이트먼트에 대해서 mysql_execute() (을)를 호출한 직후에 불려 갈 가능성이 있습니다.SELECT 스테이트먼트의 경우,mysql_stmt_affected_rows() (을)를 호출하면(자),mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타냅니다.－1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_fetch() 를 호출하기 전에 mysql_stmt_affected_rows() 하지만 불려 간 것을 나타냅니다.

에러

없습니다.

례

mysql_stmt_affected_rows() 의 사용 방법에 대해서는,항 11.1.7.5. 「mysql_execute()」 의 「예」를 참조해 주세요.

11.1.7.7. mysql_bind_result()

my_bool mysql_bind_result(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_result() (은)는, 결과 세트의 컬럼을 데이터 버퍼 및 길이 버퍼에 관련짓는(바인드 한다) 위해(때문에) 사용합니다.mysql_fetch() (을)를 호출해 데이터를 취득하는 경우, MySQL 클라이언트/서버 프로토콜에 의해, 바인드 된 컬럼의 데이터가 지정된 버퍼에 기입해집니다.

주의: mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 결과 세트의 각 컬럼에 대응한 요소가 포함되어 있으면(자) 가정합니다.요소가 포함되지 않은 경우,mysql_fetch() (은)는 단지 데이터를 취득하지 않습니다.또, 클라이언트/서버 프로토콜은 데이터의 값을 분리해 돌려주지는 않기 때문에, 버퍼의 사이즈는 데이터치를 격납 가능한 한의 충분한 크기일 필요가 있습니다.

컬럼은, 임의의 시점에서, 결과 세트의 일부만이 취득된 다음에도, 바인드 또는 재바인드 할 수가 있습니다.새롭게 바인드 했을 경우, 그것이 유효하게 되는 것은, 다음에 mysql_fetch() (을)를 호출했을 때입니다.예를 들어, 어플리케이션이 결과 세트의 컬럼을 바인드 해 mysql_fetch() (을)를 호출한다고 합니다.클라이언트/서버 프로토콜은, 바인드 된 버퍼에 데이터를 돌려줍니다.다음에 어플리케이션이 컬럼을 다른 버퍼에 바인드 한다고 합니다.프로토콜은, 다음에 mysql_fetch() 하지만 불려 갈 때까지, 새롭고 바인드 된 버퍼에 데이터를 기입하지 않습니다.

컬럼을 바인드 하려면 , 어플리케이션은 mysql_bind_result() (을)를 호출해, 형태, 주소, 및 길이 버퍼의 주소를 건네줍니다.설정할 필요가 있다 MYSQL_BIND 의 각 요소의 멤버에 대해서는,항 11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_result() 의 사용 방법에 대해서는,항 11.1.7.13. 「mysql_fetch()」 의 「예」를 참조해 주세요.

11.1.7.8. mysql_stmt_store_result()

int mysql_stmt_store_result(MYSQL_STMT *stmt)

설명

쿼리가 결과 세트를 정상적으로 생성해(SELECT,SHOW,DESCRIBE,EXPLAIN), 한층 더 클라이언트의 버퍼에 결과 세트 전체를 격납해, 그 후의 mysql_fetch() 의 호출로 버퍼 된 데이터가 돌려주어지도록(듯이) 하는 경우에 한정해,mysql_stmt_store_result() (을)를 호출할 필요가 있습니다.

그러한 쿼리 이외에서는 mysql_stmt_store_result() (을)를 호출할 필요는 없습니다만, 호출했다고 해도 이상이 발생하거나 눈에 띈 동작을 하는 일은 일절 없습니다.mysql_get_metadata() 하지만 NULL (을)를 돌려주는지 어떤지를 조사하는 것으로, 쿼리가 결과 세트를 생성했는지 어떠했는지를 검출할 수 있습니다.상세한 것에 대하여는,항 11.1.7.3. 「mysql_get_metadata()」 (을)를 참조해 주세요.

반환값

결과 세트가 정상적으로 버퍼에 격납되었을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.7.9. mysql_stmt_data_seek()

void mysql_stmt_data_seek(MYSQL_STMT *stmt, my_ulonglong offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_stmt_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_stmt_data_seek() (을)를 사용하려면 , 스테이트먼트의 결과 세트 구조체에 마지막에 실행된 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.7.10. mysql_stmt_row_seek()

MYSQL_ROW_OFFSET mysql_stmt_row_seek(MYSQL_STMT *stmt, MYSQL_ROW_OFFSET offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 레코드 커서를 설정합니다.offset 의 값은 레코드 오프셋(offset)이며,mysql_stmt_row_tell() 또는 mysql_stmt_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_stmt_data_seek() (을)를 사용합니다.

mysql_stmt_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_stmt_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수가 있습니다.

에러

없습니다.

11.1.7.11. mysql_stmt_row_tell()

MYSQL_ROW_OFFSET mysql_stmt_row_tell(MYSQL_STMT *stmt)

설명

마지막에 실행된 mysql_fetch() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_stmt_row_seek() 에 인수로서 건네줄 수가 있습니다.

mysql_stmt_row_tell() (은)는,mysql_stmt_store_result() 의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋(offset).

에러

없습니다.

11.1.7.12. mysql_stmt_num_rows()

my_ulonglong mysql_stmt_num_rows(MYSQL_STMT *stmt)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_stmt_num_rows() (을)를 사용할지 어떨지는,mysql_stmt_store_result() (을)를 사용해 결과 세트 전체를 스테이트먼트 핸들에 격납했는지 어떠했는지에 의해 정해집니다.

mysql_stmt_store_result() (을)를 사용하는 경우, 곧바로 mysql_stmt_num_rows() (을)를 호출할 수가 있습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.7.13. mysql_fetch()

int mysql_fetch(MYSQL_STMT *stmt)

설명

mysql_fetch() (은)는, 결과 세트의 다음의 레코드를 취득합니다.이 함수는 결과 세트가 존재하는 동안만, 즉,mysql_execute() (을)를 호출해 결과 세트를 작성한 후, 또는 mysql_execute() (을)를 호출해 결과 세트 전체를 버퍼에 격납하고 나서 mysql_stmt_store_result() (을)를 호출한 후에게만, 호출할 수가 있습니다.

mysql_fetch() (은)는,mysql_bind_result() (을)를 호출해 바인드 한 버퍼를 사용해 레코드 데이터를 돌려줍니다.버퍼에는, 현재의 레코드 세트의 모든 컬럼의 데이터가 격납됩니다.데이터의 길이는 length 포인터에 돌려주어집니다.

주의: 어플리케이션은,mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.

취득한 데이터가 NULL 값이었던 경우, 대응한다 MYSQL_BIND 구조체의 *is_null 의 값에는 TRUE(1)가 격납됩니다.그 이외의 값이었던 경우, 어플리케이션이 지정한 버퍼의 형태에 근거해, 데이터 및 그 길이가 각각 *buffer 요소 및 *length 요소에 돌려주어집니다.수치형 및 시간적인 값의 형태는, 이하의 겉(표)에 나타내도록(듯이), 각각 고정장입니다.캐릭터 라인형의 길이는, 실제의 데이터의 길이에 의해 정해져,data_length 에 의해 나타내집니다.

형태 | 길이
MYSQL_TYPE_TINY | 1
MYSQL_TYPE_SHORT | 2
MYSQL_TYPE_LONG | 4
MYSQL_TYPE_LONGLONG | 8
MYSQL_TYPE_FLOAT | 4
MYSQL_TYPE_DOUBLE | 8
MYSQL_TYPE_TIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATE | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATETIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_STRING | data length
MYSQL_TYPE_BLOB | data_length

반환값

반환값 | 설명
0 | 정상.데이터는 어플리케이션 데이터 버퍼에 취득되고 있다.
1 | 에러가 발생했다.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해 취득할 수 있다.
MYSQL_NO_DATA | 취득되어 있지 않은 레코드/데이터는 남지 않았다.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • CR_UNSUPPORTED_PARAM_TYPE

    버퍼의 형태는 MYSQL_TYPE_DATE,MYSQL_TYPE_TIME,MYSQL_TYPE_DATETIME, 또는 MYSQL_TYPE_TIMESTAMP 그런데, 데이터의 형태는 DATE,TIME,DATETIME, 또는 TIMESTAMP 의 머지않아도 아니다.

  • 그 외의 서포트되어 있지 않은 변환에 관한 에러는 모두 mysql_bind_result() (으)로부터 돌려주어진다.

례

이하의 예에서는,mysql_get_metadata(),mysql_bind_result(), 및 mysql_fetch() (을)를 사용해, 테이블에서 데이터를 취득하는 방법을 나타냅니다(이 예에서는 항 11.1.7.5. 「mysql_execute()」 의 예로 삽입된 2 행의 레코드를 취득하는 것과 상정하고 있습니다).mysql 변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define SELECT_SAMPLE "SELECT col1, col2, col3, col4 FROM test_table"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[4];
MYSQL_RES     *prepare_meta_result;
MYSQL_TIME    ts;
unsigned long length[4];
int           param_count, column_count, row_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
my_bool       is_null[4];

/* Prepare a SELECT query to fetch data from test_table */
stmt = mysql_prepare(mysql, SELECT_SAMPLE, strlen(SELECT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), SELECT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, SELECT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in SELECT: %d\n", param_count);

if (param_count != 0) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Fetch result set meta information */
prepare_meta_result = mysql_get_metadata(stmt);
if (!prepare_meta_result)
{
  fprintf(stderr, " mysql_get_metadata(), returned no meta information\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get total columns in the query */
column_count= mysql_num_fields(prepare_meta_result);
fprintf(stdout, " total columns in SELECT statement: %d\n", column_count);

if (column_count != 4) /* validate column count */
{
  fprintf(stderr, " invalid column count returned by MySQL\n");
  exit(0);
}

/* Execute the SELECT query */
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Bind the result buffers for all 4 columns before fetching them */

/* INTEGER COLUMN */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *) &int_data;
bind[0].is_null= &is_null[0];
bind[0].length= &length[0];

/* STRING COLUMN */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *) str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= &is_null[1];
bind[1].length= &length[1];

/* SMALLINT COLUMN */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *) &small_data;
bind[2].is_null= &is_null[2];
bind[2].length= &length[2];

/* TIMESTAMP COLUMN */
bind[3].buffer_type= MYSQL_TYPE_TIMESTAMP;
bind[3].buffer= (char *) &ts;
bind[3].is_null= &is_null[3];
bind[3].length= &length[3];

/* Bind the result buffers */
if (mysql_bind_result(stmt, bind))
{
  fprintf(stderr, " mysql_bind_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Now buffer all results to client */
if (mysql_stmt_store_result(stmt))
{
  fprintf(stderr, " mysql_stmt_store_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Fetch all rows */
row_count= 0;
fprintf(stdout, "Fetching results ...\n");
while (!mysql_fetch(stmt))
{
  row_count++;
  fprintf(stdout, "  row %d\n", row_count);

  /* column 1 */
  fprintf(stdout, "   column1 (integer)  : ");
  if (is_null[0])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %d(%ld) \n", int_data, length[0]);

  /* column 2 */
  fprintf(stdout, "   column2 (string)   : ");
  if (is_null[1])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %s(%ld) \n", str_data, length[1]);

  /* column 3 */
  fprintf(stdout, "   column3 (smallint) : ");
  if (is_null[2])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %d(%ld) \n", small_data, length[2]);

  /* column 4 */
  fprintf(stdout, "   column4 (timestamp): ");
  if (is_null[3])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %04d-%02d-%02d %02d:%02d:%02d (%ld) \n",
                                               ts.year, ts.month, ts.day,
                                               ts.hour, ts.minute, ts.second,
                                               length[3]);
  fprintf(stdout, "\n");
}

/* Validate rows fetched */
fprintf(stdout, " total rows fetched: %d\n", row_count);
if (row_count != 2)
{
  fprintf(stderr, " MySQL failed to return all rows\n");
  exit(0);
}

/* Free the prepared result metadata */
mysql_free_result(prepare_meta_result);

/* Close the statement */
if (mysql_stmt_close(stmt))
{
  fprintf(stderr, " failed while closing the statement\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

11.1.7.14. mysql_send_long_data()

my_bool mysql_send_long_data(MYSQL_STMT *stmt, unsigned int parameter_number, const char *data, unsigned long length)

설명

어플리케이션은 이 함수를 사용해, 파라미터 데이터를 개별적으로(또는 ``분리해'') 서버에 송신할 수 있습니다.이 함수를 여러 차례 호출하는 것에 의해,TEXT 또는 BLOB 의 어느 쪽인가의 데이터형의 컬럼의 문자 데이터치 또는 바이너리 데이터치를 여러 차례로 나누어 송신할 수가 있습니다.

parameter_number (은)는, 데이터를 관련짓는 파라미터를 나타내는 번호입니다.파라미터의 번호는 0 으로부터 시작됩니다.data (은)는 송신 데이터를 포함한 버퍼에의 포인터를,length (은)는 버퍼내의 데이터의 아르바이트수를 나타냅니다.

반환값

데이터를 서버에 정상적으로 송신할 수 있었을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_INVALID_PARAMETER_NO

    무효인 파라미터 번호가 지정되었다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

이하의 예에서는,TEXT 형태 컬럼의 데이터를 분리해 송신하는 방법을 나타냅니다.여기에서는, 데이터치 'MySQL - The most popular open source database' 를 text_column 컬럼에 삽입합니다.mysql 변수는 유효한 접속 핸들로 합니다.

#define INSERT_QUERY "INSERT INTO test_long_data(text_column) VALUES(?)"

MYSQL_BIND bind[1];
long       length;

if (!mysql_prepare(mysql, INSERT_QUERY, strlen(INSERT_QUERY))
{
  fprintf(stderr, "\n prepare failed");
  fprintf(stderr, "\n %s", mysql_error(mysql));
  exit(0);
}
 memset(bind, 0, sizeof(bind));
 bind[0].buffer_type= MYSQL_TYPE_STRING;
 bind[0].length= &length;
 bind[0].is_null= 0;

/* Bind the buffers */
if (mysql_bind_param(stmt, bind))
{
  fprintf(stderr, "\n param bind failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Supply data in chunks to server */
 if (!mysql_send_long_data(stmt, 0,"MySQL", 5))
{
  fprintf(stderr, "\n send_long_data failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Supply the next piece of data */
 if (mysql_send_long_data(stmt, 0," - The most popular open source database", 40))
{
  fprintf(stderr, "\n send_long_data failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Now, execute the query */
 if (mysql_execute(stmt))
{
  fprintf(stderr, "\n mysql_execute failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

11.1.7.15. mysql_stmt_close()

my_bool mysql_stmt_close(MYSQL_STMT *)

설명

프리페아드스테이트먼트를 클로우즈 합니다.mysql_stmt_close() 그럼,stmt 하지만 가리키는 스테이트먼트 핸들에 할당할 수 있었던 메모리도 해방됩니다.

현재의 스테이트먼트의 결과 세트의 처리가 도중인가, 또는 취득되어 있지 않은 레코드가 남아 있는 경우, 이 함수를 호출하면(자), 그 상태를 캔슬해, 다음의 쿼리를 실행할 수 있도록(듯이) 합니다.

반환값

스테이트먼트가 정상적으로 해방되었을 경우는 0.에러가 발생했을 경우는 0 이외.

에러

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_stmt_close() 의 사용 방법에 대해서는,항 11.1.7.5. 「mysql_execute()」 의 「예」를 참조해 주세요.

11.1.7.16. mysql_stmt_errno()

unsigned int mysql_stmt_errno(MYSQL_STMT *stmt)

설명

mysql_stmt_errno() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 스테이트먼트 API 함수의 에러 코드를 돌려줍니다.반환값이 0 의 경우, 에러는 발생하고 있지 않습니다.클라이언트의 에러 메세지 번호의 일람은, MySQL errmsg.h 헤더 파일에 기술되고 있습니다.서버의 에러 메세지 번호의 일람은,mysqld_error.h 에 기술되고 있습니다.MySQL 소스 디스트리뷰션에 포함되는 파일 Docs/mysqld_error.txt 에는, 모든 에러 메세지 및 에러 번호의 일람이 기술되고 있습니다.서버의 에러 코드의 일람은,항 12.1. 「돌려주어지는 에러」 에도 기재되어 있습니다.

반환값

에러 코드의 값.에러가 발생하고 있지 않는 경우는 0.

에러

없습니다.

11.1.7.17. mysql_stmt_error()

const char *mysql_stmt_error(MYSQL_STMT *stmt)

설명

mysql_stmt_error() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 스테이트먼트 API 함수의 에러 메세지를 포함한 눌 종단 캐릭터 라인을 돌려줍니다.에러가 발생하고 있지 않는 경우는 공문자열("")을 돌려줍니다.이것은, 다음의 2 개의 비교는 등가인 것을 의미합니다.

if (mysql_stmt_errno(stmt))
{
  // an error occurred
}

if (mysql_stmt_error(stmt)[0])
{
  // an error occurred
}

클라이언트의 에러 메세지의 언어는, MySQL 클라이언트 라이브러리를 재컴파일 하는 것에 의해 변경할 수 있습니다.현재는, 복수가 다른 언어로 에러 메세지를 돌려줄 수가 있습니다.

반환값

에러의 내용을 설명하는 캐릭터 라인.에러가 발생하고 있지 않는 경우는 공문자열.

에러

없습니다.

11.1.7.18. mysql_stmt_sqlstate()

const char *mysql_stmt_sqlstate(MYSQL_STMT *stmt)

설명

mysql_stmt_sqlstate() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 프리페아드스테이트먼트 API 함수의 SQLSTATE 에러 코드를 포함한 눌 종단 캐릭터 라인을 돌려줍니다.에러 코드는 5 문자로 나타납니다."00000" (은)는,``에러가 없는''일을 의미합니다.값은 ANSI SQL 및 ODBC 에 의해 규정되고 있습니다.생각되는 값의 일람에 대해서는,항 12.1. 「돌려주어지는 에러」 (을)를 참조해 주세요.

주의: 모든 MySQL 에러가 SQLSTATE 에 매핑 되고 있는 것은 아닙니다.매핑되어 있지 않은 에러의 경우는 "HY000"(일반 에러)가 사용됩니다.

이 함수는 MySQL 4.1.1 으로 추가되었습니다.

반환값

SQLSTATE 에러 코드를 포함한 눌 종단 캐릭터 라인.

11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급

MySQL 는, 버젼 4.1 에서 1 개의 쿼리 캐릭터 라인으로 지정된 복수 스테이트먼트의 실행을 서포트합니다.접속으로 이 기능을 사용하려면 , 접속을 오픈할 경우에 mysql_real_connect() 의 플래그 파라미터로 CLIENT_MULTI_STATEMENTS 옵션을 지정할 필요가 있습니다.이 옵션은,mysql_set_server_option(MYSQL_OPTION_MULTI_STATEMENTS_ON) (을)를 호출하는 것으로, 접속에 대해서 설정할 수도 있습니다.

디폴트에서는,mysql_query() 및 mysql_real_query() (은)는 최초의 쿼리의 스테이터스만을 돌려줍니다.그 후의 쿼리의 스테이터스는 mysql_more_results() 및 mysql_next_result() (을)를 사용해 처리할 수 있습니다.

/* Connect to server with option CLIENT_MULTI_STATEMENTS */
mysql_real_connect(..., CLIENT_MULTI_STATEMENTS);

/* Now execute multiple queries */
mysql_query(mysql,"DROP TABLE IF EXISTS test_table;\
                   CREATE TABLE test_table(id INT);\
                   INSERT INTO test_table VALUES(10);\
                   UPDATE test_table SET id=20 WHERE id=10;\
                   SELECT * FROM test_table;\
                   DROP TABLE test_table";
do
{
  /* Process all results */
  ...
  printf("total affected rows: %lld", mysql_affected_rows(mysql));
  ...
  if (!(result= mysql_store_result(mysql)))
  {
     printf(stderr, "Got fatal error processing query\n");
     exit(1);
  }
  process_result_set(result);	/* client function */
  mysql_free_result(result);
} while (!mysql_next_result(mysql));

11.1.9. C API 에 있어서의 일자치 및 시각치의 취급

MySQL 4.1 그리고 도입된 새로운 바이너리 프로토콜을 사용하면(자),MYSQL_TIME 구조체를 사용해 일자 및 시각에 관한 값(DATE,TIME,DATETIME, 및 TIMESTAMP)를 송수신 할 수 있습니다.이 구조체의 멤버에 대해서는,항 11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

시간적인 데이터를 송신하려면 ,mysql_prepare() (을)를 사용해 프리페아드스테이트먼트를 작성합니다.다음에 mysql_execute() (을)를 호출해 스테이트먼트를 실행하기 전에, 이하의 순서를 실행해 시간적인 파라미터를 설정합니다.

  1. 데이터치에 관련지을 수 있었다 MYSQL_BIND 구조체의 멤버 buffer_type 에, 송신하는 시간적인 값의 형태를 나타내는 값을 설정한다.DATE,TIME,DATETIME, 또는 TIMESTAMP 의 값의 경우,buffer_type 에 MYSQL_TYPE_DATE,MYSQL_TYPE_TIME,MYSQL_TYPE_DATETIME, 또는 MYSQL_TYPE_TIMESTAMP (을)를 각각 설정한다.

  2. MYSQL_BIND 구조체의 멤버 buffer 에, 시간적인 값이 격납되고 있다 MYSQL_TIME 구조체의 주소를 설정한다.

  3. 시간적인 값의 형태에 맞추어 MYSQL_TIME 구조체의 필요한 멤버의 값을 설정한다.

mysql_bind_param() (을)를 사용해 파라미터 데이터를 스테이트먼트에 바인드 합니다.이것으로 mysql_execute() (을)를 호출할 준비가 완료합니다.

시간적인 값을 취득하는 순서는 거의 같습니다만,buffer_type 멤버에는 취득하려고 하는 값의 형태를 설정하는 점, 및 buffer 멤버에는 돌려주어지는 값을 격납한다 MYSQL_TIME 구조체의 주소를 설정하는 점이 다릅니다.mysql_execute() (을)를 호출한 후, 결과를 취득할 때까지 에,mysql_bind_results() (을)를 호출해, 버퍼를 스테이트먼트에 바인드 합니다.

이하의 예에서는,DATE,TIME, 및 TIMESTAMP 의 형태의 데이터를 삽입하는 방법을 나타냅니다.mysql 변수는 유효한 접속 핸들로 합니다.

MYSQL_TIME  ts;
MYSQL_BIND  bind[3];
MYSQL_STMT  *stmt;

  strmov(query, "INSERT INTO test_table(date_field, time_field,
                                        timestamp_field) VALUES(?,?,?");

  stmt= mysql_prepare(mysql, query, strlen(query)));

  /* setup input buffers for all 3 parameters */
  bind[0].buffer_type= MYSQL_TYPE_DATE;
  bind[0].buffer= (char *) &ts;
  bind[0].is_null= 0;
  bind[0].length= 0;
  ..
  bind[1]= bind[2]= bind[0];
  ..

  mysql_bind_param(stmt, bind);

  /* supply the data to be sent is the ts structure */
  ts.year= 2002;
  ts.month= 02;
  ts.day= 03;

  ts.hour= 10;
  ts.minute= 45;
  ts.second= 20;

  mysql_execute(stmt);
  ..

11.1.10. C API thread 함수의 설명

thread 클라이언트를 작성하려면 , 이하의 함수를 사용할 필요가 있습니다. See 항 11.1.14. 「thread 클라이언트의 작성 방법」.

11.1.10.1. my_init()

void my_init(void)

설명

이 함수는, 다른 MySQL 함수를 호출하기 전에, 프로그램내에서 1 회만 호출할 필요가 있습니다.MySQL 하지만 필요로 하는 몇개의 글로벌 변수를 초기화합니다.thread 세이프인 클라이언트 라이브러리를 사용하고 있는 경우, 이 함수는 현재의 thread에 대해서 mysql_thread_init() 의 호출도 실시합니다.

mysql_init(),mysql_server_init(), 및 mysql_connect() (은)는, 자동적으로 이 함수를 호출합니다.

반환값

없습니다.

11.1.10.2. mysql_thread_init()

my_bool mysql_thread_init(void)

설명

thread를 작성하면(자), thread 고유의 변수를 초기화하기 위해서 이 함수를 호출할 필요가 있습니다.

my_init() 및 mysql_connect() (은)는, 자동적으로 이 함수를 호출합니다.

반환값

정상적으로 동작했을 경우는 0.에러가 발생했을 경우는 0 이외.

11.1.10.3. mysql_thread_end()

void mysql_thread_end(void)

설명

mysql_thread_init() (을)를 호출하기 전에 이 함수를 호출해,pthread_exit() 에 의해 할당할 수 있었던 메모리를 해방할 필요가 있습니다.

주의: 이 함수는, 클라이언트 라이브러리로부터는 자동적으로 불려 가지 않습니다 .메모리 리크를 피하기 위해서(때문에), 명시적으로 호출할 필요가 있습니다.

반환값

없습니다.

11.1.10.4. mysql_thread_safe()

unsigned int mysql_thread_safe(void)

설명

이 함수는, 클라이언트가 thread 세이프로서 컴파일 되었는지 어떠했는지를 나타냅니다.

반환값

클라이언트가 thread 세이프의 경우는 1, 그 이외의 경우는 0.

11.1.11. C API 편입 서버 함수의 설명

어플리케이션을 짜넣어 MySQL 서버 라이브러리와 링크하는 경우, 이하로 설명하는 함수를 사용할 필요가 있습니다. See 항 11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld」.

프로그램을,-lmysqld (이)가 아니고,-lmysqlclient (을)를 지정해 링크했을 경우, 이러한 함수는 아무것도 실행하지 않습니다.그 때문에, 코드를 변경하지 않아도, 편입 MySQL 서버 및 스탠드얼론 서버의 어느 쪽을 사용하는지를 선택할 수 있습니다.

11.1.11.1. mysql_server_init()

int mysql_server_init(int argc, char **argv, char **groups)

설명

이 함수는, 편입 서버를 사용하는 프로그램으로, 다른 MySQL 함수를 호출하기 전에, 1 회만 호출할 필요가 있습니다 .우선 짜넣어 서버를 기동해, 이 서버가 사용하는 하부조직(mysys,InnoDB 등)을 모두 초기화합니다.이 함수를 호출하지 않았던 경우, 프로그램은 크래쉬 합니다.MySQL 에 부속의 DBUG 패키지를 사용하고 있는 경우는,MY_INIT() (을)를 호출한 후에 이 함수를 호출할 필요가 있습니다.

인수의 argc 및 argv 는,main() 의 인수와 닮아 있습니다.argv 의 최초의 요소는, 통상은 프로그램명이며, 무시됩니다.사용하기 쉽게 하기 위해서, 서버에 대해서 커멘드 라인 인수가 없는 경우,argc 하 0(제로)이 됩니다.mysql_server_init() (은)는 인수의 카피를 작성하므로, 그것을 호출한 후는 argv 또는 groups (을)를 부수어도 문제 없습니다.

groups 의 NULL 그리고 종단 된 캐릭터 라인의 리스트는, 옵션 설정 파일의 어느 그룹을 액티브하게 하는지를 선택합니다.See 항 4.1.2. 「my.cnf 옵션 설정 파일」. 사용하기 쉽게 하기 위해서,groups 가 NULL 의 경우는,[server] 및 [embedded] 그룹이 읽힙니다.

례

#include <mysql.h>
#include <stdlib.h>

static char *server_args[] = {
  "this_program",       /* this string is not used */
  "--datadir=.",
  "--key_buffer_size=32M"
};
static char *server_groups[] = {
  "embedded",
  "server",
  "this_program_SERVER",
  (char *) NULL
};

int main(void) {
  mysql_server_init(sizeof(server_args) / sizeof(char *),
                    server_args, server_groups);

  /* Use any MySQL API functions here */

  mysql_server_end();

  return EXIT_SUCCESS;
}

반환값

정상적으로 종료했을 경우는 0.에러가 발생했을 경우는 1.

11.1.11.2. mysql_server_end()

void mysql_server_end(void)

설명

이 함수는, 다른 MySQL 함수를 모두 호출한 후에 1 회 호출할 필요가 있습니다 .편입 서버를 슛다운 합니다.

반환값

없습니다.

11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제

11.1.12.1. mysql_query() 가 정상적으로 종료한 다음에 mysql_store_result() 가 NULL 를 돌려주는 경우가 있는 것은 왠지

mysql_query() 의 호출이 정상적으로 종료한 다음에 mysql_store_result() 가 NULL (을)를 돌려줄 가능성은 있습니다.이러한 상황이 발생했을 경우, 이하의 몇개의 조건이 성립한 것을 의미합니다.

  • malloc() 하지만 이상종료(ABEND) 했다(결과 세트가 너무 컸을 경우 등)

  • 데이터를 읽어들일 수 없었다(접속에 에러가 발생했다)

  • 데이터를 돌려주지 않는 쿼리였다(INSERT,UPDATE, 또는 DELETE 였던 경우 등)

mysql_field_count() (을)를 호출하는 것에 의해, 스테이트먼트가 하늘이 아닌 결과 세트를 생성했는지 어떠했는지를 언제라도 조사할 수가 있습니다.mysql_field_count() 하지만 0 (을)를 돌려주는 경우, 결과 세트는 하늘이며, 마지막에 실행한 쿼리는 결과를 돌려주고 있지 않습니다(INSERT 또는 DELETE 등).mysql_field_count() 가 0 이외의 값을 돌려주는 경우, 스테이트먼트는 하늘이 아닌 결과 세트를 돌려주고 있습니다.예에 대해서는,mysql_field_count() 함수의 설명을 참조해 주세요.

mysql_error() 또는 mysql_errno() (을)를 호출하는 것에 의해, 에러가 발생했는지 어떠했는지를 판정할 수 있습니다.

11.1.12.2. 쿼리로부터 취득할 수 있는 결과에는 어떠한 것이 있을까

쿼리는, 결과 세트를 돌려주는 것 외에, 이하의 정보를 제공합니다.

  • mysql_affected_rows() (은)는,INSERT,UPDATE, 또는 DELETE (을)를 실행하는 경우, 마지막에 실행한 쿼리로 삽입, 갱신, 또는 삭제된 레코드의 수를 돌려준다.예외는,WHERE 마디를 사용하지 않고DELETE (을)를 실행했을 경우로, 이 때는 시간을 큰폭으로 단축하기 위해서 테이블을 하늘 상태로 재작성한다.이 경우,mysql_affected_rows() (은)는 삭제된 레코드가 수라고 해 0 (을)를 돌려준다.

  • mysql_num_rows()
(은)는 결과 세트의 레코드수를 돌려준다.mysql_store_result()
(을)를 사용하는 경우,mysql_store_result()
하지만 복귀한 직후에
mysql_num_rows()
(을)를 호출할 수가 있다.mysql_use_result()
(을)를 사용하는 경우,mysql_fetch_row()
(을)를 사용해 모든 레코드를 취득한 다음에 마셔
mysql_num_rows()
(을)를 호출할 수가 있다.

  • mysql_insert_id() (은)는,AUTO_INCREMENT 인덱스를 사용해 테이블에 레코드를 삽입한 마지막 쿼리가 생성했다 ID 를 돌려준다. See 항 11.1.3.32. 「mysql_insert_id()」.

  • 일부의 쿼리(LOAD DATA INFILE ...,INSERT INTO ... SELECT ...,UPDATE)는, 상기 이외에도 보충 정보를 제공한다.이 보충 정보는 mysql_info() (을)를 호출하는 것에 의해 취득한다.이 함수가 돌려주는 캐릭터 라인의 포맷에 대해서는,mysql_info() 의 설명을 참조하는 것.mysql_info() (은)는, 취득하는 보충 정보가 없는 경우는,NULL 포인터를 돌려준다.

11.1.12.3. 마지막에 삽입한 레코드의 일의인 ID 는 어떻게 취득하는 것인가

AUTO_INCREMENT 속성을 가지는 컬럼이 정의되고 있는 테이블에 레코드를 삽입하는 경우,mysql_insert_id() (을)를 호출하는 것에 의해, 마지막에 생성되었다 ID 를 취득할 수 있습니다.

또,mysql_query() 에 건네주는 쿼리 캐릭터 라인으로 LAST_INSERT_ID() 함수를 사용하는 것에 의해, 마지막에 생성되었다 ID 를 취득할 수도 있습니다.

이하의 코드를 실행하면(자),AUTO_INCREMENT 인덱스가 사용되었는지 어떠했는지를 조사할 수가 있습니다.이 코드는 동시에, 쿼리가 AUTO_INCREMENT 인덱스를 사용하는 INSERT (이었)였는지 아닌지도 조사합니다.

if (mysql_error(&mysql)[0] == 0 &&
    mysql_num_fields(result) == 0 &&
    mysql_insert_id(&mysql) != 0)
{
    used_id = mysql_insert_id(&mysql);
}

마지막에 생성된 ID (은)는, 접속 마다 서버에 보관 유지됩니다.다른 접속을 사용하는 클라이언트에 의해 변경될 것은 없습니다.AUTO_INCREMENT 속성을 가지는 다른 컬럼을 비매직치(NULL 그렇지만 0 도 아닌 값)으로 갱신했을 경우도, 이 ID (은)는 변경되지 않습니다.

어느 테이블용으로 생성된 ID (을)를 다른 테이블에 삽입하려면 , 이하의 SQL 스테이트먼트를 기술합니다.

INSERT INTO foo (auto, text)
    VALUES(NULL, 'text');              # generate ID by inserting NULL
INSERT INTO foo2 (id, text)
    VALUES(LAST_INSERT_ID(), 'text');  # use ID in second table

11.1.12.4. C API 와 링크하는 경우의 문제

C API (와)과 링크하는 경우, 일부의 시스템에서는 이하의 에러가 발생할 가능성이 있습니다.

gcc -g -o client test.o -L/usr/local/lib/mysql -lmysqlclient -lsocket -lnsl

Undefined        first referenced
 symbol          in file
floor            /usr/local/lib/mysql/libmysqlclient.a(password.o)
ld: fatal: Symbol referencing errors. No output written to client

시스템으로 이 에러가 발생했을 경우, 컴파일/링크행의 마지막에 -lm (을)를 추가해, 수학 라이브러리를 링크할 필요가 있습니다.

11.1.13. 클라이언트 프로그램의 빌드

스스로 작성한 MySQL 클라이언트 또는 써드파티로부터 입수했다 MySQL 클라이언트를 컴파일 하는 경우, 링크 커멘드로 -lmysqlclient -lz 옵션을 사용해 링크할 필요가 있습니다.또, 경우에 따라서는, 라이브러리의 소재를 링커에 통지하기 위해서 -L 옵션을 지정할 필요가 있습니다.예를 들어, 라이브러리가 /usr/local/mysql/lib 에 인스톨 되고 있는 경우, 링크 커멘드로 -L/usr/local/mysql/lib -lmysqlclient -lz (을)를 기술합니다.

MySQL 헤더 파일을 사용하는 클라이언트를 컴파일 할 때, 경우에 따라서는 -I 옵션을 지정해(예를 들어 -I/usr/local/mysql/include), 헤더 파일의 소재를 컴파일러에 통지할 필요가 있습니다.

상기의 처리를 Unix 로 간단하게 실행하기 위해서 mysql_config 스크립트가 준비되어 있습니다. See 항 4.9.11. 「mysql_config(클라이언트를 컴파일하기 위한 컴파일 옵션의 취득)」.

이 스크립트를 사용해 이하와 같이 지정하는 것으로, MySQL 클라이언트를 컴파일 할 수 있습니다.

CFG=/usr/local/mysql/bin/mysql_config
sh -c "gcc -o progname `$CFG --cflags` progname.c `$CFG --libs`"

sh -c 는,mysql_config (으)로부터의 출력을 쉘이 1 말로서 처리하지 않게 하기 위해서 필요합니다.

11.1.14. thread 클라이언트의 작성 방법

클라이언트 라이브러리는 거의 thread 세이프입니다.최대의 문제는,net.c 그리고 기술되고 있는 소켓으로부터 데이터를 읽어들이기 위한 써브루틴이, 세치기가 발생했을 때에 thread 세이프가 아닌 것입니다.이것은, 서버에 대한 읽기에 장시간 걸리는 경우, 그것을 중단할 수 있는 알람을 유저가 독자적으로 작성할 가능성이 있다고 하는 생각에 근거하는 사양입니다.세치기 SIGPIPE 에 대한 인터럽트 처리기를 인스톨 하는 경우는, 소켓의 처리를 thread 세이프로 할 필요가 있습니다.

버젼 4.0.16 의 신기능: 접속이 절단 되었을 때에 프로그램이 강제 종료하지 않게 하기 위해서, MySQL (은)는 최초로 mysql_server_init(),mysql_init(), 또는 mysql_connect() (을)를 호출할 때 SIGPIPE 를 블록 합니다.독자적으로 SIGPIPE 에 대한 인터럽트 처리기를 작성하는 경우, 우선 mysql_server_init() (을)를 호출하고 나서, 그 핸들러를 인스톨 할 필요가 있습니다.MySQL 의 낡은 버젼에서는, thread 세이프인 클라이언트 라이브러리에서만,mysql_init() (을)를 호출할 때마다,SIGPIPE 하지만 블록 되고 있었습니다.

당사의 Web 사이트(http://www.mysql.com/)에서 배포한 낡은 바이노리필드의 경우, 클라이언트 라이브러리의 컴파일에서는 thread 세이프인 옵션을 사용하지 않는 것이 보통이었습니다(Windows 의 바이너리는 디폴트로 thread 세이프로 컴파일 됩니다).새롭게 배포하는 바이너리에서는, thread 세이프인 클라이언트 라이브러리와 그렇지 않은 클라이언트 라이브러리의 양쪽 모두가 필요합니다.

다른 thread로부터 끼어들거나 MySQL 서버와의 통신에 타임 아웃을 설정할 수 있는 것 같은 thread 클라이언트를 작성하려면 ,-lmysys,-lmystrings, 및 -ldbug 의 각 라이브러리, 및 서버가 사용한다 net_serv.o 코드를 사용할 필요가 있습니다.

세치기나 타임 아웃을 사용하지 않는 경우는, thread 세이프인 클라이언트 라이브러리 (mysqlclient_r) (을)를 컴파일 해 사용하는 것만으로 끝납니다.See 항 11.1. 「MySQL C API」. 이 경우,net_serv.o 오브젝트 파일이나 다른 MySQL 라이브러리를 사용할 필요는 없습니다.

thread 클라이언트를 사용하면서, 타임 아웃이나 세치기도 사용하는 경우,thr_alarm.c 파일로 정의되고 있는 루틴을 활용할 수 있습니다.mysys 라이브러리의 루틴을 사용하고 있는 경우, 우선 my_init() (을)를 호출할 필요가 있습니다. See 항 11.1.10. 「C API thread 함수의 설명」.

mysql_real_connect() 이외의 모든 함수는, 디폴트로 thread 세이프입니다.이하에, thread 세이프인 클라이언트 라이브러리를 컴파일 해, thread 세이프에 사용하는 방법을 나타냅니다(mysql_real_connect() (을)를 사용한 이하의 기술은 mysql_connect() 에도와 같이 적용할 수 있습니다만,mysql_connect() (은)는 폐지되었으므로, 어쨌건 간에 mysql_real_connect() (을)를 사용할 필요가 있습니다).

mysql_real_connect() (을)를 thread 세이프로 하려면 , 이하의 커멘드를 사용해 클라이언트 라이브러리를 재컴파일 할 필요가 있습니다.

shell>
./configure --enable-thread-safe-client

이 커멘드에 의해, thread 세이프인 클라이언트 라이브러리 libmysqlclient_r 하지만 작성됩니다(사용하는 OS 에 thread 세이프인 gethostbyname_r() 함수가 제공되고 있으면(자) 가정).이 라이브러리는 접속 마다 thread 세이프가 됩니다.이하의 항목에 주의하면, 2 개의 thread로 같은 접속을 공유할 수 있습니다.

  • 2 개의 thread가 같은 접속으로 동시에 MySQL 서버에 쿼리를 송신할 수 없다.특히,mysql_query() (을)를 호출하고 나서 mysql_store_result() (을)를 호출할 때까지 는, 다른 thread가 같은 접속을 결코 사용하지 않게 할 필요가 있다.

  • 복수의 thread가 mysql_store_result() 그리고 취득한 복수의 결과 세트에 액세스 할 수가 있다.

  • mysql_use_result (을)를 사용하는 경우, 결과 세트를 클로우즈 할 때까지, 같은 접속을 다른 thread가 사용하지 않게 할 필요가 있다.다만, 가장 바람직한 것은, 같은 접속을 공유하는 thread 클라이언트가 mysql_store_result() (을)를 사용하는 것이다.

  • 같은 접속으로 복수의 thread를 사용하는 경우,mysql_query() (을)를 호출하는 전부터 mysql_store_result() (을)를 호출한 뒤에까지의 부분을 mutex 락으로 둘러쌀 필요가 있다.mysql_store_result() 하지만 복귀한 후는 락을 해방할 수가 있어 같은 접속으로 다른 thread가 쿼리를 실행할 수 있게 된다.

  • POSIX thread를 사용해 프로그램 하는 경우,pthread_mutex_lock() 및 pthread_mutex_unlock() (을)를 사용해, mutex 락을 설정 및 해방할 수 있다.

MySQL 데이타베이스에 접속하지 않는 MySQL 함수를 호출하는 thread를 사용하는 경우, 이하의 사항을 인식해 둘 필요가 있습니다.

mysql_init() 또는 mysql_connect() 를 호출하면(자), MySQL (은)는 thread 마다 thread 고유의 변수를 작성합니다.이 변수는 특히 디버그 라이브러리에서 사용됩니다.

thread가 mysql_init() 또는 mysql_connect() 를 호출하기 전에 MySQL 함수를 호출하면(자), thread는 필요한 thread 고유의 변수를 설정하지 않고, 그 중 코어덤프가 발생합니다.

처리를 원활히 진행하려면 , 이하에 나타내는 항목을 실행할 필요가 있습니다.

  1. mysql_real_connect() (을)를 호출하기 전에 다른 MySQL 함수를 호출하는 경우, 프로그램의 선두에서 my_init() 를 호출한다.

  2. MySQL 함수를 호출하기 전에 thread 핸들러로 mysql_thread_init() 를 호출한다.

  3. thread에서는,pthread_exit() (을)를 호출하기 전에 mysql_thread_end() (을)를 호출한다.이것에 의해 MySQL 하지만 작성한 thread 고유의 변수가 사용하고 있던 메모리가 해방된다.

클라이언트를 libmysqlclient_r (와)과 링크할 경우에, 미정도리 심볼이 있다고 하는 에러가 발생할 가능성이 있습니다.대부분의 경우, 이것은 링크/컴파일행에 thread 라이브러리를 추가하지 않았던 것이 원인입니다.

11.1.15. 편입 MySQL 서버 라이브러리 libmysqld

11.1.15.1. 편입 MySQL 서버 라이브러리의 개요

편입 MySQL 서버 라이브러리를 사용하는 것으로, 클라이언트 어플리케이션 내부에서 완전한 기능을 갖추었다 MySQL 서버를 실행할 수 있습니다.최대의 장점은, 처리 속도가 고속으로 되는 것으로, 편입 어플리케이션의 관리성이 향상하는 것입니다.

편입 MySQL 서버 라이브러리는, C/C++ 그리고 기술된 MySQL 의 클라이언트/서버 버젼을 베이스로 하고 있습니다.그 때문에, 편입 서버도 C/C++ 그리고 기술되고 있습니다.다른 언어에서의 짜넣어 서버는 제공되고 있지 않습니다.

편입 서버 버젼과 클라이언트/서버 버젼은 어느쪽이나 같다 API 하지만 준비되어 있습니다.기존의 thread 어플리케이션도, 통상은 이하의 함수에의 호출을 추가하는 것만으로, 편입 서버 라이브러리를 사용하도록(듯이) 변경할 수 있습니다.

함수 | 호출하는 타이밍
mysql_server_init() | 다른 MySQL 함수가 불려 가기 전에 호출할 필요가 있다.main() 함수의 가능한 한 선두에 가까운 장소가 바람직하다.
mysql_server_end() | 프로그램이 종료하기 전에 호출할 필요가 있다.
mysql_thread_init() | MySQL 에 액세스 하는 thread 마다 호출할 필요가 있다.
mysql_thread_end() | pthread_exit() (을)를 호출하기 전에 호출할 필요가 있다.

다음에,libmysqlclient.a (이)가 아니고,libmysqld.a (을)를 작성한 코드에 링크할 필요가 있습니다.

상기의 mysql_server_xxx 함수는 libmysqlclient.a 에도 포함되어 있어 작성한 어플리케이션을 적절한 라이브러리와 링크하는 것만으로, 편입 서버 버젼 및 클라이언트/서버 버젼의 어느 쪽을 사용할까를 바꿀 수가 있게 되어 있습니다. See 항 11.1.11.1. 「mysql_server_init()」.

11.1.15.2. libmysqld 를 사용한 프로그램의 컴파일

libmysqld 라이브러리를 취득하려면 ,--with-embedded-server 옵션을 사용해 MySQL (을)를 설정할 필요가 있습니다.

프로그램을 libmysqld (와)과 링크할 때는, 시스템 고유의 pthread 라이브러리 및 MySQL 서버가 사용하는 라이브러리도 링크할 필요가 있습니다.mysql_config --libmysqld-libs (을)를 실행하면(자), 라이브러리의 상세한 리스트를 취득할 수 있습니다.

thread 프로그램을 컴파일 및 링크할 때는, 적절한 플래그를 지정할 필요가 있습니다.이것은, 자작 코드로부터 직접 thread 함수를 호출하지 않은 경우에서도 필요합니다.

11.1.15.3. 편입 MySQL 서버를 사용할 때의 제약

편입 MySQL 서버에는 이하의 제약이 있습니다.

  • ISAM 테이블은 서포트하지 않는다(라이브러리의 사이즈를 작고하기 위한 방침).

  • 유저 정의 함수(UDF)는 사용할 수 없다.

  • 코어덤프로 스택 트레이스는 할 수 없다.

  • 내부 RAID (을)를 서포트하지 않는다(현재 대부분의 OS 그리고 사이즈의 큰 파일을 서포트하고 있으므로 통상은 필요없다).

  • 서버 또는 마스터로서 설정할 수 없다(replication 할 수 없다).

  • 외부 프로세스로부터 소켓 또는 TCP/IP (을)를 사용해 편입 MySQL 서버에 접속할 수 없다.

상기의 제약안에는,mysql_embed.h 인클루드 파일을 편집해 MySQL (을)를 재컴파일 하는 것으로 변경할 수 있는 것도 있습니다.

11.1.15.4. 편입 MySQL 서버에서의 옵션 설정 파일의 사용

옵션 설정 파일을 사용해, 클라이언트/서버 어플리케이션과 짜넣어 MySQL 서버를 사용한 어플리케이션을 간단하게 바꾸는 추천 방법을 이하에 나타냅니다. See 항 4.1.2. 「my.cnf 옵션 설정 파일」.

  • 공통되는 옵션을 [server] 섹션에 기술한다.이 옵션은 양쪽 모두의 버젼의 MySQL 에 읽힌다.

  • 클라이언트/서버 고유의 옵션을 [mysqld] 섹션에 기술한다.

  • 편입 MySQL 서버 고유의 옵션을 [embedded] 섹션에 기술한다.

  • 어플리케이션 고유의 옵션을 [ApplicationName_SERVER] 섹션에 기술한다.

11.1.15.5. 편입 MySQL 서버의 향후의 개발 과제

  • 라이브러리를 작게 하기 위해서 MySQL 의 기능의 일부를 짜넣지 않는 옵션을 제공한다.

  • 실행 속도를 향상시킨다.

  • 에러의 출력처를 stderr (으)로 한다.그 경우에 파일명을 지정하는 옵션을 추가한다.

  • InnoDB 를 짜넣어 MySQL 서버 버젼으로 사용할 때의 용장도를 삭감한다.

11.1.15.6. 편입 MySQL 서버를 사용한 간단한 예

이하에 나타내는 프로그램 및 makefile 는, Linux (이)나 FreeBSD 시스템에서도 굳이 변경하는 일 없이 동작할 것입니다.다른 operating system로 사용하는 경우는, 일부 변경이 필요합니다.이 예는, 실제의 어플리케이션을 작성하는 경우에는 피할 수 없는 혼란을 회피해, 문제점을 이해 가능한 한의 상세한 실례를 나타내는 것을 목적으로 하고 있습니다.

이 예를 실제로 동작시키려면 , mysql-4.0 소스 디렉토리와 같은 레벨에 test_libmysqld 디렉토리를 작성합니다.그 디렉토리에 test_libmysqld.c 원시 파일과 GNUmakefile (을)를 보존해,test_libmysqld 디렉토리내로부터 GNU make (을)를 실행합니다.

test_libmysqld.c

/*
 * A simple example client, using the embedded MySQL server library
 */

#include <mysql.h>
#include <stdarg.h>
#include <stdio.h>
#include <stdlib.h>

MYSQL *db_connect(const char *dbname);
void db_disconnect(MYSQL *db);
void db_do_query(MYSQL *db, const char *query);

const char *server_groups[] = {
  "test_libmysqld_SERVER", "embedded", "server", NULL
};

int
main(int argc, char **argv)
{
  MYSQL *one, *two;

  /* mysql_server_init() must be called before any other mysql
   * functions.
   *
   * You can use mysql_server_init(0, NULL, NULL), and it will
   * initialize the server using groups = {
   *   "server", "embedded", NULL
   *  }.
   *
   * In your $HOME/.my.cnf file, you probably want to put:

[test_libmysqld_SERVER]
language = /path/to/source/of/mysql/sql/share/english

   * You could, of course, modify argc and argv before passing
   * them to this function.  Or you could create new ones in any
   * way you like.  But all of the arguments in argv (except for
   * argv[0], which is the program name) should be valid options
   * for the MySQL server.
   *
   * If you link this client against the normal mysqlclient
   * library, this function is just a stub that does nothing.
   */
  mysql_server_init(argc, argv, (char **) server_groups);

  one = db_connect("test");
  two = db_connect(NULL);

  db_do_query(one, "SHOW TABLE STATUS");
  db_do_query(two, "SHOW DATABASES");

  mysql_close(two);
  mysql_close(one);

  /* This must be called after all other mysql functions */
  mysql_server_end();

  exit(EXIT_SUCCESS);
}

static void
die(MYSQL *db, char *fmt, ...)
{
  va_list ap;
  va_start(ap, fmt);
  vfprintf(stderr, fmt, ap);
  va_end(ap);
  (void) putc('\n', stderr);
  if (db)
    db_disconnect(db);
  exit(EXIT_FAILURE);
}

MYSQL *
db_connect(const char *dbname)
{
  MYSQL *db = mysql_init(NULL);
  if (!db)
    die(db, "mysql_init failed: no memory");
  /*
   * Notice that the client and server use separate group names.
   * This is critical, because the server will not accept the
   * client's options, and vice versa.
   */
  mysql_options(db, MYSQL_READ_DEFAULT_GROUP, "test_libmysqld_CLIENT");
  if (!mysql_real_connect(db, NULL, NULL, NULL, dbname, 0, NULL, 0))
    die(db, "mysql_real_connect failed: %s", mysql_error(db));

  return db;
}

void
db_disconnect(MYSQL *db)
{
  mysql_close(db);
}

void
db_do_query(MYSQL *db, const char *query)
{
  if (mysql_query(db, query) != 0)
    goto err;

  if (mysql_field_count(db) > 0)
  {
    MYSQL_RES   *res;
    MYSQL_ROW    row, end_row;
    int num_fields;

    if (!(res = mysql_store_result(db)))
      goto err;
    num_fields = mysql_num_fields(res);
    while ((row = mysql_fetch_row(res)))
    {
      (void) fputs(">> ", stdout);
      for (end_row = row + num_fields; row < end_row; ++row)
        (void) printf("%s\t", row ? (char*) *row : "NULL");
      (void) fputc('\n', stdout);
    }
    (void) fputc('\n', stdout);
    mysql_free_result(res);
  }
  else
    (void) printf("Affected rows: %lld\n", mysql_affected_rows(db));

  return;

err:
  die(db, "db_do_query failed: %s [%s]", mysql_error(db), query);
}

GNUmakefile

# This assumes the MySQL software is installed in /usr/local/mysql
inc      := /usr/local/mysql/include/mysql
lib      := /usr/local/mysql/lib

# If you have not installed the MySQL software yet, try this instead
#inc      := $(HOME) /mysql-4.0/include
#lib      := $(HOME) /mysql-4.0/libmysqld

CC       := gcc
CPPFLAGS := -I$(inc) -D_THREAD_SAFE -D_REENTRANT
CFLAGS   := -g -W -Wall
LDFLAGS  := -static
# You can change -lmysqld to -lmysqlclient to use the
# client/server library
LDLIBS    = -L$(lib) -lmysqld -lz -lm -lcrypt

ifneq (,$(shell grep FreeBSD /COPYRIGHT 2>/dev/null))
# FreeBSD
LDFLAGS += -pthread
else
# Assume Linux
LDLIBS += -lpthread
endif

# This works for simple one-file test programs
sources := $(wildcard *.c)
objects := $(patsubst %c, %o,$(sources))
targets := $(basename $(sources))

all: $(targets)

clean:
        rm -f $(targets) $(objects) *.core

11.1.15.7. 편입 MySQL 서버의 라이센스

MySQL 의 원시 코드는 GNU GPL 라이센스(see 부록 H. GNU General Public License )의 대상입니다.그 결과,libmysqld (을)를 링크하는 것에 의해 MySQL 원시 코드를 인클루드 하는 프로그램은, (GPL (와)과 호환성이 있는 라이센스아래에서) 프리 소프트웨어로서 릴리스 할 필요가 있습니다.

프리 소프트웨어를 작성하면(자),GPL 또는 그것과 호환성이 있는 라이센스아래에서 코드를 릴리스 하는 것에 의해 프리 소프트웨어를 선전하도록 해 주세요.그것을 할 수 없는 경우는, MySQL AB 로부터 MySQL 코드의 상업적 라이센스를 구입한다고 하는 선택사항이 있습니다.상세한 것에 대하여는,항 1.4.3. 「MySQL 라이센스」 (을)를 참조해 주세요.


제11 장 MySQL API

목차

11.1. MySQL C API
11.1.1. C API 데이터형
11.1.2. C API 함수의 개요
11.1.3. C API 함수의 설명
11.1.4. C API 의 Prepared Statements
11.1.5. C API 의 Prepared Statement의 데이터형
11.1.6. C API 의 Prepared Statement 함수의 개요
11.1.7. C API 의 Prepared Statement 함수의 설명
11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급
11.1.9. C API 에 있어서의 일자치 및 시각치의 취급
11.1.10. C API 스레드 함수의 설명
11.1.11. C API 편입 서버 함수의 설명
11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제
11.1.13. 클라이언트 프로그램의 빌드
11.1.14. 스레드 클라이언트의 작성 방법
11.1.15. 편입 MySQL 서버 라이브러리 libmysqld
11.2. MySQL 의 ODBC 서포트
11.2.1. MyODBC 의 인스톨 방법
11.2.2. ODBC 아드?~ 니스트레이타의 필드의 설정 방법법
11.2.3. MyODBC 의 접속 파라미터
11.2.4. MyODBC 에 관한 문제를 보고하는 방법
11.2.5. MyODBC (와)과 제휴해 동작하는 것이 알려져 있는 프로그램
11.2.6. ODBC 그리고 AUTO_INCREMENT 속성을 가지는 컬럼의 값을 취득하는 방법
11.2.7. MyODBC 에 관한 문제의 보고
11.3. MySQL 의 Java 접속(JDBC )
11.4. MySQL PHP API
11.4.1. MySQL 및 PHP (이)가 좋게 있는 문제
11.5. MySQL Perl API
11.5.1. DBI (와)과 DBD::mysql
11.5.2. DBI 인터페이스
11.5.3. DBI/DBD 에 관한 그 외의 정보
11.6. MySQL C++ API
11.6.1. Borland C++
11.7. MySQL Python API
11.8. MySQL Tcl API
11.9. MySQL Eiffel Wrapper

이 장에서는,MySQL 그리고 사용할 수 있다 API 의 입수 장소 및 사용 방법에 대해 설명합니다.가장 풍부한 종류가 준비되어 있는 것이 C API 입니다.이것은 MySQL 팀이 개발하고 있습니다.발설어 전용의 API (은)는, 이 C API (을)를 베이스로 해 개발되고 있습니다.

11.1. MySQL C API

C API 코드는,MySQL (와)과 함께 배포되고 있습니다.C API 코드는 mysqlclient 라이브러리에 격납되어C 프로그램은 이 코드를 사용해 데이타베이스에 액세스 할 수 있습니다.

MySQL 의 소스 디스트리뷰션에 포함되는 클라이언트의 상당수는 C 그리고 기술되고 있습니다.C API 의 사용 방법을 알 수 있는 코드예를 찾고 있는 경우는, 이러한 클라이언트를 참고로 해 주세요.클라이언트는,MySQL 소스 디스트리뷰션의 clients 디렉토리에 격납되고 있습니다.

다른 클라이언트 API (Connector/J (을)를 제외하는 모든 API )의 상당수는,mysqlclient 라이브러리를 사용해 MySQL 서버와 통신합니다.이 라이브러리를 사용하면, 예를 들어 환경 변수를 참조할 수 있으므로, 다른 클라이언트 프로그램과 대부분의 환경 변수를 공용할 수 있게 됩니다.공용할 수 있는 환경 변수의 일람에 대해서는, 항4.9. 「MySQL 클라이언트 사이드의 스크립트와 유틸리티」 (을)를 참조해 주세요.

클라이언트를 사용할 수 있는 통신 버퍼 사이즈에는 상한이 있습니다.내부적으로 할당할 수 있고 있는 버퍼 사이즈(16 킬로바이트)는, 최대 16 메가바이트까지 자동적으로 증가합니다.버퍼 사이즈가 증가하는 것은 버퍼의 요구량이 증가했을 경우 뿐이어서, 디폴트의 최대치를 늘렸다고 사용 자원이 증가하는 것은 아닙니다.이 사이즈 체크에서는, 잘못된 쿼리나 통신 패킷을 주로 체크합니다.

통신 버퍼 사이즈는,SQL 스테이트먼트 1 개(클라이언트로부터 서버에의 트래픽) 및 결과 데이터 1 행(서버로부터 클라이언트에의 트래픽)을 격납 가능한 한의 크기가 필요합니다.각 스레드의 통신 버퍼는, 쿼리나 레코드를 처리할 수 있도록, 그 최대치까지 동적으로 확대됩니다.예를 들어, 최대 16 메가바이트의 데이터를 격납한다 BLOB 값을 처리하는 경우, 통신 버퍼 사이즈의 최대치는(서버와 클라이언트의 양쪽 모두로) 적어도 16 메가바이트일 필요가 있습니다.클라이언트의 디폴트의 최대치는 16 메가바이트입니다만, 서버의 디폴트의 최대치는 1 메가바이트입니다.서버의 디폴트의 최대치를 늘리려면 , 서버의 기동시에 max_allowed_packet 의 값을 변경합니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

MySQL 서버는, 쿼리가 끝날 때마다 통신 버퍼 사이즈를 net_buffer_length (으)로 줄입니다.클라이언트측에서는, 접속이 절단 되어 메모리가 해방될 때까지, 그 접속에 할당할 수 있었던 버퍼 사이즈가 줄어 들 것은 없습니다.

스레드를 사용하는 프로그라?~ 그에 대해서는, 항11.1.14. 「스레드 클라이언트의 작성 방법」 (을)를 참조해 주세요.동일 프로그램내에 " 서버" (와)과 " 클라이언트" 하지만 존재한다( 및 외부의 MySQL 서버와 통신하지 않는다) 스탠드얼론 어플리케이션의 작성에 대해서는, 항11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld 」 (을)를 참조해 주세요.

11.1.1. C API 데이터형

  • MYSQL

    이 구조체는,1 개의 데이타베이스 접속에의 핸들을 나타낸다.대부분의 MySQL 함수로 사용된다.

  • MYSQL_RES

    이 구조체는, 레코드를 돌려주는 쿼리(SELECT ,SHOW ,EXPLAIN ,DESCRIBE )의 결과를 나타낸다.이 섹션에서는, 쿼리로부터 돌려주어진 정보를 결과 세트 (이)라고 부른다.

  • MYSQL_ROW

    1 행의 데이터의 타입 세이프인 표현.현재는, 아르바이트 문자열의 배열로서 실장되고 있다(필드에는 바이너리 데이터가 격납되는 경우가 있어, 그러한 데이터에서는 내부적으로 누르바이트가 사용될 가능성이 있으므로, 아르바이트 문자열을 눌 종단 문자열로서 취급할 수 없다).레코드를 취득하려면 ,mysql_fetch_row() (을)를 호출한다.

  • MYSQL_FIELD

    이 구조체에는, 필드의 이름, 형태, 사이즈 등, 필드에 관한 정보가 격납된다.멤버의 상세한 것에 대하여는, 이하로 설명한다. 각 필드에 대해서 mysql_fetch_field() (을)를 반복해 호출하는 것에 의해서, 대응한다 MYSQL_FIELD 구조체를 취득할 수 있다.필드치는 이 구조체의 일부에서는 없고,MYSQL_ROW 구조체에 포함된다.

  • MYSQL_FIELD_OFFSET

    MySQL 필드 일람에 대한 오프셋의 안전한 형태 표현(mysql_field_seek() 하지만 사용).오프셋은 레코드 내부에서의 필드 번호이며,0 (으)로부터 시작된다.

  • my_ulonglong

    레코드의 수를 나타내기 위한 형태이며,mysql_affected_rows() ,mysql_num_rows() , 및 mysql_insert_id() 그리고 사용된다.0 (으)로부터 1.84e19 까지의 범위의 값을 나타낸다.

    일부의 시스템에서는,my_ulonglong 형태의 값을 출력하려고 해도, 정상적으로 출력되지 않는다.이 형태의 값을 출력하려면 ,unsigned long (으)로 변환하고,%lu 포맷을 사용한다.이하에 예를 나타낸다.

    printf ("Number of rows: %lu\n", (unsigned long) mysql_num_rows(result));

MYSQL_FIELD 구조체의 멤버를 이하에 나타냅니다.

  • char * name

    필드의 이름.눌 종단 문자열.

  • char * table

    이 필드가 계산 결과 데이터의 필드가 아닌 경우, 이 필드가 속하는 테이블의 이름.계산 결과 데이터의 필드의 경우,table 의 값은 공문자열이 된다.

  • char * def

    이 필드의 디폴트치.눌 종단 문자열.mysql_list_fields() (을)를 사용할 때만 설정된다.

  • enum enum_field_types type

    필드의 형태. type 의 값은 다음의 어느 쪽인가에 된다.

    형태의 값 | 형태의 설명
    FIELD_TYPE_TINY | TINYINT 필드
    FIELD_TYPE_SHORT | SMALLINT 필드
    FIELD_TYPE_LONG | INTEGER 필드
    FIELD_TYPE_INT24 | MEDIUMINT 필드
    FIELD_TYPE_LONGLONG | BIGINT 필드
    FIELD_TYPE_DECIMAL | DECIMAL 또는 NUMERIC 필드
    FIELD_TYPE_FLOAT | FLOAT 필드
    FIELD_TYPE_DOUBLE | DOUBLE 또는 REAL 필드
    FIELD_TYPE_TIMESTAMP | TIMESTAMP 필드
    FIELD_TYPE_DATE | DATE 필드
    FIELD_TYPE_TIME | TIME 필드
    FIELD_TYPE_DATETIME | DATETIME 필드
    FIELD_TYPE_YEAR | YEAR 필드
    FIELD_TYPE_STRING | CHAR 필드
    FIELD_TYPE_VAR_STRING | VARCHAR 필드
    FIELD_TYPE_BLOB | BLOB 또는 TEXT 필드(max_length (을)를 사용해 최대장을 결정)
    FIELD_TYPE_SET | SET 필드
    FIELD_TYPE_ENUM | ENUM 필드
    FIELD_TYPE_NULL | NULL 형태 필드
    FIELD_TYPE_CHAR | 폐?~ (대신에 FIELD_TYPE_TINY (을)를 사용하는 것)

    IS_NUM() 매크로를 사용하면, 필드가 수치형인지 어떤지를 조사할 수 있다.type 의 값을 IS_NUM() 에 건네주면, 필드가 수치형의 경우는 TRUE (이)라고 평가된다.

    if (IS_NUM(field->type))
    printf("Field is numeric\n");

  • unsigned int length

    필드의 폭.테이블 정의로 지정된 값에 따른다.

  • unsigned int max_length

    결과 세트의 필드의 최대폭(결과 세트에 실제로 존재하는 레코드의 필드치의 최대장).mysql_store_result() 또는 mysql_list_fields() (을)를 사용했을 경우, 이 값은 필드의 최대장을 나타낸다.mysql_use_result() (을)를 사용했을 경우, 이 값은 0 (이)가 된다.

  • unsigned int flags

    필드의 다양한 상태를 나타내는 비트 플래그.flags 값은,0 또는 이하의 비트가 1 개이상 설정된 값이 된다.

    플래그의 값 | 플래그의 설명
    NOT_NULL_FLAG | NULL (을)를 설정할 수 없는 필드
    PRI_KEY_FLAG | 주키의 일부를 구성하는 필드
    UNIQUE_KEY_FLAG | 일의인 키의 일부를 구성하는 필드
    MULTIPLE_KEY_FLAG | 일의가 아닌 키의 일부를 구성하는 필드
    UNSIGNED_FLAG | UNSIGNED 속성을 가지는 필드
    ZEROFILL_FLAG | ZEROFILL 속성을 가지는 필드
    BINARY_FLAG | BINARY 속성을 가지는 필드
    AUTO_INCREMENT_FLAG | AUTO_INCREMENT 속성을 가지는 필드
    ENUM_FLAG | ENUM 형태의 필드(폐?~ )
    SET_FLAG | SET 형태의 필드(폐?~ )
    BLOB_FLAG | BLOB 형태 또는 TEXT 형태의 필드(폐?~ )
    TIMESTAMP_FLAG | TIMESTAMP 형태의 필드(폐?~ )

    BLOB_FLAG ,ENUM_FLAG ,SET_FLAG , 및 TIMESTAMP_FLAG 의 각 플래그는, 필드의 속성은 아니고 형태를 나타내고 있으므로, 폐?~ 되고 있다.대신에,field->type (을)를 FIELD_TYPE_BLOB ,FIELD_TYPE_ENUM ,FIELD_TYPE_SET , 또는 FIELD_TYPE_TIMESTAMP (와)과 비교하는 것이 바람직하다.

    다음에,flags 값의 전형적인 사용예를 나타낸다.

    if (field->flags & NOT_NULL_FLAG)
    printf("Field can't be null\n");

    이하의 매크로를 사용하면,flags 값을 조사해 불리언 값으로 결과를 얻을 수 있다.

    플래그 상태 | 설명
    IS_NOT_NULL(flags) | 이 필드가 NOT NULL (으)로서 정의되고 있는 경우는 True .
    IS_PRI_KEY(flags) | 이 필드가 주키의 경우는 True .
    IS_BLOB(flags) | 이 필드가 BLOB 또는 TEXT 의 경우는 True (폐?~ .대신에 field->type 에 의한 비교를 추천).

  • unsigned int decimals

    수치 필드의 소수부 자리수.

11.1.2. C API 함수의 개요

여기에서는,C API 그리고 제공되고 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이?~ 의 섹션으로 설명합니다. See 항11.1.3. 「C API 함수의 설명」 .

함수 | 설명
mysql_affected_rows() | 마지막에 실행되었다 UPDATE ,DELETE , 또는 INSERT 의 몇개의 쿼리에 의해서 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_change_user() | 오픈된 접속의 유저 및 데이타베이스를 변경한다.
mysql_character_set_name() | 접속의 디폴트의 캐릭터 세트의 이름을 돌려준다.
mysql_close() | 서버 접속을 절단 한다.
mysql_connect() | MySQL 서버에 접속한다.이 함수는 폐?~ 되고 있으므로, 대신에 mysql_real_connect() (을)를 사용하는 것.
mysql_create_db() | 데이타베이스를 작성한다.이 함수는 폐?~ 되고 있으므로, 대신에 SQL 커멘드 CREATE DATABASE (을)를 사용하는 것.
mysql_data_seek() | 쿼리 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_debug() | 지정된 문자열로 DBUG_PUSH (을)를 실행한다.
mysql_drop_db() | 데이타베이스를 파기한다.이 함수는 폐?~ 되고 있으므로, 대신에 SQL 커멘드 DROP DATABASE (을)를 사용하는 것.
mysql_dump_debug_info() | 디버그 정보를 로그에 쓰도록(듯이) 서버에 지시한다.
mysql_eof() | 결과 세트의 마지막 레코드가 읽혔는지를 판정한다. 이 함수는 폐?~ 되고 있어 대신에 mysql_errno() 또는 mysql_error() (을)를 사용할 수 있다.
mysql_errno() | 마지막에 불려 갔다 MySQL 함수의 에러 번호를 돌려준다.
mysql_error() | 마지막에 불려 갔다 MySQL 함수의 에러를 돌려준다.
mysql_escape_string() | 문자열에 포함되는 특수 문자를 이스케이프 하고,SQL 스테이트먼트로 사용할 수 있도록 한다.
mysql_fetch_field() | 테이블의 다음의 필드의 형태를 돌려준다.
mysql_fetch_field_direct() | 필드 번호로 지정된 테이블 필드의 형태를 돌려준다.
mysql_fetch_fields() | 모든 필드 구조체의 배열을 돌려준다.
mysql_fetch_lengths() | 현재의 레코드의 모든 컬럼에 대해 그 길이를 돌려준다.
mysql_fetch_row() | 결과 세트의 다음의 레코드를 취득한다.
mysql_field_seek() | 지정된 컬럼에 컬럼 커서를 이동한다.
mysql_field_count() | 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려준다.
mysql_field_tell() | 마지막에 실행되었다 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려준다.
mysql_free_result() | 결과 세트로 사용한 메모리를 해방한다.
mysql_get_client_info() | 클라이언트의 버젼 정보를 문자열로서 돌려준다.
mysql_get_client_version() | 클라이언트의 버젼 정보를 정수로서 돌려준다.
mysql_get_host_info() | 접속을 기술하는 문자열을 돌려준다.
mysql_get_server_version() | 서버의 버젼 번호를 정수로서 돌려준다(4.1 의 신기능).
mysql_get_proto_info() | 접속에 사용하고 있는 프로토콜의 버젼을 돌려준다.
mysql_get_server_info() | 서버의 버젼 번호를 돌려준다.
mysql_info() | 마지막에 실행된 쿼리에 관한 정보를 돌려준다.
mysql_init() | MYSQL 구조체를 취득 또는 초기화한다.
mysql_insert_id() | 전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려준다.
mysql_kill() | 지정된 스레드를 강제 종료한다.
mysql_list_dbs() | 단순한 정규 표현에 일치하는 데이타베이스명을 돌려준다.
mysql_list_fields() | 단순한 정규 표현에 일치하는 필드명을 돌려준다.
mysql_list_processes() | 현재의 서바스레드의 일람을 돌려준다.
mysql_list_tables() | 단순한 정규 표현에 일치하는 테이블명을 돌려준다.
mysql_num_fields() | 결과 세트의 컬럼수를 돌려준다.
mysql_num_rows() | 결과 세트의 레코드수를 돌려준다.
mysql_options() | mysql_connect() 의 접속 옵션을 설정한다.
mysql_ping() | 서버에의 접속이 정상적일지를 확인해, 필요하면 재접속한다.
mysql_query() | 눌 종단 문자열로서 지정되어 있다 SQL 쿼리를 실행한다.
mysql_real_connect() | MySQL 서버에 접속한다.
mysql_real_escape_string() | 접속의 현재의 캐릭터 세트를 고려하고, 문자열에 포함되는 특수 문자를 이스케이프 해,SQL 스테이트먼트로 사용할 수 있도록 한다.
mysql_real_query() | 아르바이트 문자열로서 지정되어 있다 SQL 쿼리를 실행한다.
mysql_reload() | 권한 테이블의 재독 봐 포함을 서버에 지시한다.
mysql_row_seek() | mysql_row_tell() (으)로부터 돌려주어진 값을 오프셋으로서 결과 세트내의 레코드에 시크 한다.
mysql_row_tell() | 레코드 커서의 위치를 돌려준다.
mysql_select_db() | 데이타베이스를 선택한다.
mysql_set_server_option() | 접속의 옵션(multi-statements 등)을 설정한다.
mysql_sqlstate() | 마지막에 발생한 에러의 SQLSTATE 에러 코드를 돌려준다.
mysql_shutdown() | 데이터 베이스 서버를 슛다운 한다.
mysql_stat() | 서버 스테이터스를 문자열로서 돌려준다.
mysql_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_thread_id() | 현재의 스레드 ID (을)를 돌려준다.
mysql_thread_safe() | 클라이언트가 스레드세이후로서 컴파일 되고 있는 경우는 1 (을)를 돌려준다.
mysql_use_result() | 레코드 단위의 결과 세트의 취득을 개시한다.
mysql_warning_count() | 전회 실행했다 SQL 스테이트먼트의 경고수를 돌려준다.
mysql_commit() | 트랜잭션(transaction)를 코?~ 트 한다(4.1 의 신기능).
mysql_rollback() | 트랜잭션(transaction)를 롤백(rollback) 한다(4.1 의 신기능).
mysql_autocommit() | 자동코?~ 트모드의 온/ 오프를 바꾼다(4.1 의 신기능).
mysql_more_results() | 아직 취득하고 있지 않는 결과 세트가 존재할지를 조사한다(4.1 의 신기능).
mysql_next_result() | 멀티 쿼리를 실행하고 있는 경우, 다음의 결과 세트를 취득해, 돌려준다(4.1 의 신기능).

서버에 접속하려면 ,mysql_init() (을)를 호출해 접속 핸들러를 초기화해, 다음에 그 핸들러( 및 호스트명, 유저명, 패스워드등의 그 외의 정보)를 파라미터로서 mysql_real_connect() (을)를 호출합니다.접속이 확립했을 때,mysql_real_connect() 에 의해서 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.접속이 필요없게 되면,mysql_close() (을)를 호출해 접속을 절단 합니다.

접속이 액티브한 경우, 클라이언트는 mysql_query() 또는 mysql_real_query() (을)를 사용해 서버에 SQL 쿼리를 송신할 수 있습니다.이 2 개의 차이는,mysql_query() (은)는 쿼리를 눌 종단 문자열로서mysql_real_query() (은)는 쿼리를 아르바이트 문자열로서 각각 받습니다.문자열에 바이너리 데이터가 포함되는(누르바이트가 포함될 가능성이 있다) 경우는,mysql_real_query() (을)를 사용할 필요가 있습니다.

비 SELECT 쿼리(예를 들어,INSERT ,UPDATE ,DELETE )(을)를 실행했을 경우, 변경된(영향을 받은) 레코드의 수를 알려면 ,mysql_affected_rows() (을)를 호출합니다.

SELECT 쿼리를 실행했을 경우, 선택된 레코드를 결과 세트로서 취득합니다(주의: SHOW ,DESCRIBE , 및 EXPLAIN (와)과 같이, 레코드를 돌려준다고 하는 점으로 SELECT (을)를 닮아 있는 스테이트먼트가 있어, 이것들은 SELECT 스테이트먼트와 같게 취급할 필요가 있습니다).

클라이언트가 결과 세트를 처리하는 방법은 2 개 있습니다.1 개는,mysql_store_result() (을)를 호출해 결과 세트 전체를 일괄해 취득하는 방법입니다.이 함수는, 쿼리로부터 돌려주어진 모든 레코드를 서버로부터 취득해, 클라이언트에 보존합니다.이제(벌써) 1 개는,mysql_use_result() (을)를 호출하고, 클라이언트가 레코드 단위로 결과 세트의 취득을 개시하는 방법입니다.이 함수는 결과 세트를 취득하는 처리의 초기화는 실시합니다만, 실제로는 서버로부터 레코드를 받고 있지 않습니다.

어느 쪽의 경우도, 레코드에 액세스 하려면 mysql_fetch_row() (을)를 호출합니다.mysql_store_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는, 벌써 서버로부터 취득되고 있는 레코드에 액세스 합니다.mysql_use_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는 실제로 서버로부터 레코드를 취득합니다.각 레코드의 데이터 사이즈는,mysql_fetch_lengths() (을)를 호출하는 것에 의해서 알 수 있습니다.

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출하고, 사용하고 있던 메모리를 해방합니다.

2 개의 취득 메카니즘은, 상황에 따라 구분하여 사용합니다.클라이언트 프로그램은, 필요에 따라서 가장 적절한 방법을 선택할 필요가 있습니다.실제로는,mysql_store_result() (을)를 다용하는 경향이 있습니다.

mysql_store_result() 의 장점은, 모든 레코드가 클라이언트에 취득이 끝난 상태이므로, 레코드에 차례차례 액세스 가능할 뿐만 아니라,mysql_data_seek() 또는 mysql_row_seek() (을)를 사용해 결과 세트내에서의 경향 레코드의 위치를 변경하는 것에 의해서, 결과 세트내를 전후로 이동할 수 있는 것입니다.결과 세트에 포함되는 레코드수를 알려면 ,mysql_num_rows() (을)를 호출합니다.한편, 결과 세트가 큰 경우의 mysql_store_result() 의 메모리 요건은 매우 어려운 경우가 있어, 메모리 부족이 발생할 가능성은 높아집니다.

mysql_use_result() 의 장점은, 한 번에 1 행의 레코드 밖에 보관 유지하지 않기 때문에, 클라이언트가 결과 세트로 사용하는 메모리가 적어도 되는 것입니다(또, 메모리 할당의 오버헤드가 적기 때문에 mysql_use_result() 의 실행 속도도 향상합니다).단점은, 서버를 구속하지 않게 각 레코드에 대한 처리를 단시간에 끝낼 필요가 있는 것, 결과 세트내의 레코드에 대한 랜덤 억세스 기능이 없는 것(차례차례 액세스만), 모든 레코드를 취득할 때까지 결과 세트에 포함되는 레코드수를 모르는 것입니다.게다가 찾고 있던 정보가 차례차례 액세스의 도중에 발견되었을 경우에서도, 끝까지 모든 레코드를 취득한다 필요가 있습니다 .

클라이언트는 API (을)를 사용하는 것으로, 쿼리가 SELECT 화도인가를 몰라도, 쿼리에 대해서 적절히 응답하는(필요에 따라서 레코드를 취득한다) 일이 생깁니다.그러기 위해서는,mysql_query() (또는 mysql_real_query() )(을)를 호출할 때마다 mysql_store_result() (을)를 호출합니다.이 호출이 정상 종료했을 경우, 쿼리는 SELECT (이었)였던 것으로 되고, 레코드를 읽어들일 수 있습니다.호출이 실패했을 경우,mysql_field_count() (을)를 호출하고, 이 결과가 쿼리의 결과로서 예상된 것이었다 화도인지를 판단합니다.mysql_field_count() 하지만 0 (을)를 돌려주었을 경우, 쿼리가 돌려준 데이터는 없고(INSERT ,UPDATE ,DELETE 등의 쿼리였던 일을 의미한다), 레코드를 돌려주는 쿼리는 아니었다고 판단됩니다.mysql_field_count() 하지만 0 이외의 값을 돌려주었을 경우, 레코드를 돌려주어야할 쿼리가 실행되었지만, 아무것도 돌려주지 않았다고 판단됩니다.이것은,SELECT 쿼리가 실패한 것을 의미합니다.여기에 나타낸 방법의 코딩예에 대해서는,mysql_field_count() 의 설명을 참조해 주세요.

mysql_store_result() 및 mysql_use_result() (은)는 어느쪽이나, 결과 세트를 구성하는 필드에 관한 정보(필드의 수, 이름, 형태등)를 취득합니다.레코드의 필드 정보로 차례차례 액세스 하려면 ,mysql_fetch_field() (을)를 반복해 호출하는지, 또는 레코드의 필드 번호를 지정해 mysql_fetch_field_direct() (을)를 호출합니다.현재의 필드 커서의 위치를 변경하려면 ,mysql_field_seek() (을)를 호출합니다.필드 커서의 위치를 변경하면, 그 후에 불려 갔다 mysql_fetch_field() 의 동작에 영향을 줍니다.mysql_fetch_fields() (을)를 호출하면, 모든 필드의 정보를 일괄해 취득할 수 있습니다.

에러를 검출해, 보고하는 경우,mysql_errno() 및 mysql_error() (을)를 사용해 에러 정보로 액세스 합니다.이 2 개의 함수는, 마지막에 불려 간, 성공 또는 실패의 가능성이 있는 함수의 에러 코드 또는 에러 메세지를 돌려줍니다.이 결과에 의해서, 에러가 발생한 타이?~ 그와 그 내용을 판단합니다.

11.1.3. C API 함수의 설명

여기의 설명속에서, 파라미터 또는 반환값에 NULL 하지만 사용되고 있는 경우, 이것은 C 언어에 있어서의 NULL (을)를 나타내고 있어MySQL 에 있어서의 NULL 값이 아닙니다.

값을 돌려주는 함수는, 일반적으로 포인터 또는 정수를 돌려줍니다.특히 지정되어 있지 않은 한, 포인터를 돌려주는 함수가 비 NULL 값을 돌려주었을 경우는 정상 종료를,NULL 값을 돌려주었을 경우는 에러를 나타냅니다.같이 정수를 돌려주는 함수가 0 (을)를 돌려주었을 경우는 정상 종료를,0 이외의 값을 돌려주었을 경우는 에러를 나타냅니다.주의: ``0 이외'' 그렇다고 하는 것에, 그 이상의 의미는 없습니다.함수 설명에 특히 기술이 없는 한,0 이외의 값에 대해서 비교 테스트는 필요 없습니다.

if (result)                   /* correct */
    ... error ...

if (result < 0)               /* incorrect */
    ... error ...

if (result == -1)             /* incorrect */
    ... error ...

함수가 돌려주는 에러에 대해서는, 함수 설명안의 「 에러 」서브 섹션을 참조해 주세요.발생한 에러를 조사하려면 ,mysql_errno() (을)를 호출합니다.mysql_error() (을)를 호출하면, 에러 내용의 문자열 표현을 취득할 수 있습니다.

11.1.3.1. mysql_affected_rows()

my_ulonglong mysql_affected_rows(MYSQL *mysql)

설명

마지막에 불려 갔다 UPDATE 에 의해서 변경된 레코드수, 마지막에 불려 갔다 DELETE 에 의해서 삭제된 레코드수, 또는 마지막에 불려 갔다 INSERT 에 의해서 삽입된 레코드수를 돌려줍니다.UPDATE ,DELETE , 또는 INSERT 의 몇개의 스테이트먼트에 대해 mysql_query() (을)를 호출한 후에, 이 함수를 호출합니다.SELECT 스테이트먼트의 경우,mysql_affected_rows() (을)를 호출하면,mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해서 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타내 보입니다.-1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_store_result() (을)를 호출하기 전에 mysql_affected_rows() 하지만 불려 간 것을 나타내 보입니다.

에러

없습니다.

례

mysql_query(&mysql,"UPDATE products SET cost=cost*1.25 WHERE group=10");
printf("%ld products updated",(long) mysql_affected_rows(&mysql));

mysqld 에 접속할 때에 플래그 CLIENT_FOUND_ROWS 하지만 지정되어 있는 경우,mysql_affected_rows() 하 UPDATE 스테이트먼트의 WHERE 마디에 일치하는 레코드수를 돌려줍니다.

주의: REPLACE 커멘드로 기존의 레코드가 새로운 레코드로 옮겨놓을 수 있었을 경우는 mysql_affected_rows() 하 2 (을)를 돌려줍니다.이것은, 레코드가 1 행 삽입된 다음에 중복 한 레코드가 삭제되었기 때문입니다.

11.1.3.2. mysql_change_user()

my_bool mysql_change_user(MYSQL *mysql, const char *user, const char *password, const char *db)

설명

유저를 변경해,db 그리고 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

이 함수는,MySQL 3.23.3 그리고 도입되었습니다.

mysql_change_user() (은)는, 지정한 유저가 인증되지 않는 경우, 또는 그 유저가 데이타베이스를 사용하는 권한을 가지지 않는 경우에, 실패합니다.이 경우, 유저 및 데이타베이스는 변경되지 않습니다.

디폴트 데이타베이스를 사용하지 않는 경우,db 파라미터를 NULL (으)로 설정합니다.

MySQL 4.0.6 이?~ , 이 커멘드는, 새로운 접속이 확립했을 경우는 항상, 임의의 액티브한 트랜잭션(transaction)의 ROLLBACK 의 실행, 모든 텐포라리테이불의 클로우즈, 락 된 모든 테이블의 언로크, 및 상태의 리셋트를 실시합니다.이 처리는, 유저가 변경되지 않았던 경우도 반드시 행해집니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

mysql_real_connect() 하지만 돌려주는 에러와 같다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • ER_UNKNOWN_COM_ERROR

    MySQL 서버로 이 커멘드가 실장되어 있지 않다(버젼이 낡다고 생각할 수 있다).

  • ER_ACCESS_DENIED_ERROR

    유저 또는 패스워드가 올바르지 않다.

  • ER_BAD_DB_ERROR

    데이타베이스가 존재하지 않는다.

  • ER_DBACCESS_DENIED_ERROR

    유저가 데이타베이스에의 액세스권을 가지고 있지 않다.

  • ER_WRONG_DB_NAME

    데이타베이스명이 너무 길다.

례

if (mysql_change_user(&mysql, "user", "password", "new_database"))
{
   fprintf(stderr, "Failed to change user.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.3. mysql_character_set_name()

const char *mysql_character_set_name(MYSQL *mysql)

설명

현재의 접속의 디폴트의 캐릭터 세트를 돌려줍니다.

반환값

디폴트의 캐릭터 세트.

에러

없습니다.

11.1.3.4. mysql_close()

void mysql_close(MYSQL *mysql)

설명

벌써 오픈되고 있는 접속을 클로우즈 합니다.mysql 그리고 나타나는 접속 핸들이 mysql_init() 또는 mysql_connect() 에 의해서 자동적으로 할당할 수 있었던 핸들이었던 경우는,mysql_close() 그리고 할당이 해제됩니다.

반환값

없습니다.

에러

없습니다.

11.1.3.5. mysql_connect()

MYSQL *mysql_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd)

설명

이 함수는 폐?~ 되고 있습니다.대신에 mysql_real_connect() (을)를 사용해 주세요.

mysql_connect() (은)는,host 위에서 실행하고 있다 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 의미는,mysql_real_connect() (으)로의 대응하는 파라미터와 같습니다만, 접속 파라미터에 NULL (을)를 건네줄 수 있다고 하는 차이가 있습니다.이 경우,C API (은)는 접속 구조체에 자동적으로 메모리를 할당합니다.이 메모리는 mysql_close() (을)를 호출하는 것에 의해서 해방됩니다.이 방법에는, 접속에 실패했을 때에 에러 메세지를 취득할 수 없다고 하는 단점이 있습니다(mysql_errno() 또는 mysql_error() (으)로부터 에러 정보를 취득하려면 유효한 MYSQL 포인터를 건네줄 필요가 있습니다).

반환값

mysql_real_connect() (와)과 같습니다.

에러

mysql_real_connect() (와)과 같습니다.

11.1.3.6. mysql_create_db()

int mysql_create_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름으로 데이타베이스를 작성합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 CREATE DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 작성되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_create_db(&mysql, "my_database"))
{
   fprintf(stderr, "Failed to create new database.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.7. mysql_data_seek()

void mysql_data_seek(MYSQL_RES *result, my_ulonglong offset)

설명

쿼리 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_data_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.3.8. mysql_debug()

void mysql_debug(const char *debug)

설명

지정된 문자열로 DBUG_PUSH (을)를 실행합니다.mysql_debug() (은)는,Fred Fish 디버그 라이브러리를 사용합니다.이 함수를 사용하려면 , 디버그를 서포트하기 위한 클라이언트 라이브러리를 컴파일 할 필요가 있습니다. See 항E.1. 「MySQL 서버의 디버그」 . See 항E.2. 「MySQL 클라이언트의 디버그」 .

반환값

없습니다.

에러

없습니다.

례

다음의 코드를 실행하면, 클라이언트 라이브러리에 의해서 클라이언트 머신의 /tmp/client.trace 에 트레이스 파일이 생성됩니다.

mysql_debug("d:t:O,/tmp/client.trace");

11.1.3.9. mysql_drop_db()

int mysql_drop_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름의 데이타베이스를 파기합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 DROP DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 파기되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_drop_db(&mysql, "my_database"))
  fprintf(stderr, "Failed to drop the database: Error: %s\n",
          mysql_error(&mysql));

11.1.3.10. mysql_dump_debug_info()

int mysql_dump_debug_info(MYSQL *mysql)

설명

디버그 정보를 로그에 쓰도록(듯이) 서버에 지시합니다.접속 유저가 SUPER 특권을 가지지 않는 경우는 정상적으로 동작하지 않습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.11. mysql_eof()

my_bool mysql_eof(MYSQL_RES *result)

설명

이 함수는 폐?~ 되고 있습니다.대신에 mysql_errno() 또는 mysql_error() (을)를 사용할 수 있습니다.

mysql_eof() (은)는, 결과 세트의 마지막 레코드가 읽혔는지를 판정합니다.

mysql_store_result() (을)를 호출해 결과 세트를 취득하는 경우, 클라이언트는 1 회의 동작으로 결과 세트 전체를 받습니다.이 경우,mysql_fetch_row() (을)를 호출해 반환값이 NULL 이면, 벌써 결과 세트의 마지막에 도달하고 있던 것을 알 수 있으므로,mysql_eof() (을)를 호출할 필요는 없습니다.mysql_store_result() (와)과 함께 사용하는 경우,mysql_eof() (은)는 항상 true (을)를 돌려줍니다.

한편,mysql_use_result() (을)를 사용해 결과 세트의 취득을 개시했을 경우는,mysql_fetch_row() (을)를 반복해 호출하는 것에 의해서 그 레코드를 1 행씩 서버로부터 취득합니다.이 순서를 실행하고 있는 도중에 접속에 이상이 발생하는 경우가 있으므로,mysql_fetch_row() (을)를 호출해 반환값이 NULL 에서 만나도, 그것이 반드시 결과 세트의 마지막에 정상적으로 도달한 것을 의미하는 것은 아닙니다.이 경우는,mysql_eof() (을)를 사용하는 것에 의해서, 어떤 상황인가를 판단할 수 있습니다.mysql_eof() (은)는, 결과 세트의 마지막에 도달하고 있었을 경우는 0 이외, 에러가 발생하고 있었을 경우는 0 (을)를 돌려줍니다.

mysql_eof() (은)는, 역사적으로는 표준의 MySQL 에러 함수이다 mysql_errno() 및 mysql_error() 의 전신입니다.이러한 에러 함수는 같은 정보를 돌려주므로, 벌써 폐?~ 되고 있다 mysql_eof() 보다 우선해 사용해 주세요(실제,mysql_eof() 하지만 돌려주는 것은 불리언 값만으로, 에러 함수는 에러 발생 이유를 나타내는 것보다 많은 정보를 돌려줍니다).

반환값

에러가 발생하고 있지 않는 경우는 0 .결과 세트의 마지막에 도달하고 있었을 경우는 0 이외.

에러

없습니다.

례

mysql_eof() 에는 다음과 같은 사용법을 생각할 수 있습니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(!mysql_eof(result))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

다만, 표준의 MySQL 에러 함수를 다음과 같이 사용하면, 같은 동작을 실현할 수 있습니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(mysql_errno(&mysql))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

11.1.3.12. mysql_errno()

unsigned int mysql_errno(MYSQL *mysql)

설명

mysql_errno() (은)는,mysql 그리고 지정되는 접속에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있다 API 함수의 에러 코드를 돌려줍니다.반환값이 0 의 경우, 에러는 발생하고 있지 않습니다.클라이언트의 에러 메세지 번호의 일람은,MySQL errmsg.h 헤더 파일에 기술되고 있습니다.서버의 에러 메세지 번호의 일람은,mysqld_error.h 에 기술되고 있습니다.MySQL 소스 디스트리뷰션에 포함되는 파일 Docs/mysqld_error.txt 에는, 모든 에러 메세지 및 에러 번호의 일람이 기술되고 있습니다.서버의 에러 코드의 일람은, 항12.1. 「돌려주어지는 에러」 에도 기재되어 있습니다.

주의: mysql_fetch_row() 등의 일부의 함수는, 성공했을 경우에 mysql_errno() (을)를 설정하지 않습니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_errno() (을)를 리셋트 한다고 생각해 주세요.

반환값

마지막에 불려 갔다 mysql_xxx 함수가 실패하고 있었을 경우는 그 에러 코드.0 (은)는 에러가 발생하지 않았던 것을 나타냅니다.

에러

없습니다.

11.1.3.13. mysql_error()

const char *mysql_error(MYSQL *mysql)

설명

mysql_error() (은)는,mysql 그리고 지정된 접속에 대해서, 마지막에 불려 갔다 API 함수가 실패했을 때의 에러 메세지를 눌 종단 문자열로서 돌려줍니다.함수가 실패하지 않았던 경우,mysql_error() 의 반환값은 그 전의 에러 메세지인가, 에러가 전혀 발생하고 있지 않는 경우는 공문자열이 됩니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_error() (을)를 리셋트 한다고 생각해 주세요.

mysql_errno (을)를 리셋트 하는 함수에서는, 다음의 2 개의 비교는 동등합니다.

if(mysql_errno(&mysql))
{
    // an error occurred
}

if(mysql_error(&mysql)[0] != '\0')
{
    // an error occurred
}

클라이언트의 에러 메세지의 언어는,MySQL 클라이언트 라이브러리를 재컴파일 하는 것에 의해서 변경할 수 있습니다.현재는, 복수가 다른 언어로 에러 메세지를 돌려줄 수 있습니다. See 항4.7.2. 「영어 이외의 에러 메세지」 .

반환값

에러의 내용을 설명하는 눌 종단 문자열.에러가 발생하고 있지 않는 경우는 공문자열.

에러

없습니다.

11.1.3.14. mysql_escape_string()

이 함수 대신에 mysql_real_escape_string() (을)를 사용해 주세요.

mysql_real_escape_string() (은)는 선두의 인수로서 접속 핸들러를 받아, 현재의 캐릭터 세트에 따라서 문자열을 이스케이프 합니다만, 그 2 점을 제외하면, 이 함수와 mysql_real_escape_string() (은)는 같습니다.mysql_escape_string() (은)는 접속 핸들러를 인수로서 받지 않습니다.또, 현재의 캐릭터 세트는 참조하지 않습니다.

11.1.3.15. mysql_fetch_field()

MYSQL_FIELD *mysql_fetch_field(MYSQL_RES *result)

설명

결과 세트에 포함된다 1 살의 컬럼의 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.결과 세트에 포함되는 모든 컬럼의 정의를 취득하려면 , 이 함수를 반복해 호출합니다.정의를 취득하는 컬럼이 남지 않은 경우,mysql_fetch_field() 하 NULL (을)를 돌려줍니다.

새롭고 SELECT 쿼리를 실행할 때마다,mysql_fetch_field() (은)는 선두의 컬럼의 정의를 돌려주도록(듯이) 리셋트 됩니다.또,mysql_field_seek() (을)를 호출했을 경우도,mysql_fetch_field() 하지만 돌려주는 필드가 바뀝니다.

mysql_query() (을)를 호출해 테이블에 대해서 SELECT (을)를 실행한 후 mysql_store_result() (을)를 호출하지 않았던 경우,mysql_fetch_field() (을)를 호출해 BLOB 필드의 길이를 요구하면, 디폴트의 BLOB 장(8 킬로바이트)가 돌려주어집니다(MySQL 하 BLOB 의 최대장을 모르기 때문에 8 킬로바이트를 돌려줍니다.이 값은 장래 설정 가능한 값으로 할 필요가 있습니다).결과 세트를 취득한 다음은, 그 쿼리에 있어서의 이 컬럼의 최대치의 길이가 field->max_length 에게 건네집니다.

반환값

현재의 컬럼의 MYSQL_FIELD 구조체.컬럼이 남지 않은 경우는 NULL .

에러

없습니다.

례

MYSQL_FIELD *field;

while((field = mysql_fetch_field(result)))
{
    printf("field name %s\n", field->name);
}

11.1.3.16. mysql_fetch_fields()

MYSQL_FIELD *mysql_fetch_fields(MYSQL_RES *result)

설명

결과 세트의 모든 MYSQL_FIELD 구조체의 배열을 돌려줍니다.각 구조체에는, 결과 세트에 포함된다 1 살의 컬럼의 필드 정의가 격납되고 있습니다.

반환값

결과 세트에 포함되는 모든 컬럼의 MYSQL_FIELD 구조체의 배열.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *fields;

num_fields = mysql_num_fields(result);
fields = mysql_fetch_fields(result);
for(i = 0; i < num_fields; i++)
{
   printf("Field %u is %s\n", i, fields[i].name);
}

11.1.3.17. mysql_fetch_field_direct()

MYSQL_FIELD *mysql_fetch_field_direct(MYSQL_RES *result, unsigned int fieldnr)

설명

필드 번호 fieldnr 그리고 지정되는 결과 세트의 컬럼의 필드 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.이 함수를 사용하면, 임의의 컬럼의 정의를 취득할 수 있습니다.fieldnr 의 값은 0 (으)로부터 mysql_num_fields(result)-1 의 범위에서 지정합니다.

반환값

지정한 컬럼의 MYSQL_FIELD 구조체.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *field;

num_fields = mysql_num_fields(result);
for(i = 0; i < num_fields; i++)
{
    field = mysql_fetch_field_direct(result, i);
    printf("Field %u is %s\n", i, field->name);
}

11.1.3.18. mysql_fetch_lengths()

unsigned long *mysql_fetch_lengths(MYSQL_RES *result)

설명

결과 세트내의 경향 레코드의 컬럼의 길이를 돌려줍니다.필드치를 카피하려고 하는 경우, 이 함수를 사용하면 strlen() (을)를 호출하지 않아도 길이를 취득할 수 있으므로 편리합니다.또, 결과 세트에 바이너리 데이터가 포함되어 있는 경우,strlen() (은)는 눌 문자가 포함되는 필드의 길이를 올바르게 돌려주지 않기 때문에, 이 함수를 사용해 데이터 사이즈를 조사한다 필요가 있습니다 .

하늘의 컬럼 및 NULL 값을 포함한 컬럼의 길이는 0 입니다.이 2 개를 구별하는 방법에 대해서는,mysql_fetch_row() 의 설명을 참조해 주세요.

반환값

각 컬럼의 사이즈(눌 종단 문자는 세지 않는다)를 나타낸다 unsigned long 정수의 배열.에러가 발생했을 경우는 NULL .

에러

mysql_fetch_lengths() (은)는 결과 세트의 경향 레코드에서만 유효합니다.mysql_fetch_row() (을)를 호출하기 전 또는 결과 세트의 모든 레코드를 취득한 다음에 불려 갔을 경우는 NULL (을)를 돌려줍니다.

례

MYSQL_ROW row;
unsigned long *lengths;
unsigned int num_fields;
unsigned int i;

row = mysql_fetch_row(result);
if (row)
{
    num_fields = mysql_num_fields(result);
    lengths = mysql_fetch_lengths(result);
    for(i = 0; i < num_fields; i++)
    {
         printf("Column %u is %lu bytes in length.\n", i, lengths[i]);
    }
}

11.1.3.19. mysql_fetch_row()

MYSQL_ROW mysql_fetch_row(MYSQL_RES *result)

설명

결과 세트의 다음의 레코드를 취득합니다.mysql_store_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않으면 NULL (을)를 돌려줍니다.mysql_use_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않은지, 또는 에러가 발생했을 때에 NULL (을)를 돌려줍니다.

레코드에 포함되는 값의 수는 mysql_num_fields(result) 에 의해서 취득합니다.mysql_fetch_row() (을)를 호출해 그 반환값이 row 에 격납되고 있는 경우, 값에의 포인터는 row[0] (으)로부터 row[mysql_num_fields(result)-1] (와)과 같이 나타내집니다.NULL 포인터는, 레코드의 값이 NULL 값인 것을 나타냅니다.

mysql_fetch_lengths() (을)를 호출하면, 레코드의 필드치의 길이를 취득할 수 있습니다.하늘의 필드 및 NULL (을)를 포함한 필드의 길이는 어느쪽이나 0 그렇지만, 그 필드의 포인터를 조사하는 것에 의해서 그 2 개를 구별할 수 있습니다.포인터가 NULL 의 경우, 필드의 값은 NULL 입니다.그 이외의 경우, 필드는 하늘입니다.

반환값

다음의 레코드의 MYSQL_ROW 구조체.취득하는 레코드가 남지 않은지, 에러가 발생했을 경우는 NULL .

에러

주의: mysql_fetch_row() (을)를 1 회 호출하고 나서, 다음에 호출할 때까지 에 에러가 리셋트 될 것은 없습니다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

MYSQL_ROW row;
unsigned int num_fields;
unsigned int i;

num_fields = mysql_num_fields(result);
while ((row = mysql_fetch_row(result)))
{
   unsigned long *lengths;
   lengths = mysql_fetch_lengths(result);
   for(i = 0; i < num_fields; i++)
   {
       printf("[%.*s] ", (int) lengths[i], row[i] ? row[i] : "NULL");
   }
   printf("\n");
}

11.1.3.20. mysql_field_count()

unsigned int mysql_field_count(MYSQL *mysql)

MySQL 3.22.24 보다 낡은 버젼을 사용하고 있는 경우, 이 함수 대신에 unsigned int mysql_num_fields(MYSQL *mysql) (을)를 사용해 주세요.

설명

현재의 접속으로 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려줍니다.

통상 이 함수는,mysql_store_result() 하지만 NULL (을)를 돌려주었을 때(결과 세트 포인터가 돌려주어지지 않았을 때)에 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해서,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해서, 클라이언트 프로그램은, 쿼리가 SELECT (또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql,query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if(mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
        else // mysql_store_result() should have returned data
        {
            fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
    }
}

mysql_field_count(&mysql) 의 호출 부분을 mysql_errno(&mysql) 에 옮겨놓는 방법도 있습니다.이 경우, 스테이트먼트가 SELECT (이었)였는지 아닌지는,mysql_field_count() 하지만 돌려주는 값으로부터 추측하는 것이 아니라,mysql_store_result() 하지만 돌려주는 에러를 직접 조사하고 판단합니다.

11.1.3.21. mysql_field_seek()

MYSQL_FIELD_OFFSET mysql_field_seek(MYSQL_RES *result, MYSQL_FIELD_OFFSET offset)

설명

필드 커서의 위치를 지정된 오프셋으로 설정합니다.다음에 mysql_fetch_field() (을)를 호출하면, 그 오프셋에 관련지을 수 있었던 컬럼의 필드 정의를 돌려줍니다.

레코드의 선두에 시크 하려면 ,offset 값에 0 (을)를 건네줍니다.

반환값

시크 하기 전의 필드 커서의 값.

에러

없습니다.

11.1.3.22. mysql_field_tell()

MYSQL_FIELD_OFFSET mysql_field_tell(MYSQL_RES *result)

설명

마지막에 실행되었다 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려줍니다.이 반환값을,mysql_field_seek() 에 인수로서 건네줄 수 있습니다.

반환값

필드 커서의 현재의 오프셋.

에러

없습니다.

11.1.3.23. mysql_free_result()

void mysql_free_result(MYSQL_RES *result)

설명

          mysql_store_result()
,mysql_use_result()
,mysql_list_dbs()

등이 결과 세트에 할당한 메모리를 해방합니다.결과 세트가 필요없게 되면,mysql_free_result()

(을)를 호출하고, 사용하고 있던 메모리를 해방합니다.

반환값

없습니다.

에러

없습니다.

11.1.3.24. mysql_get_client_info()

char *mysql_get_client_info(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 문자열을 돌려줍니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 문자열.

에러

없습니다.

11.1.3.25. mysql_get_client_version()

unsigned long mysql_get_client_version(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 정수를 돌려줍니다.이 값은 XYYZZ 그렇다고 하는 형식에서 나타내져X (은)는 메이저 버젼,YY (은)는 릴리스 레벨,ZZ (은)는 릴리스 레벨내의 버젼 번호입니다.예를 들어,40102 (은)는, 클라이언트의 라이브러리 버젼이 4.1.2 인 것을 나타냅니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 정수.

에러

없습니다.

11.1.3.26. mysql_get_host_info()

char *mysql_get_host_info(MYSQL *mysql)

설명

사용하고 있는 접속의 타입을 나타내는 문자열을 돌려줍니다.이 문자열에는 서버의 호스트명도 포함됩니다.

반환값

서버의 호스트명 및 접속 타입을 나타내는 문자열.

에러

없습니다.

11.1.3.27. mysql_get_proto_info()

unsigned int mysql_get_proto_info(MYSQL *mysql)

설명

현재의 접속에 사용하고 있는 프로토콜의 버젼을 돌려줍니다.

반환값

현재의 접속에 사용하고 있는 프로토콜의 버젼을 나타낸다 unsigned 정수.

에러

없습니다.

11.1.3.28. mysql_get_server_info()

char *mysql_get_server_info(MYSQL *mysql)

설명

서버의 버젼 번호를 나타내는 문자열을 돌려줍니다.

반환값

서버의 버젼 번호를 나타내는 문자열.

에러

없습니다.

11.1.3.29. mysql_get_server_version()

unsigned long mysql_get_server_version(MYSQL *mysql)

설명

서버의 버젼 번호를 정수로서 돌려줍니다(4.1 의 신기능).

반환값

MySQL 서버의 버젼을 다음의 형식에서 나타내는 번호.

main_version*10000 + minor_version *100 + sub_version

예를 들어, 버젼이 4.1.0 의 경우, 반환값은 40100 입니다.

이 값을 사용하면, 클라이언트 프로그램은 서버의 버젼으로부터 특정의 기능이 존재할지를 간단하게 판단할 수 있습니다.

에러

없습니다.

11.1.3.30. mysql_info()

char *mysql_info(MYSQL *mysql)

설명

마지막에 실행한 쿼리에 관한 정보를 나타내는 문자열을 취득합니다.다만, 대상이 되는 것은, 이하의 일람에 포함되는 스테이트먼트만입니다.마지막에 실행한 것이 다른 스테이트먼트의 쿼리였던 경우는,mysql_info() 하 NULL (을)를 돌려줍니다.문자열의 형식은, 이하에 설명하도록(듯이), 쿼리의 타입에 따라서 다릅니다.숫자는 예로서 나타내 보인 것입니다.실제의 문자열에는 실행한 쿼리에 맞은 값이 사용됩니다.

  • INSERT INTO ...SELECT ...

    문자열의 형식: Records: 100 Duplicates: 0 Warnings: 0

  • INSERT INTO ...VALUES (...),(...),(...)...

    문자열의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • LOAD DATA INFILE ...

    문자열의 형식: Records: 1 Deleted: 0 Skipped: 0 Warnings: 0

  • ALTER TABLE

    문자열의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • UPDATE

    문자열의 형식: Rows matched: 40 Changed: 40 Warnings: 0

주의: mysql_info() (은)는,INSERT ... VALUES 스테이트먼트가 복수 레코드를 삽입하는 형식의 경우에 한정해(복수의 값리스트가 지정되었을 경우에 한정해),NULL 이외의 값을 돌려줍니다.

반환값

마지막에 실행한 쿼리에 관한 정보를 나타내는 문자열.쿼리의 정보가 없는 경우는 NULL .

에러

없습니다.

11.1.3.31. mysql_init()

MYSQL *mysql_init(MYSQL *mysql)

설명

mysql_real_connect() 에 적응한다 MYSQL 오브젝트를 할당해 또는 초기화합니다.mysql 에 NULL 포인터를 건네주었을 경우, 함수는 새로운 오브젝트에 메모리를 할당해 초기화해, 그것을 돌려줍니다.그 이외의 값을 건네주었을 경우는, 오브젝트를 초기화해, 그 주소를 돌려줍니다.mysql_init() 하지만 새로운 오브젝트에 메모리를 할당했을 경우, 그 메모리는 mysql_close() (을)를 호출해 접속을 클로우즈 할 때에 해방됩니다.

반환값

초기화되었다 MYSQL* 핸들.새로운 오브젝트에 할당하는 충분한 메모리가 없었던 경우는 NULL .

에러

메모리가 부족했을 경우는 NULL (을)를 돌려줍니다.

11.1.3.32. mysql_insert_id()

my_ulonglong mysql_insert_id(MYSQL *mysql)

설명

전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려줍니다.이 함수는,AUTO_INCREMENT 필드를 포함한 테이블에 대해서 INSERT 쿼리를 실행한 다음에 사용합니다.

주의: mysql_insert_id() (은)는, 전회 실행된 쿼리로 AUTO_INCREMENT 값이 생성되지 않았던 경우는,0 (을)를 돌려줍니다.장래를 위해서 그 값을 보존할 필요가 있는 경우는, 그것을 생성하는 쿼리의 직후에 mysql_insert_id() (을)를 호출할 필요가 있습니다.

전회 실행된 쿼리가 에러를 돌려주었을 경우에 대해서는,mysql_insert_id() 의 값은 미정도리입니다.

mysql_insert_id() (은)는,AUTO_INCREMENT 값을 생성하는지, 또는 컬럼치를 LAST_INSERT_ID(expr) (으)로 설정한다 INSERT 스테이트먼트 및 UPDATE 스테이트먼트의 실행 후에 갱신됩니다. See 항6.3.6.2. 「그 외의 각종 함수」 .

주의: SQL LAST_INSERT_ID() 함수의 값에는, 반드시 마지막에 생성되었다 AUTO_INCREMENT 값이 포함됩니다.이 값은 서버에 보관 유지되므로, 어느 쿼리를 실행하고 나서 다음의 쿼리를 실행할 때까지 에 리셋트 될 것은 없습니다.

반환값

전회 실행된 쿼리에 의해서 갱신되었다 AUTO_INCREMENT 필드의 값.현재의 접속으로 아직 1 회도 쿼리가 실행되어 있지 않았던 경우, 또는 전회 실행된 쿼리로 AUTO_INCREMENT 값이 갱신되지 않았던 경우,0 (을)를 돌려줍니다.

에러

없습니다.

11.1.3.33. mysql_kill()

int mysql_kill(MYSQL *mysql, unsigned long pid)

설명

pid 그리고 지정하는 스레드를 강제 종료하도록(듯이), 서버에 요구합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.34. mysql_list_dbs()

MYSQL_RES *mysql_list_dbs(MYSQL *mysql, const char *wild)

설명

서버상의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 데이타베이스명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 데이타베이스명이 일치합니다.mysql_list_dbs() (을)를 호출하면, 쿼리 SHOW databases [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.35. mysql_list_fields()

MYSQL_RES *mysql_list_fields(MYSQL *mysql, const char *table, const char *wild)

설명

지정된 테이블의 필드로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 필드명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 필드명이 일치합니다.mysql_list_fields() (을)를 호출하면, 쿼리 SHOW COLUMNS FROM tbl_name [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

주의: mysql_list_fields() 대신에 SHOW COLUMNS FROM tbl_name (을)를 사용하는 것을 추천 합니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.36. mysql_list_processes()

MYSQL_RES *mysql_list_processes(MYSQL *mysql)

설명

현재의 서바스레드의 일람을 나타내는 결과 세트를 돌려줍니다.이것은,mysqladmin processlist 또는 SHOW PROCESSLIST 쿼리가 돌려주는 정보와 같은 타입의 정보입니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.37. mysql_list_tables()

MYSQL_RES *mysql_list_tables(MYSQL *mysql, const char *wild)

설명

현재의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 테이블명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 테이블명이 일치합니다.mysql_list_tables() (을)를 호출하면, 쿼리 SHOW tables [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.38. mysql_num_fields()

unsigned int mysql_num_fields(MYSQL_RES *result)

또는

unsigned int mysql_num_fields(MYSQL *mysql)

2 번째의 형식은,MySQL 3.22.24 이?~ 그럼 동작하지 않습니다.MYSQL* 인수를 건네주려면 , 이 함수 대신에 unsigned int mysql_field_count(MYSQL *mysql) (을)를 사용할 필요가 있습니다.

설명

결과 세트의 컬럼수를 돌려줍니다.

주의: 결과 세트에의 포인터 또는 접속 핸들에의 포인터의 어느 쪽을 사용해도, 컬럼수를 취득할 수 있습니다.mysql_store_result() 또는 mysql_use_result() 하지만 NULL (을)를 돌려주었을 경우(결과 세트 포인터가 돌려주어지지 않았던 경우)는, 접속 핸들을 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해서,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해서, 클라이언트 프로그램은, 쿼리가 SELECT (또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql,query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if (mysql_errno(&mysql))
        {
           fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
        else if (mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
    }
}

(쿼리가 결과 세트를 돌려주는 것을 알 수 있고 있는 경우)mysql_errno(&mysql) (을)를 호출하는 대신에 mysql_field_count(&mysql) 하지만 0 (을)를 돌려줄지를 조사하는 방법도 있습니다.이것은,0 (을)를 돌려주는 것은, 어떠한 이상이 발생했을 경우만이기 때문입니다.

11.1.3.39. mysql_num_rows()

my_ulonglong mysql_num_rows(MYSQL_RES *result)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_num_rows() 의 사용법은,mysql_store_result() (와)과 mysql_use_result() 의 어느 쪽을 사용해 결과 세트를 취득할까에 의해서 정해집니다.mysql_store_result() (을)를 사용하는 경우, 곧바로 mysql_num_rows() (을)를 호출할 수 있습니다.mysql_use_result() (을)를 사용하는 경우, 결과 세트에 포함되는 모든 레코드를 취득할 때까지는,mysql_num_rows() (은)는 올바른 값을 돌려주지 않습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.3.40. mysql_options()

int mysql_options(MYSQL *mysql, enum mysql_option option, const char *arg)

설명

이 함수를 사용하고, 접속 옵션을 추가 설정해, 접속의 동작을 바꿀 수 있습니다.이 함수를 여러 차례 호출하는 것으로, 복수의 옵션을 설정할 수 있습니다.

mysql_options() (은)는,mysql_init() (을)를 실행하고 나서 mysql_connect() 또는 mysql_real_connect() (을)를 호출할 때까지 에 호출할 필요가 있습니다.

option 인수는, 설정하는 옵션입니다.arg 인수는 그 옵션으로 설정하는 값입니다.옵션이 정수의 경우,arg 에는 정수치에의 포인터를 건네줄 필요가 있습니다.

설정 가능한 옵션의 값을 다음에 나타냅니다.

옵션 | 인수의 형태 | 기능
MYSQL_OPT_CONNECT_TIMEOUT | unsigned int * | 접속의 타임 아웃 시간(초단위).
MYSQL_OPT_READ_TIMEOUT | unsigned int * | 서버로부터의 읽기 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_WRITE_TIMEOUT | unsigned int * | 서버에의 써 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_COMPRESS | 미사용 | 압축된 클라이언트/ 서버 프로토콜을 사용.
MYSQL_OPT_LOCAL_INFILE | unsigned int 에의 생략 가능한 포인터 | 포인터가 지정되지 않는지, 또는 0 (은)는 아니다 unsigned int 에의 포인터가 지정되었을 경우, 커멘드 LOAD LOCAL INFILE (은)는 유효.
MYSQL_OPT_NAMED_PIPE | 미사용 | 이름 파이프를 사용해 NT 위에서 동작한다 MySQL 서버에 접속.
MYSQL_INIT_COMMAND | char * | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
MYSQL_READ_DEFAULT_FILE | char * | my.cnf (이)가 아니고, 지정된 옵션 설정 파일로부터 옵션을 읽어들인다.
MYSQL_READ_DEFAULT_GROUP | char * | my.cnf 의 지정된 그룹 또는 MYSQL_READ_DEFAULT_FILE 그리고 지정된 파일로부터 옵션을 읽어들인다.
MYSQL_OPT_PROTOCOL | unsigned int * | 사용하는 프로토콜의 타입.mysql.h 그리고 정의되고 있다 mysql_protocol_type 의 열거치의 언젠가 1 개인 것.
MYSQL_SHARED_MEMORY_BASE_NAME | char* | 서버와의 통신에 사용하는 이름 공유 메모리오브제크트.접속 상대의 mysqld 서버가 사용하는 옵션 -shared-memory-base-name (와)과 같은 값을 지정할 필요가 있다.

주의: MYSQL_READ_DEFAULT_FILE 또는 MYSQL_READ_DEFAULT_GROUP (을)를 사용하는 경우는, 그룹 client 하지만 항상 읽힙니다.

옵션 설정 파일의 지정된 그룹에는 이하의 옵션을 지정 가능합니다.

옵션 | 설명
connect-timeout | 접속의 타임 아웃 시간(초단위).Linux 그럼, 서버로부터 최초의 응답을 기다리는 경우에도 이 타임 아웃 시간을 사용한다.
compress | 압축된 클라이언트/ 서버 프로토콜을 사용.
database | 접속 커멘드로 데이타베이스가 지정되지 않았던 경우에 접속하는 데이타베이스.
debug | 디버그 옵션.
disable-local-infile | LOAD DATA LOCAL 의 사용을 무효로 한다.
host | 디폴트의 호스트명.
init-command | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
interactive-timeout | mysql_real_connect() 그리고 CLIENT_INTERACTIVE (을)를 지정하는 것과 같다. See 항11.1.3.43. 「mysql_real_connect() 」 .
local-infile[=(0|1)] | 인수가 지정되지 않는지, 또는 0 이외의 인수가 지정되었을 경우에 LOAD DATA LOCAL 의 사용을 유효하게 한다.
max_allowed_packet | 클라이언트가 서버로부터 읽어들여 가능한 패킷의 최대 사이즈.
password | 디폴트의 패스워드.
pipe | 이름 파이프를 사용해 NT 위에서 동작한다 MySQL 서버에 접속.
protocol=(TCP | SOCKET | PIPE | MEMORY) | 서버에 접속할 경우에 사용하는 프로토콜을 선택(4.1 의 신기능).
port | 디폴트의 포토 번호.
return-found-rows | UPDATE (을)를 사용했을 때에 갱신된 레코드가 아니고, 검색 결과의 레코드를 돌려주도록(듯이),mysql_info() 에 지시한다.
shared-memory-base-name=name | 서버와의 접속에 사용하는 공유 메모리의 이름(디폴트는 "MySQL" ).MySQL 4.1 의 신기능.
socket | 디폴트의 소켓 번호.
user | 디폴트의 유저.

주의: timeout 대신에 connect-timeout 하지만 제공되고 있습니다만,timeout 도 당분간은 사용할 수 있습니다.

옵션 설정 파일의 상세한 것에 대하여는, 항4.1.2. 「my.cnf 옵션 설정 파일」 (을)를 참조해 주세요.

반환값

정상 종료했을 경우는 0 .불명한 옵션을 사용했을 경우는 0 이외.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql,MYSQL_OPT_COMPRESS,0);
mysql_options(&mysql,MYSQL_READ_DEFAULT_GROUP,"odbc");
if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는, 압축된 클라이언트/ 서버 프로토콜을 사용하는 것, 및 my.cnf 파일의 odbc 섹션의 옵션을 추가로 읽어들이는 것을, 클라이언트에 요구하고 있습니다.

11.1.3.41. mysql_ping()

int mysql_ping(MYSQL *mysql)

설명

서버에의 접속이 정상적일지를 확인합니다.절단 되고 있었을 경우는, 자동적으로 재접속을 시도합니다.

장시간에 걸쳐서 아이돌 상태였던 클라이언트는 이 함수를 사용하는 것에 의해서, 서버에 의해서 접속이 절단 되어 있지 않은지 어떤지를 조사하고, 필요하면 재접속할 수 있습니다.

반환값

서버와의 접속이 정상적인 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.42. mysql_query()

int mysql_query(MYSQL *mysql, const char *query)

설명

눌 종단 문자열 query 그리고 지정되었다 SQL 쿼리를 실행합니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

mysql_query() (은)는 바이너리 데이터를 포함한 쿼리를 취급할 수 없습니다.그러한 쿼리에서는 대신에 mysql_real_query() (을)를 사용할 필요가 있습니다(바이너리 데이터에는 '\0' 하지만 포함될 가능성이 있어,mysql_query() (은)는 그것을 쿼리 문자열의 마지막으로서 해석해 버리기 위해).

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

반환값

쿼리가 정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.43. mysql_real_connect()

MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned long client_flag)

설명

mysql_real_connect() (은)는,host 그리고 동작하고 있다 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_real_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 지정 방법을 다음에 나타냅니다.

  • 1 번째의 파라미터에는, 기존의 MYSQL 구조체의 주소를 지정한다.mysql_real_connect() (을)를 호출하기 전에,mysql_init() (을)를 호출해 MYSQL 구조체를 초기화할 필요가 있다.mysql_options() (을)를 사용하면, 다양한 접속 옵션을 변경할 수 있다. See 항11.1.3.40. 「mysql_options() 」 .

  • host 파라미터에는, 호스트명 또는 IP 주소의 어느 쪽인지를 지정한다.host 에 NULL 또는 문자열 "localhost" (을)를 지정했을 경우, 로컬 호스트에게 접속하는 것으로 간주해진다.OS 하지만 소켓(Unix ) 또는 이름 파이프(Windows )(을)를 서포트하고 있는 경우,TCP/IP 대신에 그것들을 사용해 서버에 접속한다.

  • user 파라미터에는 유저의 MySQL 로그인 ID (을)를 지정한다.user 에 NULL 또는 공문자열 "" (을)를 지정했을 경우, 현재의 유저를 사용하는 것으로 간주해진다.Unix 그럼 현재의 로그인명이 사용된다.Windows 그리고 ODBC (을)를 사용하는 경우는, 현재의 유저명을 명시적으로 지정할 필요가 있다. See 항11.2.2. 「ODBC 아드?~ 니스트레이타의 필드의 설정 방법법」 .

  • passwd 파라미터에는 user 의 패스워드를 지정한다.passwd 에 NULL (을)를 지정했을 경우,user 테이블의 엔트리의 패스워드 필드에 아무것도 지정되어 있지 않은(하늘이다) 유저만이 체크 대상이 된다.데이타베이스 관리자는, 이 기능을 사용하고, 패스워드를 지정해 있을지에 따라서 유저에게 다른 특권을 준다고 한다 MySQL 특권 시스템을 셋업 할 수 있다.

    주의: 패스워드의 암호화는 클라이언트 API 에 의해서 자동적으로 처리되므로,mysql_real_connect() (을)를 호출하기 전에 패스워드의 암호화는 불필요하다.

  • db 파라미터에는 데이타베이스명을 지정한다.db 하지만 NULL (이)가 아닌 경우, 이 값이 접속의 디폴트 데이타베이스로서 설정된다.

  • port 파라미터에 0 이외의 값을 지정했을 경우, 이 값이 TCP/IP 접속의 포토 번호로서 사용된다.주의: 접속의 타입은 host 파라미터에 의해서 결정된다.

  • unix_socket 파라미터에 NULL 이외의 값을 지정했을 경우, 이 문자열이 소켓 또는 이름 파이프에 사용된다.주의: 접속의 타입은 host 파라미터에 의해서 결정된다.

  • client_flag 파라미터에는 통상 0 (을)를 지정하지만, 지극히 특수한 상황에서는 이하에 나타내는 플래그를 조합해 지정할 수 있다.

    플래그명 | 플래그의 설명
    CLIENT_COMPRESS | 압축 프로토콜을 사용.
    CLIENT_FOUND_ROWS | 영향을 받은 레코드의 수가 아니고, 검색 결과의(일치한) 레코드의 수를 돌려준다.
    CLIENT_IGNORE_SPACE | 함수명의 말미의 공백을 무시한다.모든 함수명을 예약어(reserved word)로 한다.
    CLIENT_INTERACTIVE | 아이돌 상태가(wait_timeout 초는 아니고)interactive_timeout 초계속하면 접속을 클로우즈 한다.
    CLIENT_LOCAL_FILES | LOAD DATA LOCAL 의 처리를 유효하게 한다.
    CLIENT_MULTI_STATEMENTS | 클라이언트가 복수행 쿼리(‘; ＇ (을)를 스테이트먼트의 단락으로 한다)를 송신할 가능성이 있는 것을 서버에 통지한다.이 플래그가 설정되어 있지 않은 경우, 복수행 쿼리는 무효.MySQL 4.1 의 신기능.
    CLIENT_MULTI_RESULTS | 클라이언트가 복수 쿼리 또는 Stored Procedure에 의해서 취득한 복수의 결과 세트를 처리할 수 있는 것을 서버에 통지한다.CLIENT_MULTI_STATEMENTS 하지만 설정되어 있는 경우, 이 플래그는 자동적으로 설정된다.MySQL 4.1 의 신기능.
    CLIENT_NO_SCHEMA | db_name.tbl_name.col_name 그렇다고 하는 구문의 사용을 금?~ 한다.이것은 ODCB 향해의 구문이다.이 구문을 사용했을 경우, 파서로 에러가 발생한다.이 구문은 일부의 ODBC 프로그램으로 버그를 트랩 하기 위해서 사용한다.
    CLIENT_ODBC | 클라이언트가 ODBC 경유인 것을 통지한다.이 경우,mysqld 하 ODBC 클라이언트에 적절한 처리를 실시한다.
    CLIENT_SSL | SSL (암호화 프로토콜)(을)를 사용한다.응용 프로그램에서는 이 플래그를 설정하지 않는 것.이것은 클라이언트 라이브러리가 내부에서 설정하는 플래그이다.

반환값

접속이 정상적으로 확립했을 경우는 MYSQL* 접속 핸들.접속이 확립하지 않았던 경우는 NULL .접속이 확립했을 경우, 반환값은 1 번째의 파라미터의 값과 같습니다.

에러

  • CR_CONN_HOST_ERROR

    MySQL 서버에의 접속이 확립하지 않았다.

  • CR_CONNECTION_ERROR

    로컬의 MySQL 서버에의 접속이 확립하지 않았다.

  • CR_IPSOCK_ERROR

    IP 소켓의 작성에 실패했다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SOCKET_CREATE_ERROR

    Unix 소켓의 작성에 실패했다.

  • CR_UNKNOWN_HOST

    호스트명의 IP 주소가 발견되지 않았다.

  • CR_VERSION_ERROR

    서버에 접속할 때에, 다른 프로토콜 버젼의 클라이언트 라이브러리를 사용했기 때문에, 프로토콜의 불일치가 발생했다.이 에러는,--old-protocol 옵션을 지정하지 않고 기동한 새로운 버젼의 서버에, 매우 낡은 버젼의 클라이언트 라이브러리를 사용하고 접속을 시도했을 경우에 발생할 가능성이 있다.

  • CR_NAMEDPIPEOPEN_ERROR

    Windows 그리고 이름 파이프의 작성에 실패했다.

  • CR_NAMEDPIPEWAIT_ERROR

    Windows 그리고 이름 파이프의 대기에 실패했다.

  • CR_NAMEDPIPESETSTATE_ERROR

    Windows 그리고 파이프 핸들러의 취득에 실패했다.

  • CR_SERVER_LOST

    connect_timeout 하지만 정의 값이며,connect_timeout 초경과해도 서버에 접속할 수 없었다.또는 init-command 의 실행중에 서버가 다운했다.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql,MYSQL_READ_DEFAULT_GROUP,"your_prog_name");
if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는 mysql_options() (을)를 호출해 MySQL 라이브러리가 my.cnf 파일의 [client] 및 [your_prog_name] 섹션을 읽어들이도록(듯이) 설정해 있습니다.이와 같이 설정하는 것으로, 비표준적인 방법으로 셋업 되었다 MySQL 에 대해서도 이 프로그램이 정상적으로 동작하는 것을 보증합니다.

주의: 접속이 확립했을 때,mysql_real_connect() 에 의해서 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.

11.1.3.44. mysql_real_escape_string()

unsigned long mysql_real_escape_string(MYSQL *mysql, char *to, const char *from, unsigned long length)

설명

이 함수는,SQL 스테이트먼트로 사용할 수 있는 정당한 SQL 문자열을 작성하기 위해서 사용합니다. See 항6.1.1.1. 「문자열」 .

from (으)로 지정한 문자열이, 이스케이프 되었다 SQL 문자열에 encode 됩니다.이 때, 접속의 현재의 캐릭터 세트가 고려됩니다.encode 한 결과는 to (으)로 설정되어 말미에는 문자열의 마지막을 나타내는 누르바이트가 부가됩니다.encode 되는 문자는,NUL (ASCII 0 ),'\n' ,'\r' ,‘\ ＇,‘' ＇,‘" ＇, 및 Ctrl-Z 키(see 항6.1.1. 「리터럴: 문자열과 수치의 기술 방법」 )입니다(엄밀하게 말하면,MySQL 그리고 이스케이프 할 필요가 있는 것은 쿼리내에서 문자열을 인용하기 위한 backslash 및 인용부호 뿐입니다만, 이 함수에서는 로그 파일을 읽기 쉽게 하기 위해서 다른 문자도 이스케이프 합니다).

from 그리고 지정하는 문자열의 길이는 length 아르바이트일 필요가 있습니다.to 버퍼에는, 적어도 length*2+1 아르바이트의 메모리를 할당할 필요가 있습니다(최악의 경우,1 문자 encode 하는데 2 아르바이트가 필요한 가능성이 있어, 한층 더 문자열의 마지막을 나타내는 누르바이트를 격납할 필요가 있습니다).mysql_real_escape_string() 하지만 복귀했을 때,to 에는 눌 종단 문자열이 격납되고 있습니다.반환값은 encode 후의 문자열의 길이입니다.다만, 문자열의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

례

char query[1000],*end;

end = strmov(query,"INSERT INTO test_table values(");
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"What's this",11);
*end++ = '\'';
*end++ = ',';
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"binary data: \0\r\n",16);
*end++ = '\'';
*end++ = ')';

if (mysql_real_query(&mysql,query,(unsigned int) (end - query)))
{
   fprintf(stderr, "Failed to insert row, Error: %s\n",
           mysql_error(&mysql));
}

이 예로 사용되고 있다 strmov() 함수는,mysqlclient 라이브러리에 격납되고 있습니다.strcpy() (와)과 같은 처리를 실시합니다만,1 번째의 파라미터로 지정된 문자열의 마지막을 나타내는 누르바이트에의 포인터를 돌려줍니다.

반환값

to (으)로 설정된 값의 길이.다만, 문자열의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

에러

없습니다.

11.1.3.45. mysql_real_query()

int mysql_real_query(MYSQL *mysql, const char *query, unsigned long length)

설명

query 그리고 지정한 문자열로 나타내진다 SQL 쿼리를 실행합니다.이 문자열의 길이는 length 아르바이트일 필요가 있습니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

바이너리 데이터에는 '\0' 문자가 포함될 가능성이 있으므로, 그러한 데이터를 포함한 쿼리의 경우는,mysql_query() (이)가 아니고,mysql_real_query() (을)를 사용한다 필요가 있습니다 .또,mysql_real_query() (은)는 쿼리 문자열에 대해서 strlen() (을)를 호출하지 않기 때문에,mysql_query() 보다 고속으로 동작합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

반환값

쿼리가 정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.46. mysql_reload()

int mysql_reload(MYSQL *mysql)

설명

권한 테이블의 재독 봐 포함을 MySQL 서버에 요구합니다.접속 유저에게는 RELOAD 특권이 필요합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 FLUSH PRIVILEGES 스테이트먼트를 발행해 주세요.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.47. mysql_row_seek()

MYSQL_ROW_OFFSET mysql_row_seek(MYSQL_RES *result, MYSQL_ROW_OFFSET offset)

설명

쿼리 결과 세트의 임의의 레코드에 로 커서를 설정합니다.offset 의 값은 레코드 오프셋이며,mysql_row_tell() 또는 mysql_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_data_seek() (을)를 사용합니다.

mysql_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수 있습니다.

에러

없습니다.

11.1.3.48. mysql_row_tell()

MYSQL_ROW_OFFSET mysql_row_tell(MYSQL_RES *result)

설명

마지막에 실행되었다 mysql_fetch_row() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_row_seek() 에 인수로서 건네줄 수 있습니다.

          mysql_row_tell()

(은)는,mysql_use_result()

의 다음에는 없고,mysql_store_result()

의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋.

에러

없습니다.

11.1.3.49. mysql_select_db()

int mysql_select_db(MYSQL *mysql, const char *db)

설명

db 그리고 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

접속 유저가 데이타베이스를 사용하는 권한을 가지는 유저로서 인증되지 않는 경우,mysql_select_db() (은)는 실패합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.50. mysql_set_server_option()

int mysql_set_server_option(MYSQL *mysql, enum enum_mysql_set_option option)

설명

접속의 옵션을 유효 또는 무효로 합니다.option 에는 이하의 어느 쪽인가의치를 지정할 수 있습니다.

MYSQL_OPTION_MULTI_STATEMENTS_ON | 복수 스테이트먼트의 서포트를 유효하게 한다.
MYSQL_OPTION_MULTI_STATEMENTS_OFF | 복수 스테이트먼트의 서포트를 무효로 한다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • ER_UNKNOWN_COM_ERROR

    서버가 mysql_set_server_option() (을)를 서포트하지 않았다(서버가 4.1.1 보다 낡은 버젼의 경우)인가, 또는 서버가 설정하려고 한 옵션을 서포트하지 않았다.

11.1.3.51. mysql_shutdown()

int mysql_shutdown(MYSQL *mysql)

설명

데이터 베이스 서버에 슛다운 하도록(듯이) 요구합니다.접속 유저에게는 SHUTDOWN 특권이 필요합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.52. mysql_sqlstate()

const char *mysql_sqlstate(MYSQL *mysql)

설명

마지막에 발생한 에러의 SQLSTATE 에러 코드를 포함한 눌 종단 문자열을 돌려줍니다.에러 코드는 5 문자로 나타납니다.'00000' (은)는,`` 에러가 없다'' 일을 의미합니다.값은 ANSI SQL 및 ODBC 에 의해서 규정되고 있습니다.생각할 수 있는 값의 일람에 대해서는, 항12.1. 「돌려주어지는 에러」 (을)를 참조해 주세요.

주의: 모든 MySQL 에러가 SQLSTATE 에 매핑 되고 있는 것은 아닙니다.매핑 되어 있지 않은 에러의 경우는 'HY000' (일반 에러)(이)가 사용됩니다.

이 함수는 MySQL 4.1.1 그리고 추가되었습니다.

반환값

SQLSTATE 에러 코드를 포함한 눌 종단 문자열.

관련 항목

See 항11.1.3.12. 「mysql_errno() 」 . See 항11.1.3.13. 「mysql_error() 」 . See 항11.1.7.18. 「mysql_stmt_sqlstate() 」 .

11.1.3.53. mysql_ssl_set()

int mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca, const char *capath, const char *cipher)

설명

mysql_ssl_set() (은)는,SSL (을)를 사용하고, 시큐러티로 보호된 접속을 확립하기 위해서 사용합니다.mysql_real_connect() 의 전에 호출할 필요가 있습니다.

mysql_ssl_set() (은)는, 클라이언트 라이브러리에서 OpenSSL 서포트가 유효하게 되지 않은 경우는 아무것도 하지 않습니다.

mysql (은)는,mysql_init() (으)로부터 돌려주어진 접속 핸들러입니다.다른 파라미터의 지정 방법을 다음에 나타냅니다.

  • key 파라미터에는, 비밀 키파일에의 패스명을 지정한다.

  • cert 파라미터에는, 증명서 파일에의 패스명을 지정한다.

  • ca 파라미터에는, 인증국 발행의 증명서 파일에의 패스명을 지정한다.

  • capath 파라미터에는,PEM 형식이 신뢰 받았다 CA 증명서가 격납된 디렉토리에의 패스명을 지정한다.

  • cipher 파라미터에는,SSL 암호화에 사용할 수 있는 암호의 일람을 지정한다.

사용하지 않는다 SSL 파라미터에는 NULL (을)를 지정할 수 있습니다.

반환값

이 함수는 항상 0 (을)를 돌려줍니다.SSL 하지만 올바르고 셋업 되어 있지 않은 경우, 접속을 시도하면 mysql_real_connect() 하지만 에러를 돌려줍니다.

11.1.3.54. mysql_stat()

char *mysql_stat(MYSQL *mysql)

설명

mysqladmin status 커멘드의 출력으로 같은 정보를 포함한 문자열을 돌려줍니다.이 정보에는, 사용 가능 시간(초단위), 실행중의 스레드수, 질문의 수, 재로드 회수, 및 오픈되고 있는 테이블의 수가 포함됩니다.

반환값

서버 스테이터스를 나타내는 문자열.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.55. mysql_store_result()

MYSQL_RES *mysql_store_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT ,SHOW ,DESCRIBE ,EXPLAIN )에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

다른 쿼리에서는 mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요는 없습니다만, 모든 케이스로 mysql_store_result() (을)를 호출해도, 이상이 발생하거나 눈에 띈 동작을 하는 일은 없습니다.mysql_store_result() 하지만 0 (을)를 돌려줄지를 조사하는 것으로, 쿼리로 결과 세트가 생성되었는지를 검출할 수 있습니다.이것에 대해서는 후술 합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

mysql_store_result() (은)는, 쿼리의 결과 세트 전체를 클라이언트에 읽어들여,MYSQL_RES 구조체에 메모리를 할당해 이 구조체에 결과 세트를 격납합니다.

쿼리가 결과 세트를 돌려주지 않는 경우(예를 들어, 쿼리가 INSERT 스테이트먼트였던 경우),mysql_store_result() (은)는 누르포인타를 돌려줍니다.

또, 결과 세트의 읽어들여에 실패했을 경우도,mysql_store_result() (은)는 누르포인타를 돌려줍니다.에러가 발생했는지를 조사하려면 ,mysql_error() 하지만 누르포인타를 돌려주지 않는지 어떤지,mysql_errno() 하지만 0 이외의 값을 돌려줄지, 또는 mysql_field_count() 하지만 0 이외의 값을 돌려줄지를 조사합니다.

돌려주는 레코드가 존재하지 않는 경우는 하늘의 결과 세트가 돌려주어집니다(하늘의 결과 세트는, 반환값으로서의 누르포인타와는 다릅니다).

mysql_store_result() (을)를 호출하고, 반환값이 누르포인타 이외였던 경우,mysql_num_rows() (을)를 호출하면 결과 세트에 포함되는 레코드수를 취득할 수 있습니다.

mysql_fetch_row() (을)를 호출하면, 결과 세트로부터 레코드를 취득할 수 있습니다.mysql_row_seek() 및 mysql_row_tell() (을)를 호출하면, 결과 세트내의 경향 레코드의 위치를 설정 및 취득할 수 있습니다.

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출할 필요가 있습니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트가 격납되었다 MYSQL_RES 구조체.에러가 발생했을 경우는 NULL .

에러

mysql_store_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno (을)를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.56. mysql_thread_id()

unsigned long mysql_thread_id(MYSQL *mysql)

설명

현재의 접속의 스레드 ID (을)를 돌려줍니다.이 반환값을,mysql_kill() 에 인수로서 건네주어 스레드를 강제 종료할 수 있습니다.

현재의 접속이 절단 되어mysql_ping() (을)를 사용해 재접속했을 경우, 스레드 ID (은)는 다른 값이 됩니다.이것은, 취득한 스레드 ID (을)를 보관해 다음에 사용할 수 없는 것을 의미합니다.스레드 ID 하지만 필요하게 되었을 때에, 취득할 필요가 있습니다.

반환값

현재의 접속의 스레드 ID .

에러

없습니다.

11.1.3.57. mysql_use_result()

MYSQL_RES *mysql_use_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT ,SHOW ,DESCRIBE ,EXPLAIN )에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

mysql_use_result() (은)는, 결과 세트의 취득을 개시합니다만,mysql_store_result() (와)과 같이 실제로 결과 세트를 클라이언트에 읽어들이는 것은 아닙니다.대신에,mysql_fetch_row() (을)를 호출하고,1 행씩 개별적으로 취득할 필요가 있습니다.그 경우, 쿼리의 결과는 직접 서버로부터 읽혀 텐포라리테이불이나 로컬 버퍼에는 격납되지 않습니다.이것은 mysql_store_result() (을)를 사용하는 경우보다 다소 고속으로 있어, 사용하는 메모리도 적어도 됩니다.클라이언트는, 경향 레코드 및 max_allowed_packet 아르바이트까지 증가할 가능성이 있는 통신 버퍼에 메모리를 할당할 뿐입니다.

한편, 각각의 레코드에 대한 클라이언트측에서의 처리량이 많은 경우, 또는 유저가 ^S (을)를 입력한다(스크롤을 정?~ 할) 가능성이 있는 화면에 데이터를 출력하는 경우는,mysql_use_result() 의 사용은 피할 필요가 있습니다.그러한 처리의 경우, 서버의 동작이 정?~ 하고, 읽어내지고 있는 데이터가 격납되고 있는 테이블을 다른 스레드를 갱신할 수 없게 됩니다.

mysql_use_result() (을)를 사용하는 경우,NULL 하지만 돌려주어질 때까지 mysql_fetch_row() (을)를 반복해 호출할 필요가 있습니다.그렇게 하지 않으면 취득되지 않았던 레코드가, 다음에 실행하는 쿼리의 결과 세트의 일부로서 돌려주어집니다.취득되지 않았던 레코드가 남아 있는 경우,C API (은)는 에러 Commands out of sync; you can't run this command now (을)를 돌려줍니다.

          mysql_use_result()

하지만 돌려준 결과 세트에 대해서
          mysql_data_seek()
,mysql_row_seek()
,mysql_row_tell()
,mysql_num_rows()
, 또는
          mysql_affected_rows()

(을)를 사용할 수 없습니다.또,mysql_use_result()

하지만 완료할 때까지는 다른 쿼리를 발행할 수 없습니다(다만, 모든 레코드를 취득한 다음에 있으면
          mysql_num_rows()

(은)는 취득한 레코드의 수를 정확하게 돌려줍니다).

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

MYSQL_RES 구조체.에러가 발생했을 경우는 NULL .

에러

mysql_use_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno (을)를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.58. mysql_warning_count()

unsigned int mysql_warning_count(MYSQL *mysql)

설명

전회 실행되었다 SQL 스테이트먼트의 실행중에 발생한 경고수를 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

경고수.

에러

없습니다.

11.1.3.59. mysql_commit()

my_bool mysql_commit(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 코?~ 트 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.60. mysql_rollback()

my_bool mysql_rollback(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 롤백(rollback) 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.61. mysql_autocommit()

my_bool mysql_autocommit(MYSQL *mysql, my_bool mode)

설명

mode 하지만 1 의 경우는 자동코?~ 트모드를 유효하게,mode 하지만 0 의 경우는 무효로 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.62. mysql_more_results()

my_bool mysql_more_results(MYSQL *mysql)

설명

현재 실행하고 있는 쿼리 외에 아직 취득하고 있지 않는 결과 세트가 존재해, 어플리케이션이 mysql_next_result() (을)를 호출해 취득할 필요가 있는 경우는,true (을)를 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

취득되어 있지 않은 결과 세트가 존재하는 경우는 TRUE (1 ).취득되어 있지 않은 결과 세트가 존재하지 않는 경우는 FALSE (0 ).

주의: 대부분의 경우, 이 함수 대신에 mysql_next_result() (을)를 호출해 취득되어 있지 않은 결과 세트가 있을지를 조사하고, 존재하는 경우는 다음의 결과 세트를 개시합니다.

See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」 . See 항11.1.3.63. 「mysql_next_result() 」 .

에러

없습니다.

11.1.3.63. mysql_next_result()

int mysql_next_result(MYSQL *mysql)

설명

취득되어 있지 않은 결과 세트가 존재하는 경우,mysql_next_result() (은)는 다음의 쿼리의 결과 세트를 읽어들여, 스테이터스를 어플리케이션에 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

주의: 전의 쿼리가 결과 세트를 돌려주고 있었을 경우,mysql_free_result() (을)를 호출할 필요가 있습니다.

          mysql_next_result()

(을)를 호출한 후, 접속 상태는 다음의 쿼리에 대해
          mysql_real_query()

(을)를 호출한 후와 같게 됩니다.이것은, 이 함수를 호출한 후, 이 접속으로
          mysql_store_result()
,mysql_warning_count()
,mysql_affected_rows()

등을 호출할 수 있는 것을 의미합니다.

mysql_next_result() 하지만 에러를 돌려주었을 경우, 다른 스테이트먼트는 실행되지 않습니다.또, 취득되어 있지 않은 결과 세트도 존재하지 않습니다.

See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」 .

반환값

호출이 정상적으로 동작해, 취득하는 결과 세트가 존재하고 있었을 경우는 0 , 취득하는 결과 세트가 존재하지 않았던 경우는 -1 , 에러가 발생했을 경우는 정의 값.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.예를 들어, 전의 결과 세트로 mysql_use_result() 하지만 불려 가지 않았던 경우에 이 에러가 발생한다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.4. C API 의 Prepared Statements

MySQL 4.1 그럼, 프리페아드스테이트먼트를 사용하기 위한 클라이언트/ 서버 프로토콜이 제공되고 있습니다.이 기능은,MYSQL_STMT 스테이트먼트 핸들러 데이터 구조체를 사용합니다.프리페아드스테이트먼트의 실행은, 스테이트먼트를 반복해 실행하는 경우에 효율적인 방법입니다.스테이트먼트는, 실행할 준비를 갖추기 위해서, 우선 해석됩니다.그 후,prepare 함수로부터 돌려주어지는 스테이트먼트 핸들을 사용하고,1 회이상 실행됩니다.

프리페아드스테이트먼트의 실행은, 해석이 1 회 밖에 행해지지 않기 때문에, 스테이트먼트를 직접 여러 차례 실행하는 것보다도 고속으로.스테이트먼트를 직접 실행했을 경우, 그때마다 쿼리의 해석을 합니다.프리페아드스테이트먼트를 실행하는 경우, 네트워크 트래픽도, 파라미터로서 데이터를 송신할 경우에 발생할 뿐(만큼)이므로, 삭감할 수 있습니다.

그 외에도, 프리페아드스테이트먼트의 실행에서는 바이너리 프로토콜을 사용하므로, 클라이언트 및 서버간의 데이터 전송의 효율이 향상한다고 하는 이점이 있습니다.프리페아드스테이트먼트는, 복수 쿼리를 실행할 때의 입력 및 출력의 바인딩도 서포트합니다.

11.1.5. C API 의 Prepared Statement의 데이터형

주의: 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자 전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

프리페아드스테이트먼트는, 주로 MYSQL_STMT 및 MYSQL_BIND 의 각 데이터 구조체를 사용합니다.그 외에, 시간적인 데이터를 전송 하기 위해서 MYSQL_TIME (을)를 사용합니다.

  • MYSQL_STMT

    이 구조체는, 프리페아드스테이트먼트를 나타낸다.프리페아드스테이트먼트는,mysql_prepare() (을)를 호출해 작성한다.이 함수는,MYSQL_STMT 에의 포인터인 스테이트먼트 핸들을 돌려준다.이 핸들은, 그 후에 불려 가는 모든 스테이트먼트 관련의 함수로 사용된다.

    MYSQL_STMT 구조체의 멤버를 어플리케이션이 사용할 것은 없다.

    1 개의 접속에 복수의 스테이트먼트 핸들을 관련지을 수 있다.관련짓는 핸들수는, 사용할 수 있는 system resource에 의해서 제한된다.

  • MYSQL_BIND

    이 구조체는, 쿼리의 입력(데이터치가 서버에 송신된다) 및 출력(결과치가 서버로부터 돌려주어진다)의 양쪽 모두로 사용된다.입력의 경우,mysql_bind_param() 에 건네주어 파라미터 데이터치를 버퍼에 바인드 해,mysql_execute() 하지만 사용할 수 있도록 한다.출력의 경우,mysql_bind_result() 에 건네주어 결과 세트를 버퍼에 바인드 해,mysql_fetch() 그리고 레코드를 취득할 때에 사용할 수 있도록 한다.

    MYSQL_BIND 구조체에서는, 이하에 나타내는 멤버를 응용 프로그램을 사용할 수 있다.어느 멤버도 입력 및 출력의 어느 쪽에도 사용하지만, 데이터 전송의 방향에 따라서 다른 목적으로 사용하는 경우가 있다.

    • enum enum_field_types buffer_type

      버퍼의 형태.사용할 수 있다 buffer_type 의 값의 리스트를, 이 섹션의 후반에 나타낸다.입력의 경우,buffer_type (은)는 쿼리 파라미터에 바인드 하는 값의 형태를 나타낸다.출력의 경우, 결과 세트의 버퍼로 받는 값의 형태를 나타낸다.

    • void *buffer

      입력의 경우, 쿼리 파라미터의 데이터치가 보존되는 버퍼에의 포인터.출력의 경우, 결과 세트의 컬럼치를 돌려주는 버퍼에의 포인터.컬럼형이 수치의 경우,buffer (은)는 적절한 C 언어의 형태의 변수에의 포인터로 할 필요가 있다(UNSIGNED 속성을 가지는 컬럼에 변수를 관련짓고 있는 경우, 변수는 C 언어의 unsigned 형태로 할 필요가 있다).컬럼형이 일자 및 시각의 경우,buffer 하 MYSQL_TIME 구조체에의 포인터로 할 필요가 있다.컬럼형이 문자열 및 바이너리 문자열의 경우,buffer (은)는 문자 버퍼에의 포인터로 할 필요가 있다.

    • unsigned long buffer_length

      아르바이트 단위로 나타냈다 *buffer 의 실제의 사이즈.이 값은, 버퍼에 격납할 수 있는 데이터의 최대 사이즈를 나타낸다.C 의 문자 데이터 및 바이너리 데이터의 경우,buffer_length 의 값은,mysql_bind_param() 그리고 사용하는 경우는 *buffer 하지만 나타내 보이는 데이터의 길이, 또는 mysql_bind_result() 그리고 사용하는 경우는 버퍼에 취득할 수 있는 최대 데이터 바이트수를 지정한다.

    • unsigned long *length

      unsigned long 변수에의 포인터.*buffer 에 격납하는 데이터의 실제의 아르바이트수를 나타낸다.length (은)는, 격납하는 데이터가 C 의 문자 데이터 또는 바이너리 데이터의 경우에 사용한다.입력 파라미터 데이터를 바인드 하는 경우,length (은)는,*buffer 에 격납하는 파라미터치의 길이를 나타낸다 unsigned long 변수를 가리킨다.이것은 mysql_execute() 그리고 사용된다.length 하지만 누르포인타의 경우, 프로토콜은 모든 문자 데이터 및 바이너리 데이터가 눌로 종단 되고 있으면 가정한다.출력치를 바인드 하는 경우,mysql_fetch() (은)는, 돌려주는 데이터의 컬럼치의 길이를 length 하지만 포인트 하는 변수로 설정한다.

      수치 데이터형 또는 시간적인 데이터형의 경우, 데이터치의 길이는 buffer_type 의 값에 의해서 정해지므로,length (은)는 무시된다.

    • my_bool *is_null

      my_bool 변수에의 포인터.값이 NULL 의 경우는 true ,NULL 이외의 경우는 false .입력의 경우,*is_null (을)를 true (으)로 설정하는 것에 의해서, 쿼리 파라미터로서 NULL 값을 건네주고 있는 것을 나타낸다.출력의 경우, 쿼리가 돌려주는 값이 NULL 때에 레코드를 취득하면, 이 값이 true (으)로 설정된다.

  • MYSQL_TIME

    이 구조체는, 서버와 직접 DATE ,TIME ,DATETIME , 및 TIMESTAMP 데이터를 송수신 하기 위해서 사용한다.거기에는,MYSQL_BIND 구조체의 buffer_type 멤버를 몇개의 시간을 나타내는 형태로 설정해,buffer 멤버를 MYSQL_TIME 구조체를 포인트 하도록(듯이) 설정한다.

    MYSQL_TIME 구조체의 멤버를 이하에 나타낸다.

    • unsigned int year

      년.

    • unsigned int month

      월.

    • unsigned int day

      일.

    • unsigned int hour

      시.

    • unsigned int minute

      분.

    • unsigned int second

      초.

    • my_bool neg

      시간이 부화도인지를 나타내는 불리언 값 플래그.

    • unsigned long second_part

      초의 소수부.현재는 미사용.

    MYSQL_TIME 구조체의 멤버는, 사용하는 시간적인 형태에 대응하는 부분만큼이 사용된다.year ,month , 및 day 의 각 멤버는,DATE ,DATETIME , 및 TIMESTAMP 의 값에 사용한다.hour ,minute , 및 second 의 각 멤버는,TIME ,DATETIME , 및 TIMESTAMP 의 값에 사용한다. See 항11.1.9. 「C API 에 있어서의 일자치 및 시각치의 취급」 .

MYSQL_BIND 구조체의 buffer_type 멤버로 지정할 수 있는 값을 이하의 겉(표)에 나타냅니다.이 표에는, 각각의 buffer_type 의 값에 가장 가깝다 SQL 의 데이터형을 나타내, 한층 더 수치형과 시간적인 값의 형태에 대해서는 대응한다 C 의 데이터형도 나타내 보입니다.

buffer_type 치 | SQL 의 데이터형 | C 의 데이터형
MYSQL_TYPE_TINY | TINYINT | char
MYSQL_TYPE_SHORT | SMALLINT | short int
MYSQL_TYPE_LONG | INT | long int
MYSQL_TYPE_LONGLONG | BIGINT | long long int
MYSQL_TYPE_FLOAT | FLOAT | float
MYSQL_TYPE_DOUBLE | DOUBLE | double
MYSQL_TYPE_TIME | TIME | MYSQL_TIME
MYSQL_TYPE_DATE | DATE | MYSQL_TIME
MYSQL_TYPE_DATETIME | DATETIME | MYSQL_TIME
MYSQL_TYPE_TIMESTAMP | TIMESTAMP | MYSQL_TIME
MYSQL_TYPE_STRING | CHAR |
MYSQL_TYPE_VAR_STRING | VARCHAR |
MYSQL_TYPE_TINY_BLOB | TINYBLOB/TINYTEXT |
MYSQL_TYPE_BLOB | BLOB/TEXT |
MYSQL_TYPE_MEDIUM_BLOB | MEDIUMBLOB/MEDIUMTEXT |
MYSQL_TYPE_LONG_BLOB | LONGBLOB/LONGTEXT |

암묵의 데이터형 변환은 어느 방향에도 행해질 가능성이 있습니다.

11.1.6. C API 의 Prepared Statement 함수의 개요

주의: 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자 전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

여기에서는, 프리페아드스테이트먼트의 처리에 사용할 수 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이?~ 의 섹션으로 설명합니다. See 항11.1.7. 「C API 의 Prepared Statement 함수의 설명」 .

함수 | 설명
mysql_prepare() | SQL 문자열을 실행하기 위한 프리컴파일을 실시한다.
mysql_param_count() | 프리페아드스테이트먼트의 파라미터수를 돌려준다.
mysql_get_metadata() | 프리페아드스테이트먼트메타데이타를 결과 세트 형식에서 돌려준다.
mysql_bind_param() | 어플리케이션 데이터 버퍼를, 프리페아드스테이트먼트내의 파라미터 마커에 관련짓는다.
mysql_execute() | 프리페아드스테이트먼트를 실행한다.
mysql_stmt_affected_rows() | 마지막에 실행되었다 UPDATE ,DELETE , 또는 INSERT 의 몇개의 쿼리에 의해서 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_bind_result() | 어플리케이션 데이터 버퍼를, 결과 세트의 컬럼에 관련짓는다.
mysql_stmt_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_stmt_data_seek() | 스테이트먼트의 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_stmt_row_seek() | mysql_stmt_row_tell() (으)로부터 돌려주어진 값을 오프셋으로서 스테이트먼트의 결과 세트내의 레코드에 시크 한다.
mysql_stmt_row_tell() | 스테이트먼트의 레코드 커서의 위치를 돌려준다.
mysql_stmt_num_rows() | 버퍼에 격납된 스테이트먼트의 결과 세트 전체의 레코드수를 돌려준다.
mysql_fetch() | 결과 세트의 다음의 레코드의 데이터를 취득해, 바인드 된 모든 컬럼의 데이터를 돌려준다.
mysql_stmt_close() | 프리페아드스테이트먼트가 사용하고 있던 메모리를 해방한다.
mysql_stmt_errno() | 마지막에 실행된 스테이트먼트의 에러 번호를 돌려준다.
mysql_stmt_error() | 마지막에 실행된 스테이트먼트의 에러 메세지를 돌려준다.
mysql_stmt_sqlstate() | 마지막에 실행한 스테이트먼트의 SQLSTATE 에러 코드를 돌려준다.
mysql_send_long_data() | long 형태 데이터를 분리해 서버에 송신한다.

        mysql_prepare()

(을)를 호출해 스테이트먼트 핸들을 프리컴파일 해, 초기화합니다.다음에
        mysql_bind_param()

(을)를 호출해 파라미터 데이터를 건네주어,mysql_execute()

(을)를 호출해 쿼리를 실행합니다.mysql_bind_param()

경유로 건네주는 버퍼에 격납한 파라미터치를 변경하고,mysql_execute()

(을)를 반복 실행할 수도 있습니다.

쿼리가 SELECT 스테이트먼트의 경우, 또는 결과 세트를 생성하는 그 외의 쿼리의 경우,mysql_prepare() 하 mysql_get_metadata() (을)를 사용해 MYSQL_RES 결과 세트 형식에서 결과 세트의 메타데이타 정보도 돌려줍니다.

결과를 격납하는 버퍼를 mysql_bind_result() (을)를 사용해 건네주는 것에 의해서,mysql_fetch() (은)는 자동적으로 그 버퍼에 데이터를 돌려줍니다.여기에서는 1 행씩의 취득을 합니다.

옵션으로서 is_long_data=1 또는 length=MYSQL_LONG_DATA 또는 -2 (을)를 지정했다 MYSQL_BIND 구조체를 mysql_bind_param() 그리고 건네주면,mysql_send_long_data() (을)를 사용해 텍스트 데이터 또는 바이너리 데이터를 분리해 서버에 송신할 수 있습니다.

스테이트먼트의 실행이 완료하면,mysql_stmt_close() (을)를 호출해 스테이트먼트 핸들을 클로우즈 해, 핸들에 관련 붙일 수 있어 모든 자원을 해방할 필요가 있습니다.

mysql_get_metadata() (을)를 호출해 SELECT 스테이트먼트의 결과 셋트메타데이타를 취득하고 있었을 경우도,mysql_free_result() (을)를 호출해 해방할 필요가 있습니다.

실행 스텝

스테이트먼트를 프리컴파일 해 실행하려면 , 어플리케이션으로 이하의 스텝에 따라서 처리합니다.

  1. SQL 스테이트먼트를 포함한 문자열을 파라미터로서 mysql_prepare() (을)를 호출한다.프리컴파일이 정상적으로 종료했을 경우,mysql_prepare() (은)는 유효한 스테이트먼트 핸들러를 어플리케이션에 돌려준다.

  2. 결과 세트를 생성하는 쿼리를 실행하는 경우,mysql_get_metadata() (을)를 호출해 결과 셋트메타데이타를 취득한다.이 메타데이타는 그것 자신이 결과 세트 형식이다.다만, 쿼리가 돌려주는 레코드를 포함한 결과 세트와는 따로 건네받는다.결과 셋트메타데이타에는, 결과 세트에 포함되는 컬럼수 및 각 컬럼에 관한 정보가 포함된다.

  3. mysql_bind_param() (을)를 사용하고, 파라미터의 값을 설정한다.모든 파라미터의 값을 설정할 필요가 있다.값이 설정되어 있지 않은 파라미터가 남아 있으면, 에러가 돌려주어지거나 예상외의 결과가 발생한다.

  4. mysql_execute() (을)를 호출해 스테이트먼트를 실행한다.

  5. 결과 세트를 생성하는 쿼리를 실행했을 경우,mysql_bind_result() (을)를 호출하고, 레코드의 값을 취득하기 위한 데이터 버퍼를 바인드 한다.

  6. mysql_fetch() (을)를 호출하고,1 행 분의 데이터를 버퍼에 취득한다.모든 레코드의 데이터를 취득할 수 있을 때까지 이것을 반복한다.

  7. 필요에 따라서 스텝 3 (으)로부터 6 까지를 반복하고, 파라미터의 값을 변경하면서 스테이트먼트를 재실행한다.

mysql_prepare() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버의 프로토콜을 이하에 나타냅니다.

  • 서버는 쿼리를 해석해, 스테이트먼트 ID (을)를 할당하고,OK 스테이터스를 클라이언트에 답장한다.결과 세트를 생성하는 쿼리의 경우는, 게다가 파라미터의 합계수, 컬럼수, 및 그 메타 정보를 송신한다.이 호출로, 서버는 쿼리의 모든 구문 및 의미를 확인한다.

  • 클라이언트는 이 스테이트먼트 ID (을)를 사용해 그 후의 처리를 실행한다.이 ID (을)를 사용하고, 서버는 스테이트먼트 풀중에서 사용하는 스테이트먼트를 식별한다.또, 클라이언트는 스테이트먼트 핸들을 이 ID 에 할당해 핸들을 어플리케이션에 돌려준다.

mysql_execute() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는 스테이트먼트 핸들을 사용하고, 서버에 파라미터 데이터를 송신한다.

  • 서버는 클라이언트로부터 건네받았다 ID (을)를 사용해 스테이트먼트를 식별해, 파라미터 마커를 새롭게 건네받은 데이터에 옮겨놓아 쿼리를 실행한다.결과 세트를 생성하는 쿼리를 실행했을 경우, 서버는 데이터를 클라이언트에 답장한다.결과 세트를 생성하지 않는 쿼리를 실행했을 경우, 서버는 OK 스테이터스 및 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려준다.

mysql_fetch() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는, 패킷으로부터 1 행분씩 데이터를 읽어들여, 필요에 따라서 데이터 변환하면서 어플리케이션 데이터 버퍼에 격납한다.어플리케이션 버퍼의 형태가 서버로부터 돌려주어진 필드의 형태와 같은 경우는, 직접적으로 변환을 한다.

mysql_stmt_errno() ,mysql_stmt_error() , 및 mysql_stmt_sqlstate() (을)를 사용하면, 각각 스테이트먼트의 에러 코드, 에러 메세지, 및 SQLSTATE 값을 취득할 수 있습니다.

11.1.7. C API 의 Prepared Statement 함수의 설명

쿼리를 프리컴파일 해 실행하려면 , 이하의 함수를 사용합니다.

11.1.7.1. mysql_prepare()

MYSQL_STMT * mysql_prepare(MYSQL *mysql, const char *query, unsigned long length)

설명

눌 종단 문자열 query 그리고 지정되었다 SQL 쿼리를 프리컴파일 해, 그 후의 처리에 사용하는 스테이트먼트 핸들을 돌려줍니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

어플리케이션은,SQL 문자열의 적당한 위치에 물음표(‘? ＇)(을)를 묻는 것으로,SQL 스테이트먼트로 1 개이상의 파라미터 마커를 사용할 수 있습니다.

마커는,SQL 스테이트먼트의 특정의 위치에 파묻혔을 경우에게만 적정하게 처리됩니다.예를 들어, 마커는 INSERT 스테이트먼트의 VALUES() 의 리스트로 레코드로 설정하는 컬럼의 값을 지정하는 부분, 또는 WHERE 마디로 컬럼의 값과 비교하는 값을 지정하는 부분에 사용할 수 있습니다.그러나,SELECT 스테이트먼트가 돌려주는 컬럼을 지정하는 선택 리스트로 식별자(테이블 또는 컬럼의 이름등)로서 사용하거나 등호(= )등의 바이너리 연산자의 양쪽 모두의 오퍼랜드를 지정할 수 없습니다.파라미터의 형태를 결정할 수 없기 때문에, 후자의 제약이 필요하게 됩니다.일반적으로, 파라미터는, 데이터 조작 언어(DML ) 스테이트먼트에서만 적정하게 처리되어 데이터 정의 언어(DDL ) 스테이트먼트에서는 처리되지 않습니다.

파라미터 마커는, 스테이트먼트를 실행하기 전에,mysql_bind_param() (을)를 사용해 어플리케이션 변수에 바인드 할 필요가 있습니다.

반환값

컴파일이 정상적으로 종료했을 경우는 MYSQL_STMT 구조체에의 포인터.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

컴파일이 실패했을 경우(mysql_prepare() 하지만 NULL (을)를 돌려주었을 경우), 에러 메세지는 mysql_error() (을)를 호출하는 것에 의해서 취득할 수 있습니다.

례

mysql_prepare() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.2. mysql_param_count()

unsigned long mysql_param_count(MYSQL_STMT *stmt)

설명

프리컴파일 된 스테이트먼트에 포함되는 파라미터 마커의 수를 돌려줍니다.

반환값

스테이트먼트에 포함되는 파라미터수를 나타낸다 unsigned long 정수.

에러

없습니다.

례

mysql_param_count() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.3. mysql_get_metadata()

MYSQL_RES *mysql_get_metadata(MYSQL_STMT *stmt)

설명

mysql_prepare() 에게 건네진 스테이트먼트가 결과 세트를 생성하는 것인 경우,mysql_get_metadata() 하 MYSQL_RES 구조체에의 포인터라고 하는 형태로 결과 셋트메타데이타를 돌려줍니다.이 구조체를 사용하고, 필드의 합계수 및 개개의 필드 정보등의 메타 정보를 처리할 수 있습니다.이 결과 세트에의 포인터는, 결과 셋트메타데이타를 처리하는 이하의 필드 베이스의 API 함수에 인수로서 건네줄 수 있습니다.

  • mysql_num_fields()

  • mysql_fetch_field()

  • mysql_fetch_field_direct()

  • mysql_fetch_fields()

  • mysql_field_count()

  • mysql_field_seek()

  • mysql_field_tell()

  • mysql_free_result()

결과 세트 구조체는, 사용할 필요가 없어지면 mysql_free_result() 에 건네주어 해방할 필요가 있습니다.이것은,mysql_store_result() (을)를 호출해 취득한 결과 세트를 해방하는 방법과 닮아 있습니다.

mysql_get_metadata() (으)로부터 돌려주어지는 결과 세트에는, 메타데이타만이 포함됩니다.레코드 데이터는 포함되지 않습니다.레코드를 취득하려면 , 스테이트먼트 핸들을 파라미터로서 mysql_fetch() (을)를 호출합니다.

반환값

MYSQL_RES 구조체.프리컴파일 한 쿼리의 메타 정보가 존재하지 않는 경우는 NULL .

에러

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_get_metadata() 의 사용 방법에 대해서는, 항11.1.7.13. 「mysql_fetch() 」 의 「예」를 참조해 주세요.

11.1.7.4. mysql_bind_param()

my_bool mysql_bind_param(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_param() (은)는,mysql_prepare() 에게 건네졌다 SQL 스테이트먼트에 포함되는 파라미터 마커의 데이터를 바인드 하기 위해서 사용합니다.데이터는 MYSQL_BIND 구조체를 사용해 건네줍니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 쿼리에 포함되는 각 ‘? ＇ 파라미터에 대응하는 요소가 포함되어 있으면 가정합니다.

예를 들어, 이하의 스테이트먼트를 프리컴파일 한다고 합니다.

INSERT INTO mytbl VALUES(?,?,?)

파라미터를 바인드 하는 경우,MYSQL_BIND 구조체에는 3 개의 요소가 필요하고, 이하와 같이 선언할 수 있습니다.

MYSQL_BIND bind[3];

설정할 필요가 있다 MYSQL_BIND 의 각 요소의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_NO_PARAMETERS_EXISTS

    바인드 하는 파라미터가 존재하지 않는다.

  • CR_INVALID_BUFFER_USE

    이것이long 데이터를 분리해 건네주기 위한 바인드인가, 및 버퍼의 형태가 문자열 이외 또는 바이너리 이외인지를 나타낸다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_param() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.5. mysql_execute()

int mysql_execute(MYSQL_STMT *stmt)

설명

mysql_execute() (은)는, 스테이트먼트 핸들에 관련지을 수 있고 있는 프리컴파일 된 쿼리를 실행합니다.이 호출 시에, 현재 바인드 되고 있는 파라미터 마커의 값이 서버에 송신되어 서버는 마커를 여기서 건네받은 데이터로 옮겨놓습니다.

스테이트먼트가 UPDATE ,DELETE , 또는 INSERT 의 경우,mysql_stmt_affected_rows() (을)를 호출하는 것에 의해서, 변경, 삭제, 또는 삽입된 레코드의 합계수를 취득할 수 있습니다.이것이 SELECT 등의 결과 세트를 생성하는 쿼리의 경우, 최초로 mysql_fetch() (을)를 호출해 데이터를 취득하고 나서, 다른 쿼리 처리를 필요로 하는 함수를 호출할 필요가 있습니다.결과를 취득하는 방법의 상세한 것에 대하여는, 항11.1.7.13. 「mysql_fetch() 」 (을)를 참조해 주세요.

반환값

정상적으로 실행했을 경우는 0 .에러가 발생했을 경우는 0 이외.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해서 취득할 수 있습니다.

에러

  • CR_NO_PREPARE_QUERY

    실행하기 전에 프리컴파일 된 쿼리가 존재하지 않는다.

  • CR_ALL_PARAMS_NOT_BOUND

    건네받지 않은 파라미터 데이터가 있다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

이하의 예에서는,mysql_prepare()
,mysql_param_count()
,mysql_bind_param()
,mysql_execute()
, 및
          mysql_stmt_affected_rows()

(을)를 사용하고, 테이블을 작성해, 데이터를 삽입하는 방법을 나타냅니다.mysql

변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define DROP_SAMPLE_TABLE "DROP TABLE IF EXISTS test_table"
#define CREATE_SAMPLE_TABLE "CREATE TABLE test_table(col1 INT,\
                                                 col2 VARCHAR(40),\
                                                 col3 SMALLINT,\
                                                 col4 TIMESTAMP)"
#define INSERT_SAMPLE "INSERT INTO test_table(col1,col2,col3) VALUES(?,?,?)"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[3];
my_ulonglong  affected_rows;
int           param_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
unsigned long str_length;
my_bool       is_null;

if (mysql_query(mysql, DROP_SAMPLE_TABLE))
{
  fprintf(stderr, " DROP TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

if (mysql_query(mysql, CREATE_SAMPLE_TABLE))
{
  fprintf(stderr, " CREATE TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

/* Prepare an INSERT query with 3 parameters */
/* (the TIMESTAMP column is not named; it will */
/* be set to the current date and time) */
stmt = mysql_prepare(mysql, INSERT_SAMPLE, strlen(INSERT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), INSERT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, INSERT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in INSERT: %d\n", param_count);

if (param_count != 3) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Bind the data for all 3 parameters */

/* INTEGER PARAM */
/* This is a number type, so there is no need to specify buffer_length */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *)&int_data;
bind[0].is_null= 0;
bind[0].length= 0;

/* STRING PARAM */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *)str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= 0;
bind[1].length= &str_length;

/* SMALLINT PARAM */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *)&small_data;
bind[2].is_null= &is_null;
bind[2].length= 0;

/* Bind the buffers */
if (mysql_bind_param(stmt, bind))
{
  fprintf(stderr, " mysql_bind_param() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Specify the data values for the first row */
int_data= 10;             /* integer */
strncpy(str_data, "MySQL", STRING_SIZE); /* string  */
str_length= strlen(str_data);

/* INSERT SMALLINT data as NULL */
is_null= 1;

/* Execute the INSERT statement - 1*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), 1 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total number of affected rows */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 1): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Specify data values for second row, then re-execute the statement */
int_data= 1000;
strncpy(str_data, "The most popular open source database", STRING_SIZE);
str_length= strlen(str_data);
small_data= 1000;         /* smallint */
is_null= 0;               /* reset */

/* Execute the INSERT statement - 2*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute, 2 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total rows affected */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 2): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Close the statement */
if (mysql_stmt_close(stmt))
{
  fprintf(stderr, " failed while closing the statement\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

주의: Prepared Statement 함수를 사용한 완전한 예에 대해서는, 파일 tests/mysql_client_test.c (을)를 참조해 주세요.이 파일은,MySQL 소스 디스트리뷰션 또는 BitKeeper 소스 리포지터리(repository)로부터 취득할 수 있습니다.

11.1.7.6. mysql_stmt_affected_rows()

my_ulonglong mysql_stmt_affected_rows(MYSQL_STMT *stmt)

설명

마지막에 실행된 스테이트먼트에 의해서 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려줍니다.UPDATE ,DELETE , 또는 INSERT 의 몇개의 스테이트먼트에 대해서 mysql_execute() (을)를 호출한 직후에 불려 갈 가능성이 있습니다.SELECT 스테이트먼트의 경우,mysql_stmt_affected_rows() (을)를 호출하면,mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해서 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타내 보입니다.－1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_fetch() (을)를 호출하기 전에 mysql_stmt_affected_rows() 하지만 불려 간 것을 나타내 보입니다.

에러

없습니다.

례

mysql_stmt_affected_rows() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.7. mysql_bind_result()

my_bool mysql_bind_result(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_result() (은)는, 결과 세트의 컬럼을 데이터 버퍼 및 길이 버퍼에 관련짓는(바인드 한다) 위해(때문에) 사용합니다.mysql_fetch() (을)를 호출해 데이터를 취득하는 경우,MySQL 클라이언트/ 서버 프로토콜에 의해서, 바인드 된 컬럼의 데이터가 지정된 버퍼에 써집니다.

주의: mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 결과 세트의 각 컬럼에 대응한 요소가 포함되어 있으면 가정합니다.요소가 포함되지 않은 경우,mysql_fetch() (은)는 단지 데이터를 취득하지 않습니다.또, 클라이언트/ 서버 프로토콜은 데이터의 값을 분리해 돌려주지는 않기 때문에, 버퍼의 사이즈는 데이터치를 격납 가능한 한의 충분한 크기일 필요가 있습니다.

컬럼은, 임의의 시점에서, 결과 세트의 일부만이 취득된 다음에도, 바인드 또는 재바인드 할 수 있습니다.새롭게 바인드 했을 경우, 그것이 유효하게 되는 것은, 다음에 mysql_fetch() (을)를 호출했을 때입니다.예를 들어, 어플리케이션이 결과 세트의 컬럼을 바인드 해 mysql_fetch() (을)를 호출한다고 합니다.클라이언트/ 서버 프로토콜은, 바인드 된 버퍼에 데이터를 돌려줍니다.다음에 어플리케이션이 컬럼을 다른 버퍼에 바인드 한다고 합니다.프로토콜은, 다음에 mysql_fetch() 하지만 불려 갈 때까지, 새롭고 바인드 된 버퍼에 데이터를 쓰지 않습니다.

컬럼을 바인드 하려면 , 어플리케이션은 mysql_bind_result() (을)를 호출하고, 형태, 주소, 및 길이 버퍼의 주소를 건네줍니다.설정할 필요가 있다 MYSQL_BIND 의 각 요소의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_result() 의 사용 방법에 대해서는, 항11.1.7.13. 「mysql_fetch() 」 의 「예」를 참조해 주세요.

11.1.7.8. mysql_stmt_store_result()

int mysql_stmt_store_result(MYSQL_STMT *stmt)

설명

쿼리가 결과 세트를 정상적으로 생성해(SELECT ,SHOW ,DESCRIBE ,EXPLAIN ), 한층 더 클라이언트의 버퍼에 결과 세트 전체를 격납하고, 그 후의 mysql_fetch() 의 호출로 버퍼 된 데이터가 돌려주어지도록(듯이) 하는 경우에 한정해,mysql_stmt_store_result() (을)를 호출할 필요가 있습니다.

그러한 쿼리 이외에서는 mysql_stmt_store_result() (을)를 호출할 필요는 없습니다만, 호출했다고 해도 이상이 발생하거나 눈에 띈 동작을 하는 일은 일절 없습니다.mysql_get_metadata() 하지만 NULL (을)를 돌려줄지를 조사하는 것으로, 쿼리가 결과 세트를 생성했는지를 검출할 수 있습니다.상세한 것에 대하여는, 항11.1.7.3. 「mysql_get_metadata() 」 (을)를 참조해 주세요.

반환값

결과 세트가 정상적으로 버퍼에 격납되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.7.9. mysql_stmt_data_seek()

void mysql_stmt_data_seek(MYSQL_STMT *stmt, my_ulonglong offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_stmt_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_stmt_data_seek() (을)를 사용하려면 , 스테이트먼트의 결과 세트 구조체에 마지막에 실행된 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.7.10. mysql_stmt_row_seek()

MYSQL_ROW_OFFSET mysql_stmt_row_seek(MYSQL_STMT *stmt, MYSQL_ROW_OFFSET offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 레코드 커서를 설정합니다.offset 의 값은 레코드 오프셋이며,mysql_stmt_row_tell() 또는 mysql_stmt_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_stmt_data_seek() (을)를 사용합니다.

mysql_stmt_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_stmt_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수 있습니다.

에러

없습니다.

11.1.7.11. mysql_stmt_row_tell()

MYSQL_ROW_OFFSET mysql_stmt_row_tell(MYSQL_STMT *stmt)

설명

마지막에 실행되었다 mysql_fetch() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_stmt_row_seek() 에 인수로서 건네줄 수 있습니다.

mysql_stmt_row_tell() (은)는,mysql_stmt_store_result() 의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋.

에러

없습니다.

11.1.7.12. mysql_stmt_num_rows()

my_ulonglong mysql_stmt_num_rows(MYSQL_STMT *stmt)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_stmt_num_rows() (을)를 사용할지 어떨지는,mysql_stmt_store_result() (을)를 사용해 결과 세트 전체를 스테이트먼트 핸들에 격납했는지에 의해서 정해집니다.

mysql_stmt_store_result() (을)를 사용하는 경우, 곧바로 mysql_stmt_num_rows() (을)를 호출할 수 있습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.7.13. mysql_fetch()

int mysql_fetch(MYSQL_STMT *stmt)

설명

mysql_fetch() (은)는, 결과 세트의 다음의 레코드를 취득합니다.이 함수는 결과 세트가 존재하는 동안만, 즉,mysql_execute() (을)를 호출해 결과 세트를 작성한 후, 또는 mysql_execute() (을)를 호출해 결과 세트 전체를 버퍼에 격납하고 나서 mysql_stmt_store_result() (을)를 호출한 후에게만, 호출할 수 있습니다.

mysql_fetch() (은)는,mysql_bind_result() (을)를 호출해 바인드 한 버퍼를 사용해 레코드 데이터를 돌려줍니다.버퍼에는, 현재의 레코드 세트의 모든 컬럼의 데이터가 격납됩니다.데이터의 길이는 length 포인터에 돌려주어집니다.

주의: 어플리케이션은,mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.

취득한 데이터가 NULL 값이었던 경우, 대응한다 MYSQL_BIND 구조체의 *is_null 의 값에는 TRUE (1 )(이)가 격납됩니다.그 이외의 값이었던 경우, 어플리케이션이 지정한 버퍼의 형태에 근거하고, 데이터 및 그 길이가 각각 *buffer 요소 및 *length 요소에 돌려주어집니다.수치형 및 시간적인 값의 형태는, 이하의 겉(표)에 나타내도록(듯이), 각각 고정장입니다.문자열형의 길이는, 실제의 데이터의 길이에 의해서 정해져,data_length 에 의해서 나타내집니다.

형 | 길이
MYSQL_TYPE_TINY | 1
MYSQL_TYPE_SHORT | 2
MYSQL_TYPE_LONG | 4
MYSQL_TYPE_LONGLONG | 8
MYSQL_TYPE_FLOAT | 4
MYSQL_TYPE_DOUBLE | 8
MYSQL_TYPE_TIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATE | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATETIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_STRING | data length
MYSQL_TYPE_BLOB | data_length

반환값

반환값 | 설명
0 | 정상.데이터는 어플리케이션 데이터 버퍼에 취득되고 있다.
1 | 에러가 발생했다.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해서 취득할 수 있다.
MYSQL_NO_DATA | 취득되어 있지 않은 레코드/ 데이터는 남지 않았다.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • CR_UNSUPPORTED_PARAM_TYPE

    버퍼의 형태는 MYSQL_TYPE_DATE ,MYSQL_TYPE_TIME ,MYSQL_TYPE_DATETIME , 또는 MYSQL_TYPE_TIMESTAMP 그런데, 데이터의 형태는 DATE ,TIME ,DATETIME , 또는 TIMESTAMP 의 머지않아도 아니다.

  • 그 외의 서포트되어 있지 않은 변환에 관한 에러는 모두 mysql_bind_result() (으)로부터 돌려주어진다.

례

이하의 예에서는,mysql_get_metadata() ,mysql_bind_result() , 및 mysql_fetch() (을)를 사용하고, 테이블에서 데이터를 취득하는 방법을 나타냅니다(이 예에서는 항11.1.7.5. 「mysql_execute() 」 의 예로 삽입되었다 2 행의 레코드를 취득하는 것과 상정하고 있습니다).mysql 변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define SELECT_SAMPLE "SELECT col1, col2, col3, col4 FROM test_table"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[4];
MYSQL_RES     *prepare_meta_result;
MYSQL_TIME    ts;
unsigned long length[4];
int           param_count, column_count, row_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
my_bool       is_null[4];

/* Prepare a SELECT query to fetch data from test_table */
stmt = mysql_prepare(mysql, SELECT_SAMPLE, strlen(SELECT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), SELECT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, SELECT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in SELECT: %d\n", param_count);

if (param_count != 0) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Fetch result set meta information */
prepare_meta_result = mysql_get_metadata(stmt);
if (!prepare_meta_result)
{
  fprintf(stderr, " mysql_get_metadata(), returned no meta information\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get total columns in the query */
column_count= mysql_num_fields(prepare_meta_result);
fprintf(stdout, " total columns in SELECT statement: %d\n", column_count);

if (column_count != 4) /* validate column count */
{
  fprintf(stderr, " invalid column count returned by MySQL\n");
  exit(0);
}

/* Execute the SELECT query */
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Bind the result buffers for all 4 columns before fetching them */

/* INTEGER COLUMN */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *)&int_data;
bind[0].is_null= &is_null[0];
bind[0].length= &length[0];

/* STRING COLUMN */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *)str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= &is_null[1];
bind[1].length= &length[1];

/* SMALLINT COLUMN */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *)&small_data;
bind[2].is_null= &is_null[2];
bind[2].length= &length[2];

/* TIMESTAMP COLUMN */
bind[3].buffer_type= MYSQL_TYPE_TIMESTAMP;
bind[3].buffer= (char *)&ts;
bind[3].is_null= &is_null[3];
bind[3].length= &length[3];

/* Bind the result buffers */
if (mysql_bind_result(stmt, bind))
{
  fprintf(stderr, " mysql_bind_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Now buffer all results to client */
if (mysql_stmt_store_result(stmt))
{
  fprintf(stderr, " mysql_stmt_store_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Fetch all rows */
row_count= 0;
fprintf(stdout, "Fetching results ...\n");
while (!mysql_fetch(stmt))
{
  row_count++;
  fprintf(stdout, "  row %d\n", row_count);

  /* column 1 */
  fprintf(stdout, "   column1 (integer)  : ");
  if (is_null[0])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %d(%ld)\n", int_data, length[0]);

  /* column 2 */
  fprintf(stdout, "   column2 (string)   : ");
  if (is_null[1])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %s(%ld)\n", str_data, length[1]);

  /* column 3 */
  fprintf(stdout, "   column3 (smallint) : ");
  if (is_null[2])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %d(%ld)\n", small_data, length[2]);

  /* column 4 */
  fprintf(stdout, "   column4 (timestamp): ");
  if (is_null[3])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %04d-%02d-%02d %02d:%02d:%02d (%ld)\n",
                                               ts.year, ts.month, ts.day,
                                               ts.hour, ts.minute, ts.second,
                                               length[3]);
  fprintf(stdout, "\n");
}

/* Validate rows fetched */
fprintf(stdout, " total rows fetched: %d\n", row_count);
if (row_count != 2)
{
  fprintf(stderr, " MySQL failed to return all rows\n");
  exit(0);
}

/* Free the prepared result metadata */
mysql_free_result(prepare_meta_result);

/* Close the statement */
if (mysql_stmt_close(stmt))
{
  fprintf(stderr, " failed while closing the statement\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

11.1.7.14. mysql_send_long_data()

my_bool mysql_send_long_data(MYSQL_STMT *stmt, unsigned int parameter_number, const char *data, unsigned long length)

설명

어플리케이션은 이 함수를 사용하고, 파라미터 데이터를 개별적으로(또는 `` 분리해'' ) 서버에 송신할 수 있습니다.이 함수를 여러 차례 호출하는 것에 의해서,TEXT 또는 BLOB 의 어느 쪽인가의 데이터형의 컬럼의 문자 데이터치 또는 바이너리 데이터치를 여러 차례로 나누어 송신할 수 있습니다.

parameter_number (은)는, 데이터를 관련짓는 파라미터를 나타내는 번호입니다.파라미터의 번호는 0 (으)로부터 시작됩니다.data (은)는 송신 데이터를 포함한 버퍼에의 포인터를,length (은)는 버퍼내의 데이터의 아르바이트수를 나타냅니다.

반환값

데이터를 서버에 정상적으로 송신할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_INVALID_PARAMETER_NO

    무효인 파라미터 번호가 지정되었다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

이하의 예에서는,TEXT 형태 컬럼의 데이터를 분리해 송신하는 방법을 나타냅니다.여기에서는, 데이터치 'MySQL - The most popular open source database' (을)를 text_column 컬럼에 삽입합니다.mysql 변수는 유효한 접속 핸들로 합니다.

#define INSERT_QUERY "INSERT INTO test_long_data(text_column) VALUES(?)"

MYSQL_BIND bind[1];
long       length;

if (!mysql_prepare(mysql, INSERT_QUERY, strlen(INSERT_QUERY))
{
  fprintf(stderr, "\n prepare failed");
  fprintf(stderr, "\n %s", mysql_error(mysql));
  exit(0);
}
 memset(bind, 0, sizeof(bind));
 bind[0].buffer_type= MYSQL_TYPE_STRING;
 bind[0].length= &length;
 bind[0].is_null= 0;

/* Bind the buffers */
if (mysql_bind_param(stmt, bind))
{
  fprintf(stderr, "\n param bind failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Supply data in chunks to server */
 if (!mysql_send_long_data(stmt,0,"MySQL",5))
{
  fprintf(stderr, "\n send_long_data failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Supply the next piece of data */
 if (mysql_send_long_data(stmt,0," - The most popular open source database",40))
{
  fprintf(stderr, "\n send_long_data failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Now, execute the query */
 if (mysql_execute(stmt))
{
  fprintf(stderr, "\n mysql_execute failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

11.1.7.15. mysql_stmt_close()

my_bool mysql_stmt_close(MYSQL_STMT *)

설명

프리페아드스테이트먼트를 클로우즈 합니다.mysql_stmt_close() 그럼,stmt 하지만 나타내 보이는 스테이트먼트 핸들에 할당할 수 있었던 메모리도 해방됩니다.

현재의 스테이트먼트의 결과 세트의 처리가 도중인가, 또는 취득되어 있지 않은 레코드가 남아 있는 경우, 이 함수를 호출하면, 그 상태를 캔슬하고, 다음의 쿼리를 실행할 수 있도록 합니다.

반환값

스테이트먼트가 정상적으로 해방되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_stmt_close() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.16. mysql_stmt_errno()

unsigned int mysql_stmt_errno(MYSQL_STMT *stmt)

설명

mysql_stmt_errno() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 스테이트먼트 API 함수의 에러 코드를 돌려줍니다.반환값이 0 의 경우, 에러는 발생하고 있지 않습니다.클라이언트의 에러 메세지 번호의 일람은,MySQL errmsg.h 헤더 파일에 기술되고 있습니다.서버의 에러 메세지 번호의 일람은,mysqld_error.h 에 기술되고 있습니다.MySQL 소스 디스트리뷰션에 포함되는 파일 Docs/mysqld_error.txt 에는, 모든 에러 메세지 및 에러 번호의 일람이 기술되고 있습니다.서버의 에러 코드의 일람은, 항12.1. 「돌려주어지는 에러」 에도 기재되어 있습니다.

반환값

에러 코드의 값.에러가 발생하고 있지 않는 경우는 0 .

에러

없습니다.

11.1.7.17. mysql_stmt_error()

const char *mysql_stmt_error(MYSQL_STMT *stmt)

설명

mysql_stmt_error() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 스테이트먼트 API 함수의 에러 메세지를 포함한 눌 종단 문자열을 돌려줍니다.에러가 발생하고 있지 않는 경우는 공문자열("" )(을)를 돌려줍니다.이것은, 다음의 2 개의 비교는 등가인 것을 의미합니다.

if (mysql_stmt_errno(stmt))
{
  // an error occurred
}

if (mysql_stmt_error(stmt)[0])
{
  // an error occurred
}

클라이언트의 에러 메세지의 언어는,MySQL 클라이언트 라이브러리를 재컴파일 하는 것에 의해서 변경할 수 있습니다.현재는, 복수가 다른 언어로 에러 메세지를 돌려줄 수 있습니다.

반환값

에러의 내용을 설명하는 문자열.에러가 발생하고 있지 않는 경우는 공문자열.

에러

없습니다.

11.1.7.18. mysql_stmt_sqlstate()

const char *mysql_stmt_sqlstate(MYSQL_STMT *stmt)

설명

mysql_stmt_sqlstate() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 프리페아드스테이트먼트 API 함수의 SQLSTATE 에러 코드를 포함한 눌 종단 문자열을 돌려줍니다.에러 코드는 5 문자로 나타납니다."00000" (은)는,`` 에러가 없다'' 일을 의미합니다.값은 ANSI SQL 및 ODBC 에 의해서 규정되고 있습니다.생각할 수 있는 값의 일람에 대해서는, 항12.1. 「돌려주어지는 에러」 (을)를 참조해 주세요.

주의: 모든 MySQL 에러가 SQLSTATE 에 매핑 되고 있는 것은 아닙니다.매핑 되어 있지 않은 에러의 경우는 "HY000" (일반 에러)(이)가 사용됩니다.

이 함수는 MySQL 4.1.1 그리고 추가되었습니다.

반환값

SQLSTATE 에러 코드를 포함한 눌 종단 문자열.

11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급

MySQL (은)는, 버젼 4.1 (으)로부터 1 개의 쿼리 문자열로 지정된 복수 스테이트먼트의 실행을 서포트합니다.접속으로 이 기능을 사용하려면 , 접속을 오픈할 경우에 mysql_real_connect() 의 플래그 파라미터로 CLIENT_MULTI_STATEMENTS 옵션을 지정할 필요가 있습니다.이 옵션은,mysql_set_server_option(MYSQL_OPTION_MULTI_STATEMENTS_ON) (을)를 호출하는 것으로, 접속에 대해서 설정할 수도 있습니다.

디폴트에서는,mysql_query() 및 mysql_real_query() (은)는 최초의 쿼리의 스테이터스만을 돌려줍니다.그 후의 쿼리의 스테이터스는 mysql_more_results() 및 mysql_next_result() (을)를 사용해 처리할 수 있습니다.

/* Connect to server with option CLIENT_MULTI_STATEMENTS */
mysql_real_connect(..., CLIENT_MULTI_STATEMENTS);

/* Now execute multiple queries */
mysql_query(mysql,"DROP TABLE IF EXISTS test_table;\
                   CREATE TABLE test_table(id INT);\
                   INSERT INTO test_table VALUES(10);\
                   UPDATE test_table SET id=20 WHERE id=10;\
                   SELECT * FROM test_table;\
                   DROP TABLE test_table";
do
{
  /* Process all results */
  ...
  printf("total affected rows: %lld", mysql_affected_rows(mysql));
  ...
  if (!(result= mysql_store_result(mysql)))
  {
     printf(stderr, "Got fatal error processing query\n");
     exit(1);
  }
  process_result_set(result);	/* client function */
  mysql_free_result(result);
} while (!mysql_next_result(mysql));

11.1.9. C API 에 있어서의 일자치 및 시각치의 취급

MySQL 4.1 그리고 도입된 새로운 바이너리 프로토콜을 사용하면,MYSQL_TIME 구조체를 사용해 일자 및 시각에 관한 값(DATE ,TIME ,DATETIME , 및 TIMESTAMP )(을)를 송수신 할 수 있습니다.이 구조체의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

시간적인 데이터를 송신하려면 ,mysql_prepare() (을)를 사용해 프리페아드스테이트먼트를 작성합니다.다음에 mysql_execute() (을)를 호출해 스테이트먼트를 실행하기 전에, 이하의 순서를 실행해 시간적인 파라미터를 설정합니다.

  1. 데이터치에 관련지을 수 있었다 MYSQL_BIND 구조체의 멤버 buffer_type 에, 송신하는 시간적인 값의 형태를 나타내는 값을 설정한다.DATE ,TIME ,DATETIME , 또는 TIMESTAMP 의 값의 경우,buffer_type 에 MYSQL_TYPE_DATE ,MYSQL_TYPE_TIME ,MYSQL_TYPE_DATETIME , 또는 MYSQL_TYPE_TIMESTAMP (을)를 각각 설정한다.

  2. MYSQL_BIND 구조체의 멤버 buffer 에, 시간적인 값이 격납되고 있다 MYSQL_TIME 구조체의 주소를 설정한다.

  3. 시간적인 값의 형태에 맞추어 MYSQL_TIME 구조체의 필요한 멤버의 값을 설정한다.

mysql_bind_param() (을)를 사용해 파라미터 데이터를 스테이트먼트에 바인드 합니다.이것으로 mysql_execute() (을)를 호출할 준비가 완료합니다.

시간적인 값을 취득하는 순서는 거의 같습니다만,buffer_type 멤버에는 취득하려고 하는 값의 형태를 설정하는 점, 및 buffer 멤버에는 돌려주어지는 값을 격납한다 MYSQL_TIME 구조체의 주소를 설정하는 점이 다릅니다.mysql_execute() (을)를 호출한 후, 결과를 취득할 때까지 에,mysql_bind_results() (을)를 호출하고, 버퍼를 스테이트먼트에 바인드 합니다.

이하의 예에서는,DATE ,TIME , 및 TIMESTAMP 의 형태의 데이터를 삽입하는 방법을 나타냅니다.mysql 변수는 유효한 접속 핸들로 합니다.

MYSQL_TIME  ts;
MYSQL_BIND  bind[3];
MYSQL_STMT  *stmt;

  strmov(query, "INSERT INTO test_table(date_field, time_field,
                                        timestamp_field) VALUES(?,?,?");

  stmt= mysql_prepare(mysql, query, strlen(query)));

  /* setup input buffers for all 3 parameters */
  bind[0].buffer_type= MYSQL_TYPE_DATE;
  bind[0].buffer= (char *)&ts;
  bind[0].is_null= 0;
  bind[0].length= 0;
  ..
  bind[1]= bind[2]= bind[0];
  ..

  mysql_bind_param(stmt, bind);

  /* supply the data to be sent is the ts structure */
  ts.year= 2002;
  ts.month= 02;
  ts.day= 03;

  ts.hour= 10;
  ts.minute= 45;
  ts.second= 20;

  mysql_execute(stmt);
  ..

11.1.10. C API 스레드 함수의 설명

스레드 클라이언트를 작성하려면 , 이하의 함수를 사용할 필요가 있습니다. See 항11.1.14. 「스레드 클라이언트의 작성 방법」 .

11.1.10.1. my_init()

void my_init(void)

설명

이 함수는, 다른 MySQL 함수를 호출하기 전에, 프로그램내에서 1 회만 호출할 필요가 있습니다.MySQL 하지만 필요로 하는 몇개의 글로벌 변수를 초기화합니다.스레드세이후인 클라이언트 라이브러리를 사용하고 있는 경우, 이 함수는 현재의 스레드에 대해서 mysql_thread_init() 의 호출도 실시합니다.

mysql_init() ,mysql_server_init() , 및 mysql_connect() (은)는, 자동적으로 이 함수를 호출합니다.

반환값

없습니다.

11.1.10.2. mysql_thread_init()

my_bool mysql_thread_init(void)

설명

스레드를 작성하면, 스레드 고유의 변수를 초기화하기 위해서 이 함수를 호출할 필요가 있습니다.

my_init() 및 mysql_connect() (은)는, 자동적으로 이 함수를 호출합니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

11.1.10.3. mysql_thread_end()

void mysql_thread_end(void)

설명

mysql_thread_init() (을)를 호출하기 전에 이 함수를 호출하고,pthread_exit() 에 의해서 할당할 수 있었던 메모리를 해방할 필요가 있습니다.

주의: 이 함수는, 클라이언트 라이브러리에서는 자동적으로 불려 가지 않습니다 .메모리 리크를 피하기 위해서, 명시적으로 호출할 필요가 있습니다.

반환값

없습니다.

11.1.10.4. mysql_thread_safe()

unsigned int mysql_thread_safe(void)

설명

이 함수는, 클라이언트가 스레드세이후로서 컴파일 되었는지를 나타냅니다.

반환값

클라이언트가 스레드세이후의 경우는 1 , 그 이외의 경우는 0 .

11.1.11. C API 편입 서버 함수의 설명

어플리케이션을 짜넣어 MySQL 서버 라이브러리와 링크하는 경우, 이하로 설명하는 함수를 사용할 필요가 있습니다. See 항11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld 」 .

프로그램을,-lmysqld (이)가 아니고,-lmysqlclient (을)를 지정해 링크했을 경우, 이러한 함수는 아무것도 실행하지 않습니다.그 때문에, 코드를 변경하지 않아도, 편입 MySQL 서버 및 스탠드얼론 서버의 어느 쪽을 사용하는지를 선택할 수 있습니다.

11.1.11.1. mysql_server_init()

int mysql_server_init(int argc, char **argv, char **groups)

설명

이 함수는, 편입 서버를 사용하는 프로그램으로, 다른 MySQL 함수를 호출하기 전에,1 회만 호출한다 필요가 있습니다 .우선 짜넣어 서버를 기동해, 이 서버가 사용하는 하부조직(mysys ,InnoDB 등)을 모두 초기화합니다.이 함수를 호출하지 않았던 경우, 프로그램은 크래쉬 합니다.MySQL 에 부속의 DBUG 패키지를 사용하고 있는 경우는,MY_INIT() (을)를 호출한 후에 이 함수를 호출할 필요가 있습니다.

인수의 argc 및 argv (은)는,main() 의 인수와 닮아 있습니다.argv 의 최초의 요소는, 통상은 프로그램명이며, 무시됩니다.사용하기 쉽게 하기 위해서, 서버에 대해서 커멘드 라인 인수가 없는 경우,argc 하 0 (제로)(이)가 됩니다.mysql_server_init() (은)는 인수의 카피를 작성하므로, 그것을 호출한 다음은 argv 또는 groups (을)를 부수어도 문제 없습니다.

groups 의 NULL 그리고 종단 된 문자열의 리스트는, 옵션 설정 파일의 어느 그룹을 액티브하게 하는지를 선택합니다.See 항4.1.2. 「my.cnf 옵션 설정 파일」 . 사용하기 쉽게 하기 위해서,groups 하지만 NULL 의 경우는,[server] 및 [embedded] 그룹이 읽힙니다.

례

#include <mysql.h>
#include <stdlib.h>

static char *server_args[] = {
  "this_program",       /* this string is not used */
  "--datadir=.",
  "--key_buffer_size=32M"
};
static char *server_groups[] = {
  "embedded",
  "server",
  "this_program_SERVER",
  (char *)NULL
};

int main(void) {
  mysql_server_init(sizeof(server_args) / sizeof(char *),
                    server_args, server_groups);

  /* Use any MySQL API functions here */

  mysql_server_end();

  return EXIT_SUCCESS;
}

반환값

정상적으로 종료했을 경우는 0 .에러가 발생했을 경우는 1 .

11.1.11.2. mysql_server_end()

void mysql_server_end(void)

설명

이 함수는, 다른 MySQL 함수를 모두 호출한 후에 1 회 호출한다 필요가 있습니다 .편입 서버를 슛다운 합니다.

반환값

없습니다.

11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제

11.1.12.1. mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지

mysql_query() 의 호출이 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려줄 가능성은 있습니다.이러한 상황이 발생했을 경우, 이하의 몇개의 조건이 성립한 것을 의미합니다.

  • malloc() 하지만 이상종료(ABEND) 했다(결과 세트가 너무 컸을 경우 등)

  • 데이터를 읽어들일 수 없었다(접속에 에러가 발생했다)

  • 데이터를 돌려주지 않는 쿼리였다(INSERT ,UPDATE , 또는 DELETE (이었)였던 경우 등)

mysql_field_count() (을)를 호출하는 것에 의해서, 스테이트먼트가 하늘이 아닌 결과 세트를 생성했는지를 언제라도 조사할 수 있습니다.mysql_field_count() 하지만 0 (을)를 돌려주는 경우, 결과 세트는 하늘이며, 마지막에 실행한 쿼리는 결과를 돌려주고 있지 않습니다(INSERT 또는 DELETE 등).mysql_field_count() 하지만 0 이외의 값을 돌려주는 경우, 스테이트먼트는 하늘이 아닌 결과 세트를 돌려주고 있습니다.예에 대해서는,mysql_field_count() 함수의 설명을 참조해 주세요.

mysql_error() 또는 mysql_errno() (을)를 호출하는 것에 의해서, 에러가 발생했는지를 판정할 수 있습니다.

11.1.12.2. 쿼리로부터 취득할 수 있는 결과에는 어떠한 것이 있을까

쿼리는, 결과 세트를 돌려주는 것 외에, 이하의 정보를 제공합니다.

  • mysql_affected_rows() (은)는,INSERT ,UPDATE , 또는 DELETE (을)를 실행하는 경우, 마지막에 실행한 쿼리로 삽입, 갱신, 또는 삭제된 레코드의 수를 돌려준다.예외는,WHERE 마디를 사용하지 않고 DELETE (을)를 실행했을 경우로, 이 때는 시간을 큰폭으로 단축하기 위해서 테이블을 하늘 상태로 재작성한다.이 경우,mysql_affected_rows() (은)는 삭제된 레코드가 수라고 해 0 (을)를 돌려준다.

  •               mysql_num_rows()

(은)는 결과 세트의 레코드수를 돌려준다.mysql_store_result()

(을)를 사용하는 경우,mysql_store_result()

하지만 복귀한 직후에
              mysql_num_rows()

(을)를 호출할 수 있다.mysql_use_result()

(을)를 사용하는 경우,mysql_fetch_row()

(을)를 사용해 모든 레코드를 취득한 다음에 마셔
              mysql_num_rows()

(을)를 호출할 수 있다.

  • mysql_insert_id() (은)는,AUTO_INCREMENT 인덱스를 사용해 테이블에 레코드를 삽입한 마지막 쿼리가 생성했다 ID 11.2. MySQL 의 ODBC 서포트

    11.2. MySQL 의 ODBC 서포트

    MySQL (은)는,MyODBC 프로그램이라고 하는 형태로 ODBC (을)를 서포트합니다.이 장에서는,MyODBC 의 인스톨 방법 및 그 사용 방법에 대해 설명합니다.또,MyODBC (와)과 제휴해 동작하는 것이 알려져 있는 공통 프로그램의 리스트도 제공합니다.

    11.2.1. MyODBC 의 인스톨 방법

    MyODBC 2.50 (은)는,ODBC 대응 어플리케이션이 MySQL 에 접속하기 위한 32 비트 ODBC 2.50 사양 레벨 0 (레벨 1 및 레벨 2 의 기능을 포함한다)의 드라이버입니다.MyODBC (은)는,Windows 9x/Me/NT/2000/XP 및 대부분의 Unix 플랫폼에서 동작합니다.MyODBC 3.51 (은)는,ODBC 3.5x 사양 레벨 1 (완전한 코어 API 및 레벨 2 의 기능을 포함한다)의 확장 버젼입니다.

    MyODBC 하 Open Source (이어)여,http://www.mysql.com/downloads/api-myodbc.html 그리고 최신 버젼이 공개되고 있습니다.주의: 2.50.x 버젼에는 LGPL 라이센스가 적용되어3.51.x 버젼에는 GPL 라이센스가 적용됩니다.

    MyODBC (을)를 사용해 문제가 발생하는 경우, 그것이 OLEDB (와)과 제휴해 동작하는 프로그램이면,OLEDB 드라이버를 시험할 필요가 있습니다.

    통상은,Windows 머신에 MyODBC (을)를 인스톨 할 필요가 있을 뿐입니다.Unix 그리고 MyODBC 하지만 필요하게 되는 것은,ColdFusion (와)과 같이,Unix 머신상에서 동작하면서 ODBC (을)를 사용해 데이타베이스에 접속하는 프로그램을 실행하는 경우만입니다.

    Unix 머신에 MyODBC (을)를 인스톨 하는 경우는,ODBC 매니저도 필요합니다.MyODBC (은)는, 대부분의 Unix ODBC 매니저로 동작하는 것이 알려져 있습니다.

    Windows 머신에 MyODBC (을)를 인스톨 하려면 , 적절한 MyODBC .zip 파일을 다운로드해,WinZip 등의 프로그램으로 해동하고,SETUP.EXE 파일을 실행합니다.

    Windows/NT/XP 머신에서는,MyODBC (을)를 인스톨 할 때에 이하의 에러가 발생할 가능성이 있습니다.

    An error occurred while copying C:\WINDOWS\SYSTEM\MFC30.DLL. Restart
Windows and try installing again (before running any applications which
use ODBC)

    이 경우의 문제는, 다른 어떠한 프로그램이 ODBC (을)를 사용중이며,Windows 의 설계 방침으로서Microsoft 의 ODBC 셋업 프로그램으로 새롭다 ODBC 드라이버를 인스톨 할 수 없을 가능성이 있는 것입니다.대부분의 경우,Ignore (을)를 클릭하는 것만으로 나머지의 MyODBC 파일의 카피를 속행할 수 있어 인스톨 된 프로그램도 정상적으로 동작합니다.정상적으로 동작하지 않았던 경우의 해결책으로서는, 컴퓨터를 `` 세이프 모드'' 그리고 리부트해(리부트중에 Windows 하지만 일어서기 전에 F8 키를 누른다),MyODBC (을)를 인스톨 하고 나서, 통상 모드로 리부트합니다.

    • Unix 머신으로부터 Windows 머신에 ODBC 어플리케이션(MySQL (을)를 본래 서포트하지 않는 어플리케이션)을 사용해 접속하려면 , 우선 Windows 머신에 MyODBC (을)를 인스톨 할 필요가 있다.

    • 유저 및 Windows 머신에는,Unix 머신상의 MySQL 서버에의 액세스권이 필요하다.이 액세스권을 주려면 ,GRANT 커멘드를 사용한다. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」 .

    • 이하의 순서에 따라서,ODBC DSN 엔트리를 작성할 필요가 있다.

      • Windows 머신으로 [ 컨트롤 패널] (을)를 연다.

      • [ODBC Data Sources 32-bit] 아이콘을 더블 클릭 한다.

      • [User DSN] 탭을 클릭한다.

      • [Add] (을)를 클릭한다.

      • [Create New Data Source] 다이알로그 박스로 [MySQL] (을)를 선택해,[Finish] (을)를 클릭한다.

      • [MySQL Driver default configuration] 다이알로그 박스가 표시된다. See 항11.2.2. 「ODBC 아드?~ 니스트레이타의 필드의 설정 방법법」 .

    • 어플리케이션을 기동하고,ODBC 아드?~ 니스트레이타로 지정했다 DSN (와)과 ODBC 드라이버를 선택한다.

    주의: MySQL 의 화면에는 상기 이외에도 설정 옵션(트레이스, 접속시에 prompt를 표시하지 않는 등)이 있어, 문제가 발생했을 경우에 사용할 수 있습니다.

    11.2.2. ODBC 아드?~ 니스트레이타의 필드의 설정 방법법

    Windows 95 그럼 서버명을 지정하는 방법이 3 개 생각할 수 있습니다.

    • 서버의 IP 주소를 사용한다.

    • 이하의 정보를 \windows\lmhosts 파일에 추가한다.

      ip hostname

      예를 들어, 이하와 같이 지정한다.

      194.216.84.21 my_hostname

    • DNS (을)를 사용하도록(듯이) PC (을)를 설정한다.

    ODBC setup 의 입력예를 나타냅니다.

    Windows DSN name:   test
Description:        This is my test database
MySQL Database:     test
Server:             194.216.84.21
User:               monty
Password:           my_password
Port:

    Windows DSN name 필드의 값에는,Windows 의 ODBC 설정으로 일의인 이름을 지정합니다.

    ODBC setup 다이알로그 박스의 Server ,User ,Password , 또는 Port 의 각 필드는, 입력 필수 필드가 아닙니다.다만, 이러한 필드에 값을 입력했을 경우, 그 값은 다음에 접속할 때에 디폴트로서 사용됩니다.그 시점에서, 그 디폴트치를 변경할 수 있습니다.

    포토 번호가 지정되지 않았던 경우, 디폴트 포토(3306 )(이)가 사용됩니다.

    Read options from C:\my.cnf (을)를 유효하게 했을 경우,C:\my.cnf 파일로부터 client 그룹 및 odbc 그룹의 데이터가 읽힙니다.mysql_options() 하지만 사용 가능한 모든 옵션을 사용할 수 있습니다. See 항11.1.3.40. 「mysql_options() 」 .

    11.2.3. MyODBC 의 접속 파라미터

    ODBC.INI 파일의 [Servername] 섹션으로 이하에 나타낸다 MyODBC 의 파라미터를 지정할 수 있습니다.이러한 파라미터는,SQLDriverConnect() (을)를 호출할 때 건네주는 인수 InConnectionString 그렇지만 지정할 수 있습니다.

    파라미터 | 디폴트치 | 코멘트
    user | ODBC (Windows 위) | MySQL 에 접속할 때에 사용하는 유저명
    server | localhost | MySQL 서버의 호스트명
    database | 디폴트의 데이타베이스
    option | 0 | MyODBC 의 동작을 지정하는 정수(아래와 같이 참조)
    port | 3306 | server 하지만 localhost 이외의 값의 경우에 사용한다 TCP/IP 포토
    stmt | MySQL 에 접속할 때에 실행하는 스테이트먼트
    password | server (와)과 user 의 편성에 대한 패스워드
    socket | 접속하는 소켓 또는 Windows 파이프

    option 인수는, 클라이언트가 100% ODBC 준거는 아닌 것을 MyODBC 에 통지하기 위해서 사용합니다.Windows 그럼, 통상, 접속 화면에서 복수의 선택사항을 바꾸는 것에 의해서 옵션 플래그를 설정합니다만,option 인수로 설정할 수도 있습니다.이하에,MyODBC 접속 화면에 표시되는 것과 같은 순서로 옵션의 리스트를 나타냅니다.

    비트 | 설명
    1 | 클라이언트는 MyODBC 하지만 컬럼의 실제의 폭을 돌려주는 것에 대응하고 있지 않다.
    2 | 클라이언트는 MySQL 하지만 실제로 영향을 받은 레코드의 수를 돌려주는 것에 대응하고 있지 않다.이 플래그가 설정되어 있는 경우,MySQL (은)는 영향을 받은 레코드가 아니고, 발견된 레코드를 돌려준다.MySQL 하지만 실제로 영향을 받은 레코드의 수를 돌려주는 것에 대응하려면 ,MySQL 3.21.14 이?~ (을)를 사용할 필요가 있다.
    4 | 디버그 로그를 c:\myodbc.log 에 쓴다.이것은,AUTOEXEC.BAT 에 MYSQL_DEBUG=d:t:O,c::\myodbc.log (을)를 추가하는 것과 같다.
    8 | 결과 및 파라미터에 패킷 제한을 설정하지 않는다.
    16 | 드라이버가 입력을 요구하는 화면의 표시를 필요로 해도, 그것을 표시하지 않는다.
    32 | 상황에 따라 ODBC 1.0 드라이버를 시?~ 레이트 한다.
    64 | 'database.table.column' 그리고 데이타베이스명의 사용을 무시한다.
    128 | ODBC 매니저 커서의 사용을 강제한다(실험적).
    256 | 확장 취득의 사용을 무효로 한다(실험적).
    512 | CHAR 형태 필드에서는 컬럼폭전체에 문자를 패드 한다
    1024 | SQLDescribeCol() (은)는 완전 수식 컬럼명을 돌려준다.
    2048 | 압축된 서버/ 클라이언트 프로토콜을 사용한다.
    4096 | 서버에, 함수명의 뒤 및 '(' 의 전의 공백을 무시하도록(듯이) 통지한다 (PowerBuilder 그리고 필요).이것에 의해 모든 함수명을 키워드로 한다.
    8192 | NT 위에서 동작한다 mysqld 서버에 이름 파이프를 사용해 접속한다.
    16384 | LONGLONG 형태의 컬럼을 INT 형태의 컬럼으로 변경한다(일부의 어플리케이션에서는 LONGLONG 형태에 대응하고 있지 않다).
    32768 | SQLTables (으)로부터 Table_qualifier 및 Table_owner (으)로서 'user' (을)를 돌려준다(실험적).
    65536 | my.cnf 의 client 그룹 및 odbc 그룹으로부터 파라미터를 읽어들인다.
    131072 | 안전성 체크를 추가한다(그 필요는 없을지도 모르지만 만약을 위해).

    복수의 옵션을 선택하는 경우는 상기의 플래그를 가산합니다.예를 들어, 옵션을 12 (4+8 ) (으)로 설정하면, 패키지의 제약을 받지 않고 디버그 할 수 있습니다.

    최적인 퍼포먼스를 얻기 위해서, 디폴트로 MYODBC.DLL 하지만 컴파일 됩니다.MyODBC (을)를 디버그 하는 경우(예를 들어 트레이스 기능을 유효하게 한다), 대신에 MYODBCD.DLL (을)를 사용할 필요가 있습니다.이 파일을 인스톨 하려면 , 인스톨 되고 있다 MYODBC.DLL 파일에 MYODBCD.DLL (을)를 덧쓰기 카피합니다.

    11.2.4. MyODBC 에 관한 문제를 보고하는 방법

    MyODBC (은)는,Access ,Admndemo.exe ,C++-Builder ,Borland Builder 4 ,Centura Team Developer ( 구 Gupta SQL/Windows ),ColdFusion (Solaris 및 NT 위에서 서비스 팩 5 (을)를 사용),Crystal Reports ,DataJunction ,Delphi ,ERwin ,Excel ,iHTML ,FileMaker Pro ,FoxPro ,Notes 4.5/4.6 ,SBSS ,Perl DBD-ODBC ,Paradox ,Powerbuilder ,Powerdesigner 32 비트,VC++ , 및 Visual Basic (와)과의 동작을 시험하고 있습니다.

    MyODBC (와)과 제휴해 동작하는 어플리케이션을 그 밖에 아시는 분은,myodbc 메일링 리스트에 그 취지를 투고해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 .

    일부의 프로그램에서는 Another user has modifies the record that you have modified (와)과 같은 에러가 발생할 가능성이 있습니다.. 대부분의 경우, 이것은 이하의 어느쪽이든을 실행하는 것으로 해결할 수 있습니다.

    • 주키가 존재하지 않는 경우, 그것을 테이블에 추가한다.

    • 타임 스탬프형의 컬럼이 존재하지 않는 경우, 그것을 추가한다.

    • 배정도 부동 소수점형의 필드만을 사용한다.일부의 프로그램에서는 단정도 부동 소수점의 비교로 에러가 발생할 가능성이 있다.

    상기의 어떤 것을 실행해도 문제가 해결하지 않았던 경우,MyODBC 트레이스 파일을 유효하게 하고, 문제가 발생하는 원인을 조사할 필요가 있습니다.

    11.2.5. MyODBC (와)과 제휴해 동작하는 것이 알려져 있는 프로그램

    대부분의 프로그램은 MyODBC (와)과 제휴해 동작합니다만, 여기에 나타낸 프로그램에 대해서는, 당사가 사내에서 시험했는지, 또는 유저로부터 동작 확인했다고 하는 연락을 받고 있습니다.

    • 프로그램

      코멘트

    • Access

      Access (을)를 동작시키려면 , 이하의 처리를 실행한다.

      • Access 2000 (을)를 사용하고 있는 경우,http://www.microsoft.com/data/ (으)로부터 최신(버젼 2.6 이?~ )의 Microsoft MDAC (Microsoft Data Access Components )(을)를 다운로드해, 인스톨 할 필요가 있다.이것에 의해서,MySQL 에 데이터를 export 할 때에 테이블명 및 컬럼명이 지정되지 않는다고 한다 Access 의 버그가 수정된다.이 버그는,MyODBC 버젼 2.50.33 및 MySQL 버젼 3.23.x 에 업그레이드 하는 것에 의해서 회피할 수도 있다.

        그 외에,http://support.microsoft.com/support/kb/articles/Q 239/1/14.ASP 에서 공개되고 있다 Microsoft Jet 4.0 서비스 팩 5 (을)를 다운로드해, 적용할 필요도 있다.이것은,Access 그리고 컬럼이 #deleted# (와)과 마크 되는 경우가 있는 버그를 수정한다.

        주의: MySQL 버젼 3.22 (을)를 사용하고 있는 경우, 이 문제를 회피하려면 ,MDAC 패치를 적용해,MyODBC 2.50.32 또는 2.50.34 이?~ (을)를 사용할 필요가 있다.

      • Access 의 모든 버젼으로,MyODBC 의 옵션 플래그 Return matching rows (을)를 유효하게 할 필요가 있다.Access 2.0 그럼, 한층 더 Simulate ODBC 1.0 (을)를 유효하게 할 필요가 있다.

      • 갱신 가능하게 하는 모든 테이블로 타임 스탬프형의 컬럼을 정의할 필요가 있다.이식성을 최대로 하기 위해서,TIMESTAMP(14) 또는 단순한 TIMESTAMP (을)를,TIMESTAMP(X) 대신에 사용하는 것이 추천 된다.

      • 테이블에 주키를 정의할 필요가 있다.이것을 정의하지 않는 경우, 새롭게 추가한 레코드 또는 갱신한 레코드가 #DELETED# (으)로서 표시될 가능성이 있다.

      • DOUBLE 부동 소수점형의 필드만을 사용한다.Access 그럼, 단정도 부동 소수점형의 값을 비교할 수 없다.그 결과, 표면상은, 새롭게 추가한 레코드 또는 갱신된 레코드가 #DELETED# (으)로서 표시되거나 레코드를 검색 또는 갱신할 수 없다고 하는 현상이 발생한다.

      • BIGINT 형태의 컬럼을 가지는 테이블을 MyODBC 경유로 링크하고 있는 경우, 결과가 #DELETED (으)로서 표시된다.이하에 회피책을 나타낸다.

        • 데이터형이 TIMESTAMP , 할 수 있으면 TIMESTAMP(14) 의 다?~ -컬럼을 1 개추가한다.

        • ODBC DSN 아드?~ 니스트레이타의 접속 옵션을 지정하는 다이알로그 박스로,'Change BIGINT columns to INT' (을)를 온으로 한다.

        • Access (으)로부터 테이블 링크를 삭제해, 재작성한다.

        상기의 회피책을 실행한 후도, 기존의 레코드는 #DELETED# (으)로서 표시된 채로이지만, 새롭게 추가 또는 갱신된 레코드는 올바르게 표시되게 된다.

      • TIMESTAMP 형태 컬럼을 추가한 다음에도 에러 Another user has changed your data 하지만 발생하는 경우, 다음의 대책으로 해결할 가능성이 있다.

        테이블 데이타시트뷰를 사용하지 않는다.대신에 필요한 필드를 정의한 폼을 작성해, 폼 데이타시트뷰를 사용한다.TIMESTAMP 형태 컬럼의 DefaultValue 프롭퍼티를 NOW() (으)로 설정할 필요가 있다.이 테이블을 사용하는 유저가 혼란하지 않게,TIMESTAMP 형태 컬럼을 비표시로 하는 일도 1 개의 방법이다.

      • 경우에 따라서는,Access 하지만,MySQL 하지만 해석할 수 없는 부정한 SQL 쿼리를 생성할 가능성이 있다.이것은,Access 의 메뉴로부터 "Query|SQLSpecific|Pass-Through" (을)를 선택하는 것에 의해서 수정할 수 있다.

      • NT 위에서 동작한다 Access 하지만 BLOB 형태 컬럼을 OLE OBJECTS 형태로서 보고한다.대신에 MEMO 형태 컬럼을 사용하는 경우는,ALTER TABLE (을)를 사용해 컬럼을 TEXT 형태로 변경할 필요가 있다.

      • Access 하지만 DATE 형태 컬럼을 올바르게 처리할 수 없는 경우가 있다.이 문제가 발생하는 경우, 컬럼을 DATETIME 형태로 변경한다.

      • Access 그리고 BYTE 형태로서 정의되고 있는 컬럼을 사용하고 있는 경우,Access (은)는 이 컬럼을,TINYINT UNSIGNED 형태가 아니고,TINYINT 형태로서 export 하려고 한다.이 경우, 컬럼에 127 보다 큰 값이 격납되고 있으면 문제가 발생한다.

    • ADO

      ADO API 및 MyODBC (을)를 사용해 코딩 하는 경우,MySQL 서버로 서포트되지 않는 일부의 디폴트 프롭퍼티에 주의할 필요가 있다.예를 들어,CursorLocation 프롭퍼티 에 adUseServer 하지만 설정되어 있는 경우,RecordCount 프롭퍼티 하 -1 (을)를 돌려준다.올바른 값이 돌려주어지도록(듯이) 하려면 , 이하의 VB 코드로 나타내 보이도록(듯이), 이 프롭퍼티를 adUseClient (으)로 설정할 필요가 있다.

      Dim myconn As New ADODB.Connection
Dim myrs As New Recordset
Dim mySQL As String
Dim myrows As Long

myconn.Open "DSN=MyODBCsample"
mySQL = "SELECT * from user"
myrs.Source = mySQL
Set myrs.ActiveConnection = myconn
myrs.CursorLocation = adUseClient
myrs.Open
myrows = myrs.RecordCount

myrs.Close
myconn.Close

      다른 회피책으로서는, 같은 쿼리로 SELECT COUNT(*) 스테이트먼트를 사용해 적절한 레코드수를 취득하는 방법이 있다.

    • Active server pages (ASP )

      옵션 플래그 Return matching rows (을)를 사용할 필요가 있다.

    • BDE 어플리케이션

      옵션 플래그 Don't optimize column widths 및 Return matching rows (을)를 설정할 필요가 있다.

    • Borland Builder 4

      쿼리를 개시할 때,Active 프롭퍼티 또는 Open 메소드를 사용할 수 있다.주의: Active (은)는, 자동적으로 SELECT * FROM ... 쿼리를 발행해 쿼리를 개시하지만, 테이블이 큰 경우는 문제가 되는 경우가 있다.

    • ColdFusion (Unix 위)

      이하의 정보는 ColdFusion 의 메뉴얼로부터의 발췌이다.

      이하의 정보를 사용하고,MySQL 데이터 소스에 대해서 MyODBC (와)과 함께 unixODBC 드라이버를 사용하도록(듯이) ColdFusion Server for Linux (을)를 설정한다.Allaire (은)는,MyODBC 버젼 2.50.26 하지만 MySQL 버젼 3.22.27 및 ColdFusion for Linux (와)과 제휴해 동작하는 것을 확인이 끝난 상태이다(그것이?~ 의 버젼도 당연히 동작한다).MyODBC (은)는,http://www.mysql.com/downloads/api-myodbc.html (으)로부터 다운로드할 수 있다.

      ColdFusion 버젼 4.5.1 (을)를 사용하면,ColdFusion Administrator (을)를 사용해 MySQL 데이터 소스를 추가할 수 있다.다만,ColdFusion 버젼 4.5.1 에는 드라이버는 부속되지 않았다.MySQL 드라이버가 ODBC 데이터 소스의 드롭 다운 리스트에 표시되도록(듯이) 하려면 ,MyODBC 드라이버를 빌드 하고,/opt/coldfusion/lib/libmyodbc.so 에 카피할 필요가 있다.

      Contrib 디렉토리에는 mydsn-xxx.zip 하지만 있어, 이것을 사용해 ColuFusion 어플리케이션으로 MyODBC 드라이버의 DSN 레지스트리 파일을 빌드 및 삭제할 수 있다.

    • DataJunction

      DataJunction 그럼, export로 ENUM 하지만 출력되고,MySQL 그리고 트러블의 원인이 되므로, 대신에 VARCHAR (을)를 출력하도록(듯이) 설정을 변경할 필요가 있다.

    • Excel

      정상적으로 동작한다.이하에 힌트를 나타낸다.

      • 일자 데이터로 문제가 발생하는 경우,CONCAT() 함수를 사용해 일자 데이터를 문자열로서 선택한다.예를 들어, 이하와 같이 지정한다.

        SELECT CONCAT(rise_time), CONCAT(set_time)
    FROM sunrise_sunset;

        이 방법으로 문자열로서 취득한 값은,Excel97 그리고 올바르게 시각으로서 인식된다.

        이 예로 CONCAT() (을)를 사용한 것은,ODBC 에 컬럼이 `` 문자열형'' 이다고 생각하게 하기 때문에 있다.CONCAT() (을)를 사용하지 않으면ODBC (은)는 컬럼이 시각형인 것을 인식하지만,Excel (은)는 그것을 인식하지 않는다.

        주의: Excel (은)는 자동적으로 문자열을 시각 데이터로 변환하므로, 상기의 건은 Excel 의 버그이다.소스가 텍스트 파일이면, 이 자동변역은 매우 편리하지만, 소스가 컬럼마다의 데이터형을 올바르게 보고한다 ODBC 접속인 경우는 전혀 의미를 만들어내지 않는다.

    • Word

      MySQL (으)로부터 Word 또는 Excel 문서에 데이터를 취득하려면 ,MyODBC 드라이버 및 Microsoft Query 애드 인(Add In)를 사용할 필요가 있다.

      예를 들어, 데이타베이스에,2 개의 텍스트형 컬럼을 가지는 테이블이 있다고 한다.

      • mysql 클라이언트 커멘드 라인 툴을 사용해 레코드를 삽입한다.

      • ODBC 매니저를 사용하고, 상기의 데이타베이스에 대해서, 예를 들어 my 그렇다고 한다 DSN 파일을 작성한다.

      • Word (을)를 연다.

      • 신규 문서를 작성한다.

      • [Database] 툴바의 [Insert Database] (을)를 클릭한다.

      • [Get Data] (을)를 클릭한다.

      • [Get Data] 다이알로그 박스의 우측에 있다 [MS Query] (을)를 클릭한다.

      • [MS Query] 그리고 DSN 파일 my (을)를 사용해 새로운 데이터 소스를 작성한다.

      • 새로운 쿼리를 선택한다.

      • 취득하는 컬럼을 선택한다.

      • 필요하면 필터를 작성한다.

      • 필요하면 늘어놓아 바꾸어를 지정한다.

      • [Return Data to Microsoft Word] (을)를 선택한다.

      • [Finish] (을)를 클릭한다.

      • [Insert data] (을)를 클릭해 레코드를 선택한다.

      • [OK] (을)를 클릭한다.Word 문서에 선택한 레코드가 표시된다.

    • odbcadmin

      ODBC 의 테스트 프로그램.

    • Delphi

      BDE 버젼 3.2 이?~ (을)를 사용할 필요가 있다.MySQL 에 접속하는 경우, 옵션필드 Don't optimize column width (을)를 유효하게 한다.

      또,MyODBC 의 ODBC 엔트리 및 BDE 엔트리(BDE 엔트리는 Delphi Super Page 그리고 무료 공개되고 있다 BDE Alias Editor (을)를 필요로 한다)를 셋업 하는 편리한 Delphi 코드를 이하에 나타낸다(이것에 대해서는 Bryan Brunton <bryan@flesherfab.com> 에 감사한다).

      fReg:= TRegistry.Create;
  fReg.OpenKey('\Software\ODBC\ODBC.INI\DocumentsFab', True);
  fReg.WriteString('Database', 'Documents');
  fReg.WriteString('Description', ' ');
  fReg.WriteString('Driver', 'C:\WINNT\System32\myodbc.dll');
  fReg.WriteString('Flag', '1');
  fReg.WriteString('Password', '');
  fReg.WriteString('Port', ' ');
  fReg.WriteString('Server', 'xmark');
  fReg.WriteString('User', 'winuser');
  fReg.OpenKey('\Software\ODBC\ODBC.INI\ODBC Data Sources', True);
  fReg.WriteString('DocumentsFab', 'MySQL');
  fReg.CloseKey;
  fReg.Free;

  Memo1.Lines.Add('DATABASE NAME=');
  Memo1.Lines.Add('USER NAME=');
  Memo1.Lines.Add('ODBC DSN=DocumentsFab');
  Memo1.Lines.Add('OPEN MODE=READ/WRITE');
  Memo1.Lines.Add('BATCH COUNT=200');
  Memo1.Lines.Add('LANGDRIVER=');
  Memo1.Lines.Add('MAX ROWS=-1');
  Memo1.Lines.Add('SCHEMA CACHE DIR=');
  Memo1.Lines.Add('SCHEMA CACHE SIZE=8');
  Memo1.Lines.Add('SCHEMA CACHE TIME=-1');
  Memo1.Lines.Add('SQLPASSTHRU MODE=SHARED AUTOCOMMIT');
  Memo1.Lines.Add('SQLQRYMODE=');
  Memo1.Lines.Add('ENABLE SCHEMA CACHE=FALSE');
  Memo1.Lines.Add('ENABLE BCD=FALSE');
  Memo1.Lines.Add('ROWSET SIZE=20');
  Memo1.Lines.Add('BLOBS TO CACHE=64');
  Memo1.Lines.Add('BLOB SIZE=32');

  AliasEditor.Add('DocumentsFab','MySQL',Memo1.Lines);

    • C++ Builder

      BDE 버젼 3.0 (을)를 사용해 시험이 끝난 상태.유일한 기존의 문제는, 테이블 schema가 변경되었을 때에 쿼리의 필드가 갱신되지 않는 것이다.다만,BDE (은)는 인덱스의 PRIMARY 이외의 주키를 인식하지 않는다고 생각되지만, 이것은 지금까지 문제로는 되지 않았다.

    • Vision

      옵션 플래그 Return matching rows (을)를 사용할 필요가 있다.

    • Visual Basic

      테이블을 갱신할 수 있도록 하려면 , 테이블에 주키를 정의할 필요가 있다.

      Visual Basic (을)를 ADO (와)과 함께 사용했을 경우, 큰 사이즈의 정수를 처리할 수 없다.이것은,SHOW PROCESSLIST (와)과 같은 쿼리는 올바르게 동작하지 않는 것을 의미한다.이것을 해결하려면 ,ODBC 접속 문자열에 옵션 OPTION=16384 (을)를 설정하는지, 또는 MyODBC 접속 화면에서 Change BIGINT columns to INT (을)를 선택한다.경우에 따라서는,Return matching rows 도 선택할 필요가 있다.

    • VisualInterDev

      [Microsoft][ODBC Driver Manager] Driver does not support this parameter 그렇다고 하는 에러가 발생하는 경우, 결과 세트에 BIGINT 하지만 포함되어 있는 것이 원인일 가능성이 있다.MyODBC 접속 화면에서 Change BIGINT columns to INT (을)를 선택하면 해결할 가능성이 있다.

    • Visual Objects

      옵션 플래그 Don't optimize column widths (을)를 사용할 필요가 있다.

    11.2.6. ODBC 그리고 AUTO_INCREMENT 속성을 가지는 컬럼의 값을 취득하는 방법

    자주 있는 문제로서INSERT (을)를 실행했을 때에 자동 생성된다 ID 의 값을 어떻게 취득하는가 하는 문제가 있습니다.ODBC (을)를 사용하는 경우, 이하와 같은 스테이트먼트에 의해서, 자동 생성된다 ID (을)를 취득할 수 있습니다(auto 하 AUTO_INCREMENT 속성을 가지는 필드로 한다).

    INSERT INTO foo (auto,text) VALUES(NULL,'text');
SELECT LAST_INSERT_ID();

    자동 생성되었다 ID (을)를 다른 테이블에 삽입하는 것 뿐이라면, 이하와 같은 스테이트먼트를 실행합니다.

    INSERT INTO foo (auto,text) VALUES(NULL,'text');
INSERT INTO foo2 (id,text) VALUES(LAST_INSERT_ID(),'text');

    See 항11.1.12.3. 「마지막에 삽입한 레코드의 일의인 ID (은)는 어떻게 취득하는 것인가」 .

    일부의 ODBC 어플리케이션(적어도 Delphi 및 Access )에서는, 이하의 쿼리를 사용하고, 새롭게 삽입된 레코드를 검색할 수 있습니다.

    SELECT * FROM tbl_name WHERE auto IS NULL;

    11.2.7. MyODBC 에 관한 문제의 보고

    MyODBC (을)를 사용해 문제가 발생했을 경우, 우선 MyODBC 로그를 작성하는 것, 및 ODBC 매니저로부터 로그 파일(ODBCADMIN 그리고 요구하면 작성되는 로그)를 작성하는 것부터 시작합니다.

    MyODBC 로그를 취득하려면 , 이하의 순서에 따릅니다.

    1. myodbc.dll (이)가 아니고,myodbcd.dll (을)를 사용하고 있는 것을 확인한다.확인하는 가장 간단한 방법은,MyODBC 디스트리뷰션으로부터 myodbcd.dll (을)를 취득하고,C:\windows\system32 또는 C:\winnt\system32 에 있다고 생각된다 myodbc.dll 에 덧쓰기로 카피하는 것이다.

      주의: 원래의 myodbc.dll 하 myodbcd.dll 보다 아득하게 고속의의로, 시험이 끝나면 원의 myodbc.dll 에 되돌리는 것이 바람직하다.

    2. MyODBC 접속 화면 또는 설정 화면에서 옵션 플래그 `Trace MyODBC' (을)를 유효하게 한다.로그가 C:\myodbc.log 파일에 써진다.

      상기의 화면을 재표시하면 트레이스 옵션이 무효가 되어 버리는 경우는,myodbcd.dll 드라이버가 사용되어 있지 않은 것을 의미한다(상기의 항목 참조).

    3. 어플리케이션을 기동하고, 이상종료(ABEND) 시킨다.

    MyODBC trace file (을)를 조사하고, 이상하다고 생각되는 부분을 찾습니다.myodbc.log 파일로 문자열 >mysql_real_query (을)를 검색하면, 쿼리를 발행한 부분이 발견됩니다.

    또,mysql 모니터 또는 admndemo 그리고 쿼리를 중복 해 실행해, 에러가 MyODBC 그리고 발생하고 있는지,MySQL 그리고 발생하고 있는지를 조사할 필요가 있습니다.

    이상하다고 생각되는 부분이 발견되었을 경우, 관련하는 행만(최대 40 행)을 myodbc 메일링 리스트에 투고해 주세요.See 항1.7.1.1. 「MySQL 메일링 리스트」 . 결코 MyODBC 로그 파일이나 ODBC 로그 파일을 통째로 투고하지 말아 주세요.

    이상하다고 생각되는 부분이 발견되지 않았던 경우, 마지막 수단으로서MyODBC 트레이스 파일,ODBC 로그 파일, 및 문제점을 설명한다 README 파일을 포함한 어카이브(archive)(tar 또는 zip )(을)를 작성합니다.이 어카이브(archive)를 ftp://support.mysql.com/pub/mysql/secret/ 에 업 로드합니다.이 파일에는 MySQL AB 의 담당자만을 액세스 할 수 있습니다.또, 담당자와 이러한 데이터는 완전하게 분리되어 있습니다.

    이 문제가 발생하는 프로그램을 그 밖에도 작성할 수 있는 경우는, 그것도 업 로드해 주세요.

    같은 프로그램을 다른 SQL 서버에 대해서 실행하면 정상적으로 동작하는 경우는, 그 때의 ODBC 로그 파일을 작성해 주세요.

    제공해 주실 수 있는 정보가 많은 만큼, 그 문제를 해결할 수 있을 가능성도 높아지기 때문에, 가능한 한 많은 정보를 제공해 주세요.


11.3. MySQL 의 Java 접속(JDBC )

MySQL 그럼 2 개의 JDBC 드라이버를 서포트하고 있습니다.

  • MySQL AB 제의 MySQL Connector/J .완전하게 네이티브인 Java 그리고 실장되고 있다.이 제품은, 이전에는 mm.mysql 드라이버로서 알려져 있었다.MySQL Connector/J (은)는,http://www.mysql.com/products/connector-j/ (으)로부터 다운로드할 수 있다.

  • Resin JDBC 드라이버.http://www.caucho.com/projects/jdbc-mysql/index.xtp (으)로부터 다운로드할 수 있다.

메뉴얼에 대해서는,JDBC 의 메뉴얼 및 MySQL 고유의 기능에 관한 각 드라이버의 메뉴얼을 참조해 주세요.


제11 장 MySQL API

목차

11.1. MySQL C API
11.1.1. C API 데이터형
11.1.2. C API 함수의 개요
11.1.3. C API 함수의 설명
11.1.4. C API 의 Prepared Statements
11.1.5. C API 의 Prepared Statement의 데이터형
11.1.6. C API 의 Prepared Statement 함수의 개요
11.1.7. C API 의 Prepared Statement 함수의 설명
11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급
11.1.9. C API 에 있어서의 일자치 및 시각치의 취급
11.1.10. C API 스레드 함수의 설명
11.1.11. C API 편입 서버 함수의 설명
11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제
11.1.13. 클라이언트 프로그램의 빌드
11.1.14. 스레드 클라이언트의 작성 방법
11.1.15. 편입 MySQL 서버 라이브러리 libmysqld
11.2. MySQL 의 ODBC 서포트
11.2.1. MyODBC 의 인스톨 방법
11.2.2. ODBC 아드?~ 니스트레이타의 필드의 설정 방법법
11.2.3. MyODBC 의 접속 파라미터
11.2.4. MyODBC 에 관한 문제를 보고하는 방법
11.2.5. MyODBC (와)과 제휴해 동작하는 것이 알려져 있는 프로그램
11.2.6. ODBC 그리고 AUTO_INCREMENT 속성을 가지는 컬럼의 값을 취득하는 방법
11.2.7. MyODBC 에 관한 문제의 보고
11.3. MySQL 의 Java 접속(JDBC )
11.4. MySQL PHP API
11.4.1. MySQL 및 PHP (이)가 좋게 있는 문제
11.5. MySQL Perl API
11.5.1. DBI (와)과 DBD::mysql
11.5.2. DBI 인터페이스
11.5.3. DBI/DBD 에 관한 그 외의 정보
11.6. MySQL C++ API
11.6.1. Borland C++
11.7. MySQL Python API
11.8. MySQL Tcl API
11.9. MySQL Eiffel Wrapper

이 장에서는,MySQL 그리고 사용할 수 있다 API 의 입수 장소 및 사용 방법에 대해 설명합니다.가장 풍부한 종류가 준비되어 있는 것이 C API 입니다.이것은 MySQL 팀이 개발하고 있습니다.발설어 전용의 API (은)는, 이 C API (을)를 베이스로 해 개발되고 있습니다.

11.1. MySQL C API

C API 코드는,MySQL (와)과 함께 배포되고 있습니다.C API 코드는 mysqlclient 라이브러리에 격납되어C 프로그램은 이 코드를 사용해 데이타베이스에 액세스 할 수 있습니다.

MySQL 의 소스 디스트리뷰션에 포함되는 클라이언트의 상당수는 C 그리고 기술되고 있습니다.C API 의 사용 방법을 알 수 있는 코드예를 찾고 있는 경우는, 이러한 클라이언트를 참고로 해 주세요.클라이언트는,MySQL 소스 디스트리뷰션의 clients 디렉토리에 격납되고 있습니다.

다른 클라이언트 API (Connector/J (을)를 제외하는 모든 API )의 상당수는,mysqlclient 라이브러리를 사용해 MySQL 서버와 통신합니다.이 라이브러리를 사용하면, 예를 들어 환경 변수를 참조할 수 있으므로, 다른 클라이언트 프로그램과 대부분의 환경 변수를 공용할 수 있게 됩니다.공용할 수 있는 환경 변수의 일람에 대해서는, 항4.9. 「MySQL 클라이언트 사이드의 스크립트와 유틸리티」 (을)를 참조해 주세요.

클라이언트를 사용할 수 있는 통신 버퍼 사이즈에는 상한이 있습니다.내부적으로 할당할 수 있고 있는 버퍼 사이즈(16 킬로바이트)는, 최대 16 메가바이트까지 자동적으로 증가합니다.버퍼 사이즈가 증가하는 것은 버퍼의 요구량이 증가했을 경우 뿐이어서, 디폴트의 최대치를 늘렸다고 사용 자원이 증가하는 것은 아닙니다.이 사이즈 체크에서는, 잘못된 쿼리나 통신 패킷을 주로 체크합니다.

통신 버퍼 사이즈는,SQL 스테이트먼트 1 개(클라이언트로부터 서버에의 트래픽) 및 결과 데이터 1 행(서버로부터 클라이언트에의 트래픽)을 격납 가능한 한의 크기가 필요합니다.각 스레드의 통신 버퍼는, 쿼리나 레코드를 처리할 수 있도록, 그 최대치까지 동적으로 확대됩니다.예를 들어, 최대 16 메가바이트의 데이터를 격납한다 BLOB 값을 처리하는 경우, 통신 버퍼 사이즈의 최대치는(서버와 클라이언트의 양쪽 모두로) 적어도 16 메가바이트일 필요가 있습니다.클라이언트의 디폴트의 최대치는 16 메가바이트입니다만, 서버의 디폴트의 최대치는 1 메가바이트입니다.서버의 디폴트의 최대치를 늘리려면 , 서버의 기동시에 max_allowed_packet 의 값을 변경합니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

MySQL 서버는, 쿼리가 끝날 때마다 통신 버퍼 사이즈를 net_buffer_length (으)로 줄입니다.클라이언트측에서는, 접속이 절단 되어 메모리가 해방될 때까지, 그 접속에 할당할 수 있었던 버퍼 사이즈가 줄어 들 것은 없습니다.

스레드를 사용하는 프로그라?~ 그에 대해서는, 항11.1.14. 「스레드 클라이언트의 작성 방법」 (을)를 참조해 주세요.동일 프로그램내에 " 서버" (와)과 " 클라이언트" 하지만 존재한다( 및 외부의 MySQL 서버와 통신하지 않는다) 스탠드얼론 어플리케이션의 작성에 대해서는, 항11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld 」 (을)를 참조해 주세요.

11.1.1. C API 데이터형

  • MYSQL

    이 구조체는,1 개의 데이타베이스 접속에의 핸들을 나타낸다.대부분의 MySQL 함수로 사용된다.

  • MYSQL_RES

    이 구조체는, 레코드를 돌려주는 쿼리(SELECT ,SHOW ,EXPLAIN ,DESCRIBE )의 결과를 나타낸다.이 섹션에서는, 쿼리로부터 돌려주어진 정보를 결과 세트 (이)라고 부른다.

  • MYSQL_ROW

    1 행의 데이터의 타입 세이프인 표현.현재는, 아르바이트 문자열의 배열로서 실장되고 있다(필드에는 바이너리 데이터가 격납되는 경우가 있어, 그러한 데이터에서는 내부적으로 누르바이트가 사용될 가능성이 있으므로, 아르바이트 문자열을 눌 종단 문자열로서 취급할 수 없다).레코드를 취득하려면 ,mysql_fetch_row() (을)를 호출한다.

  • MYSQL_FIELD

    이 구조체에는, 필드의 이름, 형태, 사이즈 등, 필드에 관한 정보가 격납된다.멤버의 상세한 것에 대하여는, 이하로 설명한다. 각 필드에 대해서 mysql_fetch_field() (을)를 반복해 호출하는 것에 의해서, 대응한다 MYSQL_FIELD 구조체를 취득할 수 있다.필드치는 이 구조체의 일부에서는 없고,MYSQL_ROW 구조체에 포함된다.

  • MYSQL_FIELD_OFFSET

    MySQL 필드 일람에 대한 오프셋의 안전한 형태 표현(mysql_field_seek() 하지만 사용).오프셋은 레코드 내부에서의 필드 번호이며,0 (으)로부터 시작된다.

  • my_ulonglong

    레코드의 수를 나타내기 위한 형태이며,mysql_affected_rows() ,mysql_num_rows() , 및 mysql_insert_id() 그리고 사용된다.0 (으)로부터 1.84e19 까지의 범위의 값을 나타낸다.

    일부의 시스템에서는,my_ulonglong 형태의 값을 출력하려고 해도, 정상적으로 출력되지 않는다.이 형태의 값을 출력하려면 ,unsigned long (으)로 변환하고,%lu 포맷을 사용한다.이하에 예를 나타낸다.

    printf ("Number of rows: %lu\n", (unsigned long) mysql_num_rows(result));

MYSQL_FIELD 구조체의 멤버를 이하에 나타냅니다.

  • char * name

    필드의 이름.눌 종단 문자열.

  • char * table

    이 필드가 계산 결과 데이터의 필드가 아닌 경우, 이 필드가 속하는 테이블의 이름.계산 결과 데이터의 필드의 경우,table 의 값은 공문자열이 된다.

  • char * def

    이 필드의 디폴트치.눌 종단 문자열.mysql_list_fields() (을)를 사용할 때만 설정된다.

  • enum enum_field_types type

    필드의 형태. type 의 값은 다음의 어느 쪽인가에 된다.

    형태의 값 | 형태의 설명
    FIELD_TYPE_TINY | TINYINT 필드
    FIELD_TYPE_SHORT | SMALLINT 필드
    FIELD_TYPE_LONG | INTEGER 필드
    FIELD_TYPE_INT24 | MEDIUMINT 필드
    FIELD_TYPE_LONGLONG | BIGINT 필드
    FIELD_TYPE_DECIMAL | DECIMAL 또는 NUMERIC 필드
    FIELD_TYPE_FLOAT | FLOAT 필드
    FIELD_TYPE_DOUBLE | DOUBLE 또는 REAL 필드
    FIELD_TYPE_TIMESTAMP | TIMESTAMP 필드
    FIELD_TYPE_DATE | DATE 필드
    FIELD_TYPE_TIME | TIME 필드
    FIELD_TYPE_DATETIME | DATETIME 필드
    FIELD_TYPE_YEAR | YEAR 필드
    FIELD_TYPE_STRING | CHAR 필드
    FIELD_TYPE_VAR_STRING | VARCHAR 필드
    FIELD_TYPE_BLOB | BLOB 또는 TEXT 필드(max_length (을)를 사용해 최대장을 결정)
    FIELD_TYPE_SET | SET 필드
    FIELD_TYPE_ENUM | ENUM 필드
    FIELD_TYPE_NULL | NULL 형태 필드
    FIELD_TYPE_CHAR | 폐?~ (대신에 FIELD_TYPE_TINY (을)를 사용하는 것)

    IS_NUM() 매크로를 사용하면, 필드가 수치형인지 어떤지를 조사할 수 있다.type 의 값을 IS_NUM() 에 건네주면, 필드가 수치형의 경우는 TRUE (이)라고 평가된다.

    if (IS_NUM(field->type))
    printf("Field is numeric\n");

  • unsigned int length

    필드의 폭.테이블 정의로 지정된 값에 따른다.

  • unsigned int max_length

    결과 세트의 필드의 최대폭(결과 세트에 실제로 존재하는 레코드의 필드치의 최대장).mysql_store_result() 또는 mysql_list_fields() (을)를 사용했을 경우, 이 값은 필드의 최대장을 나타낸다.mysql_use_result() (을)를 사용했을 경우, 이 값은 0 (이)가 된다.

  • unsigned int flags

    필드의 다양한 상태를 나타내는 비트 플래그.flags 값은,0 또는 이하의 비트가 1 개이상 설정된 값이 된다.

    플래그의 값 | 플래그의 설명
    NOT_NULL_FLAG | NULL (을)를 설정할 수 없는 필드
    PRI_KEY_FLAG | 주키의 일부를 구성하는 필드
    UNIQUE_KEY_FLAG | 일의인 키의 일부를 구성하는 필드
    MULTIPLE_KEY_FLAG | 일의가 아닌 키의 일부를 구성하는 필드
    UNSIGNED_FLAG | UNSIGNED 속성을 가지는 필드
    ZEROFILL_FLAG | ZEROFILL 속성을 가지는 필드
    BINARY_FLAG | BINARY 속성을 가지는 필드
    AUTO_INCREMENT_FLAG | AUTO_INCREMENT 속성을 가지는 필드
    ENUM_FLAG | ENUM 형태의 필드(폐?~ )
    SET_FLAG | SET 형태의 필드(폐?~ )
    BLOB_FLAG | BLOB 형태 또는 TEXT 형태의 필드(폐?~ )
    TIMESTAMP_FLAG | TIMESTAMP 형태의 필드(폐?~ )

    BLOB_FLAG ,ENUM_FLAG ,SET_FLAG , 및 TIMESTAMP_FLAG 의 각 플래그는, 필드의 속성은 아니고 형태를 나타내고 있으므로, 폐?~ 되고 있다.대신에,field->type (을)를 FIELD_TYPE_BLOB ,FIELD_TYPE_ENUM ,FIELD_TYPE_SET , 또는 FIELD_TYPE_TIMESTAMP (와)과 비교하는 것이 바람직하다.

    다음에,flags 값의 전형적인 사용예를 나타낸다.

    if (field->flags & NOT_NULL_FLAG)
    printf("Field can't be null\n");

    이하의 매크로를 사용하면,flags 값을 조사해 불리언 값으로 결과를 얻을 수 있다.

    플래그 상태 | 설명
    IS_NOT_NULL(flags) | 이 필드가 NOT NULL (으)로서 정의되고 있는 경우는 True .
    IS_PRI_KEY(flags) | 이 필드가 주키의 경우는 True .
    IS_BLOB(flags) | 이 필드가 BLOB 또는 TEXT 의 경우는 True (폐?~ .대신에 field->type 에 의한 비교를 추천).

  • unsigned int decimals

    수치 필드의 소수부 자리수.

11.1.2. C API 함수의 개요

여기에서는,C API 그리고 제공되고 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이?~ 의 섹션으로 설명합니다. See 항11.1.3. 「C API 함수의 설명」 .

함수 | 설명
mysql_affected_rows() | 마지막에 실행되었다 UPDATE ,DELETE , 또는 INSERT 의 몇개의 쿼리에 의해서 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_change_user() | 오픈된 접속의 유저 및 데이타베이스를 변경한다.
mysql_character_set_name() | 접속의 디폴트의 캐릭터 세트의 이름을 돌려준다.
mysql_close() | 서버 접속을 절단 한다.
mysql_connect() | MySQL 서버에 접속한다.이 함수는 폐?~ 되고 있으므로, 대신에 mysql_real_connect() (을)를 사용하는 것.
mysql_create_db() | 데이타베이스를 작성한다.이 함수는 폐?~ 되고 있으므로, 대신에 SQL 커멘드 CREATE DATABASE (을)를 사용하는 것.
mysql_data_seek() | 쿼리 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_debug() | 지정된 문자열로 DBUG_PUSH (을)를 실행한다.
mysql_drop_db() | 데이타베이스를 파기한다.이 함수는 폐?~ 되고 있으므로, 대신에 SQL 커멘드 DROP DATABASE (을)를 사용하는 것.
mysql_dump_debug_info() | 디버그 정보를 로그에 쓰도록(듯이) 서버에 지시한다.
mysql_eof() | 결과 세트의 마지막 레코드가 읽혔는지를 판정한다. 이 함수는 폐?~ 되고 있어 대신에 mysql_errno() 또는 mysql_error() (을)를 사용할 수 있다.
mysql_errno() | 마지막에 불려 갔다 MySQL 함수의 에러 번호를 돌려준다.
mysql_error() | 마지막에 불려 갔다 MySQL 함수의 에러를 돌려준다.
mysql_escape_string() | 문자열에 포함되는 특수 문자를 이스케이프 하고,SQL 스테이트먼트로 사용할 수 있도록 한다.
mysql_fetch_field() | 테이블의 다음의 필드의 형태를 돌려준다.
mysql_fetch_field_direct() | 필드 번호로 지정된 테이블 필드의 형태를 돌려준다.
mysql_fetch_fields() | 모든 필드 구조체의 배열을 돌려준다.
mysql_fetch_lengths() | 현재의 레코드의 모든 컬럼에 대해 그 길이를 돌려준다.
mysql_fetch_row() | 결과 세트의 다음의 레코드를 취득한다.
mysql_field_seek() | 지정된 컬럼에 컬럼 커서를 이동한다.
mysql_field_count() | 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려준다.
mysql_field_tell() | 마지막에 실행되었다 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려준다.
mysql_free_result() | 결과 세트로 사용한 메모리를 해방한다.
mysql_get_client_info() | 클라이언트의 버젼 정보를 문자열로서 돌려준다.
mysql_get_client_version() | 클라이언트의 버젼 정보를 정수로서 돌려준다.
mysql_get_host_info() | 접속을 기술하는 문자열을 돌려준다.
mysql_get_server_version() | 서버의 버젼 번호를 정수로서 돌려준다(4.1 의 신기능).
mysql_get_proto_info() | 접속에 사용하고 있는 프로토콜의 버젼을 돌려준다.
mysql_get_server_info() | 서버의 버젼 번호를 돌려준다.
mysql_info() | 마지막에 실행된 쿼리에 관한 정보를 돌려준다.
mysql_init() | MYSQL 구조체를 취득 또는 초기화한다.
mysql_insert_id() | 전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려준다.
mysql_kill() | 지정된 스레드를 강제 종료한다.
mysql_list_dbs() | 단순한 정규 표현에 일치하는 데이타베이스명을 돌려준다.
mysql_list_fields() | 단순한 정규 표현에 일치하는 필드명을 돌려준다.
mysql_list_processes() | 현재의 서바스레드의 일람을 돌려준다.
mysql_list_tables() | 단순한 정규 표현에 일치하는 테이블명을 돌려준다.
mysql_num_fields() | 결과 세트의 컬럼수를 돌려준다.
mysql_num_rows() | 결과 세트의 레코드수를 돌려준다.
mysql_options() | mysql_connect() 의 접속 옵션을 설정한다.
mysql_ping() | 서버에의 접속이 정상적일지를 확인해, 필요하면 재접속한다.
mysql_query() | 눌 종단 문자열로서 지정되어 있다 SQL 쿼리를 실행한다.
mysql_real_connect() | MySQL 서버에 접속한다.
mysql_real_escape_string() | 접속의 현재의 캐릭터 세트를 고려하고, 문자열에 포함되는 특수 문자를 이스케이프 해,SQL 스테이트먼트로 사용할 수 있도록 한다.
mysql_real_query() | 아르바이트 문자열로서 지정되어 있다 SQL 쿼리를 실행한다.
mysql_reload() | 권한 테이블의 재독 봐 포함을 서버에 지시한다.
mysql_row_seek() | mysql_row_tell() (으)로부터 돌려주어진 값을 오프셋으로서 결과 세트내의 레코드에 시크 한다.
mysql_row_tell() | 레코드 커서의 위치를 돌려준다.
mysql_select_db() | 데이타베이스를 선택한다.
mysql_set_server_option() | 접속의 옵션(multi-statements 등)을 설정한다.
mysql_sqlstate() | 마지막에 발생한 에러의 SQLSTATE 에러 코드를 돌려준다.
mysql_shutdown() | 데이터 베이스 서버를 슛다운 한다.
mysql_stat() | 서버 스테이터스를 문자열로서 돌려준다.
mysql_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_thread_id() | 현재의 스레드 ID (을)를 돌려준다.
mysql_thread_safe() | 클라이언트가 스레드세이후로서 컴파일 되고 있는 경우는 1 (을)를 돌려준다.
mysql_use_result() | 레코드 단위의 결과 세트의 취득을 개시한다.
mysql_warning_count() | 전회 실행했다 SQL 스테이트먼트의 경고수를 돌려준다.
mysql_commit() | 트랜잭션(transaction)를 코?~ 트 한다(4.1 의 신기능).
mysql_rollback() | 트랜잭션(transaction)를 롤백(rollback) 한다(4.1 의 신기능).
mysql_autocommit() | 자동코?~ 트모드의 온/ 오프를 바꾼다(4.1 의 신기능).
mysql_more_results() | 아직 취득하고 있지 않는 결과 세트가 존재할지를 조사한다(4.1 의 신기능).
mysql_next_result() | 멀티 쿼리를 실행하고 있는 경우, 다음의 결과 세트를 취득해, 돌려준다(4.1 의 신기능).

서버에 접속하려면 ,mysql_init() (을)를 호출해 접속 핸들러를 초기화해, 다음에 그 핸들러( 및 호스트명, 유저명, 패스워드등의 그 외의 정보)를 파라미터로서 mysql_real_connect() (을)를 호출합니다.접속이 확립했을 때,mysql_real_connect() 에 의해서 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.접속이 필요없게 되면,mysql_close() (을)를 호출해 접속을 절단 합니다.

접속이 액티브한 경우, 클라이언트는 mysql_query() 또는 mysql_real_query() (을)를 사용해 서버에 SQL 쿼리를 송신할 수 있습니다.이 2 개의 차이는,mysql_query() (은)는 쿼리를 눌 종단 문자열로서mysql_real_query() (은)는 쿼리를 아르바이트 문자열로서 각각 받습니다.문자열에 바이너리 데이터가 포함되는(누르바이트가 포함될 가능성이 있다) 경우는,mysql_real_query() (을)를 사용할 필요가 있습니다.

비 SELECT 쿼리(예를 들어,INSERT ,UPDATE ,DELETE )(을)를 실행했을 경우, 변경된(영향을 받은) 레코드의 수를 알려면 ,mysql_affected_rows() (을)를 호출합니다.

SELECT 쿼리를 실행했을 경우, 선택된 레코드를 결과 세트로서 취득합니다(주의: SHOW ,DESCRIBE , 및 EXPLAIN (와)과 같이, 레코드를 돌려준다고 하는 점으로 SELECT (을)를 닮아 있는 스테이트먼트가 있어, 이것들은 SELECT 스테이트먼트와 같게 취급할 필요가 있습니다).

클라이언트가 결과 세트를 처리하는 방법은 2 개 있습니다.1 개는,mysql_store_result() (을)를 호출해 결과 세트 전체를 일괄해 취득하는 방법입니다.이 함수는, 쿼리로부터 돌려주어진 모든 레코드를 서버로부터 취득해, 클라이언트에 보존합니다.이제(벌써) 1 개는,mysql_use_result() (을)를 호출하고, 클라이언트가 레코드 단위로 결과 세트의 취득을 개시하는 방법입니다.이 함수는 결과 세트를 취득하는 처리의 초기화는 실시합니다만, 실제로는 서버로부터 레코드를 받고 있지 않습니다.

어느 쪽의 경우도, 레코드에 액세스 하려면 mysql_fetch_row() (을)를 호출합니다.mysql_store_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는, 벌써 서버로부터 취득되고 있는 레코드에 액세스 합니다.mysql_use_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는 실제로 서버로부터 레코드를 취득합니다.각 레코드의 데이터 사이즈는,mysql_fetch_lengths() (을)를 호출하는 것에 의해서 알 수 있습니다.

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출하고, 사용하고 있던 메모리를 해방합니다.

2 개의 취득 메카니즘은, 상황에 따라 구분하여 사용합니다.클라이언트 프로그램은, 필요에 따라서 가장 적절한 방법을 선택할 필요가 있습니다.실제로는,mysql_store_result() (을)를 다용하는 경향이 있습니다.

mysql_store_result() 의 장점은, 모든 레코드가 클라이언트에 취득이 끝난 상태이므로, 레코드에 차례차례 액세스 가능할 뿐만 아니라,mysql_data_seek() 또는 mysql_row_seek() (을)를 사용해 결과 세트내에서의 경향 레코드의 위치를 변경하는 것에 의해서, 결과 세트내를 전후로 이동할 수 있는 것입니다.결과 세트에 포함되는 레코드수를 알려면 ,mysql_num_rows() (을)를 호출합니다.한편, 결과 세트가 큰 경우의 mysql_store_result() 의 메모리 요건은 매우 어려운 경우가 있어, 메모리 부족이 발생할 가능성은 높아집니다.

mysql_use_result() 의 장점은, 한 번에 1 행의 레코드 밖에 보관 유지하지 않기 때문에, 클라이언트가 결과 세트로 사용하는 메모리가 적어도 되는 것입니다(또, 메모리 할당의 오버헤드가 적기 때문에 mysql_use_result() 의 실행 속도도 향상합니다).단점은, 서버를 구속하지 않게 각 레코드에 대한 처리를 단시간에 끝낼 필요가 있는 것, 결과 세트내의 레코드에 대한 랜덤 억세스 기능이 없는 것(차례차례 액세스만), 모든 레코드를 취득할 때까지 결과 세트에 포함되는 레코드수를 모르는 것입니다.게다가 찾고 있던 정보가 차례차례 액세스의 도중에 발견되었을 경우에서도, 끝까지 모든 레코드를 취득한다 필요가 있습니다 .

클라이언트는 API (을)를 사용하는 것으로, 쿼리가 SELECT 화도인가를 몰라도, 쿼리에 대해서 적절히 응답하는(필요에 따라서 레코드를 취득한다) 일이 생깁니다.그러기 위해서는,mysql_query() (또는 mysql_real_query() )(을)를 호출할 때마다 mysql_store_result() (을)를 호출합니다.이 호출이 정상 종료했을 경우, 쿼리는 SELECT (이었)였던 것으로 되고, 레코드를 읽어들일 수 있습니다.호출이 실패했을 경우,mysql_field_count() (을)를 호출하고, 이 결과가 쿼리의 결과로서 예상된 것이었다 화도인지를 판단합니다.mysql_field_count() 하지만 0 (을)를 돌려주었을 경우, 쿼리가 돌려준 데이터는 없고(INSERT ,UPDATE ,DELETE 등의 쿼리였던 일을 의미한다), 레코드를 돌려주는 쿼리는 아니었다고 판단됩니다.mysql_field_count() 하지만 0 이외의 값을 돌려주었을 경우, 레코드를 돌려주어야할 쿼리가 실행되었지만, 아무것도 돌려주지 않았다고 판단됩니다.이것은,SELECT 쿼리가 실패한 것을 의미합니다.여기에 나타낸 방법의 코딩예에 대해서는,mysql_field_count() 의 설명을 참조해 주세요.

mysql_store_result() 및 mysql_use_result() (은)는 어느쪽이나, 결과 세트를 구성하는 필드에 관한 정보(필드의 수, 이름, 형태등)를 취득합니다.레코드의 필드 정보로 차례차례 액세스 하려면 ,mysql_fetch_field() (을)를 반복해 호출하는지, 또는 레코드의 필드 번호를 지정해 mysql_fetch_field_direct() (을)를 호출합니다.현재의 필드 커서의 위치를 변경하려면 ,mysql_field_seek() (을)를 호출합니다.필드 커서의 위치를 변경하면, 그 후에 불려 갔다 mysql_fetch_field() 의 동작에 영향을 줍니다.mysql_fetch_fields() (을)를 호출하면, 모든 필드의 정보를 일괄해 취득할 수 있습니다.

에러를 검출해, 보고하는 경우,mysql_errno() 및 mysql_error() (을)를 사용해 에러 정보로 액세스 합니다.이 2 개의 함수는, 마지막에 불려 간, 성공 또는 실패의 가능성이 있는 함수의 에러 코드 또는 에러 메세지를 돌려줍니다.이 결과에 의해서, 에러가 발생한 타이?~ 그와 그 내용을 판단합니다.

11.1.3. C API 함수의 설명

여기의 설명속에서, 파라미터 또는 반환값에 NULL 하지만 사용되고 있는 경우, 이것은 C 언어에 있어서의 NULL (을)를 나타내고 있어MySQL 에 있어서의 NULL 값이 아닙니다.

값을 돌려주는 함수는, 일반적으로 포인터 또는 정수를 돌려줍니다.특히 지정되어 있지 않은 한, 포인터를 돌려주는 함수가 비 NULL 값을 돌려주었을 경우는 정상 종료를,NULL 값을 돌려주었을 경우는 에러를 나타냅니다.같이 정수를 돌려주는 함수가 0 (을)를 돌려주었을 경우는 정상 종료를,0 이외의 값을 돌려주었을 경우는 에러를 나타냅니다.주의: ``0 이외'' 그렇다고 하는 것에, 그 이상의 의미는 없습니다.함수 설명에 특히 기술이 없는 한,0 이외의 값에 대해서 비교 테스트는 필요 없습니다.

if (result)                   /* correct */
    ... error ...

if (result < 0)               /* incorrect */
    ... error ...

if (result == -1)             /* incorrect */
    ... error ...

함수가 돌려주는 에러에 대해서는, 함수 설명안의 「 에러 」서브 섹션을 참조해 주세요.발생한 에러를 조사하려면 ,mysql_errno() (을)를 호출합니다.mysql_error() (을)를 호출하면, 에러 내용의 문자열 표현을 취득할 수 있습니다.

11.1.3.1. mysql_affected_rows()

my_ulonglong mysql_affected_rows(MYSQL *mysql)

설명

마지막에 불려 갔다 UPDATE 에 의해서 변경된 레코드수, 마지막에 불려 갔다 DELETE 에 의해서 삭제된 레코드수, 또는 마지막에 불려 갔다 INSERT 에 의해서 삽입된 레코드수를 돌려줍니다.UPDATE ,DELETE , 또는 INSERT 의 몇개의 스테이트먼트에 대해 mysql_query() (을)를 호출한 후에, 이 함수를 호출합니다.SELECT 스테이트먼트의 경우,mysql_affected_rows() (을)를 호출하면,mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해서 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타내 보입니다.-1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_store_result() (을)를 호출하기 전에 mysql_affected_rows() 하지만 불려 간 것을 나타내 보입니다.

에러

없습니다.

례

mysql_query(&mysql,"UPDATE products SET cost=cost*1.25 WHERE group=10");
printf("%ld products updated",(long) mysql_affected_rows(&mysql));

mysqld 에 접속할 때에 플래그 CLIENT_FOUND_ROWS 하지만 지정되어 있는 경우,mysql_affected_rows() 하 UPDATE 스테이트먼트의 WHERE 마디에 일치하는 레코드수를 돌려줍니다.

주의: REPLACE 커멘드로 기존의 레코드가 새로운 레코드로 옮겨놓을 수 있었을 경우는 mysql_affected_rows() 하 2 (을)를 돌려줍니다.이것은, 레코드가 1 행 삽입된 다음에 중복 한 레코드가 삭제되었기 때문입니다.

11.1.3.2. mysql_change_user()

my_bool mysql_change_user(MYSQL *mysql, const char *user, const char *password, const char *db)

설명

유저를 변경해,db 그리고 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

이 함수는,MySQL 3.23.3 그리고 도입되었습니다.

mysql_change_user() (은)는, 지정한 유저가 인증되지 않는 경우, 또는 그 유저가 데이타베이스를 사용하는 권한을 가지지 않는 경우에, 실패합니다.이 경우, 유저 및 데이타베이스는 변경되지 않습니다.

디폴트 데이타베이스를 사용하지 않는 경우,db 파라미터를 NULL (으)로 설정합니다.

MySQL 4.0.6 이?~ , 이 커멘드는, 새로운 접속이 확립했을 경우는 항상, 임의의 액티브한 트랜잭션(transaction)의 ROLLBACK 의 실행, 모든 텐포라리테이불의 클로우즈, 락 된 모든 테이블의 언로크, 및 상태의 리셋트를 실시합니다.이 처리는, 유저가 변경되지 않았던 경우도 반드시 행해집니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

mysql_real_connect() 하지만 돌려주는 에러와 같다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • ER_UNKNOWN_COM_ERROR

    MySQL 서버로 이 커멘드가 실장되어 있지 않다(버젼이 낡다고 생각할 수 있다).

  • ER_ACCESS_DENIED_ERROR

    유저 또는 패스워드가 올바르지 않다.

  • ER_BAD_DB_ERROR

    데이타베이스가 존재하지 않는다.

  • ER_DBACCESS_DENIED_ERROR

    유저가 데이타베이스에의 액세스권을 가지고 있지 않다.

  • ER_WRONG_DB_NAME

    데이타베이스명이 너무 길다.

례

if (mysql_change_user(&mysql, "user", "password", "new_database"))
{
   fprintf(stderr, "Failed to change user.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.3. mysql_character_set_name()

const char *mysql_character_set_name(MYSQL *mysql)

설명

현재의 접속의 디폴트의 캐릭터 세트를 돌려줍니다.

반환값

디폴트의 캐릭터 세트.

에러

없습니다.

11.1.3.4. mysql_close()

void mysql_close(MYSQL *mysql)

설명

벌써 오픈되고 있는 접속을 클로우즈 합니다.mysql 그리고 나타나는 접속 핸들이 mysql_init() 또는 mysql_connect() 에 의해서 자동적으로 할당할 수 있었던 핸들이었던 경우는,mysql_close() 그리고 할당이 해제됩니다.

반환값

없습니다.

에러

없습니다.

11.1.3.5. mysql_connect()

MYSQL *mysql_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd)

설명

이 함수는 폐?~ 되고 있습니다.대신에 mysql_real_connect() (을)를 사용해 주세요.

mysql_connect() (은)는,host 위에서 실행하고 있다 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 의미는,mysql_real_connect() (으)로의 대응하는 파라미터와 같습니다만, 접속 파라미터에 NULL (을)를 건네줄 수 있다고 하는 차이가 있습니다.이 경우,C API (은)는 접속 구조체에 자동적으로 메모리를 할당합니다.이 메모리는 mysql_close() (을)를 호출하는 것에 의해서 해방됩니다.이 방법에는, 접속에 실패했을 때에 에러 메세지를 취득할 수 없다고 하는 단점이 있습니다(mysql_errno() 또는 mysql_error() (으)로부터 에러 정보를 취득하려면 유효한 MYSQL 포인터를 건네줄 필요가 있습니다).

반환값

mysql_real_connect() (와)과 같습니다.

에러

mysql_real_connect() (와)과 같습니다.

11.1.3.6. mysql_create_db()

int mysql_create_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름으로 데이타베이스를 작성합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 CREATE DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 작성되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_create_db(&mysql, "my_database"))
{
   fprintf(stderr, "Failed to create new database.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.7. mysql_data_seek()

void mysql_data_seek(MYSQL_RES *result, my_ulonglong offset)

설명

쿼리 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_data_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.3.8. mysql_debug()

void mysql_debug(const char *debug)

설명

지정된 문자열로 DBUG_PUSH (을)를 실행합니다.mysql_debug() (은)는,Fred Fish 디버그 라이브러리를 사용합니다.이 함수를 사용하려면 , 디버그를 서포트하기 위한 클라이언트 라이브러리를 컴파일 할 필요가 있습니다. See 항E.1. 「MySQL 서버의 디버그」 . See 항E.2. 「MySQL 클라이언트의 디버그」 .

반환값

없습니다.

에러

없습니다.

례

다음의 코드를 실행하면, 클라이언트 라이브러리에 의해서 클라이언트 머신의 /tmp/client.trace 에 트레이스 파일이 생성됩니다.

mysql_debug("d:t:O,/tmp/client.trace");

11.1.3.9. mysql_drop_db()

int mysql_drop_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름의 데이타베이스를 파기합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 DROP DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 파기되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_drop_db(&mysql, "my_database"))
  fprintf(stderr, "Failed to drop the database: Error: %s\n",
          mysql_error(&mysql));

11.1.3.10. mysql_dump_debug_info()

int mysql_dump_debug_info(MYSQL *mysql)

설명

디버그 정보를 로그에 쓰도록(듯이) 서버에 지시합니다.접속 유저가 SUPER 특권을 가지지 않는 경우는 정상적으로 동작하지 않습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.11. mysql_eof()

my_bool mysql_eof(MYSQL_RES *result)

설명

이 함수는 폐?~ 되고 있습니다.대신에 mysql_errno() 또는 mysql_error() (을)를 사용할 수 있습니다.

mysql_eof() (은)는, 결과 세트의 마지막 레코드가 읽혔는지를 판정합니다.

mysql_store_result() (을)를 호출해 결과 세트를 취득하는 경우, 클라이언트는 1 회의 동작으로 결과 세트 전체를 받습니다.이 경우,mysql_fetch_row() (을)를 호출해 반환값이 NULL 이면, 벌써 결과 세트의 마지막에 도달하고 있던 것을 알 수 있으므로,mysql_eof() (을)를 호출할 필요는 없습니다.mysql_store_result() (와)과 함께 사용하는 경우,mysql_eof() (은)는 항상 true (을)를 돌려줍니다.

한편,mysql_use_result() (을)를 사용해 결과 세트의 취득을 개시했을 경우는,mysql_fetch_row() (을)를 반복해 호출하는 것에 의해서 그 레코드를 1 행씩 서버로부터 취득합니다.이 순서를 실행하고 있는 도중에 접속에 이상이 발생하는 경우가 있으므로,mysql_fetch_row() (을)를 호출해 반환값이 NULL 에서 만나도, 그것이 반드시 결과 세트의 마지막에 정상적으로 도달한 것을 의미하는 것은 아닙니다.이 경우는,mysql_eof() (을)를 사용하는 것에 의해서, 어떤 상황인가를 판단할 수 있습니다.mysql_eof() (은)는, 결과 세트의 마지막에 도달하고 있었을 경우는 0 이외, 에러가 발생하고 있었을 경우는 0 (을)를 돌려줍니다.

mysql_eof() (은)는, 역사적으로는 표준의 MySQL 에러 함수이다 mysql_errno() 및 mysql_error() 의 전신입니다.이러한 에러 함수는 같은 정보를 돌려주므로, 벌써 폐?~ 되고 있다 mysql_eof() 보다 우선해 사용해 주세요(실제,mysql_eof() 하지만 돌려주는 것은 불리언 값만으로, 에러 함수는 에러 발생 이유를 나타내는 것보다 많은 정보를 돌려줍니다).

반환값

에러가 발생하고 있지 않는 경우는 0 .결과 세트의 마지막에 도달하고 있었을 경우는 0 이외.

에러

없습니다.

례

mysql_eof() 에는 다음과 같은 사용법을 생각할 수 있습니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(!mysql_eof(result))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

다만, 표준의 MySQL 에러 함수를 다음과 같이 사용하면, 같은 동작을 실현할 수 있습니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(mysql_errno(&mysql))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

11.1.3.12. mysql_errno()

unsigned int mysql_errno(MYSQL *mysql)

설명

mysql_errno() (은)는,mysql 그리고 지정되는 접속에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있다 API 함수의 에러 코드를 돌려줍니다.반환값이 0 의 경우, 에러는 발생하고 있지 않습니다.클라이언트의 에러 메세지 번호의 일람은,MySQL errmsg.h 헤더 파일에 기술되고 있습니다.서버의 에러 메세지 번호의 일람은,mysqld_error.h 에 기술되고 있습니다.MySQL 소스 디스트리뷰션에 포함되는 파일 Docs/mysqld_error.txt 에는, 모든 에러 메세지 및 에러 번호의 일람이 기술되고 있습니다.서버의 에러 코드의 일람은, 항12.1. 「돌려주어지는 에러」 에도 기재되어 있습니다.

주의: mysql_fetch_row() 등의 일부의 함수는, 성공했을 경우에 mysql_errno() (을)를 설정하지 않습니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_errno() (을)를 리셋트 한다고 생각해 주세요.

반환값

마지막에 불려 갔다 mysql_xxx 함수가 실패하고 있었을 경우는 그 에러 코드.0 (은)는 에러가 발생하지 않았던 것을 나타냅니다.

에러

없습니다.

11.1.3.13. mysql_error()

const char *mysql_error(MYSQL *mysql)

설명

mysql_error() (은)는,mysql 그리고 지정된 접속에 대해서, 마지막에 불려 갔다 API 함수가 실패했을 때의 에러 메세지를 눌 종단 문자열로서 돌려줍니다.함수가 실패하지 않았던 경우,mysql_error() 의 반환값은 그 전의 에러 메세지인가, 에러가 전혀 발생하고 있지 않는 경우는 공문자열이 됩니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_error() (을)를 리셋트 한다고 생각해 주세요.

mysql_errno (을)를 리셋트 하는 함수에서는, 다음의 2 개의 비교는 동등합니다.

if(mysql_errno(&mysql))
{
    // an error occurred
}

if(mysql_error(&mysql)[0] != '\0')
{
    // an error occurred
}

클라이언트의 에러 메세지의 언어는,MySQL 클라이언트 라이브러리를 재컴파일 하는 것에 의해서 변경할 수 있습니다.현재는, 복수가 다른 언어로 에러 메세지를 돌려줄 수 있습니다. See 항4.7.2. 「영어 이외의 에러 메세지」 .

반환값

에러의 내용을 설명하는 눌 종단 문자열.에러가 발생하고 있지 않는 경우는 공문자열.

에러

없습니다.

11.1.3.14. mysql_escape_string()

이 함수 대신에 mysql_real_escape_string() (을)를 사용해 주세요.

mysql_real_escape_string() (은)는 선두의 인수로서 접속 핸들러를 받아, 현재의 캐릭터 세트에 따라서 문자열을 이스케이프 합니다만, 그 2 점을 제외하면, 이 함수와 mysql_real_escape_string() (은)는 같습니다.mysql_escape_string() (은)는 접속 핸들러를 인수로서 받지 않습니다.또, 현재의 캐릭터 세트는 참조하지 않습니다.

11.1.3.15. mysql_fetch_field()

MYSQL_FIELD *mysql_fetch_field(MYSQL_RES *result)

설명

결과 세트에 포함된다 1 살의 컬럼의 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.결과 세트에 포함되는 모든 컬럼의 정의를 취득하려면 , 이 함수를 반복해 호출합니다.정의를 취득하는 컬럼이 남지 않은 경우,mysql_fetch_field() 하 NULL (을)를 돌려줍니다.

새롭고 SELECT 쿼리를 실행할 때마다,mysql_fetch_field() (은)는 선두의 컬럼의 정의를 돌려주도록(듯이) 리셋트 됩니다.또,mysql_field_seek() (을)를 호출했을 경우도,mysql_fetch_field() 하지만 돌려주는 필드가 바뀝니다.

mysql_query() (을)를 호출해 테이블에 대해서 SELECT (을)를 실행한 후 mysql_store_result() (을)를 호출하지 않았던 경우,mysql_fetch_field() (을)를 호출해 BLOB 필드의 길이를 요구하면, 디폴트의 BLOB 장(8 킬로바이트)가 돌려주어집니다(MySQL 하 BLOB 의 최대장을 모르기 때문에 8 킬로바이트를 돌려줍니다.이 값은 장래 설정 가능한 값으로 할 필요가 있습니다).결과 세트를 취득한 다음은, 그 쿼리에 있어서의 이 컬럼의 최대치의 길이가 field->max_length 에게 건네집니다.

반환값

현재의 컬럼의 MYSQL_FIELD 구조체.컬럼이 남지 않은 경우는 NULL .

에러

없습니다.

례

MYSQL_FIELD *field;

while((field = mysql_fetch_field(result)))
{
    printf("field name %s\n", field->name);
}

11.1.3.16. mysql_fetch_fields()

MYSQL_FIELD *mysql_fetch_fields(MYSQL_RES *result)

설명

결과 세트의 모든 MYSQL_FIELD 구조체의 배열을 돌려줍니다.각 구조체에는, 결과 세트에 포함된다 1 살의 컬럼의 필드 정의가 격납되고 있습니다.

반환값

결과 세트에 포함되는 모든 컬럼의 MYSQL_FIELD 구조체의 배열.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *fields;

num_fields = mysql_num_fields(result);
fields = mysql_fetch_fields(result);
for(i = 0; i < num_fields; i++)
{
   printf("Field %u is %s\n", i, fields[i].name);
}

11.1.3.17. mysql_fetch_field_direct()

MYSQL_FIELD *mysql_fetch_field_direct(MYSQL_RES *result, unsigned int fieldnr)

설명

필드 번호 fieldnr 그리고 지정되는 결과 세트의 컬럼의 필드 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.이 함수를 사용하면, 임의의 컬럼의 정의를 취득할 수 있습니다.fieldnr 의 값은 0 (으)로부터 mysql_num_fields(result)-1 의 범위에서 지정합니다.

반환값

지정한 컬럼의 MYSQL_FIELD 구조체.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *field;

num_fields = mysql_num_fields(result);
for(i = 0; i < num_fields; i++)
{
    field = mysql_fetch_field_direct(result, i);
    printf("Field %u is %s\n", i, field->name);
}

11.1.3.18. mysql_fetch_lengths()

unsigned long *mysql_fetch_lengths(MYSQL_RES *result)

설명

결과 세트내의 경향 레코드의 컬럼의 길이를 돌려줍니다.필드치를 카피하려고 하는 경우, 이 함수를 사용하면 strlen() (을)를 호출하지 않아도 길이를 취득할 수 있으므로 편리합니다.또, 결과 세트에 바이너리 데이터가 포함되어 있는 경우,strlen() (은)는 눌 문자가 포함되는 필드의 길이를 올바르게 돌려주지 않기 때문에, 이 함수를 사용해 데이터 사이즈를 조사한다 필요가 있습니다 .

하늘의 컬럼 및 NULL 값을 포함한 컬럼의 길이는 0 입니다.이 2 개를 구별하는 방법에 대해서는,mysql_fetch_row() 의 설명을 참조해 주세요.

반환값

각 컬럼의 사이즈(눌 종단 문자는 세지 않는다)를 나타낸다 unsigned long 정수의 배열.에러가 발생했을 경우는 NULL .

에러

mysql_fetch_lengths() (은)는 결과 세트의 경향 레코드에서만 유효합니다.mysql_fetch_row() (을)를 호출하기 전 또는 결과 세트의 모든 레코드를 취득한 다음에 불려 갔을 경우는 NULL (을)를 돌려줍니다.

례

MYSQL_ROW row;
unsigned long *lengths;
unsigned int num_fields;
unsigned int i;

row = mysql_fetch_row(result);
if (row)
{
    num_fields = mysql_num_fields(result);
    lengths = mysql_fetch_lengths(result);
    for(i = 0; i < num_fields; i++)
    {
         printf("Column %u is %lu bytes in length.\n", i, lengths[i]);
    }
}

11.1.3.19. mysql_fetch_row()

MYSQL_ROW mysql_fetch_row(MYSQL_RES *result)

설명

결과 세트의 다음의 레코드를 취득합니다.mysql_store_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않으면 NULL (을)를 돌려줍니다.mysql_use_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않은지, 또는 에러가 발생했을 때에 NULL (을)를 돌려줍니다.

레코드에 포함되는 값의 수는 mysql_num_fields(result) 에 의해서 취득합니다.mysql_fetch_row() (을)를 호출해 그 반환값이 row 에 격납되고 있는 경우, 값에의 포인터는 row[0] (으)로부터 row[mysql_num_fields(result)-1] (와)과 같이 나타내집니다.NULL 포인터는, 레코드의 값이 NULL 값인 것을 나타냅니다.

mysql_fetch_lengths() (을)를 호출하면, 레코드의 필드치의 길이를 취득할 수 있습니다.하늘의 필드 및 NULL (을)를 포함한 필드의 길이는 어느쪽이나 0 그렇지만, 그 필드의 포인터를 조사하는 것에 의해서 그 2 개를 구별할 수 있습니다.포인터가 NULL 의 경우, 필드의 값은 NULL 입니다.그 이외의 경우, 필드는 하늘입니다.

반환값

다음의 레코드의 MYSQL_ROW 구조체.취득하는 레코드가 남지 않은지, 에러가 발생했을 경우는 NULL .

에러

주의: mysql_fetch_row() (을)를 1 회 호출하고 나서, 다음에 호출할 때까지 에 에러가 리셋트 될 것은 없습니다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

MYSQL_ROW row;
unsigned int num_fields;
unsigned int i;

num_fields = mysql_num_fields(result);
while ((row = mysql_fetch_row(result)))
{
   unsigned long *lengths;
   lengths = mysql_fetch_lengths(result);
   for(i = 0; i < num_fields; i++)
   {
       printf("[%.*s] ", (int) lengths[i], row[i] ? row[i] : "NULL");
   }
   printf("\n");
}

11.1.3.20. mysql_field_count()

unsigned int mysql_field_count(MYSQL *mysql)

MySQL 3.22.24 보다 낡은 버젼을 사용하고 있는 경우, 이 함수 대신에 unsigned int mysql_num_fields(MYSQL *mysql) (을)를 사용해 주세요.

설명

현재의 접속으로 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려줍니다.

통상 이 함수는,mysql_store_result() 하지만 NULL (을)를 돌려주었을 때(결과 세트 포인터가 돌려주어지지 않았을 때)에 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해서,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해서, 클라이언트 프로그램은, 쿼리가 SELECT (또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql,query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if(mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
        else // mysql_store_result() should have returned data
        {
            fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
    }
}

mysql_field_count(&mysql) 의 호출 부분을 mysql_errno(&mysql) 에 옮겨놓는 방법도 있습니다.이 경우, 스테이트먼트가 SELECT (이었)였는지 아닌지는,mysql_field_count() 하지만 돌려주는 값으로부터 추측하는 것이 아니라,mysql_store_result() 하지만 돌려주는 에러를 직접 조사하고 판단합니다.

11.1.3.21. mysql_field_seek()

MYSQL_FIELD_OFFSET mysql_field_seek(MYSQL_RES *result, MYSQL_FIELD_OFFSET offset)

설명

필드 커서의 위치를 지정된 오프셋으로 설정합니다.다음에 mysql_fetch_field() (을)를 호출하면, 그 오프셋에 관련지을 수 있었던 컬럼의 필드 정의를 돌려줍니다.

레코드의 선두에 시크 하려면 ,offset 값에 0 (을)를 건네줍니다.

반환값

시크 하기 전의 필드 커서의 값.

에러

없습니다.

11.1.3.22. mysql_field_tell()

MYSQL_FIELD_OFFSET mysql_field_tell(MYSQL_RES *result)

설명

마지막에 실행되었다 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려줍니다.이 반환값을,mysql_field_seek() 에 인수로서 건네줄 수 있습니다.

반환값

필드 커서의 현재의 오프셋.

에러

없습니다.

11.1.3.23. mysql_free_result()

void mysql_free_result(MYSQL_RES *result)

설명

          mysql_store_result()
,mysql_use_result()
,mysql_list_dbs()

등이 결과 세트에 할당한 메모리를 해방합니다.결과 세트가 필요없게 되면,mysql_free_result()

(을)를 호출하고, 사용하고 있던 메모리를 해방합니다.

반환값

없습니다.

에러

없습니다.

11.1.3.24. mysql_get_client_info()

char *mysql_get_client_info(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 문자열을 돌려줍니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 문자열.

에러

없습니다.

11.1.3.25. mysql_get_client_version()

unsigned long mysql_get_client_version(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 정수를 돌려줍니다.이 값은 XYYZZ 그렇다고 하는 형식에서 나타내져X (은)는 메이저 버젼,YY (은)는 릴리스 레벨,ZZ (은)는 릴리스 레벨내의 버젼 번호입니다.예를 들어,40102 (은)는, 클라이언트의 라이브러리 버젼이 4.1.2 인 것을 나타냅니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 정수.

에러

없습니다.

11.1.3.26. mysql_get_host_info()

char *mysql_get_host_info(MYSQL *mysql)

설명

사용하고 있는 접속의 타입을 나타내는 문자열을 돌려줍니다.이 문자열에는 서버의 호스트명도 포함됩니다.

반환값

서버의 호스트명 및 접속 타입을 나타내는 문자열.

에러

없습니다.

11.1.3.27. mysql_get_proto_info()

unsigned int mysql_get_proto_info(MYSQL *mysql)

설명

현재의 접속에 사용하고 있는 프로토콜의 버젼을 돌려줍니다.

반환값

현재의 접속에 사용하고 있는 프로토콜의 버젼을 나타낸다 unsigned 정수.

에러

없습니다.

11.1.3.28. mysql_get_server_info()

char *mysql_get_server_info(MYSQL *mysql)

설명

서버의 버젼 번호를 나타내는 문자열을 돌려줍니다.

반환값

서버의 버젼 번호를 나타내는 문자열.

에러

없습니다.

11.1.3.29. mysql_get_server_version()

unsigned long mysql_get_server_version(MYSQL *mysql)

설명

서버의 버젼 번호를 정수로서 돌려줍니다(4.1 의 신기능).

반환값

MySQL 서버의 버젼을 다음의 형식에서 나타내는 번호.

main_version*10000 + minor_version *100 + sub_version

예를 들어, 버젼이 4.1.0 의 경우, 반환값은 40100 입니다.

이 값을 사용하면, 클라이언트 프로그램은 서버의 버젼으로부터 특정의 기능이 존재할지를 간단하게 판단할 수 있습니다.

에러

없습니다.

11.1.3.30. mysql_info()

char *mysql_info(MYSQL *mysql)

설명

마지막에 실행한 쿼리에 관한 정보를 나타내는 문자열을 취득합니다.다만, 대상이 되는 것은, 이하의 일람에 포함되는 스테이트먼트만입니다.마지막에 실행한 것이 다른 스테이트먼트의 쿼리였던 경우는,mysql_info() 하 NULL (을)를 돌려줍니다.문자열의 형식은, 이하에 설명하도록(듯이), 쿼리의 타입에 따라서 다릅니다.숫자는 예로서 나타내 보인 것입니다.실제의 문자열에는 실행한 쿼리에 맞은 값이 사용됩니다.

  • INSERT INTO ...SELECT ...

    문자열의 형식: Records: 100 Duplicates: 0 Warnings: 0

  • INSERT INTO ...VALUES (...),(...),(...)...

    문자열의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • LOAD DATA INFILE ...

    문자열의 형식: Records: 1 Deleted: 0 Skipped: 0 Warnings: 0

  • ALTER TABLE

    문자열의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • UPDATE

    문자열의 형식: Rows matched: 40 Changed: 40 Warnings: 0

주의: mysql_info() (은)는,INSERT ... VALUES 스테이트먼트가 복수 레코드를 삽입하는 형식의 경우에 한정해(복수의 값리스트가 지정되었을 경우에 한정해),NULL 이외의 값을 돌려줍니다.

반환값

마지막에 실행한 쿼리에 관한 정보를 나타내는 문자열.쿼리의 정보가 없는 경우는 NULL .

에러

없습니다.

11.1.3.31. mysql_init()

MYSQL *mysql_init(MYSQL *mysql)

설명

mysql_real_connect() 에 적응한다 MYSQL 오브젝트를 할당해 또는 초기화합니다.mysql 에 NULL 포인터를 건네주었을 경우, 함수는 새로운 오브젝트에 메모리를 할당해 초기화해, 그것을 돌려줍니다.그 이외의 값을 건네주었을 경우는, 오브젝트를 초기화해, 그 주소를 돌려줍니다.mysql_init() 하지만 새로운 오브젝트에 메모리를 할당했을 경우, 그 메모리는 mysql_close() (을)를 호출해 접속을 클로우즈 할 때에 해방됩니다.

반환값

초기화되었다 MYSQL* 핸들.새로운 오브젝트에 할당하는 충분한 메모리가 없었던 경우는 NULL .

에러

메모리가 부족했을 경우는 NULL (을)를 돌려줍니다.

11.1.3.32. mysql_insert_id()

my_ulonglong mysql_insert_id(MYSQL *mysql)

설명

전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려줍니다.이 함수는,AUTO_INCREMENT 필드를 포함한 테이블에 대해서 INSERT 쿼리를 실행한 다음에 사용합니다.

주의: mysql_insert_id() (은)는, 전회 실행된 쿼리로 AUTO_INCREMENT 값이 생성되지 않았던 경우는,0 (을)를 돌려줍니다.장래를 위해서 그 값을 보존할 필요가 있는 경우는, 그것을 생성하는 쿼리의 직후에 mysql_insert_id() (을)를 호출할 필요가 있습니다.

전회 실행된 쿼리가 에러를 돌려주었을 경우에 대해서는,mysql_insert_id() 의 값은 미정도리입니다.

mysql_insert_id() (은)는,AUTO_INCREMENT 값을 생성하는지, 또는 컬럼치를 LAST_INSERT_ID(expr) (으)로 설정한다 INSERT 스테이트먼트 및 UPDATE 스테이트먼트의 실행 후에 갱신됩니다. See 항6.3.6.2. 「그 외의 각종 함수」 .

주의: SQL LAST_INSERT_ID() 함수의 값에는, 반드시 마지막에 생성되었다 AUTO_INCREMENT 값이 포함됩니다.이 값은 서버에 보관 유지되므로, 어느 쿼리를 실행하고 나서 다음의 쿼리를 실행할 때까지 에 리셋트 될 것은 없습니다.

반환값

전회 실행된 쿼리에 의해서 갱신되었다 AUTO_INCREMENT 필드의 값.현재의 접속으로 아직 1 회도 쿼리가 실행되어 있지 않았던 경우, 또는 전회 실행된 쿼리로 AUTO_INCREMENT 값이 갱신되지 않았던 경우,0 (을)를 돌려줍니다.

에러

없습니다.

11.1.3.33. mysql_kill()

int mysql_kill(MYSQL *mysql, unsigned long pid)

설명

pid 그리고 지정하는 스레드를 강제 종료하도록(듯이), 서버에 요구합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.34. mysql_list_dbs()

MYSQL_RES *mysql_list_dbs(MYSQL *mysql, const char *wild)

설명

서버상의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 데이타베이스명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 데이타베이스명이 일치합니다.mysql_list_dbs() (을)를 호출하면, 쿼리 SHOW databases [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.35. mysql_list_fields()

MYSQL_RES *mysql_list_fields(MYSQL *mysql, const char *table, const char *wild)

설명

지정된 테이블의 필드로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 필드명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 필드명이 일치합니다.mysql_list_fields() (을)를 호출하면, 쿼리 SHOW COLUMNS FROM tbl_name [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

주의: mysql_list_fields() 대신에 SHOW COLUMNS FROM tbl_name (을)를 사용하는 것을 추천 합니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.36. mysql_list_processes()

MYSQL_RES *mysql_list_processes(MYSQL *mysql)

설명

현재의 서바스레드의 일람을 나타내는 결과 세트를 돌려줍니다.이것은,mysqladmin processlist 또는 SHOW PROCESSLIST 쿼리가 돌려주는 정보와 같은 타입의 정보입니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.37. mysql_list_tables()

MYSQL_RES *mysql_list_tables(MYSQL *mysql, const char *wild)

설명

현재의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 테이블명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 테이블명이 일치합니다.mysql_list_tables() (을)를 호출하면, 쿼리 SHOW tables [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.38. mysql_num_fields()

unsigned int mysql_num_fields(MYSQL_RES *result)

또는

unsigned int mysql_num_fields(MYSQL *mysql)

2 번째의 형식은,MySQL 3.22.24 이?~ 그럼 동작하지 않습니다.MYSQL* 인수를 건네주려면 , 이 함수 대신에 unsigned int mysql_field_count(MYSQL *mysql) (을)를 사용할 필요가 있습니다.

설명

결과 세트의 컬럼수를 돌려줍니다.

주의: 결과 세트에의 포인터 또는 접속 핸들에의 포인터의 어느 쪽을 사용해도, 컬럼수를 취득할 수 있습니다.mysql_store_result() 또는 mysql_use_result() 하지만 NULL (을)를 돌려주었을 경우(결과 세트 포인터가 돌려주어지지 않았던 경우)는, 접속 핸들을 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해서,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해서, 클라이언트 프로그램은, 쿼리가 SELECT (또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql,query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if (mysql_errno(&mysql))
        {
           fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
        else if (mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
    }
}

(쿼리가 결과 세트를 돌려주는 것을 알 수 있고 있는 경우)mysql_errno(&mysql) (을)를 호출하는 대신에 mysql_field_count(&mysql) 하지만 0 (을)를 돌려줄지를 조사하는 방법도 있습니다.이것은,0 (을)를 돌려주는 것은, 어떠한 이상이 발생했을 경우만이기 때문입니다.

11.1.3.39. mysql_num_rows()

my_ulonglong mysql_num_rows(MYSQL_RES *result)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_num_rows() 의 사용법은,mysql_store_result() (와)과 mysql_use_result() 의 어느 쪽을 사용해 결과 세트를 취득할까에 의해서 정해집니다.mysql_store_result() (을)를 사용하는 경우, 곧바로 mysql_num_rows() (을)를 호출할 수 있습니다.mysql_use_result() (을)를 사용하는 경우, 결과 세트에 포함되는 모든 레코드를 취득할 때까지는,mysql_num_rows() (은)는 올바른 값을 돌려주지 않습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.3.40. mysql_options()

int mysql_options(MYSQL *mysql, enum mysql_option option, const char *arg)

설명

이 함수를 사용하고, 접속 옵션을 추가 설정해, 접속의 동작을 바꿀 수 있습니다.이 함수를 여러 차례 호출하는 것으로, 복수의 옵션을 설정할 수 있습니다.

mysql_options() (은)는,mysql_init() (을)를 실행하고 나서 mysql_connect() 또는 mysql_real_connect() (을)를 호출할 때까지 에 호출할 필요가 있습니다.

option 인수는, 설정하는 옵션입니다.arg 인수는 그 옵션으로 설정하는 값입니다.옵션이 정수의 경우,arg 에는 정수치에의 포인터를 건네줄 필요가 있습니다.

설정 가능한 옵션의 값을 다음에 나타냅니다.

옵션 | 인수의 형태 | 기능
MYSQL_OPT_CONNECT_TIMEOUT | unsigned int * | 접속의 타임 아웃 시간(초단위).
MYSQL_OPT_READ_TIMEOUT | unsigned int * | 서버로부터의 읽기 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_WRITE_TIMEOUT | unsigned int * | 서버에의 써 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_COMPRESS | 미사용 | 압축된 클라이언트/ 서버 프로토콜을 사용.
MYSQL_OPT_LOCAL_INFILE | unsigned int 에의 생략 가능한 포인터 | 포인터가 지정되지 않는지, 또는 0 (은)는 아니다 unsigned int 에의 포인터가 지정되었을 경우, 커멘드 LOAD LOCAL INFILE (은)는 유효.
MYSQL_OPT_NAMED_PIPE | 미사용 | 이름 파이프를 사용해 NT 위에서 동작한다 MySQL 서버에 접속.
MYSQL_INIT_COMMAND | char * | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
MYSQL_READ_DEFAULT_FILE | char * | my.cnf (이)가 아니고, 지정된 옵션 설정 파일로부터 옵션을 읽어들인다.
MYSQL_READ_DEFAULT_GROUP | char * | my.cnf 의 지정된 그룹 또는 MYSQL_READ_DEFAULT_FILE 그리고 지정된 파일로부터 옵션을 읽어들인다.
MYSQL_OPT_PROTOCOL | unsigned int * | 사용하는 프로토콜의 타입.mysql.h 그리고 정의되고 있다 mysql_protocol_type 의 열거치의 언젠가 1 개인 것.
MYSQL_SHARED_MEMORY_BASE_NAME | char* | 서버와의 통신에 사용하는 이름 공유 메모리오브제크트.접속 상대의 mysqld 서버가 사용하는 옵션 -shared-memory-base-name (와)과 같은 값을 지정할 필요가 있다.

주의: MYSQL_READ_DEFAULT_FILE 또는 MYSQL_READ_DEFAULT_GROUP (을)를 사용하는 경우는, 그룹 client 하지만 항상 읽힙니다.

옵션 설정 파일의 지정된 그룹에는 이하의 옵션을 지정 가능합니다.

옵션 | 설명
connect-timeout | 접속의 타임 아웃 시간(초단위).Linux 그럼, 서버로부터 최초의 응답을 기다리는 경우에도 이 타임 아웃 시간을 사용한다.
compress | 압축된 클라이언트/ 서버 프로토콜을 사용.
database | 접속 커멘드로 데이타베이스가 지정되지 않았던 경우에 접속하는 데이타베이스.
debug | 디버그 옵션.
disable-local-infile | LOAD DATA LOCAL 의 사용을 무효로 한다.
host | 디폴트의 호스트명.
init-command | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
interactive-timeout | mysql_real_connect() 그리고 CLIENT_INTERACTIVE (을)를 지정하는 것과 같다. See 항11.1.3.43. 「mysql_real_connect() 」 .
local-infile[=(0|1)] | 인수가 지정되지 않는지, 또는 0 이외의 인수가 지정되었을 경우에 LOAD DATA LOCAL 의 사용을 유효하게 한다.
max_allowed_packet | 클라이언트가 서버로부터 읽어들여 가능한 패킷의 최대 사이즈.
password | 디폴트의 패스워드.
pipe | 이름 파이프를 사용해 NT 위에서 동작한다 MySQL 서버에 접속.
protocol=(TCP | SOCKET | PIPE | MEMORY) | 서버에 접속할 경우에 사용하는 프로토콜을 선택(4.1 의 신기능).
port | 디폴트의 포토 번호.
return-found-rows | UPDATE (을)를 사용했을 때에 갱신된 레코드가 아니고, 검색 결과의 레코드를 돌려주도록(듯이),mysql_info() 에 지시한다.
shared-memory-base-name=name | 서버와의 접속에 사용하는 공유 메모리의 이름(디폴트는 "MySQL" ).MySQL 4.1 의 신기능.
socket | 디폴트의 소켓 번호.
user | 디폴트의 유저.

주의: timeout 대신에 connect-timeout 하지만 제공되고 있습니다만,timeout 도 당분간은 사용할 수 있습니다.

옵션 설정 파일의 상세한 것에 대하여는, 항4.1.2. 「my.cnf 옵션 설정 파일」 (을)를 참조해 주세요.

반환값

정상 종료했을 경우는 0 .불명한 옵션을 사용했을 경우는 0 이외.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql,MYSQL_OPT_COMPRESS,0);
mysql_options(&mysql,MYSQL_READ_DEFAULT_GROUP,"odbc");
if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는, 압축된 클라이언트/ 서버 프로토콜을 사용하는 것, 및 my.cnf 파일의 odbc 섹션의 옵션을 추가로 읽어들이는 것을, 클라이언트에 요구하고 있습니다.

11.1.3.41. mysql_ping()

int mysql_ping(MYSQL *mysql)

설명

서버에의 접속이 정상적일지를 확인합니다.절단 되고 있었을 경우는, 자동적으로 재접속을 시도합니다.

장시간에 걸쳐서 아이돌 상태였던 클라이언트는 이 함수를 사용하는 것에 의해서, 서버에 의해서 접속이 절단 되어 있지 않은지 어떤지를 조사하고, 필요하면 재접속할 수 있습니다.

반환값

서버와의 접속이 정상적인 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.42. mysql_query()

int mysql_query(MYSQL *mysql, const char *query)

설명

눌 종단 문자열 query 그리고 지정되었다 SQL 쿼리를 실행합니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

mysql_query() (은)는 바이너리 데이터를 포함한 쿼리를 취급할 수 없습니다.그러한 쿼리에서는 대신에 mysql_real_query() (을)를 사용할 필요가 있습니다(바이너리 데이터에는 '\0' 하지만 포함될 가능성이 있어,mysql_query() (은)는 그것을 쿼리 문자열의 마지막으로서 해석해 버리기 위해).

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

반환값

쿼리가 정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.43. mysql_real_connect()

MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned long client_flag)

설명

mysql_real_connect() (은)는,host 그리고 동작하고 있다 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_real_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 지정 방법을 다음에 나타냅니다.

  • 1 번째의 파라미터에는, 기존의 MYSQL 구조체의 주소를 지정한다.mysql_real_connect() (을)를 호출하기 전에,mysql_init() (을)를 호출해 MYSQL 구조체를 초기화할 필요가 있다.mysql_options() (을)를 사용하면, 다양한 접속 옵션을 변경할 수 있다. See 항11.1.3.40. 「mysql_options() 」 .

  • host 파라미터에는, 호스트명 또는 IP 주소의 어느 쪽인지를 지정한다.host 에 NULL 또는 문자열 "localhost" (을)를 지정했을 경우, 로컬 호스트에게 접속하는 것으로 간주해진다.OS 하지만 소켓(Unix ) 또는 이름 파이프(Windows )(을)를 서포트하고 있는 경우,TCP/IP 대신에 그것들을 사용해 서버에 접속한다.

  • user 파라미터에는 유저의 MySQL 로그인 ID (을)를 지정한다.user 에 NULL 또는 공문자열 "" (을)를 지정했을 경우, 현재의 유저를 사용하는 것으로 간주해진다.Unix 그럼 현재의 로그인명이 사용된다.Windows 그리고 ODBC (을)를 사용하는 경우는, 현재의 유저명을 명시적으로 지정할 필요가 있다. See 항11.2.2. 「ODBC 아드?~ 니스트레이타의 필드의 설정 방법법」 .

  • passwd 파라미터에는 user 의 패스워드를 지정한다.passwd 에 NULL (을)를 지정했을 경우,user 테이블의 엔트리의 패스워드 필드에 아무것도 지정되어 있지 않은(하늘이다) 유저만이 체크 대상이 된다.데이타베이스 관리자는, 이 기능을 사용하고, 패스워드를 지정해 있을지에 따라서 유저에게 다른 특권을 준다고 한다 MySQL 특권 시스템을 셋업 할 수 있다.

    주의: 패스워드의 암호화는 클라이언트 API 에 의해서 자동적으로 처리되므로,mysql_real_connect() (을)를 호출하기 전에 패스워드의 암호화는 불필요하다.

  • db 파라미터에는 데이타베이스명을 지정한다.db 하지만 NULL (이)가 아닌 경우, 이 값이 접속의 디폴트 데이타베이스로서 설정된다.

  • port 파라미터에 0 이외의 값을 지정했을 경우, 이 값이 TCP/IP 접속의 포토 번호로서 사용된다.주의: 접속의 타입은 host 파라미터에 의해서 결정된다.

  • unix_socket 파라미터에 NULL 이외의 값을 지정했을 경우, 이 문자열이 소켓 또는 이름 파이프에 사용된다.주의: 접속의 타입은 host 파라미터에 의해서 결정된다.

  • client_flag 파라미터에는 통상 0 (을)를 지정하지만, 지극히 특수한 상황에서는 이하에 나타내는 플래그를 조합해 지정할 수 있다.

    플래그명 | 플래그의 설명
    CLIENT_COMPRESS | 압축 프로토콜을 사용.
    CLIENT_FOUND_ROWS | 영향을 받은 레코드의 수가 아니고, 검색 결과의(일치한) 레코드의 수를 돌려준다.
    CLIENT_IGNORE_SPACE | 함수명의 말미의 공백을 무시한다.모든 함수명을 예약어(reserved word)로 한다.
    CLIENT_INTERACTIVE | 아이돌 상태가(wait_timeout 초는 아니고)interactive_timeout 초계속하면 접속을 클로우즈 한다.
    CLIENT_LOCAL_FILES | LOAD DATA LOCAL 의 처리를 유효하게 한다.
    CLIENT_MULTI_STATEMENTS | 클라이언트가 복수행 쿼리(‘; ＇ (을)를 스테이트먼트의 단락으로 한다)를 송신할 가능성이 있는 것을 서버에 통지한다.이 플래그가 설정되어 있지 않은 경우, 복수행 쿼리는 무효.MySQL 4.1 의 신기능.
    CLIENT_MULTI_RESULTS | 클라이언트가 복수 쿼리 또는 Stored Procedure에 의해서 취득한 복수의 결과 세트를 처리할 수 있는 것을 서버에 통지한다.CLIENT_MULTI_STATEMENTS 하지만 설정되어 있는 경우, 이 플래그는 자동적으로 설정된다.MySQL 4.1 의 신기능.
    CLIENT_NO_SCHEMA | db_name.tbl_name.col_name 그렇다고 하는 구문의 사용을 금?~ 한다.이것은 ODCB 향해의 구문이다.이 구문을 사용했을 경우, 파서로 에러가 발생한다.이 구문은 일부의 ODBC 프로그램으로 버그를 트랩 하기 위해서 사용한다.
    CLIENT_ODBC | 클라이언트가 ODBC 경유인 것을 통지한다.이 경우,mysqld 하 ODBC 클라이언트에 적절한 처리를 실시한다.
    CLIENT_SSL | SSL (암호화 프로토콜)(을)를 사용한다.응용 프로그램에서는 이 플래그를 설정하지 않는 것.이것은 클라이언트 라이브러리가 내부에서 설정하는 플래그이다.

반환값

접속이 정상적으로 확립했을 경우는 MYSQL* 접속 핸들.접속이 확립하지 않았던 경우는 NULL .접속이 확립했을 경우, 반환값은 1 번째의 파라미터의 값과 같습니다.

에러

  • CR_CONN_HOST_ERROR

    MySQL 서버에의 접속이 확립하지 않았다.

  • CR_CONNECTION_ERROR

    로컬의 MySQL 서버에의 접속이 확립하지 않았다.

  • CR_IPSOCK_ERROR

    IP 소켓의 작성에 실패했다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SOCKET_CREATE_ERROR

    Unix 소켓의 작성에 실패했다.

  • CR_UNKNOWN_HOST

    호스트명의 IP 주소가 발견되지 않았다.

  • CR_VERSION_ERROR

    서버에 접속할 때에, 다른 프로토콜 버젼의 클라이언트 라이브러리를 사용했기 때문에, 프로토콜의 불일치가 발생했다.이 에러는,--old-protocol 옵션을 지정하지 않고 기동한 새로운 버젼의 서버에, 매우 낡은 버젼의 클라이언트 라이브러리를 사용하고 접속을 시도했을 경우에 발생할 가능성이 있다.

  • CR_NAMEDPIPEOPEN_ERROR

    Windows 그리고 이름 파이프의 작성에 실패했다.

  • CR_NAMEDPIPEWAIT_ERROR

    Windows 그리고 이름 파이프의 대기에 실패했다.

  • CR_NAMEDPIPESETSTATE_ERROR

    Windows 그리고 파이프 핸들러의 취득에 실패했다.

  • CR_SERVER_LOST

    connect_timeout 하지만 정의 값이며,connect_timeout 초경과해도 서버에 접속할 수 없었다.또는 init-command 의 실행중에 서버가 다운했다.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql,MYSQL_READ_DEFAULT_GROUP,"your_prog_name");
if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는 mysql_options() (을)를 호출해 MySQL 라이브러리가 my.cnf 파일의 [client] 및 [your_prog_name] 섹션을 읽어들이도록(듯이) 설정해 있습니다.이와 같이 설정하는 것으로, 비표준적인 방법으로 셋업 되었다 MySQL 에 대해서도 이 프로그램이 정상적으로 동작하는 것을 보증합니다.

주의: 접속이 확립했을 때,mysql_real_connect() 에 의해서 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.

11.1.3.44. mysql_real_escape_string()

unsigned long mysql_real_escape_string(MYSQL *mysql, char *to, const char *from, unsigned long length)

설명

이 함수는,SQL 스테이트먼트로 사용할 수 있는 정당한 SQL 문자열을 작성하기 위해서 사용합니다. See 항6.1.1.1. 「문자열」 .

from (으)로 지정한 문자열이, 이스케이프 되었다 SQL 문자열에 encode 됩니다.이 때, 접속의 현재의 캐릭터 세트가 고려됩니다.encode 한 결과는 to (으)로 설정되어 말미에는 문자열의 마지막을 나타내는 누르바이트가 부가됩니다.encode 되는 문자는,NUL (ASCII 0 ),'\n' ,'\r' ,‘\ ＇,‘' ＇,‘" ＇, 및 Ctrl-Z 키(see 항6.1.1. 「리터럴: 문자열과 수치의 기술 방법」 )입니다(엄밀하게 말하면,MySQL 그리고 이스케이프 할 필요가 있는 것은 쿼리내에서 문자열을 인용하기 위한 backslash 및 인용부호 뿐입니다만, 이 함수에서는 로그 파일을 읽기 쉽게 하기 위해서 다른 문자도 이스케이프 합니다).

from 그리고 지정하는 문자열의 길이는 length 아르바이트일 필요가 있습니다.to 버퍼에는, 적어도 length*2+1 아르바이트의 메모리를 할당할 필요가 있습니다(최악의 경우,1 문자 encode 하는데 2 아르바이트가 필요한 가능성이 있어, 한층 더 문자열의 마지막을 나타내는 누르바이트를 격납할 필요가 있습니다).mysql_real_escape_string() 하지만 복귀했을 때,to 에는 눌 종단 문자열이 격납되고 있습니다.반환값은 encode 후의 문자열의 길이입니다.다만, 문자열의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

례

char query[1000],*end;

end = strmov(query,"INSERT INTO test_table values(");
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"What's this",11);
*end++ = '\'';
*end++ = ',';
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"binary data: \0\r\n",16);
*end++ = '\'';
*end++ = ')';

if (mysql_real_query(&mysql,query,(unsigned int) (end - query)))
{
   fprintf(stderr, "Failed to insert row, Error: %s\n",
           mysql_error(&mysql));
}

이 예로 사용되고 있다 strmov() 함수는,mysqlclient 라이브러리에 격납되고 있습니다.strcpy() (와)과 같은 처리를 실시합니다만,1 번째의 파라미터로 지정된 문자열의 마지막을 나타내는 누르바이트에의 포인터를 돌려줍니다.

반환값

to (으)로 설정된 값의 길이.다만, 문자열의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

에러

없습니다.

11.1.3.45. mysql_real_query()

int mysql_real_query(MYSQL *mysql, const char *query, unsigned long length)

설명

query 그리고 지정한 문자열로 나타내진다 SQL 쿼리를 실행합니다.이 문자열의 길이는 length 아르바이트일 필요가 있습니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

바이너리 데이터에는 '\0' 문자가 포함될 가능성이 있으므로, 그러한 데이터를 포함한 쿼리의 경우는,mysql_query() (이)가 아니고,mysql_real_query() (을)를 사용한다 필요가 있습니다 .또,mysql_real_query() (은)는 쿼리 문자열에 대해서 strlen() (을)를 호출하지 않기 때문에,mysql_query() 보다 고속으로 동작합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

반환값

쿼리가 정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.46. mysql_reload()

int mysql_reload(MYSQL *mysql)

설명

권한 테이블의 재독 봐 포함을 MySQL 서버에 요구합니다.접속 유저에게는 RELOAD 특권이 필요합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 FLUSH PRIVILEGES 스테이트먼트를 발행해 주세요.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.47. mysql_row_seek()

MYSQL_ROW_OFFSET mysql_row_seek(MYSQL_RES *result, MYSQL_ROW_OFFSET offset)

설명

쿼리 결과 세트의 임의의 레코드에 로 커서를 설정합니다.offset 의 값은 레코드 오프셋이며,mysql_row_tell() 또는 mysql_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_data_seek() (을)를 사용합니다.

mysql_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수 있습니다.

에러

없습니다.

11.1.3.48. mysql_row_tell()

MYSQL_ROW_OFFSET mysql_row_tell(MYSQL_RES *result)

설명

마지막에 실행되었다 mysql_fetch_row() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_row_seek() 에 인수로서 건네줄 수 있습니다.

          mysql_row_tell()

(은)는,mysql_use_result()

의 다음에는 없고,mysql_store_result()

의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋.

에러

없습니다.

11.1.3.49. mysql_select_db()

int mysql_select_db(MYSQL *mysql, const char *db)

설명

db 그리고 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

접속 유저가 데이타베이스를 사용하는 권한을 가지는 유저로서 인증되지 않는 경우,mysql_select_db() (은)는 실패합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.50. mysql_set_server_option()

int mysql_set_server_option(MYSQL *mysql, enum enum_mysql_set_option option)

설명

접속의 옵션을 유효 또는 무효로 합니다.option 에는 이하의 어느 쪽인가의치를 지정할 수 있습니다.

MYSQL_OPTION_MULTI_STATEMENTS_ON | 복수 스테이트먼트의 서포트를 유효하게 한다.
MYSQL_OPTION_MULTI_STATEMENTS_OFF | 복수 스테이트먼트의 서포트를 무효로 한다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • ER_UNKNOWN_COM_ERROR

    서버가 mysql_set_server_option() (을)를 서포트하지 않았다(서버가 4.1.1 보다 낡은 버젼의 경우)인가, 또는 서버가 설정하려고 한 옵션을 서포트하지 않았다.

11.1.3.51. mysql_shutdown()

int mysql_shutdown(MYSQL *mysql)

설명

데이터 베이스 서버에 슛다운 하도록(듯이) 요구합니다.접속 유저에게는 SHUTDOWN 특권이 필요합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.52. mysql_sqlstate()

const char *mysql_sqlstate(MYSQL *mysql)

설명

마지막에 발생한 에러의 SQLSTATE 에러 코드를 포함한 눌 종단 문자열을 돌려줍니다.에러 코드는 5 문자로 나타납니다.'00000' (은)는,`` 에러가 없다'' 일을 의미합니다.값은 ANSI SQL 및 ODBC 에 의해서 규정되고 있습니다.생각할 수 있는 값의 일람에 대해서는, 항12.1. 「돌려주어지는 에러」 (을)를 참조해 주세요.

주의: 모든 MySQL 에러가 SQLSTATE 에 매핑 되고 있는 것은 아닙니다.매핑 되어 있지 않은 에러의 경우는 'HY000' (일반 에러)(이)가 사용됩니다.

이 함수는 MySQL 4.1.1 그리고 추가되었습니다.

반환값

SQLSTATE 에러 코드를 포함한 눌 종단 문자열.

관련 항목

See 항11.1.3.12. 「mysql_errno() 」 . See 항11.1.3.13. 「mysql_error() 」 . See 항11.1.7.18. 「mysql_stmt_sqlstate() 」 .

11.1.3.53. mysql_ssl_set()

int mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca, const char *capath, const char *cipher)

설명

mysql_ssl_set() (은)는,SSL (을)를 사용하고, 시큐러티로 보호된 접속을 확립하기 위해서 사용합니다.mysql_real_connect() 의 전에 호출할 필요가 있습니다.

mysql_ssl_set() (은)는, 클라이언트 라이브러리에서 OpenSSL 서포트가 유효하게 되지 않은 경우는 아무것도 하지 않습니다.

mysql (은)는,mysql_init() (으)로부터 돌려주어진 접속 핸들러입니다.다른 파라미터의 지정 방법을 다음에 나타냅니다.

  • key 파라미터에는, 비밀 키파일에의 패스명을 지정한다.

  • cert 파라미터에는, 증명서 파일에의 패스명을 지정한다.

  • ca 파라미터에는, 인증국 발행의 증명서 파일에의 패스명을 지정한다.

  • capath 파라미터에는,PEM 형식이 신뢰 받았다 CA 증명서가 격납된 디렉토리에의 패스명을 지정한다.

  • cipher 파라미터에는,SSL 암호화에 사용할 수 있는 암호의 일람을 지정한다.

사용하지 않는다 SSL 파라미터에는 NULL (을)를 지정할 수 있습니다.

반환값

이 함수는 항상 0 (을)를 돌려줍니다.SSL 하지만 올바르고 셋업 되어 있지 않은 경우, 접속을 시도하면 mysql_real_connect() 하지만 에러를 돌려줍니다.

11.1.3.54. mysql_stat()

char *mysql_stat(MYSQL *mysql)

설명

mysqladmin status 커멘드의 출력으로 같은 정보를 포함한 문자열을 돌려줍니다.이 정보에는, 사용 가능 시간(초단위), 실행중의 스레드수, 질문의 수, 재로드 회수, 및 오픈되고 있는 테이블의 수가 포함됩니다.

반환값

서버 스테이터스를 나타내는 문자열.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.55. mysql_store_result()

MYSQL_RES *mysql_store_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT ,SHOW ,DESCRIBE ,EXPLAIN )에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

다른 쿼리에서는 mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요는 없습니다만, 모든 케이스로 mysql_store_result() (을)를 호출해도, 이상이 발생하거나 눈에 띈 동작을 하는 일은 없습니다.mysql_store_result() 하지만 0 (을)를 돌려줄지를 조사하는 것으로, 쿼리로 결과 세트가 생성되었는지를 검출할 수 있습니다.이것에 대해서는 후술 합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

mysql_store_result() (은)는, 쿼리의 결과 세트 전체를 클라이언트에 읽어들여,MYSQL_RES 구조체에 메모리를 할당해 이 구조체에 결과 세트를 격납합니다.

쿼리가 결과 세트를 돌려주지 않는 경우(예를 들어, 쿼리가 INSERT 스테이트먼트였던 경우),mysql_store_result() (은)는 누르포인타를 돌려줍니다.

또, 결과 세트의 읽어들여에 실패했을 경우도,mysql_store_result() (은)는 누르포인타를 돌려줍니다.에러가 발생했는지를 조사하려면 ,mysql_error() 하지만 누르포인타를 돌려주지 않는지 어떤지,mysql_errno() 하지만 0 이외의 값을 돌려줄지, 또는 mysql_field_count() 하지만 0 이외의 값을 돌려줄지를 조사합니다.

돌려주는 레코드가 존재하지 않는 경우는 하늘의 결과 세트가 돌려주어집니다(하늘의 결과 세트는, 반환값으로서의 누르포인타와는 다릅니다).

mysql_store_result() (을)를 호출하고, 반환값이 누르포인타 이외였던 경우,mysql_num_rows() (을)를 호출하면 결과 세트에 포함되는 레코드수를 취득할 수 있습니다.

mysql_fetch_row() (을)를 호출하면, 결과 세트로부터 레코드를 취득할 수 있습니다.mysql_row_seek() 및 mysql_row_tell() (을)를 호출하면, 결과 세트내의 경향 레코드의 위치를 설정 및 취득할 수 있습니다.

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출할 필요가 있습니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트가 격납되었다 MYSQL_RES 구조체.에러가 발생했을 경우는 NULL .

에러

mysql_store_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno (을)를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.56. mysql_thread_id()

unsigned long mysql_thread_id(MYSQL *mysql)

설명

현재의 접속의 스레드 ID (을)를 돌려줍니다.이 반환값을,mysql_kill() 에 인수로서 건네주어 스레드를 강제 종료할 수 있습니다.

현재의 접속이 절단 되어mysql_ping() (을)를 사용해 재접속했을 경우, 스레드 ID (은)는 다른 값이 됩니다.이것은, 취득한 스레드 ID (을)를 보관해 다음에 사용할 수 없는 것을 의미합니다.스레드 ID 하지만 필요하게 되었을 때에, 취득할 필요가 있습니다.

반환값

현재의 접속의 스레드 ID .

에러

없습니다.

11.1.3.57. mysql_use_result()

MYSQL_RES *mysql_use_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT ,SHOW ,DESCRIBE ,EXPLAIN )에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

mysql_use_result() (은)는, 결과 세트의 취득을 개시합니다만,mysql_store_result() (와)과 같이 실제로 결과 세트를 클라이언트에 읽어들이는 것은 아닙니다.대신에,mysql_fetch_row() (을)를 호출하고,1 행씩 개별적으로 취득할 필요가 있습니다.그 경우, 쿼리의 결과는 직접 서버로부터 읽혀 텐포라리테이불이나 로컬 버퍼에는 격납되지 않습니다.이것은 mysql_store_result() (을)를 사용하는 경우보다 다소 고속으로 있어, 사용하는 메모리도 적어도 됩니다.클라이언트는, 경향 레코드 및 max_allowed_packet 아르바이트까지 증가할 가능성이 있는 통신 버퍼에 메모리를 할당할 뿐입니다.

한편, 각각의 레코드에 대한 클라이언트측에서의 처리량이 많은 경우, 또는 유저가 ^S (을)를 입력한다(스크롤을 정?~ 할) 가능성이 있는 화면에 데이터를 출력하는 경우는,mysql_use_result() 의 사용은 피할 필요가 있습니다.그러한 처리의 경우, 서버의 동작이 정?~ 하고, 읽어내지고 있는 데이터가 격납되고 있는 테이블을 다른 스레드를 갱신할 수 없게 됩니다.

mysql_use_result() (을)를 사용하는 경우,NULL 하지만 돌려주어질 때까지 mysql_fetch_row() (을)를 반복해 호출할 필요가 있습니다.그렇게 하지 않으면 취득되지 않았던 레코드가, 다음에 실행하는 쿼리의 결과 세트의 일부로서 돌려주어집니다.취득되지 않았던 레코드가 남아 있는 경우,C API (은)는 에러 Commands out of sync; you can't run this command now (을)를 돌려줍니다.

          mysql_use_result()

하지만 돌려준 결과 세트에 대해서
          mysql_data_seek()
,mysql_row_seek()
,mysql_row_tell()
,mysql_num_rows()
, 또는
          mysql_affected_rows()

(을)를 사용할 수 없습니다.또,mysql_use_result()

하지만 완료할 때까지는 다른 쿼리를 발행할 수 없습니다(다만, 모든 레코드를 취득한 다음에 있으면
          mysql_num_rows()

(은)는 취득한 레코드의 수를 정확하게 돌려줍니다).

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

MYSQL_RES 구조체.에러가 발생했을 경우는 NULL .

에러

mysql_use_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno (을)를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.58. mysql_warning_count()

unsigned int mysql_warning_count(MYSQL *mysql)

설명

전회 실행되었다 SQL 스테이트먼트의 실행중에 발생한 경고수를 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

경고수.

에러

없습니다.

11.1.3.59. mysql_commit()

my_bool mysql_commit(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 코?~ 트 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.60. mysql_rollback()

my_bool mysql_rollback(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 롤백(rollback) 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.61. mysql_autocommit()

my_bool mysql_autocommit(MYSQL *mysql, my_bool mode)

설명

mode 하지만 1 의 경우는 자동코?~ 트모드를 유효하게,mode 하지만 0 의 경우는 무효로 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.62. mysql_more_results()

my_bool mysql_more_results(MYSQL *mysql)

설명

현재 실행하고 있는 쿼리 외에 아직 취득하고 있지 않는 결과 세트가 존재해, 어플리케이션이 mysql_next_result() (을)를 호출해 취득할 필요가 있는 경우는,true (을)를 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

취득되어 있지 않은 결과 세트가 존재하는 경우는 TRUE (1 ).취득되어 있지 않은 결과 세트가 존재하지 않는 경우는 FALSE (0 ).

주의: 대부분의 경우, 이 함수 대신에 mysql_next_result() (을)를 호출해 취득되어 있지 않은 결과 세트가 있을지를 조사하고, 존재하는 경우는 다음의 결과 세트를 개시합니다.

See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」 . See 항11.1.3.63. 「mysql_next_result() 」 .

에러

없습니다.

11.1.3.63. mysql_next_result()

int mysql_next_result(MYSQL *mysql)

설명

취득되어 있지 않은 결과 세트가 존재하는 경우,mysql_next_result() (은)는 다음의 쿼리의 결과 세트를 읽어들여, 스테이터스를 어플리케이션에 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

주의: 전의 쿼리가 결과 세트를 돌려주고 있었을 경우,mysql_free_result() (을)를 호출할 필요가 있습니다.

          mysql_next_result()

(을)를 호출한 후, 접속 상태는 다음의 쿼리에 대해
          mysql_real_query()

(을)를 호출한 후와 같게 됩니다.이것은, 이 함수를 호출한 후, 이 접속으로
          mysql_store_result()
,mysql_warning_count()
,mysql_affected_rows()

등을 호출할 수 있는 것을 의미합니다.

mysql_next_result() 하지만 에러를 돌려주었을 경우, 다른 스테이트먼트는 실행되지 않습니다.또, 취득되어 있지 않은 결과 세트도 존재하지 않습니다.

See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」 .

반환값

호출이 정상적으로 동작해, 취득하는 결과 세트가 존재하고 있었을 경우는 0 , 취득하는 결과 세트가 존재하지 않았던 경우는 -1 , 에러가 발생했을 경우는 정의 값.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.예를 들어, 전의 결과 세트로 mysql_use_result() 하지만 불려 가지 않았던 경우에 이 에러가 발생한다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.4. C API 의 Prepared Statements

MySQL 4.1 그럼, 프리페아드스테이트먼트를 사용하기 위한 클라이언트/ 서버 프로토콜이 제공되고 있습니다.이 기능은,MYSQL_STMT 스테이트먼트 핸들러 데이터 구조체를 사용합니다.프리페아드스테이트먼트의 실행은, 스테이트먼트를 반복해 실행하는 경우에 효율적인 방법입니다.스테이트먼트는, 실행할 준비를 갖추기 위해서, 우선 해석됩니다.그 후,prepare 함수로부터 돌려주어지는 스테이트먼트 핸들을 사용하고,1 회이상 실행됩니다.

프리페아드스테이트먼트의 실행은, 해석이 1 회 밖에 행해지지 않기 때문에, 스테이트먼트를 직접 여러 차례 실행하는 것보다도 고속으로.스테이트먼트를 직접 실행했을 경우, 그때마다 쿼리의 해석을 합니다.프리페아드스테이트먼트를 실행하는 경우, 네트워크 트래픽도, 파라미터로서 데이터를 송신할 경우에 발생할 뿐(만큼)이므로, 삭감할 수 있습니다.

그 외에도, 프리페아드스테이트먼트의 실행에서는 바이너리 프로토콜을 사용하므로, 클라이언트 및 서버간의 데이터 전송의 효율이 향상한다고 하는 이점이 있습니다.프리페아드스테이트먼트는, 복수 쿼리를 실행할 때의 입력 및 출력의 바인딩도 서포트합니다.

11.1.5. C API 의 Prepared Statement의 데이터형

주의: 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자 전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

프리페아드스테이트먼트는, 주로 MYSQL_STMT 및 MYSQL_BIND 의 각 데이터 구조체를 사용합니다.그 외에, 시간적인 데이터를 전송 하기 위해서 MYSQL_TIME (을)를 사용합니다.

  • MYSQL_STMT

    이 구조체는, 프리페아드스테이트먼트를 나타낸다.프리페아드스테이트먼트는,mysql_prepare() (을)를 호출해 작성한다.이 함수는,MYSQL_STMT 에의 포인터인 스테이트먼트 핸들을 돌려준다.이 핸들은, 그 후에 불려 가는 모든 스테이트먼트 관련의 함수로 사용된다.

    MYSQL_STMT 구조체의 멤버를 어플리케이션이 사용할 것은 없다.

    1 개의 접속에 복수의 스테이트먼트 핸들을 관련지을 수 있다.관련짓는 핸들수는, 사용할 수 있는 system resource에 의해서 제한된다.

  • MYSQL_BIND

    이 구조체는, 쿼리의 입력(데이터치가 서버에 송신된다) 및 출력(결과치가 서버로부터 돌려주어진다)의 양쪽 모두로 사용된다.입력의 경우,mysql_bind_param() 에 건네주어 파라미터 데이터치를 버퍼에 바인드 해,mysql_execute() 하지만 사용할 수 있도록 한다.출력의 경우,mysql_bind_result() 에 건네주어 결과 세트를 버퍼에 바인드 해,mysql_fetch() 그리고 레코드를 취득할 때에 사용할 수 있도록 한다.

    MYSQL_BIND 구조체에서는, 이하에 나타내는 멤버를 응용 프로그램을 사용할 수 있다.어느 멤버도 입력 및 출력의 어느 쪽에도 사용하지만, 데이터 전송의 방향에 따라서 다른 목적으로 사용하는 경우가 있다.

    • enum enum_field_types buffer_type

      버퍼의 형태.사용할 수 있다 buffer_type 의 값의 리스트를, 이 섹션의 후반에 나타낸다.입력의 경우,buffer_type (은)는 쿼리 파라미터에 바인드 하는 값의 형태를 나타낸다.출력의 경우, 결과 세트의 버퍼로 받는 값의 형태를 나타낸다.

    • void *buffer

      입력의 경우, 쿼리 파라미터의 데이터치가 보존되는 버퍼에의 포인터.출력의 경우, 결과 세트의 컬럼치를 돌려주는 버퍼에의 포인터.컬럼형이 수치의 경우,buffer (은)는 적절한 C 언어의 형태의 변수에의 포인터로 할 필요가 있다(UNSIGNED 속성을 가지는 컬럼에 변수를 관련짓고 있는 경우, 변수는 C 언어의 unsigned 형태로 할 필요가 있다).컬럼형이 일자 및 시각의 경우,buffer 하 MYSQL_TIME 구조체에의 포인터로 할 필요가 있다.컬럼형이 문자열 및 바이너리 문자열의 경우,buffer (은)는 문자 버퍼에의 포인터로 할 필요가 있다.

    • unsigned long buffer_length

      아르바이트 단위로 나타냈다 *buffer 의 실제의 사이즈.이 값은, 버퍼에 격납할 수 있는 데이터의 최대 사이즈를 나타낸다.C 의 문자 데이터 및 바이너리 데이터의 경우,buffer_length 의 값은,mysql_bind_param() 그리고 사용하는 경우는 *buffer 하지만 나타내 보이는 데이터의 길이, 또는 mysql_bind_result() 그리고 사용하는 경우는 버퍼에 취득할 수 있는 최대 데이터 바이트수를 지정한다.

    • unsigned long *length

      unsigned long 변수에의 포인터.*buffer 에 격납하는 데이터의 실제의 아르바이트수를 나타낸다.length (은)는, 격납하는 데이터가 C 의 문자 데이터 또는 바이너리 데이터의 경우에 사용한다.입력 파라미터 데이터를 바인드 하는 경우,length (은)는,*buffer 에 격납하는 파라미터치의 길이를 나타낸다 unsigned long 변수를 가리킨다.이것은 mysql_execute() 그리고 사용된다.length 하지만 누르포인타의 경우, 프로토콜은 모든 문자 데이터 및 바이너리 데이터가 눌로 종단 되고 있으면 가정한다.출력치를 바인드 하는 경우,mysql_fetch() (은)는, 돌려주는 데이터의 컬럼치의 길이를 length 하지만 포인트 하는 변수로 설정한다.

      수치 데이터형 또는 시간적인 데이터형의 경우, 데이터치의 길이는 buffer_type 의 값에 의해서 정해지므로,length (은)는 무시된다.

    • my_bool *is_null

      my_bool 변수에의 포인터.값이 NULL 의 경우는 true ,NULL 이외의 경우는 false .입력의 경우,*is_null (을)를 true (으)로 설정하는 것에 의해서, 쿼리 파라미터로서 NULL 값을 건네주고 있는 것을 나타낸다.출력의 경우, 쿼리가 돌려주는 값이 NULL 때에 레코드를 취득하면, 이 값이 true (으)로 설정된다.

  • MYSQL_TIME

    이 구조체는, 서버와 직접 DATE ,TIME ,DATETIME , 및 TIMESTAMP 데이터를 송수신 하기 위해서 사용한다.거기에는,MYSQL_BIND 구조체의 buffer_type 멤버를 몇개의 시간을 나타내는 형태로 설정해,buffer 멤버를 MYSQL_TIME 구조체를 포인트 하도록(듯이) 설정한다.

    MYSQL_TIME 구조체의 멤버를 이하에 나타낸다.

    • unsigned int year

      년.

    • unsigned int month

      월.

    • unsigned int day

      일.

    • unsigned int hour

      시.

    • unsigned int minute

      분.

    • unsigned int second

      초.

    • my_bool neg

      시간이 부화도인지를 나타내는 불리언 값 플래그.

    • unsigned long second_part

      초의 소수부.현재는 미사용.

    MYSQL_TIME 구조체의 멤버는, 사용하는 시간적인 형태에 대응하는 부분만큼이 사용된다.year ,month , 및 day 의 각 멤버는,DATE ,DATETIME , 및 TIMESTAMP 의 값에 사용한다.hour ,minute , 및 second 의 각 멤버는,TIME ,DATETIME , 및 TIMESTAMP 의 값에 사용한다. See 항11.1.9. 「C API 에 있어서의 일자치 및 시각치의 취급」 .

MYSQL_BIND 구조체의 buffer_type 멤버로 지정할 수 있는 값을 이하의 겉(표)에 나타냅니다.이 표에는, 각각의 buffer_type 의 값에 가장 가깝다 SQL 의 데이터형을 나타내, 한층 더 수치형과 시간적인 값의 형태에 대해서는 대응한다 C 의 데이터형도 나타내 보입니다.

buffer_type 치 | SQL 의 데이터형 | C 의 데이터형
MYSQL_TYPE_TINY | TINYINT | char
MYSQL_TYPE_SHORT | SMALLINT | short int
MYSQL_TYPE_LONG | INT | long int
MYSQL_TYPE_LONGLONG | BIGINT | long long int
MYSQL_TYPE_FLOAT | FLOAT | float
MYSQL_TYPE_DOUBLE | DOUBLE | double
MYSQL_TYPE_TIME | TIME | MYSQL_TIME
MYSQL_TYPE_DATE | DATE | MYSQL_TIME
MYSQL_TYPE_DATETIME | DATETIME | MYSQL_TIME
MYSQL_TYPE_TIMESTAMP | TIMESTAMP | MYSQL_TIME
MYSQL_TYPE_STRING | CHAR |
MYSQL_TYPE_VAR_STRING | VARCHAR |
MYSQL_TYPE_TINY_BLOB | TINYBLOB/TINYTEXT |
MYSQL_TYPE_BLOB | BLOB/TEXT |
MYSQL_TYPE_MEDIUM_BLOB | MEDIUMBLOB/MEDIUMTEXT |
MYSQL_TYPE_LONG_BLOB | LONGBLOB/LONGTEXT |

암묵의 데이터형 변환은 어느 방향에도 행해질 가능성이 있습니다.

11.1.6. C API 의 Prepared Statement 함수의 개요

주의: 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자 전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

여기에서는, 프리페아드스테이트먼트의 처리에 사용할 수 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이?~ 의 섹션으로 설명합니다. See 항11.1.7. 「C API 의 Prepared Statement 함수의 설명」 .

함수 | 설명
mysql_prepare() | SQL 문자열을 실행하기 위한 프리컴파일을 실시한다.
mysql_param_count() | 프리페아드스테이트먼트의 파라미터수를 돌려준다.
mysql_get_metadata() | 프리페아드스테이트먼트메타데이타를 결과 세트 형식에서 돌려준다.
mysql_bind_param() | 어플리케이션 데이터 버퍼를, 프리페아드스테이트먼트내의 파라미터 마커에 관련짓는다.
mysql_execute() | 프리페아드스테이트먼트를 실행한다.
mysql_stmt_affected_rows() | 마지막에 실행되었다 UPDATE ,DELETE , 또는 INSERT 의 몇개의 쿼리에 의해서 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_bind_result() | 어플리케이션 데이터 버퍼를, 결과 세트의 컬럼에 관련짓는다.
mysql_stmt_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_stmt_data_seek() | 스테이트먼트의 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_stmt_row_seek() | mysql_stmt_row_tell() (으)로부터 돌려주어진 값을 오프셋으로서 스테이트먼트의 결과 세트내의 레코드에 시크 한다.
mysql_stmt_row_tell() | 스테이트먼트의 레코드 커서의 위치를 돌려준다.
mysql_stmt_num_rows() | 버퍼에 격납된 스테이트먼트의 결과 세트 전체의 레코드수를 돌려준다.
mysql_fetch() | 결과 세트의 다음의 레코드의 데이터를 취득해, 바인드 된 모든 컬럼의 데이터를 돌려준다.
mysql_stmt_close() | 프리페아드스테이트먼트가 사용하고 있던 메모리를 해방한다.
mysql_stmt_errno() | 마지막에 실행된 스테이트먼트의 에러 번호를 돌려준다.
mysql_stmt_error() | 마지막에 실행된 스테이트먼트의 에러 메세지를 돌려준다.
mysql_stmt_sqlstate() | 마지막에 실행한 스테이트먼트의 SQLSTATE 에러 코드를 돌려준다.
mysql_send_long_data() | long 형태 데이터를 분리해 서버에 송신한다.

        mysql_prepare()

(을)를 호출해 스테이트먼트 핸들을 프리컴파일 해, 초기화합니다.다음에
        mysql_bind_param()

(을)를 호출해 파라미터 데이터를 건네주어,mysql_execute()

(을)를 호출해 쿼리를 실행합니다.mysql_bind_param()

경유로 건네주는 버퍼에 격납한 파라미터치를 변경하고,mysql_execute()

(을)를 반복 실행할 수도 있습니다.

쿼리가 SELECT 스테이트먼트의 경우, 또는 결과 세트를 생성하는 그 외의 쿼리의 경우,mysql_prepare() 하 mysql_get_metadata() (을)를 사용해 MYSQL_RES 결과 세트 형식에서 결과 세트의 메타데이타 정보도 돌려줍니다.

결과를 격납하는 버퍼를 mysql_bind_result() (을)를 사용해 건네주는 것에 의해서,mysql_fetch() (은)는 자동적으로 그 버퍼에 데이터를 돌려줍니다.여기에서는 1 행씩의 취득을 합니다.

옵션으로서 is_long_data=1 또는 length=MYSQL_LONG_DATA 또는 -2 (을)를 지정했다 MYSQL_BIND 구조체를 mysql_bind_param() 그리고 건네주면,mysql_send_long_data() (을)를 사용해 텍스트 데이터 또는 바이너리 데이터를 분리해 서버에 송신할 수 있습니다.

스테이트먼트의 실행이 완료하면,mysql_stmt_close() (을)를 호출해 스테이트먼트 핸들을 클로우즈 해, 핸들에 관련 붙일 수 있어 모든 자원을 해방할 필요가 있습니다.

mysql_get_metadata() (을)를 호출해 SELECT 스테이트먼트의 결과 셋트메타데이타를 취득하고 있었을 경우도,mysql_free_result() (을)를 호출해 해방할 필요가 있습니다.

실행 스텝

스테이트먼트를 프리컴파일 해 실행하려면 , 어플리케이션으로 이하의 스텝에 따라서 처리합니다.

  1. SQL 스테이트먼트를 포함한 문자열을 파라미터로서 mysql_prepare() (을)를 호출한다.프리컴파일이 정상적으로 종료했을 경우,mysql_prepare() (은)는 유효한 스테이트먼트 핸들러를 어플리케이션에 돌려준다.

  2. 결과 세트를 생성하는 쿼리를 실행하는 경우,mysql_get_metadata() (을)를 호출해 결과 셋트메타데이타를 취득한다.이 메타데이타는 그것 자신이 결과 세트 형식이다.다만, 쿼리가 돌려주는 레코드를 포함한 결과 세트와는 따로 건네받는다.결과 셋트메타데이타에는, 결과 세트에 포함되는 컬럼수 및 각 컬럼에 관한 정보가 포함된다.

  3. mysql_bind_param() (을)를 사용하고, 파라미터의 값을 설정한다.모든 파라미터의 값을 설정할 필요가 있다.값이 설정되어 있지 않은 파라미터가 남아 있으면, 에러가 돌려주어지거나 예상외의 결과가 발생한다.

  4. mysql_execute() (을)를 호출해 스테이트먼트를 실행한다.

  5. 결과 세트를 생성하는 쿼리를 실행했을 경우,mysql_bind_result() (을)를 호출하고, 레코드의 값을 취득하기 위한 데이터 버퍼를 바인드 한다.

  6. mysql_fetch() (을)를 호출하고,1 행 분의 데이터를 버퍼에 취득한다.모든 레코드의 데이터를 취득할 수 있을 때까지 이것을 반복한다.

  7. 필요에 따라서 스텝 3 (으)로부터 6 까지를 반복하고, 파라미터의 값을 변경하면서 스테이트먼트를 재실행한다.

mysql_prepare() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버의 프로토콜을 이하에 나타냅니다.

  • 서버는 쿼리를 해석해, 스테이트먼트 ID (을)를 할당하고,OK 스테이터스를 클라이언트에 답장한다.결과 세트를 생성하는 쿼리의 경우는, 게다가 파라미터의 합계수, 컬럼수, 및 그 메타 정보를 송신한다.이 호출로, 서버는 쿼리의 모든 구문 및 의미를 확인한다.

  • 클라이언트는 이 스테이트먼트 ID (을)를 사용해 그 후의 처리를 실행한다.이 ID (을)를 사용하고, 서버는 스테이트먼트 풀중에서 사용하는 스테이트먼트를 식별한다.또, 클라이언트는 스테이트먼트 핸들을 이 ID 에 할당해 핸들을 어플리케이션에 돌려준다.

mysql_execute() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는 스테이트먼트 핸들을 사용하고, 서버에 파라미터 데이터를 송신한다.

  • 서버는 클라이언트로부터 건네받았다 ID (을)를 사용해 스테이트먼트를 식별해, 파라미터 마커를 새롭게 건네받은 데이터에 옮겨놓아 쿼리를 실행한다.결과 세트를 생성하는 쿼리를 실행했을 경우, 서버는 데이터를 클라이언트에 답장한다.결과 세트를 생성하지 않는 쿼리를 실행했을 경우, 서버는 OK 스테이터스 및 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려준다.

mysql_fetch() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는, 패킷으로부터 1 행분씩 데이터를 읽어들여, 필요에 따라서 데이터 변환하면서 어플리케이션 데이터 버퍼에 격납한다.어플리케이션 버퍼의 형태가 서버로부터 돌려주어진 필드의 형태와 같은 경우는, 직접적으로 변환을 한다.

mysql_stmt_errno() ,mysql_stmt_error() , 및 mysql_stmt_sqlstate() (을)를 사용하면, 각각 스테이트먼트의 에러 코드, 에러 메세지, 및 SQLSTATE 값을 취득할 수 있습니다.

11.1.7. C API 의 Prepared Statement 함수의 설명

쿼리를 프리컴파일 해 실행하려면 , 이하의 함수를 사용합니다.

11.1.7.1. mysql_prepare()

MYSQL_STMT * mysql_prepare(MYSQL *mysql, const char *query, unsigned long length)

설명

눌 종단 문자열 query 그리고 지정되었다 SQL 쿼리를 프리컴파일 해, 그 후의 처리에 사용하는 스테이트먼트 핸들을 돌려줍니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

어플리케이션은,SQL 문자열의 적당한 위치에 물음표(‘? ＇)(을)를 묻는 것으로,SQL 스테이트먼트로 1 개이상의 파라미터 마커를 사용할 수 있습니다.

마커는,SQL 스테이트먼트의 특정의 위치에 파묻혔을 경우에게만 적정하게 처리됩니다.예를 들어, 마커는 INSERT 스테이트먼트의 VALUES() 의 리스트로 레코드로 설정하는 컬럼의 값을 지정하는 부분, 또는 WHERE 마디로 컬럼의 값과 비교하는 값을 지정하는 부분에 사용할 수 있습니다.그러나,SELECT 스테이트먼트가 돌려주는 컬럼을 지정하는 선택 리스트로 식별자(테이블 또는 컬럼의 이름등)로서 사용하거나 등호(= )등의 바이너리 연산자의 양쪽 모두의 오퍼랜드를 지정할 수 없습니다.파라미터의 형태를 결정할 수 없기 때문에, 후자의 제약이 필요하게 됩니다.일반적으로, 파라미터는, 데이터 조작 언어(DML ) 스테이트먼트에서만 적정하게 처리되어 데이터 정의 언어(DDL ) 스테이트먼트에서는 처리되지 않습니다.

파라미터 마커는, 스테이트먼트를 실행하기 전에,mysql_bind_param() (을)를 사용해 어플리케이션 변수에 바인드 할 필요가 있습니다.

반환값

컴파일이 정상적으로 종료했을 경우는 MYSQL_STMT 구조체에의 포인터.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

컴파일이 실패했을 경우(mysql_prepare() 하지만 NULL (을)를 돌려주었을 경우), 에러 메세지는 mysql_error() (을)를 호출하는 것에 의해서 취득할 수 있습니다.

례

mysql_prepare() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.2. mysql_param_count()

unsigned long mysql_param_count(MYSQL_STMT *stmt)

설명

프리컴파일 된 스테이트먼트에 포함되는 파라미터 마커의 수를 돌려줍니다.

반환값

스테이트먼트에 포함되는 파라미터수를 나타낸다 unsigned long 정수.

에러

없습니다.

례

mysql_param_count() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.3. mysql_get_metadata()

MYSQL_RES *mysql_get_metadata(MYSQL_STMT *stmt)

설명

mysql_prepare() 에게 건네진 스테이트먼트가 결과 세트를 생성하는 것인 경우,mysql_get_metadata() 하 MYSQL_RES 구조체에의 포인터라고 하는 형태로 결과 셋트메타데이타를 돌려줍니다.이 구조체를 사용하고, 필드의 합계수 및 개개의 필드 정보등의 메타 정보를 처리할 수 있습니다.이 결과 세트에의 포인터는, 결과 셋트메타데이타를 처리하는 이하의 필드 베이스의 API 함수에 인수로서 건네줄 수 있습니다.

  • mysql_num_fields()

  • mysql_fetch_field()

  • mysql_fetch_field_direct()

  • mysql_fetch_fields()

  • mysql_field_count()

  • mysql_field_seek()

  • mysql_field_tell()

  • mysql_free_result()

결과 세트 구조체는, 사용할 필요가 없어지면 mysql_free_result() 에 건네주어 해방할 필요가 있습니다.이것은,mysql_store_result() (을)를 호출해 취득한 결과 세트를 해방하는 방법과 닮아 있습니다.

mysql_get_metadata() (으)로부터 돌려주어지는 결과 세트에는, 메타데이타만이 포함됩니다.레코드 데이터는 포함되지 않습니다.레코드를 취득하려면 , 스테이트먼트 핸들을 파라미터로서 mysql_fetch() (을)를 호출합니다.

반환값

MYSQL_RES 구조체.프리컴파일 한 쿼리의 메타 정보가 존재하지 않는 경우는 NULL .

에러

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_get_metadata() 의 사용 방법에 대해서는, 항11.1.7.13. 「mysql_fetch() 」 의 「예」를 참조해 주세요.

11.1.7.4. mysql_bind_param()

my_bool mysql_bind_param(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_param() (은)는,mysql_prepare() 에게 건네졌다 SQL 스테이트먼트에 포함되는 파라미터 마커의 데이터를 바인드 하기 위해서 사용합니다.데이터는 MYSQL_BIND 구조체를 사용해 건네줍니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 쿼리에 포함되는 각 ‘? ＇ 파라미터에 대응하는 요소가 포함되어 있으면 가정합니다.

예를 들어, 이하의 스테이트먼트를 프리컴파일 한다고 합니다.

INSERT INTO mytbl VALUES(?,?,?)

파라미터를 바인드 하는 경우,MYSQL_BIND 구조체에는 3 개의 요소가 필요하고, 이하와 같이 선언할 수 있습니다.

MYSQL_BIND bind[3];

설정할 필요가 있다 MYSQL_BIND 의 각 요소의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_NO_PARAMETERS_EXISTS

    바인드 하는 파라미터가 존재하지 않는다.

  • CR_INVALID_BUFFER_USE

    이것이long 데이터를 분리해 건네주기 위한 바인드인가, 및 버퍼의 형태가 문자열 이외 또는 바이너리 이외인지를 나타낸다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_param() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.5. mysql_execute()

int mysql_execute(MYSQL_STMT *stmt)

설명

mysql_execute() (은)는, 스테이트먼트 핸들에 관련지을 수 있고 있는 프리컴파일 된 쿼리를 실행합니다.이 호출 시에, 현재 바인드 되고 있는 파라미터 마커의 값이 서버에 송신되어 서버는 마커를 여기서 건네받은 데이터로 옮겨놓습니다.

스테이트먼트가 UPDATE ,DELETE , 또는 INSERT 의 경우,mysql_stmt_affected_rows() (을)를 호출하는 것에 의해서, 변경, 삭제, 또는 삽입된 레코드의 합계수를 취득할 수 있습니다.이것이 SELECT 등의 결과 세트를 생성하는 쿼리의 경우, 최초로 mysql_fetch() (을)를 호출해 데이터를 취득하고 나서, 다른 쿼리 처리를 필요로 하는 함수를 호출할 필요가 있습니다.결과를 취득하는 방법의 상세한 것에 대하여는, 항11.1.7.13. 「mysql_fetch() 」 (을)를 참조해 주세요.

반환값

정상적으로 실행했을 경우는 0 .에러가 발생했을 경우는 0 이외.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해서 취득할 수 있습니다.

에러

  • CR_NO_PREPARE_QUERY

    실행하기 전에 프리컴파일 된 쿼리가 존재하지 않는다.

  • CR_ALL_PARAMS_NOT_BOUND

    건네받지 않은 파라미터 데이터가 있다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

이하의 예에서는,mysql_prepare()
,mysql_param_count()
,mysql_bind_param()
,mysql_execute()
, 및
          mysql_stmt_affected_rows()

(을)를 사용하고, 테이블을 작성해, 데이터를 삽입하는 방법을 나타냅니다.mysql

변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define DROP_SAMPLE_TABLE "DROP TABLE IF EXISTS test_table"
#define CREATE_SAMPLE_TABLE "CREATE TABLE test_table(col1 INT,\
                                                 col2 VARCHAR(40),\
                                                 col3 SMALLINT,\
                                                 col4 TIMESTAMP)"
#define INSERT_SAMPLE "INSERT INTO test_table(col1,col2,col3) VALUES(?,?,?)"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[3];
my_ulonglong  affected_rows;
int           param_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
unsigned long str_length;
my_bool       is_null;

if (mysql_query(mysql, DROP_SAMPLE_TABLE))
{
  fprintf(stderr, " DROP TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

if (mysql_query(mysql, CREATE_SAMPLE_TABLE))
{
  fprintf(stderr, " CREATE TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

/* Prepare an INSERT query with 3 parameters */
/* (the TIMESTAMP column is not named; it will */
/* be set to the current date and time) */
stmt = mysql_prepare(mysql, INSERT_SAMPLE, strlen(INSERT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), INSERT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, INSERT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in INSERT: %d\n", param_count);

if (param_count != 3) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Bind the data for all 3 parameters */

/* INTEGER PARAM */
/* This is a number type, so there is no need to specify buffer_length */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *)&int_data;
bind[0].is_null= 0;
bind[0].length= 0;

/* STRING PARAM */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *)str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= 0;
bind[1].length= &str_length;

/* SMALLINT PARAM */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *)&small_data;
bind[2].is_null= &is_null;
bind[2].length= 0;

/* Bind the buffers */
if (mysql_bind_param(stmt, bind))
{
  fprintf(stderr, " mysql_bind_param() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Specify the data values for the first row */
int_data= 10;             /* integer */
strncpy(str_data, "MySQL", STRING_SIZE); /* string  */
str_length= strlen(str_data);

/* INSERT SMALLINT data as NULL */
is_null= 1;

/* Execute the INSERT statement - 1*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), 1 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total number of affected rows */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 1): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Specify data values for second row, then re-execute the statement */
int_data= 1000;
strncpy(str_data, "The most popular open source database", STRING_SIZE);
str_length= strlen(str_data);
small_data= 1000;         /* smallint */
is_null= 0;               /* reset */

/* Execute the INSERT statement - 2*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute, 2 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total rows affected */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 2): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Close the statement */
if (mysql_stmt_close(stmt))
{
  fprintf(stderr, " failed while closing the statement\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

주의: Prepared Statement 함수를 사용한 완전한 예에 대해서는, 파일 tests/mysql_client_test.c (을)를 참조해 주세요.이 파일은,MySQL 소스 디스트리뷰션 또는 BitKeeper 소스 리포지터리(repository)로부터 취득할 수 있습니다.

11.1.7.6. mysql_stmt_affected_rows()

my_ulonglong mysql_stmt_affected_rows(MYSQL_STMT *stmt)

설명

마지막에 실행된 스테이트먼트에 의해서 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려줍니다.UPDATE ,DELETE , 또는 INSERT 의 몇개의 스테이트먼트에 대해서 mysql_execute() (을)를 호출한 직후에 불려 갈 가능성이 있습니다.SELECT 스테이트먼트의 경우,mysql_stmt_affected_rows() (을)를 호출하면,mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해서 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타내 보입니다.－1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_fetch() (을)를 호출하기 전에 mysql_stmt_affected_rows() 하지만 불려 간 것을 나타내 보입니다.

에러

없습니다.

례

mysql_stmt_affected_rows() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.7. mysql_bind_result()

my_bool mysql_bind_result(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_result() (은)는, 결과 세트의 컬럼을 데이터 버퍼 및 길이 버퍼에 관련짓는(바인드 한다) 위해(때문에) 사용합니다.mysql_fetch() (을)를 호출해 데이터를 취득하는 경우,MySQL 클라이언트/ 서버 프로토콜에 의해서, 바인드 된 컬럼의 데이터가 지정된 버퍼에 써집니다.

주의: mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 결과 세트의 각 컬럼에 대응한 요소가 포함되어 있으면 가정합니다.요소가 포함되지 않은 경우,mysql_fetch() (은)는 단지 데이터를 취득하지 않습니다.또, 클라이언트/ 서버 프로토콜은 데이터의 값을 분리해 돌려주지는 않기 때문에, 버퍼의 사이즈는 데이터치를 격납 가능한 한의 충분한 크기일 필요가 있습니다.

컬럼은, 임의의 시점에서, 결과 세트의 일부만이 취득된 다음에도, 바인드 또는 재바인드 할 수 있습니다.새롭게 바인드 했을 경우, 그것이 유효하게 되는 것은, 다음에 mysql_fetch() (을)를 호출했을 때입니다.예를 들어, 어플리케이션이 결과 세트의 컬럼을 바인드 해 mysql_fetch() (을)를 호출한다고 합니다.클라이언트/ 서버 프로토콜은, 바인드 된 버퍼에 데이터를 돌려줍니다.다음에 어플리케이션이 컬럼을 다른 버퍼에 바인드 한다고 합니다.프로토콜은, 다음에 mysql_fetch() 하지만 불려 갈 때까지, 새롭고 바인드 된 버퍼에 데이터를 쓰지 않습니다.

컬럼을 바인드 하려면 , 어플리케이션은 mysql_bind_result() (을)를 호출하고, 형태, 주소, 및 길이 버퍼의 주소를 건네줍니다.설정할 필요가 있다 MYSQL_BIND 의 각 요소의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_result() 의 사용 방법에 대해서는, 항11.1.7.13. 「mysql_fetch() 」 의 「예」를 참조해 주세요.

11.1.7.8. mysql_stmt_store_result()

int mysql_stmt_store_result(MYSQL_STMT *stmt)

설명

쿼리가 결과 세트를 정상적으로 생성해(SELECT ,SHOW ,DESCRIBE ,EXPLAIN ), 한층 더 클라이언트의 버퍼에 결과 세트 전체를 격납하고, 그 후의 mysql_fetch() 의 호출로 버퍼 된 데이터가 돌려주어지도록(듯이) 하는 경우에 한정해,mysql_stmt_store_result() (을)를 호출할 필요가 있습니다.

그러한 쿼리 이외에서는 mysql_stmt_store_result() (을)를 호출할 필요는 없습니다만, 호출했다고 해도 이상이 발생하거나 눈에 띈 동작을 하는 일은 일절 없습니다.mysql_get_metadata() 하지만 NULL (을)를 돌려줄지를 조사하는 것으로, 쿼리가 결과 세트를 생성했는지를 검출할 수 있습니다.상세한 것에 대하여는, 항11.1.7.3. 「mysql_get_metadata() 」 (을)를 참조해 주세요.

반환값

결과 세트가 정상적으로 버퍼에 격납되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.7.9. mysql_stmt_data_seek()

void mysql_stmt_data_seek(MYSQL_STMT *stmt, my_ulonglong offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_stmt_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_stmt_data_seek() (을)를 사용하려면 , 스테이트먼트의 결과 세트 구조체에 마지막에 실행된 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.7.10. mysql_stmt_row_seek()

MYSQL_ROW_OFFSET mysql_stmt_row_seek(MYSQL_STMT *stmt, MYSQL_ROW_OFFSET offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 레코드 커서를 설정합니다.offset 의 값은 레코드 오프셋이며,mysql_stmt_row_tell() 또는 mysql_stmt_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_stmt_data_seek() (을)를 사용합니다.

mysql_stmt_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_stmt_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수 있습니다.

에러

없습니다.

11.1.7.11. mysql_stmt_row_tell()

MYSQL_ROW_OFFSET mysql_stmt_row_tell(MYSQL_STMT *stmt)

설명

마지막에 실행되었다 mysql_fetch() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_stmt_row_seek() 에 인수로서 건네줄 수 있습니다.

mysql_stmt_row_tell() (은)는,mysql_stmt_store_result() 의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋.

에러

없습니다.

11.1.7.12. mysql_stmt_num_rows()

my_ulonglong mysql_stmt_num_rows(MYSQL_STMT *stmt)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_stmt_num_rows() (을)를 사용할지 어떨지는,mysql_stmt_store_result() (을)를 사용해 결과 세트 전체를 스테이트먼트 핸들에 격납했는지에 의해서 정해집니다.

mysql_stmt_store_result() (을)를 사용하는 경우, 곧바로 mysql_stmt_num_rows() (을)를 호출할 수 있습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.7.13. mysql_fetch()

int mysql_fetch(MYSQL_STMT *stmt)

설명

mysql_fetch() (은)는, 결과 세트의 다음의 레코드를 취득합니다.이 함수는 결과 세트가 존재하는 동안만, 즉,mysql_execute() (을)를 호출해 결과 세트를 작성한 후, 또는 mysql_execute() (을)를 호출해 결과 세트 전체를 버퍼에 격납하고 나서 mysql_stmt_store_result() (을)를 호출한 후에게만, 호출할 수 있습니다.

mysql_fetch() (은)는,mysql_bind_result() (을)를 호출해 바인드 한 버퍼를 사용해 레코드 데이터를 돌려줍니다.버퍼에는, 현재의 레코드 세트의 모든 컬럼의 데이터가 격납됩니다.데이터의 길이는 length 포인터에 돌려주어집니다.

주의: 어플리케이션은,mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.

취득한 데이터가 NULL 값이었던 경우, 대응한다 MYSQL_BIND 구조체의 *is_null 의 값에는 TRUE (1 )(이)가 격납됩니다.그 이외의 값이었던 경우, 어플리케이션이 지정한 버퍼의 형태에 근거하고, 데이터 및 그 길이가 각각 *buffer 요소 및 *length 요소에 돌려주어집니다.수치형 및 시간적인 값의 형태는, 이하의 겉(표)에 나타내도록(듯이), 각각 고정장입니다.문자열형의 길이는, 실제의 데이터의 길이에 의해서 정해져,data_length 에 의해서 나타내집니다.

형 | 길이
MYSQL_TYPE_TINY | 1
MYSQL_TYPE_SHORT | 2
MYSQL_TYPE_LONG | 4
MYSQL_TYPE_LONGLONG | 8
MYSQL_TYPE_FLOAT | 4
MYSQL_TYPE_DOUBLE | 8
MYSQL_TYPE_TIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATE | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATETIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_STRING | data length
MYSQL_TYPE_BLOB | data_length

반환값

반환값 | 설명
0 | 정상.데이터는 어플리케이션 데이터 버퍼에 취득되고 있다.
1 | 에러가 발생했다.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해서 취득할 수 있다.
MYSQL_NO_DATA | 취득되어 있지 않은 레코드/ 데이터는 남지 않았다.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • CR_UNSUPPORTED_PARAM_TYPE

    버퍼의 형태는 MYSQL_TYPE_DATE ,MYSQL_TYPE_TIME ,MYSQL_TYPE_DATETIME , 또는 MYSQL_TYPE_TIMESTAMP 그런데, 데이터의 형태는 DATE ,TIME ,DATETIME , 또는 TIMESTAMP 의 머지않아도 아니다.

  • 그 외의 서포트되어 있지 않은 변환에 관한 에러는 모두 mysql_bind_result() (으)로부터 돌려주어진다.

례

이하의 예에서는,mysql_get_metadata() ,mysql_bind_result() , 및 mysql_fetch() (을)를 사용하고, 테이블에서 데이터를 취득하는 방법을 나타냅니다(이 예에서는 항11.1.7.5. 「mysql_execute() 」 의 예로 삽입되었다 2 행의 레코드를 취득하는 것과 상정하고 있습니다).mysql 변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define SELECT_SAMPLE "SELECT col1, col2, col3, col4 FROM test_table"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[4];
MYSQL_RES     *prepare_meta_result;
MYSQL_TIME    ts;
unsigned long length[4];
int           param_count, column_count, row_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
my_bool       is_null[4];

/* Prepare a SELECT query to fetch data from test_table */
stmt = mysql_prepare(mysql, SELECT_SAMPLE, strlen(SELECT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), SELECT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, SELECT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in SELECT: %d\n", param_count);

if (param_count != 0) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Fetch result set meta information */
prepare_meta_result = mysql_get_metadata(stmt);
if (!prepare_meta_result)
{
  fprintf(stderr, " mysql_get_metadata(), returned no meta information\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get total columns in the query */
column_count= mysql_num_fields(prepare_meta_result);
fprintf(stdout, " total columns in SELECT statement: %d\n", column_count);

if (column_count != 4) /* validate column count */
{
  fprintf(stderr, " invalid column count returned by MySQL\n");
  exit(0);
}

/* Execute the SELECT query */
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Bind the result buffers for all 4 columns before fetching them */

/* INTEGER COLUMN */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *)&int_data;
bind[0].is_null= &is_null[0];
bind[0].length= &length[0];

/* STRING COLUMN */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *)str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= &is_null[1];
bind[1].length= &length[1];

/* SMALLINT COLUMN */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *)&small_data;
bind[2].is_null= &is_null[2];
bind[2].length= &length[2];

/* TIMESTAMP COLUMN */
bind[3].buffer_type= MYSQL_TYPE_TIMESTAMP;
bind[3].buffer= (char *)&ts;
bind[3].is_null= &is_null[3];
bind[3].length= &length[3];

/* Bind the result buffers */
if (mysql_bind_result(stmt, bind))
{
  fprintf(stderr, " mysql_bind_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Now buffer all results to client */
if (mysql_stmt_store_result(stmt))
{
  fprintf(stderr, " mysql_stmt_store_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Fetch all rows */
row_count= 0;
fprintf(stdout, "Fetching results ...\n");
while (!mysql_fetch(stmt))
{
  row_count++;
  fprintf(stdout, "  row %d\n", row_count);

  /* column 1 */
  fprintf(stdout, "   column1 (integer)  : ");
  if (is_null[0])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %d(%ld)\n", int_data, length[0]);

  /* column 2 */
  fprintf(stdout, "   column2 (string)   : ");
  if (is_null[1])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %s(%ld)\n", str_data, length[1]);

  /* column 3 */
  fprintf(stdout, "   column3 (smallint) : ");
  if (is_null[2])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %d(%ld)\n", small_data, length[2]);

  /* column 4 */
  fprintf(stdout, "   column4 (timestamp): ");
  if (is_null[3])
    fprintf(stdout, " NULL\n");
  else
    fprintf(stdout, " %04d-%02d-%02d %02d:%02d:%02d (%ld)\n",
                                               ts.year, ts.month, ts.day,
                                               ts.hour, ts.minute, ts.second,
                                               length[3]);
  fprintf(stdout, "\n");
}

/* Validate rows fetched */
fprintf(stdout, " total rows fetched: %d\n", row_count);
if (row_count != 2)
{
  fprintf(stderr, " MySQL failed to return all rows\n");
  exit(0);
}

/* Free the prepared result metadata */
mysql_free_result(prepare_meta_result);

/* Close the statement */
if (mysql_stmt_close(stmt))
{
  fprintf(stderr, " failed while closing the statement\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

11.1.7.14. mysql_send_long_data()

my_bool mysql_send_long_data(MYSQL_STMT *stmt, unsigned int parameter_number, const char *data, unsigned long length)

설명

어플리케이션은 이 함수를 사용하고, 파라미터 데이터를 개별적으로(또는 `` 분리해'' ) 서버에 송신할 수 있습니다.이 함수를 여러 차례 호출하는 것에 의해서,TEXT 또는 BLOB 의 어느 쪽인가의 데이터형의 컬럼의 문자 데이터치 또는 바이너리 데이터치를 여러 차례로 나누어 송신할 수 있습니다.

parameter_number (은)는, 데이터를 관련짓는 파라미터를 나타내는 번호입니다.파라미터의 번호는 0 (으)로부터 시작됩니다.data (은)는 송신 데이터를 포함한 버퍼에의 포인터를,length (은)는 버퍼내의 데이터의 아르바이트수를 나타냅니다.

반환값

데이터를 서버에 정상적으로 송신할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_INVALID_PARAMETER_NO

    무효인 파라미터 번호가 지정되었다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

이하의 예에서는,TEXT 형태 컬럼의 데이터를 분리해 송신하는 방법을 나타냅니다.여기에서는, 데이터치 'MySQL - The most popular open source database' (을)를 text_column 컬럼에 삽입합니다.mysql 변수는 유효한 접속 핸들로 합니다.

#define INSERT_QUERY "INSERT INTO test_long_data(text_column) VALUES(?)"

MYSQL_BIND bind[1];
long       length;

if (!mysql_prepare(mysql, INSERT_QUERY, strlen(INSERT_QUERY))
{
  fprintf(stderr, "\n prepare failed");
  fprintf(stderr, "\n %s", mysql_error(mysql));
  exit(0);
}
 memset(bind, 0, sizeof(bind));
 bind[0].buffer_type= MYSQL_TYPE_STRING;
 bind[0].length= &length;
 bind[0].is_null= 0;

/* Bind the buffers */
if (mysql_bind_param(stmt, bind))
{
  fprintf(stderr, "\n param bind failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Supply data in chunks to server */
 if (!mysql_send_long_data(stmt,0,"MySQL",5))
{
  fprintf(stderr, "\n send_long_data failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Supply the next piece of data */
 if (mysql_send_long_data(stmt,0," - The most popular open source database",40))
{
  fprintf(stderr, "\n send_long_data failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

 /* Now, execute the query */
 if (mysql_execute(stmt))
{
  fprintf(stderr, "\n mysql_execute failed");
  fprintf(stderr, "\n %s", mysql_stmt_error(stmt));
  exit(0);
}

11.1.7.15. mysql_stmt_close()

my_bool mysql_stmt_close(MYSQL_STMT *)

설명

프리페아드스테이트먼트를 클로우즈 합니다.mysql_stmt_close() 그럼,stmt 하지만 나타내 보이는 스테이트먼트 핸들에 할당할 수 있었던 메모리도 해방됩니다.

현재의 스테이트먼트의 결과 세트의 처리가 도중인가, 또는 취득되어 있지 않은 레코드가 남아 있는 경우, 이 함수를 호출하면, 그 상태를 캔슬하고, 다음의 쿼리를 실행할 수 있도록 합니다.

반환값

스테이트먼트가 정상적으로 해방되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_stmt_close() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.16. mysql_stmt_errno()

unsigned int mysql_stmt_errno(MYSQL_STMT *stmt)

설명

mysql_stmt_errno() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 스테이트먼트 API 함수의 에러 코드를 돌려줍니다.반환값이 0 의 경우, 에러는 발생하고 있지 않습니다.클라이언트의 에러 메세지 번호의 일람은,MySQL errmsg.h 헤더 파일에 기술되고 있습니다.서버의 에러 메세지 번호의 일람은,mysqld_error.h 에 기술되고 있습니다.MySQL 소스 디스트리뷰션에 포함되는 파일 Docs/mysqld_error.txt 에는, 모든 에러 메세지 및 에러 번호의 일람이 기술되고 있습니다.서버의 에러 코드의 일람은, 항12.1. 「돌려주어지는 에러」 에도 기재되어 있습니다.

반환값

에러 코드의 값.에러가 발생하고 있지 않는 경우는 0 .

에러

없습니다.

11.1.7.17. mysql_stmt_error()

const char *mysql_stmt_error(MYSQL_STMT *stmt)

설명

mysql_stmt_error() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 스테이트먼트 API 함수의 에러 메세지를 포함한 눌 종단 문자열을 돌려줍니다.에러가 발생하고 있지 않는 경우는 공문자열("" )(을)를 돌려줍니다.이것은, 다음의 2 개의 비교는 등가인 것을 의미합니다.

if (mysql_stmt_errno(stmt))
{
  // an error occurred
}

if (mysql_stmt_error(stmt)[0])
{
  // an error occurred
}

클라이언트의 에러 메세지의 언어는,MySQL 클라이언트 라이브러리를 재컴파일 하는 것에 의해서 변경할 수 있습니다.현재는, 복수가 다른 언어로 에러 메세지를 돌려줄 수 있습니다.

반환값

에러의 내용을 설명하는 문자열.에러가 발생하고 있지 않는 경우는 공문자열.

에러

없습니다.

11.1.7.18. mysql_stmt_sqlstate()

const char *mysql_stmt_sqlstate(MYSQL_STMT *stmt)

설명

mysql_stmt_sqlstate() (은)는,stmt 그리고 지정되는 스테이트먼트에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있는 프리페아드스테이트먼트 API 함수의 SQLSTATE 에러 코드를 포함한 눌 종단 문자열을 돌려줍니다.에러 코드는 5 문자로 나타납니다."00000" (은)는,`` 에러가 없다'' 일을 의미합니다.값은 ANSI SQL 및 ODBC 에 의해서 규정되고 있습니다.생각할 수 있는 값의 일람에 대해서는, 항12.1. 「돌려주어지는 에러」 (을)를 참조해 주세요.

주의: 모든 MySQL 에러가 SQLSTATE 에 매핑 되고 있는 것은 아닙니다.매핑 되어 있지 않은 에러의 경우는 "HY000" (일반 에러)(이)가 사용됩니다.

이 함수는 MySQL 4.1.1 그리고 추가되었습니다.

반환값

SQLSTATE 에러 코드를 포함한 눌 종단 문자열.

11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급

MySQL (은)는, 버젼 4.1 (으)로부터 1 개의 쿼리 문자열로 지정된 복수 스테이트먼트의 실행을 서포트합니다.접속으로 이 기능을 사용하려면 , 접속을 오픈할 경우에 mysql_real_connect() 의 플래그 파라미터로 CLIENT_MULTI_STATEMENTS 옵션을 지정할 필요가 있습니다.이 옵션은,mysql_set_server_option(MYSQL_OPTION_MULTI_STATEMENTS_ON) (을)를 호출하는 것으로, 접속에 대해서 설정할 수도 있습니다.

디폴트에서는,mysql_query() 및 mysql_real_query() (은)는 최초의 쿼리의 스테이터스만을 돌려줍니다.그 후의 쿼리의 스테이터스는 mysql_more_results() 및 mysql_next_result() (을)를 사용해 처리할 수 있습니다.

/* Connect to server with option CLIENT_MULTI_STATEMENTS */
mysql_real_connect(..., CLIENT_MULTI_STATEMENTS);

/* Now execute multiple queries */
mysql_query(mysql,"DROP TABLE IF EXISTS test_table;\
                   CREATE TABLE test_table(id INT);\
                   INSERT INTO test_table VALUES(10);\
                   UPDATE test_table SET id=20 WHERE id=10;\
                   SELECT * FROM test_table;\
                   DROP TABLE test_table";
do
{
  /* Process all results */
  ...
  printf("total affected rows: %lld", mysql_affected_rows(mysql));
  ...
  if (!(result= mysql_store_result(mysql)))
  {
     printf(stderr, "Got fatal error processing query\n");
     exit(1);
  }
  process_result_set(result);	/* client function */
  mysql_free_result(result);
} while (!mysql_next_result(mysql));

11.1.9. C API 에 있어서의 일자치 및 시각치의 취급

MySQL 4.1 그리고 도입된 새로운 바이너리 프로토콜을 사용하면,MYSQL_TIME 구조체를 사용해 일자 및 시각에 관한 값(DATE ,TIME ,DATETIME , 및 TIMESTAMP )(을)를 송수신 할 수 있습니다.이 구조체의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

시간적인 데이터를 송신하려면 ,mysql_prepare() (을)를 사용해 프리페아드스테이트먼트를 작성합니다.다음에 mysql_execute() (을)를 호출해 스테이트먼트를 실행하기 전에, 이하의 순서를 실행해 시간적인 파라미터를 설정합니다.

  1. 데이터치에 관련지을 수 있었다 MYSQL_BIND 구조체의 멤버 buffer_type 에, 송신하는 시간적인 값의 형태를 나타내는 값을 설정한다.DATE ,TIME ,DATETIME , 또는 TIMESTAMP 의 값의 경우,buffer_type 에 MYSQL_TYPE_DATE ,MYSQL_TYPE_TIME ,MYSQL_TYPE_DATETIME , 또는 MYSQL_TYPE_TIMESTAMP (을)를 각각 설정한다.

  2. MYSQL_BIND 구조체의 멤버 buffer 에, 시간적인 값이 격납되고 있다 MYSQL_TIME 구조체의 주소를 설정한다.

  3. 시간적인 값의 형태에 맞추어 MYSQL_TIME 구조체의 필요한 멤버의 값을 설정한다.

mysql_bind_param() (을)를 사용해 파라미터 데이터를 스테이트먼트에 바인드 합니다.이것으로 mysql_execute() (을)를 호출할 준비가 완료합니다.

시간적인 값을 취득하는 순서는 거의 같습니다만,buffer_type 멤버에는 취득하려고 하는 값의 형태를 설정하는 점, 및 buffer 멤버에는 돌려주어지는 값을 격납한다 MYSQL_TIME 구조체의 주소를 설정하는 점이 다릅니다.mysql_execute() (을)를 호출한 후, 결과를 취득할 때까지 에,mysql_bind_results() (을)를 호출하고, 버퍼를 스테이트먼트에 바인드 합니다.

이하의 예에서는,DATE ,TIME , 및 TIMESTAMP 의 형태의 데이터를 삽입하는 방법을 나타냅니다.mysql 변수는 유효한 접속 핸들로 합니다.

MYSQL_TIME  ts;
MYSQL_BIND  bind[3];
MYSQL_STMT  *stmt;

  strmov(query, "INSERT INTO test_table(date_field, time_field,
                                        timestamp_field) VALUES(?,?,?");

  stmt= mysql_prepare(mysql, query, strlen(query)));

  /* setup input buffers for all 3 parameters */
  bind[0].buffer_type= MYSQL_TYPE_DATE;
  bind[0].buffer= (char *)&ts;
  bind[0].is_null= 0;
  bind[0].length= 0;
  ..
  bind[1]= bind[2]= bind[0];
  ..

  mysql_bind_param(stmt, bind);

  /* supply the data to be sent is the ts structure */
  ts.year= 2002;
  ts.month= 02;
  ts.day= 03;

  ts.hour= 10;
  ts.minute= 45;
  ts.second= 20;

  mysql_execute(stmt);
  ..

11.1.10. C API 스레드 함수의 설명

스레드 클라이언트를 작성하려면 , 이하의 함수를 사용할 필요가 있습니다. See 항11.1.14. 「스레드 클라이언트의 작성 방법」 .

11.1.10.1. my_init()

void my_init(void)

설명

이 함수는, 다른 MySQL 함수를 호출하기 전에, 프로그램내에서 1 회만 호출할 필요가 있습니다.MySQL 하지만 필요로 하는 몇개의 글로벌 변수를 초기화합니다.스레드세이후인 클라이언트 라이브러리를 사용하고 있는 경우, 이 함수는 현재의 스레드에 대해서 mysql_thread_init() 의 호출도 실시합니다.

mysql_init() ,mysql_server_init() , 및 mysql_connect() (은)는, 자동적으로 이 함수를 호출합니다.

반환값

없습니다.

11.1.10.2. mysql_thread_init()

my_bool mysql_thread_init(void)

설명

스레드를 작성하면, 스레드 고유의 변수를 초기화하기 위해서 이 함수를 호출할 필요가 있습니다.

my_init() 및 mysql_connect() (은)는, 자동적으로 이 함수를 호출합니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

11.1.10.3. mysql_thread_end()

void mysql_thread_end(void)

설명

mysql_thread_init() (을)를 호출하기 전에 이 함수를 호출하고,pthread_exit() 에 의해서 할당할 수 있었던 메모리를 해방할 필요가 있습니다.

주의: 이 함수는, 클라이언트 라이브러리에서는 자동적으로 불려 가지 않습니다 .메모리 리크를 피하기 위해서, 명시적으로 호출할 필요가 있습니다.

반환값

없습니다.

11.1.10.4. mysql_thread_safe()

unsigned int mysql_thread_safe(void)

설명

이 함수는, 클라이언트가 스레드세이후로서 컴파일 되었는지를 나타냅니다.

반환값

클라이언트가 스레드세이후의 경우는 1 , 그 이외의 경우는 0 .

11.1.11. C API 편입 서버 함수의 설명

어플리케이션을 짜넣어 MySQL 서버 라이브러리와 링크하는 경우, 이하로 설명하는 함수를 사용할 필요가 있습니다. See 항11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld 」 .

프로그램을,-lmysqld (이)가 아니고,-lmysqlclient (을)를 지정해 링크했을 경우, 이러한 함수는 아무것도 실행하지 않습니다.그 때문에, 코드를 변경하지 않아도, 편입 MySQL 서버 및 스탠드얼론 서버의 어느 쪽을 사용하는지를 선택할 수 있습니다.

11.1.11.1. mysql_server_init()

int mysql_server_init(int argc, char **argv, char **groups)

설명

이 함수는, 편입 서버를 사용하는 프로그램으로, 다른 MySQL 함수를 호출하기 전에,1 회만 호출한다 필요가 있습니다 .우선 짜넣어 서버를 기동해, 이 서버가 사용하는 하부조직(mysys ,InnoDB 등)을 모두 초기화합니다.이 함수를 호출하지 않았던 경우, 프로그램은 크래쉬 합니다.MySQL 에 부속의 DBUG 패키지를 사용하고 있는 경우는,MY_INIT() (을)를 호출한 후에 이 함수를 호출할 필요가 있습니다.

인수의 argc 및 argv (은)는,main() 의 인수와 닮아 있습니다.argv 의 최초의 요소는, 통상은 프로그램명이며, 무시됩니다.사용하기 쉽게 하기 위해서, 서버에 대해서 커멘드 라인 인수가 없는 경우,argc 하 0 (제로)(이)가 됩니다.mysql_server_init() (은)는 인수의 카피를 작성하므로, 그것을 호출한 다음은 argv 또는 groups (을)를 부수어도 문제 없습니다.

groups 의 NULL 그리고 종단 된 문자열의 리스트는, 옵션 설정 파일의 어느 그룹을 액티브하게 하는지를 선택합니다.See 항4.1.2. 「my.cnf 옵션 설정 파일」 . 사용하기 쉽게 하기 위해서,groups 하지만 NULL 의 경우는,[server] 및 [embedded] 그룹이 읽힙니다.

례

#include <mysql.h>
#include <stdlib.h>

static char *server_args[] = {
  "this_program",       /* this string is not used */
  "--datadir=.",
  "--key_buffer_size=32M"
};
static char *server_groups[] = {
  "embedded",
  "server",
  "this_program_SERVER",
  (char *)NULL
};

int main(void) {
  mysql_server_init(sizeof(server_args) / sizeof(char *),
                    server_args, server_groups);

  /* Use any MySQL API functions here */

  mysql_server_end();

  return EXIT_SUCCESS;
}

반환값

정상적으로 종료했을 경우는 0 .에러가 발생했을 경우는 1 .

11.1.11.2. mysql_server_end()

void mysql_server_end(void)

설명

이 함수는, 다른 MySQL 함수를 모두 호출한 후에 1 회 호출한다 필요가 있습니다 .편입 서버를 슛다운 합니다.

반환값

없습니다.

11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제

11.1.12.1. mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지

mysql_query() 의 호출이 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려줄 가능성은 있습니다.이러한 상황이 발생했을 경우, 이하의 몇개의 조건이 성립한 것을 의미합니다.

  • malloc() 하지만 이상종료(ABEND) 했다(결과 세트가 너무 컸을 경우 등)

  • 데이터를 읽어들일 수 없었다(접속에 에러가 발생했다)

  • 데이터를 돌려주지 않는 쿼리였다(INSERT ,UPDATE , 또는 DELETE (이었)였던 경우 등)

mysql_field_count() (을)를 호출하는 것에 의해서, 스테이트먼트가 하늘이 아닌 결과 세트를 생성했는지를 언제라도 조사할 수 있습니다.mysql_field_count() 하지만 0 (을)를 돌려주는 경우, 결과 세트는 하늘이며, 마지막에 실행한 쿼리는 결과를 돌려주고 있지 않습니다(INSERT 또는 DELETE 등).mysql_field_count() 하지만 0 이외의 값을 돌려주는 경우, 스테이트먼트는 하늘이 아닌 결과 세트를 돌려주고 있습니다.예에 대해서는,mysql_field_count() 함수의 설명을 참조해 주세요.

mysql_error() 또는 mysql_errno() (을)를 호출하는 것에 의해서, 에러가 발생했는지를 판정할 수 있습니다.

11.1.12.2. 쿼리로부터 취득할 수 있는 결과에는 어떠한 것이 있을까

쿼리는, 결과 세트를 돌려주는 것 외에, 이하의 정보를 제공합니다.

  • mysql_affected_rows() (은)는,INSERT ,UPDATE , 또는 DELETE (을)를 실행하는 경우, 마지막에 실행한 쿼리로 삽입, 갱신, 또는 삭제된 레코드의 수를 돌려준다.예외는,WHERE 마디를 사용하지 않고 DELETE (을)를 실행했을 경우로, 이 때는 시간을 큰폭으로 단축하기 위해서 테이블을 하늘 상태로 재작성한다.이 경우,mysql_affected_rows() (은)는 삭제된 레코드가 수라고 해 0 (을)를 돌려준다.

  •               mysql_num_rows()

(은)는 결과 세트의 레코드수를 돌려준다.mysql_store_result()

(을)를 사용하는 경우,mysql_store_result()

하지만 복귀한 직후에
              mysql_num_rows()

(을)를 호출할 수 있다.mysql_use_result()

(을)를 사용하는 경우,mysql_fetch_row()

(을)를 사용해 모든 레코드를 취득한 다음에 마셔
              mysql_num_rows()

(을)를 호출할 수 있다.

  • mysql_insert_id() (은)는,AUTO_INCREMENT 인덱스를 사용해 테이블에 레코드를 삽입한 마지막 쿼리가 생성했다 ID (을)를 돌려준다. See 항11.1.3.32. 「mysql_insert_id() 」 .

  • 일부의 쿼리(LOAD DATA INFILE ... ,INSERT INTO ... SELECT ... ,UPDATE )(은)는, 상기 이외에도 보충 정보를 제공한다.이 보충 정보는 mysql_info() (을)를 호출하는 것에 의해서 취득한다.이 함수가 돌려주는 문자열의 포맷에 대해서는,mysql_info() 의 설명을 참조하는 것.mysql_info() (은)는, 취득하는 보충 정보가 없는 경우는,NULL 포인터를 돌려준다.

11.1.12.3. 마지막에 삽입한 레코드의 일의인 ID (은)는 어떻게 취득하는 것인가

AUTO_INCREMENT 속성을 가지는 컬럼이 정의되고 있는 테이블에 레코드를 삽입하는 경우,mysql_insert_id() (을)를 호출하는 것에 의해서, 마지막에 생성되었다 ID (을)를 취득할 수 있습니다.

또,mysql_query() 에 건네주는 쿼리 문자열로 LAST_INSERT_ID() 함수를 사용하는 것에 의해서, 마지막에 생성되었다 ID (을)를 취득할 수도 있습니다.

이하의 코드를 실행하면,AUTO_INCREMENT 인덱스가 사용되었는지를 조사할 수 있습니다.이 코드는 동시에, 쿼리가 AUTO_INCREMENT 인덱스를 사용한다 INSERT (이었)였는지 아닌지도 조사합니다.

if (mysql_error(&mysql)[0] == 0 &&
    mysql_num_fields(result) == 0 &&
    mysql_insert_id(&mysql) != 0)
{
    used_id = mysql_insert_id(&mysql);
}

마지막에 생성되었다 ID (은)는, 접속 마다 서버에 보관 유지됩니다.다른 접속을 사용하는 클라이언트에 의해서 변경될 것은 없습니다.AUTO_INCREMENT 속성을 가지는 다른 컬럼을 비매직치(NULL 그렇지만 0 도 아닌 값)으로 갱신했을 경우도, 이 ID (은)는 변경되지 않습니다.

어느 테이블용으로 생성되었다 ID (을)를 다른 테이블에 삽입하려면 , 이하의 SQL 스테이트먼트를 기술합니다.

INSERT INTO foo (auto,text)
    VALUES(NULL,'text');              # generate ID by inserting NULL
INSERT INTO foo2 (id,text)
    VALUES(LAST_INSERT_ID(),'text');  # use ID in second table

11.1.12.4. C API (와)과 링크하는 경우의 문제

C API (와)과 링크하는 경우, 일부의 시스템에서는 이하의 에러가 발생할 가능성이 있습니다.

gcc -g -o client test.o -L/usr/local/lib/mysql -lmysqlclient -lsocket -lnsl

Undefined        first referenced
 symbol          in file
floor            /usr/local/lib/mysql/libmysqlclient.a(password.o)
ld: fatal: Symbol referencing errors. No output written to client

시스템으로 이 에러가 발생했을 경우, 컴파일/ 링크행의 마지막에 -lm (을)를 추가하고, 수학 라이브러리를 링크할 필요가 있습니다.

11.1.13. 클라이언트 프로그램의 빌드

스스로 작성했다 MySQL 클라이언트 또는 써드파티로부터 입수했다 MySQL 클라이언트를 컴파일 하는 경우, 링크 커멘드로 -lmysqlclient -lz 옵션을 사용해 링크할 필요가 있습니다.또, 경우에 따라서는, 라이브러리의 소재를 링커에 통지하기 위해서 -L 옵션을 지정할 필요가 있습니다.예를 들어, 라이브러리가 /usr/local/mysql/lib 에 인스톨 되고 있는 경우, 링크 커멘드로 -L/usr/local/mysql/lib -lmysqlclient -lz (을)를 기술합니다.

MySQL 헤더 파일을 사용하는 클라이언트를 컴파일 할 때, 경우에 따라서는 -I 옵션을 지정해(예를 들어 -I/usr/local/mysql/include ), 헤더 파일의 소재를 컴파일러에 통지할 필요가 있습니다.

상기의 처리를 Unix 그리고 간단하게 실행하기 위해서 mysql_config 스크립트가 준비되어 있습니다. See 항4.9.11. 「mysql_config (클라이언트를 컴파일하기 위한 컴파일 옵션의 취득)」 .

이 스크립트를 사용해 이하와 같이 지정하는 것으로,MySQL 클라이언트를 컴파일 할 수 있습니다.

CFG=/usr/local/mysql/bin/mysql_config
sh -c "gcc -o progname `$CFG --cflags` progname.c `$CFG --libs`"

sh -c (은)는,mysql_config (으)로부터의 출력을 쉘이 1 말로서 처리하지 않게 하기 위해서 필요합니다.

11.1.14. 스레드 클라이언트의 작성 방법

클라이언트 라이브러리는 거의 스레드세이후입니다.최대의 문제는,net.c 그리고 기술되고 있는 소켓으로부터 데이터를 읽어들이기 위한 써브루틴이, 세치기가 발생했을 때에 스레드세이후가 아닌 것입니다.이것은, 서버에 대한 읽기에 장시간 걸리는 경우, 그것을 중단할 수 있는 알람을 유저가 독자적으로 작성할 가능성이 있다고 하는 생각에 근거하는 사양입니다.세치기 SIGPIPE 에 대한 인터럽트 처리기를 인스톨 하는 경우는, 소켓의 처리를 스레드세이후로 할 필요가 있습니다.

버젼 4.0.16 의 신기능: 접속이 절단 되었을 때에 프로그램이 강제 종료하지 않게 하기 위해서,MySQL (은)는 최초로 mysql_server_init() ,mysql_init() , 또는 mysql_connect() (을)를 호출할 때 SIGPIPE (을)를 블록 합니다.독자적으로 SIGPIPE 에 대한 인터럽트 처리기를 작성하는 경우, 우선 mysql_server_init() (을)를 호출하고 나서, 그 핸들러를 인스톨 할 필요가 있습니다.MySQL 의 낡은 버젼에서는, 스레드세이후인 클라이언트 라이브러리에서만,mysql_init() (을)를 호출할 때마다,SIGPIPE 하지만 블록 되고 있었습니다.

당사의 Web 사이트(http://www.mysql.com/ )(으)로 배포한 낡은 바이노리필드의 경우, 클라이언트 라이브러리의 컴파일에서는 스레드세이후인 옵션을 사용하지 않는 것이 보통이었습니다(Windows 의 바이너리는 디폴트로 스레드세이후로 컴파일 됩니다).새롭게 배포하는 바이너리에서는, 스레드세이후인 클라이언트 라이브러리와 그렇지 않은 클라이언트 라이브러리의 양쪽 모두가 필요합니다.

다른 스레드로부터 끼어들거나MySQL 서버와의 통신에 타임 아웃을 설정할 수 있는 스레드 클라이언트를 작성하려면 ,-lmysys ,-lmystrings , 및 -ldbug 의 각 라이브러리, 및 서버가 사용한다 net_serv.o 코드를 사용할 필요가 있습니다.

세치기나 타임 아웃을 사용하지 않는 경우는, 스레드세이후인 클라이언트 라이브러리 (mysqlclient_r) (을)를 컴파일 해 사용하는 것만으로 끝납니다.See 항11.1. 「MySQL C API 」 . 이 경우,net_serv.o 오브젝트 파일이나 다른 MySQL 라이브러리를 사용할 필요는 없습니다.

스레드 클라이언트를 사용하면서, 타임 아웃이나 세치기도 사용하는 경우,thr_alarm.c 파일로 정의되고 있는 루틴을 활용할 수 있습니다.mysys 라이브러리의 루틴을 사용하고 있는 경우, 우선 my_init() (을)를 호출할 필요가 있습니다. See 항11.1.10. 「C API 스레드 함수의 설명」 .

mysql_real_connect() 이외의 모든 함수는, 디폴트로 스레드세이후입니다.이하에, 스레드세이후인 클라이언트 라이브러리를 컴파일 해, 스레드세이후에 사용하는 방법을 나타냅니다(mysql_real_connect() (을)를 사용한 이하의 기술은 mysql_connect() 에도와 같이 적용할 수 있습니다만,mysql_connect() (은)는 폐?~ 되었으므로, 어쨌건 간에 mysql_real_connect() (을)를 사용할 필요가 있습니다).

mysql_real_connect() (을)를 스레드세이후로 하려면 , 이하의 커멘드를 사용해 클라이언트 라이브러리를 재컴파일 할 필요가 있습니다.

shell> ./configure --enable-thread-safe-client

이 커멘드에 의해서, 스레드세이후인 클라이언트 라이브러리 libmysqlclient_r 하지만 작성됩니다(사용한다 OS 에 스레드세이후인 gethostbyname_r() 함수가 제공되고 있으면 가정).이 라이브러리는 접속 마다 스레드세이후가 됩니다.이하의 항목에 주의하면,2 개의 스레드로 같은 접속을 공유할 수 있습니다.

  • 2 개의 스레드가 같은 접속으로 동시에 MySQL 서버에 쿼리를 송신할 수 없다.특히,mysql_query() (을)를 호출하고 나서 mysql_store_result() (을0


11.5. MySQL Perl API

여기에서는,Perl DBI 인터페이스에 대해 설명합니다.이전의 인터페이스는,mysqlperl (으)로 불리고 있었습니다.DBI/ 현재는 DBD 하지만 Perl 인터페이스로서 추천 되고 있습니다.mysqlperl (은)는 폐?~ 되어 여기에서는 설명하지 않습니다.

11.5.1. DBI (와)과 DBD::mysql

DBI (은)는, 다양한 데이타베이스 전용의 범용 인터페이스입니다.이것은, 아무것도 변경하지 않아도, 복수가 다른 데이타베이스로 동작하는 스크립트를 작성할 수 있는 것을 의미합니다.데이타베이스의 종류 마다 데이타베이스 드라이버(DBD )(을)를 정의할 필요가 있습니다.MySQL 의 경우, 이 드라이버는 DBD::mysql (으)로 불립니다.

Perl5 DBI 의 상세한 것에 대하여는,DBI 의 Web 페이지에 있는 메뉴얼을 참조해 주세요.

http://dbi.perl.org/

주의: Perl 그리고 트랜잭션(transaction)를 사용하는 경우,DBD-mysql 버젼 1.2216 이?~ 하지만 필요합니다.버젼 2.1022 이?~ 하지만 추천 됩니다.

MySQL Perl 서포트의 인스톨 순서에 대해서는, 항2.7. 「Perl 인스톨에 대한 코멘트」 (을)를 참조해 주세요.

MySQL 모듈을 인스톨 하고 있는 경우, 이하의 어느 쪽인가의 커멘드를 사용하고, 특정의 MySQL 기능에 관한 정보를 입수할 수 있습니다.

shell> perldoc DBD/mysql
shell> perldoc mysql

11.5.2. DBI 인터페이스

이식 가능한 DBI 메소드 및 속성

메소드/ 속성 | 설명
connect | 데이터 베이스 서버에의 접속을 확립한다.
disconnect | 데이터 베이스 서버에의 접속을 절단 한다.
prepare | SQL 스테이트먼트를 실행하기 위한 프리컴파일을 실시한다.
execute | 프리페아드스테이트먼트를 실행한다.
do | SQL 스테이트먼트를 프리컴파일 해, 실행한다.
quote | 삽입하는 문자열 또는 BLOB 값을 인용부호로 둘러싼다.
fetchrow_array | 필드의 배열로서 다음의 레코드를 취득한다.
fetchrow_arrayref | 필드의 참조 배열로서 다음의 레코드를 취득한다.
fetchrow_hashref | 해시 테이블에의 참조로서 다음의 레코드를 취득한다.
fetchall_arrayref | 배열의 배열로서 모든 데이터를 취득한다.
finish | 스테이트먼트의 사용을 완료하고, 자원을 해방한다.
rows | 영향을 받은 레코드의 수를 돌려준다.
data_sources | localhost 그리고 사용할 수 있는 데이타베이스의 배열을 돌려준다.
ChopBlanks | fetchrow_* 메소드로 여백을 잘라낼지를 제어한다.
NUM_OF_PARAMS | 프리페아드스테이트먼트의 플레이스홀더의 수.
NULLABLE | 어느 컬럼에 NULL (을)를 격납할 수 있는지를 나타낸다.
trace | 디버그를 위해서 트레이스를 실행한다.

MySQL 고유의 메소드 및 속성

메소드/ 속성 | 설명
mysql_insertid | 최신의 AUTO_INCREMENT 값을 돌려준다.
is_blob | 어느 컬럼이 BLOB 값인지를 나타낸다.
is_key | 어느 컬럼이 키인지를 나타낸다.
is_num | 어느 컬럼이 수치인지를 나타낸다.
is_pri_key | 어느 컬럼이 주키인지를 나타낸다.
is_not_null | 어느 컬럼에 NULL (을)를 격납할 수 없는가를 나타낸다.NULLABLE (을)를 참조.
length | 확대 가능한 최대 컬럼 사이즈를 나타낸다.
max_length | 결과 세트에 실제로 존재하는 최대의 컬럼 사이즈를 나타낸다.
NAME | 컬럼명을 나타낸다.
NUM_OF_FIELDS | 결과 세트의 필드의 수.
table | 결과 세트의 테이블명을 나타낸다.
type | 모든 컬럼의 형태를 나타낸다.

Perl 의 메소드에 대해서는, 이하의 섹션으로 상세하게 설명합니다.메소드의 반환값에 사용되는 변수에는 이하의 의미가 있습니다.

  • $dbh

    데이타베이스 핸들

  • $sth

    스테이트먼트 핸들

  • $rc

    return code(통상은 스테이터스)

  • $rv

    반환값(통상은 레코드수)

이식 가능한 DBI 메소드 및 속성

  • connect($data_source, $username, $password)

    connect 메소드를 사용하고, 데이터 소스에의 데이타베이스 접속을 확립한다.$data_source 값은 DBI:driver_name: 그리고 시작될 필요가 있다.DBD::mysql 드라이버를 사용한다 connect 의 사용예를 이하에 나타낸다.

    $dbh = DBI->connect("DBI:mysql:$database", $user, $password);
$dbh = DBI->connect("DBI:mysql:$database:$hostname",
                    $user, $password);
$dbh = DBI->connect("DBI:mysql:$database:$hostname:$port",
                    $user, $password);

    유저명 또는 패스워드, 혹은 그 양쪽 모두가 미정도리의 경우,DBI (은)는 각각 DBI_USER 및 DBI_PASS 의 각 환경 변수의 값을 사용한다.호스트명을 지정하지 않는 경우,'localhost' 하지만 사용된다.포토 번호를 지정하지 않는 경우, 디폴트의 MySQL 포토(3306 )(이)가 사용된다.

    Msql-Mysql-modules 버젼 1.2009 의 시점에서는,$data_source 값에 특정의 수식자를 사용할 수 있다.

    • mysql_read_default_file=file_name

      file_name (을)를 옵션 설정 파일로서 읽어들인다.옵션 설정 파일에 대해서는, 항4.1.2. 「my.cnf 옵션 설정 파일」 (을)를 참조하는 것.

    • mysql_read_default_group=group_name

      옵션 설정 파일을 읽어들일 때의 디폴트 그룹은, 통상은 [client] 그룹이다.mysql_read_default_group 옵션을 지정하는 것에 의해서, 디폴트 그룹은 [group_name] 그룹이 된다.

    • mysql_compression=1

      클라이언트와 서버간에 압축된 통신을 사용한다(MySQL 버젼 3.22.3 이?~ ).

    • mysql_socket=/path/to/socket

      서버에의 접속에 사용한다 Unix 소켓의 패스명을 지정한다(MySQL 버젼 3.21.15 이?~ ).

    복수의 수식자를 세?~ 코론으로 단락지어 지정할 수 있다.

    예를 들어, 유저명 및 패스워드를 DBI 스크립트에 하드 코드 하는 것을 피하려면 , 이하와 같이 connect 의 호출을 기술하고, 유저의 ~/.my.cnf 옵션 설정 파일로부터 유저명 및 패스워드를 읽어들인다.

    $dbh = DBI->connect("DBI:mysql:$database"
                . ";mysql_read_default_file=$ENV{HOME}/.my.cnf",
                $user, $password);

    이 호출에 의해서, 옵션 설정 파일의 [client] 그룹에 정의된 옵션이 읽힌다.상기와 같은 처리를,[perl] 그룹으로 지정한 옵션을 사용해 실행하려면 , 이하와 같은 코드를 기술한다.

    $dbh = DBI->connect("DBI:mysql:$database"
                . ";mysql_read_default_file=$ENV{HOME}/.my.cnf"
                . ";mysql_read_default_group=perl",
                $user, $password);

  • disconnect

    disconnect 메소드는, 데이타베이스로부터 데이타베이스 핸들을 절단 한다.통상, 이 메소드는 프로그램을 종료하기 직전에 불려 간다.이하에 예를 나타낸다.

    $rc = $dbh->disconnect;

  • prepare($statement)

    SQL 스테이트먼트를, 데이타베이스로 실행할 수 있도록 프리컴파일 해, 스테이트먼트 핸들 ($sth) (을)를 돌려준다.스테이트먼트 핸들을 사용해 execute 메소드를 호출할 수 있다.

    통상,prepare 및 execute (을)를 사용해 SELECT 스테이트먼트( 및 SHOW ,DESCRIBE ,EXPLAIN 등의 SELECT 좋아하는 스테이트먼트)를 처리한다.이하에 예를 나타낸다.

    $sth = $dbh->prepare($statement)
    or die "Can't prepare $statement: $dbh->errstr\n";

    사이즈가 큰 결과 세트를 클라이언트에 읽어들이는 경우,Perl 에 mysql_use_result() (을)를 사용하도록(듯이) 지시할 수 있다.

    my $sth = $dbh->prepare($statement { "mysql_use_result" => 1});

  • execute

    execute 메소드는, 프리페아드스테이트먼트를 실행한다.비 SELECT 스테이트먼트의 경우,execute (은)는 영향을 받은 레코드의 수를 돌려준다.영향을 받은 레코드가 없는 경우,execute 하 "0E0" (을)를 돌려준다.Perl (은)는 이 반환값을 0 (으)로서 처리하지만,true (으)로 간주한다.에러가 발생했을 경우,execute 하 undef (을)를 돌려준다.SELECT 스테이트먼트의 경우,execute (은)는 데이타베이스로 SQL 쿼리를 기동하는 것만으로 있어, 데이터를 취득하려면 , 후술 한다 fetch_* 메소드안의 1 개를 사용할 필요가 있다.이하에 예를 나타낸다.

    $rv = $sth->execute
          or die "can't execute the query: " . $sth->errstr;

  • do($statement)

    do 메소드는,SQL 스테이트먼트를 프리컴파일 및 실행해, 영향을 받은 레코드수를 돌려준다.영향을 받은 레코드가 없는 경우,do 하 "0E0" (을)를 돌려준다.Perl (은)는 이 반환값을 0 (으)로서 처리하지만,true (으)로 간주한다.이 메소드는 통상, 미리 프리컴파일 할 수 없는(드라이버의 제약에 의해), 또는 여러 차례 실행할 필요가 없는(삽입, 삭제 등) 비 SELECT 스테이트먼트로 사용한다.이하에 예를 나타낸다.

    $rv = $dbh->do($statement)
        or die "Can't execute $statement: $dbh- >errstr\n";

    일반적으로,'do' 스테이트먼트는, 파라미터를 사용하지 않는 스테이트먼트를 프리컴파일 해 실행하는 것보다도, 매우 고속으로 있다(사용하는 것이 추천 된다).

  • quote($string)

    quote 메소드는, 문자열에 포함되는 특수 문자를 " 이스케이프" 하고, 인용부호로 둘러싸기 위해서 사용한다.이하에 예를 나타낸다.

    $sql = $dbh->quote($string)

  • fetchrow_array

    이 메소드는, 다음의 레코드의 데이터를 취득해, 필드치의 배열로서 돌려준다.이하에 예를 나타낸다.

    while(@row = $sth->fetchrow_array) {
        print qw($row[0]\t$row[1]\t$row[2]\n);
}

  • fetchrow_arrayref

    이 메소드는, 다음의 레코드의 데이터를 취득해, 필드치의 배열로서 돌려준다.이하에 예를 나타낸다.

    while($row_ref = $sth->fetchrow_arrayref) {
        print qw($row_ref->[0]\t$row_ref->[1]\t$row_ref->[2]\n);
}

  • fetchrow_hashref

    이 메소드는, 레코드 데이터를 취득해, 필드명과 값의 편성을 포함한 해시 테이블에의 참조를 돌려준다.이것은 전술의 배열 참조를 사용하는 경우(정도)만큼 효율적은 아니다.이하에 예를 나타낸다.

    while($hash_ref = $sth->fetchrow_hashref) {
        print qw($hash_ref->{firstname}\t$hash_ref->{lastname}\t\
                $hash_ref->{title}\n);
}

  • fetchall_arrayref

    이 메소드는,SQL 스테이트먼트가 돌려주는 모든 데이터(레코드)를 취득하기 위해서 사용한다.이 메소드는," 각 레코드에 대응하는 배열에의 참조" 의 배열에의 참조를 돌려준다.데이터에 액세스 하거나 출력하려면 , 네스트 된 루프를 사용한다.이하에 예를 나타낸다.

    my $table = $sth->fetchall_arrayref
                or die "$sth->errstr\n";
my($i, $j);
for $i ( 0 .. $#{$table} ) {
        for $j ( 0 .. $#{$table->[$i]} ) {
                print "$table->[$i][$j]\t";
        }
        print "\n";
}

  • finish

    이 스테이트먼트 핸들을 사용해 더 이상 데이터를 취득하지 않는 것을 나타내 보인다.이 메소드를 호출하는 것에 의해서, 스테이트먼트 핸들 및 거기에 관련지을 수 있었던 system resource이 모두 해방된다.이하에 예를 나타낸다.

    $rc = $sth->finish;

  • rows

    마지막에 실행된 커멘드에 의해서 영향을 받은(갱신된, 삭제된, 등) 레코드의 수를 돌려준다.통상, 비 SELECT execute 스테이트먼트의 뒤에 사용된다.이하에 예를 나타낸다.

    $rv = $sth->rows;

  • NULLABLE

    컬럼에 NULL 값을 격납할 수 있을지를 나타내는 값의 배열에의 참조를 돌려준다.각 배열 요소에 격납할 수 있는 값은, 컬럼에 NULL 값을 격납할 수 없는 경우는 0 또는 공문자열, 격납할 수 있는 경우는 1 , 컬럼의 NULL 스테이터스가 불명한 경우는 2 이다.이하에 예를 나타낸다.

    $null_possible = $sth->{NULLABLE};

  • NUM_OF_FIELDS

    이 속성은,SELECT 스테이트먼트 또는 SHOW FIELDS 스테이트먼트가 돌려준 필드의 수를 나타낸다.이것을 사용하고, 결과 세트를 돌려주는 스테이트먼트가 실행되었는지를 조사할 수 있다.값이 0 의 경우는,INSERT ,DELETE , 또는 UPDATE 등의 비 SELECT 스테이트먼트가 실행된 것을 나타내 보인다.이하에 예를 나타낸다.

    $nr_of_fields = $sth->{NUM_OF_FIELDS};

  • data_sources($driver_name)

    이 메소드는, 호스트 'localhost' 위에서 동작한다 MySQL 서버에 대해서 사용할 수 있는 데이타베이스명을 포함한 배열을 돌려준다.이하에 예를 나타낸다.

    @dbs = DBI->data_sources("mysql");

  • ChopBlanks

    이 속성은,fetchrow_* 메소드가, 돌려주어진 값의 선두 및 말미의 공백을 잘라낼지를 결정한다.이하에 예를 나타낸다.

    $sth->{'ChopBlanks'} =1;

  • trace($trace_level) , trace($trace_level, $trace_filename)

    trace 메소드는 트레이스를 유효 또는 무효로 한다.DBI 클래스 메소드로서 불려 갔을 경우는, 모든 핸들의 트레이스를 유효 또는 무효로 한다.데이타베이스 또는 스테이트먼트 핸들의 메소드로서 불려 갔을 경우는, 지정된 핸들( 및 그 핸들로부터 향후 파생하는 아이)의 트레이스를 유효 또는 무효로 한다.$trace_level (을)를 2 (으)로 설정하면, 상세한 트레이스 정보가 출력된다.$trace_level (을)를 0 (으)로 설정하면, 트레이스가 무효가 된다.트레이스 정보는, 디폴트에서는 표준 에러 출력에 출력된다.$trace_filename 하지만 지정되었을 경우, 그 파일이 추가 모드로 열려 트레이스가 유효한 모든 핸들의 트레이스 정보가 그 파일에 출력된다.이하에 예를 나타낸다.

    DBI->trace(2);                # trace everything
DBI->trace(2,"/tmp/dbi.out"); # trace everything to
                              # /tmp/dbi.out
$dth->trace(2);               # trace this database handle
$sth->trace(2);               # trace this statement handle

    또,DBI_TRACE 환경 변수를 설정하는 것에 의해서 DBI 트레이스를 유효하게 할 수 있다.이 변수에 수치를 설정하는 것은,DBI->(value) (을)를 호출하는 것으로 동등하다.이 변수에 패스명을 설정하는 것은,DBI->(2,value) (을)를 호출하는 것으로 동등하다.

MySQL 고유의 메소드 및 속성

여기에 나타내는 메소드는 MySQL 고유하고,DBI 의 표준에는 포함되지 않습니다.is_blob ,is_key ,is_num ,is_pri_key ,is_not_null ,length ,max_length ,table 등, 그 많게는 폐?~ 되고 있습니다.DBI 표준에 대체할 수 있는 메소드나 속성이 존재하는 경우는, 여기에 명기합니다.

  • mysql_insertid

    MySQL 의 AUTO_INCREMENT 기능을 사용하는 경우, 최신의 값이 여기에 격납된다.이하에 예를 나타낸다.

    $new_id = $sth->{mysql_insertid};

    낡은 버젼의 DBI 인터페이스에서는,$sth->{'insertid'} (을)를 사용할 수 있다.

  • is_blob

    불리언 값의 배열에의 참조를 돌려준다.배열의 요소가 TRUE 의 경우, 대응하는 컬럼이 BLOB 형태인 것을 나타낸다.이하에 예를 나타낸다.

    $keys = $sth->{is_blob};

  • is_key

    불리언 값의 배열에의 참조를 돌려준다.배열의 요소가 TRUE 의 경우, 대응하는 컬럼이 키인 것을 나타낸다.이하에 예를 나타낸다.

    $keys = $sth->{is_key};

  • is_num

    불리언 값의 배열에의 참조를 돌려준다.배열의 요소가 TRUE 의 경우, 대응하는 컬럼에 수치가 격납되는 것을 나타낸다.이하에 예를 나타낸다.

    $nums = $sth->{is_num};

  • is_pri_key

    불리언 값의 배열에의 참조를 돌려준다.배열의 요소가 TRUE 의 경우, 대응하는 컬럼이 주키인 것을 나타낸다.이하에 예를 나타낸다.

    $pri_keys = $sth->{is_pri_key};

  • is_not_null

    불리언 값의 배열에의 참조를 돌려준다.배열의 요소가 FALSE 의 경우, 대응하는 컬럼에 NULL 값을 격납할 수 있는 것을 나타낸다.이하에 예를 나타낸다.

    $not_nulls = $sth->{is_not_null};

    is_not_null (은)는 폐?~ 되고 있다.DBI 표준의 NULLABLE 속성(전술)을 사용하는 것이 추천 된다.

  • length , max_length

    각 메소드는, 컬럼 사이즈의 배열에의 참조를 돌려준다.length 의 배열은, 각 컬럼의(테이블 정의로의 선언에 따른) 확대 가능한 최대 사이즈를 나타낸다.max_length 의 배열은, 결과 테이블에 실제로 존재하는 데이터의 최대 사이즈를 나타낸다.이하에 예를 나타낸다.

    $lengths = $sth->{length};
$max_lengths = $sth->{max_length};

  • NAME

    컬럼명의 배열에의 참조를 돌려준다.이하에 예를 나타낸다.

    $names = $sth->{NAME};

  • table

    테이블명의 배열에의 참조를 돌려준다.이하에 예를 나타낸다.

    $tables = $sth->{table};

  • type

    컬럼의 데이터형의 배열에의 참조를 돌려준다.이하에 예를 나타낸다.

    $types = $sth->{type};

11.5.3. DBI/DBD 에 관한 그 외의 정보

perldoc 커멘드를 사용하면 DBI 의 상세 정보를 취득할 수 있습니다.

perldoc DBI
perldoc DBI::FAQ
perldoc DBD::mysql

또,pod2man ,pod2html 등의 툴을 사용하고, 다른 포맷의 데이터로 변환할 수 있습니다.

DBI 에 관한 최신 정보에 대해서는,DBI 의 Web 페이지 http://dbi.perl.org/ (을)를 참조해 주세요..


11.6. MySQL C++ API

MySQL Connector/C++ (또는 MySQL++ )(은)는,C++ 의 오피셜 MySQL API 입니다.상세한 것에 대하여는,http://www.mysql.com/products/mysql++/ (을)를 참조해 주세요.

11.6.1. Borland C++

Borland C++ 5.02 (을)를 사용해 MySQL Windows 소스를 컴파일 할 수 있습니다(Windows 소스에는,Microsoft VC++ 및 Borland C++ 용무의 프로젝트 파일 밖에 준비되어 있지 않기 때문에, 프로젝트 파일을 자작할 필요가 있습니다).

Borland C++ (을)를 사용하는 경우의 유일한 기존의 문제는,VC++ (와)과는 다른 구조체의 alignment를 사용하고 있는 것입니다.이것은, 디폴트의 libmysql.dll 라이브러리(VC++ 그리고 컴파일 되고 있다)를 Borland C++ 그리고 사용하면, 문제가 발생하는 것을 의미합니다.이하의 어느쪽이든을 실행하면, 이 문제를 회피할 수 있습니다.

  • http://www.mysql.com/downloads/os-win32.html (으)로부터 다운로드할 수 있다 Borland C++ 의 스태틱 MySQL 라이브러리를 사용한다.

  • 사전에 할당할 수 있었다 MYSQL 구조체가 아니고,NULL (을)를 인수로서 mysql_init() (을)를 호출한다.


11.7. MySQL Python API

MySQLdb (은)는,Python 향해의 MySQL 서포트를 제공하고 있어,Python DB API 버젼 2.0 에 준거하고 있습니다.상세한 것에 대하여는,http://sourceforge.net/projects/mysql-python/ (을)를 참조해 주세요.


11.8. MySQL Tcl API

MySQLtcl (은)는,Tcl 프로그램 언어로부터 MySQL 데이터 베이스 서버에 액세스하기 위한 간단한 API 입니다.상세한 것에 대하여는,http://www.xdobry.de/mysqltcl/ (을)를 참조해 주세요.


11.9. MySQL Eiffel Wrapper

Eiffel MysQL (은)는,Mychael Ravits 하지만 작성했다 Eiffel 프로그램 언어를 사용했다 MySQL 데이터 베이스 서버에의 인터페이스입니다.상세한 것에 대하여는,http://efsa.sourceforge.net/archive/ravits/mysql.htm (을)를 참조해 주세요.


제12 장 MySQL 의 에러 처리

목차

12.1. 돌려주어지는 에러

이 장에서는,MySQL 의 에러 처리에 대해 설명합니다.

12.1. 돌려주어지는 에러

임의의 호스트 언어로 MySQL (을)를 호출했을 때에 발생할 가능성이 있는 에러 코드의 리스트를 이하에 나타냅니다.

이름 및 에러 코드 의 열은,MySQL 원시 코드 파일 include/mysqld_error.h 의 정의에 대응합니다.

SQLSTATE 의 열은,MySQL 원시 코드 파일 include/sql_state.h 의 정의에 대응합니다.

SQLSTATE 에러 코드는,MySQL 버젼 4.1 (을)를 사용하는 경우에게만 표시됩니다.SQLSTATE (은)는,X/Open/ANSI/ODBC 의 동작과 호환성을 갖게하기 위해서 추가되었습니다.

각 에러 코드에 대한 설명 텍스트는, 에러 메세지 파일 share/english/errmsg.sys 에 기술되고 있습니다.

갱신은 빈번히 행해지므로, 상기의 소스에 에러 코드가 추가될 가능성이 있습니다.

  • Error: 1000 SQLSTATE: HY000 (ER_HASHCHK)

    Message: hashchk

  • Error: 1001 SQLSTATE: HY000 (ER_NISAMCHK)

    Message: isamchk

  • Error: 1002 SQLSTATE: HY000 (ER_NO)

    Message: NO

  • Error: 1003 SQLSTATE: HY000 (ER_YES)

    Message: YES

  • Error: 1004 SQLSTATE: HY000 (ER_CANT_CREATE_FILE)

    Message: '%s' 파일을 만들 수 없습니다 (errno: %d)

  • Error: 1005 SQLSTATE: HY000 (ER_CANT_CREATE_TABLE)

    Message: '%s' 테이블을 만들 수 없습니다.(errno: %d)

  • Error: 1006 SQLSTATE: HY000 (ER_CANT_CREATE_DB)

    Message: '%s' 데이타베이스를 만들 수 없습니다 (errno: %d)

  • Error: 1007 SQLSTATE: HY000 (ER_DB_CREATE_EXISTS)

    Message: '%s' 데이타베이스를 만들 수 없습니다. 이미 그 데이타베이스가 존재합니다

  • Error: 1008 SQLSTATE: HY000 (ER_DB_DROP_EXISTS)

    Message: '%s' 데이타베이스를 파기할 수 없습니다. 그 데이타베이스가 없습니다.

  • Error: 1009 SQLSTATE: HY000 (ER_DB_DROP_DELETE)

    Message: 데이타베이스 파기 에러 ('%s' (을)를 삭제할 수 없습니다, errno: %d)

  • Error: 1010 SQLSTATE: HY000 (ER_DB_DROP_RMDIR)

    Message: 데이타베이스 파기 에러 ('%s' (을)를 rmdir 할 수 없습니다, errno: %d)

  • Error: 1011 SQLSTATE: HY000 (ER_CANT_DELETE_FILE)

    Message: '%s' 의 삭제가 에러 (errno: %d)

  • Error: 1012 SQLSTATE: HY000 (ER_CANT_FIND_SYSTEM_REC)

    Message: system table 의 레코드를 읽을 수가 없었습니다

  • Error: 1013 SQLSTATE: HY000 (ER_CANT_GET_STAT)

    Message: '%s' 의 스테이터스를 얻을 수 없습니다. (errno: %d)

  • Error: 1014 SQLSTATE: HY000 (ER_CANT_GET_WD)

    Message: working directory (을)를 얻을 수가 없었습니다 (errno: %d)

  • Error: 1015 SQLSTATE: HY000 (ER_CANT_LOCK)

    Message: 파일을 잠글 수 없습니다 (errno: %d)

  • Error: 1016 SQLSTATE: HY000 (ER_CANT_OPEN_FILE)

    Message: '%s' 파일을 열 수가 없습니다 (errno: %d)

  • Error: 1017 SQLSTATE: HY000 (ER_FILE_NOT_FOUND)

    Message: '%s' 파일을 찾아낼 수가 없습니다.(errno: %d)

  • Error: 1018 SQLSTATE: HY000 (ER_CANT_READ_DIR)

    Message: '%s' 디렉토리를 읽을 수 없습니다.(errno: %d)

  • Error: 1019 SQLSTATE: HY000 (ER_CANT_SET_WD)

    Message: '%s' 디렉토리에 chdir 할 수 없습니다.(errno: %d)

  • Error: 1020 SQLSTATE: HY000 (ER_CHECKREAD)

    Message: Record has changed since last read in table '%s'

  • Error: 1021 SQLSTATE: HY000 (ER_DISK_FULL)

    Message: Disk full (%s). 누군가가 무엇인가를 줄일 때까지 기다려 주세요...

  • Error: 1022 SQLSTATE: 23000 (ER_DUP_KEY)

    Message: table '%s' 에 key 하지만 중복 하고 있어 쓸 수 없습니다

  • Error: 1023 SQLSTATE: HY000 (ER_ERROR_ON_CLOSE)

    Message: Error on close of '%s' (errno: %d)

  • Error: 1024 SQLSTATE: HY000 (ER_ERROR_ON_READ)

    Message: '%s' 파일의 read error (errno: %d)

  • Error: 1025 SQLSTATE: HY000 (ER_ERROR_ON_RENAME)

    Message: '%s' (을)를 '%s' 에 rename 할 수 없습니다 (errno: %d)

  • Error: 1026 SQLSTATE: HY000 (ER_ERROR_ON_WRITE)

    Message: '%s' 파일을 쓸 수가 없습니다 (errno: %d)

  • Error: 1027 SQLSTATE: HY000 (ER_FILE_USED)

    Message: '%s' (은)는 락 되고 있습니다

  • Error: 1028 SQLSTATE: HY000 (ER_FILSORT_ABORT)

    Message: Sort 중단

  • Error: 1029 SQLSTATE: HY000 (ER_FORM_NOT_FOUND)

    Message: View '%s' 하지만 '%s' 에 정의되고 있지 않습니다

  • Error: 1030 SQLSTATE: HY000 (ER_GET_ERRNO)

    Message: Got error %d from table handler

  • Error: 1031 SQLSTATE: HY000 (ER_ILLEGAL_HA)

    Message: Table handler for '%s' doesn't have this option

  • Error: 1032 SQLSTATE: HY000 (ER_KEY_NOT_FOUND)

    Message: '%s' 속에 레코드가 발견되지 않습니다

  • Error: 1033 SQLSTATE: HY000 (ER_NOT_FORM_FILE)

    Message: 파일 '%s' 의 info 하지만 잘못되어 있는 것 같습니다

  • Error: 1034 SQLSTATE: HY000 (ER_NOT_KEYFILE)

    Message: '%s' 테이블의 key file 하지만 잘못되어 있는 것 같습니다. 수복을 해 주세요

  • Error: 1035 SQLSTATE: HY000 (ER_OLD_KEYFILE)

    Message: '%s' 테이블은 낡은 형식의 key file 의 같습니다; 수복을 해 주세요

  • Error: 1036 SQLSTATE: HY000 (ER_OPEN_AS_READONLY)

    Message: '%s' (은)는 읽기 전용입니다

  • Error: 1037 SQLSTATE: HY001 (ER_OUTOFMEMORY)

    Message: Out of memory. demon를 restart 해 보세요 (%d bytes 필요)

  • Error: 1038 SQLSTATE: HY001 (ER_OUT_OF_SORTMEMORY)

    Message: Out of sort memory. sort buffer size 하지만 부족한 것 같습니다.

  • Error: 1039 SQLSTATE: HY000 (ER_UNEXPECTED_EOF)

    Message: '%s' 파일을 읽어들여 안에 EOF 하지만 예기치 못한 곳에서 나타났습니다. (errno: %d)

  • Error: 1040 SQLSTATE: 08004 (ER_CON_COUNT_ERROR)

    Message: 접속이 너무 많습니다

  • Error: 1041 SQLSTATE: HY000 (ER_OUT_OF_RESOURCES)

    Message: Out of memory; mysqld 과소의 다른 프로세스가 메모리를 모두 사용하고 있든가 확인해 주세요. 메모리를 다 사용하지 않은 경우,'ulimit' (을)를 설정해 mysqld 의 메모리 사용 한계량을 많이 하는지,swap space (을)를 늘려 보세요

  • Error: 1042 SQLSTATE: 08S01 (ER_BAD_HOST_ERROR)

    Message: 그 address 의 hostname 하지만 파하지 않습니다.

  • Error: 1043 SQLSTATE: 08S01 (ER_HANDSHAKE_ERROR)

    Message: Bad handshake

  • Error: 1044 SQLSTATE: 42000 (ER_DBACCESS_DENIED_ERROR)

    Message: 유저 '%s'@'%s' 의 '%s' 데이타베이스에의 액세스를 거부합니다

  • Error: 1045 SQLSTATE: 28000 (ER_ACCESS_DENIED_ERROR)

    Message: 유저 '%s'@'%s' (을)를 거부합니다.uUsing password: %s)

  • Error: 1046 SQLSTATE: 3D000 (ER_NO_DB_ERROR)

    Message: 데이타베이스가 선택되고 있지 않습니다.

  • Error: 1047 SQLSTATE: 08S01 (ER_UNKNOWN_COM_ERROR)

    Message: 그 커멘드는 뭐야?

  • Error: 1048 SQLSTATE: 23000 (ER_BAD_NULL_ERROR)

    Message: Column '%s' 하 null 에는 할 수 없습니다

  • Error: 1049 SQLSTATE: 42000 (ER_BAD_DB_ERROR)

    Message: '%s' 정말 데이타베이스는 모릅니다.

  • Error: 1050 SQLSTATE: 42S01 (ER_TABLE_EXISTS_ERROR)

    Message: Table '%s' (은)는 이미 있습니다

  • Error: 1051 SQLSTATE: 42S02 (ER_BAD_TABLE_ERROR)

    Message: table '%s' (은)는 없습니다.

  • Error: 1052 SQLSTATE: 23000 (ER_NON_UNIQ_ERROR)

    Message: Column: '%s' in %s is ambiguous

  • Error: 1053 SQLSTATE: 08S01 (ER_SERVER_SHUTDOWN)

    Message: Server (을)를 shutdown 중...

  • Error: 1054 SQLSTATE: 42S22 (ER_BAD_FIELD_ERROR)

    Message: '%s' column 하 '%s' 에는 없습니다.

  • Error: 1055 SQLSTATE: 42000 (ER_WRONG_FIELD_WITH_GROUP)

    Message: '%s' isn't in GROUP BY

  • Error: 1056 SQLSTATE: 42000 (ER_WRONG_GROUP_FIELD)

    Message: Can't group on '%s'

  • Error: 1057 SQLSTATE: 42000 (ER_WRONG_SUM_SELECT)

    Message: Statement has sum functions and columns in same statement

  • Error: 1058 SQLSTATE: 21S01 (ER_WRONG_VALUE_COUNT)

    Message: Column count doesn't match value count

  • Error: 1059 SQLSTATE: 42000 (ER_TOO_LONG_IDENT)

    Message: Identifier name '%s' (은)는 너무 깁니다

  • Error: 1060 SQLSTATE: 42S21 (ER_DUP_FIELDNAME)

    Message: '%s' 그렇다고 한다 column 이름은 중복 하고 있습니다

  • Error: 1061 SQLSTATE: 42000 (ER_DUP_KEYNAME)

    Message: '%s' 그렇다고 한다 key 의 이름은 중복 하고 있습니다

  • Error: 1062 SQLSTATE: 23000 (ER_DUP_ENTRY)

    Message: '%s' 하 key %d 에 두어 중복 하고 있습니다

  • Error: 1063 SQLSTATE: 42000 (ER_WRONG_FIELD_SPEC)

    Message: Incorrect column specifier for column '%s'

  • Error: 1064 SQLSTATE: 42000 (ER_PARSE_ERROR)

    Message: %s : '%s' 부근 : %d 행목

  • Error: 1065 SQLSTATE: HY000 (ER_EMPTY_QUERY)

    Message: Query 하지만 하늘입니다.

  • Error: 1066 SQLSTATE: 42000 (ER_NONUNIQ_TABLE)

    Message: '%s' (은)는 일의의 table/alias 이름이 아닙니다

  • Error: 1067 SQLSTATE: 42000 (ER_INVALID_DEFAULT)

    Message: Invalid default value for '%s'

  • Error: 1068 SQLSTATE: 42000 (ER_MULTIPLE_PRI_KEY)

    Message: 복수의 primary key 하지만 정의되었습니다

  • Error: 1069 SQLSTATE: 42000 (ER_TOO_MANY_KEYS)

    Message: key 의 지정이 너무 많습니다. key (은)는 최대 %d 까지입니다

  • Error: 1070 SQLSTATE: 42000 (ER_TOO_MANY_KEY_PARTS)

    Message: Too many key parts specified; max %d parts allowed

  • Error: 1071 SQLSTATE: 42000 (ER_TOO_LONG_KEY)

    Message: key 하지만 너무 깁니다. key 의 길이는 최대 %d 입니다

  • Error: 1072 SQLSTATE: 42000 (ER_KEY_COLUMN_DOES_NOT_EXITS)

    Message: Key column '%s' 하지만 테이블에 없습니다.

  • Error: 1073 SQLSTATE: 42000 (ER_BLOB_USED_AS_KEY)

    Message: BLOB column '%s' can't be used in key specification with the used table type

  • Error: 1074 SQLSTATE: 42000 (ER_TOO_BIG_FIELDLENGTH)

    Message: column '%s' 하, 확보한다 column 의 크기가 너무 많습니다. ( 최대 %d 까지). BLOB (을)를 대신에 사용해 주세요.

  • Error: 1075 SQLSTATE: 42000 (ER_WRONG_AUTO_KEY)

    Message: 테이블의 정의가 다릅니다; there can be only one auto column and it must be defined as a key

  • Error: 1076 SQLSTATE: HY000 (ER_READY)

    Message: %s: 준비 완료

  • Error: 1077 SQLSTATE: HY000 (ER_NORMAL_SHUTDOWN)

    Message: %s: Normal shutdown

  • Error: 1078 SQLSTATE: HY000 (ER_GOT_SIGNAL)

    Message: %s: Got signal %d. 중단!

  • Error: 1079 SQLSTATE: HY000 (ER_SHUTDOWN_COMPLETE)

    Message: %s: Shutdown 완료

  • Error: 1080 SQLSTATE: 08S01 (ER_FORCING_CLOSE)

    Message: %s: 스레드 %ld 강제 종료 user: '%s'

  • Error: 1081 SQLSTATE: 08S01 (ER_IPSOCK_ERROR)

    Message: IP socket 하지만 만들 수 없습니다

  • Error: 1082 SQLSTATE: 42S12 (ER_NO_SUCH_INDEX)

    Message: Table '%s' (은)는 그러한 index (을)를 가지고 있지 않습니다(CREATE INDEX 실행시로 지정되어 있지 않습니다). 테이블을 다시 만들어 주세요

  • Error: 1083 SQLSTATE: 42000 (ER_WRONG_FIELD_TERMINATORS)

    Message: Field separator argument is not what is expected; check the manual

  • Error: 1084 SQLSTATE: 42000 (ER_BLOBS_AND_NO_TERMINATED)

    Message: You can't use fixed rowlength with BLOBs; please use 'fields terminated by'.

  • Error: 1085 SQLSTATE: HY000 (ER_TEXTFILE_NOT_READABLE)

    Message: 파일 '%s' 하 databse 의 directory 에 있을까 모든 유저가 읽을 수 있도록(듯이) 허가되어 있지 않으면 안됩니다.

  • Error: 1086 SQLSTATE: HY000 (ER_FILE_EXISTS_ERROR)

    Message: File '%s' (은)는 이미 존재합니다

  • Error: 1087 SQLSTATE: HY000 (ER_LOAD_INFO)

    Message: 레코드수: %ld 삭제: %ld Skipped: %ld Warnings: %ld

  • Error: 1088 SQLSTATE: HY000 (ER_ALTER_INFO)

    Message: 레코드수: %ld 중복: %ld

  • Error: 1089 SQLSTATE: HY000 (ER_WRONG_SUB_KEY)

    Message: Incorrect sub part key; the used key part isn't a string or the used length is longer than the key part

  • Error: 1090 SQLSTATE: 42000 (ER_CANT_REMOVE_ALL_FIELDS)

    Message: ALTER TABLE 그리고 모든 column (은)는 삭제할 수 없습니다. DROP TABLE (을)를 사용해 주세요

  • Error: 1091 SQLSTATE: 42000 (ER_CANT_DROP_FIELD_OR_KEY)

    Message: '%s' (을)를 파기할 수 없었습니다; check that column/key exists

  • Error: 1092 SQLSTATE: HY000 (ER_INSERT_INFO)

    Message: 레코드수: %ld 중복수: %ld Warnings: %ld

  • Error: 1093 SQLSTATE: HY000 (ER_UPDATE_TABLE_USED)

    Message: You can't specify target table '%s' for update in FROM clause

  • Error: 1094 SQLSTATE: HY000 (ER_NO_SUCH_THREAD)

    Message: thread id: %lu (은)는 없습니다

  • Error: 1095 SQLSTATE: HY000 (ER_KILL_DENIED_ERROR)

    Message: thread %lu 의 오너가 아닙니다

  • Error: 1096 SQLSTATE: HY000 (ER_NO_TABLES_USED)

    Message: No tables used

  • Error: 1097 SQLSTATE: HY000 (ER_TOO_BIG_SET)

    Message: Too many strings for column %s and SET

  • Error: 1098 SQLSTATE: HY000 (ER_NO_UNIQUE_LOGFILE)

    Message: Can't generate a unique log-filename %s.(1-999)

  • Error: 1099 SQLSTATE: HY000 (ER_TABLE_NOT_LOCKED_FOR_WRITE)

    Message: Table '%s' 하 READ lock (이)가 되어 있고, 갱신은 할 수 없습니다

  • Error: 1100 SQLSTATE: HY000 (ER_TABLE_NOT_LOCKED)

    Message: Table '%s' 하 LOCK TABLES 에 의해서 락 되고 있지 않습니다

  • Error: 1101 SQLSTATE: 42000 (ER_BLOB_CANT_HAVE_DEFAULT)

    Message: BLOB column '%s' can't have a default value

  • Error: 1102 SQLSTATE: 42000 (ER_WRONG_DB_NAME)

    Message: 지정했다 database 명 '%s' 하지만 잘못되어 있습니다

  • Error: 1103 SQLSTATE: 42000 (ER_WRONG_TABLE_NAME)

    Message: 지정했다 table 명 '%s' (은)는 잘못되어 있습니다

  • Error: 1104 SQLSTATE: 42000 (ER_TOO_BIG_SELECT)

    Message: The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay

  • Error: 1105 SQLSTATE: HY000 (ER_UNKNOWN_ERROR)

    Message: Unknown error

  • Error: 1106 SQLSTATE: 42000 (ER_UNKNOWN_PROCEDURE)

    Message: Unknown procedure '%s'

  • Error: 1107 SQLSTATE: 42000 (ER_WRONG_PARAMCOUNT_TO_PROCEDURE)

    Message: Incorrect parameter count to procedure '%s'

  • Error: 1108 SQLSTATE: HY000 (ER_WRONG_PARAMETERS_TO_PROCEDURE)

    Message: Incorrect parameters to procedure '%s'

  • Error: 1109 SQLSTATE: 42S02 (ER_UNKNOWN_TABLE)

    Message: Unknown table '%s' in %s

  • Error: 1110 SQLSTATE: 42000 (ER_FIELD_SPECIFIED_TWICE)

    Message: Column '%s' specified twice

  • Error: 1111 SQLSTATE: HY000 (ER_INVALID_GROUP_FUNC_USE)

    Message: Invalid use of group function

  • Error: 1112 SQLSTATE: 42000 (ER_UNSUPPORTED_EXTENSION)

    Message: Table '%s' uses an extension that doesn't exist in this MySQL version

  • Error: 1113 SQLSTATE: 42000 (ER_TABLE_MUST_HAVE_COLUMNS)

    Message: 테이블은 최저 1 개의 column 하지만 필요합니다

  • Error: 1114 SQLSTATE: HY000 (ER_RECORD_FILE_FULL)

    Message: table '%s' (은)는 가득합니다

  • Error: 1115 SQLSTATE: 42000 (ER_UNKNOWN_CHARACTER_SET)

    Message: character set '%s' (은)는 서포트하고 있지 않습니다

  • Error: 1116 SQLSTATE: HY000 (ER_TOO_MANY_TABLES)

    Message: 테이블이 너무 많습니다; MySQL can only use %d tables in a join

  • Error: 1117 SQLSTATE: HY000 (ER_TOO_MANY_FIELDS)

    Message: column 하지만 너무 많습니다

  • Error: 1118 SQLSTATE: 42000 (ER_TOO_BIG_ROWSIZE)

    Message: row size 하지만 너무 큽니다. BLOB (을)를 포함하지 않는 경우의 row size 의 최대는 %d 입니다. 몇개의 field (을)를 BLOB 에 바꾸어 주세요.

  • Error: 1119 SQLSTATE: HY000 (ER_STACK_OVERRUN)

    Message: Thread stack overrun: Used: %ld of a %ld stack. 스택 영역을 많이 취하고 싶은 경우,'mysqld -O thread_stack=#' (와)과 지정해 주세요

  • Error: 1120 SQLSTATE: 42000 (ER_WRONG_OUTER_JOIN)

    Message: Cross dependency found in OUTER JOIN; examine your ON conditions

  • Error: 1121 SQLSTATE: 42000 (ER_NULL_COLUMN_IN_INDEX)

    Message: Column '%s' 하지만 UNIQUE 인가 INDEX 그리고 사용되었습니다. 이 컬럼은 NOT NULL (이)라고 정의되고 있지 않습니다.

  • Error: 1122 SQLSTATE: HY000 (ER_CANT_FIND_UDF)

    Message: function '%s' (을)를 로드할 수 없습니다

  • Error: 1123 SQLSTATE: HY000 (ER_CANT_INITIALIZE_UDF)

    Message: function '%s' (을)를 초기화할 수 없습니다; %s

  • Error: 1124 SQLSTATE: HY000 (ER_UDF_NO_PATHS)

    Message: shared library 에의 패스가 다니고 있지 않습니다

  • Error: 1125 SQLSTATE: HY000 (ER_UDF_EXISTS)

    Message: Function '%s' (은)는 이미 정의되고 있습니다

  • Error: 1126 SQLSTATE: HY000 (ER_CANT_OPEN_LIBRARY)

    Message: shared library '%s' (을)를 열 수가 없습니다 (errno: %d %s)

  • Error: 1127 SQLSTATE: HY000 (ER_CANT_FIND_DL_ENTRY)

    Message: function '%s' (을)를 라이브러리안에 찾아낼 수가 없습니다

  • Error: 1128 SQLSTATE: HY000 (ER_FUNCTION_NOT_DEFINED)

    Message: Function '%s' (은)는 정의되고 있지 않습니다

  • Error: 1129 SQLSTATE: HY000 (ER_HOST_IS_BLOCKED)

    Message: Host '%s' 하 many connection error 때문에, 거부되었습니다. 'mysqladmin flush-hosts' 그리고 해제해 주세요

  • Error: 1130 SQLSTATE: HY000 (ER_HOST_NOT_PRIVILEGED)

    Message: Host '%s' 하 MySQL server 에 접속이 허가되고 있지 않습니다

  • Error: 1131 SQLSTATE: 42000 (ER_PASSWORD_ANONYMOUS_USER)

    Message: MySQL (을)를 anonymous users 그리고 사용하고 있는 상태에서는, 패스워드의 변경은 할 수 없습니다

  • Error: 1132 SQLSTATE: 42000 (ER_PASSWORD_NOT_ALLOWED)

    Message: 다른 유저의 패스워드를 변경하기 위해서는, mysql 데이타베이스에 대해서 update 의 허가가 없으면 안됩니다.

  • Error: 1133 SQLSTATE: 42000 (ER_PASSWORD_NO_MATCH)

    Message: Can't find any matching row in the user table

  • Error: 1134 SQLSTATE: HY000 (ER_UPDATE_INFO)

    Message: 일치수(Rows matched): %ld 변경: %ld Warnings: %ld

  • Error: 1135 SQLSTATE: HY000 (ER_CANT_CREATE_THREAD)

    Message: 신규에 스레드를 만들 수 없었습니다 (errno %d). 만약 최대 사용 허가 메모리수를 넘지 않았는데 에러가 발생하고 있다면, 메뉴얼중에서 'possible OS-dependent bug' 그렇다고 하는 문자를 찾아 쌍이라고다 차이.

  • Error: 1136 SQLSTATE: 21S01 (ER_WRONG_VALUE_COUNT_ON_ROW)

    Message: Column count doesn't match value count at row %ld

  • Error: 1137 SQLSTATE: HY000 (ER_CANT_REOPEN_TABLE)

    Message: Can't reopen table: '%s'

  • Error: 1138 SQLSTATE: 42000 (ER_INVALID_USE_OF_NULL)

    Message: NULL 값의 사용 방법이 부적절합니다

  • Error: 1139 SQLSTATE: 42000 (ER_REGEXP_ERROR)

    Message: Got error '%s' from regexp

  • Error: 1140 SQLSTATE: 42000 (ER_MIX_OF_GROUP_FUNC_AND_FIELDS)

    Message: Mixing of GROUP columns (MIN(),MAX(),COUNT(),...) with no GROUP columns is illegal if there is no GROUP BY clause

  • Error: 1141 SQLSTATE: 42000 (ER_NONEXISTING_GRANT)

    Message: 유저 '%s' ( 호스트 '%s' 의 유저) (은)는 허가되고 있지 않습니다

  • Error: 1142 SQLSTATE: 42000 (ER_TABLEACCESS_DENIED_ERROR)

    Message: 커멘드 %s 하 유저 '%s'@'%s' , 테이블 '%s' 에 대해서 허가되고 있지 않습니다

  • Error: 1143 SQLSTATE: 42000 (ER_COLUMNACCESS_DENIED_ERROR)

    Message: 커멘드 %s 하 유저 '%s'@'%s' 컬럼 '%s' 테이블 '%s' 에 대해서 허가되고 있지 않습니다

  • Error: 1144 SQLSTATE: 42000 (ER_ILLEGAL_GRANT_FOR_TABLE)

    Message: Illegal GRANT/REVOKE command; please consult the manual to see which privleges can be used.

  • Error: 1145 SQLSTATE: 42000 (ER_GRANT_WRONG_HOST_OR_USER)

    Message: The host or user argument to GRANT is too long

  • Error: 1146 SQLSTATE: 42S02 (ER_NO_SUCH_TABLE)

    Message: Table '%s.%s' doesn't exist

  • Error: 1147 SQLSTATE: 42000 (ER_NONEXISTING_TABLE_GRANT)

    Message: There is no such grant defined for user '%s' on host '%s' on table '%s'

  • Error: 1148 SQLSTATE: 42000 (ER_NOT_ALLOWED_COMMAND)

    Message: The used command is not allowed with this MySQL version

  • Error: 1149 SQLSTATE: 42000 (ER_SYNTAX_ERROR)

    Message: Something is wrong in your syntax

  • Error: 1150 SQLSTATE: HY000 (ER_DELAYED_CANT_CHANGE_LOCK)

    Message: Delayed insert thread couldn't get requested lock for table %s

  • Error: 1151 SQLSTATE: HY000 (ER_TOO_MANY_DELAYED_THREADS)

    Message: Too many delayed threads in use

  • Error: 1152 SQLSTATE: 08S01 (ER_ABORTING_CONNECTION)

    Message: Aborted connection %ld to db: '%s' user: '%s' (%s)

  • Error: 1153 SQLSTATE: 08S01 (ER_NET_PACKET_TOO_LARGE)

    Message: Got a packet bigger than 'max_allowed_packet' bytes

  • Error: 1154 SQLSTATE: 08S01 (ER_NET_READ_ERROR_FROM_PIPE)

    Message: Got a read error from the connection pipe

  • Error: 1155 SQLSTATE: 08S01 (ER_NET_FCNTL_ERROR)

    Message: Got an error from fcntl()

  • Error: 1156 SQLSTATE: 08S01 (ER_NET_PACKETS_OUT_OF_ORDER)

    Message: Got packets out of order

  • Error: 1157 SQLSTATE: 08S01 (ER_NET_UNCOMPRESS_ERROR)

    Message: Couldn't uncompress communication packet

  • Error: 1158 SQLSTATE: 08S01 (ER_NET_READ_ERROR)

    Message: Got an error reading communication packets

  • Error: 1159 SQLSTATE: 08S01 (ER_NET_READ_INTERRUPTED)

    Message: Got timeout reading communication packets

  • Error: 1160 SQLSTATE: 08S01 (ER_NET_ERROR_ON_WRITE)

    Message: Got an error writing communication packets

  • Error: 1161 SQLSTATE: 08S01 (ER_NET_WRITE_INTERRUPTED)

    Message: Got timeout writing communication packets

  • Error: 1162 SQLSTATE: 42000 (ER_TOO_LONG_STRING)

    Message: Result string is longer than 'max_allowed_packet' bytes

  • Error: 1163 SQLSTATE: 42000 (ER_TABLE_CANT_HANDLE_BLOB)

    Message: The used table type doesn't support BLOB/TEXT columns

  • Error: 1164 SQLSTATE: 42000 (ER_TABLE_CANT_HANDLE_AUTO_INCREMENT)

    Message: The used table type doesn't support AUTO_INCREMENT columns

  • Error: 1165 SQLSTATE: HY000 (ER_DELAYED_INSERT_TABLE_LOCKED)

    Message: INSERT DELAYED can't be used with table '%s', because it is locked with LOCK TABLES

  • Error: 1166 SQLSTATE: 42000 (ER_WRONG_COLUMN_NAME)

    Message: Incorrect column name '%s'

  • Error: 1167 SQLSTATE: 42000 (ER_WRONG_KEY_COLUMN)

    Message: The used table handler can't index column '%s'

  • Error: 1168 SQLSTATE: HY000 (ER_WRONG_MRG_TABLE)

    Message: All tables in the MERGE table are not defined identically

  • Error: 1169 SQLSTATE: 23000 (ER_DUP_UNIQUE)

    Message: Can't write, because of unique constraint, to table '%s'

  • Error: 1170 SQLSTATE: 42000 (ER_BLOB_KEY_WITHOUT_LENGTH)

    Message: BLOB column '%s' used in key specification without a key length

  • Error: 1171 SQLSTATE: 42000 (ER_PRIMARY_CANT_HAVE_NULL)

    Message: All parts of a PRIMARY KEY must be NOT NULL; if you need NULL in a key, use UNIQUE instead

  • Error: 1172 SQLSTATE: 42000 (ER_TOO_MANY_ROWS)

    Message: Result consisted of more than one row

  • Error: 1173 SQLSTATE: 42000 (ER_REQUIRES_PRIMARY_KEY)

    Message: This table type requires a primary key

  • Error: 1174 SQLSTATE: HY000 (ER_NO_RAID_COMPILED)

    Message: This version of MySQL is not compiled with RAID support

  • Error: 1175 SQLSTATE: HY000 (ER_UPDATE_WITHOUT_KEY_IN_SAFE_MODE)

    Message: You are using safe update mode and you tried to update a table without a WHERE that uses a KEY column

  • Error: 1176 SQLSTATE: HY000 (ER_KEY_DOES_NOT_EXITS)

    Message: Key '%s' doesn't exist in table '%s'

  • Error: 1177 SQLSTATE: 42000 (ER_CHECK_NO_SUCH_TABLE)

    Message: Can't open table

  • Error: 1178 SQLSTATE: 42000 (ER_CHECK_NOT_IMPLEMENTED)

    Message: The handler for the table doesn't support %s

  • Error: 1179 SQLSTATE: 25000 (ER_CANT_DO_THIS_DURING_AN_TRANSACTION)

    Message: You are not allowed to execute this command in a transaction

  • Error: 1180 SQLSTATE: HY000 (ER_ERROR_DURING_COMMIT)

    Message: Got error %d during COMMIT

  • Error: 1181 SQLSTATE: HY000 (ER_ERROR_DURING_ROLLBACK)

    Message: Got error %d during ROLLBACK

  • Error: 1182 SQLSTATE: HY000 (ER_ERROR_DURING_FLUSH_LOGS)

    Message: Got error %d during FLUSH_LOGS

  • Error: 1183 SQLSTATE: HY000 (ER_ERROR_DURING_CHECKPOINT)

    Message: Got error %d during CHECKPOINT

  • Error: 1184 SQLSTATE: 08S01 (ER_NEW_ABORTING_CONNECTION)

    Message: Aborted connection %ld to db: '%s' user: '%s' host: `%s' (%s)

  • Error: 1185 SQLSTATE: HY000 (ER_DUMP_NOT_IMPLEMENTED)

    Message: The handler for the table does not support binary table dump

  • Error: 1186 SQLSTATE: HY000 (ER_FLUSH_MASTER_BINLOG_CLOSED)

    Message: Binlog closed while trying to FLUSH MASTER

  • Error: 1187 SQLSTATE: HY000 (ER_INDEX_REBUILD)

    Message: Failed rebuilding the index of dumped table '%s'

  • Error: 1188 SQLSTATE: HY000 (ER_MASTER)

    Message: Error from master: '%s'

  • Error: 1189 SQLSTATE: 08S01 (ER_MASTER_NET_READ)

    Message: Net error reading from master

  • Error: 1190 SQLSTATE: 08S01 (ER_MASTER_NET_WRITE)

    Message: Net error writing to master

  • Error: 1191 SQLSTATE: HY000 (ER_FT_MATCHING_KEY_NOT_FOUND)

    Message: Can't find FULLTEXT index matching the column list

  • Error: 1192 SQLSTATE: HY000 (ER_LOCK_OR_ACTIVE_TRANSACTION)

    Message: Can't execute the given command because you have active locked tables or an active transaction

  • Error: 1193 SQLSTATE: HY000 (ER_UNKNOWN_SYSTEM_VARIABLE)

    Message: Unknown system variable '%s'

  • Error: 1194 SQLSTATE: HY000 (ER_CRASHED_ON_USAGE)

    Message: Table '%s' is marked as crashed and should be repaired

  • Error: 1195 SQLSTATE: HY000 (ER_CRASHED_ON_REPAIR)

    Message: Table '%s' is marked as crashed and last (automatic?) repair failed

  • Error: 1196 SQLSTATE: HY000 (ER_WARNING_NOT_COMPLETE_ROLLBACK)

    Message: Some non-transactional changed tables couldn't be rolled back

  • Error: 1197 SQLSTATE: HY000 (ER_TRANS_CACHE_FULL)

    Message: Multi-statement transaction required more than 'max_binlog_cache_size' bytes of storage; increase this mysqld variable and try again

  • Error: 1198 SQLSTATE: HY000 (ER_SLAVE_MUST_STOP)

    Message: This operation cannot be performed with a running slave; run STOP SLAVE first

  • Error: 1199 SQLSTATE: HY000 (ER_SLAVE_NOT_RUNNING)

    Message: This operation requires a running slave; configure slave and do START SLAVE

  • Error: 1200 SQLSTATE: HY000 (ER_BAD_SLAVE)

    Message: The server is not configured as slave; fix in config file or with CHANGE MASTER TO

  • Error: 1201 SQLSTATE: HY000 (ER_MASTER_INFO)

    Message: Could not initialize master info structure; more error messages can be found in the MySQL error log

  • Error: 1202 SQLSTATE: HY000 (ER_SLAVE_THREAD)

    Message: Could not create slave thread; check system resources

  • Error: 1203 SQLSTATE: 42000 (ER_TOO_MANY_USER_CONNECTIONS)

    Message: User %s has already more than 'max_user_connections' active connections

  • Error: 1204 SQLSTATE: HY000 (ER_SET_CONSTANTS_ONLY)

    Message: You may only use constant expressions with SET

  • Error: 1205 SQLSTATE: HY000 (ER_LOCK_WAIT_TIMEOUT)

    Message: Lock wait timeout exceeded; try restarting transaction

  • Error: 1206 SQLSTATE: HY000 (ER_LOCK_TABLE_FULL)

    Message: The total number of locks exceeds the lock table size

  • Error: 1207 SQLSTATE: 25000 (ER_READ_ONLY_TRANSACTION)

    Message: Update locks cannot be acquired during a READ UNCOMMITTED transaction

  • Error: 1208 SQLSTATE: HY000 (ER_DROP_DB_WITH_READ_LOCK)

    Message: DROP DATABASE not allowed while thread is holding global read lock

  • Error: 1209 SQLSTATE: HY000 (ER_CREATE_DB_WITH_READ_LOCK)

    Message: CREATE DATABASE not allowed while thread is holding global read lock

  • Error: 1210 SQLSTATE: HY000 (ER_WRONG_ARGUMENTS)

    Message: Incorrect arguments to %s

  • Error: 1211 SQLSTATE: 42000 (ER_NO_PERMISSION_TO_CREATE_USER)

    Message: '%s'@'%s' is not allowed to create new users

  • Error: 1212 SQLSTATE: HY000 (ER_UNION_TABLES_IN_DIFFERENT_DIR)

    Message: Incorrect table definition; all MERGE tables must be in the same database

  • Error: 1213 SQLSTATE: 40001 (ER_LOCK_DEADLOCK)

    Message: Deadlock found when trying to get lock; try restarting transaction

  • Error: 1214 SQLSTATE: HY000 (ER_TABLE_CANT_HANDLE_FT)

    Message: The used table type doesn't support FULLTEXT indexes

  • Error: 1215 SQLSTATE: HY000 (ER_CANNOT_ADD_FOREIGN)

    Message: Cannot add foreign key constraint

  • Error: 1216 SQLSTATE: 23000 (ER_NO_REFERENCED_ROW)

    Message: Cannot add a child row: a foreign key constraint fails

  • Error: 1217 SQLSTATE: 23000 (ER_ROW_IS_REFERENCED)

    Message: Cannot delete a parent row: a foreign key constraint fails

  • Error: 1218 SQLSTATE: 08S01 (ER_CONNECT_TO_MASTER)

    Message: Error connecting to master: %s

  • Error: 1219 SQLSTATE: HY000 (ER_QUERY_ON_MASTER)

    Message: Error running query on master: %s

  • Error: 1220 SQLSTATE: HY000 (ER_ERROR_WHEN_EXECUTING_COMMAND)

    Message: Error when executing command %s: %s

  • Error: 1221 SQLSTATE: HY000 (ER_WRONG_USAGE)

    Message: Incorrect usage of %s and %s

  • Error: 1222 SQLSTATE: 21000 (ER_WRONG_NUMBER_OF_COLUMNS_IN_SELECT)

    Message: The used SELECT statements have a different number of columns

  • Error: 1223 SQLSTATE: HY000 (ER_CANT_UPDATE_WITH_READLOCK)

    Message: Can't execute the query because you have a conflicting read lock

  • Error: 1224 SQLSTATE: HY000 (ER_MIXING_NOT_ALLOWED)

    Message: Mixing of transactional and non-transactional tables is disabled

  • Error: 1225 SQLSTATE: HY000 (ER_DUP_ARGUMENT)

    Message: Option '%s' used twice in statement

  • Error: 1226 SQLSTATE: 42000 (ER_USER_LIMIT_REACHED)

    Message: User '%s' has exceeded the '%s' resource (current value: %ld)

  • Error: 1227 SQLSTATE: HY000 (ER_SPECIFIC_ACCESS_DENIED_ERROR)

    Message: Access denied; you need the %s privilege for this operation

  • Error: 1228 SQLSTATE: HY000 (ER_LOCAL_VARIABLE)

    Message: Variable '%s' is a SESSION variable and can't be used with SET GLOBAL

  • Error: 1229 SQLSTATE: HY000 (ER_GLOBAL_VARIABLE)

    Message: Variable '%s' is a GLOBAL variable and should be set with SET GLOBAL

  • Error: 1230 SQLSTATE: 42000 (ER_NO_DEFAULT)

    Message: Variable '%s' doesn't have a default value

  • Error: 1231 SQLSTATE: 42000 (ER_WRONG_VALUE_FOR_VAR)

    Message: Variable '%s' can't be set to the value of '%s'

  • Error: 1232 SQLSTATE: 42000 (ER_WRONG_TYPE_FOR_VAR)

    Message: Incorrect argument type to variable '%s'

  • Error: 1233 SQLSTATE: HY000 (ER_VAR_CANT_BE_READ)

    Message: Variable '%s' can only be set, not read

  • Error: 1234 SQLSTATE: 42000 (ER_CANT_USE_OPTION_HERE)

    Message: Incorrect usage/placement of '%s'

  • Error: 1235 SQLSTATE: 42000 (ER_NOT_SUPPORTED_YET)

    Message: This version of MySQL doesn't yet support '%s'

  • Error: 1236 SQLSTATE: HY000 (ER_MASTER_FATAL_ERROR_READING_BINLOG)

    Message: Got fatal error %d: '%s' from master when reading data from binary log

  • Error: 1237 SQLSTATE: HY000 (ER_SLAVE_IGNORED_TABLE)

    Message: Slave SQL thread ignored the query because of replicate-*-table rules

  • Error: 1238 SQLSTATE: HY000 (ER_INCORRECT_GLOBAL_LOCAL_VAR)

    Message: Variable '%s' is a %s variable

  • Error: 1239 SQLSTATE: 42000 (ER_WRONG_FK_DEF)

    Message: Incorrect foreign key definition for '%s': %s

  • Error: 1240 SQLSTATE: HY000 (ER_KEY_REF_DO_NOT_MATCH_TABLE_REF)

    Message: Key reference and table reference don't match

  • Error: 1241 SQLSTATE: 21000 (ER_OPERAND_COLUMNS)

    Message: Operand should contain %d column(s)

  • Error: 1242 SQLSTATE: 21000 (ER_SUBQUERY_NO_1_ROW)

    Message: Subquery returns more than 1 row

  • Error: 1243 SQLSTATE: HY000 (ER_UNKNOWN_STMT_HANDLER)

    Message: Unknown prepared statement handler (%.*s) given to %s

  • Error: 1244 SQLSTATE: HY000 (ER_CORRUPT_HELP_DB)

    Message: Help database is corrupt or does not exist

  • Error: 1245 SQLSTATE: HY000 (ER_CYCLIC_REFERENCE)

    Message: Cyclic reference on subqueries

  • Error: 1246 SQLSTATE: HY000 (ER_AUTO_CONVERT)

    Message: Converting column '%s' from %s to %s

  • Error: 1247 SQLSTATE: 42S22 (ER_ILLEGAL_REFERENCE)

    Message: Reference '%s' not supported (%s)

  • Error: 1248 SQLSTATE: 42000 (ER_DERIVED_MUST_HAVE_ALIAS)

    Message: Every derived table must have its own alias

  • Error: 1249 SQLSTATE: 01000 (ER_SELECT_REDUCED)

    Message: Select %u was reduced during optimization

  • Error: 1250 SQLSTATE: 42000 (ER_TABLENAME_NOT_ALLOWED_HERE)

    Message: Table '%s' from one of the SELECTs cannot be used in %s

  • Error: 1251 SQLSTATE: 08004 (ER_NOT_SUPPORTED_AUTH_MODE)

    Message: Client does not support authentication protocol requested by server; consider upgrading MySQL client

  • Error: 1252 SQLSTATE: 42000 (ER_SPATIAL_CANT_HAVE_NULL)

    Message: All parts of a SPATIAL index must be NOT NULL

  • Error: 1253 SQLSTATE: 42000 (ER_COLLATION_CHARSET_MISMATCH)

    Message: COLLATION '%s' is not valid for CHARACTER SET '%s'

  • Error: 1254 SQLSTATE: HY000 (ER_SLAVE_WAS_RUNNING)

    Message: Slave is already running

  • Error: 1255 SQLSTATE: HY000 (ER_SLAVE_WAS_NOT_RUNNING)

    Message: Slave has already been stopped

  • Error: 1256 SQLSTATE: HY000 (ER_TOO_BIG_FOR_UNCOMPRESS)

    Message: Uncompressed data size too large; the maximum size is %d (probably, length of uncompressed data was corrupted)

  • Error: 1257 SQLSTATE: HY000 (ER_ZLIB_Z_MEM_ERROR)

    Message: ZLIB: Not enough memory

  • Error: 1258 SQLSTATE: HY000 (ER_ZLIB_Z_BUF_ERROR)

    Message: ZLIB: Not enough room in the output buffer (probably, length of uncompressed data was corrupted)

  • Error: 1259 SQLSTATE: HY000 (ER_ZLIB_Z_DATA_ERROR)

    Message: ZLIB: Input data corrupted

  • Error: 1260 SQLSTATE: HY000 (ER_CUT_VALUE_GROUP_CONCAT)

    Message: %d line(s) were cut by GROUP_CONCAT()

  • Error: 1261 SQLSTATE: 01000 (ER_WARN_TOO_FEW_RECORDS)

    Message: Row %ld doesn't contain data for all columns

  • Error: 1262 SQLSTATE: 01000 (ER_WARN_TOO_MANY_RECORDS)

    Message: Row %ld was truncated; it contained more data than there were input columns

  • Error: 1263 SQLSTATE: 01000 (ER_WARN_NULL_TO_NOTNULL)

    Message: Data truncated; NULL supplied to NOT NULL column '%s' at row %ld

  • Error: 1264 SQLSTATE: 01000 (ER_WARN_DATA_OUT_OF_RANGE)

    Message: Data truncated; out of range for column '%s' at row %ld

  • Error: 1265 SQLSTATE: 01000 (ER_WARN_DATA_TRUNCATED)

    Message: Data truncated for column '%s' at row %ld

  • Error: 1266 SQLSTATE: HY000 (ER_WARN_USING_OTHER_HANDLER)

    Message: Using storage engine %s for table '%s'

  • Error: 1267 SQLSTATE: HY000 (ER_CANT_AGGREGATE_2COLLATIONS)

    Message: Illegal mix of collations (%s,%s) and (%s,%s) for operation '%s'

  • Error: 1268 SQLSTATE: HY000 (ER_DROP_USER)

    Message: Can't drop one or more of the requested users

  • Error: 1269 SQLSTATE: HY000 (ER_REVOKE_GRANTS)

    Message: Can't revoke all privileges, grant for one or more of the requested users

  • Error: 1270 SQLSTATE: HY000 (ER_CANT_AGGREGATE_3COLLATIONS)

    Message: Illegal mix of collations (%s,%s), (%s,%s), (%s,%s) for operation '%s'

  • Error: 1271 SQLSTATE: HY000 (ER_CANT_AGGREGATE_NCOLLATIONS)

    Message: Illegal mix of collations for operation '%s'

  • Error: 1272 SQLSTATE: HY000 (ER_VARIABLE_IS_NOT_STRUCT)

    Message: Variable '%s' is not a variable component (can't be used as XXXX.variable_name)

  • Error: 1273 SQLSTATE: HY000 (ER_UNKNOWN_COLLATION)

    Message: Unknown collation: '%s'

  • Error: 1274 SQLSTATE: HY000 (ER_SLAVE_IGNORED_SSL_PARAMS)

    Message: SSL parameters in CHANGE MASTER are ignored because this MySQL slave was compiled without SSL support; they can be used later if MySQL slave with SSL is started

  • Error: 1275 SQLSTATE: HY000 (ER_SERVER_IS_IN_SECURE_AUTH_MODE)

    Message: Server is running in --secure-auth mode, but '%s'@'%s' has a password in the old format; please change the password to the new format

  • Error: 1276 SQLSTATE: HY000 (ER_WARN_FIELD_RESOLVED)

    Message: Field or reference '%s%s%s%s%s' of SELECT #%d was resolved in SELECT #%d

  • Error: 1277 SQLSTATE: HY000 (ER_BAD_SLAVE_UNTIL_COND)

    Message: Incorrect parameter or combination of parameters for START SLAVE UNTIL

  • Error: 1278 SQLSTATE: HY000 (ER_MISSING_SKIP_SLAVE)

    Message: It is recommended to run with --skip-slave-start when doing step-by-step replication with START SLAVE UNTIL; otherwise, you are not safe in case of unexpected slave's mysqld restart

  • Error: 1279 SQLSTATE: HY000 (ER_UNTIL_COND_IGNORED)

    Message: SQL thread is not to be started so UNTIL options are ignored

  • Error: 1280 SQLSTATE: 42000 (ER_WRONG_NAME_FOR_INDEX)

    Message: Incorrect index name '%s'

  • Error: 1281 SQLSTATE: 42000 (ER_WRONG_NAME_FOR_CATALOG)

    Message: Incorrect catalog name '%s'

  • Error: 1282 SQLSTATE: HY000 (ER_WARN_QC_RESIZE)

    Message: Query cache failed to set size %lu, new query cache size is %lu

  • Error: 1283 SQLSTATE: HY000 (ER_BAD_FT_COLUMN)

    Message: Column '%s' cannot be part of FULLTEXT index

  • Error: 1284 SQLSTATE: HY000 (ER_UNKNOWN_KEY_CACHE)

    Message: Unknown key cache '%s'

  • Error: 1285 SQLSTATE: HY000 (ER_WARN_HOSTNAME_WONT_WORK)

    Message: MySQL is started in --skip-name-resolve mode. You need to restart it without this switch for this grant to work

  • Error: 1286 SQLSTATE: 42000 (ER_UNKNOWN_STORAGE_ENGINE)

    Message: Unknown table engine '%s'

  • Error: 1287 SQLSTATE: HY000 (ER_WARN_DEPRECATED_SYNTAX)

    Message: '%s' is deprecated, use '%s' instead

  • Error: 1288 SQLSTATE: HY000 (ER_NON_UPDATABLE_TABLE)

    Message: The target table %s of the %s is not updateable

  • Error: 1289 SQLSTATE: HY000 (ER_FEATURE_DISABLED)

    Message: The '%s' feature was disabled; you need MySQL built with '%s' to have it working

  • Error: 1290 SQLSTATE: HY000 (ER_OPTION_PREVENTS_STATEMENT)

    Message: The MySQL server is running with the %s option so it cannot execute this statement

  • Error: 1291 SQLSTATE: HY000 (ER_DUPLICATED_VALUE_IN_TYPE)

    Message: Column '%s' has duplicated value '%s' in %s

  • Error: 1292 SQLSTATE: HY000 (ER_TRUNCATED_WRONG_VALUE)

    Message: Truncated wrong %s value: '%s'

  • Error: 1293 SQLSTATE: HY000 (ER_TOO_MUCH_AUTO_TIMESTAMP_COLS)

    Message: Incorrect table definition; There can only be one TIMESTAMP column with CURRENT_TIMESTAMP in DEFAULT or ON UPDATE clause

  • Error: 1294 SQLSTATE: HY000 (ER_INVALID_ON_UPDATE)

    Message: Invalid ON UPDATE clause for '%s' column

  • Error: 1295 SQLSTATE: HY000 (ER_UNSUPPORTED_PS)

    Message: This command is not supported in the prepared statement protocol yet

  • Error: 1296 SQLSTATE: HY000 (ER_GET_ERRMSG)

    Message: Got NDB error %d '%s'

  • Error: 1297 SQLSTATE: HY000 (ER_GET_TEMPORARY_ERRMSG)

    Message: Got temporary NDB error %d '%s'

  • Error: 1298 SQLSTATE: HY000 (ER_UNKNOWN_TIME_ZONE)

    Message: Unknown or incorrect time zone: '%s'

  • Error: 1299 SQLSTATE: HY000 (ER_WARN_INVALID_TIMESTAMP)

    Message: Invalid TIMESTAMP value in column '%s' at row %ld

  • Error: 1300 SQLSTATE: HY000 (ER_INVALID_CHARACTER_STRING)

    Message: Invalid %s character string: '%s'

  • Error: 1301 SQLSTATE: HY000 (ER_WARN_ALLOWED_PACKET_OVERFLOWED)

    Message: Result of %s() was larger than max_allowed_packet (%ld) - truncated

  • Error: 1302 SQLSTATE: HY000 (ER_CONFLICTING_DECLARATIONS)

    Message: Conflicting declarations: '%s%s' and '%s%s'

Client error information comes from the following files:

  • The Error values and the symbols in parentheses correspond to definitions in the include/errmsg.h MySQL source file.

  • The Message values correspond to the error messages that are listed in the libmysql/errmsg.c file. %d or %s represent numbers or strings that are substituted into the messages %when they are displayed.

Because updates are frequent, it is possible that these files contain additional error information not listed here.

  • Error: 2000 (CR_UNKNOWN_ERROR)

    Message: Unknown MySQL error

  • Error: 2001 (CR_SOCKET_CREATE_ERROR)

    Message: Can't create UNIX socket (%d)

  • Error: 2002 (CR_CONNECTION_ERROR)

    Message: Can't connect to local MySQL server through socket '%s' (%d)

  • Error: 2003 (CR_CONN_HOST_ERROR)

    Message: Can't connect to MySQL server on '%s' (%d)

  • Error: 2004 (CR_IPSOCK_ERROR)

    Message: Can't create TCP/IP socket (%d)

  • Error: 2005 (CR_UNKNOWN_HOST)

    Message: Unknown MySQL server host '%s' (%d)

  • Error: 2006 (CR_SERVER_GONE_ERROR)

    Message: MySQL server has gone away

  • Error: 2007 (CR_VERSION_ERROR)

    Message: Protocol mismatch; server version = %d, client version = %d

  • Error: 2008 (CR_OUT_OF_MEMORY)

    Message: MySQL client ran out of memory

  • Error: 2009 (CR_WRONG_HOST_INFO)

    Message: Wrong host info

  • Error: 2010 (CR_LOCALHOST_CONNECTION)

    Message: Localhost via UNIX socket

  • Error: 2011 (CR_TCP_CONNECTION)

    Message: %s via TCP/IP

  • Error: 2012 (CR_SERVER_HANDSHAKE_ERR)

    Message: Error in server handshake

  • Error: 2013 (CR_SERVER_LOST)

    Message: Lost connection to MySQL server during query

  • Error: 2014 (CR_COMMANDS_OUT_OF_SYNC)

    Message: Commands out of sync; you can't run this command now

  • Error: 2015 (CR_NAMEDPIPE_CONNECTION)

    Message: Named pipe: %s

  • Error: 2016 (CR_NAMEDPIPEWAIT_ERROR)

    Message: Can't wait for named pipe to host: %s pipe: %s (%lu)

  • Error: 2017 (CR_NAMEDPIPEOPEN_ERROR)

    Message: Can't open named pipe to host: %s pipe: %s (%lu)

  • Error: 2018 (CR_NAMEDPIPESETSTATE_ERROR)

    Message: Can't set state of named pipe to host: %s pipe: %s (%lu)

  • Error: 2019 (CR_CANT_READ_CHARSET)

    Message: Can't initialize character set %s (path: %s)

  • Error: 2020 (CR_NET_PACKET_TOO_LARGE)

    Message: Got packet bigger than 'max_allowed_packet' bytes

  • Error: 2021 (CR_EMBEDDED_CONNECTION)

    Message: Embedded server

  • Error: 2022 (CR_PROBE_SLAVE_STATUS)

    Message: Error on SHOW SLAVE STATUS:

  • Error: 2023 (CR_PROBE_SLAVE_HOSTS)

    Message: Error on SHOW SLAVE HOSTS:

  • Error: 2024 (CR_PROBE_SLAVE_CONNECT)

    Message: Error connecting to slave:

  • Error: 2025 (CR_PROBE_MASTER_CONNECT)

    Message: Error connecting to master:

  • Error: 2026 (CR_SSL_CONNECTION_ERROR)

    Message: SSL connection error

  • Error: 2027 (CR_MALFORMED_PACKET)

    Message: Malformed packet

  • Error: 2028 (CR_WRONG_LICENSE)

    Message: This client library is licensed only for use with MySQL servers having '%s' license

  • Error: 2029 (CR_NULL_POINTER)

    Message: Invalid use of null pointer

  • Error: 2030 (CR_NO_PREPARE_STMT)

    Message: Statement not prepared

  • Error: 2031 (CR_PARAMS_NOT_BOUND)

    Message: No data supplied for parameters in prepared statement

  • Error: 2032 (CR_DATA_TRUNCATED)

    Message: Data truncated

  • Error: 2033 (CR_NO_PARAMETERS_EXISTS)

    Message: No parameters exist in the statement

  • Error: 2034 (CR_INVALID_PARAMETER_NO)

    Message: Invalid parameter number

  • Error: 2035 (CR_INVALID_BUFFER_USE)

    Message: Can't send long data for non-string/non-binary data types (parameter: %d)

  • Error: 2036 (CR_UNSUPPORTED_PARAM_TYPE)

    Message: Using unsupported buffer type: %d (parameter: %d)

  • Error: 2037 (CR_SHARED_MEMORY_CONNECTION)

    Message: Shared memory: %s

  • Error: 2038 (CR_SHARED_MEMORY_CONNECT_REQUEST_ERROR)

    Message: Can't open shared memory; client could not create request event (%lu)

  • Error: 2039 (CR_SHARED_MEMORY_CONNECT_ANSWER_ERROR)

    Message: Can't open shared memory; no answer event received from server (%lu)

  • Error: 2040 (CR_SHARED_MEMORY_CONNECT_FILE_MAP_ERROR)

    Message: Can't open shared memory; server could not allocate file mapping (%lu)

  • Error: 2041 (CR_SHARED_MEMORY_CONNECT_MAP_ERROR)

    Message: Can't open shared memory; server could not get pointer to file mapping (%lu)

  • Error: 2042 (CR_SHARED_MEMORY_FILE_MAP_ERROR)

    Message: Can't open shared memory; client could not allocate file mapping (%lu)

  • Error: 2043 (CR_SHARED_MEMORY_MAP_ERROR)

    Message: Can't open shared memory; client could not get pointer to file mapping (%lu)

  • Error: 2044 (CR_SHARED_MEMORY_EVENT_ERROR)

    Message: Can't open shared memory; client could not create %s event (%lu)

  • Error: 2045 (CR_SHARED_MEMORY_CONNECT_ABANDONED_ERROR)

    Message: Can't open shared memory; no answer from server (%lu)

  • Error: 2046 (CR_SHARED_MEMORY_CONNECT_SET_ERROR)

    Message: Can't open shared memory; cannot send request event to server (%lu)

  • Error: 2047 (CR_CONN_UNKNOW_PROTOCOL)

    Message: Wrong or unknown protocol

  • Error: 2048 (CR_INVALID_CONN_HANDLE)

    Message: Invalid connection handle

  • Error: 2049 (CR_SECURE_AUTH)

    Message: Connection using old (pre-4.1.1) authentication protocol refused (client option 'secure_auth' enabled)

  • Error: 2050 (CR_FETCH_CANCELED)

    Message: Row retrieval was canceled by mysql_stmt_close() call

  • Error: 2051 (CR_NO_DATA)

    Message: Attempt to read column without prior row fetch

  • Error: 2052 (CR_NO_STMT_METADATA)

    Message: Prepared statement contains no metadata


제13 장 MySQL 의 확장

목차

13.1. MySQL 의 내부 정보
13.1.1. MySQL 의 스레드
13.1.2. MySQL 테스트 스위트
13.2. MySQL 에의 새로운 함수의 추가
13.2.1. CREATE FUNCTION/DROP FUNCTION 의 구문
13.2.2. 새로운 유저 정의 함수의 추가
13.2.3. 새로운 네이티브 함수의 추가
13.3. MySQL 에의 새로운 프로시저의 추가
13.3.1. 프로시저의 분석
13.3.2. 프로시저의 작성

13.1. MySQL 의 내부 정보

이 장에서는,MySQL 코드를 취급할 때 알 필요가 있는 사항에 대해 설명합니다.MySQL 의 개발에 공헌하고 싶은, 개발중의 비공식 버젼의 코드에 액세스 하고 싶은, 혹은 개발 과정에 흥미가 있다, 라고 하는 경우는, 항2.3.4. 「개발 소스 트리로부터의 인스톨」 의 지시를 참조해 주세요.MySQL 의 내부 정보로 흥미가 있는 경우는, 당사의 internals 메일링 리스트에 가입해 주세요.이 메일링 리스트는 그만큼 투고수는 많지 않습니다.가입 방법의 상세한 것에 대하여는, 항1.7.1.1. 「MySQL 메일링 리스트」 (을)를 참조해 주세요.MySQL AB 의 개발자는 전원 internals 리스트에 가입하고 있어MySQL 코드에 임하고 있는 사람들을 서포트합니다.코드에 대해 질문하거나MySQL 프로젝트에 제공하고 싶은 패치를 송신하는 경우에는, 이 리스트를 사양말고 사용해 주십시오.

13.1.1. MySQL 의 스레드

MySQL 서버가 작성하는 스레드를 이하에 나타냅니다.

  • TCP/IP 접속 스레드는, 모든 접속 요구를 받아들여, 새롭게 전용의 스레드를 작성하고, 접속마다의 인증 및 SQL 쿼리의 처리를 실시한다.

  • Windows NT 그럼, 이름 파이프한드라스레드가, 이름 파이프 접속 요구에 대해서 TCP/IP 접속 스레드와 같은 처리를 실행한다.

  • 시그나르스레드는, 모든 시그널을 처리한다.또, 통상은 알람을 처리해 process_alarm() (을)를 호출해, 장시간 아이돌 상태가 계속 되고 있는 접속을 타임 아웃 시킨다.

  • mysqld 하지만 -DUSE_ALARM_THREAD (을)를 지정해 컴파일 되고 있는 경우, 알람 처리 전용 스레드가 작성된다.이 스레드는,sigwait() 그리고 문제가 발생하고 있는 시스템인가, 또는 개발자가 전용의 시그널 처리 스레드를 사용하지 않고 thr_alarm() 코드를 어플리케이션으로 사용하고 싶은 경우에게만 사용한다.

  • --flush_time=# 옵션을 사용하는 경우, 전용 스레드가 작성되어 지정된 간격으로 모든 테이블을 플래시 한다.

  • 모든 접속은 그것 자신의 스레드를 가진다.

  • INSERT DELAYED (을)를 사용되는 모든 테이블은 그것 자신의 스레드를 가진다.

  • --master-host 옵션을 사용했을 경우, 스레이브레프리케이션스레드가 기동해, 마스터의 갱신을 읽어들여, 적용한다.

mysqladmin processlist (은)는, 접속 스레드,INSERT DELAYED 스레드, 및 레프리케이션스레드만을 표시합니다.

13.1.2. MySQL 테스트 스위트

최근까지는, 전범위를 대상으로 하는 당사의 테스트 스위트는 독자적으로 개발한 고객 데이터를 사용하고 있어, 그 때문에(위해) 공개되고 있지 않았습니다.테스트 프로세스 중(안)에서 유일 공개되고 있던 것이,sql-bench 디렉토리에 있다 Perl DBI/DBD 벤치마크의 crash-me 테스트, 및 tests 디렉토리에 있는 그 외의 여러가지 테스트였습니다.표준화 된 공개 테스트 스위트가 없었기 때문에, 당사제품의 유저나 개발자는,MySQL 코드에 대해서 회귀 시험을 실시하는 것이 곤란했습니다.이 문제를 해결하기 위해서, 버젼 3.23.29 (으)로부터,Unix 의 소스 디스트리뷰션 및 바이너리 디스트리뷰션에, 새롭게 작성한 테스트 시스템을 추가했습니다.이 테스트는 Unix 그리고 실행할 수 있습니다.또, 서버를 Cygwin 그리고 컴파일 했을 경우는,Cygwin 환경의 Windows 위에서 실행할 수 있습니다.네이티브인 Windows 환경에서는 현재는 동작하지 않습니다.

현재의 시험대는 MySQL 전체를 테스트하는 것은 아닙니다만,SQL (을)를 처리하는 코드에 있어서의 명백한 버그나 OS/ 라이브러리의 문제는 검출할 수 있을 것입니다.또 replication의 테스트는 철저하게 가고 있습니다.최종적으로는, 코드를 100% 커버하는 테스트를 작성하는 것을 목표로 하고 있습니다.그 때문에(위해) 테스트 스위트를 확충하기 위한 여러분으로부터의 협력을 기다리고 있습니다.특히, 사용의 시스템에 있어서 위기인 기능을 검사하는 테스트를 제공해 주시면, 향후 릴리스 되는 모든 MySQL 버젼으로 사용의 어플리케이션의 동작이 보증되게 됩니다.

13.1.2.1. MySQL 테스트 스위트의 실행

테스트 시스템은, 테스트 언어 인터프리터(mysqltest ), 모든 테스트를 실행하는 셸 스크립트(mysql-test-run ), 테스트 전용 언어로 기술된 실제의 시험대, 및 예상되는 테스트 결과로부터 구성됩니다.빌드 하고 나서 시스템으로 테스트 스위트를 실행하려면 , 소스 루트로부터 make test 또는 mysql-test/mysql-test-run (이)라고 입력합니다.바이너리 디스트리뷰션을 인스톨 했을 경우는,cd 그리고 인스톨 루트 디렉토리(/usr/local/mysql 등)으로 이동해,scripts/mysql-test-run (을)를 실행합니다.모든 테스트가 정상 종료할 필요가 있습니다.정상 종료하지 않는 케이스가 있는 경우, 그 원인을 조사해 그것이 MySQL 의 버그이면 문제점을 보고해 주세요. See 항13.1.2.3. 「MySQL 테스트 스위트의 버그의 보고」 .

테스트 스위트를 실행하려고 하는 머신상에서 mysqld 하지만 동작하고 있는 경우, 그것이 9306 및 9307 의 포토를 어느쪽이나 사용하고 있지 않았기 때문에이면, 그것을 정?~ 할 필요는 없습니다.어느 쪽인가의 포토가 사용되고 있는 경우는,mysql-test-run (을)를 편집해 마스터 포토 또는 슬레이브 포토, 혹은 그 양쪽 모두를, 사용할 수 있는 포토로 변경할 필요가 있습니다.

mysql-test/mysql-test-run test_name (을)를 사용하고, 개개의 시험대를 1 건씩 실행할 수 있습니다.

어느 테스트가 실패했을 경우,--force 옵션을 지정해 mysql-test-run (을)를 실행해, 그 밖에도 실패하는 테스트가 있을지를 조사할 필요가 있습니다.

13.1.2.2. MySQL 테스트 스위트의 확장

mysqltest 언어를 사용해 독자적으로 시험대를 작성할 수 있습니다.유감스럽지만, 그 완전한 메뉴얼은 아직 작성되고 있지 않습니다.단지, 현재의 시험대를 참고로 할 수 있습니다.독자적으로 시험대를 작성할 때의 주의점을 이하에 나타냅니다.

  • 작성한 테스트는 mysql-test/t/*.test 에 둔다.

  • 시험대는,; 그리고 종단 된 스테이트먼트로 구성되어mysql 커멘드 라인 클라이언트에의 입력과 같다.스테이트먼트는, 그것이 내부 커멘드(sleep 등)으로서 인식되는 경우를 제외하고, 디폴트로 쿼리로서 MySQL 서버에 송신된다.

  • SELECT ,SHOW ,EXPLAIN 등, 결과 세트를 생성하는 모든 쿼리는, 먼저 @/path/to/result/file (을)를 지정할 필요가 있다.파일에는 예상되는 결과를 기술할 필요가 있다.결과 파일을 간단하게 생성하는 방법으로서는,mysql-test 디렉토리로부터 mysqltest -r < t/test-case-name.test (을)를 실행해, 필요에 따라서 생성된 결과 파일을 편집하고 예상되는 출력으로 변경한다.이 경우, 표시되지 않는 문자를 추가 또는 삭제하지 않게 주의할 필요가 있다.반드시 텍스트의 변경 또는 행의 삭제, 혹은 그 양쪽 모두만을 실행하도록(듯이) 한다.행을 삽입할 필요가 있는 경우, 반드시 필드를 하드 탭으로 단락지어, 행의 마지막에 하드 탭을 두도록(듯이) 한다.od -c (을)를 사용하면, 편집중에 텍스트 문자 편집기로 아무것도 부수지 않은 것을 확인할 수 있다.mysqltest -r 의 출력을 편집할 필요가 있는 것은 버그가 발견되었을 경우만이므로, 그러한 필요성이 생기지 않는 것을 빌고 있다.

  • 테스트 스위트와의 정합성을 취하려면 , 결과 파일을 mysql-test/r 디렉토리에 두고, 이름을 test_name.result (으)로 할 필요가 있다.테스트로 복수의 결과 파일을 생성하는 경우는,test_name.a.result ,test_name.b.result (와)과 같이 이름을 붙일 필요가 있다.

  • 스테이트먼트가 에러를 돌려주는 경우, 그 스테이트먼트의 전에 --error error-number (을)를 지정한다.여기서, 에러 번호에는,',' 그리고 단락지어진 에러 번호의 리스트를 지정할 수 있다.

  • replication의 시험대를 작성한 경우, 테스트 파일의 선두행에 source include/master-slave.inc; (와)과 기술할 필요가 있다.마스터와 슬레이브를 바꾸려면 ,connection master; 및 connection slave; (을)를 사용한다.이제(벌써) 한편의 접속으로 어떠한 처리를 실행할 필요가 있는 경우, 마스터에는 connection master1; (을)를 실행해, 슬레이브에는 connection slave1; (을)를 실행한다.

  • 루프 중(안)에서 어떠한 처리를 실행할 필요가 있는 경우, 이하와 같은 코드를 작성한다.

    let $1=1000;
while ($1)
{
 # do your queries here
 dec $1;
}

  • 쿼리간에 sleeve 하려면 ,sleep 커멘드를 사용한다.초수는 소수점 이하까지 지정할 수 있으므로, 예를 들어 1.3 초sleeve 하는 경우는 sleep 1.3; (을)를 실행한다.

  • 시험대를 위해서 옵션을 추가해 슬레이브를 실행하려면 ,mysql-test/t/test_name-slave.opt 에 커멘드 라인 형식에서 기술한다.마스터의 경우는,mysql-test/t/test_name-master.opt 에 기술한다.

  • 테스트 스위트하게 질문이 있는 경우, 또는 테스트 스위트하게 제공하는 시험대가 있는 경우,MySQL 내부 정보의 메일링 리스트에 메일을 송신한다.See 항1.7.1.1. 「MySQL 메일링 리스트」 . 이 메일링 리스트는 첨부 파일을 받아들이지 않기 때문에, 관련하는 파일은 ftp://support.mysql.com/pub/mysql/Incoming/ 에 업 로드할 필요가 있다.

13.1.2.3. MySQL 테스트 스위트의 버그의 보고

사용의 MySQL 버젼이 테스트 스위트를 정상 종료할 수 없는 경우, 이하의 처리를 실행할 필요가 있습니다.

  • 어디서 이상이 발생하고 있을까를 할 수 있는 한 조사할 때까지, 버그 리포트를 송신하지 않는 것.버그 리포트를 송신하는 경우는, 사용하고 있는 시스템 및 MySQL 의 버젼에 관한 정보를 수집하기 위한 mysqlbug 스크립트를 사용한다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

  • mysql-test-run 의 출력 및 mysql-test/r 디렉토리의 모든 .reject 파일의 내용을 반드시 송신한다.

  • 테스트 스위트의 테스트가 이상종료(ABEND) 하는 경우, 그 테스트를 단독으로 실행했을 때도 이상종료(ABEND) 할지를 조사한다.

    cd mysql-test
mysql-test-run --local test-name

    단독으로 실행해도 이상종료(ABEND) 하는 경우,--with-debug (을)를 지정해 MySQL (을)를 실행해,--debug 옵션 첨부로 mysql-test-run (을)를 실행한다.이것이라도 이상종료(ABEND) 하는 경우는, 당사에서 트레이스 파일 var/tmp/master.trace (을)를 조사하고 싶기 때문에,ftp://support.mysql.com/pub/mysql/secret 에 그 파일을 업 로드한다.이 때, 반드시 사용하고 있는 시스템의 상세한 설명,mysqld 바이너리의 버젼, 및 mysqld 바이너리의 컴파일 방법을 연락한다.

  • --force 옵션을 지정해 mysql-test-run (을)를 실행해, 다른 테스트가 이상종료(ABEND) 할지도 조사한다.

  • 스스로 MySQL (을)를 컴파일 했을 경우, 메뉴얼을 참조해 사용하고 있는 플랫폼상에서 MySQL (을)를 컴파일 하는 방법을 조사한다.할 수 있으면, 당사가 컴파일 한 바이너리를 http://www.mysql.com/downloads/ (으)로부터 다운로드해 사용한다.당사가 제공하는 표준의 바이너리는 모두 테스트 스위트를 정상 종료할 것이다.

  • Result length mismatch 또는 Result content mismatch 등의 에러가 발생하는 경우, 이것은 테스트의 출력이라고 예상되는 출력이 정확하게 일치하지 않았던 것을 의미한다.이 경우,MySQL 의 버그의 가능성이 있다.혹은, 사용하고 있다 mysqld 의 버젼이 특정의 환경하에서 다소 다른 결과를 출력한 가능성이 있다.

    이상종료(ABEND) 한 테스트 결과는, 결과 파일과 같은 베이스명에 확장자(extension) .reject (을)를 붙인 이름의 파일에 출력된다.시험대를 실행해 이상종료(ABEND) 했을 경우, 이러한 2 개의 파일을 파라미터로서 diff (을)를 실행할 필요가 있다.양자의 차이를 모르는 경우, 각각을 파라미터로서 od -c (을)를 실행해, 그 사이즈를 조사한다.

  • 테스트가 전체적으로 이상종료(ABEND) 하는 경우,mysql-test/var/log 디렉토리의 로그 파일을 조사하고, 이상의 원인에 관한 힌트를 찾는다.

  • 디버그 기능을 짜넣어 MySQL (을)를 컴파일 하고 있었을 경우,--gdb 또는 --debug , 혹은 그 양쪽 모두의 옵션을 지정해 mysql-test-run (을)를 실행하는 것에 의해서 디버그 할 수 있다. See 항E.1.2. 「트레이스 파일의 작성」 .

    디버그 기능을 짜넣지 않고 MySQL (을)를 컴파일 하고 있었을 경우, 디버그 기능을 짜넣도록(듯이) 컴파일 하고 나서 재실행할 필요가 있다.거기에는,--with-debug 옵션을 지정해 configure (을)를 실행한다. See 항2.3. 「MySQL 소스 디스트리뷰션의 인스톨」 .


제11 장 MySQL API

목차

11.1. MySQL C API
11.1.1. C API 데이터형
11.1.2. C API 함수의 개요
11.1.3. C API 함수의 설명
11.1.4. C API 의 Prepared Statements
11.1.5. C API 의 Prepared Statement의 데이터형
11.1.6. C API 의 Prepared Statement 함수의 개요
11.1.7. C API 의 Prepared Statement 함수의 설명
11.1.8. C API 에 있어서의 복수 쿼리의 실행의 취급
11.1.9. C API 에 있어서의 일자치 및 시각치의 취급
11.1.10. C API 스레드 함수의 설명
11.1.11. C API 편입 서버 함수의 설명
11.1.12. C API 의 사용에 관한 일반적인 질문 및 문제
11.1.13. 클라이언트 프로그램의 빌드
11.1.14. 스레드 클라이언트의 작성 방법
11.1.15. 편입 MySQL 서버 라이브러리 libmysqld
11.2. MySQL 의 ODBC 서포트
11.2.1. MyODBC 의 인스톨 방법
11.2.2. ODBC 아드?~ 니스트레이타의 필드의 설정 방법법
11.2.3. MyODBC 의 접속 파라미터
11.2.4. MyODBC 에 관한 문제를 보고하는 방법
11.2.5. MyODBC (와)과 제휴해 동작하는 것이 알려져 있는 프로그램
11.2.6. ODBC 그리고 AUTO_INCREMENT 속성을 가지는 컬럼의 값을 취득하는 방법
11.2.7. MyODBC 에 관한 문제의 보고
11.3. MySQL 의 Java 접속(JDBC )
11.4. MySQL PHP API
11.4.1. MySQL 및 PHP (이)가 좋게 있는 문제
11.5. MySQL Perl API
11.5.1. DBI (와)과 DBD::mysql
11.5.2. DBI 인터페이스
11.5.3. DBI/DBD 에 관한 그 외의 정보
11.6. MySQL C++ API
11.6.1. Borland C++
11.7. MySQL Python API
11.8. MySQL Tcl API
11.9. MySQL Eiffel Wrapper

이 장에서는,MySQL 그리고 사용할 수 있다 API 의 입수 장소 및 사용 방법에 대해 설명합니다.가장 풍부한 종류가 준비되어 있는 것이 C API 입니다.이것은 MySQL 팀이 개발하고 있습니다.발설어 전용의 API (은)는, 이 C API (을)를 베이스로 해 개발되고 있습니다.

11.1. MySQL C API

C API 코드는,MySQL (와)과 함께 배포되고 있습니다.C API 코드는 mysqlclient 라이브러리에 격납되어C 프로그램은 이 코드를 사용해 데이타베이스에 액세스 할 수 있습니다.

MySQL 의 소스 디스트리뷰션에 포함되는 클라이언트의 상당수는 C 그리고 기술되고 있습니다.C API 의 사용 방법을 알 수 있는 코드예를 찾고 있는 경우는, 이러한 클라이언트를 참고로 해 주세요.클라이언트는,MySQL 소스 디스트리뷰션의 clients 디렉토리에 격납되고 있습니다.

다른 클라이언트 API (Connector/J (을)를 제외하는 모든 API )의 상당수는,mysqlclient 라이브러리를 사용해 MySQL 서버와 통신합니다.이 라이브러리를 사용하면, 예를 들어 환경 변수를 참조할 수 있으므로, 다른 클라이언트 프로그램과 대부분의 환경 변수를 공용할 수 있게 됩니다.공용할 수 있는 환경 변수의 일람에 대해서는, 항4.9. 「MySQL 클라이언트 사이드의 스크립트와 유틸리티」 (을)를 참조해 주세요.

클라이언트를 사용할 수 있는 통신 버퍼 사이즈에는 상한이 있습니다.내부적으로 할당할 수 있고 있는 버퍼 사이즈(16 킬로바이트)는, 최대 16 메가바이트까지 자동적으로 증가합니다.버퍼 사이즈가 증가하는 것은 버퍼의 요구량이 증가했을 경우 뿐이어서, 디폴트의 최대치를 늘렸다고 사용 자원이 증가하는 것은 아닙니다.이 사이즈 체크에서는, 잘못된 쿼리나 통신 패킷을 주로 체크합니다.

통신 버퍼 사이즈는,SQL 스테이트먼트 1 개(클라이언트로부터 서버에의 트래픽) 및 결과 데이터 1 행(서버로부터 클라이언트에의 트래픽)을 격납 가능한 한의 크기가 필요합니다.각 스레드의 통신 버퍼는, 쿼리나 레코드를 처리할 수 있도록, 그 최대치까지 동적으로 확대됩니다.예를 들어, 최대 16 메가바이트의 데이터를 격납한다 BLOB 값을 처리하는 경우, 통신 버퍼 사이즈의 최대치는(서버와 클라이언트의 양쪽 모두로) 적어도 16 메가바이트일 필요가 있습니다.클라이언트의 디폴트의 최대치는 16 메가바이트입니다만, 서버의 디폴트의 최대치는 1 메가바이트입니다.서버의 디폴트의 최대치를 늘리려면 , 서버의 기동시에 max_allowed_packet 의 값을 변경합니다. See 항5.5.2. 「서버 파라미터의 튜닝」 .

MySQL 서버는, 쿼리가 끝날 때마다 통신 버퍼 사이즈를 net_buffer_length (으)로 줄입니다.클라이언트측에서는, 접속이 절단 되어 메모리가 해방될 때까지, 그 접속에 할당할 수 있었던 버퍼 사이즈가 줄어 들 것은 없습니다.

스레드를 사용하는 프로그라?~ 그에 대해서는, 항11.1.14. 「스레드 클라이언트의 작성 방법」 (을)를 참조해 주세요.동일 프로그램내에 " 서버" (와)과 " 클라이언트" 하지만 존재한다( 및 외부의 MySQL 서버와 통신하지 않는다) 스탠드얼론 어플리케이션의 작성에 대해서는, 항11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld 」 (을)를 참조해 주세요.

11.1.1. C API 데이터형

  • MYSQL

    이 구조체는,1 개의 데이타베이스 접속에의 핸들을 나타낸다.대부분의 MySQL 함수로 사용된다.

  • MYSQL_RES

    이 구조체는, 레코드를 돌려주는 쿼리(SELECT ,SHOW ,EXPLAIN ,DESCRIBE )의 결과를 나타낸다.이 섹션에서는, 쿼리로부터 돌려주어진 정보를 결과 세트 (이)라고 부른다.

  • MYSQL_ROW

    1 행의 데이터의 타입 세이프인 표현.현재는, 아르바이트 문자열의 배열로서 실장되고 있다(필드에는 바이너리 데이터가 격납되는 경우가 있어, 그러한 데이터에서는 내부적으로 누르바이트가 사용될 가능성이 있으므로, 아르바이트 문자열을 눌 종단 문자열로서 취급할 수 없다).레코드를 취득하려면 ,mysql_fetch_row() (을)를 호출한다.

  • MYSQL_FIELD

    이 구조체에는, 필드의 이름, 형태, 사이즈 등, 필드에 관한 정보가 격납된다.멤버의 상세한 것에 대하여는, 이하로 설명한다. 각 필드에 대해서 mysql_fetch_field() (을)를 반복해 호출하는 것에 의해서, 대응한다 MYSQL_FIELD 구조체를 취득할 수 있다.필드치는 이 구조체의 일부에서는 없고,MYSQL_ROW 구조체에 포함된다.

  • MYSQL_FIELD_OFFSET

    MySQL 필드 일람에 대한 오프셋의 안전한 형태 표현(mysql_field_seek() 하지만 사용).오프셋은 레코드 내부에서의 필드 번호이며,0 (으)로부터 시작된다.

  • my_ulonglong

    레코드의 수를 나타내기 위한 형태이며,mysql_affected_rows() ,mysql_num_rows() , 및 mysql_insert_id() 그리고 사용된다.0 (으)로부터 1.84e19 까지의 범위의 값을 나타낸다.

    일부의 시스템에서는,my_ulonglong 형태의 값을 출력하려고 해도, 정상적으로 출력되지 않는다.이 형태의 값을 출력하려면 ,unsigned long (으)로 변환하고,%lu 포맷을 사용한다.이하에 예를 나타낸다.

    printf ("Number of rows: %lu\n", (unsigned long) mysql_num_rows(result));

MYSQL_FIELD 구조체의 멤버를 이하에 나타냅니다.

  • char * name

    필드의 이름.눌 종단 문자열.

  • char * table

    이 필드가 계산 결과 데이터의 필드가 아닌 경우, 이 필드가 속하는 테이블의 이름.계산 결과 데이터의 필드의 경우,table 의 값은 공문자열이 된다.

  • char * def

    이 필드의 디폴트치.눌 종단 문자열.mysql_list_fields() (을)를 사용할 때만 설정된다.

  • enum enum_field_types type

    필드의 형태. type 의 값은 다음의 어느 쪽인가에 된다.

    형태의 값 | 형태의 설명
    FIELD_TYPE_TINY | TINYINT 필드
    FIELD_TYPE_SHORT | SMALLINT 필드
    FIELD_TYPE_LONG | INTEGER 필드
    FIELD_TYPE_INT24 | MEDIUMINT 필드
    FIELD_TYPE_LONGLONG | BIGINT 필드
    FIELD_TYPE_DECIMAL | DECIMAL 또는 NUMERIC 필드
    FIELD_TYPE_FLOAT | FLOAT 필드
    FIELD_TYPE_DOUBLE | DOUBLE 또는 REAL 필드
    FIELD_TYPE_TIMESTAMP | TIMESTAMP 필드
    FIELD_TYPE_DATE | DATE 필드
    FIELD_TYPE_TIME | TIME 필드
    FIELD_TYPE_DATETIME | DATETIME 필드
    FIELD_TYPE_YEAR | YEAR 필드
    FIELD_TYPE_STRING | CHAR 필드
    FIELD_TYPE_VAR_STRING | VARCHAR 필드
    FIELD_TYPE_BLOB | BLOB 또는 TEXT 필드(max_length (을)를 사용해 최대장을 결정)
    FIELD_TYPE_SET | SET 필드
    FIELD_TYPE_ENUM | ENUM 필드
    FIELD_TYPE_NULL | NULL 형태 필드
    FIELD_TYPE_CHAR | 폐?~ (대신에 FIELD_TYPE_TINY (을)를 사용하는 것)

    IS_NUM() 매크로를 사용하면, 필드가 수치형인지 어떤지를 조사할 수 있다.type 의 값을 IS_NUM() 에 건네주면, 필드가 수치형의 경우는 TRUE (이)라고 평가된다.

    if (IS_NUM(field->type))
    printf("Field is numeric\n");

  • unsigned int length

    필드의 폭.테이블 정의로 지정된 값에 따른다.

  • unsigned int max_length

    결과 세트의 필드의 최대폭(결과 세트에 실제로 존재하는 레코드의 필드치의 최대장).mysql_store_result() 또는 mysql_list_fields() (을)를 사용했을 경우, 이 값은 필드의 최대장을 나타낸다.mysql_use_result() (을)를 사용했을 경우, 이 값은 0 (이)가 된다.

  • unsigned int flags

    필드의 다양한 상태를 나타내는 비트 플래그.flags 값은,0 또는 이하의 비트가 1 개이상 설정된 값이 된다.

    플래그의 값 | 플래그의 설명
    NOT_NULL_FLAG | NULL (을)를 설정할 수 없는 필드
    PRI_KEY_FLAG | 주키의 일부를 구성하는 필드
    UNIQUE_KEY_FLAG | 일의인 키의 일부를 구성하는 필드
    MULTIPLE_KEY_FLAG | 일의가 아닌 키의 일부를 구성하는 필드
    UNSIGNED_FLAG | UNSIGNED 속성을 가지는 필드
    ZEROFILL_FLAG | ZEROFILL 속성을 가지는 필드
    BINARY_FLAG | BINARY 속성을 가지는 필드
    AUTO_INCREMENT_FLAG | AUTO_INCREMENT 속성을 가지는 필드
    ENUM_FLAG | ENUM 형태의 필드(폐?~ )
    SET_FLAG | SET 형태의 필드(폐?~ )
    BLOB_FLAG | BLOB 형태 또는 TEXT 형태의 필드(폐?~ )
    TIMESTAMP_FLAG | TIMESTAMP 형태의 필드(폐?~ )

    BLOB_FLAG ,ENUM_FLAG ,SET_FLAG , 및 TIMESTAMP_FLAG 의 각 플래그는, 필드의 속성은 아니고 형태를 나타내고 있으므로, 폐?~ 되고 있다.대신에,field->type (을)를 FIELD_TYPE_BLOB ,FIELD_TYPE_ENUM ,FIELD_TYPE_SET , 또는 FIELD_TYPE_TIMESTAMP (와)과 비교하는 것이 바람직하다.

    다음에,flags 값의 전형적인 사용예를 나타낸다.

    if (field->flags & NOT_NULL_FLAG)
    printf("Field can't be null\n");

    이하의 매크로를 사용하면,flags 값을 조사해 불리언 값으로 결과를 얻을 수 있다.

    플래그 상태 | 설명
    IS_NOT_NULL(flags) | 이 필드가 NOT NULL (으)로서 정의되고 있는 경우는 True .
    IS_PRI_KEY(flags) | 이 필드가 주키의 경우는 True .
    IS_BLOB(flags) | 이 필드가 BLOB 또는 TEXT 의 경우는 True (폐?~ .대신에 field->type 에 의한 비교를 추천).

  • unsigned int decimals

    수치 필드의 소수부 자리수.

11.1.2. C API 함수의 개요

여기에서는,C API 그리고 제공되고 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이?~ 의 섹션으로 설명합니다. See 항11.1.3. 「C API 함수의 설명」 .

함수 | 설명
mysql_affected_rows() | 마지막에 실행되었다 UPDATE ,DELETE , 또는 INSERT 의 몇개의 쿼리에 의해서 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_change_user() | 오픈된 접속의 유저 및 데이타베이스를 변경한다.
mysql_character_set_name() | 접속의 디폴트의 캐릭터 세트의 이름을 돌려준다.
mysql_close() | 서버 접속을 절단 한다.
mysql_connect() | MySQL 서버에 접속한다.이 함수는 폐?~ 되고 있으므로, 대신에 mysql_real_connect() (을)를 사용하는 것.
mysql_create_db() | 데이타베이스를 작성한다.이 함수는 폐?~ 되고 있으므로, 대신에 SQL 커멘드 CREATE DATABASE (을)를 사용하는 것.
mysql_data_seek() | 쿼리 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_debug() | 지정된 문자열로 DBUG_PUSH (을)를 실행한다.
mysql_drop_db() | 데이타베이스를 파기한다.이 함수는 폐?~ 되고 있으므로, 대신에 SQL 커멘드 DROP DATABASE (을)를 사용하는 것.
mysql_dump_debug_info() | 디버그 정보를 로그에 쓰도록(듯이) 서버에 지시한다.
mysql_eof() | 결과 세트의 마지막 레코드가 읽혔는지를 판정한다. 이 함수는 폐?~ 되고 있어 대신에 mysql_errno() 또는 mysql_error() (을)를 사용할 수 있다.
mysql_errno() | 마지막에 불려 갔다 MySQL 함수의 에러 번호를 돌려준다.
mysql_error() | 마지막에 불려 갔다 MySQL 함수의 에러를 돌려준다.
mysql_escape_string() | 문자열에 포함되는 특수 문자를 이스케이프 하고,SQL 스테이트먼트로 사용할 수 있도록 한다.
mysql_fetch_field() | 테이블의 다음의 필드의 형태를 돌려준다.
mysql_fetch_field_direct() | 필드 번호로 지정된 테이블 필드의 형태를 돌려준다.
mysql_fetch_fields() | 모든 필드 구조체의 배열을 돌려준다.
mysql_fetch_lengths() | 현재의 레코드의 모든 컬럼에 대해 그 길이를 돌려준다.
mysql_fetch_row() | 결과 세트의 다음의 레코드를 취득한다.
mysql_field_seek() | 지정된 컬럼에 컬럼 커서를 이동한다.
mysql_field_count() | 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려준다.
mysql_field_tell() | 마지막에 실행되었다 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려준다.
mysql_free_result() | 결과 세트로 사용한 메모리를 해방한다.
mysql_get_client_info() | 클라이언트의 버젼 정보를 문자열로서 돌려준다.
mysql_get_client_version() | 클라이언트의 버젼 정보를 정수로서 돌려준다.
mysql_get_host_info() | 접속을 기술하는 문자열을 돌려준다.
mysql_get_server_version() | 서버의 버젼 번호를 정수로서 돌려준다(4.1 의 신기능).
mysql_get_proto_info() | 접속에 사용하고 있는 프로토콜의 버젼을 돌려준다.
mysql_get_server_info() | 서버의 버젼 번호를 돌려준다.
mysql_info() | 마지막에 실행된 쿼리에 관한 정보를 돌려준다.
mysql_init() | MYSQL 구조체를 취득 또는 초기화한다.
mysql_insert_id() | 전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려준다.
mysql_kill() | 지정된 스레드를 강제 종료한다.
mysql_list_dbs() | 단순한 정규 표현에 일치하는 데이타베이스명을 돌려준다.
mysql_list_fields() | 단순한 정규 표현에 일치하는 필드명을 돌려준다.
mysql_list_processes() | 현재의 서바스레드의 일람을 돌려준다.
mysql_list_tables() | 단순한 정규 표현에 일치하는 테이블명을 돌려준다.
mysql_num_fields() | 결과 세트의 컬럼수를 돌려준다.
mysql_num_rows() | 결과 세트의 레코드수를 돌려준다.
mysql_options() | mysql_connect() 의 접속 옵션을 설정한다.
mysql_ping() | 서버에의 접속이 정상적일지를 확인해, 필요하면 재접속한다.
mysql_query() | 눌 종단 문자열로서 지정되어 있다 SQL 쿼리를 실행한다.
mysql_real_connect() | MySQL 서버에 접속한다.
mysql_real_escape_string() | 접속의 현재의 캐릭터 세트를 고려하고, 문자열에 포함되는 특수 문자를 이스케이프 해,SQL 스테이트먼트로 사용할 수 있도록 한다.
mysql_real_query() | 아르바이트 문자열로서 지정되어 있다 SQL 쿼리를 실행한다.
mysql_reload() | 권한 테이블의 재독 봐 포함을 서버에 지시한다.
mysql_row_seek() | mysql_row_tell() (으)로부터 돌려주어진 값을 오프셋으로서 결과 세트내의 레코드에 시크 한다.
mysql_row_tell() | 레코드 커서의 위치를 돌려준다.
mysql_select_db() | 데이타베이스를 선택한다.
mysql_set_server_option() | 접속의 옵션(multi-statements 등)을 설정한다.
mysql_sqlstate() | 마지막에 발생한 에러의 SQLSTATE 에러 코드를 돌려준다.
mysql_shutdown() | 데이터 베이스 서버를 슛다운 한다.
mysql_stat() | 서버 스테이터스를 문자열로서 돌려준다.
mysql_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_thread_id() | 현재의 스레드 ID (을)를 돌려준다.
mysql_thread_safe() | 클라이언트가 스레드세이후로서 컴파일 되고 있는 경우는 1 (을)를 돌려준다.
mysql_use_result() | 레코드 단위의 결과 세트의 취득을 개시한다.
mysql_warning_count() | 전회 실행했다 SQL 스테이트먼트의 경고수를 돌려준다.
mysql_commit() | 트랜잭션(transaction)를 코?~ 트 한다(4.1 의 신기능).
mysql_rollback() | 트랜잭션(transaction)를 롤백(rollback) 한다(4.1 의 신기능).
mysql_autocommit() | 자동코?~ 트모드의 온/ 오프를 바꾼다(4.1 의 신기능).
mysql_more_results() | 아직 취득하고 있지 않는 결과 세트가 존재할지를 조사한다(4.1 의 신기능).
mysql_next_result() | 멀티 쿼리를 실행하고 있는 경우, 다음의 결과 세트를 취득해, 돌려준다(4.1 의 신기능).

서버에 접속하려면 ,mysql_init() (을)를 호출해 접속 핸들러를 초기화해, 다음에 그 핸들러( 및 호스트명, 유저명, 패스워드등의 그 외의 정보)를 파라미터로서 mysql_real_connect() (을)를 호출합니다.접속이 확립했을 때,mysql_real_connect() 에 의해서 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.접속이 필요없게 되면,mysql_close() (을)를 호출해 접속을 절단 합니다.

접속이 액티브한 경우, 클라이언트는 mysql_query() 또는 mysql_real_query() (을)를 사용해 서버에 SQL 쿼리를 송신할 수 있습니다.이 2 개의 차이는,mysql_query() (은)는 쿼리를 눌 종단 문자열로서mysql_real_query() (은)는 쿼리를 아르바이트 문자열로서 각각 받습니다.문자열에 바이너리 데이터가 포함되는(누르바이트가 포함될 가능성이 있다) 경우는,mysql_real_query() (을)를 사용할 필요가 있습니다.

비 SELECT 쿼리(예를 들어,INSERT ,UPDATE ,DELETE )(을)를 실행했을 경우, 변경된(영향을 받은) 레코드의 수를 알려면 ,mysql_affected_rows() (을)를 호출합니다.

SELECT 쿼리를 실행했을 경우, 선택된 레코드를 결과 세트로서 취득합니다(주의: SHOW ,DESCRIBE , 및 EXPLAIN (와)과 같이, 레코드를 돌려준다고 하는 점으로 SELECT (을)를 닮아 있는 스테이트먼트가 있어, 이것들은 SELECT 스테이트먼트와 같게 취급할 필요가 있습니다).

클라이언트가 결과 세트를 처리하는 방법은 2 개 있습니다.1 개는,mysql_store_result() (을)를 호출해 결과 세트 전체를 일괄해 취득하는 방법입니다.이 함수는, 쿼리로부터 돌려주어진 모든 레코드를 서버로부터 취득해, 클라이언트에 보존합니다.이제(벌써) 1 개는,mysql_use_result() (을)를 호출하고, 클라이언트가 레코드 단위로 결과 세트의 취득을 개시하는 방법입니다.이 함수는 결과 세트를 취득하는 처리의 초기화는 실시합니다만, 실제로는 서버로부터 레코드를 받고 있지 않습니다.

어느 쪽의 경우도, 레코드에 액세스 하려면 mysql_fetch_row() (을)를 호출합니다.mysql_store_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는, 벌써 서버로부터 취득되고 있는 레코드에 액세스 합니다.mysql_use_result() (을)를 사용했을 경우,mysql_fetch_row() (은)는 실제로 서버로부터 레코드를 취득합니다.각 레코드의 데이터 사이즈는,mysql_fetch_lengths() (을)를 호출하는 것에 의해서 알 수 있습니다.

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출하고, 사용하고 있던 메모리를 해방합니다.

2 개의 취득 메카니즘은, 상황에 따라 구분하여 사용합니다.클라이언트 프로그램은, 필요에 따라서 가장 적절한 방법을 선택할 필요가 있습니다.실제로는,mysql_store_result() (을)를 다용하는 경향이 있습니다.

mysql_store_result() 의 장점은, 모든 레코드가 클라이언트에 취득이 끝난 상태이므로, 레코드에 차례차례 액세스 가능할 뿐만 아니라,mysql_data_seek() 또는 mysql_row_seek() (을)를 사용해 결과 세트내에서의 경향 레코드의 위치를 변경하는 것에 의해서, 결과 세트내를 전후로 이동할 수 있는 것입니다.결과 세트에 포함되는 레코드수를 알려면 ,mysql_num_rows() (을)를 호출합니다.한편, 결과 세트가 큰 경우의 mysql_store_result() 의 메모리 요건은 매우 어려운 경우가 있어, 메모리 부족이 발생할 가능성은 높아집니다.

mysql_use_result() 의 장점은, 한 번에 1 행의 레코드 밖에 보관 유지하지 않기 때문에, 클라이언트가 결과 세트로 사용하는 메모리가 적어도 되는 것입니다(또, 메모리 할당의 오버헤드가 적기 때문에 mysql_use_result() 의 실행 속도도 향상합니다).단점은, 서버를 구속하지 않게 각 레코드에 대한 처리를 단시간에 끝낼 필요가 있는 것, 결과 세트내의 레코드에 대한 랜덤 억세스 기능이 없는 것(차례차례 액세스만), 모든 레코드를 취득할 때까지 결과 세트에 포함되는 레코드수를 모르는 것입니다.게다가 찾고 있던 정보가 차례차례 액세스의 도중에 발견되었을 경우에서도, 끝까지 모든 레코드를 취득한다 필요가 있습니다 .

클라이언트는 API (을)를 사용하는 것으로, 쿼리가 SELECT 화도인가를 몰라도, 쿼리에 대해서 적절히 응답하는(필요에 따라서 레코드를 취득한다) 일이 생깁니다.그러기 위해서는,mysql_query() (또는 mysql_real_query() )(을)를 호출할 때마다 mysql_store_result() (을)를 호출합니다.이 호출이 정상 종료했을 경우, 쿼리는 SELECT (이었)였던 것으로 되고, 레코드를 읽어들일 수 있습니다.호출이 실패했을 경우,mysql_field_count() (을)를 호출하고, 이 결과가 쿼리의 결과로서 예상된 것이었다 화도인지를 판단합니다.mysql_field_count() 하지만 0 (을)를 돌려주었을 경우, 쿼리가 돌려준 데이터는 없고(INSERT ,UPDATE ,DELETE 등의 쿼리였던 일을 의미한다), 레코드를 돌려주는 쿼리는 아니었다고 판단됩니다.mysql_field_count() 하지만 0 이외의 값을 돌려주었을 경우, 레코드를 돌려주어야할 쿼리가 실행되었지만, 아무것도 돌려주지 않았다고 판단됩니다.이것은,SELECT 쿼리가 실패한 것을 의미합니다.여기에 나타낸 방법의 코딩예에 대해서는,mysql_field_count() 의 설명을 참조해 주세요.

mysql_store_result() 및 mysql_use_result() (은)는 어느쪽이나, 결과 세트를 구성하는 필드에 관한 정보(필드의 수, 이름, 형태등)를 취득합니다.레코드의 필드 정보로 차례차례 액세스 하려면 ,mysql_fetch_field() (을)를 반복해 호출하는지, 또는 레코드의 필드 번호를 지정해 mysql_fetch_field_direct() (을)를 호출합니다.현재의 필드 커서의 위치를 변경하려면 ,mysql_field_seek() (을)를 호출합니다.필드 커서의 위치를 변경하면, 그 후에 불려 갔다 mysql_fetch_field() 의 동작에 영향을 줍니다.mysql_fetch_fields() (을)를 호출하면, 모든 필드의 정보를 일괄해 취득할 수 있습니다.

에러를 검출해, 보고하는 경우,mysql_errno() 및 mysql_error() (을)를 사용해 에러 정보로 액세스 합니다.이 2 개의 함수는, 마지막에 불려 간, 성공 또는 실패의 가능성이 있는 함수의 에러 코드 또는 에러 메세지를 돌려줍니다.이 결과에 의해서, 에러가 발생한 타이?~ 그와 그 내용을 판단합니다.

11.1.3. C API 함수의 설명

여기의 설명속에서, 파라미터 또는 반환값에 NULL 하지만 사용되고 있는 경우, 이것은 C 언어에 있어서의 NULL (을)를 나타내고 있어MySQL 에 있어서의 NULL 값이 아닙니다.

값을 돌려주는 함수는, 일반적으로 포인터 또는 정수를 돌려줍니다.특히 지정되어 있지 않은 한, 포인터를 돌려주는 함수가 비 NULL 값을 돌려주었을 경우는 정상 종료를,NULL 값을 돌려주었을 경우는 에러를 나타냅니다.같이 정수를 돌려주는 함수가 0 (을)를 돌려주었을 경우는 정상 종료를,0 이외의 값을 돌려주었을 경우는 에러를 나타냅니다.주의: ``0 이외'' 그렇다고 하는 것에, 그 이상의 의미는 없습니다.함수 설명에 특히 기술이 없는 한,0 이외의 값에 대해서 비교 테스트는 필요 없습니다.

if (result)                   /* correct */
    ... error ...

if (result < 0)               /* incorrect */
    ... error ...

if (result == -1)             /* incorrect */
    ... error ...

함수가 돌려주는 에러에 대해서는, 함수 설명안의 「 에러 」서브 섹션을 참조해 주세요.발생한 에러를 조사하려면 ,mysql_errno() (을)를 호출합니다.mysql_error() (을)를 호출하면, 에러 내용의 문자열 표현을 취득할 수 있습니다.

11.1.3.1. mysql_affected_rows()

my_ulonglong mysql_affected_rows(MYSQL *mysql)

설명

마지막에 불려 갔다 UPDATE 에 의해서 변경된 레코드수, 마지막에 불려 갔다 DELETE 에 의해서 삭제된 레코드수, 또는 마지막에 불려 갔다 INSERT 에 의해서 삽입된 레코드수를 돌려줍니다.UPDATE ,DELETE , 또는 INSERT 의 몇개의 스테이트먼트에 대해 mysql_query() (을)를 호출한 후에, 이 함수를 호출합니다.SELECT 스테이트먼트의 경우,mysql_affected_rows() (을)를 호출하면,mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해서 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타내 보입니다.-1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_store_result() (을)를 호출하기 전에 mysql_affected_rows() 하지만 불려 간 것을 나타내 보입니다.

에러

없습니다.

례

mysql_query(&mysql,"UPDATE products SET cost=cost*1.25 WHERE group=10");
printf("%ld products updated",(long) mysql_affected_rows(&mysql));

mysqld 에 접속할 때에 플래그 CLIENT_FOUND_ROWS 하지만 지정되어 있는 경우,mysql_affected_rows() 하 UPDATE 스테이트먼트의 WHERE 마디에 일치하는 레코드수를 돌려줍니다.

주의: REPLACE 커멘드로 기존의 레코드가 새로운 레코드로 옮겨놓을 수 있었을 경우는 mysql_affected_rows() 하 2 (을)를 돌려줍니다.이것은, 레코드가 1 행 삽입된 다음에 중복 한 레코드가 삭제되었기 때문입니다.

11.1.3.2. mysql_change_user()

my_bool mysql_change_user(MYSQL *mysql, const char *user, const char *password, const char *db)

설명

유저를 변경해,db 그리고 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

이 함수는,MySQL 3.23.3 그리고 도입되었습니다.

mysql_change_user() (은)는, 지정한 유저가 인증되지 않는 경우, 또는 그 유저가 데이타베이스를 사용하는 권한을 가지지 않는 경우에, 실패합니다.이 경우, 유저 및 데이타베이스는 변경되지 않습니다.

디폴트 데이타베이스를 사용하지 않는 경우,db 파라미터를 NULL (으)로 설정합니다.

MySQL 4.0.6 이?~ , 이 커멘드는, 새로운 접속이 확립했을 경우는 항상, 임의의 액티브한 트랜잭션(transaction)의 ROLLBACK 의 실행, 모든 텐포라리테이불의 클로우즈, 락 된 모든 테이블의 언로크, 및 상태의 리셋트를 실시합니다.이 처리는, 유저가 변경되지 않았던 경우도 반드시 행해집니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

mysql_real_connect() 하지만 돌려주는 에러와 같다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • ER_UNKNOWN_COM_ERROR

    MySQL 서버로 이 커멘드가 실장되어 있지 않다(버젼이 낡다고 생각할 수 있다).

  • ER_ACCESS_DENIED_ERROR

    유저 또는 패스워드가 올바르지 않다.

  • ER_BAD_DB_ERROR

    데이타베이스가 존재하지 않는다.

  • ER_DBACCESS_DENIED_ERROR

    유저가 데이타베이스에의 액세스권을 가지고 있지 않다.

  • ER_WRONG_DB_NAME

    데이타베이스명이 너무 길다.

례

if (mysql_change_user(&mysql, "user", "password", "new_database"))
{
   fprintf(stderr, "Failed to change user.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.3. mysql_character_set_name()

const char *mysql_character_set_name(MYSQL *mysql)

설명

현재의 접속의 디폴트의 캐릭터 세트를 돌려줍니다.

반환값

디폴트의 캐릭터 세트.

에러

없습니다.

11.1.3.4. mysql_close()

void mysql_close(MYSQL *mysql)

설명

벌써 오픈되고 있는 접속을 클로우즈 합니다.mysql 그리고 나타나는 접속 핸들이 mysql_init() 또는 mysql_connect() 에 의해서 자동적으로 할당할 수 있었던 핸들이었던 경우는,mysql_close() 그리고 할당이 해제됩니다.

반환값

없습니다.

에러

없습니다.

11.1.3.5. mysql_connect()

MYSQL *mysql_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd)

설명

이 함수는 폐?~ 되고 있습니다.대신에 mysql_real_connect() (을)를 사용해 주세요.

mysql_connect() (은)는,host 위에서 실행하고 있다 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 의미는,mysql_real_connect() (으)로의 대응하는 파라미터와 같습니다만, 접속 파라미터에 NULL (을)를 건네줄 수 있다고 하는 차이가 있습니다.이 경우,C API (은)는 접속 구조체에 자동적으로 메모리를 할당합니다.이 메모리는 mysql_close() (을)를 호출하는 것에 의해서 해방됩니다.이 방법에는, 접속에 실패했을 때에 에러 메세지를 취득할 수 없다고 하는 단점이 있습니다(mysql_errno() 또는 mysql_error() (으)로부터 에러 정보를 취득하려면 유효한 MYSQL 포인터를 건네줄 필요가 있습니다).

반환값

mysql_real_connect() (와)과 같습니다.

에러

mysql_real_connect() (와)과 같습니다.

11.1.3.6. mysql_create_db()

int mysql_create_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름으로 데이타베이스를 작성합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 CREATE DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 작성되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_create_db(&mysql, "my_database"))
{
   fprintf(stderr, "Failed to create new database.  Error: %s\n",
           mysql_error(&mysql));
}

11.1.3.7. mysql_data_seek()

void mysql_data_seek(MYSQL_RES *result, my_ulonglong offset)

설명

쿼리 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_data_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.3.8. mysql_debug()

void mysql_debug(const char *debug)

설명

지정된 문자열로 DBUG_PUSH (을)를 실행합니다.mysql_debug() (은)는,Fred Fish 디버그 라이브러리를 사용합니다.이 함수를 사용하려면 , 디버그를 서포트하기 위한 클라이언트 라이브러리를 컴파일 할 필요가 있습니다. See 항E.1. 「MySQL 서버의 디버그」 . See 항E.2. 「MySQL 클라이언트의 디버그」 .

반환값

없습니다.

에러

없습니다.

례

다음의 코드를 실행하면, 클라이언트 라이브러리에 의해서 클라이언트 머신의 /tmp/client.trace 에 트레이스 파일이 생성됩니다.

mysql_debug("d:t:O,/tmp/client.trace");

11.1.3.9. mysql_drop_db()

int mysql_drop_db(MYSQL *mysql, const char *db)

설명

db 파라미터로 지정된 이름의 데이타베이스를 파기합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 DROP DATABASE 스테이트먼트를 발행해 주세요.

반환값

데이타베이스가 정상적으로 파기되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

if(mysql_drop_db(&mysql, "my_database"))
  fprintf(stderr, "Failed to drop the database: Error: %s\n",
          mysql_error(&mysql));

11.1.3.10. mysql_dump_debug_info()

int mysql_dump_debug_info(MYSQL *mysql)

설명

디버그 정보를 로그에 쓰도록(듯이) 서버에 지시합니다.접속 유저가 SUPER 특권을 가지지 않는 경우는 정상적으로 동작하지 않습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.11. mysql_eof()

my_bool mysql_eof(MYSQL_RES *result)

설명

이 함수는 폐?~ 되고 있습니다.대신에 mysql_errno() 또는 mysql_error() (을)를 사용할 수 있습니다.

mysql_eof() (은)는, 결과 세트의 마지막 레코드가 읽혔는지를 판정합니다.

mysql_store_result() (을)를 호출해 결과 세트를 취득하는 경우, 클라이언트는 1 회의 동작으로 결과 세트 전체를 받습니다.이 경우,mysql_fetch_row() (을)를 호출해 반환값이 NULL 이면, 벌써 결과 세트의 마지막에 도달하고 있던 것을 알 수 있으므로,mysql_eof() (을)를 호출할 필요는 없습니다.mysql_store_result() (와)과 함께 사용하는 경우,mysql_eof() (은)는 항상 true (을)를 돌려줍니다.

한편,mysql_use_result() (을)를 사용해 결과 세트의 취득을 개시했을 경우는,mysql_fetch_row() (을)를 반복해 호출하는 것에 의해서 그 레코드를 1 행씩 서버로부터 취득합니다.이 순서를 실행하고 있는 도중에 접속에 이상이 발생하는 경우가 있으므로,mysql_fetch_row() (을)를 호출해 반환값이 NULL 에서 만나도, 그것이 반드시 결과 세트의 마지막에 정상적으로 도달한 것을 의미하는 것은 아닙니다.이 경우는,mysql_eof() (을)를 사용하는 것에 의해서, 어떤 상황인가를 판단할 수 있습니다.mysql_eof() (은)는, 결과 세트의 마지막에 도달하고 있었을 경우는 0 이외, 에러가 발생하고 있었을 경우는 0 (을)를 돌려줍니다.

mysql_eof() (은)는, 역사적으로는 표준의 MySQL 에러 함수이다 mysql_errno() 및 mysql_error() 의 전신입니다.이러한 에러 함수는 같은 정보를 돌려주므로, 벌써 폐?~ 되고 있다 mysql_eof() 보다 우선해 사용해 주세요(실제,mysql_eof() 하지만 돌려주는 것은 불리언 값만으로, 에러 함수는 에러 발생 이유를 나타내는 것보다 많은 정보를 돌려줍니다).

반환값

에러가 발생하고 있지 않는 경우는 0 .결과 세트의 마지막에 도달하고 있었을 경우는 0 이외.

에러

없습니다.

례

mysql_eof() 에는 다음과 같은 사용법을 생각할 수 있습니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(!mysql_eof(result))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

다만, 표준의 MySQL 에러 함수를 다음과 같이 사용하면, 같은 동작을 실현할 수 있습니다.

mysql_query(&mysql,"SELECT * FROM some_table");
result = mysql_use_result(&mysql);
while((row = mysql_fetch_row(result)))
{
    // do something with data
}
if(mysql_errno(&mysql))  // mysql_fetch_row() failed due to an error
{
    fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
}

11.1.3.12. mysql_errno()

unsigned int mysql_errno(MYSQL *mysql)

설명

mysql_errno() (은)는,mysql 그리고 지정되는 접속에 대해서, 마지막에 불려 간, 성공 또는 실패할 가능성이 있다 API 함수의 에러 코드를 돌려줍니다.반환값이 0 의 경우, 에러는 발생하고 있지 않습니다.클라이언트의 에러 메세지 번호의 일람은,MySQL errmsg.h 헤더 파일에 기술되고 있습니다.서버의 에러 메세지 번호의 일람은,mysqld_error.h 에 기술되고 있습니다.MySQL 소스 디스트리뷰션에 포함되는 파일 Docs/mysqld_error.txt 에는, 모든 에러 메세지 및 에러 번호의 일람이 기술되고 있습니다.서버의 에러 코드의 일람은, 항12.1. 「돌려주어지는 에러」 에도 기재되어 있습니다.

주의: mysql_fetch_row() 등의 일부의 함수는, 성공했을 경우에 mysql_errno() (을)를 설정하지 않습니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_errno() (을)를 리셋트 한다고 생각해 주세요.

반환값

마지막에 불려 갔다 mysql_xxx 함수가 실패하고 있었을 경우는 그 에러 코드.0 (은)는 에러가 발생하지 않았던 것을 나타냅니다.

에러

없습니다.

11.1.3.13. mysql_error()

const char *mysql_error(MYSQL *mysql)

설명

mysql_error() (은)는,mysql 그리고 지정된 접속에 대해서, 마지막에 불려 갔다 API 함수가 실패했을 때의 에러 메세지를 눌 종단 문자열로서 돌려줍니다.함수가 실패하지 않았던 경우,mysql_error() 의 반환값은 그 전의 에러 메세지인가, 에러가 전혀 발생하고 있지 않는 경우는 공문자열이 됩니다.

대개의 기준으로서 서버에 정보를 요구하는 함수는, 성공했을 경우에 mysql_error() (을)를 리셋트 한다고 생각해 주세요.

mysql_errno (을)를 리셋트 하는 함수에서는, 다음의 2 개의 비교는 동등합니다.

if(mysql_errno(&mysql))
{
    // an error occurred
}

if(mysql_error(&mysql)[0] != '\0')
{
    // an error occurred
}

클라이언트의 에러 메세지의 언어는,MySQL 클라이언트 라이브러리를 재컴파일 하는 것에 의해서 변경할 수 있습니다.현재는, 복수가 다른 언어로 에러 메세지를 돌려줄 수 있습니다. See 항4.7.2. 「영어 이외의 에러 메세지」 .

반환값

에러의 내용을 설명하는 눌 종단 문자열.에러가 발생하고 있지 않는 경우는 공문자열.

에러

없습니다.

11.1.3.14. mysql_escape_string()

이 함수 대신에 mysql_real_escape_string() (을)를 사용해 주세요.

mysql_real_escape_string() (은)는 선두의 인수로서 접속 핸들러를 받아, 현재의 캐릭터 세트에 따라서 문자열을 이스케이프 합니다만, 그 2 점을 제외하면, 이 함수와 mysql_real_escape_string() (은)는 같습니다.mysql_escape_string() (은)는 접속 핸들러를 인수로서 받지 않습니다.또, 현재의 캐릭터 세트는 참조하지 않습니다.

11.1.3.15. mysql_fetch_field()

MYSQL_FIELD *mysql_fetch_field(MYSQL_RES *result)

설명

결과 세트에 포함된다 1 살의 컬럼의 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.결과 세트에 포함되는 모든 컬럼의 정의를 취득하려면 , 이 함수를 반복해 호출합니다.정의를 취득하는 컬럼이 남지 않은 경우,mysql_fetch_field() 하 NULL (을)를 돌려줍니다.

새롭고 SELECT 쿼리를 실행할 때마다,mysql_fetch_field() (은)는 선두의 컬럼의 정의를 돌려주도록(듯이) 리셋트 됩니다.또,mysql_field_seek() (을)를 호출했을 경우도,mysql_fetch_field() 하지만 돌려주는 필드가 바뀝니다.

mysql_query() (을)를 호출해 테이블에 대해서 SELECT (을)를 실행한 후 mysql_store_result() (을)를 호출하지 않았던 경우,mysql_fetch_field() (을)를 호출해 BLOB 필드의 길이를 요구하면, 디폴트의 BLOB 장(8 킬로바이트)가 돌려주어집니다(MySQL 하 BLOB 의 최대장을 모르기 때문에 8 킬로바이트를 돌려줍니다.이 값은 장래 설정 가능한 값으로 할 필요가 있습니다).결과 세트를 취득한 다음은, 그 쿼리에 있어서의 이 컬럼의 최대치의 길이가 field->max_length 에게 건네집니다.

반환값

현재의 컬럼의 MYSQL_FIELD 구조체.컬럼이 남지 않은 경우는 NULL .

에러

없습니다.

례

MYSQL_FIELD *field;

while((field = mysql_fetch_field(result)))
{
    printf("field name %s\n", field->name);
}

11.1.3.16. mysql_fetch_fields()

MYSQL_FIELD *mysql_fetch_fields(MYSQL_RES *result)

설명

결과 세트의 모든 MYSQL_FIELD 구조체의 배열을 돌려줍니다.각 구조체에는, 결과 세트에 포함된다 1 살의 컬럼의 필드 정의가 격납되고 있습니다.

반환값

결과 세트에 포함되는 모든 컬럼의 MYSQL_FIELD 구조체의 배열.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *fields;

num_fields = mysql_num_fields(result);
fields = mysql_fetch_fields(result);
for(i = 0; i < num_fields; i++)
{
   printf("Field %u is %s\n", i, fields[i].name);
}

11.1.3.17. mysql_fetch_field_direct()

MYSQL_FIELD *mysql_fetch_field_direct(MYSQL_RES *result, unsigned int fieldnr)

설명

필드 번호 fieldnr 그리고 지정되는 결과 세트의 컬럼의 필드 정의를 MYSQL_FIELD 구조체로서 돌려줍니다.이 함수를 사용하면, 임의의 컬럼의 정의를 취득할 수 있습니다.fieldnr 의 값은 0 (으)로부터 mysql_num_fields(result)-1 의 범위에서 지정합니다.

반환값

지정한 컬럼의 MYSQL_FIELD 구조체.

에러

없습니다.

례

unsigned int num_fields;
unsigned int i;
MYSQL_FIELD *field;

num_fields = mysql_num_fields(result);
for(i = 0; i < num_fields; i++)
{
    field = mysql_fetch_field_direct(result, i);
    printf("Field %u is %s\n", i, field->name);
}

11.1.3.18. mysql_fetch_lengths()

unsigned long *mysql_fetch_lengths(MYSQL_RES *result)

설명

결과 세트내의 경향 레코드의 컬럼의 길이를 돌려줍니다.필드치를 카피하려고 하는 경우, 이 함수를 사용하면 strlen() (을)를 호출하지 않아도 길이를 취득할 수 있으므로 편리합니다.또, 결과 세트에 바이너리 데이터가 포함되어 있는 경우,strlen() (은)는 눌 문자가 포함되는 필드의 길이를 올바르게 돌려주지 않기 때문에, 이 함수를 사용해 데이터 사이즈를 조사한다 필요가 있습니다 .

하늘의 컬럼 및 NULL 값을 포함한 컬럼의 길이는 0 입니다.이 2 개를 구별하는 방법에 대해서는,mysql_fetch_row() 의 설명을 참조해 주세요.

반환값

각 컬럼의 사이즈(눌 종단 문자는 세지 않는다)를 나타낸다 unsigned long 정수의 배열.에러가 발생했을 경우는 NULL .

에러

mysql_fetch_lengths() (은)는 결과 세트의 경향 레코드에서만 유효합니다.mysql_fetch_row() (을)를 호출하기 전 또는 결과 세트의 모든 레코드를 취득한 다음에 불려 갔을 경우는 NULL (을)를 돌려줍니다.

례

MYSQL_ROW row;
unsigned long *lengths;
unsigned int num_fields;
unsigned int i;

row = mysql_fetch_row(result);
if (row)
{
    num_fields = mysql_num_fields(result);
    lengths = mysql_fetch_lengths(result);
    for(i = 0; i < num_fields; i++)
    {
         printf("Column %u is %lu bytes in length.\n", i, lengths[i]);
    }
}

11.1.3.19. mysql_fetch_row()

MYSQL_ROW mysql_fetch_row(MYSQL_RES *result)

설명

결과 세트의 다음의 레코드를 취득합니다.mysql_store_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않으면 NULL (을)를 돌려줍니다.mysql_use_result() (을)를 호출한 후에 mysql_fetch_row() (을)를 사용하는 경우, 취득하는 레코드가 남지 않은지, 또는 에러가 발생했을 때에 NULL (을)를 돌려줍니다.

레코드에 포함되는 값의 수는 mysql_num_fields(result) 에 의해서 취득합니다.mysql_fetch_row() (을)를 호출해 그 반환값이 row 에 격납되고 있는 경우, 값에의 포인터는 row[0] (으)로부터 row[mysql_num_fields(result)-1] (와)과 같이 나타내집니다.NULL 포인터는, 레코드의 값이 NULL 값인 것을 나타냅니다.

mysql_fetch_lengths() (을)를 호출하면, 레코드의 필드치의 길이를 취득할 수 있습니다.하늘의 필드 및 NULL (을)를 포함한 필드의 길이는 어느쪽이나 0 그렇지만, 그 필드의 포인터를 조사하는 것에 의해서 그 2 개를 구별할 수 있습니다.포인터가 NULL 의 경우, 필드의 값은 NULL 입니다.그 이외의 경우, 필드는 하늘입니다.

반환값

다음의 레코드의 MYSQL_ROW 구조체.취득하는 레코드가 남지 않은지, 에러가 발생했을 경우는 NULL .

에러

주의: mysql_fetch_row() (을)를 1 회 호출하고 나서, 다음에 호출할 때까지 에 에러가 리셋트 될 것은 없습니다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

MYSQL_ROW row;
unsigned int num_fields;
unsigned int i;

num_fields = mysql_num_fields(result);
while ((row = mysql_fetch_row(result)))
{
   unsigned long *lengths;
   lengths = mysql_fetch_lengths(result);
   for(i = 0; i < num_fields; i++)
   {
       printf("[%.*s] ", (int) lengths[i], row[i] ? row[i] : "NULL");
   }
   printf("\n");
}

11.1.3.20. mysql_field_count()

unsigned int mysql_field_count(MYSQL *mysql)

MySQL 3.22.24 보다 낡은 버젼을 사용하고 있는 경우, 이 함수 대신에 unsigned int mysql_num_fields(MYSQL *mysql) (을)를 사용해 주세요.

설명

현재의 접속으로 마지막에 실행된 쿼리의 결과 세트의 컬럼수를 돌려줍니다.

통상 이 함수는,mysql_store_result() 하지만 NULL (을)를 돌려주었을 때(결과 세트 포인터가 돌려주어지지 않았을 때)에 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해서,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해서, 클라이언트 프로그램은, 쿼리가 SELECT (또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql,query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if(mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
        else // mysql_store_result() should have returned data
        {
            fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
    }
}

mysql_field_count(&mysql) 의 호출 부분을 mysql_errno(&mysql) 에 옮겨놓는 방법도 있습니다.이 경우, 스테이트먼트가 SELECT (이었)였는지 아닌지는,mysql_field_count() 하지만 돌려주는 값으로부터 추측하는 것이 아니라,mysql_store_result() 하지만 돌려주는 에러를 직접 조사하고 판단합니다.

11.1.3.21. mysql_field_seek()

MYSQL_FIELD_OFFSET mysql_field_seek(MYSQL_RES *result, MYSQL_FIELD_OFFSET offset)

설명

필드 커서의 위치를 지정된 오프셋으로 설정합니다.다음에 mysql_fetch_field() (을)를 호출하면, 그 오프셋에 관련지을 수 있었던 컬럼의 필드 정의를 돌려줍니다.

레코드의 선두에 시크 하려면 ,offset 값에 0 (을)를 건네줍니다.

반환값

시크 하기 전의 필드 커서의 값.

에러

없습니다.

11.1.3.22. mysql_field_tell()

MYSQL_FIELD_OFFSET mysql_field_tell(MYSQL_RES *result)

설명

마지막에 실행되었다 mysql_fetch_field() 그리고 사용된 필드 커서의 위치를 돌려줍니다.이 반환값을,mysql_field_seek() 에 인수로서 건네줄 수 있습니다.

반환값

필드 커서의 현재의 오프셋.

에러

없습니다.

11.1.3.23. mysql_free_result()

void mysql_free_result(MYSQL_RES *result)

설명

          mysql_store_result()
,mysql_use_result()
,mysql_list_dbs()

등이 결과 세트에 할당한 메모리를 해방합니다.결과 세트가 필요없게 되면,mysql_free_result()

(을)를 호출하고, 사용하고 있던 메모리를 해방합니다.

반환값

없습니다.

에러

없습니다.

11.1.3.24. mysql_get_client_info()

char *mysql_get_client_info(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 문자열을 돌려줍니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 문자열.

에러

없습니다.

11.1.3.25. mysql_get_client_version()

unsigned long mysql_get_client_version(void)

설명

클라이언트의 라이브러리 버젼을 나타내는 정수를 돌려줍니다.이 값은 XYYZZ 그렇다고 하는 형식에서 나타내져X (은)는 메이저 버젼,YY (은)는 릴리스 레벨,ZZ (은)는 릴리스 레벨내의 버젼 번호입니다.예를 들어,40102 (은)는, 클라이언트의 라이브러리 버젼이 4.1.2 인 것을 나타냅니다.

반환값

MySQL 클라이언트의 라이브러리 버젼을 나타내는 정수.

에러

없습니다.

11.1.3.26. mysql_get_host_info()

char *mysql_get_host_info(MYSQL *mysql)

설명

사용하고 있는 접속의 타입을 나타내는 문자열을 돌려줍니다.이 문자열에는 서버의 호스트명도 포함됩니다.

반환값

서버의 호스트명 및 접속 타입을 나타내는 문자열.

에러

없습니다.

11.1.3.27. mysql_get_proto_info()

unsigned int mysql_get_proto_info(MYSQL *mysql)

설명

현재의 접속에 사용하고 있는 프로토콜의 버젼을 돌려줍니다.

반환값

현재의 접속에 사용하고 있는 프로토콜의 버젼을 나타낸다 unsigned 정수.

에러

없습니다.

11.1.3.28. mysql_get_server_info()

char *mysql_get_server_info(MYSQL *mysql)

설명

서버의 버젼 번호를 나타내는 문자열을 돌려줍니다.

반환값

서버의 버젼 번호를 나타내는 문자열.

에러

없습니다.

11.1.3.29. mysql_get_server_version()

unsigned long mysql_get_server_version(MYSQL *mysql)

설명

서버의 버젼 번호를 정수로서 돌려줍니다(4.1 의 신기능).

반환값

MySQL 서버의 버젼을 다음의 형식에서 나타내는 번호.

main_version*10000 + minor_version *100 + sub_version

예를 들어, 버젼이 4.1.0 의 경우, 반환값은 40100 입니다.

이 값을 사용하면, 클라이언트 프로그램은 서버의 버젼으로부터 특정의 기능이 존재할지를 간단하게 판단할 수 있습니다.

에러

없습니다.

11.1.3.30. mysql_info()

char *mysql_info(MYSQL *mysql)

설명

마지막에 실행한 쿼리에 관한 정보를 나타내는 문자열을 취득합니다.다만, 대상이 되는 것은, 이하의 일람에 포함되는 스테이트먼트만입니다.마지막에 실행한 것이 다른 스테이트먼트의 쿼리였던 경우는,mysql_info() 하 NULL (을)를 돌려줍니다.문자열의 형식은, 이하에 설명하도록(듯이), 쿼리의 타입에 따라서 다릅니다.숫자는 예로서 나타내 보인 것입니다.실제의 문자열에는 실행한 쿼리에 맞은 값이 사용됩니다.

  • INSERT INTO ...SELECT ...

    문자열의 형식: Records: 100 Duplicates: 0 Warnings: 0

  • INSERT INTO ...VALUES (...),(...),(...)...

    문자열의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • LOAD DATA INFILE ...

    문자열의 형식: Records: 1 Deleted: 0 Skipped: 0 Warnings: 0

  • ALTER TABLE

    문자열의 형식: Records: 3 Duplicates: 0 Warnings: 0

  • UPDATE

    문자열의 형식: Rows matched: 40 Changed: 40 Warnings: 0

주의: mysql_info() (은)는,INSERT ... VALUES 스테이트먼트가 복수 레코드를 삽입하는 형식의 경우에 한정해(복수의 값리스트가 지정되었을 경우에 한정해),NULL 이외의 값을 돌려줍니다.

반환값

마지막에 실행한 쿼리에 관한 정보를 나타내는 문자열.쿼리의 정보가 없는 경우는 NULL .

에러

없습니다.

11.1.3.31. mysql_init()

MYSQL *mysql_init(MYSQL *mysql)

설명

mysql_real_connect() 에 적응한다 MYSQL 오브젝트를 할당해 또는 초기화합니다.mysql 에 NULL 포인터를 건네주었을 경우, 함수는 새로운 오브젝트에 메모리를 할당해 초기화해, 그것을 돌려줍니다.그 이외의 값을 건네주었을 경우는, 오브젝트를 초기화해, 그 주소를 돌려줍니다.mysql_init() 하지만 새로운 오브젝트에 메모리를 할당했을 경우, 그 메모리는 mysql_close() (을)를 호출해 접속을 클로우즈 할 때에 해방됩니다.

반환값

초기화되었다 MYSQL* 핸들.새로운 오브젝트에 할당하는 충분한 메모리가 없었던 경우는 NULL .

에러

메모리가 부족했을 경우는 NULL (을)를 돌려줍니다.

11.1.3.32. mysql_insert_id()

my_ulonglong mysql_insert_id(MYSQL *mysql)

설명

전회 실행된 쿼리로 생성했다 AUTO_INCREMENT 컬럼의 ID (을)를 돌려줍니다.이 함수는,AUTO_INCREMENT 필드를 포함한 테이블에 대해서 INSERT 쿼리를 실행한 다음에 사용합니다.

주의: mysql_insert_id() (은)는, 전회 실행된 쿼리로 AUTO_INCREMENT 값이 생성되지 않았던 경우는,0 (을)를 돌려줍니다.장래를 위해서 그 값을 보존할 필요가 있는 경우는, 그것을 생성하는 쿼리의 직후에 mysql_insert_id() (을)를 호출할 필요가 있습니다.

전회 실행된 쿼리가 에러를 돌려주었을 경우에 대해서는,mysql_insert_id() 의 값은 미정도리입니다.

mysql_insert_id() (은)는,AUTO_INCREMENT 값을 생성하는지, 또는 컬럼치를 LAST_INSERT_ID(expr) (으)로 설정한다 INSERT 스테이트먼트 및 UPDATE 스테이트먼트의 실행 후에 갱신됩니다. See 항6.3.6.2. 「그 외의 각종 함수」 .

주의: SQL LAST_INSERT_ID() 함수의 값에는, 반드시 마지막에 생성되었다 AUTO_INCREMENT 값이 포함됩니다.이 값은 서버에 보관 유지되므로, 어느 쿼리를 실행하고 나서 다음의 쿼리를 실행할 때까지 에 리셋트 될 것은 없습니다.

반환값

전회 실행된 쿼리에 의해서 갱신되었다 AUTO_INCREMENT 필드의 값.현재의 접속으로 아직 1 회도 쿼리가 실행되어 있지 않았던 경우, 또는 전회 실행된 쿼리로 AUTO_INCREMENT 값이 갱신되지 않았던 경우,0 (을)를 돌려줍니다.

에러

없습니다.

11.1.3.33. mysql_kill()

int mysql_kill(MYSQL *mysql, unsigned long pid)

설명

pid 그리고 지정하는 스레드를 강제 종료하도록(듯이), 서버에 요구합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.34. mysql_list_dbs()

MYSQL_RES *mysql_list_dbs(MYSQL *mysql, const char *wild)

설명

서버상의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 데이타베이스명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 데이타베이스명이 일치합니다.mysql_list_dbs() (을)를 호출하면, 쿼리 SHOW databases [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.35. mysql_list_fields()

MYSQL_RES *mysql_list_fields(MYSQL *mysql, const char *table, const char *wild)

설명

지정된 테이블의 필드로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 필드명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 필드명이 일치합니다.mysql_list_fields() (을)를 호출하면, 쿼리 SHOW COLUMNS FROM tbl_name [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

주의: mysql_list_fields() 대신에 SHOW COLUMNS FROM tbl_name (을)를 사용하는 것을 추천 합니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.36. mysql_list_processes()

MYSQL_RES *mysql_list_processes(MYSQL *mysql)

설명

현재의 서바스레드의 일람을 나타내는 결과 세트를 돌려줍니다.이것은,mysqladmin processlist 또는 SHOW PROCESSLIST 쿼리가 돌려주는 정보와 같은 타입의 정보입니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.37. mysql_list_tables()

MYSQL_RES *mysql_list_tables(MYSQL *mysql, const char *wild)

설명

현재의 데이타베이스로부터 wild 파라미터로 지정되는 단순한 정규 표현에 일치하는 테이블명을 검색해, 결과 세트로서 돌려줍니다.wild 에는 와일드 카드 문자로서 ‘% ＇ 또는 ‘_ ＇ (을)를 사용할 수 있습니다.NULL 포인터를 지정했을 경우는 모든 테이블명이 일치합니다.mysql_list_tables() (을)를 호출하면, 쿼리 SHOW tables [LIKE wild] (을)를 실행했을 경우와 같은 결과를 얻을 수 있습니다.

결과 세트에 할당할 수 있었던 메모리를 해방하려면 ,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

정상 종료했을 경우는 MYSQL_RES 결과 세트.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.38. mysql_num_fields()

unsigned int mysql_num_fields(MYSQL_RES *result)

또는

unsigned int mysql_num_fields(MYSQL *mysql)

2 번째의 형식은,MySQL 3.22.24 이?~ 그럼 동작하지 않습니다.MYSQL* 인수를 건네주려면 , 이 함수 대신에 unsigned int mysql_field_count(MYSQL *mysql) (을)를 사용할 필요가 있습니다.

설명

결과 세트의 컬럼수를 돌려줍니다.

주의: 결과 세트에의 포인터 또는 접속 핸들에의 포인터의 어느 쪽을 사용해도, 컬럼수를 취득할 수 있습니다.mysql_store_result() 또는 mysql_use_result() 하지만 NULL (을)를 돌려주었을 경우(결과 세트 포인터가 돌려주어지지 않았던 경우)는, 접속 핸들을 사용합니다.이 경우,mysql_field_count() (을)를 호출하는 것에 의해서,mysql_store_result() 하지만 정상적인 처리로서 하늘의 결과 세트를 돌려주었는지 어떤지를 판단할 수 있습니다.이것에 의해서, 클라이언트 프로그램은, 쿼리가 SELECT (또는 SELECT 좋아하는) 스테이트먼트인지 어떤지를 몰라도 적절한 처리를 실행할 수 있습니다.이하의 예에, 이 처리의 실현 방법을 나타냅니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트에 포함되는 필드수를 나타낸다 unsigned 정수.

에러

없습니다.

례

MYSQL_RES *result;
unsigned int num_fields;
unsigned int num_rows;

if (mysql_query(&mysql,query_string))
{
    // error
}
else // query succeeded, process any data returned by it
{
    result = mysql_store_result(&mysql);
    if (result)  // there are rows
    {
        num_fields = mysql_num_fields(result);
        // retrieve rows, then call mysql_free_result(result)
    }
    else  // mysql_store_result() returned nothing; should it have?
    {
        if (mysql_errno(&mysql))
        {
           fprintf(stderr, "Error: %s\n", mysql_error(&mysql));
        }
        else if (mysql_field_count(&mysql) == 0)
        {
            // query does not return data
            // (it was not a SELECT)
            num_rows = mysql_affected_rows(&mysql);
        }
    }
}

(쿼리가 결과 세트를 돌려주는 것을 알 수 있고 있는 경우)mysql_errno(&mysql) (을)를 호출하는 대신에 mysql_field_count(&mysql) 하지만 0 (을)를 돌려줄지를 조사하는 방법도 있습니다.이것은,0 (을)를 돌려주는 것은, 어떠한 이상이 발생했을 경우만이기 때문입니다.

11.1.3.39. mysql_num_rows()

my_ulonglong mysql_num_rows(MYSQL_RES *result)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_num_rows() 의 사용법은,mysql_store_result() (와)과 mysql_use_result() 의 어느 쪽을 사용해 결과 세트를 취득할까에 의해서 정해집니다.mysql_store_result() (을)를 사용하는 경우, 곧바로 mysql_num_rows() (을)를 호출할 수 있습니다.mysql_use_result() (을)를 사용하는 경우, 결과 세트에 포함되는 모든 레코드를 취득할 때까지는,mysql_num_rows() (은)는 올바른 값을 돌려주지 않습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.3.40. mysql_options()

int mysql_options(MYSQL *mysql, enum mysql_option option, const char *arg)

설명

이 함수를 사용하고, 접속 옵션을 추가 설정해, 접속의 동작을 바꿀 수 있습니다.이 함수를 여러 차례 호출하는 것으로, 복수의 옵션을 설정할 수 있습니다.

mysql_options() (은)는,mysql_init() (을)를 실행하고 나서 mysql_connect() 또는 mysql_real_connect() (을)를 호출할 때까지 에 호출할 필요가 있습니다.

option 인수는, 설정하는 옵션입니다.arg 인수는 그 옵션으로 설정하는 값입니다.옵션이 정수의 경우,arg 에는 정수치에의 포인터를 건네줄 필요가 있습니다.

설정 가능한 옵션의 값을 다음에 나타냅니다.

옵션 | 인수의 형태 | 기능
MYSQL_OPT_CONNECT_TIMEOUT | unsigned int * | 접속의 타임 아웃 시간(초단위).
MYSQL_OPT_READ_TIMEOUT | unsigned int * | 서버로부터의 읽기 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_WRITE_TIMEOUT | unsigned int * | 서버에의 써 타임 아웃 시간(현재는 Windows 의 TCP/IP 접속에서만 유효).
MYSQL_OPT_COMPRESS | 미사용 | 압축된 클라이언트/ 서버 프로토콜을 사용.
MYSQL_OPT_LOCAL_INFILE | unsigned int 에의 생략 가능한 포인터 | 포인터가 지정되지 않는지, 또는 0 (은)는 아니다 unsigned int 에의 포인터가 지정되었을 경우, 커멘드 LOAD LOCAL INFILE (은)는 유효.
MYSQL_OPT_NAMED_PIPE | 미사용 | 이름 파이프를 사용해 NT 위에서 동작한다 MySQL 서버에 접속.
MYSQL_INIT_COMMAND | char * | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
MYSQL_READ_DEFAULT_FILE | char * | my.cnf (이)가 아니고, 지정된 옵션 설정 파일로부터 옵션을 읽어들인다.
MYSQL_READ_DEFAULT_GROUP | char * | my.cnf 의 지정된 그룹 또는 MYSQL_READ_DEFAULT_FILE 그리고 지정된 파일로부터 옵션을 읽어들인다.
MYSQL_OPT_PROTOCOL | unsigned int * | 사용하는 프로토콜의 타입.mysql.h 그리고 정의되고 있다 mysql_protocol_type 의 열거치의 언젠가 1 개인 것.
MYSQL_SHARED_MEMORY_BASE_NAME | char* | 서버와의 통신에 사용하는 이름 공유 메모리오브제크트.접속 상대의 mysqld 서버가 사용하는 옵션 -shared-memory-base-name (와)과 같은 값을 지정할 필요가 있다.

주의: MYSQL_READ_DEFAULT_FILE 또는 MYSQL_READ_DEFAULT_GROUP (을)를 사용하는 경우는, 그룹 client 하지만 항상 읽힙니다.

옵션 설정 파일의 지정된 그룹에는 이하의 옵션을 지정 가능합니다.

옵션 | 설명
connect-timeout | 접속의 타임 아웃 시간(초단위).Linux 그럼, 서버로부터 최초의 응답을 기다리는 경우에도 이 타임 아웃 시간을 사용한다.
compress | 압축된 클라이언트/ 서버 프로토콜을 사용.
database | 접속 커멘드로 데이타베이스가 지정되지 않았던 경우에 접속하는 데이타베이스.
debug | 디버그 옵션.
disable-local-infile | LOAD DATA LOCAL 의 사용을 무효로 한다.
host | 디폴트의 호스트명.
init-command | MySQL 서버에 접속할 경우에 실행하는 커멘드.재접속시에는 자동적으로 재실행된다.
interactive-timeout | mysql_real_connect() 그리고 CLIENT_INTERACTIVE (을)를 지정하는 것과 같다. See 항11.1.3.43. 「mysql_real_connect() 」 .
local-infile[=(0|1)] | 인수가 지정되지 않는지, 또는 0 이외의 인수가 지정되었을 경우에 LOAD DATA LOCAL 의 사용을 유효하게 한다.
max_allowed_packet | 클라이언트가 서버로부터 읽어들여 가능한 패킷의 최대 사이즈.
password | 디폴트의 패스워드.
pipe | 이름 파이프를 사용해 NT 위에서 동작한다 MySQL 서버에 접속.
protocol=(TCP | SOCKET | PIPE | MEMORY) | 서버에 접속할 경우에 사용하는 프로토콜을 선택(4.1 의 신기능).
port | 디폴트의 포토 번호.
return-found-rows | UPDATE (을)를 사용했을 때에 갱신된 레코드가 아니고, 검색 결과의 레코드를 돌려주도록(듯이),mysql_info() 에 지시한다.
shared-memory-base-name=name | 서버와의 접속에 사용하는 공유 메모리의 이름(디폴트는 "MySQL" ).MySQL 4.1 의 신기능.
socket | 디폴트의 소켓 번호.
user | 디폴트의 유저.

주의: timeout 대신에 connect-timeout 하지만 제공되고 있습니다만,timeout 도 당분간은 사용할 수 있습니다.

옵션 설정 파일의 상세한 것에 대하여는, 항4.1.2. 「my.cnf 옵션 설정 파일」 (을)를 참조해 주세요.

반환값

정상 종료했을 경우는 0 .불명한 옵션을 사용했을 경우는 0 이외.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql,MYSQL_OPT_COMPRESS,0);
mysql_options(&mysql,MYSQL_READ_DEFAULT_GROUP,"odbc");
if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는, 압축된 클라이언트/ 서버 프로토콜을 사용하는 것, 및 my.cnf 파일의 odbc 섹션의 옵션을 추가로 읽어들이는 것을, 클라이언트에 요구하고 있습니다.

11.1.3.41. mysql_ping()

int mysql_ping(MYSQL *mysql)

설명

서버에의 접속이 정상적일지를 확인합니다.절단 되고 있었을 경우는, 자동적으로 재접속을 시도합니다.

장시간에 걸쳐서 아이돌 상태였던 클라이언트는 이 함수를 사용하는 것에 의해서, 서버에 의해서 접속이 절단 되어 있지 않은지 어떤지를 조사하고, 필요하면 재접속할 수 있습니다.

반환값

서버와의 접속이 정상적인 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.42. mysql_query()

int mysql_query(MYSQL *mysql, const char *query)

설명

눌 종단 문자열 query 그리고 지정되었다 SQL 쿼리를 실행합니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

mysql_query() (은)는 바이너리 데이터를 포함한 쿼리를 취급할 수 없습니다.그러한 쿼리에서는 대신에 mysql_real_query() (을)를 사용할 필요가 있습니다(바이너리 데이터에는 '\0' 하지만 포함될 가능성이 있어,mysql_query() (은)는 그것을 쿼리 문자열의 마지막으로서 해석해 버리기 위해).

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

반환값

쿼리가 정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.43. mysql_real_connect()

MYSQL *mysql_real_connect(MYSQL *mysql, const char *host, const char *user, const char *passwd, const char *db, unsigned int port, const char *unix_socket, unsigned long client_flag)

설명

mysql_real_connect() (은)는,host 그리고 동작하고 있다 MySQL 데이타베이스 엔진에의 접속을 확립하려고 합니다.mysql_real_connect() 하지만 정상 종료하지 않으면, 다른 API 함수(mysql_get_client_info() (을)를 제외한다)를 실행할 수 없습니다.

파라미터의 지정 방법을 다음에 나타냅니다.

  • 1 번째의 파라미터에는, 기존의 MYSQL 구조체의 주소를 지정한다.mysql_real_connect() (을)를 호출하기 전에,mysql_init() (을)를 호출해 MYSQL 구조체를 초기화할 필요가 있다.mysql_options() (을)를 사용하면, 다양한 접속 옵션을 변경할 수 있다. See 항11.1.3.40. 「mysql_options() 」 .

  • host 파라미터에는, 호스트명 또는 IP 주소의 어느 쪽인지를 지정한다.host 에 NULL 또는 문자열 "localhost" (을)를 지정했을 경우, 로컬 호스트에게 접속하는 것으로 간주해진다.OS 하지만 소켓(Unix ) 또는 이름 파이프(Windows )(을)를 서포트하고 있는 경우,TCP/IP 대신에 그것들을 사용해 서버에 접속한다.

  • user 파라미터에는 유저의 MySQL 로그인 ID (을)를 지정한다.user 에 NULL 또는 공문자열 "" (을)를 지정했을 경우, 현재의 유저를 사용하는 것으로 간주해진다.Unix 그럼 현재의 로그인명이 사용된다.Windows 그리고 ODBC (을)를 사용하는 경우는, 현재의 유저명을 명시적으로 지정할 필요가 있다. See 항11.2.2. 「ODBC 아드?~ 니스트레이타의 필드의 설정 방법법」 .

  • passwd 파라미터에는 user 의 패스워드를 지정한다.passwd 에 NULL (을)를 지정했을 경우,user 테이블의 엔트리의 패스워드 필드에 아무것도 지정되어 있지 않은(하늘이다) 유저만이 체크 대상이 된다.데이타베이스 관리자는, 이 기능을 사용하고, 패스워드를 지정해 있을지에 따라서 유저에게 다른 특권을 준다고 한다 MySQL 특권 시스템을 셋업 할 수 있다.

    주의: 패스워드의 암호화는 클라이언트 API 에 의해서 자동적으로 처리되므로,mysql_real_connect() (을)를 호출하기 전에 패스워드의 암호화는 불필요하다.

  • db 파라미터에는 데이타베이스명을 지정한다.db 하지만 NULL (이)가 아닌 경우, 이 값이 접속의 디폴트 데이타베이스로서 설정된다.

  • port 파라미터에 0 이외의 값을 지정했을 경우, 이 값이 TCP/IP 접속의 포토 번호로서 사용된다.주의: 접속의 타입은 host 파라미터에 의해서 결정된다.

  • unix_socket 파라미터에 NULL 이외의 값을 지정했을 경우, 이 문자열이 소켓 또는 이름 파이프에 사용된다.주의: 접속의 타입은 host 파라미터에 의해서 결정된다.

  • client_flag 파라미터에는 통상 0 (을)를 지정하지만, 지극히 특수한 상황에서는 이하에 나타내는 플래그를 조합해 지정할 수 있다.

    플래그명 | 플래그의 설명
    CLIENT_COMPRESS | 압축 프로토콜을 사용.
    CLIENT_FOUND_ROWS | 영향을 받은 레코드의 수가 아니고, 검색 결과의(일치한) 레코드의 수를 돌려준다.
    CLIENT_IGNORE_SPACE | 함수명의 말미의 공백을 무시한다.모든 함수명을 예약어(reserved word)로 한다.
    CLIENT_INTERACTIVE | 아이돌 상태가(wait_timeout 초는 아니고)interactive_timeout 초계속하면 접속을 클로우즈 한다.
    CLIENT_LOCAL_FILES | LOAD DATA LOCAL 의 처리를 유효하게 한다.
    CLIENT_MULTI_STATEMENTS | 클라이언트가 복수행 쿼리(‘; ＇ (을)를 스테이트먼트의 단락으로 한다)를 송신할 가능성이 있는 것을 서버에 통지한다.이 플래그가 설정되어 있지 않은 경우, 복수행 쿼리는 무효.MySQL 4.1 의 신기능.
    CLIENT_MULTI_RESULTS | 클라이언트가 복수 쿼리 또는 Stored Procedure에 의해서 취득한 복수의 결과 세트를 처리할 수 있는 것을 서버에 통지한다.CLIENT_MULTI_STATEMENTS 하지만 설정되어 있는 경우, 이 플래그는 자동적으로 설정된다.MySQL 4.1 의 신기능.
    CLIENT_NO_SCHEMA | db_name.tbl_name.col_name 그렇다고 하는 구문의 사용을 금?~ 한다.이것은 ODCB 향해의 구문이다.이 구문을 사용했을 경우, 파서로 에러가 발생한다.이 구문은 일부의 ODBC 프로그램으로 버그를 트랩 하기 위해서 사용한다.
    CLIENT_ODBC | 클라이언트가 ODBC 경유인 것을 통지한다.이 경우,mysqld 하 ODBC 클라이언트에 적절한 처리를 실시한다.
    CLIENT_SSL | SSL (암호화 프로토콜)(을)를 사용한다.응용 프로그램에서는 이 플래그를 설정하지 않는 것.이것은 클라이언트 라이브러리가 내부에서 설정하는 플래그이다.

반환값

접속이 정상적으로 확립했을 경우는 MYSQL* 접속 핸들.접속이 확립하지 않았던 경우는 NULL .접속이 확립했을 경우, 반환값은 1 번째의 파라미터의 값과 같습니다.

에러

  • CR_CONN_HOST_ERROR

    MySQL 서버에의 접속이 확립하지 않았다.

  • CR_CONNECTION_ERROR

    로컬의 MySQL 서버에의 접속이 확립하지 않았다.

  • CR_IPSOCK_ERROR

    IP 소켓의 작성에 실패했다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SOCKET_CREATE_ERROR

    Unix 소켓의 작성에 실패했다.

  • CR_UNKNOWN_HOST

    호스트명의 IP 주소가 발견되지 않았다.

  • CR_VERSION_ERROR

    서버에 접속할 때에, 다른 프로토콜 버젼의 클라이언트 라이브러리를 사용했기 때문에, 프로토콜의 불일치가 발생했다.이 에러는,--old-protocol 옵션을 지정하지 않고 기동한 새로운 버젼의 서버에, 매우 낡은 버젼의 클라이언트 라이브러리를 사용하고 접속을 시도했을 경우에 발생할 가능성이 있다.

  • CR_NAMEDPIPEOPEN_ERROR

    Windows 그리고 이름 파이프의 작성에 실패했다.

  • CR_NAMEDPIPEWAIT_ERROR

    Windows 그리고 이름 파이프의 대기에 실패했다.

  • CR_NAMEDPIPESETSTATE_ERROR

    Windows 그리고 파이프 핸들러의 취득에 실패했다.

  • CR_SERVER_LOST

    connect_timeout 하지만 정의 값이며,connect_timeout 초경과해도 서버에 접속할 수 없었다.또는 init-command 의 실행중에 서버가 다운했다.

례

MYSQL mysql;

mysql_init(&mysql);
mysql_options(&mysql,MYSQL_READ_DEFAULT_GROUP,"your_prog_name");
if (!mysql_real_connect(&mysql,"host","user","passwd","database",0,NULL,0))
{
    fprintf(stderr, "Failed to connect to database: Error: %s\n",
          mysql_error(&mysql));
}

이 예에서는 mysql_options() (을)를 호출해 MySQL 라이브러리가 my.cnf 파일의 [client] 및 [your_prog_name] 섹션을 읽어들이도록(듯이) 설정해 있습니다.이와 같이 설정하는 것으로, 비표준적인 방법으로 셋업 되었다 MySQL 에 대해서도 이 프로그램이 정상적으로 동작하는 것을 보증합니다.

주의: 접속이 확립했을 때,mysql_real_connect() 에 의해서 reconnect 플래그(MYSQL 구조체의 일부)의 값이 1 (으)로 설정됩니다.이 플래그는, 접속이 절단 되어 쿼리를 실행할 수 없는 경우에, 거기서 쿼리를 종료하지 않고 , 서버에의 재접속을 시도하는 것을 의미합니다.

11.1.3.44. mysql_real_escape_string()

unsigned long mysql_real_escape_string(MYSQL *mysql, char *to, const char *from, unsigned long length)

설명

이 함수는,SQL 스테이트먼트로 사용할 수 있는 정당한 SQL 문자열을 작성하기 위해서 사용합니다. See 항6.1.1.1. 「문자열」 .

from (으)로 지정한 문자열이, 이스케이프 되었다 SQL 문자열에 encode 됩니다.이 때, 접속의 현재의 캐릭터 세트가 고려됩니다.encode 한 결과는 to (으)로 설정되어 말미에는 문자열의 마지막을 나타내는 누르바이트가 부가됩니다.encode 되는 문자는,NUL (ASCII 0 ),'\n' ,'\r' ,‘\ ＇,‘' ＇,‘" ＇, 및 Ctrl-Z 키(see 항6.1.1. 「리터럴: 문자열과 수치의 기술 방법」 )입니다(엄밀하게 말하면,MySQL 그리고 이스케이프 할 필요가 있는 것은 쿼리내에서 문자열을 인용하기 위한 backslash 및 인용부호 뿐입니다만, 이 함수에서는 로그 파일을 읽기 쉽게 하기 위해서 다른 문자도 이스케이프 합니다).

from 그리고 지정하는 문자열의 길이는 length 아르바이트일 필요가 있습니다.to 버퍼에는, 적어도 length*2+1 아르바이트의 메모리를 할당할 필요가 있습니다(최악의 경우,1 문자 encode 하는데 2 아르바이트가 필요한 가능성이 있어, 한층 더 문자열의 마지막을 나타내는 누르바이트를 격납할 필요가 있습니다).mysql_real_escape_string() 하지만 복귀했을 때,to 에는 눌 종단 문자열이 격납되고 있습니다.반환값은 encode 후의 문자열의 길이입니다.다만, 문자열의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

례

char query[1000],*end;

end = strmov(query,"INSERT INTO test_table values(");
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"What's this",11);
*end++ = '\'';
*end++ = ',';
*end++ = '\'';
end += mysql_real_escape_string(&mysql, end,"binary data: \0\r\n",16);
*end++ = '\'';
*end++ = ')';

if (mysql_real_query(&mysql,query,(unsigned int) (end - query)))
{
   fprintf(stderr, "Failed to insert row, Error: %s\n",
           mysql_error(&mysql));
}

이 예로 사용되고 있다 strmov() 함수는,mysqlclient 라이브러리에 격납되고 있습니다.strcpy() (와)과 같은 처리를 실시합니다만,1 번째의 파라미터로 지정된 문자열의 마지막을 나타내는 누르바이트에의 포인터를 돌려줍니다.

반환값

to (으)로 설정된 값의 길이.다만, 문자열의 마지막을 나타내는 누르바이트는 포함하지 않습니다.

에러

없습니다.

11.1.3.45. mysql_real_query()

int mysql_real_query(MYSQL *mysql, const char *query, unsigned long length)

설명

query 그리고 지정한 문자열로 나타내진다 SQL 쿼리를 실행합니다.이 문자열의 길이는 length 아르바이트일 필요가 있습니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

바이너리 데이터에는 '\0' 문자가 포함될 가능성이 있으므로, 그러한 데이터를 포함한 쿼리의 경우는,mysql_query() (이)가 아니고,mysql_real_query() (을)를 사용한다 필요가 있습니다 .또,mysql_real_query() (은)는 쿼리 문자열에 대해서 strlen() (을)를 호출하지 않기 때문에,mysql_query() 보다 고속으로 동작합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

반환값

쿼리가 정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.46. mysql_reload()

int mysql_reload(MYSQL *mysql)

설명

권한 테이블의 재독 봐 포함을 MySQL 서버에 요구합니다.접속 유저에게는 RELOAD 특권이 필요합니다.

이 함수는 폐?~ 되고 있습니다.대신에,mysql_query() (을)를 사용해 FLUSH PRIVILEGES 스테이트먼트를 발행해 주세요.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.47. mysql_row_seek()

MYSQL_ROW_OFFSET mysql_row_seek(MYSQL_RES *result, MYSQL_ROW_OFFSET offset)

설명

쿼리 결과 세트의 임의의 레코드에 로 커서를 설정합니다.offset 의 값은 레코드 오프셋이며,mysql_row_tell() 또는 mysql_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_data_seek() (을)를 사용합니다.

mysql_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_use_result() (이)가 아니고,mysql_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수 있습니다.

에러

없습니다.

11.1.3.48. mysql_row_tell()

MYSQL_ROW_OFFSET mysql_row_tell(MYSQL_RES *result)

설명

마지막에 실행되었다 mysql_fetch_row() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_row_seek() 에 인수로서 건네줄 수 있습니다.

          mysql_row_tell()

(은)는,mysql_use_result()

의 다음에는 없고,mysql_store_result()

의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋.

에러

없습니다.

11.1.3.49. mysql_select_db()

int mysql_select_db(MYSQL *mysql, const char *db)

설명

db 그리고 지정된 데이타베이스를 mysql 그리고 지정된 접속의 디폴트(경향) 데이타베이스로 합니다.이 데이타베이스는, 그 후 실행되는 쿼리로 명시적인 데이타베이스 지정자가 없는 테이블 참조를 할 때의 디폴트가 됩니다.

접속 유저가 데이타베이스를 사용하는 권한을 가지는 유저로서 인증되지 않는 경우,mysql_select_db() (은)는 실패합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.50. mysql_set_server_option()

int mysql_set_server_option(MYSQL *mysql, enum enum_mysql_set_option option)

설명

접속의 옵션을 유효 또는 무효로 합니다.option 에는 이하의 어느 쪽인가의치를 지정할 수 있습니다.

MYSQL_OPTION_MULTI_STATEMENTS_ON | 복수 스테이트먼트의 서포트를 유효하게 한다.
MYSQL_OPTION_MULTI_STATEMENTS_OFF | 복수 스테이트먼트의 서포트를 무효로 한다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • ER_UNKNOWN_COM_ERROR

    서버가 mysql_set_server_option() (을)를 서포트하지 않았다(서버가 4.1.1 보다 낡은 버젼의 경우)인가, 또는 서버가 설정하려고 한 옵션을 서포트하지 않았다.

11.1.3.51. mysql_shutdown()

int mysql_shutdown(MYSQL *mysql)

설명

데이터 베이스 서버에 슛다운 하도록(듯이) 요구합니다.접속 유저에게는 SHUTDOWN 특권이 필요합니다.

반환값

정상 종료했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.52. mysql_sqlstate()

const char *mysql_sqlstate(MYSQL *mysql)

설명

마지막에 발생한 에러의 SQLSTATE 에러 코드를 포함한 눌 종단 문자열을 돌려줍니다.에러 코드는 5 문자로 나타납니다.'00000' (은)는,`` 에러가 없다'' 일을 의미합니다.값은 ANSI SQL 및 ODBC 에 의해서 규정되고 있습니다.생각할 수 있는 값의 일람에 대해서는, 항12.1. 「돌려주어지는 에러」 (을)를 참조해 주세요.

주의: 모든 MySQL 에러가 SQLSTATE 에 매핑 되고 있는 것은 아닙니다.매핑 되어 있지 않은 에러의 경우는 'HY000' (일반 에러)(이)가 사용됩니다.

이 함수는 MySQL 4.1.1 그리고 추가되었습니다.

반환값

SQLSTATE 에러 코드를 포함한 눌 종단 문자열.

관련 항목

See 항11.1.3.12. 「mysql_errno() 」 . See 항11.1.3.13. 「mysql_error() 」 . See 항11.1.7.18. 「mysql_stmt_sqlstate() 」 .

11.1.3.53. mysql_ssl_set()

int mysql_ssl_set(MYSQL *mysql, const char *key, const char *cert, const char *ca, const char *capath, const char *cipher)

설명

mysql_ssl_set() (은)는,SSL (을)를 사용하고, 시큐러티로 보호된 접속을 확립하기 위해서 사용합니다.mysql_real_connect() 의 전에 호출할 필요가 있습니다.

mysql_ssl_set() (은)는, 클라이언트 라이브러리에서 OpenSSL 서포트가 유효하게 되지 않은 경우는 아무것도 하지 않습니다.

mysql (은)는,mysql_init() (으)로부터 돌려주어진 접속 핸들러입니다.다른 파라미터의 지정 방법을 다음에 나타냅니다.

  • key 파라미터에는, 비밀 키파일에의 패스명을 지정한다.

  • cert 파라미터에는, 증명서 파일에의 패스명을 지정한다.

  • ca 파라미터에는, 인증국 발행의 증명서 파일에의 패스명을 지정한다.

  • capath 파라미터에는,PEM 형식이 신뢰 받았다 CA 증명서가 격납된 디렉토리에의 패스명을 지정한다.

  • cipher 파라미터에는,SSL 암호화에 사용할 수 있는 암호의 일람을 지정한다.

사용하지 않는다 SSL 파라미터에는 NULL (을)를 지정할 수 있습니다.

반환값

이 함수는 항상 0 (을)를 돌려줍니다.SSL 하지만 올바르고 셋업 되어 있지 않은 경우, 접속을 시도하면 mysql_real_connect() 하지만 에러를 돌려줍니다.

11.1.3.54. mysql_stat()

char *mysql_stat(MYSQL *mysql)

설명

mysqladmin status 커멘드의 출력으로 같은 정보를 포함한 문자열을 돌려줍니다.이 정보에는, 사용 가능 시간(초단위), 실행중의 스레드수, 질문의 수, 재로드 회수, 및 오픈되고 있는 테이블의 수가 포함됩니다.

반환값

서버 스테이터스를 나타내는 문자열.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.55. mysql_store_result()

MYSQL_RES *mysql_store_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT ,SHOW ,DESCRIBE ,EXPLAIN )에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

다른 쿼리에서는 mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요는 없습니다만, 모든 케이스로 mysql_store_result() (을)를 호출해도, 이상이 발생하거나 눈에 띈 동작을 하는 일은 없습니다.mysql_store_result() 하지만 0 (을)를 돌려줄지를 조사하는 것으로, 쿼리로 결과 세트가 생성되었는지를 검출할 수 있습니다.이것에 대해서는 후술 합니다.

쿼리가 결과 세트를 돌려주는 타입인지 어떤지를 조사하려면 ,mysql_field_count() (을)를 사용합니다. See 항11.1.3.20. 「mysql_field_count() 」 .

mysql_store_result() (은)는, 쿼리의 결과 세트 전체를 클라이언트에 읽어들여,MYSQL_RES 구조체에 메모리를 할당해 이 구조체에 결과 세트를 격납합니다.

쿼리가 결과 세트를 돌려주지 않는 경우(예를 들어, 쿼리가 INSERT 스테이트먼트였던 경우),mysql_store_result() (은)는 누르포인타를 돌려줍니다.

또, 결과 세트의 읽어들여에 실패했을 경우도,mysql_store_result() (은)는 누르포인타를 돌려줍니다.에러가 발생했는지를 조사하려면 ,mysql_error() 하지만 누르포인타를 돌려주지 않는지 어떤지,mysql_errno() 하지만 0 이외의 값을 돌려줄지, 또는 mysql_field_count() 하지만 0 이외의 값을 돌려줄지를 조사합니다.

돌려주는 레코드가 존재하지 않는 경우는 하늘의 결과 세트가 돌려주어집니다(하늘의 결과 세트는, 반환값으로서의 누르포인타와는 다릅니다).

mysql_store_result() (을)를 호출하고, 반환값이 누르포인타 이외였던 경우,mysql_num_rows() (을)를 호출하면 결과 세트에 포함되는 레코드수를 취득할 수 있습니다.

mysql_fetch_row() (을)를 호출하면, 결과 세트로부터 레코드를 취득할 수 있습니다.mysql_row_seek() 및 mysql_row_tell() (을)를 호출하면, 결과 세트내의 경향 레코드의 위치를 설정 및 취득할 수 있습니다.

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출할 필요가 있습니다.

See 항11.1.12.1. 「mysql_query() 하지만 정상적으로 종료한 다음에 mysql_store_result() 하지만 NULL (을)를 돌려주는 경우가 있는 것은 왠지」 .

반환값

결과 세트가 격납되었다 MYSQL_RES 구조체.에러가 발생했을 경우는 NULL .

에러

mysql_store_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno (을)를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.56. mysql_thread_id()

unsigned long mysql_thread_id(MYSQL *mysql)

설명

현재의 접속의 스레드 ID (을)를 돌려줍니다.이 반환값을,mysql_kill() 에 인수로서 건네주어 스레드를 강제 종료할 수 있습니다.

현재의 접속이 절단 되어mysql_ping() (을)를 사용해 재접속했을 경우, 스레드 ID (은)는 다른 값이 됩니다.이것은, 취득한 스레드 ID (을)를 보관해 다음에 사용할 수 없는 것을 의미합니다.스레드 ID 하지만 필요하게 되었을 때에, 취득할 필요가 있습니다.

반환값

현재의 접속의 스레드 ID .

에러

없습니다.

11.1.3.57. mysql_use_result()

MYSQL_RES *mysql_use_result(MYSQL *mysql)

설명

정상적으로 데이터를 취득한 쿼리(SELECT ,SHOW ,DESCRIBE ,EXPLAIN )에 대해서는,mysql_store_result() 또는 mysql_use_result() (을)를 호출할 필요가 있습니다.

mysql_use_result() (은)는, 결과 세트의 취득을 개시합니다만,mysql_store_result() (와)과 같이 실제로 결과 세트를 클라이언트에 읽어들이는 것은 아닙니다.대신에,mysql_fetch_row() (을)를 호출하고,1 행씩 개별적으로 취득할 필요가 있습니다.그 경우, 쿼리의 결과는 직접 서버로부터 읽혀 텐포라리테이불이나 로컬 버퍼에는 격납되지 않습니다.이것은 mysql_store_result() (을)를 사용하는 경우보다 다소 고속으로 있어, 사용하는 메모리도 적어도 됩니다.클라이언트는, 경향 레코드 및 max_allowed_packet 아르바이트까지 증가할 가능성이 있는 통신 버퍼에 메모리를 할당할 뿐입니다.

한편, 각각의 레코드에 대한 클라이언트측에서의 처리량이 많은 경우, 또는 유저가 ^S (을)를 입력한다(스크롤을 정?~ 할) 가능성이 있는 화면에 데이터를 출력하는 경우는,mysql_use_result() 의 사용은 피할 필요가 있습니다.그러한 처리의 경우, 서버의 동작이 정?~ 하고, 읽어내지고 있는 데이터가 격납되고 있는 테이블을 다른 스레드를 갱신할 수 없게 됩니다.

mysql_use_result() (을)를 사용하는 경우,NULL 하지만 돌려주어질 때까지 mysql_fetch_row() (을)를 반복해 호출할 필요가 있습니다.그렇게 하지 않으면 취득되지 않았던 레코드가, 다음에 실행하는 쿼리의 결과 세트의 일부로서 돌려주어집니다.취득되지 않았던 레코드가 남아 있는 경우,C API (은)는 에러 Commands out of sync; you can't run this command now (을)를 돌려줍니다.

          mysql_use_result()

하지만 돌려준 결과 세트에 대해서
          mysql_data_seek()
,mysql_row_seek()
,mysql_row_tell()
,mysql_num_rows()
, 또는
          mysql_affected_rows()

(을)를 사용할 수 없습니다.또,mysql_use_result()

하지만 완료할 때까지는 다른 쿼리를 발행할 수 없습니다(다만, 모든 레코드를 취득한 다음에 있으면
          mysql_num_rows()

(은)는 취득한 레코드의 수를 정확하게 돌려줍니다).

결과 세트가 필요없게 되면,mysql_free_result() (을)를 호출할 필요가 있습니다.

반환값

MYSQL_RES 구조체.에러가 발생했을 경우는 NULL .

에러

mysql_use_result() (은)는, 정상 종료했을 경우에 mysql_error 및 mysql_errno (을)를 리셋트 합니다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.3.58. mysql_warning_count()

unsigned int mysql_warning_count(MYSQL *mysql)

설명

전회 실행되었다 SQL 스테이트먼트의 실행중에 발생한 경고수를 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

경고수.

에러

없습니다.

11.1.3.59. mysql_commit()

my_bool mysql_commit(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 코?~ 트 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.60. mysql_rollback()

my_bool mysql_rollback(MYSQL *mysql)

설명

현재의 트랜잭션(transaction)를 롤백(rollback) 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.61. mysql_autocommit()

my_bool mysql_autocommit(MYSQL *mysql, my_bool mode)

설명

mode 하지만 1 의 경우는 자동코?~ 트모드를 유효하게,mode 하지만 0 의 경우는 무효로 합니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

정상적으로 동작했을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

없습니다.

11.1.3.62. mysql_more_results()

my_bool mysql_more_results(MYSQL *mysql)

설명

현재 실행하고 있는 쿼리 외에 아직 취득하고 있지 않는 결과 세트가 존재해, 어플리케이션이 mysql_next_result() (을)를 호출해 취득할 필요가 있는 경우는,true (을)를 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

반환값

취득되어 있지 않은 결과 세트가 존재하는 경우는 TRUE (1 ).취득되어 있지 않은 결과 세트가 존재하지 않는 경우는 FALSE (0 ).

주의: 대부분의 경우, 이 함수 대신에 mysql_next_result() (을)를 호출해 취득되어 있지 않은 결과 세트가 있을지를 조사하고, 존재하는 경우는 다음의 결과 세트를 개시합니다.

See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」 . See 항11.1.3.63. 「mysql_next_result() 」 .

에러

없습니다.

11.1.3.63. mysql_next_result()

int mysql_next_result(MYSQL *mysql)

설명

취득되어 있지 않은 결과 세트가 존재하는 경우,mysql_next_result() (은)는 다음의 쿼리의 결과 세트를 읽어들여, 스테이터스를 어플리케이션에 돌려줍니다.이 함수는,MySQL 4.1 그리고 추가되었습니다.

주의: 전의 쿼리가 결과 세트를 돌려주고 있었을 경우,mysql_free_result() (을)를 호출할 필요가 있습니다.

          mysql_next_result()

(을)를 호출한 후, 접속 상태는 다음의 쿼리에 대해
          mysql_real_query()

(을)를 호출한 후와 같게 됩니다.이것은, 이 함수를 호출한 후, 이 접속으로
          mysql_store_result()
,mysql_warning_count()
,mysql_affected_rows()

등을 호출할 수 있는 것을 의미합니다.

mysql_next_result() 하지만 에러를 돌려주었을 경우, 다른 스테이트먼트는 실행되지 않습니다.또, 취득되어 있지 않은 결과 세트도 존재하지 않습니다.

See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」 .

반환값

호출이 정상적으로 동작해, 취득하는 결과 세트가 존재하고 있었을 경우는 0 , 취득하는 결과 세트가 존재하지 않았던 경우는 -1 , 에러가 발생했을 경우는 정의 값.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.예를 들어, 전의 결과 세트로 mysql_use_result() 하지만 불려 가지 않았던 경우에 이 에러가 발생한다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.4. C API 의 Prepared Statements

MySQL 4.1 그럼, 프리페아드스테이트먼트를 사용하기 위한 클라이언트/ 서버 프로토콜이 제공되고 있습니다.이 기능은,MYSQL_STMT 스테이트먼트 핸들러 데이터 구조체를 사용합니다.프리페아드스테이트먼트의 실행은, 스테이트먼트를 반복해 실행하는 경우에 효율적인 방법입니다.스테이트먼트는, 실행할 준비를 갖추기 위해서, 우선 해석됩니다.그 후,prepare 함수로부터 돌려주어지는 스테이트먼트 핸들을 사용하고,1 회이상 실행됩니다.

프리페아드스테이트먼트의 실행은, 해석이 1 회 밖에 행해지지 않기 때문에, 스테이트먼트를 직접 여러 차례 실행하는 것보다도 고속으로.스테이트먼트를 직접 실행했을 경우, 그때마다 쿼리의 해석을 합니다.프리페아드스테이트먼트를 실행하는 경우, 네트워크 트래픽도, 파라미터로서 데이터를 송신할 경우에 발생할 뿐(만큼)이므로, 삭감할 수 있습니다.

그 외에도, 프리페아드스테이트먼트의 실행에서는 바이너리 프로토콜을 사용하므로, 클라이언트 및 서버간의 데이터 전송의 효율이 향상한다고 하는 이점이 있습니다.프리페아드스테이트먼트는, 복수 쿼리를 실행할 때의 입력 및 출력의 바인딩도 서포트합니다.

11.1.5. C API 의 Prepared Statement의 데이터형

주의: 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자 전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

프리페아드스테이트먼트는, 주로 MYSQL_STMT 및 MYSQL_BIND 의 각 데이터 구조체를 사용합니다.그 외에, 시간적인 데이터를 전송 하기 위해서 MYSQL_TIME (을)를 사용합니다.

  • MYSQL_STMT

    이 구조체는, 프리페아드스테이트먼트를 나타낸다.프리페아드스테이트먼트는,mysql_prepare() (을)를 호출해 작성한다.이 함수는,MYSQL_STMT 에의 포인터인 스테이트먼트 핸들을 돌려준다.이 핸들은, 그 후에 불려 가는 모든 스테이트먼트 관련의 함수로 사용된다.

    MYSQL_STMT 구조체의 멤버를 어플리케이션이 사용할 것은 없다.

    1 개의 접속에 복수의 스테이트먼트 핸들을 관련지을 수 있다.관련짓는 핸들수는, 사용할 수 있는 system resource에 의해서 제한된다.

  • MYSQL_BIND

    이 구조체는, 쿼리의 입력(데이터치가 서버에 송신된다) 및 출력(결과치가 서버로부터 돌려주어진다)의 양쪽 모두로 사용된다.입력의 경우,mysql_bind_param() 에 건네주어 파라미터 데이터치를 버퍼에 바인드 해,mysql_execute() 하지만 사용할 수 있도록 한다.출력의 경우,mysql_bind_result() 에 건네주어 결과 세트를 버퍼에 바인드 해,mysql_fetch() 그리고 레코드를 취득할 때에 사용할 수 있도록 한다.

    MYSQL_BIND 구조체에서는, 이하에 나타내는 멤버를 응용 프로그램을 사용할 수 있다.어느 멤버도 입력 및 출력의 어느 쪽에도 사용하지만, 데이터 전송의 방향에 따라서 다른 목적으로 사용하는 경우가 있다.

    • enum enum_field_types buffer_type

      버퍼의 형태.사용할 수 있다 buffer_type 의 값의 리스트를, 이 섹션의 후반에 나타낸다.입력의 경우,buffer_type (은)는 쿼리 파라미터에 바인드 하는 값의 형태를 나타낸다.출력의 경우, 결과 세트의 버퍼로 받는 값의 형태를 나타낸다.

    • void *buffer

      입력의 경우, 쿼리 파라미터의 데이터치가 보존되는 버퍼에의 포인터.출력의 경우, 결과 세트의 컬럼치를 돌려주는 버퍼에의 포인터.컬럼형이 수치의 경우,buffer (은)는 적절한 C 언어의 형태의 변수에의 포인터로 할 필요가 있다(UNSIGNED 속성을 가지는 컬럼에 변수를 관련짓고 있는 경우, 변수는 C 언어의 unsigned 형태로 할 필요가 있다).컬럼형이 일자 및 시각의 경우,buffer 하 MYSQL_TIME 구조체에의 포인터로 할 필요가 있다.컬럼형이 문자열 및 바이너리 문자열의 경우,buffer (은)는 문자 버퍼에의 포인터로 할 필요가 있다.

    • unsigned long buffer_length

      아르바이트 단위로 나타냈다 *buffer 의 실제의 사이즈.이 값은, 버퍼에 격납할 수 있는 데이터의 최대 사이즈를 나타낸다.C 의 문자 데이터 및 바이너리 데이터의 경우,buffer_length 의 값은,mysql_bind_param() 그리고 사용하는 경우는 *buffer 하지만 나타내 보이는 데이터의 길이, 또는 mysql_bind_result() 그리고 사용하는 경우는 버퍼에 취득할 수 있는 최대 데이터 바이트수를 지정한다.

    • unsigned long *length

      unsigned long 변수에의 포인터.*buffer 에 격납하는 데이터의 실제의 아르바이트수를 나타낸다.length (은)는, 격납하는 데이터가 C 의 문자 데이터 또는 바이너리 데이터의 경우에 사용한다.입력 파라미터 데이터를 바인드 하는 경우,length (은)는,*buffer 에 격납하는 파라미터치의 길이를 나타낸다 unsigned long 변수를 가리킨다.이것은 mysql_execute() 그리고 사용된다.length 하지만 누르포인타의 경우, 프로토콜은 모든 문자 데이터 및 바이너리 데이터가 눌로 종단 되고 있으면 가정한다.출력치를 바인드 하는 경우,mysql_fetch() (은)는, 돌려주는 데이터의 컬럼치의 길이를 length 하지만 포인트 하는 변수로 설정한다.

      수치 데이터형 또는 시간적인 데이터형의 경우, 데이터치의 길이는 buffer_type 의 값에 의해서 정해지므로,length (은)는 무시된다.

    • my_bool *is_null

      my_bool 변수에의 포인터.값이 NULL 의 경우는 true ,NULL 이외의 경우는 false .입력의 경우,*is_null (을)를 true (으)로 설정하는 것에 의해서, 쿼리 파라미터로서 NULL 값을 건네주고 있는 것을 나타낸다.출력의 경우, 쿼리가 돌려주는 값이 NULL 때에 레코드를 취득하면, 이 값이 true (으)로 설정된다.

  • MYSQL_TIME

    이 구조체는, 서버와 직접 DATE ,TIME ,DATETIME , 및 TIMESTAMP 데이터를 송수신 하기 위해서 사용한다.거기에는,MYSQL_BIND 구조체의 buffer_type 멤버를 몇개의 시간을 나타내는 형태로 설정해,buffer 멤버를 MYSQL_TIME 구조체를 포인트 하도록(듯이) 설정한다.

    MYSQL_TIME 구조체의 멤버를 이하에 나타낸다.

    • unsigned int year

      년.

    • unsigned int month

      월.

    • unsigned int day

      일.

    • unsigned int hour

      시.

    • unsigned int minute

      분.

    • unsigned int second

      초.

    • my_bool neg

      시간이 부화도인지를 나타내는 불리언 값 플래그.

    • unsigned long second_part

      초의 소수부.현재는 미사용.

    MYSQL_TIME 구조체의 멤버는, 사용하는 시간적인 형태에 대응하는 부분만큼이 사용된다.year ,month , 및 day 의 각 멤버는,DATE ,DATETIME , 및 TIMESTAMP 의 값에 사용한다.hour ,minute , 및 second 의 각 멤버는,TIME ,DATETIME , 및 TIMESTAMP 의 값에 사용한다. See 항11.1.9. 「C API 에 있어서의 일자치 및 시각치의 취급」 .

MYSQL_BIND 구조체의 buffer_type 멤버로 지정할 수 있는 값을 이하의 겉(표)에 나타냅니다.이 표에는, 각각의 buffer_type 의 값에 가장 가깝다 SQL 의 데이터형을 나타내, 한층 더 수치형과 시간적인 값의 형태에 대해서는 대응한다 C 의 데이터형도 나타내 보입니다.

buffer_type 치 | SQL 의 데이터형 | C 의 데이터형
MYSQL_TYPE_TINY | TINYINT | char
MYSQL_TYPE_SHORT | SMALLINT | short int
MYSQL_TYPE_LONG | INT | long int
MYSQL_TYPE_LONGLONG | BIGINT | long long int
MYSQL_TYPE_FLOAT | FLOAT | float
MYSQL_TYPE_DOUBLE | DOUBLE | double
MYSQL_TYPE_TIME | TIME | MYSQL_TIME
MYSQL_TYPE_DATE | DATE | MYSQL_TIME
MYSQL_TYPE_DATETIME | DATETIME | MYSQL_TIME
MYSQL_TYPE_TIMESTAMP | TIMESTAMP | MYSQL_TIME
MYSQL_TYPE_STRING | CHAR |
MYSQL_TYPE_VAR_STRING | VARCHAR |
MYSQL_TYPE_TINY_BLOB | TINYBLOB/TINYTEXT |
MYSQL_TYPE_BLOB | BLOB/TEXT |
MYSQL_TYPE_MEDIUM_BLOB | MEDIUMBLOB/MEDIUMTEXT |
MYSQL_TYPE_LONG_BLOB | LONGBLOB/LONGTEXT |

암묵의 데이터형 변환은 어느 방향에도 행해질 가능성이 있습니다.

11.1.6. C API 의 Prepared Statement 함수의 개요

주의: 프리페아드스테이트먼트의 API (은)는, 향후 개정될 가능성이 있습니다.여기서 설명하는 정보는, 곧바로 이 API (을)를 사용하는 개발자 전용으로 쓰여져 있습니다만, 향후 API 하지만 변경이 될 가능성이 있는 것을 아시는 바 일어나 주세요.

여기에서는, 프리페아드스테이트먼트의 처리에 사용할 수 있는 함수에 대해 간단하게 설명합니다.상세한 것에 대하여는, 이?~ 의 섹션으로 설명합니다. See 항11.1.7. 「C API 의 Prepared Statement 함수의 설명」 .

함수 | 설명
mysql_prepare() | SQL 문자열을 실행하기 위한 프리컴파일을 실시한다.
mysql_param_count() | 프리페아드스테이트먼트의 파라미터수를 돌려준다.
mysql_get_metadata() | 프리페아드스테이트먼트메타데이타를 결과 세트 형식에서 돌려준다.
mysql_bind_param() | 어플리케이션 데이터 버퍼를, 프리페아드스테이트먼트내의 파라미터 마커에 관련짓는다.
mysql_execute() | 프리페아드스테이트먼트를 실행한다.
mysql_stmt_affected_rows() | 마지막에 실행되었다 UPDATE ,DELETE , 또는 INSERT 의 몇개의 쿼리에 의해서 변경, 삭제, 또는 삽입된 레코드의 수를 돌려준다.
mysql_bind_result() | 어플리케이션 데이터 버퍼를, 결과 세트의 컬럼에 관련짓는다.
mysql_stmt_store_result() | 결과 세트 전체를 취득해 클라이언트에 전송 한다.
mysql_stmt_data_seek() | 스테이트먼트의 결과 세트의 임의의 레코드 번호에 시크 한다.
mysql_stmt_row_seek() | mysql_stmt_row_tell() (으)로부터 돌려주어진 값을 오프셋으로서 스테이트먼트의 결과 세트내의 레코드에 시크 한다.
mysql_stmt_row_tell() | 스테이트먼트의 레코드 커서의 위치를 돌려준다.
mysql_stmt_num_rows() | 버퍼에 격납된 스테이트먼트의 결과 세트 전체의 레코드수를 돌려준다.
mysql_fetch() | 결과 세트의 다음의 레코드의 데이터를 취득해, 바인드 된 모든 컬럼의 데이터를 돌려준다.
mysql_stmt_close() | 프리페아드스테이트먼트가 사용하고 있던 메모리를 해방한다.
mysql_stmt_errno() | 마지막에 실행된 스테이트먼트의 에러 번호를 돌려준다.
mysql_stmt_error() | 마지막에 실행된 스테이트먼트의 에러 메세지를 돌려준다.
mysql_stmt_sqlstate() | 마지막에 실행한 스테이트먼트의 SQLSTATE 에러 코드를 돌려준다.
mysql_send_long_data() | long 형태 데이터를 분리해 서버에 송신한다.

        mysql_prepare()

(을)를 호출해 스테이트먼트 핸들을 프리컴파일 해, 초기화합니다.다음에
        mysql_bind_param()

(을)를 호출해 파라미터 데이터를 건네주어,mysql_execute()

(을)를 호출해 쿼리를 실행합니다.mysql_bind_param()

경유로 건네주는 버퍼에 격납한 파라미터치를 변경하고,mysql_execute()

(을)를 반복 실행할 수도 있습니다.

쿼리가 SELECT 스테이트먼트의 경우, 또는 결과 세트를 생성하는 그 외의 쿼리의 경우,mysql_prepare() 하 mysql_get_metadata() (을)를 사용해 MYSQL_RES 결과 세트 형식에서 결과 세트의 메타데이타 정보도 돌려줍니다.

결과를 격납하는 버퍼를 mysql_bind_result() (을)를 사용해 건네주는 것에 의해서,mysql_fetch() (은)는 자동적으로 그 버퍼에 데이터를 돌려줍니다.여기에서는 1 행씩의 취득을 합니다.

옵션으로서 is_long_data=1 또는 length=MYSQL_LONG_DATA 또는 -2 (을)를 지정했다 MYSQL_BIND 구조체를 mysql_bind_param() 그리고 건네주면,mysql_send_long_data() (을)를 사용해 텍스트 데이터 또는 바이너리 데이터를 분리해 서버에 송신할 수 있습니다.

스테이트먼트의 실행이 완료하면,mysql_stmt_close() (을)를 호출해 스테이트먼트 핸들을 클로우즈 해, 핸들에 관련 붙일 수 있어 모든 자원을 해방할 필요가 있습니다.

mysql_get_metadata() (을)를 호출해 SELECT 스테이트먼트의 결과 셋트메타데이타를 취득하고 있었을 경우도,mysql_free_result() (을)를 호출해 해방할 필요가 있습니다.

실행 스텝

스테이트먼트를 프리컴파일 해 실행하려면 , 어플리케이션으로 이하의 스텝에 따라서 처리합니다.

  1. SQL 스테이트먼트를 포함한 문자열을 파라미터로서 mysql_prepare() (을)를 호출한다.프리컴파일이 정상적으로 종료했을 경우,mysql_prepare() (은)는 유효한 스테이트먼트 핸들러를 어플리케이션에 돌려준다.

  2. 결과 세트를 생성하는 쿼리를 실행하는 경우,mysql_get_metadata() (을)를 호출해 결과 셋트메타데이타를 취득한다.이 메타데이타는 그것 자신이 결과 세트 형식이다.다만, 쿼리가 돌려주는 레코드를 포함한 결과 세트와는 따로 건네받는다.결과 셋트메타데이타에는, 결과 세트에 포함되는 컬럼수 및 각 컬럼에 관한 정보가 포함된다.

  3. mysql_bind_param() (을)를 사용하고, 파라미터의 값을 설정한다.모든 파라미터의 값을 설정할 필요가 있다.값이 설정되어 있지 않은 파라미터가 남아 있으면, 에러가 돌려주어지거나 예상외의 결과가 발생한다.

  4. mysql_execute() (을)를 호출해 스테이트먼트를 실행한다.

  5. 결과 세트를 생성하는 쿼리를 실행했을 경우,mysql_bind_result() (을)를 호출하고, 레코드의 값을 취득하기 위한 데이터 버퍼를 바인드 한다.

  6. mysql_fetch() (을)를 호출하고,1 행 분의 데이터를 버퍼에 취득한다.모든 레코드의 데이터를 취득할 수 있을 때까지 이것을 반복한다.

  7. 필요에 따라서 스텝 3 (으)로부터 6 까지를 반복하고, 파라미터의 값을 변경하면서 스테이트먼트를 재실행한다.

mysql_prepare() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버의 프로토콜을 이하에 나타냅니다.

  • 서버는 쿼리를 해석해, 스테이트먼트 ID (을)를 할당하고,OK 스테이터스를 클라이언트에 답장한다.결과 세트를 생성하는 쿼리의 경우는, 게다가 파라미터의 합계수, 컬럼수, 및 그 메타 정보를 송신한다.이 호출로, 서버는 쿼리의 모든 구문 및 의미를 확인한다.

  • 클라이언트는 이 스테이트먼트 ID (을)를 사용해 그 후의 처리를 실행한다.이 ID (을)를 사용하고, 서버는 스테이트먼트 풀중에서 사용하는 스테이트먼트를 식별한다.또, 클라이언트는 스테이트먼트 핸들을 이 ID 에 할당해 핸들을 어플리케이션에 돌려준다.

mysql_execute() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는 스테이트먼트 핸들을 사용하고, 서버에 파라미터 데이터를 송신한다.

  • 서버는 클라이언트로부터 건네받았다 ID (을)를 사용해 스테이트먼트를 식별해, 파라미터 마커를 새롭게 건네받은 데이터에 옮겨놓아 쿼리를 실행한다.결과 세트를 생성하는 쿼리를 실행했을 경우, 서버는 데이터를 클라이언트에 답장한다.결과 세트를 생성하지 않는 쿼리를 실행했을 경우, 서버는 OK 스테이터스 및 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려준다.

mysql_fetch() 하지만 불려 갔을 경우에 실행된다 MySQL 클라이언트/ 서버 프로토콜을 이하에 나타냅니다.

  • 클라이언트는, 패킷으로부터 1 행분씩 데이터를 읽어들여, 필요에 따라서 데이터 변환하면서 어플리케이션 데이터 버퍼에 격납한다.어플리케이션 버퍼의 형태가 서버로부터 돌려주어진 필드의 형태와 같은 경우는, 직접적으로 변환을 한다.

mysql_stmt_errno() ,mysql_stmt_error() , 및 mysql_stmt_sqlstate() (을)를 사용하면, 각각 스테이트먼트의 에러 코드, 에러 메세지, 및 SQLSTATE 값을 취득할 수 있습니다.

11.1.7. C API 의 Prepared Statement 함수의 설명

쿼리를 프리컴파일 해 실행하려면 , 이하의 함수를 사용합니다.

11.1.7.1. mysql_prepare()

MYSQL_STMT * mysql_prepare(MYSQL *mysql, const char *query, unsigned long length)

설명

눌 종단 문자열 query 그리고 지정되었다 SQL 쿼리를 프리컴파일 해, 그 후의 처리에 사용하는 스테이트먼트 핸들을 돌려줍니다.이 쿼리는 단일 SQL 스테이트먼트로 구성되어 있을 필요가 있습니다.이 스테이트먼트에는, 그 마지막을 나타내는 세?~ 코론(‘; ＇) 또는 \g (을)를 추가할 필요는 없습니다.

어플리케이션은,SQL 문자열의 적당한 위치에 물음표(‘? ＇)(을)를 묻는 것으로,SQL 스테이트먼트로 1 개이상의 파라미터 마커를 사용할 수 있습니다.

마커는,SQL 스테이트먼트의 특정의 위치에 파묻혔을 경우에게만 적정하게 처리됩니다.예를 들어, 마커는 INSERT 스테이트먼트의 VALUES() 의 리스트로 레코드로 설정하는 컬럼의 값을 지정하는 부분, 또는 WHERE 마디로 컬럼의 값과 비교하는 값을 지정하는 부분에 사용할 수 있습니다.그러나,SELECT 스테이트먼트가 돌려주는 컬럼을 지정하는 선택 리스트로 식별자(테이블 또는 컬럼의 이름등)로서 사용하거나 등호(= )등의 바이너리 연산자의 양쪽 모두의 오퍼랜드를 지정할 수 없습니다.파라미터의 형태를 결정할 수 없기 때문에, 후자의 제약이 필요하게 됩니다.일반적으로, 파라미터는, 데이터 조작 언어(DML ) 스테이트먼트에서만 적정하게 처리되어 데이터 정의 언어(DDL ) 스테이트먼트에서는 처리되지 않습니다.

파라미터 마커는, 스테이트먼트를 실행하기 전에,mysql_bind_param() (을)를 사용해 어플리케이션 변수에 바인드 할 필요가 있습니다.

반환값

컴파일이 정상적으로 종료했을 경우는 MYSQL_STMT 구조체에의 포인터.에러가 발생했을 경우는 NULL .

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

컴파일이 실패했을 경우(mysql_prepare() 하지만 NULL (을)를 돌려주었을 경우), 에러 메세지는 mysql_error() (을)를 호출하는 것에 의해서 취득할 수 있습니다.

례

mysql_prepare() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.2. mysql_param_count()

unsigned long mysql_param_count(MYSQL_STMT *stmt)

설명

프리컴파일 된 스테이트먼트에 포함되는 파라미터 마커의 수를 돌려줍니다.

반환값

스테이트먼트에 포함되는 파라미터수를 나타낸다 unsigned long 정수.

에러

없습니다.

례

mysql_param_count() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.3. mysql_get_metadata()

MYSQL_RES *mysql_get_metadata(MYSQL_STMT *stmt)

설명

mysql_prepare() 에게 건네진 스테이트먼트가 결과 세트를 생성하는 것인 경우,mysql_get_metadata() 하 MYSQL_RES 구조체에의 포인터라고 하는 형태로 결과 셋트메타데이타를 돌려줍니다.이 구조체를 사용하고, 필드의 합계수 및 개개의 필드 정보등의 메타 정보를 처리할 수 있습니다.이 결과 세트에의 포인터는, 결과 셋트메타데이타를 처리하는 이하의 필드 베이스의 API 함수에 인수로서 건네줄 수 있습니다.

  • mysql_num_fields()

  • mysql_fetch_field()

  • mysql_fetch_field_direct()

  • mysql_fetch_fields()

  • mysql_field_count()

  • mysql_field_seek()

  • mysql_field_tell()

  • mysql_free_result()

결과 세트 구조체는, 사용할 필요가 없어지면 mysql_free_result() 에 건네주어 해방할 필요가 있습니다.이것은,mysql_store_result() (을)를 호출해 취득한 결과 세트를 해방하는 방법과 닮아 있습니다.

mysql_get_metadata() (으)로부터 돌려주어지는 결과 세트에는, 메타데이타만이 포함됩니다.레코드 데이터는 포함되지 않습니다.레코드를 취득하려면 , 스테이트먼트 핸들을 파라미터로서 mysql_fetch() (을)를 호출합니다.

반환값

MYSQL_RES 구조체.프리컴파일 한 쿼리의 메타 정보가 존재하지 않는 경우는 NULL .

에러

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_get_metadata() 의 사용 방법에 대해서는, 항11.1.7.13. 「mysql_fetch() 」 의 「예」를 참조해 주세요.

11.1.7.4. mysql_bind_param()

my_bool mysql_bind_param(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_param() (은)는,mysql_prepare() 에게 건네졌다 SQL 스테이트먼트에 포함되는 파라미터 마커의 데이터를 바인드 하기 위해서 사용합니다.데이터는 MYSQL_BIND 구조체를 사용해 건네줍니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 쿼리에 포함되는 각 ‘? ＇ 파라미터에 대응하는 요소가 포함되어 있으면 가정합니다.

예를 들어, 이하의 스테이트먼트를 프리컴파일 한다고 합니다.

INSERT INTO mytbl VALUES(?,?,?)

파라미터를 바인드 하는 경우,MYSQL_BIND 구조체에는 3 개의 요소가 필요하고, 이하와 같이 선언할 수 있습니다.

MYSQL_BIND bind[3];

설정할 필요가 있다 MYSQL_BIND 의 각 요소의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_NO_PARAMETERS_EXISTS

    바인드 하는 파라미터가 존재하지 않는다.

  • CR_INVALID_BUFFER_USE

    이것이long 데이터를 분리해 건네주기 위한 바인드인가, 및 버퍼의 형태가 문자열 이외 또는 바이너리 이외인지를 나타낸다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_param() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.5. mysql_execute()

int mysql_execute(MYSQL_STMT *stmt)

설명

mysql_execute() (은)는, 스테이트먼트 핸들에 관련지을 수 있고 있는 프리컴파일 된 쿼리를 실행합니다.이 호출 시에, 현재 바인드 되고 있는 파라미터 마커의 값이 서버에 송신되어 서버는 마커를 여기서 건네받은 데이터로 옮겨놓습니다.

스테이트먼트가 UPDATE ,DELETE , 또는 INSERT 의 경우,mysql_stmt_affected_rows() (을)를 호출하는 것에 의해서, 변경, 삭제, 또는 삽입된 레코드의 합계수를 취득할 수 있습니다.이것이 SELECT 등의 결과 세트를 생성하는 쿼리의 경우, 최초로 mysql_fetch() (을)를 호출해 데이터를 취득하고 나서, 다른 쿼리 처리를 필요로 하는 함수를 호출할 필요가 있습니다.결과를 취득하는 방법의 상세한 것에 대하여는, 항11.1.7.13. 「mysql_fetch() 」 (을)를 참조해 주세요.

반환값

정상적으로 실행했을 경우는 0 .에러가 발생했을 경우는 0 이외.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해서 취득할 수 있습니다.

에러

  • CR_NO_PREPARE_QUERY

    실행하기 전에 프리컴파일 된 쿼리가 존재하지 않는다.

  • CR_ALL_PARAMS_NOT_BOUND

    건네받지 않은 파라미터 데이터가 있다.

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

이하의 예에서는,mysql_prepare()
,mysql_param_count()
,mysql_bind_param()
,mysql_execute()
, 및
          mysql_stmt_affected_rows()

(을)를 사용하고, 테이블을 작성해, 데이터를 삽입하는 방법을 나타냅니다.mysql

변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define DROP_SAMPLE_TABLE "DROP TABLE IF EXISTS test_table"
#define CREATE_SAMPLE_TABLE "CREATE TABLE test_table(col1 INT,\
                                                 col2 VARCHAR(40),\
                                                 col3 SMALLINT,\
                                                 col4 TIMESTAMP)"
#define INSERT_SAMPLE "INSERT INTO test_table(col1,col2,col3) VALUES(?,?,?)"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[3];
my_ulonglong  affected_rows;
int           param_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
unsigned long str_length;
my_bool       is_null;

if (mysql_query(mysql, DROP_SAMPLE_TABLE))
{
  fprintf(stderr, " DROP TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

if (mysql_query(mysql, CREATE_SAMPLE_TABLE))
{
  fprintf(stderr, " CREATE TABLE failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}

/* Prepare an INSERT query with 3 parameters */
/* (the TIMESTAMP column is not named; it will */
/* be set to the current date and time) */
stmt = mysql_prepare(mysql, INSERT_SAMPLE, strlen(INSERT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), INSERT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, INSERT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in INSERT: %d\n", param_count);

if (param_count != 3) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Bind the data for all 3 parameters */

/* INTEGER PARAM */
/* This is a number type, so there is no need to specify buffer_length */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *)&int_data;
bind[0].is_null= 0;
bind[0].length= 0;

/* STRING PARAM */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *)str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= 0;
bind[1].length= &str_length;

/* SMALLINT PARAM */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *)&small_data;
bind[2].is_null= &is_null;
bind[2].length= 0;

/* Bind the buffers */
if (mysql_bind_param(stmt, bind))
{
  fprintf(stderr, " mysql_bind_param() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Specify the data values for the first row */
int_data= 10;             /* integer */
strncpy(str_data, "MySQL", STRING_SIZE); /* string  */
str_length= strlen(str_data);

/* INSERT SMALLINT data as NULL */
is_null= 1;

/* Execute the INSERT statement - 1*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), 1 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total number of affected rows */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 1): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Specify data values for second row, then re-execute the statement */
int_data= 1000;
strncpy(str_data, "The most popular open source database", STRING_SIZE);
str_length= strlen(str_data);
small_data= 1000;         /* smallint */
is_null= 0;               /* reset */

/* Execute the INSERT statement - 2*/
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute, 2 failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get the total rows affected */
affected_rows= mysql_stmt_affected_rows(stmt);
fprintf(stdout, " total affected rows(insert 2): %ld\n", affected_rows);

if (affected_rows != 1) /* validate affected rows */
{
  fprintf(stderr, " invalid affected rows by MySQL\n");
  exit(0);
}

/* Close the statement */
if (mysql_stmt_close(stmt))
{
  fprintf(stderr, " failed while closing the statement\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

주의: Prepared Statement 함수를 사용한 완전한 예에 대해서는, 파일 tests/mysql_client_test.c (을)를 참조해 주세요.이 파일은,MySQL 소스 디스트리뷰션 또는 BitKeeper 소스 리포지터리(repository)로부터 취득할 수 있습니다.

11.1.7.6. mysql_stmt_affected_rows()

my_ulonglong mysql_stmt_affected_rows(MYSQL_STMT *stmt)

설명

마지막에 실행된 스테이트먼트에 의해서 변경, 삭제, 또는 삽입된 레코드의 합계수를 돌려줍니다.UPDATE ,DELETE , 또는 INSERT 의 몇개의 스테이트먼트에 대해서 mysql_execute() (을)를 호출한 직후에 불려 갈 가능성이 있습니다.SELECT 스테이트먼트의 경우,mysql_stmt_affected_rows() (을)를 호출하면,mysql_num_rows() (와)과 같게 동작합니다.

반환값

정의 정수는, 영향을 준, 또는 취득한, 레코드수를 나타냅니다.0 (은)는,UPDATE 에 의해서 갱신된 레코드가 없었던 것, 쿼리의 WHERE 마디에 일치하는 레코드가 없었던 것, 또는 쿼리가 실행되어 있지 않은 것을 나타내 보입니다.－1 (은)는, 쿼리가 에러를 돌려준 것, 또는 SELECT 쿼리의 경우에 mysql_fetch() (을)를 호출하기 전에 mysql_stmt_affected_rows() 하지만 불려 간 것을 나타내 보입니다.

에러

없습니다.

례

mysql_stmt_affected_rows() 의 사용 방법에 대해서는, 항11.1.7.5. 「mysql_execute() 」 의 「예」를 참조해 주세요.

11.1.7.7. mysql_bind_result()

my_bool mysql_bind_result(MYSQL_STMT *stmt, MYSQL_BIND *bind)

설명

mysql_bind_result() (은)는, 결과 세트의 컬럼을 데이터 버퍼 및 길이 버퍼에 관련짓는(바인드 한다) 위해(때문에) 사용합니다.mysql_fetch() (을)를 호출해 데이터를 취득하는 경우,MySQL 클라이언트/ 서버 프로토콜에 의해서, 바인드 된 컬럼의 데이터가 지정된 버퍼에 써집니다.

주의: mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.bind (은)는,MYSQL_BIND 구조체의 배열의 주소입니다.클라이언트 라이브러리는, 이 배열에, 결과 세트의 각 컬럼에 대응한 요소가 포함되어 있으면 가정합니다.요소가 포함되지 않은 경우,mysql_fetch() (은)는 단지 데이터를 취득하지 않습니다.또, 클라이언트/ 서버 프로토콜은 데이터의 값을 분리해 돌려주지는 않기 때문에, 버퍼의 사이즈는 데이터치를 격납 가능한 한의 충분한 크기일 필요가 있습니다.

컬럼은, 임의의 시점에서, 결과 세트의 일부만이 취득된 다음에도, 바인드 또는 재바인드 할 수 있습니다.새롭게 바인드 했을 경우, 그것이 유효하게 되는 것은, 다음에 mysql_fetch() (을)를 호출했을 때입니다.예를 들어, 어플리케이션이 결과 세트의 컬럼을 바인드 해 mysql_fetch() (을)를 호출한다고 합니다.클라이언트/ 서버 프로토콜은, 바인드 된 버퍼에 데이터를 돌려줍니다.다음에 어플리케이션이 컬럼을 다른 버퍼에 바인드 한다고 합니다.프로토콜은, 다음에 mysql_fetch() 하지만 불려 갈 때까지, 새롭고 바인드 된 버퍼에 데이터를 쓰지 않습니다.

컬럼을 바인드 하려면 , 어플리케이션은 mysql_bind_result() (을)를 호출하고, 형태, 주소, 및 길이 버퍼의 주소를 건네줍니다.설정할 필요가 있다 MYSQL_BIND 의 각 요소의 멤버에 대해서는, 항11.1.5. 「C API 의 프리페아드스테이트먼트의 데이터형」 (을)를 참조해 주세요.

반환값

정상적으로 바인드 할 수 있었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_NO_PREPARE_STMT

    프리컴파일 된 스테이트먼트가 존재하지 않는다.

  • CR_UNSUPPORTED_PARAM_TYPE

    변환이 서포트되어 있지 않다.buffer_type 의 값이 올바르지 않은지, 또는 서포트되어 있지 않은 형태일 가능성이 있다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

례

mysql_bind_result() 의 사용 방법에 대해서는, 항11.1.7.13. 「mysql_fetch() 」 의 「예」를 참조해 주세요.

11.1.7.8. mysql_stmt_store_result()

int mysql_stmt_store_result(MYSQL_STMT *stmt)

설명

쿼리가 결과 세트를 정상적으로 생성해(SELECT ,SHOW ,DESCRIBE ,EXPLAIN ), 한층 더 클라이언트의 버퍼에 결과 세트 전체를 격납하고, 그 후의 mysql_fetch() 의 호출로 버퍼 된 데이터가 돌려주어지도록(듯이) 하는 경우에 한정해,mysql_stmt_store_result() (을)를 호출할 필요가 있습니다.

그러한 쿼리 이외에서는 mysql_stmt_store_result() (을)를 호출할 필요는 없습니다만, 호출했다고 해도 이상이 발생하거나 눈에 띈 동작을 하는 일은 일절 없습니다.mysql_get_metadata() 하지만 NULL (을)를 돌려줄지를 조사하는 것으로, 쿼리가 결과 세트를 생성했는지를 검출할 수 있습니다.상세한 것에 대하여는, 항11.1.7.3. 「mysql_get_metadata() 」 (을)를 참조해 주세요.

반환값

결과 세트가 정상적으로 버퍼에 격납되었을 경우는 0 .에러가 발생했을 경우는 0 이외.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

11.1.7.9. mysql_stmt_data_seek()

void mysql_stmt_data_seek(MYSQL_STMT *stmt, my_ulonglong offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 시크 합니다.offset 값은 레코드 번호를 나타내,0 (으)로부터 mysql_stmt_num_rows(stmt)-1 의 범위에서 지정합니다.

mysql_stmt_data_seek() (을)를 사용하려면 , 스테이트먼트의 결과 세트 구조체에 마지막에 실행된 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

없습니다.

에러

없습니다.

11.1.7.10. mysql_stmt_row_seek()

MYSQL_ROW_OFFSET mysql_stmt_row_seek(MYSQL_STMT *stmt, MYSQL_ROW_OFFSET offset)

설명

스테이트먼트의 결과 세트의 임의의 레코드에 레코드 커서를 설정합니다.offset 의 값은 레코드 오프셋이며,mysql_stmt_row_tell() 또는 mysql_stmt_row_seek() 의 반환값이 됩니다.이 값은 레코드 번호가 아닙니다.결과 세트내의 레코드에 번호를 지정해 시크 하는 경우는, 이 함수가 아니고,mysql_stmt_data_seek() (을)를 사용합니다.

mysql_stmt_row_seek() (을)를 사용하려면 , 결과 세트 구조체에 쿼리의 결과 전체가 격납되고 있을 필요가 있으므로,mysql_stmt_store_result() (와)과 함께 사용할 필요가 있습니다.

반환값

시크 하기 전의 레코드 커서의 값.mysql_stmt_row_seek() (을)를 다음에 호출할 때 이 값을 건네줄 수 있습니다.

에러

없습니다.

11.1.7.11. mysql_stmt_row_tell()

MYSQL_ROW_OFFSET mysql_stmt_row_tell(MYSQL_STMT *stmt)

설명

마지막에 실행되었다 mysql_fetch() 그리고 사용된 레코드 커서의 현재의 위치를 돌려줍니다.이 반환값을,mysql_stmt_row_seek() 에 인수로서 건네줄 수 있습니다.

mysql_stmt_row_tell() (은)는,mysql_stmt_store_result() 의 다음에 마셔 사용할 수 있습니다.

반환값

레코드 커서의 현재의 오프셋.

에러

없습니다.

11.1.7.12. mysql_stmt_num_rows()

my_ulonglong mysql_stmt_num_rows(MYSQL_STMT *stmt)

설명

결과 세트의 레코드수를 돌려줍니다.

mysql_stmt_num_rows() (을)를 사용할지 어떨지는,mysql_stmt_store_result() (을)를 사용해 결과 세트 전체를 스테이트먼트 핸들에 격납했는지에 의해서 정해집니다.

mysql_stmt_store_result() (을)를 사용하는 경우, 곧바로 mysql_stmt_num_rows() (을)를 호출할 수 있습니다.

반환값

결과 세트의 레코드수.

에러

없습니다.

11.1.7.13. mysql_fetch()

int mysql_fetch(MYSQL_STMT *stmt)

설명

mysql_fetch() (은)는, 결과 세트의 다음의 레코드를 취득합니다.이 함수는 결과 세트가 존재하는 동안만, 즉,mysql_execute() (을)를 호출해 결과 세트를 작성한 후, 또는 mysql_execute() (을)를 호출해 결과 세트 전체를 버퍼에 격납하고 나서 mysql_stmt_store_result() (을)를 호출한 후에게만, 호출할 수 있습니다.

mysql_fetch() (은)는,mysql_bind_result() (을)를 호출해 바인드 한 버퍼를 사용해 레코드 데이터를 돌려줍니다.버퍼에는, 현재의 레코드 세트의 모든 컬럼의 데이터가 격납됩니다.데이터의 길이는 length 포인터에 돌려주어집니다.

주의: 어플리케이션은,mysql_fetch() (을)를 호출하기 전에, 모든 컬럼을 버퍼에 바인드 할 필요가 있습니다.

취득한 데이터가 NULL 값이었던 경우, 대응한다 MYSQL_BIND 구조체의 *is_null 의 값에는 TRUE (1 )(이)가 격납됩니다.그 이외의 값이었던 경우, 어플리케이션이 지정한 버퍼의 형태에 근거하고, 데이터 및 그 길이가 각각 *buffer 요소 및 *length 요소에 돌려주어집니다.수치형 및 시간적인 값의 형태는, 이하의 겉(표)에 나타내도록(듯이), 각각 고정장입니다.문자열형의 길이는, 실제의 데이터의 길이에 의해서 정해져,data_length 에 의해서 나타내집니다.

형 | 길이
MYSQL_TYPE_TINY | 1
MYSQL_TYPE_SHORT | 2
MYSQL_TYPE_LONG | 4
MYSQL_TYPE_LONGLONG | 8
MYSQL_TYPE_FLOAT | 4
MYSQL_TYPE_DOUBLE | 8
MYSQL_TYPE_TIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATE | sizeof(MYSQL_TIME)
MYSQL_TYPE_DATETIME | sizeof(MYSQL_TIME)
MYSQL_TYPE_STRING | data length
MYSQL_TYPE_BLOB | data_length

반환값

반환값 | 설명
0 | 정상.데이터는 어플리케이션 데이터 버퍼에 취득되고 있다.
1 | 에러가 발생했다.에러 코드 및 에러 메세지는,mysql_stmt_errno() 및 mysql_stmt_error() (을)를 호출하는 것에 의해서 취득할 수 있다.
MYSQL_NO_DATA | 취득되어 있지 않은 레코드/ 데이터는 남지 않았다.

에러

  • CR_COMMANDS_OUT_OF_SYNC

    커멘드가 올바른 순서로 실행되지 않았다.

  • CR_OUT_OF_MEMORY

    메모리가 부족했다.

  • CR_SERVER_GONE_ERROR

    MySQL 서버가 없어졌다.

  • CR_SERVER_LOST

    쿼리의 실행중에 서버에의 접속이 절단 되었다.

  • CR_UNKNOWN_ERROR

    불명한 에러가 발생했다.

  • CR_UNSUPPORTED_PARAM_TYPE

    버퍼의 형태는 MYSQL_TYPE_DATE ,MYSQL_TYPE_TIME ,MYSQL_TYPE_DATETIME , 또는 MYSQL_TYPE_TIMESTAMP 그런데, 데이터의 형태는 DATE ,TIME ,DATETIME , 또는 TIMESTAMP 의 머지않아도 아니다.

  • 그 외의 서포트되어 있지 않은 변환에 관한 에러는 모두 mysql_bind_result() (으)로부터 돌려주어진다.

례

이하의 예에서는,mysql_get_metadata() ,mysql_bind_result() , 및 mysql_fetch() (을)를 사용하고, 테이블에서 데이터를 취득하는 방법을 나타냅니다(이 예에서는 항11.1.7.5. 「mysql_execute() 」 의 예로 삽입되었다 2 행의 레코드를 취득하는 것과 상정하고 있습니다).mysql 변수는 유효한 접속 핸들로 합니다.

#define STRING_SIZE 50

#define SELECT_SAMPLE "SELECT col1, col2, col3, col4 FROM test_table"

MYSQL_STMT    *stmt;
MYSQL_BIND    bind[4];
MYSQL_RES     *prepare_meta_result;
MYSQL_TIME    ts;
unsigned long length[4];
int           param_count, column_count, row_count;
short         small_data;
int           int_data;
char          str_data[STRING_SIZE];
my_bool       is_null[4];

/* Prepare a SELECT query to fetch data from test_table */
stmt = mysql_prepare(mysql, SELECT_SAMPLE, strlen(SELECT_SAMPLE));
if (!stmt)
{
  fprintf(stderr, " mysql_prepare(), SELECT failed\n");
  fprintf(stderr, " %s\n", mysql_error(mysql));
  exit(0);
}
fprintf(stdout, " prepare, SELECT successful\n");

/* Get the parameter count from the statement */
param_count= mysql_param_count(stmt);
fprintf(stdout, " total parameters in SELECT: %d\n", param_count);

if (param_count != 0) /* validate parameter count */
{
  fprintf(stderr, " invalid parameter count returned by MySQL\n");
  exit(0);
}

/* Fetch result set meta information */
prepare_meta_result = mysql_get_metadata(stmt);
if (!prepare_meta_result)
{
  fprintf(stderr, " mysql_get_metadata(), returned no meta information\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Get total columns in the query */
column_count= mysql_num_fields(prepare_meta_result);
fprintf(stdout, " total columns in SELECT statement: %d\n", column_count);

if (column_count != 4) /* validate column count */
{
  fprintf(stderr, " invalid column count returned by MySQL\n");
  exit(0);
}

/* Execute the SELECT query */
if (mysql_execute(stmt))
{
  fprintf(stderr, " mysql_execute(), failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Bind the result buffers for all 4 columns before fetching them */

/* INTEGER COLUMN */
bind[0].buffer_type= MYSQL_TYPE_LONG;
bind[0].buffer= (char *)&int_data;
bind[0].is_null= &is_null[0];
bind[0].length= &length[0];

/* STRING COLUMN */
bind[1].buffer_type= MYSQL_TYPE_STRING;
bind[1].buffer= (char *)str_data;
bind[1].buffer_length= STRING_SIZE;
bind[1].is_null= &is_null[1];
bind[1].length= &length[1];

/* SMALLINT COLUMN */
bind[2].buffer_type= MYSQL_TYPE_SHORT;
bind[2].buffer= (char *)&small_data;
bind[2].is_null= &is_null[2];
bind[2].length= &length[2];

/* TIMESTAMP COLUMN */
bind[3].buffer_type= MYSQL_TYPE_TIMESTAMP;
bind[3].buffer= (char *)&ts;
bind[3].is_null= &is_null[3];
bind[3].length= &length[3];

/* Bind the result buffers */
if (mysql_bind_result(stmt, bind))
{
  fprintf(stderr, " mysql_bind_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Now buffer all results to client */
if (mysql_stmt_store_result(stmt))
{
  fprintf(stderr, " mysql_stmt_store_result() failed\n");
  fprintf(stderr, " %s\n", mysql_stmt_error(stmt));
  exit(0);
}

/* Fetch all rows */
row_count= 0;
fprintf(stdout, "Fetching results ...\n");
whi0


13.3. MySQL 에의 새로운 프로시저의 추가

MySQL 그럼, 클라이언트에 송신하기 전에 쿼리의 데이터에 액세스 하고, 변경할 수 있는 프로시저를,C++ (을)를 사용해 정의할 수 있습니다.데이터의 변경은,1 행 마다, 또는 GROUP BY 레벨로 실행할 수 있습니다.

MySQL 버젼 3.23 에는, 프로시저로 실행할 수 있는 처리를 나타내는 샘플 프로시저가 준비되어 있습니다.

또,mylua (을)를 참조하는 것을 추천합니다.이것은,LUA 언어를 사용해 실행시에 mysqld 에 프로시저를 로드하는 툴입니다.

13.3.1. 프로시저의 분석

analyse([max elements,[max memory]])

이 프로시저는,sql/sql_analyse.cc 그리고 정의되고 있습니다.쿼리로부터 돌려주어진 결과를 조사하고, 그 만큼석결과를 돌려줍니다.

  • max elements (디폴트는 256 )(은)는,analyse 하지만 컬럼 마다 검출한, 중복을 제외한 값의 최대수.analyse (은)는 이 값을 사용하고,ENUM 형태가 최적인 컬럼형인지 어떤지를 조사한다.

  • max memory (디폴트는 8192 )(은)는,analyse 하지만 중복을 제외한 값을 모두 검출할 때에 컬럼 마다 할당할 필요가 있는 최대 메모리 용량.

SELECT ... FROM ... WHERE ... PROCEDURE ANALYSE([max elements,[max memory]])

13.3.2. 프로시저의 작성

현재, 프로시저의 작성에 관한 유일한 문서는 소스입니다.

이하의 파일을 참조하는 것으로, 프로시저에 관한 모든 정보를 입수할 수 있습니다.

  • sql/sql_analyse.cc

  • sql/procedure.h

  • sql/procedure.cc

  • sql/sql_select.cc


부록 A. 문제와 일반적인 에러

목차

A.1. 문제의 원인을 찔러?~ 방법
A.2. MySQL 사용시에 자주 있는 에러
A.2.1. Access denied 에러
A.2.2. MySQL server has gone away 에러
A.2.3. Can't connect to [local] MySQL server 에러
A.2.4. Client does not support authentication protocol 에러
A.2.5. Host '...' is blocked 에러
A.2.6. Too many connections 에러
A.2.7. Some non-transactional changed tables couldn't be rolled back 에러
A.2.8. Out of memory 에러
A.2.9. Packet too large 에러
A.2.10. 통신 에러/Aborted connection
A.2.11. The table is full 에러
A.2.12. Can't create/write to file 에러
A.2.13. 클라이언트로의 Commands out of sync 에러
A.2.14. Ignoring user 에러
A.2.15. Table 'xxx' doesn't exist 에러
A.2.16. Can't initialize character set xxx 에러
A.2.17. File Not Found 에러
A.3. 인스톨 관련의 문제
A.3.1. MySQL 클라이언트 라이브러리에 링크시의 문제
A.3.2. 일반 유저로 MySQL (을)를 실행하는 방법
A.3.3. 파일 액세스권의 문제
A.4. 관리 관련의 문제
A.4.1. MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것
A.4.2. 잊은 루트 패스워드를 리셋트 하는 방법
A.4.3. 풀 디스크시의 MySQL 의 동작
A.4.4. MySQL 하지만 임시 파일을 격납하는 장소
A.4.5. MySQL 소켓 파일 /tmp/mysql.sock 의 보호 또는 변경 방법
A.4.6. 타임 존의 문제
A.5. 쿼리 관련의 문제
A.5.1. 검색시의 케이스 의존
A.5.2. DATE 컬럼 사용시의 문제
A.5.3. NULL 값의 문제
A.5.4. alias 의 문제
A.5.5. 관련 테이블에서의 레코드의 삭제
A.5.6. 부정합레코드의 문제 해결
A.5.7. 부동 소수점 비교의 문제
A.6. Optimizer 관련의 문제
A.6.1. 테이블 스캔을 회피하는 방법
A.7. 테이블 정의 관련의 문제
A.7.1. ALTER TABLE 의 문제
A.7.2. 테이블의 컬럼 순서를 변경하는 방법
A.7.3. 텐포라리테이불의 문제

이 장에서는, 유저가 조우하는 몇개의 일반적인 문제와 에러 메세지에 대해 설명하고 있습니다.어떤 문제나 분별하는 방법과 문제를 해결하기 위해서 실시하지 않으면 안 되는 것을 알 수 있습니다.또, 일반적인 문제의 적절한 해결 방법에 대해서도 기재되어 있습니다.

A.1. 문제의 원인을 찔러?~ 방법

문제에 조우했을 경우, 우선, 문제의 원인이 되고 있는 프로그램 또는 장치를 찔러?~ .

  • 이하의 증상이 있는 경우는, 하드웨어(메모리, 메인보드,CPU , 하드 디스크)의 문제나 커넬의 문제일 가능성 있어.

    • 키보드가 동작하지 않는다.이것은 통상,CapsLock 키를 누르는 것으로 확인할 수 있다.CapsLock 라이트가 변하지 않는 경우는, 키보드를 바꿀 필요가 있다(이것을 실시하기 전에, 컴퓨터를 재기동해, 키보드에 접속 떠날 수 있어 모든 케이블을 확인한다).

    • 마우스 포인터가 움직이지 않는다.

    • 머신이 리모트 머신의 ping 에 응답하지 않는다.

    • 복수의 무관계의 프로그램이 올바르게 동작하지 않는다.

    • 시스템이 예기 하지 않고 재기동했을 경우(잘못된 유저 레벨의 프로그램은, 결코 시스템을 정?~ 할 수 없다).

    이 경우, 우선 케이블을 모두 확인해, 그 후 몇개의 진단 툴을 실행해 하드웨어를 확인한다. 또, 문제가 해결될 가능성이 있는, 사용하고 있는 operating system용의 수정 프로그램, 업데이트, 또는 Service Pack 하지만 있을지를 확인한다. 모든 라이브러리(glibc 등)이 최신인 일도 확인한다.

    메모리 문제를 조기에 검출하기 위해서는 ECC 메모리 내장의 머신이 유효하다.

  • 키보드가 락 되고 있는 경우, 다른 유저로부터 머신에 로그인해,kbd_mode -a (을)를 실행해 락을 해제할 수 있는 경우가 있다.

  • 문제의 원인을 찔러?~ 위해(때문에)는, 시스템 로그 파일(/var/log/messages 등)을 조사한다.문제가 MySQL 에 있다고 생각할 수 있는 경우는,MySQL 의 로그 파일도 조사할 필요가 있다. See 항4.10.4. 「바이너리 로그」 .

  • 하드웨어의 문제는 아니라고 생각할 수 있는 경우에는, 문제의 원인이 되는 프로그램을 찔러?~ 필요가 있다.

    top ,ps ,taskmanager (이)나 같은 프로그램을 사용하고, 모든 CPU (을)를 점유 해 버리고 있는 프로그램이나, 머신을 잠그고 있는 프로그램을 조사한다.

  • top ,df (이)나 같은 프로그램을 사용하고, 메모리, 디스크 영역, 열려 있는 파일이나 다른 중요한 자원이 부족할지를 확인한다.

  • 폭주 프로세스가 문제가 되고 있는 경우는, 우선 그 강제 종료를 시도한다.강제 종료되지 않는 경우는, operating system에 버그가 있을 가능성이 있다.

다른 가능성을 모두 조사해, 문제의 원인이 되고 있는 것이 MySQL 서버인가 MySQL 클라이언트이다고 결론있었을 경우에는, 폐사 메일링 리스트 또는 서포트 팀에 버그 리포트를 전송해 주세요.버그 리포트에는, 시스템의 동작, 및 발생하고 있다고 생각할 수 있는 것을, 상세하게 기재해 주세요.또, 문제의 원인이 MySQL 이다고 생각할 수 있는 이유에 대해서도 기입해 주세요.이 장의 모든 상황을 고려에 넣어 주세요.시스템을 조사했을 때에, 문제가 어떻게 발생했는지를 정확하게 기입해 주세요.프로그램 또는 로그 파일의 출력 또는 에러 메세지를 기입하는 경우는,' 컷 & 페이스트' (을)를 사용해 주세요.

동작하고 있지 않는 프로그램 및 모든 증상을 상세하게 기술하도록 해 주세요.과거," 시스템이 동작하지 않는다" (으)로 밖에 기술되어 있지 않은 버그 리포트를 많이 받았습니다.이것으로는, 무엇이 문제인가 모릅니다.

프로그램이 실패하는 경우는, 이하를 확인하면 도움이 됩니다.

  • 그 프로그램이 분할 fault 해 코어덤프를 작성할까.

  • 프로그램이 CPU (을)를 점유 하고 있을까.top 그리고 체크한다.무엇인가 무거운 처리를 실시하고 있을 가능성이 있기 위해, 프로그램을 당분간 동작시킨다.

  • 문제의 원인이 mysqld 서버인 경우는,mysqladmin -u root ping 또는 mysqladmin -u root processlist (을)를 실행할 수 있을까.

  • MySQL 서버에 접속하려고 하면, 클라이언트 프로그램에 어떠한 메세지가 표시될까(예를 들어,mysql 그리고 시험한다). 클라이언트가 움직이지 못하게 될까.프로그램으로부터 무엇인가 출력이 있을까.

버그 리포트를 전송해 주실 때 , 이 메뉴얼에 기재되어 있는 원칙에 따라 주세요. See 항1.7.1.2. 「질문 또는 버그의 보고」 .


A.2. MySQL 사용시에 자주 있는 에러

이 섹션에서는, 빈번히 발생하는 몇개의 에러에 대해 설명합니다.에러의 내용과 문제의 해결 방법을 설명합니다.

A.2.1. Access denied 에러

See 항4.3.12. 「Access denied 에러의 원인」 . See 항4.3.6. 「권한 시스템은 어떻게 기능할까」 .

A.2.2. MySQL server has gone away 에러

이 섹션에서는, 관련한다 Lost connection to server during query 에러도 커버하고 있습니다.

MySQL server has gone away 에러의 가장 일반적인 원인은, 서버가 타임 아웃 해 접속이 클로우즈 한 것입니다.디폴트에서는, 아무것도 일어나지 않는 상태가 8 시간 계속 되면, 서버는 접속을 클로우즈 합니다.이 시간은,mysqld 개시시에 wait_timeout 변수를 설정하는 것으로 변경할 수 있습니다.

MySQL server has gone away 에러가 발생하는 일반적인 또 하나의 원인으로서는,MySQL (와)과의 connection상에서 ``close'' (을)를 발행해, 클로우즈 한 connection로 쿼리를 실행하려고 했던 것이 생각할 수 있습니다.

스크립트가 있는 경우는, 클라이언트가 자동재접속을 실행하기 위한 쿼리를 재발행하는 것만으로 해결합니다.

이 경우, 통상 이하의 에러 코드가 취득됩니다(OS 의존입니다).

에러 코드 | 설명
CR_SERVER_GONE_ERROR | 클라이언트가 서버에 문의를 송신할 수 없었습니다.
CR_SERVER_LOST | 클라이언트가 서버에 기입을 실시했을 때 에러는 발생하지 않았습니다만, 문의에 대해서 완전한 회답(또는 어떠한 회답)이 되돌아 오지 않았습니다.

누군가가 kill # 스레드ID# 그리고 실행중의 스레드를 강제 종료했을 경우도, 이 에러가 발생합니다.

mysqladmin version (을)를 실행해, 사용 가능 시간을 조사하는 것에 의해서,MySQL 하지만 강제 종료되어 있지 않은 것을 확인할 수 있습니다.문제가 mysqld 의 크래쉬이면, 크래쉬의 이유를 찾아내는 것에 주력 해 주세요. 이 경우, 우선 쿼리를 재발행하고,MySQL 하지만 다시 강제 종료될지를 체크할 필요가 있습니다. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

잘못된 쿼리인가 너무 큰 쿼리를 서버에 송신했을 경우도, 이 에러가 발생할 가능성이 있습니다.mysqld (은)는 너무 클까 이상이 있는 패킷을 취득하면, 클라이언트에 무엇인가 문제가 발생했다고 간주, 접속을 클로우즈 합니다.큰 쿼리가 필요한 경우(예를 들어, 큰 BLOB 컬럼을 사용하고 있는 경우),mysqld (을)를 -O max_allowed_packet=# 옵션(디폴트 1MB )(으)로 기동하고, 쿼리 제한을 끌어올릴 수 있습니다.확장 메모리는 요구에 따라 할당할 수 있습니다.그 때문에,mysqld (은)는, 유저가 큰 쿼리를 발행할 때나,mysqld 하지만 큰 결과 레코드를 돌려줄 필요가 있을 때만, 메모리를 늘려 할당합니다.

클라이언트가 4.0.8 보다 낡고, 서버가 4.0.8 이상의 경우, 또는 그 반대의 경우,16MB 이상의 패킷을 송신하면 접속이 없어집니다.

이 문제에 대해 버그 리포트를 작성할 때 , 반드시 이하의 정보를 기입해 주세요.

  • MySQL 하지만 강제 종료되었는지(이 정보는,hostname.err 파일 에 있다). See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

  • 특정의 쿼리가,mysqld 라고 쿼리 실행전에 CHECK TABLE 에 의한 체크가 실행된 관련 테이블을 강제 종료하는 경우, 이 시험대를 실행할 수 있을까. See 항E.1.6. 「테이블이 파손했을 경우에 시험대를 작성한다」 .

  • MySQL 서버에 있어서의 wait_timeout 변수의 값은 무엇인가. 이 값은,mysqladmin variables 그리고 확인할 수 있다.

  • mysqld (을)를 --log 그리고 실행해, 발행한 쿼리가 로그에 출력되고 있는지 어떤지 체크했는지.

See 항1.7.1.2. 「질문 또는 버그의 보고」 .

A.2.3. Can't connect to [local] MySQL server 에러

Unix 위의 MySQL 하 mysqld 서버에 다음의2 개의 방법으로 접속할 수 있습니다.Unix 소켓, 이것은 파일 시스템상의 파일(디폴트에서는 /tmp/mysqld.sock )(을)를 통해 접속합니다.또는 TCP/IP 그리고, 이것은 포토 번호를 통해 접속합니다. Unix 소켓은,TCP/IP 보다 고속으로 가, 같은 컴퓨터의 서버에 접속하는 경우 밖에 사용할 수 없습니다.Unix 소켓은, 호스트명을 지정하지 않는 경우, 또는 특별한 호스트명 localhost (을)를 지정하는 경우에 사용됩니다.

Windows 그럼,mysqld 서버가 9x/Me 그리고 동작하고 있는 경우,TCP/IP (을) 통한 봐 접속할 수 있습니다.서버가 NT/2000/XP 그리고 동작하고 있어,mysqld 하지만 --enable-named-pipe 그리고 기동하고 있는 경우는, 이름 파이프와 접속할 수도 있습니다.이름 파이프의 이름은 MySQL 입니다. mysqld 에 접속할 때에 호스트명을 주지 않는 경우는,MySQL 클라이언트는 최초로 이름 파이프에 접속하려고 합니다.이것이 올바르게 기능하지 않는 경우는,TCP/IP 포토에 접속합니다.호스트명으로서 . (을)를 사용하는 것으로써,Windows 의 이름 파이프를 강제적으로 사용할 수 있습니다.

에러(2002 )Can't connect to ... (은)는, 통상,MySQL 서버가 시스템상에서 동작하고 있지 않는지, 잘못된 소켓 파일이나 TCP/IP 포토를 사용하고,mysqld 서버에 접속하려고 했을 경우에 발생합니다.

서버상에서 mysqld 그렇다고 하는 프로세스가 동작하고 있을지, (ps 인가,Windows 의 경우는 태스크 매니저를 사용해) 최초로 확인해 주세요.mysqld 프로세스가 없으면, 이것을 기동해 주세요. See 항2.4.2. 「MySQL 서버의 기동에 관한 문제」 .

mysqld 프로세스가 동작하고 있는 경우는, 다양한 접속을 시험해 서버를 확인할 수 있습니다(포토 번호와 소켓의 패스명은, 당연히 셋업시와 다를 가능성이 있습니다).

shell> mysqladmin version
shell> mysqladmin variables
shell> mysqladmin -h `hostname` version variables
shell> mysqladmin -h `hostname` --port=3306 version
shell> mysqladmin -h 'ip for your host' version
shell> mysqladmin --protocol=socket --socket=/tmp/mysql.sock version

hostname 커멘드는, 포워드크트는 아니고 박크크트로 둘러싸 주세요.이것에 의해서,hostname 의 출력(즉 현재의 호스트명)이 mysqladmin 커멘드에 대입됩니다.

Can't connect to local MySQL server 에러가 발생하는 이유로서 이하가 생각할 수 있습니다.

  • mysqld 하지만 동작하고 있지 않다.

  • MIT-pthreads (을)를 사용하는 시스템상에서 실행하고 있다. 네이티브스레드를 가지지 않는 시스템으로 실행하고 있는 경우,mysqld 하 MIT-pthreads 패키지를 사용한다.See 항2.2.3. 「MySQL 하지만 서포트하고 있는 operating system」 .다만, 모든MIT-pthreads 버젼이 Unix 소켓을 서포트하고 있는 것은 아니다.소켓 서포트가 없는 시스템에서는, 서버에 접속할 때에, 항상 호스트명을 명시적으로 지정할 필요가 있다.이하의 커멘드를 사용하고, 서버에의 접속을 확인한다.

    shell> mysqladmin -h `hostname` version

  • 누군가가,mysqld 하지만 사용한다 Unix 소켓(디폴트에서는 /tmp/mysqld.sock )(을)를 삭제했다.MySQL 소켓을 삭제한다 cron 작업(예를 들어,/tmp 디렉토리로부터 낡은 파일을 삭제하는 작업)을 실시하고 있을 가능성이 있다.mysqladmin version (을)를 실행해,mysqladmin 하지만 사용하는 소켓이 정말로 존재할지를 항상 체크할 수 있다.이 경우의 수정 방법은,mysqld.sock (을)를 삭제하지 않게 cron 작업을 변경하는지, 소켓을 다른 장소에 이동시키는 것이다. See 항A.4.5. 「MySQL 소켓 파일 /tmp/mysql.sock 의 보호 또는 변경 방법」 .

  • --socket=/path/to/socket 옵션을 지정하고,mysqld 서버를 개시했다.서버의 소켓 패스명을 변경하는 경우는,MySQL 클라이언트에 새로운 패스를 통지할 필요가 있다.패스를 통지하려면 , 소켓 패스를 인수로서 클라이언트에 제공한다. See 항A.4.5. 「MySQL 소켓 파일 /tmp/mysql.sock 의 보호 또는 변경 방법」 .

  • Linux (을)를 사용중에 스레드가 1 개소멸했다(코어덤프 했다).이 경우, (예를 들어, 새롭다 MySQL 서버를 실행하기 전에 mysql_zap 스크립트를 사용해) 다른 mysqld 스레드를 강제 종료할 필요가 있다. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

  • 소켓 파일을 보관 유지하고 있는 디렉토리, 또는 소켓 파일 자체에의 읽어내 권한과 써 권한이 없을 가능성이 있다.이 경우, 액세스 가능한 디렉토리를 사용하도록(듯이), 디렉토리 또는 파일에 대한 권한을 변경하는지,mysqld (을)를 재기동할 필요가 있다.

에러 메세지 Can't connect to MySQL server on some_hostname 하지만 발생했을 경우는, 이하를 실시하고 문제를 찔러?~ 일이 생깁니다.

  • telnet your-host-name tcp-ip-port-number (을)를 실행하고 서버가 일어서 있는지 어떤지를 확인해,Enter 키를 몇차례 누른다.이 포토로 MySQL 서버가 동작하고 있는 경우는, 동작중의 MySQL 서버의 버젼 번호를 포함한 리스폰스가 되돌아 온다.telnet: Unable to connect to remote host: Connection refused 등의 에러가 발생하는 경우는, 서버는 소정의 포토로 동작하고 있지 않다.

  • 로컬 머신의 mysqld demon에게 접속해,mysqladmin variables 그리고 mysqld 하지만 사용하도록(듯이) 설정되었다 TCP/IP 포토(변수 port )(을)를 확인한다.

  • mysqld 서버가,--skip-networking 옵션으로 기동되어 있지 않은가 확인한다.

A.2.4. Client does not support authentication protocol 에러

MySQL 4.1 그럼, 패스워드 해시 알고리즘에 근거하는 인증 프로토콜이 사용되고 있습니다만, 이것은 구클라이언트가 사용하고 있는 것과 호환성이 없습니다. 서버를 4.1 에 업그레이드 하면, 구클라이언트로 접속하려고 했을 경우에, 이하의 에러 메세지가 발생할 가능성이 있습니다.

shell> mysql
Client does not support authentication protocol requested
by server; consider upgrading MySQL client

이 문제를 해결하려면 , 이하의 어느쪽이든을 실시해 주세요.

  • 전클라이언트 프로그램을 업그레이드 하고,4.1.1 이?~ 의 클라이언트 라이브러리를 사용하도록(듯이) 한다.

  • 4.1 보다 전의 클라이언트로부터 접속하는 경우는, 구패스워드로 유저 어카운트를 사용한다.

  • 4.1 보다 전의 클라이언트를 필요로 하는 유저를 리셋트 해, 구패스워드를 사용하도록(듯이) 한다.

    mysql> UPDATE user SET Password = OLD_PASSWORD('mypass')
    -> WHERE Host = 'some_host' AND User = 'some_user';
mysql> FLUSH PRIVILEGES;

  • 서버가 구패스워드 해시 알고리즘을 사용하도록(듯이) 지정한다.

    1. --old-passwords (을)를 지정해 mysqld (을)를 개시한다.

    2. 롱 패스워드를 가지고 있는 유저 모든 패스워드를 설정한다.이러한 유저는, 이하로 조사할 수 있다.

      SELECT * FROM mysql.user WHERE LEN(password) > 16;

패스워드 해시와 인증의 배경에 대해서는, 항4.3.11. 「MySQL 4.1 의 패스워드 해시」 (을)를 참조해 주세요.

A.2.5. Host '...' is blocked 에러

이하의 에러가 발생했을 경우

Host 'hostname' is blocked because of many connection errors.
Unblock with 'mysqladmin flush-hosts'

이것은,mysqld 하지만 'hostname' 호스트로부터 많은 접속 에러(max_connect_errors )(을)를 받았을 경우에 발생합니다.max_connect_errors 대량 발생 후,mysqld (은)는 무엇인가 문제(크래커로부터의 공격등)가 발생했다고 판단해, 이 호스트로부터의 접속을 거부하도록(듯이) 합니다.이것을 해제하는데는,mysqladmin flush-hosts 커멘드를 실행합니다.

디폴트에서는, 접속 에러가 10 회발생하면,mysqld (은)는 그 호스트를 거부합니다. 이 값은, 이하와 같이 서버를 개시하는 것으로 간단하게 변경할 수 있습니다.

shell> mysqld_safe -O max_connect_errors=10000 &

특정의 호스트에 대해서 이 에러 메세지가 발생하는 경우는, 우선, 그 호스트로부터의 TCP/IP 접속에 문제가 없는가 확인해 주세요.TCP/IP 접속이 기능하고 있지 않는 경우는,max_connect_errors 변수의 값을 늘려도 효과는 없습니다.

A.2.6. Too many connections 에러

MySQL 에 접속하려고 해 Too many connections 에러가 발생하는 경우는, 벌써 mysqld 서버에 접속하고 있다 max_connections 클라이언트가 존재하고 있습니다.

디폴트(100 )보다 많은 접속을 실시하는 경우는,max_connections 변수의 값을 100 보다 크게 하고,mysqld (을)를 재기동할 필요가 있습니다.

실제는,mysqld 그럼(max_connections+1 ) 클라이언트의 접속이 허가되고 있습니다.마지막 접속은,SUPER 특권이 있는 유저용으로 예약되고 있습니다.일반 유저에게 이 특권을 주지 않는 것에 따르고(일반 유저에게 이 특권은 필요 없습니다), 이 특권이 있는 관리자는 로그인하고,SHOW PROCESSLIST (을)를 사용하고 문제를 찾아낼 수 있습니다. See 항4.6.8.6. 「SHOW PROCESSLIST 」 .

MySQL 접속의 최대수는, 스레드라이브라리가 특정의 플랫폼에서 어느 정도까지 유용한가에 의존합니다.Linux 또는 Solaris 그럼, 사용하고 있다 RAM 의 사이즈와 클라이언트가 무엇을 실행하고 있을까에 의해서,500 ~ 1000 의 동시 접속을 서포트할 수 있습니다.

A.2.7. Some non-transactional changed tables couldn't be rolled back 에러

ROLLBACK (을)를 실행하려고 했을 때에 Warning: Some non-transactional changed tables couldn't be rolled back 하지만 발생했을 경우, 트랜잭션(transaction)로 사용한 테이블안에 트랜잭션(transaction)를 서포트하고 있지 않는 것이 있는 것을 나타내고 있습니다.이것들비트랜잭션(transaction) 테이블은,ROLLBACK 스테이트먼트로부터의 영향을 받지 않습니다.

가장 일반적으로는, 이 에러가 발생하는 것은,mysqld 바이너리로 서포트되어 있지 않은 형태의 테이블을 작성하려고 했을 때입니다. mysqld 하지만 테이블형을 서포트하고 있지 않는 경우(또는 스타트 업 옵션으로 테이블형이 무효화되고 있는 경우), 대신에, 요구한 것과 가장 유사한 테이블형(아마 MyISAM )(이)가 작성됩니다.

이하의 커멘드로 테이블의 테이블형을 확인할 수 있습니다.

SHOW TABLE STATUS LIKE 'table_name' . See 항4.6.8.2. 「SHOW TABLE STATUS 」 .

이하의 커멘드로 mysqld 바이너리가 서포트하는 확장자(extension)를 확인할 수 있습니다.

SHOW VARIABLES LIKE 'have_%' . See 항4.6.8.4. 「SHOW VARIABLES 」 .

A.2.8. Out of memory 에러

쿼리를 발행해, 이하와 같은 에러가 발생했을 경우

mysql: Out of memory at line 42, 'malloc.c'
mysql: needed 8136 byte (8k), memory in use: 12481367 bytes (12189k)
ERROR 2008: MySQL client ran out of memory

에러가 MySQL 클라이언트 mysql (을)를 참조하고 있는 것에 주의해 주세요.이 에러의 원인은, 클라이언트에 모든 결과를 격납할 만한 메모리가 없는 것입니다.

문제를 해결하려면 , 우선, 쿼리가 올바른 것을 확인해 주세요.그 쿼리는 대량의 레코드를 돌려주는 것입니까 ? 그렇다면,mysql --quick (을)를 사용할 수 있습니다.이것은, 결과 세트를 꺼내기 위해서 mysql_use_result() (을)를 사용합니다.이것에 의해서 클라이언트의 부하가 작아집니다(서버측에서는 부하가 커집니다).

A.2.9. Packet too large 에러

MySQL 클라이언트 또는 mysqld 서버가 max_allowed_packet 아르바이트보다 큰 패킷을 받았을 경우,Packet too large 에러가 발생해, 접속이 클로우즈 됩니다.

MySQL 3.23 그리고 사용할 수 있는 가장 큰 패킷은 16M 입니다(클라이언트 및 서버 프로토콜의 제한에 의합니다).MySQL 4.01 이상에서는, 패킷의 크기는, 서버상의 메모리 용량에서만 제한됩니다(이론상은 최대 2G ).

1 개의 통신 패킷은,MySQL 서버에 송신되는 단일의 SQL 스테이트먼트인가, 클라이언트에 송신되는 단일행입니다.

MySQL 클라이언트 또는 mysqld 서버가 max_allowed_packet 아르바이트보다 큰 패킷을 받았을 경우는,Packet too large 에러가 발생해, 접속이 클로우즈 됩니다.클라이언트안에는, 통신 패킷이 너무 크면 Lost connection to MySQL server during query 에러를 발생하는 것도 있습니다.

클라이언트와 서버에는, 모두 독자적인 max_allowed_packet 변수가 있습니다.큰 패킷을 취급하는 경우는, 클라이언트와 서버 양쪽 모두의 변수를 늘릴 필요가 있습니다.

메모리는 필요한 경우에게만 할당할 수 있기 위해, 이 변수를 늘려도 안전합니다.이 변수는, 클라이언트와 서버간의 부정한 패킷을 포착하거나 메모리 부족하게 되어 버리는 큰 패킷을 잘못해 사용하거나 하지 않기 위한 예방책입니다.

mysql 클라이언트를 사용하고 있는 경우는, 클라이언트를 mysql --set-variable=max_allowed_packet=8M 그리고 개시하는 것으로, 보다 큰 버퍼를 지정할 수 있습니다. 다른 클라이언트에는, 이 변수를 설정하는 다른 방법이 있습니다. MySQL 4.0 이?~ ,--set-variable (은)는 사용되지 않게 되어 있습니다.대신에 --max-allowed-packet=8M (을)를 사용해 주세요.

옵션 설정 파일을 사용하면,mysqld 그리고 max_allowed_packet (을)를 보다 큰 사이즈로 설정할 수 있습니다.예를 들어,MEDIUMBLOB 의 허용 범위 가득한 데이터를 테이블에 넣는 경우,--set-variable=max_allowed_packet=16M 옵션을 지정해 서버를 기동합니다.

큰 BLOB (을)를 사용하고 있는 경우, 큰 패킷에 관한 낯선 문제가 발생할 가능성이 있습니다만, 이것은,mysqld 에, 그 쿼리를 처리 가능한 한의 충분한 메모리에의 액세스권이 없는 것이 원인입니다.그 경우는,mysqld_safe 스크립트의 초에 ulimit -d 256000 (을)를 추가하고,mysqld (을)를 재기동해 주세요.

A.2.10. 통신 에러/Aborted connection

MySQL 3.23.40 (으)로부터,mysqld (을)를 --warnings 그리고 개시했을 경우만,Aborted connection 에러가 발생합니다.

에러 로그에 이하와 같은 에러가 포함되어 있는 경우는,

010301 14:38:23  Aborted connection 854 to db: 'users' user: 'josh'

See 항4.10.1. 「에러 로그」 .

이하가 발생했다고 생각할 수 있습니다.

  • 클라이언트 프로그램이 종료전에 mysql_close() (을)를 호출하지 않았다.

  • 클라이언트가 어떤 요구도 하지 않고 ,wait_timeout 또는 interactive_timeout 보다 많은 시간 sleeve 상태였다. See 항4.6.8.4. 「SHOW VARIABLES 」 .

  • 클라이언트 프로그램이, 전송중에 돌연 종료했다.

상기가 발생했을 경우, 서버 변수 Aborted_clients 의 값이 증가합니다.

이하의 경우, 서버 변수 Aborted_connects 의 값이 증가합니다.

  • 접속 패킷에 올바른 정보가 포함되지 않은 경우

  • 유저에게 데이타베이스에 접속하는 권한이 없는 경우

  • 유저가 잘못한 패스워드를 사용했을 경우

  • 접속 패킷의 취득에,connect_timeout 그리고 지정되어 있는 초수보다 많이 필요로 했을 경우 See 항4.6.8.4. 「SHOW VARIABLES 」 .

상기는, 부정 유저가 데이타베이스에 침입하려고 하고 있을 가능성을 나타내고 있습니다.

중?~ 된 클라이언트 및 안?~ 된 접속 에러의 그 외의 원인

  • Linux (으)로의 Ethernet 프로토콜의 사용(반이중과 전이중). 많은 Linux Ethernet 드라이버에는, 이 버그가 있다.2 개의 머신간에 ftp (을)를 사용해 큰 파일을 전송 해, 이 버그에 대해 테스트할 필요가 있다. 전송이 burst-pause-burst-pause ... 모드로 행해지고 있는 경우는,Linux 이중 신드롬에 빠져 있다. 유일한 해결책은, 네트워크 카드와 허브/ 스윗치의 이중 모드를, 전이중 또는 반이중으로 전환해 그 결과를 테스트해 가장 좋은 설정을 실시하는 것이다.

  • 독해의 중단의 원인이 되는 스레드라이브라리의 문제.

  • TCP/IP 의 설정 실수.

  • 불량 Ethernet , 허브, 스윗치, 케이블 등.이것은, 하드웨어를 교환해 보는 것으로 밖에 올바르게 진단할 수 없다.

  • max_allowed_packet 하지만 너무 작은지, 쿼리가 mysqld 에 할당할 수 있었던 메모리보다 많은 메모리를 필요로 하고 있다. See 항A.2.9. 「Packet too large 에러」 .

A.2.11. The table is full 에러

이 에러가 발생하는 케이스로서는, 이하와 같이 다양한 케이스를 생각할 수 있습니다.

  • 구버젼(3.23.0 보다 전)의 MySQL (을)를 사용하고 있고, 메모리내의 텐포라리테이불이 tmp_table_size 아르바이트보다 커졌을 때. 이 문제를 회피하려면 ,-O tmp_table_size=# 옵션을 사용해 mysqld 그리고 텐포라리테이브르사이즈를 크게 하는지, 문제의 쿼리를 발행하기 전에,SQL 옵션 SQL_BIG_TABLES (을)를 사용한다. See 항5.5.6. 「SET 구문」 .

    또,--big-tables 옵션을 지정해 mysqld (을)를 개시할 수도 있다. 이것은, 모든 쿼리에 SQL_BIG_TABLES (을)를 사용하고 있는 것과 완전히 같다.

    MySQL 버젼 3.23 그럼, 메모리내의 텐포라리테이불이 tmp_table_size 보다 커지면, 서버가 그 테이블을 자동적으로 디스크 베이스의 MyISAM 테이블로 변환했다.

  • InnoDB 테이블을 사용하고 있어,InnoDB 의 테이블 스페이스가 부족하다.이 문제를 해결하려면 ,InnoDB 의 테이블 스페이스를 확장한다.

  • 사이즈가 2GB 의 파일 밖에 서포트하고 있지 않다 OS 그리고 ISAM 또는 MyISAM 테이블을 사용하고 있어, 데이터 파일 또는 인덱스 파일이 제한에 이르렀다.

  • MyISAM 테이블을 사용하고 있어, 필요한 데이터 또는 인덱스 사이즈가,MySQL 하지만 포인터를 할당한 것보다 커지고 있다(MAX_ROWS (을)를 CREATE TABLE (으)로 지정하지 않는 경우는,MySQL 하 4G 의 데이터를 보관 유지할 수 있는 분만큼 포인터를 할당한다).

    최대 데이터와 인덱스 사이즈를 확인할 수 있다.확인하려면 , 이하의 커멘드를 실행하는지,

    SHOW TABLE STATUS FROM database LIKE 'table_name';

    myisamchk -dv database/table_name (을)를 사용한다.

    이것으로 문제가 있는 경우는, 이하의 방법으로 해결할 수 있다.

    ALTER TABLE table_name MAX_ROWS=1000000000 AVG_ROW_LENGTH=nnn;

    이 경우,MySQL (은)는 레코드수인 만큼 기초를 두어 필요한 스페이스를 최적화할 수 없기 때문에,BLOB/TEXT 필드를 가지는 테이블에 AVG_ROW_LENGTH (을)를 지정하는 것이 필요하게 된다.

A.2.12. Can't create/write to file 에러

이하와 같은 쿼리의 에러가 발생하는 경우

Can't create/write to file '\\sqla3fe_0.ism'.

MySQL 하지만, 특정의 텐포라리디레크트리에 결과 세트용의 임시 파일을 작성할 수 없는 것을 나타내 보이고 있습니다(상기의 에러는,Windows (으)로의 전형적인 에러 메세지입니다만,Unix (으)로의 에러 메세지도 잘 닮은 메세지가 됩니다). 해결하려면 ,--tmpdir=path (을)를 지정해 mysqld (을)를 기동하는지, 옵션 설정 파일에 이하의 코드를 추가합니다.

[mysqld]
tmpdir=C:/temp

c:\\temp 디렉토리가 존재하고 있으면 가정하고 있습니다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

또 perror 그리고, 취득하는 에러 코드를 확인합니다.1 개의 원인으로서 디스크가 가득 차고 있는 일도 생각할 수 있습니다.

shell> perror 28
Error code  28:  No space left on device

A.2.13. 클라이언트로의 Commands out of sync 에러

클라이언트 코드안에 Commands out of sync; you can't run this command now 하지만 있는 경우는, 잘못된 순서로 클라이언트 함수를 호출하고 있습니다.

예를 들어,mysql_free_result() (을)를 호출하기 전에 mysql_use_result() (을)를 사용해 새로운 쿼리를 실행하려고 하면, 상기가 일어날 가능성이 있습니다. 또, 데이터를 돌려준다 2 개의 쿼리를, 그 사이에 mysql_use_result() (이)나 mysql_store_result() (을)를 호출하지 말고 실행했을 경우에도 일어날 가능성이 있습니다.

A.2.14. Ignoring user 에러

다음의 에러가 발생하는 경우

Found wrong password for user: 'some_user@some_host'; ignoring user

mysqld 하지만 재기동되었을 때, 또는 액세스권 테이블이 재로드 되었을 때에,user 테이블에 무효인 패스워드의 엔트리가 발견된 것을 나타내 보이고 있습니다.결과적으로, 이 엔트리는 액세스권 시스템으로부터 무시됩니다.

이 문제를 생각할 수 있는 원인과 수정 방법

  • 구 user 테이블로 신버젼의 mysqld (을)를 실행하고 있을 가능성이 있다. mysqlshow mysql user (을)를 실행해, 패스워드 필드가 16 문자보다 짧은지 어떤지를 조사하는 것에 의해서, 이것을 확인할 수 있다.짧은 경우,scripts/add_long_password 스크립트를 실행하고, 이 상태를 수정할 수 있다.

  • 유저의 패스워드는 구패스워드(8 문자장)이지만,mysqld 하지만 --old-protocol 옵션으로 개시되지 않았다. user 테이블의 유저를 신규 패스워드로 갱신하는지,mysqld (을)를 --old-protocol (을)를 지정해 재기동한다.

  • PASSWORD() 함수를 사용하지 않고 ,user 테이블에 패스워드를 지정했다.mysql (을)를 사용해 user 테이블의 유저를 신규 패스워드로 갱신한다.이 때, 반드시 PASSWORD() 함수를 사용하는 것.

    mysql> UPDATE user SET password=PASSWORD('your password')
    ->             WHERE user='XXX';

A.2.15. Table 'xxx' doesn't exist 에러

에러 Table 'xxx' doesn't exist 또는 Can't find file: 'xxx' (errno: 2) 하지만 발생하는 경우,xxx (이)라는 이름의 경향 데이타베이스에 테이블이 없는 것을 나타내 보이고 있습니다.

MySQL 그럼, 데이타베이스와 테이블의 격납에 디렉토리와 파일을 사용하기 위해(때문에), 데이타베이스와 테이블명은, 대문자와 소문자의 구별이 있는(케이스 의존) 일 에 주의해 주세요 (Windows 그럼, 데이타베이스와 테이블명에 대문자 소문자의 구별이 없습니다.그러나, 쿼리내의 특정 테이블에의 참조에서는 대문자와 소문자를 완전하게 맞출 필요가 있습니다).

SHOW TABLES (을)를 사용하고, 경향 데이타베이스에 있는 테이블을 확인할 수 있습니다. See 항4.6.8. 「SHOW 구문」 .

A.2.16. Can't initialize character set xxx 에러

이하의 에러가 발생했을 경우

MySQL Connection Failed: Can't initialize character set xxx

이하가 생각할 수 있습니다.

  • 캐릭터 세트가 멀티 바이트의 캐릭터 세트이지만, 클라이언트에서는 캐릭터 세트가 서포트되어 있지 않다.

    이 경우, 클라이언트를 --with-charset=xxx 또는 --with-extra-charsets=xxx 그리고 재컴파일 한다. See 항2.3.3. 「일반적인 configure 옵션」 .

    표준 MySQL 바이너리는 모두 --with-extra-character-sets=complex 그리고 컴파일 되고 있다.이것에 의해서, 멀티 바이트의 캐릭터 세트 모든 것이 서포트된다. See 항4.7.1. 「데이터 및 소트용 캐릭터 세트」 .

  • 캐릭터 세트가 단순한 캐릭터 세트로, 그것이 mysqld 에 짜넣어지지 않고, 캐릭터 세트의 정의 파일이 클라이언트의 예상하는 장소에 없다.

    이 경우, 이하와 같이 한다.

    • 캐릭터 세트를 서포트하도록(듯이), 클라이언트를 재컴파일 한다. See 항2.3.3. 「일반적인 configure 옵션」 .

    • 클라이언트에, 캐릭터 세트의 정의 파일의 장소를 통지한다.많은 클라이언트에 대해서,--character-sets-dir=path-to-charset-dir 옵션을 사용해 통지하는 것으로 온다.

    • 문자 정의 파일을, 클라이언트가 그 정의 파일이 있다고 예상하고 있는 패스에 카피한다.

A.2.17. File Not Found 에러

MySQL (으)로부터 ERROR '...' not found (errno: 23) ,Can't open file: ... (errno: 24) , 또는 errno 23 또는 errno 24 (와)과 함께 다른 에러를 받았을 경우,MySQL 에 충분한 파일 기술자가 할당할 수 있지 않은 것을 나타내 보이고 있습니다.perror 유틸리티를 사용하고, 에러 번호가 무엇을 의미하고 있는지, 그 내용을 취득할 수 있습니다.

shell> perror 23
File table overflow
shell> perror 24
Too many open files
shell> perror 11
Resource temporarily unavailable

여기서의 문제는,mysqld 하지만 매우 많은 파일을 동시에 열려 하고 있는 것입니다.mysqld 하지만 동시에 많은 파일을 열지 않게 지정하는지,mysqld 그리고 사용할 수 있는 파일 기술자의 수를 늘릴 수 있습니다.

mysqld 그리고 동시에 여는 파일을 줄이기 위해서,mysqld_safe 에 -O table_cache=32 옵션(초기치는 64 )(을)를 지정하고, 테이블 캐쉬를 작게 할 수 있습니다.max_connections 의 값을 줄이는 것으로, 오픈 파일수(초기치는 90 )도 적게 됩니다.

mysqld 그리고 사용할 수 있는 파일 기술자의 수를 변경하기 위해서,mysqld_safe 에 --open-files-limit=# 옵션, 또는 mysqld 에 -O open-files-limit=# 옵션을 사용할 수 있습니다. See 항4.6.8.4. 「SHOW VARIABLES 」 . 이것을 실시하는 가장 간단한 방법은, 옵션 설정 파일에 옵션을 추가하는 것입니다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 . 이것을 서포트하고 있지 않는 구버젼의 mysqld (을)를 사용하고 있는 경우는,mysqld_safe 스크립트를 편집할 수 있습니다.스크립트에는 comment out 되었다 ulimit -n 256 행이 있습니다.'#' 문자를 삭제해 이 행의 코멘트를 해제해, 숫자 256 (을)를 변경할 수 있습니다.이것에 의해서, mysqld 그리고 사용할 수 있는 파일 기술수도 바뀝니다.

ulimit ( 및 open-files-limit )에 의해서, 파일 기술자의 수를 늘릴 수 있습니다.그러나, operating system로 정해진 상한까지 밖에 늘릴 수 없습니다.또 ' 하드' 리?~ 트가 존재해, 루트로서 mysqld_safe 또는 mysqld (을)를 개시했을 경우에 한정해 덧쓰기할 수 있습니다(이 경우,--user=... 옵션도 사용할 필요가 있습니다).각 프로세스로 이용할 수 있는 파일 기술자의 수의 OS 제한을 늘릴 필요가 있는 경우는, 그 operating system의 문서를 참조해 주세요.

tcsh 쉘을 실행하고 있는 경우는,ulimit (은)는 기능하지 않습니다. tcsh (은)는, 현재의 제한에 대해 문의하면, 잘못된 값을 돌려줍니다.이 경우,mysqld_safe (을)를 sh 그리고 개시할 필요가 있습니다.


A.3. 인스톨 관련의 문제

A.3.1. MySQL 클라이언트 라이브러리에 링크시의 문제

프로그램을 링크할 경우에,mysql_ 그리고 시작되는 미참조 심볼에 관한 이하와 같은 에러가 발생하는 경우

/tmp/ccFKsdPa.o: In function `main':
/tmp/ccFKsdPa.o(.text+0xb): undefined reference to `mysql_init'
/tmp/ccFKsdPa.o(.text+0x31): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x57): undefined reference to `mysql_real_connect'
/tmp/ccFKsdPa.o(.text+0x69): undefined reference to `mysql_error'
/tmp/ccFKsdPa.o(.text+0x9a): undefined reference to `mysql_close'

이것은, 링크행의 최후 에 -Lpath-to-the-mysql-library-lmysqlclient (을)를 추가하면 해결할 수 있습니다.

uncompress 또는 compress 함수로 undefined reference 에러가 발생하는 경우는, 링크행의 최후 에 -lz (을)를 추가해 재차 실행해 주세요.

시스템에 있어야할 함수(예: connect )에 대해서 undefined reference 에러가 발생하는 경우는, 해당하는 함수를 man 페이지로 확인해, 그 라이브러리를 링크행에 추가할지 판단해 주세요.

이하와 같이, 시스템에 존재하지 않는 함수로 undefined reference 에러가 발생하는 경우

mf_format.o(.text+0x201): undefined reference to `__lxstat'

이것은, 통상, 사용하고 있는 시스템과 100% 호환이 아닌 시스템상에서 라이브러리가 컴파일 되고 있는 것을 나타내고 있습니다.이 경우, 최신의 MySQL 소스 디스트리뷰션을 다운로드해, 그것을 독자적으로 컴파일 해 주세요. See 항2.3. 「MySQL 소스 디스트리뷰션의 인스톨」 .

프로그램을 실행하려고 하고 있지만,mysql_ 그리고 시작되는 에러인가,mysqlclient 라이브러리가 발견되지 않는 미참조 심볼의 에러가 발생하는 경우는, 시스템이 libmysqlclient.so 공유 라이브러리를 찾아낼 수 없다고 하는 것을 나타내고 있습니다.

이것을 해결하려면 , 이하의 몇개의 방법으로, 함수가 짜넣어지고 있는 공용 라이브러리를 검색하도록(듯이), 시스템에 지시합니다.

  • LD_LIBRARY_PATH 환경 변수에 libmysqlclient.so 하지만 존재하는 디렉토리의 패스를 추가한다.

  • LD_LIBRARY 환경 변수에 libmysqlclient.so 하지만 존재하는 디렉토리의 패스를 추가한다.

  • libmysqlclient.so (을)를 시스템이 검색하는 장소(예를 들어 /lib )에 카피해,ldconfig (을)를 실행해 공유 라이브러리 정보를 갱신한다.

이 문제를 해결하는 이제(벌써) 1 개의 방법으로서-static (을)를 사용하는지, 코드를 링크하기 전에 MySQL 의 동적 라이브러리를 삭제하고, 프로그램을 정적으로 링크하는 방법이 있습니다.2 번째의 케이스에서는, 다른 프로그램이 동적 라이브러리를 사용하고 있지 않는 것을 확인할 필요가 있습니다.

A.3.2. 일반 유저로 MySQL (을)를 실행하는 방법

MySQL 서버 mysqld (은)는, 어떤 Unix 유저라도 개시, 실행할 수 있습니다. mysqld (을)를 Unix 유저 user_name 그리고 실행할 수 있도록 변경하려면 , 이하를 실시해 주세요.

  1. 서버가 동작하고 있는 경우는, 그것을 정?~ 합니다(mysqladmin shutdown (을)를 사용합니다).

  2. 데이타베이스의 디렉토리와 파일을 변경하고, 그 중의 파일을 읽어들이거나 쓰거나 하는 권한을 user_name 에게 줍니다(경우에 따라서는 Unix root 유저로서 실시할 필요가 있습니다).

    shell> chown -R user_name /path/to/mysql/datadir

    MySQL 데이터 디렉토리내의 디렉토리 또는 파일이 기호 연결의 경우는, 링크에 따라, 그 파일이나 디렉토리가 가리키고 있는 디렉토리와 파일도 변경할 필요가 있습니다.chown -R 그럼, 기호 연결처까지 변경할 수 없습니다.

  3. 서버를 user_name 그리고 개시하는지,MySQL 버젼 3.22 이?~ (을)를 사용하고 있는 경우는,mysqld (을)를Unix root 유저로 개시하고,--user=user_name 옵션을 사용합니다.mysqld (은)는, 접속을 허가하기 전에,Unix 유저 user_name (으)로의 실행에 바뀝니다.

  4. 시스템 기동시에 서버를 특정의 유저명으로 자동적으로 개시하려면 , 유저명을 지정한다 user 행을,/etc/my.cnf 옵션 설정 파일이나 서버의 데이터 디렉토리에 있다 my.cnf 옵션 설정 파일의 [mysqld] 그룹에 추가합니다.예를 들어, 이하와 같이 합니다.

    [mysqld]
user=user_name

이 시점에서,mysqld 프로세스는 Unix 유저 user_name (으)로서 정상적으로 동작합니다.다만, 액세스권 테이블의 내용은 바뀌지 않습니다.디폴트에서는(액세스권 테이블의 인스톨 스크립트 mysql_install_db 의 실행 직후),mysql 데이타베이스에의 액세스 또는 데이타베이스의 작성이나 파기의 권한을 가지는 유일한 유저는 MySQL 유저 root 입니다.이러한 액세스권을 변경하지 않았던 경우, 그 액세스권은 그대로 보관 유지됩니다.root 이외의 Unix 유저로서 로그인하고 있는 경우도,MySQL root 유저로서MySQL 에 액세스 할 수 있습니다.그 때문에(위해) 실시하는 것은,-u root 옵션을 클라이언트 프로그램으로 지정할 뿐입니다.

커멘드 라인으로 -u root (을)를 지정하고,root (으)로서MySQL 에 액세스 하는 것으로,Unix root 유저, 또는 실제로는 다른 Unix 유저로서 MySQL (을)를 실행하는 것으로는 아무 관계도 없습니다 .MySQL 의 액세스권과 유저명은,Unix 유저명과는 완전하게 다른 것입니다.Unix 유저명과 유일 관련이 있는 것은, 클라이언트 프로그램을 호출할 때 -u 옵션을 지정하지 않는 경우에, 클라이언트가 MySQL 유저명으로서 Unix 로그인명을 사용하고 접속을 시도하는 것 뿐입니다.

Unix 박스 그 자체가 보호되어 있지 않은 경우는, 적어도, 액세스 테이블의 MySQL root 유저에게 패스워드를 설정해 둘 필요가 있습니다. 그렇게 하지 않으면, 머신에 어카운트가 있는 유저는,mysql -u root db_name (을)를 실행해 생각 했던 대로를 실시할 수 있습니다.

A.3.3. 파일 액세스권의 문제

파일 액세스권에 문제가 있는 경우, 예를 들어 테이블을 작성할 때에 mysql 하지만 이하의 에러 메세지를 발행했을 경우

ERROR: Can't find file: 'path/with/filename.frm' (Errcode: 13)

mysqld 기동시에, 환경 변수 UMASK 하지만 올바르게 설정되어 있지 않았던 가능성이 있습니다.umask 초기치는 0660 입니다.이하와 같이 mysqld_safe (을)를 실행하고, 이 동작을 변경할 수 있습니다.

shell> UMASK=384  # = 600 in octal
shell> export UMASK
shell> /path/to/mysqld_safe &

디폴트에서는,MySQL (은)는 액세스권 타입 0700 의 데이타베이스와 RAID 디렉토리를 작성합니다.UMASK_DIR 변수를 설정하고, 이 동작을 변경할 수 있습니다.이 변수를 설정하면,UMASK (와)과 UMASK_DIR 하지만 짜 합쳐져 새로운 디렉토리가 작성됩니다.예를 들어 새로운 디렉토리 모두에게 그룹 액세스권을 주는 경우는, 이하를 실행합니다.

shell> UMASK_DIR=504  # = 8
진수로 770
shell> export UMASK_DIR
shell> /path/to/mysqld_safe &

MySQL 버젼 3.23.25 이?~ 그럼,UMASK (와)과 UMASK_DIR 의 값이 제로로 시작되는 경우,MySQL (은)는 그 값을8 진수와 가정합니다.

See 부록 F. 환경 변수 .


A.4. 관리 관련의 문제

A.4.1. MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것

MySQL 버젼은 모두, 릴리스전에 많은 플랫폼에서 테스트되고 있습니다.이것은 MySQL 에 버그가 없다고 하는 것은 아닙니다만, 버그가 있었다고 해도, 매우 적게 찾아내는 것이 곤란합니다.무엇인가 문제가 있는 경우에, 시스템을 크래쉬 시키고 있는 것을 정확하게 조사하는 것은, 이 문제의 조기 해결에 도움이 됩니다.

우선, 문제는 mysqld demon가 죽어 있는 것에 있는지, 또는 문제가 클라이언트에 관계하고 있는지를 판단할 필요가 있습니다.mysqladmin version (을)를 실행하고,mysqld 서버가 가동하고 있던 시간을 확인할 수 있습니다.mysqld 하지만 죽어 있는 경우는, 파일 mysql-data-directory/`hostname`.err (을)를 보는 것으로 그 원인을 찾아낼 수 있습니다. See 항4.10.1. 「에러 로그」 .

시스템안에는, 이 파일에 mysqld 하지만 죽었을 때의 스택 트레이스가 있는 것이 있어,resolve_back_stack 그리고 문제를 해결할 수 있습니다.See 항E.1.4. 「스택 트레이스의 사용」 ..err 파일에 써지고 있는 변수치는, 항상 100 퍼센트 정확하다라고는 한정하지 않습니다.

MySQL 의 크래쉬의 상당수는, 인덱스 파일이나 데이터 파일의 파괴가 원인입니다. MySQL (은)는, 모든 SQL 스테이트먼트의 다음에 write() 시스템 콜을 호출해, 디스크상의 데이터를 갱신합니다.클라이언트에는, 그 후 그 결과가 통지됩니다(delay_key_write 그리고 실행하고 있는 경우로, 데이터의 기입만의 경우에는 이 마지막으로는 없습니다). 즉,OS 에 의해서 플래시 되어 있지 않은 데이터가 디스크에 확실히 써지기 위해,mysqld 하지만 크래쉬 했을 경우에서도 데이터는 안전합니다.--flush (을)를 지정해 mysqld (을)를 개시하는 것에 의해서, 각 SQL 커멘드 실행 후, 강제적으로 모든 것을 디스크와 동기 시킬 수 있습니다.

즉, 이하가 없으면, 통상은 파괴된 테이블을 얻을 것은 없습니다.

  • 누군가 또는 무엇인가가, 갱신중에 mysqld 또는 머신을 강제 종료했다.

  • 갱신중에 mysqld 하지만 죽는 버그를 찾아냈다.

  • 테이블을 적절히 잠그지 말고,mysqld 밖에서 데이터 또는 인젝스후파일을 조작하고 있다.

  • 뛰어난 파일 시스템 락(통상,lockd demon에 의해서 처리된다)를 서포트하고 있지 않는 시스템상에서, 같은 데이터에 대해서, 많은 mysqld 서버를 실행하고 있는지,--skip-external-locking 그리고 복수 서버를 실행하고 있다.

  • mysqld (을)를 혼란시키는 부정한 데이터를 포함한, 파손한 인덱스 또는 데이터 파일이 있다.

  • 데이터 스토리지의 코드에 버그를 발견했다.이것은 아마 있을 수 없는 것이지만, 가능성으로서는 있다.이 경우, 수정된 테이블의 카피에 대해서 ALTER TABLE (을)를 사용하고, 파일 타입을 다른 데이터 스토리지 엔진으로 변경할 수 있다.

크래쉬의 원인을 찾아내는 것은 매우 어렵기 때문에, 우선, 외로 동작하고 있는 것이 자신의 환경에서 크래쉬 할지를 확인해 주세요.이하를 시험해 주세요.

mysqladmin shutdown 그리고 mysqld demon를 정?~ 해, 전테이블로 myisamchk --silent --force */*.MYI (을)를 실행한 후,mysqld demon를 재기동한다.반드시, 깨끗한 상태로부터 실행하는 것. See 장 4. 데이타베이스 관리 .

  • mysqld --log (을)를 사용하고, 로그의 정보로부터, 특정의 쿼리가 서버를 종료시킬지를 판단한다.버그의 95% 하지만 특정의 쿼리에 관계하고 있다.통상, 이것은,MySQL 재실행 직전의 로그 파일에 있는 마지막 쿼리의 1 개이다. See 항4.10.2. 「일반 쿼리 로그」 . 쿼리를 실행하기 직전에 모든 테이블을 확인해도, 쿼리의 1 개로 MySQL (을)를 몇번이나 강제 종료시킬 수 있는 경우, 버그를 찔러?~ 라고 있으므로, 버그 리포트를 발행할 필요가 있다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

  • 문제의 재현에 사용하는 시험대를 작성한다. See 항E.1.6. 「테이블이 파손했을 경우에 시험대를 작성한다」 .

  • 짜넣어지고 있다 mysql-test 테스트와 MySQL 벤치마크를 실행한다.See 항13.1.2. 「MySQL 테스트 스위트」 .이것에 의해서 MySQL (을)를 정확하게 테스트할 수 있다.벤치마크에 어플리케이션을 시?~ 레이트 하는 코드를 추가할 수도 있다.벤치마크는, 소스 디스트리뷰션 또는 바이너리 디스트리뷰션의 bench 디렉토리인가,MySQL 인스톨 디렉토리의 sql-bench 디렉토리에 있다.

  • fork_test.pl (와)과 fork2_test.pl (을)를 실행한다.

  • 디버그용으로 MySQL (을)를 설정해 있는 경우는, 무엇인가 문제가 발생했을 때에, 생각할 수 있는 에러 정보의 수집이 매우 용이하게 된다. configure 에 --with-debug 옵션인가 --with-debug=full 옵션을 지정해 MySQL (을)를 재설정해, 그 후재컴파일 한다. See 항E.1. 「MySQL 서버의 디버그」 .

  • 디버그용으로 MySQL (을)를 설정하면, 안전한 메모 리어 locator가 짜넣어지고 에러를 찾아낼 수 있다.또, 무엇이 발생하고 있을까에 대해서, 많은 정보가 제공된다.

  • operating system의 최신의 패치를 적용하고 있을지 확인한다.

  • mysqld 에 옵션 --skip-external-locking (을)를 지정한다.시스템안에는,lockd 락 매니저가 적절히 동작하지 않는 것이 있다.--skip-external-locking 옵션에 의해서,mysqld 에 외부 락을 사용하지 않게 지시할 수 있다(즉, 같은 데이터로 2 개의 mysqld 서버를 실행할 수 없다.myisamchk (을)를 사용하는 경우는 주의가 필요하지만, 테스트로서 옵션을 사용하는 경우는 유익하다).

  • mysqld 하지만 동작하고 있는 것처럼 보이는데 응답이 없었던 때,mysqladmin -u root processlist (을)를 실행했는지.mysqld (은)는 소멸하고 있는 것처럼 보여도, 소멸하고 있지 않는 경우가 있다.모든 접속이 사용중인지, 내부 락 문제의 가능성이 있다. mysqladmin processlist (은)는, 통상, 이러한 경우여도 접속을 실시할 수 있어 현재의 접속수나 그 상황에 관해서 유익한 정보를 취득할 수 있다.

  • 다른 쿼리를 실행중에, 다른 윈도우로 mysqladmin -i 5 status 또는 mysqladmin -i 5 -r status (을)를 실행해, 통계를 생성한다.

  • 이하를 실행해 본다.

    1. gdb (으)로부터(또는 다른 디버거로),mysqld (을)를 기동한다. See 항E.1.3. 「mysqld 의 디버그(gdb 사용)」 .

    2. 테스트 스크립트를 실행한다.

    3. 3 개의 최하위레벨로, 백 트레이스와 로컬 변수를 출력한다.gdb 그럼,mysqld 하지만 gdb 내부에서 크래쉬 했을 경우, 이하의 커멘드로 이 출력을 실행할 수 있다.

      backtrace
info local
up
info local
up
info local

      gdb 그럼,info threads 에 의해, 존재하고 있는 스레드를 조사해thread # (# (은)는 스레드 ID )(으)로 특정의 스레드에 스윗치 할 수 있다.

  • Perl 스크립트로 어플리케이션을 시?~ 레이트 해,MySQL (을)를 크래쉬 시키거나 부정한 동작을 시키거나 한다.

  • 버그 리포트를 송부한다.See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .상세한 리포트로 하는 것.MySQL (은)는 많은 사람이 사용하고 있기 때문에, 크래쉬가 당신의 컴퓨터인 만큼 있는 어떠한 원인으로 기인하고 있을 가능성이 있다(예를 들어, 특정의 시스템 라이브러리에 관련하는 에러).

  • 가변장 레코드를 가지는 테이블에 문제가 있어,BLOB/TEXT 컬럼(BLOB/TEXT 컬럼만)을 사용하고 있지 않는 경우,ALTER TABLE 그리고 VARCHAR 모든 것을 CHAR (으)로 변경할 수 있다.이것에 의해서,MySQL (은)는 고정 사이즈의 레코드를 사용한다. 고정 사이즈의 레코드는 여분의 영역을 조금 잡을 뿐(만큼)이지만, 파괴에 대해서 매우 큰 내성이 있다.

    현재의 가변장 레코드의 코드는, 적어도 3 연간은 아무 문제도 없고 MySQL AB 그리고 사용되어 왔다.그러나 본래, 가변장 레코드는 에러가 발생하기 쉽고, 상기가 도움이 될지 시험해 보는 것도 유익하다.

A.4.2. 잊은 루트 패스워드를 리셋트 하는 방법

MySQL 에 root 패스워드를 설정하지 않으면root (으)로서 접속했을 경우에, 서버가 패스워드를 일절 요구하지 않게 됩니다.유저 마다 항상 패스워드를 설정하는 것을 추천합니다. See 항4.3.2. 「MySQL 의 크래커 대책」 .

root 패스워드를 설정한 다음에, 그것을 잊어 버렸을 경우, 이하의 순서로 새로운 패스워드를 설정할 수 있습니다.

  1. mysqld 서버에 kill (kill -9 이외)를 보내,mysqld 서버를 정?~ 합니다.pid 하지만 .pid 파일에 격납되고 있습니다.이 파일은 통상,MySQL 데이타베이스 디렉토리에 있습니다.

    shell> kill `cat /mysql-data-directory/hostname.pid`

    이것을 실시하려면 ,Unix root 유저 또는 mysqld 하지만 실행하고 있는 유저와 같지 않으면 안됩니다.

  2. --skip-grant-tables 옵션을 지정해 mysqld (을)를 재기동합니다.

  3. mysqladmin password 커멘드로 새로운 패스워드를 설정합니다.

    shell> mysqladmin -u root password 'mynewpassword'

  4. 이것으로, 적절히 mysqld (을)를 정?~ 해 재기동하는지, 이하와 같이, 액세스권 테이블을 로드할 수 있게 됩니다.

    shell> mysqladmin -h hostname flush-privileges

  5. 이 후, 새로운 패스워드를 사용해 접속할 수 있습니다.

또 하나의 방법으로서mysql 클라이언트를 사용해 새로운 패스워드를 설정할 수 있습니다.

  1. 상술한 것처럼,mysqld (을)를 정?~ 하고,--skip-grant-tables 옵션을 지정해 재기동합니다.

  2. 이하와 같이,mysqld 서버에 접속합니다.

    shell> mysql -u root mysql

  3. mysql 클라이언트로 이하의 커멘드를 실행합니다.

    mysql> UPDATE user SET Password=PASSWORD('mynewpassword')
    ->             WHERE User='root';
mysql> FLUSH PRIVILEGES;

  4. 이 후, 새로운 패스워드를 사용해 접속할 수 있습니다.

  5. 이것으로, 적절히 mysqld (을)를 정?~ 해, 재기동할 수 있습니다.

A.4.3. 풀 디스크시의 MySQL 의 동작

디스크 풀 상태가 발생했을 경우,MySQL 그럼 이하를 실시합니다.

  • 1 분 마다 1 회, 현재의 레코드를 쓰기 위해서 충분한 빈영역이 있을지 확인한다.충분한 빈영역이 있는 경우는, 아무것도 문제가 발생하지 않는 것처럼 처리를 속행한다.

  • 6 분 마다 로그 파일에 엔트리를 써, 디스크 풀 상태를 경고한다.

문제를 경감하기 위해서, 이하를 실시할 수 있습니다.

  • 처리를 속행하려면 , 전레코드를 삽입할 수 있는 디스크 영역을 확보할 필요가 있다.

  • 스레드를 정?~ 하려면 ,mysqladmin kill (을)를 스레드에 송신할 필요가 있다. 스레드는, 다음에 디스크가 체크되었을 때(1 분 )에 정?~ 한다.

  • 다른 스레드가, 디스크 풀 상태의 원인이 된 테이블을 대기하고 있을 가능성이 있다.복수의 `` 락'' 스레드가 있는 경우, 디스크 풀 상태로 대기하고 있는 스레드를 1 개강제 종료하면, 다른 스레드의 처리를 속행할 수 있다.

상기의 동작의 예외는,REPAIR 또는 OPTIMIZE (을)를 사용하고 있을 때인가, 인덱스가 LOAD DATA INFILE 또는 ALTER TABLE 스테이트먼트의 뒤에 배치로 작성될 때입니다.

상기의 커멘드는 모두, 큰 임시 파일을 사용하는 경우가 있으므로, 자원이 얼마 남지 않게 된 시스템에 문제를 일으킬 가능성이 있습니다.상기의 조작을 실행중에 MySQL 하지만 디스크 풀 상태가 되면, 큰 임시 파일이 삭제되어 테이블은 크래쉬 한 것으로서 마크 됩니다( 구테이블이 변경되지 않고 남는다 ALTER TABLE (은)는 제외합니다).

A.4.4. MySQL 하지만 임시 파일을 격납하는 장소

MySQL (은)는, 임시 파일을 격납하는 디렉토리의 패스명으로서TMPDIR 환경 변수의 값을 사용합니다.TMPDIR (을)를 설정하고 있지 않는 경우,MySQL (은)는 시스템의 디폴트를 사용합니다.시스템의 디폴트는, 통상 /tmp 또는 /usr/tmp 입니다.임시 파일 디렉토리를 포함한 파일 시스템이 매우 작은 경우,mysqld_safe (을)를 편집하고, 영역이 충분히 있는 파일 시스템의 디렉토리를 가리키도록(듯이) TMPDIR (을)를 설정할 필요가 있습니다.mysqld 에 대해서 --tmpdir 옵션을 사용해도, 텐포라리디레크트리를 설정할 수 있습니다.

MySQL (은)는 모든 임시 파일을 숨겨 파일로서 작성합니다.이것에 의해서,mysqld 하지만 강제 종료되면 임시 파일은 확실히 삭제됩니다.은폐 파일 사용의 불리한 점은, 임시 파일 디렉토리가 있는 파일 시스템을 가득 채우는 큰 임시 파일이 안보이는 것입니다.

소트시(ORDER BY 또는 GROUP BY 에 의해),MySQL (은)는 통상,1 개 또는2 개의 임시 파일을 사용합니다.필요한 최대 디스크 영역은, 이하대로입니다.

(
소트 되었지만 길이 + sizeof(
데이타베이스 포인터))
*
매치하는 레코드의 수
* 2

sizeof( 데이타베이스 포인터) (은)는, 통상 4 그렇지만, 큰 테이블에 대응하기 위해(때문에), 장래적으로 증가할 가능성이 있습니다.

SELECT 쿼리안에는,MySQL 하지만 텐포라리 SQL 테이블을 작성하는 것이 있습니다.이것들은 숨겨 파일이 아니고,SQL_* (이)라는 이름이 됩니다.

ALTER TABLE 그럼, 원의 테이블과 같은 디렉토리에 텐포라리테이불이 작성됩니다.

MySQL 4.1 이?~ (을)를 사용하고 있는 경우, 코론 : (Windows 의 경우는 세?~ 코론 ; )(으)로 단락지어진 패스의 리스트를 --tmpdir (으)로 설정하는 것으로써, 복수의 물리 디스크간에 부하를 분산시킬 수 있습니다.이 물리 디스크는, 라운드로빈 방식으로 사용됩니다. 주의: 이러한 패스는, 동일 디스크의 복수의 파티션이 아니고, 다르다 물리 디스크일 필요가 있습니다.

tmpdir (을)를 설정해 메모리베이스의 파일 시스템을 지정하는 것은 가능합니다만,MySQL 서버가 슬레이브의 경우는 할 수 없습니다.슬레이브의 경우, 컴퓨터의 재기동용으로, 몇개의 임시 파일이 필요(텐포라리테이불 또는 LOAD DATA INFILE 의 replication 모아 두어)입니다.그 때문에, 컴퓨터의 재기동으로 소거되는 메모리베이스의 tmpdir (은)는 적합하지 않습니다.디스크 베이스의 tmpdir 하지만 필요합니다.

A.4.5. MySQL 소켓 파일 /tmp/mysql.sock 의 보호 또는 변경 방법

모든 사람이 MySQL 통신 소켓 /tmp/mysql.sock (을)를 삭제할 수 있는 것이 문제이면,Unix (이)가 많은 버젼에 대하고,/tmp 파일 시스템에 sticky 비트를 설정하는 것으로써, 그 파일 시스템을 보호할 수 있게 되어 있습니다.root (으)로서 로그인해, 이하를 실시합니다.

shell> chmod +t /tmp

이것에 의해서,/tmp 파일 시스템이 보호되어 파일의 소유자나 슈퍼 유저(root ) 밖에 파일을 삭제할 수 없게 됩니다.

ls -ld /tmp (을)를 실행하고,sticky 비트가 설정되어 있는지 어떤지를 확인할 수 있습니다. 마지막 액세스권 비트가 t 이면, 비트는 설정되어 있습니다.

MySQL 하지만 소켓 파일을 사용 또는 두는 장소를, 이하의 방법으로 변경할 수 있습니다.

  • 글로벌 옵션 설정 파일 또는 로컬 옵션 설정 파일의 패스를 지정한다. 예를 들어,/etc/my.cnf 에 두는 경우

    [client]
socket=path-for-socket-file

[mysqld]
socket=path-for-socket-file

    See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

  • 커멘드 라인으로 --socket=path-for-socket-file 옵션을 사용하고,mysqld_safe (와)과 대부분의 클라이언트에 대해서 소켓을 두는 장소를 지정한다.

  • 소켓 파일의 패스를,MYSQL_UNIX_PORT 환경 변수로 지정한다.

  • configure (을)를 --with-unix-socket-path=path-for-socket-file 옵션과 함께 사용하고, 패스를 정의한다. See 항2.3.3. 「일반적인 configure 옵션」 .

이하의 커멘드로, 소켓의 동작을 테스트할 수 있습니다.

shell> mysqladmin --socket=/path/to/socket version

A.4.6. 타임 존의 문제

SELECT NOW() 하지만 현지시간은 아니고 GMT 의 값을 돌려주는 경우, 현재의 타임 존에 TZ 환경 변수를 설정할 필요가 있습니다.서버가 동작하고 있는 환경(예를 들어 mysqld_safe 또는 mysqld_safe )에 대해서 설정을 실시해 주세요. See 부록 F. 환경 변수 .


A.5. 쿼리 관련의 문제

A.5.1. 검색시의 케이스 의존

디폴트에서는,MySQL 검색에서는 대문자와 소문자는 구별되지 않습니다만(케이스비의존), 안에는, 케이스 의존의 캐릭터 세트(czech )도 있습니다. 즉,col_name LIKE 'a%' 그리고 검색하면,A 또는 a 그리고 시작되는 전컬럼의 값이 검출됩니다.이것을 케이스 의존으로 하는 경우는,INSTR(col_name, "A")=1 (으)로서 프리픽스를 체크합니다.또는, 컬럼치가 확실히 "A" (이)가 아니면 안되는 경우는,STRCMP(col_name, "A") = 0 (을)를 사용합니다.

간단한 비교 연산(>= ,> ,= ,< ,<= , 소트 및 그룹화)는, 각 문자의 `` 소트치'' 에 근거하고 있습니다.같은 소트치가 있는 문자(E ,e 및 e 등)은, 같은 문자로서 다루어집니다.

구 MySQL 버젼에서는,LIKE 비교는, 각 문자의 대문자의 값(E == e but E <> e )(으)로 실행되었습니다.새롭다 MySQL 버젼에서는,LIKE (은)는 다른 비교 연산과 같이 동작합니다.

컬럼을 항상 케이스 의존으로 취급하는 경우는,BINARY (으)로서 선언합니다. See 항6.5.3. 「CREATE TABLE 구문」 .

Big5 (으)로 불리는 encode로 중국어 데이터를 사용하고 있는 경우, 모든 문자 컬럼을 BINARY (으)로 합니다.Big5 encode 문자의 소트 순서는 ASCII 코드의 순서에 근거하고 있기 때문에, 이것이 기능합니다.

A.5.2. DATE 컬럼 사용시의 문제

DATE 값의 서식은 'YYYY-MM-DD' 입니다.표준 SQL 그럼, 다른 서식은 사용할 수 없습니다.이 서식은,UPDATE 식과 SELECT 스테이트먼트의 WHERE 마디로 사용해 주세요.예를 들어, 이하와 같이 사용합니다.

mysql> SELECT * FROM tbl_name WHERE date >= '1997-05-05';

일자가 수치 문맥으로 사용되고 있는 경우는, 편리성을 생각하고,MySQL (은)는 일자를 수치에 자동적으로 변환합니다(반대의 경우도 같습니다).갱신시나 WHERE 마디로 `` 유연한'' 문자열 서식을 사용할 수 있으므로, 일자를 TIMESTAMP ,DATE 또는 DATETIME 컬럼과 비교할 수도 있습니다(유연한 서식이란, 어떤 구두점 문자도 파트간의 단락 기호로서 사용할 수 있는 서식을 말합니다.예를 들어,'1998-08-15' (와)과 '1998#08#15' (은)는 동일합니다).또 MySQL (은)는, 단락 기호를 포함하지 않는 문자열(예를 들어 '19980815' )도, 그것이 일자로서 이해할 수 있는 경우는 변환할 수 있습니다.

특별한 '0000-00-00' 일자는,'0000-00-00' (으)로서 격납해 꺼낼 수 있습니다.MyODBC (을)를 개입시켜 '0000-00-00' 일자를 사용하고 있는 경우,MyODBC 버젼 2.40.12 이상에서는 자동적으로 NULL 에 변환됩니다.

MySQL (은)는 상술의 변환을 실행하기 위해(때문에), 이하의 스테이트먼트를 사용합니다.

mysql> INSERT INTO tbl_name (idate) VALUES (19970505);
mysql> INSERT INTO tbl_name (idate) VALUES ('19970505');
mysql> INSERT INTO tbl_name (idate) VALUES ('97-05-05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997.05.05');
mysql> INSERT INTO tbl_name (idate) VALUES ('1997 05 05');
mysql> INSERT INTO tbl_name (idate) VALUES ('0000-00-00');

mysql> SELECT idate FROM tbl_name WHERE idate >= '1997-05-05';
mysql> SELECT idate FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT MOD(idate,100) FROM tbl_name WHERE idate >= 19970505;
mysql> SELECT idate FROM tbl_name WHERE idate >= '19970505';

다만, 이하는 동작하지 않습니다.

mysql> SELECT idate FROM tbl_name WHERE STRCMP(idate,'19970505')=0;

STRCMP() (은)는 문자열 함수이므로,idate 하지만 문자열에 변환되어 문자열 비교가 실행됩니다.'19970505' (은)는 일자에 변환되지 않고, 일자 비교도 실행되지 않습니다.

MySQL (은)는, 일자가 올바른지 어떤지라고 하는 매우 한정된 확인 밖에 실시하지 않습니다.'1998-2-31' (와)과 같이 부정한 일자를 격납하면, 잘못된 일자가 격납됩니다.

MySQL (은)는, 일자를 압축해 보존하기 위해(때문에), 결과 버퍼에 적합하지 않는 특정의 일자는 격납할 수 없습니다.일자의 수락 규칙은, 이하대로입니다.

  • MySQL 하지만 임의의 일자를 격납해 꺼낼 수 있는 경우,DATE (와)과 DATETIME 컬럼은 잘못한 일자를 받아들인다.

  • 0 ~ 31 의 모든 값은, 어떤 일자에도 받아 들여진다.이것은,3 개의 다른 필드에서 년, 달, 일을 보존한다 Web 어플리케이션에서는 매우 편리하다.

  • 일 또는 달필드를 제로로 할 수도 있다.이것은,DATE 컬럼에 생년월일을 격납하는 경우로, 일자의 일부 밖에 모를 때에 편리하다.

일자를 적절한 값으로 변환할 수 없는 경우는,0 하지만 DATE 필드에 격납되어0000-00-00 (으)로서 꺼내집니다.데이타베이스가 실시하는 것은, 유저가 격납한 일자와 같은 것을 꺼내는 것이므로(일자가 논리적으로 올바르지 않은 경우에서도), 이것은 스피드와 편리성 양쪽 모두의 문제가 됩니다. 우리는, 일자를 확인하는 것은 서버는 아니고 어플리케이션의 책임이다고 생각하고 있습니다.

A.5.3. NULL 값의 문제

NULL 값이라는 것을 SQL 초심자는 자주(잘) 혼란합니다.SQL 초심자는, 많은 경우,NULL 하지만 공문자 "" (와)과 같다라고 생각해 버립니다.이것은 다릅니다.예를 들어, 이하의 스테이트먼트는 완전하게 다른 것입니다.

mysql> INSERT INTO my_table (phone) VALUES (NULL);
mysql> INSERT INTO my_table (phone) VALUES ("");

어느 쪽의 스테이트먼트도, 값을 phone 컬럼에 삽입하고 있습니다.그러나, 최초의 스테이트먼트는 NULL 값을 삽입해,2 번째는 공문자를 삽입하고 있습니다.최초의 스테이트먼트는 `` 전화 번호가 불명'' 이다고 생각할 수 있어2 번째는`` 전화를 가지고 있지 않다'' (이)라고 생각할 수 있습니다.

SQL 그럼,NULL 값은, 다른 값과 비교하면(NULL 그렇지만) 항상 가짜가 됩니다.NULL (을)를 포함한 식은, 연산자와 식에 포함되어 있는 함수의 문서에 특히 거절이 없으면, 항상 NULL 값을 생성합니다.이하의 예에서는, 전컬럼이 NULL (을)를 돌려줍니다.

mysql> SELECT NULL,1+NULL,CONCAT('Invisible',NULL);

NULL 의 컬럼치를 검색하고 싶은 경우,=NULL 테스트는 사용할 수 없습니다.어떤 식이라도 expr = NULL (은)는 가짜이므로, 이하의 스테이트먼트는 레코드를 돌려주지 않습니다.

mysql> SELECT * FROM my_table WHERE phone = NULL;

NULL 값을 검출하려면 ,IS NULL 테스트를 사용합니다. 이하로부터,NULL 의 전화 번호와 하늘의 전화 번호의 검색 방법을 알 수 있습니다.

mysql> SELECT * FROM my_table WHERE phone IS NULL;
mysql> SELECT * FROM my_table WHERE phone = "";

MySQL 버젼 3.23.2 이?~ (을)를 사용해, 한편 MyISAM ,InnoDB ,BDB 테이블형을 사용하고 있는 경우에 한정해,NULL 값을 가질 수 있는 컬럼의 인덱스를 추가할 수 있습니다. 이전의 버젼이나 다른 테이블형에서는,NOT NULL 등의 컬럼을 선언할 필요가 있습니다.이것은,NULL (을)를 인덱스화 된 컬럼에 삽입할 수 없다고 한 것이라도 있습니다.

LOAD DATA INFILE 그리고 데이터를 읽어내면, 하늘의 컬럼은 '' 그리고 갱신됩니다.컬럼에 NULL 값이 필요한 경우는, 텍스트 파일로 \N (을)를 사용해 주세요.상황에 따라서는, 리터럴 문자 'NULL' 도 사용됩니다. See 항6.4.8. 「LOAD DATA INFILE 구문」 .

ORDER BY (을)를 사용할 때,?~ 순서로 소트 하도록(듯이) DESC (을)를 지정하면,NULL 값이 최초 또는 마지막에 표시됩니다.예외: MySQL 버젼 4.0.2 (으)로부터 4.0.10 그럼, 소트 순서에 관련되지 않고 NULL 값은 1 번째에 소트 됩니다.

GROUP BY (을)를 사용하면, 모든 NULL 값이 같을이라고 보여집니다.

COUNT() ,MIN() ,SUM() 등의 집약(요약) 함수에서는,NULL 값은 무시됩니다.예외는 COUNT(*) 입니다.이 함수는, 개개의 컬럼치는 아니고 레코드를 카운트 합니다. 예를 들어, 이하의 스테이트먼트에서는 2 개의 카운트를 합니다. 처음은, 테이블에 있는 레코드수의 카운트입니다.2 번째는 age 컬럼에게 있는 비 NULL 값의 카운트입니다.

mysql> SELECT COUNT(*), COUNT(age) FROM person;

NULL 처리를 보충하기 위해서,IS NULL (와)과 IS NOT NULL 연산자와 IFNULL() 함수를 사용할 수 있습니다.

컬럼형안에는,NULL 값이 특별히 다루어지는 것이 있습니다.테이블의 최초의 컬럼 TIMESTAMP 에 NULL (을)를 삽입하면, 현재의 일자와 시각이 삽입됩니다.AUTO_INCREMENT 컬럼에 NULL (을)를 삽입하면, 차례의 다음의 번호가 삽입됩니다.

A.5.4. alias 의 문제

앨리어스(alias)를 사용하고,GROUP BY ,ORDER BY 또는 HAVING 부분의 컬럼을 참조할 수 있습니다.앨리어스(alias)를 사용하고, 컬럼에 알기 쉬운 이름을 붙일 수도 있습니다.

SELECT SQRT(a*b) as rt FROM table_name GROUP BY rt HAVING rt > 0;
SELECT id,COUNT(*) AS cnt FROM table_name GROUP BY id HAVING cnt > 0;
SELECT id AS "Customer identity" FROM table_name;

표준 SQL 그럼,WHERE 마디의 앨리어스(alias)를 참조할 수 없습니다.이것은,WHERE 코드가 실행될 때, 컬럼치가 아직 설정되어 있지 않은 경우가 있기 때문에입니다.예를 들어, 이하의 쿼리는 무효 입니다.

SELECT id,COUNT(*) AS cnt FROM table_name WHERE cnt > 0 GROUP BY id;

WHERE 스테이트먼트를 실행해 GROUP BY 부분에 추가하는 레코드를 결정해,HAVING (을)를 실행해 결과 세트로부터 어느 레코드를 사용할까 결정합니다.

A.5.5. 관련 테이블에서의 레코드의 삭제

MySQL 그럼, 서브 쿼리를 서포트하고 있지 않습니다(버젼 4.1 보다 전).또,DELETE 스테이트먼트로의 2 개이상의 테이블의 사용도 서포트하고 있지 않습니다(버젼 4.0 보다 전).그 때문에,2 개의 관련 테이블에서 레코드를 삭제하려면 , 이하의 방법을 사용해 주세요.

  1. 메인 테이블로 WHERE 조건에 근거하고, 레코드를 SELECT 한다.

  2. 같은 조건에 근거하고, 메인 테이블의 레코드를 DELETE 한다.

  3. DELETE FROM related_table WHERE related_column IN (selected_rows) .

related_column 의 쿼리의 합계 문자수가 1,048,576 (max_allowed_packet 의 디폴트치)를 넘는 경우, 분할하고, 여러 차례 DELETE 스테이트먼트를 실행해 주세요.related_column 하지만 인덱스의 경우는,100 ~ 1000 의 related_column ID (을)를 삭제할 뿐(만큼)이므로, 통상 DELETE 하지만 매우 빨라집니다.related_column 하지만 인덱스가 아닌 경우, 속도는 IN 마디의 인수의 수에 의존하지 않습니다.

A.5.6. 부정합레코드의 문제 해결

많은 테이블이 포함되는 복잡한 쿼리를 사용하고 있고, 그것이 레코드를 돌려주지 않는 경우, 이하의 순서로 쿼리의 문제를 찾아낼 필요가 있습니다.

  1. EXPLAIN 그리고 쿼리를 테스트해, 분명하게 문제라고 생각되는 개소가 있는지 확인한다. See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

  2. WHERE 마디로 사용되는 필드만을 선택한다.

  3. 레코드가 돌아갈 때까지, 쿼리로부터 1 개 1 개테이블을 삭제한다. 테이블이 큰 경우에 유효한 것은, 쿼리로 LIMIT 10 (을)를 사용하는 방법이다.

  4. 쿼리로부터 마지막에 삭제된 테이블에 대해서 레코드가 일치한 컬럼에, SELECT (을)를 실행한다.

  5. FLOAT 또는 DOUBLE 컬럼을 소수와 비교하고 있는 경우,'=' (은)는 사용할 수 없다.부동 소수점의 값은 정확한 값은 아니다.이 문제는 대부분의 컴퓨터 언어로 공통. 대부분의 경우,FLOAT (을)를 DOUBLE (으)로 변경하면 문제는 해결한다. See 항A.5.7. 「부동 소수점 비교의 문제」 .

  6. 그런데도 문제를 해결할 수 없는 경우는,mysql test < query.sql 그리고 실행할 수 있는 작은 테스트를 작성하고, 문제를 표시한다. mysqldump --quick database tables > query.sql 그리고, 테스트 파일을 작성할 수 있다.에디터로 파일을 열어, 수가 많으면 몇개의 삽입행을 삭제한다.그리고, 파일의 마지막에 SELECT 스테이트먼트를 추가한다.

    아직 문제가 남아 있는지 어떤지, 이하의 방법으로 테스트해 주세요.

    shell> mysqladmin create test2
shell> mysql test2 < query.sql

    mysqlbug (을)를 사용하고, 테스트 파일을 범용 MySQL 메일링 리스트에 투고해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 .

A.5.7. 부동 소수점 비교의 문제

부동 소수점수(실수)는, 컴퓨터 아키텍쳐 내부에서는 정확한 값으로 해서 격납되지 않기 때문에, 혼란을 일으키는 경우가 있습니다.통상 화면에 표시되는 값은, 정확한 값이 아닙니다.

field type FLOAT ,DOUBLE , 및 DECIMAL 하지만 해당합니다.

CREATE TABLE t1 (i INT, d1 DECIMAL(9,2), d2 DECIMAL(9,2));
INSERT INTO t1 VALUES (1, 101.40, 21.40), (1, -80.00, 0.00),
(2, 0.00, 0.00), (2, -13.20, 0.00), (2, 59.60, 46.40),
(2, 30.40, 30.40), (3, 37.00, 7.40), (3, -29.60, 0.00),
(4, 60.00, 15.40), (4, -10.60, 0.00), (4, -34.00, 0.00),
(5, 33.00, 0.00), (5, -25.80, 0.00), (5, 0.00, 7.20),
(6, 0.00, 0.00), (6, -51.40, 0.00);

mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b
    -> FROM t1 GROUP BY i HAVING a <> b;
+------+--------+-------+
| i    | a      | b     |
+------+--------+-------+
|    1 |  21.40 | 21.40 |
|    2 |  76.80 | 76.80 |
|    3 |   7.40 |  7.40 |
|    4 |  15.40 | 15.40 |
|    5 |   7.20 |  7.20 |
|    6 | -51.40 |  0.00 |
+------+--------+-------+

결과는 정확합니다.최초의 5 개의 레코드는 비교 테스트에 패스하지 않는 것처럼 보입니다만 패스할 수 있습니다.컴퓨터 아키텍쳐에 의합니다만, 수의 차이는, 소수점 제 10 정도 정도로 나타나기 (위해)때문입니다.

결과는 부동 소수점수(실수)이므로,ROUND( ) (또는 같은 함수)(을)를 사용해 문제를 해결할 수 없습니다.예를 들어, 이하대로입니다.

mysql> SELECT i, ROUND(SUM(d1), 2) AS a, ROUND(SUM(d2), 2) AS b
    -> FROM t1 GROUP BY i HAVING a <> b;
+------+--------+-------+
| i    | a      | b     |
+------+--------+-------+
|    1 |  21.40 | 21.40 |
|    2 |  76.80 | 76.80 |
|    3 |   7.40 |  7.40 |
|    4 |  15.40 | 15.40 |
|    5 |   7.20 |  7.20 |
|    6 | -51.40 |  0.00 |
+------+--------+-------+

컬럼 'a' 안의 수는 이하와 같이 됩니다.

mysql> SELECT i, ROUND(SUM(d1), 2)*1.0000000000000000 AS a,
    -> ROUND(SUM(d2), 2) AS b FROM t1 GROUP BY i HAVING a <> b;
+------+----------------------+-------+
| i    | a                    | b     |
+------+----------------------+-------+
|    1 |  21.3999999999999986 | 21.40 |
|    2 |  76.7999999999999972 | 76.80 |
|    3 |   7.4000000000000004 |  7.40 |
|    4 |  15.4000000000000004 | 15.40 |
|    5 |   7.2000000000000002 |  7.20 |
|    6 | -51.3999999999999986 |  0.00 |
+------+----------------------+-------+

컴퓨터 아키텍쳐에 의해서, 같은 결과가 표시되거나 되지 않거나 합니다. CPU 마다 부동 소수점수(실수)의평가방법이 다릅니다.예를 들어 머신안에는, 양쪽 모두의 인수를 1 그리고 걸어 맞추면 ' 정확한' 결과를 얻을 수 있는 것이 있습니다.예를 들어 이하와 같이 됩니다.

경고: 당신의 어플리케이션에서는, 이 방법을 결코 신용하지 말아 주세요.이것은 잘못된 방법의 예입니다.

mysql> SELECT i, ROUND(SUM(d1), 2)*1 AS a, ROUND(SUM(d2), 2)*1 AS b
    -> FROM t1 GROUP BY i HAVING a <> b;
+------+--------+------+
| i    | a      | b    |
+------+--------+------+
|    6 | -51.40 | 0.00 |
+------+--------+------+

상기의 예가 동작하는 것처럼 보이는 이유는, 테스트가 실행된 머신으로,CPU 부동 소수점 연산이 복수의 숫자를 우연히 같은 숫자에 사사오입 해 버리는 것에 있습니다.그러나,CPU 하지만 그렇게 하지 않으면 안 된다고 하는 규칙은 없기 때문에, 이 예는 신용할 수 없습니다.

부동 소수점수(실수) 비교를 실시하는 올바른 방법은, 우선 수의 허용 범위를 결정해, 계속 되어 허용 범위의 수에 대해서 비교를 실시하는 것입니다.예를 들어, 부동 소수점수(실수)는 동일이라고 보기로 하면, 그것들이 10000 분의 1 (0.0001 )의 정도로 같은 경우, 비교가 이하와 같이 행해집니다.

mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
    -> GROUP BY i HAVING ABS(a - b) > 0.0001;
+------+--------+------+
| i    | a      | b    |
+------+--------+------+
|    6 | -51.40 | 0.00 |
+------+--------+------+
1 row in set (0.00 sec)

반대로, 수가 같게 되는 레코드를 취득하고 싶은 경우는, 테스트는 다음과 같이 됩니다.

mysql> SELECT i, SUM(d1) AS a, SUM(d2) AS b FROM t1
    -> GROUP BY i HAVING ABS(a - b) < 0.0001;
+------+-------+-------+
| i    | a     | b     |
+------+-------+-------+
|    1 | 21.40 | 21.40 |
|    2 | 76.80 | 76.80 |
|    3 |  7.40 |  7.40 |
|    4 | 15.40 | 15.40 |
|    5 |  7.20 |  7.20 |
+------+-------+-------+


A.6. Optimizer 관련의 문제

MySQL (은)는 Optimizer를 사용하고, 쿼리를 해결하는 가장 뛰어난 방법을 찾아냅니다.많은 경우,MySQL (은)는 가장 가능성이 있는 쿼리를 추측할 수 있습니다만, 경우에 따라서는 데이터에 관한 충분한 정보가 수중에 없기 때문에, 경험에 근거한다 ' 추측' (을)를 실시할 필요가 있습니다.

여기에서는,MySQL 하지만 올바르게 이해하지 않는 경우를 취급합니다.

MySQL 하지만 ' 올바르고' 최적화하는데 도움이 되는 툴은, 이하대로입니다.

  • EXPLAIN . See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

  • ANALYZE TABLE . See 항4.6.2. 「ANALYZE TABLE 구문」 .

  • USE INDEX, FORCE INDEX 및 IGNORE INDEX . See 항6.4.1. 「SELECT 구문」 .

  • 글로벌 및 테이블 레벨의 STRAIGHT JOIN . See 항6.4.1. 「SELECT 구문」 .

  • 스레드 고유의 변수의 설정. See 항4.6.8.4. 「SHOW VARIABLES 」 .

A.6.1. 테이블 스캔을 회피하는 방법

MySQL 하지만 테이블 스캔을 사용해 쿼리를 해결했을 경우,EXPLAIN 그럼 type 컬럼내에 ALL 하지만 표시됩니다.이것은, 통상 이하의 경우에 일어납니다.

  • 테이블이 작고, 키 주사보다 테이블 스캔을 실시하는 것이 빠른 경우. 이것은, 레코드의 수가 10 미만으로, 레코드의 길이가 짧은 테이블이 자주 있는 케이스이다.

  • ON 또는 WHERE 마디에, 인덱스를 친 컬럼을 이용하는 조건이 없는 경우.

  • 인덱스를 친 컬럼과 변수를 비교중에,MySQL 하지만(인덱스 트리에 근거하고), 변수가 테이블의 대부분의 범위에 이르고 있기 때문에 테이블 스캔이 빠르다고 예측했을 경우. See 항5.2.4. 「MySQL 에 의한다 WHERE 마디의 최적화」 .

  • 다른 컬럼을 개입시키고, 하위의 기수(= 많은 일치 레코드)로 키를 사용하고 있는 경우.이 경우,MySQL (은)는, 그 키를 사용해 많은 키룩크압을 한다고 봐, 테이블 스캔이 빠르다고 본다.

큰 테이블의 ' 부정한' 테이블 스캔을 회피하려면 , 이하를 실시합니다.

  • 스캔 테이블에 대해서 ANALYZE TABLE (을)를 사용해, 키의 분포를 갱신한다. See 항4.6.2. 「ANALYZE TABLE 구문」 .

  • 스캔 테이블에 대해서 FORCE INDEX (을)를 사용해, 테이블의 스캔은, 특정의 인덱스의 사용과 비교하면 매우 처리의 부하가 높은 것을,MySQL 에 통지한다. See 항6.4.1. 「SELECT 구문」 .

    SELECT * FROM t1,t2 force index(index_for_column) WHERE t1.column=t2.column;

  • --max-seeks-for-key=1000 (을)를 지정해 mysqld (을)를 기동할까 SET MAX_SEEKS_FOR_KEY=1000 (을)를 실시해서, Optimizer에, 키스 왈가닥으로 1000 (을)를 넘는 키 검색을 하지 않는 것을 고한다.


A.7. 테이블 정의 관련의 문제

A.7.1. ALTER TABLE 의 문제

ALTER TABLE 에 의해서, 테이블이 현재의 캐릭터 세트로 변경됩니다. ALTER TABLE 안에 duplicate key error 하지만 발생하는 경우, 새로운 캐릭터 세트가 2 개의 키를 같은 값에 맵 하고 있는지, 테이블이 망가져 있습니다.테이블이 망가져 있는 경우는, 그 테이블로 REPAIR TABLE (을)를 실행해 주세요.

이하와 같은 에러로 ALTER TABLE 하지만 강제 종료되는 경우

Error on rename of './database/name.frm' to './database/B-a.frm' (Errcode: 17)

원인으로서MySQL 하지만 전회의 ALTER TABLE 그리고 크래쉬 있어, 사용되어 있지 않다 A-something 또는 B-something (이)라는 이름의 낡은 테이블이 있는 것을 생각할 수 있습니다.이 경우,MySQL 데이터 디렉토리로 옮겨,A- 또는 B- 그리고 시작되는 이름의 파일을 모두 삭제해 주세요(삭제하지 않고 다른 장소로 이동할 수도 있습니다).

ALTER TABLE (은)는, 이하와 같이 동작합니다.

  • 변경 요구가 있었다 A-xxx (이)라는 이름의 새로운 테- 불을 작성한다.

  • 구테이블의 모든 레코드가 A-xxx 에 카피된다.

  • 구테이블명이 B-xxx (으)로 변경된다.

  • A-xxx 하지만 구테이블명으로 변경된다.

  • B-xxx 하지만 삭제된다.

이름 변경 조작에 무엇인가 문제가 발생했을 경우는,MySQL (은)는 변경을 취소합니다.치명적인 문제가 발생했을 경우(물론 일어나서는 안 되는 것입니다만),MySQL (은)는 구테이블을 B-xxx 대로 해 둘 가능성이 있습니다만, 시스템 레벨로의 간단한 이름 변경으로 데이터는 원래대로 돌아갑니다.

A.7.2. 테이블의 컬럼 순서를 변경하는 방법

SQL 의 주된 목적은, 데이터 스토리지로부터 요구한 정보를 추출하는 것입니다.반드시, 데이타를 뽑기 시작하는 순서를 지정할 필요가 있습니다.예를 들어, 이하와 같이 됩니다.

SELECT col_name1, col_name2, col_name3 FROM tbl_name;

상기는,col_name1 ,col_name2 ,col_name3 의 순서로 컬럼을 돌려줍니다.

SELECT col_name1, col_name3, col_name2 FROM tbl_name;

상기의 경우,col_name1 ,col_name3 ,col_name2 의 순서로 컬럼을 돌려줍니다.

컬럼 순서는, 이하와 같이 변경할 수 있습니다.

  1. 올바른 순서의 컬럼으로 새로운 테이블을 작성한다.

  2. INSERT INTO new_table SELECT fields-in-new_table-order FROM old_table (을)를 실행한다.

  3. old_table (을)를 폐기하는지, 이름 변경한다.

  4. ALTER TABLE new_table RENAME old_table .

컬럼을 추가, 이동, 삭제하는 경우, 컬럼이 돌려주어지는 순서와 위치가 같게 안 되기 때문에, 어플리케이션으로,SELECT * (을)를 사용해 그 위치에 의존하는 컬럼을 반드시 꺼내지 말아 주세요.데이타베이스 구조에 간단한 변경을 더하는 것만으로도, 응용프로그램 에러가 발생합니다. 물론 SELECT * (은)는, 쿼리의 테스트에 최적입니다.

A.7.3. 텐포라리테이불의 문제

이하, 텐포라리테이불 의 제한을 나타냅니다.

  • 텐포라리테이불의 형태는,HEAP ,ISAM ,MyISAM , MERGE ,InnoDB 마셔.

  • 텐포라리테이불은 같은 쿼리로 2 회이상 사용할 수 없다. 예를 들어, 이하는 동작하지 않는다.

    mysql> SELECT * FROM temporary_table, temporary_table AS t2;

  • TEMPORARY 테이블로 RENAME (은)는 사용할 수 없다. ALTER TABLE org_name RENAME new_name (은)는 사용할 수 있다.


부록 B. 제공된 프로그램

목차

B.1. API
B.2. 컨버터
B.3. 유틸리티

MySQL (이)가 많은 유저에 의해서, 비상 에 편리한 서포트 툴과 애드 온(add-on)가 제공되었습니다.

MySQL Web 사이트(또는?~ 라)로부터 이용할 수 있는 소프트웨어의 일람은 이하대로입니다.

MySQL 관련 소프트웨어의 온라인 일람에는,http://www.mysql.com/portal/software/ (으)로부터 액세스 할 수 있습니다. 코?~ 니티 기능에 의해, 입력도 실시할 수 있게 되어 있습니다.

Perl DBI/DBD 인터페이스로 MySQL 서포트를 실시하는 경우는,Data-Dumper ,DBI , 및 DBD-mysql 파일을 취득해, 그것들을 인스톨 할 필요가 있습니다. See 항2.7. 「Perl 인스톨에 대한 코멘트」 .

주의: 여기서 소개하는 프로그램은, 자유롭게 다운로드해 사용할 수 있습니다. 프로그램의 저작권은, 각각의 소유자에 속하고 있습니다. 라이센스와 규약의 상세한 것에 대하여는, 각 제품의 문서를 참조해 주세요. MySQL AB (은)는, 본장에 있어서의 정보의 정당성, 또는 여기에 나타나고 있는 프로그램이 정확하게 동작할지에 대해서는, 일절의 책임을 지지 않습니다.

B.1. API

  • Perl 모듈

    • http://www.mysql.com/Downloads/Contrib/KAMXbase1.2.tar.gz .dbf 파일과 MySQL 테이블간의 변환을 실시한다.Pratap Pereira <pereira@ee.eng.ohio-state.edu> 하지만 작성해,Kevin A. McGrail <kmcgrail@digital1.peregrinehw.com> 하지만 확장했다 Perl 모듈. 이 컨버터는,MEMO 필드를 처리할 수 있다.

    • http://www.mysql.com/Downloads/Contrib/HandySQL-1.1.tar.gz HandySQL 하 MySQL 액세스 모듈이다.Perl 에 파묻혔다 C 인터페이스를 제공해, 표준 DBI 보다 약 20 % 빠르다.

  • OLEDB

    • http://www.mysql.com/Downloads/Win32/MyOLEDB3.exe SWSoft 의 MyOLEDB 3.0 인스톨 패키지.

    • http://www.mysql.com/Downloads/Win32/mysql-oledb-3.0.0.zip MyOLEDB 3.0 용소스.

    • http://www.mysql.com/Downloads/Win32/MySamples.zip MyOLEDB 용샘플과 문서.

    • http://www.mysql.com/Downloads/Win32/MyOLEDB.chm MyOLEDB 용헬프 파일.

    • http://www.mysql.com/Downloads/Win32/libmyodbc.zip MyOLEDB 의 빌드에 사용하는 정적 MyODBC 라이브러리.MyODBC 코드에 준거하고 있다.

  • C++

    • http://www.mysql.com/Downloads/Contrib/mysql-c++-0.02.tar.gz MySQL C++ 나팔 라이브러리.Roland Haenel ,<rh@ginster.net> 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/MyDAO.tar.gz MySQL C++ API .Satish <spitfire@pn3.vsnl.net.in> 하지만 작성.Roland Haenel 의 C++ API (와)과 Ed Carp 의 MyC 라이브러리로부터 아이디어를 얻는다.

    • http://www.mysql.com/products/mysql++/ MySQL C++ API (단순한 나팔 라이브러리는 아니다).최초의 작성자는 <kevina@clark.net> .현재 MySQL AB 그리고 Sinisa 에 의해서 보수되고 있다.

    • http://nelsonjr.homepage.com/NJrAPI/ MySQL (을)를 서포트한다 C++ 데이타베이스비의존 라이브러리.

  • Delphi

    • http://www.mysql.com/Downloads/Contrib/DelphiMySQL2.zip libmysql.dll 에 대한다 Delphi 인터페이스.<bsilva@umesd.k12.or.us> 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/Udmysql.pas Delphi 그리고 사용하기 위한 libmysql.dll 용나팔.Reiner Sombrowsky 하지만 작성.

    • http://www.fichtner.net/delphi/mysql.delphi.phtml MySQL 에 대한다 Delphi 인터페이스(원시 코드 첨부).Matthias Fichtner 하지만 작성.

    • http://www.productivity.org/projects/tmysql/ TmySQL .MySQL (을)를 Delphi 그리고 사용하기 위한 라이브러리

    • https://sourceforge.net/projects/zeoslib/ Zeos 라이브러리는,MySQL ,PostgreSQL ,Interbase ,MS SQL ,Oracle 및 DB2 용무의 Delphi 네이티브 데이타베이스와 데이타베이스 컴퍼넌트세트이다.Database Explorer 및 Database Designer 등의 개발툴도 포함되어 있다.

    • http://www.mysql.com/Downloads/Contrib/JdmMysqlDriver-0.1.0.tar.gz MySQL 용 VisualWorks 3.0 Smalltalk 드라이버.<joshmiller@earthlink.net> 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/Db.py 캐쉬 기능이 있다Python 모듈.<gandalf@rosmail.com> 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/MySQLmodule-1.4.tar.gz MySQL 용 Python 인터페이스.Joseph Skinner <joe@earthlight.co.nz> 하지만 작성.Joerg Senekowitsch <senekow@ibm.net> 하지만 수정.

    • http://www.mysql.com/Downloads/Contrib/mysqltcl-1.53.tar.gz MySQL 용 Tcl 인터페이스.msqltcl-1.50.tar.gz 에 준거하고 있다. 버젼 2.0 (와)과 상세한 것에 대하여는,http://www.xdobry.de/mysqltcl/ (을)를 참조.

    • http://www.mysql.com/Downloads/Contrib/MyC-0.1.tar.gz Visual Basic (와)과 같은 API .Ed Carp 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/Vdb-dflts-2.1.tar.gz 이것은,SQL 데이타베이스 엔진에 대한 범용 인터페이스를 제공하는 것을 목적으로 한 라이브러리 유틸리티 세트의 신버젼.이것에 의해서, 어플리케이션이 3 층 어플리케이션이 된다.이점은, 어플리케이션을 변경하지 않고 새로운 연구 최종 단계용 파일을 1 개실장하는 것으로, 다른 데이타베이스간의 스윗치나 다른 데이타베이스에의 이동이 용이하게 실시할 수 있는 것이다.<damian@cablenet.net> 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/DbFramework-1.10.tar.gz DbFramework (은)는,MySQL 데이타베이스를 조작하는 클래스의 모임이다.클래스는,CDIF 데이터 모델의 주제 에리어를 대략적으로 기준으로 하고 있다.Paul Sharpe <paul@miraclefish.com> 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/pike-mysql-1.4.tar.gz pike 용 MySQL 모듈.Roxen Web 서버로 사용.

    • http://www.mysql.com/Downloads/Contrib/squile.tar.gz guile 하지만SQL 데이타베이스라고 대화할 수 있도록 한다 guile 용모듈.Hal Roberts 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/stk-mysql.tar.gz Stk 용인터페이스.Stk (은)는, 하부에 Tcl 이외의 스킴을 가진다 Tk 위제트이다. Terry Jones 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/eiffel-wrapper-1.0.tar.gz Michael Ravits 하지만 작성했다 Eiffel 나팔.

    • http://www.mysql.com/Downloads/Contrib/SQLmy0.06.tgz MySQL 용 FlagShip Replaceable Database Driver (RDD ).Alejandro Fernandez Herrero 하지만 작성. Flagship RDD 홈 페이지의 URL 하 http://www.fship.com/rdds.html .

    • http://www.mysql.com/Downloads/Contrib/mydsn-1.0.zip mydsn.dll 의 바이너리 및 소스.Mydsn (을)를 사용하고,Coldfusion 어플리케이션으로 MyODBC 드라이버의 DNS 레지스트리 파일을 구축, 삭제한다.Miguel Angel Solórzano 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/MySQL-ADA95_API.zip MySQL API 에 대한다 ADA95 인터페이스.Francois Fabien 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/MyTool-DLL_for_VB_and_MySQL.zip Visual Basic 용 MySQL C API 부착 DLL . Ken Menzel <kenm@icarz.com> 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/MYSQLX.EXE 처리가 늦다 ODBC 메소드를 생략 하고,IIS/ASP ,VB ,VC++ (으)로부터 직접 MySQL 서버에 액세스하기 위한 ,MySQL ActiveX 오브젝트.전 MySQL field type를 완전 서포트, 완전 갱신 가능하고 multi-thread화 되고 있다(버젼 2001.1.1 ).SciBit http://www.scibit.com/ 하지만 작성.

    • http://www.fastflow.it/mylua/ MyLUA 홈 페이지.LUA 언어를 사용하고, 실행시에 로드할 수 있다 MySQL PROCEDURE (을)를 작성하는 방법이 기재되어 있다.

      • http://www.mysql.com/Downloads/Contrib/lua-4.0.tar.gz LUA 4.0

      • http://www.mysql.com/Downloads/Contrib/mylua-3.23.32.1.tar.gz LUA 4.0 (을)를 사용하기 위한 MySQL 3.23.32 용패치.Cristian Giussani 하지만 작성.

    • http://www.mysql.com/Downloads/Contrib/patched_myodbc.zip (Omniform 4.0 (을)를 서포트하기 위한 )MyODBC 드라이버의 패치. Thomas Thaele <tthaele@papenmeier.de> 하지만 작성.


B.2. 컨버터

  • http://www.mysql.com/Downloads/Contrib/mssql2mysql.txt MS-SQL (으)로부터 MySQL 에의 컨버터.Michael Kofler 하지만 작성. mssql2mysql 홈 페이지의 URL 하 http://www.kofler.cc/mysql/mssql2mysql.html .

  • http://www.mysql.com/Downloads/Contrib/dbf2mysql-1.14.tar.gz .dbf 파일과 MySQL 테이블간의 변환을 실시한다.Maarten Boekhold (<boekhold@cindy.et.tudelft.nl>) ,William Volkman ,Michael Widenius 하지만 작성.이 컨버터에는,MEMO 필드의 기본적인 읽어내 전용 서포트도 포함되어 있다.

  • http://www.mysql.com/Downloads/Contrib/dbf2mysql-1.13.tgz .dbf 파일과 MySQL 테이블간의 변환을 실시한다.Maarten Boekhold ,<boekhold@cindy.et.tudelft.nl> ,Michael Widenius 하지만 작성. 이 컨버터는,MEMO 필드를 처리할 수 없다.

  • http://www.mysql.com/Downloads/Contrib/dbf2mysql.zip Windows 위에서,FoxPro .dbf 파일과 MySQL 테이블간의 변환을 실시한다. Alexander Eltsyn ,<ae@nica.ru> , 또는 <ae@usa.net> 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/dbf2sql.zip foxpro 테이블에서 MySQL 테이블에의 데이터 전송에 도움이 되는 간결하고 간단한 prg .Danko Josic 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/dump2h-1.20.gz mysqldump 출력으로부터 C 헤더 파일에의 변환을 실시한다.Harry Brueckner <brueckner@mail.respublica.de> 하지만 작성..

  • http://www.mysql.com/Downloads/Contrib/exportsql.txt access_to_mysql.txt 에 유사한 스크립트(이 스크립트가 완전하게 조정 가능한 것을 제외하고).뛰어난 형태 변환(TIMESTAMP 필드의 검출을 포함한다) 기능을 가진다.이 스크립트는, 변환중에 경고나 제안을 실시해, 텍스트나 바이너리 데이터내의 전 특수 문자를 인용부호로 둘러싼다.또,mSQL 버젼 1 및 버젼 2 (으)로 변환해, 무상으로 사용할 수 있다.최신의 버젼에 대해서는,http://www.cynergi.net/exportsql/ (을)를 참조.Pedro Freire ,<support@cynergi.net> 하지만 작성.주의: Access 2.0 그럼 동작하지 않는다.

  • http://www.mysql.com/Downloads/Contrib/access_to_mysql.txt export 하는 테이블이 있는 데이타베이스의 Access 모듈에, 이 함수를 붙인다.exportsql 도 참조.Brian Andrews 하지만 작성. 주의: Access 2 그럼 동작하지 않는다.

  • http://www.mysql.com/Downloads/Contrib/importsql.txt exportsql.txt (와)과 정반대를 실시하는 스크립트.즉,ODBC (을)를 개입시키고, 데이터를 MySQL (으)로부터 Access 데이타베이스에 성적 불능-한다.exportsql (와)과 조합하면 매우 편리하다.이것에 의해서, DB 설계와 관리 모두에게 Access (을)를 사용해, 실제의 MySQL 서버와 동기화할 수 있기 때문이다.무상 제공.업데이트에 대해서는 http://www.netdive.com/freebies/importsql/ (을)를 참조. NetDIVE 의 Laurent Bossavit 하지만 작성. 주의: Access 2.0 그럼 동작하지 않는다.

  • http://www.mysql.com/Downloads/Contrib/mdb2sql.bas Moshe Gurvich 하지만 작성했다 Access97 (으)로부터 MySQL 에의 컨버터.

  • http://www.mysql.com/Downloads/Contrib/msql2mysqlWrapper-1.0.tgz mSQL (으)로부터 MySQL 에의 C 나팔.<alfred@sb.net> 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/sqlconv.pl 1 개의 MySQL 테이블에서 다른 테이블에, 필드를 정리해 카피하는데 사용하는 간단한 스크립트.기본적으로,mysqldump (을)를 실행해,sqlconv.pl 에 파이프 할 수 있다.스크립트는 mysqldump 출력에 의해서 필드를 해석, 재배치하므로, 그 필드를 새로운 테이블에 삽입할 수 있게 된다.예를 들어, 작업중의 다른 사이트에 새로운 테이블을 작성할 때, 그 테이블에 조금 밖에 차이가 없는 경우(즉, 필드의 순서가 차이가 나는 등)에 사용한다. Steve Shreeve 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/oracledump Oracle 데이타베이스를 MySQL (으)로 변환한다 Perl 프로그램.mysqldupm (와)과 같은 출력 형식이다.Johan Andersson 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/excel2mysql Excel 스프레드쉬트를 MySQL 데이타베이스에 임포트 한다 Perl 프로그램. Stephen Hurd <shurd@sk.sympatico.ca> 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/T2S_100.ZIP . 텍스트 파일을 MySQL 데이타베이스로 변환한다 Windows 프로그램.Asaf Azulay 하지만 작성.


B.3. 유틸리티

  • http://worldcommunity.com/opensource/utilities/mysql_backup.html MySQL Backup (은)는,MySQL 용무의 백업 스크립트이다.Peter F. Brown 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/mysql_watchdog.pl 가능한 룩 업에 대해서 MySQL demon를 모니터 한다.Yermo Lamers 하지만 작성. <yml@yml.com> .

  • http://www.mysql.com/Downloads/Contrib/mysql_structure_dumper.tar.gz

  • http://www.mysql.com/Downloads/Contrib/mysql_structure_dumper.tgz 데이타베이스의 전테이블의 구조를 출력.Thomas Wana 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/mysqlsync . 중앙 마스터 카피와 동기를 취하면서 MySQL 데이타베이스의 리모트 카피를 계속한다 Perl 스크립트.Mark Jeftovic 하지만 작성. <markjr@easydns.com> .

  • http://www.mysql.com/Downloads/Contrib/MySQLTutor-0.2.tar.gz . MySQLTutor .초심자 전용 MySQL 튜토리얼.

  • http://www.mysql.com/Downloads/Contrib/MySQLDB.zip

  • http://www.mysql.com/Downloads/Contrib/MySQLDB-readme.html . Alok Singh 하지만 작성했다 MySQL 용 COM 라이브러리.

  • http://www.mysql.com/Downloads/Contrib/mysql_replicate.pl replication를 처리한다 Perl 프로그램.<elble@icculus.nsg.nwu.edu> 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/dbcheck 테이블로 isamchk (을)를 실행하기 전에, 그 테이블의 백업을 취한다 Perl 스크립트. Elizabeth 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/mybackup .

  • http://www.mswanson.com/mybackup (mybackup 의 홈 페이지). 전데이타베이스를 백업 한다 mysqldump 용나팔.Marc Swanson 하지만 작성.

  • http://www.mysql.com/Downloads/Contrib/mdu.pl.gz MySQL 데이타베이스의 기억역사용율을 출력.


부록 C. 협력자

목차

C.1. MySQL AB 의 개발자
C.2. MySQL 에의의 공헌자
C.3. 문서 작성자 및 번역자
C.4. MySQL 그리고 사용되고 있는 라이브러리와 MySQL 부속의 라이브러리
C.5. MySQL (을)를 서포트하는 패키지
C.6. MySQL 의 작성에 사용한 툴
C.7. MySQL 의 서포터

이 부록에서는,MySQL (을)를 오늘의 형태로 하기 위해서 협력해 주신 개발자, 공헌자 및 서포터를 기재하고 있습니다.

C.1. MySQL AB 의 개발자

MySQL 데이타베이스 소프트웨어에 임하기 위해서 MySQL AB 에 채용되고 있다, 또는 채용된 개발자를, 우리와 작업을 개시한 대략의 순서로 기재하고 있습니다.또, 각 개발자의 뒤에, 그 개발자가 담당하고 있는 일 및 개발자의 실적을 기재했습니다.모든 개발자가 서포트 업무에 관련되고 있습니다.

  • Michael (Monty) Widenius

    • MySQL 서버(mysqld )의 주요 개발자 및 주요 작성자.

    • 문자열 라이브러리의 신규 함수.

    • mysys 라이브러리의 대부분.

    • ISAM 및 MyISAM 라이브러리(인덱스 압축과 복수의 레코드 서식을 가진다 B-tree 인덱스 파일 핸들러).

    • HEAP 라이브러리.뛰어난 후르다이나?~ 크핫슈를 가지는 메모리테이브르시스템.1981 해부터 사용되어1984 년경에 공개되었다.

    • replace 프로그램( 뛰어나 것 이다).

    • Windows 95 용무의 ODBC 드라이버이다 MyODBC .

    • MIT-pthread 하지만 MySQL 서버에서도 동작하도록(듯이) 버그를 수정.한층 더 많은 유틸리티를 가진다 curses 베이스의 어플리케이션 툴이다 Unireg (을)를 개발.

    • msqlperl ,DBD/DBI ,DB2mysql 등의 mSQL 툴의 이식.

    • crash-me 의 대부분 MySQL 벤치마크의 기초.

  • David Axmark

    • 참조 설명서 (texi2html 에의 확장을 포함한다)의 최초의 주요 저자.

    • 메뉴얼로부터의 자동 Web 사이트 갱신.

    • 초기의 Autoconf ,Automake 및 Libtool 서포트.

    • 라이센스.

    • 전텍스트 파일 부분(현재는,README 만이 남아 있다.나머지는 메뉴얼에 받아들여졌다).

    • 많은 신기능의 테스트.

    • 사내 프리 소프트의 법률 고문.

    • 메일링 리스트의 보수 관리자(완전하게 관리하는 시간은 없었다).

    • 오리지날의 이식 코드(10 연이상 옛 것)의 개발.현재,mysys 의 일부만이 남아 있다.

    • Monty 하지만 새로운 기능을 동작 시키려고 할 때, 한밤 중에 전화를 하는 상대.

    • 치프 "Open Sourcerer" (MySQL 코?~ 니티 관련).

  • Jani Tolonen

    • mysqlimport

    • 많은 커멘드 라인 클라이언트의 확장.

    • PROCEDURE ANALYSE()

  • Sinisa Milivojevic

    • 클라이언트/ 서버 프로토콜의(zlib 에 의한다) 압축.

    • 자구 analyzer 국면의 완전 해시.

    • 복수행 INSERT .

    • mysqldump -e 옵션.

    • LOAD DATA LOCAL INFILE .

    • SQL_CALC_FOUND_ROWS SELECT 옵션.

    • --max-user-connections=... 옵션.

    • net_read 및 net_write_timeout .

    • GRANT/REVOKE 및 SHOW GRANTS FOR .

    • 4.0 용무의 신규 클라이언트/ 서버 프로토콜.

    • 4.0 의 UNION .

    • 복수 테이블 DELETE/UPDATE .

    • 4.1 의 파생 테이블.

    • 유저 자원 관리.

    • MySQL++ C++ API (와)과 MySQLGUI 클라이언트의 초기 개발자.

  • Tonu Samuel (과거의 개발자)

    • VIO 인터페이스(암호화 클라이언트/ 서버 프로토콜의 기초).

    • MySQL 파일 시스템(파일 및 디렉토리로서 MySQL 데이타베이스를 사용하는 방법).

    • CASE 식.

    • MD5() 및 COALESCE() 함수.

    • MyISAM 테이블의 RAID 서포트.

  • Sasha Pachev

    • replication를 최초로 도입(버젼 4.0 까지).

    • SHOW CREATE TABLE .

    • mysql-bench .

  • Matt Wagner

    • MySQL 테스트스트.

    • Web 마스터(2002 해까지).

    • 개발 코디네이터.

  • Miguel Solorzano

    • Win32 의 개발과 릴리스의 빌드.

    • Windows NT 서버 코드.

    • WinMySQLAdmin

  • Timothy Smith (과거의 개발자)

    • 동적 캐릭터 세트의 서포트.

    • 빌드 시스템의 RPM 및 그 외의 부분을 구축.

    • libmysqld , 매입 서버의 초기의 개발자.

  • Sergei Golubchik

    • 풀텍스트 검색.

    • MERGE 라이브러리에 키를 추가.

  • Jeremy Cole

    • 이 뛰어난 메뉴얼의 교정과 편집.

    • ALTER TABLE ...ORDER BY ... .

    • UPDATE ...ORDER BY ... .

    • DELETE ...ORDER BY ... .

  • Indrek Siitan

    • Web 인터페이스의 설계/ 프로그라?~ 그.

    • 뉴스레터 작성자 관리 시스템.

  • Jorge del Conde

    • MySQLCC (MySQL 컨트롤 센터 ).

    • Win32 개발.

    • Web 사이트 포털을 최초로 도입.

  • Venu Anuganti

    • Connector/ODBC (MyODBC )3.51 .

    • 4.1 의 신규 클라이언트/ 서버 프로토콜(작성제스테이트먼트용).

  • Arjen Lentz

    • MySQL 참조 설명서의 갱신자.

    • O'Reilly 의 인쇄판 메뉴얼의 준비.

  • Alexander (Bar) Barkov ,Alexey (Holyfoot) Botchkov 및 Ramil Kalimullin

    • 4.1 용무의 공간 데이터(GIS )(와)과 R-Tree 의 도입.

    • 4.1 용무의 Unicode와 캐릭터 세트, 및 4.1 용무의 문서.

  • Oleksandr (Sanja) Byelkin

    • 4.0 의 쿼리 캐쉬

    • 서브 쿼리의 도입(4.1 ).

  • Aleksey (Walrus) Kishkin 및 Alexey (Ranger) Stroganov

    • 벤치마크의 설계라고 분석.

    • MySQL 테스트스트의 보수.

  • Zak Greant

    • 오픈 소스의 지지자,MySQL 코?~ 니티의 관계자.

  • Carsten Pedersen

    • MySQL 증명서 프로그램.

  • Lenz Grimmer

    • 제품(빌드 및 릴리스) 엔지니어링.

  • Peter Zaitsev

    •                 SHA1()
,AES_ENCRYPT()

및 AES_DECRYPT()
함수.

    • 각종 기능의 디버그와 클린 업.

  • Alexander (Salle) Keremidarski

    • 서포트.

    • 디버그.

  • Per-Erik Martin

    • Stored Procedure(5.0 )(와)과 Trigger의 주요 개발자.

  • Jim Winstead

    • 주요 Web 개발자.

  • Mark Matthews

    • Connector/J 드라이버(Java ).

  • Peter Gulutzan

    SQL-99 ,SQL:2003 표준 준거

    • 기존의 MySQL 코드/ 알고리즘의 문서화.

    • 캐릭터 세트의 문서화.

  • Guilhem Bichot

    • MySQL 버젼 4.0 (으)로부터의 replication.

    • DECIMAL 지수의 고정 처리.

    • mysql_tableinfo 의 작성자.

  • Antony T. Curtis

    • OS/2 에의 MySQL 데이타베이스 소프트웨어의 이식.


C.2. MySQL 에의의 공헌자

MySQL AB (은)는,MySQL 서버 (와)과 MySQL 메뉴얼 의 전저작권을 보유하고 있습니다만,MySQL 디스트리뷰션 에 공헌해 주신 분들에게 감사 말씀드립니다. 공헌자는 이하대로입니다.무순서입니다.

  • Gianmassimo Vigazzola <qwerg@mbox.vol.it> 또는 <qwerg@tin.it>

    Win32/NT 에의 최초의 이식.

  • Per Eric Olsson

    다소의 건설적인 비판과 동적 레코드 형식에 대한 정확한 테스트.

  • Irena Pancirov <irena@mail.yacc.it>

    Borland 컴파일러를 사용했다 Win32 의 이식.mysqlshutdown.exe 및 mysqlwatch.exe .

  • David J. Hughes

    쉐어웨어의 SQL 데이타베이스의 작성에 진력.MySQL AB 의 전신이다 TcX 그리고,mSQL (을)를 시작했지만, 목적을 만족시키는 것은 아닌 것을 알 수 있었기 때문에, 아프리케이션인타페스비르다 Unireg 에의 SQL 인터페이스의 작성으로 전환.mysqladmin 및 mysql 클라이언트는,mSQL 대응물에 매우 영향을 받은 프로그램이다. 우리는,MySQL 구문이 mSQL 의 슈퍼 세트가 되도록(듯이) 매우 노력했다.이 API 의 아이디어는 mSQL 에 근거한 것으로, 무료의 mSQL 프로그램을 MySQL API 에 간단하게 이식할 수 있도록 했다. MySQL 소프트웨어에는,mSQL 의 코드는 포함되지 않았다. 디스트리뷰션의 2 개의 파일(client/insert_test.c 및 client/select_test.c )(은)는,mSQL 디스트리뷰션의 대응 파일(저작권미취득)에 준거하고 있지만,mSQL (으)로부터 MySQL 서버에 코드를 변환하기 위해서 필요한 변경을 나타내는 예로서 수정되고 있다. (mSQL 의 저작권은 David J. Hughes 에 있다).

  • Patrick Lynch

    http://www.mysql.com/ 의 취득을 지원.

  • Fred Lindberg

    MySQL 메일링 리스트를 처리한다 qmail 의 설정과MySQL 메일링 리스트 관리에 대한 다대한 지원.

  • Igor Romanenko <igor@frog.kiev.ua> mysqldump (이전에는 msqldump 에서 만났지만,Monty 에 의해서 이식, 확장되었다). , Yuri Dario

    MySQL OS/2 의 이식의 계속과 확장.

  • Tim Bunce

    mysqlhotcopy 의 작성자.

  • Zarko Mocnik <zarko.mocnik@dem.si>

    슬로베니아어의 소트.

  • "TAMITO" <tommy@tmtm.org>

    _MB 캐릭터 세트의 매크로와ujis 및 sjis 의 캐릭터 세트.

  • Joshua Chamas <joshua@chamas.com>

    동시 삽입의 기준, 확장 일자 구문,NT (으)로의 디버그,MySQL 메일링 리스트의 회답.

  • Yves Carlier <Yves.Carlier@rug.ac.be>

    유저의 액세스권을 표시하는 프로그램 mysqlaccess .

  • Rhys Jones <rhys@wales.com> ( 및 GWE Technologies Limited )

    초기 JDBC 드라이버의 1 개

  • Dr Xiaokun Kelvin ZHU <X.Zhu@brad.ac.uk>

    초기 JDBC 드라이버의 1 개와 다른 MySQL 관련 Java 툴의 새로운 개발.

  • James Cooper <pixel@organic.com>

    자기 자신의 사이트에서 검색 가능한 메일링 리스트 어카이브(archive)의 셋업.

  • Rick Mehalick <Rick_Mehalick@i-o.com>

    MySQL 서버의 그래피컬한 X 클라이언트이다 xmysql .

  • Doug Sisk <sisk@wix.com>

    Red Hat Linux 대응 MySQL 의 RPM 패키지의 제공.

  • Diemand Alexander V. <axeld@vial.ethz.ch>

    Red Hat Linux-Alpha 대응 MySQL 의 RPM 패키지의 제공.

  • Antoni Pamies Olive <toni@readysoft.es>

    Intel 및 SPARC 대응이 많은 MySQL 클라이언트의 RPM 버젼의 제공.

  • Jay Bloodworth <jay@pathways.sde.state.sc.us>

    MySQL 버젼 3.21 대응 RPM 버젼의 제공.

  • David Sacerdote <davids@secnet.com>

    DNS 호스트명의 시큐러티 체크의 방침.

  • Wei-Jou Chen <jou@nematic.ieo.nctu.edu.tw>

    중국어(BIG5 ) 캐릭터의 서포트.

  • Wei He <hewei@mail.ied.ac.cn>

    중국어(GBK ) 캐릭터 세트 대응이 많은 기능.

  • Jan Pazdziora <adelton@fi.muni.cz>

    체코어의 소트 순서.

  • Zeev Suraski <bourbon@netvision.net.il>

    FROM_UNIXTIME() 의 시간 서식,ENCRYPT() 함수,bison 의 어드바이저. 메일링 리스트의 액티브 멤버.

  • Luuk de Boer <luuk@wxs.nl>

    벤치마크스트를 DBI/DBD 에 이식( 및 확장).crash-me (와)과 벤치마크의 실행의 큰 도움이 되었다.몇개의 신규 일자 함수.mysql_setpermissions 스크립트.

  • Alexis Mikhailov <root@medinf.chuvashia.su>

    유저 정의 가능 함수(UDF ),CREATE FUNCTION 및 DROP FUNCTION .

  • Andreas F. Bobak <bobak@relog.ch>

    UDF 함수의 AGGREGATE 확장.

  • Ross Wakelin <R.Wakelin@march.co.uk>

    MySQL-Win32 용 InstallShield 의 설정의 지원.

  • Jethro Wright III <jetman@li.net>

    libmysql.dll 라이브러리.

  • James Pereria <jpereira@iafrica.com>

    MySQL 서버를 관리한다 Win32 GUI 툴 Mysqlmanager .

  • Curt Sampson <cjs@portal.ca>

    MIT-pthread 의 NetBSD/Alpha 및 NetBSD 1.3/i386 에의 이식.

  • Martin Ramsch <m.ramsch@computer.org>

    MySQL 튜토리얼내의 샘플.

  • Steve Harvey

    mysqlaccess 의 안전성을 높였다.

  • Persistent Systems Private Limited http://www.pspl.co.in/konark/ 의Konark IA-64 Centre .MySQL 서버의 Win64 이식의 지원. , Albert Chin-A-Young.

    Tru64 용업데이트의 설정, 큰 파일의 서포트, 뛰어났다 TCP 나팔의 서포트.

  • John Birrell

    OS/2 용무의 pthread_mutex() 에?~ 레이션.

  • Benjamin Pflugmann

    INSERTS (을)를 처리하는 확장 MERGE 테이블.MySQL 메일링 리스트의 액티브 멤버.

  • Jocelyn Fournier

    (특히 MySQL 4.1 서브 쿼리 코드의) 무수한 버그를 발견해 리포트했다.

  • Marc Liyanage

    Mac OS X 패키지를 보수해,Mac OS X PKG 의 작성 방법에 관한 매우 유익한 피드백을 제공.

  • Robert Rutherford

    QNX 이식에 관한 매우 유익한 정보와 피드백을 제공.

그 외의 공헌자, 버그 발견자, 테스터-: James H. Thompson ,Maurizio Menghini ,Wojciech Tryc ,Luca Berra ,Zarko Mocnik ,Wim Bonis ,Elmar Haneke ,<jehamby@lightside> ,<psmith@BayNetworks.com> ,<duane@connect.com.au> ,Ted Deppner <ted@psyber.com> ,Mike Simons ,Jaakko Hyvatti

메일링 리스트 멤버로부터 제공된 많은 버그 리포트 및 패치

MySQL 메일링 리스트의 질문에 회답해 주신 분들에게 감사 드리겠습니다.

  • Daniel Koch <dkoch@amcity.com>

    Irix 셋업.

  • Luuk de Boer <luuk@wxs.nl>

    벤치마크의 질문.

  • Tim Sailer <tps@users.buoy.com>

    DBD-mysql 의 질문.

  • Boyd Lynn Gerber <gerberb@zenez.com>

    SCO 관련의 질문.

  • Richard Mehalick <RM186061@shellus.com>

    xmysql 관련의 질문과 기본적인 인스톨의 질문.

  • Zeev Suraski <bourbon@netvision.net.il>

    Apache 모듈 구성의 질문(로그 및 권한),PHP 관련의 질문,SQL 문법 관련의 질문, 그 외 일반적인 질문.

  • Francesc Guasch <frankie@citel.upc.es>

    일반적인 질문.

  • Jonathan J Smith <jsmith@wtp.net>

    Linux 의 OS 특정 사항,SQL 구문, 및 어떠한 작업을 필요로 하는 그 외의 일에 관한 질문.

  • David Sklar <sklar@student.net>

    PHP 및 Perl (으)로부터의 MySQL 의 사용.

  • Alistair MacDonald <A.MacDonald@uel.ac.uk>

    아직 지정되어 있지 않지만, 유연성이 있어 Linux 및 아마 HP-UX 도 조작할 수 있다. 유저가 mysqlbug (을)를 사용하도록 노력할 예정.

  • John Lyon <jlyon@imag.net>

    .rpm 파일을 사용한, 또는 소스로부터의 컴파일에 의한다 Linux 시스템에의 MySQL 의 인스톨에 관한 질문.

  • Lorvid Ltd. <lorvid@WOLFENET.com>

    간단한 청구/ 라이센스/ 서포트/ 저작권의 문제.

  • Patrick Sherrill <patrick@coconet.com>

    ODBC 및 VisualC++ 인터페이스에 관한 질문.

  • Randy Harmon <rjharmon@uptimecomputers.com>

    DBD ,Linux , 몇개의 SQL 구문에 관한 질문.


C.3. 문서 작성자 및 번역자

이하,MySQL 문서의 작성, 및 MySLQ 의 문서 또는 에러 메세지의 번역에 협력해 주신 분들입니다.

  • Paul DuBois

    이 메뉴얼을 정확하게 알기 쉽게 하기 위해서, 현재도 협력해 주시고 있다. Monty (와)과 David 의 영어 문서의 리라이트도 포함되어 있다.

  • Kim Aldale

    Monty 및 David 의 초기의 영어 문서의 리라이트.

  • Michael J. Miller Jr. <mke@terrapin.turbolift.com>

    첫회의 MySQL 메뉴얼의 작성.FAQ (대단히 전에 MySQL 메뉴얼로 변경)이 많은 스펠링 또는 언어를 수정.

  • Yan Cailin

    2000 연시째에, 코드화 되었다 Big5 (와)과 HK (http://mysql.hitstar.com/ ) 버젼이 준거하고 있는 중국어(간체자)에 MySQL 참조 설명서를 처음으로 번역. Personal home page at linuxdb.yeah.net .

  • Jay Flaherty <fty@mediapulse.com>

    메뉴얼내의 Perl DBI/DBD 섹션의 대부분에 종사한다.

  • Paul Southworth <pauls@etext.org> ,Ray Loyzaga <yar@cs.su.oz.au>

    참조 설명서의 교정.

  • Therrien Gilbert <gilbert@ican.net> , Jean-Marc Pouyot <jmp@scalaire.fr>

    프랑스어의 에러 메세지.

  • Petr Snajdr ,<snajdr@pvt.net>

    체코어의 에러 메세지.

  • Jaroslaw Lewandowski <jotel@itnet.com.pl>

    폴란드어의 에러 메세지.

  • Miguel Angel Fernandez Roiz

    스페인어의 에러 메세지.

  • Roy-Magne Mo <rmo@www.hivolda.no>

    노르웨이어의 에러 메세지와 버젼 3.21.# 의 테스트.

  • Timur I. Bakeyev <root@timur.tatarstan.ru>

    러시아어의 에러 메세지.

  • <brenno@dewinter.com> & Filippo Grassilli <phil@hyppo.com>

    이탈리아어의 에러 메세지.

  • Dirk Munzinger <dirk@trinity.saar.de>

    독일어의 에러 메세지.

  • Billik Stefan <billik@sun.uniag.sk>

    슬로바키아어의 에러 메세지.

  • Stefan Saroiu <tzoompy@cs.washington.edu>

    루마니아어의 에러 메세지.

  • Peter Feher

    헝가리어의 에러 메세지.

  • Roberto M. Serqueira

    포르투갈어의 에러 메세지.

  • Carsten H. Pedersen

    덴마크어의 에러 메세지.

  • Arjen G. Lentz

    네델란드어의 에러 메세지.이전의 부분 번역의 완성(게다가 정합성과 스펠에 대해서도 체크).


C.4. MySQL 로 사용되고 있는 라이브러리와 MySQL 부속의 라이브러리

이하는, MySQL 의 컴파일과 인스톨을 용이하게 하기 위해서, MySQL 서버 소스에 추가한 라이브러리의 작성자 일람입니다.이것들 라이브러리를 작성해, 작업의 간이화에 진력해 주신 분들에게 감사 말씀드립니다.

  • Fred Fish

    뛰어난 C 디버그와 트레이스 라이브러리.Monty 에 의해, 이 라이브러리에 대해서 많은 세세한 개선(속도와 보충 옵션)을 했다.

  • Richard A. O'Keefe

    퍼블릭 demon의 캐릭터 라인 라이브러리.

  • Henry Spencer

    Regex 라이브러리.WHERE column REGEXP regexp 로 사용.

  • Chris Provenzano

    유저 레벨의 휴대용 pthread.(저작권으로부터 판단) 이 제품에는, Chris Provenzano, the University of California, Berkeley 및 공헌자에 의해 개발된 소프트웨어가 포함되어 있다.현재, 사내에서, Monty 에 의해 패치가 적용된 버젼 1_60_beta6 하지만 사용되고 있다(mit-pthreads/Changes-mysql참조).

  • Jean-loup Gailly 및 Mark Adler

    zlib 라이브러리(Windows 의 MySQL 로 사용).

  • Bjorn Benson

    MySQL 를 --debug 그리고 구성할 때에 사용된다 safe_malloc(메모리체카).

  • 프리 소프트웨어 재단 (Free Software Foundation, FSF)

    readline 라이브러리(mysql 커멘드 라인 클라이언트가 사용).

  • NetBSD 협회

    libedit 패키지(mysql 커멘드 라인 클라이언트가 임의에 사용).


C.5. MySQL (을)를 서포트하는 패키지

많은 유저가 MySQL (와)과 함께 사용하는 중요한 API , 패키지, 및 어플리케이션의 작성자 또는 보수자의 일람을 이하에 나타냅니다.

최신 정보에의 갱신을 간단하고 쉽게 하기 위한(해), 이 일람에는 모든 패키지는 포함되어 있지 않습니다.다른 패키지에 대해서는,http://www.mysql.com/portal/software 의 소프트웨어 포털을 참조해 주세요.

  • Tim Bunce ,Alligator Descartes

    DBD (Perl) 인터페이스.

  • Andreas Koenig <a.koenig@mind.de>

    MySQL 서버용 Perl 인터페이스.

  • Jochen Wiedmann <wiedmann@neckar-alb.de>

    Perl DBD::mysql 모듈의 보수.

  • Eugene Chan <eugene@acenet.com.sg>

    MySQL 서버용 PHP 의 이식.

  • Georg Richter

    MySQL 4.1 의 테스트와 버그 검출. MySQL 4.1 이상으로 사용하기 위한 신규 PHP 5.0 mysqli 확장(API ).

  • Giovanni Maruzzelli <maruzz@matrice.it>

    iODBC 의 이식(Unix ODBC ).

  • Xavier Leroy <Xavier.Leroy@inria.fr>

    LinuxThreads (Linux 위에서 MySQL 서버가 사용)의 작성자.


C.6. MySQL 의 작성에 사용한 툴

이하,MySQL (을)를 작성하기 위해서 사용한 툴의 일람입니다. 여기서, 이러한 툴을 작성한 분들에게 감사 말씀드립니다.이러한 툴이 없으면,MySQL (은)는 오늘의 형태가 되지 않았습니다.

  • 프리 소프트웨어 재단 (Free Software Foundation, FSF)

    뛰어난 컴파일러(gcc )(와)과 뛰어난 디버거(gdb ) 및 libc 라이브러리를 제공.이 라이브러리의 strto.c (을)를 사용하고,Linux 그리고 동작하는 몇개의 코드를 작성했다.

  • 프리 소프트웨어 재단 (와)과 Xemacs 개발 팀

    MySQL AB 그리고 거의 모든 유저가 사용한 뛰어난 에디터 환경을 제공.

  • Julian Seward

    MySQL 의 버그를 검출에 역이었다 매우 뛰어난 메모리체카 valgrind (이것이 없으면 버그 검출은 곤란했다 )의 작성자.

  • Dorothea Lutkehaus 및 Andreas Zeller

    gdb 에 대한 뛰어난 그래피컬 프론트엔드이다 DDD (데이터 표시 디버거)(을)를 제공.


C.7. MySQL 의 서포터

MySQL AB (은)는,MySQL 서버 (와)과 MySQL 메뉴얼 의 전저작권을 소유하고 있습니다만, 신기능의 개발에 대한 융자,MySQL 서버 개발용의 하드웨어의 제공 등,MySQL 서버 의 개발을 조성해 주신 이하의 회사에 감사 말씀드립니다.

  • VA Linux / Andover.net

    자금 제공을 실시한다.

  • NuSphere

    MySQL 메뉴얼의 편집.

  • Stork Design studio

    1998 ~ 2000 해의 MySQL Web 사이트.

  • Intel

    Windows 및 Linux 플랫폼상에서의 개발에 공헌.

  • Compaq

    Linux/Alpha 위에서의 개발에 공헌.

  • SWSoft

    매입 mysqld 버젼으로의 개발.

  • FutureQuest

    --skip-show-database .


부록 D. MySQL Change History

목차

D.1. Changes in release 5.0.0 (Development)
D.2. Changes in release 4.1.x (Alpha)
D.2.1. Changes in release 4.1.2 (not released yet)
D.2.2. Changes in release 4.1.1 (01 Dec 2003)
D.2.3. Changes in release 4.1.0 (03 Apr 2003: Alpha)
D.3. Changes in release 4.0.x (Production)
D.3.1. Changes in release 4.0.17 (not released yet)
D.3.2. Changes in release 4.0.16 (17 Oct 2003)
D.3.3. Changes in release 4.0.15 (03 Sep 2003)
D.3.4. Changes in release 4.0.14 (18 Jul 2003)
D.3.5. Changes in release 4.0.13 (16 May 2003)
D.3.6. Changes in release 4.0.12 (15 Mar 2003: Production)
D.3.7. Changes in release 4.0.11 (20 Feb 2003)
D.3.8. Changes in release 4.0.10 (29 Jan 2003)
D.3.9. Changes in release 4.0.9 (09 Jan 2003)
D.3.10. Changes in release 4.0.8 (07 Jan 2003)
D.3.11. Changes in release 4.0.7 (20 Dec 2002)
D.3.12. Changes in release 4.0.6 (14 Dec 2002: Gamma)
D.3.13. Changes in release 4.0.5 (13 Nov 2002)
D.3.14. Changes in release 4.0.4 (29 Sep 2002)
D.3.15. Changes in release 4.0.3 (26 Aug 2002: Beta)
D.3.16. Changes in release 4.0.2 (01 Jul 2002)
D.3.17. Changes in release 4.0.1 (23 Dec 2001)
D.3.18. Changes in release 4.0.0 (Oct 2001: Alpha)
D.4. Changes in release 3.23.x (Recent; still supported)
D.4.1. Changes in release 3.23.59 (not released yet)
D.4.2. Changes in release 3.23.58 (11 Sep 2003)
D.4.3. Changes in release 3.23.57 (06 Jun 2003)
D.4.4. Changes in release 3.23.56 (13 Mar 2003)
D.4.5. Changes in release 3.23.55 (23 Jan 2003)
D.4.6. Changes in release 3.23.54 (05 Dec 2002)
D.4.7. Changes in release 3.23.53 (09 Oct 2002)
D.4.8. Changes in release 3.23.52 (14 Aug 2002)
D.4.9. Changes in release 3.23.51 (31 May 2002)
D.4.10. Changes in release 3.23.50 (21 Apr 2002)
D.4.11. Changes in release 3.23.49
D.4.12. Changes in release 3.23.48 (07 Feb 2002)
D.4.13. Changes in release 3.23.47 (27 Dec 2001)
D.4.14. Changes in release 3.23.46 (29 Nov 2001)
D.4.15. Changes in release 3.23.45 (22 Nov 2001)
D.4.16. Changes in release 3.23.44 (31 Oct 2001)
D.4.17. Changes in release 3.23.43 (04 Oct 2001)
D.4.18. Changes in release 3.23.42 (08 Sep 2001)
D.4.19. Changes in release 3.23.41 (11 Aug 2001)
D.4.20. Changes in release 3.23.40
D.4.21. Changes in release 3.23.39 (12 Jun 2001)
D.4.22. Changes in release 3.23.38 (09 May 2001)
D.4.23. Changes in release 3.23.37 (17 Apr 2001)
D.4.24. Changes in release 3.23.36 (27 Mar 2001)
D.4.25. Changes in release 3.23.35 (15 Mar 2001)
D.4.26. Changes in release 3.23.34a
D.4.27. Changes in release 3.23.34 (10 Mar 2001)
D.4.28. Changes in release 3.23.33 (09 Feb 2001)
D.4.29. Changes in release 3.23.32 (22 Jan 2001: Production)
D.4.30. Changes in release 3.23.31 (17 Jan 2001)
D.4.31. Changes in release 3.23.30 (04 Jan 2001)
D.4.32. Changes in release 3.23.29 (16 Dec 2000)
D.4.33. Changes in release 3.23.28 (22 Nov 2000: Gamma)
D.4.34. Changes in release 3.23.27 (24 Oct 2000)
D.4.35. Changes in release 3.23.26 (18 Oct 2000)
D.4.36. Changes in release 3.23.25 (29 Sep 2000)
D.4.37. Changes in release 3.23.24 (08 Sep 2000)
D.4.38. Changes in release 3.23.23 (01 Sep 2000)
D.4.39. Changes in release 3.23.22 (31 Jul 2000)
D.4.40. Changes in release 3.23.21
D.4.41. Changes in release 3.23.20
D.4.42. Changes in release 3.23.19
D.4.43. Changes in release 3.23.18
D.4.44. Changes in release 3.23.17
D.4.45. Changes in release 3.23.16
D.4.46. Changes in release 3.23.15 (May 2000: Beta)
D.4.47. Changes in release 3.23.14
D.4.48. Changes in release 3.23.13
D.4.49. Changes in release 3.23.12 (07 Mar 2000)
D.4.50. Changes in release 3.23.11
D.4.51. Changes in release 3.23.10
D.4.52. Changes in release 3.23.9
D.4.53. Changes in release 3.23.8 (02 Jan 2000)
D.4.54. Changes in release 3.23.7 (10 Dec 1999)
D.4.55. Changes in release 3.23.6
D.4.56. Changes in release 3.23.5 (20 Oct 1999)
D.4.57. Changes in release 3.23.4 (28 Sep 1999)
D.4.58. Changes in release 3.23.3
D.4.59. Changes in release 3.23.2 (09 Aug 1999)
D.4.60. Changes in release 3.23.1
D.4.61. Changes in release 3.23.0 (05 Aug 1999: Alpha)
D.5. Changes in release 3.22.x (Old; discontinued)
D.5.1. Changes in release 3.22.35
D.5.2. Changes in release 3.22.34
D.5.3. Changes in release 3.22.33
D.5.4. Changes in release 3.22.32 (14 Feb 2000)
D.5.5. Changes in release 3.22.31
D.5.6. Changes in release 3.22.30
D.5.7. Changes in release 3.22.29 (02 Jan 2000)
D.5.8. Changes in release 3.22.28 (20 Oct 1999)
D.5.9. Changes in release 3.22.27
D.5.10. Changes in release 3.22.26 (16 Sep 1999)
D.5.11. Changes in release 3.22.25
D.5.12. Changes in release 3.22.24 (05 Jul 1999)
D.5.13. Changes in release 3.22.23 (08 Jun 1999)
D.5.14. Changes in release 3.22.22 (30 Apr 1999)
D.5.15. Changes in release 3.22.21
D.5.16. Changes in release 3.22.20 (18 Mar 1999)
D.5.17. Changes in release 3.22.19 (Mar 1999: Production)
D.5.18. Changes in release 3.22.18
D.5.19. Changes in release 3.22.17
D.5.20. Changes in release 3.22.16 (Feb 1999: Gamma)
D.5.21. Changes in release 3.22.15
D.5.22. Changes in release 3.22.14
D.5.23. Changes in release 3.22.13
D.5.24. Changes in release 3.22.12
D.5.25. Changes in release 3.22.11
D.5.26. Changes in release 3.22.10
D.5.27. Changes in release 3.22.9
D.5.28. Changes in release 3.22.8
D.5.29. Changes in release 3.22.7 (Sep 1998: Beta)
D.5.30. Changes in release 3.22.6
D.5.31. Changes in release 3.22.5
D.5.32. Changes in release 3.22.4
D.5.33. Changes in release 3.22.3
D.5.34. Changes in release 3.22.2
D.5.35. Changes in release 3.22.1 (Jun 1998: Alpha)
D.5.36. Changes in release 3.22.0
D.6. Changes in release 3.21.x
D.6.1. Changes in release 3.21.33
D.6.2. Changes in release 3.21.32
D.6.3. Changes in release 3.21.31
D.6.4. Changes in release 3.21.30
D.6.5. Changes in release 3.21.29
D.6.6. Changes in release 3.21.28
D.6.7. Changes in release 3.21.27
D.6.8. Changes in release 3.21.26
D.6.9. Changes in release 3.21.25
D.6.10. Changes in release 3.21.24
D.6.11. Changes in release 3.21.23
D.6.12. Changes in release 3.21.22
D.6.13. Changes in release 3.21.21a
D.6.14. Changes in release 3.21.21
D.6.15. Changes in release 3.21.20
D.6.16. Changes in release 3.21.19
D.6.17. Changes in release 3.21.18
D.6.18. Changes in release 3.21.17
D.6.19. Changes in release 3.21.16
D.6.20. Changes in release 3.21.15
D.6.21. Changes in release 3.21.14b
D.6.22. Changes in release 3.21.14a
D.6.23. Changes in release 3.21.13
D.6.24. Changes in release 3.21.12
D.6.25. Changes in release 3.21.11
D.6.26. Changes in release 3.21.10
D.6.27. Changes in release 3.21.9
D.6.28. Changes in release 3.21.8
D.6.29. Changes in release 3.21.7
D.6.30. Changes in release 3.21.6
D.6.31. Changes in release 3.21.5
D.6.32. Changes in release 3.21.4
D.6.33. Changes in release 3.21.3
D.6.34. Changes in release 3.21.2
D.6.35. Changes in release 3.21.0
D.7. Changes in release 3.20.x
D.7.1. Changes in release 3.20.18
D.7.2. Changes in release 3.20.17
D.7.3. Changes in release 3.20.16
D.7.4. Changes in release 3.20.15
D.7.5. Changes in release 3.20.14
D.7.6. Changes in release 3.20.13
D.7.7. Changes in release 3.20.11
D.7.8. Changes in release 3.20.10
D.7.9. Changes in release 3.20.9
D.7.10. Changes in release 3.20.8
D.7.11. Changes in release 3.20.7
D.7.12. Changes in release 3.20.6
D.7.13. Changes in release 3.20.3
D.7.14. Changes in release 3.20.0
D.8. Changes in release 3.19.x
D.8.1. Changes in release 3.19.5
D.8.2. Changes in release 3.19.4
D.8.3. Changes in release 3.19.3

This appendix lists the changes from version to version in the MySQL source code.

We are now working actively on MySQL 4.1 & 5.0 and will only provide critical bug fixes for MySQL 4.0 and MySQL 3.23. We update this section as we add new features, so that everybody can follow the development.

Our TODO section contains what further plans we have for 4.1 & 5.0. See 항1.6. 「MySQL 의 향후(TODO )」.

Note that we tend to update the manual at the same time we make changes to MySQL. If you find a version listed here that you can't find on the MySQL download page (http://www.mysql.com/downloads/), this means that the version has not yet been released!

The date mentioned with a release version is the date of the last BitKeeper ChangeSet that this particular release has been based on, not the date when the packages have been made available. The binaries are usually made available a few days after the date of the tagged ChangeSet - building and testing all packages takes some time.

D.1. Changes in release 5.0.0 (Development)

For the time being, version 5.0 is only available in source code. See 항2.3.4. 「개발 소스 트리로부터의 인스톨」.

The following changelog shows what has already been done in the 5.0 tree:

  • Basic support for stored procedures (SQL-99 style).

  • Added SELECT INTO list_of_vars, which can be of mixed, that is, global and local type.

  • Deprecated the update log (no longer supported). It is fully replaced by the binary log.

  • User variable names are now case insensitive: if you do SET @a=10; then SELECT @A; will now return 10. Of course, the content of the variable is still case sensitive; only the name of this variable is case insensitive.


D.2. Changes in release 4.1.x (Alpha)

Version 4.1 of the MySQL server includes many enhancements and new features. Binaries for this version are available for download at http://www.mysql.com/downloads/mysql-4.1.html.

  • Subqueries and derived tables (unnamed views). See 항6.4.2. 「서브 쿼리 구문」.

  • INSERT ... ON DUPLICATE KEY UPDATE ... syntax. This allows you to UPDATE an existing row if the insert would cause a duplicate value in a PRIMARY or UNIQUE key. (REPLACE allows you to overwrite an existing row, which is something entirely different.) See 항6.4.3. 「INSERT 구문」.

  • A newly designed GROUP_CONCAT() aggregate function. See 항6.3.7. 「GROUP BY 마디로 사용하는 함수와 수식자」.

  • Extensive Unicode (UTF8) support.

  • Character sets can be defined per column, table, and database.

  • New key cache for MyISAM tables with many tunable parameters. You can have multiple key caches, preload index into caches for batches...

  • BTREE index on HEAP tables.

  • Support for OpenGIS spatial types (geographical data). See 장 10. MySQL 에 있어서의 공간 정보의 기능.

  • SHOW WARNINGS shows warnings for the last command. See 항4.6.8.9. 「SHOW WARNINGS | ERRORS 」.

  • Faster binary protocol with prepared statements and parameter binding. See 항11.1.4. 「C API 의 프리페아드스테이트먼트」.

  • You can now issue multiple statements with a single C API call and then read the results in one go. See 항11.1.8. 「C API 에 있어서의 복수 쿼리의 실행의 취급」.

  • Create Table: CREATE [TEMPORARY] TABLE [IF NOT EXISTS] table2 LIKE table1.

  • Server based HELP command that can be used in the mysql command line client (and other clients) to get help for SQL statements.

For a full list of changes, please refer to the changelog sections for each individual 4.1.x release.

D.2.1. Changes in release 4.1.2 (not released yet)

Functionality added or changed:

Bugs fixed:

  • Packaging: Fixed a bug in the Mac OS PKG postinstall script (mysql_install_db was called with an obsolete argument).

  • Packaging: Added missing file mysql_create_system_tables to the server RPM package. This bug was fixed for the 4.1.1 RPMs by updating the MySQL-server RPM from MySQL-server-4.1.1-0 to MySQL-server-4.1.1-1. The other RPMs were not affected by this change.

  • Fixed a bug in myisamchk and CHECK TABLE that sometimes resulted in a spurious error Found key at page ..... that points to record outside datafile for a table with a FULLTEXT index.

  • Fixed a hang in full-text indexing of EUC-JP (ujis) data.

  • Fixed a crash in full-text indexing of UTF-8 data.

  • Replication: a rare race condition in the slave SQL thread that could lead to an incorrect complaint that the relay log is corrupted. (Bug #2011)

  • Replication: if an administrative command on a table (OPTIMIZE TABLE, REPAIR TABLE etc) was run on the slave, this could sometimes stop the slave SQL thread (this did not lead to any corruption; one just had to type START SLAVE to get replication going again). (Bug #1858)

  • Replication: in the slave SQL thread, a multi-table UPDATE could produce an incorrect complaint that some record was not found in one table, if the UPDATE was preceded by a INSERT ... SELECT. (Bug #1701)

D.2.2. Changes in release 4.1.1 (01 Dec 2003)

Functionality added or changed:

  • Added IGNORE option for DELETE statement.

  • The MySQL source distribution now also includes the MySQL Internals Manual internals.texi.

  • Added mysql_set_server_option() C API client function to allow multiple statement handling in the server to be enabled or disabled.

  • The mysql_next_result() C API function now returns -1 if there are no more result sets.

  • Renamed CLIENT_MULTI_QUERIES connect option flag to CLIENT_MULTI_STATEMENTS. To allow for a transition period, the old option will continue to be recognized for a while.

  • Require DEFAULT before table and database default character set. This enables us to use ALTER TABLE table_name ... CHARACTER SET=... to change the character set for all CHAR, VARCHAR, and TEXT columns in a table.

  • Added MATCH ... AGAINST( ... WITH QUERY EXPANSION) and the ft_query_expansion_limit server variable.

  • Removed unused ft_max_word_len_for_sort server variable.

  • Full-text search now supports multi-byte character sets and the Unicode utf8 character set. (The Unicode ucs2 character set is not yet supported.)

  • Phrase search in MATCH ... AGAINST ( ... IN BOOLEAN MODE) no longer matches partial words.

  • Added aggregate function BIT_XOR() for bitwise XOR operations.

  • Replication over SSL now works.

  • The START SLAVE statement now supports an UNTIL clause for specifying that the slave SQL thread should be started but run only until it reaches a given position in the master's binary logs or in the slave's relay logs.

  • Produce warnings even for single-row INSERT statements, not just for multiple-row INSERT statements. Previously, it was necessary to set SQL_WARNINGS=1 to generate warnings for single-row statements.

  • Added delimiter (\d) command to the mysql command-line client for changing the statement delimiter (terminator). The default delimiter is semicolon.

  • CHAR, VARCHAR, and TEXT columns now have lengths measured in characters rather than in bytes. The character size depends on the column's character set. This means, for example, that a CHAR(n) column for a multi-byte character set will take more storage than before. Similarly, index values on such columns are measured in characters, not bytes.

  • LIMIT no longer accepts negative arguments (they used to be treated as very big positive numbers before).

  • The DATABASE() function now returns NULL rather than the empty string if there is no database selected.

  • Added --sql-mode=NO_AUTO_VALUE_ON_ZERO option to suppress the usual behavior of generating the next sequence number when zero is stored in an AUTO_INCREMENT column. With this mode enabled, zero is stored as zero; only storing NULL generates a sequence number.

  • Warning: Incompatible change! Client authentication now is based on 41-byte passwords in the user table, not 45-byte passwords as in 4.1.0. Any 45-byte passwords created for 4.1.0 must be reset after running the mysql_fix_privilege_tables script.

  • Added MySQL Server option and global variable 'secure-auth' that disallows authentication for accounts that have old (pre-4.1.1) passwords.

  • Added MySQL command line client option 'secure-auth'. If this option is set, client will refuse to send password in old (pre-4.1.1) format.

  • Warning: Incompatible change! Renamed the C API mysql_prepare_result() function to mysql_get_metadata() as the old name was confusing.

  • Added DROP USER 'username'@'hostname' statement to drop an account that has no privileges.

  • The interface to aggregated UDF functions has changed a bit. You must now declare a xxx_clear() function for each aggregate function XXX().

  • The CONCAT_WS() function no longer skips empty strings.

  • Added new ADDTIME(),
DATE(), DATEDIFF(),
LAST_DAY(),
MAKEDATE(),
MAKETIME(),
MICROSECOND(),
SUBTIME(), TIME(),
TIMEDIFF(),
TIMESTAMP(),
UTC_DATE(),
UTC_TIME(),
UTC_TIMESTAMP(), and
WEEKOFYEAR() functions.

  • Added new syntax for ADDDATE() and SUBDATE(). The second argument now may be a number representing the number of days to be added to or subtracted from the first date argument.

  • Added new type values DAY_MICROSECOND, HOUR_MICROSECOND, MINUTE_MICROSECOND, SECOND_MICROSECOND, and MICROSECOND for DATE_ADD(), DATE_SUB(), and EXTRACT().

  • Added new %f microseconds format specifier for DATE_FORMAT() and TIME_FORMAT().

  • All queries in which at least one SELECT does not use indexes properly now are written to the slow query log when long log format is used.

  • It is now possible to create a MERGE table from MyISAM tables in different databases. Formerly, all the MyISAM tables had to be in the same database, and the MERGE table had to be created in that database as well.

  • Added new COMPRESS(),
UNCOMPRESS(), and
UNCOMPRESSED_LENGTH() functions.

  • When doing SET sql_mode='mode' for a complex mode (like ANSI), we now update the sql_mode variable to include all the individual options implied by the complex mode.

  • Added the OLAP (On-Line Analytical Processing) function ROLLUP, which provides summary rows for each GROUP BY level.

  • Added SQLSTATE codes for all server errors.

  • Added mysql_sqlstate() and mysql_stmt_sqlstate() C API client functions that return the SQLSTATE error code for the last error.

  • TIME columns with hour values greater than 24 were returned incorrectly to the client.

  • ANALYZE, OPTIMIZE, REPAIR, and FLUSH statements are now stored in the binary log and thus replicated to slaves. This logging does not occur if the optional NO_WRITE_TO_BINLOG keyword (or its alias LOCAL) is given. Exceptions are that FLUSH LOGS, FLUSH MASTER, FLUSH SLAVE, and FLUSH TABLES WITH READ LOCK are not logged in any case. For a syntax example, see 항4.6.4. 「FLUSH 구문」.

  • New global variable RELAY_LOG_PURGE to enable or disable automatic relay log purging.

  • LOAD DATA now produces warnings that can be fetched with SHOW WARNINGS.

  • Added support for syntax CREATE TABLE table2 (LIKE table1) that creates an empty table table2 with a definition that is exactly the same as table1, including any indexes.

  • CREATE TABLE table_name (...) TYPE=storage_engine now generates a warning if the named storage engine is not available. The table is still created as a MyISAM table, as before.

  • Most subqueries are now much faster than before.

  • Added PURGE BINARY LOGS as an alias for PURGE MASTER LOGS.

  • Disabled the PURGE LOGS statement that was added in in version 4.1.0. The statement now should be issued as PURGE MASTER LOGS or PURGE BINARY LOGS.

  • Added SHOW BDB LOGS as an alias for SHOW LOGS.

  • Added SHOW MASTER LOGS (which had been deleted in version 4.1.0) as an alias for SHOW BINARY LOGS.

  • Added Slave_IO_State and Seconds_Behind_Master columns to the output of SHOW SLAVE STATUS. Slave_IO_State indicates the state of the slave I/O thread, and Seconds_Behind_Master indicates the number of seconds by which the slave is late compared to the master.

  • --lower-case-table-names=1 now also makes aliases case insensitive. (Bug #534)

Bugs fixed:

  • Fixed merging types and length of result set columns for UNION operations. The types and lengths now are determined taking into account values for all SELECT statements in the UNION, not just the first SELECT.

  • Fixed a bug in privilege handling that caused connections from certain IP addresses to be assigned incorrect database-level privileges. A connection could be assigned the database privileges of the previous successful authentication from one of those IP addresses, even if the IP address username and database name were different. (Bug #1636)

  • Error-handling functions were not called properly when an error resulted from [CREATE | REPLACE| INSERT] ... SELECT statements.

  • HASH, BTREE, RTREE, ERRORS, and WARNINGS no longer are reserved words. (Bug #724)

  • Fix for bug in ROLLUP when all tables were const tables. (Bug #714)

  • Fixed a bug in UNION that prohibited NULL values from being inserted into result set columns where the first SELECT of the UNION retrieved NOT NULL columns.

  • Fixed name resolution of columns of reduced subqueries in unions. (Bug #745)

  • Fixed memory overrun in subqueries in select list with WHERE clause bigger than outer query WHERE clause. (Bug #726)

  • Fixed a bug that caused MyISAM tables with FULLTEXT indexes created in 4.0.x to be unreadable in 4.1.x.

  • Fixed a data loss bug in REPAIR TABLE ... USE_FRM when used with tables that contained TIMESTAMP columns and were created in 4.0.x.

  • Fixed reduced subquery processing in ORDER BY/GROUP BY clauses. (Bug #442)

  • Fixed name resolution of outer columns of subquery in INSERT/REPLACE statements. (Bug #446)

  • Fixed bug in marking columns of reduced subqueries. (Bug #679)

  • Fixed a bug that made CREATE FULLTEXT INDEX syntax illegal.

  • Fixed a crash when a SELECT that required a temporary table (marked by Using temporary in EXPLAIN output) was used as a derived table in EXPLAIN command. (Bug #251)

  • Fixed a rare table corruption bug in DELETE from a big table with a new (created by MySQL-4.1) full-text index.

  • LAST_INSERT_ID() now returns 0 if the last INSERT statement didn't insert any rows.

  • Fixed missing last character in function output. (Bug #447)

  • Fixed a rare replication bug when a transaction spanned two or more relay logs, and the slave was stopped while executing the part of the transaction that was in the second or later relay log. Then replication would resume at the beginning of the second or later relay log, which was incorrect. (It should resume at BEGIN, in the first relay log.) (Bug #53)

  • CONNECTION_ID() now is properly replicated. (Bug #177)

  • The new PASSWORD() function in 4.1 is now properly replicated. (Bug #344)

  • Fixed a bug with double freed memory.

  • Fixed a crashing bug in UNION operations that involved temporary tables.

  • Fixed a crashing bug in DERIVED TABLES when EXPLAIN is used on a DERIVED TABLES with a join.

  • Fixed a crashing bug in DELETE with ORDER BY and LIMIT caused by an uninitialized array of reference pointers.

  • Fixed a bug in the USER() function caused by an error in the size of the allocated string.

  • Fixed a crashing bug when attempting to create a table containing a spatial (GIS) column with a storage engine that does not support spatial types.

  • Fixed a crashing bug in UNION caused by the empty select list and a non-existent column being used in some of the individual SELECT statements.

  • Fixed a replication bug with a 3.23 master and a 4.0 slave: The slave lost the replicated temporary tables if FLUSH LOGS was issued on the master. (Bug #254)

  • Fixed a security bug: A server compiled without SSL support still allowed connections by users that had the REQUIRE SSL option specified for their accounts.

  • When an undefined user variable was used in a updating query on the master (such as INSERT INTO t VALUES(@a), where @a had never been set by this connection before), the slave could replicate the query incorrectly if a previous transaction on the master used a user variable of the same name. (Bug #1331)

  • Fixed bug with prepared statements: Using the ? prepared statement parameter as the argument to certain functions or statement clauses caused a server crash when mysql_prepare() was invoked. (Bug #1500)

  • Fixed bug with prepared statements: after call to mysql_stmt_prepare placeholders became allowed in all consequent statements, even if they are not prepared (bug #1946)

D.2.3. Changes in release 4.1.0 (03 Apr 2003: Alpha)

Functionality added or changed:

  • New more secure client authentication based on 45-byte passwords in the user table.

  • New CRC32() function to compute cyclic redundancy check value.

  • On Windows, we are now using shared memory to communicate between server and client when they are running on the same machine and you are connecting to localhost.

  • REPAIR of MyISAM tables now uses less temporary disk space when sorting char columns.

  • DATE/DATETIME checking is now a bit stricter to support the ability to automatically distinguish between date, datetime, and time with microseconds. For example, dates of type YYYYMMDD HHMMDD are no longer supported; you must either have separators between each DATE/TIME part or not at all.

  • Server side help for all MySQL functions. One can now type help week in the mysql client and get help for the week() function.

  • Added new mysql_get_server_version() C API client function.

  • Fixed bug in libmysqlclient that fetched column defaults.

  • Fixed bug in mysql.cc client when skipping comments

  • Added record_in_range() method to MERGE tables to be able to choose the right index when there are many to choose from.

  • Replication now works with RAND() and user variables @var.

  • Allow one to change mode for ANSI_QUOTES on the fly.

  • EXPLAIN SELECT now can be killed. See 항4.6.7. 「KILL 구문」.

  • REPAIR TABLE now can be killed. See 항4.6.7. 「KILL 구문」.

  • Allow empty index lists to be specified for USE INDEX, IGNORE INDEX, and FORCE INDEX.

  • DROP TEMPORARY TABLE now drops only temporary tables and doesn't end transactions.

  • Added support for UNION in derived tables.

  • Warning: Incompatible change! TIMESTAMP is now returned as a string of type 'YYYY-MM-DD HH:MM:SS' and different timestamp lengths are not supported.

    This change was necessary for SQL standards compliance. In a future version, a further change will be made (backward compatible with this change), allowing the timestamp length to indicate the desired number of digits of fractions of a second.

  • New faster client/server protocol which supports prepared statements, bound parameters, and bound result columns, binary transfer of data, warnings.

  • Added database and real table name (in case of alias) to the MYSQL_FIELD structure.

  • Multi-line queries: You can now issue several queries at once and then read the results in one go.

  • In CREATE TABLE foo (a INT not null primary key) the PRIMARY word is now optional.

  • In CREATE TABLE the attribute SERIAL is now an alias for BIGINT NOT NULL AUTO_INCREMENT UNIQUE.

  • SELECT ... FROM DUAL is an alias for SELECT .... (To be compatible with some other databases).

  • If one creates a too long CHAR/VARCHAR it's now automatically changed to TEXT or BLOB; One will get a warning in this case.

  • One can specify the different BLOB/TEXT types with the syntax BLOB(length) and TEXT(length). MySQL will automatically change it to one of the internal BLOB/TEXT types.

  • CHAR BYTE is an alias for CHAR BINARY.

  • VARCHARACTER is an alias for VARCHAR.

  • New operators integer MOD integer and integer DIV integer.

  • SERIAL DEFAULT VALUE added as an alias for AUTO_INCREMENT.

  • TRUE and FALSE added as alias for 1 and 0, respectively.

  • Aliases are now forced in derived tables, as per SQL-99.

  • Fixed SELECT .. LIMIT 0 to return proper row count for SQL_CALC_FOUND_ROWS.

  • One can specify many temporary directories to be used in a round-robin fashion with: --tmpdir=dirname1:dirname2:dirname3.

  • Subqueries: SELECT * from t1 where t1.a=(SELECT t2.b FROM t2).

  • Derived tables:

    SELECT a.col1, b.col2
       FROM (SELECT MAX(col1) AS col1 FROM root_table) a,
       other_table b
       WHERE a.col1=b.col1;

  • Character sets to be defined per column, table and database.

  • Unicode (UTF8) support.

  • New CONVERT(... USING ...) syntax for converting string values between character sets.

  • BTREE index on HEAP tables.

  • Faster embedded server (new internal communication protocol).

  • One can add a comment per column in CREATE TABLE.

  • SHOW FULL COLUMNS FROM table_name shows column comments.

  • ALTER DATABASE.

  • Support for GIS (Geometrical data). See 장 10. MySQL 에 있어서의 공간 정보의 기능.

  • SHOW [COUNT(*)] WARNINGS shows warnings from the last command.

  • One can specify a column type for a colum in CREATE TABLE ... SELECT by defining the column in the CREATE part.

    CREATE TABLE foo (a tinyint not null) SELECT b+1 AS 'a' FROM bar;

  • expr SOUNDS LIKE expr same as SOUNDEX(expr)=SOUNDEX(expr).

  • Added new VARIANCE(expr) function returns the variance of expr

  • One can create a table from the existing table using CREATE [TEMPORARY] TABLE [IF NOT EXISTS] table (LIKE table). The table can be either normal or temporary.

  • New options --reconnect and --disable-reconnect for the mysql client, to reconnect automatically or not if the connection is lost.

  • START SLAVE (STOP SLAVE) no longer returns an error if the slave is already started (stopped); it returns a warning instead.

  • SLAVE START and SLAVE STOP are no longer accepted by the query parser; use START SLAVE and STOP SLAVE instead.


D.3. Changes in release 4.0.x (Production)

Version 4.0 of the MySQL server includes many enhancements and new features:

  • The InnoDB storage engine is now included in the standard binaries, adding transactions, row-level locking, and foreign keys. See 항7.5. 「InnoDB 테이블」.

  • A query cache, offering vastly increased performance for many applications. By caching complete result sets, later identical queries can return instantly. See 항6.9. 「MySQL 쿼리 캐쉬」.

  • Improved full-text indexing with boolean mode, truncation, and phrase searching. See 항6.8. 「MySQL 풀텍스트 검색」.

  • Enhanced MERGE tables, now supporting INSERT statements and AUTO_INCREMENT. See 항7.2. 「MERGE 테이블」.

  • UNION syntax in SELECT. See 항6.4.1.2. 「UNION 구문」.

  • Multiple-table DELETE statements. See 항6.4.5. 「DELETE 구문」.

  • libmysqld, the embedded server library. See 항11.1.15. 「편입 MySQL 서버 라이브러리 libmysqld 」.

  • Additional GRANT privilege options for even tighter control and security. See 항4.4.1. 「GRANT 및 REVOKE 의 구문」.

  • Management of user resources in the GRANT system, particularly useful for ISPs and other hosting providers. See 항4.4.7. 「유저 자원의 제한」.

  • Dynamic server variables, allowing configuration changes to be made without having to stop and restart the server. See 항5.5.6. 「SET 구문」.

  • Improved replication code and features. See 항4.11. 「MySQL 의 replication」.

  • Numerous new functions and options.

  • Changes to existing code for enhanced performance and reliability.

For a full list of changes, please refer to the changelog sections for each individual 4.0.x release.

D.3.1. Changes in release 4.0.17 (not released yet)

Functionality added or changed:

  • Added four new modes to WEEK(..., mode) function. See WEEK(date: (mode)). (Bug #1178)

  • Changed the default Windows service name for mysqld from MySql to MySQL. This should not affect usage, because service names are not case sensitive.

  • When you install mysqld as a service on Windows systems, mysqld will read startup options in option files from the option group with the same name as the service name. (Except when the service name is MySQL).

Bugs fixed:

  • Code cleanup: Fixed a few code defects (potential memory leaks, null pointer dereferences, uninitialized variables). Thanks to Reasoning Inc. for informing us about these findings.

  • Filesort was never shown in EXPLAIN if query contained an ORDER BY NULL clause. (Bug #1335)

  • Fixed invalidation of whole query cache on DROP DATABASE. (Bug #1898)

  • Fixed bug in range optimizer that caused wrong results for some unlikely AND/OR queries. (Bug #1828)

  • Fixed a crash in ORDER BY when ordering by expression and identifier. (Bug #1945)

  • Fixed a crash in an open HANDLER when an ALTER TABLE was executed in a different connection. (Bug #1826)

  • Fixed a bug in trunc* operator of full-text search which sometimes caused MySQL not to find all matched rows.

  • Fixed bug in zero prepending to DECIMAL column type.

  • Fixed optimizer bug, introduced in 4.0.16, when REF access plan was preferred to more efficient RANGE on another column.

  • Fixed problem when installing a MySQL server as a Windows service using a command of the form mysqld --install mysql --defaults-file=path-to-file.

  • Fixed an incorrect result from a query that uses only const tables (such as one-row tables) and non-constant expression (such as RAND()). (Bug #1271)

  • Fixed bug when the optimizer did not take SQL_CALC_FOUND_ROWS into account if LIMIT clause was present. (Bug #1274)

  • mysqlbinlog now asks for a password at the console when the -p or --password option is used with no argument. This is consistent with the way that other clients such mysqladmin and mysqldump already behave. Note: A consequence of this change is that it is no longer possible to invoke mysqlbinlog as mysqlbinlog -p pass_val (with a space between the -p option and the following password value). (Bug #1595)

  • Fixed bug accidentally introduced in 4.0.16 where the slave SQL thread deleted its replicated temporary tables when STOP SLAVE was issued.

  • In a ``chain'' replication setup A->B->C, if 2 sessions on A updated temporary tables of the same name at the same time, the binary log of B became incorrect, resulting in C becoming confused. (Bug #1686)

  • In a ``chain'' replication setup A->B->C, if STOP SLAVE was issued on B while it was replicating a temporary table from A, then when START SLAVE was issued on B, the binary log of B became incorrect, resulting in C becoming confused. (Bug #1240)

  • When MASTER_LOG_FILE and MASTER_LOG_POS were not specified, CHANGE MASTER used the coordinates of the slave I/O thread to set up replication, which broke replication if the slave SQL thread lagged behind the slave I/O thread. This caused the slave SQL thread to lose some events. The new behavior is to use the coordinates of the slave SQL thread instead. See 항4.11.8.1. 「CHANGE MASTER TO 」. (Bug #1870)

  • Now if integer is stored or converted to TIMESTAMP or DATETIME value checks of year, month, day, hour, minute and second ranges are performed and numbers representing illegal timestamps are converted to 0 value. This behavior is consistent with manual and with behavior of string to TIMESTAMP/DATETIME conversion. (Bug #1448)

  • Fixed bug when BIT_AND() and BIT_OR() group functions returned incorrect value if SELECT used a temporary table and no rows were found. (Bug #1790)

  • Fixed bug with BIT_AND() still returning signed value for an empty set in some cases. (Bug #1972)

  • Fixed bug with ^ (XOR) and >> (bit shift) still returning signed value in some cases. (Bug #1993)

  • Replication: a rare race condition in the slave SQL thread, which could lead to a wrong complain that the relay log is corrupted. (Bug #2011)

  • Replication: if an administrative command on a table (OPTIMIZE TABLE, REPAIR TABLE etc) was run on the slave, this could sometimes stop the slave SQL thread (this did not led to any corruption; one just had to type START SLAVE to get replication going again). (Bug #1858)

  • Replication: in the slave SQL thread, a multi-table UPDATE could produce a wrong complain that some record was not found in one table, if the UPDATE was preceded by a INSERT ... SELECT. (Bug #1701)

D.3.2. Changes in release 4.0.16 (17 Oct 2003)

Functionality added or changed:

  • Write memory allocation information to error log when doing mysqladmin debug. This works only on systems that support the mallinfo() call (like newer Linux systems).

  • Added the following new server variables to allow more precise memory allocation: range_alloc_block_size, query_alloc_block_size, query_prealloc_size, transaction_alloc_block_size, and transaction_prealloc_size.

  • mysqlbinlog now reads option files. To make this work one must now specify --read-from-remote-server when reading binary logs from a MySQL server. (Note that using a remote server is deprecated and may disappear in future mysqlbinlog versions).

  • Block SIGPIPE signals also for non-threaded programs. The blocking is moved from mysql_init() to mysql_server_init(), which is automatically called on the first call to mysql_init().

  • Added --libs_r and --include options to mysql_config.

  • New `> prompt for mysql. This prompt is similar to the '> and "> prompts, but indicates that an identifier quoted with backticks was begun on an earlier line and the closing backtick has not yet been seen.

  • Updated mysql_install_db to be able to use the local machine's IP address instead of the host name when building the initial grant tables if skip-name-resolve has been specified. This option can be helpful on FreeBSD to avoid thread-safety problems with the FreeBSD resolver libraries. (Thanks to Jeremy Zawodny for the patch.)

  • A documentation change: Added a note that when backing up a slave, it is necessary also to back up the master.info and relay-log.info files, as well as any SQL_LOAD-* files located in the directory specified by the --slave-load-tmpdir option. All these files are needed when the slave resumes replication after you restore the slave's data.

Bugs fixed:

  • Fixed a spurious error ERROR 14: Can't change size of file (Errcode: 2) on Windows in DELETE FROM table_name without a WHERE clause or TRUNCATE TABLE table_name, when table_name is a MyISAM table. (Bug #1397)

  • Fixed a bug that resulted in thr_alarm queue is full warnings after increasing the max_connections variable with SET GLOBAL. (Bug #1435)

  • Made LOCK TABLES to work when Lock_tables_priv is granted on the database level and Select_priv is granted on the table level.

  • Fixed crash of FLUSH QUERY CACHE on queries that use same table several times (Bug #988).

  • Fixed core dump bug when setting an enum system variable (such as SQL_WARNINGS) to NULL.

  • Extended the default timeout value for Windows clients from 30 seconds to 1 year. (The timeout that was added in MySQL 4.0.15 was way too short). This fixes a bug that caused ERROR 2013: Lost connection to MySQL server during query for queries that lasted longer than 30 seconds, if the client didn't specify a limit with mysql_options(). Users of 4.0.15 on Windows should upgrade to avoid this problem.

  • More ``out of memory'' checking in range optimizer.

  • Fixed and documented a problem when setting and using a user variable within the same SELECT statement. (Bug #1194).

  • Fixed bug in overrun check for BLOB values with compressed tables. This was a bug introduced in 4.0.14. It caused MySQL to regard some correct tables containing BLOB values as corrupted. (Bug #770, Bug #1304, and maybe Bug #1295)

  • SHOW GRANTS showed USAGE instead of the real column-level privileges when no table-level privileges were given.

  • When copying a database from the master, LOAD DATA FROM MASTER dropped the corresponding database on the slave, thus erroneously dropping tables that had no counterpart on the master and tables that may have been excluded from replication using replicate-*-table rules. Now LOAD DATA FROM MASTER no longer drops the database. Instead, it drops only the tables that have a counterpart on the master and that match the replicate-*-table rules. replicate-*-db rules can still be used to include or exclude a database as a whole from LOAD DATA FROM MASTER. A database will also be included or excluded as a whole if there are some rules like replicate-wild-do-table=db1.% or replicate-wild-ignore-table=db1.%, as is already the case for CREATE DATABASE and DROP DATABASE in replication. (Bug #1248)

  • Fixed a bug where mysqlbinlog crashed with a segmentation fault when used with the -h or --host option. (Bug #1258)

  • Fixed a bug where mysqlbinlog crashed with a segmentation fault when used on a binary log containing only final events for LOAD DATA. (Bug #1340)

  • Fixed compilation problem when compiling with OpenSSL 0.9.7 with disabled old DES support (If OPENSSL_DISABLE_OLD_DES_SUPPORT option was enabled).

  • Fixed a bug when two (or more) MySQL servers were running on the same machine, and they were both slaves, and at least one of them was replicating some LOAD DATA INFILE command from its master. The bug was that one slave MySQL server sometimes deleted the SQL_LOAD-* files (used for replication of LOAD DATA INFILE and located in the slave-load-tmpdir directory, which defaults to tmpdir) belonging to the other slave MySQL server of this machine, if these slaves had the same slave-load-tmpdir directory. When that happened, the other slave could not replicate LOAD DATA INFILE and complained about not being able to open some SQL_LOAD-* file. (Bug #1357)

  • If LOAD DATA INFILE failed for a small file, the master forgot to write a marker (a Delete_file event) in its binary log, so the slave could not delete 2 files (SQL_LOAD-*.info and SQL_LOAD-*.data from its tmpdir. (Bug #1391)

  • On Windows, the slave forgot to delete a SQL_LOAD-*.info file from tmpdir after successfully replicating a LOAD DATA INFILE command. (Bug #1392)

  • When a connection terminates, MySQL writes DROP TEMPORARY TABLE statements to the binary log for all temporary tables which the connection had not explicitely dropped. MySQL forgot to backquote the database and table names in the statement. (Bug #1345)

  • On some 64-bit machines (some HP-UX and Solaris machines), a slave installed with the 64-bit MySQL binary could not connect to its master (it connected to itself instead). (Bug #1256, Bug #1381)

  • Code was introduced in MySQL 4.0.15 for the slave to detect that the master had died while writing a transaction to its binary log. This code reported an error in a legal situation: When the slave I/O thread was stopped while copying a transaction to the relay log, the slave SQL thread would later pretend that it found an unfinished transaction. (Bug #1475)

D.3.3. Changes in release 4.0.15 (03 Sep 2003)

IMPORTANT:

If you are using this release on Windows, you should upgrade at least your clients (any program that uses libmysql.lib) to 4.0.16 or above. This is because the 4.0.15 release had a bug in the Windows client library that causes Windows clients using the library to die with a Lost connection to MySQL server during query error for queries that take more than 30 seconds. This problem is specific to Windows; clients on other platforms are unaffected.

Functionality added or changed:

  • mysqldump now correctly quotes all identifiers when communicating with the server. This assures that during the dump process, mysqldump will never send queries to the server that result in a syntax error. This problem is not related to the mysqldump program's output, which was not changed. (Bug #1148)

  • Change result set metadata information so that MIN() and MAX() report that they can return NULL (this is true because an empty set will return NULL). (Bug #324)

  • Produce an error message on Windows if a second mysqld server is started on the same TCP/IP port as an already running mysqld server.

  • The mysqld server variables wait_timeout, net_read_timeout, and net_write_timeout now work on Windows. One can now also set timeouts for read and writes in Windows clients with mysql_options().

  • Added option --sql-mode=NO_DIR_IN_CREATE to make it possible for slaves to ignore INDEX DIRECTORY and DATA DIRECTORY options given to CREATE TABLE. When this is mode is on, SHOW CREATE TABLE will not show the given directories.

  • SHOW CREATE TABLE now shows the INDEX DIRECTORY and DATA DIRECTORY options, if they were specified when the table was created.

  • The open_files_limit server variable now shows the real open files limit.

  • MATCH ... AGAINST() in natural language mode now treats words that are present in more than 2,000,000 rows as stopwords.

  • The Mac OS X installation disk images now include an additional MySQLStartupItem.pkg package that enables the automatic startup of MySQL on system bootup. See 항2.1.3. 「Mac OS X 에의 MySQL 의 인스톨」.

  • Most of the documentation included in the binary tarball distributions (.tar.gz) has been moved into a subdirectory docs. See 항2.2.5. 「인스톨 레이아웃」.

  • The manual is now included as an additional info file in the binary distributions. (Bug #1019)

  • The binary distributions now include the embedded server library (libmysqld.a) by default. Due to a linking problem with non-gcc compilers, it was not included in all packages of the initial 4.0.15 release. The affected packages were rebuilt and released as 4.0.15a. See 항1.5.1.2. 「편입 MySQL 서버」.

  • MySQL can now use range optimization for BETWEEN with non-constant limits. (Bug #991)

  • Replication error messages now include the default database, so that users can check which database the failing query was run for.

  • A documentation change: Added a paragraph about how the binlog-do-db and binlog-ignore-db options are tested against the database on the master (see 항4.10.4. 「바이너리 로그」), and a paragraph about how replicate-do-db, replicate-do-table and analogous options are tested against the database and tables on the slave (see 항4.11.6. 「replication 스타트 업 옵션」).

  • Now the slave does not replicate SET PASSWORD if it is configured to exclude the mysql database from replication (using for example replicate-wild-ignore-table=mysql.%). This was already the case for GRANT and REVOKE since version 4.0.13 (though there was Bug #980 in 4.0.13 & 4.0.14, which has been fixed in 4.0.15).

  • Rewrote the information shown in the State column of SHOW PROCESSLIST for replication threads and for MASTER_POS_WAIT() and added the most common states for these threads to the documentation, see 항4.11.3. 「replication의 실장의 상세」.

  • Added a test in replication to detect the case where the master died in the middle of writing a transaction to the binlog; such unfinished transactions now trigger an error message on the slave.

  • A GRANT command that creates an anonymous user (that is, an account with an empty username) no longer requires FLUSH PRIVILEGES for the account to be recognized by the server. (Bug #473)

  • CHANGE MASTER now flushes relay-log.info. Previously this was deferred to the next run of START SLAVE, so if mysqld was shutdown on the slave after CHANGE MASTER without having run START SLAVE, the relay log's name and position were lost. At restart they were reloaded from relay-log.info, thus reverting to their old (incorrect) values from before CHANGE MASTER and leading to error messages (as the old relay log did not exist any more) and the slave threads refusing to start. (Bug #858)

Bugs fixed:

  • Fixed buffer overflow in password handling which could potentially be exploited by MySQL users with ALTER privilege on the mysql.user table to execute random code or to gain shell access with the UID of the mysqld process (thanks to Jedi/Sector One for spotting and reporting this bug).

  • Fixed server crash on FORCE INDEX in a query that contained "Range checked for each record" in the EXPLAIN output. (Bug #1172)

  • Fixed table/column grant handling - proper sort order (from most specific to less specific, see 항4.3.10. 「액세스 제어의 단계 2: 요구 확인」) was not honored. (Bug #928)

  • Fixed rare bug in MYISAM introduced in 4.0.3 where the index file header was not updated directly after an UPDATE of split dynamic rows. The symptom was that the table had a corrupted delete-link if mysqld was shut down or the table was checked directly after the update.

  • Fixed Can't unlock file error when running myisamchk --sort-index on Windows. (Bug #1119)

  • Fixed possible deadlock when changing key_buffer_size while the key cache was actively used. (Bug #1088)

  • Fixed overflow bug in MyISAM and ISAM when a row is updated in a table with a large number of columns and at least one BLOB/TEXT column.

  • Fixed incorrect result when doing UNION and LIMIT #,# when one didn't use braces around the SELECT parts.

  • Fixed incorrect result when doing UNION and ORDER BY .. LIMIT # when one didn't use braces around the SELECT parts.

  • Fixed problem with SELECT SQL_CALC_FOUND_ROWS ... UNION ALL ... LIMIT # where FOUND_ROWS() returned incorrect number of rows.

  • Fixed unlikely stack bug when having a BIG expression of type 1+1-1+1-1... in certain combinations. (Bug #871)

  • Fixed the bug that sometimes prevented a table with a FULLTEXT index from being marked as "analyzed".

  • Fixed MySQL so that the column length (in C API) for the second column in SHOW CREATE TABLE is always larger than the data length. The only known application that was affected by the old behavior was Borland dbExpress, which truncated the output from the command. (Bug #1064)

  • Fixed crash in comparisons of strings using the tis620 character set. (Bug #1116)

  • Fixed ISAM bug in MAX() optimization.

  • myisamchk --sort-records=N no longer marks table as crashed if sorting failed because of an inappropriate key. (Bug #892)

  • Fixed a minor bug in MyISAM compressed table handling that sometimes made it impossible to repair compressed table in "Repair by sort" mode. "Repair with keycache" (myisamchk --safe-recover) worked, though. (Bug #1015)

  • Fixed bug in propagating the version number to the manual included in the distribution files. (Bug #1020)

  • Fixed key sorting problem (a PRIMARY key declared for a column that is not explicitly marked NOT NULL was sorted after a UNIQUE key for a NOT NULL column).

  • Fixed the result of INTERVAL when applied to a DATE value. (Bug #792)

  • Fixed compiling of the embedded server library in the RPM spec file. (Bug #959)

  • Added some missing files to the RPM spec file and fixed some RPM building errors that occured on Red Hat Linux 9. (Bug #998)

  • Fixed incorrect XOR evaluation in WHERE clause. (Bug #992)

  • Fixed bug with processing in query cache merged tables constructed from more then 255 tables. (Bug #930)

  • Fixed incorrect results from outer join query (e.g. LEFT JOIN) when ON condition is always false, and range search in used. (Bug #926)

  • Fixed a bug causing incorrect results from MATCH ... AGAINST() in some joins. (Bug #942)

  • MERGE tables do not ignore "Using index" (from EXPLAIN output) anymore.

  • Fixed a bug that prevented an empty table from being marked as "analyzed". (Bug #937)

  • Fixed myisamchk --sort-records crash when used on compressed table.

  • Fixed slow (as compared to 3.23) ALTER TABLE and related commands such as CREATE INDEX. (Bug #712)

  • Fixed segmentation fault resulting from LOAD DATA FROM MASTER when the master was running without the --log-bin option. (Bug #934)

  • Fixed a security bug: A server compiled without SSL support still allowed connections by users that had the REQUIRE SSL option specified for their accounts.

  • Fixed a random bug: Sometimes the slave would replicate GRANT or REVOKE queries even if it was configured to exclude the mysql database from replication (for example, using replicate-wild-ignore-table=mysql.%). (Bug #980)

  • The Last_Errno and Last_Error fields in the output of SHOW SLAVE STATUS are now cleared by CHANGE MASTER and when the slave SQL thread starts. (Bug #986)

  • A documentation mistake: It said that RESET SLAVE does not change connection information (master host, port, user, and password), whereas it does. The statement resets these to the startup options (master-host etc) if there were some. (Bug #985)

  • SHOW SLAVE STATUS now shows correct information (master host, port, user, and password) after RESET SLAVE (that is, it shows the new values, which are copied from the startup options if there were some). (Bug #985)

  • Disabled propagation of the original master's log position for events because this caused unexpected values for Exec_Master_Log_Pos and problems with MASTER_POS_WAIT() in A->B->C replication setup. (Bug #1086)

  • Fixed a segfault in mysqlbinlog when --position=x was used with x being between a Create_file event and its fellow Append_block, Exec_load or Delete_file events. (Bug #1091)

  • mysqlbinlog printed superfluous warnings when using --database, which caused syntax errors when piped to mysql. (Bug #1092)

  • Made mysqlbinlog --database filter LOAD DATA INFILE too (previously, it filtered all queries except LOAD DATA INFILE). (Bug #1093)

  • mysqlbinlog in some cases forgot to put a leading '#' in front of the original LOAD DATA INFILE (this command is displayed only for information, not to be run; it is later reworked to LOAD DATA LOCAL with a different filename, for execution by mysql). (Bug #1096)

  • binlog-do-db and binlog-ignore-db incorrectly filtered LOAD DATA INFILE (it was half-written to the binary log). This resulted in a corrupted binary log, which could cause the slave to stop with an error. (Bug #1100)

  • When, in a transaction, a transactional table (such as an InnoDB table) was updated, and later in the same transaction a non-transactional table (such as a MyISAM table) was updated using the updated content of the transactional table (with INSERT ... SELECT for example), the queries were written to the binary log in an incorrect order. (Bug #873)

  • When, in a transaction, INSERT ... SELECT updated a non-transactional table, and ROLLBACK was issued, no error was returned to the client. Now the client is warned that some changes could not be rolled back, as this was already the case for normal INSERT. (Bug #1113)

  • Fixed a potential bug: When STOP SLAVE was run while the slave SQL thread was in the middle of a transaction, and then CHANGE MASTER was used to point the slave to some non-transactional statement, the slave SQL thread could get confused (because it would still think, from the past, that it was in a transaction).

D.3.4. Changes in release 4.0.14 (18 Jul 2003)

Functionality added or changed:

  • InnoDB now supports indexing a prefix of a column. This means, in particular, that BLOB and TEXT columns can be indexed in InnoDB tables, which was not possible before.

  • A documentation change: Function INTERVAL(NULL, ...) returns -1.

  • Enabled INSERT from SELECT when the table into which the records are inserted is also a table listed in the SELECT.

  • Allow CREATE TABLE and INSERT from any UNION.

  • The SQL_CALC_FOUND_ROWS option now always returns the total number of rows for any UNION.

  • Removed --table option from mysqlbinlog to avoid repeating mysqldump functionality.

  • Comment lines in option files can now start from the middle of a line, too (like basedir=c:\mysql # installation directory).

  • Changed optimizer slightly to prefer index lookups over full table scans in some boundary cases.

  • Added thread-specific max_seeks_for_key variable that can be used to force the optimizer to use keys instead of table scans even if the cardinality of the index is low.

  • Added optimization that converts LEFT JOIN to normal join in some cases.

  • A documentation change: added a paragraph about failover in replication (how to use a surviving slave as the new master, how to resume to the original setup). See 항4.11.9. 「replication FAQ 」.

  • A documentation change: added warning notes about safe use of the CHANGE MASTER command. See 항4.11.8.1. 「CHANGE MASTER TO 」.

  • MySQL now issues a warning (not an error, as in 4.0.13) when it opens a table that was created with MySQL 4.1.

  • Added --nice option to mysqld_safe to allow setting the niceness of the mysqld process. (Thanks to Christian Hammers for providing the initial patch.) (Bug #627)

  • Added --read-only option to cause mysqld to allow no updates except from slave threads or from users with the SUPER privilege. (Original patch from Markus Benning).

  • SHOW BINLOG EVENTS FROM x where x is less than 4 now silently converts x to 4 instead of printing an error. The same change was done for CHANGE MASTER TO MASTER_LOG_POS=x and CHANGE MASTER TO RELAY_LOG_POS=x.

  • mysqld now only adds an interrupt handler for the SIGINT signal if you start it with the new --gdb option. This is because some MySQL users encountered strange problems when they accidentally sent SIGINT to mysqld threads.

  • RESET SLAVE now clears the Last_Errno and Last_Error fields in the output of SHOW SLAVE STATUS.

  • Added max_relay_log_size variable; the relay log will be rotated automatically when its size exceeds max_relay_log_size. But if max_relay_log_size is 0 (the default), max_binlog_size will be used (as in older versions). max_binlog_size still applies to binary logs in any case.

  • FLUSH LOGS now rotates relay logs in addition to the other types of logs it already rotated.

Bugs fixed:

  • Comparison/sorting for latin1_de character set was rewritten. The old algorithm could not handle cases like "sä" > "ßa". See 항4.7.1.1. 「독일어 캐릭터 세트」. In rare cases it resulted in table corruption.

  • Fixed a problem with the password prompt on Windows. (Bug #683)

  • ALTER TABLE ... UNION=(...) for MERGE table is now allowed even if some underlying MyISAM tables are read-only. (Bug #702)

  • Fixed a problem with CREATE TABLE t1 SELECT x'41'. (Bug #801)

  • Removed some incorrect lock warnings from the error log.

  • Fixed memory overrun when doing REPAIR on a table with a multi-part auto_increment key where one part was a packed CHAR.

  • Fixed a probable race condition in the replication code that could potentially lead to INSERT statements not being replicated in the event of a FLUSH LOGS command or when the binary log exceeds max_binlog_size. (Bug #791)

  • Fixed a crashing bug in INTERVAL and GROUP BY or DISTINCT. (Bug #807)

  • Fixed bug in mysqlhotcopy so it actually aborts for unsuccessful table copying operations. Fixed another bug so that it succeeds when there are thousands of tables to copy. (Bug #812)

  • Fixed problem with mysqlhotcopy failing to read options from option files. (Bug #808)

  • Fixed bugs in optimizer that sometimes prevented MySQL from using FULLTEXT indexes even though it was possible (for example, in SELECT * FROM t1 WHERE MATCH a,b AGAINST("index") > 0).

  • Fixed a bug with ``table is full'' in UNION operations.

  • Fixed a security problem that enabled users with no privileges to obtain information on the list of existing databases by using SHOW TABLES and similar commands.

  • Fixed a stack problem on UnixWare/OpenUnix.

  • Fixed a configuration problem on UnixWare/OpenUNIX and OpenServer.

  • Fixed a stack overflow problem in password verification.

  • Fixed a problem with max_user_connections.

  • HANDLER without an index now works properly when a table has deleted rows. (Bug #787)

  • Fixed a bug with LOAD DATA in mysqlbinlog. (Bug #670)

  • Fixed that SET CHARACTER SET DEFAULT works. (Bug #462)

  • Fixed MERGE table behavior in ORDER BY ... DESC queries. (Bug #515)

  • Fixed server crash on PURGE MASTER LOGS or SHOW MASTER LOGS when the binary log is off. (Bug #733)

  • Fixed password-checking problem on Windows. (Bug #464)

  • Fixed the bug in comparison of a DATETIME column and an integer constant. (Bug #504)

  • Fixed remote mode of mysqlbinlog. (Bug #672)

  • Fixed ERROR 1105: Unknown error that occurred for some SELECT queries, where a column that was declared as NOT NULL was compared with an expression that took NULL value.

  • Changed timeout in mysql_real_connect() to use poll() instead of select() to work around problem with many open files in the client.

  • Fixed incorrect results from MATCH ... AGAINST used with a LEFT JOIN query.

  • Fixed a bug that limited the maximum value for mysqld variables to 4294967295 when they are specified on the command line.

  • Fixed a bug that sometimes caused spurious ``Access denied'' errors in HANDLER ... READ statements, when a table is referenced via an alias.

  • Fixed portability problem with safe_malloc, which caused MySQL to give "Freeing wrong aligned pointer" errors on SCO 3.2.

  • ALTER TABLE ... ENABLE/DISABLE KEYS could cause a core dump when done after an INSERT DELAYED statement on the same table.

  • Fixed problem with conversion of localtime to GMT where some times resulted in different (but correct) timestamps. Now MySQL should use the smallest possible timestamp value in this case. (Bug #316)

  • Very small query cache sizes could crash mysqld. (Bug #549)

  • Fixed a bug (accidentally introduced by us but present only in version 4.0.13) that made INSERT ... SELECT into an AUTO_INCREMENT column not replicate well. This bug is in the master, not in the slave. (Bug #490)

  • Fixed a bug: When an INSERT ... SELECT statement inserted rows into a non-transactional table, but failed at some point (for example, due to a ``Duplicate key'' error), the query was not written to the binlog. Now it is written to the binlog, with its error code, as all other queries are. About the slave-skip-errors option for how to handle partially completed queries in the slave, see 항4.11.6. 「replication 스타트 업 옵션」. (Bug #491)

  • SET FOREIGN_KEY_CHECKS=0 was not replicated properly. The fix probably will not be backported to 3.23.

  • On a slave, LOAD DATA INFILE which had no IGNORE or REPLACE clause on the master, was replicated with IGNORE. While this is not a problem if the master and slave data are identical (a LOAD that produces no duplicate conflicts on the master will produce none on the slave anyway), which is true in normal operation, it is better for debugging not to silently add the IGNORE. That way, you can get an error message on the slave and discover that for some reason, the data on master and slave are different and investigate why. (Bug #571)

  • On a slave, LOAD DATA INFILE printed an incomplete ``Duplicate entry '%-.64s' for key %d''' message (the key name and value were not mentioned) in case of duplicate conflict (which does not happen in normal operation). (Bug #573)

  • When using a slave compiled with --debug, CHANGE MASTER TO RELAY_LOG_POS could cause a debug assertion failure. (Bug #576)

  • When doing a LOCK TABLES WRITE on an InnoDB table, commit could not happen, if the query was not written to the binary log (for example, if --log-bin was not used, or binlog-ignore-db was used). (Bug #578)

  • If a 3.23 master had open temporary tables that had been replicated to a 4.0 slave, and the binlog got rotated, these temporary tables were immediately dropped by the slave (which caused problems if the master used them subsequently). This bug had been fixed in 4.0.13, but in a manner which caused an unlikely inconvenience: if the 3.23 master died brutally (power failure), without having enough time to automatically write DROP TABLE statements to its binlog, then the 4.0.13 slave would not notice the temporary tables have to be dropped, until the slave mysqld server is restarted. This minor inconvenience is fixed in 3.23.57 and 4.0.14 (meaning the master must be upgraded to 3.23.57 and the slave to 4.0.14 to remove the inconvenience). (Bug #254)

  • If MASTER_POS_WAIT() was waiting, and the slave was idle, and the slave SQL thread terminated, MASTER_POS_WAIT() would wait forever. Now when the slave SQL thread terminates, MASTER_POS_WAIT() immediately returns NULL (``slave stopped''). (Bug #651)

  • After RESET SLAVE; START SLAVE;, the Relay_Log_Space value displayed by SHOW SLAVE STATUS was too big by four bytes. (Bug #763)

  • If a query was ignored on the slave (because of replicate-ignore-table and other similar rules), the slave still checked if the query got the same error code (0, no error) as on the master. So if the master had an error on the query (for example, ``Duplicate entry'' in a multiple-row insert), then the slave stopped and warned that the error codes didn't match. (Bug #797)

D.3.5. Changes in release 4.0.13 (16 May 2003)

Functionality added or changed:

  • PRIMARY KEY now implies NOT NULL. (Bug #390)

  • The Windows binary packages are now compiled with --enable-local-infile to match the Unix build configuration.

  • Removed timing of tests from mysql-test-run. time does not accept all required parameters on many platforms (for example, QNX) and timing the tests is not really required (it's not a benchmark anyway).

  • SHOW MASTER STATUS and SHOW SLAVE STATUS required the SUPER privilege; now they accept REPLICATION CLIENT as well. (Bug #343)

  • Added multi-threaded MyISAM repair optimization and myisam_repair_threads variable to enable it. See 항4.6.8.4. 「SHOW VARIABLES 」.

  • Added innodb_max_dirty_pages_pct variable which controls amount of dirty pages allowed in InnoDB buffer pool.

  • CURRENT_USER() and Access denied error messages now report the hostname exactly as it was specified in the GRANT command.

  • Removed benchmark results from the source and binary distributions. They are still available in the BK source tree, though.

  • InnoDB tables now support ANALYZE TABLE.

  • MySQL now issues an error when it opens a table that was created with MySQL 4.1.

  • Option --new now changes binary items (0xFFDF) to be treated as binary strings instead of numbers by default. This fixes some problems with character sets where it's convenient to input the string as a binary item. After this change you have to convert the binary string to INTEGER with a CAST if you want to compare two binary items with each other and know which one is bigger than the other. SELECT CAST(0xfeff AS UNSIGNED) < CAST(0xff AS UNSIGNED). This will be the default behavior in MySQL 4.1. (Bug #152)

  • Enabled delayed_insert_timeout on Linux (most modern glibc libraries have a fixed pthread_cond_timedwait). (Bug #211)

  • Don't create more insert delayed threads than given by max_insert_delayed_threads. (Bug #211)

  • Changed UPDATE ... LIMIT to apply the limit to rows that were matched, whether or not they actually were changed. Previously the limit was applied as a restriction on the number of rows changed.

  • Tuned optimizer to favor clustered index over table scan.

  • BIT_AND() and BIT_OR() now return an unsigned 64-bit value.

  • Added warnings to error log of why a secure connection failed (when running with --log-warnings).

  • Deprecated options --skip-symlink and --use-symbolic-links and replaced these with --symbolic-links.

  • The default option for innodb_flush_log_at_trx_commit was changed from 0 to 1 to make InnoDB tables ACID by default. See 항7.5.3. 「InnoDB 기동 옵션」.

  • Added a feature to SHOW KEYS to display keys that are disabled by ALTER TABLE DISABLE KEYS command.

  • When using a non-existing table type with CREATE TABLE, first try if the default table type exists before falling back to MyISAM.

  • Added MEMORY as an alias for HEAP.

  • Renamed function rnd to my_rnd as the name was too generic and is an exported symbol in libmysqlclient (thanks to Dennis Haney for the initial patch).

  • Portability fix: renamed include/dbug.h to include/my_debug.h.

  • mysqldump no longer silently deletes the binlogs when called with --master-data or --first-slave; while this behavior was convenient for some users, others may suffer from it. Now one has to explicitely ask for this deletion with the new --delete-master-logs option.

  • If the slave is configured (using for example replicate-wild-ignore-table=mysql.%) to exclude mysql.user, mysql.host, mysql.db, mysql.tables_priv and mysql.columns_priv from replication, then GRANT and REVOKE will not be replicated.

Bugs fixed:

  • Logged Access denied error message had incorrect Using password value. (Bug #398)

  • Fixed bug with NATURAL LEFT JOIN, NATURAL RIGHT JOIN and RIGHT JOIN when using many joined tables. The problem was that the JOIN method was not always associated with the tables surrounding the JOIN method. If you have a query that uses many RIGHT JOIN or NATURAL ... JOINS you should check that they work as you expected after upgrading MySQL to this version. (Bug #291)

  • mysql command line client no longer looks for \* commands inside backtick-quoted strings.

  • Fixed Unknown error when using UPDATE ... LIMIT. (Bug #373)

  • Fixed problem with ANSI mode and GROUP BY with constants. (Bug #387)

  • Fixed bug with UNION and OUTER JOIN. (Bug #386)

  • Fixed bug if one used a multiple-table UPDATE and the query required a temporary table bigger than tmp_table_size. (Bug #286)

  • Run mysql_install_db with the -IN-RPM option for the Mac OS X installation to not fail on systems with improperly configured hostname configurations.

  • LOAD DATA INFILE will now read 000000 as a zero date instead as "2000-00-00".

  • Fixed bug that caused DELETE FROM table WHERE const_expression always to delete the whole table (even if expression result was false). (Bug #355)

  • Fixed core dump bug when using FORMAT('nan',#). (Bug #284)

  • Fixed name resolution bug with HAVING ... COUNT(DISTINCT ...).

  • Fixed incorrect result from truncation operator (*) in MATCH ... AGAINST() in some complex joins.

  • Fixed a crash in REPAIR ... USE_FRM command, when used on read-only, nonexisting table or a table with a crashed index file.

  • Fixed a crashing bug in mysql monitor program. It occurred if program was started with --no-defaults, with a prompt that contained hostname and connection to non-existing db was requested

  • Fixed problem when comparing a key for a multi-byte-character set. (Bug #152)

  • Fixed bug in LEFT, RIGHT and MID when used with multi-byte character sets and some GROUP BY queries. (Bug #314)

  • Fix problem with ORDER BY being discarded for some DISTINCT queries. (Bug #275)

  • Fixed that SET SQL_BIG_SELECTS=1 works as documented (This corrects a new bug introduced in 4.0)

  • Fixed some serious bugs in UPDATE ... ORDER BY. (Bug #241)

  • Fixed unlikely problem in optimizing WHERE clause with constant expression like in WHERE 1 AND (a=1 AND b=1).

  • Fixed that SET SQL_BIG_SELECTS=1 works again.

  • Introduced proper backtick quoting for db.table in SHOW GRANTS.

  • FULLTEXT index stopped working after ALTER TABLE that converts TEXT column to CHAR. (Bug #283)

  • Fixed a security problem with SELECT and wildcarded select list, when user only had partial column SELECT privileges on the table.

  • Mark a MyISAM table as "analyzed" only when all the keys are indeed analyzed.

  • Only ignore world-writeable my.cnf files that are regular files (and not, for example, named pipes or character devices).

  • Fixed few smaller issues with SET PASSWORD.

  • Fixed error message which contained deprecated text.

  • Fixed a bug with two NATURAL JOINs in the query.

  • SUM() didn't return NULL when there was no rows in result or when all values was NULL.

  • On Unix symbolic links handling was not enabled by default and there was no way to turn this on.

  • Added missing dashes to parameter --open-files-limit in mysqld_safe. (Bug #264)

  • Fixed incorrect hostname for TCP/IP connections displayed in SHOW PROCESSLIST.

  • Fixed a bug with NAN in FORMAT(...) function ...

  • Fixed a bug with improperly cached database privileges.

  • Fixed a bug in ALTER TABLE ENABLE / DISABLE KEYS which failed to force a refresh of table data in the cache.

  • Fixed bugs in replication of LOAD DATA INFILE for custom parameters (ENCLOSED, TERMINATED and so on) and temporary tables. (Bug #183, Bug #222)

  • Fixed a replication bug when the master is 3.23 and the slave 4.0: the slave lost the replicated temporary tables if FLUSH LOGS was issued on the master. (Bug #254)

  • Fixed a bug when doing LOAD DATA INFILE IGNORE: When reading the binary log, mysqlbinlog and the replication code read REPLACE instead of IGNORE. This could make the slave's table become different from the master's table. (Bug #218)

  • Fixed a deadlock when relay_log_space_limit was set to a too small value. (Bug #79)

  • Fixed a bug in HAVING clause when an alias is used from the select list.

  • Fixed overflow bug in MyISAM when a row is inserted into a table with a large number of columns and at least one BLOB/TEXT column. Bug was caused by incorrect calculation of the needed buffer to pack data.

  • Fixed a bug when SELECT @nonexistent_variable caused the error in client - server protocol due to net_printf() being sent to the client twice.

  • Fixed a bug in setting SQL_BIG_SELECTS option.

  • Fixed a bug in SHOW PROCESSLIST which only displayed a localhost in the "Host" column. This was caused by a glitch that only used current thread information instead of information from the linked list of threads.

  • Removed unnecessary Mac OS X helper files from server RPM. (Bug #144)

  • Allow optimization of multiple-table update for InnoDB tables as well.

  • Fixed a bug in multiple-table updates that caused some rows to be updated several times.

  • Fixed a bug in mysqldump when it was called with --master-data: the CHANGE MASTER TO commands appended to the SQL dump had incorrect coordinates. (Bug #159)

  • Fixed a bug when an updating query using USER() was replicated on the slave; this caused segfault on the slave. (Bug #178). USER() is still badly replicated on the slave (it is replicated to "").

D.3.6. Changes in release 4.0.12 (15 Mar 2003: Production)

Functionality added or changed:

  • mysqld no longer reads options from world-writeable config files.

  • Integer values between 9223372036854775807 and 9999999999999999999 are now regarded as unsigned longlongs, not as floats. This makes these values work similar to values between 10000000000000000000 and 18446744073709551615.

  • SHOW PROCESSLIST will now include the client TCP port after the hostname to make it easier to know from which client the request originated.

Bugs fixed:

  • Fixed mysqld crash on extremely small values of sort_buffer variable.

  • INSERT INTO u SELECT ... FROM t was written too late to the binary log if t was very frequently updated during the execution of this query. This could cause a problem with mysqlbinlog or replication. The master must be upgraded, not the slave. (Bug #136)

  • Fixed checking of random part of WHERE clause. (Bug #142)

  • Fixed a bug with multiple-table updates with InnoDB tables. This bug occurred as, in many cases, InnoDB tables cannot be updated ``on the fly,'' but offsets to the records have to be stored in a temporary table.

  • Added missing file mysql_secure_installation to the server RPM subpackage. (Bug #141)

  • Fixed MySQL (and myisamchk) crash on artificially corrupted .MYI files.

  • Don't allow BACKUP TABLE to overwrite existing files.

  • Fixed a bug with multiple-table UPDATE statements when user had all privileges on the database where tables are located and there were any entries in tables_priv table, that is, grant_option was true.

  • Fixed a bug that allowed a user with table or column grants on some table, TRUNCATE any table in the same database.

  • Fixed deadlock when doing LOCK TABLE followed by DROP TABLE in the same thread. In this case one could still kill the thread with KILL.

  • LOAD DATA LOCAL INFILE was not properly written to the binary log (hence not properly replicated). (Bug #82)

  • RAND() entries were not read correctly by mysqlbinlog from the binary log which caused problems when restoring a table that was inserted with RAND(). INSERT INTO t1 VALUES(RAND()). In replication this worked ok.

  • SET SQL_LOG_BIN=0 was ignored for INSERT DELAYED queries. (Bug #104)

  • SHOW SLAVE STATUS reported too old positions (columns Relay_Master_Log_File and Exec_Master_Log_Pos) for the last executed statement from the master, if this statement was the COMMIT of a transaction. The master must be upgraded for that, not the slave. (Bug #52)

  • LOAD DATA INFILE was not replicated by the slave if replicate_*_table was set on the slave. (Bug #86)

  • After RESET SLAVE, the coordinates displayed by SHOW SLAVE STATUS looked un-reset (though they were, but only internally). (Bug #70)

  • Fixed query cache invalidation on LOAD DATA.

  • Fixed memory leak on ANALYZE procedure with error.

  • Fixed a bug in handling CHAR(0) columns that could cause incorrect results from the query.

  • Fixed rare bug with incorrect initialization of AUTO_INCREMENT column, as a secondary column in a multi-column key (see 항3.6.9. 「AUTO_INCREMENT 의 사용」), when data was inserted with INSERT ... SELECT or LOAD DATA into an empty table.

  • On Windows, STOP SLAVE didn't stop the slave until the slave got one new command from the master (this bug has been fixed for MySQL 4.0.11 by releasing updated 4.0.11a Windows packages, which include this individual fix on top of the 4.0.11 sources). (Bug #69)

  • Fixed a crash when no database was selected and LOAD DATA command was issued with full table name specified, including database prefix.

  • Fixed a crash when shutting down replication on some platforms (for example, Mac OS X).

  • Fixed a portability bug with pthread_attr_getstacksize on HP-UX 10.20 (Patch was also included in 4.0.11a sources).

  • Fixed the bigint test to not fail on some platforms (for example, HP-UX and Tru64) due to different return values of the atof() function.

  • Fixed the rpl_rotate_logs test to not fail on certain platforms (e.g. Mac OS X) due to a too long file name (changed slave-master-info.opt to .slave-mi).

D.3.7. Changes in release 4.0.11 (20 Feb 2003)

Functionality added or changed:

  • NULL is now sorted LAST if you use ORDER BY ... DESC (as it was before MySQL 4.0.2). This change was required to comply with the SQL-99 standard. (The original change was made because we thought that SQL-99 required NULL to be always sorted at the same position, but this was incorrect).

  • Added START TRANSACTION (SQL-99 syntax) as alias for BEGIN. This is recommended to use instead of BEGIN to start a transaction.

  • Added OLD_PASSWORD() as a synonym for PASSWORD().

  • Allow keyword ALL in group functions.

  • Added support for some new INNER JOIN and JOIN syntaxes. For example, SELECT * FROM t1 INNER JOIN t2 didn't work before.

  • Novell NetWare 6.0 porting effort completed, Novell patches merged into the main source tree.

Bugs fixed:

  • Fixed problem with multiple-table delete and InnoDB tables.

  • Fixed a problem with BLOB NOT NULL columns used with IS NULL.

  • Re-added missing pre- and post(un)install scripts to the Linux RPM packages (they were missing after the renaming of the server subpackage).

  • Fixed that table locks are not released with multiple-table updates and deletes with InnoDB storage engine.

  • Fixed bug in updating BLOB columns with long strings.

  • Fixed integer-wraparound when giving big integer (>= 10 digits) to function that requires an unsigned argument, like CREATE TABLE (...) AUTO_INCREMENT=#.

  • MIN(key_column) could in some cases return NULL on a column with NULL and other values.

  • MIN(key_column) and MAX(key_column) could in some cases return incorrect values when used in OUTER JOIN.

  • MIN(key_column) and MAX(key_column) could return incorrect values if one of the tables was empty.

  • Fixed rare crash in compressed MyISAM tables with blobs.

  • Fixed bug in using aggregate functions as argument for INTERVAL, CASE, FIELD, CONCAT_WS, ELT and MAKE_SET functions.

  • When running with --lower-case-table-names (default on Windows) and you had tables or databases with mixed case on disk, then executing SHOW TABLE STATUS followed with DROP DATABASE or DROP TABLE could fail with Errcode 13.

D.3.8. Changes in release 4.0.10 (29 Jan 2003)

Functionality added or changed:

  • Added option --log-error[=file_name] to mysqld_safe and mysqld. This option will force all error messages to be put in a log file if the option --console is not given. On Windows --log-error is enabled as default, with a default name of host_name.err if the name is not specified.

  • Changed some things from Warning: to Note: in the log files.

  • The mysqld server should now compile on NetWare.

  • Added optimization that if one does GROUP BY ... ORDER BY NULL then result is not sorted.

  • New --ft-stopword-file command-line option for mysqld to replace/disable the built-in stopword list that is used in full-text searches. See 항4.6.8.4. 「SHOW VARIABLES 」.

  • Changed default stack size from 64K to 192K; This fixes a core dump problem on Red Hat 8.0 and other systems with a glibc that requires a stack size larger than 128K for gethostbyaddr() to resolve a hostname. You can fix this for earlier MySQL versions by starting mysqld with --thread-stack=192K.

  • Added mysql_waitpid to the binary distribution and the MySQL-client RPM subpackage (required for mysql-test-run).

  • Renamed the main MySQL RPM package to MySQL-server. When updating from an older version, MySQL-server.rpm will simply replace MySQL.rpm.

  • If a slave is configured with replicate_wild_do_table=db.% or replicate_wild_ignore_table=db.%, these rules will be applied to CREATE/DROP DATABASE, too.

  • Added timeout value for MASTER_POS_WAIT().

Bugs fixed:

  • Fixed initialization of the random seed for newly created threads to give a better rand() distribution from the first call.

  • Fixed a bug that caused mysqld to hang when a table was opened with the HANDLER command and then dropped without being closed.

  • Fixed bug in logging to binary log (which affects replication) a query that inserts a NULL in an AUTO_INCREMENT column and also uses LAST_INSERT_ID().

  • Fixed an unlikely bug that could cause a memory overrun when using ORDER BY constant_expression.

  • Fixed a table corruption in myisamchk's parallel repair mode.

  • Fixed bug in query cache invalidation on simple table renaming.

  • Fixed bug in mysqladmin --relative.

  • On some 64-bit systems, show status reported a strange number for Open_files and Open_streams.

  • Fixed incorrect number of columns in EXPLAIN on empty table.

  • Fixed bug in LEFT JOIN that caused zero rows to be returned in the case the WHERE condition was evaluated as FALSE after reading const tables. (Unlikely condition).

  • FLUSH PRIVILEGES didn't correctly flush table/column privileges when mysql.tables_priv is empty.

  • Fixed bug in replication when using LOAD DATA INFILE one a file that updated an AUTO_INCREMENT column with NULL or 0. This bug only affected MySQL 4.0 masters (not slaves or MySQL 3.23 masters). Note: If you have a slave that has replicated a file with generated AUTO_INCREMENT columns then the slave data is corrupted and you should reinitialize the affected tables from the master.

  • Fixed possible memory overrun when sending a BLOB value larger than 16M to the client.

  • Fixed incorrect error message when setting a NOT NULL column to an expression that returned NULL.

  • Fixed core dump bug in str LIKE "%other_str%" where str or other_str contained characters >= 128.

  • Fixed bug: When executing on master LOAD DATA and InnoDB failed with table full error the binary log was corrupted.

D.3.9. Changes in release 4.0.9 (09 Jan 2003)

Functionality added or changed:

  • OPTIMIZE TABLE will for MyISAM tables treat all NULL values as different when calculating cardinality. This helps in optimizing joins between tables where one of the tables has a lot of NULL values in a indexed column:

    SELECT * from t1,t2 where t1.a=t2.key_with_a_lot_of_null;

  • Added join operator FORCE INDEX (key_list). This acts likes USE INDEX (key_list) but with the addition that a table scan is assumed to be VERY expensive. One bad thing with this is that it makes FORCE a reserved word.

  • Reset internal row buffer in MyISAM after each query. This will reduce memory in the case you have a lot of big blobs in a table.

Bugs fixed:

  • A security patch in 4.0.8 causes the mysqld server to die if the remote hostname can't be resolved. This is now fixed.

  • Fixed crash when replication big LOAD DATA INFILE statement that caused log rotation.

D.3.10. Changes in release 4.0.8 (07 Jan 2003)

Functionality added or changed:

  • Default max_packet_length for libmysqld.c is now 1024*1024*1024.

  • One can now specify max_allowed_packet in a file ready by mysql_options(MYSQL_READ_DEFAULT_FILE). for clients.

  • When sending a too big packet to the server with the not compressed protocol, the client now gets an error message instead of a lost connection.

  • We now send big queries/result rows in bigger hunks, which should give a small speed improvement.

  • Fixed some bugs with the compressed protocol for rows > 16M.

  • InnoDB tables now also support ON UPDATE CASCADE in FOREIGN KEY constraints. See the InnoDB section in the manual for the InnoDB changelog.

Bugs fixed:

  • Fixed bug in ALTER TABLE with BDB tables.

  • Fixed core dump bug in QUOTE() function.

  • Fixed a bug in handling communication packets bigger than 16M. Unfortunately this required a protocol change; If you upgrade the server to 4.0.8 and above and have clients that uses packets >= 255*255*255 bytes (=16581375) you must also upgrade your clients to at least 4.0.8. If you don't upgrade, the clients will hang when sending a big packet.

  • Fixed bug when sending blobs longer than 16M to client.

  • Fixed bug in GROUP BY when used on BLOB column with NULL values.

  • Fixed a bug in handling NULL values in CASE ... WHEN ...

D.3.11. Changes in release 4.0.7 (20 Dec 2002)

Functionality added or changed:

  • mysqlbug now also reports the compiler version used for building the binaries (if the compiler supports the option --version).

Bugs fixed:

  • Fixed compilation problems on OpenUnix and HPUX 10.20.

  • Fixed some optimization problems when compiling MySQL with -DBIG_TABLES on a 32-bit system.

  • mysql_drop_db() didn't check permissions properly so anyone could drop another users database. DROP DATABASE is checked properly.

D.3.12. Changes in release 4.0.6 (14 Dec 2002: Gamma)

Functionality added or changed:

  • Added syntax support for CHARACTER SET xxx and CHARSET=xxx table options (to be able to read table dumps from 4.1).

  • Fixed replication bug that caused the slave to loose its position in some cases when the replication log was rotated.

  • Fixed that a slave will restart from the start of a transaction if it's killed in the middle of one.

  • Moved the manual pages from man to man/man1 in the binary distributions.

  • The default type returned by IFNULL(A,B) is now set to be the more 'general' of the types of A and B. (The order is STRING, REAL or INTEGER).

  • Moved the mysql.server startup script in the RPM packages from /etc/rc.d/init.d/mysql to /etc/init.d/mysql (which almost all current Linux distributions support for LSB compliance).

  • Added Qcache_lowmem_prunes status variable (number of queries that were deleted from cache because of low memory).

  • Fixed mysqlcheck so it can deal with table names containing dashes.

  • Bulk insert optimization (see 항4.6.8.4. 「SHOW VARIABLES 」) is no longer used when inserting small (less than 100) number of rows.

  • Optimization added for queries like SELECT ... FROM merge_table WHERE indexed_column=constant_expr.

  • Added functions LOCALTIME and LOCALTIMESTAMP as synonyms for NOW().

  • CEIL is now an alias for CEILING.

  • The CURRENT_USER() function can be used to get a user@host value as it was matched in the GRANT system. See 항6.3.6.2. 「그 외의 각종 함수」.

  • Fixed CHECK constraints to be compatible with SQL-99. This made CHECK a reserved word. (Checking of CHECK constraints is still not implemented).

  • Added CAST(... as CHAR).

  • Added PostgreSQL compatible LIMIT syntax: SELECT ... LIMIT row_count OFFSET offset

  • mysql_change_user() will now reset the connection to the state of a fresh connect (Ie, ROLLBACK any active transaction, close all temporary tables, reset all user variables etc..)

  • CHANGE MASTER and RESET SLAVE now require that slave threads be both already stopped; these commands will return an error if at least one of these two threads is running.

Bugs fixed:

  • Fixed number of found rows returned in multi table updates

  • Make --lower-case-table-names default on Mac OS X as the default file system (HFS+) is case insensitive. See 항6.1.3. 「이름에 있어서의 케이스 의존」.

  • Transactions in AUTOCOMMIT=0 mode didn't rotate binary log.

  • A fix for the bug in a SELECT with joined tables with ORDER BY and LIMIT clause when filesort had to be used. In that case LIMIT was applied to filesort of one of the tables, although it could not be. This fix also solved problems with LEFT JOIN.

  • mysql_server_init() now makes a copy of all arguments. This fixes a problem when using the embedded server in C# program.

  • Fixed buffer overrun in libmysqlclient library that allowed a malicious MySQL server to crash the client application.

  • Fixed security-related bug in mysql_change_user() handling. All users are strongly recommended to upgrade to version 4.0.6.

  • Fixed bug that prevented --chroot command-line option of mysqld from working.

  • Fixed bug in phrase operator "..." in boolean full-text search.

  • Fixed bug that caused OPTIMIZE TABLE to corrupt the table under some rare circumstances.

  • Part rewrite of multiple-table-update to optimize it, make it safer and more bug free.

  • LOCK TABLES now works together with multiple-table-update and multiple-table-delete.

  • --replicate-do=xxx didn't work for UPDATE commands. (Bug introduced in 4.0.0)

  • Fixed shutdown problem on Mac OS X.

  • Major InnoDB bugs in REPLACE, AUTO_INCREMENT, INSERT INTO ... SELECT ... were fixed. See the InnoDB changelog in the InnoDB section of the manual.

  • RESET SLAVE caused a crash if the slave threads were running.

D.3.13. Changes in release 4.0.5 (13 Nov 2002)

Functionality added or changed:

  • Port number was added to host name (if it is known) in SHOW PROCESSLIST command

  • Changed handling of last argument in WEEK() so that one can get week number according to the ISO 8601 specification. (Old code should still work).

  • Fixed that INSERT DELAYED threads doesn't hang on Waiting for INSERT when one sends a SIGHUP to mysqld.

  • Change that AND works according to SQL-99 when it comes to NULL handling. In practice, this only affects queries where you do something like WHERE ... NOT (NULL AND 0).

  • mysqld will now resolve basedir to its full path (with realpath()). This enables one to use relative symlinks to the MySQL installation directory. This will however cause show variables to report different directories on systems where there is a symbolic link in the path.

  • Fixed that MySQL will not use index scan on index disabled with IGNORE INDEX or USE INDEX. to be ignored.

  • Added --use-frm option to mysqlcheck. When used with REPAIR, it gets the table structure from the .frm file, so the table can be repaired even if the .MYI header is corrupted.

  • Fixed bug in MAX() optimization when used with JOIN and ON expressions.

  • Added support for reading of MySQL 4.1 table definition files.

  • BETWEEN behavior changed (see 항6.3.1.2. 「비교 연산자」). Now datetime_col BETWEEN timestamp AND timestamp should work as expected.

  • One can create TEMPORARY MERGE tables now.

  • DELETE FROM myisam_table now shrinks not only the .MYD file but also the .MYI file.

  • When one uses the --open-files-limit=# option to mysqld_safe it's now passed on to mysqld.

  • Changed output from EXPLAIN from 'where used' to 'Using where' to make it more in line with other output.

  • Removed variable safe_show_database as it was no longer used.

  • Updated source tree to be built using automake 1.5 and libtool 1.4.

  • Fixed an inadvertently changed option (--ignore-space) back to the original --ignore-spaces in mysqlclient. (Both syntaxes will work).

  • Don't require UPDATE privilege when using REPLACE.

  • Added support for DROP TEMPORARY TABLE ..., to be used to make replication safer.

  • When transactions are enabled, all commands that update temporary tables inside a BEGIN/COMMIT are now stored in the binary log on COMMIT and not stored if one does ROLLBACK. This fixes some problems with non-transactional temporary tables used inside transactions.

  • Allow braces in joins in all positions. Formerly, things like SELECT * FROM (t2 LEFT JOIN t3 USING (a)), t1 worked, but not SELECT * FROM t1, (t2 LEFT JOIN t3 USING (a)). Note that braces are simply removed, they do not change the way the join is executed.

  • InnoDB now supports also isolation levels READ UNCOMMITTED and READ COMMITTED. For a detailed InnoDB changelog, see 항7.5.16. 「InnoDB 의 변경 이력」 in this manual.

Bugs fixed:

  • Fixed bug in MAX() optimization when used with JOIN and ON expressions.

  • Fixed that INSERT DELAY threads don't hang on Waiting for INSERT when one sends a SIGHUP to mysqld.

  • Fixed that MySQL will not use an index scan on an index that has been disabled with IGNORE INDEX or USE INDEX.

  • Corrected test for root user in mysqld_safe.

  • Fixed error message issued when storage engine cannot do CHECK or REPAIR.

  • Fixed rare core dump problem in complicated GROUP BY queries that didn't return any result.

  • Fixed mysqlshow to work properly with wildcarded database names and with database names that contain underscores.

  • Portability fixes to get MySQL to compile cleanly with Sun Forte 5.0.

  • Fixed MyISAM crash when using dynamic-row tables with huge numbers of packed fields.

  • Fixed query cache behavior with BDB transactions.

  • Fixed possible floating point exception in MATCH relevance calculations.

  • Fixed bug in full-text search IN BOOLEAN MODE that made MATCH to return incorrect relevance value in some complex joins.

  • Fixed a bug that limited MyISAM key length to a value slightly less that 500. It is exactly 500 now.

  • Fixed that GROUP BY on columns that may have a NULL value doesn't always use disk based temporary tables.

  • The filename argument for the --des-key-file argument to mysqld is interpreted relative to the data directory if given as a relative pathname.

  • Removed a condition that temp table with index on column that can be NULL has to be MyISAM. This was okay for 3.23, but not needed in 4.*. This resulted in slowdown in many queries since 4.0.2.

  • Small code improvement in multiple-table updates.

  • Fixed a newly introduced bug that caused ORDER BY ... LIMIT row_count to not return all rows.

  • Fixed a bug in multiple-table deletes when outer join is used on an empty table, which gets first to be deleted.

  • Fixed a bug in multiple-table updates when a single table is updated.

  • Fixed bug that caused REPAIR TABLE and myisamchk to corrupt FULLTEXT indexes.

  • Fixed bug with caching the mysql grant table database. Now queries in this database are not cached in the query cache.

  • Small fix in mysqld_safe for some shells.

  • Give error if a MyISAM MERGE table has more than 2 ^ 32 rows and MySQL was not compiled with -DBIG_TABLES.

  • Fixed some ORDER BY ... DESC problems with InnoDB tables.

D.3.14. Changes in release 4.0.4 (29 Sep 2002)

  • Fixed bug where GRANT/REVOKE failed if hostname was given in non-matching case.

  • Don't give warning in LOAD DATA INFILE when setting a timestamp to a string value of '0'.

  • Fixed bug in myisamchk -R mode.

  • Fixed bug that caused mysqld to crash on REVOKE.

  • Fixed bug in ORDER BY when there is a constant in the SELECT statement.

  • One didn't get an error message if mysqld couldn't open the privilege tables.

  • SET PASSWORD FOR ... closed the connection in case of errors (bug from 4.0.3).

  • Increased max possible max_allowed_packet in mysqld to 1 GB.

  • Fixed bug when doing a multi-line INSERT on a table with an AUTO_INCREMENT key which was not in the first part of the key.

  • Changed LOAD DATA INFILE to not recreate index if the table had rows from before.

  • Fixed overrun bug when calling AES_DECRYPT() with incorrect arguments.

  • --skip-ssl can now be used to disable SSL in the MySQL clients, even if one is using other SSL options in an option file or previously on the command line.

  • Fixed bug in MATCH ... AGAINST( ... IN BOOLEAN MODE) used with ORDER BY.

  • Added LOCK TABLES and CREATE TEMPORARY TABLES privilege on the database level. One must run the mysql_fix_privilege_tables script on old installations to activate these.

  • In SHOW TABLE ... STATUS, compressed tables sometimes showed up as dynamic.

  • SELECT @@[global|session].var_name didn't report global | session in the result column name.

  • Fixed problem in replication that FLUSH LOGS in a circular replication setup created an infinite number of binary log files. Now a rotate-binary-log command in the binary log will not cause slaves to rotate logs.

  • Removed STOP EVENT from binary log when doing FLUSH LOGS.

  • Disable the use of SHOW NEW MASTER FOR SLAVE as this needs to be completely reworked in a future release.

  • Fixed a bug with constant expression (for example, field of a one-row table, or field from a table, referenced by a UNIQUE key) appeared in ORDER BY part of SELECT DISTINCT.

  • --log-binary=a.b.c now properly strips off .b.c.

  • FLUSH LOGS removed numerical extension for all future update logs.

  • GRANT ... REQUIRE didn't store the SSL information in the mysql.user table if SSL was not enabled in the server.

  • GRANT ... REQUIRE NONE can now be used to remove SSL information.

  • AND is now optional between REQUIRE options.

  • REQUIRE option was not properly saved, which could cause strange output in SHOW GRANTS.

  • Fixed that mysqld --help reports correct values for --datadir and --bind-address.

  • Fixed that one can drop UDFs that didn't exist when mysqld was started.

  • Fixed core dump problem with SHOW VARIABLES on some 64-bit systems (like Solaris sparc).

  • Fixed a bug in my_getopt(); --set-variable syntax didn't work for those options that didn't have a valid variable in the my_option struct. This affected at least the default-table-type option.

  • Fixed a bug from 4.0.2 that caused REPAIR TABLE and myisamchk --recover to fail on tables with duplicates in a unique key.

  • Fixed a bug from 4.0.3 in calculating the default datatype for some functions. This affected queries of type CREATE TABLE table_name SELECT expression(),...

  • Fixed bug in queries of type SELECT * FROM table-list GROUP BY ... and SELECT DISTINCT * FROM ....

  • Fixed bug with the --slow-log when logging an administrator command (like FLUSH TABLES).

  • Fixed a bug that OPTIMIZE of locked and modified table, reported table corruption.

  • Fixed a bug in my_getopt() in handling of special prefixes (--skip-, --enable-). --skip-external-locking didn't work and the bug may have affected other similar options.

  • Fixed bug in checking for output file name of the tee option.

  • Added some more optimization to use index for SELECT ... FROM many_tables .. ORDER BY key limit #

  • Fixed problem in SHOW OPEN TABLES when a user didn't have access permissions to one of the opened tables.

D.3.15. Changes in release 4.0.3 (26 Aug 2002: Beta)

  • Fixed problem with types of user variables. (Bug #551)

  • Fixed problem with configure ... --localstatedir=....

  • Cleaned up mysql.server script.

  • Fixed a bug in mysqladmin shutdown when pid file was modified while mysqladmin was still waiting for the previous one to disappear. This could happen during a very quick restart and caused mysqladmin to hang until shutdown_timeout seconds had passed.

  • Don't increment warnings when setting AUTO_INCREMENT columns to NULL in LOAD DATA INFILE.

  • Fixed all boolean type variables/options to work with the old syntax, for example, all of these work: --lower-case-table-names, --lower-case-table-names=1, -O lower-case-table-names=1, --set-variable=lower-case-table-names=1

  • Fixed shutdown problem (SIGTERM signal handling) on Solaris. (Bug from 4.0.2).

  • SHOW MASTER STATUS now returns an empty set if binary log is not enabled.

  • SHOW SLAVE STATUS now returns an empty set if slave is not initialized.

  • Don't update MyISAM index file on update if not strictly necessary.

  • Fixed bug in SELECT DISTINCT ... FROM many_tables ORDER BY not-used-column.

  • Fixed a bug with BIGINT values and quoted strings.

  • Added QUOTE() function that performs SQL quoting to produce values that can be used as data values in queries.

  • Changed variable DELAY_KEY_WRITE to an enum to allow one set DELAY_KEY_WRITE for all tables without taking down the server.

  • Changed behavior of IF(condition,column,NULL) so that it returns the value of the column type.

  • Made safe_mysqld a symlink to mysqld_safe in binary distribution.

  • Fixed security bug when having an empty database name in the user.db table.

  • Fixed some problems with CREATE TABLE ... SELECT function().

  • mysqld now has the option --temp-pool enabled by default as this gives better performance with some operating systems.

  • Fixed problem with too many allocated alarms on slave when connecting to master many times (normally not a very critical error).

  • Fixed hang in CHANGE MASTER TO if the slave thread died very quickly.

  • Big cleanup in replication code (less logging, better error messages, etc..)

  • If the --code-file option is specified, the server calls setrlimit() to set the maximum allowed core file size to unlimited, so core files can be generated.

  • Fixed bug in query cache after temporary table creation.

  • Added --count=N (-c) option to mysqladmin, to make the program do only N iterations. To be used with --sleep (-i). Useful in scripts.

  • Fixed bug in multiple-table UPDATE: when updating a table, do_select() became confused about reading records from a cache.

  • Fixed bug in multiple-table UPDATE when several fields were referenced from a single table

  • Fixed bug in truncating nonexisting table.

  • Fixed bug in REVOKE that caused user resources to be randomly set.

  • Fixed bug in GRANT for the new CREATE TEMPORARY TABLE privilege.

  • Fixed bug in multiple-table DELETE when tables are re-ordered in the table initialization method and ref_lengths are of different sizes.

  • Fixed two bugs in SELECT DISTINCT with large tables.

  • Fixed bug in query cache initialization with very small query cache size.

  • Allow DEFAULT with INSERT statement.

  • The startup parameters myisam_max_sort_file_size and myisam_max_extra_sort_file_size are now given in bytes, not megabytes.

  • External system locking of MyISAM/ISAM files is now turned off by default. One can turn this on with --external-locking. (For most users this is never needed).

  • Fixed core dump bug with INSERT ... SET db_name.table_name.colname=''.

  • Fixed client hangup bug when using some SQL commands with incorrect syntax.

  • Fixed a timing bug in DROP DATABASE

  • New SET [GLOBAL | SESSION] syntax to change thread-specific and global server variables at runtime.

  • Added variable slave_compressed_protocol.

  • Renamed variable query_cache_startup_type to query_cache_type, myisam_bulk_insert_tree_size to bulk_insert_buffer_size, record_buffer to read_buffer_size and record_rnd_buffer to read_rnd_buffer_size.

  • Renamed some SQL variables, but old names will still work until 5.0. See 항2.5.2. 「버젼 3.23 (으)로부터 4.0 에의 업그레이드」.

  • Renamed --skip-locking to --skip-external-locking.

  • Removed unused variable query_buffer_size.

  • Fixed a bug that made the pager option in the mysql client non-functional.

  • Added full AUTO_INCREMENT support to MERGE tables.

  • Extended LOG() function to accept an optional arbitrary base parameter. See 항6.3.3.2. 「수학 함수」.

  • Added LOG2() function (useful for finding out how many bits a number would require for storage).

  • Added LN() natural logarithm function for compatibility with other databases. It is synonymous with LOG(X).

D.3.16. Changes in release 4.0.2 (01 Jul 2002)

  • Cleaned up NULL handling for default values in DESCRIBE table_name.

  • Fixed truncate() to round up negative values to the nearest integer.

  • Changed --chroot=path option to execute chroot() immediately after all options have been parsed.

  • Don't allow database names that contain ‘\ ＇.

  • lower_case_table_names now also affects database names.

  • Added XOR operator (logical and bitwise XOR) with ^ as a synonym for bitwise XOR.

  • Added function IS_FREE_LOCK("lock_name"). Based on code contributed by Hartmut Holzgraefe <hartmut@six.de>.

  • Removed mysql_ssl_clear() from C API, as it was not needed.

  • DECIMAL and NUMERIC types can now read exponential numbers.

  • Added SHA1() function to calculate 160 bit hash value as described in RFC 3174 (Secure Hash Algorithm). This function can be considered a cryptographically more secure equivalent of MD5(). See 항6.3.6.2. 「그 외의 각종 함수」.

  • Added AES_ENCRYPT() and AES_DECRYPT() functions to perform encryption according to AES standard (Rijndael). See 항6.3.6.2. 「그 외의 각종 함수」.

  • Added --single-transaction option to mysqldump, allowing a consistent dump of InnoDB tables. See 항4.9.7. 「mysqldump (테이블 구조와 데이터의 덤프)」.

  • Fixed bug in innodb_log_group_home_dir in SHOW VARIABLES.

  • Fixed a bug in optimizer with merge tables when non-unique values are used in summing up (causing crashes).

  • Fixed a bug in optimizer when a range specified makes index grouping impossible (causing crashes).

  • Fixed a rare bug when FULLTEXT index is present and no tables are used.

  • Added privileges CREATE TEMPORARY TABLES, EXECUTE, LOCK TABLES, REPLICATION CLIENT, REPLICATION SLAVE, SHOW DATABASES and SUPER. To use these, you must have run the mysql_fix_privilege_tables script after upgrading.

  • Fixed query cache align data bug.

  • Fixed mutex bug in replication when reading from master fails.

  • Added missing mutex in TRUNCATE TABLE; This fixes some core dump/hangup problems when using TRUNCATE TABLE.

  • Fixed bug in multiple-table DELETE when optimizer uses only indexes.

  • Fixed that ALTER TABLE table_name RENAME new_table_name is as fast as RENAME TABLE.

  • Fixed bug in GROUP BY with two or more fields, where at least one field can contain NULL values.

  • Use Turbo Boyer-Moore algorithm to speed up LIKE "%keyword%" searches.

  • Fixed bug in DROP DATABASE with symlink.

  • Fixed crash in REPAIR ... USE_FRM.

  • Fixed bug in EXPLAIN with LIMIT offset != 0.

  • Fixed bug in phrase operator "..." in boolean full-text search.

  • Fixed bug that caused duplicated rows when using truncation operator * in boolean full-text search.

  • Fixed bug in truncation operator of boolean full-text search (incorrect results when there are only +word*s in the query).

  • Fixed bug in boolean full-text search that caused a crash when an identical MATCH expression that did not use an index appeared twice.

  • Query cache is now automatically disabled in mysqldump.

  • Fixed problem on Windows 98 that made sending of results very slow.

  • Boolean full-text search weighting scheme changed to something more reasonable.

  • Fixed bug in boolean full-text search that caused MySQL to ignore queries of ft_min_word_len characters.

  • Boolean full-text search now supports ``phrase searches''.

  • New configure option --without-query-cache.

  • Memory allocation strategy for ``root memory'' changed. Block size now grows with number of allocated blocks.

  • INET_NTOA() now returns NULL if you give it an argument that is too large (greater than the value corresponding to 255.255.255.255).

  • Fix SQL_CALC_FOUND_ROWS to work with UNION. It will work only if the first SELECT has this option and if there is global LIMIT for the entire statement. For the moment, this requires using parentheses for individual SELECT queries within the statement.

  • Fixed bug in SQL_CALC_FOUND_ROWS and LIMIT.

  • Don't give an error for CREATE TABLE ...(... VARCHAR(0)).

  • Fixed SIGINT and SIGQUIT problems in mysql.cc on Linux with some glibc versions.

  • Fixed bug in convert.cc, which is caused by having an incorrect net_store_length() linked in the CONVERT::store() method.

  • DOUBLE and FLOAT columns now honor the UNSIGNED flag on storage.

  • InnoDB now retains foreign key constraints through ALTER TABLE and CREATE/DROP INDEX.

  • InnoDB now allows foreign key constraints to be added through the ALTER TABLE syntax.

  • InnoDB tables can now be set to automatically grow in size (autoextend).

  • Added --ignore-lines=n option to mysqlimport. This has the same effect as the IGNORE n LINES clause for LOAD DATA.

  • Fixed bug in UNION with last offset being transposed to total result set.

  • REPAIR ... USE_FRM added.

  • Fixed that DEFAULT_SELECT_LIMIT is always imposed on UNION result set.

  • Fixed that some SELECT options can appear only in the first SELECT.

  • Fixed bug with LIMIT with UNION, where last select is in the braces.

  • Fixed that full-text works fine with UNION operations.

  • Fixed bug with indexless boolean full-text search.

  • Fixed bug that sometimes appeared when full-text search was used with const tables.

  • Fixed incorrect error value when doing a SELECT with an empty HEAP table.

  • Use ORDER BY column DESC now sorts NULL values first. (In other words, NULL values sort first in all cases, whether or not DESC is specified.) This is changed back in 4.0.10.

  • Fixed bug in WHERE key_name='constant' ORDER BY key_name DESC.

  • Fixed bug in SELECT DISTINCT ... ORDER BY DESC optimization.

  • Fixed bug in ... HAVING 'GROUP_FUNCTION'(xxx) IS [NOT] NULL.

  • Fixed bug in truncation operator for boolean full-text search.

  • Allow value of --user=# option for mysqld to be specified as a numeric user ID.

  • Fixed a bug where SQL_CALC_ROWS returned an incorrect value when used with one table and ORDER BY and with InnoDB tables.

  • Fixed that SELECT 0 LIMIT 0 doesn't hang thread.

  • Fixed some problems with USE/IGNORE INDEX when using many keys with the same start column.

  • Don't use table scan with BerkeleyDB and InnoDB tables when we can use an index that covers the whole row.

  • Optimized InnoDB sort-buffer handling to take less memory.

  • Fixed bug in multiple-table DELETE and InnoDB tables.

  • Fixed problem with TRUNCATE and InnoDB tables that produced the error Can't execute the given command because you have active locked tables or an active transaction.

  • Added NO_UNSIGNED_SUBTRACTION to the set of flags that may be specified with the --sql-mode option for mysqld. It disables unsigned arithmetic rules when it comes to subtraction. (This will make MySQL 4.0 behave more like 3.23 with UNSIGNED columns).

  • The result returned for all bit functions (|, <<, ...) is now of type unsigned integer.

  • Added detection of nan values in MyISAM to make it possible to repair tables with nan in float or double columns.

  • Fixed new bug in myisamchk where it didn't correctly update number of ``parts'' in the MyISAM index file.

  • Changed to use autoconf 2.52 (from autoconf 2.13).

  • Fixed optimization problem where the MySQL Server was in ``preparing'' state for a long time when selecting from an empty table which had contained a lot of rows.

  • Fixed bug in complicated join with const tables. This fix also improves performance a bit when referring to another table from a const table.

  • First pre-version of multiple-table UPDATE statement.

  • Fixed bug in multiple-table DELETE.

  • Fixed bug in SELECT CONCAT(argument_list) ... GROUP BY 1.

  • INSERT ... SELECT did a full rollback in case of an error. Fixed so that we only roll back the last statement in the current transaction.

  • Fixed bug with empty expression for boolean full-text search.

  • Fixed core dump bug in updating full-text key from/to NULL.

  • ODBC compatibility: Added BIT_LENGTH() function.

  • Fixed core dump bug in GROUP BY BINARY column.

  • Added support for NULL keys in HEAP tables.

  • Use index for ORDER BY in queries of type: SELECT * FROM t WHERE key_part1=1 ORDER BY key_part1 DESC,key_part2 DESC

  • Fixed bug in FLUSH QUERY CACHE.

  • Added CAST() and CONVERT() functions. The CAST and CONVERT functions are nearly identical and mainly useful when you want to create a column with a specific type in a CREATE ... SELECT statement. For more information, read 항6.3.5. 「캐스트 함수」.

  • CREATE ... SELECT on DATE and TIME functions now create columns of the expected type.

  • Changed order in which keys are created in tables.

  • Added new columns Null and Index_type to SHOW INDEX output.

  • Added --no-beep and --prompt options to mysql command-line client.

  • New feature: management of user resources.

    GRANT ... WITH MAX_QUERIES_PER_HOUR N1
               MAX_UPDATES_PER_HOUR N2
               MAX_CONNECTIONS_PER_HOUR N3;

    See 항4.4.7. 「유저 자원의 제한」.

  • Added mysql_secure_installation to the scripts/ directory.

D.3.17. Changes in release 4.0.1 (23 Dec 2001)

  • Added system command to mysql.

  • Fixed bug when HANDLER was used with some unsupported table type.

  • mysqldump now puts ALTER TABLE tbl_name DISABLE KEYS and ALTER TABLE tbl_name ENABLE KEYS in the sql dump.

  • Added mysql_fix_extensions script.

  • Fixed stack overrun problem with LOAD DATA FROM MASTER on OSF/1.

  • Fixed shutdown problem on HP-UX.

  • Added DES_ENCRYPT() and DES_DECRYPT() functions.

  • Added FLUSH DES_KEY_FILE statement.

  • Added --des-key-file option to mysqld.

  • HEX(string) now returns the characters in string converted to hexadecimal.

  • Fixed problem with GRANT when using lower_case_table_names=1.

  • Changed SELECT ... IN SHARE MODE to SELECT ... LOCK IN SHARE MODE (as in MySQL 3.23).

  • A new query cache to cache results from identical SELECT queries.

  • Fixed core dump bug on 64-bit machines when it got an incorrect communication packet.

  • MATCH ... AGAINST(... IN BOOLEAN MODE) can now work without FULLTEXT index.

  • Fixed slave to replicate from 3.23 master.

  • Miscellaneous replication fixes/cleanup.

  • Got shutdown to work on Mac OS X.

  • Added myisam/ft_dump utility for low-level inspection of FULLTEXT indexes.

  • Fixed bug in DELETE ... WHERE ... MATCH ....

  • Added support for MATCH ... AGAINST(... IN BOOLEAN MODE). Note: you must rebuild your tables with ALTER TABLE tablename TYPE=MyISAM to be able to use boolean full-text search.

  • LOCATE() and INSTR() are now case-sensitive if either argument is a binary string.

  • Changed RAND() initialization so that RAND(N) and RAND(N+1) are more distinct.

  • Fixed core dump bug in UPDATE ... ORDER BY.

  • In 3.23, INSERT INTO ... SELECT always had IGNORE enabled. Now MySQL will stop (and possibly roll back) by default in case of an error unless you specify IGNORE.

  • Ignore DATA DIRECTORY and INDEX DIRECTORY directives on Windows.

  • Added boolean full-text search code. It should be considered early alpha.

  • Extended MODIFY and CHANGE in ALTER TABLE to accept the FIRST and AFTER keywords.

  • Indexes are now used with ORDER BY on a whole InnoDB table.

D.3.18. Changes in release 4.0.0 (Oct 2001: Alpha)

  • Added --xml option to mysql for producing XML output.

  • Added full-text variables ft_min_word_len, ft_max_word_len, and ft_max_word_len_for_sort.

  • Added documentation for libmysqld, the embedded MySQL server library. Also added example programs (a mysql client and mysqltest test program) which use libmysqld.

  • Removed all Gemini hooks from MySQL server.

  • Removed my_thread_init() and my_thread_end() from mysql_com.h, and added mysql_thread_init() and mysql_thread_end() to mysql.h.

  • Support for communication packets > 16M. In 4.0.1 we will extend MyISAM to be able to handle these.

  • Secure connections (with SSL).

  • Unsigned BIGINT constants now work. MIN() and MAX() now handle signed and unsigned BIGINT numbers correctly.

  • New character set latin1_de which provides correct German sorting.

  • STRCMP() now uses the current character set when doing comparisons, which means that the default comparison behavior now is case-insensitive.

  • TRUNCATE TABLE and DELETE FROM tbl_name are now separate functions. One bonus is that DELETE FROM tbl_name now returns the number of deleted rows, rather than zero.

  • DROP DATABASE now executes a DROP TABLE on all tables in the database, which fixes a problem with InnoDB tables.

  • Added support for UNION.

  • Added support for multiple-table DELETE operations.

  • A new HANDLER interface to MyISAM tables.

  • Added support for INSERT on MERGE tables. Patch from Benjamin Pflugmann.

  • Changed WEEK(date,0) to match the calendar in the USA.

  • COUNT(DISTINCT) is about 30% faster.

  • Speed up all internal list handling.

  • Speed up IS NULL, ISNULL() and some other internal primitives.

  • Full-text index creation now is much faster.

  • Tree-like cache to speed up bulk inserts and myisam_bulk_insert_tree_size variable.

  • Searching on packed (CHAR/VARCHAR) keys is now much faster.

  • Optimized queries of type: SELECT DISTINCT * from tbl_name ORDER by key_part1 LIMIT row_count.

  • SHOW CREATE TABLE now shows all table attributes.

  • ORDER BY ... DESC can now use keys.

  • LOAD DATA FROM MASTER ``automatically'' sets up a slave.

  • Renamed safe_mysqld to mysqld_safe to make this name more in line with other MySQL scripts/commands.

  • Added support for symbolic links to MyISAM tables. Symlink handling is now enabled by default for Windows.

  • Added SQL_CALC_FOUND_ROWS and FOUND_ROWS(). This makes it possible to know how many rows a query would have returned without a LIMIT clause.

  • Changed output format of SHOW OPEN TABLES.

  • Allow SELECT expression LIMIT ....

  • Added ORDER BY syntax to UPDATE and DELETE.

  • SHOW INDEXES is now a synonym for SHOW INDEX.

  • Added ALTER TABLE tbl_name DISABLE KEYS and ALTER TABLE tbl_name ENABLE KEYS commands.

  • Allow use of IN as a synonym for FROM in SHOW commands.

  • Implemented ``repair by sort'' for FULLTEXT indexes. REPAIR TABLE, ALTER TABLE, and OPTIMIZE TABLE for tables with FULLTEXT indexes are now up to 100 times faster.

  • Allow SQL-99 syntax X'hexadecimal-number'.

  • Cleaned up global lock handling for FLUSH TABLES WITH READ LOCK.

  • Fixed problem with DATETIME = constant in WHERE optimization.

  • Added --master-data and --no-autocommit options to mysqldump. (Thanks to Brian Aker for this.)

  • Added script mysql_explain_log.sh to distribution. (Thanks to mobile.de).


D.4. Changes in release 3.23.x (Recent; still supported)

Please note that since release 4.0 is now production level, only critical fixes are done in the 3.23 release series. You are recommended to upgrade when possible, to take advantage of all speed and feature improvements in 4.0. See 항2.5.2. 「버젼 3.23 (으)로부터 4.0 에의 업그레이드」.

The 3.23 release has several major features that are not present in previous versions. We have added three new table types:

  • MyISAM

    A new ISAM library which is tuned for SQL and supports large files.

  • InnoDB

    A transaction-safe storage engine that supports row level locking, and many Oracle-like features.

  • BerkeleyDB or BDB

    Uses the Berkeley DB library from Sleepycat Software to implement transaction-safe tables.

Note that only MyISAM is available in the standard binary distribution.

The 3.23 release also includes support for database replication between a master and many slaves, full-text indexing, and much more.

All new features are being developed in the 4.x version. Only bug fixes and minor enhancements to existing features will be added to 3.23.

The replication code and BerkeleyDB code is still not as tested and as the rest of the code, so we will probably need to do a couple of future releases of 3.23 with small fixes for this part of the code. As long as you don't use these features, you should be quite safe with MySQL 3.23!

Note that the above doesn't mean that replication or Berkeley DB don't work. We have done a lot of testing of all code, including replication and BDB without finding any problems. It only means that not as many users use this code as the rest of the code and because of this we are not yet 100% confident in this code.

D.4.1. Changes in release 3.23.59 (not released yet)

  • If a query was ignored on the slave (because of replicate-ignore-table and other similar rules), the slave still checked if the query got the same error code (0, no error) as on the master. So if the master had an error on the query (for example, ``Duplicate entry'' in a multiple-row insert), then the slave stopped and warned that the error codes didn't match. This is a backport of the fix for MySQL 4.0. (Bug #797)

  • mysqlbinlog now asks for a password at console when the -p/--password option is used with no argument. This is how the other clients (mysqladmin, mysqldump..) already behave. Note that one now has to use mysqlbinlog -p<my_password>; mysqlbinlog -p <my_password> will not work anymore (in other words, put no space after -p). (Bug #1595)

  • On some 64-bit machines (some HP-UX and Solaris machines), a slave installed with the 64-bit MySQL binary could not connect to its master (it connected to itself instead). (Bug #1256, #1381)

  • Fixed a Windows-specific bug present since MySQL version 3.23.57 and 3.23.58, which caused Windows slaves to crash when they started replication if a master.info file existed. (Bug #1720)

D.4.2. Changes in release 3.23.58 (11 Sep 2003)

  • Fixed buffer overflow in password handling which could potentially be exploited by MySQL users with ALTER privilege on the mysql.user table to execute random code or to gain shell access with the UID of the mysqld process (thanks to Jedi/Sector One for spotting and reporting this bug).

  • mysqldump now correctly quotes all identifiers when communicating with the server. This assures that during the dump process, mysqldump will never send queries to the server that result in a syntax error. This problem is not related to the mysqldump program's output, which was not changed. (Bug #1148)

  • Fixed table/column grant handling - proper sort order (from most specific to less specific, see 항4.3.10. 「액세스 제어의 단계 2: 요구 확인」) was not honored. (Bug #928)

  • Fixed overflow bug in MyISAM and ISAM when a row is updated in a table with a large number of columns and at least one BLOB/TEXT column.

  • Fixed MySQL so that field length (in C API) for the second column in SHOW CREATE TABLE is always larger than the data length. The only known application that was affected by the old behavior was Borland dbExpress, which truncated the output from the command. (Bug #1064)

  • Fixed ISAM bug in MAX() optimization.

  • Fixed Unknown error when doing ORDER BY on reference table which was used with NULL value on NOT NULL column. (Bug #479)

D.4.3. Changes in release 3.23.57 (06 Jun 2003)

  • Fixed problem in alarm handling that could cause problems when getting a packet that is too large.

  • Fixed problem when installing MySQL as a service on Windows when one gave 2 arguments (option file group name and service name) to mysqld.

  • Fixed kill pid-of-mysqld to work on Mac OS X.

  • SHOW TABLE STATUS displayed incorrect Row_format value for tables that have been compressed with myisampack. (Bug #427)

  • SHOW VARIABLES LIKE 'innodb_data_file_path' displayed only the name of the first datafile. (Bug #468)

  • Fixed security problem where mysqld didn't allow one to UPDATE rows in a table even if one had a global UPDATE privilege and a database SELECT privilege.

  • Fixed a security problem with SELECT and wildcarded select list, when user only had partial column SELECT privileges on the table.

  • Fixed unlikely problem in optimizing WHERE clause with a constant expression such as in WHERE 1 AND (a=1 AND b=1).

  • Fixed problem on IA-64 with timestamps that caused mysqlbinlog to fail.

  • The default option for innodb_flush_log_at_trx_commit was changed from 0 to 1 to make InnoDB tables ACID by default. See 항7.5.3. 「InnoDB 기동 옵션」.

  • Fixed problem with too many allocated alarms on slave when connecting to master many times (normally not a very critical error).

  • Fixed a bug in replication of temporary tables. (Bug #183)

  • Fixed 64-bit bug that affected at least AMD hammer systems.

  • Fixed a bug when doing LOAD DATA INFILE IGNORE: When reading the binary log, mysqlbinlog and the replication code read REPLACE instead of IGNORE. This could make the slave's table become different from the master's table. (Bug #218)

  • Fixed overflow bug in MyISAM when a row is inserted into a table with a large number of columns and at least one BLOB/TEXT column. Bug was caused by incorrect calculation of the needed buffer to pack data.

  • The binary log was not locked during TRUNCATE table_name or DELETE FROM table_name statements, which could cause an INSERT to table_name to be written to the log before the TRUNCATE or DELETE statements.

  • Fixed rare bug in UPDATE of InnoDB tables where one row could be updated multiple times.

  • Produce an error for empty table and column names.

  • Changed PROCEDURE ANALYSE() to report DATE instead of NEWDATE.

  • Changed PROCEDURE ANALYSE(#) to restrict the number of values in an ENUM column to # also for string values.

  • mysqldump no longer silently deletes the binary logs when invoked with the --master-data or --first-slave option; while this behavior was convenient for some users, others may suffer from it. Now one has to explicitly ask for binary logs to be deleted by using the new --delete-master-logs option.

  • Fixed a bug in mysqldump when it was invoked with the --master-data option: The CHANGE MASTER TO statements that were appended to the SQL dump had incorrect coordinates. (Bug #159)

D.4.4. Changes in release 3.23.56 (13 Mar 2003)

  • Fixed mysqld crash on extremely small values of sort_buffer variable.

  • Fixed a bug in privilege system for GRANT UPDATE on column level.

  • Fixed a rare bug when using a date in HAVING with GROUP BY.

  • Fixed checking of random part of WHERE clause. (Bug #142)

  • Fixed MySQL (and myisamchk) crash on artificially corrupted .MYI files.

  • Security enhancement: mysqld no longer reads options from world-writeable config files.

  • Security enhancement: mysqld and safe_mysqld now only use the first --user option specified on the command line. (Normally this comes from /etc/my.cnf)

  • Security enhancement: Don't allow BACKUP TABLE to overwrite existing files.

  • Fixed unlikely deadlock bug when one thread did a LOCK TABLE and another thread did a DROP TABLE. In this case one could do a KILL on one of the threads to resolve the deadlock.

  • LOAD DATA INFILE was not replicated by slave if replicate_*_table was set on the slave.

  • Fixed a bug in handling CHAR(0) columns that could cause incorrect results from the query.

  • Fixed a bug in SHOW VARIABLES on 64-bit platforms. The bug was caused by incorrect declaration of variable server_id.

  • The Comment column in SHOW TABLE STATUS now reports that it can contain NULL values (which is the case for a crashed .frm file).

  • Fixed the rpl_rotate_logs test to not fail on certain platforms (e.g. Mac OS X) due to a too long file name (changed slave-master-info.opt to .slave-mi).

  • Fixed a problem with BLOB NOT NULL columns used with IS NULL.

  • Fixed bug in MAX() optimization in MERGE tables.

  • Better RAND() initialization for new connections.

  • Fixed bug with connect timeout. This bug was manifested on OS's with poll() system call, which resulted in timeout the value specified as it was executed in both select() and poll().

  • Fixed bug in SELECT * FROM table WHERE datetime1 IS NULL OR datetime2 IS NULL.

  • Fixed bug in using aggregate functions as argument for INTERVAL, CASE, FIELD, CONCAT_WS, ELT and MAKE_SET functions.

  • When running with --lower-case-table-names (default on Windows) and you had tables or databases with mixed case on disk, then executing SHOW TABLE STATUS followed with DROP DATABASE or DROP TABLE could fail with Errcode 13.

  • Fixed bug in logging to binary log (which affects replication) a query that inserts a NULL in an auto_increment field and also uses LAST_INSERT_ID().

  • Fixed bug in mysqladmin --relative.

  • On some 64-bit systems, show status reported a strange number for Open_files and Open_streams.

D.4.5. Changes in release 3.23.55 (23 Jan 2003)

  • Fixed double free'd pointer bug in mysql_change_user() handling, that enabled a specially hacked version of MySQL client to crash mysqld. Note, that one needs to login to the server by using a valid user account to be able to exploit this bug.

  • Fixed bug with the --slow-log when logging an administrator command (like FLUSH TABLES).

  • Fixed bug in GROUP BY when used on BLOB column with NULL values.

  • Fixed a bug in handling NULL values in CASE ... WHEN ....

  • Bugfix for --chroot (see 항D.4.6. 「Changes in release 3.23.54 (05 Dec 2002) 」) is reverted. Unfortunately, there is no way to make it to work, without introducing backward-incompatible changes in my.cnf. Those who need --chroot functionality, should upgrade to MySQL 4.0. (The fix in the 4.0 branch did not break backward-compatibility).

  • Make --lower-case-table-names default on Mac OS X as the default file system (HFS+) is case insensitive.

  • Fixed a bug in scripts/mysqld_safe.sh in NOHUP_NICENESS testing.

  • Transactions in AUTOCOMMIT=0 mode didn't rotate binary log.

  • Fixed a bug in scripts/make_binary_distribution that resulted in a remaining @HOSTNAME@ variable instead of replacing it with the correct path to the hostname binary.

  • Fixed a very unlikely bug that could cause SHOW PROCESSLIST to core dump in pthread_mutex_unlock() if a new thread was connecting.

  • Forbid SLAVE STOP if the thread executing the query has locked tables. This removes a possible deadlock situation.

D.4.6. Changes in release 3.23.54 (05 Dec 2002)

  • Fixed a bug, that allowed to crash mysqld with a specially crafted packet.

  • Fixed a rare crash (double free'd pointer) when altering a temporary table.

  • Fixed buffer overrun in libmysqlclient library that allowed malicious MySQL server to crash the client application.

  • Fixed security-related bug in mysql_change_user() handling. All users are strongly recommended to upgrade to the version 3.23.54.

  • Fixed bug that prevented --chroot command-line option of mysqld from working.

  • Fixed bug that made OPTIMIZE TABLE to corrupt the table under some rare circumstances.

  • Fixed mysqlcheck so it can deal with table names containing dashes.

  • Fixed shutdown problem on Mac OS X.

  • Fixed bug with comparing an indexed NULL field with <=> NULL.

  • Fixed bug that caused IGNORE INDEX and USE INDEX sometimes to be ignored.

  • Fixed rare core dump problem in complicated GROUP BY queries that didn't return any result.

  • Fixed a bug where MATCH ... AGAINST () >=0 was treated as if it was >.

  • Fixed core dump in SHOW PROCESSLIST when running with an active slave (unlikely timing bug).

  • Make it possible to use multiple MySQL servers on Windows (code backported from 4.0.2).

  • One can create TEMPORARY MERGE tables now.

  • Fixed that --core-file works on Linux (at least on kernel 2.4.18).

  • Fixed a problem with BDB and ALTER TABLE.

  • Fixed reference to freed memory when doing complicated GROUP BY ... ORDER BY queries. Symptom was that mysqld died in function send_fields.

  • Allocate heap rows in smaller blocks to get better memory usage.

  • Fixed memory allocation bug when storing BLOB values in internal temporary tables used for some (unlikely) GROUP BY queries.

  • Fixed a bug in key optimizing handling where the expression WHERE column_name = key_column_name was calculated as true for NULL values.

  • Fixed core dump bug when doing LEFT JOIN ... WHERE key_column=NULL.

  • Fixed MyISAM crash when using dynamic-row tables with huge numbers of packed fields.

  • Updated source tree to be built using automake 1.5 and libtool 1.4.

D.4.7. Changes in release 3.23.53 (09 Oct 2002)

  • Fixed crash when SHOW INNODB STATUS was used and skip-innodb was defined.

  • Fixed possible memory corruption bug in binary log file handling when slave rotated the logs (only affected 3.23, not 4.0).

  • Fixed problem in LOCK TABLES on Windows when one connects to a database that contains upper case letters.

  • Fixed that --skip-show-databases doesn't reset the --port option.

  • Small fix in safe_mysqld for some shells.

  • Fixed that FLUSH STATUS doesn't reset delayed_insert_threads.

  • Fixed core dump bug when using the BINARY cast on a NULL value.

  • Fixed race condition when someone did a GRANT at the same time a new user logged in or did a USE database.

  • Fixed bug in ALTER TABLE and RENAME TABLE when running with -O lower_case_table_names=1 (typically on Windows) when giving the table name in uppercase.

  • Fixed that -O lower_case_table_names=1 also converts database names to lower case.

  • Fixed unlikely core dump with SELECT ... ORDER BY ... LIMIT.

  • Changed AND/OR to report that they can return NULL. This fixes a bug in GROUP BY on AND/OR expressions that return NULL.

  • Fixed a bug that OPTIMIZE of locked and modified MyISAM table, reported table corruption.

  • Fixed a BDB-related ALTER TABLE bug with dropping a column and shutting down immediately thereafter.

  • Fixed problem with configure ... --localstatedir=....

  • Fixed problem with UNSIGNED BIGINT on AIX (again).

  • Fixed bug in pthread_mutex_trylock() on HPUX 11.0.

  • Multi-threaded stress tests for InnoDB.

D.4.8. Changes in release 3.23.52 (14 Aug 2002)

  • Wrap BEGIN/COMMIT around transaction in the binary log. This makes replication honor transactions.

  • Fixed security bug when having an empty database name in the user.db table.

  • Changed initialization of RND() to make it less predicatable.

  • Fixed problem with GROUP BY on result with expression that created a BLOB field.

  • Fixed problem with GROUP BY on columns that have NULL values. To solve this we now create an MyISAM temporary table when doing a GROUP BY on a possible NULL item. From MySQL 4.0.5 we can use in memory HEAP tables for this case.

  • Fixed problem with privilege tables when downgrading from 4.0.2 to 3.23.

  • Fixed thread bug in SLAVE START, SLAVE STOP and automatic repair of MyISAM tables that could cause table cache to be corrupted.

  • Fixed possible thread related key-cache-corruption problem with OPTIMIZE TABLE and REPAIR TABLE.

  • Added name of 'administrator command' logs.

  • Fixed bug with creating an auto-increment value on second part of a UNIQUE() key where first part could contain NULL values.

  • Don't write slave-timeout reconnects to the error log.

  • Fixed bug with slave net read timeouting

  • Fixed a core-dump bug with MERGE tables and MAX() function.

  • Fixed bug in ALTER TABLE with BDB tables.

  • Fixed bug when logging LOAD DATA INFILE to binary log with no active database.

  • Fixed a bug in range optimizer (causing crashes).

  • Fixed possible problem in replication when doing DROP DATABASE on a database with InnoDB tables.

  • Fixed that mysql_info() returns 0 for 'Duplicates' when using INSERT DELAYED IGNORE.

  • Added -DHAVE_BROKEN_REALPATH to the Mac OS X (darwin) compile options in configure.in to fix a failure under high load.

D.4.9. Changes in release 3.23.51 (31 May 2002)

  • Fix bug with closing tags missing slash for mysqldump XML output.

  • Remove end space from ENUM values. (This fixed a problem with SHOW CREATE TABLE.)

  • Fixed bug in CONCAT_WS() that cut the result.

  • Changed name of server variables Com_show_master_stat to Com_show_master_status and Com_show_slave_stat to Com_show_slave_status.

  • Changed handling of gethostbyname() to make the client library thread-safe even if gethostbyname_r doesn't exist.

  • Fixed core-dump problem when giving a wrong password string to GRANT.

  • Fixed bug in DROP DATABASE with symlinked directory.

  • Fixed optimization problem with DATETIME and value outside DATETIME range.

  • Removed Sleepycat's BDB doc files from the source tree, as they're not needed (MySQL covers BDB in its own documentation).

  • Fixed MIT-pthreads to compile with glibc 2.2 (needed for make dist).

  • Fixed the FLOAT(X+1,X) is not converted to FLOAT(X+2,X). (This also affected DECIMAL, DOUBLE and REAL types)

  • Fixed the result from IF() is case in-sensitive if the second and third arguments are case sensitive.

  • Fixed core dump problem on OSF/1 in gethostbyname_r.

  • Fixed that underflowed decimal fields are not zero filled.

  • If we get an overflow when inserting '+11111' for DECIMAL(5,0) UNSIGNED columns, we will just drop the sign.

  • Fixed optimization bug with ISNULL(expression_which_cannot_be_null) and ISNULL(constant_expression).

  • Fixed host lookup bug in the glibc library that we used with the 3.23.50 Linux-x86 binaries.

D.4.10. Changes in release 3.23.50 (21 Apr 2002)

  • Fixed buffer overflow problem if someone specified a too long datadir parameter to mysqld

  • Add missing <row> tags for mysqldump XML output.

  • Fixed problem with crash-me and gcc 3.0.4.

  • Fixed that @@unknown_variable doesn't hang server.

  • Added @@VERSION as a synonym for VERSION().

  • SHOW VARIABLES LIKE 'xxx' is now case-insensitive.

  • Fixed timeout for GET_LOCK() on HP-UX with DCE threads.

  • Fixed memory allocation bug in the glibc library used to build Linux binaries, which caused mysqld to die in 'free()'.

  • Fixed SIGINT and SIGQUIT problems in mysql.

  • Fixed bug in character table converts when used with big ( > 64K) strings.

  • InnoDB now retains foreign key constraints through ALTER TABLE and CREATE/DROP INDEX.

  • InnoDB now allows foreign key constraints to be added through the ALTER TABLE syntax.

  • InnoDB tables can now be set to automatically grow in size (autoextend).

  • Our Linux RPMS and binaries are now compiled with gcc 3.0.4, which should make them a bit faster.

  • Fixed some buffer overflow problems when reading startup parameters.

  • Because of problems on shutdown we have now disabled named pipes on Windows by default. One can enable named pipes by starting mysqld with --enable-named-pipe.

  • Fixed bug when using WHERE key_column = 'J' or key_column='j'.

  • Fixed core-dump bug when using --log-bin with LOAD DATA INFILE without an active database.

  • Fixed bug in RENAME TABLE when used with lower_case_table_names=1 (default on Windows).

  • Fixed unlikely core-dump bug when using DROP TABLE on a table that was in use by a thread that also used queries on only temporary tables.

  • Fixed problem with SHOW CREATE TABLE and PRIMARY KEY when using 32 indexes.

  • Fixed that one can use SET PASSWORD for the anonymous user.

  • Fixed core dump bug when reading client groups from option files using mysql_options().

  • Memory leak (16 bytes per every corrupted table) closed.

  • Fixed binary builds to use --enable-local-infile.

  • Update source to work with new version of bison.

  • Updated shell scripts to now agree with new POSIX standard.

  • Fixed bug where DATE_FORMAT() returned empty string when used with GROUP BY.

D.4.11. Changes in release 3.23.49

  • Don't give warning for a statement that is only a comment; this is needed for mysqldump --disable-keys to work.

  • Fixed unlikely caching bug when doing a join without keys. In this case the last used field for a table always returned NULL.

  • Added options to make LOAD DATA LOCAL INFILE more secure.

  • MySQL binary release 3.23.48 for Linux contained a new glibc library, which has serious problems under high load and Red Hat 7.2. The 3.23.49 binary release doesn't have this problem.

  • Fixed shutdown problem on NT.

D.4.12. Changes in release 3.23.48 (07 Feb 2002)

  • Added --xml option to mysqldump for producing XML output.

  • Changed to use autoconf 2.52 (from autoconf 2.13)

  • Fixed bug in complicated join with const tables.

  • Added internal safety checks for InnoDB.

  • Some InnoDB variables were always shown in SHOW VARIABLES as OFF on high-byte-first systems (like SPARC).

  • Fixed problem with one thread using an InnoDB table and another thread doing an ALTER TABLE on the same table. Before that, mysqld could crash with an assertion failure in row0row.c, line 474.

  • Tuned the InnoDB SQL optimizer to favor index searches more often over table scans.

  • Fixed a performance problem with InnoDB tables when several large SELECT queries are run concurrently on a multiprocessor Linux computer. Large CPU-bound SELECT queries will now also generally run faster on all platforms.

  • If MySQL binlogging is used, InnoDB now prints after crash recovery the latest MySQL binlog name and the offset InnoDB was able to recover to. This is useful, for example, when resynchronizing a master and a slave database in replication.

  • Added better error messages to help in installation problems of InnoDB tables.

  • It is now possible to recover MySQL temporary tables that have become orphaned inside the InnoDB tablespace.

  • InnoDB now prevents a FOREIGN KEY declaration where the signedness is not the same in the referencing and referenced integer columns.

  • Calling SHOW CREATE TABLE or SHOW TABLE STATUS could cause memory corruption and make mysqld crash. Especially at risk was mysqldump, because it frequently calls SHOW CREATE TABLE.

  • If inserts to several tables containing an AUTO_INCREMENT column were wrapped inside one LOCK TABLES, InnoDB asserted in lock0lock.c.

  • In 3.23.47 we allowed several NULL values in a UNIQUE secondary index for an InnoDB table. But CHECK TABLE was not relaxed: it reports the table as corrupt. CHECK TABLE no longer complains in this situation.

  • SHOW GRANTS now shows REFERENCES instead of REFERENCE.

D.4.13. Changes in release 3.23.47 (27 Dec 2001)

  • Fixed bug when using the following construct: SELECT ... WHERE key=@var_name OR key=@var_name2

  • Restrict InnoDB keys to 500 bytes.

  • InnoDB now supports NULL in keys.

  • Fixed shutdown problem on HP-UX. (Introduced in 3.23.46)

  • Fixed core dump bug in replication when using SELECT RELEASE_LOCK().

  • Added new command: DO expression,[expression]

  • Added slave-skip-errors option.

  • Added statistics variables for all MySQL commands. (SHOW STATUS is now much longer.)

  • Fixed default values for InnoDB tables.

  • Fixed that GROUP BY expr DESC works.

  • Fixed bug when using t1 LEFT JOIN t2 ON t2.key=constant.

  • mysql_config now also works with binary (relocated) distributions.

D.4.14. Changes in release 3.23.46 (29 Nov 2001)

  • Fixed problem with aliased temporary table replication.

  • InnoDB and BDB tables will now use index when doing an ORDER BY on the whole table.

  • Fixed bug where one got an empty set instead of a DEADLOCK error when using BDB tables.

  • One can now kill ANALYZE, REPAIR, and OPTIMIZE TABLE when the thread is waiting to get a lock on the table.

  • Fixed race condition in ANALYZE TABLE.

  • Fixed bug when joining with caching (unlikely to happen).

  • Fixed race condition when using the binary log and INSERT DELAYED which could cause the binary log to have rows that were not yet written to MyISAM tables.

  • Changed caching of binary log to make replication slightly faster.

  • Fixed bug in replication on Mac OS X.

D.4.15. Changes in release 3.23.45 (22 Nov 2001)

  • (UPDATE|DELETE) ...WHERE MATCH bugfix.

  • shutdown should now work on Darwin (Mac OS X).

  • Fixed core dump when repairing corrupted packed MyISAM files.

  • --core-file now works on Solaris.

  • Fix a bug which could cause InnoDB to complain if it cannot find free blocks from the buffer cache during recovery.

  • Fixed bug in InnoDB insert buffer B-tree handling that could cause crashes.

  • Fixed bug in InnoDB lock timeout handling.

  • Fixed core dump bug in ALTER TABLE on a TEMPORARY InnoDB table.

  • Fixed bug in OPTIMIZE TABLE that reset index cardinality if it was up to date.

  • Fixed problem with t1 LEFT_JOIN t2 ... WHERE t2.date_column IS NULL when date_column was declared as NOT NULL.

  • Fixed bug with BDB tables and keys on BLOB columns.

  • Fixed bug in MERGE tables on OS with 32-bit file pointers.

  • Fixed bug in TIME_TO_SEC() when using negative values.

D.4.16. Changes in release 3.23.44 (31 Oct 2001)

  • Fixed Rows_examined count in slow query log.

  • Fixed bug when using a reference to an AVG() column in HAVING.

  • Fixed that date functions that require correct dates, like DAYOFYEAR(column), will return NULL for 0000-00-00 dates.

  • Fixed bug in const-propagation when comparing columns of different types. (SELECT * FROM date_col="2001-01-01" and date_col=time_col)

  • Fixed bug that caused error message Can't write, because of unique constraint with some GROUP BY queries.

  • Fixed problem with sjis character strings used within quoted table names.

  • Fixed core dump when using CREATE ... FULLTEXT keys with other storage engines than MyISAM.

  • Don't use signal() on Windows because this appears to not be 100% reliable.

  • Fixed bug when doing WHERE col_name=NULL on an indexed column that had NULL values.

  • Fixed bug when doing LEFT JOIN ... ON (col_name = constant) WHERE col_name = constant.

  • When using replications, aborted queries that contained % could cause a core dump.

  • TCP_NODELAY was not used on some systems. (Speed problem.)

  • Applied portability fixes for OS/2. (Patch by Yuri Dario.)

The following changes are for InnoDB tables:

  • Add missing InnoDB variables to SHOW VARIABLES.

  • Foreign keys checking is now done for InnoDB tables.

  • DROP DATABASE now works also for InnoDB tables.

  • InnoDB now supports datafiles and raw disk partitions bigger than 4 GB on those operating systems that have big files.

  • InnoDB calculates better table cardinality estimates for the MySQL optimizer.

  • Accent characters in the default character set latin1 are ordered according to the MySQL ordering.

    Note: if you are using latin1 and have inserted characters whose code is greater than 127 into an indexed CHAR column, you should run CHECK TABLE on your table when you upgrade to 3.23.44, and drop and reimport the table if CHECK TABLE reports an error!

  • A new my.cnf parameter, innodb_thread_concurrency, helps in performance tuning in heavily concurrent environments.

  • A new my.cnf parameter, innodb_fast_shutdown, speeds up server shutdown.

  • A new my.cnf parameter, innodb_force_recovery, helps to save your data in case the disk image of the database becomes corrupt.

  • innodb_monitor has been improved and a new innodb_table_monitor added.

  • Increased maximum key length from 500 to 7000 bytes.

  • Fixed a bug in replication of AUTO_INCREMENT columns with multiple-line inserts.

  • Fixed a bug when the case of letters changes in an update of an indexed secondary column.

  • Fixed a hang when there are > 24 datafiles.

  • Fixed a crash when MAX(col) is selected from an empty table, and col is not the first column in a multi-column index.

  • Fixed a bug in purge which could cause crashes.

D.4.17. Changes in release 3.23.43 (04 Oct 2001)

  • Fixed a bug in INSERT DELAYED and FLUSH TABLES introduced in 3.23.42.

  • Fixed unlikely bug, which returned non-matching rows, in SELECT with many tables and multi-column indexes and 'range' type.

  • Fixed an unlikely core dump bug when doing EXPLAIN SELECT when using many tables and ORDER BY.

  • Fixed bug in LOAD DATA FROM MASTER when using table with CHECKSUM=1.

  • Added unique error message when one gets a DEADLOCK during a transaction with BDB tables.

  • Fixed problem with BDB tables and UNIQUE columns defined as NULL.

  • Fixed problem with myisampack when using pre-space filled CHAR columns.

  • Applied patch from Yuri Dario for OS/2.

  • Fixed bug in --safe-user-create.

D.4.18. Changes in release 3.23.42 (08 Sep 2001)

  • Fixed problem when using LOCK TABLES and BDB tables.

  • Fixed problem with REPAIR TABLE on MyISAM tables with row lengths in the range from 65517 to 65520 bytes.

  • Fixed rare hang when doing mysqladmin shutdown when there was a lot of activity in other threads.

  • Fixed problem with INSERT DELAYED where delay thread could be hanging on upgrading locks with no apparent reason.

  • Fixed problem with myisampack and BLOB.

  • Fixed problem when one edited .MRG tables by hand. (Patch from Benjamin Pflugmann).

  • Enforce that all tables in a MERGE table come from the same database.

  • Fixed bug with LOAD DATA INFILE and transactional tables.

  • Fix bug when using INSERT DELAYED with wrong column definition.

  • Fixed core dump during REPAIR of some particularly broken tables.

  • Fixed bug in InnoDB and AUTO_INCREMENT columns.

  • Fixed bug in InnoDB and RENAME TABLE columns.

  • Fixed critical bug in InnoDB and BLOB columns. If you have used BLOB columns larger than 8000 bytes in an InnoDB table, it is necessary to dump the table with mysqldump, drop it and restore it from the dump.

  • Applied large patch for OS/2 from Yuri Dario.

  • Fixed problem with InnoDB when one could get the error Can't execute the given command... even when no transaction was active.

  • Applied some minor fixes that concern Gemini.

  • Use real arithmetic operations even in integer context if not all arguments are integers. (Fixes uncommon bug in some integer contexts).

  • Don't force everything to lowercase on Windows. (To fix problem with Windows and ALTER TABLE). Now --lower_case_names also works on Unix.

  • Fixed that automatic rollback is done when thread end doesn't lock other threads.

D.4.19. Changes in release 3.23.41 (11 Aug 2001)

  • Added --sql-mode=value[,value[,value]] option to mysqld. See 항4.1.1. 「mysqld 커멘드 라인 옵션」.

  • Fixed possible problem with shutdown on Solaris where the .pid file wasn't deleted.

  • InnoDB now supports < 4 GB rows. The former limit was 8000 bytes.

  • The doublewrite file flush method is used in InnoDB. It reduces the need for Unix fsync() calls to a fraction and improves performance on most Unix flavors.

  • You can now use the InnoDB Monitor to print a lot of InnoDB state information, including locks, to the standard output. This is useful in performance tuning.

  • Several bugs which could cause hangs in InnoDB have been fixed.

  • Split record_buffer to record_buffer and record_rnd_buffer. To make things compatible to previous MySQL versions, if record_rnd_buffer is not set, then it takes the value of record_buffer.

  • Fixed optimizing bug in ORDER BY where some ORDER BY parts where wrongly removed.

  • Fixed overflow bug with ALTER TABLE and MERGE tables.

  • Added prototypes for my_thread_init() and my_thread_end() to mysql_com.h

  • Added --safe-user-create option to mysqld.

  • Fixed bug in SELECT DISTINCT ... HAVING that caused error message Can't find record in #...

D.4.20. Changes in release 3.23.40

  • Fixed problem with --low-priority-updates and INSERT statements.

  • Fixed bug in slave thread when under some rare circumstances it could get 22 bytes ahead on the offset in the master.

  • Added slave_net_timeout for replication.

  • Fixed problem with UPDATE and BDB tables.

  • Fixed hard bug in BDB tables when using key parts.

  • Fixed problem when using GRANT FILE ON database.* ...; previously we added the DROP privilege for the database.

  • Fixed DELETE FROM tbl_name ... LIMIT 0 and UPDATE FROM tbl_name ... LIMIT 0, which acted as though the LIMIT clause was not present (they deleted or updated all selected rows).

  • CHECK TABLE now checks if an AUTO_INCREMENT column contains the value 0.

  • Sending a SIGHUP to mysqld will now only flush the logs, not reset the replication.

  • Fixed parser to allow floats of type 1.0e1 (no sign after e).

  • Option --force to myisamchk now also updates states.

  • Added option --warnings to mysqld. Now mysqld prints the error Aborted connection only if this option is used.

  • Fixed problem with SHOW CREATE TABLE when you didn't have a PRIMARY KEY.

  • Properly fixed the rename of innodb_unix_file_flush_method variable to innodb_flush_method.

  • Fixed bug when converting BIGINT UNSIGNED to DOUBLE. This caused a problem when doing comparisons with BIGINT values outside of the signed range.

  • Fixed bug in BDB tables when querying empty tables.

  • Fixed a bug when using COUNT(DISTINCT) with LEFT JOIN and there weren't any matching rows.

  • Removed all documentation referring to the GEMINI table type. GEMINI is not released under an Open Source license.

D.4.21. Changes in release 3.23.39 (12 Jun 2001)

  • The AUTO_INCREMENT sequence wasn't reset when dropping and adding an AUTO_INCREMENT column.

  • CREATE ... SELECT now creates non-unique indexes delayed.

  • Fixed problem where LOCK TABLES tbl_name READ followed by FLUSH TABLES put an exclusive lock on the table.

  • REAL @variable values were represented with only 2 digits when converted to strings.

  • Fixed problem that client ``hung'' when LOAD TABLE FROM MASTER failed.

  • myisamchk --fast --force will no longer repair tables that only had the open count wrong.

  • Added functions to handle symbolic links to make life easier in 4.0.

  • We are now using the -lcma thread library on HP-UX 10.20 so that MySQL will be more stable on HP-UX.

  • Fixed problem with IF() and number of decimals in the result.

  • Fixed date-part extraction functions to work with dates where day and/or month is 0.

  • Extended argument length in option files from 256 to 512 chars.

  • Fixed problem with shutdown when INSERT DELAYED was waiting for a LOCK TABLE.

  • Fixed core dump bug in InnoDB when tablespace was full.

  • Fixed problem with MERGE tables and big tables (> 4G) when using ORDER BY.

D.4.22. Changes in release 3.23.38 (09 May 2001)

  • Fixed a bug when SELECT from MERGE table sometimes results in incorrectly ordered rows.

  • Fixed a bug in REPLACE() when using the ujis character set.

  • Applied Sleepycat BDB patches 3.2.9.1 and 3.2.9.2.

  • Added --skip-stack-trace option to mysqld.

  • CREATE TEMPORARY now works with InnoDB tables.

  • InnoDB now promotes sub keys to whole keys.

  • Added option CONCURRENT to LOAD DATA.

  • Better error message when slave max_allowed_packet is too low to read a very long log event from the master.

  • Fixed bug when too many rows where removed when using SELECT DISTINCT ... HAVING.

  • SHOW CREATE TABLE now returns TEMPORARY for temporary tables.

  • Added Rows_examined to slow query log.

  • Fixed problems with function returning empty string when used together with a group function and a WHERE that didn't match any rows.

  • New program mysqlcheck.

  • Added database name to output for administrative commands like CHECK, REPAIR, OPTIMIZE.

  • Lots of portability fixes for InnoDB.

  • Changed optimizer so that queries like SELECT * FROM tbl_name,tbl_name2 ... ORDER BY key_part1 LIMIT row_count will use index on key_part1 instead of filesort.

  • Fixed bug when doing LOCK TABLE to_table WRITE,...; INSERT INTO to_table... SELECT ... when to_table was empty.

  • Fixed bug with LOCK TABLE and BDB tables.

D.4.23. Changes in release 3.23.37 (17 Apr 2001)

  • Fixed a bug when using MATCH() in HAVING clause.

  • Fixed a bug when using HEAP tables with LIKE.

  • Added --mysql-version option to safe_mysqld

  • Changed INNOBASE to InnoDB (because the INNOBASE name was already used). All configure options and mysqld start options now use innodb instead of innobase. This means that before upgrading to this version, you have to change any configuration files where you have used innobase options!

  • Fixed bug when using indexes on CHAR(255) NULL columns.

  • Slave thread will now be started even if master-host is not set, as long as server-id is set and valid master.info is present.

  • Partial updates (terminated with kill) are now logged with a special error code to the binary log. Slave will refuse to execute them if the error code indicates the update was terminated abnormally, and will have to be recovered with SET SQL_SLAVE_SKIP_COUNTER=1; SLAVE START after a manual sanity check/correction of data integrity.

  • Fixed bug that erroneously logged a drop of internal temporary table on thread termination to the binary log --- this bug affected replication.

  • Fixed a bug in REGEXP on 64-bit machines.

  • UPDATE and DELETE with WHERE unique_key_part IS NULL didn't update/delete all rows.

  • Disabled INSERT DELAYED for tables that support transactions.

  • Fixed bug when using date functions on TEXT/BLOB column with wrong date format.

  • UDFs now also work on Windows. (Patch by Ralph Mason.)

  • Fixed bug in ALTER TABLE and LOAD DATA INFILE that disabled key-sorting. These commands should now be faster in most cases.

  • Fixed performance bug where reopened tables (tables that had been waiting for FLUSH or REPAIR) would not use indexes for the next query.

  • Fixed problem with ALTER TABLE to InnoDB tables on FreeBSD.

  • Added mysqld variables myisam_max_sort_file_size and myisam_max_extra_sort_file_size.

  • Initialize signals early to avoid problem with signals in InnoDB.

  • Applied patch for the tis620 character set to make comparisons case-independent and to fix a bug in LIKE for this character set. Note: All tables that uses the tis620 character set must be fixed with myisamchk -r or REPAIR TABLE !

  • Added --skip-safemalloc option to mysqld.

D.4.24. Changes in release 3.23.36 (27 Mar 2001)

  • Fixed a bug that allowed use of database names containing a ‘. ＇ character. This fixes a serious security issue when mysqld is run as root.

  • Fixed bug when thread creation failed (could happen when doing a lot of connections in a short time).

  • Fixed some problems with FLUSH TABLES and TEMPORARY tables. (Problem with freeing the key cache and error Can't reopen table....)

  • Fixed a problem in InnoDB with other character sets than latin1 and another problem when using many columns.

  • Fixed bug that caused a core dump when using a very complex query involving DISTINCT and summary functions.

  • Added SET TRANSACTION ISOLATION LEVEL ...

  • Added SELECT ... FOR UPDATE.

  • Fixed bug where the number of affected rows was not returned when MySQL was compiled without transaction support.

  • Fixed a bug in UPDATE where keys weren't always used to find the rows to be updated.

  • Fixed a bug in CONCAT_WS() where it returned incorrect results.

  • Changed CREATE ... SELECT and INSERT ... SELECT to not allow concurrent inserts as this could make the binary log hard to repeat. (Concurrent inserts are enabled if you are not using the binary or update log.)

  • Changed some macros to be able to use fast mutex with glibc 2.2.

D.4.25. Changes in release 3.23.35 (15 Mar 2001)

  • Fixed newly introduced bug in ORDER BY.

  • Fixed wrong define CLIENT_TRANSACTIONS.

  • Fixed bug in SHOW VARIABLES when using INNOBASE tables.

  • Setting and using user variables in SELECT DISTINCT didn't work.

  • Tuned SHOW ANALYZE for small tables.

  • Fixed handling of arguments in the benchmark script run-all-tests.

D.4.26. Changes in release 3.23.34a

  • Added extra files to the distribution to allow INNOBASE support to be compiled.

D.4.27. Changes in release 3.23.34 (10 Mar 2001)

  • Added the INNOBASE storage engine and the BDB storage engine to the MySQL source distribution.

  • Updated the documentation about GEMINI tables.

  • Fixed a bug in INSERT DELAYED that caused threads to hang when inserting NULL into an AUTO_INCREMENT column.

  • Fixed a bug in CHECK TABLE / REPAIR TABLE that could cause a thread to hang.

  • REPLACE will not replace a row that conflicts with an AUTO_INCREMENT generated key.

  • mysqld now only sets CLIENT_TRANSACTIONS in mysql->server_capabilities if the server supports a transaction-safe storage engine.

  • Fixed LOAD DATA INFILE to allow numeric values to be read into ENUM and SET columns.

  • Improved error diagnostic for slave thread exit.

  • Fixed bug in ALTER TABLE ... ORDER BY.

  • Added max_user_connections variable to mysqld.

  • Limit query length for replication by max_allowed_packet, not the arbitrary limit of 4 MB.

  • Allow space around = in argument to --set-variable.

  • Fixed problem in automatic repair that could leave some threads in state Waiting for table.

  • SHOW CREATE TABLE now displays the UNION=() for MERGE tables.

  • ALTER TABLE now remembers the old UNION=() definition.

  • Fixed bug when replicating timestamps.

  • Fixed bug in bidirectional replication.

  • Fixed bug in the BDB storage engine that occurred when using an index on multi-part key where a key part may be NULL.

  • Fixed MAX() optimization on sub-key for BDB tables.

  • Fixed problem where garbage results were returned when using BDB tables and BLOB or TEXT fields when joining many tables.

  • Fixed a problem with BDB tables and TEXT columns.

  • Fixed bug when using a BLOB key where a const row wasn't found.

  • Fixed that mysqlbinlog writes the timestamp value for each query. This ensures that one gets same values for date functions like NOW() when using mysqlbinlog to pipe the queries to another server.

  • Allow --skip-gemini, --skip-bdb, and --skip-innodb options to be specified when invoking mysqld, even if these storage engines are not compiled in to mysqld.

  • One can now do GROUP BY ... DESC.

  • Fixed a deadlock in the SET code, when one ran SET @foo=bar, where bar is a column reference, an error was not properly generated.

D.4.28. Changes in release 3.23.33 (09 Feb 2001)

  • Fixed DNS lookups not to use the same mutex as the hostname cache. This will enable known hosts to be quickly resolved even if a DNS lookup takes a long time.

  • Added --character-sets-dir option to myisampack.

  • Removed warnings when running REPAIR TABLE ... EXTENDED.

  • Fixed a bug that caused a core dump when using GROUP BY on an alias, where the alias was the same as an existing column name.

  • Added SEQUENCE() as an example UDF function.

  • Changed mysql_install_db to use BINARY for CHAR columns in the privilege tables.

  • Changed TRUNCATE tbl_name to TRUNCATE TABLE tbl_name to use the same syntax as Oracle. Until 4.0 we will also allow TRUNCATE tbl_name to not crash old code.

  • Fixed ``no found rows'' bug in MyISAM tables when a BLOB was first part of a multi-part key.

  • Fixed bug where CASE didn't work with GROUP BY.

  • Added --sort-recover option to myisamchk.

  • myisamchk -S and OPTIMIZE TABLE now work on Windows.

  • Fixed bug when using DISTINCT on results from functions that referred to a group function, like:

    SELECT a, DISTINCT SEC_TO_TIME(SUM(a))
FROM tbl_name GROUP BY a, b;

  • Fixed buffer overrun in libmysqlclient library. Fixed bug in handling STOP event after ROTATE event in replication.

  • Fixed another buffer overrun in DROP DATABASE.

  • Added Table_locks_immediate and Table_locks_waited status variables.

  • Fixed bug in replication that broke slave server start with existing master.info. This fixes a bug introduced in 3.23.32.

  • Added SET SQL_SLAVE_SKIP_COUNTER=n command to recover from replication glitches without a full database copy.

  • Added max_binlog_size variable; the binary log will be rotated automatically when the size crosses the limit.

  • Added Last_Error, Last_Errno, and Slave_skip_counter variables to SHOW SLAVE STATUS.

  • Fixed bug in MASTER_POS_WAIT() function.

  • Execute core dump handler on SIGILL, and SIGBUS in addition to SIGSEGV.

  • On x86 Linux, print the current query and thread (connection) id, if available, in the core dump handler.

  • Fixed several timing bugs in the test suite.

  • Extended mysqltest to take care of the timing issues in the test suite.

  • ALTER TABLE can now be used to change the definition for a MERGE table.

  • Fixed creation of MERGE tables on Windows.

  • Portability fixes for OpenBSD and OS/2.

  • Added --temp-pool option to mysqld. Using this option will cause most temporary files created to use a small set of names, rather than a unique name for each new file. This is to work around a problem in the Linux kernel dealing with creating a bunch of new files with different names. With the old behavior, Linux seems to "leak" memory, as it's being allocated to the directory entry cache instead of the disk cache.

D.4.29. Changes in release 3.23.32 (22 Jan 2001: Production)

  • Changed code to get around compiler bug in Compaq C++ on OSF/1, that broke BACKUP, RESTORE, CHECK, REPAIR, and ANALYZE TABLE.

  • Added option FULL to SHOW COLUMNS. Now we show the privilege list for the columns only if this option is given.

  • Fixed bug in SHOW LOGS when there weren't any BDB logs.

  • Fixed a timing problem in replication that could delay sending an update to the client until a new update was done.

  • Don't convert field names when using mysql_list_fields(). This is to keep this code compatible with SHOW FIELDS.

  • MERGE tables didn't work on Windows.

  • Fixed problem with SET PASSWORD=... on Windows.

  • Added missing my_config.h to RPM distribution.

  • TRIM("foo" from "foo") didn't return an empty string.

  • Added --with-version-suffix option to configure.

  • Fixed core dump when client aborted connection without mysql_close().

  • Fixed a bug in RESTORE TABLE when trying to restore from a non-existent directory.

  • Fixed a bug which caused a core dump on the slave when replicating SET PASSWORD.

  • Added MASTER_POS_WAIT().

D.4.30. Changes in release 3.23.31 (17 Jan 2001)

  • The test suite now tests all reachable BDB interface code. During testing we found and fixed many errors in the interface code.

  • Using HAVING on an empty table could produce one result row when it shouldn't.

  • Fixed the MySQL RPM so it no longer depends on Perl5.

  • Fixed some problems with HEAP tables on Windows.

  • SHOW TABLE STATUS didn't show correct average row length for tables larger than 4G.

  • CHECK TABLE ... EXTENDED didn't check row links for fixed size tables.

  • Added option MEDIUM to CHECK TABLE.

  • Fixed problem when using DECIMAL() keys on negative numbers.

  • HOUR() (and some other TIME functions) on a CHAR column always returned NULL.

  • Fixed security bug in something (please upgrade if you are using an earlier MySQL 3.23 version).

  • Fixed buffer overflow bug when writing a certain error message.

  • Added usage of setrlimit() on Linux to get -O --open-files-limit=# to work on Linux.

  • Added bdb_version variable to mysqld.

  • Fixed bug when using expression of type:

    SELECT ... FROM t1 LEFT JOIN t2 ON (t1.a=t2.a) WHERE t1.a=t2.a

    In this case the test in the WHERE clause was wrongly optimized away.

  • Fixed bug in MyISAM when deleting keys with possible NULL values, but the first key-column was not a prefix-compressed text column.

  • Fixed mysql.server to read the [mysql.server] option file group rather than the [mysql_server] group.

  • Fixed safe_mysqld and mysql.server to also read the server option section.

  • Added Threads_created status variable to mysqld.

D.4.31. Changes in release 3.23.30 (04 Jan 2001)

  • Added SHOW OPEN TABLES command.

  • Fixed that myisamdump works against old mysqld servers.

  • Fixed myisamchk -k# so that it works again.

  • Fixed a problem with replication when the binary log file went over 2G on 32-bit systems.

  • LOCK TABLES will now automatically start a new transaction.

  • Changed BDB tables to not use internal subtransactions and reuse open files to get more speed.

  • Added --mysqld=# option to safe_mysqld.

  • Allow hex constants in the --fields-*-by and --lines-terminated-by options to mysqldump and mysqlimport. By Paul DuBois.

  • Added --safe-show-database option to mysqld.

  • Added have_bdb, have_gemini, have_innobase, have_raid and have_openssl to SHOW VARIABLES to make it easy to test for supported extensions.

  • Added --open-files-limit option to mysqld.

  • Changed --open-files option to --open-files-limit in safe_mysqld.

  • Fixed a bug where some rows were not found with HEAP tables that had many keys.

  • Fixed that --bdb-no-sync works.

  • Changed --bdb-recover to --bdb-no-recover as recover should be on by default.

  • Changed the default number of BDB locks to 10000.

  • Fixed a bug from 3.23.29 when allocating the shared structure needed for BDB tables.

  • Changed mysqld_multi.sh to use configure variables. Patch by Christopher McCrory.

  • Added fixing of include files for Solaris 2.8.

  • Fixed bug with --skip-networking on Debian Linux.

  • Fixed problem that some temporary files where reported as having the name UNOPENED in error messages.

  • Fixed bug when running two simultaneous SHOW LOGS queries.

D.4.32. Changes in release 3.23.29 (16 Dec 2000)

  • Configure updates for Tru64, large file support, and better TCP wrapper support. By Albert Chin-A-Young.

  • Fixed bug in <=> operator.

  • Fixed bug in REPLACE with BDB tables.

  • LPAD() and RPAD() will shorten the result string if it's longer than the length argument.

  • Added SHOW LOGS command.

  • Remove unused BDB logs on shutdown.

  • When creating a table, put PRIMARY keys first, followed by UNIQUE keys.

  • Fixed a bug in UPDATE involving multi-part keys where one specified all key parts both in the update and the WHERE part. In this case MySQL could try to update a record that didn't match the whole WHERE part.

  • Changed drop table to first drop the tables and then the .frm file.

  • Fixed a bug in the hostname cache which caused mysqld to report the hostname as '' in some error messages.

  • Fixed a bug with HEAP type tables; the variable max_heap_table_size wasn't used. Now either MAX_ROWS or max_heap_table_size can be used to limit the size of a HEAP type table.

  • Changed the default server-id to 1 for masters and 2 for slaves to make it easier to use the binary log.

  • Renamed bdb_lock_max variable to bdb_max_lock.

  • Added support for AUTO_INCREMENT on sub-fields for BDB tables.

  • Added ANALYZE of BDB tables.

  • In BDB tables, we now store the number of rows; this helps to optimize queries when we need an approximation of the number of rows.

  • If we get an error in a multi-row statement, we now only roll back the last statement, not the entire transaction.

  • If you do a ROLLBACK when you have updated a non-transactional table you will get an error as a warning.

  • Added --bdb-shared-data option to mysqld.

  • Added Slave_open_temp_tables status variable to mysqld

  • Added binlog_cache_size and max_binlog_cache_size variables to mysqld.

  • DROP TABLE, RENAME TABLE, CREATE INDEX and DROP INDEX are now transaction endpoints.

  • If you do a DROP DATABASE on a symbolically linked database, both the link and the original database is deleted.

  • Fixed DROP DATABASE to work on OS/2.

  • Fixed bug when doing a SELECT DISTINCT ... table1 LEFT JOIN table2 ... when table2 was empty.

  • Added --abort-slave-event-count and --disconnect-slave-event-count options to mysqld for debugging and testing of replication.

  • Fixed replication of temporary tables. Handles everything except slave server restart.

  • SHOW KEYS now shows whether key is FULLTEXT.

  • New script mysqld_multi. See 항4.8.3. 「mysqld_multi (복수의 MySQL 서버를 관리하는 프로그램)」.

  • Added new script, mysql-multi.server.sh. Thanks to Tim Bunce <Tim.Bunce@ig.co.uk> for modifying mysql.server to easily handle hosts running many mysqld processes.

  • safe_mysqld, mysql.server, and mysql_install_db have been modified to use mysql_print_defaults instead of various hacks to read the my.cnf files. In addition, the handling of various paths has been made more consistent with how mysqld handles them by default.

  • Automatically remove Berkeley DB transaction logs that no longer are in use.

  • Fixed bug with several FULLTEXT indexes in one table.

  • Added a warning if number of rows changes on REPAIR/OPTIMIZE.

  • Applied patches for OS/2 by Yuri Dario.

  • FLUSH TABLES tbl_name didn't always flush the index tree to disk properly.

  • --bootstrap is now run in a separate thread. This fixes a problem that caused mysql_install_db to core dump on some Linux machines.

  • Changed mi_create() to use less stack space.

  • Fixed bug with optimizer trying to over-optimize MATCH() when used with UNIQUE key.

  • Changed crash-me and the MySQL benchmarks to also work with FrontBase.

  • Allow RESTRICT and CASCADE after DROP TABLE to make porting easier.

  • Reset status variable which could cause problem if one used --slow-log.

  • Added connect_timeout variable to mysql and mysqladmin.

  • Added connect-timeout as an alias for timeout for option files read by mysql_options().

D.4.33. Changes in release 3.23.28 (22 Nov 2000: Gamma)

  • Added new options --pager[=...], --no-pager, --tee=... and --no-tee to the mysql client. The new corresponding interactive commands are pager, nopager, tee and notee. See 항4.9.2. 「mysql (커멘드 라인 툴)」, mysql --help and the interactive help for more information.

  • Fixed crash when automatic repair of MyISAM table failed.

  • Fixed a major performance bug in the table locking code when one constantly had a lot of SELECT, UPDATE and INSERT statements running. The symptom was that the UPDATE and INSERT queries were locked for a long time while new SELECT statements were executed before the updates.

  • When reading options_files with mysql_options() the return-found-rows option was ignored.

  • One can now specify interactive-timeout in the option file that is read by mysql_options(). This makes it possible to force programs that run for a long time (like mysqlhotcopy) to use the interactive_timeout time instead of the wait_timeout time.

  • Added to the slow query log the time and the user name for each logged query. If you are using --log-long-format then also queries that do not use an index are logged, even if the query takes less than long_query_time seconds.

  • Fixed a problem in LEFT JOIN which caused all columns in a reference table to be NULL.

  • Fixed a problem when using NATURAL JOIN without keys.

  • Fixed a bug when using a multi-part keys where the first part was of type TEXT or BLOB.

  • DROP of temporary tables wasn't stored in the update/binary log.

  • Fixed a bug where SELECT DISTINCT * ... LIMIT row_count only returned one row.

  • Fixed a bug in the assembler code in strstr() for SPARC and cleaned up the global.h header file to avoid a problem with bad aliasing with the compiler submitted with Red Hat 7.0. (Reported by Trond Eivind Glomsrød)

  • The --skip-networking option now works properly on NT.

  • Fixed a long outstanding bug in the ISAM tables when a row with a length of more than 65K was shortened by a single byte.

  • Fixed a bug in MyISAM when running multiple updating processes on the same table.

  • Allow one to use FLUSH TABLE tbl_name.

  • Added --replicate-ignore-table, --replicate-do-table, --replicate-wild-ignore-table, and --replicate-wild-do-table options to mysqld.

  • Changed all log files to use our own IO_CACHE mechanism instead of FILE to avoid OS problems when there are many files open.

  • Added --open-files and --timezone options to safe_mysqld.

  • Fixed a fatal bug in CREATE TEMPORARY TABLE ... SELECT ....

  • Fixed a problem with CREATE TABLE ... SELECT NULL.

  • Added variables large_file_support,net_read_timeout, net_write_timeout and query_buffer_size to SHOW VARIABLES.

  • Added status variables created_tmp_files and sort_merge_passes to SHOW STATUS.

  • Fixed a bug where we didn't allow an index name after the FOREIGN KEY definition.

  • Added TRUNCATE table_name as a synonym for DELETE FROM table_name.

  • Fixed a bug in a BDB key compare function when comparing part keys.

  • Added bdb_lock_max variable to mysqld.

  • Added more tests to the benchmark suite.

  • Fixed an overflow bug in the client code when using overly long database names.

  • mysql_connect() now aborts on Linux if the server doesn't answer in timeout seconds.

  • SLAVE START did not work if you started with --skip-slave-start and had not explicitly run CHANGE MASTER TO.

  • Fixed the output of SHOW MASTER STATUS to be consistent with SHOW SLAVE STATUS. (It now has no directory in the log name.)

  • Added PURGE MASTER LOGS TO.

  • Added SHOW MASTER LOGS.

  • Added --safemalloc-mem-limit option to mysqld to simulate memory shortage when compiled with the --with-debug=full option.

  • Fixed several core dumps in out-of-memory conditions.

  • SHOW SLAVE STATUS was using an uninitialized mutex if the slave had not been started yet.

  • Fixed bug in ELT() and MAKE_SET() when the query used a temporary table.

  • CHANGE MASTER TO without specifying MASTER_LOG_POS would set it to 0 instead of 4 and hit the magic number in the master binlog.

  • ALTER TABLE ... ORDER BY ... syntax added. This will create the new table with the rows in a specific order.

D.4.34. Changes in release 3.23.27 (24 Oct 2000)

  • Fixed a bug where the automatic repair of MyISAM tables sometimes failed when the datafile was corrupt.

  • Fixed a bug in SHOW CREATE when using AUTO_INCREMENT columns.

  • Changed BDB tables to use new compare function in Berkeley DB 3.2.3.

  • You can now use Unix sockets with MIT-pthreads.

  • Added the latin5 (turkish) character set.

  • Small portability fixes.

D.4.35. Changes in release 3.23.26 (18 Oct 2000)

  • Renamed FLUSH MASTER and FLUSH SLAVE to RESET MASTER and RESET SLAVE.

  • Fixed <> to work properly with NULL.

  • Fixed a problem with SUBSTRING_INDEX() and REPLACE(). (Patch by Alexander Igonitchev)

  • Fix CREATE TEMPORARY TABLE IF NOT EXISTS not to produce an error if the table exists.

  • If you don't create a PRIMARY KEY in a BDB table, a hidden PRIMARY KEY will be created.

  • Added read-only-key optimization to BDB tables.

  • LEFT JOIN in some cases preferred a full table scan when there was no WHERE clause.

  • When using --log-slow-queries, don't count the time waiting for a lock.

  • Fixed bug in lock code on Windows which could cause the key cache to report that the key file was crashed even if it was okay.

  • Automatic repair of MyISAM tables if you start mysqld with --myisam-recover.

  • Removed the TYPE= keyword from CHECK and REPAIR. Allow CHECK options to be combined. (You can still use TYPE=, but this usage is deprecated.)

  • Fixed mutex bug in the binary replication log --- long update queries could be read only in part by the slave if it did it at the wrong time, which was not fatal, but resulted in a performance-degrading reconnect and a scary message in the error log.

  • Changed the format of the binary log --- added magic number, server version, binlog version. Added the server ID and query error code for each query event.

  • Replication thread from the slave now will kill all the stale threads from the same server.

  • Long replication user names were not being handled properly.

  • Added --replicate-rewrite-db option to mysqld.

  • Added --skip-slave-start option to mysqld.

  • Updates that generated an error code (such as INSERT INTO foo(some_key) values (1),(1)) erroneously terminated the slave thread.

  • Added optimization of queries where DISTINCT is only used on columns from some of the tables.

  • Allow floating-point numbers where there is no sign after the exponent (like 1e1).

  • SHOW GRANTS didn't always show all column grants.

  • Added --default-extra-file=# option to all MySQL clients.

  • Columns referenced in INSERT statements now are initialized properly.

  • UPDATE didn't always work when used with a range on a timestamp that was part of the key that was used to find rows.

  • Fixed a bug in FULLTEXT index when inserting a NULL column.

  • Changed to use mkstemp() instead of tempnam(). Based on a patch from John Jones.

D.4.36. Changes in release 3.23.25 (29 Sep 2000)

  • Fixed that databasename works as second argument to mysqlhotcopy.

  • The values for the UMASK and UMASK_DIR environment variables now can be specified in octal by beginning the value with a zero.

  • Added RIGHT JOIN. This makes RIGHT a reserved word.

  • Added @@IDENTITY as a synonym for LAST_INSERT_ID(). (This is for MSSQL compatibility.)

  • Fixed a bug in myisamchk and REPAIR when using FULLTEXT index.

  • LOAD DATA INFILE now works with FIFOs. (Patch by Toni L. Harbaugh-Blackford.)

  • FLUSH LOGS broke replication if you specified a log name with an explicit extension as the value of the log-bin option.

  • Fixed a bug in MyISAM with packed multi-part keys.

  • Fixed crash when using CHECK TABLE on Windows.

  • Fixed a bug where FULLTEXT index always used the koi8_ukr character set.

  • Fixed privilege checking for CHECK TABLE.

  • The MyISAM repair/reindex code didn't use the --tmpdir option for its temporary files.

  • Added BACKUP TABLE and RESTORE TABLE.

  • Fixed core dump on CHANGE MASTER TO when the slave did not have the master to start with.

  • Fixed incorrect Time in the processlist for Connect of the slave thread.

  • The slave now logs when it connects to the master.

  • Fixed a core dump bug when doing FLUSH MASTER if you didn't specify a filename argument to --log-bin.

  • Added missing ha_berkeley.x files to the MySQL Windows distribution.

  • Fixed some mutex bugs in the log code that could cause thread blocks if new log files couldn't be created.

  • Added lock time and number of selected processed rows to slow query log.

  • Added --memlock option to mysqld to lock mysqld in memory on systems with the mlockall() call (as in Solaris).

  • HEAP tables didn't use keys properly. (Bug from 3.23.23.)

  • Added better support for MERGE tables (keys, mapping, creation, documentation...). See 항7.2. 「MERGE 테이블」.

  • Fixed bug in mysqldump from 3.23 which caused some CHAR columns not to be quoted.

  • Merged analyze, check, optimize and repair code.

  • OPTIMIZE TABLE is now mapped to REPAIR with statistics and sorting of the index tree. This means that for the moment it only works on MyISAM tables.

  • Added a pre-alloced block to root_malloc to get fewer mallocs.

  • Added a lot of new statistics variables.

  • Fixed ORDER BY bug with BDB tables.

  • Removed warning that mysqld couldn't remove the .pid file under Windows.

  • Changed --log-isam to log MyISAM tables instead of isam tables.

  • Fixed CHECK TABLE to work on Windows.

  • Added file mutexes to make pwrite() safe on Windows.

D.4.37. Changes in release 3.23.24 (08 Sep 2000)

  • Added created_tmp_disk_tables variable to mysqld.

  • To make it possible to reliably dump and restore tables with TIMESTAMP(X) columns, MySQL now reports columns with X other than 14 or 8 to be strings.

  • Changed sort order for latin1 as it was before MySQL Version 3.23.23. Any table that was created or modified with 3.23.22 must be repaired if it has CHAR columns that may contain characters with ASCII values greater than 128!

  • Fixed small memory leak introduced from 3.23.22 when creating a temporary table.

  • Fixed problem with BDB tables and reading on a unique (not primary) key.

  • Restored the win1251 character set (it's now only marked deprecated).

D.4.38. Changes in release 3.23.23 (01 Sep 2000)

  • Changed sort order for 'German'; all tables created with 'German' sortorder must be repaired with REPAIR TABLE or myisamchk before use!

  • Added --core-file option to mysqld to get a core file on Linux if mysqld dies on the SIGSEGV signal.

  • MySQL client mysql now starts with option --no-named-commands (-g) by default. This option can be disabled with --enable-named-commands (-G). This may cause incompatibility problems in some cases, for example, in SQL scripts that use named commands without a semicolon, etc.! Long format commands still work from the first line.

  • Fixed a problem when using many pending DROP TABLE statements at the same time.

  • Optimizer didn't use keys properly when using LEFT JOIN on an empty table.

  • Added shorter help text when invoking mysqld with incorrect options.

  • Fixed non-fatal free() bug in mysqlimport.

  • Fixed bug in MyISAM index handling of DECIMAL/NUMERIC keys.

  • Fixed a bug in concurrent insert in MyISAM tables. In some contexts, usage of MIN(key_part) or MAX(key_part) returned an empty set.

  • Updated mysqlhotcopy to use the new FLUSH TABLES table_list syntax. Only tables which are being backed up are flushed now.

  • Changed behavior of --enable-thread-safe-client so that both non-threaded (-lmysqlclient) and threaded (-lmysqlclient_r) libraries are built. Users who linked against a threaded -lmysqlclient will need to link against -lmysqlclient_r now.

  • Added atomic RENAME TABLE command.

  • Don't count NULL values in COUNT(DISTINCT ...).

  • Changed ALTER TABLE, LOAD DATA INFILE on empty tables and INSERT ... SELECT ... on empty tables to create non-unique indexes in a separate batch with sorting. This will make the above calls much faster when you have many indexes.

  • ALTER TABLE now logs the first used insert_id correctly.

  • Fixed crash when adding a default value to a BLOB column.

  • Fixed a bug with DATE_ADD/DATE_SUB where it returned a datetime instead of a date.

  • Fixed a problem with the thread cache which made some threads show up as ***DEAD*** in SHOW PROCESSLIST.

  • Fixed a lock in our thr_rwlock code, which could make selects that run at the same time as concurrent inserts crash. This only affects systems that don't have the pthread_rwlock_rdlock code.

  • When deleting rows with a non-unique key in a HEAP table, all rows weren't always deleted.

  • Fixed bug in range optimizer for HEAP tables for searches on a part index.

  • Fixed SELECT on part keys to work with BDB tables.

  • Fixed INSERT INTO bdb_table ... SELECT to work with BDB tables.

  • CHECK TABLE now updates key statistics for the table.

  • ANALYZE TABLE will now only update tables that have been changed since the last ANALYZE. Note that this is a new feature and tables will not be marked to be analysed until they are updated in any way with 3.23.23 or newer. For older tables, you have to do CHECK TABLE to update the key distribution.

  • Fixed some minor privilege problems with CHECK, ANALYZE, REPAIR and SHOW CREATE commands.

  • Added CHANGE MASTER TO statement.

  • Added FAST, QUICK EXTENDED check types to CHECK TABLES.

  • Changed myisamchk so that --fast and --check-only-changed are also honored with --sort-index and --analyze.

  • Fixed fatal bug in LOAD TABLE FROM MASTER that did not lock the table during index re-build.

  • LOAD DATA INFILE broke replication if the database was excluded from replication.

  • More variables in SHOW SLAVE STATUS and SHOW MASTER STATUS.

  • SLAVE STOP now will not return until the slave thread actually exits.

  • Full-text search via the MATCH() function and FULLTEXT index type (for MyISAM files). This makes FULLTEXT a reserved word.

D.4.39. Changes in release 3.23.22 (31 Jul 2000)

  • Fixed that lex_hash.h is created properly for each MySQL distribution.

  • Fixed that MASTER and COLLECTION are not reserved words.

  • The log generated by --slow-query-log didn't contain the whole queries.

  • Fixed that open transactions in BDB tables are rolled back if the connection is closed unexpectedly.

  • Added workaround for a bug in gcc 2.96 (intel) and gcc 2.9 (IA-64) in gen_lex_hash.c.

  • Fixed memory leak in the client library when using host= in the my.cnf file.

  • Optimized functions that manipulate the hours/minutes/seconds.

  • Fixed bug when comparing the result of DATE_ADD()/DATE_SUB() against a number.

  • Changed the meaning of -F, --fast for myisamchk. Added -C, --check-only-changed option to myisamchk.

  • Added ANALYZE tbl_name to update key statistics for tables.

  • Changed binary items 0x... to be regarded as integers by default.

  • Fix for SCO and SHOW PROCESSLIST.

  • Added auto-rehash on reconnect for the mysql client.

  • Fixed a newly introduced bug in MyISAM, where the index file couldn't get bigger than 64M.

  • Added SHOW MASTER STATUS and SHOW SLAVE STATUS.

D.4.40. Changes in release 3.23.21

  • Added mysql_character_set_name() function to the MySQL C API.

  • Made the update log ASCII 0 safe.

  • Added the mysql_config script.

  • Fixed problem when using < or > with a char column that was only partly indexed.

  • One would get a core dump if the log file was not readable by the MySQL user.

  • Changed mysqladmin to use CREATE DATABASE and DROP DATABASE statements instead of the old deprecated API calls.

  • Fixed chown warning in safe_mysqld.

  • Fixed a bug in ORDER BY that was introduced in 3.23.19.

  • Only optimize the DELETE FROM tbl_name to do a drop+create of the table if we are in AUTOCOMMIT mode (needed for BDB tables).

  • Added extra checks to avoid index corruption when the ISAM/MyISAM index files get full during an INSERT/UPDATE.

  • myisamchk didn't correctly update row checksum when used with -ro (this only gave a warning in subsequent runs).

  • Fixed bug in REPAIR TABLE so that it works with tables without indexes.

  • Fixed buffer overrun in DROP DATABASE.

  • LOAD TABLE FROM MASTER is sufficiently bug-free to announce it as a feature.

  • MATCH and AGAINST are now reserved words.

D.4.41. Changes in release 3.23.20

  • Fixed bug in 3.23.19; DELETE FROM tbl_name removed the .frm file.

  • Added SHOW CREATE TABLE.

D.4.42. Changes in release 3.23.19

  • Changed copyright for all files to GPL for the server code and utilities and to LGPL for the client libraries. See http://www.fsf.org/licenses/.

  • Fixed bug where all rows matching weren't updated on a MyISAM table when doing update based on key on a table with many keys and some key changed values.

  • The Linux MySQL RPMs and binaries are now statically linked with a linuxthread version that has faster mutex handling when used with MySQL.

  • ORDER BY can now use REF keys to find subsets of the rows that need to be sorted.

  • Changed name of print_defaults program to my_print_defaults to avoid name confusion.

  • Fixed NULLIF() to work as required by SQL-99.

  • Added net_read_timeout and net_write_timeout as startup parameters to mysqld.

  • Fixed bug that destroyed index when doing myisamchk --sort-records on a table with prefix compressed index.

  • Added pack_isam and myisampack to the standard MySQL distribution.

  • Added the syntax BEGIN WORK (the same as BEGIN).

  • Fixed core dump bug when using ORDER BY on a CONV() expression.

  • Added LOAD TABLE FROM MASTER.

  • Added FLUSH MASTER and FLUSH SLAVE.

  • Fixed big/little endian problem in the replication.

D.4.43. Changes in release 3.23.18

  • Fixed a problem from 3.23.17 when choosing character set on the client side.

  • Added FLUSH TABLES WITH READ LOCK to make a global lock suitable for making a copy of MySQL datafiles.

  • CREATE TABLE ... SELECT ... PROCEDURE now works.

  • Internal temporary tables will now use compressed index when using GROUP BY on VARCHAR/CHAR columns.

  • Fixed a problem when locking the same table with both a READ and a WRITE lock.

  • Fixed problem with myisamchk and RAID tables.

D.4.44. Changes in release 3.23.17

  • Fixed a bug in FIND_IN_SET() when the first argument was NULL.

  • Added table locks to Berkeley DB.

  • Fixed a bug with LEFT JOIN and ORDER BY where the first table had only one matching row.

  • Added 4 sample my.cnf example files in the support-files directory.

  • Fixed duplicated key problem when doing big GROUP BY operations. (This bug was probably introduced in 3.23.15.)

  • Changed syntax for INNER JOIN to match SQL-99.

  • Added NATURAL JOIN syntax.

  • A lot of fixes in the BDB interface.

  • Added handling of --no-defaults and --defaults-file to safe_mysqld.sh and mysql_install_db.sh.

  • Fixed bug in reading compressed tables with many threads.

  • Fixed that USE INDEX works with PRIMARY keys.

  • Added BEGIN statement to start a transaction in AUTOCOMMIT mode.

  • Added support for symbolic links for Windows.

  • Changed protocol to let client know if the server is in AUTOCOMMIT mode and if there is a pending transaction. If there is a pending transaction, the client library will give an error before reconnecting to the server to let the client know that the server did a rollback. The protocol is still backward-compatible with old clients.

  • KILL now works on a thread that is locked on a 'write' to a dead client.

  • Fixed memory leak in the replication slave thread.

  • Added new log-slave-updates option to mysqld, to allow daisy-chaining the slaves.

  • Fixed compile error on FreeBSD and other systems where pthread_t is not the same as int.

  • Fixed master shutdown aborting the slave thread.

  • Fixed a race condition in INSERT DELAYED code when doing ALTER TABLE.

  • Added deadlock detection sanity checks to INSERT DELAYED.

D.4.45. Changes in release 3.23.16

  • Added SLAVE START and SLAVE STOP statements.

  • Added TYPE=QUICK option to CHECK and to REPAIR.

  • Fixed bug in REPAIR TABLE when the table was in use by other threads.

  • Added a thread cache to make it possible to debug MySQL with gdb when one does a lot of reconnects. This will also improve systems where you can't use persistent connections.

  • Lots of fixes in the Berkeley DB interface.

  • UPDATE IGNORE will not abort if an update results in a DUPLICATE_KEY error.

  • Put CREATE TEMPORARY TABLE commands in the update log.

  • Fixed bug in handling of masked IP numbers in the privilege tables.

  • Fixed bug with delay_key_write tables and CHECK TABLE.

  • Added replicate-do-db and replicate-ignore-db options to mysqld, to restrict which databases get replicated.

  • Added SQL_LOG_BIN option.

D.4.46. Changes in release 3.23.15 (May 2000: Beta)

  • To start mysqld as root, you must now use the --user=root option.

  • Added interface to Berkeley DB. (This is not yet functional; play with it at your own risk!)

  • Replication between master and slaves.

  • Fixed bug that other threads could steal a lock when a thread had a lock on a table and did a FLUSH TABLES command.

  • Added the slow_launch_time variable and the Slow_launch_threads status variable to mysqld. These can be examined with mysqladmin variables and mysqladmin extended-status.

  • Added functions INET_NTOA() and INET_ATON().

  • The default type of IF() now depends on the second and third arguments and not only on the second argument.

  • Fixed case when myisamchk could go into a loop when trying to repair a crashed table.

  • Don't write INSERT DELAYED to update log if SQL_LOG_UPDATE=0.

  • Fixed problem with REPLACE on HEAP tables.

  • Added possible character sets and time zone to SHOW VARIABLES output.

  • Fixed bug in locking code that could result in locking problems with concurrent inserts under high load.

  • Fixed a problem with DELETE of many rows on a table with compressed keys where MySQL scanned the index to find the rows.

  • Fixed problem with CHECK on table with deleted keyblocks.

  • Fixed a bug in reconnect (at the client side) where it didn't free memory properly in some contexts.

  • Fixed problems in update log when using LAST_INSERT_ID() to update a table with an AUTO_INCREMENT key.

  • Added NULLIF() function.

  • Fixed bug when using LOAD DATA INFILE on a table with BLOB/TEXT columns.

  • Optimized MyISAM to be faster when inserting keys in sorted order.

  • EXPLAIN SELECT ... now also prints out whether MySQL needs to create a temporary table or use file sorting when resolving the SELECT.

  • Added optimization to skip ORDER BY parts where the part is a constant expression in the WHERE part. Indexes can now be used even if the ORDER BY doesn't match the index exactly, as long as all the unused index parts and all the extra ORDER BY columns are constants in the WHERE clause. See 항5.4.3. 「MySQL (으)로의 인덱스의 사용」.

  • UPDATE and DELETE on a whole unique key in the WHERE part are now faster than before.

  • Changed RAID_CHUNKSIZE to be in 1024-byte increments.

  • Fixed core dump in LOAD_FILE(NULL).

D.4.47. Changes in release 3.23.14

  • Added mysql_real_escape_string() function to the MySQL C API.

  • Fixed a bug in CONCAT() where one of the arguments was a function that returned a modified argument.

  • Fixed a critical bug in myisamchk, where it updated the header in the index file when one only checked the table. This confused the mysqld daemon if it updated the same table at the same time. Now the status in the index file is only updated if one uses --update-state. With older myisamchk versions you should use --read-only when only checking tables, if there is the slightest chance that the mysqld server is working on the table at the same time!

  • Fixed that DROP TABLE is logged in the update log.

  • Fixed problem when searching on DECIMAL() key field where the column data contained leading zeros.

  • Fix bug in myisamchk when the AUTO_INCREMENT column isn't the first key.

  • Allow DATETIME in ISO8601 format: 2000-03-12T12:00:00

  • Dynamic character sets. A mysqld binary can now handle many different character sets (you can choose which when starting mysqld).

  • Added command REPAIR TABLE.

  • Added mysql_thread_safe() function to the MySQL C API.

  • Added the UMASK_DIR environment variable.

  • Added CONNECTION_ID() function to return the client connection thread ID.

  • When using = on BLOB or VARCHAR BINARY keys, where only a part of the column was indexed, the whole column of the result row wasn't compared.

  • Fix for sjis character set and ORDER BY.

  • When running in ANSI mode, don't allow columns to be used that aren't in the GROUP BY part.

D.4.48. Changes in release 3.23.13

  • Fixed problem when doing locks on the same table more than 2 times in the same LOCK TABLE command; this fixed the problem one got when running the test-ATIS test with --fast or --check-only-changed.

  • Added SQL_BUFFER_RESULT option to SELECT.

  • Removed end space from double/float numbers in results from temporary tables.

  • Added CHECK TABLE command.

  • Added changes for MyISAM in 3.23.12 that didn't get into the source distribution because of CVS problems.

  • Fixed bug so that mysqladmin shutdown will wait for the local server to close down.

  • Fixed a possible endless loop when calculating timestamp.

  • Added print_defaults program to the .rpm files. Removed mysqlbug from the client .rpm file.

D.4.49. Changes in release 3.23.12 (07 Mar 2000)

  • Fixed bug in MyISAM involving REPLACE ... SELECT ... which could give a corrupted table.

  • Fixed bug in myisamchk where it incorrectly reset the AUTO_INCREMENT value.

  • LOTS of patches for Linux Alpha. MySQL now appears to be relatively stable on Alpha.

  • Changed DISTINCT on HEAP temporary tables to use hashed keys to quickly find duplicated rows. This mostly concerns queries of type SELECT DISTINCT ... GROUP BY .... This fixes a problem where not all duplicates were removed in queries of the above type. In addition, the new code is MUCH faster.

  • Added patches to make MySQL compile on Mac OS X.

  • Added IF NOT EXISTS clause to CREATE DATABASE.

  • Added --all-databases and --databases options to mysqldump to allow dumping of many databases at the same time.

  • Fixed bug in compressed DECIMAL() index in MyISAM tables.

  • Fixed bug when storing 0 into a timestamp.

  • When doing mysqladmin shutdown on a local connection, mysqladmin now waits until the PID file is gone before terminating.

  • Fixed core dump with some COUNT(DISTINCT ...) queries.

  • Fixed that myisamchk works properly with RAID tables.

  • Fixed problem with LEFT JOIN and key_field IS NULL.

  • Fixed bug in net_clear() which could give the error Aborted connection in the MySQL clients.

  • Added options USE INDEX (key_list) and IGNORE INDEX (key_list) as parameters in SELECT.

  • DELETE and RENAME should now work on RAID tables.

D.4.50. Changes in release 3.23.11

  • Allow the ALTER TABLE tbl_name ADD (field_list) syntax.

  • Fixed problem with optimizer that could sometimes use incorrect keys.

  • Fixed that GRANT/REVOKE ALL PRIVILEGES doesn't affect GRANT OPTION.

  • Removed extra ‘) ＇ from the output of SHOW GRANTS.

  • Fixed problem when storing numbers in timestamps.

  • Fix problem with timezones that have half hour offsets.

  • Allow the syntax UNIQUE INDEX in CREATE statements.

  • mysqlhotcopy - fast online hot-backup utility for local MySQL databases. By Tim Bunce.

  • New more secure mysqlaccess. Thanks to Steve Harvey for this.

  • Added --i-am-a-dummy and --safe-updates options to mysql.

  • Added select_limit and max_join_size variables to mysql.

  • Added SQL_MAX_JOIN_SIZE and SQL_SAFE_UPDATES options.

  • Added READ LOCAL lock that doesn't lock the table for concurrent inserts. (This is used by mysqldump.)

  • Changed that LOCK TABLES ... READ doesn't anymore allow concurrent inserts.

  • Added --skip-delay-key-write option to mysqld.

  • Fixed security problem in the protocol regarding password checking.

  • _rowid can now be used as an alias for an integer type unique indexed column.

  • Added back blocking of SIGPIPE when compiling with --thread-safe-clients to make things safe for old clients.

D.4.51. Changes in release 3.23.10

  • Fixed bug in 3.23.9 where memory wasn't properly freed when using LOCK TABLES.

D.4.52. Changes in release 3.23.9

  • Fixed problem that affected queries that did arithmetic on group functions.

  • Fixed problem with timestamps and INSERT DELAYED.

  • Fixed that date_col BETWEEN const_date AND const_date works.

  • Fixed problem when only changing a 0 to NULL in a table with BLOB/TEXT columns.

  • Fixed bug in range optimizer when using many key parts and or on the middle key parts: WHERE K1=1 and K3=2 and (K2=2 and K4=4 or K2=3 and K4=5)

  • Added source command to mysql to allow reading of batch files inside the mysql client. Original patch by Matthew Vanecek.

  • Fixed critical problem with the WITH GRANT OPTION option.

  • Don't give an unnecessary GRANT error when using tables from many databases in the same query.

  • Added VIO wrapper (needed for SSL support; by Andrei Errapart and Tõnu Samuel).

  • Fixed optimizer problem on SELECT when using many overlapping indexes. MySQL should now be able to choose keys even better when there are many keys to choose from.

  • Changed optimizer to prefer a range key instead of a ref key when the range key can uses more columns than the ref key (which only can use columns with =). For example, the following type of queries should now be faster: SELECT * from key_part_1=const and key_part_2 > const2

  • Fixed bug that a change of all VARCHAR columns to CHAR columns didn't change row type from dynamic to fixed.

  • Disabled floating-point exceptions for FreeBSD to fix core dump when doing SELECT FLOOR(POW(2,63)).

  • Renamed mysqld startup option from --delay-key-write to --delay-key-write-for-all-tables.

  • Added read-next-on-key to HEAP tables. This should fix all problems with HEAP tables when using non-UNIQUE keys.

  • Added option to print default arguments to all clients.

  • Added --log-slow-queries option to mysqld to log all queries that take a long time to a separate log file with a time indicating how long the query took.

  • Fixed core dump when doing WHERE key_col=RAND(...).

  • Fixed optimization bug in SELECT ... LEFT JOIN ... key_col IS NULL, when key_col could contain NULL values.

  • Fixed problem with 8-bit characters as separators in LOAD DATA INFILE.

D.4.53. Changes in release 3.23.8 (02 Jan 2000)

  • Fixed problem when handling indexfiles larger than 8G.

  • Added latest patches to MIT-pthreads for NetBSD.

  • Fixed problem with timezones that are < GMT - 11.

  • Fixed a bug when deleting packed keys in NISAM.

  • Fixed problem with ISAM when doing some ORDER BY ... DESC queries.

  • Fixed bug when doing a join on a text key which didn't cover the whole key.

  • Option --delay-key-write didn't enable delayed key writing.

  • Fixed update of TEXT column which involved only case changes.

  • Fixed that INSERT DELAYED doesn't update timestamps that are given.

  • Added function YEARWEEK() and options x, X, v and V to DATE_FORMAT().

  • Fixed problem with MAX(indexed_column) and HEAP tables.

  • Fixed problem with BLOB NULL keys and LIKE "prefix%".

  • Fixed problem with MyISAM and fixed-length rows < 5 bytes.

  • Fixed problem that could cause MySQL to touch freed memory when doing very complicated GROUP BY queries.

  • Fixed core dump if you got a crashed table where an ENUM field value was too big.

D.4.54. Changes in release 3.23.7 (10 Dec 1999)

  • Fixed workaround under Linux to avoid problems with pthread_mutex_timedwait, which is used with INSERT DELAYED. See 항2.6.2. 「Linux 의 주의 사항(모든 Linux 버젼)」.

  • Fixed that one will get a 'disk full' error message if one gets disk full when doing sorting (instead of waiting until we got more disk space).

  • Fixed a bug in MyISAM with keys > 250 characters.

  • In MyISAM one can now do an INSERT at the same time as other threads are reading from the table.

  • Added max_write_lock_count variable to mysqld to force a READ lock after a certain number of WRITE locks.

  • Inverted flag delay_key_write on show variables.

  • Renamed concurrency variable to thread_concurrency.

  • The following functions are now multi-byte-safe: LOCATE(substr,str), POSITION(substr IN str), LOCATE(substr,str,pos), INSTR(str,substr), LEFT(str,len), RIGHT(str,len), SUBSTRING(str,pos,len), SUBSTRING(str FROM pos FOR len), MID(str,pos,len), SUBSTRING(str,pos), SUBSTRING(str FROM pos), SUBSTRING_INDEX(str,delim,count), RTRIM(str), TRIM([[BOTH | TRAILING] [remstr] FROM] str), REPLACE(str,from_str,to_str), REVERSE(str), INSERT(str,pos,len,newstr), LCASE(str), LOWER(str), UCASE(str) and UPPER(str); patch by Wei He.

  • Fix core dump when releasing a lock from a non-existent table.

  • Remove locks on tables before starting to remove duplicates.

  • Added option FULL to SHOW PROCESSLIST.

  • Added option --verbose to mysqladmin.

  • Fixed problem when automatically converting HEAP to MyISAM.

  • Fixed bug in HEAP tables when doing insert + delete + insert + scan the table.

  • Fixed bugs on Alpha with REPLACE() and LOAD DATA INFILE.

  • Added interactive_timeout variable to mysqld.

  • Changed the argument to mysql_data_seek() from ulong to ulonglong.

D.4.55. Changes in release 3.23.6

  • Added -O lower_case_table_names={0|1} option to mysqld to allow users to force table names to lowercase.

  • Added SELECT ... INTO DUMPFILE.

  • Added --ansi option to mysqld to make some functions SQL-99 compatible.

  • Temporary table names now start with #sql.

  • Added quoting of identifiers with ` (" in --ansi mode).

  • Changed to use snprintf() when printing floats to avoid some buffer overflows on FreeBSD.

  • Made FLOOR() overflow safe on FreeBSD.

  • Added --quote-names option to mysqldump.

  • Fixed bug that one could make a part of a PRIMARY KEY NOT NULL.

  • Fixed encrypt() to be thread-safe and not reuse buffer.

  • Added mysql_odbc_escape_string() function to support big5 characters in MyODBC.

  • Rewrote the storage engine to use classes. This introduces a lot of new code, but will make table handling faster and better.

  • Added patch by Sasha for user-defined variables.

  • Changed that FLOAT and DOUBLE (without any length modifiers) no longer are fixed decimal point numbers.

  • Changed the meaning of FLOAT(X): Now this is the same as FLOAT if X <= 24 and a DOUBLE if 24 < X <= 53.

  • DECIMAL(X) is now an alias for DECIMAL(X,0) and DECIMAL is now an alias for DECIMAL(10,0). The same goes for NUMERIC.

  • Added option ROW_FORMAT={DEFAULT | DYNAMIC | FIXED | COMPRESSED} to CREATE_TABLE.

  • DELETE FROM table_name didn't work on temporary tables.

  • Changed function CHAR_LENGTH() to be multi-byte character safe.

  • Added function ORD(string).

D.4.56. Changes in release 3.23.5 (20 Oct 1999)

  • Fixed some Y2K problems in the new date handling in 3.23.

  • Fixed problem with SELECT DISTINCT ... ORDER BY RAND().

  • Added patches by Sergei A. Golubchik for text searching on the MyISAM level.

  • Fixed cache overflow problem when using full joins without keys.

  • Fixed some configure issues.

  • Some small changes to make parsing faster.

  • Adding a column after the last field with ALTER TABLE didn't work.

  • Fixed problem when using an AUTO_INCREMENT column in two keys

  • With MyISAM, you now can have an AUTO_INCREMENT column as a key sub part: CREATE TABLE foo (a INT NOT NULL AUTO_INCREMENT, b CHAR(5), PRIMARY KEY (b,a))

  • Fixed bug in MyISAM with packed char keys that could be NULL.

  • AS on field name with CREATE TABLE table_name SELECT ... didn't work.

  • Allow use of NATIONAL and NCHAR when defining character columns. This is the same as not using BINARY.

  • Don't allow NULL columns in a PRIMARY KEY (only in UNIQUE keys).

  • Clear LAST_INSERT_ID() if one uses this in ODBC: WHERE auto_increment_column IS NULL. This seems to fix some problems with Access.

  • SET SQL_AUTO_IS_NULL=0|1 now turns on/off the handling of searching after the last inserted row with WHERE auto_increment_column IS NULL.

  • Added new variable concurrency to mysqld for Solaris.

  • Added --relative option to mysqladmin to make extended-status more useful to monitor changes.

  • Fixed bug when using COUNT(DISTINCT ...) on an empty table.

  • Added support for the Chinese character set GBK.

  • Fixed problem with LOAD DATA INFILE and BLOB columns.

  • Added bit operator ~ (negation).

  • Fixed problem with UDF functions.

D.4.57. Changes in release 3.23.4 (28 Sep 1999)

  • Inserting a DATETIME into a TIME column no longer will try to store 'days' in it.

  • Fixed problem with storage of float/double on little endian machines. (This affected SUM().)

  • Added connect timeout on TCP/IP connections.

  • Fixed problem with LIKE "%" on an index that may have NULL values.

  • REVOKE ALL PRIVILEGES didn't revoke all privileges.

  • Allow creation of temporary tables with same name as the original table.

  • When granting a user a GRANT option for a database, he couldn't grant privileges to other users.

  • New command: SHOW GRANTS FOR user (by Sinisa).

  • New date_add syntax: date/datetime + INTERVAL # interval_type. By Joshua Chamas.

  • Fixed privilege check for LOAD DATA REPLACE.

  • Automatic fixing of broken include files on Solaris 2.7

  • Some configure issues to fix problems with big filesystem detection.

  • REGEXP is now case-insensitive if you use non-binary strings.

D.4.58. Changes in release 3.23.3

  • Added patches for MIT-pthreads on NetBSD.

  • Fixed range bug in MyISAM.

  • ASC is now the default again for ORDER BY.

  • Added LIMIT to UPDATE.

  • Added mysql_change_user() function to the MySQL C API.

  • Added character set to SHOW VARIABLES.

  • Added support of --[whitespace] comments.

  • Allow INSERT into tbl_name VALUES (), that is, you may now specify an empty value list to insert a row in which each column is set to its default value.

  • Changed SUBSTRING(text FROM pos) to conform to SQL-99. (Before this construct returned the rightmost pos characters.)

  • SUM() with GROUP BY returned 0 on some systems.

  • Changed output for SHOW TABLE STATUS.

  • Added DELAY_KEY_WRITE option to CREATE TABLE.

  • Allow AUTO_INCREMENT on any key part.

  • Fixed problem with YEAR(NOW()) and YEAR(CURDATE()).

  • Added CASE construct.

  • New function COALESCE().

D.4.59. Changes in release 3.23.2 (09 Aug 1999)

  • Fixed range optimizer bug: SELECT * FROM table_name WHERE key_part1 >= const AND (key_part2 = const OR key_part2 = const). The bug was that some rows could be duplicated in the result.

  • Running myisamchk without -a updated the index distribution incorrectly.

  • SET SQL_LOW_PRIORITY_UPDATES=1 was causing a parse error.

  • You can now update index columns that are used in the WHERE clause. UPDATE tbl_name SET KEY=KEY+1 WHERE KEY > 100

  • Date handling should now be a bit faster.

  • Added handling of fuzzy dates (dates where day or month is 0), such as '1999-01-00'.

  • Fixed optimization of SELECT ... WHERE key_part1=const1 AND key_part_2=const2 AND key_part1=const4 AND key_part2=const4; indextype should be range instead of ref.

  • Fixed egcs 1.1.2 optimizer bug (when using BLOB values) on Linux Alpha.

  • Fixed problem with LOCK TABLES combined with DELETE FROM table.

  • MyISAM tables now allow keys on NULL and BLOB/TEXT columns.

  • The following join is now much faster: SELECT ... FROM t1 LEFT JOIN t2 ON ... WHERE t2.not_null_column IS NULL.

  • ORDER BY and GROUP BY can be done on functions.

  • Changed handling of 'const_item' to allow handling of ORDER BY RAND().

  • Indexes are now used for WHERE key_column = function.

  • Indexes are now used for WHERE key_column = col_name even if the columns are not identically packed.

  • Indexes are now used for WHERE col_name IS NULL.

  • Changed heap tables to be stored in low_byte_first order (to make it easy to convert to MyISAM tables)

  • Automatic change of HEAP temporary tables to MyISAM tables in case of ``table is full'' errors.

  • Added --init-file=file_name option to mysqld.

  • Added COUNT(DISTINCT value, [value, ...]).

  • CREATE TEMPORARY TABLE now creates a temporary table, in its own namespace, that is automatically deleted if connection is dropped.

  • New reserved words (required for CASE): CASE, THEN, WHEN, ELSE and END.

  • New functions EXPORT_SET() and MD5().

  • Support for the GB2312 Chinese character set.

D.4.60. Changes in release 3.23.1

  • Fixed some compilation problems.

D.4.61. Changes in release 3.23.0 (05 Aug 1999: Alpha)

  • A new storage engine library (MyISAM) with a lot of new features. See 항7.1. 「MyISAM 테이블」.

  • You can create in-memory HEAP tables which are extremely fast for lookups.

  • Support for big files (63-bit) on OSs that support big files.

  • New function LOAD_FILE(filename) to get the contents of a file as a string value.

  • New operator <=> which will act as = but will return TRUE if both arguments are NULL. This is useful for comparing changes between tables.

  • Added the ODBC 3.0 EXTRACT(interval FROM datetime) function.

  • Columns defined as FLOAT(X) are not rounded on storage and may be in scientific notation (1.0 E+10) when retrieved.

  • REPLACE is now faster than before.

  • Changed LIKE character comparison to behave as =; This means that 'e' LIKE 'e' is now true. (If the line doesn't display correctly, the latter 'e' is a French 'e' with a dot above.)

  • SHOW TABLE STATUS returns a lot of information about the tables.

  • Added LIKE to the SHOW STATUS command.

  • Added Privileges column to SHOW COLUMNS.

  • Added Packed and Comment columns to SHOW INDEX.

  • Added comments to tables (with CREATE TABLE ... COMMENT "xxx").

  • Added UNIQUE, as in CREATE TABLE table_name (col INT not null UNIQUE)

  • New create syntax: CREATE TABLE table_name SELECT ...

  • New create syntax: CREATE TABLE IF NOT EXISTS ...

  • Allow creation of CHAR(0) columns.

  • DATE_FORMAT() now requires ‘% ＇ before any format character.

  • DELAYED is now a reserved word (sorry about that :( ).

  • An example procedure is added: analyse, file: sql_analyse.c. This will describe the data in your query. Try the following:

    SELECT ... FROM ...
WHERE ... PROCEDURE ANALYSE([max elements,[max memory]])

    This procedure is extremely useful when you want to check the data in your table!

  • BINARY cast to force a string to be compared in case-sensitive fashion.

  • Added --skip-show-database option to mysqld.

  • Check whether a row has changed in an UPDATE now also works with BLOB/TEXT columns.

  • Added the INNER join syntax. NOTE: This made INNER a reserved word!

  • Added support for netmasks to the hostname in the MySQL grant tables. You can specify a netmask using the IP/NETMASK syntax.

  • If you compare a NOT NULL DATE/DATETIME column with IS NULL, this is changed to a compare against 0 to satisfy some ODBC applications. (By <shreeve@uci.edu>.)

  • NULL IN (...) now returns NULL instead of 0. This will ensure that null_column NOT IN (...) doesn't match NULL values.

  • Fix storage of floating-point values in TIME columns.

  • Changed parsing of TIME strings to be more strict. Now the fractional second part is detected (and currently skipped). The following formats are supported:

    • [[DAYS] [H]H:]MM:]SS[.fraction]

    • [[[[[H]H]H]H]MM]SS[.fraction]

  • Detect (and ignore) fractional second part from DATETIME.

  • Added the LOW_PRIORITY attribute to LOAD DATA INFILE.

  • The default index name now uses the same case as the column name on which the index name is based.

  • Changed default number of connections to 100.

  • Use bigger buffers when using LOAD DATA INFILE.

  • DECIMAL(x,y) now works according to SQL-99.

  • Added aggregate UDF functions. Thanks to Andreas F. Bobak (<bobak@relog.ch>) for this!

  • LAST_INSERT_ID() is now updated for INSERT INTO ... SELECT.

  • Some small changes to the join table optimizer to make some joins faster.

  • SELECT DISTINCT is much faster; it uses the new UNIQUE functionality in MyISAM. One difference compared to MySQL Version 3.22 is that the output of DISTINCT is no longer sorted.

  • All C client API macros are now functions to make shared libraries more reliable. Because of this, you can no longer call mysql_num_fields() on a MYSQL object, you must use mysql_field_count() instead.

  • Added use of LIBWRAP; patch by Henning P. Schmiedehausen.

  • Don't allow AUTO_INCREMENT for other than numerical columns.

  • Using AUTO_INCREMENT will now automatically make the column NOT NULL.

  • Show NULL as the default value for AUTO_INCREMENT columns.

  • Added SQL_BIG_RESULT; SQL_SMALL_RESULT is now default.

  • Added a shared library RPM. This enhancement was contributed by David Fox (<dsfox@cogsci.ucsd.edu>).

  • Added --enable-large-files and --disable-large-files switches to configure. See configure.in for some systems where this is automatically turned off because of broken implementations.

  • Upgraded readline to 4.0.

  • New CREATE TABLE options: PACK_KEYS and CHECKSUM.

  • Added --default-table-type option to mysqld.


D.5. Changes in release 3.22.x (Old; discontinued)

The 3.22 version has faster and safer connect code than version 3.21, as well as a lot of new nice enhancements. As there aren't really any major changes, upgrading from 3.21 to 3.22 should be very easy and painless. See 항2.5.4. 「버젼 3.21 (으)로부터 3.22 에의 업그레이드」.

D.5.1. Changes in release 3.22.35

  • Fixed problem with STD().

  • Merged changes from the newest ISAM library from 3.23.

  • Fixed problem with INSERT DELAYED.

  • Fixed a bug core dump when using a LEFT JOIN/STRAIGHT_JOIN on a table with only one row.

D.5.2. Changes in release 3.22.34

  • Fixed problem with GROUP BY on TINYBLOB columns; this caused bugzilla to not show rows in some queries.

  • Had to do total recompile of the Windows binary version as VC++ didn't compile all relevant files for 3.22.33 :(

D.5.3. Changes in release 3.22.33

  • Fixed problems in Windows when locking tables with LOCK TABLE.

  • Quicker kill of SELECT DISTINCT queries.

D.5.4. Changes in release 3.22.32 (14 Feb 2000)

  • Fixed problem when storing numbers in timestamps.

  • Fix problem with timezones that have half hour offsets.

  • Added mysqlhotcopy, a fast online hot-backup utility for local MySQL databases. By Tim Bunce.

  • New more secure mysqlaccess. Thanks to Steve Harvey for this.

  • Fixed security problem in the protocol regarding password checking.

  • Fixed problem that affected queries that did arithmetic on GROUP functions.

  • Fixed a bug in the ISAM code when deleting rows on tables with packed indexes.

D.5.5. Changes in release 3.22.31

  • A few small fixes for the Windows version.

D.5.6. Changes in release 3.22.30

  • Fixed optimizer problem on SELECT when using many overlapping indexes.

  • Disabled floating-point exceptions for FreeBSD to fix core dump when doing SELECT FLOOR(POW(2,63)).

  • Added print of default arguments options to all clients.

  • Fixed critical problem with the WITH GRANT OPTION option.

  • Fixed non-critical Y2K problem when writing short date to log files.

D.5.7. Changes in release 3.22.29 (02 Jan 2000)

  • Upgraded the configure and include files to match the latest 3.23 version. This should increase portability and make it easier to build shared libraries.

  • Added latest patches to MIT-pthreads for NetBSD.

  • Fixed problem with timezones that are < GMT -11.

  • Fixed a bug when deleting packed keys in NISAM.

  • Fixed problem that could cause MySQL to touch freed memory when doing very complicated GROUP BY queries.

  • Fixed core dump if you got a crashed table where an ENUM field value was too big.

  • Added mysqlshutdown.exe and mysqlwatch.exe to the Windows distribution.

  • Fixed problem when doing ORDER BY on a reference key.

  • Fixed that INSERT DELAYED doesn't update timestamps that are given.

D.5.8. Changes in release 3.22.28 (20 Oct 1999)

  • Fixed problem with LEFT JOIN and COUNT() on a column which was declared NULL + and it had a DEFAULT value.

  • Fixed core dump problem when using CONCAT() in a WHERE clause.

  • Fixed problem with AVG() and STD() with NULL values.

D.5.9. Changes in release 3.22.27

  • Fixed prototype in my_ctype.h when using other character sets.

  • Some configure issues to fix problems with big filesystem detection.

  • Fixed problem when sorting on big BLOB columns.

  • ROUND() will now work on Windows.

D.5.10. Changes in release 3.22.26 (16 Sep 1999)

  • Fixed core dump with empty BLOB/TEXT column argument to REVERSE().

  • Extended /*! */ with version numbers.

  • Changed SUBSTRING(text FROM pos) to conform to SQL-99. (Before this construct returned the rightmost 'pos' characters.)

  • Fixed problem with LOCK TABLES combined with DELETE FROM table

  • Fixed problem that INSERT ... SELECT didn't use BIG_TABLES.

  • SET SQL_LOW_PRIORITY_UPDATES=# didn't work.

  • Password wasn't updated correctly if privileges didn't change on: GRANT ... IDENTIFIED BY

  • Fixed range optimizer bug in SELECT * FROM table_name WHERE key_part1 >= const AND (key_part2 = const OR key_part2 = const).

  • Fixed bug in compression key handling in ISAM.

D.5.11. Changes in release 3.22.25

  • Fixed some small problems with the installation.

D.5.12. Changes in release 3.22.24 (05 Jul 1999)

  • DATA is no longer a reserved word.

  • Fixed optimizer bug with tables with only one row.

  • Fixed bug when using LOCK TABLES table_name READ; FLUSH TABLES;

  • Applied some patches for HP-UX.

  • isamchk should now work on Windows.

  • Changed configure to not use big file handling on Linux as this crashes some Red Hat 6.0 systems

D.5.13. Changes in release 3.22.23 (08 Jun 1999)

  • Upgraded to use Autoconf 2.13, Automake 1.4 and libtool 1.3.2.

  • Better support for SCO in configure.

  • Added option --defaults-file=file_name to option file handling to force use of only one specific option file.

  • Extended CREATE syntax to ignore MySQL Version 3.23 keywords.

  • Fixed deadlock problem when using INSERT DELAYED on a table locked with LOCK TABLES.

  • Fixed deadlock problem when using DROP TABLE on a table that was locked by another thread.

  • Add logging of GRANT/REVOKE commands in the update log.

  • Fixed isamchk to detect a new error condition.

  • Fixed bug in NATURAL LEFT JOIN.

D.5.14. Changes in release 3.22.22 (30 Apr 1999)

  • Fixed problem in the C API when you called mysql_close() directly after mysql_init().

  • Better client error message when you can't open socket.

  • Fixed delayed_insert_thread counting when you couldn't create a new delayed_insert thread.

  • Fixed bug in CONCAT() with many arguments.

  • Added patches for DEC 3.2 and SCO.

  • Fixed path-bug when installing MySQL as a service on NT.

  • MySQL on Windows is now compiled with VC++ 6.0 instead of with VC++ 5.0.

  • New installation setup for MySQL on Windows.

D.5.15. Changes in release 3.22.21

  • Fixed problem with DELETE FROM TABLE when table was locked by another thread.

  • Fixed bug in LEFT JOIN involving empty tables.

  • Changed the mysql.db column from CHAR(32) to CHAR(60).

  • MODIFY and DELAYED are no longer reserved words.

  • Fixed a bug when storing days in a TIME column.

  • Fixed a problem with Host '...' is not allowed to connect to this MySQL server after one had inserted a new MySQL user with a GRANT command.

  • Changed to use TCP_NODELAY also on Linux (should give faster TCP/IP connections).

D.5.16. Changes in release 3.22.20 (18 Mar 1999)

  • Fixed STD() for big tables when result should be 0.

  • The update log didn't have newlines on some operating systems.

  • INSERT DELAYED had some garbage at end in the update log.

D.5.17. Changes in release 3.22.19 (Mar 1999: Production)

  • Fixed bug in mysql_install_db (from 3.22.17).

  • Changed default key cache size to 8M.

  • Fixed problem with queries that needed temporary tables with BLOB columns.

D.5.18. Changes in release 3.22.18

  • Fixes a fatal problem in 3.22.17 on Linux; after shutdown not all threads died properly.

  • Added option -O flush_time=# to mysqld. This is mostly useful on Windows and tells how often MySQL should close all unused tables and flush all updated tables to disk.

  • Fixed problem that a VARCHAR column compared with CHAR column didn't use keys efficiently.

D.5.19. Changes in release 3.22.17

  • Fixed a core dump problem when using --log-update and connecting without a default database.

  • Fixed some configure and portability problems.

  • Using LEFT JOIN on tables that had circular dependencies caused mysqld to hang forever.

D.5.20. Changes in release 3.22.16 (Feb 1999: Gamma)

  • mysqladmin processlist could kill the server if a new user logged in.

  • DELETE FROM tbl_name WHERE key_column=col_name didn't find any matching rows. Fixed.

  • DATE_ADD(column, ...) didn't work.

  • INSERT DELAYED could deadlock with status 'upgrading lock'

  • Extended ENCRYPT() to take longer salt strings than 2 characters.

  • longlong2str is now much faster than before. For Intel x86 platforms, this function is written in optimized assembler.

  • Added the MODIFY keyword to ALTER TABLE.

D.5.21. Changes in release 3.22.15

  • GRANT used with IDENTIFIED BY didn't take effect until privileges were flushed.

  • Name change of some variables in SHOW STATUS.

  • Fixed problem with ORDER BY with 'only index' optimization when there were multiple key definitions for a used column.

  • DATE and DATETIME columns are now up to 5 times faster than before.

  • INSERT DELAYED can be used to let the client do other things while the server inserts rows into a table.

  • LEFT JOIN USING (col1,col2) didn't work if one used it with tables from 2 different databases.

  • LOAD DATA LOCAL INFILE didn't work in the Unix version because of a missing file.

  • Fixed problems with VARCHAR/BLOB on very short rows (< 4 bytes); error 127 could occur when deleting rows.

  • Updating BLOB/TEXT through formulas didn't work for short (< 256 char) strings.

  • When you did a GRANT on a new host, mysqld could die on the first connect from this host.

  • Fixed bug when one used ORDER BY on column name that was the same name as an alias.

  • Added BENCHMARK(loop_count,expression) function to time expressions.

D.5.22. Changes in release 3.22.14

  • Allow empty arguments to mysqld to make it easier to start from shell scripts.

  • Setting a TIMESTAMP column to NULL didn't record the timestamp value in the update log.

  • Fixed lock handler bug when one did INSERT INTO TABLE ... SELECT ... GROUP BY.

  • Added a patch for localtime_r() on Windows so that it will no lonher crash if your date is > 2039, but instead will return a time of all zero.

  • Names for user-defined functions are no longer case-sensitive.

  • Added escape of ^Z (ASCII 26) to \Z as ^Z doesn't work with pipes on Windows.

  • mysql_fix_privileges adds a new column to the mysql.func to support aggregate UDF functions in future MySQL releases.

D.5.23. Changes in release 3.22.13

  • Saving NOW(), CURDATE() or CURTIME() directly in a column didn't work.

  • SELECT COUNT(*) ... LEFT JOIN ... didn't work with no WHERE part.

  • Updated config.guess to allow MySQL to configure on UnixWare 7.1.x.

  • Changed the implementation of pthread_cond() on the Windows version. get_lock() now correctly times out on Windows!

D.5.24. Changes in release 3.22.12

  • Fixed problem when using DATE_ADD() and DATE_SUB() in a WHERE clause.

  • You can now set the password for a user with the GRANT ... TO user IDENTIFIED BY 'password' syntax.

  • Fixed bug in GRANT checking with SELECT on many tables.

  • Added missing file mysql_fix_privilege_tables to the RPM distribution. This is not run by default because it relies on the client package.

  • Added option SQL_SMALL_RESULT to SELECT to force use of fast temporary tables when you know that the result set will be small.

  • Allow use of negative real numbers without a decimal point.

  • Day number is now adjusted to maximum days in month if the resulting month after DATE_ADD/DATE_SUB() doesn't have enough days.

  • Fix that GRANT compares columns in case-insensitive fashion.

  • Fixed a bug in sql_list.h that made ALTER TABLE dump core in some contexts.

  • The hostname in user@hostname can now include ‘. ＇ and ‘- ＇ without quotes in the context of the GRANT, REVOKE and SET PASSWORD FOR ... statements.

  • Fix for isamchk for tables which need big temporary files.

D.5.25. Changes in release 3.22.11

  • Important: You must run the mysql_fix_privilege_tables script when you upgrade to this version! This is needed because of the new GRANT system. If you don't do this, you will get Access denied when you try to use ALTER TABLE, CREATE INDEX, or DROP INDEX.

  • GRANT to allow/deny users table and column access.

  • Changed USER() to return a value in user@host format. Formerly it returned only user.

  • Changed the syntax for how to set PASSWORD for another user.

  • New command FLUSH STATUS that resets most status variables to zero.

  • New status variables: aborted_threads, aborted_connects.

  • New option variable: connection_timeout.

  • Added support for Thai sorting (by Pruet Boonma <pruet@ds90.intanon.nectec.or.th>).

  • Slovak and Japanese error messages.

  • Configuration and portability fixes.

  • Added option SET SQL_WARNINGS=1 to get a warning count also for simple (single-row) inserts.

  • MySQL now uses SIGTERM instead of SIGQUIT with shutdown to work better on FreeBSD.

  • Added option \G (print vertically) to mysql.

  • SELECT HIGH_PRIORITY ... killed mysqld.

  • IS NULL on a AUTO_INCREMENT column in a LEFT JOIN didn't work as expected.

  • New function MAKE_SET().

D.5.26. Changes in release 3.22.10

  • mysql_install_db no longer starts the MySQL server! You should start mysqld with safe_mysqld after installing it! The MySQL RPM will, however, start the server as before.

  • Added --bootstrap option to mysqld and recoded mysql_install_db to use it. This will make it easier to install MySQL with RPMs.

  • Changed +, - (sign and minus), *, /, %, ABS() and MOD() to be BIGINT aware (64-bit safe).

  • Fixed a bug in ALTER TABLE that caused mysqld to crash.

  • MySQL now always reports the conflicting key values when a duplicate key entry occurs. (Before this was only reported for INSERT.)

  • New syntax: INSERT INTO tbl_name SET col_name=value, col_name=value, ...

  • Most errors in the .err log are now prefixed with a time stamp.

  • Added option MYSQL_INIT_COMMAND to mysql_options() to make a query on connect or reconnect.

  • Added option MYSQL_READ_DEFAULT_FILE and MYSQL_READ_DEFAULT_GROUP to mysql_options() to read the following parameters from the MySQL option files: port, socket, compress, password, pipe, timeout, user, init-command, host and database.

  • Added maybe_null to the UDF structure.

  • Added option IGNORE to INSERT statements with many rows.

  • Fixed some problems with sorting of the koi8 character sets; users of koi8 must run isamchk -rq on each table that has an index on a CHAR or VARCHAR column.

  • New script mysql_setpermission, by Luuk de Boer. It allows easy creation of new users with permissions for specific databases.

  • Allow use of hexadecimal strings (0x...) when specifying a constant string (like in the column separators with LOAD DATA INFILE).

  • Ported to OS/2 (thanks to Antony T. Curtis <antony.curtis@olcs.net>).

  • Added more variables to SHOW STATUS and changed format of output to be like SHOW VARIABLES.

  • Added extended-status command to mysqladmin which will show the new status variables.

D.5.27. Changes in release 3.22.9

  • SET SQL_LOG_UPDATE=0 caused a lockup of the server.

  • New SQL command: FLUSH [ TABLES | HOSTS | LOGS | PRIVILEGES ] [, ...]

  • New SQL command: KILL thread_id.

  • Added casts and changed include files to make MySQL easier to compile on AIX and DEC OSF/1 4.x

  • Fixed conversion problem when using ALTER TABLE from a INT to a short CHAR() column.

  • Added SELECT HIGH_PRIORITY; this will get a lock for the SELECT even if there is a thread waiting for another SELECT to get a WRITE LOCK.

  • Moved wild_compare() to string class to be able to use LIKE on BLOB/TEXT columns with \0.

  • Added ESCAPE option to LIKE.

  • Added a lot more output to mysqladmin debug.

  • You can now start mysqld on Windows with the --flush option. This will flush all tables to disk after each update. This makes things much safer on the Windows platforms but also much slower.

D.5.28. Changes in release 3.22.8

  • Czech character sets should now work much better.

  • DATE_ADD() and DATE_SUB() didn't work with group functions.

  • mysql will now also try to reconnect on USE database commands.

  • Fix problem with ORDER BY and LEFT JOIN and const tables.

  • Fixed problem with ORDER BY if the first ORDER BY column was a key and the rest of the ORDER BY columns wasn't part of the key.

  • Fixed a big problem with OPTIMIZE TABLE.

  • MySQL clients on NT will now by default first try to connect with named pipes and after this with TCP/IP.

  • Fixed a problem with DROP TABLE and mysqladmin shutdown on Windows (a fatal bug from 3.22.6).

  • Fixed problems with TIME columns and negative strings.

  • Added an extra thread signal loop on shutdown to avoid some error messages from the client.

  • MySQL now uses the next available number as extension for the update log file.

  • Added patches for UNIXWARE 7.

D.5.29. Changes in release 3.22.7 (Sep 1998: Beta)

  • Added LIMIT clause for the DELETE statement.

  • You can now use the /*! ... */ syntax to hide MySQL-specific keywords when you write portable code. MySQL will parse the code inside the comments as if the surrounding /*! and */ comment characters didn't exist.

  • OPTIMIZE TABLE tbl_name can now be used to reclaim disk space after many deletes. Currently, this uses ALTER TABLE to regenerate the table, but in the future it will use an integrated isamchk for more speed.

  • Upgraded libtool to get the configure more portable.

  • Fixed slow UPDATE and DELETE operations when using DATETIME or DATE keys.

  • Changed optimizer to make it better at deciding when to do a full join and when using keys.

  • You can now use mysqladmin proc to display information about your own threads. Only users with the PROCESS privilege can get information about all threads. (In 4.0.2 one needs the SUPER privilege for this.)

  • Added handling of formats YYMMDD, YYYYMMDD, YYMMDDHHMMSS for numbers when using DATETIME and TIMESTAMP types. (Formerly these formats only worked with strings.)

  • Added connect option CLIENT_IGNORE_SPACE to allow use of spaces after function names and before ‘( ＇ (Powerbuilder requires this). This will make all function names reserved words.

  • Added the --log-long-format option to mysqld to enable timestamps and INSERT_IDs in the update log.

  • Added --where option to mysqldump (patch by Jim Faucette).

  • The lexical analyzer now uses ``perfect hashing'' for faster parsing of SQL statements.

D.5.30. Changes in release 3.22.6

  • Faster mysqldump.

  • For the LOAD DATA INFILE statement, you can now use the new LOCAL keyword to read the file from the client. mysqlimport will automatically use LOCAL when importing with the TCP/IP protocol.

  • Fixed small optimize problem when updating keys.

  • Changed makefiles to support shared libraries.

  • MySQL-NT can now use named pipes, which means that you can now use MySQL-NT without having to install TCP/IP.

D.5.31. Changes in release 3.22.5

  • All table lock handing is changed to avoid some very subtle deadlocks when using DROP TABLE, ALTER TABLE, DELETE FROM TABLE and mysqladmin flush-tables under heavy usage. Changed locking code to get better handling of locks of different types.

  • Updated DBI to 1.00 and DBD to 1.2.0.

  • Added a check that the error message file contains error messages suitable for the current version of mysqld. (To avoid errors if you accidentally try to use an old error message file.)

  • All count structures in the client (affected_rows(), insert_id(), ...) are now of type BIGINT to allow 64-bit values to be used. This required a minor change in the MySQL protocol which should affect only old clients when using tables with AUTO_INCREMENT values > 16M.

  • The return type of mysql_fetch_lengths() has changed from uint * to ulong *. This may give a warning for old clients but should work on most machines.

  • Change mysys and dbug libraries to allocate all thread variables in one struct. This makes it easier to make a threaded libmysql.dll library.

  • Use the result from gethostname() (instead of uname()) when constructing .pid file names.

  • New better compressed server/client protocol.

  • COUNT(), STD() and AVG() are extended to handle more than 4G rows.

  • You can now store values in the range -838:59:59 <= x <= 838:59:59 in a TIME column.

  • Warning: incompatible change!! If you set a TIME column to too short a value, MySQL now assumes the value is given as: [[[D ]HH:]MM:]SS instead of HH[:MM[:SS]].

  • TIME_TO_SEC() and SEC_TO_TIME() can now handle negative times and hours up to 32767.

  • Added new option SET SQL_LOG_UPDATE={0|1} to allow users with the PROCESS privilege to bypass the update log. (Modified patch from Sergey A Mukhin <violet@rosnet.net>.)

  • Fixed fatal bug in LPAD().

  • Initialize line buffer in mysql.cc to make BLOB reading from pipes safer.

  • Added -O max_connect_errors=# option to mysqld. Connect errors are now reset for each correct connection.

  • Increased the default value of max_allowed_packet to 1M in mysqld.

  • Added --low-priority-updates option to mysqld, to give table-modifying operations (INSERT, REPLACE, UPDATE, DELETE) lower priority than retrievals. You can now use {INSERT | REPLACE | UPDATE | DELETE} LOW_PRIORITY ... You can also use SET SQL_LOW_PRIORITY_UPDATES={0|1} to change the priority for one thread. One side effect is that LOW_PRIORITY is now a reserved word. :(

  • Add support for INSERT INTO table ... VALUES(...),(...),(...), to allow inserting multiple rows with a single statement.

  • INSERT INTO tbl_name is now also cached when used with LOCK TABLES. (Previously only INSERT ... SELECT and LOAD DATA INFILE were cached.)

  • Allow GROUP BY functions with HAVING:

    mysql> SELECT col FROM table GROUP BY col HAVING COUNT(*)>0;

  • mysqld will now ignore trailing ‘; ＇ characters in queries. This is to make it easier to migrate from some other SQL servers that require the trailing ‘; ＇.

  • Fix for corrupted fixed-format output generated by SELECT INTO OUTFILE.

  • Warning: incompatible change! Added Oracle GREATEST() and LEAST() functions. You must now use these instead of the MAX() and MIN() functions to get the largest/smallest value from a list of values. These can now handle REAL, BIGINT and string (CHAR or VARCHAR) values.

  • Warning: incompatible change! DAYOFWEEK() had offset 0 for Sunday. Changed the offset to 1.

  • Give an error for queries that mix GROUP BY columns and fields when there is no GROUP BY specification.

  • Added --vertical option to mysql, for printing results in vertical mode.

  • Index-only optimization; some queries are now resolved using only indexes. Until MySQL 4.0, this works only for numeric columns. See 항5.4.3. 「MySQL (으)로의 인덱스의 사용」.

  • Lots of new benchmarks.

  • A new C API chapter and lots of other improvements in the manual.

D.5.32. Changes in release 3.22.4

  • Added --tmpdir option to mysqld, for specifying the location of the temporary file directory.

  • MySQL now automatically changes a query from an ODBC client:

    SELECT ... FROM table WHERE auto_increment_column IS NULL

    to:

    SELECT ... FROM table WHERE auto_increment_column == LAST_INSERT_ID()

    This allows some ODBC programs (Delphi, Access) to retrieve the newly inserted row to fetch the AUTO_INCREMENT id.

  • DROP TABLE now waits for all users to free a table before deleting it.

  • Fixed small memory leak in the new connect protocol.

  • New functions BIN(),
OCT(), HEX() and
CONV() for converting between different
number bases.

  • Added function SUBSTRING() with 2 arguments.

  • If you created a table with a record length smaller than 5, you couldn't delete rows from the table.

  • Added optimization to remove const reference tables from ORDER BY and GROUP BY.

  • mysqld now automatically disables system locking on Linux and Windows, and for systems that use MIT-pthreads. You can force the use of locking with the --enable-external-locking option.

  • Added --console option to mysqld, to force a console window (for error messages) when using Windows.

  • Fixed table locks for Windows.

  • Allow ‘$ ＇ in identifiers.

  • Changed name of user-specific configuration file from my.cnf to .my.cnf (Unix only).

  • Added DATE_ADD() and DATE_SUB() functions.

D.5.33. Changes in release 3.22.3

  • Fixed a lock problem (bug in MySQL Version 3.22.1) when closing temporary tables.

  • Added missing mysql_ping() to the client library.

  • Added --compress option to all MySQL clients.

  • Changed byte to char in mysql.h and mysql_com.h.

D.5.34. Changes in release 3.22.2

  • Searching on multiple constant keys that matched more than 30% of the rows didn't always use the best possible key.

  • New functions <<, >>, RPAD() and LPAD().

  • You can now save default options (like passwords) in a configuration file (my.cnf).

  • Lots of small changes to get ORDER BY to work when no records are found when using fields that are not in GROUP BY (MySQL extension).

  • Added --chroot option to mysqld, to start mysqld in a chroot environment (by Nikki Chumakov <nikkic@cityline.ru>).

  • Trailing spaces are now ignored when comparing case-sensitive strings; this should fix some problems with ODBC and flag 512!

  • Fixed a core dump bug in the range optimizer.

  • Added --one-thread option to mysqld, for debugging with LinuxThreads (or glibc). (This replaces the -T32 flag)

  • Added DROP TABLE IF EXISTS to prevent an error from occurring if the table doesn't exist.

  • IF and EXISTS are now reserved words (they would have to be sooner or later).

  • Added lots of new options to mysqldump.

  • Server error messages are now in mysqld_error.h.

  • The server/client protocol now supports compression.

  • All bug fixes from MySQL Version 3.21.32.

D.5.35. Changes in release 3.22.1 (Jun 1998: Alpha)

  • Added new C API function mysql_ping().

  • Added new API functions mysql_init() and
mysql_options(). You now MUST call
mysql_init() before you call
mysql_real_connect(). You don't have to
call mysql_init() if you only use
mysql_connect().

  • Added mysql_options(...,MYSQL_OPT_CONNECT_TIMEOUT,...) so you can set a timeout for connecting to a server.

  • Added --timeout option to mysqladmin, as a test of mysql_options().

  • Added AFTER column and FIRST options to ALTER TABLE ... ADD columns. This makes it possible to add a new column at some specific location within a row in an existing table.

  • WEEK() now takes an optional argument to allow handling of weeks when the week starts on Monday (some European countries). By default, WEEK() assumes the week starts on Sunday.

  • TIME columns weren't stored properly (bug in MySQL Version 3.22.0).

  • UPDATE now returns information about how many rows were matched and updated, and how many ``warnings'' occurred when doing the update.

  • Fixed incorrect result from FORMAT(-100,2).

  • ENUM and SET columns were compared in binary (case-sensitive) fashion; changed to be case-insensitive.

D.5.36. Changes in release 3.22.0

  • New (backward-compatible) connect protocol that allows you to specify the database to use when connecting, to get much faster connections to a specific database.

    The mysql_real_connect() call is changed to:

    mysql_real_connect(MYSQL *mysql, const char *host, const char *user,
                   const char *passwd, const char *db, uint port,
                   const char *unix_socket, uint client_flag)

  • Each connection is handled by its own thread, rather than by the master accept() thread. This fixes permanently the telnet bug that was a topic on the mail list some time ago.

  • All TCP/IP connections are now checked with backward-resolution of the hostname to get better security. mysqld now has a local hostname resolver cache so connections should actually be faster than before, even with this feature.

  • A site automatically will be blocked from future connections if someone repeatedly connects with an ``improper header'' (like when one uses telnet).

  • You can now refer to tables in different databases with references of the form tbl_name@db_name or db_name.tbl_name. This makes it possible to give a user read access to some tables and write access to others simply by keeping them in different databases!

  • Added --user option to mysqld, to allow it to run as another Unix user (if it is started as the Unix root user).

  • Added caching of users and access rights (for faster access rights checking)

  • Normal users (not anonymous ones) can change their password with mysqladmin password 'new_password'. This uses encrypted passwords that are not logged in the normal MySQL log!

  • All important string functions are now coded in assembler for x86 Linux machines. This gives a speedup of 10% in many cases.

  • For tables that have many columns, the column names are now hashed for much faster column name lookup (this will speed up some benchmark tests a lot!)

  • Some benchmarks are changed to get better individual timing. (Some loops were so short that a specific test took < 2 seconds. The loops have been changed to take about 20 seconds to make it easier to compare different databases. A test that took 1-2 seconds before now takes 11-24 seconds, which is much better)

  • Re-arranged SELECT code to handle some very specific queries involving group functions (like COUNT(*)) without a GROUP BY but with HAVING. The following now works:

    mysql> SELECT COUNT(*) as C FROM table HAVING C > 1;

  • Changed the protocol for field functions to be faster and avoid some calls to malloc().

  • Added -T32 option to mysqld, for running all queries under the main thread. This makes it possible to debug mysqld under Linux with gdb!

  • Added optimization of not_null_column IS NULL (needed for some Access queries).

  • Allow STRAIGHT_JOIN to be used between two tables to force the optimizer to join them in a specific order.

  • String functions now return VARCHAR rather than CHAR and the column type is now VARCHAR for fields saved as VARCHAR. This should make the MyODBC driver better, but may break some old MySQL clients that don't handle FIELD_TYPE_VARCHAR the same way as FIELD_TYPE_CHAR.

  • CREATE INDEX and DROP INDEX are now implemented through ALTER TABLE. CREATE TABLE is still the recommended (fast) way to create indexes.

  • Added --set-variable option wait_timeout to mysqld.

  • Added time column to mysqladmin processlist to show how long a query has taken or how long a thread has slept.

  • Added lots of new variables to show variables and some new to show status.

  • Added new type YEAR. YEAR is stored in 1 byte with allowable values of 0, and 1901 to 2155.

  • Added new DATE type that is stored in 3 bytes rather than 4 bytes. All new tables are created with the new date type if you don't use the --old-protocol option to mysqld.

  • Fixed bug in record caches; for some queries, you could get Error from table handler: # on some operating systems.

  • Added --enable-assembler option to configure, for x86 machines (tested on Linux + gcc). This will enable assembler functions for the most important string functions for more speed!


D.6. Changes in release 3.21.x

Version 3.21 is quite old now, and should be avoided if possible. This information is kept here for historical purposes only.

D.6.1. Changes in release 3.21.33

  • Fixed problem when sending SIGHUP to mysqld; mysqld core dumped when starting from boot on some systems.

  • Fixed problem with losing a little memory for some connections.

  • DELETE FROM tbl_name without a WHERE condition is now done the long way when you use LOCK TABLES or if the table is in use, to avoid race conditions.

  • INSERT INTO TABLE (timestamp_column) VALUES (NULL); didn't set timestamp.

D.6.2. Changes in release 3.21.32

  • Fixed some possible race conditions when doing many reopen/close on the same tables under heavy load! This can happen if you execute mysqladmin refresh often. This could in some very rare cases corrupt the header of the index file and cause error 126 or 138.

  • Fixed fatal bug in refresh() when running with the --skip-external-locking option. There was a ``very small'' time gap after a mysqladmin refresh when a table could be corrupted if one thread updated a table while another thread did mysqladmin refresh and another thread started a new update ont the same table before the first thread had finished. A refresh (or --flush-tables) will now not return until all used tables are closed!

  • SELECT DISTINCT with a WHERE clause that didn't match any rows returned a row in some contexts (bug only in 3.21.31).

  • GROUP BY + ORDER BY returned one empty row when no rows where found.

  • Fixed a bug in the range optimizer that wrote Use_count: Wrong count for ... in the error log file.

D.6.3. Changes in release 3.21.31

  • Fixed a sign extension problem for the TINYINT type on Irix.

  • Fixed problem with LEFT("constant_string",function).

  • Fixed problem with FIND_IN_SET().

  • LEFT JOIN core dumped if the second table is used with a constant WHERE/ON expression that uniquely identifies one record.

  • Fixed problems with DATE_FORMAT() and incorrect dates. DATE_FORMAT() now ignores '%' to make it possible to extend it more easily in the future.

D.6.4. Changes in release 3.21.30

  • mysql now returns an exit code > 0 if the query returned an error.

  • Saving of command-line history to file in mysql client. By Tommy Larsen <tommy@mix.hive.no>.

  • Fixed problem with empty lines that were ignored in mysql.cc.

  • Save the pid of the signal handler thread in the pid file instead of the pid of the main thread.

  • Added patch by <tommy@valley.ne.jp> to support Japanese characters SJIS and UJIS.

  • Changed safe_mysqld to redirect startup messages to 'hostname'.err instead of 'hostname'.log to reclaim file space on mysqladmin refresh.

  • ENUM always had the first entry as default value.

  • ALTER TABLE wrote two entries to the update log.

  • sql_acc() now closes the mysql grant tables after a reload to save table space and memory.

  • Changed LOAD DATA to use less memory with tables and BLOB columns.

  • Sorting on a function which made a division / 0 produced a wrong set in some cases.

  • Fixed SELECT problem with LEFT() when using the czech character set.

  • Fixed problem in isamchk; it couldn't repair a packed table in a very unusual case.

  • SELECT statements with & or | (bit functions) failed on columns with NULL values.

  • When comparing a field = field, where one of the fields was a part key, only the length of the part key was compared.

D.6.5. Changes in release 3.21.29

  • LOCK TABLES + DELETE from tbl_name never removed locks properly.

  • Fixed problem when grouping on an OR function.

  • Fixed permission problem with umask() and creating new databases.

  • Fixed permission problem on result file with SELECT ... INTO OUTFILE ...

  • Fixed problem in range optimizer (core dump) for a very complex query.

  • Fixed problem when using MIN(integer) or MAX(integer) in GROUP BY.

  • Fixed bug on Alpha when using integer keys. (Other keys worked on Alpha.)

  • Fixed bug in WEEK("XXXX-xx-01").

D.6.6. Changes in release 3.21.28

  • Fixed socket permission (clients couldn't connect to Unix socket on Linux).

  • Fixed bug in record caches; for some queries, you could get Error from table handler: # on some operating systems.

D.6.7. Changes in release 3.21.27

  • Added user level lock functions GET_LOCK(string,timeout), RELEASE_LOCK(string).

  • Added Opened_tables to show status.

  • Changed connect timeout to 3 seconds to make it somewhat harder for crackers to kill mysqld through telnet + TCP/IP.

  • Fixed bug in range optimizer when using WHERE key_part_1 >= something AND key_part_2 <= something_else.

  • Changed configure for detection of FreeBSD 3.0 9803xx and above

  • WHERE with string_col_key = constant_string didn't always find all rows if the column had many values differing only with characters of the same sort value (like e and e with an accent).

  • Strings keys looked up with 'ref' were not compared in case-sensitive fashion.

  • Added umask() to make log files non-readable for normal users.

  • Ignore users with old (8-byte) password on startup if not using --old-protocol option to mysqld.

  • SELECT which matched all key fields returned the values in the case of the matched values, not of the found values. (Minor problem.)

D.6.8. Changes in release 3.21.26

  • FROM_DAYS(0) now returns "0000-00-00".

  • In DATE_FORMAT(), PM and AM were swapped for hours 00 and 12.

  • Extended the default maximum key size to 256.

  • Fixed bug when using BLOB/TEXT in GROUP BY with many tables.

  • An ENUM field that is not declared NOT NULL has NULL as the default value. (Previously, the default value was the first enumeration value.)

  • Fixed bug in the join optimizer code when using many part keys on the same key: INDEX (Organization,Surname(35),Initials(35)).

  • Added some tests to the table order optimizer to get some cases with SELECT ... FROM many_tables much faster.

  • Added a retry loop around accept() to possibly fix some problems on some Linux machines.

D.6.9. Changes in release 3.21.25

  • Changed typedef 'string' to typedef 'my_string' for better portability.

  • You can now kill threads that are waiting on a disk-full condition.

  • Fixed some problems with UDF functions.

  • Added long options to isamchk. Try isamchk --help.

  • Fixed a bug when using 8 bytes long (alpha); filesort() didn't work. Affects DISTINCT, ORDER BY and GROUP BY on 64-bit processors.

D.6.10. Changes in release 3.21.24

  • Dynamic loadable functions. Based on source from Alexis Mikhailov.

  • You couldn't delete from a table if no one had done a SELECT on the table.

  • Fixed problem with range optimizer with many OR operators on key parts inside each other.

  • Recoded MIN() and MAX() to work properly with strings and HAVING.

  • Changed default umask value for new files from 0664 to 0660.

  • Fixed problem with LEFT JOIN and constant expressions in the ON part.

  • Added Italian error messages from <brenno@dewinter.com>.

  • configure now works better on OSF/1 (tested on 4.0D).

  • Added hooks to allow LIKE optimization with international character support.

  • Upgraded DBI to 0.93.

D.6.11. Changes in release 3.21.23

  • The following symbols are now reserved words: TIME, DATE, TIMESTAMP, TEXT, BIT, ENUM, NO, ACTION, CHECK, YEAR, MONTH, DAY, HOUR, MINUTE, SECOND, STATUS, VARIABLES.

  • Setting a TIMESTAMP to NULL in LOAD DATA INFILE ... didn't set the current time for the TIMESTAMP.

  • Fix BETWEEN to recognize binary strings. Now BETWEEN is case-sensitive.

  • Added --skip-thread-priority option to mysqld, for systems where mysqld's thread scheduling doesn't work properly (BSDI 3.1).

  • Added ODBC functions DAYNAME() and MONTHNAME().

  • Added function TIME_FORMAT(). This works like DATE_FORMAT(), but takes a time string ('HH:MM:SS') as argument.

  • Fixed unlikely(?) key optimizer bug when using OR operators of key parts inside AND expressions.

  • Added variables command to mysqladmin.

  • A lot of small changes to the binary releases.

  • Fixed a bug in the new protocol from MySQL Version 3.21.20.

  • Changed ALTER TABLE to work with Windows (Windows can't rename open files). Also fixed a couple of small bugs in the Windows version.

  • All standard MySQL clients are now ported to MySQL for Windows.

  • MySQL can now be started as a service on NT.

D.6.12. Changes in release 3.21.22

  • Starting with this version, all MySQL distributions will be configured, compiled and tested with crash-me and the benchmarks on the following platforms: SunOS 5.6 sun4u, SunOS 5.5.1 sun4u, SunOS 4.14 sun4c, SunOS 5.6 i86pc, Irix 6.3 mips5k, HP-UX 10.20 hppa, AIX 4.2.1 ppc, OSF/1 V4.0 alpha, FreeBSD 2.2.2 i86pc and BSDI 3.1 i386.

  • Fix COUNT(*) problems when the WHERE clause didn't match any records. (Bug from 3.21.17.)

  • Removed that NULL = NULL is true. Now you must use IS NULL or IS NOT NULL to test whether a value is NULL. (This is according to SQL-99 but may break old applications that are ported from mSQL.) You can get the old behavior by compiling with -DmSQL_COMPLIANT.

  • Fixed bug that core dumped when using many LEFT OUTER JOIN clauses.

  • Fixed bug in ORDER BY on string formula with possible NULL values.

  • Fixed problem in range optimizer when using <= on sub index.

  • Added functions DAYOFYEAR(),
DAYOFMONTH(), MONTH(),
YEAR(), WEEK(),
QUARTER(), HOUR(),
MINUTE(), SECOND() and
FIND_IN_SET().

  • Added SHOW VARIABLES command.

  • Added support of ``long constant strings'' from SQL-99:

    mysql> SELECT 'first ' 'second';       -> 'first second'

  • Upgraded Msql-Mysql-modules to 1.1825.

  • Upgraded mysqlaccess to 2.02.

  • Fixed problem with Russian character set and LIKE.

  • Ported to OpenBSD 2.1.

  • New Dutch error messages.

D.6.13. Changes in release 3.21.21a

  • Configure changes for some operating systems.

D.6.14. Changes in release 3.21.21

  • Fixed optimizer bug when using WHERE data_field = date_field2 AND date_field2 = constant.

  • Added SHOW STATUS command.

  • Removed manual.ps from the source distribution to make it smaller.

D.6.15. Changes in release 3.21.20

  • Changed the maximum table name and column name lengths from 32 to 64.

  • Aliases can now be of ``any'' length.

  • Fixed mysqladmin stat to return the right number of queries.

  • Changed protocol (downward compatible) to mark if a column has the AUTO_INCREMENT attribute or is a TIMESTAMP. This is needed for the new Java driver.

  • Added Hebrew sorting order by Zeev Suraski.

  • Solaris 2.6: Fixed configure bugs and increased maximum table size from 2G to 4G.

D.6.16. Changes in release 3.21.19

  • Upgraded DBD to 1.1823. This version implements mysql_use_result in DBD-Mysql.

  • Benchmarks updated for empress (by Luuk).

  • Fixed a case of slow range searching.

  • Configure fixes (Docs directory).

  • Added function REVERSE() (by Zeev Suraski).

D.6.17. Changes in release 3.21.18

  • Issue error message if client C functions are called in wrong order.

  • Added automatic reconnect to the libmysql.c library. If a write command fails, an automatic reconnect is done.

  • Small sort sets no longer use temporary files.

  • Upgraded DBI to 0.91.

  • Fixed a couple of problems with LEFT OUTER JOIN.

  • Added CROSS JOIN syntax. CROSS is now a reserved word.

  • Recoded yacc/bison stack allocation to be even safer and to allow MySQL to handle even bigger expressions.

  • Fixed a couple of problems with the update log.

  • ORDER BY was slow when used with key ranges.

D.6.18. Changes in release 3.21.17

  • Changed documentation string of --with-unix-socket-path to avoid confusion.

  • Added ODBC and SQL-99 style LEFT OUTER JOIN.

  • The following are new reserved words: LEFT, NATURAL, USING.

  • The client library now uses the value of the environment variable MYSQL_HOST as the default host if it's defined.

  • SELECT col_name, SUM(expr) now returns NULL for col_name when there are matching rows.

  • Fixed problem with comparing binary strings and BLOB values with ASCII characters over 127.

  • Fixed lock problem: when freeing a read lock on a table with multiple read locks, a thread waiting for a write lock would have been given the lock. This shouldn't affect data integrity, but could possibly make mysqld restart if one thread was reading data that another thread modified.

  • LIMIT offset,count didn't work in INSERT ... SELECT.

  • Optimized key block caching. This will be quicker than the old algorithm when using bigger key caches.

D.6.19. Changes in release 3.21.16

  • Added ODBC 2.0 & 3.0 functions
POWER(), SPACE(),
COT(), DEGREES(),
RADIANS(), ROUND(2
arg) and TRUNCATE().

  • Warning: Incompatible change! LOCATE() parameters were swapped according to ODBC standard. Fixed.

  • Added function TIME_TO_SEC().

  • In some cases, default values were not used for NOT NULL fields.

  • Timestamp wasn't always updated properly in UPDATE SET ... statements.

  • Allow empty strings as default values for BLOB and TEXT, to be compatible with mysqldump.

D.6.20. Changes in release 3.21.15

  • Warning: Incompatible change! mysqlperl is now from Msql-Mysql-modules. This means that connect() now takes host, database, user, password arguments! The old version took host, database, password, user.

  • Allow DATE '1997-01-01', TIME '12:10:10' and TIMESTAMP '1997-01-01 12:10:10' formats required by SQL-99. Warning: Incompatible change! This has the unfortunate side-effect that you no longer can have columns named DATE, TIME or TIMESTAMP. :( Old columns can still be accessed through tablename.columnname!)

  • Changed Makefiles to hopefully work better with BSD systems. Also, manual.dvi is now included in the distribution to avoid having stupid make programs trying to rebuild it.

  • readline library upgraded to version 2.1.

  • A new sortorder german-1. That is a normal ISO-Latin1 with a german sort order.

  • Perl DBI/DBD is now included in the distribution. DBI is now the recommended way to connect to MySQL from Perl.

  • New portable benchmark suite with DBD, with test results from mSQL 2.0.3, MySQL, PostgreSQL 6.2.1 and Solid server 2.2.

  • crash-me is now included with the benchmarks; this is a Perl program designed to find as many limits as possible in an SQL server. Tested with mSQL, PostgreSQL, Solid and MySQL.

  • Fixed bug in range-optimizer that crashed MySQL on some queries.

  • Table and column name completion for mysql command-line tool, by Zeev Suraski and Andi Gutmans.

  • Added new command REPLACE that works like INSERT but replaces conflicting records with the new record. REPLACE INTO TABLE ... SELECT ... works also.

  • Added new commands CREATE DATABASE db_name and DROP DATABASE db_name.

  • Added RENAME option to ALTER TABLE: ALTER TABLE name RENAME TO new_name.

  • make_binary_distribution now includes libgcc.a in libmysqlclient.a. This should make linking work for people who don't have gcc.

  • Changed net_write() to my_net_write() because of a name conflict with Sybase.

  • New function DAYOFWEEK() compatible with ODBC.

  • Stack checking and bison memory overrun checking to make MySQL safer with weird queries.

D.6.21. Changes in release 3.21.14b

  • Fixed a couple of small configure problems on some platforms.

D.6.22. Changes in release 3.21.14a

  • Ported to SCO Openserver 5.0.4 with FSU Pthreads.

  • HP-UX 10.20 should work.

  • Added new function DATE_FORMAT().

  • Added NOT IN.

  • Added automatic removal of 'ODBC function conversions': {fn now() }

  • Handle ODBC 2.50.3 option flags.

  • Fixed comparison of DATE and TIME values with NULL.

  • Changed language name from germany to german to be consistent with the other language names.

  • Fixed sorting problem on functions returning a FLOAT. Previously, the values were converted to INT values before sorting.

  • Fixed slow sorting when sorting on key field when using key_column=constant.

  • Sorting on calculated DOUBLE values sorted on integer results instead.

  • mysql no longer requires a database argument.

  • Changed the place where HAVING should be. According to the SQL standards, it should be after GROUP BY but before ORDER BY. MySQL Version 3.20 incorrectly had it last.

  • Added Sybase command USE database to start using another database.

  • Added automatic adjusting of number of connections and table cache size if the maximum number of files that can be opened is less than needed. This should fix that mysqld doesn't crash even if you haven't done a ulimit -n 256 before starting mysqld.

  • Added lots of limit checks to make it safer when running with too little memory or when doing weird queries.

D.6.23. Changes in release 3.21.13

  • Added retry of interrupted reads and clearing of errno. This makes Linux systems much safer!

  • Fixed locking bug when using many aliases on the same table in the same SELECT.

  • Fixed bug with LIKE on number key.

  • New error message so you can check whether the connection was lost while the command was running or whether the connection was down from the start.

  • Added --table option to mysql to print in table format. Moved time and row information after query result. Added automatic reconnect of lost connections.

  • Added != as a synonym for <>.

  • Added function VERSION() to make easier logs.

  • New multi-user test tests/fork_test.pl to put some strain on the thread library.

D.6.24. Changes in release 3.21.12

  • Fixed ftruncate() call in MIT-pthreads. This made isamchk destroy the .ISM files on (Free)BSD 2.x systems.

  • Fixed broken __P_ patch in MIT-pthreads.

  • Many memory overrun checks. All string functions now return NULL if the returned string should be longer than max_allowed_packet bytes.

  • Changed the name of the INTERVAL type to ENUM, because INTERVAL is used in SQL-99.

  • In some cases, doing a JOIN + GROUP + INTO OUTFILE, the result wasn't grouped.

  • LIKE with '_' as last character didn't work. Fixed.

  • Added extended SQL-99 TRIM() function.

  • Added CURTIME().

  • Added ENCRYPT() function by Zeev Suraski.

  • Fixed better FOREIGN KEY syntax skipping. New reserved words: MATCH, FULL, PARTIAL.

  • mysqld now allows IP number and hostname for the --bind-address option.

  • Added SET CHARACTER SET cp1251_koi8 to enable conversions of data to and from the cp1251_koi8 character set.

  • Lots of changes for Windows 95 port. In theory, this version should now be easily portable to Windows 95.

  • Changed the CREATE COLUMN syntax of NOT NULL columns to be after the DEFAULT value, as specified in the SQL-99 standard. This will make mysqldump with NOT NULL and default values incompatible with MySQL Version 3.20.

  • Added many function name aliases so the functions can be used with ODBC or SQL-92 syntax.

  • Fixed syntax of ALTER TABLE tbl_name ALTER COLUMN col_name SET DEFAULT NULL.

  • Added CHAR and BIT as synonyms for CHAR(1).

  • Fixed core dump when updating as a user who has only SELECT privilege.

  • INSERT ... SELECT ... GROUP BY didn't work in some cases. An Invalid use of group function error occurred.

  • When using LIMIT, SELECT now always uses keys instead of record scan. This will give better performance on SELECT and a WHERE that matches many rows.

  • Added Russian error messages.

D.6.25. Changes in release 3.21.11

  • Configure changes.

  • MySQL now works with the new thread library on BSD/OS 3.0.

  • Added new group functions BIT_OR() and BIT_AND().

  • Added compatibility functions CHECK and REFERENCES. CHECK is now a reserved word.

  • Added ALL option to GRANT for better compatibility. (GRANT is still a dummy function.)

  • Added partly translated Dutch error messages.

  • Fixed bug in ORDER BY and GROUP BY with NULL columns.

  • Added function LAST_INSERT_ID() SQL function to retrieve last AUTO_INCREMENT value. This is intended for clients to ODBC that can't use the mysql_insert_id() API function, but can be used by any client.

  • Added --flush-logs option to mysqladmin.

  • Added command STATUS to mysql.

  • Fixed problem with ORDER BY/GROUP BY because of bug in gcc.

  • Fixed problem with INSERT ... SELECT ... GROUP BY.

D.6.26. Changes in release 3.21.10

  • New program mysqlaccess.

  • CREATE now supports all ODBC types and the mSQL TEXT type. All ODBC 2.5 functions are also supported (added REPEAT). This provides better portability.

  • Added text types TINYTEXT, TEXT, MEDIUMTEXT and LONGTEXT. These are actually BLOBtypes, but all searching is done in case-insensitive fashion.

  • All old BLOB fields are now TEXT fields. This only changes that all searching on strings is done in case-sensitive fashion. You must do an ALTER TABLE and change the datatype to BLOB if you want to have tests done in case-sensitive fashion.

  • Fixed some configure issues.

  • Made the locking code a bit safer. Fixed very unlikely deadlock situation.

  • Fixed a couple of bugs in the range optimizer. Now the new range benchmark test-select works.

D.6.27. Changes in release 3.21.9

  • Added --enable-unix-socket=pathname option to configure.

  • Fixed a couple of portability problems with include files.

  • Fixed bug in range calculation that could return empty set when searching on multiple key with only one entry (very rare).

  • Most things ported to FSU Pthreads, which should allow MySQL to run on SCO. See 항2.6.6.9. 「SCO 의 주의 사항」.

D.6.28. Changes in release 3.21.8

  • Works now in Solaris 2.6.

  • Added handling of calculation of SUM() functions. For example, you can now use SUM(column)/COUNT(column).

  • Added handling of trigometric functions:
PI(), ACOS(),
ASIN(), ATAN(),
COS(), SIN() and
TAN().

  • New languages: Norwegian, Norwegian-ny and Portuguese.

  • Fixed parameter bug in net_print() in procedure.cc.

  • Fixed a couple of memory leaks.

  • Now allow also the old SELECT ... INTO OUTFILE syntax.

  • Fixed bug with GROUP BY and SELECT on key with many values.

  • mysql_fetch_lengths() sometimes returned incorrect lengths when you used mysql_use_result(). This affected at least some cases of mysqldump --quick.

  • Fixed bug in optimization of WHERE const op field.

  • Fixed problem when sorting on NULL fields.

  • Fixed a couple of 64-bit (Alpha) problems.

  • Added --pid-file=# option to mysqld.

  • Added date formatting to FROM_UNIXTIME(), originally by Zeev Suraski.

  • Fixed bug in BETWEEN in range optimizer (did only test = of the first argument).

  • Added machine-dependent files for MIT-pthreads i386-SCO. There is probably more to do to get this to work on SCO 3.5.

D.6.29. Changes in release 3.21.7

  • Changed Makefile.am to take advantage of Automake 1.2.

  • Added the beginnings of a benchmark suite.

  • Added more secure password handling.

  • Added new client function mysql_errno(), to get the error number of the error message. This makes error checking in the client much easier. This makes the new server incompatible with the 3.20.x server when running without --old-protocol. The client code is backward-compatible. More information can be found in the README file!

  • Fixed some problems when using very long, illegal names.

D.6.30. Changes in release 3.21.6

  • Fixed more portability issues (incorrect sigwait and sigset defines).

  • configure should now be able to detect the last argument to accept().

D.6.31. Changes in release 3.21.5

  • Should now work with FreeBSD 3.0 if used with FreeBSD-3.0-libc_r-1.0.diff, which can be found at http://www.mysql.com/downloads/os-freebsd.html.

  • Added new -O tmp_table_size=# option to mysqld.

  • New function FROM_UNIXTIME(timestamp) which returns a date string in 'YYYY-MM-DD HH:MM:SS' format.

  • New function SEC_TO_TIME(seconds) which returns a string in 'HH:MM:SS' format.

  • New function SUBSTRING_INDEX(), originally by Zeev Suraski.

D.6.32. Changes in release 3.21.4

  • Should now configure and compile on OSF/1 4.0 with the DEC compiler.

  • Configuration and compilation on BSD/OS 3.0 works, but due to some bugs in BSD/OS 3.0, mysqld doesn't work on it yet.

  • Configuration and compilation on FreeBSD 3.0 works, but I couldn't get pthread_create to work.

D.6.33. Changes in release 3.21.3

  • Added reverse check lookup of hostnames to get better security.

  • Fixed some possible buffer overflows if filenames that are too long are used.

  • mysqld doesn't accept hostnames that start with digits followed by a '.', because the hostname may look like an IP number.

  • Added --skip-networking option to mysqld, to allow only socket connections. (This will not work with MIT-pthreads!)

  • Added check of too long table names for alias.

  • Added check if database name is okay.

  • Added check if too long table names.

  • Removed incorrect free() that killed the server on CREATE DATABASE or DROP DATABASE.

  • Changed some mysqld -O options to better names.

  • Added -O join_cache_size=# option to mysqld.

  • Added -O max_join_size=# option to mysqld, to be able to set a limit how big queries (in this case big = slow) one should be able to handle without specifying SET SQL_BIG_SELECTS=1. A # = is about 10 examined records. The default is ``unlimited''.

  • When comparing a TIME, DATE, DATETIME or TIMESTAMP column to a constant, the constant is converted to a time value before performing the comparison. This will make it easier to get ODBC (particularly Access97) to work with the above types. It should also make dates easier to use and the comparisons should be quicker than before.

  • Applied patch from Jochen Wiedmann that allows query() in mysqlperl to take a query with \0 in it.

  • Storing a timestamp with a 2-digit year (YYMMDD) didn't work.

  • Fix that timestamp wasn't automatically updated if set in an UPDATE clause.

  • Now the automatic timestamp field is the FIRST timestamp field.

  • SELECT * INTO OUTFILE, which didn't correctly if the outfile already existed.

  • mysql now shows the thread ID when starting or doing a reconnect.

  • Changed the default sort buffer size from 2M to 1M.

D.6.34. Changes in release 3.21.2

  • The range optimizer is coded, but only 85% tested. It can be enabled with --new, but it crashes core a lot yet...

  • More portable. Should compile on AIX and alpha-digital. At least the isam library should be relatively 64-bit clean.

  • New isamchk which can detect and fix more problems.

  • New options for isamlog.

  • Using new version of Automake.

  • Many small portability changes (from the AIX and alpha-digital port) Better checking of pthread(s) library.

  • czech error messages by <snajdr@pvt.net>.

  • Decreased size of some buffers to get fewer problems on systems with little memory. Also added more checks to handle ``out of memory'' problems.

  • mysqladmin: you can now do mysqladmin kill 5,6,7,8 to kill multiple threads.

  • When the maximum connection limit is reached, one extra connection by a user with the process_acl privilege is granted.

  • Added -O backlog=# option to mysqld.

  • Increased maximum packet size from 512K to 1024K for client.

  • Almost all of the function code is now tested in the internal test suite.

  • ALTER TABLE now returns warnings from field conversions.

  • Port changed to 3306 (got it reserved from ISI).

  • Added a fix for Visual FoxBase so that any schema name from a table specification is automatically removed.

  • New function ASCII().

  • Removed function BETWEEN(a,b,c). Use the standard SQL syntax instead: expr BETWEEN expr AND expr.

  • MySQL no longer has to use an extra temporary table when sorting on functions or SUM() functions.

  • Fixed bug that you couldn't use tbl_name.field_name in UPDATE.

  • Fixed SELECT DISTINCT when using 'hidden group'. For example:

    mysql> SELECT DISTINCT MOD(some_field,10) FROM test
    ->        GROUP BY some_field;

    Note: some_field is normally in the SELECT part. Standard SQL should require it.

D.6.35. Changes in release 3.21.0

  • New reserved words used: INTERVAL, EXPLAIN, READ, WRITE, BINARY.

  • Added ODBC function CHAR(num,...).

  • New operator IN. This uses a binary search to find a match.

  • New command LOCK TABLES tbl_name [AS alias] {READ|WRITE} ...

  • Added --log-update option to mysqld, to get a log suitable for incremental updates.

  • New command EXPLAIN SELECT ... to get information about how the optimizer will do the join.

  • For easier client code, the client should no longer use FIELD_TYPE_TINY_BLOB, FIELD_TYPE_MEDIUM_BLOB, FIELD_TYPE_LONG_BLOB or FIELD_TYPE_VAR_STRING (as previously returned by mysql_list_fields). You should instead only use FIELD_TYPE_BLOB or FIELD_TYPE_STRING. If you want exact types, you should use the command SHOW FIELDS.

  • Added varbinary syntax: 0x###### which can be used as a string (default) or a number.

  • FIELD_TYPE_CHAR is renamed to FIELD_TYPE_TINY.

  • Changed all fields to C++ classes.

  • Removed FORM struct.

  • Fields with DEFAULT values no longer need to be NOT NULL.

  • New field types:

    • ENUM

      A string which can take only a couple of defined values. The value is stored as a 1-3 byte number that is mapped automatically to a string. This is sorted according to string positions!

    • SET

      A string which may have one or many string values separated with ','. The string is stored as a 1-, 2-, 3-, 4- or 8-byte number where each bit stands for a specific set member. This is sorted according to the unsigned value of the stored packed number.

  • Now all function calculation is done with double or long long. This will provide the full 64-bit range with bit functions and fix some conversions that previously could result in precision losses. One should avoid using unsigned long long columns with full 64-bit range (numbers bigger than 9223372036854775807) because calculations are done with signed long long.

  • ORDER BY will now put NULL field values first. GROUP BY will also work with NULL values.

  • Full WHERE with expressions.

  • New range optimizer that can resolve ranges when some keypart prefix is constant. Example:

    mysql> SELECT * FROM tbl_name
    ->          WHERE key_part_1="customer"
    ->          AND key_part_2>=10 AND key_part_2<=10;


D.7. Changes in release 3.20.x

Version 3.20 is quite old now, and should be avoided if possible. This information is kept here for historical purposes only.

Changes from 3.20.18 to 3.20.32b are not documented here because the 3.21 release branched here. And the relevant changes are also documented as changes to the 3.21 version.

D.7.1. Changes in release 3.20.18

  • Added -p# (remove # directories from path) to isamlog. All files are written with a relative path from the database directory Now mysqld shouldn't crash on shutdown when using the --log-isam option.

  • New mysqlperl version. It is now compatible with msqlperl-0.63.

  • New DBD module available.

  • Added group function STD() (standard deviation).

  • The mysqld server is now compiled by default without debugging information. This will make the daemon smaller and faster.

  • Now one usually only has to specify the --basedir option to mysqld. All other paths are relative in a normal installation.

  • BLOB columns sometimes contained garbage when used with a SELECT on more than one table and ORDER BY.

  • Fixed that calculations that are not in GROUP BY work as expected (SQL-99 extension). Example:

    mysql> SELECT id,id+1 FROM table GROUP BY id;

  • The test of using MYSQL_PWD was reversed. Now MYSQL_PWD is enabled as default in the default release.

  • Fixed conversion bug which caused mysqld to core dump with Arithmetic error on SPARC-386.

  • Added --unbuffered option to mysql, for new mysqlaccess.

  • When using overlapping (unnecessary) keys and join over many tables, the optimizer could get confused and return 0 records.

D.7.2. Changes in release 3.20.17

  • You can now use BLOB columns and the functions IS NULL and IS NOT NULL in the WHERE clause.

  • All communication packets and row buffers are now allocated dynamically on demand. The default value of max_allowed_packet is now 64K for the server and 512K for the client. This is mainly used to catch incorrect packets that could trash all memory. The server limit may be changed when it is started.

  • Changed stack usage to use less memory.

  • Changed safe_mysqld to check for running daemon.

  • The ELT() function is renamed to
FIELD(). The new ELT()
function returns a value based on an index:
FIELD() is the inverse of
ELT() Example:
ELT(2,"A","B","C") returns
"B".
FIELD("B","A","B","C") returns
2.

  • COUNT(field), where field could have a NULL value, now works.

  • A couple of bugs fixed in SELECT ... GROUP BY.

  • Fixed memory overrun bug in WHERE with many unoptimizable brace levels.

  • Fixed some small bugs in the grant code.

  • If hostname isn't found by get_hostname, only the IP is checked. Previously, you got Access denied.

  • Inserts of timestamps with values didn't always work.

  • INSERT INTO ... SELECT ... WHERE could give the error Duplicated field.

  • Added some tests to safe_mysqld to make it ``safer''.

  • LIKE was case-sensitive in some places and case-insensitive in others. Now LIKE is always case-insensitive.

  • mysql.cc: Allow '#' anywhere on the line.

  • New command SET SQL_SELECT_LIMIT=#. See the FAQ for more details.

  • New version of the mysqlaccess script.

  • Change FROM_DAYS() and WEEKDAY() to also take a full TIMESTAMP or DATETIME as argument. Before they only took a number of type YYYYMMDD or YYMMDD.

  • Added new function UNIX_TIMESTAMP(timestamp_column).

D.7.3. Changes in release 3.20.16

  • More changes in MIT-pthreads to get them safer. Fixed also some link bugs at least in SunOS.

  • Changed mysqld to work around a bug in MIT-pthreads. This makes multiple small SELECT operations 20 times faster. Now lock_test.pl should work.

  • Added mysql_FetchHash(handle) to mysqlperl.

  • The mysqlbug script is now distributed built to allow for reporting bugs that appear during the build with it.

  • Changed libmysql.c to prefer getpwuid() instead of cuserid().

  • Fixed bug in SELECT optimizer when using many tables with the same column used as key to different tables.

  • Added new latin2 and Russian KOI8 character tables.

  • Added support for a dummy GRANT command to satisfy Powerbuilder.

D.7.4. Changes in release 3.20.15

  • Fixed fatal bug packets out of order when using MIT-pthreads.

  • Removed possible loop when a thread waits for command from client and fcntl() fails. Thanks to Mike Bretz for finding this bug.

  • Changed alarm loop in mysqld.cc because shutdown didn't always succeed in Linux.

  • Removed use of termbits from mysql.cc. This conflicted with glibc 2.0.

  • Fixed some syntax errors for at least BSD and Linux.

  • Fixed bug when doing a SELECT as superuser without a database.

  • Fixed bug when doing SELECT with group calculation to outfile.

D.7.5. Changes in release 3.20.14

  • If one gives -p or --password option to mysql without an argument, the user is solicited for the password from the tty.

  • Added default password from MYSQL_PWD (by Elmar Haneke).

  • Added command kill to mysqladmin to kill a specific MySQL thread.

  • Sometimes when doing a reconnect on a down connection this succeeded first on second try.

  • Fixed adding an AUTO_INCREMENT key with ALTER_TABLE.

  • AVG() gave too small value on some SELECT statements with GROUP BY and ORDER BY.

  • Added new DATETIME type (by Giovanni Maruzzelli <maruzz@matrice.it>).

  • Fixed that defining DONT_USE_DEFAULT_FIELDS works.

  • Changed to use a thread to handle alarms instead of signals on Solaris to avoid race conditions.

  • Fixed default length of signed numbers. (George Harvey <georgeh@pinacl.co.uk>.)

  • Allow anything for CREATE INDEX.

  • Add prezeros when packing numbers to DATE, TIME and TIMESTAMP.

  • Fixed a bug in OR of multiple tables (gave empty set).

  • Added many patches to MIT-pthreads. This fixes at least one lookup bug.

D.7.6. Changes in release 3.20.13

  • Added standard SQL-92 DATE and TIME types.

  • Fixed bug in SELECT with AND-OR levels.

  • Added support for Slovenian characters. The Contrib directory contains source and instructions for adding other character sets.

  • Fixed bug with LIMIT and ORDER BY.

  • Allow ORDER BY and GROUP BY on items that aren't in the SELECT list. (Thanks to Wim Bonis <bonis@kiss.de>, for pointing this out.)

  • Allow setting of timestamp values in INSERT.

  • Fixed bug with SELECT ... WHERE ... = NULL.

  • Added changes for glibc 2.0. To get glibc to work, you should add the gibc-2.0-sigwait-patch before compiling glibc.

  • Fixed bug in ALTER TABLE when changing a NOT NULL field to allow NULL values.

  • Added some SQL-92 synonyms as field types to CREATE TABLE. CREATE TABLE now allows FLOAT(4) and FLOAT(8) to mean FLOAT and DOUBLE.

  • New utility program mysqlaccess by <Yves.Carlier@rug.ac.be>. This program shows the access rights for a specific user and the grant rows that determine this grant.

  • Added WHERE const op field (by <bonis@kiss.de>).

D.7.7. Changes in release 3.20.11

  • When using SELECT ... INTO OUTFILE, all temporary tables are ISAM instead of HEAP to allow big dumps.

  • Changed date functions to be string functions. This fixed some ``funny'' side effects when sorting on dates.

  • Extended ALTER TABLE for SQL-92 compliance.

  • Some minor compatibility changes.

  • Added --port and --socket options to all utility programs and mysqld.

  • Fixed MIT-pthreads readdir_r(). Now mysqladmin create database and mysqladmin drop database should work.

  • Changed MIT-pthreads to use our tempnam(). This should fix the ``sort aborted'' bug.

  • Added sync of records count in sql_update. This fixed slow updates on first connection. (Thanks to Vaclav Bittner for the test.)

D.7.8. Changes in release 3.20.10

  • New insert type: INSERT INTO ... SELECT ...

  • MEDIUMBLOB fixed.

  • Fixed bug in ALTER TABLE and BLOB values.

  • SELECT ... INTO OUTFILE now creates the file in the current database directory.

  • DROP TABLE now can take a list of tables.

  • Oracle synonym DESCRIBE (DESC).

  • Changes to make_binary_distribution.

  • Added some comments to installation instructions about configure's C++ link test.

  • Added --without-perl option to configure.

  • Lots of small portability changes.

D.7.9. Changes in release 3.20.9

  • ALTER TABLE didn't copy null bit. As a result, fields that were allowed to have NULL values were always NULL.

  • CREATE didn't take numbers as DEFAULT.

  • Some compatibility changes for SunOS.

  • Removed config.cache from old distribution.

D.7.10. Changes in release 3.20.8

  • Fixed bug with ALTER TABLE and multi-part keys.

D.7.11. Changes in release 3.20.7

  • New commands: ALTER TABLE, SELECT ... INTO OUTFILE and LOAD DATA INFILE.

  • New function: NOW().

  • Added new field File_priv to mysql/user table.

  • New script add_file_priv which adds the new field File_priv to the user table. This script must be executed if you want to use the new SELECT ... INTO and LOAD DATA INFILE ... commands with a version of MySQL earlier than 3.20.7.

  • Fixed bug in locking code, which made lock_test.pl test fail.

  • New files NEW and BUGS.

  • Changed select_test.c and insert_test.c to include config.h.

  • Added status command to mysqladmin for short logging.

  • Increased maximum number of keys to 16 and maximum number of key parts to 15.

  • Use of sub keys. A key may now be a prefix of a string field.

  • Added -k option to mysqlshow, to get key information for a table.

  • Added long options to mysqldump.

D.7.12. Changes in release 3.20.6

  • Portable to more systems because of MIT-pthreads, which will be used automatically if configure cannot find a -lpthreads library.

  • Added GNU-style long options to almost all programs. Test with program --help.

  • Some shared library support for Linux.

  • The FAQ is now in .texi format and is available in .html, .txt and .ps formats.

  • Added new SQL function RAND([init]).

  • Changed sql_lex to handle \0 unquoted, but the client can't send the query through the C API, because it takes a str pointer. You must use mysql_real_query() to send the query.

  • Added API function mysql_get_client_info().

  • mysqld now uses the N_MAX_KEY_LENGTH from nisam.h as the maximum allowable key length.

  • The following now works:

    mysql> SELECT filter_nr,filter_nr FROM filter ORDER BY filter_nr;

    Previously, this resulted in the error: Column: 'filter_nr' in order clause is ambiguous.

  • mysql now outputs '\0', '\t', '\n' and '\\' when encountering ASCII 0, tab, newline or '\' while writing tab-separated output. This is to allow printing of binary data in a portable format. To get the old behavior, use -r (or --raw).

  • Added german error messages (60 of 80 error messages translated).

  • Added new API function mysql_fetch_lengths(MYSQL_RES *), which returns an array of column lengths (of type uint).

  • Fixed bug with IS NULL in WHERE clause.

  • Changed the optimizer a little to get better results when searching on a key part.

  • Added SELECT option STRAIGHT_JOIN to tell the optimizer that it should join tables in the given order.

  • Added support for comments starting with '--' in mysql.cc (Postgres syntax).

  • You can have SELECT expressions and table columns in a SELECT which are not used in the group part. This makes it efficient to implement lookups. The column that is used should be a constant for each group because the value is calculated only once for the first row that is found for a group.

    mysql> SELECT id,lookup.text,SUM(*) FROM test,lookup
    ->        WHERE test.id=lookup.id GROUP BY id;

  • Fixed bug in SUM(function) (could cause a core dump).

  • Changed AUTO_INCREMENT placement in the SQL query:

    INSERT INTO table (auto_field) VALUES (0);

    inserted 0, but it should insert an AUTO_INCREMENT value.

  • mysqlshow.c: Added number of records in table. Had to change the client code a little to fix this.

  • mysql now allows doubled '' or "" within strings for embedded ' or ".

  • New math functions: EXP(),
LOG(), SQRT(),
ROUND(), CEILING().

D.7.13. Changes in release 3.20.3

  • The configure source now compiles a thread-free client library -lmysqlclient. This is the only library that needs to be linked with client applications. When using the binary releases, you must link with -lmysql -lmysys -ldbug -lmystrings as before.

  • New readline library from bash-2.0.

  • LOTS of small changes to configure and makefiles (and related source).

  • It should now be possible to compile in another directory using VPATH. Tested with GNU Make 3.75.

  • safe_mysqld and mysql.server changed to be more compatible between the source and the binary releases.

  • LIMIT now takes one or two numeric arguments. If one argument is given, it indicates the maximum number of rows in a result. If two arguments are given, the first argument indicates the offset of the first row to return, the second is the maximum number of rows. With this it's easy to do a poor man's next page/previous page WWW application.

  • Changed name of SQL function FIELDS() to
ELT(). Changed SQL function
INTERVALL() to
INTERVAL().

  • Made SHOW COLUMNS a synonym for SHOW FIELDS. Added compatibility syntax FRIEND KEY to CREATE TABLE. In MySQL, this creates a non-unique key on the given columns.

  • Added CREATE INDEX and DROP INDEX as compatibility functions. In MySQL, CREATE INDEX only checks if the index exists and issues an error if it doesn't exist. DROP INDEX always succeeds.

  • mysqladmin.c: added client version to version information.

  • Fixed core dump bug in sql_acl (core on new connection).

  • Removed host, user and db tables from database test in the distribution.

  • FIELD_TYPE_CHAR can now be signed (-128 to 127) or unsigned (0 to 255) Previously, it was always unsigned.

  • Bug fixes in CONCAT() and WEEKDAY().

  • Changed a lot of source to get mysqld to be compiled with SunPro compiler.

  • SQL functions must now have a '(' immediately after the function name (no intervening space). For example, 'USER(' is regarded as beginning a function call, and 'USER (' is regarded as an identifier USER followed by a '(', not as a function call.

D.7.14. Changes in release 3.20.0

  • The source distribution is done with configure and Automake. It will make porting much easier. The readline library is included in the distribution.

  • Separate client compilation: the client code should be very easy to compile on systems which don't have threads.

  • The old Perl interface code is automatically compiled and installed. Automatic compiling of DBD will follow when the new DBD code is ported.

  • Dynamic language support: mysqld can now be started with Swedish or English (default) error messages.

  • New functions: INSERT(),
RTRIM(), LTRIM() and
FORMAT().

  • mysqldump now works correctly for all field types (even AUTO_INCREMENT). The format for SHOW FIELDS FROM tbl_name is changed so the Type column contains information suitable for CREATE TABLE. In previous releases, some CREATE TABLE information had to be patched when re-creating tables.

  • Some parser bugs from 3.19.5 (BLOB and TIMESTAMP) are corrected. TIMESTAMP now returns different date information depending on its create length.

  • Changed parser to allow a database, table or field name to start with a number or '_'.

  • All old C code from Unireg changed to C++ and cleaned up. This makes the daemon a little smaller and easier to understand.

  • A lot of small bug fixes done.

  • New INSTALL files (not final version) and some information regarding porting.


D.8. Changes in release 3.19.x

Version 3.19 is quite old now, and should be avoided if possible. This information is kept here for historical purposes only.

D.8.1. Changes in release 3.19.5

  • Some new functions, some more optimization on joins.

  • Should now compile clean on Linux (2.0.x).

  • Added functions DATABASE(),
USER(), POW(),
LOG10() (needed for ODBC).

  • In a WHERE with an ORDER BY on fields from only one table, the table is now preferred as first table in a multi-join.

  • HAVING and IS NULL or IS NOT NULL now works.

  • A group on one column and a sort on a group function (SUM(), AVG()...) didn't work together. Fixed.

  • mysqldump: Didn't send password to server.

D.8.2. Changes in release 3.19.4

  • Fixed horrible locking bug when inserting in one thread and reading in another thread.

  • Fixed one-off decimal bug. 1.00 was output as 1.0.

  • Added attribute 'Locked' to process list as information if a query is locked by another query.

  • Fixed full magic timestamp. Timestamp length may now be 14, 12, 10, 8, 6, 4 or 2 bytes.

  • Sort on some numeric functions could sort incorrectly on last number.

  • IF(arg,syntax_error,syntax_error) crashed.

  • Added functions CEILING(),
ROUND(), EXP(),
LOG() and SQRT().

  • Enhanced BETWEEN to handle strings.

D.8.3. Changes in release 3.19.3

  • Fixed SELECT with grouping on BLOB columns not to return incorrect BLOB info. Grouping, sorting and distinct on BLOB columns will not yet work as expected (probably it will group/sort by the first 7 characters in the BLOB). Grouping on formulas with a fixed string size (use MID() on a BLOB) should work.

  • When doing a full join (no direct keys) on multiple tables with BLOB fields, the BLOB was garbage on output.

  • Fixed DISTINCT with calculated columns.


부록 E. 타시스템에의 이식

목차

E.1. MySQL 서버의 디버그
E.1.1. MYSQL 의 컴파일(디버그용)
E.1.2. 트레이스 파일의 작성
E.1.3. mysqld 의 디버그(gdb 사용)
E.1.4. 스택 트레이스의 사용
E.1.5. mysqld 에 있어서의 에러의 원인을 로그 파일을 사용해 특정한다
E.1.6. 테이블이 파손했을 경우에 시험대를 작성한다
E.2. MySQL 클라이언트의 디버그
E.3. DBUG 패키지
E.4. 락 방법
E.5. RTS 스레드에 관한 코멘트
E.6. 다른 스레드패키지간의 차이

이 부록은,MySQL (을)를 다른 operating system에 이식할 때에 도움이 됩니다. 현시점에서 서포트되고 있는 operating system의 일람을 최초로 확인해 주세요. See 항2.2.3. 「MySQL 하지만 서포트하고 있는 operating system」 . MySQL 의 이식판을 새롭게 작성했을 경우는 알려주세요.이 메뉴얼과 당사 Web 사이트(http://www.mysql.com/ )에 신규 이식판을 게재해, 다른 유저에게 추천 하겠습니다.

주의: 작성했다 MySQL 이식판은 GPL 라이센스아래에서 자유롭게 복제 및 배포할 수 있습니다만, 이것에 의해서 MySQL 의 소유권이 부여되는 것이 아닙니다.

이식처의 서버에는, 유효한 Posix 스레드라이브라리가 필요합니다.우리는,Solaris 2.5 에 대해서는 Sun 의 PThread (2.4 이전의 버젼에 있어서의 네이티브스레드의 서포트는 불충분했습니다),Linux 에 대해서는 Xavier Leroy (<Xavier.Leroy@inria.fr> )에 의한다 LinuxThread (을)를 사용하고 있습니다.

네이티브스레드에 관한 충분한 서포트가 없는 상태로 신종의 Unix 에 이식할 때에 어려운 것은,MIT-pthread 의 이식이다고 생각할 수 있습니다.mit-pthreads/README (와)과 「Programming POSIX Threads 」(http://www.humanfactor.com/pthreads/ )(을)를 참조해 주세요.

MySQL 4.0.2 까지,MySQL 의 디스트리뷰션에는 Chris Provenzano 의 MIT Pthread (MIT Pthread 의 Web 페이지(http://www.mit.edu/afs/sipb/project/pthreads/ )(와)과 프로그라?~ 그 입문(http://www.mit.edu:8001/people/proven/IAP_2000/ )) 패치 적용 버젼이 포함되어 있었습니다. 이것들은 POSIX 스레드를 가지지 않는 일부의 operating system에서도 사용 가능합니다. See 항2.3.6. 「MIT-pthreads 에 관한 주의 사항」 .

다른 유자레베르스레드패키지이다 FSU Pthread (http://moss.csc.ncsu.edu/~mueller/pthreads/ (을)를 참조)를 사용할 수도 있습니다. 이 실장은 SCO 에의 이식에 사용되고 있습니다.

이러한 문제의 테스트나 실례에 대해서는,mysys 디렉토리의 thr_lock.c 및 thr_alarm.c 프로그램을 참조해 주세요.

서버와 클라이언트의 어느 쪽에도 C++ 컴파일러가 필요합니다.우리는, 많은 플랫폼에서 gcc (을)를 사용하고 있습니다.상기 이외로 유효라고 확인된 컴파일러는,SPARCworks ,Sun Forte ,Irix cc ,HP-UX aCC ,IBM AIX xlC_r) ,Intel ecc ,Compaq cxx) 입니다.

클라이언트만 컴파일 하려면 ,./configure --without-server (을)를 사용합니다.

서버만의 컴파일은, 현시점에서는 서포트되지 않고, 각별한 이유가 없는 한 추가되지 않는 것이라고 생각됩니다.

Makefile 또는 configure 스크립트를 변경할 필요가 있는 경우,GNU Automake 및 Autoconf 도 필요합니다. See 항2.3.4. 「개발 소스 트리로부터의 인스톨」 .

가장 기본적인 파일로부터 모든 것을 재작성하기 위해서 필요한 순서.

/bin/rm */.deps/*.P
/bin/rm -f config.cache
aclocal
autoheader
aclocal
automake
autoconf
./configure --with-debug=full --prefix='your installation directory'

# The makefiles generated above need GNU make 3.75 or newer.
# (called gmake below)
gmake clean all install init-db

이식에 관해서 문제가 일어났을 경우,MySQL (을)를 디버그 해야 하는 것이 있습니다. See 항E.1. 「MySQL 서버의 디버그」 .

주의: mysqld 의 디버그를 개시하기 전에, 테스트 프로그램 mysys/thr_alarm 및 mysys/thr_lock (을)를 기동해 주세요.이것에 의해서, 스레드의 인스톨이 실행될 가능성도 다소 있습니다.

E.1. MySQL 서버의 디버그

MySQL 의 신기능을 사용하고 있는 경우, 이하를 지정해 mysqld 의 실행을 시도할 수 있습니다.--skip-new (을)를 지정하면, 안전하지 않을 가능성이 있는 신기능이 모두 무효가 됩니다.--safe-mode (을)를 지정하면, 문제를 일으킬 가능성이 있는 최적화의 대부분이 무효가 됩니다. See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

mysqld 하지만 기동하지 않는 경우, 몇개의 my.cnf 파일이 셋업의 방해가 되지 않은가 확인할 필요가 있습니다. my.cnf 인수를 mysqld --print-defaults 그리고 체크해, 이러한 인수가 사용되지 않게,mysqld --no-defaults ... 그리고 기동할 수 있습니다.

mysqld 하지만CPU 또는 메모리를 소비하기 시작했는지 `` 행'' 했을 경우,mysqladmin processlist status (을)를 사용하고, 시간이 걸리는 쿼리를 실행하고 있는 유저를 확인할 수 있습니다.mysqladmin -i10 processlist status (을)를 윈도우로 실행하면 유익한 케이스도 있습니다.예를 들어, 새로운 클라이언트에 접속할 수 없을 때에 퍼포먼스의 문제가 일어나고 있는 경우입니다.

커멘드 mysqladmin debug (을)를 실행하면, 사용중의 락, 메모리의 사용 용량, 및 쿼리의 용도에 관한 정보가 mysql 로그 파일에 덤프 되어 문제 해결로 연결되는 일이 있습니다.또, 디버그를 위해서 MySQL (을)를 컴파일 하고 있지 않아도, 유익한 정보를 얻을 수 있기도 합니다.

일부의 테이블의 처리 속도가 저하하는 문제가 일어났을 경우,OPTIMIZE TABLE 또는 myisamchk 그리고 테이블의 최적화를 시도해 주세요.See 장 4. 데이타베이스 관리 . 또, 늦은 쿼리를 EXPLAIN 그리고 체크할 필요가 있습니다.

이 메뉴얼에 있어서의 OS 고유의 섹션을 참조해, 사용 환경에 특유인 문제에 대해 확인할 필요도 있습니다. See 항2.6. 「 operating system 고유의 주의 사항」 .

E.1.1. MYSQL 의 컴파일(디버그용)

지극히 고유한 문제가 일어났을 경우는, 언제라도 MySQL 의 디버그를 시도할 수 있습니다.디버그 하려면 ,--with-debug 또는 --with-debug=full 옵션을 지정해 MySQL (을)를 설정할 필요가 있습니다. MySQL 하지만 컴파일 되었는지를 체크하려면 ,mysqld --help (을)를 실행합니다.--debug 옵션이 표시되면 디버그는 유효합니다.이 경우,mysqladmin ver (을)를 실행하면,mysqld 버젼이 mysql ... --debug (으)로서 표시됩니다.

gcc 또는 egcs 의 사용시에는, 이하의 configure 행이 추천 되고 있습니다.

CC=gcc CFLAGS="-O2" CXX=gcc CXXFLAGS="-O2 -felide-constructors \
   -fno-exceptions -fno-rtti" ./configure --prefix=/usr/local/mysql \
   --with-debug --with-extra-charsets=complex

이것에 의해서,libstdc++ 라이브러리와 C++ 예외에 관한 문제가 회피되어(많은 컴파일러에서는, 스레드코드로 C++ 예외가 발생합니다), 모든 캐릭터 세트의 서포트 첨부로 MySQL 하지만 컴파일 됩니다.

메모 리오-바 런 에러의 혐의가 있는 경우,--with-debug=full 옵션을 지정해 MySQL (을)를 설정해, 메모리 할당(SAFEMALLOC ) checker를 인스톨 할 수 있습니다.다만,SAFEMALLOC (을)를 지정해 실행하면 매우 늦어지므로, 퍼포먼스의 문제가 생겼을 때에는 mysqld (을)를 --skip-safemalloc 옵션으로 기동해 주세요.이것에 의해서,malloc() (와)과 free() 에 대한 호출마다 메모 리오-바 런의 체크가 무효가 됩니다.

mysqld 하지만 --with-debug 부착의 컴파일시에 크래쉬 하지 않게 되었을 경우, 컴파일러 버그 또는 타이?~ 그바그가 MySQL 그리고 검출되었다고 생각할 수 있습니다.이 경우, 상기의 CFLAGS 및 CXXFLAGS 변수에 -g (을)를 추가해,--with-debug (을)를 지정하지 않는 방법을 시도할 수 있습니다.mysqld 하지만 크래쉬 했을 경우, 적어도 gdb (을)를 사용해 아탓치 하는지, 코어 파일상에서 gdb (을)를 실행하고 무엇이 일어났는지 확인하는 것은 가능합니다.

디버그용으로 MySQL (을)를 설정하면, 많은 특별한 체크 함수가 자동적으로 유효하게 되어, 이것들에 의해서 mysqld 상태가 감시됩니다. `` 예기치 않다'' 상태가 검출되었을 경우,stderr 에 엔트리가 써져mysqld_safe 에 의해서 에러 로그에 송신됩니다.즉, 예기치 않은 문제가 MySQL 그리고 발생했을 때에 소스 디스트리뷰션을 사용하고 있는 경우, 우선 MySQL (을)를 디버그용으로 설정할 필요가 있습니다.그 다음은 MySQL 메일링 리스트에 메일을 송신해, 헬프를 의뢰해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 . 이용의 MySQL 버젼에 관한 버그 리포트 또는 질문에 대해서는,mysqlbug (을)를 사용해 주세요.

Windows 판 MySQL 디스트리뷰션에서는,mysqld.exe 하지만 디폴트로 컴파일 되고 있습니다(트레이스 파일의 서포트 첨부).

E.1.2. 트레이스 파일의 작성

mysqld 서버가 기동하지 않는가 mysqld 서버로 곧바로 크래쉬가 일어나는 경우, 트레이스 파일을 작성해 문제의 검출을 시도할 수 있습니다.

그러기 위해서는,mysqld (을)를 디버그용으로 컴파일 해 둘 필요가 있습니다.그처럼 컴파일 되고 있는지 확인하려면 ,mysqld -V (을)를 실행합니다.버젼 번호의 말미가 -debug 인 경우, 트레이스 파일의 서포트 첨부로 컴파일 되고 있습니다.

/tmp/mysqld.trace (Windows 그럼 C:\mysqld.trace ) 안의 트레이스 로그를 지정해 mysqld 서버를 기동합니다.

mysqld --debug

Windows 그럼,--standalone 플래그를 사용해,mysqld 하지만 서비스로서 기동되지 않게 할 필요도 있습니다.

콘솔 윈도우로 이하를 실행합니다.

mysqld --debug --standalone

이 후,mysql.exe 커멘드 라인 툴을 2 번째의 콘솔 윈도우로 실행해, 문제를 재현할 수 있습니다.mysqladmin shutdown 그럼,mysqld 서버를 강제 종료할 수 있습니다.

주의: 트레이스 파일은 매우 큰 사이즈가 됩니다. 트레이스 파일의 사이즈를 작게 하고 싶은 경우, 예를 들어 이하와 같이 지정할 수 있습니다.

mysqld --debug=d,info,error,query,general,where:O,/tmp/mysqld.trace

(이 경우, 가장 흥미로운 태그가 붙은 정보만이 /tmp/mysqld.trace 에 출력됩니다.)

이것에 관한 버그 리포트를 작성하는 경우, 불편이 있다고 생각되는 행만을 트레이스 파일로부터 선택해, 적절한 메일링 리스트 앞으로 송신해 주세요.불편의 장소를 특정할 수 없는 경우에는, 트레이스 파일과 완전한 버그 리포트를 ftp://support.mysql.com/pub/mysql/secret/ 까지 ftp 그리고 송신해 주세요.MySQL 의 개발자측에서 확인하겠습니다.

트레이스 파일은,Fred Fish 에 의한다 DBUG 패키지로 작성되고 있습니다. See 항E.3. 「DBUG 패키지」 .

E.1.3. mysqld 의 디버그(gdb 사용)

많은 시스템에서는,mysqld 하지만 크래쉬 했을 때에,mysqld (을)를 gdb (으)로부터 기동하는 것으로, 보다 많은 정보를 취득할 수도 있습니다.

Linux 그리고 사용되는 구버젼의 gdb 의 일부에서는,mysqld 스레드를 디버그 할 때에 run --one-thread (을)를 사용하지 않으면 안됩니다.이 경우, 한 번에 액티브하게 할 수 있는 스레드는 1 개 뿐입니다.신속하게 gdb 5.1 에 업그레이드 하는 것을 추천합니다.이 버젼에서는, 스레드데밧그의 처리가 큰폭으로 개선되기 때문입니다.

gdb 그리고 mysqld (을)를 실행하는 경우, 스택 트레이스를 --skip-stack-trace 그리고 무효화해,gdb 내부에서 segfault (을)를 포착할 수 있도록 할 필요가 있습니다.

MySQL 4.0.14 이?~ 그럼,mysqld 에 대해서 --gdb 옵션을 사용해 주세요.이 옵션을 사용하면,SIGINT (mysqld (을)를 ^C 그리고 종료해, breakpoint를 설정하기 위해서 필요)의 인터럽트 처리기가 인스톨 되어 스택 트레이스와 코어 파일 처리가 무효가 됩니다.

gdb 그리고 MySQL (을)를 디버그 하는 것이 매우 곤란한 경우가 있습니다.예를 들어, 낡은 스레드에 대한 메모리가 gdb 에 의해서 해방되지 않고, 디버그중에 대량의 신규 접속을 연속해 확립해야 하는 경우입니다.이 문제를 회피하려면 ,-O thread_cache_size= 'max_connections +1' (을)를 지정해 mysqld (을)를 기동합니다.많은 경우,-O thread_cache_size=5' (을)를 지정하는 것만으로 상황은 큰폭으로 개선합니다.

SIGSEGV 시그널로 mysqld 하지만 크래쉬 했을 경우,Linux 위에서 코어덤프를 취득하려면 ,--core-file 옵션을 지정해 mysqld (을)를 기동합니다. 이 코어 파일을 사용해 백 트레이스를 작성해,mysqld 하지만 크래쉬 한 이유를 특정할 수도 있습니다.

shell> gdb mysqld core
gdb>   backtrace full
gdb>   exit

See 항A.4.1. 「MySQL 하지만 몇번이나 크래쉬 하는 경우에 실시하는 것」 .

gdb 4.17.x 이?~ (을)를 Linux 그리고 사용하고 있는 경우,.gdb 파일을 이하의 정보와 함께 커런트 디렉토리에 인스톨 할 필요가 있습니다.

set print sevenbit off
handle SIGUSR1 nostop noprint
handle SIGUSR2 nostop noprint
handle SIGWAITING nostop noprint
handle SIGLWP nostop noprint
handle SIGPIPE nostop
handle SIGALRM nostop
handle SIGHUP nostop
handle SIGTERM nostop noprint

gdb 그리고 스레드의 디버그에 문제가 일어났을 경우,gdb 5.x (을)를 다운로드해 대용해 보세요.gdb 의 신규 버젼에서는, 스레드의 처리가 비약적으로 개선되고 있습니다.

이하의 예는,mysqld (을)를 디버그 하는 방법을 나타냅니다.

shell> gdb /usr/local/libexec/mysqld
gdb> run
...
backtrace full # Do this when mysqld crashes

mysqlbug 그리고 생성된 상기의 출력 내용을 메일에 수중에 넣어, 통상의 MySQL 메일링 리스트 앞으로 송신해 주세요. See 항1.7.1.1. 「MySQL 메일링 리스트」 .

mysqld 하지만 행 했을 경우,strace (이)나 /usr/proc/bin/pstack (와)과 같은 시스템 툴을 사용해,mysqld 하지만 행 한 장소를 조사할 수 있습니다.

strace /tmp/log libexec/mysqld

Perl DBI 인터페이스를 사용하고 있는 경우, 디버그 정보를 유효하게 하려면 ,trace 메소드를 사용할까 DBI_TRACE 환경 변수를 설정합니다. See 항11.5.2. 「DBI 인터페이스」 .

E.1.4. 스택 트레이스의 사용

일부의 operating system에서는,mysqld 하지만 돌연 크래쉬 하면 스택 트레이스가 에러 로그에 기록됩니다.이 정보를 사용하면,mysqld 하지만 크래쉬 한 장소( 및 이유)를 확인할 수 있습니다.See 항4.10.1. 「에러 로그」 . 스택 트레이스를 취득하는 경우,mysqld 의 컴파일을 -fomit-frame-pointer 옵션 첨부 gcc 그리고 실시하지 말아 주세요. See 항E.1.1. 「MYSQL 의 컴파일(디버그용)」 .

에러 파일의 내용이 이하대로이다고 합니다.

mysqld got signal 11;
The manual section 'Debugging a MySQL server' tells you how to use a
stack trace and/or the core file to produce a readable backtrace that may
help in finding out why mysqld died
Attemping backtrace. You can use the following information to find out
where mysqld died.  If you see no messages after this, something went
terribly wrong
stack range sanity check, ok, backtrace follows
0x40077552
0x81281a0
0x8128f47
0x8127be0
0x8127995
0x8104947
0x80ff28f
0x810131b
0x80ee4bc
0x80c3c91
0x80c6b43
0x80c1fd9
0x80c1686

mysqld 하지만 크래쉬 한 장소를 특정하려면 , 이하를 실행합니다.

  1. 상기의 번호를 파일(예를 들어 mysqld.stack )에 카피한다.

  2. mysqld 서버의 심볼 파일을 작성한다.

    nm -n libexec/mysqld > /tmp/mysqld.sym

    주의: 많은 MySQL 바이너리 디스트리뷰션(이 정보가 바이너리 자체의 내부에 포함되어 있다 " 디버그" 패키지는 제외)에는, 상기의 파일이 mysqld.sym.gz 그렇다고 하는 명칭으로 동고 되고 있습니다. 여기에서는, 이 파일을 이하와 같이 간단하게 해동할 수 있습니다.

    gunzip < bin/mysqld.sym.gz > /tmp/mysqld.sym

  3. resolve_stack_dump -s /tmp/mysqld.sym -n mysqld.stack (을)를 실행한다.

    실행하면,mysqld 하지만 크래쉬 한 장소가 출력됩니다.mysqld 하지만 크래쉬 한 원인을 이 방법으로 특정할 수 없는 경우에는, 버그 리포트를 작성해, 상기 커멘드의 출력 결과를 버그 리포트에 포함할 필요가 있습니다.

    다만, 많은 경우, 스택 트레이스만으로는 문제의 이유를 특정할 수 없습니다.버그를 찾아낼까 차선책을 강구하려면 , 많은 경우,mysqld 의 크래쉬를 일으킨 쿼리외, 가능하면 문제를 재현할 수 있는 테스트테이스에 대해서도 알 필요가 있습니다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

E.1.5. mysqld 에 있어서의 에러의 원인을 로그 파일을 사용해 특정한다

주의: --log (을)를 지정해 mysqld (을)를 기동하기 전에, 모든 테이블을 myisamchk 그리고 체크해 주세요. See 장 4. 데이타베이스 관리 .

mysqld 하지만 크래쉬 또는 행 했을 경우,--log (을)를 지정해 mysqld (을)를 기동할 필요가 있습니다.mysqld 하지만 재차 크래쉬 했을 경우, 로그 파일의 말미를 참조해,mysqld 의 크래쉬를 일으킨 쿼리의 유무를 확인할 수 있습니다.

파일명 없이 --log (을)를 사용하고 있는 경우, 로그는 'hostname'.log (으)로서 데이타베이스 디렉토리에 격납됩니다.많은 경우, 로그 파일내의 마지막 쿼리가 원인으로 mysqld 하지만 크래쉬 하고 있습니다.다만, 실제로 그랬는지 어떤지를 확인하기 위해(때문에),mysqld (을)를 재기동해, 검출된 쿼리를 mysql 커멘드 라인 툴로부터 실행할 필요가 있습니다(가능한 경우).이 방법이 유효한 경우, 완료하지 않았다 복잡한 쿼리를 모두 테스트할 필요도 있습니다.

시간이 걸린다 SELECT 스테이트먼트의 모두에 대해서 커멘드 EXPLAIN (을)를 실행해, 인덱스가 mysqld 에 의해서 적절히 사용되고 있는지 어떤지를 확인할 수도 있습니다. See 항5.2.1. 「EXPLAIN 구문(SELECT 에 관한 정보의 취득)」 .

실행 시간의 긴 쿼리를 검색하려면 ,--log-slow-queries (을)를 지정해 mysqld (을)를 실행합니다. See 항4.10.5. 「슬로우 쿼리 로그」 .

텍스트 mysqld restarted 하지만 에러 로그 파일(통상은 hostname.err 그렇다고 하는 명칭)에 포함되어 있는 경우,mysqld 의 크래쉬를 일으킨 쿼리가 검출되었다고 생각할 수 있습니다.이 경우,myisamchk (see 장 4. 데이타베이스 관리 )(으)로 테이블을 모두 체크합니다.또,MySQL 로그 파일내의 쿼리를 테스트해, 어느쪽이든가 무효인지 어떤지를 확인합니다.그러한 쿼리가 발견되었을 경우, 최신 버젼의 MySQL 에의 업그레이드를 시도해 주세요.업그레이드 해도 문제가 해결하지 않고,mysql 메일 어카이브(archive)에도 유익한 정보가 없는 경우,MySQL 메일링 리스트에 버그를 리포트할 필요가 있습니다. 이 메일링 리스트가 게재되고 있다 http://lists.mysql.com/ 에는, 온라인 리스토어 카이브도 링크되고 있습니다.

myisam-recover (을)를 지정해 mysqld (을)를 기동했을 때,MyISAM 테이블이 ' 올바르게 닫혀지지 않았다' 또는 ' 크래쉬 했다' (와)과 마크 되고 있는 경우, 그 테이블은 자동적으로 체크되어 수복이 시행됩니다.이 경우,hostname.err 파일에 'Warning: Checking table ...' (와)과 써집니다.또, 테이블의 수복이 필요하면,Warning: Repairing table 하지만 계속 되어 써집니다.이러한 에러가 대량으로 발생했을 때, 직전에 mysqld 하지만 돌연 크래쉬 하고 있지 않는 경우는 비정상이고, 한층 더 조사하지 않으면 안됩니다. See 항4.1.1. 「mysqld 커멘드 라인 옵션」 .

mysqld 하지만 돌연 크래쉬 하는 것은, 물론 정상적이지는 않습니다.다만, 그 경우에는,Checking table... 메세지를 조사하는 것이 아니라,mysqld 하지만 크래쉬 한 원인을 찾아 주세요.

E.1.6. 테이블이 파손했을 경우에 시험대를 작성한다

테이블이 파손하고 있는지, 갱신 커멘드의 뒤에 mysqld 하지만 반드시 에러가 되는 경우, 이 문제가 재현되는지 테스트하려면 이하를 실행합니다.

  • MySQL demon를 강제 종료한다(mysqladmin shutdown (을)를 사용).

  • 테이블의 백업을 작성한다(수복에 의한 악영향이 생겼을 경우에 대비하기 위해).

  • 모든 테이블을 myisamchk -s database/*.MYI 그리고 체크한다.문제가 일어난 테이블이 있으면 myisamchk -r database/table.MYI 그리고 수복한다.

  • 테이블의 2 다음 백업을 작성한다.

  • 빈 용량을 늘릴 필요가 있는 경우, 낡은 로그 파일을 MySQL 데이터 디렉토리로부터 삭제 또는 이동한다.

  • mysqld (을)를 --log-bin 그리고 기동한다. See 항4.10.4. 「바이너리 로그」 . mysqld 의 크래쉬를 일으키는 쿼리를 검색하는 경우,--log --log-bin (을)를 사용한다.

  • 테이블이 크래쉬 했을 경우,mysqld server (을)를 종료한다.

  • 백업을 restore 한다.

  • --log-bin (을)를 지정하지 않는다 그리고 mysqld 서버를 기동한다.

  • mysqlbinlog update-log-file | mysql (을)를 지정해 커멘드를 재실행한다. 갱신 로그는,hostname-bin.# 그렇다고 하는 명칭으로 MySQL 데이타베이스 디렉토리에 보존된다.

  • 테이블이 재차 파손했는지, 상기의 커멘드로 mysqld (이)가 종료되는 경우, 재현 가능한 버그가 검출되고 있다.그러한 버그는, 용이하게 수정하는 것이 가능.테이블과 바이너리 로그를 ftp://support.mysql.com/pub/mysql/secret/ FTP 그리고 송신해, 당사의 버그 시스템(http://bugs.mysql.com/ )에 입력한다. 서포트 유저의 경우,<support@mysql.com> 그리고 MySQL 팀에 문제를 통지해, 신속한 수정을 의뢰할 수도 있다.

스크립트 mysql_find_rows 그리고 일부의 갱신 스테이트먼트만을 실행해, 문제를 좁힐 수도 있습니다.


E.2. MySQL 클라이언트의 디버그

MySQL 클라이언트를 통합 디버그 패키지에 의해서 디버그 하려면 ,--with-debug 또는 --with-debug=full (을)를 지정해 MySQL (을)를 설정할 필요가 있습니다. See 항2.3.3. 「일반적인 configure 옵션」 .

클라이언트를 실행하기 전에,MYSQL_DEBUG 환경 변수를 지정해 주세요.

shell> MYSQL_DEBUG=d:t:O,/tmp/client.trace
shell> export MYSQL_DEBUG

그 결과, 클라이언트에 의해서 트레이스 파일이 /tmp/client.trace 에 생성됩니다.

유저 자신의 클라이언트 코드로 문제가 일어났을 경우, 서버에 접속해, 유효라고 확인되고 있는 클라이언트로 쿼리를 실행해 보세요.그러기 위해서는,mysql (을)를 디버그 모드로 실행합니다(디버그를 유효하게 해 MySQL (을)를 컴파일 되어 있는 것이 전제).

shell> mysql --debug=d:t:O,/tmp/client.trace

버그 리포트를 메일 송신하는 경우, 상기에 의해서 유익한 정보를 얻을 수 있습니다. See 항1.7.1.3. 「버그 또는 문제를 보고하는 방법」 .

' 유효라고 생각된다' 코드로 클라이언트가 크래쉬 했을 경우,mysql.h 인클루드 파일이 mysql 라이브러리 파일과 일치할지를 확인할 필요가 있습니다. 일반적인 잘못으로서는, 낡은 버젼의 MySQL 의 mysql.h 파일을 새롭다 MySQL 라이브러리와 함께 사용하는 일이 있습니다.


E.3. DBUG 패키지

MySQL 서버와 많은 MySQL 클라이언트는,DBUG 패키지(오리지날 개발자는 Fred Fish )에 의해서 컴파일 되고 있습니다.디버그용으로 MySQL (을)를 설정했을 경우, 디버그 되고 있는 내용에 관한 트레이스 파일을 취득할 수 있습니다. See 항E.1.2. 「트레이스 파일의 작성」 .

디버그 패키지를 사용하려면 ,--debug="..." 또는 -#... 옵션을 지정해 프로그램을 기동합니다.

많은 MySQL 프로그램에는 디폴트의 디버그 문자열이 있어,--debug 에 대해서 옵션을 지정하지 않았던 경우에 사용됩니다.디폴트의 트레이스 파일은 통상,Unix 그럼 /tmp/programname.trace ,Windows 그럼 \programname.trace 입니다.

디버그 컨트롤 문자열은, 이하와 같이 코론으로 단락지어진 일련의 필드입니다.

<field_1>:<field_2>:...:<field_N>

각 필드의 구성요소는, 플래그 문자열(필수)과 후속 한다 "," 및 콤마 단락 수식자 일람(임의)입니다.

flag[,modifier,modifier,...,modifier]

현시점에서 인식되는 플래그 문자는 이하대로입니다.

플래그 | 설명
d | 현재 상태에 대해서 DBUG_<N> 매크로로부터의 출력을 유효하게 한다.키워드를 수반한다 DBUG 매크로에 관한 출력만이 선택되는 키워드 일람이 후속 하는 경우가 있다.키워드 일람이 공백이 되어 있는 경우, 모든 매크로에 관한 출력인 것을 나타낸다.
D | 각 디버거 출력행의 뒤의 지연.인수는 지연 할 시간(1/10 초단위의 수).머신의 성능에 따라서 다르다.즉,-#D,20 하 2 초지연 하는 것을 나타낸다.
f | 디버그와 트레이스의 한편 또는 양쪽 모두를 제한해, 지정된 함수의 일람에 프로파일을 설정한다.주의: 일람이 공백이 되어 있는 경우, 모든 함수가 무효가 된다.적절한 "d" 또는 "t" 플래그의 지정이 여전히 필요.이 플래그에 의해서 함수의 동작이 제한되는 것은, 함수가 유효하게 되어 있는 경우에 한정된다.
F | 디버그 또는 트레이스 출력의 각 행에 대응한 원시 파일명을 식별한다.
i | 디버그 또는 트레이스 출력의 각 행에 대응했다 PID 또는 스레드 ID (을)를 가지는 프로세스를 식별한다.
g | 프로파일을 유효하게 한다.프로그램의 프로파일에 사용할 수 있는 정보를 포함한 파일 'dbugmon.out' (을)를 작성한다.일람의 함수에만 대해 프로파일을 선택하는 키워드의 일람이 후속 하는 경우가 있다.일람이 공백이 되어 있는 경우, 모든 함수가 고려된다.
F | 디버그 또는 트레이스 출력의 각 행에 대응한 원시 파일행 번호를 식별한다.
n | 디버그 또는 트레이스 출력의 각 행에 대응한 현재의 함수의 네스트 심도를 인쇄한다.
N | dbug 출력의 각 행에 번호를 설정한다.
o | 디버거 출력 스트림을 지정 파일에 리디렉트 한다.디폴트 출력은 stderr 이다.
O | o (와)과 같이.다만, 기입마다 파일이 실제로 플래시 된다.필요에 따라서, 파일은 닫혀져 각 기입동안에 재차 열린다.
p | 디버거의 조작을 지정 프로세스에 제한한다.프로세스는,DBUG_PROCESS 매크로로 식별되어 실행되는 디버거 조작의 일람에 포함되는 것과 일치해야 한다.
P | 디버그 또는 트레이스 출력의 각 행에 대응한 현재의 프로세스명을 인쇄한다.
r | 새로운 스테이터스로 이행할 때에, 이전의 스테이터스의 함수 네스트 레벨을 계승하지 않는다.. 출력의 개시 위치가 왼쪽 마진인 경우에 유효.
S | 0 이외의 값이 _sanity() (으)로부터 돌려주어질 때까지, 디버그 대상의 각 함수로 함수 _sanity(_file_,_line_) (을)를 실행한다(메모리 리크를 검출하기 위해서 safemalloc (와)과 함께 사용되는 것이 많다).
t | 함수 호출의 유효화/ 트레이스행의 종료.최대 트레이스 레벨을 수치로 지정하는 일람(수식자가 1 개만 포함되어 있다)가 후속 하는 경우가 있다.이 레벨을 넘으면, 디버그 매크로와 트레이스 매크로의 머지않아에 대해서도 출력은 실행되지 않는다.디폴트는 컴파일 시간 옵션이다.

쉘 커멘드 라인에 표시되는 디버그 컨트롤 문자열("-#" 의 일반적인 용도는, 응용 프로그램에 대한 컨트롤 문자열의 도입)의 예를 이하에 나타냅니다.

-#d:t
-#d:f,main,subr1:F:L:t,20
-#d,input,output,files:n
-#d:t:i:O,\\mysqld.trace

MySQL 그리고 출력하기 위한 일반적인 태그(d 옵션 첨부)는,enter ,exit ,error ,warning ,info ,loop 입니다.


E.4. 락 방법

ISAM/MyISAM 및 HEAP 테이블의 테이블 락,BDB 테이블의 페이지 레벨 락,InnoDB 테이블의 행 레벨 락만이,MySQL 그리고 현재 서포트되고 있습니다. See 항5.3.1. 「MySQL 의 테이블 락 방법」 . INSERT 스테이트먼트간에 경합이 없는 경우(레코드 또는 데이터의 삭제에 의한 빈영역을 묻는 것이 아니라, 테이블 파일 말미에 추가하는 경우는 언제라도),MyISAM 테이블에서는 INSERT (와)과 SELECT (을)를 락 없이 자유롭게 조합할 수 있습니다.

버젼 3.23.33 에서는, 시스템에 있어서의 테이블 락의 경합을 Table_locks_waited 및 Table_locks_immediate 환경 변수를 확인해 분석할 수 있게 되었습니다.

테이블형을 행 레벨 락과 함께 사용할지를 결정하려면 , 어플리케이션의 처리 내용과 데이터의 선택/ 갱신 패턴을 확인할 필요가 있습니다.

행 락의 이점:

  • 다수의 스레드내가 다른 레코드에 액세스 할 때에 락의 경합이 적다.

  • 롤백(rollback)의 변경이 적다.

  • 단일 레코드를 장시간 잠글 수 있다.

행 락의 결점:

  • 페이지 레벨 락 또는 테이블 락보다 많은 메모리를 소비한다.

  • 테이블의 광범위하고 실행하는 경우, 다수의 락이 필요하게 되기 위해, 페이지 레벨 락 또는 테이블 락보다 처리 속도가 저하한다.

  • 데이터의 대부분으로 GROUP BY (을)를 빈번히 실행하는지, 테이블 전체를 빈번히 스캔 할 필요가 있는 경우, 다른 락보다 분명하게 효율이 악화된다.

  • 높은 락 레벨을 사용하면, 타입이 다른 락을 서포트해, 행 레벨 락의 경우와 같게 락 오버헤드가 감소하도록(듯이) 어플리케이션을 조정하는 것도 용이하다.

이하의 경우, 페이지 레벨/ 행 레벨 락보다 테이블 락이 적합합니다.

  • 대부분이 읽기

  • 엄밀한 키로의 읽기 및 갱신.이 경우,1 개의 키 읽기로 취득할 수 있다 1 개의 레코드를 갱신 또는 삭제한다.

    UPDATE table_name SET column=value WHERE unique_key#
DELETE FROM table_name WHERE unique_key=#

  • SELECT (와)과 INSERT (및 소수의 UPDATE 및 DELETE 스테이트먼트)를 조합한다.

  • 다수의 스캔 또는 GROUP BY (을)를 테이블 전체로 실행한다(써 없음).

행 레벨/ 페이지 레벨 락 이외의 다른 옵션:

버젼 관리(MySQL 그럼 병렬 INSERT 에 사용).다수의 독해와 동시에 단일의 기입이 가능합니다.즉, 데이타베이스/ 테이블에서는, 유저가 액세스를 개시했던 시기에 근거해, 다른 뷰가 같은 데이터에 관해서 서포트됩니다.이것은 시간 여행에 비유하는 일도, 기입시 카피, 카피 온디멘드라고 부를 수도 있습니다.

많은 경우, 카피 온디멘드는, 페이지 레벨 또는 행 레벨의 락보다 아득하게 우수합니다.다만, 최악의 경우, 통상의 락보다 아득하게 대량의 메모리를 소비합니다.

행 레벨 락 대신에, 어플리케이션 레벨 락(MySQL (으)로의 get_lock/release_lock (와)과 같이)를 사용할 수 있습니다.말할 필요도 없이, 이 락이 도움이 되는 것은 정상적으로 동작하는 어플리케이션에 한정됩니다.

많은 경우, 어플리케이션에 최적인 락 타입은 경험에 근거해 추측할 수 있습니다.그러나, 지정된 락 타입이 다른 락 타입보다 바람직하다고 판단하는 것은 일반적으로 지극히 곤란합니다.모든 것이 어플리케이션에 의존하고 있어, 어플리케이션에 있어서의 다른 부분에는 다른 락 타입이 필요하게 되기 때문입니다.

MySQL (으)로의 락에 관한 힌트를 이하에 나타냅니다.

많은 Web 어플리케이션에서는, 많은 선택, 일부의 삭제, 갱신이 주로 키로 실행되어 삽입이 특정의 테이블에 대해서 실행됩니다. MySQL 의 기본 설정은, 상기에 적절한 상태가 되어 있습니다.

동일 테이블내의 레코드를 대량으로 확인할 필요가 있는 갱신과 선택을 병용 하지 않는 경우, 동시 유저는 문제가 되지 않습니다.

동일 테이블로 삽입과 삭제를 병용 하는 경우,INSERT DELAYED 하지만 도움이 되는 일이 있습니다.

또,LOCK TABLES (을)를 사용해 처리 속도를 향상시킬 수도 있습니다(단일 락으로의 다수의 갱신은, 락 없음의 갱신보다 아득하게 고속으로 ).복수의 테이블에 분할하는 것도 유효한 대책입니다.

MySQL (으)로의 테이블 락에 처리 속도의 문제가 있는 경우, 테이블의 일부를InnoDB 또는 BDB 테이블로 변환하고 해결할 수 있기도 합니다. See 항7.5. 「InnoDB 테이블」 . See 항7.6. 「BDB 또는 BerkeleyDB 테이블」 .

이 메뉴얼의 최적화에 관한 섹션에서는, 어플리케이션의 조정 방법의 다종 다양한 국면에 붙어 채택하고 있습니다. See 항5.2.13. 「그 외의 최적화의 힌트」 .


E.5. RTS 스레드에 관한 코멘트

RTS 스레드패키지와 MySQL 의 병용을 시도했는데, 이하의 문제가 발생했습니다.

이러한 패키지에서는, 다수의 POSIX 호출이 사용되는 것 외에 모든 함수의 나팔을 작성하는데 매우 시간이 걸립니다.거기서, 스레드라이브라리를 최신의 POSIX 사양으로 변경하는 것이 간단하지 않을까 생각하게 되었습니다.

일부의 나팔은 작성이 끝난 상태입니다.상세한 것에 대하여는,mysys/my_pthread.c (을)를 참조해 주세요.

적어도 이하를 변경할 필요가 있습니다.

pthread_get_specific 그럼 1 개의 인수가 사용됩니다. sigwait 그럼 2 개의 인수가 사용됩니다. 많은 함수(적어도 pthread_cond_wait ,pthread_cond_timedwait) (으)로부터 에러시에 에러 코드가 돌려주어질 필요가 있습니다.여기에서는 -1 하지만 돌려주어져errno 하지만 설정됩니다.

이제(벌써) 1 개의 문제는, 유저 레벨의 스레드에 의해서 ALRM 시그널이 사용되어 그 때문에(위해) 많은 함수(read ,write ,open... )(이)가 중단되는 것입니다. MySQL 그럼, 중단된 모든 함수에 있어서의 세치기에 대해서 재시행할 필요가 있습니다만, 확인하는 것은 용이하지는 않습니다.

해결되어 있지 않은 최대의 문제는 이하대로입니다.

스레드레벨의 알람을 취득하기 위해(때문에),mysys/thr_alarm.c (을)를 변경해,pthread_cond_timedwait() 그리고 알람과 알람의 사이에 대기했습니다만, 에러 EINTR 그리고 중단되었습니다.원인을 조사하기 위해서 스레드라이브라리의 디버그를 시도했지만, 간단한 해결책은 발견되지 않았습니다.

MySQL (와)과 RTS 스레드의 병용을 시도하는 경우, 이하를 실시하는 것을 추천합니다.

  • MySQL 그리고 사용되는 함수를 스레드라이브라리로부터 POSIX (으)로 변경한다. 변경하는데 시간은 걸리지 않는다.

  • -DHAVE_rts_threads 그리고 모든 라이브러리를 컴파일 한다.

  • thr_alarm (을)를 컴파일 한다.

  • 실장에 약간의 차이가 있는 경우,my_pthread.h (와)과 my_pthread.c 의 변경에 의해 수정할 수 있다.

  • thr_alarm (을)를 실행한다.실행시에 `` 경고'' ,`` 에러'' , 중단 메세지의 모두 표시되지 않았던 경우, 정상적으로 실행되고 있습니다.Solaris 그리고 정상적으로 실행되었을 경우의 예를 이하에 나타냅니다.

    Main thread: 1
Thread 0 (5) started
Thread: 5  Waiting
process_alarm
Thread 1 (6) started
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 1 (1) sec
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 2 (2) sec
Thread: 6  Simulation of no alarm needed
Thread: 6  Slept for 0 (3) sec
Thread: 6  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 4 (4) sec
Thread: 6  Waiting
process_alarm
thread_alarm
Thread: 5  Slept for 10 (10) sec
Thread: 5  Waiting
process_alarm
process_alarm
thread_alarm
Thread: 6  Slept for 5 (5) sec
Thread: 6  Waiting
process_alarm
process_alarm

...
thread_alarm
Thread: 5  Slept for 0 (1) sec
end


E.6. 다른 스레드패키지간의 차이

MySQL (은)는, 사용되는 스레드패키지에 의해서 크게 좌우됩니다.그 때문에,MySQL 에 적절한 플랫폼을 선택하는 경우, 스레드패키지는 지극히 중요합니다.

스레드패키지에는, 적어도 이하의 3 종류가 있습니다.

  • 단일 프로세스내의 유자스레드.스레드의 변환은 알람에 의해서 관리되어 스레드라이브라리가 모든 비스레드세이후 함수를 락에 의해서 관리한다.실행중의 스레드가 데이터를 대기해야 하는 경우, 읽어내, 써, 선택등의 조작은 통상, 다른 스레드로 전환하는 스레드 고유의 select 그리고 관리된다.유자스레드패키지가 표준 라이브러리(낡은 버젼의 FreeBSD 및 BSDI 스레드)에 통합되고 있는 경우, 그 패키지에 필요한 오버헤드는, 모든 안전하지 않은 호출(MIT-pthread ,FSU Pthread ,RTS thread )에 매핑 해야 하는 스레드패키지보다 적어도 된다.일부의 환경(예를 들어 SCO )에서는, 모든 시스템 콜이 스레드세이후이므로, 매핑은 매우 용이하다(SCO 에 있어서의 FSU Pthread ).결점：매핑 된 모든 호출에 필요한 시간은 극히 적어, 모든 상황에 대처하는 것이 지극히 어렵다.통상, 스레드패키지에 의해서 처리되지 않는 시스템 콜도 몇개인가 존재한다(MIT-pthread , 소켓 등).스레드의 스케줄은 항상 최적이다고는 할 수 없다.

  • 개별 프로세스내의 유자스레드.스레드 변환은 커넬에 의해서 행해져 모든 데이터는 스레드간에 공유된다.스레드패키지는, 스레드간에 데이터가 공유되도록(듯이) 표준 스레드 호출을 관리한다.이 방법은 LinuxThread 그리고 사용되고 있다.결점：프로세스가 대량.스레드 작성이 늦다.1 개의 스레드가 크래쉬 했을 경우, 통상은 나머지의 스레드가 행 하고 있으므로, 그것들을 모두 강제 종료한 후에 재기동해야 한다.스레드 변환에는 약간의 코스트가 든다.

  • 카네르스레드.스레드 변환은, 스레드라이브라리 또는 커넬에 의해서 행해져 지극히 고속으로 있다.모두 1 개의 프로세스로 처리되지만, 일부의 시스템에서는 ps 에 따라서 다른 스레드가 표시되는 일이 있다.1 개의 스레드가 안?~ 되면, 프로세스 전체가 안?~ 된다.많은 시스템은 스레드세이후이며, 필요하게 되는 오버헤드는 극히 적는다.Solaris ,HP-UX ,AIX ,OSF/1 에는 카네르스레드가 있다.

일부의 시스템에서는, 시스템 라이브러리내의 유자레베르스레드에 의해서 카네르스레드가 관리된다.그러한 경우, 스레드 변환은 스레드라이브라리에 의해서만 가능하고, 커넬은 실제로는 `` 스레드 대응'' (은)는 아니다.


부록 F. 환경 변수

MySQL 그리고 직접 또는 간접적으로 사용되는 모든 환경 변수의 일람을 이하에 나타냅니다.이러한 변수의 상당수는, 이 메뉴얼의 다른 개소에도 기재되어 있습니다.

주의: 커멘드 라인의 옵션은 옵션 설정 파일과 환경 변수로 지정된 값에 우선해, 옵션 설정 파일내의 값은 환경 변수로 지정된 값에 우선합니다.

MySQL 의 동작을 수정하는 경우, 환경 변수는 아니고 옵션 설정 파일을 사용하는 것이 바람직한 것이 자주 있습니다. See 항4.1.2. 「my.cnf 옵션 설정 파일」 .

변수 | 설명
CXX | configure 실행시에 C++ 컴파일러로 설정한다.
CC | configure 실행시에 C 컴파일러로 설정한다.
CFLAGS | configure 실행시에 사용한다 C 컴파일러의 플래그.
CXXFLAGS | configure 실행시에 사용한다 C++ 컴파일러의 플래그.
DBI_USER | Perl DBI 의 디폴트 유저명.
DBI_TRACE | Perl DBI 의 트레이스시에 사용.
HOME | mysql 역사 파일의 디폴트 패스는 $HOME/.mysql_history 이다.
LD_RUN_PATH | libmysqlclient.so 의 장소를 지정하기 위해서 사용.
MYSQL_DEBUG | 디버그시의 디버그- 트레이스 옵션.
MYSQL_HISTFILE | mysql 역사 파일의 패스.
MYSQL_HOST | mysql 커멘드 라인 클라이언트에 의해서 사용되는 디폴트 호스트명.
MYSQL_PS1 | mysql 커멘드 라인 클라이언트로 사용하는 커멘드 prompt. See 항4.9.2. 「mysql (커멘드 라인 툴)」 .
MYSQL_PWD | mysqld 접속시의 디폴트 패스워드.사용하면 시큐러티가 확보되지 않는 것에 주의한다.
MYSQL_TCP_PORT | 디폴트 TCP/IP 포토.
MYSQL_UNIX_PORT | 디폴트 소켓.localhost 에의 접속에 사용.
PATH | MySQL 프로그램을 검색하기 위해서 쉘로 사용.
TMPDIR | 텐포라리테이불 또는 임시 파일이 작성되는 디렉토리.
TZ | 로컬 타임 존으로 설정된다. See 항A.4.6. 「타임 존의 문제」 .
UMASK_DIR | 디렉토리 작성시의 유저 디렉토리 작성 마스크.UMASK (와)과의 AND 연산이 실행되는 것에 주의한다.
UMASK | 파일 작성시의 유저 파일 작성 마스크.
USER | mysqld 에의 접속시에 사용하는,Windows 위의 디폴트 유저.


부록 G. MySQL 의 정규 표현

정규 표현(regex )(은)는, 복잡한 검색을 지정하기 위한 유효한 방법의 1 개입니다.

MySQL 그럼,Henry Spencer 의 정규 표현이 실장되고 있습니다만, 그 목적은 POSIX 1003.2 에 적합하는 것입니다.MySQL 그럼, 확장 버젼이 사용되고 있습니다.

여기에서는 간단한 설명에 세워 상세한 것에 대하여는 생략 하고 있습니다.상세한 정보를 입수하려면 , 소스 디스트리뷰션에 포함되어 있다 Henry Spencer 의 regex(7) 메뉴얼 페이지를 참조해 주세요. See 부록 C. 협력자 .

정규 표현에서는, 일련의 문자열을 기술합니다.가장 단순한 regexp (은)는, 특수 문자를 포함하지 않는 형식입니다.예를 들어,regexp hello 하 hello 에만 매치합니다.

단순하지 않은 형식의 정규 표현은, 특수한 구성요소를 포함하고 있어 복수의 문자열에 매치합니다.예를 들어,regexp hello|word (은)는 문자열 hello 또는 문자열 word 에 매치합니다.

한층 더 복잡한 예는 regexp B[an]*s 입니다.문자열 Bananas ,Baaaaas ,Bs 의 어느 것에도 매치하는 것 외에 이것들 이외로 선두가 B , 말미가 s (이)가 되어 있어, 한편, 선두와 말미의 사이에 a 또는 n 하지만 포함되어 있다(문자수는 묻지 않는다) 문자열의 모두에게 매치합니다.

정규 표현에서는, 이하의 특수한 문자 또는 구성요소를 사용할 수 있습니다.

  • ^

    문자열의 선두에 성냥.

    mysql> SELECT "fo\nfo" REGEXP "^fo$";           -> 0
mysql> SELECT "fofo" REGEXP "^fo";              -> 1

  • $

    문자열의 말미에 성냥.

    mysql> SELECT "fo\no" REGEXP "^fo\no$";         -> 1
mysql> SELECT "fo\no" REGEXP "^fo$";            -> 0

  • .

    모든 문자(개행도 포함한다)에 성냥.

    mysql> SELECT "fofo" REGEXP "^f.*";             -> 1
mysql> SELECT "fo\nfo" REGEXP "^f.*";           -> 1

  • a*

    연속한다 0 문자 이상의 a 에 성냥.

    mysql> SELECT "Ban" REGEXP "^Ba*n";             -> 1
mysql> SELECT "Baaan" REGEXP "^Ba*n";           -> 1
mysql> SELECT "Bn" REGEXP "^Ba*n";              -> 1

  • a+

    연속한다 1 문자 이상의 a 에 성냥.

    mysql> SELECT "Ban" REGEXP "^Ba+n";             -> 1
mysql> SELECT "Bn" REGEXP "^Ba+n";              -> 0

  • a?

    0 문자 또는 1 문자의 a 에 성냥.

    mysql> SELECT "Bn" REGEXP "^Ba?n";              -> 1
mysql> SELECT "Ban" REGEXP "^Ba?n";             -> 1
mysql> SELECT "Baan" REGEXP "^Ba?n";            -> 0

  • de|abc

    연속한다 de 또는 abc 에 성냥.

    mysql> SELECT "pi" REGEXP "pi|apa";             -> 1
mysql> SELECT "axe" REGEXP "pi|apa";            -> 0
mysql> SELECT "apa" REGEXP "pi|apa";            -> 1
mysql> SELECT "apa" REGEXP "^(pi|apa)$";        -> 1
mysql> SELECT "pi" REGEXP "^(pi|apa)$";         -> 1
mysql> SELECT "pix" REGEXP "^(pi|apa)$";        -> 0

  • (abc)*

    문자열 abc 의 0 회이상의 반복에 성냥.

    mysql> SELECT "pi" REGEXP "^(pi)*$";            -> 1
mysql> SELECT "pip" REGEXP "^(pi)*$";           -> 0
mysql> SELECT "pipi" REGEXP "^(pi)*$";          -> 1

  • {1} , {2,3}

    직전의 패턴이 다수 출현하는 경우, 그것들에 매치한다 regexp (을)를 한층 더 일반적인 방식으로 기술할 수 있습니다.

    • a*

      a{0,} 에 고쳐 쓰는 것이 가능.

    • a+

      a{1,} 에 고쳐 쓰는 것이 가능.

    • a?

      a{0,1} 에 고쳐 쓰는 것이 가능.

    보다 정확하게 표현하면, 패턴의 직후의 외모내에 정수 i 하지만 1 개 있어 콤마가 없는 경우, 패턴에 적합한다 i 회의 순서에 매치합니다.패턴의 직후의 외모내에 정수 i (와)과 콤마가 1 개씩 있는 경우, 패턴에 적합한다 i 회이상의 순서에 매치합니다. 패턴의 직후의 외모내에 2 개의 정수(i (와)과 j )(이)가 있는 경우, 패턴에 적합한다 i ~ j 회의 순서에 매치합니다.

    2 개의 인수는,0 (으)로부터 RE_DUP_MAX (디폴트는 255 )까지의 범위에 포함되어 있을 필요가 있습니다.인수가 2 개 있는 경우,2 번째는 1 번째 이상이 아니면 안됩니다.

  • [a-dX] , [^a-dX]

    a ,b ,c ,d ,X 의 어느 쪽인가에 해당한다(^ 하지만 사용되고 있는 경우, 이러한 어느 것에도 해당하지 않는다) 문자에 매치합니다.] (을)를 리터럴로서 포함하려면 ,[ 의 직후에 기술할 필요가 있습니다.- (을)를 리터럴로서 포함하려면 , 최초 또는 마지막에 기술할 필요가 있습니다.따라서,[0-9] (은)는 임의의 10 진수치에 매치합니다.의미가 정의되어 있지 않은 문자가 [] 안에 존재하는 경우, 그 문자는 특별한 의미를 가지지 않고, 자기 자신에게만 매치합니다.

    mysql> SELECT "aXbc" REGEXP "[a-dXYZ]";         -> 1
mysql> SELECT "aXbc" REGEXP "^[a-dXYZ]$";       -> 0
mysql> SELECT "aXbc" REGEXP "^[a-dXYZ]+$";      -> 1
mysql> SELECT "aXbc" REGEXP "^[^a-dXYZ]+$";     -> 0
mysql> SELECT "gheis" REGEXP "^[^a-dXYZ]+$";    -> 1
mysql> SELECT "gheisa" REGEXP "^[^a-dXYZ]+$";   -> 0

  • [[.characters.]]

    조합 요소의 문자 순서.순서는, 외모내의 리스트에 포함되는 단일의 요소입니다.외모 표현에 복수 문자의 조합 요소가 포함되어 있는 경우,2 문자 이상으로 매치합니다.예를 들어, 조합 순서에 조합 요소 ch 하지만 포함되어 있으면, 정규 표현 [[.ch.]]*c 하 chchcc 의 최초의 5 문자에 매치합니다.

  • [=character_class=]

    등가 클래스이며, 그것 자신을 포함해 그것과 등가인 모든 조합 요소의 문자열을 의미합니다.

    예를 들어,o (와)과 (+) 하지만 등가 클래스의 멤버인 경우,[[=o=]] ,[[=(+)=]] ,[o(+)] (은)는 모두 동의어입니다.등가 클래스를 범위의 종료 위치로 할 수 없습니다.

  • [:character_class:]

    외모 표현에 대해 [: (와)과 :] 그리고 둘러싸인 문자 클래스명은, 그 클래스에 속하는 모든 문자의 리스트를 의미합니다.표준 문자 클래스명은 이하대로입니다.

    명칭 | 명칭 | 명칭
    alnum | digit | punct
    alpha | graph | space
    blank | lower | upper
    cntrl | print | xdigit

    이것들은,ctype(3) 메뉴얼 페이지로 정의된 문자 클래스를 의미합니다.로케일에 의해, 다른 문자 클래스가 제공되기도 합니다.문자 클래스를 범위의 엔드 포인트로 할 수 없습니다.

    mysql> SELECT "justalnums" REGEXP "[[:alnum:]]+";       -> 1
mysql> SELECT "!!" REGEXP "[[:alnum:]]+";               -> 0

  • [[:<:]] , [[:>:]]

    각각 단어의 초와 마지막의 NULL 문자열에 매치합니다.단어 문자 순서 가운데, 전후에 다른 단어 문자가 존재하지 않는 것이 단어라고 정의되고 있습니다.단어 문자는 alnum 문자(ctype(3) 그리고 정의) 또는 언더 스코아(_ )입니다.

    mysql> SELECT "a word a" REGEXP "[[:<:]]word[[:>:]]";      -> 1
mysql> SELECT "a xword a" REGEXP "[[:<:]]word[[:>:]]";     -> 0

mysql> SELECT "weeknights" REGEXP "^(wee|week)(knights|nights)$"; -> 1


부록 H. GNU General Public License

Version 2, June 1991

Copyright © 1989, 1991 Free Software Foundation, Inc.
59 Temple Place - Suite 330, Boston, MA 02111-1307, USA
Everyone is permitted to copy and distribute verbatim copies
of this license document, but changing it is not allowed.

Preamble

The licenses for most software are designed to take away your freedom to share and change it. By contrast, the GNU General Public License is intended to guarantee your freedom to share and change free software---to make sure the software is free for all its users. This General Public License applies to most of the Free Software Foundation's software and to any other program whose authors commit to using it. (Some other Free Software Foundation software is covered by the GNU Library General Public License instead.) You can apply it to your programs, too.

When we speak of free software, we are referring to freedom, not price. Our General Public Licenses are designed to make sure that you have the freedom to distribute copies of free software (and charge for this service if you wish), that you receive source code or can get it if you want it, that you can change the software or use pieces of it in new free programs; and that you know you can do these things.

To protect your rights, we need to make restrictions that forbid anyone to deny you these rights or to ask you to surrender the rights. These restrictions translate to certain responsibilities for you if you distribute copies of the software, or if you modify it.

For example, if you distribute copies of such a program, whether gratis or for a fee, you must give the recipients all the rights that you have. You must make sure that they, too, receive or can get the source code. And you must show them these terms so they know their rights.

We protect your rights with two steps: (1) copyright the software, and (2) offer you this license which gives you legal permission to copy, distribute and/or modify the software.

Also, for each author's protection and ours, we want to make certain that everyone understands that there is no warranty for this free software. If the software is modified by someone else and passed on, we want its recipients to know that what they have is not the original, so that any problems introduced by others will not reflect on the original authors' reputations.

Finally, any free program is threatened constantly by software patents. We wish to avoid the danger that redistributors of a free program will individually obtain patent licenses, in effect making the program proprietary. To prevent this, we have made it clear that any patent must be licensed for everyone's free use or not licensed at all.

The precise terms and conditions for copying, distribution and modification follow.

GNU GENERAL PUBLIC LICENSE TERMS AND CONDITIONS FOR COPYING, DISTRIBUTION AND MODIFICATION

  1. This License applies to any program or other work which contains a notice placed by the copyright holder saying it may be distributed under the terms of this General Public License. The ``Program'', below, refers to any such program or work, and a ``work based on the Program'' means either the Program or any derivative work under copyright law: that is to say, a work containing the Program or a portion of it, either verbatim or with modifications and/or translated into another language. (Hereinafter, translation is included without limitation in the term ``modification''.) Each licensee is addressed as ``you''.

    Activities other than copying, distribution and modification are not covered by this License; they are outside its scope. The act of running the Program is not restricted, and the output from the Program is covered only if its contents constitute a work based on the Program (independent of having been made by running the Program). Whether that is true depends on what the Program does.

  2. You may copy and distribute verbatim copies of the Program's source code as you receive it, in any medium, provided that you conspicuously and appropriately publish on each copy an appropriate copyright notice and disclaimer of warranty; keep intact all the notices that refer to this License and to the absence of any warranty; and give any other recipients of the Program a copy of this License along with the Program.

    You may charge a fee for the physical act of transferring a copy, and you may at your option offer warranty protection in exchange for a fee.

  3. You may modify your copy or copies of the Program or any portion of it, thus forming a work based on the Program, and copy and distribute such modifications or work under the terms of Section 1 above, provided that you also meet all of these conditions:

    1. You must cause the modified files to carry prominent notices stating that you changed the files and the date of any change.

    2. You must cause any work that you distribute or publish, that in whole or in part contains or is derived from the Program or any part thereof, to be licensed as a whole at no charge to all third parties under the terms of this License.

    3. If the modified program normally reads commands interactively when run, you must cause it, when started running for such interactive use in the most ordinary way, to print or display an announcement including an appropriate copyright notice and a notice that there is no warranty (or else, saying that you provide a warranty) and that users may redistribute the program under these conditions, and telling the user how to view a copy of this License. (Exception: if the Program itself is interactive but does not normally print such an announcement, your work based on the Program is not required to print an announcement.)

    These requirements apply to the modified work as a whole. If identifiable sections of that work are not derived from the Program, and can be reasonably considered independent and separate works in themselves, then this License, and its terms, do not apply to those sections when you distribute them as separate works. But when you distribute the same sections as part of a whole which is a work based on the Program, the distribution of the whole must be on the terms of this License, whose permissions for other licensees extend to the entire whole, and thus to each and every part regardless of who wrote it.

    Thus, it is not the intent of this section to claim rights or contest your rights to work written entirely by you; rather, the intent is to exercise the right to control the distribution of derivative or collective works based on the Program.

    In addition, mere aggregation of another work not based on the Program with the Program (or with a work based on the Program) on a volume of a storage or distribution medium does not bring the other work under the scope of this License.

  4. You may copy and distribute the Program (or a work based on it, under Section 2) in object code or executable form under the terms of Sections 1 and 2 above provided that you also do one of the following:

    1. Accompany it with the complete corresponding machine-readable source code, which must be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    2. Accompany it with a written offer, valid for at least three years, to give any third-party, for a charge no more than your cost of physically performing source distribution, a complete machine-readable copy of the corresponding source code, to be distributed under the terms of Sections 1 and 2 above on a medium customarily used for software interchange; or,

    3. Accompany it with the information you received as to the offer to distribute corresponding source code. (This alternative is allowed only for noncommercial distribution and only if you received the program in object code or executable form with such an offer, in accord with Subsection b above.)

    The source code for a work means the preferred form of the work for making modifications to it. For an executable work, complete source code means all the source code for all modules it contains, plus any associated interface definition files, plus the scripts used to control compilation and installation of the executable. However, as a special exception, the source code distributed need not include anything that is normally distributed (in either source or binary form) with the major components (compiler, kernel, and so on) of the operating system on which the executable runs, unless that component itself accompanies the executable.

    If distribution of executable or object code is made by offering access to copy from a designated place, then offering equivalent access to copy the source code from the same place counts as distribution of the source code, even though third parties are not compelled to copy the source along with the object code.

  5. You may not copy, modify, sublicense, or distribute the Program except as expressly provided under this License. Any attempt otherwise to copy, modify, sublicense or distribute the Program is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

  6. You are not required to accept this License, since you have not signed it. However, nothing else grants you permission to modify or distribute the Program or its derivative works. These actions are prohibited by law if you do not accept this License. Therefore, by modifying or distributing the Program (or any work based on the Program), you indicate your acceptance of this License to do so, and all its terms and conditions for copying, distributing or modifying the Program or works based on it.

  7. Each time you redistribute the Program (or any work based on the Program), the recipient automatically receives a license from the original licensor to copy, distribute or modify the Program subject to these terms and conditions. You may not impose any further restrictions on the recipients' exercise of the rights granted herein. You are not responsible for enforcing compliance by third parties to this License.

  8. If, as a consequence of a court judgment or allegation of patent infringement or for any other reason (not limited to patent issues), conditions are imposed on you (whether by court order, agreement or otherwise) that contradict the conditions of this License, they do not excuse you from the conditions of this License. If you cannot distribute so as to satisfy simultaneously your obligations under this License and any other pertinent obligations, then as a consequence you may not distribute the Program at all. For example, if a patent license would not permit royalty-free redistribution of the Program by all those who receive copies directly or indirectly through you, then the only way you could satisfy both it and this License would be to refrain entirely from distribution of the Program.

    If any portion of this section is held invalid or unenforceable under any particular circumstance, the balance of the section is intended to apply and the section as a whole is intended to apply in other circumstances.

    It is not the purpose of this section to induce you to infringe any patents or other property right claims or to contest validity of any such claims; this section has the sole purpose of protecting the integrity of the free software distribution system, which is implemented by public license practices. Many people have made generous contributions to the wide range of software distributed through that system in reliance on consistent application of that system; it is up to the author/donor to decide if he or she is willing to distribute software through any other system and a licensee cannot impose that choice.

    This section is intended to make thoroughly clear what is believed to be a consequence of the rest of this License.

  9. If the distribution and/or use of the Program is restricted in certain countries either by patents or by copyrighted interfaces, the original copyright holder who places the Program under this License may add an explicit geographical distribution limitation excluding those countries, so that distribution is permitted only in or among countries not thus excluded. In such case, this License incorporates the limitation as if written in the body of this License.

  10. The Free Software Foundation may publish revised and/or new versions of the General Public License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns.

    Each version is given a distinguishing version number. If the Program specifies a version number of this License which applies to it and ``any later version'', you have the option of following the terms and conditions either of that version or of any later version published by the Free Software Foundation. If the Program does not specify a version number of this License, you may choose any version ever published by the Free Software Foundation.

  11. If you wish to incorporate parts of the Program into other free programs whose distribution conditions are different, write to the author to ask for permission. For software which is copyrighted by the Free Software Foundation, write to the Free Software Foundation; we sometimes make exceptions for this. Our decision will be guided by the two goals of preserving the free status of all derivatives of our free software and of promoting the sharing and reuse of software generally.

    NO WARRANTY

  12. BECAUSE THE PROGRAM IS LICENSED FREE OF CHARGE, THERE IS NO WARRANTY FOR THE PROGRAM, TO THE EXTENT PERMITTED BY APPLICABLE LAW. EXCEPT WHEN OTHERWISE STATED IN WRITING THE COPYRIGHT HOLDERS AND/OR OTHER PARTIES PROVIDE THE PROGRAM ``AS IS'' WITHOUT WARRANTY OF ANY KIND, EITHER EXPRESSED OR IMPLIED, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. THE ENTIRE RISK AS TO THE QUALITY AND PERFORMANCE OF THE PROGRAM IS WITH YOU. SHOULD THE PROGRAM PROVE DEFECTIVE, YOU ASSUME THE COST OF ALL NECESSARY SERVICING, REPAIR OR CORRECTION.

  13. IN NO EVENT UNLESS REQUIRED BY APPLICABLE LAW OR AGREED TO IN WRITING WILL ANY COPYRIGHT HOLDER, OR ANY OTHER PARTY WHO MAY MODIFY AND/OR REDISTRIBUTE THE PROGRAM AS PERMITTED ABOVE, BE LIABLE TO YOU FOR DAMAGES, INCLUDING ANY GENERAL, SPECIAL, INCIDENTAL OR CONSEQUENTIAL DAMAGES ARISING OUT OF THE USE OR INABILITY TO USE THE PROGRAM (INCLUDING BUT NOT LIMITED TO LOSS OF DATA OR DATA BEING RENDERED INACCURATE OR LOSSES SUSTAINED BY YOU OR THIRD PARTIES OR A FAILURE OF THE PROGRAM TO OPERATE WITH ANY OTHER PROGRAMS), EVEN IF SUCH HOLDER OR OTHER PARTY HAS BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES.

END OF TERMS AND CONDITIONS

How to Apply These Terms to Your New Programs

If you develop a new program, and you want it to be of the greatest possible use to the public, the best way to achieve this is to make it free software which everyone can redistribute and change under these terms.

To do so, attach the following notices to the program. It is safest to attach them to the start of each source file to most effectively convey the exclusion of warranty; and each file should have at least the ``copyright'' line and a pointer to where the full notice is found.

one line to give the program's name and a brief idea of what it does.
Copyright (C) yyyy  name of author

This program is free software; you can redistribute it and/or modify
it under the terms of the GNU General Public License as published by
the Free Software Foundation; either version 2 of the License, or
(at your option) any later version.

This program is distributed in the hope that it will be useful,
but WITHOUT ANY WARRANTY; without even the implied warranty of
MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE.  See the
GNU General Public License for more details.

You should have received a copy of the GNU General Public License
along with this program; if not, write to the Free Software
Foundation, Inc., 59 Temple Place - Suite 330, Boston, MA  02111-1307, USA.

Also add information on how to contact you by electronic and paper mail.

If the program is interactive, make it output a short notice like this when it starts in an interactive mode:

Gnomovision version 69, Copyright (C) 19yy name of author
Gnomovision comes with ABSOLUTELY NO WARRANTY; for details type `show w'.
This is free software, and you are welcome to redistribute it
under certain conditions; type `show c' for details.

The hypothetical commands 'show w' and 'show c' should show the appropriate parts of the General Public License. Of course, the commands you use may be called something other than 'show w' and 'show c'; they could even be mouse-clicks or menu items---whatever suits your program.

You should also get your employer (if you work as a programmer) or your school, if any, to sign a ``copyright disclaimer'' for the program, if necessary. Here is a sample; alter the names:

Yoyodyne, Inc., hereby disclaims all copyright interest in the program
`Gnomovision' (which makes passes at compilers) written by James Hacker.

signature of Ty Coon, 1 April 1989
Ty Coon, President of Vice

This General Public License does not permit incorporating your program into proprietary programs. If your program is a subroutine library, you may consider it more useful to permit linking proprietary applications with the library. If this is what you want to do, use the GNU Library General Public License instead of this License.