php中触发mysql表级锁需显式执行lock tables或ddl语句，该锁为会话级、须手动unlock tables释放，仅对当前连接有效；innodb默认行锁，但lock tables仍会升级为表锁，myisam则默认表锁。
MySQL 表级锁在 PHP 中怎么触发
PHP 本身不提供表级锁机制，所有表级锁都由底层 MySQL 执行。你调用 LOCK TABLES 或执行 DDL（如 ALTER TABLE）时，MySQL 才会加锁。PHP 的作用只是发送 SQL 命令，关键看你怎么写、什么时候释放。
常见错误是以为 mysqli_query($conn, "LOCK TABLES users WRITE") 后，后续所有操作自动受保护——其实必须显式用 UNLOCK TABLES，且该锁只对当前连接有效，其他 PHP 进程完全不受影响。
-
LOCK TABLES是会话级的，断开连接或执行UNLOCK TABLES就释放 - MyISAM 引擎默认用表锁；InnoDB 虽支持行锁，但执行
LOCK TABLES ... WRITE仍会升级为表级排他锁 - 使用 PDO 时，
PDO::exec()和mysqli_query()都能发锁命令，但不能用预处理语句传锁类型（LOCK TABLES ? WRITE会报错）
什么场景下真得用表级锁
绝大多数 Web 应用不该主动加表锁。只有极少数确定性高、时间极短、且无法拆解为行锁的操作才考虑，比如全表统计后立刻重置计数器、或 MyISAM 表的批量导入前清空+重建索引。
典型反例：用表锁保护“生成订单号”逻辑——这应该用自增 ID + 格式化，或用 INSERT ... SELECT ... FOR UPDATE 配合唯一约束，而不是锁整张 orders 表。
立即学习“PHP免费学习笔记（深入）”；
- DDL 操作（
ALTER TABLE,TRUNCATE TABLE）隐式加锁，无需手动 LOCK - 批量数据迁移前，可先
FLUSH TABLES WITH READ LOCK（需 SUPER 权限），但会阻塞所有写入，慎用 - 如果业务要求“某一类操作全局串行”，更稳妥的做法是用 Redis 分布式锁或数据库里单独一张
lock_table插入唯一记录来模拟
建表时怎么避免被表锁拖垮
建表阶段就该排除表级锁风险，核心是选对引擎和索引策略。InnoDB 是默认且首选，它让绝大多数并发场景落在行锁甚至间隙锁上，而不是整张表卡死。
容易踩的坑是：用 MyISAM 存用户订单表，然后在支付回调里执行 UPDATE orders SET status=1 WHERE order_id='xxx'——MyISAM 对任何 UPDATE 都锁全表，QPS 上百就排队。
- 确认引擎：
SHOW CREATE TABLE orders查看是否为ENGINE=InnoDB - 避免全表扫描：没有 WHERE 条件的
UPDATE或DELETE在 InnoDB 中也会升级为表级锁（实际是锁所有行+间隙，效果类似） - 大字段（如
TEXT）不建普通索引，否则可能让优化器放弃使用索引，导致锁范围扩大
CREATE TABLE `orders` ( `id` bigint unsigned NOT NULL AUTO_INCREMENT, `order_no` varchar(32) NOT NULL, `status` tinyint NOT NULL DEFAULT '0', PRIMARY KEY (`id`), UNIQUE KEY `uk_order_no` (`order_no`), KEY `idx_status` (`status`) ) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4;
并发高时表锁问题怎么快速定位
不是代码写了 LOCK TABLES 才叫表锁问题。很多“疑似卡死”其实是隐式锁或长事务导致的表级效应，比如一个未提交的事务持有行锁，另一个事务想 ALTER TABLE 就会被堵住，表现为整个表不可写。
查锁状态第一反应不是翻 PHP 日志，而是连上 MySQL 执行：
-
SHOW PROCESSLIST看有没有Locked状态或长时间Sleep的连接 -
SELECT * FROM information_schema.INNODB_TRX查当前活跃事务及其等待情况 -
SHOW OPEN TABLES WHERE In_use > 0直接看到哪些表被锁住（尤其注意In_use值大于 1）
真正难处理的是“锁等待链”：A 锁了行 X 等 B 提交，B 锁了行 Y 等 C 提交……这种靠 PHP 层加锁解决不了，必须从事务粒度和提交时机入手。
