MySQL表结构变更卡住主因是锁表或隐式事务阻塞，需查PROCESSLIST、确认autocommit状态，并注意工具特性（如phpMyAdmin需手动点底部执行按钮）及INSTANT算法限制。
MySQL 表结构变更卡在“勾选后不执行”
多数情况不是工具没反应，而是 alter table 被锁表或隐式事务阻塞了。特别是用 phpmyadmin、dbeaver 或 navicat 勾选字段修改却点不动「执行」按钮，大概率是当前连接处于未提交事务中，或者目标表正被长查询占用。
- 先执行
SHOW PROCESSLIST;，找State为Sending data、Copying to tmp table或长时间Locked的线程，用KILL [id];干掉 - 确认没有开启自动提交：运行
SELECT @@autocommit;，返回0就手动加个COMMIT;或设成SET autocommit = 1; - phpMyAdmin 中勾选操作后，实际生成的是预览 SQL，得下拉到底部点「执行」——这个按钮常被滚动遮挡，不是没功能
ALTER TABLE 修改字段时报错 “ALGORITHM=INSTANT not supported”
MySQL 8.0.12+ 支持 INSTANT 算法，但仅限加列、删列、重命名列等极少数操作；一旦涉及 MODIFY COLUMN 或改默认值，就会退化到 COPY 模式，大表直接卡死。
- 查当前支持 INSTANT 的操作：
SELECT * FROM information_schema.INNODB_TABLES WHERE NAME LIKE '%your_table%';结合ALTER TABLE ... ALGORITHM=INSTANT;显式指定（失败会立刻报错，不盲等） - 改字段类型必须用
CHANGE COLUMN或MODIFY COLUMN，但会触发重建：500 万行以上建议走 pt-online-schema-change，别硬扛 - Navicat 勾选「允许外键检查」或「启用安全更新」时，可能静默禁用某些 ALTER，关掉再试
使用 pt-online-schema-change 执行后表没更新
常见假象：原表看起来没变，其实是工具创建了新表 _xxx_new，正在拷数据或等剪切时机。它不会动原表，直到最后原子性 rename。
- 执行时加
--dry-run和--print先看它打算建什么表、挂哪些触发器 - 观察
information_schema.PROCESSLIST，应有多个pt-osc相关连接；若只有 1 个且长时间不动，大概率是主从延迟或触发器冲突 - 别手动删
_xxx_new或_xxx_old：前者删了同步中断，后者删了 rollback 失败，工具会报Table xxx_old does not exist - 执行完一定要检查
RENAME TABLE是否成功——这是唯一真正生效的一步，前面全是铺垫
SQL Server Management Studio 中“生成更改脚本”空白或报错
SSMS 的「编辑前 200 行」界面点「保存」会自动生成脚本，但若表含计算列、索引视图依赖、或开启了变更数据捕获（CDC），就直接禁用该功能。
- 右键表 →「设计」→ 改完字段后，SSMS 底部状态栏若显示「无法生成更改脚本」，说明存在不可自动处理的依赖
- 手动写
ALTER TABLE更可靠：比如改长度，必须用ALTER COLUMN varchar(255)，不能只写varchar - 勾选「阻止保存要求重新创建表的更改」后，哪怕只是加个
NOT NULL，也会拒绝保存——这时得关掉选项，或用INSERT INTO new_table SELECT ...手动迁移
真正难的从来不是点哪个勾、选哪个框，而是搞清你手里的表此刻正被谁读着、有没有隐藏约束、以及那个「执行」按钮背后到底在跑哪条 SQL。看日志、查 processlist、关掉所有自动保护开关，比反复点刷新有用得多。
