phpMyAdmin执行ALTER TABLE必然超时，因其本质是PHP脚本，受max_execution_time、$cfg['ExecTimeLimit']（默认300秒且优先级更高）和MySQL wait_timeout三重限制；亿级表ALTER需数小时，而界面早断连、状态不可知，且不支持事务、进度反馈或增量同步，真正应使用命令行或pt-online-schema-change替代。
phpmyadmin 执行 alter table 必然超时，不是配置能救的——它根本不适合干这事。
为什么改字段在 phpMyAdmin 里一定会卡住
phpMyAdmin 是 PHP 脚本，所有 SQL 都走 mysqli_query()，受三重限制：PHP 的 max_execution_time、phpMyAdmin 自带的 $cfg['ExecTimeLimit']（默认 300 秒，且优先级更高）、MySQL 的 wait_timeout。但真正致命的是：亿级表的 ALTER TABLE 在后台可能跑几小时，而 phpMyAdmin 页面早就在 5 分钟内断连、清空响应、留下一个“执行中”的假象。你刷新页面，它甚至不告诉你语句还在 MySQL 里跑着还是已失败。
- 即使你把
max_execution_time改成 0，$cfg['ExecTimeLimit'] = 0也必须加，否则没用 - 改了配置后必须清浏览器缓存或换无痕窗口，否则旧 JS 缓存仍会主动中断请求
- 就算 PHP 层撑住了，MySQL 的
max_allowed_packet不够也会导致语句被截断，表现为页面空白或“无法连接服务器”这类误导性错误
ALTER 操作本身是否真需要 phpMyAdmin
不需要。它的 SQL 标签页只是个简易客户端，没有事务控制、无进度反馈、无增量同步能力。对大表执行 ADD COLUMN、MODIFY COLUMN 这类操作，本质是重建整张表+索引+触发器日志，期间原表会被锁（哪怕用了 ALGORITHM=INPLACE，也只减少锁时间，不消除）。
- MySQL 5.7+ 的
ALGORITHM=INPLACE只避免全表拷贝，但依然要加元数据锁（MDL），阻塞写入 - MySQL 8.0+ 的
ALGORITHM=INSTANT极其受限：仅支持添加/删除虚拟列、重命名列、改注释、增删二级索引；加一个带默认值的VARCHAR就退化为COPY - 查实际执行算法，别信文档：执行完立刻查
information_schema.INNODB_TABLES的ALGORITHM字段
真正该用什么替代 phpMyAdmin
生产环境只认两种方案：命令行直连，或 pt-online-schema-change。前者绕过所有 Web 层限制，后者解决锁表问题。
- 命令行导入（推荐先试）：
mysql -u root -p your_db < /path/to/alter.sql，完全跳过 PHP、HTTP、JS 渲染三层瓶颈 - 用
pt-online-schema-change做在线变更：必须确保表有主键或唯一非空索引，否则工具无法安全追踪增量；加--dry-run先验证，再加--execute；注意磁盘空间至少预留 1.5 倍原表大小 - 如果表有外键，必须显式加
--alter-foreign-keys-method=auto，否则可能静默失败或破坏约束 - 不要在 phpMyAdmin 的 SQL 标签页里粘贴长
ALTER语句——连接中断后状态不可知，你无法判断是失败了、卡死了，还是 MySQL 还在后台默默跑着
万一已经卡住，怎么快速止损
别等页面转圈。立刻开新窗口连 MySQL，查进程、杀任务、释放锁。
立即学习“PHP免费学习笔记（深入）”；
- 执行
SHOW FULL PROCESSLIST;，找Command是Query、State是copy to tmp table或Waiting for table metadata lock的那条 - 记下它的
Id，然后KILL [id];—— 注意不是KILL QUERY，那是中断当前语句但不释放锁 - 杀完立刻查
SELECT * FROM information_schema.INNODB_TRX;，确认没有残留事务 - 如果应用已出现读异常，检查是否因 MDL 锁导致后续查询排队；必要时重启 MySQL（最后手段）
真正难的不是“怎么加字段”，而是判断这个字段是否真的必须现在加、是否必须用 ALTER 加。很多所谓“紧急需求”，其实可以通过应用层兼容（如 JSON 字段暂存、双写过渡）绕开 DDL，这才是最省事的“超时解决方案”。
