沒有列存的MySQL千萬級分析也能支援

自己原文公眾號： https://mp.weixin.qq.com/s/3mgeT93lP-PGCea0oZFDNA

 如果要做分析大家第一想到的是大資料。還想到了Oracle MySQL PG不行。我聽過不少人說，出報表去大資料啊。這個也不能說錯，但是請問報表多大？如果就是幾萬條資料一個excel輕鬆搞定。為什麼需要大資料？

    分析做的好的都是列式資料庫。行式資料庫在交易場景是必須的，在分析場景下，無用功多了，顯得有點慢。

   但是那是說在資料量巨大（請注意何為巨大）我認為1000萬一下都是常規得到。10億以上再說大也不遲。

    拿資料說話1000萬的一個表，硬查也就7秒左右（我這個列少，列數多會慢，如果有幾十列可能會20-30秒）如下圖紅框。（練習虛擬機器，低配未最佳化）

黃色框才是日常可能發生的聚合 count sum avg 等等。一天60毫秒。

藍色框才是業務常用的一個月度的小報表，1秒。

綠色框更加常見，某個使用者的一個月的資料。140毫秒。

白色框，是某個使用者的三個月的資料。380毫秒。

表結構如下：

可見在1000萬級別下，使用索引查詢。最慢的不超過1秒。（PG和Oracle 同樣下不得不說比MySQL還要快一點）

如果說用大資料去查，資料同步都不止這個時間。別說MapReduce的時間了。還有資料預熱和載入。

其實很多時候我們本地就能好好的完成任務了。

這是因為我們索引一共才3層。三次IO就行了。一次IO 5-10ms。所以說根本不可能慢。

select b.name,a.name,index_id,type,a.space,a.page_no from information_schema.innodb_sys_indexes a, information_schema.innodb_sys_tables b where a.table_id=b.table_id and a.space<>0 and b.name like '%money2%';

指定的偏移量的計算公式是page_no * innodb_page_size + 64。

49216 = 3 * 16384 +64 上面的49216是這麼來的。

這裡的0200是16進位制。看著有點費勁是吧？

因為原理是相同的，直接看Oracle的。