Performance 当正在搜索的属性具有索引时，通过baseDN限制LDAP搜索是否有任何好处？

我们正在设计一个LDAP模式（专门针对OpenDJ），我们主要需要能够在

mail

属性上进行搜索。我们不需要进行子字符串搜索，因为用户登录时会提供整个电子邮件地址

我们已经有了

mail

属性的索引。然而，我们也在考虑用电子邮件地址的第一个字母来划分用户目录（因此，所有电子邮件地址以字母

A

开头的用户都将位于

ou=users

下的

ou=A

子目录中。这样做的唯一价值是，当我们通过电子邮件搜索用户时，我们可以限制搜索的

baseDN

，从而将搜索范围缩小到大约整个目录的1/26

我的主要问题是，如果属性已经有索引，那么像这样限制LDAP搜索的

baseDN

是否会提高性能？索引是否考虑了

baseDN

，或者它们是否在整个目录中建立索引

---

第二个问题是，如果允许的话，除了在搜索时提供更具体的

baseDN

之外，是否还有其他用法可以按首字母（或任何其他安排）拆分用户目录？

当您甚至不知道是否存在性能问题时，您所考虑的似乎是过早的优化。 此外，索引和处理查询不是LDAP的标准元素，而是所使用技术的实现细节

在OpenDJ中，为整个数据库后端配置和维护索引。 无论您有1个条目还是10亿个条目，在电子邮件平等索引中查找并返回单个条目的成本都是相同的

我在LDAP和目录服务方面有20多年的经验，从未见过任何目录按照属性的第一个字母拆分条目。

I一次（而且只有一次）遇到了一个与您预期的问题类似的问题——本质上，您有太多的记录，因此搜索记录会产生不可接受的用户体验。在我的例子中，目录中有超过一百万的客户。现在IBM Tivoli directory Server的一个相当旧的迭代有几个错误，这意味着搜索目录需要几分钟才能完成（索引或无索引）。没有人愿意等待几分钟来登录并支付账单！我们不得不使用IBM的LDAP服务器

---

在这种情况下，我在创建帐户时使用了作为命名属性的电子邮件地址，并且从未搜索过目录，即我是cn=lisa@example.com，ou=客户，o=目录中的示例。当我使用lisa@example.com，该站点以编程方式将绑定DN表示为“cn=“+userInput+”，ou=customers，o=example”并验证提供的密码，而不是搜索我的帐户。

谢谢Ludovic Poitou。我认为设置目录结构需要在一开始就解决，因为以后很难更改，因此“过早优化”.但是，如果它对索引没有影响，那么就没有必要这样做。谢谢。