row_format=dynamic能突破767字节限制，根本原因在于它是启用innodb_large_prefix的必要条件：仅当行格式为dynamic（或compressed）且innodb_large_prefix=on时，innodb才允许将单列索引上限从767字节提升至3072字节；compact/redundant格式下该参数无效，强制执行767硬限制。
MySQL 5.7 默认仍报 “Specified key was too long; max key length is 767 bytes” 错误，不是因为版本新就自动解除限制，而是因为表的 ROW_FORMAT 仍是 COMPACT（5.7 默认建表格式虽为 DYNAMIC，但旧表或显式指定时仍可能沿用旧格式）。
为什么 ROW_FORMAT=DYNAMIC 能突破 767 字节限制？
根本原因不在行格式本身，而在于 DYNAMIC 是启用 innodb_large_prefix 的必要条件之一。InnoDB 在 COMPACT 或 REDUNDANT 格式下，强制使用 767 字节硬上限；只有在 DYNAMIC（或 COMPRESSED）格式下，才允许将索引键长度上限提升至 3072 字节——前提是 innodb_large_prefix 已开启（5.7 默认为 ON）。
简单说：DYNAMIC 不是“直接放宽限制”，而是“解锁了放宽限制的通道”。没它，连门都打不开。
检查并确认当前表是否真用了 DYNAMIC
别只看 MySQL 版本或建表语句里有没有写 ROW_FORMAT=DYNAMIC，实际生效要看表元数据：
-
SHOW CREATE TABLE your_table;—— 查看输出中是否含ROW_FORMAT=DYNAMIC SELECT ROW_FORMAT FROM INFORMATION_SCHEMA.TABLES WHERE TABLE_NAME = 'your_table' AND TABLE_SCHEMA = 'your_db';- 即使建表时写了
ROW_FORMAT=DYNAMIC，若innodb_file_format未设为BARRACUDA（5.6 必须手动设，5.7+ 默认），该设置也可能被忽略
如何安全地把现有表切到 DYNAMIC 并启用长索引
对已有表执行以下三步（缺一不可）：
- 确保全局参数已就绪：
SHOW VARIABLES LIKE 'innodb_large_prefix';应返回ON（5.7 默认）；SHOW VARIABLES LIKE 'innodb_file_per_table';必须为ON（否则无法用DYNAMIC） - 修改表格式：
ALTER TABLE your_table ROW_FORMAT=DYNAMIC;—— 这会重建表，注意锁表现象 - 再加索引：
ALTER TABLE your_table ADD INDEX idx_long_col (long_varchar_col);—— 此时若字段为VARCHAR(255)+utf8mb4，理论长度 1020 字节，已可成功
⚠️ 注意：如果原表是 COMPACT 格式且未启用 innodb_file_per_table，ALTER TABLE ... ROW_FORMAT=DYNAMIC 会静默失败或回退为 COMPACT，务必先验证参数。
ALTER TABLE ... ROW_FORMAT=DYNAMIC 后还是报 767 错？常见漏点
最容易被忽略的三个点：
-
innodb_file_per_table是OFF：这是硬性前提，DYNAMIC行格式要求每个表单独存为一个.ibd文件，OFF时所有表共享系统表空间，不支持DYNAMIC - 表上有
FULLTEXT索引：InnoDB 的FULLTEXT索引会强制锁定行格式为COMPACT，即使你 ALTER 也无效 - MySQL 5.7.6 之前版本：虽然 5.7 默认开启
innodb_large_prefix，但在5.7.6之前的子版本中，部分构建可能仍默认关闭，需显式SET GLOBAL innodb_large_prefix = ON;
真正起作用的从来不是“改个格式”这么轻巧——它是参数、格式、建表方式、甚至已有索引类型共同咬合的结果。一个环节松动，整个链路就卡在 767 字节不动。
