mysql> show create table tidb_mdl_view\G *************************** 1. row *************************** View: tidb_mdl_view Create View: CREATE ALGORITHM=UNDEFINED DEFINER=``@`` SQL SECURITY DEFINER VIEW `tidb_mdl_view` (`job_id`, `db_name`, `table_name`, `query`, `session_i…

我试了一下，把满日志的阈值改小就能打印出来了，tidb_slow_log_threshold 单位是 ms，设为1，那么所有的 sql 都能打印出来。 上面 wd0517 提到的 tidb_current_ts 也很好用，只要显式的开启事务就行： ··· begin; show variables like “tidb_current_ts”; exec other_sql; ··· TIDB 里，同一个事务快照读，都是用的同一个开始时间戳。

从 ticdc 中获取的应该是准确的。 只读事务，只有开始时间戳，没有提交时间戳 好像是没有查询接口直接获取事务时间戳，只读事务的更不可能。但是有个骚操作看着有可行性，就是 tidb 的慢日志会打印出来 Txn_start_ts，这个应该就是你要的事务开始时间戳。 那就想办法把慢日志打印出来，比如开启慢日志后，把设置慢日志的阈值足够小，让其输出慢日志，或者就改下源码，让它不管什么情况都打印出来，能改 ticdc，稍微改下 tidb 的应该也不难。

// number of retries to make of operations. maxRetries = 7 // max number of retries when meets error maxErrorRetries = 3 func defaultS3Retryer() request.Retryer { return retryerWithLog{ DefaultRetryer: client.DefaultRetryer{ NumMaxRetries: ma…

port Using the “port” parameter, it becomes possible to use a different port to send health-checks. On some servers, it may be desirable to dedicate a port to a specific component able to perform complex tests which are more suitable to health-checks than the application. It is common to run a sim…

你发的这个备份原理，就是我上面写的这个意思。参考 2、3、4、5。 参考上面的 5，只需要备份一个副本的数据，如果每个 tikv 都物理备份，那就备份了多个副本数据 TiDB的体系，可能没有你说的这样的合适的工具，或者说现在还没开发出来，你说的那个工具是基于mysql体系的myrocks引擎，跟tikv使用rocksdb是不一样的。

Br 就是物理备份，逻辑备份是指通过 tidb server 以库表的形式导出数据，例如使用 dumpling 工具。 Br 是通过 tikv 扫描当前实例上 region leader 的 key-value 数据，直接生成 rocksdb 的 sst 文件。 Br 备份时，为了获取一致性备份，会有个 [startTs, endTs)， 基于 tidb 的 mvcc，也就是说会把扫描出来的，但是不在范围内的版本给过滤掉。 恢复时候的 rewirte key，那是因为 key 包含 tableId、indexId 信息，在恢复的表上，tableId、indexId 可能变化了，通过 rewr…

之前看 tidb gc 代码时候也有为啥需要两次调用 UnsafeDestroyRange 的疑问： 1. 第一次是按照 safepoint 执行 UnsafeDestroyRange 2. 第二次是在 safepoint 24 小时之后 这个 rfc 有解释为什么第一次不能完全清理完成： And why do we need to check it one more time after 24 hours? After deleting the range the first time, if coincidentally PD is trying to move a Regio…

mysql是把text字段单独存储的，这一点tidb没有采取这种方式，tidb应该不会有这种性能差异。

varchar和text类型之间当然是能用varchar就用varchar了，只有varchar实在满足不了text，才会考虑后者，这个跟mysql使用的选择一致吧。在tidb上，编码没有大的区别，存储也没有，都是编码在行记录的value里。

我要挑战

TiDB v5.1、5.2、5.3 这几个版本

按道理讲是可以的！

你这里使用的版本 v5.2.2，在这个版本之前有个 alter table modify column 的 bug，会导致数据乱码： https://github.com/pingcap/tidb/pull/31070 这个 pr 被 merge 进去的时间是 2022 年 4 月 12 号，你可以检查下你版本的时间： [bin]$ ./tidb-server -V 如果时间早于 4 月 12 号，那么恭喜你，很可能你遇到这个 bug 了。 这个 bug 的触发条件是并发执行 alter table modify column，你可以通过命令检查下 ddl 有没有被重复(并发)执行： …

这里执行计划，那个 TopN_13 算子如果改为带有 keep order true 的 limit 算子就好了： limit 走 updatetime 索引 keep order true，扫出来第一个（满足limit m, n） TopN_7 对各个分区子表（各个分区）返回的 limit 结果，进行一个 topN 计算返回数据 那这个问题就稍微麻烦，如果有这种 order by limit m, n 查询的强需求，还真没有好的查询方法。 或者试着加范围查询，例如 where updatetime > “xx” and updatetime < “xxx” order by upda…

上面表格列出来的应该是QPS吧，QPS反映的是吞吐量，你都是固定用32线程测的，吞吐量比较稳定是预期行为，你试着把线程数加大看看效果。 如果真是按照 32 线程来测试，根据上面的结果大致计算单个查询的平均时延信息： 读： 1000 ms / (89603 / 32) = 0.357ms 写： 1000 ms / (22392 / 32) = 1.429ms 读写：1000 ms / (42346 / 32) = 0.755ms 对于这样的时延，说明集群处理的非常之快了，目前压测线程数不够。 还有就是对于读压测，很耗 tidb 资源，如果 tidb 压力较大，加 tikv 确实不…

看着更像是 TiDB 对于分区表下 order by idx_col limit m, n 执行计划太差的问题。 当前的执行计划，是对每个分区计算出 topN 后，把各个分区的数据汇总计算 topN，得到的结果应当是正确的，但是没有用好索引的本身有序性。 因为当前排序的列是主键列 dt，理想的执行计划应该是按照这样的逻辑执行： 分区键是 dt，那么各个分区之间，基于 dt 有序，分区 p1 内的 dt 值都小于分区 p2 的 dt 值 分区内 dt 是索引（主键索引），那么按照 dt 的索引，分区内 dt 是有序的 基于以上的有序性，按照顺序扫描分区表，对于分区表内部，使用 dt 的…

total_process_keys: 100, total_keys: 4875306766 这里两个值差别很大，要么就是 gc 问题，要么就是版本还多。 你说执行 select name from tb where I_ID >= 1000 order by id asc limit 1 比较慢耗时是多少？ 这里 limit 是 1， 1000 代表上一个查出来的 I_ID.

如果改为执行 select name from tb where I_ID >= 1000 order by id asc limit 1 会慢吗？ 完整的 analyze 执行计划看看 processed keys 以及 Total Keys？ 这里说删除不一定是 delete from tb where I_ID < k 这种，删除“旧数据”，较大概率删除 I_ID 较小的数据记录都可能造成这种情况。