Максим Кудрявцев

Первое - составь схему своей БД. Третью нормальную форму знаешь? Приведи свои данные к ней, для начала.
Затем тебе нужно определить условия порций. Ознакомиться с этим можно вот здесь Если коротко - это позволяет хранить БД на более чем одном жестком диске и добавляет скорости, когда у тебя записей в таблице очень-очень много.

Затем тебе нужно понимать, какие операции у тебя происходят наиболее часто - чтение или запись. Исходя из этого выбирай механизм хранения(MyISAM или InnoDB) и оптимизируй настройки СУБД, в т.ч. кеш.

Вообще твой вопрос очень размыт. На него сложно дать однозначный ответ сейчас. Ты пишешь про 240 млн. записей. Хорошо, может быть для тебя это много, лет 5 назад я бы тоже испугался. Ты должен понять, что количество записей мало что играет. Необходимо понимать их структуру, состав, частоту обращений, характер этих обращений, размер и т.п. Выкини из головы цифру и сосредоточься на реализации. Также решай проблемы по мере их поступления. Оптимизировать что-либо стоит тогда, когда это уже работает. Оптимизировать нужно то, что понятно, а не какие-то абстрактные циферки несуществующей еще таблиц БД

Смотри таблицу wp_users в БД. В большенстве случаев логин главного админа будет идти с ID=1

Для начала проверь еще раз свой алгоритм. Скорей всего, у тебя там добрая куча дублей, если не 100%, то какие-то куски точно будут повторяться. Не верю я что все 100% будут какими-то прям очень уникальными.

Первое что ты делаешь - общие куски своей информации выносишь в отдельное поле. Такую структуру как дерево знаешь? Вот этот общий кусок будет у тебя храниться в вершине дерева. Далее, каждая вершина хранит в себе ссылки на нижестоящие узлы с какими-то другими уникальными данными и т.д. В принципе уровней вложенности у тебя может быть бесконечно много.

К вопросу где хранить. Что-то лучше жестких дисков для этого пока еще не придумали. В твоем случае будет разумнее использовать гибридное хранилище SATA + SSD + RAM. Данные, к которым обращение происходит чаще всего, лежат в Redis (т.е. RAM), просто часто используемые - на SSD, что-то редко необходимое - на SATA. Алгоритм подсчета частоты уже сам напиши, определив для своей задачи что такое часто, не очень и редко.

Кто из провайдеров может обеспечить этим - на digitalOcean есть тарифы с гибридными винтам SATA + SSD, присмотрись к ним. Советую также глянуть в сторону docker, в твоем случае, думаю, нужно будет 10+ машин для хранения, а эта штука позволит тебе управлять их конфигурацией проще.

По поводу времени на извлечение, поиск и т.д. - гугли на тему "хранение деревьев", "поиск в дереве" и т.д. Постарайся уйти от полных графов, постарайся уйти даже от циклов, даже скажу больше, НЕ ДЕЛАЙ полный граф или цикл в графе на таком объеме, ты выстрелишь себе в ногу просто.

Придерживайся 1-3 нормальной формы. Подробнее в Вики

Много данных - это 20 млн записей....
В твоем случае вешай на поле UNIQUE + делай по этому же полю INDEX и скорость выборки/нагрузка на БД будут приемлемыми.