DBeaver不提供表访问频率统计功能，因其仅为元数据浏览和SQL执行工具，非性能监控平台；“访问热度”需依赖数据库运行时会话、审计或查询日志，而这些默认未开启、未聚合、不可被DBeaver直接读取。
它不提供表访问频率统计功能，数据库本身也不直接暴露这个维度的实时指标。 DBeaver 是一个元数据浏览和 SQL 执行工具，不是性能监控平台。所谓“访问热度”需要依赖数据库运行时的会话、审计或历史查询日志，而这些数据默认不开启、不聚合、不持久化到可被 DBeaver 直接读取的视图中。
为什么 DBeaver 没有“访问热度”标签页
DBeaver 的 Statistics 标签页只读取数据库系统表中已有的统计信息（如行数、索引大小、最后分析时间），这些是优化器用的静态元数据，和“谁在什么时候查了这张表”完全无关。访问频次属于动态行为指标，必须由数据库主动采集并存储——而绝大多数数据库（MySQL、PostgreSQL、SQL Server 默认安装）并不开启这类审计或性能追踪。
常见误区包括：
- 把
pg_stat_all_tables.seq_scan或innodb_table_stats误认为访问次数（实际是全表扫描次数或采样估算值，不包含索引查找、DML、缓存命中等） - 以为右键表 → “查看会话”能列出历史访问记录（该功能只显示当前活跃会话，且仅限连接未断开的实时快照）
- 期待 DBeaver 自动解析慢查询日志或 general_log（它不具备日志解析能力，也不默认连接日志源）
MySQL 中如何间接估算表热度
如果 MySQL 开启了 performance_schema（默认 5.7+ 启用），可通过以下语句查近期扫描/锁等待行为，但注意：这不是“访问次数”，而是“资源争用痕迹”：
SELECT object_name AS table_name,
count_read + count_write AS io_count,
lock_wait_time
FROM performance_schema.table_io_waits_summary_by_table
WHERE object_schema = 'your_db'
ORDER BY io_count DESC
LIMIT 10;关键点：
-
count_read和count_write是自上次重置以来的 I/O 次数，非 SQL 调用次数 - 该视图需
performance_schema开启，且默认只保留部分表的聚合数据 - 重置计数需执行
TRUNCATE TABLE performance_schema.table_io_waits_summary_by_table，生产环境慎用
PostgreSQL 中可查最近活动但非精确热度
PostgreSQL 提供 pg_stat_all_tables，字段如 seq_tup_read、idx_tup_fetch 反映的是元组级读取量，接近但不等于“被查了多少次”：
SELECT relname AS table_name,
seq_tup_read + idx_tup_fetch AS tuple_reads,
n_tup_ins - n_tup_del AS net_row_change
FROM pg_stat_all_tables
WHERE schemaname = 'public'
ORDER BY tuple_reads DESC
LIMIT 10;注意事项：
- 数值累积自数据库启动或上次
VACUUM ANALYZE，不按天/小时归档 - 高并发下多个查询可能合并为一次 tuple fetch，无法反推 SQL 调用频次
- 若长期未
VACUUM，统计可能严重滞后甚至溢出归零
真正需要热度数据时该怎么做
别指望 DBeaver 自动生成热度报表。真实可行路径只有两条：
- 启用数据库原生审计：MySQL 开启
general_log（性能损耗大，仅调试用）；PostgreSQL 设置log_statement = 'all'并配合pg_stat_statements插件聚合；SQL Server 启用 Extended Events 跟踪sql_batch_completed - 外挂 APM 工具：用 SkyWalking、Datadog 或开源的 pgBadger（PostgreSQL）、pt-query-digest（MySQL）解析日志，再可视化展示表级访问分布
最容易被忽略的一点：即使你拿到了原始日志，DBeaver 也无法直接导入分析——它没有日志解析模块，所有聚合、去重、时间窗口切分都得靠外部脚本或专用工具完成。
