会，但只在特定条件下：列名变更后代码仍引用旧名，导致运行时出错，如Unknown column 'old_name'或ORM KeyError；MySQL自身语法执行成功，但应用查询即崩溃。
ALTER TABLE ... CHANGE COLUMN 会触发程序报错吗
会，但只在特定条件下。不是语法执行失败，而是程序运行时出错——因为列名变了，但代码里还用着旧名字。
典型现象：Unknown column 'old_name' in 'field list' 或 ORM 报 KeyError: 'old_name'。数据库改成功了，应用一查就崩。
- 直接写 SQL 的脚本、存储过程、视图，只要引用了旧列名，立刻失效
- Django/SQLAlchemy 等 ORM 依赖模型定义，
models.py不同步更新，查询或保存时就会抛异常 - 前端传参、后端解构（如
request.json.get('old_name')）若硬编码字段名，也会静默丢数据 - MySQL 自身不报错，
ALTER TABLE t CHANGE COLUMN old_name new_name VARCHAR(32)能顺利执行
CHANGE COLUMN 和 RENAME COLUMN 有什么区别
CHANGE COLUMN 是“重命名 + 可选改类型”，RENAME COLUMN（MySQL 8.0.4+）才是纯改名。两者行为差异直接影响兼容性。
-
CHANGE COLUMN必须重复写一遍列定义：CHANGE COLUMN a b INT NOT NULL—— 即使只想改名，也得把原类型、约束全抄一遍，漏了NOT NULL或DEFAULT就会意外丢失 -
RENAME COLUMN a TO b完全不碰类型和约束，安全得多，但 MySQL 5.7 及更早版本不支持 - 如果用的是 MariaDB 或低版本 MySQL，别无选择只能用
CHANGE COLUMN，务必先SHOW CREATE TABLE备份完整定义
线上环境改列名前必须检查的三件事
不是执行完 ALTER 就完事，关键在上下游是否感知到变更。漏掉任一环，故障就在几分钟后。
- 查所有应用代码：grep -r 'old_name' ./src/，特别注意 SQL 字符串拼接、JSON key、表单 name 属性
- 查数据库侧依赖：是否有视图（
SHOW CREATE VIEW v）、触发器（SHOW TRIGGERS LIKE 't'）、存储过程（SELECT body FROM mysql.proc WHERE name = 'p'）引用该列 - 确认连接池与缓存：MyBatis 的
resultMap、Redis 里序列化的对象结构、Elasticsearch 同步任务的字段映射，都可能固化旧列名
为什么加个 IF NOT EXISTS 不行
ALTER TABLE t CHANGE COLUMN IF NOT EXISTS old_name new_name ... 是错的——MySQL 根本不支持 IF NOT EXISTS 用于 CHANGE COLUMN。
常见错误是想“防重跑”，结果语法报错：ERROR 1064 (42000): You have an error in your SQL syntax。
- MySQL 对 DDL 的条件判断非常有限，
IF NOT EXISTS只适用于CREATE TABLE、CREATE INDEX等少数语句 - 真要防重复执行，得靠外部逻辑：先
SELECT COLUMN_NAME FROM INFORMATION_SCHEMA.COLUMNS WHERE TABLE_NAME='t' AND COLUMN_NAME='old_name'查是否存在 - 或者用运维工具（如 Liquibase、Flyway）管理变更，它们自带幂等性控制
最易被忽略的一点：列名变更本身不锁表太久，但如果有长事务正在读写这张表，ALTER 会被阻塞，而阻塞期间新请求持续进来，可能引发雪崩。上线前务必确认无慢查询、无未提交事务。
