一、数据库最底层硬件逻辑：程序、内存、硬盘、总线基础规则
1 两条硬件公理
- 正在运行的程序一定存放在物理内存： 硬盘存放程序文件，启动时操作系统将程序加载至内存，CPU 才能执行指令；虚拟内存只是硬盘上的备用区域，仅存放挂起进程，运行中程序不可能只存在虚拟内存。
- 持久化数据存在硬盘，硬盘只能存储文件： 数据库断电后数据不丢失，说明业务数据不在内存；硬盘最小存储单元是文件，因此数据库程序、表数据、索引全部以文件形式落地硬盘。
2 数据库完整运行数据流（网卡→内存→总线→硬盘）
- 网络接收请求 客户端通过网络发送 SQL 字符串，经网卡 + 数据库监听端口（MySQL 默认 3306）推送给内存中的数据库进程，推送分为轮询、事件推送两种模式。
- SQL 解析处理 数据库进程解析 SQL 字符串，识别操作类型（增删改查）、目标数据库与数据表。
- 总线传输数据 内存与硬盘依靠总线传输二进制文件，总线依靠电压信号传输，存在固定带宽上限，文件越大、并发请求越多，总线拥堵越严重。
- 文件加载解码 从硬盘读取目标表文件，经总线拷贝至内存；二进制文件按编码规则解码为数组，数据库所有行数据本质是内存连续数组。
- 内存执行 CRUD，操作完成写回硬盘 在内存数组完成查询 / 新增 / 修改 / 删除，修改完成后重新编码为二进制文件，通过总线写回硬盘持久化。
3 数据库卡顿两大原因
- 单表文件体积过大 千万级数据表文件可达 1G 甚至更大，加载完整大文件会占满总线带宽，IO 耗时极高；老历史系统堆积海量数据，查询普遍卡顿就是该原因。
- 高并发争抢 + 锁排队 大量请求同时操作同一张表，全部需要通过总线加载文件，形成排队；数据库为防止数据覆盖会加行锁 / 表锁，并发请求必须排队等待锁释放，进一步拉长响应时间（场景：学校选课系统高峰期卡顿）。
二、索引底层原理：用硬件寻址能力解决全表扫描瓶颈
1 索引诞生的逻辑
内存、硬盘均支持按地址直接定位数据块，无索引时必须遍历全表（时间复杂度 O (n)）；索引提前抽取关键字 + 对应行硬盘地址并有序存储，查询时先通过索引拿到行地址，直接精准读取目标行，避免全表扫描。
2 索引文件存储特性
索引也是独立硬盘文件，关机不丢失；仅存储「关键字 + 行地址」两列，体积远小于完整数据表（800M 数据表，索引通常仅 120M 左右）。
3 索引两大层面性能优化
- 传输层优化：索引文件体积小，总线传输耗时大幅降低，减少 IO 压力。
- 查询层优化：索引文件加载后为有序树结构，查找时间复杂度 O (log n)，百万级数据仅需 20 次以内匹配，远快于逐行遍历。
4 高并发下索引仍存在瓶颈
即使索引文件很小，数百并发请求会同时拷贝多份索引副本至内存：
- 总线会被大量并发传输占满，形成新 IO 瓶颈；
- 内存处理速度远快于总线传输速度，绝大多数场景瓶颈卡在硬盘 IO / 总线，而非内存容量。
三、聚簇索引 vs 非聚簇索引
1 定义区分
- 非聚簇索引（普通二级索引） 独立小索引文件，仅存关键字 + 行地址；查询流程：加载索引→匹配关键字拿到行地址→回表读取完整数据，多一次硬盘 IO。
- 聚簇索引（主键索引，一张表仅能创建 1 个） 直接将完整数据表按主键物理排序，索引与原始数据合并存储；查找完成无需回表，直接返回完整数据。
2 性能取舍
| 类型 | 优点 | 致命缺点 | 适用场景 |
|---|---|---|---|
| 非聚簇索引 | 索引文件体积小，总线加载速度快 | 查询需要回表多一次 IO | 千万级大表、大数据量业务 |
| 聚簇索引 | 无回表操作，查询少一次寻址 | 整体文件体积巨大，总线加载极慢，写入维护成本高 | 千条以内小表，数据量极少场景 |
聚簇索引少一次 IO 速度更快是片面的，大表场景下大文件加载的总线耗时，远高于单次回表开销，大数据业务优先使用非聚簇索引。
四、字段定长与可变长度底层性能差异
1 两种字段存储形式
- 固定长度（CHAR）：定义 40 字符，无论存储 10 字符还是空值，固定占用 40 字符空间。
- 可变长度（VARCHAR）：定义最大 40 字符，存储多少字符占用多少空间，节省硬盘。
2 为什么高性能场景优先选择定长字段？
数据表文件在内存中是连续数组：
- 定长行：每行占用空间统一，可通过
起始地址 + 行号*单行长度直接计算目标行地址，遍历、解码速度极快； - 可变长行：每行长短不一，遍历解码时必须逐个寻找每行边界，循环解码开销巨大；
- 即使有索引快速定位行地址，定位后的解码步骤依然会被变长字段拖慢速度。
本质是空间换时间，牺牲少量硬盘空间换取查询、遍历整体性能提升。
五、单表数据量大的方案：分表、分库分表
1 分表诞生背景
单表数据达到千万级后，数据表、索引文件体积会膨胀至 GB 级别，总线 IO、索引加载、并发查询全部出现严重瓶颈，必须拆分大表。
2 主流分表拆分规则
- 按业务维度拆分：如人口表按省份拆分、订单表按年月拆分；
- 哈希 / 取模拆分：按身份证尾号、ID 取模均匀拆分，数据分布均衡无热点表。
3 分表性能提升逻辑
10G 单表拆分为 100 张子表后，单表仅 100M，对应索引仅 10M：
- 查询前通过分表规则快速定位目标小表；
- 仅加载 10M 小索引文件，总线传输压力大幅降低；
- 并发请求分散至不同子表，避免单表热点拥堵。
分库分表则进一步将子表分散至不同数据库实例，突破单机 CPU、内存、硬盘性能上限。
六、关系型数据库（MySQL/Oracle）与非关系型数据库（Redis/MongoDB/Hive）本质区分
1 底层存储设计差异
- 关系型数据库：数据集中存储在单张连续表文件，数据聚合在一起；
- NoSQL 数据库：数据打散分散存储，依靠哈希映射直接定位单条数据，无集中大文件。
2 擅长场景
- 关系型数据库（MySQL、Oracle）：擅长群体关联计算 原生支持多表 JOIN、GROUP BY 分组、聚合函数（MAX/MIN/AVG/SUM）、批量筛选统计，适合报表、后台复杂业务、多表关联业务；底层连续数组结构，批量扫描大量数据计算效率极高。
- 非关系型数据库（Redis/MongoDB/Hive/ZooKeeper）：擅长单点精准查询 依靠哈希散列 O (1) 直接定位单条数据，千万 / 十亿级数据查询速度几乎无衰减；不擅长批量聚合、多表关联计算，强行实现统计逻辑需要手动遍历全部数据，代码复杂、性能极差。
3 NoSQL 不能做统计计算吗？
技术层面可以通过代码循环遍历全部数据手动实现求和、平均，但存在三大问题：
- 数据分散存储，需要跨节点批量拉取数据，IO 开销爆炸；
- 无原生分组、关联语法，业务代码复杂度极高；
- 高并发场景下批量遍历会击穿系统性能，工程中几乎不会使用 NoSQL 做复杂统计。
4 总结选型逻辑
- 复杂报表、多表关联、批量统计业务 → MySQL/Oracle 关系型数据库；
- 缓存、高并发单点读写、key-value 快速查询 → Redis/MongoDB 等 NoSQL。
七、增加索引后，哪块性能会变慢？
从底层文件结构推导
- 无索引时，写入（INSERT/UPDATE/DELETE）仅操作 1 份数据表文件；
- 创建索引后，每次写入操作必须同步更新数据表 + 全部索引文件；
- 索引是有序树结构，新增、删除、修改数据需要调整树结构，额外产生多次硬盘总线 IO。
写入性能会明显变慢，索引的本质是牺牲插入、更新、删除的写入性能，换取 SELECT 查询性能提升。
总结
- 所有数据库性能问题根源都来自硬盘与内存之间的总线 IO 瓶颈，文件体积、并发量直接决定拥堵程度；
- 索引、分表、定长字段全部是围绕「减少总线传输数据量、降低遍历开销」设计的优化方案；
- 聚簇 / 非聚簇索引没有绝对优劣，必须结合数据量场景选择，拒绝死记硬背片面结论；
- 关系型与非关系型数据库区分是擅长群体批量计算 还是 单点精准查询，选型以业务操作类型为准；
- 索引存在写入损耗，读多写少业务适合大量建索引，写多读少业务需要控制索引数量。