Наразі я намагаюся запустити деякі запити щодо дамп даних коментарів Stack Overflow. Ось як виглядає схема:
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-й призведе до більшої кількості результатів, якщо потрібно змішати всі коментарі, створюючи нові комбінації ключових слів, але, нарешті, це повинно прискорити все. Звичайно, це подвоює використання дискового простору. Нові коментарі слід КОНЦАТУВАТИ до групової таблиці.