服务器配置是多少，先看看监控硬件资源有没有到瓶颈

通常DDL都会超过300ms，所以慢日志基本都能找到对应的信息，并不是只有审计日志才有

还有一个办法，如果这个表比较大，可能drop会超过300ms，这个时候去看看慢日志，这里既会记录操作用户，又会记录客户端IP

tidb.log里面会记录操作用户，搜下关键字CRUCIAL OPERATION，但是ip是不会记录的

别用了，这肯定不行，这么大字段varchar建都建不出来吧，更别说直接建索引了，不如用text，不过tidb也是不支持全文索引的，考虑考虑es呢。

【你最想实现的 TiDB 功能需求】 cdc性能提升 【你最喜欢的 TiDB 新特性 + 理由】 很多 【你最想要周边心愿池里的哪个周边】 * 2024 TiDB 社区新款双肩背包 【你考过哪些 TiDB 证书？】 PCTA\PCTP\PCSD 【你身边有多少位朋友在用 TiDB？】 10多个吧

除了常规监控，日志这些之外，遇到一些奇怪的问题或者故障，需要从底层一点一点排查，不过往往发现越离谱的问题答案越是简单

参考这里，如果没有外网就用离线镜像吧 https://docs.pingcap.com/zh/tidb/stable/tiup-mirror-reference#客户端工作流程

此话题已在最后回复的 7 天后被自动关闭。不再允许新回复。

TIFLASH_TABLES里存的是统计信息，可能统计信息不准吧

用hint走tiflash count下看看有没有差异 SELECT /*+ read_from_storage(tiflash[porsche.authorinfo]) */ count(*) FROM `porsche`.`authorinfo`; SELECT /*+ read_from_storage(tikv[porsche.authorinfo]) */ count(*) FROM `porsche`.`authorinfo`;

页面可以kill SQL，SQL自动优化建议，页面可按告警分类配置电话预警

此话题已在最后回复的 60 天后被自动关闭。不再允许新回复。

其实我的问题不是这个，这个我理解，去优化SQL就好了，我是想说文档的说法太绝对了，建议修改下

看看我上面发的图，某些情况explain子查询可能会被提前执行， 我遇到的情况是select * from t1 where a = (select max(a) from t2) ， select max(a) from t2 在explain 阶段被执行了，所以我认为文档不严谨，explain是有可能真正执行SQL的

是的，根据这里的文档explain是有可能真正执行sql子查询的 [image]

是的，和mysql5.7一样，只是语法支持，实际还是升序的

应该直接从慢日志文件可以查把

目前不支持降序索引