ライブ通知は、Websocketが繁栄し、AJAXよりも大きな利点を提供する場所です。
ご存知のように、これはAJAXの役割 を議論するときに両方の前にすでに議論されていました （CRUDに最適ですが、ポーリング時にはそれほど多くありません）およびWebSocketのパフォーマンスとAJAXのパフォーマンス （ライブアップデートが関係する場合、WebSocketは常に高速です）。
はい...on_updateを追加することで、リソースを節約し、パフォーマンス（および将来のコードメンテナンスの問題）を改善できます。 データベースアクセスポイントに「フック」します。
考え方は単純です。関数呼び出しがMySQLデータベースを更新するたびに、更新要求もコールバックに送信されます。そのコールバックは、正しいチャネルへの更新の公開を担当します。
このように、MySQLデータベースをポーリングしません。
一部のデータベースは更新コールバックを提供し、他のデータベースは提供しません。 MySQLはそうだと思います。ただし、これらのデータベースにリンクされたコールバックはデータベース固有であるため、避けています。アプリケーションのデータベースアクセスポイントにコールバックを追加することをお勧めします（IMHO）。そのため、データベースを置き換えてもコードベースに影響はありません。
AJAXは良いアプローチではないと思います。
HTTP / 2はAJAXの欠点を軽減するのに役立ちますが、すべてを解決するわけではありません。
同時に接続されると予想されるクライアントの数はわかりませんが、クライアントに1〜2秒ごとにリクエストを送信させることは、自己攻撃によるDoS攻撃に非常に近いものです。
これを考慮してください。クライアントが2秒ごとにAJAXリクエストを送信する場合、2,000の同時クライアントではなく、サーバーは1,000 req / secに応答する必要があります。これには、認証、データベースクエリ、その他すべてのジャズが含まれます。
一方、2,000の接続されたクライアントでWebsocketを使用すると、メッセージが到着するまで2,000の永続的な接続が何もしません。 CPUや作業は必要ありません。接続のメモリだけです。実際のデータがプッシュされるまで、サーバーにストレスはありません。
はい、実装はより複雑ですが、一度始めればそれほど難しくはありません。また、多くの作業を肩代わりするライブラリやヘルパーツールがたくさんあります。
Websocketアプローチに関連する一般的な問題には、水平スケーリングの処理（多くの場合、Redisなどのpub / subデータベースまたはサービスを追加することによる）、メッセージの順序付け（可能な場合は無視する方がよい）、およびデータ伝播の懸念（いつマークするか）が含まれます。データを「表示済み」として送信しますか？データ全体を送信しますか、それともデータが利用可能であることを示す通知のみを送信しますか？使用するチャネルの数とサブスクリプションの分割方法を教えてください。）
通常、回答はアプリケーション固有であり、展開しようとしている機能とデータセットの予想サイズによって異なります（SOで提供したすべての回答がチャネルである場合、維持するのは非現実的です）。
とにかく...幸運を祈ります！