相違点: 1. PGSQL には CPU コアの数に制限がありませんが、mysql には制限があります; 2. PGSQL には合計 255 の構成ファイル パラメータがあり、MySQL には合計 707 があります; 3 . PGSQL はマルチフィールド統計情報をサポートしますが、MySQL はサポートしません; 4. PGSQL は実行計画のリアルタイム コンパイルをサポートしますが、MySQL はサポートしません。
このチュートリアルの動作環境: Windows 7 システム、PostgreSQL 11&&MySQL5.7 バージョン、Dell G3 コンピューター。
PostgreSQL は、非常に充実した機能を備えたフリー ソフトウェアのオブジェクト リレーショナル データベース管理システム (ORDBMS) です。
PostgreSQL は、ほとんどの SQL 標準をサポートし、複雑なクエリ、外部キー、トリガー、ビュー、トランザクションの整合性、複数バージョンの同時実行制御待機など、その他の多くの最新機能を提供します。同様に、PostgreSQL は、新しいデータ型、関数、演算子、集計関数、インデックス メソッド、手続き型言語などを追加するなど、さまざまな方法で拡張できます。さらに、ライセンスが柔軟なため、誰でも PostgreSQL をあらゆる目的に無料で使用、変更、配布できます。
postgresql と mysql の違いの比較
比較バージョン: PostgreSQL 11 VS MySQL5.7 (innodb エンジン) Oracle 公式コミュニティ バージョン 著作権ステータス: PostgreSQL 11 (無料およびオープン ソース)、MySQL5.7 Oracle 公式コミュニティ バージョン (無料およびオープン ソース)
1. CPU 制限
PGSQL CPU コアの数に制限はありません。ある限り多くの CPU コアを使用してください
MySQL は 128 コアの CPU を使用できますが、128 コアを超えるコアは使用できません
2。構成ファイルのパラメータ
PGSQL パラメータは合計 255 個あり、そのうちの約 80 個が使用されています。パラメータは比較的安定しています。以前の大きなバージョンのデータベースを使用して、現在の大きなバージョンのデータベースを起動することもできます。バージョン設定ファイル。
MySQL には合計 707 個のパラメータがあり、そのうち約 80 個が使用されています。180 個のパラメータは常に増加しており、小さなバージョンでもパラメータが増加し、一部のパラメータは大きなバージョン間で互換性がありません
3. サードパーティ ツールの依存関係
PGSQL 高可用性クラスターのみ、patroni etcd、repmgr
# などのサードパーティ ミドルウェアに依存する必要があります。 ##MySQL のほとんどの操作は percona のサードパーティ ツール (percona-toolkit、XtraBackup) に依存しており、ツール コマンドが多すぎるため、学習コストが高く、高可用性クラスターにはサードパーティのミドルウェアも必要です。公式の MGR クラスターはまだ成熟していません4. 高可用性マスター/スレーブ レプリケーションの基本原理
PGSQL の物理ストリーミング レプリケーションは物理レプリケーションです。 SQL Server のミラーリング/AlwaysOn と同じです。厳密に一貫性があり、不整合が発生する可能性はありません。パフォーマンスと信頼性の点で、物理レプリケーションは論理レプリケーションよりも優れており、保守が容易です。MySQL マスター/スレーブ レプリケーションは、論理レプリケーション (sql_log_bin、binlog_format などのパラメータ設定が正しくないと、マスターとスレーブの不整合が発生します) 大規模なトランザクションの並列レプリケーションの効率は低く、重要なビジネスの場合は、pt-table-checksum と pt-table-checksum に依存する必要があります。 percona-toolkit の pt-table-sync ツールを使用して合計を定期的に比較します。マスター/スレーブの一貫性のあるマスター/スレーブ レプリケーション エラーを修復します。マスター/スレーブの MySQL 論理レプリケーションを再確立する必要がありますが、2 つの矛盾したデータベースのエラーは防止されません。レプリケーション関係の確立5. スレーブ データベースの読み取り専用ステータス
PGSQL システムは、デフォルトでスレーブ ライブラリを自動的に読み取り専用に設定し、手動による介入は必要ありません。必要であり、メンテナンスが簡単です MySQL スレーブ ライブラリは、スレーブ ライブラリを読み取り専用に設定するには、パラメータ super_read_only=on を手動で設定する必要があります。super_read_only パラメータにはバグがあります (リンク: https://baijiahao.baidu)。 com/s?id=1636644783594388753&wfr=spider&for=pc6. バージョン ブランチ
PGSQL にはコミュニティ バージョンのみがあり、他のブランチ バージョンはありません。PGSQL は公式です。コミュニティ版はすべての機能を備えており、標準版、エンタープライズ版、クラシック版、コミュニティ版、開発版、Web版があるSQL ServerやMySQLとは異なり、国内外で利用可能です。一部のデータベース メーカーは、Enterprise DB、Hanao Database など、PGSQL に基づいた二次開発を行っています。もちろん、これらは単なる二次開発であり、独立したブランチではありません。MySQL は、次の理由により 3 つのブランチ バージョンに分割されています。歴史的な理由、MariaDB ブランチ、Percona ブランチ、Oracle 公式ブランチ。これまでのところ、ブランチは基本的に相互に互換性がありません。Oracle 公式ブランチにもバージョンがあり、Standard Edition、Enterprise Edition、Classic Edition、および Community Edition## に分かれています#7. SQL 機能のサポートPGSQLSQL 機能のサポートは 94 種類をサポートしており、SQL 構文のサポートは最も完全です (例: 共通テーブル式 (WITH クエリ) のサポート)
MySQLSQL 機能のサポート 36 の状況がサポートされており、SQL 構文のサポートは比較的弱いです。たとえば、一般的なテーブル式 (WITH クエリ) はサポートされていません。SQL 機能のサポートの比較については、次を参照してください: http:/ /www.sql-workbench.net/dbms_comparison.html
8. マスター/スレーブ レプリケーション セキュリティPGSQL 同期ストリーム レプリケーション、強力な同期 (リモート適用)、高セキュリティ、データ損失なし PGSQL 同期ストリーム レプリケーション: すべてのスレーブ データベースがダウンすると、マスター データベースがストライクになります。マスター データベースは、非同期ストリーミング レプリケーション (非同期モード) に自動的に切り替えることができません。これは、数値を増やすことで解決する必要があります。スレーブデータベースの。
一般に、運用環境には少なくとも 2 つのスレーブ ライブラリがあります。手動による解決策: PG メイン ライブラリのパラメータ synchronous_standby_names ='' を変更し、コマンド pgctl reload を実行します。メイン ライブラリを非同期モードに切り替えます。マスターとスレーブのデータが完全に一致している 高 スイッチングを利用できるための最初の前提条件。
だから、PGSQL が攻撃するマスター データベースを選択することは理解できます。MySQL の強化された準同期レプリケーション
mysql5.7 バージョンの強化された準同期により、マスター/スレーブ レプリケーション中にデータが失われることはありません。 Mysql5.7 半同期レプリケーション関連パラメータ: パラメータ rpl_semi_sync_master_wait_for_slave_count マスター ライブラリがトランザクションをコミットする前に、少なくとも何個のスレーブ ライブラリが binlog を受信するまで待機します
通常は 1 に設定されます。ミリ秒。応答がない場合、スレーブ ライブラリは自動的に非同期モードに切り替わります。
全般 メイン ライブラリが自動的に非同期モードに切り替わらないようにするには、無限に設定します。すべてのスレーブ ライブラリはダウンします。メインスレーブ ライブラリからの応答パケットを受信できないため、ライブラリはストライキになります。手動による解決策: MySQL メイン ライブラリのパラメータ rpl_semi_sync_master_wait_for_slave_count を変更します。 =0
9. マルチフィールド統計情報PGSQL は複数フィールドの統計情報をサポートします
MySQL は複数フィールドの統計情報をサポートしません
10. インデックス タイプPGSQL 複数のインデックス タイプ (btree、hash、gin、gist、sp-gist、brin、bloom、rum、zombodb、ビットマップ、部分インデックス、式インデックス)
MySQLbtree インデックス、フルテキスト インデックス (非効率) 、式インデックス (仮想列を作成する必要があります)、メモリ テーブルのみのハッシュ インデックス
##11. 物理テーブル接続アルゴリズム
PGSQL はネストされたループ結合、ハッシュをサポートしますjoin、merge join
MySQL はネストされたループ joinのみをサポートします12. サブクエリとビューのパフォーマンス
##PGSQL サブクエリ、ビューの最適化、比較的高いパフォーマンス
MySQL ビューの述語条件には多くのプッシュダウン制限があり、サブクエリには多くのプルアップ制限があります13. 実行プランのジャストインタイム コンパイル
PGSQL は、LLVM コンパイラを使用した JIT 実行プランのジャストインタイム コンパイルをサポートします。
MySQL は実行プランのジャストインタイム コンパイルをサポートしません14。並列処理クエリ
PGSQL 並列クエリ (複数の並列クエリ最適化手法)、並列クエリは一般に商用データベースで見られ、重量のある関数です
MySQL は制限があり、主キーのみをサポートします並列クエリ15. マテリアライズド ビュー
PGSQL はマテリアライズド ビューをサポートします
MySQL はマテリアライズド ビューをサポートしません16 . プラグイン関数
PGSQL は、PGSQL、GIS 地理プラグイン、時系列データベース プラグイン、ベクトル化実行プラグインなどの機能を強化できるプラグイン関数をサポートしています。
MySQL はプラグイン関数をサポートしていません17. チェック制約
PGSQL はチェック制約をサポートしています
MySQL はサポートしていませんチェック制約を記述できますが、ストレージ エンジンはその効果を無視するため、チェック制約は機能しません (mariadb によってサポートされています)18. GPU アクセラレーション SQL
PGSQL は GPU を使用して SQL 実行速度を高速化できます
MySQL は GPU による SQL 実行速度の高速化をサポートしていません19. データ型
PGSQL には、ltree、hstore、配列型、ip 型、text 型などの豊富なデータ型があり、text 型は廃止されました。varchar および text 型フィールドの最大ストレージは 1GBです。
MySQL データ型はサポートされていません。十分に豊富な20. クロスデータベース クエリ
PGSQL はクロスデータベース クエリをサポートしていません。これは以前の Oracle 12C
MySQL と同じです。データベース間でクエリを実行できます21. バックアップと復元
PGSQL のバックアップと復元は非常に簡単で、ポイントインタイムの復元操作は SQL Server よりも高速です。フル バックアップ、wal アーカイブ バックアップ (増分)。3 ノードの PGSQL マスター/スレーブ クラスターがある場合は、いずれかのノードでフル バックアップと wal アーカイブ バックアップを実行できます。
MySQL バックアップと復元は比較的簡単です 単純すぎます。完全バックアップ binlog バックアップ (増分) 完全バックアップには、物理バックアップ用の percona の XtraBackup ツールが必要です。MySQL 自体は物理バックアップをサポートしていません。ポイントの復元操作手順は面倒で複雑です。22. パフォーマンス ビュー
PGSQL は pg_stat_statements プラグインをインストールする必要があります。pg_stat_statements プラグインは、イベントの待機、システム統計などの豊富なパフォーマンス ビューを提供します。欠点は、プラグインをインストールするには、データベースを再起動し、データベースからパフォーマンス情報を収集する必要があります。create extension pg_stat_statements コマンドを実行する必要があります。そうしないと、パフォーマンス情報が収集されず、さらに面倒です。
MySQL には、 PS ライブラリでは、デフォルトでは多くの機能がオンになっていません。PS ライブラリのパフォーマンス ビュー機能をオンにするとパフォーマンスに影響します (例: メモリ使用量による OOM バグ)23インストール方法
PGSQL には、各種プラットフォーム用の rpm パッケージ、deb パッケージなどがあり、MySQL に比べてバイナリがありません パッケージはソースコードとともにコンパイルしてインストールされるのが一般的です。
MySQL には、さまざまなプラットフォーム用の rpm パッケージ、deb パッケージなどが用意されています。ソース コードがコンパイルされてインストールされ、バイナリ パッケージがインストールされます。一般的にはバイナリ パッケージが使用されます。インストールは高速で、便利な24. DDL 操作
PGSQL は、テーブルをロックせずにフィールドを追加し、可変長フィールド タイプの長さを変更します。すべての DDL 操作は必要ありません。サードパーティ ツールのヘルプや商用データベースと同様に、DDL 操作をロールバックしてトランザクションの一貫性を確保できます
MySQL. フィールドの追加や変数の長さの変更など、ほとんどの DDL 操作はテーブルをロックするため、長さフィールドの型。したがって、操作を完了し、特に大きなテーブルに対する DDL 操作の影響を最小限に抑えるには、percona-toolkit の pt-online-schema-change ツールを使用する必要があります。DDL 操作はロールバックできません#25. 大型バージョンのリリース速度##
PGSQLPGSQL は毎年メジャー バージョンをリリースします。メジャー バージョンのリリース後 2 年目に本番環境に導入できます。バージョンの反復速度は非常に高速です。PGSQL 9.6 の正式バージョンは 2016 年にリリースされました。 PGSQL 10 の正式バージョンは 2017 年にリリースされました。 PGSQL 11 の正式バージョンは 2017 年にリリースされました。 リリース時期: 2018 PGSQL 12 正式バージョンのリリース時期: 2019
MySQL メジャーになるには通常 2 ～ 3 年かかりますリリースされる MySQL のバージョン. 一般に、問題を避けるために、メジャー バージョンはリリース後 2 年以内にのみ運用環境に導入できます. ピット、バージョンのリリース速度は比較的遅い. MySQL5.5 の正式バージョン2010 年にリリースされました。MySQL5.6 の正式バージョンは 2013 年にリリースされました。MySQL5.7 の正式バージョンは 2015 年にリリースされました。MySQL8.0 の正式バージョンは 2018 年にリリースされました。
26. 戻り構文
PGSQL は戻り構文をサポートし、戻り句は DML 戻り結果セットをサポートし、クライアント <-> DB サーバー インタラクションを 1 つ削減します
MySQL は戻り構文をサポートしません
27. 内部アーキテクチャ
PGSQL マルチプロセスアーキテクチャでは、Oracle と同様に同時接続数が多すぎることはできません。多くの最適化方法 例: ラージ ページ メモリを有効にする
#MySQL マルチスレッド アーキテクチャ マルチスレッド アーキテクチャですが、接続数には公式の制限があります。システムの同時実行性に制限があります。スレッドが多すぎると、システムが損傷します。処理能力が低下します。接続数が増加すると、パフォーマンスが低下します。一般に、一度に処理できるデータベース接続は 200 ～ 300 のみです。同時に28. クラスター化インデックス
PGSQL 自体の MVCC 実装メカニズムが原因で、PGSQL はクラスター化インデックスをサポートしませんMySQL はクラスター化インデックスをサポートします29. アイドル トランザクション終了関数
PGSQL は、アイドル トランザクションを終了するために idle_in_transaction_session_timeout パラメーターを設定します。たとえば、アプリケーション コードで開いているトランザクションを閉じるのを忘れた場合、PGSQLこのタイプのセッション トランザクションは自動的に検出され、強制終了されますMySQL はアイドル状態のトランザクションを終了する機能をサポートしていません30. 非常に大きなデータ量への対処
#PGSQL は非常に大量のデータに対応できません。PGSQL 自体の MVCC 設計上の問題により、ガベージ コレクションが必要です。最適化は後続のメジャー バージョンでのみ期待できます。 MySQL は非常に大量のデータに対応できません。 、MySQL 自体のアーキテクチャに問題があります31. 分散型進化
PGSQLHTAP データベース: CockroachDB、Tencent Tbase シャーディング クラスター: Postgres-XC、Postgres-XLMySQLHTAP データベース: TiDB シャーディング クラスター: さまざまなミドルウェア、多すぎて 1 つずつリストすることはできません32. データベース ファイル名と命名規則
PGSQLPGSQL この点は十分に行われていません。オペレーティング システム レベルでのデータベースのファイル名と命名規則 (データベースが停止しているとき)、ファイルの数、およびファイルのサイズを明確に確認することができません。オペレーティング システムのファイルが失われたり、ハードディスクが損傷したりすると、 、名前も分からないので、回復するのは非常に困難です。 PGSQL テーブル データの物理ファイルの命名/格納規則は、テーブル スペースの下では、テーブル スペースが作成されていない場合、デフォルトになります。ベースフォルダーであるテーブルスペース。例: /data/base/16454 /3599base: デフォルトのテーブルスペース pg_default が配置されている物理フォルダー 16454: テーブルが配置されているデータベースの oid 3599: の oidもちろん、テーブルのサイズが 1GB を超えると、テーブルの fsm ファイルや vm ファイルに加えて、複数の物理ファイルが生成されるため、大きなテーブルには実際には複数の物理ファイルが存在します。データ ファイルのレイアウト コンテンツが多い場合、関連情報を確認できます。もちろん、これをすべて PGSQL のせいにすることはできません。DBA として、データベースのバックアップと災害復旧を常に実行する必要があります。それが正しい方法です。メディア リカバリは通常、次のように実行されます。最後の手段。MySQL データベース名はフォルダ名です。データベース フォルダの下にはテーブル データ ファイルがあります。各テーブルには対応する frm ファイルと ibd ファイルがあります。メタデータとテーブル/インデックス データを明確に保存します。メディアのリカバリやテーブルスペースの転送に非常に便利です33. 権限の設計
PGSQLPGSQL は、アクセス許可の設計という点で非常に注意が必要です。インスタンスのアクセス許可とテーブル スペースのアクセス許可は別として、PGSQL のアクセス許可レベルは SQL Server に少し似ています。db=》schema=》object はアクセス許可について説明します。ここでお話したいと思います。 Oracle について。Oracle を使用します。例えて言うと、ORACLE 12C より前では、インスタンスとデータベースは 1 対 1 でした。つまり、インスタンスは 1 つのデータベースのみを持つことができます。MySQL や SQL Server とは異なり、インスタンスは複数のデータベースを持つことができ、データベースを自由にクエリできます。PGSQL はデータベースをまたがることはできません。データベース クエリの理由も同じです。PGSQL では複数のデータベースを構築できます。ORACLE と同様に、複数のインスタンスがあります (前述のインスタンスとデータベースは 1 対 1 です)。 PGSQL では複数のインスタンスが許可されているため、1 つのデータベースは 1 つのインスタンスに相当します。そのため、PGSQL の 1 つのインスタンスはインスタンスとは呼ばれず、クラスターと呼ばれます。クラスターの概念については、PGSQL の関連情報を確認できます。 PGSQL のインスタンス/データベースのスキーマはデータベースに相当するため、このスキーマの概念は MySQL のデータベースに相当します。 注: データベースはインスタンスに相当するため、PGSQL では複数のインスタンス/データベースが許可されます。論理的に互いに分離されています。問題は、PGSQL クラスター内のすべてのデータベースに対して一度に操作を実行できず、1 つずつ実行する必要があることです。前述の pg_stat_statements プラグインをインストールするなど、データベースごとに操作してください。 PGSQL クラスター内のすべてのデータベースからパフォーマンスを収集する必要がある場合は、load コマンドを 1 つずつ実行する必要があります。たとえば、データベース間のクエリには dblink プラグインまたは fdw プラグインが必要です。2 つのデータベース間のクエリは、クエリと同等です。 2 つのインスタンス間で実行されます。インスタンスがまたがっているため、dblink プラグインまたは fdw プラグインが必要で、原理は非常に単純です。権限操作もデータベースごとに実行されます。もう 1 つは PGSQL です。 SQL Server の db=》schema=》object の権限階層に似ていますが、実際には SQL Server よりも複雑です。また、新しく作成したテーブルは PGSQL で別途権限を与える必要があります。ロールとユーザーは同じなので、初心者ユーザー向け 彼は、違いが分からないこともあり、ロールの使い方も分からないため、PGSQL はパーミッションの設計という点で非常に難しいと述べました。
MySQL は以下の 5 つのパーミッション テーブルを使用します。権限マッピングを行うための mysql ライブラリ (これは単純です) 明確ですが、唯一の問題は、権限ロール、ユーザー テーブル、db テーブル、ホスト テーブル、tables_priv テーブル、columns_priv テーブル
34. 開発履歴
PGSQL 1995 年、開発者の Andrew Yu と Jolly Chen は SQL (Structured Query Language、構造化照会言語) 変換プログラムを Postgres に追加しました。このバージョンは Postgres95 と呼ばれ、オープン ソース コミュニティでリリースされています。 1996 年に Postgres95 に再度大きな変更が加えられ、PostgresSQL バージョン 6.0 としてリリースされ、PostgresSQL の名前が決定しました。1995 年から数えると約 24 年の歴史があります。 1996 年 2009 年に MySQL 1.0 がリリースされましたが、これは少数の人々のみが利用でき、内部リリースに相当しました。 1996 年 10 月に MySQL 3.11.1 がリリースされました (MySQL には 2.x バージョンはありません)。当初は Solaris オペレーティング システムでバイナリ バージョンのみが提供されていました。1 か月後に Linux バージョンが登場しました。1996 年から数えて、約 23 年の歴史があります。
[関連する推奨事項:
mysql ビデオ チュートリアル以上がpostgresqlとmysqlの違いは何ですかの詳細内容です。詳細については、PHP 中国語 Web サイトの他の関連記事を参照してください。
![[Web フロントエンド] Node.js クイック スタート](https://img.php.cn/upload/course/000/000/067/662b5d34ba7c0227.png)
