본문 바로가기
카테고리 없음

MySQL 5.7의 변경 사항

by 반화넬 2024. 1. 5.
반응형

MySQL 5.7로 업그레이드하기 전에 이 섹션에 설명된 변경 사항을 검토하여 현재 MySQL 설치 및 애플리케이션에 적용되는 사항을 확인하십시오. 권장 조치를 수행하십시오.

호환되지 않는 변경 으로 표시된 변경 사항은 이전 버전의 MySQL과 호환되지 않으며 업그레이드하기 전에 주의가 필요할 수 있습니다 . 우리의 목표는 이러한 변경을 방지하는 것이지만 때로는 릴리스 간의 비호환성보다 더 심각한 문제를 수정하기 위해 필요할 수도 있습니다. 설치에 적용 가능한 업그레이드 문제에 비호환성이 포함된 경우 설명에 제공된 지침을 따르십시오. CHECK TABLE때로는 테이블을 덤프하고 다시 로드하거나 또는 같은 명령문을 사용하는 경우도 있습니다 REPAIR TABLE.

덤프 및 다시 로드 지침은 2.10.12절 “테이블 또는 인덱스 재구축 또는 복구”를 참조하십시오 . 옵션 REPAIR TABLE과 관련된 모든 절차는 업그레이드하기 전에 완료 해야 합니다 . 테이블을 생성하는 데 사용된 버전과 다른 MySQL 버전에서 이 명령문을 사용하면(즉, 업그레이드 후 사용) 테이블이 손상될 수 있습니다. 섹션 13.7.2.5, “REPAIR TABLE 문”을 참조하십시오 . USE_FRM

구성 변경

시스템 테이블 변경 사항

서버 변경 사항

  • 호환되지 않는 변경 사항 : MySQL 5.7.5부터 이전 4.1 이전 비밀번호 해싱 형식을 사용하는 비밀번호에 대한 지원이 제거되었습니다. 여기에는 다음 변경 사항이 포함됩니다. 더 이상 지원되지 않는 기능을 사용하는 애플리케이션은 수정해야 합니다.
    • mysql_old_password4.1 이전 비밀번호 해시 값을 사용했던 인증 플러그인이 제거되었습니다 . 이 플러그인을 사용하는 계정은 시작 시 비활성화되며 서버는 오류 로그에 " 알 수 없는 플러그인 " 메시지를 기록합니다. 이 플러그인을 사용하는 계정 업그레이드에 대한 지침은 섹션 6.4.1.3, “4.1 이전 비밀번호 해싱 및 mysql_old_password 플러그인에서 마이그레이션”을 참조하십시오 .
    • 시스템 변수 의 경우 old_passwords 값 1(4.1 이전 해시 값 생성)은 더 이상 허용되지 않습니다.
    • 서버 및 클라이언트 프로그램에 대한 옵션 --secure-auth은 기본값이지만 이제는 작동하지 않습니다. 이는 더 이상 사용되지 않습니다. 향후 MySQL 릴리스에서는 제거될 것으로 예상됩니다.
    • --skip-secure-auth서버 및 클라이언트 프로그램에 대한 옵션은 더 이상 지원되지 않으며 이를 사용하면 오류가 발생합니다 .
    • 시스템 secure_auth변수는 1 값만 허용합니다. 0 값은 더 이상 허용되지 않습니다.
    • 기능이 OLD_PASSWORD()제거되었습니다.
  • 호환되지 않는 변경 사항 : MySQL 5.6.6에서는 2자리 YEAR(2)데이터 유형이 더 이상 사용되지 않습니다. MySQL 5.7.5에서는 에 대한 지원이 YEAR(2)제거되었습니다. MySQL 5.7.5 이상으로 업그레이드한 후에는 나머지 2자리 YEAR(2)열을 4자리YEAR 열로 변환해야 다시 사용할 수 있습니다. 변환 전략은 섹션 11.2.5, “2자리 YEAR(2) 제한 사항 및 4자리 YEAR로 마이그레이션”을 참조하십시오 . 업그레이드 후 mysql_upgrade를 실행하는 것은 가능한 변환 전략 중 하나입니다.
  • MySQL 5.7.7부터 CHECK TABLE ... FOR UPGRADE테이블에 5.6.4 이전 형식의 이전 임시 열( TIME, DATETIME및 TIMESTAMP소수 초 정밀도를 지원하지 않는 열)이 포함되어 있고 avoid_temporal_upgrade 시스템 변수가 비활성화된 경우 테이블을 다시 빌드해야 한다고 보고합니다. 이는 mysql_upgrade가 이전 임시 열이 포함된 테이블을 감지하고 업그레이드하는 데 도움이 됩니다. avoid_temporal_upgrade활성화된 경우 FOR UPGRADE테이블에 있는 이전 임시 열을 무시합니다. 결과적으로 mysql_upgrade는 이를 업그레이드하지 않습니다.이러한 임시 열이 포함되어 재구축이 필요한 테이블을 확인하려면 avoid_temporal_upgrade 실행하기 전에 비활성화하세요 CHECK TABLE ... FOR UPGRADE.
  • 이러한 임시 열이 포함된 테이블을 업그레이드하려면 avoid_temporal_upgrade 실행하기 전에 비활성화 REPAIR TABLE 하거나 mysql_upgrade 를 수행하십시오 .
  • MySQL 5.7.7부터 5.6.4 이전 형식의 이전 임시 열이 포함되어 있고 시스템 변수가 비활성화된 REPAIR TABLE경우 테이블을 업그레이드합니다 . 활성화된 avoid_temporal_upgrade경우 테이블에 있는 이전 임시 열을 무시하고 업그레이드하지 않습니다. avoid_temporal_upgradeREPAIR TABLE
  • 호환되지 않는 변경 사항 : MySQL 5.7.2부터 서버는 mysql.user시스템 테이블의 계정 행에 비어 있지 않은plugin값이 있어야 하며 값이 비어 있는 계정을 비활성화합니다. 이를 위해서는mysql.user테이블을 업그레이드하여 모든 값을 입력 plugin. MySQL 5.7.6부터 다음 절차를 사용하십시오.
    1. 이전(MySQL 5.6) 서버 중지
    2. 기존 바이너리를 새 바이너리로 교체하여 MySQL 바이너리를 업그레이드합니다.
    3. MySQL 5.7 서버를 정상적으로 시작합니다(특별 옵션 없음).
    4. mysql_upgrade를 실행하여 시스템 테이블을 업그레이드하세요.
    5. MySQL 5.7 서버 다시 시작
    기존 MySQL 설치에서 생성된 덤프 파일을 다시 로드하여 업그레이드하려는 경우:MySQL 5.7.6 이전에는 절차가 더 복잡했습니다.
    1. 이전(MySQL 5.6) 서버 중지
    2. MySQL 바이너리를 제자리에서 업그레이드합니다(이전 바이너리를 새 바이너리로 교체).
    3. --skip-grant-tables 권한 확인을 비활성화하는 옵션을 사용하여 서버를 다시 시작합니다.
    4. mysql_upgrade를 실행하여 시스템 테이블을 업그레이드하세요.
    5. 서버를 정상적으로 다시 시작합니다( 없이 --skip-grant-tables).
    기존 MySQL 설치에서 생성된 덤프 파일을 다시 로드하여 업그레이드하려는 경우:mysql_upgrade는 기본적으로 MySQLroot사용자로 실행됩니다. 이전 절차의 경우 mysql_upgrade를root 실행할 때 비밀번호가 만료되면비밀번호가 만료되어결과적으로 mysql_upgrade가 실패했음을 알리는 메시지가 표시됩니다. 이 문제를 해결하려면 비밀번호를 재설정 하고 mysql_upgrade를 다시 실행하세요. root서버가 로 시작되면 비밀번호 재설정 문은 일반적으로 작동하지 않지만 mysql_upgrade--skip-grant-tables 를 처음 호출하면 권한이 플러시되므로 mysql을 실행할 때 문이 허용됩니다.mysql_old_password이전 지침을 따른 후 DBA는 인증 플러그인을 사용하는 계정을 대신 사용할 수 있도록 변환하는 것이 좋습니다 mysql_native_password. 에 대한 지원이 mysql_old_password 제거되었기 때문입니다. 계정 업그레이드 지침은 섹션 6.4.1.3, “4.1 이전 비밀번호 해싱 및 mysql_old_password 플러그인에서 마이그레이션”을 참조하십시오 .
  • mysql_upgrade 자체에서 비밀번호가 만료되면 동일한 root방식으로 비밀번호를 다시 재설정해야 합니다.
  • $> mysql -u root -p
Enter password: ****  <- enter root password here
mysql> ALTER USER USER() IDENTIFIED BY 'root-password'; # MySQL 5.7.6 and up
mysql> SET PASSWORD = PASSWORD('root-password');        # Before MySQL 5.7.6
mysql> quit

$> mysql_upgrade -p
Enter password: ****  <- enter root password here
    1. 덤프 파일을 생성하려면 옵션 없이 mysqldump를 실행하십시오.--flush-privileges
    2. 이전(MySQL 5.6) 서버 중지
    3. MySQL 바이너리를 제자리에서 업그레이드합니다(이전 바이너리를 새 바이너리로 교체).
    4. --skip-grant-tables 권한 확인을 비활성화하는 옵션을 사용하여 서버를 다시 시작합니다.
    5. 덤프 파일 다시 로드( mysql < dump_file )
    6. mysql_upgrade를 실행하여 시스템 테이블을 업그레이드하세요.
    7. 서버를 정상적으로 다시 시작합니다( 없이 --skip-grant-tables).
  • 기존 MySQL 설치의 데이터 디렉터리를 사용하여 업그레이드하려는 경우:
    1. 덤프 파일을 생성하려면 옵션을 사용하거나 사용하지 않고 mysqldump를 실행하십시오.--add-drop-table--flush-privileges
    2. 이전(MySQL 5.6) 서버 중지
    3. MySQL 바이너리를 제자리에서 업그레이드합니다(이전 바이너리를 새 바이너리로 교체).
    4. MySQL 5.7 서버를 정상적으로 시작합니다(특별 옵션 없음).
    5. 덤프 파일 다시 로드( mysql < dump_file )
    6. mysql_upgrade를 실행하여 시스템 테이블을 업그레이드하세요.
    7. MySQL 5.7 서버 다시 시작
  • 기존 MySQL 설치의 데이터 디렉터리를 사용하여 업그레이드하려는 경우:
  • 호환되지 않는 변경 : 테이블 생성 시에는 DEFAULT값이 유효행을 삽입하거나 업데이트할 때는 값이수 있습니다예: sql_modesql_mode이 경우 에 대해서는 0이 허용되지만 CREATE TABLE에 대해서는 거부 되어야 합니다 INSERT. 그러나 이전에는 서버가 DEFAULT현재 sql_mode. 이 예에서는 성공하여 열에 INSERT 삽입됩니다 . '0000-00-00'DATE명령문 기반 로깅( )을 사용하는 경우 복제에 대한 비호환성은 binlog_format=STATEMENT복제본이 업그레이드되면 업그레이드되지 않은 소스가 오류 없이 이전 예제를 실행하는 반면 INSERT복제본에서는 실패하고 복제가 중지된다는 것입니다.
  • 이 문제를 해결하려면 소스에서 모든 새 문을 중지하고 복제본이 따라잡을 때까지 기다리세요. 그런 다음 복제본을 업그레이드하고 소스를 업그레이드합니다. 또는 새 문을 중지할 수 없는 경우 일시적으로 소스( binlog_format=ROW)에서 행 기반 로깅으로 변경하고 이 변경 시점까지 생성된 모든 바이너리 로그를 모든 복제본이 처리할 때까지 기다립니다. 그런 다음 복제본과 소스를 업그레이드하고 소스를 다시 명령문 기반 로깅으로 변경합니다.
  • MySQL 5.7.2부터 서버는 sql_mode삽입 또는 업데이트 시 경고 또는 오류를 생성하기 위해 적절한 검사를 적용합니다.
  • SET sql_mode = '';
CREATE TABLE t (d DATE DEFAULT 0);
SET sql_mode = 'NO_ZERO_DATE,STRICT_ALL_TABLES';
INSERT INTO t (d) VALUES(DEFAULT);
  • 호환되지 않는 변경 : Oracle Audit Vault와의 호환성을 높이기 위해 감사 로그 플러그인에 몇 가지 변경 사항이 적용되었습니다. 업그레이드를 위해 주요 문제는 감사 로그 파일의 기본 형식이 변경되었다는 것입니다. <AUDIT_RECORD>이전에 속성을 사용하여 기록된 요소 내의 정보는 이제 하위 요소를 사용하여 기록됩니다. 
    <AUDIT_RECORD
 TIMESTAMP="2013-04-15T15:27:27"
 NAME="Query"
 CONNECTION_ID="3"
 STATUS="0"
 SQLTEXT="SELECT 1"
/>
    새로운 형식의 예:이전에 이전 버전의 감사 로그 플러그인을 사용한 경우 다음 절차를 사용하여 이전 형식 항목이 포함된 기존 로그 파일에 새 형식 로그 항목을 쓰지 않도록 하세요.감사 로그 플러그인에 대한 자세한 내용은 섹션 6.4.5, “MySQL Enterprise Audit”을 참조하십시오 .
    1. 서버를 중지합니다.
    2. 현재 감사 로그 파일의 이름을 수동으로 바꿉니다. 이 파일에는 이전 형식만 사용하는 로그 항목이 포함되어 있습니다.
    3. 서버를 업데이트하고 다시 시작하세요. 감사 로그 플러그인은 새 형식만 사용하는 로그 항목이 포함된 새 로그 파일을 생성합니다.
  • <AUDIT_RECORD>
 <TIMESTAMP>2013-04-15T15:27:27 UTC</TIMESTAMP>
 <RECORD_ID>3998_2013-04-15T15:27:27</RECORD_ID>
 <NAME>Query</NAME>
 <CONNECTION_ID>3</CONNECTION_ID>
 <STATUS>0</STATUS>
 <STATUS_CODE>0</STATUS_CODE>
 <USER>root[root] @ localhost [127.0.0.1]</USER>
 <OS_LOGIN></OS_LOGIN>
 <HOST>localhost</HOST>
 <IP>127.0.0.1</IP>
 <COMMAND_CLASS>select</COMMAND_CLASS>
 <SQLTEXT>SELECT 1</SQLTEXT>
</AUDIT_RECORD>
  • 이전 형식의 예 <AUDIT_RECORD> :
  • MySQL 5.7.7부터 복제본의 기본 연결 시간 초과가 3600초(1시간)에서 60초(1분)로 변경되었습니다. slave_net_timeout시스템 변수에 대한 설정이 없는 복제본을 MySQL 5.7로 업그레이드하면 새로운 기본값이 적용됩니다 . 연결이 여전히 양호한 경우 데이터가 없을 때 발생하는 연결 시간 초과를 중지하도록 하트비트 신호를 조절하는 하트비트 간격의 기본 설정은 값의 절반으로 계산됩니다 slave_net_timeout. 하트비트 간격은 복제본의 소스 정보 로그(테이블 mysql.slave_master_info또는 master.info파일)에 기록되며, 값이나 기본 설정이 slave_net_timeout변경되어도 자동으로 변경되지 않습니다. 기본 연결 시간 초과 및 하트비트 간격을 사용한 후 MySQL 5.7로 업그레이드된 MySQL 5.6 복제본은 연결 시간 초과보다 훨씬 긴 하트비트 간격을 갖습니다.
  • 소스의 활동 수준이 바이너리 로그 업데이트가 최소한 60초마다 한 번씩 복제본으로 전송되는 경우 이 상황은 문제가 되지 않습니다. 그러나 소스로부터 데이터가 수신되지 않으면 하트비트가 전송되지 않으므로 연결 제한 시간이 만료됩니다. 따라서 복제본은 소스에 대한 연결이 끊어졌다고 생각하고 여러 번 다시 연결을 시도합니다( MASTER_CONNECT_RETRY 및 MASTER_RETRY_COUNT설정에 의해 제어되며 소스 정보 로그에서도 볼 수 있음). 재연결 시도는 소스가 종료해야 하는 수많은 좀비 덤프 스레드를 생성하여 소스의 오류 로그에 UUID를 사용하여 슬레이브에 대한 덤프 스레드를 초기화하는 동안 uuid동일한 UUID를 가진 좀비 덤프 스레드를 발견했습니다. 마스터가 좀비 덤프 스레드를 죽이고 있습니다 threadid . 이 문제를 방지하려면 복제본을 MySQL 5.7로 업그레이드하기 직전에 slave_net_timeout시스템 변수가 기본 설정을 사용하고 있는지 확인하십시오. 그렇다면 옵션을 실행하고 CHANGE MASTER TO하트 MASTER_HEARTBEAT_PERIOD비트 간격을 30초로 설정하여 업그레이드 후 적용되는 새로운 연결 시간 제한인 60초와 함께 작동하도록 하십시오.
  • 호환되지 않는 변경 : MySQL 5.6.22 이상에서는 REFERENCES권한을 인식했지만 완전히 적용하지는 않았습니다. SELECT, , , 또는 중 하나 이상을 가진 사용자는 INSERT테이블 에 외래 키 제약 조건을 만들 수 있습니다. MySQL 5.7(이상)에서는 사용자에게이 작업을 수행할 수 있는 권한이 필요합니다. 이는 MySQL 5.6 서버(모든 버전)에서 MySQL 5.7을 실행하는 서버로 사용자를 마이그레이션하는 경우 외래 키를 생성할 수 있어야 하는 모든 사용자에게 이 권한을 명시적으로 부여해야 함을 의미합니다. 여기에는 외래 키가 있는 테이블이 포함된 덤프를 가져오는 데 사용되는 사용자 계정이 포함됩니다. UPDATEDELETEREFERENCESREFERENCES

InnoDB 변경 사항

  • MySQL 5.7.24부터 MySQL에 번들로 제공되는 zlib 라이브러리 버전이 버전 1.2.3에서 버전 1.2.11로 상향되었습니다.큰 행이 포함 된 압축 테이블이 있는 경우 업그레이드하기 전에 MySQL 5.7 테스트 인스턴스에서 InnoDB압축 테이블 문을 테스트하는 것이 좋습니다 .CREATE TABLE
  • zlib 1.2.11의 zlib compressBound()함수는 zlib 버전 1.2.3에서보다 주어진 바이트 길이를 압축하는 데 필요한 버퍼 크기에 대한 약간 더 높은 추정치를 반환합니다. 이 함수는 압축된 테이블을 생성하거나 압축된 테이블에 행을 삽입할 때 허용되는 최대 행 크기를 결정하는 함수 compressBound() 에 의해 호출됩니다 . 결과적으로 이전 릴리스에서 성공했던 최대 행 크기에 매우 가까운 행 크기를 사용하는 작업이 이제 실패할 수 있습니다. InnoDBInnoDBInnoDBCREATE TABLE ... ROW_FORMAT=COMPRESSEDINSERT
  • 호환되지 않는 변경 :InnoDB충돌 복구 중 테이블스페이스 검색을 단순화하기 위해 MySQL 5.7.5에 새로운 리두 로그 레코드 유형이 도입되었습니다. 이 개선 사항은 리두 로그 형식을 변경합니다. 전체 업그레이드를 수행하기 전에 또는innodb_fast_shutdown 설정을. In-Place Upgrade 에서는 느린 종료를 사용하는 것이 권장됩니다 . 01innodb_fast_shutdown=0
  • 호환되지 않는 변경 : MySQL 5.7.8 및 5.7.9 실행 취소 로그에는 공간 열에 대한 정보가 충분하지 않아 업그레이드가 실패할 수 있습니다(버그 #21508582). MySQL 5.7.8 또는 5.7.9에서 5.7.10 이상으로 전체 업그레이드를 수행하기 전에 실행 innodb_fast_shutdown=0취소 로그를 지우는 데 사용되는 느린 종료를 수행하십시오. In-Place Upgrade 에서는 느린 종료를 사용하는 innodb_fast_shutdown=0것이 권장됩니다 .
  • 호환되지 않는 변경 : MySQL 5.7.8 실행 취소 로그에는 가상 열 및 가상 열 인덱스에 대한 정보가 충분하지 않아 업그레이드가 실패할 수 있습니다(버그 #21869656). MySQL 5.7.8에서 MySQL 5.7.9 이상으로 전체 업그레이드를 수행하기 전에 실행 innodb_fast_shutdown=0취소 로그를 지우는 데 사용하는 느린 종료를 수행하십시오. In-Place Upgrade 에서는 느린 종료를 사용하는 innodb_fast_shutdown=0것이 권장됩니다 .
  • 호환되지 않는 변경 사항 : MySQL 5.7.9부터 첫 번째 리두 로그 파일(ib_logfile0)의 리두 로그 헤더에는 형식 버전 식별자와 리두 로그 파일을 생성한 MySQL 버전을 식별하는 텍스트 문자열이 포함됩니다. 이 개선 사항은 redo 로그 형식을 변경하여 MySQL 5.7.9 이상으로 전체 업그레이드를 수행하기 전에또는innodb_fast_shutdown 설정을In-Place Upgrade 에서는 느린 종료를 사용하는 것이 권장됩니다 . 01innodb_fast_shutdown=0
  • MySQL 5.7.9에서는 테이블 의 암시적 기본 행 형식으로 DYNAMIC대체됩니다 . 새로운 구성 옵션인 은 기본 행 형식을 지정합니다. 허용되는 값에는 (기본값), 및 가 포함됩니다 . COMPACTInnoDBinnodb_default_row_formatInnoDBDYNAMICCOMPACTREDUNDANT옵션 을 명시적으로 정의하지 않거나 ROW_FORMAT를 사용하는 기존 테이블의 경우 ROW_FORMAT=DEFAULT테이블을 다시 작성하는 모든 작업은 테이블의 행 형식을 에서 정의한 형식으로 자동으로 변경합니다 innodb_default_row_format. 그렇지 않으면 기존 테이블은 현재 행 형식 설정을 유지합니다. 자세한 내용은 테이블의 행 형식 정의를 참조하십시오 .
  • 5.7.9로 업그레이드한 후, 생성하는 모든 새 테이블은 innodb_default_row_format 명시적으로 행 형식( ROW_FORMAT)을 정의하지 않는 한 에서 정의한 행 형식을 사용합니다.
  • MySQL 5.7.6 부터 스토리지 엔진 InnoDB 은 . 이전 버전의 MySQL에서 생성된 파티션된 테이블은 자동으로 업그레이드되지 않습니다. 다음 방법 중 하나를 사용하면 MySQL 5.7.9 이상에서 기본 파티셔닝을 사용하도록 이러한 테이블을 쉽게 업그레이드할 수 있습니다 .InnoDBInnoDBInnoDB
    • 일반 파티셔닝 처리기에서 InnoDB기본 파티셔닝으로 개별 테이블을 업그레이드하려면 명령문을 실행합니다 . ALTER TABLE table_name UPGRADE PARTITIONING
    • InnoDB일반 파티셔닝 핸들러를 사용하는 모든 테이블을 대신 기본 파티셔닝 핸들러를 사용하도록 업그레이드하려면 mysql_upgrade 를 실행하세요 .

SQL 변경

  • 호환되지 않는 변경 : 이 GET_LOCK()기능은 MDL(메타데이터 잠금) 하위 시스템을 사용하여 MySQL 5.7.5에서 다시 구현되었으며 해당 기능이 확장되었습니다.자세한 내용은 12.14절 “기능 잠금”을 참조하십시오 .
    • 이전에는 GET_LOCK() 한 번에 하나의 명명된 잠금만 획득할 수 있었고 두 번째 GET_LOCK() 호출은 기존 잠금을 ​​해제했습니다. 이제 GET_LOCK()둘 이상의 동시 명명된 잠금 획득을 허용하고 기존 잠금을 ​​해제하지 않습니다.
    • GET_LOCK()이전 잠금 해제 동작에 의존하는 애플리케이션은 새로운 동작에 맞게 수정되어야 합니다.
    • 여러 잠금을 획득하는 기능으로 인해 클라이언트 간에 교착 상태가 발생할 가능성이 있습니다. MDL 하위 시스템은 교착 상태를 감지하고 ER_USER_LOCK_DEADLOCK 이것이 발생하면 오류를 반환합니다.
    • MDL 하위 시스템에서는 잠금 이름에 64자 제한을 적용하므로 이제 이 제한은 명명된 잠금에도 적용됩니다. 이전에는 길이 제한이 적용되지 않았습니다.
    • 이제 획득한 잠금이 GET_LOCK()성능 스키마 metadata_locks테이블에 표시됩니다. 열에 는 잠금 이름이 OBJECT_TYPE표시되고 USER LEVEL LOCK열에 OBJECT_NAME는 잠금 이름이 표시됩니다.
    • 새로운 기능을 사용하면 RELEASE_ALL_LOCKS() 획득한 모든 명명된 잠금을 한 번에 해제할 수 있습니다.
  • 이제 최적화 프로그램은 절의 파생 테이블과 뷰를 FROM일관된 방식으로 처리하여 불필요한 구체화를 더 효과적으로 방지하고 보다 효율적인 실행 계획을 생성하는 푸시다운 조건을 사용할 수 있도록 합니다. 
    mysql> DELETE FROM t1
    -> WHERE id IN (SELECT id
    ->              FROM (SELECT t1.id
    ->                    FROM t1 INNER JOIN t2 USING (id)
    ->                    WHERE t2.status = 0) AS t);
ERROR 1093 (HY000): You can't specify target table 't1'
for update in FROM clause
    파생 테이블을 외부 쿼리 블록에 병합하면 테이블에서 선택하고 수정하는 문이 생성될 때 오류가 발생합니다. (실질적으로 파생 테이블을 별도의 테이블로 변환하기 때문에 구체화는 문제를 일으키지 않습니다.) 이 오류를 방지하는 해결 방법은 명령문을 실행하기 전에 시스템 변수 derived_merge 의 플래그를 비활성화하는 것입니다.optimizer_switch플래그 는 병합을 방지하는 다른 규칙이 없다는 가정 derived_merge하에 최적화 프로그램이 절의 하위 쿼리와 뷰를 FROM외부 쿼리 블록에 병합하려고 시도하는지 여부를 제어합니다. 기본적으로 플래그는 on병합을 활성화하는 것입니다. 플래그를 설정하면 off 병합을 방지하고 방금 설명한 오류를 방지할 수 있습니다. 자세한 내용은 8.2.2.4절. “병합 또는 구체화를 통해 파생 테이블 및 뷰 참조 최적화”를 참조하십시오 .
  • SET optimizer_switch = 'derived_merge=off';
  • 그러나 MySQL 5.7.11 이전의 MySQL 5.7 및 테이블을 수정하는 명령문의 경우 DELETE이전 UPDATE에 구체화된 파생 테이블에 대한 병합 전략을 사용하면 오류가 발생할 수 있습니다 ER_UPDATE_TABLE_USED.
  • MySQL 5.6에서는 예약되지 않은 일부 키워드가 MySQL 5.7에서는 예약될 수 있습니다. 섹션 9.3, “키워드 및 예약어”를 참조하십시오 . 이로 인해 이전에 식별자로 사용된 단어가 불법이 될 수 있습니다. 영향을 받은 문을 수정하려면 식별자 인용을 사용하세요. 9.2절. “스키마 개체 이름”을 참조하십시오 .
  • 업그레이드한 후에는 애플리케이션 코드에 지정된 최적화 프로그램 힌트를 테스트하여 원하는 최적화 전략을 달성하는 데 힌트가 여전히 필요한지 확인하는 것이 좋습니다. 최적화 기능 향상으로 인해 특정 최적화 기능 힌트가 불필요해질 수 있습니다. 어떤 경우에는 불필요한 최적화 힌트가 역효과를 낳을 수도 있습니다.
  • 명령문 에서 개인 에게 UNION적용하려면 다음을 묶는 괄호 안에 절을 넣으세요 . ORDER BYLIMITSELECTSELECT이전 버전의 MySQL에서는 괄호 없이 이러한 명령문을 허용할 수 있습니다. MySQL 5.7에서는 괄호에 대한 요구 사항이 적용됩니다.
  • (SELECT a FROM t1 WHERE a=10 AND B=1 ORDER BY a LIMIT 10)
UNION
(SELECT a FROM t2 WHERE a=11 AND B=2 ORDER BY a LIMIT 10);

출처 : https://dev.mysql.com/doc/refman/5.7/en/upgrading-from-previous-series.html

반응형
저작자표시

티스토리툴바