概述

FORCEINDEX 是 MySQL 中的一种提示，用于强制查询优化器使用指定的索引。在以下场景中可以使用 FORCEINDEX： 优化查询性能 跳过不必要的索引扫描 强制查询器使用覆盖索引 模拟索引失效的情况

MySQL FORCEINDEX 语法

FORCEINDEX 提示的语法如下： FORCE INDEX (index_name) 其中，`index_name` 是要强制使用的索引的名称。

MySQL FORCEINDEX 示例

为了展示 FORCEINDEX 的用法，我们将使用以下表结构和数据： CREATE TABLE marks ( id INT NOT NULL AUTO_INCREMENT, name VARCHAR(255) NOT NULL, mark INT NOT NULL, PRIMARY KEY (id) ); INSERT INTO marks (name, mark) VALUES ('Alice', 85), ('Bob', 75), ('Carol', 90), ('Dave', 60), ('Eve', 80);

示例 1：优化查询性能

假设我们想要查找成绩在 50 到 100 之间的学生。我们首先尝试不使用 FORCEINDEX： EXPLAIN SELECT FROM marks WHERE mark BETWEEN 50 AND 100; 输出如下： +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ | 1 | SIMPLE | marks | ALL | NULL | NULL | NULL | NULL | 20 | Using where | +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ 可以看出，查询优化器选择了全表扫描，因为没有可用的索引。 现在，我们使用 FORCEINDEX 指定使用 `ind_mark`索引： EXPLAIN SELECT FROM marks FORCE INDEX (ind_mark) WHERE mark BETWEEN 50 AND 100; 输出如下： +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ | 1 | SIMPLE | marks | ref | ind_mark | ind_mark | 4 | NULL | 14 | Using index | +----+-------------+----------+------+---------------+------+---------+------+---------+-------------+ 可以看到，查询优化器现在使用了 `ind_mark` 索引，从而提高了查询性能。

示例 2：强制查询器使用覆盖索引

假设我们想要查找成绩在 50 到 100 之间并且姓名为 Alice 的学生。我们可以使用覆盖索引来优化此查询： CREATE INDEX idx_marks_name ON marks (mark, name); 现在，我们可以使用 FORCEINDEX 强制查询器使用此覆盖索引： EXPLAIN SELECT FROM marks FORCE INDEX (idx_marks_name) WHERE mark BETWEEN 50 AND 100 AND name = 'Alice'; 输出如下： +----+-------------+----------+------+---------------+------+---------+------+---------+-------+ | id | select_type | table | type | possible_keys | key | key_len | ref | rows | Extra | +----+-------------+----------+------+---------------+------+---------+------+---------+-------+ | 1 | SIMPLE | marks | ref | idx_marks_name | idx_marks_name | 8 | NULL | 1 | Using index | +----+-------------+----------+------+---------------+------+---------+------+---------+-------+ 可以看到，查询优化器现在使用了覆盖索引，从而避免了回表查找。

结论

FORCEINDEX 提示是一个有用的工具，可以帮助优化 MySQL 查询性能。它允许您强制查询优化器使用指定的索引，即使查询优化器认为不适合这样做。 但是，重要的是要谨慎使用 FORCEINDEX，因为它可能会导致查询性能下降，特别是当指定的索引不是最适合的索引时。因此，在使用 FORCEINDEX 之前，请务必评估其影响并进行测试。

---

mysql分享建表和索引的几点规范

一、 MySQL建表，字段需设置为非空，需设置字段默认值。 二、 MySQL建表，字段需NULL时，需设置字段默认值，默认值不为NULL。 三、 MySQL建表，如果字段等价于外键，应在该字段加索引。 四、 MySQL建表，不同表之间的相同属性值的字段，列类型，类型长度，是否非空，是否默认值，需保持一致，否则无法正确使用索引进行关联对比。 五、 MySQL使用时，一条SQL语句只能使用一个表的一个索引。 所有的字段类型都可以索引，多列索引的属性最多15个。 六、 如果可以在多个索引中进行选择，MySQL通常使用找到最少行的索引，索引唯一值最高的索引。 七、 建立索引index（part1,part2,part3）,相当于建立了 index(part1),index(part1,part2)和index（part1,part2,part3）三个索引。 八、 MySQL针对like语法必须如下格式才使用索引：SELECT * FROM t1 WHERE key_col LIKE ab% ；九、 SELECT COUNT(*) 语法在没有where条件的语句中执行效率没有SELECT COUNT(col_name)快，但是在有where条件的语句中执行效率要快。 十、 在where条件中多个and的条件中，必须都是一个多列索引的key_part属性而且必须包含key_part1。 各自单一索引的话，只使用遍历最少行的那个索引。 十一、 在where条件中多个or的条件中，每一个条件，都必须是一个有效索引。 十二、 ORDER BY 后面的条件必须是同一索引的属性，排序顺序必须一致（比如都是升序或都是降序）。 十三、 所有GROUP BY列引用同一索引的属性，并且索引必须是按顺序保存其关键字的。 十四、 JOIN 索引，所有匹配ON和where的字段应建立合适的索引。 十五、 对智能的扫描全表使用FORCE INDEX告知MySQL，使用索引效率更高。 十六、 定期ANALYZE TABLE tbl_name为扫描的表更新关键字分布 。 十七、 定期使用慢日志检查语句，执行explain，分析可能改进的索引。 十八、 条件允许的话，设置较大的key_buffer_size和query_cache_size的值（全局参数），和sort_buffer_size的值（session变量，建议不要超过4M）。 备注主键的命名采用如下规则：主键名用pk_开头，后面跟该主键所在的表名。 主键名长度不能超过30个字符。 如果过长，可对表名进行缩写。 缩写规则同表名的缩写规则。 主键名用小写的英文单词来表示。 外键的命名采用如下规则：外键名用fk_开头，后面跟该外键所在的表名和对应的主表名（不含t_）。 子表名和父表名自己用下划线（_）分隔。 外键名长度不能超过30个字符。 如果过长，可对表名进行缩写。 缩写规则同表名的缩写规则。 外键名用小写的英文单词来表示。 索引的命名采用如下规则：1）索引名用小写的英文字母和数字表示。 索引名的长度不能超过30个字符。 2）主键对应的索引和主键同名。 3）唯一性索引用uni_开头，后面跟表名。 一般性索引用ind_开头，后面跟表名。 4）如果索引长度过长，可对表名进行缩写。 缩写规则同表名的缩写规则index 相关语法CREATE INDEX log_url ON logaudit_log(url);show index from logaudit_logdrop index log_request_time on logaudit_logsql执行效率检测 mysql explainexplain显示了mysql如何使用索引来处理select语句以及连接表。 可以帮助选择更好的索引和写出更优化的查询语句。 使用方法，在select语句前加上explain就可以了：如：explain select surname,first_name form a,b where =分析结果形式如下：table | type | possible_keys | key | key_len | ref | rows | ExtraEXPLAIN列的解释：table显示这一行的数据是关于哪张表的type这是重要的列，显示连接使用了何种类型。 从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALLpossible_keys显示可能应用在这张表中的索引。 如果为空，没有可能的索引。 可以为相关的域从WHERE语句中选择一个合适的语句key实际使用的索引。 如果为NULL，则没有使用索引。 很少的情况下，MYSQL会选择优化不足的索引。 这种情况下，可以在SELECT语句中使用USEINDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引key_len使用的索引的长度。 在不损失精确性的情况下，长度越短越好ref显示索引的哪一列被使用了，如果可能的话，是一个常数rowsMYSQL认为必须检查的用来返回请求数据的行数Extra关于MYSQL如何解析查询的额外信息。 将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢extra列返回的描述的意义Distinct一旦MYSQL找到了与行相联合匹配的行，就不再搜索了Not existsMYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了Range checked for eachRecord（index map:#）没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。 这是使用索引的最慢的连接之一Using filesort看到这个的时候，查询就需要优化了。 MYSQL需要进行额外的步骤来发现如何对返回的行排序。 它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行Using index列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候Using temporary看到这个的时候，查询需要优化了。 这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上Where used使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。 如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序）system表只有一行：system表。 这是const连接类型的特殊情况const表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。 因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待eq_ref在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用ref这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。 对于之前的表的每一个行联合，全部记录都将从表中读出。 这个类型严重依赖于根据索引匹配的记录多少—越少越好range这个连接类型使用索引返回一个范围中的行，比如使用>或FAQ1表中包含 10 万条记录，有一个 datetime 类型的字段。 取数据的语句：SELECT * FROM my_table WHERE created_at < 2010-01-20;用 EXPLAIN 检查，发现 type 是 ALL， key 是 NULL，根本没用上索引。 可以确定的是，created_at 字段设定索引了。 什么原因呢？用 SELECT COUNT(*) 看了一下符合 WHERE 条件的记录总数，居然是 6W 多条！！难怪不用索引，这时用索引毫无意义，就好像 10 万条记录的用户表，有个性别字段，不是男就是女，在这种字段设置索引是错误的决定。 稍微改造一下上述语句：SELECT * FROM my_table WHERE created_at BETWEEN 2009-12-06 AND 2010-01-20;这回问题解决！符合条件的记录只有几百条，EXPLAIN 的 type 是 range，key 是 created_at，Extra 是 Using where 。 自己总结个准则，索引的目的就是尽量缩小结果集，这样才能做到快速查询。 6万条记录符合条件，已经超出总记录数的一半，这时索引已经没有意义了，因此 MySQL 放弃使用索引。 这与设置 gender 字段，并加上索引的情况相似，当你要把所有男性记录都选取出来，符合条件的记录数约占总数的一半，MySQL 同样不会使用这个索引。 唯一值越多的字段，使用索引的效果越好。 设置联合索引时，唯一值越多的，越应该放在“左侧”。

mysql添加索引后在查询的时候是mysql自动从索引里面查询还是查询的时候有单独的参数查询索引？

MYSQL在创建索引后对索引的使用方式分为两种：\x0d\x0a1 由数据库的查询优化器自动判断是否使用索引；\x0d\x0a2 用户可在写SQL语句时强制使用索引\x0d\x0a\x0d\x0a下面就两种索引使用方式进行说明\x0d\x0a第一种，自动使用索引。 数据库在收到查询语句后会查看where语句后面的查询条件，同时查看在表上面有哪些索引，然后根据查询条件和索引进行匹配。 \x0d\x0a查询条件和索引的匹配包括查询字段与索引字段的匹配和查询类型和索引类型的匹配。 前者很好理解，就是查询条件的属性上要建有索引，后者则是说查询条件必须能够使用索引，比如等值判断和范围查询可以使用B+树索引，而hash索引只能适用于等值判断。 \x0d\x0a在找到与查询条件匹配的索引后，就是进行代价估计来决定是否使用索引，代价估计主要根据要访问的就数量，一般来说如果通过索引访问的记录数量占全表记录数量15%以上，则不会使用索引而是使用全表扫描，因为此时使用索引的代价更大。 在大多数情况下使用索引是会提高效率的。 \x0d\x0a经过优化器的判断，最终会决定是否使用索引\x0d\x0a \x0d\x0a第二种，强制使用索引，主要是通过SQL语句实现的\x0d\x0aselect * from table force index(PRI) limit 2;(强制使用主键)\x0d\x0aselect * from table force index(ziduan1_index) limit 2;(强制使用索引ziduan1_index)\x0d\x0aselect * from table force index(PRI,ziduan1_index) limit 2;(强制使用索引PRI和ziduan1_index)\x0d\x0a也可以禁止索引的使用\x0d\x0aselect * from table ignore index(PRI) limit 2;(禁止使用主键)\x0d\x0aselect * from table ignore index(ziduan1_index) limit 2;(禁止使用索引ziduan1_index)\x0d\x0aselect * from table ignore index(PRI,ziduan1_index) limit 2;(禁止使用索引PRI,ziduan1_index)