使用MySQL時有哪些必須注意的事項

下文主要給大家?guī)硎褂肕ySQL時有哪些必須注意的事項，希望這些內容能夠帶給大家實際用處，這也是我編輯使用MySQL時有哪些必須注意的事項這篇文章的主要目的。好了，廢話不多說，大家直接看下文吧。                                                             

靖西網站制作公司哪家好，找成都創(chuàng)新互聯(lián)公司！從網頁設計、網站建設、微信開發(fā)、APP開發(fā)、成都響應式網站建設公司等網站項目制作，到程序開發(fā)，運營維護。成都創(chuàng)新互聯(lián)公司于2013年創(chuàng)立到現(xiàn)在10年的時間，我們擁有了豐富的建站經驗和運維經驗，來保證我們的工作的順利進行。專注于網站建設就選成都創(chuàng)新互聯(lián)公司。

1、根深蒂固的bugs

任何大的軟件包都有 bug。但稍微深入了解一下，就會發(fā)現(xiàn)和 Mysql 相關的 bugs 自成體系。突然你就需要留心，因為 NULL 并不是以同樣的方式出現(xiàn)，外鍵約束也沒有像你想像的那樣執(zhí)行，連主鍵自動增長也會出錯。

小問題大量存在，而且并不總是可以修復，這就是為什么一些人保持一個列表。還好 MySQL 維護著一個非常好的 bug 報告系統(tǒng)，讓我們可以知道我些我們無法想像的事情，知道其他人也在經受同樣的磨難。

2、關系表的不靈活性

關系表具有條理性，條理性是好的——但是，它使得程序員不得不編造或硬塞一些數(shù)據到已經定義好模式的列中。NOSQL開始越來越受到歡迎的原因之一，就是它為程序員提供了足夠的靈活性，來加速數(shù)據庫的使用。如果一個街道地址需要增加一行，那么，你可以將它很容易地插入到一個NoSQL文檔中。如果你想添加一個完整的新的數(shù)據塊，無論它包含什么內容，文檔模型也可以原封不動地接受你的數(shù)據，而不必改為它要求的數(shù)據格式。

試想一下，你用整數(shù)格式建立了一個全部是郵編的表格。這個表是十分高效的，它執(zhí)行的規(guī)則也很好。突然一次，有人上傳了一個使用了連字符的九位數(shù)郵編?；蛘哌€有可能，你得到了一位來自加拿大客戶的信件，上面寫有郵政編碼。

這時，一切都亂了。老板要求網站要在幾小時內恢復正常工作。然而，現(xiàn)在已經沒有時間來重建數(shù)據庫。程序員可以做什么？也許，可以使用黑客手段把加拿大郵政編碼由base64的數(shù)字格式改為base 10格式？或者設置一個使用轉義編碼的輔助表格，用來說明真正的郵政編碼或者其他？誰知道呢？到處都有黑客，他們都是危險的。但你沒有時間來搞定它。

MySQL的關聯(lián)規(guī)則讓每個人都誠實和謹慎，但它能強制我們避開易受攻擊和欺騙的麻煩。

3、JOIN聯(lián)合查詢

曾幾何時，將數(shù)據分表保存是計算機科學史上的偉大創(chuàng)新。分開后的表不僅結構簡單，也簡化了使用。但它卻需要使用join語句進行查詢。

sql通過一系列join構建的復雜查詢將開發(fā)者推入了困惑與絕望的深淵。而且存儲引擎也需要以最優(yōu)的方式來高效地解析join語句。開發(fā)者需要絞盡腦汁編寫查詢語句，然后數(shù)據庫對其進行解析。

這就是很多注重運行速度的開發(fā)者放棄數(shù)據分表轉而使用不規(guī)范數(shù)據表的原因。不區(qū)分數(shù)據實體，將所有數(shù)據保存到一個大表中——以避免復雜的查詢。這樣確實很快，并且云服務器也不會耗盡內存。

磁盤空間現(xiàn)在很廉價。8TB的磁盤已經在售，更大的也要上市了。我們不再需要為使用join而絞盡腦汁了。

4、分支的混亂

是的，一個可靠的、得到良好支持的MySQL分支，可以帶來競爭和選擇，但是它也引起困惑和混亂。更糟糕的是，一個稱為MariaDB的ＭySQL分支，由Monty Widenius維護著。他同樣也在參與編寫MySQL。那么，MariaDB是真正獨立的值得我們擁護的嗎？或者它是MySQL？我們是否應該堅持使用由創(chuàng)建原始MySQL數(shù)據庫的組織運營的核心代碼？或者我們應該加入那些被認為更聰明的，往往很酷的背叛者？

還有，我們應當如何獲得關于兼容性的信息？一方面，我們被確信MariaDB和MySQL十分地相似。另一方面，我們要相信有差異——不然為什么大家都在爭論它？也許它們在性能和我們查詢的范圍內，在兩個陣營中工作方式相同？但也許他們不同-或者將來會不同。

5、存儲引擎混亂

MySQL不是事實上的同一的數(shù)據庫；它由幾個數(shù)據庫組成，它們的大多數(shù)細節(jié)都被統(tǒng)一的表面所掩蓋。在開始的時候，有一個MyISAM引擎，它很快但是在前后一致上不能做到完備。有時候你需要速度并且可以接受不一致的結果時是很好的。

當人們需要更多時，具備完整事務支持的InnoDB出現(xiàn)了。但這還不夠。現(xiàn)在，它可能有20種存儲引擎的選擇——這足以使一個數(shù)據庫管理員瘋狂。當然，有些時候在不同的存儲引擎之間切換而不必重寫你的SQL是很好的，但是切換后總會帶來混亂。這個表格我選擇的引擎是 MyISAM 還是 innoDB 呢？或者，我決定輸出的數(shù)據是CSV格式的嗎？

6、盈利的動機

雖然 MySQL 是一款成功的開源產品，但它仍然是一門生意，里面滿是靠它獲得薪水的專業(yè)開發(fā)者。當大多數(shù)用戶在持續(xù)地享受開源許可證帶來的最佳體驗時，毫無疑問這家公司還在為賺取足夠的錢來維持運營而努力。這導致自由代碼在“社區(qū)版”和出售給企業(yè)的完整產品之間產生了奇怪的分岐。
你應該付錢嗎？你在這里掙到了多少錢？在社區(qū)版之上開展經營行為是否公平？企業(yè)版中額外的功能，是否只是一個噱頭來引誘我們不斷付費呢？這至少說明一點，它是另一組需要回答的問題。選用哪個版本？遵照哪種許可證？選用它的哪個功能集？

7、原生 JSON 支持的缺乏

看 MySQL 的年齡最好的辦法是安裝它，然后你會意識到需要添加更多的驅動程序使它可用。MySQL 通常在 3306 端口上通信，它一般輸出的是它自己難以理解的格式化數(shù)據。如果你想讓你的代碼和它通信，你必須添加另一層的代碼，將 MySQL 的語言轉換成有用的東西。這些層的代碼，以庫的形式分發(fā)，經常需要人們購買一個商業(yè)的許可證。

現(xiàn)代數(shù)據存儲層通常直接以 JSON 通信。雖然 MySQL 和 MariaDB 現(xiàn)在有能力解析 SQL 中的 JSON 部分，但這還遠遠不夠好，原生的 JSON 接口已經在 CouchDB，MongoDB，或任何最新的工具中廣泛使用。

8、封閉源和專有模塊的興起

我說過 MySQL 是開源的嗎？它是，但除了一些在”開源核心“周邊開發(fā)的一些較新的、非開源的代碼、專有模塊。程序員需要吃飯，Oracle需要拿它的辛苦成果來換錢，這是商業(yè)的現(xiàn)實之一。它不像那些醫(yī)院，使用 MySQL 可以免費醫(yī)療護理。它不象那些農民，使用 MySQL 可以贈送食物。

要求 MySQL 始終堅持在一個很高的標準是有點不公平的，因為開源的成功可能是一個圈套。這是因為它開始可以免費，但并不意味著它可以始終如此。如果企業(yè)需要許多新的功能，他們將不得不用這種或那種方式付費。有時向 Oracle 付費，比自己來編寫代碼要便宜得多。有時商業(yè)的、不開源的代碼是有意義的。事實不言而喻。

對于以上關于使用MySQL時有哪些必須注意的事項，大家是不是覺得非常有幫助。如果需要了解更多內容，請繼續(xù)關注我們的行業(yè)資訊，相信你會喜歡上這些內容的。

本文標題：使用MySQL時有哪些必須注意的事項
標題鏈接：http://bm7419.com/article36/jjdjpg.html

成都網站建設公司_創(chuàng)新互聯(lián)，為您提供小程序開發(fā)、商城網站、定制網站、網站建設、微信小程序、網站策劃

廣告

聲明：本網站發(fā)布的內容（圖片、視頻和文字）以用戶投稿、用戶轉載內容為主，如果涉及侵權請盡快告知，我們將會在第一時間刪除。文章觀點不代表本網站立場，如需處理請聯(lián)系客服。電話：028-86922220；郵箱：631063699@qq.com。內容未經允許不得轉載，或轉載時需注明來源： 創(chuàng)新互聯(lián)