思考大表統計的優化策略

以innodb表的count()統計為例子

#一千萬條資料count()耗費幾十秒，基本不用幹活

select count(*) from user

二、分段count，全表掃瞄轉變為範圍掃瞄

加上where條件，將全部查詢，拆分成多個小範圍查詢。

#全表掃瞄

select
count(*
)from
user
;#改為範圍掃瞄
select
count(*
)from
user
where id <
1000000
;select
count(*
)from
user
where id>=
1000000
and id <
200000;.
...

當然分表也屬於這類方法

大問題拆成多個小問題，將壓力分散。

如果是同一張表，需要開啟多個連線(多個程序)

如果分庫了，需要連線多個資料庫

雖然能減少時間，但是不能減小壓力，count()次數多了，系統也得嗝屁

二級索引key是索引列,value是主鍵，乙個資料頁上可以儲存更多資料，減少了分頁於頁內移動

#加了之後再統計，mysql解析器會自動選擇二級索引進行count

select
count(*
)from
user

能夠減少時間，也能減小io壓力，但是時間還是挺長的，我的機器上一千萬資料從5秒編成了1秒,1秒還是比較長

假如加上where條件呢,這個方法就用不上了

凡事預則立，不預則廢，設計時加一張tablename_stats表(兩個欄位key,value)，平時就維護好統計資料，增加時加1，刪除時減1。

keyvalue

count

1111

hash值(表名+where條件)

1111

提前準備

毫無壓力，效果完美

需要提前**好可能的統計以及條件

缺點存在統計資料與實際不一致，在大資料量情況下，也不算什麼問題

最終發現還是類似myisam維護乙個計數器是最好的方法。

而我們擴充套件了功能，加了where條件的也提前計數

此生必看的科學實驗-水知道答案

《了凡四訓》詳解之改過之法

印光大師十唸法（胡小林主講第1集）

精神病為什麼治不好

百病之源

mysql大表更新sql的優化策略

問題sql背景 專案有6個表的要根據pid欄位要寫入對應的brand id欄位。但是這個其中有兩個表是千萬級別的。我的worker執行之後，線上的mysql主從同步立刻延遲了！執行了乙個多小時之後，居然延遲到了40分鐘，而且只更新了十幾萬行資料。問題sql如下 根據商品id更新品牌id id upd...

mysql大表更新sql的優化策略

問題sql背景 專案有6個表的要根據pid欄位要寫入對應的brand id欄位。但是這個其中有兩個表是千萬級別的。我的worker執行之後，線上的mysql主從同步立刻延遲了！執行了乙個多小時之後，居然延遲到了40分鐘，而且只更新了十幾萬行資料。問題sql如下 update tablename se...

MySQL 建表的優化策略

mysql 建表的優化策略 目錄1.字符集的選擇 1 2.主鍵 1 3.外來鍵 2 4.索引 2 4.1.以下情況適合於建立索引 2 4.2.以下的情況下不適合建立索引 3 4.3.聯合索引 3 4.4.索引長度 4 5.特殊字段 4 5.1.冗餘字段 4 5.2.分割字段 4 5.3.blob和c...