dBack

type

조인타입, 아래와 같다. 우수한 순서대로 뒤로갈수록 나쁜 조인형태이다.

• system
  테이블에 단 하나의 행만 존재(시스템 테이블). const join 의 특수한 경우이다.
  
  
• const
  많아야 하나의 매치되는 행만 존재하는 경우. 하나의 행이기 때문에 각 컬럼값은 나머지 연산에서 상수로 간주되며, 처음 한번만 읽어들이면 되기 때문에 무지 빠르다.
  PRIMARY KEY 나 UNIQUE index 를 상수와 비교하는 경우.
  아래의 경우에서 tbl_name 은 const table 로 조인된다.
  
  SELECT * FROM tbl_name WHERE primary_key=1;
  SELECT * FROM tbl_name
  WHERE primary_key_part1=1 AND primary_key_part2=2;
  
  
• eq_ref
  조인수행을 위해 각 테이블에서 하나씩의 행만이 읽혀지는 형태. const 타입이외에 가장 훌륭한 조인타입니다.
  조인연산에 PRIMARY KEY 나 UNIQUE index 인덱스가 사용되는 경우.
  인덱스된 컬럼이 = 연산에 사용되는 경우. 비교되는 값은 상수이거나 이전조인결과의 컬럼값일수 있다.
  다음 예에서 MySQL 은 ref_table 을 처리하는데 eq_ref 조인을 사용한다.
  
  SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;
  SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1= other_table.column
  AND ref_table.key_column_part2=1;
• ref
  이전 테이블과의 조인에 사용될 매치되는 인덱스의 모든행이 이 테이블에서 읽혀진다. leftmost prefix 키만을 사용하거나 사용된 키가 PRIMARY KEY 나 UNIQUE 가 아닐때(즉 키값으로 단일행을 추출할수 없을때) 사용되는 조인.
  만약 사용된 키가 적은수의 행과 매치될때 이것은 적절한 조인 타입니다.
  ref 는 인덱스된 컬럼과 = 연산에서 사용된다.
  아래 예에서 MySQL 은 ref_table 처리에 ref 조인 타입을 사용한다.
  
  SELECT * FROM ref_table WHERE key_column=expr;
  SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column=other_table.column;
  SELECT * FROM ref_table,other_table
  WHERE ref_table.key_column_part1= other_table.column
  AND ref_table.key_column_part2=1;
  
  
• ref_or_nullSELECT * FROM ref_table WHERE key_column=expr OR key_column IS NULL;See Section 7.2.7, “How MySQL Optimizes IS NULL”.
  
  
• ref 와 같지만 NULL 값을 포함하는 행에대한 검색이 수반된다.
  4.1.1 에서 새롭게 도입된 조인타입이며 서브쿼리 처리에서 대개 사용된다.
  아래 예에서 MySQL 은 ref_table 처리에 ref_or_null 조인타입을 사용한다.
• index_merge
  인덱스 병합 최적화가 적용되는 조인 타입.
  이 경우, key 컬럼은 사용된 인덱스의 리스트를 나타내며 key_len 컬럼은 사용된 인덱스중 가장 긴 key 명을 나타낸다.
  For more information, see Section 7.2.6, “Index Merge Optimization”.
  unique_subqueryunique_subquery 는 성능향상을 위해 서브쿼리를 단순 index 검색 함수로 대체한다.
  이것은 아래와 같은 몇몇 IN 서브쿼리 처리에서 ref 타입대신 사용된다.
  
  value IN (SELECT primary_key FROM single_table WHERE some_expr)
  
  
• index_subquery
  unique_subquery 와 마찬가지로 IN 서브쿼리를 대체한다. 그러나 이것은 아래와 같이 서브쿼리에서 non-unique 인덱스가 사용될때 동작한다.
  
  value IN (SELECT key_column FROM single_table WHERE some_expr)
  
  
• range
  SELECT * FROM tbl_name WHERE key_column = 10; SELECT * FROM tbl_name WHERE key_column BETWEEN 10 and 20; SELECT * FROM tbl_name WHERE key_column IN (10,20,30); SELECT * FROM tbl_name WHERE key_part1= 10 AND key_part2 IN (10,20,30);
  
  인덱스를 사용하여 주어진 범위 내의 행들만 추출된다. key 컬럼은 사용된 인덱스를 나타내고 key_len 는 사용된 가장 긴 key 부분을 나타낸다.
  ref 컬럼은 이 타입의 조인에서 NULL 이다.
  range 타입은 키 컬럼이 상수와 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN 또는 IN 연산에 사용될때 적용된다.
  
  
• index
  이 타입은 인덱스가 스캔된다는걸 제외하면 ALL 과 같다. 일반적으로 인덱스 파일이 데이타파일보다 작기 때문에 ALL 보다는 빠르다.
  MySQL 은 쿼리에서 단일 인덱스의 일부분인 컬럼을 사용할때 이 조인타입을 적용한다.
  
  
• ALL
  이전 테이블과의 조인을 위해 풀스캔이 된다. 만약 (조인에 쓰인) 첫번째 테이블이 고정이 아니라면 비효율적이다, 그리고 대부분의 경우에 아주 느린 성능을 보인다. 보통 상수값이나 상수인 컬럼값으로 row를 추출하도록 인덱스를 추가함으로써 ALL 타입을 피할 수 있다.

참조: m.blog.naver.com/PostView.nhn?blogId=hmoai&logNo=50033300449&proxyReferer=https:%2F%2Fwww.google.com%2F

Post method 포스트맨 파일 업로드 실제 예제

Another version

Older version

Postman 사용시 유의.

코드 레벨에서 Content-Type: {multipart/form-data} 를 기입하지 않아야 에러가 나지 않는다.

혹은,

postman header 영역에서의 content-type: multipart/form-data 를 해제 시켜준다.

Fails If In Header 

Works 

출처: stackoverflow.com/questions/16015548/tool-for-sending-multipart-form-data-request

MySQL 의 CHAR 나  VARCHAR 컬럼에 데이타를 입력할 경우 컬럼 사이즈보다 큰 데이타가 입력됐을때 당연히 DB 차원에서 insert 가 안 되는줄 알았다.

그런데 특정 서버에서는 사이즈보다 큰 부분이 truncate 되고 insert 되어 찾아보니 MySQL 서버의 sql_mode 라는 설정의 strict mode에 따라 데이타 검증을 수행하는데 5.5의 경우 기본적으로 이 모드가 꺼져 있다고 한다.

MySQL 버전마다 다르겠지만 현재 사용하고 있는 5.5.40 의 기본 sql_mode 설정은 '' 이며 (https://dev.mysql.com/doc/refman/5.5/en/server-options.html#option_mysqld_sql-mode)

이 경우 STRICT_ALL_TABLES, STRICT_TRANS_TABLES 가 꺼지며 CHAR, VARCHAR 의 크기를 초과하는 데이타 입력시 에러를 내지 않고 잘리게 된다.

개인적인 생각으로는 이런 데이타의 무결성을  app 에서 하는것 보다는 DBMS 에서 체크하는게 더 편하고 이를 위해 DBMS 를 쓰는 것이므로 비록 속도가 저하되더라도 STRICT_MODE 로 쓰는게 좋다고 보다.

그러면 STRICT MODE 로 설정을 변경해 보자.

// my.cnf

[mysqld] sql_mode="NO_ENGINE_SUBSTITUTION,STRICT_TRANS_TABLES"

STRICT MODE 로 전환되었다면 다음 SQL 문은 오류가 나고 정상적으로 동작하지 않는다.

MySQL 5.7 부터는 STRICT_MODE 가 기본 설정이라고 하니 별도의 설정 작업이 필요없다.

참고 url: www.lesstif.com/dbms/mysql-strict-mode-24445406.html

MariaDB 10.3 버전 이후 부터 쿼리를 Oracle 모드로 사용할 수 있다.

show variables like 'sql_mode%';

// my.cnf

sql_mode=ORACLE

추가하여 저장하면 사용할 수 있다.

자세한 링크: mariadb.com/kb/en/sql_modeoracle-from-mariadb-103/

MariaDB version 10.3 이후 에서는

기본적으로 시퀀스 생성을 사용할 수 있다.

-- 버전 확인

SELECT VERSION(); // 10.4.12-MariaDB-1:10.4.12+maria~bionic-log

-- 시퀀스 생성문

CREATE SEQUENCE seq_template;

-- 현재 값
SELECT LASTVAL(seq_template);
-- 다음 값
select NEXTVAL(seq_template);

-- 현재 시퀀스 값 초기화
ALTER SEQUENCE seq_template RESTART 1;

sudo apt-get purge runit 
sudo apt-get purge git-all 
sudo apt-get purge git 
sudo apt-get autoremove 
sudo apt update 
sudo apt install git

// git-core is already the newest version 로 검색

이유: Ubuntu 16.04 LTS에 runit이 upstart에 의존하고 Ubuntu가 15.04에서 systemd를 사용하도록 변경 되었기 때문에 문제가 발생함. (모든 git 패키지를 설치하는 중 에러)

const o = { lastName: 'foo' }

o.hasOwnProperty('lastName') // true

delete o['lastName']

o.hasOwnProperty('lastName') // false

pm2 cleardump
pm2 delete [app name]

pm2 list
In-memory PM2 is out-of-date, do:
error

pm2 update

locate:

/etc/mysql/mariadb.conf.d/50-server.cnf

bind-address 127.0.0.1

to

bind-address 0.0.0.0

service mysql restart

$ sudo apt-get update

$ sudo apt-get install build-essential libssl-dev

$ curl -o- https://raw.githubusercontent.com/creationix/nvm/v0.33.11/install.sh

$ source ~/.bashrc

$ nvm install 10.4.1

$ node -v
$ node --version

$ npm --version

// node default version

$ nvm alias default 6.11.5