本文共 1422 字，大约阅读时间需要 4 分钟。

从数据库实现角度来说确实也不建议太多表连接，从优化器的角度而言，选择连接路径的算法目前比较主流 的是动态规划和贪心算法，在连接表数比较少的时候选择动态规划，一阶段一阶段的去分析各种可能得连接顺序得到一个最优的执行计划，但动态规划场景下，随表的增加，计划也会爆炸式增加，优化器在选择最优计划的前提下，消耗的内存和CPU是不能不考虑的，所以当表的数量太多，数据库会退化成贪心算法，尽快，尽量少的消耗计算资源前提下出一个计划，这个计划可能不是执行最优的计划。

OB的规定是10表以上的星型连接就使用贪心算法，PG还在学术角度实现了基因算法，但工程上，大家很少使用这个。从应用的角度来说，这个约束没有出现在使用小型机+Oracle的时代，而是在阿里发起去IOE行动，转而选择用MySQL+PC服务器后，

具体来说，阿里巴巴的“去IOE”运动就是用成本更加低廉的软件——MYSQL替代Oracle，使用PC Server替代EMC2、IBM小型机等设备，以消除“IOE”对自己数据库系统的垄断。这一行动也被业内解读为低成本化——基于“IOE”在业内的垄断，整套系统维护费用非常昂贵，仅仅Oracle系统三年的销售价格就达到八位数，而阿里旗下的用户群每年都在增长，在应用云计算的过程中，“IOE”系统并不适合云服务横向扩展，也就是多个数据库系统同时运行，因此云服务一旦扩张，这部分维护成本将非常高。

数据库服务也从垂直拓展的集中式架构变成了水平拓展的分布式架构，Oracle对于多表连接的选择会做得更好，执行性能也更优，我觉得主要原因还是在它的使用场景中用户的使用习惯导致的，MySQL成熟于互联网爆发时期，很多小公司单PC够了，数据规模对性能得影响也没那么大，这不是它使用场景的痛点所在，自然没必要去费劲解决这方面的问题，同多表连接相比，大家更在乎的一个问题是当表在MySQL中数据量太大，由于它的索引结构设计没有针对大表，所以查询性能会断崖式下滑。从阿里的角度而言，由于数据规模太大，不得不考虑分库分表+中间件的模型，在分库分表场景下，能在数据库层面做join的场景自然也不多，所以大家更多的是将数据库当成一个带多行事务能力的KV系统去用。

key-value系统，指的是zookeeper，redis这类文件系统 这是轻DB重应用的思路，跟银行等传统行业重DB轻应用的思路刚好相反，如果将join放到中间件去实现，由于中间件拿到数据sharding信息更难，成本肯定更大，所以这个问题自然就落到了应用上，对于应用而言，一般的数据表设计会是一个很大的数据表集，一个或多个字典表，相对于数据表，字典表的数据增长速度会很小，两个表之间的关联一般有索引或者主键，这很适合nested loop join，

SQL的join关联表的使用方式，但是这次聊的是实现join的算法，join有三种算法，分别是Nested Loop Join，Hash join，Sort Merge Join。

而且应用也担心数据库给我把路径选错了，把join方式选错了，而在应用的角度，我的需求我会更了解，在应用层实现特定的join也容易得多，所以join一般被分解成先查一个数据集，然后用一个常量in来查另一堆数据集在分布式数据库的角度，我们希望数据库再次回到重DB的应用思路上，在分布式场景下，如何高效的选择和执行连接查询，是和单机相比一个更大的难题，也是OB的努力方向之一。

转载地址：http://idphn.baihongyu.com/