数据库知识点梳理（一）：从基础操作到底层原理
一、数据库模块总览
数据库的知识体系看似繁杂，其实可以归纳为四大板块
SQL操作：数据库最基础、最常用的核心能力，也是日常工作中使用频率最高的部分
数据建模（ER图）：数据库设计的第一步，帮我们理清业务逻辑，避免后期表结构混乱
性能优化（索引）：提升查询速度的关键技术，解决大数据量下的查询卡顿问题
底层原理（引擎/事务/锁/日志）：数据库进阶的核心，理解它才能真正读懂数据库的运行逻辑
二、SQL操作：日常数据交互
SQL是与数据库交互的“语言”，核心分为「基础增删改查（CRUD）」和「高级查询」两部分，无需死记硬背，理解逻辑就能灵活运用。
1 基础增删改查（CRUD）
这是SQL最基础的操作，对应数据的新增、查询、修改、删除，其中查询（SELECT）日常使用频率最高。
INSERT：新增数据，向数据表中插入一条或多条记录
SELECT：查询数据，可根据条件筛选、排序，是所有SQL操作中最灵活、最常用的指令
UPDATE：修改数据，根据条件更新表中已有的记录，注意避免误改全表
DELETE：删除数据，根据条件删除表中的记录，同样需谨慎操作，防止误删
2 多表关联查询
实际业务中，数据往往分散在多张表中（比如“用户表”和“订单表”），这就需要通过关联查询获取完整数据，常用的关联方式有4种：
内连接（INNER JOIN）：只返回两张表中匹配的数据，不匹配的记录会被过滤
左连接（LEFT JOIN）：返回左表全部数据，右表匹配的数据会关联显示，不匹配的部分补NULL
右连接（RIGHT JOIN）：与左连接相反，返回右表全部数据，左表匹配的数据关联显示，不匹配部分补NULL
全连接（FULL JOIN）：返回两张表的所有数据，双方不匹配的部分都补NULL
3 高级查询技巧
面对复杂的业务需求，基础查询无法满足，这时候就需要用到高级查询技巧，提升查询效率和灵活性：
分页：通过LIMIT（MySQL）或ROW_NUMBER()（SQL Server）实现数据分页展示，避免一次性加载大量数据
分组：使用GROUP BY配合聚合函数，对数据进行分组统计（比如统计每个部门的人数、每个商品的销售额）
嵌套查询：通过子查询实现复杂逻辑，把一个查询的结果作为另一个查询的条件
常用函数：聚合函数（MAX最大值、MIN最小值、AVG平均值、SUM求和）、排序函数（ORDER BY ASC升序/DESC降序），简化查询逻辑
三、ER图：数据库设计的“蓝图”
很多人做数据库设计时，直接上手建表，最后导致表结构混乱、关联关系不清，后期修改成本极高。而ER图，就是解决这个问题的关键。
ER图全称「实体-关系图（Entity-Relationship Diagram）」，用于可视化数据库表结构和表间关系，是数据库设计的第一步，也是梳理业务逻辑的核心工具。
1 ER图元素
实体：对应数据库中的一张表，比如“用户”“订单”“商品”，每个实体都有自己的属性
属性：对应表中的字段，比如“用户表”的“用户名”“手机号”“密码”，“订单表”的“订单ID”“下单时间”
关系：表与表之间的关联，比如“用户-订单”是一对多关系（一个用户可以有多个订单），“商品-订单”是多对多关系（一个订单可以包含多个商品，一个商品可以出现在多个订单中）
四、索引：提升查询速度的“加速器”
当表中数据量达到几十万、几百万条时，普通查询会变得非常缓慢，甚至出现卡顿，而索引，就是解决这个问题的核心技术——它能帮数据库快速定位数据，减少硬盘扫描次数，从而大幅提升查询速度。
1 索引的类型
联合索引：由多个字段组合而成的索引，遵循“最左前缀原则”，比如索引（name, age），查询时先匹配name，再匹配age，顺序不能颠倒
聚簇索引（聚集索引）：数据行和索引存储在一起，一张表只能有一个聚簇索引。通常主键默认就是聚簇索引，查询速度最快，因为索引和数据在同一个位置
非聚簇索引（非聚集索引）：索引和数据分开存储，一张表可以有多个非聚簇索引。查询时，先通过索引找到数据的存储地址，再回表查询完整数据，速度比聚簇索引稍慢
索引不是越多越好，过多的索引会增加数据插入、修改、删除的成本（因为每次操作都要更新索引），合理创建索引才是关键。
五、“程序与数据”的交互逻辑
很多人学完SQL操作后，还是不懂“为什么查询会慢”“为什么宕机可能丢数据”“为什么需要缓存”，其实答案都在数据库的底层原理里：运行的程序在内存中，持久化的数据在硬盘上。
1 程序与数据的存储位置
运行的程序一定在内存中：数据库服务（比如MySQL的mysqld进程）本质是硬盘上的可执行文件，启动后，操作系统会把它加载到内存（RAM），CPU才能执行指令。内存是高速存储区域，但断电后数据会丢失
数据一定在硬盘上：数据库中的业务数据（用户表、订单表等）需要持久化保存，关机断电后不丢失，所以必须存在硬盘（HDD/SSD）中。硬盘的最小存储单位是文件，因此数据库数据最终都以文件形式存在——数据库本质上就是一个“高效的文件管理系统”
2 数据库完整运行流程
阶段1：程序加载
数据库程序文件（如mysqld）位于硬盘的某个目录，启动时，操作系统将其加载到内存，变成一个运行中的进程（服务），并监听指定端口（比如MySQL默认3306端口），等待客户端连接。
阶段2：数据交互
数据库会在硬盘上创建专属数据目录（如MySQL的data目录），一张表通常对应一个或多个文件（如InnoDB的.ibd文件），存储表数据和索引。当执行SQL查询时：
内存中的数据库进程接收SQL请求
进程去硬盘读取对应表的数据文件，将数据加载到内存
在内存中完成计算、修改等操作
将修改后的数据写回硬盘文件（或先写日志再异步刷盘，兼顾性能和安全）
阶段3：数据库的使用方式
日常使用数据库，就是围绕“启动服务-连接-执行SQL-关闭服务”的流程：
启动服务：运行数据库程序，让其加载到内存并监听端口（Windows服务/ Linux systemctl start mysql）
连接数据库：用客户端工具（mysql命令行、Navicat、JDBC）连接到数据库服务
执行SQL：发送CREATE TABLE/INSERT/SELECT等语句，数据库服务在内存中处理，与硬盘数据文件交互，返回结果
关闭服务：正常关闭时，数据库会将内存中未持久化的数据刷回硬盘，保证数据不丢失
阶段4：SQL请求的完整流转
除了整体运行流程，我们再细化一下“一条SQL请求从发出到返回结果”的完整路径，更能理解底层逻辑：
通过网卡和端口（如3306）接收客户端发来的SQL字符串（如SELECT * FROM users WHERE id=1），可通过主动轮询或事件驱动接收数据
内存中的数据库进程解析SQL字符串，识别指令类型、定位操作的表和条件，将人类可读的SQL翻译成程序能理解的操作指令
：找到目标表对应的硬盘文件，将文件加载到内存，并解析成CPU可操作的数组结构（本质是数字编码）
对内存中的数组执行CRUD（查询就是遍历数组、插入就是新增数组元素、修改就是修改元素、删除就是移除元素）
将修改后的数组重新编码成二进制文件，写回硬盘对应表文件，完成数据持久化（优化机制：先写日志WAL，再异步刷盘，避免宕机丢数据）
3 底层组件
数据库引擎：决定数据存储和事务处理方式，比如MySQL的InnoDB（支持事务、行锁）和MyISAM（不支持事务、表锁）
数据库事务：遵循ACID原则（原子性、一致性、隔离性、持久性），保证数据操作的安全性，比如转账时“扣钱”和“加钱”必须同时成功或同时失败
数据库锁：用于并发控制，防止多线程操作导致数据不一致，分为行锁、表锁、共享锁、排他锁等
数据库日志：核心用于数据安全和恢复，包括重做日志（Redo Log，保证事务持久性）、回滚日志（Undo Log，实现事务回滚）、二进制日志（Bin Log，用于数据备份和主从复制）
六、数据库卡顿的原因
日常工作中，我们最常遇到的数据库问题就是“卡顿”（比如选课系统高峰期卡顿、大数据量查询缓慢），其实卡顿的本质很简单，「总线带宽有限+磁盘IO速度慢」，再加上并发和锁的影响，具体可以分为两点：
1 总线与磁盘IO瓶颈
内存与硬盘之间通过总线传输数据，总线有固定的带宽上限。大表对应大文件，加载时需要传输大量数据，会占满总线带宽，导致加载缓慢；而小表文件体积小，传输速度快，加载到内存的速度也更快。
2 并发与锁竞争加剧卡顿
多个用户同时操作同一张表（比如选课系统的“选课表”），会同时向总线发起数据加载请求，挤占总线资源，形成排队效应；同时，为了防止数据错乱，数据库会加锁，并发高时，大量请求排队等待锁释放，进一步拉长响应时间，导致卡顿。
总结
以上就是数据库的核心知识点梳理，从基础的SQL操作，到ER图设计、索引优化，再到底层运行原理和卡顿原因，形成了完整的知识闭环。其实数据库并不难，关键是抓住“程序在内存、数据在硬盘”的核心逻辑，再结合实际使用场景理解每个知识点的作用。