- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу

Все что нужно знать о DDоS-атаках грамотному менеджеру
И как реагировать на "пожар", когда неизвестно, где хранятся "огнетушители
Антон Никонов

В 2023 году 36,9% всех DDoS-атак пришлось на сферу финансов
А 24,9% – на сегмент электронной коммерции
Оксана Мамчуева
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
И так, есть таблица. Для рассылки используется.
1 500 000 записей сейчас.
Вот структура:
Запрос
Выполняется 0,0001 сек.
Выполняется 0,4 сек.
А если я добавляю туда LEFT JOIN чтобы сразу получить данные самой рассылки, то время выполнения прыгает до 19 секунд.
1,5млн это перебор для MySQL MyISAM или както по другому нужно реализовать?
Выполняется 0,4 сек.
А если индекс по двум полям: `send`, `id_subs`?
А если я добавляю туда LEFT JOIN
Смотря по чему JOIN-ить..
А если индекс по двум полям: `send`, `id_subs`?
Помогло, сенкс. Сейчас проверю с JOIN
---------- Добавлено 08.11.2019 в 07:49 ----------
С JOIN все равно долго, 2 секунды. Но уже быстрее правда.
Здравствуйте.
Для решения проблемы:
- Сделайте бэкап БД (опционально, но крайне рекомендовано).
mysqldump -u root -pPASSWORD DB_NAME > ./DB_NAME.sql
- Проиндексируйте таблицу с которой работаете и проверьте результат.
Lord Maverik,
Джоин в идеале должен делаться по столбцам одинакового типа. У Вас id mediumint(9), а id_subs smallint(5).
В джоине Вы используете на одно условие where больше чем в изначальных запросах (actv), при чем оно из присоединяемой таблицы, поэтому ситуация отличается от первого запроса, базе приходится сначала джоинить в любом случае.
Важна ли сортировка по id_subs ? Как мы понимаем рано или поздно все рассылки должны быть посланы, есть разница с какой начинать?
Если можно изменять структуру таблиц, то мы бы избавились от текстовых полей в таблицах по которым идет where и sort by, таблицу с текстом можно заджоинить в самом конце.
Если нельзя изменять структуру, то можно попробовать сделать запрос на выборку нужных id, при некоторой удаче они возьмуться из индексов не трогая саму таблицу, а потом уже выбирать остальные данные к ним.
Важна ли сортировка по id_subs ? Как мы понимаем рано или поздно все рассылки должны быть посланы, есть разница с какой начинать?
Тут все верно, не так уж и важно. Но я пробовал убирать сортировку, не влияет.
Джоин в идеале должен делаться по столбцам одинакового типа. У Вас id mediumint(9), а id_subs smallint(5).
Не помогло, но спасибо, буду иметь такие вещи в виду, чтобы поля были идентичны.
то мы бы избавились от текстовых полей в таблицах по которым идет where и sort by,
Такой запрос, убрал order и все текстовые поля вообще
Тоже выполняется долго, 3 секунды.
EXPLAIN запроса делали?
Да делайте двумя отдельными запросами и ну его нафиг. ;)
EXPLAIN запроса делали?
К сожалению, не умею этим пользоваться, хз о чем это говорит.
Да делайте двумя отдельными запросами и ну его нафиг.
Да вот уже тоже к этому склоняюсь )
Я немного туплю, но можете объяснить для чего там LEFT JOIN? У вас в cms_subscribe_temp есть записи, которых нет в cms_subscribe и вы хотите сделать рассылку по тем, кто не подписался?