Файлы там, база там...

А если взять, например, 1 дедик не дорогой или мощный ВДС, но чтобы всё деражть в одном месте?

С точностью до наоборот у нормального провайдера всегда база будет на отдельном сервер. Это очень сильно экономит ресурсы хостинга в целом и работу сайта в частности. Это тоже хороший способ отличить хостера от школохостера.

Очень спорно. База может находится на отдельном сервере, а оговариваемая ТС нагрузка, является нагрузкой, которую создает только сайт на cgi сервере.

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

Позволю себе с вами немного не согласиться, я начинал в 2005 году работать как раз с такой схемой как вы говорите были хостинг сервера и были mysql сервера отдельно, т.е на хостинге баз не было вообще, система приятная и конечно облегчает жизнь веб серверу, но реально больше проблем возникает когда надо прочекать базы, а реально на сервер обращаются с 4-5 других...... т.е фактически из за проблемы с одной базой или от проблем с sql сервером страдало 4-5 хостинг серверов...... По этому такое решение в виде решения по умолчанию мы больше не используем.... Но конечно же , если у вас высоко посещаемый сайт он один и одна база, надо разносить на разные сервера\впс... Тут перераспределение ролей (не думаю, что это экономия) - что дает дополнительную точку отказа, в частности это момент связи веб сервера с базой через сегмент сети. Все относительно :D

1. Включить кеширование скриптом.

2. Попробовать хостинг, позволяющий выдержать приличную нагрузку. Как минимум попробовать. Beget, hts - там есть тестовый период. Тему про Гигахост соседнюю покурите, если удастся настроить их кеширующую систему - вообще всё решится за 129 рублей в месяц. С Джумлой вроде оно работает, как они говорят.

Я начинал в 2001. Рекорд работы без перезагрузок сервера базы данных более 2 лет. Чекание таблиц базы влияет конкретно на каждую чекающиюся таблицу в данный конкретный момент времени. Если у вас другому - не оверсельте :)

1. На бегете, например, localhost. Школохостером его никак не назовешь, и сайты там выдерживают вполне себе серьезную наргузку. Впрочем:

2. В некоторых случаях, насколько могу судить из объяснений одного зарубежного облачного провайдера, и при настройках localhost БД может находиться физически на другой машине. Соответственно, "хорошим способом" не всегда так просто воспользоваться.

Не совсем понимаю как вот это:

связано с вот этим:

Причем тут оверсел ? Его никогда не было, были клиенты которые были размещены на 5 физ серверах и стучались все в один sql сервер... сегодня базы по 10MB через месяц базы по 1 GB ... и тому подобное, я говорю о том, что это вызывает больше проблем для других людей.... которые якобы выигрывают или экономят как вы выше выразились... Мне кажется что использовать sql на каждом сервере рациональней (2005-7 год), просто по тому, что если возникнет таки вопреки всем ожиданиям проблема с БД она будет общая для всех, а не локальная для какого-то сервера... и тогда использовали репликацию и все прочее, просто накладнее это все ... так что ли... Сейчас многое поменялось, хотя например разработчики ПО ушли не далеко, есть какие-то панели которые работают с SQL Clustering ? не видел, все названия из этой отрасли сводятся к указаниям remote-sql-server :) По этому складывать все в одну ячейку... как-то неправильно концептуально... Конечно если это какой-то мега шкаф-сторедж .... ))) другое дело ... но в 2007 .... это было за гранью моих пониманий и возможностей :D

Подозреваю что если чекание таблиц вызывает проблемы - то других идей кроме того что сервер перегружен я не имею.

Вечно апгрейдить тоже не выйдет, работали в сторону кластеризации sql.. по этому может быть уделялось сильно много времени этому, но в конечном итоге это было признано @большим гемором@, легче стало разнести все базы на свои сервера и решать штатаные проблемы с конкретными клиентами на конкретных серверах. Вообще в 2007 надо было еще поискать админа который бы с легкостью мог говорить о кластеризации SQL :) (Может тоже выборочно, но опыт то у каждого свой :D )