이 섹션에서는 InnoDB-관련 명령어 옵션과 시스템 변수에 대해서 설명을 하기로 한다. 서버 스타트업 시점에 이 변수들을 명기함으로써 트루 또는 팰스 (true or false)인 시스템 변수를 활성화 시키거나, 또는 skip- 접두어를 사용해서 비활성화 시킨다. 예를 들면, InnoDB 체크섬을 활성화 또는 비활성화 시키기 위해서는, 명령어 라인에서 --innodb_checksums 또는 --skip-innodb_checksums 를 사용하거나, 옵션 파일에서 innodb_checksums 또는 skip-innodb_checksums를 사용한다. 수치 값을 가지는 시스템 변수는 명령어 라인에서 --var_name=value 형태를 사용하거나 또는 옵션 파일에서 var_name=value와 같이 사용하면 된다. 옵션 및 시스템 변수를 지정하는 것에 대한 보다 많은 정보는 Section 4.3, “Specifying Program Options”를 참고하기 바란다. 대부분의 시스템 변수는 런타임 시점에 변경시킬 수가 있다 (Section 5.2.4.2, “Dynamic System Variables”를 참조).
InnoDB 명령어 옵션:
서버가 InnoDB를 지원하도록 컴파일 되어 있다며, InnoDB 스토리지 엔진을 활성화 시킨다. --skip-innodb를 사용하면 InnoDB를 비활성화 시킬 수가 있다.
InnoDB로 하여금 MySQL 데이터 디렉토리에 /innodb_status.라는 이름의 파일을 생성하도록 한다. InnoDB는 주기적으로 SHOW ENGINE INNODB STATUS의 결과를 이 파일에 작성한다.
InnoDB 시스템 변수:
- innodb_additional_mem_pool_size
InnoDB가 데이터 디렉토리 정보와 다른 내부 데이터 구조를 저장하기 위해 사용하는 메모리 풀의 크기 (바이트 단위). 여러분이 어플리케이션에서 테이블을 많이 가질수록,여기에 할당해야 하는 메모리가 많이 필요하게 된다. 만일 InnoDB가 이 풀에 있는 메모리를 다 사용하게 되면, 이 엔진은 OS가 사용하는 메모리를 할당하기 시작하고, MySQL 에러 로그에 경고 메시지를 작성한다. 디폴트 값은 1MB가 된다.
- innodb_autoextend_increment
테이블스페이스가 가득 차게 되었을 때 자동-확장 테이블스페이스의 확장 크기 (MB단위). 디폴트는 8MB가 된다.
- innodb_buffer_pool_awe_mem_mb
이 엔진이 AWE 메모리에 있을 경우의 버퍼 풀의 크기. 이 변수는 32-비트 윈도우 시스템에만 적용된다. 만일 여러분이 사용하는 32-비트 윈도우 시스템이 4GB 이상의 메모리를 지원한다면, 소위 “Address Windowing Extensions”을 사용해서 InnoDB 버퍼 풀을 AWE 메모리에 할당할 수가 있다. 이 변수의 최대 가능 값은 63000이다. 만일 이 값이 0보다 크다면, innodb_buffer_pool_size는 InnoDB 가 AWE 메모리에 매핑되어 있는 mysqld의 32-비트 주소 스페이스에 있는 윈도우가 된다.innodb_buffer_pool_size의 가장 좋은 크기는 500MB이다.
AWE 메모리의 장점을 살리기 위해서는, 여러분 스스로 MySQL을 컴파일 할 필요가 있다. 이렇게 하기 위해 필요한 설정은 innobase/os/os0proj.c 소스 파일에서 찾아볼 수가 있다.
InnoDB가 자신의 테이블에 있는 데이터와 인덱스를 캐시하기 위해 사용하는 메모리 버퍼의 크기 (바이트 단위). 이 값을 크게 설정하면 할수록, 테이블에 있는 데이터를 접속하는데 필요한 I/O가 덜 생긴다. 지정된 데이터베이스 서버에서는, 이 값으로 메인 메모리의 80%까지를 설정할 수가 있다. 하지만, 이 값을 너무 크게 설정하게 되면 OS와 메인 메모리 할당 경쟁이 생기기 때문에 적절하게 설정하는 좋다.
InnoDB는 하드웨어 또는 데이터 파일의 오류에 대한 여분의 폴트 톨로런스 (fault-tolerance)를 보장하기 위해 디스크에서 읽는 모든 페이지에 대해서 체크섬 확인을 사용할 수 있다. 이러한 확인은 디폴트로 활성화 되어진다. 하지만, 거의 드문 경우지만 어떤 환경 (벤치마크를 구동 중에 있는 경우)하에서는 이러한 기능이 불필요할 수도 있으며, 이럴 경우에는 --skip-innodb_checksums를 사용해서 비활성화를 시킨다. 이 변수는 MySQL 5.0.3에서 추가되었다.
- innodb_commit_concurrency
동시에 실행되는 쓰레드의 숫자. 이 값이 0이 되면 동시성 제어 (concurrency control)가 비활성화 된다. 이 변수는 MySQL 5.0.12에서 추가되었다.
- innodb_concurrency_tickets
InnoDB에 동시에 들어갈 수 있는 쓰레드의 숫자는 innodb_thread_concurrency변수로 알아볼 수가 있다. 여러 개의 쓰레드가 이미 컨커런시 한계에 도달하였다면, 하나의 쓰레드만이 큐에 들어갈 수 있다. 하나이 쓰레드가 InnoDB에 들어가게 되면,innodb_concurrency_tickets의 값과 일치하는 “자유 티켓”의 숫자가 주어지고,쓰레드가 자신의 티켓을 사용하기 전 까지는 자유롭게 InnoDB에 들어가고 나올 수가 있다. 이런 후에는, 쓰레드는 다시금 일관성 검사를 하고 InnoDB에 다시 들어가려고 시도하게 된다. 이 변수는 MySQL 5.0.3에 추가되었다.
개별적인 데이터 파일의 경로와 크기. 각각의 데이터 파일에 대한 전체 경로는 여기에서 지정된 경로에 innodb_data_home_dir를 연결해서 구성된다. 파일의 크기는MB 또는 GB (1024MB)이며, M 또는 G를 붙인다. 파일 크기의 합은 최소 10MB이상이어야 한다. 만일 innodb_data_file_path를 지정하지 않는다면, 디폴트로 10MB 크기의 자동-확장 데이터 파일을 ibdata1라는 이름으로 하나 만들게 된다. 개별 파일의 크기 한계는 여러분이 사용하는 OS에 따라서 다르다. 대형 파일을 지원하는 OS에서는4GB 이상의 파일도 만들 수가 있다. 또한, 로우 디스크 파티션을 데이터 파일 형태로 사용할 수도 있다. Section 14.2.3.2, “공유 테이블스페이스에 대해서 로우 (Row) 디바이스 사용하기”를 참조할 것.
모든 InnoDB 데이터 파일에 대한 디렉토리 경로의 공통 부분. 이 값을 설정하지 않게 되면, 디폴트는 MySQL 데이터 디렉토리가 된다. 빈 스트링을 가지고 이 값을 설정할 수도 있는데, 이렇게 되면, 여러분은 innodb_data_file_path에 있는 절대 경로를 사용할 수가 있다.
디폴트로는, InnoDB은 모든 데이터를 두 번 저장하는데, 처음에는 이중 쓰기 버퍼(doublewrite buffer)에 저장하고, 다음에는 실제 데이터 파일에 저장한다. 이 변수는 디폴트로 활성화된다. 벤치 마크 테스트를 하거나 또는 최고의 성능이 필요한 경우에는 --skip-innodb_doublewrite를 사용해서 이 변수를 비활성화 시킬 수 있다. 이 변수는 MySQL 5.0.3에서 추가되었다.
만일 이 변수를 0으로 설정하면, InnoDB는 셧다운을 하기 전에 전체 퍼지 (full purge)와 삽입 버퍼 병합 (insert buffer merge)를 실행한다. 이러한 연산들은 몇 분의 시간이 걸리거나, 극단적인 경우에는 몇 시간이 걸릴 수도 있다. 만일 이 변수를 1로 설정하면,InnoDB는 셧 다운 시점이 이러한 연산들을 건너 띄게 된다. 이 변수의 디폴트 값은 1이다. 만일 여러분이 이 변수를 2로 설정한다면, InnoDB는 마치 MySQL이 크래시 된 것처럼 자신의 로그만을 플러시 하고 셧 다운은 진행하지 않는다; 실행되지 않은 트랜젝션은 잃어 버리게 되지만, 서버를 재 스타트업 시키면 크래시 복구는 실행된다. 이러한 값 2는 MySQL 5.0.5 이후에 사용되었으며, NetWare에서는 사용할 수 없다.
InnoDB에서의 파일 I/O 쓰레드의 숫자. 일반적으로, 이 변수는 디폴트로 4를 갖게 되지만, 윈도우에서는 이 숫자를 늘려 줌으로써 디스크 I/O가 좋아질 수가 있다. 유닉스에서는, 이 숫자를 늘려도 별 효과가 발생하지 않는다; InnoDB는 항상 디폴트 숫자만을 사용한다.
이 변수가 활성화 되어 있다면, InnoDB는 데이터 및 인덱스를 공유 테이블스페이스를 이용하는 대신에 자신의 .ibd 파일을 사용해서 새로운 파일을 생성한다. 디폴트는 공유 테이블스페이스에 테이블을 생성하는 것이다. Section 14.2.3.1, “테이블 당 테이블스페이스 사용하기”를 참조할 것.
- innodb_flush_log_at_trx_commit
innodb_flush_log_at_trx_commit이 0으로 설정되면, 로그 버퍼는 초 당 한번씩 로그 파일이 기록이 되고 디스크 연산에 대한 플러시는 로그 파일에서 실행되지만, 트랜젝션 실행 시점에는 아무것도 실행되지 않게 된다. 이 값이 1 (디폴트)로 설정되면,로그 버퍼는 각 트랜젝션이 실행될 때마다 로그 파일에 기록되고 로그 파일에서 디스크 연산에 대한 플러시가 실행된다. 2로 설정되면, 로그 버퍼는 각 실행 시점마다 파일로 기록되지만, 디스크 연산에 대한 플러시는 실행되지 않는다. 하지만, 로그 파일에 대한 플러시는 값이 2일 때에도 초당 한번씩 실행된다. 초당 1회의 플러시는 모든 초당 이루어진다고는 장담할 수가 없는데, 그 이유는 프로세스 스케쥴링 문제 때문이라는 점을 알아두자.
이 변수의 디폴트 값은 1이며, 이 값은 ACID와의 호환성을 위해 요구되는 값이다. 여러분은 이 값을 1 이외의 값으로 설정해서 보다 좋은 성능을 얻을 수는 있겠지만, 크래시가 나게 되면 한 순간에 모든 것을 잃어 버릴 수도 있다. 만일 이 값을 0으로 설정한다면, 어떠한 mysqld 프로세스 크래시라도. 만일 이 값을 2로 설정한다면, OS 크래시 또는 전원 불량을 통해서만 마지막 초 순간의 트랜젝션이 지워지게 된다. 하지만,InnoDB의 크래시 복구는 영향을 받지 않으며 따라서 크래시 복구는 변수 값에 상관없이 실행된다. 대다수의 OS와 몇몇 디스크들은 디스크에 대한 플러시 연산을 제대로 실행하지 못한다는 점을 알아두자.
Note: 트랜젝션을 사용하는 InnoDB을 이용한 리플리케이션 설정에서 내구성과 일관성을 최대로 확보하기 위해서는, 여러분이 사용하는 마스터 서버의 my.cnf 파일에서innodb_flush_log_at_trx_commit=1, sync_binlog=1, innodb_safe_binlog(MySQL 5.0.3 이전 버전의 경우)를 사용해야 한다. (innodb_safe_binlog는 5.0.3이후에는 필요가 없다.)
만일 fdatasync (디폴트)를 설정하면, InnoDB는 fsync()를 사용해서 데이터와 로그 파일을 플러시한다. 만일 O_DSYNC를 설정하면, InnoDB는 O_SYNC를 사용해서 로그 파일을 열고 플러시하지만, 데이터 파일을 플러시하기 위해서는 fsync()를 사용하게 된다. 만일 O_DIRECT 가 지정된다면 (몇몇 GNU/Linux 버전에서 사용 가능함), InnoDB는 O_DIRECT를 사용해서 데이터 파일을 열고, 데이터 파일과 로그 파일을 플러시하기 위해 fsync()를 사용한다. InnoDB는 fsync()를 fdatasync()대신에 사용하고, 대부분의 유닉스에서 O_DSYNC를 사용하는 것이 문제가 있기 때문에 이것을 디폴트로 사용하지 않는다는 점을 알아두자. 이 변수는 유닉스에만 연관이 되는 변수이다. 윈도우의 경우, 플러시 방식은 항상 async_unbuffered이며 이것을 변경할 수는 없다.
이 변수가 다른 값을 가지게 되면 InnoDB performance에 상당한 영향을 미치게 된다. 예를 들면, InnoDB 데이터와 로그 파일이 SAN에 존재하는 시스템에서는,innodb_flush_method를 O_DIRECT에 설정하면 단일 SELECT 명령문의 성능을 저하시키게 된다.
크래시 복구 모드.
Warning: 여러분이 깨져있는 데이터 베이스에서 테이블을 덤프 하고자 하는 위급한 상황에서만 이 변수를 0보다 크게 설정해야 한다! 이 변수가 취할 수 있는 값은 1에서 6이다. 각 변수의 값이 의미하는 것은 Section 14.2.8.1, “Forcing InnoDB Recovery”에서 설명하고 있다. 보다 안전성을 제공하기 위해서, InnoDB는 이 변수가 0보다 큰 경우에는 자신의 데이터를 변경하지 못하게 끔 하고 있다.
InnoDB 트랜젝션의 타임아웃은 롤백이 진행되기 전에 락을 대기하는 시간이다.InnoDB 는 자동으로 자신의 락 테이블에 있는 트랜젝션 데드락 (deadlock)를 검사하고 트랜젝션을 롤 백 한다. InnoDB는 LOCK TABLES 명령문을 사용해서 락 세트를 알려준다. 디폴트는 50초이다.
- innodb_locks_unsafe_for_binlog
이 변수는 InnoDB 검색과 인덱스 스캔에서 다음-키 (next-key) 락킹을 제어한다. 디폴트로는, 0으로 설정 되는데 (비활성화), 이것은 다음-키 락킹이 활성화 됨을 의미한다.
보통의 경우, InnoDB는 “next-key locking”이라는 알고리즘을 사용한다. InnoDB는 테이블 인덱스를 검색 또는 스캔을 하는 시점에 이 알고리즘을 이용해서 하위-레벨 락킹을 실행하는데, 이렇게 되면 자신이 직면하는 모든 인덱스 레코그에서 공유 또는 배타적인 락을 설정하게 된다. 따라서, 하위-레벨 락은 실제로 인덱스 레코트 락이 된다. The locks that InnoDB가 인덱스 레코드에 설정하는 락은 인덱스 레코드보다 앞에 있는 ‘갭 (gap)”에도 영향을 준다. 만일 사용자가 공유 또는 배타적인 락을 인덱스의 레코드 R 에 가지고 있다면, 다른 사용자는 새로운 인덱스 레코드를 R 앞에 삽입할 수 없게 된다. 이 변수를 활성화 시키게 되면 InnoDB는 검색 또는 인덱스 스캔에서 다음-키 락킹을 사용할 수 없게 된다. 다음-키 락킹은 외래-키 제약과 이중 키 검사를 확인하는데 사용할 수 있다. 이 변수를 활성화 시키면 팬텀 (phantom) 문제가 발생할 수도 있음을 알아두자: 여러분이 나중에 선택된 열에 있는 몇몇 컬럼을 업데이트 하고자 하는 의도를 가지고, 100보다 큰 식별자 값을 사용해서 child 테이블에서 모든 칠드런(children)을 읽고 락을 하기 원한다고 가정하자:
SELECT * FROM child WHERE id > 100 FOR UPDATE;
id 컬럼에 인덱스가 존재한다고 가정한다. 쿼리는 id가 100보다 큰 첫 번째 레코드부터 인덱스를 스캔한다. 만일 인덱스 레코드에 설정되어 있는 락이 갭에 만들어져 있는 삽입의 락을 풀지 못한다면, 다른 클라이언트는 새로운 열을 테이블 안에 삽입할 수 있게 된다. 만일 동일한 트랜젝션 안에서 같은 SELECT를 실행한다면, 여러분은 쿼리가 리턴하는 결과에서 새로운 열을 볼 수가 있다. 이것은, 만일 새로운 아이템이 데이터베이스에 추가될 경우, InnoDB는 “serializability”를 보장하지 않는다는 것을 의미하는 것이다. 따라서, 만일 이 변수가 활성화 되어 있다면, InnoDB는 READ COMMITTED를 보장하게 된다. (“serializability” 충돌을 보장한다.)
MySQL 5.0.2 버전 이후로는, 이 옵션은 덜 안전한 기능을 제공하게 된다. UPDATE또는 DELETE에 있는 InnoDB는 업데이트 또는 삭제를 하는 열만을 잠근다. 이를 통해서 데드락의 가능성은 많이 감소하기는 하지만, 아주 없어진 것은 아니다. 이 변수를 활성화 시킨다고 하더라도 UPDATE 과 같은 연산이 다른 열에 영향을 주는 경우조차도 다른 유사한 연산 (UPDATE과 같은 연산)을 앞지르지는 못한다는 점을 알아두자.:
CREATE TABLE A(A INT NOT NULL, B INT) ENGINE = InnoDB;
INSERT INTO A VALUES (1,2),(2,3),(3,2),(4,3),(5,2);
COMMIT;
클라이언트 하나가 아래의 명령문을 실행한다고 가정하자:
SET AUTOCOMMIT = 0;
UPDATE A SET B = 5 WHERE B = 3;
그런 다음에는, 다른 클라이언트가 첫 번째 클라이언트의 명령문 다음에 나오는 아래의 명령문을 실행한다고 가정하자:
SET AUTOCOMMIT = 0;
UPDATE A SET B = 4 WHERE B = 2;
이와 같은 경우, 두 번째 UPDATE는 반드시 첫 번째 UPDATE의 실행 또는 롤백을 기다려야 한다. 첫 번째 UPDATE는 열 (2,3)에 배타적인 락을 가지고 있기 때문에, 두 번째 UPDATE이 열들을 스캐닝할 때 동일한 열에 대해서 배타적인 락을 획득하고자 시도하지만 성공하지는 못한다. 이것은, 두 번째 UPDATE가 우선 열에 대해서 배타적인 락을 획득하고 난 다음에 그 열이 결과 셋에 포함되어 있는지를 확인하기 때문이다.만일 속해 있지 않다면, 필요 없는 락을 풀게 되고, 그 때에innodb_locks_unsafe_for_binlog 변수가 활성화가 된다.
따라서, InnoDB는 첫 번째 UPDATE를 아래와 같이 실행한다:
x-lock(1,2)
unlock(1,2)
x-lock(2,3)
update(2,3) to (2,5)
x-lock(3,2)
unlock(3,2)
x-lock(4,3)
update(4,3) to (4,5)
x-lock(5,2)
unlock(5,2)
InnoDB는 두 번째 UPDATE를 아래와 같이 실행한다:
x-lock(1,2)
update(1,2) to (1,4)
x-lock(2,3) - wait for query one to commit or rollback
InnoDB 아카이브 파일을 로그할지를 결정. 이 변수는 여러 가지 이유로 존재하기는 하지만 더 이상 쓰여지지는 않는 변수다. 디폴트 값은 0이다.
InnoDB가 로그 파일을 디스크에 쓰기 위해 사용하는 버퍼의 크기 (바이트). 사용 가능한 크기는 1MB 에서 8MB이다. 디폴트는1MB. 로그 버퍼가 크면 트랜젝션을 실행하기 전에 로그를 디스크에 쓰지 않고서도 대형 트랜젝션을 처리할 수가 있게 된다. 따라서, 만일 여러분이 대형 트랜젝션을 가지고 있다면, 로그 버퍼를 크게 해서 디스크 I/O를 절감하도록 한다.
로그 그룹에 있는 각 로그의 크기 (바이트). 로그 파일의 조합 크기는 32-비트 컴퓨터에서는 4GB보다 작아야 한다. 디폴트는 5MB. 사용 가능한 크기의 범위는 1MB 에서 버퍼 풀의 1/N-th까지 이며, 여기에서 N 은 그룹에 있는 로그 파일의 수가 된다. 이 값이 클수록, 버퍼 풀에서 체크포인트 플러시 동작이 덜 필요하게 되며, 디스크 I/O를 줄여주게 된다. 하지만 로그 파일이 크게 되면, 크래시 발생시의 복구가 그 만큼 느려지게 된다.
- innodb_log_files_in_group
로그 그룹의 로그 파일의 숫자. InnoDB는 원형 방식 (circular fashion)으로 파일을 기록한다. 디폴트는 (권장 값)는 2.
- innodb_log_group_home_dir
InnoDB 로그 파일에 대한 디렉토리 경로. 만일 어떠한 InnoDB 로그 변수도 지정하지 않는다면, 디폴트로 ib_logfile0 및 ib_logfile1라는 이름의 5MB 파일 두 개를MySQL 데이터 디렉토리에 생성한다.
- innodb_max_dirty_pages_pct
0에서 100 사이의 정수가 된다. 디폴트는 90. InnoDB의 메인 쓰레드는 아직 기록되지 않은 페이지의 퍼센트가 이 값을 초과하지 않게 하기 위해 버퍼 풀에 있는 페이지를 기록하고자 시도한다.
이 변수는 퍼지 연산 (purge operation)이 래깅 (lagging)될 때 INSERT, UPDATE및 DELETE 연산을 지연 시키는 방법을 제어한다 (Section 14.2.12, “다중-버전 구현”을 참조). 이 변수의 디폴트 값은0이며, 이것은 아무런 지연도 없음을 의미한다.
InnoDB 트랜젝션 시스템은 UPDATE 또는 DELETE 연산에 의한 삭제-표시된 인덱스 레코드를 가지고 있는 트랜젝션 리스트를 관리한다. 이 리스트의 길이는 purge_lag가 되도록 한다. purge_lag 가 innodb_max_purge_lag를 초과하게 되면, 각INSERT, UPDATE 및 DELETE 연산은((purge_lag/innodb_max_purge_lag)×10)–5 밀리 초 만큼 지연된다. 이러한 지연 시간은 퍼지 배치가 시작되는 시점에, 매 초마다 계산된다. 퍼지될 열을 볼 수 있는 이전의 상수 읽기 뷰 (old consistent read view)로 인해 퍼지가 실행되지 않으면 연산은 지연되지 않는다.
문제가 있는 워크로드에 대한 전형적인 설정은 백만분의 1초 이며, 트랜젝션이 작고,크기가 100바이트 정도이며, 테이블에는 100MB의 퍼지되지 않은 열만 허용할 수 있다는 가정을 한다.
- innodb_mirrored_log_groups
데이터베이스용으로 보관하기 위한 로그 그룹의 동일한 복사본의 숫자. 현재 버전까지는, 이것은 1로 설정해야 한다.
이것은 InnoDB에 다중의 테이블스페이스를 사용하는 경우에만 관련이 있는 변수이다. 이 변수의 값은 InnoDB가 한번에 열어 둘 수 있는 .ibd 파일의 최대 숫자를 지정한다. 최소 값은 10. 디폴트는 300.
.ibd 파일용으로 사용되는 파일 설명자 (descriptor)는 InnoDB만을 위한 것이다. 이러한 설명자는 --open-files-limit 서버 옵션에 의해 지정되는 것들과는 별개의 것들이며,테이블 캐시의 연산에는 영향을 주지 않는다.
InnoDB 테이블과 바이너리 로그의 내용물 사이에 일관성 보장을 추가한다. Section 5.12.3, “The Binary Log”를 참조할 것. 이 변수는 MySQL 5.0.3부터는 삭제되었다.
ON 또는 1 (디폴트 임)로 설정되면, 이 변수는 트랜젝션의 2-단계 실행 (two-phase commit)을 지원하도록 InnoDB를 활성화 시킨다. innodb_support_xa를 활성화 시키면 트랜젝션 준비 (transaction preparation)를 위한 여분의 디스크 플러시가 발생한다. 만일 여러분이 XA를 사용하는 것에 신경을 쓰지 않는다면, 디스크 플러시의 숫자를 줄이고 InnoDB 의 성능을 좋게 하기 위해서 이 변수를 0 또는 OFF로 설정하면 된다. 이 변수는 MySQL 5.0.3에서 추가되었다.
쓰레드가 지연되기 전에 (suspended) 풀어 주기 위해 InnoDB 뮤텍스 (mutex)를 기다리는 쓰레드의 대기 시간. 이 변수는 MySQL 5.0.3에서 추가되었다.
만일 AUTOCOMMIT=0라면, InnoDB는 LOCK TABLES를 존중하게 된다; MySQL은 다른 모든 쓰레드가 테이블에 대한 자신들의 모든 락을 풀기 전까지는LOCK TABLE .. WRITE에서 리턴을 하지 않는다. innodb_table_locks의 디폴트 값은1이며, 이렇게 되면 LOCK TABLES은 AUTOCOMMIT=0경우에, InnoDB로 하여금 내부적으로 테이블을 잠그도록 한다.
- innodb_thread_concurrency
InnoDB는 이 변수가 주는 한계와 동등하거나 작게 InnoDB 내부에 OS 쓰레드의 숫자를 유지하고자 한다. 만일 성능상의 문제가 있다면, 그리고 SHOW ENGINE INNODB STATUS 가 세마포어를 기다리는 많은 수의 쓰레드를 내 보낸다면, 쓰레드 “thrashing”을 가지고 있는 것이며, 이 변수를 보다 작게 또는 보다 크게 설정해 보아야 한다. 만일 여러분이 사용하는 컴퓨터가 많은 수의 CPU와 디스크를 가지고 있는 것이라면, 컴퓨터의 자원을 보다 많이 사용할 수 있도록 이 값을 높게 설정하도록 한다. 권장하는 값은 여러분이 사용하는 시스템의 프로세스와 디스크의 전체 합이다.
이 변수의 범위는 0에서 100까지이다. MySQL 5.0.19 이전에는 20보다 크거나 같게 되면 무한 일관성 (infinite concurrency)으로 해석이 되었다. 5.0.19 버전 이후에는, 0을 무한으로 해석한다. 무한이라는 의미는 일관성 검사가 비활성화 되고 뮤텍스 (mutex)를 획득하고 풀기 위한 오버헤드를 제거된다는 것을 의미한다.
디폴트 값은 여러 번 변경되었다: MySQL 5.0.8 이전에는 8 이었으며, 5.0.8 에서5.0.18까지는 20 (infinite), 5.0.19 에서 5.0.20까지는 0 (infinite), 그리고 5.0.21이후에는8 (finite)이다.
- innodb_thread_sleep_delay
InnoDB 큐를 조이닝 (joining)하기 전에 InnoDB 쓰레드가 일시 정지 (sleep)하는 시간. 마이크로 초. 디폴트는 10,000. 0은 일시 정지를 비활성화 시킨다. 이 변수는MySQL 5.0.3에 추가되었다.
만일 이 변수의 값이 양수 (positive)라면, MySQL 서버는 모든 sync_binlog 가 자신의 바이너리 로그를 기록한 후에 그 바이너리 로그를 디스크에 동기화 시킨다(fdatasync()).자동 실행 모드 (autocommit mode)에서는 명령문 당 한 번씩 바이너리 로그를 기록하고, 그렇지 않은 경우에는 매 트랜젝션 별로 한 번씩 기록한다는 점을 알아두자. 디폴트 값은 0 이며, 이것은 디스크에 동기화를 시키지 않는다. 1의 값을 선택하는 것이 안전한데, 그 이유는 크래시가 발생할 경우에는 바이너리 로그에서 하나의 명령문/트랜젝션을 잃어버리게 되기 때문이다; 하지만, 이 값을 선택하면 성능이 덜 나오게 된다 (디스크가 배터리-백업 캐시를 가지고 있지 않는 한).
