- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Переиграть и победить: как анализировать конкурентов для продвижения сайта
С помощью Ahrefs
Александр Шестаков
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Miracle, представь, что бы выдал этот запрос не будь в нем LIMIT, DISTINCT и GROUP BY.
Наверняка у тебя там неправильно пересечение кучи строк N с еще большей кучей M, что в JOIN в результате даст N*M строк.
Для защиты от ошибок и чтобы не перегрузить сервер и сделан этот лимит.
Miracle, представь, что бы выдал этот запрос не будь в нем LIMIT, DISTINCT и GROUP BY.
а зачем? что бы увидеть масштабы?
Наверняка у тебя там неправильно пересечение кучи строк N с еще большей кучей M, что в JOIN в результате даст N*M строк.
как это проверить, буду признателен за подсказку
Miracle добавил 03.02.2011 в 01:52
вот к примеру, то что у меня выполняется дольше остального
я не увидел здесь особых нюансов.
Miracle, ты определись выполняется или получаешь ошибку. Я только ошибку имел ввиду.
покажи еще show variables like '%max_join%';
max_join_size 1 000 000
sql_max_join_size 1 000 000
Miracle добавил 03.02.2011 в 09:16
Miracle, ты определись выполняется или получаешь ошибку. Я только ошибку имел ввиду.
ошибка возникла один раз. я не знаю как увидеть где была ошибка.
правда при выходе в бд при обращении к таблице комментов она была постоянно пока не заблокировал доступ к серверу.
я не знаю как увидеть где была ошибка.
Сделай так, чтобы знал. Или ты думаешь что на форуме угадают? Выводи при возникновении ошибки сам запрос.
Значение конечно маленькое, но может так и было задумано при настройке сервера.
По-умолчанию там 18446744073709551615.
на нагруженном проекте подобное было, я добавил в начало, там где подключение, просто:
$db->do('SET SQL_BIG_SELECTS=1');подробности уже не помню... может ошибаюсь...
в конфиге MySQL, в my.cnf можно это выключить, в новой верси, вродебы
а зачем? что бы увидеть масштабы?
как это проверить, буду признателен за подсказку
Miracle добавил 03.02.2011 в 01:52
вот к примеру, то что у меня выполняется дольше остального
я не увидел здесь особых нюансов.
Очень странно. Явных косяков не видно. По сколько записей в каждой таблице у вас? Вы уверены, что именно этот запрос создаёт проблемы с MAX_JOIN_SIZE? Уж тем более неясно, почему ошибка то есть, то её нет. Косяк где-то в другом месте. Думаю, вам стоит стукнуться к хостеру.
Часто проблемы с MAX_JOIN_SIZE бывают, когда объединяется более 2-х таблиц и неправильно указаны условия в WHERE и в итоге реально объединение может быть очень и очень MAX_JOIN_SIZE. А при объединении 2-х таблиц, да ещё с ограниченным числом записей в каждой, проблем быть вроде как не должно.
Хотя... второй запрос что-то меня пугает. В нём уже 3 таблички. Так по сколько записей у вас в таблицах? Просто WHERE не прокатит? Обязательно через LEFT JOIN?
на нагруженном проекте подобное было, я добавил в начало, там где подключение, SET SQL_BIG_SELECTS=1
и нагрузил его еще больше. ай, малацца.