为支持历史数据转储的规划与决策,请问如何通过SQL语句,准确统计数据库中各个表的近期查询与写入次数?
不大可能有这个数据吧,每个请求都记录,代价有点高吧
为什么要统计这个,要解决什么
盲猜是想统计历史数据到底被访问的频率及到底多久远的数据被访问,好决策是否清理五年前、三年前、一年前的数据吧。
你应该统计应用侧的接口访问日志,最好捕获接口传参。
表的update次数吗?
– 统计非系统表的读写频次
SELECT
OBJECT_SCHEMA AS DatabaseName,
OBJECT_NAME AS TableName,
COUNT_READ,
COUNT_WRITE,
(COUNT_READ + COUNT_WRITE) AS TotalAccessCount,
– 计算读写比例
ROUND((COUNT_READ / (COUNT_READ + COUNT_WRITE)) * 100, 2) AS ReadPercentage
FROM performance_schema.table_io_waits_summary_by_table
WHERE
OBJECT_SCHEMA NOT IN (‘mysql’, ‘information_schema’, ‘performance_schema’, ‘sys’)
AND (COUNT_READ > 0 OR COUNT_WRITE > 0)
ORDER BY TotalAccessCount DESC;
可通过 performance_schema.table_io_waits_summary_by_table 表查询,过滤非系统库,统计 COUNT_READ(查询)和 COUNT_WRITE(写入)次数。
TiDB 本身无内置 “表级查询 / 写入次数计数器”,需借助 内置系统表 + 慢查询日志 实现统计,核心依赖 TiDB 对表访问的元数据记录与语句审计能力
- 数据有效期:
PERFORMANCE_SCHEMA数据默认重启后清空,若需长期统计,需定期通过 SQL 导出数据留存;慢查询日志需配置日志轮转,避免磁盘溢出。 - 复杂 SQL 适配:上述提取表名的方式对关联查询、子查询适配有限,可通过正则表达式优化(如
REGEXP 'FROM\\s+table_name'),或结合TiDB Audit Log实现更精准的表级审计。 - 权限要求:执行 SQL 需拥有
PERFORMANCE_SCHEMA、mysql库的查询权限(如SELECT权限)。 - 性能影响:开启全量慢查询日志(
long_query_time=0)会增加 TiDB 性能开销,生产环境建议仅在统计周期内开启,或使用TiDB 监控辅助统计。
好像只能参考审计表吧
table_io_waits_summary_by_table提示表不存在。
mysql库里试了下,好使。但是tidb里没有这个表。
数据库里的大表越来越多,单纯的统计表大小,难于说明不做数据转储对性能的影响,所以想补充个io使用维度的统计。