Windows Desktop Search - SQL incroyable lente '% recherche%'

Question

Je suis en train d'interroger la recherche de bureau Windows API utilisant SQL.

Je dois dire que je déteste vraiment les fenêtres 7 GUI de recherche, et je décidé d'écrire mon propre. J'ai beaucoup de fichiers indexés (environ 1.000.000), et je veux faire une recherche de noms. Quelque chose comme: Montrez-moi tout nom qui contient « lapin »

.

Mais ici je rencontre un problème de performance. Recherche de

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

est vraiment rapide. Aussi l'alternative %egon. Mais %egon% prend une éternité. Je ne sais pas si elle est dans la nature de l'indice (je comprends que les possibilités augmentent énormément) ou si je fais quelque chose de mal.

La question est:

• Est-il exact que l'indice Windows est seulement une grande base de données SQL?
• Si oui, où puis-je trouver des informations précises sur la structure de la base de données (clés primaires, index).

Si j'ai que, fondamentalement juste son optimisation SQL.

Question alternative:. Est-ce que quelqu'un connaît une instruction SQL rapide pour trouver tous les fichiers avec egon quelque part dans le nom

Edit: Pourquoi je n'aime pas l'interface graphique de recherche

Eh bien, juste pas intuitive, par rapport à XP. Si vous désactivez le chien et utilisez l'ancienne interface XP, je pourrais créer une requête de recherche comme:

  

  
• Tous les fichiers plus de 1 mois
  
• plus de 10 Mo
  
• modèle de nom *_homework_*.docx
  

Essayez ceci dans Windows 7 sans « apprendre » la syntaxe. Et l'enfer, je fais pas veulent apprendre une autre syntaxe juste pour trouver un fichier.

L'autre principal problème sont peut-être mes habitudes de recherche. La plupart du temps je sais en quelque sorte le nom du fichier (ou parties) et que vous voulez simplement l'emplacement. Et si vous utilisez la recherche de cette façon que vous avez exécuté en plusieurs problèmes:

• Tout d'abord, vous avez toujours le préfixe avec le nom:
• Ensuite, la mise en page du nom du dossier est stupide (il ordonne par dossier parent, pas le chemin complet, I pense , parce que .. Tada ... voir le point suivant)
• Alors, encore plus ennuyeux, si vous avez une liste de résultats et vous essayez de les trier, il faut toujours

Et maintenant, je pense vraiment que mon système a un bug. J'ai essayé de vérifier rapidement, recherché dans un certain dossier de taille moyenne pour « test » et il a trouvé des fichiers. Alors j'ai essayé de les trier pour les dossiers (pour vérifier mon deuxième point) et maintenant il est juste pour toujours ... Je cherche veux dire vraiment, alors je tape qu'il essaie de trouver le mot « bonjour » ... oh, fini - il trouvé environ 20 fichiers. Donc, maintenant, permet d'essayer quelque chose .... Ok, il semble maintenant comme il l'a récupéré .. Mais encore, pour ralentir à mon goût ...

Alors, assez jurons au sujet de la recherche: -)

Answer 1

On dirait qu'ils construisent un indice sur le nom, il peut donc utiliser l'index aussi longtemps que vous avez spécifié le début de la chaîne, mais si vous n'avez pas, il doit utiliser un scan de table.

En supposant qu'ils utilisent le moteur de recherche de texte intégral de Microsoft, essayez d'utiliser quelque chose comme:
... Où system.filename CONTIENT 'egon'

Il existe essentiellement deux choix: il sera rejeté comme non valide (à savoir l'interface SQL ne prend pas en charge leur extension de recherche F-T) ou bien ce sera un peu plus rapide

.

EDIT: Oops - la syntaxe doit être "contient (system.filename, 'egon')". Désolé pour cela.

Answer 2

Peut-être essayer

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

Answer 3

Ceci est lent parce que vous ne pouvez pas utiliser un index. La raison est que vous êtes à la recherche d'un match anwhere dans la chaîne plutôt que au début de la chaîne qui signifie que vous devez numériser toute la table pour le contenu.