mysql數據庫四個特點,mysql數據庫的特點

本文目錄一覽：

• 1、mysql的特點
• 2、mysql的事務四個特性以及事務的四個隔離級別
• 3、mysql主要技術特點
• 4、mysql事務的四大特性是什麼？
• 5、MYSQL相比於其他數據庫有哪些特點
• 6、mysql的特點是什麼?

mysql的特點

1、支持多線程，充分利用 CPU 資源；

2、提供多語言支持，常見的編碼如中文的 GB 2312、BIG5；

3、支持大型的數據庫。可以處理擁有上千萬條記錄的大型數據庫；

4、支持多種存儲引擎；

5、開源的，不需要支付額外的費用；

6、MySQL 對 PHP 有很好的支持；

7、MySQL是可以定製的，採用了 GPL協議，可以修改源碼來開發自己的 MySQL 系統；

8、在線 DDL/更改功能，數據架構支持動態應用程序和開發人員靈活性。

mysql的事務四個特性以及事務的四個隔離級別

分別是原子性、一致性、隔離性、持久性。

原子性是指事務包含的所有操作要麼全部成功，要麼全部失敗回滾，因此事務的操作如果成功就必須要完全應用到數據庫，如果操作失敗則不能對數據庫有任何影響。

一致性是指事務必須使數據庫從一個一致性狀態變換到另一個一致性狀態，也就是說一個事務執行之前和執行之後都必須處於一致性狀態。舉例來說，假設用戶A和用戶B兩者的錢加起來一共是1000，那麼不管A和B之間如何轉賬、轉幾次賬，事務結束後兩個用戶的錢相加起來應該還得是1000，這就是事務的一致性。

隔離性是當多個用戶並發訪問數據庫時，比如同時操作同一張表時，數據庫為每一個用戶開啟的事務，不能被其他事務的操作所干擾，多個並發事務之間要相互隔離。關於事務的隔離性數據庫提供了多種隔離級別，稍後會介紹到。

持久性是指一個事務一旦被提交了，那麼對數據庫中的數據的改變就是永久性的，即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。例如我們在使用JDBC操作數據庫時，在提交事務方法後，提示用戶事務操作完成，當我們程序執行完成直到看到提示後，就可以認定事務已經正確提交，即使這時候數據庫出現了問題，也必須要將我們的事務完全執行完成。否則的話就會造成我們雖然看到提示事務處理完畢，但是數據庫因為故障而沒有執行事務的重大錯誤。這是不允許的。

在數據庫操作中，在並發的情況下可能出現如下問題：

正是為了解決以上情況，數據庫提供了幾種隔離級別。

數據庫事務的隔離級別有4個，由低到高依次為Read uncommitted(未授權讀取、讀未提交)、Read committed（授權讀取、讀提交）、Repeatable read（可重複讀取）、Serializable（序列化），這四個級別可以逐個解決臟讀、不可重複讀、幻象讀這幾類問題。

雖然數據庫的隔離級別可以解決大多數問題，但是靈活度較差，為此又提出了悲觀鎖和樂觀鎖的概念。

悲觀鎖，它指的是對數據被外界（包括本系統當前的其他事務，以及來自外部系統的事務處理）修改持保守態度。因此，在整個數據處理過程中，將數據處於鎖定狀態。悲觀鎖的實現，往往依靠數據庫提供的鎖機制。也只有數據庫層提供的鎖機制才能真正保證數據訪問的排他性，否則，即使在本系統的數據訪問層中實現了加鎖機制，也無法保證外部系統不會修改數據。

商品t_items表中有一個字段status，status為1代表商品未被下單，status為2代表商品已經被下單（此時該商品無法再次下單），那麼我們對某個商品下單時必須確保該商品status為1。假設商品的id為1。

如果不採用鎖，那麼操作方法如下：

但是上面這種場景在高並發訪問的情況下很可能會出現問題。例如當第一步操作中，查詢出來的商品status為1。但是當我們執行第三步Update操作的時候，有可能出現其他人先一步對商品下單把t_items中的status修改為2了，但是我們並不知道數據已經被修改了，這樣就可能造成同一個商品被下單2次，使得數據不一致。所以說這種方式是不安全的。

在上面的場景中，商品信息從查詢出來到修改，中間有一個處理訂單的過程，使用悲觀鎖的原理就是，當我們在查詢出t_items信息後就把當前的數據鎖定，直到我們修改完畢後再解鎖。那麼在這個過程中，因為t_items被鎖定了，就不會出現有第三者來對其進行修改了。需要注意的是，要使用悲觀鎖，我們必須關閉mysql數據庫的自動提交屬性，因為MySQL默認使用autocommit模式，也就是說，當你執行一個更新操作後，MySQL會立刻將結果進行提交。我們可以使用命令設置MySQL為非autocommit模式： set autocommit=0;

設置完autocommit後，我們就可以執行我們的正常業務了。具體如下：

上面的begin/commit為事務的開始和結束，因為在前一步我們關閉了mysql的autocommit，所以需要手動控制事務的提交。

上面的第一步我們執行了一次查詢操作： select status from t_items where id=1 for update; 與普通查詢不一樣的是，我們使用了 select…for update 的方式，這樣就通過數據庫實現了悲觀鎖。此時在t_items表中，id為1的那條數據就被我們鎖定了，其它的事務必須等本次事務提交之後才能執行。這樣我們可以保證當前的數據不會被其它事務修改。需要注意的是，在事務中，只有 SELECT … FOR UPDATE 或 LOCK IN SHARE MODE 操作同一個數據時才會等待其它事務結束後才執行，一般 SELECT … 則不受此影響。拿上面的實例來說，當我執行 select status from t_items where id=1 for update; 後。我在另外的事務中如果再次執行 select status from t_items where id=1 for update; 則第二個事務會一直等待第一個事務的提交，此時第二個查詢處於阻塞的狀態，但是如果我是在第二個事務中執行 select status from t_items where id=1; 則能正常查詢出數據，不會受第一個事務的影響。

使用 select…for update 會把數據給鎖住，不過我們需要注意一些鎖的級別，MySQL InnoDB默認Row-Level Lock，所以只有「明確」地指定主鍵或者索引，MySQL 才會執行Row lock (只鎖住被選取的數據) ，否則MySQL 將會執行Table Lock (將整個數據表單給鎖住)。舉例如下：

1、 select * from t_items where id=1 for update;

這條語句明確指定主鍵（id=1），並且有此數據（id=1的數據存在），則採用row lock。只鎖定當前這條數據。

2、 select * from t_items where id=3 for update;

這條語句明確指定主鍵，但是卻查無此數據，此時不會產生lock（沒有元數據，又去lock誰呢？）。

3、 select * from t_items where name=’手機’ for update;

這條語句沒有指定數據的主鍵，那麼此時產生table lock，即在當前事務提交前整張數據表的所有字段將無法被查詢。

4、 select * from t_items where id0 for update; 或者 select * from t_items where id1 for update; （註：在SQL中表示不等於）

上述兩條語句的主鍵都不明確，也會產生table lock。

5、 select * from t_items where status=1 for update; （假設為status字段添加了索引）

這條語句明確指定了索引，並且有此數據，則產生row lock。

6、 select * from t_items where status=3 for update; （假設為status字段添加了索引）

這條語句明確指定索引，但是根據索引查無此數據，也就不會產生lock。

樂觀鎖（ Optimistic Locking ） 相對悲觀鎖而言，樂觀鎖假設認為數據一般情況下不會造成衝突，所以只會在數據進行提交更新的時候，才會正式對數據的衝突與否進行檢測，如果發現衝突了，則返回用戶錯誤的信息，讓用戶決定如何去做。實現樂觀鎖一般來說有以下2種方式：

mysql主要技術特點

MySQL技術特點

（1）它使用的核心線程是完全多線程，支持多處理器。

（2）有多種列類型：1、2、3、4和8字節長度自有符號/無符號整數、FLOAT、DOUBLE、CHAR、VARCHAR、TEXT、BLOB、DATE、TIME、DATETIME、TIMESTAMP、YEAR和ENUM類似。

（3）它通過一個高度化的類庫實現SQL函數庫並像其一樣快速，通常在查詢初始化後不該有任何內存分配。沒有內存漏洞。

（4）全面支持SQL的GROUP BY 和ORDER BY 子句，支持聚合函數（COUNTO()、AVG()、STD()、SUM() 、MAX()和MIN()。你可以在同一查詢中來自不同數據庫的表。

（5）支持ANSI SQL的LEFTOUTER JON和ODBC。

（6）所有列都有默認值。你可以用INSERT插入一個表列的子集，那些沒有明確給定值的列設置為他們的默認值。

（7）MySQL可以工作在不同的平台上。支持C、C++、Java、Perl、PHP、Python和TCLAPI。

（8）利用優化的一遍掃描多重連接（one-sweepmulti-join）工具可以非常快速地進行網絡連接。

（9）通過高度優化的類庫實現SQL函數庫，通常在查詢初始化後沒有任何內存分配。

（10）可以在同一查詢中混用來自不同數據庫的表。

（11）靈活且安全的權限和口令系統，並且准許其他主機的認證，口令有較高的安全性，因為當與一個服務器連接時，所有傳送的口令都會被加密。

（12）大數據庫處理。可以對某些包含50,000,000個記錄的數據庫使用MySQL。

（13）沒有內存漏洞。

（14）所有MySQL程序可以使用“##help”或“_？”選項獲得聯機幫助。

（15）服務器能為客戶提供多種語言的出錯信息。

（16）客戶端使用TCP/IP連接或Linux(Socket)和NT下的命令管道連接MySQL。

（17）MySQL特有的show命令可用來檢索數據庫表和索引的信息，explain命令可用來確定優化器如何解決一個查詢。

mysql事務的四大特性是什麼？

1、原子性（Atomicity）原子性是指事務包含的所有操作要麼全部成功，要麼全部失敗回滾，因此事務的操作如果成功就必須要完全應用到數據庫，如果操作失敗則不能對數據庫有任何影響。

2、 一致性（Consistency）一致性是指事務必須使數據庫從一個一致性狀態變換到另一個一致性狀態，也就是說一個事務執行之前和執行之後都必須處於一致性狀態。

拿轉賬來說，假設用戶A和用戶B兩者的錢加起來一共是5000，那麼不管A和B之間如何轉賬，轉幾次賬，事務結束後兩個用戶的錢相加起來應該還得是5000，這就是事務的一致性。

3、隔離性（Isolation）隔離性是當多個用戶並發訪問數據庫時，比如操作同一張表時，數據庫為每一個用戶開啟的事務，不能被其他事務的操作所干擾，多個並發事務之間要相互隔離。

即要達到這麼一種效果：對於任意兩個並發的事務T1和T2，在事務T1看來，T2要麼在T1開始之前就已經結束，要麼在T1結束之後才開始，這樣每個事務都感覺不到有其他事務在並發地執行。

4、持久性（Durability）持久性是指一個事務一旦被提交了，那麼對數據庫中的數據的改變就是永久性的，即便是在數據庫系統遇到故障的情況下也不會丟失提交事務的操作。

擴展資料

MyISAMMySQL5.0之前的默認數據庫引擎，最為常用。擁有較高的插入，查詢速度，但不支持事務InnoDB事務型數據庫的首選引擎，支持ACID事務，支持行級鎖定，MySQL5.5起成為默認數據庫引擎BDB源自BerkeleyDB，事務型數據庫的另一種選擇，支持Commit和Rollback等其他事務特性Memory所有數據置於內存的存儲引擎，擁有極高的插入，更新和查詢效率。

但是會佔用和數據量成正比的內存空間。並且其內容會在MySQL重新啟動時丟失Merge將一定數量的MyISAM表聯合而成一個整體，在超大規模數據存儲時很有用Archive非常適合存儲大量的獨立的，作為歷史記錄的數據。

因為它們不經常被讀取。Archive擁有高效的插入速度，但其對查詢的支持相對較差Federated將不同的MySQL服務器聯合起來，邏輯上組成一個完整的數據庫。非常適合分布式應用Cluster/NDB高冗餘的存儲引擎，用多台數據機器聯合提供服務以提高整體性能和安全性。適合數據量大，安全和性能要求高的應用

MYSQL相比於其他數據庫有哪些特點

　MySQL是一個小型關係型數據庫管理系統，開發者為瑞典MySQL AB公司，現在已經被Sun公司收購，支持FreeBSD、Linux、MAC、Windows等多種操作系統與其他的大型數據庫例如Oracle、DB2、SQL Server等相比功能稍弱一些

1、可以處理擁有上千萬條記錄的大型數據

2、支持常見的SQL語句規範

3、可移植行高，安裝簡單小巧

4、良好的運行效率，有豐富信息的網絡支持

5、調試、管理，優化簡單(相對其他大型數據庫)

mysql的特點是什麼?

1、MySQL性能卓越、服務穩定，很少出現異常宕機。

2、MySQL開放源代碼且無版權制約，自主性及使用成本低。

3、MySQL歷史悠久，用戶使用活躍，遇到問題可以尋求幫助。

4、MySQL體積小，安裝方便，易於維護。

5、MySQL口碑效應好，是的企業無需考慮就用之，LAMP、LNMP流行架構。

6、MySQL支持多種操作系統，提供多種API接口，支持多種開發語言，特別是PHP。

SQL Server的優點眾多，但是Microsoft SQL Server和其他數據庫產品相比也存在着以下劣勢：

1、開放性。只能運行在微軟的windows平台，沒有絲毫的開放性可言。

2、可伸縮性，並行性。並行實施和共存模型並不成熟，很難處理日益增多的用戶數和數據卷，伸縮性有限。

3、性能穩定性。SQLServer當用戶連接多時性能會變的很差，並且不夠穩定。

4、使用風險。SQLServer完全重寫的代碼，經歷了長期的測試，不斷延遲，許多功能需時間來證明。並不十分兼容早期產品。使用需要冒一定風險。

5、客戶端支持及應用模式。只支持C/S模式。