@Zhenya1243

SELECT x FROM таблица с огромными полями. Создать ли отдельную таблицу с x для оптимизации?

Всем привет, ситуация такая.

На сайте с книгами есть таблица chapters с полями book_id (ключ на другую таблицу), chapter_title (название главы), chapter_text (текст главы).

Проблема в том, что поле chapter_text может содержать огромное количество символов, вплоть до нескольких мегабайт!

Так вот, много где используется запрос SELECT title FROM book_chapters WHERE book_id = XYZ ORDER BY id исключительно для того, чтобы получить и вывести список глав конкретной книги, но сами тексты этих глав не нужны, поэтому я исключил из выборки select то самое гигантское поле текста .

Я где-то читал, что, когда ищется в строке с большим размерами, то требуется больше оперативной памяти и больше времени, даже несмотря на то, что я ограничил SELECT легкими полями.

Поэтому может лучше выделить отдельную таблицу для хранения текста? То есть, может лучше разделить эту таблицу на
легкую
chapter_title (id, book_id, title)
и огромную
chapter_text (chapter_title_id, chapter_text).

И в итоге для получения списка глав нужно лишь делать запрос к одной очень легкой таблице book_chapter! А к таблице с текстом делать запрос только тогда, когда человек читает.

На данный момент я не замечаю каких-то проблем, ищется по времени нормально, но мало ли, когда народу много, и когда просматривается много тяжелых книг, сайт переодически подвисает из-за этого, а я не в курсе (я совсем не шарю в мониторинге и профайлинге да и в администрировании в целом, только в программировании.)
  • Вопрос задан
  • 112 просмотров
Пригласить эксперта
Ответы на вопрос 2
402d
@402d
начинал с бейсика на УКНЦ в 1988
Надеюсь индекс (id,book_id, title) у Вас построен ?
Если да и оперативки достаточно, чтобы он целиком оставался в ОЗУ, то
запрос select id,book_id,title выполняется без обращения к диску. Если памяти маловато, то перечитавает с диска только файл индекса.

А вот для индекса только по book_id будет читать и основной файл.

А так ваше предположение сделать кей - валуе хранилище для блобов вполне правильное.
Будет прекрасно работать по первичному ключу.

Но думаю пока дробить нет смысла. Просто пишите код так, чтобы потом можно было легко переделать.
Н-р заведите две константы с одинаковым пока значением
TABLE_CHAPTERS_INFO и TABLE_CHAPTERS_TEXT

А разнесете их физически, после того как захотите добавить еще какие-то поля помимо титла. Н-р размер в байтах и / или листах, дату обновления
Ответ написан
@Zhenya1243 Автор вопроса
Хм, кажется нашел ответ на свой вопрос вот тут https://stackoverflow.com/questions/13760998/store.... Если есть возможность включить такой параметр innodb_file_format=barracuda, то нет смысла отделять большие тексты в отдельные таблицы - их БД сама уже там будет хранить. Поэтому главное в select просто надо не указывать эти большие поля. Надеюсь, я все правильно понял )
Ответ написан
Ваш ответ на вопрос

Войдите, чтобы написать ответ

Войти через центр авторизации
Похожие вопросы