千萬級表JOIN 語句的優化原則

2021-09-24 03:47:20 字數 1515 閱讀 7373

-- mysql join 語句的優化原則-- mysql join 語句的優化原則

-- 1.小表驅動大表(explain的第一行是驅動表),where 條件驅動表的篩選j出盡量少的數

-- 2.where裡有篩選條件,而且可以使用索引,並對驅動表曬選出盡量少的行數

-- 3.非驅動表連線join欄位最好是主鍵索引,無法建立索引的時候,設定足夠的join buffer size

-- 4.盡量避免聯表數量,避免盡量少返回字段,避免返回欄位有計算,越多,巢狀迴圈演算法越慢,

-- 5.join連線表的語句不能再用子查詢,count(1) 分頁統計返回欄位要盡量少。

-- 6.掃瞄行數必須控制在百萬級別,返回行數控制在千級別,且要分頁處理.

-- 7.必須遵循以上原則,否則不用join,改單表查詢在拼接,或者用es查詢在拼接

-- mysql join 語句study

-- 1.小表驅動大表(explain的第一行是驅動表),where 條件驅動表的篩選小行數

-- 2.nestedloopjoin實際上就是通過驅動表的結果集作為迴圈基礎資料,然後一條一條的通過該結果集中的資料作為過濾條件到下乙個表中查詢資料,細節參考)

-- 3.a.無order by條件時,根據實際情況,使用left/right/inner join即可,根據explain優化;

-- 4.b.有order by a.col條件時,所有join必須為left join,且每個join欄位都建立索引,同時where條件中只能有a表的條件,即將其它表的資料關聯到a中形成一張大表,再對a的全集進行過濾;

-- 5.通過where預估結果行數,遵循以下規則:細節參考)

--    如果where裡沒有相應表的篩選條件,無論on裡是否有相關條件,預設為全表

--      如果where裡有篩選條件,但是不能使用索引來篩選,那麼預設為全表

--      如果where裡有篩選條件,而且可以使用索引,那麼會根據索引來預估返回的記錄行數

-- 6.mysql只支援一種join演算法:nested-loop join(巢狀迴圈連線),但nested-loop join有三種變種:細節參考)

--     6.1非驅動錶走主鍵索引不用回表,最快,

--     6.2沒有所以索引,預設情況下join_buffer_size=256k,在查詢的時候mysql會將所有的需要的列快取到join buffer當中

--     6.3對s表進行了rn次訪問,對資料庫開銷大

-- select *  from  a  left join b on a.id = b.id left join a.id = c.id,這時是怎麼順序進行執行的呢?

-- 我們得知是a表先和b表進行連線,會生成一張中間臨時表,然後這張表的資料再和c表進行連線,最後生成的表的資料就是a left join b left join c 的。

-- explain  all, index,  range, ref, eq_ref, const, system, null

mysql千萬級表關聯優化(2)

交代一下背景,這算是一次專案經驗吧,屬於公司乙個已上線平台的功能,這算是離職人員挖下的坑,隨著資料越來越多,原本的sql查詢變得越來越慢,使用者體驗特別差,因此sql優化任務交到了我手上。這個sql查詢關聯兩個資料表,乙個是攻擊ip使用者表主要是記錄ip的資訊,如第一次攻擊時間,位址,ip等等,乙個...

MySQL 對於千萬級的大表的優化?

第一 優化你的sql和索引 第二 加快取,memcached,redis 第三 以上都做了後,還是慢,就做主從複製或主主複製,讀寫分離,可以在應用層做,效率高,也可以用三方工具,第三方工具推薦360的atlas,其它的要麼效率不高,要麼沒人維護 第四 如果以上都做了還是慢,不要想著去做切分,mysq...

千萬級的大表!MySQL這樣優化更好

對於乙個千萬級的大表,現在可能更多的是億級資料量,很多人第一反應是各種切分,可結果總是事半功倍,或許正是我們優化順序的不正確。下面我們來談談怎樣的優化順序可以讓效果更好。mysql資料庫一般都是按照下面的步驟去演化,成本也是由低到高 1.避免使用select 2.可確定返回記錄數的,盡量增加limi...