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, или что-то типа того.
