今天在微信上碰到某大师，简单聊了下。我和这位大师的关系也蛮有趣，最开始通过其他的渠道认识，还没有见过面，我向他推荐了我的一名前同事，没想到这位大洋彼岸的前同事竟然和这位大师也曾经是同事。真是翻洋过海也逃不出他的圈子啊。为了简单起见我简称大师为A,前同事为B,我为C,所以我就笑称既然这样，按照表的连接关系，A和B是同事，B和C是同事，那A和C也是同事了，听起来还是蛮有道理的吧。大师简单一句哈哈了事。 这个也就自己糊弄糊弄自己，猛意向似乎还确实是蛮有道理的。 如果把表的结构和sql语句结合起来，我还真找不出该怎么把这种关系给描述出来，索性画了个图，一看就不满足情况吧。 玩笑归玩笑，不过自己哪根筋搭错了，突然想起一个问题来，想起一个sql优化案例来。 有兴趣可以参考   我举一个略微简单的例子，有这么一条sql语句，性能还能够接受，但是在做审核的时候老感觉哪里不对劲。 select subscriber.customer_id,subscriber.xxxx from customer,subscriber,account where customer.customer_id=account.customer_id and customer.customer_id=subscriber_id and subscriber.customer_id=account.customer_id and subscriber.xxxx 这个语句的输出就是要显示用户的信息。 三者的关系可以这么来描述，就是典型的三户模型，客户，用户，账户。 按照三户模型，一个客户可以对应多个用户，一个客户可以对应多个账户，而用户和账户之间没有直接的映射，而是通过一个中间的属性来映射。 所以按照这个模型，可以肯定的是一个用户对应的客户只有一个，即subscriber.customer_id是唯一对应的。 一个账户对应的客户只有一个，即account.customer_id是唯一的。 所以如果用户和账户归属于同一个客户，即subscriber.customer_id=account.customer_id就可以唯一确定一个客户 所以说上面的查询过滤条件 customer.customer_id=account.customer_id and customer.customer_id=subscriber_id and subscriber.customer_id=account.customer_id 是不是从业务来看是不是显得有些多余啊。 其实直接可以根据一句subscriber.customer_id=account.customer_id就可以锁定对应的customer_id了。 所以语句就可以直接修改为下面的形式，因为业务上肯定是支持的，直接去除了customer表。 select subscriber.customer_id,subscriber.xxxx from subscriber,account where  subscriber.customer_id=xxxx and subscriber.customer_id and account.customer_id and subscriber.xxxx 世界中的关系还真是微妙，我想我们的关系就是linkedin要做的事情吧。而在脑洞大开联想起sql调优来看，在熟悉业务的基础上调优也会有一个大的提升。

来自 “ ITPUB博客 ” ，链接：http://blog.itpub.net/23718752/viewspace-1807666/，如需转载，请注明出处，否则将追究法律责任。