My SQL数据库实用技术（21）

其中表达式并不将索引列与1990 比较，而是将从列值计算出的值用于比较，而且必须计算每行的这个值。结果是， date_col 上的索引不可能得到使用。怎样解决？使用一个文字日期即可，这时将会使用date_col 上的索引：
WHERE date_col < "1990-01-01"
但是假如没有特定的日期值，那么可能会对找到具有出现在距今一定天数内的日期的记录感爱好。有几种方法来编写这样的查询，但并非所有方法都很好。三种可能的方法如下:

其中第一行不能利用索引， 因为必须为每行检索列， 以便能够计算TO _ D AYS(date_col) 的值。第二行要好一些。c u t o ff 和TO _ DAY S ( CURRENT _ DATE) 两者都是常量，因此比较表达式的右边可在查询处理前由优化程序一次计算出来，而不是每行计算一次。但date_col 列仍然出现在一个函数调用中，因此，没有使用索引。第三行是最好的方法。比较表达式的右边可在执行查询前作为常量一次计算出来，但现在其值是一个日期。这个值可直接与date_col 的值进行比较，不再需要转换为天数，可以利用索引。
■ 在LIKE 模式的起始处不要使用通配符。有时，有的人会用下列形式的WHERE 子句来搜索串：

内容来自dedecms

WHERE col_name LIKE "%string%"
假如希望找到s t r i n g，不管它出现在列中任何位置，那么这样做是对的。但不要出于习惯在串的两边加“ %”。假如实际要查找的只是出现在列的开始处的串，则不应该要第一个“%”号。例如，假如在一个包含姓的列中查找“ M a c”起始的姓，应该编写如下的WHERE 子句：
WHERE last_name LIKE "Mac%"
优化程序考虑模式中的开始的文字部分，然后利用索引找到相符合的行。不过宁可写成如下的表达式，它答应使用last_name 上的索引：
WHERE last_name >= "Mac" AND last_name < "Mad"
这种优化对使用REGEXP 操作符的模式匹配不起作用。
■ 帮助优化程序更好地评估索引的有效性。缺省时，假如将索引列中的值与常量进行比较，优化程序将假定键字是均匀地分布在索引中的。优化程序还将对索引进行一个快速的检查，以估计在确定相应的索引是否应该用于常量的比较时要使用多少条目。可利用myisamchk 或isamchk 的--analyze 选项给优化程序提供更好的信息，以便分析键值的分布。myisamchk 用于MyISAM 表，isamchk 用于ISAM 表。为了完成键值分析，必须能够登录到MySQL 服务器主机中，而且必须对表文件具有写访问权限。
■ 利用EXPLAIN 检验优化程序操作。检查用于查询中的索引是否能很快地排除行。假如不能，那么应该试一下利用STRAIGHT_JOIN 强制按特定次序使用表来完成一个连接。查询的执行方式不那么显然；MySQL 可能会有很多理由不以您认为最好的次序使用索引。 dedecms.com
■ 测试查询的其他形式，而且不止一次地运行它们。在测试一个查询的其他形式时，应该每种方法运行几次。假如对两个不同方法中的每种只运行查询一次，通常会发现第二个查询更快，因为来自第一个查询的信息在磁盘高速缓存中，不需要实际从磁盘上读出。还应该尽量在系统负载相对平稳的时候运行查询，以避免受系统中其他活动的影响。
4.2.2 忽略优化
这可能听起来有点希奇，但在以下情况中，要废除MySQL 的优化功能：
■ 强迫MySQL 慢慢地删除表的内容。在需要完全删空一个表时，利用无WHERE 子句的DELETE 语句删除整个表的内容是最快的，如下所示：
DELETE FROM tb1_name
MySQL 对这种非凡情况的DELETE 进行优化；它利用表信息文件中的表说明从头开始创建空数据文件和索引文件。这种优化使DELETE 操作极快，因为MySQL 无需单独地删除每一行。但在某些情况下，这样做会产生一些不必要的负作用：

看完这篇，您有何感觉呢？

上一篇：My SQL数据库实用技术（19）   下一篇：My SQL数据库实用技术（22）

用户名(必填) 新注册

密码(必填) 匿名评论