结论是：Laravel 5.7+ 默认 utf8mb4 下 string('email')->unique() 因 255 长度超 MySQL 索引字节限制（767 字节）而报错，应改为 string('email', 191)->unique()；全局方案是在 AppServiceProvider::boot() 中调用 Schema::defaultStringLength(191)（仅适用于 Laravel ≤ 8.x），Laravel 9+ 必须显式声明长度。
直接说结论：这不是 phpmyadmin 的问题，而是 laravel 5.7+ 默认使用 utf8mb4 字符集后，mysql 旧版本（
为什么在 phpMyAdmin 里看到 “Specified key was too long” 错误？
当你在 phpMyAdmin 中执行 Laravel 迁移 SQL（比如 CREATE TABLE 或 ALTER TABLE ADD INDEX），遇到类似 SQLSTATE[HY000]: General error: 1071 Specified key was too long; max key length is 767 bytes，本质是 MySQL 对单个索引字段的字节长度有限制：
- InnoDB 表默认最大索引长度为 767 字节（MySQL innodb_large_prefix=ON）
- Laravel 5.7+ 默认启用
utf8mb4字符集，一个字符最多占 4 字节 - 所以
VARCHAR(191)→ 191 × 4 = 764 字节，刚好卡在安全线；而VARCHAR(255)→ 1020 字节 → 超限 - phpMyAdmin 只是把 MySQL 报的这个底层限制原样显示出来，它本身不参与索引长度计算
如何快速修复迁移文件中的索引长度问题？
最稳妥、无需改服务器配置的方式：在 Laravel 迁移中显式缩短字符串字段的长度，并指定索引长度。常见于 string() 字段加 index() 时：
- 不要写：
$table->string('email')->unique();（默认 255，utf8mb4 下超限） - 改成：
$table->string('email', 191)->unique(); - 对已有迁移，可在
up()中补全长度：$table->index('title', 'posts_title_index');→ 改为$table->index('title', 'posts_title_index')->length(191);（Laravel 9+ 支持，低版本需用DB::statement()手动建索引） - 全局方案：在
AppServiceProvider::boot()中调用Schema::defaultStringLength(191);（仅适用于 Laravel ≤ 8.x；Laravel 9+ 已移除该方法，必须显式声明长度）
能否通过 phpMyAdmin 手动绕过并建索引？
可以临时试，但不推荐用于 Laravel 项目维护：
- 在 phpMyAdmin 的“SQL”标签页中，手动执行：
ALTER TABLE users ADD INDEX idx_email (email(191)); - 但下次运行
php artisan migrate:refresh仍会失败，因为迁移文件没改 - 若强行在 phpMyAdmin 中删掉报错语句再粘贴修改后的 SQL，容易漏掉外键、时间戳等依赖逻辑，导致迁移状态和数据库实际结构不一致
- 更危险的是：有人尝试在 phpMyAdmin 里改表字符集为
utf8（3 字节），虽能绕过长度限制，但会丢失 emoji、生僻汉字支持，且与 Laravel 默认配置冲突
什么时候必须改 MySQL 配置而不是改代码？
只在以下情况才考虑调整 MySQL（通常由运维操作，开发不应强求）：
立即学习“PHP免费学习笔记（深入）”；
- 你无法修改迁移文件（如维护遗留 Laravel 5.5 项目，且不允许升级）
- MySQL 版本 ≥ 5.7.7，但
innodb_file_format不是Barracuda，或innodb_file_per_table关闭 → 导致innodb_large_prefix实际不生效 - 需要支持完整
VARCHAR(255)索引（例如全文检索字段），且确认所有表都用ROW_FORMAT=DYNAMIC - 对应配置项（需重启 MySQL）：
innodb_file_format = Barracuda、innodb_file_per_table = ON、innodb_large_prefix = ON、innodb_default_row_format = dynamic
真正卡住人的地方，往往不是不会改代码，而是改完迁移后忘了清空 migrations 表里的失败记录，或者没跑 php artisan migrate:fresh 重来——phpMyAdmin 里看到的错误，永远只是 MySQL 给的最后一张“病危通知单”，病根在迁移定义和数据库能力的错配上。
