Para generar el fichero desde un comando SQL en MySQL deberemos indicar INTO OUTFILE con el nombre de fichero y las siguientes opciones:

• FIELDS TERMINATED BY: Indicamos como terminan los campos, en este caso deben ser separados por comas ‘,’
• OPTIONALLY ENCLOSED BY: Como se deben indicar en el caso que tengan el separador como valor. En este caso mediante comillas dobles ‘”‘
• ESCAPED BY: Indicamos como debemos escapar los carácteres, en este caso mediante la contrabarra ‘\\’
• LINES TERMINATED BY: Indicamos como especificamos una nueva fila, en este caso mediante un intro ‘\n’

Por lo tanto el comando SQL quedaría:

mysql>  select * from loquesea
INTO OUTFILE "/tmp/inventari.txt"
FIELDS TERMINATED BY  ','
OPTIONALLY ENCLOSED BY '"'
ESCAPED BY  '\\'
LINES TERMINATED BY '\n' from RackObject;
Query OK, 168 rows affected (0.29 sec)

Nuestra fuente: Systemadmin.es

Mediante SHOW VARIABLES podemos ver si tenemos la query cache disponible en el servidor de MySQL:

mysql> show variables like 'have_query_cache';
+------------------+-------+
| Variable_name    | Value |
+------------------+-------+
| have_query_cache | YES   |
+------------------+-------+
1 row in set (0.00 sec)

En caso de tenerla disponible deberemos consultar las variables query_cache_sizey query_cache_type para saber si esta habilitada y con que tamaño.

La variable query_cache_type puede tener tres valores:

• 0 o OFF: La query cache esta deshabilitada
• 1 o ON: La query cache esta habilitada para todas las queries menos las que indiquemos con el hint SQL_NO_CACHE
• 2 o DEMAND: La query cache esta deshabilitada para todas las queries menos las que indiquemos con el hint SQL_CACHE

Por otro lado mediante query_cache_size también podemos deshabilitar la query cache, simplemente deberemos definir el tamaño a cero. En caso que definamos un valor positivo en este parámetro, la query cache estará habilitada o no según este definida la query_cache_type.

Nuestra fuente: Systemadmin

Con dicha opción –bootstrap arranca el mínimo de la instancia sin tener disponible ni el socket ni el puerto TCP para conexiones de clientes, sino que únicamente se comunica con el usuario por stdin.

Por lo tanto, deberemos pasar los comandos que queremos que ejecute. Cuando le mandemos el EOF, se cerrará la base de datos y terminará la aplicación. Por ejemplo, con el MySQL apagado ejecutamos el mysqld con la opción bootstap y le mandamos crear una base de datos:

# /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --bootstrap
create database test_single_user;

Finalizando la entrada de comandos con control-D (EOF).

Una vez arranquemos de nuevo el MySQL normalmente, podremos comprobar como se ha ejecutado el comando que hemos indicado:

# mysql
Welcome to the MySQL monitor.  Commands end with ; or \g.
Your MySQL connection id is 1
Server version: 5.5.10-log Source distribution

Copyright (c) 2000, 2010, Oracle and/or its affiliates. All rights reserved.

Oracle is a registered trademark of Oracle Corporation and/or its
affiliates. Other names may be trademarks of their respective
owners.

Type 'help;' or '\h' for help. Type '\c' to clear the current input statement.

mysql> show databases;
+--------------------+
| Database           |
+--------------------+
| information_schema |
| mysql              |
| performance_schema |
| test_single_user   |
+--------------------+
4 rows in set (0.00 sec)

mysql>

Evidentemente, podemos ejecutar más de un comando, siendo de esta forma una buena manera de ejecutar ciertas operaciones delicadas que no queremos que nadie nos pueda molestar:

# /usr/local/mysql/bin/mysqld --defaults-file=/etc/my.cnf --bootstrap
use test_single_user
create table a2 as select * from a1;

Nuestra fuente:  systemadmin.es

En la documentación de MySQL hay un listado de limitaciones del particionamiento de MySQL 5.1. A continuación veremos aplicados algunas de las limitaciones:

Primero de todo supondremos la siguiente tabla:

CREATE TABLE `usuarios` (
  `id` int(11) NOT NULL AUTO_INCREMENT,
  `usuario` varchar(64) NOT NULL,
  `password` varchar(64) NOT NULL,
  PRIMARY KEY (`id`),
  UNIQUE KEY `usuario` (`usuario`)
) ENGINE=MyISAM AUTO_INCREMENT=1645135 DEFAULT CHARSET=utf8;

Con un total de 1.645.134 registros de ejemplo:

mysql> select count(*) from usuarios;
+----------+
| count(*) |
+----------+
|  1645134 |
+----------+
1 row in set (0.00 sec)

Nuestra fuente:systemadmin.es

El patrón de acceso que vamos a suponer es del siguiente tipo de queries:

SELECT usuario, password FROM usuarios where usuario='ejemplo';

La primera limitación que nos encontramos es que no podemos crear particiones usando tipos de datos no numéricos:

mysql> alter table usuarios_part partition by hash(usuario) partitions 8;
ERROR 1491 (HY000): The PARTITION function returns the wrong type

Y tampoco podremos usar una función como LENGTH() para transformar un string en un valor numérico:

mysql> alter table usuarios_part partition by hash(LENGTH(usuario)) partitions 8;
ERROR 1564 (HY000): This partition function is not allowed

Podemos intentar particionar por id, que ya es un valor numérico, pero nos encontraremos con otra limitación de MySQL, los índices no pueden ser globales, sino locales a la partición:

mysql> alter table usuarios_part partition by hash(id) partitions 8;
ERROR 1503 (HY000): A UNIQUE INDEX must include all columns in the table's partitioning function

Podemos verlo mirando los ficheros que genera una tabla sin particionar:

-rw-rw----  1 mysql mysql      8630 Feb 10 09:36 usuarios.frm
-rw-rw----  1 mysql mysql  34396808 Feb 10 09:37 usuarios.MYD
-rw-rw----  1 mysql mysql  53809152 Feb 10 09:37 usuarios.MYI

Y compararlos con los ficheros en una tabla particionada:

-rw-rw----  1 mysql mysql      8630 Feb 10 09:55 usuarios_part.frm
-rw-rw----  1 mysql mysql        48 Feb 10 09:55 usuarios_part.par
-rw-rw----  1 mysql mysql   4300132 Feb 10 09:56 usuarios_part#P#p0.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p0.MYI
-rw-rw----  1 mysql mysql   4299516 Feb 10 09:56 usuarios_part#P#p1.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p1.MYI
-rw-rw----  1 mysql mysql   4298944 Feb 10 09:56 usuarios_part#P#p2.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p2.MYI
-rw-rw----  1 mysql mysql   4299772 Feb 10 09:56 usuarios_part#P#p3.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p3.MYI
-rw-rw----  1 mysql mysql   4299488 Feb 10 09:56 usuarios_part#P#p4.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p4.MYI
-rw-rw----  1 mysql mysql   4299812 Feb 10 09:56 usuarios_part#P#p5.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p5.MYI
-rw-rw----  1 mysql mysql   4299280 Feb 10 09:56 usuarios_part#P#p6.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p6.MYI
-rw-rw----  1 mysql mysql   4299864 Feb 10 09:56 usuarios_part#P#p7.MYD
-rw-rw----  1 mysql mysql   2114560 Feb 10 09:56 usuarios_part#P#p7.MYI

Podemos apreciar que cada partición tiene su porpio fichero de datos y de índices según este patrón: tabla#P#p<Numero de partición>.MYI (índices)y tabla#P#p<Numero de partición>.MYD (datos)

Procederemos entonces a eliminar dicho índice UNIQUE:

mysql> alter table usuarios_part drop key usuario;
Query OK, 1645134 rows affected (6.99 sec)
Records: 1645134  Duplicates: 0  Warnings: 0

A continuación podremos crear las particiones:

mysql> alter table usuarios_part partition by hash(id) partitions 8;
Query OK, 1645134 rows affected (4.92 sec)
Records: 1645134  Duplicates: 0  Warnings: 0

Podemos a continuación comparar con una tabla sin particionar:

mysql> select * from usuarios where usuario='therealme';
+---------+-----------+----------+
| id      | usuario   | password |
+---------+-----------+----------+
| 1318467 | therealme |          |
+---------+-----------+----------+
1 row in set (0.00 sec)

Y su EXPLAIN:

mysql> explain select * from usuarios where usuario='therealme';
+----+-------------+----------+-------+---------------+---------+---------+-------+------+-------+
| id | select_type | table    | type  | possible_keys | key     | key_len | ref   | rows | Extra |
+----+-------------+----------+-------+---------------+---------+---------+-------+------+-------+
|  1 | SIMPLE      | usuarios | const | usuario       | usuario | 194     | const |    1 |       |
+----+-------------+----------+-------+---------------+---------+---------+-------+------+-------+
1 row in set (0.00 sec)

Con la tabla particionada en este punto:

mysql> select * from usuarios_part where usuario='therealme';
+---------+-----------+----------+
| id      | usuario   | password |
+---------+-----------+----------+
| 1318467 | therealme |          |
+---------+-----------+----------+
1 row in set (0.36 sec)

Hasta este punto podemos ver como la diferencia de tiempo es considerable. Podemos ver como el EXPLAIN nos indica la falta del índice:

mysql> explain select * from usuarios_part where usuario='therealme';
+----+-------------+---------------+------+---------------+------+---------+------+---------+-------------+
| id | select_type | table         | type | possible_keys | key  | key_len | ref  | rows    | Extra       |
+----+-------------+---------------+------+---------------+------+---------+------+---------+-------------+
|  1 | SIMPLE      | usuarios_part | ALL  | NULL          | NULL | NULL    | NULL | 1645134 | Using where |
+----+-------------+---------------+------+---------------+------+---------+------+---------+-------------+
1 row in set (0.00 sec)

Como no se puede crear un índice global, podemos obtar por incluir el id en el índice:

mysql> alter table usuarios_part add unique (usuario,id);
Query OK, 1645134 rows affected (39.06 sec)
Records: 1645134  Duplicates: 0  Warnings: 0

MySQL permite la utilización de prefijos de los índices existentes, por lo que podemos crear el índice (usuario,id) y utilizarlo como si fuera solo de (usuario). Esto tiene un inconveniente, realmente no estamos creando una restricción de UNIQUE en el campo “usuario”, ya que al agregar el id autoincremental el conjunto siempre será único:

mysql> insert into usuarios_part(usuario) values ('therealme');
Query OK, 1 row affected, 1 warning (0.00 sec)

mysql> select * from usuarios_part where usuario='therealme';
+---------+-----------+----------+
| id      | usuario   | password |
+---------+-----------+----------+
| 1318467 | therealme |          |
| 1645135 | therealme |          |
+---------+-----------+----------+
2 rows in set (0.42 sec)

Por la cantidad de registros, en la query en tiempo vamos a notar poca diferencia con la versión sin particionar:

mysql> select * from usuarios_part where usuario='therealme';
+---------+-----------+----------+
| id      | usuario   | password |
+---------+-----------+----------+
| 1318467 | therealme |          |
+---------+-----------+----------+
1 row in set (0.00 sec)

Pero en el EXPLAIN podemos notar la diferencia:

mysql> explain select * from usuarios_part where usuario='therealme';
+----+-------------+---------------+------+---------------+---------+---------+-------+------+-------------+
| id | select_type | table         | type | possible_keys | key     | key_len | ref   | rows | Extra       |
+----+-------------+---------------+------+---------------+---------+---------+-------+------+-------------+
|  1 | SIMPLE      | usuarios_part | ref  | usuario       | usuario | 194     | const |    8 | Using where |
+----+-------------+---------------+------+---------------+---------+---------+-------+------+-------------+
1 row in set (0.00 sec)

Debemos fijarnos en el type del EXPLAIN de las dos queries:

• En el caso de la tabla no particionada el type es const: Por lo que indica que seleccionamos un solo valor, por lo que es el mejor caso (exceptuando system que no aplicaría en este caso)
• En el caso de la tabla particionada el type es ref: Esto indica que deberá recorrer todo el índice en búsqueda de todos los valores

En el caso de una tabla sin particionar el índice se trata de un solo fichero, pero en el caso de una tabla particionada deberemos recorrer todos los índices de todas las particiones, por lo que no sólo va a ser peor por passar de un const a un ref, sino que no se trata de un índice sino tantos como particiones.

Evidentemente el particionamiento es bueno para algunos casos pero no cada caso debe ser analizado para ver si aplica. Por el contrario, muchas veces parece que la gente se lo toma como: “Con el particonamiento se solucionaran todos los problemas de rendimiento” o “Si la tabla es grande se debe particionar“. Cada cosa tiene su lugar, por lo que se debe planificar bien un cambio de estas características, nunca se debe hacer por hacer.

NuestraFuente:  SystemAdmin.es

BigDump

Nuestra Fuente: SentidoWeb.com

Para obterner dicha utilidad lo podemos hacer mediante el siguiente wget:

# cd /usr/local/bin
#  wget http://www.maatkit.org/get/mk-duplicate-key-checker
# chmod +x mk-duplicate-key-checker

Si no los teneis ya instalados, necesitareis los siguientes modulos de perl:

• DBD::mysql
• Term::ReadKey

Se pueden instalar mediante cpan (recortanda la salida):

# cpan
Terminal does not support AddHistory.

cpan shell -- CPAN exploration and modules installation (v1.7602)
ReadLine support available (try 'install Bundle::CPAN')

cpan> install Term::ReadKey
(...)
cpan> install DBD::mysql
(...)

A continuación ya se puede ejecutar mk-duplicate-key-checker así:

$ mk-duplicate-key-checker --user maite --askpass --host 172.12.1.130

Su salida sería similar a esta:

DATABASE TABLE                  ENGINE OBJECT                   TYPE STRUCT   PARENT COLUMNS
site32   zzzta_9                MyISAM PRIMARY                  KEY  BTREE    NULL   `ta_id`
site32   zzzta_9                MyISAM ta_id                    KEY  BTREE    NULL   `ta_id`
site32   zzzta_9                MyISAM ta_id_2                  KEY  BTREE    NULL   `ta_id`

Para este caso veriamos no un índice duplicado, sinó triplicado. Podemos ver su create table:

mysql> show create table zzzta_9\G
*************************** 1. row ***************************
       Table: zzzta_9
Create Table: CREATE TABLE `zzzta_9` (
  `ta_id` int(11) unsigned NOT NULL auto_increment,
  `ta_section` varchar(100) default NULL,
  `ta_url` text,
  `ta_keywords` text,
  `ta_description` text,
  PRIMARY KEY  (`ta_id`),
  UNIQUE KEY `meta_id` (`ta_id`),
  KEY `meta_id_2` (`ta_id`)
) ENGINE=MyISAM AUTO_INCREMENT=10 DEFAULT CHARSET=utf8
1 row in set (0.00 sec)

Vemos como el desarrolador ha definido:

• Un índice para el campo ta_id mediante la keyword KEY
• A continuación una restricción UNIQUE, por lo que se crea un índice implicatamente restringuiendo la columna a valores únicos incluyendo NULL como possible valor.
• Finalmente, define la columna como PRIMARY KEY, creando el tercer índice y restringiendo a valores únicos excluyendo NULL

Este tipo de errores són más comunes de lo que parece. Además los desarrolladores acostumbran a ser reticentes a quitar estos índices, incluso si estan triplicados. Para este caso sólo con la PRIMARY KEY sería suficiente.

Otro caso común sería el siguiente:

site53 areas                  MyISAM area_pt                  KEY  BTREE    NULL   `area_pt`
site53 areas                  MyISAM area_pt_name            KEY  BTREE    NULL   `area_pt`,`area_name`

En este caso vemos que el índice area_pt es prefijo del índice area_pt_name. MySQL puede usar cualquier prefijo possible de un índice multicolumna, por lo que el índice area_pt se puede eliminar, ya que MySQL podría usar el índice compuesto en su lugar.

fuente: SystemAdmin.es

Para ello primero de todo entramos como root y creamos el nuevo usuario, por ejemplo lo vamos a llamar sysdba:

$ mysql -uroot -prootpass
mysql> create user sysdba@localhost identified by 'passdba';
mysql> grant all on *.* to sysdba@localhost with grant option;

A continuación podemos comprobar su funcionamiento con:

$ mysql -usysdba -ppassdba

Finalmente podemos eliminar el usuario root:

$ for i in 127.0.0.1 localhost $(hostname); do drop user root@$i | mysql -usysdba -ppassdba; done

fuente: SystemAdmin.es

Aunque estrictamente no se trata de un tema de sistemas, no es de extrañar que alguien pregunte estos temas. Por ejemplo, ayer me encontré con un programador que asociaba SQL Injection (un problema que tuvo en la base de datos) con las comillas: “Ya escapo las comillas”

Revisando el código (PHP) encontré que hacia una diferenciación según el tipo de datos. En el caso de añadir un string a la query el código era:

$query.=" variable = '".mysql_real_escape_string($var)."'";

Mientras que si la variable era un identificador numérico:

$query.=" variable = ".mysql_real_escape_string($var);

En el caso que la variable en lugar del valor numérico contenga lo siguiente:

3; drop database ejemplo;

La query se construiría de la siguiente forma:

select name from users where variable=3; drop database ejemplo;

En este caso sólo usando comillas también para datos numéricos tendríamos un problema menos porque la query se construiría de la siguiente forma (dando un error al ejecutarse):

select name from users where variable='3; drop database ejemplo;'

SQL Injection realmente es una técnica genérica referida a añadir código SQL y no “usar comillas para hacer cosas malas“

fuente: SystemAdmin.es