怎么理解？动起手来才能发现问题，我是这个纠结了大半天，截图示例。
如下截图，扩展事件捕获到的两个目标事件的SessionId都是58，但是执行的SQL是不一样的，
如下截图是不区分事件类型，捕获到的所有的事件信息。
也就是上面说的，对于58号Session:
第一次运行了
SELECT COUNT(1) FROM TestCollectionSessionWaitStats第二次运行了
SELECT COUNT(1) FROM TestCollectionSessionWaitStats WHERE Id>10两次运行的SQL一致或者不一致问题不大，关键是捕获到的等待事件信心的SessionId也是58，怎么区分产生的事件是归属于哪一次的运行？
比如58号Session运行两次sql，产生了10条等待信息，怎么区分这10条等待信息哪些归属于第一次运行生成的，哪些归属于第二次运行生成的？
这个就依靠上面说的第二点“同一个时间段内，一个同一个SessionId不可能同时执行”
对于同一个SessionId，在sql_batch_completed事件中，从时间的维度来看
小于第一次sql_batch_completed事件完成时间的必然是58号Session第一次执行生成的
大于第一次sql_batch_completed事件完成事件的且小于第二次sql_batch_completed的必然是58号Session第二次执行生成的
有了这个理论基础，我们统计Session级别的等待就比较容易了，相信这个逻辑的实现并不难。
如下图是58号Session执行某SQL语句产生的等待详细信息，可以看到多次产生了CXPACKET和 PAGEIOLATCH_SH等待
鉴于截图问题，下面还有另外一个同样是58号Session的执行另外一个SQL捕获到的等待信息
这个统计办法就是上面提到的，在两次sql_batch_completed事件中，虽然等待事件的SessionId一样，
但是其发生的时候是处于当前事件的sql_batch_completed之前，上一次sql_batch_completed之后，
这样就可以完美地匹配到sql_batch_completed事件与其对应的wait_info事件。
在这种情况下，统计得到类似于SQL Server 2016中的sys.dm_os_wait_stats的结果也就不难了。
与sys.dm_os_wait_stats 等待信息的结果相比，上述通过扩展事件获取的等待信息，是不是更加详细和具体？
比如对于CXPACKET等待时间，
不难发现，如果计算计算其产生的次数（count），就类似于sys.dm_os_wait_stats 中的waiting_tasks_count，计算其产生的总时间（sum），就类似于wait_time_ms
