Optimisation UNION VIEW

Bonjour,

J'ai deux tables de structure non identique, la première comporte 200000 lignes et la deuxième 500000.

Je crée une vue de l'union des deux tables:

Code:

---

1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31

CREATE ALGORITHM = UNDEFINED DEFINER = `root`@`%` SQL SECURITY DEFINER VIEW `v_sondenserie` AS SELECT `sonde_cf_mesureok`.`Nserie` AS `Nsonde`, `sonde_cf_mesureok`.`A` AS `A`, `sonde_cf_mesureok`.`B` AS `B`, `sonde_cf_mesureok`.`R0` AS `R0`, `sonde_cf_mesureok`.`Pente1` AS `Pente1`, `sonde_cf_mesureok`.`Pente2` AS `Pente2`, `sonde_cf_mesureok`.`DateTime` AS `datetime`, `sonde_cf_mesureok`.`Nposte` AS `nposte` FROM `sonde_cf_mesureok` WHERE (`sonde_cf_mesureok`.`Nserie` IS NOT NULL) UNION SELECT `sondemesure`.`NSonde` AS `Nsonde`, `sondemesure`.`A` AS `A`, `sondemesure`.`B` AS `B`, `sondemesure`.`R0` AS `R0`, `sondemesure`.`Pente1` AS `Pente1`, `sondemesure`.`Pente2` AS `Pente2`, `sondemesure`.`DATETIME` AS `datetime`, `sondemesure`.`NPoste` AS `nposte` FROM `sondemesure` WHERE (`sondemesure`.`NSonde` IS NOT NULL)

---

Maintenant si je fais des SELECT


Select table 1

Code:

---

SELECT * FROM bdprod.sonde_cf_mesureok where nserie=46014075641;

---

Réponse en 630ms et utilise l'index sur nserie

Select table 2

Code:

---

SELECT * FROM bdprod.sondemesure where NSonde=46014075641;

---

Réponse en 150ms et utilise l'index sur nsonde

Select view

Code:

---

SELECT * FROM bdprod.v_sondenserie where nsonde=46014075641;

---

Réponse en 5sec sans utilisation de l'index


Pourquoi lorsque je fais un SELECT avec une clause where bien précise, le temps de réponse de ma vue est si long?

parce que MySQL dispose du plus mauvais optimiseur par rapport à la concurrence ! Et en règle générale, c'est le moins performant....

A me lire : http://blog.developpez.com/sqlpro/p9...alles_en_sql_1
http://blog.developpez.com/sqlpro/p9...oudre_aux_yeux

A +

Bonjour clecle,

à noter que tu effectues un UNION (et non un UNION ALL) entre tes deux tables, ce qui indique au SGBD qu'il doit dédoublonner ton jeu de résultats (comme le ferait un DISTINCT), ce qui rallonge fatalement le temps de traitement.
Est-ce volontaire ?

Bonjour J1,

Effectivement, mais j'ai fais le test avec le UNION ALL et le gain n'était pas significatif.


Par contre j'utilise en production la version MySQL 5.1, les index ne sont pas utilisé dans la clause UNION, par contre j'ai réalisé des test avec la version 5.6 et enfin les index sont utilisé correctement,

Je vais donc migrer(updater) ma base de production.

Merci pour vos réponses