Низът или int са предпочитани за външни ключове?

Зависи

Има много съществуващи дискусии относно компромисите между естествените и сурогатните ключове - ще трябва да решите какво работи за вас и какъв е „стандартът“ във вашата организация.

В случая на ОП има и сурогатен ключ (int userId ) и естествен ключ (char или varchar username ). Всяка колона може да се използва като първичен ключ за таблицата и така или иначе ще можете да наложите уникалността на другия ключ.

Ето някои съображения, когато избирате единия или другия начин:

Случаят за използване на сурогатни ключове (напр. UserId INT AUTO_INCREMENT)

Ако използвате сурогат, (напр. UserId INT AUTO_INCREMENT ) като първичен ключ, след което всички таблици се позовават на таблица MyUsers след това трябва да използва UserId като външен ключ.

Все пак можете да наложите уникалност на username колона чрез използване на допълнителен уникален индекс , напр.:

CREATE TABLE `MyUsers` (
  `userId` int NOT NULL AUTO_INCREMENT,
  `username` varchar(100) NOT NULL,
  ... other columns
  PRIMARY KEY(`userId`),
  UNIQUE KEY UQ_UserName (`username`)

Според @Dagon, използвайки тесен първичен ключ (като int ) има предимства за производителност и съхранение в сравнение с използването на по-широка (и променлива дължина) стойност като varchar . Това предимство засяга и други таблици, които препращат MyUsers , като външен ключ към userid ще бъде по-тесен (по-малко байтове за извличане).

Друго предимство на сурогатния целочислен ключ е, че потребителското име може да се променя лесно, без да се засягат таблици, препращащи MyUsers .Ако username беше използван като естествен ключ, а други таблици са свързани с MyUsers чрез username , това прави много неудобно промяната на потребителско име (тъй като в противен случай връзката с външния ключ би била нарушена). Ако се изисква актуализиране на потребителски имена в таблици с помощта на username като външен ключ, техника като ON UPDATE CASCADE е необходимо, за да се запази целостта на данните.

Случаят за използване на естествени ключове (т.е. потребителско име)

Един недостатък на използването на сурогатни ключове е, че другите таблици, които препращат към MyUsers чрез сурогатен ключ ще трябва да бъде JOIN върнати обратно към MyUsers таблица, ако Username колона е задължителна. Едно от потенциалните предимства на естествените ключове е, че ако една заявка изисква само Username колона от таблица, препращаща MyUsers , че не е необходимо да се присъединява обратно към MyUsers за да извлечете потребителското име, което ще спести някои I/O допълнителни разходи.