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查询条件内容请搜索脚本之家以前的文章或继续浏览下面的相关文章希望大家以后多多支持脚本之家！