MySQL存储过程不支持变量直接作为表名，因DDL语句在预编译阶段需确定结构，而变量仅运行时展开，导致语法错误1064；必须用CONCAT拼接SQL字符串，再通过PREPARE/EXECUTE动态执行，并用反引号包裹表名以防特殊字符报错。
不能直接用变量建表，必须走 PREPARE + EXECUTE；不查 information_schema 就执行会报 ERROR 1050 (42S01)；并发写入时“查是否存在→建表”有竞态风险。
为什么 CREATE TABLE tbl_@date 会报语法错误
MySQL 存储过程里不允许把变量当标识符直接拼进 DDL 语句。比如 CREATE TABLE log_20260702 中的表名部分，若写成 @tbl_name，解析器会在语法分析阶段就报 ERROR 1064 (42000)。根本原因是 DDL 语句的结构在预编译时已固化，变量只在运行时才展开，二者阶段错位。
必须用字符串拼接 + 预处理绕过：
SET @sql = CONCAT('CREATE TABLE IF NOT EXISTS `log_', DATE_FORMAT(NOW(), '%Y%m%d'), '` (id INT, ts DATETIME)');PREPARE stmt FROM @sql;EXECUTE stmt;DEALLOCATE PREPARE stmt;
注意：表名必须用反引号包裹，否则像 log-20260702 这种含横线的名称会直接语法报错；所有单引号（如默认值字符串）需双写 ''，否则 SQL 拼接失败。
如何安全判断目标表是否已存在
别用 SHOW TABLES LIKE @tbl —— 变量在 LIKE 后不生效，会报语法错误。可靠方式是查 information_schema.tables：
SELECT COUNT(*) INTO @cnt FROM information_schema.tables WHERE table_schema = DATABASE() AND table_name = @target_table;- 查完后用
IF @cnt = 0 THEN ... END IF;控制建表逻辑 - 日期格式统一用
DATE_FORMAT(NOW(), '%Y%m%d')，避免时区导致跨天误判（比如服务器设为 UTC+8，但应用按 UTC 时间写入）
如果业务要求严格按 UTC 分表，改用 DATE_FORMAT(UTC_DATE(), '%Y%m%d')，且确保所有写入客户端也统一时区。
高并发场景下怎么避免重复建表失败
两个进程同时查到表不存在，接着都执行建表，第二个必然触发 ERROR 1050。生产环境不能靠“建表失败就忽略”来兜底，得从源头控制：
- 加轻量锁：
SELECT GET_LOCK('create_table_lock', 0)返回 1 再执行建表，返回 0 则跳过；建完立刻SELECT RELEASE_LOCK('create_table_lock') - 或依赖上层调度：让定时任务（如每天凌晨 1 点的 event）统一触发，禁止业务代码实时建表
- 绝对不要在写入热点路径（如 API 入口）里调用建表逻辑，否则锁争用会拖慢整个请求链路
另外，所有分表结构必须完全一致：字段名、类型、长度、索引、默认值（CURRENT_TIMESTAMP 要求 MySQL ≥ 5.6.5），否则后续 UNION ALL 查询会因列对不上而失败。
存储过程 + 事件调度器自动触发的坑
想让系统每天自动生成新表？先确认 event_scheduler 已开启：SET GLOBAL event_scheduler = ON;（重启失效）或在 my.cnf 里配 event_scheduler = ON 并重启。
事件定义里别用 NOW() 动态算时间点，因为事件创建时就固化了 STARTS 时间：
- 错误写法：
STARTS NOW() + INTERVAL 1 DAY→ 实际只执行一次 - 正确写法：
STARTS CONCAT(YEAR(NOW()) + 1, '-01-01 00:00:00')（年度表）或用固定时间点 +EVERY 1 DAY
最后提醒：MySQL 5.7 对 PREPARE 的 SQL 字符串长度有限制（默认 1MB），如果建表语句带大量注释或复杂索引，可能触发 ERROR 1064 —— 建议删掉无用注释，用 SHOW VARIABLES LIKE 'max_allowed_packet' 确认上限。
