MySQL详解如何优化查询条件
前言
技术能解决的事情改技术
技术解决不了的事情该需求
现状
假设我们目前有两张表
业务表 书( 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查询条件内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家!
相关文章
MySQL高效模糊搜索之内置函数locate instr position find_in_set使用详解
在MySQL中一般进行模糊搜索都是使用LIKE配合通配符进行查询的,在性能上一定的影响,下面给大家分享MYSQL自带的内置模糊搜索函数,除最后一个外其它三个性能上要比Like快些2018-09-09Mysql错误1366 - Incorrect integer value解决方法
这篇文章主要介绍了Mysql错误1366 - Incorrect integer value解决方法,本文通过修改字段默认值解决,需要的朋友可以参考下2014-09-09
最新评论