如何解決MySQL問題

1、情況一：MySQL的錯誤日志文件（安裝目錄\MYOA\data5\機器名.err）會記錄如下內容：

浦北網站建設公司成都創新互聯公司,浦北網站設計制作，有大型網站制作公司豐富經驗。已為浦北數千家提供企業網站建設服務。企業網站搭建\成都外貿網站建設公司要多少錢，請找那個售后服務好的浦北做網站的公司定做！

InnoDB: Reading tablespace information from the .ibd files...

InnoDB: Error: trying to add tablespace 460 of name '.\td_oa\flow_data_35.ibd'

InnoDB: to the tablespace memory cache, but tablespace

InnoDB: 460 of name '.\td_oa\exam_data.ibd' already exists in the tablespace

解決方法：

1）剪切出安裝目錄\MYOA\data5\TD_OA的flow_data_35.ibd和flow_data_35.frm兩個文件；

2）啟動MySQL5_OA服務，使用備份的flow_data_35.sql導入到TD_OA庫中。如果提示flow_data_35表已經存在不能導入，則繼續按后續步驟執行；

3）在data5下手動建立tmp目錄；

4）使用MySQL管理工具或MySQL命令行程序在tmp下建立名稱為flow_data_35的表（包含一個字段即可）；

5）將tmp下的flow_data_35.frm和flow_data_35.ibd拷貝到安裝目錄\MYOA\data5\TD_OA目錄下；

6）在MySQL管理工具或MySQL命令行程序中，進入TD_OA庫，使用“drop table flow_data_35;”命令清除公共表空間中殘留的flow_data_35表的相關信息；

7）進入tmp庫，刪掉flow_data_35表；

8）使用備份的flow_data_35.sql導入到TD_OA庫中；

9）如果還有其他表存在該問題，可重復執行4至8步驟。

2、情況二：MySQL的錯誤日志文件（安裝目錄\MYOA\data5\機器名.err）會記錄如下內容：

130409 15:54:31 [Note] Plugin 'FEDERATED' is disabled.

130409 15:54:31 InnoDB: The InnoDB memory heap is disabled

130409 15:54:31 InnoDB: Mutexes and rw_locks use Windows interlocked functions

130409 15:54:31 InnoDB: Compressed tables use zlib 1.2.3

130409 15:54:32 InnoDB: Initializing buffer pool, size = 1023.0M

InnoDB: VirtualAlloc(1086849024 bytes) failed; Windows error 8

130409 15:54:32 InnoDB: Completed initialization of buffer pool

130409 15:54:32 InnoDB: Fatal error: cannot allocate memory for the buffer pool

130409 15:54:32 [ERROR] Plugin 'InnoDB' init function returned error.

130409 15:54:32 [ERROR] Plugin 'InnoDB' registration as a STORAGE ENGINE failed.

130409 15:54:32 [ERROR] Unknown/unsupported storage engine: Innodb

130409 15:54:32 [ERROR] Aborting

解決方法：

此情況出現的原因是myoa\mysql5\my.ini中innodb_buffer_pool_size的值太大，OA服務器操作系統不支持所致。改小后再啟動mysql5_OA服務即可，一般保持和數據庫大小一致。數據庫大小即是myoa/data5的大小。

3、情況三：mysql服務啟動不了，事件查看器中顯示：The syntax

'--log-slow-queries' is deprecated and will be removed in a future

release. Please use '--slow-query-log'/'--slow-query-log-file' instead.

解決方法：安裝目錄\MYOA\data5下的ibdata1、ib_logfile0、ib_logfile1文件屬性被設置為只讀導致，取消只讀控制，重啟mysql5_OA服務即可。

4、情況四：MySQL的錯誤日志文件（data5\機器名.err）會記錄如下內容：InnoDB: No valid checkpoint found.

解決方法：此問題找不到檢查點，數據庫是無效的，此種情況，只能用熱備份數據恢復。

5、以上四種情況，是2013版OA系統目前比較常見的mysql服務啟動不了的現象和解決辦法，大家可作參考，其他情況的話，再具體分析處理。

6、分析思路總結：遇到mysql5_OA服務啟動不了的情況，首先查看myoa\data5下的錯誤日志文件，根據日志中的具體內容進行具體分析。

7、2013版MYSQL服務啟動不了（可以嘗試強制啟動mysql服務）方法如下：

1)打開\MYOA\mysql5\my.ini，去掉innodb_force_recovery=1前邊的注釋。

2)啟動MySQL5_OA服務，此時MySQL處于只讀狀態，可以導出，不可寫入。如果仍不能啟動，可以嘗試將innodb_force_recovery修改為2、3、4、5、6等，直到可以啟動為止。

3)使用MySQL管理工具，將TD_OA等相關的數據庫導出為SQL文件。

4)停止MySQL5_OA服務，刪除TD_OA下的所有文件、ibdata1、ib_logfile0、ib_logfile1等文件。

5）打開\MYOA\mysql5\my.ini，在innodb_force_recovery=1前邊加上#號，將該項注釋掉。

6)啟動MySQL5_OA服務，然后導入此前備份的SQL文件。

7)檢查數據庫，將無法通過該方法恢復的數據表，通過之前自動備份的SQL文件進行恢復。

mysql binlog數據是怎么處理的

MySQL 的 Binlog 記錄著 MySQL 數據庫的所有變更信息，了解 Binlog 的結構可以幫助我們解析Binlog，甚至對 Binlog 進行一些修改，或者說是“篡改”，例如實現類似于 Oracle 的 flashback 的功能，恢復誤刪除的記錄，把 update 的記錄再還原回去等。本文將帶您探討一下這些神奇功能的實現，您會發現比您想象地要簡單得多。本文指的 Binlog 是 ROW 模式的 Binlog，這也是 MySQL 8 里的默認模式，STATEMENT 模式因為使用中有很多限制，現在用得越來越少了。

Binlog 由事件（event）組成，請注意是事件（event）不是事務（transaction），一個事務可以包含多個事件。事件描述對數據庫的修改內容。

現在我們已經了解了 Binlog 的結構，我們可以試著修改 Binlog 里的數據。例如前面舉例的 Binlog 刪除了一條記錄，我們可以試著把這條記錄恢復，Binlog 里面有個刪除行（DELETE_ROWS_EVENT）的事件，就是這個事件刪除了記錄，這個事件和寫行（WRITE_ROWS_EVENT）的事件的數據結構是完全一樣的，只是刪除行事件的類型是 32，寫行事件的類型是 30，我們把對應的 Binlog 位置的 32 改成 30 即可把已經刪除的記錄再插入回去。從前面的 “show binlog events” 里面可看到這個 DELETE_ROWS_EVENT 是從位置 378 開始的，這里的位置就是 Binlog 文件的實際位置（以字節為單位）。從事件（event）的結構里面可以看到 type_code 是在 event 的第 5 個字節，我們寫個 Python 小程序把把第383（378+5=383）字節改成 30 即可。當然您也可以用二進制編輯工具來改。

找出 Binlog 中的大事務

由于 ROW 模式的 Binlog 是每一個變更都記錄一條日志，因此一個簡單的 SQL，在 Binlog 里可能會產生一個巨無霸的事務，例如一個不帶 where 的 update 或 delete 語句，修改了全表里面的所有記錄，每條記錄都在 Binlog 里面記錄一次，結果是一個巨大的事務記錄。這樣的大事務經常是產生麻煩的根源。我的一個客戶有一次向我抱怨，一個 Binlog 前滾，滾了兩天也沒有動靜，我把那個 Binlog 解析了一下，發現里面有個事務產生了 1.4G 的記錄，修改了 66 萬條記錄！下面是一個簡單的找出 Binlog 中大事務的 Python 小程序，我們知道用 mysqlbinlog 解析的 Binlog，每個事務都是以 BEGIN 開頭，以 COMMIT 結束。我們找出 BENGIN 前面的 “# at” 的位置，檢查 COMMIT 后面的 “# at” 位置，這兩個位置相減即可計算出這個事務的大小，下面是這個 Python 程序的例子。

切割 Binlog 中的大事務

對于大的事務，MySQL 會把它分解成多個事件（注意一個是事務 TRANSACTION，另一個是事件 EVENT），事件的大小由參數 binlog-row-event-max-size 決定，這個參數默認是 8K。因此我們可以把若干個事件切割成一個單獨的略小的事務

ROW 模式下，即使我們只更新了一條記錄的其中某個字段，也會記錄每個字段變更前后的值，這個行為是 binlog_row_image 參數控制的，這個參數有 3 個值，默認為 FULL，也就是記錄列的所有修改，即使字段沒有發生變更也會記錄。這樣我們就可以實現類似 Oracle 的 flashback 的功能，我個人估計 MySQL 未來的版本從可能會基于 Binlog 推出這樣的功能。

了解了 Binlog 的結構，再加上 Python 這把瑞士軍刀，我們還可以實現很多功能，例如我們可以統計哪個表被修改地最多？我們還可以把 Binlog 切割成一段一段的，然后再重組，可以靈活地進行 MySQL 數據庫的修改和遷移等工作。

怎么樣對MySQL中的事件進行調度

怎么樣對MySQL中的事件進行調度

一、概述

事件調度器是在 MySQL 5.1 中新增的另一個特色功能，可以作為定時任務調度器，取代部分原先只能用操作系統任務調度器才能完成的定時功能。例如，Linux 中的 crontabe 只能精確到每分鐘執行一次，而 MySQL 的事件調度器則可以實現每秒鐘執行一個任務，這在一些對實時性要求較高的環境下就非常實用了。

事件調度器是定時觸發執行的，在這個角度上也可以稱作是"臨時的觸發器"。觸發器只是針對某個表產生的事件執行一些語句，而事件調度器則是在某一個(間隔)時間執行一些語句。事件是由一個特定的線程來管理的，也就是所謂的"事件調度器"。啟用事件調度器后，擁有 SUPER 權限的賬戶執行 SHOW PROCESSLIST 就可以看到這個線程了。通過設定全局變量event_scheduler 的值即可動態的控制事件調度器是否啟用。

復制代碼 代碼如下:

(root:localhost:)test SET GLOBAL event_scheduler = ON;

(root:localhost:)test show processlist\G

*************************** 4. row ***************************

Id: 46147

User: event_scheduler

Host: localhost

db: NULL

Command: Daemon

Time: 1

State: Waiting on empty queue

Info: NULL

如上，該線程的所有者是 event_scheduler。

二、應用案例

本案例是利用 event scheduler 的特性，每秒鐘調用一次存儲過程，用于判斷 SLAVE 是否正常運行，如果發現 SLAVE 關閉了，忽略 0 次錯誤，然后重新啟動 SLAVE。

首先創建存儲過程

delimiter //

復制代碼 代碼如下:

create procedure `Slave_Monitor`()

begin

SELECT VARIABLE_VALUE INTO @SLAVE_STATUS

FROM information_schema.GLOBAL_STATUS

WHERE VARIABLE_NAME='SLAVE_RUNNING';

IF ('ON' != @SLAVE_STATUS) THEN

SET GLOBAL SQL_SLAVE_SKIP_COUNTER=0;

SLAVE START;

END IF;

end; //

delimiter ;

由于存儲過程中無法調用類似 SHOW SLAVE STATUS 這樣的語句，因此無法得到確切的復制錯誤信息和錯誤代碼，不能進一步的處理 SLAVE 停止的各種情況。

接著，創建任務

復制代碼 代碼如下:

CREATE EVENT IF NOT EXISTS `Slave_Monitor`

ON SCHEDULE EVERY 5 SECOND

ON COMPLETION PRESERVE

DO

CALL Slave_Monitor();

創建了一個任務，每 5秒鐘 執行一次，任務結束后依舊保留該任務，而不是刪除。當然了，在本例中的任務不會結束，除非將它手動禁止了。

如果在運行中想要臨時關閉一下某個任務，執行 ALTER EVENT 語句即可：

復制代碼 代碼如下:

(root:localhost:)test alter event `Slave_Monitor` ON

COMPLETION PRESERVE DISABLE;

(root:localhost:)test alter event `Slave_Monitor` ON

COMPLETION PRESERVE ENABLE;

怎么用mysql處理這樣的問題？

通常情況下在PHP中MySQL查詢是串行的，如果能實現MySQL查詢的異步化，就能實現多條SQL語句同時執行，這樣就能大大地縮短MySQL查詢的耗時，提高數據庫查詢的效率。目前MySQL的異步查詢只在MySQLi擴展提供，查詢方法分別是：

1、使用MYSQLI_ASYNC模式執行mysqli::query

2、獲取異步查詢結果：mysqli::reap_async_query

使用mysql異步查詢，需要使用mysqlnd作為PHP的MySQL數據庫驅動。

使用MySQL異步查詢，因為需要給所有查詢都創建一個新的連接，而MySQL服務端會為每個連接創建一個單獨的線程進行處理，如果創建的線程過多，則會造成線程切換引起系統負載過高。Swoole中的異步MySQL其原理是通過MYSQLI_ASYNC模式查詢，然后獲取mysql連接的socket，加入到epoll事件循環中，當數據庫返回結果時會回調指定函數，這個過程是完全異步非阻塞的。

MySQL知識點總結

只要字段值還可以繼續拆分，就不滿足第一范式。

范式設計得越詳細，對某些實際操作可能會更好，但并非都有好處，需要對項目的實際情況進行設定。

在滿足第一范式的前提下，其他列都必須完全依賴于主鍵列。 如果出現不完全依賴，只可能發生在聯合主鍵的情況下：

實際上，在這張訂單表中，product_name 只依賴于 product_id ，customer_name 只依賴于 customer_id。也就是說，product_name 和 customer_id 是沒用關系的，customer_name 和 product_id 也是沒有關系的。

這就不滿足第二范式：其他列都必須完全依賴于主鍵列！

拆分之后，myorder 表中的 product_id 和 customer_id 完全依賴于 order_id 主鍵，而 product 和 customer 表中的其他字段又完全依賴于主鍵。滿足了第二范式的設計！

在滿足第二范式的前提下，除了主鍵列之外，其他列之間不能有傳遞依賴關系。

表中的 customer_phone 有可能依賴于 order_id 、 customer_id 兩列，也就不滿足了第三范式的設計：其他列之間不能有傳遞依賴關系。

修改后就不存在其他列之間的傳遞依賴關系，其他列都只依賴于主鍵列，滿足了第三范式的設計！

查詢每門課的平均成績。

查詢 score 表中至少有 2 名學生選修，并以 3 開頭的課程的平均分數。

分析表發現，至少有 2 名學生選修的課程是 3-105 、3-245 、6-166 ，以 3 開頭的課程是 3-105 、3-245。也就是說，我們要查詢所有 3-105 和 3-245 的 degree 平均分。

查詢所有學生的 name，以及該學生在 score 表中對應的 c_no 和 degree 。

通過分析可以發現，只要把 score 表中的 s_no 字段值替換成 student 表中對應的 name 字段值就可以了，如何做呢？

查詢所有學生的 no 、課程名稱 ( course 表中的 name ) 和成績 ( score 表中的 degree ) 列。

只有 score 關聯學生的 no ，因此只要查詢 score 表，就能找出所有和學生相關的 no 和 degree ：

然后查詢 course 表：

只要把 score 表中的 c_no 替換成 course 表中對應的 name 字段值就可以了。

查詢所有學生的 name 、課程名 ( course 表中的 name ) 和 degree 。

只有 score 表中關聯學生的學號和課堂號，我們只要圍繞著 score 這張表查詢就好了。

只要把 s_no 和 c_no 替換成 student 和 srouse 表中對應的 name 字段值就好了。

首先把 s_no 替換成 student 表中的 name 字段：

再把 c_no 替換成 course 表中的 name 字段：

查詢 95031 班學生每門課程的平均成績。

在 score 表中根據 student 表的學生編號篩選出學生的課堂號和成績：

這時只要將 c_no 分組一下就能得出 95031 班學生每門課的平均成績：

查詢在 3-105 課程中，所有成績高于 109 號同學的記錄。

首先篩選出課堂號為 3-105 ，在找出所有成績高于 109 號同學的的行。

查詢所有成績高于 109 號同學的 3-105 課程成績記錄。

查詢所有和 101 、108 號學生同年出生的 no 、name 、birthday 列。

查詢 '張旭' 教師任課的學生成績表。

首先找到教師編號：

通過 sourse 表找到該教師課程號：

通過篩選出的課程號查詢成績表：

查詢某選修課程多于5個同學的教師姓名。

首先在 teacher 表中，根據 no 字段來判斷該教師的同一門課程是否有至少5名學員選修：

查看和教師編號有有關的表的信息：

我們已經找到和教師編號有關的字段就在 course 表中，但是還無法知道哪門課程至少有5名學生選修，所以還需要根據 score 表來查詢：

根據篩選出來的課程號，找出在某課程中，擁有至少5名學員的教師編號：

在 teacher 表中，根據篩選出來的教師編號找到教師姓名：

查詢 “計算機系” 課程的成績表。

思路是，先找出 course 表中所有 計算機系 課程的編號，然后根據這個編號查詢 score 表。

查詢 計算機系 與 電子工程系 中的不同職稱的教師。

查詢課程 3-105 且成績 至少 高于 3-245 的 score 表。

查詢課程 3-105 且成績高于 3-245 的 score 表。

查詢某課程成績比該課程平均成績低的 score 表。

查詢所有任課 ( 在 course 表里有課程 ) 教師的 name 和 department 。

查詢 student 表中至少有 2 名男生的 class 。

查詢 student 表中不姓 "王" 的同學記錄。

查詢 student 表中每個學生的姓名和年齡。

查詢 student 表中最大和最小的 birthday 值。

以 class 和 birthday 從大到小的順序查詢 student 表。

查詢 "男" 教師及其所上的課程。

查詢最高分同學的 score 表。

查詢和 "李軍" 同性別的所有同學 name 。

查詢和 "李軍" 同性別且同班的同學 name 。

查詢所有選修 "計算機導論" 課程的 "男" 同學成績表。

需要的 "計算機導論" 和性別為 "男" 的編號可以在 course 和 student 表中找到。

建立一個 grade 表代表學生的成績等級，并插入數據：

查詢所有學生的 s_no 、c_no 和 grade 列。

思路是，使用區間 ( BETWEEN ) 查詢，判斷學生的成績 ( degree ) 在 grade 表的 low 和 upp 之間。

準備用于測試連接查詢的數據：

分析兩張表發現，person 表并沒有為 cardId 字段設置一個在 card 表中對應的 id 外鍵。如果設置了的話，person 中 cardId 字段值為 6 的行就插不進去，因為該 cardId 值在 card 表中并沒有。

要查詢這兩張表中有關系的數據，可以使用 INNER JOIN ( 內連接 ) 將它們連接在一起。

完整顯示左邊的表 ( person ) ，右邊的表如果符合條件就顯示，不符合則補 NULL 。

完整顯示右邊的表 ( card ) ，左邊的表如果符合條件就顯示，不符合則補 NULL 。

完整顯示兩張表的全部數據。

在 MySQL 中，事務其實是一個最小的不可分割的工作單元。事務能夠 保證一個業務的完整性 。

比如我們的銀行轉賬：

在實際項目中，假設只有一條 SQL 語句執行成功，而另外一條執行失敗了，就會出現數據前后不一致。

因此，在執行多條有關聯 SQL 語句時， 事務 可能會要求這些 SQL 語句要么同時執行成功，要么就都執行失敗。

在 MySQL 中，事務的 自動提交 狀態默認是開啟的。

自動提交的作用 ：當我們執行一條 SQL 語句的時候，其產生的效果就會立即體現出來，且不能 回滾 。

什么是回滾？舉個例子：

可以看到，在執行插入語句后數據立刻生效，原因是 MySQL 中的事務自動將它 提交 到了數據庫中。那么所謂 回滾 的意思就是，撤銷執行過的所有 SQL 語句，使其回滾到 最后一次提交 數據時的狀態。

在 MySQL 中使用 ROLLBACK 執行回滾：

由于所有執行過的 SQL 語句都已經被提交過了，所以數據并沒有發生回滾。那如何讓數據可以發生回滾？

將自動提交關閉后，測試數據回滾：

那如何將虛擬的數據真正提交到數據庫中？使用 COMMIT :

事務的實際應用 ，讓我們再回到銀行轉賬項目：

這時假設在轉賬時發生了意外，就可以使用 ROLLBACK 回滾到最后一次提交的狀態：

這時我們又回到了發生意外之前的狀態，也就是說，事務給我們提供了一個可以反悔的機會。假設數據沒有發生意外，這時可以手動將數據真正提交到數據表中：COMMIT 。

事務的默認提交被開啟 ( @@AUTOCOMMIT = 1 ) 后，此時就不能使用事務回滾了。但是我們還可以手動開啟一個事務處理事件，使其可以發生回滾：

仍然使用 COMMIT 提交數據，提交后無法再發生本次事務的回滾。

事務的四大特征：

事務的隔離性可分為四種 ( 性能從低到高 ) ：

查看當前數據庫的默認隔離級別：

修改隔離級別：

測試 READ UNCOMMITTED ( 讀取未提交 ) 的隔離性：

由于小明的轉賬是在新開啟的事務上進行操作的，而該操作的結果是可以被其他事務（另一方的淘寶店）看見的，因此淘寶店的查詢結果是正確的，淘寶店確認到賬。但就在這時，如果小明在它所處的事務上又執行了 ROLLBACK 命令，會發生什么？

這就是所謂的 臟讀 ，一個事務讀取到另外一個事務還未提交的數據。這在實際開發中是不允許出現的。

把隔離級別設置為 READ COMMITTED ：

這樣，再有新的事務連接進來時，它們就只能查詢到已經提交過的事務數據了。但是對于當前事務來說，它們看到的還是未提交的數據，例如：

但是這樣還有問題，那就是假設一個事務在操作數據時，其他事務干擾了這個事務的數據。例如：

雖然 READ COMMITTED 讓我們只能讀取到其他事務已經提交的數據，但還是會出現問題，就是 在讀取同一個表的數據時，可能會發生前后不一致的情況。* 這被稱為* 不可重復讀現象 ( READ COMMITTED ) 。

將隔離級別設置為 REPEATABLE READ ( 可被重復讀取 ) :

測試 REPEATABLE READ ，假設在兩個不同的連接上分別執行 START TRANSACTION :

當前事務開啟后，沒提交之前，查詢不到，提交后可以被查詢到。但是，在提交之前其他事務被開啟了，那么在這條事務線上，就不會查詢到當前有操作事務的連接。相當于開辟出一條單獨的線程。

無論小張是否執行過 COMMIT ，在小王這邊，都不會查詢到小張的事務記錄，而是只會查詢到自己所處事務的記錄：

這是 因為小王在此之前開啟了一個新的事務 ( START TRANSACTION ) * ，那么* 在他的這條新事務的線上，跟其他事務是沒有聯系的 ，也就是說，此時如果其他事務正在操作數據，它是不知道的。

然而事實是，在真實的數據表中，小張已經插入了一條數據。但是小王此時并不知道，也插入了同一條數據，會發生什么呢？

報錯了，操作被告知已存在主鍵為 6 的字段。這種現象也被稱為 幻讀，一個事務提交的數據，不能被其他事務讀取到 。

顧名思義，就是所有事務的 寫入操作 全都是串行化的。什么意思？把隔離級別修改成 SERIALIZABLE :

還是拿小張和小王來舉例：

此時會發生什么呢？由于現在的隔離級別是 SERIALIZABLE ( 串行化 ) ，串行化的意思就是：假設把所有的事務都放在一個串行的隊列中，那么所有的事務都會按照 固定順序執行 ，執行完一個事務后再繼續執行下一個事務的 寫入操作 ( 這意味著隊列中同時只能執行一個事務的寫入操作 ) 。

根據這個解釋，小王在插入數據時，會出現等待狀態，直到小張執行 COMMIT 結束它所處的事務，或者出現等待超時。

轉載：

mysql事件沒執行

1、命令查看是否開啟event_scheduleSHOWVARIABLESLIKE'event_scheduler'。

2、使用命令開啟臨時開啟，重啟mysql又還原回去。

3、修改配置永久修改配置文件的[mysqld]部分加上event_scheduler=ON。

分享名稱：mysql事件怎么處理 mysql的事務是怎么實現的
鏈接分享：http://vcdvsql.cn/article24/hepije.html

成都網站建設公司_創新互聯，為您提供搜索引擎優化、小程序開發、Google、自適應網站、建站公司、網站排名

廣告

聲明：本網站發布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創新互聯