phpMyAdmin 不支持直接显示 SQL 执行内存消耗，因其仅为前端界面且 MySQL 服务端不暴露实时内存分配数据；仅能通过 MySQL profiling（需 ≥5.7 版本、PROCESS 权限、特定操作）间接推断，或借助 performance_schema 查看线程/全局内存事件汇总。
phpMyAdmin 本身不支持直接显示 SQL 执行内存消耗
phpmyadmin 是一个 web 前端界面，它不采集、不展示单条查询的内存使用量。mysql 服务端也**不对外暴露实时内存分配字节数**（如 malloc 多少 kb），更不会把这类指标透传给 phpmyadmin。所谓“显示内存消耗”，实际只能通过 mysql 内置的 profiling 功能间接推断——但前提是版本、权限、操作类型都满足苛刻条件。
SHOW PROFILE MEMORY 只在特定条件下有效
执行 SHOW PROFILE MEMORY FOR QUERY N 确实能输出内存相关字段，但以下任一不满足，结果就是空或报错：
- MySQL 版本必须 ≥ 5.7（5.6 及更早会报错或静默忽略
MEMORY参数） - 当前用户需有
PROCESS权限，否则返回Access denied; you need (at least one of) the PROCESS privilege(s) - 仅部分内部操作会上报内存：比如
Sorting result、Creating sort index、Hash join；简单SELECT * FROM small_table很可能全程无 MEMORY 记录 - phpMyAdmin 每次请求是独立会话，
SET profiling = 1后必须紧跟着查、再立刻执行SHOW PROFILES和SHOW PROFILE MEMORY FOR QUERY N，跨页面或刷新就失效
替代方案：用 performance_schema 查全局/线程级内存统计
如果目标是监控“哪些查询吃内存”，比单次 profiling 更可靠的是查 performance_schema 的聚合视图：
-
SELECT * FROM performance_schema.memory_summary_by_thread_by_event_name ORDER BY SUM_NUMBER_OF_BYTES_ALLOC DESC LIMIT 10—— 看各线程最近内存分配峰值 -
SELECT * FROM performance_schema.memory_summary_global_by_event_name WHERE EVENT_NAME LIKE 'memory%'—— 全局内存事件汇总，含sql/JOIN_CACHE、innodb/buf_buf_pool等关键项 - 注意：需确认
performance_schema已启用（SELECT @@performance_schema返回 1），且相关 consumers 已打开（如setup_consumers中的memory_events）
这些数据不是单条 SQL 的快照，而是按事件类型累计的内存申请/释放行为，更适合定位长期内存压力来源。
真正影响内存的配置项，得看 MySQL 服务端
用户常误以为“SQL 执行内存”是某条语句独占的，其实它由多个服务端参数共同约束：
立即学习“PHP免费学习笔记（深入）”；
-
tmp_table_size和max_heap_table_size：决定内存临时表上限，超了就落盘，触发Copying to tmp table阶段耗时飙升 -
sort_buffer_size：每个排序操作独享，非全局总和；并发高时容易被误判为“内存爆炸” -
innodb_buffer_pool_size：InnoDB 缓冲池大小，占 MySQL 总内存大头，但它属于预分配静态内存，不随单条 SQL 波动 - PHP 层的
memory_limit和 MySQL 层的max_allowed_packet是两个独立限制，别混为一谈
想让某条慢查询“少占内存”，优先优化语句本身（加索引、避免 SELECT *、拆分 GROUP BY）——而不是指望 phpMyAdmin 显示一个数字来告诉你它用了多少 MB。
