4 ms·
I've found UUID and other kinds of random primary keys to be very bad for performance once the data set no longer fits into memory. When that happens, the worki
by FooBarWidget 14y ago
I've found UUID and other kinds of random primary keys to be very bad for performance once the data set no longer fits into memory. When that happens, the working set of the primary key index becomes that of the entire index, so you end up with a lot of random disk I/O. Unless you have SSDs, your database performance then goes down the drain.
Of course you can also use a UUID that's less random, e.g. something with an incrementing first part and a small random last part.
- jacques_chester 14y agoIf you want UUIDs to double as a nonce (I use them this way), then you will need to use v4 UUIDs and yes, they are basically impossible to index because they should be normally distributed across a very large range of possibilities. If you want incrementing UUIDs, use v1 UUIDs, which are based MAC address + a timestamp. These change in a predictable way and are more indexable.
- jacques_chester 14y agos/normally distributed/uniformly distributed/ This is what happens when I try to sound cleverer than I actually am. :(