Azure MySQL单服务器内存不足报错排查求助（内存使用率偏低）

• 拥有一台Azure Database for MySQL单服务器实例，包含12个极小表（每个表≤10行数据）
• 仅由C#应用中的自动化测试进行查询，每日运行约20000次，执行简单查询，部分测试会创建临时表后立即删除
• 服务器规格：Basic，2 vCore，50 GB，MySQL版本为8.0

近期出现大量测试失败，报错信息如下：

• Out of memory; check if mysqld or some other process uses all available memory; if not, you may have to use 'ulimit' to allow mysqld to use more memory or you can add more swap space
• An error occurred when accessing your server. Please retry or report your issues.
• Failed to read the result set ---> System.IO.IOException: Unable to read data from the transport connection: Connection reset by peer

查看过去7天的内存使用率，平均约26%，最高仅略超30%，看似无异常：

已查阅Azure官方文档排查内存问题，但未找到适配当前场景的方案。因数据库及表规模极小，仅执行简单查询，希望在扩容前明确问题原因，寻求排查思路。

1. 捕捉瞬时内存峰值 #

监控的平均/最高值无法反映短时间内的内存突增，尤其是自动化测试批量并发执行场景：

• 查看Azure监控中内存使用率的分钟级/秒级粒度数据，确认是否存在瞬间冲高到阈值的情况
• 启用MySQL performance_schema，查询memory_summary_global_by_event_name表，跟踪内存分配的瞬时变化

2. 排查临时表内存消耗 #

即使临时表创建后立即删除，高并发下内存临时表的创建可能瞬间占用大量内存：

• 执行SHOW GLOBAL STATUS LIKE 'Created_tmp%';，对比Created_tmp_tables（内存临时表）和Created_tmp_disk_tables（磁盘临时表）的创建频率
• 检查tmp_table_size和max_heap_table_size配置，若值过大，高并发场景下内存临时表的累积可能触发OOM

3. 检查连接数与并发瓶颈 #

自动化测试的高并发连接可能导致内存占用激增：

• 执行SHOW GLOBAL STATUS LIKE 'Threads_%';，查看Threads_connected（总连接数）和Threads_running（活跃连接数）的峰值
• 检查C#应用的连接池配置，确认是否存在连接泄漏（比如未正确释放数据库连接），导致连接数持续累积

4. 核对MySQL内存配置与实例配额 #

Azure Database for MySQL Basic层有固定内存配额，即使监控使用率低，mysqld进程可能因内部配置触发限制：

• 执行SHOW VARIABLES LIKE '%memory%';，重点检查innodb_buffer_pool_size、sort_buffer_size、join_buffer_size等参数
• 对比Basic层2 vCore实例的默认内存配额，确认是否存在参数配置超出配额的情况

5. 排查网络连接重置问题 #

连接重置报错可能与网络或连接超时相关，需同步排查：

• 查看Azure监控中的网络吞吐量、连接成功率指标，确认是否存在网络瓶颈或丢包
• 检查MySQL的wait_timeout和interactive_timeout配置，是否因连接闲置过久被服务器主动断开，导致应用端报错

内容的提问来源于stack exchange，提问作者Uri Shapira