MySQL で UUID を主キーとして使用した場合のパフォーマンスに関するオンライン記事をいくつか読みました。共通のテーマは、それらが賛成か反対かは、非連続データがインデックスのパフォーマンスを損なうという考えです。
https://blog.codinghorror.com/primary-keys-ids-versus-guids/
最高のパフォーマンスを得るには、生成された GUID が部分的に連続している必要があります
https://www.percona.com/blog/2014/12/19/store-uuid-optimized-way/
UUIDフィールドを再配置して使用する関数を作成します（UUIDを再配置するとパフォーマンスが大幅に向上することを示した後）
ただし、非順次データが B-TREES、HASHES、CLUSTERED インデックスなどのインデックスにどのように影響するかを理解できません。
私の UUID ブログをリストに追加できます。(これは MySQL にも同様に当てはまります。)
パフォーマンスの問題は、インデックス (クラスター化されているか、BTree、ハッシュ、またはその他であるかに関係なく) が大きすぎて RAM にキャッシュされるまで発生しないことに注意してください。その時点で、到達する (または挿入しようとする) 「次の」UUID が RAM にある可能性は低いため、パフォーマンスに影響を与える I/O が必要になります。
対照的に、datetime をキーとする行を挿入する場合は、多少時系列で行を挿入すると、ほとんどの場合、BTree の同じブロックに挿入されます。これは、「次の」行がI/O を必要とする可能性が低いことを意味します。
I/O は、パフォーマンスの最大の要因です。
私のブログでは、タイプ 1 uuid をタイムスタンプに似たものに変換する方法を指摘しています。これにより、「参照の局所性」が実現され、I/O が減り、速度が向上します。MySQL 8.0 には、ストアド関数と同じことを行う組み込み関数があります。それでも、I/O を減らすには、タイプ 1 が必要であり、関数を呼び出す必要があります。