多租户Laravel应用的Elastic Beanstalk扩缩容方案咨询

一、补充监控手段 #

• MySQL内部排查：执行SHOW PROCESSLIST查看并发查询的锁等待、临时表生成情况；开启慢查询日志（配置slow_query_log=1、long_query_time=2），定位报表查询的具体瓶颈，比如是否存在排序溢出磁盘、表级锁阻塞。
• RDS高级监控：启用RDS Performance Insights，它能直观展示SQL语句的等待时间占比，帮你确认是否存在IO瓶颈（虽然CPU内存指标正常，但大数据量查询可能引发磁盘读性能瓶颈）。
• 应用层日志检查：查看Laravel的storage/logs/laravel.log，确认超时是数据库响应慢还是应用层连接池耗尽；同时检查PHP-FPM进程数配置，是否因并发查询占满进程导致系统停滞。

二、RDS实例选型方案 #

• 放弃突发型实例：t3.micro的CPU积分机制在持续并发查询场景下会快速耗尽积分，导致CPU强制降频——你看到的20%CPU峰值可能是降频后的表现，并非真实负载上限。不建议升级到更大的t3系列，因为同样存在积分限制。
• 优先选择通用型m类实例：比如m5.large，这类实例提供稳定的CPU性能，无积分限制，适合持续的复杂查询场景。如果预算紧张，可临时开启t3实例的无限CPU模式（CPUCredits=unlimited），但长期来看m类实例的稳定性更有保障。
• 先优化内存配置：当前RDS可用内存剩余40-50%，可先调整innodb_buffer_pool_size至可用内存的70-80%，让更多热点数据缓存到内存，减少磁盘IO——这可能是解决报表查询卡顿的低成本关键优化。

三、Multi-AZ的实际作用 #

Multi-AZ是高可用方案，而非性能优化手段。它仅在主实例故障时自动切换到备用AZ，正常情况下所有读写请求仍由主实例处理，不会提升查询性能。当前性能问题无需启用Multi-AZ，除非你需要异地容灾保障。

四、额外优化方向 #

• 报表预计算：将高频报表的统计结果提前计算到汇总表（比如每日凌晨通过Laravel任务生成），避免实时关联数百万条数据。
• Laravel查询优化：用chunk()分批处理大结果集，避免一次性加载大量数据到内存；针对多租户场景配置隔离性的查询缓存。
• 连接池调整：修改config/database.php中的数据库连接池配置，合理设置最大连接数，避免并发查询时连接耗尽导致请求等待。

内容的提问来源于stack exchange，提问作者Ben CLS