在SQL Server数据库的日常管理中，统计每个表的行数是运维人员和开发者经常需要处理的需求，比如评估数据增长情况、排查数据异常、优化存储方案等场景都需要用到这个数据。如果使用传统的SELECT COUNT(*)方式逐表统计，当表数据量较大时，会触发全表扫描，不仅执行速度慢，还会占用大量IO和CPU资源，影响数据库的正常服务。而通过SYS.INDEXES系统视图结合其他系统表进行聚合查询，能够快速获取所有表的行数，避免全表扫描带来的性能损耗。
SYS.INDEXES系统视图的作用
SYS.INDEXES是SQL Server内置的系统视图，存储了数据库中所有索引（包括堆表和聚集索引）的详细信息。其中rows字段记录了每个索引对应的近似行数，对于聚集索引来说，这个数值就是对应表的行数；对于堆表（没有聚集索引的表），每个分区对应的行数也会存储在该视图中。需要注意的是，这个行数是基于索引统计信息的近似值，不是实时精确计数，但对于大多数统计场景来说已经足够准确，而且获取速度远快于全表扫描。
快速统计所有表行数的实现方法
要实现统计每个表的行数，需要结合SYS.TABLES、SYS.SCHEMAS、SYS.INDEXES三个系统视图，通过关联查询获取表名和对应的行数信息。具体逻辑是：先通过SYS.TABLES获取所有用户表的信息，关联SYS.SCHEMAS获取表所属的模式名，再关联SYS.INDEXES筛选出聚集索引或者堆表的分区信息，最后对行数进行聚合。
基础查询语句
以下是完整的查询语句，能够返回所有用户表的模式名、表名和对应的行数：
SELECT
s.name AS schema_name,
t.name AS table_name,
SUM(i.rows) AS row_count
FROM
sys.tables t
INNER JOIN
sys.schemas s ON t.schema_id = s.schema_id
INNER JOIN
sys.indexes i ON t.object_id = i.object_id
INNER JOIN
sys.partitions p ON i.object_id = p.object_id AND i.index_id = p.index_id
WHERE
i.index_id IN (0, 1) -- 0代表堆表，1代表聚集索引
AND t.type = 'U' -- 筛选用户表，排除系统表
GROUP BY
s.name,
t.name
ORDER BY
row_count DESC; -- 按行数降序排列
语句逻辑说明
sys.tables：存储数据库中所有表的基本信息，type = 'U'用来过滤掉系统表，只保留用户创建的表。sys.schemas：存储所有模式的信息，通过schema_id和sys.tables关联，获取表所属的模式名，避免不同模式下同名表混淆。sys.indexes：存储索引信息，index_id = 0表示堆表（没有聚集索引的表），index_id = 1表示聚集索引，这两种情况对应的行数就是表的行数，其他非聚集索引不需要统计。sys.partitions：存储索引分区的行数信息，因为一个大表可能分为多个分区，所以需要关联该表并对rows字段求和，得到整个表的行数。
使用注意事项
虽然这种方法统计速度快，但使用时需要注意以下几点：
- 行数是近似值：SYS.INDEXES中的行数来自统计信息，不是实时精确计数。如果刚执行过大批量数据插入、删除操作，统计信息可能没有及时更新，导致行数不准确。如果需要精确计数，可以先执行
UPDATE STATISTICS 表名更新统计信息，再执行查询，或者仍然使用COUNT(*)方式，但要接受性能损耗。 - 排除系统表：查询时一定要加上
t.type = 'U'的条件，否则会把系统表的行数也统计进来，干扰结果。 - 权限要求：执行该查询的账号需要有访问系统视图的权限，一般db_owner或者sysadmin角色的成员都有这个权限，普通用户可能需要单独授权。
不同场景的选择建议
如果是日常运维、数据概览等场景，不需要精确行数，优先使用SYS.INDEXES的聚合查询方法，效率更高；如果是数据对账、数据迁移校验等需要精确行数的场景，建议对单表使用COUNT(*)查询，或者先更新统计信息再使用系统视图查询，确保结果准确。
需要注意的是，SQL Server的统计信息默认会自动更新，但当表数据变化量较小时，可能不会触发自动更新，因此如果对行数准确性要求较高，建议先手动更新统计信息再查询。
SQL_Serversys_indexes表行数统计系统视图T-SQL修改时间：2026-06-30 20:24:34