标签 优化 下的文章

opcache参数配置优化详解

我们在日常的PHP开发过程中,应该经常会听见Opcache这个词,那么啥是Opcode呢?
Install-OPcache-in-CentOS-7.png
Opcache 的前生是 Optimizer+ ,它是PHP的官方公司 Zend 开发的一款闭源但可以免费使用的 PHP 优化加速组件。 Optimizer+ 将PHP代码预编译生成的脚本文件 Opcode 缓存在共享内存中供以后反复使用,从而避免了从磁盘读取代码再次编译的时间消耗。同时,它还应用了一些代码优化模式,使得代码执行更快。从而加速PHP的执行。

Optimizer+ 于 2013年3月中旬改名为 Opcache。并且在 PHP License 下开源: https://github.com/zendtech/ZendOptimizerPlus



---阅读剩余部分---

MySQL中使用Optimize优化表

OPTIMIZE TABLE 用于回收闲置的数据库空间,当表上的数据行被删除时,所占据的磁盘空间并没有立即被回收,使用了OPTIMIZE TABLE命令后这些空间将被回收,并且对磁盘上的数据行进行重排(注意:是磁盘上,而非数据库)。

多数时间并不需要运行OPTIMIZE TABLE,只需在批量删除数据行之后,或定期(每周一次或每月一次)进行一次数据表优化操作即可,只对那些特定的表运行,这个操作对于游戏数据库中的某些表特别起作用,这些表基本上需要每周做一次优化,甚至一周两次。

如果您已经删除了表的一大部分,或者如果您已经对含有可变长度行的表(含有VARCHAR, BLOB或TEXT列的表)进行了很多更改,则应使用OPTIMIZE TABLE。被删除的记录被保持在链接清单中,后续的INSERT操作会重新使用旧的记录位置。

OPTIMIZE TABLE只对MyISAM, BDB和InnoDB表起作用。

OPTIMIZE TABLE TABLENAME

对于MyISAM表,OPTIMIZE TABLE按如下方式操作:

  1. 如果表已经删除或分解了行,则修复表。
  2. 如果未对索引页进行分类,则进行分类。
  3. 如果表的统计数据没有更新(并且通过对索引进行分类不能实现修复),则进行更新。

对于BDB表,OPTIMIZE TABLE目前被映射到ANALYZE TABLE上。

对于InnoDB表,OPTIMIZE TABLE被映射到ALTER TABLE上,这会重建表、更新索引统计信息、回收主键索引中空间。

在OPTIMIZE TABLE运行过程中,MySQL会锁定表。
如果MySQL是有备库的,只希望在主库上执行的话,那么可以加上关键字NO_WRITE_TO_BINLOG(或者LOCAL,意思完全相同)。

Oracle 性能优化之高消耗的SQL

与用户执行 SQL 有关的动态视图有 v$sql、v$sqlarea、v$sqltext、v$sql_plan、 v$sqlstats 等。

v$sql 中包含了所有用户执行的所有 SQL 信息,不同用户、不同会 话执行相同 SQL 的语义、执行计划可能会不同,这些 SQL 字面值相同(具有相同 的 sql_id),通过不同的 child_number 来区分。
v$sqlarea 中仅包含 SQL 语句的字面 信息,忽略了相同 SQL 语句在执行会话、语义、执行计划上的不同,相同的 SQL 语句在 v$sqlara 中仅以一行显示。

---阅读剩余部分---

MySQL EXPLAIN详解

EXPLAIN显示了MySQL如何使用索引来处理SELECT语句以及连接表,可以帮助选择更好的索引和写出更优化的查询语句,一般主要用来SQL查询优化·
使用方法,在select语句前加上EXPLAIN就可以了,如下面的sql查询:

EXPLAIN 
SELECT 
  uc.ID AS userId,
  uc.USER_NAME AS userName,
  uc.USER_PWD AS PASSWORD,
  uc.BIRTHDAY AS birthday,
  uc.EMAIL AS email,
  uc.MOBILE AS mobile,
  uc.NICKNAME AS nickName,
  uc.CREATE_DATE AS createdDate,
  uc.UPDATE_DATE AS updatedDate,
  uc.IS_DEL AS isDel,
  uc.SEX AS sex,
  uc.LAST_LOGIN_DATE AS lastLoginDate,
  uc.USER_MALL AS projectId,
  level.UC_USER_LEVEL_ID AS ucUserLevelId,
  uclevel.LEVEL_NAME AS ucUserLevelName,
  level.RISE_RANK_DATE AS riseRankDate,
  growth.ID AS ucUserGrowthId,
  growth.GROWTH_VALUE AS growthValue,
  point.ID AS ucUserPointId,
  point.BONUSPOINT AS bonuspoint 
FROM
  UC_USER uc 
  LEFT JOIN UC_USER_PROPERTY_GROWTH growth 
    ON uc.ID = growth.USER_ID 
  LEFT JOIN UC_USER_PROPERTY_LEVEL level
    ON uc.ID = level.USER_ID 
  LEFT JOIN UC_USER_LEVEL uclevel 
    ON uclevel.ID = level.UC_USER_LEVEL_ID 
  LEFT JOIN UC_USER_PROPERTY_POINT point 
    ON uc.ID = point.USER_ID 
WHERE uc.IS_DEL = '0' 
ORDER BY uc.LAST_LOGIN_DATE DESC,
  uc.ID DESC 
LIMIT 0, 20;

返回结果如下

+----+-------------+---------+------------+--------+---------------+---------+---------+----------------------------------+------+----------+----------------------------------------------------+
| id | select_type | table   | partitions | type   | possible_keys | key     | key_len | ref                              | rows | filtered | Extra                                              |
+----+-------------+---------+------------+--------+---------------+---------+---------+----------------------------------+------+----------+----------------------------------------------------+
|  1 | SIMPLE      | uc      | NULL       | ALL    | NULL          | NULL    | NULL    | NULL                             | 4728 |    10.00 | Using where; Using temporary; Using filesort       |
|  1 | SIMPLE      | growth  | NULL       | ALL    | NULL          | NULL    | NULL    | NULL                             | 4308 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
|  1 | SIMPLE      | level   | NULL       | ALL    | NULL          | NULL    | NULL    | NULL                             | 4512 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
|  1 | SIMPLE      | uclevel | NULL       | eq_ref | PRIMARY       | PRIMARY | 8       | weixin_db.level.UC_USER_LEVEL_ID |    1 |   100.00 | NULL                                               |
|  1 | SIMPLE      | point   | NULL       | ALL    | NULL          | NULL    | NULL    | NULL                             | 3699 |   100.00 | Using where; Using join buffer (Block Nested Loop) |
+----+-------------+---------+------------+--------+---------------+---------+---------+----------------------------------+------+----------+----------------------------------------------------+
5 rows in set, 1 warning (0.00 sec)

id.png
EXPLAIN出来的信息有12列,分别是id、select_type、table、partitions、type、possible_keys、key、key_len、ref、rows、filtered、Extra,下面对这些字段出现的可能进行解释:



---阅读剩余部分---

最新

分类

归档

评论

  • Liang: 贴下编译参数和步骤,...
  • shao3911: 您好,为什么我在编译...
  • aliang: 先看是yum安装还是...
  • aliang: 将原来的nginx安...
  • yen: 3、如果要回滚的话,...
  • yen: 刚好需要升级ngin...
  • 文雨: 一些新的method...
  • aliang: 默认不屏蔽估计开发团...
  • 山野愚人居: PHP既然允许直接使...
  • aliang: 最下面有github地址·

其它