下载文档原格式
数据库中的物理设计与优化策略数据库是一个存储和管理数据的关键工具，它能够提供高效的数据访问和操作。
在数据库的设计和优化过程中，物理设计和优化策略是不可或缺的部分。
本文将详细探讨数据库中的物理设计和优化策略，并介绍一些常用的技巧和方法。
一、物理设计物理设计是指将逻辑设计转化为实际的存储结构和计算机文件表示方式的过程。
在进行物理设计时，主要考虑以下几个方面：1. 存储结构选择存储结构的选择对数据库的性能有着重要的影响。
常见的存储结构包括堆文件、哈希文件和索引文件。
在选择存储结构时，需要考虑数据的访问模式、数据的大小和访问频率等因素。
2. 数据分区为了提高查询效率和降低存储开销，数据可以在物理上进行分区。
常见的数据分区方法包括水平分区和垂直分区。
水平分区是将表中的数据划分为多个子集，每个子集存储在不同的存储设备上。
垂直分区则是将表的列按照某种规则进行分割，每个分区只包含一部分列。
3. 索引设计索引是提高数据库查询效率的重要手段。
在进行索引设计时，需要考虑到索引的选择和建立。
常用的索引包括B树索引、哈希索引和位图索引。
在选择索引时，需要根据查询的特点和数据的分布情况进行优化。
4. 数据复制和冗余为了提高数据库的可用性和容错性，可以对数据进行复制和冗余。
数据复制是将数据存储在多个节点上，从而实现在某个节点失效时仍能使用其他节点的数据。
冗余是指在不同的地方存储相同的数据，以避免数据的丢失和损坏。
二、优化策略在进行数据库的物理设计后，还需要采取一些优化策略来进一步提高数据库的性能和效率。
以下是一些常用的优化策略：1. 查询优化查询是数据库中最常见的操作。
为了提高查询的效率，可以进行查询优化。
查询优化的方法包括使用合适的索引、优化查询语句、减少查询次数和使用缓存等。
2. 硬件优化硬件配置对数据库的性能有着直接的影响。
可以通过升级硬件、调整硬件参数和提高硬件利用率等方式来进行硬件优化。
例如，增加硬盘容量和带宽、提高CPU的运行速度和内存的大小等。
数据库中的空间数据存储与查询设计与优化策略在当今信息化时代，空间数据的存储与查询变得越来越重要。
许多应用领域，如地理信息系统（GIS）、位置服务应用、地理空间分析等，都需要高效地存储和查询大量的空间数据。
本文将探讨数据库中的空间数据存储与查询的设计与优化策略，以提高数据的访问效率和用户体验。
一、空间数据存储设计1. 数据库模型选择在空间数据存储设计中，选择合适的数据库模型是一个关键的步骤。
常用的数据库模型包括层次模型、网状模型、关系模型和面向对象模型。
对于空间数据的存储，关系模型和面向对象模型是比较常见和适用的选择。
关系模型的优势在于其结构化的特点，能够方便地进行复杂的查询和关联操作；而面向对象模型则更加适合描述和处理复杂的空间数据结构。
2. 空间索引技术为了加快查询速度，我们需要在数据库中建立空间索引。
常用的空间索引技术包括四叉树、R树和网格索引等。
四叉树是一种二维空间索引方法，能够高效地支持空间数据的插入和查询操作。
R树是一种多维空间索引结构，适用于高维度的空间数据。
网格索引将空间数据划分为规则的网格单元，可以提供快速的查询性能。
3. 数据分片存储对于大规模的空间数据集合，将数据进行分片存储可以提高数据的访问效率。
可以根据数据的地理位置或者属性进行分片，并将不同分片存储在不同的物理存储设备上。
这样可以减少单个查询的数据量，提高查询效率。
同时，可以采用分布式存储和并行查询的技术，进一步加快数据的访问速度。
二、空间数据查询优化策略1. 空间查询算法选择针对不同类型的空间查询，选择合适的查询算法可以提高查询效率。
常见的空间查询算法包括范围查询、最近邻查询和空间连接查询等。
对于范围查询，可以使用R树或网格索引等技术来减少查询的数据量。
最近邻查询可以利用k-d树或R树等索引结构来加速查询速度。
空间连接查询可以通过空间索引和关联查询等方法来实现。
2. 查询缓存技术查询缓存是一种常用的查询优化技术，可以减少重复查询的开销。
优化数据库的八种方法优化数据库是提高数据库性能和效率的重要手段之一。
下面将介绍八种常见的数据库优化方法。
一、合理设计数据库结构数据库结构的设计直接影响数据库的性能和效率。
在设计数据库时，应注意以下几点：1. 表的字段应设置合理的数据类型和长度，避免浪费存储空间和计算资源。
2. 为表添加适当的索引，以加快查询速度。
索引应根据查询的频率和类型进行选择。
3. 合理划分表和字段的关系，避免冗余和重复数据。
使用范式化的设计可以提高数据的一致性和完整性。
二、优化查询语句优化查询语句是提高数据库性能的关键。
以下是一些优化查询语句的方法：1. 调整查询语句的顺序，将最常用和最重要的条件放在前面，以提高查询效率。
2. 避免使用通配符查询，如“%”，会导致全表扫描，影响性能。
3. 使用合适的连接方式，如INNER JOIN、LEFT JOIN等，减少不必要的数据读取。
4. 避免在WHERE子句中使用函数，函数会导致索引失效，影响查询效率。
三、优化索引索引是提高数据库查询效率的重要手段。
以下是一些优化索引的方法：1. 选择合适的索引类型，如B树索引、哈希索引等，根据查询的类型和频率进行选择。
2. 避免在索引列上使用函数或运算符，这会导致索引失效。
3. 定期对索引进行优化和重建，以保证索引的有效性和性能。
四、合理使用缓存缓存是提高数据库访问速度的重要手段。
以下是一些合理使用缓存的方法：1. 使用数据库缓存，如Redis、Memcached等，可以减少对数据库的访问次数。
2. 合理设置缓存时间，避免缓存数据过期或过长时间没有更新。
3. 使用缓存预热，提前加载常用数据到缓存中，减少用户访问时的延迟。
五、分表分库当数据库数据量庞大时，可以考虑进行分表分库操作，以减轻单个数据库的压力。
以下是一些分表分库的方法：1. 根据业务需求和数据特点，将数据划分到不同的表或数据库中。
2. 使用分片技术，将数据按照一定规则分布到多个数据库中。
分布式数据库设计与优化随着互联网的发展和数据量的不断增长，传统的单机数据库已经无法满足大规模的数据存储和访问需求。
为了解决这一问题，分布式数据库被广泛采用。
本文将着重介绍分布式数据库的设计和优化策略。
一、分布式数据库设计1. 数据划分在分布式数据库中，数据划分是非常重要的一步。
好的数据划分可以提高系统的并发性能和可伸缩性。
其思路是将数据按照某种规则分散到不同的节点上，实现负载均衡和数据的并行处理。
常见的数据划分策略有两种，即垂直划分和水平划分。
垂直划分指的是将一个表按照列进行拆分，将不同的列存储在不同的节点上。
水平划分则是根据某个条件将表中的数据分散到不同的节点上。
2. 数据复制为了保证分布式数据库的高可用性和容错能力，数据复制是必不可少的。
通过将数据复制到多个节点上，可以避免单点故障，提高系统的可靠性。
数据复制有两种方式，即主备复制和多库复制。
主备复制是将一个节点作为主节点，其他节点作为备节点。
主节点负责处理用户的读写请求，备节点则负责同步主节点的数据。
当主节点发生故障时，可以通过自动切换备节点来保证系统的正常运行。
多库复制是将数据复制到多个节点上，每个节点都可以处理用户的读写请求。
通过多库复制可以提高系统的读取性能，但写入操作需要同步到所有节点，对于写入性能有一定的影响。
3. 数据一致性在分布式数据库中，数据一致性是一个复杂而重要的问题。
由于数据被分散存储在不同的节点上，数据的一致性需要得到保证。
在设计分布式数据库时，需要考虑如何解决数据一致性的问题。
常见的保证数据一致性的方法有两种，即强一致性和最终一致性。
强一致性要求所有节点在同一时刻看到的数据是一致的，但会影响系统的性能和可伸缩性。
最终一致性则允许在一段时间内存在数据不一致的情况，但能够保证最终数据的一致性。
二、分布式数据库优化1. 查询优化查询优化是提高分布式数据库性能的关键。
在设计查询时，应尽量减少数据的传输和节点间的通信开销。
可以通过以下方法来进行查询优化：- 使用索引：在查询中使用索引可以加快数据的查找速度，降低系统的负载。
电商平台数据库设计与优化随着互联网的迅猛发展，电子商务平台已经成为了商业交易的主要形式之一。
对于电商平台来说，数据库的设计与优化至关重要。
一方面，合理的数据库设计能够提高系统的性能和运行效率，保证系统的稳定性和可靠性；另一方面，数据库的优化能够提升用户体验，加快网页加载速度，提高购物流程的顺畅度。
一、数据库设计在进行电商平台数据库设计时，需要考虑以下几个方面：1. 数据库的表结构设计：合理的表结构设计是一个高性能数据库的基础。
根据电商平台的属性，可以设计出包括用户表、商品表、订单表、购物车表等在内的多个表，通过主键、外键等关系进行关联。
2. 数据库的索引设计：索引是提高数据库查询效率的关键。
在电商平台设计中，根据经常查询的字段进行索引的设计，如商品的分类、名称、价格等。
但需要注意的是，过多的索引会增加数据库的存储空间和维护成本，需要考虑权衡。
3. 数据库的数据类型选择：合适的数据类型不仅能节约存储空间，还能提高数据库的查询性能。
在电商平台设计中，可以选择适当的整型、字符型、日期时间型等数据类型，并根据业务需求进行选择。
4. 数据库的范式设计：范式是数据库设计中的一种规范，能够帮助减少数据冗余和提高数据更新的速度。
在电商平台设计中，可以使用第三范式进行表的设计，避免数据的重复存储。
二、数据库优化数据库优化是为了提高系统性能和用户体验，保证电商平台的正常运行。
以下是一些常用的数据库优化方法：1. 优化查询语句：对于经常用到的查询语句，可以使用索引、限制返回结果集的数量、添加合适的过滤条件等方式进行优化。
避免使用SELECT *语句，只查询需要的字段，减少数据库的负载。
2. 合理使用缓存：对于频繁读取但很少修改的数据，可以使用缓存技术，如Redis或Memcached。
将数据缓存在内存中，加快数据的读取速度，减轻数据库的压力。
3. 数据分区和分表：对于数据量较大的表，可以考虑进行数据分区，将数据分散存储在不同的物理磁盘上，提高查询效率。
数据时序数据库设计与性能优化方法数据时序数据库是一种专门用于存储和管理时间序列数据的数据库系统。
随着物联网、金融交易和监控系统等领域对时间序列数据处理需求的增加，数据时序数据库也变得越来越重要。
在设计和优化数据时序数据库时，需要考虑数据存储、索引方式、数据压缩和查询性能等因素。
本文将介绍数据时序数据库的设计原则和性能优化方法。
首先，数据时序数据库的设计需要考虑数据存储方式。
一种常见的方法是按照时间顺序将数据存储在连续的存储介质中，例如按照时间顺序存储在硬盘上或者按照时间顺序存储在内存中。
这样可以提高数据的读取和写入效率，因为数据存储的顺序与查询时常使用的时间范围相匹配。
其次，索引方式对于数据时序数据库的性能优化也非常重要。
在处理时间序列数据时，常用的索引结构包括B-树、R树和哈希索引。
根据数据时序数据库的特点，可以选择适合的索引结构。
例如，B-树适合范围查询，R树适合多维数据查询，哈希索引适合等值查询。
选择合适的索引结构可以提高查询性能。
此外，数据压缩也是提高数据时序数据库性能的一项重要方法。
由于时间序列数据通常具有周期性、重复性和局部性，因此可以利用数据的特点进行无损和有损的压缩。
无损压缩方法包括gzip、snappy和LZO等，有损压缩方法包括差值压缩、哈夫曼压缩和波峰波谷压缩等。
选择合适的压缩方法可以减少存储空间的占用，提高读写和查询性能。
另外，查询性能是数据时序数据库设计中需要特别关注的问题。
为了提高查询性能，可以使用索引、分区和缓存等技术。
索引已经提到过，可以根据查询的特点选择合适的索引结构。
分区可以将大表按照时间或其他方式划分成多个较小的表，查询时只需要扫描部分表，减少查询的数据量。
缓存可以将查询结果缓存到内存中，下次查询时直接从缓存中读取结果，避免重复计算。
这些技术可以提高查询性能。
除了以上的方法，数据时序数据库的性能优化还可以通过批量写入、数据预聚合和负载均衡等手段来实现。
批量写入可以减少写入操作的频率，提高写入性能。
数据库管理中的数据模型设计与性能优化实际案例分享及实践经验总结在数据库管理中，数据模型设计和性能优化是至关重要的环节。
一个有效的数据模型设计可以提高数据库的性能、可扩展性和可维护性，而性能优化则可以进一步提升数据库的响应速度和吞吐量。
本文将分享一些实际案例，以及在数据模型设计和性能优化方面的一些实践经验总结。
一、数据模型设计实际案例分享1. 不合理的关系模型设计导致性能瓶颈在一个电子商务网站的数据库设计中，产品和订单之间采用了多对多的关系模型，导致查询订单详情的性能低下。
经过重新设计数据模型，将订单详情直接与产品关联，使用简单的一对多关系模型，显著提高了查询性能。
2. 索引设计的意义和优化效果在一个物流管理系统的数据库设计中，查询运输记录的性能一直较差。
通过对数据库表的索引设计优化，可以大幅提升查询性能。
例如，使用非聚集索引优化date字段的查询，以及使用聚集索引优化运输记录的状态字段的查询。
二、性能优化实践经验总结1. 选择合适的数据类型选择合适的数据类型可以减少数据库的存储空间，并提高查询性能。
例如，对于一个存储手机号码的字段，选择使用INT类型存储可以减少存储空间。
2. 合理使用索引索引是提高数据库查询性能的重要工具，但过多的索引会导致插入和更新操作变慢。
因此，在设计数据库表时需要权衡索引的数量和占用空间，选择合适的字段建立索引，并定期评估和优化索引的使用情况。
3. 合理分割数据针对大型数据库系统，合理分割数据可以显著提高查询性能。
可以将数据按照时间、地理位置等特征进行分割，将热点数据和冷数据存储在不同的数据表或数据库中，减轻查询的负担。
4. 数据库缓存优化数据库缓存可以大幅提升查询性能，降低数据库负载。
通过使用缓存技术，将经常查询的数据缓存在内存中，减少对数据库的查询操作。
常用的缓存技术包括Redis、Memcached等。
5. 定期数据清理定期清理无效、过期或冗余的数据可以提高数据库的查询性能。
⼤数据量数据库设计与优化⽅案（SQL优化）⼀、数据库结构的设计如果不能设计⼀个合理的数据库模型，不仅会增加客户端和服务器段程序的编程和维护的难度，⽽且将会影响系统实际运⾏的性能。
所以，在⼀个系统开始实施之前，完备的数据库模型的设计是必须的。
在⼀个系统分析、设计阶段，因为数据量较⼩，负荷较低。
我们往往只注意到功能的实现，⽽很难注意到性能的薄弱之处，等到系统投⼊实际运⾏⼀段时间后，才发现系统的性能在降低，这时再来考虑提⾼系统性能则要花费更多的⼈⼒物⼒，⽽整个系统也不可避免的形成了⼀个打补丁⼯程。
所以在考虑整个系统的流程的时候，我们必须要考虑，在⾼并发⼤数据量的访问情况下，我们的系统会不会出现极端的情况。
（例：对外统计系统在7⽉16⽇出现的数据异常的情况，并发⼤数据量的的访问造成，数据库的响应时间不能跟上数据刷新的速度造成。
具体情况是：在⽇期临界时（00：00：00），判断数据库中是否有当前⽇期的记录，没有则插⼊⼀条当前⽇期的记录。
在低并发访问的情况下，不会发⽣问题，但是当⽇期临界时的访问量相当⼤的时候，在做这⼀判断的时候，会出现多次条件成⽴，则数据库⾥会被插⼊多条当前⽇期的记录，从⽽造成数据错误），数据库的模型确定下来之后，我们有必要做⼀个系统内数据流向图，分析可能出现的瓶颈。
为了保证数据库的⼀致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。
（例:⽤户表的地区，我们可以把地区另外存放到⼀个地区表中）如果数据冗余低，数据的完整性容易得到保证，提⾼了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。
⽽对于多表之间的关联查询（尤其是⼤数据表）时，其性能将会降低，同时也提⾼了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量⼤⼩、数据项的访问频度，对此类数据表频繁的关联查询应适当提⾼数据冗余设计但增加了表间连接查询的操作，也使得程序的变得复杂，为了提⾼系统的响应时间，合理的数据冗余也是必要的。
数据库优化方案范文1.合理设计和规范化数据库结构：-使用适当的数据类型和长度，避免存储过大或过小的数据。
-使用适当的索引，加快数据查询的速度。
-将数据库分为多个表，并建立表之间的关系，避免冗余数据和数据重复。
2.优化查询语句：-使用合适的查询语句，避免全表扫描和不必要的数据读取。
-使用连接查询和子查询，减少查询的次数和数据传输量。
-使用合适的过滤条件和排序条件，减少不必要的数据读取和处理。
3.创建适当的索引：-对于经常使用的查询字段，创建索引以加快查询速度。
-对于表中的唯一字段，创建唯一索引以保证数据的一致性和唯一性。
-避免过多的索引，因为索引会增加数据存储的大小和写入的时间。
4.使用合适的缓存：-对于经常读取的数据，可以使用缓存来提高读取速度。
- 可以使用缓存数据库如Redis来缓存查询结果，避免频繁查询数据库。
5.控制事务的粒度：-对于数据的读取操作，可以使用读未提交的事务级别来提高并发性能。
-对于数据的写入操作，可以使用适当的事务级别来保证数据的一致性和可靠性。
6.优化数据库配置参数：-根据系统需求和硬件配置，调整数据库的缓存大小和最大连接数等参数。
-避免使用默认配置，因为默认配置往往不能满足系统的性能需求。
7.数据库分区与分库分表：-对于大数据量的表，可以使用分区表来提高查询和写入的速度。
-对于数据量过大的数据库，可以将数据库分为多个库，并根据业务需求将数据分散到不同的库中，以提高并发性能和减少单点故障。
8.使用数据库镜像与备份：-对于关键数据，可以使用数据库镜像来提高系统的可用性和容错性。
-定期进行数据库备份，以保证数据的安全性和可恢复性。
9.数据库性能监控和分析：-定期监控数据库的性能指标，如查询响应时间、数据库连接数、缓存命中率等。
-根据监控数据分析数据库的性能问题，并及时进行优化和调整。
总结起来，数据库优化包括合理设计数据库结构、优化查询语句、创建适当的索引、使用合适的缓存、控制事务的粒度、优化数据库配置参数、数据库分区与分库分表、使用数据库镜像与备份、数据库性能监控和分析等方面。
数据库系统中的物理设计和优化方法随着信息技术的发展，越来越多的企业、机构和组织开始采用数据库系统进行数据管理和存储。
数据库系统不仅提高了数据管理的效率和安全性，还可以为企业提供更好的决策支持和数据分析。
然而，在数据库系统的设计和开发中，物理设计和优化方法的正确运用非常重要，能够大大提高数据库系统的性能和效果。
一、物理设计的基本原则物理设计是指根据数据库逻辑设计，采用现有的硬件和操作系统环境来设计数据库系统的存储结构和物理对象。
物理设计的基本原则如下：1. 适当选择存储设备物理设计应该根据数据存储容量和性能需求来选择存储设备。
例如，对于大型数据库系统，应该选择高速硬盘（如RAID）来提高数据库的性能和容量；对于小型数据库系统，可以选择低速、廉价的存储设备来降低成本。
2. 性能优先数据库的性能和效果是物理设计的最重要目标。
为达到最优性能，物理设计应该优化系统的存储结构、存储方式、索引结构和查询性能等方面。
3. 数据安全性物理设计应该考虑数据的安全性。
例如，采用数据备份和恢复功能、嵌入式安全特性、事务控制等技术来保护数据的安全性。
4. 可维护性物理设计应该考虑数据库的可维护性，并且应该能够方便地更新或修改系统而不影响数据的正常使用。
例如，合理的备份和恢复策略、数据库的容量扩展和缩减等都应该是物理设计的考量因素。
二、物理优化的方法物理优化是指通过优化数据库的物理存储结构、访问路径和查询优化等方式来提高数据库的性能和效果。
下面是一些常见的物理优化方法：1. 索引优化索引是物理优化的一个重要环节。
正确地选择、建立和使用索引能够大大提高数据库的查询效率。
索引的优化可以从以下几个方面考虑：(1) 建立合理的索引类型合理的索引类型可以大大提高查询的效率。
例如，表的主键、外键、唯一索引等认为建立适当的索引类型能够提高查询效率。
(2) 建立合理的索引数量并不是每个字段都需要建立索引。
过多的索引会影响数据库的性能，因此应该根据具体情况来选择建立索引。
一、数据库结构的设计如果不能设计一个合理的数据库模型，不仅会增加客户端和服务器端程序的编程和维护的难度，而且将会影响系统实际运行的性能。
所以，在一个系统开始实施之前，完备的数据库模型的设计是必须的。
在一个系统分析、设计阶段，因为数据量较小，负荷较低。
我们往往只注意到功能的实现，而很难注意到性能的薄弱之处，等到系统投入实际运行一段时间后，才发现系统的性能在降低，这时再来考虑提高系统性能则要花费更多的人力物力，而整个系统也不可避免的形成了一个打补丁工程。
所以在考虑整个系统的流程的时候，我们必须要考虑，在高并发大数据量的访问情况下，我们的系统会不会出现极端的情况。
（例如：对外统计系统在7月16日出现的数据异常的情况，并发大数据量的访问造成，数据库的响应时间不能跟上数据刷新的速度。
具体情况是：在日期临界时（00：00：00），判断数据库中是否有当前日期的记录，没有则插入一条当前日期的记录。
在低并发访问的情况下，不会发生问题，但是在当日期临界时的访问量相当大，且在做这一判断的时候，会出现多次条件成立，则数据库里会被插入多条当前日期的记录，从而造成数据错误。
），数据库的模型确定下来之后，我们有必要做一个系统内数据流向图，分析可能出现的瓶颈。
为了保证数据库的一致性和完整性，在逻辑设计的时候往往会设计过多的表间关联，尽可能的降低数据的冗余。
（例如用户表的地区，我们可以把地区另外存放到一个地区表中）如果数据冗余低，数据的完整性容易得到保证，提高了数据吞吐速度，保证了数据的完整性，清楚地表达数据元素之间的关系。
而对于多表之间的关联查询（尤其是大数据表）时，其性能将会降低，同时也提高了客户端程序的编程难度，因此，物理设计需折衷考虑，根据业务规则，确定对关联表的数据量大小、数据项的访问频度，对此类数据表频繁的关联查询应适当提高数据冗余设计但增加了表间连接查询的操作，也使得程序的变得复杂，为了提高系统的响应时间，合理的数据冗余也是必要的。
设计人员在设计阶段应根据系统操作的类型、频度加以均衡考虑。
另外，最好不要用自增属性字段作为主键与子表关联，不便于系统的迁移和数据恢复。
原来的表格必须可以通过由它分离出去的表格重新构建。
使用这个规定的好处是，你可以确保不会在分离的表格中引入多余的列，所有你创建的表格结构都与它们的实际需要一样大。
应用这条规定是一个好习惯，不过除非你要处理一个非常大型的数据，否则你将不需要用到它。
（例如一个通行证系统，我可以将USERID，USERNAME，USERPASSWORD，单独出来做个表，再把USERID作为其他表的外键）表的设计具体注意的问题：1、数据行的长度不要超过8020字节，如果超过这个长度的话在物理页中这条数据会占用两行从而造成存储碎片，降低查询效率。
2、能够用数字类型的字段尽量选择数字类型而不用字符串类型的（电话号码），这会降低查询和连接的性能，并会增加存储开销。
这是因为引擎在处理查询和连接回逐个比较字符串中每一个字符，而对于数字型而言只需要比较一次就够了。
3、对于不可变字符类型char和可变字符类型varchar 都是8000字节，char 查询快，但是耗存储空间，varchar查询相对慢一些但是节省存储空间。
在设计字段的时候可以灵活选择，例如用户名、密码等长度变化不大的字段可以选择CHAR，对于评论等长度变化大的字段可以选择VARCHAR。
4、字段的长度在最大限度的满足可能的需要的前提下，应该尽可能的设得短一些，这样可以提高查询的效率，而且在建立索引的时候也可以减少资源的消耗。
二、查询的优化1、保证在实现功能的基础上，尽量减少对数据库的访问次数；2、通过搜索参数，尽量减少对表的访问行数，最小化结果集，从而减轻网络负担；3、能够分开的操作尽量分开处理，提高每次的响应速度；4、在数据窗口使用SQL时，尽量把使用的索引放在选择的首列；5、算法的结构尽量简单；6、在查询时，不要过多地使用通配符如SELECT * FROM T1语句，要用到几列就选择几列，如：SELECT COL1，COL2 FROM T1；7、在可能的情况下尽量限制查询结果集行数如：SELECT TOP 300 COL1，COL2，COL3 FROM T1，因为某些情况下用户是不需要那么多的数据的。
8、在没有建索引的情况下，数据库查找某一条数据，就必须进行全表扫描了，对所有数据进行一次遍历，查找出符合条件的记录。
在数据量比较小的情况下，也许看不出明显的差别，但是当数据量大的情况下，这种情况就是极为糟糕的了；9、SQL 语句在SQL SERVER中是如何执行的，他们担心自己所写的SQL语句会被SQL SERVER误解。
比如：select * from table1 where name='zhangsan' and tID > 10000和执行:select * from table1 where tID > 10000 and name='zhangsan'一些人不知道以上两条语句的执行效率是否一样，因为如果简单的从语句先后上看，这两个语句的确是不一样，如果tID是一个聚合索引，那么后一句仅仅从表的 10000条以后的记录中查找就行了；而前一句则要先从全表中查找看有几个name='zhangsan'的，而后再根据限制条件条件tID> 10000来提出查询结果。
事实上，这样的担心是不必要的。
SQL SERVER中有一个“查询分析优化器”，它可以计算出where子句中的搜索条件并确定哪个索引能缩小表扫描的搜索空间，也就是说，它能实现自动优化。
虽然查询优化器可以根据where子句自动的进行查询优化，但有时查询优化器就会不按照您的本意进行快速查询。
在查询分析阶段，查询优化器查看查询的每个阶段并决定限制需要扫描的数据量是否有用。
如果一个阶段可以被用作一个扫描参数（SARG），那么就称之为可优化的，并且可以利用索引快速获得所需数据。
SARG的定义：用于限制搜索的一个操作，因为它通常是指一个特定的匹配，一个值的范围内的匹配或者两个以上条件的AND连接。
形式如下：列名操作符 <常数或变量> 或 <常数或变量> 操作符列名列名可以出现在操作符的一边，而常数或变量出现在操作符的另一边。
如：Name= ’张三’Price > 50005000 < priceName= ’张三’ and price > 5000如果一个表达式不能满足SARG的形式，那它就无法限制搜索的范围了，也就是SQL SERVER必须对每一行都判断它是否满足WHERE子句中的所有条件。
所以一个索引对于不满足SARG形式的表达式来说是无用的。
所以，优化查询最重要的就是，尽量使语句符合查询优化器的规则，避免全表扫描，而使用索引查询。
具体要注意的：1.应尽量避免在where子句中对字段进行null值判断，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num is null可以在num上设置默认值0，确保表中num列没有null值，然后这样查询：select id from t where num=02.应尽量避免在 where 子句中使用!=或<>操作符，否则将导致引擎放弃使用索引而进行全表扫描。
优化器将无法通过索引来确定将要命中的行数，因此需要搜索该表的所有行。
3.应尽量避免在 where 子句中使用 or 来连接条件，否则将导致引擎放弃使用索引而进行全表扫描，如：select id from t where num=10 or num=20可以这样查询：select id from t where num=10union allselect id from t where num=204.in 和 not in 也要慎用，因为in会使系统无法使用索引，而只能直接搜索表中的数据。
如：select id from t where num in(1，2，3)对于连续的数值，能用 between 就不要用 in 了select id from t where num between 1 and 35.在索引过的字符数据中，尽量避免使用非字母打头搜索。
这也使得引擎无法利用索引。
见如下例子：SELECT * FROM T1 WHERE NAME LIKE ‘%L%’SELECT * FROM T1 WHERE SUBSTING(NAME，2，1)=’L’SELECT * FROM T1 WHERE NAME LIKE ‘L%’即使NAME字段建有索引，前两个查询依然无法利用索引完成加快操作，引擎不得不对全表所有数据逐条操作来完成任务。
而第三个查询能够使用索引来加快操作。
6.必要时强制查询优化器使用某个索引，如在 where 子句中使用参数，也会导致全表扫描。
因为SQL只有在运行时才会解析局部变量，但优化程序不能将访问计划的选择推迟到运行时；它必须在编译时进行选择。
然而，如果在编译时建立访问计划，变量的值还是未知的，因而无法作为索引选择的输入项。
如下面语句将进行全表扫描：select id from t where num=@num可以改为强制查询使用索引：select id from t with(index(索引名)) where num=@num7.应尽量避免在 where 子句中对字段进行表达式操作，这将导致引擎放弃使用索引而进行全表扫描。
如：SELECT * FROM T1 WHERE F1/2=100应改为:SELECT * FROM T1 WHERE F1=100*2SELECT * FROM RECORD WHERE SUBSTRING(CARD_NO，1，4)=’5378’应改为:SELECT * FROM RECORD WHERE CARD_NO LIKE ‘5378%’SELECT member_number， first_name， last_name FROM membersWHERE DATEDIFF(yy，datofbirth，GETDATE()) > 21应改为:SELECT member_number， first_name， last_name FROM membersWHERE dateofbirth < DATEADD(yy，-21，GETDATE())即：任何对列的操作都将导致表扫描，它包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等号右边。
8.应尽量避免在where子句中对字段进行函数操作，这将导致引擎放弃使用索引而进行全表扫描。
