mysql의 인덱스 및 FROM_UNIXTIME 문제에 대한 자세한 설명

본 글은 mysql에서 index와 FROM_UNIXTIME 사이의 이슈에 대한 관련 정보를 주로 소개하고 있습니다. 필요한 친구들은

Zero 및 background

를 참고하시면 됩니다. 이번주 목요일에 알림을 많이 받았는데 DBA에게 요청한 결과 살펴보니 느린 쿼리를 발견했습니다.

단순히 정보를 수집한 결과, 이 느린 쿼리 문제는 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 function입니다.

그래서 공식 MYSQL 문서를 확인해 보니 6개는 문제가 없는 것으로 나타났습니다.

모든 스토리지 엔진은 테이블당 최소 16개의 인덱스와 최소 256바이트의 총 인덱스 길이를 지원합니다.
대부분의 스토리지 엔진은 더 높은 제한을 가지고 있습니다.

그래서 문제가 FROM_UNIXTIME 함수에 있다고 의심했습니다.

그런 다음 MYSQL의 INDEX 섹션을 살펴보고 몇 가지 단서를 찾으세요.

1.WHERE 절과 일치하는 행을 빠르게 찾으려면.
2. 행을 고려 대상에서 제거하려면
여러 인덱스 중에서 선택할 수 있는 경우 MySQL은 일반적으로 가장 적은 수의 행을 찾는 인덱스를 사용합니다. 3. 테이블에 다중 열 인덱스가 있는 경우 최적화 프로그램은 인덱스의
왼쪽가장 접두사를 사용하여 행을 조회할 수 있습니다.4. MySQL은
선언d인 경우 열의 인덱스를 더 효율적으로 사용할 수 있습니다. 다른 열 비교(예를 들어
문자열 열을 임시 또는 숫자 열과 비교)는 prev값을 비교할 수 없는 경우 dir적으로 인덱스를 사용할 수 있습니다. 변환 없이 .4조를 보니 유형이 다르면 색인이 생성되지 않을 수 있다고 언급되어 있습니다. FROM_UNIXTIME의 반환 값을 string

유형으로 변환할 수 없는 것은 아닐까요?

따라서 FROM_UNIXTIME 함수

의 반환 값을 쿼리하세요.

MySQL FROM_UNIXTIME() <a href="http://www.php.cn/wiki/135.html" target="_blank">return<br/>은 <a href="http://www .php.cn/wiki/1255.html" target="_blank">date</p> /datetime은 unix_timestamp 버전의 것입니다.

MySQL FROM_UNIXTIME() <a href="http://www.php.cn/wiki/135.html" target="_blank">return</a>s a <a href="http://www.php.cn/wiki/1255.html" target="_blank">date</a> /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의 인덱스 및 FROM_UNIXTIME 문제에 대한 자세한 설명의 상세 내용입니다. 자세한 내용은 PHP 중국어 웹사이트의 기타 관련 기사를 참조하세요!