一、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更節省空間。
詳見:http://www.cnblogs.com/mgod/archive/2007/08/05/844011.html
三、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能夠把它保存的記錄根據鍵排序,默認是按升序排序。
詳見:http://www.zlmind.com/?p=679
五、Tomcat,Apache,JBoss的區別?
答: 1、Apache是Http服務器,Tomcat是web服務器,JBoss是應用服務器。
2、Apache解析靜態的html文件;Tomcat可解析jsp動態頁面、也可充當servlet容器。
詳見:http://foohsinglong.iteye.com/blog/1195780
六、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不會,比較安全。
詳見:http://www.cnblogs.com/wxf0701/archive/2008/08/17/1269798.html
七、Session, Cookie區別
答: 1、Session由應用服務器維護的一個服務器端的存儲空間;Cookie是客戶端的存儲空間,由瀏覽器維護。
2、用戶可以通過瀏覽器設置決定是否保存Cookie,而不能決定是否保存Session,因爲Session是由服務器端維護的。
3、Session中保存的是對象,Cookie中保存的是字符串。
4、Session和Cookie不能跨窗口使用,每打開一個瀏覽器系統會賦予一個SessionID,此時的SessionID不同,若要完成跨瀏覽器訪問數據,可以使用 Application。
5、Session、Cookie都有失效時間,過期後會自動刪除,減少系統開銷。
詳見:http://www.chinahtml.com/1007/128010707619425.html
八、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的生命週期:
九、HTTP 報文包含內容1、init():負責初始化Servlet對象。
2、service():負責響應客戶端請求。
3、destroy():當Servlet對象推出時,負責釋放佔用資源。
詳見:http://sunnylocus.iteye.com/blog/342996
答: 主要包含四部分:
十、Statement與PreparedStatement的區別,什麼是SQL注入,如何防止SQL注入1、request line
2、header line
3、blank line
4、request body
詳見:http://blog.csdn.net/heruiup/article/details/6072961
答: 1、PreparedStatement支持動態設置參數,Statement不支持。
2、PreparedStatement可避免如類似 單引號 的編碼麻煩,Statement不可以。
3、PreparedStatement支持預編譯,Statement不支持。
4、在sql語句出錯時PreparedStatement不易檢查,而Statement則更便於查錯。
5、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不 行,需要手工檢測。
十一、sendRedirect, foward區別
答: 1、foward是服務器端控制頁面轉向,在客戶端的瀏覽器地址中不會顯示轉向後的地址;sendRedirect則是完全的跳轉,瀏覽器中會顯示跳轉的地址並重 新發送請求鏈接。
原理:forward是服務器請求資源,服務器直接訪問目標地址的URL,把那個URL的響應內容讀取過來,然後再將這些內容返回給瀏覽器,瀏覽器根本不知 道服務器發送的這些內容是從哪來的,所以地址欄還是原來的地址。
redirect是服務器端根據邏輯,發送一個狀態碼,告訴瀏覽器重新去請求的那個地址,瀏覽器會用剛纔的所有參數重新發送新的請求。
詳見:http://dubaopeng.iteye.com/blog/1056564
十二、關於JAVA內存模型,一個對象(兩個屬性,四個方法)實例化100次,現在內存中的存儲狀態,幾個對象,幾個屬性,幾個方法。
答: 由於JAVA中new出來的對象都是放在堆中,所以如果要實例化100次,將在堆中產生100個對象,一般對象與其中的屬性、方法都屬於一個整體,但如果 屬性和方法是靜態的,就是用static關鍵字聲明的,那麼屬於類的屬性和方法永遠只在內存中存在一份。
詳見:http://wenwen.soso.com/z/q252323203.htm?sp=4000
十三、談談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緩存(二級緩存,一般由第三方提供)。
詳見:http://wxg6203.iteye.com/blog/766947 http://jyjiao2007.iteye.com/blog/760554
十四、反射講一講,主要是概念,都在哪需要反射機制,反射的性能,如何優化
答: 反射機制的定義:
是在運行狀態中,對於任意的一個類,都能夠知道這個類的所有屬性和方法,對任意一個對象都能夠通過反射機制調用一個類的任意方法,這種動態獲取類信息及動態調用類對象方法的功能稱爲java的反射機制。
反射的作用:
1、動態地創建類的實例,將類綁定到現有的對象中,或從現有的對象中獲取類型。
2、應用程序需要在運行時從某個特定的程序集中載入一個特定的類
十五、談談Hibernate與Ibatis的區別,哪個性能會更高一些
答: 1、Hibernate偏向於對象的操作達到數據庫相關操作的目的;而ibatis更偏向於sql語句的優化。
十六、對Spring的理解,項目中都用什麼?怎麼用的?對IOC、和AOP的理解及實現原理2、Hibernate的使用的查詢語句是自己的hql,而ibatis則是標準的sql語句。
3、Hibernate相對複雜,不易學習;ibatis類似sql語句,簡單易學。
性能方面:
1、如果系統數據處理量巨大,性能要求極爲苛刻時,往往需要人工編寫高性能的sql語句或存錯過程,此時ibatis具有更好的可控性,因此性能優於Hibernate。
2、同樣的需求下,由於hibernate可以自動生成hql語句,而ibatis需要手動寫sql語句,此時採用Hibernate的效率高於ibatis。
詳見:http://blog.csdn.net/cdh1213/article/details/5967405 http://wenku.baidu.com/view/06c4486aaf1ffc4ffe47acfb.html
答: Spring是一個開源框架,處於MVC模式中的控制層,它能應對需求快速的變化,其主要原因它有一種面向切面編程(AOP)的優勢,其次它提升了系統性能,因爲通過 依賴倒置機制(IOC),系統中用到的對象不是在系統加載時就全部實例化,而是在調用到這個類時纔會實例化該類的對象,從而提升了系統性能。這兩個優秀的性能 使得Spring受到許多J2EE公司的青睞,如阿里裏中使用最多的也是Spring相關技術。
Spring的優點:
1、降低了組件之間的耦合性,實現了軟件各層之間的解耦。
2、可以使用容易提供的衆多服務,如事務管理,消息服務,日誌記錄等。
3、容器提供了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
十七、線程同步,併發操作怎麼控制
答: Java中可在方法名前加關鍵字syschronized來處理當有多個線程同時訪問共享資源時候的問題。syschronized相當於一把鎖,當有申請者申請該
資源時,如果該資源沒有被佔用,那麼將資源交付給這個申請者使用,在此期間,其他申請者只能申請而不能使用該資源,當該資源被使用完成後將釋放該資源上的鎖,其他申請者可申請使用。
併發控制主要是爲了多線程操作時帶來的資源讀寫問題。如果不加以空間可能會出現死鎖,讀髒數據、不可重複讀、丟失更新等異常。
併發操作可以通過加鎖的方式進行控制,鎖又可分爲樂觀鎖和悲觀鎖。
悲觀鎖:
悲觀鎖併發模式假定系統中存在足夠多的數據修改操作,以致於任何確定的讀操作都可能會受到由個別的用戶所製造的數據修改的影響。也就是說悲觀鎖假定衝突總會發生,通過獨佔正在被讀取的數據來避免衝突。但是獨佔數據會導致其他進程無法修改該數據,進而產生阻塞,讀數據和寫數據會相互阻塞。
樂觀鎖:
樂觀鎖假定系統的數據修改只會產生非常少的衝突,也就是說任何進程都不大可能修改別的進程正在訪問的數據。樂觀併發模式下,讀數據和寫數據之間不會發生衝突,只有寫數據與寫數據之間會發生衝突。即讀數據不會產生阻塞,只有寫數據纔會產生阻塞。
詳見:http://www.cnblogs.com/ego/articles/1514350.html http://blog.csdn.net/niu870781892/article/details/6140755
十八、描述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)
答: 詳見:http://xuezhongfeicn.blog.163.com/blog/static/2246014120106144143737/
二一、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、 索引的設計
在設計階段,可以根據功能和性能的需求進行初步的索引設計,這裏需要根據預計的數據量和查詢來設計索引,可能與將來實際使用的時候會有所區別。
關於索引的選擇,應改主意:
A、 根據數據量決定哪些表需要增加索引,數據量小的可以只有主鍵。
B、 根據使用頻率決定哪些字段需要建立索引,選擇經常作爲連接條件、篩選條件、聚合查詢、排序的字段作爲索引的候選字段。
C、 把經常一起出現的字段組合在一起,組成組合索引,組合索引的字段順序與主鍵一樣,也需要把最常用的字段放在前面,把重複率低的字段放在前面。
D、 一個表不要加太多索引,因爲索引影響插入和更新的速度。
三、 編碼階段
編碼階段是本文的重點,因爲在設計確定的情況下,編碼的質量幾乎決定了整個系統的質量。
編碼階段首先是需要所有程序員有性能意識,也就是在實現功能同時有考慮性能的思想,數據庫是能進行集合運算的工具,我們應該儘量的利用這個工具,所謂集合運算實際是批量運算,就是儘量減少在客戶端進行大數據量的循環操作,而用SQL語句或者存儲過程代替。關於思想和意識,很難說得很清楚,需要在編程過程中來體會。
下面羅列一些編程階段需要注意的事項:
1、 只返回需要的數據
返回數據到客戶端至少需要數據庫提取數據、網絡傳輸數據、客戶端接收數據以及客戶端處理數據等環節,如果返回不需要的數據,就會增加服務器、網絡和客戶端的無效勞動,其害處是顯而易見的,避免這類事件需要注意:
A、橫向來看,不要寫SELECT *的語句,而是選擇你需要的字段。
B、 縱向來看,合理寫WHERE子句,不要寫沒有WHERE的SQL語句。
C、 注意SELECT INTO後的WHERE子句,因爲SELECT INTO把數據插入到臨時表,這個過程會鎖定一些系統表,如果這個WHERE子句返回的數據過多或者速度太慢,會造成系統表長期鎖定,諸塞其他進程。
D、對於聚合查詢,可以用HAVING子句進一步限定返回的行。
2、 儘量少做重複的工作
這一點和上一點的目的是一樣的,就是儘量減少無效工作,但是這一點的側重點在客戶端程序,需要注意的如下:
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
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代替寫法。比如:
- 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)
6、 慎用遊標
數據庫一般的操作是集合操作,也就是對由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,分別代表主單位、單位1、單位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、 注意動態遊標的不確定性,動態遊標查詢的記錄集數據如果被修改,會自動刷新遊標,這樣使得動態遊標有了不確定性,因爲在多用戶環境下,如果其他進程或者本身更改了紀錄,就可能刷新遊標的記錄集。
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有索引則不應該改。
發現過這樣的語句:
- 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’
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語句檢查數據庫表和索引是否有問題,這兩個語句也能修復一般的問題。
D、
五、 網上資料中一些說法的個人不同意見
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有效。
答: 詳見: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)
二三、如何分析ORACLE的執行計劃?
答: 詳見:http://blog.chinaunix.net/space.php?uid=22539324&do=blog&id=2644068
二四、 DB中索引原理,種類,使用索引的好處和問題是什麼?
答: 經常需要修改的表不易對改變建立索引,因爲數據庫對索引進行維護需要額外的開銷。對經常需要查詢的大數據表需要建立索引,這樣會增加
查詢的效率。
索引的原理:沒有找到合適的答案。
索引的種類:B*Tree、反向索引、降序索引、位圖索引、函數索引。詳見:http://wenku.baidu.com/view/d4d6ee1ba76e58fafab00336.html
二五、JVM垃圾回收實現原理。垃圾回收的線程優先級。
答: 詳見:http://chenchendefeng.iteye.com/blog/455883
二六、jvm 最大內存設置。設置的原理。結合垃圾回收講講。
答: 詳見:http://www.open-open.com/lib/view/open1324736648468.html