тяжелый запрос?

Всем привет, есть таблица textbooks размером 1.1 гигабайт
К ней обращаются по такому запросу
select id, title from texbooks where book_id = 112233 and status = 1 order by id desc

индекс стоит на поле book_id.

В последнее время бд начала нехило тормозить, ищу проблему, а этот запрос начал тормозить 1-2 секунды выполнения, вот и решил его исследовать.

должен ли такой запрос выполнятся долго? можно ли как то улучшить запрос?

я думаю, что этот запрос не должен выполнятся долго. вроде, бд должна сначала должна вытащить записи по запросу where book_id = 112233 т.к. на нем индекс, то есть быстро, и по полученным записям сделать вторую выборку status = 1 и их отсортировать order by.

или status = 1 заставит БД пройтись по всей таблице??
БД mysql

explain?
Сколько в таблице записей с таким book_id? Сколько из них с status = 1?

-----
PostgreSQL DBA

По разному. в textbooks хранятся главы книг с текстом, у книги может быть одна глава, а то и 50. Ну в среднем 15 записей по определенному book_id/

Я перепутал, status = 0. Это означает глава не удалена, удаленных глав почти нет, но изредка главы удаляются, поэтому и запрос такой. Так что, очень мало. в 99% случаев status = 0, 1% status = 0.
(Добавление)
может быть проблема в том, что я неправильно организовал все...

Таблица textbooks содержит столбцы id, title (название главы), text_of_chapter (сам текст главы, иногда там хранится 1мб текста),status.

Запросом, который я привел выше, я просто вытаскиваю оглавление (нужны только title), но не текст. Наверно надо будет эту таблицу разбить на две таблицы: главы; текст главы.
Прикреплено изображение (Нажмите для увеличения)

(Отредактировано автором: 18 Октября, 2016 - 20:02:03)

Адекватно.
Производительность доступа к случайной главе по прямому id нормальная?
Что говорит профилировщик, на что субд затрачивает время? https://dev[dot]mysql[dot]com/doc/refman[dot][dot][dot]how-profile[dot]html И там же, профайлер io.

-----
PostgreSQL DBA

в phpmyadmin использовал Profiler
по id запрос выполняется быстро.
sorting result 1.9 s
Вообщем, проверил 10 запросов, затраты на sorting result составляют почти все время (от 0.1 сек до 2 сек). Почему же так долго, может потому большой объем извлекается? некоторые главы в сумме составляют мегабайт текста.
наверно придется отказаться от order by, а сортировку делать средствами php.
есть ли способы это улучшить?
Прикреплено изображение (Нажмите для увеличения)

(Отредактировано автором: 18 Октября, 2016 - 21:44:02)

Это с text полем или без него? В теме уже фигурировали оба запроса, но между ними серьёзная разница.
Для text ещё объяснимо, сортировка датасета с text - это всегда дисковая сортировка. А без него - запрос должен нормально жить.

-----
PostgreSQL DBA

ох, точно, тестировал на select * from..., совсем забыл про поля. сам текст не нужен. Стало 0.2 - 0.4 сек - и это тоже на сортировку все время ушло.
Странно, утром и днем наблюдал, что почему то эти запросы были очень долгие 1-2 секунды, и пользователи в последнее время стали жаловаться, что сайт часто начал висеть. Буду искать далее слабые места, спасибо, что помогли, профайлер - вещь, не знал о нем

Можно воткнуть индекс book_id & status. С учётом неявной ссылка на PK в innodb получится отличный index scan, включая сортировку.

-----
PostgreSQL DBA