能在dashboard里看见这个慢SQL吗,执行时间那页和执行计划发下
每天7:30写入,且是在insert执行期间,健康度下降,insert执行200万数据,执行时间在一个半小时左右,定时任务去收集统计信息的话,什么时间收集比较合适?
一个空表insert大量数据 不用关心健康度下降,健康度就是个计算 (1 - modify_count
/row_count
) * 100。 要关心的是insert慢,健康度不影响Insert速度
可能会影响到insert,如果健康度下降,索引失效,查询可能无法走索引,导致全表扫描
这样说的话健康度下降会影响的是查询,对正在执行中的insert也会有影响嘛?
咋影响Insert, insert时考虑唯一约束,有主键 唯一建索引 没统计信息都能用,没唯一约束 还查啥
就是analyze table xxx
插入为啥会超时?你是怎么插入的?不会一次性插入200万数据吧?
大量数据变更:在短时间内对表进行大量的 INSERT、UPDATE 或 DELETE 操作,尤其是大批量的 INSERT 操作,会迅速改变表的数据分布,导致统计信息过时。TiDB的表健康度是一个反映统计信息准确性的指标。健康度的计算基于几个关键的统计信息元素:modify_count(自上次分析以来被修改的行数)和row_count(表的总行数)。具体的计算方式如下:
当 modify_count 大于或等于 row_count 时,健康度为 0。
当 modify_count 小于 row_count 时,健康度的计算公式为 (1 - modify_count / row_count) * 100。
这意味着如果一个表自上次分析后有大量数据变更,modify_count 会接近或超过 row_count,导致健康度下降。健康度是衡量统计信息是否过时的一个指标,健康度越低,表示统计信息越不准确。
有公式 。
数据变化频繁,若数据特征一致通常执行计划不会有问题,若担心统计信息收集不及时,用 hint 或 bind 固定执行计划
有没有看过dashboard的热力图,监控信息。排除下是不是写热点或者是硬件性能不够(或者gc回收了)。
如果定位不到问题点,可以尝试下hash分区表。 这类拉取快照数据可以考虑下hash 分区表,将数据打散,统计信息的维护工作也是基于分区来的,速度会更快点(不过需要考虑下分区字段)。或许会有改善
大批量写入执行完成之后。
锁了表的统计信息? 是怎么操作的? 因为看你这个数据 row_count为 0,说明根本没有统计信息的。有手动analyze table
一下,看执行有没有报错么?
表的健康度降低是正常的,这个跟你插入超时应该没有必然联系啊,先解决超时看看哪里问题,插入时什么方式的,开事物200万一提交吗
统计信息收集一般是在大数据量导入完成之后收集, 你 insert 的 并发是多少? 多少条一提交? 如果应用端没日志的话,可以 tidb 的日志里搜下相关sql 看看有没有执行失败的原因
如果每天插入之后都是相同的量,也可以考虑通过锁定统计信息来保证统计信息不会一直变化,可以看下这个链接:https://docs.pingcap.com/zh/tidb/v7.5/statistics#锁定统计信息