If tutorials available on this website are helpful for you, please whitelist this website in your ad blocker😭 or Donate to help us ❤️ pay for the web hosting to keep the website running.
जब multiple users एक साथ database को access करते हैं, तो उनके बीच data के operations में conflicts हो सकते हैं। Deadlock और MVCC (Multi-Version Concurrency Control) कुछ ऐसे concepts हैं जो ऐसे conflicts को handle करने में help करते हैं।
आज हम इन दोनो को समझेंगे, और Deadlock को Handle करना भी सीखेंगे ।
●●●
MySQL के default storage engine, InnoDB, MVCC implement करता है जिससे concurrency improve होती है और readers और writers एक दूसरे को block नहीं करते।
जब transaction start होता है, वो एक consistent snapshot लेता है जिसमे only data committed पहले तक ही दिखाई देता है।
ये snapshot undo log से maintain होता है—अगर data change हुआ है तो InnoDB पुरानी versions use करता है read के लिए।
READ COMMITTED में हर SELECT new ReadView लेता है, जबकि REPEATABLE READ में transaction के पहले SELECT का snapshot बार-बार repeat होता है।
Read operations lock-free रहती हैं → read-lock wait नहीं होती और deadlocks का risk कम होता है।
Consistent read without blocking writer processes.
●●●
Deadlock तब होता है जब दो या ज़्यादा transactions एक दूसरे का resource lock चाहते रहते हैं—और कोई नहीं release करता।
MySQL automatically deadlocks detect करता है using a wait-for graph, फिर एक transaction को “victim” choose करके rollback करता है (usually जो least work किया हो).
SHOW ENGINE INNODB STATUS; command से latest deadlock detail मिलता है—transaction IDs, involved SQL, locks etc.
अगर innodb_print_all_deadlocks = ON set हो, तो सब deadlocks error log में record होंगे।
●●●
सब transactions को same resource order (tables, rows) में lock करने का pattern follow करना चाहिए. इससे circular waits avoid होते हैं।
Transactions को छोटा रखो—unnecessary processing transaction के बाहर करो।
Large operations को batch‑wise break करो. Toga locks कम duration के लिए hold रहेंगे।
Default REPEATABLE READ में gap locks use होती हैं जिससे deadlock hone के chances बढ़ जाते हैं।
अगर consistent read sequence required नहीं हो, तो READ COMMITTED use करो—less locking, fewer deadlocks.
WHERE, JOIN, ORDER BY columns properly indexed hone चाहिए. Full scans से locks बढ़ जाते हैं।
Indexing से lock scope limited होता है।
Application में retry logic implement करो: अगर deadlock error आये (error code 1213), तो transaction को exponential backoff के साथ retry करो।
Complex transactions में SAVEPOINT set करो, जिससे partial rollback possible हो without aborting full transaction.
Regularly deadlock logs review करो, patterns identify करो।
Tools use करो जैसे Percona PMM, Grafana dashboards, या SHOW ENGINE INNODB STATUS snapshots.
Load testing करके simulated contention detect करो।
●●●
MVCC ensure करता है कि read operations non-blocking हो, जिससे readers के बीच deadlocks का risk कम हो जाता है।
लेकिन write transactions (INSERT, UPDATE, DELETE) अब भी row-level locking का use करते हैं, जिसमे deadlocks possible हैं (especially when two writes target same rows or index ranges).
MySQL का MVCC और InnoDB deadlock detection system यह ensure करता है कि user का system hang न हो — एक transaction automatically abort कर दिया जाता है और application उससे दुबारा try करती है।
“ Repeatable Read में gap locks कि वजह से delete operation 7M rows पर fail हुआ, but Read Committed पर same query 2 minutes में successful हुआ। ”
मतलब isolation level impact करता है deadlock behavior पर।
“Avoid triggers and foreign keys for high concurrency workloads—these can cause deadlocks due तो implicit locking overhead.”
Triggers का execution original transaction का हिस्सा होता है और यह easily से deadlock का reason बन सकते हैं।
●●●
Loading ...
