最近遇到了要选择String类型通过uuid设置实体类id好还是选择数字整型设置成数据库自增好的问题，
总结了一下两者的优缺点：
用数据库自增id的优点：
首先字段长度较uuid小很多，可以是bigint甚至是int类型，这对检索的性能会有所影响。我们平时数据库一般用的都是innodb引擎的表，这种表格检索数据的时候，哪怕走索引，也是先根据索引找到主键，然后由主键找到这条记录。所以主键的长度短的话，读性能是会好一点的。
在写的方面，因为是自增的，所以主键是趋势自增的，也就是说新增的数据永远在后面，这点对于性能有很大的提升（这点我接下来会在uuid的优缺点分析中解释，虽然用词可能不太专业）。

用数据库自增id的缺点：
最致命的一个缺点就是，很容易被别人知晓业务量，然后很容易被网络爬虫教做人
高并发的情况下，竞争自增锁会降低数据库的吞吐能力
数据迁移的时候，特别是发生表格合并这种操作的时候，会非常蛋疼

接下来说下uuid的优点：
基本不会有冲突的情况，这个也是uuid比较好的一个方面，更具有唯一性
可以在应用层生成，提高数据库吞吐能力
是string类型，写代码的时候方便很多

uuid的缺点
与自增相比，最大的缺陷就是随机io。这一点又要谈到我们的innodb了，因为这个默认引擎，表中数据是按照主键顺序存放的。也就是说，如果发生了随机io，那么就会频繁地移动磁盘块。当数据量大的时候，写的短板将非常明显。当然，这个缺点可以通过nosql那些产品解决。
读取出来的数据也是没有规律的，通常需要order by，其实也很消耗数据库资源

所以这两种用法，要根据实际情况去选择，在查询多的业务选择上uuid在业务数量级小的数据上使用更具有优势，，当需要用到对大数量级数据处理时，再根据实际情况来选择
。。。待续