数据库优化资料
数据库优化方法与技巧
数据库优化方法与技巧数据库是现代信息系统中的核心组成部分，负责存储和管理数据，为应用程序提供高效的数据操作和查询功能。
然而，随着数据量和访问量的增加，数据库性能可能会受到限制，导致应用程序响应变慢甚至崩溃。
为了解决这个问题，数据库优化成为了必不可少的一环。
本文将介绍一些常用的数据库优化方法与技巧，从索引优化、查询优化、数据模型设计等方面来提高数据库的性能。
一、索引优化索引是提高数据库查询性能的重要手段。
在设计数据库时，通过对关键字段创建索引可以大大减少查询的时间复杂度，提高查询效率。
确定哪些字段需要创建索引，是一个需要仔细考虑的问题。
一般来说，可以根据以下几个原则进行索引优化：1.选择合适的索引类型：不同的数据库支持不同的索引类型，如B树索引、哈希索引、全文索引等。
根据需要选择最适合的索引类型可以提高查询效率。
2.避免过多索引：虽然索引可以加速查询，但是过多的索引也会带来额外的维护成本。
只选择关键字段创建索引，并在数据库设计中尽量避免冗余字段可以减少索引的数量。
3.使用组合索引：当需要同时根据多个字段进行查询时，可以考虑创建组合索引，将多个字段合并在一起作为索引，可以提高查询效率。
4.定期维护索引：随着数据库的更新，索引的性能可能会下降。
定期对索引进行维护，如重新构建索引、优化索引大小等，可以保持索引的高效性。
二、查询优化查询是数据库最常用的操作之一，优化查询性能对整个系统的响应速度有着重要的影响。
下面是一些常见的查询优化方法：1.减少查询结果集：只返回应用程序需要的数据可以减少查询的时间和数据传输的开销。
尽量使用SELECT语句指定需要的字段，避免使用SELECT * 来返回全部字段。
2.使用JOIN优化查询：当涉及到多个表的查询时，使用JOIN操作将多个查询合并为一个复杂查询可以减少数据库的访问次数，提高查询效率。
3.避免使用子查询：尽量避免使用子查询，特别是在大数据量的情况下，因为子查询会增加数据库的负载和查询的时间。
数据库优化报告模板
数据库优化报告模板系统数据库优化报告模板版本记录1.概述本文档主要对系统实际运行过程中的数据库出现的性能问题进行分析优化2.SQL语句类优化2.1把SQL语句中使用SELECT * 的语句该成SELECT 列名，原因是：ORACLE在解析的过程中，会将' * '依次转换成所有的列名，这个工作是通过查询数据字典完成的，这意味着将耗费更多的时间。
2.2把SQL语句中的小写改为大写，原因是：oracle总是先解析sql语句，把小写的字母转换成大写的再执行。
2.3对于保存多条数据的SQL语句使用批处理语句保存，减少访问数据库的次数2.4联合查询优化：--No.1 tableA 100w条记录tableB 1w条记录执行速度十秒级SELECT COUNT(*) FROM tableA,tableB;--No.2 执行速度百秒级甚至更高SELECT COUNT(*) FROM tableB,tableA;因此我们选择No.2的方式。
2.5Where子句后面的条件过滤有讲究ORACLE对where子句后面的条件过滤是自下向上，从右向左扫描的，所以和From 子句一样一样的，把过滤条件排个序，按过滤数据的大小，自然就是可以过滤掉最大数量记录的条件必须写在WHERE子句的末尾最下面，最右边，依次类推。
3.存储过程类优化3.1同步数据优化：原方案用java对于一条数据先执行select语句在数据库查出所有记录删除，再插入一条，每晚同步数据需要平均20分钟；优化方案：创建存储过程，创建临时表，批量删除原表数据，再将临时表数据插入数据库表。
每晚同步数据时间缩短为平均8分钟。
4.数据库索引优化注：总是使用索引的第一个列，如果索引是建立在多个列上, 只有在它的第一个列(leading column)被where子句引用时,优化器才会选择使用该索引. 这也是一条简单而重要的规则，当仅引用索引的第二个列时,优化器使用了全表扫描而忽略了索引。
数据库中常见的性能瓶颈及优化技巧
数据库中常见的性能瓶颈及优化技巧数据库在现代软件中扮演着关键角色，用于存储和管理庞大的数据。
然而，数据库性能问题可能会影响应用程序的整体性能。
本文将讨论一些常见的数据库性能瓶颈，并介绍一些优化技巧，以提高数据库系统的性能。
1. 硬件资源不足硬件资源不足是导致数据库性能下降的一个常见原因。
如处理器、内存、网络等资源的不足可能会降低数据库的响应时间和吞吐量。
为了解决这个问题，可以考虑以下优化技巧：- 升级硬件：替换较旧或不足的硬件组件，如增加处理器核心、扩展内存容量或升级网络带宽，以提高系统的整体性能。
- 负载平衡：将负载分摊到多个服务器上，以减轻单个服务器的压力，提高性能和可伸缩性。
- 数据库分片：将数据库分成多个片段，以便将数据分布到多个服务器上，并提高系统的并行处理能力。
2. 无效的查询和索引查询是数据库系统中常见的操作，但不正确或无效的查询可能会导致性能问题。
以下是一些优化技巧：- 优化查询语句：确保查询语句正确、高效，并避免不必要的查询。
使用适当的条件和索引来限制结果集的大小，并避免全表扫描。
- 创建索引：使用适当的索引来加速查询操作。
在频繁使用的列上创建索引，但要注意过多的索引可能会导致性能下降。
- 表分区：将大型表分区以提高查询效率。
根据数据的特点，将表分成较小的逻辑段，以便查询时只需扫描特定的分区。
3. 缺乏适当的数据库设计数据库的设计对性能有重要影响。
以下是一些优化技巧：- 范式化：合理地规范化数据模型，以减少冗余数据，并提高查询和更新操作的效率。
- 数据库关系：使用适当的外键和索引来建立表之间的关系。
合理使用连接（JOIN）操作而不是冗余数据。
- 缓存机制：使用合适的缓存机制，如缓存查询结果、页面片段或常用数据，以减少数据库的访问压力。
4. 日志和事务管理数据库系统通常具有事务和日志记录功能，它们虽然为数据完整性提供了保障，但也可能影响性能。
以下是一些建议：- 调整事务隔离级别：根据业务需求调整事务的隔离级别，以平衡数据完整性和并发性能。
优化数据库的八种方法
优化数据库的八种方法优化数据库是提高数据库性能和效率的重要手段之一。
下面将介绍八种常见的数据库优化方法。
一、合理设计数据库结构数据库结构的设计直接影响数据库的性能和效率。
在设计数据库时，应注意以下几点：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、资源利用率：包括 CPU 利用率、内存利用率、磁盘 I/O 利用率等。
过高或过低的资源利用率都可能表示存在性能问题。
三、数据库性能问题的常见原因1、不合理的数据库设计表结构设计不当，例如字段类型选择不合理、冗余字段过多等。
缺乏适当的索引，导致查询时需要进行全表扫描。
2、数据量过大随着业务的发展，数据量不断增加，可能超出了数据库的处理能力。
3、复杂的查询语句编写的查询语句过于复杂，包含多个嵌套子查询、连接操作等，增加了数据库的处理负担。
4、数据库配置不当数据库服务器的参数配置不合理，如内存分配、缓存设置等。
5、硬件资源不足服务器的 CPU、内存、磁盘等硬件资源无法满足数据库的需求。
四、数据库性能优化的方法1、数据库设计优化对表结构进行合理设计，选择合适的数据类型，减少数据冗余。
根据业务需求创建必要的索引，但要避免过度索引。
2、数据优化定期清理无用的数据，对历史数据进行归档或迁移。
对数据进行分区，将大表拆分成多个小表，提高查询效率。
数据库表结构优化报告
数据库表结构优化报告在当今数字化时代，数据库作为信息存储和管理的核心组件，其性能和效率直接影响着整个系统的运行效果。
而数据库表结构的优化则是提升数据库性能的关键环节之一。
本报告将深入探讨数据库表结构优化的重要性、常见问题及优化策略，并通过实际案例分析来展示优化的效果。
一、数据库表结构优化的重要性数据库表结构的合理性直接决定了数据的存储方式、查询效率和数据的完整性。
一个优化良好的表结构能够减少数据冗余、提高数据的一致性和准确性，同时加快数据的检索和更新速度。
这不仅能够提升用户体验，还能降低系统的维护成本和硬件资源的消耗。
二、常见的数据库表结构问题（一）数据冗余数据冗余是指在多个表中重复存储相同的数据。
这不仅浪费存储空间，还容易导致数据不一致性的问题。
例如，在一个员工信息表和部门信息表中，如果同时存储了部门名称，就会造成数据冗余。
（二）字段类型不合理选择不合适的字段类型可能导致存储空间的浪费或性能的下降。
例如，对于一个整数类型的字段，如果使用了过大的整数类型，会浪费存储空间；而对于一个字符串类型的字段，如果长度设置过短，可能导致数据截断。
（三）缺乏索引索引是提高查询效率的重要手段，但如果索引设置不当或缺失，会导致查询速度缓慢。
例如，对于经常用于查询和连接的字段，如果没有建立索引，数据库需要进行全表扫描，大大降低了查询性能。
（四）表结构设计不合理表结构设计不合理包括表的拆分和合并不当、关联关系设计不合理等。
例如，将一个业务逻辑上紧密相关的实体拆分成多个表，会增加关联操作的复杂性和性能开销。
三、数据库表结构优化策略（一）消除数据冗余通过合理的表设计和规范化，将重复的数据进行整合和去除。
例如，使用主外键关联来关联相关的表，避免在多个表中重复存储相同的数据。
（二）选择合适的字段类型根据数据的实际情况选择合适的字段类型。
例如，对于整数类型，根据数据的范围选择合适的整数类型（如 tinyint、smallint、int 等）；对于字符串类型，根据预计的长度设置合理的长度。
数据库优化方案
五、实施计划
1.硬件优化：在1个月内完成硬件升级；
2.软件优化：在2个月内完成数据库版本升级及参数优化；
3.架构优化：在3个月内完成读写分离和数据库集群部署；
4.数据备份与恢复：在2个月内建立实时备份机制，并完成恢复测试；
5.性能监控与调优：在1个月内部署性能监控工具，并持续进行性能优化。
（2）定期进行数据恢复测试，确保备份有效性；
（3）制定应急预案，提高故障应对能力。
5.性能监控与优化
（1）部署数据库性能监控工具，实时监控数据库性能；
（2）定期分析数据库性能瓶颈，制定优化方案；
（3）建立数据库性能优化团队，持续关注并优化数据库性能。
五、实施计划
1.硬件优化：在1个月内完成硬件升级；
六、风险评估与应对策略
1.硬件升级过程中可能出现兼容性问题，需提前进行兼容性测试；
2.数据库版本升级及参数调整可能导致业务中断，需制定详细的迁移及回滚计划；
3.读写分离和数据库集群部署可能影响现有业务，需选择合适的时间窗口进行操作；
4.实时备份可能对系统性能产生影响，需评估备份策略，确保系统性能不受影响。
（3）探索分布式数据库解决方案，应对大数据量存储及处理需求。
4.数据备份与恢复
（1）建立实时数据备份机制，确保数据安全性；
（2）定期进行数据恢复测试，验证备份有效性；
（3）制定应急预案，提高故障应对及恢复能力。
5.性能监控与调优
（1）部署专业的数据库性能监控工具，实时监控数据库性能指标；
（2）定期分析性能瓶颈，调整优化措施；
三、优化目标
1.提高数据库性能，降低查询响应时间；
数据库优化方案
数据库优化方案随着互联网时代的到来，数据库在各行各业中扮演着至关重要的角色。
然而，随着数据量的不断增长以及用户对数据需求的日益增加，数据库的性能问题也逐渐显露出来。
为了提高数据库的性能并优化其运行效率，需要采取一系列的数据库优化方案。
1. 合理设计数据模型数据库的性能问题往往源自于不合理的数据模型设计。
因此，合理的数据模型设计是数据库优化的第一步。
在设计数据模型时，需要充分考虑业务需求，并根据业务需求合理划分表，减少数据冗余和表之间的关联数量。
同时，还需要选择合适的数据类型和字段长度，避免存储时的浪费和索引时的性能损耗。
2. 优化查询语句查询语句是数据库最频繁执行的操作之一，也是影响数据库性能的重要因素。
为了提高查询效率，需要优化查询语句。
首先，尽量避免使用通配符查询，而是使用具体的条件进行查询，以减少不必要的扫描和匹配。
其次，合理利用索引以加快查询速度。
在设计表结构时，需要根据查询频率和字段的特点选择合适的字段建立索引。
另外，还可以通过调整查询语句的顺序和结构，以及合理设置分页参数来提高查询效率。
3. 调整数据库参数数据库的性能还与数据库参数的设置密切相关。
通过调整数据库参数，可以在不改变硬件环境和数据库结构的情况下提高数据库性能。
常见的参数包括缓冲区大小、连接数、并发数等。
在调整这些参数时，需要根据具体的业务需求和硬件环境的实际情况进行权衡和调整，以达到最佳的性能效果。
4. 定期清理和优化数据库随着时间的推移，数据库中的数据量不断增加，数据库性能也会逐渐下降。
为了保持数据库的良好性能，需要定期清理和优化数据库。
首先，定期清理无用的数据和重复的数据，以减少数据量并提高查询效率。
其次，可以通过表分区、表压缩、索引重建等方式对数据库进行优化，以提高数据库性能和响应速度。
5. 数据库分片对于大型的数据库，单个数据库服务器可能无法满足数据量和访问压力的需求。
为了提高数据库的性能和可扩展性，可以考虑对数据库进行分片。
- 1、下载文档前请自行甄别文档内容的完整性，平台不提供额外的编辑、内容补充、找答案等附加服务。
- 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
- 3、如文档侵犯您的权益，请联系客服反馈,我们会尽快为您处理(人工客服工作时间：9:00-18:30)。
对于一个以数据为中心的应用，数据库的好坏直接影响到程序的性能，因此数据库性能至关重要。
一般来说，要保证数据库的效率，要做好以下四个方面的工作：数据库设计、sql语句优化、数据库参数配置、恰当的硬件资源和操作系统，这个顺序也表现了这四个工作对性能影响的大小。
下面我们逐个阐明：一、数据库设计适度的反范式,注意是适度的我们都知道三范式，基于三范式建立的模型是最有效保存数据的方式，也是最容易扩展的模式。
我们在开发应用程序时，设计的数据库要最大程度的遵守三范式，特别是对于OLTP型的系统，三范式是必须遵守的规则。
当然，三范式最大的问题在于查询时通常需要join很多表，导致查询效率很低。
所以有时候基于性能考虑，我们需要有意的违反三范式，适度的做冗余，以达到提高查询效率的目的。
注意这里的反范式是适度的，必须为这种做法提供充分的理由。
下面就是一个糟糕的实例：在这里，为了提高学生活动记录的检索效率，把单位名称冗余到学生活动记录表里。
单位信息有500条记录，而学生活动记录在一年内大概有200万数据量。
如果学生活动记录表不冗余这个单位名称字段，只包含三个int字段和一个timestamp字段，只占用了16字节，是一个很小的表。
而冗余了一个varchar(32)的字段后则是原来的3倍，检索起来相应也多了这么多的I/O。
而且记录数相差悬殊，500 VS 2000000 ，导致更新一个单位名称还要更新4000条冗余记录。
由此可见，这个冗余根本就是适得其反。
下面这个冗余就很好可以看到，[学生考试总分]是冗余的，这个分数完全可以通过[得分情况]汇总得到。
在【学生考试总分】里，一次考试一个学生只有一条记录，而在【得分情况】里，一个学生针对试卷里一个小题的一个小问一条记录，粗略的算一下比例大概是1：100。
而且判卷子得分是不会轻易变的，更新的频率不高，所以说这个冗余是比较好的。
适当建立索引说起提高数据库性能，索引是最物美价廉的东西了。
不用加内存，不用改程序，不用调sql，只要执行个正确的’create index’，查询速度就可能提高百倍千倍，这可真有诱惑力。
可是天下没有免费的午餐，查询速度的提高是以插入、更新、删除的速度为代价的，这些写操作，增加了大量的I/O。
由于索引的存储结构不同于表的存储，一个表的索引所占空间比数据所占空间还大的情况经常发生。
这意味着我们在写数据库的时候做了很多额外的工作，而这个工作只是为了提高读的效率。
因此，我们建立一个索引，必须保证这个索引不会“亏本”。
一般需要遵守这样的规则：索引的字段必须是经常作为查询条件的字段;如果索引多个字段，第一个字段要是经常作为查询条件的。
如果只有第二个字段作为查询条件，这个索引不会起到作用;索引的字段必须有足够的区分度;Mysql 对于长字段支持前缀索引;对表进行水平划分如果一个表的记录数太多了，比如上千万条，而且需要经常检索，那么我们就有必要化整为零了。
如果我拆成100个表，那么每个表只有10万条记录。
当然这需要数据在逻辑上可以划分。
一个好的划分依据，有利于程序的简单实现，也可以充分利用水平分表的优势。
比如系统界面上只提供按月查询的功能，那么把表按月拆分成12个，每个查询只查询一个表就够了。
如果非要按照地域来分，即使把表拆的再小，查询还是要联合所有表来查，还不如不拆了。
所以一个好的拆分依据是最重要的。
这里有个比较好的实例每个学生做过的题都记录在这个表里，包括对题和错题。
每个题会对应一个或多个知识点，我们需要根据错题来分析学生在哪个知识点上掌握的不足。
这个表很容易达到千万级，迫切需要拆分，那么根据什么来拆呢?从需求上看，无论是老师还是学生，最终会把焦点落在一个学生的身上。
学生会关心自己，老师会关心自己班的学生。
而且每个学科的知识点是不同的。
所以我们很容易想到，联合学科和知识点两个字段来拆分这个表。
这样拆下来，每个表大概2万条数据，检索效率非常高。
对表进行垂直划分有些表记录数并不多，可能也就2、3万条，但是字段却很长，表占用空间很大，检索表时需要执行大量I/O，严重降低了性能。
这个时候需要把大的字段拆分到另一个表，并且该表与原表是一对一的关系。
【试题内容】、【答案信息】两个表，最初是作为几个字段添加到【试题信息】里的，可以看到试题内容和答案这两个字段很长，在表里有3万记录时，表已经占了1G的空间，在列试题列表时非常慢。
经过分析，发现系统很多时候是根据【册】、【单元】、类型、类别、难易程度等查询条件，分页显示试题详细内容。
而每次检索都是这几个表做join，每次要扫描一遍1G的表，很郁闷啊。
我们完全可以把内容和答案拆分成另一个表，只有显示详细内容的时候才读这个大表，由此就产生了【试题内容】、【答案信息】两个表。
选择适当的字段类型，特别是主键选择字段的一般原则是保小不保大，能用占用字节小的字段就不用大字段。
比如主键，我们强烈建议用自增类型，不用guid，为什么?省空间啊?空间是什么?空间就是效率!按4个字节和按32个字节定位一条记录，谁快谁慢太明显了。
涉及到几个表做join时，效果就更明显了。
值得一提的是，datetime和timestamp，datetime占用8个字节，而timestamp 占用4 个字节，只用了一半，而timestamp表示的范围是1970—2037，对于大多数应用，尤其是记录什么考试时间，登录时间这类信息，绰绰有余啊。
文件、图片等大文件用文件系统存储，不用数据库不用多说，铁律!!!数据库只存储路径。
外键表示清楚，方便建立索引我们都知道，在powerdesigner里为两个实体建立关系，生成物理模型时会自动给外键建立索引。
所以我们不要怕建立关系把线拉乱，建立个ShortCut就好了。
掌握表的写入时机在库模式相同的情况下，如何使用数据库也对性能有着重要作用。
同样是写入一个表，先写和后写对后续的操作会产生很大影响。
例如在上面提到的适度冗余里的例子，我们最初的目的是记录考生的总分，以达到提高检索效率的目的，也就是在录入成绩时写入这个表。
在需求里有这样的要求：列出本次考试的所有学生成绩，没有录入成绩的也显示该学生名称，只是总分显示为空。
这个查询就需这还只是个中间过程，这要是用程序实时处理，即使编程人员不罢工，数据库也会歇了。
选择合适的引擎Mysql提供了很多种引擎，我们用的最多的是myisam，innodb，memory这三类。
官方手册上说道myisqm比innodb 的读速度要快，大概是3倍。
不过书不能尽信啊，《OreIlly.High.Performance.Mysql》这本书里提到了myisam和innodb 的比较，在测试中myisam的表现还不及innodb。
至于memory，哈哈，还是比较好用的。
在批处理种作临时表是个不错的选择(如果内存够大)。
在我的一个批处理中，速度比近乎1：10。
二、SQL语句优化Sql语句优化工具·慢日志如果发现系统慢了，又说不清楚是哪里慢，那么就该用这个工具了。
只需要为mysql配置参数，mysql会自己记录下来慢的sql语句。
配置很简单，参数文件里配置：slow_query_log=d:/slow.txtlong_query_time = 2就可以在d:/slow.txt里找到执行时间超过2秒的语句了，根据这个文件定位问题吧。
·mysqldumpslow.pl慢日志文件可能会很大，让人去看是很难受的事。
这时候我们可以通过mysql自带的工具来分析。
这个工具可以格式化慢日志文件，对于只是参数不同的语句会归类类并，比如有两个语句select * from a where id=1 和select * from a where id=2，经过这个工具整理后就只剩下select * from a where id=N，这样读起来就舒服多了。
而且这个工具可以实现简单的排序，让我们有的放矢。
Explain现在我们已经知道是哪个语句慢了，那么它为什么慢呢?看看mysql是怎么执行的吧，用explain可以看到mysql执行计划，下面的用法来源于手册EXPLAIN语法(获取SELECT相关信息)EXPLAIN [EXTENDED] SELECT select_optionsEXPLAIN语句可以用作DESCRIBE的一个同义词，或获得关于MySQL如何执行SELECT语句的信息：·EXPLAIN tbl_name是DESCRIBE tbl_name或SHOW COLUMNS FROM tbl_name的一个同义词。
·如果在SELECT语句前放上关键词EXPLAIN，MySQL将解释它如何处理SELECT，提供有关表如何联接和联接的次序。
该节解释EXPLAIN的第2个用法。
借助于EXPLAIN，可以知道什么时候必须为表加入索引以得到一个使用索引来寻找记录的更快的SELECT。
如果由于使用不正确的索引出现了问题，应运行ANALYZE TABLE更新表的统计(例如关键字集的势)，这样会影响优化器进行的选择。
还可以知道优化器是否以一个最佳次序联接表。
为了强制优化器让一个SELECT语句按照表命名顺序的联接次序，语句应以STRAIGHT_JOIN而不只是SELECT开头。
EXPLAIN为用于SELECT语句中的每个表返回一行信息。
表以它们在处理查询过程中将被MySQL读入的顺序被列出。
MySQL用一遍扫描多次联接(single-sweep multi-join)的方式解决所有联接。
这意味着MySQL从第一个表中读一行，然后找到在第二个表中的一个匹配行，然后在第3个表中等等。
当所有的表处理完后，它输出选中的列并且返回表清单直到找到一个有更多的匹配行的表。
从该表读入下一行并继续处理下一个表。
当使用EXTENDED关键字时，EXPLAIN产生附加信息，可以用SHOW WARNINGS浏览。
该信息显示优化器限定SELECT语句中的表和列名，重写并且执行优化规则后SELECT语句是什么样子，并且还可能包括优化过程的其它注解。
如果什么都做不了，试试全索引扫描如果一个语句实在不能优化了，那么还有一个方法可以试试：索引覆盖。
如果一个语句可以从索引上获取全部数据，就不需要通过索引再去读表，省了很多I/O。
比如这样一个表如果我要统计每个学生每道题的得分情况，我们除了要给每个表的主键外键建立索引，还要对【得分情况】的实际得分字段索引，这样，整个查询就可以从索引得到数据了。
三、数据库参数配置最重要的参数就是内存，我们主要用的innodb引擎，所以下面两个参数调的很大# Additional memory pool that is used by InnoDB to store metadata# information. If InnoDB requires more memory for this purpose it will# start to allocate it from the OS. As this is fast enough on most# recent operating systems, you normally do not need to change this# value. SHOW INNODB STATUS will display the current amount used.innodb_additional_mem_pool_size = 64M# InnoDB, unlike MyISAM, uses a buffer pool to cache both indexes and# row data. The bigger you set this the less disk I/O is needed to# access data in tables. On a dedicated database server you may set this# parameter up to 80% of the machine physical memory size. Do not set it# too large, though, because competition of the physical memory may# cause paging in the operating system. Note that on 32bit systems you# might be limited to 2-3.5G of user level memory per process, so do not# set it too high.innodb_buffer_pool_size = 5G对于myisam，需要调整key_buffer_size当然调整参数还是要看状态，用show status语句可以看到当前状态，以决定改调整哪些参数Cretated_tmp_disk_tables 增加tmp_table_sizeHandler_read_key 高表示索引正确Handler_read_rnd高表示索引不正确Key_reads/Key_read_requests 应小于0.01 计算缓存损失率，增加Key_buffer_sizeOpentables/Open_tables 增加table_cacheselect_full_join 没有实用索引的链接的数量。