InnoDB and MyISAM are a lot of people use MySQL most commonly used type of two tables, two table types have advantages and disadvantages, not the same after 5.7
1, transactions and foreign keys
InnoDB transactional support the four transaction isolation levels, rollback, crash repair capacity multi-version concurrency and transaction security, including ACID. If the application needs to perform a lot of INSERT or UPDATE operation, you should use InnoDB, which can improve the performance of multi-user concurrent operation of
MyISAM manage non-transactional table. It provides high-speed storage and retrieval, as well as full-text search capabilities. If the application needs to perform a large number of SELECT query, MyISAM is a better choice
2, full-text indexing
Innodb does not support full-text indexing, if we use, it is best to use sphinx and other search engines. myisam for Chinese support is not very good
But the new version has support Innodb
3, lock
mysql supports three levels of locking, row-level, page-level, table level;
MyISAM supports table-level locking, and Oracle provide the same type of lock is not read (non-locking read in SELECTs)
InnoDB supports row-level locking, InnoDB row lock table is not absolute, if MySQL can not determine the range to be scanned in the implementation of a SQL statement, InnoDB table locks will also affect the whole table, pay attention to the gap locks
例如update table set num=1 where name like “%aaa%”
4, storage
MyISAM storage into three files on disk. The name of the first file name of the table to start, pointed out that the extension file extension types, .frm file stores the table definition, data file name .MYD, index file extension is .MYI
InnoDB, disk-based resource is InnoDB tablespace data files and its log files, InnoDB table size is limited only to the operating system file size
Note: MyISAM table is stored in the form of a file, use the data transfer cross-platform MyISAM storage will save a lot of trouble
5, the index
The InnoDB (index organized tables) used clustered index, the index data is stored sequentially, it is possible to cache index, the data can also be cached
A non-clustered index MyISAM (heap organization table) used, and the index file separately, random access memory, a cache index only
6, concurrent
MyISAM blocking read and write to each other: not only can block read when written, MyISAM can block write when read, but reading by itself does not block other read
InnoDB write blocking associated with the transaction isolation level
7, Scene Selection
MyISAM
- Does not require transaction support (not supported)
- Concurrent relatively low (locking mechanism issue)
- Relatively few data modification (blocking problem), read-mostly
- Data consistency requirements are not very high
- Try Index (caching)
- Adjust the priority of reading and writing, according to the actual needs of important actions to ensure that greater priority
- Enabling delayed insertion write performance improvement in large quantities
- Try to make the order of operations insert data is written to the tail, reduce congestion
- Decomposition large operation, a single operation to reduce blocking time
- Reduce the number of concurrent, some high concurrency scenarios carried out by applying queuing mechanism
- For relatively static data, make full use Query Cache can greatly improve the efficiency of access
- Count of MyISAM only when a full table scan is particularly efficient, count with other conditions need to be actual data access
InnoDB
- Require transaction support (with better characteristics Affairs)
- Row-level locking has a good ability to adapt to high concurrency, but need to make sure that the query is completed by an index
- More frequent data updates scenes
- Require a higher data consistency
- Large memory hardware, you can use InnoDB better caching, the ability to improve memory utilization, minimize disk IO
- Primary key as small as possible, avoid Secondary index put excessive burdens space
- Avoid full table scan, because it will use table locks
- As the index and cache all data, improve response time
- In large quantities of small insertions, try to control their own affairs and do not use autocommit automatic submission
- Innodb_flush_log_at_trx_commit reasonable set of parameter values, do not over-pursue security
- Avoid the primary key update, because it will bring a lot of data movement
8, other details
1) the number of rows is not particularly InnoDB storage table, note that, when the count (*) statement contains the conditions where, two kinds of operation is the same table
2) For AUTO_INCREMENT type of field, InnoDB must contain only the index of the field, but in the MyISAM table, you can other fields to establish joint index together, if you specify an AUTO_INCREMENT column for a table, InnoDB table handle in the data dictionary of It contains a counter called the auto-increment counter, which is used in assigning new values for the column. Auto-increment counter is stored only in main memory rather than disk exists
3) When the DELETE FROM table, InnoDB will not re-establish the table, but delete the line by line
4) LOAD TABLE FROM MASTER InnoDB operation does not work, the solution is first put into InnoDB tables MyISAM table, and then import the data into InnoDB tables, but for additional InnoDB characteristics (e.g., foreign key) used table NA
5) If you do a lot of SELECT, MyISAM is a better choice, if you perform a large number of data INSERT or UPDATE, for performance reasons, you should use InnoDB tables
7. Why MyISAM will be faster than the query speed Innodb
InnoDB doing SELECT when you want to maintain a lot more things than MYISAM engine;
1) InnoDB data to be cached and indexed, only MyISAM cache index block, there is an intermediate which is reduced to be swapped out
2) innodb address to be mapped to a block, then the file is the OFFSET direct line, MyISAM recorded positioning faster than INNODB
3) InnoDB also need to maintain a consistent MVCC; though not your scene, but he still needs to check and maintain
MVCC (Multi-Version Concurrency Control) multi-version concurrency control
InnoDB: By adding two rows for each additional hidden value to achieve MVCC, these two values a record of when this row of data is created, another record when this line of data expired (or deleted). But InnoDB does not store the actual time when these events occur, on the contrary it only storage system version number when these events occur. This is a number with the creation of affairs and growing. Each transaction will be recorded when the transaction began its own system version number. Each query must check the version number to each row of data and transactions of the version number are the same. Let's see when the isolation level is REPEATABLE READ when this strategy is how to apply to a specific operation
SELECT InnoDB must each row of data to ensure that it meets two conditions
1, InnoDB must find a version of the line, and it is at least as old versions of the transaction (that is, its version number is not greater than the version number of the transaction). This ensures that the matter is before the transaction begins, or when the transaction is created or modified the data line when the line data is there.
2, delete the version of this line of data must be undefined or larger than transactional version. This ensures that no rows are deleted before the transaction began.
8, mysql performance discussion
MyISAM most people criticized the shortcomings is the lack of support services
InnoDB disk performance is very worrying
MySQL lack of good tablespace
The main difference between the two types is Innodb support transaction processing and foreign keys, and row-level locking. The MyISAM does not support. Therefore, it is easy to MyISAM often been considered suitable only for use in small projects.
I, as a user perspective using MySQL departure, Innodb and MyISAM are more like, but from my current operation and maintenance of the database platform to achieve demand: 99.9% of stability, convenience of scalability and high availability is the case, absolutely MyISAM It is my first choice.
For the following reasons:
1, first of all most of my current project is hosted on the platform reading and writing small projects rather than read performance MyISAM is a lot of strong Innodb.
2, MyISAM index and data are separated, and the index is compressed, memory usage corresponds to improve a lot. More can load index and is Innodb index and data are closely tied, do not use compression which will result in Innodb bulky than MyISAM is not small.
3, from a platform perspective, often occur every month or two application developers do not accidentally update a table where the scope does not write, can not lead the table with normal, and this time MyISAM superiority manifested a casual correspondence table extracted from the compressed file copy day, just put under a directory database, and then dump into sql then turned back to the main database, and on the corresponding binlog complement. If Innodb, I am afraid that there can be such a fast speed, and I do not say let Innodb regularly with export xxx.sql backup mechanism, because the amount of data a minimum of a database instance on my platform basically tens of G size.
4, application logic from my contact with it, select count (*) and order by most frequently, would be able to account for more than 60% of the total operation of the entire sql statement, and this is actually the operating Innodb will lock table many people think that Innodb is row-level locking, that it is only where the primary key is valid, non-primary key will lock the whole table.
5, there is often a lot of applications departments need me to give them some regular data tables, MyISAM, then it is easy for them to send correspondence frm.MYD that table, MYI file, let them in the corresponding version of the database start on the line, and you need to export xxx.sql Innodb, because the light to others file, the affected data dictionary file, the other party can not be used.
6, if the ratio insert MyISAM and write, then, Innodb yet reached MyISAM write performance, if it is for the update operation based on the index, although the MyISAM may be less Innodb, but so high concurrent write, from the library can chase on it is also a problem, not as by sub-library sub-table multi-instance architecture to solve.
7, if it is, then use MyISAM, merge engine can greatly speed up application development department, as long as they merge on the table to do some select count (*) operation, it is ideal for large projects total about hundreds of millions of rows of a certain type (such as logs, survey) business table.
Of course Innodb not absolutely no use for Project Services such as stock market simulation project, I use active users more than 20 million times, is also very easy Innodb cope, so I personally also like to Innodb, but if the database platform application departure, I still preferred MyISAM.
In addition, some people may say you MyISAM can not write too much anti, but I can be offset by the architecture, to say the use of my existing database platform capacity: the amount of data in a master-slave more than a few hundred T, more than one billion daily pv dynamic pages, there are several large projects through the data interface invoke not counted in the total number of pv, (including a major project since the beginning of memcached did not deploy, resulting in a single database handling 90 million queries per day). And my whole database server load average at around 0.5-1.
MyISAM index achieved
MyISAM engine used as a B + Tree index structure, leaf node is stored in the address data field of the data record. Figure:
Here provided a total of three tables, we assume Col1 primary key, the primary index is a figure MyISAM tables (Primary key) schematically. It can be seen MyISAM index file only save the address data records. In MyISAM, the main index and a secondary index (Secondary key) without any difference in structure, but the main index key requirement is unique, and the auxiliary key index may be repeated. If we build a secondary index on Col2, the structure of this index is shown below:
Is also an address B + Tree, data field holds the data records. Thus, MyISAM index search algorithm first search algorithm in accordance with the B + Tree search index, if the specified Key is present, the value of its data field taken out, then the value of the address data field, reads the corresponding data record.
MyISAM indexes mode is also called "non-clustered", the reason so called to distinguish the InnoDB clustered index.
InnoDB index achieved
Although InnoDB also be used as a B + Tree index structure, but the specific implementation manner, but with different MyISAM.
The first major difference is that InnoDB data file itself is an index file. Known from the above, MyISAM index file and data file are separate, only the address of the index file stored in the data record. In the InnoDB table data file itself is a pressing B + Tree index structure of the organization, this tree's leaf node data field holds a complete data record. This index is the primary key of key data tables, so InnoDB table data file itself is the main index.
The figure is a schematic diagram InnoDB primary index (also data files), you can see the leaf node contains complete data record. This index is called the clustered index. Because InnoDB data file itself Yaoan primary key aggregation, so InnoDB requires table must have a primary key (MyISAM can not), if not explicitly specified, MySQL system will automatically select a column as the primary key uniquely identifies a data record, if there is no this column, MySQL automatically generates a hidden field as the primary key InnoDB tables, this field is 6 bytes in length, as long integer type.
The second difference is that the MyISAM index InnoDB secondary index field stores data records corresponding to the primary key value instead of an address. In other words, all the secondary index InnoDB are cited as the primary key data field. For example, defined below shows a secondary index on the Col3:
Here in ASCII English characters as the comparison criteria. This implementation clustered index makes the search highly efficient primary key press, but the secondary index search index needs to be retrieved twice: first retrieve the auxiliary primary key index is obtained, and then use the primary index to the primary key to retrieve records obtained.
to sum up
In database development, understand the different storage engines for indexing implementation and optimization proper use of the index are very helpful. For example, knowing the InnoDB after the index to achieve, it is easy to see why not recommend the use of long field as the primary key, because all secondary indexes are references to the main index, long the main index will make secondary indexes become too large. As another example, a non-monotonic field as the primary key in InnoDB is not a good practice because InnoDB data file itself is a B + Tree, non-monotonic primary key will result in the insertion of a new recording data file in order to maintain + Tree characteristic B and frequent split adjusted, very inefficient, and use auto-increment field as the primary key is a good choice.