一、基础体系
核心定义
关系型数据库（RDBMS）：基于关系模型（二维表）、遵循 SQL 标准
架构定位：C/S 架构（客户端-服务端）、TCP/IP 通信（默认3306端口）
底层特性：MVCC（多版本并发控制）、事务日志（redo/undo）支撑高并发
安装与配置（高并发适配）
安装方式
Docker 安装：基于镜像层隔离，快速部署，适合集群环境
源码编译：定制编译参数（如开启大页内存、关闭无用引擎）
核心配置文件（my.cnf/my.ini）
[mysqld] 段（高并发关键配置）
innodb_buffer_pool_size：物理内存50%-70%（缓存数据页/索引页，减少磁盘IO）
innodb_log_file_size：1-4G（redo log 大小，太大恢复慢，太小刷盘频繁）
innodb_flush_log_at_trx_commit=1（事务提交刷盘，高可用）
sync_binlog=1（binlog 同步刷盘，主从一致）
max_connections=10000（高并发连接数，需配合操作系统文件句柄限制）
wait_timeout=60（闲置连接超时，释放资源）
整体架构（分层原理）
连接层：基于 TCP 握手，连接池（ProxySQL/MaxScale）管理连接，避免频繁创建销毁
服务层
SQL 解析器：生成抽象语法树（AST），校验语法
查询优化器：基于成本（CBO）选择执行计划，高并发下需避免全表扫描
执行器：调用存储引擎接口，高并发下减少锁等待
存储层：插件式引擎，InnoDB 为高并发首选
二、SQL 核心
DDL（高并发风险）
执行原理：隐式提交+表锁，高并发下易阻塞
优化方案：Online DDL（8.0）、业务低峰执行、分批次修改
DML（高并发执行）
INSERT 优化
原理：批量插入（INSERT INTO ... VALUES (),(),()）减少日志刷盘次数
高并发方案：分库分表写入、异步写入（消息队列缓冲）
SELECT 优化
执行流程：缓存池→磁盘，高并发下优先命中缓存
优化方案：覆盖索引、避免 SELECT *、分页优化（LIMIT 结合主键）
UPDATE/DELETE 优化
原理：行锁+undo log，高并发下易锁冲突
优化方案：缩小更新范围、短事务、避免长事务持有锁
高级查询（高并发避坑）
JOIN 优化：小表驱动大表，避免大表 JOIN 大表（高并发下内存溢出）
子查询优化：转为 JOIN，减少嵌套执行（高并发下性能下降）
三、数据存储
数据类型（高并发选择）
原则：更小的数据类型=更快的IO+更多的缓存（如用 TINYINT 代替 INT）
避坑：避免 TEXT/BLOB 大字段（高并发下IO耗时，可拆分到单独表）
存储引擎（高并发对比）
InnoDB（高并发首选）
优势：行锁、MVCC、事务、崩溃恢复
高并发优化：innodb_thread_concurrency=64（控制并发线程数）
MyISAM：不支持行锁，高并发写场景绝对禁用
TokuDB：高写入场景（如日志），压缩比高，但读性能略差
磁盘文件（高并发调优）
表空间：独立表空间（.ibd），便于单表恢复/迁移
数据页：16KB 默认，高并发写可调整（需测试，不建议随意改）
磁盘选型：SSD（IOPS 高）> NVMe SSD > 机械硬盘（高并发下机械硬盘IO瓶颈）
四、索引体系
索引底层结构对比（核心）
B+ 树索引（InnoDB 主流）
结构：多路平衡树，非叶子存键+指针，叶子节点有序链表
优点：范围查询极快（> / between / order by）、磁盘IO少（层高2~3层）、适合排序/分组/联合查询
缺点：插入无序会造成页分裂、等值查询不如哈希索引快
哈希索引
结构：哈希表
优点：等值查询=O(1)（极快）
缺点：不支持范围/排序/模糊/最左前缀、大量哈希冲突会退化
使用场景：Memory 引擎、等值查询极高并发场景
全文索引
结构：倒排索引
优点：分词检索、MATCH AGAINST 远快于 like %xx%
缺点：占空间、写入慢、只适合文本搜索
索引类型对比（实用级）
主键索引（聚簇）：叶子存整行数据，每张表唯一；行锁最小粒度；不回表；适用主键查询、增删改主锚点
唯一索引：键唯一，允许NULL；锁机制同普通索引；回表（InnoDB）；适用手机号、身份证、唯一业务键
普通索引：无约束，叶子存主键；行锁；回表；适用常规查询加速
联合索引：多列按顺序构建B+树；锁机制同普通索引；满足最左可覆盖；适用多条件组合查询
覆盖索引：查询列全部在索引里；无额外IO；不回表；高并发必用
聚簇索引 vs 非聚簇索引（核心对比）
聚簇索引（InnoDB）：数据跟主键索引绑在一起；叶子节点=整行数据；优点（主键查询最快、范围查询连续IO）；缺点（主键插入无序→页分裂严重、表必须有主键）
非聚簇索引（MyISAM）：数据和索引分开存储；索引叶子存行指针；优点（索引更新快）；缺点（回表是随机IO，高并发拉胯）
联合索引最左前缀原理（详细）
联合索引 (a,b,c) 等价于：(a)、(a,b)、(a,b,c)
能命中：where a=?、where a=? and b=?、where a=? and b=? and c=?
不能命中：where b=?、where c=?、where a=? and c=?（b断链，c失效）
索引失效场景（详细总结）
索引列使用函数、运算：year(create_time)=2025
模糊查询以 % 开头：like '%abc'
类型隐式转换：varchar 字段用数字查询
联合索引不满足最左前缀
优化器认为全表更快（数据量小）
or 前后有一列无索引→整句失效
not in / != / is not null 有时会失效
执行计划（高并发分析）
关键字段：type（ALL 需优化）、rows（预估扫描行数）、Extra（Using filesort/Using temporary 需优化）
分析工具：EXPLAIN ANALYZE（8.0+），精准分析执行耗时
五、事务与锁
事务 ACID 底层实现
原子性：undo log 记录数据前镜像，回滚时直接恢复到修改前状态
一致性：由原子性、隔离性、持久性共同保证，配合主键/外键等约束
隔离性：MVCC（多版本并发控制）+ 锁机制，避免事务间相互干扰
持久性：redo log 预写日志，事务提交后日志刷盘，即使崩溃也能恢复数据
四大隔离级别 + 问题 + 实现原理
读未提交（RU）：允许脏读、不可重复读、幻读；实现机制：不加锁，直接读取最新数据；适用场景：无（几乎不用）
读已提交（RC）：禁止脏读，允许不可重复读、幻读；实现机制：每次查询生成新 ReadView；高并发推荐（锁范围小、并发高）
可重复读（RR）：禁止脏读、不可重复读、幻读（InnoDB 专属）；实现机制：事务第一次 SELECT 生成 ReadView，全程复用 + Next-Key Lock；MySQL 默认级别
串行化（S）：禁止所有并发问题；实现机制：全部加锁，事务串行执行；适用场景：数据一致性要求极高的低并发场景（如财务对账）
MVCC 详细原理（面试必问）
隐藏列（每行必备）：trx_id（生成该数据版本的事务ID）、roll_pointer（指向 undo log 版本链的指针）
版本链：数据更新不直接覆盖，而是新增版本，旧版本存入 undo log，多个版本形成链表，供回滚和快照读使用
ReadView（可见性视图）：判断数据版本是否对当前事务可见
核心字段：m_ids（当前活跃事务ID集合）、min_trx_id（活跃事务最小ID）、max_trx_id（下一个要分配的事务ID）、creator_trx_id（当前事务ID）
可见规则：1. trx_id == creator_trx_id → 可见；2. trx_id < min_trx_id → 可见；3. trx_id >= max_trx_id → 不可见；4. trx_id 在 m_ids 中 → 不可见，否则可见
关键区别：RC 级别每执行一条 SELECT 生成新 ReadView；RR 级别事务第一次 SELECT 生成 ReadView，全程复用
锁机制
按粒度分类：
表锁：锁全表，并发极差，MyISAM 默认，InnoDB 仅 DDL 时使用
页锁：粒度介于表锁和行锁之间，极少使用
行锁：锁单行数据，InnoDB 高并发基础，粒度细、冲突少
按属性分类：
共享锁（S锁，读锁）：多个事务可同时持有，用于读操作；互斥排他锁（X锁）
排他锁（X锁，写锁）：仅一个事务可持有，用于写操作；互斥共享锁和其他排他锁
InnoDB 行锁算法（重点，解决幻读）：
记录锁（Record Lock）：锁定单行具体记录，仅锁定存在的行
间隙锁（Gap Lock）：锁定数据间隙（不存在的行范围），防止插入新数据；仅在 RR 级别生效
Next-Key Lock：记录锁 + 间隙锁的组合，InnoDB 默认行锁算法；解决 RR 级别下的幻读问题；RC 级别下会退化为记录锁（减少锁冲突）
快照读 vs 当前读
快照读（无锁，高并发首选）：普通 SELECT 语句；读取 MVCC 历史版本；不加锁，不阻塞其他事务；是高并发并发控制的核心
当前读（加锁，保证一致性）：select ... for update、insert / update / delete；读取数据最新版本，同时加锁；防止并发修改，保证数据一致性
死锁原理 + 解决方案
死锁四大条件：互斥（锁不可共享）、请求与保持（持有一个锁，再请求另一个）、不可剥夺（锁不能被强制收回）、循环等待（多个事务互相等待对方释放锁）
解决方案：固定加锁顺序（最有效）、拆分长事务（减少锁持有时间）、快提交事务、设置 innodb_lock_wait_timeout（锁等待超时时间）、开启死锁检测（innodb_deadlock_detect=ON）、使用 RC 级别减少间隙锁冲突
六、日志体系
redo log（重做日志，保证持久性）
核心作用：保证事务持久性（ACID 中的 D）、实现崩溃恢复（crash-safe）、采用 WAL（Write-Ahead Logging）机制（先写日志，再写磁盘）
核心特点：物理日志（记录数据页的修改位置、偏移量，而非SQL语句）、循环写（固定大小，写满后覆盖旧日志）、顺序IO（写入速度极快，适配高并发）
关键配置（生产环境必配）：
innodb_log_file_size：单个 redo log 文件大小，推荐1G~4G（太大：崩溃恢复慢；太小：刷盘频繁，影响性能）
innodb_log_files_in_group：redo log 文件数量，默认2个（ib_logfile0、ib_logfile1）
innodb_flush_log_at_trx_commit：日志刷盘策略（0：每秒写日志+刷盘，可能丢1秒数据；1：每次事务提交写日志+刷盘，最安全，生产推荐；2：每次提交写日志，每秒刷盘，允许秒级数据丢失，兼顾性能和安全）
崩溃恢复原理：启动时读取 redo log，将未刷盘的修改重新应用到数据页，恢复到崩溃前状态
undo log（回滚日志，实现原子性+MVCC）
核心作用：实现事务原子性（ACID 中的 A）、支撑 MVCC（生成历史版本，供快照读和回滚）
日志类型（按操作分类）：
insert undo：记录插入操作的日志，仅用于事务回滚；事务提交后可立即清理（插入的数据无历史版本依赖）
update undo：记录更新/删除操作的日志，用于事务回滚和 MVCC 版本链；事务提交后不能立即清理，需等待所有依赖该版本的事务结束后清理
存储位置：默认存于系统表空间（ibdata1），可配置独立存储（避免表空间膨胀）
binlog（二进制日志，主从复制+数据恢复）
核心作用：主从复制（从库通过 binlog 同步主库数据）、基于时间点恢复（PITR，恢复到指定时间点的数据）
核心特点：逻辑日志（记录SQL语句的执行逻辑或行数据变更）、追加写（不会覆盖，文件大小可配置）、与存储引擎无关（所有引擎都支持）
三种日志格式（重点对比）：
STATEMENT（语句级）：记录执行的SQL语句；优点：日志文件小、写入快；缺点：不确定函数（now()、rand()）会导致主从数据不一致；不推荐生产使用
ROW（行级，推荐）：记录每行数据的变更（插入/更新/删除前后的内容）；优点：主从数据精准一致，不受函数影响；缺点：日志文件大、写入速度略慢
MIXED（混合级）：自动切换 STATEMENT 和 ROW 格式；简单场景用 STATEMENT，复杂场景用 ROW；兼顾大小和一致性，但不如 ROW 稳定
关键配置：
sync_binlog=1：每次事务提交时，将 binlog 同步刷盘；保证主从一致，生产推荐（避免 binlog 丢失导致主从错乱）
binlog_format=ROW：设置日志格式为行级，保证主从数据一致
两阶段提交（2PC，保证日志一致性）
核心目的：保证 redo log 与 binlog 同步一致，避免主从数据错乱（若只写一个日志，另一个未写就崩溃，会导致数据不一致）
详细执行流程：
prepare 阶段：事务提交时，先写入 redo log，标记为「prepare」状态；此时 redo log 已刷盘（若崩溃，重启后可通过 binlog 判断是否需要提交）
写入 binlog：将事务的 binlog 写入磁盘，确保 binlog 完整（若崩溃，重启后删除 redo log 的 prepare 标记，事务回滚）
commit 阶段：将 redo log 的状态从「prepare」改为「commit」，事务正式完成；此时即使崩溃，重启后通过 redo log 的 commit 标记，确认事务已完成
其他辅助日志
错误日志：记录 MySQL 启动、运行、崩溃过程中的错误信息；用于排查启动失败、运行异常等问题
慢查询日志：记录执行时间超过 long_query_time（默认10秒，高并发下建议设为1秒）的 SQL 语句；是 SQL 优化的核心工具；高并发下需开启，用于定位慢查询瓶颈
通用查询日志：记录所有 MySQL 接收的 SQL 请求；日志量大，高并发场景禁止开启（会严重影响性能）
七、高并发架构解决方案
读写分离（基础方案，分散读压力）
核心原理：主库负责写操作（insert/update/delete），从库负责读操作（select）；分散高并发读压力，提升整体吞吐量
实现架构：
基础版：主库 + 1~N 从库，通过 ProxySQL/MaxScale 做读写路由（自动将读请求转发到从库，写请求转发到主库）
高可用版：主从切换（MHA/Keepalived），当主库故障时，自动切换到从库，避免主库单点故障
核心问题：主从延迟（高并发写场景下，binlog 同步不及时，导致从库数据比主库滞后）
解决方案：开启半同步复制（主库等待从库确认接收 binlog 后再返回）、开启并行复制（innodb_parallel_read_threads=8，提升从库同步速度）、业务层面容忍延迟（如读从库失败降级读主库）、避免大事务（减少 binlog 生成量）
分库分表（海量数据+高并发写，突破单库单表瓶颈）
适用场景：单表数据量>1000万、QPS>1万、单库磁盘空间不足
分库分表方式（详细）：
垂直分库：按业务模块拆分（如用户库、订单库、商品库）；解决单库压力过大、不同业务隔离的问题
垂直分表：按字段拆分（如用户基本信息表+用户详情表）；解决单表字段过多、大字段IO耗时的问题
水平分表：按规则拆分单表数据（如订单表按用户ID哈希拆分、按时间范围拆分）；解决单表数据量过大、查询/写入变慢的问题
实现中间件：
应用层中间件：Sharding-JDBC（嵌入应用，无额外部署成本，性能好）
代理层中间件：MyCat（独立部署，对应用透明，便于管理）
核心问题及解决方案：
跨库Join：解决方案→全局表（公共数据，如字典表，每个库都存一份）、冗余字段（避免跨库查询）、应用层聚合（先查各库数据，再在应用层合并）
分布式事务：解决方案→Seata（支持TCC/SAGA模式，保证强一致性）、消息队列（最终一致性，适合非核心业务）
扩容困难：解决方案→预分片（提前规划分片数量，避免后期扩容）、一致性哈希（减少扩容时的数据迁移量）
缓存架构
核心架构：MySQL + Redis（多级缓存）；利用 Redis 高性能，减少 MySQL 读压力（高并发读场景，Redis 命中率可达90%以上）
实现逻辑：
读请求：先查 Redis→未命中查 MySQL→将 MySQL 结果写入 Redis（设置合理过期时间）
写请求：先更新 MySQL→删除 Redis 对应缓存（避免缓存与数据库不一致，禁止先删缓存再更数据库）
核心问题及解决方案（高并发下缓存三大异常）：
缓存穿透：高并发下查询不存在的数据（如恶意查询不存在的用户ID），导致请求全部打向 MySQL，击穿数据库
解决方案：布隆过滤器（提前过滤不存在的key）、缓存空值（将不存在的key缓存，设置短期过期时间）
缓存击穿：高并发下热点Key（如热门商品ID）过期，大量请求同时打向 MySQL，导致MySQL压力骤增
解决方案：热点Key永不过期（定期更新缓存）、互斥锁（多个请求竞争锁，只有一个请求查MySQL并更新缓存）
缓存雪崩：高并发下大量Key同时过期，或Redis集群故障，导致所有请求打向MySQL，引发服务雪崩
解决方案：Key过期时间随机（避免同时过期）、部署Redis集群（避免单点故障）、多级缓存（本地缓存+Redis+MySQL，兜底保障）
数据库集群
MGR（MySQL Group Replication，组复制）
核心原理：基于Paxos协议，支持多主/单主模式；多个节点组成集群，数据实时同步，自动选主（主库故障时，自动选举新主），保证数据一致性
适用场景：高并发+高可用场景（如电商核心交易、金融支付）
优化配置：设置 group_replication_single_primary_mode=ON（单主模式，减少多主写冲突，提升并发性能）
分片集群（MyCat + MGR）
核心原理：分库分表（MyCat）+ 集群（MGR）；既分散读写压力，又保证每个分片的高可用；适合超大规模数据（如亿级订单表、千万级用户表）
异步写入（高并发写削峰，非实时场景适用）
核心架构：业务系统→消息队列（Kafka/RabbitMQ）→消费程序→MySQL
适用场景：非实时写场景（如日志收集、统计数据上报、用户行为记录）
核心问题：数据一致性（消息丢失、消费失败导致数据未写入MySQL）
解决方案：消息确认机制（生产者确认消息发送成功，消费者确认消息消费成功）、重试机制（消费失败自动重试，避免数据丢失）、最终一致性校验（定期对比消息队列和MySQL数据，补全缺失数据）
八、高并发常见问题与解决方案（根因+落地）
连接数耗尽
根因：高并发下 max_connections 设置过小、连接未及时释放（如长连接未关闭）、慢查询占满连接池
解决方案：调大 max_connections（结合操作系统文件句柄限制）、开启连接池（ProxySQL/MaxScale）、优化慢查询（减少连接占用时间）、设置 wait_timeout（闲置连接自动释放）
IO 瓶颈（高并发下最常见）
根因：高并发下全表扫描、索引失效（导致大量磁盘IO）、磁盘IOPS不足（如机械硬盘）、innodb_buffer_pool_size 过小（缓存命中率低）
解决方案：优化索引（避免失效，使用覆盖索引）、升级磁盘（用SSD/NVMe SSD，提升IOPS）、增大 innodb_buffer_pool_size（提升缓存命中率，减少磁盘IO）、分库分表（分散IO压力）
CPU 飙升
根因：高并发下复杂SQL（如多表JOIN、大量聚合函数）、锁竞争激烈（导致CPU占用过高）、MySQL 进程占用过多资源
解决方案：简化SQL（拆分复杂查询、减少聚合函数使用）、优化索引（减少锁竞争）、拆分长事务（缩短锁持有时间）、限制MySQL进程CPU使用率（避免影响其他服务）
主从延迟
根因：高并发写导致 binlog 生成过快、从库复制线程数不足、从库硬件性能差、大事务（单事务生成大量binlog）
解决方案：开启并行复制（提升从库同步速度）、升级从库硬件（CPU/内存/磁盘）、拆分大事务（减少binlog生成量）、业务层面容忍延迟（如非核心读请求走从库，核心读请求走主库）
数据不一致
根因：高并发下主从复制异常（binlog丢失、同步中断）、分布式事务未处理好、缓存与数据库更新策略不当
解决方案：监控主从状态（及时发现同步异常）、使用分布式事务中间件（Seata）、优化缓存更新策略（先更数据库再删缓存）、定期校验数据（主从数据对比，补全不一致数据）
服务雪崩
根因：高并发下慢查询占满连接池→新请求无法处理→服务连锁故障→整体不可用
解决方案：熔断（Sentinel/Hystrix，当MySQL异常时，熔断请求，避免服务拖垮）、限流（限制QPS，避免超出MySQL承载能力）、降级（非核心功能关闭，优先保障核心业务，如读缓存返回默认值）、应急扩容（临时增加从库、提升缓存容量）
九、高并发监控与运维
核心监控指标
连接数指标：Threads_connected（当前连接数）、Threads_running（活跃连接数，高并发下需控制在CPU核心数2倍以内）
锁指标：Innodb_row_lock_waits（行锁等待次数）、Innodb_deadlocks（死锁次数）、Innodb_row_lock_time（行锁等待总时间）
IO 指标：Innodb_data_reads（磁盘读次数）、Innodb_data_writes（磁盘写次数）、Innodb_buffer_pool_hit_ratio（缓存命中率，需≥95%）
SQL 指标：Slow_queries（慢查询数）、Select_scan（全表扫描数）、QPS（每秒查询数）、TPS（每秒事务数）
监控工具
开源工具：Prometheus + Grafana（可视化监控，支持自定义面板，实时查看指标）、Zabbix（异常告警，支持邮件/短信通知）、pt-query-digest（慢查询分析工具）
商业工具：MySQL Enterprise Monitor、阿里云RDS监控（自带监控+告警，无需额外部署）
应急处理（高并发故障快速响应）
紧急扩容：临时增加从库（分担读压力）、提升Redis缓存容量（提升缓存命中率）
限流降级：关闭非核心功能（如营销活动）、限制QPS（避免超出MySQL承载能力）
慢查询终止：通过 kill 命令终止慢查询进程，释放连接池资源
数据回滚：基于 binlog 做时间点恢复（PITR），恢复到故障前的数据状态
主从切换：当主库故障时，通过 MHA/Keepalived 自动切换到从库，恢复写服务
