InnoDB 테이블 생성 오류 :“행 크기가 너무 큼”


11

보고서를 생성 할 목적으로 정규화 된 db 구조를 임시 테이블로 병합하는 일부 엔지니어가 있습니다. 열은 다음과 같이 지정됩니다 TEXT NOT NULL( "왜 그들이 그렇게 하는가?"를 알고 있습니다.이 문제를 해결한다고 가정하겠습니다).

Linux에서는 InnoDB 플러그인 1.0.9와 함께 MySQL 5.1.48 커뮤니티 RHEL5를 사용합니다.

MyISAM을 사용할 때 최대 열 또는 최대 행 길이의 테이블 크기 제한이 발생하지 않았습니다 (조사 중에 2598에서 최대 열 제한을 초과했습니다 (2599 번째 오류는 1117을 발생시킵니다). InnoDB를 사용하면 한계에 도달합니다. 테이블 (데이터 삽입 없음) :

1 행의 오류 1118 (42000) : 행 크기가 너무 큽니다. BLOB를 계산하지 않고 사용 된 테이블 유형의 최대 행 크기는 8126입니다. 일부 열을 TEXT 또는 BLOB로 변경해야합니다.

다음에 대한 답변을 찾고 있습니다.

  1. 로트의 v / v / b / t 열을 사용할 때 행 크기 파티클을 결정하는 자세한 공식은 무엇입니까? varchar(N)열 (N은 1에서 512 사이), UTF8 문자 세트 (* 3) 및 실패 할 때까지 테이블이 가져 오는 열 수를 사용하여 몇 가지 다른 형식을 시도했습니다 . 내가 시도한 콤보 중 어느 것도 실제 테스트 결과와 일치하는 값을 제공하지 않습니다.

  2. 행 크기를 계산할 때 고려해야 할 다른 '오버 헤드'는 무엇입니까?

  3. varchar (109) 열이있는 테이블 만들기에서 varchar (110) 열로 갈 때 오류 메시지가 8126에서 65535로 변경되는 이유는 무엇입니까?


나는 같은 문제가 있었다. 데이터베이스를 확인할 때 웹 브라우저의 애드온 중 하나가 페이지 소스 코드에 HTML 코드를 삽입하는 것 (양식까지)을 발견하여 문제가 발생했습니다.

HTML은 악당이 아닙니다. HTML의 크기도 아닙니다. text / varchar 열이 여러 개 있어야하고 해결할 수있는 몇 가지 제한 사항이 있습니다.
Rick James

답변:


19

질문에 대한 답변은 InnoDB 파일 형식에 따라 다르므로 복잡 합니다 . 현재 Antelope와 Barracuda라는 두 가지 형식이 있습니다.

중앙 테이블 스페이스 파일 (ibdata1)은 항상 영양 형식입니다. 테이블 당 파일을 사용하는 경우 my.cnf에서 설정 하여 개별 파일이 바라쿠다 형식을 사용하도록 할 수 있습니다 innodb_file_format=Barracuda.

기본 포인트 :

  • 하나의 16KB 페이지의 InnoDB 데이터는 최소한 두 개의 데이터 행을 보유해야합니다. 또한 각 페이지에는 페이지 체크섬과 로그 시퀀스 번호 등이 포함 된 머리글과 바닥 글이 있습니다. 여기에서 행당 8KB 미만의 한도를 얻을 수 있습니다.

  • INTEGER, DATE, FLOAT, CHAR과 같은 고정 크기 데이터 유형은이 기본 데이터 페이지에 저장되며 행 크기 제한에 포함됩니다.

  • VARCHAR, TEXT, BLOB와 같은 가변 크기 데이터 유형은 오버 플로우 페이지에 저장되므로 행 크기 제한에 완전히 반영되지 않습니다. 영양에서 오버 플로우 페이지에 저장되는 것 외에 최대 768 바이트의 이러한 열이 기본 데이터 페이지에 저장됩니다. 바라쿠다는 동적 행 형식을 지원 하므로 기본 데이터 페이지에 20 바이트 포인터 만 저장할 수 있습니다.

  • 가변 크기 데이터 형식에는 길이를 인코딩하기 위해 1 바이트 이상의 접두사가 붙습니다. 또한 InnoDB 행 형식에는 필드 오프셋 배열이 있습니다. 따라서 위키에 문서화 된 내부 구조가 어느 정도 있습니다 . [편집] 죽은 링크 - 여기 지금 더 나은 보인다.

바라쿠다는 오버 플로우 데이터의 스토리지 효율성을 높이기 위해 ROW_FORMAT = COMPRESSED 도 지원합니다 .

또한 잘 디자인 된 테이블이 행 크기 제한을 초과하는 것을 본 적이 없다고 언급해야합니다. First Normal Form 의 반복 그룹 조건을 위반하는 것은 강력한 "코드 냄새"입니다 .


2
DB에 익숙하지 않은 엔지니어는 플랫 데이터 경로를 사용하는 것이 매우 쉽습니다. 절대 수행하지 않습니다. 비슷한 상황을 가진 내 자신의 레거시 DB는 행 크기에 도달하지 않으므로 덜 극적인 것이지만 소년은 성능이 뛰어납니다! 보고 엔지니어가 조인을 수행하고 인덱싱 전체를 통해 해당 작업을 보완해야한다는 점을 인정해야한다고합니다.
TechieGurl

1

내 상황은 약간 다릅니다. 각 행에 저장해야하는 데이터 요소 중 하나가 잠재적으로 매우 큽니다. (데이터 필드는 여러 개의 포함 된 이미지를 포함 할 수있는 문서의 LONGBLOB입니다. 샘플 데이터베이스에는 25-30MB의 문서가 포함되어 있지만 경우에 따라이 문서가 더 클 수 있습니다.) . InnoDB 파일 형식을 Barracuda로 변경하고 로그 파일 크기를 늘리고 행 형식을 COMPRESSED로 설정했습니다.

내가 찾은 유일한 해결책은 MySQL 5.6.x에서 MySQL 5.5.x로 되 돌리는 것입니다.

당사 사이트를 사용함과 동시에 당사의 쿠키 정책개인정보 보호정책을 읽고 이해하였음을 인정하는 것으로 간주합니다.
Licensed under cc by-sa 3.0 with attribution required.