資料庫受住
查看MySQL資料庫的死鎖日誌
1. 使用終端或命令提示符登錄到MySQL，輸入命令：mysql -h xxxx.xxx.xxx -P 3306 -u username -p解釋：xxxx.xxx.xxx是資料庫IP地址，username是資料庫用戶名，輸入命令後，會讓你輸入username對應的密碼，就可以登錄了
4. 如何分析日誌，定位死鎖原因看3裡面的圖，紫色劃線部分分析：事務1，等待RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`，這個位置的X鎖事務2，持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`這個地方的S鎖事務2，等待這個地方的X鎖理論上這個事務2是可以提交的不會，死鎖，但是這個事務日誌只列印最後一部分死鎖，信息，這裡面隱含的條件是，事務1也持有RECORD LOCKS space id 553 page no 376 n bits 368 index `index_user_id` of table `tbj`.`score_user`這個地方的S鎖，這樣，事務2不能加X鎖，同時事務1也不能加X鎖，產生死鎖。
2. Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障處理方式
Oracle資料庫無響應故障，簡單地講就是資料庫實例不能響應客戶端發起的請求，客戶端提交一個SQL後，就一直處於等待資料庫實例返回結果的狀態。更嚴重的現象是客戶端根本不能連接到資料庫，發起一個連接請求後，一直處於等待狀態。Oracle資料庫無響應故障怎麼處理呢?下面跟我一起來學習Oracle資料庫無響應故障的處理方法吧!
無響應的故障現象一般有以下幾種：
1.Oracle的進程在等待某個資源或事件
這種現象一般可以從V$SESSION_WAT、V$LATCH、V$LATCHHOLDER等動態視圖中檢查進程正在等待的資源或事件，而被等待的資源或事件，一直都不能被獲取，甚至是很長時間都不可獲得。如果這個正在等待的進程持有了其他的資源，則會引起其他的進程等待，這樣就很可能引起實例中大范圍的會話發生等待。由於進程在等待資源或事件時，通常都處於SLEEP狀態，消耗的CPU資源非常少(在等待latch時要稍微多消耗一些CPU資源)，所以從OS來看，CPU的消耗並不高，甚至是非常低。
這種因為等待而引起的個別進程Hang，相對比較容易處理。
2. OracleProcess Spins
所謂Spin，就是指Oracle進程中的代碼在執行某個過程時，陷入了循環。在V$SESSION視圖中，往往可以看到Hang住的會話，一直處於“ACTIVE”狀態。對於這樣的會話，用“alter system kill session ‘sid,serial#’”命令也不能完全斷開會話，會話只能被標記為“killed”，會話會繼續消耗大量的CPU。進程Spins由於是在做循環，CPU的消耗非常大，從OS上明顯可以看到這樣的進程，通常會消耗整個CPU的資源。
而對於這樣的Hang住的會話，處理起來相對比較復雜，並且為了從根本上解決問題，需要超過DBA日常維護所需要的技能。
從故障范圍來看，無響應故障可以分為以下幾種情況：
1. 單個或部分會話(進程)Hang住
這種情況屬於小范圍的故障，業務影響相對較小，一般來說只會影響業務系統的個別模塊。在一個多應用系統的資料庫上面，如果Hang住的會話比較多，則影響的可能是其中的一個應用系統。這里有一個例外，如果Hang住的進程是系統後台進程，如pmon、smon等，則影響的范圍就非常大了，最終甚至會影響整個資料庫及所有應用系統。還有值得注意的是，即使是少部分會話Hang住，也要及時處理，否則極有可能會擴散到整個系統。
2. 單個資料庫實例Hang住
這種情況造成的影響非常大。在這個實例上的所有應用系統均受到嚴重影響，並且在找到根源並最終解決問題之前，資料庫實例往往須要重啟。
3. OPS或RAC中的多個實例或所有實例都Hang住
在這種情況下，即使是OPS或RAC，都已經沒辦法提供高可用特性了。使用這個資料庫的所有應用系統將不能繼續提供服務，這種情況往往須要重啟。
無響應故障成因分析
Oracle資料庫無響應，一般主要由以下幾種原因引起：
1. 資料庫主機負載過高，嚴重超過主機承受能力
比如應用設計不當，資料庫性能低下，活動會話數的大量增加，導致資料庫主機的負載迅速增加，資料庫不能正常操作，並最終Hang住;主機物理內存嚴重不足，引起大量的換頁，特別是在SGA中的內存被大量換出到虛擬內存時，資料庫實例往往就會Hang住。
2. 日常維護不當、不正確的操作引起資料庫Hang住
比如歸檔日誌的存儲空間滿，導致資料庫不能歸檔，引起資料庫Hang住;在一個大並發的繁忙的系
統上，對DML操作比較多的大表進行move、增加外鍵約束等操作也可能使系統在短時間內負載大幅升高，並引起資料庫系統Hang住;不正確的資源計劃(Resource Plan)配置，使進程得不到足夠的CPU等。
3. Oracle資料庫的Bug
幾乎每個版本都存在著會導致資料庫系統Hang住的Bug，這些Bug會在一些特定的條件下觸發，特別是在RAC資料庫中，引起資料庫Hang住的Bug比較多。
4. 其他方面的一些原因
比如在RAC資料庫中，如果一個節點退出或加入到RAC的過程中，當進行Resource Reconfiguration時，會使系統凍結一段時間，也有可能使系統Hang住。
以上所描述的幾種常見的會導致Oracle資料庫實例Hang住的原因中，大部分的情況是可以避免的，只要維護得當，一般不會出現這種故障。對於Oracle資料庫Bug所導致的資料庫無響應故障，由於是在特定的情況下才會觸發，所以如果能夠盡量對資料庫打上最新版本的補丁，並且熟悉當前版本中會導致系統Hang住的Bug以及觸發條件，就能夠最大限度地避免這種故障的發生，提高系統的可用性。
那麼，在資料庫Hang住的情況下，如何去分析並發現導致問題的根源?一方面，由於系統Hang住會導致業務系統不可用，為了能夠盡快地恢復業務，須快速地判斷問題所在，然後Kill掉引起故障的會話和進程，或者資料庫實例不得不重啟以迅速恢復業務;但另一方面，如果只是重啟資料庫或Kill會話和進程來解決問題，在很多情況下是治標不治本的辦法，在以後故障隨時可能會出現。如何在二者之間進行抉擇呢?對於資料庫Hang故障的處理，首先是盡可能地收集到系統Hang住時的狀態數據，然後盡快地恢復業務，恢復業務後分析收集到的數據，找到資料庫系統Hang住的真正原因，然後再進行相應的處理。下一節將詳細描述資料庫系統Hang住後的處理流程。
無響應故障處理流程
對於Oracle無響應故障的處理，我們可以按下圖所示的流程進行。
值得注意的是，上圖並不是一個完整的Oracle資料庫故障處理流程圖，只是處理Oralce資料庫無響應這一類特定的故障的流程，只列出了針對這一特定類型故障處理時的關鍵處理點。不過既然是故障，所以這類故障的處理流程與其他故障的處理流程，有著非常相似的地方。
下面是整個流程的詳細說明：
1. 在出現資料庫無響應故障後，首先確認系統的影響范圍，如上節所描述的'，是部分業務系統或模塊還是所有的業務系統都受影響，是不是整個實例或多個實例都無響應。同時應詢問系統維護和開發人員，受影響的系統在出現故障前是否有過變動，包括主機硬體、操作系統、網路、資料庫以及應用等。有時一個細小的變動就可能導致出現資料庫Hang住這樣嚴重的故障。曾經遇到一個庫，應用只是修改了一個SELECT語句就導致了資料庫Hang住。
2. 為了避免由於網路、資料庫監聽或客戶端因素影響分析，建議都登錄到主機上進行操作。
3. 如果主機不能登錄(為了避免干擾流程主線，這里不討論如網路問題這樣也會導致不能連接的故障)，嘗試關閉出現問題的業務系統，甚至是所有的業務系統。如果關閉了所有的業務系統之後，仍然不能連接，則只有考慮重新啟動資料庫主機。在資料庫主機重新啟動後，使用操作系統工具或OSW等長期監控操作系統的資源使用，同時監控Oracle資料庫的性能和等待等。
4. 登錄上主機後，先用top、topas等命令簡單觀察一下系統。看看系統的CPU使用、物理內存和虛擬內存的使用、IO使用等情況。
5. 使用SQLPLUS連接資料庫，如果不能連接，則只能從操作系統上觀察系統中是否有異常的現象，比如佔用CPU過高的進程。使用gdb、dbx等debugger工具對資料庫進行system state mp;使用strace、truss等工具檢查異常進程的系統調用;使用pstack、procstack等工具察看異常進程的call stack等。
6. 使用SQLPLUS連接上資料庫後，進行hanganalyze、system state mp等操作;或檢查等待事件、異常會話等正在執行的SQL等待。
7. 找到故障產生的原因，如果暫時找不到原因，盡量收集數據。
8.確良如果應用急須恢復，可通過Kill會話、重啟資料庫實例等方式，先恢復應用。
9. 根據最終診斷結果，對資料庫升級打補丁，或者修改應用等方式從根本上解決問題。
怎樣避免資料庫出現無響應故障
作為Oracle資料庫DBA，除了處理故障之外，更重要的是如何預防故障的發生。根據前面對資料庫無響應故障的成因分析，在日常的維護工作中，須做到以下幾點：
1. 進行正確的維護操作
很多的資料庫無響應故障都是由於不正確的維護操作引起的。應避免在業務高峰期做大的維護操作，比如像move、加主外鍵約束等會長時間鎖表的操作。如果的確需要，盡量使用正確的操作方法。比如用ONLINE方式重建索引;建主鍵、唯一鍵約束時先建索引，然後在建約束時指定新建的索引，等等。也就是保證系統的並發性、可伸縮性，避免系統串列操作的出現。
2. 優化應用設計，優化資料庫性能
為避免性能問題導致在業務高峰期資料庫不能及時有效處理來自業務的請求，甚至於完全Hang住。對於資料庫中存在串列訪問的部分進行優化，比如latch、enqueue，還包括不合理的sequence設計等。特別是在RAC資料庫中，嚴重串列訪問等待往往更容易引起嚴重的性能問題。優化應用設計，使資料庫具有更好的可伸縮性和並行處理能力，能夠有效地避免性能問題引起的資料庫Hang住。
3. 利用監控系統隨時監控系統負載
遇到系統負載過高，內存不足，OS中虛擬內存換頁很頻繁等情況時，及時採取措施;監控Oracle資料庫的核心進程，如pmon、smon等，看是否有異常，如過高的CPU消耗。出現異常應立即處理;監控歸檔空間和日誌切換;監控資料庫中的等待事件，比如是否有大量的enqueue、log file switch (archiving needed)、resmgr:become active等待事件等。
4. 為資料庫打上補丁
很多的無響應故障是由於Oracle的Bug引起的，資料庫DBA應關注當前版本中有哪些Bug會導致資料庫Hang住，盡量為資料庫打上解決這些Bug的補丁。
;3. 資料庫索引是什麼，有什麼用，怎麼用
1、資料庫索引是什麼，有什麼用
資料庫索引是對資料庫表中一列或多列的值進行排序的一種結構，使用索引可快速訪問資料庫表中的特定信息。如果想按特定職員的姓來查找他或她，則與在表中搜索所有的行相比，索引有助於更快地獲取信息。
索引的一個主要目的就是加快檢索表中數據的方法，亦即能協助信息搜索者盡快的找到符合限制條件的記錄ID的輔助數據結構。
2、資料庫索引的用法
當表中有大量記錄時，若要對表進行查詢，第一種搜索信息方式是全表搜索，是將所有記錄一一取出，和查詢條件進行一一對比，然後返回滿足條件的記錄，這樣做會消耗大量資料庫系統時間，並造成大量磁碟I/O操作；
第二種就是在表中建立索引，然後在索引中找到符合查詢條件的索引值，最後通過保存在索引中的ROWID（相當於頁碼）快速找到表中對應的記錄。
索引是一個單獨的、物理的資料庫結構，它是某個表中一列或若干列值的集合和相應的指向表中物理標識值的數據頁的邏輯指針清單。
(3)資料庫受住擴展閱讀：
一、索引的原理：
對要查詢的欄位建立索引其實就是把該欄位按照一定的方式排序；建立的索引只對該欄位有用，如果查詢的欄位改變，那麼這個索引也就無效了，比如圖書館的書是按照書名的第一個字母排序的，那麼你想要找作者叫張三的就不能用改索引了；還有就是如果索引太多會降低查詢的速度。
二、資料庫索引的特點：
1、避免進行資料庫全表的掃描，大多數情況，只需要掃描較少的索引頁和數據頁，而不是查詢所有數據頁。而且對於非聚集索引，有時不需要訪問數據頁即可得到數據。
2、聚集索引可以避免數據插入操作，集中於表的最後一個數據頁面。
3、在某些情況下，索引可以避免排序操作。
4. 哪些因素影響了資料庫性能
網路寬頻，磁碟IO，查詢速度都會影響到資料庫的性能。
具體問題具體分析，舉例來說明為什麼磁碟IO成瓶頸資料庫的性能急速下降了。
為什麼當磁碟IO成瓶頸之後, 資料庫的性能不是達到飽和的平衡狀態，而是急劇下降。為什麼資料庫的性能有非常明顯的分界點，原因是什麼？
相信大部分做資料庫運維的朋友，都遇到這種情況。 資料庫在前一天性能表現的相當穩定，資料庫的響應時間也很正常，但就在今天，在業務人員反饋業務流量沒有任何上升的情況下，資料庫的變得不穩定了，有時候一個最簡單的insert操作， 需要幾十秒，但99%的insert卻又可以在幾毫秒完成，這又是為什麼了？
dba此時心中有無限的疑惑，到底是什麼原因呢? 磁碟IO性能變差了？還是業務運維人員反饋的流量壓根就不對？ 還是資料庫內部出問題？昨天不是還好好的嗎？
當資料庫出現響應時間不穩定的時候，我們在操作系統上會看到磁碟的利用率會比較高，如果觀察仔細一點，還可以看到，存在一些讀的IO. 資料庫伺服器如果存在大量的寫IO,性能一般都是正常跟穩定的，但只要存在少量的讀IO,則性能開始出現抖動，存在大量的讀IO時（排除配備非常高速磁碟的機器），對於在線交易的資料庫系統來說，大概性能就雪崩了。為什麼操作系統上看到的磁碟讀IO跟寫IO所帶來的性能差距這么大呢？
如果親之前沒有注意到上述的現象，親對上述的結論也是懷疑。但請看下面的分解。
在寫這個文章之前，作者閱讀了大量跟的IO相關的代碼，如非同步IO線程的相關的，innodb_buffer池相關的，以及跟讀數據塊最相關的核心函數buf_page_get_gen函數以及其調用的相關子函數。為了將文章寫得通俗點，看起來不那麼累，因此不再一行一行的將代碼解析寫出來。
咱們先來提問題。buf_page_get_gen函數的作用是從Buffer bool裡面讀數據頁，可能存在以下幾種情況。
提問. 數據頁不在buffer bool 裡面該怎麼辦？
回答：去讀文件，將文件中的數據頁載入到buffer pool裡面。下面是函數buffer_read_page的函數，作用是將物理數據頁載入到buffer pool, 圖片中顯示
buffer_read_page函數棧的頂層是pread64(),調用了操作系統的讀函數。
通過解析buf_wait_for_read函數的下層函數，我們知道其實通過首先自旋加鎖pin的方式，超過設定的自旋次數之後，進入等待，等待IO完成被喚醒。這樣節省不停自旋pin時消耗的cpu,但需要付出被喚起時的開銷。
再繼續擴展問題： 如果會話線程A 經過物理IO將數據頁1001讀入buffer之後，他需要修改這個頁，而在會話線程A之後的其他的同樣需要訪問數據頁1001的會話線程，即使在數據頁1001被入讀buffer pool之後，將仍然處於等待中。因為在數據頁上讀取或者更新的時候，同樣需要上鎖，這樣才能保證數據頁並發讀取/更新的一致性。
由此可見，當一個高並發的系統，出現了熱點數據頁需要從磁碟上載入到buffer pool中時，造成的延遲，是難以想像的。因此排在等待熱點頁隊列最後的會話線程最後才得到需要的頁，響應時間也就越長，這就是造成了一個簡單的sql需要執行幾十秒的原因。
再回頭來看上面的問題，mysql資料庫出現性能下降時，可以看到操作系統有讀IO。 原因是，在資料庫對數據頁的更改，是在內存中的，然後通過檢查點線程進行非同步寫盤，這個非同步的寫操作是不堵塞執行sql的會話線程的。所以，即使看到操作系統上有大量的寫IO，資料庫的性能也是很平穩的。但當用戶線程需要查找的數據頁不在buffer pool中時，則會從磁碟上讀取，在一個熱點數據頁不是非常多的情況下，我們設置足夠大的innodb_buffer_pool的size, 基本可以緩存所有的數據頁，因此一般都不會出現缺頁的情況，也就是在操作系統上基本看不到讀的IO。 當出現讀的IO時，原因時在執行buf_read_page_low函數，從磁碟上讀取數據頁到buffer pool, 則資料庫的性能則開始下降，當出現大量的讀IO，資料庫的性能會非常差。
5. MYSQL資料庫怎麼查看 哪些表被鎖了
以下五種方法可以快速定位全局鎖的位置，僅供參考。
方法1：利用 metadata_locks 視圖
此方法僅適用於 MySQL 5.7 以上版本，該版本 performance_schema 新增了 metadata_locks，如果上鎖前啟用了元數據鎖的探針（默認是未啟用的），可以比較容易的定位全局鎖會話。
方法2：利用 events_statements_history 視圖此方法適用於 MySQL 5.6 以上版本，啟用 performance_schema.eventsstatements_history（5.6 默認未啟用，5.7 默認啟用），該表會 SQL 歷史記錄執行，如果請求太多，會自動清理早期的信息，有可能將上鎖會話的信息清理掉。
方法3：利用 gdb 工具如果上述兩種都用不了或者沒來得及啟用，可以嘗試第三種方法。利用 gdb 找到所有線程信息，查看每個線程中持有全局鎖對象，輸出對應的會話 ID，為了便於快速定位，我寫成了腳本形式。也可以使用 gdb 交互模式，但 attach mysql 進程後 mysql 會完全 hang 住，讀請求也會受到影響，不建議使用交互模式。
方法4：show processlist
如果備份程序使用的特定用戶執行備份，如果是 root 用戶備份，那 time 值越大的是持鎖會話的概率越大，如果業務也用 root 訪問，重點是 state 和 info 為空的，這里有個小技巧可以快速篩選，篩選後嘗試 kill 對應 ID，再觀察是否還有 wait global read lock 狀態的會話。
方法5：重啟試試！
6. 影響資料庫性能的主要因素有哪些
以MySQL為例：
影響資料庫性能的主要因素總結如下：
1、sql查詢速度
2、網卡流量
3、伺服器硬體
4、磁碟IO
以上因素並不是時時刻刻都會影響資料庫性能，而就像木桶效應一樣。如果其中一個因素嚴重影響性能，那麼整個資料庫性能就會嚴重受阻。另外，這些影響因素都是相對的。
例如：當數據量並沒有達到百萬千萬這樣的級別，那麼sql查詢速度也許就不是個重要因素，換句話說，你的sql語句效率適當低下可能並不影響整個效率多少，反之，這種情況，無論如何怎麼優化sql語句，可能都沒有太明顯的效果。
相關內容拓展：
1、SQL查詢速度
風險：效率低下的SQL
2、網卡流量
風險：網卡IO被占滿（100Mb/8=100MB）
方案：
①減少從伺服器的數量。從伺服器都要從主伺服器上復制日誌，所以，從伺服器越多，網路流量越大。
②進行分級緩存。前方大量緩存突然失效會對資料庫造成嚴重的沖擊。
③避免使用「select * 」進行查詢
④分離業務網路和伺服器網路
3、磁碟IO
風險：磁碟IO性能突然下降。
方案：使用更好的磁碟設備解決。
7. 資料庫的作用
1、幫助企業准確找到目標客戶：
在市場細分化理論指導下的營銷，是根據人口統計及消費者共同的心理特點，將客戶劃歸為某一類別。而通過新一代高速計算機和資料庫技術，以使企業能夠集中精力於更少的人身上，最終目標集中在最小消費單位——特定企業或個人身上，實現准確定位。
2、降低營銷成本，提高營銷效率：
運用資料庫能夠准確找出某種產品的目標客戶，用資料庫技術進行篩選消費者，其郵寄宣傳品的反饋率可以高達20%～30％。
3、使消費者成為企業長期、忠誠的用戶，保證企業掌握穩定的客戶群：
建立資料庫，以便能夠分析客戶是些什麼人，採取什麼措施以保住客戶。當通過資料庫鎖定企業的重點客戶後，企業每次舉行促銷宣傳活動，必以這部分客戶為主要對象，極力改進服務，滿足他們的需求，使這些客戶成為公司穩定的客戶。
(7)資料庫受住擴展閱讀：
資料庫的優點：
1、查詢迅速、准確，且有多種表達與傳輸方式：
如果要查找的內容較多，則查找與抄寫既費時又費力。資料庫系統能根據給定的條件自動地按一定途徑以毫秒級速度進行掃描查找，可以在瞬間將符合要求的數據一一用表格或其他方式顯示出來，還可以自動地列印出來或通過網路傳輸到指定地址，而且不會出現錯誤。
2、數據結構化且統一管理：
在資料庫中，數據按邏輯結構組織起來，而按物理結構存放在磁介質中，並且由資料庫管理系統統一管理，既考慮了數據本身的特點，也考慮了數據之間以及文件之間的聯系，數據的查詢、檢索和處理很方便。
8. ora-12719 操作要求資料庫 處於restricted模式下 怎麼處理
資料庫受限模式，在這個模式下只有RESTRICTED SESSION 許可權的人才可以登陸，一般用與資料庫維護的時候使用。
RESTRICTED SESSION Clause
The RESTRICTED SESSION clause lets you restrict logon to Oracle.
You can use this clause regardless of whether your instance has the database
dismounted or mounted, open or closed.
Restricting Session Logons: Example You may want to restrict logons if you are
performing application maintenance and you want only application developers
with RESTRICTED SESSION system privilege to log on. To restrict logons, issue the
following statement:
ALTER SYSTEM
9. 資料庫承載問題
MySQL∶網站開發者的新選擇
「變動」這兩個字對 IT 業界來說是再普通不過的事了。如果今天管理階層的主管們跟你要資料庫的推薦名單，很可能在你開始執行你所推薦的方案之前，你的推薦名單上的項目就已經過時了。 如此一來，你可能就要重新考慮各種軟硬體方案，好讓你∶
·幫你將事情完成
·買來以便幫助別人完成他們的工作
·開發以便幫助別人更好地完成他們的工作
不論你的消息有多新，在你的建議通過層層關卡，並且拿到購買資金之前，你的推薦表上的某些項目通常都會過時。幸運的是，沒有人會責怪你，或者是對你反唇相譏 -- 這是這一行里很自然的事情。資料庫技術通常在你能夠掌握它之前就變了。
為了適應日新月異的資料庫技術，有相當多的軟體工程師逐漸地從桌面資料庫軟體諸如 Microsoft Access 以及 SQL Server，轉到使用 MySQL。雖然嚴格說來MySQL 並非 SQL Server 的對手，但許多服務提供商都支持 MySQL，並視之為便宜而有效率的替代品。
Susan Sales Harkins 經常在 CNET Builder.com 發表文章，是一位精通微軟 Office 的專家。她也是Using Microsoft Access 97和Using Microsoft Access 2000兩書的作者，這兩本書均由 Que 所出版。
Martin W. P. Reid 也經常在 CNET Builder.com 發表文章，是英國貝爾法斯特女王大學（Queen's University） 的分析師暨程序設計員。他也指導關系型資料庫設計的課程；工作之餘也為北愛爾蘭的一些小型企業充當資料庫顧問。
▲考慮使用 MySQL 的原因
如果你要找的是可靠的資料庫軟體，以便支持你的網站開發工作，那麼以下的原因就說明了你為什麼應該考慮 MySQL而不是其它資料庫∶
·它便宜（通常是免費）。
·它的網路承載比較少。
·它經過很好的優化（Highly Optimized）。
·應用程序通過它做備份來比較簡單。
·它為各種不同的資料格式提供有彈性的擴展介面 (ODBC)。
·它較好學，且操作簡單。
·你負擔得起的客戶支持費用。
▲關於「$」的問題
簡單的說，你不會找到比 MySQL 更便宜的了。事實上，對大多數用戶來說，MySQL 是免費的。有時候雖然是要付出一小筆的授權費，但是這個付費規定只限於以下兩種情況∶
·以內嵌（embedded）的方式使用 MySQL 伺服器
·只使用 MySQL 的商業用途軟體
例如，Windows 版本的 MySQL 伺服器，需要授權。雖然只付比美金 $200 元多一點點的費用，MySQL 還是比其他任何資料庫軟體來得更便宜多了。Office XP Developer 的零售價是美金 $799 元，升級版則是美金 $549 元。Access 2002 的價格是美金 $339 元，升級版則是美金 $109 元。
▲ 避免堵塞
針對多個使用者共同讀寫信息的需求，Access 根本不是 MySQL 的對手。Access 在大約十五個使用者連上來的時候，就輸掉了。我們還聽說過當只有五個人連上來時， 就會有一些問題（這並不是說，只有五個人能夠同時連上由 Access 資料庫支持的網站）。「同時連結」（Simultaneous connection）事實上是一種並發處理（concurrent process）。因此，雖然事實上 Access 可以處理的連結數目是無限制的，但只要那些連結保持在並發處理的范圍限制內就沒關系。對於只讀網站（這些網站並非你想像中的少數）它可以支持到最多到 255 個使用者。而較大的網站，則無可避免的必須升級到 SQL Server 以提高穩定性和效率。
相對說來，MySQL 內定最大連結數為 100 個使用者。但是，我們絕對不可以用一個程序的內建設定來判斷它的效能。到目前為止，我們還沒聽說過使用 MySQL 的較大而且訪問頻繁的網站上的使用者有任何抱怨。除此之外，即使有網路上有 大量 的資料往來，似乎並不會對MYSQL的查詢優化（query optimization）造成多大的影響。
在 Windows 98 操作系統上使用相同的硬體和數據尺寸，MySQL 表現得比 Access 2000 還要快 – 但只是並非所有的情況下都是如此。 這兩者在資料更新方面的效能，有著很大的差異，同樣的資料更新，Access 要花上兩倍的時間。如果是在高速系統上做小量的資料的處理，你不會去注意到這兩者間的差異。 但只有在處理的是幾十萬筆資料的時候，這效能上的差異才會明顯。MySQL 只在處理資料庫對象結構（object structure）的時候，才會輸給 Access。 當建立表格（table） 以及索引的時候，MySqL 會將表格鎖住，如此一來會導致正在進行的大量資料處理速度慢下來。然而以上所提到的最後一個問題在網站開發時，通常並不會造成麻煩。 因為網站上，我們所重視的是用戶來訪時查詢的速度，而非資料儲存結構本身。因此，在這個領域，MySQL 勝利。
▲MYSQL其它的優點
·優化
對於 MySQL 的優化，我們可以說，主要的問題在於你的硬體條件，而非 MySQL 本身。不過對於 Access，（以及其他桌面資料庫軟體）事情就不是這樣了。 沒錯，Microsoft Jet Database 的確實有效率，不過它還不是最快的。如果你的資料庫設計得非常差，你的網站還是會受到影響而速度變慢的。 資料庫結構設計也會影響到 MySQL，例如，MySQL 並不支持外鍵（foreign key）。這個缺點會影響到你的資料庫設計以及網站的效率。對於使用 MySQL 做資料庫的網站，你應該注意的是，如何讓硬碟存取IO減少到最低值、如何讓一個或多個 CPU 隨時保持在高速作業的狀態、以及適當的網路帶寬， 而非實際上的資料庫設計以及資料查詢語句。事實上，有些網站開發者將 MySQL 稱為目前市面上跑得最快的資料庫。不過，當你的資料庫有很多表格需要同時在一個事務過程（transaction）內完成更新的時候，MySQL 的確跑得不怎麼樣。
·備份
如果你曾經有過搶救一個損壞的 MDB 檔案的慘痛經驗，那麼你會對 MySQL 表示非常激賞。這是 MySQL 另一個勝過 Access 的地方。首先，mysqlmp 會產生一個比 Access 好很多而且也更可靠的備份檔案。相比之下，在 Access中你只是將一個 MDB 檔拷貝起來做備份。其次，即使 MySQL 的備份有部分損壞，復原起來也要比一個損壞的 MDB 檔要容易得多了。
·可延伸性（Scalability）以及資料處理能力
套句登山者的話來說，將 Access 資料庫來跟 MySQL 相比，簡直就是像把印第安那的小山丘拿來跟科羅拉多洛磯山脈的 Pike's Peak 頂相比較。事實就是這么簡單∶MySQL 可以處理的檔案比 Access 所能處理的檔案大很多。如果你硬將 Access 資料庫弄到 100MB 的 MDB 檔案時，你要准備好一個字典厚的紀錄本來記錄來自客戶對於網站效率低下的抱怨。而類似的資料庫在 MySQL 上面跑，就不會發生承載過重的跡象。
另外，MySQL 同時提供高度多樣性，能夠提供很多不同的使用者介面，包括命令行客戶端操作，網頁瀏覽器，以及各式各樣的程序語言介面，例如 C+，Perl，Java，PHP，以及 Python。你可以使用事先包裝好的客戶端，或者乾脆自己寫一個合適的應用程序。MySQL 可用於 Unix，Windows，以及 OS/2 等平台，因此它可以用在個人電腦或者是伺服器上。
沒錯，Microsoft ActiveX Data Objects Library（ADO）的確使得 Access 在外部資料市場（foreign data market）上能夠做更具彈性的應用。它能夠讓你不用管資料的所在位置而取出資料，然後在公用的介面上（即網頁瀏覽器）將資料顯示出來。不過，其壞處是 ADO 畢竟是比較笨重（它本身就是個資源大雜燴）而且學習它要花不少的金錢跟時間，就算你是一個能力不錯的開發工程師或者軟體工程師也一樣。沒有人能在一天內將 ADO 學會。
▲學習曲線
如果你已經熟悉資料庫技術，那麼基本上你已經沒什麼問題了。精通資料庫的人在一天之內就可以把 MySQL 學會，把這個經驗加到他的履歷表裡面去。相較之下，Access 是個復雜得多的資料庫及開發工具。即使是一個能力不錯的開發工程師也需要一段時間才能具備足夠的專業知識，有效地使用這個軟體。
正如你期待的，MySQL 支持結構化查詢語言（Structured Query Language ,SQL）。如果你已經學會某種版本的 SQL 語言，事情會好辦很多。具有 VB 或者是 VBA 知識背景的開發工程師會發現，他們以前所具備的 ASP 背景，能夠幫助他們縮短學習時間。
▲客戶支持
雖然好用而且免費的客戶支持已不存在，然而MySQL 倒提供了一些電子群組名單供您參考。有一些是頗具技術性的，而且會員們往往互相提供最佳的客戶支持 -- 他們彼此分享經驗和專業知識。此外，你還可以購買具有 客戶支持 的版本，包括 email 支持或者電話支持的方式。大致上來說，客戶支持費率並非固定的，因此我們無法提供你相關價位的信息。
▲MySQL 的不足之處
Access 是一個關聯性資料庫管理系統（RDBMS），然而 MySQL 並非在每一個層面都是如此。這表示，雖然 MySQL 很好用，它還不是最好的。 以下列表記錄了目前關聯性層面以及管理層面，MySQL 尚未支持的部分:
MySQL 沒法處理復雜的關聯性資料庫功能，例如，子查詢（subqueries），雖然大多數的子查詢都可以改寫成 join。我們期待下一版出來時，這項功能會被加進來。
另一個 MySQL 沒有提供支持的功能是事務處理（transaction）以及事務的提交（commit）/撤銷（rollback）。 一個事務指的是被當作一個單位來共同執行的一群或一套命令。如果一個事務沒法完成，那麼整個事務裡面沒有一個指令是真正執行下去的。對於必須處理線上訂單的商業網站來說， MySQL 沒有支持這項功能，的確讓人覺得很失望。 但是可以用MaxSQL，一個分開的伺服器，它能通過外掛的表格來支持事務功能。
外鍵（foreign key）以及參考完整性限制（referential integrity）可以讓你制定表格中資料間的約束，然後將約束（constraint）加到你所規定的資料裡面。這些MYSQL沒有的功能表示一個有賴復雜的資料關系的應用程序並不適合使用 MySQL。 當我們說 MySQL 不支持外鍵時，我們指的就是資料庫的參考完整性限制 -- MySQL 並沒有支持外鍵的規則，當然更沒有支持連鎖刪除（cascading delete）的功能。 簡短的說，如果你的工作需要使用復雜的資料關聯，那你還是用原來的 Access 吧。
你在 MySQL 中也不會找到存儲進程（stored procere）以及觸發器（trigger）。（針對這些功能，在 Access 提供了相對的事件進程（event procere）。）
Access 的 GetRows 功能，提供了較好的資料拾取。
▲總結
下面這個表格能讓你對於 MySQL，Access，以及 SQL Server 大致上比起來是怎麼樣有個基本概念:
□訪問頻繁的網站
·MySQL √
·Access √**
·SQL Server √
□復雜的資料關聯
·MySQL ×
·Access √
·SQL Server √
□在線訂單處理
·MySQL √*
·Access √***
·SQL Server √
□兼容性
·MySQL ×
·Access √****
·SQL Server √
□易於使用及操作
·MySQL √
·Access ×
·SQL Server ×
註：
* 需要MaxSQL
** 前提是資料只讀的話
*** 通過Jet SQL獲得的附加功能
**** 因為只有ADO
如果你需要使用復雜的資料庫，並且有很多資源和金錢，那麼你就用 SQL Server 吧。如果你仍舊需要復雜的資料庫但是卻沒有雄厚的後援，那麼用 Access 看看。至於其他的人，至少應該給 MySQL 一個使用的機會吧！