这种应该隐藏起来， 让别人看到了，还不让看。别人会说你小气的

这个sql很简单，检查下是不是索引没加完整啊， where条件的都加上索引。 如果都加了索引，按道理只会扫码存在记录的行

最佳解决办法是创建只读账户， 另外， 可以使用 MySQL Proxy 或 MariaDB MaxScale 等中间件，在代理层设置只读模式

其实我已经通过较少关联+强制校验条件 的方式改写，解决了这个问题。后续还是先升级，然后再系统解决这种问题，感谢

[image]

可以通过grafana 自带的告警功能

我要升级+我已经受不了4.0.16的版本了，苦于优化不彻底，资源消耗过重太久了

提示很明显，建议找到字符长度为336的值，看是不是业务代码导致值变化

正在计划中。。

你好，帮忙看下，我找的位置对不。 这里rpc_time用了这么久，对应的是 关联表_this吗？那为啥这个表的rpc_time这么突出？ [image]

已经不能算上个时代了，hibernate版本还是4，加上jsp里的级联引用，根本改不完，也不敢动

执行计划：TiFlash是后面建的，之前走的tikv，基本无影响。 Result_8.html (22.8 KB)

执行计划没有问题， 考虑优先排除 和Tidb的网络连接问题， 或者 在另外时间点执行来排除服务器负载问题

单表数据量都不大，都是几十w级别的。但是整体执行耗时19s左右。想知道： 集群服务器CPU飙升是否真的是由这种SQL造成， 如何鉴定

SQL_MODE支持全局和SESSION级别的， SESSION 级别的 SQL 模式的变化只会影响当前的客户端。 以下临时修改SQL_mode我在mysql上测试是ok的，tidb下应该也是一样的。 [使用JDBC] @Test public void sessionSqlMode() { String jdbcURL2 = "jdbc:mysql://localhost:3306/erp?sessionVariables=sql_mode='STRICT_TRANS_TABLES,NO_ENGINE_SUBSTITUTION'"; Co…

感谢社区给的活动机会~！！收获了证书，更是找到在DB方向深入的路！ [image]

show processlist 看一下，mysql执行ddl也有元数据错的问题

help命令是依赖内置mysql库的内容，参考： https://mysql.net.cn/doc/refman/8.0/en/server-side-help-support.html 考虑是否是用户权限不够的原因

首先，应该要定位慢的原因才来确定解决办法，你随意升级未必不是引出更多问题。 DDL和DML要考虑是否是大事务阻塞、或触发了表锁的原因，可以尝试下建表，或者在业务空闲时间来操作以对比。