Mysql: mysql between 日期索引 索引问题-日期索引使用

表结构:

dep_date

dep

arr

联合索引: ind_coll_date_route  (dep_date ,dep,arr)

这两天发现原来的查询效率慢了,使用explain 查看,居然没有使用索引, 
我的索引是日期类型的,首先想到的是mysql对日期类型的索引的处理机制是不是不同,在where条件里试了几种,发现效果都差不多,

where dep_date >= ‘20161121’ 
where dep_date  >= ‘2016-11-21’ 
where dep_date  between ‘2016-11-01’ and ‘2016-11-21’

还有各种函数,最后发现结论都是一样的,在baidu上查询也没有有价值的内容。

最后发现了一些规律,但不知道是否有普遍性,即:

在查询数据条数约占总条数五分之一以下时能够使用到索引,但超过五分之一时,则使用全表扫描了。

试了多张表,均是这个结论, 所以想这个五分之一应该是在某一个地方设置的,或者是系统默认在查询优化时的一个经验值,在以后的处理的进修引起注意。

解决办法:

强制走索引

SELECT *
FROM  `table_xxx`
FORCE INDEX ( ind_coll_date_route )
WHERE dep_date
BETWEEN  ‘2017-12-01‘
AND  ‘2017-12-30‘

  

时间: 2024-07-30 08:55:26

Mysql: mysql between 日期索引 索引问题-日期索引使用的相关文章

mysql性能优化-慢查询分析、优化索引和配置

一.优化概述 二.查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三.配置优化 1)      max_connections 2)      back_log 3)      interactive_timeout 4)      key_buffer_size 5)      query_cache_size 6)      record_buffer_size 7)      read_rnd_buffer

mysql性能优化-慢查询分析、优化索引和配置【转】

一.优化概述 二.查询与索引优化分析 1性能瓶颈定位 Show命令 慢查询日志 explain分析查询 profiling分析查询 2索引及查询优化 三.配置优化 1)      max_connections 2)      back_log 3)      interactive_timeout 4)      key_buffer_size 5)      query_cache_size 6)      record_buffer_size 7)      read_rnd_buffer

Mysql 索引实现原理. 聚集索引, 非聚集索引

Mysql索引实现: B-tree,B是balance,一般用于数据库的索引.使用B-tree结构可以显著减少定位记录时所经历的中间过程,从而加快存取速度.而B+tree是B-tree的一个变种,MySQL就普遍使用B+tree实现其索引结构. 一般来说,索引本身也很大,不可能全部存储在内存中,因此索引往往以索引文件的形式存储的磁盘上.这样的话,索引查找过程中就要产生磁盘I/O消耗,相对于内存存取,I/O存取的消耗要高几个数量级,所以评价一个数据结构作为索引的优劣最重要的指标就是在查找过程中磁盘

MySQL优化GROUP BY-松散索引扫描与紧凑索引扫描

满足GROUP BY子句的最一般的方法是扫描整个表并创建一个新的临时表,表中每个组的所有行应为连续的,然后使用该临时表来找到组并应用累积函数(如果有).在某些情况中,MySQL能够做得更好,即通过索引访问而不用创建临时表. 为GROUP BY使用索引的最重要的前提条件是所有GROUP BY列引用同一索引的属性,并且索引按顺序保存其关键字.是否用索引访问来代替临时表的使用还取决于在查询中使用了哪部分索引.为该部分指定的条件,以及选择的累积函数. 由于GROUP BY 实际上也同样会进行排序操作,而

MySQL中IN子查询会导致无法使用索引

原文:MySQL中IN子查询会导致无法使用索引 今天看到一个博客园的一篇关于MySQL的IN子查询优化的案例,一开始感觉有点半信半疑(如果是换做在SQL Server中,这种情况是绝对不可能的,后面会做一个简单的测试.)随后动手按照他说的做了一个表来测试验证,发现MySQL的IN子查询做的不好,确实会导致无法使用索引的情况(IN子查询无法使用所以,场景是MySQL,截止的版本是5.7.18) MySQL的测试环境 测试表如下 create table test_table2 ( id int a

mysql重复索引、冗余索引、未使用索引的定义和查找

1.冗余和重复索引 mysql允许在相同列上创建多个索引,无论是有意还是无意,mysql需要单独维护重复的索引,并且优化器在优化查询的时候也需要逐个地进行考虑,这会影响性能.重复索引是指的在相同的列上按照相同的顺序创建的相同类型的索引,应该避免这样创建重复所以,发现以后也应该立即删除.但,在相同的列上创建不同类型的索引来满足不同的查询需求是可以的. 冗余索引和重复索引有一些不同,如果创建了索引(a,b),再创建索引(a)就是冗余索引,因为这只是前面一个索引的前缀索引,因此(a,b)也可以当作(a

MySQL B+树索引和哈希索引的区别

导读 在MySQL里常用的索引数据结构有B+树索引和哈希索引两种,我们来看下这两种索引数据结构的区别及其不同的应用建议. 二者区别 备注:先说下,在MySQL文档里,实际上是把B+树索引写成了BTREE,例如像下面这样的写法: CREATE TABLE t(aid int unsigned not null auto_increment,userid int unsigned not null default 0,username varchar(20) not null default ‘’,

Mysql数据库优化技术之配置篇、索引篇 ( 必看 必看 转)

转自:Mysql数据库优化技术之配置篇.索引篇 ( 必看 必看 ) (一)减少数据库访问 对于可以静态化的页面,尽可能静态化 对一个动态页面中可以静态的局部,采用静态化 部分数据可以生成XML,或者文本文件形式保存 使用数据缓存技术,例如: MemCached (二)优化的检测方法 1.用户体验检测 2.Mysql状态检测 在Mysql命令行里面使用show status命令,得到当前mysql状态. 主要关注下列属性: key_read_requests (索引读的请求数)(key_buffe

Mysql学习笔记(四)聊聊数据库索引

小心情(可直接跳到分割线后) 今天心情好些了.一些浓的化不开的坏情绪,也渐渐的在晚上解决掉一个复杂的逻辑问题后,渐渐消散了. 今天中午去吃饭的时候,坤哥漫不经心的说:'我这么多年终于悟出了一个道理,人年轻的时候不要那么拼命,都没有时间做其他事情了' 我问什么其他事情,坤哥看了我一眼,又继续漫不经心的说,那么忙,都没有时间谈恋爱了. 我想不那么拼命可以嘛?房价每年都涨,生活的成本与日俱增.如果不努力让自己的价值所赚取的金钱,超过经济增速.那么只能继续成为一个社会底层的loser,继续在青春的美好时