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 6148