关于uuid与自增列的选择
关于uuid与自增列的选择
在db交流群里看到有人提问，说他的userName 登录名是唯一的，可以用其做主键嘛，如果用自增列，那又要多一列。
后面又说，如果要用主键ID，用uuid会不会好一些呢？作为新手的我也对这个问题发生了兴趣，百度检索下得出大致结论：
uuid：可以简单的的理解为全球唯一标识符
一、缺点
1.无序性：uuid是无序的， 插入数据时，页的位置会发生变化，页分裂，速度慢。一般情况下主键是聚簇索引，会把相邻主键的数据安放在相邻的物理存储上。如果主键不是自增，而是随机的，那么频繁的插入会使 innodb 频繁地移动磁盘块，而影响写入性能。
2.占空间大：uuid占的空间大，并且别的索引还都要包含主键的值，那么每个索引的空间也都会增大，占的空间大，需要读数据时一般会认为需要的io次数多, 如果需要分库分表，往往是海量数据，这个时候使用UUID不是一个好的选择（占用空间太大）。主键一般情况下追求短整型，确定好你的整型类型（根据需求）。
二、优点
1.数据离散化便于发布集群
2.利于水平分割
3.数据多写，合并复制等分布式操作
自增ID：可以简单理解成一个自增的序列
缺点：
1.不利于水平分割
2.插入增加增量，删除不减少增量
3.数据聚集化不便于发布集群
4.主键冲突。
系统大了点，要考虑分布式，甚至数据库双写之类，这样的策略是不够的。举个例子，系统做了双机房，想做一个数据库的异地双向同步。那么当双方还没同步的情况下，可能录入了同样的ID。当然了，只是双机房的话还是可以用 increase by 的方式，把数据库自增步伐修改为奇偶。比如说机房1的主库是基数的ID，机房2的主库是偶数的ID。双向同步创建数据来说就没有冲突了。（双向同步还有好多问题的，并发下的update时序问题等这里不展开讨论）
优点：即uuid缺点的反向
总结：
主要原因是索引在磁盘上存储的形式，常用的 b-tree 索引如果 id 是连续的，那么数据存储在相邻的磁盘上，如果查询和写入操作的 id 连续，那么减少随机读写硬盘的几率，提升读写效率。
所以看你的实际情况，如果你用的是 b-tree 索引，同时记录比较多，那么用有序 id 作为索引效率会高很多。具体情况题主可以自己测试一下，差距明显。
跨库join的问题
在拆分之前，系统中很多列表和详情页所需的数据是可以通过sql join来完成的。而拆分后，数据库可能是分布式在不同实例和不同的主机上，join将变得非常麻烦。而且基于架构规范，性能，安全性等方面考虑，一般是禁止跨库join的。
那该怎么办呢？首先要考虑下垂直分库的设计问题，如果可以调整，那就优先调整。如果无法调整的情况，下面笔者将结合以往的实际经验，总结几种常见的解决思路，并分析其适用场景。
跨库Join的几种解决思路
全局表
所谓全局表，就是有可能系统中所有模块都可能会依赖到的一些表。比较类似我们理解的“数据字典”。为了避免跨库join查询，我们可以将这类表在其他每个数据库中均保存一份。同时，这类数据通常也很少发生修改（甚至几乎不会），所以也不用太担心“一致性”问题。
字段冗余
这是一种典型的反范式设计，在互联网行业中比较常见，通常是为了性能来避免join查询。
举个电商业务中很简单的场景：
“订单表”中保存“卖家Id”的同时，将卖家的“Name”字段也冗余，这样查询订单详情的时候就不需要再去查询“卖家用户表”。
字段冗余能带来便利，是一种“空间换时间”的体现。但其适用场景也比较有限，比较适合依赖字段较少的情况。最复杂的还是数据一致性问题，这点很难保证，可以借助数据库中的触发器或者在业务代码层面去保证。
当然，也需要结合实际业务场景来看一致性的要求。就像上面例子，如果卖家修改了Name之后，是否需要在订单信息中同步更新呢？
数据同步
定时A库中的tab_a表和B库中tbl_b有关联，可以定时将指定的表做同步。当然，同步本来会对数据库带来一定的影响，需要性能影响和数据时效性中取得一个平衡。这样来避免复杂的跨库查询。笔者曾经在项目中是通过ETL工具来实施的。
系统层组装
在系统层面，通过调用不同模块的组件或者服务，获取到数据并进行字段拼装。说起来很容易，但实践起来可真没有这么简单，尤其是数据库设计上存在问题但又无法轻易调整的时候。
具体情况通常会比较复杂。下面笔者结合以往实际经验，并通过伪代码方式来描述。
简单的列表查询的情况
伪代码很容易理解，先获取“我的提问列表”数据，然后再根据列表中的UserId去循环调用依赖的用户服务获取到用户的RealName，拼装结果并返回。
有经验的读者一眼就能看出上诉伪代码存在效率问题。循环调用服务，可能会有循环RPC，循环查询数据库…不推荐使用。再看看改进后的：
这种实现方式，看起来要优雅一点，其实就是把循环调用改成一次调用。当然，用户服务的数据库查询中很可能是In查询，效率方面比上一种方式更高。（坊间流传In查询会全表扫描，存在性能问题，传闻不可全信。其实查询优化器都是基本成本估算的，经过测试，在In语句中条件字段有索引的时候，条件较少的情况是会走索引的。这里不细展开说明，感兴趣的朋友请自行测试）。
小结
简单字段组装的情况下，我们只需要先获取“主表”数据，然后再根据关联关系，调用其他模块的组件或服务来获取依赖的其他字段（如例中依赖的用户信息），最后将数据进行组装。
通常，我们都会通过缓存来避免频繁RPC通信和数据库查询的开销。列表查询带条件过滤的情况
在上述例子中，都是简单的字段组装，而不存在条件过滤。看拆分前的SQL：
这种连接查询并且还带条件过滤的情况，想在代码层面组装数据其实是非常复杂的（尤其是左表和右表都带条件过滤的情况会更复杂），不能像之前例子中那样简单的进行组装了。试想一下，如果像上面那样简单的进行组装，造成的结果就是返回的数据不完整，不准确。
有如下几种解决思路：
-
查出所有的问答数据，然后调用用户服务进行拼装数据，再根据过滤字段state字段进行过滤，最后进行排序和分页并返回。
这种方式能够保证数据的准确性和完整性，但是性能影响非常大，不建议使用。
-
查询出state字段符合/不符合的UserId，在查询问答数据的时候使用in/not in进行过滤，排序，分页等。过滤出有效的问答数据后，再调用用户服务获取数据进行组装。
这种方式明显更优雅点。笔者之前在某个项目的特殊场景中就是采用过这种方式实现。
跨库事务（分布式事务）的问题
按业务拆分数据库之后，不可避免的就是“分布式事务”的问题。以往在代码中通过spring注解简单配置就能实现事务的，现在则需要花很大的成本去保证一致性。这里不展开介绍，
感兴趣的读者可以自行参考《分布式事务一致性解决方案》，链接地址：
http://www.infoq.com/cn/articles/solution-of-distributed-system-transaction-consistency
