PHP 開発者がよく犯す MySQL の 10 の間違いについて話しましょう_PHP チュートリアル
- WBOYオリジナル
- 2016-07-13 17:48:25784ブラウズ
最近、「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 文字は 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 数学関数の一部も注意して使用する必要があります。大規模なアプリケーションでは、データベースへの負担が最も大きくなることが多く、複雑な 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. さらに: 他のデータベースは考慮されません
これはまったく正しいです。アプリケーションでは、アプリケーション用に他のデータベースを選択するだけでなく、特定のビジネス タイプに対して同じアプリケーション内で複数のデータベースを並行して使用することも必要です。データベースでなくても、その他のさまざまなキャッシュ、メモリストレージ、その他のソリューションであっても。