지난번에 글을 쓰려고 하다가 바빠서 못 썼었는데,

오늘은 시간이 나서 몇자 적습니다.

DB 속도의 관건은 중요한 순서대로 따지면,

1. query의 최적화,

2. 서버 튜닝의 최적화,

3. 시스템(하드웨어&OS)의 최적화입니다.

여기서는 query의 최적화 문제만 언급하겠습니다.

먼저,

인덱싱에서 btree든 hash 든 그 인덱스 되는 것은

앞에서 부터 그 문자 전체까지만 입니다.

즉, 중간자 검색에서는 인덱싱 사용이 불가능합니다. btree, hash 특성상.

즉, select * from t where name like '%상기%'

이런식의 쿼리를 사용한다면, name 필드에 대한 인덱스를 만들어

두었다 하더라도 사용할 수 없게 됩니다.

이런식의 결과물을 원하는데, 인덱싱이 필요하다면, "Full Indexing" 기법을 이용해야합니다. (이것에 대한 짧은 글은 이곳 게시판에 제가 적어두었습니다)

---------

다음, join에서의 인덱싱은 주의를 기우려서 처리해야합니다.

저희 회사 쇼핑물 DB의 쿼리를 예로 들어서 설명하면,

shop=> explain select a.goodid from good a, categood b where a.goodid = '1234' and a.goodid = b.goodid;

Nested Loop (cost=0.00..4.45 rows=2 width=8)

-> Index Scan using good_goodid_i on good a (cost=0.00..2.42 rows=1 width=4)

-> Index Scan using categood_good_i on categood b (cost=0.00..2.02 rows=1 width=4)

------------------

shop=> explain select a.goodid from good a, categood b where a.goodid = b.goodid and b.goodid = a.goodid;

Hash Join (cost=694.99..1197.39 rows=2 width=8)

-> Seq Scan on categood b (cost=0.00..120.49 rows=7349 width=4)

-> Hash (cost=683.39..683.39 rows=4639 width=4)

-> Seq Scan on good a (cost=0.00..683.39 rows=4639 width=4)

-------------------

이 쿼리의 결과는 동일합니다. 하지만,

내부적으로 처리하는 과정은 위의 내용처럼 판이하게 틀립니다.

이런 부분에서의 주의가 바로 query의 속도 문제와 직결됩니다.