I duplicated a project with a vagrant box which installs Debian, Nginx, PhpMyAdmin, .. With the new project the Laravel's php artisan migrate
is not working anymore and I get the error:
[Illuminate\Database\QueryException]
SQLSTATE[HY000]: General error: 1709 Index column size too large. The maximum column size is 767 bytes. (SQL: alter table `courses` add unique `courses_name_unique`(`na
me`))
When I make a dump (structure + data) of the working project database and import it in the database giving the errors on migrate, then everything is ok and it creates all the tables and data is imported..
How can I fix the size so that I can run the migrate method?
As you can see in the error message - "The maximum column size is 767 bytes", if you want to create an index on it. A VARCHAR(255)
column can take up to 765 (255*3) bytes using utf8
and 1020 (255*4) bytes using utf8mb4
. This is because in MySQL utf8
takes up to 3 bytes and utf8mb4
up to 4 bytes (the real UTF8). Thus creating a VARCHAR(255)
(unique) index with utf8mb4
will fail.
This are your options to fix the problem:
Set default collation in my.ini
:
collation_server=utf8_unicode_ci
character_set_server=utf8
Set default collation for the database when creating:
CREATE DATABASE IF NOT EXISTS `your_db` COLLATE 'utf8_unicode_ci'
Set default collation for the table/column. (I don't recommend that)
Change the column size to 190 (varchar(190)
) or less.
The Mysql server configuration is overwriten by Laravel's migration command. It will set the collation and charset to the configuration's version.
Change the fields charset
and collation
of the db engine in the database config file located in config/database.php
.
..
'mysql' => [
'driver' => 'mysql',
'host' => env('DB_HOST', '127.0.0.1'),
'port' => env('DB_PORT', '3306'),
'database' => env('DB_DATABASE', 'forge'),
'username' => env('DB_USERNAME', 'forge'),
'password' => env('DB_PASSWORD', ''),
//'charset' => 'utf8mb4',
//'collation' => 'utf8mb4_unicode_ci',
'charset' => 'utf8',
'collation' => 'utf8_unicode_ci',
'prefix' => '',
'strict' => true,
'engine' => null,
],
..
For mariadb, update your *my.cnf
file with following configuration,
innodb_default_row_format=dynamic
innodb_file_format=barracuda
innodb_file_per_table=true
innodb_large_prefix=true
Then, you have to restart mariadb
service for updated configuration to take effect.
Three solutions, each with a drawback:
MySQL 5.7 avoids the problem. Consider upgrading.
VARCHAR(255)
is usually var bigger than necessary. If you can safely shrink to 191 or less, the error will go away.
Switch to utf8 (from utf8mb4), if you don't need Chinese or Emoji.
2 more options here: http://mysql.rjweb.org/doc.php/limits#767_limit_in_innodb_indexes
For Laravel 5.5 or higher change on your config/database.php file the engine to InnoDB ROW_FORMAT=DYNAMIC:
'connections' => [
...
'mysql' => [
...
'engine' => 'InnoDB ROW_FORMAT=DYNAMIC',
]]
Thanks to laracasts: https://laracasts.com/discuss/channels/eloquent/migrations-and-table-options-row-format
By default MySQL uses the character set utf8 which means that we use 3 bytes for every 1 character. This means, column type of varchar(10) uses 30 bytes resulting in the max prefix size for compact row format to be equivalent to varchar(255). That is 255 * 3bytes = 765 bytes which is, two bytes less than the max of 767 bytes.
With innodb_large_prefix set to on and using row format COMPRESSED or DYNAMIC, you can increase the max prefix character size to 65536 bytes instead of 767 bytes. The below chart shows the max character length with InnoDB large prefix and [COMPRESSED| DYNAMIC] row formats. These values, expect for utf8mb4, are higher than the maximum row size of a table, so there is no way to hit these limits
More info here https://discuss.pivotal.io/hc/en-us/articles/115004086747-Apps-are-down-due-to-the-Maximum-Column-Size-is-767-bytes-Constraint-in-MySQL
In App\Providers\AppServiceProvider.php
, import Schema
with:
use Illuminate\Support\Facades\Schema;
and in the boot()
function add this line:
Schema::defaultStringLength(191);
Also had this issue what I just did, was revert from utf8mb4_unicode_ci to utf8_unicode_ci in the db connection script
If you love us? You can donate to us via Paypal or buy me a coffee so we can maintain and grow! Thank you!
Donate Us With