mysql启动后cpu持续高并非全文索引后台扫描所致，因其无此机制；真实开销仅发生在显式match...against查询时，取决于缓存命中、分词处理、排序及并发执行等因素。
MySQL启动后CPU持续高，真是全文索引在后台扫描？
不是。MySQL本身没有“全文索引后台扫描”这个机制。InnoDB全文索引（FULLTEXT）的更新是同步写入辅助表（如FTS_0000000000000001_0000000000000002_INDEX_1）的，不依赖定时轮询或后台扫描任务。你看到的CPU高，大概率是其他原因被误判——比如某个应用刚连上就批量执行SELECT ... MATCH AGAINST，或者有未加索引的LIKE '%xxx%'查询被当成全文需求硬扛。
哪些操作会触发InnoDB全文索引的真实开销？
InnoDB全文索引的实际CPU消耗只发生在明确使用MATCH ... AGAINST时，且取决于以下几点：
-
MATCH查询是否命中缓存：首次执行需加载倒排索引页到innodb_buffer_pool，可能引发大量磁盘读和解析开销 - 查询词是否触发停用词过滤或分词器处理：中文需
ngram或mechanical插件，分词本身吃CPU - 结果集排序：如果
ORDER BY MATCH(...) DESC且匹配行数大，Using filesort会显著拉高CPU - 并发执行多个
MATCH查询：每个都独立解析倒排结构，无共享计算
如何快速排除全文索引不是真凶？
直接查当前活跃负载里有没有MATCH相关SQL，而不是猜后台在扫什么：
SELECT id, user, host, db, command, time, state, LEFT(info, 200) AS sql_text FROM information_schema.PROCESSLIST WHERE info IS NOT NULL AND info LIKE '%MATCH%AGAINST%' AND command != 'Sleep' ORDER BY time DESC;
如果结果为空，全文索引可立即排除。再顺手跑一句：
SELECT table_schema, table_name, engine, comment
FROM information_schema.TABLES
WHERE engine = 'InnoDB'
AND table_schema NOT IN ('mysql', 'information_schema', 'performance_schema', 'sys')
AND table_name IN (
SELECT table_name FROM information_schema.STATISTICS
WHERE index_type = 'FULLTEXT'
);
确认确实建了FULLTEXT索引——很多团队根本没建，只是以为自己用了。
真正该盯住的CPU热点来源
全文索引背锅最多，但实际更常见的CPU大户是这几类：
-
SELECT * FROM huge_table WHERE created_at > '2025-01-01'：没在created_at建索引，type=ALL全表扫 -
UPDATE orders SET status = 'shipped' WHERE user_id = ? AND status = 'pending'：user_id + status缺联合索引，每次都要遍历pending状态行 -
GROUP BY category ORDER BY COUNT(*) DESC：大数据量下Using temporary; Using filesort双杀 - 长事务未提交：阻塞其他会话，导致一堆线程卡在
Waiting for table metadata lock，top里看mysqld CPU高，其实是等锁空转
别被“全文索引”这个词带偏——它只是个查询语法糖，不是后台服务。CPU高，永远先看SHOW PROCESSLIST里活的SQL，再看EXPLAIN输出里的type和Extra，最后才轮到索引结构本身。
