I want to create a table of 325 column:
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;
I replaced all the VARCHAR with the TEXT and i have added Barracuda in the my.ini file of MySQL, this is the attributes added:
innodb_file_per_table=1
innodb_file_format=Barracuda
innodb_file_format_check = ON
but i still have this error:
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.
EDIT: I can't change the structure of the database because it's legacy application/system/database. The create of a new table, it's an export of the legacy database.
EDIT2: i wrote this question that is similar to others but inside there are some solution that i found on internet like VARCHAR and Barracuda, but i still have that problem so i decided to open a new question with already the classic answer inside for seeing if someone have other answers
I tried all the solutions here, but only this parameter
innodb_strict_mode = 0
solved my day...
From the manual:
The innodb_strict_mode setting affects the handling of syntax errors
for CREATE TABLE, ALTER TABLE and CREATE INDEX statements.
innodb_strict_mode also enables a record size check, so that an INSERT
or UPDATE never fails due to the record being too large for the
selected page size.
I struggled with the same error code recently, due to a change in MySQL Server 5.6.20.
I was able to solve the problem by changing the innodb_log_file_size in the my.ini text file.
In the release notes, it is explained that an innodb_log_file_size that is too small will trigger a "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 edit path:
sudo nano /etc/mysql/mysql.conf.d/mysqld.cnf
on MS Windows the path will be something like:
C:\ProgramData\MySQL\MySQL Server 5.7\my.ini
Don't forget to retart the service (or restart your machine)
Have similar issue this morning and following way saved my life:
Did you try to turn off the innodb_strict_mode?
SET GLOBAL innodb_strict_mode = 0;
and then try to import it again.
innodb_strict_mode is ON using MySQL >= 5.7.7, before it was OFF.
The key parameter is: innodb_page_size
Support for 32k and 64k page sizes was added in MySQL 5.7. For both 32k and 64k page sizes, the maximum row length is approximately 16000 bytes.
The trick is that this parameter can be only changed during the INITIALIZATION of the mysql service instance, so it does not have any affect if you change this parameter after the instance is already initialized (the very first run of the instance).
innodb_page_size can only be configured prior to initializing the MySQL instance and cannot be changed afterward. If no value is specified, the instance is initialized using the default page size. See Section 14.6.1, “InnoDB Startup Configuration”.
So if you do not change this value in my.ini before initialization, the default value will be 16K, which will have row size limit of ~8K. Thats why the error comes up.
If you increase the innodb_page_size, the innodb_log_buffer_size must be also increased. Set it at least to 16M. Also if the ROW_FORMAT is set to COMPRESSED you cannot increase innodb_page_size to 32k, or 64K. It should be DYNAMIC (default in 5.7).
ROW_FORMAT=COMPRESSED is not supported when innodb_page_size is set to 32KB or 64KB. For innodb_page_size=32k, extent size is 2MB. For innodb_page_size=64k, extent size is 4MB. innodb_log_buffer_size should be set to at least 16M (the default) when using 32k or 64k page sizes.
Furthermore the innodb_buffer_pool_size should be increased from 128M to 512M at least, otherwise you will get an error on initialization of the instance (I do not have the exact error).
After this, the row size error gone.
The problem with this is that you have to create a new MySql instance, and migrate data to your new DataBase instance, from old one.
Parameters that I changed and works (after creating a new instance and initialized with the my.ini that is first modified with these settings):
innodb_page_size=64k
innodb_log_buffer_size=32M
innodb_buffer_pool_size=512M
All the settings and descriptions in which I found the solution can be found here:
https://dev.mysql.com/doc/refman/5.7/en/innodb-parameters.html
Hope this helps!
Regards!
For MariaDB users (version >= 10.2.2) and MySQL (version >= 5.7), the simple solution is:
ALTER TABLE `table` ROW_FORMAT=DYNAMIC;
If InnoDB strict mode is enabled this error can show.
Check enabled or not
SHOW variables LIKE '%strict%';
If enable then you can disable.
SET GLOBAL innodb_strict_mode=OFF;
For more detail information read here>>
I had the issue when importing SQL-dumps (from MySQL 8) to MariaDB on MacOS (with Brew).
Start by editing your my.cnf.
If you use Brew, it's usually store at /usr/local/etc/:
pico /usr/local/etc/my.cnf
Add this to the config:
[mysqld]
innodb_log_file_size = 1024M
innodb_strict_mode = 0
Then restart MariaDB:
brew services restart mariadb
Please notice that this in a workaround and not a fix since turning of strict mode in not fixing the problem, but since it's my local environment and not a production environment i'm ok with that.
MySQL is pretty clear about its maximum row size:
Every table (regardless of storage engine) has a maximum row size of
65,535 bytes. Storage engines may place additional constraints on this
limit, reducing the effective maximum row size.
. . .
Individual storage engines might impose additional restrictions that
limit table column count. Examples:
InnoDB permits up to 1000 columns.
InnoDB restricts row size to something less than half a database page
(approximately 8000 bytes), not including VARBINARY, VARCHAR, BLOB, or
TEXT columns.
Different InnoDB storage formats (COMPRESSED, REDUNDANT) use different
amounts of page header and trailer data, which affects the amount of
storage available for rows.
If you have 325 repeating sets of columns, you are exceeding several of the restrictions. This is also a suspicious data format. You should have 325 rows for each row in the table you want, one for each group of columns.
I recently created a table with 82 columns and had the same error with InnoDB.
To bypass the problem we switched the table format to MyISAM as it was just used for a basic form.
Changing into MyISAM is not the solution. For innodb following worked for me on mysql 8.0.27 on a huge server.
set followings on my.cnf and initialize it. Make sure you have taken backups if databases exist as initializing needs to be remove the data directory.
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
I just want to provide some other people with help with a more serious variant of this problem. In some situations, the error ("Row size too large .. Changing some columns to TEXT or BLOB") will occur even with "alter table drop column" and "alter table modify column" statements!
Consequently you can become completely stuck, not able to change a varchar to a text, or drop columns (trying to solve the problem ironically results in the same message).
If you have this problem, the solution is to alter or drop multiple columns at once. You can do this in MySQL with the syntax "alter table example drop column a, drop column b, drop column c" and if you drop enough columns at once, it will actually execute rather than raising the error.
For MySQL 5.7 on Mac OS X El Capitan:
OS X provides example configuration files at /usr/local/mysql/support-files/my-default.cnf
To add variables, first stop the server and just copy above file to, /usr/local/mysql/etc/my.cnf
cmd : sudo cp /usr/local/mysql/support-files/my-default.cnf /usr/local/mysql/etc/my.cnf
NOTE: create 'etc' folder under 'mysql' in case it doesn't exists.
cmd : sudo mkdir /usr/local/mysql/etc
Once the my.cnf is created under etc. it's time to set variable inside that.
cmd: sudo nano my.cnf
set variables below [mysqld]
[mysqld]
innodb_log_file_size = 512M
innodb_strict_mode = 0
now start a server!
innodb_log_file_size=512M
innodb_strict_mode=0
These two lines worked for me, in the mysql configuration !
The following worked for me, nothing else -:
SET GLOBAL innodb_log_buffer_size = 80*1024*1024*1024;
and
SET GLOBAL innodb_strict_mode = 0;
Hope this helps someone because it wasted couple of days of my time as I was trying to do this in my.cnf with no joy.
I also encountered that. Changing "innodb_log_file_size","innodb_log_buffer_size" and the other settings in "my.ini" file did not solve my problem. I pass it by changing my column types "text" to varchar(20) and not using varchar values bigger than 20 . Maybe you can decrease the size of columns, too, if it possible.
text--->varchar(20)
varchar(256) --> varchar(20)
What fixed mine was to add
SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=ON;
At the beginning of my ".sql" file, as it is said in:
https://gist.github.com/tonykwon/8910261
I was having same issue. I search "innodb_strict_mode" in my.ini but couldn't found.
I then added the same, it will still show you the warning, but you can continue. just add
innodb_strict_mode = 0;
I was using XAMPP on Windows 10 and had this issue using PHPMyAdmin.
when I added innodb_log_file_size = 500M and innodb_log_buffer_size = 800M to my my.ini file, MySQL would not start.
So I tried deleting ib_logfile0 and ib_logfile1 located in (C:\xampp\mysql\data) and this did not help at all.
luckily I could re-install (I needed to upgrade XAMPP anyway)
The simple solution in my case was to set innodb_strict_mode=0 in the my.ini file.
After this I was able to create the table.
STEPS:
Close XAMPP completely.
Edit the my.ini file (located in C:\xampp\mysql\data) add innodb_strict_mode=0 in the InnoDB section.
Start XAMPP and import the table again.
N.B complete these steps as ADMIN
Tried many things but found the solution by adding the below line in my.ini and restarting the MySQL service.
innodb_strict_mode = 0
sql_mode=""
innodb_strict_mode=0
brew services stop mariadb
brew services start mariadb
MariaDB has a fairly lengthy document specifically on this issue showing how and why with several ways to resolve it.
Troubleshooting Row Size Too Large Errors With InnoDB
Possible Options:
Converting the Table to the DYNAMIC Row Format (This is default is newer versions, so may not work if you're already set to dynamic)
Converting Some Columns to BLOB or TEXT
Increasing the Length of VARBINARY Columns
Increasing the Length of VARCHAR Columns
Refactoring the Table into Multiple Tables
Refactoring Some Columns into JSON
Disabling InnoDB Strict Mode ("Unsafe" way)
None of the answers to date mention the effect of the innodb_page_size parameter. Possibly because changing this parameter was not a supported operation prior to MySQL 5.7.6. From the documentation:
The maximum row length, except for variable-length columns (VARBINARY, VARCHAR, BLOB and TEXT), is slightly less than half of a database page for 4KB, 8KB, 16KB, and 32KB page sizes. For example, the maximum row length for the default innodb_page_size of 16KB is about 8000 bytes. For an InnoDB page size of 64KB, the maximum row length is about 16000 bytes. LONGBLOB and LONGTEXT columns must be less than 4GB, and the total row length, including BLOB and TEXT columns, must be less than 4GB.
Note that increasing the page size is not without its drawbacks. Again from the documentation:
As of MySQL 5.7.6, 32KB and 64KB page sizes are supported but ROW_FORMAT=COMPRESSED is still unsupported for page sizes greater than 16KB. For both 32KB and 64KB page sizes, the maximum record size is 16KB. For innodb_page_size=32k, extent size is 2MB. For innodb_page_size=64k, extent size is 4MB.
A MySQL instance using a particular InnoDB page size cannot use data files or log files from an instance that uses a different page size. This limitation could affect restore or downgrade operations using data from MySQL 5.6, which does support page sizes other than 16KB.
FIX FOR MYSQL IN DOCKER
I'm using #fefe's excellent answer here to show how to fix this problem within some minutes when using docker (via docker-compose). It's quite easy as you don't have to touch MySQL's configuration files, but it requires you to export and import your entire data:
The default situation of your MySQL setup probably looks like this. Your data is saved inside the data-mysql volume.
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
Make a backup of your entire data/database via SQL export, so you have a .sql.gz or something. I'm using Adminer for this.
To fix (and as explained in #fefe's answer) we have to setup the MySQL instance from zero, meaning we have to delete the mysql docker container and the mysql volume docker container. Do a docker container ls and a docker volume ls to see all your containers and volumes, and pick the two names that are your mysql instance and your mysql volume, for me it's mysql (container) and docker_data-mysql (volume).
Stop your running instances via docker-compose down (or however you usually stop your docker stuff).
To delete them, I do docker container rm mysql and docker volume rm docker_data-mysql (note that there is an underscore AND a dash in the name).
Add these settings to your mysql block in your docker setup:
mysql:
image: mysql:5.7.25
command: ['--innodb_page_size=64k', '--innodb_log_buffer_size=32M', '--innodb_buffer_pool_size=512M']
container_name: mysql
# ...
Restart your instances, the mysql and mysql volume should be build automatically, now with the new settings.
Import your database dump file, maybe with:
gzip -dc < database.sql.gz | docker exec -i mysql mysql -uroot -pYOURPASSWORD
Voila! Worked very fine for me!
I have changed the length of value from varchar(255) to varchar(25) to all varchar columns and i get the solution.
if you are using the MySQLWorkbench you have the option to change the to change the query_alloc_block_size= 16258 and save it.
Step 1. click on the options file at the left side.
Step 2: click on General and select the checkBox of query_alloc_block_size and increase their size. for example change 8129 --> 16258
On my case it was casing from Limits on Table Column Count and Row Size
and doing changes described in this answer saved my day.
Add the following to the my.cnf file under [mysqld] section.
innodb_file_per_table
innodb_file_format = Barracuda
ALTER the table to use ROW_FORMAT=COMPRESSED.
ALTER TABLE table_name
ENGINE=InnoDB
ROW_FORMAT=COMPRESSED
KEY_BLOCK_SIZE=8;
https://stackoverflow.com/a/15585700/2195130
If you're getting this error on Google Cloud SQL (mysql 5.7 for example) then it's probably not at this time going to be a simple fix as not all InnoDB flags are supported. If you're coming across from Mysql 5.5 as I was (for an old Wordpress setup) this could mean you need to wrangle some column types in the source database before you export.
Some more information can be found here.
I experienced the same issue on an import of a data dump. Temporarily disabling the innodb strict mode solved my problem.
-- 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;
In the case that this message appears when changing MariaDB version, I had exactly the same issue changing to MariaDB 10.6.5 and that's how I solved the issue:
Using PhpMyAdmin, I exported the .sql file from the old MariaDB version
Edited the .sql file using an editor such as Notepad++ and added the line
SET GLOBAL innodb_default_row_format='dynamic'; on top as follows:
-- 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.Imported the altered .sql file to MariaDB 10.6.5
All worked fine
I'd like to know if WordPress can be pointed at the DB equivalent of SQL CE. I presume the answer is yes, if MySQL has something equivalent to SQL CE.
What's the low down on this?
Update: Given the answers so far, I will re-state my question so that it is more easily understood: "Can WordPress be pointed at SQLite instead of MySQL?"
I'd like to know if WordPress can be pointed at the DB equivalent of SQL CE
No.
Or at least not easily. WordPress is built on top the LAMP stack where M is strictly MySQL. Although it has a database abstraction layer (WPDB), the code and plugins are littered and accept direct SQL code (MySQL).
If you are interested in this, check out the discussion in the WP Codex.
What is the MySQL Equivalent of SQL CE?
In my opinion, I'd make the jump and say SQLite.
As far as I'm aware there is no MySQL equivalent of SQL Compact Edition. You may want to check SQLite instead (www.sqlite.org). Wordpress supports this.
You may find this surprising but MySQL can be stripped down to operate like a Compact Edition database. MySQL (eh Oracle) does not seem to support the Embedded MySQL anymore (or at least they make hard to find). However, you can make the following tweeks to MySQL:
TWEEK #1 : Disable InnoDB
Start mysqld with this in my.cnf:
[mysqld]
skip-innodb
Benefits
Faster startup of mysql
Does not create ibdata1, ib_logfile0, ib_logfile1
Does not allocate default InnoDB Buffer Pool (MySQL 5.5 128M, before MySQL 5.5 8MB)
Less memory consumption (InnoDB code is not memory resident)
TWEEK #2 : Preload Indexes of the Most Important MyISAM Tables
By default, MyISAM uses the Key Cache and its size is governed by key_buffer_Size. Interestingly, MyISAM allows you to create a dedicate key cache for onr ot more tables.
For example, if you have the table mysite.wp_posts, you can create a dedicated 256M key cache as follows:
SET GLOBAL wp_posts_cache.key_buffer_size = 1024 * 1024 * 256;
CACHE INDEX mysite.wp_posts IN wp_posts_cache;
LOAD INDEX INTO CACHE mysite.wp_posts;
You can have this done at start by doing this:
echo "SET GLOBAL wp_posts_cache.key_buffer_size = 1024 * 1024 * 256;" > /var/lib/mysql/startup.sql
echo "CACHE INDEX mysite.wp_posts IN wp_posts_cache;" > /var/lib/mysql/startup.sql
echo "LOAD INDEX INTO CACHE mysite.wp_posts;" > /var/lib/mysql/startup.sql
Give it a Try !!!
then add this to my.cnf
[mysqld]
init-file=/var/lib/mysql/startup.sql
Then, restart mysql
I just went to look over one my site's databases and noticed that all of the tables had been converted to MyISAM (they used to be InnoDB).
What's more is that InnoDB seems to missing, along with BerkeleyDB, Federated, and others.
A few months ago I upgraded from MySql 5.0 to 5.1.38. I can't imagine that I wouldn't have noticed if InnoDB was not installed after the upgrade, but maybe it's been that way since the upgrade. Having several 10 GB tables automatically convert themselves to MyISAM without hearing about any downtime seems very unlikely to me.
Regardless, the mysql system variable have_innodb is set to NO. Can I simply change that to YES or does that mean InnoDB is missing from the install?
Maybe InnoDB parameters were changed during upgrade? This advice from MySQL Forums helped me in a similar situation: http://forums.mysql.com/read.php?22,397052,408970
In short: Stop the MySQL daemon, delete ib_logfile* from datadir, restart MySQL.
If the field in SHOW ENGINES is "no" it means it's not compiled in. You would have to either compile the server again, compile the innodb plugin and load it or fetch server binaries which have it enabled.
You can't simply set the mysql system variable to YES to convert the table from MyISAM to InnoDB.
ALTER TABLE t1 ENGINE=InnoDB;
When InnoDB support is turned off even is you use ENGINE=InnoDB in your create table statements, the table will use the default storage engine for MySQL which is normally MyISAM.
It could also be the case that the innodb logfile[01] are corrupted. In which case the engine will show as disabled and the tables as ISAM. The log will mention it.