在全文索引上使用GROUPBY的MySQL查询速度非常慢

我正在建立一个收集反馈的在线工具。 现在，我正在为每个问题的所有答案创建一个可视化摘要，旁边有答案出现。我使用这个查询：

SELECT 
feedback_answer, 
feedback_qtype, 
COUNT(feedback_answer) as occurence 
FROM acc_data_1005 
WHERE (feedback_qtype=5 or feedback_qtype=4 or feedback_qtype=12 or feedback_qtype=13 or feedback_qtype=1 or feedback_qtype=2) 
and survey_id=205283 
GROUP BY feedback_answer ORDER BY feedback_qtype DESC, COUNT(feedback_answer) DESC

数据库表：

CREATE TABLE `acc_data_1005` (
  `id` int UNSIGNED NOT NULL,
  `survey_id` int UNSIGNED NOT NULL,
  `feedback_id` int UNSIGNED NOT NULL,
  `date_registered` date NOT NULL,
  `feedback_qid` int UNSIGNED NOT NULL,
  `feedback_question` varchar(140) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `feedback_qtype` tinyint UNSIGNED NOT NULL COMMENT 'nps, text, input etc',
  `data_type` tinyint UNSIGNED NOT NULL COMMENT '0 till 10 are sensitive data options (first name, last name, email etc.)',
  `feedback_answer` varchar(1500) CHARACTER SET utf8mb4 COLLATE utf8mb4_unicode_ci NOT NULL,
  `additional_data` varchar(500) COLLATE utf8mb4_unicode_ci NOT NULL
) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci ROW_FORMAT=DYNAMIC;

ALTER TABLE `acc_data_1005`
  ADD PRIMARY KEY (`id`),
  ADD KEY `date_registered` (`date_registered`),
  ADD KEY `feedback_qid` (`feedback_qid`,`feedback_question`) USING BTREE,
  ADD KEY `feedback_id` (`feedback_id`),
  ADD KEY `survey_id` (`survey_id`);
ALTER TABLE `acc_data_1005` ADD FULLTEXT KEY `feedback_answer` (`feedback_answer`);


ALTER TABLE `acc_data_1005`
  MODIFY `id` int UNSIGNED NOT NULL AUTO_INCREMENT, AUTO_INCREMENT=2020001;
COMMIT;

这个表大约有200万行，对于这个测试，它们都有相同的调查id。 Profling说执行需要96%的时间，解释结果：

id
select_type
table
partitions
type
possible_keys
key
key_len
ref
rows
filtered
Extra

1
SIMPLE
acc_data_1005
NULL
ref
survey_id,feedback_answer
survey_id
4
const
998375
46.86
Using where; Using temporary; Using filesort

此查询只需11行，大约需要22-30秒。 如果删除survey_id（这很重要），查询大约需要2-4秒（仍然太多）

我已经做了几个小时了，但不知道为什么这个查询这么慢。

---

如果有帮助的话，我可以转储SQL文件中的行（大约400-600MB）。

由于在全文索引（反馈回答）长字符项上扫描200万行，group by的速度很慢

我创建了另一个表“analysis_stats”，创建了一个cron作业，每月运行这个查询（仅针对该月的数据），并将其存储在stats表中

当客户希望获得全年的数据（200多万行，速度太慢）时，我只需要从stats表中获取几行数据，然后仅在当前月份运行group by查询。这只需要将大约10000-20000行分组，而不是立即分组的200万行

也许不是最有效的方法，但对我来说很有效；）

---

希望它可以帮助有类似问题的人。

您的查询中没有使用全文，因此全文索引的存在不会影响查询速度。请使用单个

反馈\u qtype in（{values list}）

替换您的OR条件链。嗨，Akina，根据解释结果使用反馈\u答案（全文索引）？将OR替换为IN，没有结果我看到使用DDL中的

key='survey\u id'

这是

ADD key

survey\u id`（

survey\u id

）`）。这不是金融时报<代码>反馈\u答案列在

可能的\u键

中，但它没有被使用。啊，你在哪里可以看到它实际被使用/未被使用？什么是DDL和FTS（全文搜索？）。关于如何使查询更快，还有其他想法吗？