數(shù)據(jù)庫(kù)高并發(fā)請(qǐng)求，如何保證數(shù)據(jù)完整性？所謂的并發(fā)可以從它不是并行的概念中看出。從用戶的角度來看，有一種同時(shí)執(zhí)行的假象，但它在數(shù)據(jù)庫(kù)中確實(shí)是串行的，或者在某個(gè)粒度上是串行的。以更新表中的一行數(shù)據(jù)為例，更

數(shù)據(jù)庫(kù)高并發(fā)請(qǐng)求，如何保證數(shù)據(jù)完整性？

所謂的并發(fā)可以從它不是并行的概念中看出。從用戶的角度來看，有一種同時(shí)執(zhí)行的假象，但它在數(shù)據(jù)庫(kù)中確實(shí)是串行的，或者在某個(gè)粒度上是串行的。

以更新表中的一行數(shù)據(jù)為例，更新時(shí)會(huì)鎖定更改后的數(shù)據(jù)行，避免其他進(jìn)程訪問該行，從而避免數(shù)據(jù)沖突。

此外，還有其他類型的鎖，以適應(yīng)不同的場(chǎng)景。因此，在我們所謂的并發(fā)場(chǎng)景中，不存在數(shù)據(jù)問題。

MySQL主從復(fù)制能完美解決數(shù)據(jù)庫(kù)的單點(diǎn)問題嗎？為什么？

使用主從時(shí)，實(shí)際上放棄了強(qiáng)一致性。由于受試者只問一個(gè)問題，我們不考慮訪問次數(shù)的問題。換句話說，假設(shè)主從復(fù)制可以完全支持當(dāng)前的系統(tǒng)訪問。)

通用數(shù)據(jù)庫(kù)主從設(shè)置：

主數(shù)據(jù)庫(kù)可以讀寫

即系統(tǒng)可以同時(shí)從主數(shù)據(jù)庫(kù)和從數(shù)據(jù)庫(kù)獲取數(shù)據(jù)。數(shù)據(jù)寫入主庫(kù)后，會(huì)自動(dòng)同步到從庫(kù)。

這構(gòu)成了一個(gè)簡(jiǎn)單的分布式系統(tǒng)。根據(jù)cap定理，三個(gè)中只能選擇一個(gè)。如果一致性很強(qiáng)，則不會(huì)提高系統(tǒng)的可用性，反而會(huì)降低系統(tǒng)的可用性。

讓我們看看上面的主從結(jié)構(gòu)中可能出現(xiàn)什么問題：

系統(tǒng)寫入主數(shù)據(jù)庫(kù)，然后從主數(shù)據(jù)庫(kù)進(jìn)行查詢。這是一個(gè)單點(diǎn)數(shù)據(jù)庫(kù)，沒有影響。

-如果數(shù)據(jù)已同步，則沒有影響

-如果數(shù)據(jù)未同步，則會(huì)查詢舊數(shù)據(jù)

-如果同步有問題，則會(huì)斷開主設(shè)備和從設(shè)備的連接。如果系統(tǒng)無法感知它，那么查詢可能總是舊數(shù)據(jù)。這里我們需要監(jiān)視同步。當(dāng)同步出現(xiàn)問題時(shí)，我們應(yīng)該及時(shí)處理

掛斷庫(kù)。主數(shù)據(jù)不能與從數(shù)據(jù)同步。如果主從交換機(jī)是自動(dòng)的，單點(diǎn)故障的概率只會(huì)降低50%（如果主數(shù)據(jù)庫(kù)或備用數(shù)據(jù)庫(kù)發(fā)生故障，并且沒有人恢復(fù)）。

mysql數(shù)據(jù)庫(kù)，事務(wù)提交怎么處理？

查看MySQL客戶端的事務(wù)提交模式：選擇@@autocommit

將MySQL客戶端的事務(wù)提交模式修改為手動(dòng)提交命令：設(shè)置@@autocommit=0

（注：0表示手動(dòng)提交，即使用MySQL客戶端執(zhí)行SQL命令后，必須使用commit命令執(zhí)行事務(wù)，否則執(zhí)行的SQL將無效如果要取消事務(wù)，請(qǐng)使用rollback命令。1表示自動(dòng)提交，即不需要在MySQL客戶端手動(dòng)執(zhí)行commit命令。）

在MySQL的自動(dòng)提交模式下，每條SQL語(yǔ)句都是一個(gè)獨(dú)立的事務(wù)。

注意：

1。手動(dòng)設(shè)置@@autocommit=0，即設(shè)置為非自動(dòng)提交模式，該模式僅對(duì)當(dāng)前MySQL命令行窗口有效。打開新窗口后，默認(rèn)值仍然是auto commit；

2。對(duì)于非自動(dòng)提交模式，例如在命令行中添加記錄，并在退出命令行后重新打開命令行，以前插入的記錄不可用。（只需使用select*from表名進(jìn)行驗(yàn)證。）