MySQL 外键约束阻止修改被引用列，需明确级联策略或临时禁用检查（仅当前会话），但会导致悬空引用；权限不足、配置限制或隐式类型转换亦可致操作失败或无实际变更。
phpMyAdmin 执行 UPDATE/DELETE 时提示 “Cannot change column ‘xxx’: used in a foreign key constraint”
这是外键约束在起作用，不是 phpmyadmin 的“安全提示”，而是 mysql 层面的强制限制。你改的是被其他表引用的列（比如主键或唯一键），mysql 拒绝直接修改，防止数据不一致。
真正要做的不是“取消外键检查”，而是明确是否需要级联变更，或者临时禁用约束——但必须清楚后果：
-
SET FOREIGN_KEY_CHECKS = 0只对当前会话有效，断开连接后自动恢复为 1 - 它不会绕过
UPDATE或DELETE本身的语法或权限限制，只跳过外键依赖校验 - 如果关联表里已有数据，禁用后执行
UPDATE改了主键值，那些外键字段就变成悬空引用（ORPHANED），后续查不到、JOIN 失败、甚至触发ON DELETE CASCADE意外删除
示例：你想把 users 表的 id = 5 改成 100，而 orders.user_id 正引用着它：
SET FOREIGN_KEY_CHECKS = 0;<br>UPDATE users SET id = 100 WHERE id = 5;<br>UPDATE orders SET user_id = 100 WHERE user_id = 5;<br>SET FOREIGN_KEY_CHECKS = 1;
phpMyAdmin 界面里点“执行”却没反应 / 提示“无权执行此操作”
这通常不是界面问题，而是你登录的 MySQL 用户缺少 UPDATE、DELETE 或 ALTER 权限，或者 phpMyAdmin 配置了 $cfg['AllowUserDropDatabase'] = false 类似的限制项。
检查三件事：
立即学习“PHP免费学习笔记（深入）”；
- 确认当前用户有对应表的
UPDATE权限：SHOW GRANTS FOR CURRENT_USER(); - 看 phpMyAdmin 配置文件（通常是
config.inc.php）里有没有$cfg['IgnoreMultiSubmitErrors'] = true;—— 如果是false，一条语句出错整批中断 - 某些托管环境（如 cPanel）默认禁用
SET语句，SET FOREIGN_KEY_CHECKS = 0会被直接拦截，连错误都不报，只静默失败
为什么执行完 UPDATE 后数据没变，但 phpMyAdmin 显示“受影响 1 行”
常见于 WHERE 条件匹配到记录，但 SET 部分赋的值和原值完全一样。MySQL 认为“逻辑上更新成功”，返回影响行数，实际磁盘没写。
典型场景：
-
UPDATE products SET price = 99.99 WHERE id = 123，而该行price原值就是99.99 - 字段类型隐式转换导致比较失效，比如
WHERE status = '1'匹配的是TINYINT字段，但传入字符串可能被转成0 - 使用了
utf8mb4和utf8混合 collation，WHERE 中的中文字符因排序规则不同无法匹配
验证方法：加 SELECT 先查原始值：SELECT id, price FROM products WHERE id = 123;
误操作后想回滚，但 phpMyAdmin 没提供“事务回滚”按钮
phpMyAdmin 默认所有查询都在自动提交模式（AUTOCOMMIT = 1），每条 UPDATE 或 DELETE 执行完立刻生效，无法回滚。
真要支持回滚，必须手动开启事务：
- 先执行：
START TRANSACTION; - 再执行你的
UPDATE/DELETE - 确认没问题就
COMMIT;，出错了就ROLLBACK; - 注意：不能跨多个 phpMyAdmin 的“SQL 标签页”维持事务，每个标签页是独立会话
更稳妥的做法是导出前先备份：CREATE TABLE users_backup AS SELECT * FROM users; —— 这比依赖事务更可靠，尤其面对大表或长事务锁表风险。
外键不是障碍，是护栏；绕开它不难，难的是知道哪根柱子动了会塌房。
