Идентификатор первичного ключа достигает предела типа данных bigint

У меня есть таблица, которая регулярно подвергается большим вставкам и удалениям (, и из-за этого в числовой последовательности столбца первичного идентификатора )есть большие пробелы. У него был первичный столбец идентификатора типа «int», который был изменен на «bigint». Несмотря на это изменение, предел этого типа данных также неизбежно будет превышен в какой-то момент в будущем (текущее использование указывает, что это произойдет в течение следующего года или около того ).

Как вы справляетесь с этим сценарием? Я задаюсь вопросом (шок ужас )нужен ли мне столбец первичного ключа, поскольку он не используется каким-либо очевидным образом в каких-либо запросах или на него ссылаются другие таблицы и т. д. Будет ли удаление столбца решением? Или такие действия приведут к тому, что вас с отвращением исключит из сообщества mysql?!

Мы уже почти достигли отметки в 500 миллионов для идентификатора с автоматическим приращением. Таблица содержит ключевые слова, связанные с данными файла, в отдельной таблице. Каждая строка данных файла может иметь до 30 ключевых слов, связанных с ней в таблице ключевых слов, поэтому они действительно начинают складываться после того, как у вас есть десятки тысяч файлов, которые постоянно вставляются и удаляются. В настоящее время таблица ключевых слов содержит ключевое слово и идентификатор файла, с которым оно связано, поэтому, если я избавлюсь от текущего столбца основного идентификатора, не будет уникального идентификатора, кроме ключевого слова (varchar )и идентификатора файла (int )полей вместе взятых, что было бы ужасным первичным ключом.

Все мысли/ответы/опыт/решения были получены с благодарностью.