首页 > 数据库 > MySQL > 正文

mysql中索引与FROM_UNIXTIME的问题

2024-07-24 12:51:44
字体:
来源:转载
供稿:网友

零、背景

这周四收到很多告警,找DBA看了看,发现有个慢查询。

简单收集一些信息后,发现这个慢查询问题隐藏的很深,问了好多人包括DBA都不知道原因。

一、问题

有一个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: BTREE6 rows in set (0.02 sec)

然后我写了一个SQL如下:

SELECT count(*)FROM d_union_stat.t_local_cache_log_metawhere `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: 5809647SET 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. 右值是 FROM_UNIXTIME 函数。

于是查询MYSQL官方文档,发现6个不是问题。

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 函数了。

然后看看MYSQL的INDEX小节,找到一点蛛丝马迹。

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.

发表评论 共有条评论
用户名: 密码:
验证码: 匿名发表