지난번에 글을 쓰려고 하다가 바빠서 못 썼었는데,
오늘은 시간이 나서 몇자 적습니다.
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의 속도 문제와 직결됩니다.
|