mysql use index （） 优化查询的例子

USE INDEX
在你查询语句中表名的后面，添加 USE INDEX 来提供你希望 MySQ 去参考的索引列
表，就可以让 MySQL 不再考虑其他可用的索引。
Eg:SELECT * FROM mytable USE INDEX (mod_time, name) ...
?
IGNORE INDEX
如果你只是单纯的想让 MySQL 忽略一个或者多个索引，可以使用 IGNORE INDEX 作
为 Hint。
Eg:SELECT * FROM mytale IGNORE INDEX (priority) ...
?
FORCE INDEX
为强制 MySQL 使用一个特定的索引，可在查询中使用 FORCE INDEX 作为 Hint。
Eg:SELECT * FROM mytable FORCE INDEX (mod_time) ...

FORCE INDEX 通常用来对查询强制使用一个或者多个索引。 MySQL 通常会根据统计信息选择正确的索引，但是当查询优化器选择了错误的索引或者根本没有使用索引的时候，这个提示将非常有用。

IGNORE INDEX 提示会禁止查询优化器使用指定的索引。在具有多个索引的查询时，可以用来指定不需要优化器使用的那个索引，还可以在删除不必要的索引之前在查询中禁止使用该索引。

FORCE INDEX/IGNORE INDEX 的语法：

SELECT *** FROM TABLE [{USE|IGNORE|FORCE} INDEX (key_list)] WHERE ……

下面的例子是使用 IGNORE INDEX 以后，执行计划的变化情况，默认的执行计划是按照主键索引进行扫描，如果我们使用 IGNORE INDEX 忽略主键索引，则会按照全表扫描执行：

mysql> desc select count(*) from test3 where id = 1 \G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: test3

type: const

possible_keys: PRIMARY

key: PRIMARY

key_len: 4

ref: const

rows: 1

Extra: Using index

1 row in set (0.00 sec)

mysql> desc select count(*) from test3 ignore index (primary) where id = 1 \G

*************************** 1. row ***************************

id: 1

select_type: SIMPLE

table: test3

type: ALL

possible_keys: NULL

key: NULL

key_len: NULL

ref: NULL

rows: 862560

Extra: Using where

1 row in set (0.00 sec)

使用use index优化sql查询

先看一下arena_match_index的表结构，大家注意表的索引结构
CREATE TABLE `arena_match_index` (
  `tid` int(10) unsigned NOT NULL DEFAULT ‘0‘,
  `mid` int(10) unsigned NOT NULL DEFAULT ‘0‘,
  `group` int(10) unsigned NOT NULL DEFAULT ‘0‘,
  `round` tinyint(3) unsigned NOT NULL DEFAULT ‘0‘,
  `day` date NOT NULL DEFAULT ‘0000-00-00‘,
  `begintime` datetime NOT NULL DEFAULT ‘0000-00-00 00:00:00‘,
  UNIQUE KEY `tm` (`tid`,`mid`),
  KEY `mid` (`mid`),
  KEY `begintime` (`begintime`),
  KEY `dg` (`day`,`group`),
  KEY `td` (`tid`,`day`)
) ENGINE=MyISAM DEFAULT CHARSET=utf8
 
接着看下面的sql：
SELECT round  FROM arena_match_index WHERE `day` = ‘2010-12-31‘ AND `group` = 18 AND `begintime` < ‘2010-12-31 12:14:28‘order by begintime LIMIT 1; 
这条sql的查询条件显示可能使用的索引有`begintime`和`dg`，但是由于使用了order by begintime排序mysql最后选择使用`begintime`索引，explain的结果为：
 
mysql> explain SELECT round  FROM arena_match_index  WHERE `day` = ‘2010-12-31‘ AND `group` = 18 AND `begintime` < ‘2010-12-31 12:14:28‘ order by begintime LIMIT 1;
+----+-------------+-------------------+-------+---------------+-----------+---------+------+--------+-------------+
| id | select_type | table             | type  | possible_keys | key       | key_len | ref  | rows   | Extra       |
+----+-------------+-------------------+-------+---------------+-----------+---------+------+--------+-------------+
|  1 | SIMPLE      | arena_match_index | range | begintime,dg  | begintime | 8       | NULL | 226480 | Using where | 
+----+-------------+-------------------+-------+---------------+-----------+---------+------+--------+-------------+
explain的结果显示使用`begintime`索引要扫描22w条记录，这样的查询性能是非常糟糕的，实际的执行情况也是初次执行（还未有缓存数据时）时需要30秒以上的时间。
 
实际上这个查询使用`dg`联合索引的性能更好，因为同一天同一个小组内也就几十场比赛，因此应该优先使用`dg`索引定位到匹配的数据集合再进行排序，那么如何告诉mysql使用指定索引呢？使用use index语句：
mysql> explain SELECT round  FROM arena_match_index use index (dg) WHERE `day` = ‘2010-12-31‘ AND `group` = 18 AND `begintime` < ‘2010-12-31 12:14:28‘ order by begintime LIMIT 1;
+----+-------------+-------------------+------+---------------+------+---------+-------------+------+-----------------------------+
| id | select_type | table             | type | possible_keys | key  | key_len | ref         | rows | Extra                       |
+----+-------------+-------------------+------+---------------+------+---------+-------------+------+-----------------------------+
|  1 | SIMPLE      | arena_match_index | ref  | dg            | dg   | 7       | const,const |  757 | Using where; Using filesort | 
+----+-------------+-------------------+------+---------------+------+---------+-------------+------+-----------------------------+
explain结果显示使用`dg`联合索引只需要扫描757条数据，性能直接提升了上百倍，实际的执行情况也是几乎立即就返回了查询结果。

在最初的查询语句中只要把order by begintime去掉，mysql就会使用`dg`索引了，再次印证了order by会影响mysql的索引选择策略！
mysql> explain SELECT round  FROM arena_match_index  WHERE `day` = ‘2010-12-31‘ AND `group` = 18 AND `begintime` < ‘2010-12-31 12:14:28‘  LIMIT 1;
+----+-------------+-------------------+------+---------------+------+---------+-------------+------+-------------+
| id | select_type | table             | type | possible_keys | key  | key_len | ref         | rows | Extra       |
+----+-------------+-------------------+------+---------------+------+---------+-------------+------+-------------+
|  1 | SIMPLE      | arena_match_index | ref  | begintime,dg  | dg   | 7       | const,const |  717 | Using where | 
+----+-------------+-------------------+------+---------------+------+---------+-------------+------+-------------+

通过上面的例子说mysql有时候也并不聪明，并非总能做出最优选择，还是需要我们开发者对它进行“调教”！

原文地址：https://www.cnblogs.com/jpfss/p/9155039.html

时间： 2024-10-06 22:33:27

mysql use index （） 优化查询的例子的相关文章

mysql&#160;use&#160;index()&#160;优化查询

mysql use index() 优化查询 FORCE INDEX/IGNORE INDEX 的语法: SELECT *** FROM TABLE [{USE|IGNORE|FORCE} INDEX (key_list)] WHERE …… USE INDEX 在你查询语句中表名的后面,添加 USE INDEX 来提供你希望 MySQ 去参考的索引列 表,就可以让 MySQL 不再考虑其他可用的索引. Eg:SELECT * FROM mytable USE INDEX (mod_time,

mysql使用索引优化查询效率

索引的概念 索引是一种特殊的文件(InnoDB数据表上的索引是表空间的一个组成部分),它们包含着对数据表里所有记录的引用指针.更通俗的说,数据库索引好比是一本书前面的目录,能加快数据库的查询速度.在没有索引的情况下,数据库会遍历全部数据后选择符合条件的:而有了相应的索引之后,数据库会直接在索引中查找符合条件的选项.如果我们把SQL语句换成"SELECT * FROM 表名 WHERE id=2000000",那么你是希望数据库按照顺序读取完200万行数据以后给你结果还是直接在索引中定位

MySQL索引和优化查询

来自:http://blog.chinaunix.net/uid-29532375-id-4144615.html 索引和优化查询 恰当的索引可以加快查询速度,可以分为四种类型:主键.唯一索引.全文索引.普通索引.主键:唯一且没有null值.create table pk_test(f1 int not null,primary key(f1));alter table customer modify id int not null, add primary key(id);普通索引:允许重复的

mysql force index 优化案例

1. ct_monitor 表记录200多万条记录 2. device 表 45 条记录 3. 两个表进行join并排序 需要 16.750 秒 我们一看,就知道这个结果 明显的 不符合常识!!! 如果我们 先查 ct_monitor 表的 主键 排序之后的 6条记录,然后用那6条记录来关联 device表,根本不可能需要16秒的时间!!!! 4. 如果去掉 order by mm.id desc 时,只需要 0.001 秒: 可以看到问题主要是 order by mm.id desc 导致了使

mysql数据库性能优化 - 查询缓存

查询缓存       缓存机制简单的说就是缓存sql文本和查询结果,如果运行相同的sql,服务器直接从缓存中取到结果,而不需要去解析和执行sql,如果表更改了,那么使用这个表的所有缓存查询将不再有效,查询缓存值的相关条目被清空.更改指的是表中任何数据或是结构的改变,包括insert.update.delete.truncate.alter table.drop table或drop database等.这对频繁更新的表,查询缓存是不适合的,而对一些不常改变数据且大量相同的sql查询的表,查询缓存

MySQL 千万 级数据量根据（索引）优化 查询 速度

一.索引的作用 索引通俗来讲就相当于书的目录,当我们根据条件查询的时候,没有索引,便需要全表扫描,数据量少还可以,一旦数据量超过百万甚至千万,一条查询sql执行往往需要几十秒甚至更多,5秒以上就已经让人难以忍受了. 提升查询速度的方向一是提升硬件(内存.cpu.硬盘),二是在软件上优化(加索引.优化sql:优化sql不在本文阐述范围之内). 能在软件上解决的,就不在硬件上解决,毕竟硬件提升代码昂贵,性价比太低.代价小且行之有效的解决方法就是合理的加索引. 索引使用得当,能使查询速度提升上万倍,效

30.5. MySQL用户,权限,服务器配置,查询缓存及优化,索引等

MySQL用户和权限管理 元数据数据库:mysql系统授权表:db, host, usercolumns_priv, tables_priv, procs_priv, proxies_priv 用户账号:'USERNAME'@'HOST' @'HOST': 主机名 IP地址或Network可用通配符: % _示例:172.16.%.% 用户管理 创建用户:CREATE USERCREATE USER 'USERNAME'@'HOST' [IDENTIFIED BY 'password']:默认权

高性能mysql 第6章 查询性能优化

在mysql的执行计划中: id id用来表示执行顺序,id相同的为一组,先执行id数字大的组,然后执行数字小的组.在id相同的一组内,顺序由上而下执行. type 表示MySQL在表中找到所需行的方式,又称"访问类型",常见类型如下: 由左至右,由最差到最好. ALL代表全表扫描,index代表索引全扫描,range索引范围扫描,ref是非唯一性索引扫描,常见的是作用在=的比较上,但是非唯一.eq_ref:唯一性索引扫描. possible_keys 指出MySQL能使用哪个索引在表

mysql数据库添加索引优化查询效率

项目中如果表中的数据过多的话,会影响查询的效率,那么我们需要想办法优化查询,通常添加索引就是我们的选择之一: 1.添加PRIMARY KEY(主键索引) mysql>ALTER TABLE `table_name` ADD PRIMARY KEY ( `column` ) 2.添加UNIQUE(唯一索引) mysql>ALTER TABLE `table_name` ADD UNIQUE ( `column` ) 3.添加INDEX(普通索引) mysql>ALTER TABLE `ta