MySQL执行SELECT本质是Server层与InnoDB协同的“指令翻译+数据搬运”：连接器一次性校验权限，8.0起跳过查询缓存，分析器拆解SQL，优化器基于成本选执行计划，执行器调用InnoDB通过Buffer Pool和B+树读取数据。
MySQL InnoDB 执行一条 SELECT 查询，本质是 Server 层与存储引擎层协同完成的一次“指令翻译 + 数据搬运”过程，不是简单走个 B+ 树就完事——中间每一步都可能成为性能瓶颈点。
连接器先校验权限，后续不再重复检查
客户端发来查询请求后，连接器 首先验证用户名密码，并一次性确认该用户对目标表/列是否有查询权限。这个权限判断只发生在连接建立时，哪怕你在事务中反复执行同一条 SELECT，也不会再查权限表。但要注意：FLUSH PRIVILEGES 或动态修改权限后，已存在的连接不会自动同步新权限，必须重连才生效。
MySQL 8.0 已彻底移除查询缓存，别再配 query_cache_type
如果你在 MySQL 8.0+ 环境里还看到 query_cache_size 或 query_cache_type 配置项，它们已被忽略，且启动时会报警告。早期版本中缓存依赖 SQL 文本全匹配，只要 users 表有任意 INSERT/UPDATE/DELETE，所有命中该表的缓存都会失效——高并发下几乎无用，反而增加锁开销。现在所有查询一律跳过这步，直接进解析器。
分析器拆解 SQL，优化器决定怎么查（不是“能不能查”）
分析器做词法和语法分析，把 SELECT * FROM users WHERE id = 10 拆成关键词、表名、条件等结构；接着预处理器检查表和列是否存在、别名是否冲突；最后交给优化器生成执行计划。关键点在于：优化器 不负责权限或语义合法性（那是分析器的事），它只基于统计信息估算成本，决定是否走索引、用哪个索引、关联顺序怎么排。比如 EXPLAIN 显示 type: ALL，说明优化器认为全表扫描比走索引更便宜——往往意味着缺少合适索引，或 WHERE 条件没命中索引最左前缀。
InnoDB 真正读数据时，B+ 树只是导航工具，Buffer Pool 才是关键
执行器调用 InnoDB 接口后，实际数据读取分三步：
– 先查 Buffer Pool 是否已有对应数据页（内存命中）；
– 若无，则从磁盘 .ibd 文件加载整个页（16KB）进来；
– 再在页内用二分查找定位具体记录（叶子节点内）。
注意：即使 id 是主键，InnoDB 也必须从根节点开始逐层导航 B+ 树，不能“直接跳转”。而如果查询涉及二级索引（如 INDEX(city)），还会触发“回表”——先查二级索引页拿到主键值，再用主键去聚簇索引里二次查找，这多一次 B+ 树搜索和 Buffer Pool 查找。
真正容易被忽略的是：B+ 树高度通常只有 3～4 层，但 Buffer Pool 命中率低、磁盘随机 IO 慢、锁等待、大结果集排序/分页这些环节，往往比树导航本身耗时得多。
