主キーと一意のインデックスの違いは何ですか
違い: 1. 主キーは制約であり、一意のインデックスはインデックスです。 2. 主キーの作成後は、一意のインデックスを含める必要がありますが、一意のインデックスは必ずしも主キーである必要はありません。 3. 一意のインデックス列では NULL 値が許可されますが、主キー列では NULL 値が許可されません。 4. 主キーは他のテーブルから外部キーとして参照できますが、一意のインデックスは参照できません。
このチュートリアルの動作環境: Windows7 システム、mysql8 バージョン、Dell G3 コンピューター。
主キー インデックスと一意インデックスの違い
主キーは制約であり、一意インデックスはインデックスです。本質的には同じですが異なります。
主キーを作成した後は、一意のインデックスを含める必要があります。一意のインデックスは必ずしも主キーである必要はありません。
一意のインデックス列では NULL 値が許可されますが、主キー列では NULL 値が許可されません。
主キー列が作成されると、デフォルトで NULL 一意のインデックスが設定されます。
主キーは他のテーブルから外部キーとして参照できますが、一意のインデックスは参照できません。
- #テーブルでは主キーを最大 1 つしか作成できませんが、一意のインデックスは複数作成できます。
- 主キーは、自動インクリメント列や ID 番号など、変更が容易ではない一意の識別子に適しています。
- RBO モードでは、主キーの実行プランの優先順位は一意のインデックスの実行プランの優先順位よりも高くなります。どちらもクエリの速度を向上させることができます。
例:
--主キーと一意のインデックスのみを含むテーブルを作成しますCREATE TABLE test (PrimaryKey VARCHAR2(20), UniqueKey VARCHAR2(20) );
ALTER TABLE test ADD CONSTRAINT test_PrimaryKey PRIMARY KEY (PrimaryKey);
CREATE UNIQUE INDEX test_UniqueKey ON test (UniqueKey);
SELECT table_name,table_type,index_name,index_type,uniqueness FROM USER_INDEXES WHERE TABLE_NAME='TEST';
SELECT table_name,index_name,column_name,column_position FROM USER_IND_COLUMNS WHERE TABLE_NAME='TEST';
SELECT table_name,constraint_name,constraint_type FROM USER_CONSTRAINTS WHERE TABLE_NAME='TEST';
# には主キー制約名のみが表示されます。
##-- 主キー制約フィールド名のみが USER_CONS_COLUMNS
SELECT table_name,constraint_name,column_name,position FROM USER_CONS_COLUMNS WHERE CONSTRAINT_NAME IN (SELECT CONSTRAINT_NAME FROM USER_CONSTRAINTS WHERE TABLE_NAME='TEST');
-- 一意のインデックスに非 null 制約を追加します。
ALTER TABLE test MODIFY UniqueKey NOT NULL;
SELECT table_name,constraint_name,constraint_type FROM USER_CONSTRAINTS WHERE TABLE_NAME='TEST'
-- 主キー制約フィールド名と非 null 制約名のみが表示されます。非 null 制約は、USER_CONS_COLUMNS フィールド名で確認できます。
SELECT table_name,constraint_name,column_name,position FROM USER_CONS_COLUMNS WHERE CONSTRAINT_NAME IN (SELECT CONSTRAINT_NAME FROM USER_CONSTRAINTS WHERE TABLE_NAME='TEST')
プログラミング関連の知識の詳細については、プログラミング教育
以上が主キーと一意のインデックスの違いは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。

ホットAIツール

Undresser.AI Undress
リアルなヌード写真を作成する AI 搭載アプリ

AI Clothes Remover
写真から衣服を削除するオンライン AI ツール。

Undress AI Tool
脱衣画像を無料で

Clothoff.io
AI衣類リムーバー

AI Hentai Generator
AIヘンタイを無料で生成します。

人気の記事

ホットツール

メモ帳++7.3.1
使いやすく無料のコードエディター

SublimeText3 中国語版
中国語版、とても使いやすい

ゼンドスタジオ 13.0.1
強力な PHP 統合開発環境

ドリームウィーバー CS6
ビジュアル Web 開発ツール

SublimeText3 Mac版
神レベルのコード編集ソフト(SublimeText3)

ホットトピック

ルートとしてMySQLにログインできない主な理由は、許可の問題、構成ファイルエラー、一貫性のないパスワード、ソケットファイルの問題、またはファイアウォール傍受です。解決策には、構成ファイルのBind-Addressパラメーターが正しく構成されているかどうかを確認します。ルートユーザー許可が変更されているか削除されてリセットされているかを確認します。ケースや特殊文字を含むパスワードが正確であることを確認します。ソケットファイルの許可設定とパスを確認します。ファイアウォールがMySQLサーバーへの接続をブロックすることを確認します。

1.正しいインデックスを使用して、データの量を削減してデータ検索をスピードアップしました。テーブルの列を複数回検索する場合は、その列のインデックスを作成します。あなたまたはあなたのアプリが基準に従って複数の列からのデータが必要な場合、複合インデックス2を作成します2。選択した列のみを避けます。必要な列のすべてを選択すると、より多くのサーバーメモリを使用する場合にのみサーバーが遅くなり、たとえばテーブルにはcreated_atやupdated_atやupdated_atなどの列が含まれます。

MySQLがテーブル構造を変更すると、メタデータロックが通常使用され、テーブルがロックされる可能性があります。ロックの影響を減らすために、次の測定値をとることができます。1。オンラインDDLでテーブルを使用できます。 2。バッチで複雑な変更を実行します。 3.小規模またはオフピーク期間中に操作します。 4. PT-OSCツールを使用して、より細かい制御を実現します。

データ統合の簡素化:AmazonrdsmysqlとRedshiftのゼロETL統合効率的なデータ統合は、データ駆動型組織の中心にあります。従来のETL(抽出、変換、負荷)プロセスは、特にデータベース(AmazonrdsmysQlなど)をデータウェアハウス(Redshiftなど)と統合する場合、複雑で時間がかかります。ただし、AWSは、この状況を完全に変えたゼロETL統合ソリューションを提供し、RDSMYSQLからRedshiftへのデータ移行のための簡略化されたほぼリアルタイムソリューションを提供します。この記事では、RDSMysQl Zero ETLのRedshiftとの統合に飛び込み、それがどのように機能するか、それがデータエンジニアと開発者にもたらす利点を説明します。

MySQLデータベースでは、ユーザーとデータベースの関係は、アクセス許可と表によって定義されます。ユーザーには、データベースにアクセスするためのユーザー名とパスワードがあります。許可は助成金コマンドを通じて付与され、テーブルはCreate Tableコマンドによって作成されます。ユーザーとデータベースの関係を確立するには、データベースを作成し、ユーザーを作成してから許可を付与する必要があります。

MySQLには、無料のコミュニティバージョンと有料エンタープライズバージョンがあります。コミュニティバージョンは無料で使用および変更できますが、サポートは制限されており、安定性要件が低く、技術的な能力が強いアプリケーションに適しています。 Enterprise Editionは、安定した信頼性の高い高性能データベースを必要とするアプリケーションに対する包括的な商業サポートを提供し、サポートの支払いを喜んでいます。バージョンを選択する際に考慮される要因には、アプリケーションの重要性、予算編成、技術スキルが含まれます。完璧なオプションはなく、最も適切なオプションのみであり、特定の状況に応じて慎重に選択する必要があります。

MySQLはAndroidで直接実行できませんが、次の方法を使用して間接的に実装できます。Androidシステムに構築されたLightWeight Database SQLiteを使用して、別のサーバーを必要とせず、モバイルデバイスアプリケーションに非常に適したリソース使用量が少ない。 MySQLサーバーにリモートで接続し、データの読み取りと書き込みのためにネットワークを介してリモートサーバー上のMySQLデータベースに接続しますが、強力なネットワーク依存関係、セキュリティの問題、サーバーコストなどの短所があります。

MySQLデータベースパフォーマンス最適化ガイドリソース集約型アプリケーションでは、MySQLデータベースが重要な役割を果たし、大規模なトランザクションの管理を担当しています。ただし、アプリケーションのスケールが拡大すると、データベースパフォーマンスのボトルネックが制約になることがよくあります。この記事では、一連の効果的なMySQLパフォーマンス最適化戦略を検討して、アプリケーションが高負荷の下で効率的で応答性の高いままであることを保証します。実際のケースを組み合わせて、インデックス作成、クエリ最適化、データベース設計、キャッシュなどの詳細な主要なテクノロジーを説明します。 1.データベースアーキテクチャの設計と最適化されたデータベースアーキテクチャは、MySQLパフォーマンスの最適化の基礎です。いくつかのコア原則は次のとおりです。適切なデータ型を選択し、ニーズを満たす最小のデータ型を選択すると、ストレージスペースを節約するだけでなく、データ処理速度を向上させることもできます。
