MySQL存储引擎之InnoDB

时间:2020-12-11 07:33:58

一、The InnoDB Engine

  Each InnoDB table is represented on disk by an .frm format file in the database directory,as well as data and index storage in the InnoDB tablespace.The InnoDB tablespace is a logical single storage area that is made up of one or more files or partitions on disk.By default,InnoDB uses a single tablespace that is shared by all InnoDB tables.The tablespace is stored in machine-independent format.It is implemented such that table sizes can exceed the maximum file size allowed by the filesystem.It is also possible to configure InnoDB to create each table with its own tablespace.

  InnoDB supports transactions,with commit and rollback.It provides full ACID(atomicity,consistency,isolation, durability) compliance.Multi-versioning is used to isolate transactions from one another.

  InnoDB provides auto-recovery after a crash of the MySQL server or the host on which the server runs.     MySQL manages query contention for InnoDB tables using multi-versioning and row-level locking.Multi- versioning gives each transaction its own view of the database.This,combined with row-level locking,keeps contention to a minimum.The result is good query concurrency even if clients are performing a mix of reads and writes.However,it's possible for deadlock to occur.     InnoDB supports foreign keys and referential integrity,including cascaded deletes and updates.     The tablespace storage format is portable,so InnoDB files can be copied directly to another host and used by a server there.     InnoDB operates using two primary disk-based resources:a tablespace for storing table contents,and a set of log files for recording transaction activity.

  Each InnoDB table has a format (.frm) file in the database directory of the database to which the table belogs. This is the same as tables managed by any other MySQL storage engine,such as MyISAM.However,InnoDB manages table contents (data rows and indexes) on disk differently than does the MyISAM engine.By default, InnoDB uses a shared "tablespace",which is one or more files that form a single logical storage area.All InnoDB tables are stored together within the tablespace.There are no table-specific data files or index files for InnoDB the way there are for MyISAM tables.The tablespace also contains a rollback segment.As transactions modify rows,undo log information is stored in the rollback segment.This information is used to roll back failed transactions.

二、The InnoDB Tablespace and Logs

  Although InnoDB treats the shared tablespace as a single logical storage area,it can consist of one file or multiple files.Each file can ben a regular file or a raw partition.The final file in the shared tablespace can ben configured to be auto-extending,in which case InnoDB expands it automatically if the tablespace file up. Because the shared tablespace is used for InnoDB tables in all database (and thus is not database specific), tablespace files are stored by default in the server's data directory,not within a particular database directory.

  If you do not want to use the shared tablespace for storing table contents,you can start the server with the --innodb_file_per_table option.In this case,for each new table that InnoDB creates,it sets up an .ibd file in the database directory to accompany the table's .frm file.The .ibd file acts as the table's own tablespace file and InnoDB stores table contents in it.(The shared tablespace still is needed because it contains the InnoDB data dictionary and the rollback segment.)

  Use of the --innodb_file_per_table option does not affect accessibility of any InnoDB tables that may already have been created in the shared tablespace.Those tables remain accesibel.

  In addition to its tablespace files,the InnoDB storage engine manages a set of InnoDB-specific log files that contain information about ongoing transactions.As a client performs a transaction,the changes that it makes are held in the InnoDB log.The more recent log contents are cached in memory.Normally, the cached log information is written and flushed to log files on disk at transaction commit time,though that may also occur earlier.

  If a crash occurs while the tables are being modified,the log file are used for auto-recovery.When the MySQL server restarts,it reapplies the changes recorded in the logs,to ensure that the tables reflect all committed transactions.

  It can consist of one file or multiple files.     Each component file of the tablespace can be a regular file or a raw partition (a device file).A given tablespace can including both types of files.

  Tablespace files can be on different filesystems or physical disk drives.One reason to place the files on multiple physical drives is to distribute InnoDB-related disk activity among them.

  The tablespace size can exceed the limits that the filessystem places on maximum file size.This is true for two reasons.First,the tablespace can consist of multiple files and thus can be large than any single file.Second, the tablespace can include raw partitions,which are not bound by filesystem limits on maximum file size.InnoDB can use the full extent of partitions,which makes it easy to configure a very large tablespace.

  The last component of the tablespace can be auto-extending,with an optional limit on how large the file can grow.           

Using Foreign Keys   Both tables must be InnoDB tables and they must be TEMPORARY tables.     In the referencing table,there must be an index where the foreign key columns are listed as the first columns in the same order.Such an index is created on the referencing table automatically if it does not exist.     In the referenced table,there must be an index where the referenced columns are listed as the first columns in the same order.

  Index prefixes on foreign key columns are not supported.     If the CONSTRAINT symbol clause is given,the symbol value must be unique in the database.   

三、Configuring InnoDB Buffers  

   InnoDB uses a buffer pool to hold information read from InnoDB tables.The buffer pool serves to reduce disk I/O for information that is frequently accessed,and a larger buffer more effectively achieves this goal.To change the size of the buffer pool,set the innodb_buffer_pool_size option.Its default value is 8MB.If your machine has the memory available,you can the value much higher.

  innodb_buffer_pool_size  

  The size in bytes of the momory buffer InnoDB uses to cache data and indexes of its tables.The larger you set this value,the less disk I/O is neednd to access data in tables.On a dedicated database server, you may set this to up to 80% of the machine physical memory size.However,do not set it too large because competition for physical memory might cause paging in the operating system.

  innodb_additional_mem_pool_size  

  The size in bytes of a memory pool InnoDB uses to store data dictionary information and other internal data structures.The more tables you have in your application,the more memory you need to allocate here.If InnoDB runs out of memory in this pool,it starts to allocate memory from the operating system and writes warning messages to the MySQL error log.The default value is 1MB.

  Innodb_max_dirty_pages_pct  

  This is an integer in the range from 0 to 100.The default is 90.The main thread in InnoDB tries to write pages from the buffer pool so that the percentage of dirty(not yet written) pages will not exceed this value.     

四、Use foreign key

mysql> create table parent(p_id int,p_msg varchar(100),
    ->  index idx_p_id (p_id))
    -> engine = innodb;
Query OK, 0 rows affected (0.05 sec)

mysql> show index from parent \G;
*************************** 1. row ***************************
        Table: parent
   Non_unique: 1
     Key_name: idx_p_id
 Seq_in_index: 1
  Column_name: p_id
    Collation: A
  Cardinality: 0
     Sub_part: NULL
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment: 
Index_comment: 
1 row in set (0.01 sec)

ERROR: 
No query specified

mysql> create table child(c_id int,c_msg varchar(200),
    ->   foreign key (c_id) references parent(p_id)
    ->  on delete cascade
    ->  on update cascade)
    ->  engine = innodb;
Query OK, 0 rows affected (0.04 sec)


mysql> show index from child \G;
*************************** 1. row ***************************
        Table: child
   Non_unique: 1
     Key_name: c_id
 Seq_in_index: 1
  Column_name: c_id
    Collation: A
  Cardinality: 0
     Sub_part: NULL
       Packed: NULL
         Null: YES
   Index_type: BTREE
      Comment: 
Index_comment: 
1 row in set (0.01 sec)

ERROR: 
No query specified

mysql> insert into child values(1,'aaa');
ERROR 1452 (23000): Cannot add or update a child row: a foreign key constraint fails (`jack`.`child`, CONSTRAINT `child_ibfk_1` FOREIGN KEY (`c_id`) REFERENCES `parent` (`p_id`) ON DELETE CASCADE ON UPDATE CASCADE)  



mysql> insert into parent values(1,'aaaaaa');
Query OK, 1 row affected (0.01 sec)

mysql> insert into child values(1,'aaa');
Query OK, 1 row affected (0.01 sec)

mysql> select * from child;
+------+-------+
| c_id | c_msg |
+------+-------+
|    1 | aaa   |
+------+-------+
1 row in set (0.01 sec)

mysql> select * from parent;
+------+--------+
| p_id | p_msg  |
+------+--------+
|    1 | aaaaaa |
+------+--------+
1 row in set (0.00 sec)

mysql> insert into child values(1,'bbbb');
Query OK, 1 row affected (0.01 sec)

mysql> select * from child;
+------+-------+
| c_id | c_msg |
+------+-------+
|    1 | aaa   |
|    1 | bbbb  |
+------+-------+
2 rows in set (0.00 sec)

mysql> update parent set p_id=2;
Query OK, 1 row affected (0.05 sec)
Rows matched: 1  Changed: 1  Warnings: 0

mysql> select * from child;
+------+-------+
| c_id | c_msg |
+------+-------+
|    2 | aaa   |
|    2 | bbbb  |
+------+-------+
2 rows in set (0.00 sec)

mysql> select * from parent;
+------+--------+
| p_id | p_msg  |
+------+--------+
|    2 | aaaaaa |
+------+--------+
1 row in set (0.00 sec)

mysql> delete from parent;
Query OK, 1 row affected (0.20 sec)

mysql> select * from parent;
Empty set (0.00 sec)

mysql> select * from child;
Empty set (0.00 sec)

mysql> select constraint_name,update_rule,delete_rule,table_name,referenced_table_name from REFERENTIAL_CONSTRAINTS where table_name = 'child';
+-----------------+-------------+-------------+------------+-----------------------+
| constraint_name | update_rule | delete_rule | table_name | referenced_table_name |
+-----------------+-------------+-------------+------------+-----------------------+
| child_ibfk_1    | CASCADE     | CASCADE     | child      | parent                |
+-----------------+-------------+-------------+------------+-----------------------+
1 row in set (0.01 sec)