mysql hint优化器提示之使用force index 强制使用索引和指定禁用索引

1、mysql强制使用主键索引

2、强制指定一个特定索引

3、同时指定两个

4、在多个表join中强制使用索引

select * from table ignore index(PRI) limit 2(禁止使用主键)

select * from table ignore index(idx) limit 2(禁止使用索引”idx”)

select * from table ignore index(PRI,idx) limit 2(禁止使用索引”PRI,idx”)

force index 不建议使用，如果数据量有变化，指定的索引可能不是最佳的

where条件==>order by 条件==>group by 条件 按顺序遵守 最佳左前缀法则

假设创建了复合索引：a,b,c

不在索引列上做任何的 *** 作（计算、函数、显式或隐式的类型转换），否则会导致索引失效而转向全表扫描

1、字符不加单引号会导致索引失效

name字段为varchar类型

这条sql发生了隐式的类型转换：数值==>字符串。所以导致了全表扫描，索引失效

应尽量避免在 where 子句中对字段进行表达式 *** 作，这将导致引擎放弃使用索引而进行全表扫描。如：

mysql中的范围条件有：in/not in、 like、 <>、BETWEEN AND ；

<>后面的索引失效

in会导致索引全部失效！！！

BETWEEN AND 范围条件不会导致索引失效！！！

尽量让索引列和查询列一致；减少select * 的使用

1、查询表结构

2、查询表的索引结构

联合索引：name,age,post；说明add_time字段没有添加索引

3、查看select * 的执行计划

4、查看 select name,age,pos的执行计划

5、如果select只用一部分索引

like以通配符开头（’%abc…’）mysql索引失效会变成全表扫描的 *** 作。

解决：可以使用 覆盖索引 来解决这个问题！

1、先查看表上的索引

id、name、age、pos 四个字段上都有索引； 注意：name是联合索引中的第一个，带头大哥！

2、查看表结构

有个add_time字段没有用到索引

3、查看执行计划

使用UNION ALL

假设创建了联合索引 x(a,b,c)

ps：like虽然也是范围查询但是区别于>、<，%用在最前面就只用到索引a了；%用在最后面可以用到a+b+c！

下面的sql几乎违背了上面的所有原则，索引依然全部生效。因为select是索引覆盖的，select里不包含没有建立索引的字段。因此总是用到索引的。可以看出来索引覆盖在sql优化中的作用性

损坏mysql数据表的索引

mysql表索引被破坏的问题及解决

下午上班，惊闻我的dedecms的网站出问题了，访问一看，果然全屏报错，检查mysql日志，错误信息为：

Table '.\dedecmsv4\dede_archives' is marked as crashed and should be repaired

提示说cms的文章表dede_archives被标记有问题，需要修复。于是赶快恢复历史数据，上网查找原因。最终将问题解决。解决方法如下：

找到mysql的安装目录的bin/myisamchk工具，在命令行中输入：

myisamchk -c -r ../data/dedecmsv4/dede_archives.MYI

然后myisamchk 工具会帮助你恢复数据表的索引。重新启动mysql，问题解决。

问题分析：

1、错误产生原因，有网友说是频繁查询和更新dede_archives表造成的索引错误，因为我的页面没有静态生成，而是动态页面，因此比较同意

这种说法。还有说法为是MYSQL数据库因为某种原因而受到了损坏，如：数据库服务器突发性的断电、在提在数据库表提供服务时对表的原文件

进行某种 *** 作都有可能导致MYSQL数据库表被损坏而无法读取数据。总之就是因为某些不可测的问题造成表的损坏。

2、问题解决办法。

当你试图修复一个被破坏的表的问题时，有三种修复类型。如果你得到一个错误信息指出一个临时文件不能建立，删除信息所指出的文件并再

试一次--这通常是上一次修复 *** 作遗留下来的。

这三种修复方法如下所示：

% myisamchk --recover --quick /path/to/tblName

% myisamchk --recover /path/to/tblName

% myisamchk --safe-recover /path/to/tblName

第一种是最快的，用来修复最普通的问题；而最后一种是最慢的，用来修复一些其它方法所不能修复的问题。

检查和修复MySQL数据文件

如果上面的方法无法修复一个被损坏的表，在你放弃之前，你还可以试试下面这两个技巧：

如果你怀疑表的索引文件(*.MYI)发生了不可修复的错误，甚至是丢失了这个文件，你可以使用数据文件(*.MYD)和数据格式文件(*.frm)重新生

成它。首先制作一个数据文件(tblName.MYD)的拷贝。重启你的MySQL服务并连接到这个服务上，使用下面的命令删除表的内容：

mysql>DELETE FROM tblName

在删除表的内容的同时，会建立一个新的索引文件。退出登录并重新关闭服务，然后用你刚才保存的数据文件(tblName.MYD)覆盖新的(空)数据

文件。最后，使用myisamchk执行标准的修复(上面的第二种方法)，根据表的数据的内容和表的格式文件重新生成索引数据。

如果你的表的格式文件(tblName.frm)丢失了或者是发生了不可修复的错误，但是你清楚如何使用相应的CREATE

TABLE语句来重新生成这张表，你可以重新生成一个新的.frm文件并和你的数据文件和索引文件(如果索引文件有问题，使用上面的方法重建一

个新的)一起使用。首先制作一个数据和索引文件的拷贝，然后删除原来的文件(删除数据目录下有关这个表的所有记录)。

启动MySQL服务并使用当初的CREATE

TABLE文件建立一个新的表。新的.frm文件应该可以正常工作了，但是最好你还是执行一下标准的修复(上面的第二种方法)。

3、myisamchk工具介绍（见mysql的官方手册）

可以使用myisamchk实用程序来获得有关数据库表的信息或检查、修复、优化他们。myisamchk适用MyISAM表(对应.MYI和.MYD文件的表)。

调用myisamchk的方法：

shell>myisamchk [options] tbl_name ...

options指定你想让myisamchk做什么。在后面描述它们。还可以通过调用myisamchk --help得到选项列表。

tbl_name是你想要检查或修复的数据库表。如果你不在数据库目录的某处运行myisamchk，你必须指定数据库目录的路径，因为myisamchk不知

道你的数据库位于哪儿。实际上，myisamchk不在乎你正在 *** 作的文件是否位于一个数据库目录；你可以将对应于数据库表的文件拷贝到别处并

且在那里执行恢复 *** 作。

如果你愿意，可以用myisamchk命令行命名几个表。还可以通过命名索引文件(用“

.MYI”后缀)来指定一个表。它允许你通过使用模式“*.MYI”指定在一个目录所有的表。例如，如果你在数据库目录，可以这样在目录下检查

所有的MyISAM表：

shell>myisamchk *.MYI

如果你不在数据库目录下，可通过指定到目录的路径检查所有在那里的表：

shell>myisamchk /path/to/database_dir*.MYI

---