Приветствую, господа! Возникла проблема и нужно определиться в причине. Выполняю один и тот же запрос с сортировкой и лимитом в консоли, phpMyAdmin и через раз-другой, выдаются абсолютно разные результаты. То, что дело не в запросе - это примерно 110% из 100, т.к. на локалке всё работает идеально. Разница только в том, что на локалке версия мускула 5.5.53, а на боевом - 5.5.56. Перед тем, как принимать что-то по решению проблемы, хочу спросить, если кто сталкивался с подобным: может ли это быть неправильная конфигурация MySQL или это баг конкретной версии?
Нет. Все JOIN-ы и условия выборки идут только по индексированным числовым полям. И я специально акцентировал внимание на том, что сам запрос тут не при чем. Я тоже когда-то любил так поумничать... Нужно на форуме ввести правило, где задающий вопрос обязательно указывал: гуглил или нет
@Deonis Ну не знаю вот любой ответ берешь и вроде все логично. Код (Text): The issue is that InnoDB's estimated statistics vary (they are only estimates, and there is some randomness) so sometimes the optimizer is choosing one plan, sometimes another. You might have to use STRAIGHT_JOIN or some other hint to prevent this flapping back and forth. I don't think you have a good index on the table for this query. The index_merge query plan is really not very good. Please paste SHOW CREATE TABLE.
@Deonis, запрос написан ручками или собирается билдером? Логи смотрели? На экран готовый запрос с ответом выводили? В чём сложность показать реальный запрос тут на форуме?
@nospiou, видел, но не мой случай, т.к. таблицы MyISAM. Сейчас проверил на соседнем серваке, где версия мускула 5.5.40 и работает зараза, как часы. Естественно, что конфиги на всех трёх мускулах, где тестировал, разные. Вот и думаю: то ли именно версия 5.5.56 глючная, то ли "криво" собралась, то ли дело где-то в конфигах. Да ни в чем: Код (Text): SELECT `p`.`product_id`, `p`.`manufacturer_id`, ( SELECT AVG(`rating`) AS `total` FROM `oc_review` `r1` WHERE `r1`.`product_id` = `p`.`product_id` AND `r1`.`status` = 1 GROUP BY `r1`.`product_id` ) AS `rating`, `p`.`hits` FROM `oc_category_path` `cp` LEFT JOIN `oc_product_to_category` `p2c` ON (`cp`.`category_id` = `p2c`.`category_id`) LEFT JOIN `oc_product` `p` ON (`p2c`.`product_id` = `p`.`product_id`) LEFT JOIN `oc_product_description` `pd` ON (`p`.`product_id` = `pd`.`product_id`) LEFT JOIN `oc_product_to_store` `p2s` ON (`p`.`product_id` = `p2s`.`product_id`) WHERE `pd`.`language_id` = 1 AND `p`.`status` = 1 AND `p`.`quantity` > 0 AND `cp`.`path_id` = 118 GROUP BY `p`.`product_id` ORDER BY `p`.`sort_order` DESC, `p`.`has_discount` DESC LIMIT 0,24
Один в один. Ок, если пойти методом исключения, то может ли какой-то параметр конфига влиять на такое поведение? Я сам в этом сомневаюсь, хоть и не особо силён в настройках, но гипотетически такой вариант не отбрасываю.
@Deonis А вот кто его знает. Я вот вижу GROUP BY без сортировки это не может повлиять? Код (Text): This is a bug in your use of the database. MySQL is quite explicit that when you include columns in the SELECT clause in an aggregation query -- and they are not in the GROUP BY -- then they come from indeterminate rows.
Хрен его знает... С другой стороны, на других серваках тоже бы влияло. В общем, если еще пару вариантов не внесут ясность, то скорее всего, что придётся спрыгивать на другую версию.
Вот неплохое объяснение с разными результатами https://dba.stackexchange.com/quest...ting-different-results-from-a-query-vs-a-view