【 TiDB 使用环境】生产环境
【 TiDB 版本】
【复现路径】表做了TiFlash，对于业务来说很多SQL用到了此表，TP场景、AP场景
【遇到的问题：问题现象及影响】对于TP场景来说，高并发时，表关联过程中走到了Tiflash，大量SQL会阻塞，造成生产环境系统卡顿严重；
1 个赞
因为有其他业务系统调用，查询走到Tiflash性能并不会低；目前做法是对于TP高并发做了对于用到的SQL binding 处理，缓解了部分压力
不知道大家对此有其他啥看法没，或则最佳实践
或者增加Tiflash节点能解决此类问题么
- SQL Binding处理：对于TP高并发场景，可以对使用到TiFlash的SQL进行binding处理，以缓解部分压力。
- 增加TiFlash节点：考虑增加TiFlash节点来分散负载，这可能有助于解决因高并发导致的阻塞问题
增加tiflash节点缓解效果有限。tiflash并发高了cpu会激增。
我们现在的做法就是优化语句，并发较高的能走tikv就不走tiflash。
很多SQL都是根据页面选择的条件动态生成的，尝试过一些bingding，但是不可预估
现在也是从这个方向考虑的，在找开发对的过程中
看这个，tp业务和ap业务需要适当隔离。
tp业务用单独的tidb或者设置查询的时候直接隔离掉tiflash引擎。
ap业务尽量使用mpp。直接下推到tiflash执行，tidb直接拿结果。
这样做的结果就是ap业务大部分计算都在tiflash上执行，而tp业务也会因为没有聚合计算带来的大范围扫描而更加稳定。
2 个赞
我们这边业务查询较复杂，用户自定义查询多，我们是主从模式，好多不好优化的查询都切到从库上去查
1 个赞
其实可以分tidb-server，面向大并发的适用tikv的指定tidb-server，引擎锁定为tikv，olap类需求，单独走tiflash引擎的tidb-server。
1 个赞