25列のテーブルを作成したい:
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のようなインターネット上で見つけたいくつかの解決策がありますが、まだその問題がありますので、誰か他の答えがあります
MySQL Server 5.6.20の変更により、最近同じエラーコードで苦労しました。 my.iniテキストファイルのinnodb_log_file_sizeを変更することで問題を解決できました。
リリースノートでは、innodb_log_file_sizeが小さすぎると「行サイズが大きすぎるエラー」がトリガーされると説明されています。
http://dev.mysql.com/doc/relnotes/mysql/5.6/en/news-5-6-20.html
ここですべてのソリューションを試しましたが、このパラメータのみ
innodb_strict_mode = 0
私の一日を解決しました...
マニュアルから:
Innodb_strict_mode設定は、CREATE TABLE、ALTER TABLE、およびCREATE INDEXステートメントの構文エラーの処理に影響します。 innodb_strict_modeはレコードサイズのチェックも有効にするため、選択したページサイズに対してレコードが大きすぎるためにINSERTまたはUPDATEが失敗することはありません。
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
サービスを再起動する(またはマシンを再起動する)ことを忘れないでください
最近82列のテーブルを作成しましたが、InnoDBでも同じエラーが発生しました。この問題を回避するために、テーブル形式をMyISAM
に切り替えました。これは、基本的なフォームで使用されたためです。
(REAL SOLUTION MYSQL 5.7)
現在最新のmysqlサーバー(5.7.21)で同じエラーに遭遇しました:
行サイズが大きすぎる(> 8126)。一部の列をTEXTまたはBLOBに変更すると役立つ場合があります。現在の行形式では、0バイトのBLOBプレフィックスがインラインに格納されます。
MYSQLのマニュアルを数時間読んだ後、解決策を見つけました!
キーパラメータは次のとおりです。innodb_page_size
MySQL 5.7では、32kおよび64kのページサイズのサポートが追加されました。 32kおよび64kのページサイズの場合、最大行長は約16000バイトです。
秘Theは、このパラメーターはmysqlサービスインスタンスのINITIALIZATIONの間にのみ変更できるため、インスタンスが既に初期化された後にこのパラメーターを変更します(インスタンスの最初の実行)。
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に増やすことはできません。動的でなければなりません(5.7のデフォルト)。
Innodb_page_sizeが32KBまたは64KBに設定されている場合、ROW_FORMAT = COMPRESSEDはサポートされません。 innodb_page_size = 32kの場合、エクステントサイズは2MBです。 innodb_page_size = 64kの場合、エクステントサイズは4MBです。 32kまたは64kのページサイズを使用する場合、innodb_log_buffer_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
ソリューションを見つけたすべての設定と説明は、次の場所にあります。
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html
お役に立てれば!
よろしく!
この問題のより深刻な変種について、他の人々に助けを提供したいだけです。状況によっては、「alter table drop column」および「alter table modify column」ステートメントでもエラー(「行サイズが大きすぎます。一部の列をTEXTまたはBLOBに変更する」)が発生します!
そのため、varcharをテキストに変更したり、列をドロップしたりできなくなります(問題を解決しようとすると、同じメッセージが表示されます)。
この問題がある場合、解決策は複数の列を一度に変更または削除することです。 MySQLでこれを行うには、「alter table example drop column a、drop column b、drop column c」という構文を使用します。一度に十分な列をドロップすると、エラーが発生するのではなく、実際に実行されます。
MySQLの最大行サイズはかなり明確です。
(ストレージエンジンに関係なく)すべてのテーブルの最大行サイズは65,535バイトです。ストレージエンジンは、この制限に追加の制約を課し、有効な最大行サイズを縮小する場合があります。
。 。 。
個々のストレージエンジンは、テーブルの列数を制限する追加の制限を課す場合があります。例:
InnoDBは最大1000列を許可します。
InnoDBは、行サイズをデータベースページの半分(約8000バイト)未満に制限します。VARBINARY、VARCHAR、BLOB、またはTEXTカラムは含まれません。
異なるInnoDBストレージ形式(COMPRESSED、REDUNDANT)は、異なる量のページヘッダーとトレーラーデータを使用します。これは、行で使用可能なストレージの量に影響します。
325の列の繰り返しセットがある場合、いくつかの制限を超えています。これも疑わしいデータ形式です。必要なテーブルの各行に325行、列の各グループに1行が必要です。
私が修正したのは追加することでした
SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=ON;
「.sql」ファイルの冒頭には、次のように記載されています。 https://Gist.github.com/tonykwon/8910261
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
サーバーを起動します!
MyISAMへの変更は解決策ではありません。 innodbの場合、次の方法でうまくいきました。
my.cnfで以下を設定します
innodb_strict_mode = 0
それにも出会いました。 「innodb_log_file_size」、「innodb_log_buffer_size」、および「my.ini」ファイルの他の設定を変更しても問題は解決しませんでした。列タイプ「テキスト」をvarchar(20)に変更し、20を超えるvarchar値を使用しないことで渡します。可能であれば、列のサイズを小さくすることもできます。テキスト---> varchar(20)varchar(256)-> varchar(20)
ここでは、@ fefeの優れた回答を使用して、dockerを使用して(docker-compose経由で)数分以内にこの問題を解決する方法を示します。 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 を使用しています。
(そして@fefeの回答で説明されているように)修正するには、MySQLインスタンスをゼロからセットアップする必要があります。つまり、mysqlドッカーコンテナandを削除する必要がありますmysqlボリュームDockerコンテナ。 docker container ls
とdocker volume ls
を実行して、すべてのコンテナーとボリュームを表示し、mysqlインスタンスとmysqlボリュームの2つの名前を選択します。私にとっては、mysql
(コンテナー)とdocker_data-mysql
(ボリューム)です。
実行中のインスタンスをdocker-compose down
経由で停止します(または、通常はdockerなどを停止します)。
それらを削除するには、docker container rm mysql
とdocker volume rm docker_data-mysql
を実行します(名前にアンダースコアとダッシュがあることに注意してください)。
これらの設定をdockerセットアップの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ボリュームが新しい設定で自動的にビルドされます。
次の方法で、データベースダンプファイルをインポートします。
gzip -dc < database.sql.gz | docker exec -i mysql mysql -uroot -pYOURPASSWORD
出来上がり!私にとってはとてもうまくいきました!
今朝、同様の問題があり、次の方法で私の命が救われました:
innodb_strict_mode
をオフにしようとしていますか?
SET GLOBAL innodb_strict_mode = 0;
その後、再度インポートを試みます。
innodb_strict_mode
は、MySQL> = 5.7.7を使用してONで、以前はOFFでした。
以下は私のために働いたが、他には何もなかった-:
SET GLOBAL innodb_log_buffer_size = 80 * 1024 * 1024 * 1024;
そして
SET GLOBAL innodb_strict_mode = 0;
これが誰かの助けになることを願っています。なぜなら、my.cnfでこれを何の喜びもなくしようとしていたので、それが私の時間の数日間を無駄にしていたからです。
これまでの回答では、innodb_page_sizeパラメーターの効果について言及していません。おそらく、このパラメーターの変更は、MySQL 5.7.6より前のサポートされた操作ではなかったためです。 ドキュメント から:
可変長列(VARBINARY、VARCHAR、BLOB、およびTEXT)を除く最大行長は、4KB、8KB、16KB、および32KBのページサイズのデータベースページの半分未満です。たとえば、16KBのデフォルトのinnodb_page_sizeの最大行長は約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のデータを使用した復元またはダウングレード操作に影響する可能性があります。
Google Cloud SQLでこのエラー(mysql 5.7など)が発生する場合、すべてのInnoDBフラグがサポートされているわけではないため、現時点ではおそらく簡単な修正にはなりません。私がそうであったようにMysql 5.5に出くわしている場合(古いWordpressセットアップの場合)、これはエクスポートする前にソースデータベースのいくつかの列タイプを圧縮する必要があることを意味します。
いくつかの詳細情報を見つけることができます こちら 。
私の場合、それは「テーブルの列数と行サイズの制限」のケースであり、この回答で説明されている変更を行うことで私の時間を節約できました。
[mysqld]セクションの下のmy.cnfファイルに次を追加します。
innodb_file_per_table
innodb_file_format =バラクーダ
ROW_FORMAT = COMPRESSEDを使用するようにテーブルを変更します。
ALTER TABLE table_name
ENGINE = InnoDB
ROW_FORMAT = COMPRESSED
KEY_BLOCK_SIZE = 8;