我负责使用 MariaDB (10.0.21) db.t3.2xlarge 的 API 的维护职责。今天，没有明显的原因（检查了传入 api 的请求数量，没有异常，没有代码更改，没有数据库更改），数据库开始变得缓慢，甚至获取 api 的访问令牌也需要 4-6 时间秒（通常低于 500 毫秒）。 从性能洞察（过去 5 小时）中，我可以看到，对于等待 (AAS) 的数据库加载，大部分等待是“synch/mutex/aria/PAGECACHE::cache_lock”(29.92)，其次是 CPU (13.87) ）并且创建所有这些的 SQL 是从迄今为止运行良好的视图中进行选择的。 图表： https://imgur.com/B5baGzx https://imgur.com/BTU6MAf
我可以在 RDS 上获得的所有图表： https://imgur.com/a/8XO04gZ
选择分析： https://imgur.com/S9uQJpW
我不是数据库专家，但我想其中有些做得不够好。但问题仍然存在……为什么会突然发生这种情况？我们确实对引擎进行了自动小更新，但我检查了一下，过去一周没有更新。 我还检查了数据库的进程列表，并且可以看到 v_links 查询中的选择卡在“发送数据”
我还运行了卡在控制台“发送数据”中的查询，并在 10 毫秒内完成。
我也在 aws 论坛上创建了一个线程：https://forums.aws.amazon.com/thread.jspa?messageID=921037
在与 AWS 支持人员联系并进行长期调查后，我们发现 max_tmp_table 设置为 32，并且由于我们在创建多个临时表的视图上有大量并发请求，因此 32 太小，tmp 表开始溢出到磁盘，因此 aria 缓存等待时间增加直至挂起。
我们在 MariaDB RDS 上的“synch/mutex/aria/PAGECACHE::cache_lock”也遇到了类似的问题。
我们正在获取并排序 20 万多行，更改以下参数对我们有帮助： tmp_表大小 最大堆表大小
进程列表中的“Converting HEAP to Aria”状态也有查询