NULL 과 NOT NULL 을 모두 지정되지 않은 경우, 그 컬럼은 NULL 이 지정된 것처럼 처리됩니다.

정수 또는 부동 소수점의 컬럼은 추가 속성 AUTO_INCREMENT 를 지정할 수 있습니다. 인덱싱 된 AUTO_INCREMENT 컬럼에 NULL (권장) 또는 0 값을 삽입하면 열이 다음 시퀀스 값으로 설정됩니다. 일반적으로 이것은 value +1 입니다. 여기서 value 는 현재 테이블에있는 컬럼의 최대 값입니다. AUTO_INCREMENT 시퀀스는 1 에서 시작됩니다.

행을 삽입 한 후 AUTO_INCREMENT 값을 얻으려면, LAST_INSERT_ID() SQL 함수 또는 mysql_insert_id() C API 함수를 사용합니다. 섹션 12.14 "정보 함수" 및 섹션 23.8.7.37 "mysql_insert_id ()" 를 참조하십시오.

NO_AUTO_VALUE_ON_ZERO SQL 모드가 활성화되어있는 경우 새 시퀀스 값을 생성하지 않고 0 을 AUTO_INCREMENT 컬럼에 0 로 저장할 수 있습니다. 섹션 5.1.7 "서버 SQL 모드" 를 참조하십시오.

MyISAM 테이블의 경우, 멀티 컬럼 키의 AUTO_INCREMENT 보조 컬럼을 지정할 수 있습니다. 섹션 3.6.9 "AUTO_INCREMENT 사용" 을 참조하십시오.

MySQL을 일부 ODBC 응용 프로그램과 호환성있게하기 위해 다음의 쿼리를 사용하여 마지막으로 삽입 된 행의 AUTO_INCREMENT 값을 찾을 수 있습니다.

 SELECT * FROM tbl_name WHERE auto_col IS NULL

InnoDB 와 AUTO_INCREMENT 내용은 섹션 14.6.5 "InnoDB에서 AUTO_INCREMENT 처리" 를 참조하십시오. AUTO_INCREMENT 와 MySQL 복제 내용은 섹션 17.4.1.1 "복제 및 AUTO_INCREMENT" 를 참조하십시오.

문자 데이터 유형 ( CHAR , VARCHAR , TEXT )은 컬럼 문자 셋과 콜레 션을 지정하기위한 CHARACTER SET 과 COLLATE 속성을 포함 할 수 있습니다. 자세한 내용은 섹션 10.1 "문자 집합 지원" 을 참조하십시오. CHARSET 는 CHARACTER SET 의 동의어입니다. 예 :

 CREATE TABLE t (c CHAR (20) CHARACTER SET utf8 COLLATE utf8_bin);

MySQL 5.6은 문자 컬럼 정의의 길이의 지정을 문자로 해석합니다. (MySQL 4.1 이전 버전에서는 바이트 단위로 해석되었습니다.) BINARY 및 VARBINARY 길이는 바이트 단위입니다.

DEFAULT 절은 컬럼의 기본값을 지정합니다. 한 가지 예외가 있습니다. 기본값은 상수 여야가 있으므로, 함수 또는 식을 수 없습니다. 이것은 예를 들어 날짜 컬럼의 기본값으로 NOW() 이나 CURRENT_DATE 등의 함수 값을 설정할 수 없다는 것을 의미합니다. 예외적으로 TIMESTAMP 또는 (MySQL 5.6.5의 시점에서는) DATETIME 컬럼의 기본값으로 CURRENT_TIMESTAMP 를 지정할 수 있습니다. 섹션 11.3.5 "TIMESTAMP 및 DATETIME 자동 초기화 및 업데이트 기능" 을 참조하십시오.

컬럼 정의에 명시적인 DEFAULT 값이 포함되어 있지 않은 경우, MySQL은 섹션 11.6 "데이터 유형 기본값" 에 설명 된대로 기본값을 결정합니다.

BLOB 및 TEXT 컬럼에 기본값을 할당 할 수 없습니다.

NO_ZERO_DATE 또는 NO_ZERO_IN_DATE SQL 모드가 활성화되어있을 때, 날짜 값의 기본이 해당 모드에 따라 잘못된 경우 CREATE TABLE 에서는 엄격한 SQL 모드가 활성화되어 있지 않으면 경고를 엄격 모드가 활성화 이 경우 오류를 생성합니다. 예를 들어, NO_ZERO_IN_DATE 이 활성화되어있는 경우 c1 DATE DEFAULT '2010-00-00' 는 경고가 생성됩니다. (MySQL 5.6.6 이전에는 엄격 모드가 활성화되어 있지 않은 경우에도이 문은 오류를 생성합니다.)

COMMENT 옵션을 사용하여 컬럼의 댓글을 최대 1024 자 길이로 지정할 수 있습니다. 이 코멘트는 SHOW CREATE TABLE 및 SHOW FULL COLUMNS 문이 표시됩니다.

MySQL Cluster는 COLUMN_FORMAT 를 사용하여 NDB 테이블의 각 컬럼의 데이터 저장 포맷을 지정할 수도 있습니다. 허용되는 컬럼 형식은 FIXED , DYNAMIC 및 DEFAULT 입니다. FIXED 는 고정 폭의 스토리지를 지정하는 데 사용되며, DYNAMIC 은 열이 가변 폭 될 수 있도록하고 DEFAULT 는 컬럼에서 그 컬럼의 데이터 형식에 따라 결정되는 고정 폭 또는 가변 폭의 스토리지가 사용 되도록합니다 ( ROW_FORMAT 지정자에 의해 재정의 될 수 있습니다).

NDB 테이블의 경우 COLUMN_FORMAT 의 기본값은 DEFAULT 입니다.

COLUMN_FORMAT 현재 NDB 이외의 스토리지 엔진을 사용하는 테이블의 컬럼에는 영향을주지 않습니다. MySQL 5.6 이상에서는 COLUMN_FORMAT 는 암묵적으로 무시됩니다.

NDB 테이블의 경우 STORAGE 절을 사용하여 열이 디스크 또는 메모리에 모두 저장되는지를 지정할 수도 있습니다. STORAGE DISK 를 지정하면 컬럼은 디스크에 저장되어 STORAGE MEMORY 를 지정하면 인 메모리 스토리지가 사용됩니다. 사용되는 CREATE TABLE 문은 계속 TABLESPACE 절을 포함해야합니다.

 mysql> CREATE TABLE t1 (
     -> c1 INT STORAGE DISK,
     -> c2 INT STORAGE MEMORY
     -> ) ENGINE NDB;
 ERROR 1005 (HY000) : Can not create table 'c.t1'(errno : 140)

 mysql> CREATE TABLE t1 (
     -> c1 INT STORAGE DISK,
     -> c2 INT STORAGE MEMORY
     -> ) TABLESPACE ts_1 ENGINE NDB;
 Query OK, 0 rows affected (1.06 sec)

NDB 테이블의 경우 STORAGE DEFAULT 는 STORAGE MEMORY 과 동일합니다.

STORAGE 절은 NDB 이외의 스토리지 엔진을 사용하는 테이블에는 영향을주지 않습니다. STORAGE 키워드는 MySQL Cluster와 함께 제공된 mysqld의 구축에서만 지원됩니다. 다른 어떤 버전의 MySQL에서 인식되지 않습니다. 이 경우 STORAGE 키워드를 사용하려고하면 반드시 구문 오류가 발생합니다.

KEY 는 보통 INDEX 의 동의어입니다. 키 속성 PRIMARY KEY 또한 열 정의에 지정하려면 단순히 KEY 로 지정할 수 있습니다. 이것은 다른 데이터베이스 시스템과의 호환성을 위해 구현되었습니다.

UNIQUE 인덱스는 인덱스의 모든 값이 달라야하는 제한 조건을 작성합니다. 기존 행에 일치하는 키 값을 갖는 새 행을 추가하려고하면 오류가 발생합니다. 모든 엔진에 대한 UNIQUE 인덱스는 NULL 을 포함 할 수있다 컬럼에서 여러 NULL 값을 허용합니다.

PRIMARY KEY 는 모든 키 컬럼을 NOT NULL 로 정의해야하는 고유 인덱스입니다. 그들이 NOT NULL 로 명시 적으로 선언되어 있지 않은 경우, MySQL은 그들을 암묵적으로 (그리고 경고없이) 그렇게 선언합니다. 테이블에 존재할 수있는 PRIMARY KEY 는 1 개뿐입니다. PRIMARY KEY 의 이름은 항상 PRIMARY 입니다. 따라서이를 다른 어떤 종류의 인덱스의 이름으로 사용할 수 없습니다.

PRIMARY KEY 가 없을 때 응용 프로그램이 테이블의 PRIMARY KEY 을 요구하는 경우 MySQL은 NULL 컬럼이없는 최초의 UNIQUE 인덱스를 PRIMARY KEY 로서 돌려줍니다.

InnoDB 테이블에서는 보조 인덱스를위한 스토리지 오버 헤드를 최소화하기 위해 PRIMARY KEY 를 작은 값으로 유지하십시오. 각 보조 인덱스 항목에는 해당 행의 기본 키 컬럼의 복사본이 포함되어 있습니다. ( 섹션 14.2.13 "InnoDB 테이블 및 인덱스 구조" 를 참조하십시오.)

생성 된 테이블에서 PRIMARY KEY 가 먼저 배치되고 그 다음에 모든 UNIQUE 인덱스, 또한 고유하지 않은 인덱스가 계속됩니다. 이것은 MySQL 옵티마이 저가 사용하는 인덱스에 우선 순위를 지정하거나 중복 된 UNIQUE 키를보다 빠르게 감지 할 데 도움이됩니다.

PRIMARY KEY 를 멀티 컬럼 인덱스 할 수 있습니다. 그러나 컬럼 지정에서 PRIMARY KEY 키 속성을 사용하여 멀티 컬럼 인덱스를 만들 수 없습니다. 그것을 행해도, 그 단일 컬럼이 기본으로 표시 될뿐입니다. 개별 PRIMARY KEY( index_col_name , ...) 절을 사용해야합니다.

PRIMARY KEY 또는 UNIQUE 인덱스가 정수를 포함하는 하나의 컬럼만으로 구성되는 경우 SELECT 문에서 컬럼을 _rowid 로 참조 할 수 있습니다.

MySQL은 PRIMARY KEY 이름은 PRIMARY 입니다. 기타 인덱스에 이름을 할당하지 않으면 그 인덱스는 첫 인덱싱 된 컬럼과 동일한 이름을 할당 그것을 고유하기 위해 옵션의 접미사 ( _2 , _3 , ... )를 붙일 수 합니다. 테이블의 인덱스 이름은 SHOW INDEX FROM tbl_name 을 사용하여 확인할 수 있습니다. 섹션 13.7.5.23 "SHOW INDEX 구문" 을 참조하십시오.

일부 스토리지 엔진은 인덱스를 만들 때 인덱스 유형을 지정할 수 있습니다. index_type 지정자 구문은 USING type_name 입니다.

예 :

 CREATE TABLE lookup
   (id INT, INDEX USING BTREE (id))
   ENGINE = MEMORY;

USING 권장되는 위치는 인덱스 컬럼리스트의 나머지입니다. 컬럼리스트 앞에도 지정할 수 있지만이 옵션을 그 위치에서 사용하기위한 지원은 비추천이며, 미래의 MySQL 릴리스에서 제거 될 예정입니다.

index_option 값은 인덱스의 추가 옵션을 지정합니다. USING 그런 옵션 중 하나입니다. 허용되는 index_option 값의 자세한 내용은 섹션 13.1.13 "CREATE INDEX 구문" 을 참조하십시오.

인덱스의 자세한 내용은 섹션 8.3.1 "MySQL의 인덱스 사용 방법" 을 참조하십시오.

MySQL 5.6에서는 NULL 값을 가질 수가있는 컬럼의 인덱스를 지원하는 것은 InnoDB , MyISAM 및 MEMORY 뿐입니다. 그렇지 않으면 인덱스 컬럼을 NOT NULL 로 선언해야합니다. 그렇지 않으면 오류 결과가 발생합니다.

CHAR , VARCHAR , BINARY 및 VARBINARY 컬럼의 경우 col_name ( length ) 구문을 사용하여 인덱스 프리픽스 길이를 지정하여 컬럼 값의 첫 부분만을 사용하는 인덱스를 만들 수 있습니다. BLOB 및 TEXT 컬럼에 인덱스를 설정할 수 있지만, 프리픽스 길이를 지정해야합니다. 프리픽스 길이는 바이너리가 아닌 문자열의 경우는 문자에서 이진 문자열 형의 경우는 바이트 단위로 지정됩니다. 즉, 인덱스 항목은 CHAR , VARCHAR 및 TEXT 컬럼의 경우 각 컬럼 값의 첫 번째 length 문자 BINARY , VARBINARY , 그리고 BLOB 컬럼의 경우 각 컬럼 값의 첫 번째 length 바이트로 구성됩니다. 이와 같이 컬럼 값의 프리픽스에만 인덱스를 설정하면 인덱스 파일을 훨씬 줄일 수 있습니다. 섹션 8.3.4 "컬럼 인덱스" 를 참조하십시오.

BLOB 및 TEXT 컬럼에 인덱스 설정을 지원하는 것은 InnoDB 와 MyISAM 스토리지 엔진뿐입니다. 예 :

 CREATE TABLE test (blob_col BLOB, INDEX (blob_col (10)));

InnoDB 테이블에서는 프리픽스의 길이를 최대 767 바이트이며 또한 innodb_large_prefix 옵션이 활성화되어있는 경우는 3072 바이트로 할 수 있습니다. 프리픽스의 제한이 바이트 단위로 측정되는 반면 CREATE TABLE 문에서 프리픽스 길이는 바이너리가 아닌 데이터 형식 ( CHAR , VARCHAR , TEXT )는 문자로 해석됩니다. 멀티 바이트 문자 집합을 사용하는 컬럼의 프리픽스 길이를 지정하는 경우이 점을 고려하십시오.

index_col_name 의 지정을 ASC 또는 DESC 로 종료시킬 수 있습니다. 이러한 키워드는 인덱스 값의 오름차순 또는 내림차순으로 저장을 지정하는 미래의 확장을 위해 허용되어 있습니다. 현재 이들은 분석되지만 무시됩니다. 인덱스 값은 항상 오름차순으로 저장됩니다.

SELECT 에서 컬럼에 ORDER BY 또는 GROUP BY 를 사용하면 서버는 max_sort_length 시스템 변수에 의해 표시된 초기 바이트만을 사용하여 값을 정렬합니다.

텍스트 검색에 사용되는 특수한 FULLTEXT 인덱스를 만들 수 있습니다. FULLTEXT 인덱스를 지원하는 것은 InnoDB 와 MyISAM 뿐입니다. 이들은 CHAR , VARCHAR 및 TEXT 컬럼에서만 만들 수 있습니다. 인덱스 설정은 항상 컬럼 전체에 대해 수행됩니다. 컬럼 접두어 인덱싱은 지원되지 않기 때문에 프리픽스 길이가 지정 되어도 무시됩니다. 작업의 자세한 내용은 섹션 12.9 "전체 텍스트 검색 함수" 를 참조하십시오. WITH PARSER 절은 텍스트 인덱싱 및 검색 작업에 특수 처리가 필요한 경우 파서 플러그인을 인덱스에 연관시킬 수 있도록 index_option 값으로 지정할 수 있습니다. 이 절은 FULLTEXT 인덱스에 대해서만 유효합니다. 플러그인 작성의 자세한 내용은 섹션 24.2 "MySQL 플러그인 API" 를 참조하십시오.

공간 데이터 형식에 SPATIAL 인덱스를 만들 수 있습니다. 공간 형은 MyISAM 테이블에서만 지원되며 인덱스 컬럼을 NOT NULL 로 선언해야합니다. 섹션 11.5 "공간 데이터의 확장" 을 참조하십시오.

MySQL 5.6에서는 인덱스 정의에 최대 1024 문자 옵션의 주석을 포함 할 수 있습니다.

InnoDB 및 NDB 테이블은 외부 키 제약의 체크를 지원하고 있습니다. 참조되는 테이블의 컬럼은 항상 명시 적으로 이름을 붙일 필요가 있습니다. 외부 키에 대해 ON DELETE 와 ON UPDATE 모두의 액션이 지원되고 있습니다. 자세한 내용 및 예제는 섹션 13.1.17.2 "외래 키 제약 조건 사용" 을 참조하십시오. InnoDB 의 외부 키에 고유 한 정보는 섹션 14.6.6 "InnoDB와 FOREIGN KEY 제약 조건" 을 참조하십시오.

다른 스토리지 엔진의 경우 MySQL Server는 CREATE TABLE 문에서 FOREIGN KEY 및 REFERENCES 구문을 분석하고 무시합니다. CHECK 절은 모든 스토리지 엔진에 의해 해석되지만 무시됩니다. 섹션 1.8.2.4 "외래 키 차이" 를 참조하십시오.

테이블 당 4096 컬럼 강한 제한이 있지만, 특정 테이블에서 실제 최대 수가 더 적을 수 있습니다. 실제 최대 개수는 섹션 D.10.4 "테이블 컬럼 및 행 크기 제한" 에 설명 된 요인에 따라 다릅니다.

AUTO_INCREMENT

테이블의 초기 AUTO_INCREMENT 값. MySQL 5.6에서는 이것은 MyISAM , MEMORY , InnoDB 및 ARCHIVE 테이블에서 작동합니다. AUTO_INCREMENT 테이블 옵션을 지원하지 않는 엔진의 첫 번째 자동 증가 값을 설정하려면 테이블을 만든 후 원하는 값보다 1 작은 값을 가지는 " 더미 " 행을 삽입 한 후 그 더미 행을 삭제합니다.

CREATE TABLE 문에서 AUTO_INCREMENT 테이블 옵션을 지원하는 엔진의 경우 ALTER TABLE tbl_name AUTO_INCREMENT = N 을 사용하여 AUTO_INCREMENT 값을 재설정 할 수 있습니다. 이 값을 현재 컬럼에있는 최대 값보다 작게 설정 할 수 없습니다.

AVG_ROW_LENGTH

테이블의 평균 행 길이의 근사치. 이를 설정할 필요가있는 것은, 가변 크기의 행이있는 큰 테이블의 경우뿐입니다.

MyISAM 테이블을 만들 때 MySQL은 MAX_ROWS 및 AVG_ROW_LENGTH 옵션의 곱을 사용하여 결과 테이블이 어느 정도의 크기가되는지를 판정합니다. 두 옵션 모두 지정하지 않으면, MyISAM 데이터와 인덱스 파일의 최대 크기는 기본적으로 256T 바이트입니다. (운영 체제에서 그 크기의 파일을 지원하지 않는 경우 테이블 크기는 파일 크기 제한에 의해 제한됩니다.) 인덱스를 더 작고 빠르게하기 위해 포인터 크기를 작게 유지하고 싶어하고, 실제로 큰 파일이 필요하지 않은 경우 myisam_data_pointer_size 시스템 변수를 설정하여 기본 포인터 크기를 줄일 수 있습니다. ( 섹션 5.1.4 "서버 시스템 변수" 를 참조하십시오.) 모든 테이블을 기본 제한을 넘어 확장 할 수 있도록하고 싶다고 생각하고 테이블이 필요 이상으로 조금 늦게하고 커져도 감당할 수있는 경우이 변수를 설정하여 기본 포인터 크기를 크게 할 수 있습니다. 이 값을 7로 설정하면 최대 65,536T 바이트의 테이블 크기가 허용됩니다.

[DEFAULT] CHARACTER SET

테이블의 기본 문자 집합을 지정합니다. CHARSET 는 CHARACTER SET 의 동의어입니다. 문자 세트 이름이 DEFAULT 인 경우, 데이터베이스 문자 세트가 사용됩니다.

CHECKSUM

MySQL에서 모든 행의 라이브 체크섬 (즉, 테이블이 변경되면 MySQL이 자동으로 업데이트하는 체크섬)가 유지되도록하는 경우이를 1로 설정합니다. 이렇게하면 테이블의 업데이트가 조금 느려지지만 손상된 테이블을 쉽게 찾을 수 있습니다. CHECKSUM TABLE 문이 체크섬을보고합니다. ( MyISAM 만)

[DEFAULT] COLLATE

테이블의 기본 데이터 정렬을 지정합니다.

COMMENT

테이블의 코멘트이며, 길이는 최대 2048 자입니다.

CONNECTION

FEDERATED 테이블의 연결 문자열입니다.

DATA DIRECTORY , INDEX DIRECTORY

InnoDB 는 DATA DIRECTORY = ' directory ' 옵션을 사용하면 MySQL 데이터 디렉토리 이외의 장소에 새로운 InnoDB file-per-table 테이블 공간을 만들 수 있습니다. MySQL은 지정된 디렉토리에 데이터베이스 이름에 해당하는 하위 디렉토리를 만들고, 그 안에 새 테이블의 .ibd 파일을 만듭니다. InnoDB 테이블에서 DATA DIRECTORY 옵션을 사용하려면 innodb_file_per_table 구성 옵션을 활성화해야합니다. 이 디렉토리는 디렉토리 (상대 경로가 아닌) 전체 경로 이름이어야합니다. 자세한 내용은 섹션 14.5.4 "테이블 공간의 위치 지정" 을 참조하십시오.

MyISAM 테이블을 작성하려면 DATA DIRECTORY = ' directory ' 어구, INDEX DIRECTORY = ' directory ' 어구 또는 둘 모두를 사용할 수 있습니다. 이들은 각각 MyISAM 테이블의 데이터 파일과 인덱스 파일을 저장할 위치를 지정합니다. InnoDB 테이블과 달리 DATA DIRECTORY 또는 INDEX DIRECTORY 옵션으로 MyISAM 테이블을 만들 때 MySQL은 데이터베이스 이름에 해당하는 하위 디렉토리를 생성하지 않습니다. 각 파일은 지정된 디렉토리에 생성됩니다.

이 옵션은 --skip-symbolic-links 옵션을 사용하지 않은 경우에만 작동합니다. 또한 운영 시스템도 작동 thread에 대해서 안전한 realpath () 호출이 존재해야합니다. 자세한 내용은 섹션 8.11.3.1.2 "Unix 기반 MyISAM에 대한 심볼릭 링크 사용" 을 참조하십시오.

MyISAM 테이블이 DATA DIRECTORY 옵션없이 생성되는 경우, .MYD 파일이 데이터베이스 디렉토리에 생성됩니다. 기본적으로 MyISAM 이 기존의 .MYD 파일을 발견하면 해당 파일을 덮어 씁니다. INDEX DIRECTORY 옵션을 지정하지 않고 작성된 테이블에 대한 .MYI 파일에 마찬가지입니다. 이 동작을하지 않으려면 --keep_files_on_create 옵션을 사용하여 서버를 시작합니다. 이 경우 MyISAM 은 기존 파일을 덮어 쓰지 않고 대신 오류를 반환합니다.

MyISAM 테이블이 DATA DIRECTORY 또는 INDEX DIRECTORY 옵션을 사용하여 만들어진 기존의 .MYD 또는 .MYI 파일이 발견되면 MyISAM은 항상 오류를 반환합니다. 지정된 디렉토리에있는 파일은 덮어 쓰지 않습니다.

DELAY_KEY_WRITE

테이블의 키 업데이트를 테이블이 닫힐 때까지 지연 경우에는이를 1로 설정합니다. 섹션 5.1 "서버 시스템 변수" 에있는 delay_key_write 시스템 변수의 설명을 참조하십시오. ( MyISAM 만)

INSERT_METHOD

MERGE 테이블에 데이터를 삽입하는 경우 INSERT_METHOD 를 사용하여 행을 삽입 할 테이블을 지정해야합니다. INSERT_METHOD 는 MERGE 테이블에만 유용한 옵션입니다. 첫 번째 또는 마지막 테이블에 삽입하려면 FIRST 또는 LAST 값을 삽입되지 않도록하려면 NO 값을 사용합니다. 섹션 15.7 "MERGE 저장 엔진" 을 참조하십시오.

KEY_BLOCK_SIZE

압축 된 InnoDB 테이블에서는 옵션에서 페이지 에 사용할 크기를 바이트 단위로 지정합니다. 이 값은 팁으로 처리됩니다. InnoDB 는 필요에 따라 다른 크기를 사용 할 수 있습니다. 값 0은 innodb_page_size 값의 절반 인 디폴트의 압축 된 페이지 크기를 나타냅니다. KEY_BLOCK_SIZE 값은 innodb_page_size 값 이하로 밖에 할 수 없습니다. innodb_page_size 값보다 큰 값을 지정한 경우에는 그 값이 무시되고 경고가 발행됩니다. 또한 KEY_BLOCK_SIZE 는 innodb_page_size 값의 절반으로 설정됩니다. innodb_strict_mode = ON 의 경우 잘못된 KEY_BLOCK_SIZE 값을 지정하면 오류가 반환됩니다. 사용법 자세한 내용은 섹션 14.7 "InnoDB 압축 테이블" 을 참조하십시오.

개별 인덱스 정의는 테이블 값을 재정의하는 자체 KEY_BLOCK_SIZE 값을 지정할 수 있습니다.

MAX_ROWS

테이블에 저장하는 것을 예정하고있는 최대 행 수. 이것은 강한 제한이 아니라 어느 쪽 일까하고 말하면, 테이블이 적어도이 행수를 저장할 수 있어야한다는 스토리지 엔진에 대한 팁입니다.

NDB 스토리지 엔진은이 값을 최대 값으로 취급합니다. 매우 큰 (수백만 개의 행 포함) MySQL Cluster 테이블을 작성하려는 경우이 옵션을 사용하여 MAX_ROWS = 2 * rows 를 설정하여 테이블의 기본 키의 해시를 저장하는 데 사용되는 해시 테이블에 NDB 의해 충분한 수의 인덱스 슬롯이 할당되는 것을 보장하도록하십시오. 여기서, rows 는 테이블에 삽입 할 것으로 예상되는 행 수입니다.

MAX_ROWS 의 최대 값은 4294967295입니다. 이를 초과하는 값이 제한 잘립니다.

MIN_ROWS

테이블에 저장하는 것을 예정하고있는 행의 최소 수. MEMORY 스토리지 엔진이 옵션을 메모리 사용에 대한 팁으로 사용합니다.

PACK_KEYS

PACK_KEYS 는 MyISAM 테이블에서만 사용할 수 있습니다. 인덱스를 작게하려면이 옵션을 1로 설정합니다. 일반적으로 이것에 의해 업데이트 늦게 읽기 속도를 높일 수 있습니다. 이 옵션을 0으로 설정하면 키의 모든 포장이 해제됩니다. 이 DEFAULT 로 설정하면 긴 CHAR , VARCHAR , BINARY 또는 VARBINARY 컬럼만을 팩하는 스토리지 엔진에 지시합니다.

PACK_KEYS 를 사용하지 않으면 기본적으로 문자열을 팩하지만 숫자는 팩하지 않습니다. PACK_KEYS = 1 을 사용하는 경우는 수치도 팩됩니다.

2 진수의 키를 팩하는 경우, MySQL은 다음 프리픽스 압축을 사용합니다.

즉, 2 개의 연속 된 행에 동일한 키가 다수 존재하는 경우는 다음의 " 동일한 " 키는 모든 일반 (행에 대한 포인터를 포함) 2 바이트 밖에 차지하지 않습니다. 이것을 다음의 키가 storage_size_for_key + pointer_size (여기서 포인터 크기는 보통 4)를 점유하는 일반적인 경우와 비교하십시오. 반대로 말하면, 프리픽스 압축에서 큰 이점을 얻을 수있는 것은 같은 수치가 다수 존재하는 경우만입니다. 모든 키가 완전히 다른 경우는 그 키가 NULL 값을 가질 수있는 키가 아닌 한, 키 당 1 바이트 많이 사용됩니다. (이 경우, 팩 된 키의 길이는 키가 NULL 인지 여부를 표시하는 데 사용되는 것과 동일한 바이트에 저장됩니다.)

PASSWORD

이 옵션은 사용되지 않습니다. .frm 파일을 암호화하고 다른 모든 MySQL 서버에서 사용할 수 없도록 할 필요가있는 경우에는 당사의 영업 부서에 문의하십시오.

ROW_FORMAT

행이 저장되는 실제 포맷을 정의합니다. 이러한 선택은 테이블에 사용되는 스토리지 엔진에 따라 다릅니다.

InnoDB 테이블의 경우 :

MyISAM 테이블의 경우이 옵션 값을 정적 행 형식 또는 가변 행 형식을 나타내는 FIXED 또는 DYNAMIC 으로 설정할 수 있습니다. myisampack 는이 형식을 COMPRESSED 로 설정합니다. 섹션 15.2.3 "MyISAM 테이블 스토리지 포맷" 을 참조하십시오.

STATS_AUTO_RECALC

InnoDB 테이블의 영구 통계 를 자동으로 다시 계산할지 여부를 지정합니다. 값 DEFAULT 를 지정하면 테이블의 영구 통계 설정은 innodb_stats_auto_recalc 구성 옵션에 의해 결정됩니다. 값 1 을 지정하면 통계 테이블에서 데이터의 10 %가 변경된 때 다시 계산됩니다. 값 0 은이 테이블의 자동 재 계산되지 않도록합니다. 이 설정의 경우 테이블에 대폭적인 변경을 행한 뒤에 통계를 다시 계산하려면 ANALYZE TABLE 문을 발행합니다. 영구 통계 기능의 자세한 내용은 섹션 14.13.16.1 "영구 옵티 마이저 통계 매개 변수 구성" 을 참조하십시오.

STATS_PERSISTENT

InnoDB 테이블의 영구 통계 를 사용할지 여부를 지정합니다. 값 DEFAULT 를 지정하면 테이블의 영구 통계 설정은 innodb_stats_persistent 구성 옵션에 의해 결정됩니다. 값 1 이 테이블 영구 통계를 사용하는데 대해, 값 0 은이 기능을 해제합니다. CREATE TABLE 또는 ALTER TABLE 문을 사용하여 영구 통계를 활성화 한 뒤, 대표적인 데이터 테이블에로드 된 후 통계를 계산하려면 ANALYZE TABLE 문을 발행합니다. 영구 통계 기능의 자세한 내용은 섹션 14.13.16.1 "영구 옵티 마이저 통계 매개 변수 구성" 을 참조하십시오.

STATS_SAMPLE_PAGES

인덱스 컬럼의 중요도 및 기타 통계 ( ANALYZE TABLE 에 의해 계산되는 통계 등)를 추정 할 때 샘플링하는 인덱스 페이지 수입니다. 자세한 내용은 섹션 14.13.16.1 "영구 옵티 마이저 통계 매개 변수 구성" 을 참조하십시오.

UNION

UNION 은 동일한 MyISAM 테이블의 컬렉션을 한 것으로 액세스하는 데 사용됩니다. 이것은 MERGE 테이블에서만 작동합니다. 섹션 15.7 "MERGE 저장 엔진" 을 참조하십시오.

MERGE 테이블에 매핑하는 테이블에 대한 SELECT , UPDATE 및 DELETE 권한이 필요합니다.

HASH ( expr ) : 행의 배치 및 검색을위한 키를 생성하기 위해 하나 이상의 컬럼을 해시합니다. expr 는 하나 이상의 테이블 컬럼을 사용한 식입니다. 이것은 하나의 정수 값을 얻을 수있는 유효한 MySQL 식 (MySQL 함수 포함) 할 수 있습니다. 예를 들어, 다음은 모두 PARTITION BY HASH 를 사용하여 유효한 CREATE TABLE 문입니다.

CREATE TABLE t1 (col1 INT, col2 CHAR (5))
    PARTITION BY HASH (col1);

CREATE TABLE t1 (col1 INT, col2 CHAR (5), col3 DATETIME)
    PARTITION BY HASH (YEAR (col3));

PARTITION BY HASH 은 VALUES LESS THAN 또는 VALUES IN 의 어느 조항도 사용할 수 없습니다.

PARTITION BY HASH 은 expr 을 파티션의 숫자로 나눈 나머지 (즉, 법)을 사용합니다. 예 및 자세한 내용은 섹션 19.2.4 "HASH 파티셔닝" 를 참조하십시오.

LINEAR 키워드는 다소 다른 알고리즘이 필요합니다. 이 경우 행이 저장되는 파티션의 수는 1 개 이상의 논리적 AND 연산의 결과로 계산됩니다. 선형 해시의 설명 및 예제는 섹션 19.2.4.1 "LINEAR HASH 파티셔닝" 를 참조하십시오.

KEY ( column_list ) : 이것은 HASH 와 비슷하지만, 균일 한 데이터 분배를 보장하기 위해 MySQL이 해시 함수를 제공하는 점이 다릅니다. column_list 인수는 단순히 하나 이상의 테이블 컬럼 (최대 16 개)의 목록입니다. 이 예는 4 개의 파티션이있는 키에 의해 분할 된 간단한 테이블을 보여줍니다.

CREATE TABLE tk (col1 INT, col2 CHAR (5), col3 DATE)
    PARTITION BY KEY (col3)
    PARTITIONS 4;

키에 의해 분할 된 테이블의 경우 LINEAR 키워드를 사용하여 선형 분할을 채용 할 수 있습니다. 여기에는 HASH 로 파티션 된 테이블의 경우와 같은 효과가 있습니다. 즉, 파티션 번호는 법이 아니라 & 연산자를 사용하여 찾을 수 있습니다 (자세한 내용은 섹션 19.2.4.1 "LINEAR HASH 파티셔닝" 및 섹션 19.2.5 "KEY 파티션" 을 참조하십시오). 이 예에서는 키에 의한 선형 분할을 사용하여 5 개의 파티션간에 데이터를 분산시킵니다.

CREATE TABLE tk (col1 INT, col2 CHAR (5), col3 DATE)
    PARTITION BY LINEAR KEY (col3)
    PARTITIONS 5;

ALGORITHM = {1 | 2} 옵션은 MySQL 5.6.11에서 [SUB] PARTITION BY [LINEAR] KEY 로 지원하고 있습니다. ALGORITHM = 1 을 지정하면 서버는 MySQL 5.1과 같은 키 해시 함수를 사용합니다. ALGORITHM = 2 는 서버가 MySQL 5.5 이상에서 구현되고 KEY 에 의해 분할 된 새 테이블에서 기본적으로 사용되는 키 해시 함수를 사용하는 것을 나타냅니다. (MySQL 5.5 이상에서 채택 된 키 해시 함수에 의해 생성 된 파티션 된 테이블을 MySQL 5.1 서버에서 사용할 수 없습니다.)이 옵션을 지정하지 않는 경우는 ALGORITHM=2 를 사용하는 것과 같은 효과 수 있습니다. 이 옵션은 주로 [LINEAR] KEY 로 파티션 된 테이블을 MySQL 5.1 이후의 MySQL 버전간에 업그레이드하거나 다운 그레이드 할 때 사용하거나 MySQL 5.5 이후의 서버에서 MySQL 5.1 서버에서 사용할 수있는 KEY 또는 LINEAR KEY 로 파티션 된 테이블을 만드는 것을 목적으로하고 있습니다. 자세한 내용은 섹션 13.1.7.1 "ALTER TABLE 파티션 작업" 을 참조하십시오.

MySQL 5.6.11 이후 mysqldump 이 옵션을 버전 관리 된 주석에 다음과 같이 씁니다.

CREATE TABLE t1 (a INT)
/ *! 50100 PARTITION BY KEY * / / *! 50611 ALGORITHM = 1 * / / *! 50100 ()
      PARTITIONS 3 * /

이렇게하면 MySQL 5.6.10 이전의 서버는이 옵션을 무시하게됩니다. 이 버전에서는 보통이면 구문 오류가 발생합니다. KEY 로 파티션 또는 서브 파티션 된 테이블을 사용하는 MySQL 5.5.31 또는 그 이후의 MySQL 5.5 서버에서 생성 된 덤프 버전 5.6.11 이전의 MySQL 5.6 서버에로드하려는 있는 경우 계속하기 전에 섹션 2.11.1.3 「MySQL 5.5에서 5.6로 업그레이드 " 를 참조하도록하십시오. (그래서 찾은 정보는 MySQL 5.6.11 이후 서버에서 생성 된 KEY 로 파티션 또는 서브 파티션 된 테이블을 포함 덤프를 MySQL 5.5.30 이전의 서버에로드하는 경우에도 적용됩니다 .)

또한 MySQL 5.6.11 이후에서는 ALGORITHM = 1 이 mysqldump 와 같은 방법으로 버전 관리 된 코멘트를 사용하여 SHOW CREATE TABLE 의 출력에 필요한 표시됩니다. ALGORITHM = 2 는 원래의 테이블을 만들 때이 옵션이 지정된 경우에도 SHOW CREATE TABLE 의 출력에서 항상 생략됩니다.

PARTITION BY KEY 는 VALUES LESS THAN 또는 VALUES IN 의 어느 조항도 사용할 수 없습니다.

RANGE ( expr ) :이 경우, expr 은 VALUES LESS THAN 연산자 세트를 사용하여 값의 범위를 나타냅니다. 범위 분할을 사용하는 경우 VALUES LESS THAN 를 사용하여 하나 이상의 파티션을 정의해야합니다. 범위 분할은 VALUES IN 을 사용할 수 없습니다.

다음의 계획에 따라 연도 값을 포함한 컬럼들로 분할하는 테이블이 있다고합니다.

이러한 파티셔닝을 구현하는 테이블은 다음 CREATE TABLE 문에서 얻을 수 있습니다.

 CREATE TABLE t1 (
    year_col INT,
    some_data INT
 )
 PARTITION BY RANGE (year_col) (
     PARTITION p0 VALUES LESS THAN (1991)
     PARTITION p1 VALUES LESS THAN (1995)
     PARTITION p2 VALUES LESS THAN (1999)
    PARTITION p3 VALUES LESS THAN (2002)
    PARTITION p4 VALUES LESS THAN (2006)
    PARTITION p5 VALUES LESS THAN MAXVALUE
 );

PARTITION ... VALUES LESS THAN ... 문은 연속적으로 작동합니다. VALUES LESS THAN MAXVALUE 는 그렇지 지정되는 최대 값보다 큰 " 나머지 " 값을 지정하도록 작동합니다.

VALUES LESS THAN 절 (C, Java, PHP 등의 많은 프로그래밍 언어로 볼 수있는) switch ... case 블록 case 부분과 같은 방법으로 연속적으로 작동합니다. 즉,이 절은 연속 된 각 VALUES LESS THAN 에서 지정된 상한이 이전 어구의 상한보다 크고 MAXVALUE 를 참조하는 어구가 목록에있는 모든 어구의 마지막에 오는 방식으로 배치되어 있어야합니다.

RANGE COLUMNS ( column_list ) : RANGE 대한이 변형은 여러 컬럼에 대한 범위 조건을 사용했다 (즉, WHERE a = 1 AND b <10 이나 WHERE a = 1 AND b = 10 AND c <10 등의 조건을 가진 ) 쿼리에 대한 파티션 가지 치기를 용이하게합니다. 그러면 COLUMNS 절의 컬럼 목록과 각 PARTITION ... VALUES LESS THAN ( value_list ) 파티션 정의 절의 컬럼 값 세트를 사용하여 여러 컬럼의 값의 범위를 지정할 수 있도록 됩니다. (가장 간단한 경우는이 세트는 단일 컬럼으로 구성됩니다.) column_list 및 value_list 에서 볼 수있는 열의 최대 수는 16입니다.

COLUMNS 절에서 사용되는 column_list 에는 열 이름 만 포함 할 수 있습니다. 목록의 각 컬럼은 MySQL의 데이터 유형 중 정수, 문자열 및 시간 또는 날짜 컬럼 형 중 하나 여야합니다. BLOB , TEXT , SET , ENUM , BIT 또는 공간 데이터 형식을 사용한 컬럼은 허용되지 않습니다. 부동 소수 형을 사용하는 컬럼도 허용되지 않습니다. 또한 COLUMNS 절은 함수 및 연산 식을 사용할 수 없습니다.

파티션 정의에 사용되는 VALUES LESS THAN 절은 COLUMNS () 절에 나타나는 컬럼마다 리터럴 값을 지정해야합니다. 즉, 각 VALUES LESS THAN 절에서 사용되는 값 목록에는 COLUMNS 절에 나열되어있는 컬럼의 수와 같은 수의 값이 포함되어 있어야합니다. VALUES LESS THAN 절 COLUMNS 절에 존재하는 수보다 많거나 또는 적은 값을 사용하려고하면이 문은 오류 Inconsistency in usage of column lists for partitioning ... 실패합니다. VALUES LESS THAN 나타나는 임의의 값으로 NULL 을 사용할 수 없습니다. 이 예에서와 같이 첫 번째 열 이외의 특정 컬럼에 MAXVALUE 를 여러 번 사용할 수 있습니다.

CREATE TABLE rc (
    a INT NOT NULL, 
    b INT NOT NULL
 )
PARTITION BY RANGE COLUMNS (a, b) (
    PARTITION p0 VALUES LESS THAN (10,5)
    PARTITION p1 VALUES LESS THAN (20,10)
    PARTITION p2 VALUES LESS THAN (MAXVALUE 15)
    PARTITION p3 VALUES LESS THAN (MAXVALUE, MAXVALUE)
 );

VALUES LESS THAN 값 목록에 사용되는 각 값이 해당 컬럼의 형태에 정확하게 일치해야합니다. 변환되지 않습니다. 예를 들어 정수형을 사용하는 컬럼에 일치하는 값으로 문자열 '1' 을 사용하거나 (대신 숫자 1 을 사용할 필요가 있습니다) 문자열을 사용하는 컬럼에 일치하는 값으로 수치 1 을 사용 할 수 없습니다 (이런 경우는 따옴표로 둘러싸인 문자열 '1' 을 사용해야합니다).

자세한 내용은 섹션 19.2.1 "RANGE 파티셔닝" 및 19.4 절 "파티션 가지 치기" 를 참조하십시오.

LIST ( expr ) : 이것은 주 또는 국가 코드와 같은 제한된 가능한 값 세트를 가지는 테이블 컬럼을 기준으로 파티션을 할당 할 수 있습니다. 이런 경우는 특정 국가 또는 국가에 관련하는 모든 행을 단일 파티션에 할당하거나 특정 주 또는 국가의 세트를 위해 파티션을 예약 할 수 있습니다. 이것은 RANGE 와 비슷하지만 각 파티션에 허용되는 값을 지정하기 위해 VALUES IN 밖에 사용할 수없는 점이 다릅니다.

VALUES IN 은 일치하는 값 목록과 함께 사용됩니다. 예를 들어, 다음과 같은 파티셔닝을 만들 수 있습니다.

CREATE TABLE client_firms (
     id INT,
    name VARCHAR (35)
 )
PARTITION BY LIST (id) (
    PARTITION r0 VALUES IN (1, 5, 9, 13, 17, 21)
    PARTITION r1 VALUES IN (2, 6, 10, 14, 18, 22)
    PARTITION r2 VALUES IN (3, 7, 11, 15, 19, 23)
    PARTITION r3 VALUES IN (4, 8, 12, 16, 20, 24)
 );

목록 파티셔닝을 사용하는 경우 VALUES IN 을 사용하여 하나의 파티션을 정의해야합니다. PARTITION BY LIST 는 VALUES LESS THAN 을 사용할 수 없습니다.

LIST COLUMNS ( column_list ) : LIST 에 대한이 변형은 여러 컬럼에 대한 비교 기준을 사용했다 (즉, WHERE a = 5 AND b = 5 와 WHERE a = 1 AND b = 10 AND c = 5 와 같은 조건을 가진 ) 쿼리에 대한 파티션 가지 치기를 용이하게합니다. 그러면 COLUMNS 절의 컬럼 목록과 각 PARTITION ... VALUES IN ( value_list ) 파티션 정의 절의 컬럼 값 세트를 사용하여 여러 열에서 값을 지정 할 수 있습니다.

LIST COLUMNS ( column_list ) 에서 사용되는 컬럼리스트와 VALUES IN ( value_list ) 에서 사용되는 값 목록에 관련한 데이터 형을 관리하는 규칙은 VALUES IN 절에서는 MAXVALUE 가 허용되지 않고 NULL 을 사용할 수 있다는 점을 제외하고 각 RANGE COLUMNS ( column_list ) 에서 사용되는 컬럼리스트와 VALUES LESS THAN ( value_list ) 에서 사용되는 값 목록의 경우 규칙과 동일합니다.

PARTITION BY LIST COLUMNS 에서 VALUES IN 에 사용되는 값의 목록은 PARTITION BY LIST 에서 사용 된 경우와 비교하여 중요한 차이가 하나 있습니다. PARTITION BY LIST COLUMNS 에서 사용 된 경우 VALUES IN 절의 각 요소는 컬럼 값의 집합 이어야합니다. 각 세트의 값의 수는 COLUMNS 절에서 사용되는 컬럼 수와 동일해야 이러한 값의 데이터 형은 그 열의 데이터 형과 일치하고있다 (게다가, 같은 순서로 나타난다 )해야합니다. 가장 간단한 경우는이 세트는 단일 컬럼으로 구성됩니다. column_list 및 value_list 를 구성하는 각 요소에서 사용할 수있는 열의 최대 수는 16입니다.

다음의 CREATE TABLE 문에서 정의 된 테이블은 LIST COLUMNS 파티셔닝 된 테이블의 예를 보여줍니다.

CREATE TABLE lc (
    a INT NULL, 
    b INT NULL
 )
PARTITION BY LIST COLUMNS (a, b) (
    PARTITION p0 VALUES IN ((0,0), (NULL, NULL))
    PARTITION p1 VALUES IN ((0,1), (0,2), (0,3), (1,1), (1,2))
    PARTITION p2 VALUES IN ((1,0), (2,0), (2,1), (3,0), (3,1))
    PARTITION p3 VALUES IN ((1,3), (2,2), (2,3), (3,2), (3,3))
 );

옵션에서 PARTITIONS num 절을 사용하여 파티션 수를 지정할 수 있습니다. 여기서 num 은 파티션의 수입니다. 이 어구 와 다른 몇개의 PARTITION 절 모두가 사용되는 경우 num 은 PARTITION 절을 사용하여 선언 된 모든 파티션의 총 수와 동일해야합니다.

옵션에서 파티션을 여러 하위 파티션으로 나눌 수 있습니다. 이것은 옵션 SUBPARTITION BY 절을 사용하여 나타낼 수 있습니다. 서브 파티션은 HASH 또는 KEY 하여 수행 할 수 있습니다. 이 모두 LINEAR 할 수 있습니다. 이들은 동일한 파티션 유형에 대해 앞에서 설명한 것과 동일하게 작동합니다. ( LIST 또는 RANGE 에 의해 서브 파티션 할 수 없습니다.)

서브 파티션의 수는 SUBPARTITIONS 키워드와 그 뒤의 정수 값을 사용하여 나타낼 수 있습니다.

PARTITIONS 또는 SUBPARTITIONS 절에서 사용되는 값의 엄격한 검사가 적용되며,이 값은 다음의 규칙을 준수해야합니다.

PARTITION partition_name : 이것은 파티션의 논리 이름을 지정합니다.

VALUES 절 : 범위의 분할은 각 파티션에 VALUES LESS THAN 절이 포함되어 있어야합니다. 목록 파티셔닝에서는 파티션마다 VALUES IN 절을 지정해야합니다. 이것은이 파티션에 어떤 행을 포함 하는지를 결정하는 데 사용됩니다. 구문 예제는 제 19 장 " 분할 " 에있는 파티션 유형의 설명을 참조하십시오.

옵션 COMMENT 절을 사용하면이 파티션을 설명하는 문자열을 지정할 수 있습니다. 예 :

COMMENT = 'Data for the years previous to 1999'

MySQL 5.6.6에서 파티션 댓글의 최대 길이는 1024 자입니다. (이전에는이​​ 제한이 명시 적으로 정의되지 않았습니다.)

DATA DIRECTORY 와 INDEX DIRECTORY 는 각각이 파티션의 데이터와 인덱스가 저장되는 디렉토리를 나타내는 데 사용할 수 있습니다. data_dir 과 index_dir 는 모두 절대 시스템 경로 이름이어야합니다. 예 :

CREATE TABLE th (id INT, name VARCHAR(30), adate DATE)
PARTITION BY LIST(YEAR(adate))
(
  PARTITION p1999 VALUES IN (1995, 1999, 2003)
    DATA DIRECTORY = '/var/appdata/95/data'
    INDEX DIRECTORY = '/var/appdata/95/idx',
  PARTITION p2000 VALUES IN (1996, 2000, 2004)
    DATA DIRECTORY = '/var/appdata/96/data'
    INDEX DIRECTORY = '/var/appdata/96/idx',
  PARTITION p2001 VALUES IN (1997, 2001, 2005)
    DATA DIRECTORY = '/var/appdata/97/data'
    INDEX DIRECTORY = '/var/appdata/97/idx',
  PARTITION p2002 VALUES IN (1998, 2002, 2006)
    DATA DIRECTORY = '/var/appdata/98/data'
    INDEX DIRECTORY = '/var/appdata/98/idx'
);

DATA DIRECTORY 와 INDEX DIRECTORY 는 MyISAM 테이블에 사용되는 CREATE TABLE 문 table_option 절과 같은 방식으로 작동합니다.

파티션 당 하나의 데이터 디렉토리와 하나의 색인 디렉토리를 지정할 수 있습니다. 지정되지 않은 상태로 남아있는 경우 데이터와 인덱스는 기본적으로 그 테이블의 데이터베이스 디렉토리에 저장됩니다.

Windows에서 DATA DIRECTORY 및 INDEX DIRECTORY 옵션은 MyISAM 테이블의 개별 파티션 또는 서브 파티션에 대해 지원되지 않고 INDEX DIRECTORY 옵션은 InnoDB 테이블의 개별 파티션 또는 서브 파티션에 대해 지원되지 않습니다. 이 옵션은 경고가 생성된다는 점을 제외하고 Windows에서는 무시됩니다. (Bug # 30459)

MAX_ROWS 와 MIN_ROWS 은 각각이 파티션에 저장되는 행의 최대 수와 최소 수를 지정하는 데 사용할 수 있습니다. max_number_of_rows 과 min_number_of_rows 값은 양의 정수이어야합니다. 같은 이름을 가진 테이블 수준의 옵션과 마찬가지로, 이들은 서버에 " 제안 " 으로 만 기능하고 강한 제한은 없습니다.

옵션 TABLESPACE 절을 사용하면이 파티션의 테이블 스페이스를 지정할 수 있습니다. MySQL Cluster에만 사용됩니다.

분할 처리기는 PARTITION 와 SUBPARTITION 모두에 대해 [STORAGE] ENGINE 옵션을 받아들입니다. 현재이를 사용하려면 모든 파티션 또는 모든 하위 파티션을 동일한 스토리지 엔진으로 설정하는 방법 밖에없고, 같은 테이블의 파티션 또는 서브 파티션을 다른 스토리지 엔진을 설정하려고하면 오류 ERROR 1469 (HY000) : The mix of handlers in the partitions is not permitted in this version of MySQL 이 발생합니다. 미래의 MySQL 릴리스에서는이 분할 제한을 해소 할 예정입니다.

옵션에서 파티션 정의에 하나 이상의 subpartition_definition 절을 포함 할 수 있습니다. 이러한 각 조항은 최소한 SUBPARTITION name 으로 구성됩니다. 여기서 name 은 하위 파티션의 식별자입니다. PARTITION 키워드가 SUBPARTITION 에 대체 점을 제외하고 하위 파티션 정의의 구문은 파티션 정의의 구문과 동일합니다.

서브 파티션은 HASH 또는 KEY 에 의해 실행해야, RANGE 또는 LIST 파티션에서만 실행할 수 있습니다. 섹션 19.2.6 "서브 파티셔닝" 를 참조하십시오.