搞点多维分析，糙快猛的解决方案就是使用ROLAP（关系型OLAP）了。数据经维度建模后存储在MySQL，ROLAP引擎（比如开源的Mondrian）负责将OLAP请求转化为SQL语句提交给数据库。OLAP计算分析功能导致MySQL需要进行较多复杂SQL查询，性能调优必不可少，本文总结了一些实用原则。

OLAP的典型应用包括复杂动态报表，需要支持钻取（上卷和下钻）、切片、切块和旋转操作。下表总结了OLAP和OLTP系统的主要区别。OLAP的特点决定了SQL的查询场景和优化方案，下文将从索引、聚合、子查询、表连接和Pivoting等几个方面分别介绍。

OLAP

OLTP

用户量

分析人员用户量相对小

高并发

数据库设计

维度模型：星型、雪花型号

规范化

数据量

大，动辄千万级别

小，一般不超过百万级别

SQL读写场景

定期导入，一般无更新，复杂查询每次检索大量数据

以事务为单位每次读写少量数据

在权衡数据容错恢复和性能之后，存储引擎选择的是Innodb。Innodb索引的特性是主键聚集索引和B+Tree数据结构。利用这两个特性，能够提升数据导入和多维度组合切片的性能。

1)       数据导入速度

下图为Innodb表主键索引示意图，聚集索引使表中所有数据必须按照主键顺序存储在主键索引叶子节点上。如果不按照主键顺序导入数据，会导致额外的分页、数据查找、移动IO操作，这样，Innodb表的插入速度严重依赖于插入顺序。解决方法比较简单：主键使用Auto_Increment列。

2)       多维度切片

多维度组合查询、分组和汇总操作非常常见，那么在多个维度字段上添加复合索引是必不可少的，而复合索引的字段选择和顺序尤为重要。

谁排NO.1？一般遵循以下原则：

a)        Mysql只进行索引最左前缀匹配，可以选择最常查询的字段排首位。特殊情况：如果少量查询场景不存在该字段怎么处理？需要另外再建索引吗？假设在盘古系统中，运营单位一般会出现在所有查询中，所以会建立[运营单位，行业，产品线……]的复合索引，但某些高级别管理人员的查询语句中，不包含运营单位，那么需要再建立[行业，产品线……]的复合索引吗？答案是看情况，提供小技巧：应用层处理，在不包括运营单位条件的查询SQL中加入“运营单位 in（所有运营单位）”条件

b)        最佳性能优化原则决定索引区分度最大的字段排首位（可用count(distinct column)/count(*)计算）

还有个大家往往会忽略的问题，谁排最后呢？答案是：将可能存在范围条件检索的字段放最后。来个案例

假设建立的复合索引为[avg_cms_weekly,trade_id, ,balance]，那么由于在avg_csm_weekly上存在范围条件，MySQL不会使用剩余的索引。

MySQL不支持Hash聚合，仅支持流聚合。流聚合会先根据GROUP BY的字段进行排序，然后流式访问排序好的数据，进行分组聚合。如果在explain的extra列中看到Using temporary和Using filesort，说明聚合使用了临时表和文件排序操作，这可能导致性能低下。最佳优化目标是让聚合操作使用Covering Index，即完全不用查询表数据，只在索引上完成聚合查询。

下面查询语句会使用复合索引[trade_id,product_line_id]

观察查询计划，在extra列显示Using index，说明该操作为Covering Index查询。

在OLAP分析中，时间范围上的聚合操作非常普遍。下面以账号每日消费表为示例，总结几种常见的时间聚合查询模板

account_id（账户）

stdate(数据日期)

click_pay(点击消费)

1

2013-08-01

100

1

2013-08-02

150

2

2013-08-01

125

1）累计聚合

返回账户加入某度以来累计消费和平均值。