問(wèn)答專(zhuān)欄Q & A COLUMN
商業(yè)智能BI 分析報(bào)表查詢(xún)慢，這是商業(yè)智能BI分析領(lǐng)域的一個(gè)常態(tài)。實(shí)際上，我們了解一下其中的原理，大概就能理解慢的原因，以及以后如何優(yōu)化的一個(gè)方向。
數(shù)據(jù)可視化 - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺(tái)
大部分的商業(yè)智能BI工具都是基于B/S 架構(gòu)的。B指的就是Browser 瀏覽器，S 指的就是 Server 服務(wù)器。每一次來(lái)自瀏覽器的點(diǎn)擊，都是通過(guò)HTTP協(xié)議像服務(wù)器發(fā)送一次 Request 請(qǐng)求，一次商業(yè)智能BI分析報(bào)表的查詢(xún)本質(zhì)上發(fā)送了一條 SQL 查詢(xún)命令到了應(yīng)用服務(wù)器端通過(guò)程序翻譯再到數(shù)據(jù)庫(kù)服務(wù)器做了一次數(shù)據(jù)查詢(xún)動(dòng)作。
如果這個(gè)商業(yè)智能BI分析報(bào)表的SQL查詢(xún)本身就比較復(fù)雜，底層數(shù)據(jù)模型建立的又不好，或者在數(shù)據(jù)庫(kù)服務(wù)器硬件環(huán)境配置本身也不好的情況下，這條SQL的執(zhí)行可能就需要花費(fèi)很長(zhǎng)的時(shí)間。這個(gè)是第一個(gè)時(shí)間損耗的點(diǎn)。
第二個(gè)點(diǎn)就是商業(yè)智能BI分析報(bào)表的SQL查詢(xún)可能返回了大量的數(shù)據(jù)，比如幾十萬(wàn)、上百萬(wàn)、上千萬(wàn)、上億的數(shù)據(jù)，這個(gè)數(shù)據(jù)最后打包通過(guò)HTTP協(xié)議Response響應(yīng)返回，需要通過(guò)網(wǎng)絡(luò)返回到Browser 瀏覽器端，幾十萬(wàn)的數(shù)據(jù)可能有上百兆MB，上百萬(wàn)、上千萬(wàn)的數(shù)據(jù)可能是幾百兆（MB）甚至一個(gè)GB的數(shù)據(jù)。大家試想一下平時(shí)下載個(gè)電影需要多長(zhǎng)時(shí)間，下載一個(gè)幾百兆的文件需要多長(zhǎng)時(shí)間，這個(gè)還跟網(wǎng)絡(luò)帶寬有很大的關(guān)系，這個(gè)是第二個(gè)時(shí)間損耗的點(diǎn)。
數(shù)據(jù)可視化 - 派可數(shù)據(jù)商業(yè)智能BI可視化分析平臺(tái)
數(shù)據(jù)返回到瀏覽器前端，在可視化圖表展現(xiàn)的時(shí)候，如果在商業(yè)智能BI分析報(bào)表中寫(xiě)了很多復(fù)雜的表達(dá)式、聚合函數(shù)，數(shù)據(jù)需要消耗本地瀏覽器所在電腦大量的內(nèi)存來(lái)完成數(shù)據(jù)的計(jì)算。前端指標(biāo)計(jì)算、條件表達(dá)式和各類(lèi)聚合函數(shù)設(shè)計(jì)的越多，需要的時(shí)間就越長(zhǎng)，這個(gè)就是第三個(gè)時(shí)間損耗的點(diǎn)。
最后就是頁(yè)面的渲染，商業(yè)智能BI分析報(bào)表中可視化圖表越多、結(jié)構(gòu)越復(fù)雜、列越多，數(shù)據(jù)渲染通過(guò)HTML組織到最后的呈現(xiàn)時(shí)間就越長(zhǎng)，這個(gè)就是第四個(gè)時(shí)間損耗的點(diǎn)。
到最后頁(yè)面全部加載完成，HTTP 請(qǐng)求終止與服務(wù)器斷開(kāi)連接。
評(píng)論0
加載中...
如果是普通的視圖，與復(fù)雜SQL的查詢(xún)區(qū)別就在于視圖減少了復(fù)雜SQL長(zhǎng)語(yǔ)句的傳輸，在99.99%的情況下你是很難測(cè)出兩者的區(qū)別，或者可以說(shuō)在當(dāng)下這些服務(wù)器和帶寬的狀態(tài)下，可以直接忽略這個(gè)細(xì)微的效率影響，當(dāng)成一致即可。
樓上有人說(shuō)到物化視圖，先說(shuō)明，這個(gè)是在oracle里面才特有的一個(gè)視圖，它是占用物理存儲(chǔ)的，在MySQL里面是沒(méi)有物化視圖等手段，但是可以通過(guò)一個(gè)簡(jiǎn)單的轉(zhuǎn)換達(dá)到差不多的效果，MySQL可以觸發(fā)器+存儲(chǔ)過(guò)程去跑出一個(gè)表，這個(gè)表映射出來(lái)查詢(xún)。
其實(shí)SQL的優(yōu)化要考慮比較多方面，結(jié)合起來(lái)處理才能真正消除慢SQL。
評(píng)論0
加載中...
先說(shuō)結(jié)論，不會(huì)。
原因有兩點(diǎn)，第一 視圖并不是獨(dú)立的存儲(chǔ)結(jié)構(gòu)，數(shù)據(jù)還是原來(lái)的數(shù)據(jù)，查詢(xún)的時(shí)候還是要執(zhí)行SQL，所以，原來(lái)的SQL慢，查詢(xún)視圖還是慢。
我們看看視圖的定義，視圖的概念VIEW （ 視 圖 ） 是 一 個(gè) 或 多 個(gè) 表 的 部 分 數(shù) 據(jù) ， 它 可 以 像 表 一 樣 進(jìn) 行 CRUD 操 作 ， 但 沒(méi) 有 具 體 的 存 儲(chǔ) 數(shù) 據(jù) 結(jié) 構(gòu) ， 它 以 一 個(gè) SELECTi? 句 的 形 式 存 在 數(shù) 據(jù) 庫(kù) 中 。 本 質(zhì) ： 一 條 有 名 字 的 SELECT 語(yǔ) 句 表 現(xiàn) ： 一 到 多 張 表 的 部 分 內(nèi) 容
視圖的優(yōu)點(diǎn)：
限制數(shù)據(jù)庫(kù)的訪(fǎng)問(wèn)
簡(jiǎn)化查詢(xún)
數(shù)據(jù)的獨(dú)立性
對(duì)同一數(shù)據(jù)有不同的表現(xiàn)
第二，復(fù)雜SQL與創(chuàng)建的視圖，區(qū)別僅僅是查詢(xún)時(shí)SQL從哪里來(lái)的區(qū)別，視圖是數(shù)據(jù)庫(kù)保存了SQL而已。
不知道是否回答了你的問(wèn)題，歡迎回復(fù)交流。
評(píng)論0
加載中...
并不會(huì)，視圖只是預(yù)編譯好的查詢(xún)，可以看做一個(gè)預(yù)先編寫(xiě)好的子查詢(xún)，沒(méi)有物理存儲(chǔ)，實(shí)際執(zhí)行時(shí)是先執(zhí)行視圖定義語(yǔ)句獲取視圖數(shù)據(jù)，再在視圖數(shù)據(jù)基礎(chǔ)上再次查詢(xún)，實(shí)際數(shù)據(jù)讀取上并無(wú)優(yōu)化。
評(píng)論0
加載中...
查詢(xún)過(guò)于復(fù)雜表連接過(guò)多的話(huà)是否可以將數(shù)據(jù)先加工好放入單表中再進(jìn)行查詢(xún)，建好相關(guān)索引?；蛘呖梢詮膕ql本身入手，是否有優(yōu)化的地方。正常view不會(huì)對(duì)性能有影響。
評(píng)論0
加載中...
一般情況是可以的，但也有一些特殊的情況是不行的。某些情況下，如果寫(xiě)成試圖性能會(huì)更差。慢的你懷疑人生
評(píng)論0
加載中...0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答0
回答
