я бы назвал это элементарным математическим расчётом
для одноразовой операции 10 минут написания запроса + 14 часов выполнения его без моего вмешательства выиграли у 1-2 дней написания скрипта + непрогнозируемого времени удаления этих же полумиллиарда строк=)
Stierus
архивная БД и актуальная не идентичны по полям. может, я не совсем верно их обозвал, но смысл следующий - в актуальной в основной таблице около 20 столбцов ещё куча связанных таблиц, туда вытягиваются данные определённые из нужных сессий. в основной таблице дублирующихся сессий нет. Архивная БД сохраняет ВООБЩЕ ВСЁ, что мне шлют в сессиях, а это - произвольное количество полей. потому в таблице с одним id_session может быть 20-150 строк.
В прочем, пока я это писал, до меня дошло, что можно сделать группировку по id_session и получится применить ваш скрипт
другой вопрос - выгрузка данных + проход скриптом + загрузка результата в БД будет быстрее, чем
Кросс-БД запросы будут работать крайне медленно почти всегда.
Скопируйте имеющуюся таблицу с актуальными данными в архивную БД и сделайте через JOIN (приведу пример - если я правильно понял какая таблица - архивная, а какая - актуальная. Поменяете местами, если не так)
id_session(INT)| id_counter(INT)| value(BIGINT OR TEXT)
на мой взгляд(сейчас) не самая удачная конструкция, но ... такая уж есть=)
есть другая база данных (с актуальной информацией), в которой есть таблица, хранящая актуальные данные по сессиям.
Необходимо - удалить из архивной БД все записи с id_session, которых нету в актуальной базе данных.
мне знаний хватает только на то, чтобы родить следующий запрос
WHERE id_session NOTIN(SELECT id_session FROM db2.table1)
а ещё я знаю, что подобный запрос у меня будет работать до китайской пасхи=)
В связи с этим два вопроса
- как MySQL оптимизирует подобный запрос и где об этом почитать?
- есть ли конструкции, которые помогут ускорить выполнение требуемой задачи? (Добавление)
можно, кстати, сначала найти id_session, которых нету в актуальной БД, поместить их в темповую БД и удалять уже, используя IN вместо NOT IN
подозреваю, что это ускорит работу, но не колоссально=(
тоже не знаю, возможно ли. если не ошибаюсь, проверить существование результата можно только ПОСЛЕ отработанного запроса. так что, как мне кажется, придётся делать в два запроса с условием либо в PHP, либо в процедуре
кстати, советовал бы завести отдельную табличку, где хранить количество slug для каждого пользователя и при добавлении в таблицу slug нового значения(или удаления) инкрементировать счётчики в этой статистической таблице.
да я знаю, чем отличается статическое свойство от динамического. и статический метод от динамического.
всё, что меня сейчас удивило - это то, что в документации нету упоминания о возможности вызова статического метода через экземпляр класса. и то, что о вызове статических свойств и методов через static:: можно узнать только из комментариев(хотя, может, плохо искал.)
и то, что это возможно, не говорит о том, что я брошусь везде это использовать., безумно хохоча и размахивая руками. просто удивление вызвало, а мне тут уже объясняют про существующие утверждения, когда и как надо делать. (без, кстати, указания, где эти утверждения написаны).
Есть четкое разделение, когда как нужно делать - так и делайте
когда есть чёткое разделение, о нём обычно пишут в документации. точно так же, как и о доступных, но не рекомендованных или устаревших способах.
В данном случае в документации этот момент опущен(как мне кажется), что и удивляет.
Главная
Помощь
Поиск
Пользователи
Найдено сообщений: 92
