mysql> show variables like '%cost_model%'; +-------------------------+-------+ | Variable_name | Value | +-------------------------+-------+ | tidb_cost_model_version | 2 | +-------------------------+-------+ 1 row in set (0.00 sec) 在tidb_cost_model_version = 2的情况下可以查看执行计划cost成本代价计算方式…

我们是对于所有数据库都是BR全备。 增量日志备份的选择是： 1、在6.5以下版本采用tidb-binlog做binlog日志备份； 2、在6.5版本优先使用tidb-binlog做日志备份，但会牺牲分区表的exchange功能（drainer不支持该ddl的同步）。如果一定要用分区表的exchange功能则推荐用pitr做增量日志备份，但不能使用快速创建索引（fastreorg）功能、且pitr在目前版本不兼容lightning的local模式导数； 3、在7.5版本优先采用pitr方式做增量日志备份，该版本可以快速创建索引但注意还是和lightning local模式不兼容。 官方…

以前感觉tiproxy有点鸡肋，没什么用， 听大佬解答后茅塞顿开

如果涉及key的更新（聚簇索引表的主键或非聚簇索引表的rowid）则是获取整行记录先delete（insert标记）再insert。如果不涉及key的更新则直接insert。 其实我们更常用的涉及大批量数据操作的是delete，但是delete也是需要把整行数据都读取到tidb-server中，主要是因为需要同步tidb-binlog和对索引字段的维护，其实这块我感觉是可以优化的只是代价较大。

看这个issue对应的PR只合并到了主干版本，7.1应该是不能通过打补丁升级解决的。需要升级大版本。 如果短期不能升级大版本，先尝试其它方式绕过下吧。

是BUG，参考：https://github.com/pingcap/tidb/issues/46248

根据 @h5n1 大佬提供的思路，如下两个脚本可能对你有所帮助： 1、对于compact，可以参考这个脚本，可能更方便一些：https://gitee.com/wencycool/something_for_tidb/blob/main/ops/tidb-compact.py 在tiup管控机上用安装用户tidb执行： [image] 2、对于统计当前表大小：ops/get_table_size.py · wencycool/something_for_tidb - Gitee.com 在tiup管控机上用安装用户tidb执行： [image]

6.5对于kill已经做了很多埋点，常见的一些都能够杀掉，但是还有一些落盘行为没有很好的处理。 参考： 非并行hashAgg数据落盘读取阶段kill当前语句不生效 因此建议使用最新补丁比如6.5.5或者7.5版本做测试看看是否该机制已经进一步完善了。

简单写了个参数对比脚本：something_for_tidb: nothing..................... - Gitee.com 不知是否有所帮助 使用说明： PS E:\PythonProjects\something_for_tidb\tidb_config_diff> python main.py -h usage: main.py [-h] [-d DB] {collect,report} ... 参数对比工具 options: -h, --help show this help message and exit …

放在一起打印那个cte上下关联都关联不上排查问题头痛的狠，单独拎出来第二个语句打印的这个执行计划让人摸不到头脑。大概率是bug，而且产品还要对这个cte显示做优化，不然排查问题相当头痛。@表妹。

第一个执行计划，对于tor表，你tor.customer_id、tor.account_id、tor.symbol三个字段过滤后优化器评估出记录数为218250.82条记录，但是实际执行竟然是0条！这也是导致了对于第二个执行计划中优化器错误的认为结果集比较多选择了利用tod表走聚簇索引主键id来避免排序，关联tor表能较快的返回结果，但实际上符合tor条件的表是不会达到100条记录的，因为符合条件的结果是0，所以最终请求了所有tod表数据，并索引关联tor表导致执行时间太久。 这里优化器根据统计信息评估的结果和实际严重不符，要么就是统计信息太旧，要么就是Count-Min Sketch ha…

tidb-server <--------------------------> tikv-server 宝贵的网络资源： 1、对于update、delete操作，tidb还是需要把整行记录拿到tidb-server中，我想这主要因为1、需要维护tidb-binlog，需要将整行记录传给下游；2、有较多涉及到的索引字段须读到tidb-server中加工处理后回填维护索引。但是这大量的数据搬动可能消耗大量的网络资源（网络带宽、GRPC通道拥挤）。因此是否能下的功夫优化这个无法绕过的问题。后面不推荐tidb-binlog（ticdc代替下游供数、brlog代替增量恢复），那么更应该着手优化这块…

对于TiCDC： 1、希望上下游都是tidb集群时，ticdc摆脱对GC的依赖（大集群长时间holdGC）。可以利用BR backup全量恢复，ticdc读取BRlog来追增量，最终再拉去tikv log。 2、希望摆脱对上游集群的依赖，目前上游集群挂掉，ticdc无法工作，希望在上游集群挂掉后还是能完成已经传到ticdc中日志的同步到下游。 3、ticdc redo，当上游出现灾难性故障时，下游的最终一致性可能遭到破坏，为了保证下游同步到一致性点引入了redo的概念，但是6.5后ticdc推荐部署在上游，ticdc redo推荐写在下游（避免上游整体机房出问题），如果下游需跨中心访问，…

可观测行，在数据库内核层面提供的数据还是太少了，且感觉较为混乱。 表的统计信息有的存在于mysql视图下，有的在information视图下，看似较多地方查询实则缺少较为实用直观的视图：比如 1）、我想查某张表最近一次统计信息更新时间，如果这张表很久没有更新，那么就很难查询到，如果在syscat.tables中存在一列说明统计信息最后一次更新时间，那么还是很有帮助的。 2）、太多的show stats但缺少直方图的视图查询（默认mysql库下的太不直观），比如快速的查询一个字段的分布频率（用于评估等值条件）和分位数（用于评估范围条件）情况，在视图中可以进行关联等操作。 对于Ti…

如果说的是这个问题，那么join reorder可以在产品上进一步优化，但是这是一个大工程。但是我们可以先退而求其次让用户自己指定想要的连表顺序，但是也是不太容易，参考帖子：Hint中表连接顺序LEADING应支持多表关联优先级和兼容物理优化阶段Join算法的选择

因为c和d表关联，存在多对多情况，导致结果集放大了很多结果为4194048，然后在和p3关联，导致大量的p3主键索引读。因为三张表关联最终结果记录不多，但是c,d先关联产生的中间结果很多，说明关联顺序存在问题，楼上那位虾总也是看到这里所以在表连接顺序上帮你调整优化。 但是我猜想他还想通过将数据类型转换成一致的将非等值连接条件下压到存储层过滤，但是这个对于左边通过batch获取记录的情况是无法将非等值条件下压到右侧的，这个行为和mysql的bka(batched key accessed)以及ob的use_batch行为一样。只不过后两者也支持非batch方式，支持非batch主要是他们都是存…

看tidb和mysql的执行计划一样，tidb主要慢在indexJoin去p3表获取记录，但是这里和mysql行为一样，tidb却很慢，这块应该主要是c.persionid太不连续导致，在lsmtree和btree的等值查询硬碰硬情况下lsmtree差的还是挺多的，尽管tidb已经在内部做了很多优化（比如尽量将key作为有序请求，get请求数据转为next）但是c.persionid过于离散会导致大量的逻辑block读。另外也没想到mysql对400多万数据主键关联索引查找仅需5秒就能搞定，我估计索引都在内存中吧。 tidb索引IndexJoin的一些行为在这个贴子里有较为详细的探讨，希望有所…

简单来说这是从他脑子里获取的。这位大佬是tidb优化器核心设计和实现者。