Суть такова. Будут записи со значением 0, они должны быть в базе, но постоянной работы с ними не будет. Вернее, она будет, но не такая активная. И будут все остальные записи, которые будут проверяться таском каждые 25 сек., истёк ли у них timestamp.

Вот, собсно, и должны попасть в выборку только "активные" записи.

Значит between

Т.к. нужно диапазон хватать

И индексы не забудь

А эвент делать можно и реже

Угу, сейчас explain'ом прошёлся, фильтрация увеличивается, но всё равно по всем строкам проходится.

А эвент делать можно и реже

В моём случае - не желательно.

Можно селектить с таймштампом

И тогда в выборку они попадать не будут

То есть, после SELECT указать timestamp и это автоматически отсеет нули?

Нет, ща распишу

Мне нужно было селектить живые записи, которые не протухли по timestamp

Я сделал отдельное поле active 0/1 значения

У меня будет даже не SELECT. У меня будет DELETE всех записей, которые имеют timestamp > 0, и которые при этом должны быть удалены на текущий момент (определяем по timestamp). Записи с нулями хранятся вечно.

Ааа

Ну я продолжу

Угу

Живую запись доставал: where active = 1 and timestamp > unix_timestamp(now())

А потом евент повесил раз в пол часа обновлять поле active

Нагрузка нормально просела прям

До этого 2 раза в минуту чекал

Правда у меея база 30гб)

Гм, я вот думаю, будет ли у меня возможность вешать event. Т.к. буду работать через сторонний скрипт и напрямую доступа к БД не будет, ну, то есть, только общение посредством запросов.

В настройки mysql не лезем.

И БД будет конечно не таких объёмов =)

Зависит от прав

Если мускул не даст, то cron - наше все

Но там минимальный период - 1 минута

Ну тогда это точно не мой вариант, юзеры тупо не разберутся с этим. Пишу под http://amxmodx.org/api/

Можно извратиться через && запускать скрипты и слипить

Прикол ещё в чём. БД окажется на каком-нибудь shared хостинге. И у юзера не будет возможности всё детально настроить.

Как вариант

Это возможно

Для базы - vps)

Поэтому, к сожалению, я пока ориентируюсь только на оптимизацию запросов, но задачи придётся реализовывать при помощи скрипта + запросов, как это не печально.

Ну при индексе по timestamp будет работать быстро

Ну да, только unique боюсь делать.

Придётся обойтись обычным.

Не нужно там uniq

Двух записей в секунду не будет?

Это возможно.

Ну я о том, что будут записи, которые в одно время протухнут

Да, такое вполне может быть. За секунду скрипт вполне может добавить несколько записей одновременно.

Значит никаких уников

+

Всё-таки решил избавиться от нуля, изменил запрос таким образом: SELECT * FROM `some_table` WHERE `timestamp` <= UNIX_TIMESTAMP() IS NOT NULL

0 и null разные значения

И условие это не отработает

Ты на null проверяешь unix_timestamp текущий

0 и null разные значения

Ну да, я понимаю.

И условие это не отработает

Если использовать именно NULL вместо нуля, то ОК.

А у тебя запрос не дольше будет отрабатывать . Тут тебе нужно будет проверять 2 типа значений число и нулл , а так индексы построил и поиск быстрей ?

Если честно, не проверял. Построю временную БД и поиграюсь как следует с explain'ом.

*временную таблицу, БД есть уже, по сути

Отпиши потом результат , а то любопытно

ОК, на днях сделаю.

Добрый день!Подскажите, пожалуйста, как к каждому amount прибавить сумму предыдущих.

SQL-кодом?

https://www.w3schools.com/sql/sql_func_sum.asp - оно?

>.SQL-кодом? да

это нужно сделать один раз:

?

Для каждой даты прибавить сумму предыдущих. К примеру 1434 1434 + 1435 1434 + 1435 + 1436

я имею в виду саму операцию нужно один раз сделать над таблицей или она будет повторяться через время?

Один раз

тогда напиши простой скрипт и всё

те это можно сделать динамически не меня дату?

Напиши лучше, что ты хочешь сделать. Где тебе нужны эти данные в конечном итоге, где ты будешь их использовать.

Если на веб-странице, например, то нет никакого смысла обновлять данные в самих записях, тебе нужен скрипт.

Все оказалось намного проще чем я думал SELECT *, (SELECT SUM(count) FROM tmp_res WHERE bdate <= t.bdate) FROM tmp_res as t;

Для каждой даты прибавить сумму предыдущих. К примеру 1434 1434 + 1435 1434 + 1435 + 1436

window functions, если и есть, то только в восьмерке

select user_models.*, count(user_id) as count_messages from chat_logs left join user_models on user_models.id = user_id where chat_id = 2 group by user_id order by count_messages desc Как такое чудо можно оптимизировать? Запрос считает кол-во сообщений юзера в чате. Профайлер говорит что самая затратная операция "Copying to tmp table"

Проблема по всей видимости в count и group by

Explain запроса

Если есть возможность, то лучше такое хранить в доп колонке в юзерах, т.е. сразу аггрегированное знажение.

При росте базы все равно придется так делать.

Хотя зависит от объема

Для начала - индексы в порядке?

джойнить-то зачем

Видно, что тянется инфа из юзеров

ну и здесь-то зачем ее тянуть

давайте сделаем громадную промежуточную таблицу, а потом начнем ее фильтровать и считать

Для начала - индексы в порядке?

Да, с индексом стало в несколько раз быстрее, но всё ещё медленно

Скорее всего для вывода Юзер1: 1555 Юзер2: 1200 ...

Скорее всего для вывода Юзер1: 1555 Юзер2: 1200 ...

да серьезно что ли

да серьезно что ли

Предлагай решение, а не просто критикуй

имена трех с половиной калек легко возвращаются вторым запросом по конкретным айдишникам, не говоря уж о том, что изврат с подзапросом наверняка сделает все гораздо лучше и позволит джойнить с уже готовым результатом, а не со всей таблицей

ооо боги

кто-то еще апеллирует к сперва добейся

Понятно, что лучше хранить количество сообщений в отдельном поле.