标题：一次高并发下的sql分析,及最终解决方法：
现象：pagelatch_ch,pagelatch_ex 资源等待多
1. 对bulk insert 的使用方式改造，1000条以上的数据才会用bulk insert （数据条目少的时候使用insert 命令）
2. order 中使用了大量的表变量，对tempdb 的性能要求比较高，经常出现 pagelatch_ch,pagelatch_ex 的等待，为此将tempdb 的文件数量调整至 与数据库服务器的CPU核心数 等同，tempdb的数据文件文件的大小和增长值要一样；但最终将部分表变量改造为 公共表表达式写法 with cte 方式
注1. SQLServer 【表变量，临时表】性能比对（表变量比临时表性能好，造成的pagelatch_sh,pagelatch_ex 等待更少，在tempdb 文件数与cpu 核心数一致的情况下）
具体性能比对结果如下：https://channel9.msdn.com/Series/SQL-Workshops/Tempdb-Metadata-Contention-in-SQL-Server-Table-Variable-Vs-Temporary-Table）
注2：过多的表变量会导致sqlserver tempdb 元数据争用（tempdb metadata 上会有pagelatch_sh,pagelatch_ex资源等待 ），后续把表变量逐步改善为 WITH CTE 写法（公用表表达式common table express(CTE)）；CTE 表达式比 表变量效率更高或持平，但是不会对tempdb进行资源消耗，不会导致tempdb 的元数据资源等待
https://www.cnblogs.com/xmliu/p/7085644.html?utm_source=itdadao&utm_medium=referral
3.将事务的隔离级别进行调整：SERIALIZABLE(可序列化)->READ COMMITTED(已提交读,默认级别) [https://www.cnblogs.com/chenmh/p/3998614.html]
SQLServer 高并发下的 【表变量，临时表，公共表表达式】的性能比拼（HIS3）
原文：https://www.cnblogs.com/ifreesoft/p/14101936.html
如果您也喜欢它,动动您的小指点个赞吧
602392714
清零编程群