Какой дизайн БД быстрее: уникальный индекс и INSERT IGNORE, или использование SELECT для поиска существующих записей?

Question

У меня есть таблица с одним столбцом: userid.

Когда пользователь заходит на определенную страницу, его идентификатор пользователя вставляется в таблицу. Идентификаторы пользователей уникальны, поэтому в этой таблице не должно быть двух одинаковых идентификаторов пользователей.

Я рассматриваю два варианта:

1. Создание уникального столбца и использование команд INSERT каждый раз, когда пользователь заходит на эту страницу.
2. Проверка, если пользователь уже записан в таблицу, путем SELECT извлечения из таблицы, затем INSERT, если запись не найдена.

Какой из них быстрее?

Answer 1

Определенно создайте индекс UNIQUE, или, лучше, сделайте этот столбец PRIMARY KEY.

Вам все равно нужен индекс, чтобы ваши чеки были быстрыми.

Почему бы не сделать этот индекс UNIQUE, чтобы у вас была другая альтернативная опция (если вы по какой-то причине забыли проверить с помощью SELECT)?

Если ваша таблица InnoDB, она все равно будет иметь PRIMARY KEY, поскольку все таблицы InnoDB организованы по индексу по дизайну.

В случае, если вы не объявили PRIMARY KEY в своей таблице, InnoDB создаст скрытый столбец в качестве первичного ключа, таким образом, сделав вашу таблицу слишком большой, и у вас не будет индекс по вашей колонке.

Создание PRIMARY KEY в вашем столбце - беспроигрышный вариант.

Вы можете оформить

INSERT
IGNORE
INTO    mytable
VALUES  (userid)

и проверьте, сколько записей было затронуто.

Если 0, было нарушение ключа, но не исключение.

Answer 2

Как насчет использования ЗАМЕНА ?

Если пользователь уже существует, его заменяют, а если нет, вставляется новая строка.

Answer 3

SELECT быстрее ... но вы бы предпочли проверку SELECT не из-за этого, а чтобы избежать ошибки ..

Answer 4

как насчет обновления, например

UPDATE xxx SET x=x+1 WHERE userid=y

и если это не удастся (например, нет соответствующих строк), тогда будет ли вставка для нового пользователя?

Answer 5

Вы должны сделать его уникальным в любом случае.

Будет ли сначала проверяться использование SELECT, зависит от того, какой сценарий наиболее распространен. Если у вас все время есть новые пользователи и только иногда существующие пользователи, система может в целом быстрее вставлять и перехватывать исключение в тех редких случаях, когда это происходит, но исключение медленнее, чем проверка сначала, а затем вставка, поэтому Это распространенный сценарий, что это уже существующий пользователь, вы должны всегда проверять сначала с помощью select.

Answer 6

orrrrrrr

INSERT INTO xxx (`userid`) VALUES (4) ON DUPLICATE KEY UPDATE userid=VALUE(`userid`)