4 ms·
A better argument against Type 4 GUID keys is that random distribution of your primary key doesn't preserve temporal locality in indexes. If you have a big enou
by barrkel 6y ago
A better argument against Type 4 GUID keys is that random distribution of your primary key doesn't preserve temporal locality in indexes. If you have a big enough keyspace to worry even in the slightest about collisions in 122 bits, you have a bigger index than will comfortably fit in memory. Under those circumstances, random key lookups will thrash your cache. If you access multiple rows at a time which were allocated close together in time - not unusual with normalized schema - you'll want them adjacent in the index too.
- bob1029 6y agoAny reasonable database index implementation will utilize data structures which address this exact flavor of concern. Concepts like the splay tree can optimize the locality of access dynamically based upon actual access patterns over time. But, you are right in that this locality of access property is available by default using integral types without the constraint imposed of needing to use a particular kind of dynamic data structure.
- barrkel 6y agoPlenty of databases use b+trees, which don't address this exact flavour of concern. In my direct experience, MySQL will perform quite poorly with lots of random lookups once your index starts getting to a meaty size.