phpMyAdmin 4.9 点“更改”卡住或超时，主因是默认触发全表COPY重建且未显式指定ALGORITHM=INPLACE/LOCK=NONE；应切SQL页手动执行补全约束的MODIFY COLUMN语句，并调大wait_timeout等服务端超时参数。
phpMyAdmin 4.9 点“更改”后卡住或报超时，怎么办
phpMyAdmin 4.9 对大表（比如行数 > 50 万或单行宽字段多）执行字段修改时，常在点击“更改”保存后卡在 Loading 状态，或直接返回 MySQL server has gone away、timeout 错误。这不是界面 bug，而是它底层调用 ALTER TABLE 时未加 ALGORITHM=INPLACE 或 LOCK=NONE，且默认启用全表拷贝重建——旧版本不自动降级策略，也不提示你换 SQL 手动执行。
实际应对方式不是等它转圈，而是立刻切到 SQL 标签页手动执行：
- 先查当前字段最大长度：
SELECT MAX(LENGTH(column_name)) FROM table_name;，确认扩长是否安全 - 若只是扩展 VARCHAR 长度（如
VARCHAR(100) → VARCHAR(255)），用MODIFY COLUMN并显式补全约束，避免丢NOT NULL或DEFAULT - 禁用 phpMyAdmin 自动事务包装：在 SQL 窗口顶部取消勾选 “启用自动提交”，防止长操作被意外中断
为什么不能只改长度数字，必须重写整行定义
在 phpMyAdmin 4.9 的“结构”页点“更改”，它生成的 SQL 默认只含类型和长度，比如 MODIFY COLUMN name VARCHAR(255)。但 MySQL 实际执行时会把原字段所有属性（NOT NULL、DEFAULT 'xxx'、COLUMN_FORMAT FIXED 等）全部清空——哪怕你没动它们。
后果是：应用层突然收到 NULL 值、插入时报错 Field 'name' doesn't have a default value，或者 ORM 映射失败。所以必须人工补全：
立即学习“PHP免费学习笔记（深入）”；
- 先用
SHOW CREATE TABLE table_name查出原字段完整定义 - 把
VARCHAR(100)换成VARCHAR(255)，其余部分一字不改粘贴进 SQL 窗口 - 特别注意：如果原字段有
COMMENT，漏写就会丢失注释，后续排查字段用途会变困难
缩字段长度在 phpMyAdmin 4.9 里根本不能点保存
当你在界面上把 VARCHAR(255) 改成 VARCHAR(50) 并点“保存”，phpMyAdmin 4.9 不会提前校验数据，而是直接发 MODIFY COLUMN。一旦表中存在超长值，MySQL 执行时静默截断（无警告），且事务无法回滚——你刷一下页面，发现数据已经丢了。
安全做法只有两步，缺一不可：
- 执行检查语句：
SELECT id, column_name FROM table_name WHERE LENGTH(column_name) > 50;，人工确认是否可删/可截 - 真要收缩，必须用带
USING的ALTER TABLE ... ALTER COLUMN ... TYPE（仅 PostgreSQL）或 MySQL 下先UPDATE截断再MODIFY，不能依赖界面 - phpMyAdmin 4.9 的“更改”按钮对收缩操作毫无防护能力，把它当摆设更安全
真正影响成败的是 MySQL 服务端配置，不是 phpMyAdmin
很多人以为调大 phpMyAdmin 的 $cfg['MaxExecutionTime'] 就能搞定大表修改，其实没用——超时发生在 MySQL 层：wait_timeout、innodb_lock_wait_timeout、max_allowed_packet 这三个参数才决定 ALTER 能不能跑完。
如果你没有服务器权限，至少得确认：
- 执行前在 SQL 窗口先运行：
SET SESSION wait_timeout = 600; SET SESSION innodb_lock_wait_timeout = 600; - 如果字段含 JSON 或长文本，
max_allowed_packet小于内容长度会导致直接中断，此时只能导出再导入 - phpMyAdmin 4.9 不显示这些服务端限制，错误信息也模糊，所以看到 “无法连接 MySQL 服务器” 先别重试，先查
SHOW VARIABLES LIKE '%timeout%';
