CSDN官方APP
创新互联是一家专业提供科尔沁企业网站建设,专注与成都网站建设、成都网站设计、H5场景定制、小程序制作等业务。10年已为科尔沁众多企业、政府机构等服务。创新互联专业网络公司优惠进行中。
中国专业的IT社区立即下载
CSDN首页
博客
学院
下载
GitChat
论坛
APP
问答
商城
VIP
活动
招聘
ITeye
TinyMind
专题
Copyright © 1999-2019,
CSDN.NET, All Rights Reserved
crimeheaven的专栏
登录
crimeheaven关注 访问量 6万+ 原创 22 博主更多文章
转 mysql跨库操作速度慢的解决方案
crimeheaven阅读数：24752014-03-14
远程连接mysql速度慢的解决方法:skip-name-resolve取消DNS的反向解析
PHP远程连接MYSQL速度慢,有时远程连接到MYSQL用时4-20秒不等,本地连接MYSQL正常,出现这种问题的主要原因是,默认安装的MYSQL开启了DNS的反向解析,在MY.INI(WINDOWS系统下)或MY.CNF(UNIX或LINUX系统下)文件的[mysqld]下加入skip-name-resolve这一句。
但是，这样会引起一个问题：连接mysql时，不能使用 localhost连接了，而是要使用IP地址的；如果是按localhost对用户赋权限的话，用户登录权限也要修改一下的。
连接mysql速度慢的解决方法.
2台服务器，一台跑iis+php，一台跑mysql，和以往一样配置好环境，测试页面一切OK
跑应用的时候发现php访问mysql速度很慢，这种情况在以前从未发现过，虽然2台服务器并非在同一网段中，但是ping数值基本上都在1,2ms之间，tcp连接应该不是问题关健，google以后找到答案，在my.ini文件的[mysqld]部分加入:skip-name-resolve，保存文件，重启mysql，一切OK啦，速度象飞一样了
新版本的mysql配置起来不象以前的那个傻瓜化了，这个问题折腾了我一上午的时间，晚上回来总算是解决了，嘿嘿，又学到一些东西。
Windows 2003下的MySQL 5服务器，本机连接到MySQL服务非常快，局域网内有两台Linux机器，有一台连接很快，另外一台输入密码后要等好几秒钟才能连上。
方法一:net start mysql(或者是其他服务名)
方法二:在系统下启动MySQL服务
MySql安装目录：“d:\MySql\”
进入命令行输入窗口（Dos命令输入）
进入“d:\MySql\bin”目录下运行“mysqld -u root” 命令。写法：
d:\MySql\bin\mysqld -u root (Enter)
运行后在进程管理中有mysql的进程，运行成功（可能需要手动关闭命令窗口）
1、wordpress 被黑，WordPress无法正常加载页面？
第一种：自己在后台修改了wordpress网址，导致不能登陆后台。
解决办法：
1、首先我们登录MySQL数据库，这个不用我教吧；
2、查看表”wp_options”的数据（你的表不一定是以”wp”开始的）；
3、修改”option_name “为”siteurl”和”home”的两条记录（一般在第一页和第二页），将内容改为之前能够正常使用的地址；
4、保存数据后，就可以重新登录网站和后台了。
第二种：wordpress 主题丢失以及后台无法进入。
症状：
后台进不去。当在浏览器栏里面输入后台文件的位置的时候会出现404页面错误。主题丢失。博客首页的所有的样式全部失效，页面就剩下一个纯文字的页面。在浏览器里面输入无论是还是 都得到是相同的错误：缺少wp-login.php文件。
原因：
在后台设置了一下，拿seo笔记做个例子，也就是把那个后面的那个blog给去掉了，就导致了上面的问题。
解决办法：
确认目录里面是有wp-login.PHP这个文件的，应该不是缺少文件引起的，既然文件是存在的，但报错的时候却说是不存在，那么只有一个原因，wp-admin这个页面的文件不知道到哪里去找wp-login.php这个文件，另外主题的消失也应该是因为不知道到什么地方去找相应的主题而引起的。
因为在后台错误的设置引起了现在的状况，只要将那个改回来应该就没事了，但是现在后台是进不去，只能从数据库中想办法。查找了相关的信息以后发现wordpress是将路径信息存放在wp_options这张表里面的。下面就说一下具体解决方案：
通过Cpanel面板进入phpmyadmin页面。选择你写的博客的数据库。选择wp_options这张表，转换到Browse（浏览）模式。将siteurl的值改回 。至此，wordpress知道如何去寻找相应的主题和页面了，问题解决。
说直白了做这个事情的目的就是让能够自动的转向到 ，这个可以用301转向来做，具体方法网上有很多，有兴趣的可以搜搜看看。
第三种：wordpress上传服务器后只能打开首页链接，其他链接都不行，后台可以打开。
先把固定连接改成默认，删除根目录下的.htaccess 文件；再把固定连接改回来，这时候就会自动生成一个.htaccess 文件。
第四种：前台可以显示，后台不能登陆显示空白。
解决办法：
一般这种情况主要是wordpress插件的问题，首先使用你的FTP工具连接到你的空间，然后进入到wordpress的FTP安装目录，将wp-content目录下的plugins文件夹改名，也就是说将“plugins”改成了“plugin”，这样前台调用插件的那些模块便会出现”Database Results Error”。这个时候你的wordpress后台便已经可以登陆了。登陆的地址是：http://你的博客地址/wp-login.php，比如：,登陆以后你便可以在管理后台的插件的栏目，看到所有的插件都已停用，这个时候你便可以将“plugin”文件夹名字改回到原来的名称“plugins”，之后可以逐一调试找到出问题的插件。
第五种：升级wordpress导致后台不能登陆。
直接去ftp上，把wp-content下的object-cache.php改个名字或者删除，再进后台，OK。
因为这个“非插件”的object-cache能大大减少查询，对提速还是有很大作用，相信看过相关文章的站长都用过。但其实wp3.0已经把这个归类于内部插件了，可能会导致一些未知问题。我觉得有时候缓存尤其是数据库的缓存会影响升级，安装插件的莫名问题。当做这些操作出现奇怪问题时，先去检查一下这个。
PS：这个object-cache很好用的，改名进去后台后。或是成功启用插件后，再改回来测试，没有问题了，估计是缓存更新了。
第六种：修改代码导致网站错误，前台只显示首页，后台空白不能登陆。
直接用备份的文件直接覆盖所有文件！在themes文件夹下多出了一个idream.bk的文件，进入idream.bk文件夹发现里面全是原来的文件，但是idream里面却多了一些别的文件，将idream文件随便令命名，然后将idream.bk文件改为idream，刷新网页后发现后台可以登陆了，但是主题却没有出现，首页还是一片纯文字页面，进入后台“外观”-“主题”-启用idream主题后台，后台又出现了空白，前台没有变化。直接将原来的idream文件删除，只留下重命名为idream的idream.bk文件夹，刷新网页正常显示了。
对照看看是否能帮到你。

2、如何限制WordPress后台管理员密码错误登陆次数？
这个要根据服务器不同的生产环境来采用不同的应对办法的，一般需要现在 WordPress 后台登陆的场景都是因为被恶意扫描登陆的情况下的。造成被这样恶意登陆的主要原因就是暴露了服务器真实IP，应对方法可以总结如下几个：
通过WEB服务器限制wp-login.php文件的访问
WEB服务器限制同一时间的并发访问数量和限定速度上限
服务器端加上带有WAF防御的 CDN 服务器（推荐360网站卫士和百度云加速）
服务器防火墙拦截屏蔽这类非法的恶意请求
当然，最土豪的办法其实就是在做以上这些措施的时候，变更一下服务器的真实IP地址，因为暴露了真实IP地址以后，这类恶意请求都是有针对性的，拦截和屏蔽效果会差了很多，同时也容易引来CC/DDOS攻击。
一个十年草根博客站长【明月登楼的博客】（imydl.com）熟悉 WordPress 、 Typecho 博客平台创建、运营网站，多年VPS服务器运维经历，实践经验丰富，在这里为您解答专业方面的所有疑问！
3、zblog和wordpress的区别？
1.开发团队
用一个程序，了解开发团队是很有必要的。不然被人卖了还不知道是谁干的，那就十分尴尬了。Zblog属于国产团队开发制作，具体介绍可以参见Zblog官方网站的介绍。而Wordpress是全球风靡的Blog程序，前一阵WP官网发布了中文版，查看具体情况参见Wordpress官方中文站。
2.程序语言
这点其实不想谈太多，不过出于长远目光来看，还是有必要声明下。Zblog是asp程序，Wordpress是Php程序。国内流行asp大部分是因为盗版的猖獗与版权意识淡薄，而今后中国的版权发展状况如何也会影响到asp程序的应用推广。而国外几乎清一色的php程序，很大的原由是Php的开源免费。
3.空间支持
基本上国内符合asp程序的空间很多，但在国外比较少。而要想更好的操作Wordpress最好选用国外的空间，因为比较好的支持程序静态化。国内的空间商虽然支持php没有问题，但静态化支持方面不是很理想。同时国外空间更廉价，基本都是限制每月流量，国内的空间商贵限制IIS、CPU占用等。而当你的博客访问量增大，国内的空间就会让你感到懊恼了。
4.操作性
相比而言，Zblog功能操作方面更符合国人习惯，比如有文章置顶、模板的自动安装、文章编辑等。Wordpress在2.7版本后对后台界面也进行了改善，不过整体的操作性而言，还是有待继续改善，毕竟是非国人的创作。Zblog转移备份之类十分简单，就如一个绿色软件；而Wordpress转移与备份还要涉及数据库，相对繁琐一点。
5.插件模板
插件模板方面其实Wordpress比Zblog要丰富得多，利用各种插件可以实现很多功能，同时由于Wordpress的流行度使得模板数量比Zblog也要多得多。而相比而言，Zblog的插件与模板在数量上与Wordpress还是有差距。Wordpress可以后台预览模板再使用，而Zblog模板只能套在官方的程序上预览，不够贴切。不过在插件上，虽然Zblog的数量较少，但插件功能方面比较贴近国人的需求。同时随着Zblog的用户增加，模板与插件的数量在不断的增加。
6.SEO与推广
在SEO方面，其实Wordpress与Zblog各具特色。不过个人感觉Wordpree在Google方面还是比Zblog有优势，Zblog相比Wordpress的SEO优势其实并不是很多人说的程序先天性，而是更便捷的Diy，而最终效果如何要看自己的SEO水平与项目决定。在推广方面，Wordpress可以跟踪谷歌博客搜索的外部链接，这是十分吸引人的地方。
7.用户反馈
用户反馈其实还包括防SPAM，恶意留言现在已经成为Blogger的一个苦恼。Wordpress与Zblog都有反SPAM与恶意留言的插件，而Wordpress更容易屏蔽边缘性的留言。而Zblog实行的是链接转向，所以要更人性点。相比反馈方面，正如上面提到的Wordpress可以跟踪谷歌博客搜索的外部链接，所以可以与其他blogger进行很好的反馈跟踪。
目前而言，如果追求操作便捷性与国人习惯，更推荐Zblog。如果想更好的DIY与持久blogger，更推荐Wordpress。至于自己的技术如何其实并不重要，程序用得久了自然会。
4、如何优化一个臃肿的WordPress让其照样能飞起来？
第一，WordPress 并不臃肿，反而很精简！
第二，臃肿是因为主题和插件而导致的。
第三，飞起来需要优化这些主题和插件：
换成更简洁的主题（通常付费主题会更好）
将不需要的插件删掉
安装缓存插件 wp-rocket、wp-super-cache 等等
更多详细 WordPress优化技巧
我这个网站就是 WordPress 做的，是不是飞快
更多关于 WordPress 话题，前往：王会的博客
5、wordpress的安装页面怎么都打不开？
更正一下是nginx，做站是一个折腾的过程，一定要细心，有时候一点小细节不注意就会把人搞死，一点小建议哈。
报404是找不到页面，建议你把所有的W P文件全部删除，并且数据库清空在拷贝安装一次，如果还不行，建议你把vps重置，重新安装LNMP，安装好后先打开你的vps服务器ip地址或域名看能不能打开页面，如果能则检查安装包是不是损坏或缺失文件，建议从官网重新下载。
如果依然报错，建议换成LAMP进行尝试，wp官方是推荐apache的，另外nginx在配置.htaccess重定向文件时也比较方便，nginx就需要转码后才可
单机MySQL数据库的优化
一、服务器硬件对MySQL性能的影响
①磁盘寻道能力 （磁盘I/O），我们现在上的都是SAS15000转的硬盘。MySQL每秒钟都在进行大量、复杂的查询操作，对磁盘的读写量可想而知。所以，通常认为磁 盘I/O是制约MySQL性能的最大因素之一，对于日均访 问量在100万PV以上的Discuz!论坛，由于磁盘I/O的制约，MySQL的性能会非常低下！解决这一制约因素可以考虑以下几种解决方案： 使用RAID1+0磁盘阵列，注意不要尝试使用RAID-5，MySQL在RAID-5磁盘阵列上的效率不会像你期待的那样快。
②CPU 对于MySQL应用，推荐使用DELL R710，E5620 @2.40GHz（4 core）* 2 ，我现在比较喜欢DELL R710，也在用其作Linuxakg 虚拟化应用；
③物理内存对于一台使用MySQL的Database Server来说，服务器内存建议不要小于2GB，推荐使用4GB以上的物理内存，不过内存对于现在的服务器而言可以说是一个可以忽略的问题，工作中遇到高端服务器基本上内存都超过了32G。
我们工作中用得比较多的数据库服务器是HP DL580G5和DELL R710，稳定性和性能都不错；特别是DELL R710，我发现许多同行都是采用它作数据库的服务器，所以重点推荐下。
二、MySQL的线上安装我建议采取编译安装的方法，这样性能上有较大提升，服务器系统我建议用64bit的Centos5.5，源码包的编译参数会默 认以Debgu模式生成二进制代码，而Debug模式给MySQL带来的性能损失是比较大的，所以当我们编译准备安装的产品代码时，一定不要忘记使用“— without-debug”参数禁用Debug模式。而如果把—with-mysqld-ldflags和—with-client-ldflags二 个编译参数设置为—all-static的话，可以告诉编译器以静态方式编译和编译结果代码得到最高的性能。使用静态编译和使用动态编译的代码相比，性能 差距可能会达到5%至10%之多。我参考了简朝阳先生的编译参数，特列如下，供大家参考
./configure –prefix=/usr/local/mysql –without-debug –without-bench –enable-thread-safe-client –enable-assembler –enable-profiling –with-mysqld-ldflags=-all-static –with-client-ldflags=-all-static –with-charset=latin1 –with-extra-charset=utf8,gbk –with-innodb –with-csv-storage-engine –with-federated-storage-engine –with-mysqld-user=mysql –without-我是怎么了ded-server –with-server-suffix=-community –with-unix-socket-path=/usr/local/mysql/sock/mysql.sock
三、MySQL自身因素当解决了上述服务器硬件制约因素后，让我们看看MySQL自身的优化是如何操作的。对 MySQL自身的优化主要是对其配置文件my.cnf中的各项参数进行优化调整。下面介绍一些对性能影响较大的参数。
下面，根据以上硬件配置结合一份已经优化好的my.cnf进行说明：
#vim /etc/my.cnf
以下只列出my.cnf文件中[mysqld]段落中的内容，其他段落内容对MySQL运行性能影响甚微，因而姑且忽略。
[mysqld]
port = 3306
serverid = 1
socket = /tmp/mysql.sock
skip-locking
#避免MySQL的外部锁定，减少出错几率增强稳定性。
skip-name-resolve
#禁止MySQL对外部连接进行DNS解析，使用这一选项可以消除MySQL进行DNS解析的时间。但需要注意，如果开启该选项，则所有远程主机连接授权都要使用IP地址方式，否则MySQL将无法正常处理连接请求！
back_log = 384
#back_log参数的值指出在MySQL暂时停止响应新请求之前的短时间内多少个请求可以被存在堆栈中。 如果系统在一个短时间内有很多连接，则需要增大该参数的值，该参数值指定到来的TCP/IP连接的侦听队列的大小。不同的操作系统在这个队列大小上有它自 己的限制。 试图设定back_log高于你的操作系统的限制将是无效的。默认值为50。对于Linux系统推荐设置为小于512的整数。
key_buffer_size = 384M
#key_buffer_size指定用于索引的缓冲区大小，增加它可得到更好的索引处理性能。对于内存在4GB左右的服务器该参数可设置为256M或384M。注意：该参数值设置的过大反而会是服务器整体效率降低！
max_allowed_packet = 4M
thread_stack = 256K
table_cache = 614K
sort_buffer_size = 6M
#查询排序时所能使用的缓冲区大小。注意：该参数对应的分配内存是每连接独占，如果有100个连接，那么实际分配的总共排序缓冲区大小为100 × 6 ＝ 600MB。所以，对于内存在4GB左右的服务器推荐设置为6-8M。
read_buffer_size = 4M
#读查询操作所能使用的缓冲区大小。和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
join_buffer_size = 8M
#联合查询操作所能使用的缓冲区大小，和sort_buffer_size一样，该参数对应的分配内存也是每连接独享。
myisam_sort_buffer_size = 64M
table_cache = 512
thread_cache_size = 64
query_cache_size = 64M
#指定MySQL查询缓冲区的大小。可以通过在MySQL控制台观察，如果Qcache_lowmem_prunes的值非常大，则表明经常出现缓冲不 够 的情况；如果Qcache_hits的值非常大，则表明查询缓冲使用非常频繁，如果该值较小反而会影响效率，那么可以考虑不用查询缓 冲；Qcache_free_blocks，如果该值非常大，则表明缓冲区中碎片很多。
tmp_table_size = 256M
max_connections = 768
#指定MySQL允许的最大连接进程数。如果在访问论坛时经常出现Too Many Connections的错误提 示，则需要增大该参数值。
max_connect_errors = 1000
wait_timeout = 10
#指定一个请求的最大连接时间，对于4GB左右内存的服务器可以设置为5-10。
thread_concurrency = 8
#该参数取值为服务器逻辑CPU数量*2，在本例中，服务器有2颗物理CPU，而每颗物理CPU又支持H.T超线程，所以实际取值为4*2=8；这个目前也是双四核主流服务器配置。
skip-networking
#开启该选项可以彻底关闭MySQL的TCP/IP连接方式，如果WEB服务器是以远程连接的方式访问MySQL数据库服务器则不要开启该选项！否则将无法正常连接！
table_cache=1024
#物理内存越大，设置就越大。默认为2402,调到512-1024最佳
innodb_additional_mem_pool_size=4M
#默认为2M
innodb_flush_log_at_trx_commit=1
#设置为0就是等到innodb_log_buffer_size列队满后再统一储存，默认为1
innodb_log_buffer_size=2M
#默认为1M
innodb_thread_concurrency=8
#你的服务器CPU有几个就设置为几，建议用默认一般为8
key_buffer_size=256M
#默认为218，调到128最佳
tmp_table_size=64M
#默认为16M，调到64-256最挂
read_buffer_size=4M
#默认为64K
read_rnd_buffer_size=16M
#默认为256K
sort_buffer_size=32M
#默认为256K
thread_cache_size=120
#默认为60
query_cache_size=32M
※值得注意的是：
很多情况需要具体情况具体分析
一、如果Key_reads太大，则应该把my.cnf中Key_buffer_size变大，保持Key_reads/Key_read_requests至少1/100以上，越小越好。
二、如果Qcache_lowmem_prunes很大，就要增加Query_cache_size的值。
很多时候我们发现，通过参数设置进行性能优化所带来的性能提升，可能并不如许多人想象的那样产生质的飞跃，除非是之前的设置存在严重不合理的情况。我们 不能将性能调优完全依托于通过DBA在数据库上线后进行的参数调整，而应该在系统设计和开发阶段就尽可能减少性能问题。
【51CTO独家特稿】如果单MySQL的优化始终还是顶不住压力时，这个时候我们就必须考虑MySQL的高可用架构（很多同学也爱说成是MySQL集群）了，目前可行的方案有：
一、MySQL Cluster
优势：可用性非常高，性能非常好。每份数据至少可在不同主机存一份拷贝，且冗余数据拷贝实时同步。但它的维护非常复杂，存在部分Bug，目前还不适合比较核心的线上系统，所以这个我不推荐。
二、DRBD磁盘网络镜像方案
优势：软件功能强大，数据可在底层快设备级别跨物理主机镜像，且可根据性能和可靠性要求配置不同级别的同步。IO操作保持顺序，可满足数据库对数据一致 性的苛刻要求。但非分布式文件系统环境无法支持镜像数据同时可见，性能和可靠性两者相互矛盾，无法适用于性能和可靠性要求都比较苛刻的环境，维护成本高于 MySQL Replication。另外，DRBD也是官方推荐的可用于MySQL高可用方案之一，所以这个大家可根据实际环境来考虑是否部署。
三、MySQL Replication
在实际应用场景中，MySQL Replication是使用最为广泛的一种提高系统扩展性的设计手段。众多的MySQL使用者通过Replication功能提升系统的扩展性后，通过 简单的增加价格低廉的硬件设备成倍 甚至成数量级地提高了原有系统的性能，是广大MySQL中低端使用者非常喜欢的功能之一，也是许多MySQL使用者选择MySQL最为重要的原因。
比较常规的MySQL Replication架构也有好几种，这里分别简单说明下
MySQL Replication架构一：常规复制架构--Master-slaves，是由一个Master复制到一个或多个Salve的架构模式，主要用于读压力大的应用数据库端廉价扩展解决方案，读写分离，Master主要负责写方面的压力。
MySQL Replication架构二：级联复制架构，即Master-Slaves-Slaves,这个也是为了防止Slaves的读压力过大，而配置一层二级 Slaves，很容易解决Master端因为附属slave太多而成为瓶劲的风险。
MySQL Replication架构三：Dual Master与级联复制结合架构，即Master-Master-Slaves，最大的好处是既可以避免主Master的写操作受到Slave集群的复制带来的影响，而且保证了主Master的单点故障。
以上就是比较常见的MySQL replication架构方案，大家可根据自己公司的具体环境来设计 ，Mysql 负载均衡可考虑用LVS或Haproxy来做，高可用HA软件我推荐Heartbeat。
MySQL Replication的不足：如果Master主机硬件故障无法恢复，则可能造成部分未传送到slave端的数据丢失。所以大家应该根据自己目前的网络 规划，选择自己合理的Mysql架构方案，跟自己的MySQL DBA和程序员多沟涌，多备份（备份我至少会做到本地和异地双备份），多测试，数据的事是最大的事，出不得半点差错，切记切记。
