远远达不到限制的数据长度，而且在同实例下的其他库的一样表结构的表就没问题，而且只是部分数据有问题，刚才又测试出新的问题，直接update也不会更新，而且直接delete也不会被删除掉
update返回 Rows matched: 1 Changed: 1 Warnings: 0
delete返回 Query OK, 1 row affected
3 个月前
我尝试将时区改成CST也是一样，然后新建表，在information_schema里面记录的还是少八小时
修改sql如下：
update mysql.tidb set VARIABLE_VALUE=‘CST’ where variable_name = ‘system_tz’ ;
修改以后重启tidb了
tiup cluster stop cluster_name -R tidb
tiup cluster start cluster_name -R tidb
[%E5%9B%BE%E7%89%87]
1 年前
从慢查询看是持续在记录insert操作，基本都是300ms+。尝试过将auto_increment改成auto_random了，发现热点问题没有得到改善，也手动split过一些regoin了，基本没什么效果
1 年前
日志已经不可查了，我们默认保留30天。
15.217这个机器虽然指标偏高，就是单纯部署的服务多，但是也没达到瓶颈，后来下线了集群也一样，写慢主要是集中在两个表，从dashboard看也是有热点，然后主键都是auto_increment属性，后来改成auto_random也是一样的，热点问题依然存在。
1 年前
![[%E5%9B%BE%E7%89%87]](https://asktug.com/uploads/default/original/4X/7/4/2/742b4546fc9f4a035286db2ac569aaba67692e07.png){kind=link}
没有更多内容了