landergate: в случае с in - получим записей максимум по числу элементов в запросе, в not in все кроме запроса. Разница в порядки. In - по ключу, not in - фулскан
landergate: и что в того? Он фулсканом будет ходить по нему и добавлять в ответ все что не совпадает со списком id. Число проверок будет равно числу строк* числу элементов в запросе.
В кроне поставить в 23:50 заполнение нулями счетчиков на следующие сутки. У меня такой проблемы не было, так как почти всегда js плагин графика при отсутствии значения в массиве на дату/ключ равняет его в нуль или просто прерывает график.
synapse_people: если у Вас число записей на миллионы, а подсчет сумм в кабинете для статистики занимает много времени, тормозит бд и т.п., то лучше оптимизировать.
Кстати, не отменяет того факта, что можно делать 2 записи. Причем основную в бд статистики, а с составным ключем запись создавать через триггер.
synapse_people: У Вас и будет в реальном времени, но сама операция суммирования вынесена в запрос вставки. Фактически при квантизации статистики по суткам глупо хранить все факты переходов, если это не нужно. Если данные в бд пишутся из принципы "сохраним все, а потом пригодится", то лучше в отдельный таблицы выносить, делать индексы и вычищать данные которые уже не нужны из основных таблиц.
mozart1337: да, так и есть. На деле проще мониторить нагрузку по факту и юзать контейнеры. Всегда можно будет раскидать по серверам иным все в процессе роста нагрузки
