winscp中文版 怎么可以同步的快一点

Posted 2023-05-11

参考技术A 下载安装完成WinSCP软件后，进入到需要同步文件的目录，如下图

进入到需要同步文件的目录后，点击界面上方的同步按钮，如下图

点击后会弹出一个窗口，窗口名为同步

第一个设置项就是本地目录也就是本地文件存放的位置，本地目录的下方是远程目录，是服务器文件存放的位置；在方向目录中如果是服务器同步文件到本地，就选择本地，如果是本地文件同步到服务器就选择远程，这里不要选择错了，不然后期非常麻烦

接着就是模式设置，模式设置直接选择默认的“同步文件”选项即可；在同步选项设置里设置设置按照修改时间和选上预览修改即可

如果选择了预览修改，然后会比较文件，当然这样可能要花一些比较的时间，但是如果设置出错了预览能够及时的发现，不至于产生破坏性的影响。本回答被提问者采纳

MYSQL group by 怎么能快一点，之别一根筋

一般来都有这样一个说法，MYSQL 表的数据超过500万行就不行了，而在这个说法之后就是MYSQL 的group by 的性能奇差无比。

如果要用一句话来说，你把MYSQL 当其他数据库用了（PG, SQL SERVER ,ORACLE），所招致的结果。

select last_name,count(*) from employees where hire_date between 1990-01-01 and 2000-01-01 group by last_name limit 10;

上面是一个查询语句

下面是有索引，没索引，不同索引的查询时间

三种情况，最后将索引落在分组字段的情况下，查询的时间是最短的。

因为group by实际上执行相同的排序操作，所以group by基本上只是排序后的分组操作，这样，我们就可以一组一组地扫描数据，并动态地执行组。所以在有where 后的条件的索引和GROUP BY 的字段的索引，这样的情况大概率的可能性选择的是分组的索引来进行相关的查询。

当然我们也可以通过，一些参数来强制系统查询的预期结果，例如 SQL_SMALL_RESULT , SQL_BIG_RESULT , SQL_BUFFER_RESULT

我们可以看到三种强制的预期，

1 我们的group by 或 distinct 操作的数据结果集是比较大的，则使用big_result，MYSQL会在磁盘创建临时表，并且很可能走全表扫描的方式

2 如果我们的预设的结果集比较小，则结果集会在内存中进行存储，大家可以看到连香港的 file sort 都不在存在

3 如果希望更快的解锁查询的表，可以选择buffer_result, 将尽快的将表解锁并且将结果存储在本地机，而不是 直接 send data

下面我们来看一个稍微复杂的查询

select d.dept_no,count(s.salary) as count_salary from employees as e 

    -> left join salaries as s on e.emp_no = s.emp_no 

    -> left join dept_emp as d on d.emp_no = e.emp_no

    -> where e.gender = M

    -> group by d.dept_no;

查询的主要目的查询是男性的每个部门的总的工资消耗

可以看到基本上查询在不到6秒的时间，如何优化这样的查询在MYSQL中。

首先查询的时间过长是一个问题，有的时候我们的想法一般是怎么让这个语句更快的出结果，而加各种的索引，而实际中语句的优化的另一种想法是怎么能让锁表的时间更短，看上去这两者不矛盾，但实际当然其实可能是两种截然不同的思路。

例如上面的语句我这样操作，首先获得所有的部门分组信息的dept_no

将其保存在程序的缓存中，然后

通过下面的语句将每个部门的工资总和获取后，在进行累加的计算（这使用程序来做不是一件困难的事情），最后获得总体的和上面语句一样的结果，而经过实际的操作，整体的查询九个部门的工资最长的不过0.34秒，最短的仅仅0.02秒。整体的查询9次累加的耗时都不超过1 秒。

select d.dept_no,count(s.salary) as count_salary from employees as e  left join salaries as s on e.emp_no = s.emp_no  left join dept_emp as d on d.emp_no = e.emp_no where e.gender = M and d.dept_no = d009;

通过这样的查询方法，总比死在怎么整体优化一条SQL 要好的多，语句优化，一定要灵活，不要一根筋。当然遇到类似的情况也要分析，如果遇到GROUP BY 就用这样的方法，其实还是一根筋。