MySQL Error: Index column size too large. The maximum column size is 767 bytes

Question

I've unsuccessfully been through the AWS forum and Stack Overflow trying to find a solution to the following error: Index column size too large. The maximum column size is 767 bytes

I am running a WordPress website with 1.5M records in the postmeta table. I recently added an index to the postmeta table, and all was testing ok. However I had an incident with my server today (botnet scan dwindled my RDS credits), and restarted both my Lightsail instance and my RDS MySQL instance. After the restart I noticed that the site wasn't working properly and upon further investigation found the postmeta table was returning the error Index column size too large. The maximum column size is 767 bytes.

I'm running on MySQL 8.0.20

The table is:

    Engine = InnoDB  
    Charset = utf8mb4  
    Collation = utf8mb4_0900_ai_ci  
    Row Format = Compact  

Many existing "solutions" talk about recreating the table, however I need the data that's currently in the table. Unfortunately this issue is present in my oldest AWS RDS Snapshot, so back ups don't appear to be an option.

Every time I try run an ALTER or SELECT statement, I get the same error, Index column size too large. The maximum column size is 767 bytes. I've tried:

• Changing the ROWFORMAT=DYNAMIC
• Converting the charset and records to utf8
• Changing the meta_value column from 255 to 191
• Removing the custom index
• Dumping the table

I can see that the default ROWFORMAT is now "DYNAMIC", however this table is still "COMPACT" from when it was running on MySQL 5.7

I've also tried updating the AWS RDS MySQL from 8.0.20 to 8.0.23, however the update fails cause it reports the table is corrupt in PrePatchCompatibility.log.
Ref: https://dba.stackexchange.com/questions/234822/mysql-error-seems-unfixable-index-column-size-too-large#answer-283266

There are some other suggestions about modifying the environment and file system, and running "innodb_force_recovery".
https://dba.stackexchange.com/questions/116730/corrupted-innodb-table-mysqlcheck-and-mysqldump-crash-server
However being an RDS instance, I don't have access to this lower level of the instance.

I suspect this issue is the column length and utf8mb4, however my main priority is getting the data from the currently in the table.
I also understand that changing the ROWFORMAT to DYNAMIC should fix this issue - however getting the same error.

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

I have also tried the "RDS Export to S3" option with no luck.

Please help, I'm lost as to what else to try.

Answer 1

我遇到并解决了同样的问题。情况是这样的。

在旧版 MySQL 表格式中，VARCHAR 或 blob 列上的索引的最大大小为 767 字节（不是字符）。这些 wp_something元WordPress 表具有 VARCHAR(255) 数据类型的关键列（如 meta_key）。当 utf8mb4 是字符集时，每个字符最多可以占用 767 个字节中的四个。这意味着索引必须定义为前缀。元密钥（191）。

是什么让 MySQL 表成为遗留表？

1. MyISAM 访问方法，或
2. MySQL 的旧版本（5.5、早期 5.6）仅支持较旧的 InnoDB Antelope ondisk 表格式，而不支持较新的Barracuda文件格式，或者
3. InnoDB 和 ROW_FORMAT 是COMPACT （或REDUNDANT）。

因此，为了摆脱 varchar(255) 列上的前缀索引，该表需要是 InnoDB 并使用 DYNAMIC（或 COMPRESSED）ROW_FORMAT。

无需从头开始重建旧表。你可以通过说来转换它

ALTER TABLE whatever ENGINE=InnoDB, ROW_FORMAT=DYNAMIC;

然后您就不再遇到前缀键 (191) 问题。

在执行此类操作之前，请先备份数据库。你知道的。

并且，升级到最新版本的 MySQL 或 MariaDB。严重地。MySQL 5.6长期支持于2021年2月1日结束，新版本更好。（GoDaddy！我正在看着你。）