技术面：MySQL篇（为啥会有非关系型数据库？MySQL的数据存储一定在磁盘吗？）

关系型数据库

关系型数据库是一种基于关系模型（二维表结构）的数据库管理系统，数据以"行-列"的形式存储在表中，表与表之间通过主键（Primary Key）和外键（Foreign Key）建立关联关系。
通过预定义的Schema（数据结构）将数据组织为相互关联的表。其本质是结构化数据的规范化管理工具。

NoSQL数据库

简单说，NoSQL（Not Only SQL，"不仅仅是SQL"）就是一种不依赖于传统关系型数据库模型的数据库。它不使用SQL作为主要查询语言，也不需要预先定义复杂的表结构。
数据结构更加灵活，支持多种数据模型（如键值对、文档、列族和图形等）。
你可以把它想象成一个"灵活的收纳盒"，而关系型数据库就像一个"固定尺寸的文件柜"。

已有关系型数据库，为啥还有的非关系型数据库

虽然关系型数据库在很多情况下都能很好地满足需求，但在某些特定场景下，NoSQL 数据库具有更好的性能和可扩展性。

可以从以下几个方面，说明在某些特定场景下NoSQL比（MySQL、Oracle）关系型数据库更适合：

1.可扩展性

NoSQL 数据库通常具有更好的可扩展性，可以轻松地在多个服务器之间分布数据。这对于需要处理大量数据和高并发访问的应用（如社交网络、电子商务网站等）非常重要。而关系型数据库在扩展性方面相对较差，尤其是在需要跨多个服务器分布数据时。

2. 灵活的数据模型

NoSQL 数据库通常具有更灵活的数据模型，可以轻松地存储和查询非结构化和半结构化数据（如 JSON、XML 等）。
这使得 NoSQL 数据库非常适合处理各种类型的数据，如文本、图像、视频等。而关系型数据库通常需要预先定义表结构，对于非结构化数据的存储和查询相对较困难。

3. 高性能

在某些场景下，NoSQL 数据库可以提供比关系型数据库更高的性能。例如，Redis 等内存数据库可以将数据存储在内存中，从而实现极快的读写速度。而关系型数据库通常需要将数据存储在磁盘上，读写速度相对较慢。

4. 高可用性

NoSQL 数据库通常具有更好的容错性和高可用性。例如：Cassandra 等分布式数据库可以在多个节点之间自动复制数据，从而在某个节点发生故障时仍能保证数据的可用性。而关系型数据库在实现高可用性方面通常需要更多的配置和管理。

5. 低成本

NoSQL 数据库通常具有更低的成本，尤其是在开源社区中。许多 NoSQL 数据库（如 MongoDB、Redis 等）都是开源的，可以免费使用。而关系型数据库（如 Oracle、SQL Server 等）通常需要购买许可证，成本较高。

6. 特定场景的优势

在某些特定场景下，NoSQL 数据库具有明显优势。例如：在处理大量日志数据、实时数据分析、物联网设备数据等场景时，NoSQL 数据库可以提供更好的性能和可扩展性。

查询与操作方式对比

特点	关系型数据库	非关系型数据库
查询语言	标准SQL（结构化查询语言）	无统一标准，多为API或特定查询语法
复杂查询	支持复杂JOIN、聚合查询	通常不支持或支持有限的复杂查询
事务处理	强ACID支持（原子性、一致性、隔离性、持久性）	通常支持最终一致性，ACID支持较弱

适用场景对比

场景	关系型数据库	非关系型数据库
需要严格数据一致性	✅ 金融交易、订单系统	❌ 通常不支持强一致性
数据结构稳定	✅ 企业ERP、OA系统	❌ 数据结构常变化
复杂查询需求	✅ 适合多表关联查询	❌ 通常不支持复杂关联查询
高并发、大数据量	❌ 通常性能受限	✅ 社交网络、实时分析、IoT
非结构化/半结构化数据	❌ 处理效率低	✅ 适合存储JSON、文本、图片等

结论

NoSQL的存在并非否定关系型数据库，而是互相补充，主要是：

• 解决关系型数据库无法覆盖的场景（如PB级数据存储）
• 提供更合适的技术选项（如实时推荐系统选Redis而非MySQL）
• 推动数据库技术生态的多元化

在现代的软件架构中，两者常以混合部署方式协同工作：

• 用PostgreSQL管理核心交易数据
• 用MongoDB存储用户行为日志
• 用Elasticsearch实现搜索功能

MySQL的数据存储一定在磁盘吗？

基于磁盘的存储（默认情况）

大多数情况下，MySQL确实将数据存储在磁盘上，这是最常见的存储方式：

• 默认存储引擎：从MySQL 5.5开始，InnoDB成为默认存储引擎
• 存储方式：数据存储在.ibd文件（InnoDB独占表空间）或共享表空间文件ibdata1中
• 数据文件位置：通过show variables like '%datadir%';命令可查看，通常在/usr/local/var/mysql或/var/lib/mysql

基于内存的存储（特殊情况）

MySQL也可以将数据存储在内存中，这通过MEMORY存储引擎实现：

MEMORY存储引擎：允许将数据和索引存储在内存中，提高检索速度和修改效率

主要特点：

• 无磁盘数据文件（仅.frm文件存储表结构）
• 数据在内存中，重启MySQL后数据会丢失
• 适合临时数据、缓存或快速查询场景
• 通过ENGINE = MEMORY指定

MySQL中如何指定引擎
1、创建表时，可以通过ENGINE来指定存储引擎，在create语句最后加上"engine=存储引擎"即可;

CREATE TABLE table_test (
    id INT UNSIGNED NOT NULL AUTO_INCREMENT PRIMARY KEY
) ENGINE = InnoDB;

2、修改表时，可以使用“alter table 表名 engine=存储引擎;”
来指定存储引擎。

ALTER TABLE table_test ENGINE=InnoDB;

常见误解澄清

因为MySQL的InnoDB为了提高数据库的操作效率，设计了Buffer Pool（内存缓冲区）用于缓存数据，人们看到"Buffer Pool"（内存缓冲区）就误以为数据存储在内存中。
这不是数据存储在内存中，而是数据在磁盘上，部分数据被缓存在内存中以提高性能。误解了"In-Memory Database"的概念（MySQL 本身不提供独立进程级的 In-Memory Database（如 SAP HANA），仅通过 Memory 引擎提供表级内存存储）。

总结

MySQL的数据存储不一定是基于磁盘的。
虽然大多数情况下，MySQL使用InnoDB或MyISAM等存储引擎将数据存储在磁盘上（如.ibd或.MYD文件），但它也支持MEMORY存储引擎，允许将数据完全存储在内存中，从而获得极快的查询速度。使用MEMORY存储引擎时，数据仅存在于内存中，重启MySQL服务后数据会丢失，因此它适用于临时数据或缓存场景，而非持久化数据存储。

下面是MySQL各存储引擎的对比

存储引擎	默认状态	事务支持	锁机制	索引支持	数据存储方式	适用场景	优缺点
InnoDB	✅ (MySQL 5.5+)	✅ ACID	行级锁+MVCC	B+Tree, Fulltext(5.6+)	聚簇索引，数据与索引一起存储	OLTP系统、高并发事务处理(订单、银行系统)	优点：事务安全、行级锁、外键支持、崩溃恢复。缺点：存储空间占用稍高，写入效率略低
MyISAM	❌ (系统表已弃用，用户仍可用)	❌	表级锁	B+Tree, Fulltext	非聚簇索引，数据与索引分离	读多写少、静态数据(日志、静态内容)	优点：读操作速度快，空间占用小。缺点：不支持事务，崩溃后数据易损坏
Memory	❌	❌	表级锁	Hash, B-Tree	全部存储在内存中	临时缓存、高频查询(会话管理)	优点：读写速度极快。缺点：数据重启丢失，内存限制
Archive	❌	❌	插入级内部锁，无并发读写锁	❌ 无	高压缩存储	历史日志、归档数据	优点：高压缩比，占用空间小。缺点：查询性能低，不支持索引
CSV	❌	❌	无	❌ 索引重启后失效	CSV格式文本文件	数据导入导出、轻量存储	优点：可直接用文本编辑器查看。缺点：不支持索引、事务和分区
Blackhole	❌	❌ (不存储数据，无持久化事务)	表级锁	❌ 无	不存储数据	数据复制中继、日志过滤	优点：空写延迟最低。缺点：数据直接丢弃
BDB	❌	✅ ACID	行级锁	B+Tree	非聚簇索引	事务处理，但已过时	优点：支持事务，比MyISAM更安全。缺点：已被InnoDB取代，不再推荐使用
NDB	❌	✅ ACID	行级锁（跨分区升级为表锁）	B+Tree	分布式内存存储	高可用、高并发的分布式系统	优点：高可用性、高性能、分布式支持。缺点：需要MySQL Cluster环境，配置复杂