怎样改进数据库的查询性能

1、使你的数据库结构规范化，但是不要求一定达到第三范式，为了显示和打印目的可以有数据冗余2、评估你的系统中对性能影响的关键处，减少被频繁访问的核心表的数量，并在这些核心

表上重点优化索引，表结构（尽量紧凑）。典型的核心表是代码表。

3、对于统计类应用，如果可能应写成触发器和存储过程，这样就有可能把一个消耗大量时

间的统计运算分布到每INSERT，DELETE，或者UPDATE来处理，从而极大提高查询类 *** 作的速度。

查询选择群居索引最有效。其他索引也要针对业务进行选择。由于维护索引也要消耗系

统资源和时间，所以过多的索引对性能是损害甚至是毫无效果的。

5、如果可能，可以利用大数据库对SQL的一些特殊规定来进一步优化，比如查询暗示。

6、适当选择硬件，综合考虑CPU，内存，I/O系统的性能，以当前的CPU，内存配置来看，

很多数据库系统的瓶颈出在I/O系统上。所以如果有可能，最好使用RAID。

当然如果你有足够的财力，可以买更好的服务器，或者搞服务器集群就更利害啦。

7、可能的话，尽量使用存储过程，因为存储过程的执行计划可以重复使用，而且不需要

象普通由CLIENT提交的SQL那样进行处理和编译。

8、检查你的应用程序设计，如果有可能，尽量减少查询次数和在网络上往返的数据。为了

获取少量字段而写SELECT 对性能的损害也比较利害。

9、在应用程序中协调并发和一致性之间的矛盾。并不是所有业务都需要放在事务中。大量

业务是允许脏读的，在不关键事务中使用脏读，或者读提交，可以大大降低DEADLOCK和

进程之间彼此等待的机会，从而把由于互相锁定资源引起的等待降低到最小。

不要在事务执行中进行大量计算或者与用户交互的 *** 作，因为事务的执行在要求上是

不允许被打断的原子 *** 作（回滚是失败的），所以事务应该多而短小。长事务会锁住

很多资源比较长的时间，因此也比较容易导致其他进程对资源的等待和死锁的机会。

10、评估你开发系统的关键业务，在很多数据库系统对性能的要求是彼此矛盾的，比如OLTP

应用和DSS是不同的。DSS倾向于使用各种索引加快检索速度，而大量的索引对OLTP则是负担。

11、不要在应用程序中写怪异的SQL 查询，比如 WHERE money!40000，这样的语句，这种

SQL查询，数据库的SQL优化器是无法进行优化的。

12、定期维护和管理你的数据库系统，压缩掉那些垃圾空间，很多数据库系统执行类似

删除，事务等 *** 作的时候，并不回收无用的物理空间。所以，制定一份合理的数据库

维护计划，不要等日志文件或者LOG文件越长越大的时候才去整理数据库。

还有很多很多要注意的东西，。。。。。。

如何加快查询速度

1、升级硬件

2、根据查询条件,建立索引,优化索引、优化访问方式，限制结果集的数据量。

3、扩大服务器的内存

4、增加服务器CPU个数

5、对于大的数据库不要设置数据库自动增长，它会降低服务器的性能

6、在查询Select语句中用Where字句限制返回的行数,避免表扫描,如果返回不必要的数据，浪费了服务器的I/O资源，加重了网络的负担降低性能。如果表很大，在表扫描的期间将表锁住，禁止其他的联接访问表,后果严重。

7、查询时不要返回不需要的行、列

8、用select

top

100

/

10

Percent

来限制用户返回的行数或者SET

ROWCOUNT来限制 *** 作的行

9、在IN后面值的列表中，将出现最频繁的值放在最前面，出现得最少的放在最后面，减少判断的次数

10、一般在GROUP

BY

个HAVING字句之前就能剔除多余的行，所以尽量不要用它们来做剔除行的工作。他们的执行顺序应该如下最优：

select的Where字句选择所有合适的行，Group

By用来分组个统计行，Having字句用来剔除多余的分组。这样Group

By

个Having的开销小，查询快对于大的数据行进行分组和Having十分消耗资源。如果Group

BY的目的不包括计算，只是分组，那么用Distinct更快

11、一次更新多条记录比分多次更新每次一条快,就是说批处理好

在公路建设中，通过建立多条车道可以提高道路的流量。其实这个道理在Oracle数据库中也行得通。即可以将关键数据文件存储在多块硬盘上，以提高Oracle数据库的性能。可惜的是，不少数据库管理员没有意识到这一点。在这篇文章中笔者就以Oracle11G为例，说明如何通过在硬盘之间分布关键数据文件来提高性能。 一、在硬盘之间分布关键数据文件的基本原则。

在传统的文件系统上(即不是在裸机上)部署Oracle数据库，可以通过将关键的数据文件分布到多个可用的文件系统上或者不同的硬盘上来提高数据库的性能。具体的来说，需要遵循如下几个原则。

一是对于表来说，往往包含两个部分，即基本表与索引表。只要为基本表中的字段创建了索引，其对应的就有一张索引表。当用户访问表中的数据时，应用系统需要同时访问到索引表与数据表。此时我们可以将这两张表比喻成两辆车。如果现在只有一个车道(即将他们同时存放在一个硬盘或者文件系统中)，那么两辆车必须前后行使。而如果现在有两个车道(即将基本表与其相对应的索引表存放在不同的硬盘或者文件系统中)，那么这两辆车就可以并排行使。显然，后者的效率更高。为此笔者建议，可将经常需要访问的表和与之对应的索引表分开来存放。

二是可以将日志文件也分开来存放。不光光是数据表与索引表存在着这种状况。其实在日志文件管理中也是如此。只要条件允许，那么最好能够将联机重做日志和归档日志与其它数据文件存放在不同的硬盘或者文件系统上。因为当用户往数据库中写入数据时，需要同时往数据文件与重做日志文件中写入数据。此时如果将它们分开来存放，那么就相当于有了多条车道，分别往不同的文件中写入数据。这无疑就可以提高数据写入的效率，从而提高数据库的性能。

二、哪些文件最好能够分开存放

在讲到硬盘之间分布关键数据文件的基本原则的时候，笔者举了几个需要分开存放的几个案例。但是在实际工作中，并不仅仅局限于上面提到的这些文件。笔者认为，如果条件允许的话，那么可以考虑将如下文件放置在不同的硬盘上。

一是表空间，如临时表空间、系统表空间、UNDO表空间等等。这三个表空间可能系统会同时进行访问。为此需要将其分开来存放。二是数据文件和索引文件。上面提到过，需要将经常访问的数据文件与其对应的索引文件存放在不同的硬盘上。因为这两类文件在访问数据时也可能会同时访问到。三是 *** 作系统盘与数据库文件单独存放。显然Oracle系统肯定是与 *** 作系统同时运行的。为了避免他们之间的I/Q冲突，就需要将Oracle部署在 *** 作系统盘以外的磁盘上。四是联机重做日志文件。这个文件比较复杂，不但要将其与其他文件分开来存放。而且还需要注意的是，最好能够将其存放在性能最佳的硬盘上。

最后需要说明的一点是，增加磁盘也会增加成本。这不光光是购买磁盘所需要的花费，还包括管理的成本。所以这之间也会涉及到成本与性能之间的一个均衡问题。如果企业的数据不是很多，或者主要是涉及到查询 *** 作，那么这么设计的话，就可能不怎么合理。因为投入要大于回报。

三、如何确定是否需要将文件分开来存放

在实际工作中，企业的数据是一个从少到多的过程。也就是说，刚开始使用数据库的时候，可能数据量比较少，此时出于成本的考虑，没有将相关文件存放在不同的磁盘上。但是随着工作的深入，用户会发现数据库的性能在逐渐的降低。此时管理员就需要考虑，能够采取这种多建车道的措施，来提高数据库性能。当然在采取这个措施之前，管理员需要先进性评估。此时评估所需要用到的一个指标就是磁盘的I/O争用。

磁盘争用通常发生在有多个进程试图同时访问一个物理磁盘的情况下。如现在用户需要访问某个数据表中的数据，此时系统需要访问索引文件与数据表文件。如果将它们放置在同一磁盘上，那么在访问时就会发生I/O冲突。所以评估I/O冲突的严重程度，可以帮我们来确定是否需要将关键文件存放在不同的磁盘上。

将I/O平均的分布到多个可用的磁盘上，这可以有效的减少磁盘之间的争用情况，提高数据存储与读取的性能。从而提高Oracle等应用程序的效率。在实际工作中，数据库控制文件中有两个参数可以用来帮助我们评估这个指标。这两个参数是文件平均读取时间和文件平均写入时间。不过在使用这两个参数的时候，其只评估所有与数据库相关联的文件。管理员如果有需要的话，也可以通过下面的查询语句来查询数据文件是否存在I/O问题。查询的语法与结果如下图所示：

从如上的查询结果中可以看出某个数据文件是否繁忙，数据文件之间是否存在着/I/O冲突文件。这里需要注意的是，这个结果是一个动态的结果。在不同的时刻、用户进行不同的 *** 作时往往会得出不同的结论。为此笔者建议，在使用这个数据的时候，最好能够多跟踪几次。然后分析多次运行的结果。只有如此，才能够得到比较合乎情理的判断。 通常情况下，管理员根据上面的结果可以得出三种结论。

第一种结论是上面这些数据文件都不是很忙。即文件的平均读取时间与写入时间都比较短，表示这两个文件都是比较空闲的。此时正常情况下，数据库的性能应该是不错的。也就是说，如果此时数据库的性能不理想的话，那么就不是磁盘的I/O所造成的。管理员应该从其他角度来改善数据库的性能。

第二种结论是每个数据库文件都非常的繁忙。此时有可能是读取时间或者写入时间比较长，或者说两个时间都比较长。当多个数据文件同时比较繁忙并且他们处于同一磁盘的话，那么管理员就需要考虑购买新的磁盘，然后将上面提到的这些关键文件重新整理，让他们部署在不同的磁盘上。

第三种结论是某几个特定的数据文件比较繁忙，而其他数据文件还可以。此时管理员如果成本受到限制，那么也不需要重新购买硬盘。在磁盘上的物理写入和读取次数上如果出现比较大的差异，就表明某个磁盘负载过大，即有很严重的I/O冲突。此时最好能够将这个磁盘中的文件进行调整，如将某些文件移动到另外的一块I/O相对不怎么严重的磁盘上。不过在采取这个 *** 作的时候，需要注意一点。对于联机重做日志文件来说，即使其所在的磁盘I/O冲突比较低，或者访问这个文件的时间比较短，但是也不建议将其他数据文件转移到其所在的磁盘上来。因为通常情况下，为了保障数据库的性能，我们都建议将联机重做日志文件单独存放，并且还需要讲起放置在性能比较高的硬盘上。

总之，将关键的Oracle数据库文件分开放置。如此的话可以有效避免磁盘争用成为Oracle数据库系统的性能瓶颈。

我理解的是你希望了解mysql性能测试的方法：

其实常用的一般：

选取最适用的字段属性

MySQL可以很好的支持大数据量的存取，但是一般说来，数据库中的表越小，在它上面执行的查询也就会越快。因此，在创建表的时候，为了获得更好的性能，我们可以将表中字段的宽度设得尽可能小。例如，在定义邮政编码这个字段时，如果将其设置为CHAR(255),显然给数据库增加了不必要的空间，甚至使用VARCHAR这种类型也是多余的，因为CHAR(6)就可以很好的完成任务了。同样的，如果可以的话，我们应该使用MEDIUMINT而不是BIGIN来定义整型字段。

另外一个提高效率的方法是在可能的情况下，应该尽量把字段设置为NOT NULL，这样在将来执行查询的时候，数据库不用去比较NULL值。

对于某些文本字段，例如“省份”或者“性别”，我们可以将它们定义为ENUM类型。因为在MySQL中，ENUM类型被当作数值型数据来处理，而数值型数据被处理起来的速度要比文本类型快得多。这样，我们又可以提高数据库的性能。

2、使用连接（JOIN）来代替子查询(Sub-Queries)

MySQL从41开始支持SQL的子查询。这个技术可以使用SELECT语句来创建一个单列的查询结果，然后把这个结果作为过滤条件用在另一个查询中。例如，我们要将客户基本信息表中没有任何订单的客户删除掉，就可以利用子查询先从销售信息表中将所有发出订单的客户ID取出来，然后将结果传递给主查询，如下所示：

DELETE FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

使用子查询可以一次性的完成很多逻辑上需要多个步骤才能完成的SQL *** 作，同时也可以避免事务或者表锁死，并且写起来也很容易。但是，有些情况下，子查询可以被更有效率的连接（JOIN） 替代。例如，假设我们要将所有没有订单记录的用户取出来，可以用下面这个查询完成：

SELECT FROM customerinfo WHERE CustomerID NOT in (SELECT CustomerID FROM salesinfo )

如果使用连接（JOIN） 来完成这个查询工作，速度将会快很多。尤其是当salesinfo表中对CustomerID建有索引的话，性能将会更好，查询如下：

SELECT FROM customerinfo LEFT JOIN salesinfoON customerinfoCustomerID=salesinfo CustomerID WHERE salesinfoCustomerID IS NULL

连接（JOIN） 之所以更有效率一些，是因为 MySQL不需要在内存中创建临时表来完成这个逻辑上的需要两个步骤的查询工作。

3、使用联合(UNION)来代替手动创建的临时表

MySQL 从 40 的版本开始支持 UNION 查询，它可以把需要使用临时表的两条或更多的 SELECT 查询合并的一个查询中。在客户端的查询会话结束的时候，临时表会被自动删除，从而保证数据库整齐、高效。使用 UNION 来创建查询的时候，我们只需要用 UNION作为关键字把多个 SELECT 语句连接起来就可以了，要注意的是所有 SELECT 语句中的字段数目要想同。下面的例子就演示了一个使用 UNION的查询。

SELECT Name, Phone FROM client UNION SELECT Name, BirthDate FROM author

UNION

SELECT Name, Supplier FROM product

4、事务

尽管我们可以使用子查询（Sub-Queries）、连接（JOIN）和联合（UNION）来创建各种各样的查询，但不是所有的数据库 *** 作都可以只用一条或少数几条SQL语句就可以完成的。更多的时候是需要用到一系列的语句来完成某种工作。但是在这种情况下，当这个语句块中的某一条语句运行出错的时候，整个语句块的 *** 作就会变得不确定起来。设想一下，要把某个数据同时插入两个相关联的表中，可能会出现这样的情况：第一个表中成功更新后，数据库突然出现意外状况，造成第二个表中的 *** 作没有完成，这样，就会造成数据的不完整，甚至会破坏数据库中的数据。要避免这种情况，就应该使用事务，它的作用是：要么语句块中每条语句都 *** 作成功，要么都失败。换句话说，就是可以保持数据库中数据的一致性和完整性。事物以BEGIN 关键字开始，COMMIT关键字结束。在这之间的一条SQL *** 作失败，那么，ROLLBACK命令就可以把数据库恢复到BEGIN开始之前的状态。

BEGIN;

INSERT INTO salesinfo SET CustomerID=14;

UPDATE inventory SET Quantity=11

WHERE item='book';

COMMIT;

事务的另一个重要作用是当多个用户同时使用相同的数据源时，它可以利用锁定数据库的方法来为用户提供一种安全的访问方式，这样可以保证用户的 *** 作不被其它的用户所干扰。

5、锁定表

尽管事务是维护数据库完整性的一个非常好的方法，但却因为它的独占性，有时会影响数据库的性能，尤其是在很大的应用系统中。由于在事务执行的过程中，数据库将会被锁定，因此其它的用户请求只能暂时等待直到该事务结束。如果一个数据库系统只有少数几个用户

来使用，事务造成的影响不会成为一个太大的问题；但假设有成千上万的用户同时访问一个数据库系统，例如访问一个电子商务网站，就会产生比较严重的响应延迟。

其实，有些情况下我们可以通过锁定表的方法来获得更好的性能。下面的例子就用锁定表的方法来完成前面一个例子中事务的功能。

LOCK TABLE inventory WRITE

SELECT Quantity FROM inventory

WHEREItem='book';

UPDATE inventory SET Quantity=11

WHEREItem='book';

UNLOCK TABLES

这里，我们用一个 SELECT 语句取出初始数据，通过一些计算，用 UPDATE 语句将新值更新到表中。包含有 WRITE 关键字的 LOCK TABLE 语句可以保证在 UNLOCK TABLES 命令被执行之前，不会有其它的访问来对 inventory 进行插入、更新或者删除的 *** 作。

6、使用外键

锁定表的方法可以维护数据的完整性，但是它却不能保证数据的关联性。这个时候我们就可以使用外键。例如，外键可以保证每一条销售记录都指向某一个存在的客户。在这里，外键可以把customerinfo 表中的CustomerID映射到salesinfo表中CustomerID，任何一条没有合法CustomerID的记录都不会被更新或插入到salesinfo中。

CREATE TABLE customerinfo

(

CustomerID INT NOT NULL ,

PRIMARY KEY ( CustomerID )

) TYPE = INNODB;

CREATE TABLE salesinfo

(

SalesID INT NOT NULL,

CustomerID INT NOT NULL,

PRIMARY KEY(CustomerID, SalesID),

FOREIGN KEY (CustomerID) REFERENCES customerinfo

(CustomerID) ON DELETECASCADE

) TYPE = INNODB;

注意例子中的参数“ON DELETE CASCADE”。该参数保证当 customerinfo 表中的一条客户记录被删除的时候，salesinfo 表中所有与该客户相关的记录也会被自动删除。如果要在 MySQL 中使用外键，一定要记住在创建表的时候将表的类型定义为事务安全表 InnoDB类型。该类型不是 MySQL 表的默认类型。定义的方法是在 CREATE TABLE 语句中加上 TYPE=INNODB。如例中所示。

7、使用索引

索引是提高数据库性能的常用方法，它可以令数据库服务器以比没有索引快得多的速度检索特定的行，尤其是在查询语句当中包含有MAX(), MIN()和ORDERBY这些命令的时候，性能提高更为明显。那该对哪些字段建立索引呢？一般说来，索引应建立在那些将用于JOIN, WHERE判断和ORDER BY排序的字段上。尽量不要对数据库中某个含有大量重复的值的字段建立索引。对于一个ENUM类型的字段来说，出现大量重复值是很有可能的情况，例如customerinfo中的“province” 字段，在这样的字段上建立索引将不会有什么帮助；相反，还有可能降低数据库的性能。我们在创建表的时候可以同时创建合适的索引，也可以使用ALTER TABLE或CREATE INDEX在以后创建索引。此外，MySQL

从版本32323开始支持全文索引和搜索。全文索引在MySQL 中是一个FULLTEXT类型索引，但仅能用于MyISAM 类型的表。对于一个大的数据库，将数据装载到一个没有FULLTEXT索引的表中，然后再使用ALTER TABLE或CREATE INDEX创建索引，将是非常快的。但如果将数据装载到一个已经有FULLTEXT索引的表中，执行过程将会非常慢。

8、优化的查询语句

绝大多数情况下，使用索引可以提高查询的速度，但如果SQL语句使用不恰当的话，索引将无法发挥它应有的作用。下面是应该注意的几个方面。首先，最好是在相同类型的字段间进行比较的 *** 作。在MySQL 323版之前，这甚至是一个必须的条件。例如不能将一个建有索引的INT字段和BIGINT字段进行比较；但是作为特殊的情况，在CHAR类型的字段和VARCHAR类型字段的字段大小相同的时候，可以将它们进行比较。其次，在建有索引的字段上尽量不要使用函数进行 *** 作。

例如，在一个DATE类型的字段上使用YEAE()函数时，将会使索引不能发挥应有的作用。所以，下面的两个查询虽然返回的结果一样，但后者要比前者快得多。

SELECT FROM order WHERE YEAR(OrderDate)<2001;

SELECT FROM order WHERE OrderDate<"2001-01-01";

同样的情形也会发生在对数值型字段进行计算的时候：

SELECT FROM inventory WHERE Amount/7<24;

SELECT FROM inventory WHERE Amount<247;

上面的两个查询也是返回相同的结果，但后面的查询将比前面的一个快很多。第三，在搜索字符型字段时，我们有时会使用 LIKE 关键字和通配符，这种做法虽然简单，但却也是以牺牲系统性能为代价的。例如下面的查询将会比较表中的每一条记录。

SELECT FROM books

WHERE name like "MySQL%"

但是如果换用下面的查询，返回的结果一样，但速度就要快上很多：

SELECT FROM books

WHERE name>="MySQL"and name<"MySQM"

最后，应该注意避免在查询中让MySQL进行自动类型转换，因为转换过程也会使索引变得不起作用。

1、使用系统性能监视器监视当前SQL的工作性能（控制面板-->管理工具-->性能）可以查看SQL对磁盘、内存的总体占用

2、使用SQL 性能监视器（SQL Profiler）可以查看SQL 的执行事件，读写次数，起始和结束事件等等，可以保存死锁图形。

在开始演示之前，我们先介绍下两个概念。

概念一，数据的可选择性基数，也就是常说的cardinality值。

查询优化器在生成各种执行计划之前，得先从统计信息中取得相关数据，这样才能估算每步 *** 作所涉及到的记录数，而这个相关数据就是cardinality。简单来说，就是每个值在每个字段中的唯一值分布状态。

比如表t1有100行记录，其中一列为f1。f1中唯一值的个数可以是100个，也可以是1个，当然也可以是1到100之间的任何一个数字。这里唯一值越的多少，就是这个列的可选择基数。

那看到这里我们就明白了，为什么要在基数高的字段上建立索引，而基数低的的字段建立索引反而没有全表扫描来的快。当然这个只是一方面，至于更深入的探讨就不在我这篇探讨的范围了。

概念二，关于HINT的使用。

这里我来说下HINT是什么，在什么时候用。

HINT简单来说就是在某些特定的场景下人工协助MySQL优化器的工作，使她生成最优的执行计划。一般来说，优化器的执行计划都是最优化的，不过在某些特定场景下，执行计划可能不是最优化。

比如：表t1经过大量的频繁更新 *** 作，（UPDATE,DELETE,INSERT），cardinality已经很不准确了，这时候刚好执行了一条SQL，那么有可能这条SQL的执行计划就不是最优的。为什么说有可能呢？

来看下具体演示

譬如，以下两条SQL，

A：

select from t1 where f1 = 20;

B：

select from t1 where f1 = 30;

如果f1的值刚好频繁更新的值为30，并且没有达到MySQL自动更新cardinality值的临界值或者说用户设置了手动更新又或者用户减少了sample page等等，那么对这两条语句来说，可能不准确的就是B了。

这里顺带说下，MySQL提供了自动更新和手动更新表cardinality值的方法，因篇幅有限，需要的可以查阅手册。

那回到正题上，MySQL 80 带来了几个HINT，我今天就举个index_merge的例子。

示例表结构：

mysql> desc t1;+------------+--------------+------+-----+---------+----------------+| Field      | Type         | Null | Key | Default | Extra          |+------------+--------------+------+-----+---------+----------------+| id         | int(11)      | NO   | PRI | NULL    | auto_increment || rank1      | int(11)      | YES  | MUL | NULL    |                || rank2      | int(11)      | YES  | MUL | NULL    |                || log_time   | datetime     | YES  | MUL | NULL    |                || prefix_uid | varchar(100) | YES  |     | NULL    |                || desc1      | text         | YES  |     | NULL    |                || rank3      | int(11)      | YES  | MUL | NULL    |                |+------------+--------------+------+-----+---------+----------------+7 rows in set (000 sec)

表记录数：

mysql> select count() from t1;+----------+| count() |+----------+|    32768 |+----------+1 row in set (001 sec)

这里我们两条经典的SQL：

SQL C：

select from t1 where rank1 = 1 or rank2 = 2 or rank3 = 2;

SQL D：

select from t1 where rank1 =100  and rank2 =100  and rank3 =100;

表t1实际上在rank1,rank2,rank3三列上分别有一个二级索引。

那我们来看SQL C的查询计划。

显然，没有用到任何索引，扫描的行数为32034，cost为324365。

mysql> explain  format=json select from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "324365"    },    "table": {      "table_name": "t1",      "access_type": "ALL",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "rows_examined_per_scan": 32034,      "rows_produced_per_join": 115,      "filtered": "036",      "cost_info": {        "read_cost": "323207",        "eval_cost": "1158",        "prefix_cost": "324365",        "data_read_per_join": "49K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们加上hint给相同的查询，再次看看查询计划。

这个时候用到了index_merge,union了三个列。扫描的行数为1103，cost为44109，明显比之前的快了好几倍。

mysql> explain  format=json select /+ index_merge(t1) / from t1  where rank1 =1 or rank2 = 2 or rank3 = 2\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "44109"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "union(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1103,      "rows_produced_per_join": 1103,      "filtered": "10000",      "cost_info": {        "read_cost": "33079",        "eval_cost": "11030",        "prefix_cost": "44109",        "data_read_per_join": "473K"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank1` = 1) or (`ytt``t1``rank2` = 2) or (`ytt``t1``rank3` = 2))"    }  }}1 row in set, 1 warning (000 sec)

我们再看下SQL D的计划：

不加HINT，

mysql> explain format=json select from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "53434"    },    "table": {      "table_name": "t1",      "access_type": "ref",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "idx_rank1",      "used_key_parts": [        "rank1"      ],      "key_length": "5",      "ref": [        "const"      ],      "rows_examined_per_scan": 555,      "rows_produced_per_join": 0,      "filtered": "007",      "cost_info": {        "read_cost": "47884",        "eval_cost": "004",        "prefix_cost": "53434",        "data_read_per_join": "176"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100))"    }  }}1 row in set, 1 warning (000 sec)

加了HINT，

mysql> explain format=json select /+ index_merge(t1)/ from t1 where rank1 =100 and rank2 =100 and rank3 =100\G 1 row EXPLAIN: {  "query_block": {    "select_id": 1,    "cost_info": {      "query_cost": "523"    },    "table": {      "table_name": "t1",      "access_type": "index_merge",      "possible_keys": [        "idx_rank1",        "idx_rank2",        "idx_rank3"      ],      "key": "intersect(idx_rank1,idx_rank2,idx_rank3)",      "key_length": "5,5,5",      "rows_examined_per_scan": 1,      "rows_produced_per_join": 1,      "filtered": "10000",      "cost_info": {        "read_cost": "513",        "eval_cost": "010",        "prefix_cost": "523",        "data_read_per_join": "440"      },      "used_columns": [        "id",        "rank1",        "rank2",        "log_time",        "prefix_uid",        "desc1",        "rank3"      ],      "attached_condition": "((`ytt``t1``rank3` = 100) and (`ytt``t1``rank2` = 100) and (`ytt``t1``rank1` = 100))"    }  }}1 row in set, 1 warning (000 sec)

对比下以上两个，加了HINT的比不加HINT的cost小了100倍。

总结下，就是说表的cardinality值影响这张的查询计划，如果这个值没有正常更新的话，就需要手工加HINT了。相信MySQL未来的版本会带来更多的HINT。

以上就是关于怎样改进数据库的查询性能全部的内容，包括:怎样改进数据库的查询性能、sql语句性能如何优化、如何提高oracle数据库的性能 / 查查362等相关内容解答，如果想了解更多相关内容，可以关注我们，你们的支持是我们更新的动力！