|
|
|
| 1) Добрый день, есть вариант получать mail пользователя по login(varchar 50 PK) или id(mediumint UNIQUE ), что быстрее (теоретически):
SELECT mail FROM user WHERE id=".$id
SELECT mail FROM user WHERE login=".$login
|
PS. возможность проверить в реальных условиях нет.
2) Насколько оправдано использование PK на login, UNIQUE на id (чем традиционное PK на id)?
Так как большинство выборок идут по login. | |
|
|
|
|
|
|
|
для: ntro123
(07.04.2015 в 19:06)
| | 1) Не важно по первичному ключу или по уникальному. Важен тип поля. По целочисленному полю быстрее.
2) Не оправдано. Хотя я навскидку не могу придумать причину почему так не стоит делать, но я за свою практику такого не встречал. Т.е. как минимум в 99.99% случаев делают ровно наоборот. Практической пользы делать "не как все" - нет. Так зачем такой разрыв шаблона?
P.S.
> Так как большинство выборок идут по login.
Это зачем же?
Выборку по логину нужно сделать один раз при авторизации.
Далее сохраняете id пользователя в сессию и все последующие выборки делаете по быстрому целочисленному полю. | |
|
|
|
|
|
|
|
для: Sfinks
(08.04.2015 в 21:18)
| | Пожалуй соглашусь со всем выше сказанным за исключением "Не важно по первичному ключу или по уникальному" PK он физически "на диске" записывается упорядоченно уже сам по себе. Поэтому выборка должна быть (теоретически) быстрее, по сравнению с индексом, когда сначала идет только поиск по таблице индексов, затем берется адрес и значение по адресу. Но с другой стороны если в таблице есть поля переменной длины (тот же mail varchar(50)) то по PK должно быть медленнее или быстрее? т.к. каждый раз вычисляется длина полей переменной длины, чтобы знать где заканчивается строка.
PS. PK по любому верну на id, но хотелось бы разобраться с ним до конца. | |
|
|
|
|
|
|
|
для: ntro123
(08.04.2015 в 22:14)
| | > PK он физически "на диске" записывается упорядоченно уже сам по себе.
Любой ключ (индекс) физически "на диске" записывается упорядоченно уже сам по себе.
А если вы имели ввиду что поле, по которому создан PK записывается упорядоченно, так это во-первых тоже спорно, а во вторых, при поиске по ключу не имеет никакого значения. | |
|
|
|
|
|
|
|
для: Sfinks
(09.04.2015 в 09:28)
| | Да, я хотел сказать, что сама таблица упорядочена по PK, в отличии от других ключей (индексов) которые тоже упорядочены (но уже в своей таблице индексов), и которые ссылаются уже на конкретный кортеж в "основной" таблице.
По любому должна быть разница в скорости между PK и UNIQUE (при прочих равных), но, все равно, тут вариант один: PK на id и UNIQUE на login. | |
|
|
|