1、truncate 和 delete
truncate操作沒有記錄刪除操作日誌
主要的原因是因為 truncate 操作不會啟用觸發器,因為truncate操作不會記錄各行刪除操作的日誌,所以當你需要刪除一張表的資料時你需要考慮是否應該有刪除操作記錄日誌，而不是根據個人的習慣來操作。
2、事務
[1]並不是事務中的任意一條語句報錯整個事務都會回滾，其它的可執行成功的語句依然會執行成功並提交。
[2]try...catch
delete from table1
begin try
begin transaction
insert into table1(id,age) values(1,20)
insert into table1(id,age) values(2,20)
insert into table1(id,age) values(3,20)
insert into table3 values(1)
commit transaction
end try
begin catch
rollback transaction
end catch
----重新開啟乙個回話執行查詢，發現由於存在物件出錯begin catch並沒有收到執行報錯，且事務一直處於開啟狀態，沒有被提交，也沒有執行回滾。
select * from table1
---如果事務已經提交查詢xact_state()的狀態值是0,或者執行dbcc opentran
select xact_state()
dbcc opentran
---手動執行提交或者回滾操作
rollback transaction
try...catch 不會返回物件錯誤或者字段錯誤等型別的錯誤。
[3]開啟xact_abort
set xact_abort on
begin transaction
insert into table1(id,age) values(1,20)
insert into table1(id,age) values(2,20)
insert into table1(id,age) values(3,20)
insert into table3 values(1)
commit transaction
set xact_abort off
---事務全部執行回滾操作(物件table3是不存在報錯，但是也回滾所有的提交，跟上面的try...catch的區別)
select * from table1
---查詢是否有開啟事務
select xact_state()
dbcc opentran
未查找到有開啟事務
當 set xact_abort 為 on 時，如果執行 transact-sql 語句產生執行時錯誤，則整個事務將終止並回滾。
當 set xact_abort 為 off 時，有時只回滾產生錯誤的 transact-sql 語句，而事務將繼續進行處理。如果錯誤很嚴重，那麼即使 set xact_abort 為 off，
也可能回滾整個事務。off 是預設設定。
編譯錯誤（如語法錯誤）不受 set xact_abort 的影響。
3、 條件欄位的先後順序
當你建索引的時候索引的順序很重要，一般把查詢最頻繁的字段設第乙個字段，可以避免建多餘的索引。
所以這裡我一般是這樣規定where條件的，對於經常用作查詢的字段放在第乙個位置，其它的字段根據表的實際字段順序排列，這樣往往你的查詢語句走索引的概率會更大。
4、外連線
[1]對於外連線，連線條件不會改變主表的資料，即不會刪減主表的資料；
[2]無論你在連線條件on裡面怎樣設定主表的條件都不影響主表資料的輸出，影響主表資料的輸出只在where條件裡，where條件影響最後資料的輸出。而對於附表的條件就應該寫在連線條件（on）裡而不是where條件裡，這裡說的是外連線（包括左連線和右連線）。
[3]對於inner join就不存在這種情況，無論你的條件是寫在where後面還是on後面都是一樣的，但是還是建議寫在where後面。
5、謂詞型別要與字段型別對齊
[1]謂詞型別與字段型別不一致，於定義表的字段型別與查詢條件中該字段型別不一致，導致執行計畫走了索引掃瞄，且執行計畫select也有提示。
[2] 謂詞型別與字段型別一致，所以查詢走了索引查詢。
6、is not null 與 != (或 <>)區別
平時經常會遇到這兩種寫法：is not null與!=null。也經常會遇到資料庫有符合條件!=null的資料，但是返回為空集合。實際上，是由於對二者使用區別理解不透徹。
預設情況下，推薦使用 is not null去做條件判斷，因為sql預設情況下對 where 字段！= null 的判斷會永遠返回0行，卻不會提示語法錯誤。
原因：sql server文件中對null值的比較運算定義了兩種規則，如在sql server 2000中：
[1]ansisql（sql-92）規定的null值的比較取值結果都為false，既null=null取值也是false。
[2]另一種不遵循ansisql標準，即null=null為true。：
例如資料表test結構：
rownum data ------------------- 1 'liu yang' 2 null 3 '12345'
按照ansi sql標準，下面的兩個查詢都不返回任何行：
查詢一: select * from test where data=null
查詢二: select * from test where data<>null
而按照非ansi sql標準，查詢1將返回第二行，查詢2返回1、3行。
這是因為在sql中，null是一種特有的資料型別，其等價於沒有任何值、是未知數。null與0、空字串、空格都不同。
ansi sql標準中取得null值的行，需要用下面的查詢：select * from test where data is null
而非ansi sql標準中 data=null 等同於 data is null，data<>null 等同於 data is not null。
如果你一定要使用!= null來進行條件判斷，需要加上這個命令語句：set ansi_nulls off，這時資料庫進入ansi sql非標準模式，你會發現is not null 和 != null 是等效的了。
這裡使用的是模式切換命令set ansi_nulls[on/off]。on值採用ansi sql嚴格標準，off值採用非標準相容模式。另外set ansi_defaults [on/off]命令也可以實現標準的切換，只是這個命令控制的是一組符合sql-92標準的設定，其中就包括null值的標準。
預設情況下，資料庫管理程式（db-library）是set ansi_nulls為off的。但是我們的大多數應用程式，都是通過odbc或者oledb來訪問資料庫的，作為一種開放相容的資料庫訪問程式，或許是相容性的考慮，setansi_nulls值設定為on。這樣一來帶來的一些問題是需要注意的。像儲存過程或者自定義函式這樣的應用程式都是基於db-library的，預設情況下，setansi_nulls為off，並且在這樣的程式中，不能使用setansi_nulls在乙個環境中修改規則，只能修改資料庫配置引數。
例如下面這種情況：你的應用程式使用adodb來訪問資料庫，採用oledb或者odbc資料提供程式。對於查詢一: select * from test where data=null 我們可以直接傳送命令取得查詢結果集，也可把它放到儲存過程當中。但二者查詢結果不同。若直接使用查詢命令，不返回任何行；而如果訪問儲存過程，返回第2行的資料。
最後，我們再次宣告：資料庫預設情況下，做sql條件查詢比較時使用關鍵字"is null" 和 "is not null"。
1、去除左空格：ltrim(字段)
2、去除右空格：rtrim(字段)
3、去除前後空格：ltrim(rtrim(字段)) 或 rtrim(ltrim(字段))
4、replace('字串',' ','') 這個是替換所有的空格
日常積累C
預設建構函式準確來說就是在呼叫時不需要傳入形參的建構函式。c 11 在原有提供預設建構函式 賦值建構函式 複製賦值運算子和析構函式的基礎上增加移動建構函式和移動複製運算子。預設建構函式原型 someclass someclass const someclass 移動建構函式原型 someclass ...
linux命令日常積累
壓縮命令 命令格式 tar zcvf 壓縮檔案名.tar.gz 被壓縮檔案名 1 cd 檔案目錄 切換到檔案目錄 2 ls 檢視一下檔案 3 tar zcvf aa 壓縮檔案名 tar.gz bb 要備份的檔名 ear 可先切換到當前目錄下。壓縮檔案名和被壓縮檔案名都可加入路徑。解壓縮命令 命令格式...
Qt之日常積累
qt獲取qdatatimeedit的值 qdatetime datetimes qdatetimeedit time new qdatetimeedit qdatetime currentdatetime datetimes time datetime 讀取qtextedit的值 qstring c...