Являются ли множественные агрегаты в операторе выбора проблемой производительности?
Вам действительно нужно использовать только те инструменты? Они не предназначены для обработки XML, и хотя можно получить что-то, что работает нормально большую часть времени, оно не будет работать в крайних случаях, таких как кодирование, разрывы строк и т. Д.
Я рекомендую xml_grep:
xml_grep 'job' jobs.xml --text_only
Что дает результат:
programming
В ubuntu / debian xml_grep находится в пакете xml-twig-tools.
1 ответ
В качестве общего ответа я бы сказал, нет. Тем не менее, только план выполнения SQL скажет .
В вашем случае вы многократно используете одни и те же выражения агрегации. Даже базовый оптимизатор SQL должен понимать, что они одинаковые и вычислять каждый из них один раз.
Поскольку ваш запрос не имеет условий фильтрации, он читает обе таблицы целиком. Самая большая стоимость вашего запроса, вероятно, связана с порядком соединения. Должен ли он начинаться с payments, а затем идти к users или наоборот? Наличие / отсутствие индексов может быть решающим здесь.
Редактировать:
Теперь, если вы обнаружите, что ваш оптимизатор не настолько умен, вы можете убедиться, что он вычисляет каждую агрегацию только один раз, используя подзапрос (или CTE при использовании MySQL 8.x). Например, вы можете перефразировать ваш запрос как:
select
total_sales,
quantity,
total_sales / quantity as average_sale,
`name`,
`user_id`
from (
SELECT
SUM(payments.amount) as total_sales,
COUNT(payments.id) as quantity,
`users`.`name`,
`payments`.`user_id`
FROM `payments`
INNER JOIN `users` on `payments`.`user_id` = `users`.`id`
GROUP BY `payments`.`user_id`
) x
ORDER BY `total_sales` DESC