おそらく、MySQL サーバーとアプリケーションが実行されているマシンとの間のネットワーク トラフィックのオーバーヘッドを節約する目的でこれを行っていると思われます。たまたま、MySQL サーバー上の他の種類のワークロードを節約していません。ディスクから LONGTEXT アイテムを取得し、それを実行する必要がありますSUBSTRING
。
おそらく、確実なパフォーマンス分析に基づいて、このネットワーク トラフィックを節約する必要があるとすでに判断しているはずです。MySQL サーバーのワークロードがあまり節約されないことがわかったので、この分析を再検討することをお勧めします。無数の非常に長い LONGTEXT アイテムと、それらの一部を取得して表示するための大量のトラフィックがない限り、節約はわずかです。
つまり、これは最適化タスクです。ヤグニ? http://en.wikipedia.org/wiki/YAGNI
どうしても必要な場合は、LONGTEXT 項目を単語ごとに処理するソフトウェアを作成する必要があります。最善の策は、クライアント ソフトウェアでこれを行うことです。最初のページと記事の ak または 2 ページを取得することから始めます。次に、テキストを解析して完全な単語を探します。最初のページとそれに続く空白で最後の完全な単語を見つけたら、その文字位置が次のページの開始位置になります。
この種のタスクは、MySQL ストアド プロシージャの首に大きな負担となります。さらに、ストアド プロシージャで実行すると、複製可能なクライアント マシンではなく、共有されたスケールアップが難しいリソース (MySQL サーバー マシン) で処理サイクルを使用することになります。
私はあなたが求めていることをするためのきれいなコードをあなたに与えていないことを知っています. しかし、あなたが提案していることをするのは明らかに良い考えではありません。
編集:
観察: 1 ギガバイトのサーバー RAM のコストは約 20 米ドルです。memcached のようなキャッシュ システムは、100 米ドル相当のメモリを効率的に活用するのに優れています。あなたが説明したユースケースには十分です。
もう 1 つの観察結果として、大規模なドキュメントを処理する多くの企業は、ドキュメントの保存に DBMS ではなくファイル システムを使用しています。ファイル システムは、コンテンツ サーバー間で非常に簡単に共有または複製できます。ファイルは、オーバーヘッドなしで簡単にランダム アクセスできます。
ブック全体を単一の BLOB または CLOB に格納するのは少し革新的です。本を何らかのセグメントで分割できる場合は、ページですか? 章?千語チャンク?-- セグメントごとに個別のデータ行を作成すると、DBMS は、説明したものよりもはるかにうまくスケールアップします。
とにかくそれを行う場合は、次のようにします。
各セグメントで必要な文字よりも常に 100 文字多く取得します。たとえば、30000 ~ 35000 の文字が必要な場合は、30000 ~ 35100 を取得します。
セグメントを取得した後、データ内の最初の単語区切りを探し (最初のセグメントを除く)、その単語から始まる表示を行います。
同様に、余分な 100 バイトの最初の単語区切りを見つけて、その単語区切りまで表示します。
したがって、フェッチされたデータは 30000 ~ 35100 であり、表示されるデータは 30013 ~ 35048 である可能性がありますが、それは単語全体になります。