我经常听说有人想为他们的数据库安装 SSD。但人们往往不想将他们的表放在 SSD 上，而是想将他们的数据库日志放在 SSD 上，而将他们的表放在普通硬盘上。
但为什么有人想这么做呢？
日志使用顺序写入。而 SSD 的顺序 IO 速度并不比常规磁盘快。因此将日志放在 SSD 上不会带来任何性能提升。
SSD 比常规磁盘快得多的一个领域是随机 IO。那么明智的做法难道不应该是将表放在 SSD 上，而将日志留在常规磁盘上吗？
我是否遗漏了什么？
答案1
是的，与整个数据库相比，事务日志通常*具有恒定但非常低的吞吐量。但吞吐量绝对是第一要务，当它延迟时，对数据库的所有更新都必须等待。将日志写入镜像，甚至 RAID5 在经济上是有利的，但前提是您可以保持写入顺序。如果您与其他任何东西（无论是数据文件、索引还是色情电影集合）共享磁盘，那么您的性能就会面临风险。
在较大的环境中，通常情况下多种的数据库实例集中在同一个存储上。当然，您不想将日志放在同一组驱动器上，因为多个连续写入组合起来实际上会形成一个大的类似随机的写入。
一种选择是为每个日志序列专用一个单独的镜像（两个磁盘）。但另一种选择（在某些情况下经济可行）是保持简单，并为所有日志文件使用单个 SSD，这样您就有了单独的设备和数据路径，并具有良好的随机性能。实际上，多个日志中的任何一个都不会延迟任何数据库。我见过这样的设置，但我不推荐它（SSD 的非易失性对我来说太脆弱了）。
[*] - 一些引擎将重做日志与撤消信息混合在一起，使事情变得复杂（例如 MS SQL Server）
答案2
您总是希望将日志刷新到非易失性存储器（盘片或闪存）中，而基于 DRAM 的 SSD 的写入速度比硬盘更快。
为了提高性能，事务日志几乎总是应该缓存在内存中，因此读取速度实际上并不重要。
因此，您应该能够通过将事务日志放在 SSD 上来获得更高的写入吞吐量。
顺便说一句，我曾经尝试将 MySQL innodb 事务日志放在 tmpfs 上，与磁盘相比，性能提高了 10-20%。