MySQL读写分离是一种常见的数据库架构优化手段，通过将读操作分散到多个从库，以减轻主库的压力，提高系统的响应速度和并发能力。然而，这种架构下会出现“过期读”问题，即由于主从之间数据同步存在延迟，导致从库读取的数据不是最新的。针对这一问题，业界提出了多种解决方案，下面将逐一介绍：

强制走主库方案

方案描述：对于那些对实时性要求较高的读操作，可以直接将其路由至主库执行。这样做的好处在于可以确保读取到最新数据，但会增加主库压力，降低读写分离的优势。

Sleep 方案

方案描述：在从库接收到读请求后，可以通过等待一段时间（Sleep）来尽可能确保数据同步完成，之后再执行读操作。这种方法较为简单粗暴，但无法精确控制等待时间，容易影响性能，并且在高并发环境下效果不稳定。

判断主备无延迟方案

方案描述：通过监控主从节点间的延迟情况，在确认主从数据同步无延迟时才允许从库执行读操作。这种方式依赖于精确的延迟检测机制，但并不能消除延迟风险，只是降低了过期读的可能性。

配合 Semi-Sync 方案

方案描述：MySQL的半同步复制(Semi-Synchronous Replication)特性可以在主库提交事务前等待至少一个从库确认接收binlog事件。启用半同步复制后，可以显著减少主从延迟，从而降低过期读的风险。

等主库位点方案

方案描述：在从库读取数据前，先确保从库已复制到与主库相同的binlog事件位点，只有当位点一致或超过某个阈值时，才执行读操作。这种方式能够更加精确地控制从库何时可以提供服务，但实现起来相对复杂。

GTID 方案

方案描述：全局事务标识符(Global Transaction Identifier, GTID)方案简化了主从同步的管理和跟踪。通过监控从库的GTID复制进度，确保从库在读取数据前已应用到与主库相同的GTID事务。这种方式能更有效地解决过期读问题，但需确保数据库版本支持GTID，并合理配置GTID复制。

实际生产中的策略
在实际生产环境中，一般会采取更加细致的策略。首先，根据业务需求对读请求进行分类，区分出那些可以容忍一定程度过期读的查询和那些必须获取最新数据的查询。对于不允许过期读的查询，可以采用等GTID或等位点的方案，确保在从库读取数据时，其数据状态与主库保持一致。

总结而言，MySQL读写分离中的过期读问题可以通过以上提到的多种策略结合使用来解决，具体实施方案需结合业务特性和技术栈进行权衡优化，以达到最佳的性能和数据一致性平衡。