MySQL 8.021 = 100% CPU 當許多 UPDATE 查詢到 1 個表時

我只是用MySQL 8.021在****Freebsd 12上安裝了新的 LEMP 堆棧

注意到 CPU 的高使用率， 我在正常條件下單獨測試了我的查詢，每次執行時間約為 0.2 秒 - 這對我來說絕對沒問題，但是……

我的 PHP 腳本執行非常簡單的查詢：

1. 更新client_table中的設置值=0；
2. 更新client_table中的設置值=1；
3. 循環 10 個查詢 - 更新 client_table 中的大約 10 個欄位，每個查詢 = 1 個帶有 WHERE 子句的指定行；（當我循環 100 個查詢時，它的查詢超過 60 秒，並且由於 cloudflare 也超時…… - 它們的限制為 90 秒）一般來說，我不想超過 60 秒，因為 cron 我每 1 分鐘使用 crontab 的 10 個腳本實例

1 個實例執行：20-25 秒 10 個實例執行：40-50 秒 每個腳本，所以至少加倍

事實是，當我將查詢數量從每個實例的 50 個提高到 100 個時，它幾乎是執行 1 個實例的 3 倍。

mysql 表有近 30.000 條記錄，大約 20 個欄位 tinyint - int，5x 日期時間，1 個文本，最多 64k 字元 - 現在大部分欄位都是空的，所以絕對沒有太多數據

- 頂級 PID、使用者名、THR PRI NICE SIZE RES 狀態 C 時間、WCPU 命令 67805 mysql、60 20 0 4454M 1147M 選擇 0 3:29 106.81% mysqld

附言。最多 CPU 是 20% 使用者，因為WCPU 顯示所有核心使用情況（六個） 所以也許它不是真的很大的 CPU 使用率，而是在同時對 1 個表進行大量查詢時阻塞？

我使用帶有 6 個虛擬核心和 16GB RAM 和 400GB ssd 磁碟的 Contabo VPS

我認為我的腳本即使有循環和所有這些東西也不應該對 MySQL 造成太大的傷害……我聽說 8.018 但實際上從埠它是 8.021……所以所有東西都應該被修復。

my.cnf 編輯： ** 我嘗試的修改後的配置：（現在切換到 mysql 5.7 - 但同樣的情況，所以我懷疑這是 mysql VERSION 問題）**

也許您對我的配置文件有任何性能提示，**可以同時為 1 個表提供更多查詢，**或者您可能遇到過此類問題？

我的腳本查詢：

# 1 update
UPDATE products SET available_worker_id = 0
   WHERE available_worker_id = 1

# 2 update
UPDATE products SET available_worker_id = '1'
   WHERE check_available_date <= NOW()
     AND available_worker_id = 0
     AND product_id > 0
   ORDER BY check_available_date ASC LIMIT 100

# 3 update
SELECT product_id, next_check_avail FROM products
   WHERE available_worker_id = '1'
   ORDER BY check_available_date ASC LIMIT 100

while ($item = mysqli_fetch_assoc($result)) {
   $mysqli->query("UPDATE products SET shop1-shop10 = $TINY_INT, available_date = NOW(), check_available_date = '".date("Y-m-d H:i:s", time() + $item['next_check_avail'])."', available_worker_id = 0
   WHERE product_id = $product_id
   LIMIT 1")
}

** DEBUG SQL：（一次執行 2 個實例）** Max_used_connections 4 Max_used_connections_time 2020-10-27 19:03:02 Delayed_insert_threads 0 Performance_schema_thread_classes_lost 0 Performance_schema_thread_instances_lost 0 Slow_launch_threads 0 Threads_cached 3 Threads_connected 1 Threads_created 4 Threads

10 個實例： Max_used_connections 11 Threads_connected 11 Threads_created 11 Threads_running 10

---

表：https ://pastebin.com/raw/qQPWR3mD

通常，數據庫不會執行緩慢。 查詢可以。

更新client_table中的設置值=0；

查看實際的查詢（不是上面的釋義）。

查看該查詢的“where 子句”。

它是由索引支持還是您的數據庫必須掃描整個表才能找到要更新的記錄？這很容易解釋過多的 CPU 負載（您可能會發現整個表都位於記憶體中）。

循環執行更新也是有問題的。

您是否檢索到記錄“ID”列表並且現在正在循環它們，對每個進行更改？關係 DBMS 喜歡處理可以擴展到數百萬行的“集”行。在單個行中“狙擊”，您可以在單個基於集合的查詢中處理它們，這會更慢。

查詢中常用欄位的索引並將我的數據庫模式 PRIMARY KEY 從 URL (VARCHAR) 更改為 PRODUCT_ID (INT) 幫助很大！

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