Pesquisa de desktop do Windows - SQL inacreditável lenta '%Search%'

Question

Estou tentando consultar a API de pesquisa de desktop do Windows usando o SQL.

Devo dizer que realmente odeio a GUI da Windows 7 e, por isso, decidi escrever o meu. Eu tenho muitos arquivos indexados (aproximadamente 1.000.000) e quero fazer uma pesquisa por nomes. Algo como: Mostre -me todo nome que contém "Bunny".

Mas aqui eu encontro um problema de desempenho. Procurando por

SELECT "System.ItemPathDisplay" 
FROM "SystemIndex" 
WHERE System.FileName LIKE 'egon%'

é muito rápido. Também o %egon alternativo. Mas %egon% leva uma eternidade. Não tenho certeza se está na natureza do índice (entendo que as possibilidades aumentam enormemente) ou se estou fazendo algo errado.

A questão é:

• É correto que o índice do Windows seja apenas um grande banco de dados SQL?
• Nesse caso, onde posso encontrar informações exatas sobre a estrutura do banco de dados (chaves primárias, índices).

Se eu tiver isso, basicamente está apenas otimizando o SQL.

Pergunta alternativa: Alguém conhece uma instrução SQL rápida para encontrar todos os arquivos com Egon em algum lugar no nome.

EDIT: Por que eu não gosto da GUI de pesquisa

Bem, simplesmente não é intuitivo, em comparação com o XP. Se você desativar o cachorro e usar a interface XP antiga, eu poderia criar uma consulta de pesquisa como:

• Todos os arquivos com mais de 1 mês
• maior que 10 MB
• Nome Pattern *_homework_*.docx

Experimente isso no Windows 7 sem "aprender" a sintaxe. E inferno eu faço não Deseja aprender outra sintaxe apenas para encontrar um arquivo.

O outro principal problema são talvez meus hábitos de pesquisa. Na maioria das vezes, de alguma forma conheço o nome do arquivo (ou partes) e simplesmente quero o local. E se você usar a pesquisa desta maneira, terá vários problemas:

• Primeiro de tudo, você sempre precisa prefixá -lo com o nome:
• Então o layout do nome da pasta é estúpido (está pedindo pela pasta pai, não caminho completo, eu acho, porque .. tada ... veja o próximo ponto)
• Então, ainda mais irritante, se você tiver uma lista de resultados e tenta classificá -los, leva uma eternidade

E agora eu realmente acho que meu sistema tem um bug. Tentei verificá -lo rapidamente, pesquisado em uma pasta de tamanho médio para "teste" e ele encontrou alguns arquivos. Então eu tentei classificá -los para pastas (para verificar meu segundo ponto) e agora ele está apenas pesquisando para sempre ... quero dizer, realmente, enquanto estou digitando ele tenta encontrar a palavra "olá" ... Oh, terminado - ele encontrou aproximadamente 20 arquivos. Então, agora, vamos tentar algo ... ok, agora parece que ele se recuperou .. mas ainda assim, para desacelerar para o meu gosto ...

Então, o suficiente xingar sobre a pesquisa :-)

Answer 1

Parece que eles estão criando um índice no nome, para que ele possa usar o índice, desde que você especifique o início da string, mas se você não tiver, ele precisa usar uma varredura de tabela.

Supondo que estejam usando o mecanismo de pesquisa de texto completo da Microsoft e tente usar algo como:
... onde o System.FileName contém 'egon'

Existem basicamente duas opções: será rejeitado como inválido (ou seja, essa interface SQL não suporta sua extensão de pesquisa de FT) ou então será um pouco mais rápido.

EDIT: OOPS - A sintaxe deve ser "contém (System.FileName, 'Egon')". Desculpa aí.

Answer 2

Talvez tente

"SELECT \"System.ItemPathDisplay\" FROM \"SystemIndex\" WHERE CONTAINS(System.FileName, 'egon')";

Answer 3

Isso é lento porque você não pode usar um índice. O motivo é que você está procurando uma partida em um lugar na string, e não no início da string, o que significa que você deve digitalizar a tabela inteira para o conteúdo.