MySQL core dump不存SQL文本，需通过gdb分析栈帧定位THD指针并读取query_string字段；若为空则结合error log的backtrace和Thread pointer等线索推断。
core文件里根本找不到SQL，别白费劲翻字符串
MySQL的core dump是进程内存快照，不是日志——它不保存SQL文本的完整副本。直接用strings core.12345 | grep "SELECT"大概率捞出一堆无关碎片，甚至误判。真正能关联到SQL的，只有正在执行该SQL的线程栈中、调用链末端函数的参数或局部变量（极少数情况）。更现实的做法是：先确认core是否有效，再聚焦栈顶函数是否属于SQL执行路径。
用gdb看#0函数名，快速判断是否与SQL相关
启动gdb /path/to/mysqld core.12345后，执行bt看栈回溯，重点盯#0那一行：
- 如果
#0是pthread_cond_wait、poll、epoll_wait等阻塞调用：说明进程卡在等待，不是崩溃点，继续往上找第一个非系统调用的MySQL函数 - 如果
#0是ha_innobase::index_read、JOIN::exec、subselect_single_select_engine::exec这类存储引擎或执行器函数：大概率就是SQL执行途中崩了，值得深挖 - 如果
#0是my_malloc、String::append、Item_func::val_str等内存/字符串操作：可能由某条SQL触发了非法内存访问，需结合上下文参数判断
注意：#0显示??或地址而非函数名，说明缺少debuginfo符号，得先装对应版本的mysql-debuginfo包。
从栈帧里提取THD指针，再查SQL_TEXT字段
一旦确认栈属于SQL执行路径，就尝试从某个栈帧中提取THD*（线程句柄）指针，这是定位SQL的唯一可靠入口：
- 在gdb中执行
frame 2（或任意含THD*参数的帧），再用print *(THD*)$rdi（x86_64下常存于$rdi）或print *(THD*)$rsi打印结构体 - 若成功，检查
thd->query_string.str或thd->m_query_string.str（不同版本字段名略有差异），用print (char*)thd->query_string.str输出SQL原文 - 如果
str为空或乱码，说明SQL已释放（如语句执行完但崩溃发生在清理阶段），此时只能靠栈中函数名+参数推断类型，例如dict_table_get_first_index调用失败，往往指向某张表的DDL或索引操作
别漏掉error log里的backtrace线索
core dump和error log必须对照着看。MySQL崩溃时，error log里紧挨着Attempting backtrace的几行，已经给出了关键栈帧（比如/mysqld(handle_fatal_signal+0x37b)），这比gdb里看到的原始地址更易定位到源码位置。更重要的是，log里还包含：
-
Thread pointer: 0x7f914ec27000—— 这个地址可直接在gdb里用print *(THD*)0x7f914ec27000尝试解析 -
Query ID: 123456789（若开启performance_schema且配置了events_statements_history_long）—— 可反查该ID对应的SQL - 崩溃前最后几条
ERROR或Warning，比如InnoDB: page corruption on space=73，说明问题不在SQL本身，而在底层页损坏，此时查SQL意义不大
真正难啃的case，往往是栈里看不出SQL，error log也没明确线索——那基本可以确定：崩溃由内存越界、野指针或硬件故障引发，SQL只是“恰好在线程里执行”，并非根本原因。
