这篇讲的是 MySQL 锁问题的最佳实践，作者从自身处理的大量实际案例出发，系统性地梳理了在设计、开发和维护三个阶段如何规避锁问题。 文章一针见血地指出，许多严重的锁等待或死锁，根源往往在设计之初就埋下了。比如，继续使用仅支持表级锁的 MyISAM 引擎，会因一个慢查询阻塞所有更新；而索引设计不当，如更新语句触发 index merge，可能导致不同事务以不同顺序锁定索引，直接引发死锁。 在开发阶段，作者通过一个真实案例展示了长事务的危害：一个事务由于包含了其他业务逻辑，迟迟未能提交，导致后续更新同一行记录的事务陷入漫长的锁等待。排查时通过查询 innodb_lock_waits 视图定位阻塞事务，并结合 general log 还原事务上下文，最终发现问题。 文章的价值在于，它没有停留在理论，而是提供了具体的排查命令、日志分析方法和优化建议（如创建组合索引避免 index merge）。对于 DBA、后端开发以及运维人员来说，这些源于生产环境的经验能帮助他们在各自的环节提前预防，避免业务连接堆积或超时等严重故障。
这篇讲的是RDS只读实例延迟的深度排查与实战解决。作者开篇即点明，延迟是只读架构（基于原生Binlog复制）与生俱来的挑战，会导致数据不一致甚至触发Binlog堆积，最终可能引发只读实例被锁、业务读操作失败。 文章系统梳理了导致延迟的五大典型场景，并给出了具体判据。例如，只读节点IOPS耗尽可能源于规格过小（对比主库配置）；主库TPS过高但只读节点是单线程同步时，延迟难以避免；耗时长的DDL操作（如ALTER TABLE）会原样在只读节点执行，造成秒级甚至分钟级的同步卡顿；而大事务（如INSERT…SELECT）则会产生海量Binlog，使只读节点的SQL线程长时间处于“追赶”状态。 文章最后归纳了一套实用的“四看”排查法：一看只读节点IOPS是否触顶，二看其Binlog增长是否异常（定位大事务），三对比主库的ComDML指标（判断写入压力），四检查是否存在“Waiting for table metadata lock”等连接阻塞。这套方法能帮助用户快速定位问题根源，无论是优化配置、调整业务还是拆分事务，都能让读写分离架构运行得更顺畅。
这篇讲的是RDS MySQL用户常困惑的参数调优问题。作者从实际场景出发，首先明确了哪些参数由产品规格或数据安全决定无法修改，比如内存、连接数和主备同步相关参数。这解决了用户“能不能改”的首要疑惑。 文章的核心价值在于，它清晰地指出绝大部分参数已由专业团队优化，仅需针对特殊场景微调。随后，作者深入剖析了open_files_limit、back_log、innodb_autoinc_lock_mode等几个关键参数：逐一说明其作用、设置不当会引发的典型错误现象（如“Too many open files”、连接超时或死锁），并给出了具体的调整建议和原理。 此外，文章还介绍了几个RDS特有的实用参数，例如控制临时磁盘空间的rds_max_tmp_disk_space和用于保护数据库的rds_threads_running_high_watermark，让读者能按需应用。整体而言，这篇文章并非泛泛而谈，而是提供了从“能否修改”到“为何调整”再到“如何调整”的完整实践路径，能帮助用户避免性能陷阱。
这篇讲的是如何将一个耗时 750ms 的复杂关联 SQL 优化到毫秒级的过程。作者从一个真实案例出发，通过分析执行计划，精准定位了性能瓶颈：一条只返回一行数据的查询，却因为驱动表选择不当和索引缺失，导致在两张表上发生了全表扫描。 优化过程分为两步走。首先，针对 `left join` 的 d 表添加了缺失的 `yh_id` 索引，使其扫描行数从 5 万多行骤降至 272 行。但整体耗时并未改善，因为优化器仍坚持选择 a 表作为驱动表。作者进一步深入分析，发现根本原因在于关联字段 `yh_id` 在 b 表上没有索引，导致优化器认为以 a 表驱动的代价更低。于是，第二步是为 b 表和过滤性极强的 c 表分别添加了 `yh_id` 和 `yh_dm` 索引。 索引齐全后，优化器终于“回心转意”，转而选择数据量更小、过滤条件更强的 c 表作为驱动表，执行计划彻底改变，查询时间从 0.75 秒直接降为 0.00 秒。这个案例清晰地展示了，优化复杂 SQL 不能只看单表索引，更要理清表间关联逻辑与数据分布，通过分析执行计划来引导优化器做出正确选择。
