不能直接用存储过程批量删冗余字段，因mysql无“冗余字段”定义且drop column不支持变量占位符，须拼接带反引号的sql并加异常处理，且ddl不可回滚，需人工审核日志后执行。
不能直接用存储过程“批量删冗余字段”——MySQL没有“冗余字段”的定义，只有你认为冗余的字段。所谓“批量删”，本质是「按规则批量 DROP COLUMN」，必须先明确字段名、表范围和安全边界，否则极易误删。
怎么安全定位要删的字段？
别靠肉眼扫表，用 INFORMATION_SCHEMA.COLUMNS 精确查：
- 只查目标库：WHERE
TABLE_SCHEMA = 'your_db_name' - 限定字段名模式：比如所有叫
old_flag、backup_time或带_bak后缀的字段，用COLUMN_NAME LIKE '%_bak' - 排除系统表/中间表：加
AND TABLE_NAME NOT LIKE 'tmp_%'等条件 - 务必先 SELECT 出来核对：不要一上来就 EXECUTE
为什么不能在存储过程中直接写 DROP COLUMN 语句？
因为 DROP COLUMN 是 DDL，不支持变量占位符；必须拼 SQL 字符串 + PREPARE/EXECUTE。但这里有个关键陷阱：
-
CONCAT('ALTER TABLE ', table_name, ' DROP COLUMN ', column_name)—— 如果column_name含空格或特殊字符（如user id），会报错 - 正确做法是用反引号包裹：
CONCAT('ALTER TABLE `', table_name, '` DROP COLUMN `', column_name, '`') - 如果字段不存在，MySQL 默认报错退出（错误码 1091），需加异常处理器兜底
如何避免执行中途崩溃导致部分表被删、部分没删？
存储过程本身不支持事务回滚 DDL 操作（ALTER TABLE 会自动提交），所以「全量成功 or 全量失败」不成立。应对策略是：
- 把生成的 SQL 先写进临时表或日志表，人工 review 后再执行
- 用
DECLARE CONTINUE HANDLER FOR 1091忽略「字段不存在」错误，防止中断 - 每条
EXECUTE后加SELECT CONCAT('Done: ', table_name, '.', column_name);打印进度 - 生产环境严禁直接调用，先在测试库跑通，再导出 SQL 脚本人工审核后执行
一个可用的最小化模板（删所有表中的 is_deleted_bak 字段）
DELIMITER //
DROP PROCEDURE IF EXISTS drop_redundant_column//
CREATE PROCEDURE drop_redundant_column()
BEGIN
DECLARE done INT DEFAULT 0;
DECLARE tname VARCHAR(64);
DECLARE cname VARCHAR(64);
DECLARE cur CURSOR FOR
SELECT TABLE_NAME, COLUMN_NAME
FROM INFORMATION_SCHEMA.COLUMNS
WHERE TABLE_SCHEMA = 'your_db_name'
AND COLUMN_NAME = 'is_deleted_bak';
DECLARE CONTINUE HANDLER FOR NOT FOUND SET done = 1;
DECLARE CONTINUE HANDLER FOR 1091 BEGIN END; -- 忽略字段不存在错误
<p>OPEN cur;
read_loop: LOOP
FETCH cur INTO tname, cname;
IF done THEN LEAVE read_loop; END IF;</p><pre class="brush:php;toolbar:false;">SET @sql = CONCAT('ALTER TABLE `', tname, '` DROP COLUMN `', cname, '`');
PREPARE stmt FROM @sql;
EXECUTE stmt;
DEALLOCATE PREPARE stmt;END LOOP; CLOSE cur; END// DELIMITER ; CALL drop_redundant_column();
真正危险的不是语法，而是你没想清楚「这个字段到底是不是真的没人用了」——应用代码、历史脚本、BI 查询都可能还依赖它。删之前，grep 代码库、查慢日志、看监控 SQL 样本，比写一百行存储过程都重要。
