--1. 执行下这个， 贴出截图出来：

EXEC sp_helpindex 'PackCodeInfo'



--2. 这个的结果， 也贴截图出来

SELECT 

 COUNT(DISTINCT ProductID) AS ProductID_CNT

,COUNT(DISTINCT Batchno) AS Batchno_CNT

,COUNT(DISTINCT LevelNo) AS LevelNo_CNT

FROM PackCodeInfo WITH(NOLOCK)



--3. 分区不是空口白话，分区字段必须放在 where 之中才能提高效率

--   3.1 你的 where 为什么不带分区字段？是否可以加上？

--   3.2 你经常用的查询就是下面这个？

/*

select PackCode,BoxNo 

from PackCodeInfo where ProductID='3' and Batchno='1305131' and LevelNo=2 

order by Boxno

*/



--4. 这个表的增、删、改是否频繁？



--5. 所有不包含中文的字符串类字段， 都应该由 nvarchar 改为 varchar 



--6. 2 亿多条数据， 已经是一个比较大的数据量， 想很快反应其实是比较困难的。

--   首先， 不需要的历史数据应该归档到历史表。 

--     按日期分 历史表（一年前），较常用表（一年内），当前表（一个月内） 比较好;

--   如果分 3 个表了还是卡或者不想分， 那你就得把常用的结果， 以报表形式弄出来， 

--   每天凌晨统计出结果报表， 让用户查最终的报表， 而不是直接查源表。

1， 2  步只是查询操作， 能有什么影响？先贴出来再说吧。
3.  分区字段你查询时 where 里用不到， 那分区有什么意义？还不如不分区，把聚集索建立在经常查的字段上。
4.  主要是关心是否频繁， 你没回答。
5.  如果你确定只是纯英文或数字就换 varchar ， 没什么好怕的。 如果什么都不相信， 来论坛就没什么意义了。
6.  如果你不按我说的分表， 也不想做报表， 这么大的数据量还想快速查询， 很困难。思路要转变过来——不破不立。
-- 即使按你们现在的做法， 也可以把转移的周期缩短， 比如 2、3 个月转一次。

索引碎片整理之后， 有一定的效果， 你可以用一下， 建立作业， 每个周末的凌晨执行一次。但你的数据量这么大， 还是解决不了根本。
https://blog.csdn.net/yenange/article/details/52412297

--5. 所有不包含中文的字符串类字段， 都应该由 nvarchar 改为 varchar ？？ 我不太同意这个做法，以我的经验，好多时，我还要把varchar 改为nvarchar，用varchar时，会很慢，但改为nvarchar就快多了。

Quote: 引用 10 楼 sywcf 的回复:

--5. 所有不包含中文的字符串类字段， 都应该由 nvarchar 改为 varchar ？？ 我不太同意这个做法，以我的经验，好多时，我还要把varchar 改为nvarchar，用varchar时，会很慢，但改为nvarchar就快多了。

你改列类型， 只是主动更新了统计信息导致变快吧， 如果你现在再改回 varchar ， 你再看看是否会变慢？

如果你还不信， 举一个可以重现的例子出来： 
把脚本贴出来， 
或者把你的测试库用云盘共享出来。