商业智能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
回答
