49. as much as 7.2x faster than the theoretical rate of inserts in a "normal" DBMS clustered (primary key) index PK values 001 - nnn B-tree leaf nodes, containing data key values A Z B-tree leaf nodes, containing PKs Secondary index key values A Z B-tree leaf nodes, containing PKs Clustered index Secondary index
50.
51. if a user has IX lock on table T, no other user can take S lock on T
52. if a user has an S lock on table T, no other user can take X locks on rows in T ? IS is compatible with S, but not with X. Thus, if a user has row share locks, no other user can lock the table in X mode S LOCKED! S LOCKED! S LOCKED! A B IS lock
53.
54. Statement-Based Replication Relies on No Phantoms MySQL binlog A’s DELETE B’s INSERT 5. The MySQL binlog contain B's transaction before A's We do not know if A deleted the row that B inserted! User B BEGIN; INSERT INTO t VALUES (10); 2. Before A commits, user B inserts the same row slave may get out-of- sync with the master! User A BEGIN; DELETE FROM t WHERE a = 10; 1. User A deletes a row User B BEGIN; INSERT INTO t VALUES (10); COMMIT; 3. User B commits before A User A BEGIN; DELETE FROM t WHERE a = 10; COMMIT; 4. User A commits
55. Row-Based Replication Needs Less Locking MySQL binlog A’s DELETE B’s INSERT 5. The MySQL binlog contain B's transaction before A's Row-based binlog contains information of each individual row that was deleted or inserted => phantoms are no longer a problem! User B BEGIN; INSERT INTO t VALUES (10); 2. Before A commits, user B inserts the same row User A BEGIN; DELETE FROM t WHERE a = 10; 1. User A deletes a row User B BEGIN; INSERT INTO t VALUES (10); COMMIT; 3. User B commits before A User A BEGIN; DELETE FROM t WHERE a = 10; COMMIT; 4. User A commits
56.
57. Types of Gap Locking in InnoDB InnoDB minimizes gap locking by using record-only locks in UNIQUE searches UPDATE t SET a = a + 1 WHERE primary_key_value = 100; Gap lock locks just the gap before the key Record-only lock locks just the key and not the gap Insert-intention gap lock held when waiting to insert into a gap Next-key lock locks the key & the gap before the key
The following 32 pages are allocated individually (from the fragmented extent space); after that, full 64 page extents are allocated Using multiple tablespaces can be beneficial to users who want to move specific tables to separate physical disks or who wish to restore backups of single tables quickly without interrupting the use of the remaining InnoDB tables.
Also overflow page pointers Whether any columns are stored off-page depends on the page size and the total size of the row. When the row is too long to fit entirely within the page of the clustered index, InnoDB will choose the longest columns for off-page storage until the row fits on the clustered index page.
COMPACT mode always stores up to 768-byte prefix of such columns in the clustered index page New DYNAMIC mode stores long columns entirely “off-page”, with only a 20-byte prefix in the clustered index page If row does not fit in clustered index page, some long BLOB or VARCHAR column(s) may be stored on an overflow page the REDUNDANT format is available to retain compatibility with older versions of MySQL
If you do not define a PRIMARY KEY for your table, InnoDB uses the first UNIQUE index that has only NOT NULL columns as the clustered index. If there is no such index in the table, InnoDB internally generates a clustered index where the rows are ordered by the row ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order. All InnoDB indexes are B-trees where the index records are stored in the leaf pages of the tree. The default size of an index page is 16KB. When new records are inserted, InnoDB tries to leave 1/16 of the page free for future insertions and updates of the index records.
If you specify the autoextend option for the last data file, InnoDB extends the data file if it runs out of free space in the tablespace. The increment is 8MB at a time by default. It can be modified by changing the innodb_autoextend_increment system variable. You can use raw disk partitions as data files in the shared tablespace. Remember that only the last data file in the innodb_data_file_path can be specified as auto-extending.
Note : InnoDB always needs the shared tablespace because it puts its internal data dictionary and undo logs there. To support recovery and unique features.
Combination of physical (disk address) and logical (field content) logging -- Physiological Logging Logging is used for durability at crash recovery InnoDB keeps two logs, the redo log and the undo log. The redo log is for re-doing data changes that had not been written to disk when a crash occurred. The undo log is primarily for removing data changes that had been written to disk when a crash occurred, but should not have been written, because they were for uncommitted transactions. The undo log is inside the tablespace. The undo log is primarily for removing data changes that had been written to disk when a crash occurred, but should not have been written, because they were for uncommitted transactions . The undo log is inside the tablespace. The "insert" section of the undo log is needed only for transaction rollback and can be discarded at COMMIT time. The "update/delete" section of the undo log is also useful for consistent reads, and can be discarded when InnoDB has ended all transactions that might need the undo log records to reconstruct earlier versions of rows. An undo log record's contents are: Primary Key Value (not a page number or physical address), Old Transaction ID (of the transaction that updated the row), and the changes (only old values). COMMIT will write the contents of the log buffer to disk, and put undo log records in a history list. ROLLBACK will delete undo log records that are no longer needed. PURGE (an internal operation that occurs outside user control) will no-longer-necessary undo log records and, for data records that have been marked for deletion and are no longer necessary for consistent read, will remove the records.
There is one redo log for the entire workspace, it contains multiple files, it is circular. The file header includes the last successful checkpoint. A redo log record's contents are: Space id, Page Number (4 bytes = page number within tablespace), Offset of change within page (2 bytes), Log Record Type (insert, update, delete, "fill space with blanks", etc.), and the changes on that page ( only after images , not before images).
Primary goal: make it faster! Run-time --- Faster! Foreground threads from MySQL server Memory: log buffer (REDO records), Buffer pool (data pages; index pages; undo records; adaptive hash indexes; table of lock info), and additional memory pool(cached data dictionary; open table handles)
Typically two segments for each index (non-leaf index segment and leaf index segment) One segment for very small indexes only Each secondary index has its own pair of segments