SELECT AVEC LIKE

Bonjour

J'avais peur que la non performance soit une mauvaise efficacité en terme de
résultat de recherche
par contre je suppose que ça ne sert à rien que je déclare en fulltext des
champs sur lesquels je ne fais que des requêtes en LIKE

Sais-tu où l'on peut trouver un comparatif de performances mySQL et
PostgreSQL (livre ou web) ?

Merci

Bernard


"Jacques Caron" <jc@imfeurope.com> a écrit dans le message de news:
opslk0lprlzscttn@news.free.fr...
| On Wed, 2 Feb 2005 18:37:32 +0100, Bernard Le Lann
| <bernard.lelann@tiscali.fr> wrote:
|
| > J'utilise pas mal le LIKE sous mySQL aussi j'aimerais savoir comment
(ou
| > pourquoi) LIKE est par nature non performant.
|
| Parce qu'il ne peut pas utiliser d'index (sauf cas particuliers). Ainsi,
| si tu fais une requête du type:
|
| SELECT * FROM table WHERE champ=X
|
| et que tu as un index sur table(champ), alors cet index sera utilisé pour
| aller directement au(x) bon(s) enregistrements. Ca représente quelques
| blocs à lire sur disque au maximum (s'ils ne sont pas déjà en cache).
|
| Si tu fais une requête du type:
|
| SELECT * FROM table WHERE champ LIKE '%X%'
|
| Alors le seul moyen pour le serveur SQL c'est de lire tous les
| enregistrements de la table un par un, regarder s'ils correspondent ou
| pas, et passer au suivant. Sur une table un tant soit peu importante,
| c'est nettement moins performant.
|
| PostgreSQL sait utiliser un index pour une requête du type:
|
| SELECT * FROM table WHERE champ LIKE 'X%'
|
| (i.e. le champ doit absolument commencer par X)
|
| Mais ce n'est pas valable pour un LIKE '%X' ou un '%X%'. Je suppose que
| c'est pareil pour MySQL.
|
| Evidemment, si tu n'as pas d'index sur ta table, ça ne change pas grand
| chose (un chouïa de CPU quand même), mais là on ne peut plus rien pour toi
| ;->
|
| Jacques.
| --
| Interactive Media Factory
| Création, développement et hébergement
| de services interactifs: SMS, SMS+, Audiotel...
| http://www.imfeurope.com/

Le Thu, 03 Feb 2005 16:28:50 +0100, Bernard Le Lann a écrit :

Sais-tu où l'on peut trouver un comparatif de performances mySQL et
PostgreSQL (livre ou web) ?

C'est sujet à controverses :-)

Personnellement:
- mySQL : bien pour beaucoup de lectures, peu d'accès simultanés
(exemple typique: cache)
- postgreSQL : bien pour accès concurrents et aspects transactionnels
(et support correct de l'internationalisation)

Donc chaque outil est perfomant... dans un certain cadre.

--
Patrick Mevzek . . . . . . Dot and Co (Paris, France)
<http://www.dotandco.net/> <http://www.dotandco.com/>
Dépêches sur le nommage <news://news.dotandco.net/dotandco.info.news>

Patrick Mevzek a dit le 03/02/2005 à 16:43:

Personnellement:
- mySQL : bien pour beaucoup de lectures, peu d'accès simultanés
(exemple typique: cache)
- postgreSQL : bien pour accès concurrents et aspects transactionnels
(et support correct de l'internationalisation)

MySQL supporte parfaitement les transactions, et a un bon support des
charsets et des collations.

Bernard Le Lann a dit le 03/02/2005 à 16:28:

par contre je suppose que ça ne sert à rien que je déclare en fulltext des
champs sur lesquels je ne fais que des requêtes en LIKE

Justement, si tu passes en fulltext, tu n'utilises plus LIKE, mais un
outil plus puissant.

loufoque wrote:

MySQL supporte parfaitement les transactions, et a un bon support des
charsets et des collations.

uniquement en InnoDb pour les transactions et avec de mauvaises perfs à
la clef

nofuture a dit le 03/02/2005 à 19:59:

uniquement en InnoDb pour les transactions et avec de mauvaises perfs à
la clef

MyISAM est effectivement plus rapide, mais faut pas exagérer non plus,
les perfs ne sont pas si mauvaises.