2. MySQL架构与存储引擎选型

MySQL 之所以能在企业级场景中同时支撑高并发事务、复杂查询和多种业务形态，核心在于它采用了分层架构：连接层负责接入与安全，SQL 层负责解析、优化与执行调度，存储引擎层负责数据的实际读写与事务实现。理解这三层的职责边界，是后续做存储引擎选型、性能调优和故障定位的基础。

一、三层架构的职责划分

连接层是客户端进入 MySQL 的第一道关口。它处理 TCP 连接、SSL 加密、用户认证（用户名、密码、来源主机）、权限校验，并为每个连接分配一个线程（或由线程池复用）。连接建立后，客户端发送的 SQL 文本才会进入 SQL 层。连接层的典型参数包括 max_connections、wait_timeout、thread_cache_size。当出现“Too many connections”时，问题通常出在连接层而非 SQL 层。

SQL 层是 MySQL 的“大脑”，与存储引擎无关。它依次完成：查询缓存（8.0 已移除）、解析器做词法与语法分析生成解析树、预处理器校验表和列是否存在、优化器基于统计信息选择索引与连接顺序、执行器调用存储引擎接口获取数据并做过滤、排序、聚合。SQL 层还统一管理视图、触发器、存储过程、权限和 binlog。因此，一条慢 SQL 既可能是优化器选错索引，也可能是存储引擎层锁等待，需要分层排查。

存储引擎层是数据的“仓库”，以插件形式存在。MySQL 通过统一的 handler API 与引擎交互，不同引擎决定数据如何存储、索引如何组织、是否支持事务和行锁。常见的引擎有 InnoDB、MyISAM、Memory、Archive、CSV 等。其中 InnoDB 是 5.5 之后的默认引擎，也是企业级 OLTP 场景的首选。

二、InnoDB 与 MyISAM 的关键差异

两者最本质的区别在于事务与锁粒度。InnoDB 支持 ACID 事务、行级锁、MVCC 多版本并发控制和外键，适合订单、支付、库存等强一致场景；MyISAM 只支持表级锁、无事务、无崩溃恢复能力，一次写操作会阻塞整张表的读写。在并发写入较高的系统中，MyISAM 的表锁会迅速成为瓶颈。

在索引结构上，InnoDB 使用聚簇索引：主键索引的叶子节点直接存放整行数据，二级索引叶子存放主键值，因此按主键查询最快，但二级索引回表会多一次查找。MyISAM 的索引与数据分离，索引叶子存放数据文件的行地址，主键和二级索引结构一致，都需要一次额外的数据文件定位。

在计数与统计上，MyISAM 保存了精确的行数，SELECT COUNT(*) 无需扫描即可返回；InnoDB 不保存精确行数，需要遍历索引统计，因此大表 COUNT(*) 会明显偏慢。这也是很多报表场景误选 MyISAM 的原因，但可以用汇总表或缓存替代。

在崩溃恢复上，InnoDB 依靠 redo log 和 undo log 实现崩溃后的自动恢复，MyISAM 崩溃后可能产生数据文件损坏，需要 myisamchk 修复，且无法保证数据不丢失。

三、企业选型方法

选型不应凭“哪个快”的直觉，而应围绕业务特征做判断。可以按以下决策路径推进：

1. 是否需要事务：只要涉及转账、扣减库存、订单状态流转等一致性要求，直接选 InnoDB，无需继续比较。
2. 并发写入程度：写多或读写混合且并发较高时选 InnoDB；纯读、批量写入且能接受表锁的场景才考虑 MyISAM。
3. 数据可靠性要求：不能容忍崩溃丢数据或损坏，必须 InnoDB。
4. 特殊功能需求：需要全文索引时，MySQL 5.6 之后 InnoDB 已支持；需要极高压缩比的日志归档，可考虑 Archive；需要内存级临时表，可用 Memory。
5. 迁移成本：从 MyISAM 迁移到 InnoDB 需评估大事务、锁等待和磁盘空间，建议在低峰期用 ALTER TABLE ... ENGINE=InnoDB 分批执行。

四、选型检查清单（可直接使用）

最后需要强调：存储引擎是表级属性，同一数据库中可以混用。例如核心交易表用 InnoDB，历史日志表用 Archive，临时统计表用 Memory。选型的落脚点始终是业务对一致性、并发和可靠性的真实要求，而不是单一的性能数字。