索引|一文带你你搞懂索引如何优化( 三 )
- 如果索引中有范围查找 , 那么索引有序性无法利用 , 如WHERE a>10 ORDER BY b , 索引(a,b)无法排序 。
- 对列进行索引 , 如果可能应该指定一个前缀长度 。 例如 , 如果有一个CHAR(255)的列 , 如果该列在前10个或20个字符内 , 可以做到既使得前缀索引的区分度接近全列索引 , 那么就不要对整个列进行索引 。 因为短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作 , 减少索引文件的维护开销 。 可以使用count(distinct leftIndex(列名, 索引长度))/count(*) 来计算前缀索引的区分度 。
- 但缺点是不能用于 ORDER BY 和 GROUP BY 操作 , 也不能用于覆盖索引 。
- 不过很多时候没必要对全字段建立索引 , 根据实际文本区分度决定索引长度即可 。
- MySQL 并不是跳过 offset 行 , 而是取 offset+N 行 , 然后返回放弃前 offset 行 , 返回 N 行 , 那当 offset 特别大的时候 , 效率就非常的低下 , 要么控制返回的总页数 , 要么对超过特定阈值的页数进行 SQL 改写 。
- 示例如下 , 先快速定位需要获取的id段 , 然后再关联:
selecta.* from 表1a,(selectid from 表1 where条件 limit100000,20) b wherea.id=b.id; 15、如果明确知道只有一条结果返回 , limit 1 能够提高效率
- 比如如下 SQL 语句:
select* from user wherelogin_name=? - 可以优化为:
select* from user wherelogin_name=? limit 1 - 自己明确知道只有一条结果 , 但数据库并不知道 , 明确告诉它 , 让它主动停止游标移动 。
- 需要 join 的字段 , 数据类型必须一致 , 多表关联查询时 , 保证被关联的字段需要有索引 。
- 例如:left join是由左边决定的 , 左边的数据一定都有 , 所以右边是我们的关键点 , 建立索引要建右边的 。 当然如果索引在左边 , 可以用right join 。
- consts:单表中最多只有一个匹配行(主键或者唯一索引) , 在优化阶段即可读取到数据 。
- ref:使用普通的索引(Normal Index) 。
- range:对索引进行范围检索 。
- 当 type=index 时 , 索引物理文件全扫 , 速度非常慢 。
- 不要以为唯一索引影响了 insert 速度 , 这个速度损耗可以忽略 , 但提高查找速度是明显的 。 另外 , 即使在应用层做了非常完善的校验控制 , 只要没有唯一索引 , 根据墨菲定律 , 必然有脏数据产生 。
- 索引越多越好 , 认为需要一个查询就建一个索引 。
- 宁缺勿滥 , 认为索引会消耗空间、严重拖慢更新和新增速度 。
- 抵制惟一索引 , 认为业务的惟一性一律需要在应用层通过“先查后插”方式解决 。
- 过早优化 , 在不了解系统的情况下就开始优化 。
- 既然索引可以加快查询速度 , 那么是不是只要是查询语句需要 , 就建上索引?答案是否定的 。 因为索引虽然加快了查询速度 , 但索引也是有代价的:索引文件本身要消耗存储空间 , 同时索引会加重插入、删除和修改记录时的负担 , 另外 , MySQL在运行时也要消耗资源维护索引 , 因此索引并不是越多越好 。 一般两种情况下不建议建索引 。
推荐阅读
- 一加手机|4G 网速跟不上?5G 手机带你一起乘风破浪!
- 妍妍觅双|“华为”和“荣耀”的区别是什么?一文总结看完秒懂
- 共享单车|需求定生死、频次决成败,显电带你看共享经济冰火两重天
- 车驰夜幕|断供瓦解,国产高端芯片真的来了,英媒:我们的芯片将一文不值
- 管径|管道天天见,管径搞不懂?一文了解De、DN、D、d、Φ区别
- 新机发布|10.14发 iPhone12官宣 带你提前看4款真机!
- 电热汇|管道天天见,管径搞不懂?一文了解De、DN、D、d、Φ区别
- 5G|iPhone12来势汹汹,11真就一文不值?等与买你选谁?
- i7|11代酷睿已来 对比市面轻薄本带你了解哪一款适合你 纯干货
- 济南蚂蚁逛街|济南蚂蚁逛街教育科技有限公司带你了解跨境电子商务
