当前位置:文档之家› 第7章:优化

第7章:优化

第7章:优化

目录

7.1. 优化概述

7.1.1. MySQL设计局限与折衷

7.1.2. 为可移植性设计应用程序

7.1.3. 我们已将MySQL用在何处?

7.1.4. MySQL基准套件

7.1.5. 使用自己的基准

7.2. 优化SELECT语句和其它查询

7.2.1. EXPLAIN语法(获取SELECT相关信息)

7.2.2. 估计查询性能

7.2.3. SELECT查询的速度

7.2.4. MySQL怎样优化WHERE子句

7.2.5. 范围优化

7.2.6. 索引合并优化

7.2.7. MySQL如何优化IS NULL

7.2.8. MySQL如何优化DISTINCT

7.2.9. MySQL如何优化LEFT JOIN和RIGHT JOIN

7.2.10. MySQL如何优化嵌套Join

7.2.11. MySQL如何简化外部联合

7.2.12. MySQL如何优化ORDER BY

7.2.13. MySQL如何优化GROUP BY

7.2.14. MySQL如何优化LIMIT

7.2.15. 如何避免表扫描

7.2.16. INSERT语句的速度

7.2.17. UPDATE语句的速度

7.2.18. DELETE语句的速度

7.2.19. 其它优化技巧

7.3. 锁定事宜

7.3.1. 锁定方法

7.3.2. 表锁定事宜

7.4. 优化数据库结构

7.4.1. 设计选择

7.4.2. 使你的数据尽可能小

7.4.3. 列索引

7.4.4. 多列索引

7.4.5. MySQL如何使用索引

7.4.6. MyISAM键高速缓冲

7.4.7. MyISAM索引统计集合

7.4.8. MySQL如何计算打开的表

7.4.9. MySQL如何打开和关闭表

7.4.10. 在同一个数据库中创建多个表的缺陷

7.5. 优化MySQL服务器

7.5.1. 系统因素和启动参数的调节

7.5.2. 调节服务器参数

7.5.3. 控制查询优化器的性能

7.5.4. 编译和链接怎样影响MySQL的速度

7.5.5. MySQL如何使用内存

7.5.6. MySQL如何使用DNS

7.6. 磁盘事宜

7.6.1. 使用符号链接

优化是一个复杂的任务,因为最终要求了解整个待优化的系统。尽管可以进行局部优化而不需要了解系统或应用程序,为了优化得更好,你必须知道更多的信息。本章解释并给出不同的优化MySQL的方法示例。但要记住总有一些其它方法使系统更快,尽管需要更多的工作。

7.1. 优化概述

7.1.1. MySQL设计局限与折衷

7.1.2. 为可移植性设计应用程序

7.1.3. 我们已将MySQL用在何处?

7.1.4. MySQL基准套件

7.1.5. 使用自己的基准

使一个系统更快的最重要因素当然是基本设计。此外,还需要知道系统正做什么样的事情,以及瓶颈是什么。

最常见的系统瓶颈是:

?磁盘搜索。需要花时间从磁盘上找到一个数据,用在现代磁盘的平均时间通常小于10ms,因此理论上我们能够每秒大约搜索1000次。这个时间在新磁盘上提高不大并且很难为一个表进行优化。优化它的方法是将数据分布在多个磁盘上。

?磁盘读/写。当磁盘放入正确位置后,我们需要从中读取数据。对于现代的磁盘,一个磁盘至少传输10-20Mb/s的吞吐。这比搜索要容易优化,因为你能从多个磁盘并行地读。

?CPU周期。我们将数据读入内存后,需要对它进行处理以获得我们需要的结果。表相对于内存较小是最常见的限制因素。但是对于小表,速度通常不成问题。

·内存带宽。当CPU需要的数据超出CPU缓存时,主缓存带宽就成为内存的一个瓶颈。这在大多数系统正是一个不常见的瓶颈但是你应该知道它。

7.1.1. MySQL设计局限与折衷

当使用MyISAM存储引擎时,MySQL使用极快速的表锁定,以便允许多次读或一次写。使用该存储引擎的最大问题出现在同一个表中进行混合稳定数据流更新与慢速选择。如果这只是某些表的问题,你可以使用另一个存储引擎。参见第15章:存储引擎和表类型。

MySQL可以使用事务表和非事务表。为了更容易地让非事务表顺利工作(如果出现问题不能回滚),MySQL采用下述规则。请注意这些规则只适用于不运行在严格模式下或为INSERT或UPDATE使用IGNORE规定程序时。

·所有列有默认值。请注意当运行在严格SQL模式(包括TRADITIONAL SQL模式)时,必须为NOT NULL列指定默认值。

·如果向列内插入不合适的或超出范围的值,MySQL将该列设定为“最好的可能的值”,而不是报告错误。对于数字值,为0、可能的最小值或最大值。对于字符串,为空字符串或列内可以保存的字符串。请注意当运行在严格模式或TRADITIONAL SQL模式时该行为不适用。

·所有表达式的计算结果返回一个表示错误状况的信号。例如,1/0返回NULL。(使用ERROR_FOR_DIVISION_BY_ZERO SQL模式可以更改该行为)。如果正使用非事务表,不应该使用MySQL来检查列的内容。一般情况,最安全的(通常是最快的)方法径是让应用程序确保只向数据库传递合法值。

相关详细信息参见1.8.6节,“MySQL处理约束的方式”和13.2.4节,“INSERT 语法”或5.3.2节,“SQL服务器模式”。

7.1.2. 为可移植性设计应用程序

因为不同SQL服务器实现了标准SQL的不同部分,需要花功夫来编写可移植的SQL应用程序。对很简单的选择/插入,很容易实现移植,但是需要的功能越多则越困难。如果想要应用程序对很多数据库系统都快,它变得更难!

为了使一个复杂应用程序可移植,你需要选择它应该工作的SQL服务器,并确定这些服务器支持什么特性。

所有数据库都有一些弱点。这就是它们不同的设计折衷导致的不同行为。

可以使用MySQL的crash-me程序来找出能用于数据库服务器选择的函数、类型和限制。crash-me并不能找出所有的特性,但是其广度仍然很合理,可以进行大约450个测试。

crash-me可以提供的一种类型的信息的例子:如果想要使用Informix或DB2,不应该使用超过18个字符的列名。

crash-me程序和MySQL基准程序是独立于数据库的。通过观察它们是如何编写的,编可以知道必须为编写独立于数据库的应用程序做什么。基准本身可在

MySQL源码分发的“sql-bench”目录下找到。它们用DBI数据库接口以Perl写成。

使用DBI本身即可以解决部分移植性问题,因为它提供与数据库无关的的存取方法。

关于crash-me结果,访问

https://www.doczj.com/doc/795490721.html,/tech-resources/crash-me.php。到

https://www.doczj.com/doc/795490721.html,/tech-resources/benchmarks/看这个基准的结果。

如果你为数据库的独立性而努力,需要很好地了解每个SQL服务器的瓶颈。例如,MySQL在检索和更新MyISAM表记录方面很快,但是在同一个表上混合慢速读者和写者方面有一个问题。另一方面,当你试图访问最近更新了(直到它们被刷新到磁盘上)的行时,在Oracle中有一个很大的问题。事务数据库总的来说在从记录文件表中生成总结表方面不是很好,因为在这种情况下,行锁定几乎没有用。为了使应用程序“确实”独立于数据库,需要定义一个容易扩展的接口,用它可操纵数据。因为C++在大多数系统上可以适用,使用数据库的一个C++ 类接口是有意义的。

如果你使用某个数据库特定的功能(例如MySQL专用的REPLACE语句),应该为SQL服务器编码一个方法以实现同样的功能。尽管慢些,但确允许其它服务器执行同样的任务。

用MySQL,可以使用/*! */语法把MySQL特定的关键词加到查询中。在/**/中的代码将被其它大多数SQL服务器视为注释(并被忽略)。

如果高性能真的比准确性更重要,就像在一些web应用程序那样,一种可行的方法是创建一个应用层,缓存所有的结果以便得到更高的性能。通过只是让旧的结果在短时间后‘过期’,能保持缓存合理地刷新。这在极高负载的情况下是相当不错的,在此情况下,能动态地增加缓存并且设定较高的过期时限直到一切恢复正常。

在这种情况下,表创建信息应该包含缓存初始大小和表刷新频率等信息。

实施应用程序缓存的一种方法是使用MySQL查询缓存。启用查询缓存后,服务器可以确定是否可以重新使用查询结果。这样简化了你的应用程序。参见5.13节,“MySQL查询高速缓冲”。

7.1.3. 我们已将MySQL用在何处?

该节描述了Mysql的早期应用程序。

在MySQL最初开发期间,MySQL的功能适合大多数客户。MySQL为瑞典的一些最大的零售商处理数据仓库。

我们从所有商店得到所有红利卡交易的每周总结,并且我们期望为所有店主提供有用的信息以帮助他们得出他们的广告战如何影响他们的顾客。

数据是相当巨量的(大约每月7百万宗交易总结)并且我们保存4-10年来的数据需要呈现给用户。我们每周从顾客那里得到请求,他们想要“立刻”访问来自该数据的新报告。

我们通过每月将所有信息存储在压缩的“交易”表中来解决它。我们有一套简单的宏/脚本用来生成来自交易表的不同条件( 产品组、顾客id,商店...)的总结表。报告是由一个进行语法分析网页的小perl脚本动态生成的网页,在脚本中执行SQL语句并且插入结果。我们很想使用PHP或mod_perl,但是那时它们还不可用。

对图形数据,我们用C语言编写了一个简单的工具,它能基于那些结果处理SQL 查询结果并生成GIF图形。该工具也从分析Web网页的perl脚本中动态地执行。在大多数情况下,一个新的报告通过简单地复制一个现有脚本并且修改其中的SQL查询来完成。在一些情况下,我们将需要把更多的列加到一个现有的总结表

中或产生一个新的,但是这也相当简单,因为我们在磁盘上保存所有交易表。(目前我们大约有50G的交易表和200G的其它顾客数据)。

我们也让我们的顾客直接用ODBC访问总结表以便高级用户能自己用这些数据进行试验。

该系统工作得很好,我们可以毫无问题地用很适度的Sun Ultra SPARC工作站硬件(2x200MHz)来处理数据。该系统被逐步移植到了Linux中。

7.1.4. MySQL基准套件

本节应该包含MySQL基准套件(和crash-me)的技术描述,但是该描述还没写成。目前,你可以通过在MySQL源码分发中的“sql-bench”目录下的代码和结果了解基

准套件是如何工作的。

通过基准用户可以了解一个给定的SQL实现在哪方面执行得很好或很糟糕。

注意,这个基准是单线程的,它可以测量操作执行的最小时间。我们计划将来在基准套件中添加多线程测试。

要使用基准套件,必须满足下面的要求:

·基准套件随MySQL源码分发提供。可以从

https://www.doczj.com/doc/795490721.html,/downloads/下载分发,或者使用当前的开发源码

树(参见2.8.3节,“从开发源码树安装”)。

·基准脚本用Perl编写而成,使用Perl DBI模块访问数据库服务器,因此必须安装DBI。还需要为每个待测试的服务器提供服务器专用DBD 驱动程序。例如,要测试MySQL、PostgreSQL和DB2,必须安装DBD::mysql、DBD::Pg和DBD::DB2模块。参见2.13节,“Perl安装注意事项”。

获得MySQL源码分发后,可以在sql-bench目录找到基准套件。要运行基准测试,应构建MySQL,然后进入sql-bench目录并执行run-all-tests脚本:

shell> cd sql-bench

shell> perl run-all-tests --server=server_name

server_name是一个支持的服务器。要获得所有选项和支持的服务器,调用命令:shell> perl run-all-tests --help

crash-me脚本也位于sql-bench目录。crash-me尝试通过实际运行查询确定数据库支持的特性以及其功能和限制。例如,它确定:

·支持什么列类型

·支持多少索引

·支持什么函数

·查询可以多大

·VARCHAR列可以多大

可以从https://www.doczj.com/doc/795490721.html,/tech-resources/crash-me.php发现许多不同数据库服务器的crash-me的结果。关于基准测试结果的详细信息,访问

https://www.doczj.com/doc/795490721.html,/tech-resources/benchmarks/。

7.1.5. 使用自己的基准

一定要测试应用程序和数据库,以发现瓶颈在哪儿。通过修正它(或通过用一个“哑模块”代替瓶颈),可以很容易地确定下一个瓶颈。即使你的应用程序的整体性能目前可以接受,至少应该对每个瓶颈做一个计划,如果某天确实需要更好的性能,应知道如何解决它。

关于一些可移植的基准程序的例子,参见MySQL基准套件。请参见7.1.4节,“M ySQL基准套件”。可以利用这个套件的任何程序并且根据你的需要修改它。通过这样做,可以尝试不同的问题的解决方案并测试哪一个是最好的解决方案。另一个免费基准套件是开放源码数据库基准套件,参见

https://www.doczj.com/doc/795490721.html,/。

在系统负载繁重时出现一些问题是很普遍的,并且很多客户已经与我们联系了,他们在生产系统中有一个(测试)系统并且有负载问题。大多数情况下,性能问题经证明是与基本数据库设计有关的问题(例如,表扫描在高负载时表现不好)或操作系统或库问题。如果系统已经不在生产系统中,它们大多数将很容易修正。为了避免这样的问题,应该把工作重点放在在可能最坏的负载下测试你的整个应用程序。你可以使用Super Smack。该工具可以从

https://www.doczj.com/doc/795490721.html,/mysql/super-smack/获得。正如它的名字所建议,它可以根据你的需要提供合理的系统,因此确保只用于你的开发系统。

7.2. 优化SELECT语句和其它查询

7.2.1. EXPLAIN语法(获取SELECT相关信息)

7.2.2. 估计查询性能

7.2.3. SELECT查询的速度

7.2.4. MySQL怎样优化WHERE子句

7.2.5. 范围优化

7.2.6. 索引合并优化

7.2.7. MySQL如何优化IS NULL

7.2.8. MySQL如何优化DISTINCT

7.2.9. MySQL如何优化LEFT JOIN和RIGHT JOIN

7.2.10. MySQL如何优化嵌套Join

7.2.11. MySQL如何简化外部联合

7.2.12. MySQL如何优化ORDER BY

7.2.13. MySQL如何优化GROUP BY

7.2.14. MySQL如何优化LIMIT

7.2.15. 如何避免表扫描

7.2.16. INSERT语句的速度

7.2.17. UPDATE语句的速度

7.2.18. DELETE语句的速度

7.2.19. 其它优化技巧

首先,影响所有语句的一个因素是:你的许可设置得越复杂,所需要的开销越多。

执行GRANT语句时使用简单的许可,当客户执行语句时,可以使MySQL降低许可检查开销。例如,如果未授予任何表级或列级权限,服务器不需要检查

tables_priv和columns_priv表的内容。同样地,如果不对任何账户进行限制,服务器不需要对资源进行统计。如果查询量很高,可以花一些时间使用简化的授权结构来降低许可检查开销。

如果你的问题是与具体MySQL表达式或函数有关,可以使用mysql客户程序所带的BENCHMARK()函数执行定时测试。其语法为

BENCHMARK(loop_count,expression)。例如:

mysql> SELECT BENCHMARK(1000000,1+1);

+------------------------+

| BENCHMARK(1000000,1+1) |

+------------------------+

| 0 |

+------------------------+

1 row in set (0.3

2 sec)

上面结果在PentiumII 400MHz系统上获得。它显示MySQL在该系统上在0.32

秒内可以执行1,000,000个简单的+表达式运算。

所有MySQL函数应该被高度优化,但是总有可能有一些例外。BENCHMARK()是一个找出是否查询有问题的优秀的工具。

7.2.1. EXPLAIN语法(获取SELECT相关信息)

EXPLAIN tbl_name

或:

EXPLAIN [EXTENDED] SELECT select_options

EXPLAIN语句可以用作DESCRIBE的一个同义词,或获得关于MySQL如何执行SELECT 语句的信息:

·EXPLAIN tbl_name是DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。

·如果在SELECT语句前放上关键词EXPLAIN,MySQL将解释它如何处理SELECT,提供有关表如何联接和联接的次序。

该节解释EXPLAIN的第2个用法。

借助于EXPLAIN,可以知道什么时候必须为表加入索引以得到一个使用索引来寻找记录的更快的SELECT。

如果由于使用不正确的索引出现了问题,应运行ANALYZE TABLE更新表的统计(例如关键字集的势),这样会影响优化器进行的选择。参见13.5.2.1节,“ANALYZE TABLE语法”。

还可以知道优化器是否以一个最佳次序联接表。为了强制优化器让一个SELECT 语句按照表命名顺序的联接次序,语句应以STRAIGHT_JOIN而不只是SELECT开头。

EXPLAIN为用于SELECT语句中的每个表返回一行信息。表以它们在处理查询过程中将被MySQL读入的顺序被列出。MySQL用一遍扫描多次联接(single-sweep multi-join)的方式解决所有联接。这意味着MySQL从第一个表中读一行,然后

找到在第二个表中的一个匹配行,然后在第3个表中等等。当所有的表处理完后,它输出选中的列并且返回表清单直到找到一个有更多的匹配行的表。从该表读入下一行并继续处理下一个表。

当使用EXTENDED关键字时,EXPLAIN产生附加信息,可以用SHOW WARNINGS浏览。该信息显示优化器限定SELECT语句中的表和列名,重写并且执行优化规则后SELECT 语句是什么样子,并且还可能包括优化过程的其它注解。

EXPLAIN的每个输出行提供一个表的相关信息,并且每个行包括下面的列:

·id

SELECT识别符。这是SELECT的查询序列号。

·select_type

SELECT类型,可以为以下任何一种:

o SIMPLE

简单SELECT(不使用UNION或子查询)

o PRIMARY

最外面的SELECT

o UNION

UNION中的第二个或后面的SELECT语句

o DEPENDENT UNION

UNION中的第二个或后面的SELECT语句,取决于外面的查询o UNION RESULT

UNION的结果。

o SUBQUERY

子查询中的第一个SELECT

o DEPENDENT SUBQUERY

子查询中的第一个SELECT,取决于外面的查询

o DERIVED

导出表的SELECT(FROM子句的子查询)

·table

输出的行所引用的表。

·type

联接类型。下面给出各种联接类型,按照从最佳类型到最坏类型进行排序:o system

表仅有一行(=系统表)。这是const联接类型的一个特例。

o const

表最多有一个匹配行,它将在查询开始时被读取。因为仅有一行,

在这行的列值可被优化器剩余部分认为是常数。const表很快,因

为它们只读取一次!

const用于用常数值比较PRIMARY KEY或UNIQUE索引的所有部分时。

在下面的查询中,tbl_name可以用于const表:

SELECT * from tbl_name WHERE primary_key=1;

SELECT * from tbl_name

WHERE primary_key_part1=1和primary_key_part2=2;

o eq_ref

对于每个来自于前面的表的行组合,从该表中读取一行。这可能是最好的联接类型,除了const类型。它用在一个索引的所有部分被联接使用并且索引是UNIQUE或PRIMARY KEY。

eq_ref可以用于使用=操作符比较的带索引的列。比较值可以为常量或一个使用在该表前面所读取的表的列的表达式。

在下面的例子中,MySQL可以使用eq_ref联接来处理ref_tables:SELECT * FROM ref_table,other_table

WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table

WHERE ref_table.key_column_part1=other_table.column

AND ref_table.key_column_part2=1;

o ref

对于每个来自于前面的表的行组合,所有有匹配索引值的行将从这张表中读取。如果联接只使用键的最左边的前缀,或如果键不是UNIQUE或PRIMARY KEY(换句话说,如果联接不能基于关键字选择单个行的话),则使用ref。如果使用的键仅仅匹配少量行,该联接类型是不错的。

ref可以用于使用=或<=>操作符的带索引的列。

在下面的例子中,MySQL可以使用ref联接来处理ref_tables:

SELECT * FROM ref_table WHERE key_column=expr;

SELECT * FROM ref_table,other_table

WHERE ref_table.key_column=other_table.column;

SELECT * FROM ref_table,other_table

WHERE ref_table.key_column_part1=other_table.column

AND ref_table.key_column_part2=1;

o ref_or_null

该联接类型如同ref,但是添加了MySQL可以专门搜索包含NULL值的行。在解决子查询中经常使用该联接类型的优化。

在下面的例子中,MySQL可以使用ref_or_null联接来处理

ref_tables:

SELECT * FROM ref_table

WHERE key_column=expr OR key_column IS NULL;

参见7.2.7节,“MySQL如何优化IS NULL”。

o index_merge

该联接类型表示使用了索引合并优化方法。在这种情况下,key列包含了使用的索引的清单,key_len包含了使用的索引的最长的关键元素。详细信息参见7.2.6节,“索引合并优化”。

o unique_subquery

该类型替换了下面形式的IN子查询的ref:

value IN (SELECT primary_key FROM single_table WHERE some_expr)

unique_subquery是一个索引查找函数,可以完全替换子查询,效率

更高。

o index_subquery

该联接类型类似于unique_subquery。可以替换IN子查询,但只适合

下列形式的子查询中的非唯一索引:

value IN (SELECT key_column FROM single_table WHERE some_expr) o range

只检索给定范围的行,使用一个索引来选择行。key列显示使用了

哪个索引。key_len包含所使用索引的最长关键元素。在该类型中

ref列为NULL。

当使用=、<>、>、>=、<、<=、IS NULL、<=>、BETWEEN或者IN操作符,

用常量比较关键字列时,可以使用range:

SELECT * FROM tbl_name

WHERE key_column = 10;

SELECT * FROM tbl_name

WHERE key_column BETWEEN 10 and 20;

SELECT * FROM tbl_name

WHERE key_column IN (10,20,30);

SELECT * FROM tbl_name

WHERE key_part1= 10 AND key_part2 IN (10,20,30);

o index

该联接类型与ALL相同,除了只有索引树被扫描。这通常比ALL

快,因为索引文件通常比数据文件小。

当查询只使用作为单索引一部分的列时,MySQL可以使用该联接类

型。

o ALL

对于每个来自于先前的表的行组合,进行完整的表扫描。如果表是

第一个没标记const的表,这通常不好,并且通常在它情况下很差。

通常可以增加更多的索引而不要使用ALL,使得行能基于前面的表

中的常数值或列值被检索出。

·possible_keys

possible_keys列指出MySQL能使用哪个索引在该表中找到行。注意,该列完全独立于EXPLAIN输出所示的表的次序。这意味着在possible_keys 中的某些键实际上不能按生成的表次序使用。

如果该列是NULL,则没有相关的索引。在这种情况下,可以通过检查WHERE 子句看是否它引用某些列或适合索引的列来提高你的查询性能。如果是这样,创造一个适当的索引并且再次用EXPLAIN检查查询。参见13.1.2节,“ALTER TABLE语法”。

为了看清一张表有什么索引,使用SHOW INDEX FROM tbl_name。

·key

key列显示MySQL实际决定使用的键(索引)。如果没有选择索引,键是NULL。要想强制MySQL使用或忽视possible_keys列中的索引,在查询中使用FORCE INDEX、USE INDEX或者IGNORE INDEX。参见13.2.7节,“SELECT 语法”。

对于MyISAM和BDB表,运行ANALYZE TABLE可以帮助优化器选择更好的索引。

对于MyISAM表,可以使用myisamchk --analyze。参见13.5.2.1节,“ANALY ZE TABLE语法”和5.9.4节,“表维护和崩溃恢复”。

·key_len

key_len列显示MySQL决定使用的键长度。如果键是NULL,则长度为NULL。

注意通过key_len值我们可以确定MySQL将实际使用一个多部关键字的几个部分。

·ref

ref列显示使用哪个列或常数与key一起从表中选择行。

·rows

rows列显示MySQL认为它执行查询时必须检查的行数。

·Extra

该列包含MySQL解决查询的详细信息。下面解释了该列可以显示的不同的文本字符串:

o Distinct

MySQL发现第1个匹配行后,停止为当前的行组合搜索更多的行。

o Not exists

MySQL能够对查询进行LEFT JOIN优化,发现1个匹配LEFT JOIN标

准的行后,不再为前面的的行组合在该表内检查更多的行。

下面是一个可以这样优化的查询类型的例子:

SELECT * 从t1 LEFT JOIN t2 ON t1.id=t2.id

WHERE t2.id IS NULL;

假定t2.id定义为NOT NULL。在这种情况下,MySQL使用t1.id的值

扫描t1并查找t2中的行。如果MySQL在t2中发现一个匹配的行,

它知道t2.id绝不会为NULL,并且不再扫描t2内有相同的id值的行。

换句话说,对于t1的每个行,MySQL只需要在t2中查找一次,无

论t2内实际有多少匹配的行。

o range checked for each record (index map: #)

MySQL没有发现好的可以使用的索引,但发现如果来自前面的表的

列值已知,可能部分索引可以使用。对前面的表的每个行组合,

MySQL检查是否可以使用range或index_merge访问方法来索取行。

关于适用性标准的描述参见7.2.5节,“范围优化”和7.2.6节,

“索引合并优化”,不同的是前面表的所有列值已知并且认为是常

量。

这并不很快,但比执行没有索引的联接要快得多。

o Using filesort

MySQL需要额外的一次传递,以找出如何按排序顺序检索行。通过

根据联接类型浏览所有行并为所有匹配WHERE子句的行保存排序关

键字和行的指针来完成排序。然后关键字被排序,并按排序顺序检

索行。参见7.2.12节,“MySQL如何优化ORDER BY”。

o Using index

从只使用索引树中的信息而不需要进一步搜索读取实际的行来检

索表中的列信息。当查询只使用作为单一索引一部分的列时,可以

使用该策略。

o Using temporary

为了解决查询,MySQL需要创建一个临时表来容纳结果。典型情况

如查询包含可以按不同情况列出列的GROUP BY和ORDER BY子句时。

o Using where

WHERE子句用于限制哪一个行匹配下一个表或发送到客户。除非你

专门从表中索取或检查所有行,如果Extra值不为Using where并且

表联接类型为ALL或index,查询可能会有一些错误。

如果想要使查询尽可能快,应找出Using filesort 和Using temporary

的Extra值。

o Using sort_union(...), Using union(...), Using intersect(...)

这些函数说明如何为index_merge联接类型合并索引扫描。详细信息

参见7.2.6节,“索引合并优化”。

o Using index for group-by

类似于访问表的Using index方式,Using index for group-by表示MySQL

发现了一个索引,可以用来查询GROUP BY或DISTINCT查询的所有列,

而不要额外搜索硬盘访问实际的表。并且,按最有效的方式使用索

引,以便对于每个组,只读取少量索引条目。详情参见7.2.13节,

“MySQL如何优化GROUP BY”。

通过相乘EXPLAIN输出的rows列的所有值,你能得到一个关于一个联接如何的提示。这应该粗略地告诉你MySQL必须检查多少行以执行查询。当你使用

max_join_size变量限制查询时,也用这个乘积来确定执行哪个多表SELECT语句。参见7.5.2节,“调节服务器参数”。

下列例子显示出一个多表JOIN如何能使用EXPLAIN提供的信息逐步被优化。

假定你有下面所示的SELECT语句,计划使用EXPLAIN来检查它:

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_1.COUNTRY, do.CUSTNAME

FROM tt, et, et AS et_1, do

WHERE tt.SubmitTime IS NULL

AND tt.ActualPC = et.EMPLOYID

AND tt.AssignedPC = et_1.EMPLOYID

AND tt.ClientID = do.CUSTNMBR;

对于这个例子,假定:

·

·

·值不是均匀分布的。

开始,在进行优化前,EXPLAIN语句产生下列信息:

table type possible_keys key key_len ref rows Extra

et ALL PRIMARY NULL NULL NULL 74

do ALL PRIMARY NULL NULL NULL 2135

et_1 ALL PRIMARY NULL NULL NULL 74

tt ALL AssignedPC, NULL NULL NULL 3872

ClientID,

ActualPC

range checked for each record (key map: 35)

因为type对每张表是ALL,这个输出显示MySQL正在对所有表产生一个笛卡尔乘积;即每一个行的组合!这将花相当长的时间,因为必须检查每张表的行数的乘积!对于一个实例,这是74 * 2135 * 74 * 3872 = 45,268,558,720行。如果表更大,你只能想象它将花多长时间……

这里的一个问题是MySQL能更高效地在声明具有相同类型和尺寸的列上使用索引。在本文中,VARCHAR和CHAR是相同的,除非它们声明为不同的长度。因为tt.ActualPC被声明为CHAR(10)并且et.EMPLOYID被声明为CHAR(15),长度不匹配。

为了修正在列长度上的不同,使用ALTER TABLE将ActualPC的长度从10个字符变为15个字符:

mysql> ALTER TABLE tt MODIFY ActualPC VARCHAR(15);

现在tt.ActualPC和et.EMPLOYID都是VARCHAR(15),再执行EXPLAIN语句产生这个结果:

table type possible_keys key key_len ref rows Extra

tt ALL AssignedPC, NULL NULL NULL 3872 Using

ClientID, where

ActualPC

do ALL PRIMARY NULL NULL NULL 2135

range checked for each record (key map: 1)

et_1 ALL PRIMARY NULL NULL NULL 74

range checked for each record (key map: 1)

et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1

这不是完美的,但是好一些了:rows值的乘积少了一个因子74。这个版本在几秒内执行完。

第2种方法能消除tt.AssignedPC = et_1.EMPLOYID和tt.ClientID =

do.CUSTNMBR比较的列的长度失配问题:

mysql> ALTER TABLE tt MODIFY AssignedPC VARCHAR(15),

->MODIFY ClientID VARCHAR(15);

EXPLAIN产生的输出显示在下面:

table type possible_keys key key_len ref rows Extra

et ALL PRIMARY NULL NULL NULL 74

tt ref AssignedPC, ActualPC 15 et.EMPLOYID 52 Using

ClientID, where

ActualPC

et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1

do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1

这几乎很好了。

剩下的问题是,默认情况,MySQL假设在tt.ActualPC列的值是均匀分布的,并且对tt表不是这样。幸好,很容易告诉MySQL来分析关键字分布:

mysql> ANALYZE TABLE tt;

现在联接是“完美”的了,而且EXPLAIN产生这个结果:

table type possible_keys key key_len ref rows Extra

tt ALL AssignedPC NULL NULL NULL 3872 Using

ClientID, where

ActualPC

et eq_ref PRIMARY PRIMARY 15 tt.ActualPC 1

et_1 eq_ref PRIMARY PRIMARY 15 tt.AssignedPC 1

do eq_ref PRIMARY PRIMARY 15 tt.ClientID 1

注意在从EXPLAIN输出的rows列是一个来自MySQL联接优化器的“教育猜测”。你应该检查数字是否接近事实。如果不是,可以通过在SELECT语句里面使用

STRAIGHT_JOIN并且试着在FROM子句以不同的次序列出表,可能得到更好的性能。

7.2.2. 估计查询性能

在大多数情况下,可以通过计算磁盘搜索来估计性能。对小的表,通常能在1

次磁盘搜索中找到行(因为索引可能被缓存)。对更大的表,可以使用B-树索引进行估计,将需要log(row_count)/log(index_block_length/3 *

2/(index_length + data_pointer_length))+1次搜索才能找到行。

在MySQL中,索引块通常是1024个字节,数据指针通常是4个字节,这对于有一个长度为3(中等整数)的索引的500,000行的表,通过公式可以计算出

log(500,000)/log(1024/3*2/(3+4))+1= 4次搜索。

上面的索引需要大约500,000 * 7 * 3/2 = 5.2MB,(假设典型情况下索引缓存区填充率为2/3),可以将大部分索引保存在内存中,仅需要1-2调用从OS读数据来找出行。

然而对于写,将需要4次搜索请求(如上)来找到在哪儿存放新索引,并且通常需要2次搜索来更新这个索引并且写入行。

注意,上述讨论并不意味着应用程序的性能将缓慢地以log N退化!当表格变得更大时,所有内容缓存到OS或SQL服务器后,将仅仅或多或少地更慢。在数据变得太大不能缓存后,将逐渐变得更慢,直到应用程序只能进行磁盘搜索(以log N增加)。为了避免这个问题,随数据增加而增加键高速缓冲区大小。对于MyISAM表, 由key_buffer_size系统变量控制键高速缓冲区大小。参见7.5.2节,“调节服务器参数”。

7.2.3. SELECT查询的速度

总的来说,要想使一个较慢速SELECT ... WHERE更快,应首先检查是否能增加一个索引。不同表之间的引用通常通过索引来完成。你可以使用EXPLAIN语句来确定SELECT语句使用哪些索引。参见7.4.5节,“MySQL如何使用索引”和7.2.1节,“EXPLAIN语法(获取关于SELECT的信息)”。

下面是一些加速对MyISAM表的查询的一般建议:

·为了帮助MySQL更好地优化查询,在一个装载数据后的表上运行ANALYZE TABLE或myisamchk --analyze。这样为每一个索引更新指出有

相同值的行的平均行数的值(当然,如果只有一个索引,这总是1。)MySQL 使用该方法来决定当你联接两个基于非常量表达式的表时选择哪个索引。

你可以使用SHOW INDEX FROM tbl_name并检查Cardinality值来检查表分

析结果。myisamchk --description --verbose可以显示索引分布信息。

·要想根据一个索引排序一个索引和数据,使用myisamchk

--sort-index --sort-records=1(如果你想要在索引1上排序)。如果只有一个索引,想要根据该索引的次序读取所有的记录,这是使查询更快的一个好方法。但是请注意,第一次对一个大表按照这种方法排序时将花很长时间!

7.2.4. MySQL怎样优化WHERE子句

该节讨论为处理WHERE子句而进行的优化。例子中使用了SELECT语句,但相同的优化也适用DELETE和UPDATE语句中的WHERE子句。

请注意对MySQL优化器的工作在不断进行中,因此该节并不完善。MySQL执行了大量的优化,本文中所列的并不详尽。

下面列出了MySQL执行的部分优化:

·去除不必要的括号:

((a AND b) AND c OR (((a AND b) AND (c AND d)))) ????????????????

-> (a AND b AND c) OR (a AND b AND c AND d) ????????????????

·常量重叠:

(a

????????????????

-> b>5 AND b=c AND a=5

????????????????

·去除常量条件(由于常量重叠需要):

(B>=5 AND B=5) OR (B=6 AND 5=5) OR (B=7 AND 5=6)

????????????????

-> B=5 OR B=6

????????????????

·索引使用的常数表达式仅计算一次。

?对于MyISAM和HEAP表,在一个单个表上的没有一个WHERE的COUNT(*)直接从表中检索信息。当仅使用一个表时,对NOT NULL表达式也这样做。

?无效常数表达式的早期检测。MySQL快速检测某些SELECT语句是不可能的并且不返回行。

?如果不使用GROUP BY或分组函数(COUNT()、MIN()……),HAVING与WHERE 合并。

?对于联接内的每个表,构造一个更简单的WHERE以便更快地对表进行WHERE计算并且也尽快跳过记录。

?所有常数的表在查询中比其它表先读出。常数表为:

o空表或只有1行的表。

o与在一个PRIMARY KEY或UNIQUE索引的WHERE子句一起使用的表,这里所有的索引部分使用常数表达式并且索引部分被定义为

NOT NULL。

下列的所有表用作常数表:

mysql> SELECT * FROM t WHERE primary_key=1;

mysql> SELECT * FROM t1,t2

WHERE t1.primary_key=1 AND t2.primary_key=t1.id;

?尝试所有可能性便可以找到表联接的最好联接组合。如果所有在ORDER BY和GROUP BY的列来自同一个表,那么当联接时,该表首先被选中。

?如果有一个ORDER BY子句和不同的GROUP BY子句,或如果ORDER BY 或GROUP BY包含联接队列中的第一个表之外的其它表的列,则创建一个

临时表。

?如果使用SQL_SMALL_RESULT,MySQL使用内存中的一个临时表。

?每个表的索引被查询,并且使用最好的索引,除非优化器认为使用表扫描更有效。是否使用扫描取决于是否最好的索引跨越超过30%的表。优化器更加复杂,其估计基于其它因素,例如表大小、行数和I/O块大小,因此固定比例不再决定选择使用索引还是扫描。

?在一些情况下,MySQL能从索引中读出行,甚至不查询数据文件。如果索引使用的所有列是数值类,那么只使用索引树来进行查询。

?输出每个记录前,跳过不匹配HAVING子句的行。

下面是一些快速查询的例子:

SELECT COUNT(*) FROM tbl_name;

SELECT MIN(key_part1),MAX(key_part1) FROM tbl_name;

SELECT MAX(key_part2) FROM tbl_name

WHERE key_part1=constant;

SELECT ... FROM tbl_name

ORDER BY key_part1,key_part2,... LIMIT 10;

SELECT ... FROM tbl_name

ORDER BY key_part1 DESC, key_part2 DESC, ... LIMIT 10;

下列查询仅使用索引树就可以解决(假设索引的列为数值型):

SELECT key_part1,key_part2 FROM tbl_name WHERE key_part1=val;

SELECT COUNT(*) FROM tbl_name

WHERE key_part1=val1 AND key_part2=val2;

SELECT key_part2 FROM tbl_name GROUP BY key_part1;

下列查询使用索引按排序顺序检索行,不用另外的排序:

SELECT ... FROM tbl_name

ORDER BY key_part1,key_part2,... ;

SELECT ... FROM tbl_name

ORDER BY key_part1 DESC, key_part2 DESC, ... ;

7.2.5. 范围优化

7.2.5.1. 单元素索引的范围访问方法

7.2.5.2. 多元素索引的范围访问方法

range访问方法使用单一索引来搜索包含在一个或几个索引值距离内的表记录的子集。可以用于单部分或多元素索引。后面的章节将详细描述如何从WHERE子句提取区间。

7.2.5.1. 单元素索引的范围访问方法

对于单元素索引,可以用WHERE子句中的相应条件很方便地表示索引值区间,因此我们称为范围条件而不是“区间”。

单元素索引范围条件的定义如下:

·对于BTREE和HASH索引,当使用=、<=>、IN、IS NULL或者IS NOT NULL 操作符时,关键元素与常量值的比较关系对应一个范围条件。

·对于BTREE索引,当使用>、<、>=、<=、BETWEEN、!=或者<>,或者LIKE 'pattern'(其中'pattern'不以通配符开始)操作符时,关键元素与常量值的比较关系对应一个范围条件。

·对于所有类型的索引,多个范围条件结合OR或AND则产生一个范围条件。

前面描述的“常量值”系指:

·查询字符串中的常量

·同一联接中的const或system表中的列

·无关联子查询的结果

·完全从前面类型的子表达式组成的表达式

下面是一些WHERE子句中有范围条件的查询的例子:

SELECT * FROM t1

WHERE key_col > 1

AND key_col < 10;

SELECT * FROM t1

WHERE key_col = 1

OR key_col IN (15,18,20);

SELECT * FROM t1

WHERE key_col LIKE 'ab%'

OR key_col BETWEEN 'bar' AND 'foo';

请注意在常量传播阶段部分非常量值可以转换为常数。

MySQL尝试为每个可能的索引从WHERE子句提取范围条件。在提取过程中,不能用于构成范围条件的条件被放弃,产生重叠范围的条件组合到一起,并且产生空范围的条件被删除。

例如,考虑下面的语句,其中key1是有索引的列,nonkey没有索引:

SELECT * FROM t1 WHERE

(key1 < 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR

(key1 < 'bar' AND nonkey = 4) OR

(key1 < 'uux' AND key1 > 'z');

key1的提取过程如下:

1. 用原始WHERE子句开始:

2. (key1 < 'abc' AND (key1 LIKE 'abcde%' OR key1 LIKE '%b')) OR

3. (key1 < 'bar' AND nonkey = 4) OR

4. (key1 < 'uux' AND key1 > 'z')

5. 删除nonkey = 4和key1 LIKE '%b',因为它们不能用于范围扫描。删除

它们的正确途径是用TRUE替换它们,以便进行范围扫描时不会丢失匹配

的记录。用TRUE替换它们后,可以得到:

6. (key1 < 'abc' AND (key1 LIKE 'abcde%' OR TRUE)) OR

7. (key1 < 'bar' AND TRUE) OR

8. (key1 < 'uux' AND key1 > 'z')

9. 取消总是为true或false的条件:

·(key1 LIKE 'abcde%' OR TRUE)总是true

·(key1 < 'uux' AND key1 > 'z')总是false 用常量替换这些条件,我们得到:

(key1 < 'abc' AND TRUE) OR (key1 < 'bar' AND TRUE) OR (FALSE)

删除不必要的TRUE和FALSE常量,我们得到

(key1 < 'abc') OR (key1 < 'bar')

10.将重叠区间组合成一个产生用于范围扫描的最终条件:

11. (key1 < 'bar')

总的来说(如前面的例子所述),用于范围扫描的条件比WHERE子句限制少。MySQL 再执行检查以过滤掉满足范围条件但不完全满足WHERE子句的行。

范围条件提取算法可以处理嵌套的任意深度的AND/OR结构,并且其输出不依赖条件在WHERE子句中出现的顺序。

7.2.5.2. 多元素索引的范围访问方法

多元素索引的范围条件是单元素索引的范围条件的扩展。多元素索引的范围条件将索引记录限制到一个或几个关键元组内。使用索引的顺序,通过一系列关键元组来定义关键元组区间。

例如,考虑定义为key1(key_part1, key_part2, key_part3)的多元素索引,以及下面的按关键字顺序所列的关键元组:

key_part1key_part2key_part3

NULL 1 'abc'

NULL 1'xyz'

NULL 2 'foo'

1 1 'abc'

1 1 'xyz'

1 2 'abc'

2 1 'aaa'

条件key_part1 = 1定义了下面的范围:

(1,-inf,-inf) <= (key_part1,key_part2,key_part3) < (1,+inf,+inf)

范围包括前面数据集中的第4、5和6个元组,可以用于范围访问方法。

通过对比,条件key_part3= 'abc'不定义单一的区间,不能用于范围访问方法。下面更加详细地描述了范围条件如何用于多元素索引中。

·对于HASH索引,可以使用包含相同值的每个区间。这说明区间只能由下面形式的条件产生:

key_part1cmp const1

????????????????

AND key_part2cmp const2

AND ...

????????????????

AND key_partN cmp constN;

????????????????

这里,const1,const2,...为常量,cmp是=、<=>或者IS NULL比较操作符之

一,条件包括所有索引部分。(也就是说,有N个条件,每一个对应N-元素索引的每个部分)。

关于常量的定义,参见7.2.5.1节,“单元素索引的范围访问方法”。

例如,下面为三元素HASH索引的范围条件:

key_part1 = 1 AND key_part2 IS NULL AND key_part3 = 'foo'·对于BTREE索引,区间可以对结合AND的条件有用,其中每个条件用一个常量值通过=、<=>、IS NULL、>、<、>=、<=、!=、<>、BETWEEN或者LIKE 'pattern' (其中'pattern'不以通配符开头)比较一个关键元素。区间可

以足够长以确定一个包含所有匹配条件(或如果使用<>或!=,为两个区间)的记录的单一的关键元组。例如,对于条件:

key_part1= 'foo' AND key_part2>= 10 AND key_part3> ????????????????

10

单一区间为:

('foo',10,10)

< (key_part1,key_part2,key_part3)

< ('foo',+inf,+inf)

创建的区间可以比原条件包含更多的记录。例如,前面的区间包括值

('foo',11,0),不满足原条件。

·如果包含区间内的一系列记录的条件结合使用OR,则形成包括一系列包含在区间并集的记录的一个条件。如果条件结合使用了AND,则形成包括一系列包含在区间交集内的记录的一个条件。例如,对于两部分索引的条件:

(key_part1 = 1 AND key_part2 < 2)

????????????????

OR (key_part1 > 5)

????????????????

区间为:

(1, -inf) < (key_part1, key_part2) < (1, 2)

(5, -inf) < (key_part1, key_part2)

在该例子中,第1行的区间左侧的约束使用了一个关键元素,右侧约束使

用了两个关键元素。第2行的区间只使用了一个关键元素。EXPLAIN输出

的key_len列表示所使用关键字前缀的最大长度。

在某些情况中,key_len可以表示使用的关键元素,但可能不是你所期望

的。假定key_part1和key_part2可以为NULL。则key_len列显示下面条

件的两个关键元素的长度:

key_part1 >= 1 AND key_part2 < 2

但实际上,该条件可以变换为:

key_part1 >= 1 AND key_part2 IS NOT NULL

7.2.5.1节,“单元素索引的范围访问方法”描述了如何进行优化以结合或删除单元素索引范围条件的区间。多元素索引范围条件的区间的步骤类似。

核电厂汽轮机控制系统优化改进分析 刘玉廷

核电厂汽轮机控制系统优化改进分析刘玉廷 发表时间:2018-01-06T20:53:43.340Z 来源:《电力设备》2017年第26期作者:刘玉廷 [导读] 摘要:某核电厂#1机组投入商运后,在冬季工况电功率达到额定功率1086MW时,核功率为2885MW,核功率仅为99.3%FP,未达到核岛设计的满功率。 (苏州热工研究院有限公司广东深圳 518124) 摘要:某核电厂#1机组投入商运后,在冬季工况电功率达到额定功率1086MW时,核功率为2885MW,核功率仅为99.3%FP,未达到核岛设计的满功率。为了提高该核电厂#1机组电功率,保证核功率能够达到100%FP,从而对该核电厂的汽轮机控制系统进行优化改进,提高机组整体运行经济性。 关键词:核电厂;汽轮机;控制系统;优化改进 1 工程概况 某核电厂GRE系统(汽轮机控制系统)采用西门子设计方案,GRE系统中汽轮机负荷最大限值GRE0110ND为额定负荷1086MW。根据汽轮机维修手册和热平衡图等文件,汽轮机在VWO工况下运行,负荷可达到1117.2MW。目前该核电厂受限于GRE系统GRE0110ND值(最大负荷限值)的限制,汽轮机负荷最大只能达到额定负荷1086MW。目前存在问题如下:首先,在冬季海水温度低时,汽轮机电功率已达到1086MW时,但核功率约为99.3%FP,理论上核功率100%FP时,还可提升电功率约10MW,汽轮机电功率未达到最佳经济效益。其次,受此最大负荷上限定值的限制,导致核功率无法达到满功率,同时会给核岛满功率相关性能试验带来不便。为充分发挥汽轮机潜能,提高机组整体运行的经济性,需对该核电1、2号机汽轮机GRE系统中负荷最大限值进行修改:将GRE0110ND限值修改为1117.2MW。 2 汽轮机控制系统改进 2.1 汽轮机控制系统改进方案 修改汽轮机最大负荷上限定值,由1086MW修改为1117.2MW。 根据汽轮机目标负荷,详细变更方案如下:1)将GRE AP3/AP1控制器中负荷最大限值修改为1117.2MW,使汽轮机最大目标负荷设定值与汽轮机VWO工况相匹配。 2)GRE控制回路负荷最大限值修改后,RB控制回路相关参数量程需进行同步修改,使之与定值手册文件保持一致。3)TCS与DCS 通讯清单中与负荷设定相关的通讯点量程修改。参考逻辑图文件中负荷参考值72信号生成逻辑的量程设置0-1200及DCS输入信号清单文件中GRE072MY量程0-1200MW,TCS与DCS负荷设定相关通讯点量程需统一修改为1200MW。 1200MW量程的统一还可有效避免非异常工况控制器小选71信号(送RGL负荷限制信号)触发RGL GD输入的负荷参考值72信号切至开度参考值74信号造成RGL不必要扰动。4)DCS/TCS画面描述修改。由于汽轮机负荷最大限值及通讯点量程的修改,DCS/TCS画面描述需进行同步修改,保证画面显示与逻辑设置一致。 2.2 核电厂汽轮机控制系统改进的可行性 2.2.1 轴承振动评估 通过对50%Pn和100%Pn两个功率平台各轴承瓦振和轴振的比较分析可得:两个功率平台各轴承的振动情况非常良好,当汽轮发电机组功率发生变化时,各轴承振动变化不大,且都远小于报警值。因此,该汽轮发电机组电功率提升至1117.2MW时,对汽轮发电机组各轴承的振动基本无影响。 2.3轴承温度分析评估 通过对50%Pn和100%Pn两个功率平台各轴承温度比较分析可得:两个功率平台轴承温度均非常良好,当汽轮发电机组功率变化时,汽轮机轴承温度变化不大,且远小于各轴承温度报警值。因此,#1汽轮发电机组功率提升至1117.2MW时,对各轴承温度基本无影响。 2.2.2 汽轮机低压转子绝对膨胀评估 汽轮机低压转子绝对膨胀测点(GME1401MV)布置在汽轮机4 号轴承座上,根据本机型滑销系统特点,该测点表征的是低压转子的绝对膨胀值。目前低压转子绝对膨胀(GME1401MV)报警值为16.1mm,手动停机值为18.1mm。汽轮机低压转子绝对膨胀受冬季低温环境影响明显,当环境温度和海水温度降低时,低压转子绝对膨胀值(GME1401MV)有增大趋势。鉴于现场的实际运行情况,将低压转子绝对膨胀的报警值调整到17.8mm,打闸值调整到19.1mm,不影响汽机安全运行。 2.2.3 RCV系统运行分析评估 #1机组核功率为99.3%FP时,RCV系统各参数都在设计范围内。如果将核功率提升至100%FP,一回路压力仍维持在15.5MPa时,平均温度将上升至310℃左右。RCV系统下泄温度将会略有上升,主泵轴封泄漏水量也将会略有增加,但都不会超过设计限值。如果该核电厂#1机组由目前的状态提升功率至100%FP后,RCV下泄温度有所上升,其它RCV系统设备和运行参数变化值微小,都在设计范围内,不会影响其设备可靠性和超设计运行。因此,该核电厂#1机组核功率提升至100%FP,化容控制和反应性控制主要功能都能按照设计要求运行。主冷却剂泵的轴封水泄漏量会略有增加,但未超过设计范围,不会导致主泵轴封泄漏量高报警。同时,此变化不会对稳压器的辅助喷淋水产生影响。 2.2.4 CRF系统运行评估 目前,该核电厂#1机组电功率约为1087.53MW,一回路热功率约为2891.85MW,海水温度约12.035℃。考虑极端情况,转化为电能

2020年供应链优化项目参照模板

ASPEN MIMI 供应链优化项目 一、供应链技术简介 随着中国加入WTO,客户需求的增加和企业竞争的全球化,中国企业正迎接着变革传统的经营方式的时代。企业信息化建设所涉及的企业管理中的问题很多,其中“供应链管理”就是非常重要的一个方面,能够使得企业的生产、销售和物流计划最佳化的供应链管理正日益受到重视。供应链管理(Supply Chain Management,简称SCM)是近几年在企业实行E化和信息化管理中最流行和有效的管理模式之一。事实也证明,成功的供应链管理确实能使企业在激烈的市场竞争中,明显地提升企业的核心竞争力。 1.什么是供应链管理 供应链管理(Supply Chain Management)则是对供应链所涉及组织的集成和对物流、信息流、资金流的协同,以满足用户的需求和提高供应链整体竞争能力。简而言之,供应链管理就是优化和改进供应链活动,供应链管理的对象是供应链的组织(企业)和它们内部的“流”及组织与组织(企业与企业)之间的“流”;应用的方法是集成和协同;目标

是满足用户需求最终和提高供应链的整体竞争能力。有效的供应链管理是通过持续地向以下这些关键业务目标努力来实现利益最大化的,包括: ●降低成本 ●提高收入 ●改进质量 ●缩短市场需求响应时间 ●提高业务伙伴的灵活性 ●优化库存 ●提高资产利用率 2.供应链管理优化的关键驱动因素是什么? 当今国际上供应链管理面临的最大挑战,是在最大程度降低成本与投资的情况下满足供应链优化的三个主要驱动因素: 驱动因素之一就是供应链透明——最终用户能够对从原材料采购到成品发运的整个过程进行有效的跟踪、控制、调整,能够实现对整个供应链从采购到销售全过程的监控,掌握充分的信息。 驱动因素之二就是供应链灵活——当下游的市场情况或上游的供应商供应情况发生变化的时候,能够比竞争对手更快地调整供应链运作方式及策略,通过灵活的供应链管理

方案比较法(第七章)

7 矿井设计的方案比较法 7.1 概述 方案比较法是工程设计中最基本和最常用的设计方法,既能解决总体的又能解决局部的设计问题,常被称为万能的设计方法。近代出现的“最优化设计”方法(实际上方案比较法也是优化方法之一)也是在此基础上发展起来的。我国自五十年代初,在矿井设计中一直沿用方案比较法,尤其在方案设计或可行性研究中,多用此法。 7.1.1方案比较法的实质 在进行工程设计时,根据已知条件列出在技术上可行的若干个方案,然后进行具体的技术分析和经济比较,从中选出相对最优越的一种方案。这种设计方法就称为方案比较法。7.1.2方案比较法的步骤 (1)首先要明确设计的内容、性质、要求(这些要求在《设计任务书》中有具体文字说明),以及设计要达到的目标(主要参数和额定指标)等。 (2)然后熟悉和掌握设计任务或设计中所要解决的总体或局部课题的内部及外部条件。对矿井设计来说,主要是:井田的地质地形条件;交通情况;与邻井的关系;与其他企业关系等。 (3)根据内部及外部条件,依设计任务的内容和目标,提出可行的方案。 (4)对提出的可行方案进行技术和经济分析,从中选取(3~5)个较优方案。 (5)对选出的较优方案进行详细的技术和经济计算与比较,明确各方案在技术上和经济上的差异,全面衡量各方案的利弊。然后从各方案中选出最优的方案,做为设计最终方案。 (6)最后按设计任务的要求,对方案做出详细描述的文字说明(包括各项参数),并绘出方案的图纸。 7.2矿井设计方案的技术分析 由于矿井地质条件的多样性和技术装备的不断发展,一个井田的开拓可以提出若干技术上可行的设计方案。从这些可行的设计方案中选择技术上先进、经济上合理的方案,就是方案比较的任务。 井田开拓方案比较内容包括井筒形式、生产能力、井筒(平硐)位置、水平划分、通风方式、运输大巷布置、大巷运输方式、总回风道布置、采区划分等项。 7.2.1井筒形式方案比较内容 在技术上可用平硐开拓也可用斜井开拓的井田,或可用斜井开拓也可用立井开拓的井田,或可用单一方式开拓也可用综合式开拓的井田,其井筒形式往往需要进行大量的方案比较工作。

ERP系统改善建议

ERP系统优化建议 --------信息部 1.采购往来账查询时间不一致问题: 现象:采购退出单打印单据上只有打印时间,跟系统的开票时间对不上,不方便对账,且纸质单据上多出一栏【备注】。 解决方案:修改采购退出单打印方案,将表头【备注】去掉、【打印时间】调整为开票日期。建议:若系统支持,单据上可增加栏位【打印次数】,以防止重复打印导致二次对账。 2.采购退补价问题: 现象:采购中间发生退补价,实际退货时由于系统不能提示发生过退补,故操作员可能仍按原采购价进行退货从而导致经济损失。 解决方案:在采购原单上,增加一个【退补新价】字段,审核退补单时更新退补价至该字段(写一个存储过程),并在采购退出开票单上浏览原单窗体上显示出来,按采购新价进行退回。 3.查询哪些采购退回开票单已实际出库比较困难,需手工找单排查费力耗时? 原因分析:为提高工作效率,采购退回开票单会提前填制,且实际出库时并未在系统单据上留下标识记录。 解决方案:在采购退回开票单主表增加【已出库】字段,辅助功能上增加【实际出库】按钮,当货品实际出库时操作员搜索该单并执行该功能即可,相关报表根据需要可增加【是否实际出库】条件查询。 4.采购开票(退出开票)能否自动分仓? 解决方案:在辅助功能处增加【自动分仓】按钮(写一个存储过程),根据货品分类将散件自动分配到散件仓,以减少操作员单据录入时间和人为误差。 5.采购退出开票能否提供修改【开票日期】功能? 解决方案:可以。方法一:若管理流程上允许直接修改,则将该栏位属性修改为可编辑即可;方法二:在表头增加【新开票日期】栏位,单据保存时自动更新开票日期或在打印模板中增加新模板(按新开票日期打印)。 6.网上订购平台登录时提示脚本错误“dd未定义”(不影响系统使用) 解决方案:非平台程序错误。由于平台主窗体调用了公司网站首页文件,而网站首页文件有代码问题,故修正该网页文件即可。 建议:如腾迅除了拥有QQ还拥有WebQQ一样,如果可能,可以开发一个基于浏览器版本的网上订购平台,并整合到公司网站里(公司网站目前为静态网页不支持后台动态管理,需继续升级和开发),这样当原订购平台不能正常下单或者因为安装问题不能正常使用时,可以为客户提供另一种订购渠道,增强客户对网上订货平台的信心。

应用系统项目优化方案研究

应用系统项目优化方案研究 版本:1.0

文档描述 文档变更

目录 1引言 (6) 1.1背景 (6) 1.2目的 (6) 1.3术语缩略语 (6) 1.4参考资料 (7) 1.5适用人群 (7) 2现状分析 (8) 3调优总体方案汇总 (9) 3.1应用程序调优(目前采用) (9) 3.1.1Java代码优化 9 3.1.2页面代码优化 9 3.1.3Sql语句优化(V2.2) 9 3.1.4应用架构代码优化 9 3.2容器调优(目前采用) (9) 3.2.1应用服务器优化(weblogic优化) 9 3.2.2JVM优化 12 3.3数据库调优(目前采用) (13) 3.3.1合理建立数据库 13 3.3.2SQL语句的优化 13 3.3.3数据库对象存储方式的优化 13 3.3.4内存的优化 13 3.3.5I/O 优化 13 3.3.6使用大表分区技术(采用) 13 3.3.7优化回滚段设计 13

3.3.8优化重做日志文件 13 3.4操作系统调优 (13) 3.5性能监控 (13) 3.5.1操作系统监控 13 3.5.2数据库监控 13 3.5.3中间件监控 13 3.5.4代码监控 14 3.5.5业务监控 14 3.6拆分与扩展 (14) 3.6.1硬件增加 14 3.6.2应用系统拆分 14 3.6.3业务拆分 14 3.6.4数据分割 15 3.7接口优化 (16) 4第一阶段方案 (17)

1引言 1.1背景 系统的数据量增长越来越快,系统的瓶颈问题越来越严重,影响了系统的正常使用,导致用户对系统操作方面非常不满意。 系统在前期已经进行过一些优化: 1.系统内部优化:页面框架变更、查询功能优化、sql表中加入索引等常规 优化 2.组件级调优:数据库、中间件一些常用参数的配置 取得一些效果,但在数据量成级数增长后,需要一些系统性的全面优化方案,以解决系统性能问题。 1.2目的 本文主要是针对系统的一个整体的优化,不涉及代码级别的。 1.3术语缩略语 1.4参考资料 1.5适用人群 项目管理人员、架构人员、配置管理人员、开发人员

能量系统优化项目建议书

能量系统优化项目建议书

能量系统优化(系统节能)项目 项 目 建 议 书 二〇一一年五月十日

目录 一、总论-- 7 (一)项目企业、项目背景、项目概况及项目建设的必要性 (二)项目承担企业产品质量、技术水平、生产能力、生产工艺及装备现状,与国内外先进水平的比较 (三)项目概况 (四)项目建设的必要性 二、发展规划、产业政策、行业准入和市场分析--14 (一)发展规划、产业政策、行业准入分析 (二)市场分析。包括产品市场供需分析、市场竞争力及风险分析 三、建设规模与主要建设方案--17 (一)主要建设条件 (二)项目主要建设内容及单项投资预计金额

(三)改造后主要产品生产规模(包括产能等) (四)改造后主要产品方案 (五)项目实施前后用能状况 四、技术方案、设备方案和工程方案--23 (一)主要设备方案 (二)工程方案 (三)技术方案、生产工艺流程及装备水平 (四)项目招标内容(适用于申请专项资金100万元及以上的投资项目) 五、厂址选择及用地方案--25 (一)厂址现状及建设条件、用地方案 (二)现有场地利用情况 (三)土地利用合理性分析 六、总图、运输与公用辅助工程--26 (一)总图布置

(二)场内外运输 (三)公用辅助工程 七、主要原材料供应、资源开发及综合利用分析--28 (一)主要原材料供应 (二)资源开发和利用方案 (三)资源节约措施 八、节能措施--29 (一)能耗状况和能耗指标分析 (二)节能措施和节能效果分析 九、环境影响分析--30 (一)厂址环境条件和现状 (二)项目建设和生产对环境的影响 (三)环境保护措施方案 (四)环境保护 (五)环境影响评价

第7讲最优化问题.pdf

第7讲最优化问题 一、知识要点 在日常生活和生产中,我们经常会遇到下面的问题:完成一件事情,怎样 合理安排才能做到用的时间最少,效果最佳。这类问题在数学中称为统筹问题。 我们还会遇到“费用最省”、“面积最大”、“损耗最小”等等问题,这些问 题往往可以从极端情况去探讨它的最大(小)值,这类问题在数学中称为极值 问题。以上的问题实际上都是“最优化问题”。 二、精讲精练 【例题1】用一只平底锅煎饼,每次只能放两个,剪一个饼需要2分钟(规定正反面各需要1分钟)。问煎3个饼至少需要多少分钟? 练习1: 1、烤面包时,第一面需要2分钟,第二面只要烤1分钟,即烤一片面包需要3分钟。小丽用来烤面包的架子,一次只能放两片面包,她每天早上吃3片面包,至少要烤多少分钟? 2、用一只平底锅烙大饼,锅里只能同时放两个。烙熟大饼的一面需要3分钟,现在要烙3个大饼,最少要用几分钟? 1

【例题2】妈妈让小明给客人烧水沏茶。洗水壶需要1分钟,烧开水需要15分钟,洗茶壶需要1分钟,洗茶杯需要1分钟。要让客人喝上茶,最少需要多少分钟? 练习2: 1、小虎早晨要完成这样几件事:烧一壶开水需要10分钟,把开水灌进热 水瓶需要2分钟,取奶需要5分钟,整理书包需要4分钟。他完成这几件事最少需要多少分钟? 2、小强给客人沏茶,烧开水需要12分钟,洗茶杯要2分钟,买茶叶要8 分钟,放茶叶泡茶要1分钟。为了让客人早点喝上茶,你认为最合理的安排, 多少分钟就可以了? 2

【例题3】五(1)班赵明、孙勇、李佳三位同学同时到达学校卫生室,等 候校医治病。赵明打针需要5分钟,孙勇包纱布需要3分钟,李佳点眼药水需要1分钟。卫生室只有一位校医,校医如何安排三位同学的治病次序,才能使 三位同学留在卫生室的时间总和最短? 练习3: 1、甲、乙、丙三人分别拿着2个、3个、1个热水瓶同时到达开水供应点打热水。热水龙头只有一个,怎样安排他们打水的次序,可以使他们打热水所 花的总时间最少? 2、甲、乙、丙三人到商场批发部洽谈业务,甲、乙、丙三人需要的时间分 别是10分钟、16分钟和8分钟。怎样安排,使3人所花的时间最少?最少时间是多少? 3

系统优化

《系统优化》教学设计 一、教材内容分析 1.教材的地位和作用 系统优化是系统分析的深入,也是系统的结构和系统分析的综合,又是系统设计的基础,更是系统设计过程中的重要环节,它是是本书的重要内容之一。本内容是让学生“理解系统 优化的意义,能结合实例分析影响系统优化的因素”。 2.教学重点:系统优化的方法和一般步骤。 二、学情分析 进入系统的内容,学生的兴趣明显比前期活跃,显然系统分析的深入符合高二学生的智力发展需求。但是,学生在对某个系统的分析容易陷入原有的逻辑思维,而不能很好地应用系统的思想和方法分析和解决问题,不能很好理解系统优化的约束条件和影响系统优化的因素。因此,系统优化的约束条件和影响系统优化的因素成了本节教学内容上的难点。 三、教学目标 能结合生产生活中的实例,理解系统优化的意义,并能结合实例分析影响系统优化的因素。 四、教学资源准备 “技术与设计2”配套教具旋转木马30套(江苏南京宝高公司提供)、多媒体 五、教学流程 六、教学过程: (一)引入新课(系统分析,承上启下) 情景设置:有一个农夫带一条狼、一只羊和一筐白菜过河。如果没有农夫看管,则狼要吃羊,羊要吃白菜。但是船很小,只够农夫带一样东西过河。请你帮农夫解决难题?

学生:1、农夫带着羊首先过河,农夫回来; 2、农夫与狼过河,农夫与羊回来; 3、农夫搬白菜过河,农夫回来; 4、农夫与羊一起过河。 教师提问:说说你们对该系统分析的过程? 学生:问题的突破口在——狼与白菜能够共存!农夫、狼、羊、白菜和船组成了这个系统。系统中各要素是一个整体,都依赖农夫过河;最大的问题是“船很小,只够农夫带一样东西过河”和“没有农夫看管,则狼要吃羊,羊要吃白菜”的冲突。我们联系已知条件,做了一系列的分析实验,但是比较其他方案不能实现所有要素都安全过河。最后得出以上方案。 教师:你们的思维过程很有价值,很清晰。而且在系统分析的过程中抓住了系统分析的三大原则——整体性、科学性、综合性。 现实生活中,有很多产品在不断更新,系统在不断的升级。做任何事情我们都追求更好,希望投入尽可能少,回报越多越好。为了使系统达到最优的目标所提出的各种解决方法,称为最优方法。但是有很多复杂系统,实施方案五花八门、干扰因素四面八方,我们不可能的逐个比较权衡,或者漫无目的瞎蒙。因此我们有必要进行定性定量的科学分析,寻找系统最优值。 (二)新课教学 1.案例分析: 案例一:“农作物种植系统的优化——农作物间作套种” 槟榔林套种香草兰收益高

NC项目系统优化

年度末NC项目系统优化 NC用户年度末时往往是使用NC最频繁的时候,在这个时候效率问题便变得尤为突出,为了防止因为应用服务器配置,数据库配置不当而引起的效率问题,保证客户业务顺利进行,需要前方顾问在这个时间段做以下优化工作: 一:应用服务器 1:应用服务器中客户日常业务中一定要避免输出所有sql语句: 如果输出的话,会极大的加重应用服务器I/O的负载. 可以用setting工具中的是否输出sql语句选项,不选,然后点接设置按钮就可以屏蔽掉. 2:保证NC应用服务器启动参数设置正常: 查看启动文件startup中的-Xms 与-Xmx的值,与发版推荐或技术工作指导手册中推荐的值没有太大出入就行. 如果是NC3.0,可以在setting工具的最后一个面板中获取对应端口中间件的内存使用状况,可以跟踪实际使用中内存是否会存在瓶颈. 3:对于widows操作系统:操作系统尽量干净。 不要安装DNS系统 不要安装盗版防火墙软件 在应用服务器上尽量不要安装数据库系统 每周重启一次 4:应用服务器中NC中间件设置自动重启功能。 通过设置NC应用服务器每天自动重启来提高NC应用服务器响应的效率. 如果是NC2.3与NC3.0,可以用NC中commander命令来进行设置. 注意:避开NC中自动任务批处理执行时间 (1):用commander.bat(commander.sh)中的clock命令可以设置自动重启定时。只要中间件监控进程没有断掉,设置的自动重启定时就不会销掉。(注意,设置后,除非监控进程断掉,否则自动重启定时无法取消) (2):还可以在./ierp/bin/clock.properts中设置是否默认启动自动重启定时,以及自动重启定时的时间。 ### 设置服务器重启闹钟 ### 闹钟时间 clock = 00:00 ### 是否启动闹钟 enable = false 如果enable设置位true,则启动中间件时监控进程会默认启动自动重启定时。时间位clock属性对应的时间。注意该时间不能为00:00,否则默认为不启动闹钟功能。 5:定时轻理NC中的日志

道路系统交通改善优化设计

摘要 随着社会经济的发展、城市化进程的加快和机动车辆的迅猛增加,城市交通问题日益严重。城市主干道是城市交通的主要承担者,因此对城市主干道的交通组织优化研究是缓解和改善城市交通的主要内容。 论文以城市主干道为研究对象,对城市主干道交通组织优化中最主要的交通渠化和交通信号协调控制两个主要方面做若干研究,分别从空间和时间上实现主干道交通流的合理、有效、快速通过。本文首先对主干道路段交通组织,包括路段行车道组织、行人过街组织、公交组织、路段车速组织等交通组织进行深入分析,给出了路段交通组织优化流程。 城市道路交叉口是城市道路网络的节点,交叉口的交通流如果不能很好的理顺,就会成为主干道路的瓶颈。论文首先分析了交叉口交通特点,通过对交叉口渠化方法特别是信号交叉口的渠化分析,得到可以通过对交叉口进行时空结合控制的优化思想,来减少交叉口处的交通冲突点,提高路口的通行能力和交通安全性。 本次我的毕业设计课题是由重庆交通大学交通运输学院交通信息与控制专业下达的毕业设计任务书中给出,对菜袁路进行交通组织优化,主要是分析交通流量,渠化交叉口和信号配时,合理设置标志标线等交通工程设施,来缓减交通拥挤、保障交通安全与畅通、降低对环境污染和节约能源,实现安全、畅通、高效及其与环境的协调适应的交通状况。 关键词:城市主干道,交叉口,交通组织优化,交通渠化,信号协调控制 - 1 -

ABSTRACT Along with the increasing development of social economy and urbanization, the urban traffic problem has been put outstanding. Urban arterial road is the main un-dertaker of the urban transportation. Therefore, the study on the traffic organization and optimization should be the major course in solving and impr-oving the urban traffic problem. The dissertation catches the urban arterial road as studying object, makes some researches on the urban main road traffic organization and optimization from two aspects, traffic channelization and traffic signal coordinated control. Firstly, the paper makes a deeply analyses on the traffic organization in main road segment, including the linking section of intersection and roud segment, the roadway, passingstreet for pedestrian, public transportation and road speed. Then,the optimized route guidance prodance procedure for segment traffic is offered. As the node of city road net, intersection would be a bottleneck if its traffic fow not be put in order. Analyzing the traffic charateristica of intersection especially the channelization of signalized intersection, the thesis gives the control idea that colli-sion can be deceased and the capability and security can be improved by combining space with time at intersections. The subject of my graduation from the Institute of Traffic and Transportation, Chong qing jiao tong university traffic information and control graduate design tasks assigned by the book is given on the Cai Yuan Road of traffic organization optimi-zation, mainly analyze the traffic flow, intersection and highly channelizing signal timing, setting up reasonable sign and marking, transportation engineering facilities to ease traffic congestion, ensuring traffic safety and expedite, and reduce environ-mental pollution and energy conservation, realize safe, expedite, efficient and coor-dinate with environment to traffic condition. Keywords:urban arterial road, intersection, traffic organization and optimi-zation; traffic channelization; coordinated signal control

系统优化及合理化建议

第九章合理化及系统优化建议为了使本工程能够更顺利、更完美地完成,达到更理想的施工效果,同时能够节省项目成本,我司组织了一大批富有理论知识,同时,又具有丰富施工技术经验的技术人员对图纸进行了深入的探索和研究,并对现场情况进行了考察,提出了一些浅显意见,供业主、设计院、监理单位各方专家参考。 第一节系统优化的内容 系统优化的内容包括:对系统的流程进行优化;对系统设计的参数进行校核;对重点区域管线的走向进行调整和重新布置;对原有施工图纸中的错漏进行补正;对设备材料的选用提供建议。 作为施工单位系统优化的重点在于:对重点区域管线的走向进行调整和重新布置;对原有施工图纸中的错漏进行补正;对设备材料的选用提供建议。 第二节对系统流程的优化 1.建议在水池入水管加装一个止回阀,水池顶加装两处DN150透气管。 2.图DS-10 :地下室管井前室未设计照明,建议补充。 3.防雷接地系统 本楼现状如下: (1)本楼前临大海,后靠山坡,地处强雷击区,建筑物Y形、狭长布局,极易引雷; (2)再加上是旧楼改造,原有防雷引下线结点远远不够,据现场勘察,现场仅有4,5个引下点; (3)现改造为超5星级标准酒店,对大楼外部装饰要求高,需避免对外部

装饰、土建结构较大破坏; (4)超5星级标准酒店的对安全性要求高,应按二类防雷建筑物要求设计。 因此建议: (1)防雷系统采用国外进口的长效、提前放电的防雷系统产品:要求在国外普遍使用成熟的及在国内一些重点建筑上使用过的,保护范围大、构造简单、安装维护方便,运行费用低,效果须充分满足本地、本楼要求。 (2)据我司在珠海的类似经验,在和记黄埔的珠海唐家湾海怡湾畔会所设计安装2支法国依丽达针形防雷系列产品,使用4年,效果非常好,本小区频繁雷击,独有会所区域安然无恙。建议本楼使用1~2支法国依丽达防雷系统(银色针形),或英国E.F.公司SYSTEM3000防雷系统(金色半球形)。 (3)接闪器装置在电梯机房顶,不锈钢支架支撑,支架高2m*口径φ40;引下线用50mm2铜轴电缆通过电梯井引下至室外专用接地极,室外接地极用多条2m长铜棒连接制作,接地电阻小于1Ω。 (4)重新设置完整可靠的等地位接地系统。 (5)末端动力回路、照明回路、插座回路分开设置,末端动力和照明回路设置300mA/0.2s,100mA/0.1s的漏电保护装置,插座回路设置30mA/0.01s的漏电保护装置。 第三节对系统参数的校核 1.通过校核及我司经验,建议:集粪井及集水井中排污泵单出口排水段采用DN65管。

电力调控运行系统优化的必要性与改进措施 李远发

电力调控运行系统优化的必要性与改进措施李远发 发表时间:2018-01-30T17:28:44.400Z 来源:《电力设备》2017年第28期作者:李远发[导读] 摘要:当前,随着我国经济的快速发展,人们对电能的需求量越来越大,电网数量也随之增多,电网结构也就越来越复杂,为了保证电力系统的稳定、安全运行,就需要加强电力调控系统的优化,只有通过对电力调控系统的优化,才有利于电力系统效率的提高,并且对电力系统调度和运行也具有非常重要的保障作用,进而提升我国电力系统运行的安全性和可靠性。 (国网江西省电力公司大余县供电分公司江西大余 341500)摘要:当前,随着我国经济的快速发展,人们对电能的需求量越来越大,电网数量也随之增多,电网结构也就越来越复杂,为了保证电力系统的稳定、安全运行,就需要加强电力调控系统的优化,只有通过对电力调控系统的优化,才有利于电力系统效率的提高,并且对电力系统调度和运行也具有非常重要的保障作用,进而提升我国电力系统运行的安全性和可靠性。本文相关内容可供行业人员借鉴参考。 关键词:电力调控;运行系统;优化措施电力调控系统的应用不仅提高了供电水平,同时提高了电力企业的工作效率,使电力企业投入更少的人力和资金情况下为用户提供更好的电力服务,提高了电力企业的经济效益。目前我国的电力调控系统正在向智能调控方向发展,这对于电力企业来说既是一个难得的机遇,也是一个严峻的挑战。现阶段,我国的电力调控运行系统仍然存在一定的问题阻碍电力行业的发展,因此对电力调控运行系统优化方法的研究具有重要的现实意义。 1. 电力调控运行系统的优化原则 1.1开放性 优化后的电力调控系统具有开放性,能够及时准确的好而其他电力调控机构建立联系,实现信息共享,避免信息杂糅和信息冲突造成的信息遗漏失误,在开放性的电力调控系统中,有效的加强电力系统的管理,提高该系统的兼容性,也给电力工作带来便利,提高电力工作者的工作效率。 1.2可扩充性 计算机网络的快速发展,为电力行业的发展提供了更多的可能,在网络规划不断扩充的趋势下,需要充分体现出电力系统的可扩充性。当系统优化完成后,要能够适用未来不断发展的信息技术,以便于向新技术进行平稳地过渡。 1.3实用性 进行系统优化后,保证原有设备的正常运行下,对系统进行优化升级,尽量满足电力行业的时代发展,对电力资源有效的整合和利用,节省企业的成本开支,创造相关经济效益。当然,在对电力系统进行优化升级时,一定要遵循安全、有效的原则,实现管理过程的智能化,有利于后期对电力调控运行的维护和再度升级。 2. 电力调控运行系统优化的必要性 2.1确保整个电力网安全运行 电力网的组成复杂,且规模较大,途径许多变电场所和发电站,还有非常多的电力用户,利用多种不同电压的输电线路相连构成电力网络,其对电能输送的要求非常严格。发电阶段、电力输送阶段及用户用电阶段的许多工作都要在短时间内达成,且发电机组出力与电力网承受的重量务必要确保彼此平衡,若想达成这个标准,电力调控运行系统是关键的组成因素。目前,电力调度运行体系和电力监督运行体系已经逐步向着智能化方向发展,电力调度工作人员可以越来越快速、高效取得电力网相关数据信息,且对电力系统实行监测和控制。与此同时,解决电力问题,更好的确保总体电力网中电能质量,保障电力网的正常工作。 2.2确保电力网的供电质量 电网的持续进步,电力调控运行系统也越来越复杂,导致电力网的供电质量很难得到保证,且用户用电的安全稳定均需要电力调控运行系统来保障。电力网发生问题的时候,或出现操作不正确,极易发生停电故障,给电力用户正常的生产生活造成影响,还很可能对电力设备造成损害,导致出现安全事故。许多问题所造成的人员经济财产损失不可想象,除非达到电力调控运行系统的安全运行要求,方能真正预防电力安全事故的发生。 3. 电力调控运行系统应用现状的分析 3.1管理制度不够完善 电力调控运行系统,是新时期电力公司改革的新举措,是在电力管理系统中的新的管理模式,虽然极大的促进电力企业的发展,但是随着电力调控系统逐步运行,因为管理制度不够健全造成电力调控运行系统作用受限也是非常明显。电力公司针对调控系统,缺乏全面性和具体的认识,因此在制定管理制度过程中,大体沿用相关行业的管理经验,对电力企业运行中产生的问题并不适用,问题得不到有效解决,也阻碍电力调控系统的更新和发展。 3.2操作人员专业知识不足 我国的电力发展的现状来看,电力系统在建成后就会投入使用运行,这就造成了相关电力调控的管理人员未进行专业的知识培训进入职工作,甚至很多工作人员是被临时安排参与到电力调控管理当中,这就造成了电力调控系统在具体的调控操作中缺乏保障,而且,由于工作人员专业知识薄弱技能不足在具体的操作中存在安全隐患。在电力系统运行工作中,很容易表现出因人员操作失误导致的系统运行故障,不利于电力系统的稳定、安全运行工作。 4. 对电力调控运行系统优化的改进措施 4.1优化电力调控运行系统设计目标 电力调控运行系统牵涉面比较广,而且相互交错很是复杂,没办法进行整体的大规模的集中改进,所以针对电力调控运行系统的整体设计目标进行完善和优化,具有一定的可行性。具体要做的就是针对电力运行过程中的大的具体问题进行有效的改进,并将改进方案应用到电力调控运行系统中,一步步的磨合和逐步改进,增强系统设计目标的契合性,保证电力系统的平稳发展。在对电力运行系统进行整体设计时。确切到对运行状态下主接线图和监视设备的运作情况的设计和优化,收集系统在运行中的数据信息,绘制运行状态正常的动态发展图,有效的保证电力调控运行系统的工作人员工作顺利开展。 4.2完善电力调控运行管理机制和体系

清华大学最优化 10.12及第五周作业(1)

10月12日作业: ,,2 3345 2..23max )5(3213213213213 21≥=++-≥++≤-+-+-x x x x x x x x x x x x t s x x x 答案:max (0,2,0), 4f = ,,8 321 32..23min )7(321213213 21≥≥+=+-+-x x x x x x x x t s x x x 答案:min 8110,,9,33 f ? ?= ??? 第五周作业(1) 1. 给定原问题 ,,2 321 ..34min 3213213213 21≥≥-+≥+-++x x x x x x x x x t s x x x 已知对偶问题的最优解??? ??=37,35),(21w w ,利用对偶性质求原问题的最优解。 答案:41,,033?? ??? 2. 给定线性规划问题: 0 ,,1 26..215min 3213211 3213 1≥≥++≥+-+x x x x x x b x x x t s x x 其中1b 是某一个正数,已知这个问题的一个最优解为?? ? ??=41,0,21 ),,(321x x x 。

(1) 写出对偶问题。 (2) 求对偶问题的最优解。 答案:(2)119,44?? ??? 3. 考虑线性规划问题 min ..0 cx s t Ax b x =≥ 其中A 是m 阶对称矩阵,T c b =。证明若(0)x 是上述问题的可行解,则它也是最优解。 证明:对偶问题为 max ..wb s t wA c ≤ 因为A 是对称矩阵,且T c b =,所以()(0)(0)T w x =是对偶问题的可行解, 由于 (0)(0)cx w b =,所以,(0)x 是原问题的最优解。

电力调控运行系统优化的必要性及改进措施 刘景成

电力调控运行系统优化的必要性及改进措施刘景成 发表时间:2018-06-27T09:43:11.680Z 来源:《电力设备》2018年第6期作者:刘景成方志明黄丁婕朱云晶[导读] 摘要:我国人民生活水平不断提升,对于电力能源的需求量也在成倍地增加。 (国网福建省电力有限公司宁德供电公司福建宁德 352100)摘要:我国人民生活水平不断提升,对于电力能源的需求量也在成倍地增加。为了有效地改善我国用电量突增的情况,我国的电力行业在电网专业的设备建设上在不断的提升中,电网设备的增加就意味着电网的具体结构更加的复杂,做好对于电力调控运行系统优化提高电力调控运行系统的运行效率对于确保电力的安全、高效的供应是十分重要且必要的。 关键词:电力调控运行系统;优化;措施引言 随着时代发展,人们对电力系统运行的稳定性和安全性提出了更高的要求。电力调控运行,作为一种重要的电力系统监测、控制、管理的现代化手段,其目的是为了在保证电力供应的同时,提高对电网事故情况的应急处理效率和准确率,确保电力系统供应的安全稳定运行。 1电力调控运行系统优化的必要性 1.1操作专业性较差 操作专业性较差是促使电力调控运行系统优化的原因。众所周知,我国当前的电力系统发展已有了很大的进步,并建成了较为完整的电力调控系统,而且这一系统生产运行的可靠性也得到了较好的验证。但是需要注意的是,这一系统在实际的生产实践中操作专业性仍然较差,即电力调控运行系统运行的安全性能无法得到有效的保证,这就需要对这一系统进行优化。 1.2科学统筹电力系统分配 最大化满足用户用电需求是我们进行电力调控运行的主要目的。电力系统结构复杂,包括了发电、输电、变电、配电等诸多环节,在各个环节都有相应的监控信息和自动调控系统,从而保证了用电的安全性、稳定性和经济性。在电网迎峰度夏和迎峰度冬的电量供应不足时会出现“拉闸限电”的情况,所谓拉闸限电是一种电网宏观调整措施,指在电网发电机出力不能满足区域用电负荷要求或输变电设备承载力不够的状况下,通过调整负荷分布还是不能满足区域需求时,为保证电网和设备的安全,从而采用的人为切除负荷的方法。这种传统有效的电力调控运行方式保证了电力系统的科学稳定分配。 1.3安全性能需要提升 安全性能对电力调控运行系统来说非常重要。通常来说,在电力系统的运行过程中,电力调度往往属于应用系统的范畴。这意味着这一系统具有较高的实际运用性能和较为突出的实践性特点,因此,当电力调度系统处在运行状态的时候,工作人员往往会将注意力全都投入到应用功能的体现之上,但却忽略了系统整体的管理工作。这也是电力调控运行系统需要优化的重要内容。 2电力调控运行系统优化的改进措施 2.1电力调度运行系统的优化 电力调度运行系统可谓是电力调控运行系统中的重要组成之一,并且其功能较多,内容纷杂,为了使其多媒体语言报警功能,信息采集、处理功能,画面编辑显示功能和历史库管理功能等发挥更多作用,做好统计计算和安全管理等方面工作,需要通过适宜的方法对系统进行优化:一、对电力调度运行系统的设计目标进行改进。通过该优化方法可以使系统扩展性、扩充性有所提升,设计人员可将网络主站设计当作入手点进行设计,研发出更多优秀的软件程序,为电力调度系统运行的高效性及质量提供更多保障;设计过程中应对系统监视设备、主接线图方面的显示进行考虑,使系统能够自动完成数据信息的收集工作,做好数据存档工作,为运行曲线图绘制等方面工作的开展提供更多支持。二、秉承实用性、开放性及可扩充性原则进行设计。首先,对系统的实用性进行优化提升。系统的优化工作需要避免对原有设备、投资等产生负面影响,因此在优化过程中需要对成本及资源投入方面的问题进行考虑,在满足系统设计需求的同时对现有计算机及网络资源进行最大限度的利用,秉承安全、可靠的原则进行设计,将管理维护简单、性价比高的系统先行优化。其次,开放性的增强。优化系统时,需要对电力调度系统和其他系统信息资源共享及传递方面的问题进行考虑,通过简化复杂信息量的方式减少信息冲突问题的出现,并且在提高系统开放性的同时,能够对更多的内容进行兼容,为系统与外界操作平台对接、资源共享和利用等方面工作提供更多支持。最后,对系统的可扩充性进行优化。随着网络信息技术的普及发展,网络规划扩充变成了电力调度运行系统优化工作中需要重点考虑的内容,通过可扩充性设计能够使系统联网方案满足今后设备扩充等方面的需求,提高系统对日后信息技术的适应能力,确保调度系统中新老技术过渡工作顺利进行。 2.2优化系统网络框架 作为调控运行系统优化的关键环节,系统自动化设定中,针对主系统和副系统进行优化。对于电力调控运行系统远程工作站而言,该系统里的计算机可以通过其独有的综合设备对网络进行正确连接。对于系统网络框架而言,可以通过网卡、集线器设备等进行正确连接,在传输介质方面,可以使用八芯双绞线。对于比较分散、距离比较远的建筑物来说,这种组网布局,会给传输性能指标带来一定影响。所以,在设计网络框架时,应该结合工作站实际运行情况,应用不同方法,进而确保系统联网的稳定性。 2.3电力调控监控系统的优化 在我国电力调控系统运行的过程中,一套优质的电力调控监控系统非常的必要,因此电力调控监控系统的优化显得非常的重要。在对电力监控系统的强化以及优化的过程中首先要对监控系统的实时监控功能以及数据录入功能进行针对性的强化,在上述的基础上积极做好电力调控监控系统对于监控系统的自动化方面的提升,只有这样才能够有效的提升我国电力调控系统的监控能力,保障我国电力行业的电力调控的正常、稳定、安全的运行。 2.4提升专业技能,加强工作管理 电力调控运行系统实现最优化运行不仅需要从系统硬件着手,而且需要提高电力调控人员的专业技能。只有增强队伍的专业性,才能避免人为因素对系统优化发展造成的阻碍。在日常工作中,应该不定期举办电力调控运行系统知识讲座,武装员工头脑,提升调控人员专业技能。同时,在管理工作中,应该加强制度考核,设立奖惩体系,鼓励员工积极性,树立标杆榜样,达到以点带面的效果,全面提高从业人员业务水平。

相关主题
文本预览
相关文档 最新文档