MySQL: Une requête recherche-t-elle à l'intérieur de la table entière?

Question

1. Donc, si je recherche le mot ball à l'intérieur de la table toys où j'ai 5.000.000 entrées-t-il rechercher tous les 5 millions?

Je pense que la réponse est oui, car comment devrait-il savoir d'autre, mais laissez-moi savoir s'il vous plaît.

2. Si yes: Si j'ai besoin de plus d'informations de cette table n'est pas plus logique d'interroger une seule fois et de travailler avec les résultats?

Un exemple

J'ai cette structure de table par exemple:

id | toy_name | state

Maintenant, je dois interroger comme ce

mysql_query("SELECT * FROM toys WHERE STATE = 1");

Mais n'est pas plus logique d'interroger pour toute la table mysql_query("SELECT * FROM toys"); puis faire if($query['state'] == 1)?

3. Et quelque chose d'autre, si je mets un ORDER BY id LIMIT 5 dans le mysql_query le rechercherons pour les 5 millions d'entrées ou seulement le dernier 5?

Merci pour les réponses.

Answer 1

1. Oui, sauf si vous avez une clause LIMIT, il parcourra toutes les lignes. Il effectuera une analyse de table à moins qu'il ne puisse utiliser un index.

2. Vous devriez utiliser une requête avec une clause WHERE ici, ne pas filtrer les résultats en PHP. Votre SGBDR est conçu pour être capable de faire ce genre de chose efficacement. Ce n'est que lorsque vous devez effectuer un traitement complexe des données qu'il est plus approprié de charger un ensemble de résultats dans PHP et de le faire à cet endroit. Avec le LIMIT 5, le SGBDR parcourra la table jusqu'à ce qu'il vous ait trouvé vos cinq lignes, puis il cessera de chercher. Donc, tout ce que je peux dire à coup sûr, c'est qu'il faudra compter entre 5 et 5 millions de lignes!

Answer 2

Lire ce sur les index :-)

http://dev.mysql.com/doc/refman/5.0/en/mysql-indexes.html

Il rend uber rapide :-)

scan de table est ici que s'il n'y a pas d'index correspondants et en effet l'opération très lente . Le tri est également accéléré par les index.

Et pour le # 2 - c'est lent parce que le taux de transfert de MySQL -> PHP est lent, et MySQL est beaucoup plus rapide à faire le filtrage.

Answer 3

Pour votre question # 1: Dépend de la façon dont vous recherchez 'balle'.S'il n'y a pas d'index sur la colonne (s) où vous recherchez, alors la table entière doit être lue. S'il y a un index, puis ...

1. WHERE field LIKE 'ball%' utilisera un indice
2. WHERE field LIKE '%ball%' sera PAS utiliser un index

Pour votre # 2, pensez de cette façon: Faire SELECT * FROM table puis en parcourant les résultats dans votre application est exactement le même que d'aller à la super walmart locale, en chargeant l'inventaire complet du magasin dans votre voiture, conduisant à la maison, en passant par chaque boîte/paquet, et jeter tout sauf le paquet de gomme de l'impulsif acheter rack par le front jusqu'à ce que vous vouliez en premier lieu. Le but d'une base de données est de faciliter la recherche de données et de filtrer par n'importe quel type de clause que vous pourriez penser. En glissant tout dans votre application et en y effectuant le filtrage, vous avez réduit cette base de données brillante à une interface de disque très coûteuse, et vous feriez probablement mieux de stocker les choses dans des fichiers plats. C'est pourquoi il y a des clauses WHERE. "CHOISISSEZ quelque chose du magasin où type = pack_of_gum" vous obtient juste la gomme, et ne vous oblige pas à transporter à la maison quelques milliers de bouteilles de shampoing et des sacs de litière pour chat.

Pour votre # 3, oui. Si vous avez une clause ORDER BY dans une requête LIMIT, l'ensemble de résultats doit être trié avant que la base de données puisse comprendre ce que ces 5 enregistrements doivent être. Bien que ce ne soit pas aussi grave que de transférer l'intégralité de l'ensemble d'enregistrements à votre application et de ne sélectionner que les cinq premiers enregistrements, cela implique encore un peu plus de travail que la simple récupération des 5 premiers enregistrements correspondant à votre clause WHERE.