MySQL storage engine MyISAM and InnoDB talk in detail

I. Overview

MySQL database supports a variety of storage engines, including MyISAM, InnoDB, MERGE, MEMORY (HEAP), BDB (BerkeleyDB), EXAMPLE, FEDERATED, ARCHIVE, CSV, BLACKHOLE, etc.

We can show enginescheck the support for engine types of MySQL installed on our system through instructions:
Insert picture description here

You can also show variables like '%storage_engine%'view the storage engine used by MySQL by default through instructions. From the figure below, you can see that the default storage engine for MySQL on my system is InnoDB.
Insert picture description here

My MySQL version is 5.7.32:
Insert picture description here
MyISAM is the storage engine that comes with MySQL; InnoDB is developed by a third-party company and integrated into MySQL in the form of a plug-in.
Before version 5.5, MyISAM was MySQL's default database engine; later versions of MySQL used more InnoDB by default.

This article mainly discusses the commonly used MyISAM and InnoDB.


Two, MyISAM and InnoDB talk in detail

1. Compare

1. Storage structure
1) MyISAM
Each MyISAM is stored as three files on the disk. The name of the first file starts with the name of the table, and the extension indicates the file type.
.frm: table structure file
. MYD: data file.
MYI: index file

The index file saves the location of the data file where the record is located. After the location information is obtained by reading the index file, the data is quickly obtained by reading the data file.
Insert picture description here
2) InnoDB
has only two files:
.frm: table structure file.
ibd: data, index file

InnoDB uses a clustered index to implement a B-Tree index. The clustered index is implemented by compactly storing data rows and adjacent primary keys in a file.
The size of the InnoDB table is only limited by the size of the operating system file, which is generally 2GB.
Insert picture description here
InnoDB uses tablespace (tablespace) to manage data, store table data and indexes. Before mysql5.6.6, a shared table space was used, and a single table space was used in later versions.

  • Shared table space: ibdata1 and ibdata2 are stored in the Data folder, and all tables are shared.
  • Single table space: It can be opened through global variables. After opening, each table has a corresponding .ibd corresponding to it.
# When innodb_file_per_table is enabled (the default in 5.6.6 and higher), InnoDB stores the data and indexes for each newly created table
# in a separate .ibd file, rather than in the system tablespace.
innodb_file_per_table=1

You can show variables like '%innodb_file_per_table%'check whether mysql opens a separate table space through instructions: the advantages and disadvantages of
Insert picture description here
shared table space and single table space :
1) Single table space
Advantages:
-Each table has its own independent table space.
-The data and indexes of each table will be stored in its own table space.
-A single table can be moved in different databases.
-Space can be reclaimed (drop/truncate table operation table space cannot be automatically reclaimed).
-For tables that use independent tablespaces, no matter how you delete them, the fragmentation of the tablespace will not affect performance too seriously, and there are opportunities to deal with it.
Disadvantages:
-The single table increase is larger than the shared space method.

2) Common table space
Advantages:
-The table space can be divided into multiple files and stored on each disk (the table space file size is not limited by the table size, such as a table can be distributed on different files).
-The size limit is no longer the file size limit, but its own limit. As you can see from Innodb's official documentation, the maximum limit of its table space is 64TB.

Disadvantages:-All
data and indexes are stored in one file. There will be a very large file. Although a large file can be divided into multiple small files, multiple tables and indexes are stored in the table space. After a large number of delete operations are performed on a table, there will be a large number of gaps in the table space, especially for statistical analysis, the log system is the least suitable for applications such as shared table space.

2. Transactions
1) MyISAM
does not support transactions. Emphasis on performance, execution is faster than InnoDB type.

2) InnoDB
supports transactions. Provide advanced database functions such as external keys.
InnoDB's AUTOCOMMIT is turned on by default, that is, each SQL statement will be encapsulated into a transaction by default and submitted automatically, but this will affect efficiency; we can merge transactions and display multiple SQL statements between begin and commit to form a composition Resubmit a transaction to reduce the overhead caused by multiple submissions of the database and improve performance.

3. CURD operation
1) MyISAM

  • If you perform a large number of selects, MyISAM is the best choice.

2)InnoDB

  • If you perform a lot of INSERT or UPDATE, InnoDB should be used in terms of performance;
  • Execute delete from table, InnoDB will not re-create the table, but delete row by row;
  • load table from masterThe operation does not work for InnoDB. Solution: Change InnoDB to MyISAM table, import data and then change to InnoDB. However, it does not apply to tables that use additional InnoDB features (foreign keys).

4、AUTO_INCREMENT
1)MyISAM

  • MyISAM automatically updates this column for INSERT and UPDATE operations, making the AUTO_INCREMENT column faster. After the value at the top of the sequence is deleted, it cannot be reused. (When the AUTO_INCREMENT column is defined as the last column of a multi-column index, the value deleted from the top of the sequence can be reused)
  • The AUTO_INCREMENT value can be reset with ALTER TABLE or myisamch.
  • For fields of type AUTO_INCREMENT, a joint index can be established with other fields.

2)InnoDB

  • If you specify an AUTO_INCREMENT column for a table, the InnoDB table handle in the data dictionary contains a counter called an auto-increment counter, which is used to assign a new value to the column.
  • The auto-increment counter is only stored in main memory, not on disk.

5, Table row
1) MyISAM
specific number of rows MyISAM storage table in the query select count(*) from tablewhen the query number of rows in the table, simply read out the number of rows to save.
However, when the count(*) statement contains where conditions, you need to scan the entire table to get the number of rows.

2) InnoDB
InnoDB does not save the specific number of rows in the table. When executing select count(*) from table, InnoDB will scan the entire table to calculate how many rows there are.

6. Lock
Table-level lock:-When inserting a table, the table-level lock locks the entire table.
-Low overhead, fast locking, no deadlock, large lock granularity (the entire table), low concurrency, and high probability of lock contention.
Row-level lock:-Use row-level lock to change multiple attributes for one piece of data.
-High overhead, slow locking, deadlocks, minimum lock granularity (one row of data), high concurrency, and low lock contention probability.
Page level lock:-The data is stored on the disk as one page, one page is 4K. For a relatively large table (such as tens of millions), lock part of the table data at this time, and only one operation is allowed on one page .
-The overhead, locking speed, lock granularity, and concurrency are all between table-level locks and row-level locks, and deadlocks will occur.

1) MyISAM
provides table locks.

2) InnoDB
provides row locks and table locks.

Row locks are implemented by locking index items, which will fail in the following situations, and lock the entire table:

  • Not retrieve data by index conditions, such as update table set a=1 where user like '%lee%'.
  • DELETE FROM mytableSuch delete statement.

7. Table primary key
1) MyISAM
allows tables without any indexes and primary keys to exist, and indexes are the addresses where rows are stored.

2) InnoDB
stores the index value (the value of the primary key ) for the primary key index, and also stores the data of each column. If the primary key is not set, it will try to use the foreign key as the primary key. If there is no foreign key, a hidden ROWID will be automatically generated as the primary key. InnoDB has a larger primary key range, up to 2 times that of MyISAM.

8. Full text index
1) MyISAM
supports (FULLTEXT type) full text index.

2) InnoDB
does not support (FULLTEXT type) full-text indexing, but you can use the sphinx plug-in to support full-text indexing, and the effect is better.

Q: Why does InnoDB not support full-text indexing?
InnoDB data is already on the node. If you want to index full-text, it is equivalent to copying a database.

Q: Which storage engine should be used for blog system articles?
It is better to store the articles of the blog system in MyISAM. InnoDB's leaf nodes are used to store articles, which makes the leaf nodes too large and not suitable for storing articles. The full-text index of the blog system is a summary and MD5 value for query.

Q: Which is faster to find data?
For a table, MyISAM can add the index tree of the entire table to the memory, and then find it on the disk. InnoDB adds part of the data to the memory because it can get the data directly.
To find a piece of data (with less data), MyISAM is faster than InnoDB, and InnoDB is faster than MyISAM when there are more data to query. This is because MyISAM reads a piece of data every time it reads the disk, and InnoDB can save the commonly used data. Part of the data is stored in memory.

2. Usage scenarios

1)MyISAM

  • Read operation is the main business, and UPDATE is relatively small, so it is suitable to use MyISAM.
  • Concurrency is not high.
  • The amount of table data is small.
  • Hardware resources are limited.

2)InnoDB

  • The amount of reading and writing is not much, and large fields are frequently updated. Choose InnoDB.
  • The table data volume exceeds 10 million, and the concurrency is high.
  • High safety and reliability requirements.

Guess you like

Origin blog.csdn.net/locahuang/article/details/110475389