1) 사용자 인증 방식 변경
Mysql 8.0 버전부터는 Caching SHA-2 Authentication 인증 방식이 기본 인증 방식으로 바뀌었다.
Mysql 5.7 에 존재했던 사용자 계정은 여전히 Native Authentication 인증 방식을 사용하겠지만
Mysql 8.0 버전에서 별도의 옵션 없이 생성되는
사용자 계정은 Caching SHA-2 Authentication 인증 방식을 사용하게 될 것이다.
만약 Native Authentication 을 계속 사용하고자 한다면 Mysql 서버를 시작할 때 --default-authentication-plugin=mysql_native_password 파라미터를 활성화하자.
mysql 5.7 그대로 쓰려면 mysql_native_password 활성화 해야한다.
2) Mysql 8.0과의 호환성 체크
8.0 업그레이드 전에 5.7 버전에서 손상된 FRM 파일이나 호환되지 않는 데이터 타입 또는 함수가 있는지 mysqlcheck 유틸리티를 이용해 확인해 볼 것을 권장한다.
3) 외래키 이름의 길이
Mysql 8.0에서는 외래키(foreign key)의 이름이 64글자로 제한된다.
그래서 기존의 Mysql 서버에서 외래키 이름이 64글자 이상인 것이 있는지 확인하고 필요하면 변경하자.
4) 인덱스 힌트
Mysql 5.x에서 사용되던 인덱스 힌트가 있다면 Mysql 8.0에서 먼저 성능 테스트를 수행하자.
이거는 어느 데이터베이스라도 동일하다. 버전업 전에 전체 SQL은 검수를 못하더라도
/* sql ID */별로 중요한 프로세스와 관련된 sql은 필수적으로
실행계획을 확인하고 성능체크를 해서 문제가 있으면 튜닝을 해야한다.
5) Group by 에 사용된 정렬 옵션
Mysql 5.x에서 Group by 절의 컬럼 뒤에 'ASC'나 'DESC'를 사용(GROUP BY field_name [ASC | DESC]) 하고 있다면 먼저 제거하거나 다른 방식으로 변경하자.
6) 파티션을 위한 공용 테이블스페이스
mysql 8.0에서는 파티션의 각 테이블스페이스를 공용 테이블스페이스에 저장할 수 없다.
그래서 파티션의 테이블 스페이스가 공용 테이블스페이스에 저장된 것이 있는지 먼저 확인하고,
있다면 ALTER TABLE .. REORANIZE 명령을 실행해 개별 테이블 스페이스를 사용하도록 변경해야 한다.
#공용 테이블 스페이스에 저장된 파티션이 있는지 확인
select
distinct NAME
, SPACE
, SPACE_TYPE
from information_schema.INNODB_SYS_TABLES
where NAME like '%#P#%'
and SPACE_TYPE NOT LIKE '%Single%';
Empty set (0.01 sec)
my.cnf의 시스템 설정에서
innodb_file_per_table = 1 로 설정되어있지 않다면
공용 테이블 스페이스가 있을 수도 있다 확인필요!
7) mysql 8.0.15 버전과 이후 버전에 따라 업그레이드 방법 차이
# mysql 5.7.x -> mysql 8.0.15 까지 upgrade시
1. mysql shutdown
2. mysql 5.7 프로그램 삭제
3. mysql 8.0 프로그램 설치
4. mysql 8.0 서버(mysqld) 시작(mysql 서버가 데이터 딕셔너리 업그레이드 자동실행)
5. mysql_upgrade 프로그램 실행(mysql_upgrade 프로그램이 시스템 테이블의 구조를 Mysql 8.0에 맞게 변경)
# mysql 5.7.x -> mysql 8.0.16 부터 upgrade시
1. mysql shutdown
2. mysql 5.7 프로그램 삭제
3. mysql 8.0 프로그램 설치
4. mysql 8.0 서버(mysqld) 시작(mysql 서버가 데이터 딕셔너리 업그레이드를 실행 후, 시스템 테이블 구조를 mysql 8.0 에 맞게 변환)
// 이제 mysql_upgrade 안써도 된다.
#추가로 찾아본 부분정리
5) Group by 절의 'ASC'나 'DESC'를 제거하라?
이해가 안되서 좀 찾아보니 mysql 5.x에서는 Group by 로 정렬시 order by를 굳이 사용하지 않아도 (ASC)라는
암묵적인 지원이 있었는데
mysql 8.0에서는 그런것이 없고 order by를 사용해야지만 정확한 정보를 얻을 수 있다는 얘기다.
#참조
https://dev.mysql.com/worklog/task/?id=8693
MySQL에서 GROUP BY는 역사적으로 정렬에 사용되었다.
쿼리가 GROUP BY를 지정하면 쿼리에 동일한 열에 대한 ORDER BY가 있는 것처럼 출력 행이 열별로 그룹화되어 정렬됩니다.
이것은 MySQL 버전 5.7 이전에 있었다. 그러나 GROUP BY에 대한 암묵적 정렬이 제거되면서 MySQL 8.0에서 변경되었다.
그러나 여전히 남아 있는 것은 GROUP BY 열 - GROUP BY 열 ASC/DESC의 순서를 지정하기 위해 MySQL이 GROUP BY 절과 함께 제공하는 비표준 확장입니다.
이 작업 로그의 목적은 ASC 및 DESC를 기준으로 그룹화에 대한 구문을 제거하는 것입니다.
이것과 GROUP BY에 대한 암시적 정렬의 이전 제거를 통해, 우리는 또한 현재 GROUP BY가 항상 정렬한다고 가정하는 코드의 일부를 제거할 수 있다.
예를 들어 쿼리가 그룹당 하나의 행만 생성하므로 GROUP BY를 제거할 수 있는 경우, Optimizer는 가능한 경우 GROUP BY를 주문 기준으로 현재 다시 씁니다.
이 작업은 GROUP BY를 지정할 때 사용자가 예상한 결과로 수행됩니다.
그러나 제거되지 않는 것은 다음과 같습니다:
MySQL Optimizer는 현재 ORDER BY 열이 GROUP BY 열과 호환되는지 확인합니다. 호환되는 것으로 확인되면 GROUP BY가 필요한 정렬을 제공한다고 생각하여 ORDER를 제거합니다.
나중에 그룹화된 결과를 생성하기 위해 그룹화 기준을 정렬해야 하는 것으로 결정된 경우 이는 좋은 최적화입니다.
그러나 그룹화에 임시 테이블을 사용하는 경우처럼 그룹화 기준으로 데이터를 정렬하여 그룹화된 결과를 얻을 필요가 없다면 비용이 많이 들 수 있습니다.
이 경우, 서버는 임시 테이블의 그룹당 하나의 행을 업데이트하여 나중에 정렬할 수 있는 행 수를 줄입니다.
데이터를 그룹화하기 전에 모든 행을 정렬해야 하는 것에 비해 이 방법이 더 좋습니다.
MySQL 옵티마이저는 현재 위의 작업을 비교하기 위한 비용 모델이 없기 때문에 호환성이 발견되면 ORDER BY를 GROUP BY로 이동하는 코드가 남아 있다.
위의 변경 사항은 이 작업 로그에 의해 도입되지 않습니다.
따라서 이 작업 로그를 사용하여 GROUP BY ASC 및 GROUP BY DESC의 비표준 구문을 제거하고 위에서 언급한 코드를 재팩터링하여 이를 따를 것입니다.
MySQL 5.7의 ASC/DESC에 의한 GROUP BY ASC 구문 사용 중지.
참고: 8.0.12 이전까지 Mysql은 롤업과 함께 ORDER BY를 허용하지 않았습니다.
그 이유는 ROLLUP이 행에서 NULLs를 생성하고 Mysql은 NULLs를 최소 값으로 처리하는 동안 바람직하지 않은 결과를 초래하기 때문입니다.
따라서 ROLLUP을 사용하여 쿼리에 대한 주문 결과를 얻기가 어렵습니다.
따라서 이 경우 정렬된 결과를 제공하기 위해 GROUP BY ASC/DESC가 있어야 했다.
그러나 롤업 및 그룹화() 기능이 포함된 ORDER BY(주문 기준) 기능을 사용하면 조항별로 그룹화()를 사용하여 다음 문서에서 언급한 대로 원하는 결과를 얻을 수 있습니다.
#rollup and order by
http://mangalpardeshi.blogspot.co.uk/2009/08/rollup-and-order-by.html
'쇠똥굴리기(BOOK) > Real mysql 8.0' 카테고리의 다른 글
트랜젝션 지원 메타데이터 (0) | 2023.04.07 |
---|---|
SET PERSIST 이야기 (0) | 2023.03.27 |
mysql 서버 연결 방식 localhost / 127.0.0.1 차이 (0) | 2023.03.15 |
mysql 시작과 종료 (0) | 2023.03.14 |
왜 Mysql 인가? (0) | 2023.03.13 |