网站的宝塔面板数据库每天都会出现无法链接
香港 服务器 ，wordprss网站天天连不上数据库，重启mySql就可以了。之前也出现过类似的情况，后来这个群里的高手说增加服务器的内存就好了，内存也增加了。过了一会儿又出现了类似的问题，请大神如何解决。
解答
您好！建议您根据MySQL日志排查下问题所在，服务器命令行执行以下命令查看MySQL错误日志。
cat /www/server/data/*.err|grep -i -C 10 error您好，这个错误提示信息的意思是1、您设置的mysql性能配置和当前的服务器无法匹配，建议您在软件商店—MySQL管理—性能调整中调整下，如果您的服务器不是单独的跑mysql，这个优化方案不要设置和您的内存一致的优化方案，否则您的其他服务占用了内存后，会导致无法给您的存储引擎分更多的内存2、存储引擎不支持，从mysql5.5.36版本开始（大概是这个小版本）默认的存储引擎是InnoDB，如果您的表是MyIsam，那么就出现不支持的提示
美国签证审查的流程是什么样的？
Check要分几种情况，但是无论哪一种，只要是被Check了，你的所有资料都会被送到华盛顿的VISA总部，也就是DOS。 当然，材料不是寄过去的，具体不知道是怎样的过程，但是很快。 有人说是传真到总部，但是我在官方网站中看到了Cable一词，也有可能是特殊通道过去。 反正，被Check了，你的所有资料会在当天就进入华盛顿总部的数据库。 第一种情况：你很幸运，是最快的过程。 也许虽然你被Check了，但是总部认为没有必要将你移交到安全部门进入安全审查程序。 那么，一般在3个星期之内，你的状态就会clear。 也有另外一种解释，你的材料很幸运的很快排除了安全因素，没有进入人工审查流程第二种情况：不太走运，你被送到了安全部门，就是他们说的被移交到了USCIS，或者DHS(以前的INS部门)USCIS(U.S. Citizenship and Immigration Services), DHS(U.S. Department of Homeland Security)。 进行的内容，现在知道的有Name Check(背景调查)和Fingerprint Check(指纹比对)。 实际上，背景调查每个被送到DOS的人人应该都做了。 根据FBI的名字调查系统，一般人的名字调查会在3天内得到结果。 但是，并不是所有人的名字调查都没有问题。 如果出现在数据库当中，名字和生日都吻合，那么就出现命中。 出现命中，你的材料可能被送到FBI的相关部门经行人工审查。 这样的过程，FBI最终会给出一个称之为SAO的意见给Department of State，这样的过程因为人工程序的加入，就变长了。 根据，没有出现吻合，使馆部门(posts)可以在10天之内同意VISA申请。 FBI只是争取在120天内完成调查，并且这个时间在经两年都难以保证。 当然，美国政府正在加快这个审查过程。 一般来说，进入这样程序的check就绝不可能在21天内清除状态。 一般的时间好像在45天以上。 但是，一般在2个月到3个月之内，FBI的调查过程会结束。 第三种情况：三个月都没有结束。 几率为2%。 FBI的调查肯定涉及到了某些困难的东西，在这样的情况下，多少时间的检查都有可能了。 等待时间分段：0 天 < 等待 < 60 天每个星期向DOS打个电话吧。 每天打也没必要，他们只是接线员，崔他们一点作用也没有。 每个星期打只是为了能尽早的知道自己clear了，case没有在DOS丢失，没有其他任何的作用。 60 天 < 等待 < 120 天根据规定，超过60天后，你可以向你提交申请的领事馆发传真，他们会帮助你向FBI发出require reply的要求， 但是FBI可以不作答复。 120 天 < 等待签证成功几率渺茫。 原文来源：
如何做SQL Server性能测试
对于DBA来讲，我们都会做新服务器的性能测试。 我会从TPC的基准测试入手，使用HammerDB做整体性能评估（前身是HammerOra），跟厂商数据对比。 再使用DiskSpd针对性的测试磁盘IO性能指标（前身是SQLIO），再到SQLIOSIM测试存储的完整性，再到ostress并发压力测试，对于数据库服务器迁移，我们还会收集和回放Profiler Trace，并收集期间关键性能计数器做对比。 下面我着重谈谈使用HammerDB的TPC-C来做SQL Server基准测试。 自己写负载测试代码很困难为了模拟数据库的负载，你想要有多个应用程序用户和混合数据读写的语句。 你不想总是对单一行更新相同的值，或者只是重复插入假的值。 自己动手使用PowerShell、C#等语言写负载测试脚本也不是不可能，只是太消耗时间，你需要创建或者恢复数据库，并做对应的测试。 免费而简单的压测SQL Server：使用HammerDB模拟OLTP数据库负载HammerDB是一个免费、开源的工具，允许你针对SQL Server、Oracle、MySQL和PostgreSQL等运行TPC-C和TPC-H基准测试。 你可以使用HammerDB来针对一个数据库生成脚本并导入测试。 HammerDB也允许你配置一个测试运行的长度，定义暖机阶段，对于每个运行的虚拟用户的数量。 首先，HammerDB有一个自动化队列，让你将多个运行在不同级别的虚拟用户整合到一个队列--你可以以此获得在什么级别下虚拟用户性能平稳的结果曲线。 你也可以用它来模拟用于示范或研究目的的不同负载。 用于SQL Server上的HammerDB的优缺点HammerDB是一个免费工具，它也极易访问和快速的启动基准测试和模拟负载的方法。 它的自动程序特性也是的运行工作负载相当自动。 主要缺点是它有一个学习曲线。 用户界面不是很直观，需要花费时间去习惯。 再你使用这个工具一段时间之后，将会更加容易。 HammerDB也不是运行每一个基准测试。 它不运行TPC-E基准，例如，SQL Server更热衷于当前更具发展的OLTP基准TPC-E。 如果你用HammerDB运行一个TPC-C基准，你应该理解它不能直接与供应商提供的TPC-C基准结果相比较。 但是，它是免费的、快速的、易用的。 基准测试使用案例基准测试负载不能精确模拟你的应用程序的特点。 每个负载是唯一的，在不同的系统有不同的瓶颈。 对于很多使用案例，使用预定义的基准测试仍然是非常有效的,包括以下性能的比较：多个环境（例如：旧的物理服务器，新的虚拟环境）使用各种因素的不同及时点（例如：使用共享存储和共享主机资源的虚拟机的性能）在配置改变前后的点当然，对一个数据库服务器运行基准测试可以影响其他SQL Server数据库或者相同主机上其他虚拟机的性能，在生产环境你确保有完善的测试计划。 对于自学和研究来说，有预配置的负载非常棒。 开始使用基准测试你可以从阅读HammerDB官方文档的“SQL Server OLTP Load Testing Guide”开始。
preparedStatement和Statement 有什么不一样
在JDBC应用中,如果你已经是稍有水平开发者,你就应该始终以PreparedStatement代替Statement.也就是说,在任何时候都不要使用Statement 一.代码的可读性和可维护性. 虽然用PreparedStatement来代替Statement会使代码多出几行,但这样的代码无论从可读性还是可维护性上来说.都比直接用Statement的代码高很多档次: (INSERT into tb_name (col1,col2,col2,col4) values (+var1+,+var2+,+var3+,+var4+)); perstmt = (insert into tb_name (col1,col2,col2,col4) values (?,?,?,?)); (1,var1); (2,var2); (3,var3); (4,var4); (); 不用我多说,对于第一种方法.别说其他人去读你的代码,就是你自己过一段时间再去读,都会觉得伤心. 二尽最大可能提高性能. 每一种数据库都会尽最大努力对预编译语句提供最大的性能优化.因为预编译语句有可能被重复调用.所以语句在被DB的编译器编译后的执行代码被缓存下来,那么下次调用时只要是相同的预编译语句就不需要编译,只要将参数直接传入编译过的语句执行代码中(相当于一个涵数)就会得到执行.这并不是说只有一个Connection中多次执行的预编译语句被缓存,而是对于整个DB中,只要预编译的语句语法和缓存中匹配.那么在任何时候就可以不需要再次编译而可以直接执行.而statement的语句中,即使是相同一操作,而由于每次操作的数据不同所以使整个语句相匹配的机会极小,几乎不太可能匹配.比如: insert into tb_name (col1,col2) values (11,22); insert into tb_name (col1,col2) values (11,23); 即使是相同操作但因为数据内容不一样,所以整个个语句本身不能匹配,没有缓存语句的意义.事实是没有数据库会对普通语句编译后的执行代码缓存.这样每执行一次都要对传入的语句编译一次. 当然并不是所以预编译语句都一定会被缓存,数据库本身会用一种策略,比如使用频度等因素来决定什么时候不再缓存已有的预编译结果.以保存有更多的空间存储新的预编译语句. 三.最重要的一点是极大地提高了安全性. 即使到目前为止,仍有一些人连基本的恶义SQL语法都不知道. String sql = select * from tb_name where name= +varname+ and passwd=+varpasswd+; 如果我们把[ or 1 = 1]作为varpasswd传入进来.用户名随意,看看会成为什么? select * from tb_name = 随意 and passwd = or 1 = 1; 因为1=1肯定成立,所以可以任何通过验证.更有甚者: 把[;drop table tb_name;]作为varpasswd传入进来,则: select * from tb_name = 随意 and passwd = ;drop table tb_name;有些数据库是不会让你成功的,但也有很多数据库就可以使这些语句得到执行. 而如果你使用预编译语句.你传入的任何内容就不会和原来的语句发生任何匹配的关系.(前提是数据库本身支持预编译,但上前可能没有什么服务端数据库不支持编译了,只有少数的桌面数据库,就是直接文件访问的那些)只要全使用预编译语句,你就用不着对传入的数据做任何过虑.而如果使用普通的statement,有可能要对drop,;等做费尽心机的判断和过虑. 上面的几个原因,还不足让你在任何时候都使用PreparedStatement吗?
发表评论