首頁 / CompScience / Database / MySQL / MySQL 5最後一次學科練習

MySQL 5最後一次學科練習

2013-08-16_104439

這是第十四次ㄚ琪自我練習的結果,也即將是最後一次的練習,因為明日就要上陣測試認證了,揮別炎熱的考季就看這次了,這一次的測試50題,答對45題得90分,錯5題扣5分,總計得分85分,跟上次一樣,通過認證沒問題,要成為資料庫應用的高手,指日可下。好了,閒話太多了,回到主題吧,這一回錯的題目好像比較不一樣了,粗心的成份看起來不多,讓我們好好研究研究吧。

2013-08-16_104504

這是MySQL 5實力養成暨評量裡的3-93.『假設資料表格book(id,name,author,price),請問下列各項SQL敘述,哪些是合法的?』

答案:

(A) select * from book where price between 300 and 500 order by price;

(C) insert into book values(“B004″,”5″,”CSF”,350);

(D) delete from book where name = “%mysql%”;

(A)、(C)沒問題,(D)則是頭一遭,因為以前會刪除like “%mysql%”這樣的用法,沒有用過= “%mysql%”這樣子,當然這個指令經過測試是沒錯的,但是我猜應該很少使用吧。

2013-08-16_104540

這是MySQL 5實力養成暨評量裡的9-21.『請參閱附圖作答

當使用InnoDB資料表且MySQL伺服器處理一個COMMIT敘述時,MySQL會先寫入整筆交易到binary log,然後才會提交資料到InnoDB資料表,若正好在此兩個動作中間發生當機事件,會造成binary log仍會寫入該筆紀錄,但InnoDB會作回復(Roll back)動作,造成了binary log與實際資料不同不的現象,若要解決此現象,可在執行參數中加入下列哪一個參數,便可避免此問題?』

答案:(A) –innodb-safe-binlog

好了,這一個選項也是很詭異的,特別是查考手冊之後發現5.0.3版之後這個就反對使用了,在MySQL 5.0 Reference Manual :: 5 MySQL Server Administration :: 5.1 The MySQL Server :: 5.1.3 Server Command Optionsu有講述這個選項:

--innodb-safe-binlog

Deprecated 5.0.3
Removed 5.0.3
Command-Line Format --innodb-safe-binlog
Option-File Format innodb-safe-binlog
Permitted Values
Type boolean

If this option is given, then after a crash recovery by InnoDBmysqld truncates the binary log after the last not-rolled-back transaction in the log. The option also causes InnoDB to print an error if the binary log is smaller or shorter than it should be. See Section 5.2.3, “The Binary Log”. This option was removed in MySQL 5.0.3, having been made obsolete by the introduction of XA transaction support.

簡體中文的MySQL 5.1参考手册 :: 5. 数据库管理::5.11. MySQL日志文件::5.11.3. 二进制日志也有提到。

我們把這一節轉成繁體給各位好好學習一下:

二進制日誌以一種更有效的格式,並且是交易安全的方式包含更新日誌中可用的所有訊息。

二進制日誌包含了所有更新了資料者已經潛在更新了資料(例如,沒有匹配任何行的一個DELETE)的所有敘述。敘述以「事件」的形式保存,它描述資料更改。

釋:二進制日誌已經代替了老的更新日誌,更新日誌在MySQL 5.1中不再使用。

二進制日誌還包含關於每個更新資料庫的敘述的執行時間訊息。它不包含沒有修改任何資料的敘述。如果您想要記錄所有敘述(例如,為了識別有問題的查詢),您應使用一般查詢日誌。參見5.11.2節,「通用查詢日誌」

二進制日誌的主要目的是在恢復使能夠最大可能地更新資料庫,因為二進制日誌包含備份後進行的所有更新。

二進制日誌還用於在主複製伺服器上記錄所有將發送給從伺服器的敘述。參見第6章:MySQL中的複製

運行伺服器時若啟用二進制日誌則性能大約慢1%。但是,二進制日誌的好處,即用於恢復並允許設置複製超過了這個小小的性能損失。

當用–log-bin[=file_name]選項啟動時,mysqld寫入包含所有更新資料的SQL命令的日誌檔案。如果未給出file_name值, 預設名為-bin後面所跟的主機名。如果給出了檔案名,但沒有包含路徑,則檔案被寫入資料目錄。建議指定一個檔案名,原因參見A.8.1節,「MySQL中的打開事宜」

如果您在日誌名中提供了延伸名(例如,–log-bin=file_name.extension),則延伸名被悄悄除掉並忽略。

mysqld在每個二進制日誌名後面新增一個數字延伸名。每次您啟動伺服器或刷新日誌時該數字則增加。如果當前的日誌大小達到max_binlog_size,還會自動建立新的二進制日誌。如果您正使用大的交易,二進制日誌還會超過max_binlog_size:交易全寫入一個二進制日誌中,絕對不要寫入不同的二進制日誌中。

為了能夠知道還使用了哪個不同的二進制日誌檔案,mysqld還建立一個二進制日誌索引檔案,包含所有使用的二進制日誌檔案的檔案名。預設情況下與二進制日誌檔案的檔案名相同,延伸名為’.index’。您可以用–log-bin-index[=file_name]選項更改二進制日誌索引檔案的檔案名。當mysqld在運行時,不應手動編輯該檔案;如果這樣做將會使mysqld變得混亂。

可以用RESET MASTER語句刪除所有二進制日誌檔案,或用PURGE MASTER LOGS只刪除部分二進制檔案。參見13.5.5.5節,「RESET語法」13.6.1節,「用於控制主伺服器的SQL語句」

二進制日誌格式有一些已知限制,會影響從備份恢復。參見6.7節,「複製特性和已知問題」

保存程式和觸發器的二進制日誌的描述參見20.4節,「儲存子程式和觸發程式的二進制日誌功能」

可以使用下面的mysqld選項來影響記錄到二進制日誌知的內容。又見選項後面的討論。

·         –binlog-do-db=db_name

告訴主伺服器,如果當前的資料庫(即USE選定的資料庫)是db_name,應將更新記錄到二進制日誌中。其它所有沒有明顯指定的資料庫  被忽略。如果使用該選項,您應確保只對當前的資料庫進行更新。

對於CREATE DATABASE、ALTER DATABASE和DROP DATABASE語句,有一個例外,即通過操作的資料庫來決定是否應記錄敘述,而不是用當前的資料庫。

一個不能按照期望執行的例子:如果用binlog-do-db=sales啟動伺服器,並且執行USE prices; UPDATE sales.january SET amount=amount+1000;,該敘述不寫入二進制日誌。

·         –binlog-ignore-db=db_name

告訴主伺服器,如果當前的資料庫(即USE選定的資料庫)是db_name,不應將更新保存到二進制日誌中。如果您使用該選項,您應確保只對當前的資料庫進行更新。

一個不能按照您期望的執行的例子:如果伺服器用binlog-ignore-db=sales啟動,並且執行USE prices; UPDATE sales.january SET amount=amount+1000;,該語句不寫入二進制日誌。

類似於–binlog-do-db,對於CREATE DATABASE、ALTER DATABASE和DROP DATABASE敘述,有一個例外,即通過操作的資料庫來決定是否應記錄敘述,而不是用當前的資料庫。

要想記錄或忽視多個資料庫,使用多個選項,為每個資料庫指定相應的選項。

伺服器根據下面的規則對選項進行評估,以便將更新記錄到二進制日誌中或忽視。請注意對於CREATE/ALTER/DROP DATABASE敘述有一個例外。在這些情況下,根據以下規則,所建立、修改或刪除的資料庫將代替當前的資料庫。

1.    是否有binlog-do-db或binlog-ignore-db規則?

·         沒有:將敘述寫入二進制日誌並退出。

·         有:執行下一步。

2.    有一些規則(binlog-do-db或binlog-ignore-db或二者都有)。當前有一個資料庫(USE是否選擇了資料庫?)?

·         沒有:不要寫入敘述,並退出。

·         有:執行下一步。

3.    有當前的資料庫。是否有binlog-do-db規則?

·         有:當前的資料庫是否匹配binlog-do-db規則?

o        有:寫入敘述並退出。

o        沒有:不要寫入敘述,退出。

·         No:執行下一步。

4.    有一些binlog-ignore-db規則。當前的資料庫是否匹配binlog-ignore-db規則?

·         有:不要寫入敘述,並退出。

·         沒有:寫入查詢並退出。

例如,只用binlog-do-db=sales運行的伺服器不將當前資料庫不為sales的敘述寫入二進制日誌(換句話說,binlog-do-db有時可以資料表示「忽視其它資料庫」)。

如果您正進行複製,應確保沒有從伺服器在使用舊的二進制日誌檔案,方可刪除它們。一種方法是每天一次執行mysqladmin flush-logs並刪除三天前的所有日誌。可以手動刪除,或最好使用PURGE MASTER LOGS(參見13.6.1節,「用於控制主伺服器的SQL語句」),該敘述還會安全地更新二進制日誌索引檔案(可以採用日期參數)。

具有SUPER權限的客戶端可以通過SET SQL_LOG_BIN=0敘述禁止將自己的敘述記入二進制記錄。參見13.5.3節,「SET語法」

您可以用mysqlbinlog實用工具檢查二進制日誌檔案。如果您想要重新處理日誌止的敘述,這很有用。例如,可以從二進制日誌更新MySQL伺服器,方法如下:

shell> mysqlbinlog log-file | mysql -h server_name

關於mysqlbinlog實用工具的詳細訊息以及如何使用它,參見8.6節,「mysqlbinlog:用於處理二進制日誌檔案的實用工具」

如果您正使用交易,必須使用MySQL二進制日誌進行備份,而不能使用舊的更新日誌。

查詢結束後、鎖定被釋放前或提交完成後則立即記入二進制日誌。這樣可以確保按執行順序記入日誌。

對非交易資料表的更新執行完畢後立即保存到二進制日誌中。對於交易資料表,例如BDB或InnoDB資料表,所有更改資料表的更新(UPDATE、DELETE或INSERT) 被緩存起來,直到伺服器接收到COMMIT敘述。在該點,執行完COMMIT之前,mysqld將整個交易寫入二進制日誌。當處理交易的線程啟動時,它為緩衝查詢分配binlog_cache_size大小的內存。如果語句大於該值,線程則打開臨時檔案來保存交易。線程結束後臨時檔案被刪除。

Binlog_cache_use狀態變數顯示了使用該緩衝區(也可能是臨時檔案)保存語句的交易的數量。Binlog_cache_disk_use狀態變數顯示了這些交易中實際上有多少必須使用臨時檔案。這兩個變數可以用於將binlog_cache_size調節到足夠大的值,以避免使用臨時檔案。

max_binlog_cache_size(預設4GB)可以用來限制用來緩存多敘述交易的緩衝區總大小。如果某個交易大於該值,將會失敗並 回復。

如果您正使用更新日誌或二進制日誌,當使用CREATE … SELECT or INSERT … SELECT時,並行插入被轉換為普通插入。這樣通過在備份時使用日誌可以確保重新建立資料表的備份。

請注意MySQL 5.1值的二進制日誌格式與以前版本的MySQL不同,因為複製改進了。參見6.5節,「不同MySQL版本之間的複製相容性」

預設情況下,並不是每次寫入時都將二進制日誌與硬盤同步。因此如果作業系統或機器(不僅僅是MySQL伺服器)當機,有可能二進制日誌中最後的敘述丟失了。要想防止這種情況,您可以使用sync_binlog全局變數(1是最安全的值,但也是最慢的),使二進制日誌在每N次二進制日誌寫入後與硬盤同步。參見5.3.3節,「伺服器系統變數」。即使sync_binlog設置為1,出現當機時,也有可能資料表內容和二進制日誌內容之間存在不一致性。例如,如果使用InnoDB資料表,MySQL伺服器處理COMMIT敘述,它將整筆交易寫入二進制日誌並將交易提交到InnoDB中。如果在兩次操作之間出現當機事件,重啟時,交易被InnoDB回復,但仍然存在二進制日誌中。可以用–innodb-safe-binlog選項解決該問題,可以增加InnoDB資料表內容和二進制日誌之間的一致性。(註釋:在MySQL 5.1中不需要–innodb-safe-binlog;由於引入了XA事務支援,該選項作廢了)。

該選項可以提供更大程度的安全,還應對MySQL伺服器進行配置,使每個交易的二進制日誌(sync_binlog =1)和(預設情況為真)InnoDB日誌與硬盤同步。該選項的效果是當機後重啟時,在回復交易後,MySQL伺服器從二進制日誌剪切回復的InnoDB交易。這樣可以確保二進制日誌反饋InnoDB資料表的確切資料等,並使從伺服器保持與主伺服器保持同步(不接收 回復的敘述)。

請注意即使MySQL伺服器更新其它儲存引擎而不是InnoDB,也可以使用–innodb-safe-binlog。在InnoDB當機恢復時,只從二進制日誌中刪除影響InnoDB資料表的敘述/交易。如果當機恢復時MySQL伺服器發現二進制日誌變短了(即至少缺少一個成功提交的InnoDB交易),如果sync_binlog =1並且硬盤/檔案系統的確能根據需要進行同步(有些不需要)則不會發生,則輸出錯誤消息 (“二進制日誌<名>比期望的要小”)。在這種情況下,二進制日誌不準確,複製應從主伺服器的資料快照開始。

寫入二進制日誌檔案和二進制日誌索引檔案的方法與寫入MyISAM資料表相同。參見A.4.3節,「MySQL處理磁盤滿的方式」

2013-08-16_104610

這是MySQL 5實力養成暨評量裡的5-01.『在運算式中,COALESCE函式可傳回資料中第一個非NULL的值,試問執行SELECT COALESCE(NULL,1,2,3);結果為何?』

答案:(B) 1

請參閱MySQL ISNULL,這一題如果仔細看的法應該是有解的。

2013-08-16_104646

 

這是MySQL 5實力養成暨評量裡的3-97.『SQL語法中,UPDATE指令通常會搭配哪一個關鍵字使用?』

答案:(C) WHERE

在鬼月錯這樣的題目,真可說是鬼迷了心竅了,無語~

2013-08-16_104706

這是MySQL 5實力養成暨評量裡的4-26.『新增整數數值型態的欄位時,若指定欄位位數,例如:INT(5),此種型態,當新增數值的資料數超過五位時,但仍在INT的範圍內,此時有何作用?』

答案:(D) 沒有影響,仍寫入原值

再列一次連結MySQL 數值型態可以幫助大家瞭解這種題型的解題。

馬上成為工作達人的Fans

About ㄚ琪

工作達人Fun Taiwan的創辦者及總編,可以在這裡更認識他。

發表迴響

你的電子郵件位址並不會被公開。 Required fields are marked *

*

Scroll To Top

 好吃、好玩、旅遊、試吃、試用、邀稿、SEO

歡迎洽詢:flylinux@gmail.com

➨ 國外美食旅遊  日本東京自由行  美國猶他加州自由行  韓國釜山首爾慶州自由行 │ 泰國馬來西亞新加坡自由行  澳門廣東香港自由行日本九州奈良京阪自由行 │澳洲墨爾本坎培拉雪梨自由行 │中國北京自由行 

紅屋頂加級大阪難波飯店 (Red Roof Plus Osaka Namba) 日本大阪紅屋頂加級大阪難波飯店 (Red Roof Plus Osaka Namba)激推