測試：? http://blog.csdn.net/chenmengyi828/article/details/52136921

一、String,StringBuffer, StringBuilder的區別是什么？String為什么是不可變的？

答：1、String是字符串常量，StringBuffer和StringBuilder都是字符串變量。后兩者的字符內容可變，而前者創建后內容不可變。

2、String不可變是因為在JDK中String類被聲明為一個final類。

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

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

二、Vector,ArrayList, LinkedList的區別是什么？

答：

1、Vector、ArrayList都是以類似數組的形式存儲在內存中，LinkedList則以鏈表的形式進行存儲。

2、List中的元素有序、允許有重復的元素，Set中的元素無序、不允許有重復元素。

3、Vector線程同步，ArrayList、LinkedList線程不同步。

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

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

三、HashTable, HashMap，TreeMap區別？

答：

1、HashTable線程同步，HashMap非線程同步。

2、HashTable不允許<鍵,值>有空值，HashMap允許<鍵,值>有空值。

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

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

5、TreeMap能夠把它保存的記錄根據鍵排序，默認是按升序排序。

五、Tomcat，Apache，JBoss的區別？

答：

1、Apache是Http服務器，Tomcat是web服務器，JBoss是應用服務器。

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

六、GET，POST區別？

答：

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

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

用來說明服務器要使用的附加信息

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

[]請求的內容數據

區別：

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

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

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

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

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

七、Session, Cookie區別

答：

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

2、用戶可以通過瀏覽器設置決定是否保存Cookie，而不能決定是否保存Session，因為Session是由服務器端維護的。

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

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

5、Session、Cookie都有失效時間，過期后會自動刪除，減少系統開銷。

八、Servlet的生命周期

答：

大致分為4部：Servlet類加載-->實例化-->服務-->銷毀

下圖是Tomcat中Servlet時序圖。

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

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

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

4、Servlet創建一個HttpResponse對象。

5、Servlet調用HttpServlet對象的service方法，把HttpRequest對象和HttpResponse對象作為參數傳遞給HttpServlet對象中。

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

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

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

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

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

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

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

九、HTTP報文包含內容

答：

主要包含四部分：

1、request line

2、header line

3、blank line

4、request body

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

答：

1、PreparedStatement支持動態設置參數，Statement不支持。

2、PreparedStatement可避免如類似單引號的編碼麻煩，Statement不可以。

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

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

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

什么是SQL注入：通過sql語句的拼接達到無參數查詢數據庫數據目的的方法。

如將要執行的sql語句為select * from table where name =

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

因此可以采用PrepareStatement來避免Sql注入，在服務器端接收參數數據后，進行驗證，此時PrepareStatement會自動檢測，而Statement不行，需要手工檢測。

十一、sendRedirect, foward區別

答：

1、foward是服務器端控制頁面轉向，在客戶端的瀏覽器地址中不會顯示轉向后的地址；sendRedirect則是完全的跳轉，瀏覽器中會顯示跳轉的地址并重新發送請求鏈接。

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

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

十二、關于JAVA內存模型，一個對象（兩個屬性，四個方法）實例化100次，現在內存中的存儲狀態，幾個對象，幾個屬性，幾個方法。

答：

由于JAVA中new出來的對象都是放在堆中，所以如果要實例化100次，將在堆中產生100個對象，一般對象與其中的屬性、方法都屬于一個整體，但如果屬性和方法是靜態的，就是用static關鍵字聲明的，那么屬于類的屬性和方法永遠只在內存中存在一份。

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

答：

Hibernate是一個開發的對象關系映射框架（ORM）。它對JDBC進行了非常對象封裝，Hibernate允許程序員采用面向對象的方式來操作關系數據庫。

Hibernate的優點：

1、程序更加面向對象

2、提高了生產率

3、方便移植

4、無入侵性。

缺點：

1、效率比JDBC略差

2、不適合批量操作

3、只能配置一種關聯關系

Hibernate有四種查詢方式：

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

2、Hibernate query language

3、標準查詢語言

4、通過sql查詢

Hibernage工作原理：

1、配置hibernate對象關系映射文件、啟動服務器

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

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

4、通過Seesion對象完成數據庫的增刪改查操作。

Hibernate中的狀態轉移

臨時狀態（transient）

1、不處于session緩存中

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

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

持久化狀態(persisted)

1、處于session緩存中

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

3、seesion在特定的時刻會保存兩者同步

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

流離狀態（detached）

1、不再位于session緩存中

2、游離對象由持久化狀態轉變而來，數據庫中還沒有相應記錄。

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

具體如下圖所示：

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

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

答：

反射機制的定義：

是在運行狀態中，對于任意的一個類，都能夠知道這個類的所有屬性和方法，對任意一個對象都能夠通過反射機制調用一個類的任意方法，這種動態獲取類信息及動態調用類對象方法的功能稱為java的反射機制。

反射的作用：

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

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

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

答：

1、Hibernate偏向于對象的操作達到數據庫相關操作的目的；而ibatis更偏向于sql語句的優化。

2、Hibernate的使用的查詢語句是自己的hql，而ibatis則是標準的sql語句。

3、Hibernate相對復雜，不易學習；ibatis類似sql語句，簡單易學。

性能方面：

1、如果系統數據處理量巨大，性能要求極為苛刻時，往往需要人工編寫高性能的sql語句或存錯過程，此時ibatis具有更好的可控性，因此性能優于Hibernate。

2、同樣的需求下，由于hibernate可以自動生成hql語句，而ibatis需要手動寫sql語句，此時采用Hibernate的效率高于ibatis。

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

答：

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

Spring的優點：

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

2、可以使用容易提供的眾多服務，如事務管理，消息服務，日志記錄等。

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

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

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

十七、線程同步，并發操作怎么控制

答：

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

資源時，如果該資源沒有被占用，那么將資源交付給這個申請者使用，在此期間，其他申請者只能申請而不能使用該資源，當該資源被使用完成后將釋放該資源上的鎖，其他申請者可申請使用。

并發控制主要是為了多線程操作時帶來的資源讀寫問題。如果不加以空間可能會出現死鎖，讀臟數據、不可重復讀、丟失更新等異常。

并發操作可以通過加鎖的方式進行控制，鎖又可分為樂觀鎖和悲觀鎖。

悲觀鎖：

悲觀鎖并發模式假定系統中存在足夠多的數據修改操作，以致于任何確定的讀操作都可能會受到由個別的用戶所制造的數據修改的影響。也就是說悲觀鎖假定沖突總會發生，通過獨占正在被讀取的數據來避免沖突。但是獨占數據會導致其他進程無法修改該數據，進而產生阻塞，讀數據和寫數據會相互阻塞。

樂觀鎖：

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

十八、描述struts的工作流程

答：

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

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

3、如果ActionForm實例不存在，就創建一個ActionForm對象，把客戶提交的表單數據保存到ActionForm對象中。

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

5、ActionServlet根據ActionMapping實例包含的映射信息決定請求轉發給哪個Action，如果相應的Action實例不存在，就先創建一個實例，然后調用Action的execute()方法。

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

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

十九、Tomcat的session處理，如果讓你實現一個tomcatserver，如何實現session機制

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

二十、關于Cache(Ehcache,Memcached)

答：

最近研究了一下緩存技術，主要比較了一下memcached和ehcache。

ehcache是純java編寫的，通信是通過RMI方式，適用于基于java技術的項目。

memcached服務器端是c編寫的，客戶端有多個語言的實現，如c，php（淘寶，sina等各大門戶網站），python（豆瓣網），java（Xmemcached，spymemcached)。memcached服務器端是使用文本或者二進制通信的。memcached的python客戶端沒有開源，其他語言的好像都開源了。另外我以前不明白為什么各大互聯網公司都是使用memcached緩存，后來我明白了原因：因為各大門戶網站以及淘寶是使用php編寫的網站，memcached有php客戶端，而ehcache是純java。

二一、sql的優化相關問題

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

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

我始終認為，一個系統的性能的提高，不單單是試運行或者維護階段的性能調優的任務，也不單單是開發階段的事情，而是在整個軟件生命周期都需要注意，進行有效工作才能達到的。所以我希望按照軟件生命周期的不同階段來總結數據庫性能優化相關的注意事項。

一、分析階段

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

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

二、設計階段

設計階段可以說是以后系統性能的關鍵階段，在這個階段，有一個關系到以后幾乎所有性能調優的過程—數據庫設計。

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

以下是性能要求設計階段需要注意的：

1、數據庫邏輯設計的規范化

數據庫邏輯設計的規范化就是我們一般所說的范式，我們可以這樣來簡單理解范式：

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

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

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

更高的范式要求這里就不再作介紹了，個人認為，如果全部達到第二范式，大部分達到第三范式，系統會產生較少的列和較多的表，因而減少了數據冗余，也利于性能的提高。

2、合理的冗余

完全按照規范化設計的系統幾乎是不可能的，除非系統特別的小，在規范化設計后，有計劃地加入冗余是必要的。

冗余可以是冗余數據庫、冗余表或者冗余字段，不同粒度的冗余可以起到不同的作用。

冗余可以是為了編程方便而增加，也可以是為了性能的提高而增加。從性能角度來說，冗余數據庫可以分散數據庫壓力，冗余表可以分散數據量大的表的并發壓力，也可以加快特殊查詢的速度，冗余字段可以有效減少數據庫表的連接，提高效率。

3、主鍵的設計

主鍵是必要的，SQL SERVER的主鍵同時是一個唯一索引，而且在實際應用中，我們往往選擇最小的鍵組合作為主鍵，所以主鍵往往適合作為表的聚集索引。聚集索引對查詢的影響是比較大的，這個在下面索引的敘述。

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

主鍵的選擇還要注意組合主鍵的字段次序，對于組合主鍵來說，不同的字段次序的主鍵的性能差別可能會很大，一般應該選擇重復率低、單獨或者組合查詢可能性大的字段放在前面。

4、外鍵的設計

外鍵作為數據庫對象，很多人認為麻煩而不用，實際上，外鍵在大部分情況下是很有用的，理由是：

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

謹慎使用級聯刪除和級聯更新，級聯刪除和級聯更新作為SQL SERVER 2000當年的新功能，在2005作了保留，應該有其可用之處。我這里說的謹慎，是因為級聯刪除和級聯更新有些突破了傳統的關于外鍵的定義，功能有點太過強大，使用前必須確定自己已經把握好其功能范圍，否則，級聯刪除和級聯更新可能讓你的數據莫名其妙的被修改或者丟失。從性能看級聯刪除和級聯更新是比其他方法更高效的方法。

5、字段的設計

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

A、數據類型盡量用數字型，數字型的比較比字符型的快很多。

B、數據類型盡量小，這里的盡量小是指在滿足可以預見的未來需求的前提下的。

C、盡量不要允許NULL，除非必要，可以用NOT NULL+DEFAULT代替。

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

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

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

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

這里需要注意文件組的作用，適用文件組可以有效把I/O操作分散到不同的物理硬盤，提高并發能力。

7、系統設計

整個系統的設計特別是系統結構設計對性能是有很大影響的，對于一般的OLTP系統，可以選擇C/S結構、三層的C/S結構等，不同的系統結構其性能的關鍵也有所不同。

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

8、索引的設計

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

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

·根據數據量決定哪些表需要增加索引，數據量小的可以只有主鍵。

·根據使用頻率決定哪些字段需要建立索引，選擇經常作為連接條件、篩選條件、聚合查詢、排序的字段作為索引的候選字段。

·把經常一起出現的字段組合在一起，組成組合索引，組合索引的字段順序與主鍵一樣，也需要把最常用的字段放在前面，把重復率低的字段放在前面。

·一個表不要加太多索引，因為索引影響插入和更新的速度。

三、編碼階段

編碼階段是本文的重點，因為在設計確定的情況下，編碼的質量幾乎決定了整個系統的質量。

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

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

1、只返回需要的數據

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

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

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

C、注意SELECT INTO后的WHERE子句，因為SELECT INTO把數據插入到臨時表，這個過程會鎖定一些系統表，如果這個WHERE子句返回的數據過多或者速度太慢，會造成系統表長期鎖定，諸塞其他進程。

D、對于聚合查詢，可以用HAVING子句進一步限定返回的行。

2、盡量少做重復的工作

這一點和上一點的目的是一樣的，就是盡量減少無效工作，但是這一點的側重點在客戶端程序，需要注意的如下：

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

B、減少多次的數據轉換，也許需要數據轉換是設計的問題，但是減少次數是程序員可以做到的。

C、杜絕不必要的子查詢和連接表，子查詢在執行計劃一般解釋成外連接，多余的連接表帶來額外的開銷。

D、合并對同一表同一條件的多次UPDATE，比如

1.? ? UPDATE EMPLOYEE SET FNAME=’HAIWER’ WHERE EMP_ID=’ VPA30890F’

2.? ? UPDATE EMPLOYEE SET LNAME=’YANG’ WHERE EMP_ID=’ VPA30890F’

這兩個語句應該合并成以下一個語句

1.? ? UPDATE EMPLOYEE SET FNAME=’HAIWER’,LNAME=’YANG’

2.? ? WHERE EMP_ID=’ VPA30890F’

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

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

SELECT * FROM EMPLOYEE WHERE 1=2

3、注意事務和鎖

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

A、事務操作過程要盡量小，能拆分的事務要拆分開來。

B、事務操作過程不應該有交互，因為交互等待的時候，事務并未結束，可能鎖定了很多資源。

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

D、提高事務中每個語句的效率，利用索引和其他方法提高每個語句的效率可以有效地減少整個事務的執行時間。

E、盡量不要指定鎖類型和索引，SQL SERVER允許我們自己指定語句使用的鎖類型和索引，但是一般情況下，SQL SERVER優化器選擇的鎖類型和索引是在當前數據量和查詢條件下是最優的，我們指定的可能只是在目前情況下更有，但是數據量和數據分布在將來是會變化的。

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

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

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

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來避免上述問題。

5、子查詢的用法

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

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

如果子查詢的條件中使用了其外層的表的字段，這種子查詢就叫作相關子查詢。相關子查詢可以用IN、NOT IN、EXISTS、NOT EXISTS引入。

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

A、NOT IN、NOT EXISTS的相關子查詢可以改用LEFT JOIN代替寫法。比如：

1.? ? SELECT PUB_NAME

2.? ? FROM PUBLISHERS

3.? ? WHERE PUB_ID NOT IN

4.? ? (SELECT PUB_ID

5.? ? FROM TITLES

6.? ? WHERE TYPE = ’BUSINESS’)

可以改寫成：

1.? ? SELECT A.PUB_NAME

2.? ? FROM PUBLISHERS A LEFT JOIN TITLES B

3.? ? ON? ? ? ? B.TYPE = ’BUSINESS’ AND

4.? ? A.PUB_ID=B. PUB_ID

5.? ? WHERE B.PUB_ID IS NULL

1.? ? SELECT TITLE

2.? ? FROM TITLES

3.? ? WHERE NOT EXISTS

4.? ? (SELECT TITLE_ID

5.? ? FROM SALES

6.? ? WHERE TITLE_ID = TITLES.TITLE_ID)

可以改寫成：

1.? ? SELECT TITLE

2.? ? FROM TITLES LEFT JOIN SALES

3.? ? ON SALES.TITLE_ID = TITLES.TITLE_ID

4.? ? WHERE SALES.TITLE_ID IS NULL

B、如果保證子查詢沒有重復，IN、EXISTS的相關子查詢可以用INNER JOIN代替。比如：

1.? ? SELECT PUB_NAME

2.? ? FROM PUBLISHERS

3.? ? WHERE PUB_ID IN

4.? ? (SELECT PUB_ID

5.? ? FROM TITLES

6.? ? WHERE TYPE = ’BUSINESS’)

可以改寫成：

1.? ? SELECT DISTINCT A.PUB_NAME

2.? ? FROM PUBLISHERS A INNER JOIN TITLES B

3.? ? ON? ? ? ? B.TYPE = ’BUSINESS’ AND

4.? ? A.PUB_ID=B. PUB_ID

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

1.? ? SELECT PUB_NAME

2.? ? FROM PUBLISHERS

3.? ? WHERE PUB_ID IN

4.? ? (SELECT PUB_ID

5.? ? FROM TITLES

6.? ? WHERE TYPE = ’BUSINESS’)

可以用下面語句代替：

1.? ? SELECT PUB_NAME

2.? ? FROM PUBLISHERS

3.? ? WHERE EXISTS

4.? ? (SELECT 1

5.? ? FROM TITLES

6.? ? WHERE TYPE = ’BUSINESS’ AND

7.? ? PUB_ID= PUBLISHERS.PUB_ID)

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

1.? ? SELECT JOB_DESC FROM JOBS

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

應該改成：

1.? ? SELECT JOBS.JOB_DESC FROM JOBS LEFT JOIN EMPLOYEE

2.? ? ON EMPLOYEE.JOB_ID=JOBS.JOB_ID

3.? ? WHERE EMPLOYEE.EMP_ID IS NULL

1.? ? SELECT JOB_DESC FROM JOBS

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

應該改成：

1.? ? SELECT JOB_DESC FROM JOBS

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

6、慎用游標

數據庫一般的操作是集合操作，也就是對由WHERE子句和選擇列確定的結果集作集合操作，游標是提供的一個非集合操作的途徑。一般情況下，游標實現的功能往往相當于客戶端的一個循環實現的功能，所以，大部分情況下，我們把游標功能搬到客戶端。

游標是把結果集放在服務器內存，并通過循環一條一條處理記錄，對數據庫資源（特別是內存和鎖資源）的消耗是非常大的，所以，我們應該只有在沒有其他方法的情況下才使用游標。

另外，我們可以用SQL SERVER的一些特性來代替游標，達到提高速度的目的。

A、字符串連接的例子

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

1.? ? DECLARE @NAME VARCHAR(20)

2.? ? DECLARE @NAME VARCHAR(1000)

3.? ? DECLARE NAME_CURSOR CURSOR FOR

4.? ? SELECT FNAME FROM EMPLOYEE WHERE JOB_ID=10 ORDER BY EMP_ID

5.? ? OPEN NAME_CURSOR

6.? ? FETCH NEXT FROM RNAME_CURSOR INTO @NAME

7.? ? WHILE @@FETCH_STATUS = 0

8.? ? BEGIN

9.? ? SET @NAMES = ISNULL(@NAMES+’,’,’’)+@NAME

10.? FETCH NEXT FROM NAME_CURSOR? INTO @NAME

11.? END

12.? CLOSE NAME_CURSOR

13.? DEALLOCATE NAME_CURSOR

可以如下修改，功能相同：

1.? ? DECLARE @NAME VARCHAR(1000)

2.? ? SELECT @NAMES = ISNULL(@NAMES+’,’,’’)+FNAME

3.? ? FROM EMPLOYEE WHERE JOB_ID=10 ORDER BY EMP_ID

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

很多使用游標的原因是因為有些處理需要根據記錄的各種情況需要作不同的處理，實際上這種情況，我們可以用CASE WHEN語句進行必要的判斷處理，而且CASE WHEN是可以嵌套的。比如:

表結構:

1.? ? CREATE TABLE料件表(

2.料號VARCHAR(30),

3.名稱VARCHAR(100),

4.主單位VARCHAR(20),

5.單位1? ? ? ? VARCHAR(20),

6.單位1參數NUMERIC(18,4),

7.單位2? ? ? ? VARCHAR(20),

8.單位2參數NUMERIC(18,4)

9.? ? )

10.? GO

11.? CREATE TABLE入庫表(

12.時間DATETIME,

13.料號VARCHAR(30),

14.單位INT,

15.入庫數量NUMERIC(18,4),

16.損壞數量NUMERIC(18,4)

17.? )

18.? GO

其中，單位字段可以是0，1，2，分別代表主單位、單位1、單位2，很多計算需要統一單位，統一單位可以用游標實現：

1.? ? DECLARE @料號VARCHAR(30),

2.? ? @單位INT,

3.? ? @參數NUMERIC(18,4),

4.? ? DECLARE CUR CURSOR FOR

5.? ? SELECT料號,單位FROM入庫表WHERE單位<>0

6.? ? OPEN CUR

7.? ? FETCH NEXT FROM CUR INTO @料號,@單位

8.? ? WHILE @@FETCH_STATUS<>-1

9.? ? BEGIN

10.? IF @單位=1

11.? BEGIN

12.? SET @參數=(SELECT單位1參數FROM料件表WHERE料號=@料號)

13.? UPDATE入庫表SET數量=數量*@參數,損壞數量=損壞數量*@參數,單位=1 WHERE CURRENT OF CUR

14.? END

15.? IF @單位=2

16.? BEGIN

17.? SET @參數=(SELECT單位1參數FROM料件表WHERE料號=@料號)

18.? UPDATE入庫表SET數量=數量*@參數,損壞數量=損壞數量*@參數,單位=1 WHERE CURRENT OF CUR

19.? END

20.? FETCH NEXT FROM CUR INTO @料號,@單位

21.? END

22.? CLOSE CUR

23.? DEALLOCATE CUR

可以改寫成：

1.? ? UPDATE A SET

2.數量=CASE A.單位WHEN 1 THEN? ? ? A.數量*B.單位1參數

3.? ? WHEN 2 THEN? ? ? ? A.數量*B.單位2參數

4.? ? ELSE A.數量

5.? ? END,

6.損壞數量= CASE A.單位WHEN 1 THEN? ? A.損壞數量*B.單位1參數

7.? ? WHEN 2 THEN? ? ? ? A.損壞數量*B.單位2參數

8.? ? ELSE A.損壞數量

9.? ? END,

10.單位=1

11.? FROM入庫表A,料件表B

12.? WHERE? ? A.單位<>1? ? ? AND

13.? A.料號=B.料號

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

SQL ERVER的語句比較靈活，變量參與的UPDATE語句可以實現一些游標一樣的功能，比如：

在SELECT A,B,C,CAST(NULL AS INT) AS序號

2.? ? INTO #T

3.? ? FROM表

4.? ? ORDER BY A ,NEWID()

產生臨時表后，已經按照A字段排序，但是在A相同的情況下是亂序的，這時如果需要更改序號字段為按照A字段分組的記錄序號，就只有游標和變量參與的UPDATE語句可以實現了，這個變量參與的UPDATE語句如下：

1.? ? DECLARE @A INT

2.? ? DECLARE @序號INT

3.? ? UPDATE #T SET

4.? ? @序號=CASE WHEN A=@A THEN @序號+1 ELSE 1 END,

5.? ? @A=A,

6.序號=@序號

D、如果必須使用游標，注意選擇游標的類型，如果只是循環取數據，那就應該用只進游標（選項FAST_FORWARD），一般只需要靜態游標（選項STATIC）。

E、注意動態游標的不確定性，動態游標查詢的記錄集數據如果被修改，會自動刷新游標，這樣使得動態游標有了不確定性，因為在多用戶環境下，如果其他進程或者本身更改了紀錄，就可能刷新游標的記錄集。

7、盡量使用索引

建立索引后，并不是每個查詢都會使用索引，在使用索引的情況下，索引的使用效率也會有很大的差別。只要我們在查詢語句中沒有強制指定索引，索引的選擇和使用方法是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有索引則不應該改。

發現過這樣的語句：

1.? ? SELECT年,月,金額FROM結余表

2.? ? WHERE 100*年+月=2007*100+10

應該改為：

1.? ? SELECT年,月,金額FROM結余表

2.? ? WHERE年=2007 AND

3.月=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’

8、注意連接條件的寫法

多表連接的連接條件對索引的選擇有著重要的意義，所以我們在寫連接條件條件的時候需要特別的注意。

A、多表連接的時候，連接條件必須寫全，寧可重復，不要缺漏。

B、連接條件盡量使用聚集索引

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

9、其他需要注意的地方

經驗表明，問題發現的越早解決的成本越低，很多性能問題可以在編碼階段就發現，為了提早發現性能問題，需要注意：

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

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

C、每個SQL語句盡量簡單

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

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

10、學會分辯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參數

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

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

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

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

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

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

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

五、網上資料中一些說法的個人不同意見

1、“應盡量避免在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是不同概念的，以上說法的兩個查詢的意義和記錄數是不同的。

2、“應盡量避免在WHERE子句中使用!=或<>操作符，否則將引擎放棄使用索引而進行全表掃描。”

個人意見：經過測試，<>也是可以用INDEX SEEK查找的。

3、“應盡量避免在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”

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

4、“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”

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

5、“如果在WHERE子句中使用參數，也會導致全表掃描。因為SQL只有在運行時才會解析局部變量，但優化程序不能將訪問計劃的選擇推遲到運行時；它必須在編譯時進行選擇。然而，如果在編譯時建立訪問計劃，變量的值還是未知的，因而無法作為索引選擇的輸入項。如下面語句將進行全表掃描：

SELECT ID FROM T WHERE NUM=@NUM

可以改為強制查詢使用索引：

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

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

6、“盡可能的使用VARCHAR/NVARCHAR代替CHAR/NCHAR，因為首先變長字段存儲空間小，可以節省存儲空間，其次對于查詢來說，在一個相對較小的字段內搜索效率顯然要高些。”

個人意見：“在一個相對較小的字段內搜索效率顯然要高些”顯然是對的，但是字段的長短似乎不是由變不變長決定，而是業務本身決定。在SQLSERVER6.5或者之前版本，不定長字符串字段的比較速度比定長的字符串字段的比較速度慢很多，所以對于那些版本，我們都是推薦使用定長字段存儲一些關鍵字段。而在2000版本，修改了不定長字符串字段的比較方法，與定長字段的比較速度差別不大了，這樣為了方便，我們大量使用不定長字段。

7、關于連接表的順序或者條件的順序的說法，經過測試，在SQL SERVER，這些順序都是不影響性能的，這些說法可能是對ORACLE有效。

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

答：詳見：鏈接

如何查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)

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

答：詳見：鏈接

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

答：經常需要修改的表不易對改變建立索引，因為數據庫對索引進行維護需要額外的開銷。對經常需要查詢的大數據表需要建立索引，這樣會增加

查詢的效率。

索引的原理：沒有找到合適的答案。

索引的種類：B*Tree、反向索引、降序索引、位圖索引、函數索引。詳見：https://wenku.baidu.com/view/d4d6ee1ba76e58fafab00336.html

二五、JVM垃圾回收實現原理。垃圾回收的線程優先級。

答：詳見：http://chenchendefeng.iteye.com/blog/455883

二六、jvm最大內存設置。設置的原理。結合垃圾回收講講。

答：詳見：http://www.open-open.com/lib/view/open1324736648468.html