CREATE INDEX报“Access denied”本质是MySQL服务端权限校验失败，非phpMyAdmin限制；若含INDEX或ALTER字样则缺对应权限，若Errcode:28则是tmpdir所在分区空间耗尽。
不能创建索引，八成不是语法错，而是 MySQL 拒绝写入表空间——要么没权限，要么没空间，两者常被混为一谈，但排查路径完全不同。
为什么 CREATE INDEX 报错 “Access denied” 却和索引语法无关？
phpMyAdmin 或命令行执行 CREATE INDEX 时提示 “Access denied for user”，本质是 MySQL 服务端校验失败，不是前端限制。关键看错误信息里有没有 INDEX 或 ALTER 字样：
- 若报错含
INDEX command denied或ERROR 1142，说明用户缺少INDEX或（更常见）ALTER权限 - 若报错是
Errcode: 28 - No space left on device，则和权限无关，是磁盘或临时空间耗尽 - MySQL 5.7 及以前不支持对单表授予
INDEX权限，必须授ALTER；MariaDB 则可显式授INDEX - 主机名必须完全匹配：
'user'@'localhost'和'user'@'%'是两个独立账号，授权时别漏掉@'host'部分
怎么确认当前用户到底缺哪类权限？
用高权限账号（如 root）连上 MySQL，执行：
SHOW GRANTS FOR 'your_user'@'host';
重点检查输出中是否含：
-
GRANT ALTER ON `db_name`.`table_name`（精确到表） -
GRANT ALTER ON `db_name`.*（整个库） -
GRANT INDEX ON `db_name`.`table_name`（MariaDB 常见）
如果都没有，就需补授权。最稳妥的是：
GRANT ALTER ON `mydb`.`mytable` TO 'your_user'@'host';<br>FLUSH PRIVILEGES;
注意：反引号包裹数据库/表名，避免大小写或特殊字符引发解析错误；FLUSH PRIVILEGES 不可省，否则权限不生效。
为什么授权后还是报空间不足（Errcode: 28）？
这是典型“权限误判”——错误码 28 表示系统级写入失败，和 MySQL 用户权限完全无关。真正原因通常是：
- MySQL 临时文件目录（
tmpdir）所在分区满了。默认是/tmp（Linux）或系统临时目录（Windows），不是数据目录 - 导入大表后建索引会触发排序和临时表重建，需要等量甚至 2 倍磁盘空间
- 在 phpEnv 等 Windows 集成环境里，
ibtmp1文件可能涨到数 GB 且不自动清理 -
innodb_file_per_table = OFF时，ibdata1只增不减，删表不释放空间
查临时目录位置：
SELECT @@tmpdir;
然后用系统命令检查该路径所在分区剩余空间（Linux 用 df -h，Windows 用资源管理器看对应盘符）。
绕过界面直接执行 CREATE INDEX 的实操要点
即使权限和空间都 OK，phpMyAdmin 图形化按钮仍可能失败——它生成的语句常带冗余子句，旧版 MySQL 易因此误判。此时应手动进 SQL 页执行：
- 用最简形式：
CREATE INDEX idx_col ON mytable (col_name);，不加USING BTREE或字符集声明 - 前缀索引要合法：
CREATE INDEX idx_title ON posts (title(100));，括号内长度值不能超字段定义上限（如TEXT类型必须指定） - 避免在函数列上建索引：
CREATE INDEX idx_upname ON users (UPPER(name));在 MySQL 8.0 以下不支持，会报语法错 - 建索引期间表会被锁（尤其是
ALTER TABLE方式），线上表建议选低峰期操作
真正卡住的往往不是那条 SQL 本身，而是权限作用域写错了 host、临时目录挂载点只剩几百 MB、或者 ibtmp1 被撑爆却以为是数据目录满了——先盯住错误码和 SHOW GRANTS 输出，比反复重试快得多。
