MariaDB/MySQL mysqldump 옵션정리

Posted 2016. 3. 19. 22:05

MyriaDB는 태생이 MySQL이라서 아직까지는 mysql명령어를 그대로 사용한다.


테스트를 위한 database 및 user를 생성합니다.


-- utf8옵션으로 데이터베이스를 생성합니다.

create database org_db default character set utf8 collate utf8_general_ci;

create database target_db default character set utf8 collate utf8_general_ci;


-- 사용자를 생성합니다.

create user 'test_user'@'%' identified by 'test_password';


-- 사용자에게 생성한 DB 접근권한을 부여합니다. 모든 권한을 다 줍니다. 세부권한에 대한 옵션은 별도 참조

-- 참고로 권한을 제거하는 명령어는 revoke 입니다.

grant all privileges on org_db.* to 'test_user'@'%';

grant all privileges on target_db.* to 'test_user'@'%';

flush privileges;


참고 : http://durst.tistory.com/183


테스트를 위한 org_db에 테이블도 몇개 만들고 데이터를 넣어둡니다.

use org_db;

create table t1( id varchar(10), nm varchar(20), reg_dttm datetime );

insert into t1 values ('a1', '테스트', now() ),('a4', '테스트4', now() ),('a2', '테스트2', now() ),('a3', '테스트3', now() );


create table t2( id varchar(10), nm varchar(20), reg_dttm datetime );

insert into t2 values ('a1', '테스트', now() ),('a4', '테스트4', now() ),('a2', '테스트2', now() ),('a3', '테스트3', now() );


create table t3( id varchar(10), nm varchar(20), reg_dttm datetime );

insert into t3 values ('a1', '테스트', now() ),('a4', '테스트4', now() ),('a2', '테스트2', now() ),('a3', '테스트3', now() );


이제 mysqldump 를 사용해 봅니다.

--org_db 전체를 dump합니다.

mysqldump -h 192.168.0.245 -u test_user -ptest_password org_db > org_db_all.sql

-- password는 -p옵션뒤에 바로 붙입니다. 띄어쓸경우 비밀번호가 아닌 database명으로 인식합니다.


-- 데이터 없이 구조만 가져오고 싶을때는 no-data 옵션을 사용

mysqldump -h 192.168.0.245 -u test_user -ptest_password org_db --no-data > org_db_all_structure.sql


-- org_db에 있는 특정테이블만 dump 합니다.

mysqldump -h 192.168.0.245 -u test_user -ptest_password org_db t1 t2 > org_db_t1_t2.sql


--add-drop-database,  --add-drop-table  은 drop database, drop table 구문을 사용하지 않습니다.

--no-create-db, --no-create-info 는 위의 옵션과 함께 사용하는데, create database, create table 구문을 사용하지 않습니다.

   다만 no-create-info를 사용할 경우 view는 dump를 받을수 없게 되니 유의.

--skip-add-locks --single-transaction --skip-lock-tables 는 dump 시 lock을 걸지 않고 실시합니다.

 운영중인 db에서  dump를 하고자 할때 사용합니다.


참고 : http://intomysql.blogspot.kr/2010/12/mysqldump.html


dump 받은 데이터가 utf-8이 아니라면 utf-8로 변환합니다.

mysql\ iconv -f latin1(source db 인코딩) -t UTF-8(target db 인코딩) dump.sql > newdump.sql


참고 : http://appletree.or.kr


테이블이나 데이터를 동일 host의 접근가능한 database에 복사하려고 하는 경우엔 굳이 dump를 받지 않고 create&select, insert&select를 해도 됩니다.

참고 : http://ra2kstar.tistory.com/109








MySQL 에서 쿼리 결과를 Ctrl+C 해서 Excel에 붙여넣기를 하다보면 결과값 중에 엔터값이나 캐리지 리턴 값이 있는 경우 엑셀의 셀을 벗어나 버리는 상황이 발생합니다.

 

이럴때 replace함수를 이용하여 처리하면 한줄로 처리됩니다.

 

SELECT

       REPLACE(REPLACE(MSG_KOR_TXT,'\r\n',' '),'\r',' ') AS MSG_TXT
FROM MSG

 

 

 



원본 : http://dev.mysql.com/doc/refman/5.0/en/procedure-analyse.html

8.8.2. Using PROCEDURE ANALYSE

ANALYSE([max_elements[,max_memory]])

ANALYSE() examines the result from a query and returns an analysis of the results that suggests optimal data types for each column that may help reduce table sizes. To obtain this analysis, append PROCEDURE ANALYSE to the end of a SELECT statement:

SELECT ... FROM ... WHERE ... PROCEDURE ANALYSE([max_elements,[max_memory]])

For example:

SELECT col1, col2 FROM table1 PROCEDURE ANALYSE(10, 2000);

The results show some statistics for the values returned by the query, and propose an optimal data type for the columns. This can be helpful for checking your existing tables, or after importing new data. You may need to try different settings for the arguments so that PROCEDURE ANALYSE() does not suggest the ENUM data type when it is not appropriate.

The arguments are optional and are used as follows:

  • max_elements (default 256) is the maximum number of distinct values that ANALYSE() notices per column. This is used by ANALYSE() to check whether the optimal data type should be of type ENUM; if there are more than max_elements distinct values, then ENUM is not a suggested type.

  • max_memory (default 8192) is the maximum amount of memory that ANALYSE() should allocate per column while trying to find all distinct values.

 

처음 DB를 구성해서 일정기간 사용하다보면 특정 테이블에 데이터가 편중되고, 그러다 보면 해당 테이블 때문에 병목현상이 발생하는 경우가 종종 있다. 그때부터 해당 테이블을 어떻게 커스터마이징 해야할까 고민하게 되고 각 컬럼이 제대로 사용되는지 체크해보고 싶은 욕구가 생긴다. 가령 VARCHAR(100) 으로 선언했음에도 불구하고  실제 데이터는 20 byte 미만으로 사용된다면 해당 컬럼의 선언은 굳이 varchar(100) 이 아니라 varchar(20)으로 하는것이 좋다는 것은 누구나 아는 사실이다.

이를 분석하기 위한 방법이 바로 PROCEDURE ANALYSE 이다.

 

 



« PREV : 1 : 2 : 3 : 4 : 5 : ··· : 9 : NEXT »