現在、ほぼすべての記事で、utfのみを使用する必要があると記載されています。これは、utfが現代的で普遍的であり、一般的に非常に有用だからです。 この事実を否定することなく、私は同時にスクリプトの速度を言う著者に当惑させ、仕事の速度のために++ iよりも++ iを書く方が良いという事実に訴えたいと思います。
だから驚き-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％大きいことに注意してください