mysql存储过程中需用prepare+execute动态建表，先concat拼接含反引号的sql，再执行并释放；建表前须查information_schema判断存在性，注意权限、时区、竞态及结构一致性。
MySQL 存储过程里怎么拼接表名并执行 CREATE TABLE
MySQL 不允许在存储过程中直接用变量作为 CREATE TABLE 的表名，比如 CREATE TABLE tbl_202401 (id INT) 中的 tbl_202401 不能写成 @tbl_name。必须用预处理语句（PREPARE + EXECUTE）绕过这个限制。
常见错误现象：ERROR 1064 (42000): You have an error in your SQL syntax，往往是因为直接拼字符串后没走预处理，或者拼出来的 SQL 有空格、引号不匹配。
- 先用
CONCAT()拼出完整建表语句，注意字段定义里所有单引号要双写（''），避免 SQL 注入风险 - 用
SET @sql = CONCAT(...)赋值，再PREPARE stmt FROM @sql，最后EXECUTE stmt，别忘了DEALLOCATE PREPARE stmt - 表名建议用反引号包裹，比如
`log_20240101`，防止日期含横线或关键字冲突 - 建表语句中若含默认值（如
created_at DATETIME DEFAULT CURRENT_TIMESTAMP），确保 MySQL 版本 ≥ 5.6，否则会报错
如何让存储过程按当天日期自动判断是否需要建新表
核心逻辑是：查一下目标表是否存在，不存在就建。不能每次调用都无脑建——会报 ERROR 1050 (42S01): Table 'xxx' already exists。
使用场景：日志类业务，每天一张表，写入前检查当天表是否存在；或定时任务（如每天凌晨 1 点调用一次）。
- 用
SELECT COUNT(*) INTO @cnt FROM information_schema.tables WHERE table_schema = DATABASE() AND table_name = @target_table判断表是否存在 - 日期格式统一用
DATE_FORMAT(NOW(), '%Y%m%d')，避免时区导致跨天误差；如需按 UTC 时间分表，改用UTC_DATE()配合DATE_FORMAT(UTC_DATE(), '%Y%m%d') - 不要用
SHOW TABLES LIKE @target_table，因为变量不支持，会报语法错误 - 如果并发高（比如多进程同时写入），单纯“查+建”有竞态风险，生产环境建议加一层轻量锁（如
GET_LOCK('create_table_lock', 0)）或依赖上层调度控制调用频次
分表字段设计要注意什么，避免后续查询翻车
动态建的表结构必须和主逻辑一致，否则应用层查 log_20240101 和 log_20240102 时字段对不上，UNION ALL 就会失败。
性能影响：每张表独立 B+ 树，单表数据量小，写入快；但跨日查询需 UNION ALL 多张表，MySQL 5.7 及以前版本无法下推条件到各子表，全表扫描开销大。
- 所有分表必须严格保持字段名、类型、长度、默认值、索引一致；推荐把建表语句抽成常量字符串，在存储过程中复用
- 关键查询字段（如
user_id、status）务必加索引，否则单表快、查起来慢 - 避免在分表字段里用
TEXT或BLOB类型，InnoDB 行溢出会影响插入性能 - 如果要用分区表替代分表，注意 MySQL 分区功能对
ALTER TABLE支持有限，且 8.0 后已标记为 deprecated，不建议新项目采用
调用存储过程的时机和权限问题
存储过程本身不自动触发，必须由外部显式调用（比如应用代码、事件调度器或定时脚本）。很多人卡在这步：写了过程却没跑起来。
容易踩的坑：权限不足导致 CREATE TABLE 失败，报错 ERROR 1142 (42000): CREATE command denied to user。
- 执行存储过程的用户必须有
CREATE权限，且对当前库有CREATE ROUTINE权限（创建过程时需要），调用时还需EXECUTE权限 - 用
EVENT自动调用需开启event_scheduler = ON，并赋予EVENT权限；事件里不能直接调用存储过程里的预处理语句（某些旧版本有 bug），建议事件只做简单判断，建表仍由过程完成 - 测试时先手动执行
CALL sp_create_daily_table()，确认能建出表；再检查SHOW PROCEDURE STATUS WHERE Db = 'your_db'确认过程存在且定义正确 - 过程里别漏掉
DELIMITER $$和结尾的$$，否则 MySQL 客户端会把第一个分号就当作结束，导致语法错误
真正麻烦的不是建表本身，而是后续的查询路由、归档清理、表名生成规则一致性——这些没法靠一个存储过程兜底。尤其当业务开始按月/按用户 ID 进一步拆分时，表名逻辑会迅速变得脆弱。动手前先想清楚：这个分表策略未来半年会不会被推翻。
