为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【问题】
如附件中图1所示，我在分区表上执行一个join查询的时候，分区表作为被驱动表有3个分区被查询，只有一个分区走了主键索引，另外两个分区走了全表扫描，这3个分区的查询条件是完全一样的，为什么会出现这种情况？
如附件中图2所示，我添加了/*+ INL_JOIN(r, ws) */ 的SQL Hint，执行计划反而没有按照Hint的指示执行，而是把Hint中的第一个表作为了被驱动表。
【TiDB 版本】 5.7.25-TiDB-v6.1.1
【附件】
图1：
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
set session tidb_partition_prune_mode = ‘dynamic’; 打开动态裁剪后再试试
hint生效了的，hash join变成了index nl join，只不过驱动表顺序反了，可以再加个hint让ws表走主键索引试试，看能否纠正驱动顺序
你的另一个帖子上是动态裁剪后全表扫描或其他情况下大量的cop请求发送到tiflash造成的积压，先这个环境是那个版本升级吗？ 看你现在的执行计划里走的都是tikv可以试试开启动态裁剪后，加/read_from_storage(tikv[xx])/方式强制走tikv，避免走tiflash。 不开动态裁剪的话，表关联时不能识别到关联条件值而做分区裁剪。
加了use index的hint之后还是那样，不仅驱动表的顺序没变，连ws表的查询有两个分区也还是走的全表扫描
是从6.1升到了6.1.1。
现在没法通过加 read_from_storage的hint强制走tikv，一旦开启分区裁剪，那么多的查询改不过来。
在测试环境开启分区动态裁剪的情况下查询的确是正常了：
但是线上那个在tiflash下分区裁剪的问题没有fix不敢开动态分区裁剪啊。
你可以先在会话级设置观察下开启后执行计划是否正常，全局开启确实影响比较大，原有SQL加hint可以用SPM方式绑定，但是开动态裁剪等这类的优化器相关参数tidb还不支持hint，听说官方后续会做一个变量hint ，目前只能等官方修复这个tiflash问题了。
去掉INL_JOIN，只加hint让ws走主键试试
在你之前的帖子上 官方回复了优化进度，后续全部使用mpp模式
set session tidb_partition_prune_mode=dynamic
老哥，能贴下完整SQL语句（包括变量）和完整执行计划么。
好的，等发版了
