应先用 SHOW TABLES LIKE 和 SHOW CREATE TABLE 确认表是否存在及结构是否匹配，再决定建表或 ALTER TABLE；CREATE TABLE IF NOT EXISTS 不校验结构一致性，不能替代结构验证。
MySQL建表报 ERROR 1050 (42S01): Table 'xxx' already exists 怎么办
直接删掉旧表再建，是最常见也最危险的做法。尤其在生产环境，drop table 会清空数据、删除索引、重置自增id，还可能被其他会话正在读写——不是“能不能删”，而是“敢不敢删”。真正该做的是先确认这个表是不是真的冲突、为什么冲突、要不要保留。
SHOW CREATE TABLE 和 SHOW TABLES LIKE 必须一起用
只查 SHOW TABLES LIKE 'user_profile' 只能知道表名是否存在，但无法判断是不是同库不同引擎、是不是临时表、甚至是不是大小写敏感导致的“假存在”。SHOW CREATE TABLE 才能看到真实结构和存储引擎，是唯一能交叉验证的方式。
实操建议：
- 先执行
SHOW TABLES LIKE 'user_profile'，确认是否在当前数据库中可见 - 再执行
SHOW CREATE TABLE user_profile，看能否成功返回建表语句；如果报ERROR 1146 (42S02)，说明表名存在但不在当前库（比如在别的 schema）或权限不足 - 若使用 MySQL 8.0+ 且启用了
lower_case_table_names=0，注意User_Profile和user_profile是两个不同表，LIKE查询需严格匹配大小写
用 CREATE TABLE IF NOT EXISTS 不等于安全
它只跳过建表动作，不校验结构一致性。你用它反复执行带新字段或改类型的 SQL，不会报错，但也不会生效——表结构还是老样子，容易误以为“更新成功”。
典型陷阱：
-
CREATE TABLE IF NOT EXISTS t1 (id INT) ENGINE=InnoDB;第二次执行完全静默，哪怕你改成ENGINE=MyISAM也无反应 - 字段类型变更（如
VARCHAR(50)→VARCHAR(100)）必须用ALTER TABLE，IF NOT EXISTS帮不上忙 - 某些 ORM 或迁移工具（如 Django
makemigrations）生成的 SQL 默认不含IF NOT EXISTS，手动加时得同步检查是否真需要它
真正稳妥的建表流程：先查后建，结构优先
核心原则：不要依赖“建表失败就不管了”，而要主动判断“这个表是否满足我要的结构”。靠人工比靠错误码更可靠。
推荐步骤：
- 用
SELECT COUNT(*) FROM information_schema.COLUMNS WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 't1' AND COLUMN_NAME = 'new_field'检查字段是否存在 - 用
SELECT ENGINE, ROW_FORMAT FROM information_schema.TABLES WHERE TABLE_SCHEMA = 'your_db' AND TABLE_NAME = 't1'核对引擎与格式是否符合预期 - 如果表存在但结构不符，明确走
ALTER TABLE路径；如果完全不存在，再用CREATE TABLE - 所有 DDL 操作，务必在事务外单独执行（MySQL 的 DDL 会隐式提交），避免和前面的
INSERT或UPDATE意外交互
复杂点在于：表名冲突背后可能是 schema 切换错误、连接用户权限错配、或者测试脚本反复 source 同一份 SQL —— 这些问题不会因为加了 IF NOT EXISTS 就消失，得从执行上下文里找根子。
