Задавайте вопросы, мы ответим
Вы не зашли.
Как-то непонятно, последние пару месяцев начали вылазить ошибки, которые до этого 4 года никогда не видел. О них я создавал уже несколько тем с вопросами, консенсуса так и не нашли. Несколько раз получал такое сообщение:
#1104 - The SELECT would examine more than MAX_JOIN_SIZE rows; check your WHERE and use SET SQL_BIG_SELECTS=1 or SET SQL_MAX_JOIN_SIZE=# if the SELECT is okay
Ну, думаю, запрос толстый, данных много, не хватает ресурсов, пересмотрел конфиг/запрос, проблема решилась. Сегодня же очередной финт, свалил меня наповал...
Имеем вполне успешно выполняемый запрос:
SELECT
`routes`.`id` ,
`routes`.`name` ,
`routes`.`credits` ,
`routes`.`all_signs` ,
`routes`.`status` ,
COUNT( DISTINCT `users`.`id` ) AS `users` ,
COUNT( DISTINCT `routes_signs`.`sign_id` ) AS `signs`
FROM `routes`
LEFT JOIN `users` ON `users`.`route_id` = `routes`.`id`
LEFT JOIN `routes_signs` ON `routes_signs`.`route_id` = `routes`.`id`
GROUP BY `routes`.`id`
ORDER BY `users` DESC
Стоит только поменять сортировку с `users` на `routes`.`id`, как вылазит вот это сообщение. Где логика?
ЗЫ SQL_BIG_SELECTS у нас OFF, но ведь в запросе меняется только сортировка, не влияющая на выборку.
Неактивен
Здесь MySQL полагается на свою оценку числа выбираемых строк. Что выдаст EXPLAIN для двух запросов?
Неактивен
Эксплейн одинаковый для обоих запросов:
id select_type table type possible_keys key key_len ref rows Extra
1 SIMPLE routes ALL NULL NULL NULL NULL 19 Using temporary; Using filesort
1 SIMPLE users ALL NULL NULL NULL NULL 14106
1 SIMPLE routes_signs ref PRIMARY PRIMARY 1 route.routes.id 2869 Using index
Неактивен
Очень странно. Согласно EXPLAIN всего 700 миллионов записей. А чему равно MAX_JOIN_SIZE?
Неактивен
Сейчас 512М... Этот параметр задаёт количество записей или лимит памяти для джоина?
Неактивен
max_join_size - максимальное количество записей, join_buffer_size - размер буфера
Неактивен
Хм, значит есть смысл увеличить max_join_size. Какие-то рекомендации есть аля "чем больше тем лучше"?
ЗЫ Но тема не раскрыта, при разных сортировках имеем разный результат при одинаковых эксплейнах
Неактивен
Например, можно для max_join_size оставить значение по умолчанию 18446744073709551615. Никаких пробем с этим значением не было.
Насчет темы, получается, что алгоритм для оценки join_size не такой как в explain. Разобраться можно только отлаживая исходный код. Разработчики вряд ли признают багу, так как нигде в документации не написано, что результат должен быть одинаковый, а join_size оценивается лишь приближенно в любом случае.
Неактивен
Ок, спасибо за помощь
Неактивен
Сорри, что не конкретно по теме, но вас не напрягает два ALL-объединения? Есть мысль, что неплохо бы индекс добавить (`users`.`route_id` скорее всего, но не зная структуры таблицы не уверен).
Неактивен
Мммм, да, спасибо за подсказку, даже не думал об этом, ведь данных в таблицах не много Добавил индекс, теперь 14106 стало 2360
Неактивен