기현이♡경민이♡예진이의 해피하우스♥

네이버의 경향,한겨례 뉴스차단 과연 그들이 맞는가?

예진이네집 괴스트 — Mon, 12 Mar 2012 14:30:09 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

조선일보의 90일간 malware 결과

http://www.google.com/safebrowsing/diagnostic?site=chosun.com

YTN의 90일간 malware 결과

http://www.google.com/safebrowsing/diagnostic?site=ytn.co.kr

동아일보의 90일간 malware 결과

http://www.google.com/safebrowsing/diagnostic?site=donga.com

한겨례신문의 90일간 malware 결과

http://www.google.com/safebrowsing/diagnostic?site=hani.co.kr

경향신문의 90일간 malware 결과

http://www.google.com/safebrowsing/diagnostic?site=khan.co.kr

기사를 보다가 문득 생각나서 구글의 malware(악성코드) 검색을 이용해서 malware빈도를 비교 해보게 됐다.

어떤사이트에 malware 많은것일까?
네이버가 내부에서 파악하고 있는 통계는 어떤기준인지 먼저 밝여야 하지 않을까??

정치적이 아니라는 근거를 언넝 밝혀라~~~~~~

자꾸 의심하게되네 씨바!~~~

요즘 심취한 coldplay 의 fix you 가사 및 유튜브

예진이네집 괴스트 — Thu, 01 Dec 2011 14:50:33 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

When you try your best but you don't succeed,

최선을 다했으나 성공하지 못했을 때

When you get what you want, but not what you need,

원하는 것을 얻었으나 필요한 것은 아닐 때

When you feel so tired, but you can't sleep,

너무 피곤하나 잠들지 못할 때

Stuck in reverse,

모든 것이 엉켜버린 기분일 때

and the tears come streaming down your face,

눈물이 흘러 얼굴로 떨어질 때

When you lose something you can't replace,

대체할 수 없는 소중한 것을 잃어버렸을 때

When you love someone but it goes to waste,

너무나 사랑했으나 수포로 돌아갔을 때

Could it be worse?

더 이상 나쁠 수 있을까요?

Lights will guide you home,

불빛이 당신을 집으로 인도하고

and ignite your bones,

마음 속 깊이 불을 밝혀 줄 거에요.

and I will try to fix you

그리고 나는 당신을 어루만져 줄게요.

High up above or down below,

더 높은 곳으로 오르거나 더 낮은 곳으로 떨어질 때

When you're too in love to let it go,

떠나 보내기엔 너무나 사랑할 때

If you'll never try, you'll never know,

노력하지 않으면 절대 알 수 없겠죠

Just what you are worth

당신이 얼마나 소중한 존재인지

Lights will guide you home,

불빛이 당신을 집으로 인도하고

and ignite your bones

마음 속 깊이 불을 밝혀 줄 거에요.

and I will try to fix you

그리고 나는 당신을 어루만져 줄게요.

Tears stream down your face

눈물이 흘러 얼굴로 떨어질 때

When you lose something you cannot replace

대체할 수 없는 소중한 것을 잃어버렸을 때

Tears stream down your face

눈물이 흘러 얼굴로 떨어질 때

And I

그리고 난

Tears stream down your face

눈물이 흘러 얼굴로 떨어질 때

I promise you I will learn from all of my mistakes

내 실수들로부터 배울 거라고 약속할게요.

Tears stream down your face

눈물이 흘러 얼굴로 떨어질 때

And I

그리고 난

Lights will guide you home

And ignite your bones

And I will try to fix you.

출처: 새로운 출발선에 서서 by 삼돌 누나

==============================================================================================================================================================================

요즘 이런류의 서정적인 노래가 끌린다.
가사도 아름답고 맘에도 와 닫는다.

프로그래머의 아내가 알아야 할 97가지

예진이네집 괴스트 — Fri, 15 Jul 2011 11:27:39 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

딱 떨어지는 숫자는 2진수입니다.
한 손으로 31까지 셀 수 있음
만능이 아님
"컴퓨터"를 잘 하는게 아님
프로그래머라고 Office 시리즈에 정통한 것이 아님
아, 그 작업은 사무쪽 누님이 잘하실 겁니다.
가나 입력으로 변환한 다음에는 반드시 로마자 입력으로 돌려놓을 것
프로그램의 쓰레기 수집은 잘 하지만 자기 방의 쓰레기 수집은 잘 못함
멀티스레드 처리 작성은 할 수 있지만 멀티스레드 처리는 못함
Amazon 에서 사는 건 기술서이므로, 딱히 포장물 내용을 확인할 필요는 없음
쌓아놓은 책은 스택이므로 순번을 바꾸지 말것
오라일리 책은 「같은 책」이 아님
표지에 동물만 그려져 있는 책만 꽂혀있어도 그건 동물도감이 아님
프로그래밍을 안하는 날도 있음
프로그래밍 언어나 에디터에 대한 집착이 사라진다면 깨달음을 얻었거나 완전연소했거나 둘 중 하나
언어로 바람피우는 것과 인생의 바람피우기는 다른 것
「자식을 죽인다」는 말에 놀라지 말 것
일 관계로 전화를 할 때, 자식이 죽지 않으면 부모를 죽여버리라는 대화를 들어도 놀라지 말것
라이브러리라는 것은 도서관을 말하는 게 아님
「사이드 이펙트(부작용)」는 부정적인 의미로 사용하는 것이 아님
특히 「다이아몬드 상속」은 유산상속같은 이야기를 하는 것이 아님
괜히 보석 이름 같은 것을 중얼거려도 보석에 대해 잘 아는 것이 아님
루비와 펄 중에 뭐가 좋아? 라고 물어보면, 싱긋 웃으면서 펄이라고 대답할 것
「조금만 더하면」「거의 끝났어」라는 말이 나오기 시작하면 당분간 끝나지 않을 것이라고 생각할 것
갑자기 혼잣말을 하기 시작해도 정신이 이상해진 것이 아님
PC 를 보고 있는 남편에게 말을 걸어도 되는 타이밍인지 아닌지 외견으로 판단하는 것은 포기하는 것이 좋음
23-24시 정도가 가장 활발함
HP 는 항상 0에 수렴함
회사와 집의 구별이 그다지 없고, PC 앞에 있는가 없는가의 구별 밖에 없음
스스로가 정보수집과 오락의 경계선을 이해하지 못함
몬스터헌터는 업무
애니메이션 보는 것은 업무
일을 하는 것처럼 보이지만 실은 인터넷을 하는 것 뿐임
주말에도 스터디에 간다고 하는 것은 공부를 열심히 한다는 증거, 가사가 싫어서 그러는 게 아님
한밤에 긴급전화가 왔다면, 다음날부터의 예정은 캔슬이라고 생각합시다
밤중에 갑자기 사라져도 그냥 장애 대응하러 간 것임
오전중에 돌아오는 일이 많아져도 바람피우는 것이 아닌지 의심하지 말것
주말에만 사복으로 「출근」했다고 바람피우는 것이라고 의심하지 말 것
결혼식장에서 신랑이 사라져도 당황하지 말것. 고객이 호출한 것 뿐임
정시퇴근은 도시전설
「귀가한다」「귀가할 수 있다」라는 말은 별 도움이 안됨
10일 정도 돌아오지 않아도 당황하지 말 것
감금같은 걸 당해도 빚이 있어서 그러거나 한 게 아님
가끔씩 일찍 돌아와도 잘렸을 걱정은 하지 말 것
여름 휴가 언제야? 라고 묻지 말 것
Twitter 의 post 빈도 감소나 내용에서 상대가 얼마나 바쁜지 추측해서 위로할 것
화재나 행진같은 것에 트라우마를 갖고 있을 것
남편 급여의 직능급과 기본급과 잔업수당의 비율
노동기준법
OA 기기라고 적힌 우편물은 절대로 OA 기기가 아님
PC 나 휴대폰, iphone 에 패스워드 락이 걸려있는 것은 보안대책을 위해서. 바람을 핀다거나 야한 것을 숨기고 있는게 아니랍니다（　＾ω＾）
컴퓨터는 이미 집에 있잖아, 라고 하지 마시길. 당신이 갖고 있는 구두나 가방과 같은 것입니다.
한밤중에 컴퓨터로 동영상을 보면서 싱글거리고 있다면, 그것은 분명 Apple 의 신제품 발표이므로 신용카드를 몰수하는 것이 좋음
스티브 잡스의 프리젠테이션이 있는 다음날 아침에 갑자기 개최되는 가족회의에서 제출하는 안건에 대하여 「다른 집은 다른 집이고 우리 집은 우리 집이야!」라고 기각할 것
뭐가 뭔지 알수 없는 T 셔츠를 남편이 계속 가져와도 적당히 버리거나 하지 말 것
컴퓨터 책상에 놓여있는 피겨나 프라모델은 버리지 말 것
그것은 잡동사니도 부서진 물건도 아님
키넥트를 사려고 하는 것은 유저 인터페이스 연구 때문에
러브 플러스를 하는 것은 유저 인터페이스 연구 때문에
사용자 경험(UX)인지 뭔지 하는 주제에 CUI 를 좋아함
LCD 가 달려있는 작고 비슷하게 생긴 기계를 잔뜩 갖고 있어도 전부 다른 물건이며 각자 의미가 있습니다
동작검증을 하기 위해서는 신제품이 필요하며, 그것은 Amazon 에서 배달됨
옥션 사용방법을 숙지하고, 남편이 사온 장난감을 팔아치워 용돈으로 씁시다
생일 선물은 원하는 물건을 미리 말해두지 않으면 신제품 디지털 가전(Gadjet)을 받게 됨
깜짝 선물을 준비하고 싶다면 남편의 Amazon 위시 리스트를 조사함
iPhone 앱, Android 앱, Web 사이트를 만들었다는 이야기를 들으면 뭐가 뭔지 몰라도 상냥하게 대답해줄 것
쓸데없이 하이텐션으로 의미를 알 수 없는 소리를 지껄일 때에는 단순히 흥미 깊은 기술이 나와서 텐션이 높아진 것 뿐이므로, "잘 모르겠지만, 대단하다는 건 알겠다"라고 대답해주세요
갑자기 이상한 어휘가 늘었다면 니코니코 동화같은 데애서 유행하고 있는 것이라고 추측하시길
남편의 HN 과 본명을 이어보려고 해서는 안됨
남편의 블로그의 과거로그를 음독해서는 안됨
남편의 HN 으로 검색해서 흑역사를 알아서는 안됨
「우리 마누라가…」라고 했을 때, 그것은 프로그래머 사이에서 통용되는 전문용어입니다. 당신을 말하는 것이 아닙니다
오타쿠라고 하면 필요 이상으로 싫어하지만, 긱(Geek)이라고 말하면 기뻐합니다
침울해하고 있을 때는 「컴퓨터를 조작해서 ○○할 때 마우스를 쓰지 않고 키보드만으로 하려면 어떻게 해야해?」라고 물으면 기뻐하면서 가르쳐 줄 것입니다
「시뮬레이션」이라고 말하면 혼나므로 주의할 것
이상, 이하, 미만, 보다 위, 보다 아래를 대충 섞어쓰면 기분이 나빠짐
프로그래머는 「절대로」「뭔가 이상해졌어」「아무것도 안했어」같은 말에 과잉으로 반응합니다. 홧병, 쇼크사, 자살의 위험성이 있으므로 이런 말을 사용할 때에는 세심한 주의가 필요합니다
부부싸움할 때 최대의 무기는 화이트 보드
어쩌다 아내의 방식에 불만을 표시하면 「그건 사양(仕様)이예요」라고 대답함
남편이 이건 사양이라고 말하면 그 사양은 변경되었습니다 라고 대답할 것
싸워서 꼭지가 돌아버렸을 때에는, 네트워크 회선을 끊어버리는 것이 가장 손쉽고 효과적으로 분노를 표현하는 방법입니다.
가능하면 아내와의 대화를 자동화시키고 싶어 함
아내에게는 사양 변경이 붙는 법
홈 서버를 가리키면서 쓰지도 않는데 왜 항상 전원이 켜져 있는 거야 라고 묻지 말 것
연락수단은 전화<<<<<(넘을 수 없는 벽)<<<<메일<<<<<<<IRC, Skype, etc
Google Calender 에서 상대의 스터디 스케쥴을 파악할 것
집안 예정은 남편이 지정한 그룹웨어로 공유할 것. 구두(口頭)로의 통지만으로는 위험
남편이 해야할 것은 데스마치(죽음의 행진)이 아닌 여유가 있을 때 기억시켜두지 않으면 답이 없음
가정 내의 중요한 스케쥴을 끼워넣고 싶을 때에는 마감 근처의 주말은 피합시다. 어차피 집에 못 돌아옵니다
남편이 전문분야인 화제에는 신중하게 접근할 것
친구 관계의 잡담을 할 때에는 상관관계도를 그려주면 이해가 빨라집니다
단순히 이야기를 들어주기 바랄 때에서는 그렇게 명시할 것
동의해주기 바랄 때에 분석되어 정론을 들어도 화내지 마시기 바랍니다
요건은 항목별로 적어서 전하지 않으면 프로그래머 스스로가 버그를 냄
밤생활이 불만이면 Redbull 을 내밀어봄
정기적으로 자식들에게 이게 아빠야 하면서 사진을 보여주세요
남편이 「프로그래머의 아내가 알아야 할 97가지」같은 걸 트윗해도 신경쓰지 말 것
읽어보라고 한 97가지의 절반 이상이 뭔 소리인지 몰라도 어쩔 수 없음
이러니저러니 해도 아내를 사랑함. 하지만「쪽팔려서 말 못해」라고 생각해서 말로 표현하지 않을뿐.

경민아 잘 읽어보고 모르면 물어봐줘.. ㅎㅎㅎㅎ

원본인 일본사이트 원본 : http://d.hatena.ne.jp/tt_clown/20101218/1292609206

도치맘에서 이벤트 하네요..꼭 됐으면 좋겠네요 애기가 요즘 동화를 좋아해서..^&^

예진이네집 괴스트 — Thu, 25 Nov 2010 08:49:34 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

[이벤트] 은평문화예술회관에서 진행되는 가족 뮤지컬 "피터팬"에 도치맘 회원 5쌍 초대합니다.(~11월29일)

서울 은평문화예술회관에서 진행되는 피터팬에 도치맘회원 5쌍 (1인당 2매)초대합니다. ^^

피터팬의 모험...아이들이 참 좋아하는 내용이죠? ^^

가까우신 분들은 이벤트 참여하셔서 아이들과 즐거운 시간 되시길 바랍니다. ^^

공연: 가족뮤지컬 ‘피터팬’ (은평)

초대일: 12월 5일(일) 오후 2시 5쌍(1인2매)

당첨되신 분들께서는 여기를 클릭 하셔서 12월 5일 재밌게 관람하시고 후기 남겨주시기 바랍니다.

당첨되신 분들은 도치맘카페에 나중에 성함 연락처 알려주시고 가시면 되고요.

12월 5일 현장가셔서 쑥쑥닷컴에서 오셨다고 하시면 됩니다. ^^ 당첨자 11월 30일에 발표하겠습니다. 감사합니다.

[이벤트 기간] ~11월 29일

[이벤트 발표] 11월 30일

[선정인원] 5쌍(총10분)

[이벤트 미션]

1. 본 게시물을 본인 블로그에 스크랩 하시고, 그 URL을 댓글에 남겨주세요[전체공개가 필수임]

2. 아이의 연령, 필요하신 이유를 간단히 작성해 주세요

3. 받으신후 2주내에 도치맘 정해진 후기란과 본인 블로그, 쑥쑥 게시판 에 후기 남겨주시기 바랍니다.

서평과 후기는 본인들의 약속입니다. 지키지 못하실 분들은 이벤트 참여 삼가 부탁드립니다.

http://cafe.naver.com/dochithink.cafe

[미서평과 활용 후기 작성안하시는 분들의 활동 정지에 관란 절차 안내]

1) 기간이 마감되면 최종으로 안올리신 분들께 개별 쪽지 다시 발송됩니다.

2) 공지후 기간안에 안올리신 분들은 자동 활동정지 됩니다.

3) 활동정지를 해지하려면-->본인 블로그에 올리신 후기 URL 링크 거시어 젠틀맘님께 쪽지 보내주세요

서평자분들과 리뷰어 분들은 후기 작성 기간내에 꼭 후기 작성 부탁드립니다

[출처] [이벤트] 은평문화예술회관에서 진행되는 가족 뮤지컬 "피터팬"에 도치맘 회원 5쌍 초대합니다.(~11월29일) ([도치맘카페]도치엄마들의생각키우기) |작성자 도치해피맘

빅파일 체험이벤트 비비라이너 당첨됬어요.. 정말 좋아요~~ 적은시간에 최고의 효과 최코~!!

예진이네집 괴스트 — Mon, 11 Oct 2010 21:38:31 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

이자세는 가슴업시키는 자세입니다

설명서보고 조림하면 이런모양이 되고요^^ 설명서보면 누구나 쉽게 조림가능해요

이건 옆구리살 관리해주는 자세입니다

이건 허벅지살관리 해주는 자세이고요

작고 가벼워서 언제어디서나 운동하기 좋아요

이건 등살 관리해주는 자세입니다 등을 바로 펴고해야하는데 잘 안되네요~^^

이건 팔둑살 관리하는 자세입니다

TV보면서 아무때나 짬날때마다 할 수있어 너무 좋아요
옆에다 두고 보일때마다 너무 잘 사용하고 있어요^^
감사합니다.^^

html 특수문자표

예진이네집 괴스트 — Wed, 01 Sep 2010 11:55:56 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

  =
! = !
" = "
# = #
$ = $
% = %
& = &
' = '
( = (
) = )
* = *
+ = +
, = ,
- = -
. = .
/ = /
0 = 0
1 = 1
2 = 2
3 = 3
4 = 4
5 = 5
6 = 6
7 = 7
8 = 8
9 = 9
: = :
; = ;
< = <
= = =
> = >
? = ?
@ = @
A = A
B = B
C = C
D = D
E = E
F = F
G = G
H = H
I = I
J = J
K = K
L = L
M = M
N = N
O = O
P = P
Q = Q

R = R
S = S
T = T
U = U
V = V
W = W
X = X
Y = Y
Z = Z
[ = [
\ = \
] = ]
^ = ^
_ = _
` = `
a = a
b = b
c = c
d = d
e = e
f = f
g = g
h = h
i = i
j = j
k = k
l = l
m = m
n = n
o = o
p = p
q = q
r = r
s = s
t = t
u = u
v = v
w = w
x = x
y = y
z = z
{ = {
| = |
} = }
~ = ~

¡ = ¡
¢ = ¢
£ = £
¤ = ¤
¥ = ¥
¦ = ¦
§ = §
¨ = ¨
© = ©
ª = ª
« = «
¬ = ¬
 =
® = ®
¯ = ¯
° = °
± = ±
² = ²
³ = ³
´ = ´
µ = µ
¶ = ¶
· = ·
¸ = ¸
¹ = ¹
º = º
» = »
¼ = ¼
½ = ½
¾ = ¾
¿ = ¿
À = À
Á = Á
Â = Â
Ã = Ã
Ä = Ä
Å = Å
Æ = Æ
Ç = Ç
È = È
É = É
Ê = Ê
Ë = Ë
Ì = Ì
Í = Í
Î = Î
Ï = Ï
Ð = Ð
Ñ = Ñ
Ò = Ò

Ó = Ó
Ô = Ô
Õ = Õ
Ö = Ö
× = ×
Ø = Ø
Ù = Ù
Ú = Ú
Û = Û
Ü = Ü
Ý = Ý
Þ = Þ
ß = ß
à = à
á = á
â = â
ã = ã
ä = ä
å = å
æ = æ
ç = ç
è = è
é = é
ê = ê

아래는 Symbolic HTML entity입니다
이제 NetScape사용자 분들도 제데로 보이시죠. 명심하실것은 quot,amp,lt,gt,nbsp 다섯개 이외의 것은 모두 < PRE > tag로 묽어준 안에서만 제대로 나타난다는 겁니다 잊지마시길 .. 여기까지 읽어주셔서 감사합니다. 즐거운 하루되세요
  는 빈칸, space입니다

" = "

& = &

< = <

> = >

  =

¡ = ¡

¢ = ¢

£ = £

¤ = ¤

¥ = ¥

¦ = ¦

§ = §

¨ = ¨

© = ©

ª = ª

« = «

¬ = ¬

 =

® = ®

¯ = ¯

° = °

± = ±

² = ²

³ = ³

´ = ´

µ = µ

¶ = ¶

· = ·

¸ = ¸

¹ = ¹

º = º

» = »

¼ = ¼

½ = ½

¾ = ¾

¿ = ¿

à = à

á = á

â = â

ã = ã

ä = ä

å = å

æ = æ

ç = ç

è = è

é = é

ê = ê

ë = ë

ì = ì

í = í

î = î

ï = ï

ð = ð

ñ = ñ

ò = ò

ó = ó

ô = ô

õ = õ

ö = ö

× = ×

ø = ø

ù = ù

ú = ú

û = û

ü = ü

ý = ý

þ = þ

ß = ß

à = à

á = á

â = â

ã = ã

ä = ä

å = å

æ = æ

ç = ç

è = è

é = é

ê = ê

ë = ë

ì = ì

í = í

î = î

ï = ï

ð = ð

ñ = ñ

ò = ò

ó = ó

ô = ô

õ = õ

ö = ö

÷ = ÷

ø = ø

ù = ù

ú = ú

û = û

ü = ü

ý = ý

þ = þ

ÿ = ÿ

친구가 한턱쏴서 갔었던 종로의 청계천 근처

예진이네집 괴스트 — Thu, 19 Aug 2010 16:43:15 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

친구녀석이 TGIF 에서 한턱쏴서 맛있게 식사하고서 이곳저곳을 둘러봤다.

중간에 진짜 말이 끄는 마차도 보고 청개천도 내려가 보고 그러다가..

신기한 사진찍는 기계가 눈에 들어와서 한컷..

내 이메일로 전송하니 며칠뒤에야 도착했네.. ㅎㅎㅎ

그것도 스팸편지함으로.. ㅡㅡ;;; 서버관리자는 조금 신경써야 할 듯.. RFC 규약에 맞추서 보내주시구려.. ㅋㅋ

EXPLAIN을 사용해서 쿼리 최적화 하기

예진이네집 괴스트 — Wed, 11 Aug 2010 09:56:45 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

7.2.1. EXPLAIN을 사용해서 쿼리 최적화 하기

EXPLAIN tbl_name

또는:

EXPLAIN [EXTENDED] SELECT select_options

EXPLAIN 명령문은 DESCRIBE에 대한 동의어로 사용할 수 있거나 또는 MySQL이 SELECT 명령문을 실행하는 방법에 대한 정보를 얻기 위한 수단으로 사용할 수가 있다:

EXPLAIN tbl_name은 DESCRIBE tbl_name 또는 SHOW COLUMNS FROM tbl_name과 동일한 의미이다.
SELECT 명령문을 EXPLAIN 앞에 두면, MySQL은 쿼리 실행 플랜 (query execution plan) 정보를 옵티마이저 (optimizer)에서 가져 와서 출력 한다. 즉, MySQL은 테이블들이 어떤 순서로 조인 (join) 하는지에 대한 정보를 포함해서, SELECT를 처리하는 방법에 대해서 알려 준다.

이 섹션에서는 쿼리 실행 플랜 정보를 얻기 위한 EXPLAIN사용법을 설명한다. DESCRIBE 및 SHOW COLUMNS 명령문에 대한 설명은 Section 13.3.1, “DESCRIBE 신텍스”, 및 Section 13.5.4.3, “SHOW COLUMNS 신텍스”를 참조하기 바란다.

EXPLAIN를 사용함으로써, 여러분은 테이블의 어느 곳에 인덱스를 추가해야만 열을 찾기 위한 SELECT가 보다 빠르게 되는지를 알 수 있게 된다. 또한, EXPLAIN를 사용하면 옵티마이저가 최적의 (optimal) 순서로 테이블을 조인 (join)할 수 있는지 여부도 검사할 수가 있다. SELECT 명령문에 명명되어 있는 테이블의 순서와 상응하게 조인 (join) 순서를 사용하도록 옵티마이저를 만들기 위해서는, 명령문에 SELECT만을 사용하는 대신에 SELECT STRAIGHT_JOIN을 사용해서 시작을 하도록 한다.

만일 여러분 생각에는 사용 되어야만 했을 인덱스가 사용되지 않은 상태로 문제를 일으키게 되면, 키의 기수 (cardinality)와 같은 테이블 상태를 업데이트 하기 위해 ANALYZE TABLE을 구동 시켜야 하는데, 이것은 옵티마이저의 선택에 영향을 미치게 된다. Section 13.5.2.1, “ANALYZE TABLE 신텍스”를 참조할 것.

EXPLAIN은 SELECT 명령문에서 사용된 각 테이블 정보 열을 리턴한다. MySQL이 쿼리를 처리하는 동안 읽을 수 있도록 테이블들은 결과물 안에 목록으로 정리가 된다. MySQL 은 single-sweep multi-join 방법을 사용해서 모든 조인 (join)을 풀어 버린다 (reslove). 이것은 MySQL이 첫 번째 테이블에서 열을 읽고, 그 다음에 두 번째 테이블에서 매치 (match)가 되는 것을 찾으며, 세 번째, 네 번째 등으로 이동을 한다는 것을 의미하는 것이다. 모든 테이블을 처리한 후에, MySQL은 선택된 컬럼을 내 보내고 테이블에서 매치되는 다른 열이 있을 때까지 테이블을 역으로 검사한다. 그 테이블에서 그 다음 열을 읽고 다음 테이블로 이동을 해서 동일한 과정을 반복 진행한다.

EXTENDED 키워드가 사용되면, EXPLAIN은 EXPLAIN 명령문 다음에 SHOW WARNINGS 명령문을 입력해서 볼 수 있는 기타 정보를 리턴한다. 이 정보는 옵티마이저가 SELECT 명령문에 있는 컬럼 이름과 테이블을 얼마나 많이 검증을 하였는지를 보여주며, SELECT는 최적화 과정에 관한 어플리케이션 재 작성과 최적화 규칙, 그리고 다른 가능한 노트 (notes)를 보여준다.

EXPLAIN를 통해서 나오는 각각의 결과 열은 하나의 테이블에 대한 정보이며, 각 열은 아래의 컬럼을 가지고 있다:

id

SELECT 아이덴티파이어 (identifier). 이것은 쿼리 안에 있는 SELECT의 순차적인 번호(sequential number)이다.

select_type

SELECT에 대한 타입이며, 아래의 테이블에 있는 것 중에 하나가 된다:

`SIMPLE`	Simple `SELECT` (not using `UNION` or subqueries)
`PRIMARY`	Outermost `SELECT`
`UNION`	Second or later `SELECT` statement in a `UNION`
`DEPENDENT UNION`	Second or later `SELECT` statement in a `UNION`, dependent on outer query
`UNION RESULT`	Result of a `UNION`.
`SUBQUERY`	First `SELECT` in subquery
`DEPENDENT SUBQUERY`	First `SELECT` in subquery, dependent on outer query
`DERIVED`	Derived table `SELECT` (subquery in `FROM` clause)

DEPENDENT는 전형적으로는 상호 연관된 (correlated) 서브 쿼리(subquery)의 사용을 의미한다.

table

결과 열이 참조하는 테이블.

type

조인 (join) 타입. 서로 다른 타입의 조인 (join)이 아래에 있는데, 가장 좋은 것부터 가장 나쁜 것의 순서로 되어 있다:

system

테이블은 하나의 열만을 가지고 있다 (= 시스템 테이블). 이것은 const 조인 (join) 타입의 특별한 경우이다.

const

테이블은 적어도 하나의 매칭 (matching) 테이블을 가지고 있는데, 쿼리가 시작되는 시점에서 이 테이블을 읽게 된다. 여기에는 하나의 열만이 존재하기 때문에, 이 열에 있는 컬럼에서 얻는 값은 나머지 옵티마이저에 의해 상수 (constant)로 인식될 수 있다. const 테이블은 한번 밖에 읽혀지지 않기 때문에 매우 빠르다.

const는 PRIMARY KEY 또는 UNIQUE 인덱스의 모든 부분을 상수 값 (constant value)과 비교를 할 때 사용된다. 아래의 쿼리에서 보면, tbl_name은 const 테이블 형태로 사용되고 있다:

SELECT * FROM tbl_name WHERE primery_key=1;

SELECT * FROM tbl_name

  WHERE primery_key_part1=1 AND primery_key_part2=2;

eq_ref

이전 테이블로부터 각 열을 조합 (combination)하기 위해서 이 테이블의 열을 하나읽는다. system 및 const 타입과는 달리, 이것이 가장 최선의 가능 조인 (join) 타입이다. 이것은 조인 (join)에 의해 인덱스의 모든 부분이 사용될 때 쓰이게 되며, 이때 인덱스는 PRIMARY KEY 또는 UNIQUE 인덱스가 된다.

eq_ref는 = 연산자를 사용해서 비교되는 인덱스된 컬럼용으로 사용될 수 있다. 비교 값은 이 테이블 전에 읽었던 테이블에서 컬럼을 사용한 수식 또는 상수 (constant)가 될 수 있다. 아래의 예제에서 보면, MySQL은 ref_table를 처리하기 위해서 eq_ref 조인 (join)을 사용하고 있다.

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

이전 테이블에서 읽어온 각각의 열을 조합하기 위해 이 테이블에서 매칭 (matching)되는 인덱스 값을 가진 모든 열을 읽어온다. 만일 조인 (join)이 키의 좌측 끝(leftmost) 접두사 만을 사용하거나 또는 키 값이 PRIMARY KEY 또는 UNIQUE 인덱스가 아니라면 (달리 말하면, 만일 조인 (join)이 키 값을 기반으로 한 단일 (single) 열을 선택하지 않는다면), ref가 사용된다. 만일 사용된 키가 적은 수의 열에 대해서만 매치가 된다면, 그것은 좋은 조인 (join) 타입인 것이다.

ref는 = 또는 <=> 연산자를 사용해서 비교되는 인덱스된 컬럼에 대해 사용될 수 있다. 아래의 예제에서 본다면, MySQL은 ref_table 처리 과정에서 ref 조인 (join)을 사용한다.

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_null

이 조인 (join) 타입은 ref과 유사하지만, MySQL이 NULL 값을 가지고 있는 열에 대해서도 검색을 한다는 점에서 차이가 있다. 이 조인 (join) 타입 최적화는 서브 쿼리(subqueries)를 해석할 때 자주 사용된다. 아래의 예제에서 보면, MySQL은 ref_table처리 과정에서 ref_or_null 조인 (join)을 사용하고 있다.

SELECT * FROM ref_table

  WHERE key_column=expr OR key_column IS NULL;

index_merge

이 조인 (join) 타입은 인덱스 병합 최적화가 사용되었음을 나타낸다. 이 경우에, 결과 열에 있는 key 컬럼은 사용된 인덱스 리스트를 가지고 있고, key_len는 사용된 인덱스에 대해서 가장 긴 키 부분의 리스트를 가지고 있다.

unique_subquery

이 타입은 아래 형태의 IN 서브 쿼리 (subqueries)에 대해서 ref를 대체한다:

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery는 효율성을 위해서 서브 쿼리 (subquery)를 대체하는 인덱스 룩업(lookup) 함수이다.

index_subquery

이것은 unique_subquery와 유사한 조인 (join) 타입이다. 이것은 IN 서브 쿼리(subqueries)를 대체하지만, 아래 형태의 서브 쿼리 (subquery)에 있는 논-유니크(non-unique)인덱스에 대해서도 동작을 한다:

value IN (SELECT key_column FROM single_table WHERE some_expr)

range

주어진 범위에 들어 있는 열만을 추출하며, 열 선택은 인덱스를 사용한다. 결과 열에 있는 key 컬럼은 어떤 인덱스가 사용되었는지를 가리킨다. key_len은 사용된 키에서 가장 긴 부분을 가진다. ref 컬럼은 이 타입에 대해서는 NULL 값이 된다.

range는 키 컬럼이 =, <>, >, >=, <, <=, IS NULL, <=>, BETWEEN, 또는 IN 연산자를 사용하는 상수 (constant)와 비교할 때 사용될 수 있다:

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);

index

이 조인 (join) 타입은 ALL과 동일하지만, 인덱스 트리 (index tree)만을 스캔한다는 점에서 다르다. 일반적으로, 보통의 인덱스 파일이 데이터 파일보다 작기 때문에, 이것은 ALL 보다는 빠르게 동작한다.

MySQL은 쿼리가 단일 인덱스의 일부분인 컬럼만을 사용할 때 이 조인 (join) 타입을 사용한다.

ALL

이전 테이블에서 읽어온 각각의 열을 조합하기 위해 전체 테이블 스캔을 실행한다. 테이블이 const가 표시되지 않은 첫 번째 테이블이고, 다른 모든 경우에 있어서 매우 좋지 않은 경우라면, 이것은 그리 좋은 경우가 아니다. 일반적인 경우에는, 이전 테이블에서 가져온 상수(constant) 값 또는 컬럼 값을 사용해서 테이블 열을 추출하는 인덱스를 추가하면 ALL을 피할 수가 있다.

possible_keys

possible_keys 컬럼은 이 테이블에서 열을 찾기 위해 MySQL이 선택한 인덱스를 가리킨다. 이 컬럼은 EXPLAIN 결과에서 나타나는 테이블 순서와는 전적으로 별개의 순서가 된다. 이것은, possible_keys에 있는 키 중에 어떤 것들은 테이블 순서를 만드는 과정에서는 사용되지 않을 수도 있음을 의미하는 것이다.

만일 이 컬럼 값이 NULL이라면, 연관된 인덱스가 존재하지 않게 된다. 이와 같은 경우, 여러분은 WHERE 구문을 검사해서, 이 구문이 인덱스 하기에 적당한 컬럼을 참조하고 있는지 여부를 알아 봄으로써 쿼리 속도를 개선 시킬 수가 있게 된다. 그러한 경우라면, 적절한 인덱스를 하나 생성한 후에, EXPLAIN을 다시 사용해서 쿼리를 검사한다.

테이블이 어떤 인덱스를 가지고 있는지를 보기 위해서는, SHOW INDEX FROM tbl_name를 사용한다.

key

key 컬럼은 MySQL이 실제로 사용할 예정인 키 (인덱스)를 가리킨다. 만일 아무런 인덱스도 선택되지 않았다면, 그 키는 NULL이 된다. MySQL로 하여금 possible_keys 컬럼에 있는 인덱스를 사용하거나 또는 무시하도록 만들기 위해서, FORCE INDEX, USE INDEX, 또는 IGNORE INDEX를 쿼리에서 사용하도록 한다.

MyISAM 및 BDB 테이블의 경우에는, ANALYZE TABLE를 구동시키면 옵티마이저가 보다 좋은 인덱스를 선택하도록 도움을 줄 수가 있다. MyISAM 테이블의 경우에는, myisamchk --analyze 가 동일한 역할을 한다.

key_len

key_len 컬럼은 MySQL이 사용하기로 결정한 키의 길이를 나타낸다. 만일 key 컬럼이 NULL이라면, 이 값도 NULL이 된다. key_len 값은 다중-부분 (multiple-part) 키 중에 얼마나 많은 부분을 MySQL이 실제로 사용하는지를 여러분이 알 수 있도록 해 준다.

ref

ref 컬럼은 테이블에서 열을 선택하기 위해 key 컬럼 안에 명명되어 있는 인덱스를 어떤 컬럼 또는 상수(constant)와 비교하는지를 보여준다.

rows

rows 컬럼은 MySQL이 쿼리를 실행하기 위해 조사해야 하는 열의 숫자를 가리킨다.

Extra

이 컬럼은 MySQL이 쿼리를 어떻게 해석하는지에 관한 추가적인 정보를 제공한다. 이 컬럼이 가질 수 있는 값은 다음과 같다:

Distinct

MySQL은 명확한 값 (distinct value)를 찾게 되며, 따라서 MySQL이 매칭되는 열을 찾게 되면 더 이상의 열에 대해서는 검색을 중단한다.

Not exists

MySQL은 쿼리상에서 LEFT JOIN 최적화를 실행 했으며, 이 최적화와 매치되는 열을 찾은 후에는 더 이상 이 테이블에서 이전 열 조합 검색을 하지 않게 된다. 이러한 방식으로 최적화가 되는 쿼리 타입의 예는 다음과 같다:

SELECT * FROM t1 LEFT JOIN t2 ON t1.id=t2.id

  WHERE t2.id IS NULL;

t2.id를 NOT NULL로 정의했다고 가정하자. 이와 같은 경우, MySQL은 t1을 스캔하고 t1.id 값을 사용해서 t2에 있는 열을 검색한다. 만일 MySQL이 t2에서 매칭되는 열을 발견하면, MySQL은 t2.id 가 결코 NULL이 아님을 알게 되며, 따라서 동일한 id 값을 가지고 있는 t2에서는 더 이상 열을 스캔하지 않게 된다. 달리 표현하면, t1에 있는 각 열에 대해서, MySQL은 t2에서는 단일 검색 (lookup)만을 하게 되며, t2에서 실제로 얼마나 많은 열이 매치가 되는지는 상관이 없게 된다.

range checked for each record (index map: N)

MySQL은 사용하기에 좋은 인덱스를 찾지 못했으나, 이전 테이블에서 컬럼 값을 찾고 난 후에는 사용할 수도 있을 법한 인덱스는 알아냈다. 이전 테이블에 있는 각 열 조합에 대해서는, MySQL은 그 조합이 열을 추출하기 위해서 range 또는 index_merge 접근 방식을 사용할 수 있는지를 검사한다. 이 방법은 그리 빠른 방법은 아니지만, 인덱스를 전혀 사용하지 않는 것 보다는 빠르게 진행한다.

Using filesort

MySQL은 저장된 순서에 따라서 열을 추출하는 방법을 찾기 위해 기타 과정을 진행한다. 정렬 (sort)은 조인 (join) 타입과 정렬 키 및 WHERE 구문과 매치가 되는 모든 열에 대한 열 포인터 (pointer)를 사용해서 모든 열에 걸쳐 진행 된다. 그런 다음에 그 키는 저장이 되고 열은 저장 순서에 따라서 추출된다.

Using index

인덱스 트리에 있는 정보만을 가지고 테이블에서 컬럼 정보를 추출한다. 쿼리가 단일 인덱스의 일부 컬럼만을 사용하는 경우에, 이러한 전략을 사용할 수가 있다.

Using temporary

쿼리를 해석하기 위해서는, 결과를 저장할 임시 테이블을 하나 생성해야 한다. 만일 쿼리가 컬럼을 서로 다르게 목록화 하는 GROUP BY 및 ORDER BY 구문을 가지고 있는 경우에 이런 것이 일어나게 된다.

Using where

WHERE 구문은 다음 테이블에 대한 열 매치 (match) 또는 클라이언트에 보내지는 열을 제한하기 위해 사용된다. 테이블에서 모든 열을 조사하거나 불러올 의도가 특별히 없다면, Extra 값이 Using where 가 아니고, 테이블 조인 (join) 타입이 ALL 또는 index일 경우에는 쿼리에 문제가 생길 수도 있다.

만일 여러분이 가능한 한 빠른 쿼리를 만들고 싶다면, Extra Using filesort 및 Using temporary 값을 조사하도록 한다.

Using sort_union(...), Using union(...), Using intersect(...)

이것들은 인덱스 스캔이 어떻게 index_merge 조인 타입과 병합 (merge)이 되는지를 나타낸다. Section 7.2.6, “인덱스 병합 최적화”를 참조할 것.

Using index for group-by

테이블 접근에 대한 Using index 방식과 유사한 Using index for group-by 방식은MySQL이 실제 테이블을 추가적으로 검색을 하지 않고서도, GROUP BY 또는 DISTINCT 쿼리의 모든 컬럼을 추출 (retrieve)하기 위해 사용될 수 있는 인덱스를 찾았음을 가리킨다. 또한, 그 인덱스는 각 그룹에 대해 가장 효과적인 방식으로 사용되기 때문에, 적은 수의 인덱스 엔트리만이 읽혀지게 된다.

Using where with pushed condition

이 아이템은 NDB Cluster 테이블에만 적용된다. 이것은 MySQL 클러스터가 인덱스가 되지 않은 컬럼 (non-indexed column)과 상수 (constant) 간의 직접 비교 (direct comparision (=))의 효율성을 개선하기 위해서 조건문을 푸시 다운 (condition pushdown) 하는 중이라는 의미를 갖는다. 이와 같은 경우, 조건문은 동시에 값이 검사되는 클러스터의 모든 데이터 노드로 “푸시 다운 (pushed down)” 된다. 이것은 매치되지 않는 열을 네트워크 전체에 보낼 필요성을 없애 주며, 조건문 푸시 다운을 하지 않는 경우에 비해서 5 ~ 10배의 속도 향상을 얻을 수가 있다.

여러분이 아래와 같은 클러스터 테이블을 가지고 있다고 가정하자:

CREATE TABLE t1 (

    a INT,

    b INT,

    KEY(a)

) ENGINE=NDBCLUSTER;

이와 같은 경우, 조건문 푸시 다운은 아래와 같은 쿼리와 함께 사용될 수 있다:

SELECT a,b FROM t1 WHERE b = 10;

이것은 EXPLAIN SELECT 결과를 통해서 볼 수가 있는데, 그 결과는 다음과 같다:

mysql> EXPLAIN SELECT a,b FROM t1 WHERE b = 10\G

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

        table: t1

         type: ALL

possible_keys: NULL

          key: NULL

      key_len: NULL

          ref: NULL

         rows: 10

        Extra: Using where with pushed condition

조건문 푸시 다운은 다음의 쿼리와 함께 사용할 수 없다:

SELECT a,b FROM t1 WHERE a = 10;

SELECT a,b FROM t1 WHERE b + 1 = 10;

첫 번째 쿼리의 경우에는 조건문 푸시 다운을 적용할 수가 없는데, 그 이유는 인덱스가 컬럼 a에 존재하기 때문이다. 두 번째 경우에 대해서 조건문 푸시 다운을 사용할 수 없는 이유는, 인덱스가 되지 않은 컬럼 b를 포함하는 비교문이 간접적이기 때문이다. (하지만, WHERE 구문에서 b + 1 = 10 을 b = 9 로 줄여서 비교를 한다면 푸시 다운을 사용할 수가 있다.)

하지만, > 또는 < 연산자를 사용해서 인덱스된 컬럼을 상수(constant)와 비교를 하는 경우에는 조건문 푸시 다운을 사용할 수가 있다:

mysql> EXPLAIN SELECT a,b FROM t1 WHERE a<2\G

*************************** 1. row ***************************

           id: 1

  select_type: SIMPLE

        table: t1

         type: range

possible_keys: a

          key: a

      key_len: 5

          ref: NULL

         rows: 2

        Extra: Using where with pushed condition

조건문 푸시 다운에 관련해서는 아래의 사항을 기억하기 바란다:

조건문 푸시 다운은 MySQL 클러스터에만 관련이 있으며, 다른 스토리지 엔진을 사용하고 있는 테이블에 대해서 쿼리를 실행할 경우에는 발생하지 않는다.
조건문 푸시 다운 기능은 디폴트로 사용되지 않는다. 이 기능을 활성화 시키기 위해서는, mysqld을 --engine-condition-pushdown 옵션과 함께 시작하거나, 또는 아래의 명령문을 실행한다:

SET engine_condition_pushdown=On;

조건문 푸시 다운, Using where with pushed condition, 그리고 engine_condition_pushdown 등은 모두 5.0 클러스터에서 추가 되었다.

여러분은 EXPLAIN 결과에 있는 rows 컬럼 값을 사용하면 좋은 조인 (join)을 얻는 방법을 알아 낼 수가 있다. 이것은 MySQL이 쿼리를 실행하기 위해서 조사해야 하는 열의 수가 얼마나 되는지 대략적으로 알려준다. 만일 여러분이 max_join_size 시스템 변수를 사용해서 쿼리를 제한하면, 이러한 열은 다중-테이블 SELECT 명령문을 실행해야 하는지 아니면 무시해야 하는지를 결정할 때 이 열 값을 사용할 수도 있다.

아래의 예제는 EXPLAIN에 의해 얻어진 정보를 가지고서 다중-테이블 조인을 어떻게 최적화 시키는 지를 설명하는 것이다.

다음과 같은 SELECT 명령문을 가지고 있으며, EXPLAIN을 사용해서 이것을 조사한다고 가정하자:

EXPLAIN SELECT tt.TicketNumber, tt.TimeIn,

               tt.ProjectReference, tt.EstimatedShipDate,

               tt.ActualShipDate, tt.ClientID,

               tt.ServiceCodes, tt.RepetitiveID,

               tt.CurrentProcess, tt.CurrentDPPerson,

               tt.RecordVolume, tt.DPPrinted, et.COUNTRY,

               et_1.COUNTRY, do.CUSTNAME

        FROM tt, et, et AS et_1, do

        WHERE tt.SubmitTime IS NULL

          AND tt.ActualPC = et.EMPLOYID

          AND tt.AssignedPC = et_1.EMPLOYID

          AND tt.ClientID = do.CUSTNMBR;

위 예제에 대해서, 다음과 같은 가정을 하도록 하자:

비교가 되는 컬럼은 아래와 같이 선언 되었다:

*Table*	*Column*	*Data Type*
`Tt`	`ActualPC`	`CHAR(10)`
`Tt`	`AssignedPC`	`CHAR(10)`
`Tt`	`ClientID`	`CHAR(10)`
`Et`	`EMPLOYID`	`CHAR(15)`
`Do`	`CUSTNMBR`	`CHAR(15)`

테이블은 아래와 같은 인덱스를 가지고 있다:

*Table*	*Index*
`Tt`	`ActualPC`
`Tt`	`AssignedPC`
`Tt`	`ClientID`
`Et`	`EMPLOYID` (primary key)
`Do`	`CUSTNMBR` (primary key)

tt.ActualPC 값은 골고루 분산되지 않는다.

최적화가 실행되지 전에, EXPLAIN 명령문은 다음과 같은 정보를 생성한다:

table type possible_keys key  key_len ref  rows  Extra

et    ALL  PRIMARY       NULL NULL    NULL 74

do    ALL  PRIMARY       NULL NULL    NULL 2135

et_1  ALL  PRIMARY       NULL NULL    NULL 74

tt    ALL  AssignedPC,   NULL NULL    NULL 3872

                 ClientID,

                 ActualPC

           range checked for each record (key map: 35)

type 은 모든 테이블에 대해 ALL이기 때문에, 이 결과 값은 MySQL이 모든 테이블에 대해서 하나의 카르테시안 (Cartesian) 값을 생성하는 중이라는 것을 가리킨다; 즉, 열에 대한 모든 조합. 이 과정은 각각의 테이블에 있는 열의 숫자를 조사해야 하기 때문에 시간이 오래 걸리게 된다. 위의 경우에는, 74 × 2135 × 74 × 3872 = 45,268,558,720 열이 된다.

만일 컬럼 상의 인덱스들을 동일한 타입과 크기로 선언할 경우에는, MySQL이 이를 효과적으로 처리하는데 한가지 문제가 생긴다. 위의 문장에서 보면, VARCHAR 및 CHAR의 크기를 동일하게 선언하면, 이것들은 동일한 것으로 간주가 된다. tt.ActualPC는 CHAR(10)로 선언 되었고 et.EMPLOYID는 CHAR(15)로 선언 되었기 때문에, 길이가 맞지 않게 된다.

컬럼 길이 간의 이러한 문제를 해결 하기 위해서는, ALTER TABLE를 사용해서 ActualPC의 길이를 10 개 문자에서 15 문자로 늘리도록 한다:

mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15);

이제 tt.ActualPC 및 et.EMPLOYID는 모두 VARCHAR(15)가 된다. EXPLAIN 명령문을 다시 실행하면 아래와 같은 결과를 얻게 된다:

table type   possible_keys key     key_len ref         rows    Extra

tt    ALL    AssignedPC,   NULL    NULL    NULL        3872    Using

             ClientID,                                         where

             ActualPC

do    ALL    PRIMARY       NULL    NULL    NULL        2135

      range checked for each record (key map: 1)

et_1  ALL    PRIMARY       NULL    NULL    NULL        74

      range checked for each record (key map: 1)

et    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC 1

이 결과 값은 완벽하지는 않지만 많이 개선이 된 것이다: rows 값은 74 보다 작다. 이와 같은 실행은 수초 정도 걸린다.

두 번째 대안으로는, tt.AssignedPC = et_1.EMPLOYID 와 tt.ClientID = do.CUSTNMBR 비교에서 컬럼 길이가 일치하지 않는 것을 제거하는 것이다:

mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),

    ->                MODIFY ClientID   VARCHAR(15);

이와 같이 수정을 하면, EXPLAIN은 다음과 같은 결과를 만들게 된다:

table type   possible_keys key      key_len ref           rows Extra

et    ALL    PRIMARY       NULL     NULL    NULL          74

tt    ref    AssignedPC,   ActualPC 15      et.EMPLOYID   52   Using

             ClientID,                                         where

             ActualPC

et_1  eq_ref PRIMARY       PRIMARY  15      tt.AssignedPC 1

do    eq_ref PRIMARY       PRIMARY  15      tt.ClientID   1

이렇게 하고 나면, 쿼리는 거의 최적화가 이루어진다. 이제 남아 있는 문제는, MySQL이 tt.ActualPC 컬럼에 있는 값들은 골고루 분포되어 있으나, tt 테이블에 대해서는 그렇지 않다고 가정하고 있다는 점이다. 다행스러운 것은, MySQL로 하여금 키 분포도를 분석하도록 만드는 것이 쉽다는 점이다:

mysql> ANALYZE TABLE tt;

추가적인 인덱스 정보를 사용하면, 조인 (join)은 완벽해 지고 EXPLAIN은 아래와 같은 결과를 만들게 된다:

table type   possible_keys key     key_len ref           rows Extra

tt    ALL    AssignedPC    NULL    NULL    NULL          3872 Using

             ClientID,                                        where

             ActualPC

et    eq_ref PRIMARY       PRIMARY 15      tt.ActualPC   1

et_1  eq_ref PRIMARY       PRIMARY 15      tt.AssignedPC 1

do    eq_ref PRIMARY       PRIMARY 15      tt.ClientID   1

EXPLAIN 결과에 있는 rows 컬럼은 MySQL 조인 (join) 최적화를 통해서 개선된다는 점을 알아두자. rows 가 만들어 내는 값과 쿼리가 리턴하는 열의 실제 숫자를 비교함으로써 그 숫자가 거의 일치하는지를 검사해야 한다. 만일 그 숫자가 많이 차이가 난다면, SELECT 명령문에서 STRAIGHT_JOIN을 사용하고 FROM 구문에서 테이블 순서를 다르게 하면 보다 나은 성능을 얻을 수가 있을 것이다.

출처: http://www.mysqlkorea.co.kr/sub.html?mcode=manual&scode=01&m_no=21444&cat1=7&cat2=217&cat3=227&lang=k

숨쉬기가 답답할 때. 호흡이 답답한 증상

예진이네집 괴스트 — Wed, 28 Jul 2010 20:57:03 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

기관지가 안 좋은 분들에게 잘 나타나는 증상인데요.

감기나 기침도 없고 다른 아무런 증상도 없는데 이상하게 호흡이 안편한 경우가 있습니다.
특히 잠을 잘 때 안 편하지요. 그렇게 되면 코를 안 골던 사람도 코를 콜 게 됩니다. 답답하니까 푸우~하고 입으로 숨을 내 쉬는 잠을 자게 되는 것입니다. 어떤 분들은 가슴에 살이 찌면 그러더라 말하는 분들도 있습니다.
특히 운동을 많이 한 날이나 술을 먹은 날 심해 집니다.

그러나 근본 치료는 차고 더움을 관찰하고 생활을 조절해야만 치료가 됩니다.
방치를 하게 되면 점점 심해져서 평소에도 숨이 잘 안 쉬어지는 상태로 가게 되고 더 심해지면 호흡부전이 되기도 합니다.

목 아래로 두 번째 부분의 뼈를 눌러보면 아플 것입니다.
실내 온도가 차가워지면 가슴 부위가 차가워지면서 그런 증상을 느끼는 경우와 가슴에 열이 많아지면서 그런 증상을 느끼는 두 종류가 있게 됩니다.
자신의 증상이 어느 쪽인가를 먼저 판단해야만 합니다.

쉽게 판단을 하는 방법이 있습니다.
며칠 간 방안이 좀 춥고 옷을 많이 입고 지내지 않았다면, 일단 두꺼운 옷을 입고 몸을 덥게 해 봅니다. 그렇게 30분간 있어 봅니다.
이 때 상태가 약간 호전이 되거나 감각이 좋아지면, "아, 그동안 몸이 차가웠구나 판단하고 방안의 온도도 올리고 음식도 열량이 많고 따뜻한 음식 위주로 먹어야합니다.
절대 냉성의 음식은 멀리해야 하며 과일이나 채식은 안하는 것이 좋습니다.
그렇게 3일간만 하세요.
약을 쓴다면 비타민 E를 이 때 먹는 것입니다.
그러면 좋아집니다. 좋아지고 나서는 방안의 온도를 너무 높지 않게 약간 조절하세요.

반대로 두꺼운 옷을 입고 몸을 덥게 하는데 더 감각이 안 좋아지고 상태가 이상하다. 싶으면, "아차 몸을 덥게 하면 안되는 구나." 판단하고 옷을 모두 시원하게 입고 방안의 온도를 팍 내리고 음식도 모두 시원한 음식 위주로 먹습니다.
과일도 먹고 채식을 좀 합니다. 도라지도 이 때 먹는 것입니다.
위와 같이 3일 정도 하면 대부분 좋아집니다. 3일이 넘고 나면 방안의 온도를 다시 중립으로 잘 조절하세요.

(몸이 차가우면서 숨이 답답할 때는, 술을 드셔도 맥주나 매실주를 먹게 되면 잠을 자면서 상태가 더욱 안 좋아지면서 코를 골게 되는 것입니다.
이 때는 실내 온도를 올리고 옷을 더 입으며 인삼을 먹고 비타민 E를 먹어서 보온이 되게 하면 자연스럽게 해소가 되게 됩니다.)

그러나 반대로 열이 많으면서 그럴 때는 상체의 옷을 시원하게 입고 실내 온도를 며칠간만 내리고 도라지나 백년초 열매를 복용 해 주면 다시 좋아집니다.

백년초 열매는 기침이 나고 가래가 나올 때까지 복용하고 가래가 나오기 시작하고 3일 정도 지나면 복용을 중지해야 합니다.
열매의 가시들을 잘 긁어 제거하고 네쪽으로 나누어서 그대로 오물오물 씹어서 씨는 씹지말고 그냥 함께 삼킵니다.
먹기가 사나우면 열매를 쪼개서 그 분량과 같은 설탕으로 제어서 냉장고에 넣어두고 드시면 됩니다.
이 때 별도의 물은 섞지 마세요.
그리고 백년초열매를 복용할 때 너무 심하게 기침이 난다면 가슴부위를 특별하게 보온하고 몸을 따뜻하게 하세요 그러면 기침은 멈추고 가래만 배출이 됩니다.

일반적으로 기관지 쪽에 염증이 있고 가래가 덥고 있다면 반드시 모두 배출이 되어야합니다.
그러나 염증이 아직있는 관계로 배출을 해도 계속 도로 가래가 낍니다. 그렇기 때문에 계속 가래 배출이 이루어지면서 염증이 소멸되어 가야 합니다.
마지막에는 가래가 안 나오게 되는데 그 때가 완치 된 것입니다.
그 과정 중에 기침이 심하다 싶으면 반드시 보온을 해서 몸을 따뜻하게 조절하면서 그 과정을 완수해야 합니다.
백년초 열매를 복용하는 과정에 다른 부작용이 있다면 5일 정도 복용하고 7주일을 쉬고 다시 복욕하며 그렇지 않다면 가래가 완전하게 멈출 때까지 복용하면 됩니다.
그리고 가슴 부위에 열이 많다고 판단이 된다면 (다른 곳보다 피부색깔이 붉거나 하면 열이 많다고 보면 된다. 또 잘 모르겠으면 차가운 물건과 따듯한 물건을 두가지 준비를 하고 각각 가슴 복판에 대 본다. 환부가 어느 쪽을 대니 감각이 편해지는 지를 보고 그 쪽을 선택하면 된다.)백년초 열매를 복용하면서 더불어서 가슴 복판 외부에 지속적으로 차가운 걸 대서 열을 뺀다 그러면 신속하게 회복이 된다.
그러다가 만약 기침이 심해지면 중지하고 따뜻하게 조치를 해야한다.

가슴 부위가 찬지 더운지를 모른다면 두꺼운 옷을 입고 시험을 하셔야 합니다.
두터운 옷을 입었을 때 숨이 편해진다면 몸이 춥워서 숨이차고 가슴이 답답해진 것이므로 몸을 따뜻하게 조치를 한다는 것입니다.
그리고 두꺼운 옷을 입었을 때 좋아지기는 커녕, 더욱 답답해진다면 현재 몸의 열이 많아서 숨이 차고 가슴이 답답한 것입니다.
평소에 안 그렇다가 그런 현상이 자주 나타난다면 주의를 하세요.
대체로 나이가 들어가면서 그런 증상이 없던 사람도 나타납니다.

운동도 좀 해주세요. 적절한 운동이 뭐냐고요?
상체 운동은 부드럽게 천천히 마치 자유형 수영하는 듯한 동작을 해 주면 숨이 편해지면서 밤에 답답한 호흡을 하지 않게 될 것입니다.
반드시 담배를 끊어야 하고요.
계속 방치하면 점차 심해지니까 조심을 하세요.

2010년 남아공 월드컵 일정표 (1400x1050)

예진이네집 괴스트 — Mon, 14 Jun 2010 16:57:10 +0900

크리에이티브 커먼즈 라이선스

이 저작물은 크리에이티브 커먼즈 코리아 저작자표시-비영리-동일조건변경허락 2.0 대한민국 라이선스에 따라 이용하실 수 있습니다.

남아공 일정표 입니당..

바탕화면으로 깔아놓고 주요경기를 보는 센쓰... ㅋㅋ