遇到磁盘告警、慢查询调优或者要评估迁移方案时DBA和开发问得最多的一个问题就是“这张表到底占了多少空间”可一旦换了一个数据库原本顺手拈来的查询语句可能就完全不适用了。MySQL 有 information_schemaPostgreSQL 有一堆 pg 开头的函数Oracle 要看段视图SQL Server 又得折腾系统视图……这就是很多人在“数据库表格大小”这件事上反复踩坑的原因。这篇《屠龙刀法36》就把常见数据库的查表大小方法一次性梳理清楚覆盖 MySQL、PostgreSQL、Oracle、SQL Server、达梦、人大金仓、SQLite 和 ClickHouse并附带我在实际运维中积累的注意事项争取让你看完就能直接照着用。1. 先搞清楚你为什么需要关心表格大小1.1 表格大小信息能解决哪些问题按我的经验关心表格大小的场景通常就那么几类。第一类是磁盘空间告警。半夜收到服务器磁盘空间不足的消息登录数据库后第一件事就是找出哪张表膨胀得最厉害。这时候如果还一个个表去估算磁盘早满了。第二类是慢查询优化。优化 SQL 之前必须先知道表的数据量和物理占用。一个 10 万行的表和 1 亿行的表即使查询语句写得一模一样优化思路也完全不同。大表要考虑索引、分区、分库分表小表可能一条普通索引就解决了。第三类是迁移和备份评估。要把数据库从旧服务器搬到新机器或者从线下迁到云上估算目标库容量时表格大小就是最直接的依据。备份策略、存储成本、网络传输时间全都跟它挂钩。第四类是容量规划。业务上线前要做容量评估DBA 需要知道现有表增长速度从而预测未来半年到一年的空间需求。还有一个场景我常碰到数据库课程设计或考试题库里要统计表大小很多学生只知道查看 Excel 里的行数到了真实数据库环境就懵了。本质上表格大小和行数是两个概念行数只是数据量的一部分还有索引、冗余、碎片、系统保留空间等。1.2 总体思路不同数据库的“档案库”在哪里说一句大实话不同数据库查表大小的方法千差万别但底层思路是完全一致的——去“系统表/系统视图”里找元数据。MySQL、SQL Server、Oracle、PostgreSQL 都有自己的“元数据库”只是名字和存法不一样。MySQL 叫 information_schemaPostgreSQL 有 pg_catalog 和一堆视图Oracle 有数据字典视图SQL Server 存在于系统表中。本质上表大小就是一些元数据字段的统计结果比如字节数、页数、段数。但在细节上不同数据库的精确程度差异很大MySQL 的 information_schema 是估算值InnoDB 引擎下尤其不准PostgreSQL 提供的是基于统计信息与文件系统信息的综合值相对准确Oracle 的 dba_segments 是基于“段分配”的空间也就是 Oracle 已经分配出去的空间不是实际数据文件大小SQL Server 的 sys.dm_db_partition_stats 能精确反映页分配情况SQLite 最简单直接算文件大小就行。可见理解这些差异比记住某一条 SQL 更重要。只要掌握了“元数据视图 字节换算”这个基本框架换一个数据库也不会慌。2. MySQL最常用也最容易被表象骗到的查询方式2.1 基础查询information_schema.tables 里的关键字段MySQL 中查表大小最常用的就是 information_schema.tables 表。它本身就存着每张表的元数据关键字段有 TABLE_NAME、TABLE_ROWS、DATA_LENGTH、INDEX_LENGTH、DATA_FREE、ENGINE、TABLE_SCHEMA 这几个。字段含义先讲明白DATA_LENGTH数据部分占用的字节数。对于 InnoDB 表这是聚簇索引占用的空间也就是实际数据行所在的空间INDEX_LENGTH索引部分占用的字节数DATA_FREE碎片空间也就是表里有空闲但没被利用的页TABLE_ROWS估算的行数注意只是估算不是精确值。下面的 SQL 能把一个库里所有表按占用空间从大到小排列并自动换算成 MBSELECT TABLE_NAME, ROUND((DATA_LENGTH INDEX_LENGTH) / 1024 / 1024, 2) AS total_size_mb, ROUND(DATA_LENGTH / 1024 / 1024, 2) AS data_mb, ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS index_mb, ROUND(DATA_FREE / 1024 / 1024, 2) AS free_mb, TABLE_ROWS FROM information_schema.tables WHERE TABLE_SCHEMA your_database ORDER BY (DATA_LENGTH INDEX_LENGTH) DESC;建议把 WHERE 子句里的库名换成实际库名然后 LIMIT 20优先看排前面的表。2.2 按库统计与快速定位大表如果只想快速知道哪个库占空间最多可以按 TABLE_SCHEMA 分组求和SELECT TABLE_SCHEMA, ROUND(SUM(DATA_LENGTH INDEX_LENGTH) / 1024 / 1024, 2) AS total_size_mb, ROUND(SUM(DATA_FREE) / 1024 / 1024, 2) AS total_free_mb FROM information_schema.tables GROUP BY TABLE_SCHEMA ORDER BY total_size_mb DESC;我最喜欢用的一个场景是定位某个业务库里最大的 10 张表快速找出“空间刺客”。有一次我排查 MySQL 告警就是靠这条语句发现一个日志表已经占了几十 GB而业务上早就没人读了最后直接归档清理效果立竿见影。2.3 坑点统计信息不实时别拿旧账当真相用 MySQL 的 information_schema 查表大小最需要注意的是结果并非实时。InnoDB 引擎下TABLE_ROWS 是预估值官方文档也说这是个大概数字而 DATA_LENGTH 和 INDEX_LENGTH 也可能依赖统计信息。比如说你往一张空表里插入了 100 万行立刻去查 information_schema.tables看到的 TABLE_ROWS 可能还是 0 或者一个很旧的值。解决方法就一个字analyze。ANALYZE TABLE your_table;执行完后统计信息会刷新查询结果才会更接近真实值。但即便如此对于 InnoDB 表行数仍然会有一定偏差。如果非要精确行数只能 COUNT()但大表 COUNT() 本身就很慢生产环境要谨慎。还有一个隐藏坑information_schema.tables 里面统计的是“表空间”的概念而 InnoDB 表可能因为行溢出、外部存储、压缩等机制在实际物理文件.ibd上占用的大小会和这个值有出入。如果遇到数据文件特别大的情况直接去 datadir 下面核对 .ibd 文件大小也是常见手段。3. PostgreSQL函数丰富但要知道该调哪个3.1 库、表、索引、TOAST 大小函数对比PostgreSQL 比 MySQL 做得更规整提供了一组非常易用的函数全是 pg_ 开头。它们之间区别主要体现在“范围”上pg_database_size(oid)某个数据库整体占用的磁盘空间包含所有表、索引、序列、系统表等pg_relation_size(oid)某张表本身占用的空间注意是不含索引的pg_total_relation_size(oid)某张表及其索引、TOAST 表等全部关联对象加在一起的总体积pg_indexes_size(oid)某张表上所有索引的总大小pg_size_pretty(size)把字节数自动转成可读字符串比如 12335 MB。我经常用的一条语句是SELECT pg_size_pretty(pg_database_size(your_db)) AS db_size;如果没有权限查看其他库可以连接到你自己的库后用 current_database() 代替SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;3.2 一条 SQL 看所有表大小PostgreSQL 里查所有表的大小一般要联合 pg_class、pg_namespaceSELECT n.nspname AS schema_name, c.relname AS table_name, pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size, pg_size_pretty(pg_relation_size(c.oid)) AS table_size, pg_size_pretty(pg_indexes_size(c.oid)) AS index_size FROM pg_class c JOIN pg_namespace n ON n.oid c.relnamespace WHERE c.relkind r AND n.nspname NOT IN (pg_catalog, information_schema) ORDER BY pg_total_relation_size(c.oid) DESC;解释一下关键条件c.relkind r 表示普通表排除索引、序列、视图等schema 过滤是为了不显示 PostgreSQL 自带的系统表。执行结果里total_size 是“表本身 索引 TOAST”这通常才是真实磁盘上占用的空间。TOAST 是 PostgreSQL 处理大字段比如 text、bytea的辅助存储机制一张表有很多大字段时TOAST 体积可能远超主表本身不看 total_size 你根本猜不到空间去哪了。3.3 注意事务膨胀与统计表的差异PostgreSQL 还有一个比较特殊的问题因为 MVCC 机制表在频繁更新、删除后会产生大量死元组导致表膨胀。你可能看到 pg_total_relation_size 很大但实际有效数据很少这就是典型的膨胀。解决方法通常要执行 VACUUM FULL这个操作会重建表并回收空间但它会锁表在线业务需要谨慎安排时间窗口。平时维护可以定期执行 VACUUM ANALYZE它不会锁表但也不能完全回收空间只能更新统计信息和清理旧元组。PostgreSQL 的统计信息视图 pg_stat_user_tables 里还包含 n_live_tup、n_dead_tup 等字段可以用来辅助判断表是否严重膨胀。4. Oracle 与国产数据库段segment思维和系统视图4.1 Oracle 的 dba_segments 与 user_segments切换到 Oracle你会发现概念完全不一样了。Oracle 把数据库对象占用的物理空间叫作“段segment”一个表如果建了索引那至少有两个段表段和索引段。查表大小就是查段的大小。普通用户没有 DBA 权限时可以查 user_segments它会返回当前用户自己拥有的段DBA 用户或授权用户可查 dba_segments能看到所有 schema 的对象。常用查询如下SELECT segment_name, segment_type, ROUND(bytes / 1024 / 1024, 2) AS size_mb FROM user_segments WHERE segment_type TABLE ORDER BY bytes DESC;如果你还想看表和索引一起的大小可以去掉 WHERE segment_type TABLE 限制直接按 segment_name 聚合。Oracle 里还有一种常见需求就是查表的行数和大小一起展示。需要有统计信息SELECT t.table_name, t.num_rows, ROUND(s.bytes / 1024 / 1024, 2) AS size_mb FROM user_tables t LEFT JOIN user_segments s ON s.segment_name t.table_name AND s.segment_type TABLE ORDER BY s.bytes DESC;这里字段 num_rows 是统计信息里的行数不是实时值精确行数需要执行 DBMS_STATS.GATHER_TABLE_STATS 刷新。4.2 达梦、人大金仓的差异与踩坑记录做国产化改造时达梦DM和人大金仓KingbaseES也是高频出现的目标数据库。这两类数据库的兼容策略不同查看表大小的方式也有差异。达梦数据库整体语法与 Oracle 高度相似尤其是数据库结构层面。很多 Oracle 管理语句在达梦里几乎可以直接跑。比如查当前用户下表大小SELECT segment_name, segment_type, ROUND(bytes / 1024 / 1024, 2) AS size_mb FROM user_segments WHERE segment_type TABLE ORDER BY bytes DESC;如果遇到没有 user_segments 视图的版本也可以查 all_segments 或 dba_segments反正在达梦里能看到“段”字样的视图基本就是查这个。需要注意不同版本、不同模式Oracle 兼容模式/MySQL 兼容模式下的系统视图会有些差异我建议首次连接后先跑一条 SELECT * FROM ALL_SEGMENTS WHERE ROWNUM 10 看看能读出什么字段再改写成符合需求的 SQL。人大金仓 KingbaseES 是基于 PostgreSQL 内核开发的所以大部分 PostgreSQL 函数都能直接用比如前面提到的 pg_total_relation_size。我在实际项目里用类似下面的语句查过表大小SELECT schemaname, tablename, pg_size_pretty(pg_total_relation_size(schemaname || . || tablename)) AS total_size FROM pg_tables WHERE schemaname NOT IN (pg_catalog, information_schema) ORDER BY pg_total_relation_size(schemaname || . || tablename) DESC;不过还是要提醒一句金仓版本众多不同版本的兼容层细节会有差异。如果你对国产数据库不熟悉建议把这套查询放到一套测试库上先跑一遍确认输出没问题再上生产环境。遇到“视图或函数不存在”的报错先别慌通常只是用户权限不足或视图名不同换一个等价视图往往就通了。5. SQL Server系统视图和存储过程5.1 sp_spaceused 和 sys.tables 的联合使用SQL Server 里最简单的单表大小查看方法是存储过程 sp_spaceused。直接传表名进去EXEC sp_spaceused dbo.your_table;返回结果会包含行数、保留空间reserved、数据空间data、索引大小index_size和未使用空间unused。这个方式最快但一次只能看一张表。要一次看全库所有表就要查询系统视图了。常用到 sys.tables、sys.indexes、sys.dm_db_partition_stats、sys.allocation_units 这几个对象。sys.dm_db_partition_stats 返回每个分区的行数、预留页数等配合 sys.allocation_units 可以算出实际使用空间。下面是一条我在 SQL Server 2008 到 2019 都验证过的查询SELECT t.name AS table_name, p.rows AS row_count, SUM(a.total_pages) * 8 / 1024 AS total_size_mb, SUM(a.used_pages) * 8 / 1024 AS used_size_mb, (SUM(a.total_pages) - SUM(a.used_pages)) * 8 / 1024 AS unused_size_mb FROM sys.tables t JOIN sys.indexes i ON t.object_id i.object_id JOIN sys.partitions p ON i.object_id p.object_id AND i.index_id p.index_id JOIN sys.allocation_units a ON p.partition_id a.container_id WHERE t.is_ms_shipped 0 GROUP BY t.name, p.rows ORDER BY total_size_mb DESC;这里的关键是total_pages 是“页”的数量SQL Server 每页是 8KB所以乘以 8 得到 KB再除以 1024 得到 MB。注意索引也以 index_id 区分如果只想统计堆表或聚集索引可以根据 index_id 过滤但日常场景直接聚合更好。5.2 快速得到所有表大小报表如果你用的是 SQL Server Management StudioSSMS其实有内置报表功能。右键数据库名 → 报表 → 标准报表 → “按表分区的磁盘使用情况”就能直接看到所有表的行数、数据空间、索引空间和总空间。不过我在实际环境里更偏爱上一条 SQL 查询因为可以随时导出、过滤、排序列还能在自动巡检脚本里用。SQL Server 的统计信息可能也存在滞后。如果感觉大小和实际不符可执行DBCC UPDATEUSAGE(0);这个命令会更新系统目录中的页面计数和行数信息让查询更准确。注意执行时可能对数据库造成一定开销建议在业务低峰期执行。6. SQLite 和 ClickHouse不一样思路的数据库6.1 SQLite单文件数据库怎么算大小SQLite 是嵌入式数据库整个库通常就是一个文件。所以最朴素的查表大小方法是在操作系统层面执行 ls -l直接看数据库文件大小ls -lh /path/to/your_database.db但这只是整体文件大小。如果需要知道内部哪张表占了多少空间SQLite 也提供了 dbstat 虚拟表接口需要 SQLite 编译时开启了 SQLITE_ENABLE_DBSTAT_VTAB 选项。可以这样查SELECT name AS table_name, SUM(pgsize) / 1024.0 AS size_kb FROM dbstat GROUP BY name ORDER BY size_kb DESC;dbstat 里 pgsize 表示每个 B-tree 页占用的字节数聚合后就能得到每个表包括索引的大小。要注意SQLite 的表通常以 B-tree 组织索引也在这个输出里。如果没有 dbstat 虚拟表那就退而求其次用 PRAGMA page_count 和 page_size 计算总体大小最多只能看到整个库的大小PRAGMA page_count; PRAGMA page_size;两者相乘就是当前数据库文件的理论大小单位是字节。因为 SQLite 会预分配页面这个值可能和实际文件大小有细微差别。6.2 ClickHouse按分区查大小其实更实用ClickHouse 是列式分析数据库很多人在做日志或指标分析时用它。“表大小”这个概念在 ClickHouse 里通常要看系统表 system.parts它记录每一部分part的数据量。SELECT table, formatReadableSize(sum(bytes_on_disk)) AS total_size FROM system.parts WHERE active GROUP BY table ORDER BY sum(bytes_on_disk) DESC;说明一下active 条件用于过滤掉已经合并但还没清理的旧分区数据。ClickHouse 后台会自动合并数据分区只查询 active 分片能反映业务上正在使用的数据大小避免重复计数。更进一步可以按分区查看大小用来定位分区数据倾斜或者做冷热数据评估SELECT table, partition_id, formatReadableSize(sum(bytes_on_disk)) AS partition_size, count() AS part_count FROM system.parts WHERE active AND database your_db GROUP BY table, partition_id ORDER BY sum(bytes_on_disk) DESC LIMIT 20;ClickHouse 的压缩率通常非常高bytes_on_disk 是磁盘真实占用而不是原始数据大小。7. 用工具偷懒DBeaver、Navicat 与命令行7.1 DBeaver 的表属性面板怎么用DBeaver 是最主流的多数据库客户端之一支持的数据库非常多日常开发中配合 MySQL、PostgreSQL、达梦、金仓都是不错的组合。在数据库导航树里找到某张表右键选择“查看表信息”或“属性”DBeaver 会显示表的 DDL、行数、存储信息等。但在不同数据库上DBeaver 对表大小的展示支持不太一样。比如 PostgreSQL 一般能看到比较完整的大小信息MySQL 也能看到简单的统计而 Oracle 可能只能看到段信息。如果 DBeaver 的界面没有直接显示大小我的经验是直接在 SQL 终端里执行对应的查询语句然后把结果保存为 DBeaver 的“查询”书签下次需要时一键打开比翻面板快很多。7.2 各数据库命令行查看方式速查命令行永远是最后兜底的手段尤其在服务器上没法开 GUI 客户端时。MySQL 可以用SHOW TABLE STATUS FROM your_database;这个命令直接输出表行数、数据长度、索引长度等字段和查询 information_schema 本质上是一回事但写法更简洁。PostgreSQL 在 psql 终端里可以用\dt 表名这条元命令会显示表大小、描述等信息类似地 \l 显示所有数据库大小。注意 \dt 显示的大小只包含表本身的存储不包含索引和 TOAST需要看总体大小还是要用 SQL 查询。SQL Server 用 SQLCMD 时直接执行第 5 节里的 SQL 即可。Oracle 在 SQL*Plus 里执行 user_segments 的 SELECT 也没问题。8. 常见问题排查与经验总结8.1 统计值不准确时的处理方案这一节我放在最后是因为它其实是实践中最重要的内容不管用哪种数据库查出来的表大小都可能是“不精确”的。MySQL 的 information_schema 中行数是估算值建议 ANALYZE TABLE 刷新统计信息PostgreSQL 的表大小实时性较好但膨胀会导致统计值与物理空间差距大建议定期 VACUUM ANALYZEOracle 的段大小反映的是已分配空间可能存在高水位线问题需要通过 shrink space 或 move 释放物理空间SQL Server 建议先用 DBCC UPDATEUSAGE(0) 修正统计再查询。所谓“高水位线”可以通俗理解为一桶水喝完但桶还是那么大水位降不下去。Oracle、PostgreSQL、MySQL 都有类似的碎片和空间复用机制。如果一张表删了大量数据文件却不见变小大概率就是这个问题。8.2 权限不足怎么看很多同学连上数据库后一查系统视图就报错说没有权限。这里给大家一个解决思路优先使用当前用户可以访问的系统视图或函数。Oracle 没有 DBA 权限就用 USER_SEGMENTS、USER_TABLES只能看自己的对象MySQL 至少需要 PROCESS 权限才能查 information_schema没有就找 DBA 授权SQL Server 普通用户可能连 sys.dm_db_partition_stats 都查不到建议找 DBA 开通 VIEW DEFINITION 或者使用 SSMS 内置报表PostgreSQL 的元数据访问一般用户都能查到但持有更细粒度权限限制时也可能受限。总的原则是先确认当前用户能看到的视图范围再设计查询。权限越少能看到的对象越少这是数据库安全设计不是 Bug。8.3 计算大小和清理碎片的一些心得最后分享一点个人体会。把“查表大小”这件事做好绝不只是执行一条 SQL 那么简单。我日常工作里会做两件事一是把常用查询整理成一个脚本库比如 dbsize_mysql.sql、dbsize_pg.sql、dbsize_oracle.sql、dbsize_sqlserver.sql每个文件里放对应数据库的查表大小 SQL并写好注释。新环境、新项目直接用省时省力。二是在做表空间优化时不要随便执行 OPTIMIZE TABLE、VACUUM FULL、SHRINK SPACE 这类重量级操作。它们都可能造成锁表或严重 IO 压力。最好先评估业务允许的停机窗口再选择合适的清理策略。我遇到过最典型的案例是一个 MySQL 的日志表已经膨胀到 40GB实际有效数据只有 500MB。用 OPTIMIZE TABLE 重建后空间立刻释放整个过程花了不到三分钟但期间表被锁定对线上写入有一定影响。后来我们改成夜间自动切换日志表 定期归档旧数据的方式就把这类问题彻底规避了。另一个经验是查表格大小别只看表本身一定要把索引、TOAST、LOB 段、分区等关联对象算进去。MySQL 里看 DATA_LENGTH INDEX_LENGTHOracle 里看段类型包含 TABLE 和 INDEXPostgreSQL 里用 pg_total_relation_sizeSQL Server 里把 reserved 字段当作参考这些都是我在实战中踩过的坑总结出来的。表格大小查询是个“小功能”但它牵扯到数据库的存储引擎、统计信息、系统视图权限、碎片回收机制等一系列底层设计。希望这篇整理能帮你建立一套“换什么库都能快速上手”的思路——只要找到元数据视图再注意统计信息和权限边界这个需求就永远难不倒你。
遇到磁盘告警、慢查询调优或者要评估迁移方案时DBA和开发问得最多的一个问题就是“这张表到底占了多少空间”可一旦换了一个数据库原本顺手拈来的查询语句可能就完全不适用了。MySQL 有 information_schemaPostgreSQL 有一堆 pg 开头的函数Oracle 要看段视图SQL Server 又得折腾系统视图……这就是很多人在“数据库表格大小”这件事上反复踩坑的原因。这篇《屠龙刀法36》就把常见数据库的查表大小方法一次性梳理清楚覆盖 MySQL、PostgreSQL、Oracle、SQL Server、达梦、人大金仓、SQLite 和 ClickHouse并附带我在实际运维中积累的注意事项争取让你看完就能直接照着用。1. 先搞清楚你为什么需要关心表格大小1.1 表格大小信息能解决哪些问题按我的经验关心表格大小的场景通常就那么几类。第一类是磁盘空间告警。半夜收到服务器磁盘空间不足的消息登录数据库后第一件事就是找出哪张表膨胀得最厉害。这时候如果还一个个表去估算磁盘早满了。第二类是慢查询优化。优化 SQL 之前必须先知道表的数据量和物理占用。一个 10 万行的表和 1 亿行的表即使查询语句写得一模一样优化思路也完全不同。大表要考虑索引、分区、分库分表小表可能一条普通索引就解决了。第三类是迁移和备份评估。要把数据库从旧服务器搬到新机器或者从线下迁到云上估算目标库容量时表格大小就是最直接的依据。备份策略、存储成本、网络传输时间全都跟它挂钩。第四类是容量规划。业务上线前要做容量评估DBA 需要知道现有表增长速度从而预测未来半年到一年的空间需求。还有一个场景我常碰到数据库课程设计或考试题库里要统计表大小很多学生只知道查看 Excel 里的行数到了真实数据库环境就懵了。本质上表格大小和行数是两个概念行数只是数据量的一部分还有索引、冗余、碎片、系统保留空间等。1.2 总体思路不同数据库的“档案库”在哪里说一句大实话不同数据库查表大小的方法千差万别但底层思路是完全一致的——去“系统表/系统视图”里找元数据。MySQL、SQL Server、Oracle、PostgreSQL 都有自己的“元数据库”只是名字和存法不一样。MySQL 叫 information_schemaPostgreSQL 有 pg_catalog 和一堆视图Oracle 有数据字典视图SQL Server 存在于系统表中。本质上表大小就是一些元数据字段的统计结果比如字节数、页数、段数。但在细节上不同数据库的精确程度差异很大MySQL 的 information_schema 是估算值InnoDB 引擎下尤其不准PostgreSQL 提供的是基于统计信息与文件系统信息的综合值相对准确Oracle 的 dba_segments 是基于“段分配”的空间也就是 Oracle 已经分配出去的空间不是实际数据文件大小SQL Server 的 sys.dm_db_partition_stats 能精确反映页分配情况SQLite 最简单直接算文件大小就行。可见理解这些差异比记住某一条 SQL 更重要。只要掌握了“元数据视图 字节换算”这个基本框架换一个数据库也不会慌。2. MySQL最常用也最容易被表象骗到的查询方式2.1 基础查询information_schema.tables 里的关键字段MySQL 中查表大小最常用的就是 information_schema.tables 表。它本身就存着每张表的元数据关键字段有 TABLE_NAME、TABLE_ROWS、DATA_LENGTH、INDEX_LENGTH、DATA_FREE、ENGINE、TABLE_SCHEMA 这几个。字段含义先讲明白DATA_LENGTH数据部分占用的字节数。对于 InnoDB 表这是聚簇索引占用的空间也就是实际数据行所在的空间INDEX_LENGTH索引部分占用的字节数DATA_FREE碎片空间也就是表里有空闲但没被利用的页TABLE_ROWS估算的行数注意只是估算不是精确值。下面的 SQL 能把一个库里所有表按占用空间从大到小排列并自动换算成 MBSELECT TABLE_NAME, ROUND((DATA_LENGTH INDEX_LENGTH) / 1024 / 1024, 2) AS total_size_mb, ROUND(DATA_LENGTH / 1024 / 1024, 2) AS data_mb, ROUND(INDEX_LENGTH / 1024 / 1024, 2) AS index_mb, ROUND(DATA_FREE / 1024 / 1024, 2) AS free_mb, TABLE_ROWS FROM information_schema.tables WHERE TABLE_SCHEMA your_database ORDER BY (DATA_LENGTH INDEX_LENGTH) DESC;建议把 WHERE 子句里的库名换成实际库名然后 LIMIT 20优先看排前面的表。2.2 按库统计与快速定位大表如果只想快速知道哪个库占空间最多可以按 TABLE_SCHEMA 分组求和SELECT TABLE_SCHEMA, ROUND(SUM(DATA_LENGTH INDEX_LENGTH) / 1024 / 1024, 2) AS total_size_mb, ROUND(SUM(DATA_FREE) / 1024 / 1024, 2) AS total_free_mb FROM information_schema.tables GROUP BY TABLE_SCHEMA ORDER BY total_size_mb DESC;我最喜欢用的一个场景是定位某个业务库里最大的 10 张表快速找出“空间刺客”。有一次我排查 MySQL 告警就是靠这条语句发现一个日志表已经占了几十 GB而业务上早就没人读了最后直接归档清理效果立竿见影。2.3 坑点统计信息不实时别拿旧账当真相用 MySQL 的 information_schema 查表大小最需要注意的是结果并非实时。InnoDB 引擎下TABLE_ROWS 是预估值官方文档也说这是个大概数字而 DATA_LENGTH 和 INDEX_LENGTH 也可能依赖统计信息。比如说你往一张空表里插入了 100 万行立刻去查 information_schema.tables看到的 TABLE_ROWS 可能还是 0 或者一个很旧的值。解决方法就一个字analyze。ANALYZE TABLE your_table;执行完后统计信息会刷新查询结果才会更接近真实值。但即便如此对于 InnoDB 表行数仍然会有一定偏差。如果非要精确行数只能 COUNT()但大表 COUNT() 本身就很慢生产环境要谨慎。还有一个隐藏坑information_schema.tables 里面统计的是“表空间”的概念而 InnoDB 表可能因为行溢出、外部存储、压缩等机制在实际物理文件.ibd上占用的大小会和这个值有出入。如果遇到数据文件特别大的情况直接去 datadir 下面核对 .ibd 文件大小也是常见手段。3. PostgreSQL函数丰富但要知道该调哪个3.1 库、表、索引、TOAST 大小函数对比PostgreSQL 比 MySQL 做得更规整提供了一组非常易用的函数全是 pg_ 开头。它们之间区别主要体现在“范围”上pg_database_size(oid)某个数据库整体占用的磁盘空间包含所有表、索引、序列、系统表等pg_relation_size(oid)某张表本身占用的空间注意是不含索引的pg_total_relation_size(oid)某张表及其索引、TOAST 表等全部关联对象加在一起的总体积pg_indexes_size(oid)某张表上所有索引的总大小pg_size_pretty(size)把字节数自动转成可读字符串比如 12335 MB。我经常用的一条语句是SELECT pg_size_pretty(pg_database_size(your_db)) AS db_size;如果没有权限查看其他库可以连接到你自己的库后用 current_database() 代替SELECT pg_size_pretty(pg_database_size(current_database())) AS db_size;3.2 一条 SQL 看所有表大小PostgreSQL 里查所有表的大小一般要联合 pg_class、pg_namespaceSELECT n.nspname AS schema_name, c.relname AS table_name, pg_size_pretty(pg_total_relation_size(c.oid)) AS total_size, pg_size_pretty(pg_relation_size(c.oid)) AS table_size, pg_size_pretty(pg_indexes_size(c.oid)) AS index_size FROM pg_class c JOIN pg_namespace n ON n.oid c.relnamespace WHERE c.relkind r AND n.nspname NOT IN (pg_catalog, information_schema) ORDER BY pg_total_relation_size(c.oid) DESC;解释一下关键条件c.relkind r 表示普通表排除索引、序列、视图等schema 过滤是为了不显示 PostgreSQL 自带的系统表。执行结果里total_size 是“表本身 索引 TOAST”这通常才是真实磁盘上占用的空间。TOAST 是 PostgreSQL 处理大字段比如 text、bytea的辅助存储机制一张表有很多大字段时TOAST 体积可能远超主表本身不看 total_size 你根本猜不到空间去哪了。3.3 注意事务膨胀与统计表的差异PostgreSQL 还有一个比较特殊的问题因为 MVCC 机制表在频繁更新、删除后会产生大量死元组导致表膨胀。你可能看到 pg_total_relation_size 很大但实际有效数据很少这就是典型的膨胀。解决方法通常要执行 VACUUM FULL这个操作会重建表并回收空间但它会锁表在线业务需要谨慎安排时间窗口。平时维护可以定期执行 VACUUM ANALYZE它不会锁表但也不能完全回收空间只能更新统计信息和清理旧元组。PostgreSQL 的统计信息视图 pg_stat_user_tables 里还包含 n_live_tup、n_dead_tup 等字段可以用来辅助判断表是否严重膨胀。4. Oracle 与国产数据库段segment思维和系统视图4.1 Oracle 的 dba_segments 与 user_segments切换到 Oracle你会发现概念完全不一样了。Oracle 把数据库对象占用的物理空间叫作“段segment”一个表如果建了索引那至少有两个段表段和索引段。查表大小就是查段的大小。普通用户没有 DBA 权限时可以查 user_segments它会返回当前用户自己拥有的段DBA 用户或授权用户可查 dba_segments能看到所有 schema 的对象。常用查询如下SELECT segment_name, segment_type, ROUND(bytes / 1024 / 1024, 2) AS size_mb FROM user_segments WHERE segment_type TABLE ORDER BY bytes DESC;如果你还想看表和索引一起的大小可以去掉 WHERE segment_type TABLE 限制直接按 segment_name 聚合。Oracle 里还有一种常见需求就是查表的行数和大小一起展示。需要有统计信息SELECT t.table_name, t.num_rows, ROUND(s.bytes / 1024 / 1024, 2) AS size_mb FROM user_tables t LEFT JOIN user_segments s ON s.segment_name t.table_name AND s.segment_type TABLE ORDER BY s.bytes DESC;这里字段 num_rows 是统计信息里的行数不是实时值精确行数需要执行 DBMS_STATS.GATHER_TABLE_STATS 刷新。4.2 达梦、人大金仓的差异与踩坑记录做国产化改造时达梦DM和人大金仓KingbaseES也是高频出现的目标数据库。这两类数据库的兼容策略不同查看表大小的方式也有差异。达梦数据库整体语法与 Oracle 高度相似尤其是数据库结构层面。很多 Oracle 管理语句在达梦里几乎可以直接跑。比如查当前用户下表大小SELECT segment_name, segment_type, ROUND(bytes / 1024 / 1024, 2) AS size_mb FROM user_segments WHERE segment_type TABLE ORDER BY bytes DESC;如果遇到没有 user_segments 视图的版本也可以查 all_segments 或 dba_segments反正在达梦里能看到“段”字样的视图基本就是查这个。需要注意不同版本、不同模式Oracle 兼容模式/MySQL 兼容模式下的系统视图会有些差异我建议首次连接后先跑一条 SELECT * FROM ALL_SEGMENTS WHERE ROWNUM 10 看看能读出什么字段再改写成符合需求的 SQL。人大金仓 KingbaseES 是基于 PostgreSQL 内核开发的所以大部分 PostgreSQL 函数都能直接用比如前面提到的 pg_total_relation_size。我在实际项目里用类似下面的语句查过表大小SELECT schemaname, tablename, pg_size_pretty(pg_total_relation_size(schemaname || . || tablename)) AS total_size FROM pg_tables WHERE schemaname NOT IN (pg_catalog, information_schema) ORDER BY pg_total_relation_size(schemaname || . || tablename) DESC;不过还是要提醒一句金仓版本众多不同版本的兼容层细节会有差异。如果你对国产数据库不熟悉建议把这套查询放到一套测试库上先跑一遍确认输出没问题再上生产环境。遇到“视图或函数不存在”的报错先别慌通常只是用户权限不足或视图名不同换一个等价视图往往就通了。5. SQL Server系统视图和存储过程5.1 sp_spaceused 和 sys.tables 的联合使用SQL Server 里最简单的单表大小查看方法是存储过程 sp_spaceused。直接传表名进去EXEC sp_spaceused dbo.your_table;返回结果会包含行数、保留空间reserved、数据空间data、索引大小index_size和未使用空间unused。这个方式最快但一次只能看一张表。要一次看全库所有表就要查询系统视图了。常用到 sys.tables、sys.indexes、sys.dm_db_partition_stats、sys.allocation_units 这几个对象。sys.dm_db_partition_stats 返回每个分区的行数、预留页数等配合 sys.allocation_units 可以算出实际使用空间。下面是一条我在 SQL Server 2008 到 2019 都验证过的查询SELECT t.name AS table_name, p.rows AS row_count, SUM(a.total_pages) * 8 / 1024 AS total_size_mb, SUM(a.used_pages) * 8 / 1024 AS used_size_mb, (SUM(a.total_pages) - SUM(a.used_pages)) * 8 / 1024 AS unused_size_mb FROM sys.tables t JOIN sys.indexes i ON t.object_id i.object_id JOIN sys.partitions p ON i.object_id p.object_id AND i.index_id p.index_id JOIN sys.allocation_units a ON p.partition_id a.container_id WHERE t.is_ms_shipped 0 GROUP BY t.name, p.rows ORDER BY total_size_mb DESC;这里的关键是total_pages 是“页”的数量SQL Server 每页是 8KB所以乘以 8 得到 KB再除以 1024 得到 MB。注意索引也以 index_id 区分如果只想统计堆表或聚集索引可以根据 index_id 过滤但日常场景直接聚合更好。5.2 快速得到所有表大小报表如果你用的是 SQL Server Management StudioSSMS其实有内置报表功能。右键数据库名 → 报表 → 标准报表 → “按表分区的磁盘使用情况”就能直接看到所有表的行数、数据空间、索引空间和总空间。不过我在实际环境里更偏爱上一条 SQL 查询因为可以随时导出、过滤、排序列还能在自动巡检脚本里用。SQL Server 的统计信息可能也存在滞后。如果感觉大小和实际不符可执行DBCC UPDATEUSAGE(0);这个命令会更新系统目录中的页面计数和行数信息让查询更准确。注意执行时可能对数据库造成一定开销建议在业务低峰期执行。6. SQLite 和 ClickHouse不一样思路的数据库6.1 SQLite单文件数据库怎么算大小SQLite 是嵌入式数据库整个库通常就是一个文件。所以最朴素的查表大小方法是在操作系统层面执行 ls -l直接看数据库文件大小ls -lh /path/to/your_database.db但这只是整体文件大小。如果需要知道内部哪张表占了多少空间SQLite 也提供了 dbstat 虚拟表接口需要 SQLite 编译时开启了 SQLITE_ENABLE_DBSTAT_VTAB 选项。可以这样查SELECT name AS table_name, SUM(pgsize) / 1024.0 AS size_kb FROM dbstat GROUP BY name ORDER BY size_kb DESC;dbstat 里 pgsize 表示每个 B-tree 页占用的字节数聚合后就能得到每个表包括索引的大小。要注意SQLite 的表通常以 B-tree 组织索引也在这个输出里。如果没有 dbstat 虚拟表那就退而求其次用 PRAGMA page_count 和 page_size 计算总体大小最多只能看到整个库的大小PRAGMA page_count; PRAGMA page_size;两者相乘就是当前数据库文件的理论大小单位是字节。因为 SQLite 会预分配页面这个值可能和实际文件大小有细微差别。6.2 ClickHouse按分区查大小其实更实用ClickHouse 是列式分析数据库很多人在做日志或指标分析时用它。“表大小”这个概念在 ClickHouse 里通常要看系统表 system.parts它记录每一部分part的数据量。SELECT table, formatReadableSize(sum(bytes_on_disk)) AS total_size FROM system.parts WHERE active GROUP BY table ORDER BY sum(bytes_on_disk) DESC;说明一下active 条件用于过滤掉已经合并但还没清理的旧分区数据。ClickHouse 后台会自动合并数据分区只查询 active 分片能反映业务上正在使用的数据大小避免重复计数。更进一步可以按分区查看大小用来定位分区数据倾斜或者做冷热数据评估SELECT table, partition_id, formatReadableSize(sum(bytes_on_disk)) AS partition_size, count() AS part_count FROM system.parts WHERE active AND database your_db GROUP BY table, partition_id ORDER BY sum(bytes_on_disk) DESC LIMIT 20;ClickHouse 的压缩率通常非常高bytes_on_disk 是磁盘真实占用而不是原始数据大小。7. 用工具偷懒DBeaver、Navicat 与命令行7.1 DBeaver 的表属性面板怎么用DBeaver 是最主流的多数据库客户端之一支持的数据库非常多日常开发中配合 MySQL、PostgreSQL、达梦、金仓都是不错的组合。在数据库导航树里找到某张表右键选择“查看表信息”或“属性”DBeaver 会显示表的 DDL、行数、存储信息等。但在不同数据库上DBeaver 对表大小的展示支持不太一样。比如 PostgreSQL 一般能看到比较完整的大小信息MySQL 也能看到简单的统计而 Oracle 可能只能看到段信息。如果 DBeaver 的界面没有直接显示大小我的经验是直接在 SQL 终端里执行对应的查询语句然后把结果保存为 DBeaver 的“查询”书签下次需要时一键打开比翻面板快很多。7.2 各数据库命令行查看方式速查命令行永远是最后兜底的手段尤其在服务器上没法开 GUI 客户端时。MySQL 可以用SHOW TABLE STATUS FROM your_database;这个命令直接输出表行数、数据长度、索引长度等字段和查询 information_schema 本质上是一回事但写法更简洁。PostgreSQL 在 psql 终端里可以用\dt 表名这条元命令会显示表大小、描述等信息类似地 \l 显示所有数据库大小。注意 \dt 显示的大小只包含表本身的存储不包含索引和 TOAST需要看总体大小还是要用 SQL 查询。SQL Server 用 SQLCMD 时直接执行第 5 节里的 SQL 即可。Oracle 在 SQL*Plus 里执行 user_segments 的 SELECT 也没问题。8. 常见问题排查与经验总结8.1 统计值不准确时的处理方案这一节我放在最后是因为它其实是实践中最重要的内容不管用哪种数据库查出来的表大小都可能是“不精确”的。MySQL 的 information_schema 中行数是估算值建议 ANALYZE TABLE 刷新统计信息PostgreSQL 的表大小实时性较好但膨胀会导致统计值与物理空间差距大建议定期 VACUUM ANALYZEOracle 的段大小反映的是已分配空间可能存在高水位线问题需要通过 shrink space 或 move 释放物理空间SQL Server 建议先用 DBCC UPDATEUSAGE(0) 修正统计再查询。所谓“高水位线”可以通俗理解为一桶水喝完但桶还是那么大水位降不下去。Oracle、PostgreSQL、MySQL 都有类似的碎片和空间复用机制。如果一张表删了大量数据文件却不见变小大概率就是这个问题。8.2 权限不足怎么看很多同学连上数据库后一查系统视图就报错说没有权限。这里给大家一个解决思路优先使用当前用户可以访问的系统视图或函数。Oracle 没有 DBA 权限就用 USER_SEGMENTS、USER_TABLES只能看自己的对象MySQL 至少需要 PROCESS 权限才能查 information_schema没有就找 DBA 授权SQL Server 普通用户可能连 sys.dm_db_partition_stats 都查不到建议找 DBA 开通 VIEW DEFINITION 或者使用 SSMS 内置报表PostgreSQL 的元数据访问一般用户都能查到但持有更细粒度权限限制时也可能受限。总的原则是先确认当前用户能看到的视图范围再设计查询。权限越少能看到的对象越少这是数据库安全设计不是 Bug。8.3 计算大小和清理碎片的一些心得最后分享一点个人体会。把“查表大小”这件事做好绝不只是执行一条 SQL 那么简单。我日常工作里会做两件事一是把常用查询整理成一个脚本库比如 dbsize_mysql.sql、dbsize_pg.sql、dbsize_oracle.sql、dbsize_sqlserver.sql每个文件里放对应数据库的查表大小 SQL并写好注释。新环境、新项目直接用省时省力。二是在做表空间优化时不要随便执行 OPTIMIZE TABLE、VACUUM FULL、SHRINK SPACE 这类重量级操作。它们都可能造成锁表或严重 IO 压力。最好先评估业务允许的停机窗口再选择合适的清理策略。我遇到过最典型的案例是一个 MySQL 的日志表已经膨胀到 40GB实际有效数据只有 500MB。用 OPTIMIZE TABLE 重建后空间立刻释放整个过程花了不到三分钟但期间表被锁定对线上写入有一定影响。后来我们改成夜间自动切换日志表 定期归档旧数据的方式就把这类问题彻底规避了。另一个经验是查表格大小别只看表本身一定要把索引、TOAST、LOB 段、分区等关联对象算进去。MySQL 里看 DATA_LENGTH INDEX_LENGTHOracle 里看段类型包含 TABLE 和 INDEXPostgreSQL 里用 pg_total_relation_sizeSQL Server 里把 reserved 字段当作参考这些都是我在实战中踩过的坑总结出来的。表格大小查询是个“小功能”但它牵扯到数据库的存储引擎、统计信息、系统视图权限、碎片回收机制等一系列底层设计。希望这篇整理能帮你建立一套“换什么库都能快速上手”的思路——只要找到元数据视图再注意统计信息和权限边界这个需求就永远难不倒你。
