我理解完整的提示：
/*+ FULL(alias) */
将强制优化器执行全表扫描。
除了在查询选择表中大部分行的明显索引之外，是否还有比使用索引更有用的场景？
答案 0 :(得分：3)
非常广泛的主题。
来自Oracle文档"When using hints, in some cases, you might need to specify a full set of hints in order to ensure the optimal execution plan. For example, if you have a very complex query, which consists of many table joins, and if you specify only the INDEX hint for a given table, then the optimizer needs to determine the remaining access paths to be used, as well as the corresponding join methods. Therefore, even though you gave the INDEX hint, the optimizer might not necessarily use that hint, because the optimizer might have determined that the requested index cannot be used due to the join methods and access paths selected by the optimizer."
它避免使用索引并使用FTS。
与所有一般概念一样，这有例外。全表扫描可以比索引扫描更便宜，然后通过rowid访问表 - 有时候便宜得多。
摘录from：
除了表格的块之外，还需要读取索引块。如果索引很大（表大小的相当大的百分比），SGA（和关联锁存器）上的压力可能会很明显 如果索引的排序顺序与数据存储在实际表中的方式不匹配，则完成查询所需的逻辑I / O数可能（可能多）多于完成查询的LIO数量表扫描。 （索引的聚类因子是您可以查看的指标之一。）
基本上，如果通过索引进行扫描会使数据块I / O请求在整个表中跳转，那么整体成本将高于可以进行大量顺序读取的成本。 FTS更可能使用多块直接路径读取，完全绕过SGA，这也可能是好的 - 没有“缓存抖动”，更少锁存。
如果你有覆盖索引，很可能会一直打败全表扫描。如果不是，它将取决于需要处理的实际块（数据+索引）的百分比（索引对该查询的选择性），以及它们相对于彼此的“物理排序”的程度。 / p>
至于为什么优化器会为你选择“错误的”路径：很难说。关于索引或表的陈旧统计可能像往常一样，基于LIKE计算的估计可能对于某些模式是关闭的，实例参数可能有利于索引太多，...如果这是唯一的行为不端的查询，并且你的统计数据是最新的，使用/ * + full * /提示听起来不是太糟糕。
同时阅读Stack documentation