SQL优化小讲堂(五)——索引的那些事

简介: 提到索引,想必小伙伴们都知道,它是为了提高查询效率而生。但是在查询过程中,怎么才能让我们的查询语句使用索引?相必大家或多或少都会遇到这样的问题。今天我们就来回答这个问题。

1. 聚集索引和非聚集索引


索引一般分为聚集索引和非聚集索引。

聚集索引速度很快,但只能建一个,所以尽量把经常使用的列建成聚集索引。

非聚集索引虽然没聚集索引快,但是可以建多个,比全表扫描快。


2 如何建立高效的索引


A.关联条件上建立索引

例如:

SELECT  * FROM  T1

JOIN  T2 ON  T1.ORDER_ID=T2.ORDER_ID;

在关联条件ON后面的两个列就可以分别建立索引,这样会很快将符合关联条件的数据查询出来。

B.在条件查询上建立索引

例如:

SELECT * FROM T1

WHERE  T1.PRICE>20;

在WHERE条件PRICE列上就可以建立索引。

注意:以下几种情况不会使用索引

  • 在索引列上使用了运算符的,
    例如:T1.PRICE*0.5>20,这种不会使用索引
  • 在索引列上使用了函数的,
    例如:UPPER(T1.ADDRESS)='NEWYORK',也不会使用索引
  • 在使用索引时存在空值NULL的,
    例如:T1.ADDRESS IS NULL,那么在查询时就不会走索引了
  • 字符型数据不加引号也不会使用索引
    例如:ORDER_ID原本是字符型,T1.ORDER_ID='112'会使用索引,但是如果去掉引号,变成了T1.ORDER_ID=112,查询语句不会报错,但是不会使用索引了。
  • 或(OR)和不等(<>,!=)以及NOT IN等这些也不会使用索引
  • 经常使用的LIKE,除了后置匹配,其他匹配均不走索引
    例如:T1.ADDRESS LIKE ‘NEW%’,这个走索引,但是像
    T1.ADDRESS LIKE ‘%NEW%’和T1.ADDRESS LIKE ‘%NEW’则均不走索引了
  • 最后如果查询优化器判断全表扫描比走索引还快也不会使用到索引。

C.建立索引的原则

  • 不频繁写入和更新的列适合建立索引
  • 经常查询的列适合建立索引
  • 重复数据较少的可以建立索引

D.联合索引的妙用

联合索引就是几个列合在一起组成一个索引,这种在WHERE条件中相比单列索引会起到意想不到效果。

例如:

SELECT * FROM T1 WHERE T1.CITY=‘北京’ AND T1.DISTR='海淀区';

这个时候将列CITY和DISTR建立成一个联合索引,效果会更好。

注意:联合索引需要按顺序走,如果中间某个索引不能使用,那它之后的列均不会使用索引。

例如:

SELECT * FROM T1

WHERE T1.CITY=‘北京’

AND LEFT(T1.DISTR,3)='海淀区'

AND T1.ROAD='#10'

如果我们将CITY,DISTR,ROAD建立成为联合索引,由于索引的前置规则,只会让CITY走索引,后面的DISTR因为使用了函数,索引失效,最后的ROAD列因为DISTR的失效也会跟着失效,这里记住即可。


3什么情况不适合建立索引


由于创建索引和维护索引耗时,时间随着数据的增加而增加,成正比;需要占物理空间;当对表中的数据进行维护时,对索引也要进行维护,这样就降低了数据的维护速度。基于这些缺点,以下情况不适合建立索引

  • 对于在查询过程中很少使用或参考的列,不应该创建索引。
  • 对于那些只有很少数据值的列,不应该创建索引,例如:性别。
  • 对于那些定义为image,text和bit数据类型的列,不应该创建索引。
  • 当修改性能远大于检索性能,不应该建立索引。
  • 重复值较多的也不适合建立索引。
相关文章
|
23天前
|
SQL 缓存 Java
sql优化方法
sql优化方法
19 0
|
2月前
|
SQL 存储 关系型数据库
一文搞懂SQL优化——如何高效添加数据
**SQL优化关键点:** 1. **批量插入**提高效率,一次性建议不超过500条。 2. **手动事务**减少开销,多条插入语句用一个事务。 3. **主键顺序插入**避免页分裂,提升性能。 4. **使用`LOAD DATA INFILE`**大批量导入快速。 5. **避免主键乱序**,减少不必要的磁盘操作。 6. **选择合适主键类型**,避免UUID或长主键导致的性能问题。 7. **避免主键修改**,保持索引稳定。 这些技巧能优化数据库操作,提升系统性能。
282 4
一文搞懂SQL优化——如何高效添加数据
|
2月前
|
SQL 存储 关系型数据库
SQL优化之Explain详解(mysql)
`Explain`是MySQL中用于分析SQL查询执行计划的工具。它可以帮助我们了解MySQL如何执行SQL语句,包括如何使用索引、预计的行数以及查询的顺序。以下是`Explain`输出的关键列及其含义的简要摘要: 1. **id**:查询的序列号,表示查询中的子句层次,id越大优先级越高。 2. **select_type**:表示查询的类型,如SIMPLE(简单查询)、PRIMARY(主查询,多表查询中的第一个查询)、SUBQUERY(子查询)、DERIVED(派生表)或UNION(UNION操作的查询部分)。 3. **table**:查询涉及的表名,如果是子查询,可能显示为衍生表
31 0
|
1月前
|
SQL 关系型数据库 MySQL
项目中遇到一张900w的数据表把原先要花费17s执行的SQL优化到300ms经验加100哈哈哈
项目中遇到一张900w的数据表把原先要花费17s执行的SQL优化到300ms经验加100哈哈哈
25 1
|
20天前
|
SQL 数据库 数据库管理
【SQL server】玩转SQL server数据库:第三章 关系数据库标准语言SQL(一)模式、表、索引与视图
【SQL server】玩转SQL server数据库:第三章 关系数据库标准语言SQL(一)模式、表、索引与视图
55 11
|
2天前
|
存储 SQL 缓存
30个业务场景的SQL优化
这些优化策略和示例可以帮助改善 `SQL` 查询的性能和效率。在实践中,需要综合考虑数据库设计、`SQL` 编写、服务器配置等多方面因素,选择合适的优化方法,并进行充分的测试和验证。以上 30 个经验是 V 哥在实际经验中总结的内容,当然,业务场景不同,具体的优化策略也会不同,按实际情况处理,这不就是程序员要做的事情么。
|
2天前
|
SQL 存储 算法
clickhouse SQL优化
clickhouse 是 OLAP 数据库,但其具有独特的索引设计,所以如果拿 MySQL 或者其他 RDB 的优化经验来优化 clickhouse 可能得不到很好的效果,所以特此单独整理一篇文档,用于有 SQL 优化需求的同学,本人接触 clickhouse 时间也不长,难免有不足的地方,如果大家发现错误,还请不吝指正。
|
5天前
|
SQL 关系型数据库 MySQL
【MySQL】SQL优化
【MySQL】SQL优化
|
6天前
|
SQL 存储 关系型数据库
MySQL SQL优化
MySQL SQL优化
10 0
|
9天前
|
SQL 分布式计算 资源调度
一文解析 ODPS SQL 任务优化方法原理
本文重点尝试从ODPS SQL的逻辑执行计划和Logview中的执行计划出发,分析日常数据研发过程中各种优化方法背后的原理,覆盖了部分调优方法的分析,从知道怎么优化,到为什么这样优化,以及还能怎样优化。
103458 0