数据库管理员平均每周要处理超过15次锁等待问题，而其中超过六成可以通过索引设计和事务拆分提前规避。

从一次电商秒杀看锁竞争的真实成本

假设一张订单表在秒杀场景下同时写入1000条记录，默认行锁模式下，同一主键或聚簇索引范围的数据会排队等待。某团队曾遇到秒杀接口响应从200ms飙升到8秒的情况，排查发现是因为update语句没有走索引，导致MySQL从行锁升级为表锁。加上事务中有跨表查询未提交，锁持有时间被拉长到2秒以上。添加唯一索引后，锁粒度回到行级，响应时间立刻降到400ms以内。

备份恢复中最容易忽略的间隙锁陷阱

夜间逻辑备份使用mysqldump时，如果未指定--single-transaction，MyISAM表会被全局读锁阻塞写入。更隐蔽的情况是：某金融系统在凌晨用pt-online-schema-change改表结构，触发隐式提交导致备份事务中断，恢复时发现少了23分钟的数据。实际解决方案是：对InnoDB表强制使用--single-transaction，对混合引擎库先查询information_schema.tables确认存储引擎类型，再单独处理MyISAM表。

索引下推与联合索引的左前缀误区

某用户反馈查询`WHERE age BETWEEN 20 AND 30 AND city='北京'`明明有联合索引(age,city)却走了全表扫描。检查发现索引定义是(city,age)，而查询条件中city的等值条件在age的范围条件之后，左前缀规则下city无法被利用。正确做法是建立(city,age)索引，让等值字段放在最左侧。数据验证显示，这样修改后扫描行数从80万降到300行，执行时间从3.2秒降至12毫秒。

3个最易踩中的盲区与对策

• 盲区1：认为事务隔离级别越高越安全——可重复读级别在RC（读已提交）基础上增加间隙锁，高并发插入场景下容易产生死锁。实际高频交易系统多用RC级别，配合应用层乐观锁控制并发。
• 盲区2：忽略慢查询日志的采样粒度——默认long_query_time=10秒会漏掉大量0.5秒的慢语句。建议生产环境设为1秒，并配合pt-query-digest定期分析前20条最耗时的模式。
• 盲区3：连接池大小盲目设大——MySQL的线程处理是CPU密集型，当连接数超过CPU核心数2倍时，上下文切换开销反而拖慢响应。最佳实践是保持连接数在(CPU核心数×2+1)以下，等待队列用应用层队列处理。