Tuesday, January 28, 2014

Utilice el índice incluso con un varchar | | caracteres

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

Hace poco me di cuenta de un post en el forums.mysql.com sitio: Cómo búsqueda rápida en 3 millones de registro? 
El ejemplo que utiliza un LIKE '% eed' 

Eso no será aprovechado de un índice y hará un escaneo completo de tabla. 
A continuación se muestra un ejemplo que utiliza la base de datos mundial, por lo que no de 3 millones de discos, pero tratando de mostrar cómo funciona. 

> 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 |
+------+------------------------+-------------+----------------+------------+
Para mostrar el punto más 

> 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) 

La salida de explicación anterior muestra que no se utilizan índices. 

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
<

Así que para las muecas pongamos una tecla en el campo varchar. Note que no pongo una tecla en todo el rango de sólo los primeros caracteres. Esto es, por supuesto, depende de sus datos. 

> 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

Lo mismo ocurrirá con esta siquiera importa? 

> 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) 

No, no importa, porque el LIKE '% presa' obligará a un análisis completo de todos modos. 

> 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) 

Note la diferencia en el resultado de explicar anteriormente. Esta consulta utiliza un índice.No está utilizando el nombre que el índice pero que está utilizando un índice. Entonces, ¿cómo puede usted tomar ventaja del índice 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) 

La consulta anterior se utilizará el índice name_key. 

El punto es que usted tiene que tener cuidado de la forma de escribir la consulta SQL y asegurarse de que se ejecuta explica a encontrar el mejor índice de elección para su búsqueda.

Sunday, January 19, 2014

Puede replicación MySQL ponerse al día

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

Así que la replicación se ha mejorado recientemente en MySQL 5.6. Sin embargo, la gente sigue utilizando 5.1 y 5.5 por lo que algunas de estas mejoras tendrán que esperar para golpear el mundo real.

Recientemente ayudé a paso en esta dirección con una solución de replicación de geo-localizada. Una parte del país tenía un servidor MySQL 5.1 y la otra parte del país tuvo un nuevo servidor MySQL 5.6 instalado.

Después de lidiar con los problemas de obtener la copia de seguridad inicial de los datos desde el primario al servidor secundario (tardó varias horas para decir lo menos), tuve que decidir podría replicación ponerse al día y mantener el ritmo. El servidor principal tenía algunos grandes consultas y optimización es siempre un buen lugar para empezar. Tuve que hacer el servidor secundario tirando y aplicar lo más rápido que pude primero sin embargo.

Así que aquí hay algunas cosas que debe revisar y tener en cuenta cuando se trata de la réplica. He añadido algunos enlaces de abajo que ayudan a apoyar mis pensamientos mientras trabajaba en esto.

La replicación puede ser muy de E / S pesada. Dependiendo de su aplicación. Un sitio blog no tiene que muchas escrituras por lo que la replicación de E / S es la luz, pero un servidor primario en gran medida por escrito y actualizado va a conducir a un servidor de replicación escribir mucho relay_logs y binary_logs si están habilitadas. Los logs binarios pueden ser activados en la secundaria que le permite ejecutar copias de seguridad o usted puede ser que este servidor sea un primario a otros.

Dividí los registros en una partición de datos diferente del directorio de datos.
Esto se establece en el archivo my.cnf - relay-log

El buffer de InnoDB ya se estableció en un valor de más de 10 GB. Esto fue suficiente para este servidor.
El camarero fue más de 90.000 segundos por detrás todavía.

Así que empecé a hacer algunos ajustes en el servidor y terminamos con estos ajustes en el final. Concedido cada servidor es diferente.

mysql> select @ @ sync_relay_log_info \ G
*************************** 1. fila ***************************
@ @ Sync_relay_log_info: 0
1 row in set (0.08 sec)

mysql> select @ @ innodb_flush_log_at_trx_commit \ G
*************************** 1. fila ***************************
@ @ Innodb_flush_log_at_trx_commit: 2
1 row in set (0.00 sec)

mysql> select @ @ log_slave_updates \ G
*************************** 1. fila ***************************
@ @ Log_slave_updates: 0

mysql> select @ @ sync_binlog \ G
*************************** 1. fila ***************************
@ @ Sync_binlog: 0
1 row in set (0.00 sec)

mysql> select @ @ max_relay_log_size \ G
*************************** 1. fila ***************************
@ @ Max_relay_log_size: 268435456

Me volví el registro binario fuera como yo supervisé diferentes configuraciones y opciones para ayudar a la replicación de ponerse al día. Me tomó un tiempo. Algunos de los ajustes que ves arriba puede o no se han aplicado a medida que trabajaba dentro de este marco de tiempo. Sin embargo, no ponerse al día en 0 segundos atrás. Ahora usted puede notar que muchos de estos ajustes anteriores se relacionan en y alrededor del registro binario. Así que me encontré una pequeña prueba. Por lo tanto, he reiniciado y permitió a los registros de basura. Me registré en el servidor más tarde y encontró que 10,000 + segundos atrás. Así que una vez más, reinicié y desactivado los registros de basura. Se alcanzó (0 segundos detrás) con el servidor principal en menos de 15 minutos. Solía ​​Aurimas ' herramienta mientras veía a ponerse al día también. Si aún no lo use antes, es una herramienta muy agradable y práctico.

Lo que todo esto significa es que el servidor principal debe ser conforme a ACID. Con esta configuración también está en función del sistema operativo para el caché y limpiar. Este es el servidor se puede utilizar como un servidor de lectura principalmente para alimentar a la información a los demás. También quiere decir que sí, la replicación geo-localizada puede mantenerse al día con un servidor primario.

¿Qué pasa si usted necesita parar el esclavo, se sigue ponerse al día rápidamente?

¿Cómo y por qué te detienes el esclavo es mi primera respuesta. Usted debe entrar en el hábito de usar SLAVE STOP SQL_THREAD , en lugar de SLAVE STOP ; Esto permite que los logs retardados continúen para recopilar datos y no aplicarlo a su servidor principal. Así que si usted puede tomar ventaja de que va a ayudar a reducir el tiempo que toma para que usted pueda rellenar los logs retardados después.

Algunos de lectura adicional para usted:

Saturday, January 4, 2014

El trabajo duro que pasa desapercibido ....

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

Me tomé un momento hoy y ser informado uno de mis distribuciones de Linux. En esta distribución resulta que tengo Percona 5.6 instalado como la base de datos MySQL. He mencionado antes cómo puede configurar su elección de MySQL a través de un repositorio Yum .

Mi punto aquí es, sin embargo, ¿cómo alguna vez las gracias a estas personas por todo el trabajo que hacen?

Muchos de estos repositorios están a cargo de las empresas y estas personas se les paga por lo que hacen. Sin embargo, a través de la observación y en general / preguntas de la encuesta de la Linux (incluyendo Debian / Ubuntu) de la comunidad, la mayoría de la gente no actualizar hasta que esté disponible en su distribución. Sucede que soy una persona que quiera estar al tanto de los arreglos de seguridad y errores, así que tengo el rico repositorio de actualización de la fuente de la mayor frecuencia posible.

Mi punto es, mucho trabajo entra en el envasado de estos archivos para su distribución y en su mayor parte se ve como un trabajo bastante ingrato. Recuerdo los más viejos (no de edad, pero mayores) día de tar y gzip, cuando había que cavar y encontrar las dependencias a ti mismo. -. / Configure .. nop necesitará algo más ir descargue e instale de que vuelva a intentarlo .....

Acabo de actualizar 25 paquetes diferentes en algunos momentos, lo que habría tenido algún tiempo antes. Mientras Yum y Get Apt están lejos de ser nueva, y me suenan como un viejo contador de tiempo aquí, sólo pensé que sería bueno para dar las gracias, a todas las personas que trabajan entre bastidores para hacer que todas nuestras experiencias de Linux, y mucho menos MySQL relacionados instala, más fácil y más suave.

Quiero señalar que Oracle tiene 5,6 paquetes ahora disponibles.


Recuerdo que mi post anterior mencionó que de no haber sido.

Wednesday, January 1, 2014

Un DBA MySQL mira PostgreSQL PostgreSQL part3 Para MySQL

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

Así que recientemente he publicado: Un DBA MySQL mira PostgreSQL y parte 2: MySQL a PostgreSQL .

Este post va a explorar la migración de PostgreSQL a MySQL . Una vez más, el objetivo a largo plazo con estos mensajes han de ser capaces de mostrar cómo funciona la información dentro de las diferentes bases de datos, así como la forma de resolver problemas similares en cada base de datos cuando surgieran ejemplos.

MySQL empuja el MySQL Workbench la herramienta de migración de base de datos. Tengo que admitir que tengo curiosidad por qué la Utilidades MySQL no proporciona una opción de línea de comandos. La entrada en el blog anterior ( parte 2 ) mostró lo fácil la migración a través de línea de comandos para MySQL a PostgreSQL . Tenga en mente que cuando armonización de datos a MySQL Data Engine tiene que ser considerado.

En pocas palabras, si usted va a llevar los datos de nuevo en MySQL desde PostgreSQL una opción rápida es probable que el MySQL Workbench . Pero eso no es una solución global ya que a menudo preferimos quedarnos en nuestras ventanas de terminal. Así que va a hacer lo siguiente:
  • Volcar el esquema de PostgreSQL en un archivo
    • Revisar y editar el archivo de MySQL.
  • Per esquema y las tablas que desee exportar como un archivo csv.
  • Importar de nuevo en MySQL

De todos modos, primero tenemos todavía los datos en PostgreSQL desde la base de datos Mundial ejemplo.

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=> 


Vacíe el esquema:

$ pg_dump -s world > world_schema.pgsql 


Usando pg_dump tomar el - de sólo los datos y - inserta simplemente crear archivos estándar SQL de datos.

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

Usted verá más adelante que hacer un volcado por mesa sería mejor, pero esto funciona.

Creación de una base de datos en MySQL para colocar los datos de nuevo, así como poner a prueba su nuevo esquema.

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


Edite su archivo de esquema: vi world_schema.pgsql
Usted tiene la nueva base de datos MySQL creada para que pueda probarlos a medida que avanza.


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); 


Usted tendrá que revisar el archivo para todas las claves relacionadas para que pueda crear afirmaciones válidas.
Usted tendrá que entender MySQL para que pueda crear afirmaciones válidas CREATE TABLE.


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`)
); 

Es, por supuesto, depende de usted. pero una vez que se resuelve la PRIMARY KEY por tabla, me gustaría crear declaraciones alter para actualizar los nuevos esquemas para que pueda asegurarse de que captura todo. Si bien todos ellos pueden ser añadidos directamente a la primera sentencia CREATE para la mayor parte como se procesa el archivo haciendo Postgresql altera puede mantener a raya volcado.

Algunos ejemplos de las sentencias ALTER necesarios:

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`) 


Una vez que todo el esquema es actualizada y válida. usted puede poner los datos guardados.

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; 

Copie los archivos a cabo por mesa en este caso debido a las restricciones. Editar en consecuencia para cada archivo sólo contiene los datos por mesa. Debería haber tirado así o simplemente volcar de nuevo por tabla.

$ 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 


Así que en pocas palabras, no es tan fácil, debo decir automatizado, para migrar a MySQL a través de la línea de comandos debido a los cambios de esquema que requerirán su atención, pero se puede hacer. 

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

MySQL Workbench de migración de base de datos, por supuesto, puede hacer el mismo proceso y se puede aprender más sobre esta herramienta aquí -http://www.mysql.com/products/workbench/migrate/ 

Un DBA MySQL mira PostgreSQL part2: MySQL a PostgreSQL

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

Así que recientemente he publicado: Un DBA MySQL mira PostgreSQL

Este post va a explorar la migración de MySQL a PostgreSQL . Pronto voy a seguir con unaPostgreSQL migración de regreso a MySQL . El objetivo a largo plazo con estos mensajes es mostrar cómo funciona la información dentro de las diferentes bases de datos, así como la forma de resolver problemas similares en cada base de datos, cuando debería surgir.

Para las migraciones Voy a usar el ejemplo de uso frecuente: la base de datos del mundodisponibles en dev.mysql.com .

También voy a reconocer esto, tengo más experiencia con MySQL a PostgreSQL . PostgreSQLDBA podría escribir y recomendar diferentes soluciones a este tipo de situaciones. Este es también un ejemplo muy sencillo.

En primer lugar para asegurar que este proceso es de principio a fin:


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 


Así que ahora vamos a ver si el PostgreSQL base de datos configurado y listo.

# 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 


Este script de perl sencilla ( mysql2pgsql.perl ) ayuda a que el proceso de migración deMySQL a PostgreSQL .


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


Reúna los MySQL de datos y tenerlo listo.

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 

..
INSERT 0 1
AVISO: Las cascadas de caída a otros 2 objetos
DETALLE: caer en cascada a la restricción en la mesa countrylanguage_countrycode_fkey countrylanguage
caer en cascada a la restricción city_countrycode_fkey en la mesa de la ciudad
..
INSERT 0 1
INSERT 0 1
DROP TABLE
CREATE TABLE
INSERT 0 1
INSERT 0 1
..
INSERT 0 1
CREATE INDEX
ALTER TABLE


Así que vamos a ver lo que tenemos.


$ 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) 


mundo => select count (ID) de la Ciudad;
contar
-------
4079
(1 row)

mundo => select * from límite de la ciudad de 10;
Identificación | nombre | código del país | barrio | población
---- + ------------------------------------- + ------- ------ + ---------------------- + ------------
1 | Kabul | AFG | Kabol | 1780000
2 | Qandahar | AFG | Qandahar | 237500
3 | Herat | AFG | Herat | 186800
4 | Mazar-e-Sharif | AFG | Balkh | 127800
5 | Amsterdam | NLD | Holanda del Norte | 731200
6 | Rotterdam | NLD | Zuid-Holland | 593321
7 | Haag | NLD | Zuid-Holland | 440900
8 | Utrecht | NLD | Utrecht | 234323
9 | Eindhoven | NLD | Noord-Brabant | 201843
10 | Tilburg | NLD | Noord-Brabant | 193238
(10 filas)

mundo => \ dt + City
Lista de las relaciones
Esquema | Nombre | Tipo | Propietario | Tamaño | Descripción
-------- + ------ + ------- + ---------- + -------- + ------ -------
público | ciudad | Mesa | testuser | 432 kB |
(1 row)


Pues los recuentos coinciden y los datos están disponibles. Pero ahora quiero ver la versión MySQL de un "SHOW CREATE TABLE"; Tenga en cuenta que en MySQL CREATE DATABASE y CREATE SCHEMA son básicamente la misma cosa.


$ 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
-- 


Como se puede ver para ver la tabla es el mismo que un comando mysqldump
$ Mysqldump-u root-p - NO_DATA - mundo de base de datos - tablas City
Más trabajo que un típico MySQL está acostumbrado a tener que hacer sólo para ver la estructura de la tabla.

Sin embargo, nuestros datos y el esquema se mueve encima en PostgreSQL desde MySQL .

Otro post pronto por venir ... Si lo mueve hacia atrás.