mysqldate_sub索引失效

因为该函数会对日期进行改变。根据查询相关公开信息显示，UNIX_TIMESTAMP函数可以替代date_sub函数，从而避免索引失效。

创新互联专注为客户提供全方位的互联网综合服务，包含不限于成都做网站、网站设计、外贸营销网站建设、郫都网络推广、成都小程序开发、郫都网络营销、郫都企业策划、郫都品牌公关、搜索引擎seo、人物专访、企业宣传片、企业代运营等，从售前售中售后，我们都将竭诚为您服务，您的肯定，是我们最大的嘉奖；创新互联为所有大学生创业者提供郫都建站搭建服务，24小时服务热线：18980820575，官方网址：www.cdcxhl.com

MySQL中使用OR连接查询条件不会让索引失效

今天听到一种说法，说OR会使索引失效，最好使用UNION代替。查了一下发现的确有些文章这么说。但总觉得没什么道理。直觉上觉得虽然or连接的查询条件不能使用联合索引，但感觉两个单独的索引是可以用的。看了一些文章，感觉一直很疑惑。

于是试了一下，发现果然如此。

这里的type项是index_merge。搜索后发现是MySQL5.0后的新技术，索引合并。index merge 技术简单说就是在用OR，AND连接的多个查询条件时，可以分别使用前后查询中的索引，然后将它们各自的结果合并交集或并集。当然具体是否使用index merge，优化器会自己选择，比如and连接时有联合索引，或干脆全表查询就很快，就没必要使用它了。

具体可以查阅文档：

还是很有意思的。

可能因为mysql这个东西太复杂，感觉sql优化都快成玄学了。网上流传了很多“奇技淫巧”，让人真假难辨。我觉得可能是过去mysql优化不是很好时，大家有一些优化的技巧，但随着mysql更新优化，现在已经成为过时甚至错误的做法。但这些说法还在流传，造成了我这样的新手的困惑。

所以看来小白要学技术，还是要踏实点多看官方文档，多亲自实践，少看博客，少道听途说。

MySQL: 你的binlog_expire_logs_seconds可能正在失效

如果你正在使用MySQL8.0，并且在使用物理热备工具，那么 binlog_expire_logs_seconds 可能不会如你预想的那样生效。

为了防止 binlog 文件过大导致无可用的磁盘空间，MySQL提供了一个系统变量用来配置过期时间，MySQL5.7时变量名为 expire_logs_days ，精确度为天；MySQL8.0使用 binlog_expire_logs_seconds 来控制，其效果和名字的变化一样，精确度由天变成了秒。超过这个时间的 binlog 会被自动清理，自动清理的触发时机为（注意：并不是以每秒这样的固定频率检查是否有过期日志）：

MySQL启动不用多说，binlog 刷新又分两种情况：

下面我们来看一个 binlog_expire_logs_seconds 失效的场景。

这是因为MySQL8.0为了解决备份时的全局锁问题，新引入了 LOCK INSTANCE FOR BACKUP 备份锁，而这把锁恰好导致了 binlog_expire_logs_seconds 的失效，下面两张图说明这个问题：

如果 MySQL 每天的数据修改很少，产生的 binlog 很小，而 max_binlog_size 设置很大。每次在达到单个 binlog 的最大大小前，执行定时任务调用 xtrabackup 备份，备份时加的备份锁 LOCK INSTANCE FOR BACKUP 和 FLUSH NO_WRITE_TO_BINLOG BINARY LOGS 会导致：binlog 刷新了，但是无法自动删除过期的 binlog。新的 binlog 写一天没有达到最大大小，又进行备份，每天循环这个逻辑，导致过期的 binlog 越来越多，一直无法被自动删除。

当然，如果你使用的是 MySQL5.7，那并不会有这个问题，虽然 MySQL5.7时备份时会加全局锁，但是并不影响过期 binlog 的自动删除。从这个角度看，这是个 bug，所以报给官方后很快被确认了：

等待修复的过程是漫长的，如果你恰好遇见了这个冷门的 bug，可以把 max_binlog_size 调小，保证在备份前 binlog 就能够达到最大大小，自然的刷新可以正常触发自动删除。

mysql 避免索引失效

where条件==order by 条件==group by 条件 按顺序遵守 最佳左前缀法则

假设创建了复合索引：a,b,c

不在索引列上做任何的操作（计算、函数、显式或隐式的类型转换），否则会导致索引失效而转向全表扫描

1、字符不加单引号会导致索引失效

name字段为varchar类型

这条sql发生了隐式的类型转换：数值==字符串。所以导致了全表扫描，索引失效

应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。如：

mysql中的范围条件有：in/not in、 like、 、BETWEEN AND ；

后面的索引失效

in会导致索引全部失效！！！

BETWEEN AND 范围条件不会导致索引失效！！！

尽量让索引列和查询列一致；减少select * 的使用

1、查询表结构

2、查询表的索引结构

联合索引：name,age,post；说明add_time字段没有添加索引

3、查看select * 的执行计划

4、查看 select name,age,pos的执行计划

5、如果select只用一部分索引

like以通配符开头（’%abc…’）mysql索引失效会变成全表扫描的操作。

解决：可以使用 覆盖索引 来解决这个问题！

1、先查看表上的索引

id、name、age、pos 四个字段上都有索引； 注意：name是联合索引中的第一个，带头大哥！

2、查看表结构

有个add_time字段没有用到索引

3、查看执行计划

使用UNION ALL

假设创建了联合索引 x(a,b,c)

ps：like虽然也是范围查询但是区别于、，%用在最前面就只用到索引a了；%用在最后面可以用到a+b+c！

下面的sql几乎违背了上面的所有原则，索引依然全部生效。因为select是索引覆盖的，select里不包含没有建立索引的字段。因此总是用到索引的。可以看出来索引覆盖在sql优化中的作用性

本文标题：mysql怎么防止失效 小学劳动教育课程论文
本文来源：http://scgulin.cn/article/dojdedd.html