虽然前面的答案不一定是错误的，但它们并没有给予完整的画面。
请看，有两种类型的“逻辑文件”-键控和非键控。
1.非密钥逻辑文件实际上等同于视图，不会充当索引。
1.键控逻辑文件相当于索引（据我所知，它们在底层系统中实际上是以相同的方式实现的）。这些 * 将 * 按照您对索引的期望。
所有逻辑文件，键控或非键控，实际上都显示在iSeries Navigator中作为视图（我认为只有“实际”- SQL -索引显示为索引）。
我...实际上不确定如何找出一个逻辑文件是否是从导航器键入的。在iSeries上，我的公司有一个（我假设是）自定义命令来显示给定物理文件的各种逻辑文件（以及它们的键）（索引也会显示）。然而，键控列很容易在逻辑文件定义中找到-让您的一些AS/400朋友向您展示定义以及要查找的内容。
IBM DB2 documentation：
从SQL接口的Angular 来看，逻辑文件与视图和索引是相同的。
还有这篇文章"SQL indexes and native I/O – no contradiction (2016)"，它讨论了“DDS键控逻辑文件”和“SQL索引”之间的区别。注意：逻辑文件是DDS的一部分，它们通过“本地I/O”访问。“DDS是一种过时的技术”。

逻辑文件合并了视图（列选择和表连接）和索引（行排序）的功能。它们通常用作索引，但在导航器中显示为视图。另外，物理文件（不是表）也可以有索引。
SQL表、视图和索引在DB2foriSeries中使用物理和逻辑文件实现。主要区别在于数据库检查数据完整性的时间。在写时检查表，在读时检查文件。您可以将垃圾数据放入文件，但不能放入表。

实际上，SQL创建的索引/视图和通过DDS创建的逻辑文件之间有许多微小的差异（这是为逻辑文件（LF）编写源文件并将其编译为LF对象的方式）。
他们是同一个人吗？这是一个明确的没有在那里。但也有非常相似的东西，在大多数情况下，你可以使用任何一个。有可能你永远不会体验到任何不同，但也有可能，有一天你站在一个无法解释的情况下，因为这些差异。以下是我迄今为止学到的一些差异（我现在还记得）。（我将在这里讨论LF-逻辑文件-和PF（物理文件）。PF或多或少就是你在SQL中所称的表，但就像LF和索引/视图一样，我不会把它们称为相同的）

• LF可以具有选择/省略语句，其过滤PF的哪些行。* 小心那些！* 它们不仅经常令人困惑，而且还可能对您的SQL查询产生重大影响。现代查询优化器（SQE）忽略了这样的LF，甚至可能导致SQE根本不被使用，仅仅因为存在（取决于您的SQL配置）。你通常可以用一个排序索引和一个选择来获得相同的行为。
• LF可以共享数据路径（具有索引col 1、col 2、col 3的LF A和具有索引col 1、col 2、col 4的LF B应该共享索引afaik），sql索引不这样做（但是该优点应该不如下一个缺点重要）
• 索引可以具有更大的页面大小。据我所知，这可以使一个巨大的table上的差异）。
• 当您重命名PF并从其DDS源重新评级时，索引和LF的行为可能会有所不同。索引应该保留在重命名的对象上，而LF应该引用具有旧名称的新对象

这些差异与IBM DB2/400-system创建于很久以前，当时还没有人谈论SQL，并一直在开发。但是自从SQL变得重要，IBM也为他们常用的数据库引入了SQL支持。所以索引/视图需要支持这些东西，SQL要求它们。另一方面，LF必须与AS/400 s历史保持向下兼容。这些是不同的。因此，如果不放弃对其中一个的支持，它们就不可能是相同的。但他们试图接近。

在寻找其他东西的时候偶然发现了这个讨论，所以我想我也会加一个贡献。PF和LF通常被称为“本机文件”，因为它们与这个系统祖先（S/38，甚至不确定是否更早）一起诞生，而表/视图是后来用SQL引入的。虽然现在SQE在优化过程中同时考虑PF/LF和表/视图，但两者之间的另一个巨大差异是，虽然两者都可以在任何SQL语句中使用，即使嵌入在编译程序中，但只有PF/LF可以在编译程序中使用。考虑到已编译的程序，PF/LF记录格式的更改意味着重新绑定/重新编译过程，而在表/视图更改的情况下不需要重新绑定/重新编译过程，除非从SQL语句外部引用它们。

在寻找其他东西的时候遇到了这个讨论，所以我想我会有所贡献。键控逻辑文件提供索引的功能。但是，索引的性能比逻辑文件好，如果DB2 for IBM i中的查询优化器可以使用索引，那么它更有可能使用SQE（SQL查询引擎）而不是较旧且效率较低的CQE（“经典”查询引擎）来优化查询。默认情况下，索引的页大小比逻辑文件大，这有助于提高性能。在IBMi操作系统的最新版本中，可以指定逻辑文件的页大小，因此索引的优势不再像以前那样重要。IBM的战略方向是将数据库性能改进工作集中在较新的SQL DDL定义的数据库对象（表、索引等）上，而忽略较旧的遗留DDS定义的对象（物理和逻辑文件）。

IBM的这份PDF解释了DB2中的索引方法，对于我理解AS400系统上使用SQL创建的表或作为物理文件创建的表之间的差异很有帮助。
IBM DB2 for i indexing methods and strategies

这是一个有趣的测试结果。
当查询物理文件时，查询优化器可以利用逻辑文件的索引，即使用户配置文件被显式地 *EXCLUDE到逻辑文件。
但是，尝试直接查询逻辑文件将导致授权错误。
因此，逻辑文件的索引部分似乎总是可用于查询优化器，而逻辑文件的视图部分是安全部分。
这个测试是问这个问题的结果...如果我给予用户配置文件 *USE访问物理文件的权限，但不访问逻辑文件，查询优化器是否仍然能够利用逻辑文件的索引。答案是肯定的。
对于SQL索引也是如此。即使用户是 *EXCLUDE，优化器也会使用它。

根据description，AS/400 DB2逻辑文件在大多数其他关系数据库中称为视图。我不得不说，我不认为逻辑文件和索引是一样的。