MySQL存储过程中动态拼接UPDATE语句必须用CONCAT()拼接字符串并用PREPARE+EXECUTE执行，表名等标识符须反引号包裹、白名单校验且不可参数化，参数值须通过USING绑定或严格过滤转义，严禁字符串拼接。
存储过程里怎么动态拼接UPDATE语句
核心就一条：用CONCAT()拼字符串，再用PREPARE + EXECUTE执行。不能直接写UPDATE ... WHERE table_name = ?——表名不支持参数化，必须硬编码进SQL字符串里。
常见错误现象：ERROR 1064（语法错误）或ERROR 1146（表不存在），往往是因为拼接时漏了反引号、空格或分号；或者table_name字段里混入了非法字符（比如横线、点号），没做转义。
- 表名含特殊字符（如
user-log、order_detail_v2）必须用反引号包裹：`user-log` - 拼接前先校验表是否存在，避免运行时报错中断流程：
SELECT COUNT(*) FROM information_schema.tables WHERE table_schema = 'your_db' AND table_name = ? - UPDATE语句末尾要加分号，但
EXECUTE不认分号，所以分号只保留在CONCAT()生成的字符串里，别加在PREPARE之前
如何安全地遍历所有含指定字段的业务表
不能靠人工列一张表清单——容易漏、难维护。要用information_schema.columns查元数据，聚焦真实业务约束：字段名匹配 + 表归属库正确 + 字段类型合理（比如只更新VARCHAR类姓名字段，跳过INT主键）。
使用场景：用户姓名变更后，同步更新几十张表里的create_user_name和update_user_name字段。
- WHERE条件必须同时检查：
table_schema（库名）、column_name IN ('create_user_name', 'update_user_name')、data_type = 'varchar' - 用
GROUP BY table_name HAVING COUNT(DISTINCT column_name) = 2确保该表两个字段都存在，避免只更新一半 - 不要用
SELECT *查information_schema，只取table_name，减少结果集体积，加快游标遍历
动态SQL执行时怎么防止SQL注入
输入参数（如userId、newName）绝不能直接拼进字符串。必须用CONCAT()外层拼结构，参数值通过REPLACE()或变量赋值间接代入——更稳妥的是把参数全挪到WHERE子句里，用预编译占位符，但MySQL存储过程中对EXECUTE ... USING的支持有限，仅适用于SELECT/INSERT等，UPDATE动态表名场景下仍需字符串拼接。
所以实际做法是：对userId这类ID字段，强制限定为VARCHAR(255)且只允许字母数字；对newName这种文本，用REPLACE(newName, "'", "''")双单引号转义，并限制长度（如SUBSTRING(newName, 1, 50)）。
- 禁止拼接任何来自
INFORMATION_SCHEMA以外的表名、字段名、库名——这些必须白名单校验或硬编码 - 调试阶段打开
SELECT @sql;打印生成语句，肉眼核对是否有多余;、未闭合引号、意外换行 - 上线前在测试库跑一遍，用
SHOW PROCESSLIST确认没有长事务阻塞
为什么不用MERGE或批量UPDATE替代游标
因为目标表不确定——你不知道要更新哪几张表，也不知道每张表的主键字段叫什么（有的叫user_id，有的叫creator_id）。MERGE和UPDATE ... JOIN都要求表结构已知、关联条件固定，而这里是“元数据驱动”的通用同步逻辑。
性能上，游标逐行确实慢，但胜在可控：锁粒度小（每次只锁一张表的一批行）、出错可定位到具体哪张表、便于加重试或跳过策略。真要提速，只能靠缩小扫描范围（比如加AND table_name NOT LIKE 'tmp_%'排除临时表）或加索引（确保create_userId字段有索引）。
最容易被忽略的是错误处理：游标循环里没加DECLARE CONTINUE HANDLER FOR SQLEXCEPTION，一旦某张表更新失败（比如字段被删了），整个存储过程就中断，后续表全被跳过。必须给每个EXECUTE包一层异常捕获，记录日志再继续。
