• 遇事不决临键锁：可以认为，全部都是加临键锁的，除了下面两个子句提到的例外情况
• 右边缺省间隙锁：例如你的值只有(1,4,7)三个，但是你查询的条件是where id < 5，那么加的是间隙锁，因为7本身就不在查询范围里。
• 等值查询记录锁：针对的是主键和唯一索引，不适用于普通索引

• 公司出现过的死锁，包括排查过程、解决方案
• 其他锁使用不当的场景，比如因为锁使用不当造成的一些性能问题
• 收集至少一个使用乐观锁的场景，并看看相关的SQL是怎么写的
• 收集使用悲观锁的场景，尝试使用乐观锁来优化

这些案例非常重要，如果自己没有亲自遇到的话，也要找同事问清楚，或是参考网上的案例来实际看看锁的应用。

类似索引，面试官可能直接写一个SQL语句，问你可能加什么锁

• 在主键或唯一索引上使用等值查询，例如where email = 'abc@qq.com' 区分记录存在与不存在的情况 （存在是记录锁 不存在是间隙锁 未命中索引是表锁）
• 在主键或唯一索引上使用范围查询，例如where email >= 'abc@qq.com' （临键锁 大于部分是间隙锁 等于部分是记录锁）
• 在普通索引上使用等值查询 （临键锁）
• 在普通索引上使用范围查询（临键锁）
• 执行查询，但是查询不会使用任何索引（表锁）

不管怎么回答，都要强调间隙锁和临键锁是在可重复读的隔离级别下才有效果

聊到下面的话题，也可以引导到锁机制上

• 索引：MySQL的InnoDB是借助索引来实现行锁的
• 性能问题：锁使用不当引起的性能问题

• 乐观锁：比如原子操作的CAS操作，聊一聊在MySQL层面上怎么利用类似CAS的操作实现乐观锁

  在 MySQL 层面上，要实现类似 CAS 操作来实现乐观锁，通常可以使用以下方式：

  1. 使用版本号或时间戳：在数据表中添加一个版本号或时间戳字段，每次更新数据时将版本号加一或更新时间戳。在进行更新操作时，需要检查更新前后的版本号或时间戳是否一致，如果一致则进行更新，否则认为数据已被其他事务修改。
  2. 使用乐观锁的存储过程：通过存储过程实现乐观锁的逻辑，可以在存储过程中进行数据检查和更新操作，以确保并发更新时的数据一致性。

  这些方法可以帮助在 MySQL 层面上实现类似 CAS 操作的乐观锁机制，从而避免并发更新时出现数据不一致的问题。

• 语言相关的锁：比如Go的mutex

• 死锁：公司的数据库死锁案例