大多数投资者认为比特币到2030年不会突破5万美元

函数操作

当在 查询 where = 左侧使用表达式或函数时，如字段 A 为字符串型且有索引, 有 where length(a) = 6查询，这时传递一个 6 到 A 的索引树，不难想象在树的第一层就迷路了。

隐式转换

隐式类型转换和隐式字符编码转换也会导致这个问题。

•  隐式类型转换对于 JOOQ 这种框架来说一般倒不会出现。
•  隐式字符编码转换在连表查询时倒可能出现，即连表字段的类型相同但字符编码不同。

破坏了有序性

至于 Like 语句 % 开头、字符串未加 ’’ 原因基本一致，MySQL 认为对索引字段的操作可能会破坏索引有序性就机智的优化掉了。

不过，对于如性别这种区分度过低的字段，索引失效就不是因为这个原因。

1.1.3 性别字段为什么不要加索引

为什么索引区分度低的字段不要加索引。盲猜效率低，效率的确低，有时甚至会等于没加。

对于非聚簇索引，是要回表的。假如有 100 条数据，在 sex 字段建立索引，扫描到 51 个 male，需要再回表扫描 51 行。还不如直接来一次全表扫描呢。

所以，InnoDB 引擎对于这种场景就会放弃使用索引，至于区分度多低多少会放弃，大致是某类型的数据占到总的 30% 左右时，就会放弃使用该字段的索引，有兴趣可以试一下。

1.1.4 有什么好用且简单的索引方法

前面说到大多慢查询都源于索引，怎么建立并用好索引。这里有一些简单的规则。

•  索引下推：性别字段不适合建索引，但确实存在查询场景怎么办？如果是多条件查询，可以建立联合索引利用该特性优化。
•  覆盖索引：也是联合索引，查询需要的信息在索引里已经包含了，就不会再回表了。
•  前缀索引：对于字符串，可以只在前 N 位添加索引，避免不必要的开支。假如的确需要如关键字查询，那交给更合适的如 ES 或许更好。
•  不要对索引字段做函数操作
•  对于确定的、写多读少的表或者频繁更新的字段都应该考虑索引的维护成本。

1.1.5 如何评价 MySQL 选错了索引

有时，建立了猛一看挺正确的索引，但事情却没按计划发展。就像“为啥 XXX 有索引，根据它查询还是慢查询”。

此刻没准要自信点：我的代码不可能有 BUG，肯定是 MySQL 出了问题。MySQL 的确可能有点问题。

这种情况常见于建了一大堆索引，查询条件一大堆。没使用你想让它用的那一个，而是选了个区分度低的，导致过多的扫描。造成的原因基本有两个：

•  信息统计不准确：可以使用 analyze table x重新分析。
•  优化器误判：可以 force index强制指定。或修改语句引导优化器，增加或删除索引绕过。

但根据我浅薄的经验来看，更可能是因为你建了些没必要的索引导致的。不会真有人以为 MySQL 没自己机灵吧？

除了上面这些索引原因外，还有下面这些不常见或者说不好判断的原因存在。

1.2 等MDL锁

在 MySQL 5.5 版本中引入了 MDL，对一个表做 CRUD 操作时，自动加 MDL 读锁；对表结构做变更时，加 MDL 写锁。读写锁、写锁间互斥。

当某语句拿 MDL 写锁就会阻塞 MDL 读锁，可以使用show processlist命令查看处于Waiting for table metadata lock状态的语句。

1.3 等 flush

flush 很快，大多是因为 flush 命令被别的语句堵住，它又堵住了 select 。通过show processlist命令查看时会发现处于Waiting for table flush状态。

1.4 等行锁

某事物持有写锁未提交。

1.5 当前读

InnoDB 默认级别是可重复读。设想一个场景：事物 A 开始事务，事务 B 也开始执行大量更新。B 率先提交， A 是当前读，就要依次执行 undo log ，直到找到事务 B 开始前的值。

 

（编辑：揭阳站长网）

【声明】本站内容均来自网络，其相关言论仅代表作者个人观点，不代表本站立场。若无意侵犯到您的权利，请及时与联系站长删除相关内容!