MySQL索引名实际限制为64字符，超长会导致CREATE INDEX失败；InnoDB按字节截断（utf8mb4下更严），云数据库常额外压至55–60字符；命名应控制在32字符内并统一小写下划线格式。
MySQL索引名本身没有硬编码的长度上限，但过长会触发底层文件系统或元数据管理的隐式限制，导致 CREATE INDEX 或 ALTER TABLE 失败。
索引名实际被截断的边界在哪
MySQL 将索引名写入数据字典（INFORMATION_SCHEMA.STATISTICS）和存储引擎的元数据文件中。InnoDB 会把索引名作为标识符存入系统表空间或独立表空间的内部结构里，而这些结构依赖操作系统对文件名、路径、内存结构体字段的约束。
常见表现是：你定义了长度为 65 字符的索引名，执行成功；但定义 72 字符时，报错 ERROR 1059 (42000): Identifier name '...' is too long。
- MySQL 5.7 默认最大标识符长度为
64字符（含下划线、数字、字母），这个值由编译时宏NAME_LEN控制，对应内部结构体字段大小 - InnoDB 表空间元数据中，索引名字段实际只预留了
64字节（不是字符），在 utf8mb4 下若含非 ASCII 字符可能更早截断 - 某些云数据库（如阿里云 RDS、腾讯云 CDB）会在代理层额外校验，把上限压到
60或55字符以预留扩展位
为什么不是所有长索引名都报错
是否报错取决于索引名是否参与了「物理文件生成」环节。例如：
- 普通 B+Tree 索引名只存于数据字典，走的是内存/系统表校验路径，受
64字符限制 - 全文索引（
FULLTEXT）在 InnoDB 中会生成额外的辅助表（如fts_XXX_0000000000000001_index），此时索引名会被拼接到文件名中——Linux ext4 对单个文件名限制是255字节，但 MySQL 内部拼接逻辑会先截断再加后缀，所以原始索引名超过50字符就容易出问题 - 分区表的局部索引名，还会被嵌入到分区元数据字符串中，进一步压缩可用长度
命名过长引发的连锁问题
索引名超长不只是建不起来，它会影响后续所有依赖该名称的操作：
-
DROP INDEX语句必须用原名，一旦被截断，你根本不知道数据库里存的是哪个缩写版本（比如idx_user_profile_extra_info_created_at_v2可能变成idx_user_profile_extra_info_crea） - 备份恢复工具（如
mysqldump --no-create-info+mysqlpump）在解析 DDL 时可能因名称不匹配跳过索引重建 - 监控系统（如 Prometheus + mysqld_exporter）采集
information_schema时，若索引名含不可见字符或截断乱码，会导致指标标签异常甚至崩溃 - ORM 框架（如 Django 的
db_table、Hibernate 的@Index）生成迁移脚本时，若未显式指定name，默认生成的长名极易撞上限
安全又清晰的命名实践
别靠试错去逼近 64 这个数字。直接按以下规则控制：
- 统一前缀 + 业务缩写 + 字段简写，例如：
uk_user_email、idx_order_status_ctime，全部控制在32字符以内 - 避免使用驼峰（
userEmailIndex），全小写+下划线更稳定，也方便 shell 脚本或 CI/CD 工具处理 - 联合索引不要堆字段名，用语义化缩写代替：比如
(tenant_id, status, created_at)→idx_tenant_status_ctime，而非idx_tenant_id_status_created_at - 上线前用
SELECT index_name FROM information_schema.statistics WHERE table_name = 'xxx' AND table_schema = 'yyy';核查真实入库名，确认没被截断
真正麻烦的从来不是“能不能起长名”，而是长名一旦入库，就卡在元数据里动弹不得——删不掉、改不了、导不出，比索引本身还难清理。
