Добрый день, не хочу ошибиться на начальном этапе, помогите плиз

Есть новостной сайт
Объем таблицы новостей - 1,5 млн записей.
Сайт довольно нагруженный

переделываем структуру базы

Я хочу разбить таблицу с новостями на две

news - хранится только НЕ вариативная информация (дата новости, количество просмотров, author_id, rubric_id и т.д.)
news_articles - хранится заголовок, тело новости и т.д., а также news_id (связь с таблицей news)

Таблицу news шардирую по createdAt (т.к. в каждом запросе будет order по дате)
Таблицу news_article шардирую по Id

На главной странице для формирования ленты последних новостей делаю выборку по news, выбираю множество id пусть с limit 50, а для получения заголовков выполняю второй запрос (SELECT header FROM news_articles WHERE news_id IN (множество полученых id в прошлом запросе)))

Запрос получения id из таблицы news формируется динамически. Т.е. мне нужно выбрать id по какой-то определенной рубрике, либо для другого блока только с комментариями, в третьем блоке сортировать по дате, а в четвертом - по просмотрам
Вычитал, что такая таблица должна быть без вариативных полей, для максимальной выборки.


ВОПРОСЫ
1) Насколько так правильно делать? Хочется добиться максимальной производительности
2) По такому принципу хочу формировать все блоки на главной, смущает, что news_id IN (...) может быть много параметров - до 50 или даже 100, т.е. news_id IN (?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?,?...) Это не проблема?
3) Может посоветуете более оптимальные варианты
4) Чтоб не выполнять второй запрос можно header вставить в news, но это varchar. Я так понимаю сразу упадет производительность, т.к. это вариативное поле, да и объем таблицы сразу существенно возрастет.

спасибо за ответ
меня не пугает количество таблиц, меня больше интересуют те вопросы о которых я спросил, особенно 2 и 4

как-то уходим в глубокую теорию.

Я постарался расписать задачу, которая стоит, а также исходные данные и вариант своего решения (своей структуры основной таблицы).
Меня интересует нормально ли такое решение

Melkij, о, спасибо уже по делу.

Да кеширование будет, это уже другой вопрос
Вы говорите, что не видите смысла разделять таблицы.

Т.е. тексты материалов, заголовки и служебную информацию (дата новости, id рубрики и т.д.) хранить в одной таблице? Сейчас они как раз и хранятся в одной таблице. я и хочу их вынести отдельно. Вот только нужно ли выносить заголовки или varchar можно оставить

автороптимальный вариант - нанять разработчика бд.

авторты понимаешь неправильно.

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

Спасибо. Рад, что есть адекватные люди.

Я бы тоже не хотел ничего разбивать. (сейчас полная версия таблицы занимает больше 7Гб)
Если сделать правильные индексы, то все работает шустро, но есть один косяк по такой таблице - это 100500 страница в навигации

LIMIT 100500, 10

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

Посоветуйте как быть с запросом по такой таблице:
SELECT n.header FROM news as n WHERE n.rubric_id=4 ORDER BY n.create_at DESC LIMIT 100500, 10