Puisque vous avez mis en place une prime, je vais partager mes secrets durement gagnés...
En général, tous les SQL que j'ai réglés aujourd'hui nécessitaient l'utilisation de sous-requêtes. Venant du monde des bases de données Oracle, les choses que je tenais pour acquises ne fonctionnaient pas de la même manière avec MySQL. Et mes lectures sur le réglage de MySQL me font conclure que MySQL est derrière Oracle en termes d'optimisation des requêtes.
Alors que les requêtes simples requises pour la plupart des applications B2C peuvent bien fonctionner pour MySQL, la plupart des requêtes de type de rapport agrégé nécessaires pour Intelligence Reporting semblent nécessiter un peu de planification et de réorganisation des requêtes SQL pour guider MySQL afin de les exécuter plus rapidement.
Gestion :
max_connections est le nombre de connexions simultanées. La valeur par défaut est de 100 connexions (151 depuis 5.0) - très petit.
Remarque :
les connexions utilisent de la mémoire et votre système d'exploitation peut ne pas être en mesure de gérer un grand nombre de connexions.
Les binaires MySQL pour Linux/x86 vous permettent d'avoir jusqu'à 4096 connexions simultanées, mais les binaires auto-compilés ont souvent moins de limite.
Définissez table_cache pour qu'il corresponde au nombre de vos tables ouvertes et connexions simultanées. Surveillez la valeur open_tables et si elle augmente rapidement, vous devrez augmenter sa taille.
Remarque :
Les 2 paramètres précédents peuvent nécessiter beaucoup de fichiers ouverts. 20+max_connections+table_cache*2 est une bonne estimation de ce dont vous avez besoin. MySQL sur Linux a une option open_file_limit, définissez cette limite.
Si vous avez des requêtes complexes, sort_buffer_size et tmp_table_size sont susceptibles d'être très importants. Les valeurs dépendront de la complexité de la requête et des ressources disponibles, mais 4 Mo et 32 Mo, respectivement, sont des points de départ recommandés.
Remarque :Il s'agit de valeurs "par connexion", parmi read_buffer_size, read_rnd_buffer_size et quelques autres, ce qui signifie que cette valeur peut être nécessaire pour chaque connexion. Tenez donc compte de votre charge et des ressources disponibles lors de la définition de ces paramètres. Par exemple, sort_buffer_size n'est alloué que si MySQL doit faire un tri. Remarque :veillez à ne pas manquer de mémoire.
Si vous avez établi de nombreuses connexions (c'est-à-dire un site Web sans connexions persistantes), vous pouvez améliorer les performances en définissant thread_cache_size sur une valeur non nulle. 16 est une bonne valeur pour commencer. Augmentez la valeur jusqu'à ce que vos threads_created ne se développent pas très rapidement.
CLÉ PRIMAIRE :
Il ne peut y avoir qu'une seule colonne AUTO_INCREMENT par table, elle doit être indexée et ne peut pas avoir de valeur DEFAULT
KEY est normalement synonyme d'INDEX. L'attribut de clé PRIMARY KEY peut également être spécifié uniquement comme KEY lorsqu'il est donné dans une définition de colonne. Cela a été implémenté pour la compatibilité avec d'autres systèmes de base de données.
Une CLÉ PRIMAIRE est un index unique où toutes les colonnes de clé doivent être définies comme NON NULL
Si un index PRIMARY KEY ou UNIQUE se compose d'une seule colonne de type entier, vous pouvez également faire référence à la colonne en tant que "_rowid" dans les instructions SELECT.
Dans MySQL, le nom d'une PRIMARY KEY est PRIMARY
Actuellement, seules les tables InnoDB (v5.1 ?) prennent en charge les clés étrangères.
Habituellement, vous créez tous les index dont vous avez besoin lorsque vous créez des tables. Toute colonne déclarée PRIMARY KEY, KEY, UNIQUE ou INDEX sera indexée.
NULL signifie "n'ayant pas de valeur". Pour tester NULL, vous ne pouvez pas utilisez les opérateurs de comparaison arithmétique tels que =,
NO_AUTO_VALUE_ON_ZERO supprime l'incrémentation automatique pour 0 afin que seul NULL génère le numéro de séquence suivant. Ce mode peut être utile si 0 a été stocké dans la colonne AUTO_INCREMENT d'une table. (Le stockage de 0 n'est pas une pratique recommandée, soit dit en passant.)
Pour modifier la valeur du compteur AUTO_INCREMENT à utiliser pour les nouvelles lignes :
ALTER TABLE mytable AUTO_INCREMENT = value;
ouSET INSERT_ID =valeur ;
Sauf indication contraire, la valeur commencera par :1000000 ou spécifiez-la ainsi :
...) ENGINE=MyISAM DEFAULT CHARSET=latin1 AUTO_INCREMENT=1
Horodatage :
Les valeurs des colonnes TIMESTAMP sont converties du fuseau horaire actuel en UTC pour le stockage, et de l'UTC au fuseau horaire actuel pour la récupération.
http://dev.mysql.com/doc/refman/5.1 /fr/horodatage.html Pour une colonne TIMESTAMP d'une table, vous pouvez affecter l'horodatage actuel comme valeur par défaut et comme valeur de mise à jour automatique.
une chose à surveiller lors de l'utilisation de l'un de ces types dans une clause WHERE, il est préférable de doWHERE datecolumn =FROM_UNIXTIME(1057941242) et notWHERE UNIX_TIMESTAMP(datecolumn) =1057941242.faire ce dernier ne profitera pas d'un index sur ce colonne.
http://dev.mysql.com /doc/refman/5.1/en/date-and-time-functions.html
UNIX_TIMESTAMP()
FROM_UNIXTIME()
UTC_DATE()
UTC_TIME()
UTC_TIMESTAMP()
si vous convertissez une date-heure en horodatage unix dans MySQL :
Et puis ajoutez-y 24 heures :
Et puis reconvertissez-la en date-heure, elle perd comme par magie une heure !
Voici ce qui se passe. Lors de la conversion de l'horodatage unix en une date/heure, le fuseau horaire est pris en considération et il se trouve qu'entre le 28 et le 29 octobre 2006, nous avons dépassé l'heure d'été et perdu une heure.
Depuis MySQL 4.1.3, les fonctions CURRENT_TIMESTAMP(), CURRENT_TIME(), CURRENT_DATE() et FROM_UNIXTIME() renvoient des valeurs dans le fuseau horaire actuel de la connexion. , qui est disponible en tant que valeur de la variable système time_zone. De plus, UNIX_TIMESTAMP() suppose que son argument est une valeur datetime dans le fuseau horaire actuel.
Le paramètre de fuseau horaire actuel n'affecte pas les valeurs affichées par des fonctions telles que UTC_TIMESTAMP() ou les valeurs des colonnes DATE, TIME ou DATETIME.
REMARQUE :SUR LA MISE À JOUR UNIQUEMENT met à jour le DateTime si un champ est modifié Si un UPDATE n'entraîne aucun changement de champ, alors le DateTime n'est PAS mis à jour !
De plus, le premier TIMESTAMP est toujours AUTOUPDATE par défaut même s'il n'est pas spécifié
Lorsque je travaille avec des dates, je conviens presque toujours à la date julienne car le calcul des données consiste alors simplement à ajouter ou à soustraire des entiers et des secondes depuis minuit pour la même raison. Il est rare que j'aie besoin d'une résolution temporelle d'une granularité plus fine que les secondes.
Ces deux éléments peuvent être stockés sous la forme d'un entier de 4 octets, et si l'espace est vraiment restreint, ils peuvent être combinés en temps UNIX (secondes depuis l'époque du 1/1/1970) sous la forme d'un entier non signé qui sera bon jusqu'en 2106 environ :
' secondes en 24 heures =86400
' Entier signé max val =2 147 483 647 - peut contenir 68 ans de secondes
' Entier non signé max val =4 294 967 295 - peut contenir 136 ans de secondes
Protocole binaire :
MySQL 4.1 a introduit un protocole binaire qui permet d'envoyer et de renvoyer des valeurs de données non-chaînes au format natif sans conversion vers et depuis le format chaîne. (Très utile)
De plus, mysql_real_query() est plus rapide que mysql_query() car il n'appelle pas strlen() pour opérer sur la chaîne d'instruction.
http://dev.mysql.com/tech-resources /articles/4.1/prepared-statements.html Le protocole binaire prend en charge les instructions préparées côté serveur et permet la transmission des valeurs de données au format natif. Le protocole binaire a subi de nombreuses révisions au cours des versions précédentes de MySQL 4.1.
Vous pouvez utiliser la macro IS_NUM() pour tester si un champ a un type numérique.Passez la valeur de type à IS_NUM() et elle est évaluée à TRUE si le champ est numérique :
Une chose à noter est que les données binaires PEUVENT être envoyé dans une requête régulière si vous l'échappez et rappelez-vous que MySQL nécessite seulement que la barre oblique inverse et le guillemet soient échappés. C'est donc un moyen très simple d'INSÉRER des chaînes binaires plus courtes comme des mots de passe cryptés/salés par exemple.
Serveur maître :
http://www.experts-exchange.com/Database/MySQL/Q_22967482 .html
http://www.databasejournal.com/features/mysql/article.php /10897_3355201_2
ACCORDER L'ESCLAVE DE RÉPLICATION SUR . à slave_user IDENTIFIÉ PAR 'slave_password'
#Master Binary Logging Config STATEMENT causes replication
to be statement-based - default
log-bin=Mike
binlog-format=STATEMENT
server-id=1
max_binlog_size = 10M
expire_logs_days = 120
#Slave Config
master-host=master-hostname
master-user=slave-user
master-password=slave-password
server-id=2
Le fichier journal binaire doit lire :
http://dev.mysql.com/doc/refman /5.0/fr/binary-log.html
http://www.mydigitallife.info/2007/10/06/how-to-read-mysql-binary-log-files-binlog-with-mysqlbinlog/
http://dev.mysql.com/doc/refman/5.1 /fr/mysqlbinlog.html
http://dev.mysql.com/doc/refman /5.0/fr/binary-log.html
http://dev.mysql.com/doc /refman/5.1/en/binary-log-setting.html
Vous pouvez supprimer tous les fichiers journaux binaires avec l'instruction RESET MASTER, ou un sous-ensemble d'entre eux avec PURGE MASTER
--result-file=binlog.txt TrustedFriend-bin.000030
Normalisation :
http://dev.mysql.com/tech-resources /articles/intro-to-normalization.html
Fonctions UDF
http://www.koders.com/cpp/fid10666379322B54AD41AEB0E4100D87C8CDDF1D8C.aspx"
http://souptonuts.sourceforge.net/readme_mysql.htm
Types de données :
http://dev.mysql.com/doc/refman /5.1/fr/exigences-de-stockage.html
http://www.informit.com/articles/article.aspx ?p=1238838&seqNum=2
http://bitfilm. net/2008/03/24/saving-bytes-efficient-data-storage-mysql-part-1/
Une chose à noter est que sur une table mixte avec CHAR et VARCHAR, mySQL changera les CHAR en VARCHAR
RecNum integer_type UNSIGNED NOT NULL AUTO_INCREMENT, PRIMARY KEY (RecNum)
MySQL représente toujours les dates avec l'année en premier, conformément aux spécifications standard SQL et ISO 8601
Divers :
La désactivation de certaines fonctionnalités de MySQl entraînera des fichiers de données plus petits et un accès plus rapide. Par exemple :
--datadir spécifiera le répertoire de données et
--skip-innodb désactivera l'option inno et vous fera économiser 10-20M
Plus icihttp://dev.mysql.com/tech -ressources/articles/mysql-c-api.html
Télécharger le chapitre 7 - Gratuit
InnoDB est transactionnel mais il y a une surcharge de performances qui l'accompagne. J'ai trouvé que les tables MyISAM étaient suffisantes pour 90 % de mes projets. Les tables non sécurisées pour les transactions (MyISAM) présentent plusieurs avantages qui leur sont propres, qui se produisent tous parce que :
il n'y a pas de surcharge de transaction :
Beaucoup plus rapide
Moins d'espace disque requis
Moins de mémoire nécessaire pour effectuer les mises à jour
Chaque table MyISAM est stockée sur disque dans trois fichiers. Les fichiers ont des noms qui commencent par le nom de la table et ont une extension pour indiquer le type de fichier. Un fichier .frm stocke le format du tableau. Le fichier de données a une extension .MYD (MYData). Le fichier d'index a une extension .MYI (MYIndex).
Ces fichiers peuvent être copié dans un emplacement de stockage intact sans utiliser la fonction de sauvegarde des administrateurs MySQL qui prend du temps (tout comme la restauration)
L'astuce consiste à faire une copie de ces fichiers puis à supprimer la table. Lorsque vous remettrez les fichiers, MySQl les reconnaîtra et mettra à jour le suivi de la table.
Si vous devez sauvegarder/restaurer,
La restauration d'une sauvegarde ou l'importation à partir d'un fichier de vidage existant peut prendre beaucoup de temps en fonction du nombre d'index et de clés primaires que vous avez sur chaque table. Vous pouvez considérablement accélérer ce processus en modifiant votre fichier de vidage d'origine en l'entourant des éléments suivants :
SET AUTOCOMMIT = 0;
SET FOREIGN_KEY_CHECKS=0;
.. your dump file ..
SET FOREIGN_KEY_CHECKS = 1;
COMMIT;
SET AUTOCOMMIT = 1;
Pour augmenter considérablement la vitesse de rechargement, ajoutez la commande SQL SET AUTOCOMMIT =0; au début du fichier de vidage, et ajoutez le COMMIT ; commande jusqu'au bout.
Par défaut, la validation automatique est activée, ce qui signifie que chaque commande d'insertion dans le fichier de vidage sera traitée comme une transaction distincte et écrite sur le disque avant le démarrage de la suivante. Si vous n'ajoutez pas ces commandes, le rechargement d'une grande base de données dans InnoDB peut prendre plusieurs heures...
La taille maximale d'une ligne dans une table MySQL est de 65 535 octets
La longueur maximale effective d'un VARCHAR dans MySQL 5.0.3 et sur =taille de ligne maximale (65 535 octets)
Les valeurs VARCHAR ne sont pas remplies lorsqu'elles sont stockées. Les espaces de fin sont conservés lorsque les valeurs sont stockées et récupérées, conformément au standard SQL.
Les valeurs CHAR et VARCHAR dans MySQL sont comparées sans tenir compte des espaces de fin.
L'utilisation de CHAR n'accélérera votre accès que si l'intégralité de l'enregistrement est de taille fixe. C'est-à-dire que si vous utilisez un objet de taille variable, autant faire en sorte qu'ils soient tous de taille variable. Vous ne gagnez pas en vitesse en utilisant un CHAR dans une table qui contient également un VARCHAR.
La limite VARCHAR de 255 caractères a été portée à 65 535 caractères à partir de MySQL 5.0.3
Les recherches en texte intégral sont prises en charge uniquement pour les tables MyISAM.
http://dev.mysql.com/doc/refman /5.0/fr/fulltext-search.html
Les colonnes BLOB n'ont pas de jeu de caractères, et le tri et la comparaison sont basés sur les valeurs numériques des octets dans les valeurs de colonne
Si le mode SQL strict n'est pas activé et que vous affectez une valeur à une colonne BLOB ou TEXT qui dépasse la longueur maximale de la colonne, la valeur est tronquée pour tenir et un avertissement est généré.
Commandes utiles :
vérifier le mode strict :SELECT @@global.sql_mode ;
désactiver le mode strict :
SET @@global.sql_mode='';
SET @@global.sql_mode='MYSQL40'
ou supprimez :sql-mode="STRICT_TRANS_TABLES,...
AFFICHER LES COLONNES DE mytable
SELECT max(namecount) AS virtualcolumn FROM matable ORDER BY colonnevirtuelle
http://dev.mysql.com /doc/refman/5.0/en/group-by-hidden-fields.html
http://dev.mysql .com/doc/refman/5.1/en/information-functions.html#function_last-insert-id dernier_insert_id()
vous obtient le PK de la dernière ligne insérée dans le thread actuel max(pkcolname) vous obtient le dernier PK global.
Remarque :si la table est vide, max(pkcolname) renvoie 1 mysql_insert_id() convertit le type de retour de la fonction native de l'API MySQL C mysql_insert_id() en un type oflong (nommé int en PHP).
Si votre colonne AUTO_INCREMENT a un type de colonne de BIGINT, la valeur renvoyée par mysql_insert_id() sera incorrecte. Utilisez plutôt la fonction SQL interne MySQL LAST_INSERT_ID() dans une requête SQL.
http://dev.mysql .com/doc/refman/5.0/en/information-functions.html#function_last-insert-id
Juste une note que lorsque vous essayez d'insérer des données dans un tableau et que vous obtenez l'erreur :
Unknown column ‘the first bit of data what you want to put into the table‘ in ‘field list’
en utilisant quelque chose comme
INSERT INTO table (this, that) VALUES ($this, $that)
c'est parce que vous n'avez pas d'apostrophes autour des valeurs que vous essayez de coller dans le tableau. Vous devriez donc changer votre code en :
INSERT INTO table (this, that) VALUES ('$this', '$that')
rappel que `` sont utilisés pour définir des champs MySQL, des bases de données ou des tables, pas des valeurs;)
Perte de connexion au serveur lors de la requête :
http://dev.mysql.com/doc/refman /5.1/fr/disparu.html
http://dev.mysql.com/doc /refman/5.1/fr/paquet-trop-large.html
http://dev.mysql.com/doc/refman /5.0/en/server-parameters.html
http://dev.mysql.com/doc/refman /5.1/fr/show-variables.html
http://dev.mysql.com/doc/refman /5.1/fr/option-files.html
http://dev.mysql.com/doc/refman /5.1/fr/error-log.html
Réglage des requêtes
http://www.artfulsoftware.com/infotree/queries.php?&bw =1313
Eh bien, cela devrait suffire pour gagner le bonus, je pense... Le fruit de nombreuses heures et de nombreux projets avec un super gratuit base de données. Je développe des serveurs de données d'application sur des plates-formes Windows principalement avec MySQL. Le pire gâchis que j'ai dû régler était
Le cauchemar ultime de la base de données héritée MySQL
Cela a nécessité une série d'applications pour traiter les tables en quelque chose d'utile en utilisant de nombreuses astuces mentionnées ici.
Si vous avez trouvé cela incroyablement utile, exprimez vos remerciements en votant pour.
Consultez également mes autres articles et livres blancs sur :www.coastrd.com
