Как спроектировать базу данных сайта знакомств на MySQL?
1. ENUM вообще говоря довольно большая штука 65535 вариантов. Но все же рекомендую делать через нормализацию, вам это словарь может еще пригодится где-то.
2. Ключами стоит делать то, по чем вы будете искать. В случае, если данные в конце слабо отличаются, а основные изменения в начале - имеет смысл ограничить индекс по размеру (ВНИМАНИЕ ТОЛЬКО ДЛЯ ЭКОНОМИИ ПАМЯТИ). Например:
abcd
bacd
dxdc
aabd
У приведенных строк на последнем символе разница не существенная, посему индекс можно ограничить 3-мя.
3. Вот тут бабка на двое гадала, если у вас будет индекс на уникальность (НЕ primary), то множество NULL вы получить сможете, а вот множество "" - нет. NOT NULL рекомендую использовать в случае, если вы требуете обязательности заполнения данных.
4. Конечно MEMORY! Всего один сбой в ДЦ и у вас появится работы на еще пол года, это же замечательно)) В памяти можно хранить только то, что вы согласны в любой момент потерять.
Если по хорошему - memory таблицы во первых имеют кучу ограничений, во вторых - проигрывают k-v хранилищам типа memcached/redis по скорости, в третьих не поддерживают вытеснения.PS: планируется высокое посещение сайта (десятки тысяч пользователей).
За какой период?
Если за сутки - это... не высокое посещение, вы даже foreign ключики позволить себе сможете.
Если за минуту (и реально много данных) - вот это уже интересно, про FK забудьте, пересчет индексов будет слишком дорогим. Под поиск - смотрите в сторону кластера на elasticsearch, так же скорее всего потребуется кластер мемкэшей. БД дергать можно будет но по минимуму. Основная работа должна будет происходить в фоновом режиме, посему подберите сервер очередей типа rabbitmq, или что-то типа того.
1. справочник стран. в анкете хранить ид страны.  связь "многие к 1"
2. хз что такое бтрее индексы.
3. лучше использовать нулл. наверное не так поняли тему или был какой то нюанс. 
4. иннодб