Сообщение #5 korshunov » 04.04.2019, 11:34
zyxer писал(а):Попробуйте погонять этот запрос на разных наборах данных, и увидите что большинство из них там действительно нужны. Да, для некоторых полей они добавлены "на всякий случай".
Хорошо, пробуем.
На свежеустановленной CMS открываю страницу категории Детские игрушки
http://localhost/OkayCMS232/catalog/detskie-igrushkiЗапрос на этой странице имеет вид:
Код: Выделить всё
SELECT
MAX(`fv`.`id`) AS `id`,
MAX(`fv`.`feature_id`) AS `feature_id`,
MAX(`fv`.`position`) AS `position`,
count(`pf`.`product_id`) AS `count`,
MAX(`f`.`id`) AS `feature_id`,
MAX(`f`.`auto_name_id`) AS `auto_name_id`,
MAX(`f`.`auto_value_id`) AS `auto_value_id`,
MAX(`f`.`url`) AS `url`,
MAX(`f`.`in_filter`) AS `in_filter`,
MAX(`f`.`yandex`) AS `yandex`,
MAX(`f`.`url_in_product`) AS `url_in_product`,
MAX(`fv`.`to_index`) AS `to_index`,
MAX(l.value) AS value, MAX(l.translit) AS translit, MAX(l.feature_id) AS feature_id,
MAX(lf.name) AS name
FROM `ok_features_values` AS `fv`
LEFT JOIN `ok_features` AS `f` ON `f`.`id`=`fv`.`feature_id`
LEFT JOIN `ok_products_features_values` AS `pf` ON `pf`.`value_id`=`fv`.`id`
LEFT JOIN ok_lang_features_values l ON l.feature_value_id=fv.id AND l.lang_id = 1
LEFT JOIN ok_lang_features lf ON lf.feature_id=f.id AND lf.lang_id = 1
LEFT JOIN `ok_products` AS `p` ON `p`.`id`=`pf`.`product_id`
INNER JOIN `ok_products_categories` `pc` ON `pc`.`product_id`=`pf`.`product_id` AND `pc`.`category_id` in('10','11','9')
WHERE
1
AND `fv`.`feature_id` in('10','42','43','44','45','46','47')
AND `visible`=1
GROUP BY `fv`.`id`
ORDER BY `f`.`position` ASC, `fv`.`position` ASC, `value` ASC
1. Первое поле MAX(`fv`.`id`) AS `id` стоит под функцией MAX, которая совсем не нужна по причине имеющейся группировки как раз по этому полю. И в двух следующих полях MAX - тоже лишняя деталь.
2. Про второе поле и еще два с ним связанных (с алиасом AS `feature_id`) уже говорилось - явное безобразие (или нерациональность, или ошибка, или неграмотность - выбирайте на свой вкус).
3. Поля url_in_product - непонятно зачем и для чего тут нужно. По моим сведениям, на фронтенде оно используется в шаблоне только на странице отдельного товара. А на всех прочих страницах оно совсем ни к чему. Если я что не доглядел, ткните носом, пожалуйста...
4. Поле yandex - аналогично непонятно, зачем. я вообще не вижу не только, где его значение в результатах запроса используется не только на странице категории, но и вообще на фронтенде. Если знаете, подскажите...
5. Дальше уж анализировать не стал...
zyxer писал(а):...большинство из них там действительно нужны. Да, для некоторых полей они добавлены "на всякий случай".
Думаю, что все как раз наоборот - очень много полей просто не нужны и добавлены именно "на всякий случай".
Подозреваю, что сами Вы не особо-то пробовали "погонять этот запрос на разных наборах данных", потому как не увидеть ошибку с тройным повторный алиасом ну никак не возможно...
zyxer писал(а):Что вы имеете ввиду под фразой "корректный правильный код"? Я имею ввиду не размытую фразу которыми вы любите бросаться, а что-то конкретное.
Конкретно уже говорил: надо бы писать код под новые стандарты MySQL, а не подгонять старые методы, чтобы они работали в виде исключений. В данном примере - поголовное искусственное применение MAX в извлекаемых полях - выглядит явно нерационально. И набор полей - явно перегружен лишними значениями.
Кстати, этот запрос у меня по времени выполнения - самый затратный (съедает 25-30% от времени выполнения всех запросов на странице).
[quote="zyxer"]
Попробуйте погонять этот запрос на разных наборах данных, и увидите что большинство из них там действительно нужны. Да, для некоторых полей они добавлены "на всякий случай".
[/quote]
Хорошо, пробуем.
На свежеустановленной CMS открываю страницу категории Детские игрушки
http://localhost/OkayCMS232/catalog/detskie-igrushki
Запрос на этой странице имеет вид:
[code] SELECT
MAX(`fv`.`id`) AS `id`,
MAX(`fv`.`feature_id`) AS `feature_id`,
MAX(`fv`.`position`) AS `position`,
count(`pf`.`product_id`) AS `count`,
MAX(`f`.`id`) AS `feature_id`,
MAX(`f`.`auto_name_id`) AS `auto_name_id`,
MAX(`f`.`auto_value_id`) AS `auto_value_id`,
MAX(`f`.`url`) AS `url`,
MAX(`f`.`in_filter`) AS `in_filter`,
MAX(`f`.`yandex`) AS `yandex`,
MAX(`f`.`url_in_product`) AS `url_in_product`,
MAX(`fv`.`to_index`) AS `to_index`,
MAX(l.value) AS value, MAX(l.translit) AS translit, MAX(l.feature_id) AS feature_id,
MAX(lf.name) AS name
FROM `ok_features_values` AS `fv`
LEFT JOIN `ok_features` AS `f` ON `f`.`id`=`fv`.`feature_id`
LEFT JOIN `ok_products_features_values` AS `pf` ON `pf`.`value_id`=`fv`.`id`
LEFT JOIN ok_lang_features_values l ON l.feature_value_id=fv.id AND l.lang_id = 1
LEFT JOIN ok_lang_features lf ON lf.feature_id=f.id AND lf.lang_id = 1
LEFT JOIN `ok_products` AS `p` ON `p`.`id`=`pf`.`product_id`
INNER JOIN `ok_products_categories` `pc` ON `pc`.`product_id`=`pf`.`product_id` AND `pc`.`category_id` in('10','11','9')
WHERE
1
AND `fv`.`feature_id` in('10','42','43','44','45','46','47')
AND `visible`=1
GROUP BY `fv`.`id`
ORDER BY `f`.`position` ASC, `fv`.`position` ASC, `value` ASC
[/code]
1. Первое поле MAX(`fv`.`id`) AS `id` стоит под функцией MAX, которая совсем не нужна по причине имеющейся группировки как раз по этому полю. И в двух следующих полях MAX - тоже лишняя деталь.
2. Про второе поле и еще два с ним связанных (с алиасом AS `feature_id`) уже говорилось - явное безобразие (или нерациональность, или ошибка, или неграмотность - выбирайте на свой вкус).
3. Поля url_in_product - непонятно зачем и для чего тут нужно. По моим сведениям, на фронтенде оно используется в шаблоне только на странице отдельного товара. А на всех прочих страницах оно совсем ни к чему. Если я что не доглядел, ткните носом, пожалуйста...
4. Поле yandex - аналогично непонятно, зачем. я вообще не вижу не только, где его значение в результатах запроса используется не только на странице категории, но и вообще на фронтенде. Если знаете, подскажите...
5. Дальше уж анализировать не стал...
[quote="zyxer"]
...большинство из них там действительно нужны. Да, для некоторых полей они добавлены "на всякий случай".
[/quote]
Думаю, что все как раз наоборот - очень много полей просто не нужны и добавлены именно "на всякий случай".
Подозреваю, что сами Вы не особо-то пробовали "погонять этот запрос на разных наборах данных", потому как не увидеть ошибку с тройным повторный алиасом ну никак не возможно...
[quote="zyxer"]Что вы имеете ввиду под фразой "корректный правильный код"? Я имею ввиду не размытую фразу которыми вы любите бросаться, а что-то конкретное.
[/quote]
Конкретно уже говорил: надо бы писать код под новые стандарты MySQL, а не подгонять старые методы, чтобы они работали в виде исключений. В данном примере - поголовное искусственное применение MAX в извлекаемых полях - выглядит явно нерационально. И набор полей - явно перегружен лишними значениями.
Кстати, этот запрос у меня по времени выполнения - самый затратный (съедает 25-30% от времени выполнения всех запросов на странице).