0
votes

Le filtre de requête SQL Server avec la commande est lent

J'ai eu du mal avec cela pendant un moment.

J'ai une base de données avec trois tables (chacune ayant des millions d'enregistrements) comme suit (supprimé des colonnes de simplicité): P>

SELECT TOP 20
    1
FROM
    [Entity]
    INNER JOIN [EntityData] ON [Entity].[Id] = [EntityData].[Entity_Id]
    INNER JOIN [EntityLevel] ON [Entity].[EntityLevel_Id] = [EntityLevel].[Id]
WHERE
    [EntityLevel].[Sort] = 1
ORDER BY
    [EntityData].[Code]

sql sql-server indexing query-performance

7 commentaires

est trier = 1 un filtre commun? Un indice filtré sera utile pour cela. Juste une note que vous travaillez avec une base de données EAV ici qui sont bien connues pour les problèmes de performance et d'évolutivité


                                        
                                                                            Trier = 1 n'est pas un filtre courant, il est courant de filtrer par type, mais la valeur n'est pas courante, ce qui me manque de comprendre, c'est que c'est juste une jointure normale et la requête fonctionne très vite avec plusieurs conditons, mais ralentit avec la commande par et les deux filtres
                                        
                                                                            Il utilise un plan de requête différent. Lorsque vous les observez et essayez de vous entraîner de savoir pourquoi cela le fait, vous pouvez souvent le réparer. Très souvent, la mise à jour des statistiques le trie. Parfois, le problème est le paramètre reniflant
                                        
                                                                            Ok juste relire, il est réduit à la commande  par code ? Le code n'est pas la colonne principale de n'importe quel index, donc je suppose que la commande par (toujours une opération coûteuse) est le problème. Un indice en regroupement corrige généralement l'ordre par des problèmes de performance, mais vous en obtenez seulement un.

                                        
                                                                            Encore une fois, je dois commenter le design EAV  et  le GUID PK's. Cela semble être une idée fantastique à un développeur, mais à un DBA, ce n'est pas le cas.

                                        
                                                                            J'ai mis à jour les statistiques et le résultat est identique, ira la question et inclure le plan d'exécution réel
                                        
                                                                            Je comprends le problème EAV, mais cette requête spécifique est juste une jointure habituelle, la même chose si la table [entitydata] est autre chose (comme [personne]), et je peux essayer d'ajouter un index sur le code seul et voir le résultat



                                    
                    3 Réponses :
                    
                                            
                            
                                
                                    0
 votes
                                
                            
                            
                                
                                     Essayez des index sur 


  [entité] ([id], [entitylevel_id]) , 
  [entitydata] ([datalanguage_id], [entity_id], [code])  et 
  [entitylevel] ([Trier], [ID]) . 


 Expérience avec l'ordre des colonnes. Pour 2. et 3. J'ai supposé que  [entitydata]. [Datalanguage_id] = 'B6930015-F177-4ED3-97B0-AAEF401F9265'  et  [Entityllevel]. [Trier] = 1  dans le  où le filtre de la clause  plus que la jointure. Mais je ne connais pas les données et que l'hypothèse pourrait être fausse.                                 


                                                                    
                                    
                                    
                                        2 commentaires
                                        
                                                                                            
                                                    Je pourrais avoir quelque chose de mal, mais pouvez-vous s'il vous plaît expliquer pourquoi j'ai besoin d'index n ° 1, car il devrait exister déjà car [id] est pk et index en cluster ?, Indice n ° 3, pourquoi devrais-je inclure la colonne PK dans Un index? N'est-ce pas déjà inclus dans tous les index?, pour l'hypothèse, la requête fonctionne rapidement sans la commande par                                                
                                                
                                                                                            
                                                    @AhmedMsedeek: Je ne pouvais pas (et je ne peux toujours pas) trouver cette information dans votre message. Mais de toute façon, je ne sais pas si vous  besoin , vous devez tester cela pour vous-même. Je ne peux pas faire cela parce que je n'ai pas les données et tout. Il pense que cela pourrait peut-être aider la participation mieux que l'index en cluster, car il trie aussi par  [entititylevel_id] . Et puis il y a la possibilité, lors de la modification de la commande, comme je l'ai mentionné, que  ([iD])  est la meilleure option. L'index en cluster ne couvre pas du tout.                                                

                                                
                                                                                    

                                    

                                                            

                        

                        
                                            
                            
                                
                                    0
 votes
                                
                            
                            
                                
                                     Votre question concerne cette requête:  xxx  
 Je pense que le problème est que SQL Server ne peut pas utiliser l'index du tri. Vous pourriez être capable de contourner cela en utilisant  Exist :   xxx  
 pour cette version, vous souhaitez un index sur  entitylevel (id, tri ) .  
 Ceci  peut  permettre au moteur SQL d'utiliser l'index du tri (comme il semble faire dans d'autres cas). Bien sûr, vous ne pouvez pas sélectionner des colonnes à partir de  entitylevel  - mais vos exemples de requêtes ne font pas cela de toute façon.                                  


                                                                    
                                    
                                    
                                        0 commentaires
                                        
                                                                                    
                                    
                                                            

                        

                        
                                            
                            
                                
                                    0
 votes
                                
                            
                            
                                
                                     Pour toute personne concernée, c'est la solution au problème: 
 Il s'est avéré qu'avec beaucoup de lignes, ce qui prenait le temps est de créer des recherches clés et des matchs de hachage en raison de différents index. La solution était donc la solution. Pour ajouter l'index suivant pour permettre l'utilisation d'un seul index sur la table pour tous les valeurs du filtre (et de la commande par):   xxx  
 mais puisque je peux aussi filtrer par code dans certains Situations et non seulement utilisez la commande par, j'ai donc modifié l'index comme tel:   xxx                                  

                                                                    
                                    
                                    
                                        0 commentaires

Articles qui pourrait vous intéresser : Ordre des requêtes de syntaxe SQL par Problème de jointure sql, impossible de récupérer les enregistrements de la table a qui correspondent à une condition de la table b et les enregistrements restants de la table a Interroger les données de PostgreSQL à partir de deux tables Comment identifier les lignes par groupe avant un certain écart de valeur?