MySQL在一个非常简单的查询中速度非常慢

我在一个小表（115k条记录）中运行一个非常简单的查询，得到的响应非常慢。。。 回答大约需要8秒，我不明白为什么需要这么长时间。任何建议都会很棒

表:

CREATE TABLE `financeiro_fluxo` (
  `id` int(10) unsigned NOT NULL AUTO_INCREMENT,
  `branch` int(10) unsigned NOT NULL,
  `abertura` int(10) DEFAULT NULL,
  `origem` int(10) unsigned DEFAULT NULL,
  `status_pagamento` tinyint(3) unsigned DEFAULT NULL,
  `conta` int(10) unsigned NOT NULL,
  `tipo_lancamento` tinyint(3) unsigned NOT NULL,
  `categoria` int(10) unsigned NOT NULL,
  `tipo_entidade` varchar(32) COLLATE utf8_unicode_ci NOT NULL,
  `entidade` int(10) unsigned DEFAULT NULL,
  `entidade_input` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `tipo_pagamento` tinyint(3) unsigned NOT NULL,
  `parcela` smallint(5) unsigned NOT NULL,
  `parcelas` smallint(5) unsigned NOT NULL,
  `valor` decimal(12,2) NOT NULL,
  `valor_taxa` decimal(12,2) DEFAULT NULL,
  `valor_troco` decimal(12,2) DEFAULT NULL,
  `confirmado` tinyint(3) unsigned DEFAULT NULL,
  `data_confirmacao` datetime DEFAULT NULL,
  `vencimento` date NOT NULL,
  `info` varchar(510) COLLATE utf8_unicode_ci DEFAULT NULL,
  `bandeira` int(10) unsigned DEFAULT NULL,
  `user_add` int(10) unsigned NOT NULL,
  `user_last` int(10) unsigned NOT NULL,
  `param_ref` varchar(32) COLLATE utf8_unicode_ci DEFAULT NULL,
  `param` varchar(255) COLLATE utf8_unicode_ci DEFAULT NULL,
  `file` int(10) unsigned DEFAULT NULL,
  `date_created` datetime NOT NULL,
  `date_modified` datetime NOT NULL,
  `status` smallint(6) unsigned NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `id` (`id`)
) ENGINE=InnoDB AUTO_INCREMENT=116749 DEFAULT CHARSET=utf8 COLLATE=utf8_unicode_ci

查询：

SELECT * from financeiro_fluxo

说明：

id  select_type     table               type    key   key_len   rows   
1   SIMPLE          financeiro_fluxo    ALL                     116244  

使用相同的表在localhost上运行相同的查询，在不到一秒的时间内返回

简介：

---

您似乎正在进行全表扫描，因为您的查询不包含任何限制条件（例如WHERE子句或LIMIT）。为了更好地执行查询，请使用带有某种条件的索引列。如果在id不为NULL的位置添加

会发生什么情况

我假设您需要所有记录，如果不通过在更具体的WHERE子句（索引列上）或limit子句中添加条件来限制结果集的话。

这些“报告”会聚合数据吗？当然，您可以通过在服务器上做更多的工作来加快8秒（远程）查询的速度，从而减少通过网络传输的数据

也就是说，考虑是否可以在

选择中执行
平均（..）、计数（*）、总和（..）、最大（..）等操作

再迈出一步。。。建立并维护包含小计（等）的“汇总表”。然后，无论是在服务器上还是在网络上，读取（或扫描）汇总表和汇总小计等都会更快

（我同意需要避免
*
，并且这8秒可能是由于网络延迟（和“带宽”）。服务器在地理位置上在哪里？选择1；
需要多长时间？
检查您的InnoDB调优。可能是默认值太糟糕了。您试图获得~150MB的容量。。。从磁盘读取、处理、发送到客户端。。。在本地主机上可以很快，但在远程服务器上却很难。基本上是网络时间。查询总是需要不到一秒的时间（请在show processlist上确认），但通过网络传输到客户端需要8秒。对于每晚，一分钟的批处理是完全可以接受的。有什么问题吗？现在，您不应该以交互方式检索10万行，是吗？发生的情况如下：您正在选择所有内容。一切都因数据而异。通过管道（网络）挤压所有东西需要时间。所需的时间取决于管道是否胖（bandwith），服务器在尝试满足您的请求时是否在做其他事情（例如出于任何原因使用HDD，这会减慢选择），是否有足够的内存来缓冲您生成的查询结果（因为它必须位于某个位置，直到它被冲入管道）。那么，你想要什么样的答案？你不能通过使用诙谐的代码来消除硬件限制。这不是全表扫描，而是全表读取。使用
limit，offset
仍将执行全表扫描，如果没有索引候选项来减少正在迭代的数据集。关于全表扫描，这表示相反，或者这是您对全表读取和全表扫描的定义？因此，首先-我和您一样讨厌挑剔的人。第二，你发布的链接没有说其他。扫描意味着正在读取每一行，然后将其与某种条件进行比较（例如，
，其中x类似于“%text%”
）。全表扫描意味着对每个记录都进行了相同的扫描。全表读取不需要任何条件即可工作。我们无法提供一个条件，让MySQL更快地发送相同的数据，这正是OP所追求的。您试图提出您自己并不真正理解的策略（
其中id不为NULL
在这里无效）。@Rafanake规则#1不要使用SELECT*，除非您将使用每一列。规则#2选择不带WHERE的行。除非您试图创建CSV类型的输出数据文件，否则您很少能够有效地使用任何联机系统的任何表中的每一列。认识到本地主机系统通常比通过可用连接器连接的任何系统都要快。“扫描”与“读取”——扫描中的大部分时间都花在读取行上。也就是说，在讨论性能时，它们之间没有太大区别。