6
votes

(Bitwise) supersets et sous-ensembles dans MySQL

sont les requêtes suivantes efficaces dans MySQL: xxx

... Si un index du champ a été créé?

sinon, est-il un moyen de Faites-le courir plus vite?

optimization mysql subset bit-manipulation

1 commentaires

C'est une excellente question, mais vous devez accepter certaines de vos réponses - 20% ne vont pas inviter les gens à essayer de vous répondre

3 Réponses :

1
votes

Je doute que l'optimiseur entraîne une ...

Peut-être que vous pouvez appeler Expliquer sur ces requêtes et confirmer ma supposition pessimiste. (Se rappelant bien sûr que de nombreuses décisions de plan de requête sont basées sur l'instance spécifique d'une base de données donnée, c'est-à-dire des quantités variables de données et / ou de données simplement avec un profil statistique différent peuvent produire des plans distincts).

supposant que la table a une quantité importante de lignes et que les critères "bits bits" restent suffisamment sélectifs) une optimisation possible est obtenue lors de l'évolution d'une opération bit dans chaque rangée, en réécrivant la requête avec une construction (ou avec une jointure)

quelque chose comme ça (conceptuel, c'est-à-dire non testé) xxx

Les avantages complètes d'une approche de ce type doivent être évalués avec des cas d'utilisation différents (tous dont avec un nombre considérable de lignes dans le tableau, car l'approche directe "où champ | numéro = numéro" est suffisamment efficace), mais je soupçonne que cela pourrait être nettement plus rapide. Des gains supplémentaires peuvent être obtenus si les «TblfieldValues» n'ont pas besoin d'être recréés à chaque fois. La création efficace de ce tableau implique un indice sur le champ dans la table d'origine.

1 commentaires

C'est une solution qui devient de plus en plus intéressante pour la diminution du nombre de valeurs du champ. J'envisagerais de scinder un champ de Bigint dans un ensemble de champs d'tinytins juste pour l'intention de cette optimisation.

0
votes

J'ai essayé cela moi-même et les opérations bitwises ne suffisent pas pour empêcher MySQL d'utiliser un index sur la colonne "Champ". Cependant, il est probable qu'une analyse complète de l'indice a lieu.

0 commentaires

7
votes

mise à jour:

Voir cette entrée dans mon blog pour les détails de performance:

Opérations et index bitwise
xxx
Cet index peut être efficace de deux manières:
1. Pour éviter les analyses de table précoce (puisque la valeur à comparer est contenue dans l'index lui-même)
  
  limiter la gamme de valeurs examinées.
  aucun état dans les requêtes ci-dessus est sargable , il s'agit que l'index ne soit pas utilisé pour la balayage de la plage (avec les conditions telles qu'elles sont maintenant). < p> Cependant, point 1 est toujours en attente, et l'index peut être utile.
  Si votre table contient, dites, 100 octets par ligne en moyenne et 1 000 000 enregistrements, la numérisation de la table doit alors numériser 100 Mo de données.
  Si vous avez un index (avec un 4 -BYTE Touche, 6 -BYTE ROOKER POINTER ET UN DEVENTION INTERNE), la requête devra numériser uniquement 10 Mo de données plus des données supplémentaires de la table si le filtre réussit.
  La numérisation de la table est plus efficace si votre condition n'est pas sélective (vous avez une probabilité élevée pour correspondre à la condition). L'analyse de l'index est plus efficace si votre condition est sélective (vous avez une probabilité faible pour correspondre à la condition). Ces deux requêtes nécessiteront de numériser l'index entier. mais en réécrivant la requête et Vous pouvez également bénéficier de la distance sur l'index. Cette condition: champ et numéro = numéro ne peut correspondre aux champs que si les bits les plus élevés du numéro Set est défini dans le champ aussi. et vous devez simplement fournir cette condition supplémentaire à la requête: xxx p > Cela utilisera la plage de filtrage grossier et de la condition du filtrage fin. Plus les bits pour Number sont non définis à la fin, mieux c'est.

1 commentaires Il y a une optimisation possible pour ou aussi: "Champ | Number = Number" n'est jamais vrai si le champ a des bits plus élevés que les bits de Nombre de numéros. Donc: Sélectionnez * de la table où champ | Nombre = numéro et champ <2 << étage (log (2, numéro)); Je peux également imaginer des requêtes d'optimisation d'optimisation avec plus d'une plage en utilisant plus d'une des bits les plus élevées de champ. Une situation extrême serait lorsque chaque valeur du champ a été explicitement spécifiée (à l'aide de «champ» dans (valeur1, ...) »). Quoi qu'il en soit, c'est une bonne réponse.


                
		    
                    Articles qui pourrait vous intéresser :
                                            
                            Le moyen le plus rapide de trouver et de remplacer une ligne spécifique dans un gros fichier texte avec Python                        
                        
                                            
                            sans boucles à somme Plage de nombres impairs                        
                        
                                            
                            Étant donné un ensemble de points ou de vecteurs, trouvez l'ensemble de N points les plus proches les uns des autres                        
                        
                                            
                            Méthode plus rapide pour extraire et combiner des bits de UINT16 à UINT8