TiDB 恢复备份后如何用 REFRESH STATS 命令将统计信息重新加载到内存【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidbTiDB 集群启动时会把统计信息加载到每个 TiDB 节点的内存中。当 BR 工具在集群运行期间完成统计信息相关表的物理恢复backup and restore后节点内存中仍然是恢复前的统计信息查询无法及时用上恢复回来的最新统计。设计文档给出的替代方案是整体重启 TiDB 节点让启动流程重新初始化统计但这显然不方便。REFRESH STATS命令就是为解决这个问题引入的它可以在不重启集群、不重新执行ANALYZE的情况下强制把指定表的统计信息重新加载到内存BR 工具恢复完成后即可用它触发刷新。该命令同样适用于排查内存统计信息异常的场景见 设计文档。命令语法与各参数含义命令格式如下来自设计文档的 guide-level 说明REFRESH STATS TARGETS [FULL | LITE] [CLUSTER];文档给出的示例REFRESH STATS db1.tbl1, tbl2, db2.*, *.* FULL CLUSTER;各部分的取值规则TARGETS是逗号分隔的目标列表支持四种形式tab1当前 schema 下的tab1表。注意如果未指定当前数据库解析阶段会直接报ErrNoDB错误因此执行前先用USE db选定数据库或者全部写成db.table形式见 fillDefaultDBForStatsObjectsdb1.tbl1指定库下的具体表db2.*指定库下的所有表*.*集群内所有表。FULL | LITE指定刷新统计信息的类型。省略时取配置项lite-init-statsv7.10 引入的值显式写FULL等价于lite-init-statsfalse显式写LITE等价于lite-init-statstrue见 executeRefreshStatsOnCurrentInstanceCLUSTER设置后刷新发生在集群中所有 TiDB 实例上不设置时只刷新当前连接的 TiDB 实例。因为统计信息存放在各 TiDB 节点的内存中而用户可能只连到单个节点所以跨节点刷新需要CLUSTER。其实现方式是仿照KILL语句通过 coprocessor 框架把语句广播到所有 TiDB 节点store type 设为 TiDB、server ID 设为 0使每个 TiDB 节点各生成一个 coprocessor 任务。执行前置条件集群已启动BR 对统计信息表的恢复操作已经完成执行用户具备目标表的SELECT权限BR 工具则通过动态权限校验设计文档写为 ADMIN_RESTORE源码中的校验名称为 RESTORE_ADMIN见 requireSelectOrRestoreAdminPrivForStatsObjects确认没有其它统计初始化操作正在进行设计文档 FAQ 明确已有 init stats 操作在处理时会尽早返回错误避免并发刷新把实现复杂化。执行步骤以恢复完db1和db2两个库的统计信息为例用具备目标表SELECT权限的账号连接集群后执行REFRESH STATS db1.*, db2.* FULL CLUSTER;需要说明的参数选择目标写成db.*或db.tbl形式可以不依赖当前数据库跨节点广播时也会带上完整限定名避免其它节点因当前库不同而漏刷源码注释中明确解释了这一处理是否需要CLUSTER取决于你的访问方式如果只刷新当前连接的实例省略即可集群多节点时建议加上保证所有节点都加载最新统计FULL/LITE按需指定。文档没有给出二者的性能取舍结论如果你不确定省略该选项让命令跟随lite-init-stats配置即可。结果验证命令正常返回、无报错是刷新触发的基本信号。执行端可在 TiDB 日志中确认刷新完成。源码中会记录如下日志见 executeRefreshStats仅刷新当前实例Successfully refreshed statistics on the current instance集群广播Successfully broadcast query远端节点收到广播后执行Successfully refreshed statistics from remote如果指定的库或表全部不存在命令不会报错也不会做任何刷新源码中的处理是记录No valid database or table to refresh stats后直接返回排查时应先确认目标库表名是否正确。限制与注意事项设计文档在 Impacts Risks 中提示该命令可能对 TiKV 上的在线负载产生性能影响文档建议通过综合测试评估后再使用生产集群中执行前应对影响有预期。设计文档给出的超时参考公式为Timeout min((总表数 × 节点数) / 每分钟 1M 表 1 分钟缓冲, 15 分钟)并明确标注“该估算需要通过测试验证”Unresolved Questions 中性能影响量级仍未定因此不要把 15 分钟上限当作固定承诺值。若集群中已存在部分统计信息做物理恢复会丢弃它们并重建统计信息表设计文档 FAQ 说明这种情况下应退回 stats JSON 备份恢复方案而不是物理恢复。延伸阅读设计文档、执行器实现、权限与语句构建、语法定义。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 TiDB 恢复备份后如何用 REFRESH STATS 命令将统计信息重新加载到内存
TiDB 恢复备份后如何用 REFRESH STATS 命令将统计信息重新加载到内存【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidbTiDB 集群启动时会把统计信息加载到每个 TiDB 节点的内存中。当 BR 工具在集群运行期间完成统计信息相关表的物理恢复backup and restore后节点内存中仍然是恢复前的统计信息查询无法及时用上恢复回来的最新统计。设计文档给出的替代方案是整体重启 TiDB 节点让启动流程重新初始化统计但这显然不方便。REFRESH STATS命令就是为解决这个问题引入的它可以在不重启集群、不重新执行ANALYZE的情况下强制把指定表的统计信息重新加载到内存BR 工具恢复完成后即可用它触发刷新。该命令同样适用于排查内存统计信息异常的场景见 设计文档。命令语法与各参数含义命令格式如下来自设计文档的 guide-level 说明REFRESH STATS TARGETS [FULL | LITE] [CLUSTER];文档给出的示例REFRESH STATS db1.tbl1, tbl2, db2.*, *.* FULL CLUSTER;各部分的取值规则TARGETS是逗号分隔的目标列表支持四种形式tab1当前 schema 下的tab1表。注意如果未指定当前数据库解析阶段会直接报ErrNoDB错误因此执行前先用USE db选定数据库或者全部写成db.table形式见 fillDefaultDBForStatsObjectsdb1.tbl1指定库下的具体表db2.*指定库下的所有表*.*集群内所有表。FULL | LITE指定刷新统计信息的类型。省略时取配置项lite-init-statsv7.10 引入的值显式写FULL等价于lite-init-statsfalse显式写LITE等价于lite-init-statstrue见 executeRefreshStatsOnCurrentInstanceCLUSTER设置后刷新发生在集群中所有 TiDB 实例上不设置时只刷新当前连接的 TiDB 实例。因为统计信息存放在各 TiDB 节点的内存中而用户可能只连到单个节点所以跨节点刷新需要CLUSTER。其实现方式是仿照KILL语句通过 coprocessor 框架把语句广播到所有 TiDB 节点store type 设为 TiDB、server ID 设为 0使每个 TiDB 节点各生成一个 coprocessor 任务。执行前置条件集群已启动BR 对统计信息表的恢复操作已经完成执行用户具备目标表的SELECT权限BR 工具则通过动态权限校验设计文档写为 ADMIN_RESTORE源码中的校验名称为 RESTORE_ADMIN见 requireSelectOrRestoreAdminPrivForStatsObjects确认没有其它统计初始化操作正在进行设计文档 FAQ 明确已有 init stats 操作在处理时会尽早返回错误避免并发刷新把实现复杂化。执行步骤以恢复完db1和db2两个库的统计信息为例用具备目标表SELECT权限的账号连接集群后执行REFRESH STATS db1.*, db2.* FULL CLUSTER;需要说明的参数选择目标写成db.*或db.tbl形式可以不依赖当前数据库跨节点广播时也会带上完整限定名避免其它节点因当前库不同而漏刷源码注释中明确解释了这一处理是否需要CLUSTER取决于你的访问方式如果只刷新当前连接的实例省略即可集群多节点时建议加上保证所有节点都加载最新统计FULL/LITE按需指定。文档没有给出二者的性能取舍结论如果你不确定省略该选项让命令跟随lite-init-stats配置即可。结果验证命令正常返回、无报错是刷新触发的基本信号。执行端可在 TiDB 日志中确认刷新完成。源码中会记录如下日志见 executeRefreshStats仅刷新当前实例Successfully refreshed statistics on the current instance集群广播Successfully broadcast query远端节点收到广播后执行Successfully refreshed statistics from remote如果指定的库或表全部不存在命令不会报错也不会做任何刷新源码中的处理是记录No valid database or table to refresh stats后直接返回排查时应先确认目标库表名是否正确。限制与注意事项设计文档在 Impacts Risks 中提示该命令可能对 TiKV 上的在线负载产生性能影响文档建议通过综合测试评估后再使用生产集群中执行前应对影响有预期。设计文档给出的超时参考公式为Timeout min((总表数 × 节点数) / 每分钟 1M 表 1 分钟缓冲, 15 分钟)并明确标注“该估算需要通过测试验证”Unresolved Questions 中性能影响量级仍未定因此不要把 15 分钟上限当作固定承诺值。若集群中已存在部分统计信息做物理恢复会丢弃它们并重建统计信息表设计文档 FAQ 说明这种情况下应退回 stats JSON 备份恢复方案而不是物理恢复。延伸阅读设计文档、执行器实现、权限与语句构建、语法定义。【免费下载链接】tidbTiDB is built for agentic workloads that grow unpredictably, with ACID guarantees and native support for transactions, analytics, and vector search. No data silos. No noisy neighbors. No infrastructure ceiling.项目地址: https://gitcode.com/GitHub_Trending/ti/tidb创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考