mysql의 인덱스 및 FROM_UNIXTIME 문제에 대한 자세한 설명
- 小云云원래의
- 2018-01-17 10:45:081829검색
이 글은 mysql의 index와 FROM_UNIXTIME 이슈에 대한 관련 정보를 주로 소개하고 있으니, 필요한 친구들이 참고하시면 도움이 될 것 같습니다.
Zero, background
간단히 정보를 수집해 보니 이런 느린 쿼리 문제가 깊게 숨겨져 있다는 걸 알게 되었어요. DBA를 비롯한 많은 분들에게 물어보니 아직도 그 이유를 모르겠습니다.
1. 문제
다음과 같이 정의된 필드가 있는 DB가 있습니다.
MySQL [d_union_stat]> desc t_local_cache_log_meta; +----------------+--------------+------+-----+---------------------+ | Field | Type | Null | Key | Default | +----------------+--------------+------+-----+---------------------+ | c_id | int(11) | NO | PRI | NULL | | c_key | varchar(128) | NO | MUL | | | c_time | int(11) | NO | MUL | 0 | | c_mtime | varchar(45) | NO | MUL | 0000-00-00 00:00:00 | +----------------+--------------+------+-----+---------------------+ 17 rows in set (0.01 sec)
인덱스는 다음과 같습니다.
MySQL [d_union_stat]> show index from t_local_cache_log_meta \G
*************************** 1. row ***************************
Table: t_local_cache_log_meta
Non_unique: 0
Key_name: PRIMARY
Column_name: c_id
Collation: A
Cardinality: 6517096
Index_type: BTREE
*************************** 2. row ***************************
.
.
.
*************************** 6. row ***************************
Table: t_local_cache_log_meta
Non_unique: 1
Key_name: index_mtime
Column_name: c_mtime
Collation: A
Cardinality: 592463
Index_type: BTREE
6 rows in set (0.02 sec)그리고 다음과 같이 SQL을 작성했습니다.
SELECT count(*) FROM d_union_stat.t_local_cache_log_meta where `c_mtime` < FROM_UNIXTIME(1494485402);
드디어 어느 날 DBA가 와서 이 SQL이 느린 SQL이라고 요약을 하더군요.
# Time: 170518 11:31:14 # Query_time: 12.312329 Lock_time: 0.000061 Rows_sent: 0 Rows_examined: 5809647 SET timestamp=1495078274; DELETE FROM `t_local_cache_log_meta` WHERE `c_mtime`< FROM_UNIXTIME(1494473461) limit 1000;
말문이 막혔습니다. 내 DB는 색인화되어 있고 SQL은 신중하게 최적화되어 있습니다. 왜 SQL이 느린가요?
왜 느린 SQL이냐고 물으니 DBA도 대답을 하지 못했습니다. 주변 동료들도 대답을 하지 못하더군요.
깊이 감춰진 지식 포인트를 만났다는 생각이 몰래 들었습니다.
의심스러운 점은 두 가지입니다. 1. 인덱스가 6개 있습니다. 2. rvalue는 FROM_UNIXTIME 함수입니다.
그래서 공식 MYSQL 문서를 확인해 보니 6개는 문제가 없는 것으로 나타났습니다.
모든 스토리지 엔진은 테이블당 최소 16개의 인덱스와 최소 256바이트의 총 인덱스 길이를 지원합니다.
대부분의 스토리지 엔진은 더 높은 제한을 가지고 있습니다.
그래서 문제가 FROM_UNIXTIME 함수에 있다고 의심했습니다.
그런 다음 MYSQL의 INDEX 섹션을 살펴보고 몇 가지 단서를 찾으세요.
1. WHERE 절과 일치하는 행을 빠르게 찾으려면
2. 여러 인덱스 중에서 선택할 수 있는 경우 MySQL은 일반적으로 가장 적은 수의 행을 찾는 인덱스를 사용합니다. 테이블에 다중 열 인덱스가 있는 경우 최적화 프로그램은 인덱스의 가장 왼쪽 접두사를 사용하여 행을 조회할 수 있습니다.
4. 동일한 유형과 크기로 선언되면 MySQL은 열의 인덱스를 더 효율적으로 사용할 수 있습니다. 서로 다른 열의 비교(예: 문자열 열을 임시 또는 숫자 열과 비교)는 변환 없이 값을 직접 비교할 수 없는 경우 인덱스 사용을 방해할 수 있습니다.
4조를 보니 다른 유형이 있을 수 있다는 언급이 있었습니다. cause inconsistency 인덱스를 살펴보면 FROM_UNIXTIME의 반환값을 문자열 형태로 변환할 수는 없나요?
반환되는 것은 시간 유형인데 강제로 문자열 유형으로 지정하는 것은 어떻습니까? MySQL FROM_UNIXTIME() returns a date /datetime from a version of unix_timestamp.
MySQL [d_union_stat]> explain SELECT
-> *
-> FROM
-> t_local_cache_log_meta
-> where
-> `c_mtime` = CONCAT(FROM_UNIXTIME(1494485402)) \G
*************************** 1. row ***************************
id: 1
select_type: SIMPLE
table: t_local_cache_log_meta
type: ref
possible_keys: index_mtime
key: index_mtime
key_len: 137
ref: const
rows: 1
Extra: Using where
1 row in set (0.01 sec) 이번에는 인덱스를 사용하여 하나의 데이터만 스캔하는 것을 볼 수 있습니다.
2. 결론
이번에는 FROM_UNIXTIME의 반환 값을 강제로 변환하여 인덱스를 사용할 수 있습니다.
그래서 이 SQL은 rvalue와 lvalue의 유형이 일치하지 않기 때문에 상위 인덱스를 사용할 수 없습니다. . 관련 권장 사항:
MySQL에서 두 테이블과 관련된 조인 테이블에 대한 인덱스를 생성하는 방법 자세한 그래픽 및 텍스트 설명
MySQL 파티션 필드 열에 대해 별도의 인덱스를 생성해야 합니까?
위 내용은 mysql의 인덱스 및 FROM_UNIXTIME 문제에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!