#表結構如圖所示。
目前資料量是8000W行。
請問有什麼優化的方法和想法嗎?
count(*)不會統計每一列的值(不管是否為null),而是直接統計行數,效率要高些;
另外也可以用排除法,例如platform是qq的資料很多,可以用總的資料減掉platform=other的資料;
從業務上來考慮,精確值獲取成本很高,然而近似值成本較低,如果要求不嚴格,可以用近似值代替;
另外也可以考慮用redis等「記憶體資料庫」來維護這種取得耗時的資料;
1.如果當我遇到這樣的問題的話,我的解決辦法是新建一個表,例如playfrom_count來統計. 框架中如果用after_insert以及after_delete這樣的方法更好,如果沒有的話就自己寫一個. 2.如果這樣的查詢業務量不是很大的話,或者不是很精確的話,可以做一個任務去跑.每隔一段時間更新一次.3.無論你是innodb還是myisam,因為你添加了where所以都會對全表進行掃描.所以可以透過新增主鍵來增加檢索速度.
方案1. 對platform建立分區表方案2. 按platform分錶方案3. 對platform建單獨索引,不過考慮你platform的值集應該不會很大,這樣做索引不合適
這個問題在經典的關係型資料庫都會遇到,通用的解決方法是去存取系統表,裡面有每個表的資料行數,速度比你 COUNT(*) 快無數倍。
升級下機器吧,怎麼簡單的count都要20s,雖然有很多辦法比如分區表,但是感覺投入得不償失.
建議先考慮一下業務場景的需求,單純從技術方面考慮的解決方案成本過高,很多時候基本上實施不了。 可能的解決方案有:1、分錶:依照platform分為多個表,儲存引擎為MyISAM,查詢語句改為count(*),MyISAM會保存表格的總行數,因此查詢效率很有極大的提升。需考慮分錶對系統改造的工作量、MyISAM不支援事務是否能滿足系統需求。
2、建立冗餘表或字段,把需要匯總的資料在變更時重新計算,需要考慮大量的更新操作是否加大系統的負載。
3、如果對查詢結果不要求時完全精確的,可以定時計算結果並保存起來,查詢的時候不在直接查詢原表。
這種情況下可以依照月或季度等分成多個統計表,例如你800萬數據,新建一張表,每一行代表一個月的總記錄。這樣再統計就會快很多。
count(*)不會統計每一列的值(不管是否為null),而是直接統計行數,效率要高些;
另外也可以用排除法,例如platform是qq的資料很多,可以用總的資料減掉platform=other的資料;
從業務上來考慮,精確值獲取成本很高,然而近似值成本較低,如果要求不嚴格,可以用近似值代替;
另外也可以考慮用redis等「記憶體資料庫」來維護這種取得耗時的資料;
1.如果當我遇到這樣的問題的話,我的解決辦法是新建一個表,例如playfrom_count來統計.
框架中如果用after_insert以及after_delete這樣的方法更好,如果沒有的話就自己寫一個.
2.如果這樣的查詢業務量不是很大的話,或者不是很精確的話,可以做一個任務去跑.每隔一段時間更新一次.
3.無論你是innodb還是myisam,因為你添加了where所以都會對全表進行掃描.所以可以透過新增主鍵來增加檢索速度.
方案1. 對platform建立分區表
方案2. 按platform分錶
方案3. 對platform建單獨索引,不過考慮你platform的值集應該不會很大,這樣做索引不合適
這個問題在經典的關係型資料庫都會遇到,通用的解決方法是去存取系統表,裡面有每個表的資料行數,速度比你 COUNT(*) 快無數倍。
升級下機器吧,怎麼簡單的count都要20s,雖然有很多辦法比如分區表,但是感覺投入得不償失.
建議先考慮一下業務場景的需求,單純從技術方面考慮的解決方案成本過高,很多時候基本上實施不了。
可能的解決方案有:
1、分錶:依照platform分為多個表,儲存引擎為MyISAM,查詢語句改為count(*),MyISAM會保存表格的總行數,因此查詢效率很有極大的提升。需考慮分錶對系統改造的工作量、MyISAM不支援事務是否能滿足系統需求。
2、建立冗餘表或字段,把需要匯總的資料在變更時重新計算,需要考慮大量的更新操作是否加大系統的負載。
3、如果對查詢結果不要求時完全精確的,可以定時計算結果並保存起來,查詢的時候不在直接查詢原表。
這種情況下可以依照月或季度等分成多個統計表,例如你800萬數據,新建一張表,每一行代表一個月的總記錄。這樣再統計就會快很多。