phpMyAdmin 不提供行级锁定界面功能，所有行锁必须由 MySQL 在事务中显式执行；点击编辑或浏览仅发送普通 SELECT，不加锁；可靠方式是在 SQL 标签页手动执行 BEGIN 后的 SELECT ... FOR UPDATE 或 LOCK IN SHARE MODE。
phpmyadmin 本身不提供行级锁定界面功能，它只是一个 web 前端，无法直接“锁定查询结果中的某几行”供后续操作——所有行锁必须由 mysql 服务端在事务中显式执行，且仅对当前连接有效。
为什么 phpMyAdmin 里点选的行不会被锁住
你在 phpMyAdmin 的表格视图中点击某行、甚至勾选多行再点“编辑”，只是前端生成了一个 UPDATE 或 SELECT 表单，提交时才真正发 SQL。此时若无显式事务和锁语句，MySQL 完全按默认隔离级别（通常是 REPEATABLE READ）处理，**不加任何行锁**。
- phpMyAdmin 的“浏览”页面执行的是普通
SELECT，不带FOR UPDATE或LOCK IN SHARE MODE - 即使你复制了某行的主键去写
UPDATE，执行瞬间才加锁，且锁在语句结束或事务提交后立即释放 - 没有后台长连接维持锁状态，“锁定结果行”这个动作在 phpMyAdmin 界面层根本不存在
真要锁住某些行，必须手写带锁的 SELECT 语句
唯一可靠方式：在 phpMyAdmin 的“SQL”标签页中，手动运行带锁提示的 SELECT ... FOR UPDATE（排他锁）或 SELECT ... LOCK IN SHARE MODE（共享锁），且必须包裹在 BEGIN / COMMIT 事务中。
- 先执行
BEGIN开启事务 - 再执行类似
SELECT * FROM users WHERE id IN (101, 102) FOR UPDATE—— 这会为匹配的行加写锁 - 此时其他连接尝试更新这些
id会阻塞，直到你执行COMMIT或ROLLBACK - 注意：
FOR UPDATE在非唯一索引列上可能升级为间隙锁（gap lock），影响并发插入 - 如果只读不改，用
LOCK IN SHARE MODE允许多个读事务共存，但会阻止写事务
常见误操作与后果
很多人以为在 phpMyAdmin 中“编辑某行”就等于锁住了它，实际完全不是：
- 点击“编辑”后弹出表单，此时 MySQL 已释放所有锁（因为上一条
SELECT早就结束了） - 你填完点“执行”，phpMyAdmin 发送的是独立
UPDATE，若期间别人已改过该行，可能产生覆盖或触发WHERE条件失效 - 试图在 SQL 标签页单独执行
SELECT ... FOR UPDATE但不跟COMMIT，连接断开后事务自动回滚，锁无效 - 在 phpMyAdmin 设置里开启“启用二进制日志”或“启用持久连接”对行锁毫无帮助——锁由 SQL 语义和事务控制，不由前端配置决定
真正的行锁依赖精确的 SQL 语义、索引支持和事务生命周期管理；phpMyAdmin 只是传话筒，别指望它替你 hold 住锁。最易被忽略的一点：锁是否生效，取决于你查的字段是否有可用索引——全表扫描时，FOR UPDATE 可能锁住整张表。
