你有没有想过如何使用搜索功能在所有整站中实现！互联网博客和网站，大多数都采用MySQL数据库。MySQL提供了一个美妙的方式实施一个小的搜索引擎，在您的网站（全文检索）。所有您需要做的是拥有的MySQL 4.x及以上。MySQL提供全文检索功能，我们可以用它来 ??实现搜索功能。
创新互联于2013年成立，先为新泰等服务建站，新泰等地企业，进行企业商务咨询服务。为新泰企业网站制作PC+手机+微官网三网同步一站式服务解决您的所有建站问题。
首先，让我们为我们的例子中设置一个示例表。我们将创建一个名为第一个表。
CREATE TABLE articles (
id INT UNSIGNED AUTO_INCREMENT NOT NULL PRIMARY KEY,
title VARCHAR(200),
body TEXT,
FULLTEXT (title,body)
);
在此表中还可以添加一些示例数据。执行后，插入查询。
INSERT INTO articles (title,body) VALUES
('MySQL Tutorial','DBMS stands for DataBase ...'),
('How To Use MySQL Well','After you went through a ...'),
('Optimizing MySQL','In this tutorial we will show ...'),
('1001 MySQL Tricks','1. Never run mysqld as root. 2. ...'),
('MySQL vs. YourSQL','In the following database comparison ...'),
('MySQL Security','When configured properly, MySQL ...');
一旦样本数据是准备好，我们可以开始我们的全文检索功能。
自然语言全文搜索
尝试我们的示例表上执行下面的SELECT查询。
SELECT * FROM articles
WHERE MATCH (title,body) AGAINST ('database');
你就能看到结果如下：
在下面的数据库比较5 MySQL与YourSQL的...
MySQL教程DBMS 1代表数据库...
我们在上面的SQL查询（标题，正文）反对（“数据库”）的比赛，选择所有的记录，列标题和正文进行全文搜索。
您可以修改该查询，并创建您自己的版本，以自己的数据库中执行全文搜索。
布尔全文搜索
它可能发生，你要指定某些关键字在您的搜索条件。此外，您可能要忽略某些关键字。布尔全文搜索可以用来执行这些要求的全文检索。
检查下面的SELECT查询。
SELECT * FROM articles WHERE MATCH (title,body)
AGAINST ('+MySQL -YourSQL' IN BOOLEAN MODE);
如果您发现上述选择查询，我们增加了布尔MODE反对（）。这个查询将获取MySQL的关键字，但不YourSQL关键字的所有记录。请注意+和-我们以前指定的关键字！
在执行此功能，MySQL使用什么有时也被称为布尔逻辑作为暗示，其中：+代表与-代表不是[无操作员]暗示或
以下是几个例子布尔搜索条件。
“苹果香蕉
查找行至少包含两个词之一。
“+苹果+果汁”
寻找包含两个单词的行。
“+苹果Macintosh
查找行包含“苹果”，但排名的行，如果它们也包含“麦金塔”。
“+苹果Macintosh的”
查找行包含“苹果”这个词，而不是“麦金塔”。
'+苹果Macintosh的“
查找包含单词“苹果”的行，但如果该行也包含单词“麦金塔”，速度比如果行不低。这是“软”比“+苹果Macintosh电脑”，为“麦金塔”的存在，导致该行不能在所有返回的搜索。
'+苹果+（营业额馅饼）“
行包含“苹果”和“营业额”，或“苹果”和“馅饼”（任何顺序）的话，但排名“苹果的营业额”比“苹果馅饼“。
限制
支持全文检索的MyISAM表只。MySQL 4.1中，使用多个字符设置一个单一的表内的支持。然而，在一个FULLTEXT索引的所有列，必须使用相同的字符集和校对规则。MATCH（）列列表必须匹配完全在一些列清单表的FULLTEXT索引定义，除非这场比赛（）是在布尔模式。布尔模式搜索，可以做非索引列，虽然他们很可能是缓慢的。
二级索引？？
mysql中每个表都有一个聚簇索引（clustered index ），除此之外的表上的每个非聚簇索引都是二级索引，又叫辅助索引（secondary indexes）。
以InnoDB来说，每个InnoDB表具有一个特殊的索引称为聚集索引。如果您的表上定义有主键，该主键索引是聚集索引。如果你不定义为您的表的主键时，MySQL取第一个唯一索引（unique）而且只含非空列（NOT NULL）作为主键，InnoDB使用它作为聚集索引。如果没有这样的列，InnoDB就自己产生一个这样的ID值，它有六个字节，而且是隐藏的，使其作为聚簇索引。
聚簇索引主要是为了方便存储。。所以二级索引应该都是对聚簇索引的索引。
下面是Mysql Manual上的原话，也可能我理解有误。
Every InnoDB table has a special index called the clustered index where the data for the rows is stored. If you define a PRIMARY KEY on your table, the index of the primary key is the clustered index.
If you do not define a PRIMARY KEY for your table, MySQL picks the first UNIQUE index that has only NOT NULL columns as the primary key and InnoDB uses it as the clustered index. If there is no such index in the table, InnoDB internally generates a hidden clustered index on a synthetic column containing row ID values. The rows are ordered by the ID that InnoDB assigns to the rows in such a table. The row ID is a 6-byte field that increases monotonically as new rows are inserted. Thus, the rows ordered by the row ID are physically in insertion order.
Accessing a row through the clustered index is fast because the row data is on the same page where the index search leads. If a table is large, the clustered index architecture often saves a disk I/O operation when compared to storage organizations that store row data using a different page from the index record. (For example, MyISAM uses one file for data rows and another for index records.)
In InnoDB, the records in non-clustered indexes (also called secondary indexes) contain the primary key value for the row. InnoDB uses this primary key value to search for the row in the clustered index. If the primary key is long, the secondary indexes use more space, so it is advantageous to have a short primary key.
假如你有一个表， SQL CREATE TABLE test_tab (2 id INT, 3 name VARCHAR(10), 4 age INT, 5 val VARCHAR(10)6 );你的业务，有一个查询，是 SELECT * FROM test_tab WHERE name = 一个外部输入的数据 刚开始，数据不多的时候，执行效果还不错。 随着数据量的增加，这个查询，执行起来，越来越慢了。 然后在 name 上面 建立了索引 CREATE INDEX idx_test4_name ON test_tab (name ); 这样， 可以加快前面那个查询的速度。 但是，某天，你执行了下面这个SQL， 发现速度又慢了 SELECT * FROM test_tab WHERE age = 25 为啥呢？ 因为 age 字段上面，没有索引 索引只在 name 上面有 换句话说， 也就是 WHERE 里面的条件， 会自动判断，有没有 可用的索引，如果有， 该不该用。 多列索引，就是一个索引，包含了2个字段。 例如：CREATE INDEX idx_test_name_age ON test_tab (name, age);那么SELECT * FROM test_tabWHEREname LIKE '张%' AND age = 25 这样的查询，将能够使用上面的索引。 多列索引，还有一个可用的情况就是， 某些情况下，可能查询，只访问索引就足够了， 不需要再访问表了。例如：SELECTAVG( avg ) AS 平均年龄FROMtest_tabWHEREname LIKE '张%' 这个时候， name 与 age 都包含在索引里面。 查询不需要去检索表中的数据。
一般情况下，mysql会默认提供多种存储引擎,你可以通过下面的查看:
看你的mysql现在已提供什么存储引擎:
mysql show engines;
看你的mysql当前默认的存储引擎:
mysql show variables like '%storage_engine%';
你要看某个表用了什么引擎(在显示结果里参数engine后面的就表示该表当前用的存储引擎):
mysql show create table 表名;
MySQL数据库引擎详解
作为Java程序员，MySQL数据库大家平时应该都没少使用吧，对MySQL数据库的引擎应该也有所了解，这篇文章就让我详细的说说MySQL数据库的Innodb和MyIASM两种引擎以及其索引结构。也来巩固一下自己对这块知识的掌握。
Innodb引擎
Innodb引擎提供了对数据库ACID事务的支持，并且实现了SQL标准的四种隔离级别，关于数据库事务与其隔离级别的内容请见数据库事务与其隔
离级别这篇文章。该引擎还提供了行级锁和外键约束，它的设计目标是处理大容量数据库系统，它本身其实就是基于MySQL后台的完整数据库系统，MySQL
运行时Innodb会在内存中建立缓冲池，用于缓冲数据和索引。但是该引擎不支持FULLTEXT类型的索引，而且它没有保存表的行数，当SELECT
COUNT(*) FROM
TABLE时需要扫描全表。当需要使用数据库事务时，该引擎当然是首选。由于锁的粒度更小，写操作不会锁定全表，所以在并发较高时，使用Innodb引擎
会提升效率。但是使用行级锁也不是绝对的，如果在执行一个SQL语句时MySQL不能确定要扫描的范围，InnoDB表同样会锁全表。
MyIASM引擎
MyIASM是MySQL默认的引擎，但是它没有提供对数据库事务的支持，也不支持行级锁和外键，因此当INSERT(插入)或UPDATE(更
新)数据时即写操作需要锁定整个表，效率便会低一些。不过和Innodb不同，MyIASM中存储了表的行数，于是SELECT COUNT(*)
FROM
TABLE时只需要直接读取已经保存好的值而不需要进行全表扫描。如果表的读操作远远多于写操作且不需要数据库事务的支持，那么MyIASM也是很好的选
择。
两种引擎的选择
大尺寸的数据集趋向于选择InnoDB引擎，因为它支持事务处理和故障恢复。数据库的大小决定了故障恢复的时间长短，InnoDB可以利用事务日志
进行数据恢复，这会比较快。主键查询在InnoDB引擎下也会相当快，不过需要注意的是如果主键太长也会导致性能问题，关于这个问题我会在下文中讲到。大
批的INSERT语句(在每个INSERT语句中写入多行，批量插入)在MyISAM下会快一些，但是UPDATE语句在InnoDB下则会更快一些，尤
其是在并发量大的时候。
Index——索引
索引（Index）是帮助MySQL高效获取数据的数据结构。MyIASM和Innodb都使用了树这种数据结构做为索引，关于树我也曾经写过一篇文章树是一种伟大的数据结构，只是自己的理解，有兴趣的朋友可以去阅读。下面我接着讲这两种引擎使用的索引结构，讲到这里，首先应该谈一下B-Tree和B+Tree。
B-Tree和B+Tree
B+Tree是B-Tree的变种，那么我就先讲B-Tree吧，相信大家都知道红黑树，这是我前段时间学《算法》一书时，实现的一颗红黑树，大家
可以参考。其实红黑树类似2,3-查找树，这种树既有2叉结点又有3叉结点。B-Tree也与之类似，它的每个结点做多可以有d个分支（叉），d称为B-
Tree的度，如下图所示，它的每个结点可以有4个元素，5个分支，于是它的度为5。B-Tree中的元素是有序的，比如图中元素7左边的指针指向的结点
中的元素都小于7，而元素7和16之间的指针指向的结点中的元素都处于7和16之间，正是满足这样的关系，才能高效的查找：首先从根节点进行二分查找，找
到就返回对应的值，否则就进入相应的区间结点递归的查找，直到找到对应的元素或找到null指针，找到null指针则表示查找失败。这个查找是十分高效
的，其时间复杂度为O(logN)（以d为底，当d很大时，树的高度就很低），因为每次检索最多只需要检索树高h个结点。
接下来就该讲B+Tree了，它是B-Tree的变种，如下面两张图所示：
vcHLx/i85LLp0a/Qp8LKoaM8L3A+DQo8aDMgaWQ9"myisam引擎的索引结构"MyISAM引擎的索引结构
MyISAM引擎的索引结构为B+Tree，其中B+Tree的数据域存储的内容为实际数据的地址，也就是说它的索引和实际的数据是分开的，只不过是用索引指向了实际的数据，这种索引就是所谓的非聚集索引。
Innodb引擎的索引结构
MyISAM引擎的索引结构同样也是B+Tree，但是Innodb的索引文件本身就是数据文件，即B+Tree的数据域存储的就是实际的数据，这种索引就是聚集索引。这个索引的key就是数据表的主键，因此InnoDB表数据文件本身就是主索引。
因为InnoDB的数据文件本身要按主键聚集，所以InnoDB要求表必须有主键（MyISAM可以没有），如果没有显式指定，则MySQL系统会自动选择一个可以唯一标识数据记录的列作为主键，如果不存在这种列，则MySQL自动为InnoDB表生成一个隐含字段作为主键，这个字段长度为6个字节，类型为长整形。
并且和MyISAM不同，InnoDB的辅助索引数据域存储的也是相应记录主键的值而不是地址，所以当以辅助索引查找时，会先根据辅助索引找到主
键，再根据主键索引找到实际的数据。所以Innodb不建议使用过长的主键，否则会使辅助索引变得过大。建议使用自增的字段作为主键，这样B+Tree的
每一个结点都会被顺序的填满，而不会频繁的分裂调整，会有效的提升插入数据的效率。
explain显示了MySQL如何使用索引来处理select语句以及连接表。可以帮助选择更好的索引和写出更优化的查询语句。
使用方法，在select语句前加上explain就可以了：
如：
explain select surname,first_name form a,b where a.id=b.id
EXPLAIN列的解释：
table：显示这一行的数据是关于哪张表的
type：这是重要的列，显示连接使用了何种类型。从最好到最差的连接类型为const、eq_reg、ref、range、indexhe和ALL
possible_keys：显示可能应用在这张表中的索引。如果为空，没有可能的索引。可以为相关的域从WHERE语句中选择一个合适的语句
key： 实际使用的索引。如果为NULL，则没有使用索引。很少的情况下，MYSQL会选择优化不足的索引。这种情况下，可以在SELECT语句中使用USE INDEX（indexname）来强制使用一个索引或者用IGNORE INDEX（indexname）来强制MYSQL忽略索引
key_len：使用的索引的长度。在不损失精确性的情况下，长度越短越好
ref：显示索引的哪一列被使用了，如果可能的话，是一个常数
rows：MYSQL认为必须检查的用来返回请求数据的行数
Extra：关于MYSQL如何解析查询的额外信息。将在表4.3中讨论，但这里可以看到的坏的例子是Using temporary和Using filesort，意思MYSQL根本不能使用索引，结果是检索会很慢
extra列返回的描述的意义
Distinct:一旦MYSQL找到了与行相联合匹配的行，就不再搜索了
Not exists: MYSQL优化了LEFT JOIN，一旦它找到了匹配LEFT JOIN标准的行，就不再搜索了
Range checked for each Record（index map:#）:没有找到理想的索引，因此对于从前面表中来的每一个行组合，MYSQL检查使用哪个索引，并用它来从表中返回行。这是使用索引的最慢的连接之一
Using filesort: 看到这个的时候，查询就需要优化了。MYSQL需要进行额外的步骤来发现如何对返回的行排序。它根据连接类型以及存储排序键值和匹配条件的全部行的行指针来排序全部行
Using index: 列数据是从仅仅使用了索引中的信息而没有读取实际的行动的表返回的，这发生在对表的全部的请求列都是同一个索引的部分的时候
Using temporary 看到这个的时候，查询需要优化了。这里，MYSQL需要创建一个临时表来存储结果，这通常发生在对不同的列集进行ORDER BY上，而不是GROUP BY上
Where used 使用了WHERE从句来限制哪些行将与下一张表匹配或者是返回给用户。如果不想返回表中的全部行，并且连接类型ALL或index，这就会发生，或者是查询有问题不同连接类型的解释（按照效率高低的顺序排序）
system 表只有一行：system表。这是const连接类型的特殊情况
const:表中的一个记录的最大值能够匹配这个查询（索引可以是主键或惟一索引）。因为只有一行，这个值实际就是常数，因为MYSQL先读这个值然后把它当做常数来对待
eq_ref:在连接中，MYSQL在查询时，从前面的表中，对每一个记录的联合都从表中读取一个记录，它在查询使用了索引为主键或惟一键的全部时使用
ref:这个连接类型只有在查询使用了不是惟一或主键的键或者是这些类型的部分（比如，利用最左边前缀）时发生。对于之前的表的每一个行联合，全部记录都将从表中读出。这个类型严重依赖于根据索引匹配的记录多少—越少越好
range:这个连接类型使用索引返回一个范围中的行，比如使用或查找东西时发生的情况
index: 这个连接类型对前面的表中的每一个记录联合进行完全扫描（比ALL更好，因为索引一般小于表数据）
ALL:这个连接类型对于前面的每一个记录联合进行完全扫描，这一般比较糟糕，应该尽量避免