请教大神这是数据库问题还是代码问题

走一路_拈花瓣翩翩 2018-10-07 12:27:34

代码中利用的是线程池，多线程解析xml文件，把数据保存到数据库。
--------------
ROW OPERATIONS
--------------
0 queries inside InnoDB, 0 queries in queue
3 read views open inside InnoDB
Process ID=3408, Main thread ID=4508, state: sleeping
Number of rows inserted 20037484, updated 32888, deleted 5, read 1080534421
0.00 inserts/s, 0.00 updates/s, 0.00 deletes/s, 0.00 reads/s
----------------------------
----------------------------
END OF INNODB MONITOR OUTPUT
============================
InnoDB: ###### Diagnostic info printed to the standard error stream
2018-09-29T13:14:21.502160Z 0 [ERROR] [FATAL] InnoDB: Semaphore wait has lasted > 600 seconds. We intentionally crash the server because it appears to be hung.
2018-09-29 21:14:21 0x1028 InnoDB: Assertion failure in thread 4136 in file le ut0ut.cc lin line 942
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to to http://bugs.mysql.com.
In.
InnoDB: If you get repeated assertion failures or crashes, even
InnoDB: immediately after the mysqld startup, there may be
InnoDB: corruption in the InnoDB tablespace. Please refer to
InnoDB: B: http://dev.mysql.com/doc/refman/5.7/en/forcing-innodb-recovery.html
Inn
InnoDB: about forcing recovery.
13:14:21 UTC - mysqld got exception 0x80000003 ;
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=8388608
read_buffer_size=8388608
max_used_connections=103
max_threads=1000
thread_count=4
connection_count=4
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 3821459 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.

Thread pointer: 0x0
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...
13f9b1f22 mysqld.exe!my_sigabrt_handler()[my_thr_init.c:449]
7fef7d8ee1d MSVCR120.dll!raise()
7fef7d94a14 MSVCR120.dll!abort()
13facd9d4 mysqld.exe!ut_dbg_assertion_failed()[ut0dbg.cc:67]
13facdbb1 mysqld.exe!ib::fatal::~fatal()[ut0ut.cc:942]
13fa15183 mysqld.exe!srv_error_monitor_thread()[srv0srv.cc:1738]
77aa652d kernel32.dll!BaseThreadInitThunk()
77bdc521 ntdll.dll!RtlUserThreadStart()
The manual page at http://dev.mysql.com/doc/mysql/en/crashing.html contains
information that should help you find out what is causing the crash.

...全文