504 Gateway Timeout常因MyISAM表级锁导致：单次写操作阻塞全表，其他请求排队超时；SHOW ENGINE INNODB STATUS无效，应查SHOW PROCESSLIST、SHOW OPEN TABLES及performance_schema.metadata_locks，根本解法是迁移到InnoDB。
MyISAM 表根本不会“死锁”，但它的表级锁会直接拖垮 HTTP 请求——这不是配置问题，而是引擎特性决定的。你看到的 504 Gateway Timeout 或 PHP 脚本超时，几乎总是因为某条 INSERT、ALTER 或 LOAD DATA 卡住了整张表，其他请求排队等锁，直到 Web 层先扛不住。
为什么 SHOW ENGINE INNODB STATUS 查不到 MyISAM 锁问题
这条命令只对 InnoDB 有效，MyISAM 没有事务、没有死锁检测、也不维护锁队列。你执行它，要么返回空，要么只显示无关的 InnoDB 状态。真正该查的是：
-
SHOW PROCESSLIST：找State列为Locked或Waiting for table level lock的线程 -
SHOW OPEN TABLES WHERE In_use > 0：确认哪些表正被写锁强占（In_use > 0表示有线程持有写锁） -
SELECT * FROM performance_schema.metadata_locks WHERE OBJECT_SCHEMA = 'your_db'：查看元数据锁（MDL）是否被长期持有
MyISAM 锁等待的典型触发点
所有阻塞都源于它的表级锁特性：一次写操作会独占整张表，其他读写全部排队。常见诱因包括：
- 单条
INSERT INTO t VALUES (),(),...插入上万行，锁表数秒甚至分钟 -
LOAD DATA INFILE导入大文件，未加LOW_PRIORITY - 高峰期执行
ALTER TABLE（哪怕只是加字段，MyISAM 也要全表拷贝重建） - 普通
SELECT与写操作争抢锁（默认不加优先级，会被写锁阻塞） - 事务中混用 MyISAM 和 InnoDB 表（MyISAM 不参与事务，但会拖慢连接释放）
如何快速缓解 HTTP 层超时
不能“解决死锁”（因为不存在），但能大幅缩短锁表时间和排队深度，避免 Web 请求在数据库层卡死：
- 批量写入拆成每
500–1000行一批，用循环或脚本控制，避免单条巨量INSERT - 读密集场景下，非关键查询显式加
SQL_NO_CACHE；必要时用SELECT HIGH_PRIORITY抢锁（慎用，可能饿死写操作） - 写操作优先用
INSERT LOW_PRIORITY，让读请求优先通过（INSERT DELAYED在 MySQL 8.0 已移除） - 必须改结构时，用原子切换：
CREATE TABLE new LIKE old→INSERT INTO new SELECT * FROM old→RENAME TABLE old TO old_bak, new TO old
最根本的缓解方式不是调优，而是迁移
除非你明确依赖 MyISAM 的全文索引（InnoDB 自 5.6 起已支持）或压缩表特性，否则应尽快把表引擎改为 InnoDB。这不是“可选项”，而是当前版本下对 MyISAM 表锁问题的唯一根治路径。迁移后，LOCK WAIT TIMEOUT EXCEEDED 错误会从“整张表卡死”退化为“某几行冲突”，排查和恢复成本骤降。
