MySQL详解如何优化查询条件

 更新时间:2022年05月21日 08:43:54   作者:会喷火才能叫火山  
我们知道从MySQL表中使用SELECT语句来查询数据,如需有条件地从表中选取数据,可将WHERE子句添加到SELECT语句中,本篇我们来看看怎样优化查询条件

前言

技术能解决的事情改技术

技术解决不了的事情该需求

现状

假设我们目前有两张表

业务表 书( t_a_book ) 阅读历史记录表 (t_r_book_history) 用户表

其两张表的数据逻辑如下

t_a_book

t_r_book_history

t_a_user

当然了,我们假设当前的数据量并不只是我们眼前看到的这几条数据,而是线上真实情况。

每张表至少都是10w+起步

问题一

这时候,我们需要面临第一个业务问题,

我们需要做一个报表,显示用户阅读图书的记录,并显示用户名,用户号,书名

这时候我们如何设计查询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 
ORDER BY bh.release_time DESC LIMIT 10;

查询出来的结果为

其逻辑为

  • 数据库根据release_time倒序查询数据表,取出倒序的数据
  • 根据左连接获取 用户信息
  • 根据左连接获取 图书信息

单表查询

如果此时我们选择化繁为简,使用单表的查询方法,来查询数据其SQL为

SELECT * FROM t_r_book_history bh 
WHERE 
	bh.record_flag = 1 
ORDER BY bh.release_time DESC LIMIT 10;
// 用户信息
SELECT * FROM t_a_user u WHERE u.id IN ();
// 图书信息
SELECT * FROM t_a_books b WHERE u.id IN ();

其数据逻辑与多表联查一致,唯一不同的便是需要查询三次

结论

我们可以看,当前两种查询方式的逻辑来看。

主要会存在的流量压力在与 t_r_book_history 这张表上面

当数据量大的时候,我们只需要根据release_time 做索引,简化这一步的操作。

后续都可以使用主键来简化操作

由此来看,两个语句其实在本质上没有明显的快慢之分

问题二

现在我们需要增加两个查询条件

  • 用户名称,支持模糊查询
  • 书名信息,支持模糊查询

如果这时候,我们如何编写SQL

多表联查

如果我们使用多表联查的思路来填写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.name like "四%"
	and u.name like "张%"
ORDER BY bh.release_time DESC LIMIT 10;

显示的数据

其逻辑为

  • 查询用户表,根据其用户名称进行模糊查询
  • 查询书表,根据书名进行模糊查询
  • 根据用户主键,书籍主键作为查询条件来进行查询

单表查询

SELECT * FROM t_a_user WHERE user_name LIKE "张%"
SELECT * FROM t_a_book WHERE user_name LIKE "四%"
SELECT * FROM t_r_book_history bh 
WHERE 
	bh.record_flag = 1 
ORDER BY bh.release_time DESC LIMIT 10;
// 用户信息
SELECT * FROM t_a_user u WHERE u.id IN ();
// 图书信息
SELECT * FROM t_a_books b WHERE u.id IN ();

其查询逻辑与多表联查一致

问题

现在主要的问题在于 , t_a_user , t_a_book , t_r_book_history 这三张表都是大表,

我们使用的查询条件也十分的模糊

简单的说 , 无论我们使用哪种方法, 都有可能会出现几十万个符合的结果

因此,我们无论使用哪种编写方法 , 这个SQL都是不可行的

如何解决

文章写到这里,我们会发现这个问题,已经不能停留再技术成面的问题。

因此,我们就只能修改需求

我们这里的问题 , 是这两张表的查询条件。他十分的模糊,我们无法将范围限制在几条,几十条,甚至几百条内。

既然这样,我们就只能跟需求方表示,这个查询条件必须使用十分“明确”的数据

例如对于用户,我们常常能用什么来明确指向一个用户呢?

id,数据主键,手机号码

我们如何确定一本书呢?我们可以用一个ISBN

修改这两个查询条件,才能将这个不能解决的问题,修改为解决

但是,有人说,我们是技术。不能对产品提这样的想法,

但是我想说,你是打算在将来来查询卡半分钟的时候说,说服所有人这个东西不关我的事

还是说,在未开发前说服产品

到此这篇关于MySQL详解如何优化查询条件的文章就介绍到这了,更多相关MySQL查询条件内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!

相关文章

  • com.mysql.jdbc.Driver 和 com.mysql.cj.jdbc.Driver 的区别

    com.mysql.jdbc.Driver 和 com.mysql.cj.jdbc.Driver&n

    大家在连接mysql的时候,启动项目,会警告你推荐使用com.mysql.cj.jdbc.Driver 而不是com.mysql.jdbc.Driver,本文主要介绍了com.mysql.jdbc.Driver 和 com.mysql.cj.jdbc.Driver 的区别,具有一定的参考价值,感兴趣的可以了解一下
    2024-03-03
  • Oracle与MySQL的区别及优缺点

    Oracle与MySQL的区别及优缺点

    这篇文章主要介绍了Oracle与MySQL的区别及优缺点,文章围绕主题展开详细的内容介绍,具有一定的参考价值,需要的小伙伴可以参加一下
    2022-08-08
  • 浅谈mysql双层not exists查询执行流程

    浅谈mysql双层not exists查询执行流程

    本文主要介绍了浅谈mysql双层not exists查询执行流程,文中通过示例代码介绍的非常详细,对大家的学习或者工作具有一定的参考学习价值,需要的朋友们下面随着小编来一起学习学习吧
    2023-06-06
  • MySQL主键批量修改的坑与解决方案

    MySQL主键批量修改的坑与解决方案

    在日常开发中,我们可能会遇到需要批量修改 MySQL 数据表主键的情况,乍一看,修改主键 ID 似乎是一个简单的操作,但如果处理不当,会导致操作失败甚至数据丢失,本文将详细剖析问题成因,并总结多种安全高效的解决方案,需要的朋友可以参考下
    2024-12-12
  • 完美解决mysql in条件语句只读取一条信息问题的2种方案

    完美解决mysql in条件语句只读取一条信息问题的2种方案

    使用mysql多表查询时一个表中的某个字段作为另一表的in查询条件,只能读取一条信息,而直接用数字的话可以正常读取
    2018-04-04
  • MySQL密码策略管理插件validate_password用法详解

    MySQL密码策略管理插件validate_password用法详解

    自MySQL5.6起,引入validate_password插件,用于密码长度和强度管理,在MySQL8.0中,该插件通过服务器组件重新实现,插件默认不允许密码为用户名,可设定最小长度和强度等级,还可要求密码包含数字、大小写字母和特殊字符
    2024-11-11
  • 与MSSQL对比学习MYSQL的心得(五)--运算符

    与MSSQL对比学习MYSQL的心得(五)--运算符

    MYSQL中的运算符很多,这一节主要讲MYSQL中有的,而SQLSERVER没有的运算符
    2014-06-06
  • MySQL中处理各种重复的一些方法

    MySQL中处理各种重复的一些方法

    这篇文章主要介绍了MySQL中处理各种重复的一些方法,包括对表和查询结果的重复的一些处理,需要的朋友可以参考下
    2015-05-05
  • MySQL日志系统详细资料分享

    MySQL日志系统详细资料分享

    本文给大家汇总介绍了一下MySQL中的日志系统的详细资料,非常的细致,有需要的小伙伴可以参考下
    2017-02-02
  • mysql主从同步原理及应用场景示例详解

    mysql主从同步原理及应用场景示例详解

    这篇文章主要为大家介绍了mysql主从同步原理及应用场景示例详解,有需要的朋友可以借鉴参考下,希望能够有所帮助,祝大家多多进步,早日升职加薪
    2022-08-08

最新评论