Вычислите рабочее общее количество в MySQL
Существует полное объяснение использования «статического» свойства здесь Microsoft.
В опыте веб-фреймворка (например, для этого .NET Core) мы используем статическое объявление для примитивных значений, которые НЕ потребуют никаких изменений.
6 ответов
Возможно, это более простое решение для вас, которое избавит базу данных от необходимости выполнять множество запросов. Выполняется только один запрос, а затем выполняется небольшая математическая обработка результатов за один проход.
SET @runtot:=0;
SELECT
q1.d,
q1.c,
(@runtot := @runtot + q1.c) AS rt
FROM
(SELECT
DAYOFYEAR(`date`) AS d,
COUNT(*) AS c
FROM `orders`
WHERE `hasPaid` > 0
GROUP BY d
ORDER BY d) AS q1
Это даст вам дополнительный столбец RT (промежуточный итог). Не пропустите оператор SET вверху, чтобы сначала инициализировать переменную промежуточного итога, иначе вы просто получите столбец со значениями NULL.
SELECT
DAYOFYEAR(O.`date`) AS d,
COUNT(*),
(select count(*) from `orders`
where DAYOFYEAR(`date`) <= d and `hasPaid` > 0)
FROM
`orders` as O
WHERE
O.`hasPaid` > 0
GROUP BY d
ORDER BY d
Это потребует некоторой синтаксической настройки (у меня нет MySQL для тестирования ее), но она показывает Вам идею. Подзапрос просто должен возвратиться и сложить все новое, которое Вы уже включали во внешний запрос, и это должно сделать это для каждой строки.
Смотрят на этот вопрос для того, как использовать соединения для выполнения того же.
Для обращения к опасениям по поводу снижения производительности с растущими данными: С тех пор через год существует максимум 366 дней, и я предполагаю, что Вы не выполняете этот запрос против нескольких лет, подзапрос будет оценен до 366 раз. С надлежащими индексами в день и флагом hasPaid, Вы будете в порядке.
Я сказал бы, что это невозможно, каждая получающаяся строка должна быть независимой. Используйте язык программирования для получения этих значений
Если у Вас нет никакой другой опции, но выполнения этого в sql, я суммировал бы результаты на языке программирования, который делает запрос. Вложение как это будет, стал очень медленным, когда таблица растет.
Можно взломать это использование оператора Cross Join или некоторых соединений slef, но это станет медленным с любыми большими наборами данных, таким образом, вероятно, лучше всего сделанными в процессоре запросов сообщения; любой курсор в клиентском коде
Это - одно из единственных мест, где курсоры быстрее, чем основанные на наборе запросы, если производительность очень важна, я был бы или
- , Делают это за пределами MySql или
- курсоры MySql 5 Использования