sql 查询-从浆糊到清晰的过程
記錄從給一個(gè)查詢需求整理自己的思路.
當(dāng)新手菜鳥遇到一個(gè)新的需求時(shí), 往往 理不清楚 業(yè)務(wù)的思路. 導(dǎo)致sql寫不出來.
當(dāng)今互聯(lián)網(wǎng)的需求增多, 程序很多放到 語言層面去處理了, 只要做單表查詢就可以滿足需求, 造成
很多人寫sql依然還是老大難.
?
記錄我整理遺留業(yè)務(wù)造成線上功能加載1分鐘才能展示問題:
?業(yè)務(wù)比較復(fù)雜, 當(dāng)初設(shè)計(jì)的人也都走光了. 一個(gè)簡單的業(yè)務(wù), 居然需要表關(guān)聯(lián)十多張表才能得到一個(gè)想要的sql結(jié)果集.
而sql線上執(zhí)行都在40秒到1分鐘左右.
很是痛苦. 看到一個(gè)訂單表中, 拿一個(gè)訂單生成時(shí)間, 還需要到一個(gè)日志表中關(guān)聯(lián)獲取, 都要罵娘了, 且日志存到了mysql里...
這個(gè)也是無語的.
我也是新手. 這兩年多的業(yè)務(wù)做的基本也是以 語言層面為主. sql多是些 簡單的查詢.? 導(dǎo)致一直沒有 深入.?
遇到這個(gè)業(yè)務(wù)后. 就更加體會(huì)到 sql的重要性.?
?
拿到業(yè)務(wù), 了解業(yè)務(wù)需求之后, 通過對數(shù)據(jù)庫表, 是最快可以全面掌握解決方案的.
反問法:? (針對查詢業(yè)務(wù))
1. 要什么數(shù)據(jù)?
2. 要誰的數(shù)據(jù)??
3. 要哪個(gè)時(shí)間段的數(shù)據(jù)?
?
一般要什么數(shù)據(jù), 那他就是作為主線了, 以它的維度, 去考慮.
多表關(guān)聯(lián)時(shí), 一定要注意 笛卡爾積的問題.? wait?? 啥是笛卡爾積? 我忘了.?
笛卡爾積: 當(dāng)你的主表與其他表做關(guān)聯(lián)時(shí),.主表可能 就會(huì)查詢出很多數(shù)據(jù).?
當(dāng)在去與關(guān)聯(lián)表去 inner或者left? join時(shí), 會(huì)拿著主表查詢出的數(shù)據(jù) 依次去與關(guān)聯(lián)表匹配.
假設(shè):? 主表查詢出 2w條數(shù)據(jù), 關(guān)聯(lián)表給的條件又能查出5000條,??
結(jié)果在關(guān)聯(lián)時(shí), 會(huì)拿著2w條依次去和5k條匹配. 也就是 2w *乘以?5k的效果.
再說點(diǎn)好理解的, 我給你2萬把鑰匙, 你要試出哪些 能開這5k把鎖. 這能快嗎...
怎樣可以提高查詢效率呢.
可以單次只拿少量的鑰匙, 去匹配. 這是我這次的解決方案.?
先寫個(gè)簡單的sql, mysql的話, 使用limit 0,10, 每次只取10條,
用這個(gè)簡單sql作為一個(gè)臨時(shí)表, 在和關(guān)聯(lián)表匹配. 效率就高了
還有, 就是? 內(nèi)連接和 左連接? inner和 left的使用掌握不好, 不知道何時(shí)用哪個(gè).
思路:? 這個(gè)思路不絕對.?
還是基于第一個(gè)簡單的sql, 查詢出的結(jié)果如果都對的話, 關(guān)聯(lián)其他表, 基本都是取一些 相關(guān)聯(lián)的字段了
如果表關(guān)聯(lián), 數(shù)量保持單表查詢時(shí)的數(shù)量, 一般情況可以假設(shè)是 關(guān)聯(lián)的關(guān)鍵字用對了,
如果單表查詢與關(guān)聯(lián)后數(shù)量不一致了, 可以做個(gè)分組, 還不一致, 就可以考慮, 換個(gè) 關(guān)聯(lián)關(guān)鍵字了.?
如果使用inner后, 數(shù)量少了, 說明關(guān)聯(lián)后, 沒有匹配到數(shù)據(jù),? ?造成把兩個(gè)表中的數(shù)據(jù)都舍棄了
就要換成left了, 起碼保留主表數(shù)據(jù).
除非. 要求兩個(gè)表的數(shù)據(jù)要么都要, 要么都沒有這種, 就使用inner join
暫時(shí)總結(jié)這么多, 留著自己復(fù)習(xí)理解吧
?
總結(jié)
以上是生活随笔為你收集整理的sql 查询-从浆糊到清晰的过程的全部內(nèi)容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: Netty高性能之道
- 下一篇: 用C处理字符串:键盘输入“yes”,则输