如何在MySQL JOIN查询中合理利用Cell+Time复合主键索引？

1. 强制指定使用复合主键索引 #

MySQL优化器偶尔会因为统计信息偏差或成本估算失误，放弃使用复合主键而选择单键索引。你可以在查询里显式强制调用主键索引，试试这个写法：

SELECT 
    h.Time,
    SUM(h.counter1) AS kpi1,
    SUM(h.counter2) AS kpi2,
    -- 剩下的838个KPI聚合逻辑同理补充
    ...
FROM h_cell h
FORCE INDEX (PRIMARY)
JOIN clusters_cust c ON h.Cell = c.Cell
WHERE c.Cluster = '用户指定集群' 
  AND h.Time BETWEEN '起始日期' AND '结束日期'
GROUP BY h.Time;

注意：强制索引不是万能的，如果目标集群包含90%以上的Cell这类极端数据分布场景，可能反而变慢，一定要实际测试验证效果。

2. 更新表统计信息 #

优化器选择索引完全依赖表的统计信息，如果统计信息过时，很容易做出错误判断。先执行以下命令更新统计：

ANALYZE TABLE h_cell;
ANALYZE TABLE clusters_cust;

MyISAM的ANALYZE TABLE会更新索引的分布统计，帮助优化器更准确判断使用复合索引的成本。

3. 拆分查询，避免JOIN/子查询的模糊性 #

如果业务流程允许，拆分两步查询：先把目标集群对应的所有Cell查出来，再把这些Cell作为常量直接写进主查询，不用JOIN或者IN子查询关联。比如：

-- 第一步：获取目标集群的所有Cell列表
SELECT Cell FROM clusters_cust WHERE Cluster = '用户指定集群';

-- 第二步：将上面得到的Cell列表作为IN条件传入主查询
SELECT 
    h.Time,
    SUM(h.counter1) AS kpi1,
    ...
FROM h_cell h
WHERE h.Cell IN ('cell_001', 'cell_002', ..., 'cell_N')
  AND h.Time BETWEEN '起始日期' AND '结束日期'
GROUP BY h.Time;

这样优化器能明确知道要过滤的Cell数量，更容易选择(Cell,Time)复合索引——先按Cell过滤，再按Time范围筛选，还能利用索引的有序性快速完成分组。

4. 给表按时间分区 #

你的表存储了2年的日统计数据，且查询经常按时间范围过滤，给h_cell按Time字段分区（比如按月）能大幅减少扫描的数据量，配合复合索引效果会更好：

-- 示例：按月份分区（根据你的实际时间范围调整分区规则）
ALTER TABLE h_cell
PARTITION BY RANGE (TO_DAYS(Time)) (
    PARTITION p202201 VALUES LESS THAN (TO_DAYS('2022-02-01')),
    PARTITION p202202 VALUES LESS THAN (TO_DAYS('2022-03-01')),
    -- 依次添加后续月份的分区
    ...
    PARTITION p202401 VALUES LESS THAN (TO_DAYS('2024-02-01'))
);

分区后，查询指定时间范围时只会扫描对应的分区，优化器会更倾向于使用(Cell,Time)复合索引，因为整体扫描范围缩小了很多。

5. 考虑转换为InnoDB引擎 #

MyISAM的主键是普通唯一索引，查询需要回表到数据文件；而InnoDB的主键是聚簇索引，数据按主键顺序存储，(Cell,Time)主键的查询不需要回表（所有计数器字段都在聚簇索引中），性能会更稳定。如果业务允许，试试转换引擎：

ALTER TABLE h_cell ENGINE=InnoDB;

转换前一定要备份数据，另外InnoDB和MyISAM的锁机制、事务特性不同，需要评估业务兼容性。

内容的提问来源于stack exchange，提问作者Ivaylo