阿里巴巴JAVA面試題
一、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的請求格式如下。
<request line> 主要包含三個資訊：1、請求的型別（GET或POST），2、要訪問的資源（如\res\img\a.jif），3、Http版本（http/1.1）
<header> 用來說明伺服器要使用的附加資訊
<blank line> 這是Http的規定，必須空一行
[<request-body>] 請求的內容資料
區別：
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+’,’,’’)[email protected]
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 料號 [email protected]料號)
13. UPDATE 入庫表 SET 數量=數量*@引數,損壞數量=損壞數量*@引數,單位=1 WHERE CURRENT OF CUR
14. END
15. IF @單位=2
16. BEGIN
17. SET @引數=(SELECT 單位1引數 FROM 料件表 WHERE 料號 [email protected]料號)
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 [email protected] THEN @序號+1 ELSE 1 END,
5. @A=A,
6. 序號[email protected]序號
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 [email protected]
可以改為強制查詢使用索引：
SELECT ID FROM T WITH(INDEX(索引名)) WHERE [email protected]”
個人意見：關於區域性變數的解釋比較奇怪，使用引數如果會影響效能，那儲存過程就該校除了，我堅持我上面對於強制索引的看法。
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、反向索引、降序索引、點陣圖索引、函式索引。詳見：連結
二五、JVM垃圾回收實現原理。垃圾回收的執行緒優先順序。
答： 詳見：連結
二六、jvm 最大記憶體設定。設定的原理。結合垃圾回收講講。
答： 詳見：連結