A. 数据库设计的重要性
原创点经验吧，好的数据库设计有下面的一些作用，下面说的都是关系型数据库。
1、首先充分体现系统的需求，数据库是为应用服务的，好的数据库设计应该首先能满足应用系统的业务需求，准确的表达数据间关系。
2、保证数据的准确性和一致性，通过主外键、非空、限制、唯一索引等保证数据的健壮。
3、提高数据的查询效率，通过合理表结构，安排物理存储分区、增加索引等方式，提高数据的读取速度，提高查询效率。
4、有好的扩展性，在必要时能根据需求扩展数据结构。
B. 中国建设银行用什么数据库
核心系统（core banking）应该用的是DB2，但外围应用有别的数据库，比如网银好像是oracle。
C. 简单的银行叫号系统 C++编程
编程是好比是两个城市之间的旅程，开发语言（C++）就好比是交通工具，其实乘坐什么工具并不重要，最重要的是你要知道怎么走，也就是整个程序的设计你要明了。废话少说，下面简单介绍一下这个系统的开发流程：
第一步，先把数据库设计好，如果是单个银行网点，可以用ACCESS或者sqllite数据库，如果是某个银行集团的多个网点，那就需考虑用大型数据库了，比如Microsoft SQL Server;
数据库中最起码要包含以下几个表：
1，业务类型表：
2，取号类型表（普通号、优先号）
3，挂号表等
第二步，搭系统框架，这个是整个程序的基石，如果如果要自己设计的话，首先你要有两三年的编程经验，急不得。你可以去网上或者是学长那找一些好的模板，这样会快一点。
4，画界面
整个程序的界面包含主界面和一些基本数据的维护界面以及统计报表等，这个需要你一步一步去画。
5，基本的增删改查数据库操作
界面画好之后，就要对基本数据进行处理了，程序的许多BUG也会在这个时候产生，这个也是基本功，祝你好运。
6，数据的增删改查做完之后整个程序的开发也就完成的差不多了，剩下的就是一下细节性的东西，不过此时你的旅途只完成了一半。
7，还有一半的工作就是测试测试再测试
若还有疑问，咨询HESIN排队。网络HESIN排队就可以。
D. 什么是银行的数据大集中，为什么要数据大集中呢
简单地讲，大集中就是将分布在各个分支机构和营业网点的业务数据及其他一些相关的数据实现集中。事实上，大集中是依靠科技手段，实现数据的集中和数据的整合，并通过对数据深层次的挖掘，对银行的客户数据、业务数据进行系统分析和评价，推动商业银行向决策科学化方向迈进，提高银行的管理水平和工作效率。
60年代，自IBM发明了第一台商业计算机系统后，IT开始从无到有，以一种置于玻璃房的主机挂终端的形式起步发展。从80年末期到90年代初期，由于较低的附加开销、较低的劳工费用，使整个工业界的趋势走向分布式及部门式管理。为了加快对市场的响应时间，对IT应用系统开发的速度提出了更快的要求，因此IT的体系结构从原来单一集中式模式，走向分布式模式。并且逐步演变成难以控制的分散式架构。经过几年实践证明，在这种分散式模式下，带来许多负面效果：
1)降低了IT的效率
＊分散的数据
＊分散的技术力量
＊机器，软件系统资源不可共享
＊管理水平的不平衡
2)支持及管理人员的增加
＊艰难的整体规划
＊艰难的整体管理
3)缺乏标准化
4)增加数据安全性、完整性的风险
5)软件需要分散的重复投资，软件及维护费用急剧上升
6)计算机硬件资源利用率低，众多的计算中心均需自备备份主机及相应设备，无法公用机器的“白色空间”(及空置的CPU资源)
7)更困难的财政及固定资产管理
8)企业内部无法形成数据集中及应用集中，因此无法快速有效地为企业整体的经营管理者提供管理辅助信息。
9)无法承受灾难备份的投资，在众多的分散中心的条件下，实施相互灾难备份的费用非常庞大，其管理及运作是及其艰难的。
面对这些挑战，IT的管理者自然要问：
＊怎样更好地支持、管理网络、软件及服务器？
＊怎样更好地控制投资回报？
＊怎样有效快速地分析业务数据？
＊怎样集成分布式应用及数据？
＊怎样将传统的应用面向电子商务的同时，又能保证关键应用的高可用性及安全性？
大集中就是在这种背景下产生的。总结国外IT业的集中方式，无非可以分为以下四种形式的集中：
1)管理运作的集中：即将分散式的IT体系结构，用集中式管理模式进行运作。
2)物理集中：即不改变任何应用体系结构，仅仅将运作在多个服务器上的应用集中在一台或多台集群式系统内，从而减少了服务器的数量及种类，可共享系统资源，但客户数据可能依然是分散的。
3)数据集中：可以使用存储技术，实施数据的集中存储及管理；或通过一定的共享软件机制，实施数据的集中共享。
4)应用的集中：真正可以做到与业务集中相匹配的应用集中，及客户关键业务信息的数据集中。
不同程度的集中，会产生不同的效果，投入及工程的复杂程度也不尽相同。在大集中项目中要考虑许多技术因素，但最最关键的是高层领导的重视及支持，及业务部门的介入。
大集中可能会引进对当前IT体系结构的重组(reengineering)，因此需从以下几个方面考量其系统的设计：
首先集中决不是单纯IT的技术问题，为IT集中而集中是无效之举。集中必源于业务的改革，必带来业务流程的改变。其最终目的是提高企业整体的运作及管理效率并带来最大利润。
次之，集中必带来对应用体系结构的重新评估，可能带来应用的调整甚至结构重组。
在设计大中心系统时，要有端到端的全局体系结构设计观念。即从客户端经由底层网络到前端机，经由骨干网络到大中心服务器，其整体结构要具有端到端的高可用性及可管理性。
大中心的整体设计考量因素为以下几个方面：
1)应用的考量：
在多层次的系统架构中，各类应用在何层服务器上运行，应用的功能如何分布。要不断评估何种应用要进行集中，何种应用具有地区的特性，需要分布式运作。
2)企业核心信息数据库的考量：
核心企业信息如何存放。只有形成了一个逻辑的统一的企业信息数据库，才可以充分享受到集中的优势。
3)整体系统性能考量：
由于集中将所有的核心业务运行在一个集中的系统上，客户的服务业务量呈爆炸式增长，虽着电子商务的发展，BTB、BTC系统的建立，将每天都需要面对大量来自外界的数据访问和交互式操作，所有这些需要大中心系统具有持续且稳定的响应性能。
4)系统的可扩展性的考量：
大中心系统必须具有很好的可扩展性及成长的能力。中国是一个人口众多的国家，因此大型企业的客户数量是惊人的。中国许多大型企业所服务的客户数大于任何一个北美或欧洲的大型企业。以银行为例，中国四大商业银行的客户帐号数均达上亿，因此其企业客户核心信息数据量将达到几十个GB甚至为几十个TB的数据量。因此数据库、中间件、服务器及存储系统均需要具有优秀的可扩展性。除了应付爆发式的数据存储需求，基础设施还需要应付短时间内访问高峰的冲击，并提供足够的灵活性对信息有效的管理。
5)高可靠性及高可恢复性的考量：
企业需要考虑为客户提供每周7天、每天24小时的不间断服务。同时，基础设施必须为以不同方式接入的用户提供同样的易用性，以及在异构系统之间进行快速的信息查找和交换的应用灵活性，并保持系统能够以很快的速度得到扩展。
6)冗灾备份及恢复能力考量：
灾难备份方案绝不是一个单纯的技术方案，并且灾难备份也决不是一个数据远程拷贝的方案。它必须基于应用的考量，并外加业务备份规划。从技术角度考虑，级别越高则备份的能力越高。方案的选择必须立足于业务的需求，级别越高的备份方案，其项目实施总成本则越高，因此必须基于商务的承受能力进行方案的选择。
7)端到端的系统管理：
集中后的系统管理将比分布式小中心的运作显得尤其重要。在小型中心中，通常靠个体的手工管理，当实施大集中后，手工的、无系统化的管理将无法提供所需要的服务水准。因此必须建立可以集中观测、集中管理的系统，但同时又可以分级进行控制、维护的体系结构。由于应用的集中运作，因此建立帮助平台及严格的变更管理体系尤为重要。
8)系统安全性考量：
企业需要保证系统和数据的安全性。需要考虑安全性的不仅是系统设备，还有设备提供商的实际能力。企业需要选择可信赖的合作伙伴和供应商，在基础设施系统的管理能力和数据安全方面都要有出色表现。安全可靠的系统不仅能保证前端与后端的系统安全，还需要确保服务器与应用程序的防攻击能力。
9)投资保护及降低业务风险：
大集中体系结构是在现有的IT体系结构之上进行再造的过程。体系结构方案必须考虑对现有的IT技术、设备的投资加以保护。甚至包括对应用投资及技术人员投资的保护。在设计和构建基础设施的过程中，大中心方案不仅仅要着眼于当前的需求，更要放眼于未来的业务发展需求，本着节约成本、保护投资的原则，优化、整合和利用旧系统的资源，使大中心体系结构具有前瞻性。
大集中项目是一个逐步演变的过程，我们不可能在一日之间废弃旧的体系结构，建立新的体系结构。在建设过程中需要保证与原有系统的成功整合，保证公司和顾客数据的安全性，降低整体风险。在由多种平台和技术组成的异构环境中，大集中项目必须实现新系统结构与原有系统的平滑转换，这要求有严格的项目规划和项目管理。
10)总体成本考量：
成本效益永远是要考量的因素之一。与分布式环境相比，数据中心集中可以节省总体IT成本。但是要注意的是，在向集中过渡的过程中，必须重视新型应用的投资。所有IT的投资都不应偏离未来集中的大方向，以避免投资浪费。
分布式的信息技术结构是历史的原因造成的，它在当时是最佳的选择，并且也是中国IT发展必经之路。面对未来WTO的挑战，许多企业开始重视规模化经营。为了在竞争中生存并超越对手，IT也必然需要采用高度的集中和可管理的结构。它也是内部业务集中管理的必然要求，大集中不只是一个技术上的项目，除了它的高科技含量外，它是一个强有力的、策略性的业务项目，它是中国银行业发展所面临的一个挑战。
E. 数据库高手请进——关于银行储蓄系统问题
....要是设计好了,就可以自己开银行
F. 银行如何建设企业级数据库基础逻辑数据模型
前言:逻辑数据模型LDM是一种图形化的展现方式，一般采用面向对象的设计方法，有效组织来源多样的各种业务数据，使用统一的逻辑语言描述业务。借助相对抽象、逻辑统一且结构稳健的结构，实现数据仓库系统所要求的数据存储目标，支持大量的分析应用，是实现业务智能的重要基础，同时也是数据管理分析的工具和交流的有效手段。 需要强调的是，数据仓库逻辑数据模型特指数据仓库系统的核心基础模型，在搭建企业级数据仓库系统时，需要充分了解和分析种前台业务处理系统和应用，在此基础上进行有效的重组和整合，为各种分析应用(如客户关系管理、风险管理等)提供单一的、整合的数据基础，保证全行不同业务部门从不同的视角都可以使用统一的数据实现各自的分析需求。——担负这种数据重组和整合任务的数据模型称为数据仓库系统的“基础逻辑数据模型”。 基础逻辑数据模型建设好之后，银行可根据不同的分析应用需要(如客户关系管理、绩效考核、风险管理等)，根据应用产品和功能设计不同的分析应用模型，包含具体的、特定的分析逻辑，往往这种模型中都含有较多加工处理的成分。——这种为实现特定用途而设计的数据模型称为数据仓库系统的“应用数据模型”。 因此，不夸张地说核心基础数据模型建设的成败性会影响到整个数据仓库系统的建设乃至后续各种分析应用，应引起银行科技建设和业务分析人员的高度重视。 本文尝试从银行建设基础逻辑数据模型的角度出发，分析、探讨建设过程中应该考虑的主要因素、建设的方法以及注意的问题。 一、整体规划、明确目标、合理定位 银行建设数据仓库系统时应充分明确建设目标，核心的逻辑数据模型是对银行业务的高度抽象、能够提供对关键业务数据的组织和整理，建立一套完整、统一、规范的标准，以便进行各类分析。一个好的核心基础数据数据模型应该满足以下条件: 概念上:具有高度抽象的、中性的、可共享的的概念，可有效、全面、完整地适应与涵盖银行现有的业务范畴以及数据范围;不针对某个特别的应用而设计; 结构上:应是稳定的、灵活的、可扩展的;能以满足第三范式的方法构建模型，存放最详尽的数据，保证足够的灵活性，适应复杂的实际业务情况，在业务发生变化或者新增数据源时易于扩展;核心结构在很长时间内应保持稳定性，便于回答不断产生、不断变化且无法预先定义的业务问题; 表现形式:应是规范的，易懂的;包括各类命名规范，业务规则定义，度量方式等。使用统一的业务语言进行模型设计，易于业务人员的理解和使用;也有利于IT部门和业务部门人员的沟通; 数据仓库系统的建设目的和方法不同于传统业务系统，其开发建设方式也有所不同，它的建设绝不是一蹴而就的事情，不能期望一朝一夕就可以全部完成，比较成熟的建设步骤应该是分阶段实施，逐步进行完善和增强因此作为项目起步的LDM建设对于规范和推动整个数据仓库系统的建设都将起到一个很好的促进。整个建设过程最关键的阶段就是项目的最初阶段，应将工作重心放在搭建模型框架、建立模型设计思想和培养模型设计人员三个方面。 明确了建设目标，具体实施应该如何开展呢? 二、审慎选择、量体裁衣、度身定做 银行在明确建设目标之后，如何选择具体的实施策略、制定设计的阶段和步骤呢?常见的主要有以下两种: 第一种:自主研发:银行根据以往的业务经验提炼本行业务的关键主题;再设计出本行的概念模型;然后通过具体的业务反复论证，同时考虑将来的分析需求进行基础逻辑数据模型的详细设计。 这种方法可以快速启动，完全依托本行的业务元素和规则，使用行内技术人员和业务人员比较熟悉的语言进行模型的设计，具有很好的适用性。但是整个建设周期比较长，同时往往由于经验不足等原因给项目带来一些不可控的风险，由于参与人员经验的不足，不能够站在全行的高度，从管理分析的角度去理解所有的业务以及相应的数据，造成一些局限性。 第二种:依托业成熟产品进行客户化:银行研究不同的业界模型产品，从中选择一个作为蓝本，结合本行的业务数据和应用系统进行具体的定制化。 这种方法的建设周期短、风险小，同时也能够很好地借鉴成熟的逻辑数据模型中蕴涵的经营管理理念。但是银行需要研究和比较多个业界流行的逻辑数据模型，熟悉各自的设计思想和理念，并从中挑选一个适合本行的模型产品进行客户化。 从国际、国内商业银行建设数据仓库系统的经验和案例来看，为了保证项目的成功实施，避免和控制项目风险，他们几乎都选择了第二种方法:客户化。那银行在面对众多逻辑数据模型产品进行选择的过程中主要应该都关注一些什么样的内容呢? 产品层面: 覆盖范围:模型产品应能够适合、涵盖银行的所有业务范围，可以在单一模型中能支撑金零售银行、公司业务、保险、信用卡、经纪、证券和电子商务等，满足未来混业经营的需要; 对业务发展的适应性:模型产品应有高度的概括和归纳，既满足范式化要求，又具有足够的灵活性，在扩展业务、新增品种或改变规则时，模型通过简单的调整和扩展即可适应; 对应用的支撑和扩充:模型产品不应偏向某个部门或某些专业的特定应用，要能够支持绩效管理、客户关系管理、资产负债管理、资金财务管理、风险管理等应用，并与国际金融业完全接轨，从数据接口层面支撑业界监管需要; 模型的开放性:模型产品应有清晰、严谨的模型架构，满足模块化和结构化的设计要求，真正实现数据一次导入，多次使用; 转化成物理数据模型的方便性:LDM设计完成，进行一些物理化的定义之后就可以直接利用建模工具平滑地完成物理模型设计。 服务层面: 客户化方法与能力:逻辑数据模型必须有经过实际项目验证过的客户化方法论做指导，明确严格的工作步骤、流程、任务分配，并提供必要模板; 业绩经验与表现:应具有国际化大型(特别是国内)商业银行相关项目和领域的成功实施案例;在行业内具有良好的信誉和业绩; 全球支持能力:全球专职研发团队——各国家地区的具体实施团队;高级建模顾问——高级金融行业顾问; 不难看出，上述这些考核的方面都是和将来的实施密切相关的。的确，一个成熟的优秀的模型产品，如果没有得到成功的实施，最终也不能为银行创造效益。下一部分主要讨论在实施过程中的关键因素。 三、关键成功因素 (1)参与人员的业务经验 LDM的设计和实施不是一个纯粹的技术问题，需要参与人员具有较高的银行业务修养和素质，设计人员应能够凭借丰富的业务经验和知识，将散落在各种不同业务系统以及日常经营管理中的各种数据元素进行高度的抽象和概况，形成本行的几个主题域(如当事人、协议、产品、事件等)，用以清晰地表达业务逻辑和关系。同时，他们也必须时刻以目标(建设数据仓库系统)为导向，有选择地从前台业务系统中抽取相关的数据信息进行映射。 (2)设计团队的沟通机制 逻辑数据模型的设计过程本身就是一个不断发现问题、解决问题的过程，不可能某一个人就能够掌握庞杂银行业务中的点点滴滴，因此需要整个项目团队的密切配合。每个设计人员都必应具有良好的学习沟通能力，能够对建模工作达成共识，根据所定义的结构，将具体的业务数据映射到模型中，同时进行一些修改和校正。 (3)银行内部IT管理的水平 LDM设计过程中很大量的工作都是对现有业务系统的分析，包括对系统架构和功能的梳理、业务规则和关键业务元素的提炼、系统之间的逻辑关系等，并结合样本数据初步了解数据质量。如果没有一套有效的管理模式和有力的技术支持，如果没有现有业务系统的完备资料;如果没有快速问题反馈和解决机制，LDM的建设只能是空谈，因此这给银行内部IT管理水平提出了很高的要求。 (4)模型的管理和维护 在LDM整个建设周期内还应高度重视维护和管理工作，必需有严格的建模技术规范做指导和约束，包括命名、描述、版本控制等。随着时间的推移和项目建设阶段和目标的变化，为了使建成的基础数据模型具有持续的生命力，应在建设的所有阶段把涉及的建模规范内容文档化并强制执行;在人员发生变动时规定新参与人员应严格遵守这些规范，不能另行编制，保证前后的一致性。 总结: 尽管LDM仅仅是一个逻辑的概念，数据仓库系统需要在逻辑数据模型的指导下，进行真正的物理实施，将把分散在不同平台、以不同方式组织的各种业务数据以及部分外部信息经过清洗和转化，在保证数据一致性、准确性和实效性的前提下，开发各种应用，奠定实现银行商业智能的重要基础。 但是可以看到，通过数据仓库系统逻辑数据模型的设计，将有利于对银行现有业务过程的全局认识和系统把握，同时还能够从整体上对全行使用的操作型业务系统进行回顾，从而提供改造和完善的建议，最终探索出一条符合银行自身业务实际发展要求的分析型应用系统的道路，为数据仓库系统的建设奠定坚实的基础。
G. 数据库设计过程中，对于大批量的数据如何进行数据库优化
实例讲解MYSQL数据库的查询优化技术
作者：佚名 文章来源：未知 点击数：2538 更新时间：2006-1-19
数据库系统是管理信息系统的核心，基于数据库的联机事务处理（OLTP）以及联机分析处理(OLAP)是银行、企业、政府等部门最为重要的计算机应用之一。从大多数系统的应用实例来看，查询操作在各种数据库操作中所占据的比重最大，而查询操作所基于的SELECT语句在SQL语句中又是代价最大的语句。举例来说，如果数据的量积累到一定的程度，比如一个银行的账户数据库表信息积累到上百万甚至上千万条记录，全表扫描一次往往需要数十分钟，甚至数小时。如果采用比全表扫描更好的查询策略，往往可以使查询时间降为几分钟，由此可见查询优化技术的重要性。
笔者在应用项目的实施中发现，许多程序员在利用一些前端数据库开发工具（如PowerBuilder、Delphi等）开发数据库应用程序时，只注重用户界面的华丽，并不重视查询语句的效率问题，导致所开发出来的应用系统效率低下，资源浪费严重。因此，如何设计高效合理的查询语句就显得非常重要。本文以应用实例为基础，结合数据库理论，介绍查询优化技术在现实系统中的运用。
分析问题
许多程序员认为查询优化是DBMS（数据库管理系统）的任务，与程序员所编写的SQL语句关系不大，这是错误的。一个好的查询计划往往可以使程序性能提高数十倍。查询计划是用户所提交的SQL语句的集合，查询规划是经过优化处理之后所产生的语句集合。DBMS处理查询计划的过程是这样的：在做完查询语句的词法、语法检查之后，将语句提交给DBMS的查询优化器，优化器做完代数优化和存取路径的优化之后，由预编译模块对语句进行处理并生成查询规划，然后在合适的时间提交给系统处理执行，最后将执行结果返回给用户。在实际的数据库产品(如Oracle、Sybase等)的高版本中都是采用基于代价的优化方法，这种优化能根据从系统字典表所得到的信息来估计不同的查询规划的代价，然后选择一个较优的规划。虽然现在的数据库产品在查询优化方面已经做得越来越好，但由用户提交的SQL语句是系统优化的基础，很难设想一个原本糟糕的查询计划经过系统的优化之后会变得高效，因此用户所写语句的优劣至关重要。系统所做查询优化我们暂不讨论，下面重点说明改善用户查询计划的解决方案。
解决问题
下面以关系数据库系统Informix为例，介绍改善用户查询计划的方法。
1．合理使用索引
索引是数据库中重要的数据结构，它的根本目的就是为了提高查询效率。现在大多数的数据库产品都采用IBM最先提出的ISAM索引结构。索引的使用要恰到好处，其使用原则如下：
●在经常进行连接，但是没有指定为外键的列上建立索引，而不经常连接的字段则由优化器自动生成索引。
●在频繁进行排序或分组（即进行group by或order by操作）的列上建立索引。
●在条件表达式中经常用到的不同值较多的列上建立检索，在不同值少的列上不要建立索引。比如在雇员表的“性别”列上只有“男”与“女”两个不同值，因此就无必要建立索引。如果建立索引不但不会提高查询效率，反而会严重降低更新速度。
●如果待排序的列有多个，可以在这些列上建立复合索引（compound index）。
●使用系统工具。如Informix数据库有一个tbcheck工具，可以在可疑的索引上进行检查。在一些数据库服务器上，索引可能失效或者因为频繁操作而使得读取效率降低，如果一个使用索引的查询不明不白地慢下来，可以试着用tbcheck工具检查索引的完整性，必要时进行修复。另外，当数据库表更新大量数据后，删除并重建索引可以提高查询速度。
2．避免或简化排序
应当简化或避免对大型表进行重复的排序。当能够利用索引自动以适当的次序产生输出时，优化器就避免了排序的步骤。以下是一些影响因素：
●索引中不包括一个或几个待排序的列；
●group by或order by子句中列的次序与索引的次序不一样；
●排序的列来自不同的表。
为了避免不必要的排序，就要正确地增建索引，合理地合并数据库表（尽管有时可能影响表的规范化，但相对于效率的提高是值得的）。如果排序不可避免，那么应当试图简化它，如缩小排序的列的范围等。
3．消除对大型表行数据的顺序存取
在嵌套查询中，对表的顺序存取对查询效率可能产生致命的影响。比如采用顺序存取策略，一个嵌套3层的查询，如果每层都查询1000行，那么这个查询就要查询10亿行数据。避免这种情况的主要方法就是对连接的列进行索引。例如，两个表：学生表（学号、姓名、年龄……）和选课表（学号、课程号、成绩）。如果两个表要做连接，就要在“学号”这个连接字段上建立索引。
还可以使用并集来避免顺序存取。尽管在所有的检查列上都有索引，但某些形式的where子句强迫优化器使用顺序存取。下面的查询将强迫对orders表执行顺序操作：
SELECT ＊ FROM orders WHERE (customer_num=104 AND order_num>1001) OR order_num=1008
虽然在customer_num和order_num上建有索引，但是在上面的语句中优化器还是使用顺序存取路径扫描整个表。因为这个语句要检索的是分离的行的集合，所以应该改为如下语句：
SELECT ＊ FROM orders WHERE customer_num=104 AND order_num>1001
UNION
SELECT ＊ FROM orders WHERE order_num=1008
这样就能利用索引路径处理查询。
4．避免相关子查询
一个列的标签同时在主查询和where子句中的查询中出现，那么很可能当主查询中的列值改变之后，子查询必须重新查询一次。查询嵌套层次越多，效率越低，因此应当尽量避免子查询。如果子查询不可避免，那么要在子查询中过滤掉尽可能多的行。
5．避免困难的正规表达式
MATCHES和LIKE关键字支持通配符匹配，技术上叫正规表达式。但这种匹配特别耗费时间。例如：SELECT ＊ FROM customer WHERE zipcode LIKE “98_ _ _”
即使在zipcode字段上建立了索引，在这种情况下也还是采用顺序扫描的方式。如果把语句改为SELECT ＊ FROM customer WHERE zipcode >“98000”，在执行查询时就会利用索引来查询，显然会大大提高速度。
另外，还要避免非开始的子串。例如语句：SELECT ＊ FROM customer WHERE zipcode[2，3]>“80”，在where子句中采用了非开始子串，因而这个语句也不会使用索引。
6．使用临时表加速查询
把表的一个子集进行排序并创建临时表，有时能加速查询。它有助于避免多重排序操作，而且在其他方面还能简化优化器的工作。例如：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
AND cust.postcode>“98000”
ORDER BY cust.name
如果这个查询要被执行多次而不止一次，可以把所有未付款的客户找出来放在一个临时文件中，并按客户的名字进行排序：
SELECT cust.name，rcvbles.balance，……other columns
FROM cust，rcvbles
WHERE cust.customer_id = rcvlbes.customer_id
AND rcvblls.balance>0
ORDER BY cust.name
INTO TEMP cust_with_balance
然后以下面的方式在临时表中查询：
SELECT ＊ FROM cust_with_balance
WHERE postcode>“98000”
临时表中的行要比主表中的行少，而且物理顺序就是所要求的顺序，减少了磁盘I/O，所以查询工作量可以得到大幅减少。
注意：临时表创建后不会反映主表的修改。在主表中数据频繁修改的情况下，注意不要丢失数据。
7．用排序来取代非顺序存取
非顺序磁盘存取是最慢的操作，表现在磁盘存取臂的来回移动。SQL语句隐藏了这一情况，使得我们在写应用程序时很容易写出要求存取大量非顺序页的查询。
有些时候，用数据库的排序能力来替代非顺序的存取能改进查询。
实例分析
下面我们举一个制造公司的例子来说明如何进行查询优化。制造公司数据库中包括3个表，模式如下所示：
1．part表
零件号零件描述其他列
（part_num）（part_desc）（other column）
102，032Seageat 30G disk……
500，049Novel 10M network card……
……
2．vendor表
厂商号厂商名其他列
（vendor _num）（vendor_name） （other column）
910，257Seageat Corp……
523，045IBM Corp……
……
3．parven表
零件号厂商号零件数量
（part_num）（vendor_num）（part_amount）
102，032910，2573,450,000
234，423321，0014，000，000
……
下面的查询将在这些表上定期运行，并产生关于所有零件数量的报表：
SELECT part_desc，vendor_name，part_amount
FROM part，vendor，parven
WHERE part.part_num=parven.part_num
AND parven.vendor_num = vendor.vendor_num
ORDER BY part.part_num
如果不建立索引，上述查询代码的开销将十分巨大。为此，我们在零件号和厂商号上建立索引。索引的建立避免了在嵌套中反复扫描。关于表与索引的统计信息如下：
表行尺寸行数量每页行数量数据页数量
（table）(row size)（Row count）（Rows/Pages）（Data Pages）
part15010，00025400
Vendor1501，000 2540
Parven13 15，000300 50
索引键尺寸每页键数量页面数量
（Indexes）(Key Size)（Keys/Page)(Leaf Pages）
part450020
Vendor45002
Parven825060
看起来是个相对简单的3表连接，但是其查询开销是很大的。通过查看系统表可以看到，在part_num上和vendor_num上有簇索引，因此索引是按照物理顺序存放的。parven表没有特定的存放次序。这些表的大小说明从缓冲页中非顺序存取的成功率很小。此语句的优化查询规划是：首先从part中顺序读取400页，然后再对parven表非顺序存取1万次，每次2页（一个索引页、一个数据页），总计2万个磁盘页，最后对vendor表非顺序存取1.5万次，合3万个磁盘页。可以看出在这个索引好的连接上花费的磁盘存取为5.04万次。
实际上，我们可以通过使用临时表分3个步骤来提高查询效率：
1．从parven表中按vendor_num的次序读数据：
SELECT part_num，vendor_num，price
FROM parven
ORDER BY vendor_num
INTO temp pv_by_vn
这个语句顺序读parven（50页），写一个临时表（50页），并排序。假定排序的开销为200页，总共是300页。
2．把临时表和vendor表连接，把结果输出到一个临时表，并按part_num排序：
SELECT pv_by_vn，＊ vendor.vendor_num
FROM pv_by_vn，vendor
WHERE pv_by_vn.vendor_num=vendor.vendor_num
ORDER BY pv_by_vn.part_num
INTO TMP pvvn_by_pn
DROP TABLE pv_by_vn
这个查询读取pv_by_vn(50页)，它通过索引存取vendor表1.5万次，但由于按vendor_num次序排列，实际上只是通过索引顺序地读vendor表（40＋2=42页），输出的表每页约95行，共160页。写并存取这些页引发5＊160=800次的读写，索引共读写892页。
3．把输出和part连接得到最后的结果：
SELECT pvvn_by_pn.＊，part.part_desc
FROM pvvn_by_pn，part
WHERE pvvn_by_pn.part_num=part.part_num
DROP TABLE pvvn_by_pn
这样，查询顺序地读pvvn_by_pn(160页)，通过索引读part表1.5万次，由于建有索引，所以实际上进行1772次磁盘读写，优化比例为30∶1。笔者在Informix Dynamic
Sever上做同样的实验，发现在时间耗费上的优化比例为5∶1(如果增加数据量，比例可能会更大)。
小结
20％的代码用去了80％的时间，这是程序设计中的一个着名定律，在数据库应用程序中也同样如此。我们的优化要抓住关键问题，对于数据库应用程序来说，重点在于SQL的执行效率。查询优化的重点环节是使得数据库服务器少从磁盘中读数据以及顺序读页而不是非顺序读页。