mysql8數據庫（mysql8數據庫原理與應用微課版答案）

本文目錄一覽：

• 1、自己建的數據庫放在mysql8什麼地方?
• 2、mysql8好用嗎？現在用的多嗎？
• 3、mysql8 ibdata文件丟失怎麼恢複數據

自己建的數據庫放在mysql8什麼地方?

默認在安裝目錄的data文件下，數據庫創建時會生成和數據庫同名的文件夾，該文件下既是數據庫文件。

mysql8好用嗎？現在用的多嗎？

mysql8 可以說是一個質的飛越。增加了很多新特性，以及提高了各方面的速度。增加了開窗函數

Ⅱ InnoDB增強

自增列方面

自增列方面。現在自增列計數器會在每次值修改時，將值寫到REDO LOG中，並且在CHECKPOINT時寫到存儲引擎私有的系統表中。

這就消除了以往重啟實例自增列不連續的問題（這也可能形成了一個新的競爭點（蓋國強會上提問InnoDB開發者））。

Btree索引方面

Btree索引被損壞。InnoDB會向REDO LOG中寫入一個損壞標誌。同時也會CHECKPOINT時將內存中損壞頁的數據記錄到存儲引擎私有的系統表中。

這也就促成了恢復時。兩邊一致的情形。索引不可用，並不會造成實例起不來。這很大程度上降低了之前使用innodb_force_recovery和innodb_fast_shutdown的必要。

提升了一致性。（對於一般DBA來說透明，知道有這麼回事就好）

NoSQl操作

InnoDB memcached插件支持多個get操作（在單個memcached查詢中獲取多個鍵/值對）

和範圍查詢。（個人認為這個挺牛逼，有點像NoSQL，不僅僅是NoSQL）。

需要安裝daemon_memcached插件，其中多了一個innodb_memcache schema,這個schema中有幾張表,其中一張containers用來與InnoDB表之間做映射,，

然後通過接口訪問Innodb表。然後會有一個11211的端口打開，用於建立連接。

好處是通過減少客戶端和服務器之間的通信流量，在單個memcached查詢中獲取多個鍵/值對的功能可以提高讀取性能。

對於InnoDB來說，也意味着更少的事務和開放式表操作。

死鎖檢測

新的動態配置選項innodb_deadlock_detect可用于禁用死鎖檢測，默認打開。 在高並發系統上，當大量線程等待相同的鎖時，死鎖檢測會導致速度下降。 有時，在死鎖發生時，

禁用死鎖檢測並依賴innodb_lock_wait_timeout設置進行事務回滾可能更有效。記得之前版本遇到死鎖會自動回滾。以下截圖來自MySQL5.7，與8.0默認相同。

（也就是說即便MySQL5.7也是有死鎖檢測的，並且自動回滾權重較小的事務（套死除外））。

嘗試更改innodb_deadlock_detect參數為OFF。則遇到死鎖時兩個工作線程都會被堵塞。直到innodb_lock_wait_timeout設定的鎖超時。

新的INFORMATION_SCHEMA.INNODB_CACHED_INDEXES表保存了Innodb索引緩存在Innodb buffer pool中的頁數。

現在，所有InnoDB臨時表都將在共享臨時表空間ibtmp1中創建。

加密特性

支持REDO和UNDO表空間加密。

共享鎖方面

InnoDB在 SELECT … FOR SHARE 和 SELECT … FOR UPDATE鎖定讀語句上 支持不等待（ NOWAIT）和跳過鎖（SKIP LOCKED）的選項。也就是說以往加了共享鎖之後必須手動釋放。

這裡如果沒有鎖就返回結果，如果有就報下面錯誤。

如果是用有鎖就跳過，則無數據。

根據場景使用。反正都是秒回。降低了排查數據庫超時的可能。

mysql8 ibdata文件丟失怎麼恢複數據

因為磁盤空間不足，我的一個虛擬機服務器崩潰了。結果數據庫服務器進程無法啟動，數據也就無法導出。只能想辦法從數據庫原始文件 ibdata 和 frm 文件中恢複數據庫。

因為沒有經驗，好不容易才找到了恢復方法。特此記錄，以備後用。

磁盤空間不足之後，mysqld 進程無法啟動，提示“Can’t connect to local MySQL server through socket ‘/var/lib/mysql/mysql.sock’ (2)”。這真是讓人無比頭大，數據庫根本連接不上。

目錄 Contents

1. 保存原始數據庫文件

2. 恢復方法

3. 參考資料：

1. 保存原始數據庫文件¶

好在數據庫原始文件還在。在我的系統環境和配置情況下，這些文件位於 /var/lib/mysql/ 文件夾下面。假設數據庫名是 test，則這些文件表現為：

–mysql

|–test

|–1.frm

|–2.frm

|…

|–mysql

|…

|–ib_logfile0

|–ib_logfile1

|–ibdata1

|…

這些就是原始數據庫文件，可以用來恢複數據庫。將這些文件額外保存一份，以防萬一。

2. 恢復方法¶

我的原始虛擬機完全沒有磁盤空間而無法啟動數據庫服務器進程。雖然試着刪除一些不需要的文件，但是數據庫卻始終無法連接。於是我新建了一個幾乎一樣的虛擬機（當然磁盤加大了），試圖將這些數據庫文件導入並恢複數據庫。

在經歷了很多錯誤之後，終於找到了正確的方法：

安裝完成新服務器之後，通過命令行新建了與原來一樣的數據庫：數據庫名稱、用戶名、密碼都一樣。如果有多個數據庫需要恢復，就都給建好。（跟配置新服務器一樣，參見安裝和配置 MYSQL 數據庫服務器。）

停止 mysqld 進程

service mysqld stop

將備份的原始數據庫文件中的所有 .frm 文件（保持原來的目錄結構）和 ibdata1 文件複製到新服務器的數據庫文件目錄中（如果新服務器操作系統和配置環境一樣，那麼目錄結構也一樣），其它文件不要。

使用 -innodb_force_recovery=6參數啟動數據庫服務器進程，這裡是

/etc/init.d/mysqld start -defaults-file=/etc/my.cnf -standalone -console -innodb_force_recovery=6

OK，數據庫恢復完成。