This kind of operation does not adhere to the ACID  principle of database design. It is considered very risky, because the data could be rolled back , or updated further before being committed; then, the transaction doing the dirty read would be using data that was never confirmed as accurate. 

Its opposite is consistent read , where InnoDB  ensures that a transaction does not read information updated by another transaction, even if the other transaction commits in the meantime. See Also ACID, commit, consistent read, isolation level, READ UNCOMMITTED, rollback. 

disk-based 

 A kind of database that primarily organizes data on disk storage (hard drives or equivalent). Data is brought back and forth between disk and memory to be operated upon. It is the opposite of an in-memory database . Although InnoDB  is disk-based, it also contains features such as he buffer pool , multiple buffer pool instances, and the adaptive hash index  that allow certain kinds of workloads to work primarily from memory. See Also adaptive hash index, buffer pool, in-memory database. 

disk-bound 

 A type of workload  where the primary bottleneck  is disk I/O. (Also known as I/O-bound .) Typically involves frequent writes to disk, or random reads of more data than can fit into the buffer pool . See Also bottleneck, buffer pool, workload. 

DML 

 Data manipulation language, a set of SQL  statements for performing INSERT , UPDATE , and DELETE  operations. The SELECT  statement is sometimes considered as a DML statement, because the SELECT ... FOR UPDATE form is subject to the same considerations for locking  as INSERT , UPDATE , and DELETE . 

DML statements for an InnoDB  table operate in the context of a transaction , so their effects can be committed or rolled back  as a single unit. 

Contrast with DDL  and DCL . 

See Also commit, DCL, DDL, locking, rollback, SQL, transaction. 

document id 

 In the InnoDB full-text search  feature, a special column in the table containing the FULLTEXT index , to uniquely identify the document associated with each ilist  value. Its name is FTS_DOC_ID  (uppercase required). The column itself must be of BIGINT UNSIGNED NOT NULL  type, with a unique index named FTS_DOC_ID_INDEX . Preferably, you define this column when creating the table. If InnoDB  must add the column to the table while creating a FULLTEXT  index, the indexing operation is considerably more expensive. See Also full-text search, FULLTEXT index, ilist. 

doublewrite buffer 

InnoDB  uses a file flush technique called doublewrite. Before writing pages  to the data files , InnoDB  first writes them to a storage area called the doublewrite buffer. Only after the write and the flush to the doublewrite buffer have completed, does InnoDB  write the pages to their proper positions in the data file. If there is an operating system, storage subsystem, or mysqld  process crash in the middle of a page write, InnoDB  can later find a good copy of the page from the doublewrite buffer during crash recovery . 

Although data is always written twice, the doublewrite buffer does not require twice as much I/O overhead or twice as many I/O operations. Data is written to the buffer itself as a large sequential chunk, with a single fsync()  call to the operating system. 

To turn off the doublewrite buffer, specify the option innodb_doublewrite=0 . See Also crash recovery, data files, page, purge. 

drop 

 A kind of DDL  operation that removes a schema object, through a statement such as DROP TABLE  or DROP INDEX . It maps internally to an ALTER TABLE  statement. From an InnoDB  perspective, the performance considerations of such operations involve the time that the data dictionary  is locked to ensure that interrelated 

