Dammit! 为什么有这么多的事情值得吐槽？
Centos上Apache重启，mysql重启, nginx 重启方法
1.重启 apache
service httpd restrat
/etc/init.d/httpd stop
/etc/init.d/httpd start
2.重启 mysql
service mysql restart
/etc/init.d/mysqld stop
/etc/init.d/mysqld start
3.重启Nginx
service nginx restart
/etc/init.d/nginx stop
/etc/init.d/nginx start
WordPress提供了一些功能函数可以轻松地显示数据库查询的统计信息，这些信息可以公开地显示在网页中，或者隐藏在源代码中，更或者只有你自己可以看到。
WordPress主要提供了两个统计函数：
1.网页加载时查询数据库的次数:
|
1 |
<?php echo get_num_queries(); ?> |
2.服务器端完成这些查询所花费的时间:
|
1 |
<?php timer_stop(7); ?> |
可以使用3种方式在网页中显示:
如果你觉的你的服务器或空间的处理速度好，或者想让你的访问者看到这些查询统计信息的话，你可以将这些统计信息公开显示在页面中：（效果查看博客的页面底部）
|
1 |
<p>< ?php echo get_num_queries(); ?> queries in < ?php timer_stop(3); ?> seconds</p> |
如果你不想将统计信息显示在页面上供访问者查看，但又想自己可以知道这些统计信息，那么你可以通过html的注释将结果只显示在源代码中（PS：大家也可以从源代码中查看的哦！）：
|
1 |
<!-- <?php echo get_num_queries(); ?> queries in < ?php timer_stop(3); ?> seconds --> |
该方法是第二种显示的优化方法，只需博客管理员登录后就可以查看查询统计信息，访问者是无法查看的：
|
1 2 3 |
< ?php if (current_user_can('level_10')) { echo '<!-- ' . get_num_queries() . ' queries in ' . timer_stop(3) . ' seconds -->'; } ?> |
如果想查看具体查询了数据库哪些内容，可以用如下解决方法：
1、首先在 wp-config.php 里添加如下代码：
|
1 |
define('SAVEQUERIES',true); |
然后在 footer.php 里添加如下代码：
|
1 2 3 4 5 6 |
<?php if(is_user_logged_in()){ global $wpdb; echo "<pre>"; print_r($wpdb->queries); echo "</pre>"; }?> |
分析：
1、if (is_user_logged_in()) 用于判断当前访客是否已登录，也可以用 if (current_user_can('level_10')) 来判断是否为管理员登录，目的是为了不让游客查看到这些数据，此代码可省；
2、global $wpdb; 定义全局变量$wpdb，这是Wordpress默认的数据库类；
3、<pre></pre>将结果嵌套在HTML标签<pre>内；
4、print_r($wpdb->queries); 输出各次数据库查询的信息。
刷新首页或日志页，可看到类似如下的输出结果：
|
1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 |
Array ( [0]=>Array ( [0]=> SELECT SQL_CALC_FOUND_ROWS wp_posts.* FROM wp_posts WHERE 1=1 AND wp_posts.post_type ='post' AND (wp_posts.post_status ='publish' OR wp_posts.post_status ='private') ORDER BY wp_posts.post_date DESC LIMIT 0,10 [1]=>0.0003960132598877 [2]=>require, wp, WP->main, WP->query_posts, WP_Query->query, WP_Query->get_posts ) [1]=>Array ( [0]=> SELECT option_value FROM wp_options WHERE option_name ='nuodou_header_code' LIMIT 1 [1]=>0.0013589859008789 [2]=>require, require_once, include, get_header, locate_template, load_template, require_once, get_option ) |
下面的活儿就得自己分析了，看看哪些是可以删除，哪些是可以改进的，以减少数据库查询次数。
MyISAM 和 InnoDB 讲解
InnoDB和MyISAM是许多人在使用MySQL时最常用的两个表类型，这两个表类型各有优劣，视具体应用而定。基本的差别为：MyISAM类型不支持事务处理等高级处理，而InnoDB类型支持。MyISAM类型的表强调的是性能，其执行数度比InnoDB类型更快，但是不提供事务支持，而InnoDB提供事务支持已经外部键等高级数据库功能。
以下是一些细节和具体实现的差别：
◆1.InnoDB不支持FULLTEXT类型的索引。
◆2.InnoDB 中不保存表的具体行数，也就是说，执行select count(*) from table时，InnoDB要扫描一遍整个表来计算有多少行，但是MyISAM只要简单的读出保存好的行数即可。注意的是，当count(*)语句包含 where条件时，两种表的操作是一样的。
◆3.对于AUTO_INCREMENT类型的字段，InnoDB中必须包含只有该字段的索引，但是在MyISAM表中，可以和其他字段一起建立联合索引。
◆4.DELETE FROM table时，InnoDB不会重新建立表，而是一行一行的删除。
◆5.LOAD TABLE FROM MASTER操作对InnoDB是不起作用的，解决方法是首先把InnoDB表改成MyISAM表，导入数据后再改成InnoDB表，但是对于使用的额外的InnoDB特性(例如外键)的表不适用。
另外，InnoDB表的行锁也不是绝对的，假如在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表，例如update table set num=1 where name like “%aaa%”
两种类型最主要的差别就是Innodb 支持事务处理与外键和行级锁.而MyISAM不支持.所以MyISAM往往就容易被人认为只适合在小项目中使用。
我作为使用MySQL的用户角度出发，Innodb和MyISAM都是比较喜欢的，但是从我目前运维的数据库平台要达到需求：99.9%的稳定性，方便的扩展性和高可用性来说的话，MyISAM绝对是我的首选。
原因如下：
1、首先我目前平台上承载的大部分项目是读多写少的项目，而MyISAM的读性能是比Innodb强不少的。
2、MyISAM的索引和数据是分开的，并且索引是有压缩的，内存使用率就对应提高了不少。能加载更多索引，而Innodb是索引和数据是紧密捆绑的，没有使用压缩从而会造成Innodb比MyISAM体积庞大不小。
3、从平台角度来说，经常隔1，2个月就会发生应用开发人员不小心update一个表where写的范围不对，导致这个表没法正常用了，这个时候MyISAM的优越性就体现出来了，随便从当天拷贝的压缩包取出对应表的文件，随便放到一个数据库目录下，然后dump成sql再导回到主库，并把对应的binlog补上。如果是Innodb，恐怕不可能有这么快速度，别和我说让Innodb定期用导出xxx.sql机制备份，因为我平台上最小的一个数据库实例的数据量基本都是几十G大小。
4、从我接触的应用逻辑来说，select count(*) 和order by 是最频繁的，大概能占了整个sql总语句的60%以上的操作，而这种操作Innodb其实也是会锁表的，很多人以为Innodb是行级锁，那个只是where对它主键是有效，非主键的都会锁全表的。
5、还有就是经常有很多应用部门需要我给他们定期某些表的数据，MyISAM的话很方便，只要发给他们对应那表的frm.MYD,MYI的文件，让他们自己在对应版本的数据库启动就行，而Innodb就需要导出xxx.sql了，因为光给别人文件，受字典数据文件的影响，对方是无法使用的。
6、如果和MyISAM比insert写操作的话，Innodb还达不到MyISAM的写性能，如果是针对基于索引的update操作，虽然MyISAM可能会逊色Innodb,但是那么高并发的写，从库能否追的上也是一个问题，还不如通过多实例分库分表架构来解决。
7、如果是用MyISAM的话，merge引擎可以大大加快应用部门的开发速度，他们只要对这个merge表做一些select count(*)操作，非常适合大项目总量约几亿的rows某一类型(如日志，调查统计)的业务表。
当然Innodb也不是绝对不用，用事务的项目如模拟炒股项目，我就是用Innodb的，活跃用户20多万时候，也是很轻松应付了，因此我个人也是很喜欢Innodb的，只是如果从数据库平台应用出发，我还是会首选MyISAM。
另外，可能有人会说你MyISAM无法抗太多写操作，但是我可以通过架构来弥补，说个我现有用的数据库平台容量：主从数据总量在几百T以上，每天十多亿 pv的动态页面，还有几个大项目是通过数据接口方式调用未算进pv总数，(其中包括一个大项目因为初期memcached没部署,导致单台数据库每天处理 9千万的查询)。而我的整体数据库服务器平均负载都在0.5-1左右。
近期评论