数据库锁机制有哪些（行锁、表锁、意向锁等）？它们如何影响并发性能？死锁是如何产生的？如何避免或检测死锁？
数据库锁机制是保证数据并发访问一致性的核心手段，不同的锁类型适用于不同场景，对并发性能的影响也差异显著。以下从锁类型、并发影响、死锁原理及处理三个方面展开说明：
一、数据库锁的主要类型及工作原理、适用场景
1. 按锁定粒度划分（最常见分类）
（1）表锁（Table-level Lock）
工作原理：对整个表进行加锁，锁定期间其他事务无法对表执行冲突操作（如写操作）。
分为共享锁（S锁，读锁）和排他锁（X锁，写锁）：
S锁：事务持有后，其他事务可加S锁（共享读），但不可加X锁（阻塞写）；
X锁：事务持有后，其他事务不可加S锁或X锁（读写均阻塞）。
适用场景：
读写比例极度不均衡（读远多于写），且写操作频率低（如静态配置表）；
不支持行锁的数据库引擎（如MySQL的MyISAM）；
需批量修改全表数据（如ALTER TABLE），避免逐行锁的开销。
特点：实现简单、开销小（无需记录每行锁状态），但锁定粒度大，并发冲突概率高（尤其写操作时会阻塞全表读）。
（2）行锁（Row-level Lock）
工作原理：仅对表中某一行数据加锁，其他事务可操作表中其他行，锁定粒度极小。
同样支持S锁和X锁，且遵循“两阶段锁协议”（事务结束时释放所有锁）。
注意：行锁通常依赖索引实现，若查询未命中索引（如全表扫描），数据库可能自动升级为表锁（如MySQL InnoDB的“间隙锁+行锁”退化场景）。
适用场景：
并发写入频繁，且修改集中在部分行（如用户订单表、交易记录）；
支持事务的数据库引擎（如InnoDB、PostgreSQL），需保证事务ACID特性；
读写冲突较少的场景（如多用户同时修改不同行数据）。
特点：并发性能高（冲突概率低），但实现复杂、开销大（需维护每行锁的状态），可能引发死锁。
（3）页锁（Page-level Lock）
工作原理：锁定数据页（数据库存储的基本单位，如InnoDB默认页大小16KB），粒度介于表锁和行锁之间。
当事务操作某页中的一行时，会锁定整个页，其他事务可操作其他页。
适用场景：
数据访问模式集中在某几页（如按范围查询并修改连续行），避免行锁的高频开销和表锁的低并发；
部分数据库引擎（如BDB）的默认锁机制。
特点：平衡了表锁和行锁的优缺点，并发性能中等，但可能因“页内多行竞争”导致冲突（如同一页内多行被频繁修改）。
2. 意向锁（Intention Lock）
工作原理：InnoDB特有的表级锁，用于“预先声明”事务对表中行锁的操作意图，避免表锁与行锁的冲突检查开销。
分为意向共享锁（IS）和意向排他锁（IX）：
事务想对某行加S锁时，需先对表加IS锁；
事务想对某行加X锁时，需先对表加IX锁。
作用：当需要加表级S锁/X锁时，只需检查表上是否有冲突的意向锁（如加表S锁需确保无IX锁），无需逐行检查行锁，减少锁检查开销。
特点：不直接阻塞读写操作，仅作为“意向标记”，是行锁与表锁协作的桥梁。
3. 其他特殊锁
间隙锁（Gap Lock）：InnoDB在RR（可重复读）隔离级别下，为防止幻读，对索引范围间隙加锁（如WHERE id > 10会锁定id=10之后的间隙），避免其他事务插入新行。
临键锁（Next-key Lock）：行锁+间隙锁的组合，锁定索引记录及相邻间隙，是InnoDB默认的行级锁模式。
乐观锁（Optimistic Lock）：非数据库原生锁，通过版本号（如version字段）或时间戳实现，事务操作时不加锁，提交时检查版本是否变化（如UPDATE ... WHERE version = 1），适合读多写少、冲突少的场景。
悲观锁（Pessimistic Lock）：即上述表锁、行锁等，事务操作时直接加锁，阻塞其他事务，适合写冲突频繁的场景。
二、锁机制对并发性能的影响
锁机制对并发的影响核心取决于锁定粒度和冲突概率，规律如下：
粒度越小（如行锁）：并发性能越高（锁定范围小，冲突少），但锁维护开销大（内存、CPU消耗高）；
粒度越大（如表锁）：并发性能越低（锁定范围大，冲突多），但锁维护开销小（适合简单场景）。
具体影响案例：
表锁在写操作时会阻塞全表读，导致读请求排队，并发吞吐量骤降；
行锁若使用不当（如无索引导致升级为表锁），会退化为表锁的低并发问题；
间隙锁可能导致“锁范围扩大”（如范围查询锁定过多间隙），引发不必要的阻塞，降低并发。
三、死锁的产生、避免与检测
1. 死锁的产生原因
死锁是指两个或多个事务相互持有对方需要的锁，且都不主动释放，导致永久阻塞的状态。
核心条件（满足以下全部）：
互斥：事务持有对方需要的排他锁；
持有并等待：事务已持有部分锁，且等待其他锁；
不可剥夺：锁只能由持有事务主动释放，不可强制剥夺；
循环等待：事务形成环形等待链（如A等B的锁，B等A的锁）。
示例：
事务1：更新行A（持有行A的X锁），再尝试更新行B；
事务2：更新行B（持有行B的X锁），再尝试更新行A；
此时事务1等待行B的锁，事务2等待行A的锁，形成死锁。
2. 死锁的避免方法
统一加锁顺序：所有事务按固定顺序获取锁（如按主键升序），避免循环等待（如上述示例中，强制事务1和2都先更新行A再更新行B）。
减少锁持有时间：事务中尽量晚加锁、早释放（如避免在事务中执行无关操作，快速提交），降低锁冲突窗口。
降低隔离级别：如从RR（可重复读）降为RC（读提交），InnoDB在RC级别会关闭间隙锁（除外键和唯一索引），减少锁范围。
使用乐观锁：通过版本号控制，避免显式加锁，从根本上消除死锁（适合冲突少的场景）。
限制锁超时时间：设置锁等待超时（如MySQL的innodb_lock_wait_timeout），超时后自动释放锁，避免永久阻塞。
3. 死锁的检测与处理
数据库自动检测：主流数据库（如InnoDB、PostgreSQL）内置死锁检测机制（如InnoDB通过“等待图”检测循环等待），发现死锁后会选择“代价最小”的事务回滚（如修改行数少的事务），释放锁以打破僵局。
人工监控：通过数据库日志（如MySQL的error.log）或系统视图（如SHOW ENGINE INNODB STATUS）查看死锁详情（涉及的事务、SQL、锁类型），针对性优化。
总结
锁机制的核心是平衡“一致性”与“并发性能”：粒度小的锁（行锁）并发高但开销大，粒度大的锁（表锁）相反。死锁的本质是循环等待，可通过规范加锁顺序、减少锁持有时间等方式避免，数据库也会自动检测并处理死锁。实际应用中需根据业务场景（读写比例、冲突频率）选择合适的锁策略，避免过度加锁或锁滥用。