Editing Universally unique identifier (section)

==== Combined Time-GUID ====

The random nature of standard UUIDs of versions 3, 4, and 5, and the ordering of the fields within standard versions 1 and 2 may create problems with database [[locality of reference|locality]] or performance when UUIDs are used as [[primary key]]s. For example, in 2002 Jimmy Nilsson reported a significant improvement in performance with Microsoft SQL Server when the version-4 UUIDs being used as keys were modified to include a non-random suffix based on system time. This so-called "COMB" (combined time-GUID) approach made the UUIDs significantly more likely to be duplicated, as Nilsson acknowledged, but Nilsson only required uniqueness within the application.<ref>{{cite web |last=Nilsson |first=Jimmy |url=http://www.informit.com/articles/article.aspx?p=25862 |title=The Cost of GUIDs as Primary Keys |website=InformIT |access-date=2012-06-20|date=2002-03-08 }}</ref> By reordering and encoding version 1 and 2 UUIDs so that the timestamp comes first, insertion performance loss can be averted.<ref>{{cite web |url=https://percona.com/blog/2014/12/19/store-uuid-optimized-way/ |publisher=Percona |title=Storing UUID Values in MySQL |access-date=2021-02-10 |archive-url=https://web.archive.org/web/20201129230946/https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/ |archive-date=2020-11-29| date=2014-12-19}}</ref>

COMB-like arrangements of UUID payloads were eventually standardized in RFC 9562{{r|RFC 9562}} as UUIDv6 and UUIDv7.