Mysql

MySQL數據庫上的Wordpress UPDATE查詢卡住了

  • January 12, 2022

我有一台 Amazon 24XL 伺服器

  • 96 種顏色
  • 378 GB 記憶體
  • 數據庫大小 5.7G
  • Debian GNU/Linux 9（延伸）
  • PHP 7.3.16
  • mysql Ver 15.1 Distrib 10.3.22-MariaDB

我只有一個使用者閱讀文章的 WordPress 網站，有 4-5 個小外掛 一個外掛用於在我的訂閱者資料中添加積分和獎勵。當我的網站上有大約 2500 個使用者時，大約有 3000 多個更新查詢執行以更新表“wp_custom_points_user”

問題是查詢卡在更新中我找不到解決這些問題的方法但是伺服器有很多 RAM，CPU 可用，但由於同一張表上的查詢它卡住並在我的網站上導致 502。我正在尋找優化 MySQL 來滿足並發更新查詢，因為它們需要更長的時間來響應並且我懷疑有一些鎖。但是我有所有帶有索引和使用 InnoDB 的表

在此處輸入圖像描述

這是 SHOW ENGINE INNODB 狀態；

=====================================
2020-04-06 13:45:46 0x7f934bf24700 INNODB MONITOR OUTPUT
=====================================
Per second averages calculated from the last 27 seconds
-----------------
BACKGROUND THREAD
-----------------
srv_master_thread loops: 8196 srv_active, 0 srv_shutdown, 0 srv_idle
srv_master_thread log flush and writes: 8196
----------
SEMAPHORES
----------
OS WAIT ARRAY INFO: reservation count 15589494
OS WAIT ARRAY INFO: signal count 41500023
RW-shared spins 0, rounds 154525943, OS waits 1459106
RW-excl spins 0, rounds 10328037, OS waits 40587
RW-sx spins 71982, rounds 547220, OS waits 3916
Spin rounds per wait: 154525943.00 RW-shared, 10328037.00 RW-excl, 7.60 RW-sx
------------
TRANSACTIONS
------------
Trx id counter 351880322
Purge done for trx's n:o < 351880319 undo n:o < 0 state: running
History list length 1
... truncated...
mpact format; info bits 0
0: len 4; hex 80000001; asc     ;;
1: len 6; hex 000000000000; asc       ;;
2: len 7; hex 80000000000000; asc        ;;
3: len 4; hex 80004cd6; asc   L ;;
4: len 4; hex 800186b0; asc     ;;

------------------
---TRANSACTION 351861705, ACTIVE 40 sec starting index read
mysql tables in use 1, locked 1
LOCK WAIT 2 lock struct(s), heap size 1136, 1 row lock(s)
MySQL thread id 421774, OS thread handle 140270896170752, query id 8187691 localhost wpdatabayf Updating
UPDATE `wp_custom_points_user` SET `total_points` = '18900' WHERE `user_id` = 188768
------- TRX HAS BEEN WAITING 40 SEC FOR THIS LOCK TO BE GRANTED:
RECORD LOCKS space id 1468 page no 5 n bits 568 index PRIMARY of table `wpdatabayf`.`wp_custom_points_user` trx id 351861705 lock_mode X waiting
Record lock, heap no 2 PHYSICAL RECORD: n_fields 5; compact format; info bits 0
0: len 4; hex 80000001; asc     ;;
1: len 6; hex 000000000000; asc       ;;
2: len 7; hex 80000000000000; asc        ;;
3: len 4; hex 80004cd6; asc   L ;;
4: len 4; hex 800186b0; asc     ;;

---BUFFER POOL 1
.
.
.
.
---BUFFER POOL 31
Buffer pool size   8192
Free buffers       1725
Database pages     6096
Old database pages 2253
Modified db pages  183
Percent of dirty pages(LRU & free pages): 2.340
Max dirty pages percent: 75.000
Pending reads 0
Pending writes: LRU 0, flush list 0, single page 0
Pages made young 0, not young 0
0.00 youngs/s, 0.00 non-youngs/s
Pages read 5594, created 502, written 12349
0.00 reads/s, 0.00 creates/s, 0.74 writes/s
Buffer pool hit rate 1000 / 1000, young-making rate 0 / 1000 not 0 / 1000
Pages read ahead 0.00/s, evicted without access 0.00/s, Random read ahead 0.00/s
LRU len: 6096, unzip_LRU len: 0
I/O sum[0]:cur[0], unzip sum[0]:cur[0]
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
2 read views open inside InnoDB
Process ID=72108, Main thread ID=140323093444352, state: sleeping
Number of rows inserted 88380, updated 193228, deleted 34011, read 84305568368
11.44 inserts/s, 21.74 updates/s, 0.00 deletes/s, 12469107.55 reads/s
Number of system rows inserted 0, updated 0, deleted 0, read 0
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
END OF INNODB MONITOR OUTPUT
============================

更新

SHOW CREATE TABLE wp_custom_points_user;
+----------------------------------+------------------------------------------------------+
| Table                            | Create Table                                         |
+----------------------------------+------------------------------------------------------+
| wp_custom_points_user | CREATE TABLE `wp_custom_points_user` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `total_points` int(11) NOT NULL,
 `user_id` int(11) NOT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `ixd_uc_tzs_wp_custom_points_user` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=199180 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci |
+----------------------------------+------------------------------------------------------+

SHOW INDEX FROM wp_custom_points_user;
+----------------------------------+------------+---------------------------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| Table                            | Non_unique | Key_name                                    | Seq_in_index | Column_name | Collation | Cardinality | Sub_part | Packed | Null | Index_type | Comment | Index_comment |
+----------------------------------+------------+---------------------------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+
| wp_custom_points_user            |          0 | PRIMARY                                     |            1 | id          | A         |      171334 |     NULL | NULL   |      | BTREE      |         |               |
| wp_custom_points_user            |          0 | ixd_uc_tzs_wp_custom_points_user            |            1 | user_id     | A         |      171334 |     NULL | NULL   |      | BTREE      |         |               |
+----------------------------------+------------+---------------------------------------------+--------------+-------------+-----------+-------------+----------+--------+------+------------+---------+---------------+

此行取自 SHOW ENGINE INNODB STATUS；

更新wp_custom_points_user集total_points= ‘18900’user_id其中 = 188768

total_points 值周圍的引號會影響性能，應將其刪除

更新wp_custom_points_user集total_points= 18900user_id其中 = 188768

以避免在設置行上的值時產生 DATATYPE 操作成本。

反引號被這個線上編輯器弄亂了，沒有辦法有效地溝通。

UPDATE `wp_custom_points_user`
   SET `total_points` = '18900'
   WHERE `user_id` = 188768

CREATE TABLE `wp_custom_points_user` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `total_points` int(11) NOT NULL,
 `user_id` int(11) NOT NULL,
 PRIMARY KEY (`id`),
 UNIQUE KEY `ixd_uc_tzs_wp_custom_points_user` (`user_id`)
) ENGINE=InnoDB AUTO_INCREMENT=199180 DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_unicode_ci

我們還需要看一件事——圍繞UPDATE. 周圍有BEGIN... COMMIT交易嗎？的價值是autocommit多少？

我懷疑交易中有很長的一組語句。造成延誤的是交易。值 ( total_points) 聽起來像是某種計數器。我不知道他們為什麼不做一些更簡單的事情，比如

UPDATE ... SET total_points = total_points + 1  WHERE ...

相反，他們必須在做

BEGIN;
SELECT total_points ... FOR UPDATE;  -- it would be a bug without FOR UPDATE
some other stuff         -- this may be slow
UPDATE ...
COMMIT;

還…

沒有明顯的理由為 PK 設置 auto_inc。他們應該改成這樣，這樣可以加快速度：

CREATE TABLE `wp_custom_points_user` (
 `total_points` int(11) NOT NULL,
 `user_id` int(11) NOT NULL,
 PRIMARY KEY (`user_id`),
) ENGINE=InnoDB

您可以對錶定義進行這些更改。但是，如果他們依賴於id其他東西，您可能會破壞某些東西。因此，以下應該是安全的，並實現了一些加速：

CREATE TABLE `wp_custom_points_user` (
 `id` int(11) NOT NULL AUTO_INCREMENT,
 `total_points` int(11) NOT NULL,
 `user_id` int(11) NOT NULL,
 INDEX (`id`),                -- minimum needed for auto_increment
 PRIMARY KEY (`user_id`)      -- clustering to get some speedup
) ENGINE=InnoDB

這可以通過以下方式實現：

ALTER TABLE wp_custom_points_user
   DROP PRIMARY KEY,
   ADD  PRIMARY KEY(user_id),
   DROP INDEX ixd_uc_tzs_wp_custom_points_user,
   ADD INDEX(id);

引用自：https://dba.stackexchange.com/questions/264589

相關問答

Mysql

MariaDB 10.6 出現無法終止的阻塞查詢問題

  • August 25, 2022
檢視問答
Mysql

如何更新和管理數百萬個數據庫

  • August 9, 2022
檢視問答
Mysql

是否有一個布爾列來儲存多值屬性的值是否是一個糟糕的微優化？

  • August 5, 2022
檢視問答
Mysql

為大多數行不存在的數據儲存列

  • May 27, 2022
檢視問答
Mysql

神奇寶貝評論的數據庫設計

  • April 2, 2022
檢視問答
Mysql

多餘的未使用的列對將來有幫助嗎？

  • February 2, 2022
檢視問答