程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 數據庫知識 >> MYSQL數據庫 >> MySQL綜合教程 >> 8個不得不說的MySQL陷阱

8個不得不說的MySQL陷阱

編輯:MySQL綜合教程

8個不得不說的MySQL陷阱


MySQL安裝簡單,速度較快,功能豐富。另外它還是開源運動的標桿,它的偉大成就向我們展示了一個成功的公司是可以建立在開源代碼之上的。

然而用過mysql的人都曾對著顯示器揮舞過拳頭。但你不可能發明一種每秒能保存成千上萬行互聯網數據,並且一點錯誤都沒有的技術吧。

為了在這個夏天躁起來,我們列舉了8個抱怨開源關系型數據庫的理由。下面列舉的理由中不僅限於 MySQL,有一些是針對關系型數據庫的。如果我們沒有理清楚關系型數據庫和 MySQL,我們將會永遠陷入90年代的思想上。我們需要推倒然後重建這些。或者我們轉向使用一個最近流行的,存在時間沒有長到可以列出一堆像下面一樣的理由的數據庫。

\

根深蒂固的bugs

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

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

關系表的不靈活性

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

試想一下,你用整數格式建立了一個全部是郵編的表格。這個表是十分高效的,它執行的規則也很好。突然一次,有人上傳了一個使用了連字符的九位數郵編。或者還有可能,你得到了一位來自加拿大客戶的信件,上面寫有郵政編碼。

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

MySQL的關聯規則讓每個人都誠實和謹慎,但它能強制我們避開易受攻擊和欺騙的麻煩。

JOIN聯合查詢

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

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

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

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

分支的混亂

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

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

存儲引擎混亂

MySQL不是事實上的同一的數據庫;它由幾個數據庫組成,它們的大多數細節都被統一的表面所掩蓋。在開始的時候,有一個MyISAM引擎,它很快但是在前後一致上不能做到完備。有時候你需要速度並且可以接受不一致的結果時是很好的。

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

盈利的動機

雖然 MySQL 是一款成功的開源產品,但它仍然是一門生意,裡面滿是靠它獲得薪水的專業開發者。當大多數用戶在持續地享受開源許可證帶來的最佳體驗時,毫無疑問這家公司還在為賺取足夠的錢來維持運營而努力。這導致自由代碼在“社區版”和出售給企業的完整產品之間產生了奇怪的分岐。

你應該付錢嗎?你在這裡掙到了多少錢?在社區版之上開展經營行為是否公平?企業版中額外的功能,是否只是一個噱頭來引誘我們不斷付費呢?這至少說明一點,它是另一組需要回答的問題。選用哪個版本?遵照哪種許可證?選用它的哪個功能集?

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved