Everybody knows that parsing the output of SHOW ENGINE INNODB STATUS is hard, especially when you want to track the information historically, or want to aggregate any of the more dynamic sections such as the TRANSACTIONS one.
Within the InnoDB plugin the INFORMATION_SCHEMA.INNODB_TRX table was added, which allowed you to at least get some of the information on each transaction, but not the full breadth of information that SHOW ENGINE INNODB STATUS provided.
“This is nice..” I thought “..but why not go the whole hog..?”.. And so I set about doing that, and opened up Bug#53336. In a very short time, I was in a review process with the InnoDB team, the patch was cleaned up, and (after a little hiccup) everything has been pushed for the next milestone.
Here’s the docs notes that I wrote for it today (with a little more annotation):
This patch adds the following columns:
mysql> DESC innodb_trx; +----------------------------+---------------------+------+-----+---------------------+-------+ | FIELD | Type | NULL | KEY | DEFAULT | Extra | +----------------------------+---------------------+------+-----+---------------------+-------+ ... | trx_operation_state | varchar(64) | YES | | NULL | | | trx_tables_in_use | bigint(21) UNSIGNED | NO | | 0 | | | trx_tables_locked | bigint(21) UNSIGNED | NO | | 0 | | | trx_lock_structs | bigint(21) UNSIGNED | NO | | 0 | | | trx_lock_memory_bytes | bigint(21) UNSIGNED | NO | | 0 | | | trx_rows_locked | bigint(21) UNSIGNED | NO | | 0 | | | trx_rows_modified | bigint(21) UNSIGNED | NO | | 0 | | | trx_concurrency_tickets | bigint(21) UNSIGNED | NO | | 0 | | | trx_isolation_level | varchar(16) | NO | | | | | trx_unique_checks | int(1) | NO | | 0 | | | trx_foreign_key_checks | int(1) | NO | | 0 | | | trx_last_foreign_key_error | varchar(256) | YES | | NULL | | | trx_adaptive_hash_latched | int(1) | NO | | 0 | | | trx_adaptive_hash_timeout | bigint(21) UNSIGNED | NO | | 0 | | +----------------------------+---------------------+------+-----+---------------------+-------+ 22 rows IN SET (0.05 sec)
Most of these are self explanatory, a lot of them duplicate the information within SHOW ENGINE INNODB STATUS (so you now no longer need to parse the output of that to get complete transaction information).
Below are some of my notes. For comparison, here’s an example of a transaction from the SHOW ENGINE INNODB STATUS statement:
---TRANSACTION 517, ACTIVE 1 sec, OS thread id 2958520320 inserting mysql TABLES IN USE 2, locked 2 189 LOCK struct(s), heap size 27968, 54389 row LOCK(s), undo log entries 2406 MySQL thread id 2, query id 36 localhost root Sending DATA INSERT IGNORE INTO t1 (SELECT (i * rand())*100, 1 FROM t1)
trx_operation_state - corresponds to “inserting”, InnoDB’s internal transaction state
trx_tables_in_use - corresponds to “mysql tables in use 2″, the number of table locks requested by MySQL via external_lock()
trx_tables_locked - corresponds to “locked 2″, the number of actual table locks taken via external_lock()
trx_lock_structs - corresponds to “189 lock struct(s)”, the size of the lock struct list
trx_lock_memory_bytes - corresponds to “heap size 27968″, the number of bytes allocated to locks structs
trx_rows_locked - corresponds to “54389 row lock(s)”, an estimation of the number of rows locked (delete marked rows may make it imprecise)
trx_rows_modified - corresponds to “undo log entries 2406″, the number of rows modified in the transaction (inserted, updated, deleted)
Not seen in the transaction output above:
trx_concurrency_tickets - corresponds to “thread declared inside InnoDB 89″ for a transaction in SHOW ENGINE INNODB STATUS, the number of concurrency tickets remaining for the transaction when innodb_thread_concurrency != 0
trx_isolation_level - the transactions isolation level
trx_unique_checks - whether the transaction has “SET UNIQUE_CHECKS = 0″
trx_foreign_key_checks - whether the transaction has “SET FOREIGN_KEY_CHECKS = 0″
trx_last_foreign_key_error - if the last statement in the transaction resulted in an FK error, the error text is printed here
trx_adaptive_hash_latched - corresponds to “holds adaptive hash latch” being printed for a transaction in SHOW ENGINE INNODB STATUS
trx_adaptive_hash_timeout - when innodb_adapative_hash_index is enabled (default), statements that try to get the adapative hash latch spin 10000 (BTR_SEA_TIMEOUT) times, re-trying getting the adaptive hash latch, before giving up. lower numbers here for a lot of transactions may indicate contention on the adaptive hash latch
In summary - no more having to parse SHOW ENGINE INNODB STATUS output for transaction information, now you can just do it with SQL (with all it’s aggregation goodness as well if you want to)!
PlanetMySQL Voting: Vote UP / Vote DOWN