我正在尝试购买一个新的服务器来运行 MySQL 服务器。这个新服务器将成为我主机的从属。但是，该服务器将专门用于报告“大量读取和复杂查询”。
现在我正在考虑投资固态硬盘，但想知道它是否真的物有所值。SSD 和 SATA 7200 硬盘的差价约为 1500 美元，而 SSD 的磁盘空间较少。如果我确实投资SSD，速度会很明显吗？
我可以购买 4 个（500GB SATA 7200）比购买 2 个（500GB SSD）少 1500 美元
你能帮我做决定看看是否值得升级吗？
我想再提一提的是，我没有使用，query_cache所以会有很多磁盘读取。
该服务器将有 32GB 的 RAM 并将运行 Ubuntu 12.04
我今天才听说罗伯特·马丁，他似乎是软件界的一个显赫人物，所以我的头衔并不是说看起来像是一个点击诱饵或我在他嘴里说的话，但这只是我是如何以我有限的经验和理解来解释我从他那里听到的。
我在看一个视频今天（关于软件架构），Robert C. Martin 的演讲，在视频的后半部分，数据库的主题是主要焦点。
根据我对他所说的话的理解，他似乎是在说 SSD 会降低数据库的实用性（相当大）。
解释我是如何得出这种解释的：
他讨论了如何使用 HDD/旋转磁盘，检索数据很慢。然而，他指出，现在我们使用固态硬盘。他从“RAM 即将到来”开始，然后继续提到 RAM 磁盘，但随后说他不能称之为 RAM 磁盘，因此只说 RAM。所以对于 RAM，我们不需要索引，因为每个字节都需要相同的时间来获取。（这一段是我转述的）
因此，他建议 RAM（如在计算机内存中）作为 DB 的替代品（正如我将他的声明解释为那样）是没有意义的，因为这就像说所有记录在应用程序的生命周期内都在内存中处理（除非您根据需要从磁盘文件中提取）
所以，我用 RAM 来思考，他的意思是 SSD。因此，在这种情况下，他是说 SSD 会降低数据库的实用性。他甚至说：“如果我是甲骨文，我会害怕。我存在的根本原因正在消失。”
根据我对 SSD 的一点了解，与 HDD 不同，HDD 是O(n)寻道时间（我认为），SSD 接近O(1)或几乎是随机的。所以，他的建议对我来说很有趣，因为我从来没有这样想过。几年前我第一次接触数据库时，当一位教授描述与常规文件系统相比的好处时，我得出的结论是数据库的主要作用本质上是一个非常索引的文件系统（以及优化、缓存、并发访问、等），因此，如果 SSD 中不需要索引，这种类型确实会使数据库变得不那么有用。
尽管如此，以我是新手的开头，我发现很难相信它们变得不那么有用了，因为每个人仍然使用 DB 作为其应用程序的主要点，而不是纯粹的文件系统，并且感觉好像他过于简单化了数据库的作用。
注意：我确实一直看到最后，以确保他没有说不同的话。
供参考：42 : 22是整个数据库主题出现的时候， 43:52是他开始说“为什么我们甚至有数据库”的时候
这个答案确实说 SSD 大大加快了数据库的速度。 这个问题询问优化是如何改变的。
对于TL;DR我的问题，SSD 在服务器市场（无论是即将到来还是已经发生）的广泛使用是否会降低数据库的实用性？
似乎演示者试图传达的是，使用 SSD，人们可以将数据存储在磁盘上，而不必担心检索数据会像使用较旧的 HDD 一样慢，与使用 SSD 一样，寻道时间接近O(1)（我认为）。因此，如果这是真的，那么假设它会失去它所拥有的优势之一：索引，因为拥有索引以加快查找时间的优势已经不复存在。
我有一个 1.4TB 的 SQL Server 数据库，它在磁盘 I/O 方面遇到了很大的困难。我们已经在服务器中安装了一个新的 SSD 阵列，它将解决我们所有的问题，我们只是在讨论移动数据库的最佳方式。理想情况下，如果我们可以在不停机的情况下完成这项工作，那就最好了。但是，如果要在两天性能不佳（例如复制数据时）与两小时停机时间之间进行选择，则后者可能更可取。
到目前为止，我们提出的解决方案是：
简单的复制。使数据库脱机，复制文件，更改 SQL Server 中的位置并使其重新联机。粗略的数字估计这最多需要五个小时，这不是真的可以接受，但这是最简单的解决方案。
块级复制。使用类似 rsync 的实用程序，我们在数据库启动时在后台复制文件。当我们准备好迁移时，我们使数据库脱机，使用此实用程序进行差异复制，然后将 SQL 服务器指向新文件并使其联机。这里的时间未知。我们不知道对 1.4TB 进行差异分析并复制它需要多长时间。我们的另一个担忧是块级副本会使文件处于 SQL Server 无法读取的某种状态，我们将浪费时间。
SQL 迁移。在新磁盘上创建一个新的 1.4TB SQL 数据文件并禁用所有其他文件的自动增长。然后依次对所有其他数据文件运行 DBBC SHRINKFILE(-file_name-, EMPTYFILE)。处理完所有数据后，我将在某个时间点使用预定窗口将 MDF 文件移至 SSD 并删除其他未使用的文件。我喜欢这个，因为它最大限度地减少了停机时间。但我不知道这需要多长时间，以及它在发生时是否会导致性能下降。
我们没有任何类型的负载和性能环境来测试这个。我可以验证这些策略是否适用于我们的暂存环境，但不是影响，而不是性能。
我阅读了这篇关于 SSD 上 PostgreSQL 性能的文章：
这两个配置似乎很重要random_page_costvsseq_page_cost
由于两个参数都需要匹配特定的硬件，我想知道是否可以自动检测匹配值？
更新
我脑子里有这些步骤：
我正在一个新的 SSD 阵列上进行计时试验，该阵列同时运行 SQLIO 测试和 DB 还原和 DBCC CHECKDB 调用的实际工作负载。我发现我的 SQLIO 批处理生成的 IOPS 和吞吐量与我观察到的工作负载之间存在重大差异，工作负载仅请求我使用 SQLIO 能够观察到的一小部分，通常在 5,000 IOPS 范围内并产生不超过 400 MB/s 的吞吐量。
如果硬件有足够的容量来处理负载，那么 DBCC CHECKDB 将消耗多少资源事件是否存在固有限制？我可以尝试哪些设置来扩展 DBCC CHECKDB 对 CPU 和磁盘资源的使用？
以下是具体...
从 systeminfo
OS Name: Microsoft Windows Server 2012 R2 Standard
OS Version: 6.3.9600 N/A Build 9600
System Manufacturer: HP
System Model: ProLiant DL580 G7
System Type: x64-based PC
Processor(s): 4 Processor(s) Installed.
[01]: Intel64 Family 6 Model 46 Stepping 6 GenuineIntel ~1042 Mhz
Total Physical Memory: 131,062 MB …
在配置我们的新服务器（IBM X3650M4、2x Intel Xeon E5-2620、64G RAM、RAID 10（4x 240G SSD））时，我们遇到了一个奇怪的问题。我们试图将转储 ( mydumper) 从我们的（旧）生产环境导入到我们的新环境中，但我们几乎无法这样做。
转储为47G（压缩），+/- 4500 个表，最大的表为 7.1G（54285914 行）、2.2G、1.7G 和 1.7G。
我们试图myloader用 12 个（或 8 个）线程运行，但大多数时候都失败了。几分钟后，myloader遇到大桌子和摊位。一些工具显示没有更多活动（htop没有 CPU 负载，iostat没有写入或读取），mytop显示 4 个（长时间运行）永远不会完成的查询，大多数innotop屏幕都被冻结（因为SHOW INNODB STATUS不再返回任何结果）。当我尝试重新启动时mysql也失败了，因为mysql无法杀死多个线程。唯一的补救方法是使用killall -9 mysqld mysql.
我们正在使用以下 mysql 配置：
# cat /etc/mysql/my.cnf
# Ansible managed
[client]
port = 3306
socket = /var/run/mysqld/mysqld.sock
ssl_cert = /etc/mysql/client-cert.pem
ssl_key = …我有一个将本地 SSD 用于 tempDB 的生产部署。我在 RAID1 配置中有 2 个 SSD。我看到平均读取时间为 1-2 毫秒，但所有四个 tempdb 数据文件的平均写入时间都显示为 1377 毫秒。
每个 tempdb 数据文件为 2GB，具有 1GB 的增长设置（自 5 个月前部署以来没有增长）
tempdb 日志显示平均读取时间为 67 毫秒，平均写入时间为 215 毫秒。
SSD 是三星 840 专业版。
以下代码是我用来获取统计信息的代码
SELECT a.database_Id,
a.file_id,
db_name(a.database_id) AS dbname,
b.name,
db_file_type = CASE
WHEN a.file_id = 2 THEN 'Log'
ELSE 'Data'
END,
UPPER(SUBSTRING(b.physical_name, 1, 2)) AS disk_location,
a.io_stall,
a.io_stall_read_ms / Case When a.num_of_reads = 0 Then 1 Else a.num_of_reads end AvgRead,
a.io_stall_write_ms / Case When a.num_of_writes = 0 …我有数据库，我的任务是将两个数据库 DBName1 和 DBName2 移动到 SSD，而我在 SSD 上只有有限的空间来容纳这些数据库。出于显而易见的原因，我不想缩小日志或数据文件，Brent 或 Paul 可能会去疯狂的。我注意到数据库没有增长太多，它使用的是最初分配的一部分。日志文件的初始大小分别为当前大小 41GB 和 147GB。当我检查 DBCC SQLPERF(logspace) 时，我发现 41017.3 MB 日志大小和 0.4339632 % 日志空间使用 % 和状态 0 147474MB 日志大小和 0.08165617 日志空间使用 % 和状态 0。
Database Name Log Size (MB) Log Space Used (%) Status
DBNAme1 41017.3 0.4339632 0
DBName2 147474 0.08165617 0
Database files(Sp_Spaceused)
database_name database_size unallocated space
DBName1 126294.31 MB 67443.73 MB
reserved data index_size unused
18261272 KB 8347376 KB 9677480 KB 236416 KB
database_name database_size unallocated space
DBName2 271075.31 …据我所知，SSD 往往具有自然的 4K 扇区大小，但是将 Windows 簇大小格式化为 64K 会有好处吗？这是旋转 Rust 的好习惯，但是它与 SSD 相关吗？
最近，我听说我不应该在 SSD 驱动器上托管我的 MySQL 数据库，因为磁盘故障和数据丢失的可能性很大。
鉴于我的数据库中 20% 的查询是 INSERT 和 UPDATE，这里是我的问题：
ssd ×10
performance ×4
sql-server ×4
mysql ×3
hardware ×2
tempdb ×2
dbcc ×1
import ×1
index ×1
innodb ×1
postgresql ×1
shrink ×1