trx_id: 175661214788
trx_state: LOCK WAIT
trx_started: 2023-11-02 16:45:59
trx_requested_lock_id: 175661214788:179813:264:120
trx_wait_started: 2023-11-02 16:45:59
trx_weight: 2
trx_mysql_thread_id: 909105
trx_query: UPDATE b_catalog_price SET PRODUCT_ID = 1002764, CATALOG_GROUP_ID = 1, CURRENCY = 'RUB', QUANTITY_FROM = NULL, QUANTITY_TO = NULL, PRICE = '257', `EXT
trx_operation_state: starting index read
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 1128
trx_rows_locked: 1
trx_rows_modified: 0
trx_concurrency_tickets: 0
trx_isolation_level: READ COMMITTED
trx_unique_checks: 1
trx_foreign_key_checks: 1
trx_last_foreign_key_error: NULL
trx_is_read_only: 0
trx_autocommit_non_locking: 0
*************************** 74. row ***************************
trx_id: 175660762324
trx_state: RUNNING
trx_started: 2023-11-02 16:35:28
trx_requested_lock_id: NULL
trx_wait_started: NULL
trx_weight: 3
trx_mysql_thread_id: 905559
trx_query: UPDATE b_catalog_price SET PRODUCT_ID = 1002764, CATALOG_GROUP_ID = 1, CURRENCY = 'RUB', QUANTITY_FROM = NULL, QUANTITY_TO = NULL, PRICE = '257', `EXT
trx_operation_state: updating or deleting
trx_tables_in_use: 1
trx_tables_locked: 1
trx_lock_structs: 2
trx_lock_memory_bytes: 1128
trx_rows_locked: 1
Если смотреть по времени исполнения, то видна разница в 10 минут. Неужели за 10 минут не смог выполниться запрос на обновление элемента с указанным первичным ключом и перестроиться индекс?? Такая проблема возникает спонтанно с периличностью раз-два в неделю.
Так это разные транзакции, хоть SQL запрос там и одинаковый. Разный транзакшн id разные треды. Времени выполнения там нет, там время старта транзакции. Вы сравниваете два времени начала двух разных транзакций и делаете вывод, что запрос не добежал за 10 минут… Если у вас апдейт «подвисает», возможно это из-за ожидания блокировок. В первом аутпуте как раз транзакция не выполняет апдейт, а ждет блокировку. Как долго она будет ждать, зависит от того, кто эту блокировку держит.
Обсуждают сегодня