我有一个非常高的插入率和更新率以及读取率的表。平均每秒插入和更新大约 100 行。每秒大约有 1000 次选择。
该表有大约 1 亿个元组。这是一个关系表，所以它只有大约 5 个字段。三个字段包含键，因此它们被索引。所有字段都是整数。
我正在考虑对数据进行分片，但是，它增加了很多复杂性，但确实提供了速度。另一种选择是使用 innodb。
该数据库在 256GB ssd 的 RAID 1 上运行，具有 32GB 1600mhz 的 RAM 和超频至 4Ghz 的 i7 3770k
数据库在高峰时间不断冻结，其中查询可能高达 200 行被插入或更新，每秒 2500 次选择
你们能指出我应该做什么吗？
分片通常是分配表大小的好主意。负载问题通常应通过复制数据环境来解决。在您的情况下，您的问题是a）巨大的表和b）表级锁定和c）糟糕的硬件。
如果您可以使用表上的一个键作为主键，那么 InnoDB 可能是一个不错的选择，因为他会让您进行行级锁定，这可能会减少您的查询相互等待。一个好的测试可能是将您的表复制到测试服务器并尝试针对他的所有查询，看看性能优势是什么。InnoDB 的资源消耗率高于 MyISAM，因此请记住这一点。
对不起，伙计，但您的硬件无法满足您所需的性能。Twitter 以 2.6k QPS 每秒执行 34 次写入。你不能在做 Twitter 的音量时并认为增强的游戏桌面会减少它。购买带有一些 SSD 驱动器的 15,000 美元的戴尔，您将能够突破 100,000 QPS。你现在正处于大时代。是时候放弃启动设备并为自己准备一台不错的服务器了。你不想分片。升级硬件会更便宜，坦率地说，你需要这样做。
分片非常适合拆分大表。就是这样。
让我把坏事说清楚。开发分片架构很糟糕。你想尽一切可能不分片。升级硬件，购买多台服务器并设置复制，优化你的代码，但看在上帝的份上，不要分片。您远远低于分片的性能线。当你的推力持续 30k+ QPS 时，我们就可以谈分片了。直到那天，NO。
您可以购买一台配备 16 核 5TB Fusion IO 和 256 GB RAM 的中端服务器（3 万美元 Dell PowerEdge），他将带您一路达到 200k QPS。
但是，如果你拒绝听我的话并且无论如何都要分片，那么这就是你需要做的。
分片后，您不希望跨多个分片访问数据。您需要选择一个分区规则，尽可能将您的查询保持在同一个分片上。在分布式数据环境中分发查询（规则 4）非常痛苦。
您的代码需要能够访问所有分片。根据你的分区规则创建一个分片映射，让你的代码知道去哪里获取他想要的数据。
你不想手动决定去哪个分片。写一个为你做的包装器。当你编写代码时，你会感谢自己。
您最终需要平衡分片以保持最佳性能。事先为此做好计划并编写代码，目的是让你有一些 kron 工作来平衡你的分片。
您不可避免地需要打破规则 1。发生这种情况时，您将需要一个查询包装器，它可以从多个分片中提取数据并将其聚合（带入）到一个地方。您拥有的分片越多，就越有可能需要多线程。在我的商店中，我们称之为分布式查询（即在多个分片上运行的查询）。
坏消息：没有用于执行分布式查询和聚合结果的代码。Apache Hadoop 尝试过，但他很糟糕。HiveDB 也是如此。一个好的查询分发器很难架构、难以编写、难以优化。这是公司每年要处理的数十亿美元的问题。我不拉屎你，但如果你想出一个很好的包装器来跨分片分布查询，支持排序+限制子句并很好地扩展，你可能一夜之间成为百万富翁。卖30万美元？你门外有一英里长的队伍。
我的观点是分片很难而且很昂贵。这需要大量的工作，并且您想尽一切可能不进行分片。如果必须，请遵守规则。