mysql資料庫機制
方法如下:
1、首先打開Mysql命令行編輯器,連接Mysql資料庫;
(1)mysql資料庫機制擴展閱讀:
MySQL是一個關系型資料庫管理系統,由瑞典MySQL AB 公司開發,目前屬於Oracle旗下產品。MySQL 是最流行的關系型資料庫管理系統之一,在 WEB 應用方面,MySQL是最好的RDBMS(Relational Database Management System,關系資料庫管理系統) 應用軟體。
MySQL是一種關系資料庫管理系統,關系資料庫將數據保存在盯野不同的表中,而不是將所有數據放在一個大倉庫內,這樣就增加了速度並提高了靈活性。
MySQL所使用的 SQL 語言是用於訪問資料庫的最常用標准化語言。MySQL 軟體採用了雙授權政策,分為社區版和商業版,由於其體積小、速度快、總體擁有成本低,尤其是開放源碼這一特點,一般中小型網站的開發都選擇 MySQL 作為網站資料庫。
由於其社區版的性能卓越,搭配PHP和Apache可組成良好的開發環境。
與其他的大型資料庫,例如Oracle、DB2、SQL Server等相比,MySQL自有它的不足之處,但是這絲毫也沒有減少它受歡迎的程度。對於一般的個人使用者和中小型企業來說,MySQL提供的功能已經綽綽有餘,而且由於 MySQL是開放源碼軟體,因此可以大大降低總體擁有成本。
Linux作為操作系統,Apache或Nginx作為Web伺服器,MySQL 作為資料庫,PHP/Perl/Python作為伺服器端腳本解釋器。由於這四個軟體都是免費或開放源碼軟體(FLOSS),因此使用這種方式不用花一分錢(除開人工成本)就可以建立起一個穩定、免費的網站系統,被業界稱為「LAMP「或「LNMP」組合。
MyISAMMySQL 5.0 之前的默認資料庫引擎,最為常用。擁有較高的插入,查詢速度,但不支持事務
InnoDB事務型資料庫的首選引擎,支持ACID事務,支持行級鎖定, MySQL 5.5 起成為默認資料庫引擎
BDB源 自 Berkeley DB,事務型資料庫的另一種選擇,支持Commit 和Rollback 等其他事務特性
Memory所有數據置於內存的存儲引擎,擁有極高的插入,更新和查詢效率。但是會佔用和數據量成正比的內存空間。並且其內容會在 MySQL 重新啟動時丟失
Merge將一定數量的 MyISAM 表聯合而成一個整體,在超大規模數據存儲時很有用
Archive非常適合存儲大量的獨立的,作為歷史記錄的數據。因為它們不經常被讀取。Archive 擁有高效的插入速度,但其對查詢的支持相對較差
Federated將不同的 MySQL 伺服器聯合起來,邏輯上組成一個完整的資料庫。非常適合分布式應用
Cluster/NDB高冗餘的存儲引擎,用多台數據機器聯合提供服務以提高整體性能和安全源搭性。適合數據量大,安全和性能要求高的應用
CSV: 邏輯上由逗號分割數據的存儲引擎。它會在資料庫子目錄里為每個數據表創建一個 .csv 文件。這是一種普通文本文件,每個數據行佔用一個文本行。CSV 存儲引擎不支持索引。
BlackHole:黑洞引擎,寫入的任何數據都會消失,一般用於記錄 binlog 做復制的中繼
EXAMPLE 存儲引擎是一個不做任何事情的存根凱裂喊引擎。它的目的是作為 MySQL源代碼中的一個例子,用來演示如何開始編寫一個新存儲引擎。同樣,它的主要興趣是對開發者。EXAMPLE 存儲引擎不支持編索引。
另外,MySQL 的存儲引擎介面定義良好。有興趣的開發者可以通過閱讀文檔編寫自己的存儲引擎。
2. 什麼是Mysql資料庫,與其它資料庫的區別和特點是什麼
MySQL(發音為「mynbsp;essnbsp;cuenbsp;el「,不是「mynbsp;sequel「)是一種開放源代碼的關系型資料庫管理系統(RDBMS),MySQL資料庫系統使用最常用的資料庫管理語言--結構化查詢語言(SQL)進行資料庫管理。nbsp;nbsp;由於MySQL是開放源代碼的,因此任何人都可以在Generalnbsp;Publicnbsp;License的許可下下載並根據個性化的需要對其進行修改。MySQL因為其速度、可靠性和適應性而備受關注。大多數人都認為在不需要事務化處理的情況下,MySQL是管理內容最好的選擇。nbsp;nbsp;nbsp;nbsp;MySQL關系型資料庫於1998年1月發行第一個版本。它使用系統核心提供的多線程機制提供完全的多線程運行模式,提供了面向C、C++、nbsp;Eiffel、Java、Perl、PHP、Python以及Tcl等編程語言的編程介面(APIs),支持多種欄位類型並且提供了完整的操作符支持查詢中的SELECT和WHERE操作。nbsp;nbsp;nbsp;nbsp;MySQL開發組計劃於2001年中期公布MySQL4.0版本。在這個版本中將有以下新的特性被提供:新的表定義文件格式、高性能的數據復制功能、更加強大的全文搜索功能。在此之後,MySQL開發著希望提供安全的數據復制機制、在BeOS操作系統上的MySQL實現以及對延時關鍵字的定期刷新選項。隨著時間的推進,MySQL將對ANSInbsp;92/ANSInbsp;99標准完全兼容。MsSql----amp;gt;MicroSoftnbsp;nbsp;nbsp;Sqlnbsp;nbsp;nbsp;Server,需要money,而且很多呢。(大型項目用,大型網站用)nbsp;nbsp;nbsp;nbsp;MySql----amp;gt;免費的。速度快。可以用於小型項目。nbsp;mysql資料庫和oracle的區別和選擇:LAMP大會的時候我跟Yahoo的一個技術高管聊的時候,我問他Yahoo在選擇MySQL還是nbsp;Oracle的時候是怎麼考慮,他的答案令我非常驚訝。他說大部分的時候我們是會用MySQL的,因為它的性能已經達到我們的要求。但是什麼時候我們會選用Oracle呢,就是當我們需要存儲收費用戶的數據的時候。我就問為什麼,難道Oracle比MySQL穩定嗎?他說,這個倒沒有特別考慮。關鍵是如果使用Oracle的話,當出現問題的時候我們可以找到負責人,Oracle會負責事故的處理,但是如果用MySQL的話,我們找誰去?
3. 請簡要簡述MySQL的四大系統資料庫及其作用
MySQL 自帶了四個資料庫,如下:
mysql庫。是MySQL的核心資料庫,存儲用戶、許可權等信息
information_schema。存儲表、鎖等性能信息。元數據關於數據的數據,如資料庫名,表名,訪問許可權,庫表的數據類型,庫索引的信息等
sys。這個庫數據來源於performance_schema。目標是把performance_schema的復雜程度降低,讓DBA能更好的閱讀這個庫里的內容,讓DBA更快的了解DB的運行情況。
performance_schema。這個庫主要收集資料庫伺服器性能參數,用於監控伺服器在一個較低級別的過程中的資源消耗,資源等待等情況
4. MySQL資料庫優化(七)
為了能最小化磁碟I/O MyISAM 存儲引擎採用了很多資料庫系統使用的一種策略 它採用一種機制將最經常訪問的表保存在內存區塊中
對索引區塊來說 它維護著一個叫索引緩存(索引緩沖)的結構體 這個結構體中放著許多那些最常使用的索引區塊的緩沖區塊 對數據區塊來說 MySQL沒有使用特定的緩存 它依靠操作系統的本地文件系統緩存本章首先描述了 MyISAM 索引緩存的基本操作 然後討論在MySQL 中所做的改進 它提高了索引緩存性能 同時能更好地控制緩存操作
線程之間不再是串列地訪問索引緩存 多個線程可以並行地訪問索引緩存 可以設置多個索引緩存 同時也能指定數據表索引到特定的緩存中索引緩存機制對 ISAM 表同樣適用 不過 這種有效性正在減弱 自從MySQL 開始 MyISAM 表類型引進之後 ISAM 就不再建議使用了 MySQL 更是延續了這個趨勢 ISAM 類型默認被禁用了
可以通過系統變數 key_buffer_size 來控制索引緩存區塊的大小 如果這個值大小為 那麼就不使用緩存 當這個值小得於不足以分配區塊緩沖的最小數量( )時 也不會使用緩存
當索引緩存無法操作時 索引文件就只通過操作系統提供的本地文件系統緩沖來訪問(換言之 表索引區塊採用的訪問策略和數據區塊的一致)
一個索引區塊在 MyISAM 索引文件中數純升是一個連續訪問的單元 通常這個索引區塊的大小和B樹索引節點大小一樣薯老(索引在磁碟中是以B樹結構來表示的 這個樹的底部時葉子節點 葉子節點之上則是非葉子節點)
在索引緩存結構中所有的區塊大小都是一樣的 這個值可能等於 大於 或小於表的索引區塊大小 通常這兩個值是不一樣的
當必須訪問來自任何錶的索引區塊時 伺服器首先檢查在索引緩存中是否有可用的緩沖區塊 如果有 伺服器就訪問緩存中的數據 而非磁碟 就是說 它直接存取緩存 而不是存取磁碟 否則 伺服器選擇一個(多個)包含其它不同表索引區塊的緩存緩沖區塊 將它的內容替換成請求表的索引區塊的拷貝 一旦新的索引區塊在緩存中了 索引數據就可以存取了
當發生被選中要替換的區塊內容修改了的情況時 這個區塊就被認為 臟 了 那麼 在替換之前 它的內容就必須先刷新到它指向的標索引
通常伺服器遵循LRU(最近最少使用)策略 當要選擇替換的區塊時 它選擇最近最少使用的索引區塊 為了想要讓選擇變得更容易 索引緩存模塊會維護一個包含所有使用區塊特別的隊列(LRU鏈) 當一個區塊被訪問了 就把它放到隊列的最後位置 當區塊要被替換時 在隊列開始位置的區塊就是最近最少使用的 它就是第一候選刪除對象
共享訪問索引緩存
在MySQL 以前 訪問索引緩存是串列的 兩個線程不能並行地訪問索引緩存緩沖 伺服器處理一個訪問索引區塊的請求只能等它之前的請求處理完 結果 新的請求所需的索引區塊就不在任何索引緩存環沖區塊中 因為其他線程把包含這個索引區塊的緩沖給更新了
從MySQL 開始 伺服器支持共享方式訪問索引緩存
沒有正在被更新的緩沖可以被多個線程訪問
緩沖正被更新時 需要使用這個緩沖的線程只能等到更新完成之後
多個線程可以初始化需要替換緩存區塊的請求 只要它們不幹擾別的線程(也就是 它們請求不同的索引區塊 因此不同的緩存區塊被替換)
共享方式訪問索引緩存令伺服器明顯改善了吞吐量
多重索引緩存
共享訪問索引緩存改善了性能 卻不能完全消褲尺除線程間的沖突 它們仍然爭搶控制管理存取索引緩存緩沖的結構 為了更進一步減少索引緩存存取沖突 MySQL 提供了多重索引緩存特性 這能將不同的表索引指定到不同的索引緩存
當有多個索引緩存 伺服器在處理指定的 MyISAM 表查詢時必須知道該使用哪個 默認地 所有的 MyISAM 表索引都緩存在默認的索引緩存中 想要指定到特定的緩存中 可以使用 CACHE INDEX 語句
如下語句所示 指定表的索 t t 和 t 引緩存到名為 hot_cache 的緩存中
mysql>CACHEINDEXt t t INhot_cache; + + + + + |Table|Op|Msg_type|Msg_text| + + + + + |test t |assign_to_keycache|status|OK| |test t |assign_to_keycache|status|OK| |test t |assign_to_keycache|status|OK| + + + + +
注意 如果伺服器編譯支持存 ISAM 儲引擎了 那麼 ISAM 表也使用索引緩存機制 不過 ISAM 表索引只能使用默認的索引緩存而不能自定義
CACHE INDEX 語句中用到的索引緩存是根據用 SET GLOBAL 語句的參數設定的值或者伺服器啟動參數指定的值創建的 如下 mysql> SET GLOBAL keycache key_buffer_size= * ;想要刪除索引緩存 只需設置它的大小為 mysql> SET GLOBAL keycache key_buffer_size= ;索引緩存變數是一個結構體變數 由名字和組件構成 例如 keycache key_buffer_size keycache 就是緩存名 key_buffer_size 是緩存組件 默認地 表索引在伺服器啟動時指定到主(默認的)索引緩存中 當一個索引緩存被刪掉後 指定到這個緩存的所有索引都被重新指向到了默認索引緩存中去 對一個繁忙的系統來說 我們建議以下三條策略來使用索引緩存 熱緩存佔用 %的總緩存空間 用於繁重搜索但很少更新的表 冷緩存佔用 %的總緩存空間 用於中等強度更新的表 如臨時表 冷緩存佔用 %的總緩存空間 作為默認的緩存 用於所有其他表 使用三個緩存的一個原因是好處在於 存取一個緩存結構時不會阻止對其他緩存的訪問 訪問一個表索引的查詢不會跟指定到其他緩存的查詢競爭 性能提高還表現在以下幾點原因 熱緩存只用於檢索記錄 因此它的內容總是不需要變化 所以 無論什麼時候一個索引區塊需要從磁碟中引入 被選中要替換的緩存區塊的內容總是要先被刷新 索引被指向熱緩存中後 如果沒有需要掃描全部索引的查詢 那麼對應到B樹中非葉子節點的索引區塊極可能還保留在緩存中 在臨時表裡必須頻繁執行一個更新操作是相當快的 如果要被更新的節點已經在緩存中了 它無需先從磁碟中讀取出來 當臨時表的索引大小和冷緩存大小一樣時 那麼在需要更新一個節點時它已經在緩存中存在的幾率是相當高的
中點插入策略
默認地 MySQL 的索引緩存管理系統採用LRU策略來選擇要被清除的緩存區塊 不過它也支持更完善的方法 叫做 中點插入策略
使用中點插入策略時 LRU鏈就被分割成兩半 一個熱子鏈 一個溫子鏈 兩半分割的點不是固定的 不過緩存管理系統會注意不讓溫子鏈部分 太短 總是至少包括全部緩存區塊的 key_cache_division_limit 比率 key_cache_division_limit 是緩存結構體變數的組件部分 因此它是每個緩存都可以設置這個參數值
當一個索引區塊從表中讀入緩存時 它首先放在溫子鏈的末尾 當達到一定的點擊率(訪問這個區塊)後 它就提升到熱子鏈中去 目前 要提升一個區塊的點擊率( )對每個區塊來說都是一樣的 將來 我們會讓點擊率依靠B樹中對應的索引區塊節點的級別 包含非葉子節點的索引區塊所要求的提升點擊率就低一點 包含葉子節點的B索引樹的區塊的值就高點
提升起來的區塊首先放在熱子鏈的末尾 這個區塊在熱子鏈內一直循環 如果這個區塊在該子鏈開頭位置停留時間足夠長了 它就會被降級回溫子鏈 這個時間是由索引緩存結構體變數的組件 key_cache_age_threshold 值來決定的
這個閥值是這么描述的 一個索引緩存包含了 N 個區塊 熱子鏈開頭的區塊在低於 N*key_cache_age_threshold/ 次訪問後就被移動到溫子鏈的開頭位置 它又首先成為被刪除的候選對象 因為要被替換的區塊還是從溫子鏈的開頭位置開始的
中點插入策略就能在緩存中總能保持更有價值的區塊 如果更喜歡採用LRU策略 只需讓 key_cache_division_limit 的值低於默認值
中點插入策略能幫助改善在執行需要有效掃描索引 它會將所有對應到B樹中高級別的有價值的節點推出的查詢時的性能 為了避免這樣 就必須設定 key_cache_division_limit 遠遠低於 以採用中點插入策略 則在掃描索引操作時那些有價值的頻繁點擊的節點就會保留在熱子鏈中了
索引預載入
如果索引緩存中有足夠的區塊用來保存全部索引 或者至少足夠保存全部非葉子節點 那麼在使用前就載入索引緩存就很有意義了 將索引區塊以十分有效的方法預載入索引緩存緩沖 從磁碟中順序地讀取索引區塊
沒有預載入 查詢所需的索引區塊仍然需要被放到緩存中去 雖然索引區塊要保留在緩存中 因為有足夠的緩沖 它們可以從磁碟中隨機讀取到 而非順序地
想要預載入緩存 可以使用 LOAD INDEX INTO CACHE 語句 如下語句預載入了表 t 和 t 的索引節點(區塊)
mysql>LOADINDEXINTOCACHEt t IGNORELEAVES; + + + + + |Table|Op|Msg_type|Msg_text| + + + + + |test t |preload_keys|status|OK| |test t |preload_keys|status|OK| + + + + +
增加修飾語 IGNORE LEAVES 就只預載入非葉子節點的索引區塊 因此 上述語句載入了 t 的全部索引區塊 但是只載入 t 的非葉子節點區塊
如果使用 CACHE INDEX 語句將索引指向一個索引緩存 將索引區塊預先放到那個緩存中去 否則 索引區塊只會載入到默認的緩存中去
索引緩存大小
MySQL 引進了對每個索引緩存的新變數 key_cache_block_size 這個變數可以指定每個索引緩存的區塊大小 用它就可以來調整索引文件I/O操作的性能
當讀緩沖的大小和本地操作系統的I/O緩沖大小一樣時 就達到了I/O操作的最高性能了 但是設置索引節點的大小和I/O緩沖大小一樣未必能達到最好的總體性能 讀比較大的葉子節點時 伺服器會讀進來很多不必要的數據 這大大阻礙了讀其他葉子節點
目前 還不能控制數據表的索引區塊大小 這個大小在伺服器創建索引文件 ` MYI 時已經設定好了 它根據數據表的索引大小的定義而定 在很多時候 它設置成和I/O緩沖大小一樣 在將來 可以改變它的值 並且會全面採用變數 key_cache_block_size
重建索引緩存
索引緩存可以通過修改其參數值在任何時候重建它 例如
mysql>SETGLOBALcold_cache key_buffer_size= * * ;
如果設定索引緩存的結構體變數組件變數 key_buffer_size 或 key_cache_block_size 任何一個的值和它當前的值不一樣 伺服器就會清空原來的緩存 在新的變數值基礎上重建緩存 如果緩存中有任何的 臟 索引塊 伺服器會先把它們保存起來然後才重建緩存 重新設定其他的索引緩存變數並不會重建緩存
lishixin/Article/program/Oracle/201311/16615