サブラインインデックスのあるフィールドに1文字のフィルタとワイルドカード（*）を使用すると、OpenLDAPインスタンスのレコードが返されません。フィルターに複数の文字がある場合、検索は非常に高速です。私の質問はなぜですか？フィルタが1文字+ワイルドカードで構成されている場合、slapdの結果が遅くなる
シナリオはLMDBバックエンド、OS X、130万件のレコードを、インデックスのように設定、のOpenLDAP v.2.4.44である：「検索フィルタがある場合
olcDbIndex: objectClass eq
olcDbIndex: cn eq,sub
（CN = S *） 'の場合、クエリには時間がかかりますが、フィルタが'（cn = sm *） 'の場合は高速です。 slapindexを実行すると違いはありません。ここで
は、いくつかの数字は、時間を使用して、以下のとおりです。
$time ldapsearch -H ldap:/// -D cn=Manager,dc=xyz,dc=com -w secret -b dc=xyz,dc=com -s sub -z 5 '(cn=s*)' cn sn
-- some ldap records --
real 0m0.474s
user 0m0.001s
sys 0m0.002s
はに変更 '（CN = SM *）'利回り：へ
real 0m0.012s
user 0m0.001s
sys 0m0.003s
「（CN = SMI * ） '：
real 0m0.012s
user 0m0.001s
sys 0m0.003s
実際には、フィルタに複数の文字とワイルドカードが付いていると、それらの時間は一定のままです。
さらに調査すると、アルファベットを下げると徐々に時間が長くなることがわかりましたが、その1文字の検索でのみ発生しました。 で行く
'（CN = A *'）が与える：
real 0m0.012s
user 0m0.001s
sys 0m0.003s
を '（CN = B *）'：
real 0m0.046s
user 0m0.001s
sys 0m0.004s
この時点で、あなたが見ることができますユーザーとsysは常に高速ですので、今から省略して実際の時間だけを表示します。したがって：
'(cn=a*)' --> 0m0.012s
'(cn=b*)' --> 0m0.046s
'(cn=c*)' --> 0m0.105s
'(cn=d*)' --> 0m0.149s
'(cn=e*)' --> 0m0.174s
...
'(cn=m*)' --> 0m0.342s
...
'(cn=s*)' --> 0m0.523s
...
'(cn=z*)' --> 0m0.606s
しかし、これらの検索のいずれかに追加の文字が指定されていれば、それは高速に戻ります（0.012sは平均です）。だから何らかの理由で、slapdは最初の文字を見つけるのに時間がかかりますが、1文字が使われる場合に限ります。
インデックスを付けられていない 'sn'属性（例： 'sn = s *'）のフィルタリングでは、1文字+ワイルドカードフィルタを使用した場合、インデックス付き 'cn' 。したがって、slapdは、1文字+ワイルドカードのフィルタリング時に 'cn'属性の部分文字列インデックスを無視しているようです。しかし、2番目の文字を追加すると 'cn'フィルタは速くなりますが、 'sn'フィルタは遅くなりますが、これは予期されることです。
なぜこのようなことが起こり、どのように修正できますか？