MySQL中控制创建和删除索引的权限是INDEX权限，而非ALTER或CREATE；ALTER仅允许修改表结构（如增删列），而INDEX权限专门管控CREATE INDEX、DROP INDEX及ALTER TABLE ... ADD/DROP INDEX操作，二者必须显式分开授予。
MySQL 中控制用户创建和删除索引的权限，靠的是 INDEX 权限，不是 CREATE 或 ALTER —— 这点容易搞错。
为什么单独授予 INDEX 权限而不是用 ALTER
很多人以为只要给 ALTER 就能建/删索引，其实不对：ALTER 允许改表结构（比如加列、改类型），但建/删索引是独立操作，MySQL 专门用 INDEX 权限控制。如果只给 ALTER 不给 INDEX，用户执行 CREATE INDEX 或 DROP INDEX 会报错：ERROR 1142 (42000): INDEX command denied to user。
-
INDEX权限仅控制CREATE INDEX、DROP INDEX和ALTER TABLE ... ADD/DROP INDEX -
ALTER权限不自动包含INDEX，两者必须显式分开授予 - 在 MySQL 8.0+ 中，
INDEX权限仍属于数据库级或表级，不能按列授予
GRANT INDEX 的实际写法和常见错误
授予权限时必须指定作用范围（库或表），且不能省略 ON 后的数据库名——哪怕只想让某用户对单个表建索引，也得写成 db_name.table_name，不能只写 table_name。
- 正确：
GRANT INDEX ON mydb.users TO 'dev'@'192.168.1.%'; - 错误：
GRANT INDEX ON users TO 'dev'@'%';（缺少数据库名，会报错ERROR 1144 (42000)） - 错误：
GRANT INDEX ON *.* TO 'dev'@'%';（全局授权风险高，且多数生产环境禁止） - 撤销时也要严格匹配：
REVOKE INDEX ON mydb.users FROM 'dev'@'192.168.1.%';
验证用户是否真有 INDEX 权限
别只信自己刚执行的 GRANT 命令，得查实际生效结果。因为权限缓存、主机名匹配、大小写、甚至 MySQL 版本差异都可能让权限没生效。
- 用
SHOW GRANTS FOR 'dev'@'192.168.1.%';查看当前分配的权限列表 - 注意输出里是否明确出现
GRANT INDEX ON `mydb`.`users`，而不是笼统的ALL PRIVILEGES - 登录该用户后尝试执行
CREATE INDEX idx_name ON users(name);，失败时看具体错误码——如果是1142就确认是权限问题；如果是1022（duplicate key）则是业务逻辑问题 - MySQL 8.0+ 可查
mysql.role_edges或mysql.role_subsets确认角色是否间接赋予了INDEX
生产环境里最常被忽略的细节
INDEX 权限本身不危险，但容易和其它权限叠加出意料之外的能力。比如用户同时有 SELECT + INDEX，就能通过建索引暴露敏感字段的分布特征；如果还给了 CREATE TEMPORARY TABLES，甚至可能绕过某些审计规则。
- 不要把
INDEX和ALTER打包授予，除非明确需要改表结构 - 避免用
%通配符授权，特别是对内网 IP 段也要精确到 /24 或更细粒度 -
FLUSH PRIVILEGES在 MySQL 8.0+ 通常不需要，但如果你手动改过mysql.user表，就得执行 - 索引操作会锁表（尤其
ALGORITHM=INPLACE不支持所有场景），权限放开前得评估业务影响
