为提高效率，请提供以下信息，问题描述清晰能够更快得到解决：
【 TiDB 使用环境】
【概述】 场景 + 问题概述
【背景】 做过哪些操作
【现象】 业务和数据库现象
【问题】 当前遇到的问题
【业务影响】
【TiDB 版本】
【应用软件及版本】
【附件】 相关日志及配置信息
监控（https://metricstool.pingcap.com/)
若提问为性能优化、故障排查类问题，请下载脚本运行。终端输出的打印结果，请务必全选并复制粘贴上传。
基于代价来评估。
优化器首先会对SQL执行Point_Get判断，如果是主键或者唯一索引上的查询，那没什么好评估的，就是最优的了
然后进行逻辑优化，对SQL进行等价改写，消除一些冗余逻辑，外连接改内连接等等
最后根据表的统计信息，选择代价最低的执行计划。这里的代价是基于SQL执行时可能消耗的CPU、I/O等资源并结合表的统计信息、索引情况等综合计算出来的。举个例子，一个SQL涉及a、b、c三张表之间的INNER JOIN，三张表相互关联的顺序有3*2=6种可能，表与表之间进行JOIN的方式有4种可能(HashJoin/MergeJoin/IndexJoin/IndexHashJoin)，那三张表JOIN的方式一共就是6*4*2=48种可能(每种关联顺序有2个JOIN点，每个JOIN点有4种方法可选)，优化器需要基于每张表的大小、关联字段及其它字段的索引、索引的筛选能力、执行时的资源消耗，从这至少48种执行计划中，选择执行代价最小的一个。从这个过程也可以看出，统计信息的准确性对优化器评估最优执行计划起着至关重要的作用
对于像对象或者系统统计信息、编译环境、绑定变量等输入信息尚可以人工干预进行改善，对于由于优化器本身缺陷导致选择次优的执行计划TiDB有什么辅助改进的手段？
该主题在最后一个回复创建后60天后自动关闭。不再允许新的回复。
