7行锁
增么减少行锁对性能的影响？
引擎层实现行锁
MyISAM不支持行锁，只能用表锁控制并发，性能低
InnoDB支持行锁
两阶段行锁
事务开始时不加，使用时加，事务提交时释放
优化思路：合理安排事务语句顺序
把最可能造成锁冲突、影响并发度锁的申请时机往后放
死锁
循环等待资源
解决死锁
show engine innodb status 查看InnoDB引擎的状态信息LATEST DETECTED DEADLOCK部分查看死锁详情。
通过死锁日志分析死锁
超时机制
InnoDB innodb_lock_wait_timeout默认值50s
缺点：时间长无法等待
主动死锁检查
innodb_deadlock_detect默认值on
可以快速发现并处理，但有额外负担（消耗CPU）
1000个线程并发更新同一行，死锁检查数量级时100万级（每个线程都检查1000个线程000*1000）即使没有发生死锁，也消耗大量CPU。
如何解决热点行更新，主动检查导致的性能问题呢？
- 关闭检查
出现死锁的风险，出现后回滚，重试一般业务无损
若出现大量超时，业务有损 - （共享资源）并发度控制
- 修改MySQL引擎源码，对相同行更新进入引擎前排队
- 业务涉及优化，如将共享变量合理拆分，将并发请求分散
如影院卖票，影院余额可设置多行记录累加，但须考虑退票，业务上需要详细设计。