Форум: Форум PHPФорум ApacheФорум Регулярные ВыраженияФорум MySQLHTML+CSS+JavaScriptФорум FlashРазное
Новые темы: 0000000
Самоучитель PHP 5 / 6 (3 издание). Авторы: Кузнецов М.В., Симдянов И.В. Самоучитель MySQL 5. Авторы: Кузнецов М.В., Симдянов И.В. PHP на примерах (2 издание). Авторы: Кузнецов М.В., Симдянов И.В. PHP. Практика создания Web-сайтов (второе издание). Авторы: Кузнецов М.В., Симдянов И.В. Объектно-ориентированное программирование на PHP. Авторы: Кузнецов М.В., Симдянов И.В.
ВСЕ НАШИ КНИГИ
Консультационный центр SoftTime

Форум MySQL

Выбрать другой форум

 

Здравствуйте, Посетитель!

вид форума:
Линейный форум Структурный форум

тема: PK или UNIQUE индексы, что быстрее
 
 автор: ntro123   (07.04.2015 в 19:06)   письмо автору
 
 

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.

  Ответить  
 
 автор: Sfinks   (08.04.2015 в 21:18)   письмо автору
 
   для: ntro123   (07.04.2015 в 19:06)
 

1) Не важно по первичному ключу или по уникальному. Важен тип поля. По целочисленному полю быстрее.
2) Не оправдано. Хотя я навскидку не могу придумать причину почему так не стоит делать, но я за свою практику такого не встречал. Т.е. как минимум в 99.99% случаев делают ровно наоборот. Практической пользы делать "не как все" - нет. Так зачем такой разрыв шаблона?

P.S.
> Так как большинство выборок идут по login.
Это зачем же?
Выборку по логину нужно сделать один раз при авторизации.
Далее сохраняете id пользователя в сессию и все последующие выборки делаете по быстрому целочисленному полю.

  Ответить  
 
 автор: ntro123   (08.04.2015 в 22:14)   письмо автору
 
   для: Sfinks   (08.04.2015 в 21:18)
 

Пожалуй соглашусь со всем выше сказанным за исключением "Не важно по первичному ключу или по уникальному" PK он физически "на диске" записывается упорядоченно уже сам по себе. Поэтому выборка должна быть (теоретически) быстрее, по сравнению с индексом, когда сначала идет только поиск по таблице индексов, затем берется адрес и значение по адресу. Но с другой стороны если в таблице есть поля переменной длины (тот же mail varchar(50)) то по PK должно быть медленнее или быстрее? т.к. каждый раз вычисляется длина полей переменной длины, чтобы знать где заканчивается строка.

PS. PK по любому верну на id, но хотелось бы разобраться с ним до конца.

  Ответить  
 
 автор: Sfinks   (09.04.2015 в 09:28)   письмо автору
 
   для: ntro123   (08.04.2015 в 22:14)
 

> PK он физически "на диске" записывается упорядоченно уже сам по себе.
Любой ключ (индекс) физически "на диске" записывается упорядоченно уже сам по себе.
А если вы имели ввиду что поле, по которому создан PK записывается упорядоченно, так это во-первых тоже спорно, а во вторых, при поиске по ключу не имеет никакого значения.

  Ответить  
 
 автор: ntro123   (09.04.2015 в 12:19)   письмо автору
 
   для: Sfinks   (09.04.2015 в 09:28)
 

Да, я хотел сказать, что сама таблица упорядочена по PK, в отличии от других ключей (индексов) которые тоже упорядочены (но уже в своей таблице индексов), и которые ссылаются уже на конкретный кортеж в "основной" таблице.

По любому должна быть разница в скорости между PK и UNIQUE (при прочих равных), но, все равно, тут вариант один: PK на id и UNIQUE на login.

  Ответить  
Rambler's Top100
вверх

Rambler's Top100 Яндекс.Метрика Яндекс цитирования