MySQL 并非只是一个单纯的“存储数据的程序”，它的设计理念决定了它能在各种规模的场景中保持灵活与高效。理解它的三个核心设计思想，能帮助你从“会用”提升到“懂得为什么这么用”。
1.2.1 客户端/服务器架构
MySQL 采用经典的客户端/服务器（C/S）架构。这意味着 MySQL 数据库本身是一个独立的服务进程（mysqld），应用程序不直接操作数据文件，而是通过网络连接向服务进程发送 SQL 请求，服务进程访问数据文件，再将结果返回。
这个架构在实际应用中表现为：
- 服务进程（mysqld）：负责管理数据库文件、解析 SQL 语句、执行查询、控制并发，是数据库的“大脑”。启动 MySQL 服务后，它就在后台持续监听端口（默认 3306）。
- 客户端程序（mysql）：可以是官方的命令行工具
mysql，也可以是你用 Java、Python、Go 等语言编写的应用程序。客户端通过 TCP/IP 或本地 Socket 与服务进程通信。 - 连接协议：客户端与服务端之间有一套标准的通信协议，传输的是序列化后的请求和响应，并不是直接传文本 SQL。这套协议保证了不同语言的驱动程序（如 JDBC、Python 的
mysql-connector）都能与 MySQL 正常交互。
在服务进程内部，架构又被细分为连接层、服务层、引擎层、存储层（将在第 3 章详细展开）。连接层负责建立和管理客户端连接，例如：
- 当客户端请求连接时，服务端分配一个线程（或线程池中的线程）为该连接服务。
- 连接建立后需要经过身份认证（用户名、密码、主机名），然后与特定的数据库绑定。
- 每个连接都有自己的会话级变量，如字符集、事务隔离级别等。
这种架构带来的实际好处是：数据与应用程序分离。应用程序和后端数据库可以部署在同一台服务器，也可以分离到不同服务器，甚至将数据库部署到独立的集群上。连接只需提供 IP 和端口，这为分布式部署、读写分离、负载均衡等架构提供了基础。
还有一个开发者会经常接触到的概念：连接池。由于每次建立连接都需要 TCP 三次握手、权限验证等开销，频繁创建和销毁连接会严重影响性能。因此，应用程序通常会使用连接池（如 HikariCP、C3P0）来复用连接。MySQL 服务端也可以通过配置 max_connections 对连接数进行硬限制，防止资源耗尽。
1.2.2 插件式存储引擎
插件式存储引擎是 MySQL 最具标志性的设计之一，也是它区别于 Oracle、PostgreSQL 等数据库的最重要特征。简单地说，MySQL 将数据的具体存储和检索方式抽象为引擎层，用户可以在创建表时指定使用哪种引擎，甚至可以在同一个库中混用不同引擎的表。
这意味着什么？
- 服务层只负责 SQL 解析、优化、权限检查等通用逻辑，而不关心数据到底怎么存。
- 真正的数据读写、索引维护、事务管理、锁机制都由底层存储引擎完成。
- 每种引擎有各自的特点和适用场景，就像同一辆车可以换装不同型号的发动机，你可以根据路况选择。
在 MySQL 中，查看当前支持哪些引擎可以用命令 SHOW ENGINES;。常见的引擎包括：
- InnoDB：从 MySQL 5.5 开始成为默认引擎。它支持事务（ACID）、行级锁、MVCC、外键，并且在崩溃后可以通过重做日志自动恢复。绝大多数业务场景都应选择 InnoDB。如果你的公司只使用一种引擎，那么一定是 InnoDB。
- MyISAM：MySQL 早期默认引擎，不支持事务和行锁，只有表级锁，崩溃后容易丢数据。它的优势是简单、节省空间，曾经在只读或日志类场景中有一定使用。现在基本不建议再用，因为 InnoDB 已经全面超越它。
- Memory：数据全部存在内存中，使用 HASH 或 B 树索引，重启后数据会丢失。适合做临时表或缓存中间结果，但不能用于存储需要持久化的数据。
- Archive：只支持 INSERT 和 SELECT，用压缩格式存储，适合归档很少更新的历史数据。
- 此外还有 CSV、Blackhole、Federated 等特殊用途引擎。
在实际建表时，可以通过 ENGINE=InnoDB 指定引擎，如果不写则使用服务器默认引擎（通常就是 InnoDB）。你也可以通过 ALTER TABLE ... ENGINE=InnoDB 将表转换为其他引擎。但要特别注意，引擎之间的转换可能会丢失特性（比如将 InnoDB 表转为 MyISAM 会丢失事务支持），而且并非所有引擎都互相兼容。
插件式引擎的设计还带来了一个巨大优势：可扩展性。你甚至可以根据 API 规范编写自己的存储引擎，让 MySQL 与你的特定数据存储系统对接。尽管实际开发自定义引擎的情况很少，但大量第三方或公司内部正是利用这个特性实现了定制化存储方案。
1.2.3 SQL 标准兼容
SQL（Structured Query Language）是操作关系型数据库的通用语言，有 ANSI/ISO 定义的标准。MySQL 对 SQL 标准的支持总体良好，但也存在一些特有扩展和差异。
首先，MySQL 使用的是标准 SQL 的变体，它兼容大部分 SQL:1992、SQL:1999 和 SQL:2003 标准，同时在标准之上增加了一些实用的函数和语法，例如 LIMIT 子句、REPLACE 语句、反引号（`）作为标识符引用符。这些扩展在实际开发中非常便利，但可能导致从其他数据库迁移时需要注意调整个别语法。
在 SQL 标准兼容方面，一个重要的机制是 sql_mode 服务器变量。它可以调整 MySQL 的行为，使其更严格地遵守 SQL 标准，或者容忍一些宽松的输入。常见模式有：
STRICT_TRANS_TABLES：对于事务型存储引擎，当插入不合法的数据时，语句会失败并抛出错误，而不是像非严格模式那样仅发出警告，并把值转换为最接近的有效值。生产环境强烈建议开启此模式，能避免脏数据悄悄进入数据库。ONLY_FULL_GROUP_BY：要求GROUP BY子句中的列必须出现在SELECT列表中，或者被聚合函数包裹，否则查询会报错。这个模式能避免结果中的随机性，符合标准 SQL 规范。NO_ZERO_DATE、NO_ZERO_IN_DATE：禁止将'0000-00-00'这样的非法日期写入表，强制规范日期数据。
从 MySQL 5.7 开始，新安装的实例默认启用了严格模式（STRICT_TRANS_TABLES 等），这正体现了 MySQL 向标准靠拢的趋势。到了 MySQL 8.0，更多现代 SQL 特性被支持：窗口函数（ROW_NUMBER(), RANK()）、公共表表达式（CTE 即 WITH 子句）、递归 CTE、INTERSECT 和 EXCEPT 集合操作等。这使得 MySQL 在分析类查询中的表现能力大幅提升。
另外需要注意的是，不同数据库系统的 SQL 方言差异。例如，Oracle 使用 CONNECT BY 做递归查询，而 MySQL 8.0 中使用 WITH RECURSIVE；PostgreSQL 有更丰富的数据类型；SQL Server 使用 TOP 而 MySQL 使用 LIMIT。如果你需要做数据库迁移，一定要注意这些差异点，并利用 sql_mode 调整兼容行为，必要时通过中间件或手动改写 SQL。
总之，MySQL 完全胜任标准 SQL 的日常开发需求，而它的扩展语法和灵活的兼容模式则为开发者提供了额外的便利和可控性。在实际项目里，只要避开个别不相容的写法，并开启严格模式，就可以用标准的 SQL 思维方式来组织和查询数据。
通过这三个核心设计，MySQL 在最外层架构、内部存储与 SQL 交互三个维度上实现了高度的灵活和可配置性，也为其后续的优化、扩展和运维奠定了坚实基础。