MySQL存储过程中需用CONCAT拼接含动态表名的INSERT INTO ... SELECT语句，赋值给用户变量@sql后通过PREPARE/EXECUTE执行；日期条件须用?占位符配合EXECUTE ... USING传参；归档前应校验目标表存在性并按源表结构创建；删除操作须与归档使用同一时间戳条件并在事务中完成。
MySQL存储过程中怎么拼接动态表名并执行INSERT INTO ... SELECT？
不能直接把表名写死在SQL里，得用预处理语句（PREPARE + EXECUTE）。否则会报错：ERROR 1146 (42S02): Table 'db.xxx_202401' doesn't exist——不是表真不存在，而是存储过程编译时就校验了静态表名，而你传入的是变量。
关键点：表名不能出现在INSERT INTO后面的标识符位置，必须通过字符串拼接+预处理绕过语法检查。
- 用
CONCAT()拼出完整SQL字符串，比如CONCAT('INSERT INTO ', archive_table_name, ' SELECT * FROM ', source_table_name, ' WHERE ...') - 必须用
SET @sql = ...赋值给用户变量，再PREPARE stmt FROM @sql，最后EXECUTE stmt - 别忘了
DEALLOCATE PREPARE stmt，否则下次调用会报ERROR 1243 (HY000): Unknown prepared statement handler
分表归档时WHERE条件里的日期字段怎么安全传参？
日期范围不能拼进SQL字符串，否则有SQL注入风险，也容易因格式不一致导致查询结果为空。比如DATE(created_at) < '2024-01-01'这种写法在拼接时容易漏引号或时区偏差。
正确做法是：日期参数走EXECUTE ... USING占位符，只让表名动态、数据条件参数化。
- 拼SQL时用
?代替日期条件值，例如CONCAT('INSERT INTO ', archive_table_name, ' SELECT * FROM ', source_table_name, ' WHERE created_at < ?') -
EXECUTE stmt USING @archive_before_date，其中@archive_before_date是DATE或DATETIME类型变量 - 确保
@archive_before_date已用STR_TO_DATE()或CAST()转成标准类型，避免隐式转换失败
如何判断目标归档表是否存在，不存在时自动建表？
靠CREATE TABLE IF NOT EXISTS不够——它不会校验结构是否一致。如果历史表字段顺序、类型、索引不同，后续INSERT可能失败或丢数据。
稳妥做法是先查information_schema.TABLES确认存在性，再比对COLUMNS，但实际中更常用“建表模板+REPLACE”逻辑。
- 用
SELECT COUNT(*) INTO table_exists FROM information_schema.TABLES WHERE TABLE_SCHEMA = DATABASE() AND TABLE_NAME = archive_table_name - 如果不存在，从源表
SHOW CREATE TABLE结果中提取建表语句，用REPLACE改表名，再SET @create_sql = ...+ 预处理执行 - 注意：
SHOW CREATE TABLE返回的语句含AUTO_INCREMENT和ENGINE等细节，直接复用最保险；别手写建表语句，容易漏COMMENT或COLLATION
归档后删除原表数据，为什么加LIMIT反而更危险？
加LIMIT看似防误删，但在高并发下可能造成重复归档或漏删——因为SELECT和DELETE不是原子操作，中间可能有新数据写入。
真正安全的做法是用事务+时间戳锚点，而不是依赖行数限制。
- 归档前先查出本次要处理的最大
created_at值，存入变量@max_time_to_archive - 归档SQL用
WHERE created_at <= @max_time_to_archive，确保范围明确 - 删除也用同一条件：
DELETE FROM source_table_name WHERE created_at <= @max_time_to_archive，并在同一事务中执行 - 别用
DELETE ... LIMIT，除非你能接受“删了一部分、剩下没删、下次又归一次”的脏数据循环
动态表名+参数化条件+事务边界，这三块没对齐，归档逻辑就只是个半成品。尤其是跨月归档时，@max_time_to_archive的精度（秒级还是天级）和时区设置，很容易被忽略。
