最近 和一個同事一同開發一個電商項目 項目收尾寫報表的時候 隊友可把我坑慘了
首先是SQL SERVER DATENAME()這個方法的坑
再次是一個日期的性能問題

1.DATENAME(month,getdate())在數據庫腳本運行環境為中文的時候返回01、02的數據，運行環境為英文的時候返回may這樣的英文日期縮寫

報表按月查詢 界面大概就長這個樣子 傳去存儲的參數：@time=‘202005’

既然只說時間的問題
定義一個訂單表Orders如下:

CREATE TABLE [dbo].[Orders]([OrderID] [int] IDENTITY(1,1) NOT NULL, --訂單號[AddTime] [datetime] NULL --訂單時間 )

當時我們的開發環境和測試環境的數據庫腳本執行語言是中文的 線上卻是英文的
導致以下慘劇:
sql語句如下：

declare @time varchar(20)=‘202005’ select COUNT(*) from Orders WHERE DATENAME(YEAR,AddTime)+DATENAME(MONTH,AddTime) =@time

開發環境數據庫：

線上環境數據庫：

坑爹啊 數據全掛了
后面試了下：

set language 'Simplified Chinese' declare @time varchar(20)=‘202005’ select COUNT(*) from Orders WHERE DATENAME(YEAR,AddTime)+DATENAME(MONTH,AddTime) =@time

把腳本的運行環境改為中文 但是返回特別卡
我以為這樣設置不行 實際上是可以的（就是卡）
后面又換種寫法：

declare @time varchar(20)='202005' select COUNT(*) from Orders --WHERE substring(CONVERT(varchar(100),AddTime, 112),0,7)=@time WHERE RIGHT(CONVERT(varchar(100),AddTime, 112),6)=@time

但是還是超級卡 那就是性能問題了

2.把日期轉為字符去比較的性能問題

把數據庫的日期類型字段轉成字符去比較性能會變的超級差 而且也利用不了索引 最后換成這種方法： declare @time varchar(20)='202005',@startTime varchar(50)=null,@endTime varchar(50)=nullSELECT @startTime= substring(@time,0,5)+'-'+substring(@time,5,2)+'-'+'01' SELECT @endtime=CONVERT(VARCHAR(7),DATEADD(MONTH, 1, @startTime),121)+'-01'select COUNT(*) from Orders WHERE AddTime>@startTime and AddTime<@endTime

閃電一般的速度 完美解決隊友的坑 也想解決我的坑隊友

總結

以上是生活随笔為你收集整理的SQL DATENAME(month,getdate())返回的数据为英文日期及把日期转为字符去比较的性能问题的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。