没什么效果，我还是搭建几个 enforce_mpp的 tidb吧
执行计划
加了hint才走
硬件配置
现在好多健康度100的表 也都不走索引 ，走tikv 全表扫描 。 
EXPLAIN SELECT user_id, stat_date, dept_id FROM board_design_department_employee WHERE stat_date = ‘2024-04-28’ AND priority = 1
没走 idx_date 索引 。
如果把后面 AND priority = 1 还会走主键 。 完全不合逻辑的执行计划 。
这个你是改的session还是global
tidb_analyze_version tidb_cost_model_version 这2个都改成2 重新收集统计信息
SHOW VARIABLES LIKE ‘tidb_analyze_version’ 当前值 2
SHOW VARIABLES LIKE ‘tidb_cost_model_version’ 当前值 1
tidb_cost_model_version=2 之后看着正常一些了。 谢谢 。
tidb_opt_seek_factor 改的session
tidb_analyze_version tidb_cost_model_version 只是解决了索引的选择，不再走全表。但是还没解决直走tikv，不走tiflash的问题
是on
先收集信息，再从其他方面去查看
遇到同样问题，除非显式指定tiflash，否则即使把 tidb_analyze_version 和 tidb_cost_model_version 参数都修改为2并且重新 analyze table 后，依然默认走tikv而不走tiflash
我这边把 tidb_allow_tiflash_cop 参数改为1后，可以解决这个问题，供参考
改完执行计划什么样？ 还有tiflash[mpp]吗
像你贴的这个 原来是所有算子都走tiflash吧
应该是的，刚测了下所有都走tiflash是最快的
你这个sql，并不是一个带group by的聚合计算，正常来说，tiflash算效果不会太好。所以优化器基本不会选择tiflash。
如果你一定要走tiflash，只能是设置变量，强制mpp。
设置tidb_enforce_mpp=ON
https://docs.pingcap.com/zh/tidb/stable/use-tiflash-mpp-mode#控制是否选择-mpp-模式
强制mmp并不好，刚确认了原因，是因为 tidb_cost_model_version 代价模型改为2后引起的，把 tidb_cost_model_version 改回 1后就可以恢复，即使不设置 tidb_allow_tiflash_cop 也可恢复。文档上说新的代价模型更优，但我这边实际使用应该还是原来的代价模型更优些，新代价模型还会导致一些原来能用索引的用不上索引
是的，因为升级了版本，改用了新的代价模型，而且我的sql没有group by，估计是新代价模型认为不应该用tiflash，而事实上使用tiflash执行只需要几百豪秒，用tikv执行需要10秒多。我们在一些 where xxx like '%xxx%'语句上使用tiflash进行加速是一个很好的选择，毕竟这样的语句没办法用上索引，但用tiflash的话只需要读取那一列数据就可以了，比用tikv要快很多
升级后，最好做统计信息更新。