Здравствуйте, Konstantin, Вы писали:

K>А если делать выборки уже ближе к концу таблицы, то просто караул как долго. Вот типа такой запрос:
K>

 SELECT * FROM `table` LIMIT 799000 , 1000

K>(...Query took 149.6909 sec)
K>Подскажите, как ускорить это дело ? Вроде же должно быть примерно с такой же скоростью ?

В конце таблицы с такой же скоростью как и в начале такой пейджинг работать не должен и не будет, ведь он в общем случае должен обработать все строки — от первой (в порядке сортировки) строки таблицы и до последней строки отображаемой страницы пейджинга.

Тем не менее во многих случаях такой запрос пейджинга "в лоб" можно ускорить специально для доступа к страницам "в конце" таблицы немного переписав его.
Запрос разбиваем на две части. Первая — простой пейджинг как и раньше, но мы выбираем не все поля (select * ...), а только первичный ключ (select ID ...). Во второй части — уже отобранный после пейджинга список ID (их будет столько, сколько записей мы отображаем на одной странице, т.е. где-то десятки-сотни) мы джойним с основной таблицей и уже из нее выбираем полные строки со всеми нужными полями. Join здесь скорее всего должен быть типа nested loops с внутренним циклом по индексу первичного ключа основной таблицы.

Схематично запрос выглядит так:

select * from table // здесь получаем полные строки
inner join
(
    select ID from table // получаем только первичный ключ
    where .... // все фильтры также указываем во внутреннем запросе
    order by ... // пейджинг без сортировки - некорректен
    limit ... // здесь же пейджинг
) IDs
    on table.ID = IDs.ID // nested loops