SSD上的大量MySQL数据导入会损坏它吗？

我必须将大量数据（约1亿行，~100次）导入MySQL数据库。目前，它存储在我的硬盘驱动器上，导入的瓶颈似乎是硬盘驱动器的写入速度。

我听说SSD不喜欢大量连续写入，并且它往往会损坏它们。你怎么看？这真的是现代固态硬盘的问题吗？

这真的不是一个直截了当的答案。

SSD不关心连续写入，也不关心任何特定扇区被覆盖的次数。当SSD首次出现时，像SQL这样的东西是一个坏词，因为操作系统通常像传统硬盘驱动器一样对待驱动器，故障非常频繁。

从那时起，驱动器变得更大，更便宜，更可靠，意味着更多读/写，操作系统变得更加智能。

SQL中的SSD不仅常见，而且经常受到鼓励。随意浏览DBA姐妹网站。

我的想法是这样做，假设SQL服务器是使用冗余磁盘正确构建的。如果没有，那么无论如何最终都会失败。

读取很好，SSD可以读取它们的位而没有任何不利影响。

写作是另一回事。清除一点会影响该位的完整性，并且在大量顺序写入之后，该位将完全停止接受新写入。然而，它仍然可以阅读。

我只想说新企业驱动器的写入限制是巨大的。以三星新推出的845DC Pro为例。在保修期内，5年内每天可以进行10次驱动器写入。我想它会做两倍的数字。把它归结为数字，这是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闪存的驱动器，您应该没问题。无论如何，RAID 10和备份是你的朋友有一个原因。至少如果SSD写入限制确实成为问题，您仍然可以读取存储在故障位中的数据。

固态硬盘的运行成本也更低，更酷，更安静，企业型号特别耐电力问题。没有更多的头部崩溃担心，当然，您的数据库访问需求的巨大性能提升。

写入SSD并不一定是坏事。这是单个块的写入和重写，这很糟糕。这意味着如果您编写文件删除它然后再次写入，或一遍又一遍地对文件进行少量更改。这会导致SSD的磨损。数据库绝对适合这一类。

但是根据这篇文章，已经有数PB的数据被写入SSD并且仍然可以运行。这可能是由于磨损均衡的进步：

磨损均衡尝试通过排列数据来解决这些限制，以便在介质上均匀地分配擦除和重写。以这种方式，由于高写入周期的集中，没有单个擦除块过早地失效。

在您的特定情况下，我会将数据库驻留在SSD上以提高速度，但每天都会备份。您也可以考虑在RAID 1阵列中获得两个SSD 。两个SSD同时出现故障的可能性很低。

注意：RAID阵列不是备份!!!! 无论您是否使用RAID阵列，都要备份。无论您是否使用SSD，都要备份。

我们假设您的导入不涉及更新，也没有删除。所以你要做所有的插入。这应该只是将新数据写入事务日志。

这意味着随着数据的添加，它总是被写入新的扇区。可能会有一些缓冲/交换多次被搅拌/写入，但忽略这一点，所有这些插入理论上会导致每个扇区不超过一次写入。根据MySQL的实现方式以及您正在执行的批量插入，当事务日志集成到主数据文件中时，您可能会在以后生成第二组写入（我对不同的数据库引擎有所了解） ，并假设MySQL在刷新事务日志方面有些相似）。

重点是，你不是在“搅拌”SSD。也就是说，你没有进行大量的修改/移动/删除/等等。这可能会多次重写相同的扇区。所以你基本上只会为每个扇区生成非常少量的写入，这才是真正重要的。

假设您没有完全填满SSD，那么应该有足够的空间用于那些正在搅拌的热点（例如缓冲器/交换），以通过磨损均衡算法最小化磨损。

（索引可能是另一回事。由于许多数据库中的聚簇索引在插入数据时涉及很多修改。通常在数据仓库环境中执行大型isnerts时，在批量导入期间关闭索引然后更新它们。）

这不是问题。

首先，SSD在过去几年中有了很大的改进。过度配置和磨损均衡（以及少量，TRIM命令，虽然在您的情况下不适用）使它们非常适合作为重型通用磁盘。我没有在我的开发PC上使用除SSD以外的任何东西（它经常进行大量编译），甚至没有在擦除周期数附近。

此外，这句话：

SSD不喜欢大规模连续写入，并且它往往会损坏它们

是完全错误的。情况恰恰相反，频繁的小写操作（如果有的话）可能会对SSD造成损害。

与传统硬盘不同，SSD（或者更确切地说是基于NAND的闪存）在物理上组织成大块，逻辑上包含多个扇区。典型的块大小是512kB，而扇区（文件系统使用的单位）传统上是1kB（不同的值是可能的，二十年前512B是常见的）。
使用512kB块可以完成三件事。它可以被读取，部分或全部可以被编程（=写入），并且可以擦除整个部分。擦除是有问题的，因为擦除周期数量有限，并且您只能擦除完整的块。

因此，大写非常适合SSD，而小写不是。

在小写入的情况下，控制器必须读取块，修改副本，擦除不同的块并对其进行编程。如果没有缓存，在最糟糕的情况下，您需要擦除512.000块才能写入512 KB。在最好的情况下（大型连续写入），您需要完成1次擦除。

导入MySQL数据库与执行许多单独的插入查询有很大不同。引擎能够将大量写入（数据和索引）合并在一起，并且不需要在每对插入之间进行同步。这相当于一个更友好的SSD写入模式。

SSD不喜欢它。如果您将最大写入速度保持5到10年（每天24小时，每周7天），那么最终可能会出现SSD故障。

OFC。5年后，大多数服务器都达到了经济效益。

免责声明：
不要尝试使用第一代SSD。那些不那么健壮的人。

如果您真的对确定详细信息感兴趣，那么您需要回答以下问题：

平均每行有多少字节？

如果你可以告诉我有10列，每列是varchar（100），编码是UTF-8那么我可以猜测在最坏的情况下你每行有4,000个字节的数据，并添加更多的字节元数据所以说4,200个字节？

你的酷刑SQL计算4,200 x 100 x 100,000,000 = 42,000,000,000,000 bytes写入磁盘的数据

42,000,000,000,000 / 1000 = 42,000,000,000 KB

42,000,000,000 / 1000 = 42,000,000 MB

42,000,000 / 1000 = 42,000 GB

42,000 / 1000 = 42 TB

在这种理论上最糟糕的情况下，您将向磁盘写入42 TB

根据@KronoS提供的这篇文章，你应该对你的酷刑SQL大约25回合好。

正如这篇关于SSD的文章的海报所说，真正有害的是一次又一次地编写小块数据。

• 位存储在{1,2,3}位单元中。这些寿命有限。
• 单元格被分组为[2-16] KB页面（最小可写单元）
• 页面分为（128-256页）块（最小可擦除单位）
• 对于要重写的页面，它 - 以及它的整个块---需要先被删除

这就是建议的原因

• 从不写一页不到一页，
• 缓冲小写，和
• 单独的读写请求
• “大型单线程写入比许多小型并发写入更好”

所以，一次真正的大量似乎更好。