优化器根据统计信息计算每个算子的代价，你是想了解优化器吗？
揭秘 TiDB 新优化器：Cascades Planner 原理解析 | PingCAP
21 天前
首先要考虑到降本增效，也可能带来风险。
资源管控，一套数据库集群，多套应用对接，减少物理资源使用，减少DBA运维成本（可能存在一套应用异常占用资源影响其他应用的风险）。
使用私有云，超融合等虚拟化技术，小型数据库服务器可能存在大量CPU资源，内存资源浪费，虚拟化可以解决这部分问题CPU可多分，内存可先少分，看情况增加（可能增加资源CPU不足风险）。
延长服务器使用年限或者使用旧服务器（可能增加宕机，应急风险）
下云，或者上云，看情况都有可能减少成本。
搬机房，把服务器放到机房资源便宜的地方。
搞人，包括换人、裁员、用外包等使用人力成本低的地方的人力资源。
换开源，商用的换成社区版，能不花钱…
2 个月前
你说的没错，是需要右边关联表的字段唯一才能保证可以不扫，习惯于看到id就认为是主键这个是有问题的，还是得核实一下
2 个月前
他的语句是SELECT count 表关联是left join 而且where条件只有左边的表，所以左边满足条件+右边满足条件算一条；左边满足条件右边不满足也算一条，就是说不管右边满不满足条件，只要左边满足就算，所以理论上是不需要查询右边的表的。
3 个月前
第二个执行计划更优，实际上left join 对count的话，第一个表就足够了，第一个执行计划实际多了一步对第二个表的扫描，所以时间长了。问题就是使用order by 后（虽然没有意义）使得生产了更好的执行计划。
如果Optimizer Trace: 开发好了的话可能能看出来是什么原因导致优化器没有选到正确的执行计划
Optimizer Trace: 用于收集和监控优化器内部优化逻辑流程，提升用户现场的问题诊断能力和效率，并为后续的基于诊断监控的反馈优化提供数据输入；
我觉得解决方法就是用 执行计划绑定 (SQL Binding)
执行计划管理 (SPM) | PingCAP 文档中…
3 个月前
没有更多内容了