Windows 10 (10.0.18363.0) 上的 MySQL 8.0.24 在執行最終結果查詢時在同一點附近崩潰，但僅在執行具有更多記錄的數據輸入查詢之後。

重新啟動 MySQL 服務並不能解決崩潰問題，而且它是可重複的。完全重啟 Windows 後（通過shutdown /r /t 1，以確保硬重啟）沒有崩潰；最終結果查詢執行並在 4 分鐘內完成。

我懷疑 Windows 記憶體資源被我的大型初始數據載入過程消耗或損壞，直到重新啟動後才會恢復，但該錯誤僅在我執行下游查詢時才顯示它的存在。

什麼可能會在 Windows 中被 MySQL 損壞，並且可以通過重新啟動來恢復？下面的詳細資訊是針對此實例的，但我的問題是一般性的：

1. 使用新的並行工具將大型 (6Gb) 載入到 Windows/mySQL
2. 嘗試對結果進行簡單查詢，導致 mySQL 崩潰
3. 相同的簡單查詢僅在 Windows 重新啟動後才成功，mySQL 重新啟動**無法修復。在唯一（並且可靠地可重複）修復是硬重啟的情況下，如何避免破壞具有大量數據負載的 Windows mySQL？問題不是“需要重新啟動”，而是為什麼在大型查詢中崩潰？

細節

下面的許多細節被證明是無關緊要的，請參閱接受的答案以獲得解釋。

在“最終結果”之前執行的數據載入查詢正在使用該實用程序（在 8.0.17 中引入），這是一種跨並行執行緒mysqhsh util.importTable呼叫的增強型 shell 命令。LOAD DATA INFILE這將數據載入時間從幾個小時減少到大約 50 分鐘。我有 6Gb 的數據，其中大部分位於兩個表中，每個表有 1-2 百萬行。數據在並行實用程序中載入PRIMARY KEY，然後用ALTER TABLE ADD INDEX.

所有這些執行都沒有任何錯誤，始終如一，數據集每天都在變化和增長。

失敗的結果查詢從數據載入和後處理期間創建的其他表中獲取值，然後UNIONs 他們有一個數據頭，並將結果寫到幾個文件中。這兩個查詢產生 < 100K 記錄，並且通常更少，因為它們是增量。這就是它所做的一切。所有的複雜性和大連接都在數據載入和處理.sql腳本中，所有這些都執行沒有錯誤，但似乎正在破壞 Windows。我在 InnoDB 系列上嘗試了各種設置，包括不同數量的緩衝池擴展、hash index on/off、innodb_flush_neighbors、innodb_lru_scan_depth等。這些確實對性能有影響，但不影響這個問題。在初始數據載入期間，我設置ALTER INSTANCE DISABLE INNODB REDO_LOG（從 8.0.21 開始新）以加快初始數據載入，但ALTER INSTANCE ENABLE INNODB REDO_LOG在執行失敗的查詢之前恢復。 題外話：如果你使用這個不要忘記重新啟用，因為任何影響 MySQL 的系統故障或崩潰都會導致實例損壞。BTDT。按照建議，僅在初始輸入期間使用。 我還沒有嘗試執行REDO LOG啟用的輸入過程。那是我的下一個測試。— 此模式中沒有設置觸發器或儲存采購，並且沒有其他任何東西在執行。實際上，這個 MySQL 實例中根本沒有觸發器。

日誌和.ini設置 來自崩潰的錯誤日誌 ( .err) 如下。前三行是輸入期間的警告，在出現任何問題之前，我正在切換重做日誌記錄（注意時間是分散的）。最後一個是ENABLE（應該是）。下一行 SQL 已崩潰並且 mySQL80 服務未執行。在2021-05-01T23:17:49我已經手動重新啟動了 mySQL80 服務：

none ! 2021-05-01T22:20:43.437169Z 1905 [Warning] [MY-013601] [InnoDB] InnoDB redo logging is enabled. Data is now safe and can be recovered in case of a server crash. ! 2021-05-01T22:35:52.244860Z 1966 [Warning] [MY-013600] [InnoDB] InnoDB redo logging is disabled. All data could be lost in case of a server crash. ! 2021-05-01T23:03:05.731314Z 1966 [Warning] [MY-013601] [InnoDB] InnoDB redo logging is enabled. Data is now safe and can be recovered in case of a server crash. ! 23:14:04 UTC - mysqld got exception 0xc0000005 ; ! Most likely, you have hit a bug, but this error can also be caused by malfunctioning hardware. ! Thread pointer: 0x280d9a167e0 ! 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... ! 7ff686461930 mysqld.exe!?set_compression_level@Zstd_comp@compression@transaction@binary_log@@UEAAXI@Z() ! 7ff68646104a mysqld.exe!?set_compression_level@Zstd_comp@compression@transaction@binary_log@@UEAAXI@Z() ! 7ff684fa32d7 mysqld.exe!?ha_rnd_next@handler@@QEAAHPEAE@Z() ! 7ff685295e71 mysqld.exe!?Read@TableScanIterator@@UEAAHXZ() ! 7ff6854616f7 mysqld.exe!?Read@FilterIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461757 mysqld.exe!?Read@FilterIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685461916 mysqld.exe!?Read@NestedLoopIterator@@UEAAHXZ() ! 7ff685460b99 mysqld.exe!?MaterializeQueryBlock@MaterializeIterator@@AEAA_NAEBUQueryBlock@1@PEA_K@Z() ! 7ff685460118 mysqld.exe!?Init@MaterializeIterator@@UEAA_NXZ() ! 7ff685304938 mysqld.exe!?filesort@@YA_NPEAVTHD@@PEAVFilesort@@PEAVRowIterator@@_K3PEAVFilesort_info@@PEAVSort_result@@PEA_K@Z() ! 7ff6854302ae mysqld.exe!?DoSort@SortingIterator@@AEAAHXZ() ! 7ff68543063a mysqld.exe!?Init@SortingIterator@@UEAA_NXZ() ! 7ff68545fcb4 mysqld.exe!?Init@AggregateIterator@@UEAA_NXZ() ! 7ff685460b5a mysqld.exe!?MaterializeQueryBlock@MaterializeIterator@@AEAA_NAEBUQueryBlock@1@PEA_K@Z() ! 7ff685460118 mysqld.exe!?Init@MaterializeIterator@@UEAA_NXZ() ! 7ff685460b5a mysqld.exe!?MaterializeQueryBlock@MaterializeIterator@@AEAA_NAEBUQueryBlock@1@PEA_K@Z() ! 7ff685460118 mysqld.exe!?Init@MaterializeIterator@@UEAA_NXZ() ! 7ff6852f99be mysqld.exe!?ExecuteIteratorQuery@Query_expression@@QEAA_NPEAVTHD@@@Z() ! 7ff6852fb0d6 mysqld.exe!?execute@Query_expression@@QEAA_NPEAVTHD@@@Z() ! 7ff68543a51d mysqld.exe!?execute@Sql_cmd_load_index@@UEAA_NPEAVTHD@@@Z() ! 7ff68543a1ca mysqld.exe!?execute@Sql_cmd_create_table@@UEAA_NPEAVTHD@@@Z() ! 7ff685179a71 mysqld.exe!?mysql_execute_command@@YAHPEAVTHD@@_N@Z() ! 7ff685174c2f mysqld.exe!?dispatch_sql_command@@YAXPEAVTHD@@PEAVParser_state@@@Z() ! 7ff685173a4c mysqld.exe!?dispatch_command@@YA_NPEAVTHD@@PEBTCOM_DATA@@W4enum_server_command@@@Z() ! 7ff68517500e mysqld.exe!?do_command@@YA_NPEAVTHD@@@Z() ! 7ff684fc64a8 mysqld.exe!?modify_thread_cache_size@Per_thread_connection_handler@@SAXK@Z() ! 7ff6863ddbe1 mysqld.exe!?set_compression_level@Zstd_comp@compression@transaction@binary_log@@UEAAXI@Z() ! 7ff685fc1d1c mysqld.exe!?my_thread_join@@YAHPEAUmy_thread_handle@@PEAPEAX@Z() ! 7ffb255d10b2 ucrtbase.dll!_beginthreadex() ! 7ffb280d7c24 KERNEL32.DLL!BaseThreadInitThunk() ! 7ffb286ad721 ntdll.dll!RtlUserThreadStart() ! ! Trying to get some variables. ! Some pointers may be invalid and cause the dump to abort. ! Query (280e085ec78): CREATE TABLE active_fan_export! SELECT !2021 Web Fan Acct Name, fan_profile_acct_name,Fan Profile, fan_id, account_type, Account Name! ,Account ID, Agree Name, agree_id, postal_code, state, svid ! ,>1 yr,GA,f enroll,Discount,oe name,disc value ! ,mobility enterprise type ! ,email domain count,email domains! FROM ! ( ! SELECT ! -1 asRank/******************** verbatim headers ********************************************************************/ ! ,'web_fan_acct_name'2021 Web Fan Acct Name,'fan_profile_acct_name' fan_profile_acct_name,'Fan Profile'Fan Profile! ,'fan_id'fan_id,'account_type' account_type, 'Account Name' Account Name! ! ,'Account ID'Account ID, 'Agree Name' Agree Name,'agree_id' agree_id,'postal_code' postal_code! ,'state'state,'svid' svid! ! ,'>1 yr'>1 yr,'GA' GA,'f enroll' f enroll,'Discount' Discount,'oe name' oe name,'disc value' disc value! ,'mobility enterprise type'mobility enterprise ty ! Connection ID (thread ID): 1141 ! Status: NOT_KILLED ! ! 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. ! 2021-05-01T23:17:49.000709Z 0 [Warning] [MY-010915] [Server] ‘NO_ZERO_DATE’, ‘NO_ZERO_IN_DATE’ and ‘ERROR_FOR_DIVISION_BY_ZERO’ sql modes should be used with strict mode. They will be merged with strict mode in a future release. !`

這也是我.ini的各種參數。這是在 512GB SSD、16GB RAM 戴爾 Precision 3551 筆記型電腦上：https ://pastebin.com/Kz0y3zFD

這讓我想起了 Windows 藍屏和莫名其妙的崩潰的糟糕日子。Windows 10 得到了很大改進，但即使有 16 GB，仍然可能永久耗盡資源（例如：打開太多並發應用程序或視窗，事情仍然會中斷並需要重新啟動）。我想我可能會在並行執行緒、巨型記憶體緩衝區等方面推動同樣的限制。我會在時間允許的情況下嘗試的事情：-減少 innodb 緩衝區大小-弄亂 parititons 的數量-使用少於 11 個執行緒（Intel i7-10850H支持 12 個 6 核） - 在載入期間打開 REDO LOG - 啟用雙寫緩衝 - 使用 Office 365、聊天等執行載入和最終查詢 關閉 - 在 Ubuntu 或 RHEL 主機上嘗試 - 來自答案/評論的其他想法 - - ＃＃＃ 更多資訊

$$ “dev.mysql.com/doc/mysql/en/crashing.html” $$$$ 1 $$從mySQL的官方文件有以下建議。我將用斜體字回复每一個： * MySQL 伺服器或伺服器主機在更新過程中被殺死。未應用更新；通常避免在更新期間殺死伺服器

• 你在 mysqld 中發現了一個錯誤，導致它在更新過程中死掉。可能

• 某些外部程序正在與 mysqld 同時操作數據文件或索引文件，而沒有正確鎖定表。不，這是桌面，只有其他正在執行的程序是 Office 和聊天客戶端

• 您在不支持良好文件系統鎖（通常由 lockd 鎖管理器處理）的系統上使用相同的數據目錄執行多個 mysqld 伺服器，或者您正在執行禁用外部鎖定的多個伺服器。在具有文件鎖的 NTFS 卷上使用股票安裝，不在任何地方執行第二台伺服器，永遠沒有複製

*您有一個崩潰的數據文件或索引文件，其中包含非常損壞的數據，這使 mysqld 感到困惑。是的，崩潰 = 困惑

• 您在數據儲存程式碼中發現了一個錯誤。這不太可能，但至少是可能的。在這種情況下，您可以嘗試通過在已修復的表副本上使用 ALTER TABLE 將儲存引擎更改為另一個引擎。 可能，但想知道“錯誤”是否

• 在啟用通用查詢日誌的情況下啟動 mysqld（請參閱第 5.4.3 節，“通用查詢日誌”）。要做的事情：將嘗試通用查詢日誌，其他建議雖然有些是特定於 Linux 主機的

— 詳細說明“對性能的影響”，例如，@@innodb_flush_neighbors設置為 0 而不是 2 減少了 11 個執行緒在“等待”中花費的時間處理程序送出”狀態，如在 Workbench 中觀察到的。這種變化對實際時間的影響很小，大約比 12 分鐘的載入時間少了 45 秒。我嘗試COMPRESSED了有關這些數據的表格，它使輸入速度減慢了大約一半。查詢失敗的源表是

!CREATE TABLE active_fan_export( !2021 Web Fan Acct Namevarchar(255) NOT NULL DEFAULT '', !fan_profile_acct_namelongtext NOT NULL, !Fan Profilelongtext NOT NULL, !fan_idvarchar(30) DEFAULT NULL, !account_typevarchar(12) DEFAULT NULL, !Account Namelongtext, !Account IDvarchar(15) DEFAULT NULL, !Agree Namelongtext, !agree_idvarchar(30) DEFAULT NULL, !postal_codevarchar(30) NOT NULL DEFAULT '', !statevarchar(10) NOT NULL DEFAULT '', !svidvarchar(30) NOT NULL DEFAULT '', !>1 yrvarchar(5) CHARACTER SET cp850 NOT NULL DEFAULT '', !GAvarchar(2) CHARACTER SET cp850 NOT NULL DEFAULT '', !f enrollvarchar(8) CHARACTER SET cp850 NOT NULL DEFAULT '', !Discountvarchar(15) NOT NULL DEFAULT '', !oe namevarchar(255) NOT NULL DEFAULT '', !disc valuevarchar(15) NOT NULL DEFAULT '', !mobility enterprise typevarchar(30) NOT NULL DEFAULT '', !email domain countvarchar(21) CHARACTER SET cp850 NOT NULL DEFAULT '', !email domainsvarchar(200) NOT NULL DEFAULT '', ! KEYfan_id (fan_id), ! KEY agree_id (agree_id), ! KEY Account ID (Account ID), ! KEY mobility enterprise type (mobility enterprise type) !) ENGINE=InnoDB DEFAULT CHARSET=utf8mb4 COLLATE=utf8mb4_0900_ai_ci; ! Thecp850是一個驚喜；我不知道那是從哪裡來的。我需要通過邏輯返回到初始數據載入。

importTable 多執行緒處理是 I/O 綁定的，除非定義了索引。在表定義中包含索引後，導入的 Mb/S 從大約 15 下降到 1，20 分鐘的載入時間上升到大約 30。索引載入後需要 3 分 30 秒，所以我不包括索引當我創建這些表時。即使有 12 個執行緒，CPU 也都在 50% 範圍內，並且 GUI 響應（瀏覽器、Outlook 等）幾乎沒有受到影響。索引創建是 CPU 密集型的。它不使用多個 CPU，但它確實在 GUI（瀏覽器、Outlook 等）中停止響應。關於 I/O 密集型的說明：此數據庫以前在具有 i7-6820HQ CPU 的 HP Z-book 上執行，具有更少的 4 個執行緒和更慢的基準測試。Z-book 帶有一個 SATA M.2 驅動器和一個空的 M.2 nVME 插槽。我添加了一張 WD750 遊戲玩家 nVME 卡，並將 mySQL 安裝和數據移至其中。那做了一個載入表格的速度提高了**30% 。**替換的戴爾只有一個M.2插槽，上面有企業形象，不能碰。該驅動器是 nVME KIOXIA 512 GB，其基準約為 WD Black 數字的 75%。即使 CPU 和 2019 年主機板技術比 2016 年更快，稍慢的 nVME 驅動器為 6Gb 數據產生的載入時間增加了 5-15%。

$$ 1 $$: https://dev.mysql.com/doc/refman/8.0/en/crashing.html

在這篇文章中找到了一個明顯的解決方案（如多次執行沒有崩潰，如果隨著時間的推移會出現故障，將標記為已解決） ，其中在.err日誌中找到了類似的文本。

通過禁用 mySQLoptimizer_switch系統中的特定條目，多次執行沒有觀察到崩潰。數據每週增加 10-25K 行，因此最近執行的數據集稍大。對於較新的數據集，即使在乾淨重啟後也觀察到崩潰。這否定了原始文章中的重新啟動修復理論。

optimizer_switch旗幟

根據這篇文章，這些開關的預設設置發生了變化：

SET GLOBAL optimizer_switch=
'derived_merge=off,
subquery_to_derived=off,
prefer_ordering_index=off,
semijoin=off';

崩潰停止發生，性能沒有明顯下降。無論哪種方式，查詢都需要大約 550 秒才能完成（儘管沒有關閉這些開關，它不會完成並且經常崩潰）。

工作台警告：標誌在工作台會話期間是固定的

Workbench 似乎在啟動時讀取這些開關一次，並且在工具完全退出並重新啟動之前它們不會改變。

例如，可以從 Workbench 視窗內部發出這些命令

但是系統上報的值

不反映變化：

在從工具執行查詢之前，請務必確認 Workbench 本身的設置。該REDO_LOG設置顯示為提醒，禁用此標誌的 mySQL 崩潰可以清除此處發生的實例。（幸運的是，我手頭有最近的實例備份）。更新：我在執行 Workbench 時發生了另一次崩潰，然後在關閉它後執行完成。我不會在 Workbench 處於活動狀態時執行此查詢，因為它似乎與導致崩潰或忽略我的 SQL 腳本中設置的 optimizer_switch 會話設置有關。

從 shell 所做的更改按預期直覺地工作： GLOBAL在重新啟動時生效，並SESSION更改目前會話中的值：

考慮這些 my.ini

$$ mysqld $$部分更改

innodb_thread_concurrency=0  # from 25 to allow Windows autosizing
thread_cache=size=10  # from 30 for your 6 core cpu to leave 2 for other purposes.

錯誤日誌似乎線上程管理方面存在問題。

引用自：https://dba.stackexchange.com/questions/291048