- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
У меня на стандартном форумном движке выскочила ошибка
SELECT would examine more than MAX_JOIN_SIZE rows
Запрос простой:
если уменьшить количество forum_id и написать IN (4, 5, 6, 7, 8), то ошибка пропадает.
В таблице pb_topics меньше 100 строк, MAX_JOIN_SIZE установлен как 50 000 000. Я установил для этого запроса SQL_BIG_SELECTS=1, чтобы эта ошибка не выскакивала, но мне просто интересно, как сервер MySQL планирует такой запрос? Никогда не влезал глубоко в этот механизм, и просто не понимаю, каким образом из таблицы в 100 строк при простой выборке по совпадающим полям можно спланировать получение 50 миллионов строк?
Какая версия Mysql и в каком формате БД?
Вызывает тоже самое?
А если без COUNT будет так же ошибка?
Какая версия Mysql и в каком формате БД?
MariaDB 10.5.12, таблицы InnoDB.
COUNT(*) даёт ту же ошибку. Без COUNT тоже.
MariaDB 10.5.12, таблицы InnoDB.
COUNT(*) даёт ту же ошибку. Без COUNT тоже.
Отлично, теперь уменьшайте количество forum_id и без COUNT смотрите, что вам выводит БД. Если там меньше 100 строк то никаких проблем, если будет больше, значит что-то не так где-то.
Отлично, теперь уменьшайте количество forum_id и без COUNT смотрите, что вам выводит БД. Если там меньше 100 строк то никаких проблем, если будет больше, значит что-то не так где-то.
Не так там что-то в планировании запроса, сервер как-то странно пытается "предвидеть" результат.
Запрос
выдаёт ту же ошибку, а запрос
или запрос
завершаются успешно, и выдают результат 0 строк.
Смотрим, что будет.
Последний запрос убираем
Смотрим, что будет.
Будет какая-то мистика.
Если убрать последний запрос, будет всё без ошибок, выдаётся правильный ответ, все строки таблицы.
Без ошибок также следующие варианты:
AND topic_visibility IN (0)
AND topic_visibility IN ( 3)
AND topic_visibility IN (1, 3)
AND topic_visibility IN (0, 3, 1)
AND topic_visibility IN (0, 1)
А варианты
AND topic_visibility IN (0, 2)
AND topic_visibility IN (0, 3)
AND topic_visibility IN (0, 4)
дают ошибку.
Вообще у меня плохие воспоминание об 10.5 у меня она один запрос вообще не выполняла, а тупо зависала.
Вот и у меня такое впечатление, что это какой-то баг.
Вот и у меня такое впечатление, что это какой-то баг.
А если без IN просто AND и OR?
А если без IN просто AND и OR?
Вроде бы сервер всё равно преобразует IN() в OR (или хз какая там кухня).
Но проверил.
Та же фигня. Та же ошибка. Меняем 3 на 1 или 0 на 1 – ошибка пропадает.