推 liisi: 哈哈 連DK大都這樣說了 看來是無法預防了 01/09 22:24
→ liisi: 只是我上頭不是RD出身 我很難跟他說明要怎解決問題 囧rz.. 01/09 22:25
※ 引述《liisi (小心一點)》之銘言：
: 想請問一下版友
: 如果網站同時有1千人在讀取同一個table 是否會造成lock
: 我今天遇到這種情況 很多買家湧進商品頁面 打算搶單
: 因為搶單關係 很多人會狂按F5重整 (db就會一直去讀商品的table)
: 直到搶單按鈕一出現 馬上下訂單
: 結果時間一到 公司的網站當掉快20分鐘
: MIS是說主機沒有問題 主要是db sql卡住
: 我查了一下 processlist
: 全都卡在 select 商品的table 或是和商品相關join到的table
: 我是把時間長的幾個process kill掉 才慢慢恢復正常
: 之前偶爾卡了幾秒 還不算嚴重
: 但是今天卻卡了20分鐘 整個被lock住 無法釋出
: 必須透過kill process才能恢復正常 囧rz..
: 但是像這種 select lock 要如何解決?
: 我看了一下內文 是有提到 WITH NOLOCK 但是好像是mssql才行
: 想請問mysql有方法可以預防這問題嗎?
你問問看土地公比較有機會...
平常把 PMM 裝起來記錄 MySQL 的各種狀況：
https://www.percona.com/software/database-tools/percona-monitoring-and-management
接上 Grafana 之類的系統，至少在有問題的時候可以看資料去猜：
https://www.percona.com/blog/2016/10/25/monitoring-os-metrics-amazon-rds-grafana/
然後 lock 的時候看一下 InnoDB 裡面的情況，通常會很長，需要慢慢讀：
SHOW ENGINE INNODB STATUS;
SHOW ENGINE INNODB MUTEX;
--
Resistance is futile.
https://blog.gslin.org/ & <[email protected]>
--
※ 發信站: 批踢踢實業坊(ptt.cc), 來自: 122.116.104.21
※ 文章網址: https://www.ptt.cc/bbs/Database/M.1515389750.A.D15.html