要優(yōu)化聊天應(yīng)用程序的MySQL，請(qǐng)使用有效的表結(jié)構(gòu)，優(yōu)化查詢，調(diào)整MySQL設(shè)置并添加緩存。 1）結(jié)構(gòu)帶有索引的Sender_ID，Receiver_ID和時(shí)間戳的消息表，將消息內(nèi)容分開(kāi)。 2）用復(fù)合索引優(yōu)化查詢，避免選擇 *，并使用基于范圍的分頁(yè)。 3）調(diào)整InnoDB設(shè)置，使用連接池，批處理插入物并考慮分區(qū)。 4）使用Redis緩存最新消息和存在數(shù)據(jù)，從而減少了數(shù)據(jù)庫(kù)負(fù)載。

當(dāng)使用MySQL作為后端構(gòu)建聊天或消息傳遞應(yīng)用程序時(shí)，如果不正確處理，性能很快就會(huì)成為瓶頸。聊天應(yīng)用程序的性質(zhì) - 頻繁的小寫作，實(shí)時(shí)讀取和高分子 - 默認(rèn)mysql設(shè)置和基本表結(jié)構(gòu)不會(huì)削減它。

以下是一些實(shí)用的優(yōu)化，可以真正改變。

使用正確的表結(jié)構(gòu)進(jìn)行消息存儲(chǔ)

聊天應(yīng)用程序會(huì)生成許多小記錄，因此有效地構(gòu)造表是關(guān)鍵。一個(gè)常見(jiàn)且有效的設(shè)置是具有以下最小結(jié)構(gòu)的messages表：

• id - 唯一消息ID（主鍵）
• sender_id - 發(fā)送消息的用戶
• receiver_id - 接收它的用戶（如果支持組聊天，則組ID）
• message - 消息的內(nèi)容
• timestamp - 發(fā)送消息時(shí)
• read_status - 是否讀取消息（可選）

尖端：

• 將消息內(nèi)容保留在與元數(shù)據(jù)的單獨(dú)列中，以便于索引。
• 如果支持消息編輯或刪除，請(qǐng)考慮使用message_edits或deleted_messages表，而不是直接從主表中更新/刪除。

另外，請(qǐng)確保索引正確的列。至少，索引sender_id ， receiver_id和timestamp 。這使得兩個(gè)用戶之間的對(duì)話更快。

優(yōu)化用于實(shí)時(shí)對(duì)話的查詢

有效地獲取聊天歷史至關(guān)重要。大多數(shù)查詢看起來(lái)像：

從消息中選擇 *
其中（sender_id = 1和receiver_id = 2）
   或（sender_id = 2和receiver_id = 1）
按時(shí)間戳ASC訂購(gòu)
限制50;

這有效，但是如果不優(yōu)化，它可能會(huì)變得慢。這是改善它的方法：

• 使用復(fù)合索引：在(sender_id, receiver_id, timestamp)上創(chuàng)建一個(gè)復(fù)合索引。這有助于mySQL迅速找到正確的對(duì)話窗口。

• *避免選擇`**：僅獲取所需的字段，尤其是當(dāng)您的消息表具有大文本或斑點(diǎn)列時(shí)。

• 巧妙地講話：而不是使用LIMIT offset, size而是使用時(shí)間戳使用基于范圍的分頁(yè)，而不是使用限制偏移，而不是使用限制偏移量：

  從消息中選擇 *
  其中（sender_id = 1和receiver_id = 2）
     或（sender_id = 2和receiver_id = 1）
     和時(shí)間戳<&#39;last_seen_timestamp&#39;
  訂購(gòu)時(shí)間戳desc
  限制50;

  這樣，您避免掃描所有以前的消息。

  ---

  調(diào)整高寫入負(fù)載的mysql設(shè)置

  聊天應(yīng)用程序較重，因此默認(rèn)的MySQL配置是不夠的。以下是一些關(guān)鍵領(lǐng)域：

  • InnoDB設(shè)置：增加innodb_log_file_size和innodb_log_buffer_size來(lái)處理頻繁寫入。較大的日志文件在消息插入爆發(fā)過(guò)程中減少磁盤I/O。
  • 連接池：聊天應(yīng)用程序通常打開(kāi)并關(guān)閉許多短暫的連接。使用連接池（例如ProxySQL或應(yīng)用程序級(jí)池）來(lái)減少開(kāi)銷。
  • 查詢緩存：將其關(guān)閉。它在更新的MySQL版本中被棄用，實(shí)際上可能會(huì)損害寫入較重的環(huán)境中的性能。
  • 使用批處理插入：如果您的應(yīng)用程序允許，則不要一次插入一條消息，而是在單個(gè)插入中進(jìn)行批處理多個(gè)消息。

  另外，一旦達(dá)到一定的量表，請(qǐng)考慮分解或分區(qū)，尤其是在存儲(chǔ)全局聊天日志的情況下。從用戶ID或?qū)υ拰?duì)進(jìn)行簡(jiǎn)單的分區(qū)開(kāi)始。

  ---

  考慮使用緩存層

  即使有優(yōu)化的查詢，實(shí)時(shí)閱讀消息也可能很昂貴。添加緩存層可以幫助減少數(shù)據(jù)庫(kù)負(fù)載。

  • REDIS是緩存最新消息或未閱讀計(jì)數(shù)的流行選擇。
  • 將每個(gè)對(duì)話的最新消息存儲(chǔ)在Redis中，然后返回MySQL以獲取舊消息。
  • 使用Redis跟蹤存在和在線狀態(tài) - DATA經(jīng)常變化并且不需要持久性。

  請(qǐng)記住，當(dāng)新消息傳來(lái)或用戶將消息標(biāo)記為讀取時(shí)，要無(wú)效或更新緩存。

  ---

  最后的想法

  為聊天應(yīng)用程序優(yōu)化MySQL并不過(guò)于復(fù)雜，但確實(shí)需要周到的設(shè)計(jì)和調(diào)整。從正確的模式開(kāi)始，優(yōu)化您的查詢以進(jìn)行對(duì)話檢索，調(diào)整MySQL設(shè)置以進(jìn)行高并發(fā)，并在適當(dāng)?shù)那闆r下使用緩存。

  在達(dá)到功能限制之前，您可能會(huì)遇到性能問(wèn)題，因此請(qǐng)盡早計(jì)劃可伸縮性。而且，如果負(fù)載太高，請(qǐng)不要害怕將某些數(shù)據(jù)移至NOSQL商店或?qū)Ｓ孟㈥?duì)列。

  基本上，這一切都是關(guān)于平衡結(jié)構(gòu)，速度和規(guī)模。

  以上是優(yōu)化聊天應(yīng)用程序和消息傳遞的MySQL的詳細(xì)內(nèi)容。更多信息請(qǐng)關(guān)注PHP中文網(wǎng)其他相關(guān)文章！