Ни делайте этого ни в коем случае.
Если злоумышленники получат доступ к исходному коду скриптов, что бывает из-за дыр в php-скриптах или т.п., они завладеют вашим админским паролем.
Для соединения с mysql всегда используйте отдельный специальный mysql-логин/пароль.
Проще всего просто соединиться с mysql от имени root и дать команду
GRANT ALL PRIVILEGES ON имябазы.* TO имяюзера@localhost IDENTIFIED BY 'пароль';
В WHM (т.е. администраторской части cpanel) есть пункт "CPU/Memory/MySQL Usage". Он весьма далек от реальности, потому как основан просто на периодических снапшотах списка процессов. Таким образом самый невинный скрипт, запущенный в неподходящий момент, может там показать 99% ;)
Эти проценты - некий миф. Или скорее уловка, которую используют хостеры, чтобы иметь формальный повод приструнить зарвавшихся пользователей. Потому как адекватно обосновать претензии зачастую весьма сложно.
Если хотите застраховаться от проблем - просто спросите хостера, не грузит ли ваш сайт сервер?
Для начала стоит разобраться в чем узкое место. Хотя бы mysqltuner запустить и посмотреть slow log.
А там уже и думать как решать проблему - то ли памяти добавлять, то ли оптимизировать индексы - добавить нужные или уменьшить их размер, удалив редкоиспользуемые, но большие. Или думать как структуру базы и запросов менять.
Я очень сомневаюсь, что механическое перенесение базы на другое ПО даст адекватные резуьтаты.
Дык все дело в структуре базы и сложности запросов, а не в размере.
Если система использует только простые запросы с использованием индексов и т.п. - то есть то, что mysql УМЕЕТ делать ХОРОШО, то mysql даст фору любой базе.
А если программер навернет кучу субреквестов и join'ов по десятку таблиц - то это будет не вина мускула, что он будет тормозить ;)
У каждого продукта есть свои сильные и слабые стороны. Нужно просто уметь использовать одни и избегать других.
"абстрактное идеальное железо" - самое распространненое заблуждение студентов и начинающих программистов, за которое они неизбежно получают в пятак от админов и заказчиков.
MySQL умеет работать быстро, но только если писать запросы со знанием дела.
Главу руководства "оптимизация" не просто желательно прочитать. Ее ОБЯЗАТЕЛЬНО нужно прочитать 11 раз, вникая в каждое слово, прежде чем садиться писать более менее большое приложение.
А "максимальный объем" ограничен по большей частью размером винта(ов).
Нет, у ext3 ограничение 32K на количество поддиректорий, на количество файлов это не распространяется.
Бабушка надвое сказала. Тут сложно сказать теоретически - нужно пробовать. Но мне кажется, что разница в скорости будет незначительной.
Но это, по крайней мере, будет работать без извращений с файловыми системами.
Можно использовать innodb, чтобы уменьшить число файлов.
Сама постановка задачи выглядит очень сомнительной.
Наверное самое лучшее, это не требовтьа от мускула того, на что он не заточен, а поискать другой, более прямой путь.
Например, другой типа базы. Вот хотя бы sqlite - там сколько файлов столько и баз ;)
Или другой принципе разделения пользователей. Например, база на всех одна, а имена таблиц начинать в зависимости от имени пользователя. Безопасный доступ при этом вполне можно обеспечить - мускул поддерживает права доступа для отдельных таблиц.
Установи ЕЩЕ раз из исходников поверху, точно так же как сейчас установлен. Параметры ./configure можно узнать по phpinfo() или php -i
А затем сделай make uninstall
Вы сначала действительно расскажите, чем собственно mysql-сервер загружен?
Какого рода запросы выполняются чаще всего? Что обычно видно по show processlist? В полной ли мере используются индексы?
Если проблема в запросам к full text index'ам, то их реально никак не оптимизируешь. Зато само собой напрашивается сделать репликацию на второй сервер и использовать два сервера параллельно.
Или же переходить на другой поиск, не full text.
