面试知识,数据库索引优化

简介:

问什么问题?

  1. 索引有什么代价?哪些场景下你需要建索引?或者有时候反过来问,哪些场景下不推荐建索引。
  2. 建好索引之后,怎么才能最高效地利用索引?或者反过来问,请说出一个无法有效利用已建索引的案例。

索引的好处?

快速查询数据。

代价是什么?

  1. 索引需要占硬盘空间,这是空间方面的代价。
  2. 一旦插入新的数据,就需要重新建索引,这是时间上的代价。

不同场景,不同对待。

场景一,数据表规模不大,就几千行,即使不建索引,查询语句的返回时间也不长,这时建索引的意义就不大。当然,若就几千行,索引所占的空间也不多,所以这种情况下,顶多属于“性价比”不高。

场景二,某个商品表里有几百万条商品信息,同时每天会在一个时间点,往其中更新大概十万条左右的商品信息,现在用where语句查询特定商品时(比如where name = ‘XXX’)速度很慢。为了提升查询效率可以建索引,但当每天更新数据时,又会重建索引,这是要耗费时间的。这时就需要综合考虑,甚至可以在更新前删除索引,更新后再重建。

场景三,因为在数据表里ID值都不相同,所以索引能发挥出比较大的作用。相反,如果某个字段重复率很高,如性别字段,或者某个字段大多数值是空(null),那么不建议对该字段建索引。

建立索引原则

一定是有业务需求了才会建索引。比如在一个商品表里,我们经常要根据name做查询,如果没有索引,查询速度会很慢,这时就需要建索引。但在项目开发中,如果不经常根据商品编号查询,那么就没必要对编号建索引。

最后再强调一次,建索引是要付出代价的,没事别乱建着玩,同时在一个表上也不能建太多的索引。

具体的例子来看索引的正确用法

  1. 语句一:select name from 商品表。不会用到索引,因为没有where语句。
  2. 语句二:select * from 商品表 where name = ‘Java书’,会用到索引,如果项目里经常用到name来查询,且商品表的数据量很大,而name值的重复率又不高,那么建议建索引。
  3. 语句三:select * from 商品表 where name like ‘Java%’ 这是个模糊查询,会用到索引,请大家记住,用like进行模糊查询时,如果第一个就是模糊的匹配符,比如where name like ‘%java’,那么在查询时不会走索引。在其他情况下,不论用了多少个%,也不论%的位置,只要不出现在第一个位置,那么都能用到索引。

学生成绩表里有两个字段:姓名和成绩。现在对成绩这个整数类型的字段建索引。

  1. 第一种情况,当数字型字段遇到非等值操作符时,无法用到索引。比如:

​ select name from 学生成绩表 where 成绩>95 , 一旦出现大于符号,就不能用到索引,为了用到索引,我们应该改一下SQL语句里的where从句:where 成绩 in (96,97,98,99,100)

  1. 第二种情况,如果对索引字段进行了某种左值操作,那么无法用到索引。

​ 能用到索引的写法:select name from 学生成绩表 where 成绩 = 60

​ 不能用到索引的写法:select name from 学生成绩表 where 成绩+40 = 100

  1. 第三种情况,如果对索引字段进行了函数操作,那么无法用到索引。

​ 比如SQL语句:select * from 商品表 where substr(name) = ‘J’,我们希望查询商品名首字母是J的记录,可一旦针对name使用函数,即使name字段上有索引,也无法用到。

看一些图

非聚集索引和聚集索引的区别在于, 通过聚集索引可以查到需要查找的数据, 而通过非聚集索引可以查到记录对应的主键值 , 再使用主键的值通过聚集索引查找到需要的数据。
不管以任何方式查询表, 最终都会利用主键通过聚集索引来定位到数据, 聚集索引(主键)是通往真实数据所在的唯一路径。

后记

不少程序员平时用过索引,但不知道怎么说,这很吃亏。对于高级程序员而言,如果你这都说不好,那么你的能力比初级的要高多少?对于初级程序员而言,如果你掌握了,而且能在面试中很好地说,那么你和同等能力的人相比,就很占优势。



本文转自TBHacker博客园博客,原文链接:http://www.cnblogs.com/jiqing9006/p/7466257.html,如需转载请自行联系原作者

相关文章
|
1天前
|
存储 NoSQL 分布式数据库
微服务架构下的数据库设计与优化策略####
本文深入探讨了在微服务架构下,如何进行高效的数据库设计与优化,以确保系统的可扩展性、低延迟与高并发处理能力。不同于传统单一数据库模式,微服务架构要求更细粒度的服务划分,这对数据库设计提出了新的挑战。本文将从数据库分片、复制、事务管理及性能调优等方面阐述最佳实践,旨在为开发者提供一套系统性的解决方案框架。 ####
|
2天前
|
存储 SQL 数据库
深入浅出后端开发之数据库优化实战
【10月更文挑战第35天】在软件开发的世界里,数据库性能直接关系到应用的响应速度和用户体验。本文将带你了解如何通过合理的索引设计、查询优化以及恰当的数据存储策略来提升数据库性能。我们将一起探索这些技巧背后的原理,并通过实际案例感受优化带来的显著效果。
12 4
|
1天前
|
SQL 缓存 监控
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
本文详细解析了数据库、缓存、异步处理和Web性能优化四大策略,系统性能优化必知必备,大厂面试高频。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:4 大性能优化策略(数据库、SQL、JVM等)
|
4天前
|
SQL druid 数据库
如何进行数据库连接池的参数优化?
数据库连接池参数优化包括:1) 确定合适的初始连接数,考虑数据库规模和应用需求;2) 调整最大连接数,依据并发量和资源状况;3) 设置最小空闲连接数,平衡资源利用和响应速度;4) 优化连接超时时间,确保系统响应和资源利用合理;5) 配置连接有效性检测,定期检查连接状态;6) 调整空闲连接回收时间,适应访问模式并配合数据库超时设置。
|
8天前
|
SQL 缓存 监控
数据库优化
【10月更文挑战第29天】数据库优化
19 1
|
9天前
|
缓存 关系型数据库 MySQL
如何优化 MySQL 数据库的性能?
【10月更文挑战第28天】
29 1
|
4天前
|
存储 关系型数据库 数据库
Postgres数据库BRIN索引介绍
BRIN索引是PostgreSQL提供的一种高效、轻量级的索引类型,特别适用于大规模、顺序数据的范围查询。通过存储数据块的摘要信息,BRIN索引在降低存储和维护成本的同时,提供了良好的查询性能。然而,其适用场景有限,不适合随机数据分布或频繁更新的场景。在选择索引类型时,需根据数据特性和查询需求进行权衡。希望本文对你理解和使用PostgreSQL的BRIN索引有所帮助。
10 0
|
10天前
|
监控 关系型数据库 MySQL
数据库优化:MySQL索引策略与查询性能调优实战
【10月更文挑战第27天】本文深入探讨了MySQL的索引策略和查询性能调优技巧。通过介绍B-Tree索引、哈希索引和全文索引等不同类型,以及如何创建和维护索引,结合实战案例分析查询执行计划,帮助读者掌握提升查询性能的方法。定期优化索引和调整查询语句是提高数据库性能的关键。
49 0
|
3月前
|
存储 Java
【IO面试题 四】、介绍一下Java的序列化与反序列化
Java的序列化与反序列化允许对象通过实现Serializable接口转换成字节序列并存储或传输,之后可以通过ObjectInputStream和ObjectOutputStream的方法将这些字节序列恢复成对象。
|
3天前
|
存储 算法 Java
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
本文详解自旋锁的概念、优缺点、使用场景及Java实现。关注【mikechen的互联网架构】,10年+BAT架构经验倾囊相授。
大厂面试高频:什么是自旋锁?Java 实现自旋锁的原理?
下一篇
无影云桌面