归档可用的缓冲大小和数量调整

调整归档时第一件需要确保的事是LGWR没有等待ARCn完成归档一个日志文件 第二个需要考虑的是ARCn活动时的影响对前台进程最小化 而这两个方面通常是刚好相对的 因此最好的目标就是调整ARCn使其足够快 并在可以证明其影响了前台进程时降低其速度 主要包括以下原则 另外还包括归档可用的缓冲大小和数量的调整 以及归档进程的数量

缓冲的大小

ARCn每次从日志文件读取 _log_archive_buffer_size（以块为单位） 并写入归档目的地 因此如果_log_archive_buffer_size设置为OS下最大的可能值 那么ARCn的性能将最大化并且其在I/O子系统上的负载将最小化 如果该参数在OS上为UNLIMITED 那么设置为最大的物理I/O大小的几倍 效果将最好

缓冲的数量

如果_log_archive_buffers可用并且可以从日志文件异步读取 那么ARCn将使用aio_read()系统调用并行读取日志到多个缓冲 如果多个日志成员可用 将使用并行异步读每个日志文件成员以扩展磁盘I/O负载 如果使用了软件/硬件镜像进行日志文件传播 类似的负载平衡将会自动由软件/硬件使用 因此 可以考虑使用并行归档读 使用与每个日志文件相同多的磁盘 镜像或者传播 然后配置_log_archive_buffers最多为

需要注意的是 不能通过设置多个_arch_io_slaves来模麓尤罩疚募稍辈⑿幸觳蕉痢RCn通常自己执行该任何并仅使用I/O服务器来写 *** 作

为了在可能时进行异步归档写 至少需要设置两个_log_archive_buffers 以并行从日志文件读取 但是如果系统达到了cpu负载颈瓶并且归档期间前台进程受到了影响 并且没有归档聚集的威胁 应该考虑减少缓冲数量 分散cpu负载

进程数量

如果产生的重做持续过高或者需要归档到多个位置 通常需要多个ARCn进程 从Oracle i开始 可以通过设置log_archive_max_processes参数 也可以通过定期调度ALTER SYSTEM ARCHIVE LOG ALL 如果没有归档聚集 该命令的影响是很小的 但是如果有 该命令会迅速产生额外的arcn帮助赶上聚集

为了防止LGWR赶上归档聚集运行多个ARCn是最大的保险 但是为了使该策略有效 恰当的配置在线日志和归档终点的磁盘是很重要的

因为也可以使用手工归档 Oracle在归档期间将在任何在线日志文件上保留一个排斥的WL（等待日志）队列锁 而忽略log_archive_max_processes的设置 这些队列上的 *** 作由archive control latch保护 归档活动可以从STATSPACK等报告中的该LARCHE上的gets列得到

影响归档进程性能的两个威胁

在RAC环境下 在实例没有启动时 其线程是可用的 如果一个关闭的 启用的线程的当前SCN落后于force scn 那么在那个线程上将发生强制的日志切换并且活动实例的ARCn为未活动的实例归档日志文件 这使得arcn进程转移到那个实例中工作而不是执行其自己的工作 然而如果ARCn被其自己的lgwr唤醒归档其自己实例的日志 那么ARCn将会刮起这个归档 这应该通过保持空闲实例启动或者禁用其重做线程完全避免

归档在前项滚动期间将被完全禁用 因此应该确保干净的关闭 保持重做产生最小化

通用的索引块头

header address = x c c

kdxcolev

KDXCOLEV Flags =

kdxcolok

kdxcoopc x : opcode= : iot flags= is converted=Y

kdxconco

kdxcosdc

kdxconro

kdxcofbo = x

kdxcofeo = x

kdxcoavs

kdxcolev 索引级别（ 代表页块）

kdxcolok 标示结构块事块是否发生

kdxcoopc 内部 *** 作码

kdxconco 索引列数量 包括ROWID

kdxcosdc 块中索引结构改变的数量

kdxconro 索引条目的数量 不包括kdxbrlmc指针

kdxcofbo 块中空闲空间的开始位置

kdxcofeo 块中空闲空间的结束位置

kdxcoavs 块中的可用空间数量（kdxcofbo kdxcofeo）

分支头区域

kdxbrlmc = x

kdxbrsno

kdxbrbksz

kdxbrlmc 如果索引值小于第一个值（row# ） 则为该索引值所在的块地址

kdxbrsno 最后更改的索引条目

kdxbrbksz 可使用的块空间

叶块头区域

kdxlespl

kdxlende

kdxlenxt = x b

kdxleprv = x d

kdxledsz

kdxlebksz

kdxlespl 块拆分时被清除的未提交数据的字节数

kdxlende 被删除的条目数

kdxlenxt 下一个页块的RBA

kdxleprv 上一个页块的RBA

kdxlebksz 可使用的块空间（默认小于分支的可用空间） 分支条目

row# [ ] dba: = x

col ; len ; ( ): c

col ; TERM

row# [ ] dba: = x

col ; len ; ( ): c

col ; TERM

行号 [块中的起始位置] dba

列号 列长度 列值

brach中的每个entry有 个columns:

一个是child blocks中的最大值 另一个是指向的下一层block的address

但是某些时候可能会有一些比较奇怪的结果

row# [ ] dba: = x c

col ; len ; ( ):

…

col ; len ; ( ):

end of branch block dump

叶条目

row# [ ] flag: S lock: len=

col ; len ; ( ): c

col ; len ; ( ): db a

row# [ ] flag: DS lock: len=

行号[在块中的开始位置] 各种标记（锁信息 删除信息）

索引列号 长度 值 其中 个字节的为ROWID号 将其转换为二进制 算法结果为

前 bit代表了file_id

中 bit代表了block_id

后 bit代表了row_id

通过文件号和块号算出的结果为创建该索引的表的块

奇怪的是 为什么索引中的rowid不能直接找到obj_id

因为索引段对应的数据段在 一开始就知道 因为是先知道数据段才找到索引段 然后

根据索引段内容去搜索数据段内容 所以索引段中 rowid 不必包含 data_object_id 信息

如果索引是建立在非分区表上 或者是分区表上的 LOCAL 索引 使用的是 bytes的 Restricted ROWID 如果索引是建立在分区表上的 GLOBAL index 则使用 bytes 的 Extended ROWID 这样可以区分索引指向哪个分区表

更新/重用索引条目

当更新了索引条目后 DUMP如下

kdxconco

kdxcosdc

kdxconro

kdxcofbo = x

kdxcofeo = x f

kdxcoavs

kdxlespl

kdxlende

kdxlenxt = x

kdxleprv = x

kdxledsz

kdxlebksz

row# [ ] flag: D lock: => deleted index entry

col ; len ; ( ): f

col ; len ; ( ): a

row# [ ] flag: lock:

col ; len ; ( ): a => new index entry

col ; len ; ( ): a

更新后 将包含一个删除的条目 一个新的条目 在随后的插入中 如果新插入的索引条目能够放到被删除的索引条目的位置上 就会直接重用这个条目 根据索引值来决定

所谓重用 是对row 的重用 而不是对row所在物理存储（或说物理位置）的重用 索引是按照indexed value对row进行排序的 有新的row 入 首先按照value排序 将他放在合适的row list中 如果他的位置正好原来有个row被删掉了 则重用这个row在row list中的位置 至于物理存储上 则可能根据版本不同会有不同 在 中 我做的测试并没有向下开辟空间

结论:

·到叶块中的任何插入都将移除所有被删除的条目

·删除的空间在随后的写中被清除

·删除的空间在延迟块清除中被清除

·全空块被放在空闲列表 可以重用

索引统计

·dba_indexes

·dbms_stats

·index_stats

yze index index_name validate structure;

分析资源 锁

·v$segment_statistics

statistics_level = typical (or all)

注意事项

blevel (dba_indexes) vs height (index_stats)

blocks allocated 但未必使用

lf_rows_len包含行负载（单列索引 个字节）

pct_used索引结构中当前使用的空间 (used_space/btree_space)

绝大多数索引统计包含删除的条目

non deleted rows = lf_rows – del_lf_rows

lishixinzhi/Article/program/Oracle/201311/16904

ORACLE数据库的PL/SQL语句执行的优化器 有基于代价的优化器（CBO）和基于规则的优化器（RBO）

RBO的优化方式 依赖于一套严格的语法规则 只要按照规则写出的语句 不管数据表和索引的内容是否发生变化 不会影响PL/SQL语句的 执行计划

CBO自ORACLE 版被引入 ORACLE自 版以来采用的许多新技术都是只基于CBO的 如星型连接排列查询 哈希连接查询 反向索引 索引表 分区表和并行查询等 CBO计算各种可能 执行计划 的 代价 即cost 从中选用cost最低的方案 作为实际运行方案 各 执行计划 的cost的计算根据 依赖于数据表中数据的统计分布 ORACLE数据库本身对该统计分布是不清楚的 须要分析表和相关的索引 才能搜集到CBO所需的数据

CBO是ORACLE推荐使用的优化方式 要想使用好CBO 使SQL语句发挥最大效能 必须保证统计数据的及时性

统计信息的生成可以有完全计算法和抽样估算法

SQL例句如下

完全计算法 yze table abc pute statistics;

抽样估算法（抽样 %） yze table abc estimate statistics sample percent;

对表作完全计算所花的时间相当于做全表扫描 抽样估算法由于采用抽样 比完全计算法的生成统计速度要快 如果不是要求要有精确数据的话 尽量采用抽样分析法 建议对表分析采用抽样估算 对索引分析可以采用完全计算

我们可以采用以下两种方法 对数据库的表和索引及簇表定期分析生成统计信息 保证应用的正常性能

在系统设置定时任务 执行分析脚本

在数据库服务器端 我们以UNIX用户oracle 运行脚本 yze 在 yze中 我们生成待执行sql脚本 并运行 （假设我们要分析scott用户下的所有表和索引）

Analyze脚本内容如下

sqlplus scott/tiger 《 EOF

set pagesize

set heading off

SPOOL ANALYTAB SQL

SELECT ANALYZE TABLE SCOTT ||TABLE_NAME|| ESTIMATE STATISTICS SAMPLE PERCENT ; FROM USER_TABLES;

SPOOL OFF

SPOOL ANALYIND SQL

SELECT ANALYZE TABLE SCOTT ||TABLE_NAME|| ESTIMATE STATISTICS SAMPLE PERCENT FOR ALL INDEXES; FROM USER_TABLES;

SPOOL OFF

SPOOL ANALYZE LOG

@ANALYTAB SQL

@ANALYIND SQL

SPOOL OFF

EXIT

在UNIX平台上crontab加入 以上文件 设置为每个月或合适的时间段运行

利用ORACLE提供的程序包（PACKAGE）对相关的数据库对象进行分析

有以下的程序包可以对表 索引 簇表进行分析

包中的存储过程的相关参数解释如下

TYPE可以是 TABLE INDEX CLUSTER中其一

SCHEMA为 TABLE INDEX CLUSTER的所有者 NULL为当前用户

NAME为 相关对象的名称

METHOD是 ESTIMATE PUTE DELETE中其一 当选用ESTIMATE

下面两项 ESTIMATE_ROWS和ESTIMATE_PERCENT不能同时为空值

ESTIMATE_ROWS是 估算的抽样行数

ESTIMATE_PERCENT是 估算的抽样百分比

METHOD_OPT是 有以下选项

FOR TABLE /只统计表/

[FOR ALL [INDEXED] COLUMNS] [SIZE N] /只统计有索引的表列/

FOR ALL INDEXES /只分析统计相关索引/

PARTNAME是 指定要分析的分区名称

）

DBMS_DDL ANALYZE_OBJECT（

TYPE VARCHAR

SCHEMA VARCHAR

NAME VARCHAR

METHOD VARCHAR

ESTIMATE_ROWS NUMBER DEFAULT NULL

ESTIMATE_PERCENT NUMBER DEFAULT NULL

METHOD_OPT VARCHAR DEFAULT NULL

PARTNAME VARCHAR DEFAULT NULL ） ;

该存储过程可对特定的表 索引和簇表进行分析

lishixinzhi/Article/program/PB/201311/24615

几个简单的步骤大幅提高Oracle性能 我优化数据库的三板斧

数据库优化的讨论可以说是一个永恒的主题 资深的Oracle优化人员通常会要求提出性能问题的人对数据库做一个statspack 贴出数据库配置等等 还有的人认为要抓出执行最慢的语句来进行优化 但实际情况是 提出疑问的人很可能根本不懂执行计划 更不要说statspack了 而我认为 数据库优化 应该首先从大的方面考虑 网络 服务器硬件配置 *** 作系统配置 Oracle服务器配置 数据结构组织 然后才是具体的调整 实际上网络 硬件等往往无法决定更换 应用程序一般也无法修改 因此应该着重从数据库配置 数据结构上来下手 首先让数据库有一个良好的配置 然后再考虑具体优化某些过慢的语句 我在给我的用户系统进行优化的过程中 总结了一些基本的 简单易行的办法来优化数据库 算是我的三板斧 呵呵 不过请注意 这些不一定普遍使用 甚至有的会有副作用 但是对OLTP系统 基于成本的数据库往往行之有效 不妨试试 （注 附件是Burleson写的用来报告数据库性能等信息的脚本 本文用到）

一．设置合适的SGA

常常有人抱怨服务器硬件很好 但是Oracle就是很慢 很可能是内存分配不合理造成的 ( )假设内存有 M 这通常是小型应用 建议Oracle的SGA大约 M 其中 共享池（SHARED_POOL_SIZE）可以设置 M到 M 根据实际的用户数 查询等来定 数据块缓冲区可以大致分配 M M i下需要设置DB_BLOCK_BUFFERS DB_BLOCK_BUFFERDB_BLOCK_SIZE等于数据块缓冲区大小 i 下的数据缓冲区可以用db_cache_size来直接分配

( )假设内存有 G Oracle 的SGA可以考虑分配 M 共享池分配 M到 M 数据缓冲区分配 M到 M

( )内存 G SGA可以考虑分配 G 共享池 M到 M 剩下的给数据块缓冲区

( )内存 G以上 共享池 M到 M就足够啦 再多也没有太大帮助 (Biti_rainy有专述)数据缓冲区是尽可能的大 但是一定要注意两个问题 一是要给 *** 作系统和其他应用留够内存 二是对于 位的 *** 作系统 Oracle的SGA有 G的限制 有的 位 *** 作系统上可以突破这个限制 方法还请看Biti的大作吧

二．分析表和索引 更改优化模式

Oracle默认优化模式是CHOOSE 在这种情况下 如果表没有经过分析 经常导致查询使用全表扫描 而不使用索引 这通常导致磁盘I/O太多 而导致查询很慢 如果没有使用执行计划稳定性 则应该把表和索引都分析一下 这样可能直接会使查询速度大幅提升 分析表命令可以用ANALYZE TABLE 分析索引可以用ANALYZE INDEX命令 对于少于 万的表 可以考虑分析整个表 对于很大的表 可以按百分比来分析 但是百分比不能过低 否则生成的统计信息可能不准确 可以通过DBA_TABLES的LAST_ANALYZED列来查看表是否经过分析或分析时间 索引可以通过DBA_INDEXES的LAST_ANALYZED列

下面通过例子来说明分析前后的速度对比 （表CASE_GA_AJZLZ大约有 万数据 有主键）首先在SQLPLUS中打开自动查询执行计划功能 (第一次要执行\RDBMS\ADMIN\utlxplan sql来创建PLAN_TABLE这个表)

SQL> SET AUTOTRACE ON SQL>SET TIMING ON

通过SET AUTOTRACE ON 来查看语句的执行计划 通过SET TIMING ON 来查看语句运行时间

SQL> select count() from CASE_GA_AJZLZ; COUNT() 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=CHOOSE SORT (AGGREGATE) TABLE ACCESS (FULL) OF CASE_GA_AJZLZ ……………………

请注意上面分析中的TABLE ACCESS(FULL) 这说明该语句执行了全表扫描 而且查询使用了 秒 这时表还没有经过分析 下面我们来对该表进行分析

SQL> yze table CASE_GA_AJZLZ pute statistics;

表已分析 已用时间: : : 然后再来查询

SQL> select count() from CASE_GA_AJZLZ; COUNT() 已用时间: : : Execution Plan SELECT STATEMENT Optimizer=FIRST_ROWS (Cost= Card= ) SORT (AGGREGATE) INDEX (FAST FULL SCAN) OF PK_AJZLZ (UNIQUE) (Cost= Card= ) …………………………

请注意 这次时间仅仅用了 秒！这要归功于INDEX(FAST FULL SCAN) 通过分析表 查询使用了PK_AJZLZ索引 磁盘I/O大幅减少 速度也大幅提升！下面的实用语句可以

用来生成分析某个用户的所有表和索引 假设用户是GAXZUSR

SQL> set pagesize SQL> spool d:\ yze_tables sql; SQL> select yze table ||owner|| ||table_name|| pute statistics; from dba_tables where owner= GAXZUSR ; SQL> spool off SQL> spool spool d:\ yze_indexes sql; SQL> select yze index ||owner|| ||index_name|| pute statistics; from dba_indexes where owner= GAXZUSR ; SQL> spool off SQL> @d:\ yze_tables sql SQL> @d:\ yze_indexes sql

解释 上面的语句生成了两个sql文件 分别分析全部的GAXZUSR的表和索引 如果需要按照百分比来分析表 可以修改一下脚本 通过上面的步骤 我们就完成了对表和索引的分析 可以测试一下速度的改进啦 建议定期运行上面的语句 尤其是数据经过大量更新

当然 也可以通过dbms_stats来分析表和索引 更方便一些 但是我仍然习惯上面的方法 因为成功与否会直接提示出来

另外 我们可以将优化模式进行修改 optimizer_mode值可以是RULE CHOOSE FIRST_ROWS和ALL_ROWS 对于OLTP系统 可以改成FIRST_ROWS 来要求查询尽快返回结果 这样即使不用分析 在一般情况下也可以提高查询性能 但是表和索引经过分析后有助于找到最合适的执行计划

三．设置cursor_sharing=FORCE 或SIMILAR

这种方法是 i才开始有的 oracle 不支持 通过设置该参数 可以强制共享只有文字不同的语句解释计划 例如下面两条语句可以共享

SQL> SELECT FROM MYTABLE WHERE NAME= tom SQL> SELECT FROM MYTABLE WHERE NAME= turner

这个方法可以大幅降低缓冲区利用率低的问题 避免语句重新解释 通过这个功能 可以很大程度上解决硬解析带来的性能下降的问题 个人感觉可根据系统的实际情况 决定是否将该参数改成FORCE 该参数默认是exact 不过一定要注意 修改之前 必须先给ORACLE打补丁 否则改之后oracle会占用 %的CPU 无法使用 对于ORACLE i 可以设置成SIMILAR 这个设置综合了FORCE和EXACT的优点 不过请慎用这个功能 这个参数也可能带来很大的负面影响！

四．将常用的小表 索引钉在数据缓存KEEP池中

内存上数据读取速度远远比硬盘中读取要快 据称 内存中数据读的速度是硬盘的 倍！如果资源比较丰富 把常用的小的 而且经常进行全表扫描的表给钉内存中 当然是在好不过了 可以简单的通过ALTER TABLE tablename CACHE来实现 在ORACLE i之后可以使用ALTER TABLE table STORAGE(BUFFER_POOL KEEP) 一般来说 可以考虑把 数据块之内的表放在keep池中 当然要根据内存大小等因素来定 关于如何查出那些表或索引符合条件 可以使用本文提供的access sql和access_report sql 这两个脚本是著名的Oracle专家 Burleson写的 你也可以在读懂了情况下根据实际情况调整一下脚本 对于索引 可以通过ALTER INDEX indexname STORAGE(BUFFER_POOL KEEP)来钉在KEEP池中

将表定在KEEP池中需要做一些准备工作 对于ORACLE i 需要设置DB_KEEP_CACHE_SIZE 对于 i 需要设置buffer_pool_keep 在 i中 还要修改db_block_lru_latches 该参数默认是 无法使用buffer_pool_keep 该参数应该比 CPU数量少 但是要大于 才能设置DB_KEEP_CACHE_BUFFER buffer_pool_keep从db_block_buffers中分配 因此也要小于db_block_buffers 设置好这些参数后 就可以把常用对象永久钉在内存里

五．设置optimizer_max_permutations

对于多表连接查询 如果采用基于成本优化(CBO) ORACLE会计算出很多种运行方案

从中选择出最优方案 这个参数就是设置oracle究竟从多少种方案来选择最优 如果设置太大 那么计算最优方案过程也是时间比较长的 Oracle 和 i默认是 建议改成 对于 i 已经默认是 了

六．调整排序参数

( ) SORT_AREA_SIZE:默认的用来排序的SORT_AREA_SIZE大小是 K 通常显得有点小 一般可以考虑设置成 M（ ） 这个参数不能设置过大 因为每个连接都要分配同样的排序内存

lishixinzhi/Article/program/Oracle/201311/18879

▲ SHOW 执行下面这个命令可以了解服务器的运行状态 mysql >show status;该命令将显示出一长列状态变量及其对应的值 其中包括 被中止访问的用户数量 被中止的连接数量 尝试连接的次数 并发连接数量最大值 以及其他许多有用的信息 这些信息对于确定系统问题和效率低下的原因是十分有用的 SHOW命令除了能够显示出MySQL服务器整体状态信息之外 它还能够显示出有关日志文件 指定数据库 表 索引 进程和许可权限表的宝贵信息 请访问了解更多信息 ▲ EXPLAIN EXPLAIN能够分析SELECT命令的处理过程 这不仅对于决定是否要为表加上索引很有用 而且对于了解MySQL处理复杂连接的过程也很有用 下面这个例子显示了如何用EXPLAIN提供的信息逐步地优化连接查询 （本例来自MySQL文档 见 原文写到这里似乎有点潦草了事 特加上此例 ）假定用EXPLAIN分析的SELECT命令如下所示 EXPLAIN SELECT tt TicketNumber tt TimeIn tt ProjectReference tt EstimatedShipDate tt ActualShipDate tt ClientID tt ServiceCodes tt RepetitiveID tt CurrentProcess tt CurrentDPPerson tt RecordVolume tt DPPrinted et COUNTRY et_ COUNTRY do CUSTNAMEFROM tt et et AS et_ doWHERE tt SubmitTime IS NULLAND tt ActualPC = et EMPLOYIDAND tt AssignedPC = et_ EMPLOYIDAND tt ClientID = do CUSTNMBR;SELECT命令中出现的表定义如下 ※表定义表 列 列类型tt ActualPC CHAR( )tt AssignedPC CHAR( )tt ClientID CHAR( )et EMPLOYID CHAR( )do CUSTNMBR CHAR( )※索引表 索引tt ActualPCtt AssignedPCtt ClientIDet EMPLOYID (主键)do CUSTNMBR (主键)※tt ActualPC值分布不均匀在进行任何优化之前 EXPLAIN对SELECT执行分析的结果如下 table type possible_keyskey key_len ref rows Extraet　ALL PRIMARY　 NULL NULL　NULL do　ALL PRIMARY　 NULL NULL　NULL et_ ALL PRIMARY　 NULL NULL　NULL tt　ALL AssignedPC ClientID ActualPC NULL NULL　NULL range checked for each record (key map: )每一个表的type都是ALL 它表明MySQL为每一个表进行了完全连接！这个 *** 作是相当耗时的 因为待处理行的数量达到每一个表行数的乘积！即 这里的总处理行数为 = 这里的问题之一在于 如果数据库列的声明不同 MySQL（还）不能有效地运用列的索引 在这个问题上 VARCHAR和CHAR是一样的 除非它们声明的长度不同 由于tt ActualPC声明为CHAR( ) 而et EMPLOYID声明为CHAR( ) 因此这里存在列长度不匹配问题 为了解决这两个列的长度不匹配问题 用ALTER TABLE命令把ActualPC列从 个字符扩展到 字符 如下所示 mysql > ALTER TABLE tt MODIFY ActualPC VARCHAR( );现在tt ActualPC和et EMPLOYID都是VARCHAR( )了 执行EXPLAIN进行分析得到的结果如下所示 table type　possible_keys　key　 key_len ref rows　Extratt　ALL　AssignedPC ClientID ActualPC NULL NULL NULLwhere useddo　ALL　PRIMARY NULL　NULL　NULL range checked for each record (key map: )et_ ALL　PRIMARY NULL　NULL　NULL range checked for each record (key map: )et　eq_ref PRIMARY PRIMARY tt ActualPC 这还算不上完美 但已经好多了（行数的乘积现在少了一个系数 ） 现在这个SQL命令执行大概需要数秒钟时间 为了避免tt AssignedPC = et_ EMPLOYID以及tt ClientID = do CUSTNMBR比较中的列长度不匹配 我们可以进行如下改动 mysql > ALTER TABLE tt MODIFY AssignedPC VARCHAR( ) MODIFY ClientID　VARCHAR( );现在EXPLAIN显示的结果如下 table type　possible_keys　key　 key_len ref　rows　 Extraet　ALL　PRIMARY NULL　NULL　NULL　 tt　ref　AssignedPC ClientID ActualPC ActualPC et EMPLOYID where usedet_ eq_ref PRIMARY PRIMARY tt AssignedPC do　eq_ref PRIMARY PRIMARY tt ClientID　 这个结果已经比较令人满意了 余下的问题在于 默认情况下 MySQL假定tt ActualPC列的值均匀分布 而事实上tt表的情况并非如此 幸而 我们可以很容易地让MySQL知道这一点 shell > myisamc yze PATH_TO_MYSQL_DATABASE/ttshell > mysqladmin refresh现在这个连接 *** 作已经非常理想 EXPLAIN分析的结果如下 table type　possible_keys　key　 key_len ref　rows　Extratt　ALL　AssignedPC ClientID ActualPC NULL NULL NULL　where usedet　eq_ref PRIMARY PRIMARY tt ActualPC　 et_ eq_ref PRIMARY PRIMARY tt AssignedPC do　eq_ref PRIMARY PRIMARY tt ClientID　 ▲ OPTIMIZE OPTIMIZE能够恢复和整理磁盘空间以及数据碎片 一旦对包含变长行的表进行了大量的更新或者删除 进行这个 *** 作就非常有必要了 OPTIMIZE当前只能用于MyISAM和BDB表 结束语 从编译数据库服务器开始 贯穿整个管理过程 能够改善MySQL性能的因素实在非常多 本文只涉及了其中很小的一部分 lishixinzhi/Article/program/MySQL/201311/29480

在windows服务器开启php的gd库时 使用cgi之后phpinfo()得到的结果中 Configure Command 中并没有出现gd

Configure Command 后显示的是

代码如下:

cscript /nologo configure js " enable snapshot build" " disable isapi" " enable debug pack" " without mssql" " without pdo mssql" " without pi web" " with pdo oci=C:php sdkoracleinstantclient sdk shared" " with oci =C:php sdkoracleinstantclient sdk shared" " with oci g=C:php sdkoracleinstantclient sdk shared" " enable object out dir= /obj/" " enable dotnet=shared" " with mcrypt=static" " disable static yze" " with pgo"

lishixinzhi/Article/program/PHP/201311/21168

---