我必须将大量数据（约 1 亿行，约 100 次）导入 MySQL 数据库。目前，这些数据存储在我的硬盘驱动器上，而导入的瓶颈似乎是硬盘驱动器的写入速度。
我听说 SSD 不喜欢大量连续写入，而且这很容易损坏它们。你怎么看？这真的是现代 SSD 的问题吗？
答案1
对此确实没有一个简单的答案。
SSD 并不关心连续写入，而是关心特定扇区被覆盖的次数。SSD 刚推出时，SQL 之类的东西是个坏词，因为操作系统通常将驱动器视为传统 HDD，并且故障非常频繁。
从那时起，驱动器变得更大、更便宜、更可靠、读/写次数更多，操作系统也变得更智能。
SQL 中的 SSD 不仅很常见，而且经常受到鼓励。请随意阅读DBA 姊妹网站。
我的想法是这样做，假设 SQL 服务器正确构建并具有冗余磁盘。如果没有，那么无论如何最终都会失败。
答案2
读取很好，并且 SSD 可以读取其位而不会产生任何不利影响。
写入是另一回事。清除一个位会影响该位的完整性，之后很多连续写入后，该位将完全停止接受新的写入。但是仍然可以读取。
我只想说，新企业级硬盘的写入限制非常大。以三星新款 845DC Pro 为例。保修期内，它每天可写入 10 次，保修期为 5 年。我想它会达到这个数字的两倍。具体来说，800 GB 型号在 5 年内写入了 14,600 TB。
或者每年 2920 TB，
或者每天 8 TB，五年。
给我看看有保修的硬盘，能覆盖这么多的使用量。我甚至不确定你一天能不能往硬盘上写入 8 TB 的数据：- (50 MB/s 平均吞吐量 * 60 (秒) * 60 (分钟) * 24 (小时) = 4,320,000 MB/天 = 4.32 TB/天) 事实证明你做不到（在普通硬盘上）。
只要你使用基于 V-NAND（或同样耐用的 SLC）的驱动器，而不是基于 TLC 或不良 MLC 闪存的驱动器，就应该没问题。无论如何，袭击备份是您的好朋友，这是有原因的。至少如果 SSD 写入限制确实成为问题，您仍然可以读取存储在错误位中的数据。
SSD 运行成本更低、散热更凉爽、更安静，企业型号尤其能抵抗电源问题。不再担心磁头碰撞，当然，巨大的提高您的数据库访问需求的性能。
答案3
写入 SSD 并不一定是坏事。写入和重写单个块才是坏事。这意味着如果你写入一个文件，删除它然后再次写入，或者一遍又一遍地对文件进行少量更改。这会对 SSD 造成磨损。数据库肯定属于这一类。
然而根据本文，PB 级的数据已被写入 SSD 并且仍然可以运行。这可能是由于磨损均衡：
磨损均衡技术试图通过排列数据来解决这些限制，使擦除和重写均匀分布在介质上。这样，就不会有单个擦除块因写入次数集中而过早失效。
在您的特定情况下，我会将数据库驻留在 SSD 上以提高速度，但每天备份。您也可以考虑在RAID 1阵列也是如此。两个 SSD 同时发生故障的可能性很低。
注意：RAID 阵列不是备份！！！！无论您是否使用 RAID 阵列，都要进行备份。无论您是否使用 SSD，都要进行备份。
答案4
这没问题。
首先，SSD 在过去几年中得到了很大的改进。过度配置和磨损均衡（以及少量的 TRIM 命令，虽然不适用于您的情况）使它们非常适合用作重型通用磁盘。我在我的开发 PC 上只使用 SSD（它经常进行大量编译），甚至没有接近擦除周期数。
此外，该声明：
SSD 不喜欢大量连续写入，这往往会损坏它们
是完全错误的。事实恰恰相反，频繁的小写入，如果有的话，可能会对SSD造成损坏。
与传统硬盘不同，SSD（或者更确切地说是内部基于 NAND 的闪存）在物理上以大块的形式组织，这些大块在逻辑上包含多个扇区。典型的块大小为 512kB，而扇区（文件系统使用的单位）传统上为 1kB（可能有不同的值，二十年前 512B 很常见）。512kB
块可以做三件事。可以读取、可以对部分或全部进行编程（= 写入），并且可以擦除整个块。擦除是有问题的，因为擦除次数有限，并且只能擦除整个块。
因此，大容量写入对 SSD 非常友好，而小容量写入则不然。
对于小规模写入，控制器必须读入一个块，修改副本，擦除另一个块，然后对其进行编程。如果没有缓存，在最坏的情况下，您需要擦除 512,000 个块才能写入 512 千字节。在最佳情况下（大规模、连续写入），您需要执行 1 次擦除。
向 MySQL 数据库执行导入操作与执行多个单独的插入查询有很大不同。引擎能够将大量写入（数据和索引）合并在一起，并且无需在每对插入之间进行同步。这相当于一种更适合 SSD 的写入模式。