{"id":4046,"date":"2022-09-30T15:42:09","date_gmt":"2022-09-30T13:42:09","guid":{"rendered":"https:\/\/www.combell.com\/en\/help\/?post_type=ht_kb&p=4046"},"modified":"2024-12-11T13:04:12","modified_gmt":"2024-12-11T12:04:12","slug":"quota-phpmyadmin-vs-disk-usage","status":"publish","type":"ht_kb","link":"https:\/\/www.combell.com\/en\/help\/kb\/quota-phpmyadmin-vs-disk-usage\/","title":{"rendered":"Quota: phpMyAdmin vs disk usage"},"content":{"rendered":"\n

MySQL’s SHOW TABLE STATUS<\/code>  and phpMyAdmin provide an overview of the usage of each table. This often differs (a lot) from what is actually in use on disk because of multiple reasons and possibly a combination of them.<\/p>\n\n\n\n

Why is there a difference between MySQL and phpMyAdmin?<\/h2>\n\n\n\n

Indices<\/h3>\n\n\n\n

When creating a table, you can define one or more indices. An index contains (part of) the data for a specific column to filter the results with references to the full record information. This means that part of the data may be duplicated on disk.<\/p>\n\n\n\n

Fragmentation or “empty” spaces in the data file<\/h3>\n\n\n\n

MySQL doesn’t actually remove data after deleting a record in the middle of a table, but marks it as “deleted” so new data can reuse the space. In situations where this doesn’t happen the data still occupies some disk space, causing your table to be larger on disk than what MySQL shows.<\/p>\n\n\n\n

Over time, for certain types of tables (primarily tables used to store cached data) with volatile data, the space taken up by deleted records grows fast. Making up 50% or even >100% of the size of the actual useful data.<\/p>\n\n\n\n

Lazy counting by MySQL<\/h3>\n\n\n\n

Because it’s resource intensive to read the whole data file from disk to calculate the usage, MySQL tries to be smart by estimating some numbers based on a sample of data from the table. Otherwise the performance of your MySQL queries would suffer, resulting in high latency and slow websites.<\/p>\n\n\n\n

This data sample might no longer be realistic over time, causing an underestimation of the effective disk usage.<\/p>\n\n\n\n

Amount of tables<\/h3>\n\n\n\n

Next to having smart queries and adding the right indices, the structure of the database is very important. Only add the tables you really need. Every table creates a bit overhead and the more tables the bigger the overhead becomes.<\/p>\n\n\n\n

Solutions<\/h2>\n\n\n\n

Re-analyzing or optimizing the tables suspected of using more on disk than what MySQL reports often<\/strong> helps. There are a few ways to do this:<\/p>\n\n\n\n

  • To solve the lazy counting, it might be sufficient to just run ANALYZE TABLE <tablename>;<\/code><\/li>
  • To solve the fragmentation (which can also occur in indices), you could trigger a rebuild with either:
    • OPTIMIZE TABLE <tablename>;<\/code><\/li>
    • ALTER TABLE <tablename> ENGINE=InnoDB;<\/code> (only if this is an InnoDB table, the previous option is a safer method since it works for all types)<\/li><\/ul><\/li><\/ul>\n\n\n\n

      Benefits of having an optimised database<\/h2>\n\n\n\n

      Besides using less disk space, an optimised database has some other advantages.<\/p>\n\n\n\n

      • Accessing larger databases require more memory and CPU from the system, resources that could be used for other important processes.<\/li>
      • Making a backup of an optimised database takes less time, which in turn will benefit the general server performance during backup windows.<\/li>
      • Querying unoptimised tables may slow down your website.<\/li><\/ul>\n","protected":false},"excerpt":{"rendered":"

        MySQL’s SHOW TABLE STATUS  and phpMyAdmin provide an overview of the usage of each table. This often differs (a lot) from what is actually in use on disk because of multiple reasons and possibly a combination of them. Why is there a difference between MySQL and phpMyAdmin? Indices When creating a…<\/p>\n","protected":false},"author":1,"comment_status":"closed","ping_status":"closed","template":"","format":"standard","meta":{"footnotes":""},"ht-kb-category":[23,43],"ht-kb-tag":[],"acf":[],"_links":{"self":[{"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/ht-kb\/4046"}],"collection":[{"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/ht-kb"}],"about":[{"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/types\/ht_kb"}],"author":[{"embeddable":true,"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/users\/1"}],"replies":[{"embeddable":true,"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/comments?post=4046"}],"version-history":[{"count":1,"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/ht-kb\/4046\/revisions"}],"predecessor-version":[{"id":4047,"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/ht-kb\/4046\/revisions\/4047"}],"wp:attachment":[{"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/media?parent=4046"}],"wp:term":[{"taxonomy":"ht_kb_category","embeddable":true,"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/ht-kb-category?post=4046"},{"taxonomy":"ht_kb_tag","embeddable":true,"href":"https:\/\/www.combell.com\/en\/help\/wp-json\/wp\/v2\/ht-kb-tag?post=4046"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}