tiflash 是 tidb 的列式存储引擎，作为 tikv 补充支持 htap 实时分析；其副本为异步只读、不参与 raft，适用于大宽表聚合、时间范围扫描及高基数等值查询，但不适用于单行点查或强一致性事务；需合理配置副本数、用 hint 或会话变量强制路由，并通过 explain 确认执行计划命中 tiflash。
TiFlash 是 TiDB 的列式存储引擎，通过异步复制 Region 副本实现 HTAP 场景下的实时分析加速。它不替代 TiKV，而是作为其补充：TiKV 负责高并发、低延迟的事务处理（行存），TiFlash 专注复杂 OLAP 查询（列存）。要真正发挥列存优势，关键不在“开了没”，而在“怎么配”和“怎么用”。
明确 TiFlash 副本的作用与适用边界
TiFlash 副本本质是 TiKV Region 的异步只读副本，按表或按分区粒度添加，不参与 Raft 投票，也不承担写入压力。它适合以下场景：
- 大宽表的聚合查询（如 SUM/COUNT/GROUP BY 多字段）
- 时间范围扫描（如 WHERE event_time BETWEEN '2024-01-01' AND '2024-06-01'）
- 高基数列的等值或 IN 查询（如 SELECT * FROM user_log WHERE city IN ('Beijing', 'Shanghai')）
- 需要避免全表扫 TiKV（尤其是大表 + 小结果集）的报表类 SQL
不适合场景包括：单行点查（PK 查询）、强一致性要求的读写混合事务、频繁更新小批量数据的表——这些仍应走 TiKV。
合理配置 TiFlash 副本数与调度策略
副本数不是越多越好。默认 1 副本已可满足多数分析负载；设为 2 或 3 主要用于高可用或跨机房容灾，但会增加同步延迟与存储开销。
- 添加副本用 ALTER TABLE t SET TIFLASH REPLICA 1，非 DDL 操作，不锁表
- 查看副本状态执行 SELECT * FROM information_schema.tiflash_replica，重点关注 AVAILABLE、PROGRESS 列
- 避免对高频写入且无分析需求的表（如订单明细流水表）盲目加副本，防止同步积压拖慢整体集群
- 若集群含多 AZ，可通过 PD 调度规则将 TiFlash 实例绑定到特定 label，确保副本物理隔离
让查询真正命中 TiFlash 的关键技巧
TiDB 优化器默认优先选择 TiKV，除非显式指定或满足自动下推条件。要确保分析 SQL 走 TiFlash，有三种可靠方式：
- Hint 强制路由：在 SQL 中加入 /*+ READ_FROM_STORAGE(TIFLASH[t1, t2]) */
- 表级别设置：执行 SET SESSION tidb_isolation_read_engines = "tiflash"，当前会话所有查询自动倾向 TiFlash（需确保表有副本）
- 优化器自动识别：当查询满足「大表扫描 + 聚合/JOIN + 无强一致性 hint」时，优化器可能主动选择 TiFlash，但不可依赖——务必用 EXPLAIN 确认执行计划中是否出现 tiflash 字样
注意：JOIN 多表时，只要任一表无 TiFlash 副本，整个 JOIN 可能退回到 TiKV 执行；建议分析链路中涉及的主维表均配置副本。
监控与调优：不只是“能跑”，还要“跑得稳”
TiFlash 不是“一配了之”。需持续关注三类指标：
- 同步延迟：通过 Grafana 中 tiflash_replica_sync_duration_seconds 观察，持续 >30s 需排查网络或 TiKV 压力
- 查询耗时分布：对比同 SQL 在 TiKV vs TiFlash 下的 EXPLAIN ANALYZE 结果，关注 Scan、Selection、Aggregation 各阶段耗时差异
- 内存与压缩率：TiFlash 使用 LZ4 压缩，实际内存占用约为原始数据的 30%~60%；若查询频繁 OOM，可调整 tidb_mem_quota_query 或优化谓词下推
常见问题如“加了副本但查询没变快”，大概率是谓词未下推（例如函数包裹列：WHERE DATE(create_time) = '2024-01-01'），导致全列扫描后过滤——改写为 WHERE create_time >= '2024-01-01' AND create_time
