ゲーム開発者 PHP 開発者がよく犯す MySQL の 10 の間違いの分析と修正

1. InnoDB の代わりに MyISAM を使用する
完全に間違っています、反論の理由:
まず第一に、元の記事では MyISAM がデフォルトで使用されると述べていますが、実際には、MySQL 5.5.x では InnoDB がデフォルトのテーブル エンジンになっています。
さらに、単に InnoDB を使用するだけではすべての問題が解決されるわけではありません。場合によっては、アプリケーションのパフォーマンスが 10%、あるいは 40% 低下する可能性があります。
フォーラムセクションテーブル、ニュース分類テーブル、各種コードテーブル、その他長期間運用されないテーブルなど、特定のビジネスに対処するのが最善の方法ですが、それでも優れたパフォーマンスを備えたMyISAMエンジンを使用する必要があります。
そして、ユーザー、アカウント、パイプラインなど、データの整合性とタイミングを厳密に要求するトランザクション処理を使用する必要があるものは、InnoDB エンジンを使用する必要があり、アプリケーションもトランザクション処理メカニズムをうまく活用する必要があります。もちろん、トランザクション処理は必然的に大幅なパフォーマンスの低下をもたらしますが、これは単純な同時実行性の高いアプリケーションでは必要です。
最後に、外部キー制約はパフォーマンスに重大な影響を与えるため、一般的にパブリック Web インターネット アプリケーションでは使用されません。データの整合性は、依然としてプログラマー、またはアプリケーション アーキテクチャ自体の堅牢性に依存して維持されています。正式な 3 番目のパラダイムは、企業の内部 MIS システムおよび 12306 などの Web サイトでのみ使用されます。
2. PHP の mysql メソッドを使用します
完全に間違っているわけではありませんが、適切に選択する必要があります:
Mysqli は優れていますが、すべてのサーバーが PHP 用の mysqli サポートをコンパイルしているわけではありません。
アプリケーションが自分でデプロイしたサーバーのみを使用することが決定でき、アプリケーションが完全に自分で開発されている場合は、mysqli が最適な選択です。
しかし、アプリケーションが仮想ホスト上にデプロイされたり、他の人（分散プロジェクトなど）によってデプロイされたりする可能性が高い場合は、MySQL 関数セットを正直に使用し、適切にカプセル化するか、成熟したフレームワークを使用して SQL インジェクションを防ぐ方が良いでしょう。
3. ユーザー入力をフィルターしないでください
言うまでもなく、MagicQuote または成熟したフレームワークです。 SQL インジェクションは古いトピックです。
4. UTF-8 を使用しないでください
ほとんどの場合は可能ですが、次のことも慎重に考慮する必要があります。
UTF-8 の 1 文字は 3 バイトを占有するため、GBK などの他のエンコーディングのファイルより 33% 大きいことを知っておく必要があります。 。つまり、同じ Web ページが UTF-8 エンコードで 100KB である場合、GBK エンコードでは 66KB にしかならないということです。したがって、PHP が UTF-8 を使用するように決定されている場合でも、フロントエンド ページは状況に応じて必要なエンコーディングを選択する必要があります。ただし、PHP が UTF-8 を使用し、フロントエンド テンプレートが GBK で、テンプレート エンジンが強力でない場合は、トランスコーディング作業で十分です。したがって、単純に UTF-8 を選択するのではなく、必要なエンコーディングを使用するようにしてください。
最後のコメント: UTF-8 では strlen("I")=3、GBK では strlen("I")=2
5. SQL を使用する必要がある場合は PHP を使用する
同様に考慮してください:
たとえば、次のような人がいます。ユーザーは、テーブルを作成するときにデフォルト値として CURRENT_TIMESTAMP を入力することに慣れています。これは、登録時間と投稿時間の効果を実現するために使用されます。 または、時刻判定 SQL 文に SELECT x FROM tab1 WHERE regdate のように記述します。MySQL の時刻関数を使用せず、アプリケーション内で時刻を計算するのが正しい方法です。分散アプリケーションの場合、時刻を均一に管理するためにタイムサーバーが必要です。
記事内で言及されている MySQL 数学関数の一部も注意して使用する必要があります。大規模なアプリケーションでは、データベースへの負担が最も大きくなることが多く、複雑な WHERE ステートメントがクエリ速度の低下の原因となるためです。したがって、計算はコア データベースではなく、グローバルな安定性に影響を与えない安価なアプリケーション サーバーにできるだけ配置する必要があります。
6. クエリを最適化していない
言うまでもなく、大規模なアプリケーションではさまざまな JOIN を使用することさえできません。たとえ 2 つのクエリを作成しても、PHP を使用してデータを結合できます。
7. 間違ったデータ型の使用
INT、TinyINT、VARCHAR、CHAR、TEXT などのフィールド型を適切に選択することに問題はありません。
大規模なアプリケーションでは、Date、DateTime、TIMESTAMP の 3 つのタイプを使用してはならず、代わりに INT(10) UNSIGNED を使用する必要があります。
1つはパフォーマンスであり、もう1つはアプリケーション、特にPHPにとってUNIX_TIMESTAMPタイムスタンプを変換するのに非常に便利であるということです。 Date を使用してさまざまな時刻形式を出力するのは面倒です。
8. SELECT クエリで * を使用する
推奨します
9. インデックス作成が不十分または過剰な場合
インデックス作成は必要ですが、インデックスによってクエリを解決できない場合は、memcache または nosql ソリューションを検討してください。
10. バックアップはありません
これは作者が数字をでっち上げているだけですか?
11. さらに、他のデータベースは考慮されていません
これはまったく正しいです。アプリケーションでは、アプリケーション用に他のデータベースを選択するだけでなく、特定のビジネス タイプに対して同じアプリケーション内で複数のデータベースを並行して使用することも必要です。データベースでなくても、その他のさまざまなキャッシュ、メモリストレージ、その他のソリューションであっても。

以上、ゲーム開発者や PHP 開発者がよく犯す 10 個の MySQL エラーの修正分析を紹介しました。ゲーム開発者向けの内容も含まれており、PHP チュートリアルに興味のある友人の参考になれば幸いです。