Discussion :

[dari68]

Bonjour,

Pour les retours d'expériences sur V7 et V8 de MySQL: je cherche à savoir la taille max à partir de laquelle le moteur cale ....?

Merci.

A+

[SQLpro]

Cela ne dépend pas de la volumétrie directement mais, et dans l'ordre :

1. du respect des formes normale lors de la modélisation de la base
2. de l'indexation
3. de l'écriture des requêtes
4. du style du développement (bd épaisse ou tout dans l'application)

et d'autres problématiques hors de portée de MySQmerde... (partitionnement, compression, indexation verticale...)

A +

[Séb.]

Pour les retours d'expériences sur V7 et V8 de MySQL: je cherche à savoir la taille max à partir de laquelle le moteur cale ....?

Actuellement je travaille sur une base MySQL 8.0.32 de pas loin 80 Go, certaines tables avec plus de 120 millions de lignes, ça va, mais dans mon cas PostgreSQL fait mieux selon quelques tests effectués.
Parfois, lorsque les jointures sont "profondes", je dois jouer sur l'optimiseur pour que les requêtes aboutissent (tendance à faire les jointures avant d'appliquer le WHERE).
Dur de te donner davantage d'infos étant donné que tu n'exposes pas tes besoins.

MySQL 7 n'existe pas, et étant donné les avancées sur MySQL 8 il serait impensable d'utiliser une version antérieure.

[Artemus24]

Salut à tous.

Mysql 7 n'existe pas ! La dernière version de MySql est la 8.0.32.
Juste une précision, votre demande concerne bien Mysql et non MariaDB. Est-ce bien cela ?

Pour les questions de performances, je rejoins SQLPRO car la modélisation de votre base de données est un facteur important.
Il y a aussi la gestion de vos requêtes dans vos applications, ce qui pourrait être votre principale problématique.

Comme le dit Sébastien, il nous faudrait plus d'informations sur les problèmes que vous rencontrez.
Si la question concerne le choix d'un futur SGBR pour vos développements en fonction d'une grosse volumétrie, je vous conseille de passer à Microsoft SQL Server.

Cordialement.
Artemus24.
@+

[dari68]

Bonjour,

Merci SQLPRO, Merci SEB, Merci Artemus24 de vos retours respectifs.

Pardon: Séb je voulais dire v5.7, Artemus24 Oui c'est de MySQL, au passage dans cette version le dernier

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

alter table modify colonne ... not null

a pris ~ 30 min sur une table de ~ 11 millions de lignes ....

Je cherche à fournir aux équipes projets les limites de MySQL ...

A+

[Artemus24]

Salut Dari68.

Il aurait fallu désactiver les index pour gagner du temps.
Sinon, pourquoi ajouter une colonne sur une base de données en prod ?

Cordialement.
Artemus24.
@+

[escartefigue]

Parfois, lorsque les jointures sont "profondes", je dois jouer sur l'optimiseur pour que les requêtes aboutissent (tendance à faire les jointures avant d'appliquer le WHERE).

Ce phénomène se produit probablement avec des jointures à l'ancienne dont les critères sont dans le WHERE.
L'un des intérêts d'utiliser l'opérateur JOIN ON est non seulement de rendre la requête plus lisible (on ne confond plus restriction et jointure), mais aussi d'appliquer les critères de restriction sans passer par un produit cartésien des tables jointes.

[dari68]

Bonjour,

Merci Artemus24,

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Il aurait fallu désactiver les index pour gagner du temps.

Merci pour ce précieux conseil.

Code :

Sélectionner tout - Visualiser dans une fenêtre à part

Sinon, pourquoi ajouter une colonne sur une base de données en prod ?

Suite à une évolution applicative.

A+