MySQL: 오류 코드: 1118 행 크기가 너무 큽니다(> 8126).일부 열을 TEXT 또는 BLOB로 변경
325열 테이블을 만듭니다.
CREATE TABLE NAMESCHEMA.NAMETABLE
(
ROW_ID TEXT NOT NULL , //this is the primary key
324 column of these types:
CHAR(1),
DATE,
DECIMAL(10,0),
DECIMAL(10,7),
TEXT,
LONG,
) ROW_FORMAT=COMPRESSED;
모든 VARCHAR을 TEXT로 교체하고 MySQL의 my.ini 파일에 Barracuda를 추가했습니다. 추가된 특성은 다음과 같습니다.
innodb_file_per_table=1
innodb_file_format=Barracuda
innodb_file_format_check = ON
하지만 여전히 다음 오류가 있습니다.
Error Code: 1118
Row size too large (> 8126). Changing some columns to TEXT or BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
편집: 레거시 응용 프로그램/시스템/데이터베이스이므로 데이터베이스 구조를 변경할 수 없습니다.새 테이블 작성은 레거시 데이터베이스를 내보내는 것입니다.
EDIT2: 다른 질문과 유사한 질문을 작성했지만 내부에는 VARCHAR 및 Barracuda와 같은 인터넷에서 찾은 솔루션이 몇 개 있지만, 여전히 문제가 남아 있기 때문에 다른 답을 가지고 있는지 알아보기 위해 이미 고전적인 답변이 포함된 새 질문을 열기로 했습니다.
여기서 모든 솔루션을 시도했지만 이 파라미터만
innodb_strict_mode = 0
내 하루를 해결했다...
매뉴얼:
innodb_strict_mode 설정은 CREATE TABLE, ALTER TABLE 및 CREATE INDEX 문의 구문 오류 처리에 영향을 줍니다.innodb_strict_mode를 사용하면 선택한 페이지 크기에 비해 레코드가 너무 커서 INSERT 또는 UPDATE가 실패하는 일이 없습니다.
최근 MySQL Server 5.6.20 변경으로 인해 동일한 에러코드로 인해 어려움을 겪었습니다.my.ini 텍스트 파일의 innodb_log_file_size를 변경하여 문제를 해결할 수 있었습니다.
릴리스 노트에서는 innodb_log_file_size가 너무 작으면 "Row size too large error"가 발생한다는 설명이 나와 있습니다.
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html
ERROR 1118 (42000) at line 1852:
Row size too large (> 8126). Changing some columns to TEXT or
BLOB may help. In current row format, BLOB prefix of 0 bytes is stored inline.
[mysqld]
innodb_log_file_size = 512M
innodb_strict_mode = 0
ubuntu 16.04 편집 경로:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
MS Windows 의 패스는 다음과 같습니다.
C:\ProgramData\MySQL\MySQL Server 5.7\my.ini
서비스의 재기동(또는 머신의 재기동)을 잊지 말아 주세요.
주요 파라미터는 innodb_page_size 입니다.
32k 및 64k 페이지 크기 지원이 MySQL 5.7에서 추가되었습니다.32k 페이지 사이즈와 64k 페이지 사이즈 모두에서 최대 행 길이는 약 16000바이트입니다.
이 파라미터는 mysql 서비스인스턴스의 INITIALIZION 중에만 변경할 수 있기 때문에 인스턴스가 이미 초기화된 후(인스턴스의 첫 번째 실행) 이 파라미터를 변경해도 영향을 주지 않습니다.
innodb_page_size는 MySQL 인스턴스를 초기화하기 전에만 구성할 수 있으며 이후에는 변경할 수 없습니다.값을 지정하지 않으면 기본 페이지 크기를 사용하여 인스턴스가 초기화됩니다.섹션 14.6.1 "InnoDB 스타트업 컨피규레이션"을 참조하십시오.
따라서 초기화 전에 my.ini에서 이 값을 변경하지 않으면 기본값은 16K가 되고 행 크기 제한이 최대 8K가 됩니다.그래서 에러가 발생합니다.
innodb_page_size를 늘릴 경우 innodb_log_buffer_size도 늘려야 합니다.최소 16M으로 설정합니다.또한 ROW_FORMAT이 COMPRESSED로 설정되어 있는 경우 innodb_page_size를 32k 또는 64K로 늘릴 수 없습니다.DYNAMIC이어야 합니다(5.7의 기본값).
innodb_page_size가 32KB 또는 64KB로 설정된 경우 ROW_FORMAT=COMPRESSED가 지원되지 않습니다.innodb_page_size=32k의 경우 익스텐트 크기는 2MB, innodb_page_size=64k의 경우 익스텐트 크기는 4MB입니다. 32k 또는 64k 페이지 크기를 사용할 경우 innodb_log_size를 최소 16M(기본값)으로 설정해야 합니다.
또한 innodb_buffer_pool_size를 128M에서 512M으로 늘려야 합니다.그렇지 않으면 인스턴스 초기화 시 오류가 발생합니다(정확한 오류는 없습니다).
그 후 행 크기 오류가 사라졌습니다.
이 문제의 문제는 새 MySql 인스턴스를 생성하고 이전 인스턴스에서 새 DataBase 인스턴스로 데이터를 마이그레이션해야 한다는 것입니다.
변경 및 동작하는 파라미터(새로운 인스턴스를 생성하여 이러한 설정으로 처음 변경된my.ini로 초기화한 후):
innodb_page_size=64k
innodb_log_buffer_size=32M
innodb_buffer_pool_size=512M
솔루션을 찾은 모든 설정 및 설명은 다음 URL에서 확인할 수 있습니다.
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html
이게 도움이 됐으면 좋겠네요!
안부 전해 주세요!
오늘 아침에도 비슷한 문제가 있어서 다음 방법으로 목숨을 구했습니다.
★★★★★★★★★★★★★★의 전원을 했습니까?innodb_strict_mode
SET GLOBAL innodb_strict_mode = 0;
다시 Import를 시도합니다.
innodb_strict_modeMySQL > = 5.7.7 ON.
MariaDB 사용자(버전 > = 10.2.2) 및 MySQL(버전 > = 5.7)의 경우 간단한 솔루션은 다음과 같습니다.
ALTER TABLE `table` ROW_FORMAT=DYNAMIC;
SQL 덤프(MySQL 8)를 MacOS(Brew)의 MariaDB로 가져올 때 문제가 발생했습니다.
, 「 」의 을 합니다.my.cnf.
Brew에 ./usr/local/etc/:
pico /usr/local/etc/my.cnf
이것을 설정에 추가합니다.
[mysqld]
innodb_log_file_size = 1024M
innodb_strict_mode = 0
그런 다음 마리아를 재시작합니다.DB:
brew services restart mariadb
이것은 문제를 수정하지 않는 엄격한 모드로 전환한 이후 수정이 아닌 회피책이지만, 운영 환경이 아닌 로컬 환경이기 때문에 괜찮습니다.
InnoDB strict 모드를 활성화하면 이 오류가 나타날 수 있습니다.
활성화 여부 확인
SHOW variables LIKE '%strict%';
유효하게 하면, 무효로 할 수 있습니다.
SET GLOBAL innodb_strict_mode=OFF;
최근에 82개의 컬럼으로 테이블을 만들었는데 InnoDB에서 같은 오류가 발생했습니다.을 ""로 했습니다.MyISAM기본적인 형태로만 사용됐기 때문입니다.
MyISAM으로 변경하는 것은 해결책이 아닙니다.innodb following은 큰 서버에서 mysql 8.0.27에서 저를 위해 일했습니다.
my.cnf에서 다음을 설정하고 초기화합니다.초기화 중 데이터 디렉토리를 제거해야 하므로 데이터베이스가 존재하는 경우 백업을 수행했는지 확인하십시오.
innodb-strict-mode=OFF
innodb-page-size=64K
innodb-log-buffer-size=256M
innodb-log-file-size=1G
innodb-data-file-path=ibdata1:2G:autoextend
MySQL은 최대 행 크기에 대해 매우 명확합니다.
모든 테이블(스토리지 엔진에 관계없이)의 최대 행 크기는 65,535바이트입니다.스토리지 엔진은 이 제한에 추가 제약을 가하여 유효 최대 행 크기를 줄일 수 있습니다.
. . .
개별 스토리지 엔진은 테이블 열 수를 제한하는 추가 제한을 가할 수 있습니다.예:
InnoDB는 최대 1000개의 열을 허용합니다.
InnoDB는 VARB를 포함하지 않고 행 크기를 데이터베이스 페이지의 절반(약 8000바이트) 미만으로 제한합니다.INARY, VARCHAR, BLOB 또는 TEXT 열.
InnoDB 스토리지 형식(COMPRESSED, REDUEND)마다 페이지 헤더 및 트레일러 데이터의 양이 달라 행에 사용할 수 있는 스토리지 양에 영향을 미칩니다.
반복 열 집합이 325개이면 여러 제한을 초과한 것입니다.이것도 의심스러운 데이터 형식입니다.표의 각 행에 대해 열의 각 그룹에 하나씩 325개의 행이 있어야 합니다.
Mac OS X El Capitan에서 MySQL 5.7을 사용하는 경우:
OS X는 /usr/local/mysql/support-files/my-default.cnf에 샘플 설정 파일을 제공합니다.
변수를 추가하려면 먼저 서버를 중지하고 위의 파일을 /usr/local/mysql/etc/my.cnf 에 복사합니다.
cmd : sudo cp /usr/local/mysql/support-files/my-default.cnf /usr/local/mysql/etc/my.cnf
메모: 존재하지 않는 경우 'mysql' 아래에 'etc' 폴더를 만듭니다.
cmd : sudo mkdir /usr/local/mysql/etc
my.cnf가 작성되면 등.이제 그 안에 변수를 설정할 때입니다.
cmd: sudo nano my.cnf
변수를 [mysqld] 이하로 설정합니다.
[mysqld]
innodb_log_file_size = 512M
innodb_strict_mode = 0
이제 서버를 시작합니다!
나는 단지 이 문제의 더 심각한 변종들에 대해 다른 사람들에게 도움을 주고 싶을 뿐이다.경우에 따라서는 에러("Row size too large ...")가 발생합니다.일부 열을 TEXT 또는 BLOB)로 변경하는 것은 "table drop column" 및 "table modify column" 문에서도 발생합니다.
그 결과 완전히 고착되거나 varchar를 텍스트로 변경할 수 없거나 열을 드롭할 수 있습니다(반어적으로 문제를 해결하려고 하면 같은 메시지가 나타납니다).
이 문제가 있는 경우 여러 열을 한 번에 변경하거나 삭제하는 것이 해결책입니다.MySQL에서는 "alter table example drop column a, drop column b, drop column c" 구문을 사용하여 이 작업을 수행할 수 있습니다.한 번에 충분한 컬럼을 드롭하면 오류가 발생하지 않고 실제로 실행됩니다.
innodb_log_file_size=512M
innodb_strict_mode=0
mysql 설정에서는 이 2개의 행이 동작했습니다.
다음은 나에게 효과가 있었지만, 다른 것은 없었다.
SET GLOBAL innodb_log_size = 80*sen*sen*sen;
그리고.
SET GLOBAL innodb_mode = 0;
my.cnf에서 이 작업을 수행하느라 며칠간의 시간을 허비했기 때문에 누군가 도움이 되었으면 합니다.
내 것이 무엇을 추가했는가?
SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=ON;
.sql 파일의 선두에 https://gist.github.com/tonykwon/8910261 라고 기재되어 있습니다.
저도 같은 문제가 있었어요.my.ini에서 "innodb_strict_mode"를 검색했지만 찾을 수 없었습니다.
그런 다음 동일한 내용을 추가했습니다. 경고가 계속 표시되지만 계속할 수 있습니다.덧붙이기만 하면 된다
innodb_strict_mode = 0;
Windows 10 에서는 XAMPP 를 사용하고 있었습니다만, PHPMyAdmin 를 사용했을 때에 이 문제가 발생했습니다.
가 했 when when를 때innodb_log_file_size = 500M ★★★★★★★★★★★★★★★★★」innodb_log_buffer_size = 800M 나 my my mymy.ini이이 、 MySQL 、 MySQL 、 않다다다다다다다다 。
저는 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★ib_logfile0 ★★★★★★★★★★★★★★★★★」ib_logfile1 ( ( ) )에 .C:\xampp\mysql\data을 사용하다
다행히 재설치할 수 있었다(XAMPP를 업그레이드해야 했다)
은 ★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★★innodb_strict_mode=0 my.inifilename을 클릭합니다.
그 후 테이블을 작성할 수 있었습니다.
순서:
- XAMPP를 완전히 닫습니다.
my.ini에 )C:\xampp\mysql\data) 추가) 。innodb_strict_mode=0InnoDB inno inno inno inno inno inno inno inno inno 。- XAMPP를 시작하고 테이블을 다시 Import합니다.
N.B.는 관리자로서 다음 단계를 완료합니다.
많은 시도를 했지만 my.ini에 아래 행을 추가하고 MySQL 서비스를 재시작하여 해결책을 찾았습니다.
innodb_strict_mode = 0
저도 그거 봤어요."innodb_log_file_size", "innodb_log_buffer_size" 및 "my.ini" 파일의 다른 설정을 변경해도 문제가 해결되지 않았습니다.컬럼 타입 "text"를 varchar(20)로 변경하고 20보다 큰 varchar 값을 사용하지 않음으로써 전달합니다.가능하다면 컬럼의 크기를 줄일 수도 있습니다.text---> varchar(20) varchar(256) --> varchar(20)
- sql_mode="
- innodb_mod_mode=0
- 양조 서비스 중지 mariadb
- 양조 서비스를 시작하다
varchar(255)에서 varchar(25)로 모든 varchar 컬럼으로 값의 길이를 변경하여 솔루션을 얻습니다.
지금까지의 답변 중 innodb_page_size 파라미터의 효과에 대해서는 언급하지 않았습니다.MySQL 5.7.6 이전 버전에서는 이 매개 변수 변경이 지원되지 않았기 때문일 수 있습니다.매뉴얼에서 다음 항목을 참조하십시오.
가변 길이 열(VARBINAL, VARCHAR, BLOB 및 TEXT)을 제외한 최대 행 길이는 4KB, 8KB, 16KB 및 32KB 페이지 크기의 데이터베이스 페이지의 절반보다 약간 작습니다.예를 들어 기본 innodb_page_size 16KB의 최대 행 길이는 약 8000바이트입니다.InnoDB 페이지 크기가 64KB인 경우 최대 행 길이는 약 16000바이트입니다.LONGBLOB 및 LONGTEXT 열은 4GB 미만이어야 하며 BLOB 및 TEXT 열을 포함한 총 행 길이는 4GB 미만이어야 합니다.
페이지 크기를 늘리는 데 단점이 없는 것은 아닙니다.매뉴얼에서 다시 설명하겠습니다.
MySQL 5.7.6에서는 32KB 및 64KB의 페이지 크기가 지원되지만 16KB보다 큰 페이지 크기에는 ROW_FORMAT=COMPRESSED가 여전히 지원되지 않습니다.32KB 및 64KB 페이지 크기 모두에서 최대 레코드 크기는 16KB입니다.innodb_page_size=32k의 경우 익스텐트 사이즈는 2MB, innodb_page_size=64k의 경우 익스텐트 사이즈는 4MB입니다.
특정 InnoDB 페이지 크기를 사용하는 MySQL 인스턴스는 다른 페이지 크기를 사용하는 인스턴스의 데이터 파일 또는 로그 파일을 사용할 수 없습니다.이 제한은 16KB 이외의 페이지 크기를 지원하는 MySQL 5.6의 데이터를 사용한 복원 또는 다운그레이드 작업에 영향을 줄 수 있습니다.
도커의 MYSQL 고정 장치
도커를 사용할 때 (도커 컴포즈를 통해) 몇 분 안에 이 문제를 해결하는 방법을 보여주기 위해 @fefe의 훌륭한 답변을 사용하고 있습니다.MySQL의 구성 파일을 조작할 필요가 없기 때문에 매우 간단하지만 전체 데이터를 내보내고 가져와야 합니다.
MySQL 설정의 기본 상황은 다음과 같습니다.데이터가 저장되는 장소는data-mysql용량.
mysql:
image: mysql:5.7.25
container_name: mysql
restart: always
volumes:
- data-mysql:/var/lib/mysql
environment:
- "MYSQL_DATABASE=XXX"
- "MYSQL_USER=XXX"
- "MYSQL_PASSWORD=XXX"
- "MYSQL_ROOT_PASSWORD=XXX"
expose:
- 3306
SQL 내보내기를 통해 전체 데이터/데이터베이스를 백업하면 .sql.gz 같은 것을 얻을 수 있습니다.관리자(adminer)를 사용하고 있습니다.
(@fe's 답변에서 설명한 바와 같이) 수정하려면 MySQL 인스턴스를 0부터 설정해야 합니다.즉, mysql 도커 컨테이너와 mysql 볼륨 도커 컨테이너를 삭제해야 합니다.을 실행합니다.
docker container ls및 adocker volume ls모든 컨테이너와 볼륨을 보고 mysql 인스턴스와 mysql 볼륨이라는 두 이름을 선택합니다.mysql(표준) 및docker_data-mysql(볼륨).실행 중인 인스턴스를 중지하려면
docker-compose down(혹은 보통 도킹 스테이션은 정지합니다).삭제하기 위해
docker container rm mysql그리고.docker volume rm docker_data-mysql(이름에는 밑줄과 대시가 있습니다).도커 설정의 mysql 블록에 다음 설정을 추가합니다.
mysql:
image: mysql:5.7.25
command: ['--innodb_page_size=64k', '--innodb_log_buffer_size=32M', '--innodb_buffer_pool_size=512M']
container_name: mysql
# ...
인스턴스를 재시작하면 mysql 및 mysql 볼륨이 새 설정으로 자동으로 구축됩니다.
데이터베이스 덤프 파일 Import 방법:
gzip -dc < database.sql.gz | docker exec -i mysql mysql -uroot -pYOURPASSWORD
와일라! 나한테는 아주 잘 먹혔어!
MySQLWorkbench를 사용하는 경우 를 변경하여 query_block_size= 16258을 변경하여 저장할 수 있습니다.
스텝 1.options file왼쪽에서
순서 2: 을 클릭합니다.General를 선택합니다.checkBoxquery_block_size를 지정하고 크기를 늘립니다.예를 들어 8129 --> 16258을 변경합니다.
제 경우 테이블 컬럼카운트와 행크기의 제한에 따라 이 답변에 기재된 변경을 통해 위기를 모면할 수 있었습니다.
[ mysqld ]섹션의 my.cnf 파일에 다음 항목을 추가합니다.
innodb_file_per_table
innodb_file_format = BarracudaROW_FORMAT=COMPRESSED를 사용하도록 테이블을 변경합니다.
ALTER TABLE_name
엔진=InnoDB
ROW_FORMAT=압축
키 블록사이즈=8;
https://stackoverflow.com/a/15585700/2195130
Google Cloud SQL(예를 들어 mysql 5.7)에서 이 오류가 발생하는 경우 일부 InnoDB 플래그가 지원되지 않으므로 현재 간단한 수정이 아닐 수 있습니다.이전 Wordpress 셋업의 경우처럼 Mysql 5.5를 사용하는 경우 내보내기 전에 소스 데이터베이스의 일부 열 유형을 서로 충돌시켜야 합니다.
자세한 정보는 이쪽에서 확인할 수 있습니다.
데이터 덤프 Import에서도 같은 문제가 발생했습니다.innodb strict 모드를 일시적으로 비활성화하면 문제가 해결되었습니다.
-- shows the acutal value of the variable
SHOW VARIABLES WHERE variable_name = 'innodb_strict_mode';
-- change the value (ON/OFF)
SET GLOBAL innodb_strict_mode=ON;
MariaDB 버전 변경 시 이 메시지가 뜨는 경우, MariaDB 10.6.5로 변경했을 때와 완전히 같은 문제를 해결했습니다.
- PhpMyAdmin을 사용하여 이전 MariaDB 버전에서 .sql 파일을 내보냈습니다.
- Notepad하고 .sql .
SET GLOBAL innodb_default_row_format='dynamic';위에는 다음과 같이 표시됩니다.
-- phpMyAdmin SQL Dump
-- version 5.1.1
-- https://www.phpmyadmin.net/
--
-- Host: (*Your host*)
-- Generation Time: Feb 12, 2022 at 05:22 PM
-- Server version: 10.6.4-MariaDB
-- PHP Version: 8.0.3
SET GLOBAL innodb_default_row_format='dynamic';
SET SQL_MODE = "NO_AUTO_VALUE_ON_ZERO";
START TRANSACTION;
SET time_zone = "+00:00";
3. 변경된 .sql 파일을 MariaDB 10.6.5로 Import.
모두 정상적으로 동작했습니다.
mysql 5.7.36을 사용하고 있습니다.
는 이이가 to to to to to to to to to to to to to로 바뀝니다.my.ini파일이 작동했습니다.
max_allowed_packet = 900M
innodb-default-row-format = dynamic
innodb-lock-wait-timeout = 1200
innodb-log-buffer-size=512M
innodb-log-file-size = 1G
확인은 할 수 없지만, 첫 번째 2개의 설정이 가장 큰 영향을 미쳤다고 생각합니다.
서비스를 재시작하여 변경 내용을 적용합니다.
언급URL : https://stackoverflow.com/questions/22637733/mysql-error-code-1118-row-size-too-large-8126-changing-some-columns-to-te
'itsource' 카테고리의 다른 글
| 객체가 비어 있습니까? (0) | 2022.11.05 |
|---|---|
| IF 문을 사용할 때 MariaDB 구문 오류 발생 (0) | 2022.11.05 |
| JavaScript에서 "assert"란 무엇입니까? (0) | 2022.11.05 |
| 루프하지 않고 Array List의 합계를 얻을 수 있습니까? (0) | 2022.11.05 |
| 특정 클래스가 있는 가장 가까운 상위 요소 찾기 (0) | 2022.11.05 |