我在一个包含 250 000 行的 Amazon RDS 实例上有一个 MySQL 表。当我尝试
SELECT * FROM tableName
没有任何条件（仅用于测试，普通查询指定了我需要的列，但我需要其中的大部分），查询需要 20 到 60 秒才能执行。这将是我的报告的基本查询，报告应该在 60 秒内运行，所以我认为这不会成功（我添加连接时它超时）。该报告在我们较小的测试环境中运行没有任何问题。
是不是因为 MySQL 试图锁定表并等待所有写入完成，所以查询花费了这么长时间？这张桌子上可能有很多写。我正在对 MySQL 从站进行查询，因为我不想用我的查询锁定生产系统。
一个有 250,000 行的表对于 MySQL 来说根本不算大。
但是，等待这些行返回到应用程序确实需要时间。那是网络时间，你和亚马逊之间可能有很多跃点。
除非您的报表真的要处理所有数据，否则请使用更简单的查询来检查数据库的性能，例如：
select count(*) from table;
编辑：
您的问题不太可能是由于数据库造成的。这可能是由于网络流量。正如另一个答案中提到的，流式传输可能会解决问题。您也许还可以使用数据格式将总大小缩小到更合理的程度。
最后的一步是将数据保存在文本文件中，压缩文件，将其移动并解压缩。尽管这听起来需要做很多工作，但您可能会对数据进行 5 倍到 10 倍的压缩，从而节省大量的传输时间，并且在其余处理方面仍然有很大的性能提升。
请记住，MySQL 必须准备您的结果集并将其传输到您的客户端。在您的情况下，这可能是 200MB 的数据，它必须在连接中穿梭，所以 20 秒一点也不差。默认情况下，大多数库会等待收到整个结果，然后再将其转发给应用程序。
要加快速度，请仅获取您需要的列，或者使用LIMIT. SELECT *通常表明某人超级懒惰并且根本没有优化。
如果您的库支持流式传输结果集，请使用它，因为您几乎可以立即开始获取数据。它将允许您在行进入时对其进行迭代，而无需缓冲整个结果。
我从我的客户那里获得了更新的规格，并且能够将返回的用户数量减少到 250，尽管在 60 秒内完成了（有很多 JOINS）。
所以也许答案真的是：尽量不要用查询转储整个表，只获取您需要的确切数据。客户端具有 SQL 访问权限，他必须更新他的查询，因此只返回相关用户。
我永远不应该真正使用 * 作为通配符。选择您实际需要的字段，然后创建这些字段组合的索引。
如果您有数千行，另一种选择是实现分页。如果结果数据直接用于报表，单次看不到100多行。