数据库基础知识体系：概念、约束、范式与国产产品
数据库（Database）是按照数据结构来组织、存储和管理数据的仓库，其核心目标是高效、安全地处理大量数据的增删改查操作，广泛应用于网站后台、企业管理系统、金融交易系统等各类场景。
一、数据库的核心概念
1.数据（Data）
数据库中存储的基本单元，包括数字、文本、图片、音频等多种格式。例如：用户的姓名、年龄、手机号。
2.数据表（Table）
数据库中数据的主要存储形式，采用行（Row）和列（Column） 的二维结构组织数据，类似 Excel 表格。
列（字段 / Field）：代表数据的属性，每一列有固定的数据类型（如整数、字符串、日期）。
行（记录 / Record）：代表一条完整的数据，是多个字段的组合。
例：用户表（user）
| id | name | age | phone |
|---|---|---|---|
| 1 | 张三 | 25 | 13800138000 |
| 2 | 李四 | 30 | 13900139000 |
3.数据库管理系统（DBMS）
用于管理数据库的软件，用户通过 DBMS 与数据库交互，执行数据的创建、查询、更新和删除操作。常见的 DBMS 有 MySQL、Oracle、PostgreSQL、SQL Server 等。
4.结构化查询语言（SQL）
操作关系型数据库的标准语言，分为三类核心指令：
数据定义语言（DDL）：创建 / 修改 / 删除数据库、表结构，如 CREATE、ALTER、DROP。
数据操作语言（DML）：增删改数据，如 INSERT、DELETE、UPDATE。
数据查询语言（DQL）：查询数据，核心指令为 SELECT。
二、数据库的分类
根据数据的存储结构和组织方式，数据库主要分为两大类型：
1. 关系型数据库（RDBMS）
核心特点 ：以二维表结构 存储数据，表与表之间通过主键（Primary Key）和外键（Foreign Key） 建立关联关系，支持事务（ACID 特性）和复杂的多表查询。
主键（PK） ：唯一标识表中一条记录的字段，不可重复、不可为空，例如用户表的 id。
外键（FK） ：用于关联两个表的字段，指向另一个表的主键，例如订单表的 user_id 关联用户表的 id。
ACID 特性：保证事务的可靠性，即原子性（Atomicity）、一致性（Consistency）、隔离性（Isolation）、持久性（Durability）。
原子性（Atomicity）：事务是一个不可分割的最小工作单元，事务中的所有操作要么全部执行成功，要么全部执行失败并回滚到事务执行前的状态。
一致性（Consistency）：事务执行前后，数据库的数据完整性约束保持不变，数据始终处于合法、一致的状态。
隔离性（Isolation）：当多个事务并发执行时，不同事务之间相互隔离，一个事务的执行不能被其他事务干扰，每个事务都感觉不到其他事务的存在。
持久性（Durability）：一个事务一旦提交（Commit），其对数据库中数据的修改就是永久性的，接下来的其他操作或系统故障都不会影响已提交的事务数据。
代表产品：MySQL（开源常用）、Oracle（企业级商用）、PostgreSQL（开源高级特性丰富）、SQL Server（微软生态）。
2. 非关系型数据库（NoSQL）
核心特点：不依赖二维表结构，存储格式灵活（键值对、文档、列族、图形等），主要用于处理海量、高并发、非结构化或半结构化数据，牺牲部分事务一致性换取高性能。
常见类型及代表
| 类型 | 存储格式 | 代表产品 | 适用场景 |
|---|---|---|---|
| 键值型 | Key-Value | Redis | 缓存、会话存储、计数器 |
| 文档型 | JSON/BSON 文档 | MongoDB | 日志存储、内容管理系统 |
| 列族型 | 列族式存储 | HBase | 大数据分析、时序数据存储 |
| 图形型 | 节点和边 | Neo4j | 社交网络、推荐系统 |
三、数据库的核心功能
1.数据存储
按照预设的结构（如关系型表、NoSQL 文档）持久化存储数据，支持海量数据的高效写入。
2.数据查询
提供灵活的查询能力，支持单表查询、多表关联查询、条件筛选、排序、分页等操作。
3.数据更新与删除
支持对已有数据的修改和删除，保证操作的原子性。
4.事务管理
关系型数据库的核心能力，确保一组操作要么全部成功，要么全部失败，避免数据不一致。
5.权限控制
对不同用户分配不同的操作权限（如只读、读写、管理员权限），保障数据安全。
6.索引优化
通过创建索引（类似书籍的目录），大幅提升数据查询的效率。
四、数据库的常用术语
1.索引（Index）
对表中一个或多个字段的值进行排序的结构，用于加速查询，常见类型有主键索引、唯一索引、普通索引、复合索引。
注意：索引会提升查询速度，但会降低插入、更新、删除的速度，需合理创建。
2.视图（View）
基于一个或多个表的查询结果创建的虚拟表，不存储实际数据，仅保存查询逻辑，可简化复杂查询、限制数据访问范围。
3.存储过程（Stored Procedure）
预编译的 SQL 语句集合，存储在数据库中，可通过名称调用，支持参数传递，能减少网络传输、提高执行效率。
4.触发器（Trigger）
与表关联的特殊存储过程，当表发生 INSERT/UPDATE/DELETE
操作时自动执行，常用于数据校验、日志记录等场景。
5.游标（Cursor）
数据库游标（Cursor）：逐行处理数据的 "指针"
游标是关系型数据库中用于逐行读取和处理查询结果集 的数据库对象，它就像一个 "指针"------ 普通的 SELECT 查询会一次性返回所有符合条件的结果集，而游标可以让你精准定位到结果集中的某一行，逐个读取、修改甚至删除该行数据，特别适合处理需要逐行判断或操作的复杂业务逻辑。
(1) 特性
面向行操作：突破 SQL"面向集合" 的特性，将批量结果集拆解为单行处理；
可定位性：支持在结果集中前后移动指针（如移到第一行、最后一行、下一行）；
可操作性：部分游标支持修改 / 删除当前指向的行数据；
会话级生命周期：游标绑定到数据库会话，会话结束后游标自动销毁。
(2) 游标的适用场景
游标通常用于普通 SQL 语句难以实现的逐行处理场景，比如：
批量更新数据时，需要根据每行的具体值做不同逻辑判断（如按用户等级调整积分）；
逐行读取大结果集，避免一次性加载所有数据导致内存溢出；
数据迁移 / 清洗时，对每行数据做复杂的格式转换或校验。
注意：游标会降低数据库性能（逐行操作比批量操作慢），仅在无法用批量 SQL（如
UPDATE ... WHERE）实现时使用。
(3) 游标的使用步骤
游标使用遵循固定流程：声明 → 打开 → 读取 → 关闭 → 释放
5.数据库三大范式
范式（Normal Form，NF）是判断数据库表结构设计是否合理的标准，遵循的范式级别越高，数据冗余越低，但多表关联的复杂度会上升。
第一范式（1NF）：原子性
定义 ：表中的每一列都必须是不可再分的原子数据项，不能存在复合字段或多值字段。
反例：用户表中设计 contact 字段存储 电话-邮箱，违反原子性。
| id | name | contact |
|---|---|---|
| 1 | 张三 | 13800138000-zhangsan@xxx.com |
正例：拆分为独立字段，满足原子性。
| id | name | phone | |
|---|---|---|---|
| 1 | 张三 | 13800138000 | zhangsan@xxx.com |
第二范式（2NF）：唯一性
定义：在满足 1NF 的基础上，非主键字段必须完全依赖于主键，而不能依赖于主键的一部分（主要针对联合主键场景）。
前提：当表的主键是多个字段的组合（联合主键）时，才会涉及 2NF 的判断。
反例：订单明细表（联合主键：order_id + product_id）中包含 user_name 字段。
| order_id | product_id | product_name | user_name | price |
|---|---|---|---|---|
| 1001 | 2001 | 小米手机 | 张三 | 2999 |
| 1001 | 2002 | 华为耳机 | 张三 | 399 |
问题：user_name 只依赖 order_id（订单属于哪个用户），不依赖 product_id，违反 2NF。 |
正例：拆分表，消除部分依赖。
订单表（order_id 为主键）：存储订单与用户的关联
| order_id | user_name | order_time |
|---|---|---|
| 1001 | 张三 | 2025-01-01 |
订单明细表（联合主键：order_id + product_id）：存储订单与商品的关联
| order_id | product_id | product_name | price |
|---|---|---|---|
| 1001 | 2001 | 小米手机 | 2999 |
| 1001 | 2002 | 华为耳机 | 399 |
第三范式（3NF）：传递性
定义：在满足 2NF 的基础上，非主键字段不能传递依赖于主键，即非主键字段之间不能存在依赖关系。
传递依赖：A → B，B → C → 则 A → C（A 是主键）。
反例：用户表（user_id 为主键）中包含 city和 province字段。
| user_id | user_name | city | province |
|---|---|---|---|
| 1 | 张三 | 深圳市 | 广东省 |
问题：province 依赖 city，city 依赖 user_id → province 传递依赖于 user_id，存在冗余（多个深圳用户会重复存储 "广东省"）。 |
正例：拆分表，消除传递依赖。
用户表
| user_id | user_name | city_id |
|---|---|---|
| 1 | 张三 | 1 |
城市表（city_id 为主键）
| city_id | city | province |
|---|---|---|
| 1 | 深圳市 | 广东省 |
5.数据库的完整性约束
数据库的完整性约束是指为了保证数据库中数据的正确性、一致性和有效性，对数据表及数据操作施加的一系列规则限制。其目标是防止非法、无效的数据进入数据库，避免因数据错误导致业务逻辑异常。
分类：
(1) 实体完整性约束（Entity Integrity）
目标：保证表中每条记录都是唯一可识别的，即主键字段的唯一性和非空性。
约束类型：
主键约束（PRIMARY KEY）：
定义：表的主键字段必须唯一且非空，一个表只能有一个主键（可以是单一字段或联合字段）。
示例：
sql
CREATE TABLE user (
id INT PRIMARY KEY AUTO_INCREMENT, -- 主键约束，自增保证唯一性
name VARCHAR(20) NOT NULL
);唯一约束（UNIQUE）：
定义：保证字段值唯一，但允许单个空值（NULL）（多个 NULL 不视为重复），一个表可以有多个唯一约束。
示例：用户手机号不能重复
sql
CREATE TABLE user (
id INT PRIMARY KEY AUTO_INCREMENT,
phone VARCHAR(11) UNIQUE -- 唯一约束
);区别：主键约束 = 唯一约束 + 非空约束；唯一约束可用于非主键的唯一标识字段（如手机号、邮箱）。
(2) 域完整性约束（Domain Integrity）
目标：保证表中字段的值符合预设的类型和规则，限制字段的取值范围、数据类型、格式等。
常见约束类型：
| 约束类型 | 作用 | 示例 |
|---|---|---|
| 数据类型约束 | 限制字段的数据类型（如 INT、VARCHAR、DATE） | age INT（年龄必须是整数） |
| 非空约束（NOT NULL） | 字段值不能为 NULL | name VARCHAR(20) NOT NULL |
| 默认值约束（DEFAULT） | 字段未赋值时，自动填充默认值 | status TINYINT DEFAULT 0（状态默认 0） |
| 检查约束（CHECK） | 限制字段值的范围或条件（MySQL 8.0 后正式支持） | age INT CHECK (age > 0 AND age < 150) |
示例:定义用户表的域约束
sql
CREATE TABLE user (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(20) NOT NULL, -- 非空约束
age INT CHECK (age > 0), -- 检查约束：年龄必须大于0
gender CHAR(1) DEFAULT '未知' -- 默认值约束
);(3) 参照完整性约束（Referential Integrity）
目标：保证表与表之间的关联关系有效，防止出现孤立的外键数据，维护数据的一致性。
约束类型：
外键约束（FOREIGN KEY）
定义：子表的外键字段必须引用父表的主键或唯一键字段，外键值必须是父表中已存在的值，或为 NULL（若允许）。
关联操作：当父表数据被修改 / 删除时，可配置外键的联动策略：
ON DELETE CASCADE：父表删除数据，子表关联数据自动删除ON UPDATE CASCADE：父表更新主键，子表关联外键自动更新ON DELETE SET NULL：父表删除数据，子表外键设为 NULL
示例:订单表（子表）关联用户表（父表）
sql
-- 父表：用户表
CREATE TABLE user (
id INT PRIMARY KEY AUTO_INCREMENT,
name VARCHAR(20) NOT NULL
);
-- 子表：订单表，外键关联用户表id
CREATE TABLE order_info (
order_id INT PRIMARY KEY AUTO_INCREMENT,
user_id INT,
order_time DATETIME,
-- 外键约束
FOREIGN KEY (user_id) REFERENCES user(id) ON DELETE CASCADE
);注意：高并发场景中，为提升写入性能，部分系统会取消数据库外键约束，改为在业务代码中维护参照完整性。
(4) 用户定义完整性约束
目标：满足特定业务场景的自定义规则，是对上述三类约束的补充。
常见场景：
密码长度必须大于 6 位
邮箱格式必须符合 xxx@xxx.xxx
订单金额必须大于 0
实现方式：
- 简单规则可通过
CHECK约束实现； - 复杂规则可通过触发器（TRIGGER） 或存储过程实现；
- 也可在业务代码层进行校验（如后端接口参数校验）。
(5) 自定义完整性约束（业务层补充）
在实际开发中，部分复杂的完整性规则无法通过数据库原生约束实现，需要在业务代码中完成，例如：
同一个用户不能在 1 分钟内重复下单
转账时，转出账户余额不能小于转账金额
五、数据库的应用场景
互联网领域：用户信息、订单数据、商品信息的存储与查询（如电商、社交平台）。
企业管理：员工档案、财务数据、客户关系管理（CRM）系统。
大数据领域：海量日志数据、时序数据的存储与分析（如 HBase+Spark）。
物联网（IoT）：设备采集的传感器数据存储与实时监控。
六、学习数据库的路径
掌握SQL 语法 ：熟练使用 SELECT、INSERT、UPDATE、DELETE 及多表关联查询（JOIN）。
理解关系型数据库设计原则：遵循三大范式，合理设计表结构、主键、外键。
学习数据库优化：索引设计、查询语句优化、分库分表、读写分离等。
了解NoSQL 数据库：根据业务场景选择合适的非关系型数据库，掌握其核心操作。
七、国产数据库
1、金融级分布式事务数据库（OLTP 核心）
| 产品 | 厂商 | 核心特性 | 典型场景 |
|---|---|---|---|
| OceanBase | 蚂蚁集团 | 原生分布式、强一致性、TPC-C 世界纪录、兼容 MySQL/Oracle | 银行核心交易、支付清算、证券核心系统 |
| TDSQL | 腾讯云 | 金融级高可用、分布式扩展、HTAP 融合、多副本容错 | 银行信用卡核心、保险保单系统、政务支付 |
| GoldenDB | 中兴通讯 | 分布式事务强一致、证券交易市占率领先 | 证券交易、银行理财、基金清算 |
2、传统全栈自研数据库（信创核心）
| 产品 | 厂商 | 核心特性 | 典型场景 |
|---|---|---|---|
| 达梦 DM | 达梦数据 | 全栈自研、高安全（等保四级）、兼容 Oracle | 政务云、军工、国家电网、南方航空 |
| 人大金仓 KingbaseES | 电科金仓 | 兼容 PostgreSQL/Oracle、适配国产芯片 | 政务核心系统、能源调度、军工管理 |
| 南大通用 GBase | 南大通用 | 列式存储、MPP 并行计算、PB 级分析 | 电信数据仓库、金融风控、政务大数据 |
3、云原生数据库（云场景主流）
| 产品 | 厂商 | 核心特性 | 典型场景 |
|---|---|---|---|
| PolarDB | 阿里云 | 存储计算分离、秒级扩容、AI 融合优化 | 电商高并发、SaaS 多租户、政企云平台 |
| GaussDB/openGauss | 华为 | 全栈自主、OLTP/OLAP 双场景、鲲鹏优化 | 省级政务云、电信核心网、金融数据分析 |
| TiDB | 平凯星辰 | MySQL 兼容、HTAP、弹性扩展、分布式 SQL | 互联网中台、金融风控、物流调度 |
4、其他特色数据库
分析型：GBase 8a（南大通用，列式存储，适配数据仓库）、TDengine（时序数据，物联网 / 工业监控）。
时序 / 物联网：TDengine（高效时序存储，电力 / 车联网）、InfluxDB（国产适配版，监控数据）。
多模：GBase 8c（南大通用，多模多态分布式，适配混合负载）。
5、选型
场景匹配：金融核心选 OceanBase/TDSQL；政务信创选达梦 / 人大金仓；云原生选 PolarDB/GaussDB；HTAP 选 TiDB/TDSQL。
生态适配：优先适配国产芯片（龙芯、飞腾）、操作系统（麒麟、统信）与中间件。
性能与成本：分布式适合海量高并发；云原生适合弹性扩缩；传统架构适合稳态核心系统。