|
Задавайте вопросы, мы ответим
Вы не зашли.
Я так понимаю, что иногда мускл неявно использует временные таблицы для хранения промежуточных данных.
У меня такая ситуация, что из таблицы в 40млн записей, по поиску отбираются 4млн, затем группируются и в конечном результате выдаются 500 штук. По наблюдению за процессами я определил, что эти 4млн записей сначала копируются во временную таблицу, а затем уже группируются, что занимает прилично времени.
Собссна вопрос, как можно ускорить такой процесс? Можно ли как-то не использовать это копирование и группировать непосредственно из таблицы выборки? Или может я вообще неправильно придумал себе объяснения))
Неактивен
Вы уберите группировку и посмотрите останется ли использование временной таблицы или нет. Иногда могут помочь составные ключи, но в хоть немного сложном случае они не помогут. Вы можете сделать, чтобы временная таблица была не на диске, а в памяти - для этого надо увеличить tmp_table_size и max_heap_table_size, см. http://dev.mysql.com/doc/refman/5.1/en/ … ngine.html
Неактивен
Да, без группировки временная таблица не используется. С ключами тоже не выйдет, слишком много полей в поиске и наличие каждого не гарантированно.
С tmp_table_size и max_heap_table_size тоже непонятки, но это скорее локальная проблема. Как-то заметил, что когда мускл скушает порядка 600Мб памяти, большинство запросов не выполняется ссылаясь на нехватку памяти, хотя на сервере установлено 4Гб и они точно свободны.
Неактивен
Neval написал:
С tmp_table_size и max_heap_table_size тоже непонятки, но это скорее локальная проблема. Как-то заметил, что когда мускл скушает порядка 600Мб памяти, большинство запросов не выполняется ссылаясь на нехватку памяти, хотя на сервере установлено 4Гб и они точно свободны.
Система FreeBSD? Если да, попробуйте MySQL перекомпилить из исходников оригинальных (не из портов)
Неактивен
Да-да, вот до этого всё никак руки не дойдут 
Неактивен
