B.3.7 Known Issues in MySQL

B.3.7 Known Issues in MySQL

이 섹션에서는 최근 버전의 MySQL에서 알려진 issue들을 나열합니다.

플랫폼별 issue에 대한 정보는 Section 2.1, “General Installation Guidance”의 installation 및 디버깅 안내와 Section 7.9, “Debugging MySQL”를 참조하십시오.

다음과 같은 문제들이 알려져 있습니다:

• IN에 대한 서브쿼리 최적화는 =에 대한 것만큼 효과적이지 않습니다.

• lower_case_table_names=2를 사용하더라도 (database와 테이블 이름에 대해 MySQL이 사용된 대소문자를 기억하도록 해 주는 설정), MySQL은 함수 DATABASE() 또는 여러 로그 내에서 (대소문자를 구분하지 않는 시스템에서) database 이름에 사용된 대소문자를 기억하지 않습니다.

• FOREIGN KEY 제약 조건을 drop하는 것은 복제에서 동작하지 않는데, 그 제약 조건이 replica에서 다른 이름을 가지고 있을 수 있기 때문입니다.

• REPLACE (및 REPLACE 옵션을 사용하는 LOAD DATA)는 ON DELETE CASCADE를 트리거하지 않습니다.

• DISTINCT와 ORDER BY의 조합은 DISTINCT 목록에 있는 칼럼들만, 그리고 그 칼럼들 전부를 사용하지 않으면 GROUP_CONCAT() 안에서 동작하지 않습니다.

• 큰 정수 값(263과 264−1 사이)을 decimal 또는 문자열 칼럼에 insert할 때, 그 숫자가 signed 정수 컨텍스트에서 평가되기 때문에 음수 값으로 insert됩니다.

• statement 기반 바이너리 로깅을 사용하는 경우, source 서버는 실행된 쿼리들을 바이너리 로그에 기록합니다. 이는 대부분의 경우 완벽하게 동작하는 매우 빠르고, compact하며, 효율적인 로깅 방식입니다. 그러나 data modification이 비결정적으로 이루어지도록 설계된 쿼리(이는 복제 외부에서도 일반적으로 권장되지 않는 방식)인 경우, source와 replica의 데이터가 서로 달라질 수 있습니다.

예를 들면 다음과 같습니다:

• AUTO_INCREMENT 칼럼에 0 또는 NULL 값을 insert하는 CREATE TABLE ... SELECT 또는 INSERT ... SELECT statement.

• foreign key에 ON DELETE CASCADE 속성이 있는 테이블에서 row를 삭제하는 DELETE.

• insert되는 데이터에 duplicate key 값이 있는 경우의 REPLACE ... SELECT, INSERT IGNORE ... SELECT.

위의 쿼리들에 한해서만, 그리고 오직 그 쿼리들이 결정적인 순서를 보장하는 ORDER BY 절을 가지지 않을 때에만 해당됩니다.

예를 들어, ORDER BY가 없는 INSERT ... SELECT의 경우, SELECT는 source와 replica에서 옵티마이저가 내리는 선택에 따라 row들을 서로 다른 순서로 반환할 수 있습니다 (이로 인해 같은 row가 다른 순위를 가지게 되고, 결과적으로 AUTO_INCREMENT 칼럼에서 서로 다른 숫자를 부여받게 됩니다).

쿼리가 source와 replica에서 서로 다르게 최적화되는 경우는 다음과 같습니다:

• 테이블이 source와 replica에서 서로 다른 스토리지 엔진으로 저장된 경우. (source와 replica에서 다른 스토리지 엔진을 사용할 수 있습니다. 예를 들어, source에서는 InnoDB를, replica에서는 사용 가능한 디스크 공간이 더 적을 경우 MyISAM을 사용할 수 있습니다.)

• source와 replica의 MySQL 버퍼 크기 ( key_buffer_size 등)이 서로 다른 경우.

• source와 replica가 서로 다른 MySQL 버전을 실행하고 있고, 이 버전들 간에 옵티마이저 코드가 다른 경우.

이 문제는 mysqlbinlog|mysql을 사용한 database 복원에도 영향을 줄 수 있습니다.

이 문제를 피하는 가장 쉬운 방법은, 위에서 언급한 비결정적 쿼리들에 ORDER BY 절을 추가하여 row들이 항상 동일한 순서로 저장되거나 수정되도록 하는 것입니다. row 기반 또는 mixed 로깅 포맷을 사용하는 것도 이 문제를 피하는 방법입니다.

• startup 옵션으로 파일 이름을 지정하지 않는 경우, 로그 파일 이름은 서버 호스트 이름을 기반으로 합니다. 호스트 이름을 다른 것으로 변경한 후에도 동일한 로그 파일 이름을 유지하려면, --log-bin=old_host_name-bin과 같은 옵션을 명시적으로 사용해야 합니다. Section 7.1.7, “Server Command Options”를 참조하십시오. 또는, 호스트 이름 변경 사항을 반영하도록 기존 파일들의 이름을 변경할 수 있습니다. 바이너리 로그인 경우에는 바이너리 로그 인덱스 파일을 편집하여 그 안의 바이너리 로그 파일 이름도 수정해야 합니다. (replica의 relay 로그에 대해서도 동일하게 적용됩니다.)

• mysqlbinlog은 LOAD DATA statement 이후에 남겨진 temporary 파일을 삭제하지 않습니다. Section 6.6.9, “mysqlbinlog — Utility for Processing Binary Log Files”를 참조하십시오.

• RENAME은 TEMPORARY 테이블이나 MERGE 테이블에서 사용 중인 테이블에 대해서는 동작하지 않습니다.

• SET CHARACTER SET을 사용할 때에는, database, 테이블, 칼럼 이름에 변환된 문자(translation된 character)를 사용할 수 없습니다.

• 서버는 데이터 값을 비교할 때 첫 max_sort_length byte만 사용합니다. 이는 값들이 첫 max_sort_length byte 이후에서만 서로 다른 경우에는, 이 값들을 GROUP BY, ORDER BY, DISTINCT에서 신뢰할 수 없음을 의미합니다. 이를 우회하려면 이 변수 값을 증가시키십시오. max_sort_length의 기본 값은 1024이며, 서버 startup 시점이나 runtime에 변경할 수 있습니다.

• numeric 계산은 BIGINT 또는 DOUBLE (둘 다 일반적으로 64 bit 길이)로 수행됩니다. 얻는 precision은 사용하는 함수에 따라 다릅니다. 일반적인 규칙은 비트 함수는 BIGINT precision으로 수행되고, IF()와 ELT()는 BIGINT 또는 DOUBLE precision으로, 그 외의 것들은 DOUBLE precision으로 수행된다는 것입니다. 63 bit(9223372036854775807)보다 큰 unsigned long long 값은 비트 필드 이외의 용도로 사용하는 것을 피해야 합니다.

• 하나의 테이블에 최대 255개의 ENUM 및 SET 칼럼을 둘 수 있습니다.

• MIN(), MAX() 및 기타 집계 함수에서, MySQL은 현재 ENUM 및 SET 칼럼을, set 내에서의 상대적인 위치가 아닌 문자열 값으로 비교합니다.

• UPDATE statement에서는 칼럼이 왼쪽에서 오른쪽 순서로 update됩니다. update된 칼럼을 참조하면 원래 값이 아니라 update된 값을 얻게 됩니다. 예를 들어, 다음 statement는 KEY를 1이 아니라 2만큼 증가시킵니다:

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

• 하나의 쿼리에서 여러 temporary 테이블을 참조할 수 있지만, 특정 temporary 테이블 하나를 두 번 이상 참조할 수는 없습니다. 예를 들어, 다음 예시는 동작하지 않습니다:

1mysql> SELECT * FROM temp_table, temp_table AS t2;
2ERROR 1137: Can't reopen table: 'temp_table'

• 조인에서 “hidden” 칼럼을 사용할 때 옵티마이저가 DISTINCT를 처리하는 방식은, hidden 칼럼을 사용하지 않을 때와 다를 수 있습니다. 조인에서는 hidden 칼럼이 결과의 일부로 간주되며(표시되지 않더라도), 일반 쿼리에서는 hidden 칼럼이 DISTINCT 비교에 참여하지 않습니다.

그 예는 다음과 같습니다:

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

및

1SELECT DISTINCT band_downloads.mp3id
2         FROM band_downloads,band_mp3
3         WHERE band_downloads.userid = 9
4         AND band_mp3.id = band_downloads.mp3id
5         ORDER BY band_downloads.id DESC;

두 번째 경우에는, hidden id 칼럼의 값이 서로 다를 수 있기 때문에 결과 set에서 동일한 row가 두 개 생길 수 있습니다.

이 현상은 ORDER BY 칼럼이 결과에 포함되어 있지 않은 쿼리에서만 발생합니다.

• 빈 set을 반환하는 쿼리에 대해 PROCEDURE를 실행하는 경우, 어떤 경우에는 PROCEDURE가 칼럼을 변환하지 않습니다.

• MERGE 타입의 테이블을 생성할 때, 하위 테이블들이 호환되는 타입인지 여부를 검사하지 않습니다.

• MERGE 테이블에 사용되는 테이블에 대해 ALTER TABLE을 사용하여 UNIQUE 인덱스를 추가한 다음, MERGE 테이블에 normal 인덱스를 추가하면, 테이블에 기존의 non-UNIQUE key가 있었던 경우, 테이블들 간에 key 순서가 달라집니다. 이는 ALTER TABLE이 duplicate key를 가능한 한 빨리 감지하기 위해 normal 인덱스보다 앞에 UNIQUE 인덱스를 두기 때문입니다.

• non-temporary 테이블에 정의된 trigger가 있는 경우, temporary 테이블을 포함하고 non-temporary 테이블과의 조인을 사용하는 UPDATE statement는, update statement가 non-temporary 테이블만 읽는 경우에도 다음 경우에는 에러를 발생시킬 수 있습니다:

  • read-only 모드가 활성화된 경우 (SET GLOBAL read_only = 1 사용).

  • 트랜잭션 레벨이 READ_ONLY로 설정된 경우 (즉, SET GLOBAL TRANSACTION READ ONLY 또는 SET SESSION TRANSACTION READ ONLY 사용).