Differences between MySQL Engines

What is the storage engine? Data in MySQL is stored in files (or memory) using different technologies. Each of these technologies uses different storage mechanisms, indexing techniques, locking levels, and ultimately provides a wide range of different features and capabilities. By choosing different technologies, you can get additional speeds or features to improve the overall functionality of your application. For example, if you are studying a large amount of temporary data, you may need to use the memory storage engine. The memory storage engine can store all table data in the memory. Alternatively, you may need a database that supports transaction processing (to ensure the ability to roll back data when the transaction processing fails ). These different technologies and related functions are called storage engines (also called table types) in MySQL ). MySQL is configured with many different storage engines by default, which can be set in advance or enabled on the MySQL server. You can select a storage engine for servers, databases, and tables, this gives you maximum flexibility when choosing how to store your information, how to retrieve it, and what features and features you need to combine your data. The flexibility to choose how to store and retrieve your data is the main reason why MySQL is so popular. Other database systems (including most commercial options) only support one type of data storage. Unfortunately, the "one size fits all needs" approach adopted by other types of database solutions means you have to sacrifice some performance, you can adjust your database in several hours or even days. To use MySQL, we only need to modify the storage engine we use. In this article, we are not prepared to focus on the technical aspects of different storage engines (although we inevitably want to study some aspects of these factors). On the contrary, we will focus on the requirements that these different engines are most suitable for and how to enable different storage engines. To achieve this, we must understand some basic problems before introducing the specific situation of each storage engine. How to determine which storage engines are available You can use the Display Engine Command in MySQL (for example, MySQL Server 4.1.2 or later) to get a list of available engines. mysql> show engines;+------------+---------+------------------------------------------------------------+| Engine | Support | Comment |+------------+---------+------------------------------------------------------------+| MyISAM | DEFAULT | Default engine as of MySQL 3.23 with great performance || HEAP | YES | Alias for MEMORY || MEMORY | YES | Hash based, stored in memory, useful for temporary tables || MERGE | YES | Collection of identical MyISAM tables || MRG_MYISAM | YES | Alias for MERGE || ISAM | NO | Obsolete storage engine, now replaced by MyISAM || MRG_ISAM | NO | Obsolete storage engine, now replaced by MERGE || InnoDB | YES | Supports transactions, row-level locking, and foreign keys || INNOBASE | YES | Alias for INNODB || BDB | NO | Supports transactions and page-level locking || BERKELEYDB | NO | Alias for BDB || NDBCLUSTER | NO | Clustered, fault-tolerant, memory-based tables || NDB | NO | Alias for NDBCLUSTER || EXAMPLE | NO | Example storage engine || ARCHIVE | NO | Archive storage engine || CSV | NO | CSV storage engine |+------------+---------+------------------------------------------------------------+16 rows in set (0.01 sec) This table shows the list of available database engines and whether these engines are supported in the current database server. For MySQL versions earlier than MySQL 4.1.2, you can use mysql> show variables like "have _ %" (display variables similar to "have _ % ): mysql> show variables like "have_%"; +------------------+----------+ | Variable_name | Value | +------------------+----------+ | have_bdb | YES | | have_crypt | YES | | have_innodb | DISABLED | | have_isam | YES | | have_raid | YES | | have_symlink | YES | | have_openssl | YES | | have_query_cache | YES | +------------------+----------+ 8 rows in set (0.01 sec)  You can set the available engine in the MySQL Installation Software by modifying the options in the setting script. If you are using a pre-packaged MySQL binary release software, this software contains common engines. However, it should be noted that if you want to use some uncommon engines, especially CSV, rchive (archive) and blackhole (black hole) engines, you need to manually recompile the MySQL source code. Use a specified storage engine You can specify a storage engine in many ways. The simplest method is to set a default engine type (using the storage_engine option) in the MySQL settings file if you like a storage engine that meets most of your database requirements) you can also add the -- default-storage-engine or -- default-table-type option after the command line when starting the database server. A more flexible way is to specify the storage engine used when the mysql client is released along with the MySQL server. The most direct method is to specify the storage engine type when creating a table, as shown below: Create Table mytable (ID int, title char (20) engine = InnoDB You can also change the storage engine used by the existing table by using the following statement: Alter table mytable engine = MyISAM However, you need to be very careful when modifying the table type in this way, because modifying a type that does not support the same index, field type, or table size may cause data loss. If you specify a storage engine that does not exist in your current database, a MyISAM (default) type table will be created. Differences between storage engines To determine which storage engine to choose, we must first consider the different core functions provided by each storage engine. This feature allows us to differentiate different storage engines. We generally divide these core functions into four categories: supported fields and data types, lock types, indexes, and processing. Some engines have unique features that can motivate you to make decisions. Let's take a closer look at these specific issues. Field and Data Type Although all these engines support common data types, such as integer, real, and complex types, not all engines Support other field types, especially blogs (Binary large objects) or text type. Other engines may only support limited character widths and data sizes. These limitations may directly affect the data you can store, or indirectly affect the type of the search you implement or the index you create for the information. These differences can affect the performance and functions of your application, because you must choose to make decisions on the features of the storage engine based on the data type you want to store. Lock The locking function in the database engine determines how to manage access and update information. When an object in the database is locked for Information Update, other processes cannot modify the data before the update is complete (in some cases, this data cannot be read ). Locking affects not only how many different applications update information in the database, but also the query of that data. This is because the query may need to access the data being modified or updated. In general, this latency is very small. Most locking mechanisms are designed to prevent multiple processes from updating the same data. Because inserting and updating information to data both needs to be locked, you can imagine that using the same database by multiple application programs may have a great impact. Different storage engines Support locking at different object levels, and these levels affect information that can be accessed at the same time. Three supported levels are available: Table locking, block locking, and row locking. Table locks are the most supported. Such locks are provided in MyISAM. When the data is updated, it locks the entire table. This prevents many applications from updating a specific table at the same time. This has a great impact on many multi-user databases, because it delays the update process. Page-level locking uses the Berkeley DB Engine and locks data based on the uploaded information page (8 KB. When the database is updated in many places, this locking will not cause any problems. However, the last 8 KB of the data structure will be locked when several lines of information are added. When a large number of rows are required, especially a large amount of small data, this will cause problems. Row-level locking provides the best parallel access function. Only one row of data in a table is locked. This means that many applications can update the data of different rows in the same table without locking. Only the InnoDB Storage engine supports row-level locking. Create an index Index creation can significantly improve performance when searching and recovering data in the database. Different storage engines provide different indexing technologies. Some technologies may be more suitable for the data type you store. Some storage engines do not support indexing at all, probably because they use basic table indexes (such as the merge engine) or because indexes (such as federated or blackhole engines) are not allowed in data storage ). Transaction Processing The transaction processing function provides reliability during the update and insertion of information into the table. This reliability is achieved through the following method, which allows you to update the data in the table, but only accepts the changes to the table after all the related operations of the application are complete. For example, the processing of each accounting entry in the accounting process will include