获取指定日期在其所在（年/月）的第几周

每周的第一天为周日，如果这个周跨月份，则无论输入本周内任何一天，都会计算在上月的最后一周

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31

SET ANSI_NULLS ON
GO
SET QUOTED_IDENTIFIER ON
GO
CREATE function [dbo].[Get_Week_No](@Date datetime,@Dimensionality varchar(100))
--每周第一天为日，周序号以周日所在序号顺次排列
returns varchar(100)
as
begin
	declare @WkNumber varchar(100)
	if(ISNULL(@Date,'')='')
	begin
		set @WkNumber='';
	end
	else
	begin
		if(@Dimensionality='YEAR')
		BEGIN
			--@Date在其所在年份的第几周
			SELECT @WkNumber=datepart( wk, cast(@Date as date))
		END
		ELSE
		BEGIN
			--@Date在其所在月份的第几周
			select @WkNumber= datepart(day,dateadd(day,1-(datepart(weekday,cast(@Date as datetime))),cast(@Date as datetime)))/7 + 1 
		END
	end

		return @WkNumber
end

SQL 执行效率优化

一、避免使用SELECT *

1. SELECT * 属于全表扫描，不利于提高查询效率。
2. 如果本身只需要使用表中的几个字段，全量查询增大了使查询结果集，占用更多的数据库内存，增加数据库负担，甚至出现内存溢出。
3. 除了对数据库增加了压力，对应用程序和网络也增加了压力。

因此，我们在查询时只查需要用到的列就可以了

1
2
3
4
5

--反例
SELECT * FROM Order where Id=1

--正例
SELECT Order_number,Userid FROM Order where Id=1

二、用UNION ALL代替UNION

众所周知，使用UNION ALL可以获取包含重复数据在内的所有数据。而使用UNION查询出的结果集，是经过了比较去重后的。

去重这个过程数据库需要将所有数据进行遍历比较，会增加查询的耗时。因此在确保两个数据集没有重复数据的情况下，使用UNION ALL是最优的。

1
2
3
4
5
6
7
8
9

--反例
SELECT Order_number,Userid FROM Order where Id<100
UNION
SELECT Order_number,Userid FROM Order where Id>200

--正例
SELECT Order_number,Userid FROM Order where Id<100
UNION ALL
SELECT Order_number,Userid FROM Order where Id>200

三、IN 与 EXISTS

IN适用于主表的数据量大于子表的情况，而EXISTS则相反。

两者的详细区别，可以看看这个博主的文章：

SQL 查询中 in 和 exists 的区别分析

1
2
3
4
5
6
7
8
9

--IN适用场景
SELECT Order_number,Userid FROM Order where Id IN(
    SELECT * FROM UserBase WHERE ID<100
)

--EXISTS使用场景
SELECT * FROM UserBase A WHERE EXISTS (
    SELECT Userid FROM Order B WHERE A.Userid=B.Userid
)

四、用连接查询代替子查询

子查询程序会先执行在嵌套在最内层的语句，再执行外层的语句。

执行时会自动创建临时表，查询完毕后会再删除这些临时表，有一些额外的性能消耗。在整体数据量较大的情况下，可以改成连接查询

1
2
3

SELECT * FROM Order A INNER JOIN UserBase B
ON A.Userid=B.Userid
WHERE B.Userid<1000

声明:

• 转载请注明出处。

1、区别

• SQLserver 默认排序规则为Chinese_PRC_CI_AS，此排序规则使用varchar类型来可以“正常存取”存放中文字符以及一些东南亚国家的字符，同时varchar类型在存放英文字符和数字时比nvarchar节省一半的存储空间，但在遇到特殊字符或生僻字时，会产生问题。

Chinese_PRC：针对大陆简体字 UNICODE 的排序规则。

CI：CaseSensitivity：指定不区分大小写。

AS：AccentSensitivity：指定区分重音。

VARCHAR类型的列使用ANSI编码，也即GBK存储数据（不能存储emoji表情）。

NVARCHAR类型的列使用UTF-16编码存储数据（能存储所有Unicode字符，包含emoji表情）。

• 例如：我是cooper

VARCHAR字段占2×2+6=10个字节的存储空间。

NVARCHAR字段占8×2=16个字节的存储空间。

2、应用

1. 写入

   1 2 3 4 5 6 7

   CREATE TABLE test ( [name] [varchar](50) NULL, [type] [nvarchar](50) NULL ) INSERT INTO test (name, type) VALUES (N'®', N'®')

• 插入的字符为商标上的®。
• N表示单引号中的字符串使用的是Unicode编码，我们sqlserver引擎会用Unicode的方式去解析内容，而不是用GBK编码的方式。

2. 查询

   1 2	SELECT * FROM TestDemo WHERE order_type LIKE '%®%' --不用N SELECT * FROM TestDemo WHERE order_type LIKE N'®%' --用N

   查询结果如下：
   

总结

1. 数据库表设计时需要注意是否可能存入特殊字符与生僻字。
2. 建议使用 NVARCHAR 来存放非英文字符数据。理由：

• VARCHAR 类型存放特殊字符或生僻字时存在乱码或字符被转变的问题
• 对于中文字符，使用 VARCHAR 和 NVARCHAR 消耗同样的空间，对于英文字符，使用 VARCHAR 比 NVARCHAR 节省一倍的空间，但随着磁盘成本越来越低，其提升的性能和节省的成本有限。（例外：如果数据中存在大量英文字符和少量非英文字符，则可以结合实际情况考虑 VARCHAR 类型）
• 使用 VARCHAR 存放非英文字符时，容易生成错误的预估值，尤其在执行 LIKE 这类匹配的预估时。

PicGo+Gitee搭建图床

1. 安装PicGo

• 前往PicGo官网下载PicGo
• 注意：windwos 选择.exe，mac 系统选择dmg下载。

2. 打开PicGo

3.安装Gitee插件

• 在插件设置中搜索gitee
  
• 安装gitee-uploader 1.1.2
• 注意：安装前需要保证自己电脑已经安装Node.js

4.创建Gitee图床仓库

• 注册并登陆Gitee
• 新建一个仓库
  
• 将仓库设为公开的
• 只创建master主分支
• 其他信息自行填写，之后提交即可

5.配置PicGo

• 在PicGo的图床设置中找到gitee
  
• repo：用户名/仓库名称
• branch：master
• token：Gitee的私人令牌
• customPath：选年月
• customURL：不用填

私人令牌创建方法

• 点击头像—>设置—>私人令牌—>生成新令牌
  
• 勾选一项即可
• 注意：私人令牌生成后必须自己妥善保存，关闭后无法重新查看

gitee做图床，上传的图片大小不能超过1MB。
参考：https://www.cnblogs.com/xsyz/p/14043564.html