MySQL无法创建索引主因是utf8mb4下字段长度超索引字节限制，如VARCHAR(255)需缩为email(191)；字段截断源于PHP用strlen而非mb_strlen判断字符数，且substr破坏UTF8编码边界。
phpEnv 下 MySQL 无法创建索引，通常不是 phpEnv 本身的问题，而是底层 MySQL 实例的配置、表结构或操作方式触发了限制；数据库字段长度超限则多发生在导入或插入时被静默截断，根源在列定义而非 PHP 转义。
为什么 ALTER TABLE ADD INDEX 报错或无响应
常见现象包括：执行 ALTER TABLE users ADD INDEX idx_email (email) 后卡住、超时、返回 ERROR 1071 (42000): Specified key was too long，或 EXPLAIN 显示未走索引。
- 最典型原因是
email字段为VARCHAR(255)且字符集是utf8mb4：InnoDB 单索引键最大长度为 767 字节（旧版本）或 3072 字节（MySQL 5.7+ +innodb_large_prefix=ON），而utf8mb4下 255 字符最多占 255 × 4 = 1020 字节 → 超限 - 解决方法不是“加大限制”，而是精准控制索引长度：
ALTER TABLE users ADD INDEX idx_email (email(191))—— 191 × 4 = 764 字节，安全落在 767 以内 - 若用的是 MySQL 5.6 或更低版本，还需确认
innodb_file_format = Barracuda和innodb_file_per_table = ON，否则即使设了idx_email(191)仍可能失败 - 联合索引中包含多个
VARCHAR字段时，要逐个计算字节总和，例如(name(50), email(191))在utf8mb4下最多占 (50+191) × 4 = 964 字节，仍超 767 → 必须进一步缩短
导入数据时字段被截断却不报错
现象是：CSV 或 Excel 导入后，name 字段只存了前 10 个汉字，但 PHP 没抛异常，MySQL 日志里只有 Warning: Data truncated for column 'name' at row 1。
- 根本原因不是
mysqli_real_escape_string()没用，而是字段定义为VARCHAR(10)，而 UTF8MB4 下一个汉字占 4 字节 → 实际最多存 2–3 个汉字就满 10 字节了（取决于具体字符） - PHP 层必须用
mb_strlen($value, 'UTF8')判断字符数，不能用strlen()（它算字节）；再对照SHOW COLUMNS FROM table_name LIKE 'name'获取定义长度 - 安全截断必须用
mb_substr($value, 0, $maxCharLen, 'UTF8')，否则substr()可能切在汉字中间导致乱码 - 上线前检查
extension=mbstring是否启用，PHP 7.4+ 默认开启，但某些精简版 phpEnv 可能关闭
phpEnv 中修改 MySQL 配置的实际路径
phpEnv 是 Windows 下集成环境，其 MySQL 配置文件不在标准位置，容易找错。
立即学习“PHP免费学习笔记（深入）”；
- 真实
my.ini一般位于：phpEnv\MySQL\my.ini或phpEnv\MySQL\data\my.ini（不是C:\Windows\my.ini） - 关键参数需同时改两处：在
[mysqld]段下加innodb_large_prefix = ON和innodb_file_format = Barracuda；在[client]段确保default-character-set = utf8mb4 - 改完必须重启 MySQL 服务（通过 phpEnv 控制面板点“重启 MySQL”），仅重启 Apache 无效
- 验证是否生效：
mysql -u root -p -e "SHOW VARIABLES LIKE 'innodb_large_prefix';"，返回ON才算成功
真正卡住人的地方，往往不是不会写 CREATE INDEX，而是没意识到 utf8mb4 字段长度和索引字节限制之间存在隐式换算关系；也不是没做截断，而是用了 substr 破坏了 UTF8 编码边界。这些细节在本地小数据时完全不暴露，一到生产环境就突然崩掉。
