基于PowerShell实现数据复制精准耗时测量 排查数据库迁移估时脚本失真问题

具体的脚本bug #

• 复制逻辑存在硬路径错误：你用Get-ChildItem -Recurse遍历源目录拿到的是嵌套的文件、子目录对象，但Copy-Item的时候没有还原对应的目录层级，所有条目都被直接丢到根目标路径E:\SQL01。一方面递归遍历会重复识别到所有子目录条目，大幅触发路径冲突报错；另一方面如果是正在运行的SQL实例对应的数据库文件，还会因为被进程锁定直接拒绝访问。这些场景下Copy-Item都会直接抛错快速返回，根本不会执行实际的磁盘读写，Measure-Command自然只会统计到错误流程结束的极短耗时——把几百个微秒级的错误操作耗时加起来，刚好就是你看到的22毫秒。
• 计时方法本身不准：就算复制能正常跑通，逐文件单独测耗时再加总的逻辑，会重复叠加PowerShell命令解析、文件元数据查询的固定开销，还会被系统文件缓存的临时加速效果干扰，完全反映不出大文件连续传输的真实吞吐水平。
• 脚本输出逻辑无效：你最后写的$results -f "c"是对数组做格式化，根本不会输出任何内容，你拿到的那个总耗时本质是所有快速返回的错误操作的累加值，和实际5TB数据的传输没有任何关系。

实用的时长估算方法 #

完全没必要逐文件跑复制循环来测时间，效率低还不准：

1. 先测稳定传输带宽：在源、目标路径之间传一个10-20GB的临时大文件，用Measure-Command测这一次完整传输的耗时，算出两个存储位置之间的实际有效吞吐（即总传输字节/总耗时）。
2. 统计准确的待迁移总数据量：执行(Get-ChildItem 'D:\SQL01' -Recurse -File | Measure-Object -Property Length -Sum).Sum拿到所有需要迁移的文件的总字节数，用总数据量除以之前测出的稳定带宽，就能得到贴合实际的理论迁移时长。
3. 正式迁移优先用robocopy替代手写的逐文件循环：这类专门为大目录迁移设计的工具会自动还原目录结构、对被锁定的文件自动重试，跑完后还会直接输出总耗时、平均吞吐数据，比PowerShell循环的可靠性高很多。

额外提醒：迁移SQL Server数据文件前，一定要先停掉对应的SQL实例，不然文件被进程锁定会直接中断复制流程，测出来的时长完全没有参考性。

内容的提问来源于stack exchange，提问作者sam.solo.works