从开始使用mysql起， 就觉得：
1. 索引的使用对innodb的性能的影响是很大的， 在做explain的时候， 当extra中出现了filesort的时候一般就意味者低效率和应当优化sql语句
2. 在select语句中， where中用到的条件字段order by中的字段最好是同一个(些)字段(假定只有都只有一个(些)字段)， 且这个字段最好是有索引的， 这样在explain的时候， type就会是index, 且extra中不会有filesort; 如果where中的字段和order by的字段不一样的话， 则可能出现filesort, 从而会导致低效
在实际中遇到了一个例子， 发现上面的理解其实是比较片面的， 这个例子的大体情况是：
表t_mytable中有字段F_time_1和F_time_2,分别是datatime， 且分别都有索引；字段F_pid是主键
1. 运行sql语句 SELECT … FROM t_mytable WHERE F_pid=’val’ AND F_time_1>= ‘time1′ AND F_TIME_1 <= ‘time2′ ORDER BY F_time_1， 记录条目是12条， 但发现效率很低；觉得很奇怪：这个语句的效率应该高才对的
2. 尝试着改了一下sql语句为SELECT … FROM t_mytable WHERE F_pid=’val’ AND F_time_2>= ‘time1′ AND F_TIME_2 <= ‘time2′ ORDER BY F_time_1，记录条目是8条，效率很高；
阅读全文…
相关日志
第十五 基于函数的索引要求等式匹配
上面的例子中，我们创建了基于函数的索引，但是如果执行下面的查询：
select * from emp where substr(ename,1,1)=’S’ 阅读全文…
相关日志
第十一 like子句尽量前端匹配
因为like参数使用的非常频繁，因此如果能够对like子句使用索引，将很高的提高查询的效率。
例6：select * from city where name like ‘%S%’
以上查询的执行计划用了全表扫描（TABLE ACCESS FULL），如果能够修改为：
select * from city where name like ‘S%’。 阅读全文…
相关日志
第七 索引提高数据分布不均匀时查询效率
索引的选择性低，但数据的值分布差异很大时，仍然可以利用索引提高效率。A、数据分布不均匀的特殊情况下，选择性不高的索引也要创建。
表ServiceInfo中数据量很大，假设有一百万行，其中有一个字段DisposalCourseFlag，取值范围为枚举值：[0，1，2，3，4，5，6，7]。按照前面说的索引建立的规则，“选择性不高的字段不应该建立索引，该字段只有8种取值，索引值的重复率很高，索引选择性明显很低，因此不建索引。然而，由于该字段上数据值的分布情况非常特殊，具体如下表： 阅读全文…
相关日志
第一 避免对列的操作
任何对列的操作都可能导致全表扫描，这里所谓的操作包括数据库函数、计算表达式等等，查询时要尽可能将操作移至等式的右边，甚至去掉函数。
例1：下列SQL条件语句中的列都建有恰当的索引，但30万行数据情况下执行速度却非常慢： 阅读全文…
相关日志
一个系统执行效率的高低包括很多因素，而一旦涉及到数据库，那么SQL语句的执行效率就是重中之重，在规模比较大的局点，往往因为一个小的SQL语句不够优化，导致数据库性能急剧下降，小型机idle所剩无几，应用服务器断连、超时，严重影响业务的正常运行。因此，称低效的SQL语句为客服业务的‘恶龙’并不过分。数据库的优化方法有很多种，在应用层来说，主要是基于索引的优化。 阅读全文…
相关日志
数据库索引是为了增加查询速度而对表字段附加的一种标识。见过很多人机械的理解索引的概念，认为增加索引只有好处没有坏处。这里想把之前的索引学习笔记总结一下：
首先明白为什么索引会增加速度，DB在执行一条Sql语句的时候，默认的方式是根据搜索条件进行全表扫描，遇到匹配条件的就加入搜索结果集合。如果我们对某一字段增加索引，查询时就会先去索引列表中一次定位到特定值的行数，大大减少遍历匹配的行数，所以能明显增加查询的速度。那么在任何时候都应该加索引么？这里有几个反例：1、如果每次都需要取到所有表记录，无论如何都必须进行全表扫描了，那么是否加索引也没有意义了。2、对非唯一的字段，例如”性别”这种大量重复值的字段，增加索引也没有什么意义。3、对于记录比较少的表，增加索引不会带来速度的优化反而浪费了存储空间，因为索引是需要存储空间的，而且有个致命缺点是对于update/insert/delete的每次执行，字段的索引都必须重新计算更新。 阅读全文…
相关日志
