mysql中的行級鎖通過for update和lock in share mode實現，1.for update用于排他鎖，防止其他事務修改數據，適用于并發更新控制和原子操作，需注意性能、死鎖、索引依賴和超時設置；2.lock in share mode用于共享鎖，允許多個事務讀取但阻止修改，適用于一致性讀和報表生成，需注意并發讀、修改限制和死鎖問題；3.避免死鎖策略包括統一加鎖順序、減少鎖持有時間、使用低隔離級別、避免交叉更新及nowait/skip locked選項；4.不同隔離級別影響for update鎖定范圍，repeatable read鎖定所有查詢行，read committed僅鎖定修改行；5.可通過performance schema監控行級鎖狀態；6.行級鎖相比表級鎖具有更高并發性但開銷更大，應根據應用場景選擇合適的鎖粒度。
行級鎖在mysql中主要通過FOR UPDATE和LOCK IN SHARE MODE來實現，目的是為了在并發環境下保證數據的一致性和完整性。FOR UPDATE用于排他鎖，確保只有一個事務可以修改某一行數據；LOCK IN SHARE MODE用于共享鎖，允許多個事務讀取同一行數據，但阻止任何事務修改。
如何使用FOR UPDATE和LOCK IN SHARE MODE？
FOR UPDATE的使用場景和注意事項
FOR UPDATE是一種悲觀鎖機制，它會在事務開始時鎖定選定的行，直到事務結束才釋放鎖。
使用場景：
- 防止并發更新： 當多個用戶同時嘗試更新同一行數據時，FOR UPDATE可以確保只有一個用戶成功，其他用戶需要等待鎖釋放。
- 實現原子操作： 例如，在庫存系統中，先查詢庫存，然后減少庫存，這兩個操作需要原子性保證，FOR UPDATE可以防止其他事務在查詢和更新之間修改庫存。
示例：
START TRANSACTION; SELECT quantity FROM products WHERE product_id = 1 FOR UPDATE; -- 檢查庫存是否足夠 IF quantity > 0 THEN UPDATE products SET quantity = quantity - 1 WHERE product_id = 1; COMMIT; ELSE ROLLBACK; END IF;
注意事項：
- 性能影響： FOR UPDATE會阻塞其他事務對鎖定的行的訪問，可能降低并發性能。
- 死鎖風險： 如果多個事務以不同的順序鎖定資源，可能會導致死鎖。需要仔細設計事務邏輯，避免循環依賴。
- 索引依賴： FOR UPDATE必須依賴索引才能工作。如果沒有索引，MySQL會鎖定整個表，這會嚴重影響性能。
- 鎖等待超時： 可以通過innodb_lock_wait_timeout參數設置鎖等待超時時間，避免事務長時間阻塞。
LOCK IN SHARE MODE的使用場景和注意事項
LOCK IN SHARE MODE允許事務獲取共享鎖，多個事務可以同時讀取同一行數據，但阻止其他事務修改或刪除這些行。
使用場景：
- 數據一致性讀取： 當需要確保在讀取數據的過程中，數據不會被其他事務修改時，可以使用LOCK IN SHARE MODE。
- 生成報表： 在生成報表時，需要確保數據在報表生成期間保持不變。
示例：
START TRANSACTION; SELECT * FROM products WHERE category = 'Electronics' LOCK IN SHARE MODE; -- 生成報表 COMMIT;
注意事項：
- 并發讀取： LOCK IN SHARE MODE允許多個事務并發讀取數據，提高了并發性能。
- 防止修改： 其他事務不能修改或刪除被鎖定的行，但可以插入新的行。
- 鎖釋放： 共享鎖在事務結束時釋放。
- 死鎖： 雖然LOCK IN SHARE MODE主要用于讀取，但仍然可能與其他類型的鎖發生死鎖。
如何避免死鎖？
死鎖是使用行級鎖時常見的問題，以下是一些避免死鎖的策略：
- 統一加鎖順序： 確保所有事務以相同的順序鎖定資源。
- 減少鎖持有時間： 盡快提交或回滾事務，減少鎖的持有時間。
- 使用較低隔離級別： 適當降低事務隔離級別，例如使用讀已提交（READ COMMITTED）隔離級別。
- 避免交叉更新： 盡量避免多個事務更新同一批數據。
- 使用NOWAIT或SKIP LOCKED： MySQL 8.0及以上版本支持NOWAIT和SKIP LOCKED選項，可以避免事務無限期等待鎖。
FOR UPDATE在不同隔離級別下的行為差異
事務隔離級別會影響FOR UPDATE的行為。在可重復讀（REPEATABLE READ）隔離級別下，FOR UPDATE會鎖定所有被查詢到的行，即使這些行沒有被修改。而在讀已提交（READ COMMITTED）隔離級別下，FOR UPDATE只會鎖定實際被修改的行。
如何監控行級鎖？
可以使用MySQL的性能模式（Performance Schema）來監控行級鎖。通過查詢performance_schema.data_locks和performance_schema.data_lock_waits表，可以了解當前系統中哪些事務正在持有鎖，哪些事務正在等待鎖。
例如，查詢正在等待鎖的事務：
SELECT waiting_trx.trx_id AS waiting_trx_id, waiting_trx.trx_mysql_thread_id AS waiting_thread, waiting_trx.trx_query AS waiting_query, blocking_trx.trx_id AS blocking_trx_id, blocking_trx.trx_mysql_thread_id AS blocking_thread, blocking_trx.trx_query AS blocking_query FROM performance_schema.data_lock_waits dlw INNER JOIN information_schema.innodb_trx waiting_trx ON dlw.requesting_engine_transaction_id = waiting_trx.trx_id INNER JOIN information_schema.innodb_trx blocking_trx ON dlw.blocking_engine_transaction_id = blocking_trx.trx_id;
行級鎖與表級鎖的比較
行級鎖和表級鎖是兩種不同的鎖定粒度。行級鎖只鎖定需要修改的行，并發性能較高，但開銷也較大。表級鎖鎖定整個表，開銷較小，但并發性能較低。在選擇鎖定粒度時，需要根據具體的應用場景進行權衡。通常情況下，行級鎖適用于并發較高的場景，而表級鎖適用于并發較低的場景。
