您好,登錄后才能下訂單哦!
這篇文章給大家分享的是有關php+mysql開發中的基礎知識有哪些的內容。小編覺得挺實用的,因此分享給大家做個參考,一起跟隨小編過來看看吧。
支持事務、行級鎖、并發性能更好,CPU 及內存緩存頁優化得當,資源利用率更高
無需轉碼,無亂碼風險
N 年后誰知道這個 r1,r2,r3 字段是干嘛的
高并發大數據的互聯網業務,架構設計思路是“解放數據庫 CPU,將計算轉移到服務層”,并發量大的情況下,這些功能很可能將數據庫拖死,業務邏輯放到服務層具備更好的擴展性,能夠輕易實現“增機器就加性能”。數據庫擅長存儲與索引,CPU 計算盡量挪到上層
不要讓數據庫做它不擅長的事情。大文件和照片存儲在文件系統(使用上傳服務),數據庫里存 URI
a)主鍵遞增,數據行寫入可以提高插入性能,可以避免 page 分裂,減少表碎片,提升空間和內存的使用
b)主鍵要選擇較短的數據類型, Innodb 引擎普通索引都會保存主鍵的值,較短的數據類型可以有效的減少索引的磁盤空間,提高索引的緩存效率c) 無主鍵的表刪除,在 row 模式的主從架構,會導致備庫卡住
外鍵會導致表與表之間耦合,update 與 delete 操作都會涉及相關聯的表,十分影響 sql 的性能,甚至會造成死鎖。高并發情況下容易造成數據庫性能,大數據高并發業務場景數據庫使用以性能優先
a)null 的列使索引/索引統計/值比較都更加復雜,對 MySQL 來說更難優化
b)null 這種類型 MySQL 內部需要進行特殊處理,增加數據庫處理記錄的復雜性;同等條件下,表中有較多空字段的時候,數據庫的處理性能會降低很多
c)null 值需要更多的存儲空間,無論是表還是索引中每行中的 null 的列都需要額外的空間來標識
d)對 null 的處理時候,只能采用 is null 或 is not null,而不能采用=、in、<、<>、!=、 not in 這些操作符號。如:where name!='cuiyang',如果存在 name 為 null 值的記錄,查詢結果就不會包含 name 為 null 值的記錄
會浪費更多的磁盤和內存空間,非必要的大量的大字段查詢會淘汰掉熱數據,導致內存命中率急劇降低,影響數據庫性能
使用整數存儲,小數容易導致錢對不上
a)涉及到區號或者國家代號,可能出現+-()
b)手機號會去做數學運算么?
c)varchar 可以支持模糊查詢,例如:like“138%”
a)增加新的 ENUM 值要做 DDL 操作
b)ENUM 的內部實際存儲就是整數,你以為自己定義的是字符串?
字段超過 5 個時,實際已經起不到有效過濾數據的作用了
a)更新會變更 B+樹,更新頻繁的字段建立索引會大大降低數據庫性能
b)“性別”這種區分度不大的屬性,建立索引是沒有什么意義的,不能有效過濾數據,性能與全表掃描類似
能夠更加有效的過濾數據
a)讀取不需要的列會增加 CPU、IO、NET 消耗
b)不能有效的利用覆蓋索引
c)使用 SELECT *容易在增加或者刪除字段后出現程序 BUG
容易在增加或者刪除字段后出現程序 BUG
SELECT uid FROM t_user WHERE phone=13812345678
會導致全表掃描,而不能命中 phone 索引
(24)避免在 WHERE 條件的屬性上使用函數或者表達式
SELECT uid FROM t_user WHERE from_unixtime(day)>='2017-02-15'
會導致全表掃描正確的寫法是:
SELECT uid FROM t_user WHERE day>= unix_timestamp(‘2017-02-15 00:00:00')
a)負向查詢條件:NOT、!=、<>、!<、!>、NOT IN、NOT LIKE 等,會導致全表掃描
b)%開頭的模糊查詢,會導致全表掃描
會產生臨時表,消耗較多內存與 CPU,極大影響數據庫性能
舊版本 Mysql 的 OR 查詢是不能命中索引的,即使能命中索引,數據庫也需要耗費更多的 CPU 幫助實施查詢優化
感謝各位的閱讀!關于“php+mysql開發中的基礎知識有哪些”這篇文章就分享到這里了,希望以上內容可以對大家有一定的幫助,讓大家可以學到更多知識,如果覺得文章不錯,可以把它分享出去讓更多的人看到吧!
免責聲明:本站發布的內容(圖片、視頻和文字)以原創、轉載和分享為主,文章觀點不代表本網站立場,如果涉及侵權請聯系站長郵箱:is@yisu.com進行舉報,并提供相關證據,一經查實,將立刻刪除涉嫌侵權內容。