最可靠方式是查各数据库专用元数据视图：sql server用sys.tables+schema_id，mysql用information_schema.tables+显式库名，postgresql用pg_class与pg_namespace联查并限定relkind='r'。
SQL Server 中用 sys.tables 判断表是否存在
在 SQL Server 存储过程中，最可靠、性能也较好的方式是查 sys.tables 视图。它只返回用户创建的表（不含系统表），且查询快、权限要求低。
常见错误是直接查 sysobjects 或拼接字符串做 OBJECT_ID() 判断——前者已过时，后者在跨数据库或带 schema 的场景下容易漏判。
- 必须指定
schema_id或用双引号/括号包裹 schema 名，比如OBJECT_ID('dbo.MyTable')才准确，OBJECT_ID('MyTable')可能返回 null - 推荐写法：
IF EXISTS (SELECT 1 FROM sys.tables WHERE name = 'MyTable' AND schema_id = SCHEMA_ID('dbo')) - 如果不确定 schema，默认是
dbo，但硬编码SCHEMA_ID('dbo')比用字符串拼接更安全
MySQL 中查 information_schema.TABLES 的注意事项
MySQL 没有内置函数快速判断表存在，得走 information_schema.TABLES。但它对大小写敏感、依赖当前 database 上下文，容易踩坑。
典型现象：在存储过程中执行正常，但换个数据库 context 就查不到——因为 TABLE_SCHEMA 字段存的是表所属库名，不是当前 session 的库。
- 务必显式指定库名：
SELECT COUNT(*) FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'mydb' AND TABLE_NAME = 'mytable'
- 表名大小写要和实际建表一致（Linux 下默认区分，Windows 不区分）
- 避免用
SHOW TABLES LIKE 'mytable'：它不能在存储过程里直接用于条件判断，还得配合SELECT INTO临时变量，多一步且易出错
PostgreSQL 中用 pg_class + pg_namespace 联查
PostgreSQL 的元数据分散在多个系统表里。pg_class 存表/索引等对象，但不存 schema 名；pg_namespace 存 schema 信息，必须联查才能准确定位。
单独查 pg_class.relname = 'mytable' 可能命中同名的序列、视图甚至其他 schema 下的表。
- 标准写法：
SELECT 1 FROM pg_class c JOIN pg_namespace n ON c.relnamespace = n.oid WHERE c.relname = 'mytable' AND n.nspname = 'public'
- 注意：
relkind = 'r'可加可不加（'r'表示普通表），但加了能排除掉视图（'v'）、序列（'S'）等干扰项 - 不要用
\dt或psql元命令——它们不在 SQL 存储过程里可用
跨数据库兼容性差，别试图写“一套 SQL 走天下”
各数据库的元数据表结构、字段名、大小写规则、权限模型都不同，强行抽象一个通用函数，最终只会增加维护成本和运行时错误。
真正需要多库支持时，应该在应用层做适配，或者为每个目标数据库单独维护一套存储过程逻辑。
最容易被忽略的一点：某些环境（如 SQL Server 的 contained database、PostgreSQL 的 search_path 设置）会让 schema 解析行为发生偏移，光靠名字匹配不够，必须结合上下文显式限定。
