MySQL中使用UUID函数作为主键的问题
对于 InnoDB 这种聚集主键类型的引擎来说，数据会按照主键进行物理排序，这对 auto_increment int 是个好消息，因为后一次插入的主键位置总是在最后。但是对 uuid 来说，这却是个坏消息，因为 uuid 是杂乱无章的，每次插入的主键位置是不确定的，可能在开头，也可能在中间，在进行主键物理排序的时候，势必会造成大量的 IO操作影响效率，因此不适合使用 UUID 做物理主键。比较适合的做法是把uuid作为逻辑主键，物理主键依然使用自增ID。
GUID
全局唯一标识符，简称GUID（Globally Unique Identifier），是一种由算法生成的唯一标识，通常表示成32个十六进制数字组成的字符串，实质上是一个128位长的二进制整数。
GUID的主要目的是产生完全唯一的数字，在理想情况下，任何计算机和计算机集群都不会生成两个相同的GUID，GUID的总量也足够大，达到了2^128个，所以随机生成两个相同的GUID的可能性是非常小的，但是并不为0；所以，用于生成GUID的算法通常都加入了非随机的参数（如时间），以保证重复的情况不会发生。
GUID已经广泛使用于数据库表格的主键。由于主键需要用作索引，于是就产生了一个性能问题：当主键足够随机时，新的记录就必须插入到原有的索引中间，而不能仅仅排在最后。
为缓解这个问题并仍然提供足够的随机程度以避免GUID的重复，人们就创造了一些新的算法来生成序列化的GUID。
2002年8月，吉米尼尔森（Jimmy Nilsson）给出了第一种方法，并称之为“COMB”（combined guid/timestamp，意思是：组合GUID/时间戳）。他将GUID中数据4的最后6字节用系统时间的最低位替换。经测试，这对随机性的影响很小，但是有一个副作用即是其创建的时间可以从GUID中轻松还原。
自从Microsoft SQL Server 2005版开始，微软在Transact-SQL中加入了一个新函数，叫做NEWSEQUENTIALID()，用来生成主键增大的GUID，但一旦服务器重新启动，其再次生成的GUID可能反而变小（但仍然保持唯一）。这在很大程度上提高了索引的性能，但并不能保证所生成的GUID已知增大。这个函数产生的GUID很简单就可以预测，因此不适合用于安全目的。
2006年，一些程序员发现，在一些平台上的Oracle软件中，SYS_GUID函数能返回序列化的GUID。但这个实际上是一个BUG导致的。
全局唯一性ID问题
https://tech.meituan.com/MT_Leaf.html
文中的思路可以借鉴，目前先只使用snowflake来处理