mysql的歷史可以追溯到2023年，它的創始人叫作michael widenius，他在開發乙個報表工具的時候，設計了一套api，後來他的客戶要求他的api支援sql語句，他直接借助於msql（當時比較牛）的**，將它整合到自己的儲存引擎中。但是他總是感覺不滿意，萌生了要自己做一套資料庫的想法。一到2023年，mysql 1.0發布，僅僅過了幾個月的時間，2023年10月mysql 3.11.1當時發布了solaris的版本，乙個月後，linux的版本誕生，從那時候開始，mysql慢慢的被人所接受。
2023年，michael widenius成立了mysql ab公司，mysql由個人開發轉變為團隊開發，2023年使用gpl協議開源。2023年，mysql生命中的大事發生了，那就是儲存引擎innodb的誕生！直到現在，mysql可以選擇的儲存引擎，innodb依然是no.1。2023年1月，mysql ab公司被sun公司以10億美金收購，mysql資料庫進入sun時代。sun為mysql的發展提供了絕佳的環境，2023年11月，mysql 5.1發布，mysql成為了最受歡迎的小型資料庫。
在此之前，oracle在2023年就收購了innodb，因此，innodb一直以來都只能作為第三方外掛程式供使用者選擇。2023年4月，oracle公司以74億美元收購sun公司，mysql也隨之進入oracle時代。2023年12月，mysql 5.5發布，oracle終於把innodb做成了mysql預設的儲存引擎，mysql從此進入了輝煌時代。然而，從那之後，oracle對mysql的態度漸漸發生了變化，oracle雖然宣稱mysql依然尊少gpl協議，但卻暗地裡把開發人員全部換成了oracle自己人，開源社群再也影響不了mysql發展的腳步，真正有心做貢獻的人也被拒之門外，mysql隨時都有閉源的可能……
先提一下mysql名字的由來吧，michael widenius的女兒的簡稱就是my，michael widenius大概也是把mysql當成自己的女兒吧。看著自己辛苦養大的mysql被oracle搞成這樣，michael widenius非常失望，決定在mysql走向閉源前，將mysql進行分支化，依然是使用了自己女兒的名字mariadb（瑪莉亞db）。
mariadb資料庫管理系統是mysql的乙個分支，主要由開源社群在維護，採用gpl授權許可 mariadb的目的是完全相容mysql，包括api和命令列，使之能輕鬆成為mysql的代替品。在儲存引擎方面，使用xtradb來代替mysql的innodb。mariadb由mysql的創始人michael widenius主導，由開源社群的大神們進行開發。因此，大家都認為，mariadb擁有比mysql更純正的mysql血脈。最初的版本更新與mysql同步，相對mysql5以後的版本，mariadb也有相應的5.1~5.5的版本。後來mariadb終於擺脫了mysql，它的版本號直接從10.0開始，以自己的步伐進行開發，當然，還是可以對mysql完全相容。現在，mariadb的資料特性、效能等都超越了mysql。
本效能測試環境如下：
create table `performance`.`log`(
`id` int unsigned not null auto_increment,
`time` datetime not null,
`level` enum('info','debug','error') not null,
`message` text not null,
primary key (`id`)
) engine=innodb charset=utf8;
單條插入的測試結果如下表所示：
mariadb單條資料插入的效能比mysql強1倍左右。
批量插入
批量插入的測試結果如下表所示
上面的測試結果，mariadb並沒有絕對優勢，甚至有時還比mysql慢，但平均水平還是高於mysql。
經過了多次插入測試，我兩個資料庫裡插入了很多資料，此時用下面的sql查詢表中的資料量：
select count(0) from log
結果兩個表都是6785000條，mariadb用時3.065秒，mysql用時6.404秒。此時我機器的記憶體用了6個g，mariadb用了474284 k，mysql只用了66848 k。看來mariadb快是犧牲了空間換取的。
無索引先查詢一下time欄位的最大值和最小值：
select max(time), min(time) from log
mariadb用時6.333秒，mysql用時8.159秒。接下來測試過濾time欄位在0點到1點之間的資料，並對time欄位排序：
select * from log where time > '2020-02-04 00:00:00' and time < '2020-02-04 01:00:00' order by time
mariadb用時6.996秒，mysql用時10.193秒。然後測試查詢level字元是info的資料：
select * from log where level = 'info'
mariadb用時0.006秒，mysql用時0.049秒。最後測試查詢message字段值為debug的資料：
select * from log where message = 'debug'
mariadb用時0.003秒，mysql用時0.004秒。
分別對兩個資料庫的字段建立索引：
alter table `performance`.`log`
add index `time` (`time`),
add index `level` (`level`),
add fulltext index `message` (`message`);
在上面的測試中mariadb的效能的確優於mysql，看來各大廠商放棄mysql擁抱mariadb還是非常有道理的。
mysql效能優化 mysql效能優化
優化方式 1.空間換時間 冗餘 2.時間換空間 字段優先使用型別 int date char varchar text 索引型別 btree索引 hash索引 索引的葉子下，存放乙個資訊指向所在行的資料位址。btree有利於範圍查詢，hash有利於精確查詢。btree用的更多一些。btree索引的常...
mysql 效能拐點 MySQL效能優化
此篇文章簡單介紹mysql配置優化 修改back log back log值表示mysql的連線資料達到max connections時,有多少請求能夠被放在堆疊之中以等待其他連線釋放.如果等待連線的數量超過back log時,就不被授予連線資源.show variables like back l...
mysql 效能分析 Mysql效能分析
優化mysql資料庫效能的十個引數 1 max connections 允許的同時客戶的數量。增加該值增加 mysqld 要求的檔案描述符的數量。這個數字應該增加，否則，你將經常看到 too many connections 錯誤。預設數值是100，我把它改為1024 2 record buffer...