Draconian

Если у вас приложение уже работает с MySql, почему бы не создать такие справочники там? Проще будет вносить изменения и т.д.

Принимая во внимание ответ выше, можно протестировать этот вариант на отдельном инстансе - убрать айди, сгенерировать хотя бы миллион строк, и поделать разные часто выполняемые запросы, всё будет понятно. Но проблем не должно быть никаких.
К тому же, если у вас в этой таблице появятся десятки миллионов строк, скорее всего, придется задуматься о партицировании, оптимизации и т.д.

Могу только добавить, что нет принципиальной разницы, каким способом это делать, но в скрипте можно сделать более объемную и сложную обработку поля title.

Если не поздно:
Скорее всего, когда вам такое сказали, имели ввиду, что создавать отдельный айди для каждой сущности не всегда обязательно. Например, зачем уникальный айдишник для таблицы Department_and_Head_department? Никакой дополнительной информации в ней нет об этих связях. Тоже самое почти для всех таблиц связи.
Часто достаточно иметь составной первичный ключ, например, серия+номер паспорта.

Есть подозрение, что нужно либо добавить индексы, либо проверить существующие, потому что выборки по индексированным полям должны выполняться очень быстро при таких размерах.

В остальном, Walt Disney дал правильные советы: разделить эту таблицу на две - архивную (в идеале - партицированную) и оперативную, в которой хранить данные за определенный период, джобами по истечении срока перекидывать эти данные в архив.
Можно еще дополнительно иметь "супер-оперативную" таблицу, в которой хранить необходимые вам уже агрегированные данные, которые обновлять триггерами после вставки информации в оперативную таблицу. Таким образом, после обновления оперативной таблицы, у вас уже будет вся аналитика за текущий период (день\неделю и т.д.).

Что касается аналитики по архиву, из моего опыта, заказчик всегда просит оперативные, быстро работающие отчеты, и агрегированные отчеты по месяцам\годам из архива, которые лишь бы построились. :-)