一句玩笑之后的思考

本文通过一个具体的SQL查询案例探讨了如何在理解业务逻辑的基础上进行SQL优化。通过对查询条件的精简,实现了性能的有效提升。

摘要生成于 C知道 ,由 DeepSeek-R1 满血版支持, 前往体验 >

今天在微信上碰到某大师,简单聊了下。我和这位大师的关系也蛮有趣,最开始通过其他的渠道认识,还没有见过面,我向他推荐了我的一名前同事,没想到这位大洋彼岸的前同事竟然和这位大师也曾经是同事。真是翻洋过海也逃不出他的圈子啊。为了简单起见我简称大师为A,前同事为B,我为C,所以我就笑称既然这样,按照表的连接关系,A和B是同事,B和C是同事,那A和C也是同事了,听起来还是蛮有道理的吧。大师简单一句哈哈了事。
这个也就自己糊弄糊弄自己,猛意向似乎还确实是蛮有道理的。
如果把表的结构和sql语句结合起来,我还真找不出该怎么把这种关系给描述出来,索性画了个图,一看就不满足情况吧。

玩笑归玩笑,不过自己哪根筋搭错了,突然想起一个问题来,想起一个sql优化案例来。
有兴趣可以参考 通过图表简化sql语句的表关联   http://blog.itpub.net/23718752/viewspace-1455102/
我举一个略微简单的例子,有这么一条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调优来看,在熟悉业务的基础上调优也会有一个大的提升。
评论
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值