Ric*_*mes 3 mysql storage disk-structures
介绍 我从我之前的问题单驱动器与多驱动器中得出了这个问题
从一位非常有帮助的成员RolandoMySQLDBA那里得到非常详细的回答并了解到多驱动器在某些情况下可以提供很大帮助的事实之后。我开始为我的设置寻找多驱动器，与我发现的相比，这只是一点点。
更多信息 我发现了相当大的存储，比如
http://www.newegg.com/Product/Product.aspx?Item=N82E16811152212
虽然有些视频显示此类设备的写入速度甚至达到 GB
真正的问题 假设有足够的 RAM 来保存索引，MySQL 或其他开源 RDBMS（不是像 Oracle 这样的企业级 RDBMS，因为它在 SAN 上运行很常见）可以轻松地在这些野兽上运行吗？
因为它们包含真正的多驱动器设置，并且有几十个磁头可用。
我相信它不会那么简单，因为如果它有那么简单，那么为什么大多数企业设置使用商品服务器。那么，使用这些极限存储解决方案会面临哪些问题呢？
所要做的就是运行这些查询：
我的ISAM
SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.4999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1))
recommended_key_buffer_size FROM
(SELECT LEAST(POWER(2,32),KBS1) KBS
FROM (SELECT SUM(index_length) KBS1
FROM information_schema.tables
WHERE engine='MyISAM' AND
table_schema NOT IN ('information_schema','mysql')) AA ) A,
(SELECT 2 PowerOf1024) B;
数据库
SELECT CONCAT(ROUND(KBS/POWER(1024,
IF(PowerOf1024<0,0,IF(PowerOf1024>3,0,PowerOf1024)))+0.49999),
SUBSTR(' KMG',IF(PowerOf1024<0,0,
IF(PowerOf1024>3,0,PowerOf1024))+1,1)) recommended_innodb_buffer_pool_size
FROM (SELECT SUM(data_length+index_length) KBS FROM information_schema.tables
WHERE engine='InnoDB') A,
(SELECT 2 PowerOf1024) B;
这些将为现有 MyISAM 的 MyISAM 密钥缓存和 InnoDB 数据和索引的 InnoDB 缓冲池推荐正确的大小。
在运行这些 SQL 查询建议缓冲区大小时，人为因素仍然必须发挥作用。我们必须根据硬件和经常访问的数据来计划数据使用。我们还必须问：在推荐的缓冲区数量中，我的工作集有多少实际驻留在内存中？
如果您将 MySQL 配置为将 75% 的 RAM 用于 InnoDB，即使在专用的 MySQL 服务器上，操作系统也会忙于分页到磁盘。仅仅因为 MySQL 可以为缓冲区大小使用大量数字并不意味着可以突破限制。两个有两个基本的存储引擎需要考虑。
商品硬件的使用仅仅展示了 MySQL 的可配置性，并且效果显着。除非您使用 32 位 RHEL（如果您是，请立即停止使用它，喝点咖啡，升级），在存储野兽中提高缓冲区大小是值得信赖的。
例如，我的雇主有一个客户端，有 3 个数据库服务器，仅用于 MySQL。每个都有 192GB 的 RAM，其中 162GB 是 InnoDB 缓冲池。工作集实际上是 170GB。虽然进行了一些交换和分页，但数据库性能令人震惊。操作系统本身有大约 30GB 的 RAM（临时表有 16GB 的 RAM 磁盘）。我敢肯定，与科莫多龙大小的数据库服务器相比，这些服务器只是小蜥蜴。如果配置正确，MySQL 可以胜任这项任务。
请记住，InnoDB 设置了自己的制衡机制，因为当前的源代码将 InnoDB 日志文件限制为 4GB。之所以如此，是因为 InnoDB 最初的设计考虑了商品硬件。鉴于此，无论存储野兽的硬件设置和您选择运行的 MySQL 版本如何，ACID 事务吞吐量都可能成为瓶颈。
结论
可以对 Big Beefy DB 服务器进行限制。您应该始终在内存、交换空间、工作数据集和预期事务数量方面考虑操作系统。