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解决，就像给自行车装涡轮增压——结构没变，瓶颈还在那儿。
