不要你看下还有没有warning

if(‘’,A.profileid=‘’,1=1) 你这个判断条件有问题吧，这条件不如直接不要呢。。。。

讲实话，tidb的版本更新确实太快了，我去年上的项目，选型还是6，现在版本都已经到8了，其实数据库一般是不会升级的，版本太多只会增加维护的复杂度。。。我现在也就是把原来有些5的库升级成了6.5.10，有些还用的5.4.3，7，8暂时没打算上呢还。。。

sql能发一下吗？这个看着是sql写的有问题

上面的warn就是锁等待，看看相同时间tikv上有类似的锁吗

非聚簇索引表的话，肯定是有写热点的，建议你按照 https://docs.pingcap.com/zh/tidb/stable/high-concurrency-best-practices#更复杂的热点问题， 进行一下region预打散和拆分

表结构能发一下吗？

你备份的表例如是截至10点钟的数据，你库中的表在11点修改了数据，你想恢复，只能把表删了用备份还原到10点钟啊，你表不删，表里面很多没动的数据不是重复的吗？你的最终目的是什么呢？

drop完只是先gc吧，gc完了空间还没释放呢，释放得等compact

按你页面显示的sql模板id去表里查下SELECT * FROM INFORMATION_SCHEMA.STATEMENTS_SUMMARY_HISTORY b WHERE b.DIGEST=‘b823d47ec2c34e7981f6c1823e44177b0ae108fc14cc10dc92b0e0264d3e4d3b’

再碰到这种情况时，information_schema.data_lock_waits查一下，这种基本就是锁争用，或者去sql语句分析里面看下有没有其他锁这个表的语句

问题 SQL 定位 获取可能的问题 SQL，可以查看 INFORMATION_SCHEMA 中的 SLOW_QUERY 和 CLUSTER_SLOW_QUERY 。 也可以通过 tidb dashboard的 慢SQL和 SQL语句找到问题附近的 SQL并分析，定位到具体的问题 SQL，从 SQL 语句分析、慢查询的具体内容，可以详细查看内存使用量。 同时 grep expensive_query tidb.log 辅助定位问题时间点的 SQL 情况。

分区表全局索引

mysql命令进去的时候加上 --comment试试

能like出8成的数据，还走什么索引啊，直接全表还比较快。

调整亮度，调到最亮，还有读取的阈值可以调低一点

不错，就是有点慢

lsof |grep "/backup/data/tikv-20160/data"看下有哪些进程？

不是冬至吃饺子？