Я искал, если UUID, сгенерированный cakePHP (длиной 32 символа), быстрее по сравнению с автоматическим приращением. Сравнение в обеих вставках и операции Select. Какой я должен использовать UUID генерируется CakePHP или с помощью простого автоинкрементируемого из MySQLПроизводительность: UUID и auto-increment в cakephp-mysql
Вот случай-исследование, которое я нашел, но его не специфичны для CakePHP
http://krow.livejournal.com/497839.html
Я сомневаюсь, что вы» в процессе выбора первичного ключа заметна значительная часть проблем с производительностью. Ваши узкие места будут где-то еще, почти гарантированы.
По умолчанию я рекомендую использовать только первичный ключ с автоматическим приращением. Это имеет смысл - вы узнаете, какие записи заказов были вставлены с первого взгляда, поэтому вы можете их легко удалить, если тестовые данные и т. Д. Кроме того, легче читать число, чем 32 символа UUID. Поэтому юзабилити - это автоматическое увеличение INT.
Итак, когда вы используете UUID? Любая ситуация, когда вы хотите убедиться, что ключ глобально уникален (или довольно близко к нему). Один пример можно найти в базе данных с закрытыми данными; db1 и db2. Вы не можете использовать автоматические инкременты INT, потому что тогда у вас может быть 2 записи (одна в db1, одна в db2), которые имеют один и тот же первичный ключ, что приведет к кошмарам, если вам когда-либо понадобится объединить или переустановить. Так что это один из примеров, когда нужно использовать UUID.
Но, как правило, просто придерживайтесь автоматических инкрементированных INT. Это просто улучшает жизнь.
На самом деле, я бы пошел точно в другую сторону. UUID для мобильности и обратимости. Нет никакой привлекательной пользы для INT, кроме производительности, которая, как вы заметили, в большинстве случаев является номинальной в лучшем случае. –
Возможно, это одна из тех, кто «каждый в свои» ситуации. Я нахожу, особенно во время начальной работы dev, что я постоянно сортирую свои записи по обратному порядку, чтобы я мог удалить только что добавленные строки. Когда вы сортируете UUID, они сортируются по порядку создания? Опять же, мне кажется, что мне проще (как программисту) смотреть на INT, а не на строку длиной 32 строки. –
Да, мне было любопытно, что ссылка, которую я опубликовал, показывает, что UUID эффективен в сравнении с auto-inc, хотя я лично предпочитаю использовать auto-inc .. –
Всегда лучше поместить эту логику в базу данных, она будет быстрее для вставки и выбора. Потому что, когда MySQL делает PK с автоматическим значением прироста, чем автоматически делает индекс в этом поле и для лучшей производительности помещает его в нужное место на диске., Поэтому, если вы используете сортировку, это будет быстрее с индексированным PK, чем 32 длинными символами.
UUID и PK не являются взаимоисключающими. UUID может быть проиндексирован как ПК. – Grod
Проблемы с производительностью редко происходят из первичных ключей. Очень редко. –
Преимущество случайного порядка (UUID) заключается в том, что * пользователь * не может указать порядок создания. – Pacerier