MS SQL Server
  1. MS SQL Server
  3. Pourquoi exactement les fonctions non-DB dans SQL Server sont-elles plus lentes?
Intereting Posts
Tentative d'attaque par injection SQL – qu'essaient-ils de faire? Dépannage du deployment du package Web IIS avec la database SQL Comment mettre à jour un caractère spécifique de la valeur de la colonne pour toutes les tables d'une database Fluent NHibernate many-to-many utilisant une colonne non-PK Requêtes de date SQL Copier la database SQL Server Express sur un autre ordinateur Mettre à jour le champ avec datatables d'une autre database Commande par et différents types dans un CAS Colonne, paramètre ou variable # 10: impossible de find le type de données erreur de réplication transactionnelle due à l'erreur du operating system 3 Problème de connection SQL Server 2008 SQL Si datatables ne sont pas trouvées dans une date similaire, obtenez la dernière date Obtenir le count de chaque valeur distincte dans SQL Server Taille de la page SQL Server 2000 et taille de la page NTFS répliquer des données d'une table en time réel vers une autre table dans SQL Server 2008R2?

Pourquoi exactement les fonctions non-DB dans SQL Server sont-elles plus lentes?

J'entends toujours que les fonctions non liées à la database (par exemple, la comparaison de strings, les loops) dans SQL Server sont lentes parce que, bien, c'est une database. Mais pourquoi exactement cela fait-il explorer ces methods par rapport aux langages de programmation complets?

La comparaison de strings n'est pas plus lente que dans n'importe quel programme compilé mais habituellement, vous comparez beaucoup de nombreuses strings (par exemple, chaque ligne d'une table) et c'est lent.

Comme pour les loops: La database n'est pas un compilateur. Il lit votre SQL et l'interprète ensuite. Si vous pouviez envoyer du code compilé et que la database l'exécute, vous ne remarquerez pas de différence de vitesse, mais la database doit interpréter le même code encore et encore.

Si vous avez de la chance, la database convertira une boucle en une forme interne (code octet ou structure de données) mais a) prend plus de time que de pointer le CPU vers un code et b) il lui faut encore plus de code interpréter le code d'octet ou la structure de données. Pour les loops, il faut évaluer les conditions pour chaque tour.

La database relationnelle est optimisée pour faire des choses dans des sets. Quelque chose comme un slider ou une boucle ou une sous-requête corrélée qui nécessite que la database fonctionne rangée par ligne sera plus lent, souvent douloureusement lent. Le rlocation de ce code par un code basé sur un set (le type que la database est conçue pour gérer au mieux) améliorera souvent la performance de quelques heures à quelques millisecondes.

Parce qu'ils sont interprétés au lieu d'être compilés en instructions machine / CPU.