Moteur de recherche
Pour exclure des mots de votre recherche, vous devez ajouter des signes '-' devant ces mots là.
Exemple : une recherche 'apache -mysql' recherchera tout ce qui contient le mot 'apache' mais pas le mot 'mysql'.
Vous être un utilisateur de Firefox ? Ajouter le moteur de recherche du site à votre navigateur favori !
Résultats de votre recherche dans le manuel MySQL
page 1 page 2
- Manuel MySQL
# 112 : 1.5.7. Erreurs connues, et limitations de MySQL
# 444 : 5.6.4. Limiter les ressources utilisateurs
# 594 : 7.1.1. Limitations et inconvénients des choix conceptuels de MySQL
# 632 : 7.2.12. Comment MySQL optimise LIMIT
# 1206 : 14.6.4. Limitations du moteur de stockage FEDERATED
# 1438 : 16.8. Cluster Limitations in MySQL 4.1 - Chapitre 16. Introduction à MySQL Cluster - Manuel MySQL
# 93 : 16.8. Cluster Limitations in MySQL 4.1
# 697 : mysql> SELECT Name, Population FROM City ORDER BY Population DESC LIMIT 5;
# 739 : LIMIT 5";
# 1538 : Des paramètres similairse existents dans le module Dblqh pour gérer les lectures et modifications lorsque les données ont été localisées. Dans Dblqh.hpp avec ZATTRINBUF_FILESIZE qui vaut 10000*128 octets (1250ko) et ZDATABUF_FILE_SIZE, qui vaut 10000*16 octets (environ 156ko). Nous n'avons aucune connaissance de situation qui soient limitées par ces valeurs.
# 1547 : Ce paramètre est utilisé pour contrôler la quantité de scans paralelles qui sont effectués dans le cluster. Chaque coordination de transaction peut gérer un certain nombre de scan de tables simultanément, et ce nombre est limité par cette option. Chaque partition va utiliser une ligne de scan dans le noeud où la partition est située. Le nombre de lignes est la taille de ce paramètre multiplié par le nombre de noeuds, ce qui fait que le cluster peut supporter le nombre maximal de scan, multiplié par le nombre de noeuds du cluster.
# 1600 : Ce paramètre limite le nombre de fichiers de trace qui seront conservés sur le serveur, avant de remplacer un ancien fichier de trace. Les fichiers de trace sont générés lorsque le noeud crash pour une raison donnée.
# 1628 : La valeur par défaut pour ce paramètre est 128. La valeur minimale est de 8, et il n'y a pas de maximum. Il y a des limitations internes, qui empêchent d'aller au dela de 1600. Chaque objet de table consomme environs 20ko de mémoire par noeud.
# 1655 : Ce paramètre limite le nombre d'objet trigger dans le cluster.
# 1816 : Par défaut, ce paramètre ne limite pas l'arrivée des données. Pour des cluster en production, qui doivent s'assurer qu'aucune transaction ne bloque le serveur durant trop longtemp, il faut utiliser une valeur basse. L'unité est la millisecondes.
# 1823 : Lorsqu'une transactioon est implique dans l'exécution d'une requête, elle attend les autres noeuds. Si les autres noeuds ne répondent pas, il peut se passer 3 choses. Premièrement, le noeud peut être mort; deuxièment, l'opération peut être placée dans une file d'attente de verrou; troisièmement, le noeud impliqué peut être surchargé. Ce paramètre limite la durée de l'attente avant d'annuler la transaction. - Annexe B. Crédits - Manuel MySQL
# 898 : Rhys Jones <rhys@wales.com> (et GWE Technologies Limited)
# 1052 : Konark IA-64 Centre of Persistent Systems Private Limited
# 2113 : Permettre toutes les variables SQL dans la clause LIMIT, comme LIMIT @a,@b.
# 2270 : SQL_OPTION MAX_SELECT_TIME=# pour donner une limite de temps à une requête.
# 2280 : Améliorer LIMIT pour permettre la lecture de données à la fin du résultat. - Chapitre 12. Fonctions à utiliser dans les clauses SELECT et WHERE - Manuel MySQL
# 547 : Notez que les conversions précédentes peuvent produire des résultats étranges dans certains cas limites :
# 1360 : Retourne une portion de la chaîne de caractères str, située avant count occurrences du délimiteur delim. Si l'argument count est positif, tout ce qui précède le délimiteur final sera retourné. Si l'argument count est négatif, tout ce qui suit le délimiteur final sera retourné :
# 2087 : -> ORDER BY RAND() LIMIT 1000;
# 2490 : MySQL autorise tous les signes de ponctuation, comme délimiteur dans le format de expr. Ceux qui sont affichés dans la table sont des suggestions. Si l'argument date est une valeur DATE et que vos calculs impliquent des parties YEAR, MONTH et DAY (c'est à dire, sans partie horaire), le résultat sera de type DATE. Sinon, le résultat est de type DATETIME :
# 3909 : Recherche les lignes qui contiennent exactement la phrase ``deux mots'' (par exemple, les lignes qui contiennent ``deux mots d'amour'' mais pas ``le mot deux''). Notez que les caractères ‘"’ qui entourent la phrase délimitent la phrase. Ils ne délimitent pas la chaîne.
# 4792 : Une commande SELECT peut inclure une clause LIMIT pour restreindre le nombre de lignes qui sera retournée par le client. Dans certains cas, il est mieux de savoir combien de lignes une commande aurait retourné, sans la clause LIMIT, mais sans lancer à nouveau le calcul. Pour cela, ajoutez l'option SQL_CALC_FOUND_ROWS dans la commande SELECT, puis appelez FOUND_ROWS() après :
# 4795 : -> WHERE id > 100 LIMIT 10;
# 4799 : Le second SELECT retourne un nombre indiquant combien de lignes le premier SELECT aurait retourné s'il n'avait pas été écrit avec une clauseLIMIT.
# 4801 : Notez que si vous utilisez SELECT SQL_CALC_FOUND_ROWS ..., MySQL calcule toutes les lignes dans la liste des résultats. Ainsi, c'est plus rapide si vous n'utilisez pas de clause LIMIT et que la liste des résultats n'a pas besoin d'être envoyée au client. Si la commande SELECT précédente n'inclut pas l'option SQL_CALC_FOUND_ROWS, alors FOUND_ROWS() pourrait retourner une valeur différente suivant que LIMIT est utilisé ou pas.
# 4803 : SQL_CALC_FOUND_ROWS et FOUND_ROWS() peuvent être pratiques dans des situations où vous devez limiter le nombre de lignes que la requête retourne, mais que vous devez tout de même connaître le nombre de ligne total, sans exécuter une seconde requête. Un exemple classique est un script web qui présente des résultats de recherche. En utilisant FOUND_ROWS(), vous connaîtrez facilement le nombre de lignes de résultat. - Chapitre 19. Procédures stockées et fonctions - Manuel MySQL
# 75 : L'implémentation des procédures stockées de MySQL est en cours de développement. Toutes les syntaxes décrites dans ce chapitre sont supportées, et les limitations ou extensions sont documentés lorsque c'est nécessaire.
# 213 : Note : Actuellement, les fonctions stockées FUNCTIONs ne doivent pas contenir de références aux tables. Notez que cela inclut aussi les commandes SET, mais pas les commandes SELECT. Cette limitation sera supprimée aussitôt que possible.
# 215 : L'exemple suivant est une procédure stockée simple, qui utilise un paramètre de sortie OUT. L'exemple utilise la commande delimiter du client mysql pour modifier le délimiteur de commande avant de définir la procédure. Cela permet au délimiteur ; d'être utilisé dans le corps de la procédure, plutôt que d'être interprété par le client mysql.
# 217 : mysql> delimiter |
# 240 : mysql> delimiter |
# 381 : Les commandes multiples requièrent un client capable d'envoyer des requêtes contenant le caractère ‘;’. C'est géré dans le client en ligne de commande mysql, avec la commande delimiter. En changeant le caractère de fin de requête ‘;’ pour le remplacer par ‘|’ permet à ‘;’ d'être utilisé dans le corps de la routine.
# 465 : SELECT id,data INTO x,y FROM test.t1 LIMIT 1;
# 565 : mysql> delimiter |
# 877 : mysql> delimiter | - Chapitre 15. Le moteur de tables InnoDB - Manuel MySQL
# 166 : Techniquement, InnoDB est un gestionnaire de table placé sous MySQL. InnoDB dispose de son propre buffer pour mettre en cache les données et les index en mémoire centrale. InnoDB stocke les tables et index dans un espace de table, qui peut être réparti dans plusieurs fichiers. Ceci diffère des tables comme, par exemple, MyISAM où chaque table est stockée dans un fichier différent. Les tables InnoDB peuvent prendre n'importe quelle taille, même sur les systèmes d'exploitation dont la limite est de 2 Go par fichier.
# 621 : Les pointeurs de fichiers utilisés par .ibd sont réservés pour InnoDB. Ils sont indépendants de ceux spécifiés par --open-files-limit, et n'affectent pas les opérations de cache.
# 628 : InnoDB essaie de garder le nombre de thread système concurents inférieur à la limite de ce paramètre. La valeur par défaut est 8. Si vous avez des problèmes de performances, et que SHOW INNODB STATUS revèle que des threads attendent des sémaphores, essayez de diminuer ou augmenter ce paramètre. Si vous avez un serveur avec de nombreux processeurs et disques, vous pouvez essayer d'augmenter la valeur, pour utiliser au mieux les ressources disponibles. Une vlaeur recommandée est la somme du nombre de processeurs et de disques que vous avez. Une valeur de 500 ou supérieur, supprime la vérification de concurence. Cette option a été ajoutée depuis MySQL 3.23.44 et 4.0.1.
# 1055 : Il y a des limitations mineures à la réplication InnoDB :
# 1065 : Avant MySQL 4.0.6, SLAVE STOP ne respectait la limite de transaction. Une transaction incomplète était annulée, et la prochaine commande SLAVE START n'exécutait que le reste de la transaction, ce qui conduisait à un échec.
# 1081 : La plupart de ces limitations peuvent être levées en utilisant un serveur récent, pour lequel les limitations n'existent pas.
# 1908 : Limitez votre utilisation des verrous. Si vous pouvez vous permettre de faire retourner à une commande SELECT des données un peu anciennes, n'ajoutez pas la clause FOR UPDATE ou LOCK IN SHARE MODE. Utiliser le niveau d'isolation READ COMMITTED est bon ici, car chaque lecture cohérente dans la même transaction lira avec des données aussi fraîches que possible à chaque fois.
# 1951 : Si l'outil Unix top ou si le Task Manager de Windows montre que l'utilisation du CPU, lors de la charge de travail, est inférieure à 70%, votre calcul est probablement limité par les disques. Vous faites peut être trop d'écriture de transaction, ou le tampon de traitement ("buffer pool") est peut être trop petit. Augmenter la taille du tampon peut aider, mais il ne faut pas qu'il dépasse 80% de la mémoire physique.
# 1998 : Attention aux annulations lors des insertions de masse : InnoDB utilise une buffer d'insertion pour éviter les accès disques, mais la fonction d'annulation correspondante n'utilise pas ce mécanisme. Une annulation qui utilise beaucoup d'accès disque est environ 30 fois plus lente que l'insertion équivalent. Interrompre la base ne va pas aider, car l'annulation reprendra lors du redémarrage de la base. La seule solution pour ce débarasser de cette annulation lénifiante est d'augmenter la taille du pool de buffer, pour que l'annulation soit limitée par le processeur et non plus par le disque. Ou alors, effacez toute la base InnoDB. See Section 15.9.1, « Forcer la restauration ».
# 3281 : Sur certains systèmes d'exploitation, le fichier de données est limité à 2 Go. - Index - Manuel MySQL
# 554 : known, Erreurs connues, et limitations de MySQL
# 1640 : delayed_insert_limit, Syntaxe de INSERT DELAYED
# 1690 : issues, Erreurs connues, et limitations de MySQL
# 1692 : limitations, Limitations et inconvénients des choix conceptuels de MySQL
# 2028 : known, Erreurs connues, et limitations de MySQL
# 2178 : size limits, Quelles tailles peuvent atteindre les tables MySQL
# 2886 : known errors, Erreurs connues, et limitations de MySQL
# 2968 : LIMIT, Comment MySQL optimise LIMIT, Fonctions d'informations
# 2970 : limitations
# 2974 : design, Limitations et inconvénients des choix conceptuels de MySQL - Chapitre 3. Tutoriels d'introduction - Manuel MySQL
# 1568 : Tout comme la table animal, il est facile d'enregistrer les enregistrements initiaux en créant un fichier texte délimité par des tabulations, contenant l'information :
# 2064 : Une autre solution est de trier toutes les lignes en ordre décroissant, et de ne lire que la première ligne avec la clause LIMIT :
# 2069 : LIMIT 1;
# 2072 : Note : s'il y a beaucoup d'articles chers (par exemple, chaque 19.95) la solution avec LIMIT n'en montre qu'un !. - Chapitre 1. Informations générales - Manuel MySQL
# 81 : 1.5.7. Erreurs connues, et limitations de MySQL
# 143 : Pour une liste des bogues connus et des limitations, voyez Section 1.5.7, « Erreurs connues, et limitations de MySQL ».
# 595 : Charges supportées et limites
# 701 : Chaque version du Serveur MySQL était parfaitement fonctionnelle. Les seuls problèmes étaient rencontrés par les utilisateurs de code de ces ``zone d'ombres''. Naturellement, les nouveaux utilisateurs ne connaissent pas ces zones : cette section tente de les présenter, dans la mesure de nos connaissances. Les descriptions correspondent surtout aux versions 3.23 du Serveur MySQL. Tous les bogues connus et rapportés ont été corrigés dans la dernière version, à l'exception de ceux qui sont listés dans la section Bugs, qui sont des problèmes de conception. See Section 1.5.7, « Erreurs connues, et limitations de MySQL ».
# 763 : MySQL version 3.22 a une limite de 4Go par table. Avec le nouveau format de table MyISAM, disponible avec MySQL version 3.23, la taille maximale des tables a été poussée à 8 millions de teraoctets (2 ^ 63 octets).
# 765 : Notez, toutefois, que les systèmes d'exploitation ont leur propres limites. Voici quelques exemples :
# 778 : Limite
# 834 : D'autres méthodes pour contourner les limitations des systèmes de fichiers avec les tables MyISAM :
# 844 : Une autre méthode pour contourner les limites du système de fichiers pour les tables MyISAM est d'utiliser les options RAID. See Section 13.2.5, « Syntaxe de CREATE TABLE ».
# 968 : La série de production est MySQL 4.0, qui a été déclarée stable pour un environnement de production depuis la version 4.0.12, publiée en Mars 2003. Cela signifie que les développements futurs de la série des 4.0 est limitée aux corrections de bugs. Pour les anciennes version 3.23, seuls les bogues critiques seront corrigés. - Chapitre 9. Structure du langage - Manuel MySQL
# 752 : Les variables utilisateur peuvent être utilisés là où les expressions sont allouées. Notez que cela n'inclut pas pour l'instant les contextes où un nombre est explicitement requis, comme ce qui est le cas avec la clause LIMIT dans une requête SELECT, ou la clause IGNORE nombre LINES dans une requête LOAD DATA.
# 881 : key_cache_division_limit
# 1023 : La syntaxe des commentaires décrites ici s'applique à l'analyseur du serveur mysqld, lorsqu'il traite les commandes SQL. Le client mysql peut aussi effectuer des analyses de commandes avant de les envoyer : par exemple, il recherche les limites de requêtes dans les commandes multi-lignes. Cependant, il y a des limitations dans la fa¸on de gérer les commentaires /* ... */ :
# 1039 : Ces limitations s'appliquent aussi bien à mysql en ligne de commande, que lorsque vous demandez à mysql de lire des commandes depuis un fichier (mysql < un-fichier).
# 1367 : LIMIT
page 1 page 2
Remonter 
