mysql ocp 题库部分解析
question 1:
知識點:
(1).set global sql_skip_slave_counter=1 ? 使slave跳過1個錯誤事務
5.6版本之后會報錯,因為是通過GTID來進行復制的,也需要跳過這個事務從而繼續復制,這個事務可以到主上的binlog里面查看:因為不知道找哪個GTID上出錯,所以也不知道如何跳過哪個GTID。但在show slave status里的信息里可以找到在執行Master里的POS
(2).生成gtid ,
set session gtid_next='4e659069-3cd8-11e5-9a49-001c4270714e:1';?
注入空事務
begin; commit;
然后改回默認值
gtid_next = "AUTOMATIC" 默認值
question 4:
知識點:
Numeric Type Storage Requirements
| TINYINT | 1 byte |
| SMALLINT | 2 bytes |
| MEDIUMINT | 3 bytes |
| INT ,? INTEGER | 4 bytes |
| BIGINT | 8 bytes |
| FLOAT( p ) | 4 bytes if 0 <=? p ?<= 24, 8 bytes if 25 <=? p ?<= 53 |
| FLOAT | 4 bytes |
| DOUBLE [PRECISION] ,? REAL | 8 bytes |
| DECIMAL( M , D ) ,? NUMERIC( M , D ) | Varies; see following discussion |
| BIT( M ) | approximately ( M +7)/8 bytes |
question 6:
A錯,load data infile針對的是select ... into oufile輸出的表數據文件,其文件中不含有插入執行語句,僅含有數據。而mysqldump導出的文件包含的數據是以可執行sql語句實現的。
B錯, 漏掉了< ?正確應該是:
Shell> mysql –u root –p sakila < sakila2013.sql
C錯,因為mysqlimport是類似于load data infile語句功能的shell命令行工具,因此對應倒入的文件都應該是非sql語句執行的純表數據文件。
E錯. mysql命令項使用中,短項使用單橫杠,長命令項使用雙橫杠 -silent項應該時候雙橫杠,因此錯。
question 9 :
分析:這是一個讀密集型數據庫,數據庫會在一段時間后刷新,但是其查詢的結果集大小波動不大。而所有結果集都在Query Cache中,且網頁應用使用一套有限的查詢語句。且Query Cache hit rate很高。
因此A,D錯,請求通過的應用查詢,查詢語句數量有限,結果集都能放在Query Cache中,相同查詢語句的請求不會增多Query Cache中的資源的占用,因此清理查詢并非主要矛盾。
B也錯,因此Query_cache_min_res_unit設置過大,僅會造成Query Cache中碎片過多。如果請求的結果集都能在Query Cache中,這就和碎片沒什么關系了。
C正確,盡管官方文檔中未大量解釋Query Cache Mutex爭用問題,在線程運行查詢語句時,會在Query Cache中先獲取Mutex鎖,之后開始查詢匹配的查詢語句和結果集。如果找到后返回結果。
如果未找到匹配,在執行查詢后,需要將查詢語句和結果集插入Query Cache中,這也會需要獲取鎖。盡管這個時間所需非常短,但是在讀密集的情況下,資源爭用會導致線程排隊等待現象。
知識點:
(1).查詢緩存并沒有能起到提升性能的做用
如果何配置查詢緩存:
query_cache_type 這個系統變量控制著查詢緩存工能的開啟的關閉。
query_cache_type=0時表示關閉,1時表示打開,2表示只要select 中明確指定SQL_CACHE才緩存。
這個參數的設置有點奇怪,1、如果事先查詢緩存是關閉的然而用 set @@global.query_cache_type=1; 會報錯
ERROR 1651 (HY000): Query cache is disabled; restart the server with query_cache_type=1 to enable it
2、如果事先是打開著的嘗試去閉關它,那么這個關閉也是不完全的,這種情況下查詢還是會去嘗試查找緩存。
最好的關閉查詢緩存的辦法就是把my.cnf 中的query_cache_type=0然后再重啟mysql。
查詢緩存相關的系統變量:
have_query_cache 表示這個mysql版本是否支持查詢緩存。
query_cache_limit 表示單個結果集所被允許緩存的最大值。
query_cache_min_res_unit 每個被緩存的結果集要占用的最小內存。
query_cache_size 用于查詢緩存的內存大小。
如何監控查詢緩存的命中率:?
Qcache_free_memory 查詢緩存目前剩余空間大小。
Qcache_hits ? ? 查詢緩存的命中次數。
Qcache_inserts 查詢緩存插入的次數。
也就是說緩存的命中率為 Qcache_hits/(Qcache_hits+Qcache_inserts)
(2).
mysql使用總內存 = global_buffers + all_thread_buffers
global_buffers ( 全局內存分配總和 ) =
innodb_buffer_pool_size -- InnoDB高速緩沖,行數據、索引緩沖,以及事務鎖、自適應哈希等
+innodb_additional_mem_pool_size -- InnoDB數據字典額外內存,緩存所有表數據字典
+innodb_log_buffer_size -- InnoDB REDO日志緩沖,提高REDO日志寫入效率
+key_buffer_size -- MyISAM表索引高速緩沖,提高MyISAM表索引讀寫效率
+query_cache_size -- 查詢高速緩存,緩存查詢結果,提高反復查詢返回效率
+table_cahce -- 表空間文件描述符緩存,提高數據表打開效率
+table_definition_cache -- 表定義文件描述符緩存,提高數據表打開效率
all_thread_buffers (會話/線程級內存分配總和) =
max_threads(當前活躍連接數) * (
read_buffer_size -- 順序讀緩沖,提高順序讀效率
+read_rnd_buffer_size -- 隨機讀緩沖,提高隨機讀效率
+sort_buffer_size -- 排序緩沖,提高排序效率
+join_buffer_size -- 表連接緩沖,提高表連接效率
+binlog_cache_size -- 二進制日志緩沖,提高二進制日志寫入效率
+tmp_table_size -- 內存臨時表,提高臨時表存儲效率
+thread_stack -- 線程堆棧,暫時寄存SQL語句/存儲過程
+thread_cache_size -- 線程緩存,降低多次反復打開線程開銷
+net_buffer_length -- 線程持連接緩沖以及讀取結果緩沖
+bulk_insert_buffer_size ) -- MyISAM表批量寫入數據緩沖
(3). 內存碎片
query_cache_min_res_unit ? ?查詢緩存分配的最小塊的大小(字節),默認為4k
query_alloc_block_size ? ?為查詢分析和執行過程中創建的對象分配的內存塊大小
Qcache_free_blocks ? ?代表內存自由塊的多少,反映了內存碎片的情況
==========================
1)當查詢進行的時候,Mysql把查詢結果保存在qurey cache中,但如果要保存的結果比較大,超過query_cache_min_res_unit的值 ,這時候mysql將一邊檢索結果,一邊進行保存結果,所以,有時候并不是把所有結果全部得到后再進行一次性保存,而是每次分配一塊 query_cache_min_res_unit 大小的內存空間保存結果集,使用完后,接著再分配一個這樣的塊,如果還不不夠,接著再分配一個塊,依此類推,也就是說,有可能在一次查詢中,mysql要 進行多次內存分配的操作。
2)內存碎片的產生。當一塊分配的內存沒有完全使用時,MySQL會把這塊內存Trim掉,把沒有使用的那部分歸還以重 復利用。比如,第一次分配4KB,只用了3KB,剩1KB,第二次連續操作,分配4KB,用了2KB,剩2KB,這兩次連續操作共剩下的 1KB+2KB=3KB,不足以做個一個內存單元分配, 這時候,內存碎片便產生了。
3)使用flush query cache,可以消除碎片
4)如果Qcache_free_blocks值過大,可能是query_cache_min_res_unit值過大,應該調小些
5)query_cache_min_res_unit的估計值:(query_cache_size - Qcache_free_memory) / Qcache_queries_in_cache
question 10:
MySQL-mysql_config_editor安全登錄工具
mysql_config_editor出現在mysql5.6.6以后的版本,可以給指定的連接和密碼生成一個加密文件.mylogin.cnf,默認位于當前用戶家目錄下。通過該文件可以使用mysql、mysqladmin等直接登錄,避免明文密碼出現在腳本中。
notice:使用該特性要求當前主機的mysql版本在5.6.6版本及以上,對將要登陸的mysql服務器版本沒有要求。
Usage:
生成加密文件:
[root@master ~]# mysql_config_editor set --login-path=jjscj --host=192.168.1.190 --user=jjscj --password?
Enter password:
[root@master ~]# ll ~/.mylogin.cnf?
-rw------- 1 root root 248 Aug 28 14:58 /root/.mylogin.cnf
使用加密文件登錄:
[root@master ~]# mysql --login-path=jjscj?
Welcome to the MySQL monitor.
查看當前主機上的加密文件:
[root@master ~]# mysql_config_editor print --all?
[local]?
user = root?
password = *****?
host = localhost?
[jjscj]?
user = jjscj?
password = *****?
host = 192.168.1.190
[remote]
user = jjscj
password = *****
host = 192.168.1.190
刪除某個加密登陸:
[root@master ~]# mysql_config_editor remove --login-path=remote?
[root@master ~]# mysql_config_editor print --all?
[local]?
user = root?
password = *****?
host = localhost?
[jjscj]?
user = jjscj?
password = *****?
host = 192.168.1.190
重置所有:
[root@master ~]# mysql_config_editor reset?
question 11:
PURGE { BINARY | MASTER } LOGS
{ TO 'log_name' | BEFORE datetime_expr }
PURGE BINARY LOGS TO 'mysql-bin.000002';
PURGE BINARY LOGS BEFORE '2014-04-28 23:59:59';
question 12:
知識點:
innodb_autoinc_lock_mode = 0 (傳統鎖模式)
保持了MySQL 5.1版本中相同的行為, 向后兼容.
在這種鎖模式下, 所有"INSERT"語句在插入表AUTO-INCREMENT列時獲取表級別的AUTO-INC鎖, 該鎖會持有到語句執行結束(而非事務結束), 確保auto-increment值以可預期, 可重復, 連續的序列順序分配給INSERT語句
在SBR主備同步模式下, 可以保證同一條SQL語句復制到備庫時可以產生和主庫相同的auto-increment值. Multiple-INSRT語句在備庫執行產生確定性的結果, 就如在主庫上執行的一樣. 如果Multiple-INSRT語句產生的auto-increment值是交錯的, 那么并發的兩條INSERT語句將產生不確定性的結果, 那么也就不能可靠的使用SBR模式復制主備數據同步.
innodb_autoinc_lock_mode = 1 (連續鎖模式)
這是InnoDB默認的鎖模式.
"Bulk inserts"使用特殊的AUTO-INC table-level lock, 并且持有鎖到語句結束. 包括所有的INSERT...SELECT, REPLACE...SELECT, 以及LOAD DATA語句. 同一時刻只有一個語句可以持有AUTO-INC table-level lock.
"Simple inserts"避免le使用table-level AUTO-INC lock, 而是使用互斥鎖(mutex, 更輕量級鎖)控制獲取需要的auto-increment值, 只有在分配auto-increment值期間持有, 并不是語句執行結束. 如果有事務持有table-level AUTO-INC lock, 那么"Simple inserts"將會向"Bulk inserts"一樣等待AUTO-INC lock.
這個鎖模式確保了所有"INSER-like"語句產生連續的auto-increment值(包括哪些事先不確定插入行數的"INSERT"語句), 這些操作在SBR模式數據復制時都是安全的.
簡單來說, 這個鎖模式明顯的提升了在使用SBR復制時的可擴展性以及安全性. 更深入的, 像"傳統鎖模式"那樣對于特定的SQL語句分配的auto-increment值是連續的.
一個例外是"Mixed-mode inserts", 用戶指定了一些auto-increment值, 有些則沒有指定, "Simple inserts"插入多行數據. 對這些插入, InnoDB分配了比插入行數更多的auto-increment值. 所有auto-increment自動的連續產生(所有比最近之前執行的語句的auto-increment值大), 剩余沒用的auto-increment值就忽略(丟失)不用了.
innodb_autoinc_lock_mode = 2 (交錯鎖模式)
這個鎖模式下, 所有"INSERT-like"語句不使用table-level AUTO-INC lock, 同一時刻SQL語句可以并發執行. 這是最快的, 更高擴展性的鎖模式, 但是在使用SBR復制或者恢復場景中回放binary log時卻是不安全的.
這個鎖模式下, auto-increment值在所有并發執行的"INSERT-like"語句中保持唯一以及單調增長. 同一時刻多條SQL語句產生的交錯的auto-increment值.
如果只有"Simple inserts"執行, 那么將不會產生的間隙的auto-increment值(排除"Mixdex-mode inserts"); 當執行"Bulk-inserts"時, 任何執行的SQL都可能產生間隙的auto-increment值.
詳細請參考:? http://www.cnblogs.com/renolei/p/5559135.html
question 19:
知識點:
Default-authentication-plugin
mysql_native_password(使用MySQL本地密碼)和sha256_password(用SHA-256 密碼)
添加該參數后,原有用戶不受影響,任何創建新賬號的語句,如果沒有加密的密碼哈希值用于要求hash 格式的默認身份認證插件,該語句執行將失敗。
CREATE USER ... IDENTIFIED BY 'encrypted password'; GRANT ... IDENTIFIED BY 'encrypted password';
注意:如果你使用該選項修改默認身份認證方法而不是mysql_native_password,MySQL5.6.6之前版本的客戶端不能連接。因為它們不明白身份認證協議的改變。
question 21:
知識點:
mysql_secure_installation
編譯安裝完mysql5.6,如果用于生產環境,最好執行mysql_secure_installation來做一些常規化安全設置。
需要提前將~mysql/bin加入環境變量
/apps/mysql/bin/mysql_secure_installation
(1).提示輸入密碼,沒有密碼就直接回車
(2).提示設置root user密碼 ?Y
(3).生產環境建議刪除系統創建的匿名用戶 ?Y
(4).禁止root用戶遠程登錄 ?Y
(5).刪除test數據庫 ?Y
(6).重載權限表 ?Y
question 24:
知識點:
MEMORY 存儲引擎只包含.frm表結構文件。 數據保存在內存中。重啟后數據將會丟失。
InnoDB:支持事務處理,支持外鍵,支持崩潰修復能力和并發控制。如果需要對事務的完整性要求比較高(比如銀行),要求實現并發控制(比如售票),那選擇InnoDB有很大的優勢。如果需要頻繁的更新、刪除操作的數據庫,也可以選擇InnoDB,因為支持事務的提交(commit)和回滾(rollback)。?
MyISAM:插入數據快,空間和內存使用比較低。如果表主要是用于插入新記錄和讀出記錄,那么選擇MyISAM能實現處理高效率。如果應用的完整性、并發性要求比 較低,也可以使用。
MEMORY:所有的數據都在內存中,數據的處理速度快,但是安全性不高。如果需要很快的讀寫速度,對數據的安全性要求較低,可以選擇MEMOEY。它對表的大小有要求,不能建立太大的表。所以,這類數據庫只使用在相對較小的數據庫表。
question 29:
知識點:
(1).flush logs
主要是關閉當前的二進制日志文件并創建一個新文件,新的二進制日志文件的名字在當前的二進制文件的編號上加1。
命令需要reload權限
在mysql中flush logs操作會生成一個新的binlog文件,如果在slave庫執行則同時會生成一個新的replay log
當刪除slow log或者general log,然后執行flush logs,此時會再重新生成一個新的slow log或者general log
(2).其他flush 命令
flush hosts 主要是用來清空主機緩存表。如果你的某些主機改變IP數字,或如果你得到錯誤消息Host … isblocked,你應該清空主機表。當在連接MySQL服務器時,對一臺給定的主機有多于 max_connect_errors個錯誤連續不斷地發生,MySQL為了安全的需要將會阻止該主機進一步的連接請求。清空主機表允許主機再嘗試連接。
flush privileges 主要是每當重新賦權后,為了以防萬一,讓新權限立即生效,一般都執行一把,目地是從數據庫授權表中重新裝載權限到緩存中。
flush tables 主要是關閉所有打開的表,同時該操作將會清空查詢緩存中的內容。
flush tables with read lock 主要是關閉所有打開的表,同時對于所有數據庫中的表都加一個讀鎖,直到顯示地執行unlock tables,該操作常常用于數據備份的時候。
flush status 重置大多數狀態變量到0。
flush master 刪除所有的二進制日志索引文件中的二進制日志文件,重置二進制日志文件的索引文件為空,創建一個新的二進制日志文件,不過這個已經不推薦使用,改成reset master 了。可以想象,以前自己是多土啊,本來一條簡單的命令就可以搞定的,卻要好幾條命令來,以前的做法是先查出來當前的二進制日志文件名,再用purge 操作。
flush query cache 重整查詢緩存,消除其中的碎片,提高性能,但是并不影響查詢緩存中現有的數據,這點和Flush table 和Reset Query? Cache(將會清空查詢緩存的內容)不一樣的。
flush slave? 類似于重置復制吧,讓從數據庫忘記主數據庫的復制位置,同時也會刪除已經下載下來的relay log,與Master一樣,已經不推薦使用,改成Reset Slave了。
question 30:
知識點:
frm、MYD、MYI是myisam引擎表的結構文件,數據文件,索引文件
備份過程參考: http://blog.itpub.net/15412087/viewspace-2152876/
question 31:
A ?在INNODB共享表空間上統計和總結表頁面非常耗時
B ?收集信息需要多種多樣的磁盤級操作,這個非常耗時
C ?查詢語句中的聚合函數功能在收集來自各個存儲引擎緩存細節從而得到結果的過程非常耗時
D ?收集信息需要大量的來自不同schema下的表的鎖,從而引發爭議點
question 34:
B --skip-networking 開啟后將關閉tcp/ip 不能遠程訪問mysql
D?為安全考慮希望指定的IP訪問MySQL,可以在配置文件中增加bind-address=IP,前提是關閉skip-networking
question 39:
知識點:
(1).master.info 和 relay.info 分別記錄接收主庫binlog的位置,和從庫應用binlog的位置
(2).relay index file 記錄當前relay-log的文件位置
(3).slave_master_info 和 slave_relay_log_info Table作用等同于(1)的兩個文件。可以避免寫文件的壓力。
question 40:
/etc/init.d/mysql stop
mysqladmin -u root -p shutdown
net stop mysql
question 41:
知識點:
DELAY_KEY_WRITE是指在表關閉之前,將對表的update操作只更新數據到磁盤,而不更新索引到磁盤,把對索引的更改記錄在內存。(這個選項的作用是暫時制止MySQL在該命令每插入一條新記錄和每修改一條現有之后立刻對索引進行刷新,對索引的刷新將等到全部記錄插入/修改完畢之后再進行)
??????? 這樣MyISAM表可以使索引更新更快。在關閉表的時候一起更新索引到磁盤。
場景:表有update操作,duang duang的體現出優勢了。因為這個參數能延遲更新索引到表關閉。經常更新一個大表的時候,可以用這個參數
小提示:當DELAY_KEY_WRITE使用的時候,如果出現重啟或者掉電啥的情況,會導致在cache的索引update沒來得及更新,所以必須在啟動參數加上 --myisam-recover,這樣在你啟動mysql的時候會檢查你的表并同步表和索引.或者在重啟服務器之前運行myisamchk。使用該特性,應用--myisam-recover選項啟動服務器,為所有MyISAM表添加自動檢查。
question 45:
知識點:
validate-password=ON/OFF/FORCE/FORCE_PLUS_PERMANENT: 決定是否使用該插件(及強制/永久強制使用)。
validate_password_dictionary_file:插件用于驗證密碼強度的字典文件路徑。
validate_password_length:密碼最小長度。
validate_password_mixed_case_count:密碼至少要包含的小寫字母個數和大寫字母個數。
validate_password_number_count:密碼至少要包含的數字個數。
validate_password_policy:密碼強度檢查等級,0/LOW、1/MEDIUM、2/STRONG。
validate_password_special_char_count:密碼至少要包含的特殊字符數。
其中,關于validate_password_policy-密碼強度檢查等級:
0/LOW:只檢查長度。
1/MEDIUM:檢查長度、數字、大小寫、特殊字符。
2/STRONG:檢查長度、數字、大小寫、特殊字符字典文件。
question 47:
直直接運行mysqld程序來啟動MySQL服務的方法很少見,mysqld_safe腳本會在啟動MySQL服務器后繼續監控其運行情況,并在其死機時重新啟動它。用mysqld_safe腳本來啟動MySQL服務器的做法在BSD風格的unix系統上很常見,非BSD風格的UNIX系統中的 mysql.server腳本其實也是調用mysqld_safe腳本去啟動MySQL服務器的。
question 48:
知識點:
SQL_MODE可能是比較容易讓開發人員和DBA忽略的一個變量,默認為空。SQL_MODE的設置其實是比較冒險的一種設置,因為在這種設置下可以允許一些非法操作,比如可以將NULL插入NOT NULL的字段中,也可以插入一些非法日期,如“2012-12-32”。因此在生產環境中強烈建議開發人員將這個值設為嚴格模式,這樣有些問題可以在數據庫的設計和開發階段就能發現,而如果在生產環境下運行數據庫后發現這類問題,那么修改的代價將變得十分巨大。此外,正確地設置SQL_MODE還可以做一些約束(Constraint)檢查的工作。
對于SQL_MODE的設置,可以在MySQL的配置文件如my.cnf和my.ini中進行,也可以在客戶端工具中進行,并且可以分別進行全局的設置或當前會話的設置。下面的命令可以用來查看當前SQL_MODE的設置情況。
STRICT_ALL_TABLES:對所有引擎的表都啟用嚴格模式。(STRICT_TRANS_TABLES只對支持事務的表啟用嚴格模式)。
question 49:
A 修復innodb存儲引擎,參考 https://blog.csdn.net/l1028386804/article/details/77199194
B&C CHECK TABLE & REPAIR TABLE用于修復被破壞的表。默認情況下,REPAIR TABLE與myisamchk --recovertbl_name具有相同的效果。REPAIR TABLE對MyISAM和ARCHIVE表起作用。
question 58:
知識點:
CREATE [OR REPLACE] [ALGORITHM = {UNDEFINED | MERGE | TEMPTABLE}]
? ? VIEW view_name [(column_list)]
? ? AS select_statement
? ? [WITH [CASCADED | LOCAL] CHECK OPTION]
視圖定義服從下述限制:
·SELECT語句不能包含FROM子句中的子查詢。
·SELECT語句不能引用系統或用戶變量。
·SELECT語句不能引用預處理語句參數。
·在存儲子程序內,定義不能引用子程序參數或局部變量。
·在定義中引用的表或視圖必須存在。但是,創建了視圖后,能夠舍棄定義引用的表或視圖。要想檢查視圖定義是否存在這類問題,可使用CHECK TABLE語句。
·在定義中不能引用TEMPORARY表,不能創建TEMPORARY視圖。
·在視圖定義中命名的表必須已存在。
·不能將觸發程序與視圖關聯在一起。
可選的ALGORITHM子句是對標準SQL的MySQL擴展。ALGORITHM可取三個值:MERGE、TEMPTABLE或UNDEFINED。如果沒有ALGORITHM子句,默認算法是UNDEFINED(未定義的)。
對于MERGE,會將引用視圖的語句的文本與視圖定義合并起來,使得視圖定義的某一部分取代語句的對應部分。
對于TEMPTABLE,視圖的結果將被置于臨時表中,然后使用它執行語句。
對于UNDEFINED,MySQL將選擇所要使用的算法。如果可能,它傾向于MERGE而不是TEMPTABLE,這是因為MERGE通常更有效,而且如果使用了臨時表,視圖是不可更新的。
MERGE算法要求視圖中的行和基表中的行具有一對一的關系。如果不具有該關系。必須使用臨時表取而代之。如果視圖包含下述結構中的任何一種,將失去一對一的關系:
·聚合函數(SUM(), MIN(), MAX(), COUNT()等)。
·DISTINCT
·GROUP BY
·HAVING
·UNION或UNION ALL
·僅引用文字值(在該情況下,沒有基本表)。
某些視圖是可更新的。也就是說,可以在諸如UPDATE、DELETE或INSERT等語句中使用它們,以更新基表的內容。對于可更新的視圖,在視圖中的行和基表中的行之間必須具有一對一的關系。還有一些特定的其他結構,這類結構會使得視圖不可更新。更具體地講,如果視圖包含下述結構中的任何一種,那么它就是不可更新的:
·聚合函數(SUM(), MIN(), MAX(), COUNT()等)。
·DISTINCT
·GROUP BY
·HAVING
·UNION或UNION ALL
·位于選擇列表中的子查詢
·Join
·FROM子句中的不可更新視圖
·WHERE子句中的子查詢,引用FROM子句中的表。
·僅引用文字值(在該情況下,沒有要更新的基本表)。
·ALGORITHM = TEMPTABLE(使用臨時表總會使視圖成為不可更新的)。
關于可插入性(可用INSERT語句更新),如果它也滿足關于視圖列的下述額外要求,可更新的視圖也是可插入的
question 64:
默認,所有的臨時表都是被復制的,無論是否匹配--replicate-do-db, --replicate-do-table, or --replicate-wild-do-table,復制臨時表都會發生。但是,--replicate-ignore-table 和 --replicate-wild-ignore-table 兩個選項是用來忽略臨時表的。
如果你不想復制某些臨時表,請使用--replicate-wild-ignore-table 選項。如:--replicate-wild-ignore-table=foo%.bar%,意思是告訴slave線程不要復制匹配以foo開頭和以bar開頭的表。
question 66:
select into outfile用法
SELECT?...?FROM?TABLE_A INTO?OUTFILE?"/path/to/file" FIELDS?TERMINATED?BY?','?OPTIONALLY?ENCLOSED?BY?'"' LINES?TERMINATED?BY?'\n';
load data infile用法
LOAD?DATA?INFILE?"/path/to/file"?INTO?TABLE?table_name; 注意:如果導出時用到了FIELDS?TERMINATED?BY?','?OPTIONALLY?ENCLOSED?BY?'"'?LINES?TERMINATED?BY?'\n'語句,那么LODA時也要加上同樣的分隔限制語句。還要注意編碼問題。
mysqlimport用法
mysqlimport?-h?172.16.145.125?-u?ocetl?-pocetl?test??--fields-terminated-by='|'?'/home/ocetl/tmp_user_info.txt'?--columns='user_id,user_name,user_age,user_addr'?--local -h??mysql?ip地址 -u?用戶 -p?用戶名密碼 注意:-p與密碼之間不能有空格 test?數據庫名稱 --fields-terminated-by??文件中字段之間的分隔符 /home/ocetl/tmp_uesr_info.txt????文件在linux的本地路徑 --columns???要加載文件到表的字段名 --local?:從本地客戶端讀入輸入文件。
question 67:
知識點:
MySQL中內存分為全局內存和線程內存兩大部分 :
per_thread_buffers=(read_buffer_size+read_rnd_buffer_size+sort_buffer_size+thread_stack+join_buffer_size+binlog_cache_size +tmp_table_size)*max_connections global_buffers= innodb_buffer_pool_size+innodb_additional_mem_pool_size+innodb_log_buffer_size+key_buffer_size+query_cache_size total_memory=global_buffers+per_thread_buffers 全局緩存:
key_buffer_size: 決定索引處理的速度,尤其是索引讀的速度。默認值是16M,通過檢查狀態值Key_read_requests和Key_reads,可以知道key_buffer_size設置是否合理。比例key_reads / key_read_requests應該盡可能的低,至少是1:100,1:1000更好(上述狀態值可以使用'key_read%'獲得用來顯示狀態數據)。key_buffer_size只對MyISAM表起作用。即使你不使用MyISAM表,但是內部的臨時磁盤表是MyISAM表,也要使用該值。可以使用檢查狀態值'created_tmp_disk_tables'得知詳情。
innodb_buffer_pool_size: InnoDB使用該參數指定大小的內存來緩沖數據和索引,這個是Innodb引擎中影響性能最大的參數。
innodb_additional_mem_pool_size:指定InnoDB用來存儲數據字典和其他內部數據結構的內存池大小。缺省值是8M。通常不用太大,只要夠用就行,應該與表結構的復雜度有關系。如果不夠用,MySQL會在錯誤日志中寫入一條警告信息。
innodb_log_buffer_size: 指定InnoDB用來存儲日志數據的緩存大小,如果您的表操作中包含大量并發事務(或大規模事務),并且在事務提交前要求記錄日志文件,請盡量調高此項值,以提高日志效率。
query_cache_size: 是MySQL的查詢緩沖大小。(從4.0.1開始,MySQL提供了查詢緩沖機制)使用查詢緩沖,MySQL將SELECT語句和查詢結果存放在緩沖區中,今后對于同樣的SELECT語句(區分大小寫),將直接從緩沖區中讀取結果。根據MySQL用戶手冊,使用查詢緩沖最多可以達到238%的效率。通過檢查狀態值'Qcache_%',可以知道query_cache_size設置是否合理:如果Qcache_lowmem_prunes的值非常大,則表明經常出現緩沖不夠的情況,如果Qcache_hits的值也非常大,則表明查詢緩沖使用非常頻繁,此時需要增加緩沖大小;如果Qcache_hits的值不大,則表明你的查詢重復率很低,這種情況下使用查詢緩沖反而會影響效率,那么可以考慮不用查詢緩沖。此外,在SELECT語句中加入SQL_NO_CACHE可以明確表示不使用查詢緩沖。
線程緩存
每個連接到MySQL服務器的線程都需要有自己的緩沖。大概需要立刻分配256K,甚至在線程空閑時,它們使用默認的線程堆棧,網絡緩存等。事務開始之后,則需要增加更多的空間。運行較小的查詢可能僅給指定的線程增加少量的內存消耗,然而如果對數據表做復雜的操作例如掃描、排序或者需要臨時表,則需分配大約read_buffer_size,sort_buffer_size,read_rnd_buffer_size,tmp_table_size大小的內存空間。不過它們只是在需要的時候才分配,并且在那些操作做完之后就釋放了。有的是立刻分配成單獨的組塊。tmp_table_size 可能高達MySQL所能分配給這個操作的最大內存空間了。
read_buffer_size: 是MySQL讀入緩沖區大小。對表進行順序掃描的請求將分配一個讀入緩沖區,MySQL會為它分配一段內存緩沖區。read_buffer_size變量控制這一緩沖區的大小。如果對表的順序掃描請求非常頻繁,并且你認為頻繁掃描進行得太慢,可以通過增加該變量值以及內存緩沖區大小提高其性能。
sort_buffer_size: 是MySQL執行排序使用的緩沖大小。如果想要增加ORDER BY的速度,首先看是否可以讓MySQL使用索引而不是額外的排序階段。如果不能,可以嘗試增加sort_buffer_size變量的大小。
read_rnd_buffer_size: 是MySQL的隨機讀緩沖區大小。當按任意順序讀取行時(例如,按照排序順序),將分配一個隨機讀緩存區。進行排序查詢時,MySQL會首先掃描一遍該緩沖,以避免磁盤搜索,提高查詢速度,如果需要排序大量數據,可適當調高該值。但MySQL會為每個客戶連接發放該緩沖空間,所以應盡量適當設置該值,以避免內存開銷過大。
tmp_table_size: 是MySQL的臨時表緩沖大小。所有聯合在一個DML指令內完成,并且大多數聯合甚至可以不用臨時表即可以完成。大多數臨時表是基于內存的(HEAP)表。具有大的記錄長度的臨時表 (所有列的長度的和)或包含BLOB列的表存儲在硬盤上。如果某個內部heap(堆積)表大小超過tmp_table_size,MySQL可以根據需要自動將內存中的heap表改為基于硬盤的MyISAM表。還可以通過設置tmp_table_size選項來增加臨時表的大小。也就是說,如果調高該值,MySQL同時將增加heap表的大小,可達到提高聯接查詢速度的效果。
thread_stack : 主要用來存放每一個線程自身的標識信息,如線程id,線程運行時基本信息等等,我們可以通過 thread_stack 參數來設置為每一個線程棧分配多大的內存。?
join_buffer_size: 應用程序經常會出現一些兩表(或多表)Join的操作需求,MySQL在完成某些 Join 需求的時候(all/index join),為了減少參與Join的“被驅動表”的讀取次數以提高性能,需要使用到 Join Buffer 來協助完成 Join操作。當 Join Buffer 太小,MySQL 不會將該 Buffer 存入磁盤文件,而是先將Join Buffer中的結果集與需要 Join 的表進行 Join 操作,然后清空 Join Buffer 中的數據,繼續將剩余的結果集寫入此 Buffer 中,如此往復。這勢必會造成被驅動表需要被多次讀取,成倍增加 IO 訪問,降低效率。
binlog_cache_size: 在事務過程中容納二進制日志SQL 語句的緩存大小。二進制日志緩存是服務器支持事務存儲引擎并且服務器啟用了二進制日志(—log-bin 選項)的前提下為每個客戶端分配的內存,注意,是每個Client 都可以分配設置大小的binlog cache 空間。如果系統中經常會出現多語句事務的話,可以嘗試增加該值的大小,以獲得更好的性能。當然,我們可以通過MySQL 的以下兩個狀態變量來判斷當前的binlog_cache_size 的狀況:Binlog_cache_use 和Binlog_cache_disk_use。“max_binlog_cache_size”:和"binlog_cache_size"相對應,但是所代表的是binlog 能夠使用的最大cache 內存大小。當我們執行多語句事務的時候,max_binlog_cache_size 如果不夠大的話,系統可能會報出“ Multi-statement transaction required more than 'max_binlog_cache_size' bytes ofstorage”的錯誤。
其中需要注意的是:table_cache表示的是所有線程打開的表的數目,和內存無關。
question 69:
知識點:
https://www.jianshu.com/p/926169bbd544
question 70:
知識點:
log_output=‘FILE‘表示將日志存入文件,默認值是‘FILE‘ log_output=‘TABLE‘表示將日志存入數據庫,這樣日志信息就會被寫入到mysql.slow_log表中.
mysql數據庫支持同時兩種日志存儲方式,配置的時候以逗號隔開即可,如:log_output=‘FILE,TABLE‘.日志記錄到系統專用日志表中,要比記錄到文件耗費更多的系統資源,因此對于需要啟用慢查日志,又需要比夠獲得更高的系統性能,那么建議優先記錄到文件.
question 71:
參考: http://blog.itpub.net/15412087/viewspace-2152193/
question 72:
知識點:
頁級:引擎 BDB。
表級:引擎 MyISAM 和 MEMORY, 理解為鎖住整個表,可以同時讀,寫不行
行級:引擎 INNODB , 單獨的一行記錄加鎖
上述三種鎖的特性可大致歸納如下:
1) 表級鎖:開銷小,加鎖快;不會出現死鎖;鎖定粒度大,發生鎖沖突的概率最高,并發度最低。
2) 行級鎖:開銷大,加鎖慢;會出現死鎖;鎖定粒度最小,發生鎖沖突的概率最低,并發度也最高。
3) 頁面鎖:開銷和加鎖時間界于表鎖和行鎖之間;會出現死鎖;鎖定粒度界于表鎖和行鎖之間,并發度一般。
question 74:
知識點:
Mysql general日志
記錄所有執行過的語句,但是開啟后對于數據庫服務器的壓力影響比較嚴重.不太建議搭建日常開啟該日志,在某些情況下,比如統計匯總SQL,審計可以考慮暫時性的開啟general log,否則容易出現問題.
Mysql slow 日志
記錄執行超過時間閾值的SQL語句,用來判定執行比較慢的sql
binlog
不記錄 select show 等查詢語句,記錄dml ddl等數據庫變動的語句.
question 75:
知識點:
DRBD(DistributedReplicatedBlockDevice)是一個基于塊設備級別在遠程服務器直接同步和鏡像數據的軟件,用軟件實現的、無共享的、服務器之間鏡像塊設備內容的存儲復制解決方案。它可以實現在網絡中兩臺服務器之間基于塊設備級別的實時鏡像或同步復制(兩臺服務器都寫入成功)/異步復制(本地服務器寫入成功),相當于網絡的RAID1,由于是基于塊設備(磁盤,LVM邏輯卷),在文件系統的底層,所以數據復制要比cp命令更快。DRBD已經被MySQL官方寫入文檔手冊作為推薦的高可用的方案之一。
question 82:
--order-by-primary
如果存在主鍵,或者第一個唯一鍵,對每個表的記錄進行排序。在導出MyISAM表到InnoDB表時有效,但會使得導出工作花費很長時間。
question 83:
知識點:
The? SUPER ?privilege enables these operations and server behaviors:
-
Enables configuration changes by modifying global system variables. For some system variables, setting the session value also requires the? SUPER ?privilege; if so, it is indicated in the variable description. Examples include? binlog_format ,? sql_log_bin , and? sql_log_off .
-
Enables changes to global transaction characteristics (see? Section?13.3.6, “SET TRANSACTION Syntax” ).
-
Enables starting and stopping replication on slave servers.
-
Enables use of the? CHANGE MASTER TO ?statement.
-
Enables binary log control by means of the? PURGE BINARY LOGS ?and? BINLOG ?statements.
-
Enables setting the effective authorization ID when executing a view or stored program. A user with this privilege can specify any account in the? DEFINER ?attribute of a view or stored program.
-
Enables use of the? CREATE SERVER ,? ALTER SERVER , and? DROP SERVER ?statements.
-
Enables use of the? mysqladmin debug ?command.
-
Enables reading the DES key file by the? DES_ENCRYPT() ?function.
-
Enables control over client connections not permitted to non- SUPER ?accounts:
-
Enables use of the? KILL ?statement or? mysqladmin kill ?command to kill threads belonging to other accounts. (You can always kill your own threads.)
-
The server accepts one connection from a? SUPER ?client even if the connection limit controlled by the max_connections ?system variable is reached.
-
Updates can be performed even when the? read_only ?system variable is enabled. This applies to table updates and use of account-management statements such as? GRANT ?and? REVOKE .
-
The server does not execute? init_connect ?system variable content when? SUPER ?clients connect.
-
question 87:
知識點:
tmp_table_size
它規定了內部內存臨時表的最大值,每個線程都要分配。(實際起限制作用的是tmp_table_size和max_heap_table_size的最小值。)如果內存臨時表超出了限制,MySQL就會自動地把它轉化為基于磁盤的MyISAM表,存儲在指定的tmpdir目錄下
max_heap_table_size
這個變量定義了用戶可以創建的內存表(memory table)的大小.這個值用來計算內存表的最大行數值。這個變量支持動態改變,即set @max_heap_table_size=#
,但是對于已經存在的內存表就沒有什么用了,除非這個表被重新創建(create table)或者修改(alter table)或者truncate table。服務重啟也會設置已經存在的內存表為全局max_heap_table_size的值。
這個變量和tmp_table_size一起限制了內部內存表的大小。
*你可以比較內部基于磁盤的臨時表的總數和創建在內存中的臨時表的總數(Created_tmp_disk_tables和Created_tmp_tables),一般的比例關系是:
Created_tmp_disk_tables/Created_tmp_tables<5%
question 88:
知識點:
參考: https://www.cnblogs.com/mysql-dba/p/7061300.html
question 92:
知識點:
max_user_connections:限制每個用戶的session連接個數,例如max_user_connections=1 ,那么用戶u1只能連接的session數為1,如果還有用戶u2,還是可以連接,但是連接數仍然為1
max_connections :是對整個服務器的用戶限制,整個服務器只能開這么多session,而不考慮用戶!
question 93:
知識點:
參考: https://www.cnblogs.com/yycc/p/7338894.html
question 96:
知識點:
mysqldump --quick
不緩沖查詢,直接導出到標準輸出。默認為打開狀態,使用--skip-quick取消該選項
mysqldump --single-transaction
備份時保持一致性
mysqldump --tab
為每個表在給定路徑創建tab分割的文本文件。注意:僅僅用于mysqldump和mysqld服務器運行在相同機器上。
question 97:
知識點:
mysqldump --master-data
導出數據時,當這個參數的值為1的時候,mysqldump出來的文件就會包括CHANGE MASTER TO這個語句,CHANGE MASTER TO后面緊接著就是file和position的記錄,在slave上導入數據時就會執行這個語句,salve就會根據指定這個文件位置從master端復制binlog。默認情況下這個值是1
當這個值是2的時候,chang master to也是會寫到dump文件里面去的,但是這個語句是被注釋的狀態。
來自 “ ITPUB博客 ” ,鏈接:http://blog.itpub.net/15412087/viewspace-2168573/,如需轉載,請注明出處,否則將追究法律責任。
轉載于:http://blog.itpub.net/15412087/viewspace-2168573/
總結
以上是生活随笔為你收集整理的mysql ocp 题库部分解析的全部內容,希望文章能夠幫你解決所遇到的問題。
- 上一篇: php libiconv close_P
- 下一篇: 【SQL Server】用SQL命令建立