PHP 開発者がよく犯す MySQL の 10 個の間違いの分析と修正_PHP チュートリアル

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. クエリを最適化していない

言うまでもなく、大規模なアプリケーションでは、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. さらに: 他のデータベースは考慮されていません

これは全く正しいです。アプリケーションでは、アプリケーション用に他のデータベースを選択するだけでなく、特定のビジネス タイプに対して同じアプリケーション内で複数のデータベースを並行して使用することも必要です。データベースでなくても、その他のさまざまなキャッシュ、メモリストレージ、その他のソリューションであっても。