RDBMS RDBMS（Relational Database Management System，关系型数据库管理系统）是基于关系模型 的数据库系统，以表为核心组织数据，通过主键/外键关联不同数据集，核心目标是实现数据的结构化存储、高效访问与一致性保障 。常见产品包括MySQL、Oracle、PostgreSQL、SQL Server等。
一、库（Database）：数据的逻辑容器与资源单元 1. 定义与本质 库是RDBMS中逻辑独立的数据集容器 ，本质是命名空间+物理存储的映射 ：
逻辑上隔离不同业务数据（如订单库、用户库）； 物理上对应磁盘独立目录（如MySQL默认路径/var/lib/mysql/[库名]）。 2. 核心属性与作用 核心属性 具体说明 元数据 存储在系统库（如information_schema），记录库名、字符集等信息 字符集 库级默认配置（如utf8mb4），避免数据乱码 权限边界 数据库权限分配的基本单位，遵循最小权限原则 资源隔离 企业级RDBMS支持库级CPU/内存配额，保障核心业务性能
3. 实战操作（MySQL为例） -- 创建库（指定字符集） CREATE DATABASE ecommerce_orderDEFAULT CHARACTER SET utf8mb4COLLATE utf8mb4_unicode_ci; -- 查看库元数据 SELECT SCHEMA_NAME, DEFAULT_CHARACTER_SET_NAMEFROM information_schema. SCHEMATAWHERE SCHEMA_NAME= 'ecommerce_order' ; 4. 进阶拆分策略 拆分方式 原理 适用场景 垂直分库 按业务模块拆分 电商拆分为用户库、订单库 水平分库 按哈希/范围分散同业务表 订单表按用户ID分布到多个分库 读写分离 主库写、从库读 提升高并发读场景性能
5. 避坑指南 库与表字符集需统一，避免乱码； 按业务分配最小权限，禁止滥用全库权限； 高频库与低频库分磁盘部署，防止IO瓶颈。 二、表（Table）：结构化数据的核心载体 1. 定义与结构 表是RDBMS存储数据的基本单元，由**行（记录）和 列（字段）**组成：
列：定义数据类型（如INT、DECIMAL）与约束（主键、外键）； 行：存储具体业务数据。 2. 核心属性 （1）字段属性 字段属性 说明 数据类型 影响性能与存储空间，金额用DECIMAL、手机号用CHAR(11) 约束 主键（唯一标识）、外键（关联一致性）、非空、唯一
（2）存储引擎（MySQL特有） 特性 InnoDB（默认） MyISAM Memory 事务/外键 支持 不支持 不支持 锁粒度 行级锁 表级锁 表级锁 适用场景 核心业务表 只读统计/日志表 临时缓存表
3. 实战：表的创建 CREATE TABLE ` user ` ( ` user_id` INT UNSIGNED NOT NULL AUTO_INCREMENT COMMENT '主键' , ` user_name` VARCHAR ( 50 ) NOT NULL COMMENT '用户名（唯一）' , ` mobile` CHAR ( 11 ) NOT NULL COMMENT '手机号（唯一）' , ` dept_id` INT UNSIGNED COMMENT '部门外键' , ` create_time` DATETIME NOT NULL DEFAULT CURRENT_TIMESTAMP , PRIMARY KEY ( ` user_id` ) , UNIQUE KEY ` uk_user_name` ( ` user_name` ) , FOREIGN KEY ( ` dept_id` ) REFERENCES ` department` ( ` dept_id` ) ON DELETE SET NULL ) ENGINE = InnoDB DEFAULT CHARSET = utf8mb4COMMENT = '用户核心表' ; 4. 避坑指南 避免用VARCHAR存固定长度数据，用INT存金额； 主键优先选自增INT，避免UUID导致索引碎片化； 大字段（如头像）拆分到单独表，降低主表IO开销； 减少冗余字段，遵循3NF避免更新不一致。 三、视图（View）：基于查询的虚拟表 1. 定义与本质 视图是存储查询语句的虚拟表 ，不存储数据，每次访问时执行底层查询返回实时结果。
2. 核心作用 简化复杂查询：封装多表关联、聚合逻辑； 数据安全：只暴露非敏感字段； 逻辑复用：避免重复编写SQL； 屏蔽表结构变更：上层应用无需改动。 3. 分类与实战 视图类型 特点 适用场景 操作示例 普通视图 实时查询 业务数据查询 CREATE VIEW v_user_order AS SELECT u.user_id, o.order_id FROM user u LEFT JOINordero ON u.user_id=o.user_id;物化视图 存储物理结果，定期刷新 报表统计 Oracle：CREATE MATERIALIZED VIEW mv_daily_order REFRESH EVERY 1 DAY AS SELECT DATE(create_time), COUNT(*) FROMorderGROUP BY DATE(create_time); 递归视图 基于CTE 层级数据（组织架构） MySQL：CREATE VIEW v_dept_tree AS WITH RECURSIVE dept_cte AS (SELECT * FROM department WHERE parent_id=0 UNION ALL SELECT d.* FROM department d JOIN dept_cte c ON d.parent_id=c.dept_id) SELECT * FROM dept_cte;
4. 避坑指南 避免复杂视图嵌套，性能差时改用物化视图； 大部分视图不支持写操作，禁止通过视图修改数据； 表结构变更后，需同步更新视图定义并校验可用性。 四、索引（Index）：提升查询性能的核心工具 1. 定义与本质 索引是加速查询的特殊数据结构 ，将字段值与行物理位置关联，将全表扫描（O(n)）优化为索引查找（O(log n)）。
2. 主流索引结构对比 结构 优点 缺点 适用场景 B+树（主流） 支持范围查询、排序，查询稳定 写操作需维护树平衡 绝大多数等值/范围查询 哈希索引 等值查询速度极快（O(1)） 不支持范围查询 纯等值查询（如Redis） 全文索引 支持文本关键词检索 维护成本高 文章、商品描述查询
3. 索引类型与适用场景 索引类型 特点 适用场景 主键索引 唯一+非空，InnoDB为聚簇索引 主键查询 唯一索引 字段值唯一，允许NULL 手机号、用户名 普通索引 无唯一性约束 常用查询条件（创建时间） 复合索引 遵循最左前缀原则 多字段联合查询
4. 索引失效场景与解决方案 失效场景 示例 解决方案 索引字段函数操作 DATE(create_time) = '2025-12-18'改为范围查询：create_time BETWEEN '2025-12-18 00:00:00' AND '2025-12-18 23:59:59' 隐式类型转换 mobile = 13800138000（mobile为VARCHAR）改为字符串匹配：mobile = '13800138000' LIKE以%开头 user_name LIKE '%张三'改用全文索引 复合索引不满足最左前缀 索引(user_id, create_time)，查询create_time='2025-12-18' 查询条件加入user_id或单独建索引
5. 优化黄金法则 小表（<1000行）无需建索引； 复合索引按查询频率排序，高频字段放前面； 单表索引数<5个，避免写操作开销过大； 用EXPLAIN分析执行计划，定期删除无用索引、重建碎片化索引。 五、设计范式（Normalization） 1. 定义与目标 范式是减少数据冗余、保证一致性的规则 ，核心是“一事一地”，解决插入、更新、删除异常 。
2. 核心范式（1NF~3NF+BCNF） 范式 核心要求 反例 正例 1NF（原子性） 字段值不可再分 address存储“省-市-区”拆分为province/city/district 2NF（完全依赖） 非主键字段完全依赖主键 复合主键(order_id, product_id)表含order_create_time order_create_time移至订单表3NF（消除传递依赖） 非主键字段不依赖其他非主键字段 用户表含dept_id/dept_name 拆分部门表，用户表仅存dept_id BCNF（补充3NF） 所有决定因素包含主键 选课表(student_id, course_id)含teacher_id（course_id→teacher_id） 拆分课程表存储course_id/teacher_id
3. 避坑指南 核心业务表遵循3NF，日志表无需遵循范式； 避免盲目追求高范式，防止表拆分过多导致关联查询性能下降。 六、总结 RDBMS的核心逻辑围绕**“结构化存储”与“高效访问”**展开：
库：隔离数据、管理资源； 表：结构化存储、保障数据完整性； 视图：简化查询、保障数据安全； 索引：加速查询、优化性能； 范式：减少冗余、保证一致性。 