最稳、最通用的方式是查INFORMATION_SCHEMA.TABLES，因其不依赖当前数据库上下文、可显式指定TABLE_SCHEMA和TABLE_NAME、支持嵌入变量与条件判断，而SHOW TABLES LIKE受限于USE状态、无法直接用于逻辑分支且存在版本兼容与性能问题。
直接查 information_schema.TABLES 是最稳、最通用的方式，别用 SHOW TABLES LIKE 做自动化判断。
为什么优先用 information_schema.TABLES 而不是 SHOW TABLES
SHOW TABLES LIKE 'xxx' 看起来简单，但它有硬伤：
- 只作用于当前
USE的数据库，没显式指定库名时容易跨库误判 - 返回的是结果集，没法直接塞进变量或条件分支里（比如存储过程中不能写
IF EXISTS (SHOW TABLES...)） - 在 MySQL 5.7 及更早版本中，频繁调用会触发临时表创建，高并发下可能吃光内存
- 不带
WHERE条件的SHOW TABLES还会扫描整个库目录，IO 开销比查视图大
SELECT COUNT(*) 查询必须带 TABLE_SCHEMA 和 TABLE_NAME
只查 TABLE_NAME 不够，同名表可能存在于多个库。漏掉 TABLE_SCHEMA 就等于没限定范围：
- 正确写法：
SELECT COUNT(*) FROM information_schema.TABLES WHERE table_schema = 'mydb' AND table_name = 'users'; - 错误写法：
SELECT COUNT(*) FROM information_schema.TABLES WHERE table_name = 'users';（可能命中其他库的users） - 大小写敏感：Linux 下默认区分大小写，
'MyDB'和'mydb'是两个库，务必和实际库名完全一致 - 权限注意：账号需有对
information_schema的SELECT权限；某些托管环境会禁用该权限，此时只能退回到异常捕获方案
在存储过程或动态 SQL 中安全取值
MySQL 不允许在 IF 语句里直接嵌套查询，得先存变量再判断：
- 用
SELECT ... INTO @var把结果抓出来：SELECT COUNT(*) INTO @exists FROM information_schema.TABLES WHERE table_schema = 'mydb' AND table_name = 'users'; - 之后才能用：
IF @exists > 0 THEN ... END IF; - 避免用
SELECT 1 LIMIT 1——空结果集不会给变量赋值，变量保持旧值或NULL，逻辑容易出错 - 推荐统一用
COUNT(*) > 0 AS exists_flag返回布尔语义，更直观
MySQL 8.0+ 的性能差异要留意
MySQL 8.0 把 information_schema.TABLES 改成了基于数据字典的视图，不再扫 FRM 文件，查询快且稳定。但仍有两点容易被忽略：
- 即使在 8.0，
INFORMATION_SCHEMA视图仍走优化器，如果没加WHERE条件，还是会全量扫描底层字典表 -
TABLES视图里table_rows字段在 InnoDB 中是估算值，不能用来判断“表是否为空”，只能用于“是否存在” - 不要依赖
SHOW CREATE TABLE或DESCRIBE判断存在性——它们是语句，不是可计算的数据源，解析成本高且不可靠
真正难的不是写对一行 SQL，而是在多库共存、权限受限、版本混杂的生产环境里，让同一段判断逻辑在所有场景下都返回确定结果。字段名拼错、库名大小写、变量未初始化——这些地方一漏，后面所有分支都可能走偏。
