distinct的後面若是是多個列,要求因此列都重複的,能夠過濾html
oracle與mysql的區別node
Mysql通常使用自動增加類型,在建立表時只要指定表的主鍵爲auto increment,插入記錄時,不須要再指定該記錄的主鍵值,Mysql將自動增加;Oracle沒有自動增加類型,主
鍵通常使用的序列,插入記錄時將序列號的下一個值付給該字段便可;只是ORM框架是隻要是native主鍵生成策略便可。mysql
MYSQL裏能夠用雙引號包起字符串,ORACLE裏只能夠用單引號包起字符串。在插入和修改字符串前必須作單引號的替換:把全部出現的一個單引號替換成兩個單引號。sql
MYSQL的非空字段也有空的內容,ORACLE裏定義了非空字段就不允許有空的內容。按MYSQL的NOT NULL來定義ORACLE表結構, 導數據的時候會產生錯誤。所以導數據時要對空字符
進行判斷,若是爲NULL或空字符,須要把它改爲一個空格的字符串。數據庫
3. 翻頁的SQL語句的處理
MYSQL處理翻頁的SQL語句比較簡單,用LIMIT 開始位置, 記錄個數;PHP裏還能夠用SEEK定位到結果集的位置。ORACLE處理翻頁的SQL語句就比較繁瑣了。每一個結果集只有一個ROWNUM字段標明它的位置, 而且只能用ROWNUM<100, 不能用ROWNUM>80。
如下是通過分析後較好的兩種ORACLE翻頁SQL語句( ID是惟一關鍵字的字段名 ):服務器
1、基本概念架構
2、Mysql基本介紹併發
三範式定義(範式和反範式)oracle
9. 如何通俗地理解三個範式? 框架
答:第一範式:1NF是對屬性的原子性約束,要求屬性具備原子性,不可再分解;
第二範式:2NF是對記錄的唯一性約束,要求記錄有唯一標識,即實體的唯一性;
第三範式:3NF是對字段冗餘性的約束,即任何字段不能由其餘字段派生出來,它要求字段沒有冗餘。。
範式化設計優缺點:
優勢:
能夠儘可能得減小數據冗餘,使得更新快,體積小
缺點:對於查詢須要多個表進行關聯,減小寫得效率增長讀得效率,更難進行索引優化
反範式化:
優勢:能夠減小表得關聯,能夠更好得進行索引優化
缺點:數據冗餘以及數據異常,數據得修改須要更多的成本
char和varchar:
1.char(n) 若存入字符數小於n,則以空格補於其後,查詢之時再將空格去掉。因此char類型存儲的字符串末尾不能有空格,varchar不限於此。
2.char(n) 固定長度,char(4)無論是存入幾個字符,都將佔用4個字節,varchar是存入的實際字符數+1個字節(n<=255)或2個字節(n>255),
因此varchar(4),存入3個字符將佔用4個字節。
3.char類型的字符串檢索速度要比varchar類型的快。
varchar和text:
1.varchar可指定n,text不能指定,內部存儲varchar是存入的實際字符數+1個字節(n<=255)或2個字節(n>255),text是實際字符數+2個字
節。
2.text類型不能有默認值。
3.varchar可直接建立索引,text建立索引要指定前多少個字符。varchar查詢速度快於text
5.二進制數據(_Blob)
1._BLOB和_text存儲方式不一樣,_TEXT以文本方式存儲,英文存儲區分大小寫,而_Blob是以二進制方式存儲,不分大小寫。
2._BLOB存儲的數據只能總體讀出。
3._TEXT能夠指定字符集,_BLO不用指定字符集。
InnoDB 是 MySQL 默認的事務型存儲引擎,只有在須要 InnoDB 不支持的特性時,才考慮使用其它存儲引擎。
採用 MVCC 來支持高併發,而且實現了四個標準的隔離級別,默認級別是可重複讀。
表是基於聚簇索引創建的,它對主鍵的查詢性能有很高的提高。
內部作了不少優化,包括從磁盤讀取數據時採用的可預測性讀、可以自動在內存中建立哈希索引以加速讀操做的自適應哈希索引、可以加速插入操做的插入緩衝區等。
經過一些機制和工具支持真正的熱備份。
事務
InnoDB 是事務型的。
備份
InnoDB 支持在線熱備份。
崩潰恢復
MyISAM 崩潰後發生損壞的機率比 InnoDB 高不少,並且恢復的速度也更慢。
併發
MyISAM 只支持表級鎖,而 InnoDB 還支持行級鎖。
其它特性
MyISAM 支持全文索引,地理空間索引。
原子性(Atomicity)一個事務必須被視爲一個不可分割的最小工做單元,整個事務中的全部操做要麼所有提交成功,要麼所有失敗回滾,對於一個事務來講,不可能只執行其中的一部分操做。
一致性(Consistency)數據庫老是從一個一致性的狀態轉換到另外一個一致性的狀態。
隔離性(Isolation)一個事務所作的修改在最終提交之前,對其餘事務是不可見的。
持久性(Durability)一旦事務提交,則其所作的修改不會永久保存到數據庫。
4 種隔離級別
READ UNCOMMITTED(未提交讀)髒讀:事務中的修改,即便沒有提交,對其餘事務也都是可見的。
READ COMMITTED(提交讀)不可重複讀:事務從開始直到提交以前,所作的任何修改對其餘事務都是不可見的。
REPEATABLE READ(可重複讀):幻讀:一個事務按相同的查詢條件讀取之前檢索過的數據,其餘事務插入了知足其查詢條件的新數據。產生幻行。
SERIALIZABLE(可串行化) 強制事務串行執行
MVVC是個行級鎖的變種,它在普通讀狀況下避免了加鎖操做,自特定狀況下加鎖。
死鎖是指兩個或兩個以上的進程在執行過程當中,因爭奪資源而形成的一種互相等待的現象,若無外力做用,它們都將沒法推動下去.此時稱系統處於死鎖狀態或系統產生了死鎖,這些永遠在互相等的進程稱爲死鎖進程.
1.儘可能避免併發的執行涉及到修改數據的語句。
2.要求每個事務一次就將全部要使用到的數據所有加鎖,不然就不容許執行。
3.預先規定一個加鎖順序,全部的事務都必須按照這個順序對數據執行封鎖。如不一樣的過程在事務內部對對象的更新執行順序應儘可能保證一致。
4.每一個事務的執行時間不可太長,對程序段的事務可考慮將其分割爲幾個事務。在事務中不要求輸入,應該在事務以前獲得輸入,而後快速執行事務。
5.使用盡量低的隔離級別。
6.數據存儲空間離散法。該方法是指採用各類手段,將邏輯上在一個表中的數據分散的若干離散的空間上去,以便改善對錶的訪問性能。主要經過將大表按行或者列分解爲若干小表,或者按照不一樣的用戶羣兩種方法實現。
7.編寫應用程序,讓進程持有鎖的時間儘量短,這樣其它進程就沒必要花太長的時間等待鎖被釋放。
(1)終止(或撤銷)進程。終止(或撤銷)系統中的一個或多個死鎖進程,直至打破循環環路,使系統從死鎖狀態中解除出來。
(2)搶佔資源。從一個或多個進程中搶佔足夠數量的資源,分配給死鎖進程,以打破死鎖狀態。
一、查看錯誤日誌
由於死鎖被檢測到後會回滾,這些信息都會以異常反應在應用的業務日誌中,經過這些日誌咱們能夠定位到相應的代碼,並把事務的sql給梳理出來。
一、查詢是否鎖表 show OPEN TABLES where In_use > 0;
二、查詢進程 show processlist 查詢到相對應的進程===而後 kill id
三、查看正在鎖的事務 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCKS;
四、查看等待鎖的事務 SELECT * FROM INFORMATION_SCHEMA.INNODB_LOCK_WAITS;
B-Tree 索引是大多數 MySQL 存儲引擎的默認索引類型。
由於再也不須要進行全表掃描,只須要對樹進行搜索便可,所以查找速度快不少。
能夠指定多個列做爲索引列,多個索引列共同組成鍵。B-Tree 索引適用於全鍵值、鍵值範圍和鍵前綴查找,其中鍵前綴查找只適用於最左前綴查找。
除了用於查找,還能夠用於排序和分組。
若是不是按照索引列的順序進行查找,則沒法使用索引。
基於哈希表實現,優勢是查找很是快。
在 MySQL 中只有 Memory 引擎顯式支持哈希索引。
InnoDB 引擎有一個特殊的功能叫「自適應哈希索引」,當某個索引值被使用的很是頻繁時,會在 B-Tree 索引之上再建立一個哈希索引,這樣就讓 B-Tree 索引具備哈希索引的一些優勢,好比快速的哈希查找。
限制:哈希索引只包含哈希值和行指針,而不存儲字段值,因此不能使用索引中的值來避免讀取行。不過,訪問內存中的行的速度很快,因此大部分狀況下這一點對性能影響並不明顯;沒法用於分組與排序;只支持精確查找,沒法用於部分查找和範圍查找;若是哈希衝突不少,查找速度會變得很慢。
大大減小了服務器須要掃描的數據量;
幫助服務器避免進行排序和建立臨時表;
將隨機 I/O 變爲順序 I/O。
定時器
熱備份
錯誤日誌:記錄了當 mysqld 啓動和中止時,以及服務器在 運行過程當中發生任何嚴重錯誤時的相關信息。
二進制文件:記錄了全部的 DDL(數據定義語言)語句和 DML(數據操縱語言) 語句,不包括數據查詢語句。語句以「事件」的形式保存,它描述了數據的更改過程。(按期刪除日誌,默認關閉)。
查詢日誌:記錄了客戶端的全部語句,格式爲純文本格式,能夠直接進行讀取。(log 日誌中記錄了全部數據庫的操做,對於訪問頻繁的系統,此日誌對系統性能的影響較大,建議關閉,默認關閉)。
慢查詢日誌:慢查詢日誌記錄了包含全部執行時間超過參數long_query_time(單位:秒)所設置值的 SQL 語句的日誌。(純文本格式)MySQL日誌文件之錯誤日誌和慢查詢日誌詳解。
日誌文件小結:
系統故障時,建議首先查看錯誤日誌,以幫助用戶迅速定位故障緣由。
記錄數據的變動、數據的備份、數據的複製等操做時,打開二進制日誌。默認不記錄此日誌,建議經過--log-bin 選項將此日誌打開。
若是但願記錄數據庫發生的任何操做,包括 SELECT,則須要用--log 將查詢日誌打開, 此日誌默認關閉,通常狀況下建議不要打開此日誌,以避免影響系統總體性能。
查看系統的性能問題, 但願找到有性能問題的SQL語 句,須要 用 --log-slow-queries 打開慢查詢日誌。對於大量的慢查詢日誌,建議使用 mysqldumpslow 工具 來進行彙總查看。
drop,delete與truncate的區別
(1)DELETE語句執行刪除的過程是每次從表中刪除一行,而且同時將該行的刪除操做做爲事務記錄在日誌中保存以便進行進行回滾操做。
TRUNCATE TABLE 則一次性地從表中刪除全部的數據並不把單獨的刪除操做記錄記入日誌保存,刪除行是不能恢復的。而且在刪除的過程當中不會激活與表有關的刪除觸發器。執行速度快。
數據庫的優化
MySQL能夠很好的支持大數據量的存取,可是通常說來,數據庫中的表越小,在它上面執行的查詢也就會越快。所以,在建立表的時候,爲了得到更好的性能,咱們能夠將表中字段的寬度設得儘量小。
例如,在定義郵政編碼這個字段時,若是將其設置爲CHAR(255),顯然給數據庫增長了沒必要要的空間,甚至使用VARCHAR這種類型也是多餘的,由於CHAR(6)就能夠很好的完成任務了。一樣的,若是能夠的話,咱們應該使用MEDIUMINT而不是BIGIN來定義整型字段。
另一個提升效率的方法是在可能的狀況下,應該儘可能把字段設置爲NOTNULL,這樣在未來執行查詢的時候,數據庫不用去比較NULL值。
對於某些文本字段,例如「省份」或者「性別」,咱們能夠將它們定義爲ENUM類型。由於在MySQL中,ENUM類型被看成數值型數據來處理,而數值型數據被處理起來的速度要比文本類型快得多。這樣,咱們又能夠提升數據庫的性能。
鏈接(JOIN)..之因此更有效率一些,是由於MySQL不須要在內存中建立臨時表來完成這個邏輯上的須要兩個步驟的查詢工做。
儘管咱們可使用子查詢(Sub-Queries)、鏈接(JOIN)和聯合(UNION)來建立各類各樣的查詢,但不是全部的數據庫操做均可以只用一條或少數幾條SQL語句就能夠完成的。更多的時候是須要用到一系列的語句來完成某種工做。可是在這種狀況下,當這個語句塊中的某一條語句運行出錯的時候,整個語句塊的操做就會變得不肯定起來。設想一下,要把某個數據同時插入兩個相關聯的表中,可能會出現這樣的狀況:第一個表中成功更新後,數據庫忽然出現意外情況,形成第二個表中的操做沒有完成,這樣,就會形成數據的不完整,甚至會破壞數據庫中的數據。要避免這種狀況,就應該使用事務,它的做用是:要麼語句塊中每條語句都操做成功,要麼都失敗。換句話說,就是能夠保持數據庫中數據的一致性和完整性。事物以BEGIN關鍵字開始,COMMIT關鍵字結束。在這之間的一條SQL操做失敗,那麼,ROLLBACK命令就能夠把數據庫恢復到BEGIN開始以前的狀態。
鎖定表的方法能夠維護數據的完整性,可是它卻不能保證數據的關聯性。這個時候咱們就可使用外鍵。
例如,外鍵能夠保證每一條銷售記錄都指向某一個存在的客戶。在這裏,外鍵能夠把customerinfo表中的CustomerID映射到salesinfo表中CustomerID,任何一條沒有合法CustomerID的記錄都不會被更新或插入到salesinfo中。
建索引