MySQL 5.6에 온라인 DDL이 도입되었으므로 ALTER TABLE명령은 선택적으로 지정 ALGORITHM=INPLACE하거나 ALGORITHM=COPY지정할 수 있습니다. 온라인 DDL 의 개요는 기본적으로 INPLACE가능한 모든 곳에서 사용 되며 알고리즘이 더 저렴하다는 것을 암시 합니다.INPLACECOPY
그래서 성명서 ALGORITHM=COPY에 어떤 이유를 명시해야 ALTER TABLE합니까?
답변
예,를 지정할 수있는 경우가 COPY있지만 성능 이외의 다른 이유 일 수 있습니다.
MySQL이 새로운 기능인 버전 5.6의 온라인 DLL 처리를 도입했음을 이해하는 것이 중요합니다. 오프라인 처리를 제거하지 않았습니다. 따라서이 두 가지 모드를 구별 할 필요가 있습니다.
-
일부 작업은 여전히 오프라인 모드에서만 작동합니다. 제자리에서 수행 할 수 있거나 수행 할 수없는 DDL 작업 목록은 표 15.10,“ DDL 작업의 온라인 상태 요약 ”을 참조하십시오 .
-
온라인 및 오프라인 모드에서의 작업은 동작이 약간 다르므로 호환성 이유로 “오래된”것을 선택할 수 있습니다.
몇 가지 예 (더 제안) :
-
MySQL은 5.6 이전에 생성 된 InnoDB 테이블은 지원하지 않습니다
ALTER TABLE ... ALGORITHM=INPLACE시간적 열 (포함 테이블DATE,DATETIME또는TIMESTAMP) 및 사용 재건되지 않았다ALTER TABLE ... ALGORITHM=COPY. 이 경우ALTER TABLE ... ALGORITHM=INPLACE작업이 오류를 반환합니다. -
ADD PRIMARY KEY의 절은 해당 데이터 유형의 기본값 (INT의 경우 0, varchar의 경우 빈 문자열)으로COPY mode자동 변환NULL되지만IN_PLACE그렇지 않습니다.
ALGORITHM = COPY 절을 사용하면 기본 키 열에 NULL 값이 있음에도 불구하고 작업이 성공합니다. 데이터가 자동으로 변경되어 문제가 발생할 수 있습니다.
선호하는 또 다른 이유 COPY:
ALGORITHM = COPY 또는 old_alter_table = 1을 지정하는 조작은 특수 시나리오에서 정확한 역 호환성을 위해 필요한 경우 테이블 복사 동작을 강제 실행합니다.
MySQL 매뉴얼은 실제 시나리오에 대해서는 언급하지 않지만 일부는 상상할 수 있습니다. 예를 들어 개발자는 ALTER INDEX작업 중 테이블이 잠기고 테이블이 읽기 전용이거나 완전히 잠겨 있고 인덱스를 다시 작성하는 동안 정적 테이블을 읽는 프로세스가 있습니다.
답변
@Stoleg은 아마도 가장 좋은 대답을 가지고 있지만 여기 또 다른 대답이 있습니다. =COPY에 심각한 버그가있는 경우 개발자 가 탈출 해치로 떠났다는 교육받은 추측입니다 =INLINE. 이렇게 ALTER하면 새 기능이 손상 되어도 사용자가 계속 사용할 수 있습니다.
나는 수년 동안 이와 같은 것들 (플래그 sql_mode, my.cnf설정 등)을 보았습니다 . 새 릴리스의 목적은 새롭고 더 나은 기능을 제공하는 것입니다.
최적화 플래그는이 범주에 속하지만 이전 작업에 매달릴 더 많은 이유가 있습니다. 옵티마이 저는 항상 “잘못된 작업”을합니다. 단순히 너무 많은 가능성이 있습니다.
답변
InnoDB 테이블 스페이스 암호화를 지원하는 MySQL 버전에서 암호화를 추가하기 위해 테이블을 변경하면 복사 알고리즘을 사용하여 변경이 필요하지 않습니다.