|
|
Задавайте вопросы, мы ответим
Вы не зашли.
Страниц: 1 2
Попробуйте OR заменить на WordID IN (892, ...)
Неактивен
Для чистоты эксперимента выполнил следующее:
set profiling=1;
SELECT word_weight.DocID FROM indexdata.word_weight
WHERE WordID = 68603 OR WordID = 204661 OR WordID = 16347
OR WordID = 68131;
show profiles;
Query_ID 17; Duration 2.41972925.
При увеличении количества WordID время Duration растет. Ничего не понимаю. Это все делаю не через MySQL Query Browser, а программно. Ничего не понимаю...
Неактивен
попробуйте написанное в сообщении #26
Неактивен
straylon, нужно SHOW PROFILE - без S на конце. Тогда будет видна детализация по запросу.
Это все делаю не через MySQL Query Browser, а программно.
А программно — это как? Что у вас за клиент?
Вы можете попробовать на клиенте не принимать результат, а просто послать запрос, чтобы он на сервере выполнился, а клиент его не обрабатывал? (все-таки подозрение на клиент — что из-за него медленно)
Неактивен
Просмотрел show profile for query 17;
Все параметры маленькие, кроме 'Sending data', = 2.388797.
Но данные мне нужны же? Да и тестил на запрос вида SELECT Count(*) - где всего одна строчка должна быть, как sending data, все равно время время 'Sending data' от 3 секунд и выше
Неактивен
LaZy, в том то и загвоздка, что клиент посылает запрос (вот кусок кода на Qt):
QString frelev_file = "SELECT word_weight.DocID FROM indexdata.word_weight WHERE WordID = 68603 OR WordID = 204661 OR WordID = 16347 OR WordID = 68131";
query.prepare(frelev_file);
query.exec();
Т.е. просто посылаю на сервер на выполнение и все. Никак результат не обрабатываю. Мистика... Если количество WordId в запросе больше, чем 3 слова, то выплняется от 2 секунд и выше, если 1-2 слова, то около секунды.
Неактивен
Что за время такое Sending data в случае всего одной строки COUNT(*). Вот что странно.
Неактивен
Да, странно..
Впрочем, ходят слухи, что Sending data может отхватывать время у Executing. Т.е. в это время запрос действительно выполняется. На это указывает также высокая загрузка процессора, о которой вы упоминали.
Скажите, какой у вас процессор?
Неактивен
Повозился еще. Для большинства запросов вида SELECT count(*) выполняется все достаточно быстро ~ 0,3 s, если все индексы загружены в память. Значит все дело в большой выборке (много DocID находится в результате запроса). Но проблема остается - мне же нужны как раз эти DocID, а не их число, да и выбрасывать нельзя (LIMIT), т.к. часть информации потеряется. А дальше их упорядочивание по GROUP BY и HAVING. Скорее всего для такой задачи, которая описана в самом первом сообщении, 3-4 секунды это нормальное время для MySQL. Вариант с WordID IN (, .... ) ничего не меняет 
Неактивен
Сейчас все это тестировал на компе c процессором Intel на два ядра, каждое по 1.8 Ггц.
Неактивен
Да уж.. Все-таки странно, что так долго. Колонки-то короткие. 20000 записей по 6 байт - это ведь всего 100-200k. Странно, что он с ними так долго справляется.
Ну, возможно, тут действительно ничего не поделаешь
Вообще говоря, если для вас актуальна задача поиска слов и документы обновляются не очень быстро — посмотрите в сторону sphinx.
Неактивен
LaZy, да тут задача автоматического реферирования стоит, а не поиска. Вот такая вот фигня.
Неактивен
Ээ.. Что это собой представляет?
Неактивен
У вас есть статья на несколько страниц, можете краткую выдержку из нее прочесть самых информативных предложений (объем сами задаете, например, 7-10 предложений).
Неактивен
Вот можете посмотреть скриншот, как это все выглядит в нашей разработке. Занимаемся оптимизацией сейчас. Думал на таком запросе пару секунд сэкономить. Но видно не судьба.
Неактивен
Страниц: 1 2
