В большинстве проектов, с которыми я работал, обычно используют "дефолтный" тип для uuid-идентификаторов - UUIDv4. UUIDv4 - это 122 бита чистого рандома, отличный тип для уникального идентификатора. Но, обычно мы работаем с этим типом в базах, часто поле с этим типом помечается как primary key, и минус его в том, что он, при вставке в базу в индексируемом поле, дает хаотичный порядок. Простыми словами: при вставке в базу UUIDv4 попадает в случайное место индекса, из-за чего таблица постоянно разрывается на куски, индекс разрастается и вставки начинают работать медленее. Посмотрим на примере с b-tree индексами. Как работает b-tree: - индекс - это дерево, в котором данные упорядочены по ключу - листовые страницы хранят отсортированные значения PK - новые ключи вставляются так, чтобы порядок сохранялся Что происходит, когда мы вставляем в индекс UUIDv4: - новая вставка попадает в происзвольное место середины b-tree - это чаще провоцирует page split - деление страниц дерева пополам и перенос записей в новую страницу - это дорогие операции, они увеличивают глубину дерева Получается, что b-tree, который должен быть плотным и последовательным, превращается в хаотичный набор частично заполненных страниц из-за случайного порядка ключей. Как это решить? Использовать UUIDv7. Во-первых, этот тип хранит в себе не только рандомный ключ, но и время: - первые 48 бит - timestamp - остальные - рандомный ключ + секвенс, чтобы избежать коллизий Во-вторых, все значения монотонно возрастают из-за включенного в ключ timestamp. Что умеет v7, чего не умеет v4: - когда мы сортируем по uuid - фактически, мы сортируем по времени - когда мы вставляем в индекс - новые записи всегда будут добавляться в конец b-tree дерева, а не в рандомное место Получается, что используя UUIDv7 мы автоматически оптимизируем вставку в индекс уменьшая оверхед уменьшением количества page split. Вывод: используйте UUIDv7, он лучше, стабильней, и можно писать order by id desc и получать очень быструю сортировку по времени 😎 dev notes | golang digest