最近一段时间处理了较多锁的问题，包括锁等待导致业务连接堆积或超时，死锁导致业务失败等，这类问题对业务可能会造成严重的影响，没有处理经验的用户往往无从下手。下面将从整个数据库设计，开发，运维阶段介绍如何避免锁问题的发生，提供一些最佳实践供RDS的用户参考。

    只读实例是目前RDS用户实现数据读写分离的一种常见架构，用户只需要将业务中的读请求分担到只读节点上，就可以缓解主库查询压力，同时也可以把一些OLAP的分析查询放到另外的只读节点上，减小复杂统计查询对主库的冲击。 由于RDS只读节点采用原生的MySQL Binlog复制技术，那么延迟必然会成为他成立之初就会存在的问题。延迟会导致只读节点与主库的数据出现不一致，进而可能造成业务上逻辑的混乱或者数据不正确；另外只读实例延迟同样也会触发binlog堆积，导致只读实例的空间迅速消耗完，这样会导致只读实例被锁定，锁定之后应用则无法完成读操作。 最近也收到了很多用户关于只读实例延迟的问题反馈，下面将会分析RDS只读实例出现延迟的几种常见场景，希望能够帮助用户理解和处理只读节点的延迟，更好地使用只读节点。

    很多时候，RDS用户经常会问如何调优RDS MySQL的参数，为了回答这个问题，写一篇blog来进行解释：1、哪一些参数不能修改，那一些参数可以修改；2、这些提供修改的参数是不是已经是最佳设置，如何才能利用好这些参数。

    昨天处理了一则复杂关联SQL的优化，这类SQL的优化往往考虑以下四点： 第一.查询所返回的结果集，通常查询返回的结果集很少，是有信心进行优化的； 第二.驱动表的选择至关重要，通过查看执行计划，可以看到优化器选择的驱动表,从执行计划中的rows可以大致反映出问题的所在； 第三.理清各表之间的关联关系，注意关联字段上是否有合适的索引； 第四.使用straight_join关键词来强制表之间的关联顺序，可以方便我们验证某些猜想； 执行时间： mysql> select c.yh_id, -> c.yh_dm, -> c.yh_mc, -> c.mm, -> c.yh_lx, -> a.jg_id, -> a.jg_dm, -> a.jg_mc, -> a.jgxz_dm, -> d.js_dm yh_