根本原因在于Laravel迁移自动创建索引时生成的索引名超长（>64字符）且字段默认长度过大，导致MySQL 5.6/5.7在innodb_large_prefix=OFF时触发1071错误；phpMyAdmin手动调整仅修改表结构，不修正迁移逻辑与状态，无法根治。
根本不用在 phpMyAdmin 里调——那只是临时糊弄，治标不治本，还容易让迁移状态和实际表结构脱节。
为什么 phpMyAdmin 调整解决不了 Laravel 迁移的字符集过长问题
你看到的「Specified key was too long」或「SQLSTATE[42000]: Syntax error or access violation」错误，根源不在某张表的当前状态，而在于 Laravel 迁移系统在执行 up() 时，试图为字段（比如 email）自动创建索引，而默认生成的索引名拼上表前缀后超过 MySQL 5.7 及更早版本的 64 字符限制。phpMyAdmin 里手动改表、删索引、重命名，绕过了 Laravel 的迁移逻辑，下次 php artisan migrate 或 migrate:fresh 仍会照常报错，甚至因状态不一致直接失败。
Laravel 9 迁移索引名过长的真实触发点
这个错误高频出现在以下场景：
- 执行
php artisan migrate:fresh时，Laravel 自动加载了框架内置迁移（如2019_12_14_000001_create_personal_access_tokens_table.php），它会对(tokenable_type, tokenable_id)建联合索引 - 你的 MySQL 是 5.6/5.7 且
innodb_large_prefix = OFF（阿里云 RDS 默认关） - 表名本身长（如
tenant_organization_user_permissions），加上字段名和类型前缀，index名轻松突破 64 字符
此时无论你在 phpMyAdmin 里把表改成什么样，只要没干预 Laravel 的索引命名逻辑，下一次迁移照样崩。
立即学习“PHP免费学习笔记（深入）”；
真正该动手的地方：AppServiceProvider + 显式命名
修复必须落在代码层，且要覆盖迁移执行前的全部时机：
- 在
app/Providers/AppServiceProvider.php的boot()方法中注册索引名生成器：Builder::setIndexNameGenerator(...) - 同时补上
Builder::defaultStringLength(191)，确保string()字段能建索引（utf8mb4 下 191×4=764 字节 ≤ 767 限制） - 对关键索引（尤其是联合索引或长字段）直接显式命名，例如：
$table->index(['user_id', 'status'], 'idx_usr_sts') - 删掉已失败的迁移记录（
DELETE FROM migrations WHERE migration = 'xxx'），再清缓存：php artisan config:clear && php artisan cache:clear
为什么别信“改完 phpMyAdmin 就行”这种说法
因为 Laravel 迁移不是一次性 DDL 工具，它是带状态追踪的版本控制系统。你在 phpMyAdmin 里手动操作，等于只改了「数据库快照」，但没更新 migrations 表里的记录、没同步本地迁移文件的语义、也没修正后续迁移对这张表的依赖假设。一旦团队协作、CI 流水线跑迁移、或者换服务器重部署，问题立刻复现——而且更难排查。
最易被忽略的一点：框架自动生成的迁移（比如 Sanctum、Passport 发布的）不会因为你手动删过一次索引就跳过重建。它们每次都会按原逻辑重试，直到你从命名源头把它收住。
