想请问几个Mysql中的常见但又值得讨论的问题，1、怎样提高Like查询的效率，或有什么替代的办法？2、分页中，limit读取和全部读取再行分页

Question

想请问几个Mysql中的常见但又值得讨论的问题，1、怎样提高Like查询的效率，或有什么替代的办法？不知道怎么算like，是和shell通配符一样么？
先把数据都选出来,用fnmatch匹配一下试试

Answer 1

由于用mysql的项目都很小，也没深入去研究过mysql.感觉挺好，最近想用mysql做个大点的产品性应用，这不得不对考虑一些以前没注意的问题了。
1、很多地方都提到使用了LIKE '%keyword%'，特别是多个字段都进行模糊查询，效率会大副下降，但在数据库查询中，这又是不得不经常用到的，那么该怎么提高效率呢？
    索引对模糊查询是否起作用？
    又其它方法也能达到模糊查询的功能吗？2、看到很多分页的探讨，主要有三种：
    最常见的就是limit，第二是先读取，再选择某段范围的数据进行显示，再则是，建立分页的索引表。
    第一种，最方便，有没有提高效率的办法？也要使用索引吗？
    第二种，好象效率不会高，因为会把数据全部读出来，是这样吗？
    第三种，没增加、删除数据都需要维护分页表，太麻烦，并且容易造成数据不统一问题。    有什么更好的建议吗？3、组合索引，title 、id都建立了索引，但不是组合索引，那么当进行 WHERE title = '关键字' AND id > 100 的组合查询时是不起作用的呢？4、读取数据时，先将所有的数据记录读入数组，再对数组进行循环输出，是否会效率很低？另，转两篇关于mysql优化的贴子。
MySQL优化简明指南
http://community.csdn.net/Expert/topic/4810/4810242.xml?temp=.7860681MySql中管理百万级要注意些什么东西
http://community.csdn.net/Expert/topic/4810/4810254.xml?temp=.7779657

Answer 2

1 .LIKE '%keyword%'这种写法无办法索引和优化。一般只能对搜索结果做缓存。
2 .用limit不用说了
3 .mysql每条查询只会使用一个索引。
4 .不会。这是最常用的做法。当然前提是你读的数据不会太多。

Answer 3

LIKE 'keyword%'这样搜索时可以索引。

Answer 4

1、like不会使用索引，也无法使用索引
2、对大容量的字段（text）进行查询应用全文检索索引，但是mysql的全文检索不支持中文（“海量”的除外）
简单的替代解决办法是：
a、切割文字为词组，另存入表中进行查询。由于可利用索引，所以速度很快。只是要增加3-4倍存储空间。具体的做法可见phpBB
b、把文字转换为拼音存入有全文检索索引的字段，可直接利用数据库的全文检索功能，速度更快。也是要增大3-4倍存储空间
3、使用limit是必然的，只取需要数量的记录何了而不为呢？
4、是否“先将所有的数据记录读入数组”完全取决于你对数据的后继处理方式，不存在效率问题。当然，要多用些内存

Answer 5

1 like，在应用中应该尽量避免这样的语句的使用，如果实在避免不了，如果愿意可以尝试使用 全文索引：P
2 习惯用limit 并可以适当优化（翻页时带上其他限制条件）
3 如果你的查询种类比较固定，那么在应用时可以尝试优化索引。

Answer 6

看到大家的讨论想到几点：
2.1、to:xuzuning(唠叨)，>>切割文字为词组，另存入表中进行查询。由于可利用索引，所以速度很快。只是要增加3-4倍存储空间。
   这样我觉得不是3-4倍的问题了，全文检索因为文中的任何一个字符或字符串（包括汉字），都可能被检索，这些可能被检索的字符串都存到索引表里吗？并且是应该在第一次被搜索的时候对内容进行分析，然后把匹配的数据进行记录。是这样吗？这样的话，这个量和效率也值得思考。抱歉，我还没看过phpBB，所以对其做法不了解，以上肯定存在不正确的理解，我等会看看phpBB。
并，我记得唠叨在哪个帖子讨论过这个事情。2.2、我有看到有说使用limit效率会降低很多，有这样的说法吗？特别对于大数据量的数据库。因为它要去定位记录集。2.3、现在有很多分页采用AJAX实现，有两疑问：
1）假如把数据都先取出来再分页，那么相应的数据量（xml数据）会很大，这样岂不是效率更低；
2）假如是对AJAX传递分页参数和查询url，这样每次都仍然是先查询数据记录，再输出，这好象没有太大的意义；2.4、谁能简要讲述下数据库查询的缓存使用方法，是把查询条件和查询结果记录起来，或存储在哪里吗？2.5、两表关联的查询效率和两次单独查询单个表的效率，应该哪个高？

Answer 7

2.2、我有看到有说使用limit效率会降低很多，有这样的说法吗？特别对于大数据量的数据库。因为它要去定位记录集。是吗？那么读取全部数据就要快些吗？在读取数据库中间的记录时，无论是否使用索引，都是需要从头开始一条一条筛选的
使用limit与读取全部数据的不同之处在于：前者在读取到满足条件的指定数量的记录后就不再读了，而后者是一定要读到全部结束。我不知道那种更占优势，自己评判吧！
2.3、现在有很多分页采用AJAX实现，有两疑问：
.....所以我说“完全取决于你对数据的后继处理方式”

Answer 8

如果表有100W行 谁会一次全读回来？？少用like 没效率 如果非要用的话 关键字索引表是个好东西

Answer 9

to：xuzuning(唠叨) 
搞混了，不是这个意思。我是看到说limit需要根据起始位置逐条筛选，于是会效率很低；
当然全部读取和它相比更不可取；>>但这种筛选的影响，对大数据量数据（大于10w条）影响有多大；>>我看到有介绍说，对于这样的情况，不应当用limit，而是应该通过建立分页索引表，或其它的方式，先建立连续的id序列，或建立每页id范围的记录表，再根据这个表去分页查询。我是觉得limit的影响有这个大吗？有必要用第二种方法或采用其它方法吗？

Answer 10

其实最方便的方法就是保持ID这个字段的连续性 分页索引也是这个意思 虽然有10W数据但常用的不超过1K 建立常用数据表也是个好办法

Answer 11

limit的实际使用性能是很好的。100w以内的数据量都没必要想别的。
一个分页索引基本只能面向某一条sql。维护这个分页索引的代价太大。所以只有数据量超大，而且改动很少的时候才比较实用。

Answer 12

web上应该不存在使用分页索引的情况。web的数据库都是以微秒为执行时间单位的。limit完全可以胜任。你看的文章极有可能是基于桌面系统的(以分钟甚至小时为执行时间单位)。