Sqlite Optimisation de la Requête (select * from où ET n'est pas de l'ordre dans la limite de décalage)

Des idées pour l'optimisation de la requête suivante à l'aide Sqlite3?

SELECT * FROM Feed 
    WHERE ActivityType IN ('PhotoActivity','CommentActivity') 
    AND UserKey NOT IN ('testUser', 'testUser2') 
    ORDER BY TimeStamp DESC 
    LIMIT 20 OFFSET 0;

La table n'aura jamais plus de 100 000 enregistrements, et nous attendons de 100 à 1 lit à l'écrit.

Toute aide est grandement appréciée.

Table Sql est:

CREATE TABLE Feed (
        FeedActivityKey TEXT PRIMARY KEY,           
        UserKey TEXT,
        AssemblyQualifiedName TEXT,
        SerializedObject BLOB,
        ActivityType TEXT,
        CorrelatedKey TEXT,
        TimeStamp INTEGER);
    CREATE INDEX Feed_ActivityTypeUserKey ON [FriendFeed] (
    [ActivityType], [UserKey] DESC);
    CREATE INDEX Feed_UserKey ON [FriendFeed] (
    [UserKey] DESC);
    CREATE INDEX Feed_TimeStamp ON [FriendFeed] (
    [TimeStamp] DESC);

Expliquer Sortie est:

0 Trace 0 0 0 0

1 OpenEphemeral 1 3 0 keyinfo(1,-BINAIRE) 0

Entier de 2 20 1 0 0

3 MustBeInt 1 0 0 0

4 IfZero 1 73 0 0

5 Entier 0 2 0 0

6 MustBeInt 2 0 0 0

7 IfPos 2 9 0 0

8 Entier 0 2 0 0

9 Ajouter 1 2 3 0

10 IfPos 1 12 0 0

11 Entier -1 3 0 0

12 String8 0 4 0 PhotoActivity 0

13 String8 0 5 0 CommentActivity 0

14 Goto 0 74 0 0

15 OpenRead 0 2 0 7 0

16 OpenRead 2 4 0 keyinfo(2,BINAIRE,BINAIRE) 0

17 7 25 0 0

18 Entier 1 7 0 0

19 OpenEphemeral 4 1 0 keyinfo(1,BINAIRE) 0

20 Null 0 9 0 0

21 MakeRecord 4 1 9 0

22 IdxInsert 4 9 0 0

23 MakeRecord 5 1 9 0

24 IdxInsert 4 9 0 0

25 Rewind 4 53 0 0

26 la Colonne 4 0 6 0

27 IsNull 6 52 0 0

28 Affinité 6 1 0 aab 0

29 SeekGe 2 52 6 1 0

30 IdxGE 2 52 6 1 1

31 IdxRowid 2 9 0 0

32 Cherchent 0 9 0 0

33 Colonne 0 0 10 0

34 Colonne 2 1 11 0

35 Colonne 0 2 12 0

36 Colonne 0 3 13 0

37 Colonne 2 0 14 0

38 Colonne 0 5 15 0

39 Colonne 0 6 16 0

40 MakeRecord 10 7 9 0

41 Colonne 0 6 17 0

42 Séquence 1 18 0 0

43 Déplacer 9 19 1 0

44 MakeRecord 17 3 8 0

45 IdxInsert 1 8 0 0

46 IfZero 3 49 0 0

47 AddImm 3 -1 0 0

48 Goto 0 51 0 0

49 1 0 0 0

50 Supprimer 1 0 0 0

51 2 30 0 0

52 4 26 0 0

53 Fermer 0 0 0 0

54 Fermer 2 0 0 0

55 OpenPseudo 5 1 7 0

56 Tri 1 72 0 0

57 AddImm 2 -1 0 0

58 IfNeg 2 60 0 0

59 Goto 0 71 0 0

60 Colonne 1 2 9 0

61 Entier 1 8 0 0

62 Insérer 5 9 8 0

63 Colonne 5 0 10 0

64 Colonne 5 1 11 0

65 Colonne 5 2 12 0

66 Colonne 5 3 13 0

67 Colonne 5 4 14 0

68 Colonne 5 5 15 0

69 Colonne 5 6 16 0

70 ResultRow 10 7 0 0

71 1 57 0 0

72 Près de 5 0 0 0

73 Arrêt 0 0 0 0

74 Transaction 0 0 0 0

75 VerifyCookie 0 5 0 0

76 TableLock 0 2 0 FriendFeed 0

77 Goto 0 15 0 0

  • Je suppose que c'est juste une faute de frappe, mais le DDL vous a donné crée un tableau de Flux, mais les index d'une table appelée FriendFeed. Si c'est vraiment le cas, vous n'êtes pas d'indexation de la table que vous êtes en sélectionnant contre.
  • Ouais c'est une faute de frappe
  • Quelle est la cardinalité (ActivityType), (UserKey), et (ActivityType, UserKey)? Sont-ils pris en charge par des tables de référence dans lequel vous pourriez éventuellement stocker integer Id?
  • Ces bases de données seront stockées par l'utilisateur dans un système qui a beaucoup d'utilisateurs. Le stockage des tables de référence pour ces entraînerait une tonne de données dupliquées. Je peux utiliser un enum pour les types d'activité, mais UserKey pourrait être une valeur inconnue dans le contexte de ce jeu de données.
  • Après l'exécution de l'Analyser, j'ai réussi à obtenir de la requête jusqu'à 8 ms.
InformationsquelleAutor Alex Spence | 2010-02-16