Quando eu executei o seguinte comando:

ALTER TABLE `mytable` ADD UNIQUE (
`column1` ,
`column2`
);

Recebi esta mensagem de erro:

#1071 - Specified key was too long; max key length is 767 bytes

Informações sobre a coluna1 e a coluna2:

column1 varchar(20) utf8_general_ci
column2  varchar(500) utf8_general_ci

Eu acho que varchar(20)requer apenas 21 bytes, enquanto varchar(500)requer apenas 501 bytes. Portanto, o total de bytes é 522, menor que 767. Então, por que recebi a mensagem de erro?

#1071 - Specified key was too long; max key length is 767 bytes

767 bytes é a limitação de prefixo declarada para tabelas InnoDB no MySQL versão 5.6 (e versões anteriores). Tem 1.000 bytes de comprimento para tabelas MyISAM. No MySQL versão 5.7 e superior, esse limite foi aumentado para 3072 bytes.

Você também deve estar ciente de que, se você definir um índice em um grande campo char ou varchar codificado por utf8mb4, precisará dividir o comprimento máximo do prefixo do índice de 767 bytes (ou 3072 bytes) por 4, resultando em 191. Isso ocorre porque o comprimento máximo de um caractere utf8mb4 é de quatro bytes. Para um caractere utf8, seriam três bytes, resultando no comprimento máximo do prefixo do índice de 254.

Uma opção que você tem é apenas colocar um limite inferior nos seus campos VARCHAR.

Outra opção (de acordo com a resposta a esse problema ) é obter o subconjunto da coluna em vez de todo o valor, ou seja:

ALTER TABLE `mytable` ADD UNIQUE ( column1(15), column2(200) );

Ajuste conforme você precisa obter a chave para aplicar, mas me pergunto se valeria a pena revisar seu modelo de dados em relação a essa entidade para ver se há melhorias que permitam implementar as regras de negócios pretendidas sem atingir a limitação do MySQL.

Se alguém estiver tendo problemas com o INNODB / Utf-8 tentando colocar um UNIQUEíndice em um VARCHAR(256)campo, mude para VARCHAR(255). Parece 255 é a limitação.

Quando você atinge o limite. Defina o seguinte.

• INNODB utf8 VARCHAR(255)
• INNODB utf8mb4 VARCHAR(191)

O MySQL assume o pior caso para o número de bytes por caractere na string. Para a codificação 'utf8' do MySQL, são 3 bytes por caractere, uma vez que essa codificação não permite caracteres além U+FFFF. Para a codificação 'utf8mb4' do MySQL, são 4 bytes por caractere, já que é o que o MySQL chama de UTF-8 real.

Então, supondo que você esteja usando 'utf8', sua primeira coluna receberá 60 bytes do índice e a segunda, 1500.

execute esta consulta antes da sua consulta:

SET @@global.innodb_large_prefix = 1;

isso aumentará o limite para 3072 bytes.

Solução para o Laravel Framework

Conforme a documentação do Laravel 5.4. * ; Você deve definir o comprimento padrão da string dentro do bootmétodo do app/Providers/AppServiceProvider.phparquivo da seguinte maneira:

use Illuminate\Support\Facades\Schema;

public function boot() 
{
    Schema::defaultStringLength(191); 
}

Explicação dessa correção, fornecida pela documentação do Laravel 5.4. * :

O Laravel usa o utf8mb4conjunto de caracteres por padrão, que inclui suporte para armazenar "emojis" no banco de dados. Se você estiver executando uma versão do MySQL mais antiga que a versão 5.7.7 ou MariaDB mais antiga que a versão 10.2.2, pode ser necessário configurar manualmente o comprimento padrão da sequência gerada pelas migrações para que o MySQL crie índices para elas. Você pode configurar isso chamando o Schema::defaultStringLengthmétodo dentro do seu AppServiceProvider.

Como alternativa, você pode ativar a innodb_large_prefixopção para o seu banco de dados. Consulte a documentação do seu banco de dados para obter instruções sobre como ativar corretamente esta opção.

Qual codificação de caracteres você está usando? Alguns conjuntos de caracteres (como UTF-16 etc.) usam mais de um byte por caractere.

Acho varchar (20) requer apenas 21 bytes enquanto varchar (500) requer apenas 501 bytes. Portanto, o total de bytes é 522, menor que 767. Então, por que recebi a mensagem de erro?

O UTF8 requer 3 bytes por caractere para armazenar a sequência, portanto, no seu caso, 20 + 500 caracteres = 20 * 3 + 500 * 3 = 1560 bytes, que são mais do que permitidos 767 bytes.

O limite para UTF8 é 767/3 = 255 caracteres , para UTF8mb4, que usa 4 bytes por caractere, é 767/4 = 191 caracteres.

Existem duas soluções para esse problema se você precisar usar uma coluna mais longa que o limite:

1. Use codificação "mais barata" (aquela que requer menos bytes por caractere).
   No meu caso, eu precisei adicionar um índice Exclusivo na coluna que contém a sequência de caracteres de artigo SEO, como eu uso apenas [A-z0-9\-]caracteres para SEO, usei latin1_general_cique usa apenas um byte por caractere e assim a coluna pode ter 767 bytes de comprimento.
2. Crie um hash a partir da sua coluna e use apenas um índice exclusivo.
   A outra opção para mim era criar outra coluna que armazenasse o hash do SEO. Essa coluna teria a UNIQUEchave para garantir que os valores do SEO sejam únicos. Eu também adicionaria um KEYíndice à coluna SEO original para acelerar a pesquisa.

A resposta sobre por que você recebe a mensagem de erro já foi respondida por muitos usuários aqui. Minha resposta é sobre como consertar e usá-lo como está.

Consulte a partir deste link .

1. Abra o cliente MySQL (ou cliente MariaDB). É uma ferramenta de linha de comando.
2. Ele pedirá sua senha, digite sua senha correta.
3. Selecione seu banco de dados usando este comando use my_database_name;

Banco de dados alterado

4. set global innodb_large_prefix=on;

Consulta OK, 0 linhas afetadas (0,00 s)

5. set global innodb_file_format=Barracuda;

Consulta OK, 0 linhas afetadas (0,02 s)

6. Vá para o seu banco de dados no phpMyAdmin ou algo parecido para facilitar o gerenciamento. > Selecione banco de dados> Visualizar estrutura da tabela > Vá para a guia Operações . > Altere ROW_FORMAT para DYNAMIC e salve as alterações.
7. Vá para a guia estrutura da tabela > clique no botão Exclusivo .
8. Feito. Agora não deve ter erros.

O problema dessa correção é se você exportar db para outro servidor (por exemplo, de host local para host real) e não puder usar a linha de comando do MySQL nesse servidor. Você não pode fazê-lo funcionar lá.

Specified key was too long; max key length is 767 bytes

Você recebeu essa mensagem porque 1 byte é igual a 1 caractere apenas se você usar o latin-1conjunto de caracteres. Se você usar utf8, cada caractere será considerado 3 bytes ao definir sua coluna-chave. Se você usar utf8mb4, cada caractere será considerado com 4 bytes ao definir sua coluna-chave. Portanto, você precisa multiplicar o limite de caracteres do campo-chave por 1, 3 ou 4 (no meu exemplo) para determinar o número de bytes que o campo-chave está tentando permitir. Se você estiver usando uft8mb4, poderá definir apenas 191 caracteres para um campo de chave primária nativo InnoDB. Apenas não viole 767 bytes.

Substitua utf8mb4por utf8no seu arquivo de importação.

você pode adicionar uma coluna do md5 de colunas longas

Encontramos esse problema ao tentar adicionar um índice UNIQUE a um campo VARCHAR (255) usando utf8mb4. Embora o problema já esteja bem delineado aqui, eu gostaria de acrescentar alguns conselhos práticos sobre como descobrimos e resolvemos isso.

Ao usar utf8mb4, os caracteres contam como 4 bytes, enquanto em utf8, eles podem ter 3 bytes. Os bancos de dados do InnoDB têm um limite que os índices podem conter apenas 767 bytes. Portanto, ao usar utf8, você pode armazenar 255 caracteres (767/3 = 255), mas usando utf8mb4, você pode armazenar apenas 191 caracteres (767/4 = 191).

Você é absolutamente capaz de adicionar índices regulares para VARCHAR(255)campos usando utf8mb4, mas o que acontece é que o tamanho do índice é truncado automaticamente em 191 caracteres - como unique_keyaqui:

Isso é bom, porque índices regulares são usados ​​apenas para ajudar o MySQL a pesquisar seus dados mais rapidamente. O campo inteiro não precisa ser indexado.

Então, por que o MySQL trunca o índice automaticamente para índices regulares, mas gera um erro explícito ao tentar fazer isso para índices exclusivos? Bem, para que o MySQL possa descobrir se o valor que está sendo inserido ou atualizado já existe, ele precisa indexar todo o valor e não apenas parte dele.

No final do dia, se você deseja ter um índice exclusivo em um campo, todo o conteúdo do campo deve caber no índice. Para utf8mb4, isso significa reduzir o comprimento do campo VARCHAR para 191 caracteres ou menos. Se você não precisar de utf8mb4 para essa tabela ou campo, poderá devolvê-lo ao utf8 e poder manter seus 255 campos de comprimento.

Aqui está a minha resposta original:

Acabei de largar o banco de dados e recriar assim, e o erro se foi:

drop database if exists rhodes; create database rhodes default CHARACTER set utf8 default COLLATE utf8_general_ci;

No entanto, não funciona para todos os casos.

Na verdade, é um problema usar índices nas colunas VARCHAR com o conjunto de caracteres utf8(ou utf8mb4), com colunas VARCHAR que possuem mais de um determinado comprimento de caracteres. No caso de utf8mb4, esse determinado comprimento é 191.

Consulte a seção Índice longo neste artigo para obter mais informações sobre como usar índices longos no banco de dados MySQL: http://hanoian.com/content/index.php/24-automate-the-converting-a-mysql-database- conjunto de caracteres para utf8mb4

5 soluções alternativas:

O limite foi aumentado em 5.7.7 (MariaDB 10.2.2?). E pode ser aumentado com algum trabalho em 5.6 (10.1).

Se você estiver atingindo o limite por tentar usar o CHARACTER SET utf8mb4. Em seguida, siga um destes procedimentos (cada um tem uma desvantagem) para evitar o erro:

⚈  Upgrade to 5.7.7 for 3072 byte limit -- your cloud may not provide this;
⚈  Change 255 to 191 on the VARCHAR -- you lose any values longer than 191 characters (unlikely?);
⚈  ALTER .. CONVERT TO utf8 -- you lose Emoji and some of Chinese;
⚈  Use a "prefix" index -- you lose some of the performance benefits.
⚈  Or... Stay with older version but perform 4 steps to raise the limit to 3072 bytes:

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=1;
SET GLOBAL innodb_large_prefix=1;
logout & login (to get the global values);
ALTER TABLE tbl ROW_FORMAT=DYNAMIC;  -- (or COMPRESSED)

- http://mysql.rjweb.org/doc.php/limits#767_limit_in_innodb_indexes

Corrigi esse problema com:

varchar(200) 

substituído por

varchar(191)

todo o varchar que tem mais de 200 substitui-os por 191 ou os define como texto.

Eu fiz alguma pesquisa sobre este tópico, finalmente recebi algumas alterações personalizadas

Para o MySQL workbench 6.3.7 Versão está disponível uma fase gráfica

1. Inicie o Workbench e selecione a conexão.
2. Vá para gerenciamento ou Instância e selecione Arquivo de opções.
3. Se o Workbench solicitar permissão para ler o arquivo de configuração e permitir, pressione OK duas vezes.
4. No centro, aparece a janela do arquivo de opções do administrador.
5. Vá para a guia InnoDB e verifique o innodb_large_prefix, se não estiver marcado na seção Geral.
6. defina o valor da opção innodb_default_row_format como DYNAMIC.

Para as versões abaixo da 6.3.7, as opções diretas não estão disponíveis, portanto, é necessário ir com o prompt de comando

1. Inicie o CMD como administrador.
2. Ir para o diretório em que o servidor mysql está instalado A maioria dos casos está em "C: \ Arquivos de Programas \ MySQL \ MySQL Server 5.7 \ bin", então o comando é "cd \" "cd Arquivos de Programas \ MySQL \ MySQL Server 5.7 \ bin".
3. Agora execute o comando mysql -u userName -p databasescheema Agora ele pediu a senha do respectivo usuário. Forneça a senha e entre no prompt do mysql.
4. Temos que definir algumas configurações globais, digite os comandos abaixo, um por um, definir global innodb_large_prefix = on; definir global innodb_file_format = barracuda; definir global innodb_file_per_table = true;
5. Agora, finalmente, temos que alterar o ROW_FORMAT da tabela necessária, por padrão, seu COMPACT, temos que configurá-lo para DYNAMIC.
6. use o seguinte comando alter table table_name ROW_FORMAT = DYNAMIC;
7. Feito

Para laravel 5.7 a 6.0

Passos a seguir

1. Vá para App\Providers\AppServiceProvider.php.
2. Adicione isso ao provedor use Illuminate\Support\Facades\Schema;no topo.
3. Dentro da função de inicialização Schema::defaultStringLength(191);

isso tudo, aproveite.

mude seu agrupamento. Você pode usar utf8_general_ci que suporta quase todos

Apenas mudar utf8mb4para a utf8criação de tabelas resolveu meu problema. Por exemplo: CREATE TABLE ... DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci;para CREATE TABLE ... DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci;.

Para consertar isso, isso funciona para mim como um encanto.

ALTER DATABASE dbname CHARACTER SET utf8 COLLATE utf8_general_ci;

Com base na coluna fornecida abaixo, essas duas colunas de sequência variável estão usando utf8_general_ciagrupamento ( utf8charset está implícito).

No MySQL, utf8charset usa no máximo 3 bytes para cada caractere. Portanto, seria necessário alocar 500 * 3 = 1500 bytes, o que é muito maior do que os 767 bytes permitidos pelo MySQL. É por isso que você está recebendo esse erro 1071.

Em outras palavras, você precisa calcular a contagem de caracteres com base na representação de bytes do conjunto de caracteres, pois nem todo conjunto de caracteres é uma representação de byte único (como você presumiu.) O IE utf8no MySQL usa no máximo 3 bytes por caractere, 767 / 3≈255 caracteres e, para utf8mb4, no máximo, uma representação de 4 bytes, 767/4 × 191 caracteres.

Também é sabido que o MySQL

column1 varchar(20) utf8_general_ci
column2  varchar(500) utf8_general_ci

Achei esta consulta útil para detectar quais colunas tinham um índice que viola o comprimento máximo:

SELECT
  c.TABLE_NAME As TableName,
  c.COLUMN_NAME AS ColumnName,
  c.DATA_TYPE AS DataType,
  c.CHARACTER_MAXIMUM_LENGTH AS ColumnLength,
  s.INDEX_NAME AS IndexName
FROM information_schema.COLUMNS AS c
INNER JOIN information_schema.statistics AS s
  ON s.table_name = c.TABLE_NAME
 AND s.COLUMN_NAME = c.COLUMN_NAME 
WHERE c.TABLE_SCHEMA = DATABASE()
  AND c.CHARACTER_MAXIMUM_LENGTH > 191 
  AND c.DATA_TYPE IN ('char', 'varchar', 'text')

Por favor, verifique se sql_modeé como

sql_mode=NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES

se for, mude para

sql_mode=NO_ENGINE_SUBSTITUTION

OU

reinicie o servidor alterando o arquivo my.cnf (colocando a seguir)

innodb_large_prefix=on

No meu caso, tive esse problema ao fazer backup de um banco de dados usando os caracteres de saída / entrada de redirecionamento do linux. Portanto, altero a sintaxe conforme descrito abaixo. PS: usando um terminal linux ou mac.

Backup (sem o> redirecionamento)

# mysqldump -u root -p databasename -r bkp.sql

Restaurar (sem o <redirecionamento)

# mysql -u root -p --default-character-set=utf8 databasename
mysql> SET names 'utf8'
mysql> SOURCE bkp.sql

O erro "Chave especificada era muito longa; o comprimento máximo da chave é 767 bytes" simples desapareceu.

Comprimentos de índice e MySQL / MariaDB

O Laravel usa o conjunto de caracteres utf8mb4 por padrão, que inclui suporte para armazenar "emojis" no banco de dados. Se você estiver executando uma versão do MySQL mais antiga que a versão 5.7.7 ou MariaDB mais antiga que a versão 10.2.2, pode ser necessário configurar manualmente o comprimento padrão da sequência gerada pelas migrações para que o MySQL crie índices para elas. Você pode configurar isso chamando o método Schema :: defaultStringLength em seu AppServiceProvider:

use Illuminate\Support\Facades\Schema;

/**
 * Bootstrap any application services.
 *
 * @return void
 */
public function boot()
{
    Schema::defaultStringLength(191);
}

Como alternativa, você pode ativar a opção innodb_large_prefix para o seu banco de dados. Consulte a documentação do seu banco de dados para obter instruções sobre como ativar corretamente esta opção.

Referência do blog: https://www.scratchcode.io/specified-key-too-long-error-in-laravel/

Referência da documentação oficial do laravel: https://laravel.com/docs/5.7/migrations

Se você estiver criando algo como:

CREATE TABLE IF NOT EXISTS your_table (
  id int(7) UNSIGNED NOT NULL AUTO_INCREMENT,
  name varchar(256) COLLATE utf8mb4_bin NOT NULL,
  PRIMARY KEY (id),
  UNIQUE KEY name (name)
) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=1 ROW_FORMAT=FIXED;

deveria ser algo como

CREATE TABLE IF NOT EXISTS your_table (
      id int(7) UNSIGNED NOT NULL AUTO_INCREMENT,
      name varchar(256) COLLATE utf8mb4_bin NOT NULL,
      PRIMARY KEY (id)
    ) ENGINE=INNODB DEFAULT CHARSET=utf8mb4 AUTO_INCREMENT=1 ROW_FORMAT=FIXED;

mas você precisa verificar a exclusividade dessa coluna a partir do código ou adicionar uma nova coluna como MD5 ou SHA1 da coluna varchar

Devido a limitações de prefixo, este erro ocorrerá. 767 bytes é a limitação de prefixo declarada para tabelas InnoDB nas versões MySQL anteriores à 5.7. Tem 1.000 bytes de comprimento para tabelas MyISAM. No MySQL versão 5.7 e superior, esse limite foi aumentado para 3072 bytes.

A execução do seguinte no serviço que fornece o erro deve resolver o problema. Isso deve ser executado na CLI MYSQL.

SET GLOBAL innodb_file_format=Barracuda;
SET GLOBAL innodb_file_per_table=on;
SET GLOBAL innodb_large_prefix=on;

Altere CHARSET do campo de índice reclamante para "latin1",
isto é, ALTER TABLE tbl CHANGE myfield myfield varchar (600) CHARACTER SET latin1 DEFAULT NULL;
latin1 leva um byte para um caractere em vez de quatro

Se você mudou innodb_log_file_sizerecentemente, tente restaurar o valor anterior que funcionou.