MySQL存储过程中应使用SELECT COUNT(*) INTO @var FROM information_schema.TABLES WHERE table_schema='db' AND table_name='tb'判断表存在性，因其可赋值、逻辑可控、跨库安全；SHOW TABLES和CREATE TABLE IF NOT EXISTS均无法满足条件分支需求。
MySQL存储过程中查information_schema.TABLES判断表存在性
直接查 information_schema.TABLES 是 MySQL 存储过程里最通用、权限要求最低的判断方式，比 SHOW TABLES LIKE 更适合做条件分支依据——因为后者无法直接赋值给变量，而前者能用 SELECT ... INTO 拿到确定数值。
- 必须显式指定
table_schema，不能依赖当前 session 的 database 上下文；写成DATABASE()看似方便，但跨库调用时会失效 -
table_name区分大小写：Linux 环境下默认严格匹配建表时的大小写，Windows 下可能不敏感，别靠测试环境猜行为 - 避免用
SELECT 1 FROM ... LIMIT 1判断——空结果集会导致INTO变量未被赋值，后续IF @exists THEN可能静默跳过 - 推荐始终用
COUNT(*) INTO @var，这样@var一定有值（0 或正整数），逻辑更可控
为什么不用SHOW TABLES LIKE在存储过程中做判断
SHOW TABLES LIKE 'xxx' 执行快、不锁元数据，但它在存储过程里没法直接参与流程控制。MySQL 不允许把 SHOW 的结果集用 INTO 赋值，也没法在 IF 条件里直接用它返回行数。
- 想绕过只能用预处理语句 + 临时表或游标，代码冗长且易出错
- 某些 MySQL 版本（如 5.7 早期）对
SHOW在存储过程中的上下文支持不稳定 - 如果只是手动检查或应用层调用（比如 PHP 用
mysqli->num_rows），它很合适；但进存储过程就得切回information_schema
CREATE TABLE IF NOT EXISTS不能替代存在性判断
CREATE TABLE IF NOT EXISTS 是原子 DDL，只控制是否报错，不返回任何状态值。你在存储过程里执行它，完事了还是不知道表原来存不存在，后续逻辑（比如要不要 INSERT 初始化数据）就断掉了。
- 它不改变任何用户变量，也不能用在
IF EXISTS(...)这类语法里 - 字段结构不一致时也不校验，比如已有表是
id BIGINT，你用IF NOT EXISTS建一个id INT的同名表，会直接报错 - 真正需要“先判断、再分支”的场景（例如：存在则
TRUNCATE，不存在则CREATE），必须靠查询结果驱动
跨数据库判断时table_schema不能硬编码DATABASE()
如果你的存储过程要操作多个库（比如从 log_db 同步结构到 main_db），DATABASE() 返回的是当前连接默认库，不是目标库名，会导致永远查不到表。
- 正确做法是把目标库名作为
IN参数传入，或用SET @target_db = 'log_db'显式声明 - 然后在查询中写
WHERE table_schema = @target_db AND table_name = 'event_log' - 别试图用
USE log_db切换上下文来“骗过”information_schema——它是全局视图，不受USE影响
真正容易被忽略的是权限和大小写一致性：有些生产环境禁用了 information_schema 查询权限，或者 lower_case_table_names 设置不统一，导致本地测试通过、上线就查不到。写之前先确认目标环境的实际配置。
