MySQL 中锁粒度直接影响并发性能。锁的粒度越小，并发性越高，冲突越少。优化锁粒度的核心是尽量使用更细粒度的锁，避免长时间持有大范围锁。以下是几个关键策略。
选择合适的存储引擎
不同的存储引擎支持不同级别的锁：
InnoDB：支持行级锁，锁粒度最小，适合高并发读写场景。在事务中操作数据时，只锁定涉及的行，其他行仍可被访问。 MyISAM：只支持表级锁，任何写操作都会锁住整张表，导致并发性能差，不推荐用于写密集型应用。因此，优先使用 InnoDB 引擎是优化锁粒度的第一步。
合理设计索引以支持行锁
InnoDB 的行锁依赖索引。如果 SQL 查询无法命中索引，会退化为表锁，大幅降低并发能力。
确保 WHERE 条件中的字段有合适的索引。 避免全表扫描，比如在没有索引的列上做查询或类型转换（如字符串与数字比较）。 使用 EXPLAIN 检查执行计划，确认是否使用了索引和行锁。例如，执行
UPDATE users SET name='Tom' WHERE id=100，如果 id 是主键或唯一索引，只会锁定该行；如果没有索引，则可能锁整张表。
减少事务持有锁的时间
锁的持续时间越长，其他事务等待的概率越大。应尽量缩短事务生命周期。
避免在事务中执行耗时操作，如网络请求、复杂计算。 尽快提交事务，不要在事务提交前长时间等待用户输入或外部响应。 使用自动提交模式处理简单语句，减少显式事务的滥用。例如，把非数据库操作移出事务块，先完成逻辑再开启事务更新数据。
避免死锁和锁升级
虽然 InnoDB 支持行锁，但在某些情况下仍可能出现锁竞争甚至死锁。
按固定顺序访问多张表或多行数据，减少死锁概率。 批量更新时分批提交，避免一次性锁定大量行导致锁升级或资源耗尽。 设置合理的超时时间（innodb_lock_wait_timeout），及时释放等待锁的事务。InnoDB 会自动检测死锁并回滚代价较小的事务，但频繁死锁说明设计需要优化。
基本上就这些。关键是用对引擎、建好索引、控制事务范围。锁粒度优化不是一蹴而就，需要结合业务场景持续观察和调整。
