MySQLOLTP 首选
- 安装部署简单，生态与文档极其成熟
- InnoDB 引擎稳定，主从复制方案丰富
- 互联网公司主流，运维工具链完善
- JSON、窗口函数等新特性持续补齐
适用场景：电商订单、用户系统、内容管理，读多写少的中大型业务。
90% 的慢查询都能在索引和执行计划里找到答案。看懂 B+ 树，才看懂为什么这个索引没生效。
B+ TREE
InnoDB 的数据按 B+ 树聚簇存储，二级索引存主键再回表。理解这套结构，索引设计才有依据。
只有叶子节点存数据，且叶子间用链表相连，范围查询天然高效，树高通常 3-4 层。
最左前缀、覆盖索引、联合索引顺序，把高频查询的列组合放到一棵树上。
type、key、rows、Extra 四列定生死，看一眼就知道走没走索引、扫了多少行。
二级索引拿主键再回表是性能损耗点，覆盖索引能把这步直接省掉。
关系型数据库的两条主流路线，选型前先想清楚业务要的是什么。
数据库不是只会写 SELECT 就够了，这六块是面试与实战的高频考点。
线上慢了别慌，照着这张清单逐条排查，多数问题能定位到。
杜绝 SELECT *，减少网络与内存开销，也更容易命中覆盖索引。
避免在索引列上做函数运算或隐式类型转换，否则索引直接失效。
LIMIT 1000000,10 改用游标或延迟关联，别让数据库扫一堆丢掉。
长事务持锁过久会阻塞并发，把非必要操作移出事务边界。
让行数少的表做驱动表，被驱动表的关联列务必建索引。
读多写少的高频查询前置 Redis，给数据库卸掉绝大多数读压力。
配合 EXPLAIN 定期 review，新上线的 SQL 一定要过一眼执行计划。
能用 INT 别用 VARCHAR，能用 TIMESTAMP 别用 DATETIME，存储与索引都更省。
系统教程配合面试真题，理论实战一起上。