Connaître la taille des tables d’une base de données en ligne de commandes
Depuis que j’ai commencé à travailler chez LinkByNet, j’ai pris l’habitude d’interroger MySQL/MariaDB directement en ligne de commande, et comme pour un shell « Linux », il y a plein de choses pour lesquelles c’est plus rapide. Mais parfois, il y a certains petits trucs qui rendent un outil comme PHPMyAdmin pratique, et ça passe notamment par la taille des tables, une des étapes quand on analyse les pistes d’amélioration de performance. Fort heureusement, on peut s’en sortir rapidement aussi sans faire appel au clicodrôme. Simplement je sais pas, mais ça marche bien en tout cas.
Une seule commande. Certes, c’est du niveau de ce que j’ai pu vous présenter précédemment, mais ça tient à une commande à conserver dans un coin pour avoir une vision de la taille de vos tables. Donc la commande c’est celle-là :
1 |
SELECT TABLE_NAME, table_rows, data_length, index_length, round(((data_length + index_length) / 1024 / 1024),2) "Taille en Mo" FROM information_schema.TABLES WHERE table_schema = "blog"; |
Que fait donc cette commande ? Les informations liées à votre base de données se trouvent dans la base information_schema, et en l’occurrence, la table TABLES. On récupère donc les informations essentielles, le nom de la table, le nombre de lignes, la taille des données index compris, et on fait un petit calcul pour afficher la taille en méga-octets (d’où la double division par 1024, parce que les tailles sont stockées en octets). table_schema désigne le nom de votre base (blog dans l’exemple). Voilà le résultat pour la mienne :
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 29 30 31 32 33 |
+------------------------------+------------+-------------+--------------+--------------+ | TABLE_NAME | table_rows | data_length | index_length | Taille en Mo | +------------------------------+------------+-------------+--------------+--------------+ | wp_blc_filters | 0 | 16384 | 0 | 0.02 | | wp_blc_instances | 1279 | 278528 | 147456 | 0.41 | | wp_blc_links | 1027 | 1589248 | 262144 | 1.77 | | wp_blc_synch | 165 | 16384 | 16384 | 0.03 | | wp_cn_track_post | 88013 | 5783552 | 0 | 5.52 | | wp_commentmeta | 946 | 98304 | 180224 | 0.27 | | wp_comments | 489 | 376832 | 81920 | 0.44 | | wp_contactformmaker | 1 | 32768 | 0 | 0.03 | | wp_contactformmaker_blocked | 0 | 16384 | 0 | 0.02 | | wp_contactformmaker_submits | 0 | 16384 | 0 | 0.02 | | wp_contactformmaker_themes | 34 | 1589248 | 0 | 1.52 | | wp_contactformmaker_views | 1 | 16384 | 0 | 0.02 | | wp_links | 0 | 16384 | 16384 | 0.03 | | wp_microblogposter_accounts | 1 | 16384 | 16384 | 0.03 | | wp_microblogposter_logs | 790 | 229376 | 0 | 0.22 | | wp_microblogposter_old_items | 59 | 16384 | 0 | 0.02 | | wp_ngg_album | 0 | 16384 | 0 | 0.02 | | wp_ngg_gallery | 0 | 16384 | 0 | 0.02 | | wp_ngg_pictures | 0 | 16384 | 16384 | 0.03 | | wp_options | 725 | 1441792 | 65536 | 1.44 | | wp_postmeta | 2808 | 1589248 | 262144 | 1.77 | | wp_posts | 1864 | 26755072 | 409600 | 25.91 | | wp_q2w3_inc_manager | 2 | 16384 | 0 | 0.02 | | wp_term_relationships | 2126 | 114688 | 81920 | 0.19 | | wp_term_taxonomy | 994 | 98304 | 114688 | 0.20 | | wp_termmeta | 0 | 16384 | 32768 | 0.05 | | wp_terms | 953 | 81920 | 98304 | 0.17 | | wp_usermeta | 30 | 16384 | 32768 | 0.05 | | wp_users | 1 | 16384 | 32768 | 0.05 | +------------------------------+------------+-------------+--------------+--------------+ |
Déjà je découvre que j’ai encore des tables de NextGen Gallery alors que je n’utilise plus cette extension (je ne me souviens même pas l’avoir utilisé une seule fois dans un article au final). Et on se rend compte que fort logiquement la table la plus grosse est wp_posts, puisqu’elle contient les informations et données de tout ce que vous postez : images, pages, articles, y compris toutes les révisions. Évidemment les autres tables sont importantes également, mais là, vous avez un moyen par exemple de pointer du doigt le responsable d’une grosse lenteur, pourquoi pas, comme ça a été mon cas lors de ma première utilisation, un dump anormalement long.
Sur certains blogs pour connaitre la taille d’une base de données ils mettent la requête suivante :
SELECT table_schema, round(sum(data_length+index_length)/1024/1024,2) AS « Size (MB) »
FROM information_schema.tables
GROUP BY table_schema;
Mais je ne comprend pas à quoi sert le « ,2 » ou « ,4 » dans le « round ». Est ce que tu sais pourquoi?
C’est la précision avec laquelle tu arrondis la taille calculée. « ,2 », deux chiffres après la virgule, « ,4 », quatre chiffres. Aussi simple que ça 🙂
Ok. Merci.