MySQL行锁和表锁最核心的区别在于锁定粒度——行锁只锁住符合条件的某几行，表锁则直接锁住整张表。这个差异直接决定了它们在并发性、锁开销、死锁风险和适用场景上的不同表现。
锁定粒度与并发能力
行锁作用于单行数据，多个事务可同时修改不同行，互不干扰；而表锁一旦加锁，其他事务对这张表的任何读写（包括SELECT、INSERT、UPDATE、DELETE）都会被阻塞。
行锁：适合高并发OLTP业务，比如电商下单、账户余额变更 表锁：适合低频批量操作，如夜间报表统计、历史归档或MyISAM引擎下的简单读多写少场景锁的开销与死锁风险
行锁管理成本高，需维护每行的锁状态，加锁慢，且可能因事务交叉等待引发死锁；表锁结构简单，加锁快、无死锁，但容易成为性能瓶颈。
InnoDB默认用行锁，但若WHERE条件未命中索引，会自动升级为表锁 MyISAM只支持表锁，增删改查自动加读/写锁，无需手动干预 可通过SHOW ENGINE INNODB STATUS\G查看当前行锁等待与死锁详情锁的实现方式与显式控制
行锁通常隐式触发（如UPDATE WHERE id=5），也可显式声明：
SELECT ... FOR UPDATE加排他锁，
SELECT ... LOCK IN SHARE MODE加共享锁；表锁则需显式使用
LOCK TABLES t1 WRITE等命令（InnoDB中慎用，MyISAM中更常见）。 行锁依赖索引生效，无索引字段查询会退化为全表扫描+表级锁定 表锁分READ（允许多个并发读）和WRITE（独占，阻塞一切读写）两种模式 显式表锁必须配对使用
UNLOCK TABLES，否则会持续阻塞
引擎支持与默认行为
锁机制高度依赖存储引擎：InnoDB默认行锁，支持事务与MVCC；MyISAM只支持表锁，无事务；MEMORY引擎也仅支持表锁。
检查表引擎：SHOW CREATE TABLE table_name监控表锁争用：
SHOW STATUS LIKE 'Table_locks%'，重点关注Table_locks_waited是否持续增长 生产环境应优先选用InnoDB，并确保关键查询字段有合适索引，避免隐式锁升级
