與編譯生成的sql語句不夠靈活

㈠ sql 語句問題

1.當然就是不等於的意思。還可以用!=表示。
2.SELECT * FROM TABLENAME where 1=1 表示取全部記錄。
其實與無條件時(SELECT * FROM TABLENAME)，是一樣的效果。
但時有時候，比如在需要動態生成查詢語句時，為了格式的一致性和通用性，必需要出現WHERE子句，而又要選擇全部記錄時，條件就可以給1＝1，即條件為真。

==================
where 1=1 和沒有這個 1=1 有什麼不同?
答：
WHERE 子句後面必須要有條件。
所以，當有WHERE 時，要想顯示全部記錄，就須使用1=1或2=2之類的結果為真的條件表達式。
就是說：
有WHERE 1=1或沒有where 1=1是一樣的。
但是有WHERE時，後面有沒有1=1就不一樣了，因為
SELECT *FROM TABLENAME WHERE
這個語句缺少條件。會報錯。
SELECT *FROM TABLENAME WHERE 1=1才是對的
而
SELECT *FROM TABLENAME 與上面語句輸出效果相同。但動態生成SQL語句時前者會更方便和通用一些。

㈡ 【求助】SQL的問題

MY SQL， SQL Server， Oracle 是三種資料庫
基本的 SQL 語句是一樣的，就是某些語法/函數 的細節上，有差異。
這些資料庫，是作為伺服器來運行的。 不是讓你把 SQL 語句編譯成 EXE 的
這個與 C/C++， java 有一定的差異。

資料庫主要是 配合這 C/C++， Java 來協同工作的。不是獨立工作的。
舉個例子，比如你有一個 圖書館管理系統 的軟體。
你需要用文件來保存 圖書的名稱/編號/分類/作者...等信息。
以及哪些人，在什麼時候，借了書，又在什麼時候，歸還了書。
你需要自定義文件的結構，自己處理文件的讀寫，管理好文件的指針之類的。
還要寫演算法，負責檢索，哪些書籍沒有歸還，哪些書借得多之類的。

如果用資料庫的話，只需要建立幾張表。 C/C++ Java 那裡，就不需要自己管理文件了。
只需要打開資料庫連接，然後傳遞 INSERT / SELECT / UPDATE / DELETE 之類的 SQL 語句
給 資料庫伺服器就可以了。
至於要做什麼復雜的查詢，比如哪些書籍沒有歸還，哪些書借得多之類的。
只需要 寫一個 SELECT 的 SQL 語句就可以了。

至於某些非常復雜/耗時的操作， 那麼需要寫存儲過程。
這個存儲過程，是要編譯的。
但是編譯的結果，不是什麼 EXE 之類的程序。
是編譯成資料庫伺服器可以處理的執行代碼，外部不可見的。

下面是 SQL Server 的一些日常處理的例子，你可以參考參考。
http://hi..com/wangqing999/blog/category/Sql%20Server

㈢ JSP頁面寫的SQL語句為什麼執行速度非常慢

如果你從後台傳過來，那是因為你已經把數據給查到了，只要在頁面操作就行了！相反，如果在頁面上寫SQL查數據，每次都有重新查一遍，速度當然就慢下來了啊！

㈣ SQL查詢語句性能優化建議

1對查詢進行優化，應盡量避免全表掃描，首先應考慮在 where 及 order by 涉及的列上建立索引。
2.應盡量避免在 where 子句中對欄位進行 null 值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：

select id from t where num is null

可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：

select id from t where num=0

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

4.應盡量避免在 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

5.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

6.下面的查詢也將導致全表掃描：

select id from t where name like '«c%'

若要提高效率，可以考慮全文檢索。

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

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

select id from t with(index(索引名)) where num=@num

8.應盡量避免在 where 子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where num/2=100

應改為:

select id from t where num=100*2

9.應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：

select id from t where substring(name,1,3)='abc'--name以abc開頭的id

select id from t where datediff(day,createdate,'2005-11-30')=0--『2005-11-30』生成的id

應改為:

select id from t where name like 'abc%'

select id from t where createdate>='2005-11-30' and createdate<'2005-12-1'

10.不要在 where 子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。

11.在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致
12.不要寫一些沒有意義的查詢，如需要生成一個空表結構：

select col1,col2 into #t from t where 1=0

這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：

create table #t(...)

13.很多時候用 exists 代替 in 是一個好的選擇：

select num from a where num in(selectnum from b)

用下面的語句替換：

select num from a where exists(select 1 from b where num=a.num)

14.並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。

15.索引並不是越多越好，索引固然可以提高相應的 select 的效率，但同時也降低了 insert 及 update 的效率，因為 insert 或 update 時有可能會重建索引，所以怎樣建索引需要慎重考慮，視具體情況而定。一個表的索引數最好不要超過6個，若太多則應考慮一些不常使用到的列上建的索引是否有必要。

16.應盡可能的避免更新 clustered 索引數據列，因為 clustered 索引數據列的順序就是表記錄的物理存儲順序，一旦該列值改變將導致整個表記錄的順序的調整，會耗費相當大的資源。若應用系統需要頻繁更新 clustered 索引數據列，那麼需要考慮是否應將該索引建為 clustered 索引。

17.盡量使用數字型欄位，若只含數值信息的欄位盡量不要設計為字元型，這會降低查詢和連接的性能，並會增加存儲開銷。這是因為引擎在處理查詢和連接時會逐個比較字元串中每一個字元，而對於數字型而言只需要比較一次就夠了。

18.盡可能的使用 varchar/nvarchar 代替 char/nchar ，因為首先變長欄位存儲空間小，可以節省存儲空間，其次對於查詢來說，在一個相對較小的欄位內搜索效率顯然要高些。

19.任何地方都不要使用 select * from t ，用具體的欄位列表代替「*」，不要返回用不到的任何欄位。

20.盡量使用表變數來代替臨時表。如果表變數包含大量數據，請注意索引非常有限(只有主鍵索引)。

21.避免頻繁創建和刪除臨時表，以減少系統表資源的消耗。

22.臨時表並不是不可使用，適當地使用它們可以使某些常式更有效，例如，當需要重復引用大型表或常用表中的某個數據集時。但是，對於一次性事件，最好使用導出表。

23.在新建臨時表時，如果一次性插入數據量很大，那麼可以使用 select into 代替 create table，避免造成大量 log ，以提高速度;如果數據量不大，為了緩和系統表的資源，應先create table，然後insert。

24.如果使用到了臨時表，在存儲過程的最後務必將所有的臨時表顯式刪除，先 truncate table ，然後 drop table ，這樣可以避免系統表的較長時間鎖定。

25.盡量避免使用游標，因為游標的效率較差，如果游標操作的數據超過1萬行，那麼就應該考慮改寫。

26.使用基於游標的方法或臨時表方法之前，應先尋找基於集的解決方案來解決問題，基於集的方法通常更有效。

27.與臨時表一樣，游標並不是不可使用。對小型數據集使用 FAST_FORWARD 游標通常要優於其他逐行處理方法，尤其是在必須引用幾個表才能獲得所需的數據時。在結果集中包括「合計」的常式通常要比使用游標執行的速度快。如果開發時間允許，基於游標的方法和基於集的方法都可以嘗試一下，看哪一種方法的效果更好。

28.在所有的存儲過程和觸發器的開始處設置 SET NOCOUNT ON ，在結束時設置 SET NOCOUNT OFF 。無需在執行存儲過程和觸發器的每個語句後向客戶端發送 DONE_IN_PROC 消息。

29.盡量避免大事務操作，提高系統並發能力。

30.盡量避免向客戶端返回大數據量，若數據量過大，應該考慮相應需求是否合理。

㈤ 一條復雜的SQL語句，為什麼第一次查詢很慢，而第二次查詢卻明顯快了

第一次SQL要先編譯，從磁碟讀入緩存，再返回客戶端。

第二次SQL不用編譯，直接運行，會省時間，最省時間的是不用再讀入緩存及查找了，直接返回客戶端。

㈥ 存儲過程和sql語句的優缺點優點有哪些

存儲過程是一組予編譯的SQL語句
它的優點：1.允許模塊化程序設計，就是說只需要創建一次過程，以後在程序中就可以調用該過程任意次。
2.允許更快執行，如果某操作需要執行大量SQL語句或重復執行，存儲過程比SQL語句執行的要快。
3.減少網路流量，例如一個需要數百行的SQL代碼的操作有一條執行語句完成，不需要在網路中發送數百行代碼。
4.更好的安全機制，對於沒有許可權執行存儲過程的用戶，也可授權他們執行存儲過程。

㈦ sql運行問題

sql運行問題？
資料庫運行過程中常見的故障有3類：事物故障、系統故障、介質故障。

恢復策略：
1、事物故障：
發生事務故障時，被迫中斷的事務可能已對資料庫進行丁修改，為了消除該事務對資料庫的影響，要利用日誌文件中所記載的信息，強行回滾該事務，將資料庫恢復到修改前的初始狀態。
為此，要檢查日誌文件中由這些事務所引起的發生變化的記錄，取消這些沒有完成的事務所做的一切改變，這類恢復操作稱為事務撤銷。
2、系統故障：
系統故障的恢復要完成兩方面的工作，既要撤銷所有末完成的事務，還要重做所有已提交的事務，這樣才能將資料庫真正恢復到一致的狀態。

3、介質故障：
介質故障比事務故障和系統故障發生的可能性要小，但這是最嚴重的一種故障，破壞性很大，磁碟上的物理數據和日誌文件可能被破壞，這需要裝入發生介質故障前最新的後備資料庫副本，然後利用日誌文件重做該副本後所運行的所有事務。
「數據故障恢復」和「完整性約束」、「並發控制」一樣，都是資料庫數據保護機制中的一種完整性控制。所有的系統都免不了會發生故障，有可能是硬體失靈，有可能是軟體系統崩潰，也有可能是其他外界的原因，比如斷電等等。
資料庫運行的突然中斷會使資料庫處在一個錯誤的狀態，而且故障排除後沒有辦法讓系統精確地從斷點繼續執行下去。這就要求DBMS要有一套故障後的數據恢復機構，保證資料庫能夠回復到一致的、正確地狀態去。

㈧ 這段代碼sql語句能否正常執行。存在哪些問題

不能正常運行因為這就是不是sql的代碼……

你應該把sql的命令單獨拿出來在資料庫運行一次，然後確定沒有問題再寫進程序去。

㈨ sql語句優化有什麼方法

1. 對查詢進行優化，應盡量避免全表掃描，首先應考慮在where及orderby涉及的列上建立索引。

2. 應盡量避免在where子句中對欄位進行null值判斷，否則將導致引擎放棄使用索引而進行全表掃描，如：
   selectidfromtwherenumisnull
   可以在num上設置默認值0，確保表中num列沒有null值，然後這樣查詢：
   selectidfromtwherenum=0

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

4. 應盡量避免在where子句中使用or來連接條件，否則將導致引擎放棄使用索引而進行全表掃描，如：
   selectidfromtwherenum=10ornum=20
   可以這樣查詢：
   selectidfromtwherenum=10
   unionall
   selectidfromtwherenum=20
   

5. in和notin也要慎用，否則會導致全表掃描，如：
   selectidfromtwherenumin(1,2,3)
   對於連續的數值，能用between就不要用in了：
   
   

6. 下面的查詢也將導致全表掃描：
   selectidfromtwherenamelike'%abc%'
   

7. 應盡量避免在where子句中對欄位進行表達式操作，這將導致引擎放棄使用索引而進行全表掃描。如：
   selectidfromtwherenum/2=100
   應改為:
   selectidfromtwherenum=100*2

8. 應盡量避免在where子句中對欄位進行函數操作，這將導致引擎放棄使用索引而進行全表掃描。如：
   selectidfromtwheresubstring(name,1,3)='abc'--name以abc開頭的id
   應改為:
   selectidfromtwherenamelike'abc%'
   

9. 不要在where子句中的「=」左邊進行函數、算術運算或其他表達式運算，否則系統將可能無法正確使用索引。
   

10. 在使用索引欄位作為條件時，如果該索引是復合索引，那麼必須使用到該索引中的第一個欄位作為條件時才能保證系統使用該索引，
    否則該索引將不會被使用，並且應盡可能的讓欄位順序與索引順序相一致。
    

11. 不要寫一些沒有意義的查詢，如需要生成一個空表結構：
    selectcol1,col2into#tfromtwhere1=0
    這類代碼不會返回任何結果集，但是會消耗系統資源的，應改成這樣：
    createtable#t(...)
    

12. 很多時候用exists代替in是一個好的選擇：
    selectnumfromawherenumin(selectnumfromb)
    用下面的語句替換：
    selectnumfromawhereexists(select1frombwherenum=a.num)
    

13. 並不是所有索引對查詢都有效，SQL是根據表中數據來進行查詢優化的，當索引列有大量數據重復時，SQL查詢可能不會去利用索引，
    如一表中有欄位sex，male、female幾乎各一半，那麼即使在sex上建了索引也對查詢效率起不了作用。