一、自增还是UUID？数据库主键的类型选择
自增还是UUID？这个问题看似简单，但是能诱发很多思考，也涉及到了很多细节。先说下uuid和 auto_increment（数据库自增主键）的优缺点吧，因为是个人理解，如有错误恳请指出：
1、自增主键
自增ID是在设计表时将id字段的值设置为自增的形式，这样当插入一行数据时无需指定id会自动根据前一字段的ID值+1进行填充。在MySQL数据库中，可通过sql语句AUTO_INCREMENT来对特定的字段启用自增赋值 使用自增ID作为主键，能够保证字段的原子性。
auto_increment优点：
- 字段长度较uuid小很多，可以是bigint甚至是int类型，这对检索的性能会有所影响。我们平时数据库一般用的都是innodb引擎的表，这种表格检索数据的时候，哪怕走索引，也是先根据索引找到主键，然后由主键找到这条记录。所以主键的长度短的话，读性能是会好一点的。
- 在写的方面，因为是自增的，所以主键是趋势自增的，也就是说新增的数据永远在后面，这点对于性能有很大的提升（这点我接下来会在uuid的优缺点分析中解释，虽然用词可能不太专业）
- 数据库自动编号，速度快，而且是增量增长，按顺序存放，对于检索非常有利；
- 数字型，占用空间小，易排序，在程序中传递也方便；
- 如果通过非系统增加记录时，可以不用指定该字段，不用担心主键重复问题。
auto_incremen的缺点：
- 最致命的一个缺点就是，很容易被别人知晓业务量，然后很容易被网络爬虫教做人
- 高并发的情况下，竞争自增锁会降低数据库的吞吐能力
- 数据迁移的时候，特别是发生表格合并这种操作的时候，会非常蛋疼
因为自动增长，在手动要插入指定ID的记录时会显得麻烦，尤其是当系统与其它系统集成时，需要数据导入时，很难保证原系统的ID不发生主键冲突（前提是老系统也是数字型的）。特别是在新系统上线时，新旧系统并行存在，并且是异库异构的数据库的情况下，需要双向同步时，自增主键将是你的噩梦；在系统集成或割接时，如果新旧系统主键不同是数字型就会导致修改主键数据类型，这也会导致其它有外键关联的表的修改，后果同样很严重；若系统也是数字型的，在导入时，为了区分新老数据，可能想在老数据主键前统一加一个字符标识（例如“o”，old）来表示这是老数据，那么自动增长的数字型又面临一个挑战。
2、UUID
UUID含义是通用唯一识别码 (Universally Unique Identifier)，指在一台机器上生成的数字，它保证对在同一时空中的所有机器都是唯一的。通常平台会提供生成的API。换句话说能够在一定的范围内保证主键id的唯一性。
优点：
- 地球唯一的guid，绝对不会冲突。数据拆分、合并存储的时候，能达到全局的唯一性
- 可以在应用层生成，提高数据库吞吐能力
- 是string类型，写代码的时候方便很多
缺点：
- 影响插入速度， 并且造成硬盘使用率低。与自增相比，最大的缺陷就是随机io。这一点又要谈到我们的innodb了，因为这个默认引擎，表中数据是按照主键顺序存放的。也就是说，如果发生了随机io，那么就会频繁地移动磁盘块。当数据量大的时候，写的短板将非常明显。当然，这个缺点可以通过nosql那些产品解决。
- uuid之间比较大小相对数字慢不少， 影响查询速度。
- uuid占空间大， 如果你建的索引越多， 影响越严重
- 读取出来的数据也是没有规律的，通常需要order by，其实也很消耗数据库资源
- 看起来比较丑
二、为啥不能用uuid做MySQL的主键？
在 MySQL 中设计表的时候，MySQL 官方推荐不要使用 uuid 或者不连续不重复的雪花 id（long 形且唯一，单机递增），而是推荐连续自增的主键 id，官方的推荐是 auto_increment。
那么为什么不建议采用 uuid，使用 uuid 究竟有什么坏处？要说明这个问题，我们首先来建立三张表，分别是：user_auto_key、user_uuid、user_random_key，他们分别表示自动增长的主键，uuid 作为主键，随机 key 作为主键，其他我们完全保持不变。
根据控制变量法，我们只把每个表的主键使用不同的策略生成，而其他的字段完全一样，然后测试一下表的插入速度和查询速度。
注：这里的随机 key 其实是指用雪花算法算出来的前后不连续不重复无规律的id：一串 18 位长度的 long 值。
光有理论不行，直接上程序，使用 Spring 的 jdbcTemplate 来实现增查测试。
技术框架：Spring Boot+jdbcTemplate+junit+hutool，程序的原理就是连接自己的测试数据库，然后在相同的环境下写入同等数量的数据，来分析一下 insert 插入的时间来进行综合其效率。
为了做到最真实的效果，所有的数据采用随机生成，比如名字、邮箱、地址都是随机生成：
程序写入效率测试结果
在已有数据量为 130W 的时候：我们再来测试一下插入 10w 数据，看看会有什么结果：
可以看出在数据量 100W 左右的时候，uuid 的插入效率垫底，并且在后序增加了 130W 的数据，uuid 的时间又直线下降。
时间占用量总体可以打出的效率排名为：auto_key>random_key>uuid。
uuid 的效率最低，在数据量较大的情况下，效率直线下滑。那么为什么会出现这样的现象呢？带着疑问,我们来探讨一下这个问题：
三、使用 uuid 和自增 id 的索引结构对比
1、使用自增 id 的内部结构
自增的主键的值是顺序的，所以 InnoDB 把每一条记录都存储在一条记录的后面。
当达到页面的最大填充因子时候（InnoDB 默认的最大填充因子是页大小的 15/16，会留出 1/16 的空间留作以后的修改）。
下一条记录就会写入新的页中，一旦数据按照这种顺序的方式加载，主键页就会近乎于顺序的记录填满，提升了页面的最大填充率，不会有页的浪费。
新插入的行一定会在原有的最大数据行下一行，MySQL 定位和寻址很快，不会为计算新行的位置而做出额外的消耗。
减少了页分裂和碎片的产生。
2、使用 uuid 的索引内部结构
因为 uuid 相对顺序的自增 id 来说是毫无规律可言的，新行的值不一定要比之前的主键的值要大，所以 innodb 无法做到总是把新行插入到索引的最后，而是需要为新行寻找新的合适的位置从而来分配新的空间。
这个过程需要做很多额外的操作，数据的毫无顺序会导致数据分布散乱，将会导致以下的问题：
写入的目标页很可能已经刷新到磁盘上并且从缓存上移除，或者还没有被加载到缓存中，innodb 在插入之前不得不先找到并从磁盘读取目标页到内存中，这将导致大量的随机 IO。
因为写入是乱序的，innodb 不得不频繁的做页分裂操作，以便为新的行分配空间，页分裂导致移动大量的数据，一次插入最少需要修改三个页以上。
由于频繁的页分裂，页会变得稀疏并被不规则的填充，最终会导致数据会有碎片。在把随机值（uuid 和雪花 id）载入到聚簇索引（InnoDB 默认的索引类型）以后，有时候会需要做一次 OPTIMEIZE TABLE 来重建表并优化页的填充，这将又需要一定的时间消耗。
结论：使用 InnoDB 应该尽可能的按主键的自增顺序插入，并且尽可能使用单调的增加的聚簇键的值来插入新行。