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