AWS RDS MySQL innodb/btr_search_latch
我在 AWS RDS 上运行 MySQL 5.7.24，我有一个 InnoDB 类型表并且在正常流量下工作正常，但是当向 50k 用户发送推送通知时出现了问题。
服务器具有 32 GB RAM、8vCPU，我的 AWS RDS 服务器是 db.m5.2xlarge。
wait /synch/sxlock/innodb/btr_search_latch占用的资源大于wait/io/table/sql/handler如下图所示
innodb_adaptive_hash_index现已启用
您想在五分钟内发送 50,000 个推送通知吗？
50,000 / 300 秒意味着您每秒推送 167 个通知，我假设然后更新数据库以记录推送结果。也许您正在许多并发线程中执行此操作，因此您可以并行进行推送。
您是否考虑过逐渐执行这些推送通知，例如超过 10 或 15 分钟？
或者批量更新数据库？
或者使用更少的线程来避免数据库的高争用？
我曾经在SchoolMessenger工作，这是一家为美国大多数公立学校提供通知服务的公司。我们每天发送数百万条通知、短信和电话。我们的方法是让一个非常复杂的 Java 应用程序对通知进行排队，然后逐渐发布它们。然后随着推送的结果进来，这些也排队，并逐渐更新数据库。
我们使用MySQL，但我们也将它与ActiveMQ一起用作持久队列。将所有要完成的任务推入队列，然后工作线程池将执行任务，并将结果推回另一个队列。然后结果读取线程将从队列中读取批量结果并批量更新数据库。
当您设计后端系统来完成大规模工作时，您必须考虑新的方法来构建应用程序以避免出现瓶颈。
作为一名数据库性能和扩展顾问，我多次观察到这条规则：
数据或流量每增长 10 倍，您就应该重新评估您的软件架构。您可能需要重新设计它的某些部分才能在更大的范围内工作。