小編給大家分享一下MySQL中索引與FROM_UNIXTIME的問題示例，相信大部分人都還不怎么了解，因此分享這篇文章給大家參考一下，希望大家閱讀完這篇文章后大有收獲，下面讓我們一起去了解一下吧！

創(chuàng)新互聯(lián)建站專注為客戶提供全方位的互聯(lián)網(wǎng)綜合服務(wù)，包含不限于成都網(wǎng)站設(shè)計(jì)、做網(wǎng)站、融水網(wǎng)絡(luò)推廣、小程序開發(fā)、融水網(wǎng)絡(luò)營銷、融水企業(yè)策劃、融水品牌公關(guān)、搜索引擎seo、人物專訪、企業(yè)宣傳片、企業(yè)代運(yùn)營等，從售前售中售后，我們都將竭誠為您服務(wù)，您的肯定，是我們最大的嘉獎(jiǎng)；創(chuàng)新互聯(lián)建站為所有大學(xué)生創(chuàng)業(yè)者提供融水建站搭建服務(wù)，24小時(shí)服務(wù)熱線：028-86922220，官方網(wǎng)址：chinadenli.net

零、背景

簡單收集一些信息后，發(fā)現(xiàn)這個(gè)慢查詢問題隱藏的很深，問了好多人包括DBA都不知道原因。

一、問題

有一個(gè)DB, 有一個(gè)字段, 定義如下.

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)

然后我寫了一個(gè)SQL如下:

SELECT 
  count(*)
FROM
  d_union_stat.t_local_cache_log_meta
where
  `c_mtime` < FROM_UNIXTIME(1494485402);

終于有一天DBA過來了, 扔給我一個(gè)流水，說這個(gè)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;

我頓時(shí)無語了，我的DB都是加了索引，SQL都是精心優(yōu)化了的，怎么是慢SQL呢？

問為什么是慢SQL，DBA答不上來， 問了周圍的同事也都答不上來。

我心里暗想遇到一個(gè)隱藏很深的知識點(diǎn)了。

令人懷疑的地方有兩個(gè)：1.有6個(gè)索引。 2. 右值是 FROM_UNIXTIME 函數(shù)。

于是查詢MYSQL官方文檔，發(fā)現(xiàn)6個(gè)不是問題。

All storage engines support at least 16 indexes per table and a total index length of at least 256 bytes.  
Most storage engines have higher limits.

于是懷疑問題是 FROM_UNIXTIME 函數(shù)了。

然后看看MYSQL的INDEX小節(jié)，找到一點(diǎn)蛛絲馬跡。

1.To find the rows matching a WHERE clause quickly.
2. To eliminate rows from consideration.
If there is a choice between multiple indexes, MySQL normally uses the index that finds the smallest number of rows.
3.If the table has a multiple-column index, any leftmost prefix of the index can be used by the optimizer to look up rows.
4. MySQL can use indexes on columns more efficiently if they are declared as the same type and size.
Comparison of dissimilar columns (comparing a string column to a temporal or numeric column, for example) may prevent use of indexes if values cannot be compared directly without conversion.

看到第4條的時(shí)候，提到不同類型可能導(dǎo)致不走索引，難道 FROM_UNIXTIME 的返回值不能轉(zhuǎn)化為字符串類型？

于是查詢 FROM_UNIXTIME 函數(shù)的返回值。

MySQL FROM_UNIXTIME() returns a date /datetime from a version of unix_timestamp.

返回的是一個(gè)時(shí)間類型，那強(qiáng)制轉(zhuǎn)化為字符串類型呢？

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)

這次可以看到, 使用了索引，只掃描了一個(gè)數(shù)據(jù)。

二、結(jié)論

這次對 FROM_UNIXTIME 的返回值強(qiáng)制轉(zhuǎn)化一下就可以利用上索引了。

所以這個(gè)SQL不能利用上索引是右值與左值的類型不一致導(dǎo)致的。 。

以上是“mysql中索引與FROM_UNIXTIME的問題示例”這篇文章的所有內(nèi)容，感謝各位的閱讀！相信大家都有了一定的了解，希望分享的內(nèi)容對大家有所幫助，如果還想學(xué)習(xí)更多知識，歡迎關(guān)注創(chuàng)新互聯(lián)行業(yè)資訊頻道！

網(wǎng)頁題目：mysql中索引與FROM_UNIXTIME的問題示例
文章位置：http://chinadenli.net/article24/gpdpce.html

成都網(wǎng)站建設(shè)公司_創(chuàng)新互聯(lián)，為您提供營銷型網(wǎng)站建設(shè)、云服務(wù)器、電子商務(wù)、網(wǎng)頁設(shè)計(jì)公司、品牌網(wǎng)站建設(shè)、企業(yè)建站

廣告

聲明：本網(wǎng)站發(fā)布的內(nèi)容（圖片、視頻和文字）以用戶投稿、用戶轉(zhuǎn)載內(nèi)容為主，如果涉及侵權(quán)請盡快告知，我們將會(huì)在第一時(shí)間刪除。文章觀點(diǎn)不代表本網(wǎng)站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內(nèi)容未經(jīng)允許不得轉(zhuǎn)載，或轉(zhuǎn)載時(shí)需注明來源： 創(chuàng)新互聯(lián)