flower read技术鸡肋吗？
【TiDB 使用环境】生产环境 /测试环境
【TiDB 版本】
【部署方式】云上部署（什么云）/机器部署
【操作系统/CPU 架构/芯片详情】
【机器部署详情】CPU大小/内存大小/磁盘大小
【集群数据量】
【集群节点数】
【问题复现路径】做过哪些操作出现的问题
【遇到的问题：问题现象及影响】
【资源配置】进入到 TiDB Dashboard -集群信息 (Cluster Info) -主机(Hosts) 截图此页面
【复制黏贴 ERROR 报错的日志】
【其他附件：截图/日志/监控】
有人说这个很鸡肋，没有试过，有试过的说一下呢
当 Leader 节点发生故障或正在进行 Leader 切换时，Follower Read 可以让系统继续提供读服务，保证业务的连续性
建议先确认一下你指的是Follower Read。这技术在生产环境里挺实用的，不是鸡肋。
核心用法：设置tidb_replica_read = 'follower'或更细粒度的'closest-replicable'，让读请求分散到follower节点。适合读多写少、对一致性要求不高的场景，比如报表查询、历史数据读取。
测试过，没发现有啥用 查询压测没有明显变化
我觉得还行，不鸡肋
读多写少、报表 / 历史查询、跨机房多 AZ、存在读热点场景，能分摊负载。
无热点集群不建议全局开启
假设你的 TiKV 集群有 3 个节点，默认情况下，无论这 3 个节点的 CPU 多空闲，读请求都只会打到 Leader 所在的 1 个节点上，导致单节点 CPU 被打满，而另外 2 个节点在“看戏”。
开启 Follower Read 后，读压力会均匀分散到 3 个节点上，理论上可以将集群的读吞吐量提升 2~3 倍 。
业务上的确没有用到过这个,但是不说明没有用啊
相对来说还是有点鸡肋
Follower Read 适用于以下场景：
有些场景是需要这样的，比如朋友圈类的，一致性要求不高的。资源使用率可以更好，对热点读的场景有优化。
建议根据自己业务的读写比例和对数据一致性的要求，来评估是否开启以及如何配置 Follower Read
不是鸡肋：适合可接受轻微延迟的读打散，能吃掉 Follower CPU。强一致实时读仍走 Leader。按业务一致性要求选用，别一刀切。
不太适合说是“鸡肋”，更准确地说Follower Read 是一个场景比较明确的能力，不是开了就一定变快。TiDB 默认读 Region Leader，Follower Read 的价值主要是把一部分读流量分摊到 Follower，比较适合读请求很多、存在读热点、读写负载需要摊开，或者多 AZ 部署希望尽量读取本地副本、减少跨 AZ 流量的场景。但它为了保证强一致性，Follower 在真正读取之前还要通过 Raft ReadIndex 和 Leader 确认一次提交进度，相当于多了一次网络交互，所以如果业务主要是主键点查、单次查询本来就很快，开启以后收益可能不明显，甚至会增加一点延迟和 TiKV CPU 开销；官方也更推荐在大查询、批量读取或者明显读热点场景下使用。所以我觉得判断它有没有价值不能只看“有三个副本是不是应该都拿来读”，关键还是看当前瓶颈是不是在 Leader 的读压力或者跨 AZ 流量，如果本身 Leader 没压力、查询又都是小查询，那确实会感觉比较鸡肋；反过来在重读、多 AZ、热点明显的集群里，它还是很实用的。新版还有 closest-adaptive 这种策略，小查询继续走 Leader，预估返回数据比较大时再优先本地副本，本身也是在解决“一刀切开启 Follower Read 不一定划算”的问题。
启用过，感觉不出来明显差异