That's why you use ksuid (https://segment.com/blog/a-brief-history-of-the-uuid/) or, if you're willing to go with a draft spec you could go with the new UUIDv7 format https://www.ietf.org/archive/id/draft-ietf-uuidrev-rfc4122bi...
"KSUIDs are larger than UUIDs and Flake IDs, weighing in at 160 bits. They consist of a 32-bit timestamp and a 128-bit randomly generated payload."
TTTTTTTTRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRRR
T-Timestamp R-Random
There are economy arguments against using this as quasi-sequential PKs.
For efficient index lookup and sorting, best is to use CPU's native register sizes. It would be great if the PK would be a DWORD (32 bits) or QWORD (64 bits), one would assume the DB engine will align the access for efficient handling of the L1-L2 caches and prevent page tearing.