namejm

　　如果原始数据中没有重复的数值，并且数值的位数是已知的，那么，可以考虑用 for /l 生成从1～N的递增序列，每生成一个数值，就用 findstr 在原始表中查询数据，我觉得这应该是最简洁最高效的办法。

　　当然，如何用 findstr 来精确匹配每一列数值，还得想办法对原始数据做一番处理。至于需要如何处理，各位开动脑筋想一想吧^_^。

namejm

　　我认为，对于排序的问题，并没有一个谁快谁慢的绝对方案，要具体问题具体分析。

　　如果数据十分少，且范围十分大，用 for /l + findstr 的方法无疑是很浪费的做法。

　　如果是大量的数据，并且数据范围很窄，那么， for /l + findstr 应该是比较有优势的，因为用 for /l 罗列数字序列的速度非常快，可以免去数值大小的比较这一步，比较耗时的操作都是花费在频繁地调用findstr来打开文本文件上面，这使得 for /l + findstr 方案的效率骤然降低；在这种情况下，我觉得如果换用其他的方案，还需要先正确提取每一个数值，然后遍历表中的数据，对取到的每一个数值在表中做一番比较，处理次数将呈几何级增长，即使通过优化算法，数值比较的次数仍然十分可观，比较保守的估计，比较次数应该不低于1+2+3+……+N 次（N为数字个数），再加上批处理中没有数组的设计，保存那些临时数据也是件麻烦的事情，综合起来考虑，我并不觉得其他的方法比 for /l + findstr 好到哪里去。当然，限于本人的学识，对排序算法粗通皮毛，不知道是否有更高效的算法存在。

　　声明：以上言论未经实测验证，仅为本人的推理，正确与否，以实际测试结果为准。

namejm

　　如果是 set 后再 for ，对付少量的数据确实是个很高效的算法；若楼主的意图是处理海量数据，那么，大量的变量将会撑满内存，好像场面壮观了点^_^。

namejm

　　做这个题目的时候，又想起了以前在其他论坛曾经帮别人解答过类似的题目，有位网友给出了一段十分经典的代码，用的是 for /l + findstr正则+sort 方案，只需要设置两个变量即可搞定，处理海量数据的速度只能用震惊来形容，处理顶楼的数据，排序部分花了不到两秒钟（机器配置：主频1.6G、内存512M、操作系统XP_SP3）。呵呵，先卖个关子，请大家继续。

　　用顶楼的数据来测试我那个 for /l + findstr 的猜想，等了快10分钟都还没得到最终结果，看来cmd.exe对频繁调用某些命令可能有一些抑制机制，以防非正常的调用导致系统崩溃——当然，这只是我的一个猜想，各位可以当做是我在为自己可耻的失败寻找冠冕堂皇的理由^_^。

namejm

　　for /l+findstr+sort 方案需要生成临时文件，临时文件是一行一条数据，然后想办法sort，需要用findstr的正则来控制要提取的数字的位数，如何控制参与sort的数字的位数是这个方案的关键，暂时就提示那么多，看看有没有人能写出成形的代码。

　　呵呵，貌似这个题目弄成挑战赛了。

namejm

　　terse在17楼的代码思路也非常不错，如果第二条for语句不使用type语句而直接sort的话，效率还可以稍有提升。

　　23楼的思路正是我提到的 for /l+findstr+sort 方案，与17楼的方案比起来，在速度上差远了。

　　就目前情况而言，17楼的方案应该是最通用、也是效率最高的了。