Я не большой поклонник суррогатных ключей. Мне еще предстоит увидеть сценарий, в котором я бы предпочел использовать один для каждой таблицы базы данных.
Я бы сказал Нет .
Прочтите этот ответ: суррогатные против натуральных бизнес-ключей
Вышеизложенное можно рассматривать как саркастическое или пламенное (несмотря на удивительно много голосов), поэтому оно удалено.
В общем случае было много вопросов и ответов по суррогатным и естественным ключам, поэтому я чувствовал, что этот вопрос больше похож на дубликат. Я считаю, что суррогатные ключи хороши и очень полезны, главным образом потому, что естественные ключи могут приводить к очень большим первичным ключам в нижнем конце цепочки связанных таблиц - и это плохо обрабатывается многими СУБД, кластерные индексы становятся большими и т. Д. Но говорить, что « каждая таблица MySQL должна иметь автоматически увеличиваемый первичный ключ », - это очень абсолютное утверждение, и я думаю, что бывают случаи, когда они действительно предлагают мало или ничего.
Поскольку ОП обновил вопрос, я постараюсь прокомментировать эту конкретную тему.
Я думаю, что это как раз тот случай, когда автоинкрементный первичный ключ не только бесполезен, но и добавляет отрицательное значение. Предположим, что table1 и table2 находятся в отношениях 1:1, memberid может быть как Primary Key, так и Foreign Key до table1.
Добавление столбца идентификатора с автоинкрементом добавляет один индекс и, если он кластеризован (например, индексы PK InnoDB), увеличивает размер индекса memberid. Более того, если у вас есть такой автоинкрементный идентификатор, некоторое соединение таблицы 2 с другими таблицами должно быть выполнено с использованием этого id (соединения с таблицами в 1:n отношении к таблице 2), а некоторые с использованием memberid ( СОЕДИНЕНИЯ к таблицам в 1:n отношении table1). Если у вас есть только memberid, оба этих типа могут быть
сделано с помощью memberid.