我有一个包含 300 万条记录的数据库表。一个 java 线程从表中读取 10,000 条记录并对其进行处理。处理后跳转到下一个 10,000，依此类推。为了加快速度，我有 25 个线程执行相同的任务（读取 + 处理），然后我有 4 个物理服务器运行相同的 java 程序。所以有效地我有 100 个线程做同样的工作（阅读 + 处理）。
我使用的策略是拥有一个 sql 过程，该过程执行抓取下 10,000 条记录并将它们标记为由特定线程处理的工作。但是，我注意到线程似乎正在等待一段时间，试图调用该过程并获得响应。我可以使用什么其他策略来加快数据选择的过程。
我的数据库服务器是mysql，编程语言是java
处理这种情况的惯用方式是生产者-消费者设计模式。在 Java 领域实现它的惯用方式是使用jms。
本质上，您需要一台主服务器读取记录并将它们推送到 JMS 队列。然后，您将有任意数量的消费者从该队列中读取并相互竞争。由您决定如何详细实现这一点：您要发送带有完整记录的消息还是只发送 ID？一条消息中的所有 10000 条记录或每条消息的记录？
另一种方法是map-reduce，看看hadoop。但是学习曲线有点陡峭。
对我来说，这听起来像是 Hadoop 的工作。
我怀疑您主要是与此方案绑定的数据库 IO。如果您正在尝试提高系统的性能，如果可以的话，我建议您将数据分区到多个数据库服务器上。 MySQL 有一些我没有经验的分区模式。如果您自己进行分区，它可能会给数据库模式增加很多复杂性，并且您必须使用散列机制添加某种路由层，以便以某种方式在多个分区中划分您的记录。但我怀疑你会获得显着的速度提升，并且你的线程不会等待那么多。
如果您无法对数据进行分区，那么我怀疑将数据库移动到SSD 内存驱动器将是一个巨大的胜利——任何可以提高这些分区上 IO 速率的方法。由于固有的性能问题，请远离 RAID5。如果您需要一个可靠的文件系统，那么镜像或RAID10将具有更好的性能，而RAID50也是大分区的一个选项。
最后，您可能会发现，如果您的数据库 IO 总线受到干扰，您的应用程序会以更少的线程执行得更好。这取决于许多因素，包括并发查询、数据库布局等。您可以尝试降低每个客户端的线程数，看看是否会有所不同。然而，影响可能很小。