The difference between InnoDB and MyISAM (High Performance MySQL notes)

1, InnoDB supports transactions, MyISAM does not support, that is to say MyISAM does not support transaction rollback operation, this function can be fatal

2, InnoDB supports row locking, MyISAM table locks only support, but InnoDB row lock is built on top of the index, which means that if the index does not hit, then the operation will still relegated to a table lock. As for the index uid

    update t_user set age = 10 where uid = 1; hit index, row locks.

    update t_user set age = 10 where uid = 1;! misses index table lock.

3, InnoDB table is created based on cluster index using B + tree, MyISAM is based on non-clustered index, index data structure is a B + tree

  Clustered index: it is not a separate index type, but a data storage. Clustered index is established relying on the primary key, this index value and the storage of all the data stored in the row to the same structure.

If no primary key, InnoDB will choose a unique non-empty instead of the index, if the index does not meet the conditions, implicit InnoDB will create a primary key as the clustered index. InnoDB, the non-clustered index, also known as secondary index or two indexes, they are the data of a row address ( corrected here, the index pointer stored in the two rows is not directed, but the primary key of the OK! ) to deposit leaf node B + tree, that is, to find the index by two lines of data stored in the main engine need to find a leaf node the key corresponding to the secondary index, and according to this value clustered index Find the corresponding data line. Here to do a repetitive work, so do at least twice a B + tree to find (at least, is because there may be some updated data can not be stored in its original location, which can lead to fragmentation of the table appears in a row or left in situ a pointer to the new location, thus a non-clustering index may not be able to find the object of primary key). For InnoDB, the adaptive hash index can be reduced such repeating work.

Therefore, the clustered index is essential for IO-intensive systems, can greatly improve its performance. But if all the data stored in the system memory, the clustered index will be no advantage. However, the clustered index also has some drawbacks, such as updating the price index of the column too cramped, the entire row of data had to follow the index to a new location, as well as page splitting issues.

For MyISAM storage engine, the file contains the following three formats:

.frm file table structure described  
.MYD is a table data file  
.MYI table data file is any index tree data

For InnoDB, both index and data in the same file, .IDB

 

4, InnoDB is not saved specific rows in the table, the execution select count (*) requires a full table scan from table. The MyISAM use a variable to hold the number of rows in the entire table, just read the variable carrying out the above statement can be, very fast

5, InnoDB version began to support full-text index after 5.7, and supports full-text index has been MyISAM

6, MyISAM supports compression, transmission of compressed table, query rates are greatly improved, but the table in a compressed state can not be amended, modified only before extracting

7, InnoDB and MyISAM does not support foreign keys support, that is to say, if you turn into a table by the InnoDB MyISAM and then turn back, foreign keys will disappear

8, InnoDB table must have a primary key (user does not specify, then will find himself or generate an implicit primary key), but you can not Myisam


 

So both how to choose?

  • If you need the transaction and transaction rollback, InnoDB!
  • If you read much more than write, MyISAM! 
  • If you still have no idea, then InnoDB it, after all it is the main push (default) memory engine

 

Finally, mention here InnoDB engine of the four characteristics (want to delve into the students can see the link blogger): insert buffer (insert buffer), the second write (double write), adaptive hash index (ahi ), pre-reading (read ahead)

 

Guess you like

Origin www.cnblogs.com/ZoHy/p/11305269.html