![]()  | 
		     | 
	
Задавайте вопросы, мы ответим
Вы не зашли.
Как-то непонятно, последние пару месяцев начали вылазить ошибки, которые до этого 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 ![]()
Неактивен