1) SSD / 4k 테스트
ssd / innodb_page_size = 4k 를 위한 성능테스트를 다시하려고
대용량 조회쿼리부분 DB와 table만 마이그레이션을 하던 중에 아래와 같은 에러를 만났다.
ERROR 1118 (42000) at line 25: Row size too large (> 1982). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix 0 bytes is stored inline.
에러내용을 보면 innodb table에서 한 row에 넣을 수 있는 size max가 있는데 그것을 넘어서 table 생성을 못한다는 에러이다 생성하려는 테이블의 컬럼은 varchar, text, int, char 등..뭐 다양하게 있는 테이블인데 정확하게 113개 넣고 114개째.. 에러가 났다.
테이블 자체가 정규화가 안되서 컬럼이 무식하게 많은 테이블이긴 하지만, 만약 page size가 16k 였다면
아래와 같은 에러를 만났을 것이다.
ERROR 1118 (42000) at line 25: Row size too large (> 8126). Changing some columns to TEXT or BLOB or using ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED may help. In current row format, BLOB prefix of 768 bytes is stored inline.
2) 테스트 중단
테스트 의미가 없어서 하지 않기로 했다.
테이블 스키마 변경까지 해서 테스트를 하는 것은 기존 쿼리와 동일비교가 되지않아 할 이유가 없어졌다.
3) 결론
SSD / 4k 써야할까?
처음부터 my.cnf에 innodb_page_size = 4096으로 설정하고 데이터를 쌓았다면 모를까..;;
그렇지 않았다면 쓰지 않는 것이 나을 거 같다.
쓰지 않는 이유 중 또 한가지는 ERROR 1118 (42000) 을 만났을 때 page_size 4k는 다른 선택지가 없다.
하지만 16k는 테이블 압축이라는 옵션이 있어서 Barracuda 엔진이 = on 인 상태라면(mysql 5.7 이상 기본 on) ROW_FORMAT=DYNAMIC or ROW_FORMAT=COMPRESSED 으로 설정하면 압축을 통해 varchar 사이즈가 한계를 넘는 경우라도 index까지 생성할 수 있다.
innodb_page_size 테스트는 여기서 종료한다.
'RDB > mysql' 카테고리의 다른 글
mysql 컬럼 타입 datetime vs timestamp 차이 (0) | 2020.04.08 |
---|---|
[error] mysqldump: Got errno 28 on write (0) | 2020.04.02 |
SSD 파티션 튜닝 1 (0) | 2020.03.26 |
[에러] mysql DB disk 폴더 이동후 재시작 (0) | 2020.03.26 |
mysqldump Table wildcard % 백업하기 (0) | 2020.03.16 |