创建、删除或修改fulltext索引需index权限，通常还需alter权限；执行match() against()查询需select权限；重建索引还可能要求对停用词表的select权限。
全文索引操作需要哪些权限？
在 MySQL 中，创建、删除或修改 FULLTEXT 索引本身不依赖特殊权限，但实际执行涉及几个关键权限层级：
-
INDEX权限：必须拥有，否则ALTER TABLE ... ADD FULLTEXT或DROP INDEX会报错ERROR 1142 (42000): INDEX command denied to user -
ALTER权限：多数情况下也需要，因为ADD FULLTEXT是 DDL 操作；若仅用CREATE INDEX语法，则只需INDEX -
SELECT权限：执行MATCH() AGAINST()查询时必需，否则报ERROR 1142: SELECT command denied -
INSERT/UPDATE/DELETE：不影响索引结构，但影响索引内容更新（InnoDB 全文索引在事务提交后异步更新）
注意：CREATE FULLTEXT INDEX 语句不能单独授权——MySQL 不提供 CREATE FULLTEXT INDEX 这类细粒度权限，它被归入 INDEX 权限范畴。
为什么给用户授了 ALL PRIVILEGES 还报错？
常见现象：DBA 执行 GRANT ALL ON db.* TO 'u'@'%'; FLUSH PRIVILEGES;，但应用用户仍无法建全文索引。原因通常是：
- 权限未生效于目标库：比如用户连接时用了
USE other_db;，而权限只给了db.*，ALTER TABLE会因跨库失败 - 用户 host 匹配失败：如授权的是
'u'@'localhost'，但连接用的是'u'@'127.0.0.1'（二者在 MySQL 权限系统中视为不同用户） - 权限缓存未刷新：虽然
FLUSH PRIVILEGES多数情况有效，但某些 RDS（如阿里云 MySQL 8.0）需通过控制台「提交参数」或等待内部同步，命令行刷新可能无效
验证方式：用该用户登录后执行 SHOW GRANTS;，确认输出里确实含 GRANT INDEX ON `db`.* 或 GRANT ALL PRIVILEGES ON `db`.*。
生产环境最小权限怎么配？
不建议直接授 ALL，尤其对应用账号。推荐按动作最小化授权：
- 只读搜索账号：
GRANT SELECT, INDEX ON db.articles TO 'searcher'@'%';（INDEX允许其执行MATCH查询，但无法改表结构） - 索引维护账号（如运维脚本）：
GRANT SELECT, INSERT, UPDATE, DELETE, ALTER, INDEX ON db.articles TO 'ft_maintainer'@'10.0.0.%'; - 禁止跨库操作：显式限定库名，避免
GRANT ... ON *.*；全文索引不跨库生效，ON *.*反而增加误操作风险
特别注意：INDEX 权限本身不包含查看索引定义的能力——要查 SHOW CREATE TABLE 或 INFORMATION_SCHEMA.STATISTICS，还需 SELECT 权限。
全文索引重建时权限有额外要求吗？
有。重建全文索引（如删旧索引再建新）本质是两次 DDL：
-
ALTER TABLE t DROP INDEX ft_idx→ 需INDEX+ALTER -
ALTER TABLE t ADD FULLTEXT INDEX ft_idx (col)→ 同样需INDEX+ALTER，且要求表无长事务阻塞（否则会卡住） - 如果配置了自定义停用词表（
innodb_ft_server_stopword_table），建索引前还必须对该表有SELECT权限，否则报ERROR 1856: Invalid stopword table
容易被忽略的一点：重建期间 InnoDB 会扫描全表并解析文本，若字段含敏感内容，SELECT 权限实际等价于授予了“可读全文”权限——权限设计时得把数据可见性一并考虑进去。
