IdentifiantMot de passe
Loading...
Mot de passe oublié ?Je m'inscris ! (gratuit)
Navigation

Inscrivez-vous gratuitement
pour pouvoir participer, suivre les réponses en temps réel, voter pour les messages, poser vos propres questions et recevoir la newsletter

Requêtes MySQL Discussion :

La requête UPDATE a-t-elle un buffer ou une taille de caractère limitée ?


Sujet :

Requêtes MySQL

Vue hybride

Message précédent Message précédent   Message suivant Message suivant
  1. #1
    Membre éprouvé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Avril 2009
    Messages
    1 478
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 478
    Par défaut La requête UPDATE a-t-elle un buffer ou une taille de caractère limitée ?
    bonjour,

    j'ai un étrange bug ou plutôt comportement aléatoire qui ne produit pas d'erreur:

    j'ai une table basique avec un champ gros_texte de type 'text' (en codage utf8mb4_general_ci au cas où c'est important à savoir).

    je fais des requêtes simple de type :

    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    update matable set gros_texte="blabla" where ma_cle=5
    quand je mets un blabla simple de qq caractères, la requête marche et met bien à jour son champ dans la table : 1 row affected
    quand je mets un blabla de 8 lignes, la requête fonctionne sans retourner d'erreur mais affiche un " 0 row affected" et le champ n'est pas mis à jour


    j'obtiens le retour "0 row affected" en testant dans phpmyadmin la requête, mais dans le process réel, je n'ai aucun retour d'erreur. je vois juste que la mise à jour n'est pas faite.
    d'où ça peut venir ? une histoire de buffer ou paramètre à régler ? ce serait étrange car si yavait un buffer ou une taille limite de la requête, la fin " where ma_cle=5" serait tronquée et ça créerait une vrai erreur.

    une idée du problème ?

  2. #2
    Expert confirmé
    Avatar de Séb.
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    5 347
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2005
    Messages : 5 347
    Billets dans le blog
    17
    Par défaut
    Teste sur un vrai client MySQL
    => En ligne de commande, ou via MySQL Workbench

    Il y a le paramètre max_allowed_packet qui peut limiter la taille des requêtes
    https://dev.mysql.com/doc/refman/8.0...allowed_packet
    Tes 8 lignes sont peut-être très longues ou ton hébergeur *très* restrictif (par défaut max à 64 Mo)

  3. #3
    Membre éprouvé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Avril 2009
    Messages
    1 478
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 478
    Par défaut
    sur le serveur de prod, j'ai tenté
    Code sql : Sélectionner tout - Visualiser dans une fenêtre à part
    SHOW VARIABLES LIKE 'max_allowed_packet';
    et me retourne:
    max_allowed_packet 67108864
    en local sur mon xamp de dev, ça me retourne :

    1048576


    La doc ne dit pas ce qu'il se passe en cas de valeur dépassée, c'est dommage, je ne sais pas ça vient de là ou pas .

  4. #4
    Expert confirmé
    Avatar de Séb.
    Profil pro
    Inscrit en
    Mars 2005
    Messages
    5 347
    Détails du profil
    Informations personnelles :
    Âge : 47
    Localisation : France

    Informations professionnelles :
    Secteur : High Tech - Opérateur de télécommunications

    Informations forums :
    Inscription : Mars 2005
    Messages : 5 347
    Billets dans le blog
    17
    Par défaut
    1 Mo c'est très peu. Ça peut vite bloquer si tu fais des INSERT de masse type :

    INSERT INTO ta_table (col1, col2, col3)
    VALUES (val1, val2, val3), (val1, val2, val3), (val1, val2,  val3), ...
    De mémoire il y a un message d'erreur spécifique.

    Vérifie les logs MySQL et teste avec un vrai client.

  5. #5
    Membre Expert
    Profil pro
    Inscrit en
    Mai 2006
    Messages
    721
    Détails du profil
    Informations personnelles :
    Localisation : Belgique

    Informations forums :
    Inscription : Mai 2006
    Messages : 721
    Par défaut
    Il n'y a peut-être pas d'erreur, mais il peut y avoir des warnings. Donc oui, tester en ligne de commande et on peut injecter un fichier avec le SQL dedans pour plus de commodité.

  6. #6
    Membre éprouvé
    Avatar de clavier12AZQSWX
    Homme Profil pro
    Technicien maintenance
    Inscrit en
    Avril 2009
    Messages
    1 478
    Détails du profil
    Informations personnelles :
    Sexe : Homme
    Âge : 48
    Localisation : France, Somme (Picardie)

    Informations professionnelles :
    Activité : Technicien maintenance

    Informations forums :
    Inscription : Avril 2009
    Messages : 1 478
    Par défaut
    bon,

    j'ai regardé mon log local mysql_error.log (là où j'ai la plus petite valeur) et je n'ai pas d'erreur ER_NET_PACKET_TOO_LARGE


    InnoDB: using atomic writes.
    2023-08-07 9:37:08 0 [Note] InnoDB: Mutexes and rw_locks use Windows interlocked functions
    2023-08-07 9:37:08 0 [Note] InnoDB: Uses event mutexes
    2023-08-07 9:37:08 0 [Note] InnoDB: Compressed tables use zlib 1.2.11
    2023-08-07 9:37:08 0 [Note] InnoDB: Number of pools: 1
    2023-08-07 9:37:08 0 [Note] InnoDB: Using SSE2 crc32 instructions
    2023-08-07 9:37:08 0 [Note] InnoDB: Initializing buffer pool, total size = 16M, instances = 1, chunk size = 16M
    2023-08-07 9:37:08 0 [Note] InnoDB: Completed initialization of buffer pool
    2023-08-07 9:37:08 0 [Note] InnoDB: Starting crash recovery from checkpoint LSN=462122826
    2023-08-07 9:37:11 0 [Note] InnoDB: 128 out of 128 rollback segments are active.
    2023-08-07 9:37:11 0 [Note] InnoDB: Removed temporary tablespace data file: "ibtmp1"
    2023-08-07 9:37:11 0 [Note] InnoDB: Creating shared tablespace for temporary tables
    2023-08-07 9:37:11 0 [Note] InnoDB: Setting file 'C:\xampp\mysql\data\ibtmp1' size to 12 MB. Physically writing the file full; Please wait ...
    2023-08-07 9:37:11 0 [Note] InnoDB: File 'C:\xampp\mysql\data\ibtmp1' size is now 12 MB.
    2023-08-07 9:37:11 0 [Note] InnoDB: Waiting for purge to start
    2023-08-07 9:37:11 0 [Note] InnoDB: 10.4.8 started; log sequence number 462122835; transaction id 60578
    2023-08-07 9:37:11 0 [Note] InnoDB: Loading buffer pool(s) from C:\xampp\mysql\data\ib_buffer_pool
    2023-08-07 9:37:11 0 [Note] Plugin 'FEEDBACK' is disabled.
    2023-08-07 9:37:11 0 [Note] InnoDB: Buffer pool(s) load completed at 230807 9:37:11
    2023-08-07 9:37:11 0 [Note] Server socket created on IP: '::'.
    InnoDB: using atomic writes.
    je vais voir si je peux tester en dehors du serveur.

+ Répondre à la discussion
Cette discussion est résolue.

Partager

Partager
  • Envoyer la discussion sur Viadeo
  • Envoyer la discussion sur Twitter
  • Envoyer la discussion sur Google
  • Envoyer la discussion sur Facebook
  • Envoyer la discussion sur Digg
  • Envoyer la discussion sur Delicious
  • Envoyer la discussion sur MySpace
  • Envoyer la discussion sur Yahoo