时间字段必须单独建b-tree索引，因复合索引（如device_id, time）无法支持纯时间范围查询；应优先创建单列索引idx_time on metrics(ts)，再按需添加复合索引，并避免函数操作、确保排序字段与索引顺序一致、选用bigint存储时间戳以提升性能。
时间字段必须单独建 B-tree 索引，别信“复合索引能覆盖所有查询”
海量时序数据（比如每秒写入上万条的监控指标）最常查的是 WHERE time BETWEEN ? AND ?，这时 time 字段必须有独立的 B-tree 索引。MySQL 的 B-tree 索引天然适合范围扫描，而很多人误以为加在复合索引最左列就行——但若复合索引是 (device_id, time)，查纯时间范围时根本用不上，因为 device_id 没出现在 WHERE 条件里，索引无法跳过前导列。
实操建议：
- 对高频时间范围查询的字段（如
created_at、ts），优先建立单列索引：CREATE INDEX idx_time ON metrics (ts); - 如果同时按设备+时间查，再补一个
(device_id, ts)复合索引，但不要指望它替代单列ts索引 - 避免在时间字段上用函数，比如
WHERE DATE(ts) = '2024-01-01'会让索引失效；改用ts >= '2024-01-01' AND ts
分区表不是银弹，但 RANGE COLUMNS 分区 + 时间索引能显著降低扫描量
当单表超千万甚至上亿行，即使有索引，全索引扫描仍可能慢——因为 B-tree 深度变大，磁盘随机 IO 增多。这时可考虑按时间分区，让 MySQL 直接裁剪掉无关分区。关键点：必须用 RANGE COLUMNS(ts)，不能用 RANGE(YEAR(ts)) 这类表达式分区，否则无法利用索引下推（ICP）和分区裁剪。
实操建议：
- 按月或按周分区（别按天，分区数太多会拖慢元数据操作），例如：
PARTITION BY RANGE COLUMNS(ts) (PARTITION p202401 VALUES LESS THAN ('2024-02-01'), ...) - 每个分区内仍需保留
ts单列索引，分区不替代索引，只是缩小搜索范围 - 注意
ALTER TABLE ... REORGANIZE PARTITION在大数据量下会锁表，生产环境慎用
ORDER BY time LIMIT N 查询要警惕 filesort，强制走索引排序
时序场景常见“查最近 N 条记录”，写成 SELECT * FROM metrics WHERE ts > ? ORDER BY ts DESC LIMIT 100。如果 ts 有索引，MySQL 通常能用索引完成排序；但如果 WHERE 条件太宽（比如查过去一小时的所有数据），优化器可能放弃索引排序，转而用临时表 + filesort，性能断崖下跌。
实操建议：
- 用
EXPLAIN确认Extra字段不含Using filesort；若出现，说明索引未被用于排序 - 确保
ORDER BY字段与索引顺序一致（升序/降序匹配），MySQL 8.0+ 支持降序索引，可显式建INDEX idx_ts_desc (ts DESC) - 避免在
SELECT *中包含大字段（如TEXT），它们会迫使 MySQL 回表取数据，放大 I/O 开销；必要时用覆盖索引，把常用字段也加入索引
时间精度影响索引选择：DATETIME vs BIGINT 存毫秒时间戳
用 DATETIME(6) 存微秒级时间，看着语义清晰，但实际写入和索引效率不如 BIGINT 存毫秒时间戳。原因：DATETIME 是变长类型（受时区、小数秒影响），B-tree 比较开销略高；而 BIGINT 固定 8 字节，比较快，且不受时区转换干扰。
实操建议：
- 若业务要求毫秒/微秒精度且查询频繁，优先用
BIGINT存 Unix 毫秒时间戳（如1717027200123），索引更紧凑、扫描更快 - 务必统一时间基准（服务端生成，禁止客户端传时间），避免因时钟漂移导致时间乱序
- 如果必须用 DATETIME，请确认
explicit_defaults_for_timestamp=OFF（旧默认行为），否则NULL值处理逻辑复杂，易引发隐式转换
时间范围查询的瓶颈往往不在“有没有索引”，而在“索引是否被真正用上”——分区裁剪是否生效、ORDER BY 是否触发 filesort、时间字段类型是否引入隐式转换，这些细节比索引本身更容易被忽略。
