MySQL核心应用全解析：存储引擎/日志/事务/索引/锁 + 慢SQL优化 + NoSQL场景-洪萨配资

文章目录

目录
- 前言
- 一、MySQL核心特性深度解析
- - 1. 常用存储引擎对比（MySQL核心差异化特性）
  - - 核心引擎详细说明
  - 2. MySQL核心日志体系（数据安全+故障恢复+排查优化）
  - - 核心日志详细说明
  - 3. MySQL事务特性（ACID+隔离级别）
  - - 3.1 事务ACID特性详解
    - 3.2 事务隔离级别（解决并发事务冲突问题）
    - 核心说明
  - 4. MySQL索引机制（提升查询效率的核心）
  - - 4.1 索引分类对比表
    - 4.2 核心索引详细说明
  - 5. MySQL锁机制（解决并发数据冲突）
  - - 5.1 锁分类对比表
    - 5.2 核心锁详细说明
- 二、慢SQL问题排查与全流程优化
- - 1. 慢SQL排查流程（步骤化+工具化）
  - - 关键工具说明
  - 2. 慢SQL全流程优化（多维度落地）
- 三、NoSQL数据库核心解析（使用场景+与MySQL对比）
- - 1. MySQL与NoSQL核心对比表
  - 2. NoSQL主流类型及使用场景表
  - 3. NoSQL核心使用场景总结
  - 4. NoSQL不适用场景
- 四、总结与实践建议

MySQL作为全球最流行的开源关系型数据库（RDBMS），凭借轻量高效、开源免费、生态完善的特性，占据了互联网后端存储的半壁江山。在实际生产环境中，能否吃透MySQL的核心特性（存储引擎、日志、事务、索引、锁），能否快速排查并优化慢SQL，以及合理选择NoSQL作为补充，直接决定了系统的性能、稳定性和可扩展性。

一、MySQL核心特性深度解析

1. 常用存储引擎对比（MySQL核心差异化特性）

存储引擎是MySQL的灵魂，不同引擎对应不同的存储机制、功能特性和性能表现，InnoDB为当前默认且主流的引擎。

对比维度	InnoDB（默认）	MyISAM（经典旧引擎）	Memory（Heap）	Archive（归档引擎）
事务支持	支持（完整ACID特性）	不支持	不支持	不支持
MVCC支持	支持（多版本并发控制，提升读并发）	不支持	不支持	不支持
锁粒度	行级锁（粒度细，并发性能高）+ 表级锁（兜底）	表级锁（粒度粗，并发性能低）	表级锁	行级锁（仅支持插入/查询，无更新/删除）
索引类型	B+树索引（主键索引聚簇索引，辅助索引非聚簇）	B+树索引（均为非聚簇索引）	哈希索引/BTREE索引	无索引（仅支持自增ID排序）
外键支持	支持	不支持	不支持	不支持
全文索引/地理索引	支持（5.6版本后）	支持	不支持	不支持
数据持久化	支持（磁盘存储，崩溃可恢复）	支持（磁盘存储）	不支持（内存存储，重启丢失）	支持（磁盘存储，高压缩比）
缓存机制	缓冲池（缓存数据+索引）	仅缓存索引	全部数据缓存于内存	无专门缓存
适用场景	电商、金融等需要事务、高并发的核心业务	博客、静态数据等只读/少写的查询场景	临时数据存储、高频查询的临时表	日志归档、数据备份等批量插入+极少查询的场景
核心优势	事务安全、并发高、崩溃恢复、数据一致性强	查询速度快、占用磁盘空间小	读写速度极快（内存操作）	高压缩比、批量插入效率极高
核心劣势	占用资源多、查询速度略逊于MyISAM	无事务、并发差、无崩溃恢复	数据易丢失、不支持大数据量	不支持更新/删除、查询功能有限

核心引擎详细说明

InnoDB：生产环境首选，通过redo log和undo log保障事务一致性和崩溃恢复，行级锁大幅提升高并发场景下的性能，聚簇索引优化查询效率，支持外键和MVCC，完美适配需要强数据一致性的业务（如订单、支付、用户信息）。
MyISAM：已逐步被InnoDB替代，无事务开销，查询速度更快，但表级锁导致写入操作（插入/更新/删除）会阻塞全表查询，且崩溃后无法恢复数据，仅适用于静态只读场景。
Memory：数据存储在内存中，读写性能极致，但重启MySQL后数据丢失，适用于临时计算、会话存储等无需持久化的场景。
Archive：数据以高压缩格式存储，批量插入效率极高，但不支持更新和删除，仅支持简单查询，适用于日志归档、审计数据存储等场景。

2. MySQL核心日志体系（数据安全+故障恢复+排查优化）

MySQL日志是保障数据一致性、实现主从复制和排查问题的关键，核心日志包括redo log、undo log、binlog三大核心，辅以其他辅助日志。

日志类型	核心作用	存储内容	持久化方式	引擎依赖	适用场景
Redo Log（重做日志）	保障事务持久性、崩溃恢复（防止数据丢失）	物理日志（记录数据页的修改内容，如“页X偏移Y改为Z”）	循环写入（固定大小文件组）	仅InnoDB	数据库崩溃后恢复未刷盘的事务数据、保障ACID持久化
Undo Log（回滚日志）	事务回滚、MVCC多版本并发控制	逻辑日志（记录数据修改前的状态，如“将ID=1的name从A改为B”的反向操作）	追加写入（按事务生成）	仅InnoDB	事务回滚（执行ROLLBACK）、快照读（实现可重复读）
Binlog（二进制日志）	主从复制、数据备份与恢复	逻辑日志（记录SQL语句的执行逻辑，或行级修改内容）	追加写入（可配置刷盘策略）	所有引擎	主从同步（备库通过binlog复制主库数据）、数据误删后恢复
Error Log（错误日志）	记录MySQL启动/运行/停止过程中的错误信息	错误信息、警告信息、异常堆栈等	追加写入	所有引擎	排查MySQL启动失败、运行异常等问题
Slow Query Log（慢查询日志）	记录执行时间超过阈值的SQL语句	慢SQL语句、执行时间、锁等待时间、执行用户等	追加写入	所有引擎	定位慢SQL、优化性能瓶颈
General Log（通用日志）	记录所有MySQL的连接请求和SQL执行记录	连接信息、所有SQL语句（包括查询/写入）	追加写入	所有引擎	调试SQL执行流程、排查异常操作（生产环境不建议开启，性能开销大）

核心日志详细说明

Redo Log：InnoDB独有，采用“预写日志（WAL）”机制，事务提交时先写入redo log，再异步刷盘到数据文件，避免频繁磁盘IO，保障崩溃后未刷盘的数据不丢失。其循环写入特性意味着旧日志会被覆盖，仅用于短期崩溃恢复，不用于数据备份。
Undo Log：InnoDB独有，与事务绑定，每个事务对应一份undo log，事务回滚时通过undo log恢复数据到修改前状态；同时，MVCC通过读取undo log中的历史版本数据，实现不加锁的快照读，提升读并发性能。
Binlog：服务器层日志（所有引擎通用），有三种格式：STATEMENT（记录SQL语句）、ROW（记录行级修改，推荐）、MIXED（混合模式）。Binlog是主从复制的核心，也是数据误操作后（如误删表）通过备份+binlog恢复数据的关键。

3. MySQL事务特性（ACID+隔离级别）

事务是MySQL保障数据一致性的核心，适用于需要原子性执行的业务场景（如订单创建+库存扣减）。

3.1 事务ACID特性详解

特性名称	英文全称	核心含义	保障机制
原子性（Atomicity）	Atomicity	事务中的所有操作要么全部执行成功，要么全部失败回滚，无中间状态	Undo Log（事务失败时回滚数据）、事务提交/回滚机制
一致性（Consistency）	Consistency	事务执行前后，数据库的完整性约束（主键、外键、唯一性）保持不变	原子性、隔离性、持久性共同保障，业务逻辑约束辅助
隔离性（Isolation）	Isolation	多个事务并发执行时，一个事务的执行结果不会被其他事务干扰	锁机制（悲观锁）、MVCC（乐观锁）、事务隔离级别
持久性（Durability）	Durability	事务提交后，修改的数据永久保存到数据库，即使数据库崩溃也不会丢失	Redo Log（预写日志）、Binlog（辅助数据恢复）

3.2 事务隔离级别（解决并发事务冲突问题）

并发事务会导致脏读、不可重复读、幻读三大问题，不同隔离级别对应不同的问题解决能力和并发性能。

隔离级别名称	脏读（Dirty Read）	不可重复读（Non-repeatable Read）	幻读（Phantom Read）	并发性能	核心说明	MySQL默认级别
读未提交（Read Uncommitted）	允许	允许	允许	最高	一个事务可以读取另一个事务未提交的修改，数据一致性最差	否
读已提交（Read Committed）	禁止	允许	允许	较高	一个事务只能读取另一个事务已提交的修改，解决脏读问题	否（Oracle默认）
可重复读（Repeatable Read）	禁止	禁止	基本禁止（InnoDB）	中等	事务执行期间，多次读取同一数据结果一致，解决脏读、不可重复读；InnoDB通过MVCC+间隙锁解决幻读	是
串行化（Serializable）	禁止	禁止	禁止	最低	事务串行执行，完全避免并发冲突，通过表级锁实现，仅适用于低并发场景	否

核心说明

三大并发问题：
1. 脏读：事务A读取了事务B未提交的修改，后续事务B回滚，事务A读取的数据是无效的“脏数据”。
2. 不可重复读：事务A多次读取同一数据，期间事务B修改并提交了该数据，导致事务A多次读取结果不一致（针对更新操作）。
3. 幻读：事务A按条件查询数据，期间事务B插入了符合该条件的新数据，导致事务A再次查询时出现“新增的数据幻觉”（针对插入操作）。
InnoDB优化：默认隔离级别为可重复读，通过MVCC解决脏读和不可重复读，通过间隙锁（Next-Key Lock）解决幻读，兼顾了数据一致性和并发性能。

4. MySQL索引机制（提升查询效率的核心）

索引是帮助MySQL快速查询数据的数据结构（主流为B+树），相当于数据库的“目录”，合理创建索引可将查询效率提升几个数量级。

4.1 索引分类对比表

分类维度	索引类型	核心特点	适用场景	优点	缺点
按存储结构	B+树索引	叶子节点有序链接，非叶子节点仅存索引键，支持范围查询、排序	绝大部分查询场景（等值查询、范围查询、排序）	查询效率稳定、支持多种查询类型、适配聚簇索引	插入/更新略有开销（需维护B+树结构）
哈希索引	基于哈希表实现，等值查询极速，不支持范围查询	仅等值查询的场景（如Memory引擎默认索引）	等值查询效率极高、插入/更新快	不支持范围查询、不支持排序、存在哈希冲突
全文索引	针对文本内容建立索引，支持关键词模糊查询	文章内容、商品描述等文本检索场景	高效支持模糊关键词查询	占用空间大、查询精度有限
R树索引	针对地理空间数据建立索引，支持空间范围查询	地图位置、地理坐标等空间数据查询	高效支持空间范围查询	适用场景单一、维护成本高
按逻辑功能	主键索引（PRIMARY KEY）	唯一标识记录，自动创建，不允许NULL值，聚簇索引（InnoDB）	唯一标识每条数据（如用户ID、订单ID）	查询效率最高、保障数据唯一性	一张表仅能有一个主键索引
唯一索引（UNIQUE）	索引列值唯一，允许NULL值（最多一个NULL）	保障数据唯一性（如手机号、邮箱）	避免重复数据、查询效率高	插入/更新时需校验唯一性，略有开销
普通索引（INDEX）	无唯一性约束，仅用于提升查询效率	普通查询场景（如商品分类、订单状态）	提升查询效率、创建灵活	无数据校验、占用磁盘空间
复合索引（联合索引）	基于多个字段创建的索引，遵循“最左前缀原则”	多字段联合查询（如name+age、order_no+user_id）	比单字段索引更适配多字段查询、减少索引数量	维护成本高、需遵循最左前缀原则否则失效
前缀索引	基于字符串字段的前N个字符创建索引	长字符串字段查询（如身份证号、URL）	减少索引占用空间、提升查询效率	可能降低索引选择性、不支持后缀查询

4.2 核心索引详细说明

B+树索引：InnoDB默认索引类型，核心优势在于：
1. 叶子节点包含所有索引列（聚簇索引包含整行数据），且按顺序链接，支持范围查询和排序。
2. 非叶子节点仅存储索引键，不存储数据，能缓存更多索引条目，减少磁盘IO。
聚簇索引：InnoDB特有，主键索引默认是聚簇索引，叶子节点存储整行数据；辅助索引叶子节点存储主键值，查询时需回表（通过主键值查聚簇索引），因此主键应尽量选择占用空间小的字段（如自增ID）。
最左前缀原则：复合索引的查询需遵循“从左到右”的字段顺序，若跳过左侧字段，索引会失效（如复合索引(a,b,c)，仅支持a、a,b、a,b,c顺序的查询，不支持b、b,c、a,c的查询）。

5. MySQL锁机制（解决并发数据冲突）

锁是MySQL保障并发事务数据一致性的核心，不同引擎的锁机制差异极大，InnoDB的锁机制最为灵活高效。

5.1 锁分类对比表

分类维度	锁类型	锁定范围	兼容性（自身/其他事务）	引擎支持	适用场景	并发性能
按锁定粒度	全局锁	整个MySQL实例（所有数据库）	自身兼容、其他事务所有操作阻塞	所有引擎	全库备份（FLUSH TABLES WITH READ LOCK）	最低
表级锁	整张表	共享锁（S锁）相互兼容，排他锁（X锁）与所有锁互斥	InnoDB/MyISAM	MyISAM默认锁；InnoDB的DDL操作、无索引的DML操作	较低
行级锁	单条/多条记录（索引对应的行）	共享锁（S锁）相互兼容，排他锁（X锁）与所有锁互斥	仅InnoDB	InnoDB的DML操作（插入/更新/删除）	最高
按功能用途	共享锁（S锁/读锁）	对应粒度（表/行）	与S锁兼容，与X锁互斥	所有引擎	仅读取数据，不修改数据（SELECT … LOCK IN SHARE MODE）	较高
排他锁（X锁/写锁）	对应粒度（表/行）	与所有锁（S锁/X锁）互斥	所有引擎	修改数据（INSERT/UPDATE/DELETE、SELECT … FOR UPDATE）	较低
按意向类型（InnoDB）	意向共享锁（IS锁）	整张表	与IS/S锁兼容，与IX/X锁互斥	仅InnoDB	加行级S锁前自动加表级IS锁，标识“即将加行读锁”	无额外开销，辅助锁冲突检测
意向排他锁（IX锁）	整张表	仅与IS锁兼容，与其他锁互斥	仅InnoDB	加行级X锁前自动加表级IX锁，标识“即将加行写锁”	无额外开销，辅助锁冲突检测

5.2 核心锁详细说明

行级锁细分：InnoDB行级锁分为记录锁（锁定具体某一行记录）和间隙锁（锁定记录之间的间隙，防止插入新数据，解决幻读），两者结合称为Next-Key Lock（临键锁），是InnoDB默认的行锁算法。
锁冲突场景：
1. 事务A对某行加X锁，事务B对同一行加S/X锁都会阻塞，直到事务A释放锁。
2. InnoDB中，若查询未使用索引（全表扫描），行级锁会退化为表级锁，导致并发性能急剧下降。
MyISAM锁机制：仅支持表级锁，写入操作加X锁，查询操作加S锁，因此写入操作会阻塞全表查询，查询操作也会阻塞写入操作，并发性能差。

二、慢SQL问题排查与全流程优化

慢SQL是MySQL性能瓶颈的最常见原因（执行时间超过long_query_time默认1秒），需遵循“排查-分析-优化-验证”的全流程解决。

1. 慢SQL排查流程（步骤化+工具化）

排查步骤	核心操作	工具/命令	核心作用	关键说明
1. 开启慢查询日志	配置慢查询参数并生效	配置文件：my.cnf 参数： 1. slow_query_log=ON 2. long_query_time=1（可调整为0.5） 3. log_queries_not_using_indexes=ON 4. slow_query_log_file=/var/log/mysql/slow.log	开启慢SQL记录，捕获符合条件的SQL	生产环境建议开启，`log_queries_not_using_indexes`可捕获未使用索引的SQL（即使未超时）
2. 定位慢SQL	筛选慢查询日志中的核心SQL	1. mysqldumpslow（MySQL自带） 2. pt-query-digest（Percona工具，推荐） 3. show processlist（实时查看运行中的SQL）	按执行次数、耗时排序，定位高频慢SQL/超慢SQL	`mysqldumpslow -s t -t 10 slow.log`：按耗时排序取前10条慢SQL
3. 分析执行计划	解读SQL的执行细节，定位瓶颈	EXPLAIN + 慢SQL（如EXPLAIN SELECT * FROM user WHERE id=1）	查看索引使用、表扫描方式、行数预估等	重点关注`type`、`key`、`rows`、`Extra`四个字段
4. 定位性能瓶颈	结合执行计划和业务场景分析	手动分析+Performance Schema（MySQL性能监控）	确定瓶颈类型（索引失效、全表扫描、关联查询不合理等）	常见瓶颈：全表扫描（type=ALL）、索引失效（key=NULL）、回表过多（Extra=Using filesort）

关键工具说明

EXPLAIN字段解读表：

字段名	核心含义	优化目标
id	查询执行顺序（数字越大越先执行，相同数字并行执行）	无（仅用于理解执行顺序）
select_type	查询类型（SIMPLE/PRIMARY/SUBQUERY/DERIVED等）	尽量避免子查询（SUBQUERY），优先用联表查询
table	涉及的表名	无（仅用于定位表）
type	访问类型（查询效率从高到低：system > const > eq_ref > ref > range > index > ALL）	至少优化到`range`，最好达到`ref`/`eq_ref`，避免`ALL`（全表扫描）
possible_keys	可能使用的索引	非空（若为空，说明无可用索引）
key	实际使用的索引	与`possible_keys`一致（若为NULL，索引失效）
key_len	索引使用的长度	越长越好（说明索引字段利用充分）
rows	预估扫描的行数	越少越好（接近实际返回行数）
Extra	额外信息	避免`Using filesort`（文件排序）、`Using temporary`（临时表）、`Using join buffer`（联表缓冲）

2. 慢SQL全流程优化（多维度落地）

优化维度	核心优化方法	具体操作示例	优化效果
SQL语句优化	1. 避免SELECT *，只查需要的字段 2. 优化关联查询（用JOIN替代子查询，小表驱动大表） 3. 避免索引列上的函数操作/类型转换 4. 优化IN子句（大数据量用JOIN替代） 5. 避免ORDER BY/RAND()（随机排序开销大）	优化前：SELECT * FROM user WHERE DATE(create_time)=‘2026-01-01’ 优化后：SELECT id,name FROM user WHERE create_time BETWEEN ‘2026-01-01 00:00:00’ AND ‘2026-01-01 23:59:59’	减少数据传输量、避免索引失效、降低排序/关联开销
索引优化	1. 创建合适的复合索引（遵循最左前缀原则） 2. 使用前缀索引优化长字符串 3. 删除冗余索引和无用索引 4. 避免过度索引（索引过多影响插入/更新） 5. 主键选择自增ID（减少B+树分裂）	场景：查询WHERE name=‘张三’ AND age=20 优化：创建复合索引`idx_name_age(name,age)`，而非两个单字段索引	提升查询效率、减少索引维护开销、避免索引失效
表结构优化	1. 选择合适的数据类型（如用INT替代VARCHAR，用DATETIME替代TIMESTAMP） 2. 垂直拆分（大表拆分为小表，如用户表拆分为基础信息表和详情表） 3. 水平拆分（分库分表，如按用户ID哈希分表） 4. 添加适当的缓存（如Redis缓存高频查询数据）	优化前：用户表包含ID、name、age、address、avatar、signature等20+字段优化后：拆分为user_base（ID、name、age）和user_detail（ID、address、avatar、signature）	减少表宽度、提升查询效率、适配大数据量存储
MySQL配置优化	1. 调整缓冲池（innodb_buffer_pool_size=物理内存的50%-70%） 2. 调整连接数（max_connections=1000，根据业务调整） 3. 调整日志配置（innodb_log_file_size=1G，binlog_format=ROW） 4. 关闭不必要的功能（如general log）	配置文件my.cnf： innodb_buffer_pool_size=8G max_connections=1000 innodb_log_file_size=1G	提升内存缓存效率、避免连接数不足、优化日志写入性能
架构优化	1. 主从分离（主库写入，从库查询，分流读压力） 2. 读写分离（通过中间件如MyCat实现） 3. 引入缓存（Redis/Memcached缓存高频热点数据） 4. 数据分区（按时间/地域分区，如订单表按月份分区）	场景：电商平台高频查询商品信息优化：将商品信息缓存到Redis，过期时间30分钟，更新时同步缓存	分流数据库压力、提升查询响应速度、适配高并发场景

三、NoSQL数据库核心解析（使用场景+与MySQL对比）

NoSQL（Not Only SQL）是对关系型数据库的补充，不遵循ACID特性（部分支持），采用非关系型数据模型，适配大数据量、高并发、非结构化数据的场景。

1. MySQL与NoSQL核心对比表

对比维度	MySQL（关系型数据库）	NoSQL（非关系型数据库）
数据模型	结构化数据（二维表+行+列，遵循Schema约束）	非结构化/半结构化数据（键值、文档、列族、图形），无严格Schema约束
事务支持	完整ACID特性，支持复杂事务	大部分不支持ACID（仅部分如MongoDB 4.0+支持单文档事务），支持最终一致性
索引机制	成熟的B+树索引、复合索引等，支持复杂查询	索引支持相对简单（如键值型仅支持主键索引，文档型支持简单索引）
关联查询	支持复杂联表查询（JOIN）	基本不支持关联查询（需业务层实现）
可扩展性	垂直扩展易（升级硬件），水平扩展难（分库分表复杂）	垂直扩展难，水平扩展易（分布式架构天然支持）
适用数据量	中小数据量（单库千万级以内）	海量数据量（亿级/十亿级）
并发性能	中等（行级锁提升并发，受限于事务和索引）	极高（无事务开销，分布式架构分流压力）
数据一致性	强一致性	最终一致性（大部分），部分支持强一致性

2. NoSQL主流类型及使用场景表

NoSQL类型	代表产品	核心特点	典型使用场景	不适用场景
键值型（Key-Value）	Redis、Memcached、LevelDB	以键值对存储，查询极速，支持简单操作	缓存（热点数据）、会话存储、计数器、分布式锁、消息队列	复杂查询、需要关联数据的场景
文档型（Document）	MongoDB、CouchDB	以JSON/BSON文档存储，支持灵活的数据模型	内容管理（博客、文章）、用户画像、电商商品信息、日志存储	强事务要求、复杂联表查询的场景
列族型（Column-Family）	HBase、Cassandra	按列族存储，适合海量结构化数据，分布式架构	大数据存储（用户行为日志）、时序数据（监控数据）、数据仓库	小数据量、低并发、需要复杂查询的场景
图形型（Graph）	Neo4j、ArangoDB	以节点和关系存储，擅长处理关联关系复杂的数据	社交网络（好友关系）、知识图谱、路线规划（地图导航）	海量简单数据存储、高并发读写的场景

3. NoSQL核心使用场景总结

高并发读写场景：如电商秒杀、微博热点话题，使用Redis（键值型）分流数据库压力，支撑每秒数十万次读写。
海量数据存储场景：如用户行为日志、监控数据，使用HBase（列族型）存储亿级数据，支持高效批量写入和查询。
非结构化/半结构化数据存储场景：如用户画像、商品描述，使用MongoDB（文档型），无需严格Schema，适配灵活的数据结构。
复杂关联关系场景：如社交网络好友关系、知识图谱，使用Neo4j（图形型），高效处理节点间的复杂关联查询。
缓存场景：如高频查询的商品信息、用户信息，使用Redis/Memcached，提升查询响应速度，降低数据库压力。

4. NoSQL不适用场景

需要强事务一致性的场景（如金融支付、订单交易），优先选择MySQL。
需要复杂联表查询的场景（如多表关联统计），优先选择MySQL。
小数据量、低并发的简单业务场景，MySQL足够满足需求，无需引入NoSQL增加架构复杂度。

四、总结与实践建议

MySQL核心选型建议：
- 存储引擎优先选择InnoDB，放弃MyISAM；临时数据存储可使用Memory引擎，归档数据可使用Archive引擎。
- 事务隔离级别默认使用可重复读（InnoDB），无需调整；核心业务（如金融）可考虑串行化（牺牲并发换一致性）。
- 索引设计遵循“按需创建、最左前缀、避免冗余”，优先使用复合索引替代多个单字段索引，主键选择自增ID。
- 锁机制需避免“行锁退化为表锁”（确保查询使用索引），高并发场景尽量减少长事务。
慢SQL优化核心思路：
- 先通过慢查询日志+EXPLAIN定位瓶颈，再从“SQL语句→索引→表结构→配置→架构”逐步优化，由浅入深。
- 避免索引失效的核心：不做索引列的函数操作、类型转换，遵循复合索引最左前缀原则。
MySQL与NoSQL协同使用：
- NoSQL是MySQL的补充，而非替代；核心业务（强事务、复杂查询）用MySQL，非核心业务（高并发、海量数据、非结构化数据）用NoSQL。
- 典型架构：MySQL（存储核心业务数据）+ Redis（缓存热点数据）+ MongoDB（存储非结构化数据）+ HBase（存储海量日志数据）。

MySQL核心应用全解析：存储引擎/日志/事务/索引/锁 + 慢SQL优化 + NoSQL场景