だから驚き-utfでの作業はcp1251よりも遅くなります。 サイズが大きく、文字がバイト単位で「整列」されていないためです。 それはphp / mysqlについてです
実際、これには特にひどいものは何もありません。 コード内のジャムとは異なり、utfを使用してもそれほど遅くなることはありませんが、直線的に遅くなるため、ほとんどの場合、問題はスケーリングによって非常に簡単に解決されます。 顧客/雇用主からより強力なサーバーにお金を渡そうとしたことがないなら、これはあなたを安心させるはずです。
あなたが安心していない場合、以下はあなたに役立つかもしれないいくつかの数字です。
患者:非常に強力な空borne部隊ではなく、ノード上の唯一の部隊(あちこちにドラッグする方が簡単ですが、それは重要ではありません)、数百万行のいくつかのテーブル、ロシア語のテキスト、英語。 テストをリブートするたびに、サーバーには何もロードされなくなります。 テストは少なくとも3回実行され、平均は表に表示されます。
どんなデータ | UTF結果 | CP1251の結果 | cp1251の利点 |
---|---|---|---|
MyISAM(テキスト、テキスト、int、int) | ***** | ***** | ***** |
元のDBサイズ | 1.250 GB | 0.975 GB | 1.28回 |
マスタデータ | 706 Mb | 479 Mb | 1.47回 |
インデックスデータ | 544 Mb | 496 Mb | 1.09回 |
行の一部を削除するリクエスト | 16秒 | 7秒 | 2.28回 |
フルテキストインデックスの削除 | 26秒 | 23秒 | 1.13回 |
フルテキストインデックスの構築 | 6分22秒 | 3分12秒 | 1.98回 |
正確なエントリを検索、10回* 1 | 9.67秒 | 1.92秒 | 5.03回 |
ファイルへのmysqldumpエクスポート | 8.8秒 | 4.9秒 | 1.79回 |
ファイルからのmysqlインポート | 13.8秒 | 8.7秒 | 1.58回 |
* .sqlファイルサイズ | 773 Mb | 526 Mb | 1.46回 |
スフィンクスの索引付け | 103秒 | 41秒 | 2.51回 |
スフィンクスの基本サイズ | 680 Mb | 433 Mb | 1.57回 |
innoDB(テキスト、テキスト、整数、整数) * 3 | ***** | ***** | ***** |
元のDBサイズ | 925 Mb | 629 Mb | 1.47回 |
行の一部を削除するリクエスト | 21.2秒 | 12秒 | 1.76回 |
正確なエントリを10回検索 | 33.47秒 | 21.89秒 | 1.52回 |
ファイルへのmysqldumpエクスポート | 23秒 | 17秒 | 1.35回 |
ファイルからのmysqlインポート* 4 | 8分24秒 | 5分41秒 | 1.47回 |
* .sqlファイルサイズ | 748 Mb | 510 Mb | 1.46回 |
メモリint、char(128) * 2 | ***** | ***** | ***** |
メモリテーブルサイズ | 515 Mb | 179 Mb | 2.87回 |
メモリテーブルの行の長さ | 390 | 133 | 2.93回 |
メモリテーブル1000回の検索、毎回見つかるもの | 1.9秒 | 0.32秒 | 5.93回 |
メモリテーブル1000検索、何も見つかりませんでした | 1.8秒 | 0.28秒 | 6.42回 |
* 1 :これらの数値にショックを受けて、同様のテストがローカルホストで開始され、利点は3.02倍に減少しました。 おそらく、何かがキャッシュに入れられなかったか、utfの場合に不必要にディスクに落ちたため、データが増えました。
* 2 :メモリテーブルは、正確な出現を検索するために使用されます。メモリテーブルには、純粋にロシア語のテキストといくつかのスペースが含まれています。 約200万行。 utf8のメモリテーブルのサイズは、cp1251の3倍です。 固定サイズが使用され(メモリには他の方法はありません)、その中のuft8は文字ごとに3バイトを予約します。
* 3 :innoDBの場合、フルテキストインデックスは、innoDBでサポートされていないためテストされていません。 InnoDBはMyISAMや他の空中システムとはわずかに異なるサイズのテーブルを使用したため、絶対的な結果を直接比較することはできません。
* 4 :innoDBへのインポートに多くの時間がかかった理由は非常に不明です。 MyISAMの場合、インポートとエクスポートの違いは最小限です。
そして、いくつかの一般的な言葉。 一般的に言えば、この「記事」は数年前にドラフト形式で作成されました。 ここにスフィンクスのみが追加され、テストが繰り返されました。 そして、utfの見通しについてのいくつかのフォーラムでの論争の結果として生じ、彼らは他のエンコーディングが1年で死ぬだろうと言っている。 しかし、彼らは死ななかった。
さらに、例えばphp / mysqlの問題はまだ非常に異なっています。 最初にutf、次にutf-8、次にutf8を記述する必要があります。 そして、utfでさえru_RU.UTFまたはen_EN.UTFのいずれかであり、これはiconv //で変な効果を与えます//トランジットを無視します//神はその理由を知っています。 phpをモジュールとしてインストールすると、サーバー全体でロケールが同じになり、すべての結果が得られます。正しいロケールでも、文字列を操作するために通常の関数を使用することはできません。この作業をサポートする類似物を使用する必要があります。 一般的に、utfは確かに高度な技術ですが、過度に熱狂的になることなく、思慮深く適用する必要があります。
PS:プロキシでトラフィックを圧縮したい人のために、utf8のHTMLファイルはgzipでも5-20%大きいことに注意してください