问题标签 [full-table-scan]

我正在尝试查找字段以值开头的文档。

使用notablescan禁用表扫描。

这有效：

这不会：

我得到错误：

url和都有索引source.homeUrl：

对子文档索引的正则表达式查询是否有任何限制？

所以我有这个表包含 100000 行

现在我刚刚添加了一个新列 field3 并且在 field3 上有一个索引

所以我添加了大约 50 行包含 field3（其他行的 field3 为 NULL）

所以我做了一个选择

对此的解释是相当理智的。它使用 field3 上的索引并且只扫描 2 行

但是，当我在 IN 语句中添加更多值时

这最终导致不使用索引并最终对整个 100000+ 行执行全表扫描。

为什么mysql会这样做？"If you need to access most of the rows, it is faster to read sequentially, because this minimizes disk seeks."我从http://dev.mysql.com/doc/refman/5.1/en/mysql-indexes.html知道 mysql

但这不可能比使用索引获取这 10 个值更快

为什么mysql会这样做，我如何指示mysql强制他们使用索引而不是执行全表扫描......

考虑以下视图

some_table有数百万行并且在+another_table上有一个索引。 a_idother_column

现在，考虑以下 SQL：

谁能告诉我为什么这个 sql 查询要进行全表扫描some_table？目标是有一个视图，它返回equalsanother_table所在的行数。 other_column'ABC'

如果我LEFT JOIN my_view在查询中替换为LEFT JOIN ( the AS CLAUSE from the view )，它不会进行全表扫描并使用 a_id + other_column 索引。

我难住了。任何帮助表示赞赏。

我正在阅读 MySql 索引优化的文档。

我找到了一个设置 --max-seeks-for-key=1000 。我在这里检查了 MySQL 的“服务器系统变量” 。
根据它

“通过将其设置为较低的值（例如，100），您可以强制 MySQL 更喜欢索引而不是表扫描”

.
我从 FULL TABLE SCAN 中了解到的是：

当查询需要访问大部分行时，顺序读取比通过索引更快。即使查询不需要所有行，顺序读取也可以最大限度地减少磁盘寻道。

因此，如果 MySQL 正在执行最小化磁盘搜索的全表扫描，为什么要使用 --max-seeks-for-key=1000 来选择可能增加磁盘搜索的索引扫描。

在文档8.3.1.20 How to Avoid Full Table Scan中，它被提及为避免全扫描的一个步骤： Start mysqld with the --max-seeks-for-key=1000

所以我很想知道 --max-seeks-for-key 是否有任何实际和有意义的用途。

据我所知，堆表是没有聚集索引并且没有物理顺序的表。我有一个 120k 行的堆表“扫描”，我正在使用这个选择：

如果我为“id”列创建一个非聚集索引，我会得到223 physical reads。如果我删除非聚集索引并更改表以使“id”成为我的主键（以及我的聚集索引），我会得到515 physical reads。

如果聚集索引表是这样的图片：

为什么聚集索引扫描像表扫描一样工作？（或者在检索所有行的情况下更糟）。为什么它不使用具有较少块并且已经具有我需要的ID的“聚集索引表”？

我有一个负责存储日志的表。DDL 是这样的：

使用这两个索引：

但是这个查询会产生一个完整的表扫描：

为什么我总是看到一个FULL TABLE SCANon 列DATA和STRUCTURE_CODE？

（我也尝试过创建两个不同的索引STRUCTURE_CODE，DATA但我总是进行全表扫描）

在过去的几个月里，我们将一些表从 MYiSAM 迁移到了 InnoDB。理论上，我们这样做是为了行锁定优势，因为我们通过多个网络抓取实例更新各个行。我现在在我的 slow_query_log (10s) 中建立了数以万计的 slow_queries。和很多全表扫描。我对一行进行非常简单的更新（更新 4 或 5 列）需要 28 秒。（我们的 I/O 和效率非常好，失败/中止的尝试非常低 < 0.5%）

我们更新最多的两个表以 ID (int 11) 作为主键。在 InnoDB 中，主键是一个聚集键，因此按 ID 顺序写入索引的磁盘。但是我们最重要的两个记录标识列是BillsofLading和Container（都是 varchar22）。我们的大多数 DML 查询都基于这两列查找记录。我们也有索引BillsofLading，container. 据我了解，InnoDB 在创建这两个二级索引时也使用主键。

所以，我可以有一个ID=1 和BillsofLading='z' 的记录，以及另一个ID=9 和BillsofLading='a' 的记录。使用 InnoDB 索引，当基于 SELECT where BillsofLading='a' 更新记录时，由于索引基于ID?

在此先感谢您帮助这里的逻辑！

我在使用不同的正确查询更改 PL/SQL oracle 中的查询时遇到问题。当前查询：

我的客户需要修改查询，因为：

这个问题有什么解决方案？

提前致谢

从包中添加查询

首先：我知道在 Cassandra 中进行全面扫描不是一个好主意，但是，目前，这就是我所需要的。

当我开始寻找这样的事情时，我读到人们说不可能在 Cassandra 中进行全面扫描，而且他不是被迫做这种事情的。

不满意，我一直在寻找，直到找到这篇文章： http ://www.myhowto.org/bigdata/2013/11/04/scanning-the-entire-cassandra-column-family-with-cql/

看起来很合理，我试了一下。由于我将只进行一次完整扫描并且时间和性能不是问题，因此我编写了查询并将其放入一个简单的作业中以查找我想要的所有记录。从 20 亿行记录中，我的预期输出是 1000 条左右，但是，我只有 100 条记录。

我的工作：

基本上我所做的是搜索允许的最小令牌并逐步进行直到最后一个。

我不知道，但就像这项工作没有完全完成全扫描，或者我的查询只访问了一个节点或其他东西。我不知道我是否做错了什么，或者真的不可能进行全面扫描。

今天我有将近 2 TB 的数据，在一个由七个节点组成的集群中只有一个表。

有人已经遇到过这种情况或有什么建议吗？

我有类似这样的查询：

问题是这个表非常大，Oracle 正在进行全表扫描。我试图创建一个索引（带有 status、child_id、parent_id 列）来加速这个查询，但是 Oracle 没有使用这个索引，即使有提示。

有没有办法加快这个查询？