mysql密碼修改,存儲過程的優缺點我的總結

在 Linux 主機中在命令提示行下輸入下面的命令java

> MySQL -uroot -p123456

  123456 爲 root 用戶的密碼。
建立遠程登錄用戶並受權程序員

>grant all PRIVILEGES on *.* to liuwei@'%' identified by 'xingwi2017';

上面的語句表示將 discuz 數據庫的全部權限受權給 ted 這個用戶,容許 ted 用戶在
123.123.123.123 這個 IP 進行遠程登錄,並設置 ted 用戶的密碼爲 123456 。
下面逐一分析全部的參數:
all PRIVILEGES 表示賦予全部的權限給指定用戶,這裏也能夠替換爲賦予某一具體的權限,
例如:select,insert,update,delete,create,drop 等,具體權限間用「,」半角逗號分隔。
discuz.* 表示上面的權限是針對於哪一個表的,discuz 指的是數據庫,後面的 * 表示對於所
有的表,由此能夠推理出:對於所有數據庫的所有表受權爲「*.*」,對於某一數據庫的所有
表受權爲「數據庫名.*」,對於某一數據庫的某一表受權爲「數據庫名.表名」。
ted 表示你要給哪一個用戶受權,這個用戶能夠是存在的用戶,也能夠是不存在的用戶。
123.123.123.123 表示容許遠程鏈接的 IP 地址,若是想不限制連接的 IP 則設置爲「%」便可。
123456 爲用戶的密碼。
執行了上面的語句後,再執行下面的語句,方可當即生效。面試

FLUSH PRIVILEGES;

公司的系統是自主開發的,歷史比較悠久,有很多是傳統C/S架構,採用存儲過程來處理業務邏輯。數據庫

近來作新系統的時候,我採用了三層架構,拋棄存儲過程改用ORM。緩存

有同事問及不用存儲過程的理由,我想了一下,對存儲過程作了以下總結。服務器

本人經驗和水平有限,總結有所偏頗,還請你們糾察。網絡

優勢架構

1.在生產環境下,能夠經過直接修改存儲過程的方式修改業務邏輯(或bug),而不用重啓服務器。但這一點便利被許多人濫用了。有人直接就在正式服務器上修改存儲過程,而沒有通過完整的測試,後果很是嚴重。併發

2.執行速度快。存儲過程通過編譯以後會比單獨一條一條執行要快。但這個效率真是沒太大影響。若是是要作大數據量的導入、同步,咱們能夠用其它手段。框架

3.減小網絡傳輸。存儲過程直接就在數據庫服務器上跑,全部的數據訪問都在服務器內部進行,不須要傳輸數據到其它終端。但咱們的應付服務器一般與數據庫是在同一內網,大數據的訪問的瓶頸會是硬盤的速度,而不是網速。

4.可以解決presentation與數據之間的差別,說得文藝青年點就是解決OO模型與二維數據持久化之間的阻抗。領域模型和數據模型的設計可能不是同一我的(一個是SA,另外一個是DBA),二者的分歧可能會很大——這不奇怪,一個是以OO的思想來設計,一個是結構化的數據來設計,你們互不妥協——你說爲了軟件的彈性必須這麼設計,他說爲了效率必須那樣設計,爲了抹平鴻溝,就用存儲過程來作數據存儲的邏輯映射(把屬性映射到字段)。好吧,臺下已經有同窗在叨咕ORM了。

5.方便DBA優化。全部的SQL集中在一個地方,DBA會很高興。這一點算是ORM的軟肋。不過按照CQRS框架的思想,查詢是用存儲過程仍是ORM,還真不是問題——DBA對數據庫的優化,ORM同樣會受益。何況放在ORM中還能用二級緩存,有些時候效率還會更高。

 

缺點

1.SQL自己是一種結構化查詢語言,加上了一些控制(賦值、循環和異常處理等),但不是OO的,本質上仍是過程化的,面對複雜的業務邏輯,過程化的處理會很吃力。這一點算致命傷。

2.不便於調試。基本上沒有較好的調試器,不少時候是用print來調試,但用這種方法調試長達數百行的存儲過程簡直是噩夢。好吧,這一點不算啥,C#/java同樣能寫出噩夢般的代碼。

3.沒辦法應用緩存。雖然有全局臨時表之類的方法能夠作緩存,但一樣加劇了數據庫的負擔。若是緩存併發嚴重,常常要加鎖,那效率實在堪憂。

4.沒法適應數據庫的切割(水平或垂直切割)。數據庫切割以後,存儲過程並不清楚數據存儲在哪一個數據庫中。

5.精通SQL的新手愈來愈少——不要笑,這是真的,我面試過N多新人,都不知道如何建立全局臨時表、不知道having、不知道彙集索引和非彙集索引,更別提遊標和提交叉表查詢了。好吧,這個缺點算是湊數用的,做爲屌絲程序員,咱們的口號是:沒有不會的,只有不用的。除了少數有語言潔癖的人,我相信精通SQL只是時間問題。

 

總結

存儲過程最大的優勢是部署的方便性——能夠在生產環境下直接修改——雖然濫用的後果很嚴重。

存儲過程最大的缺點是SQL語言自己的侷限性——咱們不該該用存儲過程處理複雜的業務邏輯——讓SQL迴歸它「結構化查詢語言」的功用吧。

相關文章
相關標籤/搜索