MySQL三层架构分工明确：连接层处理认证与连接，Server层负责SQL解析、优化和执行计划生成，存储引擎层（如InnoDB）实际完成数据读写；各层解耦使SQL逻辑与事务、锁等行为分离。
MySQL 是关系型数据库，它的基本原理不是靠“语法糖”堆出来的，而是由三层协作结构、事务保障机制和物理/逻辑分离设计共同支撑的。如果你在写业务 SQL 时经常遇到慢查询、死锁或主从延迟，大概率是因为没摸清这三块怎么咬合。
MySQL 的三层架构是怎么分工的
最上层是连接与协议处理（比如 mysql_real_connect 建连、认证、SSL 握手），中间层负责 SQL 解析（Parser）、优化（Optimizer）、执行计划生成（EXPLAIN 输出的核心来源），最下层才是存储引擎（如 InnoDB）真正读写磁盘。
关键点在于：SQL 语句在中间层被重写、索引选择、JOIN 顺序调整，而这些决策完全不依赖底层引擎——所以换 MyISAM 或 Archive 引擎时，SELECT 逻辑不变，但并发、事务、锁行为会彻底不同。
-
SELECT * FROM user WHERE id = 1走主键查找，中间层确认用PRIMARY索引后，把定位请求发给InnoDB，后者从Buffer Pool或磁盘页加载数据页 - 如果加了
ORDER BY created_at LIMIT 10，中间层可能放弃索引排序，改用文件排序（Using filesort），哪怕created_at有索引 -
max_allowed_packet是网络层参数，超长INSERT语句在进入解析器前就被截断或报错：Packets larger than max_allowed_packet are not allowed
ACID 是怎么在 InnoDB 里落地的
不是靠口号，是靠三类日志 + 内存结构硬刚出来的：
-
Undo Log存在ibdata1或独立 undo 表空间里，用于回滚和 MVCC 版本链构建；事务未提交前，其他事务查不到你改的数据，靠的是读取对应版本的undo记录 -
Redo Log是固定大小的循环文件（ib_logfile0/1），记录“物理页修改”，崩溃后靠它重放未刷盘的变更；innodb_log_file_size太小会导致频繁 checkpoint，拖慢写入 -
Binlog是 Server 层的日志，格式为STATEMENT/ROW，主从复制和 PITR（按时间点恢复）全靠它；注意：Redo和Binlog通过两阶段提交（prepare → commit）保证一致性
一个 UPDATE 执行时，先写 Undo（留退路），再改内存页并记 Redo（保持久），最后写 Binlog（供复制），缺一不可。
为什么索引失效、锁升级、幻读总在生产环境冒头
因为 MySQL 不会替你做“语义理解”。它只认执行计划，而执行计划受统计信息、隔离级别、索引结构三者联合约束：
-
WHERE status = ? AND create_time > ?，如果status区分度极低（比如只有 0/1），优化器可能直接放弃复合索引，走全表扫描 -
SELECT ... FOR UPDATE在REPEATABLE READ下会对扫描范围加间隙锁（Gap Lock），不是只锁命中行；DELETE同理，删 1 行可能锁住整个区间 -
SELECT COUNT(*)在InnoDB里不是查元数据，而是实际遍历聚簇索引，大表无条件统计必然慢；加WHERE也未必快——要看是否能利用索引覆盖
真正容易被忽略的是：autocommit=1 时每个语句都是独立事务，但 SET autocommit=0 后没显式 COMMIT，连接挂了就变成长事务，Undo Log 无法清理，Buffer Pool 脏页堆积，主从延迟飙升。
