你现在只用了一个merchan_id字段命中的索引，过滤出395797条数据，后面加上了inefficient、del_flag、material_type和name过滤之后只剩下1条数据。你搞个索引把merchan_id、inefficient、del_flag、material_type字段都带上。这样就不需要大量回表了

文档有问题，需要删除query-status后面的resume-task 后续会反馈修改

另外单机多实例部署 TiKV 或者多实例部署的时候需要使用numa或者cgroup来现在tikv占用cpu的资源总量，否则就会出现单个tikv cpu资源总量是单机全部cpu的情况。 例如32vc的服务器部署了4个tikv，3台服务器一共12个tikv实例不设置numa或cgroup时且cpu加总利用率32%是计算方式如下： 3200%/(32 * 4 * 3)=0.08<0.2，此时资源利用率虽然高，但是还是没有超过0.2，需要使用 cgroup: tikv: resource_control: memory_limit: 32G cpu_quota: 800% numa: …

假设你每个 TiKV 占用8vc的资源，一共4个 TiKV，目前总的 TiKV 4个实例累加起来 CPU 利用率是800%也就是用了12vc，此时整体 TiKV 利用率是。 800%/(8*4)=0.25 > 0.2 此时是可以评估出来的 TiDB 同理，在时间范围内tidb或者tikv任意资源利用率大于0.2才可以评估成功 阶段一可能累加起来没有超过20%

主要原因是因为升级过程中需要执行几个 DDL SQL，由于 DDL Owner 目录不存在导致 DDL 无法创建目录并且无法成功执行 DDL 导致升级不成功。 通过修复 DDL Owner节点问题，让DDL顺利执行可以完成升级

通过admin show ddl jobs;可以看到有DDL持续被cancelled 通过admin show ddl;定位ddl owner节点，并且发现tidb owner节点报错。 建议手动mkdir再重启 [image]

这个应该是文档提示问题，我反馈一下

1、就是说如果hint方式对单条SQL进行RU限制后，只要是负债没有达到当前版本的30倍，是不会报错的是吧？ 是的，没有超过30倍不会报错。 2、正常一个SQL的流程获取完region点信息后，对于同一个TiKV是不是只有一次RPC请求，使用batch的方式？那如果是绑定RU的SQL则会进行多次串行？ 一个复杂 AP SQL 可能会有多个算子请求多次 TiKV，单个算子是并发 Batch 请求多个 Region，第二个算子开始执行之前会统计第一个算子消耗的 RU 并在必要时出发流控。正常 OLTP SQL 一般是一次 TiKV 请求，此时多个 SQL 之间也会形成并发请求和 RU 控制

可以参考这篇文章中 Bad SQL 限流章节说明