请帮忙！我们几个月来一直在努力解决这个问题。本周，我们将 RDS 实例升级到性能最高的实例，尽管发生这种情况的次数减少了，但我们的数据库仍然突然达到 100%。它突然出现。有时是凌晨 2 点，有时是中午。
我已经排除了 DOS 的可能性——我们的页面访问日志流量正常
我已经排除了 memcached 突然死亡的可能性（命中和未命中继续正常）。
当我们遇到问题时，SHOW PROCESSLIST 报告队列中有大约 500 个查询。如果我关闭它们或重新启动服务器，它们就会不断回来，然后最终不知从何而来，我们的服务器恢复正常。有时长达 3 个小时。
当服务器最终恢复正常时，我们的性能不佳的查询需要 0.02 秒才能执行，但是当我们处于 100% CPU 物理阶段时，这些查询永远不会完成执行。
请帮忙！有人知道 MYSQL 查询优化吗？服务器会不会突然决定使用不同的索引，从而陷入困境？
答案1
http://www.mysqlperformanceblog.com/2010/09/10/cache-miss-storm/
事实证明，我们的问题是缓存风暴未命中，又称为未命中踩踏。
我们通过实现 50% 的缓存过期时间解决了这个问题。基本上，对于 memcache 中的每个项目，我们都会使用类似的键加上附加的“重新生成”字符串来创建第二个缓存项目。此项目在典型缓存过期时间的 50% 时过期，向下一个请求表明我们即将过期缓存，并且下一个请求将需要尝试重新生成缓存。
这可以防止用户同时尝试重新生成缓存的风暴，并确保我们的缓存有最好的机会始终保持新鲜！
很难追踪！