We are all familiar with “.frm” files since the earliest days of MySQL, The community has been continuously requesting for replacement of file-system based metadata for several good reasons, So with MySQL 8.0 “.frm” files are gone for ever, Going forward MySQL stores table metadata in the data dictionary tables which uses InnoDB storage engine. This blog is about MySQL 8.0 data dictionary and how it creates value for MySQL going forward:<\/p>\n

How file based metadata management used to work in the past (before MySQL 8.0) ?\u00a0<\/strong><\/p>\n

\n
• Every table in MySQL will have corresponding .frm file, This .frm file stores information like column names and data-types in the binary format, In addition to the .frm file, there are .trn, .trg and .par files to support triggers, trigger namespace and partitioning .<\/li>\n<\/ul>\n

  What are major bottlenecks faced due to the usage of file based metadata management ?\u00a0<\/strong><\/p>\n

  \n
  • Operationally it always appeared very irrational, Why we need to have an separate mechanism to track the schema information ? Originally this was the idea from Drizzle –\u00a0 Drizzle made it very clear (almost ) that it should get out of the way and let the storage engines be the storage engines and not try to second guess them or keep track of things behind their back.<\/li>\n
  • Dictionaries out of synch.<\/strong>–\u00a0Before MySQL 8.0, the data dictionary is a\u00a0 \u201csplit brain\u201d, where\u00a0 the \u201cserver\u201d and InnoDB have their own separate data dictionary, where some information duplicated. Information that is duplicated in the MySQL server dictionary and the InnoDB dictionary might get out of synch, and we need one common \u201csource of truth\u201d\u00a0 for dictionary information.<\/li>\n
  • INFORMATION_SCHEMA is the bottleneck<\/strong>–\u00a0The main reason behind these performance issues in the INFORMATION_SCHEMA (before MySQL 8.0)<\/tt>\u00a0implementation is that INFORMATION_SCHEMA\u00a0<\/tt>tables are implemented as temporary tables that are created on-the-fly during query execution.\u00a0For a MySQL server having hundreds of databases, each with hundreds of tables within them, the INFORMATION_SCHEMA\u00a0<\/tt>query would end-up doing lot of I\/O reading each individual FRM files from the file system. And it would also end-up using more CPU cycles in effort to open the table and prepare related in-memory data structures. It does attempt to use the MySQL server table cache (the system variable \u2018table_definition_cache<\/tt>\u2018), however in large server instances it\u2019s very rare to have a table cache that is large enough to accommodate all of these tables.<\/li>\n
  • No atomic DDL<\/strong>–\u00a0Storing the data dictionary in non-transactional tables and files, means that DDLs are unsafe for replication (they are not transactional, not even atomic). If a compound DDL fails we still need to replicate it and hope that it fails with the same error. This is a best effort\u00a0<\/b>approach and there is a lot of logic coded to handle this . It is hard to maintain, slows down progress and bloats the replication codebase. The data dictionary is stored partly in non-transactional tables. These are not safe for replication building resilient HA systems on top of MySQL. For instance, some dictionary tables need to be manipulated using regular DML, which causes problems for GTIDs.<\/li>\n
  • Crash recovery. <\/strong>Since the DDL statements are not atomic, it is challenging to recover after crashing in the middle of a DDL execution, and is especially problematic for replication.<\/li>\n<\/ul>\n

    How things are changed with MySQL 8.0 \u00a0?\u00a0<\/strong><\/p>\n

    MySQL 8.0 introduced a\u00a0native data dictionary based on InnoDB.\u00a0 This change has enabled us to get rid of file-based metadata store (FRM\u00a0<\/tt>files) and also help MySQL to move towards supporting transactional DDL. We have now the metadata of all database tables stored in transactional data dictionary tables, it enables us to design an INFORMATION_SCHEMA\u00a0<\/tt>table as a database VIEW over the data dictionary tables. This eliminates costs such as the creation of temporary tables for each INFORMATION_SCHEMA\u00a0<\/tt>query during execution on-the-fly, and also scanning file-system directories to find FRM files. It is also now possible to utilize the full power of the MySQL optimizer to prepare better query execution plans using indexes on data dictionary tables.\u00a0INFORMATION SCHEMA is now implemented as views over dictionary tables, requires no extra disc accesses, no creation of temporary tables, and is subject to similar handling of character sets and collations as user tables.<\/p>\n

    The following diagram (Source: MySQL server team blog<\/a>) explains the difference in design in MySQL 5.7 and 8.0 :<\/p>\n

    <\/p>\n","protected":false},"excerpt":{"rendered":"

    We are all familiar with “.frm” files since the earliest days of MySQL, The community has been continuously requesting for replacement of file-system based metadata for several good reasons, So with MySQL 8.0 “.frm” files […]<\/a><\/p>\n<\/div>","protected":false},"author":10,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[2,125,104],"tags":[5,127,16],"yoast_head":"\n