Fonctionnalités cachées de MySQL

101

Je travaille avec Microsoft SQL Server depuis de nombreuses années maintenant, mais je viens tout juste de commencer à utiliser MySQL avec mes applications Web et j'ai soif de connaissances.

Pour continuer avec la longue série de questions sur les «fonctionnalités cachées» , j'aimerais connaître les fonctionnalités cachées ou pratiques de MySQL qui, espérons-le, amélioreront ma connaissance de cette base de données open source.

GateKiller
la source

Réponses:

161

Puisque tu as mis 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 types de requêtes 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 pour les exécuter plus rapidement.

Administration:

max_connectionsest le nombre de connexions simultanées. La valeur par défaut est 100 connexions (151 depuis 5.0) - très petite.

Remarque:

les connexions prennent 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 correspondre au nombre de vos tables ouvertes et connexions simultanées. Regardez 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 probablement très importants. Les valeurs dépendent 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 est alloué uniquement si MySQL a besoin de 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 différente de zéro. 16 est une bonne valeur pour commencer. Augmentez la valeur jusqu'à ce que vos threads_created n'augmentent 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 elle ne peut pas avoir de valeur DEFAULT

KEY est normalement un synonyme d'INDEX. L'attribut clé PRIMARY KEY peut également être spécifié comme juste KEY lorsqu'il est donné dans une définition de colonne. Cela a été mis en œuvre pour la compatibilité avec d'autres systèmes de base de données.

Une clé PRIMAIRE est un index unique où toutes les colonnes clés doivent être définies comme NOT 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 CLÉ PRIMAIRE est PRIMAIRE

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 comme PRIMARY KEY, KEY, UNIQUE ou INDEX sera indexée.

NULL signifie "n'ayant pas de valeur". Pour tester NULL, vous ne pouvez pas utiliser les opérateurs de comparaison arithmétique tels que =, <ou <>. Utilisez plutôt les opérateurs IS NULL et IS NOT NULL:

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. (Soit dit en passant, stocker 0 n'est pas une pratique recommandée.)

Pour modifier la valeur du compteur AUTO_INCREMENT à utiliser pour les nouvelles lignes:

ALTER TABLE mytable AUTO_INCREMENT = value; 

ou SET INSERT_ID = valeur;

Sauf indication contraire, la valeur commencera par: 1000000 ou spécifiez-la ainsi:

...) MOTEUR = MyISAM DEFAULT CHARSET = latin1 AUTO_INCREMENT = 1

HORAIRES:

Les valeurs des colonnes TIMESTAMP sont converties du fuseau horaire actuel en UTC pour le stockage et de UTC au fuseau horaire actuel pour la récupération.

http://dev.mysql.com/doc/refman/5.1/en/timestamp.html Pour une colonne TIMESTAMP dans une table, vous pouvez affecter l'horodatage actuel comme valeur par défaut et la 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 faire WHERE datecolumn = FROM_UNIXTIME (1057941242) et non WHERE UNIX_TIMESTAMP (datecolumn) = 1057941242. faire ce dernier ne profitera pas d'un index sur cette 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 un datetime en horodatage unix dans MySQL:
Et puis ajoutez-y 24 heures:
Et puis convertissez-le en un datetime il 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 compte et il se trouve qu'entre le 28 et le 29 octobre 2006, nous avons quitté l'heure d'été et perdu une heure.

À partir de 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 comme 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: ON UPDATE met à jour UNIQUEMENT la DateTime si un champ est modifié. Si une MISE À JOUR entraîne aucun champ en cours de modification, la DateTime n'est PAS mise à 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 convoque presque toujours la date julienne car les mathématiques des données sont alors une simple question d'ajouter ou de 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.

Les deux peuvent être stockés sous forme d'entier de 4 octets, et si l'espace est vraiment restreint, ils peuvent être combinés en temps UNIX (secondes depuis l'époque 1/1/1970) sous forme d'entier non signé qui sera bon jusqu'à environ 2106 comme:

'secondes en 24 heures = 86400

'Valeur max. De l'entier signé = 2,147,483,647 - peut contenir 68 années de secondes

'Valeur max. D'un entier non signé = 4 294 967 295 - peut contenir 136 années 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îne 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 agir sur la chaîne de l'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 de valeurs de données au format natif. Le protocole binaire a subi de nombreuses révisions lors 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 il est évalué à TRUE si le champ est numérique:

Une chose à noter est que les données binaires PEUVENT être envoyées dans une requête normale si vous les échappez et que vous vous souvenez que MySQL ne nécessite que la barre oblique inverse et le caractère guillemet échappé. 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

GRANT REPLICATION SLAVE ON . à slave_user IDENTIFIED BY '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/en/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/en/mysqlbinlog.html

http://dev.mysql.com/doc/refman/5.0/en/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/en/storage-requirements.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 à la fois 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 MySQl se traduira par 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 ici http://dev.mysql.com/tech-resources/articles/mysql-c-api.html

Télécharger le chapitre 7 - gratuit

InnoDB est transactionnel mais il y a une surcharge de performance qui l'accompagne. J'ai trouvé les tables MyISAM 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 frais généraux de transaction:

Plus vite

Besoins d'espace disque réduits

Moins de mémoire requise 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 de la table. Le fichier de données a une extension .MYD (MYData). Le fichier d'index a une extension .MYI (MYIndex).

Ces fichiers peuvent être copiés 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 à DROPER la table. Lorsque vous remettez les fichiers en place, MySQl les reconnaît et met à 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 du temps en fonction du nombre d'index et de clés primaires que vous avez sur chaque table. Vous pouvez accélérer considérablement 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'à la fin.

Par défaut, l'autocommit est activé, 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 on = taille de ligne maximale (65 535 octets)

Les valeurs VARCHAR ne sont pas complétées 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 SQL standard.

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'ensemble de l'enregistrement est de taille fixe. Autrement dit, si vous utilisez un objet de taille variable, vous pouvez tout aussi bien rendre tous les objets de taille variable. Vous ne gagnez aucune vitesse en utilisant un CHAR dans une table qui contient également un VARCHAR.

La limite VARCHAR de 255 caractères a été augmentée à 65535 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/en/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 attribuez une valeur à une colonne BLOB ou TEXT qui dépasse la longueur maximale de la colonne, la valeur est tronquée pour s'adapter 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, ...

MONTRER LES COLONNES DE mytable

SELECT max (namecount) AS virtualcolumnFROM mytable ORDER BY virtualcolumn

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 last_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 MySQL C API mysql_insert_id () en un type long (nommé int en PHP).

Si votre colonne AUTO_INCREMENT a un type de colonne BIGINT, la valeur retournée par mysql_insert_id () sera incorrecte. À la place, utilisez la fonction SQL MySQL interne 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 une table 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 à la table. 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, bases de données ou tables MySQL, pas des valeurs;)

Connexion perdue au serveur pendant la requête:

http://dev.mysql.com/doc/refman/5.1/en/gone-away.html

http://dev.mysql.com/doc/refman/5.1/en/packet-too-large.html

http://dev.mysql.com/doc/refman/5.0/en/server-parameters.html

http://dev.mysql.com/doc/refman/5.1/en/show-variables.html

http://dev.mysql.com/doc/refman/5.1/en/option-files.html

http://dev.mysql.com/doc/refman/5.1/en/error-log.html

Requêtes de réglage

http://www.artfulsoftware.com/infotree/queries.php?&bw=1313

Et bien ça devrait suffire pour gagner le bonus je pense ... Les fruits de nombreuses heures et de nombreux projets avec une excellente base de données gratuite . Je développe des serveurs de données d'application sur des plates-formes Windows principalement avec MySQL. Le pire désordre que j'ai dû redresser était

Le cauchemar ultime des bases de données héritées MySQL

Cela nécessitait une série d'applications pour transformer 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.

Consultez également mes autres articles et livres blancs sur: www.coastrd.com

Mike Trader
la source
22

L'une des fonctionnalités pas si cachées de MySQL est qu'il n'est pas vraiment bon pour être conforme à SQL, enfin, pas vraiment de bogues, mais, plus de pièges ... :-)

tapis
la source
Les lettres d'autres savent que cette liste a été précieuse lors du passage de MSSQL à MySQL. Cheers Mat.
GateKiller
Beaucoup de ces pièges proviennent de versions antérieures de MySQL.
jmucchiello
D'une part, je ne pense pas qu'il sera jamais possible de mettre une valeur NULL dans un champ d'horodatage.
mat
3
MySQL n'est pas particulièrement compatible avec SQL que de nombreuses autres bases de données; tant que vous vous en tenez à un sous-ensemble sain de SQL, vous pouvez généralement éviter les pièges - ce qui est plus que ce que l'on peut dire par exemple. Les tristement célèbres chaînes vides NULL d'Oracle.
bobince
1
Vous pouvez désactiver certains des piègesSET SESSION sql_mode='ANSI';
Kornel
21

Une commande pour savoir quelles tables sont actuellement dans le cache:

mysql> SHOW open TABLES FROM test;
+----------+-------+--------+-------------+
| DATABASE | TABLE | In_use | Name_locked |
+----------+-------+--------+-------------+
| test     | a     |      3 |           0 |
+----------+-------+--------+-------------+
1 row IN SET (0.00 sec)

(Du blog de performance MySQL )

Eran Galperin
la source
15

Une commande pour savoir qui fait quoi:

mysql> show processlist;
show processlist;
+----+-------------+-----------------+------+---------+------+----------------------------------+------------------+
| Id | User        | Host            | db   | Command | Time | State                            | Info             |
+----+-------------+-----------------+------+---------+------+----------------------------------+------------------+
|  1 | root        | localhost:32893 | NULL | Sleep   |    0 |                                  | NULL             |
|  5 | system user |                 | NULL | Connect |   98 | Waiting for master to send event | NULL             |
|  6 | system user |                 | NULL | Connect | 5018 | Reading event from the relay log | NULL             |
+-----+------+-----------+---------+---------+-------+-------+------------------+
3 rows in set (0.00 sec) 

Et vous pouvez tuer un processus avec:

mysql>kill 5 
CMS
la source
5
SHOW FULL PROCESSLIST si vous ne voulez pas que les requêtes soient tronquées.
Greg
11

J'aime particulièrement le support intégré de MySQL pour inet_ntoa()et inet_aton(). Cela rend la gestion des adresses IP dans les tables très simple (du moins tant qu'il ne s'agit que d'adresses IPv4!)

Alnitak
la source
2
PostgreSQL a un très bon type inet, qui gère très bien ipv4 et ipv6 :-)
mat
Je les aimais aussi, mais ne pas avoir à les utiliser du tout, c'est encore mieux. +1 pour Postgres.
Kornel
11

J'adore on duplicate key(AKA upsert, merge) pour toutes sortes de compteurs créés paresseusement:

insert into occurances(word,count) values('foo',1),('bar',1) 
  on duplicate key cnt=cnt+1

Vous pouvez insérer plusieurs lignes dans une requête et gérer immédiatement l'index en double pour chacune des lignes.

porneL
la source
10

Encore une fois - des fonctionnalités pas vraiment cachées, mais vraiment pratiques:

Fonctionnalité

Saisissez facilement DDL:

SHOW CREATE TABLE CountryLanguage

production:

CountryLanguage | CREATE TABLE countrylanguage (
  CountryCode char(3) NOT NULL DEFAULT '',
  Language char(30) NOT NULL DEFAULT '',
  IsOfficial enum('T','F') NOT NULL DEFAULT 'F',
  Percentage float(4,1) NOT NULL DEFAULT '0.0',
  PRIMARY KEY (CountryCode,Language)
) ENGINE=MyISAM DEFAULT CHARSET=latin1

Fonctionnalité: Fonction d'agrégation GROUP_CONCAT () Crée une chaîne concaténée de ses arguments par détail, et les agrège en les concaténant par groupe.

Exemple 1: simple

SELECT   CountryCode
,        GROUP_CONCAT(Language) AS List
FROM     CountryLanguage
GROUP BY CountryCode             

Production:

+-------------+------------------------------------+
| CountryCode | List                               |
+-------------+------------------------------------+
| ABW         | Dutch,English,Papiamento,Spanish   |
. ...         . ...                                .
| ZWE         | English,Ndebele,Nyanja,Shona       |
+-------------+------------------------------------+

Exemple 2: plusieurs arguments

SELECT   CountryCode
,        GROUP_CONCAT(
             Language
,            IF(IsOfficial='T', ' (Official)', '')
         )               AS List
FROM     CountryLanguage
GROUP BY CountryCode

Production:

+-------------+---------------------------------------------+
| CountryCode | List                                        |
+-------------+---------------------------------------------+
| ABW         | Dutch (Official),English,Papiamento,Spanish |
. ...         . ...                                         .
| ZWE         | English (Official),Ndebele,Nyanja,Shona     |
+-------------+---------------------------------------------+

Exemple 3: Utilisation d'un séparateur personnalisé

SELECT   CountryCode
,        GROUP_CONCAT(Language SEPARATOR ' and ') AS List
FROM     CountryLanguage
GROUP BY CountryCode

Production:

+-------------+----------------------------------------------+
| CountryCode | List                                         |
+-------------+----------------------------------------------+
| ABW         | Dutch and English and Papiamento and Spanish |
. ...         . ...                                          .
| ZWE         | English and Ndebele and Nyanja and Shona     |
+-------------+----------------------------------------------+

Exemple 4: Contrôle de l'ordre des éléments de la liste

SELECT   CountryCode
,        GROUP_CONCAT(
         Language
         ORDER BY CASE IsOfficial WHEN 'T' THEN 1 ELSE 2 END DESC
         ,        Language
         )               AS List
FROM     CountryLanguage
GROUP BY CountryCode

Production:

+-------------+------------------------------------+
| CountryCode | List                               |
+-------------+------------------------------------+
| ABW         | English,Papiamento,Spanish,Dutch,  |
. ...         . ...                                .
| ZWE         | Ndebele,Nyanja,Shona,English       |
+-------------+------------------------------------+

Fonctionnalité: COUNT (DISTINCT) avec plusieurs expressions

Vous pouvez utiliser plusieurs expressions dans une expression COUNT (DISTINCT ...) pour compter le nombre de combinaisons.

SELECT COUNT(DISTINCT CountryCode, Language) FROM CountryLanguage

Fonctionnalité / Gotcha: Pas besoin d'inclure des expressions non agrégées dans la liste GROUP BY

La plupart des SGBDR appliquent un GROUP BY conforme à SQL92 qui exige que toutes les expressions non agrégées de la liste SELECT apparaissent dans GROUP BY. Dans ces SGBDR, cette déclaration:

SELECT     Country.Code, Country.Continent, COUNT(CountryLanguage.Language)
FROM       CountryLanguage 
INNER JOIN Country 
ON         CountryLanguage.CountryCode = Country.Code
GROUP BY   Country.Code

n'est pas valide, car la liste SELECT contient la colonne non agrégée Country.Continent qui n'apparaît pas dans la liste GROUP BY. Dans ces SGBDR, vous devez soit modifier la liste GROUP BY pour lire

GROUP BY   Country.Code, Country.Continent

ou vous devez ajouter un agrégat non sens à Country.Continent, par exemple

SELECT     Country.Code, MAX(Country.Continent), COUNT(CountryLanguage.Language)

Maintenant, le fait est que, logiquement, il n'y a rien qui exige que Country.Continent soit agrandi. Voir, Country.Code est la clé primaire de la table Country. Country.Continent est également une colonne de la table Country et dépend donc fonctionnellement de la clé primaire Country.Code. Ainsi, il doit exister exactement une valeur dans Country.Continent pour chaque Country.Code distinct. Si vous vous rendez compte de cela, vous vous rendez compte qu'il n'est pas logique de l'agréger (il n'y a qu'une seule valeur, à droite) ni de le regrouper (car cela ne rendra pas le résultat plus unique car vous regroupez déjà par sur le pk)

Quoi qu'il en soit - MySQL vous permet d'inclure des colonnes non agrégées dans la liste SELECT sans vous obliger à les ajouter également à la clause GROUP BY.

Le problème avec ceci est que MySQL ne vous protège pas au cas où vous utiliseriez une colonne non agrégée. Donc, une requête comme celle-ci:

SELECT     Country.Code, COUNT(CountryLanguage.Language), CountryLanguage.Percentage
FROM       CountryLanguage 
INNER JOIN Country 
ON         CountryLanguage.CountryCode = Country.Code
GROUP BY   Country.Code

Sera exécuté sans réclamation, mais la colonne CountryLanguage.Percentage contiendra un non-sens (c'est-à-dire, de toutes les langues pourcentages, l'une des valeurs disponibles pour le pourcentage sera choisie au hasard ou au moins en dehors de votre contrôle.

Voir: Démystifier le groupe par mythes

anon
la source
L'autorisation de colonnes non déclarées dans group by est l'une de mes fonctionnalités les moins préférées provenant d'Oracle. C'est un gros problème si vous êtes habitué à Oracle - il vous permet simplement d'exécuter la requête, les résultats semblent corrects, mais vous réalisez ensuite que cela ne fait pas ce que vous pensiez.
mbafford
7

La commande "pager" dans le client

Si vous avez, par exemple, 10 000 lignes dans votre résultat et que vous souhaitez les afficher (cela suppose les commandes "less" et "tee" disponibles, ce qui est normalement le cas sous Linux; sous Windows YMMV.)

pager less
select lots_of_stuff FROM tbl WHERE clause_which_matches_10k_rows;

Et vous les obtiendrez dans la visionneuse de fichiers "moins" afin que vous puissiez les parcourir joliment, rechercher, etc.

Aussi

pager tee myfile.txt
select a_few_things FROM tbl WHERE i_want_to_save_output_to_a_file;

Écrira facilement dans un fichier.

MarkR
la source
malheureusement sous Windows, même si "less" et "tee" existent, l'option pager elle-même n'est pas prise en charge. pas facilement de toute façon
Berry Tsakala
6

Certaines choses peuvent vous intéresser:

<query>\G -- \G in the CLI instead of the ; will show one column per row
explain <query>; -- this will show the execution plan for the query
SorinV
la source
3

Voici quelques-uns de mes conseils - j'ai blogué à leur sujet dans mon blog ( Lien )

  1. Vous n'avez pas besoin d'utiliser le signe «@» lors de la déclaration des variables.
  2. Vous devez utiliser un délimiteur (la valeur par défaut est ';') pour délimiter la fin d'une instruction - Lien
  3. Si vous essayez de déplacer des données entre MS-SQL 2005 et mySQL, il y a quelques obstacles à franchir - Lien
  4. Faire des correspondances sensibles à la casse dans mySQL - lien
Nikhil
la source
3

Si vous comptez travailler avec des bases de données InnoDb à grande et / ou haute transaction, apprenez et comprenez "SHOW INNODB STATUS" Mysql Performance Blog , il deviendra votre ami.

Hawk Kroeger
la source
3

Si vous utilisez cmdline Mysq, vous pouvez interagir avec la ligne de commande (sur les machines Linux - pas sûr s'il existe un effet équivalent sur Windows) en utilisant le point d'exclamation / cri. Par exemple:

\! cat file1.sql

affichera le code pour file1.sql. Pour enregistrer votre relevé et votre requête dans un fichier, utilisez la fonction tee

\T filename

pour désactiver cette option, utilisez \ t

Enfin, pour exécuter un script que vous avez déjà enregistré, utilisez "nom de fichier source". Bien sûr, l'alternative normale est de diriger le nom du script lors du démarrage de mysql depuis la ligne de commande:

    mysql -u root -p < case1.sql

J'espère que c'est utile à quelqu'un!

Edit: Je viens de me souvenir d'un autre - lors de l'appel de mysql à partir de la ligne de commande, vous pouvez utiliser le commutateur -t pour que la sortie soit au format table - un véritable avantage avec certaines requêtes (bien que bien sûr, terminer les requêtes avec \ G comme mentionné ailleurs ici est également utile à cet égard). Beaucoup plus sur divers commutateurs Outil de ligne de commande

Je viens de trouver un moyen intéressant de changer l'ordre d'un tri (utilisez normalement Case ...) Si vous voulez changer l'ordre d'un tri (peut-être trier par 1, 4, 3, 2 au lieu de 1, 2, 3, 4) vous pouvez utiliser la fonction de champ dans la clause Trier par. Par exemple

Trier par champ (sort_field, 1,4,3,2)

DBMarcos99
la source
3

Je ne pense pas que ce soit spécifique à MySQL, mais éclairant pour moi:

Au lieu d'écrire

WHERE (x.id > y.id) OR (x.id = y.id AND x.f2 > y.f2) 

Tu peux juste écrire

WHERE (x.id, x.f2) > (y.id, y.f2)
Johan
la source
C'est vraiment cool, mais quels seraient certains cas d'utilisation pour cela?
mangue ivre
Cela peut être utile pour rechercher tous les enregistrements plus gros qu'un enregistrement donné.
Fantius
2

mysqlsla - Un des outils d'analyse des journaux de requêtes lentes les plus couramment utilisés. Vous pouvez voir les 10 pires requêtes depuis le dernier déploiement des journaux de requêtes lentes. Il peut également vous indiquer le nombre de fois que la requête BAD a été déclenchée et combien de temps total cela a pris sur le serveur.

Pawan
la source
2

En fait documenté , mais très ennuyeux: conversions automatiques pour des dates incorrectes et d'autres entrées incorrectes.

Avant MySQL 5.0.2, MySQL pardonne les valeurs de données illégales ou inappropriées et les contraint à des valeurs légales pour la saisie de données. Dans MySQL 5.0.2 et versions ultérieures, cela reste le comportement par défaut, mais vous pouvez modifier le mode SQL du serveur pour sélectionner un traitement plus traditionnel des mauvaises valeurs de sorte que le serveur les rejette et abandonne l'instruction dans laquelle elles se produisent.

Quant aux dates: vous aurez parfois de la «chance» lorsque MySQL n'ajuste pas l'entrée à des dates valides proches, mais la stocke à la place comme 0000-00-00qui, par définition, n'est pas valide. Cependant, même dans ce cas, vous auriez peut-être voulu que MySQL échoue plutôt que de stocker silencieusement cette valeur pour vous.

Arjan
la source
1

InnoDB stocke par défaut toutes les tables dans un espace table global qui ne sera jamais réduit .

Vous pouvez utiliser innodb_file_per_tablequi placera chaque table dans un tablespace distinct qui sera supprimé lorsque vous supprimerez la table ou la base de données.

Planifiez à l'avance car vous devez vider et restaurer la base de données pour récupérer de l'espace dans le cas contraire.

Utilisation des tablespaces par table

serbaut
la source
1

Si vous insérez dans la colonne datetime la valeur de chaîne vide "", MySQL conservera la valeur 00/00/0000 00:00:00. Contrairement à Oracle, qui enregistrera une valeur nulle.

Devid G
la source
1

Lors de mes benchmarks avec de grands ensembles de données et des champs DATETIME, il est toujours plus lent de faire cette requête:

SELECT * FROM mytable
WHERE date(date_colum) BETWEEN '2011-01-01' AND ''2011-03-03';

Que cette approche:

SELECT * FROM mytable
WHERE date_column BETWEEN '2011-01-01 00:00:00' AND '2011-03-03 23:59:59'
Osvaldo Mercado
la source