无条件全选昂贵的全表扫描答案

【问题标题】：Expensive full table scan on select all without condition无条件全选昂贵的全表扫描
【发布时间】：2019-12-08 17:20:14
【问题描述】：

我有一个包含 210 列的宽表（这可能是一个糟糕的结构，但每次都需要所有数据）。主键有一个主类型索引。

现在，当我在没有任何条件的情况下从我的单个表中选择 * 时。它会导致全表扫描。

上面写着： 未找到该表的可用索引

这也意味着搜索范围太广，索引没用。

我可以做些什么来避免这种全表扫描？

注意：我每次都需要所有信息，因此破坏表格会导致性能下降..！

我是 MySQL 新手。因此，我们将不胜感激。谢谢..！

【问题讨论】：

我从来没有运行过 " select * from my single table without any condition " 并且没有得到完整的扫描。我什至不知道这是可能的，是吗？但如果你这样做，它会识别索引SELECT indexed_column1, indexed_column1, FROM table
解释你想从表中提取的内容。并提供SHOW CREATE TABLE。
@RickJames 谢谢。我的表有 int、Big int 和 text 数据类型。情况是我们必须在最坏的情况下选择 *。我所做的是将表格分成两个，即一个具有 int 和 big int 类型，另一个是文本类型。而我们未来的数据将超过100万条记录。现在我已经用 60 万条记录测试了 int/big int 表。耗时 492 秒。正常吗？我们可以做些什么来加快数据检索速度？
现在，解释一下您的客户将如何处理一百万行 - 特别是如果它们很庞大，有很多 TEXTs，而不是小的 INTs。我问这个是因为可能在 SQL 中进行更多处理会更好，并且发送的行数少于一百万行和/或少于 210 列。
（这个问题大部分是stackoverflow.com/questions/57284895/…的重复）

【解决方案1】：

全表扫描的原因如下

为了避免使用下面的全表扫描：

使用 ANALYZE TABLE tbl_name 更新已扫描表的键分布。
对已扫描的表使用 FORCE INDEX 来告诉 MySQL 与使用给定索引相比，表扫描非常昂贵：

例如SELECT * FROM t1, t2 FORCE INDEX (index_for_column) WHERE t1.col_name=t2.col_name;

【讨论】：