最稳妥方式是用SELECT COUNT() INTO变量查information_schema.TABLES；必须指定table_schema，避免因空结果集导致逻辑异常，且COUNT()确保变量总有确定值（0或正整数）。
用 SELECT COUNT(*) INTO 判断表存在性最稳妥
在存储过程中不能直接用 SHOW TABLES LIKE 的结果做逻辑分支，因为 MySQL 不允许把 SHOW 语句的结果赋值给变量。唯一可靠的方式是查 information_schema.TABLES 并用 SELECT ... INTO 把计数存进用户变量。
常见错误是写成 SELECT 1 FROM information_schema.TABLES WHERE ... LIMIT 1，一旦没匹配到行，变量不会被赋值（保持 NULL 或旧值），后续 IF @cnt = 1 就会逻辑错乱。
- 必须用
COUNT(*)：确保无论是否存在，变量都有确定数值（0 或正整数） - 必须显式指定
table_schema：不能只靠当前库，跨库操作或存储过程被调用时库上下文可能不同 - 推荐写法：
SELECT COUNT(*) INTO @table_exists FROM information_schema.TABLES WHERE table_schema = 'my_app' AND table_name = 'user_log';
别在 IF EXISTS 里套 CREATE TABLE IF NOT EXISTS 做判断
CREATE TABLE IF NOT EXISTS 是原子 DDL 操作，不是条件判断语句。它执行完你依然不知道表“原来存不存在”，更没法据此决定下一步是 TRUNCATE 还是 ALTER。
典型误用场景：想“如果表存在就清空，不存在就建表”，却写成：
CREATE TABLE IF NOT EXISTS user_cache (id INT); TRUNCATE TABLE user_cache;
这会导致表已存在时也执行 TRUNCATE，但若表不存在，TRUNCATE 直接报错中断——根本没达到分支目的。
面向 CRM 系统的 MySQL 8 数据库模式设计。当用户需要为客户关系管理（CRM）系统设计、评审、优化或生成数据库模式时，应使用此项技能。
- 真正需要分支逻辑，必须先查元数据，再用
IF @table_exists > 0 THEN ... ELSE ... END IF -
DROP TABLE IF EXISTS同理：静默成功不等于你知道它原来有没有 - DDL 类语句无法嵌套在条件中，只能作为
IF分支内的独立语句
注意大小写、权限和 performance 影响
information_schema.TABLES 查询看似轻量，但在高并发或低权限环境下容易出问题。
-
table_name和table_schema匹配区分大小写：取决于系统变量lower_case_table_names，线上环境常为 1（强制小写），但开发机可能是 0，导致本地能跑线上失败 - 某些只读账号被禁止访问
information_schema：报错ERROR 1142 (42000): SELECT command denied to user，此时连SHOW TABLES LIKE都可能被禁用 - 在循环里反复查
information_schema（比如批量检查 50 张表）会明显拖慢执行：应一次性查出所有目标表名，用IN批量比对
替代方案：SHOW TABLES LIKE 在应用层更实用
如果你的存储过程不需要严格“分支”，只是初始化前做个轻量探活，SHOW TABLES LIKE 其实更快、更少锁竞争，且语法简单。
但它在存储过程内不可直接用于判断——MySQL 不支持 SHOW 结果集赋值。所以它的合理使用场景是应用层（如 Python/Java）：
- Python 中：
cursor.execute("SHOW TABLES LIKE %s", ("session_log",))，然后看cursor.fetchall()是否为空 - 避免在存储过程中硬编码
SHOW+PREPARE绕过限制：语法复杂、易出错、维护成本高 - 真要存过程里用，还是老实用
information_schema+INTO，这是唯一被 MySQL 官方文档隐式承认的稳定路径
真正麻烦的不是怎么写那几行 SQL，而是不同环境下的 lower_case_table_names 设置、账号权限颗粒度、以及是否意识到 IF NOT EXISTS 语句根本不返回布尔值——这些细节一漏，脚本就在生产环境静默失效。
