Skip to content

M
MariaDB
Commit 1a754720 authored by arjen@co3064164-a.bitbike.com's avatar arjen@co3064164-a.bitbike.com
Browse files
Options

manual.texi: 

  InnoDB section merge from Heikki.
parent 8066874e
Hide whitespace changes
Inline Side-by-side
Showing with 258 additions and 144 deletions
Docs/manual.texi
View file @ 1a754720
......@@ -37458,37 +37458,85 @@ SUM_OVER_ALL_KEYS(max_length_of_key + sizeof(char*) * 2)
@section InnoDB Tables
@menu
* InnoDB overview:: InnoDB tables overview
* InnoDB start:: InnoDB startup options
* InnoDB init:: Creating InnoDB table space.
* Using InnoDB tables:: Creating InnoDB tables
* Adding and removing:: Adding and removing InnoDB data and log files
* Backing up:: Backing up and recovering an InnoDB database
* Moving:: Moving an InnoDB database to another machine
* InnoDB transaction model:: InnoDB transaction model.
* Implementation:: Implementation of multiversioning
* Table and index:: Table and index structures
* File space management:: File space management and disk i/o
* Error handling:: Error handling
* InnoDB restrictions:: Restrictions on InnoDB tables
* InnoDB contact information:: InnoDB contact information.
* InnoDB overview:: InnoDB Tables Overview
* InnoDB start:: InnoDB Startup Options
* InnoDB init:: Creating InnoDB Tablespace
* Using InnoDB tables:: Creating InnoDB Tables
* Adding and removing:: Adding and Removing InnoDB Data and Log Files
* Backing up:: Backing up and Recovering an InnoDB Database
* Moving:: Moving an InnoDB Database to Another Machine
* InnoDB transaction model:: InnoDB Transaction Model.
* Implementation:: Implementation of Multiversioning
* Table and index:: Table and Index Structures
* File space management:: File Space Management and Disk i/o
* Error handling:: Error Handling
* InnoDB restrictions:: Restrictions on InnoDB Tables
* InnoDB contact information:: InnoDB Contact Information.
@end menu
@node InnoDB overview, InnoDB start, InnoDB, InnoDB
@subsection InnoDB tables overview
@subsection InnoDB Tables Overview
InnoDB provides MySQL with a transaction-safe table handler with
commit, rollback, and crash recovery capabilities. InnoDB does
locking on row level and also provides an Oracle-style
consistent
non-locking read in @code{SELECT}s. These features increase
multiuser concurrency and performance. There is no need for
lock escalation in InnoDB,
because row level locks in InnoDB fit in very small space.
InnoDB tables support @code{FOREIGN KEY} constraints
as the first table type in MySQL.
InnoDB has been designed for maximum performance
when processing
large data volumes. Its CPU efficiency is probably not
matched by any other disk-based relational database engine.
Technically, InnoDB is a complete database backend placed under MySQL.
InnoDB has its own buffer pool for caching data and indexes in main
memory. InnoDB stores its tables and indexes in a tablespace, which
may consist of several files. This is different from, for example,
MyISAM tables where each table is stored as a separate file.
InnoDB tables can be of any size also on those operating
systems where file size is limited to 2 GB.
You can find the latest information about InnoDB at
@uref{http://www.innodb.com}. The most up-to-date version of the
InnoDB manual is always placed there, and you can also order
commercial licenses and support for InnoDB.
InnoDB is currently (October 2001) used in production at
several large database sites requiring high performance.
The famous Internet news site Slashdot.org runs on
InnoDB. Mytrix, Inc. stores over 1 TB of data in
InnoDB, and another site handles an average
load of 800 inserts/updates per second in InnoDB.
InnoDB tables are included in the MySQL source distribution
starting from 3.23.34a and are activated in the @strong{MySQL -max}
binary.
starting from 3.23.34a and are activated in the MySQL -Max
binary. For Windows the -Max binaries are contained in the
standard distribution.
If you have downloaded a binary version of MySQL that includes
support for InnoDB (mysqld-max), simply follow the instructions for
installing a binary version of MySQL. @xref{Installing binary}.
support for InnoDB, simply follow the instructions of the
MySQL manual
for installing a binary version of MySQL. If you already have
MySQL-3.23 installed, then the simplest way to install
MySQL -Max is to replace the server executable @file{mysqld}
with the corresponding executable in the -Max distribution.
MySQL and MySQL -Max differ only in the server executable.
@xref{Installing binary}.
@xref{mysqld-max, , @code{mysqld-max}}.
To compile MySQL with InnoDB support, download MySQL-3.23.37 or newer
and configure MySQL with the @code{--with-innodb} option.
To compile MySQL with InnoDB support,
download MySQL-3.23.34a or newer version from
@uref{http://www.mysql.com}
and configure MySQL with the
@code{--with-innodb} option. See the
MySQL manual
about installing a MySQL source distribution.
@xref{Installing source}.
@example
......@@ -37496,47 +37544,23 @@ cd /path/to/source/of/mysql-3.23.37
./configure --with-innodb
@end example
To get InnoDB to work you have to specify where the data for InnoDB
tables should be stored by specifying the @code{innodb_data_file_path}
option on the command line or in an MySQL option file. @xref{InnoDB
start}. If you have configured MySQL for InnoDB but you have not
specified the above option, @code{mysqld} will print at start:
To use InnoDB you have to specify InnoDB startup options in
your @file{my.cnf} or @file{my.ini} file. The minimal way
to modify it is to add to the @code{[mysqld]} section the line
@example
Can't initialize InnoDB as 'innodb_data_file_path' is not set
innodb_data_file_path=ibdata:30M
@end example
InnoDB provides MySQL with a transaction-safe table handler with
commit, rollback, and crash recovery capabilities. InnoDB does
locking on row level, and also provides an Oracle-style consistent
non-locking read in @code{SELECT}s, which increases transaction
concurrency. There is not need for lock escalation in InnoDB,
because row level locks in InnoDB fit in very small space.
InnoDB has been designed for maximum performance when processing
large data volumes. Its CPU efficiency is probably not
matched by any other disk-based relational database engine.
You can find the latest information about InnoDB at
@uref{http://www.innodb.com}. The most up-to-date version of the
InnoDB manual is always placed there, and you can also order commercial
support for InnoDB.
Technically, InnoDB is a database backend placed under MySQL. InnoDB
has its own buffer pool for caching data and indexes in main
memory. InnoDB stores its tables and indexes in a tablespace, which
may consist of several files. This is different from, for example,
@code{MyISAM} tables where each table is stored as a separate file.
but to get good performance it is best that you specify options
like recommended below in the section 'InnoDB startup options'.
InnoDB is distributed under the GNU GPL License Version 2 (of June 1991).
In the source distribution of MySQL, InnoDB appears as a subdirectory.
@node InnoDB start, InnoDB init, InnoDB overview, InnoDB
@subsection InnoDB startup options
Beginning from MySQL-3.23.37 the prefix of the options is changed
from @code{innobase_...} to @code{innodb_...}.
@subsection InnoDB Startup Options
To use InnoDB tables you @strong{MUST} specify configuration parameters
in the MySQL configuration file in the @code{[mysqld]} section of
......@@ -37550,6 +37574,10 @@ hard disk. Below is an example of possible configuration parameters in
@file{my.cnf} for InnoDB:
@example
[mysqld]
# You can write your other MySQL server options here
# ...
#
innodb_data_file_path = ibdata1:2000M;ibdata2:2000M
innodb_data_home_dir = c:\ibdata
set-variable = innodb_mirrored_log_groups=1
......@@ -37558,19 +37586,34 @@ set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=30M
set-variable = innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
#.._arch_dir must be the same as .._log_group_home_dir
innodb_log_arch_dir = c:\iblogs
innodb_log_archive=0
set-variable = innodb_buffer_pool_size=80M
set-variable = innodb_buffer_pool_size=70M
set-variable = innodb_additional_mem_pool_size=10M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50
@end example
Note that data files must be < 4G, and < 2G on
some file systems! The total size of data files has
Note that some operating systems
restrict file size to < 2G.
The total size of data files has
to be >= 10 MB.
InnoDB does not create directories:
you have to create them yourself.
Check that the MySQL server
has the rights to create files in the directories you specify.
When you the first time create an InnoDB database, it
is best that you start the MySQL server from the command
prompt. Then InnoDB will print the information about the
database creation to the screen, and you see what is
happening. See below in section 3 what the printout
should look like.
For example, in Windows you can start @file{mysqld-max.exe} with:
@example
your-path-to-mysqld>mysqld-max --standalone --console
@end example
Suppose you have a Linux machine with 512 MB RAM and
three 20 GB hard disks (at directory paths @file{/},
......@@ -37579,6 +37622,10 @@ Below is an example of possible configuration parameters in @file{my.cnf} for
InnoDB:
@example
[mysqld]
# You can write your other MySQL server options here
# ...
#
innodb_data_file_path = ibdata/ibdata1:2000M;dr2/ibdata/ibdata2:2000M
innodb_data_home_dir = /
set-variable = innodb_mirrored_log_groups=1
......@@ -37587,9 +37634,10 @@ set-variable = innodb_log_files_in_group=3
set-variable = innodb_log_file_size=50M
set-variable = innodb_log_buffer_size=8M
innodb_flush_log_at_trx_commit=1
#.._arch_dir must be the same as .._log_group_home_dir
innodb_log_arch_dir = /dr3/iblogs
innodb_log_archive=0
set-variable = innodb_buffer_pool_size=400M
set-variable = innodb_buffer_pool_size=350M
set-variable = innodb_additional_mem_pool_size=20M
set-variable = innodb_file_io_threads=4
set-variable = innodb_lock_wait_timeout=50
......@@ -37615,9 +37663,12 @@ The common part of the directory path for all InnoDB data files.
Paths to individual data files and their sizes. The full directory path
to each data file is acquired by concatenating innodb_data_home_dir to
the paths specified here. The file sizes are specified in megabytes,
hence the 'M' after the size specification above. Do not set a file size
bigger than 4000M, and on most operating systems not bigger than 2000M.
hence the 'M' after the size specification above.
InnoDB also understands the abbreviation 'G', 1G meaning 1024M.
Starting from
3.23.44 you can set the file size bigger than 4 GB on those
operating systems which support big files.
On some operating systems files must be < 2 GB.
The sum of the sizes of the files must be at least 10 MB.
@item @code{innodb_mirrored_log_groups} @tab
Number of identical copies of log groups we
......@@ -37632,7 +37683,8 @@ Size of each log file in a log group in megabytes. Sensible values range
from 1M to the size of the buffer pool specified below. The bigger the
value, the less checkpoint flush activity is needed in the buffer pool,
saving disk i/o. But bigger log files also mean that recovery will be
slower in case of a crash. File size restriction as for a data file.
slower in case of a crash. The combined size of log files must
be < 4 GB on 32-bit computers.
@item @code{innodb_log_buffer_size} @tab
The size of the buffer which InnoDB uses to write log to the log files
on disk. Sensible values range from 1M to half the combined size of log
......@@ -37657,7 +37709,7 @@ archive InnoDB log files.
The size of the memory buffer InnoDB uses to cache data and indexes of
its tables. The bigger you set this the less disk i/o is needed to
access data in tables. On a dedicated database server you may set this
parameter up to 90 % of the machine physical memory size. Do not set it
parameter up to 80 % of the machine physical memory size. Do not set it
too large, though, because competition of the physical memory may cause
paging in the operating system.
@item @code{innodb_additional_mem_pool_size} @tab
......@@ -37669,7 +37721,7 @@ will start to allocate memory from the operating system, and write
warning messages to the MySQL error log.
@item @code{innodb_file_io_threads} @tab
Number of file i/o threads in InnoDB. Normally, this should be 4, but
on Windows NT disk i/o may benefit from a larger number.
on Windows disk i/o may benefit from a larger number.
@item @code{innodb_lock_wait_timeout} @tab
Timeout in seconds an InnoDB transaction may wait for a lock before
being rolled back. InnoDB automatically detects transaction deadlocks
......@@ -37686,7 +37738,7 @@ Another option is @code{O_DSYNC}.
@node InnoDB init, Using InnoDB tables, InnoDB start, InnoDB
@subsection Creating InnoDB table space
@subsection Creating InnoDB Tablespace
Suppose you have installed MySQL and have edited @file{my.cnf} so that
it contains the necessary InnoDB configuration parameters.
......@@ -37752,7 +37804,7 @@ mysqld: ready for connections
@node Error creating InnoDB, , InnoDB init, InnoDB init
@subsubsection If something goes wrong in database creation
@subsubsection If Something Goes Wrong in Database Creation
If something goes wrong in an InnoDB database creation, you should
delete all files created by InnoDB. This means all data files, all log
......@@ -37763,7 +37815,7 @@ directories. Then you can try the InnoDB database creation again.
@node Using InnoDB tables, Adding and removing, InnoDB init, InnoDB
@subsection Creating InnoDB tables
@subsection Creating InnoDB Tables
Suppose you have started the MySQL client with the command
@code{mysql test}.
......@@ -37797,15 +37849,7 @@ Note that the statistics @code{SHOW} gives about InnoDB tables
are only approximate: they are used in SQL optimisation. Table and
index reserved sizes in bytes are accurate, though.
NOTE: @code{DROP DATABASE} does not currently work for InnoDB tables!
You must drop the tables individually. Also take care not to delete or
add @file{.frm} files to your InnoDB database manually: use
@code{CREATE TABLE} and @code{DROP TABLE} commands.
InnoDB has its own internal data dictionary, and you will get problems
if the MySQL @file{.frm} files are out of 'sync' with the InnoDB
internal data dictionary.
@subsubsection Converting MyISAM tables to InnoDB
@subsubsection Converting MyISAM Tables to InnoDB
InnoDB does not have a special optimisation for separate index creation.
Therefore it does not pay to export and import the table and create indexes
......@@ -37845,9 +37889,55 @@ it is better that you kill the database process and delete all InnoDB data
and log files and all InnoDB table @file{.frm} files, and start
your job again, rather than wait for millions of disk i/os to complete.
@subsubsection Foreign Key Constraints
InnoDB version 3.23.44 features foreign key constraints. InnoDB is the
first MySQL table type which allows you to define foreign key
constraints to guard the integrity of your data.
An example:
@example
CREATE TABLE parent(id INT NOT NULL, PRIMARY KEY (id)) TYPE=INNODB;
CREATE TABLE child(id INT, parent_id INT, INDEX par_ind (parent_id),
FOREIGN KEY (parent_id) REFERENCES parent(id)) TYPE=INNODB;
@end example
Both tables have to be InnoDB type and there must be an index
where the foreign key and the referenced key are listed as the first
columns. Any @code{ALTER TABLE} currently removes all foreign key
constrainst defined for the table, but not the constraints
that reference the table. Corresponding columns in the foreign key
and the referenced key have to have similar internal data types
inside InnoDB so that they can be compared without a type
conversion. The length of string types need not be the same.
The size and the signedness of integer types has to be same.
When doing foreign key checks InnoDB sets shared row
level locks on child or parent records it has to look at.
InnoDB allows you to drop any table even though that
would break the foreign key constraints which reference
the table. When you drop a table the constraints which
were defined in its create statement are also dropped.
If you recreate a table which was dropped, it has to have
a definition which conforms to the foreign key constraints
referencing it. It must have the right column names and types,
and it must have indexes on the referenced keys, as stated above.
You can list the foreign key constraints for a table
@code{T} with
@example
SHOW TABLE STATUS FROM yourdatabasename LIKE 'T';
@end example
The foreign key constraints are listed in the table comment of
the output.
InnoDB does not yet support @code{CASCADE ON DELETE}
or other special options on the constraints.
@node Adding and removing, Backing up, Using InnoDB tables, InnoDB
@subsection Adding and removing InnoDB data and log files
@subsection Adding and Removing InnoDB Data and Log Files
You cannot increase the size of an InnoDB data file. To add more into
your tablespace you have to add a new data file. To do this you have to
......@@ -37856,7 +37946,7 @@ new file to @code{innodb_data_file_path}, and then start MySQL
again.
Currently you cannot remove a data file from InnoDB. To decrease the
size of your database you have to use @code{mysqldump} to dump
size of your database you have to use @file{mysqldump} to dump
all your tables, create a new database, and import your tables to the
new database.
......@@ -37870,7 +37960,7 @@ you at the startup that it is creating new log files.
@node Backing up, Moving, Adding and removing, InnoDB
@subsection Backing up and recovering an InnoDB database
@subsection Backing up and Recovering an InnoDB Database
The key to safe database management is taking regular backups.
To take a 'binary' backup of your database you have to do the following:
......@@ -37989,7 +38079,7 @@ because there will be more log to apply to the database.
@node Moving, InnoDB transaction model, Backing up, InnoDB
@subsection Moving an InnoDB database to another machine
@subsection Moving an InnoDB Database to Another Machine
InnoDB data and log files are binary-compatible on all platforms
if the floating point number format on the machines is the same.
......@@ -38010,10 +38100,10 @@ a table.
@node InnoDB transaction model, Implementation, Moving, InnoDB
@subsection InnoDB transaction model
@subsection InnoDB Transaction Model
In the InnoDB transaction model the goal has been to combine the best
sides of a multiversioning database to traditional two-phase locking.
properties of a multiversioning database to traditional two-phase locking.
InnoDB does locking on row level and runs queries by default
as non-locking consistent reads, in the style of Oracle.
The lock table in InnoDB is stored so space-efficiently that lock
......@@ -38022,7 +38112,7 @@ to lock every row in the database, or any random subset of the rows,
without InnoDB running out of memory.
In InnoDB all user activity happens inside transactions. If the
auto commit mode is used in MySQL, then each SQL statement
auto-commit mode is used in MySQL, then each SQL statement
will form a single transaction. If the auto commit mode is
switched off, then we can think that a user always has a transaction
open. If he issues
......@@ -38036,17 +38126,17 @@ on the other hand cancels all modifications made by the current
transaction.
@menu
* InnoDB consistent read:: Consistent read
* InnoDB locking reads:: Locking reads
* InnoDB Next-key locking:: Next-key locking: avoiding the phantom problem
* InnoDB Locks set:: Locks set by different SQL statements in InnoDB
* InnoDB Deadlock detection:: Deadlock detection and rollback
* InnoDB Consistent read example:: An example of how the consistent read works in InnoDB
* InnoDB consistent read:: Consistent Read
* InnoDB locking reads:: Locking Reads
* InnoDB Next-key locking:: Next-key Locking: Avoiding the Phantom Problem
* InnoDB Locks set:: Locks Set by Different SQL Statements in InnoDB
* InnoDB Deadlock detection:: Deadlock Detection and Rollback
* InnoDB Consistent read example:: An Example of How the Consistent Read Works in InnoDB
@end menu
@node InnoDB consistent read, InnoDB locking reads, InnoDB transaction model, InnoDB transaction model
@subsubsection Consistent read
@subsubsection Consistent Read
A consistent read means that InnoDB uses its multiversioning to
present to a query a snapshot of the database at a point in time.
......@@ -38072,7 +38162,7 @@ on the table.
@node InnoDB locking reads, InnoDB Next-key locking, InnoDB consistent read, InnoDB transaction model
@subsubsection Locking reads
@subsubsection Locking Reads
A consistent read is not convenient in some circumstances.
Suppose you want to add a new row into your table @code{CHILD},
......@@ -38130,7 +38220,7 @@ on the rows.
@node InnoDB Next-key locking, InnoDB Locks set, InnoDB locking reads, InnoDB transaction model
@subsubsection Next-key locking: avoiding the phantom problem
@subsubsection Next-key Locking: Avoiding the Phantom Problem
In row level locking InnoDB uses an algorithm called next-key locking.
InnoDB does the row level locking so that when it searches or
......@@ -38174,7 +38264,7 @@ after the last record in the index. Just that happens in the previous
example: the locks set by InnoDB will prevent any insert to
the table where @code{ID} would be bigger than 100.
You can use the next-key locking to implement a uniqueness
You can use next-key locking to implement a uniqueness
check in your application: if you read your data in share mode
and do not see a duplicate for a row you are going to insert,
then you can safely insert your row and know that the next-key
......@@ -38183,9 +38273,8 @@ anyone meanwhile inserting a duplicate for your row. Thus the next-key
locking allows you to 'lock' the non-existence of something in your
table.
@node InnoDB Locks set, InnoDB Deadlock detection, InnoDB Next-key locking, InnoDB transaction model
@subsubsection Locks set by different SQL statements in InnoDB
@subsubsection Locks Set by Different SQL Statements in InnoDB
@itemize @bullet
@item
......@@ -38226,6 +38315,12 @@ lock on every record the search encounters.
@code{DELETE FROM ... WHERE ...} : sets an exclusive next-key
lock on every record the search encounters.
@item
If a @code{FOREIGN KEY} constraint is defined on a table,
any insert, update, or delete which requires checking of the constraint
condition sets shared record level locks on the records it
looks at to check the constraint. Also in the case where the
constraint fails, InnoDB sets these locks.
@item
@code{LOCK TABLES ... } : sets table locks. In the implementation
the MySQL layer of code sets these locks. The automatic deadlock detection
of InnoDB cannot detect deadlocks where such table locks are involved:
......@@ -38238,7 +38333,7 @@ locks. But that does not put transaction integerity into danger.
@node InnoDB Deadlock detection, InnoDB Consistent read example, InnoDB Locks set, InnoDB transaction model
@subsubsection Deadlock detection and rollback
@subsubsection Deadlock Detection and Rollback
InnoDB automatically detects a deadlock of transactions and rolls
back the transaction whose lock request was the last one to build
......@@ -38257,7 +38352,7 @@ stores row locks in a format where it cannot afterwards know which was
set by which SQL statement.
@node InnoDB Consistent read example, , InnoDB Deadlock detection, InnoDB transaction model
@subsubsection An example of how the consistent read works in InnoDB
@subsubsection An Example of How the Consistent Read Works in InnoDB
When you issue a consistent read, that is, an ordinary @code{SELECT}
statement, InnoDB will give your transaction a timepoint according
......@@ -38289,9 +38384,9 @@ v SELECT * FROM t;
COMMIT;
SELECT * FROM t;
----------------------
| 1 | 2 |
----------------------
---------------------
| 1 | 2 |
---------------------
@end example
Thus user A sees the row inserted by B only when B has committed the
......@@ -38306,7 +38401,7 @@ SELECT * FROM t LOCK IN SHARE MODE;
@end example
@subsection Performance tuning tips
@subsection Performance Tuning Tips
@strong{1.}
If the Unix @file{top} or the Windows @file{Task Manager} shows that
......@@ -38398,15 +38493,24 @@ This tip is of course valid for inserts into any table type, not just InnoDB.
Starting from version 3.23.41 InnoDB includes the InnoDB
Monitor which prints information on the InnoDB internal state.
When swithed on, InnoDB Monitor
will make the MySQL server to print data to the standard
output about once every 10 seconds. This data is useful in
will make the MySQL server @file{mysqld} to print data
(note: the MySQL client will not print anything)
to the standard
output about once every 15 seconds. This data is useful in
performance tuning.
On Windows you must start @code{mysqld-max}
from a MS-DOS prompt
with the @code{--standalone --console}
options to direct the output to the MS-DOS prompt
window.
There is a separate @code{innodb_lock_monitor} which
prints the same information as @code{innodb_monitor}
plus information on locks set by each transaction.
The printed information includes data on:
@itemize @bullet
@item
table and record locks held by each active transaction,
@item
lock waits of a transactions,
@item
semaphore waits of threads,
......@@ -38519,8 +38623,8 @@ may have lock contention. The output can also help to
trace reasons for transaction deadlocks.
@item
Section SYNC INFO will report reserved semaphores
if you compile InnoDB with <code>UNIV_SYNC_DEBUG</code>
defined in <tt>univ.i</tt>.
if you compile InnoDB with @code{UNIV_SYNC_DEBUG}
defined in @file{univ.i}.
@item
Section SYNC ARRAY INFO reports threads waiting
for a semaphore and statistics on how many times
......@@ -38542,7 +38646,7 @@ currently doing.
@end itemize
@node Implementation, Table and index, InnoDB transaction model, InnoDB
@subsection Implementation of multiversioning
@subsection Implementation of Multiversioning
Since InnoDB is a multiversioned database, it must keep information
of old versions of rows in the tablespace. This information is stored
......@@ -38573,7 +38677,9 @@ a snapshot that in a consistent read could need the information
in the update undo log to build an earlier version of a database
row.
You must remember to commit your transactions regularly. Otherwise
You must remember to commit your transactions regularly,
also those transactions which only issue consistent reads.
Otherwise
InnoDB cannot discard data from the update undo logs, and the
rollback segment may grow too big, filling up your tablespace.
......@@ -38592,7 +38698,19 @@ time as the SQL statement which did the deletion.
@node Table and index, File space management, Implementation, InnoDB
@subsection Table and index structures
@subsection Table and Index Structures
MySQL stores its data dictionary information of tables
in @file{.frm}
files in database directories. But every InnoDB type table
also has its own entry in InnoDB internal data dictionaries
inside the tablespace. When MySQL drops a table or a database,
it has to delete both a @file{.frm} file or files, and
the corresponding entries inside the InnoDB data dictionary.
This is the reason why you cannot move InnoDB tables between
databases simply by moving the @file{.frm} files, and why
@code{DROP DATABASE} did not work for InnoDB type tables
in MySQL versions <= 3.23.43.
Every InnoDB table has a special index called the clustered index
where the data of the rows is stored. If you define a
......@@ -38620,15 +38738,15 @@ index. Note that if the primary key is long, the secondary indexes
will use more space.
@menu
* InnoDB physical structure:: Physical structure of an index
* InnoDB Insert buffering:: Insert buffering
* InnoDB Adaptive hash:: Adaptive hash indexes
* InnoDB Physical record:: Physical record structure
* InnoDB physical structure:: Physical Structure of an Index
* InnoDB Insert buffering:: Insert Buffering
* InnoDB Adaptive hash:: Adaptive Hash Indexes
* InnoDB Physical record:: Physical Record Structure
@end menu
@node InnoDB physical structure, InnoDB Insert buffering, Table and index, Table and index
@subsubsection Physical structure of an index
@subsubsection Physical Structure of an Index
All indexes in InnoDB are B-trees where the index records are
stored in the leaf pages of the tree. The default size of an index
......@@ -38644,7 +38762,7 @@ InnoDB will try to contract the index tree to free the page.
@node InnoDB Insert buffering, InnoDB Adaptive hash, InnoDB physical structure, Table and index
@subsubsection Insert buffering
@subsubsection Insert Buffering
It is a common situation in a database application that the
primary key is a unique identifier and new rows are inserted in the
......@@ -38672,7 +38790,7 @@ to a table up to 15 times.
@node InnoDB Adaptive hash, InnoDB Physical record, InnoDB Insert buffering, Table and index
@subsubsection Adaptive hash indexes
@subsubsection Adaptive Hash Indexes
If a database fits almost entirely in main memory, then the fastest way
to perform queries on it is to use hash indexes. InnoDB has an
......@@ -38696,7 +38814,7 @@ databases.
@node InnoDB Physical record, , InnoDB Adaptive hash, Table and index
@subsubsection Physical record structure
@subsubsection Physical Record Structure
@itemize @bullet
@item
......@@ -38719,7 +38837,7 @@ If the total length of the fields in a record is < 128 bytes, then
the pointer is 1 byte, else 2 bytes.
@end itemize
@subsubsection How an auto-increment column works in InnoDB
@subsubsection How an Auto-increment Column Works in InnoDB
After a database startup, when a user first does an insert to a
table @code{T}
......@@ -38728,16 +38846,16 @@ an explicit value for the column, then InnoDB executes @code{SELECT
MAX(auto-inc-column) FROM T}, and assigns that value incremented
by one to the the column and the auto-increment counter of the table.
We say that
the auto-increment counter for table @code{T} has been initialised.
the auto-increment counter for table @code{T} has been initialized.
InnoDB follows the same procedure in initialising the auto-increment counter
InnoDB follows the same procedure in initializing the auto-increment counter
for a freshly created table.
Note that if the user specifies in an insert the value 0 to the auto-increment
column, then InnoDB treats the row like the value would not have been
specified.
After the auto-increment counter has been initialised, if a user inserts
After the auto-increment counter has been initialized, if a user inserts
a row where he explicitly specifies the column value, and the value is bigger
than the current counter value, then the counter is set to the specified
column value. If the user does not explicitly specify a value, then InnoDB
......@@ -38754,12 +38872,12 @@ integer that can be stored in the specified integer type.
@node File space management, Error handling, Table and index, InnoDB
@subsection File space management and disk i/o
@subsection File Space Management and Disk i/o
@menu
* InnoDB Disk i/o:: Disk i/o
* InnoDB File space:: File space management
* InnoDB File Defragmenting:: Defragmenting a table
* InnoDB File space:: File Space Management
* InnoDB File Defragmenting:: Defragmenting a Table
@end menu
......@@ -38802,7 +38920,7 @@ file size in @code{innodb_data_file_path}. The partition must be
1000 000 bytes.
@example
innodb_data_file_path=hdd1:3Gnewraw;hdd2:2Gnewraw
innodb_data_file_path=hdd1:5Gnewraw;hdd2:2Gnewraw
@end example
When you start the database again you MUST change the keyword
......@@ -38810,10 +38928,10 @@ to @code{raw}. Otherwise InnoDB will write over your
partition!
@example
innodb_data_file_path=hdd1:3Graw;hdd2:2Graw
innodb_data_file_path=hdd1:5Graw;hdd2:2Graw
@end example
Using a raw disk you can on some Unixes perform non-buffered i/o.
By using a raw disk you can on some Unixes perform unbuffered i/o.
There are two read-ahead heuristics in InnoDB: sequential read-ahead
and random read-ahead. In sequential read-ahead InnoDB notices that
......@@ -38826,7 +38944,7 @@ reads to the i/o system.
@node InnoDB File space, InnoDB File Defragmenting, InnoDB Disk i/o, File space management
@subsubsection File space management
@subsubsection File Space Management
The data files you define in the configuration file form the tablespace
of InnoDB. The files are simply catenated to form the tablespace,
......@@ -38874,7 +38992,7 @@ consistent read.
@node InnoDB File Defragmenting, , InnoDB File space, File space management
@subsubsection Defragmenting a table
@subsubsection Defragmenting a Table
If there are random insertions or deletions
in the indexes of a table, the indexes
......@@ -38898,13 +39016,13 @@ not occur.
@node Error handling, InnoDB restrictions, File space management, InnoDB
@subsection Error handling
@subsection Error Handling
The error handling in InnoDB is not always the same as
specified in the ANSI SQL standards. According to the ANSI
standard, any error during an SQL statement should cause the
rollback of that statement. InnoDB sometimes rolls back only
part of the statement.
part of the statement, or the whole transaction.
The following list specifies the error handling of InnoDB.
@itemize @bullet
......@@ -38913,9 +39031,9 @@ If you run out of file space in the tablespace,
you will get the MySQL @code{'Table is full'} error
and InnoDB rolls back the SQL statement.
@item
A transaction deadlock or a timeout in a lock wait will give
@code{'Table handler error 1000000'} and InnoDB rolls back
the SQL statement.
A transaction deadlock or a timeout in a lock wait make InnoDB
to roll back
the whole transaction.
@item
A duplicate key error only rolls back the insert of that particular row,
even in a statement like @code{INSERT INTO ... SELECT ...}.
......@@ -38931,7 +39049,7 @@ they roll back the corresponding SQL statement.
@node InnoDB restrictions, InnoDB contact information, Error handling, InnoDB
@subsection Restrictions on InnoDB tables
@subsection Restrictions on InnoDB Tables
@itemize @bullet
......@@ -38947,7 +39065,7 @@ error:
CREATE TABLE T (A CHAR(20), B INT, UNIQUE (A(5))) TYPE = InnoDB;
@end example
If you create a non unique index on a prefix of a column, InnoDB will
If you create a non-unique index on a prefix of a column, InnoDB will
create an index over the whole column.
@item
@code{INSERT DELAYED} is not supported for InnoDB tables.
......@@ -38971,23 +39089,19 @@ A table cannot contain more than 1000 columns.
deletes all rows, one by one, which is not that fast. In future versions
of MySQL you can use @code{TRUNCATE} which is fast.
@item
Before dropping a database with InnoDB tables one has to drop
the individual InnoDB tables first.
@item
The default database page size in InnoDB is 16 kB. By recompiling the
code one can set it from 8 kB to 64 kB.
The maximun row length is slightly less than half of a database page
in versions <= 3.23.40 of InnoDB. Starting from source
release 3.23.41 BLOB and
TEXT columns are allowed to be < 4 GB, the total row length must also be
< 4 GB. InnoDB does not store fields whose size is <= 30 bytes on separate
< 4 GB. InnoDB does not store fields whose size is <= 128 bytes on separate
pages. After InnoDB has modified the row by storing long fields on
separate pages, the remaining length of the row must be slightly less
than half a database page.
separate pages, the remaining length of the row must be less
than half a database page. The maximun key length is 7000 bytes.
@item
The maximum data or log file size is 2 GB or 4 GB depending on how large
files your operating system supports. Support for > 4 GB files will
be added to InnoDB in a future version.
On some operating systems data files must be < 2 GB. The combined
size of log files must be < 4 GB on 32-bit computers.
@item
The maximum tablespace size is 4 billion database pages. This is also
the maximum size for a table. The minimum tablespace size is 10 MB.
......@@ -38995,7 +39109,7 @@ the maximum size for a table. The minimum tablespace size is 10 MB.
@node InnoDB contact information, , InnoDB restrictions, InnoDB
@subsection InnoDB contact information
@subsection InnoDB Contact Information
Contact information of Innobase Oy, producer of the InnoDB engine.
Website: @uref{http://www.innodb.com}. Email:
Markdown is supported
0% or
You are about to add 0 people to the discussion. Proceed with caution.
Finish editing this message first!
Please register or to comment
GitLab Nexedi Edition | About GitLab | About Nexedi | 沪ICP备2021021310号-2 | 沪ICP备2021021310号-7