2014年1月28日火曜日

でも、varchar型を使用してインデックスを使用してください| | CHAR

Original post: http://anothermysqldba.blogspot.com/2014/01/use-your-index-even-with-varchar-char.html

私は最近、上のポストに気づいforums.mysql.comのサイトを: 3百万レコードを検索する早送りするには? 
与えられた例は、LIKE '%のEED」を使用 

つまり、インデックスを活用していないし、全表スキャンを行います。 
下の世界のデータベースを使用した例ですが、そうではない300万たレコードが、ちょうどそれがどのように動作するかを示すためにしようとしています。 

> explain select * from City where Name LIKE '%dam' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4188
Extra: Using where
1 row in set (0.01 sec)

[world]> select count(*) FROM City;
+----------+
| count(*) |
+----------+
| 4079 |
+----------+

> select * from City where Name LIKE '%dam';
+------+------------------------+-------------+----------------+------------+
| ID | Name | CountryCode | District | Population
+------+------------------------+-------------+----------------+------------+
| 5 | Amsterdam | NLD | Noord-Holland | 731200 |
| 6 | Rotterdam | NLD | Zuid-Holland | 593321 |
| 1146 | Ramagundam | IND | Andhra Pradesh | 214384 |
| 1318 | Haldwani-cum-Kathgodam | IND | Uttaranchal | 104195 |
| 2867 | Tando Adam | PAK | Sind | 103400 |
| 3122 | Potsdam | DEU | Brandenburg | 128983 |
+------+------------------------+-------------+----------------+------------+
さらにポイントを表示するには 

> explain select * from City where Name LIKE '%dam%' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4188
Extra: Using where
1 row in set (0.00 sec)

> select * from City where Name LIKE '%dam%';
+------+------------------------+-------------+----------------+------------+
| ID | Name | CountryCode | District | Population |
+------+------------------------+-------------+----------------+------------+<
| 5 | Amsterdam | NLD | Noord-Holland | 731200 |
| 6 | Rotterdam | NLD | Zuid-Holland | 593321 |
| 380 | Pindamonhangaba | BRA | São Paulo | 121904 |<
| 625 | Damanhur | EGY | al-Buhayra | 212203 |
| 1146 | Ramagundam | IND | Andhra Pradesh | 214384 |
| 1318 | Haldwani-cum-Kathgodam | IND | Uttaranchal | 104195 |
| 1347 | Damoh | IND | Madhya Pradesh | 95661 |
| 2867 | Tando Adam | PAK | Sind | 103400 |
| 2912 | Adamstown | PCN | – | 42 |
| 3122 | Potsdam | DEU | Brandenburg | 128983 |
| 3177 | al-Dammam | SAU | al-Sharqiya | 482300 |
| 3250 | Damascus | SYR | Damascus | 1347000 |
+------+------------------------+-------------+----------------+------------+<
12 rows in set (0.00 sec) 

上記のExplain出力は、インデックスが使用されていないことを示しています。 

CREATE TABLE `City` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`Name` char(35) NOT NULL DEFAULT '',
`CountryCode` char(3) NOT NULL DEFAULT '',
`District` char(20) NOT NULL DEFAULT '',
`Population` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`ID`),
KEY `CountryCode` (`CountryCode`),
CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`)
) ENGINE=InnoDB
<

だから、にやにや笑いのために私たちはVARCHARフィールドにキーを入れてみましょう。 私は最初の数文字範囲全体にキーを入れないで注意してください。 もちろんこれは、データに依存している。 

> ALTER TABLE City ADD KEY name_key(`Name`(5));
Query OK, 0 rows affected (0.54 sec)

CREATE TABLE `City` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`Name` char(35) NOT NULL DEFAULT '',
`CountryCode` char(3) NOT NULL DEFAULT '',
`District` char(20) NOT NULL DEFAULT '',
`Population` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`ID`),
KEY `CountryCode` (`CountryCode`),
KEY `name_key` (`Name`(5)),
CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`)
) ENGINE=InnoDB

だから、これはあっても関係あります? 

> explain select * from City where Name LIKE '%dam' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ALL
possible_keys: NULL
key: NULL
key_len: NULL
ref: NULL
rows: 4188
Extra: Using where
1 row in set (0.00 sec) 

いいえ、それが原因LIKE '%ダム」に関係なく、フルスキャンを強制的に、問題ではありません。 

> EXPLAIN select * from City where Name LIKE '%dam' AND CountryCode = 'IND' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: ref
possible_keys: CountryCode
key: CountryCode
key_len: 3
ref: const
rows: 341
Extra: Using index condition; Using where
1 row in set (0.00 sec) 

上記のExplain出力の違いに注目してください。 このクエリは、インデックスを使用しています。 これは、指標として名前を使用していないが、それはインデックスを使用している。 それでは、どのようにvarchar型のインデックスを利用することができますか? 

> EXPLAIN select * from City where Name LIKE 'Ra%' \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: City
type: range
possible_keys: name_key
key: name_key
key_len: 5
ref: NULL
rows: 35
Extra: Using where
1 row in set (0.00 sec) 

上記のクエリはname_keyインデックスを使用します。 

ポイント幸福を使用すると、SQLクエリを記述して、クエリのための選択の最適なインデックスを見つけるために説明して実行されるようには注意しなければならないことである。

2014年1月20日月曜日

MySQLのレプリケーションは追いつくことができます

Original post: http://anothermysqldba.blogspot.com/2014/01/can-mysql-replication-catch-up.html

だから、複製は、最近のMySQL 5.6で改善された。 しかし、人々はまだ5.1および5.5を使用しているので、それらの改善点のいくつかは、現実の世界をヒットするのを待つ必要があります。

私は最近、地理位置レプリケーションソリューションでこの方向に移動しました。 国の一部は、MySQL 5.1のサーバを持っていたし、国の他の部分は、新しいMySQL 5.6サーバがインストールされていた。

(控えめに言っても、数時間かかった)セカンダリサーバにプライマリから初期データのバックアップを取得する問題に対処した後、私は追いつくの複製とついていく可能性が決めなければならなかった。 プライマリサーバはいくつかの大きなクエリを持っていたし、最適化が常に起動するには良い場所です。 私は、セカンダリサーバが引っ張って速く私も最初にできる限り適用しなければならなかった。

だからここにチェックして、レプリケーションになると心に留めておくべきいくつかあります。 私はこの上で働いていたように私の思考のための支援を、以下のいくつかのリンクを追加した。

レプリケーションは非常にI / Oの重いことができます。 アプリケーションによっては。 ブ ログサイトでは、多くの書き込みがレプリケーションのI / Oに光であることはありませんが、頻繁に書かれており、更新されたプライマリサーバは、それらが有効になっている場合relay_logsと binary_logsをたくさん書いてReplication Serverにつながるとしている。 バイナリログには、バックアップを実行するか、このサーバが他の人にプライマリにするかもしれない可能にするために、セカンダリ上で有効にすることができます。

私は、データディレクトリとは別のデータ·パーティションにログを分割します。
これは、my.cnfファイルに設定されているリレーログ-

InnoDBのバッファプールは既に10GB以上の値に設定されました。 これは、このサーバーのたくさんいた。
サーバーは背後に90,000秒であった。

だから私は、サーバーにいくつかの調整を行うために開始され、最終的にはこれらの設定になってしまった。 付与されたすべてのサーバーが異なっている。

MySQLの>を@ sync_relay_log_info \ G
*************************** 1。 行***************************
@ @ sync_relay_log_info:0
セット内の1行(0.08秒)

MySQLの> @選択innodb_flush_log_at_trx_commit \ G
*************************** 1。 行***************************
@ @ innodb_flush_log_at_trx_commit:2
セット内の1行(0.00秒)

MySQLの> @選択log_slave_updates \ G
*************************** 1。 行***************************
@ @ log_slave_updates:0

MySQLの> @選択sync_binlog \ G
*************************** 1。 行***************************
@ @ sync_binlog:0
セット内の1行(0.00秒)

MySQLの> @選択max_relay_log_sizeを \ G
*************************** 1。 行***************************
@ @ max_relay_log_sizeを:268435456

私は、レプリケーション·キャッチアップを支援する様々な設定やオプションをモニターして、私はバイナリログがオフになっています。 それはしばらく時間がかかった。 私はこの時間枠内で働いていたとして、あなたは上記を参照の設定の一部は、または適用されていない場合があります。 まだそれは戻って0秒に追いつくでした。 今、あなたは、これらの設定の多くは、上記のバイナリログとその周辺関連していることに気づくかもしれません。 だから私は少しのテストを実行しました。 だから、私はビンログを再起動し、使用可能に。 私は後で、サーバー上でチェックインし、万秒以上の背後にそれを発見した。 だから私は、もう一度再起動し、binログを無効に。 これは、15分以内のプライマリサーバと(0秒の後ろ)に追いついた。 私はAurimas「使用ツールは 、私はそれは同様に追いつく見守る。 あなたが前にそれを使用していない場合、それは非常に素晴らしく、便利なツールです。

これは是非、プライマリサーバが、ACID準拠している必要がありますです。 このセットアップを使用すると、キャッシュ用のOSに依存し、クリーンアップしている。 これは、サーバーが他の人に情報を供給するための主リードサーバとして使用されている。 また、はい、地理位置レプリケーションがプライマリサーバで最新の状態に保つことができることを意味します。

あなたは、スレーブを停止する必要がある場合は、それはまだすぐに何を追いつくだろうか?

どのように、なぜあなたは、スレーブを停止しないのは、私の最初の反応である。 あなたが使用することの習慣を身に取得する必要があり、STOP SLAVE SQL_THREADを 、代わりに、STOP SLAVE ;これはリレーログがデータを収集し、ちょうどあなたのプライマリサーバに適用しないように続けることができます。 だから、それは後でリレーログを移入するのにかかる時間を短縮することを利用することができます。

あなたのためのいくつかの追加の読書:

2014年1月4日土曜日

見過ごされて行くハードワーク....

Originally posted: http://anothermysqldba.blogspot.com/2014/01/hard-work-that-goes-unnoticed.html

今日は瞬間を取り、私のLinuxディストリビューションのいずれかを更新した。 この分布では、私はPercona 5.6は、MySQLデータベースとしてインストールされているために起こる。 私はあなたのお好みに設定できますか前に言及しているのYumリポジトリを経由してMySQLを

ここに私のポイントは、しかしである、どのように我々は、これまで彼らが行うすべての作業のためにこれらの人々に感謝しますか?

これらのリポジトリの多くは、企業が実行され、これらの人々は、彼らが何のために支払いを受ける。 それは彼らのディストリビューションに利用可能になるまで、まだ、地域社会(のDebian / Ubuntuのを含む)は、Linuxの調査の一般的な観察/質問を通じて、人々の大半はアップグレードされません。 私はセキュリティとバグ修正の上に滞在したい方に起こるので、私はyumを持つリポジトリできるだけ頻繁に元からアップデートを。

私のポイントは、多くの作業を配布するため、これらのファイルのパッケージングになり、ほとんどの部分は、それはかなり報われない仕事のように見え、ある。 あなた自身を掘ると依存関係を見つけなければならなかったとき、私は、tarとgzipの古い(古いが、古いではない)日々を思い出す。 - 。/ configureを.. いや、ダウンロードを行って、それをインストールして何か他のものを必要とし、再試行してください.....

私は前にいくつかの時間がかかったでしょうしばらくすると25種類のパッケージを、アップグレードした。 ヤ ムやapt取得が遠く新品であり、私はここで、古いタイマーのような音が、私はちょうどそれが私たちのLinuxの経験のすべてを作るために舞台裏で働く すべての人々のおかげで、と言う、おろかはいいかもしれないと思った関連MySQLは、簡単かつスムーズにインストールされます。

私はOracleが利用可能になりました5.6のパッケージを持っていることを指摘します。


私は私のことを思い出して、以前の投稿は、それがされていなかったか述べた。

2014年1月2日木曜日

MySQLのDBAは、MySQLへのPostgreSQLの第3部のPostgreSQLを見て

Original post: http://anothermysqldba.blogspot.com/2014/01/a-mysql-dba-looks-at-postgresql-part3.html

だから私は最近投稿: MySQLはデータベース管理者は、PostgreSQLを見てパート2:MySQLをPostgreSQLへの 。

この記事はからの移行を検討しますPostgreSQLのMySQLを 。 もう一度、これらのポストに長期的な目標は、データが異なるデータベース内でどのように動作するだけでなく、例が発生するタイミングを各データベースで同じような問題を解決する方法ができるショーされることになる。

MySQLはプッシュMySQLのワークベンチのデータベースの移行のためのツールです。 私は、なぜ私は好奇心旺盛だということを認めざるを得ないのMySQLユーティリティのコマンドラインオプションを提供しません。 以前のブログの記事( パート2 )コマンドラインからの移行がためだったどのように簡単に示したのMySQLへのPostgreSQLの 。 バックアップするデータを持って来るときにかかわらず、心に留めておくのMySQLデータエンジンを考慮しなければならない。

簡単に言えば、あなたが戻ってにデータを取り込むしようとしている場合はMySQLからPostgreSQLを fastオプションは、可能性がありますMySQLのワークベンチ 。 私たちはしばしば私たちのターミナルウィンドウ内にとどまることを好むので、しかし、それは全体的な解決策ではありません。 だから、次の操作を実行します。
  • からのスキーマダンプPostgreSQLをファイルに
    • MySQLのファイルを確認し、編集します。
  • 目的のスキーマとテーブルごとにCSVファイルとして実施エクスポートします。
  • 背中へのインポートMySQLの

とにかく、最初に我々はまだデータがあるのPostgreSQLからの世界データベースの例を。

world=> \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------+-------+----------
public | city | table | testuser
public | country | table | testuser
public | countrylanguage | table | testuser
(3 rows)

world=> select count(ID) from City;
count
-------
4079
(1 row)

world=> 


スキーマをダンプ:

$ pg_dump -s world > world_schema.pgsql 


データ専用と - - 取るpg_dumpの使用は、単にデータの標準SQLファイルを構築するために挿入されます。

pg_dump --data-only --inserts world > world_data.pgsql 

あなたは、テーブルごとにダンプを行うことは、より良いだろうと後でわかりますが、これは動作します。

MySQLでデータベースを作成すると、バックデータを置くだけでなく、あなたの新しいスキーマをテストします。

mysql> CREATE DATABASE world_back;
Query OK, 1 row affected (0.01 sec) 


スキーマファイルを編集します。VI world_schema.pgsql
あなたは、あなたが行くようにあなたがそれらをテストすることができますように、新しいMySQLデータベースが作成されました。


CREATE TABLE city (
id integer DEFAULT nextval('city_id_seq'::regclass) NOT NULL,
name character(35) DEFAULT ''::bpchar NOT NULL,
countrycode character(3) DEFAULT ''::bpchar NOT NULL,
district character(20) DEFAULT ''::bpchar NOT NULL,
population integer DEFAULT 0 NOT NULL
);

CREATE TABLE country (
code character(3) DEFAULT ''::bpchar NOT NULL,
name character(52) DEFAULT ''::bpchar NOT NULL,
continent character varying DEFAULT 'Asia'::character varying NOT NULL,
region character(26) DEFAULT ''::bpchar NOT NULL,
surfacearea double precision DEFAULT 0::double precision NOT NULL,
indepyear smallint,
population integer DEFAULT 0 NOT NULL,
lifeexpectancy double precision,
gnp double precision,
gnpold double precision,
localname character(45) DEFAULT ''::bpchar NOT NULL,
governmentform character(45) DEFAULT ''::bpchar NOT NULL,
headofstate character(60) DEFAULT NULL::bpchar,
capital integer,
code2 character(2) DEFAULT ''::bpchar NOT NULL,
CONSTRAINT country_continent_check CHECK (((continent)::text = ANY ((ARRAY['Asia'::character varying, 'Europe'::character varying, 'North America'::character varying, 'Africa'::character varying, 'Oceania'::character varying, 'Antarctica'::character varying, 'South America'::character varying])::text[])))
);
ALTER TABLE ONLY city
ADD CONSTRAINT city_pkey PRIMARY KEY (id);

CREATE INDEX city_countrycode_idx ON city USING btree (countrycode); 


有効な文を作成できるように、関連するすべてのキーのファイルを確認する必要があります。
有効なのCREATE TABLE文を作成できるように、MySQLを理解する必要があります。


CREATE TABLE city (
`id` int(11) NOT NULL AUTO_INCREMENT,
`name` char(35) NOT NULL DEFAULT '',
`countrycode` char(3) NOT NULL DEFAULT '',
`district` char(20) NOT NULL DEFAULT '',
`population` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`id`)
);

CREATE TABLE `country` (
`code` char(3) NOT NULL DEFAULT '',
`name` char(52) NOT NULL DEFAULT '',
`continent` char(5) NOT NULL DEFAULT '',
`region` char(26) NOT NULL DEFAULT '',
`surfaceArea` float(10,2) NOT NULL DEFAULT '0.00',
`indepyear` smallint(6) DEFAULT NULL,
`population` int(11) NOT NULL DEFAULT '0',
`lifeexpectancy` float(3,1) DEFAULT NULL,
`gnp` float(10,2) DEFAULT NULL,
`gnpold` float(10,2) DEFAULT NULL,
`localname` char(45) NOT NULL DEFAULT '',
`governmentform` char(45) NOT NULL DEFAULT '',
`headofstate` char(60) DEFAULT NULL,
`capital` int(11) DEFAULT NULL,
`code2` char(2) NOT NULL DEFAULT '',
PRIMARY KEY (`code`)
); 

それはあなた次第のコースです。 あなたは、テーブルごとに主キーをうまくしかし、一度、私はあなたがすべてのものをキャッチすることを確認することができますように、新しいスキーマを更新するには、ALTERステートメントを作成します。 あなたはPostgreSQLが、ファイル変更し、チェックであなたを保つことができることをダンププロセスとして彼らはすべての大部分は最初のCREATE文に直接追加することができますが。

必要なアルター文のいくつかの例:

ALTER TABLE city ENGINE=InnoDB;
ALTER TABLE country ENGINE=InnoDB;
ALTER TABLE countrylanguage ENGINE=InnoDB;

ALTER TABLE country DROP continent;
ALTER TABLE country ADD continent enum('Asia','Europe','North America','Africa','Oceania','Antarctica','South America') NOT NULL DEFAULT 'Asia' AFTER name;

ALTER TABLE city ADD KEY `countrycode` (`countrycode`),
ALTER TABLE city ADD CONSTRAINT `city_ibfk_1` FOREIGN KEY (`countrycode`) REFERENCES `country` (`code`) 


すべてのスキーマが更新され、有効なされたら。 あなたが戻って保存されたデータを置くことができます。

vi world_data.pgsql to remove the SET statements at the top.
--
-- PostgreSQL database dump
--

SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;

SET search_path = public, pg_catalog; 

ための制約この場合、テーブルごとにファイルをコピーします。 編集は、それに応じて、各ファイルは、テーブルごとにデータを持っています。 私はちょうどそのようにダンプまたは単にテーブルごとに再びダンプしておく必要があります。

$ cp world_data.pgsql world_data_city.pgsql
$ cp world_data.pgsql world_data_countrylanguage.pgsql
$ cp world_data.pgsql world_data_country.pgsql

$ mysql -u root -p world_back < world_data_country.pgsql
Enter password:
$ mysql -u root -p world_back < world_data_countrylanguage.pgsql
Enter password:
$ mysql -u root -p world_back < world_data_city.pgsql 


単にそれは簡単ではありません置くので、私は、ので、あなたの注意を必要としますが、それは行うことができ、スキーマの変更がコマンドライン経由でのMySQLへの移行を、自動化されたと言うべきである。 

mysql> select count(id) from city;
+-----------+
| count(id) |
+-----------+
| 4079 |
+-----------+
1 row in set (0.14 sec)

MySQLのワークベンチはもちろん、データベースの移行は、同じプロセスを行うことができますし、ここでそのツールの詳細について学ぶことができます-http://www.mysql.com/products/workbench/migrate/ 

2014年1月1日水曜日

PostgreSQLへのMySQLの:MySQLのDBAは、PostgreSQLのその2を見て

Original post: http://anothermysqldba.blogspot.com/2014/01/a-mysql-dba-looks-at-postgresql-part2.html

だから私は最近投稿: MySQLのDBAは、PostgreSQLのを見て 

この記事はからの移行を検討しますMySQLのPostgreSQLの 。 私はすぐにそれをフォローアップしますPostgreSQLのバックへの移行MySQLの 。 これらのポストに長期的な目標は、データはそれが生じた場合ときに、各データベースに同じような問題を解決する方法だけでな​​く、異なるデータベース内でどのように機能するかを示すことです。 

:移行のために私は頻繁に使用される例が使用されます世界データベースで利用可能なdev.mysql.comを 。 

私もこれを認めますが、私は、より経験豊富な私はMySQLよりもPostgreSQLが 。 PostgreSQLの DBAが書いて、そのような状況にさまざまなソリューションをお勧めかもしれません。 また、これは非常に単純な例です。 

このプロセスを確実にするために最初の最初から最後までです。 


mysql> create database world;
Query OK, 1 row affected (0.00 sec

# mysql world < world_innodb.sql
mysql> show create table City;
CREATE TABLE `City` (
`ID` int(11) NOT NULL AUTO_INCREMENT,
`Name` char(35) NOT NULL DEFAULT '',
`CountryCode` char(3) NOT NULL DEFAULT '',
`District` char(20) NOT NULL DEFAULT '',
`Population` int(11) NOT NULL DEFAULT '0',
PRIMARY KEY (`ID`),
KEY `CountryCode` (`CountryCode`),
CONSTRAINT `city_ibfk_1` FOREIGN KEY (`CountryCode`) REFERENCES `Country` (`Code`)
) ENGINE=InnoDB

mysql> select count(ID) from City\G
*************************** 1. row ***************************
count(ID): 4079 


だから今私は取得させ、PostgreSQLのデータベースが設定され、準備が整いました。 

# su postgres
$ psql
psql (9.3.2)
Type "help" for help.

postgres=# CREATE DATABASE world;
CREATE DATABASE

# GRANT ALL ON DATABASE world TO testuser;
GRANT 


postgres=# \q 


この単純なPerlスクリプト( mysql2pgsql.perlは )からの移行プロセスを支援するのMySQLのPostgreSQL 。 


# su testuser
$ cd
$ pwd
/home/testuser
$ wget http://pgfoundry.org/frs/download.php/1535/mysql2pgsql.perl 


収集MySQLのデータを、それを準備。 

mysqldump -u root -p world > mysql2postgresql.sql
$ ./mysql2pgsql.perl mysql2postgresql.sql mysql2postgresql.pgsql
table "city" will be dropped CASCADE
"city_id_seq"--
table "country" will be dropped CASCADE
table "countrylanguage" will be dropped CASCADE

$ psql world < mysql2postgresql.pgsql | more
DROP TABLE
DROP SEQUENCE
CREATE SEQUENCE
CREATE TABLE
INSERT 0 1 

..
0 1を挿入
注意:2他のオブジェクトへのドロップカスケード
詳細:テーブルcountrylanguageにcountrylanguage_countrycode_fkey制約カスケードをドロップ
テーブルの街にcity_countrycode_fkey制約カスケードをドロップ
..
0 1を挿入
0 1を挿入
DROP TABLEの
CREATE TABLEを
0 1を挿入
0 1を挿入
..
0 1を挿入
CREATE INDEXの
ALTER TABLEの


だから私たちは、我々が持っているものを見てみましょう。 


$ psql -d world
psql (9.3.2)
Type "help" for help.

world=> \dt
List of relations
Schema | Name | Type | Owner
--------+-----------------+-------+----------
public | city | table | testuser
public | country | table | testuser
public | countrylanguage | table | testuser
(3 rows) 


市から世界=> SELECT COUNT(ID);
カウント
-------
4079
(1行目)

世界=>市の上限10から選択*;
ID |名前|国番号|地区|人口
---- + ------------------------------------- + ------- ------ + ---------------------- + ------------
1 |カブール| AFG | Kabol |178万
2 |カンダハール| AFG |カンダハール| 237500
3 |ヘラート| AFG |ヘラート| 186800
4 |マザリシャリフ| AFG |バルフ| 127800
5 |アムステルダム| NLD |ホラント| 731200
6 |ロッテルダム| NLD |南ホラント| 593321
7 |ハーグ| NLD |南ホラント| 440900
8 |ユトレヒト| NLD |ユトレヒト| 234323
9 |アイントホーフェン| NLD |北ブラバント| 201843
10 |ティルブルグ| NLD |北ブラバント| 193238
(10行)

世界=> \ DT +市
関係のリスト
スキーマ|名前|タイプ|オーナー|サイズ|説明
-------- + ------ + ------- + ---------- + -------- + ------ -------
公共|街|テーブル| testuserと| 432 MB |
(1行目)


さてカウントが一致し、データが入手可能です。 しかし、今私はMySQLバージョン"ショーはCREATE TABLE」を見たいと思って、であることに注意してくださいMySQLのデータベースを作成し、スキーマを作成、基本的には同じものです。 


$ pg_dump -t city -s world
--
-- PostgreSQL database dump
--

SET statement_timeout = 0;
SET lock_timeout = 0;
SET client_encoding = 'UTF8';
SET standard_conforming_strings = on;
SET check_function_bodies = false;
SET client_min_messages = warning;

SET search_path = public, pg_catalog;

SET default_tablespace = '';

SET default_with_oids = false;

--
-- Name: city; Type: TABLE; Schema: public; Owner: testuser; Tablespace:
--

CREATE TABLE city (
id integer DEFAULT nextval('city_id_seq'::regclass) NOT NULL,
name character(35) DEFAULT ''::bpchar NOT NULL,
countrycode character(3) DEFAULT ''::bpchar NOT NULL,
district character(20) DEFAULT ''::bpchar NOT NULL,
population integer DEFAULT 0 NOT NULL
);


ALTER TABLE public.city OWNER TO testuser;

--
-- Name: city_pkey; Type: CONSTRAINT; Schema: public; Owner: testuser; Tablespace:
--

ALTER TABLE ONLY city
ADD CONSTRAINT city_pkey PRIMARY KEY (id);


--
-- Name: city_countrycode_idx; Type: INDEX; Schema: public; Owner: testuser; Tablespace:
--

CREATE INDEX city_countrycode_idx ON city USING btree (countrycode);


--
-- PostgreSQL database dump complete
-- 


あなたは表を参照するように見ることができるようにmysqldumpコマンドと同じです 
$ mysqldumpを-UのルートP - NO_DATA - データベースの世界 - テーブル·シティ 
典型的なよりも多くの作業のMySQLは、単にテーブルの構造を見るために使う必要があるために使用されます。 

しかし、我々のデータとスキーマはに上に移動したPostgreSQLのからMySQLを 。 

すぐに来て別のポスト... それを後退。