olap场景下应避免滥用b+树索引，因其对大表扫描、多列聚合等操作低效甚至有害；优先采用覆盖索引、“过滤→分组→覆盖”建索引顺序、分区裁剪及物化汇总表等更适合olap的策略。
OLAP场景下别乱建B+树索引
MySQL默认的InnoDB引擎用B+树索引，对点查、范围查友好，但OLAP查询常涉及大表扫描、多列聚合、GROUP BY、ORDER BY混合字段、高基数列过滤——这时B+树索引往往失效，甚至拖慢查询。比如在10亿行订单表上对order_status + created_at建联合索引，却执行SELECT COUNT(*) FROM orders WHERE region = 'south' GROUP BY product_category，索引大概率不会被用到。
关键判断点：如果WHERE条件里没有索引最左前缀，或GROUP BY字段不在索引覆盖范围内，或查询需要大量回表，那这个索引对OLAP就是低效甚至有害的。
- 避免在高基数时间字段（如
created_at）上单独建索引，除非查询明确带该字段的窄范围过滤 - 慎用
TEXT/JSON列上的全文索引——它们不支持统计类聚合，且MATCH ... AGAINST无法和SUM()混用 - 不要为每个WHERE字段都建单列索引；
InnoDB优化器通常只选一个索引，其余列仍需全表扫描
用覆盖索引减少回表和临时表
OLAP查询常要返回多列+聚合，若索引不包含SELECT中所有字段，MySQL就得回主键聚簇索引取数据，IO爆炸。更糟的是，如果GROUP BY或ORDER BY字段不在索引中，还会触发Using temporary; Using filesort——这是OLAP慢查询头号元凶。
实操建议：
- 把
WHERE过滤字段放索引最左，中间放GROUP BY字段，最后放SELECT中需要的非聚合列（即“过滤→分组→覆盖”顺序） - 例如：查询
SELECT region, COUNT(*), AVG(amount) FROM sales WHERE year = 2023 GROUP BY region，建索引INDEX idx_year_region (year, region, amount)比(year, region)更优——amount被覆盖，避免回表算AVG - 用
EXPLAIN FORMAT=TREE确认是否出现Using index；若看到Using where; Using index condition，说明索引生效但仍有部分过滤下推不到存储层
分区表不是银弹，但按时间切分对OLAP很实用
MySQL原生分区（PARTITION BY RANGE COLUMNS(created_at)）不能替代索引，但它能帮优化器快速裁剪掉无关分区，尤其适合按天/月归档的历史数据查询。注意：5.7+才支持RANGE COLUMNS，且分区键必须是索引一部分（含主键），否则建表失败。
常见陷阱：
- 分区过多（如按小时分1000个区）会导致打开表文件数暴增，触发
open_files_limit报错：ERROR 1864 (HY000): Table has no partition for value … - 跨分区
GROUP BY仍需合并结果，性能未必比单表好；应尽量让查询落在1–3个分区里 -
ALTER TABLE ... REORGANIZE PARTITION会锁表，大数据量下慎用；建议用EXCHANGE PARTITION配合临时表做滚动加载
真正适合OLAP的方案：别硬刚MySQL
当单表超5千万行、QPS不高但查询复杂度上升时，MySQL的优化空间迅速见顶。这时候强行调优索引、加缓存、拆JOIN，不如承认一个事实：InnoDB不是为OLAP设计的。
可落地的折中路径：
- 用
mysqldump或SELECT ... INTO OUTFILE定期导出冷数据到ClickHouse或Doris，它们对宽表、多维分析、近似去重（uniqCombined）原生支持 - 在MySQL内启用
columnstore插件（如MyRocks或MySQL 8.4+实验性列存引擎），但要注意其事务能力弱、DDL慢、生态工具支持少 - 如果必须用MySQL，至少把聚合结果物化：建
summary_sales_daily表，用EVENT每天凌晨跑INSERT ... SELECT GROUP BY，查询直接读汇总表
最常被忽略的一点：OLAP查询的“快”，本质是预计算 + 数据裁剪 + 列式压缩的组合效果；指望靠几个ALTER TABLE ADD INDEX解决，就像给自行车装涡轮增压——结构没变，瓶颈还在那儿。
