技术博客
MySQL 的 B+ 树索引是严格按定义顺序逐列比较的，一旦 WHERE 条件跳过最左列（即“断层”），后续所有列都无法参与索引查找。比如建了 INDEX idx_user (city, age, status)，但查询写成 WHERE age = 25 AND status = ‘active’，EXPLAIN 中 key 字段会显示 NULL，type 是 ALL，rows 接近全表行数——本质就是退化为全表扫描。
MySQL 的 UPDATE 如果 WHERE 条件列没有索引，会触发全表扫描，尤其在大表上，不仅慢，还会锁住大量行（甚至整表），阻塞其他写操作。常见现象是 SHOW PROCESSLIST 里看到状态为 Updating 且 Time 持续增长。
MySQL 的执行计划（EXPLAIN 输出结果）不是在客户端拼接 SQL 时生成，也不是在存储引擎读数据时才决定，而是在 Server 层的查询优化器（Query Optimizer）完成逻辑解析和语义检查之后、实际执行之前生成的。具体来说，它发生在：parser → resolver → optimizer → executor 这一链条中的 optimizer 阶段。
MySQL优化器不负责执行SQL，也不直接提升速度；它的唯一任务是：在所有可能的执行路径中，选一个预估成本最低的方案。这个“成本”不是时间，而是MySQL内部估算的I/O次数、CPU开销等加权值。你看到的EXPLAIN输出，就是它拍板后的结果——不是建议，是已决定的路线图。
SQL统计实时指标的核心是平衡延迟、准确性与资源开销，优先采用物化视图、滚动聚合、流批一体及缓存兜底策略，实现 […]
SQL查询变慢主因是写法、表结构与执行路径不合理；索引需匹配WHERE等实际使用条件，复合索引字段顺序要与查询 […]