В настоящее время я пытаюсь выполнить несколько запросов к дампу данных комментариев переполнения стека. Вот как выглядит схема:
CREATE TABLE `socomments` (
`Id` int(11) NOT NULL,
`PostId` int(11) NOT NULL,
`Score` int(11) DEFAULT NULL,
`Text` varchar(600) NOT NULL,
`CreationDate` timestamp NOT NULL DEFAULT CURRENT_TIMESTAMP ON UPDATE CURRENT_TIMESTAMP,
`UserId` int(11) NOT NULL,
PRIMARY KEY (`Id`),
KEY `idx_socomments_PostId` (`PostId`),
KEY `CreationDate` (`CreationDate`),
FULLTEXT KEY `Text` (`Text`)
) ENGINE=InnoDB DEFAULT CHARSET=utf8Я выполнил этот запрос к таблице, и он работал невероятно медленно (у него есть 29 миллионов строк, но у него есть полнотекстовый индекс):
SELECT *
FROM socomments
WHERE MATCH (Text) AGAINST ('"fixed the post"' IN BOOLEAN MODE)Итак, я его профилировал, результаты которого таковы:
|| Status || Duration ||
|| starting || 0.000058 ||
|| checking permissions || 0.000006 ||
|| Opening tables || 0.000014 ||
|| init || 0.000019 ||
|| System lock || 0.000006 ||
|| optimizing || 0.000007 ||
|| statistics || 0.000013 ||
|| preparing || 0.000005 ||
|| FULLTEXT initialization || 207.1112 ||
|| executing || 0.000009 ||
|| Sending data || 0.000856 ||
|| end || 0.000004 ||
|| query end || 0.000004 ||
|| closing tables || 0.000006 ||
|| freeing items || 0.000059 ||
|| logging slow query || 0.000037 ||
|| cleaning up || 0.000046 ||Как видите, он долго тратит на инициализацию FULLTEXT. Это нормально? Если нет, то как бы это исправить?
id_group 2иid_group 23. С этим ваш поиск внутри вашей основной таблицы и ограничить ваш запрос диапазонами идентификаторов от 2.000 до 2.999 и от 23.000 до 23.999. Конечно, 2-й будет давать больше результатов по мере необходимости, поскольку вы смешиваете все комментарии, создавая новые комбинации ключевых слов, но, наконец, это должно ускорить все это. Конечно, это удваивает использование дискового пространства. Новые комментарии должны быть связаны с таблицей групп.