MySQL 服务器已经消失 - 尝试了一切答案

【问题标题】：MySQL Server Has Gone Away - Tried EverythingMySQL 服务器已经消失 - 尝试了一切
【发布时间】：2016-11-29 01:37:28
【问题描述】：

我正在执行下面的查询，几秒钟后我收到“MySQL serer has gone away”错误。我试图增加 wait_timeout、max_allowed_packet 和人们建议的其他一些变量，但我无法修复它。

SELECT tmp.filter_group_id,
       tmp.filter_id,
       tmp.product_id
FROM
  (SELECT *
   FROM
 (SELECT f.filter_group_id,
     pf.filter_id,
     p.product_id,
     (IFNULL(
       (SELECT price
        FROM oc_product_special AS ps
        WHERE ps.product_id = p.product_id
          AND ps.customer_group_id = '1'
          AND ((ps.date_start = '0000-00-00'
                OR ps.date_start < NOW())
               AND (ps.date_end = '0000-00-00'
                    OR ps.date_end > NOW()))
        ORDER BY ps.priority ASC, ps.price ASC LIMIT 1), 
        IFNULL(
          (SELECT price
           FROM oc_product_discount AS pd2
           WHERE pd2.product_id = p.product_id
             AND pd2.customer_group_id = '1'
             AND pd2.quantity >= '1'
             AND ((pd2.date_start = '0000-00-00'
                   OR pd2.date_start < NOW())
                  AND (pd2.date_end = '0000-00-00'
                       OR pd2.date_end > NOW()))
               ORDER BY pd2.priority ASC, pd2.price ASC LIMIT 1), p.price)) * 1) AS mf_price
      FROM oc_product AS p
      INNER JOIN oc_product_filter AS pf ON pf.product_id = p.product_id
      INNER JOIN oc_filter AS f ON f.filter_id = pf.filter_id
      INNER JOIN oc_product_to_store AS p2s ON p2s.product_id = p.product_id
      AND p2s.store_id = 0
      INNER JOIN oc_product_to_category AS p2c ON p2c.product_id = p.product_id
      INNER JOIN oc_category_path AS cp ON cp.category_id = p2c.category_id
      WHERE p.date_available <= NOW()
        AND p.status = '1'
        AND (FIND_IN_SET(18, p.mfilter_values))
        AND cp.path_id IN(6) ) AS tmp
   WHERE (mf_price > 40
          AND mf_price < 701) ) AS tmp
WHERE tmp.filter_group_id NOT IN(1);

^ 这是导致我从日志文件中得到的问题的查询。

如果我将“SELECT tmp.filter_group_id, tmp.filter_id, tmp.product_id”部分更改为“SELECT tmp.*”，则查询可以正常工作并在 0.2 秒内返回结果。不幸的是，更改它并不能解决我的问题，因为还有另一个查询，例如：

SELECT mfp.filter_group_id,
           mfp.filter_id,
           COUNT(DISTINCT mfp.product_id) FROM ([THE QUERY ABOVE]) as mfp
GROUP BY mfp.filter_group_id,
           mfp.filter_id;

所以我必须让第一个查询工作。有什么建议吗？

编辑：

这里是mysql.log

18:43:06 UTC - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=2147483648
read_buffer_size=16777216
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2852645 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x1c6215421c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
7ff64e61d542    mysqld.exe!Item_subselect::exec()[item_subselect.cc:575]
7ff64e6231b2    mysqld.exe!Item_singlerow_subselect::val_decimal()[item_subselect.cc:1259]
7ff64e490f53    mysqld.exe!Item_func_ifnull::decimal_op()[item_cmpfunc.cc:3382]
7ff64e51bf4b    mysqld.exe!Item_func_numhybrid::val_decimal()[item_func.cc:1453]
7ff64e511586    mysqld.exe!Item_func_mul::decimal_op()[item_func.cc:2067]
7ff64e51bf4b    mysqld.exe!Item_func_numhybrid::val_decimal()[item_func.cc:1453]
7ff64e4e46ac    mysqld.exe!Item_direct_ref::val_decimal()[item.cc:8598]
7ff64e48ef18    mysqld.exe!Arg_comparator::compare_decimal()[item_cmpfunc.cc:1763]
7ff64e49d4b1    mysqld.exe!Item_func_gt::val_int()[item_cmpfunc.cc:2608]
7ff64e4e3a41    mysqld.exe!Item::val_bool()[item.cc:211]
7ff64e49cb9c    mysqld.exe!Item_cond_and::val_int()[item_cmpfunc.cc:6102]
7ff64ea3682e    mysqld.exe!evaluate_join_record()[sql_executor.cc:1483]
7ff64ea3a437    mysqld.exe!sub_select()[sql_executor.cc:1288]
7ff64ea369b5    mysqld.exe!evaluate_join_record()[sql_executor.cc:1634]
7ff64ea3a437    mysqld.exe!sub_select()[sql_executor.cc:1288]
7ff64ea356c1    mysqld.exe!do_select()[sql_executor.cc:941]
7ff64ea3703b    mysqld.exe!JOIN::exec()[sql_executor.cc:199]
7ff64e608571    mysqld.exe!handle_query()[sql_select.cc:185]
7ff64e4c27f6    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:4947]
7ff64e4c46de    mysqld.exe!mysql_execute_command()[sql_parse.cc:2597]
7ff64e4c7faa    mysqld.exe!mysql_parse()[sql_parse.cc:5363]
7ff64e4c12c9    mysqld.exe!dispatch_command()[sql_parse.cc:1287]
7ff64e4c226a    mysqld.exe!do_command()[sql_parse.cc:854]
7ff64e469634    mysqld.exe!handle_connection()[connection_handler_per_thread.cc:295]
7ff64ee7ad82    mysqld.exe!pfs_spawn_thread()[pfs.cc:2195]
7ff64eba46fb    mysqld.exe!win_thread_start()[my_thread.c:38]
7ff64ef3b39f    mysqld.exe!_callthreadstartex()[threadex.c:376]
7ff64ef3b5ea    mysqld.exe!_threadstartex()[threadex.c:354]
7ff887d48364    KERNEL32.DLL!BaseThreadInitThunk()
7ff888b65e91    ntdll.dll!RtlUserThreadStart()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (1c6215902a0): (18:43:06 UTC - mysqld got exception 0xc0000005 ;
This could be because you hit a bug. It is also possible that this binary
or one of the libraries it was linked against is corrupt, improperly built,
or misconfigured. This error can also be caused by malfunctioning hardware.
Attempting to collect some information that could help diagnose the problem.
As this is a crash and something is definitely wrong, the information
collection process might fail.

key_buffer_size=2147483648
read_buffer_size=16777216
max_used_connections=1
max_threads=151
thread_count=1
connection_count=1
It is possible that mysqld could use up to 
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 2852645 K  bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x1c6215421c0
Attempting backtrace. You can use the following information to find out
where mysqld died. If you see no messages after this, something went
terribly wrong...
7ff64e61d542    mysqld.exe!Item_subselect::exec()[item_subselect.cc:575]
7ff64e6231b2    mysqld.exe!Item_singlerow_subselect::val_decimal()[item_subselect.cc:1259]
7ff64e490f53    mysqld.exe!Item_func_ifnull::decimal_op()[item_cmpfunc.cc:3382]
7ff64e51bf4b    mysqld.exe!Item_func_numhybrid::val_decimal()[item_func.cc:1453]
7ff64e511586    mysqld.exe!Item_func_mul::decimal_op()[item_func.cc:2067]
7ff64e51bf4b    mysqld.exe!Item_func_numhybrid::val_decimal()[item_func.cc:1453]
7ff64e4e46ac    mysqld.exe!Item_direct_ref::val_decimal()[item.cc:8598]
7ff64e48ef18    mysqld.exe!Arg_comparator::compare_decimal()[item_cmpfunc.cc:1763]
7ff64e49d4b1    mysqld.exe!Item_func_gt::val_int()[item_cmpfunc.cc:2608]
7ff64e4e3a41    mysqld.exe!Item::val_bool()[item.cc:211]
7ff64e49cb9c    mysqld.exe!Item_cond_and::val_int()[item_cmpfunc.cc:6102]
7ff64ea3682e    mysqld.exe!evaluate_join_record()[sql_executor.cc:1483]
7ff64ea3a437    mysqld.exe!sub_select()[sql_executor.cc:1288]
7ff64ea369b5    mysqld.exe!evaluate_join_record()[sql_executor.cc:1634]
7ff64ea3a437    mysqld.exe!sub_select()[sql_executor.cc:1288]
7ff64ea356c1    mysqld.exe!do_select()[sql_executor.cc:941]
7ff64ea3703b    mysqld.exe!JOIN::exec()[sql_executor.cc:199]
7ff64e608571    mysqld.exe!handle_query()[sql_select.cc:185]
7ff64e4c27f6    mysqld.exe!execute_sqlcom_select()[sql_parse.cc:4947]
7ff64e4c46de    mysqld.exe!mysql_execute_command()[sql_parse.cc:2597]
7ff64e4c7faa    mysqld.exe!mysql_parse()[sql_parse.cc:5363]
7ff64e4c12c9    mysqld.exe!dispatch_command()[sql_parse.cc:1287]
7ff64e4c226a    mysqld.exe!do_command()[sql_parse.cc:854]
7ff64e469634    mysqld.exe!handle_connection()[connection_handler_per_thread.cc:295]
7ff64ee7ad82    mysqld.exe!pfs_spawn_thread()[pfs.cc:2195]
7ff64eba46fb    mysqld.exe!win_thread_start()[my_thread.c:38]
7ff64ef3b39f    mysqld.exe!_callthreadstartex()[threadex.c:376]
7ff64ef3b5ea    mysqld.exe!_threadstartex()[threadex.c:354]
7ff887d48364    KERNEL32.DLL!BaseThreadInitThunk()
7ff888b65e91    ntdll.dll!RtlUserThreadStart()

Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (1c6215902a0): SELECT tmp.filter_group_id, ... the query above)
Connection ID (thread ID): 10
Status: NOT_KILLED

编辑 2：顺便说一句，这是 MySQL 5.7.9 服务器，它在我使用 WAMP 的 Windows 机器上运行。

我在共享主机的 2 台服务器上拥有相同的数据库（至少多 5 倍的行）：

MySQL 5.6.23
Percona 5.6.28-76.1

两者都几乎立即运行查询。

【问题讨论】：

你检查错误日志文件了吗？
这可能是 MySQL Server 版本 5.7.9 吗？
@Michael-sqlbot 是的，它是 5.7.9
@Michael-sqlbot 我已经升级到5.7.14，问题已经解决了！ 5.7.9 中是否存在与此相关的错误？
是的，我怀疑它可能是Bug #79787，崩溃和堆栈跟踪以 item_subselect.cc 结尾，就像你的一样。据说它在 5.7.10 中工作，尽管目前对 bug 跟踪器的官方后续行动非常软弱，并且没有提供关于他们究竟修复了什么的解释（它显然在提交此特定报告之前已修复）因此，如果可以确定，我想在此处的答案中提供更好的解释。在崩溃之前，您是否有任何其他记录的警告或错误？

标签： mysql

【解决方案1】：

此问题的症状似乎与Bug #79787 相同。尽管那里没有明确记录，但这似乎已在 MySQL Server 5.7.10 中得到解决，该版本实际上是在报告错误前几天发布的。

在某些情况下，在派生表的选择列表中包含嵌套派生表和标量子查询的查询可能会导致服务器退出。（缺陷号 22062023）

https://dev.mysql.com/doc/relnotes/mysql/5.7/en/news-5-7-10.html#mysqld-5-7-10-bug

“服务器退出”是“严重崩溃”的委婉说法。

这似乎是由 defect 引起的，它不正确地认为列“未使用”并将其优化掉，最终导致无效的内存访问，因为实际上该列已在外部查询中使用。

升级到 5.7.10 或更高版本可解决该问题，该问题可能已在 5.7 开发早期引入，因此在 5.7.0 之前可能根本不存在。

【讨论】：

【解决方案2】：

将此“复合”索引添加到 ps 和 pd2：

INDEX(customer_group_id, priority, price)

如果仍然失败，请在http://bugs.mysql.com 写一个错误报告； MySQL 永远不会崩溃。

【讨论】：

试过了。仍然崩溃。