Laravel 会自动生成索引名，规则为 table_name_column_name_index（如 users_email_index）；字段过长或联合索引时截断加哈希后缀，导致不可读、难维护、回滚风险高。
迁移里不显式指定索引名，Laravel 会自动生成什么？
Laravel 默认用 table_name_column_name_index 拼接规则生成索引名，比如在 users 表给 email 字段加唯一索引，会得到 users_email_unique；普通索引则是 users_email_index。
问题在于：字段名过长、多字段联合索引、或表名含下划线时，Laravel 会截断并加哈希后缀（如 posts_category_id_status_index_3a7b2c），导致名字不可读、难排查、上线后 rename 或 drop 时容易写错。
- 联合索引字段顺序变化 → 自动生成的哈希值不同 → 实际建了两个索引，浪费空间
- MySQL 5.7+ 对索引名长度限制为 64 字符，Laravel 截断逻辑不透明，可能触发
Identifier name 'xxx' is too long -
php artisan migrate:rollback依赖索引名反向操作，名字不稳定 = 回滚失败风险
如何在 Schema 构建时强制指定索引名？
所有 index()、unique()、primary()、foreign() 方法都支持第二个参数传入自定义名称，必须是字符串，且不能含空格或特殊符号（MySQL 要求）。
推荐命名格式：prefix_table_columns_type，例如：idx_users_email（普通索引）、uidx_posts_slug（唯一索引）、fk_posts_user_id（外键索引）。
- 前缀统一用
idx/uidx/fk，一眼区分类型 - 表名用单数（
user而非users），避免和 Laravel 默认复数逻辑混淆 - 多字段联合索引按实际查询顺序列字段，用下划线连接，如
idx_orders_status_created_at - 外键索引名必须和约束名一致（否则
dropForeign()找不到），即foreign('user_id')->references('id')->on('users')->onDelete('cascade')配套用foreign('fk_orders_user_id')
示例：
Schema::create('posts', function (Blueprint $table) {
$table->id();
$table->string('slug');
$table->unsignedBigInteger('user_id');
$table->string('status')->default('draft');
$table->timestamps();
$table->unique('slug', 'uidx_posts_slug'); // ← 显式命名
$table->index(['status', 'created_at'], 'idx_posts_status_created_at'); // ← 联合索引名
$table->foreign('user_id', 'fk_posts_user_id')->references('id')->on('users'); // ← 外键索引名
});
已存在的迁移怎么补索引名？
不能直接改旧迁移文件再重跑 —— php artisan migrate 不会重新执行已记录的迁移。正确做法是新建迁移，用 Schema::table() + dropIndex() / dropUnique() 先删默认名索引，再用新名字重建。
但注意：MySQL 不允许在一条语句中先删后建同名索引（会报错），必须分两步，且中间不能有其他写操作（否则可能短暂无索引）。
- 先查当前索引名：
SHOW INDEX FROM posts;，确认是posts_slug_unique这类默认名 - 新建迁移，
up()中先$table->dropUnique('posts_slug_unique');，再$table->unique('slug', 'uidx_posts_slug'); -
down()要反向操作：先删新名索引，再用默认名重建（保持兼容性） - 生产环境务必在低峰期操作，并确认该索引无正在使用的查询依赖（如唯一校验）
索引名不规范会导致哪些部署/协作问题？
最常踩的坑不是建不起来，而是“看起来建了，其实没生效”——比如在 MySQL 8.0+ 上，索引名重复不会报错，而是静默跳过；或者团队成员本地用 SQLite 测试，它根本不校验索引名长度，上线 MySQL 就炸。
- Docker 环境里 MySQL 版本和本地不一致，
index()生成规则微调（如 5.7 vs 8.0 对哈希截断策略不同） - DBA 审核 SQL 时只认标准命名，看到
users_email_index_abc123直接打回 - 使用
schema:dump导出结构时，未命名索引会被转成随机字符串，无法版本控制 - 第三方工具（如 Laravel Telescope、Sentry 查询监控）按索引名聚合慢查询，名字混乱 = 监控失效
真正麻烦的从来不是“怎么起名”，而是“什么时候起、谁负责起、起完怎么验证”。只要第一次建表迁移就定好规则，后面基本不用操心 —— 但漏掉那一次，后续就得靠人肉 grep 和 SHOW INDEX 去救火。
