应将分析类大范围扫描（如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 的实际耗时分布，而不是只看执行计划形状。
