当企业上线MES系统之后，仅仅是万里长征的开始，为什么要进行MES的优化？这是一个非常之现实以迫切的问题，众所周知，MES系统所运行的必要基础数据之外，MES系统每天还采集了大量的生产过程数据存放到数据库之中，其数据量大小，取决于如下几个方面：

A． 企业的生产规模。

B． MES管理的产品流程的数量

C． MES每流程上数据采集节点的站点数

D． 每站点数内部的数据采集内容

E．第站点上的数据采集的时间频率

F．第三方系统存放到MES数据库中的数据内容

随着系统的上线，数据量日渐增大，由最初的几个G，增加到100G甚至几个TB, 系统的性能，也随之而下降，同时还表现出如下的几个方面的弊病：

G．系统扫描相应变慢

H．系统报表查询变慢

I．看板等实时刷新程序无法正常执行

J．系统登陆时间过长

K．系统作业过程中停顿(卡，延时) 或死锁, 需重启服务器次数增多。

L．数据备份日渐困难。

以上问题不光是MES系统所特有的，所有的事务处理性(OLTP)性的数据库应用系统，都将面临以上的困扰。由于很多MES系统默认采用的是关系性数据库（SQL Server /Oracle），除少量计算在前端完成以外，系统中95%的逻辑运算都在DB层中实现，非常依赖于数据库服务器的性能， 所以，当MES系统表现不尽如人意之时，首先需要在数据库后台进行必要的数据优化，完成后基本上就能取得相应的性能提升，说明如何针对DB层进行深度的优化：

wise-MES后台优化包含的内容如下：

1.合理的表以及逻辑关系的设计；

2.数据库的日常维护工作；

3.数据库大数据量表的数据压缩；

4.数据库大数据量表的分区表方法；

5.历史数据的定期迁移；

6.合理的负载部署，服务器的分工；

7.服务器硬件性能的提升；

 以下以最常见的表结构与逻辑关系的设计的优化为例子加以重点说明：wise-MES系统表以及标准模型表，以及相关逻辑（存储过程）是在系统平台的设计阶段已定决定，并且经过了相当多的实践，其性能相对稳定可靠，靠此部份的优化以提升系统整体性能的收益不大，效果也不太明显。

系统在实施周期时根据客户所定制的表，以及存储过程，特别是新上线的功能插件所对应的存储过程，将有比较大的优化余地， 在这类业务表的设计时，应注意如下方面：

A.遵守业界通行的数据库设计的标准范式（至少前3个范式尽可能遵守）

B.遵守wise-MES建议的主键定义方法，以及字段命名规则

C.合理的设计表的冗余以及关联，区分事务处理表（大表），以及基础数据表(小表)。

D.合理设计索引，特别是经常用于查询的表的索引（产品表，工单表, Lot表等），对于大表只创建必要的索引。

E.对于第三方测试数据表，采用分库或分服务器的设计方案，不要放到MES主数据库中。

F.一切新表的设计，应以性能为首要考虑因素

业务逻辑（查询或存储过程）设计时时，应注意如下方面：

A. 所有的内部查询应基于主键PK

B.避免在一个大的SQL中采用一次性连接多个表的查询 (特别是大表对大表的关联，是非常不明智的)，应拆分为基于PK的多步来执行查询。

C. 避免使用大的事务包裹业务逻辑，事务应尽可能短小，否则容易占用服务器资源导致排队甚至死锁。

D. 少用游标，绝不要针对大表使用游标。

E.Select查询时尽可能使用 With (no lock) 语句，避免占用锁的开销，在每一个存储过程中加入：SET TRANSACTION ISOLATION LEVEL READ UNCOMMITTED ,以降低死锁的可能性。

F.Insert最好以批量方式执行，一次性处理多条新记录。

G.Update应基于PK为条件，避免使用复杂的Where表达式, 导致表锁。

H.一切有利于减少死锁，提升性能的逻辑设计为首要考虑因素。

事实证明，频繁的死锁往往出自于不合理的业务逻辑设计，故在进行wise-MES的客户化功能的数据设计时，应仔细权衡，以性能为先导，才能取得相对较好的结果。

当数据库服务层的优化进达到一个相当高的水准之后，企业的还需要考虑后续的一些优化过程，比如大数据的定期归档，提升网络以及服务器本身的的IOPS性能等等，进行深度的负载均衡的设计，在这方面，不同的MES厂商水平参差不齐，所以选型MES时，请注意一定不能有“运维优化黑箱”，候选的MES系统所有的数据资产必须全方位向甲方开放，同时还需要提供专业的瓶颈定位工具以及优化工具，它必须是一个“可高度优化的MES”, 否则企业将会为此付出极为沉痛的代价。

只有从源头加以及分析与优化，才能让你的MES系统“健步如飞”。