cbo成本模型是mysql基于统计信息与可配置常量（如io_block_read_cost=1.0）量化评估各执行路径总成本（io+cpu）并选择最低成本方案的优化机制，其核心是成本最小化而非强制用索引。
MySQL优化器的CBO不是“该不该用索引”的裁判，而是个精打细算的账房先生：它只选总成本最低的执行路径，哪怕那条路是全表扫描。
什么是CBO成本模型
CBO（Cost-Based Optimizer）是MySQL 5.7+默认启用的优化策略，它不依赖固定规则，而是对每个候选执行计划做量化成本估算，再择优选用。这个“成本”不是毫秒数，也不是IO次数，而是一套抽象单位——以io_block_read_cost为基准（默认值1.0），其他操作按相对开销折算。
整个模型分两层成本：
- Server 层成本：比如
row_evaluate_cost（每行WHERE判断开销，默认0.1）、key_compare_cost（每次索引键比较开销，默认0.05） - Engine 层成本：比如
io_block_read_cost（磁盘页读取，默认1.0）、memory_block_read_cost（Buffer Pool页读取，默认0.25）
这些常量都存于系统库mysql.server_cost和mysql.engine_cost中，可查可调，但不建议随意改——它们是基于机械硬盘时代校准的通用经验值。
代价怎么算：一个简化公式
总成本 ≈ IO成本 + CPU成本
其中：
- IO成本 = 读取页数 × 对应的块读成本（磁盘 or 内存）
- CPU成本 = 预估访问行数 ×
row_evaluate_cost+ 预估索引比较次数 ×key_compare_cost
例如一条SELECT * FROM t WHERE a = 1，假设：
- 全表扫描需读1000页（磁盘），成本 = 1000 × 1.0 = 1000
- 走索引
idx_a需读5页（内存）+ 比较100次键值，成本 = 5 × 0.25 + 100 × 0.05 = 1.25 + 5 = 6.25
那优化器就选索引；但如果统计信息显示匹配行数高达80%，索引回表开销剧增，可能全表反而更便宜。
哪些因素会显著抬高成本导致索引被弃用
优化器放弃索引，往往不是因为“写法错”，而是成本被悄悄拉高了：
- 字段类型隐式转换，比如
WHERE phone = 13800138000（phone是VARCHAR），触发全字段函数化，索引失效且无法进入候选列表 - 统计信息过期：
ANALYZE TABLE没跑过，优化器误判匹配行数，低估全表扫描成本 - 小表或高选择性差的条件：比如
WHERE status IN (0,1)覆盖95%数据，走索引要回表95%行，IO放大严重 - 临时表落盘：当
GROUP BY或ORDER BY需要排序且超出tmp_table_size，创建磁盘临时表的成本（disk_temptable_create_cost=20.0）会直接压垮其他路径
怎么验证某条SQL实际走了什么成本路径
别猜，用EXPLAIN FORMAT=JSON看真实估算：
EXPLAIN FORMAT=JSON SELECT * FROM orders WHERE user_id = 123;
输出里重点关注：
-
query_cost：总预估成本值 -
used_columns和possible_keys：哪些列参与评估、哪些索引进了候选池 -
rows_examined_per_scan：优化器认为这条路径要检查多少行 -
index_condition_pushdown是否启用：影响row_evaluate_cost实际发生位置
如果发现query_cost远高于预期，优先检查rows_examined_per_scan是否离谱——那大概率是统计不准或条件写法触发了隐式转换。
真正难的从来不是“有没有索引”，而是让优化器相信“用这个索引确实更省”。而它的信任，只建立在准确的统计信息、干净的数据类型、以及没被意外放大的IO/CPU开销之上。
