MySQL复杂查询CPU飙升主因是优化器在解析与计划生成阶段高开销计算，如嵌套子查询、多层JOIN、函数导致的代价估算震荡；EXPLAIN FORMAT=TREE显示cost异常高（如超百万）即表明优化器卡在计划生成而非执行。
MySQL 复杂查询导致 CPU 飙升，核心原因不是“查询本身复杂”，而是解析、优化、执行三个阶段中，parser 和 optimizer 在语法检查与计划生成环节反复做高开销计算，尤其当 SQL 包含嵌套子查询、多层 JOIN、非确定性函数（如 NOW()、RAND()）、或隐式类型转换时，优化器会陷入代价估算震荡，反复尝试不同执行路径——这部分纯 CPU 计算不读磁盘，却吃满单核。
EXPLAIN FORMAT=TREE 显示“cost”异常高？说明优化器卡在计划生成阶段
MySQL 8.0+ 的 EXPLAIN FORMAT=TREE 会显示预估 cost，若看到某节点 cost 达到百万级甚至更高（比如 cost: 1248932.50），基本可断定优化器正在暴力枚举连接顺序或索引组合。这不是执行慢，是“还没开始执行就卡住了”。
- 典型触发场景：
SELECT * FROM a JOIN b ON ... JOIN c ON ... JOIN d ON ...（4 张表以上无主键/外键约束） - 避免方式：用
STRAIGHT_JOIN强制连接顺序，跳过优化器穷举；或拆成两段查询，中间结果存入临时表 - 验证方法：对比
EXPLAIN FORMAT=TRADITIONAL和FORMAT=TREE的输出耗时，前者秒出、后者卡顿数秒 → 问题在 optimizer，不在 storage engine
WHERE 中出现函数或表达式，强制全表扫描且关闭索引下推
像 WHERE DATE(created_at) = '2026-04-15' 或 WHERE price * 1.1 > 100 这类写法，会让 MySQL 放弃使用 created_at 或 price 上的索引，转为逐行计算函数值。更糟的是，InnoDB 的索引下推（ICP）机制在这种情况下完全失效，所有行都得从引擎层拉到 server 层再过滤。
解析 MySQL 8.0 的 DDL 脚本，并将表结构导出为 Excel 格式。适用于用户需将 MySQL 的 `CREATE TABLE` 语句转换为结构化的 Excel 文件场景，导出内容包含字段名、数据类型、长度及精度等信息。支持多张表的批量处理，每张表对应 Excel 中的一个独立工作表。适用于数据库文档编写、数据字典生成及模式分析等任务。
- 真实影响：100 万行表，CPU 在 server 层做 100 万次
DATE()调用，而不是在引擎层用索引快速定位日期范围 - 修复方式：
WHERE created_at >= '2026-04-15' AND created_at ；对计算字段建生成列 + 索引：ALTER TABLE t ADD COLUMN price_taxed DECIMAL(10,2) STORED AS (price * 1.1), ADD INDEX idx_price_taxed (price_taxed) - 注意：即使有索引，
WHERE UPPER(name) = 'ABC'同样失效，应统一存储小写并用name = 'abc'
临时表在内存中撑爆 CPU，而非磁盘 IO 成瓶颈
当排序（ORDER BY）、分组（GROUP BY）、去重（DISTINCT）的数据量超过 tmp_table_size 和 max_heap_table_size 中的较小值时，MySQL 会把内存临时表转为磁盘 MyISAM 表——但很多人忽略了：**磁盘表创建前，MySQL 仍要在内存里完成全部数据的排序和哈希计算**。这部分 CPU 消耗极高，且无法被 iostat 观察到。
- 查证方式：
SHOW GLOBAL STATUS LIKE 'Created_tmp%';，若Created_tmp_disk_tables增长快，同时Created_tmp_tables也高，说明排序/分组逻辑本身就在压 CPU - 调优动作：增大
tmp_table_size（需同步设max_heap_table_size到相同值），但别盲目调到 1G+，可能引发 OOM；更治本的是加覆盖索引，让ORDER BY直接走索引有序性 - 危险信号：
SELECT ... GROUP BY x ORDER BY y中x和y不在同一个索引里 → 必然触发临时表 + 文件排序
真正难处理的不是慢查询，而是那些 EXPLAIN 看似走了索引、执行时间却忽高忽低、perf top 显示大量 my_hash_sort 或 Item_func::val_str 占比的查询——它们暴露的是优化器与 server 层计算模型的耦合深度，改 SQL 比调参数管用十倍。
