最快判断表是否存在应使用 SHOW TABLES LIKE 'table_name'，它轻量、精准、不触发锁且比查询 information_schema.tables 更快。
直接用 SHOW TABLES LIKE 最快，不用建表语句干扰判断
MySQL 没有标准 SQL 的 IF NOT EXISTS 表存在性检查语法（那只是建表/删表时的可选修饰），真想“快速判断”，就得绕开 DDL 语句本身。最轻量、最准、最不触发锁的方式是查 information_schema.tables 或用 SHOW TABLES LIKE —— 后者在绝大多数场景下更快，因为不走全表扫描，且能利用内部缓存。
-
SHOW TABLES LIKE 'user_profile'返回一行就存在，空结果集就不存在；注意单引号必须，通配符支持%和_ - 别用
SELECT COUNT(*) FROM information_schema.tables WHERE table_name = 'xxx' AND table_schema = DATABASE()：慢，且在高并发下可能被information_schema元数据锁拖累 - 如果跨库判断，把
DATABASE()换成具体库名字符串，比如'my_app'，但记得加单引号
DROP TABLE IF EXISTS 和 CREATE TABLE IF NOT EXISTS 不是判断逻辑，是原子操作
这两个语句里的 IF NOT EXISTS 是 MySQL 自己的语法糖，仅控制是否报错，并不返回“存在与否”的布尔值。它们适合脚本初始化，但不适合做条件分支依据 —— 因为你没法在同一个语句里“先判断再决定后续流程”。
-
DROP TABLE IF EXISTS user_log：表不存在也不报错，但执行完你还是不知道它原来存不存在 -
CREATE TABLE IF NOT EXISTS config (k VARCHAR(32), v TEXT)：如果表已存在，该语句静默跳过，但不会告诉你字段是否一致、索引是否缺失 - 误以为用了
IF NOT EXISTS就等于做了存在性校验，容易导致后续逻辑（比如 ALTER）失败却没兜底
在存储过程或应用层做条件分支，得靠查询结果驱动
真正需要“判断后分支”的场景（比如：存在则清空，不存在则建表），必须把存在性查询的结果取出来，再写 IF 或应用层 if。MySQL 存储过程里不能直接用 SHOW 结果赋值，得换种方式。
- 推荐用
SELECT COUNT(*) INTO @cnt FROM information_schema.tables WHERE table_schema = DATABASE() AND table_name = 'tmp_report'，然后IF @cnt > 0 THEN ... - 应用层（如 Python）更简单：
cursor.execute("SHOW TABLES LIKE %s", ("order_history",))，看cursor.fetchall()是否为空 - 别在循环里反复执行存在性检查 —— 比如批量建 50 张表前逐个
SHOW TABLES LIKE，性能会明显下降；应先查一次所有目标表名，一次性比对
大小写和引号陷阱：Linux 下表名默认区分大小写
MySQL 在 Linux 上默认按文件系统大小写敏感处理表名，SHOW TABLES LIKE 'User' 和 SHOW TABLES LIKE 'user' 可能一个返回一行、一个空——尤其当开发环境是 macOS（不区分）、生产是 Linux（区分）时，这个差异极易漏测。
- 统一用小写表名，建表语句里也小写，避免隐式转换带来的不一致
- 不要依赖反引号包裹来“修复”大小写问题：
SHOW TABLES LIKE `User`在 Linux 上依然查不到小写文件名的表 - 如果必须兼容，可在连接时加
lower_case_table_names=1，但这是启动参数，改了要重启 MySQL，且影响已有数据
CREATE TABLE IF NOT EXISTS 能保平安，但它完全不管结构变更。表存在但字段少两个、类型不对、索引缺了——它一声不吭，后面 INSERT 或 SELECT 就崩。真要健壮，得单独校验结构，不是只看“表在不在”。 
