![](data:image/svg+xml;charset=utf-8,<svg width="640" height="640" style="background-color:%2344badc;font-family:Nunito,sans-serif" viewBox="0 0 100 100" preserveAspectRatio="xMidYMid meet" xmlns="http://www.w3.org/2000/svg">
<text font-size="30" x="50%" y="50%" dy="5" fill="white" dominant-baseline="middle" text-anchor="middle">WS</text>
</svg>)
Database для affiliate-сайта на миллион страниц: схема, которая не душит сервер
Для сетки с большим количеством страниц база ломается не от «миллиона записей», а от плохих запросов. Рабочий минимум: отдельный MySQL/MariaDB-сервер, строгие индексы, object cache и вынесенный full-text поиск наружу, если он реально нужен.
Что держать в базе:
— только контент, метаданные, статусы, связи;
— без тяжёлых расчётов при каждом запросе;
— без выборок по `LIKE '%keyword%'` на больших таблицах;
— без автозапуска дорогих cron-задач внутри веб-запроса.
Что ускоряет:
— composite index под реальные WHERE/JOIN, а не «на всякий случай»;
— persistent object cache через Redis;
— read-heavy трафик — через реплики, если архитектура уже выросла;
— кэширование готовых страниц или фрагментов, если страницы шаблонные;
— отдельная таблица под часто фильтруемые поля, если постов много.
Если сайт на WordPress, не превращай `postmeta` в свалку. Именно она обычно убивает TTFB: десятки JOIN'ов, мета-запросы, сортировка по неиндексированным полям. Лечится переносом критичных атрибутов в нормальные поля, чисткой плагинов и проверкой `EXPLAIN` для каждого тяжёлого запроса.
Финал простой: сначала режь число запросов и только потом покупай более жирный сервер. Хорошая схема БД для affiliate-сайта — это не «мощнее железо», а меньше случайных чтений, правильные индексы и кэш на каждом слое.
Для сетки с большим количеством страниц база ломается не от «миллиона записей», а от плохих запросов. Рабочий минимум: отдельный MySQL/MariaDB-сервер, строгие индексы, object cache и вынесенный full-text поиск наружу, если он реально нужен.
Что держать в базе:
— только контент, метаданные, статусы, связи;
— без тяжёлых расчётов при каждом запросе;
— без выборок по `LIKE '%keyword%'` на больших таблицах;
— без автозапуска дорогих cron-задач внутри веб-запроса.
Что ускоряет:
— composite index под реальные WHERE/JOIN, а не «на всякий случай»;
— persistent object cache через Redis;
— read-heavy трафик — через реплики, если архитектура уже выросла;
— кэширование готовых страниц или фрагментов, если страницы шаблонные;
— отдельная таблица под часто фильтруемые поля, если постов много.
Если сайт на WordPress, не превращай `postmeta` в свалку. Именно она обычно убивает TTFB: десятки JOIN'ов, мета-запросы, сортировка по неиндексированным полям. Лечится переносом критичных атрибутов в нормальные поля, чисткой плагинов и проверкой `EXPLAIN` для каждого тяжёлого запроса.
Финал простой: сначала режь число запросов и только потом покупай более жирный сервер. Хорошая схема БД для affiliate-сайта — это не «мощнее железо», а меньше случайных чтений, правильные индексы и кэш на каждом слое.