行锁和表锁的核心区别在于锁定范围和并发能力：行锁只锁某一行，多个事务可同时操作不同行；表锁锁住整张表，其他事务对这张表的任何读写都会被阻塞。
锁定粒度与影响范围不同
行锁作用于单行数据，是 InnoDB 引擎默认采用的锁机制。它依赖索引实现——只有 WHERE 条件命中索引时，才会真正加行锁；若查询无索引，InnoDB 会退化为全表扫描并升级为表锁。
表锁作用于整张表，MyISAM 引擎只支持表锁，InnoDB 在显式使用
LOCK TABLES或执行 DDL（如
ALTER TABLE）时也会触发表级锁。读锁（
READ）允许多个事务并发读，但阻塞写；写锁（
WRITE）则完全独占，读写均被阻塞。
并发性能与锁冲突概率相反
行锁粒度小，并发高，适合电商订单、账户余额等高频更新场景。但管理开销大，存在死锁风险，需靠事务及时提交、避免循环等待来规避。
表锁粒度大，并发低，适用于批量导入、报表统计等短时全表操作。优点是加锁快、无死锁，但一旦写锁持有时间稍长，后续所有请求就会排队等待。
加锁方式与使用条件有明显差异
行锁通常隐式触发：
UPDATE、
DELETE、
INSERT自动加排他锁（X锁）；显式加锁用
SELECT ... FOR UPDATE（写锁）或
SELECT ... LOCK IN SHARE MODE（读锁），且必须在事务中执行。
表锁既可隐式（MyISAM 查询/更新自动加锁），也可显式：
LOCK TABLES t1 WRITE，之后必须配对
UNLOCK TABLES。注意 InnoDB 显式加表锁会禁用 MVCC，降低并发优势。
引擎支持和实际选择建议
MyISAM 只支持表锁，不适合写多场景；InnoDB 默认行锁，应优先使用。除非满足以下条件，否则不建议主动用表锁：
需要对整张表做快速批量更新或清空 确认没有其他并发写入，且操作耗时极短 业务逻辑明确要求强一致性且不依赖高并发日常开发中，更关键的是避免行锁失效：确保 WHERE 条件走索引，监控
table_locks_waited和
innodb_row_lock_waits等状态变量，及时发现锁争用苗头。
