какую базу данных записывают идентификатор для использования: долго или гуид?
Я запустил сервер MySQL в Docker, как это, просто используя значения по умолчанию:
docker run -d --rm --name mysql -e MYSQL_ALLOW_EMPTY_PASSWORD=true mysql
И создал базу данных следующим образом:
docker exec -it mysql mysql -e 'create database if not exists test'
И затем подключите интерактивный сеанс так:
docker exec -it mysql mysql test
Затем я заполнил его 32 миллионами случайных дат, запустив эту ...
INSERT into dates select date(from_unixtime(rand()*unix_timestamp(now())) );
, а затем выполняя это несколько десятков раз:
INSERT into dates select date(from_unixtime(rand()*unix_timestamp(now())) ) from dates;
Теперь у меня почти в два раза больше дат, чем у вас:
mysql> explain select * from dates;
+----+-------------+-------+------------+------+---------------+------+---------+------+----------+----------+-------+
| id | select_type | table | partitions | type | possible_keys | key | key_len | ref | rows | filtered | Extra |
+----+-------------+-------+------------+------+---------------+------+---------+------+----------+----------+-------+
| 1 | SIMPLE | dates | NULL | ALL | NULL | NULL | NULL | NULL | 33497947 | 100.00 | NULL |
+----+-------------+-------+------------+------+---------------+------+---------+------+----------+----------+-------+
1 row in set, 1 warning (0.00 sec)
Наконец, я могу продемонстрировать, как быстро я могу искать по таблице:
mysql> select count(*), d from dates where d between '2001-01-01' and '2001-12-31' group by d order by d desc;
....
365 rows in set (4 min 31.17 sec)
Имеет смысл, в 2001 году было несколько тысяч результатов на каждый день. (Помните, что эти даты случайным образом распределяются между 1970 - эпохой - и сейчас).
Нет индексов или чего-то еще, и нет настройки SQL. Прошло 4,5 минуты. Надеемся, что это даст вам основание для ожидания вашего сервера и производительности запросов.
5 ответов
гуиды имеют
Преимущества:
- Способность создать их офлайн из базы данных, не вызывая беспокойство о коллизиях.
- Вы никогда не собираетесь заканчиваться их
Недостатки:
- Последовательные вставки могут работать плохо (особенно на кластерных индексах).
- Последовательные Гуиды фиксируют это
- Займите больше места на строку
- создание того чисто не является дешевым
- но если клиенты генерируют их, это не на самом деле без проблем
Столбец должен все еще иметь ограничение на уникальность данных (или как PK или как отдельное ограничение, если это - часть некоторых других отношений), так как нет ничего останавливающего кого-то предоставляющего GUID рукой и случайно/сознательно нарушающий уникальность.
Если пространство не беспокоит Вас и Вашу производительность, если не значительно повлиявший они заставляют много из проблем уйти. Решение неизбежно характерно для индивидуальных потребностей приложения.
Я использую GUID в любом сценарии, который включает или репликацию или клиентское идентификационное поколение. Именно так намного легче управлять идентификационными данными в любой из тех ситуаций с GUID.
Для двухуровневых сценариев как веб-приложение, говорящее непосредственно с базой данных, или для серверов, которые не должны копировать (или возможно только должен копировать в одном направлении, pub/sub стиль) затем, я думаю, что столбец ID автопостепенного увеличения очень хорошо.
Что касается того, остаться ли с autoincs или переместиться в GUID... это - одна вещь защитить GUID в приложении зеленого поля, где можно принять все эти решения впереди. Это - другой, чтобы советовать кому-то перемещать существующую базу данных. Это могло бы быть больше боли, чем это стоит.
GUID имеют проблемы с производительностью и параллелизмом, когда расщепления страницы происходят. INTs может выполнить заливку страницы в 100% - только добавленный в одном конце, ГУИДЫ добавляют везде, таким образом, вероятно, необходимо выполнить более низкую заливку - который тратит впустую пространство всюду по индексу.
ГУИДЫ могут быть выделены в приложении, таким образом, Приложение может знать идентификатор записи, это создаст, который может быть удобным; но, технически, для дублирующихся GUID возможно быть сгенерированным (неравное положение, но, по крайней мере, поместите Unique Index on GUID столбцы),
Я согласовываю для слияния баз данных его более легкое. Но для меня прямой INT лучше, и затем живите со стычкой разбирания, как объединить DBS, когда/если это на самом деле необходимо.
Если Ваши данные часто перемещаются, то GUID является лучшим для Ключа таблицы. Если Вы действительно заботитесь о производительности, просто придерживаетесь интервала или bigint
Если Вы хотите усилить оба из вышеупомянутых, используйте интервал или bigint как ключ таблицы, и каждая строка может иметь rowguid столбец так, чтобы данные могли также быть перемещены легко, не теряя целостность.
Если идентификаторы будут отображенными в querystring, используйте Гуиды, иначе используйте долго, как правило.