Performance gains from ordered UUID primary keys

[spice lion]

Hi everyone. I am several months into a pre-production project that I started before Laravel released official support for UUID primary keys using a trait.
I wanted UUIDs on my project so I rolled my own trait. My trait does not use ordered UUIDs (but the database columns do have an index).

I am wondering if anyone has any insight into if it's worth it for me to refactor my entire application to use ordered UUIDs as provided by Laravel's official trait.
As I understand it, ordered UUIDs will be more efficient to query because they can be sorted.

Does anyone know how big of a difference using ordered UUIDs might make?

[nocturne night]

I dug deep into this a while ago for an analytics project that has a lot of rows, and I don't remember exactly why, but at least in MySQL, integer primary keys are the most performant, or at least close enough to being most performant that I chose to use them over UUIDs, (ordered or not).

IIRC, orders vs unordered may provider different performance benefits, and it depends on how the table is indexed. I think if there's an index on the primary key, and you use ordered UUIDs, and you have an insert-heavy workflow, then there are performance gains over an unordered UUID because the index isn't constantly being rewritten at random locations.

I think I found my entry point into UUID research, if you want to go down a similar rabbit hole: https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/

ramsey/uuid can do what Percona describes: https://github.com/ramsey/uuid/issues/117