行锁锁单行、并发高但有死锁风险，依赖索引；表锁锁整表、并发低但无死锁，MyISAM仅支持表锁，InnoDB默认行锁，显式表锁会禁用MVCC。
行锁和表锁的核心区别在于锁定范围和并发能力：行锁只锁某一行，多个事务可同时操作不同行；表锁锁住整张表，其他事务对这张表的任何读写都会被阻塞。
锁定粒度与影响范围不同
行锁作用于单行数据，是 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 等状态变量，及时发现锁争用苗头。
