一個(gè)復(fù)雜的查詢sql速度會比把sql建立成視圖來查詢速度更快嗎？

商業(yè)智能BI 分析報(bào)表查詢慢，這是商業(yè)智能BI分析領(lǐng)域的一個(gè)常態(tài)。實(shí)際上，我們了解一下其中的原理，大概就能理解慢的原因，以及以后如何優(yōu)化的一個(gè)方向。

數(shù)據(jù)可視化 - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺

大部分的商業(yè)智能BI工具都是基于B/S 架構(gòu)的。B指的就是Browser 瀏覽器，S 指的就是 Server 服務(wù)器。每一次來自瀏覽器的點(diǎn)擊，都是通過HTTP協(xié)議像服務(wù)器發(fā)送一次 Request 請求，一次商業(yè)智能BI分析報(bào)表的查詢本質(zhì)上發(fā)送了一條 SQL 查詢命令到了應(yīng)用服務(wù)器端通過程序翻譯再到數(shù)據(jù)庫服務(wù)器做了一次數(shù)據(jù)查詢動作。

如果這個(gè)商業(yè)智能BI分析報(bào)表的SQL查詢本身就比較復(fù)雜，底層數(shù)據(jù)模型建立的又不好，或者在數(shù)據(jù)庫服務(wù)器硬件環(huán)境配置本身也不好的情況下，這條SQL的執(zhí)行可能就需要花費(fèi)很長的時(shí)間。這個(gè)是第一個(gè)時(shí)間損耗的點(diǎn)。

第二個(gè)點(diǎn)就是商業(yè)智能BI分析報(bào)表的SQL查詢可能返回了大量的數(shù)據(jù)，比如幾十萬、上百萬、上千萬、上億的數(shù)據(jù)，這個(gè)數(shù)據(jù)最后打包通過HTTP協(xié)議Response響應(yīng)返回，需要通過網(wǎng)絡(luò)返回到Browser 瀏覽器端，幾十萬的數(shù)據(jù)可能有上百兆MB，上百萬、上千萬的數(shù)據(jù)可能是幾百兆（MB）甚至一個(gè)GB的數(shù)據(jù)。大家試想一下平時(shí)下載個(gè)電影需要多長時(shí)間，下載一個(gè)幾百兆的文件需要多長時(shí)間，這個(gè)還跟網(wǎng)絡(luò)帶寬有很大的關(guān)系，這個(gè)是第二個(gè)時(shí)間損耗的點(diǎn)。

數(shù)據(jù)可視化 - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺

數(shù)據(jù)返回到瀏覽器前端，在可視化圖表展現(xiàn)的時(shí)候，如果在商業(yè)智能BI分析報(bào)表中寫了很多復(fù)雜的表達(dá)式、聚合函數(shù)，數(shù)據(jù)需要消耗本地瀏覽器所在電腦大量的內(nèi)存來完成數(shù)據(jù)的計(jì)算。前端指標(biāo)計(jì)算、條件表達(dá)式和各類聚合函數(shù)設(shè)計(jì)的越多，需要的時(shí)間就越長，這個(gè)就是第三個(gè)時(shí)間損耗的點(diǎn)。

最后就是頁面的渲染，商業(yè)智能BI分析報(bào)表中可視化圖表越多、結(jié)構(gòu)越復(fù)雜、列越多，數(shù)據(jù)渲染通過HTML組織到最后的呈現(xiàn)時(shí)間就越長，這個(gè)就是第四個(gè)時(shí)間損耗的點(diǎn)。

到最后頁面全部加載完成，HTTP 請求終止與服務(wù)器斷開連接。