一跷跪、This function has none of DETERMINISTIC, NO SQL, or READS SQL DATA in its de 錯誤解決辦法
這是我們開啟了bin-log, 我們就必須指定我們的函數(shù)是否是
1 DETERMINISTIC 不確定的
2 NO SQL 沒有SQl語句吵瞻，當(dāng)然也不會修改數(shù)據(jù)
3 READS SQL DATA 只是讀取數(shù)據(jù)，當(dāng)然也不會修改數(shù)據(jù)
4 MODIFIES SQL DATA 要修改數(shù)據(jù)
5 CONTAINS SQL 包含了SQL語句
其中在function里面济舆，只有 DETERMINISTIC, NO SQL 和 READS SQL DATA 被支持吗冤。如果我們開啟了 bin-log, 我們就必須為我們的function指定一個參數(shù)九府。
在MySQL中創(chuàng)建函數(shù)時出現(xiàn)這種錯誤的解決方法：執(zhí)行下面語句
set global log_bin_trust_function_creators=TRUE;
二 侄旬、navicat 連接mysql 錯誤提示 ： 2003 Can't connect to MySql server on "localhost"(10061)
mysql 服務(wù) 關(guān)閉 不能重啟
windows 意外關(guān)閉 mysql 服務(wù)不能啟動肺蔚，報錯
2003 Can't connect to MySql server on "localhost"(10061)
在mysql 的data目錄下找到 .err錯誤日志
[ERROR] [MY-000000] [InnoDB] InnoDB: Assertion failure: dict0dict.cc:1235:table2 == NULL
InnoDB: thread 20556
InnoDB: We intentionally generate a memory trap.
InnoDB: Submit a detailed bug report to http://bugs.mysql.com.
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: http://dev.mysql.com/doc/refman/8.0/en/forcing-innodb-recovery.html
InnoDB: about forcing recovery.
02:18:37 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=131072
max_used_connections=2
max_threads=151
thread_count=3
connection_count=2
It is possible that mysqld could use up to
key_buffer_size + (read_buffer_size + sort_buffer_size)*max_threads = 67690 K bytes of memory
Hope that's ok; if not, decrease some variables in the equation.
Thread pointer: 0x1c5f286a6a0
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...
7ff74ffeb242 mysqld.exe!my_sigabrt_handler()[my_thr_init.cc:373]
7ffee836dc17 ucrtbase.dll!raise()
7ffee836eaa1 ucrtbase.dll!abort()
7ff7502360b7 mysqld.exe!ut_dbg_assertion_failed()[ut0dbg.cc:90]
7ff750177e0c mysqld.exe!dict_table_add_to_cache()[dict0dict.cc:1235]
7ff75028d02e mysqld.exe!dd_open_table_onedd::Table()[dict0dd.cc:4062]
7ff75028bad6 mysqld.exe!dd_open_tabledd::Table()[dict0dd.cc:4229]
7ff75013a5d0 mysqld.exe!ha_innobase::open()[ha_innodb.cc:6150]
7ff74f28a1ea mysqld.exe!handler::ha_open()[handler.cc:2633]
7ff74f31c7b8 mysqld.exe!open_table_from_share()[table.cc:2941]
7ff74f42495e mysqld.exe!open_table()[sql_base.cc:3298]
7ff74f423920 mysqld.exe!open_and_process_table()[sql_base.cc:4958]
7ff74f425886 mysqld.exe!open_tables()[sql_base.cc:5583]
7ff74f425dd1 mysqld.exe!open_tables_for_query()[sql_base.cc:6363]
7ff74f4d0ec9 mysqld.exe!Sql_cmd_dml::prepare()[sql_select.cc:345]
7ff74f4cd88d mysqld.exe!Sql_cmd_dml::execute()[sql_select.cc:494]
7ff74f432d38 mysqld.exe!mysql_execute_command()[sql_parse.cc:4147]
7ff74f433816 mysqld.exe!mysql_parse()[sql_parse.cc:4927]
7ff74f42d6b8 mysqld.exe!dispatch_command()[sql_parse.cc:1607]
7ff74f42e5e5 mysqld.exe!do_command()[sql_parse.cc:1233]
7ff74f2ac538 mysqld.exe!handle_connection()[connection_handler_per_thread.cc:308]
7ff7503d3e87 mysqld.exe!pfs_spawn_thread()[pfs.cc:2839]
7ff74ffeb1dc mysqld.exe!win_thread_start()[my_thread.cc:52]
7ffee831cd70 ucrtbase.dll!_o__realloc_base()
7ffeeb708364 KERNEL32.DLL!BaseThreadInitThunk()
7ffeeb9c70b1 ntdll.dll!RtlUserThreadStart()
Trying to get some variables.
Some pointers may be invalid and cause the dump to abort.
Query (1c5f32f33e8): SELECT COUNT(1) FROM mdmDB.contract_ticket
Connection ID (thread ID): 8
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.
可能是windows 非正常關(guān)機 導(dǎo)致的問題
網(wǎng)上解決辦法
1儡羔、重啟 MySQL服務(wù)
2、重改一下密碼
都無效
下面的方法 幫到了我
其中重點的幾句是：
2020-04-07T02:08:36.359052Z 8 [ERROR] [MY-013183] [InnoDB] Assertion failure: dict0dict.cc:1224:table2 == NULL thread 123145436229632
InnoDB: We intentionally generate a memory trap.
InnoDB: We intentionally generate a memory trap.
Connection ID (thread ID): 8
Status: NOT_KILLED
從網(wǎng)上搜了下發(fā)現(xiàn)這種大多是因為突然宕機造成的數(shù)據(jù)庫數(shù)據(jù)出了問題汰蜘，我這塊出錯的表是在django的apscheduler中仇冯，在運行時這部分表的確會不斷進(jìn)行查詢等操作族操，所以突遇意外也是很有可能的苛坚。
解決方法首選是修改 innodb_force_recovery 的值，這個值的說明如下：
innodb_force_recovery 會影響整個InnoDB存儲引擎的恢復(fù)狀況色难。默認(rèn)為0，表示當(dāng)需要恢復(fù)時執(zhí)行所有的
innodb_force_recovery可以設(shè)置為1-6,大的數(shù)字包含前面所有數(shù)字的影響枷莉。當(dāng)設(shè)置參數(shù)值大于0后笤妙，可以對表進(jìn)行
select,create,drop操作,但insert,update或者delete這類操作是不允許的。
值為1：(SRV_FORCE_IGNORE_CORRUPT):忽略檢查到的corrupt頁。
值為2：(SRV_FORCE_NO_BACKGROUND):阻止主線程的運行，如主線程需要執(zhí)行full purge操作严蓖，會導(dǎo)致crash氧急。
值為3：(SRV_FORCE_NO_TRX_UNDO):不執(zhí)行事務(wù)回滾操作吩坝。
值為4：(SRV_FORCE_NO_IBUF_MERGE):不執(zhí)行插入緩沖的合并操作。
值為5：(SRV_FORCE_NO_UNDO_LOG_SCAN):不查看重做日志哑蔫，InnoDB存儲引擎會將未提交的事務(wù)視為已提交钉寝。
值為6：(SRV_FORCE_NO_LOG_REDO):不執(zhí)行前滾的操作。
修改my.ini文件
在[mysqld]下面加上一行
innodb_force_recovery = 1
闸迷，建議從1開始試嵌纲，未成功再變成2、3腥沽、4…我理解的是逮走，數(shù)字越大，恢復(fù)的數(shù)據(jù)就離最新版本越遠(yuǎn)今阳。
然后保存my.ini师溅，重啟mysql
我的修改成2 后 啟動成功 恢復(fù)了
innodb_force_recovery 改回0
之后記得把my.ini里的 innodb_force_recovery 值改回0，重啟mysql盾舌。
三墓臭、 本地計算機上的mysql服務(wù)啟動后停止，某些服務(wù)在未由其他服務(wù)或程序使用時將自動停止妖谴。
其實是my.ini保存的時候窿锉，自動使用了 utf-8 編碼，導(dǎo)致mysql 無法正常識別my.ini窖维。解決方法很簡單：my.ini另存榆综，選編碼 ANSI ，就可以了铸史。親測有效鼻疮。
