前言

技術(shù)能解決的事情改技術(shù)

技術(shù)解決不了的事情該需求

現(xiàn)狀

假設(shè)我們目前有兩張表

業(yè)務(wù)表 書（ t_a_book ） 閱讀歷史記錄表 (t_r_book_history) 用戶表

其兩張表的數(shù)據(jù)邏輯如下

t_a_book

t_r_book_history

t_a_user

當(dāng)然了，我們假設(shè)當(dāng)前的數(shù)據(jù)量并不只是我們眼前看到的這幾條數(shù)據(jù)，而是線上真實(shí)情況。

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

問題一

這時(shí)候，我們需要面臨第一個(gè)業(yè)務(wù)問題，

我們需要做一個(gè)報(bào)表，顯示用戶閱讀圖書的記錄，并顯示用戶名，用戶號(hào)，書名

這時(shí)候我們?nèi)绾卧O(shè)計(jì)查詢SQL

多表聯(lián)查

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;

查詢出來的結(jié)果為

其邏輯為

• 數(shù)據(jù)庫根據(jù)release_time倒序查詢數(shù)據(jù)表，取出倒序的數(shù)據(jù)
• 根據(jù)左連接獲取 用戶信息
• 根據(jù)左連接獲取 圖書信息

單表查詢

如果此時(shí)我們選擇化繁為簡(jiǎn)，使用單表的查詢方法，來查詢數(shù)據(jù)其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 ();

其數(shù)據(jù)邏輯與多表聯(lián)查一致，唯一不同的便是需要查詢?nèi)?/p>

結(jié)論

我們可以看，當(dāng)前兩種查詢方式的邏輯來看。

主要會(huì)存在的流量壓力在與 t_r_book_history 這張表上面

當(dāng)數(shù)據(jù)量大的時(shí)候，我們只需要根據(jù)release_time 做索引，簡(jiǎn)化這一步的操作。

后續(xù)都可以使用主鍵來簡(jiǎn)化操作

由此來看，兩個(gè)語句其實(shí)在本質(zhì)上沒有明顯的快慢之分

問題二

現(xiàn)在我們需要增加兩個(gè)查詢條件

• 用戶名稱，支持模糊查詢
• 書名信息，支持模糊查詢

如果這時(shí)候，我們?nèi)绾尉帉慡QL

多表聯(lián)查

如果我們使用多表聯(lián)查的思路來填寫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;

顯示的數(shù)據(jù)

其邏輯為

• 查詢用戶表，根據(jù)其用戶名稱進(jìn)行模糊查詢
• 查詢書表，根據(jù)書名進(jìn)行模糊查詢
• 根據(jù)用戶主鍵，書籍主鍵作為查詢條件來進(jìn)行查詢

單表查詢

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 ();

其查詢邏輯與多表聯(lián)查一致

問題

現(xiàn)在主要的問題在于 ， t_a_user , t_a_book , t_r_book_history 這三張表都是大表，

我們使用的查詢條件也十分的模糊

簡(jiǎn)單的說 ， 無論我們使用哪種方法， 都有可能會(huì)出現(xiàn)幾十萬個(gè)符合的結(jié)果

因此，我們無論使用哪種編寫方法 ， 這個(gè)SQL都是不可行的

如何解決

文章寫到這里，我們會(huì)發(fā)現(xiàn)這個(gè)問題，已經(jīng)不能停留再技術(shù)成面的問題。

因此，我們就只能修改需求

我們這里的問題 ， 是這兩張表的查詢條件。他十分的模糊，我們無法將范圍限制在幾條，幾十條，甚至幾百條內(nèi)。

既然這樣，我們就只能跟需求方表示，這個(gè)查詢條件必須使用十分“明確”的數(shù)據(jù)

例如對(duì)于用戶，我們常常能用什么來明確指向一個(gè)用戶呢？

id,數(shù)據(jù)主鍵，手機(jī)號(hào)碼

我們?nèi)绾未_定一本書呢？我們可以用一個(gè)ISBN

修改這兩個(gè)查詢條件，才能將這個(gè)不能解決的問題，修改為解決

但是，有人說，我們是技術(shù)。不能對(duì)產(chǎn)品提這樣的想法，

但是我想說，你是打算在將來來查詢卡半分鐘的時(shí)候說，說服所有人這個(gè)東西不關(guān)我的事

還是說，在未開發(fā)前說服產(chǎn)品

到此這篇關(guān)于MySQL詳解如何優(yōu)化查詢條件的文章就介紹到這了,更多相關(guān)MySQL查詢條件內(nèi)容請(qǐng)搜索腳本之家以前的文章或繼續(xù)瀏覽下面的相關(guān)文章希望大家以后多多支持腳本之家！