[MySQL] Storage Engine (1): Introduction to Storage Engine

First, let's think about a question. In a relational database, what structure is the data placed in? Answer: Put it in the table, we can understand this table as an Excel spreadsheet.

Therefore, when our table stores data, it also organizes the storage structure of the data. This storage structure is determined by our storage engine, so we can also call the storage engine a table type.

In MySQL, a variety of storage engines are supported, and they can be replaced, so it is called a plug-in storage engine. Why are there so many storage engines? Is one not enough? Keep this question for now.

1. View the storage engine

For example, for tables that already exist in our database, how do we check their storage engines?

show table status from `forum`; --forum是指定数据库名

[External link image transfer failed. The origin site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-InyXfWHT-1603815339184)(Untitled.assets/image-20201027171707820.png)]

In addition, it can also be viewed through DDL table creation statement.

In MySQL, each table we create can specify its storage engine, not a database can only use one storage engine. The storage engine is used in units of tables. Moreover, the storage engine can be modified after the table is created.

We say that the storage engine used by a table determines the structure of our data storage. How are they stored on the server? We first need to find the path where the database stores the data:

show variables like 'datadir';

[External link image transfer failed. The source site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-drfIrsP1-1603815339187)(Untitled.assets/image-20201027172157794.png)]

By default, each database has its own folder, take the forum database as an example.

[External link image transfer failed. The source site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-knZMp5Cv-1603815339189)(Untitled.assets/image-20201027172605747.png)]

Any storage engine has a frm file, this is the table structure definition file. Different storage engines store data in different ways and generate different files. Innodb has one, memory does not, and myisam has two.

What is the difference between these storage engines?

2. Storage engines supported by MySQL

MyISAM and InnoDB are the two storage engines we use the most. Before MySQL 5.5, the default storage engine was MyISAM, which comes with MySQL. When we create the table without specifying the storage engine, it will use MyISAM as the storage engine. The predecessor of MyISAM is ISAM (IndexedSequentialAccessMethod: the method of using indexes to access data sequentially).

After version 5.5, the default storage engine was changed to InnoDB, which was developed by a third-party company for MySQL. Why should it be changed? The main reason is that InnoDB supports transactions and row-level locks, which is more suitable for scenarios with high business consistency requirements.

There is also a bit of grievances between Oracle and MySQL.


InnoDB was originally developed by InnobaseOy, and it cooperated with MySQLAB to open source the code of InnoDB. But I didn't expect MySQL's competitor Oracle to acquire InnobaseOy. Later, in 2008, Sun Company (Sun, which developed the Java language) acquired MySQLAB, and in 2009, Sun Company was acquired by Oracle, so MySQL and InnoDB are another one. Some people think that MySQL is more and more like Oracle, which is actually the reason.

So in addition to these two storage engines we are most familiar with, what other commonly used storage engines does the database support? We can use this command to view the database's support for the storage engine:

show engines;

[External link image transfer failed. The source site may have an anti-leech link mechanism. It is recommended to save the image and upload it directly (img-Su09LV1i-1603815339190)(Untitled.assets/image-20201027173124782.png)]

Among them are descriptions of storage engines and support for transactions, XA protocols and Savepoints.

  • The XA protocol is used to implement distributed transactions (divided into local resource managers, transaction managers).
  • Savepoints are used to implement sub-transactions (nested transactions). After creating a Savepoints, the transaction can be rolled back to this point without affecting the operations before the creation of Savepoints.

comparative analysis

What are the characteristics of the storage engines supported by these databases?

1) MyISAM (3 files)

The scope of application is relatively small. Table-level locking limits the performance of read/write, so in Web and data warehouse configurations, it is usually used for read-only or read-based work.

  • Support table-level locking (inserts and updates will lock the table). Does not support transactions

  • Has a higher insert and query (select) speed

  • The number of rows in the table is stored (count is faster). (How to quickly insert 1 million pieces of data into the database? We have an operation that first inserts data with MyISAM and then changes the storage engine to InnoDB)

  • Applicable: data analysis projects such as read-only

2) InnoDB (2 files)

The default storage engine in mysql5.7. InnoDB is a transaction-safe (ACID-compatible) MySQL storage engine that has commit, rollback, and crash recovery functions to protect user data. InnoDB row-level locks (not upgraded to more coarse-grained locks) and Oracle-style consistent non-locking reads improve multi-user concurrency and performance. InnoDB stores user data in a clustered index to reduce I/O for common queries based on primary keys. In order to maintain data integrity, InnoDB also supports foreign key referential integrity constraints.

  • Support transactions and foreign keys, so data integrity and consistency are higher

  • Support row-level locks and table-level locks

  • Support read and write concurrency, write non-blocking read (MVCC)

  • Special index storage method can reduce IO and improve query efficiency

  • Application: frequently updated tables, business systems with concurrent read and write or transaction processing

3) Memory (1 file)

Store all data in RAM for quick access in environments where non-critical data needs to be found quickly. This engine was formerly known as the heap engine. Its use cases are decreasing; InnoDB and its buffer pool memory area provide a universal and durable method to store most or all of the data in memory, while ndbcluster provides fast key-value lookup for large distributed data sets.

  • Put the data in the memory, the speed of reading and writing is very fast, but the data will all disappear if the database is restarted or crashed. Only suitable for temporary tables.
  • Store the data in the table in memory

4) CSV (3 files)

Its table is actually a text file with comma-separated values. The csv table allows data to be imported or dumped in csv format to exchange data with scripts and applications that read and write the same format. Because the csv table does not have an index, the data is usually saved in the innodb table during normal operation, and the csv table is only used during the import or export stage.

Blank lines are not allowed, and indexes are not supported. The format is universal and can be edited directly, suitable for importing and exporting between different databases.

5) Archive (2 files)

These compact, unindexed tables are used to store and retrieve large amounts of rarely cited historical, archive, or security audit information.

Indexes are not supported, and update delete is not supported.

These are some common storage engines in MySQL. We have seen that different storage engines provide different features. They have different storage mechanisms, indexing methods, locking levels and other functions. We have different requirements for data operations in different business scenarios, and we can choose different storage engines to meet our needs. This is why MySQL supports so many storage engines.

3. How to choose a storage engine?

  • If you have high requirements for data consistency and need transaction support, you can choose InnoDB.
  • If the data query is more and less updated, and the query performance requirements are relatively high, you can choose MyISAM.
  • If you need a temporary table for query, you can choose Memory.
  • If all storage engines cannot meet your needs, and the technical capabilities are sufficient, you can develop a storage engine in C language according to the internal manual of the official website

Guess you like

Origin blog.csdn.net/weixin_43935927/article/details/113983566