自行解决了业务场景就不可能一致。分页展示是多次前后端的接口调用。每次接口调用的时间点就不是一个时间点。后端服务不可能查到一样的结果（除非这段期间内数据没修改过）。
即使加了order by time desc/asc 。同一个时间点可能存在多条数据，例如：一页展示10条数据，同一个时间点正好有12条数据。那么如果只是依照时间进行排序一定会乱序，参考官方文档 分页查询 | TiDB 文档中心 (pingcap.com)
6 个月前
可以先从监控或者是pd-ctl的scheduler show 查看下是否还在调度region。先排除后台任务没完成这个情况。
6 个月前
都要做。tidb服务拆分，有助于普通业务的稳定，避免query执行的时候内存不足。tikv侧也可以进行相关优化也可以上个tiflash，看看能不能优化跑批或者是部分其他业务请求
7 个月前
后三行内有expected element type <Error> but have <html> 这个错误信息，在minio的 github 的issue 查来下好像有类似报错但是没有前置。issue里面有提及nginx这类负载，可以参考下
Error when copying files - expected element type but have · Issue #18536 · minio/minio · GitHub
7 个月前
有没有可能和sql_mode 有关呢
7 个月前
you right。 是我想错了，光盯着报错内容了。
7 个月前
_tidb_rowid是一个问题，但是正常索引标记是带上table_id 的。有主键冲突，说明实际写入的最底层的table_id还是beta的
7 个月前
从正常的索引存储结构应该是table_id__tidb_rowid 。rename 不改变table_id
7 个月前
![[image]](https://asktug.com/uploads/default/original/4X/3/5/0/3505e170a9e69f5b20e4ccbda79abab27af1b264.png){kind=link}
我的理解是这样的，snapshot是数据快照的时间点。数据在最后一次commit后数据才能被读取到。那么这次commit 时间点应该比你binlog的时间点稍微晚一丢丢，也就是24s后。在23s 的快照时间点上，数据其实还未真正的commit，表实际上是没有数据的。
7 个月前
走tiflash 就不要select* ，是坏习惯。tiflash 本来就是列存了，要啥拿啥，这样扫描的数据就少了。其次你这个表reportTime 应该是字符串，substr 必定从第一个位置开始截取，完全可以考虑用前缀的like匹配。没必要使用substr函数
9 个月前
![[image]](https://asktug.com/uploads/default/original/4X/f/6/a/f6a175526abb0797f3bef64f32f424f492dd7b94.png){kind=link}
没有更多内容了