java基礎問題（轉）

時間 2019-11-29

原文原文鏈接

原文地址：http://blog.csdn.net/free0sky/article/details/7927275php

1、String,StringBuffer, StringBuilder 的區別是什麼？String爲何是不可變的？
html

答：一、String是字符串常量，StringBuffer和StringBuilder都是字符串變量。後二者的字符內容可變，而前者建立後內容不可變。java

二、String不可變是由於在JDK中String類被聲明爲一個final類。程序員

三、StringBuffer是線程安全的，而StringBuilder是非線程安全的。web

ps：線程安全會帶來額外的系統開銷，因此StringBuilder的效率比StringBuffer高。若是對系統中的線程是否安全很掌握，可用StringBuffer，在線程不安全處加上關鍵字Synchronize。sql

2、Vector,ArrayList, LinkedList的區別是什麼？數據庫

答：一、Vector、ArrayList都是以相似數組的形式存儲在內存中，LinkedList則以鏈表的形式進行存儲。編程

二、List中的元素有序、容許有重複的元素，Set中的元素無序、不容許有重複元素。設計模式

三、Vector線程同步，ArrayList、LinkedList線程不一樣步。數組

四、LinkedList適合指定位置插入、刪除操做，不適合查找；ArrayList、Vector適合查找，不適合指定位置的插入、刪除操做。

五、ArrayList在元素填滿容器時會自動擴充容器大小的50%，而Vector則是100%，所以ArrayList更節省空間。

詳見：http://www.cnblogs.com/mgod/archive/2007/08/05/844011.html

3、HashTable, HashMap，TreeMap區別？

答：一、HashTable線程同步，HashMap非線程同步。

二、HashTable不容許<鍵,值>有空值，HashMap容許<鍵,值>有空值。

三、HashTable使用Enumeration，HashMap使用Iterator。

四、HashTable中hash數組的默認大小是11，增長方式的old*2+1，HashMap中hash數組的默認大小是16，增加方式必定是2的指數倍。

五、TreeMap可以把它保存的記錄根據鍵排序，默認是按升序排序。

詳見：http://www.zlmind.com/?p=679

5、Tomcat，Apache，JBoss的區別？

答：一、Apache是Http服務器，Tomcat是web服務器，JBoss是應用服務器。

二、Apache解析靜態的html文件；Tomcat可解析jsp動態頁面、也可充當servlet容器。

詳見：http://foohsinglong.iteye.com/blog/1195780

6、GET，POST區別？

答：基礎知識：Http的請求格式以下。

<request line> 主要包含三個信息：一、請求的類型（GET或POST），二、要訪問的資源（如\res\img\a.jif），三、Http版本（http/1.1）

<header> 用來講明服務器要使用的附加信息

<blank line> 這是Http的規定，必須空一行

[<request-body>] 請求的內容數據

區別：

一、Get是從服務器端獲取數據，Post則是向服務器端發送數據。

二、在客戶端，Get方式經過URL提交數據，在URL地址欄能夠看到請求消息，該消息被編碼過；Post數據則是放在Html header內提交。

三、對於Get方式，服務器端用Request.QueryString獲取變量的值；對用Post方式，服務器端用Request.Form獲取提交的數據值。

四、Get方式提交的數據最多1024字節，而Post則沒有限制。

五、Get方式提交的參數及參數值會在地址欄顯示，不安全，而Post不會，比較安全。

詳見：http://www.cnblogs.com/wxf0701/archive/2008/08/17/1269798.html

7、Session, Cookie區別

答：一、Session由應用服務器維護的一個服務器端的存儲空間；Cookie是客戶端的存儲空間，由瀏覽器維護。

二、用戶能夠經過瀏覽器設置決定是否保存Cookie，而不能決定是否保存Session，由於Session是由服務器端維護的。

三、Session中保存的是對象，Cookie中保存的是字符串。

四、Session和Cookie不能跨窗口使用，每打開一個瀏覽器系統會賦予一個SessionID，此時的SessionID不一樣，若要完成跨瀏覽器訪問數據，可使用 Application。

五、Session、Cookie都有失效時間，過時後會自動刪除，減小系統開銷。

詳見：http://www.chinahtml.com/1007/128010707619425.html

8、Servlet的生命週期

答：大體分爲4部：Servlet類加載-->實例化-->服務-->銷燬

下圖是Tomcat中Servlet時序圖。

一、Web Client向Servlet容器(Tomcat)發出Http請求。

二、Servlet容器接收Client端的請求。

三、Servlet容器建立一個HttpRequest對象，將Client的請求信息封裝到這個對象中。

四、Servlet建立一個HttpResponse對象。

五、Servlet調用HttpServlet對象的service方法，把HttpRequest對象和HttpResponse對象做爲參數傳遞給HttpServlet對象中。

六、HttpServlet調用HttpRequest對象的方法，獲取Http請求，並進行相應處理。

七、處理完成HttpServlet調用HttpResponse對象的方法，返回響應數據。

八、Servlet容器把HttpServlet的響應結果傳回客戶端。

其中的3個方法說明了Servlet的生命週期：

一、init()：負責初始化Servlet對象。

二、service()：負責響應客戶端請求。

三、destroy()：當Servlet對象推出時，負責釋放佔用資源。

詳見：http://sunnylocus.iteye.com/blog/342996

9、HTTP 報文包含內容

答：主要包含四部分：

一、request line

二、header line

三、blank line

四、request body

詳見：http://blog.csdn.net/heruiup/article/details/6072961

10、Statement與PreparedStatement的區別,什麼是SQL注入，如何防止SQL注入

答：一、PreparedStatement支持動態設置參數，Statement不支持。

二、PreparedStatement可避免如相似單引號的編碼麻煩，Statement不能夠。

三、PreparedStatement支持預編譯，Statement不支持。

四、在sql語句出錯時PreparedStatement不易檢查，而Statement則更便於查錯。

五、PreparedStatement可防止Sql助於，更加安全，而Statement不行。

詳見：http://blog.163.com/xiaokangzhijia@126/blog/static/1659548562010927222912/

什麼是SQL注入：

經過sql語句的拼接達到無參數查詢數據庫數據目的的方法。

如將要執行的sql語句爲 select * from table where name = "+appName+"，利用appName參數值的輸入，來生成惡意的sql語句，如將['or'1'='1'] 傳入可在數據庫中執行。

所以能夠採用PrepareStatement來避免Sql注入，在服務器端接收參數數據後，進行驗證，此時PrepareStatement會自動檢測，而Statement不行，須要手工檢測。

11、sendRedirect, foward區別

答：一、foward是服務器端控制頁面轉向，在客戶端的瀏覽器地址中不會顯示轉向後的地址；sendRedirect則是徹底的跳轉，瀏覽器中會顯示跳轉的地址並重新發送請求連接。

原理：forward是服務器請求資源，服務器直接訪問目標地址的URL，把那個URL的響應內容讀取過來，而後再將這些內容返回給瀏覽器，瀏覽器根本不知道服務器發送的這些內容是從哪來的，因此地址欄仍是原來的地址。

redirect是服務器端根據邏輯，發送一個狀態碼，告訴瀏覽器從新去請求的那個地址，瀏覽器會用剛纔的全部參數從新發送新的請求。

詳見：http://dubaopeng.iteye.com/blog/1056564

12、關於JAVA內存模型，一個對象（兩個屬性，四個方法）實例化100次，如今內存中的存儲狀態，幾個對象，幾個屬性，幾個方法。

答：因爲JAVA中new出來的對象都是放在堆中，因此若是要實例化100次，將在堆中產生100個對象，通常對象與其中的屬性、方法都屬於一個總體，但若是屬性和方法是靜態的，就是用static關鍵字聲明的，那麼屬於類的屬性和方法永遠只在內存中存在一份。

詳見：http://wenwen.soso.com/z/q252323203.htm?sp=4000

十3、談談Hibernate的理解，一級和二級緩存的做用，在項目中Hibernate都是怎麼使用緩存的。

答： Hibernate是一個開發的對象關係映射框架（ORM）。它對JDBC進行了很是對象封裝，Hibernate容許程序員採用面向對象的方式來操做關係數據庫。

Hibernate的優勢：

一、程序更加面向對象

二、提升了生產率

三、方便移植

四、無入侵性。

缺點：

一、效率比JDBC略差

二、不適合批量操做

三、只能配置一種關聯關係

Hibernate有四種查詢方式：

一、get、load方法，根據id號查詢對象。

二、Hibernate query language

三、標準查詢語言

四、經過sql查詢

Hibernage工做原理：

一、配置hibernate對象關係映射文件、啓動服務器

二、服務器經過實例化Configuration對象，讀取hibernate.cfg.xml文件的配置內容，並根據相關的需求建好表以及表之間的映射關係。

三、經過實例化的Configuration對象創建SeesionFactory實例，經過SessionFactory實例建立Session對象。

四、經過Seesion對象完成數據庫的增刪改查操做。

Hibernate中的狀態轉移

臨時狀態（transient）

一、不處於session緩存中

二、數據庫中沒有對象記錄

java是如何進入臨時狀態的：一、經過new語句建立一個對象時。二、剛調用session的delete方法時，從seesion緩存中刪除一個對象時。

持久化狀態(persisted)

一、處於session緩存中

二、持久化對象數據庫中沒有對象記錄

三、seesion在特定的時刻會保存二者同步

java如何進入持久化狀態：一、seesion的save()方法。二、seesion的load().get()方法返回的對象。三、seesion的find()方法返回的list集合中存放的對象。四、Session的update().save()方法。

流離狀態（detached）

一、再也不位於session緩存中

二、遊離對象由持久化狀態轉變而來，數據庫中尚未相應記錄。

java如何進入流離狀態：一、Session的close()。Session的evict()方法，從緩存中刪除一個對象。

具體以下圖所示：

Hibernate中的緩存主要有Session緩存（一級緩存）和SessionFactory緩存（二級緩存，通常由第三方提供）。

詳見：http://wxg6203.iteye.com/blog/766947 http://jyjiao2007.iteye.com/blog/760554

十4、反射講一講，主要是概念,都在哪須要反射機制，反射的性能，如何優化

答：反射機制的定義：

是在運行狀態中，對於任意的一個類，都可以知道這個類的全部屬性和方法，對任意一個對象都可以經過反射機制調用一個類的任意方法，這種動態獲取類信息及動態調用類對象方法的功能稱爲java的反射機制。

反射的做用：

一、動態地建立類的實例，將類綁定到現有的對象中，或從現有的對象中獲取類型。

二、應用程序須要在運行時從某個特定的程序集中載入一個特定的類

詳見：http://blog.csdn.net/p785810989/article/details/6495956

十5、談談Hibernate與Ibatis的區別，哪一個性能會更高一些

答：一、Hibernate偏向於對象的操做達到數據庫相關操做的目的；而ibatis更偏向於sql語句的優化。

二、Hibernate的使用的查詢語句是本身的hql，而ibatis則是標準的sql語句。

三、Hibernate相對複雜，不易學習；ibatis相似sql語句，簡單易學。

性能方面：

一、若是系統數據處理量巨大，性能要求極爲苛刻時，每每須要人工編寫高性能的sql語句或存錯過程，此時ibatis具備更好的可控性，所以性能優於Hibernate。

二、一樣的需求下，因爲hibernate能夠自動生成hql語句，而ibatis須要手動寫sql語句，此時採用Hibernate的效率高於ibatis。
詳見：http://blog.csdn.net/cdh1213/article/details/5967405 http://wenku.baidu.com/view/06c4486aaf1ffc4ffe47acfb.html

十6、對Spring的理解，項目中都用什麼？怎麼用的？對IOC、和AOP的理解及實現原理

答： Spring是一個開源框架，處於MVC模式中的控制層，它能應對需求快速的變化，其主要緣由它有一種面向切面編程（AOP）的優點，其次它提高了系統性能，由於經過依賴倒置機制（IOC），系統中用到的對象不是在系統加載時就所有實例化，而是在調用到這個類時纔會實例化該類的對象，從而提高了系統性能。這兩個優秀的性能使得Spring受到許多J2EE公司的青睞，如阿里裏中使用最多的也是Spring相關技術。

Spring的優勢：

一、下降了組件之間的耦合性，實現了軟件各層之間的解耦。

二、可使用容易提供的衆多服務，如事務管理，消息服務，日誌記錄等。

三、容器提供了AOP技術，利用它很容易實現如權限攔截、運行期監控等功能。

Spring中AOP技術是設計模式中的動態代理模式。只需實現jdk提供的動態代理接口InvocationHandler，全部被代理對象的方法都由InvocationHandler接管實際的處理任務。面向切面編程中還要理解切入點、切面、通知、織入等概念。

Spring中IOC則利用了Java強大的反射機制來實現。所謂依賴注入即組件之間的依賴關係由容器在運行期決定。其中依賴注入的方法有兩種，經過構造函數注入，經過set方法進行注入。

詳見：http://www.360doc.com/content/08/0113/20/7635_970484.shtml http://www.zlmind.com/?p=694

十7、線程同步，併發操做怎麼控制

答： Java中可在方法名前加關鍵字syschronized來處理當有多個線程同時訪問共享資源時候的問題。syschronized至關於一把鎖，當有申請者申請該

資源時，若是該資源沒有被佔用，那麼將資源交付給這個申請者使用，在此期間，其餘申請者只能申請而不能使用該資源，當該資源被使用完成後將釋放該資源上的鎖，其餘申請者可申請使用。

併發控制主要是爲了多線程操做時帶來的資源讀寫問題。若是不加以空間可能會出現死鎖，讀髒數據、不可重複讀、丟失更新等異常。

併發操做能夠經過加鎖的方式進行控制，鎖又可分爲樂觀鎖和悲觀鎖。

悲觀鎖：

悲觀鎖併發模式假定系統中存在足夠多的數據修改操做，以至於任何肯定的讀操做均可能會受到由個別的用戶所製造的數據修改的影響。也就是說悲觀鎖假定衝突總會發生，經過獨佔正在被讀取的數據來避免衝突。可是獨佔數據會致使其餘進程沒法修改該數據，進而產生阻塞，讀數據和寫數據會相互阻塞。

樂觀鎖：

樂觀鎖假定系統的數據修改只會產生很是少的衝突，也就是說任何進程都不大可能修改別的進程正在訪問的數據。樂觀併發模式下，讀數據和寫數據之間不會發生衝突，只有寫數據與寫數據之間會發生衝突。即讀數據不會產生阻塞，只有寫數據纔會產生阻塞。

詳見：http://www.cnblogs.com/ego/articles/1514350.html http://blog.csdn.net/niu870781892/article/details/6140755

十8、描述struts的工做流程

答：一、在web應用啓動時，加載並初始化ActionServlet，ActionServlet從struts-config.xml文件中讀取配置信息，將它們存放到各個配置對象中。

二、當ActionServlet接收到一個客戶請求時，首先檢索和用戶請求相匹配的ActionMapping實例，若是不存在，就返回用戶請求路徑無效信息。

三、若是ActionForm實例不存在，就建立一個ActionForm對象，把客戶提交的表單數據保存到ActionForm對象中。

四、根據配置信息決定是否須要驗證表單，若是須要，就調用ActionForm的validate()方法，若是ActionForm的validate() 方法返回null或返回一個不包含ActionMessage的ActionErrors對象，就表示表單驗證成功。

五、ActionServlet根據ActionMapping實例包含的映射信息決定請求轉發給哪一個Action，若是相應的Action實例不存在，就先建立一個實例，而後調用Action的execute()方法。

六、Action的execute()方法返回一個ActionForward對象，ActionServlet再把客戶請求轉發給ActionForward對象指向的JSP組件。

七、ActionForward對象指向的JSP組件生成動態網頁，返回給客戶。

十9、Tomcat的session處理，若是讓你實現一個tomcatserver，如何實現session機制

答：沒有找到合適的答案。

二10、關於Cache(Ehcache,Memcached)

答：詳見：http://xuezhongfeicn.blog.163.com/blog/static/2246014120106144143737/

二1、sql的優化相關問題

答：這篇文章寫的真心不錯，值得仔細拜讀，因此將其轉載過來了。

近期因工做須要，但願比較全面的總結下SQL SERVER數據庫性能優化相關的注意事項，在網上搜索了一下,發現不少文章,有的都列出了上百條,可是仔細看發現，有不少似是而非或者過期(可能對 SQL SERVER6.5之前的版本或者ORACLE是適用的)的信息，只好本身根據之前的經驗和測試結果進行總結了。

我始終認爲，一個系統的性能的提升，不僅僅是試運行或者維護階段的性能調優的任務，也不僅僅是開發階段的事情，而是在整個軟件生命週期都須要注意，進行有效工做才能達到的。因此我但願按照軟件生命週期的不一樣階段來總結數據庫性能優化相關的注意事項。

1、分析階段

一般來講，在系統分析階段每每有太多須要關注的地方，系統各類功能性、可用性、可靠性、安全性需求每每吸引了咱們大部分的注意力，可是，咱們必須注意，性能是很重要的非功能性需求，必須根據系統的特色肯定其實時性需求、響應時間的需求、硬件的配置等。最好能有各類需求的量化的指標。

另外一方面，在分析階段應該根據各類需求區分出系統的類型，大的方面，區分是OLTP（聯機事務處理系統）和OLAP（聯機分析處理系統）。

2、設計階段

設計階段能夠說是之後系統性能的關鍵階段，在這個階段，有一個關係到之後幾乎全部性能調優的過程—數據庫設計。

在數據庫設計完成後，能夠進行初步的索引設計，好的索引設計能夠指導編碼階段寫出高效率的代碼，爲整個系統的性能打下良好的基礎。

如下是性能要求設計階段須要注意的：

一、數據庫邏輯設計的規範化

數據庫邏輯設計的規範化就是咱們通常所說的範式，咱們能夠這樣來簡單理解範式：

第1規範：沒有重複的組或多值的列，這是數據庫設計的最低要求。

第2規範: 每一個非關鍵字段必須依賴於主關鍵字，不能依賴於一個組合式主關鍵字的某些組成部分。消除部分依賴，大部分狀況下，數據庫設計都應該達到第二範式。

第3規範: 一個非關鍵字段不能依賴於另外一個非關鍵字段。消除傳遞依賴，達到第三範式應該是系統中大部分表的要求，除非一些特殊做用的表。

更高的範式要求這裏就再也不做介紹了，我的認爲，若是所有達到第二範式，大部分達到第三範式，系統會產生較少的列和較多的表，於是減小了數據冗餘，也利於性能的提升。

二、合理的冗餘

徹底按照規範化設計的系統幾乎是不可能的，除非系統特別的小，在規範化設計後，有計劃地加入冗餘是必要的。

冗餘能夠是冗餘數據庫、冗餘表或者冗餘字段，不一樣粒度的冗餘能夠起到不一樣的做用。

冗餘能夠是爲了編程方便而增長，也能夠是爲了性能的提升而增長。從性能角度來講，冗餘數據庫能夠分散數據庫壓力，冗餘表能夠分散數據量大的表的併發壓力，也能夠加快特殊查詢的速度，冗餘字段能夠有效減小數據庫表的鏈接，提升效率。

三、主鍵的設計

主鍵是必要的，SQL SERVER的主鍵同時是一個惟一索引，並且在實際應用中，咱們每每選擇最小的鍵組合做爲主鍵，因此主鍵每每適合做爲表的彙集索引。彙集索引對查詢的影響是比較大的，這個在下面索引的敘述。

在有多個鍵的表，主鍵的選擇也比較重要，通常選擇總的長度小的鍵，小的鍵的比較速度快，同時小的鍵可使主鍵的B樹結構的層次更少。

主鍵的選擇還要注意組合主鍵的字段次序，對於組合主鍵來講，不一樣的字段次序的主鍵的性能差異可能會很大，通常應該選擇重複率低、單獨或者組合查詢可能性大的字段放在前面。

四、外鍵的設計

外鍵做爲數據庫對象，不少人認爲麻煩而不用，實際上，外鍵在大部分狀況下是頗有用的，理由是：

外鍵是最高效的一致性維護方法，數據庫的一致性要求，依次能夠用外鍵、CHECK約束、規則約束、觸發器、客戶端程序，通常認爲，離數據越近的方法效率越高。

謹慎使用級聯刪除和級聯更新，級聯刪除和級聯更新做爲SQL SERVER 2000當年的新功能，在2005做了保留，應該有其可用之處。我這裏說的謹慎，是由於級聯刪除和級聯更新有些突破了傳統的關於外鍵的定義，功能有點太過強大，使用前必須肯定本身已經把握好其功能範圍，不然，級聯刪除和級聯更新可能讓你的數據莫名其妙的被修改或者丟失。從性能看級聯刪除和級聯更新是比其餘方法更高效的方法。

五、字段的設計

字段是數據庫最基本的單位，其設計對性能的影響是很大的。須要注意以下：

A、數據類型儘可能用數字型，數字型的比較比字符型的快不少。

B、數據類型儘可能小，這裏的儘可能小是指在知足能夠預見的將來需求的前提下的。

C、儘可能不要容許NULL，除非必要，能夠用NOT NULL+DEFAULT代替。

D、少用TEXT和IMAGE，二進制字段的讀寫是比較慢的，並且，讀取的方法也很少，大部分狀況下最好不用。

E、自增字段要慎用，不利於數據遷移。

六、數據庫物理存儲和環境的設計

在設計階段，能夠對數據庫的物理存儲、操做系統環境、網絡環境進行必要的設計，使得咱們的系統在未來能適應比較多的用戶併發和比較大的數據量。

這裏須要注意文件組的做用，適用文件組能夠有效把I/O操做分散到不一樣的物理硬盤，提升併發能力。

七、系統設計

整個系統的設計特別是系統結構設計對性能是有很大影響的，對於通常的OLTP系統，能夠選擇C/S結構、三層的C/S結構等，不一樣的系統結構其性能的關鍵也有所不一樣。

系統設計階段應該概括一些業務邏輯放在數據庫編程實現，數據庫編程包括數據庫存儲過程、觸發器和函數。用數據庫編程實現業務邏輯的好處是減小網絡流量並可更充分利用數據庫的預編譯和緩存功能。

八、索引的設計

在設計階段，能夠根據功能和性能的需求進行初步的索引設計，這裏須要根據預計的數據量和查詢來設計索引，可能與未來實際使用的時候會有所區別。

關於索引的選擇，應改主意：

A、根據數據量決定哪些表須要增長索引，數據量小的能夠只有主鍵。

B、根據使用頻率決定哪些字段須要創建索引，選擇常常做爲鏈接條件、篩選條件、聚合查詢、排序的字段做爲索引的候選字段。

C、把常常一塊兒出現的字段組合在一塊兒，組成組合索引，組合索引的字段順序與主鍵同樣，也須要把最經常使用的字段放在前面，把重複率低的字段放在前面。

D、一個表不要加太多索引，由於索引影響插入和更新的速度。

3、編碼階段

編碼階段是本文的重點，由於在設計肯定的狀況下，編碼的質量幾乎決定了整個系統的質量。

編碼階段首先是須要全部程序員有性能意識，也就是在實現功能同時有考慮性能的思想，數據庫是能進行集合運算的工具，咱們應該儘可能的利用這個工具，所謂集合運算實際是批量運算，就是儘可能減小在客戶端進行大數據量的循環操做，而用SQL語句或者存儲過程代替。關於思想和意識，很難說得很清楚，須要在編程過程當中來體會。

下面羅列一些編程階段須要注意的事項：

一、只返回須要的數據

返回數據到客戶端至少須要數據庫提取數據、網絡傳輸數據、客戶端接收數據以及客戶端處理數據等環節，若是返回不須要的數據，就會增長服務器、網絡和客戶端的無效勞動，其害處是顯而易見的，避免這類事件須要注意：

A、橫向來看，不要寫SELECT *的語句，而是選擇你須要的字段。

B、縱向來看，合理寫WHERE子句，不要寫沒有WHERE的SQL語句。

C、注意SELECT INTO後的WHERE子句，由於SELECT INTO把數據插入到臨時表，這個過程會鎖定一些系統表，若是這個WHERE子句返回的數據過多或者速度太慢，會形成系統表長期鎖定，諸塞其餘進程。

D、對於聚合查詢，能夠用HAVING子句進一步限定返回的行。

二、儘可能少作重複的工做

這一點和上一點的目的是同樣的，就是儘可能減小無效工做，可是這一點的側重點在客戶端程序，須要注意的以下：

A、控制同一語句的屢次執行，特別是一些基礎數據的屢次執行是不少程序員不多注意的。

B、減小屢次的數據轉換，也許須要數據轉換是設計的問題，可是減小次數是程序員能夠作到的。

C、杜毫不必要的子查詢和鏈接表，子查詢在執行計劃通常解釋成外鏈接，多餘的鏈接錶帶來額外的開銷。

D、合併對同一表同一條件的屢次UPDATE，好比

UPDATE EMPLOYEE SET FNAME=’HAIWER’ WHERE EMP_ID=’ VPA30890F’
UPDATE EMPLOYEE SET LNAME=’YANG’ WHERE EMP_ID=’ VPA30890F’

這兩個語句應該合併成如下一個語句

UPDATE EMPLOYEE SET FNAME=’HAIWER’,LNAME=’YANG’
WHERE EMP_ID=’ VPA30890F’

E、 UPDATE操做不要拆成DELETE操做+INSERT操做的形式，雖然功能相同，可是性能差異是很大的。

F、不要寫一些沒有意義的查詢，好比

SELECT * FROM EMPLOYEE WHERE 1=2

三、注意事務和鎖

事務是數據庫應用中和重要的工具，它有原子性、一致性、隔離性、持久性這四個屬性，不少操做咱們都須要利用事務來保證數據的正確性。在使用事務中咱們須要作到儘可能避免死鎖、儘可能減小阻塞。具體如下方面須要特別注意：

A、事務操做過程要儘可能小，能拆分的事務要拆分開來。

B、事務操做過程不該該有交互，由於交互等待的時候，事務並未結束，可能鎖定了不少資源。

C、事務操做過程要按同一順序訪問對象。

D、提升事務中每一個語句的效率，利用索引和其餘方法提升每一個語句的效率能夠有效地減小整個事務的執行時間。

E、儘可能不要指定鎖類型和索引，SQL SERVER容許咱們本身指定語句使用的鎖類型和索引，可是通常狀況下，SQL SERVER優化器選擇的鎖類型和索引是在當前數據量和查詢條件下是最優的，咱們指定的可能只是在目前狀況下更有，可是數據量和數據分佈在未來是會變化的。

F、查詢時能夠用較低的隔離級別，特別是報表查詢的時候，能夠選擇最低的隔離級別（未提交讀）。

四、注意臨時表和表變量的用法

在複雜系統中，臨時表和表變量很難避免，關於臨時表和表變量的用法，須要注意：

A、若是語句很複雜，鏈接太多，能夠考慮用臨時表和表變量分步完成。

B、若是須要屢次用到一個大表的同一部分數據，考慮用臨時表和表變量暫存這部分數據。

C、若是須要綜合多個表的數據，造成一個結果，能夠考慮用臨時表和表變量分步彙總這多個表的數據。

D、其餘狀況下，應該控制臨時表和表變量的使用。

E、關於臨時表和表變量的選擇，不少說法是表變量在內存，速度快，應該首選表變量，可是在實際使用中發現，這個選擇主要考慮須要放在臨時表的數據量，在數據量較多的狀況下，臨時表的速度反而更快。

F、關於臨時表產生使用SELECT INTO和CREATE TABLE + INSERT INTO的選擇，咱們作過測試，通常狀況下，SELECT INTO會比CREATE TABLE + INSERT INTO的方法快不少，可是SELECT INTO會鎖定TEMPDB的系統表SYSOBJECTS、SYSINDEXES、SYSCOLUMNS，在多用戶併發環境下，容易阻塞其餘進程，因此我的建議是，在併發系統中，儘可能使用CREATE TABLE + INSERT INTO，而大數據量的單個語句使用中，使用SELECT INTO。

G、注意排序規則，用CREATE TABLE創建的臨時表，若是不指定字段的排序規則，會選擇TEMPDB的默認排序規則，而不是當前數據庫的排序規則。若是當前數據庫的排序規則和 TEMPDB的排序規則不一樣，鏈接的時候就會出現排序規則的衝突錯誤。通常能夠在CREATE TABLE創建臨時表時指定字段的排序規則爲DATABASE_DEFAULT來避免上述問題。

五、子查詢的用法

子查詢是一個 SELECT 查詢，它嵌套在 SELECT、INSERT、UPDATE、DELETE 語句或其它子查詢中。任何容許使用表達式的地方均可以使用子查詢。

子查詢可使咱們的編程靈活多樣，能夠用來實現一些特殊的功能。可是在性能上，每每一個不合適的子查詢用法會造成一個性能瓶頸。

若是子查詢的條件中使用了其外層的表的字段，這種子查詢就叫做相關子查詢。相關子查詢能夠用IN、NOT IN、EXISTS、NOT EXISTS引入。

關於相關子查詢，應該注意：

A、NOT IN、NOT EXISTS的相關子查詢能夠改用LEFT JOIN代替寫法。好比：

SELECT PUB_NAME
FROM PUBLISHERS
WHERE PUB_ID NOT IN
(SELECT PUB_ID
FROM TITLES
WHERE TYPE = ’BUSINESS’)

能夠改寫成：

SELECT A.PUB_NAME
FROM PUBLISHERS A LEFT JOIN TITLES B
ON B.TYPE = ’BUSINESS’ AND
A.PUB_ID=B. PUB_ID
WHERE B.PUB_ID IS NULL

SELECT TITLE
FROM TITLES
WHERE NOT EXISTS
(SELECT TITLE_ID
FROM SALES
WHERE TITLE_ID = TITLES.TITLE_ID)

能夠改寫成：

SELECT TITLE
FROM TITLES LEFT JOIN SALES
ON SALES.TITLE_ID = TITLES.TITLE_ID
WHERE SALES.TITLE_ID IS NULL

B、若是保證子查詢沒有重複，IN、EXISTS的相關子查詢能夠用INNER JOIN 代替。好比：

SELECT PUB_NAME
FROM PUBLISHERS
WHERE PUB_ID IN
(SELECT PUB_ID
FROM TITLES
WHERE TYPE = ’BUSINESS’)

能夠改寫成：

SELECT DISTINCT A.PUB_NAME
FROM PUBLISHERS A INNER JOIN TITLES B
ON B.TYPE = ’BUSINESS’ AND
A.PUB_ID=B. PUB_ID

C、 IN的相關子查詢用EXISTS代替，好比

SELECT PUB_NAME
FROM PUBLISHERS
WHERE PUB_ID IN
(SELECT PUB_ID
FROM TITLES
WHERE TYPE = ’BUSINESS’)

能夠用下面語句代替：

SELECT PUB_NAME
FROM PUBLISHERS
WHERE EXISTS
(SELECT 1
FROM TITLES
WHERE TYPE = ’BUSINESS’ AND
PUB_ID= PUBLISHERS.PUB_ID)

D、不要用COUNT(*)的子查詢判斷是否存在記錄，最好用LEFT JOIN或者EXISTS，好比有人寫這樣的語句：

SELECT JOB_DESC FROM JOBS
WHERE (SELECT COUNT(*) FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)=0

應該改爲：

SELECT JOBS.JOB_DESC FROM JOBS LEFT JOIN EMPLOYEE
ON EMPLOYEE.JOB_ID=JOBS.JOB_ID
WHERE EMPLOYEE.EMP_ID IS NULL

SELECT JOB_DESC FROM JOBS
WHERE (SELECT COUNT(*) FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)<>0

應該改爲：

SELECT JOB_DESC FROM JOBS
WHERE EXISTS (SELECT 1 FROM EMPLOYEE WHERE JOB_ID=JOBS.JOB_ID)

六、慎用遊標

數據庫通常的操做是集合操做，也就是對由WHERE子句和選擇列肯定的結果集做集合操做，遊標是提供的一個非集合操做的途徑。通常狀況下，遊標實現的功能每每至關於客戶端的一個循環實現的功能，因此，大部分狀況下，咱們把遊標功能搬到客戶端。

遊標是把結果集放在服務器內存，並經過循環一條一條處理記錄，對數據庫資源（特別是內存和鎖資源）的消耗是很是大的，因此，咱們應該只有在沒有其餘方法的狀況下才使用遊標。

另外，咱們能夠用SQL SERVER的一些特性來代替遊標，達到提升速度的目的。

A、字符串鏈接的例子

這是論壇常常有的例子，就是把一個表符合條件的記錄的某個字符串字段鏈接成一個變量。好比須要把JOB_ID=10的EMPLOYEE的FNAME鏈接在一塊兒，用逗號鏈接，可能最容易想到的是用遊標：

DECLARE @NAME VARCHAR(20)
DECLARE @NAME VARCHAR(1000)
DECLARE NAME_CURSOR CURSOR FOR
SELECT FNAME FROM EMPLOYEE WHERE JOB_ID=10 ORDER BY EMP_ID
OPEN NAME_CURSOR
FETCH NEXT FROM RNAME_CURSOR INTO @NAME
WHILE @@FETCH_STATUS = 0
BEGIN
SET @NAMES = ISNULL(@NAMES+’,’,’’)+@NAME
FETCH NEXT FROM NAME_CURSOR INTO @NAME
END
CLOSE NAME_CURSOR
DEALLOCATE NAME_CURSOR

能夠以下修改，功能相同：

DECLARE @NAME VARCHAR(1000)
SELECT @NAMES = ISNULL(@NAMES+’,’,’’)+FNAME
FROM EMPLOYEE WHERE JOB_ID=10 ORDER BY EMP_ID

B、用CASE WHEN 實現轉換的例子

不少使用遊標的緣由是由於有些處理須要根據記錄的各類狀況須要做不一樣的處理，實際上這種狀況，咱們能夠用CASE WHEN語句進行必要的判斷處理，並且CASE WHEN是能夠嵌套的。好比:

表結構:

CREATE TABLE 料件表(
料號 VARCHAR(30),
名稱 VARCHAR(100),
主單位 VARCHAR(20),
單位1 VARCHAR(20),
單位1參數 NUMERIC(18,4),
單位2 VARCHAR(20),
單位2參數 NUMERIC(18,4)
)
GO
CREATE TABLE 入庫表(
時間 DATETIME,
料號 VARCHAR(30),
單位 INT,
入庫數量 NUMERIC(18,4),
損壞數量 NUMERIC(18,4)
)
GO

其中，單位字段能夠是0，1，2，分別表明主單位、單位一、單位2，不少計算須要統一單位，統一單位能夠用遊標實現：

DECLARE @料號 VARCHAR(30),
@單位 INT,
@參數 NUMERIC(18,4),
DECLARE CUR CURSOR FOR
SELECT 料號,單位 FROM 入庫表 WHERE 單位 <>0
OPEN CUR
FETCH NEXT FROM CUR INTO @料號,@單位
WHILE @@FETCH_STATUS<>-1
BEGIN
IF @單位=1
BEGIN
SET @參數=(SELECT 單位1參數 FROM 料件表 WHERE 料號 =@料號)
UPDATE 入庫表 SET 數量=數量*@參數,損壞數量=損壞數量*@參數,單位=1 WHERE CURRENT OF CUR
END
IF @單位=2
BEGIN
SET @參數=(SELECT 單位1參數 FROM 料件表 WHERE 料號 =@料號)
UPDATE 入庫表 SET 數量=數量*@參數,損壞數量=損壞數量*@參數,單位=1 WHERE CURRENT OF CUR
END
FETCH NEXT FROM CUR INTO @料號,@單位
END
CLOSE CUR
DEALLOCATE CUR

能夠改寫成：

UPDATE A SET
數量=CASE A.單位 WHEN 1 THEN A.數量*B. 單位1參數
WHEN 2 THEN A.數量*B. 單位2參數
ELSE A.數量
END,
損壞數量= CASE A.單位 WHEN 1 THEN A. 損壞數量*B. 單位1參數
WHEN 2 THEN A. 損壞數量*B. 單位2參數
ELSE A. 損壞數量
END,
單位=1
FROM入庫表 A, 料件表 B
WHERE A.單位<>1 AND
A.料號=B.料號

C、變量參與的UPDATE語句的例子

SQL ERVER的語句比較靈活，變量參與的UPDATE語句能夠實現一些遊標同樣的功能，好比：

在

SELECT A,B,C,CAST(NULL AS INT) AS 序號
INTO #T
FROM 表
ORDER BY A ,NEWID()

產生臨時表後，已經按照A字段排序，可是在A相同的狀況下是亂序的，這時若是須要更改序號字段爲按照A字段分組的記錄序號，就只有遊標和變量參與的UPDATE語句能夠實現了，這個變量參與的UPDATE語句以下：

DECLARE @A INT
DECLARE @序號 INT
UPDATE #T SET
@序號=CASE WHEN A=@A THEN @序號+1 ELSE 1 END,
@A=A,
序號=@序號

D、若是必須使用遊標，注意選擇遊標的類型，若是隻是循環取數據，那就應該用只進遊標（選項FAST_FORWARD），通常只須要靜態遊標（選項STATIC）。

E、注意動態遊標的不肯定性，動態遊標查詢的記錄集數據若是被修改，會自動刷新遊標，這樣使得動態遊標有了不肯定性，由於在多用戶環境下，若是其餘進程或者自己更改了紀錄，就可能刷新遊標的記錄集。

七、儘可能使用索引

創建索引後，並非每一個查詢都會使用索引，在使用索引的狀況下，索引的使用效率也會有很大的差異。只要咱們在查詢語句中沒有強制指定索引，索引的選擇和使用方法是SQLSERVER的優化器自動做的選擇，而它選擇的根據是查詢語句的條件以及相關表的統計信息，這就要求咱們在寫SQL語句的時候儘可能使得優化器可使用索引。

爲了使得優化器能高效使用索引，寫語句的時候應該注意：

A、不要對索引字段進行運算，而要想辦法作變換，好比

SELECT ID FROM T WHERE NUM/2=100

應改成:

SELECT ID FROM T WHERE NUM=100*2

SELECT ID FROM T WHERE NUM/2=NUM1

若是NUM有索引應改成:

SELECT ID FROM T WHERE NUM=NUM1*2

若是NUM1有索引則不該該改。

發現過這樣的語句：

SELECT 年,月,金額 FROM 結餘表
WHERE 100*年+月=2007*100+10

應該改成：

SELECT 年,月,金額 FROM 結餘表
WHERE 年=2007 AND
月=10

B、不要對索引字段進行格式轉換

日期字段的例子：

WHERE CONVERT(VARCHAR(10), 日期字段,120)=’2008-08-15’

應該改成

WHERE日期字段〉=’2008-08-15’ AND 日期字段<’2008-08-16’

ISNULL轉換的例子：

WHERE ISNULL(字段,’’)<>’’應改成:WHERE字段<>’’

WHERE ISNULL(字段,’’)=’’不該修改

WHERE ISNULL(字段,’F’) =’T’應改成: WHERE字段=’T’

WHERE ISNULL(字段,’F’)<>’T’不該修改

C、不要對索引字段使用函數

WHERE LEFT(NAME, 3)=’ABC’ 或者WHERE SUBSTRING(NAME,1, 3)=’ABC’

應改成:

WHERE NAME LIKE ‘ABC%’

日期查詢的例子：

WHERE DATEDIFF(DAY, 日期,’2005-11-30′)=0應改成:WHERE 日期 >=’2005-11-30′ AND 日期 <’2005-12-1‘

WHERE DATEDIFF(DAY, 日期,’2005-11-30′)>0應改成:WHERE 日期 <’2005-11-30‘

WHERE DATEDIFF(DAY, 日期,’2005-11-30′)>=0應改成:WHERE 日期 <’2005-12-01‘

WHERE DATEDIFF(DAY, 日期,’2005-11-30′)<0應改成:WHERE 日期>=’2005-12-01‘

WHERE DATEDIFF(DAY, 日期,’2005-11-30′)<=0應改成:WHERE 日期>=’2005-11-30‘

D、不要對索引字段進行多字段鏈接

好比：

WHERE FAME+ ’.’+LNAME=‘HAIWEI.YANG’

應改成:

WHERE FNAME=‘HAIWEI’ AND LNAME=‘YANG’

八、注意鏈接條件的寫法

多表鏈接的鏈接條件對索引的選擇有着重要的意義，因此咱們在寫鏈接條件條件的時候須要特別的注意。

A、多表鏈接的時候，鏈接條件必須寫全，寧肯重複，不要缺漏。

B、鏈接條件儘可能使用匯集索引

C、注意ON部分條件和WHERE部分條件的區別

九、其餘須要注意的地方

經驗代表，問題發現的越早解決的成本越低，不少性能問題能夠在編碼階段就發現，爲了提前發現性能問題，須要注意：

A、程序員注意、關心各表的數據量。

B、編碼過程和單元測試過程儘可能用數據量較大的數據庫測試，最好能用實際數據測試。

C、每一個SQL語句儘可能簡單

D、不要頻繁更新有觸發器的表的數據

E、注意數據庫函數的限制以及其性能

十、學會分辯SQL語句的優劣

本身分辨SQL語句的優劣很是重要，只有本身能分辨優劣才能寫出高效的語句。

A、查看SQL語句的執行計劃，能夠在查詢分析其使用CTRL+L圖形化的顯示執行計劃，通常應該注意百分比最大的幾個圖形的屬性，把鼠標移動到其上面會顯示這個圖形的屬性，須要注意預計成本的數據，也要注意其標題，通常都是CLUSTERED INDEX SEEK 、INDEX SEEK 、CLUSTERED INDEX SCAN 、INDEX SCAN 、TABLE SCAN等，其中出現SCAN說明語句有優化的餘地。也能夠用語句

SET SHOWPLAN_ALL ON

要執行的語句

SET SHOWPLAN_ALL OFF

查看執行計劃的文本詳細信息。

B、用事件探查器跟蹤系統的運行，可疑跟蹤到執行的語句，以及所用的時間，CPU用量以及I/O數據，從而分析語句的效率。

C、能夠用WINDOWS的系統性能檢測器，關注CPU、I/O參數

4、測試、試運行、維護階段

測試的主要任務是發現並修改系統的問題，其中性能問題也是一個重要的方面。重點應該放在發現有性能問題的地方，並進行必要的優化。主要進行語句優化、索引優化等。

試運行和維護階段是在實際的環境下運行系統，發現的問題範圍更廣，可能涉及操做系統、網絡以及多用戶併發環境出現的問題，其優化也擴展到操做系統、網絡以及數據庫物理存儲的優化。

這個階段的優花方法在這裏再也不展開，只說明下索引維護的方法：

A、能夠用DBCC DBREINDEX語句或者SQL SERVER維護計劃設定定時進行索引重建，索引重建的目的是提升索引的效能。

B、能夠用語句UPDATE STATISTICS或者SQL SERVER維護計劃設定定時進行索引統計信息的更新，其目的是使得統計信息更能反映實際狀況，從而使得優化器選擇更合適的索引。

C、能夠用DBCC CHECKDB或者DBCC CHECKTABLE語句檢查數據庫表和索引是否有問題，這兩個語句也能修復通常的問題。

D、

5、網上資料中一些說法的我的不一樣意見

一、「應儘可能避免在 WHERE 子句中對字段進行 NULL 值判斷，不然將致使引擎放棄使用索引而進行全表掃描，如：

SELECT ID FROM T WHERE NUM IS NULL

能夠在NUM上設置默認值0，確保表中NUM列沒有NULL值，而後這樣查詢：

SELECT ID FROM T WHERE NUM=0」

我的意見：通過測試，IS NULL也是能夠用INDEX SEEK查找的，0和NULL是不一樣概念的，以上說法的兩個查詢的意義和記錄數是不一樣的。

二、「應儘可能避免在 WHERE 子句中使用!=或<>操做符，不然將引擎放棄使用索引而進行全表掃描。」

我的意見：通過測試，<>也是能夠用INDEX SEEK查找的。

三、「應儘可能避免在 WHERE 子句中使用 OR 來鏈接條件，不然將致使引擎放棄使用索引而進行全表掃描，如：

SELECT ID FROM T WHERE NUM=10 OR NUM=20

能夠這樣查詢：

SELECT ID FROM T WHERE NUM=10

UNION ALL

SELECT ID FROM T WHERE NUM=20」

我的意見：主要對全表掃描的說法不贊同。

四、「IN 和 NOT IN 也要慎用，不然會致使全表掃描，如：

SELECT ID FROM T WHERE NUM IN(1,2,3)

對於連續的數值，能用 BETWEEN 就不要用 IN 了：

SELECT ID FROM T WHERE NUM BETWEEN 1 AND 3」

我的意見：主要對全表掃描的說法不贊同。

五、「若是在 WHERE 子句中使用參數，也會致使全表掃描。由於SQL只有在運行時纔會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，若是在編譯時創建訪問計劃，變量的值仍是未知的，於是沒法做爲索引選擇的輸入項。以下面語句將進行全表掃描：

SELECT ID FROM T WHERE NUM=@NUM

能夠改成強制查詢使用索引：

SELECT ID FROM T WITH(INDEX(索引名)) WHERE NUM=@NUM」

我的意見：關於局部變量的解釋比較奇怪，使用參數若是會影響性能，那存儲過程就該校除了，我堅持我上面對於強制索引的見解。

六、「儘量的使用 VARCHAR/NVARCHAR 代替 CHAR/NCHAR ，由於首先變長字段存儲空間小，能夠節省存儲空間，其次對於查詢來講，在一個相對較小的字段內搜索效率顯然要高些。」

我的意見：「在一個相對較小的字段內搜索效率顯然要高些」顯然是對的，可是字段的長短彷佛不是由變不變長決定，而是業務自己決定。在 SQLSERVER6.5或者以前版本，不定長字符串字段的比較速度比定長的字符串字段的比較速度慢不少，因此對於那些版本，咱們都是推薦使用定長字段存儲一些關鍵字段。而在2000版本，修改了不定長字符串字段的比較方法，與定長字段的比較速度差異不大了，這樣爲了方便，咱們大量使用不定長字段。

七、關於鏈接表的順序或者條件的順序的說法，通過測試，在SQL SERVER，這些順序都是不影響性能的，這些說法多是對ORACLE有效。

二2、oracle中 rownum與rowid的理解，一千條記錄我查200到300的記錄怎麼查？

答：詳見：http://www.sunxin.org/article/242.html

如何查200到300行的記錄，能夠經過top關鍵字輔助：select top 100 * from table where id is not in (select top 200 id from table);

查詢n到m行記錄的通用公式：select top m * from table where id is not in (select top n * from table)

二3、如何分析ORACLE的執行計劃？

答：詳見：http://blog.chinaunix.net/space.php?uid=22539324&do=blog&id=2644068

二4、 DB中索引原理，種類，使用索引的好處和問題是什麼？

答：常常須要修改的表不易對改變創建索引，由於數據庫對索引進行維護須要額外的開銷。對常常須要查詢的大數據表須要創建索引，這樣會增長