MySQL lock table

52 réponses

Page 1 23

Auteur	Message
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 14/02/2012 à 12:46 A moins que tu ais activé la suppression des commentaires SQL (query_cache_strip_comments=1, disponible uniquement dans MariaDB et PerconaServer je crois), ton commentaire invalide le cache de requête MySQL. Tu ne peux pas le supprimer ? daevel : infogérance et conseil \|\| moi
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 14/02/2012 à 13:58 ... La moitié de mes requêtes ont des commentaires insérés automatiquement pour traquer les pages contenant des requêtes lentes... J'ai viré, on va voir si ca change des trucs EDIT : tu es sur de ton coup ? "Avant MySQL 5.0, une requête qui commence avec un commentaire peut être mise en cache, mais ne sera jamais lue depuis le cache. Ce problème est résolu en MySQL 5.0." JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 14/02/2012 à 14:06 En fait MySQL fait un hash de la requête complète pour utiliser le cache de requête. Donc si ton commentaire est fixe, du genre __FILE__.':'.__LINE__ c'est tout bon, ça devrait marcher, mais si c'est un truc qui change en fonction des pages comme ça a l'air d'être le cas ici, et bien tu changes l'identifiant de la requete en permanence. cf : http://www.percona.com/doc/percona-server/5.5/perf... /* first query / select name from users where users.name like 'Bob%'; / retry search */ select name from users where users.name like 'Bob%'; By default (option off), the queries are considered different, so the server will execute them both and cache them both. If the option is enabled, the queries are considered identical, so the server will execute and cache the first one and will serve the second one directly from the query cache. daevel : infogérance et conseil \|\| moi
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 14/02/2012 à 14:12 Ok, ca va mettre pas mal de requetes en cache, mais pour mes requetes lentes, ca va rien changer puisque la requete et en fonction des parametres passés dans l'URL. JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 14/02/2012 à 14:22 Parce que l'index double conseillé par tonguide n'a pas résolu ce problème de perf ? daevel : infogérance et conseil \|\| moi
devtribu \| Olivier Modérateur Inscrit le : 16/06/2005	# Le 14/02/2012 à 14:26 Par défaut il doit mettre toutes les requetes en cache sauf quand la requete sera forcément unique (ex : il y a des données de timestamp de type NOW) Apres il faut que ca soit utile de le mettre en cache Si tu mets un timer dans ta requete, il n'y a aucune chance qu'une requete identique soit appelee plus tard A la place de l'index double, j'essaierai un index simple sur projet_id Ca doit prendre moins de 10ms une requete comme ca avec le bon index Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 14/02/2012 à 14:28 Si ! Mais les photos c'est assez complexe, beaucoup de requêtes différentes suivant le type de photos, etc ... Ca va me prendre du temps 1 - d’arrêter de bosser à l'aveugle et vraiment me documenter sur les clefs 2 - mettre tout ça en place. Je pense néanmoins que les petits optimisations (clefs, cache, innodb) vont vraiment changer les choses. Merci à tous, je vous tiens au courant JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 14/02/2012 à 14:39 Avant il y avait un index simple sur projet_id et un autre sur etat. Il se servait des deux et ca prenait 100ms JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 14/02/2012 à 23:58 Bon bah super, la machine n'a pas dépassé 1 de load average sur la journée avec 5 thread en moyenne. C'est bon ça J'optimise un peu mes requetes et je peux repasser sur un kimsufi JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 09/03/2012 à 11:17 C'est moi ou les insert avec innodb sont plus lents ? J'ai une table de 128 000 000 d'entrées, avec 2 clefs, ca prend un temps fou les inserts. JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes
PyRoFlo \| Florent Modérateur Inscrit le : 09/05/2005	# Le 09/03/2012 à 16:08 Déjà rien que les contraintes de référence à vérifier (chose que ne fait pas MyISAM), ça prend du temps oui. Feu d'artifice Paris
Bool \| Olivier Modérateur Inscrit le : 09/05/2005	# Le 09/03/2012 à 17:27 Le partitionnement de table peut réduire ça fortement, mais comme dit dob, faudrait que tu sois un peu plus précis JC. daevel : infogérance et conseil \|\| moi
krucial \| Jean Christophe Administrateur Inscrit le : 09/03/2005	# Le 09/03/2012 à 18:08 J'ai une table MOT qui liste tous les mots utilisés dans le forum (700 000) et une table MATCH qui associe chaque mot à un message du forum (128M). Inserer les mots d'un message dans MATCH semble prendre 1-2 seconde environ. Je vais approfondir, mais je voulais juste savoir si INNODB etait moins rapide a gérer les insert avec key que myisam JC - Mes sites \| Affiliation devis travaux \| Cotes voitures anciennes

Auteur

Message

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 14/02/2012 à 12:46

A moins que tu ais activé la suppression des commentaires SQL (query_cache_strip_comments=1, disponible uniquement dans MariaDB et PerconaServer je crois), ton commentaire invalide le cache de requête MySQL. Tu ne peux pas le supprimer ?

daevel : infogérance et conseil || moi

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 14/02/2012 à 13:58

...

La moitié de mes requêtes ont des commentaires insérés automatiquement pour traquer les pages contenant des requêtes lentes... J'ai viré, on va voir si ca change des trucs

EDIT : tu es sur de ton coup ? "Avant MySQL 5.0, une requête qui commence avec un commentaire peut être mise en cache, mais ne sera jamais lue depuis le cache. Ce problème est résolu en MySQL 5.0."

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 14/02/2012 à 14:06

En fait MySQL fait un hash de la requête complète pour utiliser le cache de requête. Donc si ton commentaire est fixe, du genre __FILE__.':'.__LINE__ c'est tout bon, ça devrait marcher, mais si c'est un truc qui change en fonction des pages comme ça a l'air d'être le cas ici, et bien tu changes l'identifiant de la requete en permanence.

cf : http://www.percona.com/doc/percona-server/5.5/perf...

/* first query  */ select name from users where users.name like 'Bob%';

/* retry search */ select name from users where users.name like 'Bob%';

By default (option off), the queries are considered different, so the server will execute them both and cache them both.

If the option is enabled, the queries are considered identical, so the server will execute and cache the first one and will serve the second one directly from the query cache.

daevel : infogérance et conseil || moi

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 14/02/2012 à 14:12

Ok, ca va mettre pas mal de requetes en cache, mais pour mes requetes lentes, ca va rien changer puisque la requete et en fonction des parametres passés dans l'URL.

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 14/02/2012 à 14:22

Parce que l'index double conseillé par tonguide n'a pas résolu ce problème de perf ?

daevel : infogérance et conseil || moi

devtribu | Olivier
Modérateur

Inscrit le : 16/06/2005

# Le 14/02/2012 à 14:26

Par défaut il doit mettre toutes les requetes en cache sauf quand la requete sera forcément unique (ex : il y a des données de timestamp de type NOW)

Apres il faut que ca soit utile de le mettre en cache
Si tu mets un timer dans ta requete, il n'y a aucune chance qu'une requete identique soit appelee plus tard

A la place de l'index double, j'essaierai un index simple sur projet_id
Ca doit prendre moins de 10ms une requete comme ca avec le bon index

Février 2019, mon futur livre Tout JavaScript chez Dunod https://amzn.to/2PoLd0f

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 14/02/2012 à 14:28

Si ! Mais les photos c'est assez complexe, beaucoup de requêtes différentes suivant le type de photos, etc ... Ca va me prendre du temps 1 - d’arrêter de bosser à l'aveugle et vraiment me documenter sur les clefs 2 - mettre tout ça en place. Je pense néanmoins que les petits optimisations (clefs, cache, innodb) vont vraiment changer les choses.

Merci à tous, je vous tiens au courant

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 14/02/2012 à 14:39

Avant il y avait un index simple sur projet_id et un autre sur etat. Il se servait des deux et ca prenait 100ms

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 14/02/2012 à 23:58

Bon bah super, la machine n'a pas dépassé 1 de load average sur la journée avec 5 thread en moyenne. C'est bon ça J'optimise un peu mes requetes et je peux repasser sur un kimsufi

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 09/03/2012 à 11:17

C'est moi ou les insert avec innodb sont plus lents ?

J'ai une table de 128 000 000 d'entrées, avec 2 clefs, ca prend un temps fou les inserts.

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

PyRoFlo | Florent
Modérateur

Inscrit le : 09/05/2005

# Le 09/03/2012 à 16:08

Déjà rien que les contraintes de référence à vérifier (chose que ne fait pas MyISAM), ça prend du temps oui.

Feu d'artifice Paris

Bool | Olivier
Modérateur

Inscrit le : 09/05/2005

# Le 09/03/2012 à 17:27

Le partitionnement de table peut réduire ça fortement, mais comme dit dob, faudrait que tu sois un peu plus précis JC.

daevel : infogérance et conseil || moi

krucial | Jean Christophe
Administrateur

Inscrit le : 09/03/2005

# Le 09/03/2012 à 18:08

J'ai une table MOT qui liste tous les mots utilisés dans le forum (700 000) et une table MATCH qui associe chaque mot à un message du forum (128M). Inserer les mots d'un message dans MATCH semble prendre 1-2 seconde environ. Je vais approfondir, mais je voulais juste savoir si INNODB etait moins rapide a gérer les insert avec key que myisam

JC - Mes sites | Affiliation devis travaux | Cotes voitures anciennes

Page 1 23

Répondre

Vous ne pouvez pas participer au forum, car votre inscription n'a pas été validée. Pour vous faire valider en tant que Membre, cliquez ici.