SQL TiDB 的 HTAP 混合负载下 TiKV vs TiFlash 的读写分离策略

应将分析类大范围扫描（如group by、avg、count加时间过滤）发给tiflash，而点查、主键查询、强索引范围查询必须走tikv；tiflash有1–3秒同步延迟，未建副本或hint错误则无效，且oltp写入可能因tiflash同步拖慢。

什么时候该把读请求发给 TiFlash，而不是 TiKV

HTAP 场景下，TiFlash 不是“所有读都自动走它”，而是得看查询模式。分析类大范围扫描（比如 GROUP BY、AVG()、COUNT(*) 加时间范围过滤）适合走 TiFlash；点查、主键等值查询、带强索引的范围查询（如 WHERE id = ? 或 WHERE create_time > '2024-01-01' ORDER BY id LIMIT 10）必须走 TiKV，否则延迟飙升甚至超时。

常见错误现象：在报表页面用 select COUNT(*) FROM orders WHERE status = 'paid' 却没开列存副本，tidb 默认走 TiKV 做全表扫，QPS 一上去就卡住；或者反过来，给用户详情页的 SELECT * FROM users WHERE id = 123 强制指定 /*+ READ_FROM_STORAGE(TIFLASH[users]) */，结果响应从 5ms 拉到 300ms。

• 判断依据不是“是不是分析”，而是「是否能利用列存压缩 + 向量化执行加速」——简单说：涉及大量行但只读几列，且计算逻辑偏向聚合/过滤，才值得走 TiFlash
• TiFlash 副本默认不承载写入，但写操作会同步日志到它（异步 Raft Learner），所以刚写入的数据在 TiFlash 上有秒级延迟（通常 1–3s），实时性要求高的读不能依赖它
• 如果表没建 TiFlash 副本（ALTER table t SET TIFLASH REPLICA 1 没执行或失败），任何 hint 都无效，查 information_schema.tiflash_replica 确认状态

READ_FROM_STORAGE hint 写不对，TiDB 直接忽略

这个 hint 是手动读写分离最常用的控制手段，但它对语法非常敏感，错一个字符就不生效，而且不会报错，静默回退到默认策略。

常见错误现象：写了 /*+ read_from_storage(tiflash[t1]) */ 没生效，explain 显示还是 TableReader（TiKV）；或者用了双引号、下划线、大小写混用，比如 /*+ READ_FROM_STORAGE(TIFLASH["t1"]) */。

• 表名必须跟 sql 中实际引用的别名或原名完全一致（大小写敏感），例如 SELECT * FROM orders o /*+ READ_FROM_STORAGE(TIFLASH[o]) */ WHERE ...，这里必须写 [o]，不是 [orders]
• 只能写 TIFLASH 或 TIKV，不能写 TiFlash、tiflash、FLASH —— 全大写且无空格
• 多个表要分别指定：/*+ READ_FROM_STORAGE(TIFLASH[t1], TIKV[t2]) */，漏掉任意一个，那个表就按默认走
• hint 必须紧贴 SELECT 关键字后，中间不能换行或加空行，否则被 parser 截断

OLTP 写入变慢，可能是因为 TiFlash 同步拖累了 Raft 日志流

写请求只进 TiKV，但 TiDB 会把写日志同时推给 TiFlash（作为 Raft Learner）。如果 TiFlash 节点负载高、磁盘慢、网络抖动，会导致 Raft log 复制卡住，进而让 TiKV 的 apply 线程阻塞，表现就是 INSERT/UPDATE 延迟上升、tidb_slow_log 里出现 wait_tso 或 wait_apply 耗时突增。

使用场景：高峰期批量导入订单，发现写入 p99 从 20ms 涨到 800ms，但 CPU、磁盘 IO 看起来正常。

• 查 metrics_schema.tidb_query_duration 和 metrics_schema.tikv_raftstore_apply_wait_duration_seconds，如果后者持续 >100ms，大概率是 TiFlash 同步滞后
• 临时缓解：停掉部分 TiFlash 副本（ALTER TABLE t SET TIFLASH REPLICA 0），但注意这会让相关分析查询失败
• 长期方案：给 TiFlash 独占机器（NVMe SSD + 高内存），避免和 TiKV 混部；调大 tiflash-config.yml 中的 raft-store.apply-pool-size 和 storage.main.dir 所在磁盘 IOPS

为什么 EXPLAIN 显示走了 TiFlash，但实际性能更差

执行计划显示 ExchangeSender → ExchangeReceiver → MPP_TASK，说明确实进了 TiFlash，但耗时反而比 TiKV 高，核心原因是 MPP 并行度失控或数据分布不均。

常见错误现象：一个 JOIN 查询在 TiFlash 上跑了 12s，explain 显示 32 个 MPP task，但监控里发现只有 2 个 worker 在干活，其余空转。

• TiFlash 的 MPP 并行度由 tiflash-server 的 max_threads 和数据分片数共同决定，小表广播 JOIN 时若没加 /*+ BROADCAST(t2) */，TiDB 可能错误选择 Shuffle JOIN，导致跨节点传输爆炸
• 列存压缩率低的表（比如大量 TEXT / json 字段未裁剪），TiFlash 解压开销远超预期，此时不如让 TiKV 用索引快速定位再回表
• 确认是否真需要列存加速：用 SELECT COUNT(*) FROM t WHERE a > 100 AND b LIKE '%x%' 这种带模糊匹配的，TiFlash 无法跳过无效数据，性能可能反不如 TiKV 的前缀索引

复杂点在于，同一张表在不同查询条件、不同并发压力下，最优路径可能动态切换。没有一劳永逸的 hint，得结合 EXPLAIN ANALYZE 的实际耗时分布，而不是只看执行计划形状。