查表元数据需按数据库选用专用视图：MySQL用INFORMATION_SCHEMA.TABLES并加TABLE_SCHEMA过滤；PostgreSQL组合pg_tables、pg_class等系统表；SQL Server用sys.tables联sys.schemas；跨库无通用SQL，须分库实现。
查 MySQL 表元数据：用 INFORMATION_SCHEMA.TABLES
MySQL 中最直接的方式是查 INFORMATION_SCHEMA.TABLES 视图，它默认包含当前实例所有数据库的表名、类型、引擎、行数估算等基础元数据。
常见错误是漏写 TABLE_SCHEMA 条件，导致查出其他库的表干扰结果。实际使用时几乎总要加 WHERE TABLE_SCHEMA = 'your_db_name'。
- 行数（
TABLE_ROWS）是估算值，MyISAM准确，InnoDB可能偏差较大，不能用于精确计数 -
TABLE_TYPE值为'BASE TABLE'才是真实表，'VIEW'是视图，需按需过滤 - 想看建表语句？得换用
SHOW CREATE TABLE或查INFORMATION_SCHEMA.TABLES的CREATE_OPTIONS字段（仅含部分选项）
查 PostgreSQL 表元数据：从 pg_tables 和 pg_class 入手
PostgreSQL 没有统一的“元数据表”视图，pg_tables 最接近常用需求，但只覆盖普通表（不含分区表、物化视图），且不提供字段数、索引数等细节。
真正灵活的查法是组合系统表：pg_class 存表/索引/序列等对象，pg_namespace 管理 schema，pg_stat_user_tables 提供统计信息（如最后 vacuum 时间）。
- 注意
pg_tables.schemaname默认只显示public和用户自定义 schema，pg_catalog和information_schema不在其中 -
pg_class.reltuples是行数估算，和 MySQL 类似，需配合VACUUM ANALYZE更新 - 如果需要字段详情（列名、类型、是否为空），必须联查
pg_attribute，且要过滤掉系统列（attnum > 0）
SQL Server 查表元数据：优先用 sys.tables + sys.schemas
SQL Server 的系统视图命名清晰，sys.tables 对应所有用户表，sys.views 对应视图，sys.schemas 管理 schema 归属。三者联查就能拿到完整表级元数据。
容易踩的坑是忽略 sys.tables.type_desc 字段——它区分 'USER_TABLE'、'SYSTEM_TABLE'、'INTERNAL_TABLE'，不加过滤可能混入系统内部表。
-
create_date和modify_date记录的是 DDL 修改时间，不是数据变更时间 - 表大小（页数、行数）不在
sys.tables中，需联查sys.dm_db_partition_stats，且要注意index_id IN (0,1)才代表堆或聚集索引的主数据 - 权限检查：非
db_owner用户可能看不到某些表，即使有 SELECT 权限，系统视图也可能返回空行
跨数据库兼容性差，别硬写“通用 SQL”
没有一种 SQL 能在 MySQL、PostgreSQL、SQL Server 上直接跑通查表元数据。字段名、视图名、过滤逻辑全都不一样，强行抽象只会增加维护成本和运行时错误。
如果项目需要多数据库支持，建议把元数据查询逻辑封装成各数据库专用函数或配置化 SQL 片段，而不是拼接字符串或依赖 ORM 的“自动发现”——那些抽象层往往只覆盖了最简场景，一碰到分区表、临时表、外部表就失效。
真正麻烦的不是查表名，而是后续要基于这些元数据做自动化操作（比如生成文档、校验结构一致性），这时字段类型映射、NULL 约束表达方式、默认值语法差异才是大头。
