mirror of
https://github.com/Snailclimb/JavaGuide
synced 2025-07-11 18:57:06 +08:00
update: 索引优缺点
This commit is contained in:
Guide
parent
efbd62c90a
commit
9691335ca7
@ -67,7 +67,7 @@ tag:
|
||||
|
||||
**知识越贫乏的人，相信的东西就越绝对**，因为他们从未认真了解过与自己观点相对立的角度，也缺乏对技术发展的全局认识。
|
||||
|
||||
举个例子，我刚开始学习 Java 后端开发的时候，完全没什么经验，就随便买了一本书开始看。当时看的是**《Java Web 整合开发王者归来》**这本书（梦开始的地方）。
|
||||
举个例子，我刚开始学习 Java 后端开发的时候，完全没什么经验，就随便买了一本书开始看。当时看的是 **《Java Web 整合开发王者归来》** 这本书（梦开始的地方）。
|
||||
|
||||
在我上大学那会儿，这本书的很多内容其实已经过时了，比如它花了大量篇幅介绍 JSP、Struts、Hibernate、EJB 和 SVN 等技术。不过，直到现在，我依然非常感谢这本书，带我走进了 Java 后端开发的大门。
|
||||
|
||||
|
||||
@ -21,19 +21,25 @@ tag:
|
||||
|
||||
## 索引的优缺点
|
||||
|
||||
**优点**：
|
||||
**索引的优点：**
|
||||
|
||||
- 使用索引可以大大加快数据的检索速度（大大减少检索的数据量），减少 IO 次数，这也是创建索引的最主要的原因。
|
||||
- 通过创建唯一性索引，可以保证数据库表中每一行数据的唯一性。
|
||||
1. **查询速度起飞 (主要目的)**：通过索引，数据库可以**大幅减少需要扫描的数据量**，直接定位到符合条件的记录，从而显著加快数据检索速度，减少磁盘 I/O 次数。
|
||||
2. **保证数据唯一性**：通过创建**唯一索引 (Unique Index)**，可以确保表中的某一列（或几列组合）的值是独一无二的，比如用户ID、邮箱等。主键本身就是一种唯一索引。
|
||||
3. **加速排序和分组**：如果查询中的 ORDER BY 或 GROUP BY 子句涉及的列建有索引，数据库往往可以直接利用索引已经排好序的特性，避免额外的排序操作，从而提升性能。
|
||||
|
||||
**缺点**：
|
||||
**索引的缺点：**
|
||||
|
||||
- 创建和维护索引需要耗费许多时间。当对表中的数据进行增删改的时候，如果数据有索引，那么索引也需要动态地修改，这会降低 SQL 执行效率。
|
||||
- 索引需要使用物理文件存储，也会耗费一定空间。
|
||||
1. **创建和维护耗时**：创建索引本身需要时间，特别是对大表操作时。更重要的是，当对表中的数据进行**增、删、改 (DML操作)** 时，不仅要操作数据本身，相关的索引也必须动态更新和维护，这会**降低这些 DML 操作的执行效率**。
|
||||
2. **占用存储空间**：索引本质上也是一种数据结构，需要以物理文件（或内存结构）的形式存储，因此会**额外占用一定的磁盘空间**。索引越多、越大，占用的空间也就越多。
|
||||
3. **可能被误用或失效**：如果索引设计不当，或者查询语句写得不好，数据库优化器可能不会选择使用索引（或者选错索引），反而导致性能下降。
|
||||
|
||||
但是，**使用索引一定能提高查询性能吗?**
|
||||
**那么，用了索引就一定能提高查询性能吗？**
|
||||
|
||||
大多数情况下，索引查询都是比全表扫描要快的。但是如果数据库的数据量不大，那么使用索引也不一定能够带来很大提升。
|
||||
**不一定。** 大多数情况下，合理使用索引确实比全表扫描快得多。但也有例外：
|
||||
|
||||
- **数据量太小**：如果表里的数据非常少（比如就几百条），全表扫描可能比通过索引查找更快，因为走索引本身也有开销。
|
||||
- **查询结果集占比过大**：如果要查询的数据占了整张表的大部分（比如超过20%-30%），优化器可能会认为全表扫描更划算，因为通过索引多次回表（随机I/O）的成本可能高于一次顺序的全表扫描。
|
||||
- **索引维护不当或统计信息过时**：导致优化器做出错误判断。
|
||||
|
||||
## 索引底层数据结构选型
|
||||
|
||||
|
||||
@ -174,7 +174,7 @@ Java 类的继承关系由类索引、父类索引和接口索引集合三项确
|
||||
|
||||
**字段的 access_flag 的取值:**
|
||||
|
||||
|
||||
|
||||
|
||||
### 方法表集合（Methods）
|
||||
|
||||
@ -193,7 +193,7 @@ Class 文件存储格式中对方法的描述与对字段的描述几乎采用
|
||||
|
||||
**方法表的 access_flag 取值：**
|
||||
|
||||
|
||||
|
||||
|
||||
注意：因为`volatile`修饰符和`transient`修饰符不可以修饰方法，所以方法表的访问标志中没有这两个对应的标志，但是增加了`synchronized`、`native`、`abstract`等关键字修饰方法，所以也就多了这些关键字对应的标志。
|
||||
|
||||
|
||||
@ -3,21 +3,17 @@ title: RestFul API 简明教程
|
||||
category: 代码质量
|
||||
---
|
||||
|
||||
|
||||
|
||||
这篇文章简单聊聊后端程序员必备的 RESTful API 相关的知识。
|
||||
|
||||
开始正式介绍 RESTful API 之前，我们需要首先搞清：**API 到底是什么？**
|
||||
|
||||
## 何为 API？
|
||||
|
||||
|
||||
|
||||
**API（Application Programming Interface）** 翻译过来是应用程序编程接口的意思。
|
||||
|
||||
我们在进行后端开发的时候，主要的工作就是为前端或者其他后端服务提供 API 比如查询用户数据的 API 。
|
||||
|
||||
|
||||
|
||||
|
||||
但是， API 不仅仅代表后端系统暴露的接口，像框架中提供的方法也属于 API 的范畴。
|
||||
|
||||
@ -66,7 +62,7 @@ POST /classes：新建一个班级
|
||||
|
||||
## RESTful API 规范
|
||||
|
||||
|
||||
|
||||
|
||||
### 动作
|
||||
|
||||
|
||||
Loading…
x
Reference in New Issue
Block a user