加索引失败主因是字段类型不匹配、外键约束异常或索引名超长；需依错误码1215/1062/“index name too long”定位，检查被引用表存在性、字段类型一致性、索引命名长度及查询条件是否匹配索引顺序。
加索引失败，八成不是语法写错，而是字段类型、约束顺序或数据库环境不匹配——先查错误信息里有没有 1215、1062 或 “index name too long”，再动手改代码。
Migration里加索引报SQLSTATE[HY000]: General error: 1215
这是外键约束失败的典型错误，和 index() 本身无关，但常被误认为“加索引失败”。根本原因是：你要加索引的字段（比如 user_id）想同时建外键，但被引用的表还没建、字段类型不一致，或被引用字段没索引。
- 检查被引用表是否存在，且主键是
id（bigIncrements）；如果不是，foreignId('user_id')就会失败 - 确认字段类型严格一致：
users.id是bigIncrements→posts.user_id必须是unsignedBigInteger，不能是integer或漏掉unsigned - 如果被引用字段（如
users.id）本身没索引（极少见），先确保它有主键 —— 主键自动建索引，否则外键无法创建 - SQLite 用户记得在
AppServiceProvider::boot()里加DB::statement('PRAGMA foreign_keys = ON');
Migration执行时提示“index name too long”或报错42000
MySQL 5.7 以下版本（尤其是阿里云 RDS 默认配置或老部署环境）对索引名长度限制为 64 字符，而 Laravel 默认生成的索引名（如 tenant_organization_user_permissions_email_verified_at_index）很容易超长。
- 别去改 MySQL 配置（
innodb_large_prefix很多环境不可控），直接在App\Providers\AppServiceProvider::boot()里重写命名逻辑 - 必须在所有迁移运行前注册：
Builder::setIndexNameGenerator(...)，否则已存在的迁移不会生效 - 更稳妥的做法是显式命名：
$table->index('email', 'idx_users_email')，联合索引同理：$table->index(['user_id', 'status'], 'idx_orders_user_status') - 删除时也得用对应名字：
$table->dropIndex('idx_users_email')，别依赖dropUnique()这类自动拼名的方法
加了index()但查询还是慢，EXPLAIN 显示没走索引
索引建了≠被用上。MySQL 是否使用索引，取决于查询条件、字段可空性、复合索引顺序等，和迁移写法无关。
- 检查 WHERE 条件是否匹配索引字段顺序：联合索引
['user_id', 'status']能加速WHERE user_id = ? AND status = ?，但WHERE status = ?单独用就无效 - 避免在大量为
NULL的字段上建索引（如deleted_at未软删除时全为 NULL），MySQL 可能跳过 - 字符串字段（如
name）建索引前确认长度：string('name', 191)->index()，否则 MySQL 默认只索引前 768 字节，可能失效 - 用
DB::select('EXPLAIN SELECT * FROM orders WHERE user_id = 123 AND status = "paid"')查key列是否命中你建的索引名，rows是否显著减少
已有数据的表加unique()失败，报1062 Duplicate entry
unique 约束要求全表无重复值，Laravel 迁移执行时会触发 MySQL 全表校验，不是“加个索引而已”。
- 先查重复：
SELECT email, COUNT(*) FROM users GROUP BY email HAVING COUNT(*) > 1 - 清理后再迁移，别用
SET FOREIGN_KEY_CHECKS=0临时绕过 —— 它不解决数据一致性问题 - 软删除场景下，
email唯一性需扩展为['email', 'deleted_at']联合唯一，否则已删除用户邮箱还能被复用 - 记住：
unique()是约束+索引，index()只是索引 —— 想防重复插入，必须用unique()，且字段应设NOT NULL（MySQL 对 NULL 值允许多个，唯一性失效）
最易被忽略的一点：本地开发用 MySQL 8，生产用 MySQL 5.6，哪怕迁移文件一字不差，索引名长度、fulltext 支持、甚至外键行为都可能不同。上线前务必在镜像环境中验证迁移全流程，而不是只看 php artisan migrate 是否输出 success。
