Mysql为何不推荐写多表SQL

前言

  1. 在大部分情况下,单表并不是比多表快
  2. 单表优势在于理解成本与可控性
  3. 有时候你觉得单表SQL不好写的时候,你改更新的是表结构

现状

在我们学习MySql的路程之中,估计不少人告诫我们不要写长语句。
至于为什么,确实很少人提起。
下面我们就拿现状做例子 ,
我们再次拿图书馆系统的老三张表作为例子,会有些改动的只不过我们给这些表增添了一些小细节

图书表

在这里插入图片描述

用户表

在这里插入图片描述

用户阅读历史记录表

在这里插入图片描述

两种查询的效率

关于查询的效率,大家可以从上篇文章之中看到具体过程,这里不再复述。 (主要懒得再写一遍)
上一篇文章

主要的结论便是,其实对于一条查询语句来说,无论我们写哪种语句。效率都是相差无几的(大部分情况下)
(从严谨上来说,甚至多表联查是更加节省资源,快速的一种方法。但是,这种节省资源的“方式” , 并不会影响核心速率 )

所以,如果只是为了速度,这个并不是劝谏他人的理由

问题

假设,我们现在遇见一个问题。

我们需要实现一个报表,主要查询条件为

  1. 书本ISBN号,可一次性输入十个 (必选)
  2. 用户手机号,可一次性输入十个(必选)
  3. 根据用户等级进行筛选
  4. 根据图书类型进行筛选
  5. 根据借阅时间倒序

那么复合SQL的查询逻辑是什么样的呢


SELECT * FROM t_r_book_history bh 
	LEFT JOIN t_a_user u ON bh.user_id = u.id 
	LEFT JOIN t_a_book b ON bh.book_id = b.id 
WHERE 
	bh.record_flag = 1 
	AND b.id IN `#{isbn}`
	AND b.book_type = 1
	AND u.user_id IN `#{userIdList}`
	AND u.user_rank = 1
ORDER BY bh.release_time DESC LIMIT 10;

使用单表查询的SQL是什么呢?


SELECT user_id FROM t_a_user WHERE id IN `#{isbn}` and user_rank=1;

SELECT book_id FROM t_a_book WHERE user_id IN `#{userIdList}` and book_tyoe=1;

SELECT * from t_r_book_history WHERE record_flag=1 and user_id IN (`#{userIdList}`) AND book_id IN `#{bookIdList}` ORDER BY release_time LIMIT 10;

从运行速度上来说 , 使用单表查询不如多表联查
但是,你能说的清除多表查询的运行逻辑吗?
对于不同版本的SQL,对于多表联查。他有着自己的优化器。他会自己去制定一个执行计划,在某些更加复杂的情况下。便经常会出现无法执行某个表的索引的情况
(对于某些业务,经常出现一个屏幕都装不下的SQL )
但是对于单表查询来说, 他的运行逻辑是透明的,可读的,更加容易理解的。未来的自己,后续的开发人员,都能更加容易的读懂,此刻写下代码的你

  • 1
    点赞
  • 6
    收藏
    觉得还不错? 一键收藏
  • 2
    评论

“相关推荐”对你有帮助么?

  • 非常没帮助
  • 没帮助
  • 一般
  • 有帮助
  • 非常有帮助
提交
评论 2
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

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

抵扣说明:

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

余额充值