- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Что делать, если ваша email-рассылка попала в спам
10 распространенных причин и решений
Екатерина Ткаченко
Там id непрерывны? Может так сделать (индекс по id будет задействован):
WHERE id>=513500 AND id<513600 ORDER BY id ASC
Скорее всего, этот запрос нормально работает
Маловероятно.
---------- Добавлено 28.08.2013 в 15:52 ----------
Там id непрерывны? Может так сделать (индекс по id будет задействован):
WHERE id>=513500 AND id<513600 ORDER BY id ASC
Смотрите запрос без where. Там такая же картинка. Индексы не используются не из-за запроса, причина более глобальная.
WapGraf, нет, в запросе без where картина вообще другая. Там то понятно почему все строки перебираются.
Если хочется докопаться до истины, нужно делать как тут уже подсказывали:
Это проверяется и без slow log:
flush status;
select ...тут наш запрос...;
show status like 'Handler_read_%';
Да я знаю как себя ведет мускул при использовании limit. Но Using filesort не должно быть при этом все равно!
Даже проверил у себя на большой таблице, может я чего забыл, но таки нет. Ничего нормального тут нету при наличии ключа. Тут явно не работает индекс. Другой причины, кроме как отсутствие возможности быть из-за кривых параметров мускула, я не вижу.
WapGraf, изначально было с WHERE и тоже медленно работало, потом ТС зачем-то полез выдумывать эквивалентные по результатам запросы без WHERE и еще больше ухудшил ситуацию теперь уже явно плохими планами, а вы их зачем-то начали обсуждать. Не надо так (c)
Ещё можно попробовать индексы перестроить (может занять некоторое время.. по возможности делать ночью когда все спят когда нет посетителей)
Как вариант - скопировать в другую таблицу.
WapGraf, изначально было с WHERE и тоже медленно работало, потом ТС зачем-то полез выдумывать эквивалентные по результатам запросы без WHERE и еще больше ухудшил ситуацию теперь уже явно плохими планами, а вы их зачем-то начали обсуждать. Не надо так (c)
Может и не надо, но сути это не меняет. Индекс должен использоваться (если есть где ему хранится), а не используется. Здесь вины клиента нету, это хостера забота.
---------- Добавлено 28.08.2013 в 20:30 ----------
Ещё можно попробовать индексы перестроить (может занять некоторое время.. по возможности делать ночью когда все спят когда нет посетителей)
Как вариант - скопировать в другую таблицу.
Если не ошибаюсь, то при таком размере таблицы на джино сработают лимиты.
WapGraf, так план же показывает, что индекс используется. о чем тут еще хостеру заботится ?
netwind, сгенерируйте табличку на пару млн. записей сделайте пару выборок, выполните explaine и получите filesort. После оптимизируйте мускул, выполните explaine повторно и никакого filesort не будет.
А filesort это что? Тормоза, нагрузка и т.д.
WapGraf, решили меня перенудить? не получится. где тут в оригинальном запросе filesort ?
Отличный план с использованием индекса. Только прогноз rows не правильный. Но это просто особенность mysql.