嗯，7.5版本，发现了一个执行频繁耗费cpu的sql，sql里执行的索引不是最优的，有时根据店铺id，有时根据订单id去筛选数据，我们查询条件是shopId，tid，oid，表的健康度只有61
4 个月前
我们只有一个tdib节点，这个节点内存溢出自动重启之后，需要全量手刷一次就正常了，不然好多sql都很慢，这种我理解不应该是重启会把统计信息加载一次到内存么？
10 个月前
统计信息不准确：TiDB使用统计信息来优化查询计划，如果统计信息不准确，TiFlash可能会选择不合适的索引，导致指定索引失效。解决方法是定期收集和更新统计信息，可以使用"ANALYZE TABLE"语句来手动更新统计信息。
TiFlash元数据同步问题：** 如果TiFlash的元数据与TiDB的元数据不一致，也可能导致指定索引失效。确保TiFlash的元数据与TiDB保持同步，可以尝试重启TiFlash实例，或者使用"flush privileges"等命令来刷新权限和元数据信息。
1 年前
如果某些数据区域特别热点，可能会导致某个节点的磁盘使用率较高。您可以考虑优化查询以减少热点访问，或者通过调整 TiKV 的 region split 策略来分散热点数据。
1 年前
关于 TiFlash 副本数的设置，建议考虑以下因素：
性能需求： TiFlash 副本数的增加可以提高查询性能和容错能力，但也会增加资源占用。您需要根据您的业务需求和查询负载来平衡性能和资源消耗。
硬件资源： 每个 TiFlash 副本需要一定的硬件资源，包括 CPU、内存和存储。您需要确保集群中有足够的硬件资源来支持所需的副本数。
数据复制延迟： TiFlash 副本之间需要进行数据同步，增加副本数可能会导致数据同步延迟增加。这可能会影响查询的实时性。
容错能力： 增加 TiFlash 副本数可以提高系统的容错性，因为在部分副本失效时，其他副本仍然可以继续提供查询服务。
一般…
1 年前
DELETE 操作时间过长，您可以考虑以下优化策略：
分批删除（Batch Delete）： 将大量的删除操作分成多个较小的批次进行，以减少单个事务的数据量，从而减轻 prewrite 阶段的负担。
调整事务隔离级别（Transaction Isolation Level）： 降低事务的隔离级别可能会减少冲突检测的开销，但同时会降低隔离性。
调整索引结构： 表的索引结构会影响 DELETE 操作的性能，可能需要重新评估索引的设计。
1 年前
一些可能的原因：
索引更新： 当表中有索引（包括主键索引和其他索引）时，每次插入操作都需要更新索引。随着数据量的增加，索引的维护成本也会增加，从而导致插入操作变慢。这可能会在大量插入操作后影响性能。
锁竞争： 在并发环境中，多个插入操作可能会竞争相同的资源，如行级锁、表级锁等。随着并发插入的增加，锁竞争可能会导致插入性能下降。
写放大： TiDB 使用 Raft 协议来保证数据的一致性，这可能会导致写放大问题。当多个插入操作被组合成一批提交时，数据可能需要在不同的副本之间进行复制，从而导致写放大，降低性能。
统计信息更新： TiDB 使用统计信息来优化查询计划。随着数据量的增加，统…
1 年前
TableRangeScan操作通常用于主键范围查询。tidb中，主键是用于唯一标识每个数据记录的关键字。TableRangeScan操作允许您在特定的主键范围内检索数据记录，这通常用于执行范围查询、分页查询或其他需要基于主键顺序的查询。
1 年前
没有更多内容了