易栈网-膘叔

 继昨天的处理之后，又来新的笔记 ，这次的笔记纯粹是个人的测试，与实际条件有关，比如，我要查询的字段不超过varchar的255的长度，所以我才这么做。

昨天做普通索引后，1100万条记录，索引 为220M，改成全文索引后，索引文件为1.1G，存储空间上，涨了5倍左右。

以下是笔记 ，请不要笑话，场景不同而已

• 经过测试
  • title 字段改为全文索引后，在1100万条的时候
    • 优点：
      • 速度也为0.0x秒级。速度非常快
      • 即使有or条件，只要带了limit参数，速度也非常快
    • 缺点：
      • 如果查询不带limit ,直接卡死，因为他要计算total count
      • select count() 卡死
      • 如果查询不存在的关键字，卡死
  • 使用方法
    • 尽量不做select count 查询 （数量低于100万时可以考虑，超过100万时，其实已经没有必要）
    • 查询一定要带上limit条件
    • 每次查询到不存在的关键字时，记录到关键词库，每次有新增记录时，select 关键词库一下，如果新增房间中有关键字，则将关键词去除，避免卡死
• 暂时不使用coreseek（sphinx）/xunsearch等第三方工具
  • xunsearch只支持分词查询，不支持完全匹配
  • 第三方工具，耗内存，而且增量的时候，不够及时

 这是一篇未完成的博客，在这里面做了一点记录

这是昨天SAE分享的一篇文章，开始的时候，我看了一遍，发现好象没有什么特别的内容，但再仔细看的时候，发现居然可以这样做。。。

     问题描述：

      我们要访问的表是一个非常大的表，四千万条记录，id是主键，program_id上建了索引。

      执行一条SQL:

      这条SQL非常慢。我们原以为处理记录太多的原因，所以加了id限制，一次只读五十万条记录

      但是这条SQL仍然很慢，速度比上面一条几乎没有提升。Mysql处理50万条记录的表，条件字段还建了索引，这条语句应该是瞬间完成的。

      问题分析：

      这张表大约容量30G，数据库服务器内存16G，无法一次载入。就是这个造成了问题。

      这条SQL有两个条件，ID一到五十万和Program_id一到四千，因为program_id范围小得多，mysql选择它做为主要索引。

      先通过索引文件找出了所有program_id在1到4000范围里所有的id，这个过程非常快。

      接下来要通过这些id找出表里的记录，由于这些id是离散的，所以mysql对这个表的访问不是顺序读取。

      而这个表又非常大，无法一次装入内存，所以每访问一条记录mysql都要重新在磁盘上定位并把附近的记录都载入内存，大量的IO操作导致了速度的下降。

      问题解决方案：

1. 以program_id为条件对表进行分区

2. 分表处理，每张表的大小不超过内存的大小

      然而，服务器用的是mysql5.0，不支持分区，而且这个表是公共表，无法在不影响其它项目的条件下修改表的结构。所以我们采取了第三种办法：

      现在program_id的范围远大于id的范围，id被当做主要索引进行查找，由于id是主键，所以查找的是连续50万条记录，速度和访问一个50万条记录的表基本一样

      总结：

      这是一个在千万笔记录表中由于使用了索引导致了数据查找变慢的问题，有一定的典型性和大家交流下！

-----------

看我标红的那一段，原来还能够这样做，以前真的没有注意过，也从来没有想过，先利用主键做一次过滤。这样效率会好很多啊

上述内容来自：http://ourmysql.com/archives/108?f=wb，该网站还有很多技巧值得一看。

数据库是否建索引以及如何更好的建索引，当然是有讲究的。虽然都知道建了索引后，在按条件搜索的时候速度会快很多，但其实，如果索引建的不合理，反而是使得数据库效率降低。何时需要建索引，其实是值得深究的，创建之后，怎样判断效率，当然还得好好学习。要多做尝试才会知道。

这一篇讲的比较详细，所以就转载了，来自冰山的http://xinsync.xju.edu.cn/index.php/archives/6845。

在数据库表中，对字段建立索引可以大大提高查询速度。假如我们创建了一个 mytable表：

我们随机向里面插入了10000条记录，其中有一条：5555, admin。

在查找 username=”admin” 的记录 SELECT * FROM mytable WHERE username=’admin’; 时，如果在username上已经建立了索引，MySQL无须任何扫描，即准确可找到该记录。相反，MySQL会扫描所有记录，即要查询10000条记 录。

索引分单列索引和组合索引。单列索引，即一个索引只包含单个列，一个表可以有多个单列索引，但这不是组合索引。组合索引，即一个索包含多个列。

索引的类型包括：

（1）普通索引
这是最基本的索引，它没有任何限制。它有以下几种创建方式：
●     创建索引

如果是CHAR，VARCHAR类型，length可以小于字段实际长度；如果是BLOB和TEXT类型，必须指定 length，下同。
●     修改表结构

●     创建表的时候直接指定

删除索引的语法：

（2）唯一索引

它与前面的普通索引类似，不同的就是：索引列的值必须唯一，但允许有空值。如果是组合索引，则列值的组合必须唯一。它有以下几种创建方式：
●     创建索引

●     修改表结构

●     创建表的时候直接指定

（3）主键索引

它是一种特殊的唯一索引，不允许有空值。一般是在建表的时候同时创建主键索引：

当然也可以用 ALTER 命令。记住：一个表只能有一个主键。

（4）组合索引

为了形象地对比单列索引和组合索引，为表添加多个字段：

为了进一步榨取MySQL的效率，就要考虑建立组合索引。就是将 name, city, age建到一个索引里：

建表时，usernname长度为 16，这里用 10。这是因为一般情况下名字的长度不会超过10，这样会加速索引查询速度，还会减少索引文件的大小，提高INSERT的更新速度。

如果分别在 usernname，city，age上建立单列索引，让该表有3个单列索引，查询时和上述的组合索引效率也会大不一样，远远低于我们的组合索引。虽然此 时有了三个索引，但MySQL只能用到其中的那个它认为似乎是最有效率的单列索引。

建立这样的组合索引，其实是相当于分别建立了下面三组组合索引：

为什么没有 city，age这样的组合索引呢？这是因为MySQL组合索引“最左前缀”的结果。简单的理解就是只从最左面的开始组合。并不是只要包含这三列的查询都 会用到该组合索引，下面的几个SQL就会用到这个组合索引：

而下面几个则不会用到：

（5）建立索引的时机

到这里我们已经学会了建立索引，那么我们需要在什么情况下建立索引呢？一般来说，在WHERE和JOIN中出现的列需要建立索引，但也不完全如此， 因为 MySQL只对<，<=，=，>，>=，BETWEEN，IN，以及某些时候的LIKE才会使用索引。例如：

此时就需要对city和age建立索引，由于mytable表的userame也出现在了JOIN子句中，也有对它建立索引的必要。

刚才提到只有某些时候的LIKE才需建立索引。因为在以通配符%和_开头作查询时，MySQL不会使用索引。例如下句会使用索引：

而下句就不会使用：

因此，在使用LIKE时应注意以上的区别。

（6）索引的不足之处

上面都在说使用索引的好处，但过多的使用索引将会造成滥用。因此索引也会有它的缺点：

●     虽然索引大大提高了查询速度，同时却会降低更新表的速度，如对表进行INSERT、UPDATE和DELETE。因为更新表时，MySQL不仅要保存数 据，还要保存一下索引文件。

●     建立索引会占用磁盘空间的索引文件。一般情况这个问题不太严重，但如果你在一个大表上创建了多种组合索引，索引文件的会膨胀很快。

索引只是提高效率的一个因素，如果你的MySQL有大数据量的表，就需要花时间研究建立最优秀的索引，或优化查询语句。

（7）使用索引的注意事项

使用索引时，有以下一些技巧和注意事项：

●     索引不会包含有NULL值的列

只要列中包含有NULL值都将不会被包含在索引中，复合索引中只要有一列含有NULL值，那么这一列对于此复合索引就是无效的。所以我们在数据库设 计时不要让字段的默认值为NULL。

●     使用短索引

对串列进行索引，如果可能应该指定一个前缀长度。例如，如果有一个CHAR(255)的列，如果在前10个或20个字符内，多数值是惟一的，那么就 不要对整个列进行索引。短索引不仅可以提高查询速度而且可以节省磁盘空间和I/O操作。

●     索引列排序

MySQL查询只使用一个索引，因此如果where子句中已经使用了索引的话，那么order by中的列是不会使用索引的。因此数据库默认排序可以符合要求的情况下不要使用排序操作；尽量不要包含多个列的排序，如果需要最好给这些列创建复合索引。

●     like语句操作

一般情况下不鼓励使用like操作，如果非使用不可，如何使用也是一个问题。like “%aaa%” 不会使用索引而like “aaa%”可以使用索引。

●     不要在列上进行运算

将在每个行上进行运算，这将导致索引失效而进行全表扫描，因此我们可以改成

●     不使用NOT IN和<>操作

NOT IN和<>操作都不会使用索引将进行全表扫描。NOT IN可以使用NOT EXISTS代替，id<>3则可以使用id>3 or id<3来代替。

--EOF--

本博客内部关于MYSQL索引的相关文章有：

MYSQL索引之小小分析

［分享］mysql数据库索引查询优化的分享

联合索引的经典例子

当然，对于索引，肯定要看MYSQL中EXPLAIN的说明

1.SQL需求，统计当天的数据量。

2.查看其索引，以gmt_create开头。

3.查看awr报表的性能，逻辑读很高，达到9700个。

因为是只通过索引扫描，当看到返回结果集在2万左右，我们很容易估算出这个sql需要的逻辑读，(gmt_date字段7个字节+win_type字段1个字节+rowid+…）*2万，小于100个，现在很明显是偏高的。
4.调整前我们先去看数据分布。

5.调整索引,改为以win_type开头，为什么要以win_type开头呢？

6.查看其执行计划，逻辑读变成了89。

都在说建索引一定要看数据分布，从数据分布来看，一天的的数据(gmt_create)量在22万左右，而win_type的数据量非常 大，win_type为1有300万左右，为什么还要把win_type放在索引的前面呢？抛块砖，希望大家能对联合索引有更深入的理解，希望一起讨论。

--EOF--

帖子下的几个评论也很有意思：