- Поисковые системы
- Практика оптимизации
- Трафик для сайтов
- Монетизация сайтов
- Сайтостроение
- Социальный Маркетинг
- Общение профессионалов
- Биржа и продажа
- Финансовые объявления
- Работа на постоянной основе
- Сайты - покупка, продажа
- Соцсети: страницы, группы, приложения
- Сайты без доменов
- Трафик, тизерная и баннерная реклама
- Продажа, оценка, регистрация доменов
- Ссылки - обмен, покупка, продажа
- Программы и скрипты
- Размещение статей
- Инфопродукты
- Прочие цифровые товары
- Работа и услуги для вебмастера
- Оптимизация, продвижение и аудит
- Ведение рекламных кампаний
- Услуги в области SMM
- Программирование
- Администрирование серверов и сайтов
- Прокси, ВПН, анонимайзеры, IP
- Платное обучение, вебинары
- Регистрация в каталогах
- Копирайтинг, переводы
- Дизайн
- Usability: консультации и аудит
- Изготовление сайтов
- Наполнение сайтов
- Прочие услуги
- Не про работу
Авторизуйтесь или зарегистрируйтесь, чтобы оставить комментарий
Запрос:
В таблицу ~700k строк.
Имеется индекс по толбцу 'num'.
Играясь со значениями параметром LIMIT, обнаружил что если задать LIMIT 100000,20 то Mysql не использует индекс для этого запроса, в следствии чего запрос получается очень долгим.
Объясните, пожалуйста, почему так происходит?
А мускуль то какой версии?
Есть дока по мускуль 5 вот тут http://mysql.ru/docs/man/MySQL_indexes.html
Там внизу написано, может подойти под ситуацию:
- Если использование индекса требует от MySQL прохода более чем по 30% строк в данной таблице (в таких случаях просмотр таблицы, по всей видимости, окажется намного быстрее, так как потребуется выполнить меньше операций поиска). Следует учитывать, что если подобный запрос использует LIMIT по отношению только к извлекаемой части строк, то MySQL будет применять индекс в любом случае, так как небольшое количество строк можно найти намного быстрее, чтобы вернуть результат.
- Если диапазон изменения индекса может содержать величины NULL при использовании выражений ORDER BY ... DESC.
А мускуль то какой версии?
5
Есть дока по мускуль 5 вот тут http://mysql.ru/docs/man/MySQL_indexes.html
Там внизу написано, может подойти под ситуацию:
Не, ни то ни другое не походит.
в следствии чего запрос получается очень долгим.
Потому что индекс используется только для сортировки, а для выборки 20 строк, начиная со 100000-й, ему нужно перелопатить эти 100000 строк.
В данном случае можно либо добавить колонку, записать в неё номера строк по порядку, проиндексировать и делать выборку с помощью WHERE row_id>=100000 AND row_id<100020, либо кэшировать результат.
А двиг-то какой у MySQL? И 5-х версий много...
Покажи результат EXPLAIN, SHOW CREATE TABLE, а потом уже будут конкретные советы.
Для совсем уж конкретных советов, лучше выложить дамп тестовых данных и запросов, где проблема воспроизводится.
А двиг-то какой у MySQL? И 5-х версий много...
InnoDB
Покажи результат EXPLAIN, SHOW CREATE TABLE, а потом уже будут конкретные советы.
Для совсем уж конкретных советов, лучше выложить дамп тестовых данных и запросов, где проблема воспроизводится.
CREATE TABLE `log_search` (
`id` mediumint(6) unsigned NOT NULL AUTO_INCREMENT,
`name` tinytext NOT NULL,
`count` smallint(7) unsigned NOT NULL,
`type` tinyint(1) unsigned NOT NULL,
`sm` tinyint(1) unsigned NOT NULL,
PRIMARY KEY (`id`),
KEY `ft_name` (`name`(40)),
KEY `IND_COUNT` (`count`)
) ENGINE=InnoDB AUTO_INCREMENT=804264 DEFAULT CHARSET=cp1251
Можешь попробовать поиграть в USE INDEX/FORCE INDEX, но не обязательно это ускорит запрос.
Скорее всего распределение по этому индексу неравномерное. Например в конце, если двигаться по порядку count DESC ( и зачем называть поля зарезервированным словом COUNT ?), много одинаковых значений count.
Одними индексами и запросами тут ничего не сделать. Нужно пересмотреть условия задачи. Например, добавить еще одно поле - порядок. Там уже зависит от предметной области. И вообще кому и зачем понадобилось листать до 100000-ой записи, если они там все одинаковые по полю count ?