最近 和一个同事一同开发一个电商项目 项目收尾写报表的时候 队友可把我坑惨了
首先是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)=null
SELECT @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
闪电一般的速度 完美解决队友的坑 也想解决我的坑队友